Chapter 6

Architectural
Design

CSC3324
Dr Houda CHAKIRI

Copyright © 2016, 2011, 2006 Pearson Education, Inc. All Rights Reserved
 Learning Objectives

• Architectural design decisions

• Architectural views
• Architectural patterns
• Application architectures
 Software Architecture

To create a reliable, secure and

efficient product, you need to pay
attention to architectural design
which includes:
• The overall organization,
• How the software is
decomposed into
components,
• The server organization
• The technologies that you use
to build the software.

3
The IEEE definition of software
architecture

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

4
 Architectural Design

Architectural design is
concerned with understanding
how a software system should be
organized and designing the
overall structure of that system.

The Architecture of a Packing

Robot Control System
Architectural
Design
• Architectural design is the critical link
between design and requirements
engineering, as it identifies the main
structural components in a system and
the relationships between them.

• The output of the architectural design

process is an architectural model that
describes how the system is organized as
a set of communicating components.
Architectural
Design
Process
 Software Architecture Document

Product Overview—Product vision, stakeholders, target

market, etc.
Architectural Models—Specification using various models,
both static and dynamic.
Mapping Between Models—Tables and text relating models
Architectural Design Rationale— Explanation of difficult,
crucial, puzzling, and hard-to-change design decisions
 Architectural
Abstraction

• Architecture in the small is concerned with the architecture of

individual programs. At this level, we are concerned with the way
that an individual program is decomposed into components.

• Architecture in the large is concerned with the architecture of

complex enterprise systems that include other systems,
programs, and program components. These enterprise systems
are distributed over different computers, which may be owned
and managed by different companies.
 Advantages of Explicit Architecture

• Stakeholder communication
• Architecture may be used as a focus of discussion by
system stakeholders.
• System analysis
• Means that analysis of whether the system can meet its
non-functional requirements is possible.
• Large-scale reuse
• The architecture may be reusable across a range of systems
• Product-line architectures may be developed.
Notations for Architectural Specifications
 •C1: Order Processing System
Architectural •C1 : Product Catalog
•C2 : Online Store •C2: Payment Gateway
complexity

• Complexity in a
system architecture
arises because of the
•C1: Customer
number and the Profile
nature of the Management
relationships •C2: Order
between History

components in that
system. Examples of
•C1: Inventory Management
component •C2: Order Management
relationships:

12
Architectural Modeling Notations

Several notations for architectural modeling:

• Box-and-line diagrams
• UML component diagrams
• UML package diagrams
• UML deployment diagrams
 Box and Line
Diagrams

• Very abstract - they do

not show the nature of
component
relationships nor the
externally visible
properties of the sub- • Icons (boxes) connected with
systems. lines
• However, useful for • No rules governing formation
communication with • Used for both static and dynamic
stakeholders and for Modeling
project planning. • Good idea to include a legend
Box-and-Line
Diagram
Example
1. Make box-and-line diagrams only
when no standard notation is
adequate.
2. Keep the boxes and lines simple.
3. Make symbols for different things
look different.
4. Use symbols consistently in different
diagrams.
5. Use grammatical conventions to
name elements (noun phrases for
things and verb phrases for actions)
 Component diagrams (UML)
A Component-Based Diagram, is
a type of structural diagram in the
Unified Modeling Language
(UML) that visualizes the
organization and
interrelationships of the
components within a system.

Components are modular parts of a system that encapsulate

implementation and expose a set of interfaces. These diagrams
illustrate how components are wired together to form larger systems,
detailing their dependencies and interactions.
Component-Based Diagrams are widely used in system design to
promote modularity, enhance understanding of system architecture.
Component-Based
Diagram Elements
• Components
• Interfaces
• Relationships
• Ports
• Artifacts
• Nodes
Steps to Create a Component-
Based Diagrams
1. Identify the System Scope and Requirements
2. Identify and Define Components
3. Identify Provided and Required Interfaces
4. Identify Relationships and Dependencies
5. Identify Artifacts
6. Identify Nodes
7. Draw the Diagram
Architectural
Design
Decisions

Architectural
design is a
creative
process so the
process differs
depending on
the type of
system being
developed.
However, a number of common decisions span all design processes
and these decisions affect the non-functional characteristics of the
system.
Architecture Reuse

• Systems in the same domain often have similar

