The Object-Oriented

Design Process

Introduction to UML

Unified Modeling Language

UML is a graphical language for visualizing, specifying,

constructing, and documenting the artifacts of a
softwareintensive system.

UML is established by the Object Management Group

(OMG) as the standard notation for distributed object
systems.

UML is just a notation. It is not, nor does it specify:

Processes

Tools

Programming languages

Using UML aids in communication among analysts,

designers, and programmers.
3

A brief history of UML

In the early to mid-1990s, three modeling languages were popular

Each was developed by a leader in the world of OO:

James Rumbaugh object-modeling technique (OMT)

Grady Booch Booch method

Ivar Jacobson Object-oriented software engineering

All three joined Rational in 1994 and 1995

Became known as The Three Amigos

Combined their methodologies to creating the non-proprietary Unified

Modeling Language (UML) in 1996

UML is officially defined by the Object Management Group (OMG)

UML 1 Submitted in 1996

UML 2 Submitted to OMG in 2003

Some important UML artifacts

Use case diagrams and descriptions capture the

requirements of the system.

Class diagrams capture the classes, attributes,

methods for classes and the relationships between
classes.
Object diagrams

are a variant of class diagrams that show

specific objects to give an example or snapshot of running
system.

Activity diagrams show flow of activities in a

process.
5

Some important UML artifacts

State machines show change of state and events

that cause change of state for specific objects.

Interaction diagrams show interactions between

objects.
There

are several types of interaction diagrams.

Sequence diagrams

show sequence of messages among

objects in an execution scenario.

UML also defines:

Component diagrams show physical structure of software components.

Deployment diagrams show the architecture of a system in terms of

physical nodes (hardware) and distribution of software components.
6

Use case diagram

How users interact with a system

Class diagram

Class diagrams show the classes involved in a

system and relationships between them.

Class and object diagrams

A class diagram is used to show classes, their attributes,

their methods and their relationship to other classes.

An object diagram is used to show specific instances

individual objects and the values of their attributes at one
point in time.

Activity diagram

Procedural and parallel behavior

10

State machine

How events change state of an object over its life

11

Sequence diagram

Interaction between objects; emphasis on sequence

12

Communications diagram

Interaction between objects; emphasis on links

13

Summary of UML symbols

14

Drawing UML diagrams

Products from Rational that create UML

Rational Software

Modeler

Rational Software

Architect

Rational RequisitePro

Rational Method

Composer

Rational Unified

Process

Open source tools are also available, including

plug-ins for Eclipse
http://www.eclipse.org

15

Using UML in the software development process

The main purpose of UML is to facilitate

communication among all people involved in the
development process

UML is a visual language that is made up of

diagrams
Often

textual documents accompany the UML, especially

in larger scale projects that require a more formal process

UML should be modified as design decisions are

refined
16

Using UML in the software development process

UML is used on all stages of software development

Requirements gathering

Use cases describe system functionality

Analysis

Class and interaction diagrams model the business domain

Design

of the business problem

of the code

Class and interaction diagrams help design the code

Implementation

State, activity, and sequence show how scenarios unfold

Testing

Should verify all scenarios describes by use cases

17

Topics

18

UML
From Problem to Code
The Object and Class Concepts
Identifying Classes
Identifying Responsibilities
Relationships Between Classes
Use Cases
CRC Cards
UML Class Diagrams
Sequence Diagrams
State Diagrams
Using javadoc for Design Documentation
Case Study: A Voice Mail System

From Problem to Code

Three Phases:
Analysis

Design
Implementation

19

Analysis Phase

Establish the functions, services, and constraints

of the software to be developed.
The developers

and the software users work together to

produce a requirements specification, which will be the
input to the design phase.

Functional Specification which is a part of

requirements specification, has the following
characteristics:
Completely defines

tasks to be solved
Free from internal contradictions
Readable both by domain experts and software developers
Reviewable by diverse interested parties
Testable against reality
20

Design Phase

Goals
Identify classes

