Software requirements can be mapped into various representations of the design model. The architectural styles represent radically differen...
Software requirements can be mapped into various representations of the design model. The architectural styles represent radically different architectures, so it should come as no surprise that a comprehensive mapping that accomplishes the transition from the requirements model to a variety of architectural styles does not exist. In fact, there is no practical mapping for some architectural styles, and the designer must approach the translation of requirements to design for these styles in an ad hoc fashion.
To illustrate one approach to architectural mapping, we consider the call and return architecture—an extremely common structure for many types of systems. The mapping technique to be presented enables a designer to derive reasonably complex call and return architectures from data flow diagrams within the requirements model. The technique, sometimes called structured design, has its origins in earlier design concepts that stressed modularity , top-down design , and structured programming . Stevens, Myers, and Constantine were early proponents of software design based on the flow of data through a system. Early work was refined and presented in books by Myers and Yourdon and Constantine.
Structured design is often characterized as a data flow-oriented design method because it provides a convenient transition from a data flow diagram to software architecture. The transition from information flow (represented as a DFD) to program structure is accomplished as part of a six-step process: (1) the type of information flow is established; (2) flow boundaries are indicated; (3) the DFD is mapped into program structure; (4) control hierarchy is defined; (5) resultant structure is refined using design measures and heuristics; and (6) the architectural description is refined and elaborated.
The type of information flow is the driver for the mapping approach required in step 3. In the following sections we examine two flow types.
Transform Flow
Recalling the fundamental system model (level 0 data flow diagram), 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
The fundamental system model implies transform flow; therefore, it is possible to characterize all data flow in this category. However, 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, transaction flow is present.
Transaction flow is characterized by data moving along an incoming path that converts xternal 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.
It should be noted that, within a DFD for a large system, both transform and transaction flow may be present. For example, in a transaction-oriented flow, information flow along an action path may have transform flow characteristics.
