Request for new rule in validation of composition usage

[toretrondsen]

I hope it is possible to add a rule to the validator checking that no element belonging to a composition belongs to another.

Example of illegal use of ccmposition for X

• A is composed of X
• B is composed of X

[jbsarrodie]

Example of illegal use of ccmposition for X

The issue is that this is not illegal.

If in your model your have a hierarchy A composed of B composed of C. Then by derivation A is also composed of C and you might want to model it explicitely. In such case C is composed into both A an B.

[Phillipus]

Further to JB's comment, if you have your own rules or style for models you could define them in a jArchi script and run it against your models. You could even design the script to make changes in accordance.

[jbsarrodie]

Just in case, here's jArchi code for that check:

$('element').filter(function(e) {
  return $(e).inRels('composition-relationship').size() > 1
}).each(function(e) {
  console.log("Illegal use of composition for " + e.name + " (" + e.type + ")")
})

[toretrondsen]

This is indeed an illegal use of composition. The example over is not derivation. X cannot be a part og borh A and B.

[jbsarrodie]

This is indeed an illegal use of composition. The example over is not derivation. X cannot be a part og borh A and B.

This is indeed a legal use of composition. Maybe an example will help: Europe is composed of France and France is itself composed of Paris. So Europe is (by derivation) composed of Paris.

[Phillipus]

I'm going to close this issue as the original request was:

...to add a rule to the validator checking that no element belonging to a composition belongs to another.

As JB has shown this can be a valid scenario, so I won't be adding this rule to the Validator.

@toretrondsen If you disagree with JB's explanation, as I said, you can write your own rule using jArchi, as described above.

[toretrondsen]

Your comments noted, but I still disagree on that this is a valid scenario, as presented above. When saying that this could be a valid scenario because of a (possible) derivation one are making assumptions on something that is not shown (and woulkd be in the model), that is that A must be a component of B, or vice versa. And if so, to follow your example of 'Paris' above, then one should not model it like this. That would be en example of bad practice. Now, I can see that one in some cases would do exactly that: to show the derived relationship in a view because the tool is not showing it (i.e. if only "Paris" and "Europe" are used in a view and 'France' omitted). To sum up: if the model does not contain a composition between A and B (either way), then a validator should not accept the example above. If a composition does exists it should at least warn the user about it, saying that one is trying to model a derived relation. I guess I will look into jArchi to solve this...

[jbsarrodie]

And if so, to follow your example of 'Paris' above, then one should not model it like this. That would be en example of bad practice.

This is only a convention on your side but not stated this way in ArchiMate standard which doesn't forbid multiple composition targeting the same element in the same model.

ArchiMate only says: Composition is a whole/part relationship that expresses an existence dependency: if a composite is deleted, its parts are (normally) deleted as well.

Nothing prevent an element from being dependent on the existence of multiple other elements: e.g. a Joint Venture no more exist when one or the other of its members disapears. One could says that both companies are composed on the Joint Venture.

And as derivations is also another frequent case, this shouldn't IMHO be considered a validation rule in Archi (and in any other tool FWIW).

[toretrondsen]

Well, I guess we can debate this for ever and it would always be subject for once own's convention... Let me quote Gerben Wierda from Mastering Archimate (p 24 Ed 3.1)

"The composition represents a whole-part relation. It is best to look at the ArchiMate version of this common relation as the relation between a tree (a real one from your garden, not the computational concept) and its branches. A branch is a branch of a single tree and cannot be a branch of multiple trees. If the tree is destroyed, all of its branches are destroyed as well."

So, you can "destroy" Paris but Europe still exists, not the other way around. And to take your last example, It depends! You could "destroy" a joint venture but the companies behind might still exist. Further more I would model this as a collaboration rather than a composition.

The diagram below illustrates. As you can see It does not make sense.

[Phillipus]

My 2 cents with regard to the original "Request for new rule".

Clearly, there will be disagreement on whether a rule is valid or not. I wish I had not added the Validator at all. :-) Perhaps best to take it out and users can create their own rules with jArchi. 😉

[toretrondsen]

We're using Archi with coArchi and not every submitter do follow conventions, which results in using a lot of time doing manual checking. I will certainly look into jArchi 👍 And the validator is fine, really - do not remove it 😃

[jbsarrodie]

So, you can "destroy" Paris but Europe still exists, not the other way around. And to take your last example, It depends! You could "destroy" a joint venture but the companies behind might still exist.

I never said it would be the way around: "destroy" Europe or France and Paris no more exists

Further more I would model this as a collaboration rather than a composition.

That would be of course another way of modelling it.

The diagram below illustrates. As you can see It does not make sense.

In fact, especially when modelling data, it could. ArchiMate has no notion of classe vs instance. So it would be perfectly valid to use Business Object for classes, and composition for what should be true at instance level. or in your example, nothing says that "A Branch" is not a generic concept (a class) and that "A tree" and "Another tree" are not "instances".

Here's a similar, valid view (assuming Phil and JB are uniq and Arm is, in intent, a class). Phil and I have arms, of course one arm is only mine or his, and If I die my arms die too:

Let me quote Gerben Wierda from his blog ;-) In his wish list for ArchiMate 3.0 he asked: Allow multi-parent Composition. And inside the Open Group ArchiMate Forum, while working on ArchiMate 3.0, we adreed on this and thus removed the restriction mentioned in ArchiMate 2.1: an object can be part of only one composition..

Well, I guess we can debate this for ever

Of course we could ;-)

and it would always be subject for once own's convention...

Exactly, and that's why I think such strict rule should not be implemented (and also why I do like using jArchi for such "data quality" rules)

[jbsarrodie]

Clearly, there will be disagreement on whether a rule is valid or not. I wish I had not added the Validator at all. :-) Perhaps best to take it out and users can create their own rules with jArchi. 😉

I wonder if it wouldn't be best to have the opportunity, when jArchi is installed, to extend the validator preference so that users can add their own rules (e.g. by pointing to a script file which implement a defined interface taking the object to validate as input and returning a status and a message). This would make it possible to enable custom validation rules and profit from the good Validator UI.