The following sections list requirements for component-based architecture design and prediction resulting from the introduced foundations. Section 2.4.1 gives an overview on them classified by the involved research areas (cf. figure2.1 in the motivation to this chapter). Section 2.4.2 uses the literature surveys presented at the end of each related
research area section as basis to judge the state-of-the-art. Based on this and the require- ments presented in section2.4.1, section2.4.2presents the resulting deficiencies targeted in this thesis.
2.4.1
Requirements for Model-Driven, CBSE Predictability
Each introduced area of research offers advantages for a software development process. Hence, combining these areas is desirable. In detail, three main requirements result from supporting each of the areas involved:
• Firstly, a CBSE development process should be supported. The CBSE method offers advantages due to better component specifications and shared workload among the developer roles.
• Secondly, the envisioned software development process in this thesis should be based on the inclusion of models and model-transformations in order to benefit from the advantages of MDSD (cf. section 2.2). Especially, it is an aim to use the close relationship between a model and the code generated from it to increase per- formance prediction accuracy.
• Thirdly, model-driven performance predictions of the specified architectures should be supported to enable architectures whose design decisions are based on predicted quality attributes. The following paragraphs investigate each requirement in more detail.
In detail, from the CBSE requirement result the following sub-requirements:
1. Support for the CBSE development roles (cf. section2.1.2) requires distributed mod- elling activities: Each role has specify those parts of a complete system model it possesses information about. This effectively splits the complete system model into sub-models specific to each of the roles.
2. Support for a Parameterised Component Model: A model of a software component has to be parameterised by the identified influence factors (see section2.3.1). Such parameterisations allow using the same model of a component in different reuse scenarios. It is part of the responsibilities of the component developer to specify his components in such a parameterised way. By specifying their sub-models, other roles finally fix the parameters resulting in a complete model. However, when de- signing each role’s DSL, it is important to keep the models as small as possible, i.e., information derivable from other information is determined automatically.
3. Gray-Box Components: The black-box component principle should be preserved for reasons of information hiding and encapsulation (cf. section 2.1). However, performance prediction requires at least abstract models of internal component ac- tivities to estimate their resource demands. Hence, a refined black-box view on components is favoured: tools gain access to the internals of components, but the developer still only gets the information on component interfaces. In practice, this is the way components are distributed today if the bytecode is taken as the speci- fication of the internal behaviour of the component. The bytecode is only accessed by tools like virtual machines and not by the developer.
4. Third Party Deployment: In order to support the CBSE development process as pre- sented in section 2.1, not only component models but also component implemen- tations must support varying external influence factors after the implementation phase. However, existing target middleware platforms still have limited build-in support for a strict distinction of the CBSE roles. As a consequence it is required to overcome such limitations by appropriate measures encoded in transformations. Often, existing design or architectural patterns solve these problems. Whenever they exist, they should be applied.
Model-driven software development aims at increasing the effectiveness of software de- velopment activities by automating the transitions from more abstract models of the sys- tem to more concrete ones. Hence, the requirements aim at saving time and money to effectively automate as much as possible of this process:
1. Meta-Model Foundation: In order to use standard transformation engines, a meta- model is needed based on a standard meta-meta-model. The required meta-model should have a clearly defined syntax and its semantics should be as precise as pos- sible. Model elements should be accessible by standard compliant transformation engines. A counter-example to this is the tagged-value annotations used in SPT as they need upfront parsing. Instead of such strings, all relevant information should be accessible via meta-model classes.
2. Meta-Model Applicability: When designing a meta-model all parts of it (abstract and concrete syntax, static and dynamic semantics) deserve attention. Especially the concrete syntax is crucial for the applicability of the meta-model. Without a well-designed concrete syntax, the meta-model is not applicable. Case studies or experiments with common software developers offer a measure to evaluate whether the meta-model is suited.
3. Transformations Bridge Abstraction Levels: In MDSD automated transformations are used to bridge the gap between an abstract model and more concrete models or code. The transformations should execute automatically and may be parameterised by mark models to reflect mapping alternatives.
4. Standard Compliance: As much of the technology as possible should be founded on standards or de-facto standards. The resulting ability to reuse standard compliance tools leads to a higher efficiency compared to self-developed tools and transforma- tions. One reason for this is that it allows to use powerful transformation engines which allow complex operations. Such operations, like matching complex object structures, need sophisticated knowledge and hence, are hard and error-prone to implement. Additionally, it eases the exchange of tools and models which enables to use specific tools for specific tasks.
Detailed requirements resulting from the main requirement to have performance pre- dictions included in the envisioned software development process are:
1. Integrated Validation: As in other engineering disciplines, the software develop- ment process favoured in this thesis should support model validation and refine- ment steps after initial evaluations. They base on measurements performed with prototypes and (parts of) the final system.
2. Prediction Result Expressiveness: Performance predictions should result in enough information to make the right design decisions. Sometimes mean response times or average queue load is sufficient for this. But in many scenarios it is not as trade-offs are involved. For example, speeding up one class of requests might slow down an- other making it hard to state which alternative offers the better performance. In or- der to deal with the problem, this thesis favours distribution functions of stochastic results over characteristic values like mean or standard deviation. The predictions have to deal with that.
3. Annotation Inputs: It can be hard to adjust performance annotations like arrival rate estimates to predefined distribution types. This is even more true in a dis- tributed development environment where the final prediction model input is calcu- lated from several specifications done by different developer roles. Hence, support for arbitrary distribution functions for stochastic input values is needed.
Requirements which result from the combination of CBSE and MDSD are:
1. Support For Distributed Model Transformations: Model transformations can only take place when the model information needed for a specific transformation is com-
plete. Some transformations have to be executable by roles independent from oth- ers. For example, a transformation deriving code skeletons for component imple- mentations from component models has to be executable by the component de- veloper independent from other development roles. Additionally, transformations which derive prediction models have to produce partial prediction models which are combined in a finalising step.
Requirements which result from the combination of the model-driven approach and performance prediction are:
1. Model-Driven Predictions: Performance predictions have to be based on models. Models offer a cost effective way of doing early analyses and what-if scenario eval- uations.
2. (Semi-)Automatic Prediction Model Generation: In a model-driven context, model transformations translate design models into prediction models. To guide the trans- formation, developers can add manual additions like performance annotations or completion specifications to the transformation as parameter.
3. Exploit the Generative Nature of the Implementation Generation: Code is gener- ated by transformations guided by input models. However, transformations add additional information to intermediate models or final code fragments. This can be done either fully automated or semi-automated guided by parameters specified by the user as mark model.
2.4.2
Resulting Deficiencies
Judging existing approaches for each of the three foundation areas against the require- ments given in section2.4.1results in a list of deficiencies in existing approaches.
Component Models Component models offer support for the CBSE processes and com-
positional reasoning. The industrial component models even offer support for imple- menting components on middleware implementations. However, they still have limited (if any) support for advanced concepts like composed components or explicit required interfaces and do not support performance analyses.
Fractal offers advanced component concepts like composed components and run-time reconfiguration which is also supported in Fractal platform implementations. However, it misses quality evaluation methods.
Documentation-oriented models like the component model of UML2 suffer from im- precision and ambiguities. Additionally, support for performance annotations is only
available as meta-model extension via profiles. However, due to its MOF based meta- model, UML2 itself has a well-defined abstract syntax which would allow model transfor- mations using standard transformation engines. However, many UML tools still do not support exporting standard compliant XMI files which decreases tool interoperability.
Architecture Description Languages have been designed with the aim of analysing software architectures. However, from the surveyed literature only few ADLs support quality annotations and analyses namely MetaH, Rapide, and UniCon (cf. section2.1.4). Their focus is on real-time and schedulability analysis, which is unsuited for early de- sign phase performance evaluation. Additionally, they have not been designed for stan- dardised model transformations as their meta-model is commonly not expressed using a standard meta-meta-model.
SOFA possesses an explicit meta-model and also supports advanced component con- cepts like composed components. However, analyses focus on protocol and implementa- tion conformance checks via model-checking. Performance analysis is not supported.
Embedded component models offer some support for early quality analysis. Espe- cially the RoboCop component model is related to the component model used in this thesis as it supports the partitioning of models to describe components and thus could also be used in a software development process with several involved developer roles. The extensions introduced by Bondarev et al. (2005) allow the specification of resource consumptions, behavioural specifications and constant input parameter dependencies. However, given the focus on embedded systems many models used in their work only support a limited scope adding several strong assumptions on the system to be modelled. For example, it is assumed that the time needed to process a job can be derived exactly, which might be valid for an embedded controller but which is not valid for a business information system running on several software layers without real-time guarantees.
CBSE Performance Prediction Methods The CBSE prediction methods survey in sec-
tion 2.3.6 all aim at supporting performance prediction for component-based software
systems. However, as the original survey by Becker et al. (2006b) showed, only few of them support all of the CBSE developer roles involved.
The most comprehensive support has ROBOCOP. It supports all developer roles in- cluding the impact of different input parameter usages in the usage context. However, it targets at embedded systems and thus, can make several simplifying assumptions like exactly available hardware demands or constant input parameters only. Based on these assumptions, ROBOCOP supports worst-case and schedulability analyses important in the embedded domain. In this thesis, focus is on probabilistic, average case analyses more important for business information systems which do not need hard deadlines.
Additionally, non of the CBSE prediction methods supports model-driven code gener- ation from their model instances. However, the close relationship of generated code and its performance at run-time is in the focus of the Coupled Transformations method pre- sented in section4.1. To demonstrate this, this thesis presents a Java EE mapping of PCM instances in section4.6and elaborates on the resulting performance impact.
Model-Driven Performance Prediction In order to do model-driven component-based
performance predictions a meta-model is needed to specify the component-based ar- chitecture and the performance of single components. In the meta-models surveyed
by Cortellessa (2005), i.e., UML1.x with SPT annotations, the SPEED meta-model, and
CSM, many concepts needed for performance predictions like modelling the control flow, the workload, the hardware environment, or performance annotations exist. However,
as Cortellessa (2005) concludes, non of them has explicit support for component-based
software development.
The SAP approach by Di Marco and Inveradi (2004) explicitly bases it performance predictions on component-based development. It already includes compositional reason- ing on the performance of component-based architectures by combining single character- istics of single component into a system’s prediction model. The used transformation can also handle different kinds of workloads by mapping them on different routes in the used queuing network. However, it also has some drawbacks. First, it misses support for a parameterised component deployment as each component has to specify its resource demand in hardware-dependent times. Second, due to its foundation in the UML, it in- herits the issues with UML’s imprecise component model (see section2.1.4). Third, it is unclear how the authors apply the SPT profile which is designed for UML1.x to UML2 model in which the semantics of the profiling mechanism changed significantly. How- ever, they have to rely on UML2 as they use its improved component and collaboration models.
Petriu and Wang (2000) transform SPT annotated UML1.x models into LQNs. How-
ever, it is not targeting component-based developments due to its focus on UML collabo- rations. Additionally, the same issues with the UML meta-model apply as discussed for SAP.
KLAPER from Grassi et al.(2005) also claims to support component-based software systems. However, KLAPER is not aligned with the CBSE developer roles and uses a very broad component term which includes software- and hardware components. Its aim is to provide an intermediate model for transformations into performance predictions mod- els. For this, it is based on EMOF instead of using the UML. However, the few available analysis transformations also make strong assumptions on the KLAPER instance like ex-
ponential distributed workloads so that KLAPER is disregarded in this thesis.
This thesis does not use the UML as input model to avoid several issues (Becker et al.,
2008b). The most important are the missing support for creating partial models (to sup-
port the CBSE roles), the unavailability of performance annotation profiles for UML2 (UML2 is needed because of the enhanced component model over UML1.x), the com- plexity of the meta-model which would require introducing many restrictions to reflect the component concept favoured in this thesis (like disallowing inheritance for compo- nents), and the issues with tool interoperability with the XMI produced by different UML modelling tools (cf. the paragraph on UML in section2.1.4). Instead, this thesis defines a EMOF based meta-model which has explicit support for CBSE developer roles (see sec- tion 3.1) and the required parameterisation by the different influence factors on perfor- mance (cf. section2.3.1). Using an EMOF based meta-model also eases to use of standard model transformation engines.
Platform Completions The introduced platform completions (see section2.3.8) all aim
at integrating platform specific details into performance prediction models. The methods
by Verdickt et al. (2005) and Grassi et al. (2006) successfully include details on compo-
nent connectors into the prediction models. However, they do so in an all-or-nothing approach, i.e., they replace all connectors with the same details. They do not use informa- tion on the transformation of the design model into its realisation which allows a more flexible control which completions to add in which cases (cf. section4.1).
The approach by Wu and Woodside (2004) envisions the use of completion compo- nents to model platform aspects like different software layers (middleware, databases, filesystems, etc.) or networking. The authors plan to use a library of completion com- ponent to include them into the prediction model based on a set of rules not explained further. While the central idea of these completion components gives means to add plat- form details into prediction models, Wu and Woodside(2004) did not follow up on the idea in future work. In this thesis, their ideas are reused and extended. Instead of using CBML, this thesis uses the PCM which offers further advantages over CBML (cf. previ- ous paragraphs). In this thesis, the rulesWu and Woodside(2004) planned to use for the inclusion of different completions are derived from the code transformation.
The Palladio Component Model
The Palladio Component Model deals with many of the introduced requirements (cf. sec-
tion2.4.1) like explicit support for CBSE roles, an explicit model for component contexts,
and CBSE performance predictions based on arbitrary distributed random variables. A brief history of the model and its evolution shows how the requirements have been in- cluded over time.
The model builds on parametric contracts introduced by Reussner (2001). They de- scribe the intra-component relationship between the provided and the required interfaces of components by specifying the invoked required services during the execution of a pro- vided service. Early versions focused on the execution order of required services which has been used for automated component protocol adaptations (Reussner, 2001). Para- metric contracts use so-called service effect specifications (SEFFs) to specify the inner be- haviour of a component. Reussner(2001) uses finite state machines (FSMs) where states represent component states and transitions represent calls to required services. Becker
et al. (2003) introduce a first attempt to a meta-model formalisation of the SEFF concept
based on an EBNF grammar.
Reussner et al.(2003) extend the concept of parametric contracts to analyse software
reliability by annotating SEFF transitions with failure probabilities. Reussner et al.(2004) further enhance the SEFF to enable performance predictions. In this work, states of the SEFF’s FSM represent component internal computations while transitions still represent calls to required services. Random variables attached to states are used to specify time spans. They specify for how long a component remains in the respective state before issuing the following external call. By this, the model considers already the influence of component external service calls (cf. section2.3.1).
The SEFF used for performance prediction has been embedded into a more com- plex meta-model, which explicitly introduced components, interfaces, and connectors as model concepts. However, the corresponding implementation to create, serialise, and
(2005) and later on extended by a student project group (Krogmann and Becker,2007). The master thesis by Krogmann (2006) introduced an ECORE instance of the PCM’s