service architecture meta-model - q-impress

Project Deliverable D2.1Service Architecture Meta-Model (SAMM)

Project name: Q-ImPrESSContract number: FP7-215013Project deliverable: D2.1: Service Architecture Meta-ModelAuthor(s): Steffen Becker, Lubomír Bulej, Tomáš Bureš, Petr Hnetynka,

Lucia Kapová, Jan Kofron, Heiko Koziolek, Johan Kraft,Raffaella Mirandola, Johannes Stammel, Giordano Tamburrelli,Mircea Trifu

Work package: WP2Work package leader: FZIPlanned delivery date: M9Delivery date: September 30, 2008Last change: September 30, 2008Version number: 1.0

Abstract This document introduces and describes the Q-ImPrESS Service Ar-chitecture Meta-Model used in the Q-ImPrESS project as the central meta-modelto store, analyse, and transform evolving service-oriented architectures. The de-scription of the Service Architecture Meta-Model contains the requirements tobe fulfilled by the meta-model, a high-level model description, low-level meta-class details, an example instance of the Service Architecture Meta-Model, andmappings of existing meta-models on Service Architecture Meta-Model.

Keywords Service Architecture, Meta-Model, Service, Component

D2.1: Service Architecture Meta-Model

Version: 1.0 Last change: September 30, 2008

Revision history

Version Change Date Author(s) Description0.1 14-08-2008 FZI Changed document layout, applied standard layout0.2 15-08-2008 FZI Improved Documentation for Static Structure0.3 18-08-2008 FZI Improved Layout and Formatting0.4 20-08-2008 FZI Added Requirements for the SAMM0.5 20-08-2008 FZI Added mapping of SAMM to PCM0.51 24-08-2008 CUNI Completed deployment model0.6 27-08-2008 FZI Added pictures to allocation package0.61 27-08-2008 PMI Initial version of the example chapter0.7 15-09-2008 FZI Added package overview, structure modified0.71 16-09-2008 CUNI Deployment model documentation completed0.72 16-09-2008 PMI Added figures to example chapter0.8 17-09-2008 FZI Added mapping tables, figures0.9 29-09-2008 FZI Final fixes and adjustments1.0 30-09-2008 FZI Final version

c© Q-ImPrESS Consortium Dissemination Level: public /109



Contents

1 Introduction 7

2 Requirements 82.1 Consortium Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.2 Solution Strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.3 Solution-Related Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.4 Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3 High Level Model Description 153.1 Static package . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163.2 Behaviour package . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173.3 Deployment package . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.3.1 TargetEnvironment subpackage . . . . . . . . . . . . . . . . . . . . . . 183.3.2 Hardware subpackage . . . . . . . . . . . . . . . . . . . . . . . . . . . 203.3.3 Allocation subpackage . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.4 G–AST package . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203.4.1 Summary of subpackages . . . . . . . . . . . . . . . . . . . . . . . . . 213.4.2 Overview of model elements . . . . . . . . . . . . . . . . . . . . . . . . 213.4.3 Model annotations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223.4.4 Expressions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

4 Example Model Instance 244.1 Example Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244.2 Structural Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254.3 Behavioural Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264.4 Deployment Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

5 Mappings of Other Meta-Models 315.1 PCM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315.2 SOFA 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 355.3 ProgressCM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 385.4 KLAPER . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

6 Low Level Model Description 446.1 Package samm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

6.1.1 Package Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 446.2 Package samm::annotation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

6.2.1 Package Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

c© Q-ImPrESS Consortium Dissemination Level: public / 109



6.2.2 Detailed Class Documentation . . . . . . . . . . . . . . . . . . . . . . . 446.3 Package samm::behaviour . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

6.3.1 Package Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 446.3.2 Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 456.3.3 Detailed Class Documentation . . . . . . . . . . . . . . . . . . . . . . . 45

6.4 Package samm::core . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 466.4.1 Package Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 466.4.2 Detailed Class Documentation . . . . . . . . . . . . . . . . . . . . . . . 46

6.5 Package samm::datatypes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 476.5.1 Package Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 476.5.2 Detailed Class Documentation . . . . . . . . . . . . . . . . . . . . . . . 47

6.6 Package samm::deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . 486.6.1 Package Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

6.7 Package samm::deployment::allocation . . . . . . . . . . . . . . . . . . . 496.7.1 Package Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 496.7.2 Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 496.7.3 Detailed Class Documentation . . . . . . . . . . . . . . . . . . . . . . . 49

6.8 Package samm::deployment::hardware . . . . . . . . . . . . . . . . . . . . . 506.8.1 Package Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 506.8.2 Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 506.8.3 Detailed Class Documentation . . . . . . . . . . . . . . . . . . . . . . . 50

6.9 Package samm::deployment::targetenvironment . . . . . . . . . . . . . . . 566.9.1 Package Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 566.9.2 Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 566.9.3 Detailed Class Documentation . . . . . . . . . . . . . . . . . . . . . . . 56

6.10 Package samm::staticstructure . . . . . . . . . . . . . . . . . . . . . . . . 656.10.1 Package Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 656.10.2 Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 656.10.3 Detailed Class Documentation . . . . . . . . . . . . . . . . . . . . . . . 65

6.11 Package samm::usagemodel . . . . . . . . . . . . . . . . . . . . . . . . . . . . 736.11.1 Package Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

6.12 Package gast . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 736.12.1 Package Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

6.13 Package gast::accesses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 736.13.1 Package Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 736.13.2 Detailed Class Documentation . . . . . . . . . . . . . . . . . . . . . . . 74

6.14 Package gast::annotations . . . . . . . . . . . . . . . . . . . . . . . . . . . 796.14.1 Package Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 796.14.2 Detailed Class Documentation . . . . . . . . . . . . . . . . . . . . . . . 79

6.15 Package gast::core . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 806.15.1 Package Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 806.15.2 Detailed Class Documentation . . . . . . . . . . . . . . . . . . . . . . . 80




6.16 Package gast::functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 856.16.1 Package Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 856.16.2 Detailed Class Documentation . . . . . . . . . . . . . . . . . . . . . . . 86

6.17 Package gast::statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . 906.17.1 Package Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 906.17.2 Detailed Class Documentation . . . . . . . . . . . . . . . . . . . . . . . 90

6.18 Package gast::types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 946.18.1 Package Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 946.18.2 Detailed Class Documentation . . . . . . . . . . . . . . . . . . . . . . . 94

6.19 Package gast::variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1006.19.1 Package Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1006.19.2 Detailed Class Documentation . . . . . . . . . . . . . . . . . . . . . . . 100

7 Conclusions 103

Index 104

Glossary 106




1 IntroductionThis document represents deliverable D2.1 of the Q-ImPrESS description of work. It contains

the Q-ImPrESS Service Architecture Meta-Model. The Service Architecture Meta-Model specifieshow to describe service-oriented architectures in a way that allows latter quality trade-off analysesfor evolving software systems. As such, it provides the schema used by the users of the Q-ImPrESSmethod to describe architectures. For example, the Enterprise SOA showcase of Itemis or the robotcontrol system of ABB should be describable as instance of the Service Architecture Meta-Model.Additionally, the Service Architecture Meta-Model serves as foundation for all academic activitiesin order to define the Q-ImPrESS method and develop its tools. It

• defines the storage layout for reverse engineered source code,

• is the input needed to generate editors and transformations dealing with model instances,

• and finally, allows trade-off analyses to be performed.

This document provides the necessary documentation to successfully perform the aforemen-tioned tasks. It is structured as follows:

Chapter 2: Chapter 2 derives requirements which need to be met by the Service ArchitectureMeta-Model. These requirements are based on Q-ImPrESS deliverable D1.1 whichlists the requirements as identified by the industrial partners in the Q-ImPrESS con-sortium.

Chapter 3: Chapter 3 provides a high-level, package-centric overview on the Q-ImPrESS ServiceArchitecture Meta-Model. It is meant as a starting point for learning the Service Ar-chitecture Meta-Model. As such it also provides information on the design rationaleof the Service Architecture Meta-Model.

Chapter 4: Chapter 4 provides a minimal example architecture which is modelled as an instanceof the Service Architecture Meta-Model.

Chapter 5: Chapter 5 provides mappings of some of the existing service or component orientedmeta-models like KLAPER, Palladio CM, and ProgressCM, onto Q-ImPrESS Ser-vice Architecture Meta-Model instances.

Chapter 6: Chapter 6 provides all the details of the meta-classes of the Service ArchitectureMeta-Model. It lists all meta-classes, their properties, and accompanying constraints.Additionally, it provides overview class diagrams showing the meta-classes and theirrelationships.

Chapter 7: Chapter 7 concludes the presentation of the Service Architecture Meta-Model andprovides an outlook to future work and extensions.




2 RequirementsThis chapter lists the requirements derived for the Q-ImPrESS Service Architecture Meta-

Model. The requirements resulted from an intensive investigation of the requirements specifiedin Q-ImPrESS deliverable D1.1 - Requirements Document [1]. The following first presents insection 2.1 the requirements related to the Service Architecture Meta-Model taken from the D1.1deliverable. Based on this, section 2.2 derives the solution strategy taken in Q-ImPrESS workpackage 2. The solution strategy finally introduces additional requirements listed in section 2.3.

2.1 Consortium Requirements

The Service Architecture Meta-Model (SAMM) in Q-ImPrESS serves as common ground for theQ-ImPrESS method, its prediction and reverse engineering tools. As a consequence the meta-model has to fulfil a set of requirements from the perspective of the Q-ImPrESS consortium listedin the following:

1. Prediction methods: The SAMM’s information should serve as input to multiple modelscapable of predicting certain quality attributes. The quality attributes of interest are definedin D1.1 [1, Section 5.3]. They contain performance, reliability, and maintainability.

2. Trade-off analysis: The support in the SAMM for multiple quality attributes is necessaryto reach the Q-ImPrESS aim to make trade-off analyses for evolving systems (defined inD1.1 [1, Section 5.4]). This requires the SAMM to be flexible enough to provide sufficientdetails to allow the generation of different kinds of prediction models – at least one perquality attribute of interest.

3. Views: The SAMM should support multiple views to ease the modelling of different systemaspects (defined in D1.1 [1, Section 5.1]). D1.1 lists the following minimum views (adjustedto the recent Q-ImPrESS glossary): static package, behaviour package (called "DynamicInformation" in D1.1), deployment package, allocation package, usage package, and qualityannotations. The following gives details on the introduced packages.

(a) Static Package: This class of information contains details on interfaces, services, ser-vice interconnection, and service implementation (defined in D1.1 [1, Section 5.1]).

(b) Black-Box System Parts: Important to Q-ImPrESS is the ability to model system partswhose internal structure is not known (defined in D1.1 [1, Section 5.1]). The methodhas to use estimates based on measurements of these parts. Gathering such informationmay need highly specialised measurements of the black-box parts. A prerequisite isthat the black box parts can be seen as components, i.e., they have an explicit interfacesuch as the one specified in the previous enumeration paragraph.




(c) Behaviour: Behaviour characterises the control and data flow of the service orientedarchitecture while executing the system (defined in D1.1 [1, Section 5.1]).

(d) Quality Annotations: Quality annotations should express constraints on certain qualityattributes, e.g., service level agreements (SLAs) (defined in D1.1 [1, Section 5.1]).

(e) Resource Model: For the prediction of run-time properties information on the executinghardware parts and supporting software systems like operating systems or middlewarelayers is needed. The meta-model should clearly specify the amount of mandatoryinformation. However, some parts of this information may be gathered by tools, e.g.,benchmarks of the underlying middle-ware layer (defined in D1.1 [1, Section 5.1]).

(f) Special Shared Resources: Special attention is paid to the implicitly shared resourcessuch as processors or disks. As defined in D1.1, the pivotal shared resources are pro-cessor, memory, disks, and networks (defined in D1.1 [1, Section 5.3]).

(g) Allocation Information: The association of components to hard- and software nodesis needed to estimate the resource consumption and contention effects in predictionmethods (defined in D1.1 [1, Section 5.1]).

(h) Usage Profile: This view specifies the workload intensity caused by the users of theservice oriented system and information on the parameters passed to the system inrequests for service. It is needed to respect different types of system usages in qualitypredictions (defined in D1.1 [1, Section 5.1]).

4. Editors: There have to be graphical editors to manually create, adjust, or change instancesof the Q-ImPrESS Service Architecture Meta-Model (defined in [1, Section 5.1]).

5. IDE Integration: Modelling instances of the Service Architecture Meta-Model should bepossible at least in Eclipse, support for Visual Studio is optional (defined in [1, Section5.5]).

6. Types of Evolution Scenarios: Deliverable D1.1 defines some typical types of evolution sce-narios (defined in [1, Section 4.4.2, Section 4.4.3, Section 4.4.4]). Typical scenarios includeadding a new service, changing an existing service, changing the connection of services, orchanging a service’s allocation. The Service Architecture Meta-Model has to provide meansto specify models of systems undergoing such evolutions in an appropriate way.

7. Model size: The requirements document describes architecture reverse engineering scenar-ios [1, Section 5.2]. Based on the information given there, it has to be expected that in-stances of the Service Architecture Meta-Model may be large. The Service ArchitectureMeta-Model realisation therefore has to count for large model instances.

2.2 Solution Strategy

This section contains a brief overview on the solution strategy selected by the members of workpackage 2. This strategy assigns the Service Architecture Meta-Model its role in the Q-ImPrESS




tool chain. Based on the presented solution, the next section derives solution specific requirements.To realise the envisioned trade-off analysis between quality attributes for evolving service-

oriented architectures the Q-ImPrESS method should include several steps (see Figure 2.1 for anoverview).

LQN EQN-Sim...

(T3.3)

QN ModelChecker...

(T3.3)

LQN MarkovChain...

(T3.3)

Automata MarkovChain...

(T3.3)

Common Service Architecture Meta-Model

Static Behaviour

QoSAnnotations

Resources &Environment

Usage Model

Allocation

(T3.2) (T3.2)

Legend

Prediction Formalism

Prediction Model

M2M-Transformation

New Meta-ModelCode Code

Java C/C++

Rev

erse

Eng

inee

ring

(T2.2 & T2.3) Static Reverse Engineering(T2.4) Dynamic Reverse Engineering

Consistency(T5.1)

T2M-TransformationCheck Transformation

(generated)Model Editors

(T4.1)

(T2.1)

AnalysesResults

<<annotate>>(T5.2)

<<System Architect>>

ProgressCM SOFAPalladioCMKLAPER

Figure 2.1: Overview on the Envisioned Q-ImPrESS Method

First, an already existing software architecture which is subject to evolutionary changes has tobe reverse engineered into appropriate models. For this, static analysis is used to extract the staticstructure from the source code (components, interfaces, connectors). The gathered information isthen enhanced with measurements taken on existing and running systems using dynamic analysis.These measurements are needed in order to capture an abstraction of the system’s behaviour withrespect to the considered quality attributes. Because this abstraction is in essence an approximationof the behaviour, the resulting models may also need some manual corrections or additions tocompensate the loss of precision. This activity is supported by model editors, generated usingMDD techniques.

The reverse engineered information is stored in the Service Architecture Model, which is aninstance of the Service Architecture Meta-Model introduced in this document. It attempts to unifycommon aspects of meta-models for component-based and service-oriented architectures which




serve as foundation for Q-ImPrESS. The meta-models forming this foundations are KLAPER [2],PalladioCM [3, 4], ProgressCM (ProCom) [5], and the SOFA component model [6].

These meta-models are used later in the Q-ImPrESS tool-chain for quality predictions. Sinceone of the key requirements for the meta-model defined in Q-ImPrESS is to support several differ-ent prediction techniques, each with its strength and weaknesses, the Service Architecture Meta-Model has to be extensible to some extent. This extensibility is needed for the behaviour packageas further detailed in section 2.3.

Newly developed transformations then transform instances of the Q-ImPrESS Service Archi-tecture Meta-Model into the specific meta-models listed before (i.e., KLAPER, PalladioCM, Pro-gressCM, and Sofa). Each of these meta-models uses in turn its own tool-support to make pre-dictions on their supported quality attributes (e.g., mean response time, response time distribution,mean time to failure, ...) and the results are collected and fed back into the Service ArchitectureModel. They are then used in the trade-off analysis to support the user in selecting the optimaldesign decisions for the given evolution scenario.

2.3 Solution-Related Requirements

This section refines the requirements for the Service Architecture Meta-Model presented in sec-tion 2.1 and integrates additional requirements resulting from the envisioned solution strategy orfrom general experience with model-driven quality predictions.

1. Reuse of existing tools: As the migration of the existing methods and their tools (i.e.,KLAPER, PalladioCM, ProgressCM, and SOFA) to one single common meta-model is (i)not a good idea, since it would most likely have a flattening effect, making all the approachesvery similar thus loosing some of their specific strengths, and (ii) probably infeasible giventhe time and resource constraints, the SAMM should support model transformations to theparticipating prediction models preferably by using standard meta-model infrastructures likeMOF or EMF and model transformation engines such as QVT.

