Contents 3

Architectural patterns
Introduction

39

Patterns 40
1.1 Why are patterns helpful? 40
1.2 Pattern schema or template 41
1.3 Design patterns and architectural patterns
2
Examples of architectural patterns 41
2.1 Layers pattern 42
2.2 Client-Server pattern 44
2.3 Master-Slave pattern 46
2.4 Pipe-Filter pattern 47
2.5 Broker pattern 49
2.6 Peer-to-Peer pattern 51
2.7 Event-Bus pattern 52
2.8 Model-View-Controller pattern 53
2.9 Blackboard pattern 55
2.10 Interpreter pattern 56
3
Applying patterns: KWIC example 56
3.1 Shared data 57
3.2 Layers pattern 57
3.3 Event-Bus 58
3.4 Pipe-filter 58
4
Architectural styles 59
4.1 Choosing a style or a pattern 59
Discussion questions 60

1

38

41

Learning unit 3

Architectural patterns

INTRODUCTION

Before major development starts, we need to choose an architecture thatwill provide us with the desired quality attributes. Therefore we needa way to discuss architectural options and their quality consequencesin advance, before they can be applied to a design. Our decisions at
this stage can only be based on experience with architectural choices inprevious systems. Such architectural experience, reduced to its essence
and no longer cluttered with the details of the systems that produced it,is recorded in architectural patterns.
Many systems have a similar structure. Distributed systems, for instance, can have a client-server structure, with clients making requests
and a server processing those requests and answering them. When we
observe a similarity, we want to know what is common among the solutions and what variations are possible. We ask in what circumstances
an approach may be used, and how it should be used and customised
for a particular system. An architectural pattern provides an answer tosuch questions.
This learning unit introduces architectural patterns and their relation
with design patterns. We will discuss several examples of architectural
patterns, but these examples do not include all architectural patterns:
we will discuss ways to classify them.
Using an example, we will show the effect of different patterns on thesame problem. The example makes clear that you need to be able tochoose the right pattern for a given situation. To make the right choice,you need experience with different systems. Knowledge about patterns
will help you to expand upon what you learn through experience, because by learning about patterns, you learn from the experience of others.

LEARNING GOALS

After having studied this learning unit, you will be expected to be ableto:– describe the structure and function of the patterns which are covered in this unit
– describe the advantages and disadvantages of the patterns which
are covered in this unit
– explain the difference between a style and a pattern– give examples of applications of the patterns covered in this unit
– name examples of patterns that fit a certain style.

39

Open Universiteit

Software Architecture

LEARNING CORE
1

Patterns

Definition 16 (Architectural pattern) An architectural pattern is aproven structural organisation schema for software systems.

A pattern is a description of a set of predefined subsystems and their responsibilities. In a system structured according to the Client-Server pattern, for instance, two subsystems are distinguished: the client (which
can have many instances) and the server (which is unique). The responsibility of the client may be to show a user-interface to the user; theresponsibility of the server may be to process many questions and to
guard data that are of interest to the client.
A pattern also describes rules and guidelines for organising the relationships among the subsystems. The relationship between the client
and the server is that the client asks questions and the server answers
them.
Patterns are written by people with lots of experience. Knowledge
which could have remained hidden in the heads of these experienced
people is made explicit in the form of patterns. This enables others
to learn from that experience. Patterns are not constructed by a single
person: they reflect the experience of many developers. They capture
existing, well-proven solutions in software development and help topromote good design practices.
Architectural styleArchitectural patterns are also called Architectural styles, or standard architectures, but the word architectural style is more often used for aconcept that is less fine-grained than a pattern; several patterns may
therefore belong to the same architectural style. We will explain thesubtle differences later in this learning unit.
1.1

WHY ARE PATTERNS HELPFUL ?

When a certain kind of problem is solved by many developers in a similar way, and it is generally accepted that this way solves that problem well, it becomes a pattern. A pattern is therefore something that
addresses a recurring design problem for which a general solution is
known among experienced practitioners: a pattern documents existing
design solutions that have proved their worth.
By writing a pattern, it becomes easier to reuse the solution. Patterns
provide a common vocabulary and understanding of design solutions.
Pattern names become part of a widespread design language. They
remove the need to use a lengthy description to explain a solution toa particular problem. Patterns are therefore a means for documenting
software architectures. They help maintain the original vision when thearchitecture is extended and modified, or when the code is modified(but they cannot guarantee it).

40

Learning unit 3

Architectural patterns

