02291: System Integration

Transcription

1 02291: System Integration Week 7 Hubert Baumeister hub@imm.dtu.dk DTU Compute Technical University of Denmark Spring 2016

2 Contents Components (part III) Sequence Diagrams Design Validation: Use Case Realization

3 Synchronous version of the Bank

4 Closer View Port Bank to ATM (BA): Provided interface Port ATM to Bank (AB): Required interface

5 Protocol for interfaces BankToAtm and BankToATMSync Asynchronous version of the protocol state machine BankToAtm {protocol} withdraw(i,a)/[^withdrawok] withdraw(i,a)/[^withdrawnotok] Synchronous version of the protocol state machine BankToATMSync. {protocol} withdraw(i,a)/[result = true] withdraw(i,a)/[result = false] Idle verifypin(p)/[^pinok] Withdraw Idle verifypin(p)/[result = true] Withdraw verifypin(p)/[^pinnotok] verifypin(p)/[result = false]

6 Bank component with Implementation Bank BankToATMPort «delegate» «delegate» ClearingCompanyToBank * * BankToATM Bank Account Customer

7 Detailed Class Diagram for the Bank Component «interface» BankToATMSync verifypin(acct,pin): bool withdraw(acct,amt): bool BankToATMPort verifypin(acct,pin): bool withdraw(acct,amt): bool * Account number : IBAN balance : int withdraw(amount:int): bool * 1..* «interface» ClearingCompanyToBank verifypin(acct,pin): bool 1 cc * Bank name: String... accountfor(acct): Account verifypin(acct,pin) withdraw(acct,amount) 1 b * c * Customer name address...

8 Behaviour Design BankToATMPort Behaviour of class BanktToATMPort Behaviour of class Bank

9 Protocol conformance Protocol for the interface BankToATMSync BankToATMSync. {protocol} withdraw(i,a)/[result = true] withdraw(i,a)/[result = false] Idle verifypin(p)/[result = true] Withdraw verifypin(p)/[result = false] BankToATMPort lifecycle state machine

10 Summary: Components Ports in components have provided and required interfaces Each interface: Protocol state machine Implementing Components 1) Subcomponents delegating ports 2) Set of classes Classes implement provided interface of a port Classes use the required interface of a port Lifecycle state machine and protocol state machine have to conform to each other

11 Contents Components (part III) Sequence Diagrams Design Validation: Use Case Realization

12 Example: Interaction Diagrams Sequence Diagram Communication Diagram

13 Example Sequence Diagram

14 Arrow types a:a b:b async call sync call return

15 Arrow types a:a b:b

16 Example Interaction Frames

17 Interaction Frame Operators I

18 Nested sequence diagrams

19 Usages of sequence diagrams Abstract: show the execution (i.e. exchange of messages) of a system Concrete Design (c.f. CRC cards) Visualize program behaviour Visualize model execution use case realization

20 System design: Detailed Use Case Check out Use Case Name: Check out Summary: Checks out a book from the library Actors: User Preconditions: true Basic course of events 1. User scans his library card 2. User repeats 2.1 select check out 2.2 scan the book 2.3 System confirms loan Alternative paths... Postconditions Book is loaned by the user

21 Use Case scenarios as Sequence Diagrams Main scenario loop

22 System design for the main use case scenario loop [foreach b' in bor->books]

23 Contents Components (part III) Sequence Diagrams Design Validation: Use Case Realization

24 UML Models UML Model = one system UML Diagrams = view on the same system UML diagrams depend on each other Use case diagram(s) Detailed use cases Component diagram(s) Protocol statemachines Class diagram(s) Object life cycle state machines

25 Dependence between models: Consistency conditions 1) Components are implemented by class diagrams Provided interfaces in ports have to be implemented by classes 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

26 Use Case Diagram Library System

27 Detail Use Case Check out Use Case Name: Check out Summary: Checks out a book from the library Actors: User Preconditions: true Basic course of events 1. User scans his library card 2. User repeats 2.1 select check out 2.2 scan the book 2.3 System confirms loan Alternative paths 3.a. User has overdue books System rejects loan with message overdue books 3.b User has more then 5 books on loan System rejects loan with message too many books 1.a User is not registered with the system... Postconditions Book is loaned by the user

28 Implementation: Component Diagram LibrarySystem LibraryInterface «interface» LibraryInterface scan library card() check out scan book() check in...

29 Implementation: Protocol State Machine (PSM): Library Interface /[result = false] scan book/ [result = (false,'too many books') or result = (false,'overdue books') or result = true] scan library card /[result = true] check out check in... More functionality

30 Implementation: Class Diagram «interface» LibraryInterface scan library card() check out scan book() check in... user Library scan library card() check out scan book() check in... * Borrower canborrow() * {inv: overdue iff duedate <> null and today > duedate} Book overdue duedate register() deregister() checkout() checkin() 0..5 {body: books->size <= 5 and books->forall(b not(b.overdue))} {pre: bor.canborrow() post: duedate = Date.today + 3 weeks and bor.books->containing(self) }

31 Implementation: Object Life Cycle State Machine (LSM): Class Library... Idle scan library card (l) User scanned [users->contains(l)]/ return true user ok check out book scanned [not users->contains(l)] / return false scan book(s)/ (cb,msg) := bor.canborrow() after 10min [not cb] / return (false,msg) can borrow? [cb] / book := books->select(b b.signature = s); book.check_out(); return true

32 Implementation: LSM Class Book registered check out(b) / duedate := today + 3 weeks; b.books := b.books->containing(self) not registered register available [not overdue] check in borrowed at duedate deregister check in overdue [overdue]

33 Use Case success scenario realisation loop [foreach b' in bor->books]

34 Use Case fail realisation loop [foreach b' in bor->books]

35 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

36 1) User interactions Basic course of events 1. User scans his library card 2. User repeats 2.1 select check out 2.2 scan the book 2.3 System confirms loan

37 2) Messages belong to interfaces «interface» LibraryInterface scan library card() check out scan book() check in... Library scan library card() check out scan book() check in... user * Borrower canborrow() * {inv: overdue iff duedate <> null and today > duedate} {pre: bor.canborrow() post: duedate = Date.today + 3 weeks and bor.books->containing(self) } Book overdue duedate register() deregister() checkout() checkin() 0..5 {body: books->size <= 5 and books->forall(b not(b.overdue))} loop [foreach b' in bor->books]

38 3) Messages conform to the PSM (LibraryInterface) Class Library implements the LibraryInterface /[result = false] scan book/ [result = (false,'too many books') or result = (false,'overdue books') or result = true] scan library card /[result = true] check out check in... More functionality loop [foreach b' in bor->books]

39 4a) Messages follow the LSM for class Library... Idle scan library card (l) User scanned [users->contains(l)]/ return true user ok check out book scanned [not users->contains(l)] / return false scan book(s)/ (cb,msg) := bor.canborrow() after 10min [not cb] / return (false,msg) can borrow? [cb] / book := books->select(b b.signature = s); book.check_out(); return true loop [foreach b' in bor->books]

40 4b) Messages follow the LSM for class Book registered check out(b) / duedate := today + 3 weeks; b.books := b.books->containing(self) not registered register available [not overdue] check in borrowed at duedate deregister check in overdue [overdue] loop [foreach b' in bor->books]