Presentation is loading. Please wait.

Presentation is loading. Please wait.

1 Week 2 The Object-Oriented Approach to Requirements.

Similar presentations

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

1 1 Week 2 The Object-Oriented Approach to Requirements

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

6 6 Requirements Diagrams: Traditional and OO Models

7 7 Simple Use Case with an Actor

8 8 Use Case Diagram with System Boundary

9 9 Use Case of Customer Support System

10 10 All Use Cases Including Customer

11 11 Use Case Diagram for Inventory System

12 12 > 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 13 Example of Order-Entry Subsystem with > Use Cases

14 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 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 16 Brief Description of Create New Order Use Case

17 17 Intermediate Description of the Telephone Order Scenario for Create New Order

18 18 Intermediate Description of the Web Order Scenario for Create New Order

19 19 Fully Developed Description of Telephone Order Scenario for Create New Order

20 20 Fully Developed Description of Web Order Scenario for Create New Order

21 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 22 Activity Diagram: Telephone Order Scenario

23 23 Activity Diagram: Web Order Scenario

24 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 25 Sample System Sequence Diagram (SSD)

26 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 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 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 29 Repeating Message

30 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 31 Simplified Activity Diagram of the Telephone Order Scenario

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

33 33 Activity Diagram: Web Order Scenario

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

35 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 36 Example of Domain Model Class Diagram

37 37 RMO Domain Model Class Diagram

38 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 39 Relationships Between OO Requirements Models

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

Similar presentations

Ads by Google