- Email: [email protected]
Integrated Design for Research Oriented Systems: The Software Bottleneck
Copyright @ IF AC Integrated Systems Engineering. Badcn-Baden. Gennany. 1994
INTEGRATED DESIGN FOR RESEARCH ORIENTED SYSTEMS: THE SOFIWARE BOTTLENECK
E. THEUNISSEN·
•Ddft UnMniIy of T~, Faculty of E/ectricoJ Engin«ring, P.O. Box 5031, 2600 GA DeIft, NL Abstnct. Successful integrated system design requires the seamless fusion of domain specific knowledge from the encompassing disciplines into a single product. One of the problems which hampers the efficient design of systems is the fact that in many cases end users are initially unable to specify complete requirements. This is also true for software development, and a major bottleneck in the design and evaluation of systems is caused by software development problems. Various rapid prototyping tools exist to aid the user with the requirements specification. This paper discusses an approach which has the capability to smoothly progress beyond the prototyping phase.
Key Words. Aerospace engineering; computer-aided system design; program testing; program translators; software development; software engineering; software tools
investment in flexibility during system development. Flexibility is for a large part determined by software.
1. IN1RODUcnON Delft University of Technology has recently acquired a Cessna Citation 11 aircraft for research and educational purposes. For the former one, the aircraft had to be equipped with six interactive display systems which would allow it to be operated as a flying classroom. For the latter purpose, a compact high performance display system which could be installed in the right instrument panel had to be developed. Both systems were realized in a cooperation between the Faculties of Aerospace Engineering and Electrical Engineering. Furthermore, Delft University of Technology is developing a new research simulator. This new flight simulator, from now on referred to as the SRS which is an acronym for Simona Research Simulator, is being developed in a joint operation between the Faculties of Aerospace Engineering, Electrical Engineering, and Mechanical & Maritime Engineering.
Furthermore, research oriented systems are often characterized by highly interactive hardware and software. In the design of such systems it is of crucial importance to integrate software requirements with hardware design synthesis. Due to the rapid increases in performance of computer hardware this is not easy. Plant (1993) refers to the effect of the rapidity of technology changes in the area of information technology as the '4 T effect'. He states that 'unless management and developers control their software processes through an understanding of the impact that hardware, software, practical and theoretical developments have upon it, these technology changes may have a serious and detrimental effect upon the developers software creation process'. Research oriented systems should be able to keep up with advances in technology during their entire lifecycle. Software should be designed in such a way that when upgrading hardware, no major reengineering or programming is required. In other words, the software lifecycle should be extended beyond the hardware lifecycle. As a result it is necessary to design hardware with the objective of upgradeability and scalability, and software with the Objective of rehostability in mind.
One of the typical characteristics of research oriented systems is the high frequency of changes in the functional requirements during their entire lifecycle. For the design of an efficient system it is important to recognize this. To assure that during the operationallifecycle changes in the functional specification do not require major system modifications, the need for flexibility becomes paramount. This justifies an increased up-front 77
at the early design stages are much cheaper than changes to a finished product. A basic difference between the waterfall model and the prototyping model is the feedback from later to earlier phases. This feedback provides information on how decisions made at one stage are reflected later in the design, and therefore can be used to incrementally improve the earlier phases. The spiral model (Boebm, 1988) which involves a repetition of specify-design-code-validate cycles, is representative for the approach in which an easily specified prototype is extended on each cycle, and can be classified as an evolutionary prototyping approach. Based on the concept 'the larger a project is, the more there is to gain from up front investment' Levy (1986) proposes "metaprogramming" to reduce cost by reducing total system development time and increasing quality. Metaprogramming is an approach in which first a 'throwaway' prototype is generated based on a certain set of requirements which remain fixed. Once the prototype is completed and the form of the final system is fixed, a set of application generators are built which construct the real system directly from the specifications. Further system modification is done by changing the input to the generators. In Balzer's (1983) automation based paradigm, the software lifecycle is split into a repetitive prototyping cycle containing the specificationdesign-evaluation phases, followed by a coding phase. An increase in productivity relative to the spiral model can be obtained since the coding and validation process has been taken out of the prototyping lOOp. His new knowledge based software paradigm is characterized by the fact that all software lifecycle activities are machine mediated and supported, or in other words 'the machine is in the loop'. In this new software paradigm, the actual implementation is automatically derived from a formal specification. An additional advantage of automatic code generation is that to the extent that the formal manipulations which are used to generate code from a specification can be proved correct, the validation paradigm will be radically altered (Green et aL, 1986). Rather than testing the resulting implementation against the specification, the validity of the implementation arises from the process by which it was developed. Harers (1992) "vanilla" approach to modelling discusses executable specificatiOns as a means to test the model before actual implementation. This execution requires an interpreter which can run the Specification to simulate the dynamic operation, thus allowing extensive prototyping and simulation of the system in the early design phases. A further advantage of model execution is that the possibility increases that unintended patterns of
One of the problems which hampers the efficient design of systems is the fact that in many cases end users are initially unable to specify complete requirements. This is also true for software. Communication problems can result in conflicting or misinterpreted information, which reduces productivity and can lead to costly patches or require a partial redesign of the final product. As a result, the required fusion of knowledge is only obtained at very high cost. Various rapid prototyping tools exist which can be used to aid the designer with the acquisition of the requirements by providing feedback to the end users in the early design stages. However, this is not enough. For efficient system design it is very important to be able to smoothly proceed beyond the prototyping phase. This often requires rehosting of the software from the rapid prototyping system to a specific target system. Summarizing, when developing software for research oriented systems it is important to recognize the influence of the high frequency of changes in the functional specificatiOns on the required flexibility of the system, the need to integrate software requirements with hardware design synthesis, and the need to design for rehostability.
2. SOFIWARE An often encountered problem with existing software development paradigms is their inability to efficiently scale up to large projects. Therefore, the flaws responsible for this problem must be identified and eliminated. Various approaches have been proposed (Balzer et aL, 1983; Levy, 1986; Boebm, 1988). To select the one which best satisfies the requirements typical for research oriented systems, a better understanding of the typical software lifecycle in a research environment is required.
2.1
Software lifecycle models
Various models have been proposed to describe the software lifecycle. Davis et aL (1988) present a strategy for comparing alternative software development lifecycle models. Most of the different lifecycle models are either of the waterfall (Boebm, 1976) or of the prototyping model type. The latter one can be divided into rapid prototyping, where a 'throwaway' prototype is generated for initial evaluation purposes and evolutionary prototyping, where the prototype is successively refined into the final product. In this way lifecycle cost are reduced since changes made
78
realistic approaches to automatic programming: the 'bottom up approach', the 'narrow domain approach' and the 'assistant approach'. The first one is characterized by the use of very high level languages. The second approach focuses on the concept in which the end user specifies his requirements in a formal way, and uses an automatic code generator to translate these requirements into software. The third one, the assistant approach focuses on a system which supports the software designer with the design and the programmer with the implementation of the software, thus sacrificing the principle of full automation. Productivity is increased through the use of so-called assistant tools. The second myth of Rich (1988) says 'End user oriented, general purpose, fully automatic programming is possible'. In his description of reality, currently only the narrow domain approach seems feasible to construct a fully automatic program generator which directly communicates with the end user. Lowry (1991) states that automatic code generation requires trade-offs between several dimensions. He identifies the following five:
behaviour are discovered before system implementation. Balzer (1983) indicates that in certain situations the interpreted specification satisfies all the end user needs, and code generation for implementation becomes unnecessary. An advantage of interpretation compared to code generation is the high flexibility and the fact that no compilation is necessary after changes have been made to the specification. The important advantage of code generation is the increased performance and the reduced size of the resulting software, which can become even more important when code has to be ported to other target environments. 2.2
Possible approaches
As indicated in the previous section, several approaches to increase productivity exist. To cope with the increasing demands in complexity and flexibility, tools have been developed which assist the designer with the aatuisition of the specification (Kellyand Nonnenmann, 1991). As major difficulties in software design are caused by a lack of application domain knowledge on part of the designer, the need for methods to aatuire this knowledge from domain experts arises, and methods to represent this knowledge have been introduced (Borgida et aL, 1985). Nowadays, Computer Aided Software Engineering (CASE) tools try to adhere to these principles. Although for some applications code-generators which translate a formal Specification of the required functionality into an implementation in a certain target language have been developed (Barstow, 1991; Bordano et aL, 1993), most CASE tools only produce charts and documentation, and the implementation still has to be performed by a programmer. As a consequence, maintenance is still performed at the implementation level and the danger arises that during the lifecycle of the software the source code becomes the only source of available information about the actual functionality. The automatic programming paradigm (Balzer et aL, 1983) presents a solution to this problem.
1. The distance spanned between the specification level and the implementation level. 2. The breadth of the domain covered at the specification level. 3. The efficiency of the implemented code 4. The efficiency and degree of automation of the translation process 5. The correctness of the implemented code
3.1
Identification of pitfalls
As indicated by Balzer (1983), one of the
fundamental flaws in the existing software paradigm is the fact that maintenance is performed at the implementation level rather than at the Specification level. Of course this is still possible with automatic code generation and to prevent this from happening, the reasons for modifying the source code must be uncovered and eliminated. The problem is typical for code generators which produce source code from a specification, but hardly occurs with compilers. With the current software paradigm everybody will agree that when a modification must be made to a program and both the source code and the Object code is available, the modification is made at the source code level. Why? Because it is the easiest thing to do. If we are able to create the same situation with automatic code generation, nobody will try to modify the generated code, and the problem mentioned previously will disappear. Several reasons for modifying automatically generated software can be identified. These reasons
3. AUTOMATIC PROGRAMMING Often, automatic programming is identified with the situation Rich (1988) refers to as the cocktail party description of automatic programming: 'The end user writes a brief requirement for what is wanted, and the programming system will produce an efficient program satisfying the requirement'. Resulting euphoria soon after ends in disappointment Rich (1988) identifies three
79
experienced programmer would use, is necessary. The motivation to modify the code to increase speed will disappear when the efficiency of the generated source code exceeds a certain threshold. Besides these pitfalls, another aspect is very important. The system itself should be user friendly, require limited training for basic usage, and couple a gradual degree of desired complexity to a gradual increase in required expertise. In this way, a low entry level is enabled, a broad user community can be realized, and a better control of training cost is possible. If the system is only understood by a few experts, and the threshold of becoming an expert is too high, non-experts will still fall back on manual programming.
have been divided into the following three categories: 1. Allow the software to communicate with other
modules. 2. Make quick changes to the functionality. 3. Increase speed by optimizing the source code. Once a change has been made at the implementation level, the user is confronted with the dilemma that when new changes are required, all changes which were made at the implementation level must be performed again in case the new changes are made at the specification level. This will disoourage the use of the code generator for small changes in the specification of the functionality. As a result, these changes are made in the source code, and the consistency between the specification produced with the development system and the program is lost. This approach is sure to backfire in the long term as it is a very tedious task to keep track of all changes so they can be implemented in the next version of the automatically generated code. Cleaveland (1988) indicates that since a code generator is frequently part of a larger system, interfacing the automatically generated code and the rest of the system is very important. The second of Oeaveland's (1988) seven steps to building a generator therefore requires the definition of domain boundaries, and an answer to the question of what and where the interfaces should be. A method to disoourage the user from modifying the source code is to design the system in such a way that the representation of the desired functionality is not in the source code, but loaded at the start of the program. Following the idea of 'what is hard to read is hard to understand and even harder to modify', another option to discourage people from modifying automatically generated source code, proposed by Knuth (Bentley, 1986), is to generate hard-to-read programs. The wish to optimize speed is another motivation for changing the source code. For example, the graphics hardware and software determine the update rate of the displayed information, given the update rate of the information itself is high enough. The cost of the graphics hardware grows with increasing requirements on the information update rate. Update rates can be increased through clever programming of the graphics hardware. An experienced programmer will know what methods to use to obtain the highest performance. In contrast, a code generator does not contain this experience. In order for a code generator to produce optimized code, a rule base, capable of applying most of the methods which an
4. MAN-MACHINE IN1ERFACES At Oelft University of Technology, both the simulator and the laboratory aircraft are used for research into Man-Machine Interfaces (MMIs). The software complexity of the MMIs is for a large part determined by the User Interface (UI), which relies heavily on display software. Various rapid prototyping tools exist which can be used to aid the designer with display format development. However, for efficient simulator and in-flight evaluation it is important to be able to smoothly proceed beyond the prototyping phase. This requires rehosting and integration of the display software from the prototyping system to a specific . target system, which can considerably increase turnaround time. To solve this problem, the development of display software for the research simulator and the laboratory aircraft is based on the automatic programming paradigm (Balzer, 1983). A system for the development and evaluation of display software, 03S, has been realized in 1991 (Theunissen, 1994). The system is now being used for the development of display software in the laboratory, the research flight simulator, and in the laboratory aircraft. Conventional as well as various advanced display formats for research purposes, e.g. Tunnel-in-the-Sky (Theunissen, 1993), have been developed with this system. The 03S philosophy is to provide computer support at the requirements acquisition phase, the UI design phase, the software design phase, the code development phase, the software integration phase, and during maintenance and rehosting. All transitions between these phases are computer mediated, keeping all participants in the same loop through computer support.
4.1
Specification
To obtain a common frame of reference a 80
4.3
specification method, the so-called Display Definition Format (DDF), has been developed. A large distance is spanned between the specification and the implementation level, and the requirements can be specified in a narrow domain. To eliminate the necessity of making changes for communication purposes, a standard interface towards the display software has been defined in D3S (Theunissen, 1994). The high level part of the interface is connected to the inputs of the display program, and the low level part allows direct access to the buffers containing the object descriptions. To speed up the process of acquiring a workable initial specification, the UI designer is supported with tools which allow him to specify an initial design, evaluate its behaviour and refine it through the feedback obtained this way.
4.2
Software integration
Integration with the flight simulator or the laboratory aircraft requires the assistance from software specialists. To support these specialists, various tools can be used. To obtain an overview of the software design and the communication with the other systems, the specification can be translated into diagrammatic charts. In these charts the details about the layout of the UI are hidden, and the communication interface with other software is emphasized. To support the programmer with the integration of the software, source files containing the exact specification of the interface of the display software are automatically generated. This is especially useful since this information is both required for the transmitting modules and their receiving counterparts.
Implementation 4.4
The actual implementation is derived from the specification via a series of formal manipulations, often referred to as transformations. Vertical transformations are used to reduce the level of abstraction, and proceed from the specification level to the implementation level, and horizontal transformations are used to optimize the code. An advanced code generation facility allows the automatic construction of an executable prototype for further evaluation. The degree of automation in the translation process is very high. In fact, no interaction with the user is required. The · efficiency of the implemented code is also high, and situations in which it is useful to modify the generated code to increase display update rates are rarely possible. The approach to code generation used in D3S combines most of the flexibility from executable specifications with the advantages in speed and size of code generation. The first specificationevaluation cycle comprises the process of acquiring a workable initial specification. Once this specification is complete, the implementation can be generated. This rapid prototyping capability reduces the effort required for initial concept evaluation. The second specificationevaluation cycle represents simulator or in-flight evaluation. Since the Specification is loaded at the start of the program, changes to the display format can be implemented in the specification without having to regenerate the software. Thus, code generation has been taken out of the second specification-evaluation cycle, which reduces the turnaround time for simulator and in-flight evaluation. Furthermore, it prevents the user from making changes to the display format at the implementation level, since the information simply is not in the source code.
Maintenance and reuse
A variety of tools can be used for display software maintenance at the specification level. Since the specification is easy to understand, in most cases a text editor suffices. For a modification of the layout, a graphics editor is more appropriate. Since reusability is provided at the specification level, where the functionality is not yet influenced by all kind of implementation specific details, this method also encourages reuse of existing display formats. 4.5
Upgradeability and rehosting
To rehost the display software to the selected target system, code generators for the various target systems have been developed. By designing for hardware independency and separating hardware independent and hardware dependent mechanisms, the effort required for upgrading to newer systems has been minimized, while the ability to optimize for the target hardware remains. In this way, the software lifecycle can be extended beyond the hardware lifecycle.
5. CONCLUSION Due to the desired complexity, incomplete initial specification of the requirements, and the high frequency of changes in these requirements during the operational lifecycle of research oriented systems, software development, integration, and maintenance can pose a serious bottleneck. For efficient integrated system design these problems must be recognized and dealt with. Rapid prototyping systems can be used to speed up 81
Borgida, A, Greenspan, S., Mylopoulos, J. (1985). Knowledge Representation as the Basis for Requirements Specifications. IEEE Computer, Vol. 18, No. 4, pp. 82-90.
the process of acquiring complete specifications. However, there is a need to be able to smoothly proceed beyond the prototyping phase. By providing computer support at all design phases, the transitions between these phases can be computer mediated. In this way it is possible to reduce communication problems and keep all participants in the same loop. By separating hardware dependent and hardware independent mechanisms and using a hardware dependent rulebase for optimization, efficient rehosting is possible, and the software lifecycle can be extended beyond the hardware lifecycle. Experience with the development of display systems for the research flight simulator and the laboratory aircraft indicates that the approach to display software development described in this paper can be used to reduce the software bottleneck to an acceptable level. In environments where functional requirements during the product lifecycle are more stable than in a research environment, the approach described here is equally useful since it allows rapid prototyping and a fast transition from the prototype to a production system.
Cleaveland, J.C. (July 1988). Building Application Generators. IEEE Software, 25-33. Davis, AM., Bersoff, E.H., Corner, E.R. (1988). A Strategy for Comparing Alternative Software Development Life Cycle Models. IEEE Transactions on Software Engineering, Vol. 14, No. 10, pp. 1453-1461. Green, c., Luckham, D., Balzer, R., Cheatham, T., Rich, C. (1986). Report on a knowledge based software assistant. Readings in Artificial Intelligence and Software Engineering (Rich, C. and Waters, R.C., Eds.), pp. 377-428. Morgan Kaufmann, Los Altos. Harel, D. (1992). Biting the Silver Bullet. IEEE Computer, Vol. 25, No.l, pp. 8-20. Kelly, V.E., Nonnenmann, U. (1991). Reducing the Complexity of Formal Specification Acquisition. In: Automating Software Design (Lowry, M.R. and McCartney, R.D., Eds.), pp. 41-64. AAA! Press, Menlo Park.
6. REFERENCES Balzer, R., Cheatham, T.E., Green, C. (1983). Software Technology in the 1990's: Using a New Paradigm. IEEE Computer, Vol. 16, No. 11, pp. 39-45.
Levy, 1..S. (1986). A Metaprogramming Method and Its Economic Justification. IEEE Transactions on Software Engineering, Vol. SE12, No. 2, pp. 272-277.
Barstow, D. (1991). Automatic Programming for Device-Control Software. In: Automating Software Design (Lowry, MR. and McCartney, R.D., Eds.), pp. 123-140. AAA! Press, Menlo Park.
Lowry, M.R. (1991). Software Engineering in the Twenty-First Century. In: Automating Software Design (Lowry, M.R. and McCartney, R.D., Eds.), pp. 627-654. AAA! Press, Menlo Park.
Bentley, J. (1986). Programming Pearls: Literate Programming. Com. of the ACM, Vol. 29, No. 5, pp. 364-369.
Plant, R.T. (1993). Software Development Process Model for Aerospace Systems. Proc. of the 9th AlAA Computing in Aerospace Conference, pp. 883-890.
Boehm, B. W. (1976). Software Engineering. IEEE Trans. on Computers, Vol. C-25, No. 12, pp. 1226-1241.
Rich, C. and Waters, R.C. (1988). Automatic Programming: Myths and Prospects. IEEE Computer, Vol. 21, No. 8, pp. 40-51.
Boehm, B. W. (1988). A Spiral Model of Software Development and Enhancement. IEEE Computer, Vol. 21, No. 5, pp. 61-72.
Theunissen, E. (1993). The DELPHINS Tunnel-inthe-Sky program. Proc. of the Looking-Ahead Symposium, pp. 16.1-16.9. Amsterdam, The Netherlands.
Bordano, A, Lacovara, J.U., DeVall, R., Partin, C., Sugano, J., Doane, K., Compton, J. (1993). Cooperative GN&C Development in a Rapid Prototyping Environment. In: Proc. of the 9th AIAA Computing in Aerospace Conference, pp. 883-890.
Theunissen, E. (1994). The Development of the Delphins Display Design System. Proc. of the International Training and Equipment Conference pp. 583-588, The Hague, The Netherlands.
82
INTEGRATED DESIGN FOR RESEARCH ORIENTED SYSTEMS: THE SOFIWARE BOTTLENECK
E. THEUNISSEN·
•Ddft UnMniIy of T~, Faculty of E/ectricoJ Engin«ring, P.O. Box 5031, 2600 GA DeIft, NL Abstnct. Successful integrated system design requires the seamless fusion of domain specific knowledge from the encompassing disciplines into a single product. One of the problems which hampers the efficient design of systems is the fact that in many cases end users are initially unable to specify complete requirements. This is also true for software development, and a major bottleneck in the design and evaluation of systems is caused by software development problems. Various rapid prototyping tools exist to aid the user with the requirements specification. This paper discusses an approach which has the capability to smoothly progress beyond the prototyping phase.
Key Words. Aerospace engineering; computer-aided system design; program testing; program translators; software development; software engineering; software tools
investment in flexibility during system development. Flexibility is for a large part determined by software.
1. IN1RODUcnON Delft University of Technology has recently acquired a Cessna Citation 11 aircraft for research and educational purposes. For the former one, the aircraft had to be equipped with six interactive display systems which would allow it to be operated as a flying classroom. For the latter purpose, a compact high performance display system which could be installed in the right instrument panel had to be developed. Both systems were realized in a cooperation between the Faculties of Aerospace Engineering and Electrical Engineering. Furthermore, Delft University of Technology is developing a new research simulator. This new flight simulator, from now on referred to as the SRS which is an acronym for Simona Research Simulator, is being developed in a joint operation between the Faculties of Aerospace Engineering, Electrical Engineering, and Mechanical & Maritime Engineering.
Furthermore, research oriented systems are often characterized by highly interactive hardware and software. In the design of such systems it is of crucial importance to integrate software requirements with hardware design synthesis. Due to the rapid increases in performance of computer hardware this is not easy. Plant (1993) refers to the effect of the rapidity of technology changes in the area of information technology as the '4 T effect'. He states that 'unless management and developers control their software processes through an understanding of the impact that hardware, software, practical and theoretical developments have upon it, these technology changes may have a serious and detrimental effect upon the developers software creation process'. Research oriented systems should be able to keep up with advances in technology during their entire lifecycle. Software should be designed in such a way that when upgrading hardware, no major reengineering or programming is required. In other words, the software lifecycle should be extended beyond the hardware lifecycle. As a result it is necessary to design hardware with the objective of upgradeability and scalability, and software with the Objective of rehostability in mind.
One of the typical characteristics of research oriented systems is the high frequency of changes in the functional requirements during their entire lifecycle. For the design of an efficient system it is important to recognize this. To assure that during the operationallifecycle changes in the functional specification do not require major system modifications, the need for flexibility becomes paramount. This justifies an increased up-front 77
at the early design stages are much cheaper than changes to a finished product. A basic difference between the waterfall model and the prototyping model is the feedback from later to earlier phases. This feedback provides information on how decisions made at one stage are reflected later in the design, and therefore can be used to incrementally improve the earlier phases. The spiral model (Boebm, 1988) which involves a repetition of specify-design-code-validate cycles, is representative for the approach in which an easily specified prototype is extended on each cycle, and can be classified as an evolutionary prototyping approach. Based on the concept 'the larger a project is, the more there is to gain from up front investment' Levy (1986) proposes "metaprogramming" to reduce cost by reducing total system development time and increasing quality. Metaprogramming is an approach in which first a 'throwaway' prototype is generated based on a certain set of requirements which remain fixed. Once the prototype is completed and the form of the final system is fixed, a set of application generators are built which construct the real system directly from the specifications. Further system modification is done by changing the input to the generators. In Balzer's (1983) automation based paradigm, the software lifecycle is split into a repetitive prototyping cycle containing the specificationdesign-evaluation phases, followed by a coding phase. An increase in productivity relative to the spiral model can be obtained since the coding and validation process has been taken out of the prototyping lOOp. His new knowledge based software paradigm is characterized by the fact that all software lifecycle activities are machine mediated and supported, or in other words 'the machine is in the loop'. In this new software paradigm, the actual implementation is automatically derived from a formal specification. An additional advantage of automatic code generation is that to the extent that the formal manipulations which are used to generate code from a specification can be proved correct, the validation paradigm will be radically altered (Green et aL, 1986). Rather than testing the resulting implementation against the specification, the validity of the implementation arises from the process by which it was developed. Harers (1992) "vanilla" approach to modelling discusses executable specificatiOns as a means to test the model before actual implementation. This execution requires an interpreter which can run the Specification to simulate the dynamic operation, thus allowing extensive prototyping and simulation of the system in the early design phases. A further advantage of model execution is that the possibility increases that unintended patterns of
One of the problems which hampers the efficient design of systems is the fact that in many cases end users are initially unable to specify complete requirements. This is also true for software. Communication problems can result in conflicting or misinterpreted information, which reduces productivity and can lead to costly patches or require a partial redesign of the final product. As a result, the required fusion of knowledge is only obtained at very high cost. Various rapid prototyping tools exist which can be used to aid the designer with the acquisition of the requirements by providing feedback to the end users in the early design stages. However, this is not enough. For efficient system design it is very important to be able to smoothly proceed beyond the prototyping phase. This often requires rehosting of the software from the rapid prototyping system to a specific target system. Summarizing, when developing software for research oriented systems it is important to recognize the influence of the high frequency of changes in the functional specificatiOns on the required flexibility of the system, the need to integrate software requirements with hardware design synthesis, and the need to design for rehostability.
2. SOFIWARE An often encountered problem with existing software development paradigms is their inability to efficiently scale up to large projects. Therefore, the flaws responsible for this problem must be identified and eliminated. Various approaches have been proposed (Balzer et aL, 1983; Levy, 1986; Boebm, 1988). To select the one which best satisfies the requirements typical for research oriented systems, a better understanding of the typical software lifecycle in a research environment is required.
2.1
Software lifecycle models
Various models have been proposed to describe the software lifecycle. Davis et aL (1988) present a strategy for comparing alternative software development lifecycle models. Most of the different lifecycle models are either of the waterfall (Boebm, 1976) or of the prototyping model type. The latter one can be divided into rapid prototyping, where a 'throwaway' prototype is generated for initial evaluation purposes and evolutionary prototyping, where the prototype is successively refined into the final product. In this way lifecycle cost are reduced since changes made
78
realistic approaches to automatic programming: the 'bottom up approach', the 'narrow domain approach' and the 'assistant approach'. The first one is characterized by the use of very high level languages. The second approach focuses on the concept in which the end user specifies his requirements in a formal way, and uses an automatic code generator to translate these requirements into software. The third one, the assistant approach focuses on a system which supports the software designer with the design and the programmer with the implementation of the software, thus sacrificing the principle of full automation. Productivity is increased through the use of so-called assistant tools. The second myth of Rich (1988) says 'End user oriented, general purpose, fully automatic programming is possible'. In his description of reality, currently only the narrow domain approach seems feasible to construct a fully automatic program generator which directly communicates with the end user. Lowry (1991) states that automatic code generation requires trade-offs between several dimensions. He identifies the following five:
behaviour are discovered before system implementation. Balzer (1983) indicates that in certain situations the interpreted specification satisfies all the end user needs, and code generation for implementation becomes unnecessary. An advantage of interpretation compared to code generation is the high flexibility and the fact that no compilation is necessary after changes have been made to the specification. The important advantage of code generation is the increased performance and the reduced size of the resulting software, which can become even more important when code has to be ported to other target environments. 2.2
Possible approaches
As indicated in the previous section, several approaches to increase productivity exist. To cope with the increasing demands in complexity and flexibility, tools have been developed which assist the designer with the aatuisition of the specification (Kellyand Nonnenmann, 1991). As major difficulties in software design are caused by a lack of application domain knowledge on part of the designer, the need for methods to aatuire this knowledge from domain experts arises, and methods to represent this knowledge have been introduced (Borgida et aL, 1985). Nowadays, Computer Aided Software Engineering (CASE) tools try to adhere to these principles. Although for some applications code-generators which translate a formal Specification of the required functionality into an implementation in a certain target language have been developed (Barstow, 1991; Bordano et aL, 1993), most CASE tools only produce charts and documentation, and the implementation still has to be performed by a programmer. As a consequence, maintenance is still performed at the implementation level and the danger arises that during the lifecycle of the software the source code becomes the only source of available information about the actual functionality. The automatic programming paradigm (Balzer et aL, 1983) presents a solution to this problem.
1. The distance spanned between the specification level and the implementation level. 2. The breadth of the domain covered at the specification level. 3. The efficiency of the implemented code 4. The efficiency and degree of automation of the translation process 5. The correctness of the implemented code
3.1
Identification of pitfalls
As indicated by Balzer (1983), one of the
fundamental flaws in the existing software paradigm is the fact that maintenance is performed at the implementation level rather than at the Specification level. Of course this is still possible with automatic code generation and to prevent this from happening, the reasons for modifying the source code must be uncovered and eliminated. The problem is typical for code generators which produce source code from a specification, but hardly occurs with compilers. With the current software paradigm everybody will agree that when a modification must be made to a program and both the source code and the Object code is available, the modification is made at the source code level. Why? Because it is the easiest thing to do. If we are able to create the same situation with automatic code generation, nobody will try to modify the generated code, and the problem mentioned previously will disappear. Several reasons for modifying automatically generated software can be identified. These reasons
3. AUTOMATIC PROGRAMMING Often, automatic programming is identified with the situation Rich (1988) refers to as the cocktail party description of automatic programming: 'The end user writes a brief requirement for what is wanted, and the programming system will produce an efficient program satisfying the requirement'. Resulting euphoria soon after ends in disappointment Rich (1988) identifies three
79
experienced programmer would use, is necessary. The motivation to modify the code to increase speed will disappear when the efficiency of the generated source code exceeds a certain threshold. Besides these pitfalls, another aspect is very important. The system itself should be user friendly, require limited training for basic usage, and couple a gradual degree of desired complexity to a gradual increase in required expertise. In this way, a low entry level is enabled, a broad user community can be realized, and a better control of training cost is possible. If the system is only understood by a few experts, and the threshold of becoming an expert is too high, non-experts will still fall back on manual programming.
have been divided into the following three categories: 1. Allow the software to communicate with other
modules. 2. Make quick changes to the functionality. 3. Increase speed by optimizing the source code. Once a change has been made at the implementation level, the user is confronted with the dilemma that when new changes are required, all changes which were made at the implementation level must be performed again in case the new changes are made at the specification level. This will disoourage the use of the code generator for small changes in the specification of the functionality. As a result, these changes are made in the source code, and the consistency between the specification produced with the development system and the program is lost. This approach is sure to backfire in the long term as it is a very tedious task to keep track of all changes so they can be implemented in the next version of the automatically generated code. Cleaveland (1988) indicates that since a code generator is frequently part of a larger system, interfacing the automatically generated code and the rest of the system is very important. The second of Oeaveland's (1988) seven steps to building a generator therefore requires the definition of domain boundaries, and an answer to the question of what and where the interfaces should be. A method to disoourage the user from modifying the source code is to design the system in such a way that the representation of the desired functionality is not in the source code, but loaded at the start of the program. Following the idea of 'what is hard to read is hard to understand and even harder to modify', another option to discourage people from modifying automatically generated source code, proposed by Knuth (Bentley, 1986), is to generate hard-to-read programs. The wish to optimize speed is another motivation for changing the source code. For example, the graphics hardware and software determine the update rate of the displayed information, given the update rate of the information itself is high enough. The cost of the graphics hardware grows with increasing requirements on the information update rate. Update rates can be increased through clever programming of the graphics hardware. An experienced programmer will know what methods to use to obtain the highest performance. In contrast, a code generator does not contain this experience. In order for a code generator to produce optimized code, a rule base, capable of applying most of the methods which an
4. MAN-MACHINE IN1ERFACES At Oelft University of Technology, both the simulator and the laboratory aircraft are used for research into Man-Machine Interfaces (MMIs). The software complexity of the MMIs is for a large part determined by the User Interface (UI), which relies heavily on display software. Various rapid prototyping tools exist which can be used to aid the designer with display format development. However, for efficient simulator and in-flight evaluation it is important to be able to smoothly proceed beyond the prototyping phase. This requires rehosting and integration of the display software from the prototyping system to a specific . target system, which can considerably increase turnaround time. To solve this problem, the development of display software for the research simulator and the laboratory aircraft is based on the automatic programming paradigm (Balzer, 1983). A system for the development and evaluation of display software, 03S, has been realized in 1991 (Theunissen, 1994). The system is now being used for the development of display software in the laboratory, the research flight simulator, and in the laboratory aircraft. Conventional as well as various advanced display formats for research purposes, e.g. Tunnel-in-the-Sky (Theunissen, 1993), have been developed with this system. The 03S philosophy is to provide computer support at the requirements acquisition phase, the UI design phase, the software design phase, the code development phase, the software integration phase, and during maintenance and rehosting. All transitions between these phases are computer mediated, keeping all participants in the same loop through computer support.
4.1
Specification
To obtain a common frame of reference a 80
4.3
specification method, the so-called Display Definition Format (DDF), has been developed. A large distance is spanned between the specification and the implementation level, and the requirements can be specified in a narrow domain. To eliminate the necessity of making changes for communication purposes, a standard interface towards the display software has been defined in D3S (Theunissen, 1994). The high level part of the interface is connected to the inputs of the display program, and the low level part allows direct access to the buffers containing the object descriptions. To speed up the process of acquiring a workable initial specification, the UI designer is supported with tools which allow him to specify an initial design, evaluate its behaviour and refine it through the feedback obtained this way.
4.2
Software integration
Integration with the flight simulator or the laboratory aircraft requires the assistance from software specialists. To support these specialists, various tools can be used. To obtain an overview of the software design and the communication with the other systems, the specification can be translated into diagrammatic charts. In these charts the details about the layout of the UI are hidden, and the communication interface with other software is emphasized. To support the programmer with the integration of the software, source files containing the exact specification of the interface of the display software are automatically generated. This is especially useful since this information is both required for the transmitting modules and their receiving counterparts.
Implementation 4.4
The actual implementation is derived from the specification via a series of formal manipulations, often referred to as transformations. Vertical transformations are used to reduce the level of abstraction, and proceed from the specification level to the implementation level, and horizontal transformations are used to optimize the code. An advanced code generation facility allows the automatic construction of an executable prototype for further evaluation. The degree of automation in the translation process is very high. In fact, no interaction with the user is required. The · efficiency of the implemented code is also high, and situations in which it is useful to modify the generated code to increase display update rates are rarely possible. The approach to code generation used in D3S combines most of the flexibility from executable specifications with the advantages in speed and size of code generation. The first specificationevaluation cycle comprises the process of acquiring a workable initial specification. Once this specification is complete, the implementation can be generated. This rapid prototyping capability reduces the effort required for initial concept evaluation. The second specificationevaluation cycle represents simulator or in-flight evaluation. Since the Specification is loaded at the start of the program, changes to the display format can be implemented in the specification without having to regenerate the software. Thus, code generation has been taken out of the second specification-evaluation cycle, which reduces the turnaround time for simulator and in-flight evaluation. Furthermore, it prevents the user from making changes to the display format at the implementation level, since the information simply is not in the source code.
Maintenance and reuse
A variety of tools can be used for display software maintenance at the specification level. Since the specification is easy to understand, in most cases a text editor suffices. For a modification of the layout, a graphics editor is more appropriate. Since reusability is provided at the specification level, where the functionality is not yet influenced by all kind of implementation specific details, this method also encourages reuse of existing display formats. 4.5
Upgradeability and rehosting
To rehost the display software to the selected target system, code generators for the various target systems have been developed. By designing for hardware independency and separating hardware independent and hardware dependent mechanisms, the effort required for upgrading to newer systems has been minimized, while the ability to optimize for the target hardware remains. In this way, the software lifecycle can be extended beyond the hardware lifecycle.
5. CONCLUSION Due to the desired complexity, incomplete initial specification of the requirements, and the high frequency of changes in these requirements during the operational lifecycle of research oriented systems, software development, integration, and maintenance can pose a serious bottleneck. For efficient integrated system design these problems must be recognized and dealt with. Rapid prototyping systems can be used to speed up 81
Borgida, A, Greenspan, S., Mylopoulos, J. (1985). Knowledge Representation as the Basis for Requirements Specifications. IEEE Computer, Vol. 18, No. 4, pp. 82-90.
the process of acquiring complete specifications. However, there is a need to be able to smoothly proceed beyond the prototyping phase. By providing computer support at all design phases, the transitions between these phases can be computer mediated. In this way it is possible to reduce communication problems and keep all participants in the same loop. By separating hardware dependent and hardware independent mechanisms and using a hardware dependent rulebase for optimization, efficient rehosting is possible, and the software lifecycle can be extended beyond the hardware lifecycle. Experience with the development of display systems for the research flight simulator and the laboratory aircraft indicates that the approach to display software development described in this paper can be used to reduce the software bottleneck to an acceptable level. In environments where functional requirements during the product lifecycle are more stable than in a research environment, the approach described here is equally useful since it allows rapid prototyping and a fast transition from the prototype to a production system.
Cleaveland, J.C. (July 1988). Building Application Generators. IEEE Software, 25-33. Davis, AM., Bersoff, E.H., Corner, E.R. (1988). A Strategy for Comparing Alternative Software Development Life Cycle Models. IEEE Transactions on Software Engineering, Vol. 14, No. 10, pp. 1453-1461. Green, c., Luckham, D., Balzer, R., Cheatham, T., Rich, C. (1986). Report on a knowledge based software assistant. Readings in Artificial Intelligence and Software Engineering (Rich, C. and Waters, R.C., Eds.), pp. 377-428. Morgan Kaufmann, Los Altos. Harel, D. (1992). Biting the Silver Bullet. IEEE Computer, Vol. 25, No.l, pp. 8-20. Kelly, V.E., Nonnenmann, U. (1991). Reducing the Complexity of Formal Specification Acquisition. In: Automating Software Design (Lowry, M.R. and McCartney, R.D., Eds.), pp. 41-64. AAA! Press, Menlo Park.
6. REFERENCES Balzer, R., Cheatham, T.E., Green, C. (1983). Software Technology in the 1990's: Using a New Paradigm. IEEE Computer, Vol. 16, No. 11, pp. 39-45.
Levy, 1..S. (1986). A Metaprogramming Method and Its Economic Justification. IEEE Transactions on Software Engineering, Vol. SE12, No. 2, pp. 272-277.
Barstow, D. (1991). Automatic Programming for Device-Control Software. In: Automating Software Design (Lowry, MR. and McCartney, R.D., Eds.), pp. 123-140. AAA! Press, Menlo Park.
Lowry, M.R. (1991). Software Engineering in the Twenty-First Century. In: Automating Software Design (Lowry, M.R. and McCartney, R.D., Eds.), pp. 627-654. AAA! Press, Menlo Park.
Bentley, J. (1986). Programming Pearls: Literate Programming. Com. of the ACM, Vol. 29, No. 5, pp. 364-369.
Plant, R.T. (1993). Software Development Process Model for Aerospace Systems. Proc. of the 9th AlAA Computing in Aerospace Conference, pp. 883-890.
Boehm, B. W. (1976). Software Engineering. IEEE Trans. on Computers, Vol. C-25, No. 12, pp. 1226-1241.
Rich, C. and Waters, R.C. (1988). Automatic Programming: Myths and Prospects. IEEE Computer, Vol. 21, No. 8, pp. 40-51.
Boehm, B. W. (1988). A Spiral Model of Software Development and Enhancement. IEEE Computer, Vol. 21, No. 5, pp. 61-72.
Theunissen, E. (1993). The DELPHINS Tunnel-inthe-Sky program. Proc. of the Looking-Ahead Symposium, pp. 16.1-16.9. Amsterdam, The Netherlands.
Bordano, A, Lacovara, J.U., DeVall, R., Partin, C., Sugano, J., Doane, K., Compton, J. (1993). Cooperative GN&C Development in a Rapid Prototyping Environment. In: Proc. of the 9th AIAA Computing in Aerospace Conference, pp. 883-890.
Theunissen, E. (1994). The Development of the Delphins Display Design System. Proc. of the International Training and Equipment Conference pp. 583-588, The Hague, The Netherlands.
82