Chapter 1

Object Oriented Analysis and Design

UML, Patterns, and Object-Oriented Analysis and Design

The essential skills for the creation of well-designed, robust and maintainable software systems using object technology: More than just knowing an OOPL or an OO CASE

tool; Must know how to “think in objects”

UML : Unified Modeling Language. A very large set of notations (mostly diagrammatic): Useful for expressing and discussing OOA & D

decisions

What is OOD?

OOD is mostly about assigning responsibilities to classes: How should objects interact? What classes should do what? We will use responsibility-driven design to assist

with this task To help us improve our designs, we use Design

Patterns: They are named problem-solution formulas that

codify exemplary design principles

Book Approach

Case Studies show how to apply UML and patterns during OOAD within an agile approach to the Unified Process

Requirements analysis will be started using use cases: Trying to discover “what” we must develop

There are many potential SWE activities from requirements through to implementation: We will use an agile (light, flexible) version of the

Unified Process (UP) : an iterative development process.

See Fig 1.1 for range of topics and skills covered.

Topics and Skills

UML notation

Requirements analysis

Principles and guidelines

OO Patterns

Iterative development with

an agile Unified Process

OOA & D

Fig 1.1

Topics and Skills Covered

Assigning Responsibilities Object-oriented analysis and design

involves assigning responsibilities to software objects. The link between describing what we want and

how it will be realized. Given a responsibility (e.g. which class will

handle player’s personal information?) many choices will be available, but not all lead to a good overall design; good responsibility assignment leads to better design.

Larman identifies 9 fundamental OOD patterns (GRASP : General Responsibility Assignment Software Patterns or Principles)

We will also discuss the GOF (Gang of Four) patterns

What is Analysis and Design?

Analysis (or requirements analysis) involves studying the problem to be solved. It identifies what the problem is without addressing how it will be solved.

Design is the creative process that transforms a problem into a solution. It identifies how the problem will be solved. It is a conceptual solution rather than an implementation.

What is OOA&D? In essence, to consider a problem domain

and logical solution from the perspective of objects (things, concepts, or entities)

OOA: emphasis on finding and describing the objects in the problem domain

OOD: emphasis on defining logical software objects and how they should collaborate (via method calls) to fulfill the requirements

OOP: commitment to code.

Consider a flight information system:

OOA : Finding and defining the objects or concepts: Plane, Flight, Pilot etc;

OOD : Assigning responsibilities to those objects and determining how they collaborate: a Plane object must have a tailNumber

attribute and a getFlightHistory method; OOP : Implementing the design in code:

e.g. a Plane class in Java.

Plane

tailNumber

public class Plane

{

private String tailNumber ;

public List getFlightHistory () { ... }

}

1domain concept

2visualization of

domain concept

3representation in an

object -oriented

programming language

Fig 1.2 Object-orientation revolves around objects.

Ex. (Cont.)

A Short Example: A Dice Game In this dice game: a player rolls two

dice, if the total is seven he/she wins; otherwise he/she loses.

For this example, we will utilize Four Steps:

1. Defining Use Cases: 2. Defining a Domain Model 3. Defining Interaction Diagrams 4. Defining Design Class Diagrams

1.Defining Use Cases: Understanding the requirements includes

first understanding the domain processes and the external environment (external actors who participate in processes). Use Case: Play a Game

Actors: PlayerDescription: Player requests to roll the dice. System presents results. If the dice face value totals seven, player wins; otherwise player loses.

2. Defining a Domain Model

A decomposition of the problem domain involves identifying the important concepts, attributes and associations in the domain.

The conceptual model is not a description of software components; it represents concepts in the real-world problem domain.

The Conceptual Model

Player

name

DiceGame

Die

faceValue

Rolls

Plays

Includes

2

2

1

1

1

1

Fig 1.3 Partial domain model of the dice game.

Player

name

DiceGame

Die

faceValue

Rolls

Plays

Includes

2

2

1

1

1

1

3. Defining Interaction Diagrams The next step in in OOD is allocating responsibilities

to objects and illustrating how they interact via messages, expressed in sequence diagrams.

Sequence diagrams show the flow of messages between instances and the invocation of methods.

In our EX, a simulation in software of the dice game Fig 1.4 illustrates the essential step of playing by

sending messages to instances of the Die class. Note that in the real world a player rolls the dice, in

the software design the DiceGame object rolls the dice (ie, sends messages to the Die objects)

Fig 1.4 Sketched sequence diagram

4. Defining Design Class Diagrams What are the methods of a class? How do objects connect to other objects? Inspect the sequence diagrams (dynamic view) for the

necessary connections between objects and the methods that each software class must define

Add this information to a design class diagram (a static view).

Since a play message is sent to the DiceGame instance, the DiceGame class requires a play method, while the Die class requires a roll and getFaceValue method. See Fig 1.5.

Design class diagrams describe software components.

The Resulting Design Class Diagram

2

Die

faceValue : int

getFaceValue() : introll()

DiceGame

die1 : Diedie2 : Die

play()

1

Fig 1.5 Partial design class diagram

Summary of the Dice Game Example

A very simple example : gives an overview of the steps and artifacts in OOA&D

OO vs Function-Oriented A&D Prior to OOA&D structured analysis and design

was popular : decomposition of a problem by function or process resulting in a hierarchical breakdown of processes rather than by objects

OOA&D : emphasis on decomposing a problem space by objects rather than functions

The boundary between OOA and OOD is fuzzy (even more so than in traditional SWE): There is a difference between investigation (analysis)

and solution (design) During analysis we emphasize understanding the

problem while deferring issues related to the solution, performance, and so on to the design.

The Unified Modeling Language

A language for specifying, visualising and constructing the artifacts of software systems

A de facto and de jure standard; We focus on diagrams that are used frequently: Refer to the UML 2.0 standard (2003) for the

details of the language. Case tool support is excellent. The authors of the UML also defined a preferred

development process (the Unified Process) to work with the UML.

Class and Terminology

The term ‘class’ is used a lot, but it can have a precise meaning depending on the context: Within OOA, developing a Domain Model via a

domain diagram, classes are called domain concepts or conceptual classes;

Within OOD, developing a Design Model via a design diagram, classes are called design classes or software classes;

Within OOP, developing an implementation model via code in an OOPL, classes are called implementation classes.

Conclusion

We will learn how to apply OOA&D to a project using the UML and within an agile software development process.

Resources: www.omg.org (the Object Management

Group) www.uml.org (the Unified Modeling

Language)

Questions?