This is an open group. Sign in and click the "Join Group" button to become a group member and start posting.

Class Diagram III: Operation

In this post, I'll focus on the relation between Class and Operation. In addition I'll go through the inheritance chain of both metaclasses and see how this specializes the abstract concepts defined there.

I'll do the same for Properties in the next post.


Ownership and Namespace:

In short: A Class owns operations and namespaces them. In text based languages, this is clear if we write (x is the class and foo is the operation). LabVIEW follows this by placing them under the lvclass in the project explorer.

There is just one simple Association between Operation and Class that includes all information.


  • An operation may be owned by a class [0..1].

  • A class can have any number of ownedOperations

  • .

Operation as Feature of a Class:

  • The ownedOperation is subsetting Classifier::feature

  • in turn feature is subsetting the Namespace::member.

  • On the opposite of the association Operation::class subsets Feature::featuringClassifier

Class as Namespace for an Operation:

  • In addition ownedOperation is also subsetting Namespace:Smiley SurprisedwnedMember

  • in turn subsets the Namespace::member.

Luckily, due to the concept of a union, this won't lead to any issues counting the Operation double as member.

Importance of namespacing: it wasn't obvious to me at first, but it is important that Classes namespace their Operations. Otherwise you wouldn't be able to write an Operation of the same name in another Class.


The Associations related to redefinition are marked in blue except the Association between Class and Operation.

Operation is a subclass of RedefinableElement.

  • The property redefinedOperation subsets the property RedefinableElement::redefinableElement.

  • The property class subsets the property RedefinableElement::redefinitionContext of type classifier.

Multiplicity of Redefinition:

  • The uml specs allow that one redefinableElement redefines multiple other Elements. But it is suggested that they should conform by names (as well as parameters). This makes sense in the context of multiple inheritance, where the operations might clash from different ancesters.

  • An Element can be redefined in different specializations of the class it is defined.

A Copy-'n'-Paste form the uml specs:

Redefinition prevents inheritance of a redefined element into the redefinition context thereby making the name of the redefined element available for reuse, either for the redefining element, or for some other.

Inheritance summarized:

All operations are namespaced by the class they are introduced. When inherited, they get imported into the namespace of the child-class, if they are not redefined in the childclass.

I guess this will be dynamic dispatching, but I havn't found the details in the uml specs yet. Also, I didn't yet check for visibility, as a private operation wouldn't be available in child classes.

0 Kudos
Message 1 of 1
This is an open group. Sign in and click the "Join Group" button to become a group member and start posting.