Patterns support the construction of software with defined properties.
When we design a client-server application, for instance, the server
should not be built in such a way that it initiates communication with
its clients.
Many patterns explicitly address non-functional requirements for software systems. For example, the MVC (Model-View-Controller) pattern
supports changeability of user interfaces. Patterns may thus be seen as
building blocks for a more complicated design.
1.2

Pattern template

Patterns are described using a pattern template or pattern schema. All of
the many different templates have at least the following components:– context: the situation giving rise to a problem– problem: the recurring problem in that context. A solution to the problem should fulfil requirements, consider constraints and have desirable properties. These conditions are called forces. Forces may conflict with each other (performance may conflict with extensibility, forinstance). Forces differ in the degree to which they are negotiable– solution: a proven solution for the problem. The solution is given as astructure with components and relationships and as a description of
the run-time behaviour. The first description is a static model of thesolution; the second is a dynamic one.
1.3

Design pattern

PATTERN SCHEMA OR TEMPLATE

DESIGN PATTERNS AND ARCHITECTURAL PATTERNSWhat is the difference between design patterns and architectural patterns? Design patterns offer a common solution for a common problem in the form of classes working together. They are thus smaller inscale than architectural patterns, where the components are subsystems
rather than classes.
Design patterns do not influence the fundamental structure of a software system. They only affect a single subsystem. Design patterns mayhelp to implement an architectural pattern. For example, the Observer
pattern (a design pattern) is helpful when implementing a system according to the MVC architectural pattern.

Gang of Four

The concept of patterns was originally introduced by Christopher Alexander in building architecture, in ‘A pattern language’ [3] (1977) and ‘The
timeless way of building’ [2] (1979). Design patterns first attracted attention in software design and development (the Gang of Four book [22]).
Since then, patterns have been used in more disciplines: there are analysis patterns, user interface patterns, programming idioms, functional
design patterns and so on.
2

Examples of architectural patterns

In this section, we describe several architectural patterns. For each ofthese, we describe the components and connections involved, give one
or more usage examples and discuss advantages, disadvantages andother issues.

41

Open Universiteit

Software Architecture

2.1

LAYERS PATTERN

Layer nLayer n - 1

FIGURE 3.1

Layers pattern

Layers of different abstraction levels

The Layers pattern (see Figure 3.1) helps to structure applications thatcan be decomposed into groups of subtasks, each of which is at a particular level of abstraction. Each layer provides services to the next higher
layer. Services in a layer are implemented using services from the next
lower layer. Service requests are frequently done by using synchronous
procedure calls.
In short, this pattern means that conceptually different issues are implemented separately, and that layers of a higher abstraction level use
services of a lower abstraction level, and not the other way around.
This pattern has the following benefits:– A lower layer can be used by different higher layers. The TCP layerfrom TCP / IP connections, for instance, can be reused without changes
by various applications, such as telnet or FTP.
– Layers make standardisation easier: clearly defined and commonly
accepted levels of abstraction make it possible to develop standardised tasks and interfaces.
– Dependencies are kept local. When a layer shows the agreed interface to the layer above, and expects the agreed interface of the layer
below, changes can be made within the layer without affecting otherlayers. This means a developer can test particular layers independently of other layers, and can develop them independently as well:this supports development by teams.
A result of the above is that layers may easily be replaced by a different
implementation.
Example: networking protocols

ISO/OSI protocol

Figure 3.2 depicts the ISO Open System Interconnect seven layers protocol (the ISO / OSI protocol). TCP / IP is a simplified version of this protocol. FTP and HTTP are examples from the application layer; TCP is thetransport layer and IP is the network layer.
Some other examples of this pattern are:
– In the Java virtual machine, the application in Java consists of instructions for the Java virtual machine; the JVM uses services fromthe operating system underneath.

42

Learning unit 3

Architectural patterns

Application

Provides miscellaneous
protocols for common
activities

Presentation

Structures information andattaches semantics

Session

Provides dialog control
and synchronization
facilities

Transport

Breaks messages into
packets and guaranteesdelivery

Network

Selects a route fromsender to receiver

Data Link

Detects and corrects
errors in bit sequences

PhysicalTransmits bits

FIGURE 3.2

Example: networking protocols– The standard C library is built on Unix system calls.
– Web application systems often show four or more layers: presentation, application logic, domain logic and data.
– The microkernel architecture has layers on top of the microkernel:
The Mach operating system, the JBoss application server, Windows
NT and QNX are examples of the microkernel architecture.
Issues in the Layers pattern
The most stable abstractions are in the lower layer: a change in the behaviour of a layer has no effect on the layers below it. The opposite istrue as well: a change in the behaviour of a lower layer has an effect on
the layers above it, so this should be avoided.
Of course, changes in or additions to a layer without an effect on behaviour will not affect the layers above it. Layer services can therefore
be implemented in different ways (think of the Bridge pattern here,
where a dynamic link is maintained between abstraction and implementation).
Layers can be developed independently. However, defining an abstract
service interface is not an easy job. There may also be performance
overhead due to repeated transformations of data. Furthermore, thelower layers may perform unnecessary work that is not required by thehigher layers.
Relaxed layered system

