Chapter 14Software Design

CHAPTER OVERVIEW AND COMMENTS

The objective of this chapter is to provide a systematic approach for the derivation of the architectural design. Architectural design encompasses both the data architecture and the program structure layers of the design model. A general introduction to software architecture is presented. Examples are presented to illustrate the use of transform mapping and transaction mapping as means of building the architectural model using structured design approach. Architectural modeling of object-oriented systems appears later in the text. Students should be reminded that quality reviews need to be conducted for the architectural model work products.

14.1 Software Architecture

This section defines the term software architecture as a framework made up of the system structures that comprise the software components, their properties, and the relationships among these components. The goal of the architectural model is to allow the software engineer to view and evaluate the system as a whole before moving to component design. Students should be encouraged to build architectural models of their own software development projects.

14.2 Data Design

This section describes data design as the process of creating a model of the information represented at a high level of abstraction (using the customer's view of data). Students should be reminded that careful attention to data structure design is at least as important as the effort devoted to algorithm design. Students should make an effort to learn definitions for the terms data modeling, data structure, database, and

data warehouse. Students should be encouraged to use the principles of component level data design presented in this section.

14.3 Architectural Styles

A taxonomy of architectural styles (design patterns) is described in this section. With the exception of object-oriented architectures, the architecture modeling technique discussed in this chapter is generally applicable to each of these architectural styles. However, the derivation of the call and return architecture is emphasizes. Students should be encouraged to use the questions dealing with control and data issues as basis for assessing the quality of the initial architectural framework before doing more detailed analyses of the proposed software architecture.

14.4 Analyzing Alternative Architectural Designs

This section provides students with an iterative method for performing trade-off analyses of alternative architectural designs for the same software system. Students should find enough information in this section to be able to apply this technique to their own architectural designs. The second approach presented in this section applies pseudo quantitative techniques as a means of assessing the quality of an architectural design.

14.5 Mapping Requirements into Software Architecture

This section describes the general process of mapping requirements into software architectures during the structured design process. The technique described in this chapter is based on analysis of the system data flow diagram. The key point to get across to students is the difference between transform flow and transaction flow. Transform flow is largely sequential and has very little divergence along the action path. Transaction flow can follow many action paths and the processing of a single data item often triggers path selection.

14.6 Transform Mapping

The process of mapping a data flow diagram with transform characteristics into a specific architectural style is illustrated in this section. Students should be reminded to strive for DFD bubbles that exhibit high cohesion. Students should be told that both transform and transaction flows may occur in the same DFD. Each subflow should be classified and mapped using the appropriate technique (transform or transaction). Students may need to see more than one example of transform mapping before they attempt to do it on their own.

14.7 Transaction Mapping

The process of performing transaction mapping is presented as being similar to transform mapping, but focusing on transaction (not transform) centers. In transaction mapping, the first level factoring results in the derivation of the control hierarchy. The second level factoring distributes the low-level modules among the appropriate controller.

14.8 Refining the Architectural Design

Refining the architectural model involves writing a fair amount of documentation (e.g. process narratives, interface descriptions, limitations, etc.) and reviewing work products for quality. Student projects need to be subjected to the refinement process before detailed design work is undertaken. It may be worthwhile to have the students look over the design document template from the SEPA web site to see where they need to go next with their design work.

PROBLEMS AND POINTS TO PONDER

14.1 The concepts of styles and patterns occur for buildings and software at both macroscopic and microscopic levels. For example, overall styles (center-hall colonial, A-frame) can be found in a house. These represent macroscopic styles. Lower-level microscopic patterns (for a house) can be found in categories of wood molding, fireplace designs, windows, etc.

14.3 A data warehouse is a global repository for information gathered from many corporate sources.

14.5 Data centered architecture: airline reservation system; library catalog system; hotel booking systemData flow architecture: any engineering/scientific application where computation is the major functionCall and return architecture: any I-P-O applicationObject-oriented architectures: GUI-based applications; any OO applicationLayered architecture: any application in which the application functions must be decoupled from the underlying OS or network detail. Client server software is often layered.

14.11 When transform mapping is used where transaction mapping should be used, two problems arise: (1) the program structure tends to become top heavy with control modules—these should be eliminated; (2) significant data coupling occurs because information associated with one of many "processing actions" must be passed to an outgoing path.

Classic examples include:

- many engineering analysis algorithms

- many process control applications

- some commercial applications

Look for a well-developed DFD and correct mapping to program structure.