SOF 204 – Software

Architecture and Design

Patterns
Chapter 1: What is Software Architecture

Instructor: Tee Sim Hui

Prepared by SH Tee 1
Overview of this chapter

 An overview of the representation of software architecture from different

perspectives.
 A general overview of system and enterprise software architecture.
 An overview of the patterns of software architecture.
 Distinguishing good and bad software architecture.

Prepared by SH Tee 2
What is software architecture?

 Software architecture requires knowledge of computer languages and data

structure.
 Software architecture is not about computer languages, but it concerns the
organization or structure of a software system.
 A software system consists of various programs and applications, all of which
involve an enormous lines of codes.
 A good practice must be upheld in order to maintain these codes (which
comprise of computer programs) in a maintainable, interoperable, and
extensible state.

Prepared by SH Tee 3
 A software architecture encompass the structural organization of various
computer programs. These programs must be organized in specified patterns
for interoperability.
 Having a good knowledge in software architecture is vital for the successful
development of a software system.
 A good software architecture may serve to the benefits of an organization’s or
an enterprise’s objectives and aims.
 Software systems comprise of a collection of diverse applications and
programs. They must be properly designed to satisfy an organization’s
business goals.

Prepared by SH Tee 4
 A software architecture defines the patterns or ways in which the concrete
software systems may be used to achieve the rather abstract business goals of
an organization.
 Hence, a good design of software architecture requires knowledge from both
software and business perspectives.
 Software architecture guides program development and software analysis.

Prepared by SH Tee 5
Definitions of software architecture

 A very general definition of software architecture can be found in Bass

(2013): “The software architecture of a system is the set of structures needed
to reason about the system, which comprise software elements, relations
among them, and properties of both.”
 This definition implies that a software architecture is a blueprint of a set of
complex software systems. This architecture is logical rather than physical.
 Software structures that comprise a software architecture contain a set of
software elements which are held together by logical relations.

Prepared by SH Tee 6
Other definitions for software
architecture
 Software architecture concerns with the design and implementation of the
high-level structure of software (Kruchten)
 Software architecture encompasses elements, form, and rationale (Perry and
Wolf)
 Software architecture describes the elements, interactions among the
elements, and the patterns that govern the organization of those elements.
(Shaw and Garlan)

Prepared by SH Tee 7
Why a software architecture is needed?

 Software architecture is a platform for communication and information flow.

 Software architecture is a framework for the evaluation of quality attributes.
 Software architecture facilitates early design decisions.
 Software architecture defines constraints on an implementation.
 Software architecture enables the evolution of software system in an
enterprise.
 Software architecture provides a transferable and reusable IT model.

Prepared by SH Tee 8
 Software architecture improves cost and schedule estimates.
 Software architecture permits incorporation of independently developed
components.

Prepared by SH Tee 9
Software architecture vs. software
design
 Software architecture involves bigger structures of the totality of software
systems. It deals with the integration of multiple software systems.
 Software design involves smaller structures which are dealing with the
internal design of a single software process.
 All architecture is a design; not all designs are an architecture.
 Software architecture is akin to the blueprint of a house. It can be
decomposed into system design and software design, which are akin to the
individual layout of the parts inside a house.

Prepared by SH Tee 10
Categories of architectural structures

 There are three categories of architectural structures: structures as modules,

structures as dynamic entities, and structures as mapping constructs.
 Structures as modules represent a category which partitions systems into
implementation units called modules. Modules are computational tasks that
are manageable at a smaller scale.
 A large software project always consists of various small-scale modules.

Prepared by SH Tee 11
 Modules enhance the efficiency and productivity of software development. It
also facilitates collaboration and maintenance of a software system.
 Different functionality always performed by different modules.
 Modules facilitate development and upgrading of a software system.
 Modules are categorized and aggregated into layers. These layers form the
general architecture structure of a software system.
 Module categorization and assignment must be done carefully by taking the
functionality of a software system into consideration.

Prepared by SH Tee 12
 Module structures allow us to ask the following questions:
1. What is the functional task and responsibility assigned to each module?
2. How does a module interact with other modules?
3. What module to be used in a specified context?
4. How does information convey using modules?