There are several variants of the Layers pattern.
– In a Relaxed layered system, each layer may use the services of all layers
below it, not only of the next lower layer. This has efficiency benefits,
but leads to a loss of maintainability. Windows’ microkernel architec-

43

Open Universiteit

Callback

Software Architecture

ture is an example of this variant. The user interface of Eclipse forms
another example: Eclipse makes use of the SWT (the Standard Widget
Toolkit, [16]) and JFace [15]. JFace is a layer on top of the SWT andoffers a higher level of abstraction than SWT, but it is possible to useclasses of both JFace and the SWT in the same application.
– Another variant is to allow callbacks for bottom-up communication:
here, the upper layer registers a callback function with the lower
layer, as a result of which the upper layer is notified when an event
occurs.

2.2

CLIENT- SERVER PATTERN

ClientTCP/IP

Server

FIGURE 3.3

Client-Server pattern

Client-Server pattern

In the Client-Server pattern (see Figure 3.3), a server component provides
services to multiple client components. A client component requests
services from the server component. Servers are permanently active,
listening for clients.
The requests are sent beyond process and machine boundaries. Thismeans that some inter-process communication mechanism is required:clients and servers may reside on different machines, and thus in different processes. In fact, you can see the Client-Server pattern as a variantof the Layered pattern, crossing process or machine boundaries: clients
form the higher level and the server forms the lower level.

ExamplesExamples of the Client-Server pattern are remote database access (client
applications request services from a database server), remote file systems (client systems access files, provided by the server system; applications access local and remote files in a transparent manner) or webbased applications (browsers request data from a web server).

44

Learning unit 3

Architectural patterns

Issues in the Client-Server pattern
Requests are typically handled in separate threads on the server.
Inter-process communication causes overhead. Requests and result data
often have to be transformed or marshalled because they have a different representation in client and server and because there is network
traffic.
Distributed systems with many servers with the same function shouldbe transparent for clients: there should be no need for clients to differentiate between servers. When you type in the URL for Google, forinstance, you should not have to know the exact machine that is accessed (location transparency), the platform of the machine (platform
transparency), the route your request travels and so on. Intermediate
layers may be inserted for specific purposes: caching, security or loadbalancing, for instance.
Sometimes, callbacks are needed for event notification. This can also beseen as a transition to the Peer-to-Peer pattern.

State in the Client-Server pattern

Stateless serverStateful server

Clients and servers are often involved in ‘sessions’. This can be achievedin two different ways:– With a stateless server, the session state is managed by the client. Thisclient state is sent along with each request. In a web application,
the session state may be stored as URL parameters, in hidden form
fields or by using cookies. This is mandatory for the REST architectural style [18] for web applications, which is described in more detailin this unit further down; see also the learning unit on REST.
– With a stateful server, the session state is maintained by the server andis associated with a client ID.
In the Client-Server pattern, the state influences transactions, fault handling and scalability. Transactions should be atomic, leave a consistentstate and be isolated (not affected by other requests) and durable. These
properties are hard to obtain in a distributed world.
With regard to fault handling, a state maintained by the client means,for instance, that everything will be lost when the client fails. A clientmaintained state poses security issues as well, because sensitive data
must be sent to the server with each request. Scalability issues may arise
when you handle the server state in-memory: with many clients using
the server at the same time, many states have to be stored in memory at
the same time as well.

REST architecture
REST stands for Representational State Transfer. A REST architecture isa client-server architecture where clients are separated from servers bya uniform interface, servers offer addressable resources and commu-

45

Open Universiteit

Software Architecture

nication is stateless. A server may be stateful, but in that case, eachserver-state should be addressable (for instance, by a URL). A REST architecture is also a layered system: for a client, it is transparent whether
it is directly connected to a server or through one or more intermediaries.
Web applications with stateless communication follow the rules of thispattern.
MASTER - SLAVE PATTERN

2.3

masterslave 1FIGURE 3.4

Master-Slave patternslave 2slave 3Master-Slave pattern

The Master-Slave pattern (see Figure 3.4) supports fault tolerance andparallel computation. The master component distributes the work among
identical slave components and computes a final result from the results
the slaves return. Figure 3.5 shows a sequence diagram of a master distributing work between slaves.
The Master-Slave pattern is applied, for instance, in process control, in
embedded systems, in large-scale parallel computations and in faulttolerant systems.

