Course System Integration Deriving the use case realization

Size: px

Start display at page:

Download "Course System Integration Deriving the use case realization"

Clifton Douglas
5 years ago
Views:

1 Course System Integration Deriving the use case realization Hubert Baumeister March 21, 2017 The goal of the use case realization is to show that the use cases can be executed using the design consisting of components, classes, class, protocol state machines (PSMs) and life cycle state machines (LSM s). Using the example of the library, I have shown how to verify that a given sequence diagram represents the execution of a use case in the model of the library, i.e., is a use case realization. The slides of week 7 contain the list of criteria to check for and an example. However, instead of creating the sequence diagram directly and then checking that it is a realization, it is probably more efficient to construct the sequence diagram based on the model. In this example, I am going to construct the sequence diagram from the main scenario of the Check Out use case. 1. user scans his library card 2. user repeats (a) select (b) scan the book (c) system confirms the loan The first interaction of the user with the system is user scans his library card. In our case, the user interacts with the system through the LibraryInterface, which is part of the application layer. The LibraryInterface contains a method card, so in the first step, the user will send the message card to the system. 1

2 LibrarySystem LibraryInterface «interface» LibraryInterface card() scan book() check in... The problem is, which object of which class will receive the message? The object is of the class that implements LibraryInterface in component LibrarySystemm, which is class Library. «interface» LibraryInterface card() scan book() check in... user Library card() 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) } So we can draw our first interaction in the sequence diagram: 2

3 Now we have to look at how l of class Library reacts to that message. To do this, we have to look at the LSM of the Library class.... Idle card (l) scanned [users->contains(l)]/ return user ok / return book scanned [not users->contains(l)] / return false after 10min [not cb] / return (false,msg) scan book/ (cb,msg) := bor.canborrow() can borrow? [cb] / book := books->select(b b.signature = s); book.check_out(); return We assume that the LSM is in the idle state. There it can react to the event card(l). Depending on whether the library card is of an existing user, the state machine does different things. In our case, we are in the main scenario of the use case, i.e., we assume the user is registered in the library. Thus we move to state user ok and return, which is added to the sequence diagram. 3

4 In the next step, the LSM of the Library class waits for the event from the user. This is also the next step in the use case scenario: 2a) select and a method of the interface LibraryInterface. 4

5 After receiving from the user, the LSM returns control to the user without returning a value, and the state machine moves to state book scanned and waits for scan book. This again comes from the user as part of the use case: 2b) scan the book. 5

6 scan book When the Library LSM receives scan book, it sends out to the borrower the message canborrow. In the sequence diagram, we add a life line for the borrower and draw a line from Library to Borrower. 6

7 bor:borrower scan book canborrow Now we have to look at the LSM for the Borrower class, to see how the borrower reacts to the canborrow message. Idle canborrow(b) can borrow? [else]/ return [books->size >= 5] / return false [books->exists(b b.isoverdue()] / return false As we are executing the main scenario of the Check Out use case, where the user can borrow a book, the LSM takes the else transition and returns and control passes back to the LSM of the Library class. 7

8 bor:borrower scan book canborrow The next step in the Library LSM is to send the book the message check_out in the transition from can borrow? to state user ok 8

9 bor:borrower book:book scan book canborrow check_out To see what happens when check_out is executed, we have to look at the LSM of the Book class. registered (b) / duedate := today + 3 weeks; b.books := b.books->containing(self); return register/return not registered available [not overdue] check in/return borrowed at duedate deregister/return check in/return overdue [overdue] Here we assume that the book is already registered and the book is in state available [not overdue]. When the book receives check_out, it will set the due date and add the book to the books borrowed by the user and then return. Then we can continue the transition from can borrow? to user ok in the Library LSM and return. 9

10 bor:borrower book:book scan book canborrow check_out Note that the return value from the scan book message corresponds to the step 2c) system confirms the loan in the use case scenario. What is still missing is, that the sequence diagram plays together with the PSM of the interface LibraryInterface. We can either check this for this scenario or check that in general the LSM of class Library is a refinement of the PSM of the interface LibraryInterface which class Library implements. Meaning, among others, that the LSM is enabled for all the events that the PSM is enabled. 10

02291: System Integration

02291: System Integration Week 7 Hubert Baumeister hub@imm.dtu.dk DTU Compute Technical University of Denmark Spring 2013 Contents Sequence Diagrams Design Validation: Use Case Realization Example: Interaction