The Engineering of Software in TORUS
by Brian Matthews and David Johnston
The biggest problem facing software engineering is the necessity to interface with real-world computing environ-ments and legacy software.
Specification techniques, design notations, development methodologies, and modern programming paradigms all assist the expedient production of quality software. Yet all such sophistication is powerless to deal with the 'real world' of computing where interfaces are shambolic and not formally specified; where documentation is ambiguous, bad, wrong or even absent and where languages are archaic.
TORUS
The Esprit project TORUS faced exactly this challeng. This article will focus on a particular software deliverable called ToDES to illustrate how the "real world" problems were surmounted.
The partners involved were Cegelec Projects Ltd (UK), who develop and sell large-scale automation systems into the semi-continuous metal products, marine and utilities markets throughout the world; FLS Automation (DK) who supply complete automation and control systems for the cement and other process industries; Alcatel ISR (F) who provide the software development technology; and RAL (UK), who are providing expertise in generic information, document and process models, especially in STEP and SGML.
TORUS's three year mission was to raise level of reuse in industrial process control projects. It had a successful final review on the 10th of October this year.
ToDES
ToDES (TORUS Document Exchange System) provides a method of generating reusable documentation for engineering projects. The basic idea behind ToDES is to design a generic template document written in SGML (a standard document mark-up language) in such a way that it can be parameterised by engineering data in EXPRESS (a standard data design language). Each engineering project will be based on different data, but the documentation for each is automatically produced because the template is parametrised by this project-specific information.
There are three connections to the real word here - SGML, EXPRESS and the database. To illustrate the viability of ToDES, a commercial database was chosen (in this case MicroSoft Access) using pre-existing product data files as exemplar parameters.
The prototype document instantiator was a self-contained program written in a functional language called ML. The use of a functional language simplifies many tasks such as the parsing of EXPRESS and SGML. The subsequent version of ToDES used a robust public domain EXPRESS parser (written in 'C') and an ODBC database interface via a 'C' binding.
The key to real world interfacing is a good architecture, where external interfaces are placed in wrapper modules and where intra-project interfaces are both well-defined and orthogonal.
Web and Architecture
A further enhancement of ToDES has been a Web interface, which allows the instantiation and display of engineering documents via the Web. HTML the document format of Web pages, is a particular instance of SGML. Given the take-up of the Web over the last three years, the choice of SGML was fortuitously prescient.
The Web enhancement has required additional real world interfacing and the full architectural diagram (see figure) illustrates the overall approach. ToDES has two roots: the underlying database and the project integrated public domain EXPRESS utilities from the American National Institute of Science and Technology (NIST). The trunk is the Web interface, by which means access to the tool is provided.
Every proprietary interface is protected by at least one if not more wrapper modules. Clear interfaces that emerge may be designated as project external. These become documented in the project deliverables, and are of potential use outside the project.
Conclusion
ToDES has been pioneering in embedding a system based on a functional language, in a real computing environment. Although the final structure resembles a 'Tower of Babel' with many component languages including Java, C, ML, SQL, CGI, HTML and Express, it is the strong under-lying architecture that has prevented the tower from collapsing.
There is no denying that the integration between different languages, and development across diverse machines and operating systems has been difficult. However, by initially building a 'long thin slice' prototype of admittedly limited functionality but which tested the architectural interconnections a clear and useful distinction between 'system problems' and 'design issues' was maintained.
More information on TORUS at http://www.dci.clrc.ac.uk/Activity.asp?TORUS
Please contact:
Brian Matthews and David Johnston - CLRC
Tel: +44 1235 446738
E-mail: B.M.Matthews@rl.ac.uk, D.Johnston@rl.ac.uk
