Chapter 10: Architectural Design

Presented By:Andy Carroll

Software Architecture: What is it? Structure or structures of the system, which

comprise software components, the externally visible properties of those components, and the relationships among them

Two Levels Data Design Architectural Design

Software Architecture The architecture is not the operational

software. Rather, it is a representation that enables a software engineer to: Analyze the effectiveness of the design in meeting its

stated requirements, Consider architectural alternatives at a stage when

making design changes is still relatively easy, and Reduce the risks associated with the construction of the

software.

Importance? Representations of software architecture are

enablers for communication The architecture highlights early design decisions Architecture “constitutes a relatively small,

intellectually graspable model of how the system is structured and how its components work together”

Most important?

Data Design: Architectural Level Multiple Databases Data mining: Knowledge Discovery in

Databases (KDD) Data Warehousing

Data Design: Component Level Focuses on representation of data structures

that are directly accessed by software components

Best practices: Develop data abstractions Ensure relationships established Simplify where possible

Examples?

Principles of Data Design

1. The systematic analysis principles applied to function and behavior should also be applied to data.

2. All data structures and the operations to be performed on each should be identified

3. A mechanism for defining the content of each data object should be established and used to define both data and the operations applied to it.

4. Low-level design decisions should be deferred until late in the design process.

5. The representation of a data structure should be known only to those modules that must make direct use of the data contained within the structure.

6. A library of useful data structures and the operations that may be applied to them should be developed.

7. A software design and programming language should support the specification and realization of abstract data types.

Architectural Styles Styles describe a category defined by:

A set of components that perform a function Set of connectors that enable communication Constraints on integration of components Semantic models that help the understanding of overall

properties of a system Types of Architectures

Data-centered Data flow Call and Return ( Main Program/Subprogram and Remote

Procedure Call) Object Oriented Layered

Data-Centered

Example?

Data Flow

Examples?

Call and Return

Layered

Architectural Patterns Concurrency: applications must handle

multiple tasks in a manner that simulates parallelism

Persistence: Data persists if it survives past the execution of the process that created it. Two patterns are common: DBMS Pattern Application Level Persistence Pattern

Distribution: the manner in which systems or components within systems communicate with one another in a distributed environment

Organization and Refinement Assessing architectural style:

Control How is control managed? Does a hierarchy exist? How is control transferred?

Data How is data communicated? Is flow continuous? Sporadic? Component interaction with data?

When might data flow be continuous? Sporadic?

Architectural Design Representing in context: interaction with

target system Superordinate Systems Subordinate Systems Peer-Level Systems Actors

Archetypes: one element of the system Nodes, Detectors, Indicators, Controllers

Refining: implementation of previously defined archetypes

Architectural Context Example

target system: Security Function

uses

uses peershomeowner

Safehome Product

Internet-based system

surveillance function

sensors

control panel

sensors

uses

Archetype Example

Figure 10.7 UML relationships for SafeHome security function archetypes (adapted from [BOS00])

Controller

Node

communicates with

Detector Indicator

Components Example

SafeHome Executive

External Communication Management

GUI Internet Interface

Function selection

Security Surveillance Home management

Control panel

processing

detector management

alarm processing

Refined Components Example

sensorsensorsensorsensor

sensorsensorsensor

sensor

External Communication Management

GUI Internet Interface

Security

Control

panelprocessing

detector

managementalarm

processing

Keypad processing

CP display functions

scheduler

sensorsensorsensorsensor

phone communication

alarm

SafeHome Executive

Analyzing the Design Collect scenarios Elicit requirements, constraints,

environment description Describe architectural designs or

patterns that have been chosen Evaluate quality attributes in isolation Identify the sensitivity of quality

attributes to various attributes for a specific style

Critique candidate architectures

Architectural Complexity Sharing dependencies Flow dependencies Constrained dependencies

Could these be related or causal?

Mapping Data Flow to Architecture Transform Mapping

1. Review the fundamental system model.2. Review and refine data flow diagrams for the

software3. Determine whether the DFD has transform or

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

Flow Characteristics

Transform flow

Transactionflow

Transform Mapping

data flow model

"Transform" mapping

ab

c

d e fg h

ij

x1

x2 x3 x4

b c

a

d e f g i

h j

Factoring

typical "worker" modules

typical "decision making" modules

direction of increasing decision making

First Level Factoring

main programcontroller

inputcontroller

processingcontroller

outputcontroller

Second Level Factoring

D

C

B A

A

C

B

Dmapping from the flow boundary outward

main

control

Mapping Data Flow to Architecture Transaction Mapping

1. Review the fundamental system model.2. Review and refine data flow diagrams for the

software3. Determine whether the DFD has transform or

transaction flow characteristics.4. Isolate the transaction center and the flow

characteristics along each of the action paths.5. Map the DFD in 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.

Transaction Mapping

a

b

t

g

h

d

e

f

i

k

j

l

m

n

Data flow model

x1

b

a

t

x2 x3 x4

d e f g h x3.1 l m n

i j

k

mapping

program structure

Isolate Flow Paths

readcommand

validatecommand

determinetype

readrecord

calculateoutputvalues

formatreport

produceerror msg

readfixturestatus

determinesetting

formatsetting

sendcontrolvalue

command

commandinvalid command

error msg

status

combinedstatus

raw setting

fixture setting

robot control

start/stop

assemblyrecord

record

values

report

valid command

Map the Flow Model

process operator

commands

command input

controller

read command

validate command

produce error

message

determine type

fixture status

controller

report generation controller

send control value

each of the action paths must be expanded further

Refining

process operator

commands

command input

controller

read command

validate command

produce error

message

determine type

send control value

read fixture status

determine setting

format setting

read record

calculate output values

format report

fixture status

controller

report generation controller