Eclipse Summit 2009 - Aspect Oriented Modeling

Eclipse Summit 2009 - Aspect Oriented Modeling

• 1.
  Aspect Oriented Modeling EclipseSummit Europe 2009 Florian Lautenbacher (University of Augsburg, DE) Marc Dutoo (Open Wide, FR) Confidential | Date | Other Information, if necessary © 2002 IBM Corporation
• 2.
  Overview  Introducing Aspects  Requirements for the modeling domain  EMF – annotations and any*  Exploring EMF techniques  Inversion of Control – genmodel as an example  Managing extensions & an AOM framework  AOM Beyond EMF  Conclusion Eclipse Foundation, Inc. | © 2009 by the Open Wide and University of Augsburg. Made available under the EPL v1.0 2
• 3.
  Introducing Aspects An aspect is a unit of modularization of a crosscutting concern with respect to another concerns  Aspect Oriented Programming (AOP) • Has now pervaded software architecture and development. • Dedicated language features (ex. Traits in Scala) • Intrusive (ex. AspectJ in Java) or not (ex. Spring proxies).  The benefits: • Separation of features (logging, security, transactions..) • Improve the readability and maintenance of code The concept of Aspect transcends programming and has echoes in a lot of other areas, as e.g. in modeling. Eclipse Foundation, Inc. | © 2009 by the Open Wide and University of Augsburg. Made available under the EPL v1.0 3
• 4.
  Aspect-Oriented Programming andModeling  Composition points are defined in a join point model  A set of composition points is selected through Pointcut expressions  Composing is done by an aspect weaver (during design / load / runtime).  Distinction of aspects: • Homogeneous aspects: Same aspect used at several places • Heterogeneous aspects: Different aspects at these places.  About Workflows, distinction of join points: • Activity join points (or process-level join points) • Internal join points (interpretation-level join points) Eclipse Foundation, Inc. | © 2009 by the Open Wide and University of Augsburg. Made available under the EPL v1.0 4
• 5.
  Introduction – ExtendingModels Idea and Requirement: Extending models  With additional metamodel elements  With additional properties Why?  Store information that shall not be visible at runtime  Enrich the meta model with data required by applications  Example: in Bonita 4 Workflow Engine, code execution “Hooks”  Allow support for custom actions  Examples: Logging, send emails on specific actions  but also development time information, like UI A generic solution for such problems is needed! Eclipse Foundation, Inc. | © 2009 by the Open Wide and University of Augsburg. Made available under the EPL v1.0 5
• 6.
  Example: Different viewson a workflow 1/2 UML View Eclipse Foundation, Inc. | © 2009 by the Open Wide and University of Augsburg. Made available under the EPL v1.0 6
• 7.
  Example: Different viewson a workflow 2/2 Event-Driven Process Chain (EPC) View Eclipse Foundation, Inc. | © 2009 by the Open Wide and University of Augsburg. Made available under the EPL v1.0 7
• 8.
  Simple EMF technique: EMF Annotations  Classified by Source, contains a key-value map  Example: STP BPMN  Simple and all-purpose  However, not typed, not appropriate to business & domain modeling Eclipse Foundation, Inc. | © 2009 by the Open Wide and University of Augsburg. Made available under the EPL v1.0 8
• 9.
  Simple EMF technique: any* slot  i.e. “untyped” multiple containment reference  Can be used for domain specific modeling  Example: Implementations in STP SCA  Disadvantages : •The model is encumbered by extensions •Extension definitions must always be present •Version management is difficult Eclipse Foundation, Inc. | © 2009 by the Open Wide and University of Augsburg. Made available under the EPL v1.0 9
• 10.
  Further exploring EMFModeling techniques  A common way to do it : EMF modeling ! i.e. creating a « single shot » specific EMF extension  Usually extensibility is defined according to needs • Adding custom information to an element requires subclassing it • In EMF: support through Child Creation Extenders feature  Problem: what happens with many optional extensions that the user can enable “on demand”? • Having several such custom extensions (e.g. from different vendors) would mean to create a new node type that inherits from all of them • Neither flexible nor open to the end user Eclipse Foundation, Inc. | © 2009 by the Open Wide and University of Augsburg. Made available under the EPL v1.0 10
• 11.
  Adding Inversion ofControl  The extension model references the enriched model  Example: JWT‟s genmodel vs ecore model  Enables domain specific modeling, but…  Still no way to manage extensions coming from several different providers enriching the same model Eclipse Foundation, Inc. | © 2009 by the Open Wide and University of Augsburg. Made available under the EPL v1.0 11
• 12.
  Managing model extensions: JWT Conf Model  Our solution: the JWT Conf model and framework  Example: Logging Eclipse Foundation, Inc. | © 2009 by the Open Wide and University of Augsburg. Made available under the EPL v1.0 12
• 13.
  How does theJWT Conf Model work ?  Aspect-oriented extensions of the Workflow Editor  EMF models are enriched through a Configuration (ConfModel) consisting of Profiles (features)  Typed Aspects are defined in Profiles  Aspects are instantiated on elements of the decorated model Eclipse Foundation, Inc. | © 2009 by the Open Wide and University of Augsburg. Made available under the EPL v1.0 13
• 14.
  Towards an AOMframework  Additions to the UI  emf.edit extensions (display Aspects in Outline and Property Sheet)  emf.editor-based default editor  And also custom property tabs  Sample Aspects  Custom Properties : all purpose key-value  Semantic annotations (in SemPro)  SCA, RMI Actions (in OW2 Scarbo)  Governance  For now, processes (in our case, documented on the wiki)  Going further, envisioning a repository of compatible types and extensions Eclipse Foundation, Inc. | © 2009 by the Open Wide and University of Augsburg. Made available under the EPL v1.0 14
• 15.
  AOM Beyond EMF:OMG proposal  One of the first submissions for the OMG RFP « MOF Support for Semantic Structures » (SMOF) included the concept of Facets to represent information about different views on one object in possibly different contexts.  «A facet is a MOF element that describes something identified in the world. Multiple facets may contribute to the understanding of that thing in the world. »  NB. The latest version of the joint submission does not include this idea anymore. Eclipse Foundation, Inc. | © 2009 by the Open Wide and University of Augsburg. Made available under the EPL v1.0 15
• 16.
  AOM Beyond EMF:BPMN 2.0  In its current draft version, BPMN 2.0 will also provide the possibility to extend the metamodel with definitions from the outside  Only attributes though  Could be modeled by a dedicated Aspect Eclipse Foundation, Inc. | © 2009 by the Open Wide and University of Augsburg. Made available under the EPL v1.0 16
• 17.
  Conclusion  AO principles were applied on modeling through  AOM specific techniques in EMF  Supported by a generic AOM framework  Benefits of Aspects in our use case  Provide additional nodes that don„t exist in the original metamodel  Call vendor specific custom actions for specific model elements  Have additional properties on already existing metamodel elements  Next steps  Improve Conf model editor, wizards…  Making it fully independent of JWT Eclipse Foundation, Inc. | © 2009 by the Open Wide and University of Augsburg. Made available under the EPL v1.0 17
• 18.
  Thanks for yourattention ! Any questions??? Contact us at [email protected] or [email protected] JWT Conf Framework Documentation : http://wiki.eclipse.org/JWT_Metamodel_Extension & Have a look at the latest Eclipse Magazin ! We thank for his assistance:  Christian Saad – University of Augsburg, Committer on JWT Eclipse Foundation, Inc. | © 2009 by the Open Wide and University of Augsburg. Made available under the EPL v1.0 18