1

Week 2 The Object-Oriented

Approach to Requirements

2

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.

3

• 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)

4

• 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

5

6

Requirements Diagrams: Traditional and OO Models

7

Simple Use Case with an Actor

8

Use Case Diagram with System Boundary

9

Use Case of Customer Support System

10

All Use Cases Including Customer

11

Use Case Diagram for Inventory System

12

<<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

13

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

Use Cases

14

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

15

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

16

Brief Description of Create New Order

Use Case

17

Intermediate Description of the Telephone Order Scenario for Create

New Order

18

Intermediate Description of the Web Order Scenario for Create New Order

19

Fully Developed Description of Telephone Order Scenario for Create

New Order

20

Fully Developed Description of Web Order Scenario for Create New Order

21

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

22

Activity Diagram: Telephone Order Scenario

23

Activity Diagram: Web Order Scenario

24

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

25

Sample System Sequence Diagram (SSD)

26

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

27

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

28

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

29

Repeating Message

30

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

31

Simplified Activity Diagram of the Telephone Order Scenario

32

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

33

Activity Diagram: Web Order Scenario

34

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

35

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

36

Example of Domain Model Class Diagram

37

RMO Domain Model Class Diagram

38

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

39

Relationships Between OO Requirements Models