Objecteering Java Developer parameters
Overview
The Objecteering Java Developer parameter configuration window can be used to modify the behavior of the generator regarding the following elements:
· generation directories
· generation options
· project used to map types and to generate accessors
· UML profiles containing J rules
· visibility parameters
Note: The names
and internal names of each parameter are detailed below. The internal name is only useful for the "J" designer and is
used to call the getCurrentModuleParameterValue method.
Accessing parameters
To access the window used to
configure Objecteering Java Developer parameters, simply run the
"Tools/MDAC options" command or click on the 
icon in the toolbar.
The "General" set of parameters
Figure 160. The "General" set of parameters
|
The ... parameter |
internal name ... |
indicates ... |
|
JDK version |
JDKVersion |
the version of the JDK which is used. |
|
JDK (JDKPath) |
JDKPath |
the root directory of the JDK. |
|
Integrated Development Environment (IDE) |
IDE |
the integrated development environment which is to
be used during generation. |
|
Generation Mode |
GenerationMode |
the mode selected for generation (model driven
or round trip). |
|
Accessible classes (CLASSPATH) |
AccessibleClasses |
the paths for searching for imports. The separator is ";" for Windows and ":" for UNIX |
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".
The "Code generation" set of parameters
Figure 161. The "Code generation" set of parameters
|
The ... parameter |
internal name ... |
indicates ... |
|
Code generation compatible with version 2.1 |
Compatible |
whether or not to generate the same code for Enumerations as earlier versions, the visibility of attributes and associations, and their access methods. |
|
Automatically generate |
autoGenerate |
whether or not generation should be run automatically. |
|
Code generation root |
GenerationPath |
the root in which .java files are generated. |
|
Generate full name for used classes |
fullNameGeneration |
that the fully qualified name should be used for
used classes. |
|
Use Java naming rules |
UseJavaNaming |
that during generation, the names of packages,
classes, methods, attributes and parameters will be generated, while
respecting Java recommendations concerning the case (upper or lower) of the
first letter. |
|
Generating pre/post-conditions |
PrePost Generation |
whether the pre and post conditions should be generated on the methods. |
|
Generate invariants |
generate Invariant |
whether not not invariants should be generated. |
|
Invariants name |
invariantsName |
the names of the generated invariants methods. |
|
Pre condition behaviour |
errorTypeFor Preconditions |
whether a
throw exception or an assertion should be generated for preconditions. |
|
Post condition and invariant behavior |
errorType |
whether a throw exception or an assertion should be
generated. |
|
Type of exception for pre/post-conditions |
PrePostExceptionClass |
the exception class used in the generated code for the pre and post conditions. |
|
Generating accessors |
Accessors Generation |
the global running of accessor generation. |
|
Generation of accessors in Java Bean format |
GenJavaBeanLikeAccessors |
Whether or not to generate accessors in Java Bean format. In read-only mode, accessors on Boolean-type attributes are now generated by default in "is<AttributeName>" form. To generate
these accessors in "get<AttributeName>" form, the
"Generation of accessors in Java Bean format" tickbox should be
unchecked. |
|
"description" notes processed as "Javadoc" |
DescriptionAs Javadoc |
the processing of "description"
type notes as well as "Javadoc" type notes. It should be noted that if this option is selected, the "javadoc" field displays nothing, and the "description" field should still be modified. However, code/documentation generation will take the "description" note into account. |
|
Invariants processed as JavaDocInvariant |
Generate InvariantAsJavaDocInvariant |
that the invariant is generated as if it were in a
constraint stereotyped JavaDocInvariant. |
|
In parameters generated as "final" |
FinalForln |
the generation of the "final" keyword for the "in" parameters. |
|
Consistency checks |
Consistency Control |
if the specific Java consistency controls should be
executed during a generation. |
|
Types translation package |
TypesTranslationPackage |
the name of the project used for translation types
and the generation of accessors. |
|
Generating code profile |
JavaProfile |
UML profile used to generate Java code. |
|
Generating code template for Class |
JavaTemplate |
Java code generation template used for Classes. |
|
Generating code template for DataType |
dataType Template |
Java code generation template used for DataTypes. |
|
Generating code template for Enumeration |
EnumTemplate |
Java code generation template used for Enumerations. |
|
Package template |
PackageTemplate |
Java code generation template used for Packages. |
|
Use "JavaImport" notes to generate imports |
useJavaImport Notes |
that "JavaImport" note contents should be used in generation, if the note is present. |
|
Optimize "import" statements |
Import Optimization |
whether or not the necessary imports should be generated by simply calculating on classes and not packages. By optimizing Java imports, only the import of necessary classes is generated in the list of java file imports. In this mode, use links between packages are generated in the form of complete package imports. The dependencies of the class indicated by the user or calculated are browsed, and an import is generated for each class which participates in the dependency. Please note that this parameter affects only package imports, and has no effect on element imports. |
|
Strong encapsulation for access methods (modifier) |
Modifier Encapsulation |
whether or not to raise visibility one level to modify access methods of attributes and associations. |
|
Generator behavior if generated file present but not managed |
manageMode |
generator behavior in the case where the generated file is present but is not managed. Choose from "Ask", "Continue" or "Cancel". |
|
Generate
Java 5 enumerations |
generate
15Enumerations |
Whether or
not to generate enumerations with Java 5 enum keyword. |
|
Generate Javadoc comments on accessors |
Generate Accessor Comments |
Whether or not to generate a default Javadoc on accessors. |
|
Do
not generate read-only elements |
ReadOnlyElementNotGenerated |
Whether or not the Java source for
elements in read only mode should be generated. If this tickbox is checked,
the Java file is not generated if the element has not been checked-out.
However, generation is carried out recursively on all sub-elements. In this
way, it is possible to run the generation command on the root package in read
only mode, in order to only generated elements that have been checked-out. |
Note 1: The last nine parameters described do not appear in Figure 161.
Note 2: Generation options are taken into account during reverse operations.
Note 3: A definition of accessors is provided in the "Glossary". For details on notes, please see "Note types".
Note 4: To find out more about the types translation package, please see "Principles of types and accessor generation". For details on code generation templates, please see "Code generation templates".
The "External edition" set of parameters
Figure 162. The
"External edition" set of parameters
|
The ... parameter |
internal name ... |
indicates ... |
|
Generate markers for documentation zones |
DocId Generated |
whether or not markers should be generated for
documentation zones. |
|
Generate markers for code zones |
IdGenerated |
whether or not markers should be generated for code zones. |
|
Command for invoking external editor |
ExtEditor CommandLine |
the command used to launch an editor to modify the generated code. |
The
"Declaration visibility for attributes and associations" set of
parameters
Figure 163. The
"Declaration visibility for attributes and associations" set of
parameters
|
The ... parameter |
internal name ... |
is used to ... |
|
Elements with "public" visibility |
publicDataMember Visibility |
declare
the visibility of the Java instance variable generated for public attributes. |
|
Elements with "protected" visibility |
protectedData MemberVisibility |
declare the visibility of the Java instance variable generated for protected attributes. |
|
Elements with "package" visibility |
friendlyDataMemberVisibility |
declare the visibility of the Java instance variable generated for package attributes. |
|
Elements with "private" visibility |
privateDataMember Visibility |
declare the visibility of the Java instance variable generated for private attributes. |
Note: By default, attributes are generated with their modeled visibility, and accessors with a public visibility.
The
"Visibility for accessors" set of parameters
Figure 164. The "Visibility for accessors" set of parameters
|
The ... parameter |
internal name ... |
is used to ... |
|
Accessors for "public" elements |
publicAccessor Visibility |
declare
the visibility of "get" type accessors for all public attributes. |
|
Modifier for "public" elements |
publicModifier Visibility |
declare the visibility of "set" type accessors for all public attributes. |
|
Accessors for "protected" elements |
protectedAccessor Visibility |
declare the visibility of "get" type accessors for all protected attributes. |
|
Modifier for "protected" elements |
protectedModifier Visibility |
declare the visibility of "set" type accessors for all protected attributes. |
|
Accessors for "package" elements |
friendlyAccessor Visibility |
declare the visibility of "get" type accessors for all package attributes. |
|
Modifier for "package" elements |
friendlyModifier Visibility |
declare the visibility of "set" type accessors for all package attributes. |
|
Accessors for "private" elements |
privateAccessor Visibility |
declare the visibility of "get" type accessors for all private attributes. |
|
Modifier for "private" elements |
privateModifier Visibility |
declare the visibility of "set" type accessors for all private attributes. |
Note 1: By default, attributes are generated with their modeled visibility, and accessors with a public visibility.
Note 2: The {JavaPublic} tagged value still takes priority in visibility management with regard to Objecteering Java Developer parameters.
The "Compilation" set of parameters
Figure 165. The
"Compilation " set of parameters
|
The ... parameter |
internal name ... |
indicates ... |
|
Compiled files root |
CompilationPath |
the root in which .class files are generated. |
|
Compilation options |
Compilation Options |
the compilation options (aimed at Java). |
|
Generating .h files for native methods |
UseJavah |
whether or not .h files should be generated in
native methods. |
|
Native .h files generation path |
JavahGenerationPath |
the path of the .h files generated by Javah. |
|
Jar file path |
JarFilePath |
the path of the Jar file produced by the generated ANT
file. |
The "Applet" set of parameters
Figure 166. The
"Applet" set of parameters
|
The ... parameter |
internal name ... |
indicates ... |
|
Applet visualizer |
AppletVisualizer |
the command used to launch an applet. |
Note: If there are spaces in the path provided for the applet visualizer, remember to surround the given path with inverted commas.
The "Documentation" set of parameters
Figure 167. The "Documentation" set of parameters
|
The ... parameter |
internal name ... |
indicates ... |
|
Generation directory |
GenDocPath |
the directory in which HTML files are produced by Java documentation generation. |
|
Generation options |
JavaDocOptions |
options to transmit to the javadoc JDK tool for the
generation of Java documentation. |
|
Command for editing the HTML files |
HTMLCommand Editor |
the command used to visualize the generated Java documentation |
|
Generate Javadoc notes for parameters |
paramJavadoc |
whether or not Javadoc notes on parameters should be generated in your application's source code. |
|
Generate Javadoc notes for return parameters |
returnJavadoc |
whether or not Javadoc notes on return parameters should be generated in your application's source code. |
|
Generate Javadoc notes for "throws"
statements |
throwsJavadoc |
whether or not Javadoc notes on links stereotyped <<throws>> should be generated in your application's source code. |
|
Generate "See also" statements in Javadoc notes |
seeJavadoc |
whether or not "See also" statements, used to add "See also" links to the documentation generated by Javadoc, should be generated. |
Note: For further details on documentation generation, please see "Overview of Java documentation generation".
The "Reverse" set of parameters
Figure 168. The
"Reverse" set of parameters
|
The ... command |
internal name ... |
has the role of ... |
|
Classpath for the Reverse |
CompiledFilesPath |
The "Classpath for the Reverse" field is for entering the proposed default path that the compiled file reverse assistant will use when it is opened. This field is modified when the reverse is launched.. This string is made up of a list of paths separated by ":" for UNIX versions and ";" for Windows versions. These paths can be directories which have CLASSPATH semantics. They cannot, however, contain directories which correspond to Java packages. |
|
Application sources path |
SourceFilesPath |
The "Application sources path" field is for entering the proposed default path that the source file reverse assistant will use when it is opened. This field is modified when the reverse is launched. This string is made of a list of paths separated by
":" for UNIX versions, and ";" for Windows versions. They cannot, however, contain directories which correspond to Java packages. |
|
Paths for the .html files |
HTMLFilesPath |
containing the html file paths corresponding to the classes imported into the repository for visualizing their documentation. This string is made up of a list of paths separated
by ":" for the UNIX versions, and ";" for the Windows
versions. They cannot, however, contain directories which correspond to Java packages. |
|
Filter Accessors on Reverse |
AccessorFilter |
filtering accessors when a reverse operation is carried out. "Canonical" access operations (getXXX, setXXX) can be filtered during the reverse. Visibility is, however, retained. In round trip mode, this mode must be used systematically, except in certain particular cases. |
|
Automatically create diagrams on initial reverse |
DiagramCreationOn Reverse |
indicating whether or not diagrams should be automatically created when the initial reverse operation is carried out. Diagrams can also be created on subsequent request using the "Create Diagrams" command on packages. |
|
Add {JavaPublic} tagged value when public |
AddJavaPublicTagWhen Public |
automatically adding the {JavaPublic} tagged value, where the element is public. |
|
Convert abstract accessors into members |
FilterAbstractAccessor |
converting abstract accessors into attributes or associations of the class. |
|
Automatic reverse (only for Eclipse) |
autoReverse |
Automatically running the reverse in the context of an Eclipse project. |
Note 1: The reverse tool searches for the java source file in the directories indicated by the "Paths for the .java files" parameter. When more than one source file of the same name exists in these paths, the first file found is taken into account.
Note 2: .class file paths can be .zip files, .jar files or directories which have CLASSPATH semantics. For example, if you want to reverse class "C" of package "P", the C.class file is located in "...\class\P\C.class". However, CLASSPATH semantics are simply "...\class", and this is what should be defined for this parameter, instead of the full "...\class\P" path.
Note 3: For more information on reverse operations, please see "Overview of Java reverse".
The "Diagrams" set of parameters
Figure 169. The
"Diagrams" set of parameters
|
The ... parameter |
internal name ... |
indicates ... |
|
Red |
Red |
the red component of an element in a diagram. |
|
Green |
Green |
the green component of an element in a diagram. |
|
Blue |
Blue |
the blue component of an element in a diagram. |
Note: The values defined here are only applied when the "Automatically create diagrams on initial reverse" tickbox is checked in the "Reverse" set of Java Developer parameters (see Figure 168).
The "Patterns" set of parameters
Figure 170. The
"Patterns" set of parameters
|
The ... parameter |
internal name ... |
indicates ... |
|
Verbose mode |
VerboseMode |
the activation of traces during the running of the patterns. |
|
Reverse if necessary |
DoReverse |
whether or not a reverse operation should be run, where necessary. |
The
"Run" set of parameters
Figure 171. The
"Run" set of parameters
|
The ... parameter |
internal name ... |
indicates ... |
|
Application's parameters |
runParameters |
the default parameters for the application to be run. |
The "Eclipse" set of parameters
Figure 171-bis.
The "Eclipse" set of parameters
|
The ... parameter |
internal name ... |
indicates ... |
|
Name of the Eclipse project |
EclipseProject |
The name of the associated project in Eclipse. |
The "Model
components" set of parameters
Figure 173. The
"Model components" set of parameters
|
The ... parameter |
indicates ... |
|
Add Java source files in model component |
that you wish to include Java source files in a model component that you are packaging. |