Abstract

The Royal Military College of Canada (RMC) has offered a real-time software design course for 4 years as part of its software engineering option in Computer Engineering. The course is intended to make the students appreciate why the techniques taught are important, and to understand the importance and difficulty of seamlessness, from requirements to target. For the last 3 years, the course has been based on the Real-Time Object-Oriented Methodology (ROOM) [1] and the ObjecTime toolset that is based on ROOM [2]. Reasons for that choice are given in [3]. This year, variations have been introduced in about one-third of the course. This paper examines the variations and discusses the reasons for them. It also illustrates the problems of deciding what to teach in a course on real-time software design, as the authors of the present paper work closely together, but nonetheless teach variations of the course, although all support the main concepts underlying the course.

1. Introduction

The variations that are possible in a course on real-time software design are enormous. In this paper, we discuss the variations we have introduced within the past year in the undergraduate real-time systems design course at RMC. Our objective in the course is to give the students an understanding of how to approach real-time software design by giving them an opportunity to do some design in the course, using techniques that are taught in the course. The course is 14 weeks long, with 3 hours of lecture and 2 hours of lab time per week, and is given in both English and French. It is also taken by graduate students as partial fulfilment for a graduate course in software design. There is clearly a need for a greater consensus as to what the most important aspects are for a single course in this area, but that consensus has not yet been reached. Our contribution is toward a better understanding of the issues involved in reaching this consensus. One point that is clear to all of us is the importance of picking a coherent approach to design and using it as the basis for the course. Our choice of ROOM [1], as described in [3], can be justified quite strongly, but it is not the only possible choice. There are advantages to the students in being exposed to a variety of design notations and implementation environments. Our decision has been to focus on a single approach, to give the students a solid point of reference for other approaches they may see after graduation, and also because there is not time to consider alternatives in depth. The choice of ROOM has been complemented with the use of the ObjecTime toolset [2], which implements the ROOM notation and design philosophy. This paper presents a discussion of the variations that we have introduced in the two parallel versions of this undergraduate course, in English and French respectively. It also identifies the rational for such variations and outlines the benefits of each approach.

By way of background, we outline the preparation the students have prior to taking this course, and the knowledge that faculty members teaching the course must possess. The software option in the RMC computer engineering curriculum is described in [4]. It includes about 8 courses that prepare the students to do software development. The course described in this paper is in the final term of the fourth and last year of the program. By the time the students take it, they know how to program in several languages (currently including Ada and C++), they have an understanding of how operating systems work internally, and they have been exposed to object-oriented analysis and design, and to a set of work products as part of a software engineering process. Anyone teaching this course must have at least this background, and also must be familiar with different approaches to real-time software design, including the one taught in the course.

2. 1995/96 version of the course

The starting point for the variations was the 1995/96 version of the course:

i. Introduction to real-time systems, review of operating systems concepts, and overview of x86 architecture in order to conduct the context switching lab (2 weeks);

ii. Real-Time Structured Analysis and Design (RTSAD) ([5],[6]) (2 weeks);

iii. ROOM methodology and ObjecTime toolset (5 weeks);

iv. Software Cost Reduction (SCR) notation developed at the Naval Research Laboratory for precise, reviewable specification of software requirements [7], and an alarm clock example [8] (3 weeks); and

v. Schedulability issues, and Rate Monotonic Analysis in particular (2 weeks) . This section is important, not least because ObjecTime provides essentially no support for timing and schedulability analysis, although there is some recent research that may eventually lead to such support.

3. Student concerns

Issues raised by some students who took this version of the course included:

i. The use of the tutorial developed for a four day short course on ROOM and ObjecTime [9], was not the ideal approach for a semester based course. It offers a step by step sequence of activities, with little room for application of the ideas. In a short course, this is appropriate, since students in such a course bring their applications with them, and take away their new knowledge to apply in their regular jobs.

ii. Following the tutorial, the students immediately began work on a relatively big problem. They would have preferred a set of smaller and more manageable problems to start. The alarm clock problem [8], although an interesting exercise in creating a design from a specification, did not capture the imagination of some students. They tended to want to ignore the details of the specification, and assume that they could do a design that suited their concept of how an alarm clock should work. They also wanted to work on the design of a more realistic real-time system, rather than such a self-contained and apparently simple device.

