Software engineering encompasses the tools and methods for defining requirements for, designing, programming, testing, and managing software. It consists of monitoring and controlling both the software processes and the software products to ensure reliability. Software engineering was developed primarily from within the computer science community, and its use is essential for large software development projects and for high-assurance software systems such as those for aircraft control systems, nuclear power plants, and medical devices (e.g., pacemakers).

The reader may wonder at this point why a book on verification and validation in scientific computing includes a chapter on software engineering. The reason is that software engineering is critical for the efficient and reliable development of scientific computing software. Failure to perform good software engineering throughout the life cycle of a scientific computing code can result in much more additional code verification testing and debugging. Furthermore, it is extremely difficult to estimate the effect of unknown software defects on a scientific computing prediction (e.g., see Knupp et al., 2007). Since this effect is so difficult to quantify, it is prudent to minimize the introduction of software defects through good software engineering practices.

Abstract

This chapter reviews the application of Description Logics to software engineering, following a steady evolution of DL-based systems used to support the program understanding process for programmers involved in software maintenance.

Introduction

One of the first large applications of Description Logics was in the area of software engineering. In software, programmers and maintainers of large systems are plagued with information overload. These systems are typically over a million lines of code, some approach fifty million. The size of the workforce dedicated to maintaining these enormous systems is often over a thousand. In addition, turnover is quite high, as is the training investment required to make someone a productive member of the team. This seems, on the surface, to be a problem crying out for a knowledge-based solution, but understanding precisely how Description Logics can play a role requires understanding the basic problems of software engineering “in the large”.

Background

The three principal software maintenance tasks are pro-active (testing), reactive (debugging), and enhancement. Central to effective performance of these tasks is understanding the software. In the 1980s, cognitive studies of programmers involved in program understanding [Soloway et al., 1987] revealed two things:

1. Programmers typically solve problems by realizing “plans” in their programs. This seems to tie the notion of program understanding to plan recognition [Soloway et al., 1986].

2. Delocalized plans (plans which are not implemented in localized regions of code) are a serious impediment to plan recognition, for both humans and automated methods [Soloway and Letovsky, 1986].

In high school I took the only introductory computer courses that were offered, because my older brother had taken them years earlier. He would bring home pictures that he had generated with the computer and allowed me to color them. So I decided that when I got to high school, I would take computer courses so I could create pictures on the computer, too. Although I wasn't very interested in coloring pictures by the time I got to high school, I did take computer courses, and discovered that my brain seemed to work well in the logical world required by computers.

In college, I made computer science my major, and received a BS/CS from SUNY/Buffalo in 1986, and a MS/CS from SUNY/Buffalo in 1987. But at first, I discovered that I didn't know the first thing about computer science, and there were so many subfields that I didn't know what I wanted to do. After taking courses in graphics, compilers, vision, operating systems, and artificial intelligence, I found two areas interesting. The first was artificial intelligence, a hot field at that time. It seemed really futuristic to program computers that could mimic humans, and I did my master's work in that area.

At the same time, I discovered the world of operating systems, and UNIX in particular. I had to use a new UNIX machine for some of my coursework, and I quickly discovered the wonderful social aspects of the system, particularly the “talk” and “write” programs.

This chapter provides some basic background on selected topics in software engineering. This should be useful for those readers whose background is primarily in basic science and engineering, who may have not been previously exposed to this type of material. This chapter is meant to complement the introduction to mathematical topics presented in Chapter 8.

In the preceding chapters we have concentrated on the details of the Spark language. In this chapter, we look at a broader picture of how Spark might be used in the context of a software engineering process. The Spark 2014 Toolset User's Guide (Spark Team, 2014b) lists three common usage scenarios:

1. Conversion of existing software developed in Spark 2005 to Spark 2014

2. Analysis and/or conversion of legacy Ada software

3. Development of new Spark 2014 code from scratch

We start by examining each of these scenarios in more detail, discussing the interplay between proof and testing, and then presenting a case study to illustrate some issues arising when developing new Spark 2014 code from scratch.

Conversion of Spark 2005

Converting a working Spark 2005 program to Spark 2014 makes sense when that program is still undergoing active maintenance for enhanced functionality. The larger language and the enhanced set of analysis tools provided by Spark 2014 offer a potential savings in development time when adding functionality to an existing Spark 2005 program.

As Spark 2014 is a superset of Spark 2005, the conversion is straight forward. Section 7.2 of the Spark 2014 Toolset User's Guide (Spark Team, 2014b) provides a short introduction to this conversion. Appendix A of the Spark 2014 Reference Manual (Spark Team, 2014a) has information and a wealth of examples for converting Spark 2005 constructs to Spark 2014. Explanations and examples are provided for converting subprograms, type (ADT) packages, variable (ASM) packages, external subsystems, proofs, and more. Should you need to constrain your code to the Spark 2005 constructs but wish to use the cleaner syntax of Spark 2014, you may use pragma Restrictions (Spark 05) to have the analysis tools flag Spark 2014 constructs that are not available in Spark 2005.

Dross et al. (2014) discuss their experiences with converting Spark 2005 to Spark 2014 in three different domains. AdaCore has a Spark 2005 to Spark 2014 translator to assist with the translation process. At the time of this writing, this tool is available only to those using the pro versions of their GNAT and Spark products.

We illustrate a simple example of converting a Spark 2005 package to Spark 2014. The package encapsulates a circular buffer holding temperature data, for example, from an analog to digital converter.

The software crisis

The term software engineering originated in the early 1960s, and the North Atlantic Treaty Organization sponsored the first conference on the “software crisis” in 1968 in Garmisch-Partenkirchen, West Germany. It was at this conference that the term software engineering first appeared. The conference reflected on the sad fact that many large software projects ran over budget or came in late, if at all. Tony Hoare, a recipient of the Turing Award for his contributions to computing, ruefully remembers his experience of a failed software project:

In his classic book The Mythical Man-Month, Fred Brooks (B.4.1) of IBM draws on his experience developing the operating system for IBM’s massive System/360 project. Brooks makes some sobering reflections on software engineering, saying, “It is a very humbling experience to make a multimillion-dollar mistake, but it is also very memorable.”

I grew up in a very traditional, military family. Girls became young ladies, married at an early age (before they were 20 years old), and had children. They did not learn mathematics or science, and certainly didn't go to college. Every time we got into a discussion about college, my parents would ask, “Why waste four years in college, and all that money, if you're just going to get married and have children?”

When I was about seven years old, these restrictions made me decide that being a girl was basically a bad thing but that fortunately, I was really a boy. So I dressed like a boy, played “army” and “fort” with boys, and did well in school—especially in science and math. To this day, I'm not sure how I managed to act like a boy for so long without my parents putting a stop to it. But they didn't. I finally relinquished my boyhood a few years later, but by then I was headstrong and adamant that I could do things girls weren't supposed to do.

All through high school I continued to earn straight A's, and participated in a number of sports. A teacher dropped a couple of hints that completely formed my choice of college and major. Once he said, “I think you'd be good at computer science.” Weeks later he commented, “Cal Poly at San Luis Obispo has a good computer science program.”