Aima Use Case UML 20 April2016
Transcript of Aima Use Case UML 20 April2016
Use Case Diagrams
Provide structure for problem solving Experiment to explore multiple solutions Furnish abstractions to manage
complexity Reduce time-to-market for business
problem solutions Decrease development costs Manage the risk of mistakes
*Why do we use model?
The UML is a graphical language for specifying visualizing constructing documenting
the artifacts of software systems Added to the list of OMG adopted
technologies in November 1997 as UML 1.1 Most recent minor revision is UML 1.3,
adopted in November 1999 Next minor revision will be UML 1.4,
planned to be adopted in Q2 2001 Next major revision will be UML 2.0,
planned to be completed in 2002
*Quick Tour
UML NotationUML notation is useful for graphically depicting object oriented analysis and design models.
Models system requirements Facilitates design decisions Promotes communications among key players involved in the development effort Integrates system views in a complete and consistent fashion Employs a simple notation set
UML Diagrams 12 basic diagrams divided into 3 categories Structural Diagrams
Class Diagram, Object Diagram, Component Diagram, and Deployment Diagram.
Behavior Diagrams Use Case Diagram, Sequence Diagram, Activity
Diagram, Collaboration Diagram, and Statechart Diagram.
Model Management Diagrams Packages, Subsystems, and Models
UML and OOAD The techniques drawn from the UML model for OOAD include:
Use cases - represent the functional requirements of the system.
Object diagrams- graphical depiction of the objects associated with the system.
Class diagrams - show the static structure of data and operations and their relationships in a logical view of the system.
Behavior diagrams or activity diagrams - model the behavior of the system.
State diagrams - represent how objects change their states in response to events.
Sequence diagrams - show interactions between objects. Implementation diagrams including component diagrams and
deployment diagrams. Interaction or collaboration diagrams - Present an alternate or
complement to the sequence diagram that models interactions between objects in the system.
OOAD and the SDLC The object oriented development life cycle
builds on the foundation of the SDLC. But OOAD is iterative in design focusing
on the evolution of the system throughout the system development process.
For instance models built in the analysis phase are reused and refined during the design phase.
What is use case modeling? use case model: a view of a
system that emphasizes the behavior as it appears to outside users. A use case model partitions system functionality into transactions (‘use cases’) that are meaningful to users (‘actors’).
answers WHAT is the system to do
System Requirements and Use Cases
Use case diagrams are the primary focus of the requirements determination phase of analysis
Use cases describe system behavior from an external viewpoint and establish system boundaries
http://www.zoo.co.uk/~z0001039/PracGuides/pg_use_cases.htm
System Requirements and Use Cases An important aspect of use cases is that they
describe the system from the perspective of external users.
The process was designed to be inherently iterative so that developers wold involve users in discussions throughout the model development process.
This process also facilitates and enables the discovery of not yet identified system requirements.
Use cases analysis takes the place of the functional requirements stage used in SDLC.
Iterative Nature of Use Cases
Use cases control the formation of all other models used in the development process.
If user requirements change during the development process, the changes are first made in the use case model.
Changes to the use case dictate what changes need to be made in the other models.
Use Case Modeling Jacobson (and others, 1992) pioneered the application of
use case modeling for analyzing the functional requirements of a system.
Use case modeling depicts what the system is to do. It is the process of identifying and modeling business
events, who initiated them and how the system responds to them.
Use case modeling works to provide a solution to a problem by breaking down the entire scope of system functionality into many smaller views of system functionality. These smaller views of the system are often referred to as Packages. Within each package, the system is further broken down into task level functionality called 'Use Cases'
Complete Use Case modeling includes visualization (diagrams) and corresponding step-by-step documented descriptions of each identified use case.
Benefits of Use Cases Use cases are used during the entire system
development process. During analysis the use cases are used to
model functionality of the proposed system and are the starting point for identifying objects.
Use cases contain an enormous amount of system functionality detail. So they are a constant resource for validation and testing.
Use case is an invaluable vehicle for communication between developers and end users.
Definition of a Use Case A Use Case is a behaviorally related sequence of steps (a scenario), both automated and manual for the purpose of completing a single business task.
Use Case Modeling A use case model is the visualization
of a use case. A use case model has two
components: actors and use cases. Actors initiate system activity - a use
case - to complete some business task.
Note the simplicity of the model. The initial model itself it not detailed.
Fig. 3-53, UML Notation Guide
Customer
Supervisor
SalespersonPlace
Establishcredit
Check
Telephone Catalog
F ill orde rsShipping Clerk
status
order
Use Case Diagram
Characteristics of Actors
Actors represent anything that needs to interacts with the system to exchange information
An actor is a user or role that that is usually external to the system
An actor can be people as well as another system, hardware device, etc.
An actor does not represent a single individual An actor always initiates a use case. Actors are represented as stick people and Actors are given names. Because actors are outside the system, they do not need to be described in detail. Actor
Actors vs Users
Actors are different from users. A user is anyone who uses the system. An actor is a role a user plays. An actor is a type or class of users - user is a specific instance of an actor
(If the same user plays two roles, he would be represented as an instance in each class of actor, i.e. John Patton is both an instructor and advisor. He would be represented as an instance in both the actor called Instructor and the actor called Advisor.)
Characteristics of use cases
A use case is the function being described. A use case always represents complete
functionality not individual actions. A use case is a complete sequence of related
actions representing a specific way of using the system.
Use cases represent the behavior of the system in response to stimuli from an actor.
Use cases are represented as ellipses (oval).
Use Case
Actors and Temporal Events Events triggered by time are called temporal events.
Who is the actor in a temporal event?
The actor is the system itself.
Temporal Event ExampleThe backup of system data is automatically initiated to occur every night at 2:30 am. No one has to request the backup. It is a temporal event. The actor for this temporal event is the system itself.
nightly backup
system
Identifying Actors and Use Cases
One place to start is to look at context model diagrams of the system. To identify use cases, Jacobson recommends asking:
What are the main tasks performed by each actor?
Will the actor read or update any information in the system?
Will the actor have to inform the system about changes outside the system?
Does the actor have to be informed about unexpected changes?
Constructing the Use Case Model The goal is to build a use case diagram for each
significantly different kind of scenario in the system. Each scenario shows a different sequence of
interactions between actors and the system with no or conditions.
Use cases are constructed after the actors and use cases have been identified.
Use cases are often grouped in to subsystems representing logical functional areas of the system. This partitioning aids in understanding the system architecture and is key to defining your development strategy - which use cases will be developed first and by whom.
Use Case Example
<<extends>>
Owner Customer
Job/EstimateProcess
Job/Invoice Process
Late Job/Invoices
Track Customer
Customer Contact
<<extends>>
<<extends>>Office Worker
Track Job/Estimate
Old Job/Estimate
Documenting the Use Case
Each use case is documented using a step-by-step description starting with the actor initiating the use case and ending with the business event.
The description includes objective of the use case, the actor that initiates the use case and the exchange of information between the actors and the use case.
Normal Course of Events First
The normal course of events is usually documented first.
Normal course of events includes major steps that happen the majority of the time
This allows you to concentrate on the system concept without getting bogged down in too many details.
Contents of a Use Case Document (normal course of events)
• The name of the actor who initiated the case.• A high level description of the use case
• A normal event course describing the use case's major steps from beginning to end of this interaction with the actor
• Pre-condition describing the state the system is in before the use case is executed
• Post-condition describing the state the system is in after the use case is executed
• An assumptions section, which includes, any non-behavioral issues, such as performance or security, that are associated with the use case but are difficult to model within the use case's course of events.
Alternate Course of ActionA use case may also have alternate courses of actions
These alternates are deviations or branches from the normal course of events.
Alternates are documented in a separate use case.
Contents of a Use Case Document (alternate course of action)
The name of the actor who initiated the case A high level description of the use case A normal event course describing the use case's major steps
from beginning to end of this interaction with the actor Alternate course of action describing the major steps of
deviation from the normal course of action Pre-condition describing the state the system is in before the
use case is executed Post-condition describing the state the system is in after the
use case is executed An assumptions section, which includes, any non-behavioral
issues, such as performance or security, that are associated with the use case but are difficult to model within the use case's course of events.
More on developing Use Cases A use case may participate in relationships with other use cases.
There are two primary types of relationships - includes and extends.
There use to exist a relationship called ‘uses’ but it has gone away.
Fig. 3-54, UML Notation Guide
*Use Case Relationships
additional requests :
OrderProduct
Supply Arrange
«include»«include»«include»
RequestCatalog
«extend»Extension points
PaymentCustomer Data
after creation of the order
Place Order
1 * the salesperson asks forthe catalog
Extends An extends relationship, extends a use case by adding new behavior or actions.
The extends symbol is <<extends>>
When to use <<extends>> Model alternate sequences through
<<extends>> relationships Remember a use case is usually modeled
first using a normal course of actions. Then "what if" conditions are considered
and alternate courses of action are modeled in separate use cases.
These alternate use cases are related to the original use case by an "extends" relationship.
Extends
Includes The includes relationship is used to
prevent repetition of the steps required to other use cases
Includes - specifies that the base use case needs an additional use case in order to fully describe its processes.
It is mainly used to show common functionality that is shared by several use cases
Includes
When to use <<extends>> or <<includes>> Use <<extends>>
Intent is to model an extension or variation of a complete use case
Use <<includes>> The base use case must use
another use case in order to complete its process
Diagram from Popkin Software: http://www.popkin.com/images/usecase.gif
Example of Use Case Diagram for a Course Registration System
Discover ActorsActors are examined to determine their needs:
RegistrarProfessorStudent Billing System
Remember that use cases are within the system, actors are outside.
Registrar Professor Student Billing System
A use case is a pattern of behavior the system exhibits
Use cases identified: Maintain Registrar Request Course Roster Maintain Schedule Register for courses
Discover Use Cases
Maintain Curriculum
Request Course Roster
Maintain Schedule
Register for Course
Put Use Cases with ActorsEach use case is a sequence of related transactions performed by an actor and a system in a dialogue.
Actors are examined to determine their needs: Registrar - maintains curriculum Professor - requests rosters Student – registers for courses Billing System - receives information related to billing from registration
Remember that use cases are within the system, actors are outside.
BillingSystem
Student Professor
RegistrarMaintain Curriculum
Request Course Roster
Maintain Schedule
Register for Course
Relationships between use cases• A use case may participate in
relationships with other use cases. • Two common relationships are uses and
extends.
• Includes arise when one use case needs another use case.
Look for Includes
LogonValidation
Register for Course
Maintain Curriculum
Extend extends a use case by adding new behavior or actions. An extends relationship shows optional behavior. The use case that is extended must make sense without the extension.
Discover Extends
Register for CourseRequest help
Request helpRegister for Course
Use cases in opposite order – Notice the direction of the arrow
The Complete Use Case
BillingSystem
Maintain Schedule
Register for Course
Student
Professor
Request Course Roster
Registrar
Request Help
LogonValidation
<<extends>>
<<includes>>
Maintain Curriculum
<<includes>>
What’s This?
Pitfalls of Use Case Modeling The system boundary is undefined or
inconstant. The use case is written from the
system's (not the actors') point of view.
The actor names are inconsistent. There are too many use cases. The actor-to-use case relationships
resemble a spider's web.
Pitfalls continued The use-case specifications are too long. The use-case specifications are confusing. The use case doesn't correctly describe
functional entitlement. The customer doesn't understand the use
cases. The use cases are never finished. Lilly, S. Use Case Pitfalls: Top 10 Problems from Real
Projects Using Use Cases. Proceedings of TOOLS, USA 99, IEEE, 1999.
More information on the area of Use Case and Use Case Modeling
Information on Use Cases - great resource for templates, etc.: www.usecases.org
General Resources on Use Case: http://www.pols.co.uk/usecasezone/use-case-
papers.htm
Quote of the WeekThe roots of OO can be found in basic human thinking:
"In apprehending the real world, [people] constantly employ three methods of organization, which pervade all of their thinking: 1. the differentiation of experience into particular objects
and their attributes - eg. When they distinguish between a tree and its size or spatial relations to other objects.
2. the distinction between whole objects and their counterparts - eg. when they contrast a tree with its component branches, and
3. the formation of and the distinction between different classes of objects -eg. when they form the class of all trees and the class of all stones and distinguish between them."
Encyclopedia Britannica - Classification Theory