masterslave 1slave 2

ClientservicesplitWork

callSlaves

subService
subService

combineResults

FIGURE 3.5

46

Sequence diagram for the Master-Slave pattern

Learning unit 3

Architectural patterns

ExamplesOne application area for the Master-Slave pattern is fault tolerance: themaster delegates the job to be done to several slaves, receives their results and applies a strategy to decide which result to return to the client.
One possible strategy is to choose the result from the first slave that terminates. Another strategy is to choose the result that the majority ofslaves have computed. This is fail-proof as far as the slaves are concerned (the master can provide a valid result as long as not all slaves
fail), but not with respect to the master. Failure of slaves may be detected by the master using time-outs. Failure of the master means thesystem as a whole fails.
Another application area is parallel computing: the master divides acomplex task into a number of identical subtasks. Matrix computation
is an example of this: each row in the product matrix can be computedby a separate slave.
A third application area is that of computational accuracy. The execution of a service is delegated to different slaves, with at least threedifferent implementations. The master waits for the results and thenapplies a strategy for choosing the best result (the average, for instance,or the majority).

Issues in the Master-Slave pattern
Divide-and-conquer

The Master-Slave pattern is an example of the divide-and-conquer principle. In this pattern, the aspect of coordination is separated from theactual work: concerns are separated. The slaves are isolated: there is noshared state. They operate in parallel.
The latency in the master-slave communication can be an issue, forinstance in real-time systems: master and slaves live in different processes.
The pattern can only be applied to a problem that is decomposable.
2.4

PIPE - FILTER PATTERN

SourceFIGURE 3.6

Pipe-Filter pattern

FilterFilterSink

Pipe-Filter pattern

The Pipe-Filter pattern (see Figure 3.6) provides a structure for systems
that produce a stream of data. Each processing step is encapsulated ina filter component (represented by a circle in Figure 3.6). Data is passed
through pipes (represented by the arrows between adjacent filters). The
pipes may be used for buffering or for synchronisation.

47

Open Universiteit

Software Architecture

ExamplesUnix shell commands

Unix shell commands are an example of the Pipe-Filter pattern, such as:
cat file | grep xyz | sort | uniq > out
This pattern divides the task of a system into several sequential processing steps. The steps are connected by the data flow through the system:
the output of one step is the input for the next one. In the example, thecat filter reads the file and passes the contents of the file to the grep
filter. The grep filter selects lines containing xyz and passes these lines
to the sort filter. The sort filter sorts the lines and passes the sortedlines to the uniq filter. The uniq filter removes duplicate lines andpasses the result to out.
A filter consumes and delivers data incrementally (another name forthe same concept is lazily): it produces output as soon as it becomes
available and does not wait until all input is consumed.
Another example of the Pipe-Filter pattern are compilers, where a lexical analyser analyses the source file and sends the resulting tokens toa parser, which sends the resulting parse tree to a semantic analyser,
which produces an augmented syntax tree. That augmented syntax tree
is then used by the code generator to produce code, which may be optimised, and which is ultimately translated into machine code (there may
be more or fewer steps involved).
ASCII program text

Machine code

LexicalanalysisInterpreter

token stream

optimized bytecodeParserOptimization

abstract syntax tree
Semantic
analysis

FIGURE 3.7

augmented syntax tree

bytecode
Code
generation

A compiler

Figure 3.7 shows the components of a compiler. In practice, compilers do not strictly follow the pattern: the steps share global data (thesymbol table).
Issues in the Pipe-Filter pattern
The Pipe-Filter pattern has several useful properties and some disadvantages. It is easy to add new filters: a system built according to the48

Learning unit 3

Architectural patterns

Pipe-Filter pattern is easy to extend. Filters are reusable: it is possible to build different pipelines by recombining a given set of filters.
Because of the standard interface, filters can easily be developed separately, which is another advantage. However, that same interface may
be the cause of overhead because of data transformation: when the input and the output have the form of a string, for instance, and filters
are used to process real numbers, there is a lot of overhead from datatransformation.
Filters do not need to store intermediate results in files and do not needto share state. Input and output can come from or go to different places.
Another advantage of the Pipe-Filter pattern is that it enables natural
concurrent processing, as input and output consist of streams and filters start computing when they receive data. Analysis of the behaviourof a pipe-filter-based system is easy, as it is a simple composition of the
behaviours of the filters involved. When the input is called x, the behaviour of the first filter is described by function g, and the behaviourof the second filter is described by function f, the result of the pipeline
can be described as:f(g(x))
Because of this composition property, it is possible to analyse throughput as well (throughput is determined by the slowest filter), and thepossibility of deadlocks. Deadlocks may occur when at least one of thefilters needs all data before producing output. In such a case, the sizeof the buffer may be too small and the system may deadlock. The Unix
sort filter is an example of such a filter.
A disadvantage of the Pipe-Filter pattern, aside from the potential foroverhead due to data transformation, is that it is hard to use this pattern
for interactive applications.
2.5

Broker pattern

BROKER PATTERN

The Broker pattern is used to structure distributed systems with decoupled components, which interact by remote service invocations. Suchsystems are very inflexible when components have to know each other’slocation and other details (see Figure 3.8). A broker component is responsible for the coordination of communication among components:
it forwards requests and transmits results and exceptions.
Servers publish their capabilities (services and characteristics) to a broker. Clients request a service from the broker, and the broker then redirects the client to a suitable service from its registry.
Using the Broker pattern means that no other component aside fromthe broker needs to focus on low-level inter-process-communication.
Interface Definition Language (IDL)Interface Definition Language

An Interface Definition Language (IDL) is used to give a textual description of the interfaces a server offers. Some examples of IDLs are OMGIDL (Object Management Group, for CORBA ), Open Service Interface

49

Open Universiteit

Software Architecture

Definitions, M icrosoft . NET C IL ( Common I ntermediate L anguage) or
WSDL (Web Service Description Language).
Alternate software may use a binary standard, like Microsoft OLE (Object Linking and Embedding) or Universal Network Objects for the OpenOffice s uite. Such a binary description consists of a table with pointers tomethod implementations. It allows clients to call methods indirectly,
by using those pointers. A binary standard needs support from theprogramming language used.

ExamplesUDDI registry

find
User
application

publishinvoke(SOAP)Web services
host

FIGURE 3.8

Web service
UDDI registry

CORBA

Web services

An example in which the Broker pattern is used is formed by web services. In a web services application, as shown in Figure 3.8, the serverwith the UDDI registry is the Broker. UDDI stands for Universal Discovery, Description and Integration. It is a repository of web services. The
IDL used for web services is WSDL . SOAP (Simple Object Access Protocol) is the transport protocol for messages, written in XML.
Another example of the Broker pattern is CORBA, for cooperation among
heterogeneous object-oriented systems, and web services.
Issues in the Broker pattern
The Broker pattern allows dynamic change, addition, deletion and relocation of objects, and it makes distribution transparent to the developer.
It requires standardisation of service descriptions. When two brokers
cooperate, bridges may be needed to hide implementation details, as in
Figure 3.9:
Broker A receives an incoming request for a certain service. It locatesthe server responsible for executing the specified service by looking it
up in the repositories. Since the corresponding server is available atanother network node, the broker forwards the request to a remote broker. The message is passed from broker A to bridge A. This component
is responsible for converting the message from the protocol defined by50

Learning unit 3

Architectural patterns

Broker A

Bridge A

Bridge B

Broker B

forward request
find server

forward message

pack data

unpack datafind service

Process boundary

FIGURE 3.9

Two brokers cooperating

broker A into a network-specific but common protocol that is understandable to the two participating bridges. After the message has been
converted, bridge A transmits the message to bridge B. Bridge B maps
the incoming request from the network-specific format to a broker Bspecific format. Broker B then performs all the actions necessary whena request arrives, as described in the first step of the scenario.
2.6

PEER - TO - PEER PATTERN

Peer (clientand server)

Peer (clientand server)

FIGURE 3.10

Peer-to-Peer patternPeer-to-Peer pattern

The Peer-to-Peer pattern can be seen as a symmetric Client-server pattern: peers may function both as a client, requesting services from otherpeers, and as a server, providing services to other peers. A peer may act
as a client or as a server or as both, and it may change its role dynamically.
Both clients and servers in the Peer-to-Peer pattern are typically multithreaded. The services may be implicit (by means of of a connecting
stream, for instance) instead of being requested by invocation.
Peers acting as a server may inform peers acting as a client of certain

51

Open Universiteit

Software Architecture

events. Multiple clients may have to be informed, for instance using an
event-bus.

ExamplesThe following are examples of the Peer-to-Peer pattern: the Domain
Name System for the internet, the distributed search engine Sciencenet,
multi-user applications like a drawing board and Peer-to-Peer file-sharing
like Gnutella [60] or BitTorrent.

