Inferred UML elements

[Paolo F Cantoni]

In a recent topic: [size=13]Everything should be derivable[/size] I suggested that it would not be too far beyond the current UML specification to make everything (possibly) derivable.

In this topic I want to discuss a related topic.  That of inferred UMLElements.

Taking strict UML (for the moment), a UMLAssociation can be marked as derived (as Sparxian Ashely King points out, by using the isDerived Custom Property of the EAAssociation).

So what does a derived association mean?  Well, say we have a class OrganizationalUnit and another class Worker.  Each Worker is assigned to an OrganizationalUnit  (in functional notation assignedToOrganizationalUnit(worker) describes the association).  In addition, each OrganizationalUnit has a Worker designated as manager (in functional notation managerOf(organizationalUnit) is the association).  Now, it is often the case that we want to determine the manager of the Worker.  Normally, the Worker's manager is the manager of the OrganizationalUnit the Worker is assigned to.  In functional notation this would be: managerOf(worker).  However as we have just described, the value of managerOf(worker) is not arbitrary.  It is, in fact, managerOf(assignedToOrganizationalUnit(worker)).  Thus we can state that managerOf(worker) is derived by traversal of managerOf(assignedToOrganizationalUnit(worker)).

So now I've described three associations; two are canonical and one is derived.

The [size=13]UML 2.1 Superstructure (interim)[/size] Specification defines isDerived as: Specifies whether the Property is derived, i.e., whether its value or values can be computed from other information. The default value is false.

If I decide to implement the managerOf(worker) association, then I have a derived association.  But supposing I don't want to implement the association, but I'd still like to show it in the model (more specifically on diagrams) so as to aid understanding.  How do I tell an implementable derived association from one one I don't intend to implement?

The solution we've come up with is to mark it as inferred.  Inferred relationships have many uses.  For example, we might have a series of traversals via a set of CORBA interfaces and methods between a class in one component with a class in another component.  To put the full complexity every time on a diagram would quickly make them unmanageable.  Yet, placing only one link of the path doesn't come near telling enough of the story.  

To solve this problem, on the diagram we place an «inferred» relationship between the source class and the target component.  In diagram for the other side, we do the reverse.  A third diagram shows the full traversal (and the relationship of the «inferred» relationships to the others).

Inferred relationships allow the creation of multi-level views and (as we have just seen cross-level relationships).  They are useful summarising and abstraction mechanisms.

In a similar way, we can talk about inferred classifiers.  Typical uses are a classifier in a state.  You can create a specialisation of the classifier with the state as part of the name.  Thus PaidOrder is an inferred specialization of Order.  You can attach the specialized forms of the associations that only apply to PaidOrders and visually see the differences.  Naturally, these associations will be inferred versions of the Order associations.

As suggested above, we currently use «inferred» stereotypes for this purpose, but we feel a proper property would be much better.  It would be really neat if the property also set the rendering (like isDerived sets the "/" prefix).  isInferred might set the prefix "\" or "(/)" or some other distinction.

Thoughts?  Votes?
Paolo

[size=0]©2006 Paolo Cantoni, -Semantica-[/size]

[Jan van Mastbergen]

Hi Paolo,

Whether you need a model element property <<inferred>> in addition to <<derived>> depends on the purpose of the model you are building. If it is a PIM (a logical/platform independent model like the ones I make at work) with no direct relationship to application code then there is no need for anything beyond <<derived>>.
If your model is platform specific (PSM), intended to be transformed into code, it is already some explicit derivation of the logical view on information. The same <<derived>> property in that model can then be interpreted to control code generation.  

The dilemma starts imho when you are trying to combine both purposes into one model. The PIM always represents a sort of 'ideal' with respect to its realization in physical systems. The PSM's are non-trivial derivatives because they represent the compromises with technical possibilities, the quirks of the organization's etc.
It may be worthwhile to try to separate these two purposes into different models, which would make the compromises explicit. You can use the realization link to indicate the mapping between business objects and the implementation objects.

