Transcript Use Case
®
IBM Software Group
PRJ270: Essentials of Rational Unified Process
Module 4: RUP Content
1
Module 4 Objectives
Be introduced to the content of RUP and its
application by investigating:
RUP disciplines
• Requirements
• Business Modeling
• Configuration & Change Management
• Environment
• Project Management
• Analysis & Design
• Implementation
• Test
• Deployment
2
Review: RUP Organization Based on Content
RUP content is organized into disciplines.
Discipline: a collection of activities that are all
related to a major “area of concern.”
The disciplines are:
Business Modeling
Requirements
Analysis & Design
Implementation
Test
Deployment
Configuration &
Change Management
Project Management
Environment
3
RUP Disciplines
RUP has disciplines.
Artifacts from each
discipline evolve over the
iterative process.
4
Disciplines Produce and Share Models
Various
disciplines
produce
Models …
Business
Modeling
Analysis &
Design
Requirements
Implementation
Input To
Business UseCase Model
B
B
B
B
Realized By
Use-Case
Model
Automated
By
Business
Object Model
… each of
those models
is Assessed
Design Model Implementation
Model
Verified By
Test
5
Validated By
Deployment
Realized
By
Implemented
By
Requirements Discipline
Purpose
Establish and maintain agreement with the
customers and other stakeholders on what the
system should do
Provide system developers with a better
understanding of the system requirements
Define the boundaries of (delimit) the system
Provide a basis for planning the technical
contents of iterations
Provide a basis for estimating cost and time to
develop the system
Define a user-interface for the system, focusing
on the needs and goals of the users
6
Requirements Types
Features: used for scoping the project
Main audience: Stakeholders
Documented in the Vision artifact
Functional Requirements: specifying interactions
with system users
Main audience: users and project team
Modeled in the Use-Case Model artifact
Supplementary Requirements: specifying
functionality, usability, reliability, performance,
supportability requirements, and design constraints
Main audience: architects and designers
Documented in the Supplementary Specifications
artifact
7
Major Concepts in the Use-Case Model
An actor represents a
person or another
system that interacts
with the system.
Actor
A use case defines a
sequence of actions a
system performs that
yields a result of
observable value to an
actor.
Use Case
8
Actor
Actors are not part of the
system. They represent
roles a user of the system
can play.
An actor can actively
interchange information
with the system.
An actor can be a passive
recipient of information.
An actor can be a giver of
information.
An actor can represent a
human, a machine or
another system.
Actor
System
9
A User Can Act as Several Actors
Charlie as depot
manager
Charlie
Depot Manager
Charlie as
depot staff
Depot Staff
10
Use Case
Use Case
A use case specifies a dialogue between an
actor and the system.
A use case is initiated by an actor to invoke
a certain functionality in the system.
A use case is a complete and meaningful
flow of events.
Taken together, all use cases constitute all
possible ways of using the system.
11
A Scenario - One Path Through a Use Case
A use case can have many instances.
A scenario is a described use-case
instance: a specific sequence of actions
that illustrates behaviors of the system.
Student
Register for
Courses
12
Course Catalog
A Sample UML Diagram: Use Cases
A University Course Registration System
Register for Courses
Student
Select Courses to Teach
Course Catalog
Professor
Maintain Professor Information
Registrar
Maintain Student Information
Close Registration
Billing System
13
What Is in a Use-Case Model?
Actors and their descriptions
Use-case diagrams showing relationships
For each use case:
Name and brief description
Textual specification of:
• Flow of events
• Pre-conditions and post-conditions (optional)
• Special requirements
• Other diagrams, such as activity or state
diagrams
14
Review: Disciplines Produce and Share Models
Various
disciplines
produce
Models …
Business
Modeling
Analysis &
Design
Requirements
Implementation
Input To
Business UseCase Model
B
B
B
B
Realized By
Use-Case
Model
Automated
By
Business
Analysis Model
… each of
those models
is Assessed
Design Model Implementation
Model
Verified By
Test
15
Validated By
Deployment
Realized
By
Implemented
By
Use Cases as a Basis for Iteration Planning
Constraints
Use-Case Model
Project
Management
Iteration Plan
Fine-grained plan for
a single iteration
Supplementary
Specifications
During Elaboration, use
cases are implemented to
validate the architecture.
16
Use Cases as a Basis for System Modeling (1)
Use-Case Model
(requirements)
realizatio
n
influence
Design Model
Implementation Model
(classes and objects)
(source code)
17
verification
Test Scripts
Use Cases as a Basis for System Modeling (2)
Use Cases
Analysis Design
Classes Classes
18
Source
Code
Exec
Use Cases as a Basis for Test Planning
The complete behavior of a use case is tested using Test
Scripts and Test Suites.
Test Script
Test Suite
Test Script
Test Suite
19
Requirements Traceability
1
Vision
2
1
Stakeholder
Needs
3
Use-Case
Model
2
Design Model
Supplementary
Specifications
3
Test Suite
4
4
Trace product
requirements
(features) into
detailed requirements
Trace requirements
into design
Trace requirements
into test procedures
Trace requirements
into user
documentation and
training materials
End-User Documentation
Materials and Training
Materials
20
Business Modeling Discipline
Purpose
Understand problems in target organization and
identify potential improvements
Ensure customer and end user have common
understanding of target organization
Derive system requirements to support target
organization
Understand structure and dynamics of
organization in which system is to be deployed
This discipline uses an approach very
similar to that of system development
21
What Business Models Show
Customers and
vendors
Business processes
Organizational
structure
Roles and
responsibilities
Products
Internal deliverables
Events
Two Business Models
Business
Use-Case Model
Business
Analysis Model
22
Business Modeling and Software Development
Business Modeling acts as:
Input to Requirements
Business Use-Case Models help you to
understand the requirements of the system and
identify system use cases
Input to Analysis & Design
Business entities from the Business Analysis
Model help identify entity classes in the Analysis
Model
23
Configuration & Change Management Discipline
Purpose: controls change to, and maintains
the integrity of, a project’s artifacts.
24
Configuration Management (CM)
Configuration Management tools
Support members of the project team (especially
those involved in development) by enabling:
Baselining of versions and concurrent development
Configuration identification and management
Configuration status accounting and change tracking
Version selection
Software manufacture
Measurement accounting by element
A framework for Work Breakdown Structure design
The Product Directory Structure contains elements
of the product under development
25
Sample Product Directory Structure
The structure should be
initiated during Inception and
detailed as the product is
defined.
26
Change Request Management (CRM)
Two basic types of requests need to be
managed:
Defects
CRM supports all members of the team by
managing the processes to acquire, assign,
correct, and report defect-related activities.
Enhancement Requests
CRM supports the Change Control Board in the
administration of assessment and disposition of
product change proposals.
27
Change Request Management (CRM)
28
Measurement
Quality:
Describes the state of the product based on the
type, number, rate, and severity of defects
found and fixed during the course of product
development
Progress:
Measurements derived under this aspect, either
through audits or raw data, are useful in
determining the overall completeness status of
the project.
29
Environment Discipline
Purpose: Focuses on the activities
necessary to configure the process for a
project. Defines what improvements are
realistic under the project’s circumstances:
• Current process
• Current tools
• Current staff skills and capabilities for change
• Current problems and possible improvement
objectives
30
Important Environment Artifacts
Development Process: is a configuration of
the underlying RUP framework that meets
the needs of the project following it.
Development Case: describes the
development process that you have chosen
to follow in your project.
31
Development Case
Reflects decisions made by team leaders of
the project
Describes the development process that
you have chosen to follow in your project
Is contained in Environment discipline
Is created early in Inception, and updated
during project
Select from
RUP knowledge base
Minimize cost
of process definition
32
Development
Case
Development Case (Partial Example)
Artifacts
How to Use
Review
Details
Tools Used / Templates /
Examples
Incep
Elab
Const Trans
Glossary
Must
Must
Must
Must
Formal –
External
MS Word/Template: Glossary
Requirements
Management Plan
Must
Must
Must
Must
Formal –
External
RequisitePro/Template: Requirements
Management
Software
Requirements
Specification
Must
Must
Must
Must
Formal –
External
MS Word/Template: Software
Requirements Specification
Supplementary
Specification
Must
Must
Must
Must
Formal –
External
RequisitePro/Template: Supplementary
Specification
Use-Case Model
Should
Must
Must
Must
Formal –
External
Rose/Template: Use-Case Model
Use-Case Package Could
Could
Could
Could
Informal
Rose/Embedded
Stakeholder
Requests
Must
Must
Must
Must
Formal –
External
ClearQuest/Template: Stakeholder
Requests
Vision
Must
Must
Must
Must
Formal –
External
RequisitePro/Template: Vision
33
Project Management Discipline
Purpose:
Provide a framework for managing
software-intensive projects.
Provide practical guidelines for planning,
staffing, executing, and monitoring projects.
Provide a framework for managing risk.
Main artifacts are:
Project Plan
Risk Management Plan
Business Case
Iteration Plans
34
Business Case
Involves estimation of development costs
based on:
The current Product Directory Structure
Make, buy, reuse decisions made by the
architect
Estimation of project benefits to establish
ROI
Estimation fidelity improves as the project
goes through phases (shown before)
Typically the “justification” is made for the
next phase, with scoped estimates for the
rest.
35
Iteration Plan
Focus during Inception and Elaboration
Project scoping and risk reduction, especially
architectural risks
Focus during Construction and Transition
Development efficiency and product quality
36
Discussion: Strategies for Iterative Development
Incremental (1)
Incremental delivery (3)
ElaboInception ration
Prel.
Iteration
#1
Construction
#2
#n+1
#..
#m
#m+1 #m+2 . . Iter.
No.
Prel.
#1
Iteration
Co
nc
ep
tu a
Elaboration
#2
lp
r ot
o ty
pe
Transition
Prel.
#1
#2
#n+1
Iteration
Co
Ar
Re
ch
nc
lea
i te
ep
se
c
tu a
tur
al
lp
b
r ot
as
o ty
eli
pe
ne
#..
#m+1 #m+2 . . Iter.
No.
De
live
ry
#m
“Grand design” (4)
Evolutionary (2)
Inception
Inception
Transition
Construction
Elaboration
#n+1
#..
Construction
Inception
Transition
Elaboration
Construction
Transition
#1
#m+1 #m+2 . . Iter.
No.
Ar
Re
De
ch
lea
live
i te
se
ry
ctu
r al
ba
se
lin
e
#m
Co
37
nc
ep
tu
Ar
ch
al
pr o
i te
to t
#2
Re
ctu
ra
yp
e
lb
as
eli
ne
lea
#3 . .
De
se
Iter.
No.
live
ry
Planning for Iterative Development
Project Plan
Phase Plan
Iteration Plan (current)
Phases and major
milestones
What and when
Iterations for each phase
Number of iterations
Objectives
Duration
Iteration Plan (next)
“Roadmap”
Coarse-grained
Plan
38
Fine-grained
Plans
RUP Planning Guide for Microsoft® Project 2002
Free download available on RDN
Allows you to rightsize your project plan by
helping you to:
plan the number of iterations to include in each
project phase
incrementally plan each iteration by selecting
from a suggested list of:
• tasks to be undertaken
• potential deliverables and artifacts to be
produced
• roles to be responsible.
Contains one-click access to RUP
39
What You Can Do in the RUP Planning Guide
Wizards allow you to
select how many
iterations you want in
each phase, as well
as which disciplinebased RUP activities
you want in each
iteration.
Wizards allow you
to select what
deliverables you
want in each
iteration, and to
attach activities or
roles to them.
40
Analysis & Design Discipline
Purpose:
Transform the requirements into a design
of the system-to-be
Evolve a robust architecture for the
system
Adapt the design to match the
implementation environment
Primary artifact is the Design Model.
41
A Design Model:
Is an object model describing the realization
of use cases
Serves as an abstraction of the
implementation model and its source code
Is used as essential input to activities in
implementation and test
42
Use Cases Drive Analysis & Design
Analysis Model (optional)
Use-Case Model
Analysis and
Design
Design Model
Supplementary
Specifications
Architecture
Document
43
Data Model
Use-Case Realization in Analysis & Design
<<realizes>>
Use Case
(Use-Case Model)
Use Case
Use-Case Realization
(Design Model)
Sequence Diagrams
Class Diagrams
44
Collaboration Diagrams
Use-Case Analysis & Design
The complete behavior of a use case is
allocated to collaborating classes.
45
Sample UML Class Diagram
A University Course Registration System
<<boundary>>
MaintainScheduleForm
<<boundary>>
MainForm
// select maintain schedule()
1
0..1
+ // open()
+ // select 4 primary and 2 alternate offerings()
1
1
<<boundary>>
CourseCatalogSystem
1
0..*
<<control>>
RegistrationController
// add courses to schedule()
// get course offerings ()
// get course offerings()
0..1
1
<<entity>>
Schedule
// create with offerings()
46
Sample UML Sequence Diagram
:
: Student
:RegisterForCoursesForm
:
:RegistrationController
:
:CourseCatalogSystem
: Course Catalog
1: create schedule( )
2: get course offerings( )
3: get course offerings(forSemester)
4: get course offerings( )
5: display course offerings( )
6: display blank schedule( )
47
Implementation Discipline
Purpose:
Implement classes and objects in terms of
components and source code
Define the organization of the components
in terms of implementation subsystems
Test the developed components as units
Create an executable system
Primary artifact is Implementation Model.
48
What is an Implementation Model?
An Implementation
Model consists of:
Components
Implementation
Subsystems
Telephone Banking
Components include:
A
Deliverable
components, such as
executables
Components from
which the deliverables
are produced, such as
source code files
<<import>>
<<compilation>>
Trading Services
B
Components and implementation
subsystems in a Telephone Banking
System.
49
Build
A build:
Is an operational version of a system or part
of a system.
Demonstrates a subset of the capabilities
provided in the final product.
Is an integral part of the iterative lifecycle.
Provides review points.
Helps uncover integration problems as soon
as they are introduced.
50
Test Discipline
Purpose:
Finding and documenting defects in software quality
Generally advising about perceived software quality
Proving the validity of the assumptions made in design
and requirement specifications through concrete
demonstration
Validating the software product functions as designed
Validating that the requirements have been implemented
appropriately
The Test discipline:
Focuses primarily on the evaluation or assessment of
quality realized through a number of core practices
Acts in many respects as a service provider to the other
disciplines
51
Types of Test
Functionality
Performance
Function test
Benchmark test
Security test
Contention test
Volume test
Usability
Usability test
Reliability
Load test
Performance profile
Supportability
Configuration test
Integrity test
Installation test
Structure test
Stress test
Notice the match with Supplementary
Specifications Types.
52
Test Automation and Tools
Data acquisition tools
Static measurement tools
Dynamic measurement tools
Simulators or Drivers
Test management tools
53
Deployment Discipline
Purpose: Manage the activities associated
with ensuring that the software product is
available for its end users, such as:
Product deployment
Testing at the installation and target sites
Beta testing
Creating end-user support material
Creating user training material
Releasing to customer (in the form of shrinkwrapped package, download site, etc.)
54
Use Cases and End-User Documentation
Use-Case Model
Deployment
Supplementary
Specification
55
End-User Support Material
•User’s Guide
•Online Help
•Demos
•Tutorials
•Training Material
Review
RUP content is organized into disciplines. A
discipline is a collection of related activities
that are related to a major “area of concern.”
Disciplines group:
Activities that are related
The roles that perform those activities
The artifacts that result from those activities
Most disciplines produce models.
Activities in disciplines have dependencies
that cross discipline boundaries.
56
Exercises
Complete Module 4 Exercise 1: Artifact
Evolution Through Phases in the
Exercises section of your student manual.
This exercise will allow you to become
familiar with some RUP artifacts and how
they evolve through phases.
Complete Discussion Points associated with
Exercise 2.
57
58