Logical Construction of Systems
Logical Construction of Systems
Systems Analysis for Applications Software Design
Systems Analysis for Applications Software Design
Structured Systems Analysis: Tools and Techniques
Structured Systems Analysis: Tools and Techniques
| Hi-index | 0.00 |
Problems involving Ada tasking can be difficult to specify because there are few existing methods for visualizing them. Currently, software engineers must specify tasking problems by hand using informal data flow diagrams [4] or Booch diagrams [1]. Several attempts have been made at providing a workstation environment for the specification of programs: notable examples are the TAGS (Technology for the Automated Generation of Systems) environment with IORL ® (Input/Output Requirements Language) [5], and the AdaGRAPH™ environment with PAMELA™ (Process Abstraction Method for Embedded Large Applications)[3].These methods are useful for the specification of tasking problems, but they do have some drawbacks. While data flow diagrams, Warnier-Orr diagrams, and Booch diagrams have been commonly used for specification, they are not directly executable, and must be rewritten as source code by a programmer. Design errors may creep in all too easily during the translation. The automated tools also have their problems. IORL provides a good model for decomposing a system into concurrent processes, but it utilizes an unstructured, flowchart-like tool for the specification of process logic. A system is represented in IORL using a simple symbology of boxes and arrows that is not as refined as those of Yourdon or Gane and Sarson. PAMELA is based on data flow diagram techniques, but uses additional symbols that may not be intuitive to those unfamiliar with the language. And, although PAMELA allows the overall structure of a system to be developed graphically, the logic associated with each procedural component must be developed as text: graphical representations of procedural logic are not supported.A graphical specification language (GRASP: GRaphical Approach to the Specification of Programs) for tasking problems is proposed to overcome these problems. The current version of the language utilizes two presently existing software engineering tools, the data flow diagram [4] and the Warnier-Orr diagram [2,7], with some modifications. (Early in the research effort, it was determined that the data flow depicted in standard data flow diagrams was not sufficient for the specification of tasking programs, so this data flow was elaborated.) A GRASP specification is first developed using GRASP/G, a graphical language that incorporates data flow diagrams and Warnier-Orr diagrams. This specification may be automatically mapped into GRASP/T, a textual variant of GRASP/G that serves as an intermediate language. A GRASP translator can then map this GRASP/T specification into Ada source code. The two-tiered approach allows the graphics-intensive GRASP/G tools to be isolated for development on various machines, while leaving the GRASP/T tools in an easily portable state.At present, a prototype of the GRASP language [6] is being tested with GRASP graphics and translation tools written in Pascal for the Apple Macintosh™ computer. The prototype has been used to specify small problems such as the Dining Philosophers. While the prototype does not yet address the needs of complex I/O or elements unique to Ada (generic Instantiation, private units), it does handle the decomposition of a system into concurrent processes well, and “hooks” have been provided in the language for further work.