Techniques

MRT approaches apply different techniques to achieve their objectives while at the same time accommodate to the system’s setup and specifics. To structure the techniques, they have been split up into three different groups: (1)system modification, i.e. maintaining the causal connection from model(s) to system, (2)system monitoring, i.e. maintaining the causal connection from system to the model(s), and (3)general techniques, i.e. tech- niques that are not directly attributed to system modification or monitoring but have an important role in managing and supervising MRT systems.

System modification: In order to maintain the causal connection from model(s) to sys- tem different techniques have been proposed. One is the usage ofexecutable models, i.e. models comply to a language that has an operational semantic and are, much like machine code, directly interpreted/executed by the system. For this model and program share the same representation and are inherently on the same level of abstraction [85]. One example promoting the usage of executable models isMEMO[67], a DSML for multi- perspective enterprise modelling that is syntactically and semantically specified using the meta-modelling language MML [66,67]. MML allows the definition ofintrinsic fea- tures, i.e. enabling the modelling of instantiation as meta-concept [66]. Johanndeiter et al. conceptually propose in [110] the usage of OrgML (a specialisation of MEMO) to be used as executable business process model. Another example is the employment of ex- ecutable models for Human-Computer Interaction as proposed in [18]. While the usage of executable models simplifies system modifications since changes in the model directly change the system behaviour, it does contradict the abstraction principle of MDE and DSMLs to some extent because problem and solution space are on the same abstraction level. Another technique used for system modification in MRT approaches is via model transformations such as M2M- and M2T-transformations as discussed in Section2.6.3. MRT approaches using transformations to modify the system are, for instance, solutions based on the Triple Graph Grammar (TGG), e.g. [82, 262, 265, 266], or on bidirectional QVT-transformations, e.g. [222,223]. On a more general note, a special challenge model- based system modifications need to address is how run-time changes affect current in- stances of the executable model entities, i.e. modification policies.

System monitoring: In the executable models system monitoring is usually not neces- sary since the models are directly involved in the system execution and can be queried via reflective methods (e.g. intrinsic features [66,67]). Transformations may also be involved

in the monitoring of the system, e.g. see TGG approaches [82, 265,266]. Generally, the technique of extracting state information from the system is calledintrospection [227]. Based on how the state information is extracted from the system three different types can be distinguished in MRT literature:

• Event log analysis: This monitoring technique is based on analysing a log contain- ing information about state transitions of the observed system. These event logs have to conform to a specified language in order to represent or be processed into run-time models. One system monitoring approach based on such transition logs is proposed by Mao in [141]: Here traces represent a model-based reflection that pro- vides a "unique visibility" into a system’s run-time state and thus enables model- based dynamic analyses. It is furthermore demonstrated that the trace itself can be viewed as a run-time model according to a definition by France and Rumpe in [65] if it conforms to a modelling language. It can certainly be argued that such a trace/log model fulfils both, the abstraction and causal connection requirements usually associated with run-time models. Another approach presented in [19] ex- tracts information from an event log to subsequently check its consistency with the corresponding model, i.e. conformance checking (see general techniques). In [215] events omitted by a web service application are processed "online"13and checked for run-time violations which in turn may initiate the enactment of defined recov- ery plans. Also in [99,151] direct event processing via CEP or sockets is proposed to extract the system’s context.

• Enhance observed system: If state transition data is not readily available an alter- native approach is to insert monitoring functionality into the observed system. The weaving of data extraction code into the system application is often realised through aspect-oriented concepts, e.g. [151, 271]. Some approaches monitor the system state on the bytecode level, e.g. [93], others through annotations or manipulations on a higher abstraction level such as (1) Abstract Syntax Tree (AST), e.g. [158], or (2) process model, e.g. [101], which then automatically translates into monitoring functionality at enactment. The connection between implementation and model in these cases is often maintained with the help of a traceability model (see Sec- tion2.6.3).

• Reflection API: In this case an interface on the target system already exists which al- lows extraction of state information at run-time. This is achieved with reflection APIs, e.g. provided by reflective middleware solutions such as OpenORB [17] or ReMMoC [86], the reflective data structure H-graph [85], or the multi-perspective enterprise modelling framework MEMO/MML [66,67].

13_{instead of an event log, a stream of events is directly accessed and analysed event-by-event (see Com-}

Plan Analyse

Monitor Execute

Running System

Fig. 2.28 Autonomic Control Loop: Monitor-Analyse-Decide-Execute (MAPE) Mecha- nism [116]

General techniques: Apart from mechanisms for system modification or monitoring, MRT approaches also use a set of other techniques in order to tackle the objectives intro- duced in the last section. One of the key concepts of adapting systems at run-time is a strategy that can be described asautonomic control loop[116,174,271]. One implemen- tation of the autonomic control loop is the Monitor-Analyse-Decide-Execute (MAPE - or MAPE-K with a shared knowledge component) procedure as displayed in Figure2.28[116]: In a first step the system (or a part of it) is monitored (see techniques for system monitor- ing). This data is further analysed, e.g. prediction, constraint violation, etc., and the re- sults are the basis for deciding/planning whether and how the system needs to adapt. In a last step the proposed adaptation is then enacted (see techniques for system modifica- tion). Depending on the MRT approach and its objectives the adaptations can encompass structural changes, e.g. in [266], as well as parameter adaptations, e.g. in [61], or both [30]. There are different ways to carry out the adaptive reasoning in the planning phase. Exam- ples are (1)logic-based reasoning, i.e. finding a configuration that is satisfying the current contextual constraints and requirements, e.g. [62,271], or (2)optimisation-based reason- ing, i.e. configurations are analysed for their quantifiable performance in order to find the best configuration according to specified goals, e.g. [61, 156, 157]. Approaches of both types often employ simulation or other predictive analyses to determine the per- formance potential of possible configurations or to verify impacts of planned changes, e.g. [61,156,157,271]. According to Fleurey et al. adaptation reasoning requires the fol- lowing types of input [62]:context,variants,constraints, andrules. The output of the rea- soning framework is an adaptation that matches the rules based on possible variants as well as context and satisfies the dependency constraints. Vogel et al. additionally include

strategiesandgoalsto allow for a wider range of adaptive reasoning techniques [267]. Fol- lowing the principle of "everything is a model" Vogel et al. propose in [263] the ExecUtable Run-timE MegAmodel (EUREMA), a domain-specific modelling language and a runtime interpreter for adaptation engines, i.e. a megamodel language to model and execute au- tonomic control loop techniques.

technique, i.e. corresponds to "modelling in the large", other techniques used by MRT ap- proaches rather correspond to "modelling in the small". Such smaller-scale mechanisms that have not yet been discussed are, for instance, (1)model conformance, i.e. a technique that usually compares information of different language levels (see Figure2.26): whether a model conforms to its meta-model or if model instance information is consistent with the corresponding model, (2)model comparison, i.e. an operation that compares two models and provides information about the differences, or (3)model annotation, a specialisation of model weaving (see Section2.6.3). For instance, model comparison is often used to compare current with designed model to identify deviations or with a planned model in order to determine which system modifications have to be carried out [62,99,267,271].