Why create domain models? The book said to better understand key concepts
and vocabulary but isn't that what a glossary is for?
A diagram is worth 1K words.
Some people have visual minds.
A glossary does not make connections between entries visible. A Class
Use the glossary for details like: an sid has 9 digits. Use Domain model to
show that every student has an sid as an attribute.
Is the primary purpose of the domain model to solely complement a set of
In my opinion there is more to domain modeling than complementing the use cases.
They give different views of what is needed.
There are two real purposes for domain models. (1) they force you to
the stakeholders (and users) better. (2) they are used when you design
software to serve those stakeholders.
On page 132 it says "As with all things in an agile modeling and UP spirit,
a domain model is optional." Is this some kind of joke or can we option
not to have a domain model in our project?
How do you decide which artifacts are necessary to a project?
It is not a joke. In a real project you decide what artifacts are worth
doing in any given iteration and at any given time.
However, in this class, I have to be sure that you have the option to
either produce and artifact when it is needed.
that I will be requiring domain models for your projects -- just to give you
How useful in your observations is it to have domain models separate from
use cases (and how often is it beneficial) to do the domain modeling?
I used domain models for 20 years before we had use cases. Domain modeling
been that vital first step in most of my projects for a long time. However these
days I may sketch out some use cases first to get an idea of what
are the important parts of the real world that my software has to
They do different things: the use cases force you to provide something of
clear value to the user and stakeholders. The domain model provides you with a structure
that helps you figure out the internal details of object oriented design.
So you need a mix of both. Use Cases focuses your effort on the
things in the domain that need modeling, and Domain models
inspire some of the details your design.
I think that putting a domain model (graphic) and a ton of use cases
in a single document is unwise.
Use cases feel much more intuitive than domain models. What do domain
models expose that use cases do not?
The reality behind the things the users want to do. A set of use cases
can tell you what people need to do ... a domain model connects
A use case answer the question "how does a student enroll in a course",
a domain models can rapidly answer questions like "how many courses
can a student be enrolled in at one time".
Are conceptual models, domain object models, and analysis object models,
the same as domain model?
Not quite. Conceptual models can be Chen style ERD/data base designs.
A domain model is simpler and omits some classes and lots of attributes.
I think a domain object model is the same as Larman's "domain model".
Analysis object models are very similar to domain models.
We divide up a complex piece of software into layers -- there is
a lot more on this coming in the rest of the class. Each layer
is a collection of related classes. One layer contains a lot of
information about the User Interfaces. The next layer is the
"Domain Layer" which implements the classes that reflect the business:
the rules, entities, etc. Inside that we have some very technical layers
like the "Persistence layer" that looks after the data base.
More later in the course.
Listen to the stakeholders. Look in your use cases for nouns.
For more see
[ 06.html ]
and pages 138 onward.
What are the important factors of using a domain model?
When drawing a model -- listening to the stakeholders and accurately
drawing what they are thinking. Secondly -- not making the model
over elaborate: no operations, few attributes, no data types,... put
data details in Glossary/Data Dictionary. Rough at first -- tidy when
Later when designing you'll need a readable picture of the stakeholder's
world as a source of Design Classes.
Is the elaboration phase the first phase you can start coding? If so how
much should you be coding?
You can code up a few prototypes in inception, but the real start of
high-quality code is in elaboration.
It was indicated that the inception phase may last only one week. How long
should the Elaboration phase last?
It will depend on the project -- how many iterations will it take to
resolve all the
really unstable and risky requirements?
The book says that elaboration involves programming and testing the core
risky software architecture, discovering and stabilizing the majority of
the requirements, and mitigating and retiring the major risks, this list
makes elaboration seem complex and difficult; is elaboration the most
difficult phase in the unified process?
I think it is. Also the least boring and most creative. Unless, of
you enjoy coding well understood requirements using well designed classes.
Out of the artifacts for the elaborations phase which is the most important
one that should be done first?
The one that teaches you most about the project.
Ask "What don't we know?" and then look for a way to learn and record the
How many artifacts do we need for the elaboration phase?
It depends on the project -- each use case leads to an artifact... so
many use cases means many artifacts.
The idea of iterations is to give a little improvement to the stakeholders
at a time, right? So if you handle the difficult tasks first, it could
take a long time to get that first iteration done, and then if they hate
it, you have nothing. So wouldn't it be better to do something not so
difficult first and then the most difficult thing?
I used to agree with you. But no longer. Now I say:
"Tackle Risks before they tackle you."
In my research into software development projects
I found out that
many projects go over schedule
and budget because they discover some bad news in the last 10% of
the available time. So it is a wise strategy to go for the
"interesting" things first.
Notice that if the leading risk is that the stakeholders will loose faith
then the first priority will be to do something that will
win their confidence -- for example a rapid (easy) throw-away prototype
during the inception phase. Similarly if
you are not sure what the stakeholders need then you should also
do some throw-away prototyping in inception, and before elaboration.
Elaboration is about XRaying the problem like a hospital does
before deciding on an operation -- what complications might occur? Can
we mitigate them? Can we prepare for them?
Can you give us an example of an artifact that started in elaboration?
Open the front of the book. At the top of the left hand inside cover
there is a table. Go down the column headed Elab. Look at each row
that has an 's' for start in the Elab column. Domain Model is the first
(Today's topic). There are 4 others. Exercise: which?
Do all good projects have to contain a domain model or is it just an extra
With small projects you can get away with doing the model in your head.
Example: there would be a single class in the model.
Problems occur if the project expands
and you have to explain your thoughts to somebody who just joined the team.
Is the domain model meant to be strictly followed? It seems as though its
not necessary from a software development point of view.
Once upon a time we thought that the domain model was the same as
the class diagram describing the objects implemented in the software.
Now we know better. The domain model is an excellent place to
find design class names. But the precise structures in our design
come from analyzing the necessary interactions between objects
needed to realize use cases.
Would it be safe to say that domain models include the relevant nouns and
their attributes in a system?
The hard part is the word "relevant":-)
What are the advantages of doing the domain model in the elaboration phase
as opposed to the inception phase? It would appear that having a domain
model in place would be helpful in determining use cases.
I tended to agree... But many experts and practitioners prefer
to have the use case model first to control and guide the growth
of the domain model. Inception lets you pick a few important
features and your first domain model is limited to these needs: KISS.
The risk of doing a domain model early is drawing things `You Ain't Gonna
Modern methodologists aim for lean or low ceremony methods and
so they minimize the number of artifacts they mention and delay their
introduction as long as they can.
How does a Domain Model differ from a DFD?
A DFD shows how data moves through an enterprise: where it comes
from(sources), where it is stored(entities), where is is changed and
(processes), and where it finally goes to (sinks).
A domain model does not show movement but ideas about the real world.
In particular it does not show any processing/activity.
If you are given a DFD then you can find candidate classes and
associations by looking at the names of: sources, stores, flows,
and sinks. But you must be careful to remove references to
the implementation (data base, table, punched card(;-), ...).
A data model shows how to organize persistent data. A domain model
describes the ideas in the real world surrounding the computer system.
You can take the domain model and remove all things that don't need to be
remembered between use cases and add the keys and entities that normalize
the data, and then refactor the data to get adequate performance...
On page 134 the books calls the Domain Model a "Visual Dictionary" and they
also say that it could alternatively have been expressed in plain text by
using the UP Glossary. Which one is better to use, the Domain Model, the UP
Glossary, or should you use both?
Note: In my experience, glossaries are faster with computerized tools and
diagrams better with manual ones. You can sketch a fast domain model
with pencil+paper or Board+marker a lot faster than you can write down
and sort a set of definitions. Retrieving information from a diagram
can be much faster than reading text... So text is
best on a computer system that has a good search engine.
A domain model is a picture of things outside the software, not inside it.
This is a deliberate decision to think about the problem before we try to solve it.
We deliberately document the stakeholder's ideas before we decide how to code them.
Is the domain model a series of boxes showing the visualization if it has multiple steps or just one box, one small concept.
Domain models do not show steps in a process. They are not flow charts!
The typical model is a picture of types of things and their properties and relationships.
They show a set of entities connected by lines. No steps. Hardly ever just
one box. No series. Think: network diagram or electrical circuit. Or a map
of a transport system. Parts and connections. Things and their properties.
The book lists three strategies for finding conceptual classes, but only
discusses two of them. What is the best way to find the conceptual classes?
Which do you prefer?
With experience you can not miss domain model classes!
I like to do it like this: (1) noun phrases, (2) existing models and experience, (3) categories.
When learning -- do it in the order suggested: patterns, categories, nouns.
When I grade: I DO NOT CARE how you found the classes and associations -- they just have to
be believable when found.
In the definition for a conceptual class, the author vaguely defines it by
alluding to ideas, things or objects. Why is it that a hierarchy of the
abstraction is not considered instead? Intrinsically, it appears that
classes should somehow be categorized as domains are divided into layers.
Larman introduces hierarchies of abstraction later. The UML
of generalization is needed.
I've never seen a layered domain model. However we do introduce layers
in our designs to separate the user interface from the business logic for example.
This is something different -- later.
Could you explain a example of Domain Layers?
Later. The key idea is that our software has a specific set of objects whose
purpose is to model the sate of the user's world. It is a mirror world. Similar
names for the classes, associations reflect real relationships, operations that
are triggered by real world events. Typically, these classes rely on other "layers"
to -- for example: look after the data base, communicate with the user, record errors,
and so on. We will talk about this layered architecture later.
Also how do domain models and domain layers differ from each other?
A layer is a collection of classes in the software that share a common purpose.
Examples would be running the GUI, interfacing with the database, listening
to the user, keeping track of what is being done, etc.
The domain is in the real world. You can often kick the objects pictured in the
domain model. The Domain layer is inside the software -- objects. Unkickable.
Formal distinction: models of software, like the "domain layer", include some
extra decorations like arrowheads and diamond ends.
Larman and all other methodologists separate the design and code for
doing the user interface from the design and code for the logic
of the problem. They are kept separate so that (1) we can rapidly change
from one device or platform to another as needed. (2) we don't have to
worry about two incompatible problems (look_and_feel vs how it
works) at the same time.
This is one of the oldest patterns for modularizing software.
The domain model should avoid mentioning the user interface -- no
screens, table, panels, HTML controls, formats, colors, etc. This
should be treated as a separate model. It is a design model.
A Domain model is a picture of the user's world outside the software
you are designing.
Think of the user interface as the sides of a box
with the logic inside and the user outside. The domain model
is a drawing of what is outside the box... not a diagram of
the label on the box. Designing the label is not the same as designing
the device inside....
No. The domain layer is the part of the design that is inspired by the domain model.
No. Resist the temptation to do so.
By the end of a long project of any complexity you will
probably abandon the domain model (except as a rough
introduction for newcomers) and keep a special set of diagrams
defining the domain layer in the new software. If done
well you'll be able to reverse engineer a domain model
from the domain layer.
- Chapter 9 pages 134 -- Abstraction
What does the book mean when by, "an abstraction of the conceptual
An abstraction omits details. A conceptual class is an idea about real
Can you give us a better definition of a conceptual class and a realistic
Conceptual model -- formal picture of the concepts used in a domain or
business -- including the relationships between the concepts.
A model is realistic if it reflects reality rather than a computer systems.
Can you give a better example or rule for the Guideline of Attributes vs
Guidelines? The current guideline is "If we do not think of some conceptual
class X as a number or text in the real world, X is probably a conceptual
class, not an attribute."
Not really -- this is a very good rule. Thus things like
Airplane, Students, Faculty, Person, Widget, Shop, CellPhone,
Cat, Dog, Animal, ... are probably should be classes. Typical
attributes of a Student: age, gender, name, sid, major, program, ...
Typical Attributes of a Faculty: age, gender, SSN, name, rank, step,
What is the difference between a description class and a conceptual class?
The objects in a conceptual class tend to be concrete and obvious -- you trip over them if
you walk round the factory, as it were. Their descriptions (in the real world) are pieces
of paper or cards or even --in a data base.
Example: Go to JB359 and you will see a series of computers: jb359-01,
jb359-02, .... but they are all the same kind of computer. So if
we are maintaining an inventory of computers we would be wise to
have "Computer" as a conceptual class and a separate one describing the
type of computer: manufacturer=dell, memory=...., cpu=....., ...
- Lab (0..1)------(*)Computer (*)-------(1) ComputerDescription
As a result we save one copy of the description for 30 different computers.
If we delete all the computers in the lab ... we can still find the data to order
Now think about what happens if we upgrade the lab....
and the computers are put into a cluster in the graduate lab jb361...
THe descriptions stay the same.
Having the description is worth while.
In a Domain Model, if description classes are used to eloquently present and
describe classes, aren't associations redundant?
No. You have to connect the description to the object that it applies to. That
is what associations do. The connect a particular item on a shelf to a
description of that item, for example.
The author mentions a couple of mistakes with Attributes vs. Classes. What
are some other mistakes that are made that the author did not mention?
I know of a common mistake that people make with associations ...
showing a link that is the same as a chain of associations.
For example: in a genealogy program you will probably need the idea
"Grandfather" but you wouldn't show it if you already have "Father"
and "Parent" because a grandfather is the father of a parent, and
any father of a parent is a grandfather.
The definition of grandfather would go in the project glossary.
Using discrete math:
- grandfather::= father o parent.
Exercise: why don't you define
- grandfather::= father o father.
However sometimes you may need the extra association. For example,
in some cultures a boy has a special relationship with a paternal
uncle -- a brother of the boy's father. And at first sight you might
think that this means that we don't need a "paternalUncle". But this
is wrong when there is one designated "parentalUncle" among the many
possible brother's of the boy's father.
There is a way to record, in the UML, the constraint that "parentalUncle"
is one of many but we won't stress it in this class.
Can you please elaborate on how two classes can have multiple associations?
They can play different rolls to each other. For example -- A faculty
member can be the adviser of a Student and also teach that student.
A faculty member can be a member of a department and teach for
another (or the same) department -- so two distinct associations.
I once knew a teach whose daughter was in the same school -- two
associations: daughter----father and student----teacher.
should there be simpler domain models showing classes, then attributes and
links, multiple models? or just one big one.
You end up with one big one -- as long as it fits on a board/poster/piece
Teachers typically introduce one bit of the UML at a time.
For presentations however you often need to hide the details!
One reason for using a tool like DIA or Rose or Umbrello is because they
let you record the complications and display (and print)
just the details you need.
I can demo this in a lab or in my office...
One technique is to develop a complex diagram as a team on a board,
and then copy down the details into a
document, and the boxes, names and links into permanent paper document.
Again -- Analysis and Design is more than drawing diagrams -- diagrams
It seems like this chapter, we had a taste of in 372, one thing I remember
is the domain model. Will we need to do a more complete one for our
projects? Meaning... more detailed?
Yes -- Domain modeling (business modeling) is a part of systems analysis
and covered a bit in CS372. In your projects you will probably work
out a lot of detail -- but most models will be of the classes
inside the software. Business/Domain models are models of what is outside
Pages 139-141 discuss finding conceptual classes for "business information
system"s. How would you find conceptual classes for game programs?
You imagine the game running and think about the "things" that the player
thinks is on the screen/earphones.
For example in the "Mythica" game there are Gods, Heroes, Temples, Weapons,
The job of the software is to make these come alive for the player.
I was wondering if you could build a domain model for the Unreal World so I
could understand it better.
I'll try an do one in class... This note is to remind you that
in many domains some abstract things -- contracts, goals, plans,
etc. are very important.
It says that some software systems are for domains that find very little
analogy in natural business domains, and one example is software for
Can you give more examples?
This section of the book is about reminding you that some important objects
are not physical. An example would be a Bank Account or Certificate
of Deposit. These are very real to the owner and the bank but
you can't touch them or kick them.
All Games have to simulate a world that is more or less unreal.