Upload
patricia-martin
View
225
Download
0
Embed Size (px)
Citation preview
DOMAIN MODELCLASS DIAGRAMPrepared by: Fatimah AlakeelNovember, 2011
Last time …
The use case model i.e. system functionality expressed in a way understandable to an end user
Now …
Domain model .... and Class diagram
Domain Model
Domain Model
• A Domain Model illustrates meaningful concepts in a problem domain.
• It is a representation of real-world things, not software components.
• It is a set of static structure diagrams; no operations are defined.
• It may show:– Concepts / entities [ Modeled as classes and objects]
– associations between concepts– attributes of concepts
When to create Domain Model domain modelling is usually carried
out in parallel with use case modelling.
the domain model represents a structural/static view whereas use case modelling focuses on behaviour.
The domain model is viewed through a class diagram
Requirements Analysis Design Implementation Test
Use case model
Processworkflows
Requirements model
UML
+ a domain model
Why do we need a domain model?
Gives a conceptual framework of the things in the problem space
Helps you think – focus on semantics
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
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?
An obvious way to identify domain classes is to 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 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!
Domain Model Example1
Some candidate objects/classes for the retail banking system?
Classes and Objects
Customer? Retail Customer? Business Customer?
Customer accounts? Transactions on customer accounts?
What about the bank itself?
… and the ATM system?
Shop assistant?
What about other actors from the use case model?
Credit card system?
withdrawCashATM
«actor»Banking system
validateAmount
validatePIN
<<include>>
<<include>>
«actor»ATM system
The Domain ModelReturning to retail banking example …
customer
<<abstract>>
business customer retail customer
part of the use case model
A possible domain model for the retail banking system
<<abstract>>Customer
Retail Customer
Business Customer
Bank
<<abstract>>Account
Savings ChequeCash
Management
ATM system
Transactionholds►
◄has
has►
maintains▼
*1
*
1..2 *
1
*
1 ◄connectsTo
The Domain Model
1 1
A possible domain model for the retail banking system
<<abstract>>Customer
Retail Customer
Business Customer
Bank
<<abstract>>Account
Savings ChequeCash
Management
ATM system
Transactionholds►
◄has
has►
maintains▼
*1
0..1
1..2 *
1
0..1
1 ◄connectsTo
The Domain Model
could introducequalifiedassociations
cust#
acc#
1 1
A possible domain model for the retail banking system
<<abstract>>Customer
Retail Customer
Business Customer
Bank
<<abstract>>Account
Savings ChequeCash
Management
ATM system
Transactionholds►
◄has
has►
maintains▼
*1
0..1
1..2 *
1
0..1
1 ◄connectsTo
The Domain Model
could introducequalifiedassociations
cust#
acc#
.. and directed associations
1 1
Domain Model Example2
Classes and Objects
Some candidate objects/classes for the restaurant booking system?
a booking? a table?
a customer?
an advanced reservation?
a walk in?
the head waiter?the receptionist?
The Domain Model… now to the restaurant booking example …
Table Transfer
Record Booking
Cancel Booking
Record walk-in
Display Booking
Receptionist
Head Waiter
StaffRecord Arrival
Extension points:no booking
<<include>>
<<include>>
<<include>><<include>>
<<include>>
<<iextend>>
The use case diagram
The Domain Model… now to the restaurant booking example …
Booking Table
WalkIn Reservation Customer
1*
1* ◄makes
A UML note indicating a constraint on the association
{Bookings for the same tablemust not overlap}
The Domain Model… only WalkIns and Reservations will be instantiated
<<abstract>>
BookingTable
WalkIn Reservation Customer
1*
1* ◄makes
A UML note indicating a constraint on the association
{Bookings for the same tablemust not overlap}
The Domain Model
WalkIn Reservation
1*
1* ◄makes
<<abstract>>
Bookingcovers
datetime
adding some attributes …
Table
places
Customernamephone
Glossary
Booking: an assignment of a table to a party of diners for a meal
Covers: The number of diners that a booking is made for.
Customer: The person making the reservation.
Places: The number of diners that can be seated at a particular table.
Reservation: An advance booking for a table at a particular time.
WalkIn: A booking that is not made in advance
The Domain Model
WalkIn Reservation
1*
1
*
◄makes
<<abstract>>
Bookingcovers
datetime
Table
places
Customernamephone
Restaurant
Adding a class that will manage everything
1*
We will leave the issue of directional associations to later on
Class Diagram
Classes and Objects
What are objects and classes?
A preliminary definition:
An object is a concept, an abstraction, or a thing with crisp boundaries and meaning for the problem at hand.
An object has a state, behavior and identity.
The structure and behavior of similar objects are defined in their common class.
A person is a class whereas Fred, Tom and Mary are objects whose behavior and structure are defined by person.
The decomposition of a problem into objects depends on judgement and the nature of the problem.
There is no one correct representation
Note:
Class Diagrams
The class diagram describes the structure, the common attributes and operations for the objects.
• In domain modeling the class diagrams do not include all detail. They may simply only show the class name and focus on the relationships between classes.
• In the analysis and early design models the class diagrams may provide further detail e.g. an indication of the major fields and methods within each class.
• Later in a more detailed design model further detail is provided e.g. the visibility of the fields and methods, the return values and parameters for all methods etc.
(UML )Class Diagrams
Student
In a domain model
In an early analysis model
moving towards a design model
Student
studNumstudSurname
getSurname)(
Student
- studNum: int- studSurname: String- studGivenname: String
+ getSurname)(: String+ setSurname)name: String( : void
Software Design (UML)
Classes
ClassName
attributes
operations
A class is a description of a set of objects that share the same attributes,operations, relationships, and semantics.
Graphically, a class is rendered as a rectangle, usually including its name, attributes, and operations in separate, designated compartments.
Software Design (UML)
Class Names
ClassName
attributes
operations
The name of the class is the only required tag in the graphical representation of a class. It always appears in the top-most compartment. The class name is in bold and starts with a uppercase letter
Software Design (UML)
Class Attributes
Person
name : Stringaddress : Addressbirthdate : Datessn : Id
•An attribute is a named property of a class that describes the object being modeled.•In the class diagram, attributes appear in the second compartment just below the name-compartment.•The field name and data type of each field. Field names start with a lower case letter.•This section must be shown if there are methods shown in the following section• (although it can be empty).
Software Design (UML)
Class Attributes (Cont’d)
Person
name : Stringaddress : Addressbirthdate : Date/ age : Datessn : Id
Attributes are usually listed in the form:
attributeName : Type
A derived attribute is one that can becomputed from other attributes, butdoesn’t actually exist. For example,a Person’s age can be computed from his birth date. A derived attribute is designated by a preceding ‘/’ as in:
/ age : Date
Software Design (UML)
Class Attributes (Cont’d)
Person
+ name : String# address : Address# birthdate : Date/ age : Date- ssn : Id
Attributes can be:+ public# protected- private/ derived
Software Design (UML)
Class Operations
Person
name : Stringaddress : Addressbirthdate : Datessn : Id
eatsleepworkplay
Operations describe the class behavior and appear in the third compartment.
Software Design (UML)
Class Operations (Cont’d)
PhoneBook
newEntry (n : Name, a : Address, p : PhoneNumber, d : Description)getPhone ( n : Name, a : Address) : PhoneNumber
You can specify an operation by stating its signature: listing the method name, type, and default value of all parameters, and, in the case of functions, a return type. This section may be omitted.
Software Design (UML)
Depicting Classes
Person
name : Stringbirthdate : Datessn : Id
eat()sleep()work()play()
When drawing a class, you needn’t show attributes and operation in every diagram.
Person
Person
nameaddressbirthdate
Person
eatplay
Person
Software Design (UML)
Class Responsibilities
A class may also include its responsibilities in a class diagram.
A responsibility is a contract or obligation of a class to perform a particular service.
SmokeAlarm
Responsibilities
-- sound alert and notify guard station when smoke is detected.
-- indicate battery state
Software Design (UML)
Relationships
In UML, object interconnections (logical or physical), are modeled as relationships.
There are three kinds of relationships in UML:
• dependencies
• generalizations
• associations
Software Design (UML)
Dependency Relationships
CourseSchedule
add(c : Course)remove(c : Course)
Course
A dependency indicates a semantic relationship between two or more elements. The dependency from CourseSchedule to Course exists because Course is used in both the add and remove operations of CourseSchedule.
Software Design (UML)
Generalization Relationships
Person
A generalization connects a subclassto its superclass. It denotes an inheritance of attributes and behaviorfrom the superclass to the subclass andindicates a specialization in the subclassof the more general superclass.
Student
Software Design (UML)
Generalization Relationships (Cont’d)
Student
UML permits a class to inherit from multiple superclasses, although some programming languages (e.g., Java) do not permit multiple inheritance.
TeachingAssistant
Employee
Software Design (UML)
Association Relationships
If two classes in a model need to communicate with each other, there must be link between them.
An association denotes that link.
InstructorStudent
Software Design (UML)
Association Relationships (Cont’d)
We can indicate the multiplicity of an association by adding multiplicity adornments to the line denoting the association.
The example indicates that a Student has one or more Instructors:
InstructorStudent1..*
Software Design (UML)
Association Relationships (Cont’d)
The example indicates that every Instructor has one or more Students:
InstructorStudent1..*
Software Design (UML)
Association Relationships (Cont’d)
We can also indicate the behavior of an object in an association (i.e., the role of an object) using rolenames.
InstructorStudent1..*1..*
learns fromteaches
Software Design (UML)
Association Relationships (Cont’d)
We can also name the association.
TeamStudentmembership
1..* 1..*
Software Design (UML)
Association Relationships (Cont’d)
We can specify dual associations.
TeamStudent
member of
1..*
president of1 1..*
1..*
Software Design (UML)
Association Relationships (Cont’d)
We can constrain the association relationship by defining the navigability of the association. Here, a Router object requests services from a DNS object by sending messages to (invoking the operations of) the server. The direction of the association indicates that the server has no knowledge of the Router.
Router DomainNameServer
Software Design (UML)
Association Relationships (Cont’d)Associations can also be objects themselves, called link classes or an association classes.
WarrantyProduct
Registration
modelNumberserialNumberwarrentyCode
Software Design (UML)
Association Relationships (Cont’d)
A class can have a self association.
LinkedListNode
next
previous
Software Design (UML)
Association Relationships (Cont’d)We can model objects that contain other objects by way of special associations called aggregations and compositions.
An aggregation specifies a whole-part relationship between an aggregate (a whole) and a constituent part, where the part can exist independently from the aggregate. Aggregations are denoted by a hollow-diamond adornment on the association.
Car
Engine
Transmission
Software Design (UML)
Association Relationships (Cont’d)
A composition indicates a strong ownership and coincident lifetime of parts by the whole (i.e., they live and die as a whole). Compositions are denoted by a filled-diamond adornment on the association.
Window
Scrollbar
Titlebar
Menu
1
1
1
1
1
1 .. *
Domain model vs. Design Class Diagram – differences?
Register
...
endSale()enterItem(...)makePayment(...)
Sale
timeisComplete : Boolean/total
makeLineItem(...)
Register
...
Sale
timeisComplete : Boolean/total
Captures
1
11Domain Model
conceptual perspective
Design Model
DCD; software perspective
currentSale
Figure 16.2
References
Business Modelling with UML” – Penker “Analysis patterns” – Fowler
These books provide patterns for domain models.