1 Software Engineering: A Practitioners Approach, 6/e Chapter 10b: Architectural Design Software...

26
1 Software Engineering: A Practitioner’s Approach, 6/e Software Engineering: A Practitioner’s Approach, 6/e Chapter 10b: Chapter 10b: Architectural Design Architectural Design copyright © 1996, 2001, 2005 R.S. Pressman & Associates, Inc. For University Use Only May be reproduced ONLY for student use at the university level when used in conjunction with Software Engineering: A Practitioner's Approach. Any other reproduction or use is expressly prohibited.

description

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

Transcript of 1 Software Engineering: A Practitioners Approach, 6/e Chapter 10b: Architectural Design Software...

Page 1: 1 Software Engineering: A Practitioners Approach, 6/e Chapter 10b: Architectural Design Software Engineering: A Practitioners Approach, 6/e Chapter 10b:

1

Software Engineering: A Practitioner’s Software Engineering: A Practitioner’s Approach, 6/eApproach, 6/e

Chapter 10b:Chapter 10b:Architectural DesignArchitectural Design

copyright © 1996, 2001, 2005R.S. Pressman & Associates, Inc.

For University Use OnlyMay be reproduced ONLY for student use at the university level

when used in conjunction with Software Engineering: A Practitioner's Approach.Any other reproduction or use is expressly prohibited.

Page 2: 1 Software Engineering: A Practitioners Approach, 6/e Chapter 10b: Architectural Design Software Engineering: A Practitioners Approach, 6/e Chapter 10b:

2

Analyzing Architectural Analyzing Architectural DesignDesign

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.

Page 3: 1 Software Engineering: A Practitioners Approach, 6/e Chapter 10b: Architectural Design Software Engineering: A Practitioners Approach, 6/e Chapter 10b:

3

An Architectural Design An Architectural Design MethodMethod

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

customer requirements

architectural design

Page 4: 1 Software Engineering: A Practitioners Approach, 6/e Chapter 10b: Architectural Design Software Engineering: A Practitioners Approach, 6/e Chapter 10b:

4

Deriving Program Deriving Program ArchitectureArchitecture

ProgramProgramArchitectureArchitecture

Page 5: 1 Software Engineering: A Practitioners Approach, 6/e Chapter 10b: Architectural Design Software Engineering: A Practitioners Approach, 6/e Chapter 10b:

5

Partitioning the Partitioning the ArchitectureArchitecture

““horizontal” and “vertical” horizontal” and “vertical” partitioning are requiredpartitioning are required

Page 6: 1 Software Engineering: A Practitioners Approach, 6/e Chapter 10b: Architectural Design Software Engineering: A Practitioners Approach, 6/e Chapter 10b:

6

Horizontal PartitioningHorizontal Partitioning define separate branches of the module define separate branches of the module

hierarchy for each major functionhierarchy for each major function use control modules to coordinate use control modules to coordinate

communication between functionscommunication between functionsfunction 1function 1 function 3function 3

function 2function 2

Page 7: 1 Software Engineering: A Practitioners Approach, 6/e Chapter 10b: Architectural Design Software Engineering: A Practitioners Approach, 6/e Chapter 10b:

7

Vertical Partitioning:Vertical Partitioning:FactoringFactoring

design so that decision making and work design so that decision making and work are stratifiedare stratified

decision making modules should reside at decision making modules should reside at the top of the architecturethe top of the architecture

workersworkers

decision-makersdecision-makers

Page 8: 1 Software Engineering: A Practitioners Approach, 6/e Chapter 10b: Architectural Design Software Engineering: A Practitioners Approach, 6/e Chapter 10b:

8

Why Partitioned Why Partitioned Architecture?Architecture?

results in software that is easier to testresults in software that is easier to test leads to software that is easier to maintainleads to software that is easier to maintain results in propagation of fewer side effectsresults in propagation of fewer side effects results in software that is easier to extendresults in software that is easier to extend

Page 9: 1 Software Engineering: A Practitioners Approach, 6/e Chapter 10b: Architectural Design Software Engineering: A Practitioners Approach, 6/e Chapter 10b:

9

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 the PSPEC and STD are used to indicate the content of each moduleindicate the content of each module

notation:notation: structure chart structure chart

Page 10: 1 Software Engineering: A Practitioners Approach, 6/e Chapter 10b: Architectural Design Software Engineering: A Practitioners Approach, 6/e Chapter 10b:

10

Flow Flow CharacteristicsCharacteristics

Transform flow

Transactionflow

