Upload
hannah-stone
View
217
Download
0
Tags:
Embed Size (px)
Citation preview
© 2005 Prentice Hall 8-1
Stumpf and TeagueObject-Oriented Systems Analysis and Design with
UML
Chapter 8Program Design –
I nteraction D iagram s
© 2005 Prentice Hall 8-2
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.
© 2005 Prentice Hall 8-3
Learning Objectives (continued)
• Understand the differences between collaboration and sequence diagrams.
• Create interaction diagrams.
© 2005 Prentice Hall 8-4
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.
© 2005 Prentice Hall 8-5
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.
© 2005 Prentice Hall 8-6
Overview (continued)
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.
© 2005 Prentice Hall 8-7
Overview (continued)
The interaction diagrams are developed on the basis of system operation contracts produced during analysis.
This overall approach is called“design by contract.”
© 2005 Prentice Hall 8-8
Overview (continued)
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.
© 2005 Prentice Hall 8-9
Overview (continued)
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.
© 2005 Prentice Hall 8-10
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)
© 2005 Prentice Hall 8-11
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.
© 2005 Prentice Hall 8-12
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.
© 2005 Prentice Hall 8-13
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.
© 2005 Prentice Hall 8-14
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.
© 2005 Prentice Hall 8-15
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
© 2005 Prentice Hall 8-16
Fundamental Concepts – Messages (continued)
Polymorphism: Objects in different classes may respond differently to messages with the same name.
© 2005 Prentice Hall 8-17
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.
© 2005 Prentice Hall 8-18
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
© 2005 Prentice Hall 8-19
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
© 2005 Prentice Hall 8-20
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
© 2005 Prentice Hall 8-21
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
© 2005 Prentice Hall 8-22
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.
© 2005 Prentice Hall 8-23
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.)
© 2005 Prentice Hall 8-24
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.
© 2005 Prentice Hall 8-25
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.
© 2005 Prentice Hall 8-26
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.
© 2005 Prentice Hall 8-27
Collaboration Diagrams (continued)
.
FI GURE 8.5
© 2005 Prentice Hall 8-28
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.
© 2005 Prentice Hall 8-29
Sequence Diagrams (continued)
.
FI GURE 8.6
© 2005 Prentice Hall 8-30
Design Class Diagrams
A design class diagram follows the same conventions as a domain model.
However, it also shows the operations of the classes.
© 2005 Prentice Hall 8-31
Design Class Diagrams (continued)
.
FI GURE 8.7
© 2005 Prentice Hall 8-32
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.
© 2005 Prentice Hall 8-33
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.
© 2005 Prentice Hall 8-34
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.
© 2005 Prentice Hall 8-35
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)
© 2005 Prentice Hall 8-36
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.
© 2005 Prentice Hall 8-37
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.
© 2005 Prentice Hall 8-38
A Public University Example
.FI GURE 8.11
© 2005 Prentice Hall 8-39
A Public University Example (continued)
Step 1.1. Apply the Façade pattern.
FI GURE 8.12
© 2005 Prentice Hall 8-40
A Public University Example (continued)
Step 1.2. Apply the Creator pattern.
FI GURE 8.15
© 2005 Prentice Hall 8-41
A Public University Example (continued)
Step 1.3. Apply the Expert pattern.
FI GURE 8.16
© 2005 Prentice Hall 8-42
A Public University Example (continued)
Step 1.3. Apply the Expert pattern.
FI GURE 8.17
© 2005 Prentice Hall 8-43
A Public University Example (continued)
Step 1.4. Considering information flow, provide a message path to every object.
FI GURE 8.18
© 2005 Prentice Hall 8-44
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.
© 2005 Prentice Hall 8-45
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.
© 2005 Prentice Hall 8-46
Creating Sequence Diagrams (continued)
.FI GURE 8.40
© 2005 Prentice Hall 8-47
Creating Sequence Diagrams (continued)
.FI GURE 8.42
© 2005 Prentice Hall 8-48
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.