Agility requires expressive freedom for the modeler; however, automated MDE processes such as transformations require models to conform to strict constraints (e.g. well-formed rules). One way out of this apparent con ict is to allow a \relaxed" version of a modeling language to be used by modelers and then use tool support to \tighten" such models so that they are conformant to the original constraints. In this paper, we explore the issues of relaxation and tightening of modeling languages and discuss the possibilities for tool support.
The problem of agility in MDE arises because graphical models have two very di erent kinds of users: humans and programs. Humans use models to express themselves and communicate with each other. Programs manipulate models to do analyses or to transform them into other models. These two types of users give rise to a modeling dilemma: humans want expressive freedom and can cope with relaxed rules while programs need models to conform to precise constraints. How can this agility con ict be reconciled?
In this paper, we propose a transformation-based framework for addressing the agility con ict for a given modeling language by meeting the needs of both kinds of users. Human needs are satis ed by relaxing the language to permit greater expressive freedom. Program needs are satis ed by de ning a tightening transformation that converts the model in the relaxed language back into the original, more strict, language.
We limit our scope by focussing on supporting two kinds of agility: omission
agility { allowing the modeler to omit information in the model in order to
express uncertainty, irrelevance, etc., and clarity agility { allowing the modeler to
express information in the model more concisely or di erently to improve clarity.
Although our scope is limited, the usefulness of these forms of agility is justi ed
by work in the philosophy of language relating to human communication. For
example, Grice de nes a \cooperative principle" that gives four maxims that
hold in e ective human communication [
The paper is structured as follows. In Section 2, we illustrate di erent aspects of the two agility types using ve examples. In Section 3, we give a preliminary framework for language relaxation and tightening and show how it can address our examples. Section 4 explores possible tool support for the framework. We discuss related work in Section 5 and conclude in Section 6. 2
A modeling language can be relaxed in several di erent ways. In this section, we explore some of these possibilities using the examples depicted in Figure 1 (A-E), referring to these as Examples A-E, respectively. All of the examples use the language of UML class diagrams (CD). In the discussion below, assume that the metamodel of CD consists of a vocabulary de ning the element and relation types in the language and a set of constraints de ning well-formedness { i.e., a well-formed model must conform to the constraints. For each example, we rst state what the modeler is attempting to express and the type of agility required, then describe the relaxation aimed to achieve this and nally, introduce the tightening transformation required.
Example A. The modeler wants to express that she doesn't yet know what sits on the other end of the controlledBy association (omission agility). To do this, she weakens the well-formedness constraint that a binary association must have a class on both ends. The tightening transformation assigns a class to the target of the controlledBy association. Since there is choice here (i.e., an existing class or a new class), this choice must be resolved.
Example B. The modeler wants to express that in the parallel inheritance hierarchies, the classes Car/Driver and Plane/Pilot are the intended pairings with the controlledBy association (clarity agility). To do this, she uses the vertical alignment in the layout to indicate the correspondences. Note that neither the vocabulary nor the constraints of the concrete syntax are a ected, but the expressive power of the language is extended by giving the spatial relation of vertical alignment a special meaning. The tightening transformation de nes an OCL constraint for each occurrence of the vertical alignment of a pair of classes that extend Vehicle/Operator to enforce the intended constraint. Example C. The modeler wants to indicate that she isn't sure which class should hold the park() operation (omission agility). To express this, she wants to link park() to both classes but to do that, it would have to be simultaneously contained in two boxes. This \physical" constraint, which enforces the well-formedness constraint that an operation is owned by one class, cannot be weakened unless the boxes are made to overlap. Instead, for clarity, she opts for extending the vocabulary to allow operations to be speci ed externally to a class, using an ellipse and linked to the class with a dashed line (clarity agility). The tightening transformation adds an operation to a class for each ellipse linked to the class. Since in this example, two owners of the operation park() are speci ed and this violates a well-formedness constraint, there is a choice (i.e., which class is the owner?) that needs to be resolved.
Example D. To reduce clutter, the modeler wants to put the name of the class outside, but close to, its box (clarity agility). To do this, she weakens the constraint that the class name is inside the box at the top. The tightening transformation de nes text close to a class box as being the name of the class. To operationalize it, the de nition of \closeness" must be given. Example E. The modeler wants to express the fact that certain classes are \connected" without being speci c about the type of connection { it can be a generalization, an association, etc. (omission agility). To do this, she extends the vocabulary with a special dashed line to indicate this relation. The tightening transformation resolves the dashed line to one of the class diagram relations that can hold between classes. Since there is choice here, someone needs to make it. 3
Our ultimate goal is to develop a framework for the relaxation and tightening of modeling languages to address the agility con ict. In this section, we use the examples of Section 2 to discuss the characterizing features of relaxation and tightening that could be parts of such a framework.
The approach is given schematically in Figure 2. We assume that a modeling language has a transformation c2a that generates the abstract syntax for a model expressed using its concrete syntax. Modeling agility is supported by allowing the modeler to relax the concrete syntax to a new syntax, as needed, to provide the required expressive power. Then, when the model must be used for MDE operations, the tightening transformation T that transforms the model back to the more strict concrete syntax is constructed. The composition c2a T takes the relaxed model to the original abstract syntax, making it amenable to MDE operations such as transformation and analysis.
The approach is motivated by the observation that human and program (MDE) users of models have di erent foci: humans deal with concrete syntax while MDE primarily deals with the abstract syntax of a model1. Thus, all of our examples are in concrete syntax. Correspondingly, our transformation-based approach to relaxation and tightening is centered around concrete syntax rather than abstract syntax. The focus on concrete syntax does not limit the expressive power of the language relaxation; on the contrary, it is greater than if the relaxation were applied to abstract syntax. While all user-relevant information from the abstract syntax is preserved in the concrete syntax, the reverse is not true, e.g., Example D in Figure 1. One of the contributions of the present work is to bring attention to the fact that extending MDE to address human issues such as agility requires transformations on the concrete syntax. 1 Model editors and model layout algorithms are notable exceptions to this. Vehicle
ControlledBy
Car Plane void park(location)
Vehicle Plane
Car
Driver
Vehicle
The motivation in Section 1 for limiting our scope to omission and clarity agility was to ensure that a tightening transformation T always exists (though it might not be necessarily unique). Relaxation to omit information can be tightened by adding back information; while relaxation to express information differently for clarity is tightened by de ning an alternate expression in terms of native constructs in the original language. 3.1
Implementing relaxation and tightening We now consider the ways in which elements of Figure 2 are a ected by the relaxation and tightening process. The concrete syntax can be a ected in two ways: extending the vocabulary (Examples C and E) or weakening the well-formedness constraints (Examples A, C and D). When the vocabulary is extended, the interpretation transformation c2a must be correspondingly broadened; but the abstract syntax 2 2 ∘ relax concrete syntax
tighten relaxed concrete syntax broadening of c2a may still be required even if the concrete syntax is una ected { this is the case with Example B.
The language aspects involved in relaxation have corresponding tightening actions. Relaxing by extending the vocabulary requires tightening by rede ning these extensions in terms of existing constructs. Relaxing by weakening constraints requires tightening by repairing the violations of the constraints that were weakened. In Section 4, we discuss these actions in more detail. Support for agility. The examples in Figure 1 show how our approach applies to both clarity and omission agility. Clarity agility uses vocabulary extension in Example C and constraint weakening in Example D. In addition, Example B illustrates clarity agility when no language changes are made and only c2a is broadened.
Omission agility uses vocabulary extension in Examples C and E and constraint weakening in Example A. Furthermore, three di erent ways of omitting information are illustrated: dropping information (Example A), providing alternatives (Example C) and using abstraction (Example E).
Whenever omission agility is being addressed, choice may occur in the tightening process, and there are di erent ways to address this choice. One alternative is to elicit a decision from the modeler. Another possibility is to make a \systematic" decision (e.g., always create a new class in Example A). Yet another possibility is to defer the decision and keep all choices. We discuss this last possibility in Section 3.2.
Special characteristics of concrete syntax. The physical nature of concrete syntax makes it di erent from abstract syntax and this has two important implications for the framework. First, existing spatial relations that are \unused" can be appropriated for increasing expressiveness without changing the concrete syntax. This is the case with Example B where vertical alignment is given a meaning, and in Example D where closeness is given a meaning. Other relations that can be used are overlap, containment, horizontal alignment, clustering, radial alignment, etc. Second, some well-formedness constraints are enforced by the physical world, and so weakening them requires an alternative representation. This is what motivates the vocabulary extension in Example C.
ControlledBy (V) C
Car Plane (M) (M) When tightening due to information omission yields a choice of alternatives, the modeler may not be comfortable having to choose, either because she doesn't yet know which choice is correct or because she wants to consider all alternatives. In this case, the technique of partial modeling allows the modeler to defer the decision and provides an alternative to tightening.
A partial model can express a set of possible models through the use of model
annotations and is typically used to express model uncertainty. For example,
Figure 3 shows the use of the MAVO partial modeling approach to express the
choices due to the omission of information in Examples A and C of Figure 1,
resulting in A' and C', respectively. The V annotation in Example A' means that
the class C is a \variable" and so this represents a set of di erent models
according to how the variable is instantiated. The M annotations indicate \maybe"
so Example C' represents the set of models in which only one of the operation
ownership relations exists. Due to lack of space, we omit a detailed description
of MAVO partial modeling { interested readers are directed to [
Our strategy relies on tool support. In this section, we discuss some of the possibilities for this in terms of existing technologies.
Relaxation. The relaxation tool may be a general drawing tool (e.g., Visio) with a prede ned template for the concrete syntax to allow models expressed in the original language to be drawn. The relaxation mechanism of vocabulary extension is achieved by allowing other shapes to be drawn as well. The relaxation mechanism of constraint weakening is achieved by supporting an operating mode that does not enforce (selectable) constraints (e.g., see \soft validation" in Section 5). Note that physical constraints imposed by the concrete syntax cannot be weakened, so these are addressed by vocabulary extension as in Example C.
Tightening. Constructing the tightening transformation is the more di cult part of the approach. There are two steps involved in the construction: (1) Identify an occurrence of a language relaxation. Instances of vocabulary extension or constraint weakening (i.e., violation) are easy to detect automatically. Instances of broadening the interpretation may be impossible to detect without the modeler \pointing it out". One clue may be to detect occurrences of spatial relations (e.g., vertical alignment). (2) Construct the appropriate tightening depending on the type of relaxation: { For weakened constraints, we must x model inconsistencies relative to the original constraints. To do this, we can rely on existing computational approaches for computing minimal model repairs. The objective here is to search the space of possible changes to the model to nd the minimal changes that x a constraint violation. See Section 5 for a discussion of this work in the literature. If there is still a choice left after the repair process (i.e., there are several possible minimal repairs), then a strategy for dealing with choice must be followed, e.g., to elicit the decision from the modeler, follow a prede ned choice policy or use a partial modeling mechanism as described in Section 3.2. { For vocabulary extensions and other interpretation broadening, a de nition of the new elements/information in terms of constructs in the original language must be elicited from the modeler. Clearly, this requires the use of a transformation language for expressing this rede nition, and we rely on existing solutions for this, e.g., ATL2. 5
The use of relaxation to increase agility has been proposed in various contexts.
There is a long tradition of work on relaxing the input method by allowing
freehand sketching of models. See [
Some modeling tools allow \soft validation" where the satisfaction of wellformedness constraints can be deferred until a more appropriate time when the modeler is nished with a unit of work (e.g., see Microsoft modeling tools3). This mechanism can be used as a limited form of language relaxation but it only addresses constraint weakening and not vocabulary extension. 2 http://www.eclipse.org/atl/ 3 http://msdn.microsoft.com/en-us/library/bb245773.aspx
Metamodel relaxation has been used for purposes other than increasing the
expressive power of models. For example, in [
As discussed in Section 3, the issue of \model tightening" is dependent on
mechanisms for model repair. Due to lack of space, we omit a thorough review of
work in this area and instead only mention recent examples. Many approaches
focus on attempting to formulate repair rules representing various change
scenarios where speci c repair actions are performed in response to detected changes,
e.g., [
Models are used by humans and programs in di erent ways, giving rise to what we have called the agility con ict : humans require expressive freedom while programs require strict conformance to constraints. In this paper, we outlined the beginnings of a framework to address the agility con ict with a focus on two types of agility: omission agility which gives the modeler the freedom to omit information, and clarity agility which allows the modeler the ability to rephrase information to improve clarity. Our approach involves relaxing the modeling language to support these types of agility and then constructing a tightening transformation to put the relaxed model back into a form that can be accepted by MDE processes. We explored the approach through a series of examples, discussing its characteristics and potential tool support. Our next steps are to further develop the theoretical details of this approach and prototype tool support for it.