Model-driven performance analysis Becker [2008] and Moreno et al [2008]

[2008]

This approach describes model-driven analysis based on reasoning frameworks. This per- formance reasoning framework transforms a design to a model with real-time performance prop- erties that can be analysed using different evaluation procedures, such as rate monotonic analysis and simulation. It is described in Figure 2.31. The PACC Starter Kit10_{is a development environ-} ment that can generate and analyse code from the same models. Such tools are implemented as a package and independently deployed as an Eclipse plug-in, allowing any Eclipse-based tool that models software systems in a parsable design notation to benefit from the framework by export- ing their designs to ICM11components. Some (Eclipse-based tool) examples are, the IBM Ratio- nal Software Architect, Eclipse Model Development Tools (MDT), UML 2, and ACME-Studio. To add a performance reasoning framework plug-in as a modelling tool, is by creating a class that implements the method:AssemblyInstancetranslateDesignToIcm(IFiledesignFile).

ICM Design-to ICM translation Architecture Description Constraints Satisfies Performance Interpretation Performance Model Performance Analysis Analysis Result (e.g. Average + Worst case Latency) RMA, Queuing Theory Based on Performance reasoning Framework

Key:

Data

Representation Transformation

Dependency Data Flow

Figure 2.31: Performance framework,Moreno et al.[2008].

The models of this method are created with Eclipse Modelling Framework (EMF), and the Object Constraint Language (OCL), which are implemented with the OCL-EMF validation framework. This approach has five main elements beside the architecture description element, which are:

1. Design-to-ICM translation – translates from architecture descriptions to simplified repre- sentations (ICM);

10_{The PACC Starter Kit is a set of software development tools integrated to provide unbiased confidence in system}

behaviour predictions. This demonstrates how existing technologies can be used as such.

11

Intermediate Constructive Model (ICM) is a model that serves as an input to the performance reasoning frame- work, were significant architectural descriptions’ elements concerning performance analysis, are contained in this model.

2. ICM – a simplified version of the system’s original design, that serves as an input to the interpretation;

3. Interpretation – transforms ICM architecture descriptions into analytical models;

4. Analytical (Performance) model – a model that can be analysed by different evaluation techniques included in the performance analysis components; and;

5. Performance analysis – the element that analyses the performance model by analytic and simulation-based predictors based on Rate Monotonic Analysis (RMA) and queuing the- ory.

The structural model is less generic than the one of ACME (described in Section 2.3.4). Contrary to ACME, the content of a communication point is made explicit in this model. This model has an option to be required only or provided only. Typed input and output arguments are also required as a part of the needed set of communication elements. Any component model that exhibits the same bidirectional communication points is compatible with the structural model. This characteristic can be found in many component models such as Fractal or SOFA. Fractal is an advanced component model and is associated with growing programming and management support, initially proposed by France Telecom and INRIA since 2001. Distributed Systems Re- search Group at Charles University in Prague developed SOFA, a component system which provides many advance features such as: ADL-based design, provision of transparent distribu- tion of applications, behaviour specification, and verification based on behaviour protocols and different communication styles that are supported by software connectors,Becker[2008].

To make their created designs non-ambiguous, meta-models with strong semantics were used as models, therefore allowing analyses to be performed. The semantics of communica- tion points must be clear to enable analysis tools to manipulate them. According to Moreno et al.[2008] in ACME/Armani, the content of a communication point (called Portexplained in Section 2.3.4) is not expressed. The only possibility to add information in a communication point is by defining properties, which have no clear semantics. For example, it is possible to performWrightbehavioural analysis on an ACME description by adding some ACME proper- ties, containing Communication Sequential Processes (CSP) expressions,Brookes et al.[1984], Roscoe et al.[2011]. It is not possible to guarantee that the messages declared to be sent or received structurally, as there is no relationship between these properties and the structure of the architecture.

In the Moreno approach, the behavioural meta-model is strongly associated with the struc- tural meta-model. The sent and received messages expressed in the behavioural model cor- respond to the argument in the structural model. For example, this approach checks that the sent (resp. received) messages in the behavioural model correspond to the output (resp. input) arguments in the structural model. More generally, Moreno chose to have a richer structural meta-model than ACME in order to be able to check the coherence between the different meta- models; i.e. structural, behavioural, data flow and quality, Becker [2008]. The scope of this

2.5. EVALUATING SOFTWARE ARCHITECTURE

approach has different aspects and concerns such as decreasing design models and the analysis models’ semantic gaps; also, to enable the analysis tools’ utilisation together with various de- sign languages.However, this approach is limited to one quality attribute. Thus, developing an interpretation component for each quality characteristic for the purpose of its evaluation, is a hard and time-consuming job. Also, reducing the component size of the original architecture to the half number in order to evaluate quality attribute (as the case in performance model) is not delicate; and I think it does not actually reflect the real design, which could affect the integrity of the evaluation mechanism.

Other approaches:

Koziolek et al.[2007] used the Palladio Component Model (PCM) to illustrate component- based architectures to include the necessary information for performance prediction. Develop- ers and software architects will find the features of PCM very useful. Component developers have the ability to determine the performance of their components independently from context. Therefore, they will have the ability to enable predictions on third-party performance as well as improving the reusability of their components. PCM, also allows software architects to analyse the performance of their design without requiring a written code. By using the specifications, they can analyse performance using performance specifications that are retrieved from reposi- tories and assemble them to architectures,Rech et al.[2009].

More proposals, such as the intermediate models CSM byPetriu et al.[2004] and KLAPER by Grassi et al. [2005], have also been made. Also, D’Ambrogio (2005) describes a frame- work to automate the building of performance models from UML design models,Moreno et al.[2008]. UML model based performance modelling and prediction have already been exe- cuted byGilmore et al.[2003]. It incorporates performance information in the state diagrams’ transition labels,Becker[2008].

Many studies have been reported, in order to identify, analyse, evaluate and explain the relationship between quality attributes and architecture or design including their patterns. Each research has its own scope and focus in a specific domain and quality. However, very few have identified the relationship between quality attributes and architecture in general conceptual schema that can be applied for most quality attributes and can automate the analysis result. For further details and additional knowledge in this area, readers are advised to explore different resources.