Viewpoints creation using Obeo Designer or how to build

Viewpoints creation using Obeo Designer or how to build
Eclipse DSM without being an expert developer?
Etienne Juliot
Jérôme Benois
Obeo
7 Boulevard Ampère
44 481 Carquefou, France
+33 2 51 13 51 42
Obeo
7 Boulevard Ampère
44 481 Carquefou, France
+33 2 51 13 51 42
etienne.juliot@obeo.fr
jerome.benois@obeo.fr
ABSTRACT
This paper introduces the concept of viewpoint and shows how to
bring it into play. Starting with a simple example we will detail
the way to construct viewpoints based on a Domain Specific
Language. You have probably already heard about “Eclipse
Graphical Modeling Framework (GMF)” which allows you to
create your own modelers. The aim of this article is to teach you
how to go further and easily showing how to create your own
GMF modelers without having any knowledge about GMF!
Keywords
MDE, UML, DSL, DSM, Viewpoints, Eclipse, GMF.
1. INTRODUCTION
During the last two years we have seen appearing or evolving a lot
of generic languages. These languages have been supported by
frameworks to specialize behavior but introducing complexity and
verbosity of the programs. Recently major evolutions are referring
to language expressiveness in order to introduce directly in its
syntax expression capacities to provide a business semantic. So,
we have seen emerging new languages as Ruby, Groovy or Scala
which offer the possibility to be redefined through “Internal DSL”
[1]. It is about specifics syntax constructions allowing to change
language abstract level in order to specialize it to a given set of
issues.
Engineering world also provides mechanisms for adapting to
business contexts through two main mechanisms: UML profiles
provide a mechanism for extending the standard for introducing
specializations and "Domain Specific Language (DSL)” [3] which
is based on the metamodel definition dedicated to a specific
domain.
The choice between the two approaches has often been guided by
modeling tools gaps. Here we describe a new tool, Obeo
Designer, enabling through the realization of points of view,
manipulate both generic language that a specific language at
different levels of abstraction and provide a total freedom of
graphical representation. The ability to fully configure the
modeling environment offers new possibilities for creating
specific modelers.
This article begins by defining the core concepts used then we
will present Obeo Designer by an overview and its architecture.
After, we will illustrate by a case study.
2. BASIC CONCEPTS
2.1 DSM approach over MOF Models
We call "Domain Specific Modeler over MOF Models" the
approach to build environments based on modeling viewpoints
and operating models conform to MOF [4] standard. This
approach is divided into two subsets: “DSM over UML”, used to
create “homemade” diagrams via an UML profile; and “DSM
over DSL”, used to project information thanks to point of views
expressed by a specific language.
2.2 Semantic model
This is the model containing all the data handled. It conforms to
the metamodel of a specific domain, which may be a DSL or
UML [7].
2.3 Viewpoints
The notion of viewpoints is an abstraction that provides a
specification of a system, limited to a particular set of problems. It
was introduced in the specification IEEE 1471 [8]. In our context,
we use to provide our users a set of visual representations focused
on a particular concern. For example, one system can be
visualized through a dedicated view the performance constraints,
a view of the inheritances of business entities and a view to focus
on the dependencies of each entity. This use role or issue role
separation allows to better guide the user in a modeling approach.
It can thus easily understand the complexity of the modeled
system and the used language, by simpler and more accurate
representations.
Figure 1. Point of view applied on a sphere representing the
system.
2.4 Representation
A point of view provides a set of representations. This concept
defines a projection used to view or edit a set of semantic
concepts. A representation may be presented as a diagram, a table
or matrix.
3. OBEO DESIGNER OVERVIEW
Obeo Designer is an adaptive tool led by points of view. It
provides a setting environment to configure viewpoints and their
various representations. For each, it is possible to define what to
display and their graphic features, tool palettes, and their
associated behaviors. The graphical aspects are dissociated of
behavioral aspects.
This tool is characterized by its ease of use. In fact, learning such
a tool does not require an advanced level of expertise and opens
the way for new uses for designers. Obeo Designer uses an
"odesign" parameterizing template with an interpretive approach
to dynamically build a customized modeling environment. This is
illustrated in Figure 2.
possibilities offered by the « odesign » model. Thus it is possible
to define modelers without even knowing GMF technology.
The following table describes the estimated time needed for
building an industrial quality Relational modeler with the
following technologies:
Table 1. Technology/Resource comparison
Technology
Resource
User Profile
GEF + EMF
90 days
Eclipse
developer/Ergonomist
GMF Tooling
30 days
GMF Expert
Obeo Designer
5 days
Designer
4. USE CASE
4.1 Current viewpoint use case
We currently use the principles of viewpoints in three different
contexts:
4.1.1 Software mining
Figure 2. Obeo Designer overview
Obeo Designer is based on the Eclipse Modeling technological
base from which it takes part in these expandability capacities and
modularity. It is based on the frameworks EMF, GEF and GMF
that offer all the elements to build modelers. Figure 3 illustrates
the general architecture of the tool.
The point of view approach is particularly interesting in the
context of the software mining of existing legacy system,
following the reverse-engineering step. This type of use applies to
semantic models with a lot of information. The analysis needs are
so varied that the approach point of view offers an enormous gain
to classify such information by levels of abstraction.
4.1.2 Embedded Systems Modeling
We experienced Obeo Designer to build an embedded modeling
tool based on MARTE [6]. MARTE is an UML profile that
specializes UML in the field of the real-time systems and
embedded systems. The designer uses a vocabulary real-time
dedicated, without needing to know the full complexity of UML.
Figure 4 shows the three points of view created: application
software, temporal and platform execution.
Figure 3. Obeo Designer Architecture
GMF is a very powerful framework with very good modelers
ergonomics and standardization of the format for storing graphical
information. But it remains complex to understand and requires a
high level of expertise to build industrial quality modelers. Obeo
Designer hides this complexity. Indeed, the knowledge of GMF
experts who designed the solution is exposed through the
Figure 4. Obeo Designer UML/Marte Modeler
4.1.3 Information Systems Modeling
We use Obeo Designer to help the implementation of enterprise
applications (JavaEE, DotNet, etc.). This allows us to offer a
global view following the three areas:

