4 Topic 4: The Object-Oriented Approach to Requirements Adopted from: Ch. 7 The Object-Oriented Approach to Requirements (Satzinger: Systems Analysis & Design in a Changing World) 2009/10 Object Oriented Technology 1
4 Learning Objectives u Develop u Write use case diagrams use case and scenario descriptions u Develop system sequence diagrams u Explain how UML diagrams work together to define functional requirements for the objectoriented approach 2009/10 Object Oriented Technology 2
4 Overview u Objective of requirements definition is understanding user’s needs, business processes, and system to support business processes u Understand define requirements for a new system using object-oriented analysis models and techniques u Object-oriented design analysis and object-oriented l l 2009/10 Iterative approach to development Models built in analysis are refined during design Object Oriented Technology 3
1. The Unified Modeling Language and the Object Management Group 4 u Object-oriented modeling notation is Unified Modeling Language (UML 2. 0) u UML was accepted by Object Management Group (OMG) as standard modeling technique u Purpose of Object Management Group l l 2009/10 Promote theory and practice of object technology for development of distributed systems Provide common architectural framework for OO Object Oriented Technology 4
2. Object-Oriented Requirements (continued) 4 u Object-oriented system requirements are specified and documented through process of building models u Modeling process starts with identification of use cases and problem domain classes (things in users’ work environment) u Business events trigger elementary business processes (EBP) that new system must address as use cases u Use 2009/10 cases define functional requirements Object Oriented Technology 5
3. Object-Oriented Requirements Models u Use 4 case diagrams – identify actors and their use cases (goals) u Use case descriptions – include details of a use case and how actors use the system u Systems sequence diagrams (SSDs) – define inputs and outputs and sequence of interactions between user and system for a use case u Activity diagrams – describe user and system activities for a use case u State machine diagrams – describe states of each object 2009/10 Object Oriented Technology 6
3. 1 Requirements Models: Traditional vs OO Models 2009/10 Object Oriented Technology 4 7
4. The System Activities – A Use Case / Scenario View (1) 4 u Use case analysis used to identify and define all business processes that system must support u Use Case - an activity a system carried out, usually in response to a user request 2009/10 Object Oriented Technology 8
4. The System Activities – A Use Case / Scenario View (2) 4 u Actor l Role played by user l Outside automation boundary l 2 types of actors: u Primary actor – the one who starts the sequence of events, or calls the system to finish a task/goal u Supporting actors – provide service to the system, might be a printer, web service, human or another system 2009/10 Object Oriented Technology 9
4 5. Techniques for Identifying Use Cases 1. Identify user goals (Actor-Goal list) l Each goal at the elementary business process (EBP) level is a use case 2. Event decomposition technique (Event Analysis with the event table) 3. CRUD analysis technique (create, read/report, update, delete) to ensure coverage 2009/10 Object Oriented Technology 10
4 5. 1 Using EBP Guideline to identify a Use Case u EBP stands for Elementary Business Process l An EBP – a task performed by one person in one place and in response to business event that adds measurable business value, and leaves system and data in consistent state l Example Use cases: u u Handle returns u 2009/10 Add new customers Buy a cinema ticket Object Oriented Technology 11
5. 1. 1 How EBP helps to identify Use Cases? u EBP filters out l excessive low-level use cases u l It is not a single small step like “delete a line item”, or “enter customer name” excessive high-level use cases u Such as “negotiate a contract”, which takes days to complete l The main flow probably contains five to ten steps l It does not take days and multiple sessions l It is a task done during a single session l 2009/10 4 It emphasizes adding measurable business value Object Oriented Technology 12
5. 2 CRUD analysis for Identifying/Confirming Use Cases u CRUD 4 – Create, Read/Report, Update, Delete u Identify event table events or develop use case diagram directly u Compares identified use cases with domain model class diagram u Every class in class diagram must have use cases to support creating, reading, reporting, updating, and deleting object instances u Confirms 2009/10 system integration requirements Object Oriented Technology 13
4 6. Use Case Model u The Use Case Model consists of use case diagram and a set of Use Case descriptions 2009/10 Object Oriented Technology 14
4 6. 1 Use Case Diagram u Graphical UML diagram that summarizes information about actors and use cases u Simple diagram shows overview of functional requirements u Can have multiple use case diagrams l l 2009/10 By subsystem By actor Object Oriented Technology 15
6. 1. 1 Simple Use Case with an Actor 4 (Figure 7 -2) 2009/10 Object Oriented Technology 16
6. 2 Use Case Diagram with Automation Boundary and Alternate Actor Notation (Figure 7 -3) 2009/10 Object Oriented Technology 4 17
4 6. 3 All Use Cases Involving Customer as Actor (Figure 7 -4) 2009/10 Object Oriented Technology 18
4 6. 4 Use Cases of RMO Order Entry Subsystem (Partial Figure 7 -5 with package symbol) 2009/10 Object Oriented Technology 19
4 7. <<includes>> Relationships u Documents situation where one use case requires the services of a common subroutine u Another use case is developed for this common subroutine u. A common use can be reused by multiple use cases 2009/10 Object Oriented Technology 20
7. 1 Example of Order-Entry Subsystem with <<includes>> Use Cases (Figure 7 -6) 2009/10 Object Oriented Technology 4 21
4 8. Use Case Description u Use case description provides details of preconditions, postconditions, sequence of activities, and exception conditions in use case u Describes actor interacting with computer system step-bystep to carry out business activity u May have several scenarios for a use case, each a specific use case instance u Three levels of detail: brief, intermediate (casual), and fully developed (fully dressed) description u Many analysts prefer to write narrative descriptions of use cases instead of drawing activity diagrams 2009/10 Object Oriented Technology 23
8. 1 The 3 levels of Use Cases 1. brief l 2. Multiple paragraphs that cover various scenarios (Fig 7 -8, Fig 7 -9) fully developed (fully dressed) l 2009/10 One-paragraph summary, usually of the main success scenario (Fig 7 -7) intermediate (casual) l 3. 4 All steps and variations are written in details, and there are supporting sections such as Preconditions and Postconditions. (Fig 7 -10) Object Oriented Technology 24
8. 1. 1 Brief Description of Create New Order Use Case (Figure 7 -7) 2009/10 Object Oriented Technology 4 25
4 8. 1. 2 Intermediate Description of the Telephone Order Scenario for Create New Order Use Case (Figure 7 -8) 2009/10 Object Oriented Technology 26
8. 1. 2 Intermediate Description of the Web Order Scenario for Create New Order (Figure 7 -9) 2009/10 Object Oriented Technology 4 27
4 8. 1. 3 Fully Developed Description of Telephone Order Scenario for Create New Order Use Case (Figure 7 -10) 2009/10 Object Oriented Technology 28
8. 1. 3 Top Detail from Fully Developed Use Case Description (Figure 7 -10) 2009/10 Object Oriented Technology 4 29
8. 1. 3 Middle Detail from Fully Developed Use Case Description (Figure 7 -10) 2009/10 Object Oriented Technology 4 30
8. 1. 3 Bottom Detail from Fully Developed Use Case Description (Figure 7 -10) 2009/10 Object Oriented Technology 4 31
8. 2 Sections of a Use Case Description u Use case name/scenario name u Actors/stakeholders u Related use cases u Preconditions – set of criteria that must be true prior to initiation of the use case u Postconditions – set of criteria that must be true upon completion of the use case u 4 Flow of activities (or Basic Flow or Main Path or Main Success Scenario) l u 2009/10 (steps in one column or two) Exception conditions (or Alternative Flows or Extensions) Object Oriented Technology 32
9. Guidelines (tips) for writing Use Case Description 1. Give the use case an appropriate name 2. Use a consistent style 3. Use active voice 4. Use subsections (or steps) 5. Describe the flow as something that actually happens 6. Always use the name of the actor in the interaction 7. Do not mention GUI design details in the flow 8. Do not mention design or implementation details in the flow 9. Specify information retrieval and calculation means 10. 4 Define long alternatives separately 2009/10 Object Oriented Technology 33
4 10. Activity Diagrams u Used to document workflow of business process activities for each use case or scenario u Can support any level of use case description; a supplement to use case descriptions u Helpful 2009/10 in developing system sequence diagrams Object Oriented Technology 34
4 10. 1 Activity Diagram— Telephone Order Scenario (Figure 7 -12) 2009/10 Object Oriented Technology 35
4 10. 2 Activity Diagram— Web Order Scenario (Figure 7 -13) 2009/10 Object Oriented Technology 36
11. Identifying Inputs and Outputs— The System Sequence Diagram 4 u System sequence diagram (SSD) is type of UML 2. 0 interaction diagram u Used to model input and output messaging requirements for a use case or scenario u Shows actor interacting with system u Shows sequence of interactions as messages during flow of activities u System 2009/10 is shown as one object: a “black box” Object Oriented Technology 37
12. System Sequence Diagram (SSD) Notation (Figure 7 -14) 2009/10 Object Oriented Technology 4 38
4 12. 1 SSD Notation u Actor represented by a stick figure – a person (or role) that interacts with system by entering input data and receiving output data u Object is a rectangle with name of object underlined – shows individual object and not class of all similar objects ( : System for SSD ) u Lifeline or object lifeline is a vertical line under object or actor to show passage of time for object u Message is labeled on arrows to show messages sent to or received by actor or system 2009/10 Object Oriented Technology 39
4 12. 2 SSD Lifelines u Vertical l u If Shows passage of time vertical line dashed l Creation and destruction of thing is not important for scenario u Long l 2009/10 line under object or actor narrow rectangles Activation lifelines emphasize that object is active only during part of scenario Object Oriented Technology 40
4 12. 3 SSD Messages u Internal events identified by the flow of objects in a scenario u Requests from one actor or object to another to do some action u Invoke 2009/10 a particular method Object Oriented Technology 41
4 12. 4 Repeating Message (Figure 7 -15) 2009/10 Object Oriented Technology 42
![12. 4 Repeating Message 4 * [true/false condition] return-value : = messagename (parameter-list) u](https://present5.com/presentation/86ac7e2d7723ad786c2ae641596f5885/image-42.jpg "12. 4 Repeating Message 4 * [true/false condition] return-value : = messagename (parameter-list) u")
12. 4 Repeating Message 4 * [true/false condition] return-value : = messagename (parameter-list) u Asterisk (*) indicates repeat or looping of message. u Brackets [ ] indicate a true/false condition. It is a test for that message only. If it evaluates to true, the message is sent. If it evaluates to false, the message is not sent. u Message-name is the description of the requested service. It is omitted on dashed-line return messages, which only show the return data parameters. u Parameter-list (with parentheses on initiating messages and without parentheses on return messages) shows the date that is passed with the message. 2009/10 Object Oriented Technology 43
4 13. Developing a System Sequence Diagram u Begin with detailed description of use case from fully developed form or activity diagram u Identify input messages u Describe message from external actor to system using message notation u Identify and add any special conditions on input message, including iteration and true/false conditions u Identify 2009/10 and add output return messages Object Oriented Technology 44
13. 1 Activity Diagram and Resulting SSD for Telephone Order Scenario (Figures 7 -16 and 7 -17) 2009/10 Object Oriented Technology 4 45
4 13. 2 SSD of the Web Order Scenario for the Create New Order Use Case (Figure 7 -18) 2009/10 Object Oriented Technology 46
4 14. Integrating Object-Oriented Models u Complete use case diagram is needed to understand total scope of new system u Domain model class diagrams should be as complete as possible for entire system u With iterative approach, only construct use case descriptions, activity diagrams, and system sequence diagrams for use cases in iteration u Development of a new diagram often helps refine and correct previous diagrams 2009/10 Object Oriented Technology 47
14. 1 Relationships Between OO Requirements Models 2009/10 Object Oriented Technology 4 48
Summary 4 u Object-oriented approach has complete set of diagrams that define the system requirements u Requirements specified using following models: l l Use case diagrams (Topic 4) l Use case detailed model, either descriptive format (Topic 4) or activity diagram l 2009/10 Domain model class diagrams (Topic 3) System sequence diagrams (SSDs) (Topic 4) Object Oriented Technology 49
Скачать презентацию 4 Topic 4 The Object-Oriented Approach to Requirements
86ac7e2d7723ad786c2ae641596f5885.ppt