Behavioral pattern

In software engineering, behavioral design patterns are design patterns that identify common communication
patterns between objects and realize these patterns. By doing so, these patterns increase flexibility in carrying
out this communication.

Examples of this type of design pattern include:

§ Chain of responsibility pattern: Command objects are handled or passed on to other objects by logic-
containing processing objects

§ Command pattern: Command objects encapsulate an action and its parameters

§ "Externalize the Stack": Turn a recursive function into an iterative one that uses a stack.[1]
§ Interpreter pattern: Implement a specialized computer language to rapidly solve a specific set of problems

§ Iterator pattern: Iterators are used to access the elements of an aggregate object sequentially without
exposing its underlying representation
§ Mediator pattern: Provides a unified interface to a set of interfaces in a subsystem
§ Memento pattern: Provides the ability to restore an object to its previous state (rollback)

§ Observer pattern: aka Publish/Subscribe or Event Listener. Objects register to observe an event that may
be raised by another object
§ Weak reference pattern: De-couple an observer from an observable.[2]
§ State pattern: A clean way for an object to partially change its type at runtime

§ Strategy pattern: Algorithms can be selected on the fly

§ Template method pattern: Describes the program skeleton of a program

§ Visitor pattern: A way to separate an algorithm from an object

In Object Oriented Design, the chain-of-responsibility pattern is a design pattern consisting of a

source of command objects and a series of processing objects. Each processing object contains
logic that defines the types of command objects that it can handle; the rest are passed to the next
processing object in the chain. A mechanism also exists for adding new processing objects to the
end of this chain.

In object-oriented programming, the command pattern is a design pattern in which an object is

used to represent and encapsulate all the information needed to call a method at a later time. This
information includes the method name, the object that owns the method and values for the method
parameters.

In computer programming, the interpreter pattern is a design pattern that specifies how to evaluate
sentences in a language. The basic idea is to have a class for each symbol (terminal or nonterminal)
in a specialized computer language. The syntax tree of a sentence in the language is an instance of
the composite pattern and is used to evaluate (interpret) the sentence.[1]

N@ru Mtech Cse(1-1) Study Material

In object-oriented programming, the iterator pattern is a design pattern in which an iterator is used
to traverse a container and access the container's elements. The iterator pattern
decouples algorithms from containers; in some cases, algorithms are necessarily container-specific
and thus cannot be decoupled.

The mediator pattern defines an object that encapsulates how a set of objects interact. This pattern
is considered to be a behavioral pattern due to the way it can alter the program's running behavior.

Usually a program is made up of a (sometimes large) number of classes. So

the logic and computation is distributed among these classes. However, as more classes are
developed in a program, especially during maintenance and/or refactoring, the problem
of communication between these classes may become more complex. This makes the program
harder to read and maintain. Furthermore, it can become difficult to change the program, since any
change may affect code in several other classes.

With the mediator pattern, communication between objects is encapsulated with a mediator object.
Objects no longer communicate directly with each other, but instead communicate through the
mediator. This reduces the dependencies between communicating objects, thereby lowering
the coupling.

The memento pattern is a software design pattern that provides the ability to restore an object to its
previous state (undo via rollback).

The memento pattern is implemented with two objects: the originator and a caretaker. The originator
is some object that has an internal state. The caretaker is going to do something to the originator,
but wants to be able to undo the change. The caretaker first asks the originator for a memento
object. Then it does whatever operation (or sequence of operations) it was going to do. To roll back
to the state before the operations, it returns the memento object to the originator. The memento
object itself is anopaque object (one which the caretaker cannot, or should not, change). When using
this pattern, care should be taken if the originator may change other objects or resources - the
memento pattern operates on a single object.

The observer pattern is a software design pattern in which an object, called the subject, maintains
a list of its dependents, called observers, and notifies them automatically of any state changes,
usually by calling one of their methods. It is mainly used to implement distributed event
handling systems. Observer is also a key part in the familiar MVCarchitectural pattern. In fact the
observer pattern was first implemented in Smalltalk's MVC based user interface framework.[1]

