02291: System Integration
Week 7
Hubert Baumeister hub@imm.dtu.dk
DTU Compute Technical University of Denmark
Spring 2013
Contents
Sequence Diagrams
Design Validation: Use Case Realization
Example: Interaction Diagrams
Sequence Diagram
Communication Diagram
Example Sequence Diagram
Arrow types
a:A b:B
async call
sync call
return async call
sync call
async call
Example Interaction Frames
Interaction Frame Operators I
Nested sequence diagrams
Usages of sequence diagrams
I Abstract: show the execution (i.e. exchange of messages) of a system
I Concrete
I Design (c.f. CRC cards)
I Visualize program behaviour
I Visualize model execution → use case realization
System design: Detail Use Case Check out
I Use Case Name: Check out
I Summary: Checks out a book from the library
I Actors: User
I Preconditions: true
I Basic course of events
I 1. User scans his library card
I 2. User selects check out
I 3. User scans the book
I 4. System confirms loan
I Alternative paths . . .
I Postconditions
I Book is loaned by the user
Use Case scenarios as Sequence Diagrams
Main scenario
System design for the main use case scenario
loop [foreach b' in bor->books]
Contents
Sequence Diagrams
Design Validation: Use Case Realization
UML Models
I UML Model = one system
I UML Diagrams = view on the same system
→ UML diagrams depend on each other
I Use case diagram(s)
I Detailed use cases
I Component diagram(s)
I Protocol statemachines
I Class diagram(s)
I Object life cycle state machines
Dependence between models: Consistency conditions
1) Components are implemented by class diagrams
I Provided interfaces in ports have to be implemented by classes
I Object life cycle behaviour conforms to the the protocol statemachines
2) Use case scenarios can be realized by the system
→ use sequence diagrams to show this
Use Case Diagram Library System
Detail Use Case Check out
I Use Case Name: Check out
I Summary: Checks out a book from the library
I Actors: User
I Preconditions: true
I Basic course of events
I 1. User scans his library card
I 2. User selects check out
I 3. User scans the book
I 4. System confirms loan
I Alternative paths
I 3.a. User has overdue books
I System rejects loan with message ’overdue books’
I 3.b User has more then 5 books on loan
I System rejects loan with message ’too many books’
I 1.a User is not registered with the system
I . . .
I Postconditions
I Book is loaned by the user
Implementation: Component Diagram
LibrarySystem
LibraryInterface
«interface»
LibraryInterface scan library card() check out
scan book()
check in
...
Implementation: Protocol State Machine
scan library card check out
scan book/
[result = (false,'too many books') or result = (false,'overdue books') or
result = true]
...
check in
More functionality /[result = true]
/[result = false]
Implementation: Class Diagram
Library scan library card() check out scan book() check in ...
Borrower canBorrow()
Book overdue : bool register() deregister() checkout() checkin() isOverdue() : bool
*
* user
0..5
{body: overdue}
«interface»
LibraryInterface scan library card() check out scan book() check in ...
{body: books->size <= 5 and books->forAll(b | not(b.isOverdue()))}
{pre: not(bor.canBorrow()
post: dueDate = Date.today + 3 weeks and
bor.books->containing(self) }
Implementation: Behaviour Library
Idle User scanned
scan library card (l)
[not users->contains(l)] / return false
[users->contains(l)]/
return true book scanned
scan book(s)/ (cb,msg) := bor.canBorrow()
[cb] / book := books->select(b| b.signature = s);
book.check_out(); return true ...
can borrow?
user ok check out
[not cb] / return (false,msg) after 10min
Implementation: Behaviour Book
available borrowed
check out(b) / dueDate := today + 3 weeks; b.books := b.books->containing(self)
at dueDate /overdue := true
overdue check in
check in / overdue := false not registered
registered
register
deregister
Use Case success scenario realisation
loop [foreach b' in bor->books]
Use Case fail realisation
loop [foreach b' in bor->books]
Checking the a use case realization is correct
1 The sequence diagram shows correctly the user interaction of the use case scenario
2 All messages appear in the respective interfaces of the class
3 All messages are admissiable according to the protocol state machines (PSM)
4 All message sequences are admissible according to the
behaviour specification
1) User interactions
I Basic course of events
I 1. User scans his library card
I 2. User selects check out
I 3. User scans the book
I 4. System confirms loan
2) Messages belong to interfaces
Library scan library card() check out scan book() check in ...
Borrower canBorrow()
Book overdue : bool register() deregister() checkout() checkin() isOverdue() : bool
*
* user
0..5
{body: overdue}
«interface»
LibraryInterface scan library card() check out scan book() check in ...
{body: books->size <= 5 and books->forAll(b | not(b.isOverdue()))}
{pre: not(bor.canBorrow() post: dueDate = Date.today + 3 weeks and bor.books->containing(self) }
loop [foreach b' in bor->books]
3) Messages conform to the PSM
scan library card check out
scan book/
[result = (false,'too many books') or result = (false,'overdue books') or
result = true]
...
check in
More functionality /[result = true]
/[result = false]
loop [foreach b' in bor->books]
4) Messages follow the behaviour specification
Idle scan library card (l) User scanned
[not users->contains(l)] / return false
[users->contains(l)]/
return true book scanned
scan book(s)/ (cb,msg) := bor.canBorrow()
[cb] / book := books->select(b| b.signature = s);
book.check_out(); return true ...
can borrow?
user ok check out
[not cb] / return (false,msg) after 10min
loop [foreach b' in bor->books]
4) Messages follow the behaviour specification
available borrowed
check out(b) / dueDate := today + 3 weeks; b.books := b.books->containing(self)
at dueDate /overdue := true
overdue check in
check in / overdue := false not registered
registered
register
deregister
loop [foreach b' in bor->books]
