Runtime models facilitate the management of running systems in many di erent ways. One of the advantages of runtime models is that they enable the use of existing MDE tools at runtime to implement common auxiliary activities in runtime management, such as querying, visualization, and transformation. In this tool demonstration paper, we focus on this speci c aspect of runtime models. We discuss the requirements of runtime models to enable the use of model-driven tools, and present our tool to help provide such runtime models on the target systems. We apply this tool on a wide range of target systems, modeling the Android mobile system, the Eclipse GUI, the Java class structure, and the JOnAS inner structure. With the help of these runtime models, we perform the runtime management on these systems using classical MDE tools including OCL, QVT, and GMF.
For a running system, developers often need to retrieve and update its data at runtime. The runtime data depict the system's con guration, structure, state, or environment. By analyzing and changing these runtime data, developers monitor and control the system at runtime to x system defects, adapt to the changed environment, or meet newly emerged requirements. Take a mobile phone as a sample system, we may care about what wireless network (Wi-Fi) channels are currently available, as well as their signal intensity. We may also need to switch channels when necessary and possible.
However, manipulating the runtime data is not an easy task. Currently, most
systems only provide low-level APIs for manipulating the runtime data [
context : Context wifiManager : WifiManager wirelessPKU : ScanResult CCMC : ScanResult lsesvidel==w-7ir9elessPKU lsesvidel==C-6C4MC
Runtime Model conforms to
Context activityManager wifiManager WifiManager ActivityManager
scanResult ScanResult ssid : String level : Integer Mata-Model It is tedious and error-prone to manage the system by directly using the management APIs. First, there lacks explicit de nition about the data types. Second, there are di erent invocation manners for di erent systems or even di erent types of data inside the same system. Third, people have to re-implement many common auxiliary management activities on each of the APIs, such as querying, aggregation, visualization, etc.
Runtime model [
self . w i f i M a n a g e r . scanResult - > collect ( e | e . ssid )
To enable the application of existing MDE tools, the runtime model should satisfy the following three requirements. Firstly, the model should be organized in a standardized form. Second, the runtime model must have an explicit metamodel which de nes its semantics. Thirdly and most importantly, the model must have a causal connection with ever-changing system. That means if the system evolves, the model will change immediately, and if the model is modi ed, the system will change correspondingly.
These requirements call for a software agent to represent the runtime data as
a standard model conforming to a speci c meta-model, and to synchronize the
model with the runtime data. We name such agents as \synchronizers". For a
target system, runtime model providers, who are experts of the system and its API,
develop such synchronizers, and runtime model consumers, usually the common
developers, use the runtime model maintained by the synchronizer to
manipulate the runtime data, using the MDE tools. Existing approaches on runtime
model usually require runtime model providers to develop such synchronizers by
hand [
In this paper, we demonstrate a generative tool, SM@RT 1, which generates synchronizers for a wide class of systems. As shown in Figure 2, for a kind of 1 SM@RT: Supporting Models at Run-Time, the tool and the case studies are available on line: http://code.google.com/p/smatrt manipulate runtime data using OCL conforms
to context
Wifi Manager Wireless PKU
Activity Manager CCMC access model
inputs generates
Synchronizer as reference
system meta‐model define
RM provider target systems, like Android, we require the runtime model providers to de ne a system meta-model which speci es the types of the runtime data, and an access model which speci es how to manipulate the data through the API. From these two inputs, SM@RT automatically generates the synchronizer, which maintains a MOF standard runtime model for a running system instance, and ensures the causal connection between this model and the system's runtime data.
Our contributions can be summarized as follows. { We propose that runtime models could facilitate the management of systems by enabling the use of existing model-driven techniques at runtime. We also identify the key requirements for such runtime models. { We provide a generic synchronization solution between runtime models and system data, and based on this solution, we provide a generative tool to construct synchronizers for a wide class of systems. { We successfully apply this tool on several systems, and undertake several experiments to utilize the provided runtime models for managing the systems. These case studies illustrate how the runtime models facilitate the management of systems by using model-driven tools, and how our SM@RT tool implement such runtime models.
The rest of the paper is structured as follows. Section 2 discusses the requirements of runtime models. Section 3 presents our SM@RT tool to implement such runtime models. Section 4 reports our case studies. Section 5 presents some related approaches and Section 6 concludes this paper. 2
In this section, we discuss what the runtime model should be like in order to facilitate the system management with the help of MDE techniques and tools. We summarize the following three requirements, considering the feature of both runtime management and the MDE tools.
Standardized. First, the format of the runtime models should conform to some widely accepted modeling framework (the meta-meta-model and the exchange format), such as MOF, fractal, XML, etc. Standardized models provide the runtime model consumers a consistent basis for understanding and manipulating the data. Moreover, since many MDE techniques and tools are de ned and implemented on speci c modeling standards, they can be directly reused only if the model conforms to the same standard. As the OMG's Meta-Object Facilities (MOF) has became the most accepted standard, with rich tool support, in this paper we only consider the runtime models conforming to the MOF standard.
Explicitly de ned. The types of runtime models should be explicitly dened by meta-models. Such meta-models provide an intuitive guidance and a strict constraint for runtime model consumers to understand and recon gure the runtime models, and are also necessary reference for MDE tools to process the models. According to the MOF standard, a meta-model de nes the types of model elements by the classes. For each class, the meta-model de nes the data type of attributes that can be contained by the elements, and the potential relation between them and the elements of other classes.
Causally connected. Finally, we require the runtime models to have the causal connection with the running systems. The management agents monitor and recon gure the system by reading and writing the model. The causal connection ensures that each time the management agent reads the model, it gets the information representing the current system state, and similarly, each time it writes the model, the information it writes causes the proper system change. Considering the Android example, if the device enters into the scope of a new Wi-Fi service, there will be a new ScanResult element appearing in the model immediately, so that the OCL query in Section 1 returns the ID of the new WiFi service. Causal connection is an important feature of runtime models, which distinguishes them from the models used in design and development phases.
Notice that there are multiple levels for causal connection. The above requirement is just a basic one. Advanced usages of runtime models may require the model changes launched by the management agent would be stable as system evolves, or even require the model to hold some prede ned constraints. But in this paper, we cares about the minimal requirement to enable MDE tools to be used for runtime management, and leave the advanced work as the task for \using the tool in a correct way". 3
We provide a generitive tool, the SM@RT, to help implement runtime models that satisfy the above requirements. Speci cally, for a target system with a management API, the tool accepts a MOF meta-model de ning the system data, and a description about the management API to access such data. Then it automatically generates a synchronizer for the target system, which represents the system data as a MOF standard model conforming the system meta-model, and maintain the causal connection between the model and the system data. 3.1
To provide a runtime model for a speci c system, we need the information about \what kind of data can be manipulated" in this system, and \how to manipulate them through the system's API". The former is de ned by the MOF meta-model as discussed in Section 2. For the latter, we de ned an API description language to specify how to access (invoke) the API to manipulate each type of the data.
The API access is described as code snippets annotated with their e ects on the data. Look over the sample code in Section 1 for invoking the Android API. The rst line tells us that from the root system element this, whose type is Context, how we can get its child named wifiManager. The above statement comprises three kinds of information for manipulating the system data, i.e., the manipulation target (an aggregation named Context.wifiManager), the manipulation type (get), and the action (Lines 1-2 in this code snippet). From this point of view, we de ne the access model for an API as follows.
! Code
Here M etaElement is the set of all the elements in the system meta-model
(classes, attributes, etc.), M anipulation is the set of 9 types of manipulations,
including getting and setting attribute values, creating and deleting model
elements, etc., and Code is a piece of Java code [
The output of SM@RT is a \synchronizer" that maintains the causal connection between the runtime model and the running system.
The mechanism inside such synchronizers can be brie y described as \lazy
and local refreshment". Speci cally, the synchronizer maintains an in-memory
MOF standard model, in the form of a set of Java objects implementing the
EObject interface de ned in Eclipse EMF. During runtime, the synchronizer
keeps on listening to the external reading and writing operations on this
runtime model. For reading operation, the synchronizer calculates what system data
are required, collects the data via the management API, and refreshes or
complements the model according to the collected data. Similarly, for a writing
operation, the synchronizer identi es the modi cations on the model, calculates
the corresponding changes on the system, and invokes the API to implement the
changes. For di erent kinds of operations (getting, setting, adding etc.) and their
target meta-elements (classes, attributes, single or multiple valued associations),
the calculation methods are di erent. We name these methods as the
synchronization strategies. We summarized and designed a set of synchronization
strategies covering all the potential combinations of operations and meta-elements, as
presented in our previous work [
SM@RT automatically generates the synchronizers from the API description. The tool has two parts, a common library and a code generation engine. The common library implements the generic solutions inside the synchronizers, such as maintaining the mapping between model elements and system parts, and the hard-coded synchronization strategies for di erent kinds of elements and di erent operations. The code generation engine generates the parts of the synchronizers which are speci c to the target system, such as all the standard model operations (depending on the system meta-model) and the e ective API invocations to manipulate each kind of system data (depending on the access model). We generate the model operations by directly reusing Eclipse EMF generator, and generate system operations according to the items de ned in the access model, using the de ned API-invoking code snippets as the body of the system operation. The generated operations follows a strict naming convention, so that the synchronization strategy know the semantical relation between model and system operations, automatically. 4
We demonstrate four case studies for SM@RT, using it to provide runtime models for four di erent target systems, including Android mobile systems, Eclipse SWT windows, Java classes and JOnAS JEE enterprise systems. We describe the Android case in detail, showing how to construct the system-model synchronizer, how to use the MDE tool (the OCL query engine in this case) upon the runtime model, and how the synchronizer works to maintain the runtime model. 4.1
Android is a mobile operating system developed by Open Handset Alliance2. It allows developers to write managed code in Java to manipulate (read or write) a device, by invoking the API of a set of Google-developed Java libraries.
Figure 3 shows the system meta-model we de ne for Android runtime data. In this demonstration, we care about the memory, connections, running tasks and Wi-Fi. We de ne each type of system data as a class, and de ne the relations between them as properties. For example, this meta-model tells us that from a root element in type of Context, we can rst get its wifiManager, and then get the manager's scanResult to enumerate all the Wi-Fi signals. For each scanned signal, we can get its attributes like ssid, frequency, etc. This meta-model is not only an input to our synchronizer, but also a guidance for using the runtime model (like writing the OCL query) and a reference of the MDE tool (like the OCL engine).
Figure 4 shows an excerpt of the access model, which de nes how to get a Context's wifiManager. The annotations (keywords starting with \@") indicates the constitution of the item, i.e. a AccItem containing a MetaElement, 2 http://www.android.com Manipulation and a Code fragment, and whose values are de ned on the right hand side of the equal signs. Inside the code fragment, we de ne a piece of Java code to say that to get a wifiManager ($sys::result) from a Context instance ($sys::this), we should invoke a method named getSystemService with a parameter Context.WIFI SERVICE. The entire access model contains 95 items like this, with 431 lines of code (including the structural lines like "@AccItem").
We use these two inputs to generate the synchronizer. The generation result is in the form of Java source code. We compile it as an Android package, and deploy it onto an Android supported mobile phone, the \HTC Magic (G2)".
The generated synchronizer allow the device users to use OCL for querying the device data. Figure 5 shows the snapshots of four scenarios for executing OCL rules on Android. For the rst scenario, we want to list the IDs of all the Wi-Fi signals available for the device. Initially, we know that the root element (we refer to it as self in the OCL rules) is in type of Context. Then we check the system meta-model and nd that Context has an association named wifiManager. The target class WifiManager has an multiple-valued association named scanResult. And nally, the target class ScanResult has an attribute named ssid. According to terminology of Wi-Fi technique, we know that we can list the signal IDs by querying out the values of these ssids. We input the OCL rule as shown in Figure 5(a), click the button, and the result is printed under the button. Similarly, Figure 5(b) shows how we print the detailed information of the rst Wi-Fi channel. Figure 5(c) shows how we calculate the total number of clients registered on all the running services. Figure 5(d) shows a relatively complex query: We want to see what services have more than one clients listening to them. The OCL rule means \getting the running services, selecting the ones from them (a) (b) (c)
(d) whose client count is greater than 1, and nally retrieving the process name of the selected running services".
The above scenarios are implemented by directly using the Eclipse OCL engine. We compile the OCL engine on Android platform, and deploy it on the same device. After the user clicking the Apply button, the GUI retrieves the inputted OCL rule, instantiates a root element in type of Context from the synchronizer, and invoke the evaluate method of the OCL engine using this root element and the OCL rule. During the execution of the OCL engine, it will manipulate the model from this root element, by means of standard model invocation de ned by EMF. And in the same time, the synchronizer breaks the invocation, and synchronizes the model with system on-demand.
Figure 6 illustrates how the synchronizer works, when we evaluate the OCL
query in Section 1 on the runtime model as shown in Figure 1. Each life-line
in this sequence diagram represents a component that constituting the
synchronizer. At rst, the initial model only contains one root model element, in
type of Context. Following the query, the interpreter rst retrieves the root's
child named wifiManager, by invoking get on the model. The model listener
interrupts this invocation, and asks the planner to perform synchronization.
According to the synchronization strategy for \getting single-valued aggregation"
[
In this case, our target systems are SWT-based Eclipse UI parts, which could be \views", \editors" or \dialogs" running on an Eclipse platform. Such UI parts, also known as Shells according to the SWT terminology, are constituted of a set of Controls, like the Labels for presenting information, the Text elds for inputting texts, the Buttons for triggering commands, etc. Each Control has its own con gurations which can be retrieved and updated at runtime, such as the presented text, the background color, etc. The Controls and their con gurations form the runtime data of such Shells. The main idea of this case study is to provide runtime models for Eclipse windows, so that developers could recon gure the windows intuitively at runtime. That means developers do not need to completely decide the appearance of the windows, and recon gure the window at runtime. Moreover, this con guration is simply editing models, through visualized model editors. This is a prototype for \design at runtime", and may be useful in customizable GUIs or WYSIWYG GUI development.
The foreground image of Figure 7 presents a simpli ed version of the system meta-model. We de ned three common types of controls, and de ned some typical attributes for them. The background snapshot illustrates how to use the runtime model. The snapshot is an Eclipse platform, with the target system (the bottom part, an Eclipse \view") and the runtime model (the top part, a model opened in a tree-based visual model editor), together. The model elements re ect the controls in the window, and their attributes re ect the controls' congurations. We change the system by typing \Hi" on the text eld, the model element's text attribute changes instantly. We can edit the model to manipulate the system: We change the background of the rst Label into \red", and then the color of the system label changes automatically. Finally, we add a new model element in the type of Button, and a new button appears in the window . 4.3
This case is a reproduction of the Jar2UML tool3, which re ects the class structure in a Jar le as a UML model. We utilized the UML meta-model (de ned 3 http://ssel.vub.ac.be/ssel/research/mdd/jar2uml, a use case of MoDisco by Eclipse UML24) as our system meta-model, and de ne the API provided by the BCEL library5 for analyzing Java binary code. We used Eclipse UML2 tools to visualize the re ected UML model as a class diagram. 4.4
Our last case study is to equip a JOnAS JEE application server6 with runtime model. This model re ects the inner structure (e.g. what applications and EJBs are deployed), the con guration (e.g. the size of data source's connection pool), and the state (e.g. the number of EJB instances) of a running JOnAS server.
The system meta-model de nes all the 21 types of MBeans supported by
JOnAS, including EJBs, applications, middleware services, etc. The API
description speci es how to manipulate these elements and their properties through
the JMX API provided by JOnAS. We deploy the generated synchronizer on
a JOnAS server with a Java Pet Store application deployed on it, and utilize
Eclipse GMF7 to visualize the runtime model maintained by the synchronizer.
The graphical model editor based on GMF can be used as a graphical JOnAS
management tool: We can see the inner structure of the current JOnAS server,
deploy new applications or EJBs by adding model elements, and check the
system elements' current states and modify their con gurations. We also use the
QVT transformation to synchronize this runtime model with a software
architecture model in C2 style, reproducing the architecture-based runtime evolution
4 http://www.eclipse.org/uml2
5 Byte Code Engineering Library, http://jakarta.apache.org/bcel/
6 http://jonas.ow2.org
7 http://www.eclipse.org/modeling/gmf
proposed by Oreizy et al. [
In this paper, we focus on a speci c usage of runtime models, i.e., facilitating the runtime management by enabling the use of existing MDE techniques and tools at runtime. We discuss the requirements of such runtime models, and present our SM@RT tool to help on providing them. We evaluate our idea and the tool through a set of case studies on a wide range of target systems.
ACKNOWLEDGEMENT This work is supported by the National Basic Research Program of China under Grant No. 2011CB302604, the National Natural Science Foundation of China under Grant No. 60933003, 60873060; the HighTech Research & Development Program of China under Grant No. 2009AA01Z116, and the National S&T Major Project under Grant No. 2009ZX01043-002-002, the EU Seventh Framework Programme under Grant No. 231167.