Identify behavior

of classes

Identify relationships among

Artifacts
Textual description of

classes and key methods

Diagrams

of class relationships

Diagrams

of important usage scenarios

State diagrams

21

classes

for objects with rich state

Implementation Phase

Implementation is the realization of the software

design in a specific programming language. Each
unit (a single class) is implemented separately.

Unit testing is done to ensure that each unit

functions properly with respect to its specification
before the units are integrated.

The individual units are integrated and tested as a

whole to ensure that the entire software system
works properly conforming to its specification.

22

Case Study: Voice Mail System

Use text for voice, phone keys, hangup

1 2 ... 0 # on a single line means key

H on a single line means "hang up"

All other inputs mean voice

In GUI program, will use buttons for keys

23

Identifying Classes

Rule of thumb: Look for nouns in problem

description
Mailbox
Message
User
Passcode
Extension
Menu

Focus on concepts, not implementation

MessageQueue stores

24

Don't

messages

worry yet how the queue is implemented

Categories of Classes

Tangible Things

Agents

Events and Transactions

Users and Roles

Systems

System interfaces and devices

Foundational Classes

25

Identifying Responsibilities

Rule of thumb: Look for verbs in problem

description

An example: Behavior of MessageQueue:

Add

message to tail

Remove

Test

message from head

whether queue is empty

OO Principle: Every operation is the

responsibility of a single class
Example:

Add message to mailbox

Who is responsible: Message or Mailbox?
26

Class Relationships
The following relationships can exist among classes:

Dependency ("uses")

Association, including aggregation and

composition

Generalization, including inheritance and

implementation

Among them, inheritance ("is-a"), aggregation

("has"), and dependency ("use") are the most
basic relationships

27

Dependency Relationship

Class A depends on class B: method of A manipulates objects of B in

the parameters, local variables, or return types

Minimize dependency: reduce coupling

Example: Removes dependence on System and Message

