What is Software

Architecture?

Some slides based Len Bass, Paul Clements, Rick Kazman, under Creative Commons Attribution License
Architecture or Not?

Game Engine
(GE)

Score Model Player Model Reward Model

(SM) (PM) (RM)
Why Can the Previous Diagram Be Called an Architecture?

• It identifies components
• It indicates relationships
among the components.
What Does this Picture Fail to Show?

• The nature of the elements

• The responsibilities of the elements
• The significance of the connections
• The significance of the layout
Software Architecture Specifics
• Architecture defines software elements.
• It contains information about how the elements relate to each other.
• It is an abstraction
• Architecture is a not a single structure, but a collection of structures
• All computing systems have architectures.
• The behavior of each element is part of the architecture.
• Architectures can be good or bad.
Definition of a Software Architecture
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.
Example

Apache Hive is a data warehouse software project built on top of Apache Hadoop
for providing data query and analysis. https://en.wikipedia.org/wiki/Apache_Hive
Moodle/Mue
le Logical
View
Process View (Moodle/Muele)
Architecture Is a Set of Software Structures
• A structure is a set of elements held together by a relation.
• Software systems are composed of many structures, and no single
structure holds claim to being the architecture.
• Architectural structures can be divided into three groups
• Module structures – How is the system to be structured as a set of code
units?
• Component-and-connector structures – How is the system to be structured as
a set of elements that have running behavior and interactions?
• Allocation structures – How is the system to relate to nonsoftware structures
in its environment?
Groups of Software Architecture Structures

Component-
Module And-Connector Allocation

Client- Shared
Decomposition Class Server Process
Data
Uses Deployment
Concurrency

Implementation
Layered Work
Assignment
Module Structures
• Module structures document
how the system is to be
structured/broken down
• Elements are modules of some
kind
§ perhaps classes, or layers
• Modules are assigned areas of
functional responsibility
§ less emphasis on how the
software performs at runtime
• Module structures allow us to
answers many questions
Module-Based Structures

• Decomposition – the elements are modules related by the “is

a submodule of” relation.
• Uses – the units are modules, procedures or resources on the
interfaces of modules related by the “uses” relation.
• Layered – when the uses relations are controlled in a
particular way a system of layers emerges in which layer is a
coherent set of related functionality.
Component-and-connector Structures
• Component-and-connector
structures document runtime
behavior (components) and
interactions (connectors).
• Elements are runtime components
such as services, peers, clients,
servers, filters
• Connectors are the communication
vehicles among components,
§ For example call-return, process
synchronization, pipes, or others.
• Component-and-connector views
help us answer many questions
Allocation Structures
• Allocation structures describe the mapping from software structures to the
system’s environments
• organizational
• developmental
• installation
• Execution

• Allocation structures show the relationship between the software elements

and elements in one or more external environments in which the software
is created and executed.

• Allocation views help us answer many questions:

