Variable/Parameter Characterizations

Design Rationale

Introduced variable characterisations to interfaces. Data types are now carrying those variable characterisations which become part of the contract of components. Before, variable characterisations were implicit assumptions of components (SEFFs) which were not explicitly exposed in interfaces. Now, it can be checked and ensured that all variable characterisations are present when calling a service (ExternalCallAction) and a SEFF can rely on that information internally. The new models semantics can be checked statically.
- Design alternatives:
  - Characterise single parameters from an interface (characterisations are fixed for a certain interface but can change when reusing a data type)
  - Characterise data types (when reusing the data type, the variable characterisations are fixed; transitively, the characterisations are fixed for interfaces) Selected solution
    - Pro:
      - Eases passing of data accross multiple components;
      - Performance-relevant characterisations are part of the contract of a component.
      - Static checks for un- or underspecified characteristics provide faster feedback and can point out the exact cause.
      - During reverse engineering consistent variable characterisations per data type are easier to determine by heuristics
    - Con:
      - Not all characterisations are performance-relevant for every component
      - Might imply overhead for specifying characterisations which are not used in a certain component.
Variable Charactersations are no more fixed to a enum defined at the model level. Instead, they can be extended at the model level. Variable Charactersiation now also have a data type associated.
- Pro:
  - Explicit data type allows dynamic type inference in StoEx
  - New characterisations (e.g. entropy) can be realised. This does not require a meta-model or tooling change anymore.
  - Semantics per variable characterisation can be more precise (no more bending of semantics of enum-defined characterisations)
  - The connection of characterisations to data types allows accurate and precise statements about performance-relevant properties.
- Con:
  - Increased complexity of StoEx editors etc. cannot rely on a fixed number of characterisations any more. A default repository for previously existing variable characterisations is recommended (VALUE, BYTESIZE, NoE, STRUCTURE, ...).
- Remark: Complexity for solvers and simulation: The presence of expected variable characterisation (e.g. Bytesize for data transferred via network; Number of Elements declaration for CollectionIterator) must be checked prior to analysis (argument also applies to previous realisation in the PCM).

Issues and Details

This section describes several issues connected with characterizations of variables or parameters. For each issue, details on the issue and design rational are provided as well as a example how a solution could look like. Its purpose is to start discussion and provide a reference for the meaning of elements.

DataTypes

Details

Data types describe the performance-relevant behvaiour of data types. Additionally, they support to describe structural properties of data types. A data type always has a fixed set of characteristics connected to it. Data types can be stored in a repository.

Example(s)

NotPerformanceRelevant of type PrimitiveDataType without characteristics.
Int of type PrimitiveDataType with characteristic BYTESIZE (characteristic value type long) which is in this example important for network transfers.
IntValue of type PrimitiveDataType with characteristic VALUE (characteristic value type int) and BYTESIZE (characteristic value type long).
IntList of type CollectionDataType with characteristic NUMBER_OF_ELEMENTS (characteristic value type long) build on the previously described Int data type.
Table of type CompositeDataType without characterstics but with members id of type IntValue and content of type IntList.

Discussion/Questions

Meaning of Interfaces: Performance-Relevant vs. Strucural/technical

Details

The meaning of the interfaces in PCM focusses on the performance-relevant parts instead of the structural parts. The datatypes of parameters reflect the performance-relevant properties of the interface. Structural equivalence with the code executing the function is not necessary at this point. However, code and performance-relevant interface can be mapped later on by PCMLink model instances. Two structural/technical similar interfaces which differ in their performance-relevant parts can be two different performance-relevant interfaces. However, they don't have to be (depending on the interface specification).

Example(s)

Performance-relevant interface:

process(IntNumber number, NotPerfRelevant data) with
IntNumber characteristics Bytesize and Value and
NotPerfRelevant of type PrimitiveDataType without characteristics.

Discussion/Questions

Structural/technical interface:

void process(int number, EObject complexStructure);

CollectionIteratorAction, special characteristic NUMBER_OF_ELEMENTS

Details

The collection iterator action allows modelling statistically dependent performance-prediction of collection data types.

Example

(None)

Discussion/Questions

Wouldn't it make more sense to introduce an StatisticalDependentEvaluationScope of type Action? This would allow to have the same effect but also use it with the other two data types. Upon (re-)entering the scope, all parameters are evaluated to fixed values which stay the same in the scope. This would also allow to use the construct outside of LoopActions.

