next up previous contents index
Next: Resource Demanding Service Effect Up: Service Effect Specification Previous: Description   Contents   Index

Types of Service Effect Specifications

Different types of SEFFs besides simple service lists and FSMs can be modelled to support different kinds of analysis (e.g., protocol checking, QoS analysis, etc.). If different SEFF types are defined for the same provided service, a mapping should exist between the FSM SEFF and the other types of SEFFs, which ensures the same names for provided and required services and the same order of calls to required interfaces.

SEFFs have been introduced by Reussner [7], who has used them in the context of parameterised contracts for protocol adaptation (Section 2.4). In that work, counter-constraint automata are used to model SEFFs restricting the number of calls to specific required services. Furthermore, using Petri nets to model SEFFs is envisioned to support concurrent component behaviour. However, assuring protocol interoperability is not possible if the component behaviour is modeled with Petri nets, because the language inclusion problem is undecidable for them in the general case.

While plain FSMs are well-suited for restricted protocol checking, they are generally insufficient for QoS analyses, because additional stochastic information and QoS characteristics (such as execution times or reliability values) are needed. Thus, several other forms of SEFFs have been proposed. For reliability prediction, Reussner and Schmidt [28] enhance SEFF FSMs with transition probabilities, so that they become Markov models. Similar Markov models enhanced with distribution functions for execution times have been used for performance predictions by Firus et. al. [29]. Happe et. al. [30] propose modeling SEFFs as stochastic Petri nets to enable QoS analyses involving concurrency. Koziolek et. al. [31] use stochastic regular expressions as SEFFs to make component-based performance predictions. These expressions are similar to Markov models, but are hierarchically structured and contain special constructs to model loops. Koziolek et. al. [32] use annotated UML 2.0 activities as SEFF models in the context of performance analysis. In [33] so-called resource demanding SEFFs have been introduced for QoS analysis, which have become part of the PCM and are described in Section 3.2.9.4.

In the PCM, a basic component can contain any number of SEFFs for each provided service, but at most one SEFF of each type, such as FSM or Petri net. A restriction on a particular SEFF type is deliberately avoided to enable different kinds of analyses. At the point of writing, the only SEFF type explicitly included in the PCM is the resource demanding SEFF. However, other types can be included in the PCM by inheriting from the class ServiceEffectSpecification. Consistency between different SEFF types has to be ensured by component developers, as it is not checked by the component model. If component developers implement a component based on a SEFF, it has to be ensured that the language of the SEFF is a superset of the language of the implementation.


next up previous contents index
Next: Resource Demanding Service Effect Up: Service Effect Specification Previous: Description   Contents   Index
Snowball 2007-03-16