imported>Colin |
imported>Colin |
| Line 1: |
Line 1: |
| − | ==Some Notes on extensibility related to EMF framework.== | + | ''this page is under construction'' |
| | + | [[Image:IUMLB_big.png|frame|left]] |
| | + | {{TOCright}} |
| | + | ==Introduction== |
| | + | In iUML-B, Class diagrams are used to define and visualize entity-relationship data models. They can be added to Event-B Machines and Event-B Contexts and visualize given sets , constants and variables. Diagram elements elaborate pre-existing user data in order to visualize it. The diagram defines type, sub-type and further constraint information for the data by generating invariants or axioms. |
| | | | |
| − | ===Extensibility in the Rodin Database.=== | + | ==Principles of Operation== |
| − | The Rodin database can be extended with new element types by creating new Java classes that follow the pattern of the Event-B ones. This relies on the programmer creating the Java correctly.
| |
| − | The new elements are then 'registered' via an extension point so that the database knows about them.
| |
| − | Attributes can also be added via an extension point.
| |
| − | The database is minimally structured with all elements contained in a 'children' collection. Methods are then provided to simulate a structure by returning all child elements of a particular kind.
| |
| − | (note that this has the limitation that it is not possible to have two different collections which contain the same kind of element)
| |
| | | | |
| − | This approach has the advantage that it can be extended in any way (apart from the limitation noted above). However it is a very implementation-oriented view. That is, it would be nicer if extenders could work at a more model-oriented level and not have to understand (and get right) details about the coding of the database.
| + | Classes, Attributes and Associations are all model elements that represent data. They can be linked to existing Event-B data elements: Variables, Constants or (for Classes only) Carrier Sets. This relationship is called ''Elaborates'' because the diagram element elaborates properties of the data item. |
| | | | |
| − | EMF provides a more model oriented approach by allowing the extender to create a declarative abstract syntax (a meta-model) from which code is automatically generated. It is often necessary to 'tweak' the code with customisations but the situation is greatly improved.
| + | Any data element within scope, locally within the same machine or context, or via sees and extends, can be elaborated. As a short cut, a button is provided to create a new data item and link to it in one step. |
| | | | |
| − | ===Extensibility of the EMF framework for Event-B===
| + | Class diagrams can be added to Machines or Contexts, but note that some features are not available when in a Context (e.g. only constants and sets are within scope to link to and methods cannot be used in classes). |
| − | However, extensibility in EMF is currently being investigated.
| |
| | | | |
| − | It is possible to extend models by subclassing their elements and, for example, adding new attributes and collections to this subclass. However, this does not work retrospectively for previously created models. Also, extensions are effectively disjoint since an element cannot simultaneously be an instance of two or more subclasses.
| + | Methods can be placed inside Classes and link (elaborate) one or more events in the containing Machine. This means that the elaborated events are given a paramter representing the class instance (similar to 'this' or 'self' in programming languages). When in variable classes (i.e. a class that elaborates a variable) methods may be constructors or destructors. |
| | | | |
| − | When the Event-B EMF framework was created, we added a meta-class, 'Extension' and a collection, 'extensions' to the base element. The idea was that extenders could subclass this Extension class and thereby add new model features anywhere. This works, but is not very satisfactory for two reasons. Firstly it introduces an unnatural intermediate modelling artefact because the Extension element should really be the same element as its parent. Secondly, once an extension is defined there is no way of limiting who can own it. This means that the extension can be added to every kind of element in the rest of the model including all the new elements in the extension.
| + | ==Main Data Elements of a Class Diagram== |
| | + | The main data elements of a class diagram are ''class'', ''association'' and ''attribute''. These elements all visualize an Event-B data item (set constant or variable) in the Event-B model. Only a class can visualize a set. The class diagram also visualizes the type and subtype of the data item as follows. |
| | + | ===Class=== |
| | + | A Class visualizes a data item that is a set or subset. |
| | + | a) If the class diagram is in a Context and the class has no generalization relationships, and its |
| | + | ===Association=== |
| | + | ===Atttribute=== |
| | | | |
| − | Another approach is now under investigation.
| + | ==Elaboration and Generation== |
| − | This is to define the new meta-model including all new element kinds but omitting the containment that attaches it to the existing meta-model. This containment is then defined in an extension point, giving the allowed type of the owner and some EMF details about the properties of the EReference (multiplicity etc.). The core model package will then (via some additional custom code) read all extensions of this extension point and, if any have parent elements in the core package, dynamically extend the core package with a containment to attach the extension meta-model. All Extension plug-ins should also look for relevant extensions of themselves in a similar way.
| + | tbd |
| | | | |
| − | ===Extending Presentation=== | + | ==Scope== |
| − | The Rodin platform already provides an extension point for defining presentation of model elements and attributes. This extension point however, links information to Rodin elements. We require the same information linked to EMF model elements. Of course, EMF elements are synchronised with rodin elements, but this is only updated at save time. Several options exist:
| + | Elements of the class diagram can define data in the containing Event-B component and can visualize data in any Event-B component that is visible to the containing Event-B component (including itself). Hence a class diagram in a context may define/visualize sets and constants in the containing context and visualize sets and constants in any context which is extended (closure) by the containing context. A class diagram in a machine may define/visualize variables in the containing machine, visualize variables in any machine it refines (closure) and visualize sets and constants in any context that is seen by the machine or any Context that is extended by a context that is seen by the machine. |
| | | | |
| − | * Replicate the current extension point but linking to EMF models.
| + | ==Secondary information== |
| − | * Use the existing Rodin extension point mapping to the EMF element via its dynamic synchronisation with rodin elements. It would be necessary to tighten the synchronisation between EMF and Rodin elements so that they are kept in step at all times (see discussion below).
| + | Colour is used to indicate whether a diagram element has been linked to data. Icons are used to indicate the kind (set, constant or variable) of elaborated data. |
| − | * Use the existing Rodin extension point mapping to the EMF element via a static type mapping with rodin elements.
| |
| − | * Modify the existing Rodin extension to optionally specify an EMF element type in addition to the Rodin element type.
| |
| | | | |
| − | Question: does the existing Rodin extension point handle multiple collections of the same element type?
| + | ==Example== |
| | + | For example when a class diagram is first drawn and has not been linked to data it looks like this: |
| | | | |
| − | ===Tighter Synchronisation===
| + | [[File:Cd1_unlinked.png]] |
| − | TBD
| |
| | | | |
| − | ===Instructions for creating an extension===
| + | Generating this diagram produces no output to the Event-B. |
| | + | The diagram elements must first be linked to data using the '''Link Data''' or '''Create & Link''' buttons in the properties sheet. |
| | + | The followng screenshot shows the association being linked to a variable ''b'' that already exists in the machine. |
| | | | |
| − | * Design an EMF meta model (ecore) of your extension's abstract syntax. The model should NOT deal with ownership of the extension (i.e. where the extension is contained in the existing meta-models)
| + | [[File:LinkData.png|800px]] |
| − | * Load and configure the gen model (this should be set for extensible providers) <still under investigation since extending provider would be the container which is defined dynamically now>
| |
| − | * Generate the code and edit code
| |
| − | * Customise the package initialiser with the code shown below to make your package extensible
| |
| − | * Add an extension to define the containment of the extension (the containment will be added dynamically to the meta-model being extended)
| |
| − | * Add extensions to declare new kinds of Rodin elements and attributes
| |
| − | * Write Java interfaces and classes for each new Rodin element
| |
| − | * Add extensions to declare synchronisers to persist your new meta-classes into Rodin elements.
| |
| − | * Write Java classes for each synchroniser
| |
| | | | |
| | + | The following screenshot shows the class A being used to create and link to a carrier set in the seen context X0. Note that the carrier set is created in X0 immediately. It is not necessary to generate. |
| | | | |
| | + | [[File:CreatLink.png|800px]] |
| | | | |
| − | ====example code to make a package extensible==== | + | ==Class Diagrams in Contexts== |
| − | (the example is for the core package... core package should be changed to the name of your package)
| + | subtype |
| | | | |
| − | public static CorePackage init() {
| + | ==Class Diagrams in Machines== |
| − | ........
| |
| − | //Link in any extensions
| |
| − | getExtensions(theCorePackage,theMachinePackage,theContextPackage);
| |
| − |
| |
| − | // Mark meta-data to indicate it can't be changed
| |
| − | theCorePackage.freeze();
| |
| − |
| |
| − | return theCorePackage;
| |
| − | }
| |
| − |
| |
| − | /**
| |
| − | * Method to get all extensions from extension registry.
| |
| − | * Extensions can link additional EMF model content to this core model by defining a new EReference
| |
| − | * (usually a containment) which holds instances of a new metaclass.
| |
| − | *
| |
| − | * @custom
| |
| − | */
| |
| − | private static final String extensionId = "org.eventb.emf.core.metamodel_extension";
| |
| − |
| |
| − | private static void getExtensions(EPackage theCorePackage,EPackage theMachinePackage,EPackage theContextPackage) {
| |
| − | IExtensionRegistry extensionRegistry = Platform.getExtensionRegistry();
| |
| − | IExtensionPoint extensionPoint = extensionRegistry.getExtensionPoint(extensionId);
| |
| − | org.eclipse.core.runtime.IExtension[] extensions = extensionPoint.getExtensions();
| |
| − |
| |
| − | for (org.eclipse.core.runtime.IExtension extension : extensions) {
| |
| − | try {
| |
| − | EPackage extenderPackage = null;
| |
| − | IConfigurationElement [] elements = extension.getConfigurationElements();
| |
| − | for (IConfigurationElement element : elements) {
| |
| − | if ("ePackage".equals(element.getName())){
| |
| − | //String packageName = element.getAttribute("name");
| |
| − | Registry packageRegistry = EPackage.Registry.INSTANCE;
| |
| − | String extender_eNS_URI = element.getAttribute("eNS_URI");
| |
| − | extenderPackage = packageRegistry.getEPackage(extender_eNS_URI);
| |
| − | }
| |
| − | }
| |
| − | if (extenderPackage==null){
| |
| − | EventbcoreEditPlugin.INSTANCE.logError(null, "extending ePackage not found during Event-B EMF metamodel extension");
| |
| − | }else{
| |
| − | for (IConfigurationElement element : elements) {
| |
| − | if ("eReference".equals(element.getName())){
| |
| − | String eReferenceName = element.getAttribute("name");
| |
| − | String parentName = element.getAttribute("parent");
| |
| − | boolean containment = Boolean.parseBoolean(element.getAttribute("containment"));
| |
| − | String eTypeName = element.getAttribute("eType");
| |
| − | String required = element.getAttribute("required");
| |
| − | String singular = element.getAttribute("singular");
| |
| − | Object parent=null;
| |
| − | if ((parent = theCorePackage.getEClassifier(parentName)) == null)
| |
| − | if ((parent = theContextPackage.getEClassifier(parentName))==null)
| |
| − | if ((parent = theMachinePackage.getEClassifier(parentName))==null);
| |
| − |
| |
| − | if (parent instanceof EClass){
| |
| − | EClass eType = (EClass)extenderPackage.getEClassifier(eTypeName);
| |
| − | EReference eReference = EcoreFactory.eINSTANCE.createEReference();
| |
| − | eReference.setName(eReferenceName);
| |
| − | eReference.setEType(eType);
| |
| − | eReference.setContainment(containment);
| |
| − | eReference.setUpperBound(ETypedElement.UNBOUNDED_MULTIPLICITY); //change to set from required and singular
| |
| − | ((EClass)parent).getEStructuralFeatures().add(eReference);
| |
| − | }
| |
| − | }
| |
| − | }
| |
| − | }
| |
| − | }
| |
| − | catch (Exception e) {
| |
| − | EventbcoreEditPlugin.INSTANCE.logError(e, "failed getting Event-B EMF extensions");
| |
| − | }
| |
| − | }
| |
| − | }
| |
| − |
| |
| − | | |
| − | '''example metamodel-extension (containment definition)'''
| |
| − | <extension
| |
| − | point="org.eventb.emf.core.metamodel_extension">
| |
| − | <ePackage
| |
| − | eNS_URI="http://emf.eventb.org/models/records"
| |
| − | name="RecordsPackage">
| |
| − | </ePackage>
| |
| − | <eReference
| |
| − | containment="true"
| |
| − | eType="AbstractRecord"
| |
| − | name="records"
| |
| − | parent="Context"
| |
| − | required="false"
| |
| − | singular="false">
| |
| − | </eReference>
| |
| − | </extension>
| |
this page is under construction
Introduction
In iUML-B, Class diagrams are used to define and visualize entity-relationship data models. They can be added to Event-B Machines and Event-B Contexts and visualize given sets , constants and variables. Diagram elements elaborate pre-existing user data in order to visualize it. The diagram defines type, sub-type and further constraint information for the data by generating invariants or axioms.
Principles of Operation
Classes, Attributes and Associations are all model elements that represent data. They can be linked to existing Event-B data elements: Variables, Constants or (for Classes only) Carrier Sets. This relationship is called Elaborates because the diagram element elaborates properties of the data item.
Any data element within scope, locally within the same machine or context, or via sees and extends, can be elaborated. As a short cut, a button is provided to create a new data item and link to it in one step.
Class diagrams can be added to Machines or Contexts, but note that some features are not available when in a Context (e.g. only constants and sets are within scope to link to and methods cannot be used in classes).
Methods can be placed inside Classes and link (elaborate) one or more events in the containing Machine. This means that the elaborated events are given a paramter representing the class instance (similar to 'this' or 'self' in programming languages). When in variable classes (i.e. a class that elaborates a variable) methods may be constructors or destructors.
Main Data Elements of a Class Diagram
The main data elements of a class diagram are class, association and attribute. These elements all visualize an Event-B data item (set constant or variable) in the Event-B model. Only a class can visualize a set. The class diagram also visualizes the type and subtype of the data item as follows.
Class
A Class visualizes a data item that is a set or subset.
a) If the class diagram is in a Context and the class has no generalization relationships, and its
Association
Atttribute
Elaboration and Generation
tbd
Scope
Elements of the class diagram can define data in the containing Event-B component and can visualize data in any Event-B component that is visible to the containing Event-B component (including itself). Hence a class diagram in a context may define/visualize sets and constants in the containing context and visualize sets and constants in any context which is extended (closure) by the containing context. A class diagram in a machine may define/visualize variables in the containing machine, visualize variables in any machine it refines (closure) and visualize sets and constants in any context that is seen by the machine or any Context that is extended by a context that is seen by the machine.
Secondary information
Colour is used to indicate whether a diagram element has been linked to data. Icons are used to indicate the kind (set, constant or variable) of elaborated data.
Example
For example when a class diagram is first drawn and has not been linked to data it looks like this:
Generating this diagram produces no output to the Event-B.
The diagram elements must first be linked to data using the Link Data or Create & Link buttons in the properties sheet.
The followng screenshot shows the association being linked to a variable b that already exists in the machine.
The following screenshot shows the class A being used to create and link to a carrier set in the seen context X0. Note that the carrier set is created in X0 immediately. It is not necessary to generate.
Class Diagrams in Contexts
subtype
Class Diagrams in Machines
