Chapter 12

D OMAIN A NALYSIS
Domain Analysis, the next stage of development, is concerned
with devising a precise, concise, understandable, and correct
model of the real world.
Before building anything complex, the builder must
understand the requirements. Requirements can be stated in
words, but these are often imprecise and ambiguous.
During analysis, we build models and begin to understand the
requirements deeply.
To build a domain model, we must interview business experts,
examine requirements statements, and scrutinize related
artifacts.
We must analyze the implications of the requirements and
restate them rigorously. It is important to abstract important
features first and defer small details later.
The successful analysis model states what must be done,
without restricting how it is done, and avoids
implementation decisions.
The model serves several purposes:
It clarifies the requirements.
it provides a basis for agreement between the stakeholders
and the developers.
and it becomes the starting point for design and
implementation.
 OVERVIEW OF ANALYSIS
Analysis begins with a problem statement generated during
system conception.
The statement may be incomplete or informal; analysis makes
it more precise and exposes ambiguities and inconsistencies.
The problem statement should not be taken as immutable but
should serve as a basis for refining the real requirements.
Next, we must understand the real-world system described by
the problem statement, and abstract its essential features into a
model.
Statements in natural language are often ambiguous,
incomplete and inconsistent. The analysis model is a precise,
concise representation of the problem that permits answering
and building a solution.
Subsequent design steps refer to the analysis model, rather than
the original vague problem statement.
The process of constructing a rigorous model of the problem
domain forces the developer to confront misunderstanding
early in the development process while they are still easy to
correct.
The analysis model addresses the three aspects of objects:
static structure of objects(class model),
interactions among objects (interaction model) ,
and life cycle histories of objects (state model)
Almost all problems have useful class models derived from
real-world entities. Problems concerning reactive control and
timing, such as user interfaces and process control, have
important state models.
Problems containing significant computation as well as
systems that interact with other systems and different kinds of
users have important interaction models.
Analysis is not a mechanical process. The exact
representations involve judgment and in many regards are a
matter of art.
Most problem statements lack essential information, which
must be obtained from the requestor or from the analyst’s
knowledge of the real-world problem domain.
Also there is a choice in the level of abstraction for the model.
The analyst must communicate with the requestor to clarify
ambiguities and misconceptions.
The analysis models enable precise communication.
Analysis is divided into two sub stages:
The first domain analysis, focuses on understanding the
real-world essence of a problem
The second, application analysis, builds on the domain
model-incorporating major application artifacts that are seen
by users and must be approved by them.
 DOMAIN CLASS MODEL
The first step in analyzing the requirements is to construct a
domain model. The domain model shows the static structure of
the real-world system and organizes it into workable pieces.
The domain model describes real-world classes and their
relationships to each other.
During analysis, the class model precedes the state and
interaction models.
Information for the domain model comes from the problem
statement, artifacts from related systems, expert knowledge of
the application domain, and general knowledge of the real
world.
Make sure you consider all information that is available and do
not rely on single source.
Find classes and associations first, as they provide the overall
structure and approach to the problem. Next add attributes to
describe the basic network of classes and associations.
Then combine and organize classes using inheritance. Attempts
to specify inheritance directly without first understanding
classes and their attributes can distort the class structure to
match preconceived notions.
Operations are usually unimportant in a domain model. The
main purpose of a domain model is to capture the information
content of a domain.
It is best to get ideas down on paper before trying to organize
them too much, even though they may be redundant and
inconsistent, so as not to lose important details.
 An initial analysis model is likely to contain flaws that must
be corrected by later iterations. The entire model need not be
constructed uniformly.
Some aspects of the problem can be analyzed in depth
through several iterations while other aspects are still
sketchy.
We must perform the following steps to construct a domain
class model:
❑ Find classes.
❑ Prepare a data dictionary.
❑ Find associations.
❑ Find attributes of objects and links.
❑ Organize and simplify classes using inheritance.
Verify that access paths exist for likely queries.
Iterate and refine the model.
Reconsider the level of abstraction.
Group classes into packages.
Finding Classes
The first step in constructing a class model is to find relevant
classes for objects from application domain.
Objects include physical entities, such as houses, persons, and
machines, as well as concepts, such as trajectories, seating
arrangements, and payment schedules.
All classes must make sense in the application domain, avoid
computer implementation constructs, such as linked lists and
subroutines.
Not all classes are explicit in the problem statement; some are
implicit in the application domain or general knowledge.

As shown in the figure, begin by listing candidate classes found

