next up previous contents index
Next: QoS Analysis Workflow Up: Component-based Development Process Previous: Deployment   Contents   Index


Specification Workflow

The specification workflow (see Figure 2.5, right column) is carried out by the software architect. The workflows of the software architect and the component developers influence each other. Existing components (e.g., from a repository) may have an impact on the inner component identification and component specification workflow, as the software architect can reuse existing interfaces and specifications. Vice versa, newly specified components by the software architect serve as input for the component requirements analysis of component developers, who design and implement new components.

Figure 2.5: Specification Workflow
Image process-model2

The component developer's workflow is only sketched here, since it is performed separately from the software architect's workflows. If a new component needs to be implemented, the workflow of the component developer (see Figure 2.5) can be assumed to be part of the provisioning workflow according to Cheesman and Daniels [5].

Any development process model can be used to construct new components as long as functional and extra-functional properties are specified properly. First, a component requirement analysis has to be conducted. It is succeeded by functional property specification and then extra-functional property specification. The functional properties consist of interface specifications (i.e., signatures, pre/postconditions, protocols), descriptions of internal dependencies between provided and required interfaces. We use service effect specifications (Section 3.2.9) to describe such dependencies. Additionally, descriptions of the functionality of component services have to be made. Extra-functional, QoS-relevant information includes resource demands, reliability values, data flow, and transition probabilities for service effect specifications. Finally, after component implementation according to the specifications, component developers have to put the binary implementations and the specifications into repositories, where they can be retrieved and assessed by software architects.

The specification workflow of the software architect consists of four inner workflows. The first two workflows (component identification and component interaction) are adapted from [5] except that we explicitly model the influence on these workflows by existing components. For component identification, so-called ProvidedComponentTypes can be used in the PCM (see Section 3.2.5.2). Component interaction can be described in the PCM once the provided component types have evolved to ImplementationComponentTypes (see Section 3.2.5.2). During the component specification, the software architect additionally gets existing interface and service effect specifications as input. Both are transferred to the new workflow interoperability check. In this workflow, interoperability problems are solved and the architecture is optimised. For example, functional parametrised contracts [7], which are modelled as service effect specifications, can be computed (see Section 2.4). The outputs of the specification workflow are an optimised architecture and component specifications with refined interfaces.


next up previous contents index
Next: QoS Analysis Workflow Up: Component-based Development Process Previous: Deployment   Contents   Index
Snowball 2007-03-16