=Paper=
{{Paper
|id=Vol-2245/mrt_paper_4
|storemode=property
|title=Towards Software Architecture Runtime Models for Continuous Adaptive Monitoring
|pdfUrl=https://ceur-ws.org/Vol-2245/mrt_paper_4.pdf
|volume=Vol-2245
|authors=Thomas Brand,Holger Giese
|dblpUrl=https://dblp.org/rec/conf/models/BrandG18
}}
==Towards Software Architecture Runtime Models for Continuous Adaptive Monitoring==
https://ceur-ws.org/Vol-2245/mrt_paper_4.pdf
Towards software architecture runtime models for
continuous adaptive monitoring
Thomas Brand Holger Giese
Hasso Plattner Institute, University of Potsdam Hasso Plattner Institute, University of Potsdam
Potsdam, Germany Potsdam, Germany
thomas.brand@hpi.uni-potsdam.de holger.giese@hpi.uni-potsdam.de
ABSTRACT of monitorable properties and dynamically allocating monitoring
A software architecture runtime model provides an abstraction effort to produce only currently relevant monitoring results.
that allows to reason about a running system. For example, a self- Besides changing information demands also the represented
adaptive system can employ the model to detect phenomena which running system can evolve over time, for example, due to the de-
make an adaptation beneficial. O ver t ime o ther p henomena can ployment of a new software component release. This can require
become interesting and thus make the monitoring of different sys- the adaptive monitoring to maintain new kinds of information
tem properties necessary. Typically properties are declared in a in the runtime model, too. Consequently, the runtime model also
meta-model as part of application specific model element classifiers. needs to evolve accordingly with the running system [3].
In this case adding new properties requires the creation of a new A software system can be built for continuous operation without
runtime model instance based on the updated meta-model version. downtime even when it evolves. Its runtime model needs to support
In contrast, a more flexible approach allows altering the set of prop- this evolution without interruption to enable continuous adaptive
erties in the runtime model without creating a new model instance monitoring and hence continuous phenomena detection and rea-
and thus without interrupting the phenomena detection process. In soning about the system. This is especially relevant if evolution
this paper we elaborate requirements for a runtime model modeling occurs frequently for example caused by the currently fostered
language which shall enable continuous adaptive monitoring. very short software release cycles and experimentation in software
product development [7].
Reference Format: An idea to enable continuous adaptive monitoring is to utilize a
Thomas Brand and Holger Giese. 2018. Towards software architecture run-
runtime model modeling language which supports the co-evolution
time models for continuous adaptive monitoring. In Proceedings of 13th
of the system and the model as well as changing information de-
International Workshop on Models@run.time (MRT 2018). 6 pages.
mands without the need to re-instantiate the runtime model and
thereby avoiding an interruption. Such a modeling language with
1 INTRODUCTION a reusable implementation to create and maintain runtime models
A runtime model which abstracts a running system to its architec- would also reduce the effort to employ them and likely foster their
ture is a common practice for reasoning about the system [14]. The use. Thus, we want to find out more about the related requirements.
runtime model is maintained through monitoring to reflect relevant Our contribution with this paper is a set of elaborated require-
system changes in the model. A key question is, what information ments for a modeling language to create and maintain evolvable
to obtain and represent in the model [5], especially as advances in runtime models that support continuous adaptive monitoring of
information technology allow capturing more and more pieces of a running system. For an prospective approach we describe dif-
data. The answer to this question needs to consider the purpose for ferent illustrative scenarios from which we derive and generalize
which the model is maintained as well as cost-effectiveness [12]. the requirements. Additionally, we investigate two state-of-the-art
However, over time the information demand, which the runtime approaches regarding their support for the scenarios and require-
model needs to satisfy, can change regarding the level of abstraction, ments to identify beneficial and missing features.
that is the set of monitorable properties, and for which of those To the knowledge of the authors no reusable modeling language
up-to-date monitoring results are currently beneficial. has been described and evaluated for runtime models that support
Triggers for such changes might for example be the temporary continuous adaptive monitoring. Nor have requirements for such a
exploration of new features through machine learning, altered poli- language been elaborated before. Thus, this paper can be seen as a
cies or monitoring results that lead to obtaining and incorporating step towards software architecture runtime models for continuous
additional information [6]. Adaptive monitoring allows focusing the adaptive monitoring.
attention according to the information demand by altering the set In Section 2 the terminology used in this paper is introduced. In
Section 3 we describe the scenarios and in Section 4 the derived
requirements. Then we investigate two state-of-the-art approaches
Permission to make digital or hard copies of part or all of this work for personal or
classroom use is granted without fee provided that copies are not made or distributed in Section 5 regarding their support for scenarios and requirements
for profit or commercial advantage and that copies bear this notice and the full citation and outline a prospective runtime model modeling language to
on the first page. Copyrights for third-party components of this work must be honored.
For all other uses, contact the owner/author(s).
support continuous adaptive monitoring. Finally, we conclude and
MRT 2018, October 2018, Copenhagen, Denmark provide an outlook regarding future work in Section 6.
© 2018 Copyright held by the owner/author(s).
MRT 2018, October 2018, Copenhagen, Denmark T. Brand et al.
2 BACKGROUND is to selectively enable and disable the production of monitoring
In this section we introduce the terminology used in this paper. A results for the monitorable properties within this set.
runtime model is defined as "an abstraction of a running system Continuous in the context of adaptive monitoring shall mean
that is being manipulated at runtime for a specific purpose" [2]. that monitoring results can be provided to their consumers without
There are different types of runtime models. This paper considers interruption. This also needs to be the case while a runtime model,
software architecture runtime models [14]. Those runtime models which is used to access the monitoring results, is evolving in order
are graph-based data structures. They allow storing, querying and to support monitoring tasks which were unforeseen at design time.
accessing configurational as well as operational information about With this paper we are interested in supporting continuous adaptive
the running system. Configurational information comprises the monitoring through a modeling language which allows runtime
system parameters and the structure of the system with its parts model evolution with the same model instance and thus avoiding
and relationships. Operational information is a specific behavioral evolution related interruptions.
runtime aspect. It is caused or produced by the running system.
An example is a component invocation count for a certain time 3 SCENARIOS
window. Overall runtime models help "to handle the complexity of In traditional engineering with design time models and also usually
adapting or generally managing running software systems" [15]. when runtime models are employed, the abstraction respectively
A modeling language is constituted by "the structure, terms, nota- reduction is determined at design time. However, in the future
tions, syntax, semantics, and integrity rules that are used to express systems must be able to learn and adapt to unanticipated changes
a model" [10]. One way to describe a modeling language is by mod- in the context and therefore also the abstraction respectively re-
eling it. The model used to model the modeling language is called duction present in the runtime models has to change at runtime.
meta-model. Typically, classifiers for model elements are defined in For example, machine learning techniques often permit to identify
the language meta-model. A set of classifiers which belong together which features are helpful for predictions and therefore future sys-
shall be called classifier system. An implementation of the modeling tems require runtime models which (1) can be extended such that
language allows to programmatically create and maintain language new features could be explored and which (2) can be reduced to
conform models. For example, the Eclipse Modeling Framework those features that are in fact really exploited for the predictions.
(EMF) allows generating a modeling language implementation from Thus, deciding only at design time about the information that is
the language meta-model [13]. Typically language changes require represented and maintained in the runtime model is not sufficient.
repeating the code generation and re-instantiating the model by We argue that an evolvable runtime model instance could sup-
reloading or recreating it with the new implementation release. port continuous monitoring of a running system. The following
As an ongoing abstraction of a running system a runtime model illustrating scenarios [1] describe exemplarily situations which can
changes frequently in comparison to design time models. A change occur with a system employing a runtime model. We use them to
in a runtime model can, for example, be triggered when an auto- derive requirements which are later generalized in Section 4 for a
mated control loop temporarily increases the value of a system modeling language enabling evolvable runtime model instances.
configuration parameter to support the current workload of the
system. Such mostly short-term and easily reversible adaptations
shall be considered as ordinary runtime model changes. In contrast, 3.1 Running system changes
evolutionary runtime model changes shall be those which involve First we describe the scenarios related to changes of the running
defining a new or altering an existing classifier for runtime model system and derive the resulting requirements which need to be
elements. This usually requires a new release of the runtime model- supported in combination with continuous adaptive monitoring.
ing language and its implementation as well as a re-instantiation of To make the scenarios more tangible we consider the ebay-like
the model. In this paper we will discuss another approach to change mRUBiS SEAMS exemplar [16] as the running system.
a runtime model classifier system and evolve the runtime model
without this kind of interruption. Possible triggers for the runtime S1 - System adaptation. The owner of the mRUBiS online auction-
model evolution shall be changes in the information demand re- ing platform wants to ensure that the running system provides
garding the set of monitorable properties or the evolution of the a high quality of service and thus utilizes autonomic computing.
represented system, for example, when a new kind of component In this scenario the employed system adaptation engine automati-
is introduced in the system as a long-term enhancement. It shall cally restarts the malfunctioning query service of the system and
be noted that in general the co-evolution of a runtime model and increases the value of the corresponding instances pool size param-
the represented running system is a relevant subject in the runtime eter. Those temporary changes to the system are also reflected as
model research field [3]. ordinary changes in the runtime model. Changes in this adaptation
Adaptive monitoring helps to control the monitoring effort and scenario do not alter the configuration possibilities of the running
focus on the information that is currently valuable. With regard to system nor what information the runtime model can contain. Re-
runtime models we consider two dimensions of monitoring adapta- sulting requirement: Update system representation structure while
tion. The first dimension is to change the level of abstraction for the service restarts as well as the pool size parameter value (R1).
the runtime model or individual parts of it by altering the set of
S2 - System evolution. The system owner wants to permanently
monitorable system properties. This comprises properties for con-
enhance the functionality of the system by providing the users
figurational and operational information. The second dimension
with an additional new payment option. The owner deploys the
Towards software architecture runtime models for continuous adaptive monitoring MRT 2018, October 2018, Copenhagen, Denmark
corresponding add-on component from a third party software man- the service which all the instances provide together. This aggrega-
ufacturer to the system and wants the component to be represented tion is performed by the monitoring instruments maintaining the
in the runtime model, too. However, that this particular kind of runtime model. Hence, the details of the aggregation are hidden
component would be added to the system one day was not foreseen. from the runtime model.
Thus, a runtime model classifier for the component needs to be The second aggregation is called entity aggregation by structure
defined belatedly. Resulting requirement: Add a classifier for the where lower level entities for example integrated components are
new component (R3). represented by one higher level entity such as a subsystem [8].
Another difference to the first aggregation is that this time the
S3 - Software evolution. The software manufacturer is currently aggregation takes place in the runtime model and all involved
working on a new release of the inventory component and wants entities shall be present in the model. In this scenario actually an
to perform an experiment with the new version based on real data exception counter is introduced which aggregates the counts of all
and user traffic. Thus, some online shop tenants, so called early early adopter tenants to alert about its speed of increase.
adopters, get a new version of the inventory component deployed. Please be aware that in general an aggregation can occur on the
Now two versions of the inventory component with different sets level of the monitoring instruments or on the level of the runtime
of properties need to be represented in the runtime model - the old model where it is modeled as part of the runtime model. When
for the normal tenants and the new for the early adopters. Please aggregating on monitoring instruments level then only the aggre-
note that applying the result of software evolution to a system gation result is represented in the runtime model and its compo-
instance, for example, by deploying a new software component sitional structure remains transparent to runtime model queries.
version, causes system evolution, too. Resulting requirement: Add When aggregating on the runtime model level then the composi-
a new classifier with the same name but a different version number tional structure of the aggregation is modeled and can be queried
for the new component release (R3). in the runtime model.
S4 - Systems integration and division. In this scenario the system Resulting requirements: Use logical elements and relationships
owner is able to expand the business to another region by buying to represent the aggregation results in the runtime model (R8),
a company there. Instead of operating two systems some parts introduce new classifiers for the aggregation results (R3), withdraw
of the bought system shall be integrated and others be gradually obsolete classifiers for the component instances which are no longer
migrated. Both systems have their own runtime model classifier represented in the runtime model (R4), establish relationships to
system which shall coexist and stepwise be harmonized. In the indicate which components the subsystem comprises (R5).
meantime the risk of classifier name clashes needs to be precluded.
Resulting requirements: Support the two different classifier systems S7 - Itemization. In this scenario the system owner wants to better
in the runtime model (R7), represent relationships between the parts understand why the user management service sometimes becomes
of the integrated systems (R5), withdraw obsolete classifiers after very slow. Thus, the owner introduces additional monitoring ca-
the corresponding components have been migrated (R4). pabilities which enable itemizing the service and monitoring its
individual subcomponents. The additional data is supposed to help
localizing and tackling the response time problem with the service
3.2 Information demand changes
effectively. This scenario could also be combined with the filter
The scenarios about information demand changes including those scenario (S5). Whenever the response time of the user management
regarding the required abstraction level are: service drops below a threshold then the expensive detailed moni-
S5 - Filtering. In this scenario the system owner wants to use ma- toring of its subcomponents could only temporarily be activated.
chine learning to explore the runtime model and identify those Resulting requirements: Introduce the classifiers of the subcompo-
monitorable properties per tenant shop, which are good indicators nents (R3), establish the relationship between the user management
for when to preemptively increase the resources for the bid and buy component and its subcomponents (R5), optionally activate the
service to efficiently avoid long response times. For the selected monitoring of the subcomponents only when the response time
monitorable properties the production of monitoring results shall dropped below the threshold (R2).
be continued after the exploration phase. Not required monitoring
S8 - Generalization and specialization. As part of the running system
shall be deactivated afterwards for cost reasons. A generic adaptive
each of the online shops can have up to ten different item filters
monitoring approach based on the actual information demand re-
that determine which products are displayed to a shopping user. To
garding currently relevant monitoring results has been described in
indicate potential for configuration optimization the system owner
[4]. An approach using machine learning to identify indicators for
wants to regularly provide a report for each shop about the two
selecting a system self-healing option is presented in [9]. Resulting
filters which filtered the fewest respectively the most items. Instead
requirement: Indicate the actual information demand (R2).
of having to consider each of the ten filter types individually in
S6 - Aggregation. This scenario covers two different kinds of aggre- a complex runtime model query the system owner prefers a sim-
gation which this time also happen at two different places. The first ple query. This query considers all currently deployed filters in a
aggregation is called entity aggregation by function [8]. In this case general way not distinguishing between the particular filter types.
the runtime model shall abstract from the individual query compo- This is possible because the relevant properties are common to all
nent instances, which perform the same functionality in parallel, to filter types. To be able to use the simple query the owner introduces
one runtime model representation, which allows reasoning about a mechanism which ensures that each filter gets assigned to the
MRT 2018, October 2018, Copenhagen, Denmark T. Brand et al.
generic filter classifier in addition to its specific classifier. As a re- R7 - Multiple integrable classifier systems. The modeling language
mark, in the case of specialization a more specific classifier would and its implementation shall allow that a runtime model has mul-
have been assigned. Resulting requirements: Additionally assign tiple classifier systems concurrently. Also it shall be possible to
the general classifier to each filter (R6). link parts which have been classified with different classifier sys-
tems and to introduce the classifier systems at different points in
It needs to be stated that beyond the described scenarios in gen- time programmatically and without the need to re-instantiate the
eral filtering, aggregation, itemization, generalization, and special- runtime model. In order to preclude naming conflicts an explicit
ization shall be possible in the runtime model for structural or support for namespaces shall be offered.
value-based monitoring results alike.
R8 - Introducing logical elements and relationships. The modeling
4 REQUIREMENTS language and its implementation shall support logical model ele-
ments and relationships which do not physically exist in the running
In this section we generalize and describe the in Section 3 derived system for example for business related grouping purposes or to
requirements in more detail. For all requirements applies that the store derived information in the runtime model. It shall also be
corresponding solutions shall allow consumers to access monitoring possible to introduce corresponding classifiers programmatically
results through the runtime model continuously. Continuous adap- and without the need to re-instantiate the runtime model.
tive monitoring shall be achieved without the need to re-instantiate
the runtime model.
5 APPROACHES
R1 - Updating system representation structure and values. The run- Now we want to investigate to what extent two state-of-the-art
time model modeling language and its implementation shall allow approaches support our scenarios for continuous adaptive moni-
updating the structure and values of the system representation toring and the derived requirements. For this we consider the clas-
programmatically. It shall be possible to add and remove repre- sical model driven engineering approach and an existing runtime
sentations of system parts and relationships as well as change the model modeling language called CompArch [16]. For the classical
values of other monitorable properties. This requirement only cov- approach we assume that a runtime model modeling language is
ers changes to the model content representing the running system. defined which is specific to the running system and its domain.
This language shall be considered as not intended for reuse with
R2 - Indicating the actual information demand. The modeling lan-
other systems and rather inflexible regarding unforeseeable runtime
guage and its implementation shall allow recognizing attempts to
model changes. In contrast the CompArch language is designed
access monitoring results in the runtime model and processing
and reused for different scientific experiments with runtime models
the corresponding notifications programmatically. This allows the
in the context of self-adaptive systems. Thus, it already provides
monitoring to adapt the production of monitoring results to the
a certain degree of flexibility. However, as its design goal did not
actual demand in a generic way as described in [4].
explicitly comprise the support for continuous adaptive monitoring
R3 - Introducing new classifiers including classifier versions. The it can also be used to illustrate the need for some additional fea-
modeling language and its implementation shall allow defining and tures. At the end of this section we outline a prospective approach
afterwards using new classifiers in the runtime model programmat- based on a modeling language which is supposed to support the
ically and without the need to re-instantiate the runtime model. described requirements and scenarios. Table 1 and Table 2 provide
It shall also be possible to programmatically distinguish different an overview by listing the scenarios respectively requirements and
versions of a classifier without parsing the classifier name. Thus indicating how they are supported by the discussed approaches.
explicit versioning support is required.
R4 - Withdrawing obsolete classifiers. The modeling language and Table 1: Supported illustrative scenarios per approach
its implementation shall allow removing classifier definitions which
are no longer required. This shall be possible in a programmatic
manner and without the need to re-instantiate the runtime model. Support per approach
Illustrative scenario Classical CompArch Prospective
R5 - Establishing new kinds of relationships. The modeling language
and its implementation shall allow creating relationships with a S1 - System adaption X X X?
new classification programmatically and without the need to re- S2 - System evolution – (X) X?
instantiate the runtime model. This means that the decision what S3 - Software evolution – (X) X?
relationships of a system part can be represented in the runtime S4 - Systems integration – – X?
model shall be changeable after the design time. and division
S5 - Filtering (X) (X) X?
R6 - Assigning multiple classifiers. The modeling language and its S6 - Aggregation – – X?
implementation shall allow that system parts and relationships S7 - Itemization – – X?
represented in the runtime model can have multiple classifiers. S8 - Generalization and – – X?
Further it shall be possible to assign those classifiers at different specialization
points in time. This shall be possible programmatically and without
Xsupported, (X) partially supported, X? shall be supported, – not supported
the need to re-instantiate the runtime model.
Towards software architecture runtime models for continuous adaptive monitoring MRT 2018, October 2018, Copenhagen, Denmark
Table 2: Supported requirements per approach
Support per approach
Requirement Classical CompArch Prospective
R1 - Updating system representation structure and values X X X?
R2 - Indicating the actual information demand (X) (X) X?
R3 - Introducing new classifiers including classifier versions – (X) X?
R4 - Withdrawing obsolete classifiers – X X?
R5 - Establishing new kinds of relationships – – X?
R6 - Assigning multiple classifiers progressively – – X?
R7 - Integrating multiple classifier systems – – X?
R8 - Introducing new logical elements and relationships – (X) X?
Xsupported, ( X) partially supported, X? shall be supported, – not supported
5.1 Classical approach 5.2 CompArch approach
With the classical approach the decision what kind of information The classifier system of the EMF-based CompArch approach is
the runtime model can contain, that is which classes of elements split. Software engineering approach specific classifiers such as
and properties, is solely made during design time of the modeling component and connector are defined in the modeling language
language. The supported classifiers and properties of the runtime meta-model. A small fragment of the CompArch meta-model is
model modeling language are defined in the meta-model as shown depicted in Figure 2. Like with the classical approach all classifiers
exemplarily in Figure 1. Using, for example, EMF allows defining the defined in the meta-model cannot be changed easily. Thus, with
modeling language and generating source code to programmatically CompArch those classifiers are comparatively generic. However,
create and maintain models based on this language. the CompArch meta-model also defines classifiers shown on the
Changes to the language imply that the model becomes tem- left side of the meta-model in Figure 2 which allow the specification
porarily unavailable due to the repeated source code generation of additional more domain-specific classifiers as part of the runtime
and the execution of other migration tasks. We want to enable model classifier definition content, for example, as the query service
continuous adaptive monitoring through a very long lifetime of component classifier is defined in Figure 2. Also following the core
runtime model instances. Thus, the classical approach only sup- of the dynamic object model pattern [11] those specific classifiers
ports those requirements and consequently scenarios for which can be modeled with an additional model element for each of their
it does not require a re-instantiation of the runtime model that properties. A runtime model element of the system representation
means it does not need to be reloaded or recreated due to source content can be classified by referencing a classifier defined in the
code changes of the modeling language implementation. As Table 2
shows, requirement R1 is supported and requirement R2 only par- Modeling language definition content
tially as the required notification mechanism needs to be explicitly
MonitoredProperty
added to the modeling language implementation as described in name : String
*
[4]. The other requirements which demand more flexibility are not type : String
value : String
supported by this approach. The supported requirements indicated 1 *
ParameterType Parameter
in Table 2 and the resulting requirements listed per scenario in Sec- name : String * * value : String
tion 3 allow deriving the illustrative scenarios that are supported type : String
1 1 1
by the classical approach. They are also indicated in Table 1. ComponentType Component
name : String 1 *
Meta-model level
Runtime model level <>
<>
<>
classifies 4
ComponentType :Component
name = "QueryService" <>
QueryService classifies 4
ParameterType :Parameter
poolSize : Integer name = "poolSize" value = "5"
upTime : Long type = "Integer"
Meta-model level Modeling language definition content <>
:MonitoredProperty
Runtime model level <> System representation content
name = "upTime"
type = "Long"
:QueryService value = "24865727"
poolSize = 5
upTime = 24865727L Classifier definition content System representation content
Figure 1: Classical model driven engineering approach - Figure 2: CompArch approach - Simplified meta-model and
Simple exemplary meta-model and runtime model exemplary runtime model
MRT 2018, October 2018, Copenhagen, Denmark T. Brand et al.
classifier definition content. This reference needs to be created which can occur with systems employing runtime models. With the
together with the new model element by a factory, which also needs scenarios we consider, for example, experimentation in software
to create the related parameter and monitored property elements if product development and realizing self-adaptive systems utilizing
applicable. machine learning. To better understand the resulting requirements
Despite it is not explicitly stated in [16] this allows introduc- and also the implications of not fulfilling them, we investigated
ing new classifiers without re-generating source code from the to what extent the requirements and the scenarios are already
CompArch meta-model and re-instantiating the runtime model. supported by two state-of-the-art modeling language approaches,
As Table 2 shows, the requirement R1 is supported. To fully namely the classical model-driven engineering approach and an ex-
support requirement R2 a minor change to the CompArch imple- isting, reusable, and rather generic modeling language for runtime
mentation is necessary as described in [4] so that the required models. We found that the flexibility which the CompArch model-
access notification get sent. Requirement R3 is marked as partially ing language provides by allowing the definition of classifiers in the
because both, parameters and monitored properties of a compo- runtime model is actually particularly helpful to support the stated
nent type, should be classifiable by a classifier. Such a parameter or scenarios. We will continue working towards the prospective run-
monitored property classifier should also be usable with multiple time model modeling language, for example, by evaluating different
component types. Also versioning of classifiers is not yet explicitly implementation options including the use of the dynamic object
supported and the approach is specific to components with connec- model pattern. Also we plan to investigate which generic language
tors linking only modeled interfaces. Requirement R4 is supported extensions are beneficial especially regarding the self-adaptation
by deleting the obsolete classifiers form the classifier definition related functions analyze, plan and execute.
content. The requirements R5 to R7 are not supported due to con-
straints defined in the CompArch meta-model. Requirement R8 is REFERENCES
only partially supported as defining domain-specific classifiers for [1] Ian F. Alexander and Ljerka Beus-Dukic. 2009. Discovering Requirements: How to
Specify Products and Services. Wiley.
logical model elements is essentially limited to logical component [2] Nelly Bencomo, Gordon Blair, Sebastian Götz, Brice Morin, and Bernhard Rumpe.
types. In order to distinguish logical from other elements one needs 2013. Report on the 7th International Workshop on Models@Run.Time. SIGSOFT
to apply an according naming scheme. The requirements supported Software Engineering Notes (2013).
[3] Amel Bennaceur, Robert France, Giordano Tamburrelli, Thomas Vogel, Pieter J.
by the CompArch approach as indicated in Table 2 and the resulting Mosterman, Walter Cazzola, Fabio M. Costa, Alfonso Pierantonio, Matthias Tichy,
requirements listed per scenario in Section 3 lead to the support of Mehmet Akşit, Pär Emmanuelson, Huang Gang, Nikolaos Georgantas, and David
the illustrative scenarios as indicated in Table 1. Redlich. 2014. Mechanisms for Leveraging Models at Runtime in Self-adaptive
Software. In Models@run.time: Foundations, Applications, and Roadmaps, Nelly
Bencomo, Robert France, Betty H. C. Cheng, and Uwe Aßmann (Eds.).
5.3 Prospective approach [4] Thomas Brand and Holger Giese. 2018. Towards Generic Adaptive Monitoring.
In 2018 IEEE 12th International Conference on Self-Adaptive and Self-Organizing
As shown in Table 1 and Table 2 the two investigated state-of-the- Systems (SASO). to appear.
[5] Yuriy Brun, Ron Desmarais, Kurt Geihs, Marin Litoiu, Antonia Lopes, Mary
art approaches do not cover all the scenarios and requirements Shaw, and Michael Smit. 2013. A Design Space for Self-Adaptive Systems. In
which the prospective approach is supposed to support. Like the Software Engineering for Self-Adaptive Systems II: International Seminar, Dagstuhl
other two, the prospective approach shall be based on a modeling Castle, Germany, October 24-29, 2010 Revised Selected and Invited Papers, Rogério
de Lemos, Holger Giese, Hausi A. Müller, and Mary Shaw (Eds.).
language. The implementation of this reusable, future language [6] Frederica Darema. 2004. Dynamic Data Driven Applications Systems: A New
shall allow to programmatically create and maintain software archi- Paradigm for Application Simulations and Measurements. In Computational
tecture runtime models. Also it shall be flexible enough to enable Science - ICCS 2004.
[7] Aleksander Fabijan, Pavel Dmitriev, Helena Holmström Olsson, and Jan Bosch.
continuous adaptive monitoring. This means that without the need 2017. The Evolution of Continuous Experimentation in Software Product Devel-
for new language implementation releases it shall support (1) over opment: From Data to a Data-Driven Organization at Scale. In 2017 IEEE/ACM
39th International Conference on Software Engineering (ICSE).
time changing information demands regarding the level of abstrac- [8] Frederick K. Frantz. 1995. A Taxonomy of Model Abstraction Techniques. In
tion and the monitoring results which are beneficial to produce as Proceedings of the 27th Conference on Winter Simulation.
well as (2) changes to the modeled running system. This helps to [9] Sona Ghahremani, Christian M. Adriano, and Holger Giese. 2018. Training
Prediction Models for Rule-based Self-adaptive Systems. In 2018 IEEE International
avoid disturbing re-instantiations of the runtime model and thus Conference on Autonomic Computing (ICAC). To Appear.
is a way to enable continuous adaptive monitoring. In order to [10] OMG. 2014. Object Management Group Model Driven Architecture (MDA) -
support the necessary runtime model evolution, the prospective MDA Guide rev. 2.0.
[11] Dirk Riehle, Michel Tilman, and Ralph Johnson. 2005. Dynamic Object Model.
modeling language needs to be generic to a certain degree. However, In Pattern Languages of Program Design 5, Dragos Manolescu, Markus Voelter,
despite the need for genericness, the language shall still provide and James Noble (Eds.).
[12] J. Rothenberg. 1989. The Nature of Modeling. In Artificial Intelligence, Simulation
enough guidance for creating compatible, in the sense of integrable, & Modeling, Lawrence E. Widman, Kenneth A. Loparo, and Norman R. Nielsen
runtime models on a consistent and stable conceptual basis. This (Eds.).
comprises especially the support for runtime aspects with a likely [13] Dave Steinberg, Frank Budinsky, Marcelo Paternostro, and Ed Merks. 2009. EMF:
Eclipse Modeling Framework. Addison-Wesley.
small set of predefined classifiers in the language meta-model. [14] Michael Szvetits and Uwe Zdun. 2016. Systematic literature review of the ob-
jectives, techniques, kinds, and architectures of models at runtime. Software &
Systems Modeling (2016).
6 CONCLUSION AND FUTURE WORK [15] Thomas Vogel. 2018. Model-Driven Engineering of Self-Adaptive Software. Ph.D.
In this paper we elaborated and described requirements for a prospec- Dissertation. University of Potsdam, Germany.
[16] Thomas Vogel. 2018. mRUBiS: An Exemplar for Model-Based Architectural
tive modeling language which shall allow creating and maintaining Self-Healing and Self-Optimization. In International Symposium on Software
software architecture runtime models for continuous adaptive mon- Engineering for Adaptive and Self-Managing Systems.
itoring. For this purpose we first described illustrative scenarios