Software Development with C++

Maximizing Reuse with Object Technology

Kjell Nielsen

• Publisher: Academic Press
• Year: 2014
• ISBN:
  9781483265698
• Topic: Computer Science
• Subtopic: Programming in Java
• Index: Computer Science

Software Development with C++: Maximizing Reuse with Object Technology is about software development and object-oriented technology (OT), with applications implemented in C++. The basis for any software development project of complex systems is the process, rather than an individual method, which simply supports the overall process. This book is not intended as a general, all-encompassing treatise on OT. The intent is to provide practical information that is directly applicable to a development project. Explicit guidelines are offered for the infusion of OT into the various development phases. The book is divided into five major parts. Part I describes why we need a development process, the phases and steps of the software process, and how we use individual methods to support this process. Part II lays the foundation for the concepts included in OT. Part III describes how OT is used in the various phases of the software development process, including the domain analysis, system requirements analysis, system design, software requirements analysis, software design, and implementation. Part IV deals exclusively with design issues for an anticipated C++ implementation. Part V is devoted to object-oriented programming with C++. This book is intended for practicing software developers, software managers, and computer science and software engineering students. Sufficient guidelines are included to aid project leaders in establishing an overall development process for small, medium, and large system applications.

PART I

The Software Development Process

Outline

Introduction to The Software Development Process

Chapter 1: Introduction

Chapter 2: Steps in the Development Process

Chapter 3: Development Process versus Methods

Introduction to The Software Development Process

In Part I, we first present a rationale for why we need a development process for producing high quality software products. The term “object-oriented” is used today almost as a synonym for “good” software development. The ramifications of switching from traditional structured methods to object-oriented techniques are discussed in terms of the benefits and risks associated with using the new techniques.

An overview of the individual steps of the development process is provided. The initial step in the system development process is usually the system requirements analysis. We have added another step to the process: domain analysis. The primary purpose of domain analysis is to assess the potential for substantial reuse for the development of large systems, and this analysis should be performed very early in the project life cycle, even during proposal time. The focus of this effort is to determine reusable hardware and software components as well as the potential for reusing entire subsystems.

An unfortunate trend in the use of methods to support a software development process is that the method itself may get such a prominent emphasis that it becomes the process. This is a case of the tail wagging the dog and may prevent an orderly progression of the phases that are required for the creation of high quality software products. The relation between methods and the development process is described. The emphasis is on how the various methods can support the overall process.

The development approach described here is a generalized process that applies to system development, including the allocation of system requirements to hardware and software. We only provide guidelines for software development, however, guidelines for hardware design are not included in this book.

The approach presented applies to the development of small, medium, and large systems. The suggested process is not intended as a “cookbook“ approach. The development process should be tailored to fit an individual project, and some of the steps in the process can be omitted for small and medium systems. Specific recommendations for tailoring will be included later in Chapter 8.

1

Introduction

Publisher Summary

This chapter discusses the need of a development process based on the inherent complexity of even small software products. The development of software products is an inherently complex task. The complexity manifests itself in the understanding of detailed customer requirements, and specific analysis, design, and programming techniques that are necessary to produce a high quality software product. A software product is approached with completely different viewpoints by its ultimate users and the software developers. The developers look at a software product regarding design and programming techniques, and how efficient the product can be in terms of execution time and the amount of storage required. Software products can be created by programming directly from loosely formulated requirements specifications. This is referred to as hacking and rarely results in high quality software that can form the basis for a product line with reusable components. Each phase of the development process of producing software includes a number of intermediate analysis and design products that ease the communication barrier between users and developers, and among various development teams working on different portions of a large system. The intermediate products include important analysis and design documentation that is used in design reviews.

This chapter includes the rationale for why we need a development process, based on the inherent complexity of even small software products. The emphasis throughout this discussion is on the creation of high quality software, and on teams of developers working on separate phases of the development process.

The differences between structured and object-oriented approaches are described, with an emphasis on the advantages of an object-orientation. Current development practices are described with an eye toward organizations that are on the verge of, or are agonizing over whether they should be switching to object-oriented approaches.

1.1 WHY DO WE NEED A DEVELOPMENT PROCESS?

The code segment shown in Figure 1-1 is a portion of a final software product. But what does it represent, and where did it come from? The code segment is a C++ implementation of an abstraction of a “window” entity [DIL92], and can be used in various Microsoft Windows applications. It is highly unlikely that even the brightest programmer could create this code segment in isolation without the benefit of prior analysis and design. A sequence of development steps necessarily preceded the programming task for this code segment. This sequence represents a development process.

Figure 1-1 Windows abstraction

The development of software products is an inherently complex task. The complexity manifests itself in the understanding of detailed customer requirements, as well as specific analysis, design, and programming techniques that are necessary to produce a high quality software product.

A software product is approached with completely different viewpoints by its ultimate users and the software developers. The users are interested in desired features and how easy the product will be to use. The developers look at a software product with regard to design and programming techniques, and how efficient the product will be in terms of execution time and the amount of storage required.

Because of the limited capabilities of humans (even the most gifted!) to comprehend a large number of new and complex concepts, an immediate problem arises at the communication level between users and developers. Neither of these two groups fully understands the domain of the other, and some means of communication has to be created to bridge the gap of understanding.

Every software product is created to satisfy the needs of actual or perceived customers. These needs are specified in a system requirements document if a real customer is contracting to have the work done. This document represents the requirements for the new product. If a new software product line is being planned, there are a number of perceived customers who are the potential buyers of the product. In this case, the requirements may be less formally stated, but they exist nevertheless, and should be documented in a system requirements specification just as for a real customer.

Software products can be created by programming directly from loosely formulated requirements specifications. This is referred to as “hacking,” and rarely results in high quality software that can form the basis for a product line with reusable components. An extensive analysis of the system requirements and a subsequent design effort should be performed prior to the start of the actual programming effort. The analysis effort will ensure that the product we are about to create will satisfy our customers’ needs. The design effort will help in the construction of reusable software entities.

The discussion above implies that any software development effort should consist of at least three steps: analysis, design, and implementation. These three steps represent a development process. This does not imply that the steps are necessarily performed in a strict sequential order. For a large system, there are usually parallel activities happening simultaneously for several smaller portions of the system. The different development teams are dependent on the work produced by the other teams from other phases of the development.

We will note in later chapters that the three suggested steps of analysis, design, and implementation are not sufficient, and other steps that can improve the process will be added, in particular, a domain analysis step (see Chapter 2).

To summarize the discussion above, we need a development process to manage the inherent complexity of producing software. This process...