Issues in the Peer-to-Peer pattern
An advantage of the Peer-to-Peer pattern is that nodes may use thecapacity of the whole, while bringing in only their own capacity. In
other words, there is a low cost of ownership through sharing. Also,administrative overhead is low, because Peer-to-Peer networks are selforganising.
The Peer-to-Peer pattern is scalable and resilient to failure of individual
peers. Also, the configuration o f a s ystem m ay c hange dynamically:
peers may come and go while the system is running.
A disadvantage may be that there is no guarantee about quality of service, as nodes cooperate voluntarily. For the same reason, security isdifficult to g uarantee. Performance grows when the number of participating nodes grows, which also means that it may be low when there
are few nodes.
2.7

EVENT- BUS PATTERN

SourceSourceChannelChannelListener

FIGURE 3.11

Event-Bus pattern
ChannelBus

Listener

Event-Bus pattern

The Event-Bus pattern is a pattern that deals with events. It works asfollows: event sources publish messages to particular channels on an
event bus. Event listeners subscribe to particular channels. Listeners arenotified of messages that are published to a channel to which they havesubscribed.
Generation and notification of messages is asynchronous: an event source
simply generates a message and may then go on doing something else;
it does not wait until all event listeners have received the message.

52

Learning unit 3

Architectural patterns

Channels may be implicit, using the event pattern which is implemented
in the Java event model, for instance. An explicit channel means that asubscriber subscribes directly to a specific named publisher; an implicit
channel means that a subscriber subscribes to a specific named channel(to a particular event type in the Java event model) and does not needto know which producers produce for that channel.

ExamplesEvent bus
codechangedcodechangedEdit tool

FIGURE 3.12

unit testok

project
recompiled

Build tool

Unit test
runnerproject
recompiled

Debug tool

Software development environment

The Event-Bus pattern is used in process monitoring, in trading systems
and in software development environments as shown in Figure 3.12.
Another example is real-time data distribution middleware like OpenSplice [50].

Issues in the Event-Bus pattern
The Event-Bus pattern has the following characteristics. New publishers, subscribers and connections can be added easily, possibly dynamically. Delivery issues are important: for the developer of an event listener, it is important to realise that assumptions about ordering, distribution and timeliness are hard to formulate. Scalability may also be a
problem, as all messages travel through the same event bus: with anincrease in the number of messages, the capacity of the event bus may
turn into a bottleneck.
The Event-Bus pattern also allows several variations. The bus can provide event transformation services, for instance, or the bus can provide
coordination to script specific tasks.
2.8

MODEL - VIEW- CONTROLLER PATTERN

input
eventsController

updatemodel

view control

changenotification

View

query
model

Model

FIGURE 3.13

53

Model-View-Controller

Open Universiteit

Software Architecture

Model-View-Controller pattern

In the Model-View-Controller pattern, or MVC pattern (see Figure 3.13), aninteractive application is divided into three parts: the model contains
the core functionality and data, the view displays the information to theuser (more than one view may be defined) and the controller handles
the input from the user.
The MVC pattern is particularly suitable for multiple graphical user interfaces (GUIs). The model does not depend on the number and kind of
GUI s, so the pattern allows for easy changes to the ‘look and feel’.

Observer pattern

Consistency between model and view is maintained through notification. The MVC pattern often uses the Observer pattern. User input can
invoke a change in the model and a subsequent change in what theview displays, as is shown in the sequence diagram of the MVC pattern
in Figure 3.14.

:Controller:Model:Viewhandle event
update model
notifyupdate view

query model

display

FIGURE 3.14

Sequence diagram of the MVC pattern

ExamplesThe MVC pattern was introduced with the Smalltalk programming language. It was called a paradigm then: the concept of patterns did not
yet exist.
Examples of the MVC pattern are web presentation (see the learning unit
on patterns for enterprise application architecture) and the document
view architecture of Windows applications, which enables users to, forinstance, see Word or PowerPoint documents in different views (thinkof print layout, web layout, overview).

54

Learning unit 3

Architectural patterns

Issues in the MVC pattern
The MVC pattern makes it easy to have multiple views of the samemodel, which can be connected and disconnected at run-time. It is
possible to base an application framework on this pattern. Smalltalk
development environments already did this.
However, the MVC pattern increases complexity. Not all visible elements lend themselves for separation of model, views and control: menus
and simple text elements may be better off without the pattern. Also,
the pattern potentially leads to many unnecessary updates, where oneuser action results in different updates.
View and control are separated, but are very closely related. In practice, they are often put together. Views and controllers are also closely
coupled to the model. In web applications, a change in the model (forinstance, adding an email address to data about persons) will lead toa change in the view and controller as well (the web site will have toshow the property and the possibility to change the property should be
added as well).
2.9Blackboard pattern

BLACKBOARD PATTERN

The Blackboard pattern is useful for problems for which no deterministic
solution strategies are available. Several specialised subsystems assemble their knowledge to build a possibly partial or approximate solution.
All components have access to a shared data store, the blackboard.
Components may produce new data objects that are added to the blackboard. Components look for particular kinds of data on the blackboard
and may find these by pattern matching.
KnowledgeSource
1..*

updateBlackboard()
1..*
1

1

Blackboard

Controlsolutionsloop()
nextSource()

inspect()
update()FIGURE 3.15

Blackboard pattern

ExamplesExamples of problems to which the Blackboard pattern can be usefully
applied are speech recognition, submarine detection and inference ofthe 3D structure of a molecule. Tuple Space systems, like JavaSpaces,
form another example of this pattern.

55

Open Universiteit

Software Architecture

Issues in the Blackboard pattern
Adding new applications is easy. Extending the structure of the data
space is easy as well, but modifying the structure of the data space ishard, as all applications are affected. Furthermore, processes have toagree on the structure of the shared data space. There may be a needfor synchronisation and access control.
2.10

Interpreter pattern

INTERPRETER PATTERN

The Interpreter pattern is used for designing a component that interprets
programs written in a dedicated language. The interpreted program
can be replaced easily.

ExamplesRule-based systems such as expert systems, web scripting languages
such as JavaScript (client-side) or PHP (server-side) and Postscript are
examples of the interpreter pattern.

Issues in the Interpreter pattern
Because an interpreted language is generally slower than a compiled
one, performance may be an issue. Furthermore, the ease with which
an interpreted program may be replaced may cause a lack of testing:stability and security may be at risk as well.
On the other hand, the Interpreter pattern enhances flexibility, because
replacing an interpreted program is indeed easy.
3

KeyWord In Context

Applying patterns: KWIC example

A classic example to illustrate the differences between architectural patterns is the KWIC problem: KeyWord In Context, introduced by Parnas [48]. In this section, we introduce this problem and show how different architectural patterns can be used to solve it [57].
The keyword in context problem takes a list of lines as input; a line iscomposed of words. The output of the solution for the problem shouldbe all ‘circular shifts’ of all lines, sorted. A circular shift is done byrepeatedly removing the last word and appending it at the beginningof the line. For example, with the input:
man eats dog
the output should be:
dog man eats
eats dog man
man eats dog

56

Learning unit 3

3.1

Architectural patterns

SHARED DATA

Main

input
file

outputfile
line-table
Input

FIGURE 3.16

Yourdon structure chartindex
Circular shiftindex-2
Sort

Output

KWIC, the classical solution

Traditionally, the KWIC problem is solved using shared data and functional decomposition. Figure 3.16 is a Yourdon structure chart [65] forthe classical solution to the KWIC problem. The processing elements aresubroutines and the arrows represent invocations. The small arrows
show which data is added to the shared data.
The Main subroutine invokes functions. The first invoked function
reads the input file and adds a table of lines to the shared data. The
second function performs the circular shift and adds the various shifted
lines to the shared data (as a series of indexes to indicate the order). The
third function then sorts all these lines and adds the resulting lines tothe shared data (once again using indexes). The last invoked function
writes the result to an output file.
3.2

LAYERS PATTERN

Main

Input

Circular shift

Input file

Line storage

FIGURE 3.17

Sorted Lines

OutputOutput file

KWIC, Layers pattern

An alternate solution to the KWIC problem uses the Layers pattern. In
Figure 3.17, the elements are objects and the arrows denote method
calls. No data is shared: communication of data happens exclusively
through method calls.
The advantage of this solution is that the data is hidden inside the objects, which means that choices for data structures and algorithms areencapsulated in specific components and may therefore be more easilychanged, by keeping the abstract interfaces as they are.

57

Open Universiteit

Software Architecture

The organisation in layers is based on objects calling methods exclusively from objects in the same layer or in the layer directly beneaththem.
EVENT- BUS

3.3

Bus

Input

Circular shift

SorterInput file

OutputOutput file

FIGURE 3.18

KWIC, Event Bus pattern

Another solution to the KWIC problem uses the Event-Bus architecture.
Components that are interested in certain events are notified when those
events become available. That means that components are called implicitly.
Figure 3.18 is a dataflow diagram [66]. The elements are processes andthe arrows are data in transfer between processes. The shifter will be invoked after the input process has inserted the first line. Data should beshared between the input process and the circular shift and among thecircular shift, the sorter and the output process. The sorter is invokedeach time the circular shifter has inserted a line in their shared data.
This solution does not offer the advantages of data hiding that the previous solution offered, but it can be quicker due to possible parallelism.
However, it is a complicated solution, with two shared data spaces andan event bus.
PIPE - FILTER

