Non-functional properties (NFPs) concern various characteristics of a system (cost, power, QoS). These characteristics belong to different models of the system, built by different design teams, using different formalisms. Therefore, the design of a system includes a number of domain-specific modeling languages, used to express various NFPs. This paper focuses on the heterogeneity of the points of view on the system. We show that “multi-view” approaches which do not rely on a unique underlying model appear better-suited to express NFPs than model weaving or annotations. However, existing approaches in this category do not yet support model execution. We introduce a multi-view extension to ModHel'X, a framework for executing heterogeneous models, and we show how it can be used for modeling non-functional characteristics of a system and expressing NFPs. A key point of this approach is that it relies only on the core concepts of ModHel'X, but uses them in new ways.
The design of a system requires to take into account different concerns besides the core function of the system. Such concerns comprise cost, reliability, performance, or power consumption. Concerns are generally classified as functional or non-functional. While functional concerns used to be the main matter in the development process, non-functional concerns are now taken into consideration earlier because they constrain the design of the functional part of the system. This is why, in the context of Model Driven Engineering, different techniques have been developed to model non-functional characteristics of systems. One of the goals of these techniques is to allow the analysis of non-functional properties of a system together with its functional behavior during design.
Obviously, different concerns require different types of models since they rely on different domains (power, security, etc.), which therefore implies the use of suitable modeling languages or paradigms (differential equations, state machines, statistics). In consequence, several domain-specific modeling languages (DSMLs) are used when modeling a system with respect to different concerns. We focus here on the problems caused by the heterogeneity of the modeling languages which are used to model functional and non-functional features.
In this paper, we present an approach in which the system is modeled from
different points of view which correspond to different concerns. A view of the
system may regard either its functional or its non-functional characteristics. Each
view is modeled using a modeling language which is suitable for the considered
concern. Since different views of the system may be interdependent (for instance,
the power consumption of a system, which is studied in one view, may depend
on the state of the system, which is studied in another view), we provide means
to express dependencies among views in order to ensure the coherence of the
different models of the system. Our goal is to enable the simultaneous execution
of different models which represent the system under different points of view.
Our approach relies on an existing framework, called ModHel’X [
First, we present related work and motivate our approach in section 2. Then, in section 3, we introduce the approach we propose. We briefly present ModHel’X, a framework built for assembling heterogenous models through hierarchical composition in 3.1. Then, starting from the basic concepts of ModHel’X, we propose an architecture for defining the coherence of several views of a system in 3.2. This architecture introduces no new concepts in ModHel’X, but uses the composition mechanisms of ModHel’X in two ways: for aggregation (building more complex systems by assembling simple systems), and for superposition (adding layers for defining different aspects of a system). We detail the mechanisms that we propose to model interdependencies among views. In section 4, we illustrate the principles of our approach on an example. Finally, we discuss open issues in section 5, before concluding. 2
Non-functional characteristics of a system may be expressed in a number of ways. First, crosscutting concerns (including non-functional features) may be modeled separately from the functional core of the system, and later be “woven” into it. This constitutes the aspect-oriented approach. Second, non-functional features may be expressed as annotations to the core model, as done in UML with the MARTE profile. Third, the features of the system, both functional and nonfunctional, may be constructed in parallel, in relation to one another, through various “views” on the system, corresponding to various fields of concerns. 2.1
In the field of programming, object-oriented programming allows the
structuration of an application in a hierarchical fashion. However, non-functional,
crosscutting concerns are interwoven in the object-oriented code. For instance, in
an application that performs logging, virtually every class is “polluted” with
logging-related code, which increases complexity. To allow for more modularity,
aspect-oriented programming (AOP) was introduced [
AOP enables one to weave non-functional behaviors into a core program.
Likewise, one may wish to be able to weave non-functional aspects into a
functional model. To this end aspect-oriented modeling (AOM) was introduced [
Theme/UML [
RAM (Reusable Aspect Models) [
Non-functional features are not necessarily intended to be woven into the system.
Instead, one may wish to express properties to be verified on the system. Starting
from a functional model of the system, which states what the system shall do,
one can add annotations to state how the system shall do it – non-functional
properties. For instance, when using UML to model a system, one can use various
profiles that allow the addition of domain-specific annotations [
In this context, annotating a UML model amounts to attaching information
to model elements, which can be done in two ways [
The annotations may be used for two purposes: analyzing a model, and constraining the synthesis of the actual system from the model. For instance, MARTE annotations to a UML model may be used to check the model for schedulability (analysis), but also to choose a scheduler or allocate resources when generating an implementation (synthesis).
Adding annotations to a core model does not allow one to create complex
descriptions of the system from the non-functional points of view. Instead, a designer
or a team of designers may wish to be able to build full-fledged models of a
system from several points of view in parallel, while ensuring consistency among
the points of view. This is called multi-view modeling, and it can be approached
in two ways [
The work of Attiogbé et al. [
In the framework of Attiogbé et al., there is a clear distinction between an abstract reference model, which concentrates all information available about the system, and specific models, which are built from the reference model. The specific models constitute various points of view on the system. Analysis (verification of properties) can be performed on specific models. Modifications on one specific model are fed back into the reference model and then to the other specific models.
VUML is a UML profile for multi-view modeling. It is based on the concept of multi-view class. A multi-view class consists of a default (common) view and a set of specific views related to the common view through extension relations. OCL constraints enforce consistency among views. As UML is the underlying framework, there is indeed a reference model, the UML model itself.
Maintaining a reference model requires to update this model each time a view
is changed, as well as to propagate the change to the other views. Moreover,
the reference model must be an instance of a meta-model which encompasses
the semantics of every possible view of the system. Defining the semantics of
such a union language is very difficult, and reference models are therefore purely
syntactic. This makes the verification of the global coherence of a model a difficult
problem. That is why the second approach, in which there is no explicit reference
model, seems promising. Let us now see two examples of this approach: the work
of Benveniste et al. [
Benveniste et al. introduce a framework for system design, inspired by the
Tagged Signal Model [
Rosetta is a system specification language based on formal (coalgebra-based) semantics. Central in Rosetta is the notion of facet. A facet corresponds to an observable aspect of a component, either functional or non-functional. Facets which model different components can interact with each other. Also, several facets of the same component may be combined with a product operator, meaning that all of them must be satisfied simultaneously, which ensures consistency among views. Rosetta can therefore be used to model the structure of systems, as well as different points of view on system components.
However, the framework of Benveniste et al. and Rosetta remain at the level of specifications, which means that models cannot be executed directly. Therefore a designer who uses one of these tools to specify a system will have to use another tool in order to get an executable implementation.
In the remainder of this paper, we introduce a proposal which adds multi-view modeling capabilities to ModHel’X, an existing framework for heterogeneous modeling. Contrary to the aforementioned frameworks, ModHel’X is capable of executing a model: it can calculate its behavior. ModHel’X belongs to the second approach, since it considers views as layers that add information to each other in order to build an implicit model of a system. The originality of the approach presented here is to specify the links between views using the same mechanisms that were designed for the hierarchical composition of heterogeneous models. It therefore provides a uniform framework for combining heterogeneous models both for hierarchical composition and for the superposition of views. 3 3.1
We start here with a very short introduction to the basic concepts of ModHel’X,
so that we can show later how these concepts can be used for multi-view
modeling. ModHel’X [
In ModHel’X, the interpretation of a model by the generic execution
engine is directed by a model of computation. A model of computation is a set of
rules for combining the behaviors of a set of components into the behavior of a
model. Well-known examples of models of computation include discrete events,
synchronous data-flows, finite state machines and continuous time [
Pin Pin
Block
Pin
A relation
B
The elementary unit of behavior in ModHel’X is the block, as shown on figure 1. A block is defined (a) by its interface which is composed of pins, and (b) by an update operation which allows the observation of the behavior of the block through its interface. Pins are used to send and receive information and they define what is observable from a block. The behavior of a block is observed by requiring an update of its interface. The update operation requires that the block take its inputs into consideration and update its outputs according to the inputs and its current state.
Blocks can be assembled by setting relations between their pins. A composite block, as shown on figure 2, is composed of a set of blocks with relations between their pins. Its interface is a subset of the union of the interfaces of its blocks (it can hide their pins or make them visible from the outside). On the figure, the pins exposed at the interface of the composite block are shown as dashed circles in order to emphasize that they are just pins of the internal blocks which are made visible through the interface of the composite block. A model of computation is used to define the semantics of the interconnected blocks. A composite associated to a model of computation forms a model, as shown on figure 3.
A
B
MoC
A
B
MoC adaptin adaptOut
ModHel’X has support for hierarchical composition and heterogeneity thanks to interface blocks. An interface block is a kind of block whose behavior is defined by a model (which is therefore “inside” the block). An example is shown on figure 4. The model which defines the behavior of an interface block may use a different (internal) model of computation than the (external) one used for the model in which the interface block is used. Hierarchy through interface blocks is the mechanism used to combine heterogeneous models in ModHel’X. The semantic adaptation between the two models of computation is specified by defining the adaptIn and adaptOut operations of the interface block. These operations are in charge of adapting the control (scheduling, synchronization) and the data between the internal model of computation and the external one. An interface block has its own pins, and the data available on those pins is processed by its adaptIn and adaptOut operations. Typically, adaptIn uses the valuation of the pins of the interface block to compute scheduling and status information as well as a valuation of the pins of the composite block. adaptOut uses status information and the valuation of the pins of the composite block to give a valuation of the pins of the interface block. 3.2
A block in ModHel’X represents an observable behavior. When we consider a component that we want to model from different points of view, each view can be considered as an observable behavior and represented as a block in ModHel’X. With this approach, a “real world” component may be modeled by a block C' for its functional behavior, by a block CP for its power consumption, and by a block CT for its thermal behavior.
By considering that a view of a component is a ModHel’X block, we can build composite views by assembling components and interpreting this composition according to a model of computation. This is composition by aggregation, the usual way of building models with block diagram tools, for which the metamodel of ModHel’X was built.
Actually, there can be several of these views for a given system: in the same way we build a functional view of a system by assembling blocks which represent the functional behavior of the components of the system, we can also build a power consumption view of the system by assembling the blocks which represent the power consumption behavior of these components. Each of these two models computes one aspect of the behavior of the system, and they are interdependent. 3.3
Indeed, the power consumption of a system may depend on its functional behavior, and this dependency should be stated in the model of the system. This leads us to consider that blocks may be combined in two ways: by aggregation, in order to build larger models (as seen in the previous section); and by superposition, in order to build multi-view models. Composition by superposition amounts to maintaining coherence between models which represent different views of a system so that the behaviors observed in the different views are coherent.
The abstract syntax (block, pin, relation, MoC) of ModHel’X has been designed for composition by aggregation, but we will now show that it can also be used for composition by superposition. In a multi-view model, coherence between views can be denoted by relations between the ports of the views, just as the composition of the behaviors of several blocks is denoted by relations between their ports. Figure 5 shows two views of a component C, which are superposed so that observations on view CP are coherent with observations on view C'. The relations between the pins of the two views represent the coherence relation between their behaviors, and the semantics of the interconnection of these views is defined by a model of computation, as for any model in ModHel’X.
M o C 1 s C o M
A' AP
MoC' MoCP
B' BP
M o C s 2 In order to illustrate our approach of multi-view modeling, we present on figure 7 a simple example in which a thermostat regulates the temperature in a room by switching a heater on or off. For the sake of simplicity, the border and pins of the composite blocks are omitted on the figure, and the internal model of interface blocks is represented in a form (state machine, pseudo code) which is easier to understand than a strict ModHel’X model. In the functional view, a thermometer (denoted by T ) provides the thermostat with the ambient temperature. The
Superposition model Off SDF
T < 20 C T > 20 C
On
And if (state == On) {
out = 10 W } else {
out = 2 W } if (in > 0) {
out = 2000 W } else {
out = 0 W } thermostat is modeled as a state machine which switches between the On and Off states when the temperature goes below or above 20 C. When the main switch is on, the output of the thermostat is used to drive a heater. A synchronous data flow (SDF) model of computation is used for the model of the thermostat, and the continuous time (CT) model of computation is used to combine the behaviors of the thermometer, the thermostat and the heater.
In the power consumption view, the left block models the power consumption of the thermostat: 10 W when in the On state and 2 W when in the Off state. The power consumption of the heater is modeled by the next block (2000 W when powered). The last block in the power consumption view is an adder which computes the power consumption of the system by adding the power consumption of the thermostat and of the heater. The continuous time (CT) model of computation is used for this view.
Let us examine now the coherence of the views. The power consumption of the thermostat depends on its internal state, so this information must be provided by the functional view to the power consumption view. However, for the sake of modularity, the internal state of the thermostat is an implementation detail that should not be revealed to other blocks in an aggregation model. We can consider it as protected information that should be available only for blocks whose behavior is tightly coupled to the functional behavior of the thermostat. The model of the thermostat has therefore two interfaces, one for composition by aggregation, and one for composition by superposition. ModHel’X has support for this since a given model may be wrapped into several interface blocks. On figure 7, aggregation interfaces are shown using solid black rectangles and pins, and superposition interfaces are shown using thick gray rectangles and gray pins.
In a similar way, the power consumption view of the heater needs to know if the heater is powered. This is determined by the output of the And block in the functional view, which is therefore published in the superposition interface of the thermostat. This illustrates that pins that appear in the superposition interface of a model can provide information which comes either from aggregation interfaces (the output of the And block) or from superposition ones (the state output of the thermostat).
In ModHel’X, the role of the interface blocks is not only to define different interfaces for a given model, but also to adapt the behavior of this model to different models of computation. Here, the coherence of the two views of the system is expressed using the discrete event (DE) model of computation. The superposition interfaces therefore perform the semantic adaptation of the model of computation used for these models with DE. The aggregation interfaces of the same models also perform a semantic adaptation, but with CT. Let us examine the semantic adaptation of the model of the thermostat, which uses SDF. Its aggregation interface adapts between SDF and CT by making the internal model react only to significant changes in the continuous input signal, and by holding a constant continuous output when no data sample is produced by the model. Its superposition interface adapts between SDF and DE by producing output events only when the automaton changes its state or when the output of the And block changes. 5
We have shown that the basic meta-model designed to represent the structure of hierarchical heterogeneous models in ModHel’X can also be used to represent the coherence relations between several views of a system. However, we did not give the precise semantics of this representation. The generic execution algorithm of ModHel’X was designed with the hypothesis that a given block belongs to only one model because only composition by aggregation was possible. Adding composition by superposition allows a block to belong to several models, behind different interfaces. Since the observations that are made of this block through different interfaces are interdependent, the result of the execution of a multi-view model may depend on the order in which the different views are observed. In the simple example of the thermostat, the power consumption view depends on the functional view, and there is no other dependency, so we can merely compute the behavior of the functional model, then the behavior of the superposition model, and last, the behavior of the power consumption model. However, if there were cyclic dependencies between these different views, defining the semantics of the multi-view model would be more difficult. Actually, the current version of the execution engine of ModHel’X does not support it. In the following, we illustrate the problem and present some possibilities to address it.
MoC1
view 1 a p r e p u s a C o M
A A’
B B’
M o C b s u p e r p b MoC2
view 2
First, to show what a multi-view model with cyclic dependencies looks like, let us consider the example of figure 8. view 1 and view 2 model the behavior of the system according to different points of view. superp a and superp b are used to maintain the coherence between the views. One may consider that A and B are views of some components of the system according to the point of view of view 1, and that A’ and B’ are views of the same components according to the point of view of view 2. Arrows are used to show that the behavior of B depends on data produced by A, the behavior of B’ on data produced by B, the behavior of A’ on data produced by B’, and finally, the behavior of A depends on data produced by A’.
Such cyclic dependencies are common and appear naturally in models of systems. In the example of the thermostat and the heater, we could have modeled the fact that the heater makes the temperature increase when it is on. Such a model is shown on figure 9. It uses three views to model the functional behavior of the system, its power consumption behavior, and its thermic behavior. The functional and power consumption views are similar to the ones shown on figure 7, with simplified schematics for complex blocks. The thermic view models the production of heat by the heater, as well as the thermic behavior of the room. A second superposition model is used to maintain the coherence between the power consumption view and the thermic view. A third one is added to maintain the coherence between the thermic view and the functional view, because the temperature measured by the thermometer depends on the thermic behavior of the room. The relation between the output of the room thermic model and the input of the thermometer in the functional view closes a dependency loop: the temperature in the room depends on the output of the thermostat (because it drives the heater), which depends itself on the temperature. However, when T
Thermostat the heater is switched on, the temperature does not rise instantaneously, so the dependency cycle is broken by a delay: the output of the thermometer depends on the current room temperature, but the heater acts on the future temperature.
Introducing delays in communications between ports is a way of solving the issue of cyclic dependencies. However, we have seen that the semantics of the relations between blocks is determined by a model of computation. Therefore, in general, and for instance on figure 8, we cannot assume that the models of computation used in view 1, view 2, superp a and superp b all have “propagate with delay” semantics for relations.
Another way of considering cyclic dependencies is to regard the cycle as an equation of the form ~x = f (~x), with ~x the vector of values given to their pins, and to choose the value of the pins in order to solve this equation. The f function represents the behaviors of the blocks and the rules used by the model of computation to combine these behaviors. If the equation has no solution, the model has no behavior and is ill-formed. If there are several solutions to the equation, we can either consider the model as ill-formed, or pick a random solution (this allows non-deterministic behaviors), or choose a solution according to some criterion (for instance, the smallest or the largest solution according to some order). Indeed, ModHel’X allows cyclic dependencies in models, provided that a solution can be computed by repeated observations of the blocks. With the equation above, this means that ModHel’X allows cyclic dependencies when 9k0 2 N; 8k k0; f k(x~0) = f k0 (x~0). Starting from an initial guess x~0 for the values of the pins, we repeatedly apply f , which represents the observation of the blocks and the propagation of the observed values according to the relations between pins. When two successive series of observations yield the same values for the pins, a fixed point x~f has been reached and gives the behavior of the model for this observation.
The fixed point which is reached depends on the individual behavior of the blocks, but also on the model of computation, which determines the order in which blocks are observed, and how the values associated to the pins are propagated according to the relations. When ModHel’X computes the behavior of a model, it relies on the MoC of the model to compute f (~x). In our multi-view example, four models of computation are involved (one for each view, and one for each superposition model), so it is much more difficult to determine f , and therefore to find its fixed-point, if it exists. We are studying a new version of the execution engine of ModHel’X which observes the structure of multi-view models in order to schedule the observations of their views and superposition models in order to compute the behavior of the whole model as a fixed-point. 6
Non-functional aspects of a system can be captured in models which focus on a specific point of view on the system. Such models often require different modeling formalisms or DSMLs because they belong to different domains. In consequence, different models which represent views on different aspects of a system are often heterogeneous. Since non-functional properties may be interdependent (e.g. temperature, dissipated power and clock frequency in a CPU), and may also depend on the functional behavior of the system, it is necessary to model these dependencies so as to ensure the coherence of the different models of the system.
The approach of multi-view modeling presented in this paper relies on ModHel’X, a framework for heterogeneous modeling and design, to model each view of a system. Each view combines the behavior of components according to the rules of a model of computation which is equivalent to the semantics of a DSML. Components are aggregated into models and a model can be wrapped in a component to give a hierarchical structure to a larger model.
In the work presented in this paper, we introduce superposition, a new way of combining components to express the coherence between different views of a system. In this approach, a multi-view model of a system consists of several views (which are models of the system built according to different points of view), and of superposition models which propagate information between the views in order to ensure their coherence.
This approach has the main advantage of reusing the basic mechanisms designed in ModHel’X for hierarchical heterogeneous modeling. It only assumes that a given model can be encapsulated in several interfaces for composition by aggregation and superposition. It therefore provides the base of a unified framework for building heterogeneous multi-view models.