An e-Motions reimplementation of Palladio


The Palladio Component Model (PCM) is a well-known framework in which a system may be specified and simulated. PCM is a domain-specific language (DSL) and, therefore, we may define it in e-Motions. Palladio supports two kinds of predictive analyses: 1) by transformation into a program that runs a simulation of the architecture's behaviour and 2) by transforming to a formalism more amenable to analysis - for example, Queuing Petri Nets. In both cases, the semantics of the models, and in particular of the non-functional properties being analysed, is encapsulated in the transformations. This makes it very difficult to understand and validate these semantics. This is particularly problematic as more non-functional properties are supported: the current transformations support performance and reliability, but are quite complex already.

We demonstrate here how our proposal on the modular definition of non-functional properties as parametrised domain specific languages (DSLs) in the e-Motions framework can be integrated with predictive analysis of architectural software models by providing a modular reimplementation of a substantive part of the Palladio Architecture Simulator. In particular, we have re-implemented the PCM, its workload model, and parts of its stochastic expressions model. However, instead of implementing transformations to analysis models or simulators as done in Palladio, we have explicitly modelled the simulations as graph transformations in the e-Motions framework. Each NFP to be analysed is then modelled as an independent, parametrised DSL ready to be composed with the base Palladio model.

Palladio into e-Motions

e-Motions provides a way to graphically specify the dynamic behaviour of DSLs using their concrete syntax, making this task very intuitive. The abstract syntax of a DSL is specified as an Ecore metamodel, which defines all relevant concepts - and their relations - in the language. Its concrete syntax is given by a GCS (Graphical Concrete Syntax) model, which attaches an image to each language concept. Then, its behaviour is specified with (graphical) in-place model transformations.

PCM has been developed following MDE principles, and specifically it is implemented using the Eclipse Modeling Framework (EMF), its metamodel may be directly used as abstract syntax definition of Palladio in e-Motions. The concrete syntax is provided by a GCS model in which each concept in the abstract syntax of the DSL being defined is linked to an image. Since these images are used to graphically represent Palladio models in e-Motions, we have used the same images that the PCM Bench uses to represent these concepts. This way, we maintain the PCM's look in the e-Motions definition.

In e-Motions, we describe how systems evolve by describing all possible changes of the models by corresponding visual rewrite rules, that is, time-aware in-place transformation rules. Since the PCM metamodel only specifies those concepts relevant for the PCM language and the models obtained from the PCM Bench cannot be directly simulated or analyzed, we have conservatively enriched the PCM metamodel with new concepts to handle the control flow. We call this new metamodel Palladio*. Specifically, Palladio* has an additional metamodel Token, which includes two classes SToken and CToken. The former is specified at the system model (UsageModel) level, and the latter at the component model (RDSEFF) level. Both SToken and CToken classes have a Bool attribute completed, which states where an action with this Token is accomplished. A reference - with cardinality - to the Token class has been added to AbstractUserAction and AbstractSEFFAction, respectively. An ordered reference queue from ProcessingResourceSpecification to CToken, with multiplicity is used as a queue in which actions wait until resources of the corresponding type are available. Fig. 1 shows the Token metamodel and the references from classes of PCM to SToken and CToken.

Fig. 1 Token metamodel

An e-Motions definition of Palladio

This section states all visual rewrite rules involved in the current definition of Palladio. The composition of the Palladio DSL and the DSLs of the different NFPs to be analyzed, we obtain the in-place transformation rules in fig. 2.

Fig. 2 Rewriting rules

We show in what follows the rules that describe the behaviour of the Palladio DSL with the DSLs for the Response Time and Throughput 'observers'.

UsageModel concepts

Fig. 3 shows the OpenWorkloadSpec rule, which specifies the behaviour of a UsageScenario usSc with an OpenWorkload ow. When the rule is triggered, a new system token is added to the first action of the system, i.e., the start action. Moreover, the rule is fired every owRate, which is a local variable whose value is given by ow's random variable.

Fig. 3 OpenWorkload rule.

Fig. 4 shows the StartUsageModel rule, which models the Start action. It sets the completed attribute of the token to true. This rule is instantaneous.

Fig. 4 StartUsageModel rule.

Fig. 5 shows the StopUsageModel rule, which models the Stop action. Every observer monitoring a NFP collect time information in this rule, since the token objects are removed modeling the end of a whole task.

Fig. 5 StopUsageModel rule.

Fig. 6 shows the EntryLevelSystemCall rule, which models a call to a component. Once a token reach the EntryLevelSystemCall action, the token remains in this action while a new CToken is added to the start action of the component called. A new timestamp is associated to the CToken object created.

Fig. 6 EntryLevelSystemCall rule.

Fig. 7 shows the ExitLevelSystemCall rule. This rule models when a CToken object reachs the stop action of a component. Thus, this CToken object is removed and the SToken object associated is marked as completed. Moreover, all observers monitoring NFPs of this component are updated.

Fig. 7 ExitLevelSystemCall rule.

Fig. 8 shows the DelayUsageModel rule where the action Delay is specified. Note that this rule is not instantaneous, since it lasts as long as it is specified in the random variable associated to the Delay action.

