Docstoc

userGuide

Document Sample
userGuide Powered By Docstoc
					                                     MDA-Transf
                                     User Guide
                                Author : Cedric Dumoulin
                                  Date : 22 Apr. 2004
                                  Rev : 21 Nov. 2011

                              "A MDA Transformation Tool"

                                       Draft version


1 Features
      Type of input or output models: JMI models, XML, graph of objects
   

1.1 Xml Rules Features
      Declarative syntax
          o A rule specifies the source and target concepts, and how to populate the target
               from the source.
          o The engine search for the appropriate rule to translate a concept.
      Imperative syntax
          o Actions can call a rule directly
          o Local variables can be created
      Inheritance
          o A rule can inherit from another rule. All guards and actions are inherited. An
               action or a guard can be overloaded in a sub-rule.
          o This feature is supported by the syntax, but it is not yet implemented
      Multi input model and multi output model
          o The xml rules accept multi models in output, and can handle multi models in
               output.
      Customizable
          o Rules, Guard and Actions can be customized separately

2 MDA-Transf Principles
2.1 Basic Principle
The Transformation engine takes one or more models and a one or more set of rules as input,
and it produces one or more model as output.
                                              rules
                                             rules


  model
  model                                transformation                             model
                                                                                  model
                                           engine


The engine is started by passing it one or more objects to transform (models or model
elements) called source elements. The engine looks for the appropriate rule matching the
source elements, and applies the rule. The rule creates target elements, and fills them with the
source elements properties. The rule can call the engine with nested elements, allowing the
call of rules defined for other elements.

To perform a transformation, you need to do the following:
     Load or create the left and right models.
            o Source model are generally loaded, while destination model are created.
     Associate each model to its "model Context"
            o The model context is used to provide a well defined access to the model.
     Create a transformation engine instance.
     Create an engine context, associate it to the engine
     Add each model context to the engine context
     Load Rule Sets into the engine
     Call the transform() method on the engine with the elements (model, elements, …) to
        transform as parameters

3 Quick Start
The      classes      Transformation     (in     ispuml.example.mdaTransformation.
transformation) allows you to quickly develop and test your own transformation rules.
The class SimpleGenerator (in ispuml ispuml.example.mdaTransformation.
transformation) allows you to quickly develop and test your own code generation rules.

To perform a transformation, you need:
    An input model to transform
    The metamodel for the input model
          o Used to generate the JMI classes
    The metamodel for the output model
          o Used to generate the JMI classes
    A file containing your rules
    The transformation engine distribution

To perform a code generation, you need:
    An input model to generate code from
    The metamodel for the input model
          o Used to generate the JMI classes
    A file containing your code generation rules
    Some templates for the generation
       The transformation engine distribution



3.1 Prerequisites
       The transformation tool distribution (mdaTransf.jar).
       Ant (from jakarta.apache.org/ant) should be in your path.
       JDK1.4
           o JDK1.3 should also run, but you need to have an xml parser (like xerces.jar) in
                your                                                             classpath.
                You can put the parser jar under the jre/lib/ext directory; or you can
                uncomment the parser.jar declaration in the build.properties file.

3.2 Quick Setup
The quicker way to play with Transformation rules or Code Generation is to start from the
blank project named uml2java. Copy it and rename it to your owned project name.

       Make a copy of the uml2java project and rename it to your project name
       Check your installation:
            o go in the project directory
            o type ant clean
            o type ant uml2mof
                    This create the mof metamodel from its uml representation.
            o type ant uml2java
                    This transforms a uml model to a java model
            o type ant java2code
                    This generates code from the java model
            o If an exception is thrown, your installation has a problem. Correct it first
               before continuing.
       You can now customized your project:
       put your input model and its metamodel under model/
       put your output metamodel under model/
       Open metamodel-config.xml
            o Add an entry for each of your metamodel.
            o If you want to use MDR, the entry looks like this (See Metamodel Config File
               for more):
           <metamodel publicId="java"
            classname="ispuml.mdaTransformation.model.factory.MDRMetaModelHelper"
            xmiFile="model/simpleJavaMM-mof.xmi"
            mainExtent="Java2"
            engineAdaptor="ispuml.mdaTransformation.model.jmi.JmiModelContext"
           />
                      publicId: A name identifying the metamodel in the metamodel factory
                      classname: The classname of the metamodel helper used to load, save
                       and create a metamodel. In the example we use an MDR helper. You
                       can use it if you want to use MDR.
                      xmiFile: The name of the xmi file containing your metamodel
                      mainExtent: the name of the root package extent in your metamodel
                      engineAdaptor: The engine adaptor used to access the model. You can
                       use the same as in the example.
       Open build.xml
           o Locate the targets uml2java and java2code. Rename them if you wish.
                  These targets are used to start a transformation and a code generation
           o Following is a copy of the uml2java target
    <target name="uml2java" depends="compile.examples"
            description="Run Transformation uml to java (using mdr)">
        <java
