Chapter 3: Envisioning Architecture

Agenda:
 What is Software Architecture?
 The Architectural Business Cycle
 Architectural structures and views

1
 Software Architecture: Definition
 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.
 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.
2
 The Architecture Business Cycle

 For decades, software designers have been taught to

build systems based exclusively on the technical
requirements.
 Software architecture encompasses the structures of
large software systems:
– abstract view
– eliminates details of implementation, algorithm, & data
representation
– concentrates on the behavior & interaction of “black box”
elements
3
 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?
 Answer:
– Software architecture is a result of technical, business,
and social influences.
– In turn, it affects each of these environments.

4
 Where do Architectures Come From?

 The result of a set of business and technical

decisions.
 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.

5
Figure: Influence of
stakeholders on the architect
6
 Architectural Influences
 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
7
 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.

8
9
 Book’s Main Message
 Architectures affect the factors that influence
them.
 The relationships among business goals, product
requirements, architects’ experience, architectures, and
fielded systems form a cycle with feedback loops that a
business can manage:
 to handle growth, to expand enterprise area, and to take
advantage of previous investments in architecture & system
building.

10
11
 Software Processes & the ABC
 Software process 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.

12
 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?
 Quick Exercise:
 How do you
 Design one?
 Build one?
 Modify one? 13
 Architectural Activities

 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

14
 What makes a Good Architecture?
 No such thing as an inherently good or bad architecture.
 Architectures are more or less fit for some stated
purpose.
 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)
recommendations

15
 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.

16
 Rules of Thumb
 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 at
runtime 17
What is Software Architecture?

 Quite often shown as box-and-arrow diagrams(An

underwater acoustic simulation ).
Control
Process
(CP)

Prop Loss Reverb Noise

Model Model Model
(MODP) (MODR) (MODN)

Figure 18
 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!

19
 Definition Again
 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 between them.
 We see the elements (CP, MODP, MODR, MODN), but what
properties do they or their relationships have?
 Elements can be: objects, classes, functions, processes, programs,
libraries, databases, etc.
 Relationships between elements: part of, synchronization, function
call, etc.

20
 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.

21
 Definition Implications
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
architecture.
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.

22
 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]

23
 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
Figure 24
 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, 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.

25
 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.

26
 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.
– For example, the standard parts of a compiler or database
management system & how they work together.
• Compilers: lexical analysis, syntactic analysis, semantic
analysis, optimization, code generation
• Networks: the OSI reference model
27
 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.

28
 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
 Early design decisions
 earliest point at which decisions can be analyzed
 Transferable abstraction of a system
 can promote large-scale reuse
29
 Early design decisions

 The architecture:
– defines constraints on implementation
– dictates organizational structure
– inhibits or enables a system’s quality attributes
– studying it can predict system qualities
– easier to reason about and manage change
– helps in evolutionary prototyping
– enables more accurate cost & schedule estimates

30
 Quality Attributes
High performance Manage the time-based behavior
of elements; the frequency &
volume of inter-element
communication
Scalability Carefully localize the use of
resources to facilitate the
introduction of high-capacity
replacements
Deliver incremental subsets Carefully manage inter-
component usage
Re-usable elements Restrict inter-element couplings
so an extraction doesn’t have too
many environment attachments
to be useful

31
 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.
 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.
32
 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.

33
 Groups of Architectural Structures
 Module structures: units of implementation with assigned areas
of functionality - usually static
– Eg. Decomposition, uses, layered, class
 Component-and-connector structures:
– runtime components (principal units of computation) and
connectors (communication vehicles)
• Eg. Process (communication), concurrency, shared data (repository),
client-server
 Allocation structures: show relationships between software
elements & external environments (creation or execution)
• Eg. Work assignment, deployment, implementation
34
 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)?
35
Common software architecture structures

36
 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.

37
 Value of Structures

 Each structure provides the architect with a

different view into the system & a
different leverage point for design.

