SOF 204 – Software

Architecture and Design

Prepared by SH Tee 1
Overview of this chapter

 This chapter focuses on the significance of software architecture from the

Prepared by SH Tee 2
1. Inhibiting or enabling a system’s
quality attributes
 There is a wide range of system’s quality attributes: reliability, security,
extensibility, maintainability, robustness, consistency, fault-tolerance,
modifiability, accuracy, high performance, reusability, etc.
 A good software architecture is important for a system to achieve its quality
attributes.
 It is important to note that it is not necessary (and impractical) for a software
architecture to address ALL quality attributes. It is simply too costly to do so.
 The software architecture enables the desired quality attributes, while
inhibits the unfavourable attributes.
 If high performance of a system is required, special attention needs to be
given to managing the time-based behaviors of software or hardware
elements, and the frequency and volume of inter-element communication.

Prepared by SH Tee 3
 If modifiability is the desired quality attribute, suitable modules need to be
designed in such a way that the modification of one module will not affect
other modules. Similar modules are to be grouped into the same layer.
Information hiding is to be applied in software implementation.
 If security is a critical quality attribute, accessibility to a software or
hardware component needs to be managed carefully. Authentication is
required for certain sensitive software elements. Encrypted messages may
need to be regulated for reliable communication.
 If accuracy matters, specified algorithms may need to be introduced to
ensure the accurate delivery of an outcome or output data.
 If fault-tolerance is the desired quality attribute, the system must be robust
to resist potential threats. A back-up scheme/plan/system may be needed
for recovery.

Prepared by SH Tee 4
 If consistency is the desired attribute, the same design patterns and
terminologies need to be in place. The same protocol may need to be used in
the hardware and software configuration to avoid the potential conflict or
incompatibility between software or hardware elements.
 All of these quality attributes (e.g., accuracy, modifiability, etc) can be
evaluated against the standard practice or organization’s goals.
 The evaluation of a quality attribute can be both subjective and objective.
For instance, the degree of consistency may be determined more or less by
the experience of a software architect, which is a matter of personal
judgment.
 Some of the quality attributes can be measured and evaluated by technical
personnel. For example, the modifiability of a software may be judged by
programmers who are dealing with that software.

Prepared by SH Tee 5
 The evaluation of quality attributes is a mixture of science and art.
 The strategies of enabling a quality attribute are architectural (i.e., high-
level, details-omitted).
 An architecture alone cannot guarantee the quality or functionality required
of a system. The efforts from the technical teams are equally important at
the implementation level.
 After all, a good architectural design does not guarantee a good system if the
implementation is poor.
 The coordination between architectural design and the technical
implementation is vital for a successful system.

Prepared by SH Tee 6
 A good architecture is necessary but insufficient to guarantee quality. A good
planning must accompanied by an equally good implementation.
 Decisions at all stages of the software life cycle (from architectural design to
coding and deployment) affect system quality.

Prepared by SH Tee 7
2. Architectural decisions permit
reasoning and managing changes
 Software systems are constantly evolving. Changes are inevitable in the
course of the evolution of a software system.
 Software systems change in response to the changing IT ecosystems, the
business environment, and the regulatory policies.
 A good architecture enables rational reasoning about changes made to the
software and hardware elements.
 Architectural decisions facilitate the management of changes. Each change
can be backup by reasonable architectural decisions.

Prepared by SH Tee 8
 There are three categories of possible changes: local, nonlocal, and architectural.
 A local change involves the modification of a single element. For example, (1) adding a
new business rule to a pricing logic module; (2) removing a software module from an
application with respect to the change of the business environment.
 A nonlocal change requires multiple element modifications without modifying the
underlying architectural approach. For example, after adding a new business rule to a
pricing logic module, new fields are added to the database to capture the entries of
price-related information. In addition, a new graphical user interface (GUI) is added to
the application.
 An architectural change affects the fundamental ways in which the elements interact
with each other. For example, changing a system from client-server architecture to
peer-to-peer architecture.
 Local changes are usually more desirable as less cost (in terms of money and time)
is involved.

Prepared by SH Tee 9
 Nonlocal and architectural changes need to be planned and managed
carefully. A disaster could potentially happen if the scope of change is too
broad.
 Nonlocal and architectural changes can be carried out either gradually
(multiple actions) or in a “one-go” fashion (a single action).
 It is important to know when, how, and what to change.

Prepared by SH Tee 10
3. Architecture allows us to predict the
quality of a system
 It is possible to make quality predictions about a system based on an
evaluation of its architecture.
 This prediction can facilitate early design decisions.
 Architecture allows us to predict potential ad hoc problems and recurring
problems in a system.
 The earlier a problem is predicted, the easier and cheaper a solution can be
delivered.

Prepared by SH Tee 11
4. Architecture facilitates
communication among stakeholders.
 Architecture can be used by stakeholders for creating mutual understanding,
negotiating, forming consensus, and communicating with each other.
 Architecture is an abstraction. Different stakeholders (e.g., board of
directors, CEO, managers, executives, users) may have different perspectives
about a software system.
 E.g., a CEO may view an architecture from the perspective of revenue; a
manager may view it from the perspective of smooth business flow; an end
user of a software system may focus on the user-friendliness of a system.

