OBJECT-ORIENTED ANALYSIS AND DESIGN

Download Report

Transcript OBJECT-ORIENTED ANALYSIS AND DESIGN

lecture 1-6,Chitkara University
Stages in a Software Project
•Requirements Writing
Understanding the Client’s environment and needs.
•Analysis
Identifying the concepts (classes) in the problem domain and their static
associations
•Design
Identifying “solution domain” classes and mapping the functionality into these
classes
•Implementation
Constructing and individually testing the classes that compose the system.
•System Integration and Testing
Testing the system as a whole and doing corrective maintenance
•Maintenance
Adapting the system to a changing environment to extend its useful life
lecture 1-6,Chitkara University
The Waterfall Lifecycle Approach
Thoroughly clarify, record, or implement each phase of the project
before beginning the next. The subsequent phase is based upon the
design documentation previously developed.
Requirements
Analysis
Design
Implementation
Integration and Testing
Maintenance
lecture 1-6,Chitkara University
The Waterfall Lifecycle Approach
Problems with the Waterfall Approach
Large steps are taken in which many decisions are made without
the benefit of feedback.
Requirements and Design decisions, once established, are frozen in
place.
Speculative decisions increase and compound.
High risk or difficult problems are tackled late.
There is low adaptability for incorporating either design or
implementation concepts “learned” in the development process
into the project.
lecture 1-6,Chitkara University
The Unified Process
The Unified Process is a software development process or
methodology that above all promotes Iterative Development.
The result of each iteration is an executable, but incomplete
system. The system may need many iterations before it is
ready for production.
Benefits of iterative development include:
•Early mitigation of high risks
•Early visible progress.
•Early feedback, user engagement, and adaptation, leading
to a system that more nearly meets the needs of the various
stakeholders.
•Managed complexity – no compounding of complexity by
postponing the implementation phase.
•Learning within an iteration.
lecture 1-6,Chitkara University



Supports System Development Using the Unified
Model Language (UML)
Evolutionary process where the system is built
iteratively and incrementally in several builds
starting from the requirements phase
Architecture-centric
lecture 1-6,Chitkara University
RUP is a complete software-development process
framework , developed by Rational Corporation.
 It’s an iterative development methodology based
upon six industry-proven best practices.
 Processes derived from RUP vary from lightweight—
addressing the needs of small projects —to more
comprehensive processes addressing the needs of
large, possibly distributed project teams.

lecture 1-6,Chitkara University





RUP is divided into four phases, named:
Inception
Elaboration
Construction
Transition
lecture 1-6,Chitkara University
The Unified Process
phase
Inc.
Elaboration
phase
Construction
Trans.
iteration
Release
The end of each
iteration is a
minor release
lecture 1-6,Chitkara University
Final release
The Unified Process
Inception: Define the scope of the system (identify all external
entities with which the system will interact and define the
nature of the interactions)
Elaboration: Specify features and develop the architecture
Construction: Build the system
Transition: Transition Product to its users
lecture 1-6,Chitkara University
lecture 1-6,Chitkara University
Inception

The life-cycle objectives of the project are stated,
so that the needs of every stakeholder are
considered. Scope and boundary conditions,
acceptance criteria and some requirements are
established.
lecture 1-6,Chitkara University
Inception - Activities







Formulate the scope of the project.
Needs of every stakeholder, scope, boundary
conditions and acceptance criteria established.
Plan and prepare the business case.
Define risk mitigation strategy, develop an initial
project plan and identify known cost, schedule, and
profitability trade-offs.
Synthesize candidate architecture.
Candidate architecture is picked from various
potential architectures
Prepare the project environment.
lecture 1-6,Chitkara University
Inception - 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 (example: revenue projection).
An initial risk assessment.
An estimate of the resources required to complete the
elaboration phase.
lecture 1-6,Chitkara University

An analysis is done to determine the risks, stability of
vision of what the product is to become, stability of
architecture and expenditure of resources.
lecture 1-6,Chitkara University


The products and artifacts described in the exit
criteria of the previous phase.
The plan approved by the project management,
and funding authority, and the resources required
for the elaboration phase have been allocated.
lecture 1-6,Chitkara University
Define the architecture.

Project plan is defined. The process,
infrastructure and development environment are
described.
 Validate the architecture.
 Baseline the architecture.

To provide a stable basis for the bulk of the
design and implementation effort in the
construction phase.

lecture 1-6,Chitkara University





A detailed software development plan, with an
updated risk assessment, a management plan, a
staffing plan, a phase plan showing the number and
contents of the iteration , an iteration plan, and a
test plan
The development environment and other tools
A baseline vision, in the form of a set of evaluation
criteria for the final product
A domain analysis model, sufficient to be able to
call the corresponding architecture ‘complete’.
An executable architecture baseline.
lecture 1-6,Chitkara University

The Construction phase is a manufacturing
process. It emphasizes managing resources and
controlling operations to optimize costs, schedules
and quality. This phase is broken into several
iterations.
lecture 1-6,Chitkara University



The product and artifacts of the previous iteration.
The iteration plan must state the iteration specific
goals
Risks being mitigated during this iteration.
Defects being fixed during the iteration.
lecture 1-6,Chitkara University





Develop and test components.
Components required satisfying the use cases,
scenarios, and other functionality for the iteration
are built. Unit and integration tests are done on
Components.
Manage resources and control process.
Assess the iteration
Satisfaction of the goal of iteration is
determined.
lecture 1-6,Chitkara University