Which Structures are Architectural?
• A structure is architectural if it supports reasoning about the system
and the system’s properties.
• The reasoning should be about an attribute of the system that is
important to some stakeholder.
Architecture is an Abstraction
• An architecture comprises software
elements and how the elements
relate to each other.
• An architecture selects certain details
and suppresses others.
• An architecture specifically omits
certain information about elements
that is not useful for reasoning about
the system.
• It omits information that has no
consequences outside of a single
element.
• Private details of elements—details
having to do solely with internal
implementation—are not
architectural.
Every System has a Software Architecture
• Every system comprises elements and relations among them to
support some type of reasoning.
• So every system has an architecture, but the architecture may not be
known to anyone
Architecture Includes Behavior
• The behavior of each element is part of the architecture insofar as
that behavior can be used to reason about the system.
• This behavior embodies how elements interact with each other
• The exact behavior for all components is not required in all
circumstances.
• fine-grained and below the architect’s level of concern.
• Should be included if the element’s behavior:
§ influences another element or
§ influences the acceptability of the system as a whole
Structures and Views
• A view is a representation of a coherent set of architectural elements, as
written by and read by system stakeholders.
• A view consists of a representation of a set of elements and the relations among
them.
• A structure is the set of elements itself, as they exist in software or
hardware.
• In short, a view is a representation of a structure.
• For example, a module structure is the set of the system’s modules and their
organization.
• A module view is the representation of that structure, documented according to a
template in a chosen notation, and used by some system stakeholders.
• Architects design structures. They use views to document those structures.
Structures/Views Provide Insight
• Structures play such an important role in our perspective on software
architecture because of the analytical and engineering power they hold.
• Each structure provides a perspective for reasoning about some of the
relevant quality attributes.
• For example:
• The module structure, which embodies what modules use what other modules, is
strongly tied to the ease with which a system can be extended or contracted.
• The concurrency structure, which embodies parallelism within the system, is strongly
tied to the ease with which a system can be made free of deadlock and performance
bottlenecks.
• The deployment structure is strongly tied to the achievement of performance,
availability, and security goals.
• And so forth.
Some Useful Module Structures
•Decomposition structure
§ The units are modules that are related to each other by the is-a-
submodule-of relation.
•Uses structure.
§ A unit of software uses another if the correctness of the first requires
the presence of a correctly functioning version (as opposed to a stub)
of the second.
•Layer structure
§ A layer is an abstract “virtual machine” that provides a cohesive set of
services through a managed interface.
Some Useful Module Structures
•Class (or generalization) structure
• The module units in this structure are called classes.
• The relation is inherits from or is an instance of.
• This view supports reasoning about collections of similar behavior or
capability
• e.g.,the classes that other classes inherit from and parameterized differences
• The class structure allows one to reason about reuse and the
incremental addition of functionality.
• If any documentation exists for a project that has followed an object-
oriented analysis and design process, it is typically this structure.
More Useful Module Structures
•Class (or generalization) structure
§ The relation is inherits from or is an instance of.
•Data model
• The data model describes the static information structure in terms of
data entities and their relationships.
• For example, in a banking system, entities will typically include Account,
Customer, and Loan.
• Account has several attributes, such as account number, type (savings or
checking), status, and current balance.
Some Useful C&C Structures
• The relation in all component-and-connector structures is
attachment, showing how the components and the connectors
are hooked together.
• The connectors can be familiar constructs such as “invokes.”
• Useful C&C structures include:
• Service structure
• The units are services that interoperate with each other by service
coordination mechanisms such as SOAP.
• The service structure helps to engineer a system composed of components
that may have been developed anonymously and independently of each
other.
• Concurrency structure
• This structure helps determine opportunities for parallelism and the
locations where resource contention may occur.
• The units are components
• The connectors are their communication mechanisms.
• The components are arranged into logical threads.
Some Useful Allocation Structures
•Deployment structure
• The deployment structure shows how software is assigned to hardware
processing and communication elements.
• The elements are software elements (usually a process from a C&C view),
hardware entities (processors), and communication pathways.
• Relations are allocated-to, showing on which physical units the software
elements reside, and migrates-to if the allocation is dynamic.
• This structure can be used to reason about performance, data integrity,
security, and availability.
• It is of particular interest in distributed and parallel systems.
Some Useful Allocation Structures
•Implementation structure
§ This structure shows how software elements (usually modules) are mapped to the
file structure(s) in the system’s development, integration, or configuration control
environments.
§ This is critical for the management of development activities and build processes.
•Work assignment structure
§ This structure assigns responsibility for implementing and integrating the modules to
the teams who will carry it out.
§ Having a work assignment structure be part of the architecture makes it clear that
the decision about who does the work has architectural as well as management
implications.
§ The architect will know the expertise required on each team.
§ This structure will also determine the major communication pathways among the
teams: regular teleconferences, wikis, email lists, and so forth.
Relating Structures to Each Other
• Elements of one structure will be related to elements of other
structures, and we need to reason about these relations.
• A module in a decomposition structure may be manifested as one, part of
one, or several components in one of the component-and-connector
structures.
• In general, mappings between structures are many to many.
Modules vs. Components
Relating Structures to Each Other
• Each of these structures provides a different perspective and design
handle on a system.
• Each is valid and potentially useful in its own right
• They are not independent but highly interrelated.
• Often the module structure is dominant, but not always.
Relating Structures to Each Other (Cont’d)

