Architectural Design

1
Why Architecture?
The architecture is not the operational software. Rather, it is a
representation that enables a software engineer to:
(1) analyze the effectiveness of the design in meeting its
stated requirements,
(2) consider architectural alternatives at a stage when making
design changes is still relatively easy, and
(3) reduce the risks associated with the construction of the
software.

2
 Why is Architecture Important?
 Representations of software architecture are an enabler for
communication between all parties (stakeholders) interested in
the development of a computer-based system.

 The architecture highlights early design decisions that will have

a profound impact on all software engineering work that follows
and, as important, on the ultimate success of the system as an
operational entity.

 Architecture “constitutes a relatively small, intellectually

graspable mode of how the system is structured and how its
components work together”.

3
 Architectural Descriptions
The IEEE Computer Society has proposed, Recommended Practice for
Architectural Description of Software-Intensive Systems, with the
following objectives:
 to establish a conceptual framework and vocabulary for use during
the design of software architecture,
 to provide detailed guidelines for representing an architectural
description, and
 to encourage sound architectural design practices.

The IEEE standard defines an architectural description (AD) as “a

collection of products to document an architecture.” The description
itself is represented using multiple views, where each view is “a
representation of a whole system from the perspective of a related set of
concerns.”
4
 Architectural Decisions
 Each view developed as part of an architectural description
addresses a specific stakeholder concern.
 To develop each view (and the architectural description as a
whole) the system architect considers a variety of alternatives
and ultimately decides on the specific architectural features
that best meet the concern.
 Therefore, architectural decisions themselves can be
considered to be one view of the architecture.
 The reasons that decisions were made provide insight into the
structure of a system and its conformance to stakeholder
concerns.
5
 Agility and Architecture
 To avoid rework, user stories are used to create and evolve an
architectural model (walking skeleton) before coding.
 Using a technique called storyboarding, the architect contributes
architectural user stories to the project and works with the product
owner to prioritize the architectural stories with the business user
stories as “sprints” (work units) are planned.
 Hybrid models allow software architects contributing users stories
to the evolving storyboard.
 Run agile projects include delivery of work products during each
sprint.
 Reviewing code emerging from the sprint can be a useful form of
architectural review.

6
Architectural Design Process

 Basic Steps
 Creation of the data design
 Derivation of one or more representations of the architectural structure
of the system
 Analysis of alternative architectural styles to choose the one best
suited to customer requirements and quality attributes
 Elaboration of the architecture based on the selected architectural style
 A database designer creates the data architecture for a system to
represent the data components
 A system architect selects an appropriate architectural style
derived during system engineering and software requirements
analysis
Architectural Genres
 Genre implies a specific category within
the overall software domain.
 Within each category, you encounter a
number of subcategories.
 For example, within the genre of buildings, you
would encounter the following general styles:
houses, condos, apartment buildings, office
buildings, industrial building, warehouses, and
so on.
 Within each general style, more specific styles
might apply. Each style would have a structure
that can be described using a set of predictable
patterns.

8
Common Architectural Styles of American Homes

9
 Architectural Styles
Each style describes a system category that encompasses:
(1) a set of components (e.g., a database, computational
modules) that perform a function required by a system,
(2) a set of connectors that enable “communication,
coordination and cooperation” among components,
(3) constraints that define how components can be
integrated to form the system, and
(4) semantic models that enable a designer to understand
the overall properties of a system by analyzing the known
properties of its constituent parts.
 Data-centered architectures
 Data flow architectures
 Call and return architectures
 Object-oriented architectures
 Layered architectures 10
Data-Centered Architecture

11
 Data-centered architecture
 A data store (e.g., a file or database) resides at the center of
this architecture and is accessed frequently by other
components that update, add, delete, or otherwise modify
data within the store.

 Client software accesses a central repository which is in

passive state (in some cases).

 Data-centered architectures promote integrability.

 Data can be passed among clients using the blackboard

mechanism. So Client components independently execute
processes
Data Flow Architecture

13
 Data Flow architecture
 This architecture is applied when input data are to be transformed
through a series of computational or manipulative components into
output data.

 A pipe and filter pattern has a set of components, called filters,

connected by pipes that transmit data from one component to the
next.

 Each filter works independently (i.e. upstream, downstream) and is

designed to expect data input of a certain form, and produces data
output (to the next filter) of a specified form.

 The filter does not require knowledge of the working of its neighboring
filters.

 If the data flow degenerates into a single line of transforms, it is

