The meeting took place at Nov. 2 and 3, 1998 and was located at University of Zurich. It was organized by Martin Glinz (University of Zurich, Switzerland) and Gerti Kappel (University of Linz, Austria). It had the objective to exchange research results in the area of reuse-oriented requirements engineering in general, and in the area of UML-based reuse-oriented requirements engineering in particular.

Agenda of the meeting:

Gerti Kappel presented their work on using UML for component based development. Subsequently, Glinz presented the scenario-based approach they have been working on in the last couple of months.

Similar to the question posed on objects ten years ago, it has still to be clarified what a component is all about. The least common denominator may define a component being a reusable artifact. Thus, it encapsulates certain functionality and provides a clear notion of interface to use this functionality. One may distinguish two dimensions to classify components, based on the kinds of artifacts, and on the kinds of software development phases, where components are reused. Along the artifacts axis, we may distinguish executable objects, class descriptions, patterns of reusable knowledge, frameworks in the sense of patterns with inversion of control and whole executable programs. Along the phases axis, reusability may occur during all software development phases ranging from requirements specification to implementation. An interesting topic of research remains to look into each combination of the two dimensions and investigate their relevance for component technology in turn. UML supports the notion of components. There, "a component is a reusable part that provides the physical packaging of model elements.'' [UML Seaentic Guide, p.45] Thus, in UML a component is a very low-level, implementation oriented notion. In other words, it is a physical component, which comprises either source code or executable code. However, we feel that this is not enough. To explore the whole potential of reusability, there should be also the notion of a logical component with a clear interface definition supporting both the notion of a provided interface and a required interface. Examples thereof exist in the literature. Subsystems in RDD have contracts, which enclose the provided functionality to the "outside world''. At the same time, RDD also supports the notion of collaborators, which are other object classes necessary to fulfill the functionality of the object class at hand. Thus, collaborators and their provided operations make up the required interface of the respective object class. Another question concerns the packaging of functionality within components. Components may be fine-grained encapsulating some small functionality, e.g., a sort algorithm, or they are coarse-grained encapsulating whole applications. Concerning up-to-date application development including distribution and database functionality, we also regard components as a possible mechanism to encapsulate various levels of implementation details and to provide an easy-to-use interface to connect to some database and to use some underlying distribution mechanism, respectively. We feel that the component notation provided by UML is by far not sufficient. It seems, however, that the software development community has not yet agreed upon a uniform notion of component based development. Thus, defining a standard notation might be premature at this point of time.