Business: entities, persistence, data access

Component: processing, services, urbanization,

Presentation: cinematic, GUI.
Figure 7. Examples of nodes
4.3.2 Container Node Mapping
Container node mapping are elements in which nodes or other
containers may appear.
4.2 Viewpoints creation
The use case of this paper is the creation of two viewpoints based
on the information system metamodel. Indeed, we want to use the
information describing an information system following two
concerns. The first focuses on the database issues and the second
addresses the systems and networks issues.
Figure 8. Container example
4.3.3 Lists
Lists are specific types of containers to present nodes elements in
a list.
Figure 5. Use Case overview
In our example, an information system contains servers. These are
qualified by a name, a network address, a status indicating if they
are in production and their architecture (64bits or not). A server
can host a database engine. The latter is divided into schemas. A
schema is a set of tables which themselves contain columns
corresponding to any primary keys or foreign keys.
The viewpoint of database. We are interested in creating a
representation as a relational diagram. This diagram is used to
describe the structure of a database schema. Figure 6 illustrates
the creation of an « odesign » model containing viewpoint
database and a relational diagram representation.
Figure 9. List example
4.3.4 Edge Mapping
Edge mapping are links connecting two nodes and/or containers
of them.
Figure 6. Odesign model
4.3 Representation type
After this step, we define the graphical aspects of representation
"Relationship Diagram". So we have to define mappings between
semantic elements and their graphical representations. There are
several:
4.3.1 Node Mapping
A node mapping is a geometric figures with a label.
Figure 10. Connections example
4.4 Graphical diagram of the relational tables
We now focus on the creation of a list container for tables. This
container should contain a list of columns as illustrated in Figure
11:
The element « Container Creation Description Table » provides a
set of instructions and commands allowing the manipulation of
semantic and graphic elements to create table container. Using a
parameterization model simplifies many tasks once reserved for
experts (automatic application of stereotypes, splitted models,
saving a graphical element in several semantic elements, etc.)
Figure 11. Table graphical mapping
The element "Square Description" indicates the graphical used for
each node column. The component "Flat Container Color Black
Style Description ..." indicates the graphical aspect of containers
corresponding with tables.
Figure 12 illustrates the setup of a connection setting between a
column and a primary key to visually represent a foreign key
constraint. The visual appearance is defined by the « Edge Style
Description”. This element consists in a set of properties allowing
to define the type of line and the shape of the connection ends.
4.4.2 Query
The need to browse the model is very important in this kind of
algorithm. In response, the use of OCL [5] or Acceleo [2]
language to browse the semantic and graphical models is
proposed.
4.4.3 Eclipse integration
Figure 15 illustrates the final result.
Figure 12. Foreign keys connections mapping
With only this basic setup, the result is a new type of diagram
« Relational Diagram » available in the modeling environment
when the viewpoint « Database » is selected.
Figure 15. Relationship Diagram modeler
Figure 13. Relational Diagram modeler
4.4.1 The Palette
As it stands, this representation can only visualize the semantic
elements of our information system. We should add tools for the
creation of tables, columns, primary keys and others in order to
have a functional relational diagram modeler. These tools and
corresponding launched actions are also modeled. Figure 14
illustrates the tools setup to create tables, columns, and foreign
keys:
The first two things that strike are the fully integration into
Eclipse (thus avoiding the juggling not included multiple tools)
and the « pretty » character resulting modelers. The latter criterion
may seem fun, but our feedbacks show that it is one of the major
factor in the acceptance of the doings of modeling.
To ensure a daily productivity, the modeling environment
proposes:

