Chapter 10

Chapter 10

Architectural Design

CHAPTER OVERVIEW AND COMMENTS

The intent 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. Students should be reminded that quality reviews need to be conducted for the architectural model work products.

10.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.

To get a discussion of software architecture started, ask your students what the architect of a building does and why it’s important. Draw parallels to software.

10.2  Data Design

This section describes data design at both the architectural and component levels. At the architecture level, data design is the process of creating a model of the information represented at a high level of abstraction (using the customer's view of data).

The discussion of KDD and data warehousing may be beyond the scope of your course and can be deemphasized without problems. However, be sure your students understand that data architecting at the system level can make or break an application.

At the component level, data design focuses on specific data structures required to realize the data objects to be manipulated by a component. Students should be reminded that careful attention to data structure design is at least as important as the effort devoted to algorithm design. If your student have not had a course in data structures and/or database design, a brief digression into these subjects might be worthwhile, if time permits.

10.3  Architectural Styles and Patterns

Be sure that your students understand that an architectural style is a transformation that is imposed on the design of an entire system. The intent is to establish a structure for all components of the system. A pattern also imposes a transformation on the design of an architecture but differs from a style as described in the introduction of this section. Patterns can be used in conjunction with an architectural style the shape the overall structure of a system.

A taxonomy of architectural styles is described in Section 10.3.1. 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 emphasized. 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.

Architectural patterns (Section 10.3.2) are relatively obvious for a house or some other physical object, but they are more abstract for software. Spend some time discussing the patterns noted in this section.

10.4  Architectural Design

The architectural design process begins by representing the system in context. Spend some time discussing the ACD presented in Figures 10.5 and 10.6 and compare it to the diagrams used for system modeling in Chapter 6.

Be sure that your students understand the meaning on an “archetype” (Section 10.4.2) and how it fits into the notion of the architectural design.

The derivation of components that populate the architecture sometime seems like a slight of hand. Be sure you provide examples of how this is done. Both good examples and bad examples might help their understanding.

10.5  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. Students might appreciate seeing an example of this approach applied to real system.

10.5  Mapping Data Flow 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 data flow diagram discussed in Chapter 8. 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.

The process of mapping a data flow diagram with transform characteristics into a specific architectural style is illustrated in Section 10.6.3. 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.

The process of performing transaction mapping (Section 10.6.4) 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.

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.