1

In short

I would like to model a covariant association between two classes, that can each be specialized. I need to show the specialization of the related association-classes. But I want to avoid that my model could mean that there are redundant associations (i.e. one between the generalizations and one between the specializations.

Step by step explanation of the problem

I have in an UML class diagram a many-many association between a Person and a Contract. A person can be involved in several contracts, and conversely a contract can involve several persons. Each involved person ins involved with a role in the contract. One person can even be involved multiple time with different roles in the same contract:

enter image description here

There are many kind of Contract specializations. Let's take a look at CompanyFoundationContract, where several persons decide to create a company. Person can also be specialized. Here I use a special kind of person called Founder. In practice, I prefer composition over inheritance, and the founder would be a decorator. But I'll omit this detail later for the sake of simplification:
enter image description here

From the UML specialization, I know that Founder and CompanyFoundationContract inherit the many-to-many relation. But after discussion with my users of the legal practice, It soon appears that the Role of a Founder in a CompanyFoundationContract needs to be specialized as well, to takie into account for example the shares held in the company. It seems simple to model this covariance in my class diagram:

enter image description here

At first sight, this model can represent the legal complexity of such contracts: it seems obvious that other persons that are not founders can be involved in the contract with a normal role (e.g. the notray or attorney who registers the company).

Since the association-class ShareHolderRole is a specialization of the Role association-class, I'd expect to clear that it's one and the same association between Contract and Person and between CompanyFoundationContract and Founder.

However, I am worried that I missed something and that interpreting UML strictly would imply to have two different and redundant associations. How shall I model accurately the fact that there is only one association, but a covariant association-class?

Christophe
  • 68,716
  • 7
  • 72
  • 138

4 Answers4

2

Preliminary remark: First I'd like to than Bruno and Axel for their respective answers, that put me on the right track. Nevertheless digging further based on their indications, I stumble accross an even simpler solution and supporting references. As it's useful and following Bruno's suggestion I've finally decided to post it as ananswer.

Can simple associations be specialized?

In my question, I considered the case of an association class, because I thought that only classes could be specialized. But in fact, simple associations can be generalized as well.

First of all, an association is itself a already a classisifier according to UML 2.5:

Section 11.5.1: An Association classifies a set of tuples representing links between typed instances. An AssociationClass is both an Association and a Class.

A classifier can be specialized:

Section 9.2.3.2: Generalizations define generalization/specialization relationships between Classifiers.

The notation is as follows (I spare you the specs details, and I must admit that 2 weeks ago I would have claimed "nonsense" if I'd have seen this):

enter image description here

What does association specialization mean?

The semantics for associations specialization are well defined (highlights from me:

Section 11.5.3.1 (p.198): (...) In the case of Associations, specialization means that a link classified by the specializing Association is also classified by the specialized Association. Semantically this implies that sets calculated by eliminating duplicates from the collections representing the ends of the specializing Association are subsets of the corresponding sets calculated by eliminating duplicates from collections representing the ends of the specialized Association; this fact of subsetting may or may not be explicitly declared in a model.

So, without telling anything about the association ends, the specialization implies that the spcializing association is a subset of the general association. Explicit subsetting is optional:

enter image description here

And what about association classes?

Association classes are both, an association and a class. The UML specifications clarify that both are classifiers and that the properties of the metamodel are not dubplicated. So it's one and the same. The specialization applies to both at the same time:

Section 11.5.3.2:(...) the specialization and refinement rules defined for Class and Association are also applicable to AssociationClass.

Important remark: an association can generalize another association, an association class can generalize an association class, but "an AssociationClass cannot be a generalization of an Association or a Class" ), and the way we generally understand this is not valid:

enter image description here

Conclusion

When taking rigorously the UML specifications, it appears that my diagram with the simple specialization between the association classes, is correct, unambiguous and expresses the intented semantic. Alex's answer proposed to explicitly declare the implied subsetting: this is valid, but it is not required.

enter image description here

Note that there is a subtle difference: the generalization/specialization are about the association itself, whereas the subsetting is about the association ends.

Additional insights:

Christophe
  • 68,716
  • 7
  • 72
  • 138
1

(you have a typo in your diagram using Founders)

I'd expect to clear that it's one and the same association between Contract and Person and between CompanyFoundationContract and Founder

not for me, else that means it is not possible to have that association as an additional one but of course this is possible

if you want to make that clear add the name of the association ends and use the same couple of names :

enter image description here

you can also explicitly say each association end redefines the other, allowing to use different names :

enter image description here

or of course you can do in the same way I do in the 'source' answer :

enter image description here

where the constraints in blue concern the relation-class rather than just the corresponding classes, and the constraints in green are not mandatory because they can be deduced from the constraints in blue

bruno
  • 32,421
  • 7
  • 25
  • 37
  • Thank you Bruno for this extremely comprehensive question. Indeed, the names on the ends make it less ambiguous, and the `{redefines}` adresses well the covariance and the change of type. However, I have a last doubt. My intention was to specialize only the association between `Founder` and `CompanyFoundationContract`, but still allow the `Founder` to be associated with a normal (non redefined) contract (e.g. a mortgage to invest in shares), and a `CompanyFoundationContract`with a normal `Person` (e.g. the notary in charge of the contract). Would this be possible with the `{redefine}`? – Christophe Jul 19 '20 at 22:25
  • Because I have the impression that `{redefine}` changes the definition of the associated class by restricting it to the redeclared value, thus excluding the siultaneous use of the gereral association. (I'm lokking for a modelling that would allow me the same generalisation:specialization semantic as C++ templates: if I'm in the specific case, I'd like the specific association class, but if I'm not in the specific case, the general case is sitll possible.) – Christophe Jul 19 '20 at 22:29
  • 1
    @Christophe `... but still allow the Founder to be associated with a normal (non redefined) contract (e.g. a mortgage to invest in shares), and a CompanyFoundationContractwith a normal Person (e.g. the notary in charge of the contract).` you can have that with your second diagram but for me not with your third, nor with all my diagrams because my starting point is your third diagram – bruno Jul 20 '20 at 15:43
  • ok. Thanks. So it would be a variant of your third diagram with some more relaxed constraints (i.e. only the blue one for ShareHolderRole to say that this specialization is only possible for a Founder and a CompanyFoundationContract. ) – Christophe Jul 20 '20 at 16:51
  • 1
    @Christophe yes, exactely – bruno Jul 20 '20 at 16:52
  • Using the same name doesn't have any meaning. They are still different attributes. You have to explicitly redefine attributes to, well, redefine them. Only the notation allows to omit the `{redefine}`, if the redefined attribute has the same name. – Axel Scheithauer Jul 27 '20 at 19:30
  • 1
    @bruno After having read Axel’s contribution, I came to the conclusion that his proposal allows to express what I wanted in a simpler manner. I therefore marked his answer as the solution and hope you’ll understand. Of course, the upvote remains, since you provided in a very comprehensive way many useful suggestions, and in my view also a valid alternative in the comments. – Christophe Jul 30 '20 at 11:24
  • @bruno After having done some more research on the {subset}, I found [this article](https://upcommons.upc.edu/bitstream/handle/2117/9652/RedefinesSpecializationSubsettingExtendedVersion.pdf?sequence=1&isAllowed=y) that looks at the problem not from the angle of the association ends but at the association itself. Its depth of analysis of the UML specs is fascinating. I'm not sure, but it seems to say that the inheritance between associations is enough to get the semantics I expected. Would section IV and VI thereof make you reconsider some elements of your answer? – Christophe Aug 10 '20 at 00:43
  • @Christophe may be write your own answer ? – bruno Aug 10 '20 at 04:38
  • @Bruno thank you for the suggestion. After careful analysis (back to the roots!) I think it could indeed be a good idea to share the findings. Done :-) COuld you have a critical look at it? – Christophe Aug 14 '20 at 19:28
1

A specialized association class is not restricted to connect only redefined attributes. So, it is perfectly possible, that this association class connects founder and foundationContract, and those attributes have nothing to do with person and contract (except that their types are specializations). If you however do redefine them, then these new attributes (which even could have the same name) replace the old attributes, making it impossible for a founder to have non foundation contracts.

Now, a foundation contract is still a contract. Therefore, the list of contracts a person is involved in, should contain them. This can be achieved with subsetting. Just define, that a foundationContract {subsets contract} and founder {subsets person}. I think, this is what you really wanted.

Since attributes are per default sets, and "set" means, they don't contain duplicates, it is not possible for the same person to play multiple roles in the same contract. If you want this to be possible, you have to set the property {nonunique} for the attributes.

Axel Scheithauer
  • 2,758
  • 5
  • 13
  • Oho! This seems very interesting. I always viewed subsetting as a kind of relaxed redefining. So if I understand well, your proposal would graphically look like Bruno’s second diagram but using subsetting instead of redefinition. And from the semantic: this would make the specialized association applicable only for members of the subset while at the same time the general association remains valid for members that do not belong to the subset? – Christophe Jul 27 '20 at 19:29
  • Yes, that's what it would look like and what it means. – Axel Scheithauer Jul 27 '20 at 19:34
  • you made my day! Do you have by any chance a quote of the 2.5 specs that back this understanding? (sorry, I would normally look by myself, but on holiday with limited internet access :-/) – Christophe Jul 27 '20 at 19:38
  • UML 2.5: A Property may be marked as the subset of another subsettedProperty. In this case, calculate a set by eliminating duplicates from the collection of values denoted by the subsetting property in some context. Then that set shall be included in (or the same as) a set calculated by eliminating duplicates from the collection of values denoted by the subsettedProperty in the same context. – Axel Scheithauer Jul 28 '20 at 09:35
  • This means, that all user defined operations are required to add any element of `foundationContract` also to `Contract`. Users could screw this up. You can automate this by defining `/contract {derived union}`. Then of course also `nonFoundationContract` must be a subset. – Axel Scheithauer Jul 28 '20 at 09:38
  • Thanks for your insights. I marked your answer as the solution, since the result is what I’m looking for and is very expressive once one gets acquainted with subsets. Now looking for arguments in favor of this solution, I stumbled across [this article](https://upcommons.upc.edu/bitstream/handle/2117/9652/RedefinesSpecializationSubsettingExtendedVersion.pdf?sequence=1&isAllowed=y) that looks at the problem not from the angle of the association ends but at the association itself. Would section IV and VI thereof make you reconsider some elements of your answer? – Christophe Jul 30 '20 at 11:37
  • Dear Alex, any feedback on my previous comment? – Christophe Aug 10 '20 at 00:45
0

"One person can even be involved multiple time with different roles in the same contract" - Role should not be binary, but ternary association between Person, Contract and RoleType.

user6580165
  • 49
  • 3
  • 1
    Thank you for this interesting remark. You are fully right: whenever an association class is itself associated with another class, we could model this as a ternary association. But I think it's an option and not mandatory requirement. Now, suppose i'd go for a ternary association: how would this allow me to solve the issue ? – Christophe Jul 19 '20 at 22:13