The purpose of operations is to implement the actual functionality of the domain.
Operations are used
You can specify the programming language convention to be used.
Renamings are provided to allow a form of overloading.
For classes, you must only have one operation with a given name, except for «entry»s and «renaming»s. It's allowed to have operations with the same name as generated subprograms (Create, Find and Delete), but you do need to ensure that the parameter profiles don't clash.
You can't overload operations of types at all.
Class operations (no This parameter will be generated) are marked by checking the ownerScope checkbox in the modifiers section of the ArgoUML Properties tab.
Dispatching operations (which must be instance operations) are marked by checking the isAbstract checkbox in the modifiers section of the ArgoUML Properties tab. The operation will be implemented in a child class.
Instance and class variables are private, regardless of what you say in the model. You can create accessor operations and you can mark them «accessor».
For an attribute Attr, an operation is a "set" accessor if it is a procedure named Set_Attr with a single parameter of the same type as Attr, and an operation is a "get" accessor if it is a function named Get_Attr with no parameters returning a value of the same type as Attr.
The "class-ness" of the attribute and the operation must match.
Operations to be called from the Domain Initialize procedure are marked with the stereotype «init» and will be treated as a class operations. These operations must be parameterless procedures.
Operations to be called to clean up as an instance is deleted (for example, to tidy up associations) are marked with the stereotype «finalize». (It would be possible in theory to use Ada's controlled types, but that depends on your target language being Ada). Also, it's possible to have more than one «finalize» operation.
Instance operations to be called during teardown (in unit test) are marked with the stereotype «teardown». It's possible to have more than one «teardown» operation; they'll be called in alphabetical order. These are intended to clean up resources such as file descriptors; don't try to tidy up associations, they're in an indeterminate state during teardown.
«finalize» operations can call «teardown»s, but «teardown» operations should not call «finalize» ones.
Usually, an operation used as a state machine action mustn't delete the instance. The Delete operation is specially recognised; if you need to make one of your own operations delete the instance, you must stereotype it «final».
A «final» operation should always delete the instance.
In an active class, you can specify task entries using the «entry» stereotype. It's permissible to have an ordinary operation with the same name as an «entry», because «entry» operations don't generate normal subprograms.
In a «protected» type, you can nominate procedures (operations without a return value) as entries using the «entry» stereotype.
The point about an entry of a protected type is that your implementation specifies a guard condition; callers of the entry block until the guard becomes open.
You can use the «convention» stereotype with the {language = language} tag to specify the programming language to be used..
You can use the «renaming» stereotype with the {renames=other-operation} tag to specify a form of overloading (ColdFrame's translation approach rules out actual overloading). Ada semantics apply (for example, you can change parameter defaults).
Operations stereotyped «convention» and tagged with a language (C, probably) will have
pragma Convention (operation, language);
Task entries map to entry specifications in the class's task specification.
Operations and entries of protected types map to operations and entries in the type specification (in the domain package specification) and in the type's separate proper body.
Accessors map to declarations in the class package specification. If marked «accessor», proper bodies are generated in the class package body; if not, body stubs are generated in the package body with separate proper bodies, like other operations except that you don't need to provide your own implementation unless necessary.
Other operations are generated as declarations in the appropriate package specification.
Bodies are normally generated as
However, it's possible (with some limitations) to specify the body's contents in the model.
Operations with returns (op():type-name in the model) are implemented as functions.
A parameter This : Handle; is automatically generated for non-class, non-«entry» operations of normal classes.
See separate notes on analyst-specified parameters.