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


Roles in Component-based Development

Figure 2.1: Concept of Roles.
Image process-model-roles

Before introducing the individual roles of the component-based development process, we describe the general concept of roles in software development. Figure 2.1 illustrates the relation of persons, roles, and tasks. A role groups a set of tasks that have an overall purpose and each task is associated to exactly one role. For example, the role component developer performs tasks like component implementation and component specification. A role can be adopted by multiple persons, e.g. there can be multiple persons who are component developers involved in the process. On the other hand, it is also possible for a person to adopt multiple roles. For instance, some component developers might also play the role of software architects, who are responsible for designing the software architecture. The relation of persons and roles is an important concept and has to be considered when reading the following descriptions of roles.

Figure 2.2: Developer Roles in the Palladio Process Model
Image process-model-roles2

Since we want to evaluate QoS attributes during early development stages, we need additional information about the internal component structure, the usage model, and the execution environment. This information cannot be provided by a single person (e.g., the software architect) involved in the development process, since the required knowledge is spread among different persons with different development roles. Therefore, a QoS analyst requires support of component developers, software architects, domain experts, and deployers to analyse the QoS attributes of a software architecture (cf. Fig. 2.2).

Figure 2.3: Influences on the QoS properties of a Software Component
Image process-model-influences

Component developers are responsible for the specification and implementation of components. They develop components for a market as well as per request. To enable QoS analyses, they need to specify the QoS properties of their components without knowing a) to which other components they are connected, b) on which hardware/software platform they are executed, and c) which parameters are used when calling their services (cf. Figure 2.3). Only such a specification enables independent third party analyses. In the PCM, component developers use service effect specifcations (SEFF, cf. Section 3.2.9) to characterise the QoS properties of their components.

Software architects lead the development process for a complete component-based application. They design the software architecture and delegate tasks to other involved roles. For the design, the planned application specification is decomposed into component specifications. Existing component specification can be selected from repositories to plan including existing components into the application. If no existing specification matches the requirements for a planned component, a new component has to be specified abstractly. The software architect can delegate this task to component developers. Additionally, the software architect specifies component connections thereby creating an assembly model (cf. Section 3.3.2). After design, software architects are responsible for provisioning components (involving make-or-buy decisions), assembling component implementations, and directing the tests of the complete application.

Deployers specify the resources, on which the planned application shall be deployed. Resources can be hardware resources, such as CPUs, storage devices, network connections etc., as well as software resources, such as thread pools, semaphores or database connection. The result of this task is a so-called resource environment specification (cf. Section 3.4.4). With this information, the platform independent resource demands from the component specifications can be converted into timing values, which are needed for QoS analyes. For example, a component developer may have specified that a certain action of a component service takes 1000 CPU cycles. From the resource environment specification of the deployer it would now be known how many cycles the corresponding CPU could execute per second. Besides resource specification, deployers allocate components to resources. In the PCM, this step can also be done during design by creating a so-called allocation model (cf. Section 3.4.5). Later in the development process, during the deployment stage, deployers can be responsible for the installation, configuration, and start up of the application.

Domain experts participate in requirement analysis, since they have special knowledge of the business domain. They are familiar with the users' work habits and are therefore responsible for analysing and describing the user behaviour. This includes specifying workloads with user arrival rates or user populations and think times. In some cases, these values are already part of the requirement documents. If method parameter values have an influence on the QoS of the system, the domain experts may characterise these values. The outcome of the domain experts' specification task is a so-called usage model (cf. Section 3.5.2).

QoS analysts collect and integrate information from the other roles, extract QoS information from the requirements (e.g., maximal response times for use cases), and perform QoS analyses by using mathematical models or simulation. Furthermore, QoS analysts estimate missing values that are not provided by the other roles. For example, in case of an incomplete component specification, the resource demand of this component has to be estimated. Finally, they assist the software architects to interpret the results of the QoS analyses.


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