8- sequence diagrams and class diagrams
DESCRIPTION
Tutorial slides from SOEN 341 ConcordiaTRANSCRIPT
Sequence Diagrams and Class Diagrams
slides by Prof. C. Constantinides
2
Guidelines for contracts
Operation:makeNewSale...
Use Case:Process Sale
Use CaseSystemSequenceDiagram
SystemOperations Contracts
makeNewSale()
addLineItem ()
endSale()
makePayment()
SystemmakeNewSale()addLineItem(id, quantity)endSale()makePayment(cashTendered)
Operation:addLineItem...
Operation:endSale...Operation:makePayment...
3
Sequence diagrams
• Sequence diagrams illustrate interactions in a kind of fence format.
• Set of all operation contracts defines system behavior.• We will create an interaction diagram for each operation
contract.
message2()
message3()
message1()
:ClassAInstance :ClassBInstance
4
Example sequence diagram: makePayment
makePayment (cashTendered)
:Register :Sale
:Payment
makePayment (cashTendered)
create (cashTendered)
5
Illustrating classes and instances
• To show an instance of a class, the regular class box graphic symbol is used, but the name is underlined. Additionally a class name should be preceded by a colon.
• An instance name can be used to uniquely identify the instance.
Sale Class
:Sale Instance
s1:Sale Named instance
6
• An object lifeline shows the extend of the life of an object in the diagram.
• Note that newly created objects are placed at their creation height.
makePayment()
:Register :Sale
:Payment
makePayment(…)create(…)
7
Sequence diagrams
message1()
:A :B
[color=red] calculate()
8
Example-Alternate Flow (branching)
message1()
:A :B :C
[x<10] calculate()
[x>15] calculate()
Loops and Opt Flow
10
• Assume we need to create a Payment instance and associate it with Sale. What class should be responsible for this?
• However, Register may become bloated if it is assigned more and more system operations.
:Register :Sale
create()
addPayment(p)
makePayment()
p:Payment
11
• An alternative design delegates the Payment creation responsibility to Sale, which supports higher cohesion in Register.
• This design supports high cohesion and low coupling.
:Register :Sale
create()
makePayment()
:Payment
makePayment()
Return ValuesTwo Accepted ways of expressing return Values.1. Using syntax returnVar = message(parameter).2. Using a reply (or return) message at the end of the activation
bar for that method. If this is used the return value is labeled with a description.
13
Use Case realizations• A use-case realization
describes how a use case is realized in terms of collaborating objects.
• UML interaction diagrams are used to illustrate use case realizations.
• Recall Process Sale: from the main scenario we identified a number of system events (operations)
• Each system event was then described by a contract.
System
makeNewSale()addLineItem(id, quantity)endSale()makePayment(cashTendered)
Contract CO1: makeNewSaleOperation: makeNewSale ()Cross References: Use Case Process Sale.Preconditions: none.Postconditions:
– A Sale instance s was created. (instance creation)
– s was associated with Register (association formed)
– Attributes of s were initialized
14
Object design: makeNewSale
• We work through the postcondition state changes and design message interactions to satisfy the requirements.
:Register
:Sale
create()
makeNewSale()
:SalesLineItem
create()
Register creates aSale by Creator.
By Creator, Sale creates an empty multiobjectwhich will eventually holdSalesLineItem instances
By Controller.
This is NOT a SalesLineItemInstance but a collection object.
Implied to take place within theconstructor of Sale instance.
15
Creating design class diagrams (DCDs)
• Once the interaction diagrams have been completed it is possible to identify the specification for the software classes and interfaces.
• A class diagram differs from a Domain Model by showing software entities rather than real-world concepts.
• The UML has notation to define design details in static structure, or class diagrams.
16
• Typical information in a DCD includes:– Classes, associations and attributes– Interfaces (with operations and constants)– Methods– Attribute type information– Navigability– Dependencies
• The DCD depends upon the Domain Model and interaction diagrams.
• The UP defines a Design Model which includes interaction and class diagrams.
17
java.awt::Fontor
java.awt.Font
plain : Int = 0 { readOnly }bold : Int = 1 { readOnly } name : Stringstyle : Int = 0...
getFont(name : String) : FontgetName() : String...
«interface»Runnable
run()
- ellipsis “…” means there may be elements, but not shown- a blank compartment officially means “unknown” but as a convention will be used to mean “no members”
SubclassFoo
...
run()...
SuperclassFooor
SuperClassFoo { abstract }
- classOrStaticAttribute : Int+ publicAttribute : String- privateAttributeassumedPrivateAttributeisInitializedAttribute : Bool = trueaCollection : VeggieBurger [ * ]attributeMayLegallyBeNull : String [0..1] finalConstantAttribute : Int = 5 { readOnly }/derivedAttribute
+ classOrStaticMethod()+ publicMethod()assumedPublicMethod()- privateMethod()# protectedMethod()~ packageVisibleMethod()«constructor» SuperclassFoo( Long )methodWithParms(parm1 : String, parm2 : Float)methodReturnsSomething() : VeggieBurgermethodThrowsException() {exception IOException}abstractMethod()abstractMethod2() { abstract } // alternatefinalMethod() { leaf } // no override in subclasssynchronizedMethod() { guarded }
3 common compartments
1. classifier name
2. attributes
3. operations
interface implementation andsubclassing
Fruit
...
...
PurchaseOrder
...
...
1
association with multiplicities
dependency
officially in UML, the top format is used to distinguish the package name from the class name
unofficially, the second alternative is common
order
an interface shown with a keyword
18
1Captures
Sale
date: DateisComplete : Boolean
Register
1getBalance()endSale()makeNewSale()addLineItem()makePayment()
becomeComplete()isComplete()makeLineItem()makePayment()getBalance()getTotal()
Design:software perspective
1CapturesSale
date: DateisComplete : Boolean
Register1
Domain model:conceptual perspective
Domain model vs. design model classes
currentSale
19
Creating the design class diagram
1Captures
Sale
date: DateisComplete : Boolean
Register
1
Three section box Navigability
methods; parameters not specified
Type information
getBalance()endSale()makeNewSale()addLineItem()makePayment()
becomeComplete()isComplete()makeLineItem()makePayment()getBalance()getTotal()
20
How to build a class diagram
1. Identify all the classes participating in the software solution. Do this by analyzing the interaction diagrams. Draw them in a class diagram.
2. Duplicate the attributes from the associated concepts in the Domain Model.
Register
Store
ProductCatalog
SalesLineItem
quantity
Sale
Payment
addressphone
date: DateisComplete
amount: Moneyquantity
ProductSpecificationspecificationpriceid
21
3. Add method names by analyzing the interaction diagrams.– The methods for each class can be identified by analyzing the
interaction diagrams.
Sale
date: DateisComplete: Boolean
:Register :Sale3: makeLineItem(spec, quantity)
makeLineItem()
If the message makeLineItem issent to an instance of classSale, then class Sale mustdefine a makeLineItem method.
22
4. Add type information to the attributes and methods.
Register
Store
ProductCatalog ProductSpecification
SalesLineItem
quantity: integer
Sale
Payment
address: Addressphone: PhoneNumber
date: DateisComplete: Boolean
amount
… specification: Stringprice: Moneyid: ItemIDendSale()
addLineItem()makeNewSale()makePayment()
getProductSpecification()
becomeComplete()makeLineItem()makePayment()getTotal() getSubtotal()
23
Method names - multiobjects
• The find() message to the multiobject should be interpreted as a message to the container/ collection object.
• The find() method is not part of he ProductSpecification class definition.
:ProductSpecification
1.1: spec := find(id)
1: spec := getProductSpecification(id)
:ProductCatalog
24
Associations, navigability, and dependency relationships
• Add the associations necessary to support the required attribute visibility.– Each end of an association is called a role.
• Navigability is a property of the role implying visibility of the source to target class.– Attribute visibility is implied.– Add navigability arrows to the associations to indicate the direction of
attribute visibility where applicable.– Common situations suggesting a need to define an association with
navigability from A to B: A sends a message to B. A creates an instance of B. A needs to maintain a connection to B
• Add dependency relationship lines to indicate non-attribute visibility.
25
Illustrating attributes
1Captures
Sale
date: DateisComplete : Boolean
endSale()addLineItem()makePayment()
Register
1
makeLineItem()
Register class will probablyhave an attribute pointing to aSale object.
Navigability arrow indicatesRegister objects are connectedunidirectionally to Sale objects.
Absence of navigability arrow indicates no connection fromSale to Register.
26
Attributes as association texts vs. as association types
Register
...
...
Sale
...
...
1
Register
currentSale : Sale
...
Sale
...
...
using the attribute text notation to indicate Register has a reference to one Sale instance
using the association notation to indicate Register has a reference to one Sale instance
OBSERVE: this style visually emphasizes the connection between these classes currentSale
Register
currentSale : Sale
...
Sale
...
...
1thorough and unambiguous, but some people dislike the possible redundancy currentSale
27
1Captures
Sale
date: DateisComplete : Boolean
Register
1getBalance()endSale()makeNewSale()addLineItem()makePayment()
becomeComplete()isComplete()makeLineItem()makePayment()getBalance()getTotal()
Register has TWO attributes:currentSale: Salecatalog: ProductCatalog
currentSale
1catalog ProductCatalog
addProduct()getProductSpecification()
Example of attributes as association types
28
Collection attributes:Two ways to illustrate
Sale
date: DatelineItems: SalesLineItem [1..*] orlineItems: SalesLineItem [1..*] {ordered}
SalesLineItem
SalesLineItemSale
lineItems{ordered, List}
1..*
An association end can optionally havea property string like {ordered, List}
29
Adding navigability and dependency relationships
1
Captures
1
getBalance()endSale()makeNewSale()addLineItem()makePayment()
Register
ProductSpecification
specification : Stringprice : Moneyid: itemID
SalesLineItem
quantity : integer
getSubtotal()
Payment
amount : Money
ProductCatalog
addProduct()getProductSpecification()
Sale
date : DateisComplete : Boolean
address : Addressphone : PhoneNumber
Store1
1
1..*
1
1
1
1
1 11
11
*
*
Uses
Houses
Looks-in
Contains
Contains
Describes
Logs-completed Paid-by
Illustrates non-attribute visibility
becomeComplete()isComplete()makeLineItem()makePayment()getBalance()getTotal()
getRegister()
1..*