• Not all systems warrant consideration of many architectural

structures.
• The larger the systems the more dramatic the differences between
these structures tend to be.
• Structures represent the primary engineering leverage point for
satisfying quality attributes.
• Multiple structures represent a powerful separation-of-concerns
approach for creating the architecture.
Which Structures to Choose?

• Kruchten’s “four
plus one”
approach
recommends
four views
(structures)
Architectural Patterns, Reference Models, and
Reference Architectures
Reference Models
• A reference model is a division of
functionality together with data
flows between the pieces.
• For example a database
management system might have a
reference model.
• It is a standard division of a known
problem into parts that
cooperatively solve the problem.
Reference Architecture
• A reference architecture is
a reference model mapped
onto software elements
and the data flows between
them.
• The software elements
cooperatively implement
the functionality defined in
the reference model.
• That is; it maps the
functionality of a reference
model onto a system
decomposition.
From Models and Patterns to Architecture

Reference
Model

Reference Software
Architecture Architecture

Architectural
Pattern
Architectural Patterns
• Architectural elements can be composed in ways that solve particular problems.
• The compositions have been found useful over time, and over many different domains
• They have been documented and disseminated.
• These compositions of architectural elements, called architectural patterns.
• Patterns provide packaged strategies for solving some of the problems facing a system.
• An architectural pattern delineates the element types and their forms of
interaction used in solving the problem.

• A common module type pattern is the Layered pattern.

• When the uses relation among software elements is strictly unidirectional, a system of layers
emerges.
• A layer is a coherent set of related functionality.
• Many variations of this pattern, lessening the structural restriction, occur in practice.
Architectural Patterns
•Common component-and-connector type
patterns:
• Shared-data (or repository) pattern.
• This pattern comprises components and
connectors that create, store, and access
persistent data.
• The repository usually takes the form of a
(commercial) database.
• The connectors are protocols for managing the
data, such as SQL.
• Client-server pattern.
• The components are the clients and the servers.
• The connectors are protocols and messages they
share among each other to carry out the
system’s work.
Why We need software architectures
Software Architecture Issues
• Structural issues
• Organization of the systems as in the composition of
components
• Global control structures
• Protocols for communication, synchronization and
access
• Assignment of functionality to design elements
• Composition of design elements
• Physical distribution
• Scaling and performance
• Quality Attributes
Quality Attributes
• Requirements –
• Functional requirements
• Non-functional requirements == Quality Attributes
• Examples:
§ Availability
§ Usability
§ Security
§ Performance
§ Latency
§ throughput
Describing Software Architectures

• Several practices for describing architectures are still

• typically informal
• Idiosyncratic
• Ad hoc
• Typically box and line diagrams with accompanying prose
Advantages of explicit architecture
• System Analysis
• Analysis of system features before they are built
• cost saving and risks mitigation
• Large-scale reuse
• the architecture(or part of it) may be reusable across a
range of systems
• Design designs —> save design costs+less risks
• Stakeholders communication
• Architecture may be used as a focus of discussion by
system stakeholders
• Early design decisions reasoning, when it is still
relatively easy to adapt
Other Architectures
• System architecture
• Enterprise architecture
• Business architecture
• Technical architecture
• Product line architecture
Summary
• 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.
• A structure is a set of elements and the relations among them.
• A view is a representation of a coherent set of architectural elements.
A view is a representation of one or more structures.
Summary
• There are three categories of structures:
• Module structures show how a system is to be structured as a set of code or data units that have to be
constructed or procured.
• Component-and-connector structures show how the system is to be structured as a set of elements that have
runtime behavior (components) and interactions (connectors).
• Allocation structures show how the system will relate to nonsoftware structures in its environment (such as
CPUs, file systems, networks, development teams, etc.).
• Structures represent the primary engineering leverage points of an
architecture.
• Every system has a software architecture, but this architecture may be
documented and disseminated, or it may not be.
• There is no such thing as an inherently good or bad architecture.
Architectures are either more or less fit for some purpose.