architectures that reflect domain concepts.
• Application product lines are built around a core
architecture with variants that satisfy particular customer
requirements.
• The architecture of a system may be designed around one of
more architectural patterns or ‘styles’.
• These capture the essence of an architecture and can
be instantiated in different ways.
Why Architecture is important?
Architecture is important because the architecture of a
system has a fundamental influence on its non-functional
properties.

• Performance: Localize critical operations and minimize

communications. Use large rather than fine-grain components.
• Security: Use a layered architecture with critical assets in the
inner layers.
• Safety: Localise safety-critical features in a small number of sub-
systems.
• Availability: Include redundant components and mechanisms for
fault tolerance.
• Maintainability: Use fine-grain, replaceable components.
Issues that influence
architectural
decisions

22
 • Nonfunctional product characteristics:
• Security and performance affect all
users. If you get these wrong, your
product is unlikely to be a commercial
success. Some characteristics are
contradictory, so you can only optimize
The the most important.
importance of
architectural
design issues

23
 • Product lifetime:
• If you anticipate a long product lifetime,
you will need to create regular product
revisions. You therefore need an
architecture that is evolutive, so that it
can be adapted to accommodate new
The features and technology.
importance of
architectural
design issues

24
 • Software reuse:
• You can save a lot of time and effort, if you
can reuse large components from other
The products or open-source software.
However, this constrains your
importance architectural choices because you must
of fit your design around the software that is
being reused.
architectura
l design
issues

25
 • Number of users:
• If you are developing consumer software
delivered over the Internet, the number of
users can change very quickly. This can
lead to serious performance degradation
The unless you design your architecture so
importance of that your system can be quickly scaled up
and down.
architectural
design
issues(cont.)

26
 • Software compatibility:
• For some products, it is important to
maintain compatibility with other software
so that users can adopt your product and
use data prepared using a different
The system. This may limit architectural
importance of choices, such as the database software
that you can use.
architectural
design issues
(cont.)

27
 • Human and organizational factors
• The planned schedule to bring the
product to market
The • The capabilities of your development
team
importance of
• The software development budget.
architectural
design issues
If you choose an architecture that
(cont.) requires your team to learn unfamiliar
technologies, then this may delay the
delivery of your system. There is no
point in creating a “perfect”
architecture that is delivered late if
this means that a competing product
captures the market.

28
 Maintainability vs.
Performance

Architectural
Security vs.
design Usability
trade-offs

Availability vs.
Time to market
and cost.
Trade off #1: Maintainability vs
Performance

Maintainability Performance

Self contained parts (components) Few components means better

easy to replace performance

takes time for components to There may be delays involved in

communicate with each other. transferring data

30
Trade off #2: Security vs Usability

Security Usability

Design the system protection Interaction with the system is

as a series of layers. inevitably slowed by its security
features.

If one of these components is Users must remember

compromised by an attacker, information, like passwords, that
then the other layers remain is needed to penetrate a security
intact. layer.

31
Authentication
layers

To avoid this, you need an architecture

that:
• Doesn’t have too many security layers,
• Doesn’t enforce unnecessary security
• Provides helper components that
reduce the load on users. 32
Trade off #3: Availability vs time-to-market

Availability Time to Market

You achieve availability by having Implementing extra components takes
redundant components in a system. time and increases the cost of system
development.

You include sensor components Adds complexity to the system

that detect failure

Switching components that switch Increases the chances of introducing

operation to a redundant bugs and vulnerabilities.
component when a failure is
detected.

33
Architectural Design Decisions
Architectural Views

Copyright © 2016, 2011, 2006 Pearson Education, Inc. All Rights Reserved
 Architectural Views

• What views or perspectives are useful

when designing and documenting a
system’s architecture?
• What notations should be used for
describing architectural models?
• Each architectural model only shows
one view or perspective of the system.
• It might show how a system is
decomposed into modules, how
the run-time processes interact or
the different ways in which system
components are distributed across
a network. For both design and
documentation, you usually need 4+1 View Model
to present multiple views of the
software architecture.
In class practice
• Draft a component diagram for your case study.
Identify the main components, define the
interfaces they provide and require, and show
the relationships and dependencies between
them.
• This diagram should reflect how different parts of
your system interact to fulfill the use cases you
have previously worked on. Be prepared to
present and discuss your draft.
Architectural
Patterns

Copyright © 2016, 2011, 2006 Pearson Education, Inc. All Rights Reserved
Architectural Patterns

