The CAMILA Strategy for Software Reusability

by José Nuno Oliveira

Traditional ``pen and pencil'' development of software misled people to think that program design dispenses with specific development tools. Software ``in the small'' appeared to be an attractive, cheap technology, but lack of technological sophistication ``in the large'' has frustrated such expectations.

A basic problem with software development is the fact that code is hardly re-used, that is, it is difficult to produce a large software system by composition of smaller, readily available, software components. This has an obvious impact on increasing software production costs.

Software reusability is hindered by several reasons, some of which are even non-technical in nature (see an interesting account of ``sociological taboos'' against reusability in Social Aspects of Reusability, by Kruzela I., Telelogic, Sweden, 1989). But relatively recent interest on effectively promoting reusability in CASE technology tends to invert this situation. However, most CASE systems are oriented towards production management (versioning, documentation, team management etc) rather than to the end product. This may be so because their designers couldn't probably understand what a software product ``really is''. So software modules are regarded as mere text-files, their essence never being recorded. For many programmers, software re-use simply means ``do not start from scratch: edit an existing source file''. Software component repositories are built but either record trivial information or remain empty.

The CAMILA group at INESC/University of Minho, which is involved in the SOUR project (EUREKA 379), believe that reusability cannot be achieved by simple ad hoc means, even when addressed from a novel, object-oriented perspective. The basic question - ``what is a software component?'' - has to do with software specification, and can only be properly answered in a formal context. This is because some kind of ``metrics'' will be required to automate the basic operations over a software component repository, namely classification, comparison, retrieval and modification. Thus, CAMILA's strategy for building a software component repository is based on characterizing every software component by its formal specification, understood as a piece of data (internal state) and associated basic operations (events) which are described using set theory. A CAMILA component may thus be regarded as a model as in the VDM methodology, but CAMILA's notation can also express the specification of a component as the functional composition of already available sub-components.

Furthermore, CAMILA's formal notation has been studied with the view to devise a metrics for component classification. Its associated calculus - SETS - can be used not only to classify components (in a ``classify-by-data'' style) but also to calculate component implementations or to compare them (by calculating their ``difference''). Thus, architectural relationships in the repository such as is-a, is-used-by, is-implementation-of, is-special-case-of are formally decided rather than fixed by the users intuition.

In CAMILA, priority has been given to methodology foundations before going into the development of technological support tools. But rapid prototypes can already be built in the CAMILA software environment by running a ``language animator'' which is, itself, an exercise on reusability (the current version of the animator, developed using the Synthesizer Generator, still reuses a ``hidden'' LISP interpreter, augmented with the language primitive constructs and used in the past to interpret manually encoded prototypes).

CAMILA component aggregation can also be expressed by ``software-circuit'' diagrams, using a graphical notation suggestively resembling the conventional hardware notation. But diagrams should never replace formalisms - every ``software-circuit'' has a proper semantics and is just a shorthand for some piece of mathematics.

Other tools under development comprise a SETS-calculator, a performance prospector and an automatic generator of user-interfaces at prototype level.

Please contact: J. Nuno Oliveira, INESC (Braga), +351 53 604462
email: jno@di.uminho.pt