Transitional Analysis

Guidelines for transforming DFD models toStructure Chart models

Ernest CachiaDepartment of Computer Science

The Reasons

To move from an abstract system representation to a more physical one.

To offer some guidelines to this procedure. To reduce ambiguity which may arise from

subjective interpretations. To move from data flow concepts to program

structure concepts.

General Steps Involved (1)

1. The type of data flow is established What is the nature of the data flowing between

processes?

2. Determine flow boundaries (switch points) Input↔Output boundaries Hub↔Action boundaries

3. Map the abstract DFD on to a particular program structure

Transformational structure Transactional structure

General Steps Involved (2)

4. Define a valid control structure Also known as “first-level” factoring Depends on whether transformational or transactional

models are used. “Call-and-return” for transformational “Call-and-act” for transactional

5. Refine (tune) the resulting structure Also known as “second-level factoring” Map IO flow bounded parts of DFD

General Steps Involved (3)

6. Supplement and tune the final architectural structure

Apply basic module independence concepts (i.e. Explode or implode modules according to coupling/cohesion requirements) to obtain an easier implementation.

Please also visit the slides on the web-site “www.sei.cmu.edu/ata/ATAM/index.htm” for a more comprehensive and interesting approach to architectural analysis known as “Architectural Trade-off Analysis – ATA”.

Transformational Analysis(aka Transformational Mapping)

SafeHomesystem*

* Example taken from “Software Engineering – A Practitioner's Approach” by R. S. Pressman.

Controlpanel

Sensors

Controlpanel

display

Alarm

Telephoneline

Dialtones

User cmdsand data

Sensorstatus

Displayinformation

Alarmtype

Context level (level 0) Example

Errormsg

Sys parametersand data

Level 1 Example

Interactwithuser

configuresystem

Enable/disablesystem

Processpassword

Displaymsgs &status

Monitorsensors

Configuration data

Alarmtype

Dial tonesSensor status

Password

Startstop

Configurerequest

Configurationdata

Configurationdata

a/d msg

Valid id msg

Sensor informationConfigurationdata

Display information

User cmds anddata

Error msg

Sys parametersand data

Level 2 Example (Monitor sensors)

Assessagainstsetup

Formatfor

display

Gen.alarmsignal

Readsensors

Dialphone

Alarmtype

Sensor status

Sensor idand setting

alarmdata

Sensor id,type andlocation

Sensorinformation

Telephonenumber

Dial tones

Configurationdata

Level 3 Example (Assess against setup)

Acquireresponse

info.

Selectphone

number

Sensor idand setting

Configurationdata

Estab.alarmconds.

Telephonenumber

Alarm cond.Code,

sensor id, andtiming info.

List ofnumbers

alarmdata

Sensor id,type andlocation

Level 3 Example (Format for display)

Formatdisplay

GeneratedisplaySensor id,

type andlocation

Formatted id,type andlocation

Sensorinformation

Level 3 Example (Dial phone)

Setupconn

to phonenet

Gen.pulses to

lineTelephonenumber

Tone-readytelephonenumber

Dial tones

Putting Level 3 Together

Afferent branch (input)Central transform (processing)Efferent branch (output)

This DFD exhibits definite transform flow character.

First-Level Factoring

Monitorsensors

Sensor inputcontroller

Alarm condscontroller

Alarm outputcontroller

Second-Level Factoring (1)

Formatdisplay

GeneratedisplaySensor id,

type andlocation

Formatted id,type andlocation

Sensorinformation

Setupconn

to phonenet

Gen.pulses to

lineTelephonenumber

Tone-readytelephonenumber

Dial tones

Gen.alarmsignal

Alarmtype

alarmdata

These are all the processes in the efferent branch:

Second-Level Factoring (2)

Monitorsensors

Sensor inputcontroller

Alarm condscontroller

Alarm outputcontroller

Generatealarm signal

Formatdisplay

Setup conn.to phone net

Generatedisplay

Generatepulses to line

Now, do the same for the other branches (i.e. Afferent and Central)...

For the efferent branch:

Second-Level Factoring (3)

