Introduction: Componentware Methodology

An analogy to the building industry illustrates a successful application of such a component-oriented approach: First, the building owner provides the architect with the functional and non-functional requirements in a more or less informal way. Examples are the number and function of rooms and the money he wants to spend. The architect then constructs a first, overall ground plan and several side views or even a computer-generated virtual model of the building. If these proposals meet the owner's expectations, the architect will elaborate a more detailed and technical construction plan. It describes the different components of the building, like walls and windows, and how they fit together. Now the architect invites tenders for these components and evaluates their offers. At last, the ``best'' component producers get the job, place the components to the architect's disposal, and integrate them into the building. During the whole process, the architect's construction plan is the basis of communication between all parties working on the building.

Although there already exist a variety of technical concepts and tools for component-oriented software engineering, the successful model from the building industry was not completely transferred to software development yet. In our opinion, this is partly due to the lack of a suitable componentware methodology. Such a methodology should at least incorporate the following parts:

• A well-defined conceptual framework of componentware is required as a reliable foundation. It consists of a mathematical formal system model which is used to unambiguously express the basic definitions and concepts. The contained definitions and concepts should be as simple as possible, yet sufficiently powerful to capture the essential concepts and development techniques of existing technical component approaches.
• Based on the formal system model, description techniques for components are required. They correspond to the building plans of architecture and are necessary for communication with the customer and between the developers. Examples for description techniques are graphical notations like class diagrams and state transition graphs from modeling languages like UML as well as textual notations like interface specifications expressed in CORBA IDL, C++, or Java. Well-defined consistency criteria between the different description techniques allow to verify the correctness of different views onto a system with the help of specialized tools.
• Development should be organized according to a process model tailored to componentware. This includes in particular the assignment of discernible development tasks to individuals or groups in different roles, for example, a software architect responsible for the overall design of a system, and component developers who produce and sell reusable components.
• The description techniques and the componentware process model should be supported by tools . At least, these tools should be able to generate an implementation of the system as well as corresponding documentation. Furthermore, they could facilitate the verification of critical system properties, based on the formal system model.

A more extensive discussion about these fundamental parts of a componentware methodology can be found in [BRSV98b]. In the following sections we focus on the process model for componentware in detail. Such a process model supports system development by clearly defining individual development tasks, roles and results as well as the relationships between them. We first cover the essential aspects that distinguish a component-oriented process model from more traditional approaches. Subsequently, we introduce new development roles associated with componentware and propose a suitable process model for component users and developers. Then we discuss some specific component developer issues. A short conclusion ends the paper, referring to the strawman outline of CBSE'99 [CBS99].