Prepared by SH Tee 13
 Useful module structures include:
1. Decomposition structures—a module is decomposed into submodules.
2. Uses structures—the modules are related by the “uses relation”, which is a
specialized form of dependency between modules. The operation of a
module is dependent on another in the “uses relation”. A use case (often
called scenarios) stipulates the modules and their interrelationship.
3. Layer structures—modules are organized into layers which are an abstract
virtual machine that provides a cohesive and consistent set of services
through an interface.

Prepared by SH Tee 14
4. Class structures—The modules are classes of similar software components that
perform related behaviors or functions.
5. Data models—The modules encompass data entities and data relationships. It
is a common model in a database model. Examples of data entities are students
and courses. An example of data relationship is that a student may be associated
with one or more courses.

Prepared by SH Tee 15
 Module structure:

Prepared by SH Tee 16
 The second category of architectural structures treats structures as dynamic
entities.
 Dynamic structures also called runtime structures or component-and-
connector structures.
 An architectural structure is not static; rather, it is dynamic.
 Components are objects, threads, or processes.
 Connectors describe how the components interact. They stipulate such
interaction rules.

Prepared by SH Tee 17
 Software systems are evolving—the programmers and software analysts may
add, amend, and discard software (or lines of codes) from time to time.
 Software systems evolve to reflect the business operations and routines of an
enterprise.

Prepared by SH Tee 18
 A dynamic architectural structure facilitates interactions between software
elements to carry out the system’s functions.
 Various applications are interacting with each other in performing specified
system functions.
 A software architecture must accommodate the dynamic evolution of
software systems.
 The interacting applications must be compatible, extensible, and robust to
maintain the dynamicity of a software architecture.

Prepared by SH Tee 19
 The dynamic view of an architecture allows us to ask the following questions:
1. What are the executing components and how do they interact?
2. How does data progress through the system?
3. How does the system’s structure change over time?
4. How efficient does the software elements interact and co-evolve?

Prepared by SH Tee 20
 Useful dynamic (runtime or component-and-connector) structures include:
1. Service structures—the units are services that interoperate with each other by
service coordination mechanisms such as Simple Object Access Protocol
(SOAP), which is a messaging protocol used in web services. Most of the
client-server structures are service structures.
2. Concurrency structures—the units are components which are arranged into
logical threads (i.e., a sequence of computations). It allows for parallel
computations and concurrent executions of software applications.

Prepared by SH Tee 21
3. Shared data structure—it consists of components and connectors that create,
store, and access persistent data (e.g., database). It manifests how data are
produced and consumed by runtime software elements.
4. Process structure—it deals with the runtime aspects of a system. The basic
units are processes or threads that are connected with each other by
communication, synchronization, and exclusion operations.

Prepared by SH Tee 22
Prepared by SH Tee 23
 Concurrency structure

Prepared by SH Tee 24
 The third category of architectural structures treats structures as mapping
constructs.
 This type of structure stipulates the structural mapping from software
structures to the system’s life cycle.
 This mapping structure is also known as allocation structure.
 Structural mappings are defined between applications and various system’s
environments, such as the system organization, installation, recovery, and
execution environments.
 A mapping/allocation structure shows how the processes in the architecture
are mapped to hardware, and how they communicate using networks or
databases.

Prepared by SH Tee 25
 The mapping (allocation) view of an architecture allows us to ask the
following questions
1. What processor does each software element execute on?
2. How does a software element correspond to a specified hardware component?

Prepared by SH Tee 26
 Useful mapping/allocation structures are:
1. Deployment structures—it stipulates how software is assigned to hardware
processing. It consists of software elements, hardware elements, and
communication pathways between hardware and software.
2. Implementation structures—it defines how software elements are mapped to
the file structures in the system’s environments.
3. Work assignment structures—it assigns responsibility for implementing the
modules to the teams who will perform it.

Prepared by SH Tee 27
 Allocation structure

Prepared by SH Tee 28
 Three categories of architectural structures: A summarized view

