Upload
padmapria-sivakumar
View
228
Download
0
Embed Size (px)
Citation preview
8/4/2019 Rational Unified rup
1/27
RATIONAL UNIFIED
MODELLING
8/4/2019 Rational Unified rup
2/27
Traditional Structured Analysis
4 Described by W. W. Royce, 1970, IEEE WESCON,Managing the development of large softwaresystems.
4 Decomposition in terms of Function and Data
4 Data was not encapsulated:
Global Scope
File Scope
Function Scope (automatic, local)
4 Waterfall Method of Analysis and Design
8/4/2019 Rational Unified rup
3/27
Waterfall Process Assumptions
4 Requirements are known up front before design
4 Requirements rarely change
4 Users know what they want, and rarely need
visualization
4 Design can be conducted in a purely abstract space,or trial rarely leads to error
4 The technology will all fit nicely into place whenthe time comes (the apocalypse)
4 The system is not so complex.
8/4/2019 Rational Unified rup
4/27
Structured Analysis Problems
4 Reuse is complicated because Data is strewn throughout
many different functions
Reuse is usually defined as code reuse and is
implemented through cutting and pasting of the samecode in multiple places. What happens when the logic
changes?
coding changes need to be made in several different
places changing the function often changes the API which
breaks other functions dependent upon that API
data type changes need to be made each time they are
used throughout the application
8/4/2019 Rational Unified rup
5/27
Waterfall Process Limitations
4 The proof of the concept is relegated to the very end of along singular cycle. Before final integration, only
documents have been produced.4 Late deployment hides many lurking risks:
technological
conceptual
personnel
User doesn't get to see anything real until the very end
System Testing doesn't get involved until later in theprocess.
8/4/2019 Rational Unified rup
6/27
The Rational Unified Process
4 RUP is a method of managing OO Software Development
4 It can be viewed as a Software Development Framework
which is extensible and features:
Iterative Development Requirements Management
Component-Based Architectural Vision
Visual Modeling of Systems
Quality Management Change Control Management
8/4/2019 Rational Unified rup
7/27
RUP Features
4 Online Repository of Process Information
and Description in HTML format
4 Templates for all major artifacts, including:RequisitePro templates (requirements tracking)
Word Templates for Use Cases
Project Templates for Project Management4 Process Manuals describing key processes
8/4/2019 Rational Unified rup
8/27
The Phases
8/4/2019 Rational Unified rup
9/27
An Iterative Development Process...
4 Recognizes the reality of changing requirements
4 Promotes early risk mitigation, by breaking down the system into mini-
projects and focusing on the riskier elements first
4 Allows you to plan a little, design a little, and code a little
4 Encourages all participants, including testers, integrators, and technicalwriters to be involved earlier on
4 Allows the process itself to modulate with each iteration, allowing you
to correct errors sooner and put into practice lessons learned in the
prior iteration
4 Focuses on component architectures, not final big bang deployments
8/4/2019 Rational Unified rup
10/27
An Incremental Development Process...
4 Allows for software to evolve, not be produced in one
huge effort
4 Allows software to improve, by giving enough time to the
evolutionary process itself4 Forces attention on stability, for only a stable foundation
can support multiple additions
4 Allows the system (a small subset of it) to actually run
much sooner than with other processes4 Allows for the management of risk, by exposing problems
earlier on in the development process
8/4/2019 Rational Unified rup
11/27
Goals and Features of Each Iteration
4 The primary goal of each iteration is to slowly chip away
at the risk facing the project, namely:
performance risks
integration risks (different vendors, tools, etc.) conceptual risks (ferret out analysis and design flaws)
4 Perform a miniwaterfall project that ends with a delivery
of something tangible in code, available for scrutiny by the
interested parties, which produces validation or correctives4 Each iteration is risk-driven
4 The result of a single iteration is an increment--an
incremental improvement of the system, yielding an
evolutionary approach
8/4/2019 Rational Unified rup
12/27
The Development Phases
4 Inception Phase
4 Elaboration Phase
4 Construction Phase
4 Transition Phase
8/4/2019 Rational Unified rup
13/27
Inception Phase
4 Overriding goal is obtaining buy-in from all interested
parties
4 Initial requirements capture
4
Cost Benefit Analysis4 Initial Risk Analysis
4 Project scope definition
4 Defining a candidate architecture
4 Development of a disposable prototype4 Initial Use Case Model (10% - 20% complete)
4 First pass at a Domain Model
8/4/2019 Rational Unified rup
14/27
Elaboration Phase
4 Requirements Analysis and Capture
Use Case Analysis
Use Case (80% written and reviewed by end of phase)
Use Case Model (80% done)
Scenarios Sequence and Collaboration Diagrams
Class, Activity, Component, State Diagrams
Glossary (so users and developers can speak common vocabulary)
Domain Model
to understand the problem: the systems requirements as they existwithin the context of the problem domain
Risk Assessment Plan revised
Architecture Document
8/4/2019 Rational Unified rup
15/27
Construction Phase
4 Focus is on implementation of the design:
cumulative increase in functionality
greater depth of implementation (stubs fleshed out)
greater stability begins to appear implement all details, not only those of central
architectural value
analysis continues, but design and coding predominate
8/4/2019 Rational Unified rup
16/27
Transition Phase
4 The transition phase consists of the transfer of the system
to the user community
4 It includes manufacturing, shipping, installation, training,
technical support and maintenance4 Development team begins to shrink
4 Control is moved to maintenance team
4 Alpha, Beta, and final releases
4 Software updates
4 Integration with existing systems (legacy, existing
versions, etc.)
8/4/2019 Rational Unified rup
17/27
Elaboration Phase in Detail
4 Use Case Analysis
Find and understand 80% of architecturally significant
use cases and actors
Prototype User Interfaces
Prioritize Use Cases within the Use Case Model
Detail the architecturally significant Use Cases (write
and review them)
4 Prepare Domain Model of architecturally significant
classes, and identify their responsibilities and central
interfaces (View of Participating Classes)
8/4/2019 Rational Unified rup
18/27
Use Case Analysis
4 What is a Use Case?
A sequence of actions a system performs that yields a
valuable result for a particular actor.
4 What is an Actor?
A user or outside system that interacts with the system
being designed in order to obtain some value from that
interaction
4 Use Cases describe scenarios that describe the interactionbetween users of the system and the system itself.
4 Use Cases describe WHAT the system will do, but never
HOW it will be done.
8/4/2019 Rational Unified rup
19/27
Benefits of Use Cases
4 Use cases are the primary vehicle for requirements capture
in RUP
4 Use cases are described using the language of the customer
4 Use cases provide a contractual delivery process (RUP isUse Case Driven)
4 Use cases provide an easily-understood communication
mechanism
4 When requirements are traced, they make it difficult forrequirements to fall through the cracks
4 Use cases provide a concise summary of what the system
should do at an abstract (low modification cost) level.
8/4/2019 Rational Unified rup
20/27
Use Case Model Survey
4 The Use Case Model Survey is to illustrate, in
graphical form, the universe of Use Cases that the
system is contracted to deliver.
4 Each Use Case in the system appears in theSurvey with a short description of its main
function.
Participants:
Domain Expert
Architect
Analyst/Designer (Use Case author)
Testing Engineer
8/4/2019 Rational Unified rup
21/27
Sample Use Case Model Survey
8/4/2019 Rational Unified rup
22/27
Analysis Model
4 In Analysis, we analyze and refine the requirements described in the
Use Cases in order to achieve a more precise view of the requirements,
without being overwhelmed with the details
4 Again, the Analysis Model is still focusing on WHAT were going to
do, not HOW were going to do it (Design Model). But what were
going to do is drawn from the point of view of the developer, not from
the point of view of the customer
4 Whereas Use Cases are described in the language of the customer, the
Analysis Model is described in the language of the developer:
Boundary Classes
Entity Classes
Control Classes
8/4/2019 Rational Unified rup
23/27
Why spend time on the Analysis Model, why
not just face the cliff?
4 By performing analysis, designers can
inexpensively come to a better understanding of
the requirements of the system
4 By providing such an abstract overview,newcomers can understand the overall architecture
of the system efficiently, from a birds eye view,
without having to get bogged down with
implementation details.
4 The Analysis Model is a simple abstraction of
what the system is going to do from the point of
view of the developers.
8/4/2019 Rational Unified rup
24/27
Boundary Classes
4 Boundary classes are used in the Analysis Model to model interactions
between the system and its actors (users or external systems)
4 Boundary classes are often implemented in some GUI format (dialogs,
widgets, beans, etc.)
4 Boundary classes can often be abstractions of external APIs (in thecase of an external system actor)
4 Every boundary class must be associated with at least one actor:
8/4/2019 Rational Unified rup
25/27
Entity Classes
4 Entity classes are used within the Analysis
Model to model persistent information
4
Often, entity classes are created fromobjects within the business object model or
domain model
8/4/2019 Rational Unified rup
26/27
Control Classes
4 Control classes model abstractions that coordinate, sequence, transact,
and otherwise control other objects
4 Control classes are often encapsulated interactions between other
objects, as they handle and coordinate actions and control flows.
8/4/2019 Rational Unified rup
27/27
THANK YOU