next up previous contents index
Next: Roles in Component-based Development Up: Component-based Development Process Previous: Component-based Development Process   Contents   Index

Motivation

Component-based software development follows a different process than classical procedural or object-oriented development []. The task of developing software artefacts is split between the role of the component developer, who develops individual components, and the software architect, who assembles those components to form an application. Further roles are involved in specifying requirements and defining the resource environment.

For using the PCM, a specific development process with specific developer roles is envisioned, which builds on an existing component-based development process introduced by Cheeseman and Daniels [5], which was in turn based on the Rational Unified Process (RUP).

Early QoS analysis of a component-based architectures depends on information about its usage profile and resource environment. This information might not be available directly from software architects or component developers. Thus, further developer roles, such as deployers, domain experts and QoS analysts are needed for the specification and QoS analysis of a component-based architectures. These developer roles and their tasks are described in Section 2.1.2. For the PCM, a domain specific modeling language has been created for each of these roles. These modeling languages will be described in detail in Chapter 3.

The PCM process model extends the process model by Cheeseman and Daniels (Section 2.1.3). Section 2.1.4 elaborates on the specification workflow and illustrates the interdependencies between component developer and software architect. The PCM process model additionally contains a workflow ''QoS-Analysis'' (Section 2.1.5), in which all of the developer roles interact to predict the performance or reliability of the architecture.

The development process introduced in the following is generic, so that it could be followed by other model-based QoS prediction approaches for component systems [6] as well. It is furthermore not restricted to a specific QoS property like performance, but can also be used for reliability, availability, security, safety, etc. The process model reflects our vision software development including early QoS analyses. Its applicability in practice remains to be validated. Some discussion points about the process model as well as related work are summed up in Section 2.1.6.


next up previous contents index
Next: Roles in Component-based Development Up: Component-based Development Process Previous: Component-based Development Process   Contents   Index
Snowball 2007-03-16