The state pattern, which closely resembles Strategy Pattern, is a behavioral software design
pattern, also known as the objects for states pattern. This pattern is used incomputer
programming to represent the state of an object. This is a clean way for an object to partially change
its type at runtime[1]:395.

N@ru Mtech Cse(1-1) Study Material

In computer programming, the strategy pattern (also known as the policy pattern) is a
particular software design pattern, whereby algorithms can be selected at runtime. Formally
speaking, the strategy pattern defines a family of algorithms, encapsulates each one, and makes
them interchangeable. Strategy lets the algorithm vary independently from clients that use it.[1]

A template method defines the program skeleton of an algorithm. One or more of the algorithm
steps can be overridden by subclasses to allow differing behaviors while ensuring that the
overarching algorithm is still followed.

In object-oriented programming, first a class is created that provides the basic steps of an algorithm
design. These steps are implemented using abstract methods. Later on, subclasses change the
abstract methods to implement real actions. Thus the general algorithm is saved in one place but the
concrete steps may be changed by the subclasses.
In object-oriented programming and software engineering, the visitor design pattern is a way of
separating an algorithmfrom an object structure on which it operates. A practical result of this
separation is the ability to add new operations to existing object structures without modifying those
structures. It is one way to easily follow the open/closed principle.

Behavioral patterns

In Design In Code
Name Description Other
Patterns Complete[17]

Generalized observer, which allows

multiple readers and writers.
Blackboard No No N/A
Communicates information system-
wide.

Avoid coupling the sender of a

request to its receiver by giving
more than one object a chance to
Chain of responsibility handle the request. Chain the Yes No N/A

receiving objects and pass the

request along the chain until an
object handles it.

Command Encapsulate a request as an object, Yes No N/A

thereby letting you parameterize

N@ru Mtech Cse(1-1) Study Material

 clients with different requests, queue
or log requests, and
support undoable operations.

Given a language, define a

representation for its grammar along
Interpreter with an interpreter that uses the Yes No N/A

representation to interpret
sentences in the language.

Provide a way to access the

elements of an aggregate object
Iterator Yes Yes N/A
sequentially without exposing its
underlying representation.

Define an object that encapsulates

how a set of objects interact.
Mediator promotes loose
Mediator coupling by keeping objects from Yes No N/A
referring to each other explicitly, and
it lets you vary their interaction
independently.

Without violating encapsulation,

capture and externalize an object's
Memento Yes No N/A
internal state allowing the object to
be restored to this state later.

Avoid null references by providing a

Null object No No N/A
default object.

Define a one-to-many dependency

Observer orPublish/subscribe between objects where a state Yes Yes N/A
change in one object results in all its
dependents being notified and

N@ru Mtech Cse(1-1) Study Material

 updated automatically.

Define common functionality for a

Servant No No N/A
group of classes

Recombinable business logic in

Specification No No N/A
a Boolean fashion

Allow an object to alter its behavior

when its internal state changes. The
State Yes No N/A
object will appear to change its
class.

Define a family of algorithms,

encapsulate each one, and make
Strategy them interchangeable. Strategy lets Yes Yes N/A

the algorithm vary independently

from clients that use it.

Define the skeleton of an algorithm

in an operation, deferring some
steps to subclasses. Template
Template method Yes Yes N/A
method lets subclasses redefine
certain steps of an algorithm without
changing the algorithm's structure.

Represent an operation to be
performed on the elements of an
object structure. Visitor lets you
Visitor Yes No N/A
define a new operation without
changing the classes of the
elements on which it operates.

N@ru Mtech Cse(1-1) Study Material

A-7E Avionics System: A Case Study in
Utilizing Architectural Structures
An object-oriented program's runtime structure often bears little resemblance to its code
structure. The code structure is frozen at compile-time; it consists of classes in fixed
inheritance relationships. A program's runtime structure consists of rapidly changing
networks of communicating objects. In fact, the two structures are largely independent.
Trying to [understand] one from the other is like trying to understand the dynamism of
living ecosystems from the static taxonomy of plants and animals, and vice versa.

