View source for Eclipse Modeling Day/Session Abstracts Toronto

====Main Tent Session: The Unbearable Stupidity of Modeling====
'''Ed Merks, Eclipse Modeling Project'''<br>
[http://wiki.eclipse.org/images/a/a2/091116MainTentSessionModeling.pdf Slides (pdf)]

====Building DSLs with Xtext====
'''Heiko Behrens, itemis'''<br>
[http://www.slideshare.net/HeikoB/eclipse-modeling-day-2009 Slides (Slideshare)]

Domain-Specific Languages (DSLs) are becoming more and more popular, allowing developers to express their intent more precisely and with less syntactic noise. DSLs can be built on top of a host language (like Java or Ruby), which are referred to as "internal DSLs". External DSLs are far more flexible in terms of language design: You can define any desired grammar, you can define domain specific constraints and error messages. You can process documents written in the DSL by either interpreting them or by transforming them into the code of any language using a generator.

Xtext, which is a part of the Eclipse Galileo release, is a framework for developing textual domain-specific languages. Given an EBNF-style grammar, Xtext automatically generates an Ecore meta model and a rich-featured, fully configurable, text-based DSL editor, including features such as syntax highlighting, hyperlinked reference navigation, reference look-up, code completion, formatting, an outline and so on. The default implementation can easily be customized.

In this session, we will explain what DSLs are and why you should care about using them. After a short introduction, we will show in a live demo how to develop DSLs with Xtext. You will see how to define a grammar for a DSL and create a full-blown editor for this DSL. We will also show how to apply code generation that allows you to transform your DSL scripts into running software.

====B3: A Model for Unbreakable Builds====
'''Ed Merks, Eclipse Modeling Project'''<br>
[http://wiki.eclipse.org/images/d/d7/091118b3.pdf Slides (pdf)]

B3 is a newly created project that is using modeling technology to simplify software build and assembly within Eclipse.  Among the project's objectives are making build processes reproducible and adaptable and bridging discontinuities between software building and provisioning, as well as aligning potentially overlapping Eclipse technologies in the build and provisioning domains. 

This project will examine the ambition and scope of the b3 project from the perspective of an enterprise early adopter with a model-driven approach to software assembly. The internal architect of a leading global financial institution will discuss what his company has done to simplify the assembly and release of Eclipse tooling to developers across the company, as well as their interest in the evolution of their solution through b3.  Initial committer(s) to b3 will provide a more detailed look at the project's goals and objectives of b3, with an emphasis on its use of modeling to simplify  how build/assembly processes are defined, executed, shared and changed.

====Modeling on an Enterprise Scale====
'''Eike Stepper, Consultant'''<br>
[http://wiki.eclipse.org/images/f/f2/091118ModelingEnterpriseScale.pdf Slides (pdf)]

Persisting models in files is not always straightforward. Often you’ll need multi-user support or transactionality with fined-grained object-level locking, i.e., database-style persistence. I’ll introduce the CDO Model Repository, which comprises three tiers and is a general runtime platform for distributed shared models.

We'll not dive into too many implementation details of CDO. I'll rather provide you with a functional overview and explain the benefits in the context of some typical enterprise scenarios. After attending this talk you'll never want to live without the CDO Model Repository in your modeling projects.

====There's a Modeling Solution for That====
'''Bruce Trask, MDE Systems &amp; Angel Roman, MDE Systems'''<br>

Now, more than ever, you can create a domain specific modeling solution for any application.  What used to take years now takes weeks and months. This presentation will present a number of problem domains for which the Eclipse Modeling project was an excellent solution.  We will show you the gory details of the "before" pictures that demonstrate that in almost all cases, up to 80% of the work being done was duplicate and rote work targeted at exposed, unneeded complexities.  We will illustrate how the frameworks and facilities of the Eclipse Modeling project helped tackle these complexities and present the correct level of abstraction to the various audiences of the software solution.

====Papyrus: Advent of an Open Source IME at Eclipse====
'''Kenn Hussey, Independent'''<br>
[http://wiki.eclipse.org/images/b/b2/091118Papyrus.pdf Slides (pdf)]

The role and significance of open source in system design is constantly increasing. Organizations are now widely using open source solutions for many key aspects of development, including real time operating systems, compilers, debuggers and middleware. The key benefits provided by open source include greater control over product roadmaps, lower costs, more features, better support and avoidance of vendor lock-in. Modeling technologies are becoming increasingly relevant to consumers of open source; indeed, with the incubation of e4, modeling has found a home at the very heart of the Eclipse platform itself. With the commoditization of modeling tools at Eclipse, there is a growing interest in the development of an open source tool suite that supports model-based software engineering (MBSE).

In this session, we present Papyrus, an open source, Eclipse-based, integrated modeling environment (IME). The goal of Papyrus, a sub-project of the Model Development Tools (MDT) project, is threefold: first, to provide a complete, efficient, robust, methodologically agnostic modeling tool to both industry and academia; second, to provide an open and flexible facility for defining and utilizing domain-specific languages that allow for customizable validation and code generation; and third, to enable the integration of key MBSE elements such as action languages and model-level debuggers. Initially focused on UML and related standards (such as SysML and MARTE), Papyrus includes a backbone that allows integration of multiple editors and promises all the features that one would expect in an IME, such as a model exploration view, standards-compliant editors, customizable property views and support for collaborative work, advanced profile management, and customization though preferences and extension points. We will explore Papyrus from the perspective of its three communities (developers, vendors, and users) while providing an overview of what functionality currently exists, what we expect to achieve in the first major release (Helios) and where we see the project going in the future.

====AMF and Agent-Based Models: What, Why and How?====
'''Miles Parker, Metascape, LLC, Eclipse Agent Modeling Project (Incubation)'''<br>
Screencasts: [http://www.youtube.com/watch?v=J1gvszjjuGI Video 1], [http://www.youtube.com/watch?v=oOvCIxbxGAA Video 2], [http://www.youtube.com/watch?v=1bVVptIEjoA Video 3], [http://www.youtube.com/watch?v=g4v511f5FBc Video 4], [http://www.youtube.com/watch?v=abPguU0QVqw Video 5], [http://www.youtube.com/watch?v=lYp7Pq44CNM Video 6], [http://www.youtube.com/watch?v=B9HzdKMItEA Video 7]

'''What?''' Agent-Based Models (ABMs) seek to represent important real-world dynamics by designing communities of software agents that mimic real entities. Rather than make simplifying assumptions about such systems and then representing them in equation form or as off the shelf algorithmic constructs, the ABM researcher aims to identify key agent state, interaction spaces, and behaviors. Agents are then "let loose" on our computers and we explore what happens next. The computational horsepower exists today to simulate large numbers (e.g. >>10) of interacting, adaptive and autonomous agents but often desktop computers are all we need to explore significant domains. ABMs have been designed to represent all kinds of important natural systems, at scales reaching from cellular mechanics to international trade and are being used to solve truly hard problems in government, business, and academia.

'''Why?''' Existing scientific models are very good at representing relatively simple systems, and often lousy at representing complex systems. The world is full of complex systems, and our misunderstanding of these systems has contributed to (and arguably helped cause) many of the key challenges facing the world, including the global financial crisis and climate change. ABMs are not a solution to every problem, but they can help us to appreciate and gain unique insight into many systems, and often they can help us to come up with better practical decisions than we might using classic approaches.

I'll try not to spend too much time on the what and why, because the underlying technologies will likely be the most immediately relevant to modeling day attendees...

'''How?''' Meta-Modeling is at the core of the next generation of ABM tools, and the Eclipse Platform and Modeling Project has made it possible. I'll briefly introduce the Agent Modeling Platform (AMP). In addition to the Agent Modeling Framework (AMF), AMP provides execution and graphics frameworks for working with all kinds of software agents (AXF / AGF), as well as a complete ABM modeling environment (Escape).

Because an ABM model has important (and interesting) differences from classic object models, we designed an ABM specific Meta-Model (OMG M2) rather than use EMF directly. I'll discuss the experience of using Ecore as a Meta-Meta-Model (OMG M3) and describe what makes the Agent Modeling Framework Acore Meta-Model unique. I'll also discuss how Xtext makes it possible for us to do seamless and transparent code-generation targeted toward multiple APIs and share my experience designing complex editors within the EMF Edit and Editor frameworks. Finally, I'll demonstrate a new high-level textual language using Xtext and a set of end-user oriented graphical editors developed with GEF Zest for analyzing and designing Acore models.

==== Introduction to Query, Transaction and Validation ====
'''Bernd Kolb, SAP AG & Boris Gruschko, SAP AG'''<br>

EMF offers a rich toolset on top of the EMF core to build modeling tools on an enterprise scale. This implies a large amount of model elements distributed over various files. In such an environment it is essential to have capabilities to locate, modify and validate your model content in a consistent manner. This talk will present you with an overview on:  
* Query - a component to efficiently locate your model elements and merge persistent and in-memory state
* Transactions - a framework to provide a consistent view over model content, shared among different tools and threads
* Validation - helps you to implement business and technical constraints for your models

These components will help you to address the above mentioned issues and provide you with frameworks to use EMF in your own tools.

====Converging Textual and Graphical Editors====
'''Moritz Eysholdt, itemis'''<br>
[http://www.slideshare.net/meysholdt/converging-textual-and-graphical-editors Slides (Slideshare)]

When speaking about modeling, a conflict often comes up whether graphical notations or textual notations are superior. However, both sides have their advantages. For a textual notation existing tool support can be used for comparing, merging and versioning. Furthermore, the well-known comfort of editing a text via the keyboard is present. There are established syntaxes to work with expression statements. Graphical notations, however, have their advantages when the layout of a diagram can help the viewer to understand the underlying semantics. This is the case when, for example, flow or hierarchy is important.

Why not combine the advantages of both worlds? This will be done within this presentation. On the foundation of EMF, Xtext as a textual model framework will be combined with GMF as a graphical modeling framework. Thereby, a model will have a textual notation as well as a graphical notation and both will be editable. The following questions will be discussed:
* What are the strengths and weaknesses of textual notations and what are the advantages of graphical notations?
* How do you design a graphical notation for parts of the model?
* Under which circumstances should the graphical and textual notation share a common abstract syntax? What are the advantages and where are the limits?
* How do you synchronize an Xtext editor's and a GMF diagram editor's contents?
* What are the places where concepts of Xtext and GMF can support each other? Example: validation.

There will be a demo to show the feasibility of the suggested concepts and to provide a first impression of the editor's look and feel.

The approach has been implemented in an industrial project by the presenter. Therefore, the contents are based on first-hand experience.