Chapter 7 Design methods

Design has been described :  Design shares with programming a concern for abstracting information representation Representations of data structure program structure interface characteristics procedural detail  Design is information driven  a guide for the creation of the design :  the blueprint from which software is constructed ---- the data domains ---- functional domains ---- behavioral domains

7.1 Data design  Data design :  the concepts of information hiding and data abstraction provide the foundation for an approach to data design  the primary activity during data design is to select logical representations of data objects identified during the requirements definition and specification phase is the first of four design activities is to identify those program modules during design  An important related activity :

 well-designed data : lead to better program structure lead to modularity reduced procedural complexity  we consider the following set principles : 1. the systematic analysis principles applied to function and behavior should also be applied to data Representations of data objects, relationships, data flow, and content should be developed and reviewed

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

7.2 Architectural design  The primary objective of architectural design :  Architectural design : melds program structure and data structure is to develop a modular program structure represent the control relationships between modules defining interfaces that enable data to flow throughout the program

For example You’ve saved your money, you’ve purchased a beautiful piece of land, and you’ve decided to build the house of your dreams. Having no experience in such matters, you visit a builder and explain your desires-number and size of rooms, contemporary styling, spa(of course!), cathedral ceilings, lots of glass, etc.The builder listens carefully, asks a few questions, and then tells you that he’ll have a design in a few weeks. As you wait anxiously for his call, you conjure up many different (and outrageously expensive) images of your new house. What will he come up with? Finally, the phone ring and you rush to his off ice. Pulling out a large manila folder, the builder spreads a diagram of the plumbing for the second floor bathroom in front of you and proceeds to explain it in great detail. “But what about the overall design?” you say. “Don’t worry,” says the builder, “we’ll get to that later.”

Does the builder ’ s approach seem a bit unusual? they concentrate on the “ plumbing ” ( procedural details and code) to the exclusion of the software architecture.

7.3 The architectural design process  Data flow-oriented design : is an architectural design method allows a convenient transition from the analysis model to a design description of program structure

The transition from information flow to structure is accomplished as part of a five –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 by factoring; (5) the resultant structure is refined using design measures and heuristics.

7.3.1 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  At the kernel of the software, a transition occurs.  Incoming data are passed through a “ transform center ” and begin to move along paths that lead out of the software ---- pictures in a computer graphics display “ transform center ”

Internal representation Information External representation Time Incoming flow Transform flow Outgoing flow Figure 7.1 Flow of information

7.3.2 Transaction flow  Information flow is often characterized by a single data item ---- called a transaction  A transaction triggers other data flow along one of many paths transaction flow  The hub of information flow from which many action paths emanate ---- transaction center

T Transaction request … … … Action paths … … Figure 7.2 Transaction Flow It should be noted that within a DFD for a large system, both transform and transaction flow may be present

7. 4 Transform mapping  Transform mapping : ---- is set of design steps ---- allows a DFD with transform flow characteristics to be mapped into a predefined template for program structure

7.4.1 An example  the Safehome security system : the product monitors the real world it interacts with a user ---- reacts to changes that it encounters ---- a series of typed input and alphanumeric displays  The level 0 DFD for Safehome in figure 7.3

Figure 7.3 Context-level DFD for Safehome

7.4.2 design steps  design : ---- begin with a re-evaluation of work done during requirements analysis ---- move to the development of program structure  Step1 : Review the fundamental system model ---- the level 0 DFD ---- supporting information  Seven Steps :

Figure 7.3 Context-level DFD for Safehome

Figure 7.4 level 1 DFD for Safehome

 Step 2 : review and refine data flow diagrams for the software For example ---- Information obtained from analysis models contained in the software requirements specification is refined to produce greater detail ---- the level 2 DFDs for monitor sensors ( figures 7.4 and 7.5 ) are examined, and a level 3 data flow diagram is derived as shown in figure 7.6

Figure 7.5 level 2 DFD for Safehome