2. Tool selection: As the existing meta-models and their tools are based on Eclipse and theEclipse Modelling Framework (EMF) [7] integration into Eclipse is targeted first. Note, thatthis complies with the priorities for the supported IDE named by the industrial partner.

3. Static Package: As most existing meta-models in Q-ImPrESS use components as primaryparts, the Service Architecture Meta-Model also relies on components as entities for serviceimplementations. Then, a service is an instantiated and deployed component. A component’soutside view is determined by a set of provided and required interfaces (in correspondencewith the definition by Szyperski [8]). Services have to be connected via other componentsrepresenting for example a BPEL work-flow, a scripting engine, or simply by a special con-nector or component. Interfaces contain a list of available operations, their parameters in-cluding the type of parameter (IN, OUT, INOUT), and optionally, a protocol describing theallowed call sequences on this interface (Note, that the latter is hard if not impossible to




reverse engineer from source code). In addition to components and services, connectors arepart of the static structure. For connectors their different behaviour classifies them into dif-ferent types, like RPC-calls with block and return semantics or event sending where an eventis sent to the communication partner (fire and forget semantics). The SAMM has to supportvarious connectors out of the box like RPC or message sending and an extension mecha-nism to extend the set of connectors in a way which should not break quality analyses. Thelater might be realised by providing a component which describes the behaviour and qualityimpact of more advanced connectors based on the basic ones provided in the model. Forexample, one could create a connector which distributes a message to several componentsby providing a "connector component" which models this behavior.

4. Behaviour Package: For each operation offered by a service or a component at least some in-formation about the behaviour executed when the operation is triggered is needed. However,several types of formalisms for such behaviour exist with different foci on different qualityaspects, such as Stochastic Process Algebras, Activity-like languages, and Stochastic PetriNets. There may not be a common ground for these modelling styles. As a consequence, theSAMM has to support a variety of behaviour modelling languages. To realise this require-ment, the SAMM contains an extensible behaviour package. This package can be extendedwith different behaviour modelling languages like SEFFs, Process Algebra Expressions, oreven the service’s AST. Also note, that for the Q-ImPrESS method it is not feasible to sup-port all of these languages when doing reverse engineering. A selection is made based onthe reverse engineering requirements. While the control flow graph can be extracted by re-verse engineering tools, the data flow is sometimes only recoverable at run-time. For thelatter, monitoring of the running system is needed. The results of measurements are how-ever bound to the (hardware and software) parameters of the execution environment themeasurement is taken on; this may sometimes make the prediction imprecise for executionenvironments differing from the one used for measuring.

5. Quality Annotations: For the prediction of run-time properties, such as performance or reli-ability, additional information, such as resource demands caused by certain processing stepsin the architecture, loop iteration counts, polymorphic types, etc. is needed. This type ofinformation has to be attached to elements in the SAMM, such as actions in an activity-likebehaviour language. The SAMM needs to support such annotations. They should be definedflexibly to reuse them in the various behaviour modelling styles. They should also supportspecifying the source of the annotation, i.e., whether the value is a requirement, a predictedvalue, an estimation, or a measured value. A predicted value stands for the result of theprediction process, i.e., it is an output of the method, while an estimation is a user’s guessof the value, i.e., it might be an input parameter of the method. If it is a measured valueit should contain information on the execution environment used for the measurements andusage model used to measure it.

6. Resources: The initial work on resources will focus on implicitly shared resources like pro-cessor, memory, and disks (note, that this omits logical resources such as queues, which are




shared explicitly rather than implicitly). The information describing these resources in themeta model includes:

(a) For processors: number of nodes, number of cores per node, number of hyper-threadsper core, processor clock frequency, number of cache levels, size of each cache level,sharing of each cache level, inclusivity and associativity of each cache level.

(b) For system memory: total amount of physical and virtual memory, memory bus topol-ogy and transfer rate.

(c) For application memory: maximum configured heap size, heap management and col-lection strategies.

(d) For disks: sequential transfer rate, track to track and random access latency.

For particular instances of the meta-model, this information is optional since the meta-modelshould also support situations where a quick prediction from less detailed information ismade. Depending on the behaviour of the shared resources in the applications specified inthe requirements document of work package 1, further data is likely to be required. Initially,this should best be handled by including an enumerated resource type attribute for eachresource (e.g. processor type attribute with values for specific models, memory managertype attribute with values for specific virtual machine configurations, etc.).

7. Usage: The needed usage information may be gathered by monitoring tools but is likelysubject to manual changes. However, manual changes might only work to a certain extent asa large deviation of the manual values from values used to take measurements can invalidatethe resulting model.

2.4 Limitations

The prediction of quality attributes, such as performance, reliability and maintainability, still hasits limitations due to the complexity of the resulting analysis models. While the description ofthese limitations for each approach is a part of later work packages, in work package 2 somelimitations are already implied due to the capabilities given by the meta-model. The followingtables list limitations caused by component and service internal behaviour and component andservice interactions, respectively. Note that some of these limitations will be removed once theinvestigation of the behaviour of implicitly shared resources is done in work package 3. In turn,this will result in a more powerful meta-model, but also extended transformations from the ServiceArchitecture Meta-Model to the Prediction Models.




Limitation ClassMeta-Model Elements likelyneeded

Consequence

Memory AvailabilityMemory Allocation Actions,Memory Deallocation Actions

No accurate predictions (of per-formance) if memory availabilityor garbage collection is a limitingfactor.

Memory TransactionsMemory Access Rate andPattern

No accurate predictions wherethe memory subsystem is the lim-iting factor. Especially impor-tant for multi-core SMP systemswhere cores partially share thememory subsystem.

Internal Component orService State

State Changes,Trigger for State Changes,State Influence

No accurate predictions for state-ful services if state impactsperform-ance or reliability.

Concurrency,OS Scheduler

Detailed Scheduler ModelsNo accurate predictions in whichthe OS scheduler or task priori-ties play a central role.

Data Streaming(partially)

Streaming Events (Start, Stop),Streaming Interface Models

No accurate predictions forstreaming-based systems

No DynamicArchitecture

Changes of Connectors atRuntime,Triggers for these Changes

No accurate predictions of sys-tems with unforeseeable connec-tors or changing connectors atruntime

No Exceptions(partially, dependingon behaviourmeta-model used)

Exception triggers,Catch Blocks

No accurate predictions for caseswhich include exceptions




3 High Level Model DescriptionThe Service Architecture Meta-Model (SAMM) consists of five packages, each focusing on

particular aspects of services (see figure 3.1).

Figure 3.1: Overview of the meta-model packages.

The Static package focuses on modelling the static structure, i.e., representation of componentsand their interconnection. The Behaviour package models the behaviour of components realizingthe services and focuses on providing a general platform from which specific behaviour modelssupporting various kinds of behaviour reasoning (behaviour compatibility of components, reliabil-ity prediction, etc.) can be derived. The Deployment package aims at assigning the componentsto particular execution nodes (allocation) thus forming services, and modelling the hardware re-sources to support prediction of performance of the services. The Annotation package focuseson the annotation of services and their behavioural parts with various information such as thoseconcerning performance, reliability, and control-flow details (repetition counts, etc.). Finally, theUsage package aims at specification of the way the services inside a Service Architecture Model(SAM), i.e., a particular instance of SAMM, are used, e.g., in which order and how often they arecalled by a user.

Regarding the layout of this chapter, the Static package is described in section 3.1, the Be-haviour package in section 3.2, while section 3.3 focuses on the Deployment package. Finally,this chapter is concluded with section 3.4 where the G-AST model is described, as it is the corebehaviour model of the Q-ImPrESS project and forms the target platform for reverse engineering




of the source code. The Annotations and Usage packages are not described in this document sincethey are a subject of a later phase of the Q-ImPrESS project.

3.1 Static package

The Static package focuses on modelling the static structure of a service architecture. This includesrepresentation of the components and services, their hierarchical structure and interconnections andinterdependencies among them.

The top of the model structure is formed by the service architecture model (SAM) (see 6.10.3.16),which models a set of services (see 6.7.3.1). A service is a run-time entity providing its function-ality to the outside world; to be able to provide the functionality, it may use functionality of otherservices. An example of a service architecture model presenting a typical situation is depicted infigure 3.2; here, the services S1..S4 are used by the service S providing a complex service to theoutside world.

Figure 3.2: Orchestrated services providing a complex service.

As aforementioned, a service is a run-time entity; it is realized by a deployed component. Acomponent within a SAM is an instance of a component type (see 6.10.3.2) and it is a unit of designand composition. Each component type is characterized by four sets of ports—a set of providedand a set of required ports (see 6.10.3.9) and a set of source and a set of sink ports (see 6.10.3.7).Through a required port, a component can exploit functionality offered by another componentthrough its provided port. To be able to do so, the provided port and the required port have tobe connected by a connector (see 6.10.3.5). The event ports, i.e., sink and source ports, serve formodelling message based communication among components.

There are two kinds of components—primitive components (see 6.10.3.14) and compositecomponents (see 6.10.3.3). While a primitive component is a black-box, at which only the twosets of ports are visible, a composite component is a hierarchical structure composed of other (ei-ther primitive or composite) components. As an example, consider the figure 3.3. In this figure,




there are two primitive components C1 and C2 connected via an assembly connector (see 6.10.3.5).The C1 component uses its required interface to exploit the functionality offered by the C2 com-ponent. The composite component C then encapsulates the C1 and C2 components and providesthe functionality offered by the C1 component using a delegation connector (see 6.10.3.5). The Ccomponent can be deployed thus forming a service.

C

C2C1

Figure 3.3: Primitive and composite components.

Two kinds of communication among components are supported by the meta-model via twospecialized Port subclasses: Message- or event-based communication modelled by instances of theEventPort entity (see 6.10.3.7), and method-call-based communication modelled by instances ofthe InterfacePort entity (see 6.10.3.9).

To enable reuse of particular entities, interfaces, component types, message types, and datatypes are stored within a repository (see 6.10.3.15). From the repository, the entities can be fetchedand used for building new components realizing new services.

Each Entity (see 6.4.2.1) of the meta-model contains a unique id, as well as a documentationattribute to carry optional documentation for various purposes in the future. Moreover, except forConnector (see 6.10.3.5) and Endpoint (see 6.10.3.6), each entity of the static part of the meta-model is a NamedEntity (see 6.4.2.2) and thus can be referenced by name.

For a detailed view of the Static package refer to the corresponding section of chapter 6.

3.2 Behaviour package

The Behaviour package focuses on modelling the source code structure of an object-oriented soft-ware system. The aim of this package is to represent the source code in a way that abstracts fromlow level source code aspects (e.g., the implementation language) on one hand while keeping thenecessary details for further analysis of the behaviour on the other hand. Because the spectrum ofthe behavioural models used by particular project partners is too wide to be covered by a commonmeta-model at a reasonable level of details, an abstract Behaviour entity (see 6.3.3.1) has beenintroduced to the model. From this entity, specialized models, e.g., G-AST, are to be inherited. Forillustration consider figure 3.4.




Component

TypeBehaviour

*

SOFA

Behavior

Protocols

G-AST RD-SEFF

{open}

?a;?b || ?c+?ddoSth

if

then else

loop

statement

Figure 3.4: Behaviour overview.

Since the aim has been not to restrict the behaviour modelling to a particular approach, theBehaviour entity is defined as abstract only referencing particular operation it relates to. On theother hand, there is still a need to have a target model for the reverse engineering of the sourcecode, which could be used as the starting point for approaches of particular partners. Therefore,Generalized Abstract Syntax Tree (G-AST) representation (see section 3.4) has been chosen as theinitial source code representation from which other kinds of representations can be derived (e.g.,using model transformations). This will avoid multiple implementations of parsers, which is, dueto planned support of several programming languages, a significant advantage.

3.3 Deployment package

The deployment package contains entities that allow modelling of target environment into whichservices can be deployed. Such an environment contains nodes, which provide computationalcapabilities, and network elements, which allow modelling network topology of a distributed en-vironment. In line with focus of the project on performance prediction, the model of the targetenvironment allows capturing various resources that need to be taken into account during perfor-mance analysis. The package is divided into three subpackages (see figure 3.5) focusing on variousaspects of the deployment.

3.3.1 TargetEnvironment subpackage

The model captures two main aspects of the target environment. One part of the model representsthe physical layer of the environment, which comprises the above mentioned nodes and networkelements, and additional entities which serve to capture the hardware configuration of each node




Figure 3.5: Deployment package overview.

with level of detail required by various performance prediction and reliability analysis methods.These entities represent processors (with processing cores and caches), storage devices, physicalmemory, and network interfaces.

The other part represents the logical layer of the environment, built on top of the physical layerand specifically on top of hardware installed in nodes. The main concept in the logical view ofthe environment is a container, which represents an execution environment hosted on a particularnode, into which services can be deployed. The concept of a container is meant to be general,and may represent e.g., an operating system, an application server, or a virtual machine. Whatexactly is represented by a particular container depends on the service platform, but in general itshould be the top level of the software stack used to deploy services. Consequently, a node mayhost several different containers, each provided with a slice of node’s physical resources. Theallocation of physical resources to containers is expected to be enforced outside the containers andis not captured in the model.

A container uses the allocated physical resources to provide logical resources that can be con-sumed by services executing in a particular container. The logical resources mainly comprise thecounterparts of the physical resources, i.e., processor execution time, persistent storage space, sys-tem memory, and network bandwith. A container may also provide arbitrary passive resourceswhich do not have a physical counterpart and are typically consumed (and contended over) byservices running in the same container. Those include e.g. semaphores, file descriptors, etc. ThePassiveResource entity in the target environment model provides an extension point which canbe used to define specific passive resources required by a particular performance prediction orreliability analysis method.

The dual modelling of physical and logical resources is needed mainly to determine implicitsharing of hardware resources by services executing in containers on a single node.




3.3.2 Hardware subpackage

The hardware subpackage is closely related to the target environment subpackage and containsmodels describing properties of physical resources such as processors (including processing cores,cache hierarchy, and sharing of caches among cores), storage devices, physical memory, and net-work interfaces. The main purpose is to allow reuse of commonly (and repeatedly) used hardwareresources.

For each kind of physical resource, there is a descriptor entity capturing the resource attributes,and the descriptor is then referenced by instances of physical resources installed on a particularnode.

3.3.3 Allocation subpackage

The allocation subpackage represents a bridge between the static model of service architectureand a particular target environment. The model is very simple and only captures the allocation ofservices to containers.

3.4 G–AST package

One of the goals of the Q-ImPrESS project is to provide tools to build models of existing service-oriented software systems. In order to automate this process, reverse engineering and monitoringmethods are to be applied. The G-AST meta-model is an abstraction of source code and coversa superset of most typical features present in today’s common object-oriented programming lan-guages (such as Java and C/C++), i.e., constructs of these languages can be mapped to entities ofthis package.

On one hand, the G-AST meta-model serves as the output model of reverse engineering andmonitoring methods, such as SISSy [9], JAbstractor, etc. On the other hand, it serves as the inputfor extraction methods of the component-service structure (as described in the static meta-modelpackage, see section 3.1) and as a special kind of behavioural model. The last point is reflectedin the model by providing the ability to model the control-flow and data-flow inside functions andmethods.

The G-AST meta-model is based on the QBench [10] meta-model of the SISSy tool (StructuralInvestigation of Software Systems) [9] developed in the QBench research project [11] of FZI.SISSy is a tool chain for extraction of Java, Delphi, and C/C++ code into a model instance in orderto apply various static analysis algorithms.

Nevertheless, the G-AST meta-model is independent of the extraction tool and can be used byarbitrary extraction and analysis tools, as well as a stand-alone model. Moreover, it can be used fordata-transfer of source code information between extraction and analysis methods of Q-ImPrESS.

The model provides representations for packages, types, classes, interfaces, several kinds ofvariables (e.g., local variables, formal function parameters, global variables), and several kindsof functions (e.g., methods and constructors). Moreover, data-flow and control-flow information




is provided, as well as several kinds of explicitly resolved relationships between certain modelelements (e.g., inheritance relations, function calls, variable accesses).

3.4.1 Summary of subpackages

