ColdFrame: Parameters

Motivation

Operation parameters are modelled as just that, of course. The only things to note are

A parameter's mode may be

in (the default in ArgoUML)
the parameter represents a value; amongst other things, the actual can be an expression.
inout
the actual must be a variable; its original value is available to the operation, and the operation can update it.
out
the actual must be a variable; its original value is not available to the operation, and the operation can update it.

Modelling

The UML syntax for a parameter is

[mode] name : type [= default-value]

The mode and the default-value are optional.

The default-value can be an expression; ColdFrame doesn't apply any formatting.

ColdFrame provides the stereotype «not-null» to indicate that a parameter of an access type can't be null. ArgoUML doesn't allow this stereotype to be entered on the class diagram, nor does it display it; you have to apply it through the properties window.

Translation

If the mode is in it is omitted.

The language rules aren't checked by the code generator: for example, only an in parameter can have a default-value, and functions can't have in out or out parameters (this has changed in Ada 2012).

Use

As a matter of style, always name parameters from the point of view of the operation's caller, not from your point of view as implementer.

Try to make the names read well, especially if the caller uses named parameter association:

SNTP.User.Receive_Broadcasts_Via
  (The_Agent => Service,
   Reporting_To => S_Support.Receiver'Access);

Don't use long parameter names that repeat the type name. There is plenty of context available to the reader, and you make it more difficult than it need be to follow coding standards that ask for limits on line lengths.

Don't make a parameter inout just because it's large (a large record, perhaps, or an array). Trust the compiler (if Ada) or ColdFrame to do the Right Thing.