02291: System IntegrationWeek 7

Hubert Baumeisterhuba@dtu.dk

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