Introduction - SENG 330Object-Oriented Analysis and Design

SENG 330 – Fall 2006Instructor: Alex Thomo Email: thomo@cs.uvic.ca Office hours: Office Hours: TWF 12:30 - 1:30 p.m.Location: ECS 556

Objective: • How to create better object-oriented designs through

the application of a set of explainable principles and heuristics.

• How to implement these designs.

SENG 330 – Fall 2006Book:

Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design, 3d Edition,

by Craig Larman

Safari at UVic?

Owning a hammer doesn’t make one an architect…

• Knowing an OO language is a necessary but insufficient first step to create object systems.

• Learn skills forcreation of well-designed, robust, and maintainablesoftware using OO technologies and languages

UML• It’s a standard diagramming

notation…it’s not a method or procedure on how to think in objects.

• However, we need it as tool for communicating with others.– When working visually, we exploit our

brain's strength to quickly grasp symbols, units, and relationships in 2D notations.

Die

faceValue : int

getFaceValue() : introll()

DiceGame

die1 : Diedie2 : Die

play()

1

2

OOD Principles and Patterns• Responsibility-driven design:

– How should responsibilities be assigned to classes of objects?– How should objects interact?– What classes should do what?

• Tried-and-true solutions to design problems have been expressed as patterns (or formulas).– E.g. Suppose there are multiple third-party tax calculators, and each tax

calculator has a different interface: TCP socket, SOAP, Java RMI, CORBA, etc.

– What objects should be responsible for these varying external tax calculator examples?

– Solution. We should create tax calculator adapters, which handle all low level details, while presenting the same external interface, e.g.getTaxes( Sale ).

Analysis and Design?• Analysis emphasizes an investigation of the problem and

requirements, rather than a solution.– Analysis = requirements analysis + object analysis.

• Requirement analysis is strongly related to OOA/D as a prerequisite activity. – Who will use the system? – How will it be used?– What are the expectations?

• Object analysis is about finding domain objects and concepts.

• Design is a conceptual solution that fulfills the requirements. – E.g. a description of software objects, and databases schema. – Software objects are inspired by domain objects, but not necessary the

same.

Plane

tailNumber

public class Plane{

private String tailNumber;

public List getFlightHistory() {…}}

domain conceptvisualization of domain concept

representation in an object-oriented programming language

Object Analysis

Another Example

• Dice game: – A player rolls two die. – If the total is seven, they win; Otherwise, they lose.

• Analysis– Define use cases– Define a domain model

• Design– Define interaction diagrams– Define design class diagrams

Uses Cases

• Requirement analysis describes domain processes: uses cases– Use cases are written stories.

• Example: Play a dice game: A player picks up and rolls the dice. If the dice face value total seven, they win; otherwise they lose.

Domain Model

• Object oriented analysis identifies: – domain objects, – concepts, – attributes and relationships

• Result is the domain model.

Player

name

DiceGame

Die

faceValueRolls

Plays

Includes

2

2

1

1

1

1

OOD: Interaction Diagrams• OOD is about defining software objects,

their responsibilities and collaborations.

• A common notation for outlining the above is an interaction diagram.

:DiceGame

play()

die1 : Die

fv1 := getFaceValue()

die2 : Die

roll()

roll()

fv2 := getFaceValue()

Or…

Static View: Design Class Diagrams

• It’s useful also a static view of the class definitions with design class diagrams (DCD’s).

• DCD’s are inspired by the domain model, but the classes aren’t necessarily the same.

• E.g. here is no Player class. If the requirements don’t ask to remember anything about the person playing, then there is need for such a class.

2

Die

faceValue : int

getFaceValue() : introll()

DiceGame

die1 : Diedie2 : Die

play()

1

Three levels in applying UML• UML as sketch— Informal and incomplete diagrams

(often hand sketched on whiteboards) – created to explore difficult parts of the problem or solution

space, exploiting the power of visual languages.• UML as blueprint— Relatively detailed design

diagrams used either for – code generation (forward engineering) or for – reverse engineering to visualize and better understand

existing code• UML as programming language— Complete

executable specification of a software system in UML. – Executable code will be automatically generated, but is not

normally seen or modified by developers;

Recommended by agile

modeling.

Three perspectives to Apply UML• Conceptual • Specification• Implementation

