CERNOHORSKY, Jindrich 1 & ZALEWSKI, Janusz 2
1
2 Dept. of Electrical & Computer Engineering, University of Central Florida ,Orlando, FL 32816-2450, USA, jza@ece.engr.ucf.edu, http://www-ece.engr.ucf.edu/~jza
Abstract: This paper presents experiences with introducing automatic CASE tools into courses on real-time systems, both in control engineering and in software engineering programs. It outlines motivation for using software engineering tools in a classroom and discusses a specific course on ”Control Systems with Computers II” at VSB Ostrava. Then it overviews the tools used in related class projects at VSB and UCF, as well as gives some details of the projects involved. Finally, a brief discussion of lessons learned is presented.
Keywords: real-time computing, control education, software engineering, CASE tools
Analyzing the results of cooperation with industry on the development of several real-time control systems, we have found out that insufficient attention was paid to the analysis and design of project functions, system’s structure and to other important project properties. This remains true for both academic and industrial partners. The most visible consequence of this fact is the lack of adequate documentation needed for future project maintenance.
Figure 1. Four major aspects of real-time software development.
Many developers confuse the system design with an engineering description of measurement and automatic control subsystems. The latter usually consists mainly of lists of inputs and outputs, a list of controllers and eventually of description of their parameters. In some cases, it is also augmented by some written vague description of goals of the system as well as other facts, loosely related to the system being developed. Very rarely we have encountered a design made according to good software engineering practices. While lower layers of real-time software development are well understood, this is not the case for the specification and design layer (Fig. 1 [7]). In those cases, when we succeeded in elaboration of better and more detailed system design, the implementation of the project was superior to the cases when this was not done.
It is striking that this phenomenon has been observed for a relatively long period of time, spanning for at least one decade, even though the penetration of computers into miscellaneous application fields was overwhelming during this period. With computers being more and more extensively used in safety-critical applications, this situation can no longer be tolerated. One way of improving it is via education, so that "new blood" of properly educated engineers enter a job market. This is one reason why teaching fundamentals of software engineering was placed into measurement and control curriculum in VSB Ostrava. The subject is included in the course ”Control Systems with Computers II”, which is obligatory for all students of the Measurement and Control branch. The second goal of the course is to give students familiarity with additional advanced information technology concepts important, in our opinion, and complementary to the area of measurement and control.
On the other hand, at UCF, students who major in Control Engineering specialization usually take elective courses in Software Engineering. One course, specifically, ”Software Development for Real-Time Engineering Systems”, has been designed to meet the needs of interdisciplinary audiences, such as students of computer, electrical, mechanical, and aerospace engineering, with respect to software engineering principles and practices. Course objective is to provide students with knowledge of and experience in three crucial phases of real-time software development: specification, design, and implementation.
Certainly, it is not anticipated that all students graduating in measurement and control specialization will produce control software in their future job assignments. However, most of them will cooperate with software developers during the requirements analysis and design phases of various real-time systems as analysts or managers, members of development teams either on the customer or the supplier side. The knowledge of basic methods of software engineering in such cases is valuable, important, and necessary to ensure high quality of the final product.
The course on ”Control Systems with Computers II” has been evolving for several years since 1992. During this period a lot has changed in the information technology area and the course contents have been varying accordingly.
The first half of the course deals with general software engineering issues. First of all, the notion of a software life cycle is introduced. Then its individual phases (requirements analysis, system specification, design, implementation, testing, maintenance and documentation) are discussed in general. Some common concepts, used across several systematically organized design methodologies, are presented. These concepts include encapsulation, modularization, classes and objects, processes, concurrent programming, hierarchy and hierarchization, state diagrams, entity relationship diagrams, top down and bottom up approaches, etc.
Then the data flow diagrams (DFD) are presented as a general notation common to most structured approaches. Structured techniques are historically well established and correspond well to the practice of teaching fundamentals of programming and real-time programming in the second and third year of study. So they are suitable as a starting point to the introduction of software engineering principles.
As far as specific software engineering methods for design of real-time systems are concerned, MASCOT [1] and SA/SD (Structured Analysis/Structured Design) [14] are introduced first. Their presentation demonstrates what new notions and concepts should be added to the classical DFDs to make it appropriate for basic real-time design and modeling of situations typical in real-time systems.
Subsequently, a newer method, DARTS [6], is introduced. It is rooted in structured approaches as well, but it introduces high-level abstract notions, such as various modes of communication (loosely coupled, tightly coupled, with reply or without reply), tasks and events. DARTS also introduces structuring of a system into tasks, by an analogy to structuring the system into modules. Since the module and process concepts are known to students from previous courses, the DARTS techniques are quite easily understandable. Students can easily imagine how to realize the system composed of modules and processes or tasks. This is the reason why we use DARTS concepts, although there is no tool support for this method.
Object-oriented (OO) techniques of analysis and design are treated in the second half of the course. These approaches are newer and more up to date. They could be used exclusively for the purpose of analysis, even if not intended for implementation by OO programming. When learning OO approaches, the students know what implementation practice they are directed at, since they have been familiarized with OO programming techniques in the prerequisite for this course [3].
OO analysis applies the bottom up approach, a paradigm opposite to structured development. It aims at finding in a real system appropriate entities that could be modeled as program objects and specifies them as abstract classes. OO programming approach is straighter than structured approach, as illustrated in Fig. 2. Some abstractions could be identified in the process of analysis as units that could be almost directly implemented. The OO design phase is thus focused on issues concerning the communication between objects and on specification of classes in software space (solution space). What is new in this approach and what should be studied carefully is the appropriate use of inheritance and polymorphism. For a beginner, this is quite a difficult task, because correct and convenient use of these features requires a significant experience. So we discuss these questions in a limited way and using very simple and straightforward examples. For students more seriously interested in OO design we recommend individual readings [2,13].
Figure 2. Illustration of a difference between structured and OO approaches.
Recently, a great deal of attention is paid to Universal Modeling Language (UML) technologies that are implemented in products of several software tool vendors. UML finds its use also in the design of real-time embedded systems [5]. Increasing number of references to UML also appear in scientific and technical papers dealing with real-time design, for example [9]. At UCF, fundamentals of UML, with focus on statecharts, are incorporated in the real-time course. Consequently, there is a good reason to contemplate the use of UML in teaching software engineering for students of Measurement and Control branch, at VSB Ostrava.
Developing software for contemporary real-time control applications, such as flight control systems or nuclear reactor control systems, is too complex to be done manually by a single individual. Therefore automatic software tools, known as CASE (Computer Aided Software Engineering), are needed to assist in the development process.
Software tools are an important part of every software development methodology. As a matter of fact, it is a dominating factor of success or failure of any development methodology, because the lack of software tools delays and obstructs the development of applications. In principle, most CASE tools support either structured or OO methodologies or both.
For real-time systems design, it is necessary to support special features by which these systems are characterized, in order to model their properties and design concepts in a best possible way. Usually, this is accomplished by the use of special notation, which allows expressing the timing characteristics of these systems. To be fully useful in software development for real-time systems, however, the automatic tools have to provide support in the following four dimensions (Fig. 3 [16]):
Figure 3. Role of software tools in a development environment.
- support for code generation and prototyping, in particular, for specific programming languages and real-time kernels, and
- support for design verification against the requirements (for example, to assure one-to-one correspondence of design components with the requirements)
The advantage of this view, from the perspective of tool functionality, is that having the tools operational in all four dimensions, one gets the following properties covered for the software design:
Several software tools with this concept in mind operate already in the commercial marketplace.
In the first years of teaching software engineering in Control and Measurement branch at VSB, we have been using very limited demo version of Software Development Workbench (SDW) tool, which has been later abandoned in favor of SELECT OMT and SELECT YOURDON development tools. The latter is also distributed as part of the book [4] for educational purposes. The advantage of SELECT tools lies in a possibility of using both structured and object technologies realized in a unified manner.
At UCF, a more comprehensive use of real-time tools is being pursued. Prompted by the pressure from industry and big research institutions, such as NASA or nuclear research labs, since early nineties we have realized that software tool support is indispensable in teaching the development of large software systems [15]. Students have to be equipped with adequate means for graphical analysis of real-time systems and their design representation. This practical knowledge combined with theory gives them a tremendous advantage on the job market and allows starting serious assignments on day one at the workplace. With this in mind, we specifically searched for software design tools capable not only of producing an internal graphical representation of a real-time system, suitable for subsequent modeling, but also for tools which provide comprehensive capabilities of interaction with other software processes, software components, and development phases.
In terms of Figure 3, we were able to identify and successfully introduce to the classroom environment, the following software development tools suitable to real-time system design:
Our objectives of acquiring these tools were different in each case. In fact, the selection criteria followed those listed above, in association with Fig. 3.
The typical examples of problems solved as class projects at VSB were related to design of embedded control systems for the following applications:
In solving these examples, the students had the opportunity to freely choose between SELECT OMT and SELECT YOURDON (or even use DARTS and produce necessary designs by hand). By solving such practical exercises in class, the students learn how to use CASE tools effectively, what are their advantages, how important it is to organize work systematically, and how can software tools contribute to it. It is also crucial to learn recognize importance and advantages of having appropriate standards for accurate expressing of designs in a semiformal fashion, independent of an implementation environment.
In a course on real-time software development at UCF, the level of complexity of student projects evolved significantly over the years and was determined to a large extent by the availability and power of appropriate CASE tools. Initially, we offered relatively simple projects, with emphasis on manual, paper-and-pencil development, with emphasis on structured methods. Most of these projects are described in [11].
With the proliferation of object-oriented technologies and corresponding automatic support tools, our philosophy changed. Nowadays, even for simple systems we prefer using the UML notation as a vehicle for communication between the developer and the customer. For example, user and device characteristics for a microwave oven controller can be reasonably well expressed in UML using use case diagrams (Fig. 4).
Figure 4. Use case diagram for microwave oven controller.
Of course, real design of a controller does not start until the traditional context diagram is developed and all the requirements for all variables are written (Fig. 5). This is typical for both object-oriented (in particular, UML) and structured development methods [10]. However, before such diagram can be created, most likely multiple discussions between developers and customers are taking place, the results of which need to be expressed in a notation precise enough, but first of all easy to understand and convenient for all participating parties. UML provides these capabilities due to its natural graphical representation of several major concepts in software development.
Figure 5. Context diagram for microwave oven controller.
In further development with UML, one can use any of its multiple diagrams as design vehicles, however, for real-time systems sequence diagrams are particularly suitable, because they allow specifying timing properties (although in a limited fashion). An example of a sequence diagram for a part of a design for microwave oven controller is presented in Fig. 6.
Figure 6. Sample sequence diagram for microwave oven controller.
In the most comprehensive real-time project, which involved the whole class of twenty five students divided into eight teams, software for a sophisticated air-traffic control system was developed. In addition to real-time aspects, this project involved elements of distribution, safety, and reliability. The complete specification document is available from the following web page:http://www-ece.engr.ucf.edu/~jza/classes/6897/projects98/srs3.html
The physical diagram developed from this specification, as well as corresponding context diagram, are presented in Figures 7 and 8, respectively. An interesting observation is that, from the point of view of software developer, what we call an air traffic control system in not a control system at all. It is just a comprehensive data acquisition system, because there is no automatic control loop. All control is done by a human, air traffic controller.
Figure 7. Physical diagram for an air traffic control system.
The use of software development tools for this project was very systematic and involved, at various stages of development, all four tools listed in the previous section:
Figure 8. Context diagram for an air traffic control system.
In addition to projects outlined above, all tools are used each year in multiple individual projects, which range from designing a simple traffic light controller with the help of ObjecTime or Rhapsody, to non-control related projects, such as a computer bus traffic simulator with SES/workbench or a distributed optimization solver using genetic algorithms with G2.
It is our opinion confirmed by observations from the majority of projects that in systems design it is very important for students to have an exact idea of the implementation environment in which the software controller will be operating. This is consistent with the fact that the teaching of software engineering especially succeeds after teaching programming. Although in theory, one could argue that the teaching of software engineering could be done before programming.
We are also convinced, based on students’ response, that structured methodologies constitute an important fact that cannot be fully eliminated from the classroom, in favor of an OO approach. This is because they represent the top-down paradigm and use top-down approach to the analysis and design, which allows to split a system into smaller, better manageable and fully understandable parts. Then in the design stage, the bottom-up approach can be used for construction of higher abstraction entities (procedures, tasks, modules, classes and objects) that better suit respective programming models of control systems for direct implementation.
With the use of OO methods, certain concepts must be carefully explained to students to prevent unnecessary confusion. For example, there is a small problem related to different uses of a notion of an object. In OO programming, an object is a variable of a certain type (instance of a class). In OO analysis, however, an object is sometimes referred to as a member of a common and more general class having more specialized features. In fact, this is an inheritance relation and a notion of an object should denote an instance not a class.
It is important to realize that choosing appropriate software engineering projects is of primary importance. Students especially enjoy developing systems with which they have contact in everyday life, such as automatic teller machine, gas station controller, or most of those referred to in this paper. This gives students and instructors guarantee that the system functions will be understood quickly, which is necessary for doing appropriate analysis and design on schedule.
Another observation is that in an introductory software engineering course, only relatively good students are successful in creating fully functional implementation from their designs. Even if the implementation is successful, it sometimes does not conform exactly to the documentation created in the design phase. This is because the design was incomplete or contained other defects. This is, however, not necessarily a bad thing, because students would learn from their own mistakes and improve future designs on this basis.
Team work on a software project in a classroom is a very interesting learning concept enforced by real-life working environments. However, the practical application of this concept has many disadvantages. Combining partial contributions into an integrated solution causes problems, because students tend to implement their own individual designs. In a group project, the division of work in uneven and most of the work is always done by the best students, while others stay at rest, which causes problems with evaluation and grading. Nevertheless, it is our opinion that team work is an indispensable components of most software development projects, especially from medium to large size.
Finally, our experience with teaching and using CASE tools in laboratory practice is very positive and can be summarized as follows:
[1] BATE G. (Ed.), The Official Handbook of MASCOT. Version 3.1. Malvern, Worcs.: Royal Signal and Radar Establishment, 1987.
[2] BOOCH, G., Object Oriented Analysis and Design. Reading, Mass.: Addison-Wesley, 1994. ISBN 0-8053-5340-2.
[3] CERNOHORSKY J., Fundamentals of Real-Time Computing for Students of Measurement and Control. In Real-Time Systems Education III, Los Alamitos, Calif.: IEEE Computer Society Press, 1999, pp. 130-134. ISBN 0-7695-0134-6.
[4] COOLING, J.E., Real-Time Software Systems: An Introduction to Structured and Object-Oriented Design. London: ITC Press, 1997. ISBN 0-534-95492-8.
[5] DOUGLASS, B.P., Real-Time UML: Developing Efficient Objects for Embedded Systems. Reading, Mass.: Addison-Wesley, 1998. ISBN 0-201-32579-9.
[6] GOMAA, H., Software Design Methods for Concurrent and Real-Time Systems. Reading, Mass.: Addison-Wesley, 1993. ISBN 0-201-52577-1.
[7] HALANG W. et al., Real-Time Computing Education: Responding to a Challenge of the Next Century, Real-Time Programming 1997. Oxford: Pergamon, 1997, pp. 121-125. ISBN 0-08-043045-7.
[8] HAREL D., M. POLITI, Modeling Reactive Systems with Statecharts. New York: McGraw-Hill, 1998. ISBN 0-07-026205-5.
[9] HEINKE FRIGERI A., W.A. HALANG, S.H. SON (Eds.), Real-Time Programming 1999. Oxford: Pergamon, 1999, ISBN 0-08-043548-3.
[10] KORNECKI A., H. WOJCICKI, L. PELTIER, J. ZALEWSKI, N. KRUSZYNSKA, Teaching Device Drivers Technology in a Real-Time Systems Curriculum. In Real-Time Systems Education III, Los Alamitos, Calif.: IEEE Computer Society Press, 1999, pp. 42-48. ISBN 0-7695-0134-6.
[11] KORNECKI A., J. ZALEWSKI, Projects for Real-Time Systems Classes. In Real-Time Systems Education, Los Alamitos, Calif.: IEEE Computer Society Press, 1996, pp. 80-89. ISBN 0-8186-7649-3.
[12] SELIC B., G. GULLEKSON, P.T. WARD, Real-Time Object-Oriented Modeling. New York: John Wiley and Sons, 1994. ISBN 0-471-59917-4.
[13] SZYPERSKI C., Component Software – Beyond Object Oriented Programming. Reading, Mass., and New York: Addison-Wesley/ACM Press, 1997. ISBN 0-201-17888-5.
[14] WARD P.T., S.J. MELLOR, Structured Development for Real-Time Systems. Vols. 1-3. Englewood Cliffs, N.J.: Prentice Hall, 1985/86. ISBN 0-917072-51-0 (Vol. 1); 0-13-854795-5 (Vol. 2), 0-13-854803-X (Vol. 3).
[15] ZALEWSKI J., Cohesive Use of Commercial Tools in a Classroom. In Proc. Seventh SEI Conf. On Software Engineering Education, Berlin: Springer-Verlag, 1994, pp. 65-75. ISBN 3-540-57461-1.
[16] ZALEWSKI J., Real-Time Software Architectures and Design Patterns: Fundamental Concepts and Their Consequences. Real-Time Programming 1999. Oxford: Pergamon, 1999, ISBN 0-08-043548-3.