2-The Object-Oriented Design Process

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

4

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

7

Class diagram

Class diagrams show the classes involved in a

system and relationships between them.

8

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.

9

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 of the business problem

Class and interaction diagrams model the business domain

Design 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

18

Topics

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

19

From Problem to Code

Three Phases:

Analysis

Design

Implementation

20

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

21

Design Phase

Goals

Identify classes

Identify behavior of classes

Identify relationships among classes

Artifacts

Textual description of classes and key methods

Diagrams of class relationships

Diagrams of important usage scenarios

State diagrams for objects with rich state

22

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.

23

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

24

Identifying Classes

Rule of thumb: Look for nouns in problem

description

Mailbox

Message

User

Passcode

Extension

Menu

Focus on concepts, not implementation

MessageQueue stores messages

Don't worry yet how the queue is implemented

25

Categories of Classes

Tangible Things

Agents

Events and Transactions

Users and Roles

Systems

System interfaces and devices

Foundational Classes

26

Identifying Responsibilities

Rule of thumb: Look for verbs in problem

description

An example: Behavior of MessageQueue:

Add message to tail

Remove message from head

Test 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?

27

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

28

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 }

An example and UML notation for dependency

29

Association

Association represents general binary relationships

between classes

Association can have roles

Implemented through instance fields

An example and UML notation for association

relationship

30

Aggregation A special form of association

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

31

Composition

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

32

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 unidirectional

e.g. Message doesn't know about message queue containing

it

33

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 elements;

}

34

Generalization - Inheritance relationship

Inheritance relationship is formed when a class (or an

interface) extends another class (or interface).

UML notation for generalization

35

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

36

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

37

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

38

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

39

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

40

CRC Cards

41

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

42

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

43

Walkthroughs

Use case: "Leave a message"

Caller connects to voice mail system

Caller dials extension number

"Someone" must locate mailbox

Neither Mailbox nor Message can do this

New class: MailSystem

Responsibility: manage mailboxes

44

Walkthroughs

45

Other UML Diagrams

Many UML diagram types

We'll use three types:

Class Diagrams

Sequence Diagrams

State Diagrams

46

Sequence Diagrams

Each diagram shows dynamics of scenario

Object diagram: class name underlined

47

Sequence Diagrams

Self call Object Construction

48

State Diagram

Use for classes whose objects have interesting states

49

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

50

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

51

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

52

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

53

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.

54

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 1 to listen to the current message Press 2 to delete the current message Press 3 to save the current message Press 4 to 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.

55

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.

56

Use Case: Change the Greeting


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.

57

Use Case: Change the Passcode


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.

58

CRC Cards for Voice Mail System

Some obvious classes

Mailbox

Message

MailSystem

59

Initial CRC Cards

60

Telephone

Who interacts with user?

Telephone takes button presses, voice input

Telephone speaks output to user

61

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

62

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

Add card for Message class, add collaborator Message to Connection

8. Connection adds Message to Mailbox

63

Result of Use Case Analysis

64


65

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


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

10. Connection tells Mailbox to save message

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


66


67

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)

68

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

69

Dependency Relationships

70

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

71

UML Class Diagram for Voice Mail System

72

Sequence Diagram for Use Case: Leave a message

73

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

74

Sequence Diagram for Use Case: Retrieve messages

75

Connection State Diagram

76

Final Class Diagram for Voice Mail System

2-The Object-Oriented Design Process

Documents

object diagrams

uml aids

sequence diagrams

drawing uml diagrams

development process

class diagram class

case diagrams

activity diagrams