Post on 05-Jan-2016
transcript
1
On To Object Design
Chapter 14
Applying UML and Patterns
-Craig Larman
2
Connection between SSDs, System Operations and Layers
In a well-designed layered architecture that supports high cohesion and a separation of concerns, the UI layer objects will then forward the request from the UI layer onto the domain layer for handling.
How design objects?
Code : Design while coding
Draw , then code : UML on a
whiteboard , then switch to code
Only draw: tools generate
everything from diagrams.
3
WSEP 06
Designing ObjectsStatic and dynamic modeling.
Two kinds of object models:
• Static models :• Class diagrams / Package diagram / Deployment diagram
Helps design definition of packages, class name, attributtes and method signature
• Dynamic models:• Interaction Diagrams/ (Sequence / comunication). State machine
diagrams/activity diagram
Illustrate how objects collaborate via messages and methdos . They help design the logic and method bodies
5
Agile modeling practice Create Models in parallel! ( interaction diagram and class diagram)Modeling with others
6
UML INTERACTION DIAGRAMS
Chapter 15
Applying UML and Patterns
-Craig Larman
Sequence Diagrams 7
A First Look at interaction Diagrams
Illustrate how objects interacts with each other.
Emphasizes time ordering of messages.
Can model simple sequential flow, branching, iteration (loop) , …etc
Sequence / communication
sequence diagram
: A myB : B
doTwo
doOne
doThree
Each new object is added to the right
Method of Object A
Class A has an attribute of type B to be able to call doTwo and doThree.
Methods of Object B
Code
public class A{ private B myB= new B();
Public void doOne(){ myB.doTwo();myB.doThree();}
}
Class A has an attribute of type B.
Class A has a method named doOne
Class B has methods named doTwo and doThree
Communication diagram
: A
myB : B
1: doTwo
2: doThree
doOne
Interaction Diagram notation
class instance named instance
:Sale s1:SaleSale
sales: ArrayList<Sale>
:Sale s1 : Sale
lifeline box representing an instance of an ArrayList class, parameterized (templatized) to hold Sale objects
lifeline box representing an unnamed instance of class Sale
lifeline box representing a named instance
sales[ i ] : Sale
lifeline box representing one instance of class Sale, selected from the salesArrayList <Sale> collection
x : List
«metaclass»Font
lifeline box representing the class Font, or more precisely, that Font is an instance of class Class – an instance of a metaclass
related example
List is an interface
in UML 1.x we could not use an interface here, but in UML 2, this (or an abstract class) is legal
Common UML Interraction diagram notation
lifeline
Basic Sequence diagram notation
: Register : Sale
doA
doB
doX
doC
doD
typical sychronous message shown with a filled-arrow line
a found message whose sender will not be specified
execution specification bar indicates focus of control
How to illustrate a return result ?
: Register : Sale
d1 = getDate
getDate
doX
aDate
Is equivalent to
Messages sent to itself
: Register
doX
clear
Creation of Instances
: Register : Sale
makePayment(cashTendered)
: Paymentcreate(cashTendered)
authorize
note that newly created objects are placed at their creation "height"
Dashed line
Sale class will invoke the new operator and call the constructor.
Object destruction
: Sale
: Paymentcreate(cashTendered)
...the «destroy» stereotyped message, with the large X and short lifeline indicates explicit object destruction
«destroy» X
Conditional message : OPT frame is placed around one or more messages.
calculate
: Bar
yy
xx
[ color = red ]opt
: Foo
opt: Optional fragment that execute if guard [color=red] is true
Conditional message : UML1.x notation
[ color = red ] calculate
: Bar
yy
xx
: Foo
which notation do you prefer?
calculate
: Bar
yy
xx
[ color = red ]opt
: Foo
[ color = red ] calculate
: Bar
yy
xx
: Foo
Loops (iteration over a collection)
st = getSubtotal
lineItems[i] :SalesLineItem
t = getTotal
[ i < lineItems.size ]loop
: Sale This lifeline box represents one instance from a collection of many SalesLineItem objects.
lineItems[i] is the expression to select one element from the collection of many SalesLineItems; the ‘i” value refers to the same “i” in the guard in the LOOP frame
an action box may contain arbitrary language statements (in this case, incrementing ‘i’)
it is placed over the lifeline to which it applies
i++
Code page 234
22
Loops (iteration over a collection)
st = getSubtotal
lineItems[i] :SalesLineItem
t = getTotal
loop
: Sale
Which notation do you prefer
st = getSubtotal
lineItems[i] :SalesLineItem
t = getTotal
[ i < lineItems.size ]loop
: Sale This lifeline box represents one instance from a collection of many SalesLineItem objects.
lineItems[i] is the expression to select one element from the collection of many SalesLineItems; the ‘i” value refers to the same “i” in the guard in the LOOP frame
an action box may contain arbitrary language statements (in this case, incrementing ‘i’)
it is placed over the lifeline to which it applies
i++
st = getSubtotal
lineItems[i] :SalesLineItem
t = getTotal
loop
: Sale
Nesting of frames
25
How relate Interaction diagram?
26
Invoke static (class)methods
27
Polymorphism in interaction diagrams?
28
UP artifacts influencing OO design
Operation: enterItem(…)
Post-conditions:- . . .
Operation Contracts
Sale
date. . .
SalesLineItem
quantity
1..*1 . . .
. . .
Domain Model
Use-Case Model
Design Model: Register
enterItem(itemID, quantity)
: ProductCatalog
d = getProductDescription(itemID)
addLineItem( d, quantity )
: Sale
Require-ments
Business Modeling
Design
Sample UP Artifact Relationships
: System
enterItem(id, quantity)
Use Case Text
System Sequence Diagrams
makeNewSale()
system events
Cashier
Process Sale
: Cashier
use case
names
system operations
Use Case Diagram
SupplementarySpecification
Glossary
starting events to design for, and detailed post-condition to satisfy
Process Sale
1. Customer arrives ...2. ...3. Cashier enters item identifier.
inspiration for names of some software domain objects
functional requirements that must be realized by the objects
ideas for the post-conditions
Register
...
makeNewSale()enterItem(...)...
ProductCatalog
...
getProductDescription(...)...
1*
non-functional requirements
domain rules
item details, formats, validation
Questions?
30
aMember: BookBorrower
theLibraryMember:LibraryMember
theCopy: Copy theBook: Book
borrow (theCopy)1: okToBorrow
2: borrow2.1:borrowed
Can you guess the scenario from this interaction diagram ?
Collaboration diagram: Library System
BookBorrower
borrow()
2:borrow()
1:okToBorrow()
2.1: borrowed()
:LibraryMember theCopy:Copy
:Book