Transcript Objecvt-Oriented Analysis and Design

CSC 520
Advanced Object-Oriented
Analysis and Design
Applying UML and Patterns
 UML is
a standard diagrammatic notation
 UML Tools of interest, but not critical
 Possibly the most critical skill is proper
assignment of responsibilities to
components
 Patterns – well known, best-practice
solutions to common problems
Prerequisite Activity
Requirements Analysis
 Use Cases
 Unified Process - UP – an iterative development
process
 Use:




apply principles and patterns to create better object
designs
Follow a set of common activities in analysis and design
based on the UP
Create frequently used diagrams in the UML notation
Other Skills Needed
Usability engineering
 User Interface Design
 Database Design


Most critical skills

Assignment of responsibilities to classes of objects



How should objects interact?
Answers strongly influence the robustness,
maintainability, and reusability of the components
Emphasis:

principles of responsibility assignment
Object-Oriented A and D

Object-oriented analysis


Object-oriented design


emphasizes the finding and describing the objects in the
problem domain.
emphasizes the definition of software objects and how
they collaborate to fulfill the requirements.
Object-oriented programming

the design objects are implemented.
Object-Oriented Analysis
 An
investigation of the problem (rather than
how a solution is defined)
 During OO analysis, there is an emphasis
on finding and describing the objects (or
concepts) in the problem domain.
 For
example, concepts in a Library Information
System include Book, and Library.
Object-Oriented Design
Emphasizes a conceptual solution that fulfils he
requirements.
 Need to define software objects and how they
collaborate to fulfil the requirements.



For example, in the Library Information System, a Book
software object may have a title attribute and a
getChapter method.
Designs are implemented in a programming
language.

In the example, we will have a Book class in Java.
From Design to Implementation?
Analysis
investigation
of the problem
Book
(concept)
Domain concept
Design
logical solution
Book
title
print()
Construction
code
public class Book {
public void print();
private String title;
}
Representation in an
Representation in
analysis of concepts object-oriented
programming language.
Analysis and Design

Analysis emphasizes an investigation of the
problem and its requirements, not the solution.


In this context, it is best described as object analysis, an
investigation of the domain objects
Design emphasizes a conceptual solution that
fulfills the requirements, not the implementation.

In this context, it is best described as object design.
The Unified Process
Define
Use
Cases
Define
Domain
Model
Define
Interaction
Diagrams
Define
Design Class
Diagrams
Use Cases
 Use
cases are not object oriented
components
 Very popular and extraordinary useful in
describing the requirements
 An important part of the unified process
(UP)
An Example:
The Dice Game
 A Use
Case:
A player picks up and rolls the dice. If the
dice face value total seven, the player wins;
otherwise, the player loses.
Domain Model

a decomposition of the domain model involves
an identification of its




concepts
attributes
associations
This decomposition is shown in a domain model


not software objects
a visualization of the real-world domain.
Domain Model
Player
rolls
1
1
Die
2
2
plays
1
Dice Game
1
includes
What about Yahtzee?
Interaction Diagrams
 objects
interact and collaborate with one
another.
 Interaction diagrams capture this interaction
and show the flow of “messages” from
object to object.
Interaction Diagrams
:DiceGame
:Die1
play()
roll()
fv1 = getFaceValue()
roll()
fv2 = getFaceValue()
:Die2
Class Diagrams
 Interaction
diagrams capture the dynamic
view
 Class diagrams capture the static
relationship between classes.
 It illustrates the attributes and methods of a
class and the classes relationship to other
classes
Class Diagrams
Dice Game
die1 : Die
Die
1
2
faceValue : int
die2 : Die
getFaceValue() : int
play()
roll()
Iterative Development and
the Unified Process
 Waterfall
approach vs the iterative approach
 Sometimes called incremental development
 UP combines commonly accepted best
practices and activities into a cohesive and
well-documented description
 The most important UP idea is iterative
development
Waterfall Approach

Assumes that it's possible to capture all
requirements and complete analysis before design
starts

divided into several consecutive phases:







Product Specification
High Level Design
Low Level Design
Coding
Testing
Introduction
To enter a new phase is only allowed, if the final
checkpoint of the previous phase has been passed
successfully.
Waterfall Approach
 basis
of design was to minimize the use of
very expensive computing resources.
 A vestige
of the time in which it was developed,
where computer time was most precious
 development time is now the most expensive
part of a project budget.
Waterfall Approach
Iterative Approach

The advent of new object oriented programming
languages like Smalltalk and Java caused many
s/w developers to discard the waterfall approach in
favor of an iterative approach


often called "spiral" or "fountain".
normally starts with a first draft of a program.

This draft (sometimes called a prototype) is then discussed and
refined in various iterations until it is commonly accepted.
Iterative Approach

advocates claim it will generate results which are
better accepted by the potential end users.



Because these potential end users get an impression
relatively early about the look and feel of the new
product by playing around with the early "prototypes".
Potential end users can influence the product very
directly from early development.
Experience shows that projects not performed
under the stringent rules of the waterfall model
tend to exceed established schedules significantly.

Conflict exists between "time to market" and product
acceptance.
Iterative Approach
Iterative Development
Development is organized into a series of short
fixed-length mini-projects called iterations.
 The outcome of each iteration is a tested,
integrated and executable system.
 An iteration represents a complete development
cycle: it includes its own treatment of
requirements, analysis, design, implementation
and testing activities.