iii. Some students failed to see the benefit of using ObjecTime/ROOM to develop real-time systems, or any system. A significant issue raised was that no implementation was completed all the way to a target. Students were unable to make the mental link to their earlier experience with implementation by writing the code themselves, and so were frustrated that they could not develop actual working systems.

iv. For some students, the two weeks spent learning x86 assembler and architecture was too short and distracted from context switching issues.

4. Variations in 1996/97

The two main variations were between the course as taught in English, and the course as taught in French. We will refer to them as versions 1 and 2, respectively. The main differences in approach for 1996/97 were:

The major choice was between emphasizing high level design issues versus a deeper understanding of the complexity inherent in how real-time software interacts with its environment. In version 1 of the course, the emphasis was put on the transition from requirements to design, while in version 2, it was on the transition from design to implementation.

In version 1 of the course, this meant spending more time on RTSAD, and presenting the SCR methodology. In version 2 of the course, more time was spent on the concepts related to completing the implementation of real-time systems designs, and discussing issues related to real-time kernels, memory management, communication, and synchronization.

In the laboratory (which consisted of 16 Sun Sparcstations 4 and 5 with the minimum 32 MB RAM needed to run ObjecTime) , the main differences are as follows:

In version 1 of the course, a number of adjustments were made to respond to the issues raised by the students, but the basic content was relatively unchanged. The alarm clock example was used, as it has been for the past 3 years. It requires the students to read and understand a formal specification for the behaviour of an alarm clock [8], written using the SCR notation [7]. They then provide a high level design using the ObjecTime tool, derived from the requirements specification.

In version 2 of the course, the changes were more extensive. The students had two projects. For each project, a high level design, a low level design, and an implementation on the target environment using the ObjecTime toolset were generated. In the first project, the students used a specification developed using the Booch methodology [10]. In the second project, they had to develop the specification as they developed their designs. The latter approach more closely resembles current industrial practice, although it is supported in the course by a more coherent methodology and toolset than is often the case in industry.

More detailed descriptions of the changes in the 1996/97 versions of the course follow.

4.1. Version 1 of the Course

First, more emphasis was placed on system design decisions and the unique properties and requirements of embedded systems. Only one week of class time (instead of two weeks) was spent on RTSAD, to review Data Flow Diagrams (DFDs), and to add the concept of Control Flow Diagrams (CFDs) [5][6]. This provided the students with a context in which to learn and evaluate the ROOM methodology. The two week laboratory which covered the use of DFDs and CFDs was replaced by an introductory tutorial in ObjecTime using a simple example. At the same time, material covered in class showed how to expand upon these simple concepts and apply them to the more realistic design example used throughout the course text [1] and in the next six weeks in the lab. Class time was also used to discuss and justify the design decisions and approach used in the textbook design example.

The presentation of the material in the tutorial [9] was modified to emphasize the design approach and the reasons behind the design decisions that are made in the tutorial.

In addition to presenting the SCR methodology as before, the alarm clock example was modified by including a discussion on some of the system design decisions that had to be made and how the partitioning of the system into hardware and software drives the system and software design. As well, there was discussion of the extent to which an SCR style specification is or is not really independent of design, and by extension, of whether any requirements specification can really completely avoid imposing some design decisions.

4.2. Version 2 of the Course

In version 2 of the course for 1996/97, the changes were more extensive. The Motorola 68000 and its assembler were used for the context switching lab. The students are already familiar with 68000 assembler. Less than one hour was spent on RTSAD. The students are already familiar with DFDs and state transition diagrams, so only CFDs [5][6] needed to be discussed in detail.

ROOM was introduced much earlier in the term. In addition, the concepts and the tools (ObjecTime implementation mechanisms) required to implement real-time systems from a design onto a target were presented. In particular, this decision prompted the need to discuss the issue of the RPL to C++ transition that is normally part of all actual implementations on a target with ObjecTime. RPL (Rapid Prototyping Language) is a Smalltalk like language that is used at early stages of the design process in ObjecTime because less effort is needed to code in RPL than in C++. The students are tempted to want to code in C++ directly from the beginning, so it is important to make them understand that this is not good practice in a large project, primarily because a lot of early code tends to be thrown away, so the less effort put into it, the better. On the other hand, there is a trade-off, because the cost of conversion from RPL to C++ can be significant.