Patterns are a means of representing, sharing and reusing

knowledge.

An architectural pattern is a stylized description of good design

practice, which has been tried and tested in different environments.

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

Patterns may be represented using tabular and graphical

descriptions.
The Model-View-Controller (M V C) Pattern

Name MVC (Model-View-Controller)

Description 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. See Figure 6.3.
Example Figure 6.4 shows the architecture of a web-based application system
organized using the MVC pattern.
When used Used when there are multiple ways to view and interact with data. Also used
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
Organization
of the
Model-View-
Controller
Web
Application
Architecture
Using the
MVC
Pattern
 Layered Architecture

• Layered software architectures

comprise multiple layers of
components that are placed into
logical groupings based on the type
of functionality they provide or based
on their interactions with other
components, such that interlayer
communication occurs between
adjacent layers.
• Supports the incremental development
of sub-systems in different layers.
When a layer interface changes, only
the adjacent layer is affected.
The Layered Architecture Pattern
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. See Figure 6.6.
Example A layered model of a system for sharing copyright documents held in
different libraries, as shown in Figure 6.7.
When used Used when building new facilities on top of existing systems; when the
development is 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.
The
Architecture
of a Data
Retrieval
System
 A generic layered
Architectural
architecture for a
Design
web-based
Guidelines
application in
a layered
architecture

Each layer is an
area of concern
and is
Ideally, components at considered
level X (say) should only separately from
interact with the APIs of other layers.
the components in level
X-1; that is, interactions The
should be between components are
layers and not across independent
layers. and do not
overlap in
functionality. 47
Comparison of Closed
vs. Open Layered
Architecture
 • Cross-cutting concerns are concerns that are
systemic. i.e.: they affect the whole system.
• The existence of cross-cutting concerns is the
reason why modifying a system after it has
been designed to improve its security is often
difficult.

Cross-
Cutting
Concerns

In a layered architecture, cross-cutting

concerns affect all layers in the system as well
as the way in which people use the system.
49
 • Monolithic Architecture (single
deployment unit)

Architectural
structures • Distributed Architecture (multiple
deployment units, usually consisting of
services)

50
 Client-Server Architecture

• Distributed system model which shows how data and processing is

distributed across a range of components.
• Can be implemented on a single computer.
• Set of stand-alone servers which provide specific services such as
printing, data management, etc.
• Set of clients which call on these services.
• Network which allows clients to access servers.
Client-Server
Architecture

52
A Client-Server
Architecture for a
Film Library
The Client–Server Pattern
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.
Example Figure 6.11 is an example of a film and video/DVD library organized as a
client–server system.
When used Used when data in a shared database has to be accessed from a range
of locations. Because servers can be replicated, 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 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.
Multi-tier client-server
architecture
communicates with clients
using the HTTP protocol. It
delivers web pages to the manages the system
browser for rendering and data and transfers
processes HTTP requests these data to and from
from the client. the system database.

responsible for
application-specific
operations.

55
 Application
Architectures

Copyright © 2016, 2011, 2006 Pearson Education, Inc. All Rights Reserved
Application Architectures

Application systems are designed to meet an organisational

need.

As businesses have much in common, their application

systems also tend to have a common architecture that reflects
the application requirements.

A generic application architecture is an architecture for a type

of software system that may be configured and adapted to
create a system that meets specific requirements.
 Use of Application Architectures

• As a starting point for architectural design.

• As a design checklist.
• As a way of organizing the work of the development team.
• As a means of assessing components for reuse.
• As a vocabulary for talking about application types.
 Examples of Application Types

• Data processing applications

• Data driven applications that process data in batches without explicit
user intervention during the processing.
• Transaction processing applications
• Data-centred applications that process user requests and update
information in a system database.
• Event processing systems
• Applications where system actions depend on interpreting events from
the system’s environment.
• Language processing systems
• Applications where the users’ intentions are specified in a formal
language that is processed and interpreted by the system.
 Application Type Examples

Two very widely used generic application architectures are transaction

processing systems and language processing systems.
• Transaction processing systems
• E-commerce systems;
• Reservation systems.
• Language processing systems
• Compilers;
• Command interpreters.
Transaction Processing Systems

• Process user requests for information from a database or requests to

