different sets of Default Types

[ngong]

Why are the default types used for parameters and returns in operations different from those used with action pins and object-nodes?


The problem:
I used to explain an algorithm designed for an operations by one or a tree of activity diagrams. Traceability "by-name" requires to have action-pins or parameter-object-nodes in activity diagrams as of the same name and type as those used for the definition of the explained operation e.g. in an interface specification.

Many of these data flows are of simple types. I would like to use default types as to be quick in specifications. Taken the two different sets of default types, this is not possible. I got forbit to use default types for all designers.

Alternatively - and even better - I would like to populate the default types selection drop-down menu, in order to use my own set of base types.


Example using default types:

operation(par: int): boolean

(input) action-pin: Integer
(ouput) action-pin: Boolean

This can hardly be sold as traceability, at least it would be needless added complexity.

[Uffe]

Why are the default types used for parameters and returns in operations different from those used with action pins and object-nodes?

It looks like the action pin property dialog ignores the Language property, and do not populate the type dropdown with the set of types for the selected language, which the attribute and operation property dialogs do. The same appears to be true for activity parameters.

I agree that they should.

However, if you create the action as an instance of an activity, the pins' Argument properties are set correctly -- but the Type is unset. I haven't checked, but it's probably the same for other behaviors.

/Uffe

[ngong]

what about customizing the drop down list of default types?
this could also speed up the definition of parameters of operations of e.g. interfaces.
the project offers hundreds of types, but ~90% of parameter types are from a project-specific set of 10 or 20.

Currently I have to open the drop down of the type of the parameter, select "Select Type...", select "Search", type the beginning of the type name, press find, select the the type from the list. Imagine to do that for 50 operations with roughly 3 parameters each. Just to get "unit32_t" instead of "int" or "Integer".

[Uffe]

Hej Rolf,


I think I was wrong before, or maybe I was still looking at version 11. In 13.5 it's a bit better, though not quite there.

If you create an activity parameter, you must open the properties dialog for the parameter in order to access its Language property.
If you set it, the Type dropdown will contain the appropriate set of types -- but only if you open the dialog with the Language already set. If you change the Language and click Apply, the dropdown still contains the types from the old language.

For action pins, however, it still doesn't work. The Language property is not honoured.

But those are bugs. Using the Language property is the proper way to customize the set of available types, so provided the bugs are fixed you should be able to do what you want.

I've also checked, and the Language property is set correctly for activity parameters and action pins if you change the language with "Code Engineering -- Reset Options for This Package". That might help speed things up as far as activity parameters are concerned.

Operation parameters also obey the Language property (of the interface, there's no separate property for operations or their parameters).

HTH,


/Uffe