Prepared by SH Tee 12
5. Architecture carries early design
decisions
 Software architecture is a manifestation of the early design decisions about a
system.
 Early design decisions are important for future development and maintenance
of a system.
 The early design decisions constrain the decisions that follow.
 Examples of some early design decisions carried by a software architecture:
 Will the system run on one processor or be distributed across various processors?
 Will the software be layered? If so, how many layers? And how each module is
categorized into each layer? How are the layers interrelated to each other?
 What database model will be used?
 Will components communicated synchronously or asynchronously?
Prepared by SH Tee 13
  What file transfer protocol will be used?
 What communication protocol will be used?
 What nature of software will be used? Open-source or proprietary?

Prepared by SH Tee 14
6. Defining constraints on an
implementation
 Any architectural design will impose constraints on an implementation.
Example, accuracy may be attained with the sacrifice of speed.
 Trade-offs (compromises) can be met by a careful architectural design.
 Trade-offs are always determined from both technical and business
requirements.

Prepared by SH Tee 15
7. An architecture may influence the
organizational structure
 The structure prescribed by an architecture always influence the structure of
the development project and the structure of the entire organization.
 The decomposition of an architecture can be used as the basis for the work-
breakdown structure in a company—different groups of labor are assigned to
different parts of the system on the basis of the modules and submodules.
 The work-breakdown structure would determine units of planning, scheduling,
budget, and manufacture in an organization.
 Architecture influences how different work groups are communicating.

Prepared by SH Tee 16
8. Architectures enable evolutionary
prototyping
 An architecture which has been defined can be prototyped as a skeletal
system before the system’s functionality has been created and implemented.
 A prototype may include some of the key infrastructure: how the elements
initialize, communicate, share data, report errors, and etc.
 Prototyping is a way to test ideas out.
 The prototype can be simulated or drawn.
 Prototyping also facilitates early decision making and error prediction, thus
reduce the potential risk associated with a software project.

Prepared by SH Tee 17
9. Architectures improve cost and
schedule estimates
 Architectures provide a guideline for the cost allocation, human resource
allocation, schedule estimates, and project monitoring.
 It ensures that the cost allocation and budget of the software system are
inline with the organization’s overall budget and costing.
 One of the duties of a software architect is to help the project manager
create cost and schedule estimates in the early stage of the project life
cycle.
 Cost estimates usually are based on bottom-up understanding of the software
system—modules and submodules are useful for this understanding.
 By decomposing an architecture into modules and submodules, and cost of
each component can be estimated more realistically.

Prepared by SH Tee 18
 Top-down cost estimates are required to understand the cost from the
perspective of system-system or software-software interaction (e.g., the cost
of deploying a database in connection to the existing network
instrastructure). Top-down cost estimate is a strategy that permits budget
planning that involves expensive software or hardware elements.
 The software architect needs to liaise with different stakeholders (e.g.,
project manager, finance officers, database administrators, etc) in cost and
budget planning for the software system.

Prepared by SH Tee 19
10. Architectures supply a transferrable
and reusable model.
 Reuse, reuse, and reuse—an important concept and practice in almost all
fields of software engineering.
 Reusing a software component can save time and money.
 Reuse the ‘template’ and customize it according to new needs or problems at
hand.
 Reusing without customizing to fit the problem is a poor software practice.
 Architecture reuse is a practice that uses the existing software architecture
(or part of it) in building a new software architecture (or parts).
 In code reuse, we may customize the variables. Similarly, architectural
components can be customized in architecture reuse.

Prepared by SH Tee 20
 Reusing a software architecture requires understanding of the system and
software requirement in the new problem situation. The system architect has
to recognize the similarity and differences between the ‘template’
architecture and the new architecture.
 If a template architecture cannot be used to address the issue in the new
problem situation, there is no point of reusing it.
 Reuse of an architecture requires experience and knowledge of a software
architect.
 Some reuse is good, some could be potentially bad. The architect has to
make a good choice on the appropriate reuse—what to be reuse, why to
reuse, and when to reuse? Or not to reuse at all.

Prepared by SH Tee 21
11. Architectures allow incorporation of
independently developed components
 Software elements are in most cases developed separately and independently
from each other.
 Architectures define the elements that can be incorporated into the system.
 An architecture also constrains possible addition, replacement, or removal of
these elements according to how they interact with their environment.
 For example, a data-analysis application may not be added to the software
system if there is no database in that system.
 An architecture also permits the software elements to be incorporated in an
efficient, cost-saving, and optimized way.
 Without an architecture, the software architect simply loses sight about the
big picture of the interconnection of various software elements.

Prepared by SH Tee 22
 An architecture is like a street map. It exhibits how different software
elements are connected, and their topological structure on the architecture.
 You cannot build a large house on a small land. Similarly, you cannot
incorporate a large number of software elements that is beyond the capacity
of an architecture.

Prepared by SH Tee 23
12. Architectures provide a basis for
training and communication
 An architecture provides a basis for new members in a software team to
understand the overall picture of the software system.
 An architecture also facilitates understanding of the current state of the
software system among software team members.
 An architecture provides a point of entry into any technical training (e.g.,
database configuration or network layout)
 An architecture facilitates communication among various stakeholders.

Prepared by SH Tee 24
Class activities: Critical thinking

 Software architecture facilitates early design decisions for future

Prepared by SH Tee 25