© lethbridge/laganière 2001 chapter 9: architecting and designing software1 architectural patterns

© Lethbridge/Laganière 2001 Chapter 9: Architecting and designing software 1

Architectural Patterns


9.5 Architectural Patterns

The notion of patterns can be applied to software architecture.

The notion of an architectural pattern is essential to good architectural design.

• These are called architectural patterns or architectural styles.

• Each allows you to design flexible systems using components

—The components are as independent of each other as possible.

• Some architectural patterns are better for certain kinds of applications than others.


1. The Multi-Layer architectural pattern

In a layered system, each layer communicates only with the layer immediately below it. This is the classical approach.

• Each layer has a well-defined interface used by the layer immediately above.

• Recall layer cohesion – not one of the types of cohesion from years past.

—The higher layer sees the lower layer as a set of services.

—Often, a layer communicates ONLY with the layer below it – not always, but frequently.

—Services provided by layers are defined by a well-defined API.


• A complex system can be built by superposing layers at increasing levels of abstraction.

—It is important to have a separate layer for the UI.

—Layers immediately below the UI layer provide the application functions determined by the use-cases.

—Bottom layers provide general services.- e.g. network communication, database access

—Nice thing about layers, they can be replaced without impacting other layers (if the interface remains unchanged). E.g. User Interface layer when porting to a different platform or for different environments.


Example of multi-layer systems

Screen display facilities

User account management

File system

Kernel (handling processes and swapping)

Application programs

User interface

Application logic

Database access

Network communication

Transmitting and receiving

Dealing with packets

Dealing with connections

Dealing with application protocols

a) Typical layers in an application program

b) Typical layers in an operating system

c) Simplified view of layers in a communication system

Operating system access


User interface

Application logic

Database access

Network communication

a) Typical layers in an application program

Operating system access

Communications between layers: often by procedure calls• Can also be done by inter-process communications, such that the upper layers become clients; lower layers become servers.

This will illustrate how the multi-layer and the client-server architectural patterns can be usedtogether. More ahead on this ahead.

Note: we are not necessarily addressing a distributed application – only architectural layers in general for an application – in general.

.


The multi-layer architecture and design principles (how this architecture satisfies the eleven architectural design principles)*

1. Divide and conquer: The layers can be independently designed.

2. Increase cohesion: Well-designed layers have layer cohesion.

3. Reduce coupling: Well-designed lower layers do not know about the higher layers and the only connection between layers is through the API.

4. Increase abstraction: you do not need to know the details of how the lower layers are implemented.

5. Increase reusability: The lower layers can often be designed generically. (e.g. those that handle database access, persistency, etc.)


The multi-layer architecture and design principles*

6. Increase reuse: You can often reuse layers built by others that provide the services you need.

7. Increase flexibility: you can add new facilities built on lower-level services, or replace higher-level layers.

8. Anticipate obsolescence: By isolating components in separate layers, the system becomes more resistant to obsolescence.

9. Design for portability: All the dependent facilities can be isolated in one of the lower layers.

As we know, some things tend to change over time; more than some other aspects of an application.

10. Design for testability: Layers can be tested independently.

11. Design defensively: The APIs of layers are natural places to build in rigorous assertion-checking.


2. The Client-Server and other distributedarchitectural patterns*

• There is at least one component that has the role of server, waiting for and then handling connections.

• There is at least one component that has the role of client, initiating connections in order to obtain some service.

• The three-tier model for web-based client-sever applications is very popular.

—In this approach, the server is ‘in the middle’ serving as a server to a client (web-based or not; likely communicating via the Internet) and acting as a client to a database server (usually via an intranet)


The Client-Server and other distributed architectural patterns*

• A further extension is the Peer-to-Peer pattern.—A system composed of various software components

that are distributed over several hosts.—Hosts act as both clients and servers (to each other)—Any two components can set up a communications

channel through which communications is accomplished.

—Oftentimes, however, peers need to be able to find/locate each other; for this, oftentimes, a server containing location information is needed.

—(You have seen this when accessing a site to download – and a number of URLs of other sites are provided any one of which contains the software to download…)


An example of a distributed system

Client2:

Server:

Client1:

Client3:

<<communication>>look up addresses<<communication>>

exchange messages

<<communication>>exchange messages <<communication>>

exchange messages

<<communication>>look up addresses


The distributed architecture and some of the eleven architectural design principles

1. Divide and conquer: Dividing the system into client and server processes is a strong way to divide the system.

—Each can be separately developed.

2. Increase cohesion: The server can provide a cohesive service to clients.

3. Reduce coupling: There is usually only one communication channel exchanging simple messages.

4. Increase abstraction: Separate distributed components are often good abstractions.

6. Increase reuse: It is often possible to find suitable frameworks on which to build good distributed systems

—However, client-server systems are often very application specific.


The distributed architecture and design principles

7. Design for flexibility: Distributed systems can often be easily reconfigured by adding extra servers or clients.

9. Design for portability: You can write clients for new platforms without having to port the server.

10 Design for testability: You can test clients and servers independently.

11. Design defensively: You can put rigorous checks in the message handling code.


3. The Broker architectural pattern*

• Transparently distribute aspects of the software system to different nodes

—An object can call methods of another object without knowing that this object is remotely located.

— A proxy design pattern can be used such that a proxy object calls the broker, which determines where the desired object is located.

—Client does not ‘care’ where the remote object is.

—CORBA is a well-known open standard that allows you to build this kind of architecture. (Microsoft has its own architecture: COM)


Example of a Broker system

Client Brokerobject request

ProxyRemote Object

Note that all these architectural patterns are illustrated using ‘components.’


The broker architecture and design principles

1. Divide and conquer: The remote objects can be independently designed.

5. Increase reusability: It is often possible to design the remote objects so that other systems can use them too.

6. Increase reuse: You may be able to reuse remote objects that others have created.

7. Design for flexibility: The brokers can be updated as required, or the proxy can communicate with a different remote object.

9. Design for portability: You can write clients for new platforms while still accessing brokers and remote objects on other platforms.

11. Design defensively: You can provide careful assertion checking in the remote objects.


4. The Transaction-Processing architecturalpattern*

A process reads a series of inputs one by one.

• Each input describes a transaction – a command that typically some change to the data stored by the system

• Normally transactions come in one-by-one.

• There is a transaction handler component that decides what to do with each transaction

• This dispatches a procedure call or message to a component that will handle the transaction

• Numerous examples in daily life

—Inventory- Add items, delete items, update items, reorder items….can all be

realized via transactions.

—Using polymorphic methods, we can design for ‘implicit’ transaction processing rather than explicit transaction processing.


Transaction Dispatchers

• Usually handled nicely in a server that is a transaction ‘dispatcher.’• Transaction dispatcher then sends appropriate messages to the methods to carry out the transactions.• Can be very complex and are almost always ‘atomic.’

• In a threaded environment, where many transactions may be ‘in process,’ data to be modified must be locked and released as appropriate. Additional complexity.• Particularly complicated when an application needs to perform a query prior to an update transaction all the while ensuring that the data is not changed…• See database books on the details.


Example of a transaction-processing system

Transactioninput

Transactiondispatcher

transactions

Handler forReservationtransaction

Handler forFlight cancellationtransaction

...


The transaction-processing architecture and design principles (as usual, these are very good..)

1. Divide and conquer: The transaction handlers are suitable system divisions that you can give to separate software engineers.

2. Increase cohesion: Transaction handlers are naturally cohesive units.

3. Reduce coupling: Separating the dispatcher from the handlers tends to reduce coupling.

7. Design for flexibility: You can readily add new transaction handlers.

11. Design defensively: You can add assertion checking in each transaction handler and/or in the dispatcher.


5. The Pipe-and-Filter architectural pattern

A stream of data, in a relatively simple format, is passed through a series of processes

• Each of which transforms it in some way. • Data is constantly fed into the pipeline.• The processes work concurrently.

—Constant stream of data in and coming out…• The architecture is very flexible.

—Almost all the components could be removed.—Components could be added, changed, deleted, reordered…

• Very flexible particularly (for example) as in converting some characters to other characters (upper case to lower case), filtering out (removing) characters or ‘features’, etc.

• Sometimes the data might undergo a series of transformations…• Can also split pipelines or join pipelines together.• Consider:


Example of a pipe-and-filter system

encoders formicrophone input

encoder forambient

noise

cancelnoise

equalizedynamic

range

removenon-voice

frequenciescompress transmit

receivedecompressencodespeakeroutput

microphonesnearsound

source

distantmicrophone

cancelecho

TCP/IP Transmission

One pipe starts here…

Another pipeline starts here…

Pipelines join here

Think in terms of manufacturing processes, process control applications, or a GPS system; Used frequently in scientific/engineering systems than in information systems applications.

Note the concurrency…


The pipe-and-filter architecture and design principles – lots of flexibility, and fulfills:

1. Divide and conquer: The separate processes can be independently designed.

2. Increase cohesion: The processes have functional cohesion. (single input; single output; no side effects…)

3. Reduce coupling: The processes have only one input and one output.

4. Increase abstraction: The pipeline components are often good abstractions, hiding their internal details.

5. Increase reusability: The processes can often be used in many different contexts.

6. Increase reuse: It is often possible to find reusable components to insert into a pipeline.


The pipe-and-filter architecture and design principles

7. Design for flexibility: There are several ways in which the system is flexible.

10. Design for testability: It is normally easy to test the individual processes.

11. Design defensively: You rigorously check the inputs of each component, or else you can use design by contract.


6. The Model-View-Controller (MVC)architectural pattern*An architectural pattern used to help separate the

user interface layer from other parts of the system A great help to enforce layer cohesion, as the interface is quite

cohesive and reduces coupling between the UI layer and the rest

of the system.

THE MVC pattern separates the functional layer (the model – the business entities, those ‘key abstractions,’ …) from the user interface (view) and the controller.

The model consists of the underlying classes whose instances are to be viewed and manipulated.


MVC Architectural Pattern

• The model contains the underlying classes whose instances (objects) are to be viewed and manipulated

• The view contains objects used to render the appearance of the data from the model in the user interface and the controls with which an actor can interact.

• The controller contains the objects that control and handle the user’s interaction with the view and the model. It contains the business logic…and response to events.

• The Observable design pattern is normally used to separate the model from the view (later)


Example of the MVC architecture for the UI

Controller

View

Model

notify aboutchanges

create and update

modify

viewedby actor

receivesactor events

MVC exhibits layer cohesion, as the model has no idea what view and controller are attached to it (doesn’t care!). The view, business services, and model will reside

at different architectural layers.

There may be special cases when no controller component is created, but the separation of the model from the view is still essential.


The MVC architecture and design principles

1. Divide and conquer: The three components can be somewhat independently designed.

2. Increase cohesion: The components have stronger layer cohesion than if the view and controller were together in a single UI layer.

3. Reduce coupling: The communication channels between the three components are minimal.

6. Increase reuse: The view and controller normally make extensive use of reusable components for various kinds of UI controls.

7. Design for flexibility: It is usually quite easy to change the UI by changing the view, the controller, or both.

10. Design for testability: You can test the application separately from the UI.


MVC in Java (quoting directly from text)

“Several of the Swing GUI components of the Java API are based on the MVC architectural pattern. For example, JList (the view) is a graphical component used to visualize a list of items. This list is the visual representation of data handled by an AbstractListModel (the model).

It contains the data and notifies the JList whenever a change is made to the data by the application.

These two classes follow the Observer pattern; the JList registers itself as an observer of the AbstractListModel instance as follows: (Note that in the Java API, observers are usually called listeners).

listModel.addListDataListener(jList)

Finally, each time a modification is made to the list, the method fireIntervalAdded or fireIntervalRemoved is called by the controller.”


Layers

Data from IBM-Rational and Craig Larman…

© lethbridge/laganière 2001 chapter 9: architecting and designing software1 architectural patterns

Documents

architectural layers

ui layer

layer cohesion

separate layer

higher layer

user interface layer

superposing layers

upper layers