1 / 27

February 28, 2013

Unified Modeling Language Use Cases. February 28, 2013. Agenda. Intro to Unified Modeling Language (UML) Steps to Establish Use Cases Use Case Diagram Core Elements and Relationships Documenting Use Cases Use Cases in the SDLC. Intro to Unified Modeling Language.

padma
Télécharger la présentation

February 28, 2013

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Unified Modeling Language Use Cases February 28, 2013

  2. Agenda • Intro to Unified Modeling Language (UML) • Steps to Establish Use Cases • Use Case Diagram Core Elements and Relationships • Documenting Use Cases • Use Cases in the SDLC

  3. Intro to Unified Modeling Language • Object-oriented development approach • some times called OO modeling or OO techniques • Use Case Diagrams most common UML technique Source of illustration: http://www.uml-diagrams.org/use-case-diagrams-examples.html

  4. Eliciting Requirements Using Use Case • Use cases came from object-oriented world and apply to general requirements analysis • Provides a method to capture user requirements • Focus on actual, but abstracted, usage scenarios • Ask Users: • “Describe a goal you wish to accomplish with the system.” • NOT: • “What do you want the system to do?” • Explore sequences of ‘actor’ actions and system responses • Derive functional requirements and tests cases

  5. Appropriate Use Case Applications • Use cases work well for: • End-user applications • Web sites • Devices with which users must interact • Use cases are NOT valuable for: • Batch processes • Computationally-intensive systems • Event-driven real-time systems

  6. Establishing Use Cases

  7. 1- Identify Key Stakeholders • Purpose: • Identify internal and external stakeholders impacted by a proposed initiative or who share a common business need • Define stakeholder influence, authority (approve, sign off, veto), and project attitude • Define Meeting Agendas and/or Communication Plan • Determine level of effort to elicit and document requirements • Identify actors needed for User Requirements (i.e., User Stories and Use Cases) • Method: • Conduct Stakeholder Analysis • Adding stakeholders in future phases may impact scope, schedule, resources • Suggested Deliverable(s): • Stakeholder Table Most important step for Project and Process to Establish Use Cases!

  8. 2- Establish the Solution Scope • Purpose: • Align internal and external stakeholders on project scope / boundaries • Define a solution scope that can feasibly be implemented • Method: • Display how system inter operates at a very high level or how systems operate and interact logically. • Develop a baseline interaction between systems and actors; actors and system or systems and systems. • Suggested Deliverable(s): • Context Diagram or Use Case Diagram

  9. Context Diagram or Use Case Diagram - Which one is better? Latinitas Use Case Diagram • Context diagram from a DFD or a Use Case Diagram are often used to set the boundaries for a solution Latinitas Context Diagram

  10. 3 - Define the Actors • Purpose • Identify Actors (users or systems with behavior) • Primary- a user who calls on the system to deliver a service • Supporting/Secondary - provide a service to the system under development (e.g., printers, web services, people who gather information for a user) • Identify missing Stakeholder Roles • Method • Actor names are generally role names • Translate Stakeholders Table into Actors • Document the profiles of actors (with respect to the system/solution under development) helps to make use cases consistent • Suggested Deliverable(s) • Actor Profile Table • Actor Profile Characteristics

  11. Questions to Help Identify Actors • Who Uses the system directly? • Who gets information, reports, or messages from the system? • What systems or web services get/provide information or messages from/to the system? • Who starts up or operates the system? • Who maintains the system? • Who shuts down the system? • What other systems use this system? • What other systems interact with this system? • Who (or what) provides information to this system? • Does anything happen automatically at a present time?

  12. Actor Profile Table Example

  13. Actor Profile Characteristics

  14. 3 - Identify the User Interactions with a System • Purpose: • Identify goals that clearly express why a specified actor performs a particular task • Identify WHO will interface with the system (actors) and WHAT functionality is included in the system (use cases) • Solidify SCOPE of the project with a defined set of Actors and Use Cases • Method: • Establishing User Interactions with a System may require multiple process modeling tools to understand a customer’s business process • Data Flow Diagram • Use Case Diagram • Process Flow Diagram • Suggested Deliverable(s): • Use Case Diagram • Use Case Catalog

  15. Multiple Process Modeling Tools to Define User Interactions • Process Flow Diagram (PFD) • Schematic representation of a process • Breaks a process down to a finite number of steps that get executed one at a time • Explains when a decision is required in the system, and what next process steps must be executed based on a decision • Does NOT focus on inputs and outputs and why each process step is performed • Data Flow Diagram (DFD) • Provides a functional view from a system perspective • Shows HOW a system's environmental entities, processes, and data are interconnected • Shows flow of data through a system and models processes to define scope boundaries • Does NOT show the strict order of execution steps (unlike Process Flows) • Use Case Diagram (UCD) • Provides a functional view from an Actor’s perspective • Shows the use cases and actors in a system, and the relationships between them • Shows WHAT the system is, not how it functions • Does NOT explain how business requirements can be accomplished–hence, Use Cases

  16. Pitfalls of using DFD Techniques with UCD • A Context Diagram is functionally decomposed to create DFD processes • Each processes in a DFD must be “opened” to understand all actions an Actor is suppose to do • Functional decomposition works well for DFDs but is NOT advised for Use Cases

  17. Use Case Diagram - Core Elements and Relationships

  18. High Level Use Case Diagram Example • Notes, re: DFDs • Event (use case) names are verb-object like DFD processes and represent use goals not system functions • No data stores • Focus is on WHAT interactions an Actor (system users) requires with the system • No arrow heads for lines connecting actor and use case, since considered two-way • Each Use Case can include another Use Case's functionality or extend another Use Case with its own behavior. Figure 3 in UML-Use Case reading today

  19. Use Case Examples • Use cases do NOT describe: • User interface designs • Technology solutions • Application architecture • Use cases describe: • User goals • User’s view of the system • A set of task-related activities Good Examples of Use Case Names • Intuit QuickBooks “activities”: • Write a Check - Create an Invoice • Enter Credit Card - Charge Receive Payment • Amazon.com options for an accepted order: • Check Order Status - Change Shipping Options • Cancel Unshipped Items - Track Package • Buy a product online: • Search Catalog • Place Item in Shopping Cart • Pay for Items in Shopping Cart

  20. Use Case Catalog Example These Columns assist with Estimating, Planning, and Tracking

  21. 4 - Document each Significant Use Case Basic Structure and Components • Use Case Name • Revision History / Owner • Brief Description (Actor’s Goals) • Primary & Secondary Actors • Assumptions • Pre-Conditions • Post-Conditions • Triggers • Main Course of Events (basic flow) • Alternate Paths • Exception Paths Additional Components • Special Requirements • Business Rules • Dependencies • Open Issues • Response Time • Frequency of Use • Data Sources * * Suggest keeping data sources in the use case until they are signed off by the user. After approval, cerate a data dictionary

  22. Use Cases in SDLC Use Case Diagramsaid in the analysis and documentation of high level businessrequirements for scope & stakeholders Use Cases aid in defining functional requirementsand evaluating Change Requests Use Cases aid in designing wireframes, etc. Use Cases aid in creating test cases and user manuals Testing Phase(s)

  23. Visio Software and Database Category

  24. Q&A

  25. Back- Up

  26. Stakeholder Table Example

  27. Data Flow Diagrams • Include a title that states what system process is being modeled and whether it is an existing system or a proposed system • Number each DFD Figure • Environmental Entities (EE): • Labeled with EE number • Same EE number and name label on each diagram • If used twice on same diagram, label EE 1/1 and EE 1/2 • No data flows between EEs • Data Flow: • Arrow pointing in direction of data flow • Data flows must match exactly between higher-level and lower-level DFDs • No two data flows should have the same name • Process Bubble: • Processes must transform data • Must be numbered • Numbering must be consistent across all levels of DFDs • Must have verb-object format • Actors should be included, but not necessary for Figure 0 DFD • No more than 7 processes per DFD • Data Store: • Open rectangle • Must be labeled with S number or D number • Consistent across all diagrams and levels • Do not communicate with each other or EEs directly

More Related