42
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 1 Software Engineering: A Practitioner’s Approach, Software Engineering: A Practitioner’s Approach, 6/e 6/e Chapter 10 Chapter 10 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.

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

Embed Size (px)

Citation preview

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

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 1

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

Chapter 10Chapter 10Architectural DesignArchitectural Design

copyright © 1996, 2001, 2005

R.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: Software Engineering: A Practitioner’s Approach,  6/e

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 2

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

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

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

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

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

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 3

Why is Architecture Why is Architecture Important?Important?

Representations of software architecture are an enablerRepresentations of software architecture are an enabler for for communication between all parties (stakeholders) interested in the communication between all parties (stakeholders) interested in the development of a computer-based system.development of a computer-based system.

The architecture highlights early design decisionsThe architecture highlights early design decisions that will have a that will have a profound impact on all software engineering work that follows and, as profound impact on all software engineering work that follows and, as important, on the ultimate success of the system as an operational entity.important, on the ultimate success of the system as an operational entity.

Architecture “constitutes a relatively small, intellectually graspable modelArchitecture “constitutes a relatively small, intellectually graspable model of how the system is structured and how its components work together” of how the system is structured and how its components work together” [BAS03].[BAS03].

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

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 4

Data DesignData Design

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

application architectureapplication architecture Design of methods for ‘Design of methods for ‘miningmining’ the content of multiple ’ the content of multiple

databasesdatabases navigate through existing databases in an attempt to navigate through existing databases in an attempt to

extract appropriate business-level informationextract appropriate business-level information Design of a Design of a data warehousedata warehouse—a large, independent —a large, independent

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

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

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 5

Data Data DesignDesign At the component level …At the component level …

refine data objects and develop a set of data refine data objects and develop a set of data abstractionsabstractions

implement data object attributes as one or implement data object attributes as one or more data structuresmore data structures

review data structures to ensure that review data structures to ensure that appropriate relationships have been establishedappropriate relationships have been established

simplify data structures as requiredsimplify data structures as required

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

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 6

Data Design—Component Data Design—Component LevelLevel

1. The systematic analysis principles applied to function 1. The systematic analysis principles applied to function and behavior should also be applied to data. and behavior should also be applied to data. 2. All data structures and the operations to be performed 2. All data structures and the operations to be performed on each should be identified. on each should be identified. 3. A data dictionary should be established and used to 3. A data dictionary should be established and used to define both data and program design. define both data and program design. 4. Low level data design decisions should be deferred 4. Low level data design decisions should be deferred until late in the design process. until late in the design process. 5. The representation of data structure should be known 5. The representation of data structure should be known only to those modules that must make direct use of the only to those modules that must make direct use of the data contained within the structure. data contained within the structure. 6. A library of useful data structures and the operations 6. A library of useful data structures and the operations that may be applied to them should be developed. that may be applied to them should be developed. 7. A software design and programming language should 7. A software design and programming language should support the specification and realization of abstract data support the specification and realization of abstract data types.types.

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

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 7

Architectural StylesArchitectural Styles

Data-centered architecturesData-centered architectures Data flow architecturesData flow architectures Call and return architecturesCall and return architectures Object-oriented architecturesObject-oriented architectures Layered architecturesLayered architectures

Each style describes a system category that encompasses: (1) a Each style describes a system category that encompasses: (1) a set of componentsset of components (e.g., a database, computational modules) (e.g., a database, computational modules) that perform a function required by a system, (2) a that perform a function required by a system, (2) a set of set of connectorsconnectors that enable “communication, coordination and that enable “communication, coordination and cooperation” among components, (3) cooperation” among components, (3) constraintsconstraints that define that define how components can be integrated to form the system, and (4) how components can be integrated to form the system, and (4) semantic modelssemantic models that enable a designer to understand the that enable a designer to understand the overall properties of a system by analyzing the known overall properties of a system by analyzing the known properties of its constituent parts. properties of its constituent parts.

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

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 8

Data-Centered ArchitectureData-Centered Architecture

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

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 9

Data Flow ArchitectureData Flow Architecture

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

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 10

Call and Return ArchitectureCall and Return Architecture

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

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 11

Layered ArchitectureLayered Architecture

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

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 12

Architectural PatternsArchitectural Patterns ConcurrencyConcurrency—applications must handle multiple tasks in a —applications must handle multiple tasks in a

manner that simulates parallelism manner that simulates parallelism operating system process managementoperating system process management patternpattern task schedulertask scheduler pattern pattern

PersistencePersistence—Data persists if it survives past the execution of —Data persists if it survives past the execution of the process that created it. Two patterns are common: the process that created it. Two patterns are common:

a a database management systemdatabase management system pattern that applies the storage and pattern that applies the storage and retrieval capability of a DBMS to the application architectureretrieval capability of a DBMS to the application architecture

an an application levelapplication level persistencepersistence pattern that builds persistence pattern that builds persistence features into the application architecturefeatures into the application architecture

DistributionDistribution— the manner in which systems or components — the manner in which systems or components within systems communicate with one another in a distributed within systems communicate with one another in a distributed environmentenvironment

AA brokerbroker acts as a ‘middle-man’ between the client component and a acts as a ‘middle-man’ between the client component and a server component.server component.

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

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 13

