next up previous contents index
Next: Parametric Dependencies Up: Resource Demanding Service Effect Previous: External Calls and Parameter   Contents   Index


Control Flow

Figure 3.18: Control Flow in RDSEFFs
Image RDSEFF4
RDSEFFs extend classical FSM SEFFs with additional constructs for modeling control flow of the dependencies between provided and required interfaces (Figure 3.18). All control flow constructs are aligned in a hierarchical fashion that avoids ambiguities and eases analyses (an example will follow). A ResourceDemandingBehaviour contains a chain of AbstractActions, which each reference at most a single predecessor and successor. The first element of the chain is a StartAction, which has no predecessor, while the last element of the chain is a StopAction, which has no successor.

InternalActions should be used to reference ParametricResourceDemands for activities inside the described service, between calls to required services. In the future, they could be used to characterise the inner resource demand of basic components more detailed.

Figure 3.19: Branches in RDSEFFs
Image RDSEFF5

BranchActions split the control flow with an XOR-semantic: Exactly one of the attached AbstractBranchTransitions is taken when such an action is executed. Branches may result from if/ then/ else or case statement of the underlying source code.

Branch transitions can be either guarded or probabilistic (Fig. 3.19). GuardedBranchTransitions, contain a branch condition as a random variable. For example, a branch condition could be connected to the value of an input parameter (''$ x<1$''), in which case a branching probability could be computed once the value of the input parameter is known. ProbabilisticBranchTransitions directly contain a probability and not a branch condition. They can be used in case a component developer cannot specify a guard related to input parameters or just to ease the analyses.

Additionally, each type of branch transition contains a ResourceDemandingBehaviour to model the inner actions of the branch. Using inner behaviours avoids the need to have a merge action to join branches. Furthermore, it prevents problems, which might arise when a nested ''else''-branch cannot be associated unambigiously with an according ''if''-branch.

ForkActions split the control flow with an AND-semantic: Each of the inner forked ResourceDemandingBehaviours has to be executed (possibly concurrently) before the control flow continues with the successor of the corresponding ForkAction. Forks may for example result from the invocations of threads. Because the inner activities of the forked behaviours are encapsulaed in ResourceDemandingBehaviours, there is no need for a join action to reconnect concurrent control flows.

Figure 3.20: Loops in RDSEFFs
Image RDSEFF6

AbstractLoopActions, like BranchTransitions and ForkActions, contain inner ResourceDemandingBehaviour, which include actions carried out in the loop body (Fig. 3.20). Loops can originate from for or while statements of the underlying source code.

Concrete loop action can be modelled either with LoopActions or CollectionIteratorActions. The former contain the number of iterations as a random variable, and this random variable can include dependencies on input parameters (explained later). The latter enables modeling the special but common case of iterating over a collection. Because of this, CollectionIteratorActions reference an input parameter of the current component service. This input parameter must be a collection parameter and the number of elements in this collection has to be characterised with a random variable. Then the loop gets executed for each element in the collection.

Notice, that for LoopActions, it is assumed that the parameters characterisations used in the loop body are stochastically independent, whereas for CollectionIteratorActions it is assumed that the characterisations are not independent. For example, if the characterisation of a parameter value is specified by a random variable and is used by two external call actions within a loop body, the analyses algorithms have to assure, that the second action uses the same characterisation as the first action and that the random variable does not get evaluated a second time.

Modelling loops with inner behaviours instead of allowing cyclic references in the chain of AbstractActions has several advantages [31]. In Markov models, loops are specified with cycles, so that there is an entrance probability for each loop and an exit probability. The probability of entering the loop decreases if the number of loop iterations is increased. For example, entering a loop with a entrance probability of 0.9, leads to a probability of 0.81 for two loop iterations, and a probability of 0.729 for three loop iterations. Thus, the number of loop iterations is always limited to a geometrical distribution, which does not resemble practical situations well. Fixed number of loop iterations can only be specified by unrolling the loop to a number of states in Markov models. With the approach described above, it is possible to attach an arbitrary distribution function for the number of iterations to each loop.

Figure 3.21: Example Instance RDSEFF highlighting control flow concepts
Image RDSEFF_example

Figure 3.21 shows a simplified example instance of an RDSEFF, which highlights the control flow concepts introduced before. Note that the constructs are hierarchically structured. Analysis algorithms can easily traverse the abstract syntax tree to make model transformations or QoS predictions.


next up previous contents index
Next: Parametric Dependencies Up: Resource Demanding Service Effect Previous: External Calls and Parameter   Contents   Index
Snowball 2007-03-16