Usually a java project is composed of its own model and source files. During a reverse operation (or a round trip mode update), all those files are considered accessible: links are always created in the model to the corresponding classes.
Note: Each << Java Component >> can define its own source path, meaning a java project can use several source directories at the same time.
Sometimes, other elements are needed, which are essential to the project but do not actually belong to it. They usually correspond to external libraries (Jar files), or some other parts of the project not yet in the model.
All used JAR files must be declared in the project configuration. To define them, launch the “Java Designer/Configuration/Edit accessible classes” command on the project’s root package.
When a reference to a type (extends link, parameter…) is found and needs to be reversed, Java Designer goes through several steps:
Note: An “External Element” is an empty placeholder. It is recommended either to update it, or to use a Model Component that contains it. The Java code of an external element is never generated.
ANT generation creates a set of predefined targets. If you need to add a specific target, you will need to create an “AntTarget” note and write your own target in it. In this case, these parts will be generated at the end of build.xml file, between markers.
In Modelio, you can now create a compilation artifact representing the jar file, simply by clicking on the “Create Java Designer element\Compilation artifact” command, in the context menu.
A deployment diagram is automatically created below the compilation artifact, in order to create a manifestation link to packages to be embedded within your jar file. Note that you can create packages with long names, as in the example shown in the figure below.
On this artifact, you can launch various commands, as shown in the figure below.
Key:
: The “Generate” command will generate Java code for all the elements manifested
by the artifact.
: The “Update model if necessary” command will reverse the Java code for all the elements manifested by the artifact.
: The “Generate Ant file” command will generate the build.xml file in the Java
workspace directory, to compile manifested elements.
: The “Compile” command will launch the compilation by executing the ANT
target “build”, to create .class files from your generated Java files.
: The “Execute Ant target” command will open a window to present all the targets defined in the ANT file, so that you can select the target that is to be launched.
: The “Run application” command is used to run a generated and compiled application from an ANT file.
The following table details predefined targets:
Name | Label |
---|---|
Init | Initialize the environment. |
Clean | Delete all files produced by the compilation. |
Resource | Manage resource files. |
Build | Compile the project. |
Archive | Create the jar file. |
RMI | Use rmic on corresponding classes. |
Javah | Use Javah on corresponding classes. |
Note: You can specify that a jar file requires another jar file by creating a Usage link between them.
ANT files are generated according to the artifacts that represent them in the model. By default, the ant file is generated in the compilation path using the name of the artifact followed by “.xml”. It is possible to specify an alternative path using a tagged value available on artifacts. This path must be absolute and must contain the ANT file name.
By default, the Jar file produced by the generated ANT file is created in the path defined by the “Execution path” Java Designer parameter using the name of the artifact followed by “.jar”. This path can be modified at parameter level. Each Jar file can be produced with a different name and directory by using the “FileName” field found in the edition box of the compilation artifact in question.
Before an application can be run from a compilation artifact, the application in question must have been compiled. The Jar file must also have been built.
The {JavaMainClass(< FullClassPath >)} tagged value is used to specify the main class of the application. This class will be used when the application is launched from Modelio.
To run an application from a compilation artifact, simply carry out the steps shown in the figure below.
Steps:
Select the compilation artifact (in our example, the “HelloJava” jar file).
In the “Java” tab, click on the icon. The application is then
run.
Two functioning modes are available with Modelio Java Designer:
Model-driven, which is based on the total generation of declarative code from the model itself. Application code (in other words, the programming of operations) is modeling through notes, or typing in marked zones. This mode does not concern reverse engineering.
Round-trip, combining reverse engineering and code generation. Code is generated in exactly the same way as with the model driven mode. The user can freely modify the code nearby in the generated code or work in his favorite IDE. The model is updated when the “Update Source” command is run.
Release, to generate the sources with no Modelio annotation.
The Java functioning mode is configured through the standard Modelio configuration interface, which is launched using the “Set module parameters” command. The generation mode is selected in the “Generation mode” field (as shown in the figure below).
Model-driven engineering is based on complete generation of declarative code from the UML model.
Marked zones are carefully inserted into the generated Java code, with each of these zones corresponding to a note that can be added to the model. Application code (virtually reduced to the programming of operations) is written in these marked zones (using with the aid of an external editor or an IDE).
Once the zones have been completed, their contents can be transferred back into the model in the form of corresponding notes. This operation can be carried out as many times as possible.
The model-driven engineering mode does not, therefore, involve reverse engineering. All “declarative” modifications, such as, for example, the addition of a new attribute, are in fact model modifications and as such must be carried out within Modelio, before subsequently regenerating the code.
Certain mechanisms exist to guarantee that the regenerated code does not overwrite any modifications made outside Modelio.
In this way, the entire application can be fine-tuned outside Modelio, as long as the model itself is not modified.
The main advantage of this mode is that the code always corresponds to the model. In fact, it is only possible to modify declarations by modifying the model itself.
Other advantages are as follows:
The obvious drawback of the model-driven engineering mode is that you are obliged to come back to Modelio after every modification made to the model, in order to regenerate the code.
Round-trip engineering is a functioning mode that combines code generation and reverse engineering. Code is generated in exactly the same way as with model driven engineering. Specific annotations are also generated, @objid, which are used during the reverse engineering phase to match code and model elements in Modelio.
Application code (virtually reduced to programming operations if the model is complete) is written in these marked zones (using an external editor or an IDE).
Unlike the model-driven mode, the round-trip mode allows the model to be directly modified at code level. The code is then fully reversed, in order to update the model.
In the example shown in the figure below, the String type attribute appears in the model.
The main advantage of the round-trip mode is that modifications can be carried out within the code itself, with the model only being updated periodically.
The fundamental disadvantage is:
either that the code will very rapidly differ from the model
or that the model returned will be physical and will lose its “overview”
or a mix of the two previously described disadvantages
Note: See section updating the UML model for more information about the @objid annotation.
Modelio Java Designer uses a specific XML file to define the mapping of base types, containers and the default creation of accessors.
These packages are found in the “javaCustomizationFile” XML file, located in the module’s installation directory (< Project_Path >/mda/JavaDesigner/res/custom/).
You can modify basic type mapping in order to generate your own custom type. The following is an example of type definition from the customization file:
1 <ModelType name="date">
2 <JavaType name="Date">
3 <import name="java.util.Date"/>
4 <wrapper name="Date"/>
5 </JavaType>
6 </ModelType>
ModelType: the base type in Modelio.
JavaType: the corresponding java primitive type or class.
Import: the import line to add at generation, if necessary.
Wrapper: the java primitive type or class to use if the “wrapper” property is set on the model.
The second part of the customization file contains the definition for accessor default patterns.
Elements are defined with several cardinalities, according to multiplicities:
Multiplicity | Cardinality |
---|---|
0..1 | OptionalSimple. |
1..1 | MandatorySimple. |
0..* | OptionalMultiple. |
n..* | MandatoryMultiple. |
n..m | Finite. |
Each definition corresponds to a specific metaclass, for example:
1 <Attribute card="OptionalSimple">
2 <getter>
3 <defaultPattern>get$Name</defaultPattern>
4 <variants>
5 <pattern type="boolean">is$Name</pattern>
6 </variants>
7 </getter>
8 <setter>
9 <defaultPattern>set$Name</defaultPattern>
10 </setter>
11 </Attribute>
This definition contains three parts:
The default name pattern for getters generated on an attribute is “get$Name”, where $Name is replaced by the name of the attribute.
If the attribute has a boolean type, the name of the getter is “is$Name” instead of “get$Name”.
The default name pattern for setters generated on an attribute is “set$Name”.
In the same part of the customization file, default container can also be specified, for multiple cardinalities. These containers are automatically generated if no container is defined on an element, such as an Attribute, an AssociationEnd or a Parameter. For example:
1 <AssociationEnd card="MandatoryMultiple">
2 <defaultInterfaceContainer name="List">
3 <import name="java.util.List"/>
4 </defaultInterfaceContainer>
5 <defaultImplementationContainer name="ArrayList">
6 <import name="java.util.ArrayList"/>
7 </defaultImplementationContainer>
8 ...
This definition contains two parts:
The default interface container for an AssociationEnd with a n..* multiplicity is List, with a specific import.
The default implementation container for an AssociationEnd with a n..* multiplicity is ArrayList, with a specific import.
Note: You can use “Array” if you do not want specific collections to be generated.
Modelio Java Designer provides several modes of customization, each aimed at a different category of user. This complete Java generation customization enables you to generate the exact programming form desired, by adapting Modelio Java Designer to your specific needs. For example, the mapping of types and the generation of accessors used by default can be modified, so as to create specific generations or to respect forms of imposed programming.
Depending on the level of detail you want to use for parameterization, you can choose to:
modify parameters and simply change the general options Modelio Java Designer
configure the mapping of types and the generation of accessors. The choice of basic types and the way they are used in code generation is then adapted to all generations.
The Modelio Java Designer parameter configuration window can be used to modify the behavior of the module.
To access the window used to configure Modelio Java Designer parameters, simply run the “Options/Set module parameters” command from the Modelio toolbar.
– Generation mode: indicates the mode selected for generation:
– Default behavior for file retrieving: indicates what to do during generation if the file on disk has been modified since the last generation:
– Encoding: indicates the encoding used for Java files during generation and reverse operations. The default value is UTF-8.
Note: For further information on the model-driven generation mode and the round-trip generation mode, please see “Model-driven mode” and “Round-trip mode”.
Note: By default, attributes are created with a public accessor.
Note: By default, invariants and conditions are not generated.
Note: For further details on documentation generation, please see “Overview of Java documentation generation”.
Listed below are the usual concepts for Java development, together with the way in which they can be expressed in Modelio.
Java notion | UML model mapping |
---|---|
abstract class | "Abstract" field of a class |
final class | "Can be inherited" field of a class |
generalization | Class generalization, or [{JavaExtends} tagged value][2] |
interface implementation | Implementation link, or [{JavaImplements} tagged value][2] |
imports classes | Use and reference links of its package, or [{JavaImport} tagged value][2] on the class and its package |
class invariant | Constraint on class, [stereotyped JavaInvariant][3] |
inner class | Contained class |
non public class | [JavaBottom note type][4], or import link stereotyped [JavaFileGroup][5] |
Java notion | UML model mapping |
---|---|
public visibility | Public value in the Visibility field on an operation. |
protected visibility | Protected value in the Visibility field on an operation. |
private visibility | Private value in the Visibility field on an operation. |
friendly visibility | No value in the Visibility field on an operation. |
constructor | create stereotype on an operation. |
finalize() method | destroy stereotype on an operation. |
abstract | "Abstract" operation field. |
static | "Class" operation field. |
final | "Cannot be specialized" operation field. |
synchronized | [{JavaSynchronized} tagged value][2]. |
native | [{JavaNative} tagged value][2]. |
exceptions generated by an operation | [{JavaThrownException} tagged value][2]. You can model the throwing of exceptions through a dependency link towards a class which derives from java.lang.Exception or towards a signal stereotyped Exception. |
Java notion | UML model mapping |
---|---|
visibility | Same mapping process as for operations. |
static | Class field of an attribute. |
final | [{JavaFinal} tagged value][2]. |
Java source files can contain several classes. To generate several classes in the same source file, the file’s main class is linked to the other files by an element import link stereotyped as JavaFileGroup.
A Java source file containing several classes is generated in the model in the following way:
The file’s main class is linked to the other files by an element import link stereotyped JavaFileGroup.
Modelio Java Designer generation provides several features related to generation.
: The “Generate” command will generate Java code for the class.
: The “Edit” command will open an editor to modify the Java file content. When
the editor is closed, the content of the file is automatically reversed.
: The “Update model” command will reverse the Java code for the class.
Modelio Java Designer notes are used to complete the UML model with texts expressed in Java syntax. Usually, the internal processing of a UML method is entered in Java in a “JavaCode” type note associated to a method’s implementation.
Note: Certain notes can be added to certain model elements directly through the “Java” tab. For more information, please see “Java Designer property view”.
The ... type of note | Label | Is used to... |
---|---|---|
JavaHeader | Header | insert a text before declaring the class. |
JavaMembers | Members | insert a text in the class body. |
JavaBottom | Bottom | insert a text after declaring the class. |
Javadoc | Javadoc | add a comment to be used by javadoc. |
JavaTop | Top | insert a comment before the java file's package instruction. |
JavaAnnotation | Annotations | specify the annotations added to the class. |
The ... type of note | Label | Is used to... |
---|---|---|
Javadoc | Javadoc | add a comment which will be used by javadoc. |
JavaCode | Code | provide Java code for implementing the operation. |
JavaSuper | Super | insert Java code before the pre-condition (especially for calling the builder of the parent class). |
JavaReturned | Return code | insert Java code after the post-condition (especially for instructing the method return). |
JavaAnnotation | Annotations | specify the annotations added to the operation. |
The ... type of note | Label | Is used to... |
---|---|---|
JavaInitValueComment | Comment on the initial value | add a comment about the attribute. |
Javadoc | Javadoc | add a comment to be used by javadoc. |
JavaAnnotation | Annotations | specify the annotations added to the attribute. |
The ... type of note | Label | Is used to... |
---|---|---|
JavaAnnotation | Annotations | specify the annotations added to the association. |
Javadoc | Javadoc | add a comment to be used by javadoc. |
JavaInitValue | Initial value | set initialization for the association. |
JavaInitValueComment | Comment on the initial value | add a comment after the initialization of a navigable association. |
The ... type of note | Label | Is used to... |
---|---|---|
JavaAnnotation | Annotations | specify the annotations added to the package. |
The ... type of note | Label | Is used to... |
---|---|---|
Javadoc | Javadoc | add a comment to be used by javadoc. |
JavaHeader | Header | insert a text before declaring the class. |
JavaMembers | Members | insert a text in the class body. |
The ... type of note | Label | Is used to... |
---|---|---|
SeeJavadoc | See Javadoc | contain the format of a @see annotation. |
The ... type of note | Label | Is used to... |
---|---|---|
Javadoc | Javadoc | add a comment to be used by javadoc. |
The ... type of note | Label | Is used to... |
---|---|---|
JavaAnnotation | Annotations | specify the annotations added to the enumeration. |
JavaCode | Code | specify the Java code to add in the enumeration. |
Javadoc | Javadoc | add a comment to be used by javadoc. |
The ... type of note | Label | Is used to... |
---|---|---|
JavaAnnotation | Annotations | specify the annotations added to the enumeration literal. |
JavaCode | Code | add Java code to this literal. |
Javadoc | Javadoc | add a comment to be used by javadoc. |
The ... type of note | Label | Is used to... |
---|---|---|
JavaAnnotation | Annotations | specify the annotations added to the interface. |
JavaBottom | Bottom | insert a text after declaring the interface. |
Javadoc | Javadoc | add a comment to be used by javadoc. |
JavaHeader | Header | insert a text before declaring the interface. |
JavaMembers | Members | insert a text in the interface body. |
JavaTop | Top | insert a comment before the Java file's package instruction. |
The ... type of note | Label | Is used to... |
---|---|---|
AntTarget | Ant target | allow custom targets to be added in the generated ant file. |
The ... type of note | Label | Is used to... |
---|---|---|
JavaAnnotation | Annotations | specify the annotations added to the parameter. |
Javadoc | Javadoc | add a comment to be used by javadoc. |
By default, types are generated with their short name (without namespacing). For example, the following diagram:
will lead to the generation of the following code for the association of the “Age” role in the “Person” class :
1 private Integer age;
However, it remains possible to generate the association type with its full name by setting the {JavaFullName} tagged value on the navigable association. This way, the following diagram:
will lead to the generation of this code :
1 private java.lang.Integer age;
The above rule applies to the generation of navigable associations, attributes, method parameters, generalizations and implementations.
The generation of Java code is based on a UML model, extended by notes and tagged values specific to Java, in order to generate all the code for Java classes.
This generation can be parameterized to a high level, using the following mechanisms:
Java generation parameters provide general generation options
the Java customization file allows you to modify the mapping of types.
Java annotations are defined in the “Java annotation definition” window.
This window, accessible by launching the “Edit properties” command on a class stereotyped JavaAnnotation, defines all options available on the annotation definition.
Name | Function of the annotation |
---|---|
Annotation is documented | Specifies whether the annotation is documented. Corresponds to the @Documented annotation type. |
Annotation is inherited | Specifies whether the annotation is documented. Corresponds to the @Inherited annotation type. |
Retention | Specifies the retention policy of the annotation. Corresponds to the @Retention annotation type. |
Annotation target | Specifies the types of elements where the annotation is applicable. Corresponds to the @Target annotation type. |
Modelio Java Designer defines stereotypes that enable you to designate certain objects as being concerned by the generation of Java code. In this way, a constraint concerning an operation will be used as a pre-condition if it carries the JavaPreConditions stereotype.
Note: Certain stereotypes can be added to certain model elements directly through the “Java” tab. For more information, please see “Java Designer property view”.
Name | Is used to... |
---|---|
JavaAnnotation | specify that this class is an annotation. |
JavaClass | specify that this class is a Java element. |
Name | Is used to... |
---|---|
JavaResource | specify that this artifact is a Java resource. |
JarFile | specify that this artifact is a jar. |
Name | Is used to... |
---|---|
JavaPlugin | specify that this component is a Java plugin. |
Name | Is used to... |
---|---|
JavaDocInvariant | designate a constraint as being an invariant expressed in JavaDoc. Such a constraint is only taken into account if it concerns a class. |
Invariant | When the "description note processed as Javadoc" parameter is selected, the constraint is taken into account in JavaDoc as for JavaDocInvariant. |
JavaInvariant | designate a constraint as being an invariant expressed in Java. Such a constraint is only taken into account if it concerns a class. |
JavaPreCondition | designate a constraint as being a pre-condition expressed in Java. Such a constraint is only taken into account if it concerns an operation. |
JavaPostCondition | designate a constraint as being a post-condition expressed in Java. Such a constraint is only taken into account if it concerns an operation. |
Name | Is used to... |
---|---|
JavaDataType | specify that this datatype is a Java element. |
Name | Is used to... |
---|---|
JavaEnumeration | specify that this enumeration is a Java element. |
Name | Is used to... |
---|---|
JavaInterface | specify that this interface is a Java element. |
Name | Is used to... |
---|---|
JavaPackage | specify that this package is a Java element. |
The tagged values provided by Modelio Java Designer are designed to let you adapt Java semantics to a UML model, in order to generate all Java notions accurately. For example, the notion of native method in Java does not exist in UML. A {JavaNative} tagged value on a UML operation enables you to specify this on a model.
Note: Certain tagged values can be added to certain model elements directly through the “Java” tab. For more information, please see “Java Designer property view”.
Name | Label | Parameters | Role |
---|---|---|---|
JavaStatic | Static | N/A | Used to declare the embedded class as being static. |
JavaExtends | Extends | name of the parent class | Inherits non-modeled classes. |
JavaImplements | Implements | names of implemented interfaces | Implements non-modeled interfaces. |
JavaImport | Imports | names of the imported classes and packages | Imports non-modeled packages and classes. |
JavaExtern | Extern | N/A | Indicates a class for which code must not be generated. |
nocode | N/A | Prevents this class from being generated. No Java file is generated for this class. | |
persistence | N/A | Specifies that the class is persistent. |
Name | Label | Parameters | Role |
---|---|---|---|
JavaImport | Imports | names of the imported classes and packages | Imports non-modeled packages and classes. |
JavaExtern | Extern | N/A | Indicates a package for which code must not be generated from its classes. |
nocode | N/A | Prevents this package from being generated. No Java file is generated for this package. |
Name | Label | Parameters | Role |
---|---|---|---|
JavaStrict | Strict | N/A | Representation of the Java keyword "strictfp" for the generated operation. |
JavaSynchronized | Synchronized | N/A | Representation of the Java "synchronized" keyword meant for the multi-threading. |
JavaNative | Native | N/A | Representation of the "native" Java keyword for the methods written in languages other than Java. |
JavaThrownException | Thrown exceptions | name of the exceptions that may be called | Lists the exceptions the operation can generate. |
JavaTemplateParameters | Template parameters | Template parameters | Specifies template parameters for a generic operation. |
nocode | N/A | Prevents this operation from being generated. |
Name | Label | Parameters | Role |
---|---|---|---|
JavaWrapper | Use wrapped type | N/A | Uses the Wrapper class as base type (for example, Integer for int). |
type | A collection interface | Indicates a class other than the default class for the generations related to the attribute. The {type} tagged value can be used together with the {JavaImplementationType} tagged value to define a personalized collection. | |
JavaTypeExpr | Manual type expression | text for specifying the attribute's Java type | Generation of the types that cannot be represented in Modelio (ex : int [ ] [ ]). **_Note_**: Setting an attribute's multiplicity to * leads to errors!. |
JavaFinal | Final | N/A | Representation of the Java "final" keyword. |
JavaVolatile | Volatile | N/A | Representation of the Java "volatile" keyword. |
JavaTransient | Transient | N/A | Representation of the Java "transient" keyword. |
JavaFullName | Generate full name | N/A | Allows the generation of the complete name of the class, datatype or enumeration used. |
JavaImplementationType | Collection implementation type | A collection type | Specifies the concrete collection to use in a Java5Types context. The {type} tagged value can be used together with the {JavaImplementationType} tagged value to define a personalized collection. |
JavaBind | Bind | Bound types on the attribute | Specifies the types bound by a generic attribute. |
JavaArrayDimension | Array Dimension | Integer | Specifies the number of dimensions of an array. |
nocode | N/A | Prevents this attribute from being generated. | |
persistence | N/A | Specifies that the attribute is persistent. |
Name | Label | Parameters | Role |
---|---|---|---|
type | A collection interface | Indicates a class other than the default class for the generations related to the association. Specifies the exposed collection interface to use in a Java generation context. | |
JavaFinal | Final | N/A | Representation of the Java "final" keyword. |
JavaVolatile | Volatile | N/A | Representation of the Java "volatile" keyword. |
JavaTransient | Transient | N/A | Representation of the Java "transient" keyword. |
JavaTypeExpr | Manual type expression | text for specifying the attribute's Java type | Specifies the concrete collection to use in a Java5Types context. The {type} tagged value can be used together with the {JavaImplementationType} tagged value to define a personalized collection. |
JavaFullName | Generate full name | N/A | Allows the generation of the complete name of the class, datatype or enumerate used. |
JavaImplementationType | Collection implementation type | A collection type | Specifies the concrete collection to use in a Java5Types context. |
JavaBind | Bind | Bound types on the association | Specifies the types bound by a generic association. |
JavaArrayDimension | Array Dimension | Integer | Specifies the number of dimensions of an array. |
nocode | N/A | Prevents this association from being generated. | |
ordered | N/A | Specifies that the association is ordered. | |
qualifier | N/A | Used to define the association more finely. |
Name | Label | Parameters | Role |
---|---|---|---|
JavaWrapper | Use wrapped type | N/A | Uses Wrapper as its base type (for example, Integer instead of int). |
JavaTypeExpr | Manual type expression | text for specifying the parameter's Java type | Generation of the types that cannot be represented in Modelio (ex: in [ ] [ ]). **Note:** Setting a parameter's multiplicity to * leads to errors! |
JavaFullName | Generate full name | N/A | Allows the generation of the complete name of the class, datatype or enumerate used. |
type | name of the class for generating the parameter declaration | Indicates a class other than the default class to generate a parameter declaration. | |
JavaFinal | Final | N/A | Generates the "final" keyword before a parameter. |
JavaBind | Bind | Bound types to the association | Specifies the types bound by a generic parameter. |
JavaVarArgs | Is a VarArg | N/A | Specifies that this parameter is a VarArg parameter, as defined by Java 5. |
JavaArrayDimension | Array Dimension | Integer | Specifies the number of dimensions of an array. |
Name | Label | Parameters | Role |
---|---|---|---|
JavaExtends | Extends | name of the mother class | Inherits non-modeled classes. |
JavaExtern | Extern | N/A | Indicates a class for which code must not be generated. |
JavaImport | Imports | names of the imported classes and packages | Imports non-modeled packages and classes. |
JavaStatic | Static | JavaStatic | Used to declare the datatype as being static. |
persistence | N/A | Specifies that the datatype is persistent. |
Name | Label | Parameters | Role |
---|---|---|---|
JavaFullName | Generate full name | N/A | Allows the generation of the complete name of the class, datatype or enumerate used. |
JavaNoCode | Do not generate | N/A | Prevents this generalization from being generated. |
JavaBind | Bind | Bound types on the generalization | Specifies the types bound by a generic attribute. |
Name | Label | Parameters | Role |
---|---|---|---|
JavaFullName | Generate full name | N/A | Allows the generation of the complete name of the class, datatype or enumerate used. |
Name | Label | Parameters | Role |
---|---|---|---|
JavaImplements | Implements | name of the parent enumeration | Implements non-modeled interfaces. |
JavaImport | Imports | name of the class to import | Imports non-modeled packages and classes. |
JavaStatic | Static | N/A | Used to declare the embedded enumeration as being static. |
Name | Label | Parameters | Role |
---|---|---|---|
JavaArguments | Arguments | Parameter definitions | Parameters to be passed to the constructor of the enumeration when a constant is created. |
Name | Label | Parameters | Role |
---|---|---|---|
JavaNoInitValue | No initial value | N/A | Indicates that this feature will not have a default value. |
Name | Label | Parameters | Role |
---|---|---|---|
JavaExtends | Extends | name of the parent interface | Inherits non-modeled interfaces. |
JavaExtern | Extern | N/A | Indicates a class for which code must not be generated. |
JavaImport | Imports | name of the classes to import | Imports non-modeled packaged and classes. |
JavaStatic | Static | N/A | Used to declare the embedded interface as being static. |
Name | Label | Parameters | Role |
---|---|---|---|
JavaBind | Bind | type to insert in the generic | Specifies the types bound by a generic attribute. |
JavaFullName | Generate full name | N/A | Allows the generation of the complete name of the class, datatype or enumerate used. |
JavaNoCode | Do not generate | N/A | Prevents this realization from being generated. |
Name | Label | Parameters | Role |
---|---|---|---|
JavaDocumentedAnnotation | Documented Annotation | N/A | Indicates that annotations are to be documented by javadoc and similar tools by default. |
JavaInheritedAnnotation | Inherited Annotation | N/A | Indicates that the annotation type is automatically inherited. |
JavaRetentionAnnotation | Retention Annotation | N/A | Indicates how long annotations with the annotated type are to be retained. |
JavaTargetAnnotation | Target Annotation | N/A | Indicates the kinds of program element to which the annotation type applies. |
Name | Label | Parameters | Role |
---|---|---|---|
GenerationPath | Generation Path | complete path where files are generated | Generation path for Java elements contained in this component. |
Name | Label | Parameters | Role |
---|---|---|---|
JavaNoCode | Do not generate | N/A | Prevents this element from being generated. |
Name | Label | Parameters | Role |
---|---|---|---|
JavaExtends | Extends | name of the parent template parameter | Inherits non-modeled classes. |
Customization file: XML file containing information allowing Modelio types to be mapped into Java types, and accessors to be generated for attributes, navigable associations and parameters.
External edition: Operation allowing notes to be entered using an editor other than the Modelio text editor.
JDK (Java Development Kit): Library containing Java classes and tools, distributed by Sun for Java developers.
Model-driven mode: During generation, text is entered between pre- positioned markers. After edition, it is re-incorporated into the Modelio repository.
Round-trip mode: During generation, anotations are generated before methods and classes. After edition, all model parts that are now up to date with the file are added to the Modelio repository.
Security role: User group with the same rights regarding the calling of a function.
The Java property view is used to enter or modify certain information relevant to Java generation on the element selected in Modelio, such as notes, tagged values or stereotypes.
Key:
The “Java element” field is used to add the << JavaPackage >> stereotype, indicating that the package is handled by Java.
The “No code” field is used to add the {JavaNoCode} tagged value, indicating that the package will not be generated.
The icons at the top of the window are used as follows:
Key:
The “Java element” field is used to add the << JavaClass >> stereotype, indicating that the class is handled by Java.
The “No code” field is used to add the {JavaNoCode} tagged value, indicating that the class will not be generated.
The “Annotation” field is used to specify a Java 5 annotation.
The icons at the top of the window are used as follows:
Key:
The “No code” field is used to add the {JavaNoCode} tagged value, indicating that the operation will not be generated.
The “Static” tickbox indicates that the operation is “class”, in other words, shared by all its instances.
The “Synchronized” tickbox adds the {JavaSynchronize} tagged value to the operation, and indicates that the operation is synchronized.
The “Native” tickbox adds the {JavaNative} tagged value to the operation, and indicates that the operation is native.
The icons at the top of the window are used as follows:
Key:
The “No code” field is used to add the {JavaNoCode} tagged value, indicating that the attribute will not be generated.
The “Java Property” tickbox is used to add the << JavaAttributeProperty >> stereotype, indicating that the getter ad setter created for this attribute won’t be created in the model, but generated.
The “Wrapper” field is used to specify whether or not a basic type should be generated as a wrapper class. Available only for basic types with cardinality of 0..1.
The “Getter” tickbox indicates whether or not an automatically updated getter exists for this attribute.
The “Getter Visibility” combo box indicates the visibility of the generated getter, but only for Java Properties. The “Default” choice means the regular automation is applied to compute this visibility.
The “Setter” tickbox indicates whether or not an automatically updated setter exists for this attribute.
The “Setter Visibility” combo box indicates the visibility of the generated setter, but only for Java Properties. The “Default” choice means the regular automation is applied to compute this visibility.
The “Static” tickbox indicates that the attribute is static.
The “Final” tickbox adds the {JavaFinal} tagged value to the attribute, and indicates that it is final.
The “Volatile” tickbox adds the {JavaVolatile} tagged value to the attribute, and indicates that it is volatile.
The “Transient” tickbox adds the {JavaTransient} tagged value to the attribute, and indicates that it is final.
The “Collection to use” field is used to add {type(x)}, where x can be one of a group of strings in a list. This field specifies, in a package context of type Java 5, the collection to be used and the type of interface published for this attribute, within a framework of multiple cardinality.
The “Key” field is used to add the second parameter to the {type} tagged value. It indicates the key type to use for container types like HashMap.
The “No init value” field is used to disable generation of the attribute’s initial value.
The “Template binding” field is used to specify parameters if the attribute’s datatype is a generic type.
The icons at the top of the window are used as follows:
Key:
The “No code” tickbox is used to add the {JavaNoCode} tagged value, indicating that the attribute will not be generated.
The “Java Property” tickbox is used to add the << JavaAssociationEndProperty >> stereotype, indicating that the getter ad setter created for this association won’t be created in the model, but generated.
The “Getter” tickbox indicates whether or not an automatically updated getter exists for this attribute.
The “Getter Visibility” combo box indicates the visibility of the generated getter, but only for Java Properties. The “Default” choice means the regular automation is applied to compute this visibility.
The “Setter” tickbox indicates whether or not an automatically updated setter exists for this attribute.
The “Setter Visibility” combo box indicates the visibility of the generated setter, but only for Java Properties. The “Default” choice means the regular automation is applied to compute this visibility.
The “Static” tickbox indicates that the attribute is static.
The “Final” tickbox adds the {JavaFinal} tagged value to the attribute, and indicates that it is final.
The “Volatile” tickbox adds the {JavaVolatile} tagged value to the attribute, and indicates that it is volatile.
The “Transient” tickbox adds the {JavaTransient} tagged value to the attribute, and indicates that it is transient.
The “Collection to use” field is used to add {type(x)}, where x can be one of a group of strings in a list. This field specifies, in a package context of type Java 5, the collection to be used and the type of interface published for this attribute, within a framework of multiple cardinality.
The “Key” field is used to add the second parameter to the {type} tagged value. It indicates the key type to use for container types like HashMap.
The “No init value” field is used to disable the generation of the attribute’s initial value.
The “Template binding” field is used to specify parameters if the attribute’s datatype is a generic type.
The icons at the top of the window are used as follows:
Key:
The “Wrapper” field is used to if a basic type must be generated as a wrapper class.
The “Collection” field is used to add the {type(x)}.
The “Binding parameters for generics” field is used to specify parameters if the attribute’s datatype is a generic type.
The icons at the top of the window are used as follows:
Key:
The “Compilation artefact” field is used to add the << JarFile >> stereotype, indicating that this artifact is a compilation artifact.
The “Main class” field is used to add the {JavaMainClass} tagged value, indicating the namespacing of the main class in the project.
The icons at the top of the window are used as follows:
Java code generation consists of producing Java files for a model’s classes, using the correspondence between Java notions and modeling notions.
Modelio Java Designer has a default strategy for generating parameter and attribute declarations. It converts UML types into Java 5 types, ensuring modern code generation, based on the Java collections framework. Other translations can be implemented easily, using the Modelio Java Designer customization file.
Note: Before actually generating, it may be necessary to specify that classes or packages are Java elements using stereotypes or to annotate the model using tagged values and notes.
Java documentation generation uses the JDK javadoc tool to produce HTML files from the generated java files. This operation is therefore related to the generated java files. Special notes, inserted during the modeling phase and taken into account during code generation, are then used.
The compilation of generated files consists of producing the class files from generated Java files. For this, Modelio Java Designer proposes the generation and execution of ANT files.
The reverse engineering operation consists of incorporating classes of existing libraries, especially the JDK, into a model. During the modeling phase, this allows you to:
specialize these classes
implement them
create associations towards them
create attributes that have one of these classes as their type
create methods parameters that have one of these classes as their type
The reverse feature also allows you to reverse your developed code into a Modelio model.
With Modelio, you can manage your resources directly in the model. If you create a Java resource, with the filename field directed to the corresponding local file, on generation, the file is copied in the source path, in the directory corresponding to its container package.
On compilation, the resource file is copied from the source directory to the corresponding compiled files directory.
On jar file creation, the resource file is integrated into the jar file, in the corresponding directory.
Java resource files can be created on Java packages only. They are
useful when modeling property files or images that are integrated directly
into your packages.
Welcome to the Modelio Java Designer user guide!
Modelio Java Designer generates a Java application from a Modelio model, and also manages the generation of its documentation.
Modelio Java Designers automatic model completion features makes your modeling easier by managing accessors and implementing interfaces methods.
During the modeling phase, a reverse feature is provided to enable you to use classes in existing libraries, especially the JDK (Java Development Kit).
Modelio Java Designer provides five main features:
Powerful means of parameterization are also provided through:
Modelio Java Designer provides two functioning modes, to ensure consistency at all times between the model built in Modelio and the code produced:
The model-driven mode generates the entire Java application from the model and retrieves the code inserted using markers.
The round-trip mode combines code generation and reverse operations, retrieves freely typed code and creates new model elements when needed.
To use Modelio Java Designer, you need a JDK 1.7 or later.
Note: You must have a JDK. The JRE allows Java programs to be run, but does not allow them to be developed (compilation, documentation generation).
Model components are independent, identified and coherent parts of a larger model, packaged into a single file.
Model components can contain the following:
stable model extracts
tagged value and note types specific to certain modules
external files
Sometimes referred to as RAM components (reusable autonomous model components) or RAMCs, model components are used in a teamwork context, to allow different developers or development teams working on the same project to work only on a limited part of the complete project model.
In a large scale multi-user development project, with several people working together at the same time and in the same workspace, it can be challenging, not to say difficult, to efficiently manage all the interactions that take place.
Model components allow you to increase your efficiency, by reducing the size of the different model extracts involved in a project, and the number of people working on any given model part. This means that each development team can progress in its own teamwork environment and according to its own schedule, without affecting the work of the other project participants.
When you deploy a model component in a database, the model appears in your project, and you can make links to the model. Jar files deployed by this model component are also deployed and automatically taken into account as part of your classpath for compilation and reverse.
For each attribute or association in a class, a number of access methods to this data member can be automatically managed in the model. There are two groups of access methods, one for reading (“getX()” or “isX()”) and the other for modification (“setX()”, and so on).
When creating an attribute, the default choice is “Read”, and an accessor is created. Therefore, according to the element access mode, the following cases are available:
No access | Read | Write | Read-write | |
---|---|---|---|---|
Attributes | No accessor generated | get< AttributeName > | set< AttributeName > | get< AttributeName > set< AtrributeName > |
Associations | No accessor generated | get< AssociationRole > | set< AssociationRole > | get< AssociationRole > set< AssociationRole > |
With Modelio Java Designer automation, consistency is permanently maintained between an attribute or association and its access methods. If the name of the attribute changes, all the access methods are updated.
The default “JavaCode” note belonging to all automatically managed access methods contains a specific marker. Removing this marker deactivates the code update for this method, enabling to keep your specific code.
The “Automation” group of Modelio Java Designer parameters contains the default visibility value for all created access methods, according to the attribute or association visibility. It is also possible to disable the access method management in your model.
This feature maintains consistency for operations in interfaces and their implementing classes. Operations can be automatically created when a class implements a new interface, including a redefinition link visible in the fast link editor.
When the name of a method in the interface changes, all the redefined methods in its child classes are updated. If you decide to create a new operation in your interface, the same operation can be created in the child classes.
The “Automation” group of Modelio Java Designer parameters contains the different behaviors for the automatic update of classes implementing an interface.
The “Always” value does the update automatically each time an interface is modified.
The “Never” value deactivates the automatic model update.
The modules default value, “Ask”, making the following dialog box to appear after each update on an interface:
If you choose “Yes”, the modifications made to the interface will be propagated to the implementing classes, whereas if you choose “No”, the model will remain unmodified. “All” indicates your choice will be keeped for every other modified interface.
Automatic interface implementation can also be launched manually on model elements.
On an interface:
Open the contextual menu
Launch the “Update classes implementing this interface” command
On a class implementing an interface:
Open the contextual menu
Launch the “Update from implemented interface” command
To generate the documentation for a package, run the “Java Designer/Generate JavaDoc” command.
To display the documentation you have just generated, run the “Java Designer/Visualize JavaDoc” command. Your default HTML browser is automatically chosen.
Javadoc generation can be customized in the “JavaDoc” group when configuring Modelio Java Designer parameters.
Key:
“Generate JavaDoc”: This parameter is used to activate or deactivate JavaDoc generation in source files.
“Generate "description” notes as “javadoc” “: This parameter lets you generate "description” notes found in the model as “Javadoc” notes. This can be useful when a general design model is converted into a Java-specific model.
“Generation options”: This parameter defines the options given to the JavaDoc tool.
Javadoc notes are used by Modelio Java Designer to enter information that will be included in Java documentation, at class, attribute, operation, operation parameter, operation return parameter and navigable association level.
Javadoc notes can also be created on links stereotyped throw. A parameter allows the use of “description” type notes, as well as “Javadoc” type notes.
Note: Only the final Javadoc zone preceding the documented element is taken into account by the documentation generation operation.
In Modelio, a Javadoc note on... | produces Java documentation... |
---|---|
a class | for the deduced class. |
an attribute | for the attribute and its accessors. |
an operation | for the deduced operation. |
an operation parameter or return parameter | for the deduced parameter or return parameter, concatenated with the operation's documentation. Documentation generation options at parameter configuration level are used to specify whether or not you wish to generate this information in your application's source code. If you check the tickboxes at parameter configuration level, the corresponding @param and @return markers will be generated in the Javadoc zone of the operation |
a navigable association | for the attribute and its accessors. |
a link stereotyped throw | for the link. Documentation generation options are used to specify whether or not you wish to generate this information in your application's source code. If you check the tickbox, the corresponding @throws marker will be generated in the Javadoc zone of the operation. |
Note: For further information on @param, @return, @throws and @see markers, please refer to the related Javadoc documentation provided by Sun.
Javadoc @see markers are used to create “See also” links in the documentation created by Javadoc. Using Modelio Java Designer, these links are modeled through a dialog box which can be accessed via the context menu available on classes and operations.
By using the drag and drop feature, you can link a class or an operation to a package, class, operation, attribute or association. For every linked element, it is possible to add a description text.
Where operations are concerned, you can choose to display the type of the link. Possible types are:
"Generate the object name": this is used to generate only the name of
the operation.
"Generate the object name with argument types": this is used to
generate the name of the operation and the list of types of the parameters.
"Generate the object name with argument types and names": this
generates the name of the operation and the list of types and names of the parameters.
The “Add”, “Apply” and “Remove” buttons are used to add a new “See also” link, modify an existing “See also” link or delete an existing “See also” link.
The figure below shows an example of the creation of a new see also link.
Creating a new “See also” link
Steps:
Select the class or operation for which you want to create a see also link by right-clicking, and run the “Links for Javadoc generation” command.
From the explorer, drag and drop the element you wish to link the selected class or operation to.
Enter a description of the new see also link.
Select the link type. By default, this is set to “Generate the object name”.
Click on “Add” to confirm your creation and add the new link to the left hand “@see links” column.
Confirm by clicking on “OK”.
The result of this operation is shown below.
Extracts from generated Javadoc documentation and the generated source file
The information you entered in the “Enter the link text” zone of the “@see links for Javadoc” window is presented in the generated Java documentation. It is introduced by the “See Also” title, followed by the text entered.
The same information is present in the generated source file, preceded by first the @see and then by the linked elements.
Java documentation generation consists of producing HTML files from generated .java files. The JDK javadoc tool is used for this purpose. The produced documentation can be visualized using an HTML explorer.
It is possible to create class diagrams automatically after the reverse or by using a command.
In order to create the diagram corresponding to the reversed classes after the reverse, open the parameter configuration window (via the “Configuration/Settings"menu) and check the "Automatically create diagrams on initial reverse” tickbox.
To ask for diagrams to be created on a particular package, use the “Java Designer/Create diagrams” command from the contextual menu of that package. The following diagrams will be created when necessary:
These diagrams can then be modified at your convenience just as with all diagrams in Modelio.
If you need to access this feature again (using the command on a package or automatically after a reverse), the diagrams are not modified. They are renamed using the “old” prefix and new diagrams are created.
The Modelio Java Designer reverse tool makes it possible to parse Java source files and retrieve the model in Modelio. The source code does not have to be compilable, but it must use valid Java language syntax. The following example should be able to be reversed:
1 public class MyClass {
2 int myAttribute = 10;
3 }
While this example should not be able to be reversed:
1 public class MyClass {
2 int myAttribute = "10";
3 }
Certain relationships between Java and Modelio are direct, whilst others require the creation of tagged values as shown in the list below.
Metaclass | Java modifier | Tagged value |
---|---|---|
Attribute, AssociationEnd | final | {JavaFinal} |
N/A | transient | {JavaTransient} |
N/A | volatile | {JavaVolatile} |
Operation | synchronized | {JavaSynchronized} |
N/A | native | {JavaNative} |
The constructors of a Java class, which have the name as this class in Java, are created with the create stereotype in Modelio. As the passing mode of the parameters in Java is by reference, all the parameters of an operation, except the return parameter, have the In/Out type. A Java class may contain fields. Their type decides the reversed field that will be created as an attribute or an association. When the type is the primitive Java type or string, the field corresponds to an attribute. Otherwise, it is an association.
Usually an application (or even a component or a single class) is composed of its own specific elements: its source files, and external elements such as JAR files or external classes.
We will call the application’s own elements “Elements to reverse”. Most often, these elements will be systematically reversed.
Elements which are essential to the application but which do not actually belong to it will be called “External elements”. The reverse of these elements is not complete. They will be reversed according to the needs at the time of the reverse of the “External elements”.
Example:
1 // File HelloJava.java
2 public class HelloJava {
3 public static javax.swing.JFrame _jFrame_;
4
5 public static void main(String[] args) {
6 _jFrame_ = new javax.swing.JFrame("HelloJava.java");
7 _jFrame_.setSize(170, 50);
8 _jFrame_.getContentPane().add(new javax.swing.JLabel("Hello, Java !"));
9 _jFrame_.setVisible(true);
10 }
11 }
In this example, the element to reverse is the “HelloJava” class. The external element is the “JFrame” class. The Reverse tool will produce the model shown below.
The “HelloJava” class uses the “JFrame” class. The contents of the “JFrame” class are reversed into the model with the {JavaExtern} tagged value. “JFrame” stems from the “rt.jar” external component (binary). This component contains many classes (more than 3000) that are not reversed because they are not used or referenced by “HelloWorld.java”. This prevents the model from being overloaded with all the external elements.
Java source files can contain several classes. This type of file is retrieved in the model as follows:
The main class in the file is linked to other files by a use link stereotyped JavaFileGroup.
Note: If one of the classes in the file is public, it will be considered to be the main class of the file being reversed. If there is no public class, the main class is one whose name is the same as that of the file. If no class with a name corresponding to the file name is found, the first class of the file is considered to be the main class.
The syntax of the Java language allows for great complexity in the positioning of comments in the source code.
Certain constructions cannot be reproduced in UML modeling. Comments present in the application source code are taken into account according to the following rules:
All comments found before the package directive are incorporated into the model in the form of a “JavaTop” note in the main class of the file.
All comments preceding an import directive are incorporated in a “description” note.
All comments preceding a class or an interface, as well as a class element, are recuperated into the corresponding model in the form of a “description” or “Javadoc” note, depending on the case.
If the format of the comment is / … / , a “Javadoc” note is created. If the format is / …*/ or //… a “description” note is created.
Every comment following an attribute declaration is recuperated into a “JavaInitValueComment” note.
Each comment preceding a static block or an initialization block is recuperated into a “JavaMembers” note with the block that it precedes.
Each comment preceding the closure of a class is recuperated in the form of a “JavaMembers” note.
All comments at the end of the file are recuperated in the form of a “JavaBottom” note.
Comments present in the body of a method are recuperated with the rest of the method.
All other comments are ignored by the reverse.
The following example illustrates all the possibilities:
1 /*
2 * This comment will be recuperated into a JavaTop note
3 */
4 package p1.p2.p3;
5
6 /*
7 * This comment will be recuperated into a description note
8 * on the use link that corresponds to the import, if the
9 * imported element can be found.
10 */
11 import javax.swing.*;
12
13 /**
14 *This comment will be recuperated into a Javadoc note on the class MyClass
15 */
16 public class MyClass {
17 /**
18 * This comment will be recuperated into a Javadoc note on the attribute
19 * myAtt1
20 */
21 JButton myAtt1;
22 /*
23 * This comment will be recuperated into a description note on the attribute
24 * myAtt2
25 */
26 int myAtt2 = 10; /*
27 * This comment will be recuperated into a
28 * JavaInitValueComment note on myAtt2
29 */
30
31 /**
32 * This comment will be recuperated into a Javadoc note on the operation
33 * method1
34 */
35 void myMethod1() {
36 // This comment will be recuperated with the method body.
37 }
38
39 /*
40 * This comment will be recuperated into a description note on the operation
41 * method2
42 */
43 void myMethod2() {
44 /* This comment will be recuperated with the method body. */
45 }
46
47 /**
48 * This comment will be recuperated into a JavaMember note with the static
49 * block
50 */
51 static {
52 /*
53 * This comment will be recuperated with body of the static block.
54 */
55 }
56 /*
57 * This comment will be recuperated into a JavaMember note with the
58 * initialization block
59 */
60 {
61 /*
62 * This comment will be recuperated with body of the initialization
63 * block.
64 */
65 }
66 }
67 /**
68 * This comment will be recuperated into a JavaBottom note
69 */
Modelio Java Designer provides the user with the possibility of updating a class' modeling within a project. To do this, select “Update model from sources if necessary” on the class.
This command can also be launched on a package, updating all its child classes in the model.
To launch the Reverse wizard, please carry out the following steps:
Right-click on the root package to display its context menu.
Select the command “Java Designer/Reverse Java application from sources” to reverse a source file into the project.
In the first window of the wizard, the path to the application to be reversed into the project should be entered. The central part of the page updates to display the directory’s content, in order to select the elements to reverse into the project.
Select the elements you wish to reverse by checking the associated tickbox.
The “Granularity” field is used to select the desired reversal level.
Three levels are available:
Simple structural
Complete structural
Complete reverse (this reverse level is only available when reversing from sources)
For further details, please see “Three reverse levels”.
Click on the “Next” button to proceed to the next step.
The next window of the Wizard shows the current classpath of your project, as defined in the java module’s parameter. It is not modifiable here, but through classpath edition.
A jar can be ignored in the reverse by unchecking the associated tickbox.
Click on the “Next” button to proceed to the next step.
The final window of the Wizard is used to specify the classpath of the application to be reversed.
Note: All libraries specified here won’t be added to your project’s configuration, but will be considered accessible during the reverse phase.
Use the “Add” and “Remove” buttons to add or remove libraries (jar files), and the arrows to reorder them.
To go back to the previous step, click on the “Previous” button.
To launch the reverse operation, click on the “Reverse” button.
Note: A log file is automatically generated in the module’s installation directory (< Project_Path >/mda/JavaDesigner/reverse-log.html). This log file will be overwritten each time a new reverse is launched.
Reversing an application or a part of an application consists of creating a project that represents the application. A Java application can be reversed from Java source files. Modelio will produce the best possible model.
However, the reverse operation is not defined or scarcely defined for certain code constructions, either because they are not directly in tune with the UML norm, because they are very specific to Java, or simply because they are not recommended for an object-oriented approach. This introduces some restrictions in the reverse tools ability to retrieve some parts of the code in the modeling project. For more information on these restrictions, please see “Restrictions and workarounds”.
Note: The reverse tool is compatible with JDK versions 1.5 and more recent.
This reverse mode is run from the application sources. Using this mode, it is possible to retrieve:
The complete structure of the application to be reversed
The complete code of the classes and methods.
Some options make it possible to fit the quantity of retrieved elements to your needs. For more information, please see “Modelio Java Designer parameters”.
It can occur that a Java application is built from both the source files available at the time of the reverse and components available in binary version only (.jar and .class).
The reverse tool will perfectly adapt itself to the situation and will retrieve:
The complete structure of the application to reverse for the set of sources and binaries
The complete code of the classes and methods for the parts available as sources.
The main advantages of reversing Java components into a project are:
the display of the reversed classes (in a structure of packages, attributes, associations, operations)
the specialization of the reversed classes and the redefinition of their methods
the visualization of documentation and code associated with the reversed elements, when the source code is available
the possibility of continuing to develop your project
the advantages of Modelio capabilities in domains such as modeling, model consistency checking, code generation, documentation generation and production of automatic tests
A class reversed into a project receives an identifier just like an object created in the Modelio explorer or graphic editor.
If two users reverse the same class into two different projecting projects, Modelio will consider them as two different objects.
To avoid losing the links towards reversed classes during the import, it is necessary to run the reverse in a reference project from which each user imports the used classes.
If the source file contains the sequence “ ]]> ”, the sequence will not be reversed correctly. This string corresponds to the escape characters for the string “ ]]> ” that indicates the end of a CDATA zone in XML. To avoid the incorrect replacement of “]]>” by “ ]]> ”, use the following code: “]”+“]>”
When a type declaration cannot be expressed in Modelio, it is encapsulated in a {JavaTypeExpr} tagged value and the attribute, association or parameter type gets the undefined value. This {JavaTypeExpr} tagged value is not included in the signature of a method. Therefore, if an “m1” method is defined containing the only parameter which has a type that cannot be expressed (a JavaTypeExpr), the creation of a second “m1” method with only one JavaTypeExpr parameter will not be accepted by Modelio. This situation, however, is very rare.
If a file does not contain a class with the same name as the file, the model is reversed correctly. However, during the next generation, the original name of the file is lost. To avoid this type of situation, make sure that the name of a file always corresponds to one of the classes it contains.
Certain formats for comments are not supported. The following constructions must be avoided:
1 type MyVariable = test((/*comment*/a+b)*(c+d));
1 int MyVariable = input[/*comment*/0];
1 int[] MyAttribute /*comment*/;
1 private static final String/*comment*/[] MyVariable =
2 {
3 ...
4 };
1 private static final String [] MyVariable
2 /*comment*/= {
3 ...
4 };
1 if (a == 10 && (/*comment*/
2 // comment
3 b>12
4 )){
5 ...
6 }
1 public static final String
2 //comment
3 _URL_1_ = "http://www.modeliosoft.com",
4 //comment
5 _URL_2_= "http://www.modeliosoft.fr",
6 _URL_3_= "http://www.modeliosoft.fr";
1 public enum Week{
2 _Monday_ /*comment*/,
3 _Tuesday_
4 //Comment
5 , _Wednesday_,
6 _Thursday_,
7 //Comment
8 _Friday_,
9 /*Comment*/ _Saturday_,
10 _Sunday_
1 public void actionPerformed(ActionEvent e) {
2 ...
3 } //
Example:
Replace:
1 ...
2 } //comment<end of file>
with:
1 ...
2 } //comment<end of file><return>
3 <end of file>
The Modelio Java Designer reverse tool provides three reverse levels, each of which corresponds to a specific result in the produced project.
This reverse level is used to reverse only the packages and classes of the application.
This level makes it possible to use the reversed classes so as to:
define attribute types
define association types
This level is the fastest.
This level makes it possible to reverse not only the same elements as the “Simple-Structural” level, but also all the attributes, operations and associations of the reversed classes. However, operation contents and initializations (and code) are not reversed.
Reversed classes provide the same possibilities as with the “Simple- Structural” level, but in this level, it is also possible to:
visualize the reversed classes' operations
visualize attributes and associations
overload the operations reversed into the project
Using this level of reverse makes it possible to reverse the application completely, including operation source code and attribute initialization.
This level makes it possible to create a project from an application developed outside Modelio Java Designer and to continue with its development within Modelio Modeler, thereby taking advantage of the Modelio Java Designer generation function.
For the three levels, comments describing the application’s elements are reversed when these exist.
For example, a Javadoc comment in a class will be reversed into the project from “SimpleStructural” level upwards, whereas operation comments will only be reversed from the “Complete-Structural” level.
The following table details the elements reversed into the project at each level.
Simple structural | Complete structural | Complete | |
---|---|---|---|
Packages | X | X | X |
Classes | X | X | X |
Comments | X | X | X |
Attributes | X | X | |
Attribute comments | X | X | |
Attribute initializations | X | ||
Associations | X | X | |
Association comments | X | X | |
Association initializations | X | ||
Operations | X | X | |
Operation comments | X | X | |
Operation code | X |
Note: “X” indicates that the element is retrieved during the reverse operation.
In “roundtrip” mode, the “objid” annotation is generated for classes, interfaces, enumerations, attributes, associations and operations. This annotation contains the identifier of the modeling element that has been generated.
The “objid” annotation is used to find the modeling element in the Modelio project when it is reversed. Without it, the element is searched for by name. This makes it indispensable to update an element when it has been renamed or moved in the Java sources. For example, operations that have changed signature will be updated and not deleted, and then recreated.
When copying code in Java sources, the “objid” annotation must never be copied, in order not to lose information when reversing or updating a modeling element that does not correspond to the Java code.
In order to be able to compile Java sources with this new annotation, an “import” is generated to the file containing the declaration of the annotation:
1 import com.modeliosoft.modelio.javadesigner.annotations.objid;
In the module resources, a “javadesigner.jar” archive is provided, containing the declaration of the annotation. To be able to compile outside Modelio, you must add this archive. If you generate the ANT file from Modelio, the Jar archive is added automatically.
In the Introduction topic of the Modelio Java Designer user guide, you’ll find a general presentation of Modelio Java Designer, along with information on the main features of the module, the property view, resource management and a handy glossary.
The Introduction topic contains the following sections:
The Functionalities topic of the Modelio Java Designer user guide is where youll find everything you need to know about Java code generation, Javadoc generation, ANT generation, Java reverse, Java functioning modes and Java automation.
The Functionalities topic contains the following chapters and sections:
The Generating Java Code chapter of the Modelio Java Designer user guide provides all the information youll need on Java code generation with Modelio Java Designer, as well as details on the tagged values, notes and stereotypes used in Java code generation. The equivalence between Java code and modeling is also presented.
The Generating Java Code chapter contains the following sections:
In the Java Documentation Generation chapter of the Modelio Java Designer user guide, you’ll find a general presentation of generating Java documentation with Modelio Java Designer, as well as detailed information on specific Java documentation generation functions and note types.
The Java Documentation Generation chapter contains the following sections:
In the ANT Generation chapter of the Modelio Java Designer user guide, you’ll find all the information you need on generating and building compilation artifacts, and running applications from these compilation artifacts. Youll also find details on creating targets.
The ANT Generation chapter contains the following sections:
In the Java Reverse chapter of the Modelio Java Designer user guide, you’ll find everything you need to know about Java reverse operations with Modelio Java Designer, including information on reverse levels and scope, how to launch reverse operations, and how to update your UML models. Theres also a handy section with information on workarounds.
The Java Reverse chapter contains the following sections:
In the Choosing Your Functional Mode chapter of the Modelio Java Designer user guide, you’ll find information on the two functioning modes available with the Modelio Java Designer module.
The Choosing Your Functional Mode chapter contains the following sections:
In the Java Automation chapter of the Modelio Java Designer user guide, youll find everything you need to know on access methods and interface implementation.
The Java Automation chapter contains the following sections:
In the Customizing Java generation topic of the Modelio Java Designer user guide, you’ll find detailed information on the different ways in which you can customize Java generation with Modelio to meet your own specific needs and preferences.
The Customizing Java generation topic contains the following sections: