Lecture 5 Architectural Design & Patternscs00pe/epl603/lectures/Lect… · · 2012-10-02Lecture 5...
Transcript of Lecture 5 Architectural Design & Patternscs00pe/epl603/lectures/Lect… · · 2012-10-02Lecture 5...
Lecture 5 – Architectural Design & Patterns
EPL603 – Topics in Software Engineering
Efi Papatheocharous Visiting Lecturer [email protected] Office FST-B107, Tel. ext. 2740
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
Lecture 5: Architectural Design & Patterns 4
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?
One possible answer
The big problem according to David Garlan
Lecture 5: Architectural Design & Patterns 5
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
The process can be:
Ad hoc
Requires gurus
Unpredictable
Costly
The role of software architecture
The big problem according to David Garlan
Lecture 5: Architectural Design & Patterns 6
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
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.
Lecture 5: Architectural Design & Patterns 7
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
8 Lecture 5: Architectural Design & Patterns
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.
Lecture 5: Architectural Design & Patterns 9
Source: Pressman, R.S., Software Engineering: a Practitioner’s Approach, 5th Rev. Ed., McGraw-Hill, 2000.
Architectural design
In many ways, designing software resembles the process of designing a new house.
Lecture 5: Architectural Design & Patterns 10
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.
Architectural design
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.
11 Lecture 5: Architectural Design & Patterns
Source:
Architectural design
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.
12 Lecture 5: Architectural Design & Patterns
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?
Lecture 5: Architectural Design & Patterns 13
Non-functional requirements and architectures (1/2)
Lecture 5: Architectural Design & Patterns 14
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.
Source: Sommerville, I., Software Engineering, 9th ed., Addison Wesley, 2010.
Non-functional requirements and architectures (2/2)
Lecture 5: Architectural Design & Patterns 15
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.
Source: Sommerville, I., Software Engineering, 9th ed., Addison Wesley, 2010.
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.
Lecture 5: Architectural Design & Patterns 16
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)
Lecture 5: Architectural Design & Patterns 18
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)
Lecture 5: Architectural Design & Patterns 19
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)
Lecture 5: Architectural Design & Patterns 21
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.
Source: Sommerville, I., Software Engineering, 9th ed., Addison Wesley, 2010.
A pipe and filter example
An
example of
a pipe and
filter
system
used for
processing
invoices.
Lecture 5: Architectural Design & Patterns 22 Source: Sommerville, I., Software Engineering, 9th ed., Addison Wesley, 2010.
The Model-View-Controller (MVC) pattern (1/3)
Lecture 5: Architectural Design & Patterns 23
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.
Source: Sommerville, I., Software Engineering, 9th ed., Addison Wesley, 2010.
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.
Lecture 5: Architectural Design & Patterns 25 Source: Sommerville, I., Software Engineering, 9th ed., Addison Wesley, 2010.
The layered architecture (1/3)
The layered architecture is used to model the interfacing of sub-systems.
Lecture 5: Architectural Design & Patterns 26 Source: Sommerville, I., Software Engineering, 9th ed., Addison Wesley, 2010.
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)
Lecture 5: Architectural Design & Patterns 27
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.
Source: Sommerville, I., Software Engineering, 9th ed., Addison Wesley, 2010.
A layered architecture example (3/3)
A layered
model of a
system for
sharing
copyright
documents
held in
different
libraries.
Lecture 5: Architectural Design & Patterns 28 Source: Sommerville, I., Software Engineering, 9th ed., Addison Wesley, 2010.
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.
Lecture 5: Architectural Design & Patterns 29
The repository pattern (2/3)
Lecture 5: Architectural Design & Patterns 30
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)
Lecture 5: Architectural Design & Patterns 31
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.
Source: Sommerville, I., Software Engineering, 9th ed., Addison Wesley, 2010.
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.
Lecture 5: Architectural Design & Patterns 32
Source: Sommerville, I., Software Engineering, 9th ed., Addison Wesley, 2010.
The client-server pattern (2/3)
Lecture 5: Architectural Design & Patterns 33
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.
Source: Sommerville, I., Software Engineering, 9th ed., Addison Wesley, 2010.
A client-server example (3/3)
A film and
video/DVD
library
organized as a
client–server
system.
Lecture 5: Architectural Design & Patterns 34 Source: Sommerville, I., Software Engineering, 9th ed., Addison Wesley, 2010.
Client–server computing and interaction
Lecture 5: Architectural Design & Patterns 35 Source: Sommerville, I., Software Engineering, 9th ed., Addison Wesley, 2010.
Distributed systems that are accessed over the Internet
are normally organized as client-server systems.
Mapping of clients and servers to networked
computers
Lecture 5: Architectural Design & Patterns 36 Source: Sommerville, I., Software Engineering, 9th ed., Addison Wesley, 2010.
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.
Lecture 5: Architectural Design & Patterns 37 Source: Sommerville, I., Software Engineering, 9th ed., Addison Wesley, 2010.
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.
Lecture 5: Architectural Design & Patterns 38
A master-slave architecture example (2/2)
Lecture 5: Architectural Design & Patterns 39 Source: Sommerville, I., Software Engineering, 9th ed., Addison Wesley, 2010.
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.
Lecture 5: Architectural Design & Patterns 40
Thin- and fat-client architectural models (2/4)
Lecture 5: Architectural Design & Patterns 41 Source: Sommerville, I., Software Engineering, 9th ed., Addison Wesley, 2010.
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.
Lecture 5: Architectural Design & Patterns 42
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.
Lecture 5: Architectural Design & Patterns 43
An ATM system
example with a
fat-client
architecture.
Source: Sommerville, I., Software Engineering, 9th ed., Addison Wesley, 2010.
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.
Lecture 5: Architectural Design & Patterns 44
A multi-tier client-server architecture example (2/2)
Lecture 5: Architectural Design & Patterns 45 Source: Sommerville, I., Software Engineering, 9th ed., Addison Wesley, 2010.
A three-tier
architecture for
an internet
banking
system.
Use of client–server architectural patterns
Lecture 5: Architectural Design & Patterns 46
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.
47 Lecture 5: Architectural Design & Patterns
Source: Sommerville, I., Software Engineering, 9th ed., Addison Wesley, 2010.
Distributed component architectures (2/3)
48 Lecture 5: Architectural Design & Patterns Source: Sommerville, I., Software Engineering, 9th ed., Addison Wesley, 2010.
A distributed
component
architecture
for a data
mining
system
Distributed component architectures (3/3)
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.
Lecture 5: Architectural Design & Patterns 49
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.
50 Lecture 5: Architectural Design & Patterns
P2P architectural models (2/2)
Decentralised architectures Semi-centralised architectures
Lecture 5: Architectural Design & Patterns 51 Source: Sommerville, I., Software Engineering, 9th ed., Addison Wesley, 2010.
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.
52 Lecture 5: Architectural Design & Patterns
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.
Lecture 5: Architectural Design & Patterns 53
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
54 Lecture 5: Architectural Design & Patterns Source: Sommerville, I., Software Engineering, 9th ed., Addison Wesley, 2010.
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.
Lecture 5: Architectural Design & Patterns 55
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.
56 Lecture 5: Architectural Design & 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.
Lecture 5: Architectural Design & Patterns 57
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.
Lecture 5: Architectural Design & Patterns 58
Credits
Slides adapted from Ian Sommerville Software Engineering, 9/E
(http://www.cs.st-andrews.ac.uk/~ifs/Books/SE9/).