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