Architectural DesignArchitectural Design

The software must be placed into contextThe software must be placed into context the design should define the external entities (other the design should define the external entities (other

systems, devices, people) that the software interacts systems, devices, people) that the software interacts with and the nature of the interactionwith and the nature of the interaction

A set of architectural archetypes should be A set of architectural archetypes should be identifiedidentified AnAn archetypearchetype is an abstraction (similar to a class) that is an abstraction (similar to a class) that

represents one element of system behaviorrepresents one element of system behavior The designer specifies the structure of the The designer specifies the structure of the

system by defining and refining software system by defining and refining software components that implement each archetypecomponents that implement each archetype

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

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 14

Architectural ContextArchitectural Context

target system:Security Function

uses

uses peershomeowner

SafehomeProduct

Internet-basedsystem

surveillancefunction

sensors

controlpanel

sensors

uses

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

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 15

ArchetypesArchetypes

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

Controller

Node

communicates with

Detector Indicator

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

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 16

Component StructureComponent StructureSafeHomeExecutive

ExternalCommunicationManagement

GUI InternetInterface

Functionselection

Security Surveillance Homemanagement

Controlpanel

processing

detectormanagement

alarmprocessing

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

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 17

Refined Component Refined Component StructureStructure

sensorsensorsensorsensorsensorsensorsensorsensor

ExternalCommunicationManagement

GUI InternetInterface

Security

Controlpanel

processing

detectormanagement

alarmprocessing

Keypadprocessing

CP displayfunctions

scheduler

sensorsensorsensorsensor

phonecommunication

alarm

SafeHomeExecutive

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

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 18

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 19: Software Engineering: A Practitioner’s Approach,  6/e

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 19

An Architectural Design An Architectural Design MethodMethod

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

customer requirements

architectural design

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

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 20

Deriving Program Deriving Program ArchitectureArchitecture

ProgramProgramArchitectureArchitecture

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

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 21

Partitioning the Partitioning the ArchitectureArchitecture

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

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

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 22

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 functions

function 1function 1 function 3function 3

function 2function 2

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

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 23

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 24: Software Engineering: A Practitioner’s Approach,  6/e

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 24

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 25: Software Engineering: A Practitioner’s Approach,  6/e

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 25

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 26: Software Engineering: A Practitioner’s Approach,  6/e

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 26

Flow Flow CharacteristicsCharacteristics

Transform flow

Transactionflow

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

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 27

General Mapping General Mapping ApproachApproach

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

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

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 28

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

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

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 29

FactoriFactoringng

typical "worker" modules

typical "decision making" modules

direction of increasingdecision making

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

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 30

First Level First Level FactoringFactoring

main programcontroller

inputcontroller

processingcontroller

outputcontroller

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

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 31

Second Level Second Level MappingMapping

DC

B A

A

CB

Dmapping from theflow boundary outward

main

control

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

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 32

Transaction Transaction FlowFlow

T

incoming flow

action path

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

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 33

Transaction Transaction ExampleExample

operatorcommands

processoperator commands

fixture setting

report

robot control

fixtureservos

displayscreen

robotcontrolsoftware

in reality, other commandswould also be shown

assemblyrecord

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

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 34

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 35: Software Engineering: A Practitioner’s Approach,  6/e

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 35

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 36: Software Engineering: A Practitioner’s Approach,  6/e

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 36

Level 1 Data Flow Level 1 Data Flow DiagramDiagram

operator commands

readoperator

commands

determinecommand

type

analyzefixturestatus

generatereport

send controlvalue

fixtureservos

displayscreen

robotcontrol system

assemblyrecord

valid command

Error msg

fixture setting

report

robot control

fixture

select report

controlrobot

status

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

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 37

Level 2 Data Flow Level 2 Data Flow DiagramDiagram

read command

produce errormsg

validatecommand

determinetype

read fixturestatus

determinesetting

format setting

readrecord

calculateoutputvalues

formatreport

reportvalues

record

assemblyrecord

command

command invalid command

status

error msg

robot control

send controlvalue

start /stop

combined status

raw setting

fixture setting

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

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 38

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 39: Software Engineering: A Practitioner’s Approach,  6/e

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 39

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

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

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 40

Isolate Flow Isolate Flow PathsPaths

read command

produce errormsg

validatecommand

determinetype

read fixturestatus

determinesetting

format setting

readrecord

calculateoutputvalues

formatreport

reportvalues

record

assemblyrecord

command

command invalid command

status

error msg

robot control

send controlvalue

start /stop

combined status

raw setting

fixture setting

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

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 41

Map the Flow Map the Flow ModelModelprocess

operatorcommands

commandinput

controller

read command

validatecommand

produce error

message

determinetype

fixturestatus

controller

reportgenerationcontroller

sendcontrolvalue

each of the action paths must be expanded further

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

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 42

Refining the Structure Refining the Structure ChartChartprocessoperator

commands

commandinput

controller

read command

validatecommand

produce error

message

determinetype

sendcontrolvalue

read fixturestatus

determinesetting

formatsetting

read record

calculateoutputvalues

formatreport

fixturestatus

controller

reportgenerationcontroller