The Java code generator is a plug-out directly written in C++.
The generated sources follows the definition made in BOUML at the artifact / class / operation / relation / attribute / extra member levels.
When the code generation is applied on a artifact associated to several classes, the code generation is made for all these classes. Nevertheless the the Java code generator produce first the code in memory and update the appropriate files only when it is necessary, to not change the last write date of the files for nothing. Depending on the toggle verbose code generation of the global menu Languages the code generator is verbose or not.
The Java code generator plug-out may be called on :
a class : in this case the code generation is in fact applied on the class's artifact, then on all the classes associated to this artifact
a artifact : in this case the code generation is in fact applied on all the classes associated to the artifact
a class view : the code generation will be applied on all the sub classes, then on all the artifacts associated to these classes
a deployment view : the code generation is applied on all the sub artifacts
a package (may be the project itself) : the code generation will be applied on all the sub class views and deployment views, then on all their sub classes and artifacts.
When the Java code generator is ask through the Tools menu, it is applied on the project, then on all the artifacts.
The name of the generated files depend on the artifact name, the extension depend on the language and is fixed for each by the generations settings (see below), the directory where the files are generated may be set in each package containing directly or indirectly the artifact (see generation directory).
The Java definition of a artifact is set through the Java source tabs of the artifact dialog.
The code generation depend on the stereotype of the artifact :
text : the Java definition of the artifact is produced without changes, the name of the generated file is the name of the artifact, including the extension.
source : see below.
else nothing is generated for the artifact.
The generated file name is the artifact's name with the extension specified in the first Java tab of the generations settings :
In BOUML the generated code is obtained by the substitution of macros in a text, the macros known by the Java code generator are :
${NAME} produce the artifact name capitalized, ${Name} produce the artifact name with the first letter capitalized, ${nAME} produce the artifact name forced in lowercase, at least ${name} produce the artifact name without modification.
${comment} is replaced by the artifact description adding /* */
${description} is replaced by the artifact description without adding /* */
${package} is replaced by the package xx forms, dependent on the package specifications associated to the BOUML package containing the deployment view where the artifact is defined.
${import} is replaced by import forms specified by dependencies stereotypes import from classes produced by the artifact to classes or packages.
${definition} is replaced by the definition of the classes and extra artifact definitions associated to the artifact.
@{xyz} is replaced by the user property value in case xyz is the key of this property. The property if searched first for the artifact, if not found for the deployment view containing the artifact, if not found in the package containing the deployment view etc ...
The Java definition of a class is set through the Uml, Parametrized, Instantiate and Java tabs of the class dialog.
A Java type definition may be a class, an interface or an enum (may be defined through a class), depending on the stereotype and its translation in Java (see generation settings).
In BOUML the generated code is obtained by the substitution of macros in a text, the macros known by the Java code generator are :
${comment} is replaced by the description of the class adding /* */
${description} is replaced by the class description without adding /* */
${public} produce public when the class is declared public
${final} produce final when the class is declared final
${abstract} produce abstract when the class is abstract
${name} is replaced by the class's name
${extend} is replaced by the class inheritance
${implement} is replaced by the interface inheritance
${members} is replaced by the code generated for all the class's members (relations, attributes, operations and extra members) following the browser order.
${cases} only for the enums, is replaced by the enum's items definition
@{xyz} is replaced by the user property value in case xyz is the key of this property. The property if searched first for the class, if not found for the container of the class (an other class of a class view) etc ...
In the special case where the class is declared external, its Java type declaration must contains a line indicating how the name of the class is generated, by default ${name} meaning that the name is produced unchanged, the only allowed keywords are ${name}, ${Name} and ${NAME}.
The Java definition of an operation is set through the Uml and Java tabs of the operation dialog.
The indentation of the first line of the declaration/definition give the indentation added to the class definition for all the operation definition.
In BOUML the generated code is obtained by the substitution of macros in a text, the macros known by the Java code generator are :
${comment} is replaced by the description of the operation adding /* */
${description} is replaced by the operation description without adding /* */
${visibility} produce the visibility (see the UML tab)
${final} produce final when ye operation is specified final
${static} produce static when the operation is a class operation (see the UML tab), default in an interface when the check box default is checked, else an empty string
${abstract} produce abstract when the operation is abstract (see the UML tab)
${synchronized} produce synchronized when the operation is synchronized
${type} is replaced by the value type (see the UML tab)
${multiplicity} is replaced by the multiplicity of the return type (see the UML tab), a priori used in a comment
${name} is replaced by the name of the operation.
${(} and ${)} produce ( and ), but there are also a mark for BOUML to find the parameters list
${t<n>} and ${p<n>} produce the type and the name of each parameter (count from 0), this allows you to remove a parameter, etc ...
${m<n>} produce the multiplicity of each parameter (count from 0), a priori used in a comment
${throws} is replaced by the form throws ... when at least an exception is defined in the UML tab.
${staticnl} produce a line break when the operation is static, else an empty string. In case you do not like this notation, change the generation settings to remove this macro.
${body} is replaced by the body of the operation, this macro may also be replaced by the body itself (BOUML use this way for the get and set operations associated to a relation/attribute). The usage of ${body} has a great advantage : when you hit Default definition the body is not cleared ! At least BOUML share the definition forms of the operations (and other objects) to minimize the needed memory size, ${body} help for this ! The indentation of the keyword ${body} is added at the beginning of each line.
@{xyz} is replaced by the user property value in case xyz is the key of this property. The property if searched first for the operation, if not found for the class containing the operation etc ...If the toggle preserve operations's body is set through the Languages menu, the generators do not modify the body of the operations protected by dedicated delimiters. This means that for them the body definition set through BOUML is not used. The first time you generate the code with the toggle set, because the delimiters are not yet present in the generated code, the operation's body will be updated depending on their definition under BOUML. After, while the toggle is set and the delimiters present, the bodies will not change, allowing you to modify them out of BOUML.
Notes :
In case the file containing a body definition is not consistent with the artifact under BOUML, the body will be regenerated by the code generation, using its definition under the model.
When you import a project, the body of the imported operations must be the right one in the imported model. The preserved bodies of the imported operations will not be find because the identifier of an operation used to mark its body changes during the import.
The bodies under the model are not updated by the code generation, use roundtrip body for that
Only the operations using the keyword ${body} may have a preserved body.
The only modification you can do in the lines containing the delimiters is the indent.
The toggle is saved in the file associated to the project, be sure the save is done when you change this toggle !
The Java definition of an attribute is set through the Uml and Java tabs of the attribute dialog.
The indentation of the first line of the definition give the indentation added to the class definition for all the attribute definition.
An attribute may be a standard attribute or the item of an enumeration defined through a class.
In BOUML the generated code is obtained by the substitution of macros in a text, the macros known by the Java code generator are :
${comment} is replaced by the description of the attribute adding /* */
${description} is replaced by the attribute description without adding /* */
${visibility} produce the visibility (see the UML tab)
${static} produce static when the attribute is a class attribute (see the UML tab)
${final} produce final when the attribute is final
${transient} produce transient when the attribute is transient
${volatile} produce volatile when the operation is volatile
${type} is replaced by the type of the attribute (see the UML tab)
${stereotype} is replaced by the translation in Java of the relation's stereotype (see the UML tab)
${multiplicity} is replaced by the multiplicity of the relation (see the UML tab), must be used in case the multiplicity is a vector or array dimensioning ([ and ] are added when they are not present).
${name} is replaced by the attribute's name (see the UML tab)
${value} is replaced by the initial value of the attribute (see the UML tab)
@{xyz} is replaced by the user property value in case xyz is the key of this property. The property if searched first for the attribute, if not found for the class containing the attribute etc ...
The macros known by the Java code generator are :
${comment} is replaced by the description of the item adding /* */
${description} is replaced by the item description without adding /* */
${name} is replaced by the item's name (see the UML tab)
${class} is replaced by the name of the class supporting the enumeration
@{xyz} is replaced by the user property value in case xyz is the key of this property. The property if searched first for the attribute, if not found for the class containing the attribute etc ...
The Java definition of a relation is set through the Uml and Java tabs of the relation dialog.
The indentation of the first line of the definition give the indentation added to the class definition for all the relation definition.
In BOUML the generated code is obtained by the substitution of macros in a text, the macros known by the Java code generator are :
${comment} is replaced by the description of the attribute adding /* */
${description} is replaced by the attribute description without adding /* */
${visibility} produce the visibility (see the UML tab)
${static} produce static when the attribute is a class attribute (see the UML tab)
${final} produce final when the attribute is final
${transient} produce transient when the attribute is transient
${volatile} produce volatile when the operation is volatile
${type} is replaced by the name of the class pointed by the relation (see the UML tab)
${name} is replaced by the role's name (see the UML tab)
${inverse_name} is replaced by the name of the inverse role (see the UML tab)
${value} is replaced by the initial value of the relation (see the UML tab)
${stereotype} is replaced by the translation in Java of the relation's stereotype (see the UML tab)
${multiplicity} is replaced by the multiplicity of the relation (see the UML tab), must be used in case the multiplicity is a vector or array dimensioning ([ and ] are added when they are not present).
${association} is replaced by the association class (see UML tab)
@{xyz} is replaced by the user property value in case xyz is the key of this property. The property if searched first for the relation, if not found for the class containing the relation etc ...
The class inheritance are managed at the class level.
${type} is replaced by the name of the inherited class more the actuals if the generated class instantiate a generic.
The Java definition of an extra member is set through the Java tabs of the extra member dialog.
No macros.
Previous : C generator
Next : Java reverse