The same products and artifacts, updated, plus:
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).
lecture 1-6,Chitkara University

The transition phase is the phase where the
product is put in the hands of its end users. It
involves issues of marketing, packaging, installing,
configuring, supporting the user-community,
making corrections, etc.
lecture 1-6,Chitkara University

The product and artifacts of the previous iteration,
and in particular a software product sufficiently
mature to be put into the hands of its users.
lecture 1-6,Chitkara University




The RUP puts an emphasis on addressing very early
high risks areas.
It does not assume a fixed set of firm requirements
at the inception of the project, but allows to refine
the requirements as the project evolves.
It does not put either a strong focus on documents
The main focus remains the software product itself,
and its quality.
lecture 1-6,Chitkara University



RUP is not considered particularly “agile” However,
recent studies have shown that by adopting the
right essential artifacts RUP is agile.
It fails to provide any clear implementation
guidelines.
RUP leaves the tailoring to the user entirely.
lecture 1-6,Chitkara University
Management of a Software
Project
There are two groups involved with the management of a software
project:
“Management” – whose concern is resource allocation, delivery
dates, profit margin, etc.
Management likes “benchmarks” exemplified in the Waterfall
approach. Due dates can be set, and resources allocated to each
phase of the project, and project management documents can be
completed according to a schedule.
Technical staff – whose concern is producing a well-engineered
product within the constraints of the project.
The iterative process as emphasized in UP is a better approach for
engineering a software product, but it less suited for producing project reports
that indicate the status of the project and the completion of well-defined
phases of the work important to management.
lecture 1-6,Chitkara University
Timeboxing
Management of a UP project.
Iterations are “timeboxed” or fixed in length.
Iteration lengths of between two to six weeks are
recommended.
Each iteration period has its own development plan.
If all the planned activities cannot be completed
during an iteration cycle, the completion date should
not be extended, but rather tasks or requirements
from the iteration should be removed and added to
the next iteration cycle.
lecture 1-6,Chitkara University


The emphasis is on finding and describing the
objects (or concepts) in the problem domain.
In a Library Information System, some of the
concepts include Book, Library, and Patron.
lecture 1-6,Chitkara University
Object Oriented Analysis
OOA
OOA Develops a Logical Model of the system as a
set of interacting domain objects
• The model consists of two views
• The static view: defines the classes
and their dependencies
Requires
Class A Service
From
Class B
Class B
•The dynamic view: models the scenarios of
s:
Obj y:
interactions between objects ObjClass
A
Class B
3: Set_Alarm(message)
lecture 1-6,Chitkara University


The emphasis is defining software objects and how
they collaborate to fulfill the requirements.
In a Library Information System, a Book software
object may have a title attribute and a get
Chapter method.
lecture 1-6,Chitkara University


During Implementation, or Object-Oriented
Programming, design objects are implemented,
such as a book class in Java.
Implementation is also known as Coding or
Construction.
lecture 1-6,Chitkara University
The Unified Modeling Language
UML



UML stands for Unified Modeling Language
The UML is the standard language for visualizing,
specifying, constructing, and documenting the
artifacts of a software-intensive system
It can be used with all processes, throughout the
development life cycle, and across different
implementation technologies.
lecture 1-6,Chitkara University
The UML may be used to:
› Develop a Requirements Model
1. Use Case diagrams - Define the scope, and
display the boundary of a system & its major
functions using use cases and actors
2. System Sequence diagrams - Illustrate use case
realizations or scenarios of interactions
between the actors and the system
› Develop the Analysis model
1. Class diagrams - Represent a static structure of
a system
2. State Charts - Model the behavior of objects
lecture 1-6,Chitkara University
›
Develop the architecture design model
1. Class diagrams: Represent the static
architecture using packages or subsystems
2. Design Sequence diagrams: Represent the
dynamic interactions between the design
objects
›
Develop the physical architecture
implementation model
1. component & deployment diagrams: Reveal
the physical implementation architecture
lecture 1-6,Chitkara University
UML Development - Overview
ACTORS
USE CASES
REQUIREMENTS
ELICITATION
Time
SCENARIOS
Requirements
Engineering
System/Object
SEQUENCE
DIAGRAMS
ANALYSIS
ANALYSIS
Specify Domain CLASS DIAGRAM(S)
Objects
StateChart
DIAGRAMs
OPERATION CONTRACTS
Architectural
Design
SUBSYSTEM CLASS/
Include
OR COMPONENT
Design Objects
DIAGRAMS
DEPLOYMENT DIAGRAM
DESIGN SEQUENCE DIAG.
DESIGN DIAGRAMS
Detailed DESIGN
Object
Design
IMPLEMENTATION
CHOICES
IMPLEMENTATION
IMPLEMENTATION
Activity DIAGRAMS
PROGRAM
lecture 1-6,Chitkara University
D
A
T
A
D
I
C
T
I
O
N
A
R
Y
UML Diagrams
Structural diagrams – Used to describe the
building blocks of the system – features that do
not change with time. These diagrams answer
the question – What's there?
Behavioral diagrams – Used to show how the
system evolves over time (responds to requests,
events, etc.)
lecture 1-6,Chitkara University
UML Diagrams
lecture 1-6,Chitkara University
UML Diagrams
lecture 1-6,Chitkara University