SOFTWARE DESIGN AND ARCHITECTURE

LECTURE 1-3
Rabia Iftikhar Disclaimer:
presentation
The
have
contents
been
of
taken
this
from
multiple sources, i.e. Books, Research
rabia.iftikhar@faculty.muet.edu.pk articles, Thesis publications, and
websites.
 Fair Use Notice

The material used in this presentation i.e., pictures/graphs/text, etc. is solely

intended for educational/teaching purpose, offered free of cost to the students for
use under special circumstances of Online Education due to COVID-19 Lockdown
situation and may include copyrighted material - the use of which may not have
been specifically authorised by Copyright Owners. It’s application constitutes Fair
Use of any such copyrighted material as provided in globally accepted law of many
countries. The contents of presentations are intended only for the attendees of the
class being conducted by the presenter.
OUTLINES
Introduction
Architecture Business Cycle
Architectures Business Cycle and Software Processes
Good and bad architectures
INTRODUCTION
For decades, software designers have been taught to build systems based exclusively on the
technical requirements.
Requirements beget design, which begets system.
Modern software development methods provide all sorts of feedback loops from designer to
analyst. But they still make the implicit assumption that design is a product of the system's
technical requirements, period.
Architecture has emerged as a crucial part of the design process.
Software architecture encompasses the structures of large software systems. The architectural
view of a system is abstract, distilling away details of implementation, algorithm, and data
representation and concentrating on the behaviour and interaction of "black box" elements.
INTRODUCTION
A software architecture is developed as the first step toward designing a system that has a
collection of desired properties.
The software architecture of a program or computing system is the structure or structures of
the system, which comprise software elements, the externally visible properties of those
elements, and the relationships among them.
Architecture serves as an important communication, reasoning, analysis, and growth tool for
systems.
In a nutshell, if you know the requirements for a system, you can build the architecture for it.
INTRODUCTION
Where Do Architectures Come From?

An architecture is the result of a set of business and technical decisions.

There are many influences at work in its design, and the realization of these influences will
change depending on the environment in which the architecture is required to perform.
An architect designing a system for which the real-time deadlines are believed to be tight will make one set of
design choices; the same architect, designing a similar system in which the deadlines can be easily satisfied, will
make different choices. And the same architect, designing a non-real-time system, is likely to make quite different
choices still.
Even with the same requirements, hardware, support software, and human resources available, an architect
designing a system today is likely to design a different system than might have been designed five years ago.
A SOFTWARE ARCHITECT?
Software Architecture Design
Team

Application

Architecture
Realization
Software
Architecture
STRUCTURE MATTERS
Dijkstra 1968:
◦ “…Correct arrangement of the structure of the software systems before programming…”
◦ Layered structure for easier development.

Parnas 1972:
◦ “… selected criteria for the decomposition of the system impact the structure of the programs and
several design principles must be followed to provide a good structure…”
◦ Examples: separation of concerns, hierarchical structures, program families (reuse).
 EVOLUTION OF SOFTWARE
SYSTEMS
Software problems have changed in nature(algorithmic to general purpose applications)
increased complexity to millions lines of code
It has now become hard/impossible to develop system without architecture
Software Architecture Definitions
DEFINITIONS FROM THE CLASS…
Basic artifact shown to the customers and made from the requirements.
Breaking down of the system into components
And describing the interrelations between the components
A prototype of the system
Identify the components of the system along with the interaction between them
Its an abstraction of the system
Earliest artifact
SOFTWARE ARCHITECTURE- Booch
1991
“The logical and physical structure of a system, forged by all the strategic and tactical decisions
applied during development.”
Architecture is the high level structure of a system.
SOFTWARE ARCHITECTURE- Perry
and Wolf 92
 Perry and Wolf distinguish between processing elements, data elements, and connecting