termed batch sequential.
 Call and Return Architecture
This architectural style enables you to achieve a program structure that is
relatively easy to modify and scale.

• Main program/subprogram architectures. This classic program

structure decomposes function into a control hierarchy where a “main”
program invokes a number of program components that in turn may
invoke still other components.

• Remote procedure call architectures. The components of a main

program/subprogram architecture are distributed across multiple
computers on a network.

15
Call and Return Architecture

16
 Object-oriented architecture

• The components of a system encapsulate data and

the operations that must be applied to manipulate
the data.

• Communication and coordination between

components are accomplished via message passing.

• UML communication diagram that shows the

message passing for the login portion of a system
implemented using an object-oriented architect
Object-oriented architecture
 Layered Architecture
A number of different layers are defined, each accomplishing operations that
progressively become closer to the machine instruction set.
At the outer layer, components service user interface operations.
At the inner layer, components perform operating system interfacing.
Intermediate layers provide utility services and application software
functions.
Once requirements engineering uncovers the characteristics and constraints
of the system to be built, the architectural style and/or combination of
patterns that best fits those characteristics and constraints can be chosen.
 In many cases, more than one pattern might be appropriate and alternative
architectural styles can be designed and evaluated.
For example, a layered style (appropriate for most systems) can be
combined with a data-centered architecture in many database applications.
19
Layered Architecture

20
 Layered Architecture
Model-View-Controller (MVC) architecture is one of a number of
suggested mobile infrastructure models often used in Web
development.

•The model contains all application-specific content and processing

logic.
•The view contains interface-specific functions and enables the
presentation of content and processing logic required by the end user.
•The controller manages access to the model and the view and
coordinates the flow of data between them.

21
22
 Architectural Patterns
 Concurrency—applications must handle multiple tasks in a manner
that simulates parallelism
 operating system process management pattern
 task scheduler pattern
 Persistence—Data persists if it survives past the execution of the
process that created it. Two patterns are common:
 a database management system pattern that applies the storage and
retrieval capability of a DBMS to the application architecture
 an application level persistence pattern that builds persistence features
into the application architecture
 Distribution— the manner in which systems or components within
systems communicate with one another in a distributed environment
 A broker acts as a ‘middle-man’ between the client component and a
server component.

23
Architectural Design
 The software must be placed into context
 the design should define the external entities (other
systems, devices, people) that the software interacts with
and the nature of the interaction
 A set of architectural archetypes should be identified
 An archetype is an abstraction (similar to a class) that
represents one element of system behavior
 The designer specifies the structure of the system
by defining and refining software components that
implement each archetype

24
Architectural Context Diagram

25
 Superordinate systems—those systems that use the target
system as part of some higher-level processing scheme.
 Subordinate systems—those systems that are used by the
target system and provide data or processing that are
necessary to complete target system functionality.
 Peer-level systems—those systems that interact on a peer-to-