Prepared by SH Tee 29
Architecture modeling

 Software architectures are specified by models.

 To architect is to model.
 To model is to describe.
 To describe is to draw.
 Software architectures can be defined by:
 ADL (Architecture Description Language)—it defines an architecture formally.
 Architecture View Model—it represents the functional and non-functional
requirements of software applications.
 UML (Unified Modeling Language)—it is an object-oriented framework used in
software modelling and design.
 Archi—it is an open-source modelling tool for an enterprise architecture.
Prepared by SH Tee 30
Prepared by SH Tee 31
 A structure is architectural if it supports reasoning about the software system
—there is an emerging pattern that allows inference to be made from a
software element to another.
 Architecture implies patterns, ordered organizations of software elements,
and specified interactions among software elements.
 Software architecture is an abstraction—it consists of structures, which in
turn consist of software elements and relations.
 The relations among software elements stipulate how the software elements
interact and organized.

Prepared by SH Tee 32
 Software architecture as an abstraction:

Prepared by SH Tee 33
Adapted from Gorton (2006, p. 8)
 Software relations are the backbone of an architecture. They must be kept
dynamic and flexible to adapt to the change of software requirements and
business operations.
 Architecture as an abstraction implies a simplification—it does not concern
about every details of codes or technical configurations of software elements.
Rather, architecture selects certain aspects of the software elements while
omitting others.
 The selected aspects must represent the organization and interacting
patterns of software elements.

Prepared by SH Tee 34
 The abstract nature of an architecture allows us to have a bird’s-eye view of
the software systems, elements, and the interconnected software relations.
 This bird’s-eye view is important for a software architecture to grasp the
nature of the complex software system in a comprehensive way, which is
critical for system upgrade, maintenance, and restoration.
 To use software architecture to support reasoning about software systems, we
need to study the behaviors (actions, interactions, etc) of the software
elements.

Prepared by SH Tee 35
 Every software system has an architecture. But it does not mean all
architectures are equally good.
 It is the responsibility of a software architect to design a good (rather than
bad) architecture.
 A good software architecture facilitates a system’s achievement of its life-
cycle requirements. This will translate into high quality of software
attributes and efficient software interactions and behaviors.
 A good software architecture provides insights into software design and
planning.

Prepared by SH Tee 36
Software architecture vs. System and
enterprise architectures
 Software architecture is a blueprint of software systems.
 System and enterprise architecture is a blueprint of digital systems (which
includes networking devices, databases, mobile systems, etc) and of
enterprise, respectively.
 Software architecture is relevant to system and enterprise architectures
because every enterprise has a software system.
 Software architecture is embedded within the ecosystem of a system and an
enterprise architecture.

Prepared by SH Tee 37
 A system architecture defines the functionality mapping between hardware
systems and software systems.
 An enterprise architecture defines the structure and behaviors of an
enterprise’s processes, business flows, information flows, and organizational
structure.
 An enterprise architecture specifies the data and system models.
 A software architecture supports the enterprise architecture—to ensure the
smooth flows of business operations.

Prepared by SH Tee 38
Architectural patterns

 Architectural elements are composed in specified ways to solve particular

problems.
 These compositions of architectural elements, known as architectural
patterns, provide organized strategies for tackling system’s problems arisen
from time to time.
 An architectural pattern is important for reasoning and analysis about
software components.
 An architectural pattern defines the element types and their interactions in
problem solving.

Prepared by SH Tee 39
 Architectural patterns are reusable solutions in software architecture.
 An architectural pattern has a broader scope as compared to a software
design pattern.
 An architectural pattern specifies recurring patterns relevant to the software
and system elements of a software architecture.

Prepared by SH Tee 40
 Architectural patterns can be characterized according to the category of
architectural structure that is in use. For example, layered pattern is a
module type pattern; client-server pattern is a dynamic (runtime) type
pattern; multi-tier pattern is a mapping (allocation) type pattern.
 In a layered pattern, a layer groups a set of related functionality together.
Software elements are organized in a hierarchy which consists of different
layer of functionality. Layers are designed as abstractions (virtual machines)
that hide implementation details of the lower layers.

