02291: System Integration Week 7 Hubert Baumeister

(1)

02291: System Integration

Week 7 Hubert Baumeister

huba@dtu.dk

DTU Compute Technical University of Denmark

Spring 2018

(2)

Recap

I Last Week

I Life cycle state machines (LSM’s): Describes the life cycle of an object

I Protocol state machines (PSM’s): Describes the

communication protocol for provided/required interface of a component

I Today:

I Sequence diagrams

I Testing your model: Use case realizations

(3)

Contents

Components and Synchronous Communication Sequence Diagrams

Design Validation: Use Case Realization

(4)

Synchronous– vs Asynchronous Calls:

Asynchronous Call

public 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 Call

public class Atm {

// From the user interface

public void enterPin(String pin) { boolean pinOk = bank.verifyPin(pin); } }

(5)

Asynchronous Call

public 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 Call

public class Atm {

// From the user interface

public void enterPin(String pin) { boolean pinOk = bank.verifyPin(pin);

} }

(6)

Synchronous version of the Bank

(7)

Closer View

PortBank to ATM (BA):

Provided interface ^I ^PortATM to Bank(AB):

Required interface

(8)

Protocol for interfaces BankToAtm and BankToATMSync

I Asynchronous version of the protocol state machine

withdrawing withdraw

verifying idle

sm: BankToAtm {protocol}

/ [ ^ p i n N o t O k ]

/ [ ^ w i t h d r a w O k ] /[^withdrawNoOk]

withdraw(i,a) / [ ^ p i n O k ]

verifyPin(p)

I Synchronous version of the 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]

(9)

Bank component with Implementation

Bank

Customer Account

ClearingCompanyToBank * BankToATM

«delegate»

BankToATMPort

*

(10)

Detailed Class Diagram for the Bank Component

Bank name: String ...

accountFor(acct): Account verifyPin(acct,pin) withdraw(acct,amount)

«interface»

ClearingCompanyToBank verifyPIN(acct,pin): bool

Customer n a m e address ...

Account number : IBAN balance : int

withdraw(amount:int): bool ...

BankToATMPort verifyPIN(acct,pin): bool withdraw(acct,amt): bool

1 cc *

1..*

c *

*

«interface»

BankToATMSync verifyPIN(acct,pin): bool

withdraw(acct,amt): bool *

1 b

(11)

Behaviour Design BankToATMPort

I Behaviour of class BanktToATMPort

I Behaviour of class Bank

(12)

Protocol conformance

Protocol for the interface BankToATMSync

BankToATMSync. {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

(13)

Summary: Components

I Ports in components have

I provided and required interfaces

I Each interface:Protocol state machine

I Implementing Components

1) Subcomponents delegating ports 2) Set of classes

I Classes implement provided interface of a port

I Classes use the required interface of a port

I Lifecycle state machine and protocol state machine have to conform to each other

(14)

Contents

(15)

Example: Interaction Diagrams

Sequence Diagram

Communication Diagram

(16)

Example Sequence Diagram

(17)

Creation and deletion of participants

(18)

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

(19)

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

(20)

ATM to Bank: Asynchronous Version

(21)

ATM to Bank: Synchronous Version

(22)

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();

} }

(23)

Realisation with Interaction Frames

(24)

Interaction Frame Operators I

(25)

Nested sequence diagrams

(26)

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

(27)

System design: Detailed 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 repeats

I 2.1 select check out

I 2.2 scan the book

I 2.3 System confirms loan I Alternative paths

. . .

I Postconditions

I Book is loaned by the user

(28)

Use Case scenarios as Sequence Diagrams

Main scenario

sd: borrow book success

scanLibraryCard(bor) true

checkOut()

scanBook(b) true loop

User

Library

(29)

System design for the main use case scenario

scan library card(bor)

true

checkOut()

scan book(b)

canBorrow()

isOverdue() false loop

true

checkout(bor) true true

loop User

Library bor:Borrower

[b in bor.books]

b1:Book b2:Book

(30)

Contents

(31)

UML Models

I Many diagrams, but onlyone model

I Different Views on the system

I Functionality: Use Case diagram, state machines, activity diagram, . . .

I Structure: Component diagram, Class diagram

I Validation: Interaction diagram

(32)

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

(33)

Use Case Diagram Library System

(34)

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 2. User repeats

I 2.2 scan the book

I 2.3 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

(35)

Implementation: Component Diagram (synchronous version)

< < i n t e r f a c e > >

LibraryInterface scanLibraryCard() checkOut scanBook() checkIn ...

LibraryInterface

LibrarySystem

(36)

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 out scanLibraryCard

(37)

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))}

< < i n t e r f a c e > >

{inv: overdue iff dueDate <> null and today > dueDate}

Book overdue dueDate register() deregister() checkout() checkin()

Borrower canBorrow()

Library scan library card() check out scan book() check in ...

* 0..5 user

*

(38)

Implementation: Object Life Cycle State Machine (LSM): Class Library

user ok

can borrow?

...

book scanned User scanned

Idle

[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)

(39)

Implementation: LSM Class Book

registered

not registered

overdue borrowed available

deregister register

check in

when Today > dueDate checkOut(b) / dueDate := today + 3 weeks; b.books := b.books->containing(tself)

(40)

Use Case success scenario realisation

true

checkOut()

scan book(b)

canBorrow()

true

loop User

[b in bor.books]

b1:Book b2:Book

(41)

Use Case fail realisation

sd: borrow book failure: overdue books

scanLibraryCard(bor) true

checkOut()

scanBook(b)

canBorrow()

isOverdue() true loop

false false

loop User

[b in bor.books]

b1:Book b2:Book

(42)

Checking that 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

(43)

1) User interactions

I 2. User repeats

I 2.2 scan the book

I 2.3 System confirms loan

true

checkOut()

scan book(b)

canBorrow()

true

loop User

[b in bor.books]

b1:Book b2:Book

(44)

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))}

< < i n t e r f a c e > >

{inv: overdue iff dueDate <> null and today > dueDate}

Book overdue dueDate register() deregister() checkout() checkin()

Borrower canBorrow()

Library scan library card() check out scan book() check in ...

* 0..5 user

*

true

checkOut()

scan book(b) canBorrow()

true checkout(bor)

true true

loop User

[b in bor.books]

b1:Book b2:Book

(45)

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 out scanLibraryCard

true

checkOut()

true checkout(bor)

true true

loop User

[b in bor.books]

b1:Book b2:Book

(46)

4a) Messages follow the LSM for class Library

user ok

can borrow?

...

book scanned User scanned

Idle

[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)

true

checkOut()

true checkout(bor)

true true

loop User

[b in bor.books]

b1:Book b2:Book

(47)

4b) Messages follow the LSM for class Book

registered

not registered

overdue borrowed available

deregister register

check in

when Today > dueDate checkOut(b) / dueDate := today + 3 weeks; b.books := b.books->containing(tself)

true

checkOut()

true checkout(bor)

true true

loop User

[b in bor.books]

b1:Book b2:Book

(48)

Alternative: Construct the sequence diagram from the LSM’s