Monitorsensors

Sensor inputcontroller

Alarm condscontroller

Alarm outputcontroller

Establishalarm conds

Select phonenumber

Selectphone

number

Configurationdata

Estab.alarmconds.

Telephonenumber

Alarm cond.Code,

sensor id, andtiming info.

List ofnumbers

Alarmdata

Sensor id,type andlocation

For central transform:

Second-Level Factoring (4)

Finally, for the afferent branch:

Monitorsensors

Sensor inputcontroller

Alarm condscontroller

Alarm outputcontroller

Acquireresponse info.

Readsensors

Readsensors

Sensor idand setting

Sensor status

Acquireresponse

info.Alarm cond.

Code,sensor id, and

timing info.

Configurationdata

Design Refinement Some degree of refinement can sometimes be carried out on the

initial “rough-cut” of the system's structure.

Monitorsensors

Sensor inputcontroller

Establishalarm conds.

Alarm outputcontroller

Generatealarm signal

Producedisplay

Setup conn.to phone net

Generatepulses to line

Readsensors

Implode (single flow)

Implode & assimilate (inherent functionality)

Implode (triviality and single flow)

What next...?

1. Check out your coupling and cohesionThis was discussed earlier

1. Check out your “fan-in” and “fan-out”Fan-in should be highFan-out should be low(see next slide)

1. Go through a predefined final check-listThis will be organisation dependent(see example two slide on)

Fanning

High fan-in example:(good)

Calculateaverage

Determinefee

Extractgender

Get unitregistration

Accessstudentrecord

High fan-out example:(watch out – usually bad)

Retrievestudent ID

Determinename

Retrieveunit list

Calculategrades

Issueresult

Calculatederived

Final Check-list ExampleTypical check-list content(Example taken and adapted form Alan Dennis: “Systems Analysis & Design”)

Library modules have been created whenever possible (reuse and portability).

The diagram has a high fan-in structure(reuse).

Control modules have no more than 7 subordinates (efficiency).

Each module performs only one distinct function(cohesive).

Modules sparingly share information(de-coupled).

Data couples passed are actually used by recipient(stamp coupling).

Control couples are passed from “child” to “parent” module?(control coupling)

Each module has a reasonable amount of code in it(a discernible system function).

Transactional Analysis(aka Transactional Mapping)

First step of this analysis is exactly the same as for transformational – i.e. refine the DFD.

The initial “SafeHome*” example will be used.

The level one DFD will be decomposed to level two as necessary.

A “transactional centre” will then be determined.

* Taken from “Software Engineering – A Practitioner's Approach” by R. S. Pressman.

Level 1 (reproduced)

Interactwithuser

configuresystem

Enable/disablesystem

Processpassword

Displaymsgs &status

Monitorsensors

Configuration data

Alarmtype

Dial tonesSensor status

Password

Startstop

Configurerequest

Configurationdata

Configurationdata

a/d msg

Valid id msg

Sensor informationConfigurationdata

Display information

User cmds anddata

Error msg

Sys parametersand data

Level 2 Example (Interact with user)

Readusercmd

Invokecmd

processing

Password

Commandtype

User commands

startstop

Configurerequest

Level 2 Example (Process password)

Readpassword

Comparepasswordwith file

Password

Four digits Invalidpassword

Produceerrormsg

Validid msg

Error msg

Configurationdata

Level 2 Example (Configure system)

Readsystem

data Raw confdata

Buildconfig

file

Configurationdata

Configurerequest

Sys parametersand data

Putting Level 2 Together

Transaction centre (dispatching)

This DFD exhibits transaction flow character.

Transaction Structure Mapping

userinteraction

Read usercmd

Invoke cmdprocessing

Enable/disable sys.

Configurationcontroller

Passwordcontroller

Refining The StructureFully refining the DFD could yield the following structure:

userinteraction

Read usercmd

Invoke cmdprocessing

Enable/disable sys.

Configurationcontroller

Passwordcontroller

Readpassword

Comparepasswordwith file

Produceerror msg

Build configfile

Read systemdata

Display msgs& status