© 2005 Prentice Hall8-1 Stumpf and Teague Object-Oriented Systems Analysis and Design with UML

© 2005 Prentice Hall 8-1

Stumpf and TeagueObject-Oriented Systems Analysis and Design with

UML

Chapter 8Program Design –

I nteraction D iagram s


Learning Objectives

• Explain fundamental object-oriented concepts.

• Understand what patterns are and how they are used.

• Learn how to assign responsibilities to classes using the Façade, Creator, and Expert patterns.


Learning Objectives (continued)

• Understand the differences between collaboration and sequence diagrams.

• Create interaction diagrams.


Overview

The models used in object-oriented program design represent interacting units of software, known as objects.

These objects communicate with each other by messages to carry out the required responses of the system.


Overview (continued)

The chief task of object-oriented program design is to assign responsibilities to the objects.

This assignment of responsibilities is guided by patterns – design solutions based on the experience of software design professionals.



Object-oriented program design is a seven-step process.

Chapter 8 presents the first step –producing an interaction diagram for each system operation identified

during analysis.



The interaction diagrams are developed on the basis of system operation contracts produced during analysis.

This overall approach is called“design by contract.”



As discussed in Chapter 5, design by contract assumes a commitment to a contract on the part of the object which receives a message.

The preconditions and postconditions of the system operation contracts drive the program design.



In developing the interaction diagram for each system operation, we must assure that the operation:

• first checks whether every precondition of the contract is true, and then

• makes every postcondition of the contract come true.


Fundamental Concepts – Objects, Classes, and

Messages

Objects are the basic structural components of object-oriented software. They are organized into classes and communicate with each other by messages.

Each object has three components:• A unique identity• A set of attributes (internal data) • A set of behaviors (operations)


Fundamental Concepts – Objects

Encapsulation protects the internal attributes and operations of an object from external access.

Only public attributes and operations can be accessed from outside (via an interface).

Objects in the application domain (business objects) are persistent.


Fundamental Concepts – Classes

Every object is a member of a class – a group of objects with identical sets of attributes and behaviors. The value of an attribute can vary for objects in the same class.

Classes may be organized as generalization-specialization hierarchies, with subclasses and superclasses.


Fundamental Concepts – Classes (continued)

Each subclass inherits from its superclass.

Every object in a subclass has:

• all the attributes of its superclass,• all the operations of its superclass, and• all the associations of its superclass,

and may have additional attributes, operations, and associations.


Fundamental Concepts – Messages

A message is a request from an object asking a second object to carry out a behavior (an operation) belonging to the second object.

A message specifies:

• the identity of the object to which it is sent,

• the name of the operation, and possibly,

• the parameters of the message.


Fundamental Concepts – Messages (continued)

Visibility: For an object (the client) to send a message to another object (the server), the receiving object must be visible to the sending object. (That is, it must know the server’s identity).

FI GURE 8.4


Fundamental Concepts – Messages (continued)

Polymorphism: Objects in different classes may respond differently to messages with the same name.


Responsibilities

The principal task of object-oriented program design is to assign responsibilities to classes.

A responsibility is an obligation of an object to other objects.


Responsibilities (continued)

An object may be responsible for knowing:

• What it knows – its attributes• Who it knows – the objects associated

with it• What it knows how to do – the operations

it can perform


Responsibilities (continued)

An object may also be responsible for:

• Doing something itself• Requesting services from other

objects• Controlling and coordinating the

activities of other objects


Models and Techniques of Object-Oriented Program

Design• Class diagram

• Interaction diagrams• Collaboration diagram• Sequence diagram

• Contract

• Patterns

• Primary design criteria• Coupling• Cohesion• Law of Demeter


Patterns for Object-Oriented Program

DesignA pattern is a named statement of a

design problem together with its solution and guidance for applying the pattern. Patterns include:

• Façade

• Creator

• Expert

• Singleton


The Façade Pattern

Problem: Who should be responsible for handling a system operation message from an actor?

Solution: Assign this responsibility to an object representing the system as a whole.


The Creator Pattern