in the written description of the problem.
Don’t be too selective; write down every class that comes to
mind. Classes often corresponds to nouns.
For Ex: in the statement “a reservation system to sell tickets to
performance at various theatres” tentative classes would be
Reservation, System, Ticket, Performance, and Theatre.
Don’t operate blindly, however. The idea to is capture concepts;
not all nouns are concepts, and concepts are also expressed in
other parts of speech.
Don’t worry much about inheritance or high-level classes; first
get specified classes right so that you don’t subconsciously
suppress detail in an attempt to fit a preconceived structure.
For Ex: if you are building a cataloging and checkout system
for a library, identify different kinds of materials, such as books,
magazines, newspapers, records, videos, and so on.
We can organize them into broad categories later, by looking for
similarities and differences.
ATM example: Examination of the concepts in the ATM
problem statement. Fig shows additional classes that do not
appear directly in the statement but can be identified from our
knowledge of the problem domain.
❑ Keeping the right classes
Discard unnecessary and incorrect classes according to the
following criteria.
Redundant classes: If two classes express the same concept, we
should keep the most descriptive name. For Ex: although
Customer might describes a person taking an airline flight,
Passenger is more descriptive.
On the other hand, if the problem concerns contracts for a charter
airline, Customer is also an appropriate word, since a contract
might involve several passengers.
ATM Example: Customer and User are redundant; we retain
Customer because it is more descriptive.
Irrelevant classes: If a class has little or nothing to do with the
problem, eliminate it. This involves judgment, because in another
context the class could be important.
For Ex: in a theatre ticket reservation system, the occupations of
the ticket holders are irrelevant, but the occupations of the theatre
personal may be important.
ATM Ex: Apportioning Cost is outside the scope of the ATM
software.
Vague Classes: A class should be specific. Some tentative
classes may have ill-defined boundaries or be too broad in
scope.
ATM Ex: RecordkeepingProvision is vague and is handled by
Transaction. In other applications, this might be included in
other classes, such as StockSales,TelephoneCalls, or
MachineFailures.
Attributes: Names that primarily describe individual objects
should be restated as attributes. For Ex: name, birthdate, and
weight are usually attributes.
If the independent existence of a property is important, then
make it a class and not an attribute.
For Ex: an employee’s office would be a class in an
application to reassign offices after a reorganization.
ATM Ex: AccountData is underspecified but in any case
probably describes an account. An ATM dispenses cash and
receipts, but beyond that cash and receipts are peripheral to
the problem, so they should be treated as attributes.
Operations: If a name describes an operation that is applied
to objects and not manipulated in its own right, then it is not a
class.
For Ex: a telephone call is a sequence of actions involving a
caller and the telephone network. If we are simply building
telephones, then call is part of the state model and not a class.
An operation that has features of its own should be modeled
as a class, however, For Ex: in a billing system for telephone
calls a Call would be an important class with attributes such
as date, time, origin, and destination.
Roles: The name of a class should reflect its intrinsic nature
and not a role that it plays in an association. For Ex: Owner
would be a poor name for a class in a car manufacturer’s
database.
What if a list of drivers is added later? What about persons who
lease cars? The proper class is Person, which assumes various
different roles, such as owner, driver, and lessee.
One physical entity sometimes corresponds to several classes.
For Ex: Person and Employee may be distinct classes in some
circumstances and redundant in others,
In company database of employees, the two may be identical.
In a government tax database, a person may hold more than
one job, so it is important to distinguish Person from
Employee; each person can correspond to zero or more
instances of employee information.
Implementation constructs: Eliminate constructs from the
analysis model that are extraneous to the real world. We may
need them later during design.
For Ex: CPU, subroutine, process, algorithm, and interrupt
are implementations constructs for most applications,
although they are legitimate classes for an operating system.
Data structures, such as linked lists, trees, arrays, and tables,
are almost always implementation constructs.
ATM Ex: Some tentative classes are really implementation
constructs. TransactionLog is simply the set of transcations;
its exact representation is a design issue.
Communication links can be shown as associations;
CommunicationLine is simply the physical implementation of
such a link.
Derived Classes : As a general rule, omit classes that can be
derived from other classes. If a derived class is especially
important, we can include it, but do so only sparingly. Mark
all derived classes with a preceding slash(‘/’) in the class
name.
Preparing a data Dictionary
Isolated words have too many interpretations, so prepare a
data dictionary for all modeling elements. Write a paragraph
precisely describing each class.
Describe the scope of the class within the current problem,
including any assumptions or restrictions on its use. The data
dictionary also describes associations, attributes, operations,
and enumeration values.
Fig below shows a data dictionary for the classes in the ATM
problem
❑ Finding Associations
Next step is to find association between classes. A structural
relationship between two or more classes is an association. A
reference from one class to another is an association.
Attributes should not refer to classes; use an association
instead. For Ex: class Person should not have an attribute
employer; relate class Person and class Company with
association WorksFor.
Associations show relationships between classes at the same
level of abstraction as the classes themselves, while
object-valued attributes hide dependencies and obscure their
two-way nature.
Associations can be implemented in various ways, but such
implementation decisions should be kept out of the analysis
model to preserve design freedom.
Associations often correspond to stative verbs or verb
phrases. These include physical location(NextTo, part of,
ContainedIn), directed actions(Drives), communication
(TalksTo), ownership(Has, part of), or satisfaction of some
condition (WorksFor, MarriedTo, Manages).
Extract all the candidates from the problem statement and get
them down on paper first; don’t try to refine things too early.
Again, don’t treat grammatical forms blindly; the idea is to
capture relationships, however they are expressed in natural
language.
ATM Ex: Fig below shows associations. The majority are
taken directly from verb phrases in the problem statement.
For some associations the verb phrase is implicit in the
statement.
Finally, some associations depend on real-world knowledge
or assumptions. These must be verified with the requestor, as
they are not in the problem statement.
❑ Keeping the Right Associations
Associations between eliminated classes: If we have eliminated
one of the classes in the association, we must eliminate the
association or restate it in terms of other classes.
ATM Ex: We can eliminate Banking network includes cashier
stations and ATM’s, ATM dispenses cash, ATM prints receipts,
Banks provide software, Cost apportioned to banks, System
provides recordkeeping, and System provides security.
Irrelevant or implementation associations: Eliminate any
associations that are outside the problem domain or deal with
implementation constructs.
ATM Ex: For Ex: System handles concurrent access is an
implementation concept. Real-world objects are inherently
concurrent; it is the implementation of the access algorithm that
must be concurrent.
Actions: An association should describe structural property of
the application domain, not a transient event.
Sometimes, a requirement expressed as an action implies an
underlying structural relationship and we should rephrase it
accordingly.
ATM Ex: ATM accepts cash card describes part of the
interaction cycle between an ATM and a customer, not a
permanent relationship between ATMs and cash cards.
We can also eliminate ATM interacts with user. Central
computer clears transaction with bank describes an action that
implies structural relationship Central computer communicates
with bank.
Ternary associations: We can decompose most associations
among three or more classes into binary associations or phrase
them as qualified associations.
If a term in a ternary association is purely descriptive and has
no identity of its own, then the term is an attribute on a binary
association.
Association Company pays salary to person can be rephrased
as binary association Company employs person with a salary
value for each Company-Person link.
Professor teaches course in room cannot be decomposed
without losing information.
ATM Ex: Bank computer processes transaction against
account can be broken into Bank computer processes
transaction and Transaction concerns account.
Cashier enters transaction for account can be broken
similarly. ATMs communicate with central computer about
transaction is really the binary associations ATMs
communicate with central computer and Transaction entered
on ATM.
o Derived Associations: Omit associations can be defined in
terms of other associations, because they are redundant. For Ex:
GrandparentOf can be defined in terms of a pair of ParentOf
associations.
Also omit associations defined by conditions on attributes. For
Ex, youngerThan expresses a condition on the birth dates of two
persons, not additional information.
As much as possible, classes, attributes, and associations in the
class model should represent independent information.
Multiple paths between classes sometimes indicate derived
associations that are compositions of primitive associations.
Consortium owns central computer and Central computer
communicates with ATMs.
Be careful, because not all associations that form multiple paths
between classes indicate redundancy.
Sometimes the existence of an association can be derived from
two or more primitive associations and the multiplicity can not.
Keep the extra association if the additional multiplicity
constraint is important.
For Ex: in figure below a company employs many persons and
owns many computers. Each employee is assigned zero or more
computers for the employee’s personal use; some computers are
for public use and are not assigned to anyone.
The multiplicity of the AssignedTo association can not be
deduced from the Employs and Owns associations.
Misnamed Associations: Don’t say how or why a situation
came about, say what it is. Names are important to
understanding and should be chosen with great care.
ATM Ex: Bank computer maintains accounts is a statement of
actions, rephrase as Bank holds account.
Association end names: Add association end names where
appropriate. For Ex: in the WorksFor association a company is
an employer with respect to a Person and a Person is an
employee with respect to Company.
If there is only one association between a pair of classes and the
meaning of the association is clear, we may omit association end
names.
For Ex: the meaning of ATMs communicate with central
computer is clear from the class names.
An association between two instances of the same class requires
association end names to distinguish the instances. For Ex: the
association Person manages person would have the end names
boss and worker.
Qualified Association: Usually a name identifies an object
within some context; most names are not globally unique. The
context combines with the name to uniquely identify the object.
For Ex: the name of a company must be unique within the
chartering state but may be duplicated in other states. The name
of a company qualifies the association State charters company;
State and Company name uniquely identify Company. AA
qualifier distinguishes objects on the “many” side of an
association.
ATM Ex: The qualifier bankCode distinguishes the different
banks in a consortium. Each cash card needs a bank code so
that transactions can be directed to the appropriate bank.
Multiplicity: Specify multiplicity, but don’t put too much
effort into getting it right, as multiplicity often changes during
analysis.
Challenge multiplicity values of “one”. For example, the
association one Manager manages many employees precludes
matrix management or an employee with divided
responsibilities.
For multiplicity values of “many” consider whether a qualifier
is needed, also ask if the objects need to be ordered in some
way.
❑ Missing Associations: Add any missing associations that are
discovered.
ATM Ex: We overlooked Transaction entered on cashier station,
Customers have accounts, and Transaction authorized by cash
card. If cashiers are restricted to specific stations, then the
association Cashier authorized on cashier station would be
needed .
Aggregation: Aggregation is important for certain kinds of
applications, especially involving mechanical parts and bills of
material.
For other applications aggregation is relatively minor and it can
be unclear whether to use aggregation or ordinary association.
Aggregation is just an association with extra connotations.
Use whichever seems more natural at the time and move on.
ATM Ex: We decide that a Bank is part of a Consortium and
indicate the relationship with aggregation.
ATM Ex: Fig below shows a class diagram with the remaining
associations. We have split Transaction into RemoteTransaction
and CashierTransaction to accommodate different associations.
❑ Finding Attributes
Attributes are data properties of individual objects, such as
weight, velocity, or color.
Attribute values should not be objects; use an association to
show any relationship between two objects.
Attribute usually correspond to nouns followed by possessive
phrases, such as “the color of the car” or “the position of the
cursor”. Adjectives often represent specific enumerated
attribute values, such as red, on, or expired.
Unlike classes and associations, attributes are less likely to be
fully described in the problem statement. We must draw on
your knowledge of the application domain and the real world to
find them.
We can also find attributes in the artifacts of related systems.
Fortunately, attributes affect the basic structure of the problem.
Do not carry discovery of attributes to excess. Only consider
attributes directly relevant to the application. Get the most
important attributes first; we can add fine details later.
During analysis, avoid attributes that are solely for
implementation. Be sure to give each attribute a meaningful
name.
Normally, we should omit derived attributes. For example, age
is derived from birthdate and currentTime. Do not express
derived attributes as operations, such as getAge, although we
may eventually implement them that way.
Look for the attributes on associations. Such an attribute is a
property of the link between two objects, rather than being a
property of an individual object.
For Ex: the many-to-many association between Stockholder
and Company has an attribute of numberOfShares.
❑ Keeping the right attributes
Eliminate unnecessary and incorrect attributes with the
following criteria
Objects: If the independent existence of an element is
important, rather than just its value, then it is an object.
For Ex: boss, refers to a class and salary is an attribute. The
distinction often depends on the application.
For Ex: in a mailing list city might be considered as an attribute,
while in a census City would be a class with many attributes and
relationships of its own. An element that has features of its own
within the given application is a class.
Qualifiers: If the value of an attribute depends on a particular
context, then consider restating the attribute as a qualifier. For
Ex: employeeNumber is not a unique property of a person with
two jobs; it qualifies the association Company employs person.
Names: Names are often better modeled as qualifiers rather
than attributes. Test: Does the name select unique objects from a
set? Can an object in the set have more than one name?
If so, the name qualifies a qualified association. If a name
appears to be unique in the world, we may have missed the
class that is being qualified.
For Ex: department-Name may be unique within a company, but
eventually the program may need to deal with more than one
company. It is better to use a qualified association immediately.
A name is an attribute when its use does not depend on context,
especially when it need not be unique within some set.
Name of persons, unlike names of companies, may be
duplicated and are therefore attributes.
Identifiers: OO languages incorporate the notion of an object
identifier for unambiguously referencing an object. Do not
include an attribute whose only purpose is to identify an object,
as object identifiers are implicit in class models.
Only list attributes that exist in the application domain. For Ex:
accountCodes and customers see them.
In contrast, we should not list an internal transactionID as an
attribute, although it may be convenient to generate one during
implementation.
Attributes on associations: If a value requires the presence of a
link, then the property is an attribute of the association and not
of a related class.
Attributes are usually obvious on many-to-many associations;
they cannot be attached to either class because of their
multiplicity.
For Ex, in an association between Person and Club the attributes
membershipDate belongs to the association, because a person
can belong to many clubs and a club can have many members.
Attributes are more subtle on one-to-many association because
they could be attached to the “many” class without losing
information.
Resist the urge to attach them to classes, as they would be
invalid if multiplicity changed. Attributes are also subtle on
one-to-one associations.
Internal values: If an attribute describes the internal state of an
object that is invisible outside the object, then eliminate it from
the analysis.
Fine detail: Omit minor attributes that are unlikely to affect
most operations.
Discordant attributes: An attribute that seems completely
different from and unrelated to all class should be simple and
coherent.
Mixing together distinct classes is one of the major causes of
troublesome models. Unfocused classes frequently result from
premature consideration of implementation decisions during
analysis.
Boolean attributes: Reconsider all Boolean attributes. Once we
can broaden a boolean attribute and restate it as an enumeration.
ATM Ex: We apply these criteria to obtain attributes for each
class. Some tentative attributes are actually qualifiers on
associations. We consider several aspects of the model:
BankCode and CardCode are present on the card. Their format
is an implementation detail, but we must add a new association
Bank issues CashCard. CardCode is a qualifier on this
association; bankCode is the qualifier of Bank with respect to
Consortium.
The computers do not have state relevant to this problem.
Whether the machine is up or down is a transient attribute that
is part of implementation.
Avoid the temptation to omit Consortium, even though it is
currently unique. It provides the context for the bankCode
qualifier and may be useful for future expansion.
❑ Refining with Inheritance
The next step is to organize classes by using inheritance to share
common structure.
Inheritance can be added in two directions: by generalizing
common aspects of existing classes into a superclass (bottom
up)or by specializing existing classes into multiple
subclasses(top down).
Bottom-up generalization: We can discover inheritance from
the bottom up by searching for classes with similar attributes,
associations, and operations. For each generalization, define a
superclass to share common features.
We may have to slightly redefine some attributes or classes to
fit in.
ATM Ex: RemoteTransaction and CashierTransaction are
similar, except in their initiation, and can be generalized by
Transaction. CentralComputer and BankComputer have little in
common for purposes of the ATM example.
Top-down specialization: Top-down specializations are often
apparent from the application domain. Look for noun phrases
composed of various adjectives on the class name: fluorescent
lamp, incandescent lamp; fixed menu, pop-up menu, sliding
menu.
Avoid excessive refinement. If proposed specializations are
incompatible with an existing class, the existing class may be
improperly formulated.
Generalization vs. enumeration : Enumerated subcases in the
application domain are the most frequent source of
specializations.
It is sufficient to note that a set of enumerated subcases exists,
without actually listing them.
For Ex: an ATM account could be refined into CheckingAccount
and SavingsAccount. It is useful in some bankking applications;
type can be made a simple attribute of Account.
Multiple Inheritance: We can use multiple inheritance to
increase sharing, but only if necessary, because it increases both
conceptual and implementation complexity.
Similar associations: When the same association name appears
more than once with substantially the same meaning, try to
generalize the associated class.
ATM Ex: Transaction is entered on both CashierStation and
ATM; EntryStation generalizes CashierStation and ATM.
Adjusting the inheritance level: We must assign attributes and
associations to specific classes in the class hierarchy. Assign each
one to the most general class for which it is appropriate
❑ Testing Access Paths
Trace access paths through the class model to see if they yield
sensible results.
Where a unique value is expected, is there a path yielding a
unique result? For multiplicity “many” is there a way to pick
out unique values when needed?
Think of the questions we might like to ask. Are there useful
questions that cannot be answered? They indicate missing
information.
If something that seems simple in the real world appears
complex in the model, we may have missed something. It can
be acceptable to have classes that are “disconnected” from other
classes.
This usually occurs when the relationship between a
disconnected class and the remainder of the model is diffuse.
Check disconnected classes to make sure you have not
overlooked any associations.
ATM Ex: A cash card itself does not uniquely identify an
account, so the user must choose an account somehow. If the
user supplies an account type, each card can access at most
one savings and one checking account.
This is probably reasonable, and many cash cards actually
work this way, but it limits the system. The alternative is to
require customers to remember account numbers.
If a cash card accesses a single account, then transfers between
accounts are impossible. We have assumed that the ATM
network serves a single consortium of banks.
Real cash machines today often overlapping networks of banks
and accept credit cards as well as cash cards. The model would
have to be extended to handle that situation. We will assume
that the customer is satisfied with this limitation on the system.
❑ Iterating a Class Model
A class model is rarely correct after a single pass. The entire
software development process is one continual iteration;
different parts of a model are often at different stages of
completion.
If we find a deficiency, go back to an earlier stage if necessary to
correct it. Some refinements can come only after completing the
state and interaction models.
There are some signs of missing classes.
Asymmetries in associations and generalizations: Add new
classes by analogy.
Disparate attributes and operations on a class: Split a class so
that each part is coherent.
Difficulty in generalizing cleanly: One class may be playing
two roles. Split it up and one part may then fit in cleanly.
Duplicate associations with the same name and purpose:
Generalize to create the missing super class that unites them.
A role that substantially shapes the semantics of a class:
May be it should be a separate class. This often means
converting an associations into a class.
For Ex: a person can be employed by several companies with
different conditions of employment at each; Employee is then a
class denoting a person working for a particular company, in
addition to class Person and Company.
Also look out for missing associations.
Missing access paths for operations: Add new associations so
that we can answer queries.
Another concern is superfluous model elements.
Lack of attributes, operations, and associations on a class:
Why is the class needed? Avoid inventing subclasses merely to
indicate an enumeration. If proposed subclasses are otherwise
identical, mark the distinction using an attribute.
Redundant information: Remove associations that do not add
new information or mark them as derived.
And finally we may adjust the placement of attributes and
associations.
Associations end names that are too narrow for their
classes: Move the association up or down in the class hierarchy.
Need to access an object by one of its attribute values:
Consider a qualified association. In practice, model building is
not as rigidly ordered as it is shown. We can combine several
steps, once we are experienced.
ATM Ex: CashCard really has a split personality- it is both an
authorization unit within the a bank allowing access to the
customer’s accounts and also a piece of plastic data that the
ATM reads to obtain coded IDs.
In this case, the codes are actually part of the real world, not just
computer artifacts; the codes, not the cash card, are
communicated to the central computer.
We should split cash card into two classes:
CashAuthorization, an access to one or more customer accounts.
CashCard, a piece of plastic that contains a bank code and a
cash card number meaningful to the bank. Each card
authorization identifies one or more accounts- for example, one
checking account and one savings account.
Transaction is not general enough to permit transfers between
accounts because it concerns only a single account.
In general, a Transaction consists of one or more updates on
individual account. All updates in a single transaction must be
processed together as an atomic unit; if any one fails, then they
all are canceled.
The distinction between Bank and BankComputer and between
Consortium and CentralComputer doesn’t seem to affect the
analysis. The fact that communications are processed by
computers is actually an implementation artifact.
Merge BankComputer and CentralComputer into Consortium.
Customer doesn’t seem to enter into the analysis so far.
However, when we consider operations to open new accounts, it
may be an important concept.
Figure below shows a revised class diagram that is simpler and
cleaner.
❑ Shifting the Level of Abstraction
We have taken the problem statement quite literally. We have
regarded nouns and verbs in the problem description as direct
analogs of classes and associations.
This is a good way to begin analysis, but it does not always
suffice. Sometimes we must raise the level of abstraction to
solve a problem.
We should be doing this throughout as we build a model, but we
put in an explicit step to make sure we do not overlook
abstraction.
For Ex: we encountered one application in which the developers
had separate classes for IndividualContributors, Supervisor, and
Managers. This model certainly is correct, but it suffers from
some problems.
There is much commonality between the three classes- the only
difference is the reporting hierarchy. For Ex: they all have
phone numbers and addresses.
We could handle the commonality with a superclass, but that
only makes the model larger. An additional problem arose when
we talked to the developers and they said they wanted to add
another class for the persons to whom managers reported.
Fig below shows the original model and an improved model
that is more abstract. Instead of “hard coding” the management
hierarchy in the model, we can “soft code” it with an
association between boss and worker.
A person who has an employeeType of “individualContributor”
is a worker who reports to another person with an
employeeType of “Supervisor” .
Similarly, a person who is a supervisor reports to a person who
is a manager.
In the improved model a worker has an optional boss, because
the reporting hierarchy eventually stops. The improved model is
smaller and more flexible.
An additional reporting level does not change the model’s
structure; it merely alters the data that is stored.
One way that we can take advantage of abstraction is thinking
in terms of patterns. Different kinds of patterns apply to the
different development stages, but here we are interested in
patterns for analysis.
A pattern distills the knowledge of experts and provides a
proven solution to a general problem. For Ex: the right side of
figure is a pattern for modeling a management hierarchy.
The use of tried and tested patterns gives us the confidence of a
sound approach and boosts our productivity in building models.
ATM Ex: We have already included some abstractions in the
ATM model. We distinguished between a CashCard and a
CardAuthorization.
We included the notation of transactions rather than trying to
list each possible kind of interaction.
❑ Grouping Classes into Packages
The last step of class modeling is to group classes into
packages. A Package is a group of elements ( classes,
associations, generalizations, and lesser packages) with a
common theme.
Packages organize a model for convenience in drawing,
printing, and viewing. Furthermore, when we place classes and
associations in a package, we are making a semantic statement.
Generally speaking, classes in the same package are more
closely related than classes in different packages. Normally, we
should restrict each association to a single package, but we can
repeat some classes in different packages.
To assign classes to packages, look for cut points- a cut point is
a class that is the sole connection between two otherwise
disconnected parts of a model. Such a class forms a bridge
between two packages.
For Ex: in a file management system, a File is he cut point
between the directory structure and the file contents. Try to
choose packages to reduce the number of crossovers in the class
diagrams.
With a little care, we can draw most class diagrams as planar
graphs, without crossing lines.
Reuse a package from a previous design if possible, but avoid
forcing a fit. Reuse is easiest when part of the problem domain
matches a previous problem.
If the new problem is similar to a previous problem but
different, we may have to extend the original model to
encompass both problems.
Use your judgment about whether this is better than building a
new model.
ATM Ex: The current model is small and would not require
breakdown into packages, but it could serve as a core for a more
detailed model. The packages might be:
Tellers- cashier, entry station, cashier station, ATM
Accounts- account, cash card, card authorization, customer,
transaction, update, cashier transaction, remote transaction
Banks- consortium, bank
Each package could add details. The account package could
contain varieties of transactions, information about customers,
interest payments, and fees.
The bank package could contain information about branches,
addresses, and cost allocations.
 DOMAIN STATE MODEL
