02291: System IntegrationWeek 7
Hubert [email protected]
DTU ComputeTechnical University of Denmark
Spring 2018
Recap
I Last WeekI Life cycle state machines (LSM’s): Describes the life cycle
of an objectI Protocol state machines (PSM’s): Describes the
communication protocol for provided/required interface of acomponent
I Today:I Sequence diagramsI Testing your model: Use case realizations
Contents
Components and Synchronous Communication
Sequence Diagrams
Design Validation: Use Case Realization
Synchronous– vs Asynchronous Calls:
Asynchronous Callpublic class Atm implements AtmToBank {
// From the user interface
public void enterPin(String pin) {
new Thread(() -> {bank.verifyPin(pin)}).start();
}
// From the bank
public void pinOk() { ... }
public void pinNotOk() { ... }
}
Synchronous Callpublic class Atm {
// From the user interface
public void enterPin(String pin) {
boolean pinOk = bank.verifyPin(pin);
}
}
Synchronous– vs Asynchronous Calls:
Asynchronous Callpublic class Atm implements AtmToBank {
// From the user interface
public void enterPin(String pin) {
new Thread(() -> {bank.verifyPin(pin)}).start();
}
// From the bank
public void pinOk() { ... }
public void pinNotOk() { ... }
}
Synchronous Callpublic class Atm {
// From the user interface
public void enterPin(String pin) {
boolean pinOk = bank.verifyPin(pin);
}
}
Synchronous version of the Bank
Closer View
Port Bank to ATM (BA):Provided interface I Port ATM to Bank (AB):
Required interface
Protocol for interfaces BankToAtm andBankToATMSync
I Asynchronous version ofthe protocol state machine
withdrawingwithdrawverifyingidle
sm: BankToAtm {protocol}
/ [^p inNotOk]
/ [^wi thdrawOk]/ [^withdrawNoOk]
withdraw(i,a)/ [ ^p inOk]verifyPin(p)
I Synchronous version ofthe protocol state machine
BankToATMSync. {protocol}
Idle Withdraw
withdraw(i,a)/[result = false]
withdraw(i,a)/[result = true]
verifyPin(p)/[result = true]
verifyPin(p)/[result = false]
Bank component with Implementation
Bank
Bank
CustomerAccount
ClearingCompanyToBank BankToATM *
«delegate»«delegate»
BankToATMPort
*
Detailed Class Diagram for the Bank Component
Bankname: String...accountFor(acct): AccountverifyPin(acct,pin)withdraw(acct,amount)
«interface»ClearingCompanyToBank
verifyPIN(acct,pin): bool
Customernameaddress...
Accountnumber : IBANbalance : intwithdraw(amount:int): bool...
BankToATMPortverifyPIN(acct,pin): boolwithdraw(acct,amt): bool
1 cc *
1..*
1..*
*c*
«interface»BankToATMSync
verifyPIN(acct,pin): boolwithdraw(acct,amt): bool *
1 b
Behaviour Design BankToATMPort
I Behaviour of class BanktToATMPort
I Behaviour of class Bank
Protocol conformance
Protocol for the interface BankToATMSyncBankToATMSync. {protocol}
Idle Withdraw
withdraw(i,a)/[result = false]
withdraw(i,a)/[result = true]
verifyPin(p)/[result = true]
verifyPin(p)/[result = false]
BankToATMPort lifecycle state machine
Summary: Components
I Ports in components haveI provided and required interfacesI Each interface: Protocol state machine
I Implementing Components1) Subcomponents delegating ports2) Set of classes
I Classes implement provided interface of a portI Classes use the required interface of a portI Lifecycle state machine and protocol state machine have to
conform to each other
Contents
Components and Synchronous Communication
Sequence Diagrams
Design Validation: Use Case Realization
Example: Interaction Diagrams
Sequence DiagramCommunication Diagram
Example Sequence Diagram
Creation and deletion of participants
Synchronous– vs Asynchronous Calls:Synchronous
b.m(4);
c.n(...) // Starts after m has returned
Synchronous calls
m(4)
n(...)
a:A b:B c:C
Asynchronous// (new Thread(){ public void run() {b.m(4);}}).start();
new Thread(() -> {b.m(4);}).start(); // Using Lambdas from Java 8
c.n(...) // Starts immediately after m has been called
Synchronous– vs Asynchronous Calls:Synchronous
b.m(4);
c.n(...) // Starts after m has returned
Synchronous calls
m(4)
n(...)
a:A b:B c:C
Asynchronous// (new Thread(){ public void run() {b.m(4);}}).start();
new Thread(() -> {b.m(4);}).start(); // Using Lambdas from Java 8
c.n(...) // Starts immediately after m has been called
Asynchronous calls
m(4)
n(...)
a:A b:B c:C
ATM to Bank: Asynchronous Version
ATM to Bank: Synchronous Version
Interaction Frames Example
Realising an algorithm using a sequence diagram
public void dispatch() {
for (LineItem lineItem : lineItems) {
if (lineItem.getValue() > 10000) {
careful.dispatch();
} else {
regular.dispatch();
}
}
if (needsConfirmation()) {
messenger.confirm();
}
}
Realisation with 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 ConcreteI Design (c.f. CRC cards)I Visualize program behaviourI Visualize model execution ! use case realization
System design: Detailed Use Case Check out
I Use Case Name: Check outI Summary: Checks out a book from the libraryI Actors: UserI Preconditions: trueI Basic course of events
I 1. User scans his library cardI 2. User repeats
I 2.1 select check outI 2.2 scan the bookI 2.3 System confirms loan
I Alternative paths. . .
I PostconditionsI Book is loaned by the user
Use Case scenarios as Sequence Diagrams
Main scenariosd: borrow book success
scanLibraryCard(bor)
true
checkOut()
scanBook(b)
true
loop
UserLibrary
System design for the main use case scenariosd: borrow book success
scan librarycard(bor)
true
checkOut()
scan book(b)
canBorrow()
isOverdue()
false
loop
true
checkout(bor)
true
true
loop
UserLibrary bor:Borrower
[b in bor.books]
b1:Book b2:Book
Contents
Components and Synchronous Communication
Sequence Diagrams
Design Validation: Use Case Realization
UML Models
I Many diagrams, but only one modelI Different Views on the system
I Functionality: Use Case diagram, state machines, activitydiagram, . . .
I Structure: Component diagram, Class diagramI Validation: Interaction diagram
Dependence between models: Consistency conditions
1) Components are implemented by class diagramsI Provided interfaces in ports have to be implemented by
classesI Object life cycle behaviour conforms to the the protocol
statemachines2) Use case scenarios can be realized by the system
! use sequence diagrams to show this
Use Case Diagram Library System
Detail Use Case Check outI Use Case Name: Check outI Summary: Checks out a book from the libraryI Actors: UserI Preconditions: trueI Basic course of events
I 1. User scans his library cardI 2. User repeats
I 2.1 select check outI 2.2 scan the bookI 2.3 System confirms loan
I Alternative pathsI 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 systemI . . .
I PostconditionsI Book is loaned by the user
Implementation: Component Diagram (synchronousversion)
<<inter face>>LibraryInterface
scanLibraryCard()checkOutscanBook()checkIn...
LibraryInterface
LibrarySystem
Implementation: Protocol State Machine (PSM):Library Interface (synchronous version)
More functionality
...
/[result = false]
/[result = true]
check in
scanBook/[result = (false,'too many books') or result = (false,'overdue books') or
result = true]
check outscanLibraryCard
Implementation: Class Diagram
{pre: bor.canBorrow() post: dueDate = Date.today + 3 weeks and bor.books->containing(self) }
{body: books->size <= 5 and books->forAll(b | not(b.overdue))}
<<inter face>>LibraryInterface
scanLibraryCard()checkOutscanBook()checkIn...
{inv: overdue iff dueDate <> null and today > dueDate}
BookoverduedueDateregister()deregister()checkout()checkin()
BorrowercanBorrow()
Libraryscan library card()check outscan book()check in...
0..5*
user
*
Implementation: Object Life Cycle State Machine(LSM): Class Library
user ok
can borrow?
...
...
book scannedUser scannedIdle
[not cb] / return "book can't be borrowed"
scanBook(l)
[cb] / b.checkOut(); return "ok"
/ cb := bor.canBorrow()
[users->contains(l)]
[not users->contains(l)] / return err-msg
scanLibraryCard (l)
Implementation: LSM Class Book
registered
not registered
overdue
borrowedavailable
deregister
register
check in
check in
when Today > dueDate
checkOut(b) / dueDate := today + 3 weeks; b.books := b.books->containing(tself)
Use Case success scenario realisationsd: borrow book success
scan librarycard(bor)
true
checkOut()
scan book(b)
canBorrow()
isOverdue()
false
loop
true
checkout(bor)
true
true
loop
UserLibrary bor:Borrower
[b in bor.books]
b1:Book b2:Book
Use Case fail realisation
sd: borrow book failure: overdue books
scanLibraryCard(bor)
true
checkOut()
scanBook(b)
canBorrow()
isOverdue()
true
loop
false
false
loop
UserLibrary bor:Borrower
[b in bor.books]
b1:Book b2:Book
Checking that a use case realization is correct
1 The sequence diagram shows correctly the user interactionof the use case scenario
2 All messages appear in the respective interfaces of theclass
3 All messages are admissiable according to the protocolstate machines (PSM)
4 All message sequences are admissible according to thebehaviour specification
1) User interactions
I Basic course of eventsI 1. User scans his library cardI 2. User repeats
I 2.1 select check outI 2.2 scan the bookI 2.3 System confirms loan
sd: borrow book success
scan librarycard(bor)
true
checkOut()
scan book(b)
canBorrow()
isOverdue()
false
loop
true
checkout(bor)
true
true
loop
UserLibrary bor:Borrower
[b in bor.books]
b1:Book b2:Book
2) Messages belong to interfaces
{pre: bor.canBorrow() post: dueDate = Date.today + 3 weeks and bor.books->containing(self) }
{body: books->size <= 5 and books->forAll(b | not(b.overdue))}
<<inter face>>LibraryInterface
scanLibraryCard()checkOutscanBook()checkIn...
{inv: overdue iff dueDate <> null and today > dueDate}
BookoverduedueDateregister()deregister()checkout()checkin()
BorrowercanBorrow()
Libraryscan library card()check outscan book()check in...
0..5*
user
*
sd: borrow book success
scan librarycard(bor)
true
checkOut()
scan book(b)
canBorrow()
isOverdue()
false
loop
true
checkout(bor)
true
true
loop
UserLibrary bor:Borrower
[b in bor.books]
b1:Book b2:Book
3) Messages conform to the PSM (LibraryInterface)Class Library implements the LibraryInterface
More functionality
...
/[result = false]
/[result = true]
check in
scanBook/[result = (false,'too many books') or result = (false,'overdue books') or
result = true]
check outscanLibraryCard
sd: borrow book success
scan librarycard(bor)
true
checkOut()
scan book(b)
canBorrow()
isOverdue()
false
loop
true
checkout(bor)
true
true
loop
UserLibrary bor:Borrower
[b in bor.books]
b1:Book b2:Book
4a) Messages follow the LSM for class Library
user ok
can borrow?
...
...
book scannedUser scannedIdle
[not cb] / return "book can't be borrowed"
scanBook(l)
[cb] / b.checkOut(); return "ok"
/ cb := bor.canBorrow()
[users->contains(l)]
[not users->contains(l)] / return err-msg
scanLibraryCard (l)
sd: borrow book success
scan librarycard(bor)
true
checkOut()
scan book(b)
canBorrow()
isOverdue()
false
loop
true
checkout(bor)
true
true
loop
UserLibrary bor:Borrower
[b in bor.books]
b1:Book b2:Book
4b) Messages follow the LSM for class Book
registered
not registered
overdue
borrowedavailable
deregister
register
check in
check in
when Today > dueDate
checkOut(b) / dueDate := today + 3 weeks; b.books := b.books->containing(tself)
sd: borrow book success
scan librarycard(bor)
true
checkOut()
scan book(b)
canBorrow()
isOverdue()
false
loop
true
checkout(bor)
true
true
loop
UserLibrary bor:Borrower
[b in bor.books]
b1:Book b2:Book
Alternative: Construct the sequence diagram from theLSM’s