1 week 2 the object-oriented approach to requirements
TRANSCRIPT
![Page 1: 1 Week 2 The Object-Oriented Approach to Requirements](https://reader036.vdocuments.us/reader036/viewer/2022070306/5517073e550346f5558b51af/html5/thumbnails/1.jpg)
1
Week 2 The Object-Oriented
Approach to Requirements
![Page 2: 1 Week 2 The Object-Oriented Approach to Requirements](https://reader036.vdocuments.us/reader036/viewer/2022070306/5517073e550346f5558b51af/html5/thumbnails/2.jpg)
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.
![Page 3: 1 Week 2 The Object-Oriented Approach to Requirements](https://reader036.vdocuments.us/reader036/viewer/2022070306/5517073e550346f5558b51af/html5/thumbnails/3.jpg)
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)
![Page 4: 1 Week 2 The Object-Oriented Approach to Requirements](https://reader036.vdocuments.us/reader036/viewer/2022070306/5517073e550346f5558b51af/html5/thumbnails/4.jpg)
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
![Page 5: 1 Week 2 The Object-Oriented Approach to Requirements](https://reader036.vdocuments.us/reader036/viewer/2022070306/5517073e550346f5558b51af/html5/thumbnails/5.jpg)
5
![Page 6: 1 Week 2 The Object-Oriented Approach to Requirements](https://reader036.vdocuments.us/reader036/viewer/2022070306/5517073e550346f5558b51af/html5/thumbnails/6.jpg)
6
Requirements Diagrams: Traditional and OO Models
![Page 7: 1 Week 2 The Object-Oriented Approach to Requirements](https://reader036.vdocuments.us/reader036/viewer/2022070306/5517073e550346f5558b51af/html5/thumbnails/7.jpg)
7
Simple Use Case with an Actor
![Page 8: 1 Week 2 The Object-Oriented Approach to Requirements](https://reader036.vdocuments.us/reader036/viewer/2022070306/5517073e550346f5558b51af/html5/thumbnails/8.jpg)
8
Use Case Diagram with System Boundary
![Page 9: 1 Week 2 The Object-Oriented Approach to Requirements](https://reader036.vdocuments.us/reader036/viewer/2022070306/5517073e550346f5558b51af/html5/thumbnails/9.jpg)
9
Use Case of Customer Support System
![Page 10: 1 Week 2 The Object-Oriented Approach to Requirements](https://reader036.vdocuments.us/reader036/viewer/2022070306/5517073e550346f5558b51af/html5/thumbnails/10.jpg)
10
All Use Cases Including Customer
![Page 11: 1 Week 2 The Object-Oriented Approach to Requirements](https://reader036.vdocuments.us/reader036/viewer/2022070306/5517073e550346f5558b51af/html5/thumbnails/11.jpg)
11
Use Case Diagram for Inventory System
![Page 12: 1 Week 2 The Object-Oriented Approach to Requirements](https://reader036.vdocuments.us/reader036/viewer/2022070306/5517073e550346f5558b51af/html5/thumbnails/12.jpg)
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
![Page 13: 1 Week 2 The Object-Oriented Approach to Requirements](https://reader036.vdocuments.us/reader036/viewer/2022070306/5517073e550346f5558b51af/html5/thumbnails/13.jpg)
13
Example of Order-Entry Subsystem with <<Includes>>
Use Cases
![Page 14: 1 Week 2 The Object-Oriented Approach to Requirements](https://reader036.vdocuments.us/reader036/viewer/2022070306/5517073e550346f5558b51af/html5/thumbnails/14.jpg)
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
![Page 15: 1 Week 2 The Object-Oriented Approach to Requirements](https://reader036.vdocuments.us/reader036/viewer/2022070306/5517073e550346f5558b51af/html5/thumbnails/15.jpg)
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
![Page 16: 1 Week 2 The Object-Oriented Approach to Requirements](https://reader036.vdocuments.us/reader036/viewer/2022070306/5517073e550346f5558b51af/html5/thumbnails/16.jpg)
16
Brief Description of Create New Order
Use Case
![Page 17: 1 Week 2 The Object-Oriented Approach to Requirements](https://reader036.vdocuments.us/reader036/viewer/2022070306/5517073e550346f5558b51af/html5/thumbnails/17.jpg)
17
Intermediate Description of the Telephone Order Scenario for Create
New Order
![Page 18: 1 Week 2 The Object-Oriented Approach to Requirements](https://reader036.vdocuments.us/reader036/viewer/2022070306/5517073e550346f5558b51af/html5/thumbnails/18.jpg)
18
Intermediate Description of the Web Order Scenario for Create New Order
![Page 19: 1 Week 2 The Object-Oriented Approach to Requirements](https://reader036.vdocuments.us/reader036/viewer/2022070306/5517073e550346f5558b51af/html5/thumbnails/19.jpg)
19
Fully Developed Description of Telephone Order Scenario for Create
New Order
![Page 20: 1 Week 2 The Object-Oriented Approach to Requirements](https://reader036.vdocuments.us/reader036/viewer/2022070306/5517073e550346f5558b51af/html5/thumbnails/20.jpg)
20
Fully Developed Description of Web Order Scenario for Create New Order
![Page 21: 1 Week 2 The Object-Oriented Approach to Requirements](https://reader036.vdocuments.us/reader036/viewer/2022070306/5517073e550346f5558b51af/html5/thumbnails/21.jpg)
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
![Page 22: 1 Week 2 The Object-Oriented Approach to Requirements](https://reader036.vdocuments.us/reader036/viewer/2022070306/5517073e550346f5558b51af/html5/thumbnails/22.jpg)
22
Activity Diagram: Telephone Order Scenario
![Page 23: 1 Week 2 The Object-Oriented Approach to Requirements](https://reader036.vdocuments.us/reader036/viewer/2022070306/5517073e550346f5558b51af/html5/thumbnails/23.jpg)
23
Activity Diagram: Web Order Scenario
![Page 24: 1 Week 2 The Object-Oriented Approach to Requirements](https://reader036.vdocuments.us/reader036/viewer/2022070306/5517073e550346f5558b51af/html5/thumbnails/24.jpg)
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
![Page 25: 1 Week 2 The Object-Oriented Approach to Requirements](https://reader036.vdocuments.us/reader036/viewer/2022070306/5517073e550346f5558b51af/html5/thumbnails/25.jpg)
25
Sample System Sequence Diagram (SSD)
![Page 26: 1 Week 2 The Object-Oriented Approach to Requirements](https://reader036.vdocuments.us/reader036/viewer/2022070306/5517073e550346f5558b51af/html5/thumbnails/26.jpg)
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
![Page 27: 1 Week 2 The Object-Oriented Approach to Requirements](https://reader036.vdocuments.us/reader036/viewer/2022070306/5517073e550346f5558b51af/html5/thumbnails/27.jpg)
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
![Page 28: 1 Week 2 The Object-Oriented Approach to Requirements](https://reader036.vdocuments.us/reader036/viewer/2022070306/5517073e550346f5558b51af/html5/thumbnails/28.jpg)
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
![Page 29: 1 Week 2 The Object-Oriented Approach to Requirements](https://reader036.vdocuments.us/reader036/viewer/2022070306/5517073e550346f5558b51af/html5/thumbnails/29.jpg)
29
Repeating Message
![Page 30: 1 Week 2 The Object-Oriented Approach to Requirements](https://reader036.vdocuments.us/reader036/viewer/2022070306/5517073e550346f5558b51af/html5/thumbnails/30.jpg)
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
![Page 31: 1 Week 2 The Object-Oriented Approach to Requirements](https://reader036.vdocuments.us/reader036/viewer/2022070306/5517073e550346f5558b51af/html5/thumbnails/31.jpg)
31
Simplified Activity Diagram of the Telephone Order Scenario
![Page 32: 1 Week 2 The Object-Oriented Approach to Requirements](https://reader036.vdocuments.us/reader036/viewer/2022070306/5517073e550346f5558b51af/html5/thumbnails/32.jpg)
32
SSD of Simplified Telephone Order Scenario for Create New Order Use Case
![Page 33: 1 Week 2 The Object-Oriented Approach to Requirements](https://reader036.vdocuments.us/reader036/viewer/2022070306/5517073e550346f5558b51af/html5/thumbnails/33.jpg)
33
Activity Diagram: Web Order Scenario
![Page 34: 1 Week 2 The Object-Oriented Approach to Requirements](https://reader036.vdocuments.us/reader036/viewer/2022070306/5517073e550346f5558b51af/html5/thumbnails/34.jpg)
34
SSD of the Web Order Scenario for the Create New Order Use Case
![Page 35: 1 Week 2 The Object-Oriented Approach to Requirements](https://reader036.vdocuments.us/reader036/viewer/2022070306/5517073e550346f5558b51af/html5/thumbnails/35.jpg)
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
![Page 36: 1 Week 2 The Object-Oriented Approach to Requirements](https://reader036.vdocuments.us/reader036/viewer/2022070306/5517073e550346f5558b51af/html5/thumbnails/36.jpg)
36
Example of Domain Model Class Diagram
![Page 37: 1 Week 2 The Object-Oriented Approach to Requirements](https://reader036.vdocuments.us/reader036/viewer/2022070306/5517073e550346f5558b51af/html5/thumbnails/37.jpg)
37
RMO Domain Model Class Diagram
![Page 38: 1 Week 2 The Object-Oriented Approach to Requirements](https://reader036.vdocuments.us/reader036/viewer/2022070306/5517073e550346f5558b51af/html5/thumbnails/38.jpg)
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
![Page 39: 1 Week 2 The Object-Oriented Approach to Requirements](https://reader036.vdocuments.us/reader036/viewer/2022070306/5517073e550346f5558b51af/html5/thumbnails/39.jpg)
39
Relationships Between OO Requirements Models