classname="ispuml.example.mdaTransformation.simpleTransformation.Transforma
tion" fork="yes">
            <classpath path="."/>
            <classpath refid="run.example.classpath"/>
            <arg line="-mmFile metamodel-config.xml"/>
            <arg line="-src model/example2-uml14.xmi uml uml14"/>
            <arg line="-dst model/example-java.xmi java java"/>
            <arg line="-r /rules/uml2javaRules.xml"/>
        </java>
    </target>
      Change the arguments <arg …/> according to your needs:
          o Change the metamodel config file:
                      -mmFile filename
                   
                   filename: Specify the file containing the metamodel descriptions. Used
                   by the metamodel factory.
           o Change the -src and -dst command line according to your settings. You can
             have more than one –src and –dst.
                      -src|-dst modelFilename metamodelRuleUri metamodelUri
                    modelFilename: The name of the file containing the model
                    metamodelRuleUri: The name of the metamodel in the rule files
                     (value of attribute model=”…” in xxxRule.xml)
                  metamodelUri: The name of the metamodel in the metamodel factory
                     (value of attribute publicid=”…” in metamodel-config.xml)
           o Set the rule file name(s):
                      -r ruleFilename
                     The file name is absolute or relative to where the jvm is started. You
                      can specify several filenames (add –r for each filename).
      Write your rule files
           o You can start from the blank-transformationRules.xml or blank-
               generationRules.xml files.
           o See next paragraphs for details
      If you have custom rules, actions or conditions,
           o Write them
           o put them under src/example, with any extra package directories.
      run ant target-name.
           o This should compile your custom classes, and start the transformation or code
               generation.


3.3 Required Libraries
To run the transformation engine, the following librairies (.jar) are required:
    mda-transf.jar (the transformation engine !)
    commons-beanutils.jar
    commons-collections.jar
    commons-digester.jar (to parse XML rules)
    commons-logging.jar (for logging)
          velocity.jar (template engine for code generation)
          standard.jar (expression evaluation library)
          An XML parser like xerces.jar

The following can be useful if you use NSUML:
    nsmdf.jar (JMI implementation by novosoft)
    nsmdf_gen.jar (novosoft JMI generator)

If you use MDR, you will need the MDR jars.



4 V1 To V2 Transition Roadmap

4.1 Public ID
Change the Public Id declaring the DTD:
<!DOCTYPE ruleSets PUBLIC "-//MDA Transformation XML Rules 2.0//EN"
              "http://www.lifl.fr/~dumoulin/mdaTransf/resources/mdatransf-rules_2_0.dtd">


4.2 Parameters Declarations
The parameter names are now declared as attributes of the rule.
You should remove the old tags if any and replace them by attributes in the rule.
<rule ruleName=”aRule” >
       <leftParams names=”arg1, arg2”/>
       <rightParams names=”res1,res2” />
…
becomes
<rule ruleName=”aRule” leftParams=”arg1, arg2” rightParams=”res1,res2” />
…




4.3 Change the Main class for Transformation in build.xml:
            replace
 <java              classname="ispuml.example.mdaTransformation.simpleTransformation.Transformation"
fork="yes">
            with
<java classname="ispuml.example.mdaTransformation.transformation.Transformation" fork="yes">




5 XML Rules Syntax
5.1 Rule description
A rule is made of guards and actions. Guards are used to select the rule, and actions are
executed if the rule is selected.
A rule owned a context into which attributes can be stored. These attributes are visible to the
owning rule and to rules called from this rule. The attributes aren't visible to rules calling the
owning rule. To pass objects from a called rule to its calling rule, one can use the return
values, or the engine context.
An "XML" rule defined some conditions (left and right) and some actions. The conditions are
translated to guards or actions according to the direction of the transformation. If the
transformation is made from left to right, left conditions are called sources, and right
conditions destinations. If the transformation is made in the reverse order, right conditions
become sources, and left conditions become destinations. The sources conditions are
interpreted as guards, and the destination conditions as actions.
(figure: examples ruleSet/rule/leftCond/rightCond/actions/action)