peer basis (i.e., information is either produced or consumed
by the peers and the target system.
 Actors—entities (people, devices) that interact with the target
system by producing or consuming information that is
necessary for requisite processing.

26
 Architectural Context Diagram
Safehome Internet-based
Product system

control
panel target system: surveillance
Security Function function
uses
homeowner peers
uses

uses

sensors sensors

27
 Arche types
•Node Represents a cohesive collection of input and
output elements of the home security function. For
example a node might be comprised of
•(1) various sensors and
•(2) a variety of alarm (output) indicators.
•Detector An abstraction that encompasses all
sensing equipment that feeds information into the
target system.
•Indicator An abstraction that represents all
mechanisms (e.g., alarm siren, flashing lights, bell) for
indicating that an alarm condition is occurring.
•Controller An abstraction that depicts the
mechanism that allows the arming or disarming of a
node. If controllers reside on a network, they have the
ability to communicate with one another.
28
Refining the Architecture into Components
 The set of top-level components that address the following functionality:
• External communication management—coordinates communication of the
security function with external entities such as other Internet-based systems
and external alarm notification.
• Control panel processing—manages all control panel functionality.
• Detector management—coordinates access to all detectors attached to the
system.
• Alarm processing—verifies and acts on all alarm conditions.
Each of these top-level components would have to be elaborated iteratively and
then positioned within the overall SafeHome architecture. Design classes (with
appropriate attributes and operations) would be defined for each. It is
important to note, however, that the design details of all attributes and
operations would not be specified until component-level design
29
Component Structure

30
 Describing Instantiations of the System
 The architectural design that has been modeled to this
point is still relatively high level.
 The context of the system has been represented,
archetypes that indicate the important abstractions
within the problem domain have been defined, the
overall structure of the system is apparent, and the
major software components have been identified.
 However, further refinement (recall that all design is
iterative) is still necessary

31
Refined Component Structure

32
 Assessing Alternative Architectural
Designs
The Software Engineering Institute (SEI) has developed an architecture trade-off
analysis method (ATAM) that establishes an iterative evaluation process for
software architectures. The design analysis activities that follow are performed
iteratively:

1. Collect scenarios.
2. Elicit requirements, constraints, and environment description.
3. Describe the architectural styles/patterns that have been chosen to
address the scenarios and requirements:
• module view
• process view
• data flow view
4. Evaluate quality attributes by considered each attribute in
isolation.
5. Identify the sensitivity of quality attributes to various architectural
attributes for a specific architectural style.
6. Critique candidate architectures (developed in step 3) using the
sensitivity analysis conducted in step 5. 33
ADL
 Architectural description language (ADL) provides
a semantics and syntax for describing a software
architecture
 Provide the designer with the ability to:
 decompose architectural components
 compose individual components into larger architectural
blocks and
 represent interfaces (connection mechanisms) between
components.

34
An Architectural Design Method
customer requirements
"four bedrooms, three baths,
lots of glass ..."

architectural design

35
 Transition From Data Flow Diagram To
Software Architecture
 The transition from information flow (represented as a
DFD) to program structure is accomplished as part of a
six step process:
(1) the type of information flow is established
(2) flow boundaries are indicated
(3) the DFD is mapped into the program structure
(4) control hierarchy is defined
(5) the resultant structure is refined using design measures
and heuristics, and
(6) the architectural description is refined and elaborated.

36
Deriving Program Architecture

Program
Architecture

37
Partitioning the Architecture
 “horizontal” and “vertical” partitioning are
required

38
Horizontal Partitioning
 define separate branches of the module
hierarchy for each major function
 use control modules to coordinate
communication between functions
function 1 function 3

function 2
39
Vertical Partitioning: Factoring
 design so that decision making and work
are stratified
 decision making modules should reside at
the top of the architecture
decision-makers

workers

40
Why Partitioned Architecture?
 results in software that is easier to test
 leads to software that is easier to maintain
 results in propagation of fewer side effects
 results in software that is easier to extend

41
Structured Design
 objective: to derive a program
architecture that is partitioned
 approach:
 a DFD is mapped into a program
architecture
 the PSPEC and STD are used to
indicate the content of each module
 notation: structure chart

42
Flow Characteristics

Transform flow

This edition of
SEPA does not
cover transaction
mapping. For a
detailed
discussion see the
SEPA website
Transaction
flow

43
General Mapping Approach
isolate incoming and outgoing flow
boundaries; for transaction flows, isolate
the transaction center

working from the boundary outward, map

DFD transforms into corresponding modules

add control modules as required

refine the resultant program structure

using effective modularity concepts

44
General Mapping Approach
 Isolate the transform center by specifying
incoming and outgoing flow boundaries
 Perform "first-level factoring.”
 The program architecture derived using this
mapping results in a top-down distribution of
control.
 Factoring leads to a program structure in which
top-level components perform decision-making and
low-level components perform most input,
computation, and output work.
 Middle-level components perform some control and
do moderate amounts of work.
 Perform "second-level factoring."

45
Transform Mapping

b g h
a e f
d
c i
j
data flow model

x1 "Transform" mapping

x2 x3 x4

b c d e f g i

a h j

46
Factoring
direction of increasing
decision making typical "decision
making" modules

typical "worker" modules

47
First Level Factoring
main
program
controller

input processing output

controller controller controller

48
Second Level Mapping
main
D
C
control

B A
A
B
C

mapping from the D

flow boundary outward

49
 Architectural Reviews
 Architectural reviews are a type of specialized technical review that provide a
means of assessing the ability of a software architecture to meet the
system’s quality requirements (e.g., scalability or performance) and to identify
any potential risks.
 Architectural reviews have the potential to reduce project costs by detecting
design problems early.
 Architecture reviews often involve only software engineering team members
supplemented by independent experts.
 The most common architectural review techniques used in industry are:
experiencebased reasoning, prototype evaluation, scenario review and use
of checklists.
 Many architectural reviews occur early in the project life cycle; they should
also occur after new components or packages are acquired in component-
based design.

50