01-intro.pdf

Object Oriented Analysis and DesignIntroduction

Matthew Dailey

Computer Science and Information ManagementAsian Institute of Technology

Matthew Dailey (CSIM-AIT) Introduction 1 / 31

Readings

Readings for these lecture notes:

- Larman (2005), Applying UML and Patterns: An Introduction toObject-Oriented Analysis and Design and Iterative Development, 3rdedition, Chapters 14.

Some material c Larman (2005).


Outline

1 Overview

2 The Unified Process

3 Getting Started: The UP Inception Phase


OverviewOOAD goals

It is difficult to deliver quality software that meets stakeholder needs!

OOAD is one method for tackling the problem by capturing the design in away that is easy to

communicate,

review,

implement, and

evolve.


OverviewThink objects!

To develop a system using OOAD, we need to know an OO language andUML, but just as important we need to think in terms of objects.

Plane

tailNumber

public class Plane{private String tailNumber;

public List getFlightHistory() {...}}

domain conceptvisualization of domain concept

representation in an object-oriented programming language

Larman (2005), Fig. 1-2

OOAD is mainly about assigning responsibilities to classes of objects.


OverviewAnalysis

OOA means finding the objects and concepts in the problem domain.

Example analysis model:

Player

name

DiceGame

Die

faceValueRolls

Plays

Includes

2

2

1

1

1

1

Larman (2005), Fig. 1-3


OverviewDesign

OOD means defining the software components, their responsiblities, andhow they collaborate to fulfill the requirements.

Example (dynamic) design model:

Larman (2005), Fig. 1-4


OverviewDesign

Design classes are the detailed classes necessary to fulfill requirements.

Example (static) design model:

2

Die

faceValue : int

getFaceValue() : introll()

DiceGame

die1 : Diedie2 : Die

play()

1

Larman (2005), Fig. 1-5


OverviewUML

We will use the Unified Modeling Language to communicate domain anddesign models.

UML has 3 uses in software engineering:

As a sketch tool: informal, incomplete diagrams sketched on awhiteboard to explore tricky problems.

As a blueprint tool: detailed diagrams used for reverse engineeringand code generation (forward engineering).

As an end-to-end programming language: still in development.

We will favor agile approaches that use UML as a sketch tool.

Dont overdo UML!


OverviewWhats next

We begin with analysis. At this point, the classes we derive will beconceptual, representing real world things in the problem domain.

Conceptual Perspective(domain model)

Raw UML class diagram notation used to visualize real-world concepts.

Specification or Implementation

Perspective(design class diagram)

Raw UML class diagram notation used to visualize software elements.

2

Die

faceValue : int

getFaceValue() : introll()

DiceGame

die1 : Diedie2 : Die

play()

DiceGame Die

faceValueIncludes 21

Larman (2005), Fig. 1-6

Later the model will be elaborated into software classes or design classesproviding a solution, and implementation classes in a real OO language.


Outline

1 Overview




The Unified ProcessThe UP

OOAD always needs to take place within some software developmentprocess.

The Unified Process is an iterative, risk-driven, architecture-centricapproach to software development.

OOAD and the UP work well together. We will explore how OOAD workswithin the context of the UP.


The Unified ProcessIterative development

The Unified Process is iterative.

Iterative development is now standard in the industry.

Compared to traditional waterfall methods, iterative development hasproven to reduce defects, increase productivity, and increase projectsuccess rates.

The basic idea is short iterations that are fixed in length or timeboxed.

The UP is sometimes criticized as too heavy, with too much modeling andtoo much documentation before coding.

But, depending on its implementation and the type of project, the UP canbe low ceremony and agile.



In an iterative process, we go through a full cycle of analysis, design,implementation, and testing disciplines in every timeboxed iteration:

Requirements

Design

Implementation &Test & Integration

& More Design

Final Integration & System Test

Requirements

Design

3 weeks (for example)The system grows incrementally.

Feedback from iteration N leads to refinement and adaptation of the requirements and design in iteration N+1.

Iterations are fixed in length, or timeboxed.

TimeImplementation &Test & Integration

& More Design

Final Integration & System Test

Larman (2005), Fig. 2-1



Iterative development is not new.

The spiral process has been around since the 1980s.

Many big projects in the 60s and 70s used iterative techniques.

The benefit is it allows us to embrace change.

On every iteration, shareholders have the opportunity to say yes, its whatI asked for, but...

Typical iterations are 26 weeks. They should be as short as possible.

Be careful to prevent the iterations from becoming waterfall phases!


The Unified ProcessHow does it work?

Example process implementation:

Two-day requirements workshop to detail the 10% of your use caseswith the highest business value, greatest risk, and highestarchitectural impact. This is the end of the inception phase.

Plan the first iteration. Pick a subset of the detailed scenarios todesign, implement and test, in a short period, e.g. 4 weeks.

Do 2 days of modeling on whiteboards.

Program, test, and integrate continuously. Stick to the plan!

One week before end of the iteration: decide what will make it intothe current iteration and postpone remainder to the next.

Demo for stakeholders and request feedback.

Repeat until 80%90% of the use cases are fully detailed and thearchitecture is baselined. This is the end of the elaboration phase.


The Unified ProcessHow does it work?

Iteration 1 Iteration 2 Iteration 3 Iteration 4 Iteration 5

20%2%

r eq u

i r em

e nt s

s of t w

a re

30%

5%

r eq u

i r em

e nt s

s of t w

a re

50%

8%

90% 90%

20%10%

requirements workshops

Imagine this will ultimately be a 20-iteration project.

