Difference between revisions of "JWT Metamodel"

From Eclipsepedia

Jump to: navigation, search
(Metamodel extensions and JWT WE (added 20080527))
(Technical specifications v1)
Line 46: Line 46:
  
 
== [[JWT Metamodel Extension Specifications/Technical Specifications v1|Technical specifications v1]] ==
 
== [[JWT Metamodel Extension Specifications/Technical Specifications v1|Technical specifications v1]] ==
 
Building on all that has been said, here is my proposition.
 
 
Its strong points are
 
* it unifies the simple, static EMF DynamicProperties and the powerful, EMF-extensible Aspects solutions
 
* once the model has been defined, functionnalities can be added step by step, meaning it will be usable from day 1, and we can add other features (like using visibleOnChildren to impact the outline and property page UI behaviour, or loading externally defined profiles in JWT, or code handling extension versioning check) later, when we are sure of them and when we have time. I'll outline this here by "LATER".
 
 
It relies on two concepts :
 
* aspect (or dynamicproperty) : a single typed extension of a model element
 
* profile (or DynamicPropertyContainer, or ModelExtension) : a model extension made of a consistent collection of aspects
 
 
It has been filed in bugzilla as bug 241567 "Typed metamodel extensions (Aspects)" (see https://bugs.eclipse.org/bugs/show_bug.cgi?id=241567 ).
 
 
 
=== Metamodel specification ===
 
 
ProfileDefModel metamodel
 
  * done in static EMF
 
  * contained in Model or / and independent XMI file, which could be the same as the new Views one
 
 
ProfileDefModel :
 
profiledefs : ProfileDef *
 
 
ProfileDef :
 
name
 
description
 
author
 
version
 
JWT version (modelversion ?)
 
aspectdefs : AspectDefs *
 
 
AspectDef :
 
id (jwt type) (string, reference ??)
 
etype (those extending Aspect are aspects, the others e.g. primitives or EObject are supported using Property) : EString
 
singleton : EBoolean
 
assignedto (? EClass but requires to refer to the ecore, or EString)
 
visibleAsChild : EBoolean
 
 
 
=== JWT metamodel ===
 
  * depends on the static ProfileDefs metamodel
 
 
Model
 
profiledefs : ProfileDefs
 
 
ModelElement :
 
aspects : Aspect *
 
 
Aspect :
 
id (jwt type)
 
 
Property extends Aspect :
 
value : EObject
 
 
 
=== Simple Property Example ===
 
 
Now an example of properties (csaad's) :
 
  * an instance of ProfileDef (name="Example1")
 
  * containing an AspectDef (name=id="internal_id1", etype="EString", assignedto="Action", singleton="true")
 
  * and another AspectDef (name=id="internal_id2", etype="EInteger", assignedto="ActivityNode", singleton="true")
 
 
Which automatically creates property instances under said model elements, for example :
 
  * an instance of JoinNode (name="node1") containing an instance of Property (name=id="internal_id2", value="intvalue1")
 
  * an instance of ActionNode (name="node1") containing an instance of Property (name=id="internal_id2", value="intvalue2") and another instance of Property (name=id="internal_id1", value="stringvalue1")
 
 
 
=== Extended Model Example ===
 
Now an example of an extended model :
 
  * an instance of ProfileDef (name="BonitaProfile")
 
  * containing an AspectDef (name=id="BonitaTaskAspectDef", etype="BonitaTaskAspect", assignedto="Action", singleton="false")
 
  * which makes BonitaTaskAspect available to be created under Action,
 
  * BonitaTaskAspect being defined as such :
 
 
BonitaTaskAspect :
 
bonitahooks : BonitaHook*
 
 
BonitaHook
 
event : EString (listbox)
 
javaClass : EString
 
jar : EString
 
 
 
=== Original DynamicProperty Metamodel ===
 
Note : csaad's was :
 
 
ModelElement :
 
properties *
 
 
DynamicPropertyContainer :
 
name
 
description
 
author
 
version
 
JWT version
 
dynamicproperties *
 
 
DynamicProperty :
 
id
 
type (of value ?)
 
assignedto
 
visibleOnChildren (?)
 
 
 
=== Features ===
 
Localization :
 
  * Names displayed in the UI (such as those of Property instances) have to be localized. It should be done in the Eclipse manner, using bundles, and if necessary a bit of our code. However I don't think we should put localized names in the model.
 
 
Managing the model :
 
  * Configuration : Which profiles among the ones loaded in JWT are activated in a given workflow model ?
 
      * all those explicitly defined in this workflow model,
 
      * LATER and all those in files configured in plugin.xml .
 
      * LATER buttons allowing to save a workflow containg all profile definitions (including JWT configured ones)
 
  * Versioning :
 
      * updating existing version check code so it works with the new model
 
      * updating existing version check code so it works with the extended EMF metamodels
 
      * LATER adding profile versioning check
 
 
UI
 
  * LATER Property / Outline : according to visibleAsChild, Aspect instances's content (including Property instances' content) will be either shown as a subelement of their assigned model element instance, or merged in the assigned model element instance's property page. Proposition : this property page's layout could separate each Aspect content by bars.
 
  * LATER in the outline, commands for creating "not singleton" aspects ; and forbidding deletion of "singleton ones".
 
  * LATER in the outline, finer extensibility of the "new Child" commands, including allowing to configure in plugin.xml commands that create a type with a given set of aspects.
 
  * LATER Diagram : nothing
 
 
Transformation
 
  * LATER define an extension point on transformation allowing to specify additional transformation rules for a given profile (not sure of this one, typed profiles sure are nice for this, but has to be tried first).
 
 
Packaging
 
  * LATER Using EMF.Edit, create a simple editor for the ProfileDefModel metamodel and make it available in the jwt packaging tool
 
 
Finding and loading extension
 
  * LATER static EMF extension models can be configured in plugin.xml to be loaded
 
  * LATER dynamic EMF extension ecores can be provided in given directory to be loaded
 
 
  
 
== [[JWT Metamodel Extension Specifications/Technical Specifications v2|Technical specifications v2]] ==
 
== [[JWT Metamodel Extension Specifications/Technical Specifications v2|Technical specifications v2]] ==
 
See bugzilla https://bugs.eclipse.org/bugs/show_bug.cgi?id=241567 .
 
See bugzilla https://bugs.eclipse.org/bugs/show_bug.cgi?id=241567 .

Revision as of 15:35, 5 January 2009

Contents

Introduction

This page describes the discussions and requirements for the meta-model of JWT. Based on the existing meta-model of AgilPro we will summarize all wishes, extensions etc. on this page.

An important part is JWT metamodel's extensibility.


Initial metamodel

This document File:AgilPro MetamodelDescription.pdf describes the metamodel of AgilPro as it is today (2007-02-21). This document will be the basis for discussions on all working groups who have requirements on the meta-model.

JWT metamodel comparisons

Comparison with other metamodels

A comparison with other meta-models as a result of an evaluation can be found in the following document: File:EvaluationExistingMetamodels.pdf.


Metamodel and XPDL 1.0

The document File:AgilPro Metamodel.pdf describes an initial revision of the document comparing the JWT/AgilPro metamodel with the XPDL 1.0 schema. It covers all the XPDL elements as well as the Bonita engine vendor specific extensions.

Metamodel and BPMN

Please find under File:Comparison JWT BPMN v0 3.pdf a document describing the differences between the JWT Metamodel on the one hand and BPMN on the other.


JWT Metamodel Extension Specifications


Extension Requirements and Use Cases

Specification Alternatives Study

Metamodel Extension Prototype - working samples (added 20080527)

Metamodel extensions and JWT WE (added 20080527)

Metamodel extensions and JWT Transformations

TODO

Metamodel extensions and JWT Runtimes

TODO


Technical specifications v1

Technical specifications v2

See bugzilla https://bugs.eclipse.org/bugs/show_bug.cgi?id=241567 .