software architecture describes elements of a system and the relations among them. We
also emphasized that every system has many kinds of elements and that different
architectural structures are useful, even necessary, to present a complete picture of the
architecture of a system. Each structure concentrates on one aspect of the architecture.

case study of an architecture designed by engineering and specifying three specific

architectural structures: module decomposition, uses, and process. We will see how these
structures complement each other to provide a complete picture of how the system works,
and we will see how certain qualities of the system are affected by each one. Table 3.1
summarizes the three structures we will discuss.

Table 3.1. The A-7E's Architecural Structures

Relation among
Structure Elements Elements Has Influence Over

Module Modules Is a submodule of; Ease of change

Decomposition (implementation shares a secret with
units)

Uses Procedures Requires the correct Ability to field subsets and

presence of develop incrementally

Process Processes; thread of Synchronizes with; Schedulability; achieving

procedures shares CPU with; performance goals through
excludes parallelism

N@ru Mtech Cse(1-1) Study Material

 Architecture for the A-7E Avionics System
The architecture for the A-7E avionics system is centered around three architectural
structures

• Decomposition, a structure of modules

• Uses, a structure of modules

• Process, a structure of components and connectors

We will discuss each in turn.

DECOMPOSITION STRUCTURE

How the A-7E Module Decomposition Structure Achieves Quality Goals

Goal How Achieved

Ease of change to: weapons, Information hiding

platform, symbology, input

Understand anticipated changes Formal evaluation procedure to take advantage of

experience of domain experts

Assign work teams so that their Modules structured as a hierarchy; each work team
interactions were minimized assigned to a second-level module and all of its
descendants

USES STRUCTURE

How the A-7E Uses Structure Achieves Quality Goals

Goal How Achieved

Incrementally build and test Create "is-allowed-to-use" structure for programmers that
system functions limits procedures each can use

N@ru Mtech Cse(1-1) Study Material

 How the A-7E Uses Structure Achieves Quality Goals

Goal How Achieved

Design for platform change Restrict number of procedures that use platform directly

Produce usage guidance of Where appropriate, define uses to be a relationship

manageable size among modules

The World Wide Web'A Case Study in

Interoperability
Architectural Solution
The basic architectural approach used for the Web, first at CERN and later at the World Wide
Web Consortium (W3C), relied on clients and servers and a library (libWWW) that masks all
hardware, operating system, and protocol dependencies. Figure 13.3 shows how the content
producers and consumers interact through their respective servers and clients. The producer
places content that is described in HTML on a server machine. The server communicates
with a client using the HyperText Transfer Protocol (HTTP). The software on both the server
and the client is based on libWWW, so the details of the protocol and the dependencies on
the platforms are masked from it. One of the elements on the client side is a browser that
knows how to display HTML so that the content consumer is presented with an
understandable image.

Content producers and consumers interact through clients and servers

N@ru Mtech Cse(1-1) Study Material

MEETING THE ORIGINAL REQUIREMENTS: libWWW
As stated earlier, libWWW is a library of software for creating applications that run on either
the client or the server. It provides the generic functionality that is shared by most
applications: the ability to connect with remote hosts, the ability to understand streams of
HTML data, and so forth.

libWWW is a compact, portable library that can be built on to create Web-based applications
such as clients, servers, databases, and Web spiders. It is organized into five layers, as
Figure 13.4. A layered view of libWWW

ACHIEVING INITIAL QUALITY GOALS

describes how the Web achieved its initial quality goals of remote access, interoperability,
extensibility, and scalability.

How the WWW Achieved Its Initial Quality Goals

Goal How Achieved Tactics Used

N@ru Mtech Cse(1-1) Study Material

 How the WWW Achieved Its Initial Quality Goals

Goal How Achieved Tactics Used

Remote Access Build Web on top of Internet Adherence to

defined protocols

Interoperability Use libWWW to mask platform details Abstract common

services

Hide information

