Notes of Rational Related cyt
Jan 03, 2016
Notes of Rational Related
cyt
2
Outline
3
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)
4
• Ivar Jacobson is known as the father of Use Cases.
5
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
6
Things in UML
Structural Things Annotational ThingsGrouping ThingsBehavioral Things
1. Class
2. Interface
3. Collaboration
4. Use Case
5. Active Class
6. Components
7. Nodes
2. State Mechanism
1. Interaction 1. Packages 1. Notes
7
• 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.
8
9
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.
10
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.
11
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 wil
l 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 iter
ation 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).
12
13
History of UML
14
Use Cases are Employed Throughout the Process
15
Analysis and Design Overview
16
• 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
17
Use Case Analysis
18
Find key abstraction
• Essential of the system• Source of key abstraction
Domain knowledge Requirements Glossary Domain model, or the business model
19
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
20
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
21
For each use case allocate responsibilities
• Identify analysis classes for basic and alternate flows
• Assign responsibilities to classes
• Build interaction diagram
22
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
23
24
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
25
Use Case Design
26
Incorporate subsystem interaces
27
28
Class Design
29
30
31
32
33
Classes with ports and interfaces