Our approach

Apart from the well-known motivations for reusing software, productivity and quality, another one also plays a role. The average employee works in a research job for about five years and then moves on to another, most likely non-research, job. This implies that there is a high staff turnover. It is believed that the results of the domain analysis could be very useful in bringing new employees up to date with the activities of a department.

We have elected to study the construction of a repository for a department in the Laboratory rather than one for the whole Laboratory. The areas in which research is performed are quite diverse. To develop a single repository for the whole Laboratory was therefore, in our opinion, unrealistic. We do expect, however, that repositories for different departments will overlap, and we hope to devise mechanisms that will enable possible reusers to look over the boundaries of the repositories without becoming lost in the sheer quantity of components.

The repository will not only contain source code but designs and code templates as well. We also intend to provide links to the software that was used to test the various components. The 3Cs model (see [3]) will be used to define the structure of a reusable component.

A case study was started one of whose goals was to construct a repository for a department. It was decided to start this case study with a domain analysis. A priori it was decided that the ``deliverables''of the domain analysis consists of the following three items:

1. a glossary of terms
   In this glossary the concepts and objects of the domain will be defined and their interrelationships recorded. It is expected that many terms in the glossary will have a counterpart in software. It is particularly important to have a clear view of the interrelationships between the terms, because these interrelationships indicate the likely interactions between the software counterparts. As such they (partially) determine the interface of the software components. The glossary also provides important information for the classification of the components.

   For reasons explained above, we will use natural language to document the components. To avoid some of the ambiguities that arise in natural language documentation, the author of the documentation is allowed to use only the technical terms that are listed in the glossary with the same meaning. So the glossary will become a constant ``terms of reference'' or context for the reader of the documentation. This will facilitate the ease of understanding.

2. a list of characteristic problems
   We hope to find components in the large amount of available software or, to be precise, we hope to adapt pieces of existing software such that they become components. The list of characteristic problems is a first step in gaining a grip on the available software and forms a first classification mechanism for it.
3. one or more solution strategies for every characteristic problem
   An example of a characteristic problem is a phase equilibrium computation. In such a computation there is a mixture of chemical substances, a pressure and a temperature. A phase equilibrium computation entails the computation of the number of phases and their compositions. Such a problem can be solved in many different ways: using different models, different numerical methods, etc. The purpose of this ``deliverable'' is to have a relatively abstract description of each solution. The solution strategies will enable us to further classify the existing software and enable us to abstract away from any specific details of one implementation. This should help us to construct truly reusable components.

Although the domain was not large, already early in the domain analysis phase it was observed that it would require a substantial effort. That the Laboratory is not a software production environment and the researchers not professional software developers hindered the analysis substantially. Since a full domain analysis would take probably too long, we are considering to follow the approach as given in [5].

Notwithstanding the above observation, the domain knowledge representation is much more an open problem than the domain analysis. We are still actively looking for a good ``tool.'' Due to the technical environment a great deal of technical notation exists. We need to have a way to be able to capture such notation, since it would facilitate the understanding of components a great deal. Therefore, we consider a hypertext-like environment in which it is possible to define cards using TEX a viable option. Furthermore, this hypertext-like environment should provide support for layered semantic networks. Such networks will be used to record the ``deliverables'' of the domain analysis.