Week 2 The Object-Oriented Approach to Requirements

Analysis Phase Activities Gather Information Involves gathering lots of information Can get information from people who will be using the system By interviewing them By observing them Can get other information by reviewing documents and policy statements (e.g. At a bank) Can involve the analyst actually doing some or part of the task to get a feel for what is done In order to automate order-entry you may need to become an “expert” on the task (knowing how orders are processed) Need to understand current and future users, locations, system interfaces, possible solutions, etc.

Define System Requirements Involves modelling Logical Model Any model that shows what the system is required to do without committing to any one technology – requirements model is logical Physical Model Any model that shows how the system will actually be implemented Models are often graphical in nature Data flow diagrams (DFDs) Entity-relationship diagrams (ERDs)

Prioritize Requirements Important to establish which functional and technical requirements are most critical Why? Since resources are always limited and you want to address the most important things If not addressed can lead to “scope creep”, where the scope of the project just seems to expand over time

Requirements Diagrams: Traditional and OO Models

Simple Use Case with an Actor

Use Case Diagram with System Boundary

Use Case of Customer Support System

All Use Cases Including Customer

Use Case Diagram for Inventory System

<<Includes>> Relationships Documents situation where one use case requires the services of a common subroutine Another use case is developed for this common subroutine A common use case can be reused by multiple use cases

Example of Order-Entry Subsystem with <<Includes>> Use Cases

Developing a Use Case Diagram Starting points for use case development Use event table Identify all actors of the system Identify functions actors perform with system Develop flow of activities to identify various scenarios Common internal use cases can be identified and separated into different use cases

Use Case Detailed Descriptions Scenario, or use case instance, details sequence of activities within use case Shows actor interacting with computer system step-by-step to carry out business activity May have several scenarios for single use case Analysts prefer to write narrative descriptions of use cases instead of building activity diagrams Three levels: brief, intermediate, and fully developed description

Brief Description of Create New Order Use Case

Intermediate Description of the Telephone Order Scenario for Create New Order

Intermediate Description of the Web Order Scenario for Create New Order

Fully Developed Description of Telephone Order Scenario for Create New Order

Fully Developed Description of Web Order Scenario for Create New Order

Activity Diagrams Used to document work flow of business process activities for each use case scenario Standard UML diagram Can support any level of use case description Helpful in developing system sequence diagrams

Activity Diagram: Telephone Order Scenario

Activity Diagram: Web Order Scenario

Identifying Inputs and Outputs – The System Sequence Diagram Collaboration diagram Emphasizes objects that interact together to support a use case diagram May be used alone or with sequence diagram System sequence diagram Shows sequence of interactions between objects and flow of events in a single use case Focuses on message details Used more frequently in industry

Sample System Sequence Diagram (SSD)

SSD Notation Actor represented by stick figure – person (or role) that “interacts” with system by entering input data and receiving output data Object notation is rectangle with name of object underlined – shows individual object and not class of all similar objects Lifeline is vertical line under object or actor to show passage of time for object Messages use arrows to show messages sent or received by actor or system

SSD Lifelines Vertical line under object or actor: Shows passage of time If vertical line dashed: Creation and destruction of thing is not important for scenario Long narrow rectangles: Activation lifelines emphasize that object is active only during part of scenario

SSD Messages Internal events identified by the flow of objects within a scenario Requests from one actor or object to another to do some action Invokes a particular method

Repeating Message

Developing a System Sequence Diagram Begin with detailed description of use case from fully developed form or activity diagrams Identify input messages Describe message from external actor to system using message notation Identify and add any special conditions on input message, including iteration and true/false conditions Identify and add output return messages

Simplified Activity Diagram of the Telephone Order Scenario

SSD of Simplified Telephone Order Scenario for Create New Order Use Case

Activity Diagram: Web Order Scenario

SSD of the Web Order Scenario for the Create New Order Use Case

Problem Domain Modeling – The Domain Model Class Diagram Class diagram is focal point of object-oriented development Provides definition of system components Contains important class structural information for implementation with object-oriented programming Provides conceptual data model to describe classes for database definition Consists of problem domain classes and implementation classes

Example of Domain Model Class Diagram

RMO Domain Model Class Diagram

Integrating Object-Oriented Models Complete use case diagram is needed to understand total scope of new system Domain model class diagrams also should be as complete as possible for entire system With iterative approach, only construct use case descriptions, activity diagrams, and system sequence diagrams for use cases in iteration Development of a new diagram often helps refine and correct previous diagrams

Relationships Between OO Requirements Models