Descriptive Models at Run-time

In many cases, approaches in the MRT domain are regarded as holistic solutions for self- adaptation for which both directions of the causal connection between a run-time model and system are to be maintained. This is often achieved either (1) through a shared rep- resentation in the form of an executable model on the solution space (see Figure2.29and Section2.7.2), e.g. [18,110,153]), or (2) through bidirectional transformations (which al- low for some level of abstraction to the problem space), e.g. [82,222,223,265,266].

However, in domains where a greater gap in abstraction between models and man- aged system prevails, it is more difficult to maintain a causal connection between sys- tem and the run-time models. One such example domain is "IT Service Management" as introduced in Section 2.7.3 (see Figure 2.30 on page 77): In this scenario it is dif- ferentiated between an "as-is" and a "to-be" model; while the "as-is" model contains

Fig. 2.32 Run-time Models for Monitoring in Maintenance [264]

monitored/extracted information of the current state of the managed system, the "to-be" model specifies what the system should behave like [267]. Using the terminology estab- lished in the previous section, that means the "as-is" run-time model consists solely of a descriptive part and thus may also be called adescriptive run-time model. Similarly, the "to-be" model solely consists of a prescriptive part and thus can be also called apre- scriptive run-time model. The separation of concerns through a differentiation between descriptive and prescriptive run-time models has the additional benefit of allowing for other actors than the MRT system to be the driver of change, thus supporting the man- agement of so calledopen systems [79,80]. That means, this concept allows for dealing with a system change caused by an external source (e.g. exceptional behaviour, chang- ing environment). In contrast, holistic closed-loop concepts based, for instance, on exe- cutable models or bidirectional transformations assume an isolation of the system from external influences, i.e. the system will always act according to the behaviour specified in the model and not allow for deviations.

Another benefit of this differentiation is showcased by Vogel and Giese in [264] where different maintenance and self-adaptation scenarios for the adjustment of a faulty appli- cation (original approach proposed in [35]) are investigated. For the different scenarios all actors and models are associated to either the system, the user, or the engineer, i.e. defining the managing entity of the agents and models. The association to the entities for each scenario is dependent on the purpose of the MRT solution but also on what kind of interactions with the system are permitted, i.e. what model access possibilities are sup- ported by the managed system. Note, that the entities basically represent different stages of an application’s traditional lifecycle, i.e. engineer→design, user→ implementation, system→ enactment/execution. Figure2.32shows the associations for the scenario of "monitoring in maintenance". With increasing autonomy of the investigated scenarios in [264], e.g. "execution in maintenance" and "self-adaptation", an increasing number of models and agents move into the system’s sphere of influence, i.e. become run-time mod- els/agents. The different scenarios showcase that differentiating between descriptive and prescriptive run-time models is helpful to (1) separate concerns, i.e focus on particular challenges for system monitoring, adaptive reasoning, and system modification individ- ually, and (2) scale the level of autonomy to an appropriate level, i.e. appropriate for the

abstraction level of the domain (e.g. autonomous reasoning possible vs. domain-expert reasoning required) while taking the available support for system access into account (e.g. autonomous system modification possible vs. software-expert required for change im- plementation). In conclusion, the additional conceptual flexibility achieved by the differ- entiation of descriptive and prescriptive run-time models yields the following important benefits in comparison to holistic closed-loop concepts:

• allows for other drivers of change than the MRT supervision system,

• enables a greater variety of objectives, e.g. conformance checking, error handling, • different scales of lifecycle autonomy are supported, e.g. self-adaptation vs. adap-

tation reasoning by domain experts, and

• separating concerns for system monitoring, adaptive reasoning, and system adap- tation.

All four benefits are helpful when addressing domains that feature models of high ab- straction levels (e.g. business processes) where the causal connection between model and system is difficult to establish. This is further emphasised by the shift of focus in MRT publications in recent years: They concentrate less on low level self-adaptation issues but are more specialised and cover a wider application range, i.e. are user-centric, domain- specific, and goal-oriented [11].

In the context of the differentiation between these two types of run-time models and the consequential separation between the two directions of the causal connection, a de- scriptive run-time model can be defined asa causal reflection of the associated system’s current status from a problem space perspective. Research in the domain of descriptive run-time models can therefore focus on domain-specific challenges that are concerned with reflecting different dimensions of change, e.g. reflecting change on both levels: model type and model instance, and maintaining a causal connection from system to descriptive run-time model, e.g. overcoming a possibly existing abstraction gap between the avail- able system data and the domain-specific model. Figure2.33demonstrates the relation of a descriptive MRT to the system as well as to potential other relevant types of mod- els that are directly interacting with the system, i.e. design model and prescriptive MRT. Models on the meta level which are not directly interacting with the system, e.g. models for reasoning such as rule, constraint, or goal models [62,267], are not regarded in this context since they address a different concern (that of adaptive reasoning). The figure en- hances the comparison between MDE and MRT concepts from [9] shown in Figure2.27 on page70. Similarly it highlights that run-time models (descriptive and prescriptive) have a conceptually closer link to the system than design model. In this simplified view three different scenarios for descriptive MRT relationships are displayed:

