Chapter 9 - Architectural Design

Overview

Architectural design represents the structure of the data and program

components required to build a computer-based system. A number of
architectural "styles" exist. Architectural design begins with data design and
proceeds to the derivation of one or more representations of the architectural
structure of the system. The resulting architectural model encompasses both the
data architecture and the program structure. Alternative architectural patterns are
analyzed to determine the structure that is best suited to the customer’s
requirements. The architectural model is subjected to software quality review like
all other design work products.

Software architecture is a representation that enables a software engineer to

• Analyze the effectiveness of the design in meeting stated requirements

• Consider architectural alternatives
• Reduce the risk associated with the construction of the software

Importance of Architecture

• Software representations are an a communications enabler so

communications among stakeholders
• Architecture highlights early design decisions that will have a profound impact
on the ultimate success of the system as an operational entity
• The architecture itself constitutes a intellectually graspable model of how the
system is structured and how its components work together

Architectural Descriptions

• Set of work products that reflect different stakeholder system viewpoints

• Views are representations of a whole system from the perspective of a related
set of stakeholder concerns
• Viewpoints are specifications of conventions for constructing and using a view

Architectural Decision Template

• Used to document each major architectural decision for later review by

stakeholders who want to understand the proposed architectural description
o Design issue
o Resolution
 o Category
o Assumptions
o Constraints
o Alternatives
o Argument
o Implications
o Related decisions
o Related concerns
o Work products
o Notes

Architectural Genres

• Artificial intelligence
• Commercial and non-profit
• Communications
• Content authoring
• Devices
• Entertainment and sports
• Financial
• Games
• Government
• Industrial
• Legal
• Medical
• Military
• Operating systems
• Platforms
• Scientific
• Tools
• Transportation
• Utilities

Architectural Style Elements

• Set of components
• Set of connections that enable communication, coordination, and cooperation
among components
• Constraints defining how components can be integrated to form the system
• Semantic models that enable designers to understand the overall system
properties by analyzing properties of its constituent parts
Comparing Architectural Styles and Patterns

• Both impose transformations on the design of an entire system

• Scope of architectural pattern is less broad
• Patterns impose rules on the architecture describing how the software will
deliver some aspect of its functionality at the infrastructure level

Canonical Architectural Structures

• Functional structure – components represent function or processing entities,

connectors are interfaces that allow data access
• Implementation structure – components are vehicles for packaging
functionality (i.e. packages, classes, objects, functions, methods, etc.),
connectors include data sharing, control transfer, associations, etc.
• Concurrency structure – components are units of concurrency, connectors
are execution or communications constraints
• Physical structure – components are physical hardware that software is
deployed on, connectors are the hardware interfaces
• Developmental structure – components are work products and required
information sources, connectors are the relationships among the work
products

Architectural Styles

• Data centered - data store (e.g. file or database) lies at the center of this
architecture and is accessed frequently by other components (clients) that
modify data
• Data flow - input data is transformed by a series of computational or
manipulative components into output data
• Call and return - program structure decomposes function into control
hierarchy with main program invokes several subprograms (remote
subprograms may be distributed across networks)
• Object-oriented - components of system encapsulate data and operations,
communication between components is by message passing
• Layered - several layers are defined, each accomplishing operations that
progressively become closer to the machine instruction set

Architectural Patterns

• Address an application specific problem within a specific context under a set

of limitations and constraints
• Propose architectural solution that can serve as the basis for an architectural
design
Assessing Architecture Alternatives

• Control questions
o How is control managed within the architecture?
o Does a distinct control hierarchy exist?
o How do components transfer control within the system?
o How is control shared among components?
o What is the control topology?
o Is control synchronized or asynchronous?
• Data questions
o How are data communicated between components?
o Is the flow of data continuous or sporadic?
o What is the mode of data transfer?
o Do data components exist? If so what is their role?
o How do functional components interact with data components?
o Are data components active or passive?
o How do data and control interact within the system?

