SOFTWARE ENGINEERING

ARCHITECTURAL DESIGN
Contact Information

 Instructor

Mrs. Remya P George

 E-Mail:

rpgeorge@iau.edu.sa

 Office Hours:

Sunday 10-12
Monday 10-11
 Objectives
3

 Understand why the architectural design of software is important;

 Understand the decisions that have to be made about the system

architecture during the architectural design process;

 Know the architectural patterns that are often used in different types

of application system, including transaction processing systems and

language processing systems.

 Topics covered
4

 Architectural design decisions

 Architectural views

 Architectural patterns

 Application architectures
 Software architecture
5

 Architectural design is concerned with understanding how a system

should be organized and designing the overall structure of that

system (including functional and non-functional requirements).

 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 architecture of a packing robot
6
control system
 Each box in the diagram represents a
component.
 Boxes within boxes indicate that the
component has been decomposed to sub-
components.
 Arrows mean that data and control signals
are passed from component to component
in the direction of the arrows.
 It uses a vision component to pick out
objects on a conveyor, identify the type of
object, and
 Select the right kind of packaging. The
system then moves objects from the
delivery conveyor to be packaged.
 It places packaged objects on another
conveyor.
 Architectural abstraction
7

 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, and program components.

These enterprise systems are distributed over different computers, which may

be owned and managed by different companies.

 Advantages of explicit architecture
8

 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.
 Architectural design decisions
9

 During the architectural design process, system architects have to consider

a number of questions that affect the system and its development process:
1) Is there a generic application architecture that can be used?
2) How will the system be distributed?
3) What architectural styles are appropriate?
4) What approach will be used to structure the system?
5) How will the system be decomposed into subsystems?
6) What control strategy should be used?
7) How will the architectural design be evaluated?
8) How should the architecture be documented?
 Architecture reuse
10

 Using your knowledge, do you think software system is unique?

 Although each software system is unique, systems in the same

application domain often have similar architectures that reflect the

fundamental concepts of the domain.

 The architecture of a system may be designed around one of more

architectural patterns or ‘styles’ such as a client-server organization or a

layered architecture.
 Architecture and system characteristics
11

 The particular architectural style that you choose for a system should depend on the
non-functional system requirements:
 Performance
 If performance is a critical requirement, the architecture should
be designed to localize critical operations within a small number
of components, with these components all deployed on the same
computer rather than distributed across the network.
 Security
 If security is a critical requirement, a layered structure for the
architecture should be used, with the most critical components
protected in the innermost layers, with a high level of security
validation applied to these layers.
 Architecture and system characteristics
12

 Safety
 If safety is a critical requirement, the architecture should be
designed so that safety-related operations are all located in
either 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.
 Availability
 If availability is a critical requirement, the architecture should be
designed to include redundant components so that it is possible
to replace and update components without stopping the system.
 Maintainability
 Use fine-grain, changeable components.
 View model of software architecture
13

 There are four fundamental architectural views

 A logical view, which shows the key abstractions in the system as objects or

object classes.

 A process view, which shows how, at run-time, the system is composed of

interacting processes.

 A development view, which shows how the software is decomposed for

development.

 A physical view, which shows the system hardware and how software

components are distributed across the processors in the system.

 Architectural patterns
14

 Patterns are a means of representing, sharing and reusing knowledge.

 Patterns should include information about when they are useful and when

they are not useful.

 Patterns may be represented using tabular and graphical descriptions.

 An architectural pattern is a description of good design practice, which has

been tried and tested in different environments.

The Model-View-Controller (MVC) pattern
15

Name MVC (Model-View-Controller)

It is the basis of interaction management in many web-based

systems.
Separates presentation and interaction from the system data. The system
is structured into three logical components that interact with each other.
Description
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 and passes these interactions to the View and the Model.
Used when there are multiple ways to view and interact with data. Also
When used used when the future requirements for interaction and presentation of
data are unknown.

Allows the data to change independently of its representation and vice

Advantages versa. Supports presentation of the same data in different ways with
changes made in one representation shown in all of them.

Can involve additional code and code complexity when the data model
Disadvantages
and interactions are simple.
 Web application architecture using the
16
MVC pattern
manages user interaction
(e.g., key presses, mouse defines and manages how
clicks, etc.) and passes these the data is presented to
interactions to the View and the user.
the Model.

manages the system

data and associated
operations on that data.

Architecture of a web-based application system organized using the MVC pattern

 Layered architecture
17

 Used to model the interfacing of sub-systems.

 Organises the system into a set of layers each of which provide a set of

services.

 It 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
18

Name Layered architecture

Organizes the system into layers with related functionality associated with
each layer. A layer provides services to the layer above it so the lowest-
Description
level layers represent core services that are likely to be used throughout
the system.

Used when building new facilities on top of existing systems; when the
development is spread across several teams with each team responsibility
When used
for a layer of functionality; when there is a requirement for multi-level
security.
Allows replacement of entire layers so long as the interface is maintained.
Advantages Redundant facilities (e.g., authentication) can be provided in each layer to
increase the dependability of the system.

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
Disadvantages 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 generic layered architecture
19
 The architecture of the LIBSYS system
20

User Interface layer

User and authorization

layer

Application layer

System Support layer

 Information systems architecture
21

 All systems that involve interaction with a shared database can be considered
to be transaction-based information systems.
 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
 Layered information system
22
architecture
 The architecture of the MHC-PMS
23

The top layer is the user

interface. In this case, the UI
has been implemented using a
web browser.
The second layer includes some
functions that are delivered
through the web browser such
as log in and checking
components, and some form
and menu management
components that present
information to users, as well as
data validation components
that check information
consistency.
The third layer implements the functionality of the system and provides components that
implement system security, patient information creation and updating, import and export of
patient data from other databases, and report generators that create management reports.
 Repository architecture
24

 The layered architecture and MVC patterns represent the conceptual

organization of a system, While the repository pattern describes how a set
of interacting components can share data.
 The process of exchanging data (between subsystems) will be done in two ways:
 Shared data is held in a central database or repository and may be
accessed by all sub-systems;
 Each sub-system maintains its own database and passes data explicitly to
other sub-systems.
 When large amounts of data are to be shared, the repository model of
sharing is most commonly used.
 A repository architecture for an IDE
25
 The Repository pattern
26

Name Repository
All data in a system is managed in a central
repository that is accessible to all system
Description
components. Components do not interact directly,
only through the repository.

You should use this pattern when you have a system

When used
with large data that has to be stored for a long time.

Components can be independent. Changes made by

Advantages one component can be propagated to all
components.

Disadvantages The repository is a single point of failure.

 Client-server architecture
27

 The repository pattern is concerned with the static structure of a system and

does not show its run-time organization.

 The Client server pattern is the common run-time pattern for distributed systems.

 Distributed system model shows how data and processing is distributed across

a range of components.

 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.

 The Client–server pattern
28

Name Client-server

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

organized into services, with each service delivered from a separate
Description
server. Clients are users of these services and access servers to make
use of them.

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

When used
of locations.

Servers can be distributed across a network. General functionality (e.g.,

Advantages a printing service) can be available to all clients and does not need to be
implemented by all services.

Performance may be unpredictable because it depends on the network.

Disadvantages May be management problems if servers are owned by different
organizations.
 A client–server architecture for a film
29
library
30

 Thanks for your attention

 I wish you all the best