Module 3: Logical Design and Behavioral Design Patterns

Contents
Overview 1
Introduction to Behavioral Design Patterns 2
ATM Scenario 8
Relevant Behavior Patterns 13
Best Practices 20
Lab 3: Logical Design and Behavioral Design
Patterns 21
Review 24

Module 3: Logical
Design and Behavioral
Design Patterns

Information in this document is subject to change without notice. The names of companies,
products, people, characters, and/or data mentioned herein are fictitious and are in no way intended
to represent any real individual, company, product, or event, unless otherwise noted. Complying
with all applicable copyright laws is the responsibility of the user. No part of this document may
be reproduced or transmitted in any form or by any means, electronic or mechanical, for any
purpose, without the express written permission of Microsoft Corporation. If, however, your only
means of access is electronic, permission to print one copy is hereby granted.

Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual
property rights covering subject matter in this document. Except as expressly provided in any

written license agreement from Microsoft, the furnishing of this document does not give you any
license to these patents, trademarks, copyrights, or other intellectual property.

 2000 Microsoft Corporation. All rights reserved.

Microsoft, Active Directory, ActiveX, BackOffice, FrontPage, Microsoft Press, MSDN, MS-DOS,
PowerPoint, Visio, Visual Basic, Visual C++, Visual InterDev, Visual J++, Visual Studio, Win32,
Windows, and Windows NT are either registered trademarks or trademarks of Microsoft
Corporation in the U.S.A. and/or other countries.

Other product and company names mentioned herein may be the trademarks of their respective
owners.

Program Managers: Rhy Mednick, Susie Parrent
Instructional Designer: Susie Parrent
Subject Matter Experts: David Chesnut, Sam Gill (TechnoWiz), Michel Pahud
Media Management: David Mahlmann
Editing Manager: Lynette Skinner
Editor: Mick Alberts, Jennifer Linn
Production Manager: Miracle Davis
Print Coordinators: Linda Lu Cannon (Write Stuff), Marlene Lambert (Online Training
Solutions, Inc.)
Build Coordinator: Eric Wagoner
Graphic Artist: Scott Serna
Test Lead: Eric Myers
Manufacturing Manager: John Williams
Group Product Manager: Juan Fernando Rivera
Lead Product Manager, System Services and Infrastructure: Edward Dudenhoefer
Manufacturing Manager: Rick Terek
Operations Coordinator: John Williams

Manufacturing Support: Laura King; Kathy Hershey
Lead Product Manager, Release Management: Bo Galford
Group Manager, Courseware Infrastructure: David Bramble
General Manager: Robert Stewart

Module 3: Logical Design and Behavioral Design Patterns iii


Instructor Notes
This module provides students with knowledge about how to use behavioral
design patterns in the transition from conceptual to logical design. Students will
also learn how to apply this knowledge to a sample application: an Automated
Teller Machine (ATM).
After completing this module, students will be able to:
!
Describe behavioral design patterns.
!
Identify the appropriate architecture template for a given set of use cases.
!
Describe how an ATM application can take advantage of behavioral design
patterns.

Materials and Preparation
This section provides the materials and preparation tasks that you need to teach
this module.
Required Materials
To teach this module, you need the following materials:
!
Microsoft
®

PowerPoint
®
file 1910A_03.ppt
!
Module 3: Logical Design and Behavioral Design Patterns
!
Lab 3: Logical Design and Behavioral Design Patterns

Preparation Tasks
To prepare for this module, you should:
!
Read all of the materials for this module.
!
Complete the lab.

Presentation:
60 Minutes

Lab:
30 Minutes
iv Module 3: Logical Design and Behavioral Design Patterns


Module Strategy
Use the following strategy to present this module:
!
Introduction to Behavioral Design Patterns
The purpose of this section is to introduce students to behavioral design
patterns and their use in the logical design. It is important to emphasize
which design patterns are discovered in order to simplify the task of creating

