INTRODUCTION

It is essential to develop a model of a system before writing any software that will be used to control the system or to interact with it. Modeling the software is probably the hardest part of software design. Producing good software designs requires a considerable amount of practice, with a great deal of feedback on the quality of the designs with the resulting software products influencing the design of the next software system.

We view software design as an iterative process, with the goal being design improvement at each iteration. The purpose of this chapter is to discuss some basic principles that can guide the software design process. These principles will be illustrated by several examples.

You are undoubtedly aware that a fundamental change is taking place in the software industry. With the advent of cloud computing, software is not as tethered to particular servers as before. The notion of a computer itself is changing, moving from a powerful desktop or laptop that connects to a server as necessary, to much more ubiquitous devices such as smartphones and tablets, with cloud computing often added.

There also is heavy emphasis on object-oriented technology and software reuse. Some aspects of the object-oriented methodology are so different from corresponding issues in the traditional, still-common procedural approach to software design that they should be discussed separately. This is especially true in software design.

However, a considerable amount of current software engineering effort is still far more focused on requirements analysis, design, implementation, testing, and maintenance of programs that have been developed under the more familiar procedural approach rather than object-oriented techniques. Therefore, a software engineer must be familiar with designing both types of software systems. This presents a problem for the writer of a book on software engineering.

Our solution, and the one most appropriate for both the current software engineering world and that in the foreseeable future, is to use a hybrid approach that combines compo- nents that are written in either procedural or object-oriented languages. After all, an exist- ing software module that performs a specific requirement well should not be rejected for potential reuse just because a new application is object oriented. The use of even larger-scale

software components, such as the use of LabView that we discussed in Section 3.15 during our case study of agile processes, is a prime example. If we use such commercial off-the- shelf (COTS) products or any large-scale components as is, the main consideration is their applicability to our particular project. This is, of course, especially important for any agile software development process. Even if the software component is open source, we are still primarily concerned with its functionality and its quality, not whether the internal design of the component is object-oriented.

We note that this hybrid approach is common in the software engineering community and has been formalized by several organizations. Here’s a historical example. Consider the experience of the U.S. Department of Defense, which spends an enormous amount of money on software development and maintenance. A survey in the late 1970s showed that software was being developed or maintained in more than 1600 different computer lan- guages and dialects. This was the impetus for the development of the Ada programming language, which was designed to make use of the lessons learned in many years of software development (Ada, 1983; Ichbiah, 1986). Some of these lessons were information hiding, separate compilation of software interfaces and software internals using package specifi- cations and bodies, support for polymorphism and abstraction through “generics,” and strong typing. Major revisions, including increased object-oriented technology occurred in Ada in 1995, 2005, and 2012.

As this chapter is being written, there is considerable public attention directed toward a technology named “positive train control” that many experts believe might have prevented a recent train derailment when a train exceeded the 50 miles per hour speed limit on a tight curve north of Philadelphia’s 30th Street Station. Measurements suggest that the train was moving at an amazing 106 miles per hour around this curve. Many people not familiar with the technology suggest simply measuring a train’s speed using a GPS and slowing it automatically if it is determined to be too fast. Unfortunately, that approach is simply not up to the complexity of the problem.

Positive train control makes use of the information provided by local tracking devices and uses these to provide a real-time control system with a high degree of fault toler- ance. On a personal note, I had an interesting discussion with a technical manager for the Federal Railway Administration at a time (the early 1990s) when the speed controls and collision prevention software was written in a specialized language known origi- nally as Tandem Application Language, which was later renamed Tandem Transaction Application Language. Even then, a purely object-oriented programming language did not seem adequate for the task. A hybrid approach is being deployed.

While the number of programming languages currently in use is far less than 1600, it is large and expanding, including languages for statistical data analysis, for scripting, for visual programming, for textual analysis, and smartphone applications development. You should expect to learn many languages, software development kits, and development envi- ronments during your career.

The rest of this chapter will be organized as follows: First, we will present some basic, general-purpose design principles. Some of the design principles will be based on the basic technique of software pattern matching. The goal is to reuse software components at as

high a level as possible. This discussion will be followed by some representations that are commonly used for the design of procedurally oriented systems, with examples of each representation. After completing our initial discussion of the design of procedurally ori- ented systems, we will discuss some design representations for them, again with examples. The same steps will be followed for object-oriented software. This will complete our initial discussion of software design techniques. We will also discuss our agile case study.

The last three sections of this chapter will be devoted primarily to the design of the example begun earlier in this book. This example will be discussed in detail. Special emphasis will be placed on those issues that arise because of the necessary combination of both procedurally and object-oriented designs.