ISOM221+Lecture+10+-+Introduction+to+Object-Oriented+Modeling+Using+the+UML

Identify system actors something human or non human

Info iconThis preview shows page 1. Sign up to view the full content.

View Full Document Right Arrow Icon
This is the end of the preview. Sign up to access the rest of the document.

Unformatted text preview: st-conditions Alternative Flows Priority Non-Functional Requirements Assumptions Source Key Steps of Use Case Modeling 1. Identify system boundaries 2. Identify system actors: something (human or non-human) that has behavior and interacts with the system 3. Identify actors’ goals for the system 4. Identify business events that fulfill these goals 5. Model (success/failure) scenarios for these events 6. Write use case descriptions to document these scenarios 25 Levels of Use Cases Initial Use Case Include Include only general use case descriptions Base Use Case Provide a complete description of the normal set of primary interactions (flows of events) Elaborated Use Case Add alternative and conditional flows of events, if any Develop extended and included use cases, if appropriate 26 Use Case Modeling Process • Key steps for initial use case modeling 1. 2. 3. 4. 5. Identify actors Create a context diagram Identify use cases* Create initial use case descriptions* Create an initial use case diagram* Identifying the Actors • The term ‘actor’ represents the ‘role’ a user plays with respect to the system • An actor can be a person or any (non-human) external entity (e.g., external system, device, external service organization) organization) that will interact with the system • Why care about actors? – Actors help analysts focus on how the system will be used, not how it will be implemented – Systems need to provide value to actors, so identifying actors helps find use cases – Actors are external to the system, so they help define the boundary of the system 27 28 *they will be covered in Lecture 11 Identifying the Actors (cont.) • When looking for actors, ask the following questions: – – – – Who or what provides inputs to the system? Who or what receives outputs from the system? Are connections required to other systems? Who will maintain information in the system? Use Case Diagram vs. DFD • Individual use cases appear more like a DFD fragment in that they identify an individual function that the system must support • In a DFD an external entity is always the original source or destination of the information and may not necessarily be the one interacting with the system • In a use case diagram, a...
View Full Document

This note was uploaded on 12/22/2010 for the course ISOM ISOM221 taught by Professor Sheunhhee during the Spring '09 term at HKUST.

Ask a homework question - tutors are online