Replace
public class Message{
void print() { System.out.println(text); }

with
public class Message{
String getText() { // can print anywhere }

28

An example and UML notation for dependency

Association

Association represents general binary relationships

between classes

Association can have roles

Implemented through instance fields

An example and UML notation for association

relationship

29

Aggregation

A special form of association

30

Represents the has-a or part-whole relationship.

Simply a structural relationship that distinguishes the whole, that is, the
aggregate class, from the parts, that is, the component class.
Implemented through instance fields
e.g. MessageQueue aggregates Messages
e.g. Mailbox aggregates MessageQueue

An example and UML notation for aggregation

Composition

31

A stronger form of aggregation

The aggregate class exclusively owns the component class.

The lifetime of the components is entirely included in the lifetime of

the aggregate.

Contained objects don't exist outside container

An example and UML notation for composition: message

queues permanently contained in mail box

Association Direction

Some associations are bidirectional

Can

navigate from either class to the other

e.g.

Course has set of students, student has set of courses

Some associations are directed

Navigation is
e.g.

it

32

unidirectional

Message doesn't know about message queue containing

Multiplicities

any number (0 or more): *

one or more: 1..*

zero or one: 0..1

exactly one: 1

Implementation:

1, 0..1 relationship:
public class Mailbox{
...
private MessageQueue queue;
}

1:n relationship:
public class MessageQueue{
...
private ArrayList<Message> elements;
}

33

Generalization - Inheritance relationship

Inheritance relationship is formed when a class (or an

interface) extends another class (or interface).

UML notation for generalization

34

Generalization - implementation relation

The implementation relation between a class and an

interface

Interface type describes a set of methods. No

implementation, no state

Class implements interface if it implements its methods

UML notation for implementation relation

35

Use Cases

Analysis technique

Each use case focuses on a specific scenario

Use case = sequence of actions

Action = interaction between actor and computer

system

Each action yields a result

Each result has a value to one of the actors

Use variations for exceptional situations

36

Sample Use Case

Leave a Message
1.

Caller dials main number of voice mail system

2.

System speaks prompt

Enter mailbox number followed by #

3.

User types extension number

4.

System speaks
You have reached mailbox xxxx. Please leave a
message now

5.

Caller speaks message

6.

Caller hangs up

7.

System places message in mailbox

37

Sample Use Case -- Variations

Variation #1
1.1. In step 3, user enters invalid extension number

1.2. Voice mail system speaks

You have typed an invalid mailbox number.

1.3. Continue with step 2.

Variation #2
2.1. After step 4, caller hangs up instead of speaking message

2.3. Voice mail system discards empty message

38

CRC Cards

CRC = Classes, Responsibilities, Collaborators

a

very effective design tool in identifying classes, their

responsibilities, and relationships to other classes

Developed by Beck and Cunningham

Use an index card for each class

Class name on top of card

Responsibilities on left

Collaborators on right

39

CRC Cards

40

CRC Cards

Responsibilities should be high level without

concerning implementation details

Between 1 - 3 responsibilities per card is ideal

Collaborators are for the class, not for each

responsibility

41

How do you create CRC models

A CRC model is created iteratively performing the
following steps:

Find classes

One card per class

Walk through scenario of use cases, to find

responsibilities, define collaborators to fill in cards

42

Walkthroughs

Use case: "Leave a message"

Caller connects

Caller dials

to voice mail system

extension number

"Someone" must locate mailbox

Neither Mailbox nor Message can do this

New class: MailSystem

Responsibility: manage mailboxes

43

Walkthroughs

44

Other UML Diagrams

Many UML diagram types

We'll use three types:

Class

Diagrams

Sequence

Diagrams

State Diagrams

45

Sequence Diagrams

Each diagram shows dynamics of scenario

Object diagram: class name underlined

46

Sequence Diagrams
Self call

47

Object Construction

State Diagram

48

Use for classes whose objects have interesting states

Design Documentation

Recommendation: Use Javadoc comments

Leave methods blank

/**
Adds a message to the end of the new
messages.
@param aMessage a message
*/
public void addMessage(Message aMessage)
{
}

Don't compile file, just run Javadoc

Makes a good starting point for code later

49

Case Study: Voice Mail System

Use text for voice, phone keys, hangup

1 2 ... 0 # on a single line means key

H on a single line means "hang up"

All other inputs mean voice

In GUI program, will use buttons for keys

50

Use Case: Reach an Extension

1.

User dials main number of system

2.

System speaks prompt

Enter mailbox number followed by #

3.

User types extension number

4.

System speaks
You have reached mailbox xxxx. Please
leave a message now

51

Use Case: Leave a Message

1.

Caller carries out Reach an Extension

2.

Caller speaks message

3.

Caller hangs up

4.

System places message in mailbox

52

Use Case: Log in

1.

Mailbox owner carries out Reach an Extension

2.

Mailbox owner types password and #

Default password = mailbox number. To change,
see Change the Passcode

3.

System plays mailbox menu:

Enter 1 to retrieve your messages.
Enter 2 to change your passcode.
Enter 3 to change your greeting.

53

Use Case: Retrieve Messages

1.

Mailbox owner carries out Log in

2.

Mailbox owner selects "retrieve messages" menu option

3.

System plays message menu:

Press
Press
Press
Press

1
2
3
4

to
to
to
to

listen to the current message

delete the current message
save the current message
return to the mailbox menu

4.

Mailbox owner selects "listen to current message"

5.

System plays current new message, or, if no more new messages,

current old message.
Note: Message is played, not removed from queue

6.

System plays message menu

7.

User selects "delete current message". Message is removed.

8.

Continue with step 3.

54

Use Case: Retrieve Messages

Variation #1
1.1. Start at Step 6
1.2. User selects "save current message".

Message is removed from new queue and appended to

old queue

1.3. Continue with step 3.

55

Use Case: Change the Greeting

1.

Mailbox owner carries out Log in

2.

Mailbox owner selects "change greeting" menu option

3.

Mailbox owner speaks new greeting

4.

Mailbox owner presses #

5.

System sets new greeting

Variation #1: Hang up before confirmation

1.1. Start at step 3.
1.2. Mailbox owner hangs up.

1.3. System keeps old greeting.

56

Use Case: Change the Passcode

1.

Mailbox owner carries out Log in

2.

Mailbox owner selects "change passcode" menu option

3.

Mailbox owner dials new passcode

4.

Mailbox owner presses #

5.

System sets new passcode

Variation #1: Hang up before confirmation

1.1. Start at step 3.
1.2. Mailbox owner hangs up.

1.3. System keeps old passcode.

57

CRC Cards for Voice Mail System

Some obvious classes

Mailbox

Message

MailSystem

58

Initial CRC Cards

59

Telephone

Who interacts with user?

Telephone takes button presses, voice input

Telephone speaks output to user

60

Connection

With whom does Telephone communicate

With MailSystem?

What if there are multiple telephones?

Each connection can be in different state (dialing,

recording, retrieving messages,...)

Should mail system keep track of all connection states?

Better to give this responsibility to a new class

61

Analyze Use Case: Leave a message

1.

User dials extension. Telephone sends number to Connection

Add collaborator Connection to Telephone

2.

Connection asks MailSystem to find matching Mailbox

3.

Connection asks Mailbox for greeting

Add responsibility "manage greeting" to Mailbox, add collaborator

Mailbox to Connection

4.

Connection asks Telephone to play greeting

5.

User speaks message. Telephone asks Connection to record it.

Add responsibility "record voice input" to Connection)

6.

User hangs up. Telephone notifies Connection.

7.

Connection constructs Message

8.
62

Add card for Message class, add collaborator Message to Connection

Connection adds Message to Mailbox

Result of Use Case Analysis

63

Result of Use Case Analysis

64

Analyse Use Case: Retrieve messages

1.

User types in passcode. Telephone notifies Connection

2.

Connection asks Mailbox to check passcode.

Add responsibility "manage passcode" to Mailbox

3.

Connection sets current mailbox and asks Telephone to speak menu

4.

User selects "retrieve messages". Telephone passes key to Connection

5.

Connection asks Telephone to speak menu

6.

User selects "listen to current message". Telephone passes key to Connection

7.

Connection gets first message from current mailbox.

Add "retrieve messages" to responsibility of Mailbox.

Connection asks Telephone to speak message

8.

Connection asks Telephone to speak menu

9.

User selects "save current message". Telephone passes key to Connection

10.

Connection tells Mailbox to save message

11.

65

Modify responsibility of Mailbox to "retrieve, save, delete messages"

Connection asks Telephone to speak menu

Result of Use Case Analysis

66

CRC Summary

One card per class

Responsibilities at high level

Use scenario walkthroughs to fill in cards

Usually, the first design isn't perfect.

(You just saw the author's third design of the mail
system)

67

UML Class Diagram for Mail System

CRC collaborators yield dependencies

Mailbox depends on MessageQueue

Message doesn't depends on Mailbox

Connection depends on Telephone,

MailSystem, Message, Mailbox

Telephone depends on Connection

68

Dependency Relationships

69

Aggregation Relationships

A mail system has mailboxes

A mailbox has two message queues

A message queue has some number of messages

A connection has a current mailbox.

A connection has references to a mailsystem and a

telephone

70

UML Class Diagram for Voice Mail System

71

Sequence Diagram for Use Case: Leave a message

72

Interpreting a Sequence Diagram

Each key press results in separate call to dial, but only one
is shown

Connection wants to get greeting to play

Each mailbox knows its greeting

Connection must find mailbox object:

Call findMailbox on MailSystem object

Parameters are not displayed (e.g. mailbox number)

Return values are not displayed (e.g. found mailbox)

Note that connection holds on to that mailbox over

multiple call

73

Sequence Diagram for Use Case: Retrieve messages

74

Connection State Diagram

75

Final Class Diagram for Voice Mail System

76