Date post: | 27-Dec-2015 |
Category: |
Documents |
Upload: | hubert-burke |
View: | 226 times |
Download: | 0 times |
What is a domain model?
“A domain model captures the most important types of objects in the context of the business. The domain model represents the ‘things’ that exist or events that transpire in the business environment.” – I. Jacobsen
• A domain model is a visual representation of conceptual classes or real-situation objects in a domain .
• Domain models have also been called conceptual models
Domain Objects Are Not Software Objects
• The term “Domain Model” means a representation of real-situation conceptual classes, not of software objects.
Why do a domain model?• Gives a conceptual framework of the things in the
problem space• Helps you think – focus on semantics• Provides a glossary of terms – noun based• It is a static view - meaning it allows us convey
time invariant business rules• Based on the defined structure, we can describe
the state of the problem domain at any time.
Companyname
Personfirst name : Stringlast name : Stringsalary 0..11..*
Cartypename
*
+employer+employee
+owner
1..* 0..1
*
<<Rule>>If a person is not employed by a company then they do not have a car.
Simple domain model
Domain class
AttributeAssociation
Role
5
EXAMPLE:• Partial Domain model
V ideo
ID
S tocks
R ents
R ents-from
11..*
1 *1*
V ideoS tore
addressnam ephoneN um ber
C ustom er
addressnam ephoneN um ber
use cases sys. sequence diagrams domain models operation contract
Features of a domain model• The following features enable us to express time
invariant static business rules for a domain:-o Domain classes – each domain class denotes a type of
object.
o Attributes – an attribute is the description of a named slot of a specified type in a domain class; each instance of the class separately holds a value.
o Associations – an association is a relationship between two (or more) domain classes that describes links between their object instances. Associations can have roles, describing the multiplicity and participation of a class in the relationship.
o Additional rules – complex rules that cannot be shown with symbology can be shown with attached notes.
Domain classes?• Each domain class denotes a type of object. It is a
descriptor for a set of things that share common features. Classes can be:-
o Business objects - represent things that are manipulated in the business e.g. Order.
o Real world objects – things that the business keeps track of e.g. Contact, Site.
o Events that transpire - e.g. sale and payment.
• A domain class has attributes and associations with other classes (discussed below). It is important that a domain class is given a good description
How do I make a domain model?
Perform the following in very short iterations: o Make a list of candidate domain classes.o Draw these classes in a UML class diagram.o If possible, add brief descriptions for the classes.o Identify any associations that are necessary.o Decide if some domain classes are really just attributes.o Where helpful, identify role names and multiplicity for
associations.o Add any additional static rules as UML notes that cannot
be conveyed with UML symbols.o Group diagrams/domain classes by category into packages.
Concentrate more on just identifying domain classes in early iterations !
Identifying domain classes?• Three ways in which you can indentify a
domain class.• Reuse or modify existing models.• Use category list.• Identify nouns and phrases in textual
descriptions of a domain.• Consider a use case description as follows:-• 1. Customer arrives at a checkout with goods and/or
services to purchase.• 2. Cashier starts a new sale.• 3. Cashier enters item identifier.• 4. System records the sale line item and presents the item
description, price and running total.
Identifying nouns as candidates for domain objects
Candidate Conceptual Classes: Process Sale, Iteration 1
StoreRegister SaleItem
CashPayment
SalesLineItem
Cashier Customer
ProductCatalog
ProductDescription
Ledger
Identifying attributes ?
• A domain class sounds like an attribute if: -o It relies on an associated class for it’s identity –
e.g. ‘order number’ class associated to an ‘order’ class. The ‘order number’ sounds suspiciously like an attribute of ‘order’.
o It is a simple data type – e.g. ‘order number’ is a simple integer. Now it really sounds like an attribute!
Attributes vs. Classes
• Should “something” be – an attribute of a class, or – a separate conceptual class
• Examples:– Store: An attribute of Sale or separate class
• Store: Not a number or text• Should be separate conceptual class
– Flight destination: An attribute or a separate class• Destination is an airport, not a number• Should be separate conceptual class
• Guideline: – If we thing of something as simply a number or text in real life, it should be an attribute.– Otherwise it should be a conceptual class.
17
UML: Associations
VideoVideoStore Stocks
*1
association name multiplicity
-"direction reading arrow"-it has no meaning except to indicate direction of reading the association label-optional
How to name an association?
• Pattern: – Class name – verb phrase – class name– Readable and meaningful
• Try to avoid “has” or “uses”. These give no extra information
19
UML: Multiplicityzero or more;"many"
one or more
one to forty
exactly five
T
T
T
T
*
1..*
1..40
5
T3, 5, 8 exactly three,
five or eight
Customer
Video
Rents
*
One instance of aCustomer may berenting zero or moreVideos.
One instance of a Videomay be being rented byzero or one Customers.
0..1
ExampleName
Router
NameDedicatedToValidIPRangeConnectivityType
N/W Service
Name
Switch/Hub
SerialNumberHostNameIPAddressAdministratorSwitchPlugMemoryLocationInRackMaintainerWarranty
Machine
Name
Rack
1
*
1
*
1
*
*
0..1
0..1*
Mario Rack 19" Rack
1
1..*
Hard Disk CPU
MAC AddressInterfaceType
Network Interface Card11
Location
FreePort
1 *
LocationInRack
FreeSlot
1*
Location
FreePlug
* 1
RoomBuildingXY
Location
11
Graphics Card DVD CDMonitor Sound Card
MaintainerStartDateEndDate
H/W Warranty
DimensionsSlotNumberMachineDimensions
RackTypes
*
1
ManufacturerModel
Hardware Component
0..1
*
ModelManufacturer
1 *1 *
*
1
*
1
Name
Router
NameDedicatedToValidIPRangeConnectivityType
N/W Service
Name
Switch/Hub
SerialNumberHostNameIPAddressAdministratorSwitchPlugMemoryLocationInRackMaintainerWarranty
Machine
Name
Rack
1
*
1
*
1
*
*
0..1
0..1*
Mario Rack 19" Rack
MAC AddressInterfaceType
Network Interface Card11
Domain Model- POS
• Example: From the Conceptual Class Category List and noun phrase analysis, a list is generated of candidate conceptual classes for the domain.
Register Product Specification Store Cashier Customer SalesLineItem Manager ProductCatalog Item Payment Sale
Apply the following steps to create a domain model
1. List the candidate conceptual classes using the Conceptual Class Category List and noun phrase identification techniques related to the current requirements under consideration.
2. Draw them in a domain model.
3. Add the associations necessary to record relationships .
4. Add the attributes necessary to fulfill the information requirements.
Initial Domain Model
Domain Model: Adding Associations
Association Guidelines
• Focus on those associations for which knowledge of the relationship needs to be preserved for some duration ("need-to-know" associations).
• It is more important to identify conceptual classes than to identify association
• Too many associations tend to confuse a domain model rather than illuminate it. Their discovery can be time-consuming, with marginal benefit.
• Avoid showing redundant or derivable associations.
• Name an association based on a TypeName-VerbPhrase-TypeName format where the verb phrase creates a sequence that is readable and meaningful in the model context.
Roles
Each end of an association is called a role. Roles may optionally have:
• name
• multiplicity expression
• navigability
POS Domain Model Associations
Domain Model: Adding Attributes
• An attribute is a logical data value of an object.
• No Attributes as Foreign Keys
• Attributes should not be used to relate conceptual classes in the domain model
Example
Attributes in the POS Domain Model
• Payment amount— To determine if sufficient payment was provided, and to calculate change, an amount (also known as "amount tendered") must be captured.
• Product-Specification description— To show the description on a display or receipt.
• id— To look up a ProductSpecification, given an entered itemID, it is necessary to relate them to a id.
• price— To calculate the sales total, and show the line item price.• Sale date, time— A receipt is a paper report of a sale. It normally
shows date and time of sale.• SalesLineItem quantity— To record the quantity entered, when there
is more than one item in a line item sale (for example, five packages of tofu).
• Store address, name— The receipt requires the name and address of the store.
Domain Model Conclusion
References
• “Business Modelling with UML” – Penker
• “Analysis patterns” – Fowler
• Applying UML and Patterns – Craig Larman
These books provide patterns for domain models.