The day before Eclipse Summit Europe, was the face-to-face Eclipse Board of Directors meeting, so the week was off to an interesting start. I was still organizing the content for the Modeling Symposium the following day. Agile preparation I like to call it though some might use the word procrastination.
I think the symposium was a great success. It was a chance for a large number of presenters to demonstrate their favorite technology in action and gave the attendees a diverse overview of many topics they might not learn about otherwise. Each presenter was kind enough to write a brief abstract, which I've included in this blog.
Jens von Pilgrim mentioned that modeling without diagrams is like Tour de France without mountains: sure you can do it, and it's maybe even easier, but it takes out all the fun. He shows how he can drag from one diagram type to another, i.e., to transform a use case diagram into a class diagram.
Advanced Features for Migrating Models with COPE
When an Ecore model evolves, existing instances may need to be migrated. To automate the migration of these instances, COPE records the instance migration together with the Ecore model evolution in an explicit history model. The history model specifies the sequence of coupled operations that have been performed. A coupled operation encapsulates both Ecore model evolution and instance migration. Instance migration can be further automated by reusing recurring coupled operations. In this demo, we show the more advanced features of COPE to inspect and refactor the history model as well as to reverse engineer it from two versions of an Ecore model.
Markus Herrmannsdörfer demonstrated how he can use the information for transforming one Ecore model to another into a script that can transform an instance of the first model into an instance of a second model.
Modeling Eclipse Plug-in Artifacts
It was cool to see Frédéric Madiot demonstrate how every last detailed aspect of an Eclipse plug-in is represented as Ecore-based model! He then proceeded to show all the things one can do with this information, e.g., implementing additional quality checks such as the need (for the Eclipse release process) for there to be an about.html file, as well transforming a plug-in from being Eclipse 3.x-based to e4-based.
Only One Click to an EMF Application
We will demonstrate how to develop an example application with the EMF Client Platform and EMFStore. A developer only needs to define an Ecore model for the application´s entities. Based on the EMF Client Platform this already defines a basic User Interface for editing. EMFStore allows storing and distributing the instances of the model. Everything just with the click of a button, that is launching an Eclipse instance with the model plug-in.
Jonas Helming and Maximilian Koegel did three quick demos. The first showed how one can rapidly prototype model designs and test their capabilities with a high-quality editor, i.e., one with forms for editing properties. The next showed the CVS-like ability of their model repository. And finally they showed how they can integrate their repository-approach with SVN.
The CDO Model Repository – Being Connected and Unconnected
In addition to the traditional connected mode, the Helios version of CDO comes with a sophisticated offline mode that has been inspired by distributed versioning systems like Git and is almost transparent for end user applications. If you feel uncomfortable with replicating the entire history of all branches of your master repository you may be interested in this demo. We’ll present the brand new offline workspace facility, which provides you with a more CVS/SVN-like workflow: checkout, update, commit. In combination with our new EFS implementation you can seamlessly integrate your CDO-managed object graphs with any existing Eclipse technology that is based on IFiles, while still being able to access the underlying object graphs.
One of the coolest things Eike Stepper shows is the integration with the Eclipse File System where the repository contents are surfaced as IResources.
Papyrus in Action
We will introduce the Papyrus team during the session, and we will then present the MDT Papyrus project itself. The talk will focus on the UML2 abilities of the tool, full compliance towards UML2 specification, and Domain Specific Modeling Language development facilities using UML2 profiles. We will also demonstrate the various possibilities of tool customization and finally we will present the road map for the next releases.
Remi Schnekenburger and Patrick Tessier showed some of the Papyrus capabilities, such as customizing the diagrams based on stereotype application.
Acceleo on e4
During this presentation, you will see a prototype of the modeling project Acceleo on the e4 platform. That presentation will also give you the opportunity to hear the feedback of this experimental transition to e4 with its advantages and drawbacks.
Stephane Begaudeau showed some of Acceleo's nice integration features, such as its own perspective with views that show things like all the objects accessed when generating a particular artifact; an important traceability feature.
Reconciling Multiple Representations for BPMN 2.0.
The new BPMN 2.0 standard provides a good basis for interoperability between Process Modeling tools and engines from different vendors. An EMF metamodel allows one to read and write standard compliant files and offers a good API for all kinds of tools. Such a metamodel was committed to Eclipse MDT project. However it was not as simple to create as you might have thought: Unfortunately OMG defines both, a CMOF metamodel and an XML Schema, resulting in two official file formats that such an implementation must consider. Fortunately EMF provides a solution for almost everything. I’ll demo how you can merge the two sources, the EMF tricks that were used, and how finally the BPMN implementation works.
Reiner Hille-Doering talked about the incompatibilities between CMOF, with multi-inheritance and typed references verses XML Schema which single inheritance and untyped reference. The difference between these two ways of defining the model needs to be reconciled to produce a single model capable of reading and writing the exchange format implied by each definition. Because it's a large model, he defined an automated way of merging the two to produce a single result annotated with extended metadata.
Dynamic Domain Models for JUnit using EMF, redView and Xtext
Implementing unit tests for business applications means running the same test classes again and again with different inputs and expected outputs. This session should demo, how EMF, redView and Xtext can be used to create reusable test instances which can be configured by dynamic domain models.
- Xtext defines the test case specific domain model
- redView renders and binds a matching ui at runtime
- EMF stores the information in a key-value-map
Florian Pirchner showed how they can use model changes to dynamically update JDT's AST to reflect those changes.
Bonita Open Solution: Leveraging Modeling Power for Customization
Aurelien Pupier showed two of their GMF-based editors. Their editors have nice contextual palette that make creating models very easy. They've done a good job making a stylish application.
Typesystems for Xtext Languages
Ever wondered about how to efficiently write the constraints for checking the correctness of non-trivial typing rules in Xtext languages? This short talk introduces the Xtext Typesystem framework which supports the declarative definition of a wide range of typing rules for Xtext languages. I will show a few slides to explain the background and how it works, and then I'll demo how to integrate a typesystem with an actual Xtext language editor.
Markus Völter showed a grammar for a simple expression language and proceeded to demonstrate how a simple type system can be constructed from that. E.g., define the types of the literals (i.e., of the leaf expressions) and then the rules for deriving the type of composite expressions.
Modeling Meets JDT: Leverage Java Types in Your Models
A tight integration with the Java Types and the Java Development Tools (JDT) is a sweet spot especially, but not only, for textual modeling. That's why we developed a lightweight EMF representation of the Java VM types, their operations, and fields as part of the Xtext framework. In this short demo I'll show how we used the abstractions of EMF and the power of dependency injection by means of Google Guice to allow a seamless integration of modeling components with Java VM types. Especially interesting is the dedicated EMF resource implementation that allows clients to work transparently with the Java reflection layer or the available information from a JDT based Eclipse Java project. Furthermore, I'll give a short demo on how the Modeling Workflow Engine (MWE) leverages this feature to provide a highly extensible configuration language including advanced tool support for users.
Sebastian Zarnekow started with a simple DSL to show how, with the use of the JVM type model, it's possible to refer to Java classes. It seamless derives its information either from JDT or via Java reflection, depending on your environment context. Very cool and powerful stuff.
Xdoc - When Writing Documentation is Fun
Xtext comes with extensive documentation published as Eclipse Help, as HTML on our website as well as PDF for printing and offline reading. The documentation is written in Xdoc, a markup language tailored for the purpose of writing documentation for Eclipse projects. This is a short demo of Xdoc and its editing features.
One of the things Sven Efftinge requested is for folks to post information on 328477 about their use of Xtext. He then proceeded to demonstrate the capabilities of Xdoc, a DSL similar to wiki and TeX for writing documentation, with a simple example document.
Diagram views of Xtext Grammars (5 minutes)
The Xtext Syntax View visualizes the syntax of your Xtext language in a railroad diagram. It helps to analyze, debug, and document your Xtext based languages.
Jan Köhnlein's very quick demonstration of his railroad diagram pet project was very cool, so much so that I neglected to get his picture! So I took his snapshot during the beer and pretzel reception right after.
Eclipse Modeling Platform
The Eclipse Modeling Platform (EMP) is an industrial quality integrated software platform to enable complete chains of model-centric tools in organizations focused on model driven development. The requirements for EMP are being set by some of the largest companies using model driven development. EMP will be developed as an Eclipse Industry Working Group supporting a collection of open source projects and encouraging a commercial ecosystem of value-added tools and services. The platform will be based on existing Eclipse modeling technologies but focus on better integration, quality, scalability and usability for modeling professionals.
Stephan Eberle gave much the same talk as he did a the Eclipse Modeling Day in Zurich last week.
The rest of the conference, as expected, was fantastic as well. I didn't get to attend all the talks I would have liked to attend, but face-to-face time is one of the primary reasons for traveling to these types of events, so it often takes priority. As with all good things, it came to an end all too quickly.
Friday November 5th, the day after the conference, was a face-to-face meeting of the Modeling Platform Industrial Working Group. It was held at the conference center. Stephan Eberle and Martin Mandischer have been doing a fantastic job gathering requirements, analyzing the gaps that need attention, and outlining a plan for making it happen. Things are progressing well.
No trip to Germany is complete without a stop in Berlin, so that's where I headed Friday night to meet up with Frank, who had been there all that week. We even had a chance to visit Dresden on Sunday. Neither pictures nor words can do that city justice!
Today is our last full day in Germany before heading home to Vancouver tomorrow. It's been a great trip and I'm sure we'll be back soon.