Object-Oriented Analysis and Design Use Case
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Object-Oriented Analysis and Design
Use Case
Use Cases
Use case— an activity that the system performs, usually in response to a request by a user
Use cases define functional requirements Analysts decompose the system into a set
of use cases (functional decomposition) Two techniques for Identifying use cases
User goal technique Event decomposition technique
Name each use case using Verb-Noun
2
Types of Diagrams
3
Structural Diagrams – focus on static aspects of the software system Class, Object
Behavioral Diagrams – focus on dynamic aspects of the software system Use-case, Sequence, Interaction,
State Chart, Activity Implementation Diagrams – focus on
Component, Deployment
User Goal TechniqueSome RMO CSMS Users and Goals
4
User Goal Technique:Specific Steps
1. Identify all the potential users for the new system
2. Classify the potential users in terms of their functional role (e.g., shipping, marketing, sales)
3. Further classify potential users by organizational level (e.g., operational, management, executive)
4. For each type of user, interview them to find a list of specific goals they will have when using the new system (current goals and innovative functions to add value) 5
User Goal TechniqueSpecific Steps (continued)
5. Create a list of preliminary use cases organized by type of user
6. Look for duplicates with similar use case names and resolve inconsistencies
7. Identify where different types of users need the same use cases
8. Review the completed list with each type of user and then with interested stakeholders
6
Event Decomposition Technique
More Comprehensive and Complete Technique
Identify the events that occur to which the system must respond.
For each event, name a use case (verb-noun) that describes what the system does when the event occurs
Event– something that occurs at a specific time and place, can be described, and should be remembered by the system
7
Events and Use Cases
8
Types of Events
External Event an event that occurs outside the
system, usually initiated by an external agent or actor
Temporal Event an event that occurs as a result of
reaching a point in time State Event
an event that occurs when something happens inside the system that triggers some process
reorder point is reached for inventory item
9
External Event Checklist
External agent or actor wants something resulting in a transaction
Customer buys a product External agent or actor wants some
information Customer wants to know product details
External data changed and needs to be updated
Customer has new address and phone Management wants some information
Sales manager wants update on production plans
10
Temporal Event Checklist
Internal outputs needed at points in time
Management reports (summary or exception)
Operational reports (detailed transactions)
Internal statements and documents (including payroll)
External outputs needed at points of time
Statements, status reports, bills, reminders
11
Finding the actual event that affects the system
12
Tracing a sequence of transactions resulting in many events
13
Perfect Technology Assumption
14
Don’t worry about functions built into system because of limits in technology and people. Wait until design.
Event Decomposition Technique:Specific Steps
1. Consider the external events in the system environment that require a response from the system by using the checklist shown in Figure 3-3
2. For each external event, identify and name the use case that the system requires
3. Consider the temporal events that require a response from the system by using the checklist shown in Figure 3-4
4. For each temporal event, identify and name the use case that the system requires and then establish the point of time that will trigger the use case
15
Event Decomposition Technique:Specific Steps (continued)
5. Consider the state events that the system might respond to, particularly if it is a real-time system in which devices or internal state changes trigger use cases.
6. For each state event, identify and name the use case that the system requires and then define the state change.
7. When events and use cases are defined, check to see if they are required by using the perfect technology assumption. Do not include events that involve such system controls as login, logout, change password, and backup or restore the database, as these are put in later.
16
Use Cases andBrief Use Case Descriptions
17
Brief use case description is often a one sentence description showing the main steps in a use case
Use Case Diagrams
18
Use case diagram— a UML model used to graphically show uses cases and their relationships to actors
Recall UML is Unified Modeling Language, the standard for diagrams and terminology for developing information systems
Actor is the UML name for a end user Automation boundary— the boundary between the
computerized portion of the application and the users who operate the application
Use Case DiagramsSymbols
19
Use Case Diagrams
Draw for each subsystem
20
Use Case Diagrams
Draw for actor, such as customer
21
Use Case DiagramsThe <<Includes>> relationship
22
A relationship between use cases where one use case is stereotypically included within the other use case— like a called subroutine. Arrow points to subroutine
Use case specification
A use case specification is a document used to capture the specific details of a use case. Use case specifications provide a way to capture the functional requirements of a system.
Use case specifications provide a means of organizing all of the different scenarios that exist. They add detail beyond what is shown in a use case diagram. They are a useful tool in communicating with project stakeholders, system users, business analysts, and developers. These specifications define requirements in a way that all consumers of the project can understand, creating a common vocabulary for the impacted parties.
While the structure of a use case model helps drive architectural decisions, the specific scenarios outlined in a use case specification serve to verify whether early architectural assumptions are correct. Properly written use case specifications help identify and design objects, system components, and their responsibilities. Use cases also drive the creation of an efficient user interface design. They also help organize the development process. Quality assurance teams test functional requirements based on the content of a use case specification, and this document also assists with defining benchmarks for performance testing. Finally, use case specifications help with the creation of user guides, training manuals, and other related implementation tasks.
Use Case Identification and History
Use Case ID:PROJ.UC.1.1.1 <Assign a unique name to each use case>
Use Case Name:<Name – concise results oriented-name with an action verb and a noun. >
Version No:
Created by: On (date):
Last Update by: On (date):
User/Actor:<Description of the person who uses the system to accomplish tasks>
Business Owner Name: Contact Details:
Trigger:<Who (system or user) triggers this use case>
Precondition<What is true of the system state before this flow of actions begins>
Basic Flow <The optimal or normal ("good day") flow of events. The basic flow of events should describe the events that walk through a successful scenario. The basic flow should not include “and/if scenarios”>
Step User Actions System Actions
1<Phrase saying what user does> <Description of system response>
2<Repeated as needed> <Repeat…>
Use case specification
Alternate Flow <may be more than one>Step User Actions System Actions
1 <Phrase saying what user does, identify prior basic step # where alternative flow begins and subsequent basic step # where basic flow continues (if it does) after performing alternate flow>
<Description of alternative flow step(s) (number each distinct step)>
Exception Flow <identify system and data error conditions that could occur for each step in the normal and alternate flow>
1 <Phrase saying what data or system error condition occurred. Identify prior basic or alternative step # where basic/alternative flow begins and subsequent basic/ alternative step # where basic/ alternative flow continues (if it does) after performing exception flow >
<Description of system response to return back to the next step in the flow or state if the condition results in termination of the flow and what the final state of the system is at this point (i.e. redisplay first screen before error condition or something else.) (Number each distinct step). >
<Example: The VIN is invalid. (Basic Flow, Step 2)>
Post conditions
1. <What is true of the system when the flow of activities finishes> Includes or Extension Points
1. <Common functionality that appears in multiple use cases can be split out into separate use cases. Provide reference to such of the use cases that are called by the subject use case. >
Use case specification
Use case specification
• Introduction to Systems Analysis and Design: • An Agile, Iteractive Approach
• 6th Ed• Satzinger, Jackson & Burd
Terimakasih