02291: System Integration

Transcription

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

2 Contents Sequence Diagrams Design Validation: Use Case Realization

3 Example: Interaction Diagrams Sequence Diagram Communication Diagram

4 Example Sequence Diagram

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

6 Example Interaction Frames

7 Interaction Frame Operators I

8 Nested sequence diagrams

9 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

10 System design: 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 selects check out 3. User scans the book 4. System confirms loan Alternative paths... Postconditions Book is loaned by the user

11 Use Case scenarios as Sequence Diagrams Main scenario

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

13 Contents Sequence Diagrams Design Validation: Use Case Realization

14 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

15 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

16 Use Case Diagram Library System

17 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 selects check out 3. User scans the book 4. 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

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

19 Implementation: Protocol State Machine /[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

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

21 Implementation: Behaviour 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

22 Implementation: Behaviour Book registered check out(b) / duedate := today + 3 weeks; b.books := b.books->containing(self) not registered register available check in borrowed at duedate /overdue := true deregister check in / overdue := false overdue

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

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

25 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

26 1) User interactions Basic course of events 1. User scans his library card 2. User selects check out 3. User scans the book 4. System confirms loan

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

28 3) Messages conform to the PSM /[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]

29 4) Messages follow the behaviour specification... 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]

30 4) Messages follow the behaviour specification registered check out(b) / duedate := today + 3 weeks; b.books := b.books->containing(self) not registered register available check in borrowed at duedate /overdue := true deregister check in / overdue := false overdue loop [foreach b' in bor->books]