Domain Model

Domain Model - Review

• What is a Domain Model?
– Most important OO analysis model
– It illustrates noteworthy concepts in a domain.
• How to create a Domain Model?
– Finding conceptual classes
• Category List
• Noun Phrase Identification
– Identifying associations
– Adding attributes
 Association
• An association is a relationship between classes
(more precisely, instances of those classes) that
indicates some meaningful and interesting connection

• UML Semantics define association as "the semantic

relationship between two or more classifiers that
involve connections among their instances."
 When to Show an Association?
• Associations among objects that are to be shown
usually imply knowledge of a relationship that needs
to be preserved for some duration
– between what objects do we need some memory of a
relationship?
• For example, do we need to remember what
SalesLineItem instances are associated with a Sale
instance?
– Definitely, otherwise it would not be possible to
reconstruct a sale, print a receipt, or calculate a sale total.
When to Show an Association? -
• Similarly we need to remember the following
relationships
– Students in a Class
– Employees in a Department
• Some relationships exist but are not required
to be remembered
– Cashier and the Product Description
 Domain Model – Analysis
Artifact
• Remember the domain model is an analysis
artifact and is a conceptual perspective
– the statements about the need to remember refer to
a need in a real situation of the world, not a
software need, although during implementation
many of the same needs will arise.
 Too many associations
• A domain model with 20 classes could have
190 associations lines!
• Many lines on the diagram will obscure it with
"visual noise"
• Only focus on the “need to remember”
associations
 Will the Associations Be
Implemented In Software?
• Not the aim during analysis phase
• Answer
– many of these relationships will be implemented in
software as paths of navigation and visibility (both
in the Design Model and Data Model).
• The domain model is not a data model;
associations are added to highlight our rough
understanding of noteworthy relationships, not
to document object or data structures
 UML Association Notation
• Association Notation
– An association is represented as a line between
classes
 Naming an Association
• Avoid using simple association names such as "Has"
or "Uses"
– They are usually poor, as they seldom enhance our
understanding of the domain
• Sale Paid-by CashPayment
– bad example (doesn't enhance meaning): Sale Uses
CashPayment
• Player Is-on Square
– bad example (doesn't enhance meaning): Player Has Square
 Naming an Association – cont’d
• Name an association based on a ClassName-
VerbPhrase-ClassName format where the verb phrase
creates a sequence that is readable and meaningful.
– Example: Register records-current Sale
• Association names should start with a capital letter,
since an association represents a classifier of links
between instances
– In the UML, classifiers should start with a capital letter.
• Two common and equally legal formats for a
compound association name are:
– Records-current
– RecordsCurrent
 Association Ends
• The end of an association where it connects to
a classifier
• Each Association End represents a role.
• Roles may optionally have:
– multiplicity expression
– name
– navigability
 Multiplicity
• Multiplicity defines how many instances of a class
A can be associated with one instance of a class B
• For example, a single instance of a Store can be
associated with "many" (zero or more, indicated by
the *) Item instances.
Multiplicity
Multiplicity – context dependant
• The multiplicity is dependent on the domain of
software we are developing
• The multiplicity value communicates a domain
constraint that will be (or could be) reflected in
software
Multiplicity – Context Dependant
 Multiple Associations
• Two classes may have multiple associations between
them in a UML class diagram; this is not uncommon.
• An example from the domain of the airline is the
relationships between a Flight and an Airport
• The flying-to and flying-from associations are
distinctly different relationships, which should be
shown separately.
 Finding Associations – Association
Category
List Examples
A is a transaction related to another transaction B CashPayment - Sale
Cancellation - Reservation
A is a line item of a transaction B SalesLineItem - Sale
A is a product or service for a transaction (or line Item - SalesLineItem /Sale
item) B Flight – Reservation
A is a role related to a transaction B Customer - Payment
Passenger - Ticket
A is a physical or logical part of B Drawer - Register
Square - Board
Seat – Airplane
A is physically or logically contained in/on B Register - Store, Item -
Shelf
Square - Board
Passenger – Airplane
A is a description for B ProductDescription – Item
FlightDescription – Flight
 Finding Associations – Association
List
Category Examples
A is known/logged/recorded/reported/captured in B Sale – Register
Piece – Square
Reservation – FlightManifest
A is a member of B Cashier – Store
Player – MonopolyGame
Pilot – Airline
A is an organizational subunit of B Department – Store
Maintenance – Airline
A uses or manages or owns B Cashier – Register
Player – Piece
Pilot – Airplane
A is next to B SalesLineItem -
SalesLineItem
Square - Square
City - City
Example Associations – NextGen POS
Example Association - Monopoly
 Attributes
• An attribute is a logical data value of an object.
• Include attributes that the requirements (for example,
use cases) suggest or imply a need to remember
information
• For example, a receipt (which reports the information
of a sale) in the Process Sale use case normally
includes a date and time, the store name and address,
and the cashier ID, among many other things.
• Therefore,
– Sale needs a dateTime attribute
– Store needs a name and address
– Cashier needs an ID
 Attribute Notation
• Attributes are shown in
the second compartment
of the class box
• Their type and other
information may
optionally be shown
 Suitable Attribute Types
• Most attribute types should be what are often
thought of as "primitive" data types, such as
numbers, booleans, enumerations, etc.
• The type of an attribute should not normally be
a complex domain concept, such as a Sale or
Airport.
• Relate conceptual classes with an association,
not with an attribute.
 Data Types
• Data Type is a UML term that implies a set of
values for which unique identity is not meant
– Two instances of Person with name “Ahmed”
– Two instances of Integer 5
• Represent what can be thought of as an integer
or String as attribute
• Data Type classes
– ItemIdentifier
 Data Type classes
• Represent what may initially be considered a number or
string as a new data type class in the domain model if:
– It is composed of separate sections.
• phone number, name of person
– There are operations associated with it, such as parsing or
validation.
• social security number
– It has other attributes.
• promotional price could have a start (effective) date and end date
– It is a quantity with a unit.
• payment amount has a unit of currency
– It is an abstraction of one or more types with some of these
qualities.
• item identifier in the sales domain is a generalization of types such as
Universal Product Code (UPC) and European Article Number (EAN)
 Attributes – Foreign keys
• No Attributes Representing Foreign Keys
Domain Model – NextGen POS
Domain Model – Monopoly
 Is the Domain Model Correct?
• There is no such thing as a single correct domain
model.
• All models are approximations of the domain we are
attempting to understand
• The domain model is primarily a tool of
understanding and communication among a particular
group
• A useful domain model captures the essential
abstractions and information required to understand
the domain in the context of the current requirements
• It aids people in understanding the domain, its
concepts, terminology, and relationships.
 Next Artifact..
• SSD
• Domain Model

Submission Deadline: 22nd October 2010.