There are several subpackages within the G-AST package aiming at modelling various aspects ofthe source code. The accesses package contains entities to model various accesses to variables,functions, properties, etc. The annotation package deals with annotations of model elements suchas methods and attributes. The core package contain the basic model elements, such as Root(see 6.15.2.8), Package (see 6.15.2.6), File (see 6.15.2.1), and ModelElement (see 6.15.2.3). Thefunction package contains the elements for modelling arbitrary functions, such as GlobalFunctions(see 6.16.2.6), Methods (see 6.16.2.6), Constructors (see 6.16.2.1), and Destructors (see 6.16.2.3).The statement package contains entities to model internals of functions and method—it containsmodels of statements such as LoopStatement (see 6.17.2.9), JumpStatement (see 6.17.2.8), andCatchBlock (see 6.17.2.4). Finally, the types package is concerned with data types, while thevariables package with variables, such as local variable (see 6.19.2.5), method parameters (see6.19.2.3), and catch parameters (see 6.19.2.1).

3.4.2 Overview of model elements

The most elementary model entities are located in the core subpackage. The Root element (see6.15.2.8) represents the main access point to each model instance. For each G-AST model, thereis one root instance within this model. The root contains several files (see 6.15.2.1) and severalpackages (see 6.15.2.6). The files and packages form two almost independent structures; the pack-age structure models the source code from the logical point of view, i.e., packages containingclasses, global functions and variables, and their internal structure, while the file structure servesfor navigating to particular files containing the elements.

The packages form a hierarchical structure, i.e., they are allowed to be nested in each other asusual. Each package consists of classes (see 6.18.2.2) and global functions (see 6.16.2.6) and vari-ables (see 6.19.2.4). A class has a structure typical for object-oriented languages such as Java andC++, i.e., it contains several methods (see 6.16.2.7) and fields (see 6.19.2.2). For particular typesof functions and variables, there exist abstract classes within the model—Function (see 6.16.2.4)and Variable (see 6.19.2.6), respectively.

The internals of the Function element (see 6.16.2.4) are illustrated in figure 3.6.The Function element is general; it supports features of all supported languages, such as ex-

ception declaration and local classes. The body of the function is modelled by an instance of theBlockStatement element (see 6.17.2.1), which is a list of Statements (see 6.17.2.11). The State-ment is further specialized via inheritance and form entities modelling constructs of programminglanguages such as foreach, while, if, and switch. For more detailed information on specializedstatement entities please refer to figure 3.7 and the corresponding section of chapter 6.

Moreover, most kinds of relationships between elements in the source code are modelled ex-plicitly. All accesses to variables can be captured by the model and read and write accesses are




Figure 3.6: Function overview.

differentiated. In addition, calls to functions and references to types including inheritance relation-ship both between classes and interfaces are captured by the meta-model. For details about themodelled relationships see the description of the accesses subpackage in chapter 6.

The model provides ways to navigate along certain associations. Model elements which are ina containment relationship are modelled by a navigable parent-child association.

All model elements in the G-AST package are derived from the ModelElement entity (see6.15.2.3). Elements such as types, variables, and functions can be referenced by name—theyare derived from NamedModelElement (see 6.15.2.5). To access the model elements, they arestored within a model element repository (see 6.15.2.4). For each model instance, there is justone repository. To be able to provide user with useful information about location of elements insource code, the elements with an explicit representation in source code have a Position element(see 6.15.2.7) attached.

3.4.3 Model annotations

The model provides the opportunity to annotate arbitrary information to model elements. Toachieve this, the ModelAnnotation element (see 6.14.2.3) has to be extended accordingly. Somekinds of model annotations are already included in the model.

One kind of provided model annotations is a structural abstraction (see 6.14.2.4). It enablesmodelling of high-level structures of a software system, i.e., to bundle several model elementsinto an instance of a certain structural abstraction. Examples of a structural abstraction, which arealready provided in the model, are layers (see 6.14.2.2) and subsystems (see 6.14.2.5). Hence, byusing appropriate extraction tools, the layer or subsystem objects can be extracted and associatedwith the program elements they contain. There is no fixed meaning of layers or subsystem, but theuser can define their own meaning and apply corresponding extraction methods. This informationcan be used to derive a service or component structure as a set of interconnected classes.

Some programming languages, e.g., Java, allow to annotate classes or other language artefactsby annotations. These kinds of annotations are represented in the model by the Attribute element(see 6.14.2.1). This information can be used to identify certain service structures, such as annotatedweb services.




Figure 3.7: Statement elements hierarchy.

3.4.4 Expressions

In order to access the data-flow information within a function body, in addition to the statementstructure (which basically represents the control-flow), an expression structure is included in themodel. The expression structure includes information about variable assignments and kinds andorder of calculations (arithmetic operations, unary and binary operations, operation precedence,etc.).




4 Example Model InstanceThis chapter provides a minimal example architecture which is modelled as an instance of

the Service Architecture Meta-Model. It introduces a client-server architecture where a clientcommunicates with a server to retrieve data stored in a database. By focusing on various aspectsof the example, this chapter demonstrates the spectrum of features that the Service ArchitectureMeta-Model supports. Modelling the architecture through the meta-model allows to evaluate trade-offs among alternative architectures. For example, one may want to consider the trade-off betweendifferent communication styles or between different deployment strategies.

4.1 Example Description

The example presents a distributed systems composed of three different components: (1) a client,(2) a server, and (3) a database. The server offers a lot of services that rely on data extracted fromthe database. The client issues requests for services, determining the usage profile. Communi-cation among components occurs through well-defined interfaces. We presume to have severalinstances of the client component that access the server in parallel. More precisely, the client iscomposed of two distinct software components: a Graphical User Interface (GUI) and a DataRetriever that is in charge of retrieving data requested by the users accessing the remote server.Similarly, the server is composed of two software components: a Data Service and a DatabaseManager. The former component is in charge of providing a structured API to access data to theclients. The latter one is in charge of efficiently fetching data from the database, pooling databaseconnections, and caching data.

We have chosen this simple example for two reasons. First, a complex example would shiftour focus from the meta-model characteristics to details. We want to keep things simple andfocus on the important aspects of the method first while abstracting from technical issues. Second,this simple architecture represents the basic structure of many real-world applications. Indeed,the given example contains some aspects which make it a typical example of a classical businessinformation system, in which a three layered architecture is adopted to achieve a decoupling of thepresentation and data layers. The example application is shown by a component diagram in figure4.1.

A reference implementation has been created. The stored data are simple data records con-taining information about users of the system consisting only of a name (surname and first name)and an user ID. The example uses up-to-date component and service oriented technologies for theimplementation. The client and the middle-tier are based on the JavaEE technology running on theGlassfish open-source application server from Sun. The database can be any relational databasefor which a JDBC connector exists; here, the example uses a MySQL database. The data is readfrom and written to the database using JavaEE’s own OR-mapping mechanism called JPA (JavaPersistence API). It requires the database connection to be set up in the application server as aJTA (Java Transaction API) resource. The communication between a client and the server can ei-




Figure 4.1: Example Structure

ther use the JavaEE native communication mechanism based on RMI or it may use a Web-servicebinding of the interface, which would be more common for Service-Oriented Architectures (SOA).A web service invocation is performed via an RPC that embodies a client-server interaction overopen, free, and readily available technologies. For example, the request and response are encoded(marshalled) in XML using the Simple Object Access Protocol (SOAP), service descriptions areencoded in XML using the Web Services Definition Language (WSDL); SOAP may be imple-mented over any transport protocol, but HTTP is used here as it is the most common one.

In the following, we model the example incrementally pointing out various features that theQ-ImPrESS meta-model offers to software engineers. This section is structured as follows: First,we model the static structure of the architecture. Second, we model the behaviour of the systemconsidering its operations and messages taking into account two different communication styles.Finally, we model two alternative scenarios.

4.2 Structural Description

The architecture is represented by the ServiceArchitectureModel class that is a part of thesamm::staticstructure package. The ServiceArchitectureModel has a list of services and inher-its from the parent class CompositeStructure the subcomponents property. We use the former oneto model the service provided by the server and the database, while the latter one is used to modelthe client component. The client and the server are composite components since each of them iscomposed of two elementary components. In order to model this structure, the CompositeCompo-nent is realizedBy SubcomponentInstances representing the server and the client. Similarly, boththe server and client are composite components realized by other subcomponent instances thatrepresent their internal components. On the other hand, each SubcomponentInstance is associatedto a ComponentType through the relation realizedBy; ComponentTypes will be described later onfor modelling behaviour and connections among components. Since the database consists of a sin-gle component, the associated Service class is composed of a single SubcomponentInstance. Theobject diagram in figure 4.2 depicts the model as described above.

The entities defined until now allow us to model the static structure of our example architecturewith all the components in isolation; however, we still have to model the connections among the




Figure 4.2: Model Structure

different parts of our architecture. Every primitive component is also characterized by provided andrequired interfaces. In our example, since the client requires a service from the server, it is charac-terized by a required interface. Conversely, the server component Data Service provides this inter-face. At the same time, the server requires data, through a required interface, from the database,which exposes a provided interface. Also, the connections among the primitive components ofa composite component are obviously characterized by interfaces. These concepts are modelledthrough the entities InterfacePorts and their associated Interfaces. For example, the database prim-itive component is associated to an interface port through its inherited property provided. A com-plete model contains not only the components with their provided and required interfaces but alsothe connections among them. Consequently, it is necessary to connect components through Con-nectors. The property endpoints of every Connector specifies the SubcomponentEndpoints thatassociate PrimitiveComponents to the InterfacePorts involved in the connection. Moreover, eachInterfacePort specifies its associated Interface through the type property. The object diagram infigure 4.3 shows the connection among the database and the server component.

4.3 Behavioural Description

Let us now refine our example in order to enrich the model. Suppose that the stored data consistsof simple data records containing information about users of a system such as their name (surnameand forename) and user IDs and suppose that the server provides a service for fetching data related




Figure 4.3: Connector Example

to a user given its ID via the Whois operation. In this scenario, the PrimitiveComponent entityrepresenting our server, which inherits from the ComponentType entity, needs to be associated to aBehaviour class. This class is a part of the samm::behaviour that specifies a behaviour meta-modelfor services. A Behaviour object is characterized by several Operations (by one, in our case) and itis associated to the interface that provides or requires it. In our scenario, the interface required bythe client and the interface provided by the server share the same behaviour. The object diagramin figure 4.4 illustrates this scenario.

The Q-ImPrESS meta-model allows a fine-grained description of the operations. Indeed, eachof them can be associated with Messages and Exceptions, as defined in the samm::staticstructurepackage defining their inputs and outputs. Adding again the details to our model, we can introduceParameters and Types for each corresponding message. Figure 4.5 shows these concepts for theWhois operation. The same characterization can be made for the other operations as well.

Modelling systems, as illustrated in this section, helps software engineers to evaluate trade-off between alternative architectures when designing complex applications. Indeed, the architec-ture can be changed at design time with respect to certain scenarios and then evaluated using theQ-ImPrESS method and tools. Until now, we have shown the Whois operation that is a simplequery method fetching data from the database. Let us suppose that we want to compare it withan alternative involving another communication style implemented by a different operation: theWhoare operation performs mass queries (i.e., it takes a list of IDs as the input and returns a listof user data). In this scenario, the software architect can construct another model representing thealternative architectural option and can compare the predicted quality attribute with respect to a




Figure 4.4: Behavior and Operations

given metric of interest (e.g., generated network traffic) by means of the Q-ImPrESS tools. Com-paring the results obtained for the two alternatives provides valuable insights towards choosing anoptimal architecture.

4.4 Deployment Description

We can further refine our model by introducing system deployment aspects. In our example, asstated before, there are multiple clients accessing the services offered by the server in parallel.Our server is not only in charge to serve requests issued by clients but it also has to meet thedesired performance in terms of response time. Consequently, the deployment configuration andthe hardware characteristics are of key interest. Indeed, by comparing alternative scenarios, it ispossible to have insights into the choice between (1) using a single expensive machine hosting boththe sever and the database (minimizing network costs and latencies) or (2) using two less expensive




Figure 4.5: Messages, Parameters, and Types

machines that host separately the server and the database (savings with respect to hardware costsat the expense of increased network latency due to communication between the two components).Let us now show how it is possible to model a node and its hardware resources using our example.More precisely, we will model the node on which we want to deploy the server component.

First of all, it is necessary to introduce the TargetEnvironment entity defined in thesamm::deployment::targetenvironment package that represents the execution environment of a Ser-vice Architecture Model. The TargetEnvironment consists of multiple (physical) Nodes (we modelonly the node that hosts the server component now). Each Node contains hardware resources thancan be shared among multiple (logical) Containers. The Container entity represents a place towhich a service is deployed utilizing the hardware installed on the Node. In our case we onlymodel one container representing the J2EE application server that runs our server component. TheTargetEnvironment is associated to a set of ExecutionResources characterizing its nodes. In thiscase, as illustrated in figure 4.6, there are two disks for permanent storage, a processor, a memory,and a network interface.

4.5 Conclusion

The fine grained modelling allowed by the Q-ImPrESS meta-model enable us to represent systemsconsidering all the details (when needed) and, at the same time, abstracting from non-useful techni-calities (for example being technologically independent when it comes to hardware resources). Theexample presented in this section shows how it is possible to model simple services and compo-nents considering different aspects (e.g., their structure, behaviour, and hardware characterization)in order to support architectural reasoning and trade-off analyses in early design phases, in par-ticular with respect to non-functional requirements. We have shown the main characteristics andfeatures currently developed in the Q-ImPrESS meta-model applied to a simple representing thebasic structure of many existing Web-based distributed systems.




Figure 4.6: Deployment Example




5 Mappings of Other Meta-ModelsThis chapter presents mappings between the Service Architecture Meta-Model and meta-models

of particular partners. There are two reasons for having these mappings: First, the mapping fromService Architecture Meta-Model to meta-models of the partners is a necessary prerequisite forimplementation of tools transforming instances of Service Architecture Meta-Model into modelsof particular partners (instances of their respective meta-models). Second, mappings in the otherdirection shows the completeness of the Service Architecture Meta-Model in the sense that it sup-ports modelling of all features that are necessary in the models of the partners.

5.1 PCM

Rationale

The Palladio Component Model (PCM) is a software component model focusing on model-drivenquality-of-service (QoS), i.e., performance and reliability, predictions. The main goal of PCM isto assess the expected response times, throughput, and resource utilization of component-basedsoftware architectures during early development stages. The two key features of PCM are: (i)parametrized component QoS specification and (ii) a developer role concept.

Components in PCM are grey-boxes with contractually specified interfaces and specificationof particular methods’ behaviour in the form of Service Effect Specification (SEFF). They can becomposed together via their roles thus forming composite structures.

The mapping between the Service Architecture Meta-Model and the PCM meta-model arestraightforward as illustrated in the following tables.

Mapping of SAMM to PCM

SAMM PCMBehaviour packageBehaviour covered by ServiceEffectSpecification and RD-SEFFComponentTypeBehaviour N/AOperationBehaviour ServiceEffectSpecification, extended as RD-SEFF

Deployment packageService Allocation ContextCache N/AContainer ResourceEnvironmentExecutionResource N/AHardwareDescriptor ProcessingResourceSpecification




HardwareDescriptorRepository ResourceRepositoryMemory N/AMemoryDescriptor N/AMemoryResource N/ANetworkElement N/ANetworkElementDescriptor N/ANetworkInterface N/ANetworkInterfaceDescriptor N/ANetworkResource CommunicationLinkResourceSpecification (partially)Node ResourceContainerPassiveResource PassiveResource (partially)Processor ProcessingResourceTypeProcessorCore N/AProcessorDescriptor N/ASchedulingPolicy SchedulingPolicyStorageDevice ProcessingResourceTypeStorageDeviceDescriptor ProcessingResourceSpecificationStorageResource N/ATargetEnvironment ResourceEnvironmentTLB N/A

Static packageCollectionDataType CollectionDataTypeComplexDataType CompositeDataTypeComponentEndpoint No class exists for this (not necessary as only strongly

distinguished connectors (assembly/deleagtion) exist)ComponentType CompleteComponentTypeCompositeComponent CompositeComponentCompositeStructure ComposedStructureConnector AssemblyConnector/DelegationConnectorEndPoint for AssemblyConnector: Association; for Assembly-

Context: RequiredRole and ProvidedRoleEntity EntityEventPort N/AInnerElement InnerDeclarationInterface InterfaceInterfacePort ProvidedRole/RequiredRoleMessageType Parameter/association returnType of Signature (only

one return allowed in PCM)NamedEntity NamedElement




Operation SignatureOperationException ExceptionTypeParameter ParameterPrimitiveComponent BasicComponentPrimitiveDataType PrimitiveDataTypeRepository Repository (partially)ServiceArchitectureModel SystemSubcomponentEndpoint Connectors are directly associating Roles and Assem-

blyContextSubcomponentInstance AssemblyContextType DataTypeXSDPrimitiveDataType PrimitiveTypeEnum

Mapping of PCM to SAMM

