Object Oriented Analysis and Design Introduction

Matthew Dailey
Computer Science and Information Management Asian Institute of Technology

Matthew Dailey (CSIM-AIT)

Introduction

1 / 31

Readings

Readings for these lecture notes: - Larman (2005), Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development, 3rd edition, Chapters 14. Some material c Larman (2005).

Matthew Dailey (CSIM-AIT)

Introduction

2 / 31

Outline

Overview

The Unied Process

Getting Started: The UP Inception Phase

Matthew Dailey (CSIM-AIT)

Introduction

3 / 31

Overview
OOAD goals

It is dicult to deliver quality software that meets stakeholder needs! OOAD is one method for tackling the problem by capturing the design in a way that is easy to communicate, review, implement, and evolve.

Matthew Dailey (CSIM-AIT)

Introduction

4 / 31

Overview
Think objects!

To develop a system using OOAD, we need to know an OO language and UML, but just as important we need to think in terms of objects.
Plane domain concept tailNumber visualization of domain concept

representation in an object-oriented programming language

public class Plane { private String tailNumber; public List getFlightHistory() {...} }

Larman (2005), Fig. 1-2

OOAD is mainly about assigning responsibilities to classes of objects.

Matthew Dailey (CSIM-AIT)

Introduction

5 / 31

Overview
Analysis

OOA means nding the objects and concepts in the problem domain. Example analysis model:
Player name 1 Plays 1 DiceGame 1 Includes 1 Rolls 2 Die faceValue 2

Larman (2005), Fig. 1-3

Matthew Dailey (CSIM-AIT)

Introduction

6 / 31

Overview
Design

OOD means dening the software components, their responsiblities, and how they collaborate to fulll the requirements. Example (dynamic) design model:

Larman (2005), Fig. 1-4

Matthew Dailey (CSIM-AIT) Introduction 7 / 31

Overview
Design

Design classes are the detailed classes necessary to fulll requirements. Example (static) design model:
DiceGame die1 : Die die2 : Die play() 1 2 Die faceValue : int getFaceValue() : int roll()

Larman (2005), Fig. 1-5

Matthew Dailey (CSIM-AIT)

Introduction

8 / 31

Overview
UML

We will use the Unied Modeling Language to communicate domain and design models. UML has 3 uses in software engineering: As a sketch tool: informal, incomplete diagrams sketched on a whiteboard to explore tricky problems. As a blueprint tool: detailed diagrams used for reverse engineering and 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!

Matthew Dailey (CSIM-AIT)

Introduction

9 / 31

Overview
Whats next

We begin with analysis. At this point, the classes we derive will be conceptual, representing real world things in the problem domain.
DiceGame 1 Includes 2 Die faceValue Conceptual Perspective (domain model) Raw UML class diagram notation used to visualize real-world concepts.

DiceGame die1 : Die die2 : Die play() 2

Die faceValue : int getFaceValue() : int roll()

Specification or Implementation Perspective (design class diagram) Raw UML class diagram notation used to visualize software elements.

Larman (2005), Fig. 1-6

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

Matthew Dailey (CSIM-AIT)

Introduction

10 / 31

Outline

Overview

The Unied Process

Getting Started: The UP Inception Phase

Matthew Dailey (CSIM-AIT)

Introduction

11 / 31

The Unied Process

The UP

OOAD always needs to take place within some software development process. The Unied Process is an iterative, risk-driven, architecture-centric approach to software development. OOAD and the UP work well together. We will explore how OOAD works within the context of the UP.

Matthew Dailey (CSIM-AIT)

Introduction

12 / 31

The Unied Process

Iterative development

The Unied Process is iterative. Iterative development is now standard in the industry. Compared to traditional waterfall methods, iterative development has proven to reduce defects, increase productivity, and increase project success rates. The basic idea is short iterations that are xed in length or timeboxed. The UP is sometimes criticized as too heavy, with too much modeling and too much documentation before coding. But, depending on its implementation and the type of project, the UP can be low ceremony and agile.

Matthew Dailey (CSIM-AIT)

Introduction

13 / 31

The Unied Process

Iterative development

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 Time Requirements Design Implementation & Test & Integration & More Design Final Integration & System Test Feedback from iteration N leads to refinement and adaptation of the requirements and design in iteration N+1.

3 weeks (for example) Iterations are fixed in length, or timeboxed. The system grows incrementally.

Larman (2005), Fig. 2-1

Matthew Dailey (CSIM-AIT)

Introduction

14 / 31

The Unied Process

Iterative development

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 benet is it allows us to embrace change. On every iteration, shareholders have the opportunity to say yes, its what I 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!

Matthew Dailey (CSIM-AIT)

Introduction

15 / 31

The Unied Process

How does it work?

Example process implementation: Two-day requirements workshop to detail the 10% of your use cases with the highest business value, greatest risk, and highest architectural impact. This is the end of the inception phase. Plan the rst iteration. Pick a subset of the detailed scenarios to design, 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 into the 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 the architecture is baselined. This is the end of the elaboration phase.
Matthew Dailey (CSIM-AIT) Introduction 16 / 31