Extensibility of Isolate protocol and data type Abstract common

Software extensions in libWWW; allow for services
plug-in components (applets and Hide information
servlets)
Replace
components

Configuration files

Extensibility of Make each data item independent Limit possible

Data except for references it controls options

Scalability Use client-server architecture and Introduce

keep references to other data local to concurrency
referring data location Reduce
computational
overhead

N@ru Mtech Cse(1-1) Study Material

Air Traffic Control: A Case Study in Designing
for High Availability

Air traffic control (ATC) is among the most demanding of all software applications. It is hard
real time, meaning that timing deadlines must be met absolutely; it is safety critical,
meaning that human lives may be lost if the system does not perform correctly; and it
is highly distributed, requiring dozens of controllers to work cooperatively to guide aircraft
through the airways system. In the United States, whose skies are filled with more
commercial, private, and military aircraft than any other part of the world, ATC is an area of
intense public scrutiny. Aside from the obvious safety issues, building and maintaining a
safe, reliable airways system requires enormous expenditures of public money. ATC is a
multibillion-dollar undertaking.

This chapter is a case study of one part of a once-planned, next-generation ATC system for
the United States. We will see how its architecture?in particular, a set of carefully chosen
views (as in Chapter 2) coupled with the right tactics (as in Chapter 5)?held the key to
achieving its demanding and wide-ranging requirements. Although this system was never
put into operation because of budgetary constraints, it was implemented and demonstrated
that the system could meet its quality goals.

In the United States, air traffic is controlled by the Federal Aviation Administration (FAA), a
government agency responsible for aviation safety in general. The FAA is the customer for
the system we will describe. As a flight progresses from its departure airport to its arrival
airport, it deals with several ATC entities that guide it safely through each portion of the
airways (and ground facilities) it is using. Ground control coordinates the movement of
aircraft on the ground at an airport. Towers control aircraft flying within an
airport's terminal control area, a cylindrical section of airspace centered at an airport.
Finally, en route centers divide the skies over the country into 22 large sections of
responsibility.

Consider an airline flight from Key West, Florida, to Washington, D.C.'s Dulles Airport. The
crew of the flight will communicate with Key West ground control to taxi from the gate to
the end of the runway, Key West tower during takeoff and climb-out, and then Miami Center
(the en route center whose airspace covers Key West) once it leaves the Key West terminal
control area. From there the flight will be handed off to Jacksonville Center, Atlanta Center,
and so forth, until it enters the airspace controlled by Washington Center. From Washington
Center, it will be handed off to the Dulles tower, which will guide its approach and landing.

N@ru Mtech Cse(1-1) Study Material

When it leaves the runway, the flight will communicate with Dulles ground control for its
taxi to the gate. This is an oversimplified view of ATC in the United States, but it suffices for
our case study. Figure 6.1 shows the hand-off process, and Figure 6.2 shows the 22 en
route centers.

Flying from point A to point B in the U.S. air traffic control system.

Courtesy of Ian Worpole/Scientific American, 1994.

N@ru Mtech Cse(1-1) Study Material

 Figure 6.2. En route centers in the United States

The system we will study is called the Initial Sector Suite System (ISSS), which was
intended to be an upgraded hardware and software system for the 22 en route centers in
the United States. It was part of a much larger government procurement that would have,
in stages, installed similar upgraded systems in the towers and ground control facilities, as
well as the transoceanic ATC facilities.

The fact that ISSS was to be procured as only one of a set of strongly related systems had a
profound effect on its architecture. In particular, there was great incentive to adopt common
designs and elements where possible because the ISSS developer also intended to bid on
the other systems. After all, these different systems (en route center, tower, ground
control) share many elements: interfaces to radio systems, interfaces to flight plan
databases, interfaces to each other, interpreting radar data, requirements for reliability and
performance, and so on. Thus, the ISSS design was influenced broadly by the requirements
for all of the upgraded systems, not just the ISSS-specific ones. The complete set of
upgraded systems was to be called the Advanced Automation System (AAS).