Architectural Design

• Software to be developed must be put into context (i.e. model external entities
and define interfaces)
• Identify architectural archetypes (collection of abstractions that must be
modeled if the system is to be constructed)
• Specify structure of the system by defining and refining the software
components needed to implement each archetype
• Continue the process iteratively until a complete architectural structure has
been derived

Representing the System in Context

• Use the architectural context diagram to model the manner in which the
system interacts with external entities
• Systems that interoperate with the target system are represented as
o Superordinate systems – using the target system as part of some
higher level processing scheme
o Subordinate systems – used by the target system to provide data or
processing needed to complete the target system
o Peer level systems – producing or consuming information need by
peers of the target system
o Actors – people or devices that interact with the system to produce or
consume information needed for requisite processing
• Interfaces must be defined
• All the data that flow into or out of the target system must be identified
Defining Archetypes

• Archetype is a class or pattern that represents a core abstraction critical to

the design of an architecture for a core system
• Archetypes are the abstract building blocks of an architectural design
• May be defined by examining the analysis classes defined in the analysis
model
• Determine the stable elements of the architecture that will need to be
implemented when the system is built

Refining Architecture into Components

• Process begins with an examination of the analysis classes for entities from
the business domain that must be addressed in the software architecture
• Infrastructure components needed to support the business functions but have
no business connection to the application domain
• The interfaces depicted in the architecture context diagram may imply
specialized components needed to process data that crosses the interfaces
• Look for archetypes that are reoccur in several components and create new
components that service each repeating design pattern
• UML component diagrams are used to represent the overall architectural
structure

Describing System Instantiations

• Refines the high-level architectural design once the overall system structure
is apparent and the major software components have been identified
• Architecture is applied to a specific problem with intent of demonstrating that
the structure and components are appropriate

Architecture Trade-off Analysis Method

1. Collect scenarios
2. Elicit requirements, constraints, and environmental description
3. Describe architectural styles/patterns chosen to address scenarios and
requirements (module view, process view, data flow view)
4. Evaluate quality attributes independently (e.g. reliability, performance,
security, maintainability, flexibility, testability, portability, reusability,
interoperability)
5. Identify sensitivity points for architecture (any attributes significantly affected
by variation in the architecture)
6. Critique candidate architectures (from step 3) using the sensitivity analysis
(conducted in step 5)

Architectural Complexity

• Similar to coupling, dependencies driven by system information/control flow

• Sharing dependencies - represent dependence relationships among
consumers who use the same resource or producers who produce for the
same consumers
• Flow dependencies - represent dependence relationships between producers
and consumers of resources
• Constrained dependencies - represent constraints on the relative flow among
a set of components

Architectural Description Language (ADL)

• Provide syntax and semantics for describing software architecture

• Provide designers with ability to decompose components, combine
components, and define interfaces

Transform Mapping

1. Review fundamental system model

2. Review and refine data flow diagrams for the software
3. Determine whether the DFD has transform or transaction (branching flow)
characteristics
4. Isolate the transform center by specifying incoming and outgoing flow
boundaries
5. Perform first-level factoring
6. Perform second-level factoring
7. Refine the first iteration architecture using design heuristics for improved
software quality

Transaction Mapping

1. Review fundamental system model

2. Review and refine data flow diagrams for the software
3. Determine whether the DFD has transform or transaction characteristics
4. Identify the transaction center and flow characteristics along each action path
5. Perform first-level factoring (map the DFD to a program structure amenable to
transaction processing)
6. Factor and refine the transaction structure and the structure of each action
path
7. Refine the first iteration architecture using design heuristics for improved
software quality

Refining Architectural Design

• Remember that an optimal design that does not work has questionable merit
• Designers should be concerned with developing a software architectural
representation that meets the functional and performance requirements as
measured by design measures and heuristics
• Software architectural design refinement should occur in the early design
phases
• Design refinement should strive for the smallest number of components
consistent with effective modularity and the least complex data structure