Iterative and Incremental
Development
Iteration 1
Requirements
Design
Implementation
&
Test & More
Design
eg, about 4 weeks
Iteration 2
Requirements
Design
Implementation
&
Test & More
Design
The system
grows
incrementally
Iterative Development
The iterative lifecycle is based on the successive
enlargement and refinement of a system though
multiple iterations with feedback and adaptation.
 The system grows incrementally over time,
iteration by iteration.
 The system may not be eligible for production
deployment until after many iterations.

Iterative Development
[iteration N]
Requirements – Analysis - Design- Implementation - Testing
[iteration N+1]
Requirements – Analysis - Design- Implementation - Testing
Feedback from iteration N leads to
refinement and adaptation of the
requirements and design in iteration
N+1.
The system grows
incrementally.
Iterative Development
 The
output of an iteration is not an
experimental prototype but a production
subset of the final system.
 Each iteration tackles new requirements and
incrementally extends the system.
 An iteration may occasionally revisit
existing software and improve it.
Benefits

early, rather than late, mitigation of high risks
(technical, requirements, objectives, usability, etc.)
early visible progress
 early feedback, user engagement, and
adaptation leading to a refined system that
meets the real needs of the users.
 managed complexity
 learning within an iteration can be used to
improve the development process

Time-boxing Iterations
 A specific
time frame for an iteration
 If
it will (may?) not be met, drop some tasks
or requirements from the iteration
 recommended
 Problem:
time is 2 to 6 weeks.
Can time frame be realistically be
accommodated?
Which Approach?

At least for larger development projects the following
arguments and statements will hold:

To achieve good results in a reasonable time frame, an
evolutionary development approach normally needs highly skilled
all-round developers


Problem: Easier said than found
A staged development with well defined intermediate results based
on the envisaged functionality providing the basis for the future
work allows to use specialists to generate these intermediate
results.

Good specialists for development stages like "Business Analysis",
"Business Design", "Technical High and Low Level Application
Design", or "Coding and Testing" are not so rare as really good allround developers.
 the intermediate results (e.g. in the form of business models which are by
themselves valuable deliverables) may be conserved and updated
independently for future usage.
Which Approach?

True Statements (continued):

Staged development cannot react to requirement
changes affecting product acceptance during product
introduction as quickly as an evolutionary approach.


A trade-off between "time to market", "product appearance",
and "product functionality" may have to be made according to
the envisaged lifetime of the product.
A purely evolutionary development approach tends to
lengthen the development time and increase
development costs because of uncontrolled and
permanent changes.

may create a lot of required adaptations even in parts which
seem to have been finished. Risk increases, for customer to get
impatient, forcing release of an early version of the product
(comprising very likely a lot of compromises) or even
cancellation
Which Approach?

True Statements (continued):

A smart combination of a staged development
supported by an ingenious waterfall approach and
disciplined evolutionary development can result in a
reasonable "time to market" and an acceptable "quality"
(functionality, user friendliness, efficiency) as well as a
good long term "profitability" of the product, because
the maintenance costs promise to be low, the lifetime of
the program tends to be long, and at least intermediate
results like business analysis and business design may
be reused for successor projects.
Advantages of Hybrid Approach


There are a few important milestones which allow the
management to decide about a go or no-go of the
development.
For each development phase the adequate specialists can
be hired, contributing significantly to the overall quality of
the envisaged product.


It is much more likely that an established schedule is met, because
there is no (or only a short) learning phase for these specialists and
due to that only a small number of unproductive iteration cycles.
It can be decided individually and independently for each
phase how it's development progress should be controlled.

For tasks dealing mainly with problem analysis, product design,
and product specification an iterative approach can be selected. For
coding and testing as well as for information development a staged
approach with adequate checkpoints can be used, hence validating
the hybrid approach.
More Best Practices
 consider
high risk, high value issues early
 continuously engage users for feedback
 build a cohesive, core architecture early
 test early, often, and realistically
 test against the use cases
 Use a UML tool
 carefully manage requirements
The Unified Process(UP) Phases

Inception –


Elaboration –


refined vision, iterative implementation, resolution of
high risks, identification of most requirements and
scope, more realistic estimates – not the requirements
phase
Construction –


approximate vision, scope, vague estimates, business
case – a feasibility phase
iterative implementation of lower risk elements and
preparation for deployment
Transition –

beta tests and deployment
UP Disciplines


A discipline is a set of activities and related artifacts in one
subject such as requirements analysis.
An artifact is the general term used for something
produced by that discipline such as use cases.


Software artifact: Any piece of software (i.e. models/descriptions)
developed and used during software development and
maintenance. Examples are requirements specifications,
architecture and design models, source and executable code
(programs), configuration directives, test data, test scripts, process
models, project plans, various documentation etc. etc.
Work goes on in almost all disciplines during an iteration.
(See fig. 2.4)
Development Case
 Artifacts
are optional
 what
is produced at each phase and each
iteration is project dependent
 pick the ones that most address the needs of the
project
 Write
a
a development case
chart that describes which artifacts will be
used
Case Study
Fred’s PRC
Refill Center – PRC
 See Use Cases and Scenarios for the PRC
 In any application, consider
 Prescription
 User
Interfaces
 Application logic and domain objects
 Technical Services – Databases, error logging,
etc. - things that are application independent.
Inception
 What
is the business case for the project?
 Is it Feasible?
 Buy and/or build
 Rough estimate of cost?
 Proceed or stop?
Artifacts of Inception
Business Case – a description of the high level
goals
 Use-Case Model
 Supplementary Specifications
 Risk list and management
 Prototype(?)
 Iteration Plan
 Phase plan & software development plan
 Development Case