a logical design and to provide consistency. Patterns are not limited to those
that have been published in the design pattern literature. New patterns are
being added all the time. For examples, refer to William Stamatakis’ book
Microsoft Visual Basic Design Patterns, Microsoft Press®, 2000.
In the topic “Interaction with Users or Other Systems,” focus on the step of
discovering design patterns that are associated with the facade, the business
logic, and the data access layer (DAL). Emphasize that although the
discovery of design patterns is an art, there is a need to formalize the
patterns discovered to allow for their correct use.
Note that this course is not recommending a methodology or process for
creating logical and physical designs. For ease of learning, the layers are
presented from the front of a system to the back (user services to data
services). This is not necessarily the order in which you would actually
perform design work.
Also, you probably would not derive the entire logical design and then the
physical design, as implied by the labs in this course. For learning purposes,
that is the order of the labs. In reality, you will probably perform iterations
over the logical and physical designs.
!
ATM Scenario
The purpose of this section is to introduce students to the logical design
process by using a simple example of an ATM. The purpose of this example
is to illustrate how common behavioral design patterns are identified. The
section allows you to present a statement of the ATM problem, present the
ATM use cases, identify the architecture template for an ATM application,
and review the sequence diagram of an ATM object model.
!
Relevant Behavior Patterns
The purpose of this section is to present three behavioral design patterns that
might be useful in the logical design of an application: State,

Authentication, and Queue. Refer students to Appendix B, “Additional
Design Patterns Used in Market Purchasing,” for a formal description of
Authentication and Queue.
!
Best Practices
Discovering common behavioral patterns in an application is an important
logical design validation step. It confirms that the design is based on
recurrent themes.

Module 3: Logical Design and Behavioral Design Patterns v


Lab Strategy
!
Lab 3: Logical Design and Behavioral Design Patterns
The purpose of Lab 3 is for students to learn how to apply behavioral design
patterns. Students will probably not derive the exact same answers as the lab
answers. This is acceptable as long as the student answers are justified and
reflect the principles discussed in the module. Discuss with students their
answers to Lab 3.


Module 3: Logical Design and Behavioral Design Patterns 1


#
##
#

Overview

!
Introduction to Behavioral Design Patterns
!
ATM Scenario
!
Relevant Behavior Patterns
!
Best Practices


In this module, you will learn about using behavioral design patterns in the
transition from conceptual to logical design. You will also learn how to apply
this knowledge to a sample application: an Automated Teller Machine (ATM).
After completing this module, you will be able to:
!
Describe behavioral design patterns.
!
Identify the appropriate architecture template for a given set of use cases.
!
Describe how an ATM application can take advantage of behavioral design
patterns.

Topic Objective
To provide an overview of
the module topics and
objectives.
Lead-in
In this module, you will learn
about behavioral design
patterns.

2 Module 3: Logical Design and Behavioral Design Patterns


#
##
#

Introduction to Behavioral Design Patterns
!
The Problem
!
Interaction with Users or Other Systems
!
Maintaining Business Rules
!
Data Store


Behavioral design patterns represent behavior that can be translated into
common algorithms and assignments of responsibilities between objects. They
describe not only common activities that objects perform, but also common
patterns of communication between objects.
In this section, the following topics will be covered:
!
The problem
!
Interaction with users or other systems
!
Maintaining business rules
!

Data store

Topic Objective
To provide an overview of
the section topics and
objectives.
Lead-in
In this section, you will learn
about behavioral design
patterns.
Module 3: Logical Design and Behavioral Design Patterns 3


The Problem
!
Interactions
!
Rules
!
Data Store


An enterprise application can be characterized in terms of its three main
activities: its interaction with its users and other applications, its responsibility
for maintaining business rules and integrity, and its responsibility for recording
and storing a chronology of events.
Enterprise applications, while they might differ in their purpose, are
architecturally similar, as was shown in Module 2, “Architecture and Structural
Design Patterns.”
Similarly, enterprise objects that represent different entities within an enterprise