Some domain objects pass through qualitatively distinct states
during their lifetime.
It is useful to construct a state diagram of such a domain class.
The state diagram describes the various states the object can
assume, the properties and constraints of the object in various
states and the events that take an object from one state to
another.
Most domain classes do not require state diagrams and can be
adequately described by a list of operations. For the minority of
classes that do exhibit distinct states, a state model can help
understanding their behavior.
First identify the domain classes with significant states and note
the states of each class. Then determine the events that take an
object from one state to another.
Given the states and the events, we can build state diagrams for
the affected objects. Finally evaluate the state diagrams to make
sure they are complete and correct.
The following steps are performed in constructing a domain
state model
Identify domain classes with states
Find states
Find events
Build state diagrams
Evaluate state diagrams
❑ Identifying classes with States
Examine the list of domain classes for those that have a distinct
life cycle. Look for classes that can be characterized by a
progressive history or that exhibit cyclic behavior.
Identify the significant states in the life cycle of an object. For
Ex: a scientific paper for a journal goes from Being written to
Under consideration to Accepted or Rejected.
There can be some cycles, for example, if the reviewers ask for
revisions, but basically the life of this object is progressive.
On the other hand, an airplane owned by an airline cycles
through the states of Maintenance, Loading, Flying, and
Unloading.
Not every state occurs in every cycle, and there are probably
other states, but the life of this object is cyclic.
 There are also classes whose life cycle is choatic, but most
