View
218
Download
0
Category
Tags:
Preview:
Citation preview
TK2023 Object-Oriented Software Engineering
CHAPTER 5DOMAIN MODELLING
INTRODUCTION
One of the steps in object-oriented analysis is the decomposition of a domain of interest into individual conceptual classes or objects (real-world objects).
An important artifact created in this step is a domain model (also known as conceptual model, domain object model and analysis object model).
DOMAIN MODELS
A domain model is a visual representation of conceptual classes or real-world objects in a domain of interest.
In UML, a domain model is illustrated with a set of class diagrams in which no operations are defined.
It shows: conceptual classes (concepts / domain objects) associations between conceptual classes attributes of conceptual classes
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 4
conceptor domain object
association
attributes
DOMAIN MODEL - A VISUAL DICTIONARY OF ABSTRACTIONS Note that the diagram in the previous slide
depicts an abstraction of the conceptual classes; details which are uninteresting to the modellers are ignored in the diagram.
The visual makes it easy to comprehend the discrete elements and their relationships. Thus, the domain model may be considered a visual dictionary of abstractions of the domain.
DOMAIN MODELS DO NOT SHOW SOFTWARE COMPONENTS A domain model is a visualization of things in the
real-world domain of interest, not of software classes.
The following elements are not suitable in a domain model: software artifacts
responsibilities or methodsSale
dateprint()
POSApplet
IDENTIFYING CONCEPTUAL CLASSES In iterative development, a domain model is
incrementally built over several iterations in the elaboration phase.
In each iteration, the domain model is limited to the prior and current scenarios under consideration.
It is okay to miss conceptual classes during the initial identification step. The domain model can be updated when they are discovered later (e.g. during design work).
STRATEGIES FOR IDENTIFYING CONCEPTUAL CLASSES The following techniques can be used:
use a conceptual class category list identify noun phrases
Identify nouns and noun phrases in textual descriptions of a domain, and consider them as candidate classes or attributes.
Weakness: natural language is imprecise E.g. different noun phrases may represent the
same conceptual class or attribute.
use analysis patterns Analysis patterns are existing partial
domain models created by experts
CASE STUDY: PROCESS SALE Based on a simplified scenario of Process
Sale, the following candidate conceptual classes are identified using the first two techniques above:
Register ProductSpecification
Item SalesLineItem
Store Cashier
Sale Customer
Payment Manager
ProductCatalog
REPORT OBJECTS
Should "receipt" be included in the domain model? One reason to exclude it:
A receipt is a report of a sale. In general, it is not useful to include conceptual classes that reports information that can be derived from other sources.
One reason to include it: A receipt has a special role in the domain. A customer
needs a receipt in order to return bought items.
BUILDING A DOMAIN MODEL Apply the following steps:
1. Identify candidate conceptual classes related to the current requirements (use case) under consideration.
2. Represent those classes in a domain model.
3. Add associations necessary to record relationships for which there is a need to preserve some memory.
4. Add attributes necessary to fulfill the information requirements.
SOME GUIDELINES
Use the vocabulary of the domain when naming conceptual classes and attributes. For example, in the library domain, the term
"Borrower" or "Patron" is used rather than "Customer"
You should not include conceptual classes in the problem domain not pertinent to the requirements. For the case study, "Pen" and "PlasticBag" should
not be included.
You should not include things not in the problem domain. For example, "Flight" does not exist in the library
domain.
ATTRIBUTE OR CONCEPTUAL CLASS? A common mistake when building a domain
model is to represent something as an atribute when it should have been a conceptual class.
Salestore
Sale StorephoneNumber
ORRepresent "store"as an attribute
Represent "store"as a conceptualclass
Use the following rule of thumb:
If we do not think of some conceptualclass X as a number or text in the realworld, then X is probably a conceptualclass and not an attribute.
Another example,
Flightdestination OR
Flight Airportname
Consider our case study. Let's assume that: An "Item" represents a physical item in a store. An "Item" has a description, price and itemID,
which are not recorded elsewhere. Everyone working in the store has amnesia. Every time a real physical item is sold, a
corresponding software object "Item" is deleted from the computer memory.
“Rice Brand X”RM0.6011234
“Rice Brand X”RM0.6011234
“Rice Brand X”RM0.6011234
“Rice Brand X”RM11.00U110-134
“Rice Brand X”RM11.00U110-134
“Rice Brand X”RM11.00U110-134
SPECIFICATION OR DESCRIPTION CONCEPTUAL CLASSES
Problems: Information about the price of a "Rice Brand X"
product is lost if the shop is sold out of "Rice Brand X" products.
Space inefficiency as the price and itemID of "Rice Brand X" are duplicated for every "Item" instance of the same product.
This illustrates the need for conceptual classes that are specifications or descriptions of other things.
Example:
ItemdescriptionpriceserialNumberitemID
ItemserialNumber
ProductSpecificationdescriptionpriceitemID
*1
Describes
1 *
Add a specification or description conceptual class when: There needs to be a description about an item or
service, independent of the current existence of any examples of those items or services.
Deleting instances of things they describe results in a loss of information that needs to be maintained.
It reduces redundant or duplicated information.
Another example:
Airportname
Flightdatetime
FlightDescriptionnumber
1
*
1
*Describes-flights-to
1*
Described-by
* 1
Airportname
Flightdatenumbertime
* 1
Flies-to
1*
CASE STUDY: INITIAL DOMAIN MODEL
ItemRegister Store Sale
SalesLineItem Cashier Customer Manager
Payment ProductCatalog ProductSpecification
Based on the candidate conceptual classes identified previously, an initial domain model can be produced as follows:
ASSOCIATIONS
An association is a relationship between classes that indicates some meaningful and interesting connection.
Register Sale
11
Records-current
1 1
THE UML ASSOCIATION NOTATION
Sale Cashier
1** 1
Initiates
associations in domain models areinherently bidirectional
reading direction arrow - no special meaning, it's just to aid reading
multiplicity expressions
"Cashier initiates Sale"
CRITERIA FOR USEFUL ASSOCIATIONS We need to be selective when adding
associations to a domain model. There can be n*(n-1) possible associations in a
domain model with n different conceptual classes. Too many associations in a domain model can
make it difficult to understand which defeats its purpose as a communication tool.
Associations worth adding to a domain model are usually those for which knowledge of the relationship needs to be preserved for some duration (even for a millisecond).
For example,
The SalesLineItem objects associated with a Sale object need to be remembered; otherwise, it would not be possible to print a receipt, for instance.
Sale SalesLineItem
1..*11 1..*
Contains
Also, include associations as suggested by the requirements (use cases).
Sale Manager
1** 1
FINDING ASSOCIATIONS
Consider including the following associations in a domain model: Associations for which knowledge of the
relationship needs to be preserved for some duration ("need-to-know" associations).
Associations derived from the Common Associations List. Give priority to these categories
A is a physical or logical part of B A is physically or logically contained in/on B A is recorded in B
USEFUL GUIDELINES
Focus on "need-to-know" associations. It is more important to identify conceptual
classes than to identify associations. Too many associations tend to confuse a
domain model. Avoid showing redundant or derivable
associations.
Example:
SalesLineItem
Item
0..1
1..*
Sale1 1..*1 1..*
Contains
0..1
1..*
Records-Sale-Of
1..*
0..10..1
1..*
Involves
DERIVABLE
MULTIPLICITY
Multiplicity defines how many instances of a class A can be associated with one instance of a class B.
Store Item*1
Stocks
*1
association 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
Note that the multiplicity value is dependent on our interest as a modeler and software developer.
Consider the following possibilities:
husband
Person
1
1..4
Married-to
wife
1
Person
1
Married-to
wife
1
1husband
Person
1
1..*
Married-to
wife
1husband
NAMING ASSOCIATIONS The name of an association should be a verb or
a verb phrase. Ensure that it creates a sequence that is readable and meaningful in the model context. By convention, the default direction is left to right or top to bottom.
Airline
Flight PlanePerson
Employs
Supervises
Assigned-to Assigned-to
"Airline Employs Person"
"Plane Assigned-to Flight"
MULTIPLE ASSOCIATIONS BETWEEN TWO CLASSES It is not uncommon to have multiple
associations between two conceptual classes. Consider the following:
Both associations need to be shown separately as they indicate distinctly different relationships.
Flight Airport1* Flies-to
1* Flies-from
1
1*
*
ASSOCIATIONS AND IMPLEMENTATIONS Associations in a domain model represent
relationships that are meaningful in the real world.
Not all associations in a domain model need to be implemented in software.
DOMAIN MODEL FOR POS SYSTEM (WITH ASSOCIATIONS)
Register
ItemStore
Sale
Payment
SalesLineItem
CashierCustomer
ProductCatalog
ProductSpecification
Stocks
*
Houses
1..*
Used-by
*
Contains
1..*
Describes
*
Captured-on
Contained-in
1..*
Records-sale-of
0..1
Paid-by Is-for
Logs-completed
*
3 Works-on
1
1
1 1..*
1
1
1
1
1
1
1
0..1 1
1--
1
1
ADDING ATTRIBUTES
Besides associations, we also need to identify attributes of conceptual classes that are needed to satisfy the information requirements of the current scenarios under development.
ATTRIBUTE
An attribute is a logical data value of an object.
A domain model should include attributes for which the requirements (such as use cases) suggest or imply a need to remember information.
For example, a receipt normally includes the date and time of sale.
NOTATION FOR ATTRIBUTES
The type of an attribute is optional.
Saledate : Datetime attributes
GUIDELINES FOR IDENTIFYING ATTRIBUTES The attributes in a domain model should
preferably be simple attributes or data types.Examples of attribute types: Boolean, Date, Number, String (Text), Time Address, Colour, PhoneNumber,
SocialSecurityNumber, UniversalProductCode, Postcode
Consider the following:
Cashier
namecurrentRegister
Cashier
name
Register
numberWorks-on
1 1
This is not a "simple"attribute
Relate conceptual classes with an association, not with an attribute.
Flight
destination
destination is acomplex concept
AirportFlight
* 1* 1
Flies-to
ATTRIBUTES AS FOREIGN KEYS Do not use attributes as foreign keys to relate
conceptual classes (as typically done in relational database designs).
Use associations to relate those classes.
Register
numbercashierID
Register
number
Cashier
name11
Works-on
11
DOMAIN MODEL FOR POS SYSTEM
Register
ItemStore
Sale
Payment
SalesLineItem
CashierCustomer
ProductCatalog
ProductSpecification
Stocks
*
Houses
1..*
Used-by
*
Contains
1..*
Describes
*
Captured-on
Contained-in
1..*
Records-sale-of
0..1
Paid-by Is-for
Logs-completed
*
3 Works-on
1
1
1 1..*
1
1
1
1
1
1
1
0..1 1
1--
1
1
quantity
dateTimetotal
amountTendered
nameaddress
number
itemIDdescriptionprice
number
Recommended