Delimitación del contenido del derecho fundamental presuntamente

The RD-SEFF contains concepts to model the control flow of the service’s execution. How- ever, these constructs should only be used if they have an impact on the interaction of the com- ponent and its context. This is the same requirement already introduced in the discussion of parameter characterisations. If it has no impact on the interaction with the context, the control flow is hidden in the implementation of the component’s service and abstracted by InternalActions.

The design of the control flow constructs is intentionally different from those in UML activity charts even if the basic ideas are comparable. However, in contrast to UML ac- tivity charts, the RD-SEFFs control flow constructs use a similar representation as the abstract syntax trees of structured programming languages like Java. For example, a loop is not modelled by a control flow reference pointing at an action already executed earlier. It is modelled by a loop action which explicitly contains a sequence of actions represent- ing the loop body. After repeating the inner behaviour n-times, the course of actions continues at the successor of the loop action. The same is true for branch actions, forks, etc.

The rationale behind this kind of modelling is the avoidance of ambiguities which can arise when analysing models with control flows models based on arbitrary graphs like UML activity diagrams. Additionally, making nested behaviours explicit eases the handling of model instances in both types of model transformations - transformation into analysis models as well as transformations into implementations. The reason for this is that there is no need for the transformations to figure out the start and end of inner behaviours. Additionally, performance annotations like iteration counts can annotate di- rectly the corresponding control flow actions. As a consequence of the explicit modelling of nested behaviours, each behaviour is a chain of actions going directly from the (only) start action to the (only) stop action.

An overview of the available control flow concepts is given in figure3.15.

Loops The PCM supports two types of loop actions: LoopActions and CollectionItera-

+branchCondition 1 +branches 0..* 1 +bodyBehaviour +iterations 1

BranchAction AbstractLoopAction ForkAction

ResourceDemanding Behaviour AbstractBranch Transition Guarded BranchTransition BranchCondition Probabilistic BranchTransition branchProbability : Double 1 +branchBehaviour LoopAction CollectionIterator Action IterationCount 1 +parameter Parameter parameterName : String RandomVariable specification : String AbstractResource DemandingAction StartAction StopAction ForkedBehaviour * +asyncBehaviour Synchronization Point 0..1 +synchBehaviours * +synchBehaviour

Figure 3.15: Control Flow concepts in the PCM (Becker et al.,2007)

for the given amount of loop iterations. The number of iterations is determined by a stochastic expression of type Integer. As a requirement, the PCM assumes all loops to be bounded. Hence, modelling infinite loops is unsupported. To model the number of loop repetitions, a stochastic expression defines the iteration count as random variable. Com- ponent developers specify a probability for each iteration count up to a maximum count N, e.g., mathematically P (iteration count = n) = pi with P (iteration count = n) = 0

for all n > N .

CollectionIteratorActions repeat their inner behaviour for every element of a parameter of CollectionDatatype. As a consequence, CollectionIteratorActions execute the loop body for each element in the collection, i.e., NUMBER OF ELEMENTS times. Additionally, all IN- NER characterisations of the iterated parameter stay constant during the evaluation of all actions of the loop body. This allows the specification of stochastical dependent actions. For example, a component compresses a set of files and stores the result in a database. As the size of each stored file depends on the size of the uncompressed file, a CollectionIter- atorAction keeps this size constant, i.e., it does not re-evaluate the corresponding INNER characterisation on every access.

Alternatives The PCM offers two types of branch actions to specify alternatives in the

control flow of a component’s service: ProbabilisticBranches and GuardedBranches. The PCM uses so called BranchTransitions to associate the branch’s behaviour to the branch action (see figure 3.15). Consequently, two types of branch transitions exist which cor- respond to the two types of branches. The types cannot be mixed. Either all branch transitions of one BranchAction are probabilistic or guarded. For both types of branches the PCM demands that exactly one branch is active and the behaviour of this branch is

executed. Note, that this might imply specifying a transition with an empty behaviour in case of modelling an optional control flow part. For example, to specify a behaviour which only gets executed if its guard is true, an empty branch is needed which is executed in cases when the guard is false.

ProbabilisticBranchTransitions model behaviour which is random in its nature or which cannot be specified more precisely by capturing its data dependencies. For each Proba- bilisticBranchTransition a probability is given for executing the behaviour of that transition. The probabilities of all branch transitions have to sum up to 1 as a result of the require- ment that exactly one transition has to be taken.

GuardedBranchTransitions use random variables of boolean type to specify which tran- sition executes. Each transition contains a random variable called its guard condition. However, the guard condition can dependent on other random variables from whose its own distribution can be derived. In order to ensure that exactly one branch condi- tion evaluates to true, all branch conditions are evaluated using the same values for the involved random variables, i.e., the conditions are evaluated stochastically dependent. From this requirement, it follows that it is disallowed to use INNER characterisations in branch conditions as they are always evaluated independently.

For guarded branch transitions an additional constraint results for the analysis of their inner behaviour. As the guard condition has evaluated to true, it is known that the con- dition is true while evaluating its inner behaviour. Hence, the analysis of the inner be- haviour is done under the stochastic condition that the random variable of the branch’s guard condition is true. For example, the guard condition

files.BYTESIZE > 200

defines a restriction on the files.BYTESIZE random variable. Hence, in the inner be- haviour of the corresponding branch transition, all random variables depending on files.BYTESIZEhave to be evaluated conditionally with the condition files.BYTESIZE > 200:

P (f (files.BYTESIZE) = X|files.BYTESIZE > 200)

with f (files.BYTESIZE) being the definition formulae of a random variable depending on the random variable files.BYTESIZE. Bayes’ law applies (Sachs,1997, p. 78) for evalu- ating the resulting formulae. However, in simulation runs, it is much easier to ensure the respective semantics (see section4.4for details on the simulation’s semantics).

Forks In the PCM ForkActions are used to split the control flow into sub control flows.

Each control flow then executes its inner behaviour independent of the other forked be- haviours. However, if they use the same resources while processing their behaviour,

concurrent resource usage leads to resource conflicts which might have significant per- formance impacts. Each behaviour starts with a copy of the forking behaviour’s variable characterisations. The ForkAction, which started the ForkedBehaviours, waits for the subset of synchronous ForkBehaviours to finish their execution before it continuous its own con- trol. Synchronous fork behaviours are attached to the ForkAction’s SyncronizationPoint. Asynchronous fork behaviours which are not attached to the SynchronizationPoint execute until they reach their own stop action - independent of the ForkAction which initiated their execution.

For ForkedBehaviours attached to the SynchronizationPoint, it will be possible to return results of their computations to the initiating ForkAction in future versions of the PCM.

Happe(2008) currently defines the necessary meta-model changes.