5.2 RulesSet
A Rules Set is used as a container for rules. Several rules sets can be registered to a
Transformation engine. One of them should be declared as the "default" rules set.
The choice of the rule set to use can be done when calling the engine. If no rule set is
specified, the rule set of the current rule is used. If there is no current rule, the default rule set
is used.

5.3 Walk Across the Model
To transform a model you need to walk across it. One of the rules is responsible of that. The
rule catches the model, and proposes some actions to walk across it.
Following is the rule starting the transformation:
  <rule ruleName="modelRoots">
        <description> Walk the model roots</description>
        <leftConditions>
            <model uri="uml"/>
        </leftConditions>
        <actions>
            <log msg=" **** walk roots action"/>
            <transform actionName="transformRoots" >
              <left>
                 <expr expr="uml.allRoots()"/>
              </left>
            </transform>
        </actions>
    </rule>


The condition <model uri=”uml”/> catch the model of the specified name. So, the rule is
executed. The <transform …> action indicates to transform all the roots of the model. It is
possible to specify only a particular type or kind:
            <transform actionName="transformRoots" >
              <left>
                 <expr expr="uml.allOfType( uml.Model_Management.Package )"/>
                 <expr expr="uml.allOfKind( uml.core.Class )"/>
              </left>
            </transform>


5.4 Transforming a model
To be written.

5.4.1 The starting Rule
To transform a model, you submit it to the engine. Then, the engine searches for a rule to
transform the model. This rule contains a guard on the model, and one or more actions
selecting model elements to be transformed.
5.5 XML Rule Generalities
An XML Rule has the following functionalities:
    It contains conditions and actions (create-actions, pre-actions, actions and post-
     actions)
    It has a context used to store variables
    The context, and thus the variables, are accessible by the conditions and the actions
    A rule can have more than one concept has input, and can return more than one
     concept as return. This is done by declaring explicitly the parameter names to the
     rules.
         o The input parameters are then available through the rule context, like the rule
             other variables.
         o The names of the return parameters are used by the rule to retrieve the return
             values from the context. The rule should put these values in the context under
             the specified names.
    By default, no parameters names need to be specified. In this case, the rule is supposed
     to have one input parameter named “src” and one output parameter named “dst”.
    XML Rule conditions are processed as guards and as create actions if explicitly
     specified .
         o Guards are evaluated in order.
                  The rule is selected if all guards are true.
                  The evaluation process stop (and return false) as soon as a guard return
                     false.
    Create action are processed in order.
         o A create actions tag (<leftCreates> or <rightCreates>) can specified that it
             extends a conditions tag. In this case the conditions are also used as create
             actions.
         o The value of the last create action is returned and stored in the context under
             the name of the first output parameter, if this later is not already set.

5.6 Customizing Rules
Xml Rules can be customized. This is done by developing a Java class implementing the
desired behavior, and specifying that you want to use this class rather than the default
implementation.
The customized rule can be implemented in several ways: by implementing the top level Rule
interface, or by extending one of the existing implementations.

5.6.1 Specifying the Customized Rule
You specify that you want to use a customized rule by using the classname="your.class"
attribute of the <rule …> element:
<rule ruleName="aName" classname="myRuleClass" />


It is possible to set some properties of the Class by using the setProperty tag:
<rule ruleName="aName" classname="myRuleClass" >
  <setProperty name="propertyName" value="aValue" />
</rule>
The properties of the class should follow the JavaBean conventions: have a setter named void
setXxx( value : Type ); where Xxx is the name of the property, and Type is a type
compatible with the provided value. The setProperty tag take care of basic conversion from
String to int, double, boolean, ….
5.6.2 Implementing the Customized Rule
         The customized rule can be realized by implementing the Rule interface, or extending
          one of the default implementation.

5.7 Customizing Conditions
Xml conditions can be customized. This is done in the same way as customizing Rule: by
developing a Java class implementing the desired behavior, and specifying that you want to
use this class rather than the default implementation.
The customized condition can be implemented in several ways: by implementing the top level
Condition interface, or by extending one of the existing implementations.
Different existing condition tag can be customized:
     <concept …>
     <customCondition …>

Using an existing tag and extending the appropriate class allow you to use the associated
nested tags.

5.7.1 Specifying the Customized Condition
You       specify   that want to use a customized condition by using the
                           you
