Publicidad estatal y libertad de información

A service’s parameters may have significant impact on its resource demand. For example, the resource demand of a sorting service offered by a component depends on the size of the collection to sort. Thus, parameters have an impact on ParametricResourceDemands (cf. section 3.5.6). Additionally, the control flow of a service may depend on parameters as introduced in section3.5.8.

As introduced in section 3.3, a service signature has n input parameters and m out- put parameters. To capture their performance impact, component developers can attach specification on these parameters. For this, they use so called VariableUsages in Exter- nalCallActions. The PCM’s meta-model supports a set of input VariableUsages and a set of output VariableUsages for ExternalCalls. The parameter characterisations introduced in the following are part of the usage context (cf. section3.2.2) and have been introduced by

Koziolek et al. (2006) for UML-SPT and included into the PCM’s meta-model byBecker

et al.(2007). +inner Reference +variableCharacterisation 0..* +namedReference 1 VariableUsage AbstractNamed Reference Namespace Reference Variable Reference Variable Characterisation <<enumeration>> VariableCharacteri- sationType VALUE TYPE NUMBER_OF_ELEMENTS BYTESIZE STRUCTURE type : VariableCharacteri- sationType RandomVariable specification : String referenceName : String

For accurate predictions all concrete values of all parameters should be available ide- ally. However, it is often infeasible to fully specify them - for specification as well as for analysis reasons. The resulting state space is simply to large to analyse. Additionally, it is often unnecessary for performance predicitions. In the sorting example, it is sufficient to know how many array elements should be sorted - the value of each element to sort does not matter performance-wise.

To deal with this, Koziolek et al. (2006) introduced five abstractions of parame- ters which allow to specify the performance critical information of parameters (see fig- ure3.12). All of them are represented by random variables in the PCM:

1. VALUE: This random variable contains the actual value of the parameter and should be used only in cases where no other characterisation is sufficient to capture the performance relevant aspect of the parameter. The type of the random variable is the same as the parameter’s type. As a consequence, this characterisation is only available for primitive data type, like integer, string, etc.

2. STRUCTURE: STRUCTURE random variables specify a certain characteristic of the data’s format. For example, for arrays an important information could be whether the array is sorted or unsorted, for a tree it might be whether the tree is balanced or not. Whether a certain structure of a parameter has an impact on the performance of a component service highly depends on the algorithms used to implement the ser- vice. Taking the sorting example again, for Quicksort it makes a difference whether the array is already sorted or not while for Heapsort it makes little difference. The type of the STRUCTURE random variable is an enumeration defined by the compo- nent developer.

3. TYPE: The TYPE random variable specifies information about a parameter in cases where the parameter can be used in a polymorphic manner and where the perfor- mance depends on its actual type. The type of the TYPE random variable is an enumeration containing all possible subtypes of the parameter’s type.

4. BYTESIZE: The BYTESIZE random variable is used to describe the memory foot- print of a parameter. It can be used whenever the amount of data processed makes a difference performance-wise. For example, analysis tools based on the PCM should use available BYTESIZE characterisations to determine network loads (see section4.6.3for the realisation in the simulation presented in this thesis). The type of the BYTESIZE random variable is Integer.

5. NUMBER OF ELEMENTS: The NUMBER OF ELEMENTS random variable is only applicable to parameters whose type is a CollectionDataType. For those pa-

rameters, it describes the element count of the elements in the collection. This type of characterisation is useful whenever a service iterates over a given set of ele- ments and the performance depends on the iteration count. The type of the NUM- BER OF ELEMENTS random variable is Integer.

Using these parameter abstractions, it is possible to characterise service parameters in the PCM using input VariableUsages. For example, to characterise the number of elements in a collection passed to a sorting service, the following can be specified

fieldToSort.NUMBER OF ELEMENTS = IntPMF[(10; 0.5)(20; 0.5)]

In this case fieldToSort must be the name of the formal parameter in the sorting ser- vice’s signature used to pass the collection to the service. The actual number is specified as random variable (using the stochastic expressions language). In the example, it has the value 10 in 50% of all cases and 20 in all other cases. Any input parameter having an IN or INOUT modifier can be characterised in this way.

Output parameters (having modifiers OUT or INOUT) and the return value of a ser- vice can be characterised using output VariableUsages. An output variable usage takes the result values or performance relevant characterisations of them and maps them to random variables in the calling SEFF. For this, the output VariableUsages create new lo- cal random variables and assign those variables the returned values. In case of mapping return or OUT parameter abstractions, the output VariableUsages introduce new random variables which have to be disjoint from those already existing in the calling SEFF. In case of parameters having INOUT modifiers the output mapping is restricted to characterisa- tions of the variable actually passed to the call as INOUT parameter. For example, when calling a service with the signature void m(INOUT a) binding a in the calling state- ment to b, i.e, m(b), the output mapping can only characterise abstractions of b. If the respective abstraction of b already exist, they are overwritten. Due to this restriction, the output mappings for INOUT parameters result automatically from the model. Analysis transformations should derive the respective mappings automatically, thus, lowering the specification effort.

For example, if the fieldToSort in the previous sorting example is an INOUT pa- rameter, the following output VariableUsage specification is derived automatically:

field.STRUCTURE = fieldToSort.STRUCTURE

where the sorting service guarantees that fieldToSort.STRUCTURE = "Sorted" to specify that it returns the field sorted. The next section explains how result characterisa- tions and output parameter characterisations are bound to values in the called service.