PCM SAMMAllocation ServiceArchitectureModelAllocation Context ServiceAssemblyConnector ConnectorAssemblyContext SubcomponentInstanceBasicComponent PrimitiveComponentCollectionDataType CollectionDataTypeCommunicationLinkResourceSpecification bandwidth in NetworkResourceCompleteComponentType ComponentTypeComposedProvidingRequiringEntity N/AComposedStructure CompositeStructureCompositeComponent CompositeComponentCompositeDataType ComplexDataTypeConnector ConnectorDataType TypeDelegationConnector ConnectorEntity EntityExceptionType OperationExceptionExternalCallAction SimpleStatementInnerDeclaration InnerElementInterface InterfaceInterfaceProvidingRequirungEntity N/ANamedElement NamedEntityParameter Parameter




PassiveResource PassiveResourcePrimitiveDataType PrimitiveDataTypePrimitiveTypeEnum XSDPrimitiveDataTypeProcessingResourceSpecification HardwareDescriptorProcessingResourceType Processor, Memory, DiskProvidedDelegationConnector ConnectorProvidedRole InterfacePortReleaseAction SimpleStatementRepository Repository (partially)RequiredDelegationConnector ConnectorRequiredRole InterfacePortResourceContainer NodeResourceDemandingBehaviour OperationBehaviourResourceEnvironment TargetEnvironmentResourceRepository TargetEnvironmentResourceType N/A (several more concrete types such as

Disk, Memory, etc.)Role InterfacePortServiceEffectSpecification BehaviourSignature OperationSystem ServiceArchitectureModel




5.2 SOFA 2

Rationale

SOFA 2 is a component system employing hierarchically composed components with aspect ori-ented controllers, behaviour specification using Behavior Protocols, automatically generated con-nectors supporting seamless and transparent distribution of applications, and distributed runtimeenvironment with dynamic update of components. SOFA 2 provides a complete framework sup-porting all the stages of an application life cycle from development to execution.

Documentation, download, examples, etc. are available at SOFA 2 website http://sofa.ow2.org/.

Mappings between SAMM and SOFA 2 are quite straightforward (many times only differentnames of elements with the same meaning). The significant differences are as follows.

• SOFA 2 uses native type system for defining signatures of interfaces’ methods (in the currentimplementation Java types)

• SOFA 2 separates a component definition into two elements — the Frame and Architecture.The Frame defines provided and required ports while the architecture defines implementation(either primitive or composite). I.e. a frame may be realized by several architectures.

• SOFA 2 explicitly uses connectors with communication style.

• SOFA 2 separates component design and assembly (it separates component implementationand component assembly).

• SOFA 2 does not explicitly model resource environment yet (it is planned to directly reusethe SAMM resource environment definition).

Mapping of SAMM to SOFA 2

SAMM SOFA 2Behaviour packageBehaviour covered by BehaviorComponentTypeBehaviour BehaviorOperationBehaviour N/A

Deployment packageNode DeploymentDock (not yet explicitly described by a

meta-model)Service DeploymentPlan/InstanceDeploymentDescription


http://sofa.ow2.org/

http://sofa.ow2.org/



Static packageCollectionDataType native type (see Rationale)ComplexDataType native typeComponentEndpoint ComponentInterfaceEndpointComponentType Architecture (and Frame) (the Frame and Architec-

ture are separated classes tied via association; theFrame describes component ports while Architecturedescribes component implementation)

CompositeComponent ArchitectureCompositeStructure N/AConnector ConnectionEndPoint ConnectionEndpointEntity N/A (the top-level element in SOFA 2 is NamedEntity)EventPort Interface with communication style set to messagingException native typeInnerElement native typeInterface InterfaceTypeInterfacePort Interface with communication style set to procedure

callMessageType InterfaceTypeNamedEntity NamedEntityOperation native typeParameter native typePrimitiveComponent Architecture (without any subcomponent)PrimitiveDataType native typeRepository RepositoryServiceArchitectureModel Architecture/AssemblyDescriptorSubcomponentEndpoint SubcomponentInterfaceEndpointSubcomponentInstance SubcomponentInstanceType native typeXSDPrimitiveDataType native type




Mapping of SOFA 2 to SAMM

SOFA 2 SAMM

