Last week, Obeo, released a major update of their Obeo Designer product. One of the key goals of the tool is to give the ability to create domain specific modeling tools, based on Eclipse GMF (Graphical Modeling Framework) without the knowledge of GMF (or EMF, Eclipse Modeling Framework). The tool is based on the concept of "View Points":
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. In our context, we use to provide our users a set of visual representations focused on a particular concern.
For each viewpoint, 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.Obeo Designers supports the integration between viewpoints, as well as with UML. The UML modeler will be released in the coming months.
InfoQ spoke with Jerome Benois and Freddy Allilaire from Obeo about this new release.
InfoQ: why do you think the enterprise needs to ramp up its modeling capabilities?
Obeo: The big idea of modeling is to abstract from the technologies to reach a “human understandable” level. Tools can focus on business problems and not just on technical constraints. With Obeo Designer, business managers and software architects have the ability to define and share a common language. Modeling formalizes and hence facilitates the consistency of their communication. Each role in the company shows a common model and according to its own vocabulary and concerns.
Obeo’s modeling approach is based on DSLs and Viewpoints to raise this abstraction level. We facilitate the development of models that represent systems based on the analysis of requirements and constraints that the system must fulfill. The first modeling tools where “dogmatic” with standards such as MDA and UML. They were not tailored to help align business needs with information technology. In each case, one had to adapt its own semantics to fit in these tools, inevitably with compromises. Tool providers were faced with the difficulty of defining an ever-comprehensive language.
DSLs offer a dedicated formalism for each domain with as few semantics and concepts as needed. The result is a greater alignment with the business and simplified modeling. But a full DSL approach could be difficult to develop in a large group with several business units that are distinct from each other. It would lead to the emergence of many formalisms for each business units. We believe it is better to define a common language shared by all stakeholders, an ubiquitous language. To be effective and usable by all stakeholders it is necessary to have a projectional approach.The standard IIEEE 1471/D4.1 structures this approach with the concept of viewpoint on a system. Every viewpoint focuses on a given issue. This structure leads to a simplification of the analysis process which is then divided into several concerns clearly defined. Each viewpoint makes it possible to meet a set of questions for a profile given analyst using "views" that will validate the compliance of a given architecture to different rules of perspective. This approach is based on the principles of separation of concerns, refining iterative information but mainly on the exploitation of multiple specialized representations of the same model. The model engineering and MDA approaches are most consistent with this kind of approach because they help define the concepts handled accurately and unambiguously and operate a unified models corresponding to these concepts.
InfoQ: could you share with us some of the problems your customers are tackling with Obeo Designer?
Obeo: Typically, customers use Obeo Designer to collaborate on the design of complex projects subject to many constraints. It allows them to develop a number of tools thanks to a separation with different points of view (logical, physical, safety, etc.) This approach is very generic, recently, we were surprised to see people applying our approach to robotics.
In the Business Modeling context, our product is used to for instance to support the production of Insurance Services and Product Catalog . In Finance, we have customers used by financial analysts to define pricing and business rules in a comprehensive language.
In the context of Enterprise Architecture, Obeo Designer is used to support Enterprise Transformation. It supports TOGAF with key viewpoints : Strategic, Business, Data, Application and Technology viewpoints. This module supports the core diagrams and matrices define by the Open Group specification.
In the System Engineering context, customers use our product to support the system validation and verification based on Hardware / Software Consistency and Functional Analysis.
In Non-Functional Requirement Analysis, Obeo Designer is used to support the production of Timing Constraint Analysis and Risk Analysis.
We will be adding some new case studies to our web site shortly.
InfoQ: When would you recommend users to create a graphical designer vs a textual editor?
Obeo: Some people, usually, more technical, have more affinities with textual notations. Computing languages are more natural and efficient to most of us based on a textual syntax. On the other hand, graphical notations support higher levels of abstraction. The business generally prefers using graphical representations. Some graphical representations are natural to human being like a containment represented as a tree or also a sequence represented as several boxes linked each other by an arrow. Drawing is more natural for representing a workflow or to design a plane. Obeo Designer helps you a lot with graphical representations and it is an important asset of the product. However it provides also other kinds of representations like table and matrix. Also you can mix graphical and textual modeling in a same editor in order to take the best of both approaches. We are fully compatible with Xtext (a tool that provides you a textual syntax for your domain model) and EEF (a tool that provides you a form representation for your domain model).
InfoQ: Code generation has had some difficulties in the past to enter the software construction process, what has changed?
Obeo: The first generations of code generators were mostly based on the black box approach. These solutions were not adaptable to the specific user needs. These kinds of solutions were only practical to generate code skeletons. Of course, the synchronization between your entry point and the corresponding generated code was quickly lost. This yielded little gain from the code generation perspective.
One can note that, code generation has always existed ! what is a code compiler? Fortunately now most of the peoples don’t have to write assembly code and this generation is transparent for us.
Code generation tools (especially those based on modeling) have really progressed and offer a simple syntax, efficient code generation, advanced features on par with modern IDEs like JDT. In Obeo Designer, the solution for code generation is Acceleo. Acceleo is an Open-Source code generation environment based on a pragmatic vision of MDA, hosted by the Eclipse Foundation. It implements the OMG standard: MOF Model to Text Language. It allows the automatic generation of application (or parts thereof) and fit into the agile development movement. A change in the structure of the application can be built much faster than by hand. Acceleo is an adaptive solution with some ready-to-use solutions that fit to specific needs. In addition to Acceleo, Obeo Designer also brings along Obeo Traceability to detect and correct all incoherence and synchronization problems between your application code and your models.
But code generation is not the solution to everything. During the development process, software architects should carefully decide if a technical choice belongs to the framework or to the code generator. There is no global answer and it depends of the use case.
