Mapping data flow into software architecture :

Transitioning from analysis to various architecture is not straightforward, and there are no
universal mapping techniques.

Structured design is a method that helps designers organize and represent the architecture of a
system. It often involves breaking down the system into smaller, more manageable modules or
components, emphasizing clear structure and organization.

 Mapping technique is specifically applicable to the call and return architecture.

 Call and return architecture is a common structure in many systems where one module
(the caller) calls another module (the callee) and expects a return when the callee
completes its task.
 Data flow diagrams represent how data moves through a system,
 Designers use the information from data flow diagrams to structure the call and return
interactions between different modules or components.
 Data flow concepts are appropriate for moving from a data flow diagram to software
architecture.
 The type of information flow is the driver for the mapping approach.

There are two types of information flow in the system.

1. Transform flow

2. Transaction flow

Transform Flow

 Information must enter and exit software in an "external world" form.

For example, data typed on a keyboard, tones on a telephone line, and video images in a
multimedia application are all forms of external world information.
 Such externalized data must be converted into an internal form for processing.
 Information enters the system along paths that transform external data into an internal form.
 These paths are identified as incoming flow .
 At the kernel of the software, a transition occurs
 Incoming data are passed through a transform center and begin to move along paths that now
lead "out" of the software.
 Data moving along these paths are called outgoing flow.
 The overall flow of data occurs in a sequential manner and follows one, or only a few, "straight
line" paths.
 When a segment of a data flow diagram exhibits these characteristics, transform flow is
present.
 Transaction Flow:
 Information flow is often characterized by a single data item, called a transaction, that
triggers other data flow along one of many paths.
 When a DFD takes the form shown in Figure 10.10, transaction flow is present.
 Transaction flow is characterized by data moving along an incoming path that converts
external world information into a transaction.
 The transaction is evaluated and, based on its value, flow along one of many action
paths is initiated.
 The hub of information flow from which many action paths emanate is called a
transaction center
 Within a DFD for a large system, both transform and transaction flow may be present.

Transform Mapping:

 Transform mapping is a set of design steps that allows a DFD with transform flow characteristics
to be mapped into a specific architectural style.
 To illustrate this approach, we again consider the SafeHome security function.
 One element of the analysis model is a set of data flow diagrams that describe information flow
within the security function.
 To map these data flow diagrams into an architecture, the following design steps are initiated:
Step I. Review the fundamental system model.

 The fundamental system model or context diagram depicts the security function as a single
transformation, representing the external producers and consumers of data that flow into and
out of the function. Figure 10.1 1 depicts a level 0 model, and Figure 10.12 depicts refined data
flow for the security function.

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

 Information obtained from the analysis models is refined to produce greater detail.
 For example, the level 2 DFD for monitor sensors (Figure 10.13) is examined, and a level 3 data
flow diagram is derived as shown in Figure 10. 14.
 At level 3, each transform in the data flow diagram exhibits relatively high cohesion .
 That is, the process implied by a transform performs a single, distinct function that can be
implemented as a component in the SafeHome software.
 Therefore, the DFD in Figure 10. 14 contains sufficient detail for a "first cut" at the design of
architecture for the monitor sensors subsystem.
 Step 3. Determine whether the DFD has transform or transaction flow characteristics.
 Evaluating the DFD (Figure 10.14), we see data entering the software along one
incoming path and exiting along three outgoing paths.
 No distinct transaction center is implied (although the transform establishes alarm
conditions that could be perceived as such). Therefore, an overall transform
characteristic will be assumed for information flow.

Step 4. Isolate the transform center by specifying incoming and outgoing flow boundaries.
 Flow boundaries for the example are illustrated as shaded curves running vertically
through the flow in Figure 10.14.
 The transforms (bubbles) that constitute the transform center lie within the two shaded
boundaries that run from top to bottom in the figure.
 A boundary (e.g., an incoming flow boundary separating read sensors and acquire
response info could be proposed)
Step 5. Perform "first-level factoring.
 The program architecture derived using these mapping results in a top-down distribution
of control.
 Factoring results in a program structure in which top-level components perform decision-
making.
 low level components perform most input, computation, and output work.
 Middle-level components perform some control and do moderate amounts of work.
 When transform flow is encountered, a DFD is mapped to a specific structure (a call and
return architecture) that provides control for incoming, transform, and outgoing
information processing.
 This first-level factoring for the monitor sensors subsystem is illustrated in Figure 10.15.
 A main controller (called monitor sensors executive) resides at the top of the program
structure and coordinates the following subordinate control functions:
 An incoming information processing controller, called sensor input controller.
coordinates receipt of all incoming data.
 A transform flow controller, called alarm conditions controller, supervises all
operations on data in internalized form (e.g.. a module that invokes various data
transformation procedures).
 An outgoing information processing controller, called alarm output controller,
coordinates production of output information.

Step 6. Perform "second-level factoring.

 Second-level factoring is accomplished by mapping individual transforms (bubbles) of a