Special variable INNER to reference element(s) of a CollectionDataType

Details

The element(s), not the collection itself, contained in a collection should be referenced in a well-defined way. In the old meta-model, the special characterization INNER was used for that.

Example

IntList of CollectionDataType build on Int data type. INNER would refer to the int data type and its characterizations, whereas a variable of type IntList would allow to access the characterizations of the IntList data type.

Discussion/Questions

Suggestion: Introduce a Variable with the name fixed to INNER by convention/OCL constraint as well-defined way. In the meta-model this would mean changing the reference CollectionDataType->DataType to CollectionDataType->Variable and adding the OCL constraint. Pro: Same handling as 'normal' variables/parameters. Con: It has to be ensured on creation that the OCL-constraint is fulfilled.

ExternalCallAction, special variable/parameter RETURN

Details

The information returned by an external call must be accessible in the called (RD-)SEFF itself as well as the calling SEFF. In the old meta-model the parameter RETURN was used for that.

Example

Call to the operation PROCESS of an interface (assume the operation does not have input parameters, it just returns an IntValue).

Discussion/Questions

Suggestion: Introduce a Variable with the name fixed by convention to either RETURN or the name of operation (e.g. PROCESS). In the meta-model, this means adding an OCL constraint for the reference returnType__OperationSignature. Pro: Same handling as 'normal' variables/parameters. Con: It has to be ensured on creation that the OCL-constaint is fulfilled.

Containment of DataType(s) and Definition of Characterizations, PrimitiveTypeEnum

Details

DataType(s) are directly contained in a repository. It is planned to have a common set of data types which can be reused in PCM models.
CharacterisationDefinition(s) are directly contained in a repository. It is planned to have a common set of characterisations which can be reused in PCM models. Examples are BYTESIZE, NUMBER_OF_ELMENTS, VALUE(INT), VALUE(BYTE), ... .

Example (Meta-model level)

Repository <>1--*> DataType
Repository <>1--*> CharacterisationDefinition
DataType --*> CharacterisationDefinition
CharacterisationDefinition --|> Entity

CharacterisationDefinition

description : EString
valueType: CharacteristicValueTypeEnum (formerly: PrimitiveTypeEnum)

Discussion/Questions

The example does not match the current version in the branch anymore. It had been changed until it went into the branch. However, i consider the design described in example as a goal.

IN/OUT/INOUT Parameter

Details

Parameters of operations could be either IN, OUT, or INOUT. However, this information was implemented throughout the PCM. INOUT and OUT were not accessible from the calling action. Parameters for operation are always considered IN, as there are no references passed between components. Parameter passing is assumed to be by-value. Complex return parameters can be modeled separately as return data type of the operation. The returned parameter/value of an operation is considered OUT.

Example

IntValue process(Int a, Int b)

a could be INOUT and b OUT. a and b could be considered additional return parameters.

Discussion/Questions

According to the discussion by email and the details given above, the modifiers IN, OUT, and INOUT are removed. All parameters of an operation are assumed IN, the output parameter OUT.

Setting Variables and their Characterisations

Details

The characterisations of variables must be settable for component parameters, operation parameters, return parameters, ... .

Example

(see Datei:SettingVariables(Draft).PDF)

Discussion/Questions

Matching of current proposal to StoEx is not clear yet and open for discussion.
Chris saw the 'grouping' of all characterisations for one variable as advantage.
VariableSetter could be renamed to VariableCharacterisationsSetter.

Component Parameters

Details

Components should have parameters, e.g. the to model the size of a thread pool. Default values for a component are desirable. These defaults can be overwritten on allocation. Component Parameters are different from PassiveResources, as they reflect settings and not a specific resource.

Example

Component A has the parameter ThreadPoolSize of type IntValue with the characteristic VALUE = 5; Component A has the passive resource ThreadPool with the capacity equal to ThreadPoolSize.VALUE;

Discussion/Questions

Suggestion: (only the last line is realized in the current branch)

ImplementationComponentType --|> Variable
ImplementationComponentType --|> VariableSetter
AssemblyContext --|> VariableSetter

Characterisation Default Values

Details

Default values for characteristics might help entering only the required information.

Example

The characteristic VALUE(INT) should be 0 by default.
The characteristic BYTESIZE for the datatype IntValue can be 8 by default.

Discussion/Questions

Suggestion:

CharacterisationDefinition <>--defaultValue,0..1> PCMRandomVariable
DataType <>--defaultValues,*> CharacterisationValue