Page 11: 1 Software Engineering: A Practitioners Approach, 6/e Chapter 10b: Architectural Design Software Engineering: A Practitioners Approach, 6/e Chapter 10b:

11

General Mapping General Mapping ApproachApproachisolate 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

Page 12: 1 Software Engineering: A Practitioners Approach, 6/e Chapter 10b: Architectural Design Software Engineering: A Practitioners Approach, 6/e Chapter 10b:

12

Transform Transform MappingMapping

data flow model

"Transform" mapping

ab

c

d e f g h

ij

x1

x2 x3 x4

b c

a

d e f g i

h j

Page 13: 1 Software Engineering: A Practitioners Approach, 6/e Chapter 10b: Architectural Design Software Engineering: A Practitioners Approach, 6/e Chapter 10b:

13

FactoriFactoringng

typical "worker" modules

typical "decision making" modules

direction of increasing decision making

Page 14: 1 Software Engineering: A Practitioners Approach, 6/e Chapter 10b: Architectural Design Software Engineering: A Practitioners Approach, 6/e Chapter 10b:

14

First Level First Level FactoringFactoring

main programcontroller

inputcontroller

processingcontroller

outputcontroller

Page 15: 1 Software Engineering: A Practitioners Approach, 6/e Chapter 10b: Architectural Design Software Engineering: A Practitioners Approach, 6/e Chapter 10b:

15

Second Level Second Level MappingMapping

DC

B A

A

CB

Dmapping from the flow boundary outward

main

control

Page 16: 1 Software Engineering: A Practitioners Approach, 6/e Chapter 10b: Architectural Design Software Engineering: A Practitioners Approach, 6/e Chapter 10b:

16

Transaction Transaction FlowFlow

T

incoming flow

action path

Page 17: 1 Software Engineering: A Practitioners Approach, 6/e Chapter 10b: Architectural Design Software Engineering: A Practitioners Approach, 6/e Chapter 10b:

17

Transaction Transaction ExampleExample

operatorcommands

processoperator commands

fixture setting

report

robot control

fixtureservos

displayscreen

robotcontrolsoftware

in reality, other commandswould also be shown

assemblyrecord

Page 18: 1 Software Engineering: A Practitioners Approach, 6/e Chapter 10b: Architectural Design Software Engineering: A Practitioners Approach, 6/e Chapter 10b:

18

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.

Page 19: 1 Software Engineering: A Practitioners Approach, 6/e Chapter 10b: Architectural Design Software Engineering: A Practitioners Approach, 6/e Chapter 10b:

19

Deriving Deriving Level 1Level 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

Page 20: 1 Software Engineering: A Practitioners Approach, 6/e Chapter 10b: Architectural Design Software Engineering: A Practitioners Approach, 6/e Chapter 10b:

20

Level 1 Data Flow Level 1 Data Flow DiagramDiagram

operator fixtureservos

displayscreen

generate

analyzefixturestatus

sendcontrolvalue

determinecommand

type

readoperator

commandsFixture setting

assembly record

status

Error msg

commands

Validcommand

fixture

select report

control robot report

robot control

Page 21: 1 Software Engineering: A Practitioners Approach, 6/e Chapter 10b: Architectural Design Software Engineering: A Practitioners Approach, 6/e Chapter 10b:

21

Level 2 Data Flow Level 2 Data Flow DiagramDiagram

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

Page 22: 1 Software Engineering: A Practitioners Approach, 6/e Chapter 10b: Architectural Design Software Engineering: A Practitioners Approach, 6/e Chapter 10b:

22

Transaction Mapping Transaction Mapping PrinciplesPrinciplesisolate 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

Page 23: 1 Software Engineering: A Practitioners Approach, 6/e Chapter 10b: Architectural Design Software Engineering: A Practitioners Approach, 6/e Chapter 10b:

23

Transaction Transaction MappingMapping

ab

tg

h

d

e

f

i

kj

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

Page 24: 1 Software Engineering: A Practitioners Approach, 6/e Chapter 10b: Architectural Design Software Engineering: A Practitioners Approach, 6/e Chapter 10b:

24

Isolate Flow Isolate Flow PathsPaths

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

Page 25: 1 Software Engineering: A Practitioners Approach, 6/e Chapter 10b: Architectural Design Software Engineering: A Practitioners Approach, 6/e Chapter 10b:

25

Map the Flow Map the Flow ModelModelprocess

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

Page 26: 1 Software Engineering: A Practitioners Approach, 6/e Chapter 10b: Architectural Design Software Engineering: A Practitioners Approach, 6/e Chapter 10b:

26

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