1. 1 CMPT 275 Phase: Design

2. Janice Regan, 2008 2 Map of design phase DESIGN HIGH LEVEL DESIGN Modularization User Interface Module Interfaces Data Persistance Subsystem User Manual architecture LOW LEVEL DESIGN Classes Class Interfaces Interaction Diagrams Implementation Product or system Design Class Design

3. Janice Regan, 2008 3 Map of design phase DESIGN HIGH LEVEL DESIGN Modularization User Interface Module Interfaces Data Persistant Subsystem User Manual architecture LOW LEVEL DESIGN Classes Interaction Diagrams Class Interfaces Implementation

4. Janice Regan, 2008 4 Design phase  High level design (product or system design)  Architecture  Definition of subsystems  Description of interaction of subsystems  Low level design (design of classes/objects)  Attributes  Data structures  Methods  Algorithms

5. 5 Sub-Phase Low Level Design Sequence Diagrams

6. Janice Regan, 2008 6 Low Level Design  Objective of Low Level Design  Refine representation (models) of software system to a level of detail that will allow resulting representation to be used as a blueprint for implementation and unit test planning phases

7. Janice Regan, 2008 7 Modeling at different phases Requirements analysis High Level Design Low Level Design DynamicStatic 1. System Context Diagram 3. Class Diagram 2. Informal Scenarios 4. Use cases 5. Use cases Diagrams 7. Architecture (from 1,4,5,6) 6. Scenarios 9. Refined use cases (from 4,7, 8) 8. Analyze data persistence 13. Sequence Diagrams and collaboration diagrams (from 12) 12. Refined use cases and scenarios (from 9) 11. Refined Class Diagram including attributes and methods (from 3, 12, 13)

8. Janice Regan, 2008 8 Interaction Diagrams  Model dynamic aspects of the software system by specifying the interaction among objects to produce a particular behaviour  For each use case  Show object interaction  Show how software system realizes a use case  Help identify object operations (methods)

9. Janice Regan, 2008 9 Interaction Diagrams  Two types of interaction diagrams are defined in UML  Collaboration diagram: emphasizes the structural organization of objects that send and receive messages  Sequence diagram: emphasizes the time ordering of the messages passed between objects  However, both diagrams are not computationally complete; they are not algorithms! -> They do not define the behaviour

10. Janice Regan, 2008 10 Sequence Diagram: Format - 1 1. Initiating actor at top left … 2. … followed by boxes representing objects 3. Synchronous Message (wait for reply then continue) 4. Asynchronous Message (continue without waiting for reply) 5. Implicit return at end of activation initiating actor : Class or object : Class Module Name or

11. Janice Regan, 2008 11 UML Notational Elements of Interaction Diagrams Note:  An object is distinguished from a class in UML notation by the colon  An object name is optional  Multiple objects of same class may participate in behaviour  A link between 2 objects implies an association between their classes in Class Diagram

12. Janice Regan, 2008 12 Sequence Diagram: Format - 2 6. Life line indicating when object is available 7. Activation box indicates when object is active (receiving messages, doing some activity (although the diagram may not specify this), sending messages object : Class

13. Janice Regan, 2008 13 Sequence Diagram: Format - 3 8. Labels on leftmost part of diagram Indicate actions such as  other use cases being initiated  actor interacting with the UI These actions are not expressed by an arrow in the diagram since they do not represent inter- module communication Profile altered Identify use case executed Actor Name

14. Janice Regan, 2008 14 Representing messages Synchronous Message (wait for reply then continue), reply implicit, will return returnvalue1 at end of activation box started by the message, not shown in diagram Synchronous Message (wait for reply then continue), reply explicitly shown, will return returnvalue1 at end of activation box started by the message, return message illustrated returnvalue1 = message1(parameter1) message1(parameter1) message1(returnvalue1)

15. Janice Regan, 2008 15 Messages and returns object1 : Class1object2 : Class2 returnvalue1 = message1(parameter1) message2(parameter2) message2(returnvalue2) returnvalue3 = message3(parameter3) Message can be an actual message or it may be an invocation of the methods of the destination class

16. Janice Regan, 2008 16 Sending messages conditionally object1 : Class1object2 : Class2 [parameter1 > 23] returnvalue1 = message1(parameter1) Message is sent only if the condition in the square brackets is true. For this example the condition in the square brackets requires the value of parameter1 > 23

17. Janice Regan, 2008 17 Sending messages repeatedly object1 : Class1object2 : Class2 * [parameter1 > 23] returnvalue1 = message1(parameter1) Message is sent if the condition in the square brackets is true, the message is sent repeatedly until the condition in the square brackets becomes false. Usually used to send the same message to many objects

18. Janice Regan, 2008 18 Reflexive message object1 : Class1 When an object sends a message to itself, this message is a reflexive message.

19. Janice Regan, 2008 19 Sequence Diagram: Format - 3 7. Creation 8. Destruction object : Class > object : Class > object : Class

20. Janice Regan, 2008 20 Create and destroy object1 : Class1 object2 : Class2 > Returnvalue1 = message1(parameter1) object3 : Class3 > Returnvalue2 = message2(parameter2) >

21. Janice Regan, 2008 21 Sequence Diagram: Format - 4 9. Algorithm details on left most part of diagram 10. Scenario, Use Case name and functional requirement # Algorithm Actor Name

22. Janice Regan, 2008 22 Sequence Diagram: How to!  Objects that exist initially are lined up along the top of the diagram beside the actor  When object is created later, its box appears further down, at the time when it is created  Actor initiates interaction via GUI this is the first message sent  Reception of a message by an object causes one of its methods to be executed.

23. Janice Regan, 2008 23 Refined Scenario #1  Use Case Name: CheckInResource (#7)  Scenario: Student Patron Paul returns a book on time.  Preconditions:  Librarian Eva has successfully gained access to the LMS.  LMS is ready to go (DB has been populated, network is up, and LMS has been initialized).  LMS screen with Check menu is displayed.

24. Janice Regan, 2008 24 Refined Scenario #1  Main flow of events: 1. Student Patron Paul comes up to the librarian counter to return the Quantum Physics book he borrowed last week. 2. Eva the Librarian chooses CheckInResource option from the LMS screen by selecting the In command option under the Check menu. 3. A window representing a Check In Form is then displayed.

25. Janice Regan, 2008 25 Refined Scenario #1  Main flow of events (cont): 4. Eva takes the book Paul is handing to her and types in its Dewey call number in the appropriate text field then presses the "Accept" button to commit the entry. 5. The Dewey call number for the book was entered successfully and it was a valid call number, information about the Quantum Physics book and the borrowing patron is retrieved from the Database and displayed on the Check In screen.

26. Janice Regan, 2008 26 Refined Scenario #1  Main flow of events (cont):  Since Student Patron Paul is returning the Quantum Physics book before its due date, there is no overdue charge. Also, no one is currently requesting the Quantum Physics book.  LMS completes the check-in process by  changing the status of the book to “reshelve“,  canceling its “due date” and “date of loan“,  updating its “date of return“ to today,  Clearing the borrowing patron ID,  removing the Quantum Physics book from the Student Patron Paul’s list of borrowed resources.

27. Janice Regan, 2008 27 Refined Scenario #1  Main flow of events (cont):  LMS updates the records for the Quantum Physics book and the borrowing Student Patron Paul in the Database.  LMS updates the screen showing the newly checked-in book along with the updated dates.  Eva verifies by looking at the screen that the book has been checked in properly, then presses the “Done” button.

28. Janice Regan, 2008 28 Refined Scenarios #1  Postconditions:  Student Patron Paul’s record is now showing that he is no longer borrowing the Quantum Physics book. The Quantum Physics book has now a status of “reshelve”, today's date as a “date of return”, “date of loan” has been cleared and so has the “due date”.

29. Janice Regan, 2008 29 Sequence Diagram - 0 Librarian : LibrarySystem QPBook : Book Paul : Student QPBook := getResource( call # ) db : LibraryDB paul := getPatron( patronId ) QPBook := create( book, db ) paul := create ( student, db ) name := getName( ) expiryDate := getExpiryDate( ) patronId := getBorrowingPatronId( ) title := getTitle( ) author := getAuthor( ) loanDate := getLoanDate( ) dueDate := getDueDate( ) status := getStatus( ) : GUI checkIn ( Dewey call # ) Select (checkInPage ) Display (checkInPage ) checkIn ( Dewey call # )

30. Janice Regan, 2008 30 checkIn( Dewey call # ) Sequence Diagram - 1 Librarian : LibrarySystem QPBook : Book Paul : Student QPBook := getResource( call # ) db : LibraryDB paul := getPatron( patronId ) QPBook := create( book, db ) paul := create ( student, db ) name := getName( ) expiryDate := getExpiryDate( ) patronId := getBorrowingPatronId( ) title := getTitle( ) author := getAuthor( ) loanDate := getLoanDate( ) dueDate := getDueDate( ) status := getStatus( )

31. Janice Regan, 2008 31 Sequence Diagram – 2 A Librarian ok := update( QPBook ) checkIn( call # ) ok := checkIn( date ) update( paul ) Remove QPBook from “list of borrowed resources” : LibrarySystem db : LibraryDB QPBook : Book Paul : Student update( ok ) checkIn (ok ) Display(startpage) display( checkInPage ) Press done confirm Set status = “reshelve” Set “loan date” = 0 Set “due date” = 0 Set “return date” = “today” (date) Set “borrowing patron id” = 0

32. Janice Regan, 2008 32 Consider other scenarios  What if librarian Eva decides not to press done and confirm the check in of the book but chooses to press cancel and terminate the interaction instead.  Look at sequence diagram 2A, what needs to change for this new scenario?  Pressing cancel implies that nothing in the database will be changed. If cancel were pressed rather than done we would have to undo the changes to the database.

33. Janice Regan, 2008 33 Consider other scenarios  What if librarian Eva decides not to press done and confirm the check in of the book but chooses to press cancel and terminate the interaction instead.  If cancel were pressed rather than done we would have to undo the changes to the database.  This is clearly extra work, want to ask if done before the database is updated, then only update if done is pressed.  Need to refine the use case and the interaction diagram to handle both scenarios

34. Janice Regan, 2008 34 Refined Scenario #1  Main flow of events:  Since Student Patron Paul is returning the Quantum Physics book before its due date, there is no overdue charge. Also, no one is currently requesting the Quantum Physics book.  LMS completes the check-in process by  changing the status of the book to “reshelve“,  canceling its “due date” and “date of loan“,  updating its “date of return“ to today,  Clearing the borrowing patron ID,  removing the Quantum Physics book from the Student Patron Paul’s list of borrowed resources.

35. Janice Regan, 2008 35 Refined Scenario #1  LMS updates its internal records for the Quantum Physics book and the borrowing Student Patron Paul.  LMS updates the screen showing the newly checked-in book along with the updated dates (from its internal records).  Eva verifies by looking at the screen that the book has been checked in properly, then presses the “Done” button.  The changes to the records for the Quantum Physics book and the borrowing Student Patron Paul are updated in the database.

36. Janice Regan, 2008 36 Updated Sequence Diagram – 2 A Librarian ok := update( QPBook ) [flag = done] checkIn( call # ) [flag = done] ok := checkIn( date ) update( paul ) Set status = “reshelve” Set “loan date” = 0 Set “due date” = 0 Set “return date” = “today” (date) Set “borrowing patron id” = 0 Remove QPBook from “list of borrowed resources” : LibrarySystem db : LibraryDB QPBook : Book Paul : Student update( ok ) checkIn (ok ) Display(startpage) display( checkInPage ) Press done or cance l verify( flag )

37. Janice Regan, 2008 37 Sequence Diagram – 2 B Librarian ok := update( QPBook ) ok := checkIn( call # ) ok := update( paul ) Set status = “reshelve” Set “loan date” = 0 Set “due date” = 0 Set “return date” = “today” (date) Set “borrowing patron id” = 0 Remove QPBook from “list of borrowed resources” : LibrarySystem db : LibraryDB QPBook : Book Paul : Student [flag = done] ok := checkIn( date ) display( checkInPage ) verify( flag ) Press done or cance l Display(startpage)

38. Janice Regan, 2008 38 Sequence Diagram – 2 C Librarian : LibrarySystem db : LibraryDB ok := update( QPBook ) ok := checkIn( call # ) ok := checkIn( date ) ok := update( paul ) Set status = “reshelve” Set “loan date” = 0 Set “due date” = 0 Set “return date” = “today” (date) Set “borrowing patron id” = 0 Remove QPBook from “list of borrowed resources” QPBook : Book Paul : Student display( checkInPage ) Press done or cance l verify( flag ) Display(startpage)

39. Janice Regan, 2008 39  Goal: To illustrate dynamic relationships between subsystems, and to begin to define what the interfaces of each must be  Help us understand what functionality must reside in which subsystem  Will eventually allow subsystems to be implemented separately and in parallel Inter-Subsystem Interface Description

40. Janice Regan, 2008 40  Describe interactions …  Between software system and human users  Between subsystems of the software system  Between distributed processes (encompassed in a subsystem) over a network  Between software system and solutions for data persistence (e.g. database management systems)  Can be seen as public interface of module Inter-Subsystem Interface Description

41. Janice Regan, 2008 41 Modelling Inter-Subsystem Interaction  Interaction diagrams (Sequence, Collaboration)  Model dynamic aspects of the software system  Specify interaction among “entities”  Can be refined during low level design  Sequence Diagram:  Emphasizes time ordering of interactions  Collaboration Diagram  Emphasizes structural organization of the objects that are interacting.

42. Janice Regan, 2008 42 Sequence Diagram  1 sequence diagram per use case  Specify specialized communication protocol such as  Common Gateway Interface (CGI) protocol  Hypertext Transport Protocol (HTTP)

43. Janice Regan, 2008 43 Web Server Application Database System Context Diagram USER

44. Janice Regan, 2008 44 Architecture Database interface Here the database is available to the Application. In this representation the Database is not part of the application but an external software product being used by the application

45. Janice Regan, 2008 45 Use case for Web application  Use case name: Edit Profile (functional requirement #3)  Initiating actor: User  Preconditions: DB populated, system running, User reached Web site.  Main flow of events:  The User requests to edit her/his profile by pressing the Edit Profile button on the Web page.  The User validly identifies her/himself to the system through the Identify use case. (identify will shown as an > in use case diagram)  The User’s profile is retrieved from the Database and is displayed on the web page. The User updates her/his profile information. (specify information) ….

46. Janice Regan, 2008 46 Use case for Web application  The User indicates that s/he is done by pressing the Commit button.  The system stores the updated information to the Database and the use case terminates.  Postconditions: User record is updated in the Database.  Exceptional flow of events #1: (sample of exceptional flows)  The User cancels the use case at any point prior to indicating that they have completed the editing by pressing the cancel button. The Database is not altered. ….

47. Janice Regan, 2008 47 Be careful with preconditions!  This previous use case specifies that the user has reached the web site. It does not specify that the user has been validated by the security system.  The use case indicates that the user will be able to validate their identity after choosing to update their profile (using an >)  The first UI screen on the website will show update profile as a choice. The screen resulting from that choice will contain the validate identity button.

48. Janice Regan, 2008 48 Be careful with preconditions!  If the use case specified that the user must have already validated themselves then  The first UI screen would be validation (e.g. login), and validation would be a separate use case and sequence diagram used only at login.  The second (or later) UI screen would allow the user to choose the option of updating their profile.  BE SURE TO BE CONSISTENT IN YOUR DESIGN