In evolutionary iterative development, the requirements evolve over a set of the early iterations, through a series of requirements workshops (for example). Perhaps after four iterations and workshops, 90% of the requirements are defined and refined. Nevertheless, only 10% of the software is built.

1 2 3 4 5 ... 20

week 1

M T W Th F

week 2

M T W Th F

week 3

M T W Th F

kickoff meeting clarifying iteration goals with the team. 1 hour

team agile modeling & design, UML whiteboard sketching.5 hours

start coding & testing

a 3-week iteration

de-scope iteration goals if too much work

final check-in and code-freeze for the iteration baseline

demo and 2-day requirements workshop

next iteration planning meeting;2 hours

Most OOA/D and applying UML during this period

Use-case modeling during the workshop

Larman (2005), Fig. 2-4


The Unified ProcessUP summary

The UP is risk driven: in early iterations we identify and mitigate the mostsignificant risks.

The UP is client driven: we build the features the client cares about mostfirst.

The UP is architecture centric: we focus on the architecturally significantuse cases first.


The Unified ProcessUP and agility

UP is compatible with the agile manifesto:

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan


The Unified ProcessUP and agility

When modeling, we should apply the principles of agility:

Modeling is for understanding and communication, notdocumentation.

Model the difficult, tricky parts of the design, not the simple parts.

Use simple tools like whiteboards before CASE tools.

Dont model alone; rotate the whiteboard marker!

Do parallel models, e.g. static and dynamic.

Use good enough notation dont drown yourself in the details.

Be ready to throw your models away and reverse engineer from thecode you wrote.

There is no such thing as analysts, developers, and testers takeownership, from modeling to testing. Teams should be horizontal, notvertical.


The Unified ProcessModeling example

Example of some practical modeling:

Larman (2005), Fig. 2-5


The Unified ProcessBest practices

Best practices for UP application:

Keep your process simple only write documents that add value.

Dont try to fix all requirements and design everything in advance. Beagile get started, and be ready for change.

Attack high risk, high value issues first.

Continuously engage users.

Develop a cohesive core architecture in early iterations.

Continuously verify quality test early, often, and realistically.

Use use cases to drive development where appropriate.

Do some visual modeling.

Carefully manage requirements, change requests, and softwareconfiguration using appropriate tools.


The Unified ProcessUP phases

The phases in the UP are:

Inception: work out the initial vision, business case, and scope, withvague estimates.

Elaboration: refine the vision, develop the core architecture, resolvemajor risks, further detail the requirements.

Construction: work on the lower-risk, easier elements.

Transition: beta test and deploy


The Unified ProcessUP terms

Some UP terminology:

inc. elaboration construction transition

iteration phase

development cycle

release

A stable executable subset of the final product. The end of each iteration is a minor release.

increment

The difference (delta) between the releases of 2 subsequent iterations.

final production release

At this point, the system is released for production use.

milestone

An iteration end-point when some significant decision or evaluation occurs.

Larman (2005), Fig. 2-6


The Unified ProcessUP disciplines

Each phase in the UP involves all disciplines to an extent, with differentweightings in different phases.

Iterations

SampleUP Disciplines

Business Modeling

Requirements

Design

Implementation

Test

Deployment

Configuration & ChangeManagement

Project Management

Environment

Focusof thisbook

Note thatalthough aniteration includeswork in mostdisciplines, therelative effort anemphasis changover time.

This example issuggestive, notliteral.

A four-week iteration (for example).A mini-project that includes work in mostdisciplines, ending in a stable executable.

Larman (2005), Fig. 2-7


The Unified ProcessCommon mistakes

You are doing it wrong if you notice

You detail all the requirements before starting to program.

You spend days or weeks on UML modeling before starting toprogram.

You spend more time creating documents than programming.


Outline

1 Overview




Getting Started: The UP Inception PhaseInception goals

Before we begin to analyze and design a proposed system, we have to havean idea of what were going to build and decide whether we really shouldbuild it.

This is the goal of the inception phase.

Note: the inception phase is not the requirements gathering phase!

Inception focuses on

What is the scope of the project?

What is the vision and business case?

Is it feasible?

Buy or build?

Whats the rough cost?

Do it or not?


Getting Started: The UP Inception PhaseInception artifacts

In the inception UP phase, we may start on the following mostly optionalartifacts:

Vision and business case: high-level goals and constraints, businesscase, and executive summary of the project.

Use-case model: description of the functional requirements. Weidentify the names of most use cases and analyze about 10% of theuse cases in detail.

Supplementary specification: non-functional requirements, especiallythose that will affect the architecture.

Glossary: domain terminology.

(continued on next page...)


Getting Started: The UP Inception PhaseInception artifacts

Risk list and risk management plan: the business, technical, resource,and schedule risks, along with ideas for mitigation.

Prototypes and proofs-of-concept: experiments to clarify the visionand determine feasibility.

Iteration plan: detailed plan for the first iteration.

Phase plan and software development plan: low-precision guess onelaboration duration and effort, along with tools, people, otherresources.

Development case: customizations of standard processes for thisproject.

The only UML produced in inception will possibly be use case diagrams,but they are not necessary. Most of the artifacts are pure text.


Getting Started: The UP Inception PhaseCommon mistakes

You are executing inception incorrectly if:

Inception takes more than a few weeks.

You define the architecture.

You try to do requirements, design, and implementation.

There is no business case or vision.

Most use cases are detailed.

No use cases are detailed.


OverviewThe Unified ProcessGetting Started: The UP Inception Phase

01-intro.pdf

Documents

software classes

classes of objects

problem domain

implementation classes

example analysis model

software engineering

overviewdesigndesign

example static design