=Paper=
{{Paper
|id=Vol-1554/PD_MoDELS_2015_paper_6
|storemode=property
|title=MMINT: A Graphical Tool for Interactive Model Management
|pdfUrl=https://ceur-ws.org/Vol-1554/PD_MoDELS_2015_paper_6.pdf
|volume=Vol-1554
|authors=Alessio Di Sandro,Rick Salay,Michalis Famelis,Sahar Kokaly,Marsha Chechik
|dblpUrl=https://dblp.org/rec/conf/models/SandroSFKC15
}}
==MMINT: A Graphical Tool for Interactive Model Management==
https://ceur-ws.org/Vol-1554/PD_MoDELS_2015_paper_6.pdf
MMINT: A Graphical Tool for Interactive Model
Management
Alessio Di Sandro ∗ Rick Salay ∗ Michalis Famelis ∗ Sahar Kokaly † and Marsha Chechik ∗
∗ University of Toronto, Canada
Email: {adisandro, rsalay, famelis, chechik}@cs.toronto.edu
† McMaster University, Canada
Email: kokalys@mcmaster.ca
Abstract—Model Management addresses the accidental com- An effective user environment requires a rich interactive
plexity caused by the proliferation of models in software engineer- user interface and automated user assistance. We elaborate
ing. It provides a high-level view in which entire models and their on these in the context of model management:
relationships (i.e., mappings between models) can be manipulated
using transformations, such as match and merge, to implement • Interactive User Interface - Megamodels provide the
management tasks. Other model management frameworks focus means for raising the level of abstraction to manage
on support for the programming required to prepare for model complexity in model management, thus they are the nat-
management activities at the expense of the user environment
needed to facilitate these activities. In this paper, we demonstrate
ural user interface for model management. Furthermore,
MMINT- a model management tool that provides a graphical the user should be able to interact with the type level
and interactive environment for model management. MMINT where model types (i.e., metamodels), relationship types
has many features that help manage complexity while reducing and transformations are defined as well at the instance
effort in carrying out model management tasks. We illustrate level where particular model management scenarios are
these features with a realistic model management scenario. (See
video at: http://youtu.be/7B7YuV-Jvrc)
expressed and carried out. Interactivity is an important
characteristic of the user interface. Due to the complexity
of model management tasks, they often can only be
I. M OTIVATION AND G OALS partially automated. For example, performing a match
between models may need to be manually verified to
Modern software development requires managing multi- ensure the correspondences are sensible, and performing
ple, heterogeneous software artifacts, but the proliferation a merge of models may yield conflicts that need to be
of models creates an accidental complexity that must be manually resolved using human judgment.
managed. Model Management [1] addresses this challenge. • Automated User Assistance - Many model management
This is realized through the use of special models called activities are one-off tasks that suggest the need for
megamodels [2] to represent model management scenarios at a low effort rapid implementation, possibly with manual
high level of abstraction and general purpose transformations steps, rather than a polished and fully automated process.
(also called operators) [3] to manipulate models and their Even activities that become fully automated often initially
relationships (i.e., mappings between models) in order to require experimentation and exploration to get them right.
perform useful tasks. For example, a model match operator User assistance to help adapt transformations for reuse,
finds correspondences between two models and packages these support reasoning about models, etc. can reduce effort
as a mapping between the models. A merge operator can be and help manage complexity.
used to combine the content of the two models using the
correspondence information in the mapping. In this paper, we describe our tool called MMINT (“Model
Management INTeractive”) for graphical, interactive model
Several model management frameworks have been devel-
management. We summarize the features of MMINT address-
oped to support Model Driven Engineering (MDE) by facil-
ing the requirements discussed above.
itating the development of operators and the implementation
of specific model management tasks. For example, Epsilon [4] • Interactive User Interface
provides multiple domain-specific languages, each specialized – instance level megamodel - MMINT provides a
for a different model management task such as merge, val- customizable environment in which modellers can
idation, transformation, etc. The Atlas suite of tools [5] is graphically create model management scenarios us-
centred around the ATL transformation language and its use in ing megamodels at the instance level, interactively
different model management tasks. These frameworks focus on apply transformations and immediately see their re-
the programming required to prepare for model management sult and, when necessary, manually drill-down into
rather than the user environment required to carry out model the detailed content of particular models or relation-
management tasks. However, such an environment is a key ships.
factor for practical model management. – type level megamodel - a megamodel is used at the
type-level to visualize and allow rapid modifications
of the type hierarchy of model types, relationship
types and transformations at run-time to immediately
impact instance level megamodels.
• Automated User Assistance
– megamodel operators - the generic operators map,
filter and reduce, available in many programming
languages to simplify complex collection-based ma-
nipulation tasks, are built-in and adapted for use with
megamodels [6]. Fig. 1. Type megamodel in MMINT used for the examples in this paper.
– type coercion - a type coercion mechanism is avail-
able that automatically performs the necessary con- B. Executing the scenario
version transformations required to reuse transforma-
tions from related types. In MMINT a megamodel is referred to as a MID (Model
– retyping - a type down-casting mechanism is avail- Interconnection Diagram). MMINT uses a distinguished Type
able that automatically detects cases when a model MID in which model types, relationship types and transforma-
satisfies the constraints of a more specialized type tions are registered. Fig. 1 shows a screenshot of the Type MID
and thus can use its transformations. used to implement the scenario. Here, boxes represent model
The rest of this paper is organized as follows: In Sec. II types and thick blue links between them are binary relationship
we introduce and illustrate the features of MMINT by imple- types. The sub-typing between types is shown with the hollow-
menting a detailed model management scenario. In Sec. III, headed arrows. Transformations are ovals connected to their
the architecture of MMINT is described. Finally, in Sec. IV, input and output types with named links (not shown to avoid
we conclude with a summary of the paper and a discussion of clutter). For example, our scenario needs class diagrams and
future research directions. so ClassDiagram is a model type that is a sub-type of the
general model type Model. The binary relationship type CDRel
II. U SING MMINT FOR M ODEL M ANAGEMENT is a used to create mappings between ClassDiagram models.
CDMatch is a transformation that takes two ClassDiagrams
In this section, we use a model management scenario to
as input and produces a CDRel between them as output that
illustrate the MMINT features addressing the requirements for
contains links between classes that have the same name. Note
a model management user environment discussed in Sec. I.
that even the built-in megamodel operators Filter, Map and
A. Illustrative scenario Reduce appear as transformations in the Type MID.
At the instance level, MMINT is used to create MIDs
Consider the following model management scenario. A using a MID editor that allows an engineer to interactively
company uses a megamodel to track its modeling artifacts create or import models, relationships and other MIDs, invoke
(models and relationships between them). The company has transformations on them and inspect or change the results.
determined that having public attributes in class diagrams We will incrementally and interactively build a MID called
is undesirable and now (1) would like to identify all class Scenario as we carry out the steps of the scenario. Fig. 2
diagrams that contain this construct, (2) refactor them using a (top-right) shows a screenshot of the final state of this MID
predefined transformation to remove the construct, (3) merge after step (4). Initially, Scenario contains only the top left-
the modified class diagrams with the originals into a single most box referring to MID Lib (top-left of Fig. 2) that holds
class diagram, and finally, (4) produce a textual representation the class diagrams the company wants to process. We have
of the merged class diagram. limited the the number of CD’s in MID Lib to four for this
We now show how MMINT can be used to accomplish this illustration; however, the scenario scales well (See [6]).
scenario. Table I summarizes the MMINT features and the step
of the scenario in which they are illustrated. Step (1). In the first step we need to separate out the class
diagrams in Lib that contain public attributes. We can use
TABLE I
MMINT FEATURES AND WHERE THEY ARE ILLUSTRATED IN THE the megamodel operator FilterhTYPEi that, when applied to
SCENARIO . a MID, removes all models/relationships that do not conform
to type TYPE (See [6] for details); however, we need a
Requirement MMINT Step
model type that represents class diagrams that contain public
Interactive User Instance megamodel All
Interface Type megamodel 1 attributes. The Type MID allows an engineer to create new
Megamodel operators types and use them immediately. Thus, we use the Type
map 2,3 MID editor to define a new sub-type CDPublicAttributes
Automated User filter 1
Assistance reduce 3 of ClassDiagram containing the following OCL well-
Type coercion 4 formedness constraint:
Retyping 1
Fig. 2. Screenshot of the final state of MID Scenario and selected other MID’s used or created in the scenario.
CDPublicAttributes: Step (3). Now we wish to merge the class diagrams in
Attribute.allInstances()->exists( NewLib into a single class diagram. We have available to
attribute | attribute.public) us a class diagram merge transformation CDMerge that takes
Similarly, we create sub-type CDNoPublicAttributes two class diagrams and a CDRel relationship between them
with the negation of this constraint. Both are shown in Fig. 1 indicating how the class diagrams overlap [3]. That is, if the
as sub-types of ClassDiagram. We then split Lib into new relationship has a link between two classes then CDMerge will
MIDs Pub (containing CD PowerWindow and ACC) and combine these classes into a single class in the output merged
NoPub (containing CD Engine and Infotainment) model. Unfortunately, our MID NewLib contains only class
by applying FilterhCDPublicAttributesi and diagrams and no relationships indicating their overlap. We
FilterhCDNoPublicAttributesi, respectively, to Lib. can fix this by first using the transformation CDMatch that
creates a CDRel between two class diagrams and puts links
This step also illustrates the retyping feature of MMINT.
between classes with the same name. We could apply CDMatch
Even though the class diagrams in Lib are typed as
manually to each pair of class diagrams in NewLib but to
ClassDiagram, MMINT can check them against a sub-type
save time, we apply MaphCDMatchi to NewLib and get all the
(e.g., CDPublicAttributes) and automatically retype them
relationships in one step in the MIDRel MatchR. A MIDRel is
if they conform. This feature can be invoked manually on any
a megamodel containing only relationships. Finally, we union
model by the engineer or internally by other operators – in
these relationships with the class diagrams to produce MID
this case, Filter. When invoked manually on a model (via
NewLibR (content shown in Fig. 2).
right-clicking and a context menu), MMINT traverses the type
hierarchy to check the model’s conformance with all sub-types At any point in our scenario we can drill-down into models
and returns the list of retyping options for selection by the user. or relationships to examine results or manually intervene
in the process. For example, we may want to manually
Step (2). In this step, we use a standard class diagram refac- check or modify individually relationships that MaphCDMatchi
toring transformation, called AddGetters, that replaces each produced to confirm that the correct classes are linked. To
public attribute with a private attribute and a corresponding do this, we would double-click on a relationship (thick blue
getter method. MMINT allows transformations in any language arrow in NewLibR ) and view or edit it using the MMINT
to be added to the Type MID. In this case, we have used relationship editor.
Henshin [7] to implement AddGetters. We want to apply Now we can merge the models in NewLibR pairwise using
AddGetters to every class diagram in MID Pub. We can CDMerge. To do this quickly we use the megamodel operator
achieve this by using the megamodel operator MaphMAPPERi ReducehACCUMULATORi that accepts an arbitrary “merging”
that applies a transformation given by parameter MAPPER to transformation and keeps applying it until it can be ap-
each model/relationship in a MID (See [6] for details). In this plied no more (See [6] for details). In this case we apply
case, we apply MaphAddGettersi to Pub to produce MID ReducehCDMergei to MID NewLibR to produce the MID
RefPub containing the refactored class diagrams. We then NewLibM containing a single class diagram with the merged
use the built-in operator Union to produce MID NewLib that content of the class diagrams in NewLibR.
combines the MID RefPub with the class diagrams containing
no public attributes in MID NoPub. Thus, NewLib is the same Step (4). In the final step of our scenario we wish to create
as the original MID Lib but with refactored class diagrams. a Java representation of the the merged class diagram in MID
Relationship the type support runtime layer as transformation definitions.
MMINT MID Editor Editor The definition includes metadata specifying the input and
Type MID output types and other attributes such as whether this is a
Type Support Runtime conversion transformation used by the coercive typing feature.
(Model, Relationship, Transformation) Transformations can also be designated as higher order and
EMF GMF OCL take types or transformations as parameters. The megamodel
Eclipse operators Filter, Map and Reduce are implemented in this
Fig. 3. Architecture of MMINT. way. Transformation metadata is stored in the Type MID (See
Fig. 1) for use at run-time.
NewLibM. Assume we already have a transformation CD2Java
that converts a class diagram to a Java model (i.e., based MID Editor. The MID Editor provides the user interface
on a Java metamodel). In addition, we have a transformation through which MIDs are created and manipulated. Double-
Java2Text that produces the textual code of a Java model. clicking on an element (model, relationship or MID) opens
One way to get the result we want is to apply these trans- the corresponding artifact using the appropriate editor. Right-
formations in sequence on the merged class diagram in MID clicking on an element brings up a context menu that provides
NewLibM. However, this step can be simplified by using the functionality appropriate to the corresponding artifact includ-
MMINT feature of type coercion that enables transformation ing retyping assistance, transformations that can be applied
reuse. (including indirect ones via coercion) and validation.
MMINT allows some transformations in the Type MID IV. C ONCLUSION AND FUTURE WORK
to be explicitly marked as conversion transformations and
this is the case with CD2Java (See Fig. 1). Normally, when Existing model management frameworks focus on providing
a model is selected in a MID and right-clicked, MMINT programming tools in preparation of model management,
computes the list of applicable transformations based on the rather than providing a user environment in which to carry
Type MID and presents a list to the engineer to choose from. out model management tasks. MMINT allows users to perform
The type coercion features means that MMINT not only lists automatically assisted model management tasks through the
the transformations that directly apply to the model based on use of interactive type and instance megamodels. We have
its type, but also transformations that could indirectly apply if illustrated this in a detailed model management scenario.
the model was first converted using conversion transformations In the future, we intend to extend MMINT with a formal
and it does the conversions automatically. In our scenario, model management workflow language, that allows users to
this means that when we right-click on the merged class construct verifiable model management scenarios as chains
diagram in MID NewLibM, the transformation Java2Text of declarative model management operations (e.g., model
will be available and if selected, MMINT runs the necessary translation, model merge) with the use of predefined workflow
CD2Java conversion behind the scenes and then deletes the constructors (e.g., sequential composition, branching, etc.). We
intermediate result. are also investigating how to integrate MMINT with other
model management approaches.
III. MMINT A RCHITECTURE
1 R EFERENCES
MMINT is an evolution of the MMTF model management
framework [8] adding the Type MID, support for retyping, type [1] P. A. Bernstein, “Applying Model Management to Classical Meta Data
Problems,” in Proc. of CIDR’03, vol. 2003, 2003, pp. 209–220.
coercion and megamodel operators. MMINT is implemented [2] J. Bézivin, F. Jouault, and P. Valduriez, “On the Need for Megamodels,”
in Java and uses the Eclipse Modeling Framework (EMF) [9] in Proc. of OOPSLA/GPCE Workshops, 2004.
to express models and the Eclipse Graphical Modeling Frame- [3] G. Brunet, M. Chechik, S. Easterbrook, S. Nejati, N. Niu, and M. Sa-
betzadeh, “A Manifesto for Model Merging,” in Proc. of GAMMA at
work (GMF) to create custom editors for editing models and ICSE’06, 2006, pp. 5–12.
relationships. The overall architecture of MMINT is illustrated [4] D. S. Kolovos, L. M. Rose, A. Garcia-Dominguez, and R. F. Paige, The
in Fig. 3. Epsilon Book. Eclipse, 2015.
[5] J. Bézivin, F. Jouault, P. Rosenthal, and P. Valduriez, “Modeling in the
Model and Relationship types. Metamodels for new types large and modeling in the small,” in Model Driven Architecture. Springer,
2005, pp. 33–46.
can be plugged in or created directly through the Type MID. [6] R. Salay, S. Kokaly, A. Di Sandro, and M. Chechik, “Enriching Meg-
Implementations for supporting tools such as type-specific amodel Management with Collection-Based Operators,” in Proc. of MOD-
editors, validation checkers and solvers can also be plugged in ELS’15 (To appear).
[7] T. Arendt, E. Biermann, S. Jurack, C. Krause, and G. Taentzer, “Henshin:
and are managed by the type support runtime layer. A generic Advanced Concepts and Tools for In-place EMF Model Transformations,”
relationship editor is built into MMINT. in Proc. of MODELS’10, 2010, pp. 121–135.
[8] R. Salay, M. Chechik, S. Easterbrook, Z. Diskin, P. McCormick, S. Nejati,
Transformations. New transformations can be implemented M. Sabetzadeh, and P. Viriyakattiyaporn, “An Eclipse-Based Tool Frame-
work for Software Model Management,” in Proc. of Eclipse Workshop @
in Java or any transformation language and plugged into OOPSLA’07, 2007, pp. 55–59.
[9] D. Steinberg, F. Budinsky, E. Merks, and M. Paternostro, EMF: Eclipse
1 Available at: http://github.com/adisandro/MMINT Modeling Framework. Pearson Education, 2008.