At level 3, each transform in the data flow diagram exhibits relatively high cohesion `

 Step 3 : determine whether the DFD has transform or transaction flow characteristics ---- Information flow within a system can always be represented as a transform For example ---- Level 3 DFD for monitor sensors ---- the designer selects a global flow characteristic based on the prevailing nature of the DFD ---- These subflows can be used to refine program structure

One coming path Three outgoing path

 Step 4 : Isolate the transform center by specifying incoming and outgoing flow boundaries ---- Incoming flow was described as a path from external to internal form ---- Outgoing flow converts from internal to external form ---- Alternative design solutions can be derived by varying the placement of flow boundaries For example ---- level 3 DFD for monitor sensors with flow boundaries

Figure 7.6 level 3 DFD for monitor sensors with flow boundaries Flow boundary

 Step 5 : Perform “ first-level factoring ” Factoring results in some layer modules top-level modules : ---- perform decision making low-level modules : ---- perform most input, computational, and output work middle-level modules : ---- perform some control and do moderate amounts of work

When transform flow is encountered : ---- a DFD is mapped to a specific structure that provides control for incoming, transform, and outgoing information processing For example ---- This first-level factoring for the monitor sensors subsystem in figure 7.7

Figure 7.7 First factoring for monitor sensors An incoming information processing controller, Sensor input controller, coordinates receipt of all incoming data A transform flow controller, supervises all operations on data in internalized form An outgoing information processing controller, coordinates production of output information. program structure The number of modules at the first level should be limited to the minimum

 Step 6 : Perform “second-level factoring.” Second-level factoring : ---- is accomplished by mapping individual transforms of a DFD into appropriate modules within the program structure ---- Steps : beginning at the transform center moving outward along incoming and outgoing paths transforms are mapped into subordinate levels of the software structure Second level for monitor sensors ---- For example :

Figure 7.8 Second level factoring for monitor sensors A one-to-one mapping between DFD transforms and software modules

Figure 7.9 “First-cut” program structure for monitor sensors

 The narrative describes : ---- Information that passes into and out of the module ---- Information that is retained by a module ---- A procedural narrative ---- A brief discussion of restrictions and special features  The narrative serves as a first generation design specification e.g., data stored in a local data structure Indicates major decisions points and tasks file I/O hardware dependent characteristics special timing requirements ……

 Step 7 : Refine the first iteration program structure using design heuristics for improved software quality ---- By applying concepts of module independence ---- Modules are exploded or imploded to produce sensible factoring, good cohesion, minimal coupling ---- Most important, a structure that can be : ---- Safehome monitou sensors subsystem For example implemented without difficulty tested without confusion maintained without grief

Figure 7.10 Refined program structure for monitor sensors

 The objective of the preceding seven steps is to develop a global representation of software ---- once structure is defined, we can evaluate and refine software architecture by viewing it as a whole.  That is : ---- If code is the only representation of software, the developer will have great difficulty evaluating or refining at a global or holistic level “ seeing the forest for the trees ”

7. 5 Transaction mapping  Transaction : ---- is a data item ---- I n many software applications, a single data item triggers one or a number of information flows that effect a function implied by the triggering data item

7.5.1 An example  The Safehome software : ---- User interaction subsystem Level 1 data flow diagram is shown in figure 7.4 Level 2 data flow diagram is shown in figure 7.11

Figure 7.4 level 1 DFD for Safehome

Figure 7.11 Level 2 DFD for use interaction subsystem ` `

7.5.2 Design steps  Design steps for transaction mapping are similar  Steps treat transaction flow :  a major difference lies in the mapping of the DFD to software structure ---- 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

---- 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 discerned from the DFD. The transaction center lies at the origin of a number of actions paths that flow radially from it. The incoming path all action paths must also be isolated Show in figure 7.11

---- Each action path must be evaluated for its individual flow characteristic. For example, the “ password ” path has transform characteristics. Incoming, transform and outgoing flow are indicated with boundaries Transaction center Incoming path

---- Step 5. Map the DFD in a program structure amenable to transaction processing Transaction flow is mapped into a program structure Contains : ---- an incoming branch ---- 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 modules

Figure 7.12 Transaction mapping An incoming branch Transaction center A dispatch branch

 Deriving Program ArchitectureProgramArchitecture Data Flow Diagram  Two or even three bubbles can be combined and represented as one module  A single bubble any be expanded to two or more modules

Figure 7.13 First-level factoring for user interaction subsystem

---- Step 6. Factor and refine the transaction structure and the structure of each action path As an example, consider the password processing information flow ( inside shaded area )

---- Step 7. Refine the first iteration program structure using design heuristics for improved software quality The resultant program structure is shown in figure 7.7..

Figure 7.7 First-cut program structure for user interaction subsystem

7.6 Design postprocessing  Successful application of transform or transaction mapping of supplemented  Following tasks must be completed : A processing narrative must be developed for each module ---- A processing narrative is (ideally ) an unambiguous ---- bounded description of processing ---- The narrative describes processing tasks, decisions, and I/O

An interface description is provided for each module ---- the design of internal nodule interfaces ---- external system interfaces ---- the human-computer interface ---- Establish the basic data model ---- Identify all important data objects Local and global data structures are defined All design restrictions/limitations are noted ---- timing limitations ---- Bounding values or quantities of data structures ---- Special cases not considered ---- Specific characteristics of an individual module

A design review is conducted ----Traceability to software requirements ----Quality of program structure ----Interface descriptions ----Data structure descriptions ----Implementation and test practicality ----Maintainability “ optimization ” is considered

7.7 Architectural design optimization  The software designer should be concerned with developing a software that will meet all functional and performance requirements ---- Refinement of software structure ---- Design optimization should strive for the smallest number of modules ---- The least complex data structure

!