Structural vs. Functional use-Relations

In my last blog I talked about the semantics of permanent use-relations. In the meantime Micha had the idea not to differ between permanent and temporary relations but between structural and functional relations.

The idea remain the same. Some use-relations are important for the overall component structure and some are not. Let's have a look at some examples.

First of all, let's have a look at the following structure. Component owns Command owns Argument. But the Argument itself has a use-Relations to type. Imagine a function declaration f(int a, float b) where the argument a has a type int and b has type float. The relation of a method argument to its type is simply functional an will never appear as a relation in an UML diagram.


The second example show a meta-model which declares that components may extend/subclass other components. This relationship is clearly structural because it's important from the component's view. Just imagine the specialization relation in a UML diagram.


Quite special on the above relation is the fact that it's never necessary to name the role of the extends relation more specifically. Extends remains extends no matter what is extended.

The next example shows a meta-model for a component which has a collaboration relation to other components. The difference to the above design is that the collaboration relation has a role which has further information (i.e. at least a name.) For that reason the role has to be designed as an own class on the meta level called Collaborator in the subsequent example.





Let me give a résumé: First of all we distinguish structural and functional use-relation. As a rule of thumb only structural use-relations matters for the overall component structure.

Taking a closer look at structural use-relations one notice that there are relations with and without roles. If no role is needed the design is simple as seen above. If A extends B the extends relation between A and B needs no further information.


But if we do need to distinguish roles for a structural use-relation this role has to be modeled in a separate class providing at least a name. In the example below component A uses B1 as xAxis and B2 as yAxis. Note that xAxis and yAxis are instances of Collaborator.



It's quite interesting that the class Collaborator of the meta-model is visualized as a role in the instance-model. Since the decision if a structural use-relation needs a role or not is taken by the designer, we have to distinguish 3 different modes for use-relations:

• functional use-relation
• structural use-relation without a role
  
• structural use-relation with a role
  

If we specify the use-relation mode on the use relation it becomes possible to visualize components and their interdependencies soundly.

To conclude this blog let's think if this concept might work for a generic diagram editor which can visualize meta-model and model at the same time. For this reason let's have a look at the following simplified UML meta-model (which can be seen as meta-meta-model for our example).

• The type-relation from Argument to Class is a functional use-relation
  
• The extends relation from class to class is a structural use-relation without a role
• The type-relation from Member to Class is a structural use-relation with a role (Member play the role)
  

At the moment it seems to me that our concept can be applied to all types of models. And this would be greatly simplify the development of the diagram editor.