Software Architecture

IF352 – Software Engineering IST

 Reference
▪ Roger Pressman – Ch 7 & 8
▪ Ian Sommerville – Ch 6
▪ These slides are adapting from the accompanying slides of
▪ Software Engineering: A Practitioner’s Approach, 7/e (McGraw-
Hill, 200a9). Slides copyright 2009 by Roger Pressman.
▪ Ian’s Slides

9/20/2021 Software Archtiecture 2

 Objective
▪ Students understand the meaning and elements of software
architecture
▪ Students understand the role of software architecture
▪ Students are able to create an architecture of a simple software

9/20/2021 Software Archtiecture 3

 Software Architecture
▪ Software architecture alludes to “the overall structure of the
software and the ways in which that structure provides conceptual
integrity for a system” [Sha95a].
▪ The architecture model [Sha96] is derived from three sources
▪ the application domain for the software to be built;
▪ specific requirements model elements such as data flow
diagrams or analysis classes, their relationships and
collaborations for the problem at hand;
▪ the availability of architectural patterns and styles

9/20/2021 Software Archtiecture 4

 Sample of Architecture
Packing robot control system

9/20/2021 Software Archtiecture 5

 Why do we need an architecture
▪ The architecture is not the operational software. Rather, it is a
representation that enables a software engineer to:
▪ understanding how a software system should be organized and
designing the overall structure of that system.
▪ critical link between design and requirements engineering, as it identifies
the main structural components in a system and the relationships
between them.
▪ analyze the effectiveness of the design in meeting its stated
requirements,
▪ consider architectural alternatives at a stage when making design
changes is still relatively easy, and
▪ reduce the risks associated with the construction of the software.

9/20/2021 Software Archtiecture 6

 Why do we need an architecture …(2)
▪ Representations of software architecture are an enabler for
communication between all parties (stakeholders) interested in
the development of a computer-based system.
▪ The architecture highlights early design decisions that will have
a profound impact on all software engineering work that follows
and, as important, on the ultimate success of the system as an
operational entity.
▪ Architecture “constitutes a relatively small, intellectually
graspable mode of how the system is structured and how its
components work together” [BAS03].

9/20/2021 Software Archtiecture 7

 Advantages of having an explicit architecture
▪ Means for analysis of whether the system can meet its non-
functional requirements is possible.
▪ Ease in reuse at Large-scale
▪ The architecture may be reusable across a range of systems
▪ Product-line architectures may be developed.

9/20/2021 Software Archtiecture 8

Architectural Descriptions
▪ The IEEE Computer Society has proposed IEEE-Std-1471-2000,
Recommended Practice for Architectural Description of Software-Intensive
System, [IEE00]
▪ to establish a conceptual framework and vocabulary for use during the design of
software architecture,
▪ to provide detailed guidelines for representing an architectural description, and
▪ to encourage sound architectural design practices.
▪ The IEEE Standard defines an architectural description (AD) as a “a
collection of products to document an architecture.”
▪ The description itself is represented using multiple views, where each view is “a
representation of a whole system from the perspective of a related set of
[stakeholder] concerns.”

9
 Architecture Design

9/20/2021 Software Archtiecture 10

Architectural Design
▪ The software must be placed into context
▪ the design should define the external entities (other systems,
devices, people) that the software interacts with and the
nature of the interaction
▪ A set of architectural archetypes should be identified
▪ An archetype is an abstraction (similar to a class) that
represents one element of system behavior
▪ The designer specifies the structure of the system by defining
and refining software components that implement each
archetype
11
 Things to be watch out - Complexity
▪ Complexity is assessed by considering the dependencies between
components within the architecture [Zha98]
▪ Sharing dependencies represent dependence relationships among
consumers who use the same resource or producers who produce
for the same consumers.
▪ Flow dependencies represent dependence relationships between
producers and consumers of resources.
▪ Constrained dependencies represent constraints on the relative
flow of control among a set of activities.
▪ Abstraction

9/20/2021 Software Archtiecture 12

 Things to be watch out - Abstraction
▪ Architecture in Small or in Large?
▪ Architecture in the small is concerned with the architecture of
individual programs. 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.

