7

2Object-Oriented Analysis and Design with the Unified Process Objectives  Detailed Object-Oriented Requirements Definitions  System Processes—A Use Case/Scenario View  Identifying Inputs and Outputs—The System Sequence Diagram  Identifying Object Behavior—The Statechart Diagram  Integrating Object-Oriented Models

3Object-Oriented Analysis and Design with the Unified Process Object-Oriented Requirements Definitions  Use case diagram: a diagram showing the various user roles and the way those users interact with the system  System sequence diagrams (SSDs) : a diagram showing the sequence of messages between an external actor and the system during a use case or scenario  Statechart diagram: a diagram showing the life of an object in states and transitions

4Object-Oriented Analysis and Design with the Unified Process System Processes—A Use Case/Scenario View  Define use cases into two tiers:  Overview level derived from: ◘Event table and use case diagrams  Detailed level derived from combination of: ◘Use case description ◘Activity diagram ◘Sequence diagram

5Object-Oriented Analysis and Design with the Unified Process Use Cases and Actors  Source  Person or thing initiating the business event  Must be external to the system  Actor  Person or thing that touches the system  Lies outside of automation boundary

To draw a use case diagram  Drag Subsystem boundaries from the toolbox onto the diagram, to represent either your whole system or its major components.  You can draw a use case diagram without system boundaries if you do not want to describe which use cases are supported by your system or its components.  Drag Actors from the toolbox onto the diagram (placing them outside any system boundary).  Actors represent classes of users, organizations, and external systems that interact with your system.  Drag Use Cases from the toolbox onto the appropriate systems.  Use cases represent the activities that actors perform with the help of your system.  For example: Order Meal, Pay for Meal, Deliver Meal.  Click Association on the toolbox, then a use case, and then an actor that participates in the use case. Link each actor to its use cases in this manner.  Structure the use cases with the Include, Extend and Generalization relationships.  Describe the use cases in more detail.  Draw separate diagrams to focus on different subsystems or different groups of related use cases. All the diagrams in one modeling project are views of the same model. Source: 6Object-Oriented Analysis and Design with the Unified Process

7 A Simple Use Case with an Actor The Use Case Diagram

8Object-Oriented Analysis and Design with the Unified Process A Use Case Diagram of the Order-Entry Subsystem for RMO, Showing a System Boundary

9Object-Oriented Analysis and Design with the Unified Process A Use Case Diagram of the Customer Support System (by Subsystem)

10Object-Oriented Analysis and Design with the Unified Process Showing the details of a use case with Include Use an Include relation to show that one use case describes some of the detail of another. In the illustration, Order a Meal includes Pay, Choose Menu, and Choose Menu Item. Each of the included, more detailed use cases is a step that the actor or actors might have to perform to achieve the overall goal of the including use case. The arrow should point at the more detailed, included use case. > relationship Source:

11Object-Oriented Analysis and Design with the Unified Process Separating variant cases with Extend Use an Extend link to show that one use case may add functionality to another use case under certain circumstances. The arrow should point at the main, extended use case. > relationship For example, the Login use case of a typical Web site can include Register New User - but only when the user does not already have an account. Source:

12Object-Oriented Analysis and Design with the Unified Process Sharing goals with Generalization Use a Generalization relation to show that a specialized use case is a particular way to achieve the goals expressed by another general use case. The open arrowhead should point at the more general use case. Generalization relationship For example, Pay generalizes Pay by Credit Card and Pay by Cash. Source:

13Object-Oriented Analysis and Design with the Unified Process We can use different subsystem boundaries to illustrate different versions of the system. For example, the Pay use case might be included in Website Version 2 but not in Version 1.This implies that the system helps customers make their orders. However, they have to pay the restaurant directly. Use Dependency relations to link subsystems representing different versions or variants. System Versions

14Object-Oriented Analysis and Design with the Unified Process System Versions (con’t) Source:

15Object-Oriented Analysis and Design with the Unified Process Brief Description of Create New Order Use Case Developing a Use Case Diagram: (level 1-brief description)

16Object-Oriented Analysis and Design with the Unified Process Intermediate Description of Telephone Order Scenario for Create New Order Use Case Developing a Use Case Diagram: (level 2- Intermediate description)

17Object-Oriented Analysis and Design with the Unified Process Fully Developed Description of Telephone Order Scenario for Create New Order Use Case Developing a Use Case Diagram: (level 3- Fully developed description)

18Object-Oriented Analysis and Design with the Unified Process Precondition: A set of criteria that must be true prior to the initiation of a use case Postcondition: A set of criteria that must be true upon completion of the execution of a use case Precondition and Postcondition

19Object-Oriented Analysis and Design with the Unified Process Identifying Inputs and Outputs— the System Sequence Diagram  System sequence diagram (SSD)  To describe how the main components of the system interact to fulfill the goal of each use case  To describe how the internal parts of the component interact to achieve the result required for each incoming message

Sequence diagrams has several benefits  Easily see how tasks are distributed between components.  Can identify patterns of interaction that make it difficult to update the software. 20Object-Oriented Analysis and Design with the Unified Process

21Object-Oriented Analysis and Design with the Unified Process Sequence Diagram in Details Refer file

Sequence Diagram: Example Case Study: ATM Machine 22Object-Oriented Analysis and Design with the Unified Process

Sequence Diagrams 23 Indicating selection and loops  frame: box around part of a sequence diagram to indicate selection or loop  if -> (opt) [condition]  if/else -> (alt) [condition], separated by horiz. dashed line  loop -> (loop) [condition or items to loop over]

Sequence Diagrams24 Exercise !!! Create a sequence diagram depicts on the following program:

25Object-Oriented Analysis and Design with the Unified Process Identifying the Object Behavior  the Statechart Diagram Refer file

26Object-Oriented Analysis and Design with the Unified Process Rules for Developing Statecharts  [1] Select the classes that will require statecharts  [2] List all the status conditions for each group  [3] Specify transitions that cause object to leave the identified state  [4] Sequence state-transition combinations in correct order

27Object-Oriented Analysis and Design with the Unified Process Rules for Developing Statecharts (continued)  [5] Identify concurrent paths.  [6] Look for additional transitions  [7] Expand each transition as appropriate  [8] Review and test each statechart

button1&2Pressed button1Pressed button2Pressed button1Pressed button1&2Pressed Increment Minutes Increment Hours Blink Hours Blink Seconds Blink Minutes Increment Seconds Stop Blinking State Diagram : Example1 State Initial state Final state Transition Event

State Diagram : Example2 29Object-Oriented Analysis and Design with the Unified Process

30Object-Oriented Analysis and Design with the Unified Process Relationships among OO Requirements Models OO requirements models

31Object-Oriented Analysis and Design with the Unified Process Summary  OOA family of models documents users’ needs and defines system requirements  Use case detailed models (descriptive or activity)  Sequence diagrams (SSDs)  Domain model class diagrams  Statechart diagrams

32Object-Oriented Analysis and Design with the Unified Process Summary (continued)  Use case: single system function responding to an event  Actors: human users or system interfaces that initiate system response  System function decomposed into workflows  SSDs, domain models, statecharts emulate routines and object interaction  Software engineering terms signal transition into design phase