• UML describes raw diagram types, such as class diagrams and sequence diagrams. It does not superimpose a modeling perspective on these. – For example, the same UML class diagram notation can be

used to draw pictures of concepts in the real world or software classes in Java.

Iterative Development and the Unified Process

(Rational) Unified Process• A software development process describes an

approach to Software– Building– Deploying– Maintaining

• There are many activities comprising the above. • Recommended to follow: The Unified Process,

– A procedure for doing the many possible activities from requirements to implementation, and maintenance.

Key UP Idea: Iterative Development

• An iterative 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.

• Each iteration includes its own requirement analysis, design, implementation, and testing activities.

• Each iteration involves choosing a small set of requirements, and quickly designing, implementing, and testing.

• Feedback is from users, developers, and tests (such as load and usability tests). E.g.

Feedback from users or stakeholders: You don’t differentiate between products when calculating tax!Feedback from programmers: To print in special purpose paper is a daunting task! Is it worthy?Feedback from tests: To ask GoodAsGoldTaxPro calculator is very slow. (load test)

Why Iterations?Some facts:• Changes in requirements: 35% - 50%• Software development is a domain of high change and

instability. • Software is not a domain of predictable or mass

manufacturing. • Change is the constant in software projects.• Any analysis, modeling, development, or management

practice based on the assumption that things are long-term stable (i.e., the waterfall) is fundamentally flawed.

How to do Iterative and Evolutionary Analysis and Design?

1. Before iteration-1, hold the first timeboxed requirements workshop (2 days). Business and development people are present.

– On the morning of day one, identify the names of the use cases. The analysis will not be perfect.

– Ask the chief architect and business people to pick 10% from this high-level list (such as 10% of the 30 use case names), which have a blending of three qualities:

1) architecturally significant2) high business value (features business really cares about)3) high risk (such as "be able to handle 500 concurrent transactions").

Perhaps three use cases are identified: UC2, UC11, UC14.– For the remaining 1.5 days, do intensive detailed analysis for these three

use cases (write them up).

How to do Iterative and Evolutionary Analysis and Design?

2. Before iteration-1, hold an iteration planning meeting a subset from UC2, UC11, and UC14 are chosen to design, build, and test within a specified time (for example, four-week timeboxed iteration).

3. Do iteration-1 over four weeks.– On the first two days, developers and others do modeling and design work in

pairs, sketching UML diagrams at many whiteboards in a common war room…– Then the developers take off their "modeling hats" and put on their "programming

hats."– Much testing occurs. – One week before the end, ask the team if the original iteration goals can be met; if

not, de-scope the iteration, putting secondary goals back on the "to do" list.– On Tuesday of the last week there's a code freeze; all code must be checked in,

integrated, and tested to create the iteration baseline.– On Wednesday morning, demo the partial system to external stakeholders, to

show early visible progress. Feedback is requested.

UP Phases• A UP project organizes the iterations across four major phases:• Inception

– approximate vision, – business case, – scope, – vague estimates.

• Elaboration– refined vision– iterative implementation– resolution of high risks

• Construction– iterative implementation of lower risk elements

• Transition– beta tests– deployment

UP Disciplines

• UP describes work activities, such as writing a use case, within disciplines (work-codes).

• There are several disciplines:– Business modeling – e.g. domain modeling– Requirements – e.g. writing use cases– Design – all aspects of design, e.g. objects, databases,

networking etc. – …

Disciplines and phases

Case Study: The NextGen POS System

A POS System• A computerized NextGen point-of-sale (POS) system is to:

– record sales, and – handle payments.

• It includes H/S components such as:– Computer– Bar code scanner– Software

• It interfaces to various service applications, such as:– Third party tax calculators– Inventory control

• It must support multiple and varied client-side terminals and interfaces, such as:– A thin Web browser terminal– A regular PC with Java Swing graphical UI– Touch screen input– Wireless PDA’s

• Furthermore, it should support different clients with different business rules.

Business rules…

– “When you sell a widget, total the monthly sale figures, and decrease the widget inventory.”

– “Only a manager can discount blue widgets by 10%.”

Interface

Sale Payment

Log Pers is tenceFacade

applicationlog ic anddomain objec tlayer

technicals ervices layer

minor focus

explore how to connect toother layers

primary focus ofcase s tudy

explore how todes ign objects

secondaryfocus

explore howto des ignobjects

Architectural Layers