9/20/2021 Software Archtiecture 13

 Things to be watch out - Decision
▪ 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.

9/20/2021 Software Archtiecture 14

 Step-by-Step
1. Define architecture context
2. Define the archtypes
3. Define the components
▪ Considering process, control, and data models
4. Organize the components into a structure of a software
systems
5. Refine the components or the structure (rep. 3-5 if necessary)

9/20/2021 Software Archtiecture 15

Architectural Context

Safehome Internet-based
Product system

control
panel target system: surveillance
Security Function function
uses
homeowner peers
uses

uses

sensors sensors

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
16
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman.
Archetypes

Cont roller

communicat es wit h

Node

Det ect or Indicat or

These slides are designed

Figure 10.7to UML
accompany Software
relat ionships Engineering:
f or Saf eHome A Practitioner’s
securit y f unct ion archet ypes Approach, 7/e
17
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman.
(adapt ed f rom [ BOS00] )
 Defining the component

Consider your analysis

- Partitioning
- Separation concerns Program
Architecture
- Abstraction

9/20/2021 Software Archtiecture 18

Component Structure

SafeHome
Execut ive

Funct ion
select ion

Ext ernal
Communicat ion
Management

Securit y Surveillance Home

management

GUI Int ernet

Int erface

Cont rol det ect or alarm

panel management processing
processing

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
19
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman.
Refined Component Structure

SafeHome
Executive

Ext ernal
Communicat ion
Management

Security

GUI Internet
Interface

Cont rol det ect or alarm

panel m anagem ent processing
processing

Key pad
processing phone
scheduler
com m unicat ion

CP display
funct ions
alarm

sensor
sensor
sensor
sensor
sensor
sensor
sensor
sensor
sensor

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
20
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman.
Analyzing Architectural Design
▪ After doing the requirement analysis (engineering)
▪ Scenarios, requirements, constraints, env. context
▪ Quality attributes (non-functional requirements)
▪ Evaluate quality attributes by considered each attribute in
isolation.
▪ Identify the sensitivity of quality attributes to various
architectural attributes for a specific architectural style
▪ Critique the candidate architecture using quality attributes and
related sensitivity analysis
21
 (Some) system characteristics
▪ 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
▪ Localize 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.

20/09/2021 Chapter 6 Architectural Design 22

 Architecture Patterns & Styles

9/20/2021 Software Archtiecture 23

 (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.
20/09/2021 Chapter 6 Architectural Design 24
 Some) Architectural Patterns
▪ Concurrency—applications must handle multiple tasks in a manner that
simulates parallelism
▪ operating system process management pattern
▪ task scheduler pattern
▪ Persistence—Data persists if it survives past the execution of the process that
created it. Two patterns are common:
▪ a database management system pattern that applies the storage and retrieval capability of
a DBMS to the application architecture
▪ an application level persistence pattern that builds persistence features into the
application architecture
▪ Distribution— the manner in which systems or components within systems
communicate with one another in a distributed environment
▪ A broker acts as a ‘middle-man’ between the client component and a server component.
These slides are designed to accompany
Software Engineering: A Practitioner’s
Approach, 7/e (McGraw-Hill, 2009). 25
Slides copyright 2009 by Roger
 The Model-View-Controller (MVC) 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.

20/09/2021 Chapter 6 Architectural Design 26

 The organization of the Model-View-Controller

20/09/2021 Chapter 6 Architectural Design 27

 Web application architecture using the MVC pattern

20/09/2021 Chapter 6 Architectural Design 28

Architecture Style
▪ Each style describes a system category that encompasses: (1) a set of
components (e.g., a database, computational modules) that perform a function
required by a system, (2) a set of connectors that enable “communication,
coordination and cooperation” among components, (3) constraints that define
how components can be integrated to form the system, and (4) semantic
models that enable a designer to understand the overall properties of a system
by analyzing the known properties of its constituent parts.
▪ Data-centered architectures
▪ Data flow architectures
▪ Call and return architectures
▪ Object-oriented architectures
▪ Layered architectures
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
29
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman.
Data-Centered Architecture

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
30
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman.
Data Flow Architecture

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
31
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman.
Call and Return Architecture

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
32
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman.
Layered Architecture

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
33
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman.