Chapter 3: Envisioning

Architecture
Software Architecture:
Definition
⚫ The software architecture of a program or computing
system is the set of structures of the system,
which comprise software elements, the externally
visible properties of those elements, and
the relationships among them.
⚫ 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.
 The Architecture Business
⚫Cycle
For decades, software designers have been taught
to build systems based exclusively on the
technical requirements.
⚫ Software architecture is a result of technical,
business,
and social influences.
⚫ Its existence, in turn, influences these
technical, business, and social environments.
⚫ This cycle of influences from the environment
to the architecture and back to the
environment is called the Architecture Business
 Where do Architectures Come
From?are influenced by:
Architectures
⚫ Stakeholders
⚫ each stakeholder has different concerns & goals, some
contradictory
⚫ architect often has to fill in the blanks and mediate the conflicts.
⚫ Development Organization
⚫ immediate business, long-term business, and organizational
(staff skills, schedule, & budget)
⚫ Background & Experience of the Architects
⚫ repeat good results, avoid duplicating disasters
⚫ The Technical Environment
⚫ standard industry practices or common SE techniques
 Influence of system stakeholders on the
architect

Developing Marketing End User Maintenanc

organization stakeholder Stakeholder e Customer
management organizatio
stakeholder n stakeholder
stakeholde
Low Cost, Neat features, Behaviour, r
Modifiability Low cost,
Keeping Short time to Performance,
people Security , Timely
market, Low Cost
employed Reliability, delivery,
Usability
not
change
d often
 Ramifications of
Influences
⚫ The properties required by the business and organizational
goals are seldom completely understood.
⚫ Architects need to know & understand the nature,
source, and priority of constraints on the
project as early as possible.
⚫ Architects must identify & actively engage the stakeholders
to solicit their needs & expectations.
⚫ Use architecture reviews & iterative prototyping.
⚫ In addition to technical skills, architects need to be skilled
in diplomacy, negotiation, and communication.
 What Do Architectures
Influence?
⚫ Architectures affect the factors that influence them, including:
⚫ The structure of the developing organization-Project
context
⚫ The goals of developing organization- Business context
⚫ Customer requirements for the next system-
Technical context
⚫ Thearchitect’s experience with subsequent
systems- Professional context.
⚫ The software engineering culture.(i.e technical
environment)
Influences on Architectu
the re
 Software Processes & the
ABC
⚫ Softwareprocess is the term given to the
organization, ritualization, and management of
software development activities.
⚫ Many activities are involved in creating
software architecture to realize design and then to
implement or manage the system.
 Software Architecture
Activities
⚫ Creating the business case for the system
⚫ Understanding the requirements from stakeholders
⚫ Creating or selecting the architecture via conceptual integrity
⚫ Communicating thearchitecture clearlyand
unambiguously to all of the stakeholders
⚫ Analyzing or evaluating the qualities of the architecture
⚫ Implementing the system based on the architecture
faithfully according to the structures and
interaction protocols constrained.
⚫ Ensuring that the implementation conforms to the architecture
 What makes a Good
⚫Architecture?
Given the same technical requirements for a system,
two different architects in two
different organizations, will produce different
architectures.
⚫ Then how to decide which is the right one ?
⚫ Rules of thumb/observations that should be followed
when designing an architecture.
⚫ These are divided into two clusters:
1. Process recommendations
2. Product(structural) recommendations.
 Rules of Thumb: Process
recommendations
⚫ The architecture should be product of a single architect or
small group of architects.
⚫ gather both the functional requirements and a well
specified, prioritized list of quality attributes.
⚫ be well documented, with at least one static view and one
dynamic
view.
⚫ be reviewed by the system’s stakeholders.
⚫ be analyzed for applicable quantitative measures and
formally evaluated for quality measures.
⚫ develop a “skeletal” system to facilitate incremental
implementation.
 Rules of Thumb: Product
⚫ recommendations
The architecture should feature well-defined modules based on
the
principles of information hiding and separation of concerns.
⚫ Each module should have a well-defined interface that
hides changeable aspects.
⚫ Quality attributes should be achieved using well-know
architectural tactics.
⚫ The architectureshould be independentof particular
versions of commercial products or tools.
⚫ Modules that produce data should be separate from modules
that consume data for increased modifiability.
 What is Software
Architecture?
⚫ Quite often shown as box-and-arrow
diagrams.
The system consists of four An underwater acoustic
•
elements.
Three of the elements— Prop Losssimulation
Model (MODP), Reverb Model
(MODR), and Noise Model (MODN)
— might have more in common
with each other than with the fourth
—Control Process (CP) because
they are positioned next to each other.
• All of the elements apparently have
some sort of relationship with each
other, since the diagram is fully
connected.
What’s
Missing?
⚫ What is the nature of the elements?
⚫ What are the responsibilities of the elements?
⚫ What is the significance of the connections?
⚫ What is the significance of the layout?

⚫ Unless we know precisely what the elements are & how

they cooperate to accomplish the purpose of the
system, this diagram is unhelpful!
 Definition
⚫ The Again
software architecture of a program or computing system
is the set of structures of the system, which comprise
software elements, the externally visible properties of
those elements, and the relationships between them.
⚫ Elements can be: objects, classes, functions,
processes, programs, libraries, databases, etc.
⚫ Relationships between elements: part of,
synchronization, function call, etc.
Externally Visible
Properties
⚫ The assumptions that other elements can make
of an element, such as:
⚫ its provided services,
⚫ performance characteristics,
⚫ fault handling,
⚫ shared resource usage,
⚫ etc.
 Definition Implications
 Architecture defines software elements.
 Systems can and do comprise more than one structure,
all are part of the architecture.
 Every computing system with software has an
architecture.
 The behavior of each element is part of the architecture
as far as its behavior can be observed or distinguished
from the point of view of another element.
 The definition doesn’t judge goodness or badness.
 Definition from IEEE

⚫ Architecture is the fundamental organization of a

system embodied in its components, their
relationships to each other, and to the environment,
and the principles guiding its design and
evolution [IEEE 1471].
 Useful Concepts
⚫ Three stages that capture characteristics of an architecture,
on the way from box-and-arrow to full software
architectures:
⚫ Architectural Patterns
⚫ Reference Models
⚫ Reference Architectures
Reference Model
Reference Software
Architecture Architecture
Architectural
Pattern
Architectural
Patterns
⚫ A description of element & relation types
together with a set of constraints on how they
may be used.
⚫ These constraints on an architecture define a set
or family of architectures.
⚫ For example, client-server is a common
architectural pattern.
⚫ Client and server are two element types,
and their coordination is described in terms of the
protocol that the server uses to
communicate with each of its clients.
Value of
Patterns
⚫ They exhibit known quality attributes, and are a reuse
of experience.
⚫ Some patterns solve performance problems, others
apply to high-security systems, or high-availability
goals.
⚫ Choosing an architectural pattern is often the
architect’s
first major design decision.
⚫ Also referred to as architectural styles.
 Reference Models
⚫ A division of functionality together with data flow between
the pieces.
⚫ A standard decomposition of a known problem into parts
that cooperatively solve the problem.
⚫ They arise from experience, and are thus a
characteristic of
mature domains.
⚫ Examples:
⚫ Compilers: lexical analysis, syntactic analysis, semantic
analysis, optimization, code generation
⚫ Networks: the OSI reference model
 Reference Architectures
⚫ A reference model mapped onto software elements and
the data flows between them.
⚫ The elements must cooperatively implement
the functionality defined in the reference model.
⚫ A reference model defines a way of decomposing
functionalities
⚫ A reference architecture defines a way of mapping a functionalities
on subsystems/architectural components
⚫ The mapping may be 1-1, but an element may implement
a part of a function or several functions.
 Why is Architecture
Important?
⚫ Three fundamental reasons from a technical perspective:
⚫ Communication among stakeholders: a basis for
mutual understanding, negotiation, & consensus
⚫ User: reliable and available
⚫ Customer: on schedule and to budget;
⚫ Manager: cost and schedule, teams to work
largely independently
⚫ Architect: achieve all of those goals
⚫ Earlydesign decisions: earliest point at which
decisions can be analyzed
⚫ Transferable abstractionof a system: can promote large-
25 scale reuse
Early design
decisions
⚫ The architecture:
⚫ defines constraints on implementation
⚫ dictates organizational structure
⚫ inhibits or enables a system’s quality attributes
⚫ Predicting System Qualities by Studying the
Architecture
⚫ easier to reason about and manage change
⚫ helps in evolutionary prototyping
⚫ enables more accurate cost & schedule estimates
Architecture as a transferable reusable model
⚫ The earlier in the life cycle re-use is applied, the greater
the benefit that can be achieved.
 Not only code can be re-used but so can the requirements
that led to the architecture in the first place, as well
as the experience of building the re-used architecture.
 When architectural decisions can be re-used across
multiple systems, all of the early decision consequences we
just described are also transferred.
Structures and
Views
⚫ A view is a representation of a coherent set of
architectural elements, consisting of:
⚫ a set of elements
⚫ the relationships among them
⚫ A structure is the set of elements itself, as they exist
in software or hardware.
⚫ Often used interchangeably, text will distinguish.
 Groups of Architectural
Structures
Architectural structures can by and large be divided into
three groups, depending on the broad nature of the
elements they show.
⚫ Module structures: are static structures, in that they focus on the way
the
system's functionality is divided up and assigned to implementation teams
⚫ Eg. Decomposition, uses, layered, class
⚫ Component-and-connector structures
⚫ runtime components (principal units of computation) and
connectors (communication vehicles among components)
⚫ Eg. Process (communication), concurrency, shared data (repository), client-
server
⚫ Allocation structures: show relationships between software
29 elements & external environments (system's organizational, developmental,
⚫ Eg.Work assignment, deployment,
Three Types of Structures
⚫ Correspond to the three broad types of decisions
that architectural design involves:
⚫ How is the system to be structured as a set of code
units (modules?)
⚫ How is the system to be structured as a set of elements
that have runtime behavior (components) and
interactions (connectors)?
⚫ How is the system to relate to non-software structures in its
environment (i.e., CPUs, file systems, networks,
development teams, etc. - allocation)?
Common software architecture
structures
 Non-functional
Properties
⚫ Each structure provides a method for reasoning about some
of the relevant quality attributes, for example:
⚫ the uses structure, must be engineered to build a system
that can be easily extended or contracted
⚫ the process structure is engineered to eliminate deadlock
and reduce bottlenecks
⚫ the module decomposition structure is engineered to
produce modifiable systems, etc.
⚫ Each structure provides the architect with a
different view into the system & a different
32 leverage point for design.
 Three Kinds of
Module :
Structures
• Decomposition: units are related by “is a sub module of ”, larger modules
are
composed of smaller ones
• Uses: relation is “uses” (calls, passes information to, etc).
• Layered: is special case of uses, layer n can only use modules from layers <n
• Class: generalization, relation “inherits from”
Component :
• Process: units are processes, connected by communication or
synchronization
• Concurrency: to determine opportunities for parallelism (connector =
logical thread)
• Shared data: shows how data is produced and consumed
•Client-server: cooperating clients and
servers Allocation :
• Deployment:
33 Work assignment:
how who
software
is doing
is assigned to
• hardware
what elements
 Useful module structures
⚫ Decomposition
structure:
 …Useful module structures
⚫ Uses
structure:
 …Useful module structures
⚫ Layer
structure:
 …Useful module structures
⚫ Class (or generalization)
structure:
 …Useful module structures
⚫ Data
model:
 …Useful module structures
⚫ Module structures help answer questions:
⚫ What is the primary functional responsibility assigned to each
module?
⚫ What other software elements is a module allowed to use?
⚫ What other software does it actually use and depend on?
⚫ What modules are related to other modules by generalization
or specialization (i.e., inheritance) relationships?
⚫ Examining a system's module structures is an excellent way
to reason about a system's modifiability.
 Useful C&C
structures
⚫ Service structure:
 Units: services, ESB, registry

 Relations: runs concurrently

with, may run concurrently
with, excludes, precedes, etc.

 Used for: scheduling analysis,

performance analysis

Affected attributes
include: Interoperability,
modifiability
…Useful C&C structures
 …Useful C&C structures
⚫ C&C structures help answer questions:
⚫ What are the major executing components and how do they interact at
runtime?
⚫ What are the major shared data stores?
⚫ Which parts of the system are replicated?
⚫ How does data progress through the system?
⚫ What parts of the system can run in parallel?
⚫ Can the system's structure change as it executes and, if so, how?
⚫ They are crucially important for reasoning about the
system's runtime properties such as performance,
security, availability.
 Useful allocation structures
⚫ Deployment
structure:
 …Useful allocation structures
⚫ Implementation structure:
Units: software elements
(usually modules), file
structure
 Relations: stored in
Used for: configuration
control, integration, test
activities
 Affected attributes
include:
development efficiency
 …Useful allocation structures
⚫ Work assignment
structure:
 …Useful allocation structures
⚫ Allocation structures help answer questions:
⚫ What processor does each software element execute on?
⚫ In what directories or files is each element stored during development, testing,
and system building?
⚫ What is the assignment of each software element to development teams?
 Relationship between
structures
⚫ Each of these structures providesa different perspectiveand
design handle on a system.
⚫ They are not independent. Elements of one structure will be related
to elements of other structures.
 Relating Structures to Each
Other
⚫ Although the structures give different system perspectives,
they are not independent.
⚫ Elements of one structure are related to elements in
another, and we need to reason about these
relationships.
⚫ For example, a module in a decomposition structure may map to
one, part of one, or several, components in a component-and-
connector structure at runtime.
⚫ In general, mappings are many-many.
 Choosing Structures
⚫ Kruchten’s Four + One Views:
⚫ Logical View –concerned with the functionality that the system provides to
end- users. UML diagrams used to represent the logical view include, class
diagrams, and state diagrams.
⚫ elements are “key abstractions” that are objects or classes in OO.
⚫ This is a module view.
⚫ Process View–deals with the dynamic aspects of the system, explains the
system processes and how they communicate, and focuses on the runtime
behavior of the system.
⚫ addresses concurrency, distribution, integrators, performance, and scalability,
etc. UML diagrams to represent process view include the activity diagram.
⚫ This is a C&C view.
 ... Four + One
Views
⚫ Development View – illustrates a system from a programmer's perspective and is
concerned with software management.This view is also known as the
implementation view. It uses the UML Component diagram to describe system
components. UML Diagrams used to represent the development view
include the Package diagram
⚫ shows organization of software modules, libraries, subsystems, and units
of development. This is an allocation view.
⚫ Physical View – depicts the system from a system engineer's point of view. It is
concerned with the topology of software components on the physical layer as
well as the physical connections between these components.This view is also
known as the deployment view. UML diagrams used to represent the
physical view include the deployment diagram.
⚫ maps other elements onto processing & communication nodes, also an allocation
view, but usually referred to specifically as the deployment view.
 ... Four + One
Views
⚫ /cenarios(One view)- The description of an architecture is
illustrated using a small set of use cases, or scenarios, which
become a fifth view.
⚫ The scenarios describe sequences of interactions between
objects and between processes.
⚫ They are used to identify architectural elements and to illustrate
and validate the architecture design.They also serve as a
starting point for tests of an architecture prototype.
⚫ This view is also known as the use case view.
... 4+1 Architectural View
Model
... 4+1 Architectural View
Model