Intellectual Output 2: Procedural guidance

Developing and testing software is a complex activity. A procedure has been developed to design and specify object-oriented (OO) software step by step. A distinction is made between three different parts, namely an External View (also known as API), an Internal View (concerning attributes and private methods), and an Annotated Code View (the working code). Each of these parts are made up of three steps, namely Analysis (collecting all the information needed to produce the design and specification), Design (in which the structure is determined), and Specification (in which the behaviour is described). The External View, the Internal View and the Annotated Code View are then translated step-by-step into the necessary tests. Explicit guidance for each step is provided.

The procedure not only supports the development of the core functionality, but also caters for robustness. The procedure allows for an iterative and incremental development of software where it is easy to go back to an earlier step, but it is also possible to choose one's own order of execution of the different steps. The procedure does require that eventually all views are checked for consistency: in the end it is the implementation that must fulfil what is promised by the API!

The procedure has been evaluated on two groups of students. It became clear that the first group could not be motivated to produce specifications before coding. Developing software through trial and error was preferred. In a second study, we gave the students the full External View of each class. Students now appreciated the specifications, which was reflected in the quality of the software: fewer errors in the code and tests that found more errors. The evaluation provided us with two important insights. First, giving specifications is an important starting point. Students learn to appreciate the specifications and will probably draft them themselves for more complex issues. The procedure helps them with that.

Secondly, we have to conclude that many requirements are not clear at all without precise specification. Students give their own interpretation to this, which stimulates trial-and-error behaviour. We are conducting follow-up research on both aspects.

How to apply in your education

The procedure can be taught in the following ways:

  • The procedure can be taught as a whole as part of a Software Engineering course. Such a course is typically placed in a second or third study year and requires prior knowledge and experience with programming and testing.
  • Parts of the procedure can be distributed over several courses. Examples are:
    • Functions are discussed in an introductory programming course. In addition to teaching the syntax and the use of functions, the first column (External View) and the third column (Code View) can be applied from the procedure. These views indicate which aspects of a function can be distinguished, in which order they can be developed, how this leads to a design, specifications, implementation and associated tests, and documentation.
    • In a first year OO programming course, classes and methods are introduced. Here the approach may be limited to developing an External View and Code View with associated tests. Attributes are added to classes, but describing them precisely in the form of an Internal View is postponed until a follow-up course (see the next bullet).
    • In a course about data structures and algorithms, the Internal View is of special interest besides the External View and Code View. Here, the translation from domain variables to attributes and corresponding specifications is a critical activity.

The procedure itself is a complex thing for beginning students. Learning the concepts underlying the procedure and how to use the procedure cost time. It is important to introduce the procedure using simple examples, so the student has to deal with one complexity at the time. Once the procedure is understood, it can be used to solve more complex exercises. It is important to understand that the use of the procedure is not a goal in itself; instead, it provides guidance where the complexity is greater.

A good start is to give students the specifications from the beginning, before they have to construct these by themselves. In this approach, students learn to read the specifications and experience the benefits of using them: they have a grip on the implementation of the functionality, can check whether all requirements have been met and can draw up test cases more systematically. In a next step, students learn how to draw up specifications using the procedure. After that, more and more complex situations can be solved. The procedure can be explained through traditional classroom teaching and practiced by homework assignments that students work on alone or in groups. The procedure can also be taught by having the entire class, or groups of students, work together on assignments and frequently, after each procedural step, share their results and discuss them. We think this approach is most effective. Together, many more aspects are found that need to be taken into account in a design and specification. It is precisely this experience that is important! Worked-out solutions for twenty exercises, ranging from simple to more complex ones, have been provided. Several of these solutions are presented in two versions: one where each step is worked out in detail and all considerations are described, and one where only the results of each step are recorded. The exercises and solutions can be used in education.

Available material

Copyright © QPED 2023.