Problem: Who should be responsible for requesting the creation of a new object, i. e.,who sends the create message to the appropriate class?

Solution: Assign this responsibility to a class which is in some way closely involved with the class. (See Figure 8.4 in text for details.)


The Expert Pattern

Problem: What is the most basic principle for assigning responsibilities to objects?

Solution: Assign the responsibility to the class which has the information necessary to fulfill it.


Interaction Diagrams

An interaction diagram depicts the messages between objects or classes in a program. It shows collaborations between objects.

The UML includes two types of interaction diagrams – collaboration diagrams and sequence diagrams.


Collaboration Diagrams

A collaboration diagram is a network model of the messages between interacting objects and classes.

There is a UML convention for numbering the messages to show the sequence in which they occur.


Collaboration Diagrams (continued)

.

FI GURE 8.5


Sequence Diagrams

A sequence diagram shows interactions in a fence format.

The messages appear from top to bottom in the sequence in which they occur.


Sequence Diagrams (continued)

.

FI GURE 8.6


Design Class Diagrams

A design class diagram follows the same conventions as a domain model.

However, it also shows the operations of the classes.


Design Class Diagrams (continued)

.

FI GURE 8.7


Procedure for Object-Oriented

Program Design

Step 1. Produce an interaction diagram for each system operation identified during analysis.

Step 2. Produce a design class diagram showing the operations from the interaction diagrams.

Step 3. Specify the signature and the algorithm for each operation.


Procedure for Object-Oriented

Program Design (continued)

Step 4. Design the graphical user interface.

Step 5. Define the interface to the presentation layer.

Step 6. Define the interface to the storage layer.

Step 7. Place the classes in packages.


Collaboration Diagrams

A collaboration diagram is a network model of messages between interacting objects or classes. Its components are:

• Objects or classes – shown as labeled rectangles

• Links (instances of associations) – shown as lines

• Messages – shown next to the links

Arrows show the direction of messages.


Collaboration Diagrams (continued)

The links are message paths.

The sequence of messages is shown by a hierarchical numbering convention.

The standard UML syntax for a message is:

messageName (in parameter : parameterType, out parameter : parameterType)


Creating Collaboration Diagrams

Step 1.1. Apply the Façade pattern. Choose a façade object for the system.

Step 1.2. Apply the Creator pattern. Add new objects and their creators to the collaboration diagram.

Step 1.3. Apply the Expert pattern. Assign every behavior to the object which is the information expert. Show the unknown client.


Creating Collaboration Diagrams

(continued)

Step 1.4. Paying attention to information flow, fill in the rest of the clients until there is a path of messages connecting all the objects.

Step 1.5. Refine the collaboration diagram, taking into account coupling, cohesion, and the Law of Demeter.


A Public University Example

.FI GURE 8.11


A Public University Example (continued)

Step 1.1. Apply the Façade pattern.

FI GURE 8.12



Step 1.2. Apply the Creator pattern.

FI GURE 8.15



Step 1.3. Apply the Expert pattern.

FI GURE 8.16



Step 1.3. Apply the Expert pattern.

FI GURE 8.17



Step 1.4. Considering information flow, provide a message path to every object.

FI GURE 8.18


Design Sequence Diagrams

System sequence diagrams show only messages between the system and actors.

Design sequence diagrams show all the messages between objects inside the system.


Creating Sequence Diagrams

Automated tools convert collaboration diagrams to sequence diagrams and vice versa.

Manual conversion involves using the sequence numbers in the collaboration diagrams to place the messages in the sequence diagram in order from top to bottom.


Creating Sequence Diagrams (continued)

.FI GURE 8.40


Creating Sequence Diagrams (continued)

.FI GURE 8.42


Summary

Step 1 of object-oriented program design produces interaction diagrams (collaboration or sequence diagrams) for the system.

The procedure applies the Façade, Creator, and Expert patterns and uses coupling, cohesion, and the Law of Demeter (Chapter 9) to develop and refine these diagrams.

Documents

© 2005 Prentice Hall8-1 Stumpf and Teague Object-Oriented Systems Analysis and Design with UML