4.1 Introduction and Background
4.1.1 Eclipse
The original meaning of Eclipse is “an astronomical event that occurs when one celestial object moves into the shadow of another.” [Ecl]. When IBM chose “Eclipse”
to name its new Java Integrated Development Environment (IDE), it was directly targeting the Microsoft’s Visual Studio and Sun Microsystems’ Sun One Studio. After a nine‐year development, Eclipse became one of the most popular IDEs in the Open Source Community not only for Java but also for C, PHP and other programming languages.
According to the official definition, “Eclipse is an open source community, whose projects are focused on building an open development platform comprised of extensible frameworks, tools and runtimes for building, deploying and managing software across the lifecycle.” [Ecli]
4.1.2 Model-Driven Software Development (MDSD)
Generally, talking about the modeling diagram, the UML (Unified Modeling Language) and the diagrams drawn with UML come into our mind. A lot of development teams have increased productivity and quality by introducing the Model‐Driven Software Development.
Before using the Model‐Driven Development (MDD), a Model‐Driven Architecture (MDA), which is “a software design approach for the development of software systems” [MDA], has to be built firstly. The MDA includes defining Platform Independent Model (PIM), determining the target platform, defining the transformation and applying the transformation either manually or automatically.
Thank MDD, software development now turns to a model transformation. All of the models are independent with each other and separately defined. Each transformation is from an abstract level to a less abstract or concrete level, until a target system implementation is reached.
The EMF (Eclipse Modeling Framework) and GMF (Graphical Modeling Framework), which will be introduced later, are the implementations of OMG modeling standards.
Therefore, the development of the graphical editor with GMF is based on MDSD.
4 Eclipse Modeling Projects and Plug‐In
4.1.3 The Eclipse Modeling Project
Eclipse Modeling Project, which is a relative newer top‐level project in the Eclipse Community, aims to improve and widespread MDSD technology within the Eclipse Community. It provides the following capabilities: Abstract Syntax Development, Concrete Syntax Development, Model Transformation and the latest started Modeling Amalgamation Project (Amalgam), which “provides improved packaging, integration, and usability of Modeling project components” [EclMP].
Abstract Syntax Development includes the core project of Eclipse Modeling Project – Eclipse Modeling Framework (EMF), which has been existed since the appearance of Eclipse platform. EMF provides Model Transaction component, Model Validation framework, Model Query component and Model Search component etc. It also
“supports the definition of abstract syntax for modeling languages like Object Constraint Language (OCL) and Unified Modeling Language (UML)” [EclMPC].
Within Concrete Syntax Development it contains Graphical Modeling Framework (GMF) “providing a generative component and runtime infrastructure for developing graphical editors based on EMF and GEF” [EclMP] and Textual Modeling Framework (TMF) “providing tools and frameworks for developing textual syntaxes and corresponding editors based on EMF” [EclMP]. With GMF we can generate a powerful graphical editor, while with TMF we can create a high quality textual editor.
In this paper we focus on the GMF.
Using Model‐to‐Model Transformation (M2M) and Model‐to‐Text Transformation (M2T) projects we can generate a user‐defined graphical or textual editing environment. Within the M2M project the M2M rules can be defined to generate another model from already existed instance models, while within the M2T project the M2T rules can be defined to generate the requested text template.
4.2 Eclipse Modeling Framework (EMF)
“The EMF project is a modeling framework and code generation facility for building tools and other applications based on a structured data model” [EMF]. It helps programmer to generate Java code from user‐defined models automatically. The generated Java code can be modified and edited just like other normal Java code. For example, the user‐defined methods and variables can be added. When the Java code has to be regenerated caused by model changing, the user‐defined methods and variables will not be overwritten using Java annotations. The model can be stored as an XML file, which has been widely used as a standard, so that the capability of model interchange is quite easy. On the contrary, the model can be created by annotated Java code or XML.
During the generation from Ecore model to Java codes, the GenModel, which “is a
decorator model for the Ecore Model” [EMFfaq], is used to define or control the generation process. EMF provides the following key functions: EMF (Core), Compare, Model Query and Validation Framework.
4.2.1 EMF (Core)
EMF contains the following three fundamental parts: EMF, EMF.Edit and EMF.Codegen.
Within the core EMF framework, Ecore is used as a meta‐model to describe model and the runtime environment. The details and the creation of Ecore will be discussed in Chapter 5.
EMF.Edit framework provides an easy understanding graphical editor, where the model is modified. In the meantime, the stored XML file is also modified synchronously. Using command stack makes the editor to support the automatic undo and redo.
EMF.Codegen facility is able to generate the Java code to build the EMF model editor.
4.2.2 Compare
EMF Compare “brings model comparison to the EMF framework, this tool provides generic support for any kind of meta‐model in order to compare and merge models”
[EMF] Moreover, it also provides the following different compare methods: a Standalone Core providing a jar‐based comparison independent of Eclipse runtime, Team Providers Integration with SVN, CVS or GIT, Extensible Framework developed by Eclipse Plug‐in facility.
4.2.3 Model Query
The query component “facilitates the process of search and retrieval of model elements of interest in a flexible yet controlled and structured manner” [EMF].
Model Query provides the SQL‐like query methods. The SELECT class accesses the set of models iteratively, collects the result set according to the query conditions to QueryResultSet object and then returns the QueryResultSet to the caller. The FROM class determines or limits the search area and provides an iterator for elements in the search area. The WHERE class restricts the query conditions. The UPDATE class is similar to the SELECT class, and additionally provides the modification function. QueryResultSet class is used to store the result sets and return them to the caller. Moreover, Model Query provides EObjectCondition
class, ConditionPolicy class and
EObjectStructuralFeatureValueCondition class as well.
4 Eclipse Modeling Projects and Plug‐In
4.2.4 Validation Framework
Validation Framework provides batch and live validating methods. The validation process can be either explicitly executed after the modification of models or implicitly and live invoked during the modifying of models. The implicit validation needs a validation listener to monitor the validation events. Within the Validation Framework, the programmer can define various constraints with either Java or OCL.
4.3 Graphic Editing Framework (GEF)
4.3.1 Introduction
After creating the meta‐model through EMF and generating our user‐defined model, a graphical editing environment is needed to simplify the model development. A general problem is how to reflect the modification in graphical editor to the model description file synchronously. For example, when editing the graphical description of BPMN in a graphical editor, the corresponding XML schema should also be changed synchronously. Model‐View‐Controller (MVC) is one of the most popular solutions used in GEF.
“The Graphical Editing Framework (GEF) allows developers to create a rich graphical editor from an existing application model. It consists of 2 Plug‐ins. The org.eclipse.draw2d plug‐in provides a layout and rendering toolkit for displaying graphics. GEF employs an MVC architecture which enables simple changes to be applied to the model from the view” [GEFWiki].
4.3.2 Model-View-Controller (MVC)
Model‐View‐Controller (MVC) is “a software architecture, currently considered an architectural pattern used in software engineering. The pattern isolates domain logic (the application logic for the user) from input and presentation (GUI), permitting independent development, testing and maintenance of each” [MVC]. In MVC architecture, Model acts as back‐end, which provides the operation of application, the generated front‐end View is generally represented by a GUI, which presents the back‐end Model with various graphics or other ways. The Controller accepts the input from Viewer; passes it to the back‐end model and then returns the results to Viewer.
The following description is about the MVC control flow. The user changes the Viewer in UI through e.g. mouse click. The Controller listens the UI event and handles the input event. After converting the event to a Model understandable access, the Controller passes the converted event to back‐end Model. The Model will
do some corresponding operations and notify the Viewer through Controller. The modification will be represented in the UI. Through the decoupling of Model and View, which increases the reusability of code, the complexity of Model and View design has been reduced.
4.3.3 Draw2D
Within the GEF editor, the elements like figure, text, layout and connection drawn by user are provided by org.eclipse.draw2d plug‐in package.
Before painting figure, the paint() method will do some initializations like preparing the font, foreground and background color. After the initialization, the paintFigure() method is called to paint figures. In case the child figures are needed, the paintClientArea() method, which sets up a specified area for child figures, has to be invoked. Any operation on child figures is not allowed to beyond this area. After setting up the specified area, the paintChildren() method is invoked to paint child figures. Finally, the paintBorder() method is called to specify the border of the figures. The child figure is not allowed to exceed its parent’s border. Otherwise, the exceeded parts have to be cut off. During the
painting, we can use org.eclipse.draw2d.label and
org.eclipse.draw2d.text package to add label or text.
After painting the figures, the layout setting is checked. If layout is used, the implementation of layout is divided into two steps. Firstly, all figures will be marked as “invalid”. Secondly all these marked figures will be validated. During the validation, the information like minimum, maximum and preferred size, position etc. has to be proved. If the figure is modified, these two steps of validation have to be reprocessed.
Draw2d also provides connection figure, which is a special figure. Connection figure aims to connect other figures from various child areas. Therefore, the border of connection figure is not defined.
4.3.4 GEF
In MVC architecture, draw2d provides View with figures and connections while the Ecore in EMF provides the meta‐model for different GEF models. These models can be written in various formats like Java code, XML Schema. The Controller function is provided by GEF EditPart, which provides a bridge between View and Model. It converts user interacted events in UI to model understandable commands and then sends them to model, so that the model modifications can be implemented according to the UI events. And vise vase, the modifications in Model can be reflected to the UI Viewer.
4 Eclipse Modeling Projects and Plug‐In
Converting the model to our user‐defined view is relative simple. It is usually realized by adding listeners, which invoke the refresh operation on the view. But converting the UI events to model is much more complex. As soon as the modifications take effect, a request is generated to require the interface and commands, which are in charge of the modifications, in the model. At the same time the edit policies are set.
The detailed interaction of this process is beyond this paper. We will not expend it here.
4.4 Graphic Modeling Framework (GMF)
4.4.1 Introduction
Compared with GEF project, GMF project is fresher and “provides a generative component and runtime infrastructure for developing graphical editors based on EMF and GEF. It aims to provide these components, in addition to exemplary tools for select domain models which illustrate its capabilities” [GMF]. GMF is based on MVC architecture and separates the diagram and domain model, which increases the productivity and quality.
During GMF development, programmer uses Ecore to describe meta‐model.
According to the description in Ecore, the model, edit, editor and tests codes are automatically generated by EMF Generator Model. In addition, GMF UI also extends the org.eclipse.draw2d package.
4.4.2 Graphical Modeling Framework Tooling
“The GMF Tooling consists of editors to create/edit models describing the notational, semantic and tooling aspects of a graphical editor as well as a generator to produce the implementation of graphical editors” [Pla06].
After generating the model, edit and editor codes, the Graphical Definition Model, which contains the root element canvas, can be created. There are five kinds of element in canvas, which are Figure Gallery, Node, Diagram Link, Compartment and Diagram Label.
Each Figure Gallery has several Figure Descriptors. Under Figure Descriptor one kind of Figure Shapes, e.g. rectangle, rounded rectangle, ellipse, polyline, template point, polyline connection and custom figures etc., can be added. Dimension, layout, label, border and color are stored as shape’s attributes, which can be setup separately.
Finishing the setting of Figure Gallery, the Node element can be added and references the corresponding Figure Descriptor. If the label attribute has been set in the Figure Shape, a Diagram Label element need to be added and linked with it. The Diagram Link is used to associate with the connection figure in the Figure Descriptor,
while the Compartment is usually contained within other figure.
After the editing for Graphical Definition Model, the Tooling Definition Model, which is relative simple, need to be created. It defines the elements, the name of elements, and the icon of elements in editor palette. The order of elements in Tooling Definition Model determines the order of the elements in palette.
The fundamental working stage is accomplished now. Next step is to create a Mapping Model, which is the heart of GMF models and represents a diagram. In the Mapping Model there are Canvas Mapping, Top Node Reference and Link Mapping.
Canvas Mapping defines the domain model, element, palette, diagram canvas etc.
which link the already generated Ecore Model, Graphical Definition Model and Tooling Definition Model.
Top Node Reference indicates the figures, which can be directly displayed on the diagram surface. It links Diagram Node and Tool through its Node Mapping child element. If there is any child figure so‐called compartment within it, a Child Reference is needed, and the Compartment Mapping is used to map the corresponding Compartment in the Graphical Definition Model. Moreover, the Constraint, which is written in Object Constraint Language (OCL) or Java, can be defined. Its tasks include element initialization, link constraint, audits etc.
As for the Connection figure, a Link Mapping is specified to build the relationship between Diagram Link and Tool. The source and target have to be set explicitly.
The Generator Model, which provides the largest model in GMF, is generated based on the Mapping Model and Ecore Model.
4.4.3 Graphical Modeling Framework Runtime
“The generated plug‐in depends on the GMF Runtime component to produce a world class extensible graphical editor” [Pla06]. GMF runtime provides a set of reusable components such as toolbar, palette, diagram menu, connection handles, pup‐up bars, outline view, diagram export to image files etc. It also supports the bridging of EMF and GEF. The service provider infrastructure and extensibility options provide the interface to develop new runtime components based on Eclipse Plug‐In Development Environment via ExtensionPoints. Details of GMF runtime components will be introduced with examples in Chapter 5.
4.4.4 Beyond GEF and EMF
GMF is not only the name combination of GEF and EMF, but also a functional combination of both, which provides higher extensibility to meet the special needs
4 Eclipse Modeling Projects and Plug‐In
of development. Just imaging a complete graphical editor is like a comfortable room for your study. The model built with EMF is a basic renting apartment without any furniture. The graphical editor implemented by GEF is the furniture you have bought.
The various fees such as water costs and energy costs you have to pay are the maintenances of the editor. But when you use GMF, congratulations! You just rent a student dormitory, which has some furniture for your comfortable study. You do not need to pay other costs but the rent. If you think the furniture is not your taste, you can even buy anything as your will.
Compared to GEF and EMF, GMF not only saves a lot of developing costs, but also provides the flexible Plug‐In mechanism.
4.5 Plug-In Development Environment (PDE)
Eclipse is a grown and extensible architecture, which provides an open source platform for creating an extensible IDE. One of the principles of Eclipse platform is the seamless integration of plug‐ins with the workbench and other plug‐ins. The whole Eclipse IDE is an aggregation of various plug‐ins with a runtime core.
In the whole Eclipse plug‐in development environment, extension point, which provides the interface for plug‐ins, is a very important and useful concept. Every plug‐in is developed based on the existing extension point. Those user‐developed plug‐ins can also provide their extension points, so that the further development based on them is possible. Among all of the plug‐ins, Workbench and Workspace are two obligated plug‐ins, which provide a lot of extension points.
Thank plug‐in concept, the launch of Eclipse IDE is much simpler. The core of the platform starts first, and then the system plug‐ins will be found and loaded. Most of the Eclipse’s functions are implemented by plug‐ins. For example, the Workbench UI plug‐in realizes the viewer of Eclipse IDE, which provides extension points for creating plug‐ins to change file menu or add tooling buttons. Even the Java Development Tooling (JDT) is one of the Eclipse’s plug‐ins.
Theoretically speaking, Eclipse IDE is a big puzzle. Everyone can add or remove plug‐ins to build the most suitable Eclipse IDE. The detailed introduction of Eclipse Plug‐in Development Environment is beyond this paper. In Chapter 5 we will give out some closing introductions through the development of car file export plug‐in.