CADES

CADES was conceived in 1970 by David Pearson and Brian Warboys when working for ICL's New Range Operating System Technology Centre, OSTECH, in Kidsgrove.[1][2] Pearson, a theoretical physicist by training, had become a computer simulation specialist and joined ICL in 1968 after working in finite-element modelling at Cambridge and simulation research at Imperial College. Warboys had been chief architect for the ICL System 4 multi-access operating system, Multijob.

ICL's commitment to large scale software development for the 2900 Series of computers provided the basis for the Pearson and Warboys early work on a new software development environment which would address the issues of designer/programmer productivity, design integrity, evaluation and testing, version control and systems regression.[3][4]

In designing the initial architecture of the CADES environment, Pearson in particular looked to parallels with the leading hardware computer-aided design systems of the time, even attempting the use of graphics in the design process. The CADES design approach, called Structural Modelling, was rigidly data-driven and hierarchical, and expressed in a formal design language, SDL. Design specifications written in SDL were processed by the Design Analyser, before being input to the CADES Product Database, a design and implementation database supporting its own query language and forming the kernel of the Product Information System.[5][6][7]

The intention was that these designs could be evaluated/simulated using the Animator, and S3 implementation code automatically generated from them using the Environment Processor. Build generation and version control was also based on the Product Database, resulting in a highly disciplined approach to new system builds. System Regression was therefore controlled from a very early stage in the software life-cycle.[8][9]

In order to control the development of VME/B, each development was sub-divided for easier management. The structure was hierarchic, with each significant components of VME (kernel, file store, etc.)divided into sub-systems. Development activity on each sub-system created a sequence of versions.

These divisions and sub-divisions of VME/B were reflected in the hierarchical structure of the CADES database. This enabled the reuse of code within VME/B (one of the goals of software engineering). This, coupled with a suite of tools, and the use of SDL (Software Design Language) as the development language, version history and the concept of trusted source code (that is code that has passed QA and subsequently resides within CADES filestore) improved development time whilst providing satisfactory audit trails and QA processes.

CADES adopted the term "holon" to refer to modules of code (such as procedures and macros). The word came from the Greek holo meaning whole, and was lifted from Arthur Koestler's book The Ghost in the Machine. Pearson always claimed that he formulated the architecture of CADES while studying Koestler's book on a beach in Tunisia. Arranged in a hierarchy, holons provide a 'family tree' (for each sub-system), utilising parent/child relationships. Holons also maintained attributes of interaction, enabling one Holon to interact with other Holons, thus enabling more modular development and facilitating reuse. In a similar fashion CADES also retained information with regard to constant values (aka literals), user-defined types and user-defined structures.

Development under CADES was achieved using a suite of tools known as MODPRO (Module Processing) which acted as an interface (or broker) between developer and CADES. These tools enabled the developer to focus more on development that administrative, QA or SCM tasks. It was not necessary to know how to manipulate data within CADES, the application generated the required DNL (Data Navigation Language) to achieve the required results.

Development using MODPRO did not require specific knowledge of either S3 nor SCL (target language for subsequent compilation), but SDL, the Software Design Language: an abstraction above the former two. Which when coupled with the enhance-editor EDSDL (Edit SDL) interacted with CADES to manage development, or re-work. Then, again with information from CADES, when used with MODPRO tool EPETC (aka Environmental Processor or EP etc.) enabled the resultant file to be correctly targeted for S3 or SCL compilation. Subsequent tools within the suite facilitated various steps within development, such as:

• Detailed Holon information using CHED (CADES Holon Environment Details),
• Interaction with CADES using DIL (Database Interface Language, used to produce DNL),
• Report production, using CRP (CADES Report Producer),
• Transfer valid files/code in to or extract out of the secure repository, namely CADES, using XFER.

The following illustrates the typical MODPRO development route.

VME/B development using MODPRO tools

• B.C. Warboys (25 January 1988). "Extrapolation of lessons from CADES to the present day". IEE Colloquium on Industrial Impact of Software Engineering: 3.
• R. W. McGuffin; A.E. Elliston; B.R. Tranter; P.N. Westmacott (September 1979). "CADES - software engineering in practice". IEEE Proceedings 4th International Conference on Software Engineering, Munich, Germany: 136–144.
• B. Kitchenham (May 1982). "System Evolution Dynamics of VME/B". ICL Technical Journal: 42–57.
• B. W. Chatters; M. M. Lehman; J. F. Ramil; P. Wernick (2000). "Modelling a software evolution process: a long-term case study". Software Process: Improvement and Practice. 5 (2–3): 91–102. doi:10.1002/1099-1670(200006/09)5:2/3<91::AID-SPIP123>3.0.CO;2-L. Archived from the original on 5 January 2013.
• R.A Snowden (May 1990). "An Introduction To The IPSE 2.5 Project". ICL Technical Journal. 6 (3).
• B.C. Warboys, P.Veasey (May 1990). "Twenty Years With Support Environments". ICL Technical Journal. 6 (3).