Effects of Ada on design problems in a discrete event simulator

Abstract

Overall, our experience using the Ada programming language proved to be a valuable one. We believe that using an alternate high level language would not have allowed us to maintain the tight schedule of the evolutionary development of ISAAC. Clearly, the software engineering orientation of Ada was key to the success of the ISAAC simulator. Our desired to maintain an object orientation during the design and implementation process proved useful but was a bit cumbersome at times. While there are several methods to emulate some form of inheritance in Ada, the lack of a controlled two way communication mechanism between objects is a significant restriction with Ada as it relates to object oriented methodologies. We were fortunate to have the event queue in the simulator available to allow an efficient implementation of the two way communications we required. The technique used for implementing the Task Manager's data structure followed a standard paradigm for implementing a data architecture documented in an Entity-Relation-Attribute form. This technique was successful, which suggests to us the possibility of directly compiling the extended E-R-A model (including the relation characteristics used for choosing implementation structures). Extending a language to support directly an abstract Entity-Relation model would eliminate the need for coding data structures and data management algorithms, greatly reduce development time, and will result in better designs by encouraging design at an abstract level. The use of generics in the component architecture was extremely valuable in support of the abstract data entities implementation as well as significantly reducing the overall integration testing effort Although our emphasis in this paper on the use of component architecture was concentrated on the use in the Maintenance Manager, many of these generics were used in the Operations and Resource Managers as well. It interesting that the major emphasis in the rationale for the fixed point type design was limited to the real-time data acquisition domain [Rationale, 1986]. We question why other problem domains were not included in the rationale's analysis. The domain of probability calculations is both important and quite widely used. Our record oriented representation removes the uncertainties and would be adapted easily to other fixed point problems outside the probability domain. If it were incorporated into the Ada language, it would provide an excellent alternative to the real-time oriented Ada implementation. We believe the benefits of this alternate implementation of fixed point are so significant that this implementation should be considered for any fixed point application. A final note of interest is that all of the development staff, including management, had no previous Ada experience before the start of the development phase of the project in January 1989. The development staff attended a two in-house Ada training program and continually gained experience throughout the evolutionary development of ISAAC. We do hope that the presentation of our experiences working in the Ada environment will prove helpful to others in the government, industry, and academia. ©1990 ACM.