Presentation is loading. Please wait.

Presentation is loading. Please wait.

Week 2 The Object-Oriented Approach to Requirements

Similar presentations

Presentation on theme: "Week 2 The Object-Oriented Approach to Requirements"— Presentation transcript:

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


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

Download ppt "Week 2 The Object-Oriented Approach to Requirements"

Similar presentations

Ads by Google