Chapter 11

Chapter 11

Component-Level Design

CHAPTER OVERVIEW AND COMMENTS

This chapter discusses the portion of the software development process where the design is elaborated and the individual data elements and operations are designed in detail. First, different views of a “component” are introduced. Guidelines for the design of object-oriented and traditional (conventional) program components are presented.

Note:    This is as close as SEPA gets to a discussion of coding. If you want to have your students implement software so that it is executable, the discussion of component-level design can be extended to show how the design is implemented in a programming language.

11.1  What is a Component?

This section defines the term component and discusses the differences between object-oriented, traditional, and process related views of component-level design.

UML defines a component as “… a modular, deployable, and replaceable part of a system that encapsulates implementation and exposes a set of interfaces.” You should parse this definition for your students, discussion each important phrase within the context of component-level design.

Be certain that your students understand the rather fundamental difference between the object-oriented and conventional (traditional) view of a software component. In addition, the idea of different categories of components (e.g., control, problem domain, infrastructure) should be discussed.

Finally, the process (CBSE) view of a component should be presented. Middleware components should be discussed, but there is no need to emphasize them if time is short.

11.2  Designing Class-Based Components

Spend some time on the basic design principles presented in Section 10.2.1. It would be a good idea to provide additional examples to help your students understand each.

The guidelines presented in Section 10.2.2 are worthy of classroom discussion. Again additional examples will enhance understanding.

The concepts of cohesion and coupling are very important. Be certain that your students (1) understand what they are in this context and (2) know how to create component designs that achieve them. The sidebars presented in Sections 11.2.3 and 11.2.4 can be discussed in class to help cement student understanding.

11.3  Conducting Component-Level Design

The steps discussed in this section provide a reasonable task set for designing a component. You should emphasize that (1) design classes in the problem domain are usually custom-designed, however, if an organization has encouraged design for reuse, there may be an existing component that fits the bill; (2) design classes corresponding to the infrastructure domain can sometimes be often from existing class libraries; (3) a UML collaboration diagram provides an indication of message passing between components.

The printing system example presented in this section can be elaborated to provide your students with a more in-depth view of the component design process.

The quote by Blaise Pascal deserves mention in the classroom. Too often, there is a tendency to develop complex designs for relatively simple functions. Stress simplicity!

Discuss refactoring as a design tactic and provide a few simple examples using source code or PDL.

11.4  Object Constraint Language

OCL is described here briefly and again in Chapter 28 (in the context of formal specification). You need not go into great detail, but you should emphasize that OCL enables designers (or specifiers) to describe constraints in a formal, unambiguous manner.

The OCL example provided within this section is normally sufficient for most software engineering courses.

Your students may benefit from trying to use OCL to write the pre- and post-conditions for a their own components. If you are emphasizing traditional design in your course, this section may be skipped without loss of continuity.

11.5  Designing Traditional Components

This section reviews the elements of the structured programming and a number of representation techniques for procedural design. Students may need to see examples of representing algorithms using flowcharts, if they are not familiar with them from earlier course work. Be sure to note that UML activity diagrams can be used in lieu of flowcharts.

Decision tables are discussed as an example of a tabular tool for representing the connections between conditions and actions. Students will benefit from the experience of developing decision tables for their own projects.

Program design language (PDL) is discussed in detail in this section. The hardest part about getting students to express their designs using a PDL is getting them to stop trying to write directly in their favorite programming language (C++, Java, etc.). Students often fail to distinguish between low level design and implementation. Requiring students to include pseudocode representations of their algorithms as part of the module design documentation seems to help them understand some of the differences between the two.

Section 11.5.4 presents criteria for assessing the usefulness of particular design notations. If your course is more than one semester long, students may benefit from writing comparative evaluations of two different design notations or program design languages. If your students have access to automated tools, evaluating the design notations supported can be a worthwhile activity.