As a side note: I skip discussing Expressions and Constraints, as there is almost no change to Abstractions.
They are derived from TypedElement and MultiplicityElement. To me this now seems obvious, as I want them to have a type (e.g. integer) and I also would like to use arrays.
They even can have a default value.
The direction complies with other text languages i have encountered: return, in, inOut, out.
In Basics it is derived from TypedElement and MultiplicityElement; in Constructs from Namespace and Feature. The attributes of the MultiplicityElement (isOrdered, ...) are redefined to be derived from the return Parameter (which is a MultiplicityElement).
Each error is modelled by a Type object. The abstract class BehavioralFeature defines an association 'raisedExceptions'.
This is redefined by the operation class, also I don't see any variation.
Raised Exceptions have no notation in the uml diagram.
I don't really catch the use case, so I ignore this feature in it's full complexity.
Some inconsistency when redefining the ownedParameters, it's not written in the text (but in the Superstructure). Also the navigational arrow is missing. Also I don't get the reason for the redefinition, the only guess is that the other end of the association is now named 'operation'.
Only one parameter of kind return is allowed, which defines the Type and the Multiplicity attributes.
I didn't draw it on my uml diagram, but there is also an association redefinedOperation. An Operation is a RedefinableElement (super-class of feature). I still don't grasp the complete concept of redefinition.
This is mentioned in the text, but the attribute feature::isStatic is introduced in the superstructure.
An operation natively relates to our basic element in LabVIEW: the (Sub)VI. I'll need to think further from this point, so just a small set of notes:
I miss an option in uml to make a parameter required (like if I don't define a default value). This has proven to be a useful feature in LabVIEW.
Me too. One thing I've done is define a series of stereotypes in a LabVIEW profile diagram which allow me to tag methods (member VIs) as <<Property>>, <<Dynamic>>, etc. This has proved useful as well, and after doing this I'm convinced there's a way to futher extend the paramter list such that additional qualifiers can be specified using the profile diagram. I specifically want to be able to qualify required, recommended, optional. The problem is the documentation is so verbose and specific, that I'm having a tough time even finding where to begin...
I did play with eclipse/papyrus today. I created a profile with an enum (required, recommended, optional). Then I imported the metaclass Parameter and Extended it through a Sterotype LVParam with the property ConPaneKind of type of above enum.
In my test project I could apply the profile to the package, create inside the package->Class->Operation->Parameter. Then I could apply the sterotype to the parameter, it even displayed the enum nicely.
But sadly, nothing showing on the diagram.