update the database.
• From a user perspective a transaction is:
• Any coherent sequence of operations that satisfies a goal;
• For example - find the times of flights from London to Paris.
• Users make asynchronous requests for service which are then
processed by a transaction manager.
The Software Architecture
of an A T M System
 Information Systems Architecture

• Information systems have a generic architecture that can be organized as a

layered architecture.
• These are transaction-based systems as interaction with these systems
generally involves database transactions.
• Layers include:
• The user interface
• User communications
• Information retrieval
• System database
The
Architecture
of the
Mentcare
System
Web-Based Information Systems

• Information and resource management systems are now usually

web-based systems where the user interfaces are implemented using
a web browser.
• For example, e-commerce systems are Internet-based resource
management systems that accept electronic orders for goods or
services and then arrange delivery of these goods or services to the
customer.
• In an e-commerce system, the application-specific layer includes
additional functionality supporting a ‘shopping cart’ in which users
can place a number of items in separate transactions, then pay for
them all together in a single transaction.
 Server Implementation

• These systems are often implemented as multi-tier client

server/architectures
• The web server is responsible for all user communications, with the user
interface implemented using a web browser;
• The application server is responsible for implementing application-
specific logic as well as information storage and retrieval requests;
• The database server moves information to and from the database and
handles transaction management.
 Issues in Architectural Choice

• Data type and data updates

• When using structured data that may be updated by different system
features, better to have a single shared DB that provides locking and
transaction management. If data is distributed across services, you
need a way to keep it consistent and this adds overhead to your system.
• Change frequency
• If you anticipate that system components will be regularly changed or
replaced, then isolating these components as separate services
simplifies those changes.
• System execution platform
• If you plan to run your system on the cloud with users accessing it over
the Internet, best implement it as a SOA because scaling the system is
simpler. If your product is a business system that runs on local servers,
a multi-tier architecture may be more appropriate.
67
Technology Choices

Database Platform
Should you use a relational SQL Should you deliver your product
database or an unstructured on a mobile app and/or a web
NOSQL database? platform?

Server
Should you use dedicated in-
house servers or design your
system to run on a public cloud?
If a public cloud, should you use
Amazon, Google, Microsoft, or
some other option?

68
Technology Choices (cont.)

Development Tools
Open Source Do your development tools
Are there suitable open-source embed architectural
components that you could assumptions about the software
incorporate into your products? being developed that limit your
architectural choices?

69
Database

• There are two kinds of database that are now commonly used:
• Relational databases
• NoSQL databases, in which the data has a more flexible, user-
defined organization.
• Relational databases, such as MySQL, are particularly suitable for
situations where you need transaction management, and the data
structures are predictable and simple.
• NoSQL databases, such as MongoDB, are more flexible and
potentially more efficient than relational databases for data analysis.

70
Delivery Platform

• Delivery can be as a web-based or a mobile product or both. Mobile

issues:
• Intermittent connectivity You must be able to provide a limited
service without network connectivity.
• Processor power Mobile devices have less powerful processors,
so you need to minimize computationally-intensive operations.
• Power management Mobile battery life is limited so you should
try to minimize the power used by your application.
• On-screen keyboard On-screen keyboards are slow and error-
prone. You should minimize input using the screen keyboard to
reduce user frustration.

71
Server

• A key decision that you have to make is whether to design your

system to run on customer servers or to run on the cloud.
• For consumer products that are not simply mobile apps I think it
almost always makes sense to develop for the cloud.
• For business products, it is a more difficult decision.
• Some businesses are concerned about cloud security and prefer
to run their systems on in-house servers. They may have a
predictable pattern of system usage so there is less need to
design your system to cope with large changes in demand.
• An important choice you have to make if you are running your
software on the cloud is which cloud provider to use.

72
Development tools

• Development technologies, such as a mobile development toolkit or

a web application framework, influence the architecture of your
software.
• The development technology that you use may also have an indirect
influence on the system architecture.
• Developers favor architectural choices that use familiar technologies
that they understand. For example, if your team have a lot of
experience of relational databases, they may argue for this instead of
a NoSQL database.

73
Open Source

• Open-Source software is software that is available, which you can

change and modify as you wish.
• The advantage is that you can reuse / implement new software
→ reduces development costs and time to market.
• The disadvantages of using open-source software: constraints to
that software/ no control over its evolution.
• The decision on the use of open-source software depends on the
availability, maturity and continuing support.
• Open source license issues may impose constraints on how you use
the software.

74