View
214
Download
0
Embed Size (px)
Citation preview
Copyright ©2004 Cezary Z Janikow 1
Domain Model
Visualization of entities and relationships In UP presented as Class Diagrams
– Classes, Relationships, Attributes in the domain
Important analysis artifacts– Driven by use case
– Stipulates initial design ideas in contracts
– Stipulates final design in Interactions
– Provides visual dictionary
Moves through different perspectives– Conceptual: from use case
– Design: from Interactions
– Implementation: implementation details
Copyright ©2004 Cezary Z Janikow 2
Domain Model: when
Start in Inception
Most efforts to detail in Elaboration
Copyright ©2004 Cezary Z Janikow 3
Domain Model
Process Sale
1. Customer arrives ...2. ...3. Cashier enters item identifier.4....
Use Case Text
Operation: enterItem(…)
Post-conditions:- . . .
Operation Contracts
Sale
date. . .
SalesLineItem
quantity
1..*1 . . .
. . .
the domain objects, attributes, and associations that undergo state changes
Domain Model
Use-Case Model
Design Model
: Register
enterItem(itemID, quantity)
: ProductCatalog
spec = getProductSpec( itemID )
addLineItem( spec, quantity )
: Sale
. . .
conceptual classes in the domain inspire the names of some software classes in the design
conceptual classes –terms, concepts attributes, associations
Cashier: …Item ID: …...
Glossary
elaboration of some terms in the domain model
Require-ments
Business Modeling
Design
Sample UP Artifact Relationships
Copyright ©2004 Cezary Z Janikow 4
Domain Model: partial POS example (conceptual)
Register
Item
Store
addressname
Sale
date time
Payment
amount
SalesLineItem
quantity
Stocked-in
*
Houses
1..*
Contained-in
1..*
Records-sale-of
0..1
Paid-by
1
1
1
1
1
1
0..1
1
Captured-on
conceptor domain object
association
attributes
Copyright ©2004 Cezary Z Janikow 5
Class Diagram
Static view of the domain
Presents domain conceptual classes
And not proposed implementation or design classes
Sale
dateTime
visualization of a real-world concept in the domain of interest
it is a not a picture of a software class
SalesDatabase software artifact; not partof domain modelavoid
software class; not partof domain model
Sale
datetime
print()
avoid
Copyright ©2004 Cezary Z Janikow 6
Conceptual Class
Symbol
Intension: definition
Extension: set of elements
Sale
datetime
concept's symbol
"A sale represents the eventof a purchase transaction. Ithas a date and time."
concept's intension
sale-1
sale-3sale-2
sale-4
concept's extension
Copyright ©2004 Cezary Z Janikow 7
Domain Model vs. Design Model
Same names and notation lower the representation gap
Payment
amount
Sale
datetime
Pays-for
Payment
amount: Money
getBalance(): Money
Sale
date: DatestartTime: Time
getTotal(): Money. . .
Pays-for
UP Domain ModelStakeholder's view of the noteworthy concepts in the domain.
UP Design ModelThe object-oriented developer has taken inspiration from the real world domainin creating software classes.
Therefore, the representational gap between how stakeholders conceive thedomain, and its representation in software, has been lowered.
1 1
1 1
A Payment in the Domain Modelis a concept, but a Payment inthe Design Model is a softwareclass. They are not the samething, but the former inspired thenaming and definition of thelatter.
This reduces the representationalgap.
This is one of the big ideas inobject technology.
inspiresobjects
andnames in
Copyright ©2004 Cezary Z Janikow 8
Domain Model vs. Data Model?
Domain Model
– Concepts, entities, can be abstract
– Relations
– Attributes
Data Model
– How data is stored into persistent storage
– Pure data, in files or databases
Copyright ©2004 Cezary Z Janikow 9
Domain Model: how to create?
1. Find conceptual classes
– Refine existing model and/or use patterns
– Explore concepts in the Category List
See Table 9.1
– Explore Noun Phrases
Lexical/linguistic analysis of use cases and other text documents
See pate 142
2. Add associations
3. Add attributes
Copyright ©2004 Cezary Z Janikow 10
Conceptual classes in POS
StoreRegister SaleItem
CashPayment
SalesLineItem
Cashier Customer
ProductCatalog
ProductDescription
Ledger
Class or Attribute?
– Use the 3 object properties to test
– Remember design will change things if needed
Copyright ©2004 Cezary Z Janikow 11
Description Classes
Class that describes something else
– Example:
Item object represents physical object
Description of the object is separate
In the design perspective, we need to retain description even if sold out on items (and thus no item objects)
Item
descriptionpriceserial numberitemID
ProductDescription
descriptionpriceitemID
Item
serial number
Describes Better
Worse
1 *
Copyright ©2004 Cezary Z Janikow 12
Rules for having Description classes
– If descriptions are independent of the exietence of items
– If deleting an object deletes information that may need to be maintained
– If it reduces duplications or adds clarity
Worse
Flight
datetime
FlightDescription
number
Airport
name
Describes-flights-to
Described-by
Flight
datenumbertime
Airport
name
Flies-to
Better
1*
1*
1
*
Copyright ©2004 Cezary Z Janikow 13
Associations
Relationships between classes
– Stemming from relationships on objects
Transient (for some duration that we need to investigate details of)
Persistent
Derived from Analysis or the Association List (Table 9.2)
In the conceptual model, association is just a statement about the relationships
– If message need to be passes, it will persist in the design model (from Interactions)
Visibility and navigability will have to be established
Copyright ©2004 Cezary Z Janikow 14
SaleRegister Records-current 0..11
association name multiplicity
-"reading direction arrow"-it has no meaning except to indicate direction of reading the association label-often excluded
Association Notations
Copyright ©2004 Cezary Z Janikow 15
Associations
Naming
– Verb Phrases
Roles
– Each end
– Having
Names for the roles of the two classe/objects (sometime this is called “roles”)
MultiplicityHow many objects participate
NavigabilityHow one object will find the other object to send a message
Copyright ©2004 Cezary Z Janikow 16
Multiplicity
zero or more;"many"
one or more
one to 40
exactly 5
T
T
T
T
*
1..*
1..40
5
T3, 5, 8
exactly 3, 5, or 8
ItemStore Stocks
*
multiplicity of the role
1
Copyright ©2004 Cezary Z Janikow 17
Multiplicity
ItemStore Stocks
1or 0..1
Multiplicity should "1" or "0..1"?
The answer depends on our interest in using the model. Typically and practically, the muliplicity communicates adomain constraint that we care about being able to check in software, if this relationship was implemented or reflectedin software objects or a database. For example, a particular item may become sold or discarded, and thus no longerstocked in the store. From this viewpoint, "0..1" is logical, but ...
Do we care about that viewpoint? If this relationship was implemented in software, we would probably want to ensurethat an Item software instance would always be related to 1 particular Store instance, otherwise it indicates a fault orcorruption in the software elements or data.
This partial domain model does not represent software objects, but the multiplicities record constraints whose practicalvalue is usually related to our interest in building software or databases (that reflect our real-world domain) with validitychecks. From this viewpoint, "1" may be the desired value.
*
Copyright ©2004 Cezary Z Janikow 18
Multiple Associations
Two classes can have multiple relations
Flight Airport
Flies-to
Flies-from
*
* 1
1
Copyright ©2004 Cezary Z Janikow 19
Conceptual Domain Model in POS
Register
ItemStore
Sale
CashPayment
SalesLineItem
CashierCustomer
ProductCatalog
ProductDescription
Stocks
*
Houses
1..*
Used-by
*
Contains
1..*
Describes
*
Captured-on
Contained-in
1..*
Records-sale-of
0..1
Paid-by Is-for
Logs-completed
*
Works-on
1
1
1
1 1..*
1
1
1
1
1
1
1
0..1 1
1
Ledger
Records-accounts-
for
1
1
Copyright ©2004 Cezary Z Janikow 20
Attributes
Logical data value of an object
Carefully distinguish attributes from objects
– Do not use to relate classes or objects
Use associations instead
– Use as classes if
Composed of multiple elements (has attributes-states)
There are operations (behavior)
Has units of quantity
Copyright ©2004 Cezary Z Janikow 21
Attributes: notation
Sale
- dateTime : Date- / total : Money
Private visibility attributes
Math
+ pi : Real = 3.14 {readOnly}
Public visibility readonly attribute with initialization
Person
firstNamemiddleName : [0..1]lastName
Optional value
Sale
dateTime/ total : Money
attributes
derived attribute
Copyright ©2004 Cezary Z Janikow 22
Multiplicity vs. derived attribute
SalesLineItem ItemRecords-sale-of 10..1
SalesLineItem ItemRecords-sale-of0..1 1..*
Each line item records aseparate item sale.For example, 1 tofu package.
Each line item can record agroup of the same kind of items.For example, 6 tofu packages.
SalesLineItem
/quantity
ItemRecords-sale-of0..1 1..*
derived attribute fromthe multiplicity value
Copyright ©2004 Cezary Z Janikow 23
Multiplicity vs. derived attribute
SalesLineItem ItemRecords-sale-of 10..1
SalesLineItem ItemRecords-sale-of0..1 1..*
Each line item records aseparate item sale.For example, 1 tofu package.
Each line item can record agroup of the same kind of items.For example, 6 tofu packages.
SalesLineItem
/quantity
ItemRecords-sale-of0..1 1..*
derived attribute fromthe multiplicity value
Copyright ©2004 Cezary Z Janikow 24
Attributes: examples
Cashier
namecurrentRegister
Cashier
name
Register
number
Uses
Worse
Better
not a "data type" attribute
1 1
Flight
Flight
destinationWorse
BetterFlies-to Airport1 1
destination is a complex concept
Copyright ©2004 Cezary Z Janikow 25
Attributes: examples
OK
OK
ProductDescription
ProductDescription
itemId : ItemID
1Store
Store
address : Address
11 1
ItemID
idmanufacturerCodecountryCode
Address
street1street2cityName...
Cashier
namecurrentRegisterNumber
Cashier
name
Register
number
Works-on
Worse
Better
a "simple" attribute, but being used as a foreign key to relate to another object
1 1
Copyright ©2004 Cezary Z Janikow 26
Attributes: examples of quantities
Payment
amount : Number
Payment Quantity
amount : Number
Unit
...
Payment
amount : Quantity
Has-amount1*
Is-in1*
not useful
quantities are pure data values, so are suitable to show in attribute section better
Payment
amount : Money
variation: Money is a specialized Quantity whose unit is a currency
Copyright ©2004 Cezary Z Janikow 27
POS Domain Model w/attributes
Register
id
ItemStore
nameaddress
Sale
dateTime/ total
CashPayment
amountTendered
SalesLineItem
quantity
Cashier
id
Customer
ProductCatalog
ProductDescription
itemIDdescriptionprice
Stocks
*
Houses
1..*
Used-by
*
Contains
1..*
Describes
*
Captured-on
Contained-in
1..*
Records-sale-of
0..1
Paid-by Is-for
Logs-completed
*
Works-on
1
1
1
1 1..*
1
1
1
1
1
1
1
0..1 1
1
Ledger
Records-accounts-
for
1
1