Ch 1: The Architecture Business Cycle
• For decades, software designers have been taught to
build systems based exclusively on the technical
• Software architecture encompasses the structures of
large software systems:
– abstract view
– eliminates details of implementation, algorithm, & data
– concentrates on the behavior & interaction of “black box”
• 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 Business Cycle (ABC)
• Quick Exercise :
– What is the relationship of a system’s software
architecture to the environment in which the system
will be constructed and exist?
Architecture Business Cycle (ABC)
– Software architecture is a result of technical, business,
and social influences.
– In turn, it affects each of these environments.
Where do Architectures Come From?
• The result of a set of business and technical
• In any development effort, the requirements make
explicit some - but only some - of the desired
properties of the final system.
• Failure to satisfy non-documented constraints can
cause as many problems as if it functioned poorly.
Figure 1.2 Influence of
stakeholders on the architect
– each stakeholder has different concerns & goals, some
• 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
Ramifications of Influences
• Almost never are the properties required by the
business & organizational goals consciously
understood, let alone fully articulated.
– 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.
Book’s Main Message
• Architectures affect the factors that
– The relationships among business goals,
product requirements, architects’ experience,
architectures, and fielded systems form a cycle
with feedback loops that a business can
• to handle growth, to expand enterprise area, and to
take advantage of previous investments in
architecture & system building.
Software Processes & the ABC
• 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?
• How do you
– Design one?
– Build one?
– Modify one?
• Creating the Business Case for the System
• Understanding the Requirements
• Creating or Selecting the Architecture
• Communicating the Architecture
• Analyzing or Evaluating the Architecture
• Implementing Based on the Architecture
• Ensuring Conformance to an Architecture
What makes a Good Architecture?
• No such thing as an inherently good or bad
• Architectures are more or less fit for some stated
• Architectures can be evaluated - one of the great
benefits of paying attention to them - but only in
the context of specific goals.
• Rules of Thumb: process & product (structural)
Rules of Thumb (pp 15 & 16)
• Process Recommendations:
– include functional requirements and a prioritized list of
quality attributes the system must satisfy
– analyze & formally evaluate before it is too late to change
• Product Recommendations:
– well-defined modules using principles of information
hiding & separation of concerns
– separate modules that produce data from those that
consume data to increase modifiability & staged upgrades
– write tasks or processes to allow easy reallocation, perhaps
Ch 2: What is Software Architecture?
• Quite often shown as box-and-arrow diagrams.
Prop Loss Reverb Noise
Model Model Model
(MODP) (MODR) (MODN)
• 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!
• 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, an
the relationships between them.
• We see the elements (CP, MODP, MODR,
MODN), but what properties do they or their
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,
1 - architecture defines software elements.
2 - systems can and do comprise more than one
structure, all are part of the architecture.
3 - every computing system with software has an
4 - the behavior of each element is part of the
architecture as far as its behavior can be observed or
discerned from the point of view of another element.
5 - the definition doesn’t judge goodness or badness.
• Three stages that capture characteristics of an
architecture, on the way from box-and-arrow to full
– Architectural Patterns
– Reference Models
– Reference Architectures
• 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, the client-server pattern has 2 element
types (?); their relationship is a protocol that the server
uses to communicate with each of its clients, the clients
don’t communicate directly. Functionality is excluded.
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
• Often the architect’s first major design decision.
• Also referred to as architectural styles.
• 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.
– For example, the standard parts of a compiler or
database management system & how they work
• 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.
• The mapping may be 1-1, but an element may
implement a part of a function or several
Why is Architecture Important?
• Three fundamental reasons from a technical
– Communication among stakeholders
• a basis for mutual understanding, negotiation, & consensus
– Early design decisions
• earliest point at which decisions can be analyzed
– Transferable abstraction of a system
• can promote large-scale reuse
Early design decisions
• The architecture:
– defines constraints on implementation
– dictates organizational structure
– inhibits or enables a system’s quality attributes
• some details on next slide, more on p. 30
– studying it can predict system qualities
– easier to reason about and manage change
– helps in evolutionary prototyping
– enables more accurate cost & schedule estimates
High performance Manage the time-based behavior
of elements; the frequency &
volume of inter-element
Scalability Carefully localize the use of
resources to facilitate the
introduction of high-capacity
Deliver incremental subsets Carefully manage inter-
Re-usable elements Restrict inter-element couplings
so an extraction doesn’t have too
many environment attachments
to be useful
Architecture: a Transferable, Reusable Model
• The earlier in the lifecycle re-use is applied, the
greater the benefit.
– Software Product Lines share a common architecture.
– Composing with large, externally developed elements.
– Restrict the vocabulary of design alternatives: patterns.
– Architecture permits template-based development.
– Used as the basis for training.
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
• Module structures
– units of implementation with assigned areas of
functionality - usually static
• Component-and-connector structures
– runtime components (principal units of computation)
and connectors (communication vehicles)
• Allocation structures
– show relationships between software elements &
external environments (creation or execution)
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
– How is the system to be structured as a set of elements
that have runtime behavior (components) and
– How is the system to relate to non-software structures
in its environment (i.e., CPUs, file systems, networks,
development teams, etc. - allocation)?
• Each structure provides a method for reasoning
about some of the relevant quality attributes, for
– 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.
Value of Structures
• Each structure provides the architect with a
different view into the system & a different
leverage point for design.
• Table 2.1 on page 39-40 should be useful in your
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
– 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.
• Kruchten’s Four + One Views:
– Logical - elements are “key abstractions” that are
objects or classes in OO. This is a module view.
– Process - addresses concurrency & distribution of
functionality. This is a C&C view.
– Development - shows organization of software
modules, libraries, subsystems, and units of
development. This is an allocation view.
– Physical - maps other elements onto processing &
communication nodes, also an allocation view, but
usually referred to specifically as the deployment view.
• Please read “Architecture Deja Vu” on pages 43-
• What do you think? Do you agree or disagree?
Ch 3: A-7E Avionics System
• Architecture is focused on three structures:
– Decomposition into modules
– Uses – how the modules relate
– Process – components and connectors
• Information hiding:
– Also foundation to OO design,
– Except information hiding modules are derived
by identifying expected changes over the
– A module may have submodules
• Simple enough to understand fully
• Change one module without knowing or
• Most likely changes should be easiest
• Possible to make major changes as a set of
independent changes to individual modules
• If the interfaces are not changed, any
combination of old and new should run
A-7E Module Decomposition Structure
• Architects observed that, in similar systems,
changes tend to come from three areas:
– Required externally visible behavior
– Decisions controlled by the developer
• Runtime execution information – the
authoritative picture of how the software
• Uses relation:
– Procedure A is said to use procedure B if a
correctly functioning procedure B must be
present in order for A to meet its requirements.
• Allows rapid identification of functional
• The uses (allowed-to-use) structure is
documented in a table – see Table 3.4 for an
• Implemented as a set of cooperating
sequential processes that synchronize with
each other to cooperatively use shared
• Pre-runtime scheduling produced a single
• A set of programming steps that are
repeated in response to a triggering event or
to a timing constraint
• It has its own thread of control, and can
suspend by waiting for an event
• Written for two main purposes
1. For the functional drivers to compute the
output values of the avionics software
2. Less frequently, they can implement
expensive access procedures – continuously
compute in the background, returning the
most recent value when called
– See their conceptual structures on pp 63-64
• Contains the “synchronizes-with” relation
• Based on events that one process signals and one
or more processes await
• Used as the primary input to the scheduling
activity, which includes deadlock avoidance
• Process structure has two types of information:
– What procedures are included in each process,
identifying threads and re-entrant requirements
– Which processes cannot execute simultaneously