New material was added to extend what the students had learned from an operating system course taken earlier. The new material dealt primarily with real-time operating systems concepts, but it included other issues of implementation on a target platform. Topics covered included real-time kernels, real-time memory management, real-time process communication and synchronisation, and real-time programming languages.

To address the new direction taken by the course, a major re-writing of the labs was required as follows:

Lab 1: Context switching lab on the 68000. Students had to build a mini real-time kernel in its entirety.

Lab 2: Introduction to ObjecTime - RPL. In this lab the students completed the OT RPL tutorial which is excellent for covering some of the basics. It was complemented by the design of control software in RPL for a production line.

Lab 3: Introduction to ObjecTime - C++. In this lab, the students completed an implementation on a target platform using the control software generated as part of Lab 2 in C++. This lab presented the principles and philosophy related to implementing a C++ model from a RPL model;

Lab 4: Advanced concepts in C++ with ObjecTime. This lab introduced the students to the concepts of threads in C++ and also required the use of ObjecTime timing services and the mechanisms involved in sending and retrieving C++ data objects from ObjecTime messages.

Lab 5: This lab demonstrated the benefits of using ObjecTime. The students were required to design and implement a stopwatch using an analysis conducted in a previous course using the Booch methodology. In the previous course, creation of an executive object was needed to create the illusion of concurrency. In the ObjecTime version, the need for the executive object was replaced by the Micro Run Time System (RTS) and real concurrency was established by the use of threads supported by the Micro RTS.

Lab 6: In this lab, the students were required to design and implement on a target platform a miniature version of a complete real time avionics system: a Ground Collision Avoidance System (GCAS). The system requires the use of threads and timing services. The use of timing services is extremely important in this lab as data from the various avionics sensors needs to be retrieved at specific and varying time intervals.

5. Discussion

As stated above, the major difference between the two versions of the course comes from the choice of putting the emphasis on the transition from requirements to design or from design to implementation. The choice of approach results in several differences which are discussed in the following.

5.1. Context Switching Lab

In its original version, the context switching lab required that the students become familiar with basic x86 architecture and assembly language and modify a pre-existing assembly code for a mini kernel. The 68000 version of the lab required that the students build a real-time mini kernel from scratch and allowed the students to better concentrate on the issues of context switching. Because the students did not have to learn a new assembler and architecture, they could spend more time concentrating on context switching issues. However, this approach did not give them the opportunity to learn the x86 architecture and assembler nor could they experiment with a more powerful debugger (CodeView) as it applies to debugging real-time systems.

5.2. The Short Course Tutorial

When supplemented by additional discussion on the design decisions that are reflected in the tutorial [9], it is a good introduction to the issues of going from requirements to design. However, it is not a good starting point for building the knowledge needed to complete an implementation on a target platform and was therefore not used in the French version of the course.

5.3. Introducing ROOM Earlier

In version 2 of the course, it was necessary to introduce ROOM as early as possible to have time to deal with implementation issues. This decision took advantage of the fact that the students knew C++, state transition diagrams, and the OO concept. Even though the ObjecTime toolset is powerful and complex, it was felt that the students did not need to be sheltered from it. To get the full benefit of working with ObjecTime, they should be exposed to its full functionality.

Teaching ObjecTime early in the semester, and giving students small problems is a good way to deal with the complexities of the design of real-time systems and of ObjecTime as students get more and more involved with their lab assignments.

In version 1 of the course, ROOM was introduced one week earlier as a result of reducing the time spent on RTSAD.

5.4. Implementation on a Target

Both versions of the course are based on the study of five characteristics that are common to real-time systems: timeliness, reactivity, distribution, concurrency and dynamic internal structure [1]. ObjecTime is used to gain insight into these characteristics. While it is desirable to learn as much as possible about such a powerful tool as ObjecTime, care must be taken to maintain the focus on these five characteristics. One major decision is how long to stay with RPL, and if and when to move to C++. Conversion to C++ is required if a target implementation is to be realized.

