Automatic Development Tools in Software Engineering Courses Janusz Zalewski School of Electrical Engineering & Computer Science University of Central Florida Orlando, FL 32816-2450, USA jza@ece.engr.ucf.edu http://www-ece.engr.ucf.edu/~jza/ Abstract In this paper, the author discusses the role of automatic software development tools in graduate software engineering courses. The basic requirements for such tools, from the industry perspective, are presented, followed by the selection of tools meeting a comprehensive set of criteria in four process-related dimensions: internal, vertical, horizontal, and diagonal. Typical software development projects for student teams used in the Software Engineering Program at the University of Central Florida are presented, involving the following four software tools: SES/workbench, ObjecTime Developer, ilogix Rhapsody, and Gensym G2. 1 Introduction Contemporary software development is too complex to be done manually by a single individual. Industrial companies seek graduates whose technical skills go far beyond traditional software engineering curricula, based in principle on programming. Students are expected to have technical knowledge not only of programming languages but also of specic software methodologies and tools the industry uses on a daily basis. In the Software Engineering Program at the University of Central Florida, we are recognizing this fact and intensify the use of automatic software tools in a classroom environment. To be fully useful in educating students in software development, the automatic tools have to comply with full industrial requirements and provide support in the following four dimensions (Fig. 1): internal, related to all aspects of expressing architectural models via specic notation and respective transformations horizontal, related to means of communication with other models and other tools (for example, via TCP/IP protocol suite) vertical, related to the next and previous phases of the development process, with respect to: { support for code generation and prototyping, in particular, for specic programming languages and operating system kernels, and { support for design verication against the requirements (for example, to assure one-to-one correspondence of design components with the requirements) 1
diagonal, related to the use of architectural models in dierent projects and dierent processes. Previous Phase Other Processes Other Components Design Architecture Next Phase Fig. 1. Issues to consider when evaluating or selecting software development tools. 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 with respect to both the software product and the software process: correctness and performance in the internal dimension interoperability and connectivity in the horizontal dimension testability and traceability in the vertical dimensions reusability and portability in the diagonal dimension. During the years of practice in software development for real-time systems, the author evaluated and tested a whole variety of software tools suitable for use in the academic environment [1]. In recent years, the rapid evolution of software methodologies and supporting tools which operate in the networking environments made the evaluation and selection process much more comprehensive. Based on the set of criteria presented above, the following four tools were selected for classroom use in real-time software development projects: SES/workbench simulation tool from Hyperformix (Austin, Texas), to provide the ability of prototyping and checking the behavioral properties of software with respect to the internal criteria (correctness, performance, etc.) ObjecTime Developer from ObjecTime (Kanata, Ont., Canada), from the point of view of meeting the vertical development criteria (code generation and deployment, tracing the requirements) G2 from Gensym (Cambridge, Mass.), to meet horizontal design criteria of connectivity and inter-operability during real-time operation Rhapsody from ilogix (Burlington, Mass.), from the point of view of meeting diagonal criteria of the model portability and reusability across dierent projects.
2 Sample Projects In the following sections, a brief description of fours projects is presented, All projects are relatively complicated to resemble real-life environments and issues to deal with in an industrial setting. Due to space limitations, only an outline of each project is given here, referring the reader to respective web pages for more information. Current documentation should be available from the author's web page in the COURSES directory (EEL6897 and EEL6785). The duration of each project is one semester (12 weeks) and successful completion consists of the demonstration of the running software and submission of the following three deliverables: requirements specication, design description, and user manual (including test results). Progress is checked at the end of 4th and 8th week by the presentation of specication and design documents, respectively. 2.1 Space Shuttle Checkout and Launch Control System The Checkout and Launch Control System (CLCS) provides the facilities for system engineers and test conductors to command, control, and monitor space vehicle systems from the start of the Shuttle Interface Test through terminal countdown and launch or Abort/Sang and Scrub Turnaround. CLCS has been designed to be used in a wide range of control and checkout applications, including future space vehicles. A simulation model shall be built in SES/workbench for the various subsytems and services to meet the following objectives: Study workow through the system. Identify performance problems. Identify resource bottlenecks. Study resource usage and competition for resources. Analyze alternative approaches and tradeos. After realizing these objectives and gaining a greater understanding of the system to be modeled, the information will be disseminated to the modelers, designers, and programmers. Depending upon the results of the modeling and simulation, those groups may have to rene their work products to overcome potential problems concerning performance and/or resource usage. 2.2 Distributed Embedded Simulation This project consists of a training system developed for combat vehicles. The purpose is to use the combat vehicle itself for training, instead of developing separate training 'rooms' for a combat vehicle, which would cost much more. Through an interface between the combat vehicle and the training system, virtual environments can be generated for the purpose of embedded training, mission rehearsal, battleeld visualization, command coordination and simulation based acquisition. The simulation model is to be fully implemented in ObjecTime. The objective is to link the main part, developed separately, with external simulation models, which are implemented in ObjecTime Developer. These models will be running on dierent machines and
will be linked with the simulation model through the use of sockets. The protocol and message format for communication among all modules is given in a separate documentation. When a message is received, the data can be altered and then sent back for conrmation that the module was able to read, write and send data back to the SimSys. 2.3 Air Trac Control System The purpose of air-trac control is to assure safe separation between en-route aircraft and the safe and ecient handling of aircraft operations at airports. Air trac control is a closed loop activity in which pilots state the intent by ling ight plans. Controllers then plan trac ow based on the total number of ight plans and, when possible, give clearance to pilots to y according to their plans. When planning conicts arise, controllers resolve them by clearing pilots to y alternatives to their plans to avoid the conicts. If unpredicted atmospheric conditions (e.g., wind speed or direction) or pilot actions cause deviations from conict-free planned routings, controllers issue clearances for tactical maneuvers that solve any resultant problem, albeit not necessarily in a way that furthers the pilot's goal of reaching the planned destination at a certain time. The United States airspace is divided into 20 regions called En Route Trac Control Centers. Each Center is further divided into sectors. An air trac controller can control one or more air trac sectors in a Center. The airspace surrounding an airport is termed the Tracon (Terminal Radar Approach Control Area). The Tracon area is usually dened as 40-mile radius around a major airport, having an altitude of around 10,000 feet. The Tracon receives control of aircraft that are landing at the Tracon's airport and passes control of aircraft that are leaving the Tracon airspace. The Tower has nal approach control of an arriving aircraft and departure control of aircraft wanting to leave the airport. More specically, the planes start their ight with a clearance from one of more than 400 airport Towers. At about two statute miles away from the runway, one of 185 Tracon facilities takes over, tracking the planes in lower altitudes to, typically, 40 miles from an airport. Twenty eight Tracons are separate sites, the rest are part of an airport Tower. The objective of this project is to use the Universal Modeling Language (UML) and its supporting toolset, Rhapsody, to design an air trac control system (ATCS) that is fault tolerant and scalable, according to the specic requirements provided in a separate documentation. 2.4 Intelligent Data Acquisition System The objective of this project is to develop a distributed data acquisition system, which collects the data from remote sensors to the central management station, and provides an automatic reasoning capability about the acquired data with full graphical representation in real time. A real-time expert system G2 has been chosen for this task. Sample requirement include: sampling periods at remote stations between 50-500 ms (depending on station) data collection rate for the main station - 1 second continuous display of all remote sensor values graphical representation of controls (buttons, dials, etc.) reasoning about data according to a set of rules provided in a separate documentation.
3 Conclusion In the types of projects outlined above, the use of sophisticated and powerful development tools turned out to be very successful. Even though some of the projects were not fully completed and the products lacked certain obvious features, the primary objective: learning to apply the software tool in a real-life environment, was achieved in each case. The major diculty experienced by students was, of course, very steep learning curve for each of these tools. Realistically, to master the use of any ofsuch tools at a comfortable level requires approximately half of a semester of lab work. This problem is partially solved, when students who already mastered the use of a tool take another class next semester and tutor others who have not been exposed to these technologies before. References [1] Zalewski, J., Cohesive Use of Commercial Tools in a Classroom, pp. 65-75, Proc. 7th SEI Conf. on Software Engineering Education, San Antonio, TX, January 5-7, 1994, J.L. Diaz-Herrera (Ed.), Springer-Verlag, Berlin, 1994