38
 Three Kinds of Structures
 Module :
 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). Important for modifiability
 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: how software is assigned to hardware elements
 Implementation: how software is mapped onto file structures
 Work assignment: who is doing what
39
 Useful module structures
 Decomposition structure:

40
 …Useful module structures
 Uses structure:

41
 …Useful module structures
 Layer structure:

42
 …Useful module structures
 Class (or generalization) structure:

43
 …Useful module structures
 Data model:

44
 …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.

45
 Useful C&C structures
 Service structure:
 Units: services, ESB,
registry, others
 Relations: runs
concurrently with, may
run concurrently with,
excludes, precedes,etc.
 Used for: scheduling
analysis, performance
analysis
 Affected attributes
include: Interoperability,
46
modifiability
…Useful C&C structures

47
 …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.

48
 Useful allocation structures
 Deployment structure:

49
 …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
50
efficiency
 …Useful allocation structures
 Work assignment structure:

51
 …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?

52
 Relationship between structures
 Each of these structures provides a different
perspective and design handle on a system.
 They are not independent. Elements of one
structure will be related to elements of other
structures.

53
 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.

54
 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.
55
 ... 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.
56
 ... Four + One Views
 Scenarios(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.

57
... 4+1 Architectural View Model

58
... 4+1 Architectural View Model

59
 Presentation/Reading
Assignment
• Please read “Architecture Deja Vu” on pages 43-45.
• What do you think? Do you agree or disagree? Why?

• A-7E Avionics System: A Case Study in utilizing

Architectural Structures => Architecture is focused on
three structures:
• Module Decomposition Structure -Decomposition into modules
• Uses Structure -how the modules relate
• Process Structure-components and connectors
60
 Utilizing Architectural Structures

 “An object-oriented program’s structure often bears little

resemblance to its code structure.
 The code structure is frozen at compile-time; it consists of classes
in fixed inheritance relationships.
 A program’s runtime structure consists of rapidly changing
networks of communicating objects. In fact, the two structures are
largely independent.
 Trying to [understand] one from the other is like trying to
understand the dynamism of living ecosystems from the static
taxonomy of plants and animals, and vice versa”.
— E. Gamma, R. Helms, R. Johnson, and J. Vlissides [Gamma 95]
61
The A-7E’s Architecural Structures

62
 Relationship to the Architecture Business Cycle

Figure: The ABC as it relates to the A-7E avionics systems

63
 Requirements of the A-7E Avionics System

 The system is responsible for reading sensors and

updating cockpit displays that help the pilot drop
weapons on a target.
 It does not fly the aircraft.

64
 Architecture for the A-7E Avionics System

 The architecture is centered around three structures:

– Decomposition, a structure of modules
– Uses, a structure of modules
– Process, a structure of components and connectors
 The module decomposition is based on information hiding

65
How the Module Decomposition Achieves Quality Goals

Goal How Achieved

Ease of change to: weapons, platform, Information hiding

symbology, input

Understand anticipated changes Formal evaluation procedures to take

advantage of experience of domain experts

Assign work teams so that their Modules structured as a hierarchy; each

interactions were minimized work team assigned to a second-level
module and all of its descedants

66
A-7E Module Decomposition Structure

67
A-7E Module Decomposition Structure

68
 How the Uses Structure Achieves Quality Goals

Goal How Achieved

Incrementally build and test system Create “is-allowed-to-use” structure for

functions programmers that limits procedures each
can use

Design for platform change Restrict number of procedures that use

platform directly

Produce usage guidance of manageable size Where appropriate, define uses to be a

relationship among modules

69
Excerpt from the A-7E Allowed-to-Use Specification

70
 How the Process Structure Achieves Quality Goals

Goal How Achieved

Map input to output Each process implemented as cycle that

samples inputs, computes, and presents
output

Maintain real-time constraints Identify process through process structure

and then perform offline scheduling

Provide results of time-consuming Perform calculations in background and

calculations immediately return most recent value when queried

71
.
.
.
.
.
72
 THANK YOU!
 Questions?

73