elements, and this taxonomy of architectural elements largely persists through most other
definitions and approaches.
SOFTWARE ARCHITECTURE- IEEE
“Software architecture is the fundamental organization of a system, embodied in its
components, their relationships to each other and their environment, and the principles
governing its design and evolution.”
SOFTWARE ARCHITECTURE –
BASS, CLEMENTS, KAZMAN
The software architecture of a program or computing system is the structure or
structures of the system, which comprise software elements, the externally visible
properties of those elements and the relationships among them.
WHAT IS SOFTWARE DESIGN
Software design is the process by which we create a specification of a software artifact, using a
set of primitive components and subject to constraints.
The process of defining the architecture, components, interfaces, and other characteristics of a
system or component.
DIFFERENCE
Software architecture deals with high level concepts without regard to any implementation
details. Software design on the other hand takes high level concepts and applies concrete details
so that software can be implemented.
Every architectural work is a kind of design, but the reverse is not true
It's about addressing those architecturally significant requirements (the "what") that will
drive (and constrain) the "how" (the design).
What does SA address?
Complexity of software systems increased
 Developing software: hundreds/ thousands person-years
 Many software systems: complex as skyscrapers

 Designing software
 Beyond algorithms/ data structures of the computation
 New kind of problem: overall system structure

An important criteria for building complex software is: does it have a good SA, understood by
stakeholders and developers?
SA
Provides a design plan of a system
 Blueprint
 Implies purpose

 Is an abstraction that helps in managing the complexity of a system

 Software architects are limited by
 Lack of standardized ways to represent architecture
 Lack of analysis methods to predict whether an architecture will result in an implementation that
meets the requirements
SA as a design plan
 Structural plan that describes
 The elements of a system
 How they fit together
 How they work together to fulfill requirements

 Used as blueprint during development process

 Used to negotiate system requirements
 Used to set expectations with
 Customers
 Marketing/management personnel
 SA as a design plan
Project manager uses the design plan as input to the project plan.
SA as an abstraction
SA not a comprehensive decomposition of a system
Implementation details abstracted away, encapsulated into elements of the SA

SA should describe elements at a coarse level of granularity

How elements fulfill the requirements
Element interactions
Design Tradeoffs
Resolving tradeoffs may lead to
 Sacrificing some desired qualities
 E.g., simplicity

 Compromising some requirements

 Renegotiating
 Reducing portability, modifiability, etc
SA goal
One should strive for a good architecture
 When system is implemented according to the architecture, it meets its requirements and resource
budget
 It is possible to implement system according to architecture

 Not good enough when

 Not explicit or not comprehensive or not consistent or not understandable
TERMINOLOGY
1. Architectural style/pattern:
Defines element types and how they interact together with a set of constraints
Sometimes defines a mapping of functionality to architectural elements
An architectural style determines the vocabulary of components and connectors that can be used in
instances of that style, together with a set of constraints on how they can be combined. These can
include topological constraints on architectural descriptions (e.g., no cycles). Other constraints—say,
having to do with execution semantics—might also be part of the style definition
E.g. Client Server Architectural Pattern.
The following table lists the major areas of focus and the corresponding architectural styles.
TERMINOLOGY
2. Reference/domain specific architecture:
Defines element types and how they interact
They apply to a particular domain
They define how the domain functionality is mapped to architectural(software) elements.
TERMINOLOGY
3. Product line architecture:
A software product line is a set of software-intensive systems that share a common, managed set of
features satisfying the specific needs of a particular market segment or mission and that are developed
from a common set of core assets in a prescribed way.
Applies to a set of products within a company
Defines element types, how they interact, how the product functionality is mapped to them
May also define some of the instances of the architectural Elements. E.g., error-reporting components
would be common to many products of the product line
TERMINOLOGY
4. Software Architecture:
Applies to one system
Describes element types, how they interact, how the product functionality is mapped to them
Describes the instances that exist in the system
Level of specificity needed to design a system
TERMINOLOGY
5. Architecture description language:
Gives notation for architectural elements
An Architecture Description Language (ADL) is a language designed to model a system.
They have often graphical as well as plain text syntax
Mostly used in research communities
In theory: architects can use an ADL to describe any of the 1-4 terms
In practice: not all ADLs support all the 1-4 terms
Some ADLs have accompanying tools
E.g. AADL, UML, etc.
QUESTION
What do you think would happen if same requirements were given to two different architects
of different organizations?
Architecture Business Cycle
Software architecture is a result of technical, business, and social influences. Its existence in
turn affects the technical, business, and social environments that subsequently influence future
architectures. We call this cycle of influences, from the environment to the architecture and
back to the environment, the ABC.
Organizational goals-> requirements->SA-> systems-> future new organizational goals-> …
 We begin building the ABC by identifying the influences to and from architectures.
Architectures are influenced by:
◦ System Stakeholders
◦ Developing Organization
◦ Experience of Architects
◦ Technical Environment
Architecture Business Cycle
Architecture Business Cycle
Architecture affects following factors
◦ Structure of the developing organization
◦ Goals of the developing organization
◦ Customer requirements for the next system
◦ Architect’s experience for subsequent systems
◦ Technical Environment
 Architectures Business Cycle and
