Notes of Rational Related
cyt
Outline
2
Capturing business requirements using use cases
• Practical principles
 Find the right boundaries for your business requirements (Principle 1:
Get the scope right)
 Structure your use case model appropriately (Principle 2: Challenge
your use case goals and Principle 3: Use requirement attributes to
determine the best use case model)
 Elaborate your business requirements further (Principle 4: Divide et
impera: Decompose by business worker)
 Describe your business use cases appropriately (Principle 5: Use
case descriptions: State what and not how)
 Connect your business use cases, avoid redundancies, and validate
your requirements (Principle 6: Produce a domain model and
Principle 7: Use entity lifecycles)
3
• Ivar Jacobson is known as the father of Use Cases.
4
UML Concepts-The 4+1 view
•
•
•
•
•
Use Case view
 Understandability
Logical View
 Functionality
Process View
 Performance
 Scalable
 Throughput
Implementation View
 Software management
Deployment View
 System topology
 Delivery
 Installation
5
Things in UML
Structural Things
Behavioral Things
1. Class
1. Interaction
2. Interface
2. State Mechanism
Grouping Things
1. Packages
Annotational Things
1. Notes
3. Collaboration
4. Use Case
5. Active Class
6. Components
7. Nodes
6
•
Rational Software Development Process
 iterative and incremental
 object-oriented
 managed and controlled
• Inception —The good idea: specifying the end-product vision and its
business case, defining the scope of the project.1
• Elaboration —Planning the necessary activities and required resources;
specifying the features and designing the architecture.
• Construction —Building the product, and evolving the vision, the
architecture and the plans until the product—the completed vision—is
ready for transfer to its users community.
• Transition —Transitioning the product to its user’s community, which
includes manufacturing, delivering, training, supporting, maintaining the
product until the users are satisfied.
7
8
Inception phase
•
Entry criteria:






•
an original vision
a legacy system
an RFP (request for proposal)
the previous generation and a list of enhancements
some assets (software, know-how, financial assets)
a conceptual prototype, or a mock-up
Exit criteria:
 an initial business case containing at least:
 a clear formulation of the product vision—the core requirements— in terms of functionality,
scope, performance, capacity, technology base
 success criteria (for instance revenue projection)
 an initial risk assessment
 an estimate of the resources required to complete the elaboration phase.
 Optionally at the end of the inception phase, we may have:
 an initial domain analysis model (~10%-20% complete), identifying the top key use
cases, and sufficient to drive the architecture effort.
 an initial architectural prototype, which at this stage may be a throw-away
prototype.
9
Elaboration Phase
• Entry criteria:
 The products and artifacts described in the exit criteria of the
previous phase.
 The plan was approved by the project management, and funding
authority, and the resources required for the elaboration phase have
been allocated.
• Exit criteria:
 a detailed software development plan
 a baseline vision, in the form of a set of evaluation criteria for the
final product
 objective, measurable evaluation criteria for assessing the results of
the initial iterations of the construction phase
 a domain analysis model (80% complete), sufficient to be able to call
the corresponding architecture ‘complete’.
 a software architecture description)
 an executable architecture baseline.
10
Construction Phase
• Entry criteria:
 The product and artifacts of the previous iteration. The iteration plan
must state the iteration specific goals:
 additional capabilities being developed: which use cases or scenarios
will be covered
 risks being mitigated during this iteration
 defects being fixed during the iteration.
• Exit criteria:
 A release description document, which captures the results of an
iteration
 Test cases and results of the tests conducted on the products,
 An iteration plan, detailing the next iteration
 Objective measurable evaluation criteria for assessing the results of
the next iteration(s).
11
12
History of UML
13
Use Cases are Employed Throughout the Process
14
Analysis and Design Overview
15
• Use case analysis




Understand the problem
Behavior
Functional requirements
A small model
• Use case design




Understand the solution
Close to real code
Add non-functional requirements
A large model
16
Use Case Analysis
17
Find key abstraction
• Essential of the system
• Source of key abstraction




Domain knowledge
Requirements
Glossary
Domain model, or the business model
18
Boundary class handles interfaces
• Intermediate between the interface and something outside
the system
• User interface, system interface, device interface classes
• At least one boundary class per actor/use case pair
19
Control class coordinates behavior
• They decouple boundary and entity objects from one
another.
• Make the system more tolerant of changes in the system
boundary.
• One control class for per use case
20
For each use case allocate responsibilities
• Identify analysis classes for basic and alternate flows
• Assign responsibilities to classes
• Build interaction diagram
21
Guidelines for assigning behavior
• Boundary class
 Communication with actor
• Entity class
 Encapsulation/manipulation of data in use case
• Control class
 Control and coordination of use case
22
23
View of Participating Classes (VoPC) for Each Use Case
• Collect each unique class from all interaction diagrams in
the use case
• Consolidate different names, like behavior
• Separate like names, different behavior
24
Use Case Design
25
Incorporate subsystem interaces
26
27
Class Design
28
29
30
31
32
Classes with ports and interfaces
33