Prepared by SH Tee 41
 The shared-data pattern (also known as repository pattern) is a dynamic type
pattern consisting of persistent data. Data are created, stored, and accessed
from the repository, such as a database.
 The client-server pattern is a dynamic type pattern consisting of clients and
servers. This pattern is common in web services and networking systems.
 The multi-tier pattern is a mapping (allocation) type pattern defining how to
allocate the software components to hardware components.

Prepared by SH Tee 42
 Some of the architectural patterns are:
 Managed File Transfer (MFT)—A service that manages the secure transfer of data
from one device to another through a network.
 Enterprise service bus (ESB)—it is implemented in a service-oriented architecture
for mutually interacting software applications. ESB routes messages between
services and controls deployment of services.
 Peer-to-peer—individual components are known as peers. A peer may act as a
client or as a server or as both. It is a distributed architecture that partitions tasks
between peers.
 Master-slave pattern—the master component distributes the work among slave
components. The results returned from the slave components will be returned to
the master component for final compilation and computation.

Prepared by SH Tee 43
What makes a “good” architecture?

 A software architecture must be designed to fit the desired purposes.

 A good architecture does realize such a fit, while a bad architecture does not.
 There is no objectively strict definition of a good architecture. Rather, how
good an architecture is should be viewed from the pragmatic perspective.
 However, a software architecture can be evaluated against specified goals.
 There are rules to be followed when designing a software architecture. Going
against these rules will lead to a bad architecture.

Prepared by SH Tee 44
 There are two categories of architecture designing rules: process-based rules
(process recommendations) and product-based rules (product
recommendations).
 Process recommendations are:
1. The architecture should be designed by a single (or a small group of)
architect. This ensures conceptual integrity and technical consistency of an
architecture.
2. The architect should design the architecture base on a prioritized list of well-
specified quality attribute requirements.

Prepared by SH Tee 45
3. The architecture must be documented for the purpose of analysis and
maintenance of the system.
4. The architecture must be designed in such a way that the system’s quality
attributes can be delivered.
5. The architect should implement the architecture in a piecemeal fashion. This
is to avoid any major potential problem to be introduced at once into the whole
software system.

Prepared by SH Tee 46
 Product recommendations are:
1. The principles of information hiding must be used for modules. The
information-hiding module insulates the software from effects of changes.
2. The system’s quality attributes should be achieved using well-known
architectural patterns and tactics.
3. The architecture should be product- and tool-independent. This allows
flexibility and scalability.
4. Data-producing modules should be separated from data-consuming modules.
This practice will increase modifiability of software elements.

Prepared by SH Tee 47
5. Every process should be documented.
6. The system should be designed consistently, in such a way that the same
behaviour should be performed in the same condition. This will promote
modifiability and reliability while reduce development time.
7. Resource usage should be specified in an architecture. For example, a
guideline should be provided by the architect for a minimum network traffic
when the concern of network utilization arises.

Prepared by SH Tee 48
 In general, a good architecture has the following characteristics:
1. Standard ways have been developed to address recurring concerns (i.e., there
exists a well-defined architectural pattern).
2. Conceptual integrity is manifested. This helps maintaining the vision of a
software system that may guide the implementation of various applications.
3. High standard of quality attributes such as compatibility, extensibility,
maintainability, security, reliability, and fault-tolerance.
4. Taking care of the interest of various stakeholders such as board of directors,
managers, operators, and end users.

Prepared by SH Tee 49
5. A good architecture addresses both technical and business constraints.
Example of a technical constraint: “The existing database runs on Windows 10
only”. Example of a business constraint: “We are moving to an open source
version due to the daunting price imposed by the supplier”

Prepared by SH Tee 50
The responsibilities of a software
architect
 To ensure a good software architecture, the responsibilities of a software
architect include:
 Design and manage the architecture and the associated technologies.
 Liaison: architects liaise between the clients of the application and the technical
team.
 Justification of the system: provide justification pertaining to the cost, design, and
implementation of the architecture.
 Risk management: architects are constantly evaluating the risks associated with
the design and implementation of an architecture.

Prepared by SH Tee 51