lecture 5 architectural design & patternscs00pe/epl603/lectures/lect… · ·...

Lecture 5 – Architectural Design & Patterns

EPL603 – Topics in Software Engineering

Efi Papatheocharous Visiting Lecturer [email protected] Office FST-B107, Tel. ext. 2740

mailto:[email protected]

Topics covered

Software architecture

Architectural design

Architectural patterns

Architectural patterns for distributed systems

2 Lecture 5: Architectural Design & Patterns

Software architecture

“The architecture of a software system defines that system in terms of computational components and interactions among those components.”

[Shaw & Garlan, 1996]

“Architecture is the fundamental organization of a system embodied in its components, their relationships to each other and to the environment and the principles guiding its design and evolution.”

[IEEE 1471-2000]

“The software architecture of a system is the structure or structures of the system, which comprise software elements, the externally visible properties of those elements, and the relationships among them. Architecture is concerned with the public side of interfaces; private details of elements—details having to do solely with internal implementation—are not architectural.”

[Bass et al., 2003]

Lecture 5: Architectural Design & Patterns 3

Sources: IEEE Standard on the Recommended Practice for Architectural Descriptions, 2000. Shaw and Garlan, Software Architecture, Perspectives on an Emerging Discipline, Prentice-Hall, 1996 Bass, Clements, and Kazman, Software Architecture in Practice, SEI Series in Software Engineering. Addison-Wesley, 2003.

Importance of architecture

The big problem according to David Garlan


Source: Keynote speech, “The Changing Face of Software Architecture”, CSEET, Carnegie-Mellon (March 2010), Available at: http://www.cs.cmu.edu/~garlan/external%20activities/CSEET%20Keynote.pdf

How to bridge the

gap between

requirements and

solutions?

http://www.cs.cmu.edu/~garlan/external activities/CSEET Keynote.pdf

One possible answer




The process can be:

Ad hoc

Requires gurus

Unpredictable

Costly


The role of software architecture




High level system

design

System-level

abstractions

Architectural reuse

design concepts


System design by decomposition

Design by decomposition starts with a high-level description of the system’s key elements.

Then, iteratively refine the design by dividing each of the system’s elements into its constituent pieces and describing their interfaces.

The process is repeated until further refinement results in pieces that have no interfaces.


Top level

First level of decomposition

Second level of decomposition

Source: Pfleeger, S. L. and Atlee, J. M., Software Engineering, Fourth Edition, Pearson, 2010.

Example of various levels of architectures


High-level architecture of the weather station

Low-level architecture of Data Collection

Source: Sommerville, I., Software Engineering, 9th ed., Addison Wesley, 2010.

Design models

The software requirements model is transformed into design models that describe the details of the data structures, system architecture, interfaces, and components.

Each design product is reviewed for quality before moving to the next phase of software development.


Source: Pressman, R.S., Software Engineering: a Practitioner’s Approach, 5th Rev. Ed., McGraw-Hill, 2000.


In many ways, designing software resembles the process of designing a new house.


Source: Pfleeger, S. L. and Atlee, J. M., Software Engineering, Fourth Edition, Pearson, 2010.

There may not be a single “best” or “correct” architecture and the number of possible solutions may be limitless.

By gleaning ideas from past solutions and by seeking regular feedback from the customer, designers can create good architecture, one that is able to accommodate and adapt to change, that will result to a product satisfying the customer and source of guidance throughout the products’ lifetime.


Software design is a creative activity in which you identify software components and their relationships, based on customers’ requirements.

Customers’ requirements generate a list of services that the customers requires from a system and include constraints under which it should operate.

Software design is based on requirements and specification analysis. It will satisfy the functional and non-functional requirements of the system.

Once interactions between the system and its environment have been understood, you use this information for designing the system architecture.

Architectural design is the first stage in the software design process.


Source:


First you need to identify the major components that make up

the system and their interactions, and then organize the

components using possibly a suitable architectural pattern

(such as a layered or client-server model).

The activities within the process differs radically based on the

type of system being developed, the background and

experience of the system architect and specific system

requirements.

The process of realizing the design as a program (system

implementation) the design may change, thus the

implementation and the design activities are inter-leaved.


Architectural design decisions

Is there a generic application architecture that can be act as a template?

How will the system be distributed?

What architectural patterns or styles are appropriate?

What approach will be used to structure the system?

How will the system be decomposed into modules (subcomponents)?

Which architecture is best for delivering the non-functional requirements in the system?