There will of course be redundancy between the two models. This means duplicate work but if the correspondence is exact, you can refer to classes from the logical model instead of copying and modifying them.

Regards, Jan

[Paolo F Cantoni]

Hi Paolo,

Whether you need a model element property <<inferred>> in addition to <<derived>> depends on the purpose of the model you are building. If it is a PIM (a logical/platform independent model like the ones I make at work) with no direct relationship to application code then there is no need for anything beyond <<derived>>.
If your model is platform specific (PSM), intended to be transformed into code, it is already some explicit derivation of the logical view on information. The same <<derived>> property in that model can then be interpreted to control code generation.

Hi Jan,
Well, not withstanding that model levels above PSM have no direct relationship with any specific platform, my comments relating to inferred items don't only relate to generation.  The non-generation of inferred is actually a consequence in the PSM.  However, in an expository sense, inferred items are useful in the higher levels also.  I first started using them in CIM level models.

The dilemma starts IMHO when you are trying to combine both purposes into one model. The PIM always represents a sort of 'ideal' with respect to its realization in physical systems. The PSMs are non-trivial derivatives because they represent the compromises with technical possibilities, the quirks of the organization's etc.
It may be worthwhile to try to separate these two purposes into different models, which would make the compromises explicit. You can use the realization link to indicate the mapping between business objects and the implementation objects.

There will of course be redundancy between the two models. This means duplicate work but if the correspondence is exact, you can refer to classes from the logical model instead of copying and modifying them.

Regards, Jan

I first got interested in inferred items over twenty five years ago, after attending a lecture by James Marting (the then Database guru) on Canonical design of Databases.  It seems to me that in any universe of discourse, you can define a set of canonical items.  The decision as to whether the remainder are derived or inferred, rests with the behavioural aspects of the model (as opposed to the structural).  If the item is traversed or referenced in the course of the execution of a behavioural item, then the item under discussion is marked as derived, otherwise if it is useful to show the item on the model, it is marked inferred.

Paolo

[size=0]©2006 Paolo Cantoni, -Semantica-[/size]

[Jan van Mastbergen]

Paolo,

I can see your point about the use of the <inferred> property to tag elements that exist for explanatory purposes only. It makes me wonder if a single boolean property is enough then.
In every day work the model repository holds the truth in painstaking detail but diagrams are often used as a tactical weapon: you tune them to the viewpoint of your discussion partner and show only the aspects that seem relevant to the subject at hand. So, the more you discuss your models the more diagram variants you will want to produce.
At the repository level there is still the single choice whether a model element is canonical or derived.
At the tactical diagram level there are as many choices as there are viewers/viewpoints of your model. A binary property as <inferred> would not be enough to distinguish between them.
It seems to require something like the instantiation of viewpoint specific diagrams/reports from a parameterised version.

Jan

[«Midnight»]

Hey Paolo,

Just to help me get my head around this, are [inferred] and [derived] different properties, or a (possibly incomplete) set of values for one property. It seems to me - and I could be wrong here - that an element could be inferred, or it could be derived, but it cannot be both inferred and derived. [Perhaps it could be neither though; canonical elements might be an example.]

Essentially, I'm asking if we have multiple

• properties, a single
• property, or some kind of 'SomethingKind.' [If you can read this sentence aloud without adverse physical effects, you can list "OMG" on your resume as a spoken language.]
  
  The first option would be along the lines of [isLeaf] and [isRoot]. Both would default to No to preserve work to date.
  
  The enumeration option would need to be optional (a bit messy, but it won't break work to date) or have some appropriate (and benign) default.
  
  David

[Paolo F Cantoni]

Each item can be in one of three states:
Canonical, Derived, Inferred.

Inferred => Derived => ¬Canonical

Thus all Inferred items are, by definition, Derived.  Not all Derived are Inferred.

A Canonical item is neither Derived nor Inferred.

Each diagram shows whatever it needs to show to explain whatever it attempts to explain.

In the twenty-odd (and some have been very odd  ) years of modelling, I've managed to need only these three states.  But I'm open to suggestions...  

Paolo