1

Chapter 10Architectural Design

2

What is and Why Architecture?

Software architecture is the structure of the systems, which comprises

software components, properties of these components, relationships among them

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.

3

Data Design

At the architectural level … Design of one or more databases to support the

application architecture Design of methods for ‘mining’ the content of multiple

databases navigate through existing databases in an attempt to extract

appropriate business-level information Design of a data warehouse—a large, independent database

that has access to the data that are stored in databases that serve the set of applications required by a business

4

Data Design (cont.)

At the component level … refine data objects and develop a set of data

abstractions implement data object attributes as one or

more data structures review data structures to ensure that

appropriate relationships have been established

simplify data structures as required

5

Data Design Principles—Component Level

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 data dictionary should be established and used to define both data and program design.

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

5. The representation of 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.

6

Architectural Styles

Each style describes a system category that Each style describes a system category that encompasses: encompasses:

(1)(1) a a set of componentsset of components (e.g., a database, computational (e.g., a database, computational modules) that perform a function required by a system modules) that perform a function required by a system

(2)(2) a a set of connectorsset of connectors that enable “communication, coordination that enable “communication, coordination and cooperation” among components and cooperation” among components

(3)(3) constraints constraints that define how components can be integrated to that define how components can be integrated to form the system, and form the system, and

(4)(4) semantic modelssemantic models that enable a designer to understand the that enable a designer to understand the overall properties of a systemoverall properties of a system

7

Taxonomy of Architectural Styles

Data-centered architectures Data flow architectures Call and return architectures

Main program/subprogram architecture Remote procedure call architecture

Object-oriented architectures Layered architectures

8

Data-Centered Architecture

9

Data Flow Architecture

10

Call and Return Architecture

11

Layered Architecture

12

Architectural Patterns

Architecture pattern defines a specific approach for handling some behavioral characteristic of the system

Architecture pattern vs architecture style Kitchen pattern vs central-hall colonial

Representative example patterns Concurrency—applications must handle multiple tasks

in a manner that simulates parallelism operating system process management pattern task scheduler pattern

13

Architectural Patterns (cont.)

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.

14

Architectural Design Architectural design involves three main tasks:

Represent the system in context Define the external entities (other systems, devices, people) that

the software interacts with Use architectural context diagram (ACD)

Define archetypes An archetype is an abstraction (similar to a class) that represents one

element of system behavior Four architectural archetypes should be identified

Node, Detector, indicator, controller Use UML

Refine the architecture into components The designer specifies the structure of the system by defining and

refining software components that implement each archetype

15

Architectural Context

Actors

Subordinate systems

Superordinate systems

target system: Security Function

uses

uses peershomeowner

Safehome Product

Internet-based system

surveillance function

sensors

control panel

sensors

Depends on

Used by

16

Archetypes

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

Controller

Node

communicates with

Detector Indicator

17

Component Structure

SafeHome Executive

External Communication Management

GUI Internet Interface

Function selection

Security Surveillance Home management

Control panel

processing

detector management

alarm processing

18

Refined Component Structure

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

19

Analyzing Architectural Design

How to assess different architectural designs to determine the most appropriate

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, e.g., reliability, performance, security, maintainability

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.

20

An Architectural Design Method

"four bedrooms, three baths,

lots of glass ..."

customer requirements

architectural design

21

Structured Design

Objective: to derive a program architecture that is partitioned

Approach: the DFD is mapped into a program

architecture the PSPEC and STD are used to

indicate the content of each module Notation: structure chart

22

Deriving Program Architecture

ProgramProgramArchitectureArchitecture

Data flow diagram call and return architecture

23

Types of Information Flow

Transform flow A sequence of paths that form a

transition through which input data are transformed into output data

Transform flow

24

Types of Information Flow (cont.)

Transaction flow A information flow that is triggered by a single data

item, called transaction, along one of many paths

Transaction center

T

incoming flow

action path

25

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

26

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

27

Transform Mapping (cont.)

Step 1. Review the fundamental system model

Step 2. Review and refine data flow diagrams

Step 3. Determine whether the DFD has transform or transaction flow characteristics

Step 4. Isolate the transform center

Step 5. Perform “first-level factoring”

Step 6. Perform “second-level factoring”

Step 7. Refine the first-iteration architecture

28

Transform Mapping -- Illustration

Step 1. Review the fundamental system model Example: SafeHome security function

Level 0 DFD

29

Transform Mapping – Illustration (cont.)

Level 1 DFD

30

Transform Mapping – Illustration (cont.)

Step 2. Review and refine data flow diagrams Example: Level 2 DFD for monitor sensors process

31

Transform Mapping – Illustration (cont.) Level 3 DFD for monitor sensors process

32

Transform Mapping – Illustration (cont.)

Step 3. Determine whether the DFD has transform or transaction flow characteristics

Step 4. Isolate the transform center by specifying incoming and outgoing flow boundaries

33

Transform Mapping – Illustration (cont.)

Step 5. Perform “first-level factoring”

main programcontroller

inputcontroller

processingcontroller

outputcontroller

34

Factoring

typical "worker" modules

typical "decision making" modules

direction of increasing decision making

35

Transform Mapping – Illustration (cont.)

Step 6. Perform “second-level factoring”

D

C

B A

A

C

B

Dmapping from the flow boundary outward

main

control

36

Transform Mapping – Illustration (cont.)

37

Transform Mapping – Illustration (cont.)

38

Transform Mapping – Illustration (cont.)

Step 7. Refine the first-iteration architecture

39

Transaction Mapping

Step 1. Review the fundamental system model

Step 2. Review and refine data flow diagrams

Step 3. Determine whether the DFD has transform or transaction flow characteristics

Step 4. Identify the transaction center and flow characteristics along each action path

Step 5. Map the DFD in a program structure amenable to transaction processing

Step 6. Factor and refine transaction structure and the structure of each action path

Step 7. Refine the first-iteration architecture

40

Transaction Mapping (cont.)

data flow model

ab

t

de f

gh

i

j

kl

mn Mapping

b

a

x1

t

x2

d e f

x3

g h x3.1

i j

k

x4

l m n

41

Transaction Mapping – Illustration (cont.)

The first three steps are the same as transform mapping

Step 1. Review the fundamental system model Step 2. Review and refine data flow diagrams Step 3. Determine whether the DFD has

transform or transaction flow characteristics

42

Transaction Mapping – Illustration (cont.)

Step 4. Identify the transaction center and flow characteristics along each action path

Example: Level 2 DFD for user interaction subsystem

43

Transaction Mapping – Illustration (cont.)

Step 5. Map the DFD in a program structure amenable to transaction processing

An incoming branch and a dispatch branch

44

Transaction Mapping – Illustration (cont.) Example: user interaction subsystem

45

Transaction Mapping – Illustration (cont.)

Step 6. Factor and refine transaction structure and the structure of each action path

46

Remarks on Refining Architecture Design

Optimal design doesn’t work has questionable merit Refinement at early stages of design is encouraged Keep it simple

Simplicity often reflects both elegance and efficiency Strive for the smallest number of components consistent with effective

modularity and serving user requirements