a browser for the models and viewpoints;

an Outline view focused on the current container;

an adjustable Properties view;

graphic features for zoom, routing, automatic layout,
exports, etc.;

the terms of filters(to hide/ display elements following
criterions enable to be setup);

layers allowing different analysis levels.
Other kind of viewpoints on semantic elements may now be
created.
The viewpoints of systems and networks. From the same
semantic information, we created a viewpoint dedicated to
Figure 14. Tools to create tables, columns, etc.
systems and networks issues. In the odesign model we add a
tabular representation named “Servers List”.
10 custom views of the same system to facilitate its analysis and
design.
In this case study we have implemented two viewpoints to the use
of two different populations: developers and database
administrators and network systems. They can speak in a language
of their own while sharing the same semantic space.
Figure 16. Odesign model
4.4.4 Tabular representation
The aim of this representation will be to list the servers of the
information system, their status and to calculate the number of
databases they host. A tabular representation consists in rows and
columns and allows a mass capture or an "Excel" analysis. It is
then necessary to define how to input them from the semantic
elements using the following concepts:

correspondence of lines(Line Mapping): to specify
semantic element involved;

correspondence of columns (Feature Column Mapping):
to specify a property of the semantic element. The
content of a column may also be the result of an OCL or
Acceleo query for more advanced treatment.
Figure 17 shows that the background color of each line item
"Server" is subject to the constraint “<%dataBases.nSize>2%>”
expressed with the Acceleo syntax.
5. UML VS DSL OR UML AND DSL?
Who has ever tried to create complex queries on a relational
database using an oriented object model will understand dedicated
language such as SQL is probably more appropriate. Why should
it be different in the modeling languages?
Why store information on the screens, widgets, etc. in classes or
methods stereotypical? Our recommendation is simple: using
UML for what was expected. If your semantic moves away
sharply, avoid the profusion of stereotypes, focusing on a DSL.
Thus, DSL is not against UML and complement each other.
Through the use of viewpoints, it is increasingly easy to find the
representations recommended by UML (sequence, states /
transitions, components, etc.) for DSL, or even models mixing
DSL / UML.
Finally, it becomes possible to regain the freedom of DSL
vocabulary and a graphic representation as simple as PowerPoint,
while storing the semantic information in an UML model.
6. CONCLUSION
This article has focused on the implementation of viewpoints
using Obeo Designer.
Figure 17. Line Mapping example
Similarly it is possible to model behaviors in the Palette of tools
of charts, tables setup allows the definition of actions from the
right click on the cells.
Given the abundance of concepts and notations that can propose a
modeling language, this case was intended to initiate the use of
the viewpoints approach. The goal of this approach is to separate
concerns by area and thus increase the level of expressiveness.
The advantage of such a solution lies in its simplicity of handling
in order to make it accessible to all, the implementation of DSM.
7. REFERENCES
[1] Internal DSL:
http://martinfowler.com/dslwip/InternalOverview.html
[2] Acceleo, Eclipse project: http://www.eclipse.org/acceleo
[3] DSL: http://en.wikipedia.org/wiki/Domain-specific_language
[4] MOF (Meta Object Facility): http://www.omg.org/mof/
[5] OCL (Object Constraint Language):
http://www.omg.org/spec/OCL/2.0/
Figure 18. Servers List table
The final result is illustrated by Figure 18. A new type of
representation "Servers List" is accessible within the Obeo
Designer modeling environment. The editor provides a
spreadsheet to edit the properties of all servers in the information
system.
We could supplement this viewpoint by adding representations in
diagrams to model the network topology, for example. We also
found that viewpoints users have tended to create 1, then 5, then
[6] MARTE (Modeling and Analysis of Real-Time and
Embedded systems): http://www.omgmarte.org/
[7] UML (Unified Modeling Language): http://www.uml.org/
[8] IEEE 1471: http://en.wikipedia.org/wiki/IEEE_1471