BOUML only manage class's operations and friend operations, not standard C or Php and Python functions (even it is possible to define a C, Php and Python function through an extra member or in an artifact definition etc ...). An operation may have a stereotype, but it does not have a special meaning for BOUML.
Contrarily to several UML toolbox, the body of the operations is fully managed by BOUML and saved among the project data (see project files). However you can also enter the bodies out of BOUML thanks to the option Preserve operations's bodies of the Language (see top level menu).
An operation is created through the class menu called from the browser or a class picture in a class diagram :
The icon in the browser indicate if the operation is public (+), protected (#) , private (-) or package (~). The protected and package visibilities are translated in private in Idl. The package visibility is translated in private in C++, and produce nothing in Php allowing you to generate Php 4 code. Note that BOUML doesn't check the validity of the (re)refinition of an inherited operation (for instance the visibility is not checked, the operation may be final in Java etc ...), but some operations are not part of the proposed operations list : the constructors, destructors, and the operations already defined in the current class for the UML point of view (the 'UML' definition of an operation is the one written under the browser window when the operation is selected in the browser).
The operation named __init__ has a special management in Python, it is used to place the initializations or the instance attributes and relations. The python generator add the definition of this operation when it doesn't exist.
A class operation is underlined, an abstract one is written in italic. It is possible to move an operation from a class into an other, except for the get and set operations associated to a relation or an attribute.
The operation menu appearing with a right mouse click on its representation in the browser is something like these, supposing it is not read-only nor deleted :
edit allows to show/modify the operation properties including the body. In case the operation is read-only, the fields of the dialog are also read-only.
The tab Uml is a global tab, independent of the language :
The name may contains spaces to define C++ operator for instance, and a class may have several operations having the same name. A class constructor have the name of its class.
The proposed type for the value type etc ... are the non class types defined in the first tab of the generation settings, more all the classes defined in the project (with their localization to distinguish synonymous classes). You are not limited to the proposed list, and any form (even invalid for the target language(s)) may be given. The button value type: shows a menu proposing :
if the current value type is a class : to select this class in the browser
if the operation is not read-only and if a class is selected in the browser : to set the value type to be this class
if the view containing the class containing the operation is not read-only : to create a new class and to set the return type to it
Nevertheless I strongly recommend you to not add type modifier (like *, & etc ...) with a class name in the UML tab because BOUML differentiate a reference to a class of the model and any other forms, see type considerations.
The proposed stereotypes are the default ones specified through the Default stereotypes dialog more the current one (empty here). It is possible to choose into the list or to give a new one, or to empty it. The stereotype of an operation does not have special meaning for BOUML.
The visibility may be chosen with the radio buttons, the operations have a default visibility set through the class settings :
Force body generation allows to generate the body of the operation even if preserve operations's body is set in the menu Languages. This option is used by the state machine generator to produce the body of the generated operations in all the cases.
The parameters have obviously a direction (but I known a commercial UML tool which does not manage it !), a name, a type (following the considerations about the return value type) and a default value (unfortunately this one is not yet managed by the code generators !). The last column (do) of the parameters table allows to insert/delete/move a parameter :
When you add/remove/modify a parameter:
if only one language is set through the global menu Language, the definition of the operation for this language is updated to take into account the change. However the changes are based on the defaults set through the generation settings, the default definition of the parameters can't be the expected one in all the cases and I encourage you to check them
else nothing is done, this allows you to have different parameters list depending on the target language in case of a multi languages generation
The exceptions produced by the operation may be specified (even for C++), these types follow the considerations about the return value type. The last column (do) of the exception table allows to insert/delete/move an exception.
By default the description is used to produce comments by the code generators.
The editor button visible above and associated here to the description, allows to edit the description in an other window, or to call an external editor (for instance Xcoral) specified through the environment dialog. Note that this external editor have to create an own window, its parameter is the pathname of the file containing the description, its execution is done in parallel with BOUML which looks each second at the file contents to get the new definition until the dialog is closed (I do not like very much this polling but this works even QT isn't compiled with the thread support).
The default button visible above associated to the description allows to set the description with a default contain specified through the generation settings. Useful to generate comments compatible Java Doc or Doxygen for instance.
This tab allows to give the C++ declaration and definition of the operation, it is visible only if C++ is set through the Language menu
In BOUML the generated code is obtained by the substitution of macros in a text, only the Declaration and Definition part are editable, the other one help you to see what will be generated for C++ (supposing you do not modify the C++ code generator !). You can see above that the definition doesn't contains the name of the parameters whose aren't used to avoid C++ compiler warnings.
When you push the button Default declaration or Default definition, the form specified through the generation settings is proposed adding all the operation parameters given in the UML tab without any modifier. These forms may be modified as you want, even to produce illegal source code, but more probably to add type modifiers etc ...
The buttons From definition and From declaration allow to produce the declaration/definition from the definition/declaration getting the specified list of parameters and return type definition. For instance if I modify the operation's declaration like this (the first parameter is modified and the second and third ones removed) :
and I press the From declaration button, the modifications are reported in the operation's definition :
When you do not want to have this operation defined in C++, empties the declaration/definition manually or using the button not generated in C++.
It is possible to follow the visibility as it is set in the UML Tab or to change it.
${static} produce an empty string when the operation is not an class operation (see the UML tab), else produce static
${const} produce an empty string when the check box const is not checked, else produce const
${volatile} produce an empty string when the check box volatile is not checked, else produce volatile
${friend} produce an empty string when the check box friend is not checked, else produce friend
${virtual} produce an empty string when the check box virtual is not checked, else produce virtual
${inline} produce an empty string when the check box inline is not checked, else produce inline
${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
${abstract} produce the string = 0 when the operation is abstract (see the UML tab), else an empty string.
${class} is replaced by the name of the class containing the operation.
${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.
${(} and ${)} produce ( and ), but there are also a mark for BOUML to find the parameters list
${t<n>}, ${p<n>} and ${v<n>} produce the type, name and default value of each parameter (count from 0), this allows you to remove a parameter, add type modifiers etc ...
${m<n>} produce the multiplicity of each parameter (count from 0), a priori used in a comment
${throw} is replaced by the form throw (...) when at least an exception is defined in the UML tab. It is also possible to produce throw() when there is no exception depending on the generation settings.
${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 or From declaration the body is not cleared ! At least BOUML share the declaration and definition forms of the operations (and other objects) to minimize the needed memory size, ${body} help for this ! When contextual body indent is toggled the indentation of the keyword ${body} is added to the indentation of the operation at the beginning of each line except the ones starting by a '#' or when the previous one ends by '\'. Since release 3.4 contextual body indent is not set when an operation is produced by a reverse to not alter the original indent.
The forms @{property} are replaced by the value of the corresponding user property if it is defined for the class or at an upper level, else it is not substituted.
A template operation is defined with an empty declaration (allowing Bouml to detect this case) and placing the actuals between ${class} and :: in the definition part.
The edit body button is active when the definition contains ${body}, to edit it through the editor you want use the environment dialog, furthermore, when you set add operation profile on body edition through the miscellaneous menu the form defining the operation in the editor is added at the beginning of the edited file.
This tab allows to give the Java definition of the operation, it is visible only if Java is set through the Language menu
In BOUML the generated code is obtained by the substitution of macros in a text, only the Definition part is editable, the other one help you to see what will be generated for Java (supposing you do not modify the Java code generator !).
When you push the button Default definition, the form specified through the generation settings is proposed adding all the operation parameters given in the UML tab. These forms may be modified as you want, even to produce illegal source code !
When you do not want to have this operation defined in Java, empties the definition manually or using the button not generated in Java.
${visibility} produce the visibility (see the UML tab)
${final} produce an empty string when the check box final is not checked, else produce 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), else an empty string.
${synchronized} produce an empty string when the check box synchronized is not checked, else produce 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, add type modifiers etc ...
${m<n>} produce the multiplicity of each parameter (count from 0), a priori used in a comment
${throws} is replaced by the form throw (...) when at least an exception is defined in the UML tab. It is also possible to produce throw() when there is no exception depending on the generation settings.
${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 ! When contextual body indent is toggled the indentation of the keyword ${body} is added to the indent of the operation at the beginning of each line. Since release 3.4 contextual body indent is not set when an operation is produced by a reverse to not alter the original indent.
${@} produces the annotations, when it is present in the definition the button Edit annotation is active, a specific dialog allows you to enter the annotations proposing the default annotations (Deprecated ...) and the ones defined through the classes stereotyped @interface :
The forms @{property} are replaced by the value of the corresponding user property if it is defined for the class or at an upper level, else it is not substituted.
The edit body button is active when the definition contains ${body}, to edit it through the editor you want use the environment dialog, furthermore, when you set add operation profile on body edition through the miscellaneous menu the form defining the operation in the editor is added at the beginning of the edited file.
This tab allows to give the Php definition of the operation, it is visible only if Php is set through the Language menu
In BOUML the generated code is obtained by the substitution of macros in a text, only the Definition part is editable, the other one help you to see what will be generated for Php (supposing you do not modify the Php code generator !).
When you push the button Default definition, the form specified through the generation settings is proposed adding all the operation parameters given in the UML tab. These forms may be modified as you want, even to produce illegal source code !
When you do not want to have this operation defined in Php, empties the definition manually or using the button not generated in Php.
${visibility} produce the visibility (see the UML tab), except if the visibility is package, use this case to generate Php 4 code
${final} produce an empty string when the check box final is not checked, else produce final
${static} produce an empty string when the operation is not a class operation (see the UML tab), else produce static
${abstract} produce abstract when the operation is abstract (see the UML tab), else an empty string.
${name} is replaced by the name of the operation.
${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
${(} and ${)} produce ( and ), but there are also a mark for BOUML to find the parameters list
${t<n>}, ${p<n>} and ${v<n>} produce the type, name and default value of each parameter (count from 0), this allows you to remove a parameter, add modifiers etc ...
${m<n>} produce the multiplicity of each parameter (count from 0), a priori used in a comment
${staticnl} produce a line break when the operation is static, else an empty string. Not used bu default, to add it change the generation settings to use 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 ! When contextual body indent is toggled the indentation of the keyword ${body} is added to the indent of the operation at the beginning of each line. Since release 3.4 contextual body indent is not set when an operation is produced by a reverse to not alter the original indent.
The forms @{property} are replaced by the value of the corresponding user property if it is defined for the class or at an upper level, else it is not substituted.
The edit body button is active when the definition contains ${body}, to edit it through the editor you want use the environment dialog, furthermore, when you set add operation profile on body edition through the miscellaneous menu the form defining the operation in the editor is added at the beginning of the edited file.
This tab allows to give the Python definition of the operation, it is visible only if Python is set through the Language menu
In BOUML the generated code is obtained by the substitution of macros in a text, only the Definition part is editable, the other one help you to see what will be generated for Python (supposing you do not modify the Python code generator !).
When you push the button Default definition, the form specified through the generation settings is proposed adding all the operation parameters given in the UML tab. These forms may be modified as you want, even to produce illegal source code !
When you do not want to have this operation defined in Python, empties the definition manually or using the button not generated in Python.
${@} produce the decorators, don't use decorator to produce @staticmethod and @abstractmethod, see ${static} and ${abstract} bellow
${static} produce @staticmethod followed by a newline if the method is declared static in the UML tab, else an empty string
${abstract} produce @abstractmethod followed by a newline if the method is declared abstract in the UML tab, else an empty string
${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>}, ${p<n>} and ${v<n>} produce the type, name and default value of each parameter (count from 0), this allows you to remove a parameter name, add modifiers etc ...
${m<n>} produce the multiplicity of each parameter (count from 0), a priori used in a comment
${type} produces the operation return type, if it is not empty the type generation is preceded by -> (ref. pep3107)
${multiplicity} is replaced by the multiplicity of the return type (see the UML tab), a priori used in a comment
${class} is replaced by the name of the class containing the operation.
${docstring} produce the description of the operation placed between ””” and followed by a new line if the description is not empty, else nothing is produced. If you prefer you can use ${comment} or ${description}
${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 ! When contextual body indent is toggled the needed indentation is added to the body (this mean at least the first line is not indented. Since release 3.4 contextual body indent is not set when an operation is produced by a reverse to not alter the original indent. In the special case of the __init__ operation the initialization of the instance attributes and relations is added before the body, they are not produced if ${body} is not part of the operation definition.
${association} in case the operation is a getter/setter on a relation produce the association (may be the class forming a class-association with the relation) set on the relation
${type} is replaced by the return type, a priori used in a comment, may be for a form @return
${multiplicity} is replaced by the multiplicity of the return type (see the UML tab), a priori used in a comment
The forms @{property} are replaced by the value of the corresponding user property if it is defined for the class or at an upper level, else it is not substituted.
The edit body button is active when the definition contains ${body}, to edit it through the editor you want use the environment dialog, furthermore, when you set add operation profile on body edition through the miscellaneous menu the form defining the operation in the editor is added at the beginning of the edited file.
This tab allows to give the Idl declaration of the operation, it is visible only if Idl is set through the Language menu
In BOUML the generated code is obtained by the substitution of macros in a text, only the Definition part is editable, the other one help you to see what will be generated for Java (supposing you do not modify the Java code generator !).
When you push the button Default definition, the form specified through the generation settings is proposed adding all the operation parameters given in the UML tab. These forms may be modified as you want, even to produce illegal source code !
When you do not want to have this operation defined in Java+, empties the definition manually or using the button not generated in Idl.
${oneway} produce an empty string when the check box oneway is not checked, else produce oneway
${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, add type modifiers etc ...
${m<n>} produce the multiplicity of each parameter (count from 0), a priori used in a comment
${raise} is replaced by the form raise (...) when at least an exception is defined in the UML tab.
${raisenl} produce a line break when the operation have exception, else an empty string. In case you do not like this notation, change the generation settings to remove this macro.
The forms @{property} are replaced by the value of the corresponding user property if it is defined for the class or at an upper level, else it is not substituted.
The menu entry duplicate clone the operation.
The menu entry delete is only present when the operation is not read-only.
Delete the operation, and all its representation in the diagrams. After that it is possible to undelete it (from the browser) until you close the project : obviously the deleted items are not saved !
See mark
Appears only when at least one plug-out is associated to the operations. To apply a plug-out on the operation.
This very important dialog allows to specify many default definitions concerning the operations, more details will be given in C++ generator, Java generator, Php generator and Idl generator.
The first tab allows to specify how the types not supported by an UML class are translated in each language except Php, and the default C++ argument passing for these types depending on the direction more the default type form to return value :
As usual the last column do allows to copy/past/cut/insert line and applies on the line where you did the mouse click.
The fourth C++ tab Stereotypes allows to specify the default declaration and definition of an operation (without the parameters), the default argument passing for an enumeration's item and an argument whose type is not one of the types defined in the first tab, and if a throw() must be generated when the operation does not have exception. They are visible only if C++ is set through the menu Languages
The second Java tab allows to set the default operation definition (without the parameters) in Java, it is visible only if Java is set through the menu Languages
The second Php tab allows to set the default operation definition (without the parameters) in Php, it is visible only if Php is set through the menu Languages
The second Python tab allows to set the default operation definition (without the parameters) in Python for standard operation and for the special case of the __init__ operation, it is visible only if Python is set through the menu Languages
The third Idl tab allows to set the default operation declaration in Idl, it is visible only if Idl is set through the menu Languages
The tab Description allows to set a default description :
The operations are drawn with their class in a class diagram, and alone in a sequence diagram or a collaboration diagram.
The way an operation is written or not in its class picture in a class diagram depend on the class drawing settings options drawing language, hide operation, show full members definition, member max width and show member visibility, and also on the class menu entry individual operation visibility.
For instance in a class diagram, the drawing language is UML, the full member definitions and visibility are shown, and the attributes are hidden :
changing the drawing language from UML (the default) to C++ :
changing the drawing language to Java :
Previous : attribute
Next : extra member