1. In the first scenario (all elements in red, purple, or black colours) a design-time model is the basis for establishing a system instance via compilation, transforma- tion, implementation, or configuration depending on the employed MRT concept

Optional: Comparison, Weaving Optional: Comparison, Weaving Causal Connection (System -> DMRT) Descriptive MRT Design Model Compilation, Transformation, Implementation, Configuration System Design-time Run-time Prescriptive MRT Causal Connection (PMRT -> System) Transformation, Synchronisation, Deployment

Fig. 2.33 Schematic View on Relations between Descriptive Run-time Models, other Model Types, and the System

of the scenario. The descriptive MRT is conceptually linked with the design model via model weaving techniques, e.g. model enhancement, or model comparison for reasoning purposes, e.g. identifying constraint violations based on monitored run- time data [61,93,94,99,215].

2. In the second scenario (blue, purple, and black colours) a prescriptive MRT is defin- ing the functionality of the system instance via system modification techniques (see Section2.7.2). The prescriptive MRT is usually connected with a design model and updated via transformation, synchronisation, or deployment depending on the em- ployed MRT concept of the scenario. Similar to the scenario 1 the descriptive MRT is conceptually linked with the prescriptive MRT via model weaving techniques or model comparison. An example of this scenario is presented in [81,267] and shown in Figure2.30on page77 with "As-Is-Configuration Model" being the descriptive MRT and the "To-Be-Configuration Model" the prescriptive MRT. Other examples of this scenario based on a prescriptive and descriptive MRT relationship are pro- posed in [62,271].

3. In the third scenario (only black colour) the descriptive MRT is a single entity inde- pendent from possibly existing design models or prescriptive MRTs. It has the sin- gle purpose of directly and accurately discovering problem level information and/or the system’s reflective state from solution level data to enable further reasoning (this may include model comparisons however). Solutions of this scenario of indepen- dent descriptive run-time models are proposed for architecture models [208], trace models [141,142], Queueing Networks [80] or protocol behaviour models [79]. Descriptive MRTs in scenarios 1 and 2 often featuremodel weavingtechniques which link to higher level information from the design model or prescriptive MRT. These cases focus onmonitoring the system’s state on the instance level and associate it with the (existing)

information on the model level, e.g. [61,93,94,99, 215]. This is different in scenario 3 (and scenarios 1 and 2 based on model comparison) for which additionally the higher level (problem space) models have to bediscoveredfrom lower level (solution space) data received from the system, e.g. [79–81,141, 142,208, 267]. While this makes it harder to maintain the causal connection between system and the descriptive MRT it allows for more system flexibility (as discussed earlier in this section). In the domain of business processes the method of extracting problem space models (BP models) from solution space data (BP event logs) is referred to asprocess discoveryand discussed in Section2.4.

Note, that the definition of descriptive MRT provided is strongly associated with that of context models [62,151,267] or situation models [25], similarly describing the opera- tional environment of the system. Context is defined in [53] as"...any information that can be used to characterize the situation of an entity. An entity is a person, place, or object that is considered relevant to the interaction between a user and an application, including the user and applications themselves." One difference, however, is that context models can also include environmental context (e.g. the current temperature or customer satisfac- tion) which is not describing the application system but an entity that may be influencing it. Another difference is that it is often not associated with structural information (on the problem space level) but with quantifiable measures or key-value pairs, e.g. in [62,151].

In summary, with regards to the introduced objectives (see Section2.7.1) descriptive MRTs aim to fulfil that of monitoring, abstraction, and platform-independence but also act as enabler for the other objectives such as simulation, prediction, adaptation, and fault error handling. The different techniques for obtaining the information in order to maintain the causal connection are discussed in Section2.7.2: System Monitoring, e.g. event log analysis, system enhancement, or reflection APIs. The resulting descriptive MRTs are diverse and can range from simple measurable sensor data to discovered struc- tural information on the domain-level. In the former case model weaving techniques are often employed to connect domain-level models and low-level sensor data, e.g. through model enhancement. In the later case elaborate data mining algorithms have to be em- ployed to infer or update the domain-specific descriptive MRTs.