Fig. 8 DelayUsageModel rule.

Fig. 9 shows the ActionUsageModelTrans rule. When an object (note that we deal with AbstractUserAction which generalizes all actions belonging to UsageModel) has associated a SToken object completed, the SToken object is passed to its successor action and the completed attribute is set to false.

Fig. 9 ActionUsageModelTrans rule.

SEFF concepts

The following rules model Service Effect Specifications (SEFF).

Fig. 10 shows the rule modelling the StartSEFF action. Note this rule is very similar to rule illustrate in fig. 4.

Fig. 10 StartSEFF rule.

Fig. 11 shows the StopSEFF rule, which models the stop action.

Fig. 11 StopSEFF rule.

The following rules specify the BranchAction concept. Basically, the CToken is passed to the selected ProbabilisticBranch action depending on the branch probability. With the BranchSEFF2TokenProb rule a random value is obtained and stored in the prob attribute of the token. The right branch is selected in the TokenProb2ProbabilisticBranch rule (note the variable branchNumberAux). The TokenEnterInABranch rule moves the token into the right branch.

Fig. 12 BranchSEFF2TokenProb rule.
Fig. 13 TokenProb2ProbabilisticBranch rule.
Fig. 14 TokenEnterInABranch rule.

Fig. 15 shows the IntActSEFFSchFCFS rule, which models the First-Come-First-Served scheduling policy when a task or CToken object is going to demand a resource, i.e. CPU. The CToken object is added to the attribute queue belonging to the concrete resource. Since it occurs inside of a InternalAction, the CToken object is added to the resource queue when the token is passed to the InternalAction concept.

Fig. 15 IntActSEFFSchFCFS rule.

Fig. 16 shows the rule that models an InternalAction. The CToken in first position in the resource's queue is removed from this queue and marked as completed. This rule lasts the time specified by the number of units demanded to the resource and the processing rate of this resource.

Fig. 16 InternalActionSEFF rule.

Fig. 17 shows the ActionSEFFTrans rule. This rule is analogous to ActionUsageModelTrans where a completed CToken is passed to its successor. Note that if the successor is a InternalAction, the rule is not fired, since the proper scheduling policy has to be applied.

Fig. 17 ActionSEFFTrans rule.

An example

Fig. 19 shows a very simple example of a component specification in Palladio. It shows a so-called resource-demanding service-effect specification (RDSEFF) describing the key performance-relevant elements of a component's behaviour. In particular, it shows that the control flow in our component may branch into either of three flows, with different CPU demands for each flow. Each branch is associated with a particular branch probability to indicate the likelihood of a particular branch being taken.

Fig. 19

Fig. 20 shows a usage model specifying a particular workload for our component. This part of the model uses standard workload terminology to specify an open workload with an inter-arrival time of 2 time units. When a request arrives, there is a delay of 5 units loading the application, after which a call to our component is executed.

Fig. 20

The Palladio Simulator offers the results of the analysis of performance and reliability of the system being analysed in different formats. For example, for the above model, it gives the following mean response time and confidence intervals:

Mean value: 41.97139713971397 
Confidence value alpha: 0.9 
Upper bound: 52.17187782288832 
Lower bound: 31.770916456539624 

The chart in Fig. 21 represents the cumulative distribution function of the system's response time. Since the CPU resource gets saturated, the response time keeps increasing along time. For 1,000 runs, tasks take up to 90 time units.

Fig. 21

The simulation of the Palladio model using our e-Motions definition of Palladio are (for a simulation of 1000 tasks):

Mean System Response Time: 43.6626
Throughput: 0.4804

Fig. 22 shows the cumulative distribution function for the simulation in e-Motions, and Fig. 23 shows the response time as a function of the time when a request entered the system, based on the e-Motions output.

Fig. 22
Fig. 23

Minimum project example

One of the examples provided by Palladio Team in their website (see Palladio website) is the so-called Minimum Project. Whith this example the Palladio Team illustrates some of the basic features of the Palladio Model Component. Since within this example there are stochastic expressions, here we present the partial re-implementation of the stochastic exptressions into e-Motions.

Fig. 24 shows the Minimum example usage model, where a call to AComponent component succeded by a delay is specified. On the other hand, fig. 25 shows the AComponent specification. Similar to our basic example above presented, in this component there is a branch action composed by two probabilistic branches. Both branches required resources (i.e. CPU) specifying the amount of resources by means of stochastic expressions. The branch on the left side uses a typical exponential distribution and the branch on the rigth side uses a distribution which function is explicitly specified.

Fig. 24
Fig. 25

Our current re-implementation of PCM supports integer or real numbers, exponential distrubutions and DoublePDF distributions as both delay time and the use of resources specifications.


The file contains all required files to run the above example. The metamodel, the concrete syntax and the rules shown above are included in a Eclipse project. Once e-Motions has been set up (see e-Motions page), the project may be imported in Eclipse by selecting Import...-> General -> Existing Projects into Workspace -> Select archive file and then select the To perform the simulation, we have to select the behavior file (Rules/RulesBehavior.ecore), the metamodel (Metamodel/flatten.ecore), the initial model (inputModel/ECMFAexample.xmi) and set the time limit and the output model.