Software Processes
Software process is the term given to the organization, ritualization, and management of software
development activities.
What activities are involved in creating a software architecture, using that architecture to realize a design,
and then implementing or managing the evolution of a target system or application? These activities
include the following:
Creating the business case for the system
Understanding the requirements
Creating or selecting the architecture
Documenting and communicating the architecture
Analysing or evaluating the architecture
Implementing the system based on the architecture
Ensuring that the implementation conforms to the architecture

As indicated in the structure of the ABC, architecture activities have comprehensive feedback
relationships with each other.
 Good and Bad Architectures
What Makes a "Good" Architecture?
If it is true that, given the same technical requirements for a system, two different architects in different organizations
will produce different architectures, how can we determine if either one of them is the right one?
There is no such thing as an inherently good or bad architecture. Architectures are either more or less fit for some
stated purpose.
 A distributed three-tier client-server architecture may be just the ticket for a large enterprise's financial management system but
completely wrong for an avionics application.
An architecture carefully crafted to achieve high modifiability does not make sense for a throw-away prototype.

We divide our observations into two clusters:

 process recommendations and
 product (or structural) recommendations.
Good and Bad Architectures
Process Recommendations
The architecture should be the product of a single architect or a small group of architects with an identified leader.

The architect (or architecture team) should have the functional requirements for the system and an articulated,
prioritized list of quality attributes (such as security or modifiability) that the architecture is expected to satisfy.

The architecture should be well documented, with at least one static view and one dynamic view, using an agreed-on
notation that all stakeholders can understand with a minimum of effort.

The architecture should be circulated to the system's stakeholders, who should be actively involved in its review.

The architecture should be analyzed for applicable quantitative measures (such as maximum throughput) and
formally evaluated for quality attributes before it is too late to make changes to it.
Good and Bad Architectures
Process Recommendations
The architecture should lend itself to incremental implementation via the creation of a "skeletal" system
in which the communication paths are exercised but which at first has minimal functionality. This
skeletal system can then be used to "grow" the system incrementally, easing the integration and testing
efforts.

The architecture should result in a specific (and small) set of resource contention areas, the resolution
of which is clearly specified, circulated, and maintained.
Good and Bad Architectures
Product Recommendations
The architecture should feature well-defined modules whose functional responsibilities are allocated on
the principles of information hiding and separation of concerns.

Each module should have a well-defined interface that encapsulates or "hides" changeable aspects
(such as implementation strategies and data structure choices) from other software that uses its
facilities. These interfaces should allow their respective development teams to work largely
independently of each other.

Quality attributes should be achieved using well-known architectural tactics specific to each attribute.

The architecture should never depend on a particular version of a commercial product or tool. If it
depends upon a particular commercial product, it should be structured such that changing to a different
product is straightforward and inexpensive.
 Good and Bad Architectures
Product Recommendations
Modules that produce data should be separate from modules that consume data. This tends to increase modifiability
because changes are often confined to either the production or the consumption side of data. If new data is added,
both sides will have to change, but the separation allows for a staged (incremental) upgrade.

For parallel-processing systems, the architecture should feature well-defined processes or tasks that do not
necessarily mirror the module decomposition structure.

Every task or process should be written so that its assignment to a specific processor can be easily changed, perhaps
even at runtime.

The architecture should feature a small number of simple interaction patterns. That is, the system should do the
same things in the same way throughout. This will aid in understandability, reduce development time, increase
reliability, and enhance modifiability. It will also show conceptual integrity in the architecture, which, while not
measurable, leads to smooth development.
Why is Software Architecture important?
Architecture is the vehicle for stakeholder communication
Architecture manifests the earliest set of design decisions
 Constraints on implementation
 Dictates organizational structure
 Inhibits or enable quality attributes

Architecture is a transferable abstraction of a system

 Product lines share a common architecture
 Basis for training
ARCHITECTURAL EVALUATION
Better to evaluate architecture than the whole system.
Provides a means to communicate and negotiate with customers
Architecture drives the cost
Ensures high quality documentation of the architecture
Enables discoveries of architectural reuse 
Other points of view about SA
Architecture is high-level design

Architecture is overall structure of the system

Architecture is the structure, including the principles and guidelines governing their design and
evolution over time

Architecture is components and connectors