classes with states are either progressive or cyclic.
ATM Ex: Account is an important business concept, and the
appropriate behavior for an ATM depends on the state of an
Account.
The life cycle for Account is a mix of progressive and cycling to
and from problem states. No other ATM classes have a
significant domain state model.
❑ Finding States
List the state for each class. Characterize the objects in each
class-the attribute values that an object may have, the
associations that it may participate in and their multiplicities,
attributes and associations that are meaningful only in certain
states.
Give each state a meaningful name. Avoid names that indicate
how the state came about; try to directly describe the state.
Don’t focus on fine distinctions among states, particularly
quantitative differences, such as small, medium, or large. States
should be based on quantitative differences in behavior,
attributes, or associations.
It is unnecessary to determine all the states before examining
events. By looking at events and considering transitions among
states, missing states will become clear.
ATM Ex: Here are some states for an Account: Normal, Closed,
Overdrawn, Suspended
❑ Finding Events
Once you have a preliminary set of states, find the events that
cause transitions among states. Think of the stimuli that cause a
state to change.
In many cases, you can regard an event as completing a
do-activity. For Ex, if a technical paper is in the state Under
consideration, then the state terminates when a decision on the
paper is reached.
In this case, the decision can be positive(Accept paper) or
negative(Reject paper). In cases of completing a do-activity,
other possibilities are often possible and may be added in the
future- for ex, Conditionally accept with revisions.
WE can find other events by thinking about taking the object
into a specific state.
For Ex, if you lift the receiver on a telephone, it enters the
Dialing state. Many telephones have pushbuttons that invoke
specific functions.
If you press the redial button, the phone transmits the number
and enters the Calling state. If you press the program button, it
enters the Programming state.
There are additional events that occur within a state an ddo not
cause a transition. For the domain state model you should focus
on events that cause transitions among states.
When you consider an event, capture any information that it
conveys as a list of parameters.
ATM Ex: Important events include: close account, withdraw
excess funds, repeated incorrect PIN, suspected fraud, and
administrative action.
❑ Building State Diagrams
Note the states to which each event applies. Add transitions to
show the change in state caused by the occurrences of an event
when an object is in a particular state.
If an event terminates a state, it will usually have a single
transition from that state to another state. If an event initiates a
target state, then consider where it can occur, and add
transitions from those states to the target state.
Consider the possibility of using a transition on an enclosing
state rather than adding a transition from each substate to the
target state. If an event has different effects in different states,
add a transition for each state.
Once you have specified the transitions, consider the meaning
of an event in states for which there is no transition on the
event.
Is it ignored? Then everything is fine. Does it represent an
error? Then add a transition to an error state. Does it have some
effect that you forgot? Then add another transition. Sometimes
you will discover new states.
It is usually not important to consider effects when building a
state diagram for a domain class. If the objects in the class
perform activities on transitions, however, add them to the state
diagram.
ATM Ex: Fig below shows the domain state model for the
Account class.
❑ Evaluating State Diagrams
Examine each state model. Are all states connected? Pay
particular attention to paths through it. If it represents a
progressive class, is there a path from the initial state to the
final state? Are the expected variations present?
If it represents a cyclic class, is the main loop present? Are there
any dead states that terminate the cycle?
Use the knowledge of the domain to look for missing paths.
Sometimes missing paths indicate missing states. When a state
model is complete, it should accurately represent the life cycle
of the class.
ATM Ex: Our state model for Account is simplistic but we are
satisfied with it, We would require substantial banking
knowledge to construct a deeper model.
 DOMAIN INTERACTION MODEL
