Viewpoints creation using Obeo Designer or how to build Eclipse DSM without being an expert developer?

Etienne Juliot
Obeo 7 Boulevard Ampre 44 481 Carquefou, France +33 2 51 13 51 42

Jrme Benois
Obeo 7 Boulevard Ampre 44 481 Carquefou, France +33 2 51 13 51 42

etienne.juliot@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!

jerome.benois@obeo.fr 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.

Keywords
MDE, UML, DSL, DSM, Viewpoints, Eclipse, GMF.

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].

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.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 GEF + EMF

Resource 90 days

User Profile Eclipse developer/Ergonomist GMF Expert Designer

GMF Tooling Obeo Designer

30 days 5 days

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: 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:

4.3.1 Node Mapping

A node mapping is a geometric figures with a label.

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 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.

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:

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

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.

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.

6. CONCLUSION
This article has focused on the implementation of viewpoints using Obeo Designer. 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.

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.

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