Chapter 30

Chapter 30

Component-Based Software Engineering

CHAPTER OVERVIEW AND COMMENTS

This chapter describes component-based software engineering (CBSE) as a process that emphasizes the design and construction of systems with reusable software components. CBSE has two parallel engineering activities, domain engineering (discussed earlier in the text) and component-based software development. The important point to emphasize to students is that custom software components are only created when existing components cannot be modified for reuse in the system under development. It is also important to remind students that formal technical reviews and testing are still used to ensure the quality of the final product. The advantage, of course, is that less time is spent designing and coding, so software can be produced less expensively. Students would benefit from having access to a library of commercial off-the-shelf components or at least a locally developed component library.

30.1  Engineering of Component-Based Systems           

It is important to have students understand the differences between CBSE and object-oriented software engineering. The biggest difference is that in CBSE, after the architectural design is established, the software team examines the requirements to see which can be satisfied by reusing existing components rather than constructing everything from scratch. In object-oriented software engineering, developers begin detailed design immediately after establishing the architectural design. Students need to understand the software activities that take place once reusable components are identified (component qualification, component adaptation, component composition, and component update).  These activities will be described in more detail later in the chapter. It may be worthwhile for students to be given a set of requirements and an indexed collection of reusable components and try to determine which requirements can be satisfied by the reusable component and which cannot.

30.2  The CBSE Process

This is a short section that contains schematic diagrams (Figure 30.1) for the two CBSE engineering activities (domain engineering and component-based engineering). Be sure students understand the interrelationships between the domain engineering and component-based engineering activities. The activities are discussed in more detail in the subsequent chapter sections.

30.3  Domain Engineering

Students should make sure they understand the three major domain engineering activities (analysis, construction, and dissemination). It is important for students to remember is that the purpose of conducting domain analysis is to identify reusable software components. Structural modeling is an important pattern-based domain engineering approach. Students may benefit from trying to conduct their own domain analysis. Alternatively, they may benefit from discussing a real world case study that includes domain analysis.

A useful exercise is to have students identify domain classes (or functions) for a domain such as “retailing” or “health care.”

30.4  Component-Based Development

Component-based software development activities are discussed in detail in this section. If students have access to a library of reusable components (or COTS components) they should be encouraged to use the composition techniques presented to assemble a new software product. Students may benefit from using one of the free component libraries like JavaBeans. Another good exercise might be to have students try to design one of their own software components so that is can be added to an existing software reuse library.

30.5  Classifying and Retrieving Components

This section discusses the issues associated with indexing and retrieving software components from a reuse library.  It also describes the necessary features for a component reuse environment. The material is presented at a fairly general level. If your students are familiar with multimedia databases and client-server computing, you might explore some of the implementation concerns that need to be addressed to construct a reuse repository by examining a real life example of one.

27.6  Economics of CBSE

This section discusses the economics of software reuse by examining its impact on software quality, programmer productivity, and system development cost. The calculations are not hard to follow. Students might appreciate seeing the benefits gained from reuse by examining project data from a real world example. Some discussion of structure points during project estimation appears in this section. Students might appreciate seeing a complete example that uses structure points as part of the cost estimation process. Some reuse metrics are defined. Students might be encouraged to compute the reuse metrics for their own software projects.

Chapter 29

Chapter 29

Cleanroom Software Engineering

CHAPTER OVERVIEW AND COMMENTS

The late Harlan Mills (one of the true giants of the first half century of computing) suggested that software could be constructed in a way that eliminated all (or at least most) errors before delivery to a customer. He argued that proper specification, correctness proofs, and formal review mechanisms could replace haphazard testing, and as a consequence, very high quality computer software could be built. His approach, called cleanroom software engineering, is the focus of this chapter.

The cleanroom software engineering strategy introduces a radically different paradigm for software work. It emphasizes a special specification approach, formal design, correctness verification,  “statistical” testing, and certification as the set of salient activities for software engineering. The intent of this chapter is to introduce the student to each of these activities.

The chapter begins by introducing box structure specification and a more rigorous approach for representing the analysis model.  Next define refinement of the box structure specification is presented, followed by the correctness proofs that can be applied to the specification to verify that it is correct. The cleanroom approach to testing is radically different that more conventional software engineering paradigms. The culmination of this chapter is to emphasize the cleanroom testing approach.

The key concepts for students to understand are boxes, formal verification, probability distributions, and usage based testing. The mathematics and statistical background needed to read the chapter is not overwhelming. However, if you want to have your students do some cleanroom software development, you may need to do some additional teaching on program verification and statistical sampling.

Note:  Cleanroom software engineering has not been widely adopted in the industry, and for that reason, a number of reviewers for SEPA 6/e suggested that the chapter could be deleted. I disagree. Although the complete cleanroom paradigm may not be widely used, the individual elements of the approach have significant merit and provide students with insight that they may not otherwise obtain. Even if they don’t use cleanroom, your students can certainly adopt and use things like statistical use testing or proofs of correctness.

29.1  The Cleanroom Approach

This section introduces the key concepts of cleanroom software engineering and discusses its strengths and weaknesses. An outline of the basic cleanroom strategy is presented. Students will need some additional information on the use of box specifications and probability distributions before they can apply this strategy for their own projects.

29.2  Functional Specification

Functional specification using boxes is the focus of this section. It is important for students to understand the differences between black boxes (specifications), state boxes (architectural designs), and clear boxes (component designs). Even if students have weak understanding of program verification techniques, they should be able to write box specifications for their own projects using the notations shown in this section.

29.3  Cleanroom Design

If you plan to have your students verify their box specifications formally, you may need to show them some examples of the techniques used (if you did not already do so when covering Chapter 28). The key to making verification accessible to students at this level is to have them write procedural designs using only structured programming constructs in their designs. This will reduce considerably the complexity of the logic required to complete the proof. It is important for students to have a chance to consider the advantages offered by formal verification over exhaustive unit testing to try to identify defects after the fact.

29.4  Cleanroom Testing

This section provides and overview of statistical use testing and increment certification. It is important for students to understand that some type of empirical data needs to be collected to determine the probability distribution for the software usage pattern. The set of test cases created should reflect this probability distribution and then random samples of these test cases may be used as part of the testing process. Some additional review of probability and sampling may be required. Students would benefit from seeing the process of developing usage test cases for a real software product. Developing usage test cases for their own projects will be difficult, unless they have some means of acquiring projected usage pattern data. Certification is an important concept. Students should understand the differences among the certification models presented in this section as well.