Chapter 14: Design Method --- data and architectural design Design -- A multistep process in which representations of data structure, program structure, interface characteristics, and procedural detail are synthesized.

December 25, 1997 R. A. Volz -- Assistance - Haichen Liu, Brian Bolstad 2 Why Architecture? The architecture is not the operational software. Rather, it is a representation that enables a software engineer to: (1) analyze the effectiveness of the design in meeting its stated requirements, (2) consider architectural alternatives at a stage when making design changes is still relatively easy, and (3) reduce the risks associated with the construction of the software.

December 25, 1997 R. A. Volz -- Assistance - Haichen Liu, Brian Bolstad 3 Why is Architecture Important? l Representations of software architecture are an enabler for communication between all parties (stakeholders) interested in the development of a computer-based system. l The architecture highlights early design decisions that will have a profound impact on all software engineering work that follows and, as important, on the ultimate success of the system as an operational entity. l Architecture “constitutes a relatively small, intellectually graspable model of how the system is structured and how its components work together” [BAS03].

December 25, 1997 R. A. Volz -- Assistance - Haichen Liu, Brian Bolstad 4 Data Design l What is data design? n Transform the information domain model created during analysis into data structure required to implement the software n Well-designed data lead to better program structure and modularity, reduced procedural complexity

December 25, 1997 R. A. Volz -- Assistance - Haichen Liu, Brian Bolstad 5 Data Design l At the architectural level … n Design of one or more databases to support the application architecture n Design of methods for ‘mining’ the content of multiple databases –navigate through existing databases in an attempt to extract appropriate business-level information –Design of a data warehouse—a large, independent database that has access to the data that are stored in databases that serve the set of applications required by a business

December 25, 1997 R. A. Volz -- Assistance - Haichen Liu, Brian Bolstad 6 Data Design l At the component level … n refine data objects and develop a set of data abstractions n implement data object attributes as one or more data structures n review data structures to ensure that appropriate relationships have been established n simplify data structures as required

December 25, 1997 R. A. Volz -- Assistance - Haichen Liu, Brian Bolstad 7 Data Design Process l Define data structures identified during the requirements and specification phase. n Often base decision on algorithm to be used. l Identify all program modules that must operate directly upon the data structure n Constrain the scope of effect of data design decisions l Or, from OO perspective, define all operations performed on the data structure

December 25, 1997 R. A. Volz -- Assistance - Haichen Liu, Brian Bolstad 8 Principles of Data Design (Component Level) l A data dictionary should be established and used for both data and program design l Low-level data design decisions should be deferred until late in the design process l A library of useful data structures and the operations that may be applied to them should be developed. -- Reuse n E.g., stacks, lists, arrays, queues

December 25, 1997 R. A. Volz -- Assistance - Haichen Liu, Brian Bolstad 9 Principles of Data Design (cont.) l The representation of data structures should be known only to those modules that must make direct use of the data contained within the structure. n Information hiding l The software design and programming languages should support the specification and realization of abstract data types.

December 25, 1997 R. A. Volz -- Assistance - Haichen Liu, Brian Bolstad 10 Architectural Styles l Data-centered architectures l Data flow architectures l Call and return architectures l Object-oriented architectures l Layered architectures Each style describes a system category that encompasses: (1) a set of components (e.g., a database, computational modules) that perform a function required by a system, (2) a set of connectors that enable “communication, coordination and cooperation” among components, (3) constraints that define how components can be integrated to form the system, and (4) semantic models that enable a designer to understand the overall properties of a system by analyzing the known properties of its constituent parts.

December 25, 1997 R. A. Volz -- Assistance - Haichen Liu, Brian Bolstad 11 Data-Centered Architecture

December 25, 1997 R. A. Volz -- Assistance - Haichen Liu, Brian Bolstad 12 Data Flow Architecture

December 25, 1997 R. A. Volz -- Assistance - Haichen Liu, Brian Bolstad 13 Call and Return Architecture

December 25, 1997 R. A. Volz -- Assistance - Haichen Liu, Brian Bolstad 14 Layered Architecture

December 25, 1997 R. A. Volz -- Assistance - Haichen Liu, Brian Bolstad 15 Architectural Design l Objective n develop a modular program structure and represent control relationships between modules l Data flow-oriented design (Structured design) n amenable to a broad range of applications n very useful when information is processed sequentially, such as microprocessor control application; complex, numerical analysis procedure; etc. n two approaches (transform and transaction mapping)

December 25, 1997 R. A. Volz -- Assistance - Haichen Liu, Brian Bolstad 16 Structured Design l objective: to derive a program architecture that is partitioned l approach: n the DFD is mapped into a program architecture n the PSPEC and STD are used to indicate the content of each module l notation: structure chart

December 25, 1997 R. A. Volz -- Assistance - Haichen Liu, Brian Bolstad 17 Architectural Design Process l Five-step Process n the type of information flow is established n flow boundary are indicated n data flow diagram is mapped into program structure n control hierarchy is defined by factoring n resultant structure is refined using design measures heuristics