In version 1 of the course, the use of C++ as part of ObjecTime was not covered. This allowed more time for detailed discussion of the transition from requirements to design, and of system design issues as they affect the cost and efficiency of the final design. The students were still able to execute a model in the ObjecTime simulation environment, using RPL, and therefore were exposed to some of the advantages of the ROOM methodology and of using the ObjecTime tool.

In version 2 of the course the emphasis was put on how the five characteristics impact design decisions and what are the resulting effects on the implementation and execution environment. By taking the design to an implementation, the students were able to get experience with threads and concurrency issues, and with the difficulty of designing to meet timing constraints. With this approach the students also had the satisfaction of implementing complete real-time systems.

5.5. Choice of Final Project

As mentioned before, to support the approach taken by version 1, the final project consisted of an analysis of the SCR requirements for an alarm clock [8] and the modelling in ObjecTime of a design to meet such requirements. The alarm clock example was shown to require several major design decisions which had to be made very early. Use of the ObjecTime tool greatly enhances the student's ability to model, understand, and test these early design decisions in an effective manner. Use of the alarm clock example also has the added benefit of exposing the students to the SCR requirements specification methodology, and to the potential limitations of that technique. These limitations could be reduced by using the SCRtool produced by NRL [11], but the problem of finding time for the students to learn how to use the SCRtool will be hard to solve. In the current version of the course, a careful analysis by hand of the requirements as given in [8] shows that they are incomplete, so some properties of the alarm clock's final operation become dependent on design decisions. Use of the alarm clock example also makes the students realize that what, on the surface, appears to be a self-contained and simple device is anything but when it comes to actually designing and implementing the control software. Emphasis is also put on the issues of minimizing overall system cost. In particular, [8] makes no mention of the hardware that will be used to support the software being designed, so the students are exposed to the effects that hardware design decisions have on the software process. Issues such as whether buttons should cause interrupts or should be polled, and how the hardware should supply the timing signal needed to make the alarm clock work, and the effect such issues have on cost, are discussed in version 1 of the course.

From the perspective of version 2 of the course, the alarm clock did not constitute a problem that would properly bring out many of the issues related to concurrency and timeliness. As a result, a new project was needed to better address these issues. To fulfill this requirement, a project was developed which involved the design and implementation of a miniature version of an aircraft Ground Collision Avoidance System (GCAS) avionics system. The GCAS is a hard real-time system which requires concurrency and prioritization in order to meet its deadlines. The GCAS lab provided insight into designing a system that performs specific tasks at given time intervals, and that also must respond to asynchronous events. It also demonstrated the difficulty of modelling components that are external to the design. There are a number of other avionics systems that GCAS has to interact with. In the real GCAS, the data produced by these systems is tightly coupled, in the sense that aircraft attitude, altitude, speed, heading, acceleration and so on are all interdependent, even though the data representing them may come from different systems. It was necessary to implement a simple simulated flight profile to allow the students to run their designs.

6. Conclusion

In our view, the changes made for 96/97 have resulted in two improved versions of the course. There is obviously debate amongst us as to which of the two versions of the course is most appropriate. We do not have a way of settling the debate, other than to wait to see what the future brings. In both courses, the students acquired a deeper understanding of issues related to the design of real-time systems, as well as a greater understanding of the ObjecTime environment. We have taken care to steer the students around the complexities of ObjecTime, and to focus on the important issues.

It is difficult to make an assessment of the effect of the two versions of the course on the two groups of students, each taking one of the versions. Both groups seem satisfied with the version they took, but that is to be expected, since none of the students have other points of reference from which to judge whether something is missing, or to judge what is most important. If the professors are having difficulty with such judgements, the students should be having even more difficulty!

There can be a tendency on the part of the students to believe that there is one correct approach to a design. In both version of the course, the students were required to give a brief presentation of their project designs. This exercise exposed the students to various solutions and made them realize that there is more than one sound design that solves a given problem. It also allowed us to critique their different designs.

