Login | Register
My pages Projects Community openCollabNet

argouml
Wiki: Diff for "Repository Comparison With Model Interface"

Edit this page | Links to this page | Page information | Attachments | Refresh page

 

Differences between revisions 1 and 5 (spanning 5 versions)

Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
Create an operation inside an interface == Create an operation inside an interface ==

With Model Interface
Line 8: Line 10:
The big drawback is that when a new model implementation is introduced that will introduce new model element types and the MetaTypes interface will continually need to adapt to provide a new getSomething() operation.

With Repository API
Line 10: Line 15:
MetaType operationType = MetaTypes().getOperation(); MetaType operationType = repository.getMetaType("Operation");
Line 14: Line 19:
A MetaType is requested from the Repository by a string identifier. That MetaType has the functionality to create instances.
Line 15: Line 21:
Add an existing element to another - everything can be done with a far reduced API (one add method) and less verbose One criticism of this technique is compile time safety. To help with this it would be possible to create a utility class with all the model element types already defined. This would be external to the repository API though. The example below uses a utility class called Type that has all the element types predefined as constants.

{{{#!java numbering=off
Element myOperation = Type.OPERATION.createElement(myInterface);
}}}

In reality however there will be limited places where such code will exist (reverse engineering is the main candidate). For this utility methods can be created or a RepositoryFacade built.

Most places would more likely be data driven

{{{#!java numbering=off
Element myElement = myMetatype.createElement(container);
}}}

== Add an existing element to another ==

With Model Interface

Separate methods have been provided for each model element type. Once again this API will have to adapt when new model element are introduced.
Line 23: Line 47:
With Repository API
Line 29: Line 54:

== Recognising Element Type ==

With Model Interface

Separate methods have been provided for each model element type. Once again this API will have to adapt when new model element are introduced.

{{{#!java numbering=off
Model.getFacade().isANamespace(myElement);
Model.getFacade().isAFeature(myElement);
Model.getFacade().isAParameter(myElement);
}}}

With Repository API there is only one method to ever be aware of

{{{#!java numbering=off
myElement.instanceOf(Type.NAMESPACE);
myElement.instanceOf(Type.FEATURE));
myElement.instanceOf(Type.PARAMETER);
}}}

----
CategoryFurtherDevelopment

Create an operation inside an interface

With Model Interface

   1 Object operationType = Model.getMetaTypes().getOperation();
   2 Object myOperation = Model.getUmlFactory.buildNode(elementType, myInterface);

The big drawback is that when a new model implementation is introduced that will introduce new model element types and the ?MetaTypes interface will continually need to adapt to provide a new getSomething() operation.

With Repository API

   1 MetaType operationType = repository.getMetaType("Operation");
   2 Element myOperation = operationType.createElement(myInterface);

A ?MetaType is requested from the Repository by a string identifier. That ?MetaType has the functionality to create instances.

One criticism of this technique is compile time safety. To help with this it would be possible to create a utility class with all the model element types already defined. This would be external to the repository API though. The example below uses a utility class called Type that has all the element types predefined as constants.

   1 Element myOperation = Type.OPERATION.createElement(myInterface);

In reality however there will be limited places where such code will exist (reverse engineering is the main candidate). For this utility methods can be created or a ?RepositoryFacade built.

Most places would more likely be data driven

   1 Element myElement = myMetatype.createElement(container);

Add an existing element to another

With Model Interface

Separate methods have been provided for each model element type. Once again this API will have to adapt when new model element are introduced.

   1 Model.getCoreHelper().addOwnedElement(myNamespace, myInterface);
   2 Model.getCoreHelper().addFeature(myOperation, myInterface);
   3 Model.getCoreHelper().addParameter(myParameter, myOperation);

With Repository API

   1 myNamespace.add(myInterface);
   2 myInterface.add(myOperation);
   3 myOperation.add(myParameter);

Recognising Element Type

With Model Interface

Separate methods have been provided for each model element type. Once again this API will have to adapt when new model element are introduced.

   1 Model.getFacade().isANamespace(myElement);
   2 Model.getFacade().isAFeature(myElement);
   3 Model.getFacade().isAParameter(myElement);

With Repository API there is only one method to ever be aware of

   1 myElement.instanceOf(Type.NAMESPACE);
   2 myElement.instanceOf(Type.FEATURE));
   3 myElement.instanceOf(Type.PARAMETER);


CategoryFurtherDevelopment

Repository Comparison With Model Interface (last edited 2011-03-24 15:21:53 -0700 by ?bobtarling)