December 25, 1997 R. A. Volz -- Assistance - Haichen Liu, Brian Bolstad 18 Architectural Design Process (cont.) l Transform Flow A B transform center incoming flow outgoing flows C

December 25, 1997 R. A. Volz -- Assistance - Haichen Liu, Brian Bolstad 19 Architectural Design Process (cont.) l Transaction Flow T Transaction center Transaction Action paths

December 25, 1997 R. A. Volz -- Assistance - Haichen Liu, Brian Bolstad 20 Transform Mapping l Allow data flow diagram(DFD) with transform flow characteristics to be mapped into a predefined template for program structure

December 25, 1997 R. A. Volz -- Assistance - Haichen Liu, Brian Bolstad 21 Level 0 Safehome DFD

December 25, 1997 R. A. Volz -- Assistance - Haichen Liu, Brian Bolstad 22 Level 1 Safehome DFD

December 25, 1997 R. A. Volz -- Assistance - Haichen Liu, Brian Bolstad 23 Level 2 Safehome DFD - Monitor

December 25, 1997 R. A. Volz -- Assistance - Haichen Liu, Brian Bolstad 24 Transform Mapping (cont) l Design steps n Step 1. Review the fundamental system model. n Step 2. Review and refine data flow diagrams for the software. n Step 3. Determine whether DFD has transform or transaction flow characteristics. –in general---transform flow –special case---transaction flow

December 25, 1997 R. A. Volz -- Assistance - Haichen Liu, Brian Bolstad 25 Level 3 DFD for Monitor Sensors

December 25, 1997 R. A. Volz -- Assistance - Haichen Liu, Brian Bolstad 26 Transform Mapping (cont) l step 4. Isolate the transform center by specifying incoming and outgoing flow boundaries n different designers may select slightly differently n transform center can contain more than one bubble. l step 5. Perform “first-level factoring” n program structure represent a top-down distribution control. n factoring results in a program structure(top-level, middle-level, low-level) n number of modules limited to minimum.

December 25, 1997 R. A. Volz -- Assistance - Haichen Liu, Brian Bolstad 27 First Level Factoring

December 25, 1997 R. A. Volz -- Assistance - Haichen Liu, Brian Bolstad 28 Transform Mapping (cont) n step 6. Perform “second-level factoring” –mapping individual transforms(bubbles) to appropriate modules. –factoring accomplished by moving outwards from transform center boundary. n step 7. Refine the first iteration program structure using design heuristics for improved software quality.

December 25, 1997 R. A. Volz -- Assistance - Haichen Liu, Brian Bolstad 29 Second Level Factoring

December 25, 1997 R. A. Volz -- Assistance - Haichen Liu, Brian Bolstad 30 First-Cut Program Structure

December 25, 1997 R. A. Volz -- Assistance - Haichen Liu, Brian Bolstad 31 Refined Program Structure

December 25, 1997 R. A. Volz -- Assistance - Haichen Liu, Brian Bolstad 32 Transaction Mapping A single data item triggers one or more information flows

December 25, 1997 R. A. Volz -- Assistance - Haichen Liu, Brian Bolstad 33 Transaction Mapping Design l Step 1.Review the fundamental system model. l Step 2.Review and refine DFD for the software l Step 3.Determine whether the DFD has transform or transaction flow characteristics l Step 4. Identify the transaction center and flow characteristics along each of the action paths –isolate incoming path and all action paths –each action path evaluated for its flow characteristic.

December 25, 1997 R. A. Volz -- Assistance - Haichen Liu, Brian Bolstad 34 Transaction Mapping (cont) l step 5. Map the DFD in a program structure amenable to transaction processing n incoming branch –bubbles along this path map to modules n dispatch branch –dispatcher module controls all subordinate action modules –each action path mapped to corresponding structure

December 25, 1997 R. A. Volz -- Assistance - Haichen Liu, Brian Bolstad 35 Transaction Mapping

December 25, 1997 R. A. Volz -- Assistance - Haichen Liu, Brian Bolstad 36 First Level Factoring

December 25, 1997 R. A. Volz -- Assistance - Haichen Liu, Brian Bolstad 37 First-cut Program Structure

December 25, 1997 R. A. Volz -- Assistance - Haichen Liu, Brian Bolstad 38 Transaction Mapping (cont) l step 6. Factor and refine the transaction structure and the structure of each action path l step 7. Refine the first iteration program structure using design heuristics for improved software quality

December 25, 1997 R. A. Volz -- Assistance - Haichen Liu, Brian Bolstad 39 Design Postprocessing l A processing narrative must be developed for each module l An interface description is provided for each module l Local and global data structures are defined l All design restrictions/limitations are noted l A design review is conducted l “Optimization” is considered (if required and justified)

December 25, 1997 R. A. Volz -- Assistance - Haichen Liu, Brian Bolstad 40 Summary - Data & Architectural l Data design translates the data objects defined in the analysis model into data structure that reside with in the software l Architectural design use information flow characteristics described in the analysis model to derive program structure l DFD is mapped into program structure use two approaches: transform and transaction mapping