The Unied Process

How does it work?
1 2 3 4 5 ... 20

requirements workshops Imagine this will ultimately be a 20iteration 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.

requirements

requirements

software

software

90%

90%

50% 20% 2% Iteration 1 30% 5% Iteration 2 a 3-week iteration 8% Iteration 3 10% Iteration 4 20% Iteration 5

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

de-scope iteration goals if too much work

final check-in and codefreeze for the iteration baseline Use-case modeling during the workshop

demo and 2-day requirements workshop

next iteration planning meeting; 2 hours

Most OOA/D and applying UML during this period

Larman (2005), Fig. 2-4

Matthew Dailey (CSIM-AIT) Introduction 17 / 31

The Unied Process

UP summary

The UP is risk driven: in early iterations we identify and mitigate the most signicant risks. The UP is client driven: we build the features the client cares about most rst. The UP is architecture centric: we focus on the architecturally signicant use cases rst.

Matthew Dailey (CSIM-AIT)

Introduction

18 / 31

The Unied Process

UP 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

Matthew Dailey (CSIM-AIT)

Introduction

19 / 31

The Unied Process

UP and agility

When modeling, we should apply the principles of agility: Modeling is for understanding and communication, not documentation. Model the dicult, 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 the code you wrote. There is no such thing as analysts, developers, and testers take ownership, from modeling to testing. Teams should be horizontal, not vertical.
Matthew Dailey (CSIM-AIT) Introduction 20 / 31

The Unied Process

Modeling example

Example of some practical modeling:

Larman (2005), Fig. 2-5

Matthew Dailey (CSIM-AIT) Introduction 21 / 31

The Unied Process

Best practices

Best practices for UP application: Keep your process simple only write documents that add value. Dont try to x all requirements and design everything in advance. Be agile get started, and be ready for change. Attack high risk, high value issues rst. 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 software conguration using appropriate tools.
Matthew Dailey (CSIM-AIT) Introduction 22 / 31

The Unied Process

UP phases

The phases in the UP are: Inception: work out the initial vision, business case, and scope, with vague estimates. Elaboration: rene the vision, develop the core architecture, resolve major risks, further detail the requirements. Construction: work on the lower-risk, easier elements. Transition: beta test and deploy

Matthew Dailey (CSIM-AIT)

Introduction

23 / 31

The Unied Process

UP terms

Some UP terminology:
development cycle iteration phase

inc.

elaboration

construction

transition

milestone An iteration endpoint when some significant decision or evaluation occurs.

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.

Larman (2005), Fig. 2-6

Matthew Dailey (CSIM-AIT)

Introduction

24 / 31

The Unied Process

UP disciplines

Each phase in the UP involves all disciplines to an extent, with dierent weightings in dierent phases.
A four-week iteration (for example). A mini-project that includes work in most disciplines, ending in a stable executable. Sample UP Disciplines Business Modeling Focus of this book Requirements Design Implementation Test Deployment Configuration & Change Management Project Management Environment Iterations Note that although an iteration includes work in most disciplines, the relative effort an emphasis chang over time. This example is suggestive, not literal.

Larman (2005), Fig. 2-7

Matthew Dailey (CSIM-AIT) Introduction 25 / 31

The Unied Process

Common 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 to program. You spend more time creating documents than programming.

Matthew Dailey (CSIM-AIT)

Introduction

26 / 31

Outline

Overview

The Unied Process

Getting Started: The UP Inception Phase

Matthew Dailey (CSIM-AIT)

Introduction

27 / 31

Getting Started: The UP Inception Phase

Inception goals

Before we begin to analyze and design a proposed system, we have to have an idea of what were going to build and decide whether we really should build 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?
Matthew Dailey (CSIM-AIT) Introduction 28 / 31

Getting Started: The UP Inception Phase

Inception artifacts

In the inception UP phase, we may start on the following mostly optional artifacts: Vision and business case: high-level goals and constraints, business case, and executive summary of the project. Use-case model: description of the functional requirements. We identify the names of most use cases and analyze about 10% of the use cases in detail. Supplementary specication: non-functional requirements, especially those that will aect the architecture. Glossary: domain terminology. (continued on next page...)

Matthew Dailey (CSIM-AIT)

Introduction

29 / 31

Getting Started: The UP Inception Phase

Inception 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 vision and determine feasibility. Iteration plan: detailed plan for the rst iteration. Phase plan and software development plan: low-precision guess on elaboration duration and eort, along with tools, people, other resources. Development case: customizations of standard processes for this project. The only UML produced in inception will possibly be use case diagrams, but they are not necessary. Most of the artifacts are pure text.
Matthew Dailey (CSIM-AIT) Introduction 30 / 31

Getting Started: The UP Inception Phase

Common mistakes

You are executing inception incorrectly if: Inception takes more than a few weeks. You dene 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.

Matthew Dailey (CSIM-AIT)

Introduction

31 / 31