1

Chapter 10Architectural Design

Chapter 10Architectural Design

Software Engineering: A Practitioner’s Approach, 6th editionby Roger S. Pressman

2

Software ArchitectureSoftware Architecture

The software architecture of a program or computing system is the structure or structures of the system, which comprise the software components, the externally visible properties of those components, and the relationships among them.

— Bass. et al.

The software architecture of a program or computing system is the structure or structures of the system, which comprise the software components, the externally visible properties of those components, and the relationships among them.

— Bass. et al.

3

Why Architecture?Why Architecture?

Architecture is a representation of a system that enables the 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.

Architecture is a representation of a system that enables the 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.

4

Data DesignData Design

Architectural level Database design data mining data warehousing

Component level Data structure design

Architectural level Database design data mining data warehousing

Component level Data structure design

5

Architectural StylesArchitectural 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.

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.

6

Specific StylesSpecific Styles

Data-centered architecture Data flow architecture Call and return architecture Object-oriented architecture Layered architecture

Data-centered architecture Data flow architecture Call and return architecture Object-oriented architecture Layered architecture

7

Data-Centered ArchitectureData-Centered Architecture

8

Data-Flow ArchitectureData-Flow Architecture

9

Call and Return ArchitectureCall and Return Architecture

10

Object-Oriented ArchitectureObject-Oriented Architecture

11

Layered ArchitectureLayered Architecture

12

Independent Component StyleIndependent Component Style

Server

Client A Client B

Client C Client D

Peer W Peer X

Peer Y Peer Z

13

14

Architectural PatternsArchitectural Patterns

Concurrency operating system process management task scheduler

Persistence database management system application level persistence

Distribution broker

Concurrency operating system process management task scheduler

Persistence database management system application level persistence

Distribution broker

15

Architectural DesignArchitectural Design

Architectural context diagrams model how software interacts with external entities

Archetypes are classes or patterns that represent an abstraction critical to the system

Architectural components are derived from the application domain, the infrastructure, and the interface.

Architectural context diagrams model how software interacts with external entities

Archetypes are classes or patterns that represent an abstraction critical to the system

Architectural components are derived from the application domain, the infrastructure, and the interface.

16

Arch. Context DiagramArch. Context Diagram

17

SafeHome ACDSafeHome ACD

18

SafeHome ArchetypeSafeHome Archetype

19

Component StructureComponent Structure

20

Component ElaborationComponent Elaboration

21

Example Archetypes in Humanity

Example Archetypes in Humanity

Addict/Gambler Amateur Beggar Clown Companion Damsel in distress Destroyer Detective Don Juan Drunk Engineer Father Gossip Guide Healer Hero Judge King Knight Liberator/Rescuer

Addict/Gambler Amateur Beggar Clown Companion Damsel in distress Destroyer Detective Don Juan Drunk Engineer Father Gossip Guide Healer Hero Judge King Knight Liberator/Rescuer

Lover/Devotee Martyr Mediator Mentor/Teacher Messiah/Savior Monk/Nun Mother Mystic/Hermit Networker Pioneer Poet Priest/Minister Prince Prostitute Queen Rebel/Pirate Saboteur Samaritan Scribe/Journalist

Lover/Devotee Martyr Mediator Mentor/Teacher Messiah/Savior Monk/Nun Mother Mystic/Hermit Networker Pioneer Poet Priest/Minister Prince Prostitute Queen Rebel/Pirate Saboteur Samaritan Scribe/Journalist

Seeker/Wanderer Servant/Slave Storyteller Student Trickster/Thief Vampire Victim Virgin Visionary/Prophet Warrior/Soldier