NamedEntity NamedEntityVersionedEntity N/A (can be emulated by adding suffixes to the entity

namesFrame ComponentTypeArchitecture ComponentType (Frame and Architecture are merged

into ComponentTypeInterface InterfacePort or EventPort (depending on the commu-

nication style)InterfaceType Interface or MessageType (depending on the commu-

nication style)Connection ConnectorComponentInterfaceEndpoint ComponentEndpointConnectionEndpoint EndPointSubcomponentInterfaceEndpoint SubcomponentEndpointSubcomponentInstance SubcomponentInstanceBehavior ComponentTypeBehaviourProperty N/A (can be emulated by a get/set attribute provided

port)Feature N/ARepository Repository

AssemblyDescriptor ServiceArchitectureModelDeploymentPlan ServiceArchitectureModel/Service




5.3 ProgressCM

Rationale

ProgressCM [5] is a component model aimed at the design of embedded and real-time systemsmainly from the area of automotive, automation and telecom systems. Its based on its predecessorSaveCCM [12], however it adds support for system-level design. ProgressCM has been devel-oped within the PROGRESS Centre for Predictable Embedded Software Systems as the centralcomponent model unifying design, analysis and synthesis techniques.

ProgressCM is designed as a two-level model. On the higher level (called ProSys) it allowsmodelling components as active units communicating with one another by asynchronous messag-ing using explicit message channels. On the lower level (called ProSave) it allows for modellingcontrol logic. Components on this level are reactive functional blocks and the coordination amongthem is explicitly modelled by a set of special connectors (e.g. fork, join, selection, etc.). In con-trast to ProSys which makes only data-flow explicit, ProSave explicitly models both the control-and the data-flow.

ProgressCM maps relatively well to SAMM. The main issue is that ProgressCM is a two-levelmodel while SAMM does not have this disctinction. This is addressed by mapping only betweenSAMM and ProSys (the higher level of ProgressCM). The lower level of ProgressCM (ProSave)is viewed as a one of the behavior formalisms since it explicitly captures control-flows.

Components in ProSys are units with their own activity (threads) and as such they correspondto SAMM components very well, the most significant differences are the following:

• SAMM considers both procedure call and messaging as communication styles. Being domain-specific, ProgressCM restricts communication of ProSys components to messaging only.

• ProgressCM uses C-types for defining signatures of interfaces’ methods.

• Being work-in-progress, ProgressCM does not model deployment and resource environmentyet.

• ProgressCM natively relies on a distributed type of repository and thus it lacks a centralrepository node (class Repository) as it is in SAMM.

Mapping of SAMM to ProgressCM

SAMM ProgressCMBehaviour packageBehaviour Attribute (behavior is modeled as one of the compo-

nent attributes in ProgressCM)

Deployment package




Node virtual node (not yet explicitly described by the meta-model)

Service component allocation to virtual nodes (not yet explic-itly described by the meta-model)

Static packageCollectionDataType as described in Rationale, ProgressCM uses “native”

types for methods parameters, i.e. C-types in the cur-rent version.

ComplexDataType native typeComponentEndpoint ConnectionComponentType SubsystemCompositeComponent CompositeSubsystemCompositeStructure CompositeSubsystemConnector MessageChannelEndPoint ConnectionEntity this is an abstract class unnecessary in ProgressCMEventPort InputMessagePort or OutputMessagePort depending

on the isSource attributeException native typeInnerElement native typeInterface as mentioned in Rationale, ProgressCM intentionally

supports only messagingInterfacePort as mentioned in Rationale, ProgressCM intentionally

supports only messagingMessageType the type of message type is defined in attribute type of

class MessagePortNamedEntity this is an abstract class unnecessary in ProgressCMOperation native typeParameter native typePrimitiveComponent ProSaveSubsystem (this is a component specified in

ProSave, it is planned to support also componentsspecified directly by code)

PrimitiveDataType native typeRepository as mentioned in Rationale, ProgressCM uses a differ-

ent format of a repository which does not require acentral Repository class

ServiceArchitectureModel a deployed SubsystemSubcomponentEndpoint ConnectionSubcomponentInstance SubsystemInstance




Type native typeXSDPrimitiveDataType native type

Mapping of ProgressCM to SAMM

ProgressCM SAMM

Subsystem ComponentTypeSubsystemRealization ComponentType (Subsystem and its realization are

merged into ComponentTypeInputMessagePort and OutputMes-sagePort

EventPort (the direction is specified in attribute is-Source)

CompositeSubsystem CompositeComponentSubsystemInstance SubcomponentInstanceMessageChannel ConnectorConnection EndPoint (In ProgressCM the Connection represents

the relation between a MessageChannel and a port,while in SAMM the EndPoint is owned by Connec-tor. These two are however equivalent approaches tothe same.)




5.4 KLAPER

Rationale

KLAPER (Kernel LAnguage for PErformance and Reliability analysis) is an intermediate lan-guage whose goal is to support the generation of stochastic models for the predictive analysis ofperformance and reliability, starting from the design-level model of a component-based softwaresystem. This intermediate language, specified through a MOF meta-model, is based on an abstractnotion of Resource, which can be used to model both application level components, platform leveldevices. Resources, which offer Services that may require in turn other services, are composedthrough a client/server-like composition with both synchronous and asynchronous interactions. AKLAPER model is derived from a design-level model (by means of transformation rules), to makeperformance or reliability predictions, independently of the availability of an implementation ofthe application itself (which anyway is be useful to parameterize the model). Since deploymentinformation could not be known at early design stage, a KLAPER model can be built without usingthis information and can then be incrementally updated once this information is made available.

The mappings between Service Architecture Meta-Model and KLAPER meta-model are illus-trated in the following tables. We point out that, due to the high abstraction level of KLAPERseveral SAMM concepts will be mapped onto the KLAPER Resource primitive.

Mapping of SAMM to KLAPER

SAMM KLAPERBehaviour packageBehaviour Behavior

Deployment packageService ResourceCache ResourceContainer ResourceExecutionResource ResourceHardwareDescriptor Descriptor attribute of Resource/Service MetaclassesHardwareDescriptorRepository N/AMemory N/AMemoryDescriptor partially covered by attributes of ResourceMemoryResource ResourceNetworkElement ResourceNetworkElementDescriptor partially covered by attributes of ResourceNetworkInterface ServiceNetworkInterfaceDescriptor partially covered by attributes of ResourceNetworkResource Resource




Node ResourcePassiveResource ResourceProcessor ResourceProcessorCore ResourceProcessorDescriptor partially covered by attributes of ResourceSchedulingPolicy Attribute SchedulingPolicy of ResourceStorageDevice ResourceStorageDeviceDescriptor partially covered by attributes of ResourceStorageResource ResourceTargetEnvironment N/ATLB N/A

Static packageCollectionDataType KLAPER relies on Data Type available in MOFComplexDataType KLAPER relies on Data Type available in MOFComponentEndpoint N/AComponentType ResourceCompositeComponent ResourceCompositeStructure N/AConnector BindingEndPoint Call, Signal and Binding associations of Bindings ClassEventPort Wait/ServiceControl (for sink/source event ports, respec-

tively)Exception N/AFirstClassEntity N/AInnerElement N/AInterface N/AInterfacePort Service(only for provided port)MessageType N/ANamedEntity KLAPER relies on NamedElement concept in MOFOperation ServiceParameter ParameterPrimitiveComponent ResourcePrimitiveDataType KLAPER relies on Data Type available in MOFRepository N/AServiceArchitectureModel KLAPER ModelSubcomponentEndpoint N/ASubcomponentInstance ResourceType KLAPER relies on Data Type available in MOFXSDPrimitiveDataType KLAPER relies on Data Type available in MOF




Mapping of KLAPER to SAMM

KLAPER SAMMResource NodeBehavior BehaviorResource ServiceResource CacheResource ContainerResource ExecutionResourceDescriptor attribute of Resource/Service Metaclasses HardwareDescriptorResource MemoryResourceResource Attributes MemoryDescriptorResource Network ElementResource Attributes NetworkElementDescriptorService NetworkInterfaceResource Attributes NetworkInterfaceDescriptorResource Network ResourceResource NodeResource Passive ResourceResource ProcessorResource ProcessorCoreResource Attributes ProcessorDescriptorSchedulingPolicy Attribute of Resource SchedulingPolicyResource StorageDeviceResource Attributes StorageDeviceDescriptorResource StorageResourceResource ComponentTypeResource CompositeComponentBinding ConnectorService InterfacePortService OperationParameter ParameterResource PrimitiveComponentKLAPER Model ServiceArchitectureModelResource SubcomponetInstanceCall association of Binding Class EndpointSignal association of Binding Class EndpointBinding association of Binding Class EndpointWait EventPort (sink)ServiceControl EventPort (source)




6 Low Level Model Description

6.1 Package samm

6.1.1 Package Overview

The package samm contains the essential concepts of the Service Architecture Meta-model. Itis divided into several specialized subpackages. These are: Allocation package focusing on de-ployment and assigning of particular services to computational resources, i.e., nodes, Annotationpackage modelling the way services are annotated with quality annotations, Behaviour packageaiming at modelling internal behaviour of a service on an abstract level, i.e., more abstract than thesource code, Static package describing the basic entities (services, interfaces) of the architecturemodel, their interconnection (ports, endpoints), and ways of communication (messages, events),and Usage Model package focusing on modelling the usage of a service using, e.g., a user profilefor a service.

Note: This package does not contain any classes. Please see the contained sub-packages forclasses.

6.2 Package samm::annotation


The annotation package includes means for annotating the service with quality attributes as wellas with attributes specifying the usage of node resources the service needs for its execution.

6.2.2 Detailed Class Documentation

6.2.2.1 Class AnnotationOverview The Annotation entity represents abstract base class for model annotations.

6.3 Package samm::behaviour


The behaviour package specifies a behaviour meta-model for services. Since the aim is to supportmany different behaviour models to allow reasoning about various behavioural aspects, a generalbehaviour meta-model is defined that has to be specialized by particular behavioural meta-modelsvia inheritance.




6.3.2 Models

Please see figure 6.1 for an overview on this package.

Figure 6.1: Overview of the Classes in the Behaviour Package


6.3.3.1 Class BehaviourOverview This entity models the behaviour of a service. This behaviour model can be used forreasoning about substitutability of services as well as about prediction of quality aspects.

6.3.3.2 Class ComponentTypeBehaviourOverview This entity models a behaviour of a service which is not specific to an operation, butto the component in general.

Parent Classes

• Behaviour (see section 6.3.3.1 on page 45)

6.3.3.3 Class OperationBehaviourOverview This entity models an operation-specific behaviour of a service.

Class Properties Class OperationBehaviour has the following properties:




operation : OperationThis property refers to the operation this behaviour belongs to. The operation has to bea part of provided operations of the implementing component.

Parent Classes

• Behaviour (see section 6.3.3.1 on page 45)

6.4 Package samm::core


The core package contains general meta-model elements such as Entity.


6.4.2.1 Class EntityOverview This abstract class is a super class for all entities within the static package. It containsa unique id to differentiate among different derived model entities.

Class Properties Class Entity has the following properties:

documentation : StringThis property holds an optional documentation of this Entity.

id : StringThis attribute represents the unique id of the entity.

6.4.2.2 Class NamedEntityOverview This abstract class is the super class for all architecture entities that need to be referredby name.

Class Properties Class NamedEntity has the following properties:

name : StringRepresents the name of the named entity.

Parent Classes

• Entity (see section 6.4.2.1 on page 46)




6.5 Package samm::datatypes


The datatypes package contains entities to model data types, such as primitive data types andcomplex data types and their internals.


6.5.2.1 Class CollectionDataTypeOverview The CollectionDataType defines collections of elements of the same type.

Class Properties Class CollectionDataType has the following properties:

innertype : TypeThis property defines the type of the collection members.

Parent Classes

• Type (see section 6.5.2.5 on page 48)

6.5.2.2 Class ComplexDataTypeOverview The ComplexDataType entity defines complex data structures containing several itemsof various types. These structures are similar to constructs like structs or records from high-levelprogramming languages.

Class Properties Class ComplexDataType has the following properties:

elements : InnerElement [0..∗]This property defines members of an instance of ComplexDataType.

Parent Classes


6.5.2.3 Class InnerElementOverview This entity represents an item of a ComplexDataType.

Class Properties Class InnerElement has the following properties:

type : TypeThis property represents the type of the InnerElement.




Parent Classes

• NamedEntity (see section 6.4.2.2 on page 46)

6.5.2.4 Class PrimitiveDataTypeOverview The entity PrimitiveDataType specifies the basic data types, such as integers, strings,floats, date, time, and boolean.

Class Properties Class PrimitiveDataType has the following properties:

type : XSDPrimitiveDataTypes [0..1]This property specifies the XSD Primitive Data type to which this PrimitiveDataTypeis mapped.

Parent Classes


6.5.2.5 Class TypeOverview This entity represents the data type for message parameters.

Parent Classes


6.6 Package samm::deployment


The deployment package serves as a place holder for three subpackages related to modelling ofenvironment into which the services are deployed and in which they are executed. The Allocationpackage contains part of the metamodel responsible for capturing the allocation of Services toContainers. The Hardware subpackage contains hardware descriptors common for a particularinstance of the metamodel, and finally the TargetEnvironment subpackage contains the part ofthe metamodel capturing the target environment consisting of (networked) physical computationalNodes hosting the Containers into which services are deployed.





6.7 Package samm::deployment::allocation


The Allocation package focuses on modelling assignment of particular services to containers pro-vided by computational nodes. The nodes are interconnected via a network thus enabling theservices to be used by clients as well as by other services.

6.7.2 Models


Figure 6.2: Overview of the Classes in the Allocation Package


6.7.3.1 Class ServiceOverview The service entity represents a basic building unit of the service-oriented architecture.A service is a composite structure realized by a deployed component providing resp. requiringfunctionality through its provided ports to resp. from other services.

Class Properties Class Service has the following properties:

component : ComponentTypeThe component property identifies the ComponentType, whose instance actually real-izes (implements) the Service.

container : ContainerThis property determines the container on which the Service is allocated and executed.The component exploits the resources (e.g., CPU, disk, or memory) of the container.




isBlackBox : BooleanThis derived attribute specifies whether the internal structure of the Service is visible.For those Services which have the isBlackBox property set to true, no information onthe internal structure is available.

Constraints

isBlackBox:

self.subcomponents ->size() = 0

Parent Classes

• CompositeStructure (see section 6.10.3.4 on page 68)

6.8 Package samm::deployment::hardware


The Hardware package focuses on modelling properties of physical hardware that are common tomultiple instances of hardware devices in computational nodes.

6.8.2 Models

Please see figure 6.3 for an overview on the hardware descriptors hierarchy. Please see figure 6.4for an overview on the Processor entity.


6.8.3.1 Class CacheOverview The Cache entity represents a processor cache. It captures the level on which the cacheoperates in cache hierarchy, its size and associativity, size of the cache line and access latency. Eachcache can be available to one or more ProcessorCores. The Cache entity allows describing typicalcaches, such as instruction or data (or unified) caches, but is unsuitable for capturing caches suchas the Pentium 4 trace cache.

Class Properties Class Cache has the following properties:




Figure 6.3: Overview of the hardware descriptors hierarchy.

accessLatency : UnlimitedNaturalCache access latency expressed in number of clocks of the processor. The access la-tency of higher-level caches represents the miss penalty for lower-level (closer to pro-cessor) caches. The memory access latency represents the miss penalty for the highest-level cache.

associativity : UnlimitedNaturalDegree of cache associativity, possibly in powers of 2. Value of 1 indicates a direct-mapped cache, value of (cacheSize / cacheLineSize) indicates a fully associative cache.Values between those extremes indicate the degree of associativity. Other values areconsidered invalid.

cacheLineSize : UnlimitedNaturalSize of the cache line, in bytes.

cores : ProcessorCore [1..∗]Collection of processor cores sharing a particular cache.

kind : CacheKindThe kind of contents stored by this cache.

level : UnlimitedNaturalThe level at which the cache operates in the cache hierarchy.

size : UnlimitedNaturalSize of the cache, in bytes.

6.8.3.2 Class HardwareDescriptorOverview The HardwareDescriptor abstract class is a common ancestor for all kinds of hardwaredescriptors. It provides all derived entities with a common attribute containing a human-readable




Figure 6.4: Overview of the Classes related to the Processor entity.

description of particular kind of hardware. The description typically consists of vendor name,model, type, etc. All entities derived from this abstract class are owned by the HardwareDescrip-torRepository entity. The HardwareDescriptor class also extends the top-level Entity class to makeall derived classes identifiable entities.

Class Properties Class HardwareDescriptor has the following properties:

description : StringDescription of the hardware, typically the vendor name, type, model, etc.

Parent Classes


6.8.3.3 Class HardwareDescriptorRepositoryOverview The HardwareDescriptorRepository entity represents a container for all kinds of hard-ware descriptors.

Class Properties Class HardwareDescriptorRepository has the following properties:

descriptors : HardwareDescriptor [0..∗]Hardware descriptors contained within the repository.




6.8.3.4 Class MemoryDescriptorOverview The MemoryDescriptor entity captures the essential properties of different types ofmemory, such as DRAM or SRAM.

Class Properties Class MemoryDescriptor has the following properties:

accessLatency : UnlimitedNaturalAccess latency expressed in number of (Front Side Bus) clocks. The memory accesslatency basically represents the miss penalty for the last level of caches.

bandwidth : UnlimitedNaturalMemory bandwidth, in bytes per second.

burstLength : UnlimitedNaturalThe maximum amount of data that can be transferred during a single memory transac-tion, in bytes.

fsbFrequency : UnlimitedNaturalFrequency of the Front Side Bus, in Hertz.

Parent Classes

• HardwareDescriptor (see section 6.8.3.2 on page 51) ,

• HardwareDescriptor (see section 6.8.3.2 on page 51)

6.8.3.5 Class NetworkElementDescriptorOverview The NetworkElementDescriptor entity captures the common properties of an activenetwork element such as router or switch, such as aggregate bandwidth the device provides andforwarding latency between individual ports, be it routed or switched traffic.

Class Properties Class NetworkElementDescriptor has the following properties:

aggregateBandwidth : UnlimitedNaturalBandwidth of the interconnect in bits per second.

forwardingLatency : EDoubleAverage latency of the interconnect, in seconds.

Parent Classes






6.8.3.6 Class NetworkInterfaceDescriptorOverview The NetworkInterfaceDescriptor entity captures the essential properties of differenttypes of network interfaces.

Class Properties Class NetworkInterfaceDescriptor has the following properties:

linkLatency : EDoubleLatency of the network, in seconds. The latency is primarily determined by the prop-erties of the physical layer and modulation speed.

linkSpeed : UnlimitedNaturalLink speed of the network interface, in bits per second. Determines the maximumtheoretical bandwidth.

Parent Classes



6.8.3.7 Class ProcessorCoreOverview The ProcessorCore entity represents a single core within a processor package. Eachcore has a numeric identifier within the scope of the processor package and a collection of cachesthe core utilizes when executing code.

Class Properties Class ProcessorCore has the following properties:

caches : Cache [0..∗]Lists memory caches representing a cache hierarchy for a particular core.

coreId : UnlimitedNaturalIdentifier an execution core within a processor.

descriptor : ProcessorDescriptorAssociates a processor core with a particular processor.

6.8.3.8 Class ProcessorDescriptorOverview The ProcessorDescriptor entity describes the properties of a physical processor. Thisincludes the execution cores, caches and cache hierarchy, and sharing of caches among executioncores. It does not, however, represent a physical instance of a processor installed on a Node intarget environment. Note that clock frequency is not part of this description, rather it is an attributeof Processor instance installed on a node.




Class Properties Class ProcessorDescriptor has the following properties:

caches : Cache [0..∗]A collection of memory caches the processor is equipped with. Simpler processor forembedded devices may actually have no cache.

cores : ProcessorCore [1..∗]Lists processor cores of a particular processor. Each processor must have at least oneprocessor core.

tlbs : TLB [0..∗]Translation Lookaside Buffers the processor is equipped with. Simple processors forembedded devices without virtual memory support will typically have no TLBs.

Parent Classes



6.8.3.9 Class StorageDeviceDescriptorOverview The StorageDeviceDescriptor entity captures the properties of a physical disk or otherstorage devices. In case of network-based storage, the speeds and latencies should account for theproperties of the (dedicated) transport fabric.

Class Properties Class StorageDeviceDescriptor has the following properties:

cacheSize : UnlimitedNaturalSize of the disk cache, in bytes. Disk caches exhibit low hit-after-read or hit-after-writeratio, but high hit ratio of yet unread data that have been fetched into the cache by thedisk read-ahead mechanism (during sequential read).

readSpeed : UnlimitedNaturalAverage read speed, in bytes per second. For single disk and random requests, this isin tens of megabytes per second. For cached requests, this may correspond to the linkspeed of the interface, but I assume that averages are sufficient.

requestLatency : EDoubleThe average latency before the disk starts to serve a particular request, in seconds. Theservice time, however, is determined by the latency and the time it takes to transfer thedata of the request.

writeSpeed : UnlimitedNaturalAverage write speed, in bytes per second. Even though most contemporary disks sup-port write caching, but this is a dangerous feature (unless the cache is battery backed)and is typically turned off.




Parent Classes



6.8.3.10 Class TLBOverview The TLB entity represents a Translation Lookaside Buffer which is used by the pro-cessor to speed up the translation of virtual addresses to physical.

Class Properties Class TLB has the following properties:

associativity : IntegerAssociativity of the Translation Lookaside Buffer entries.

entriesCount : IntegerThe number of entries in this Translation Lookaside Buffer.

entryPageSize : IntegerThe page size of a TLB entry. This is the value the operating system is expected to usefor majority of purposes.

kind : CacheKindThe kind of data the TLB is used for.

6.9 Package samm::deployment::targetenvironment


The TargetEnvironment package specifies hardware and software resources of nodes used as allo-cation target for Services. It supports modelling of processors, storage devices, network links, andmain memory.

6.9.2 Models



6.9.3.1 Class ContainerOverview The Container entity represents an execution environment utilizing the hardware in-stalled on a Node. Logical resources provided by a Container are backed by physical resources




Figure 6.5: Overview of the Classes in the TargetEnvironment Package

provided by hardware installed on a Node. A Container represents an allocation unit for Services.Each Service is run in one Container, while a single Container may host zero or more Services.

There may be multiple Containers on a single Node and each Container must provide at leastone ExecutionResource which corresponds to a fraction of execution time of at least one proces-sor core. It also has to have at least one MemoryResource representing e.g., main memory, toaccommodate the Services running within the Container. Concerning other resources, a Containermay also provide StorageResources for persistent storage, NetworkResources to provide limitedcommunication bandwidth, and PassiveResources that need not be backed by hardware.

Class Properties Class Container has the following properties:

description : StringOptional human-readable description of the container.

executionResources : ExecutionResource [1..∗]Execution resources provided by a Container.

memoryResources : MemoryResource [1..∗]A collection of memory resources provided by a Container. There must be at least




one such resource, i.e., a Container must have certain amount of memory available forexecuting tasks assigned to it.

networkResources : NetworkResource [0..∗]Network resources provided by a Container.

passiveResources : PassiveResource [0..∗]Passive resources provided by a Container.

schedulingPolicy : SchedulingPolicy [0..1]Optional SchedulingPolicy used by the Container to distribute execution resources.

storageResources : StorageResource [0..∗]Storage resources provided by a Container.

Parent Classes


6.9.3.2 Class ExecutionResourceOverview The ExecutionResource entity represents an execution resource with the granularity ofhardware-supported thread. In modern processors, this typically corresponds to a single processorcore. Each execution resource is backed by a specific processor core. Since a single processor coremay be shared by multiple execution resources, each ExecutionResource must specify the fractionof processor time available to it.

Class Properties Class ExecutionResource has the following properties:

coreId : UnlimitedNaturalIdentifier of the core backing the associated execution resource.

fraction : EDoubleFraction of execution time of the associated processor core alloted to this resource.

processor : ProcessorPhysical Processor backing this ExecutionResource.

6.9.3.3 Class FileSystemPerformanceProfileOverview The FileSystemPerformanceProfile entity represents performance of a specific filesystem on a storage resource. The performance of file operations depends on the performanceof the underlying hardware as well as the performance of the file system code. This annotationallows attaching file system-specific performance information to a particular storage resource.

Class Properties Class FileSystemPerformanceProfile has the following properties:




fileSystem : String [0..1]Optional file system type used to manage the disk space.

storageResource : StorageResourceStorage resource associated with a particular file system performance profile.

Parent Classes

• Annotation (see section 6.2.2.1 on page 44)

6.9.3.4 Class MemoryOverview The Memory entity represents an instance of physical memory in a node. Typically, anode will only have a single physical memory instance, i.e. without attempting to model the mem-ory on the level of individual memory modules. However, embedded devices may have multipleinstances of memory, with different properties.

Class Properties Class Memory has the following properties:

descriptor : MemoryDescriptorReference to MemoryDescriptor capturing the physical attributes of this memory in-stance.

size : UnlimitedNaturalSize of this memory instance, in bytes.

Parent Classes


6.9.3.5 Class MemoryResourceOverview The MemoryResource entity represents a portion of physical memory made availableto tasks running within a Container. Each MemoryResource must be backed by a specific instanceof physical Memory.

Class Properties Class MemoryResource has the following properties:

description : String [0..1]Optional description of the memory resource.

memory : MemoryPhysical Memory backing this MemoryResource.

size : UnlimitedNaturalSize of the memory resource, in bytes. Represents the amount of memory available touser tasks. The overhead of the container itself is not included.




Parent Classes


6.9.3.6 Class NetworkElementOverview The NetworkElement entity represents a physical instance of an active network ele-ment such as switch or router in the target environment. Each element may have zero or moredownlinks, with all elements within the downlink hierarchy representing a single network. Eachelement can also have multiple siblings, with sibling links corresponding to routed links. Thecombination of downlinks and siblings allows creating network topologies consisting of connectedlocal networks. The NetworkElement entity is not expected to represent network devices such ashubs, which are considered obsolete in modern local networks.

Class Properties Class NetworkElement has the following properties:

descriptor : NetworkElementDescriptorReference to NetworkElementDescriptor capturing the common attributes of this Net-workElement.

downlinks : NetworkElement [0..∗]Downlink network elements, typically switches. Such elements allow creating localnetworks where each connected node is directly visible to other nodes.

nodeConnections : NetworkInterface [0..∗]Connections to computational Nodes, through their NetworkInterfaces.

siblings : NetworkElement [0..∗]Sibling network elements, typically routers. Such elements allow connecting localnetworks represented by the hierarchy of network elements connected by downlinkelements.

Parent Classes


6.9.3.7 Class NetworkInterfaceOverview The NetworkInterface represents an instance of physical network interface installedon a node. It references a NetworkInterfaceDescriptor, which provides common physical attributesof the network link. The bandwidth of the interface is associated with the instance, since it maydiffer from the maximal physical bandwidth determined by link speed.

Class Properties Class NetworkInterface has the following properties:




bandwidth : UnlimitedNaturalThe bandwidth of the network interface. The available bandwdith may be lower thanthe bandwidth determined by link speed.

connection : NetworkElementConnection to a network serviced by a particular NetworkElement.

descriptor : NetworkInterfaceDescriptorReference to NetworkInterfaceDescriptor capturing the common attributes of this Net-workInterface.

Parent Classes


6.9.3.8 Class NetworkResourceOverview The NetworkResource entity represents a slice of bandwidth available to a specificNetworkInterface backing the particular NetworkResource. In case of operating systems, this maycorrespond to a network interface, while in case of an application server, this may correspond to aparticular network connection.

Class Properties Class NetworkResource has the following properties:

bandwidth : UnlimitedNaturalBandwidth available to this NetworkResource, in bits per second.

networkInterface : NetworkInterfaceNetworkInterface backing this NetworkResource.

Parent Classes


6.9.3.9 Class NodeOverview The Node entity represents a physical node in the target environment. It containshardware resources such as processor, memory, disk, etc, and hosts execution environments inform of Containers. Each Node must have at least one Processor instance, one Memory instance,and one Container instance. A Node may also have network interfaces and storage devices.

Class Properties Class Node has the following properties:

containers : Container [1..∗]Containers running on a Node to provide execution environment into which servicesmay be deployed.




description : String [0..1]Optional human-readable description of the node.

memories : Memory [1..∗]Memories installed on a Node to provide transient storage for executing containers andtasks within containers.

networkInterfaces : NetworkInterface [0..∗]Physical NetworkInterfaces installed on a node.

processors : Processor [1..∗]Processors installed on a Node to provide computational capabilities.

storageDevices : StorageDevice [0..∗]Physical StorageDevices connected to/installed on a Node.

Parent Classes


6.9.3.10 Class PassiveResourceOverview The PassiveResource abstract class represents logical resources that may be providedby a container. Such resources are not typically bound to hardware, but may be provided e.g., byan operating system or application server.

6.9.3.11 Class ProcessorOverview The Processor entity represents an instance of physical processor package installedon a particular Node. Each physical processor instance must have a name and must refer to thedescriptor of processor features. A physical processor instance should also specify the maximumclock frequency.

Class Properties Class Processor has the following properties:

clockFrequency : UnlimitedNatural [0..1]The maximum clock frequency of the installed processor, in Hertz.

descriptor : ProcessorDescriptorReferences a ProcessorDescriptor entity capturing the architectural properties of theprocessor.

Parent Classes





6.9.3.12 Class SchedulingPolicyOverview The SchedulingPolicy abstract class represents a scheduling policy a particular con-tainer uses to distribute the available execution resources. The policy is determined by the valueof the policyKind attribute. Specific properties needed for particular scheduling policy should beencapsulated within a class extending the SchedulingPolicy class.

Class Properties Class SchedulingPolicy has the following properties:

kind : SchedulingPolicyKindThe kind of SchedulingPolicy.

6.9.3.13 Class SoftwarePerformanceProfileOverview The SoftwarePerformanceProfile entity represents performance of a specific kind ofsoftware on a particular processor. Since different kinds of software may yield different perfor-mance on different processors, this allows associating a number of performance profiles for differ-ent kinds of software with a particular processor type. Besides simple identification of softwarekind, each profile contains a number of attributes expressing how well the software runs on a par-ticular processor. All the attributes are optional, because obtaining such information is non-trivialand not all tools may be interested in it.

Class Properties Class SoftwarePerformanceProfile has the following properties:

clocksPerInstructionAverage : EDouble [0..1]Average number of clocks per instruction.

clocksPerInstructionDistribution : String [0..1]String specification of distribution function of the clocks per instruction metric.

processor : ProcessorDescriptorProcessor associated with a particular software performance profile.

softwareKind : StringThe kind of software for which the profile is valid. This is a free-form string.

tlbMissProbability : EDouble [0..1]The probability of TLB miss, which results in extra memory accesses due to page walk.

Parent Classes

• Annotation (see section 6.2.2.1 on page 44)




6.9.3.14 Class StorageDeviceOverview The StorageDevice entity represents a physical instance of a storage device. Theinstance references StorageDeviceDescriptor, which captures common physical properties of thedevice, such as access latency or read speed. Size of the storage device is not considered commonattribute and is defined by the StorageDevice entity, because it is reasonable to expect that devicesof various sizes may share physical properties.

Class Properties Class StorageDevice has the following properties:

descriptor : StorageDeviceDescriptorReference to descriptor capturing the physical properties of the storage device.

size : UnlimitedNaturalStorage capacity of the installed storage device, in bytes.

Parent Classes


6.9.3.15 Class StorageResourceOverview The StorageResource entity represents a portion of physical persistent storage pro-vided by storage devices. Conceptually it corresponds to a logical volume, which provides con-tiguous addressable persistent storage area.

Class Properties Class StorageResource has the following properties:

description : String [0..1]Optional description of the storage resource.

size : UnlimitedNaturalSize of the storage resource, in bytes.

storageDevices : StorageDevice [1..∗]Storage devices backing the storage resource.

Parent Classes





6.9.3.16 Class TargetEnvironmentOverview The TargetEnvironment represents execution environment containing resources thatcan be used for executing Services. Each TargetEnvironment consists of multiple Nodes, whichcontain hardware resources than can be shared among multiple Containers, which define logicalresources available to Services. A TargetEnvironment may also contain multiple network elementscorresponding to routers and switches.

Class Properties Class TargetEnvironment has the following properties:

description : String [0..1]Optional, human-readable description of the target environment.

networkElements : NetworkElement [0..∗]Network elements found in a target environment.

nodes : Node [0..∗]Hardware Nodes in a particular TargetEnvironment.

Parent Classes


6.10 Package samm::staticstructure


The staticstructure package aims at modelling of the static service architecture, i.e., types andrelations among services, interfaces, and communication links.

6.10.2 Models

Please see figure 6.6 for an overview on this package. In figure 6.7, the hierarchy of entities of thestatic package can be seen.


6.10.3.1 Class ComponentEndpointOverview The ComponentEndpoint entity represents the externally visible part of a connectorthat is to be attached to a component port thus establishing connection among components.

Parent Classes

• EndPoint (see section 6.10.3.6 on page 68)




Figure 6.6: Overview of the Classes in the StaticStructure Package

6.10.3.2 Class ComponentTypeOverview This abstract class represents a type of a component. ComponentType is determinedby two sets of ports—a set of ports provided and a set of ports required by components of this type.It forms also a common superclass for PrimitiveComponent and CompositeComponent.

Class Properties Class ComponentType has the following properties:

OperationBehaviour : OperationBehaviour [0..∗]This property defines the operation-specific behaviour of the ComponentType.

componentTypeBehaviour : ComponentTypeBehaviour [0..1]This property defines the behaviour of the ComponentType, which is not operation-specific.

provided : InterfacePort [0..∗]This property represents a set of provided ports of the ComponentType.

required : InterfacePort [0..∗]This property represents a set of required ports of the ComponentType.

sink : EventPort [0..∗]This property represents a set of sink ports of the ComponentType.




Figure 6.7: The hierarchy of the StaticStructure package entites

source : EventPort [0..∗]This property represents a set of source ports of the ComponentType.

Constraints

HasToProvideOrRequireServices:

provided ->size() + required ->size() >= 1

Parent Classes


6.10.3.3 Class CompositeComponentOverview The CompositeComponent entity is used to model the hierarchical components, i.e.,the components are allowed to be nested, thus forming a tree-like structure.

Parent Classes

• CompositeStructure (see section 6.10.3.4 on page 68) ,

• ComponentType (see section 6.10.3.2 on page 66)




6.10.3.4 Class CompositeStructureOverview This abstract entity represents an entity composed of subcomponents. The ports ofa composite structure are on the inner side connected to ports of its subcomponents using del-egation connectors. The ports of subcomponents may be, in addition, connected via assemblyconnectors to each other. CompositeStructure is a superclass for both CompositeComponent andServiceArchitecturesModel.

Class Properties Class CompositeStructure has the following properties:

connector : Connector [0..∗]This property represents the set of connectors connecting both ports of subcomponentsto each other and ports of subcomponents to ports of this CompositeStructure.

subcomponents : SubcomponentInstance [0..∗]This property represents the subcomponents forming this CompositeStructure.

6.10.3.5 Class ConnectorOverview The Connector entity represents a binding between ports of components to enablecommunication between components. The actual kind of the port (EventPort or InterfacePort)determine the communication style, i.e., either message passing or method invocations.

Class Properties Class Connector has the following properties:

endpoints : EndPoint [0..∗]This property represents the endpoints of the connector, i.e., entities to be attached tocomponent ports.

isDelegation : BooleanThis derived attribute differentiates between two kinds of connectors—assembly con-nectors and delegation connectors. An assembly connector (for which the attribute isset to false) is used for connecting ports of components on the same hierarchy level,while a delegation connector (for which the attribute is set to true) connects ports onadjacent hierarchy levels, i.e., connecting a port of a CompositeStructure with a port ofits subcomponent.

Parent Classes


6.10.3.6 Class EndPointOverview This abstract class represents a part of a connector attachable to a component port toform a (communication) connection between components. It is inherited by ComponentEndpointand SubcomponentEndpoint to realize the assembly and delegation connection, respectively.




Parent Classes• Entity (see section 6.4.2.1 on page 46)

6.10.3.7 Class EventPortOverview This entity represents a component port allowing message-based communication.

Class Properties Class EventPort has the following properties:

isSource : BooleanThis attributes specifies the role of the port—whether it is a source (isSource set totrue) or sink (isSource set to false) port. A source event port represents a required port,while a sink event port represents a provided port.

message : MessageTypeThis property defines the message (type) that mediates the events through this port.

6.10.3.8 Class InterfaceOverview The Interface class represents the interface concept of the SOA. It is the visible part ofa component to which connector endpoints can be attached and which represents the access pointto the component’s functionality.

Class Properties Class Interface has the following properties:

inheritance : Interface [0..∗]This property contains references to interfaces from which this interface is derived.

signatures : Operation [0..∗]This property represents the set of operations the interface consists of.

Parent Classes• NamedEntity (see section 6.4.2.2 on page 46)

6.10.3.9 Class InterfacePortOverview An InterfacePort represents an instance of an interface which allows exploiting thefunctionality of a component via method calls.

Class Properties Class InterfacePort has the following properties:

interfaceType : InterfaceThis property specifies the type of the InterfacePort.

isRequired : BooleanThis attributes specifies the role of the port—whether it is a required (isRequired set totrue) or provided (isRequired set to false) port.




6.10.3.10 Class MessageTypeOverview This entity represents the message type used for data communication. It is modelledaccording to the WSDL Message and it is of either the input (method parameters) or the output(return value) kind.

Class Properties Class MessageType has the following properties:

parameters : Parameter [1..∗]This property contains the parameters contained within this message.

Parent Classes


6.10.3.11 Class OperationOverview This class represents an operation signature, i.e., types of input and output messagesand exceptions that can be thrown by an operation. It is similar to the WSDL Operation.

Class Properties Class Operation has the following properties:

input : MessageType [0..1]This property defines the input of the operation.

output : MessageType [0..1]The property defines the return or output values of the operation.

throwsExceptions : OperationException [0..∗]The property specifies the exceptions that can be thrown during the operation process-ing.

Parent Classes


6.10.3.12 Class OperationExceptionOverview This entity represents an exception that may be thrown by an operation.

Class Properties Class OperationException has the following properties:

ExceptionMessage : StringThis property specifies the error message of the exception.




Parent Classes


6.10.3.13 Class ParameterOverview This class represents the data transmitted within messages, either as input or as outputof the associated operation.

Class Properties Class Parameter has the following properties:

type : TypeThis property defines the type of the message parameter.

6.10.3.14 Class PrimitiveComponentOverview This entity specifies a basic component on the lowest hierarchical level. A primitivecomponent has no subcomponents.

Parent Classes

• ComponentType (see section 6.10.3.2 on page 66)

6.10.3.15 Class RepositoryOverview The Repository entity represents a storage for first class entities that could be reusedand composed into more complex architectures.

Class Properties Class Repository has the following properties:

componenttype : ComponentType [0..∗]interface : Interface [0..∗]messagetype : MessageType [0..∗]type : Type [0..∗]

Parent Classes





6.10.3.16 Class ServiceArchitectureModelOverview This entity is a composite structure representing a service-oriented architecture model.A ServiceArchitectureModel is a set of services connected to form a service architecture (SA). ASA provides and requires services through interfaces. It provides an abstraction level for modellingservices and reasoning about their behaviour. Therefore, all constituents on the first nesting levelhave to be of the service type.

Class Properties Class ServiceArchitectureModel has the following properties:

service : Service [1..∗]The property represents the services that form the service architecture model.

Constraints

OnlyServicesOnTopLevel:

self.subcomponents ->forAll(e|e.realizedBy.oclIsTypeOf(samm::↘→deployment::allocation::Service))

Parent Classes

• CompositeStructure (see section 6.10.3.4 on page 68)

6.10.3.17 Class SubcomponentEndpointOverview This entity represents the externally visible part of a connector that is to be attachedto a port of a subcomponent thus establishing a communication link between the subcomponentand its super component.

Class Properties Class SubcomponentEndpoint has the following properties:

subcomponent : SubcomponentInstanceThis property specifies a subcomponent to which the endpoint belongs.

Parent Classes

• EndPoint (see section 6.10.3.6 on page 68)




6.10.3.18 Class SubcomponentInstanceOverview This entity specifies a subcomponent of a composite structure. Note that this is nota run-time instance of a component, it is an instance in the architectural point of view, i.e., aninstance of a component type inside of a composite structure.

Class Properties Class SubcomponentInstance has the following properties:

realizedBy : ComponentTypeThis property specifies the component type of this subcomponent instance.

Parent Classes


6.11 Package samm::usagemodel


The usagemodel package specifies usage information for monitoring, prediction and simulationpurposes.


6.12 Package gast



6.13 Package gast::accesses


This package contains all access types. Accesses represent relations between program elementslike variable accesses, function calls, and type accesses.





Figure 6.8: Overview of the access hierarchy


6.13.2.1 Class AccessOverview This class is the root of the access hierarchy. Accesses represent relationships betweenprogram elements, like function calls, variable accesses or type references.

Class Properties Class Access has the following properties:

accessedClass : ClassRepresents the class in which the access target is located. If the access target is a classitself it is returned.

accessedTarget : ModelElementRepresents the accessed model element. It is the staticaly derivable model element,which means that polymorphy etc. is not resolved.

surroundingClass : ClassReference to the class in which this access is contained.

surroundingCompositeAccess : CompositeAccess [0..1]If the access is placed in a composite access this is a reference to the surroundingcomposite access.




surroundingFunction : FunctionReference to the function in which this access is contained.

surroundingStatement : StatementReference to the statement, which contains the access.

Parent Classes

• SourceEntity (see section 6.15.2.9 on page 85)

6.13.2.2 Class CastTypeAccessOverview This class represents accesses to types due to a type cast. E. g. in case of (MyClass)var it represents a type access to MyClass.

Parent Classes

• TypeAccess (see section 6.13.2.13 on page 78)

6.13.2.3 Class CompositeAccessOverview This class is a helping construct which represents function type arguments in the caseof function calls. It bundles all accesses in the range of one function argument, e. g. in caseof method call m(a, b+c) for each function argument one composite access is created. The firstcontains a variable access to a, the second contains variable accesses to b and c. This constructenables mapping of accesses to function arguments.

Class Properties Class CompositeAccess has the following properties:

accesses : Access [0..∗]This property represents a collection with references to all contained accesses.

6.13.2.4 Class DeclarationTypeAccessOverview This class models variable and return type declarations.

Class Properties Class DeclarationTypeAccess has the following properties:

surroundingVariable : VariableThis property is a reference to the variable which is declared by this access.

Parent Classes





6.13.2.5 Class DelegateAccessOverview This class represents a special case of a function access. Due to the fact that delegatesare able to act as "multicast call forwarder", delegate accesses can have several target functions.

Class Properties Class DelegateAccess has the following properties:

accessedDelegate : DelegateThis property represents a reference to the delegate which is accessed.

accessedFunctions : Function [0..∗]This property represents a list of possible functions accessed via this delegate access.Due to the dynamics of a delegate an exact list of called functions cannot be given.Thus a conservative approach is taken, that means a list of all possible functions isreturned.

Parent Classes

• FunctionAccess (see section 6.13.2.6 on page 76)

6.13.2.6 Class FunctionAccessOverview This class represents function calls. The usage of operators (for example in C/C++)is modelled as function call as well.

Class Properties Class FunctionAccess has the following properties:

targetFunction : FunctionThis represents the reference to the accessed function.

typeArguments : Type [0..∗]This represents the list of the actual type arguments accessed in case of a generic func-tion call.

Parent Classes

• Access (see section 6.13.2.1 on page 74)

6.13.2.7 Class InheritanceTypeAccessOverview This class represents references to types in the case of inheriting from a class or im-plementing of an interface. Hence the inheritance and interface implementation relationships aremodelled by this class.

Class Properties Class InheritanceTypeAccess has the following properties:




implementationInheritance : EBooleanThe property is true if it is a private or protected inheritance relationship. It is false ifit is a public inheritance relationship.

Parent Classes


6.13.2.8 Class ParameterInstantiationTypeAccessOverview This class models a type access in the case of a type parameter instantiation.

Parent Classes


6.13.2.9 Class RunTimeTypeAccessOverview This class models type identification at runtime, e. g. with "object instanceof Type"(in Java).

Parent Classes


6.13.2.10 Class SelfAccessOverview This class models "this" and "super" accesses.

Class Properties Class SelfAccess has the following properties:

super : EBooleanThis property is true if this access models a "super" access. It is false if it is a "this"access.

Parent Classes

• VariableAccess (see section 6.13.2.14 on page 78)

6.13.2.11 Class StaticTypeAccessOverview This class represents the type access to the class or interface which is used as prefixwhile accessing a static attribute.




Parent Classes


6.13.2.12 Class ThrowTypeAccessOverview This class models throws declarations.

Class Properties Class ThrowTypeAccess has the following properties:

declared : EBooleanThis property shows, whether an exception is declared in a function signature or not.The accessed target is the type of exception.

Parent Classes


6.13.2.13 Class TypeAccessOverview This class is the root class for all type accesses.

Class Properties Class TypeAccess has the following properties:

targetType : TypeThis property represents the reference to the accessed type.

Parent Classes


6.13.2.14 Class VariableAccessOverview This class represents accesses to variables. It can be distinguished between read andwrite access.

Class Properties Class VariableAccess has the following properties:

targetVariable : VariableThis property represents the reference to the accessed variable.

write : EBooleanThis property is true if it is a write access and false if it is a read access.




Parent Classes


6.14 Package gast::annotations


This packages is for model annotations. By implementing the model annotation interfaces arbitraryinformation can be attached to model elements. Some special kinds of annotations are alreadyprovided in this package.


6.14.2.1 Class AttributeOverview This class models class attributes. They are model annotations represented as specialkind of interfaces.

Parent Classes

• Class (see section 6.18.2.2 on page 95) ,

• ModelAnnotation (see section 6.14.2.3 on page 79)

6.14.2.2 Class LayerOverview This class represents layers as special kind of a structural abstraction. Layers area common architectural pattern. By applying appropriate extraction tools layer elements can beexplicitly represented in a model instance.

Parent Classes

• StructuralAbstraction (see section 6.14.2.4 on page 80)

6.14.2.3 Class ModelAnnotationOverview This class provides a way to attach arbitrary classes to model elements for annotationpurposes.




6.14.2.4 Class StructuralAbstractionOverview This class is the supertype for all structural abstractions. It implements the ModelAn-notation interface, thus it can be annotated to arbitrary model elements. Structural abstractionsserve as a way to specify high-level structures in the software system like architectural patternsand styles.

Parent Classes

• NamedModelElement (see section 6.15.2.5 on page 82) ,

• ModelAnnotation (see section 6.14.2.3 on page 79)

6.14.2.5 Class SubsystemOverview This class enables grouping of model elements into subsystems. Subsystem is a moregeneral term for a group of model elements following a certain purpose. It is a special kind ofstructural abstraction.

Parent Classes

• StructuralAbstraction (see section 6.14.2.4 on page 80)

6.15 Package gast::core



6.15.2.1 Class FileOverview This class represents an analysed source file or an assembly file.

Class Properties Class File has the following properties:

assembly : BooleanThis property is true if it is a compiled unit (compiled assembly, JAR file or delphipackage).

globalFunctions : GlobalFunction [0..∗]This property represents a list of all global functions which are directly defined in thisfile.




globalVariables : GlobalVariable [0..∗]This property represents a list of all global variables which are directly defined in thisfile.

importedGlobalFunctions : GlobalFunction [0..∗]This property represents a list of global functions which are directly imported by thisfile.

importedGlobalVariables : GlobalVariable [0..∗]This property represents a list of global variables which are directly imported by thisfile.

importedPackages : Package [0..∗]This property represents a list of packages which are directly imported by this file.

importedTypes : Type [0..∗]This property represents a list of types which are directly imported by this file.

includedFiles : File [0..∗]This property represents a list of files which are directly imported by this file.

linesOfCode : UnlimitedNaturalThis property represents the Number of code lines. (What definiton of the lines of codemetric actually is used depends on the extraction tools, for details please refer to thedocumentation of the extraction tools)

pathName : StringThis property represents the file name of this file in the file system, if possible with afile path.

sourceFile : EBooleanThis property is true if this is source file.

types : Type [0..∗]This property represents a list of all types which are directly defined in this file.

Parent Classes

• ModelElement (see section 6.15.2.3 on page 82)

6.15.2.2 Class GenericEntityOverview This class is the common base for generic function and generic class. Generic entitiescan have a set of type parameters.

Class Properties Class GenericEntity has the following properties:

typeParameters : TypeParameterClass [0..∗]This property represents the type parameters of this generic entity.




Parent Classes


6.15.2.3 Class ModelElementOverview This entity is a super class for all classes which are part of the model. It helps toensure that each model element can be identified by a unique identifier.

Class Properties Class ModelElement has the following properties:

annotations : ModelAnnotation [0..∗]Collection with references to the model annotations annotating this model element.

status : StatusContains the status of the model element. It can contain the following values: "normal"for model elements which are extracted from source code, "library" for model elementswhich are extracted from a library, "implicit" for model elements which are implicitlyspecified in source code and "failed dependency" for model elements which have nodefinition either in source code nor in a library.

uniqueId : UnlimitedNaturalContains the unique identifier of a model element.

6.15.2.4 Class ModelElementRepositoryOverview This class offers model persistency services and manages model elements which arepart of the repository.

Class Properties Class ModelElementRepository has the following properties:

modelElements : ModelElement [0..∗]This property represents a collection which contains all model elements of the model.

root : RootThis property represents a reference to the root element.

6.15.2.5 Class NamedModelElementOverview This entity is a super class for all model elements which have a declared name oridentifier.

Class Properties Class NamedModelElement has the following properties:

simpleName : EStringRepresents the simple name of this model element.




Parent Classes


6.15.2.6 Class PackageOverview This class represents a package or a namespace.

Class Properties Class Package has the following properties:

classes : Class [0..∗]This property represents a list of all classes contained in this package. Does not containclasses which are located in subpackages.

delegates : Delegate [0..∗]This property represents a list of all delegates which are directly defined in this package.

globalFunctions : GlobalFunction [0..∗]This property represents a list of all global functions which are directly defined in thispackage.

globalVariables : GlobalVariable [0..∗]This property represents a list of all global variables which are directly defined in thispackage.

qualifiedName : EStringThis property represents the fully qualified name of this package.

subPackages : Package [0..∗]This property represents a list of all packages which are contained in this package.

surroundingPackage : PackageThis property represents a reference to the surrounding package of this package.

typeAliases : TypeAlias [0..∗]This property represents a list of all type aliases which are directly defined in thispackage.

Parent Classes

• NamedModelElement (see section 6.15.2.5 on page 82)




6.15.2.7 Class PositionOverview This class contains information about the position of a model element within thesource code.

Class Properties Class Position has the following properties:

assembly : File [0..1]This property represents a reference to the object which represents the compiled file inwhich the model element is declared.

endColumn : UnlimitedNaturalThis property represents the end column of the model element in source code.

endLine : UnlimitedNaturalThis property represents the end line of the model element in source code.

sourceFile : File [0..1]This property represents a reference to the object which represents the file in which themodel element is declared.

startColumn : UnlimitedNaturalThis property represents the start column of the model element in source code.

startLine : UnlimitedNaturalThis property represents the start line of the model element in source code.

Constraints

EitherAssemblyFileOrSourceFileSet:

This OCL constraint ensures that either the assembly attribute↘→ or the sourceFile attribute is set.

6.15.2.8 Class RootOverview This class builds the root of the model. From here the navigation to all model elementsis possible.

Class Properties Class Root has the following properties:

clones : Clone [0..∗]This property represents a list of all clones in the system.

files : File [0..∗]This property represents a list of all files in the system.




globalFunctions : GlobalFunction [0..∗]This property represents a list of all global functions in the system.

globalVariables : GlobalVariable [0..∗]This property represents a list of all global variables.

linesOfCode : UnlimitedNaturalThis property represents the number of lines of code within the system.

linesOfComments : UnlimitedNaturalThis property represents the number of lines of comments within the system.

packages : Package [0..∗]This property represents a list of all packages in the system. Packages which are con-tained in other packages are also listed here.

structuralAbstractions : StructuralAbstraction [0..∗]This property represents a list of all structural abstractions.

types : Type [0..∗]This property represents a list of all types defined or used in the system.

Parent Classes


6.15.2.9 Class SourceEntityOverview This entity provides information about whether a model element can be located insource code and provides information about the position.

Class Properties Class SourceEntity has the following properties:

position : Position [0..∗]This property represents the position of this model entity in source code.

Parent Classes


6.16 Package gast::functions


This package contains all classes and interfaces which represent the function hierarchy.Please see figure 6.9 for an overview on this package.




Figure 6.9: Overview of the function hierarchy


6.16.2.1 Class ConstructorOverview This class represents a constructor of class. A constructor is a function which is calledduring the instantiation of a class.

Class Properties Class Constructor has the following properties:

initializer : EBooleanThis property is true if this method represents an initializer.

surroundingClass : ClassThis property represents a reference to the class which this constructor belongs to.

Parent Classes

• Member (see section 6.18.2.4 on page 97) ,

• Function (see section 6.16.2.4 on page 88)

6.16.2.2 Class DelegateOverview This class represents a delegate which is a method to encapsulate one or more functionpointers.




Class Properties Class Delegate has the following properties:

innerDelegate : EBooleanThis property is true if this delegate is an inner class, which means that it is declared inthe context of another class.

invocations : Function [0..∗]This property represents a list of all functions which are called when this delegate iscalled.

superClass : Class [0..1]This property represents a reference to the common, direct super class of all delegates.This is the System.Delegate class, which is a part of the Common Language Infrastruc-ture (CLI), Base Class Library (BCL).

surroundingClass : ClassThis property represents a reference to the surrounding class of this delegate in the caseof an inner delegate. Otherwise it is "null".

surroundingPackage : PackageThis property represents a reference to the package in which this delegate is contained.

Parent Classes

• Type (see section 6.18.2.6 on page 98) ,



6.16.2.3 Class DestructorOverview This class represents a destructor, which is called when an instance of its class is beingdeleted.

Class Properties Class Destructor has the following properties:

surroundingClass : ClassThis property represents a reference to the class which this destructor belongs to.

Parent Classes






6.16.2.4 Class FunctionOverview This is the common supertype for any kind of function.

Class Properties Class Function has the following properties:

accesses : Access [0..∗]This property represents a list of all accesses, which are contained within this func-tion, inclusive ThrowTypeAccesses and return type declarations. It is derived from thestatements within the function body and from the signature.

body : BlockStatement [0..1]This property represents a reference to the BlockStatement which contains the functionbody. This property can be empty in case of an abstract function.

catchParameters : CatchParameter [0..∗]This property represents a list of catch parameters which are handled within the func-tion body.

formalParameters : FormalParameter [0..∗]This property represents a list of the formal parameters of the function.

linesOfCode : UnlimitedNaturalThis property represents the number of code lines in this function.

linesOfComments : UnlimitedNaturalThis property represents the number of comment lines in this function.

localClasses : Class [0..∗]This property represents a list of local classes which are declared within this function.

localVariables : LocalVariable [0..∗]This property represents a list of local variables declared within this function.

maximumNestingLevel : UnlimitedNaturalThis property represents the maximum nesting level of the control-flow structure withinthe function body, with respect to the depth of encapsulation of statements.

numberOfEdgesInCFG : UnlimitedNaturalThis property represents the number of edges in the control-flow graph of the function.

numberOfNodesInCFG : UnlimitedNaturalThis property represents the number of nodes in the control-flow graph of the function.

numberOfStatements : UnlimitedNaturalThis property represents the number of statements within this function.

operator : EBooleanThis property is true if the function is an operator. Operators are modelled as functionsand their usage is modelled as FunctionAccess.




returnTypeDeclaration : DeclarationTypeAccess [0..1]This property represents a TypeAccess which points to the declared return type of thefunction.

throwTypeAccesses : ThrowTypeAccess [0..∗]This property represents a list of ThrowTypeAccesses of this function.

Parent Classes



6.16.2.5 Class GenericFunctionOverview This class models generic functions. It is derived from generic entity, which providesreferences to its type parameters.

Parent Classes

• GenericEntity (see section 6.15.2.2 on page 81) ,

• GlobalFunction (see section 6.16.2.6 on page 89)

6.16.2.6 Class GlobalFunctionOverview This class models a global function.

Class Properties Class GlobalFunction has the following properties:

kind : GlobalFunctionKindThis property represents the kind of the global function. It can have the following val-ues: "NORMAL" for a normal global function, "UNITINITIALIZER" for a globalfunction which serves as unit initializer, "UNITFINALIZER" for a global functionwhich serves as unit finalizer.

surroundingPackage : PackageThis property represents a reference to the package which contains this global function.

Parent Classes





6.16.2.7 Class MethodOverview This class represents a methods of a class. Constructors and destructors are modelledexplicitly.

Class Properties Class Method has the following properties:

propertyMethod : BooleanThis property is true if this method represents a property accessor method.

surroundingClass : ClassThis property represents a reference to the class which contains this method.

surroundingProperty : PropertyIf this method is a property method this property represents a reference to the property.Otherwise it is "null".

Parent Classes• Member (see section 6.18.2.4 on page 97) ,


6.17 Package gast::statements


This package contains all classes and interfaces which belong to the statement hierarchy or areotherwise related to it. Statements describe the control flow within a function body.


6.17.2.1 Class BlockStatementOverview The BlockStatement class models a composition statement or a function body. It alsorepresents synchronized blocks.

Class Properties Class BlockStatement has the following properties:

statements : Statement [0..∗]This property is an ordered list of statements inside this block statement.

surroundingFunction : FunctionIf this block statement is a function body this is property is a reference to the function.Otherwise it is "null".

synchronized : BooleanThis property is true if this block statement represents a synchronized block.




Parent Classes

• Statement (see section 6.17.2.11 on page 94)

6.17.2.2 Class BranchOverview This class represents a branch of a BranchStatement.

Class Properties Class Branch has the following properties:

conditionExpression : GASTExpressionThis property represents the condition expression for this branch.

statement : Statement [0..∗]This property represents the statement which represents the body of this branch.

6.17.2.3 Class BranchStatementOverview This class models a branch, also known as selection statements or conditional state-ments. Typical examples are if statements or switch statements.

Class Properties Class BranchStatement has the following properties:

branches : Branch [1..∗]This property represents a list of branches.

Parent Classes


6.17.2.4 Class CatchBlockOverview This class represents a catch block. It extends the BlockStatement class and has acatch parameter.

Class Properties Class CatchBlock has the following properties:

catchParameter : CatchParameterThis property represents a reference to the catch parameter for this catch block.

Parent Classes

• BlockStatement (see section 6.17.2.1 on page 90)




6.17.2.5 Class ExceptionHandlerOverview This class represents handlings of exceptions. A typical exception handling consistsof a guarded block, also known as try block, and several catch blocks. An optional finally blockcan be contained.

Class Properties Class ExceptionHandler has the following properties:

catchBlocks : CatchBlock [1..∗]This property represents a list of the catch blocks of this exception handler.

finallyBlock : BlockStatement [0..1]This property represents a reference to the finally block of this exception handler. Ifthere is no finally block then this property will be "null".

guardedBlock : BlockStatementThis property represents a reference to the block statement which is guarded by thisexception handler.

Parent Classes


6.17.2.6 Class GASTBehaviourOverview This class represents the behaviour of a service described by G-AST meta-model. Itenables description of service behaviour in terms of control-flow and data-flow via model elementsof the G-AST meta-model.

Class Properties Class GASTBehaviour has the following properties:

blockstatement : BlockStatementThis property represents the blockstatement. The control-flow of the behaviour is mod-elled via the statement structure.

Parent Classes

• OperationBehaviour (see section 6.3.3.3 on page 45)

6.17.2.7 Class GASTExpressionOverview This class is the root class of the expression hierarchy.




6.17.2.8 Class JumpStatementOverview This class models all kinds of non-conditional jumps. Throwing of exceptions andreturn-statements are also categorized as non-conditional jumps.

Class Properties Class JumpStatement has the following properties:

kind : JumpStatementKindThis property is a reference to the kind of the jump statement.

Parent Classes


6.17.2.9 Class LoopStatementOverview The LoopStatement class models all kinds of looping statements, which can occur inconsidered object-oriented programming languages, e. g. for, while, do-while or foreach.

Class Properties Class LoopStatement has the following properties:

body : StatementThis property represents a reference to the statement which represents the body of thisloop statement.

breakConditionExpression : GASTExpressionThis property represents a reference to the expression which represents the break con-dition of this loop statement.

incrementExpression : GASTExpression [0..1]This property represents the incrementation expression of the loop. This property isoptional.

initExpression : GASTExpression [0..1]This property represents the initialization expression of the loop. This property is op-tional.

kind : LoopStatementKind

Parent Classes


6.17.2.10 Class SimpleStatementOverview The SimpleStatement class represents a statement, whose control-flow is a linear se-quence, for example variable assignments.




Parent Classes


6.17.2.11 Class StatementOverview The Statement class is the root of the statement hierarchy and represents a statement,which can occur inside a function body. Non-local class declarations, imports and other object-oriented language statements, which cannot occur inside a function body, are not modelled.

Class Properties Class Statement has the following properties:

accesses : Access [0..∗]This property represents a list of accesses within this statement.

expression : GASTExpression [0..∗]This property represents a reference to occurring expressions within this statement.

surroundingStatement : Statement [0..1]This property represents a reference to the surrounding statement of this statement. Ifthere is no surrounding statement this property is "null".

Parent Classes


6.18 Package gast::types


This package contains all classes and interfaces which belong to the type hierarchy.Please see figure 6.10 for an overview on this package.


6.18.2.1 Class ArrayOverview This class represents an array. It implements the interface TypeDecorator.

Class Properties Class Array has the following properties:

baseType : TypeThis property represents the base type of this array.

dimensions : UnlimitedNaturalThis property represents the number of dimensions of this array.




Figure 6.10: Overview of the type hierarchy.

Parent Classes

• TypeDecorator (see section 6.18.2.8 on page 99)

6.18.2.2 Class ClassOverview This class represents the class elements like they are known in the UML. It modelsclasses, primitive types as well as interfaces.

Class Properties Class Class has the following properties:

anonymous : EBooleanThis property is true if this class is an anonymous class, which is declared without anexplicit name.

constructors : Constructor [0..∗]This property represents a list of all constructors of this class.

destructors : Destructor [0..∗]This property represents a list of all destructors of this class.

fields : Field [0..∗]This property represents a list of all fields of this class.

friendClasses : Class [0..∗]This property represents a list of all friend classes of this class.




friendFunctions : Function [0..∗]This property represents a list of all friend functions of this class.

inheritanceTypeAccesses : InheritanceTypeAccess [0..∗]This property represents a list of all direct inheritance relationships of this class.

inner : EBooleanThis property is true if this class is an inner class, which means that it is declared in thecontext of another class.

innerClasses : Class [0..∗]This property represents a list of all inner classes of this class.

innerDelegates : Delegate [0..∗]This property represents a list of all delegates declared in this class.

innerTypeAliases : TypeAlias [0..∗]This property represents a list of all type aliases declared in this class.

interface : EBooleanThis property is true if this class object represents an interface.

linesOfComments : UnlimitedNaturalThis property represents the number of comments within this class.

local : EBooleanThis property is true if this class is a local class, which means that it is declared withina function body.

methods : Method [0..∗]This property represents a list of all methods of this class.

primitive : EBooleanThis property is true if this class object represents a primitive type (e. g. int).

self : FieldThis property is a helping construct, which is used as a target for all explicit and implicit"this" and "super" accesses.

superTypes : Class [0..∗]This property represents all direct super types of this class. It is derived from theinheritance hierarchy which is represented by inheritance type accesses.

surroundingClass : ClassThis property represents a reference to the class in which this class is contained, onlyin the case of inner and local classes. Otherwise this property is "null".

surroundingFunction : FunctionThis property represents a reference to the function in which this class is contained,only in case of a local class. Other this property is "null".




surroundingPackage : PackageThis property represents a reference to the package, in which this class is contained.

Parent Classes

• Type (see section 6.18.2.6 on page 98) ,

• Member (see section 6.18.2.4 on page 97)

6.18.2.3 Class GenericClassOverview This class represents a generic class.

Parent Classes

• GenericEntity (see section 6.15.2.2 on page 81) ,

• Class (see section 6.18.2.2 on page 95)

6.18.2.4 Class MemberOverview This entity represents a possible member of a class. Since there are local classes,classes are members as well. Modifiers for members are modeled within this entity.

Class Properties Class Member has the following properties:

abstract : EBooleanThis property is true if this member is abstract.

extern : BooleanThis property is true if this member is a declaration of an external entity.

final : EBooleanThis property is true if the member is final which means it cannot be overridden orredefined.

internal : BooleanThis property is true when a member is accessible within its own assembly.

introspectable : BooleanThis property is true if this member is visible to introspection.

override : BooleanThis property is true if this member overrides another member.

static : EBooleanThis property is true if this member is static which means no object is necessary foraccessing this member, but only the class.




typeParameterClassMember : BooleanThis property is true if this member belongs to a type parameter class.

virtual : BooleanThis property is true if this member is virtual.

Parent Classes


6.18.2.5 Class ReferenceOverview This class models a pointer (like in C++) or a reference.

Class Properties Class Reference has the following properties:

explicit : EBooleanThis property is true if it is a pointer and false if it is a reference.

referencedType : TypeThis property represents a reference to the referenced type.

Parent Classes

• TypeDecorator (see section 6.18.2.8 on page 99)

6.18.2.6 Class TypeOverview This entity models the root of the type hierarchy. The type hierarchy represents thetype system.

Class Properties Class Type has the following properties:

qualifiedName : EStringThis property represents the fully qualified name of this type.

referenceType : BooleanThis property is true if this type is a reference type. It is false if this type is value type.

Parent Classes

• NamedModelElement (see section 6.15.2.5 on page 82)




6.18.2.7 Class TypeAliasOverview This class models a type alias (e. g. typedef-constructs in C++).

Class Properties Class TypeAlias has the following properties:

aliasedType : TypeThis property represents a reference to the aliased type.

innerTypeAlias : EBooleanThis property is true if this type alias is an inner class.

surroundingClass : ClassThis property represents a reference to the class which contains this type alias.

surroundingPackage : PackageThis property represents a reference to the package which contains this type alias.

Parent Classes• TypeDecorator (see section 6.18.2.8 on page 99) ,

• Member (see section 6.18.2.4 on page 97)

6.18.2.8 Class TypeDecoratorOverview This entity is used to model derived types (like arrays) or type proxys.

Class Properties Class TypeDecorator has the following properties:

decoratedType : TypeThis property represents the type which is decorated by this type decorator.

undecoratedType : TypeThis property represents the innermost type which is decorated, which means all typedecorators are removed. This property is derived from the chain of type decorators.

Parent Classes• Type (see section 6.18.2.6 on page 98)

6.18.2.9 Class TypeParameterClassOverview This class represents a type of a generic type parameter.

Class Properties Class TypeParameterClass has the following properties:

typeBounds : Type [0..∗]This property represents a list of type bounds of this type parameter class. These arethe types which are bound to this type parameter when instantiating a generic class.




Parent Classes

• Class (see section 6.18.2.2 on page 95)

6.19 Package gast::variables


This package contains all classes and interfaces which belong to the variable hierarchy.lease see figure 6.11 for an overview on this package.

Figure 6.11: Overview of the variable hierarchy


6.19.2.1 Class CatchParameterOverview This class models a parameter of a catch expression.

Class Properties Class CatchParameter has the following properties:

rethrown : EBooleanThis property is true if the exception, which is handled by this catch parameter isrethrown to the caller.

surroundingFunction : FunctionThis property represents a reference to the function in which this catch parameter isdeclared.




Parent Classes

• Variable (see section 6.19.2.6 on page 102)

6.19.2.2 Class FieldOverview This class represents fields. They are class members.

Class Properties Class Field has the following properties:

propertyField : EBooleanThis property is true if it is a property field.

surroundingClass : ClassThis property represents a reference to the class the field belongs to.

Parent Classes



6.19.2.3 Class FormalParameterOverview This class represents a formal parameter of a function.

Class Properties Class FormalParameter has the following properties:

passedByReference : EBooleanThis property is true if this parameter is passed by reference, it is false if it is passed byvalue.

surroundingFunction : FunctionThis property represents a reference to the function this formal parameter belongs to.

Parent Classes


6.19.2.4 Class GlobalVariableOverview This class represents a global variable. Since global variables are not declared withinthe context of another model element, they are primarily accessible via the root object of the model.

Class Properties Class GlobalVariable has the following properties:

surroundingPackage : PackageThis property represents a reference to the package which contains the declaration ofthis global variable.




Parent Classes


6.19.2.5 Class LocalVariableOverview This class represents a local variable. Local variables are declared variables within afunction body.

Class Properties Class LocalVariable has the following properties:

surroundingFunction : FunctionThis property represents a reference to the function in which the local variable is de-clared.

Parent Classes


6.19.2.6 Class VariableOverview This class is the root of the variable hierarchy.

Class Properties Class Variable has the following properties:

const : EBooleanThis property is true if this variable is declared as constant.

type : TypeThis property represents the declared type of this variable. It is derived from typeDec-laration.getType().

typeDeclaration : DeclarationTypeAccess [0..1]This property represents a reference to a type access which points to the declared typeof this variable.

Parent Classes






7 ConclusionsThis document introduces the Q-ImPrESS Service Architecture Meta-Model. The Service Ar-

chitecture Meta-Model is the central concept in the model-driven Q-ImPrESS method. It is usedto create models of evolving service-oriented architectures for which software architects wish tomake different quality predictions. It contains in its current version packages to specify the static,dynamic, and deployment aspects of a service architecture. Instances of the Service ArchitectureMeta-Model will be editable with graphical editors and are subject to model transformations toperform quality predictions.

The Service Architecture Meta-Model is needed by software architects, tool developers, andfor dissemination activities. Software architects need to know the semantics of the model elementsavailable to them for specifying service architectures. Tool developer need the meta-model tocreate model editors, transformations, and tools for the trade-off analysis. Finally, the ServiceArchitecture Meta-Model and its concepts can be used in dissemination activities, e.g., to influencestandards like the UML SOA profile or for knowledge exchange.

Future work remains to be done in upcoming work packages to extend the meta-model withquality annotations, usage models, and more specific behaviour models. Additionally, the EMFbased tool chain need to be implemented or generated to evaluate the feasibility of the wholeapproach. Finally, the Service Architecture Meta-Model has to prove its usefulness on the realworld examples provided by ABB, Ericsson Nikola Tesla, and Itemis.




Index

gast::accessesAccess, 74CastTypeAccess, 75CompositeAccess, 75DeclarationTypeAccess, 75DelegateAccess, 76FunctionAccess, 76InheritanceTypeAccess, 76ParameterInstantiationTypeAccess, 77RunTimeTypeAccess, 77SelfAccess, 77StaticTypeAccess, 77ThrowTypeAccess, 78TypeAccess, 78VariableAccess, 78

gast::annotationsAttribute, 79Layer, 79ModelAnnotation, 79StructuralAbstraction, 80Subsystem, 80

gast::coreFile, 80GenericEntity, 81ModelElement, 82ModelElementRepository, 82NamedModelElement, 82Package, 83Position, 84Root, 84SourceEntity, 85

gast::functionsConstructor, 86Delegate, 86Destructor, 87Function, 88GenericFunction, 89GlobalFunction, 89Method, 90

gast::statements

BlockStatement, 90Branch, 91BranchStatement, 91CatchBlock, 91ExceptionHandler, 92GASTBehaviour, 92GASTExpression, 92JumpStatement, 93LoopStatement, 93SimpleStatement, 93Statement, 94

gast::typesArray, 94Class, 95GenericClass, 97Member, 97Reference, 98Type, 98TypeAlias, 99TypeDecorator, 99TypeParameterClass, 99

gast::variablesCatchParameter, 100Field, 101FormalParameter, 101GlobalVariable, 101LocalVariable, 102Variable, 102

samm::annotationAnnotation, 44

samm::behaviourBehaviour, 45ComponentTypeBehaviour, 45OperationBehaviour, 45

samm::coreEntity, 46NamedEntity, 46

samm::datatypesCollectionDataType, 47




ComplexDataType, 47InnerElement, 47PrimitiveDataType, 48Type, 48

samm::deployment::allocationService, 49

samm::deployment::hardwareCache, 50HardwareDescriptor, 51HardwareDescriptorRepository, 52MemoryDescriptor, 53NetworkElementDescriptor, 53NetworkInterfaceDescriptor, 54ProcessorCore, 54ProcessorDescriptor, 54StorageDeviceDescriptor, 55TLB, 56

samm::deployment::targetenvironmentContainer, 56ExecutionResource, 58FileSystemPerformanceProfile, 58Memory, 59MemoryResource, 59NetworkElement, 60NetworkInterface, 60NetworkResource, 61Node, 61PassiveResource, 62Processor, 62SchedulingPolicy, 63SoftwarePerformanceProfile, 63StorageDevice, 64StorageResource, 64TargetEnvironment, 65

samm::staticstructureComponentEndpoint, 65ComponentType, 66CompositeComponent, 67CompositeStructure, 68Connector, 68EndPoint, 68EventPort, 69

Interface, 69InterfacePort, 69MessageType, 70Operation, 70OperationException, 70Parameter, 71PrimitiveComponent, 71Repository, 71ServiceArchitectureModel, 72SubcomponentEndpoint, 72SubcomponentInstance, 73




Glossaryallocation model

a set of bindings between components and modelled resources, assigning each componentthe resources it requires for execution, this information is normally present in a deploymentdiagram, 9

behaviourcontrol flow and data flow within the components of the static structure, 8

black-box componenta component having only interface information. Black-box components cannot be analysedusing tools of static analysis, because they have no information about their internals, how-ever, black-box components can be monitored. In order to apply static analysis, a black-boxcomponent needs to be turned into a grey-box component, 8

componenta software component is a unit of composition with contractually specified interfaces andexplicit context dependencies only. A software component can be deployed independentlyand is subject to third-party composition, 8

connectorconnectors are architectural building blocks used to model interactions among componentsand rules that govern those interactions, 10

evolutiona change to the system or its environment, which would require an update of the SAM or theAM; the environment stands for entities using the system, e.g., other services or users, 7

logical resourcea resource provided by a container, which represents the central entity of the logical layer ofthe deployment model. Logical resources can be consumed by services executing within acontainer, 19

monitoringmeasuring of facts like timing, variable values, loop counts, etc. from existing and runningsystems, 12




passive resourcea special class of a logical resource that does not require a counterpart in form of a physicalresource. Passive resources are provided by a container with the cost of their implementationhidden in the overhead of the container, 19

physical resourcealso called hardware resource – a resource that is directly provided by hardware installedin a node, e.g. a disk represents a physical persistent storage resource. Physical resourcescan be partitioned and assigned to containers, which then provide logical resources used byservices executing within a container, 19

prediction modelsoftware model aimed at obtaining predictions concerning quality attributes of the modelledsystem, 8

quality annotationinformation about performance and reliability of a service present in SAM or implementationin a form of code annotations, 9

quality attributeperformance, reliability or maintainability, 8

resourcea physical (hardware) or logical (software) entity of limited capacity required by a compo-nent for execution, 9

resource modelan abstract description of a resource specifically tailored to serve some analysis purpose(e.g., reliability analysis), 9

reverse engineeringextraction of information based on source code/byte code only, performed not at runtime, 7

servicea deployed component, 8

service architecturea set of services connected to each other via connectors. A subject to analysis, 7




Service Architecture Meta-ModelCommon meta-model which contains everything to describe the information needed forquality prediction analysis. Serves as shared data-repository for all quality analysis methods,7

Service Architecture Modelan instance of the Service Architecture Meta-Model modelling a particular service architec-ture, 15

trade-offresults of analyses between different quality attributes, 7

usage profiledescription of usage of a service/services. This includes the order in which the services arecalled, timing, and data passed as input parameters. The usage profile can be parametrizedby usage profile parameter, 9




Bibliography[1] Becker, S., Dešic, S., Doppelhamer, J., Huljenic, D., Koziolek, H., Kruse, E., Masetti, M.,

Safonov, W., Skuliber, I., Stammel, J., Trifu, M., Tysiak, J., Weiss, R.: D1.1 - RequirementsDocument - initial version. Technical report, Q-ImPrESS consortium (2008)

[2] Grassi, V., Mirandola, R., Sabetta, A.: Filling the gap between design and performance/reli-ability models of component-based systems: A model-driven approach. Journal on Systemsand Software 80(4) (2007) 528–558

[3] Becker, S., Koziolek, H., Reussner, R.: Model-based Performance Prediction with the Palla-dio Component Model. In: Proceedings of the 6th International Workshop on Software andPerformance (WOSP2007), ACM Sigsoft (2007)

[4] Becker, S., Koziolek, H., Reussner, R.: The Palladio Component Model for Model-Driven Performance Prediction. Journal of Systems and Software (2008) In Press, AcceptedManuscript.

[5] Bureš, T., Carlson, J., Crnkovic, I., Sentilles, S., Vulgarakis, A.: ProCom - the ProgressComponent Model Reference Manual, version 1.0. Technical Report ISSN 1404-3041 ISRNMDH-MRTC-230/2008-1-SE, Mälardalen University (2008)

[6] Plasil, F., Visnovsky, S.: Behavior Protocols for Software Components. IEEE Transactionson Software Engineering 28(11) (2002) 1056–1076

[7] Budinsky, F., Steinberg, D., Merks, E., Ellersick, R., Grose, T.J.: Eclipse Modeling Frame-work. Eclipse Series. Prentice Hall (2003)

[8] Szyperski, C., Gruntz, D., Murer, S.: Component Software: Beyond Object-Oriented Pro-gramming. 2 edn. ACM Press and Addison-Wesley, New York, NY (2002)

[9] Trifu, M., Stammel, J.: SISSy sourceforge site (2005)

[10] Trifu, M., Szulman, P., Kuttruff, V.: Das QBench Systemmetamodel, V4.0. Technical Report,FZI Forschungszentrum Informatik, Karlsruhe (2005)

[11] Trifu, M.: QBench project homepage (2005)

[12] Åkerholm, M., Carlson, J., Fredriksson, J., Hansson, H., Håkansson, J., Möller, A., Pet-tersson, P., Tivoli, M.: The save approach to component-based development of vehicularsystems. Journal of Systems and Software 80(5) (2007) 655–667


service architecture meta-model - q-impress

Documents