What control strategy for the components of the system should be used?

How will the architectural design be evaluated?

How should the architecture be documented?


Non-functional requirements and architectures (1/2)


Non-functional req. Explanation

Performance If performance is a critical requirement the architecture should be

designed to localize critical operations and minimize

communication, with using a small number of components

deployed on the same computer (rather than distributed). The

components used should be relatively large, rather than

small, fine-grained component. Also consider run-time system

organization that allows the system to be replicated and

executed on different processors to increase performance.

Security If security is a critical requirement use a layered architecture with

critical assets protected in the inner layers and a high level of

validation applied to those layers.

Safety If safety is a critical requirement all safety-related operations

should be either placed in a single component or in a small

number of components. This reduces the costs and problems

of safety validation and makes it possible to provide related

protection systems that can safely shut down the system in the

event of failure.


Non-functional requirements and architectures (2/2)


Non-functional req. Explanation

Availability If availability is a critical requirement the architecture should

include redundant components, so that it is possible to replace

and update components without stopping the system and

should also include mechanisms for fault tolerance. However,

this architecture potentially minimizes performance.

Maintainability If maintainability is a critical requirement the system architecture

should include fine-grain, self-contained, replaceable

components. Components producing data should be separated

from components consuming data and shared data structures

should be avoided. However, this architecture potentially

minimizes performance.


Architectural patterns

We can improve our design by studying examples of good design. Thus, most design work is routine design, solve problem by reusing and adapting solutions from similar problems.

[Pfleeger & Atlee]

Architectural patterns were firstly introduced in the 90s under the name ‘architectural styles’ (Shaw and Garlan, 1996) and other handbooks were published on pattern-oriented software architectures until 2007.

Architectural patterns are stylized descriptions of good design practice, which have been tried and tested in different environments. They are a means of representing, sharing and reusing knowledge.

They should include information about when they are and when the are not useful.

They may be represented using tabular and graphical descriptions.


Need for architectural patterns

Architectural patterns play the role of a blueprint (template) of a software system.

Also, they play a critical role for the formation of the entire projects’:

Team structure

Documentation organization

Work Breakdown Structure (WBS)

Planning, costing and budgeting

Scheduling and resource allocation

Control and organization of components

Design and plan of implementation

Integration and evolution

Communication mechanisms

Lecture 5: Architectural Design & Patterns 17 Source: Shaw and Garlan, Software Architecture, Perspectives on an Emerging Discipline, Prentice-Hall, 1996

Common architectural patterns (1/2)


Architectural Style Description

Client/Server*

Separates the system into two applications, where the client

makes requests to the server. In many cases, the server is a

database with application logic represented as stored

procedures.

Component-Based

Architecture

Decomposes application design into reusable functional or

logical components that expose well-defined communication

interfaces.

Domain Driven

Design

An object-oriented architectural style focused on modelling a

business domain and defining business objects based on

entities within the business domain.

Layered Architecture* Partitions the concerns of the application into stacked groups

(layers).

Model View

Controller (MVC)* Separates presentation and interaction from the system data.

Common architectural patterns (2/2)


Architectural Style Description

Message Bus

An architecture style that prescribes use of a software system

that can receive and send messages using one or more

communication channels, so that applications can interact

without needing to know specific details about each other.

N-Tier / 3-Tier*

Segregates functionality into separate segments in much the

same way as the layered style, but with each segment being a

tier located on a physically separate computer.

Object-Oriented

A design paradigm based on division of responsibilities for an

application or system into individual reusable and self-sufficient

objects, each containing the data and the behaviour relevant to

the object.

Service-Oriented

Architecture (SOA)*

Refers to applications that expose and consume functionality as

a service using contracts and messages.

Repository* The pattern where all data in a system is managed in a central

repository that is accessible to all system components.

The pipe and filter architecture (1/3)

In the pipe and filter architecture functional transformations process their inputs to produce outputs.

May be referred to as a pipe and filter model (as in UNIX shell).

Variants of this approach are very common. When transformations are sequential, this is a batch sequential model which is extensively used in data processing systems.

Not really suitable for interactive systems.

Lecture 5: Architectural Design & Patterns 20 Source: Sommerville, I., Software Engineering, 9th ed., Addison Wesley, 2010.

The pipe and filter pattern (2/3)


Name Pipe and filter

Description The processing of the data in a system is organized so that each

processing component (filter) is discrete and carries out one type of

data transformation. The data flows (as in a pipe) from one

component to another for processing.

When used Commonly used in data processing applications (both batch- and

transaction-based) where inputs are processed in separate stages

to generate related outputs.

Advantages Easy to understand and supports transformation reuse. Workflow

style matches the structure of many business processes. Evolution by

adding transformations is straightforward. Can be implemented as

either a sequential or concurrent system.

Disadvantages The format for data transfer has to be agreed upon between

communicating transformations. Each transformation must parse its

input and unparse its output to the agreed form. This increases system

overhead and may mean that it is impossible to reuse functional

transformations that use incompatible data structures.


A pipe and filter example

An

example of

a pipe and

filter

system

used for

processing

invoices.


The Model-View-Controller (MVC) pattern (1/3)


Name MVC (Model-View-Controller)

Description The Model-View-Controller pattern separates presentation and interaction

from the system data. The system is structured into three logical

components that interact with each other.

The Model component manages the system data and associated operations

on that data. The View component defines and manages how the data is

presented to the user. The Controller component manages user interaction

(e.g., key presses, mouse clicks, etc.) and passes these interactions to the

View and the Model.

When used Used:

• when there are multiple ways to view and interact with data;

• when the future requirements for interaction and presentation of data are

unknown.

Advantages Allows the data to change independently of its representation and vice versa.

Supports presentation of the same data in different ways with changes made

in one representation shown in all of them.

Disadvantages Can involve additional code and code complexity when the data model and

interactions are simple.


The Model-View-Controller (MVC) (2/3)

24 Lecture 5: Architectural Design & Patterns Source: Sommerville, I., Software Engineering, 9th ed., Addison Wesley, 2010.

A Model-View-Controller (MVC) example

The

architecture of

a web-based

application

system

organized

using the MVC

pattern.


The layered architecture (1/3)

The layered architecture is used to model the interfacing of sub-systems.


Organises the system into a set of layers

(or abstract machines) each of which provide

a set of services.

Supports separation and independence

between layers.

Each layer relies only on the facilities and

services offered by the layer immediately

beneath it.

Supports the incremental development in

different layers of sub-systems, since ready

services may be made available to users.

When a layer interface changes, only the

adjacent layer is affected. Thus, it localizes

dependencies in the inner layers.

The layered pattern (2/3)


Name Layered architecture

Description Organizes the system into layers with related functionality

associated with each layer. A layer provides services to the layer

above it so the lowest-level layers represent core services that are

likely to be used throughout the system.

When used Used :

• when building new facilities on top of existing systems;

• when the development is distributed (spread across several teams

with each team responsibility for a layer of functionality);

• when there is a requirement for multi-level security.

Advantages Allows replacement of entire layers so long as the interface is

maintained. Redundant facilities (e.g., authentication) can be

provided in each layer to increase the dependability of the system.

Disadvantages In practice, providing a clean separation between layers is often

difficult and a high-level layer may have to interact directly with

lower-level layers rather than through the layer immediately below it.

Performance can be a problem because of multiple levels of

interpretation of a service request as it is processed at each layer.


A layered architecture example (3/3)

A layered

model of a

system for

sharing

copyright

documents

held in

different

libraries.


The repository architecture (1/3)

Sub-systems must exchange data. This may be done in two ways:

Each sub-system maintains its own database and passes data explicitly to other sub-systems.

Shared data is held in a central database or repository and may be accessed by all sub-systems;

When large amounts of data are to be shared, the repository model of sharing is most commonly used a this is an efficient data sharing mechanism.


The repository pattern (2/3)


Name Repository

Description All data in a system is managed in a central repository that

is accessible to all system components. Components do

not interact directly, only through the repository.

When used You should use this pattern when you have a system in which

large volumes of information are generated that has to be

stored for a long time. You may also use it in data-driven

systems where the inclusion of data in the repository triggers

an action or tool.

Advantages Components can be independent—they do not need to know

of the existence of other components. Changes made by one

component can be propagated to all components.

All data can be managed consistently (e.g., backups done at

the same time) as it is all in one place.

Disadvantages The repository is a single point of failure so problems in the

repository affect the whole system. May be inefficiencies in

organizing all communication through the repository.

Distributing the repository across several computers may be

difficult.

A repository architecture example (3/3)


A repository

architecture model of

an IDE

The components use a

repository of system

design information.

Each software tool

generates information

which is then available

for use by other tools.


The client-server architecture (1/3)

The Client-Server (C/S) architecture is a distributed system model which shows how data and processing is distributed across a range of components.

It can be implemented on a single computer. It depends on there being a clear separation between the

presentation of information and the computations that create and process that information.

In a client-server system

The user can interact with a program running on their local computer (e.g. a web browser or phone-based application). This interacts with another program running on a remote computer (e.g. a web server).

The remote computer provides services, such as access to web pages, which are available to external clients.



The client-server pattern (2/3)


Name Client-server

Description In a client–server architecture, the functionality of the system is

organized into services, with each service delivered from a

separate server. Clients are users of these services and access

servers to make use of them.

When used Used when data in a shared database has to be accessed from

a range of locations. Because servers can be replicated, it may

also be used when the load on a system is variable.

Advantages The principal advantage of this model is that servers can be

distributed across a network. General functionality (e.g., a

printing service) can be available to all clients and does not need

to be implemented by all services.

Disadvantages Each service is a single point of failure so susceptible to denial of

service attacks (DoS attacks) or server failure. Performance may

be unpredictable because it depends on the network as well as

the system. May be management problems if servers are owned by

different organizations.


A client-server example (3/3)

A film and

video/DVD

library

organized as a

client–server

system.


Client–server computing and interaction


Distributed systems that are accessed over the Internet

are normally organized as client-server systems.

Mapping of clients and servers to networked

computers


Layered client–server computing

Layered architectural

model for client–server

applications

May be structured

into layers.

With the

presentation layer

implemented on a

client computer.

Servers provide

data management,

application and db

services.


C

S

The master-slave architecture (1/2)

Master-slave architectures are commonly used in real-

time systems where there may be separate

processors associated with data acquisition from the

system’s environment, data processing and computation

and actuator management.

The ‘master’ process is usually responsible for

computation, coordination and communications

and it controls the ‘slave’ processes.

‘Slave’ processes are dedicated to specific actions,

such as the acquisition of data from an array of

sensors.


A master-slave architecture example (2/2)


A traffic management system example with master-slave

architecture.

Two-tier client server architectures (1/4)

In a two-tier client-server architecture, the system is

implemented as a single logical server (to centralize

the system for security reasons) plus an indefinite

number of clients that use that server.

Thin-client model

• where the presentation layer is implemented on the

client and all other layers (data management,

application processing and database) are implemented

on a server.

Fat-client model

• where some or all of the application processing is

carried out on the client. Data management and

database functions are implemented on the server.


Thin- and fat-client architectural models (2/4)


Thin-client model (3/4)

The thin-client model is used when legacy systems are migrated to

client-server architectures.

The legacy system acts as a server in its own right with a

graphical interface implemented on a client.

A major disadvantage is that it places a heavy processing load on

both the server and the network.


Fat-client model (4/4)

More processing is delegated to the client as the application processing is locally executed.

Most suitable for new C/S systems where the capabilities of the client system are known in advance.

Disadvantages include that it is more complex than a thin-client model especially for management and that new versions of the application have to be installed on all clients.


An ATM system

example with a

fat-client

architecture.


Multi-tier client-server architectures (1/2)

In a ‘multi-tier client–server’ architecture, there is a high volume of transactions to be processed by the server and there are different layers of the system.

Namely the different layers are:

• Presentation,

• Data Management,

• Application Processing, and

• Database.

They are separate processes that may be executed on different processors.

This avoids problems with scalability and performance if a thin-client two-tier model is chosen, or problems of system management if a fat-client model is used.


A multi-tier client-server architecture example (2/2)


A three-tier

architecture for

an internet

banking

system.

Use of client–server architectural patterns


Architecture Applications

Two-tier C/S

architecture

with thin

clients

• Legacy system applications that are used when separating application

processing and data management is impractical. Thus, the thin-clients may

access these as services.

• Computationally intensive applications such as compilers with little or

no data management.

• Data-intensive applications (browsing and querying) with nonintensive

application processing. Browsing the Web is the most common example of

a situation where this architecture is used.

Two-tier C/S

architecture

with fat clients

• Applications where application processing is provided by COTS

software (e.g., Microsoft Excel) on the client.

• Applications where computationally intensive processing of data

(e.g., data visualization) is required on the client.

• Mobile applications where internet connectivity cannot be guaranteed.

Some local processing using cached information from the database is

therefore possible.

Multi-tier C/S

architecture

• Large-scale applications with hundreds or thousands of clients.

• Applications where both the data and the application are volatile.

• Applications where data from multiple sources are integrated.

Distributed component architectures (1/3)

In distributed component architectures there is no distinction between clients and servers. Different systems and databases need to be combined.

Each distributable entity is an object that provides services to other components and receives services from other components.

Component communication is through a middleware system.

However, distributed component architectures are more complex to design than C/S systems.





A distributed

component

architecture

for a data

mining

system


Distributed component architectures suffer from two

major disadvantages:

They are more complex to design than client–server systems.

Distributed component architectures are difficult for people to

visualize and understand.

There is not one standardized middleware for distributed

component systems accepted by the community. Different

vendors, such as Microsoft and Sun, have developed different,

incompatible middleware.

As a result of these problems, service-oriented

architectures are replacing distributed component

architectures in many situations.


Peer-to-peer (P2P) architectures (1/2)

Peer to peer (P2P) systems are decentralised systems where computations may be carried out by any node in the network. They are used when clients exchange locally stored information to each other.

The overall system is designed to take advantage of the computational power and storage of a large number of networked computers. Focus here on network architectures.

Most P2P systems have been personal systems but there is increasing business use of this technology.

The logical network architecture

Decentralised architectures;

Semi-centralised architectures.

The application architecture

The generic organization of components making up a P2P application.


P2P architectural models (2/2)

Decentralised architectures Semi-centralised architectures


Software as a service

Software as a Service (SaaS) involves hosting the software remotely and providing access to it over the Internet.

Software is deployed on a server (or more commonly a number of servers) and is accessed through a web browser. It is not deployed on a local PC.

The server(s) maintain the user’s data and state during an interaction session. Transactions are usually long transactions e.g. editing a document.

The software is owned and managed by a software provider, rather than the organizations using the software.

Users may pay for the software according to the amount of use they make of it or through an annual or monthly subscription. Sometimes, the software is free for anyone to use but users must then agree to accept advertisements, which fund the software service.


SaaS and SOA

Service-Oriented Architecture (SOA) is an approach to structuring a software system as a set of separate, stateless services.

These may be provided by multiple providers and may be distributed. Typically, transactions are short transactions where a service is called, does something then returns a result.


Factors Questions

Configurability • How do you configure the software for the specific requirements of each organization?

Multi-tenancy • How do you present each user of the software with the impression that they are working with their own copy of the system while, at the same time, making efficient use of system resources?

Scalability • How do you design the system so that it can be scaled to accommodate an unpredictably large number of users?

Configuration of a software system offered as a service


Configuration options

Configuration facilities may allow for the following:

Branding

• Users from each organization are presented with an interface that

reflects their own organization.

Business rules and workflows

• Each organization defines its own rules that govern the use of the

service and its data.

Database extensions

• Each organization defines how the generic service data model is

extended to meet its specific needs.

Access control

• Service customers create individual accounts for their staff and

define the resources and functions that are accessible to each of

their users.


Key points (1/2)

A software architecture is a description of how a software system is

organized.

Architectural design decisions include decisions on the type of

application, the distribution of the system, the architectural styles to be

used.

Architectural patterns are a means of reusing knowledge about

generic system architectures. They describe the architecture, explain

when it may be used and describe its advantages and disadvantages.

Common architectural patterns include the pipe and filter pattern,

Model-View-Controller (MVC) pattern, layered and repository

patterns.


Key points (2/2)

Architectural patterns for distributed systems include master-

slave architectures, two-tier and multi-tier client-server architectures,

distributed component architectures and peer-to-peer (P2P)

architectures.

Distributed component systems require middleware to

handle component communications and to allow components to

be added to and removed from the system.

Peer-to-peer architectures are decentralized with no

distinguished clients and servers. Computations can be

distributed over many systems in different organizations.

Software as a service is a way of deploying applications as thin

client- server systems, where the client is a web browser.


Readings

Chapters 6, 7 & 18 - Sommerville, I., Software Engineering, 9th ed., Addison Wesley, 2010.

Chapter 5 & Section 6.5 - Pfleeger, S. L. and Atlee, J. M., Software Engineering, Fourth Edition, Pearson, 2010.

Shaw and Garlan, Software Architecture, Perspectives on an Emerging Discipline, Prentice-Hall, 1996.


Credits

Slides adapted from Ian Sommerville Software Engineering, 9/E

(http://www.cs.st-andrews.ac.uk/~ifs/Books/SE9/).

http://www.cs.st-andrews.ac.uk/~ifs/Books/SE9/



lecture 5 architectural design & patternscs00pe/epl603/lectures/lect… · ·...

Documents