have many things in common. In particular, they share similar behavior. The
purpose of behavioral pattern design is to identify common patterns for
interaction with users and other systems, for maintaining business rules, and for
storing data.
Discovering useful patterns and using them in the logical design of objects is an
art. The approach being prescribed for the logical design in object-oriented
analysis and design is to first identify the architecture template, to then identify
the enterprise objects that belong to each of the architecture template layers, and
to finally identify the behavioral design pattern for each of the enterprise
objects.
The goal for this approach is to use in a design as many common elements as
possible.
An excellent logical design presents the correct mix of an architectural
template, objects, and object behavioral patterns.
Because it is impossible to identify all of the pieces (the architecture, objects,
and object behavioral patterns) simultaneously, the problem is partitioned into
first identifying the architecture template, then identifying the objects, and
finally identifying the behavioral design patterns applicable for each object.
Topic Objective
To provide a background of
the behavioral design
pattern problem.
Lead-in
In this slide, you will learn
about the problem facing
application designers that
necessitates behavioral
design patterns.
4 Module 3: Logical Design and Behavioral Design Patterns

Interaction with Users or Other Systems
!
Interaction with Users
!
Interaction with Other Systems


If you think about the kind of behavior that is involved in user interaction or
interaction with other systems, you will realize that there are some common
behavioral design patterns.
Interaction with Users
For interaction with users, you could consider the following behavioral design
patterns:
!
Command
Command is a behavioral design pattern that represents requests as objects,
thereby allowing objects to be separate from the commands they execute.
For example, a toolkit may provide user interface elements such as buttons
and menu items. However, the toolkit cannot possibly know the actions with
which a user will connect those elements. A Button class will likely
perform many different functions in the same application. How will it call
the correct function when pressed? The Command pattern allows an
appropriate concrete command class to be associated with user interface
elements at run time. When the button is pressed, it calls the Command
object with which it was initialized.
!
Memento
Memento is a behavioral design pattern that captures and externalizes an
object’s internal state. An example of using a Memento occurs when a user

logs on, and the state of the application at the time they logged on
previously is restored. This state is then exposed to all of the other objects in
the application.

Topic Objective
To provide a background
about interaction with users
and other systems.
Lead-in
In this topic, you will learn
how to identify common
behavioral design patterns
in interaction with users and
other systems.
Module 3: Logical Design and Behavioral Design Patterns 5


Interaction with Other Systems
For interaction with other systems, you might consider using a Queue
behavioral design pattern.
Queue is a behavioral design pattern that defines a many-to-many dependency
between objects so that one or more objects post messages to a message queue
and all of their dependents can retrieve the messages from the message queue.
You might not find the Queue behavioral design pattern in the design patterns
literature. The Queue behavioral pattern was discovered during the
development of this course and the accompanying Market Purchasing
application. The Queue behavioral design pattern is described in detail in
Appendix B: “Additional Design Patterns used in Market Purchasing.”
Design patterns are not limited to the patterns that are formalized in the design
patterns literature. You should discover and add your own patterns based on

your observation of common behavior or interactions between objects in your
enterprise applications. Looking for common behavior is an important task
when deriving design patterns. Many patterns seem obvious once you discover
them because similar characteristics that define a pattern recur on many
systems.
6 Module 3: Logical Design and Behavioral Design Patterns


Maintaining Business Rules
!
Maintaining Integrity
!
Maintaining Consistency


The second objective of an enterprise application is to maintain the business
rules that drive the enterprise. Maintaining business rules includes maintaining
their integrity and consistency by having uniform behavior. There are some
design patterns that can be used to reflect common behavior in business rules.
These behavioral design patterns include the following:
!
Observer
Observer is a behavioral design pattern that defines a one-to-many
dependency between objects so that when a publisher object changes state,
all of its subscriber objects are notified. For example, consider a component
that needs to monitor stock prices. A stock ticker component could publish
all stock prices as they occur. Subscriber components could listen to the
stock ticker. The subscribers would be called when a stock price changes. In
a more sophisticated example, filters could be used so that subscribers only
get called when certain stock prices change or when they change above or

below a certain price level.
!
Visitor
Visitor is a behavioral design pattern that represents an operation that needs
to be performed on elements of an object structure. Visitor allows new
operations be defined without changing existing classes in the object
structure. An example of using a Visitor occurs in an order pipeline. In an
order pipeline, it is necessary to calculate taxes. The objects that calculate
taxes are Visitors to the order pipeline object structure that extend the order
processing without changing its existing classes or structure.

You will explore some of these patterns in more detail later in this course.
Topic Objective
To provide background
about interaction with users
and other systems.
Lead-in
In this topic, you will learn
how to identify common
behavioral design patterns
in interaction with users and
other systems.