Object-Oriented Analysis and Design

NGSSC Object-Oriented Scientific Programming,

June 2012

Object-Oriented Software Construction

Program = Data + Algorithm Constructing a software program can be

seen as building a model. Structured programming (the 70s)

focused on modelling algorithms, whereas OOP has its focus on modeling data.

Data is often more stable than algorithms, which makes OO models easier to change.

Data is more tangible, which makes OO models easier to understand.

History of the Object-Oriented Approach

Languages:

1969 Simula

1972 Smalltalk

1985 C++

1990 Python

1995 Java

Methods and notation:

1991 Booch

1991 OMT Rumbaugh et al

1992 OOSE Jacobsen

Unified Modeling Language:

1995 UML 0.9

2002 UML 1.4

Example: Matrix addition

Traditional version:

a and b are a two-dimensional arrays

for i = 0, lines for j = 0, cols a(i, j) = a(i, j) + b(i, j) end forend for

Example: Leap-Frog

ADT version

a and b are variables of type Matrix

a = a.add(b)

Traditional vs. Object-Oriented Software

Data structures visible Data structures hidden

Focus on a problem Focus on a problem domain

Traditional Object-oriented

Key concepts

Object Class Encapsulation Operation Inheritance Polymorphism Method

Some advantages

Faster code development (due to reusable components)

Easier to maintain and modify (due to encapsulation and inheritance)

Easier to scale programs (due to modelling and inheritance)

Easier communication with non-computer scientists

Object-Oriented Modeling

Two phases: Analysis Design

Two views: Structural/static Behavioural/dynamic

Structural/Static Modeling

Structural model: a view of a system that emphasizes the

structure of the objects, including their classifiers, relationships, attributes and operations.

No temporal information!!

We will use class diagrams to express the structural model

Building a class diagram

Identify classes Begin a data dictionary Add associations between classes Add attributes Look for inheritance relations Test the model via scenarios, and

iterate the above steps as necessary

Finding classes

Phase 1: brain stormingList concepts in the problem domainInclude anything that comes to your

mind

Phase 2: selectionRemove candidates that are:

redundant, irrelevant, vague, attributes, operations, associations, roles, implementation constructs, et cetera

Class

Fig. 3-20, UML Notation Guide

Window

display ()

size: Areavisibility: Boolean

hide ()

Window

Window

+default-size: Rectangle#maximum-size: Rectangle

+create ()

+display ()

+size: Area = (100,100)#visibility: Boolean = true

+hide ()

-xptr: XWindow*

-attachXWindow(xwin:Xwindow*)

{abstract,author=Joe,status=tested}

Class and objects

Point

x: Realy: Real

rotate (angle:Real)scale (factor:Real)

p1:Point

x = 3.5y = 2.7

:Point

x = 1y = -1

Associations

Fig. 3-40, UML Notation Guide

Person

Manages

JobCompany

boss

worker

employeeemployer

0..1

Job

Account

Person

Corporation

{Xor}

salary

Special Associations: Aggregations and Composites

Fig. 3-41, UML Notation Guide

Polygon PointContains

{ordered}

3..1

GraphicsBundle

colortexturedensity

1

1

-bundle

+vertex

Inheritance

Fig. 3-47, UML Notation Guide

Shape

SplineEllipsePolygon

Shape

SplineEllipsePolygon

Shared Target Style

Separate Target Style

. . .

. . .

Constraints and Comments

Fig. 3-17, UML Notation Guide

Member-of

Chair-of

{subset}Person Committee

Person Company

boss

{Person.employer =Person.boss.employer}

employeremployee

0..1

0..1

1

Representsan incorporated entity.

Structural Modeling Tips

Define a “skeleton” (or “backbone”) that can be extended and refined as you learn more about your domain.

Focus on using basic constructs well; add advanced constructs and/or notation only as required.

Defer implementation concerns until late in the modeling process.

When to model use cases

Model user requirements with use cases. Model test scenarios with use cases. If you are using a use-case driven

method:start with use cases and derive your

structural and behavioral models from it.

If you are not using a use-case driven method:make sure that your use cases are

consistent with your structural and behavioral models.

Behavioral/Dynamic Modeling with UML

x y z

Sequence Diagram

a

b

c

Collaboration Diagram

x y

z

1.1: a1.2: c

1.1.1: b

Use Case: Change Flight Itinerary

Actors: traveler, client account data base, airline reservation system

Preconditions: Traveler has logged inBasic course:

– Traveler selects ‘change flight itinerary’ option– System retrieves traveler’s account and flight itinerary from client

account database– System asks traveler to select itinerary segment she wants to change;

traveler selects itinerary segment.– System asks traveler for new departure and destination information;

traveler provides information.– If flights are available then …– …– System displays transaction summary.

Alternative course:– If no flights are available then…

Sequence Diagram: Change Flight Itinerary

: Booking SystemTraveler Airline Reservation System

change flight itinerary

get customer account

get itinerarypresent itinerary

select segment

present detailed info

update informationavailable flight

::

Client Account DBMSClient Account DBMS

Collaboration Diagram: Change Flight Itinerary

Traveler Client Account DBMS

Airline Reservation System

: Booking System

7: update information

2: get customer account3: get itinerary

4: present itinerary

8: available flight

1: change flight itinerary5: select segment

6: present detailed info

Design patterns

A systematic way of describing a solution to a modeling problem

Four key elements:1. Pattern name2. Problem description3. Solution4. Consequences