1

Chapter 14Chapter 14Architectural Architectural

DesignDesign

2

Why Why Architecture?Architecture?

The architecture is not the operational software. The architecture is not the operational software. Rather, it is a representation that enables a software Rather, it is a representation that enables a software engineer to: engineer to:

(1) analyze the (1) analyze the effectivenesseffectiveness of the design in meeting of the design in meeting its stated requirements, its stated requirements,

(2) consider architectural alternatives at a stage when (2) consider architectural alternatives at a stage when making design changesmaking design changes is still relatively easy, and is still relatively easy, and

(3) reduce the (3) reduce the risksrisks associated with the construction of associated with the construction of the software.the software.

3

Data Data DesignDesign

Data designData design creates a creates a modelmodel of data of data and/or information that is represented and/or information that is represented at a high level of abstraction. This at a high level of abstraction. This data model is the refined into data model is the refined into progressively more implementation-progressively more implementation-specific representations that can be specific representations that can be processed by the computer-based processed by the computer-based system.system.

• Data structuresData structures• DatabasesDatabases• Data warehouseData warehouse

4

Data Design—Data Design—Component LevelComponent Level1. 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.

12

Mapping Mapping Requirements Requirements

into into a Software a Software

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

customer requirements

architectural design

13

Deriving Program Deriving Program ArchitectureArchitecture

ProgramProgramArchitectureArchitecture

Structure Design

14

Structured DesignStructured Design

objective:objective: to derive a program to derive a program architecture that is partitionedarchitecture that is partitioned

approach:approach: • the DFD is mapped into a program the DFD is mapped into a program

architecturearchitecture• the PSPEC and STD are used to indicate the PSPEC and STD are used to indicate

the content of each modulethe content of each module

notation:notation: structure chart structure chart

15

Flow Flow CharacteristicsCharacteristics

Transform flow

Transactionflow

16

Transform Transform FlowFlow

17

Transaction Transaction FlowFlow

18

General Mapping General Mapping ApproachApproach

isolate incoming and outgoing flow isolate incoming and outgoing flow boundaries; for transform and transaction flows boundaries; for transform and transaction flows

Isolate the transaction centerIsolate the 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

19

====================================

20

Transform Transform MappingMapping

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

21

FactoriFactoringng

typical "worker" modules

typical "decision making" modules

direction of increasing decision making

22

FFirirsst t LLeevveel l FFaaccttooririnngg

main programcontroller

inputcontroller

processingcontroller

outputcontroller

23

Second Level Second Level MappingMapping

D

C

B A

A

C

B

Dmapping from the flow boundary outward

main

control

24

ExamplExampleeStep 1. Review the fundamental

system model

25

26

Step 2: Review and refine data flow diagrams for the software

27

Refining the Analysis Refining the Analysis ModelModelwrite 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.

28

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.

29

Step 5: Perform “first-level Step 5: Perform “first-level factoring.”factoring.”

30

Step 6: Perform “second-level Step 6: Perform “second-level factoring.”factoring.”

31

32

Step 7: Refine the first-iteration Step 7: Refine the first-iteration architecture using design architecture using design heuristics for improved software heuristics for improved software quality.quality.

1.Remove incoming controller – single incoming flow path

2. Implode Establish alarm conditions & Select phone number – a little decreasing cohesion is tolerable

3. Implode Format display & Generate display – two formatting is quite simple

33

34

========================================

35

Transaction Transaction MappingMapping

T

incoming flow

action path

Transaction Flow

36

Transaction Mapping Transaction Mapping PrinciplesPrinciples

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

37

Transaction Transaction MappingMapping

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

38

Isolate Flow Isolate Flow PathsPaths

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

39

Map the Flow Map the Flow ModelModel

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

40

Refining the Refining the Structure ChartStructure 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

41

ExamplExamplee

Step 1: Review the fundamental system Step 1: Review the fundamental system model. model.

Step 2: Review and refine data flow Step 2: Review and refine data flow diagrams for the software.diagrams for the software.

42

43

44

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

Step 4: Identify the transaction center and Step 4: Identify the transaction center and the flow characteristics along each the flow characteristics along each of the action paths.of the action paths.

45

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

46

47

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

48

Step 7: Refine the first-iteration Step 7: Refine the first-iteration architecture using design architecture using design heuristics for improved heuristics for improved software quality.software quality.