A significant issue is whether the students gain a sufficient appreciation of the limitations of older approaches to real-time software design, and specifically of the issue of "phase discontinuity" as emphasized in the course text [1]. There is some doubt that they do, both in version 2 of the course, and to a lesser extent in version 1 (where more time is spent on RTSAD). We all agree that RTSAD will eventually be entirely removed from the course.

In version 2 of the course, it was advantageous to build directly on a previous course in object-oriented techniques, taught by the same instructor to the same students, which used the Booch approach to analysis and design, and C++ for implementation. The instructor for version 1 of the course did not teach the corresponding previous course to the students taking version 1, and the material covered was different enough to mean that direct use of it was not feasible. For instance, in version 2, virtually no time was spent on state transition diagrams or C++, as they had been thoroughly covered in the earlier course. This was not so clearly true for the students in version 1. Also, drawing directly on some of the lab work done in the previous course allowed the students in version 2 to tackle more ambitious lab projects, and allowed them to see more clearly the benefits of ObjecTime.

For the labs that were given, a good understanding of C was all that was required. C++ is not essential unless the students have to modify the code generated by ObjecTime. On the other hand, modifying the generated code is part of the reality of real-time system construction, even with ObjecTime. Ideally, the students would modify one of their designs, and then be able to do design recovery from modified code. This may be difficult, depending on the nature of the modifications, and the extent to which they are expressible in ObjecTime. On the other hand, it is an objective worth attaining, since it is important for the students to understand the importance of the integrity of a design, and to learn approaches to maintaining integrity.

This course is part of a six course set of courses in the third and fourth years of a four year program in computer engineering at RMC, taken by the students who follow the software option. Three of the courses are taken by all computer engineering students; this course is one of the remaining three courses that constitute the software option. The program in its entirety is a good candidate, with a bit more software content, to be accredited as a software engineering undergraduate program. The present course makes an important contribution to this possibility.

Changing views of what is important in the software world, combined with our experiences with this course, and with other courses in the set, plus the possibility of adding a seventh course, will undoubtedly result in further changes to the whole program. We would ideally like to have objective evaluations of the different approaches to this course, and to the whole program, preferably via statistically valid studies, but RMC is too small to permit this, even if all our students actually had the opportunity to do real-time software design immediately after graduation. Many of them eventually do related things, but later in their careers.

7. References

[1] Bran Selic, Garth Gullekson and Paul Ward, Real-Time Object-Oriented Modelling, J. Wiley, 1994

[2] ObjecTime and MicroRTS manuals, ObjecTime, Kanata, Ontario, 1997

[3] Terry Shepard, Colin Wortley, and Bran Selic, "Using ObjecTime to Teach Real-Time Software in the Undergraduate Curriculum", Real-Time Systems Education, Ed. J. Zalewski, IEEE Computer Society Press, 1996, pp. 26-35

[4] Terry Shepard, "Software Engineering in an Undergraduate Computer Engineering Program", Proceedings of the 7th SEI Conference on Software Engineering Education, San Antonio, TX, 5-7 January 1994, pp. 23-34

[5] Derek J. Hatley, and Pirbhai, I.A., Strategies for Real-Time System Specification, Dorset House, 1987

[6] Paul T. Ward, and Mellor, S.J., Structured Development for Real-Time Systems, Volumes 1, 2 & 3, Yourdon Press, 1985

[7] Katherine L. Heninger, "Specifying Software Requirements for Complex Systems: New Techniques and Their Application", IEEE Transactions on Software Engineering, v. 6, n. 1, Jan 1980, pp. 2-13

[8] Peter Matelski and James McKim, "Alarm Clock Requirements", January 11 1988, Queen's University internal teaching note.

[9] Paul T. Ward, "ObjecTime Curriculum: New User Workshop: Basic Modelling", Paul Ward Associates, New York City, NY, 1995

[10] Grady Booch Object-Oriented Analysis and Design with Applications, 2nd Edition, Benjamin/Cummings, 1994

[11] SCRtool, Naval Research Laboratories, Washington, DC, USA (contact: Connie Heitmeyer, heitmeye@itd.nrl.navy.mil)