DFD into appropriate modules within the architecture.
 Beginning at the transform center boundary and moving outward along incoming and
then outgoing paths, transforms are mapped into subordinate levels of the software
structure. The general approach to second-level factoring is illustrated in Figure 1 0. 16
 Figure 10.16 illustrates a one-to-one mapping between DFD transforms
and software modules, different mappings frequently occur.
 Two or even three bubbles can be combined and represented as one component, or a
single bubble may be expanded to two or more components.
 Second-level factoring for incoming flow follows in the same manner.
 Factoring is again accomplished by moving outward from the transform center boundary on the
incoming flow side.
 The transform center of monitor sensors subsystem software is mapped somewhat differently.
 Each of the data conversion or calculation transforms of the transform portion of the DFD is
mapped into a module subordinate to the transform controller.
 Step 7. Refine the first-iteration architecture using design heuristics for improved software
quality
 A first-iteration architecture can always be refined by applying concepts of functional
independence.
 Components are exploded or imploded to produce sensible factoring, good cohesion, minimal
coupling and most importantly, a structure that can be implemented without difficulty, tested
without confusion, and maintained without grief.

Transaction Mapping :
 In many software applications, a single data item triggers one of a number of information flows
that effect a function implied by the triggering data item. The data item, called a transaction.
 Transaction mapping will be illustrated by considering the user interaction subsystem of the
SafeHome security function.
 Level 1 data flow for this subsystem is shown as part of Figure 10.12.
 Refining the flow, a level 2 data flow diagram is developed and shown in Figure 10.19.
 The data object user commands flows into the system and results in additional information flow
along one of three action paths.
 A single data item, command type, causes the data flow to fan out- ward from a hub.
 Therefore, the overall data flow characteristic is transaction oriented.
 Information flow along two of the three action paths a accommodates additional incoming flow
(e.g. , system parameters and data are in- put on the "configure" action path). Each action path
flows into a single transform, display messages and status.

Steps to Transaction mapping:

Step 1 . Review the fundamental system model.

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

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

 Steps 1,2, and 3 are identical to corresponding steps in transform mapping.

 The DFD shown in Figure 10.19 has a classic transaction flow characteristic
 Flow along two of the action paths emanating from the invoke command processing bubble
appears to have transform flow characteristics. Therefore, flow boundaries must be established
for both flow types.

Step 4. Identify the transaction center and the flow characteristics along each of the action paths.
 The location of the transaction center can be immediately find out from the DFD
 The transaction center lies at the origin of a number of actions paths that flow radially from it.
 For the flow shown in Figure 10.19, the invoke command processing bubble is the transaction
center.
 The incoming path (i.e., the flow path along which a transaction is received) and all action paths
must also be isolated.
 Each action path must be evaluated for its individual flow characteristic.
 For example, the "password" path (shown enclosed by a shaded area in Figure 10.19) has
transform characteristics.
 Incoming, transform, and outgoing flow are indicated with boundaries.

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

 Transaction flow is mapped into an architecture that contains an incoming branch and a
dispatch branch.
 Starting at the transaction center, bubbles along the incoming path are mapped into
modules.
 The structure of the dispatch branch contains a dispatcher module that controls all
subordinate action modules
 Each action flow path of the DFD is mapped to a structure that corresponds to its specific
flow characteristics.
 Considering the user interaction subsystem data flow, first-level factoring for step 5 is
shown in Figure 10.21,
 The bubbles read user command and activate/deactivate system map directly into the
architecture without the need for intermediate control modules.
 The transaction center, invoke command processing, maps directly into a dispatcher
module of the same name.
 Controllers for system configuration and pass- word processing are created as illustrated in
Figure 10.2

 Considering the user interaction subsystem data flow, first-level factoring for step 5 is
shown in Figure 10.21
 The bubbles read user command and activate/deactivate system map directly into the
architecture without the need for intermediate control modules
 The transaction center, invoke command processing, maps directly into a dispatcher
module of the same name.
 Controllers for system configuration and pass- word processing are created as illustrated in
Figure 10.21
Step 6. Factor and refine the transaction structure and the structure of each action path.
 Each action path of the data flow diagram has its own information flow characteristics.
 As an example, consider the password processing information flow shown (inside
shaded area) in Figure 10.19.
 The flow exhibits classic transform characteristics.
 A password is input (incoming flow) and transmitted to a transform center where it is
compared against stored passwords.
 An alarm and warning message (outgoing flow) are produced {if a match is not
obtained). The "configure'1 path is drawn similarly using the transform mapping. The
resultant software architecture is shown in Figure 10.22.

Step 7. Refine the first-iteration architecture using design heuristics for improved
software quality.
 This step for transaction mapping is identical to the corresponding step for transform
mapping. In both design approaches, criteria such as module independence,
practicality (efficacy of implementation and test), and maintainability must be carefully
considered as structural modifications are proposed.

5. Refining the Architectural Design:

 Design refinement should strive for the smallest number of components that is
consistent with effective modularity and the least complex data structure that
adequately serves information requirements.