3.4

Input

Circular shift

Sort

Input file

FIGURE 3.19

OutputOutput file

KWIC, Pipe-filter pattern

Yet another possible solution to the KWIC problem uses the Pipe-filter
pattern. In this case, a chain of transformers is constructed. For this, weneed a uniform data format.
The same amount of parallelism as was achieved in the Event Bus solution is possible here, in a less complicated system.

58

Learning unit 3

Architectural patterns

The same amount of data hiding as in the layered object-oriented solution is possible here as well, with the only drawback being that there is a
uniform data format for the pipes. This makes the filters easier to workwith. However, when different data structures are chosen inside thefilters, there may be overhead because of translation between different
data structures.
4

Architectural styles

Patterns have all been developed bottom-up: for a given problem, after a certain kind of solution has been used time and time again, thissolution is written down in the form of a pattern.
Architectural styles

Interacting processes

Dataflow style

Data centred style

Hierarchical styleCall and return styleArchitectural styles, on the other hand, have all been formulated topdown: when you see a software system as a configuration of components and connectors, you can classify them according to the nature of
the components and connectors. In general, patterns belong to one ofthese styles.
Mary Shaw and Paul Clements have proposed a classification of styles [56],based on the constituent parts (components and connectors), control issues and data issues. This classification is as follows:– Interacting processes have their own thread of control. Communication
may have the form of asynchronous message passing, implicit invocation through events, or remote procedure calls. When the Event
Bus pattern is implemented with independent processes or with objects with their own thread of control, this pattern is an example ofthis style. The Client-Server pattern and Peer-to-Peer pattern are examples as well.
– In the Dataflow style, data flows from one component to another, in a
stream. The Pipe-filter pattern belongs to this style. Some instances of
the Client-Server pattern also belong to this style, for instance whena client is used to receive and display streaming audio or video sent
by a server.
– The Data centred style involves central storage of data. An exampleof this style is the Blackboard pattern. Again, instances of the ClientServer pattern may belong to this style. For example, if the mainfunction of the server is to manage a database and clients are used toaccess that database.
– In the Hierarchical style, the system is partitioned into subsystems
with limited interaction. Patterns within this style are the Interpreter
pattern and the Layers pattern.
– The Call and return style makes the calling process wait for the returnof request. Patterns within this style are the Master-slave and, again,
the Layers pattern. Object-oriented systems without threads are also
an example of this style.

4.1

CHOOSING A STYLE OR A PATTERN

Which architectural pattern is best for a given situation depends onwhich requirements have the highest priority, such as:– Maintainability: how easy or difficult is it to add an additional pro-

59

Open Universiteit

Software Architecture

cessing component, for instance to filter certain words? How easy
or difficult is it to change the input format, by adding line numbers,
for example? In the Pipe-Filter pattern for instance, adding a filter isvery easy, but changing the input format might be hard.
– Reusability: can individual components be reused in other systems?
In this case, the Pipe-and-Filter pattern enhances reusability becauseof the uniform data format that is used.
– Performance: is the response time small enough? Is overall resource
behaviour (memory usage in this example) acceptable? Patterns thatmake use of parallelism, such as the Pipe-Filter pattern and the EventBus pattern, will have better performance. On the other hand, starting a complex system like the Event Bus system, or transforming
data in every filter using a different data structure, may lower performance.
– Explicitness: is it possible to provide feedback to the user? Per stage?
This is not possible in the Pipe-Filter pattern, for instance.
– Fault tolerance: for the KWIC example, there is no difference between
the different solutions, but fault-tolerance would have been enhanced
if a Master-slave pattern been applied.
The list of requirements and their priorities will vary for every system.
No rigid guidelines are available to tell you which pattern will be thebest in every case. Much also depends on the implementation of thepattern. Independent processes, for example, may be implemented using threads or using processes on different machines. The balance between communication and computation, the capacity of the processors
involved and the speed of communication between machines, among
other things, will decide which implementation will have the best performance.

DISCUSSIONaQUESTIONSIn a previous learning unit, we introduced the name tactic for an
architectural decision that influences the quality of the product. Architectural patterns can be viewed as being constructed from tactics.
Can you give some examples?
b Once a pattern has been used in an architectural design, the reason
for its use may be forgotten, and over time the design may start todiverge from the pattern. Do you think this should be prevented? If
so, how?
c Design patterns often represent crosscutting concerns that can be
implemented using aspect-oriented programming or program transformation techniques. Is the same true of architectural patterns?

60