classname="your.class" attribute of one of the customizable condition tags
(<customCondition …> element:
<concept … classname="myConditionClass" />
<customCondition … classname="myConditionClass" />


It is possible to set some properties of the Class by using the setProperty tag:
<customCondition … classname="myConditionClass" >
  <setProperty name="propertyName" value="aValue" />
</customCondition>
The properties of the class should follow the JavaBean conventions: have a setter named void
setXxx( value : Type ); where Xxx is the name of the property, and Type is a type
compatible with the provided value. The setProperty tag take care of basic conversion from
String to int, double, boolean, ….

5.7.2 Implementing the Customized Condition
          The customized condition can be realized by implementing the Condition interface, or
           extending one of the default implementation.

5.8 Customizing Actions
Xml actions can be customized. This is done in the same way as customizing Rule: by
developing a Java class implementing the desired behavior, and specifying that you want to
use this class rather than the default implementation.
The customized action can be implemented in several ways: by implementing the top level
Action interface, or by extending one of the existing implementations.
Different existing action tag can be customized:
     <transform …>
     <customAction …>

Using an existing tag and extending the appropriate class allow you to use the associated
nested tags.
5.8.1 Specifying a Customized Action
You specify that you want to use a customized action by using the classname="your.class"
attribute of one of the customizable action tags (<action …>:
<transform … classname="MyActionClass" />
  or
<customAction … classname="MyActionClass" />


It is possible to set some properties of the Class by using the setProperty tag:
<customAction … classname="MyActionClass" >
  <setProperty name="propertyName" value="aValue" />
</customAction>
The properties of the class should follow the JavaBean conventions: have a setter named void
setXxx( value : Type ); where Xxx is the name of the property, and Type is a type
compatible with the provided value. The setProperty tag take care of basic conversion from
String to int, double, boolean, …

5.8.2 Implementing the Customized Action
      The customized action can be realized by implementing the Action interface, or
       extending one of the default implementation.


5.9 Generating Code
Code generation is done by rules catching model concepts and generating the corresponding
code from a specified template. A template can be specified inline in the body of the generate
action or in a separate file. Templates are implemented by Velocity templates
(jakarta.apache.org/velocity).

Following is an example of rule with an inline template:

  <rule ruleName="class" name="class">
    <description> Transform a class to a class</description>
    <leftConditions>
      <concept type="Core.Class" model="uml" use="required"/>
    </leftConditions>
    <actions>
      <filewriter name="writer" filename="${src.name}" fileExtension=".java"
                  path="${packages}" />
      <generate writer="writer" >
        public class ${src.name}
        {
            // attributes
        ${engine.callRule( "src.feature[*]", "attribute" )}
            // Nested element
        ${engine.generate( "src.ownedElement[*]" )
        }
      </generate>
      <closeFilewriter name="writer" />
    </actions>
  </rule>



The rule catches the "class" concept.
The action <filewriter …> specify a file writer backup by the specified filename under the
specified path. The 'filename' and 'path' attribute can take expressions that are evaluated when
the action is called (see ${src.name} which refer to the attribute 'name' of the bean named
'src'. The engine saves the bean denoted by the source condition under the name 'src', so
${src.name} refer to the property 'name' of the 'class'.) . The action saves the filewriter
specification under the name 'writer". The filewriter is not opened immediately; it will be
opened later, when needed.

The action <generate …> declare and call the template. The action uses the specified writer,
and opens it if needed. In the previous example the template is declared in the action body.
You can specify a template filename instead by setting the attribute
template="aTemplate.vm".

      <generate writer="writer" template="templates/interface.vm" />


The action <closeWriter   writer="aWriterName"/>   close the specified writer if it has been opened.


5.9.1 Templates Syntax
The templates syntax follows the velocity templates syntax. The template content is
considered as text, except the references which are replaced by their values. References are of
the form ${propertyName} or $propertyName. The propertyName can be a "." separated
path to the property like in ${src. name}.
The velocity syntax allows to call methods on the references: ${bean.method( arg1, arg2
)}. The transformation engine provides a bean named 'engine' with methods to call
recursively the engine. Following are some example of engine calls:
     ${engine.generate( "src.feature[*]" ) }:
            o Try to call the rule for the "src.feature[*]" property
     ${engine.generate( ["src.feature, src.ownedElement"] ) }:
            o Try to call the rule for the "src.feature[*]" and src.ownedElement properties.
               The […] parentheses are used to specify a collection of arguments.
     ${engine.generate( "src.feature[*]", "ruleSetName" ) }:
            o Lookup for an appropriate rule in the specified ruleset.
     ${engine.callRule( "src.feature[*]", "attribute" ) }:
            o Call the rule "attribute" with the "src.feature[*]" property.
     ${engine.callRule( "src.feature[*]", "attribute", "ruleSetName" ) }.
            o Call the rule "attribute" in the specified ruleset with the "src.feature[*]"
               property.


5.9.2 Example
/**
 * Class ${src.name}
 */
public class ${src.name}
{
    // attributes
  ${engine.callRule( "src.feature[*]", "attribute" )}
    // Nested element
  ${engine.generate( "src.ownedElement[*]" )}
}




5.9.3 References available to a template:
The references available to a template are the attributes of the rule context and the "engine"
reference. Note that the engine stores the conditions related concept under the attribute "src"
and "dst" when no other name is specified. So, it is possible to access the source concept and
properties through "src.propertyName"

6 Debugging Rules
Some information about how rules are executed can be shown. This is useful during rules
development to do some debugging.
The Transformation engine uses the Jakarta commons-logging package to enable or disable
the information shown. For more information on how to use this package, please refer to the
commons-logging documentation. Here we will describe a simple way to show the debug
information. More sophisticated viewers can be used (log4j, java logging, …).
The following loggings are available:
      ispuml.mdaTransformation.RuleLog
          o This log shows the rule logs. It     is useful for the rules developers during rule
              development.
      ispuml.mdaTransformation.EngineLog
          o This log shows the engine logs. It is    useful to debug the engine. It is reserved
              for the engine developers. Don't use it if you just want to debug rules.

A simple way to enable the logging is to use the SimpleLog. You need to files:
      commons-logging.properties
           o This file specify the logging system to use
      simplelog.properties
           o This file specify the log systems

The file commons-logging.properties contains:
org.apache.commons.logging.Log=org.apache.commons.logging.impl.SimpleLog


The file simplelog.properties contains:
# Logging detail level,
# Must be one of ("trace", "debug", "info", "warn", "error", or "fatal").
org.apache.commons.logging.simplelog.defaultlog=error

# Logging detail level for a SimpleLog instance named "xxxxx".
# Must be one of ("trace", "debug", "info", "warn", "error", or "fatal").
# If not specified, the default logging detail level is used
# org.apache.commons.logging.simplelog.log.xxxxx
org.apache.commons.logging.simplelog.log.ispuml.mdaTransformation.RuleLog=trace
org.apache.commons.logging.simplelog.log.ispuml.mdaTransformation.EngineLog=fatal

#org.apache.commons.logging.simplelog.showlogname=true
#org.apache.commons.logging.simplelog.showShortLogname
#org.apache.commons.logging.simplelog.showdatetime=true


You can change the detail level according to your needs.
Some tips:
    level "warn"
           o Show warning about missing rule for a given concept
    level "info"
           o Show calls to the transform() method

7 Metamodel Factory
The Metamodel Factory is used by programs like Transformation or SimpleGeneration to load
the metamodels. These metamodels are described in a separate configuration files, which can
be reused across different projects.
The configuration file specifies the metamodel unique name, used by programs, and the
metamodel specification needed to load this metamodel. The metamodel data found in the
specification depend on the metamodel utility used (MDR, EMF, NsUML, XML, …). Each
metamodel utility has its own “metamodel helper” used to load and save the metamodel. An
implementation is provided for the most common utility, but it is possible to write its own
implementation by implementing the ispuml.mdaTransformation.model.factory.
MetaModelHelper or extending the ispuml.mdaTransformation.model.factory.
MetaModelHelperBase.
Once this is done, you can add your metamodel in the metamodel configuration file.

7.1 Metamodel Configuration File
Following is an example of a metamodel configuration file. There is an XML node
<metamodel publicId=”aName” > for each metamodel. The attribute publicId is used to
identify the metamodel in the factory. The classname attribute specify the name of the class
implementing the MetaModelHelper. The others attributes meaning depend on the helper.
<!DOCTYPE metamodels PUBLIC "-//MDATransf Meta Model config 1.0//EN"
            "http://www.lifl.fr/~dumoulin/mdaTransf/resources/metamodelConfig_1_0.dtd">
<metamodels>

   <metamodel publicId="uml14"
           classname="ispuml.mdaTransformation.model.factory.MDRMetaModelHelper"
           xmiFile="model/uml14-01-02-15_Diff.xml"
           mainExtent="UML"/>
           engineAdaptor="ispuml.mdaTransformation.model.jmi.JmiUML14ModelContext"

   <metamodel publicId="mof14"
           classname="ispuml.mdaTransformation.model.factory.MDRMetaModelHelper"
           xmiFile="model/mof14.xml"
           mainExtent="Model"
           engineAdaptor="ispuml.mdaTransformation.model.jmi.JmiModelContext"
          />

   <metamodel publicId="isp-nsuml"
            classname="ispuml.mdaTransformation.model.factory.NsUmlMetaModelHelper"
            engineAdaptor="ispuml.mdaTransformation.model.jmi.JmiModelContext"
            outermostExtentImpl="ispuml.model.impl.IspUMLPackageImpl"
           />
</metamodels>



MDR Attributes:
   xmiFile: The name of the file containing the MOF description of the metamodel.
   mainExtent: The name of the main package of the metamodel.
   engineAdaptor: The name of the Java class used as adaptor between the engine and the
     models.
     For JMI models, use ispuml.mdaTransformation.model.jmi.JmiModelContext.

NsUML Attributes:
    outermostExtentImpl: The name of the JMI implementation class representing the
     main package of the metamodel.
    engineAdaptor: The name of the Java class used as adaptor between the engine and the
     models.
     For JMI models, use ispuml.mdaTransformation.model.jmi.JmiModelContext.
7.1.1 Writing Metamodel Helper
You      can        write     your     metamodel     helper    by      implementing     the
ispuml.mdaTransformation.model.factory.MetaModelHelper                or   extending    the
ispuml.mdaTransformation.model.factory.MetaModelHelperBase.
The MetaModelHelper class provides methods for the metamodel life cycle (load, save, …),
and common getter / setter used to set the attributes from the configuration file. The next
table gives the getter/setter property name and the corresponding attribute name in the
configuration file:
            Property name                     XML attribute
     "mmURI",                               "publicId",
     "mmFilename",                          "xmiFile",
     "metaModelMainExtentName",             "mainExtent",
     "mmAdaptorClassname",                  "engineAdaptor",
     "mmOutermostExtentClassname",          "outermostExtentImpl",

Your custom implementation can use this attributes and gives them another meaning.
You can also add new attributes. For that, you need to declare the corresponding getter and
setter in your class, following the JavaBeans conventions (public AType
getAttributeName(); public setAttributeName( AType value); ). Then, you can set
this attribute from the XML configuration file by using the <setAttribute name=””
value=””/> tag as follow:
  <metamodel publicId="isp-nsuml"
           classname="myPackage.MyMetaModelHelper"
           engineAdaptor="ispuml.mdaTransformation.model.jmi.JmiModelContext"
           >
      <setProperty name=”attributeName” value=”aValue”/>
      <setProperty name=”anotherAttributeName” value=”anotherValue”/>
  </metamodel>
When the configuration file is loaded, your metamodel helper will be created, and any
attributes set in the XML file will be set in the newly created class.
Then, the factory will return the class anytime a program requests it by its publicId.

8 Metamodel Contexts
Following is a list of “metamodel helper” or “metamodel context”.
When        using         JMI      with        no     UML         metamodel,      choose
ispuml.mdaTransformation.model.jmi.JmiModelContext.
When using a uml metamodel, choose the appropriate helper according to the UML version.

   Description              Common JMI Metamodel Helper / Context
   Classname                ispuml.mdaTransformation.model.jmi.JmiModelContext
     jar file               mdaTransf.jar
 Compatibility list             


   Description              UML1.3 Metamodel Helper / Context
   Classname                ispuml.mdaTransformation.model.jmi.JmiUML13ModelContext
     jar file               mdaTransf.jar
 Compatibility list              UML13 Metamodel (JMI)

      Description           UML1.4 Metamodel Helper / Context
      Classname             ispuml.mdaTransformation.model.jmi.JmiUML14ModelContext
   jar file          mdaTransf.jar
Compatibility list      UML14 Metamodel (JMI)


   Description       Base implementation of Metamodel Helper / Context.
                     This implementation provides property getter and setter. The UML
                     related methods are not implemented.
                     This implementation can not be used as is. It requests an additional
                     ModelUtil implementation.
  Classname          ispuml.mdaTransformation.model.SimpleModel
    jar file         mdaTransf.jar
Compatibility list       

   Description       The Tau G2 Metamodel Helper / Context.
                     This implementation is suitable for the Tau G2 metamodel generated
                     with Castor.
  Classname          ispuml.taug2.mdaTransformation.Taug2ModelContext
    jar file         taug2-model.jar
Compatibility list        The tau G2 metamodel generated with castor.

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:0
posted:11/21/2011
language:
pages:14