(Source: http://www.myss.com/)

22

Example Archetypes in Software Architecture

Example Archetypes in Software Architecture

Node Detector/Sensor Indicator Controller Manager

Node Detector/Sensor Indicator Controller Manager

Moment-Interval Role Description Party, Place, or Thing

Moment-Interval Role Description Party, Place, or Thing

(Source: Archetypes, Color, and the Domain Neutral Component)(Source: Pressman)

23

Archetypes – their attributes Archetypes – their attributes

24

Archetypes – their methodsArchetypes – their methods

25

26

Component StructureComponent Structure

SafeHome Executive

External Communication Management

GUI Internet Interface

Function selection

Security Surveillance Home management

Control panel

processing

detector management

alarm processing

27

Refined Component StructureRefined 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

28

Analyzing Architectural DesignAnalyzing Architectural Design

1. Collect scenarios. 1. Collect scenarios. 2. Elicit requirements, constraints, and environment 2. Elicit requirements, constraints, and environment description. description. 3. Describe the architectural styles/patterns that have 3. Describe the architectural styles/patterns that have been chosen to address the scenarios and requirements:been chosen to address the scenarios and requirements:

• • module viewmodule view• • process viewprocess view• • data flow viewdata flow view

4. Evaluate quality attributes by considered each 4. Evaluate quality attributes by considered each attribute in isolation. attribute in isolation. 5. Identify the sensitivity of quality attributes to various 5. Identify the sensitivity of quality attributes to various architectural attributes for a specific architectural style. architectural attributes for a specific architectural style. 6. Critique candidate architectures (developed in step 3) 6. Critique candidate architectures (developed in step 3) using the sensitivity analysis conducted in step 5.using the sensitivity analysis conducted in step 5.

29

An Architectural Design Method

"four bedrooms, three baths,lots of glass ..."

customer requirements

architectural design

30

Deriving Program Architecture

ProgramProgramArchitectureArchitecture

31

Partitioning the Architecture

“horizontal” and “vertical” partitioning are required

32

Horizontal Partitioning

define separate branches of the module hierarchy for each major function

use control modules to coordinate communication between functions

function 1function 1 function 3function 3

function 2function 2

33

Vertical Partitioning:Factoring design so that decision making and work are

stratified decision making modules should reside at the

top of the architecture

workersworkers

decision-makersdecision-makers

34

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

35

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

36

Flow Characteristics

Transform flow

Transactionflow

37

General Mapping Approach

isolate incoming and outgoing flow isolate incoming and outgoing flow boundaries; for transaction flows, isolate boundaries; for transaction flows, isolate the transaction centerthe transaction center

working from the boundary outward, mapworking from the boundary outward, mapDFD transforms into corresponding modulesDFD transforms into corresponding modules

add control modules as requiredadd control modules as required

refine the resultant program structurerefine the resultant program structureusing effective modularity conceptsusing effective modularity concepts

38

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

39

Factoring

typical "worker" modules

typical "decision making" modules

direction of increasing decision making

40

First Level Factoring

main programcontroller

inputcontroller

processingcontroller

outputcontroller

41

Second Level Mapping

D

C

B A

A

C

B

Dmapping from the flow boundary outward

main

control

42

Transaction Flow

T

incoming flow

action path

43

Transaction Example

operatorcommands

processoperator commands

fixture setting

report

robot control

fixtureservos

displayscreen

robotcontrolsoftware

in reality, other commandswould also be shown

assemblyrecord

44

Refining the Analysis Model

write an English language processing narrative write an English language processing narrative for the level 01 flow modelfor the level 01 flow model

apply noun/verb parse to isolate processes, data apply noun/verb parse to isolate processes, data items, store and entitiesitems, store and entities

develop level 02 and 03 flow modelsdevelop level 02 and 03 flow models

create corresponding data dictionary entriescreate corresponding data dictionary entries

refine flow models as appropriaterefine flow models as appropriate

... now, we're ready to begin design!... now, we're ready to begin design!

1.1.

2.2.

3.3.

4.4.

5.5.

45

Deriving Level 1Processing narrative for " process operator commands"Processing narrative for " process operator commands"

Process operator command software reads operator commands from Process operator command software reads operator commands from the cell operator. An error message is displayed for invalid commands. the cell operator. An error message is displayed for invalid commands. The command type is determined for valid commands and appropriate The command type is determined for valid commands and appropriate action is taken. When fixture commands are encountered, fixture action is taken. When fixture commands are encountered, fixture status is analyzed and a fixture setting is output to the fixture servos. status is analyzed and a fixture setting is output to the fixture servos. When a report is selected, the assembly record file is read and a When a report is selected, the assembly record file is read and a report is generated and displayed on the operator display screen. report is generated and displayed on the operator display screen. When robot control switches are selected, control values are sent to When robot control switches are selected, control values are sent to

the robot control system. the robot control system.

Processing narrative for " process operator commands"Processing narrative for " process operator commands"

Process operator command software Process operator command software readsreads operator operator commandscommands from from the cell the cell operatoroperator. An . An error messageerror message is is displayeddisplayed for for invalid commandsinvalid commands. . The The command typecommand type is is determineddetermined for for valid commandsvalid commands and appropriate and appropriate action is action is takentaken. When . When fixture commandsfixture commands are are encounteredencountered, , fixture fixture statusstatus is is analyzedanalyzed and a and a fixture settingfixture setting is is outputoutput to the to the fixture servosfixture servos. . When a When a reportreport is is selectedselected,, the the assembly record fileassembly record file is is readread and a and a report is report is generatedgenerated and and displayeddisplayed on the operator on the operator display screendisplay screen. . When When robot control switchesrobot control switches are are selectedselected, , control valuecontrol values s are are sentsent to to the the robot control system. robot control system.

noun-verbnoun-verbparseparse

46

Level 1 Data Flow Diagram

operator commands

read operator

commands

determine command

type

analyze fixture status

generate report

send control value

fixture servos

display screen

robot control system

assembly record

valid command

Error msg

fixture setting

report

robot control

fixture

select report

control robot

status

47

Level 2 Data Flow Diagram

read command

produce error msg

validate command

determine type

read fixture status

determine setting

format setting

read record

calculate output values

format report

reportvalues

record

assembly record

command

command invalid command

status

error msg

robot control

send control value

start /stop

combined status

raw setting

fixture setting

48

Transaction Mapping Principles

isolate the incoming flow pathisolate the incoming flow path

define each of the action paths by looking for define each of the action paths by looking for the "spokes of the wheel"the "spokes of the wheel"

assess the flow on each action pathassess the flow on each action path

define the dispatch and control structuredefine the dispatch and control structure

map each action path flow individuallymap each action path flow individually

49

Transaction Mapping

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

50

Isolate Flow Paths

read command

produce error msg

validate command

determine type

read fixture status

determine setting

format setting

read record

calculate output values

format report

reportvalues

record

assembly record

command

command invalid command

status

error msg

robot control

send control value

start /stop

combined status

raw setting

fixture setting

51

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

52

Refining the Structure Chartprocess

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