Ultimately, the AAS program was canceled in favor of a less ambitious, less costly, more
staged upgrade plan. Nevertheless, ISSS is still an illuminating case study because, when
the program was canceled, the design and most of the code were actually already
completed. Furthermore, the architecture of the system (as well as most other aspects) was

N@ru Mtech Cse(1-1) Study Material

studied by an independent audit team and found to be well suited to its requirements.
Finally, the system that was deployed instead of ISSS borrowed heavily from the ISSS
architecture. For these reasons, we will present the ISSS architecture as an actual solution
to an extremely difficult problem.

How the ATC System Achieves Its Quality Goals

Goal How Achieved Tactic(s) Used

High Availability Hardware redundancy (both State resynchronization; shadowing;

processor and network); active redundancy; removal from service;
software redundancy (layered limit exposure; ping/echo; heartbeat;
fault detection and recovery) exception; spare

High Distributed multiprocessors; Introduce concurrency

Performance front-end schedulability
analysis, and network
modeling

Openness Interface wrapping and Abstract common services; maintain

layering interface stability

Modifiability Templates and table-driven Abstract common services; semantic

adaptation data; careful
assignment of module
responsbilities; strict use of
specified interfaces
coherence; maintain interface stability;
anticipate expected changes; generalize
the module; component replacement;
adherence to defined procotols;
configuration files

Ability to Field Appropriate separation of Abstract common services

Subsets concerns

Interoperability Client-server division of Adherence to defined protocols; maintain

functionality and message- interface stability
based communications

N@ru Mtech Cse(1-1) Study Material

CelsiusTech: A Case Study in Product Line
Development
This chapter relates the experience of CelsiusTech AB, a Swedish naval defense contractor
that successfully adopted a product line approach to building complex software-intensive
systems. Called Ship System 2000 (SS2000), their product line consists of shipboard
command-and-control systems for Scandinavian, Middle Eastern, and South Pacific navies.

This case study illustrates the entire Architecture Business Cycle (ABC), but especially
shows how a product line architecture led CelsiusTech to new business opportunities. Figure
15.1 shows the roles of the ABC stakeholders in the CelsiusTech experience.

Figure 15.1. The ABC as applied to CelsiusTech

SS2000 Requirements and How the Architecture Achieved Them

Requirement How Achieved Related Tactic(s)

N@ru Mtech Cse(1-1) Study Material

 SS2000 Requirements and How the Architecture Achieved Them

Requirement How Achieved Related Tactic(s)

Performance Strict network traffic protocols; software is Introduce

written as a set of processes to maximize concurrency
concurrency and written to be location
Reduce demand
independent, allowing for relocation to tune
Multiple copies
performance; COOB is by-passed for high-data-
volume transactions; otherwise, data sent only Increase resources
when altered and distributed so response times
are short

Reliability, Redundant LAN; fault-tolerant software; Exceptions

Availability, and standard Ada exception protocols; software
Active redundancy
Safety written to be location independent and hence
State
can be migrated in case of failure; strict
resynchronization
ownership of data prevents multi-writer race
conditions Transactions

Modifiability Strict use of message-based communication Semantic

(including ability to provides interface isolated from implementation coherence
produce new details; software written to be location
Anticipate expected
members of the independent; layering provides portability
changes
SS2000 family) across platforms, network topologies, IPC
Generalize modules
protocols, etc.; data producers and consumers
unaware of each other because of COOB; heavy Abstract common
use of Ada generics; heavy use of element services
parameterization; system functions and system
Interface stability
function groups provide semantic coherence
Intermediary

N@ru Mtech Cse(1-1) Study Material

 SS2000 Requirements and How the Architecture Achieved Them

Requirement How Achieved Related Tactic(s)

Configuration files

Component
replacement

Adherence to
defined protocols

Testability Interfaces using strongly typed messages push Separate interface

a whole class of errors to compile time; strict from
data ownership, semantic coherence of implementation
elements, and strong interface definitions
simplify discovery of responsibility

N@ru Mtech Cse(1-1) Study Material