Iterating the Analysis
The iteration to the analysis should be done as follows:
❑ Refining the Analysis Model
⚫ The overall analysis model may show inconsistencies and
imbalances within and across models. Iterate the different
portions to produce a cleaner, more coherent model.
⚫ Try to refine classes to increase sharing and improve
structure. Sometimes more restructuring is needed as your
understanding increases.
⚫ Watch out for generalizations factored on the wrong concepts.
Remove classes and associations that seemed useful at first
but now appear extraneous.
⚫ A good model feels right and does not appear to have
extraneous detail.
❑ Restating the Requirements
When the analysis is complete, the model serves as the basis for
the requirements and defines the scope of future discourse. Most
of the real requirements will be part of the model.
You should verify the final model with the requestor. During
analysis some requirements may appear to be incorrect or
impractical; confirm corrections to the requirements.
The final verified analysis model serves as the basis for system
architecture, design, and implementation.
You should revise the original problem statement to incorporate
corrections and understanding during analysis.
❑ Analysis and Design
The goal of analysis is to specify the problem fully without
introducing a bias to any particular implementation, but it is
possible to avoid all taints of implementation.
There is no absolute line between the various development
stages, nor is there any such thing as a perfect analysis.
Don’t treat the rules very rigidly. The purpose of rules is to
preserve flexibility and permit changes later, but remember that
the goal of modeling is to accomplish the total job, and
flexibility.
ATM Ex: We have no further changes to the ATM model at this
time. A true application is more likely to incur revision.