Generalization and inheritance of relationships in UML

[John Bromell]

Hi all,

I'm new to this group and would like to ask a simple question for which I have so far found no definitive answer: In UML, does a specialized class inherit the relationships of the generalized class with which it has a generalization relationship?

As an example, suppose I have a use case X with specialized use cases a, b and c linked to it, and X has a <<realize>> relation to a requirement, R. Do use cases a, b, and c inherit the relationship to requirement R? Does it depend on the value of the generalization relationships' isSubstitutable attribute?

Does it make any difference which version of the UML spec I'm using?

Thanks in advance,

John

[Ken Lloyd]

Hi John,

 

Since the <<Realization>> in Use Case X is a contract (much like an interface, compared, say, with the dependency <<Trace>> which merely follows that Requirement, a more common situation), it seems to me that a, b, and c would inherit that contract. 

 

Ken

--
--
You received this message because you are subscribed to the Google
Groups "UML Forum" group.
Public website: www.umlforum.com
To post to this group, send email to umlf...@googlegroups.com
To unsubscribe from this group, send email to
umlforum+u...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/umlforum?hl=en?hl=en
 
---
You received this message because you are subscribed to the Google Groups "UML Forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to umlforum+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

No virus found in this message.
Checked by AVG - www.avg.com
Version: 2014.0.4335 / Virus Database: 3705/7129 - Release Date: 02/27/14

[H. S. Lahman]

Responding to Bromell...

Hi all,

I'm new to this group and would like to ask a simple question for which I have so far found no definitive answer: In UML, does a specialized class inherit the relationships of the generalized class with which it has a generalization relationship?

The short answer is: Yes. The relationships to the generalization become polymorphic relationships to the specializations. However,...

As an example, suppose I have a use case X with specialized use cases a, b and c linked to it, and X has a <<realize>> relation to a requirement, R. Do use cases a, b, and c inherit the relationship to requirement R? Does it depend on the value of the generalization relationships' isSubstitutable attribute?

Use cases are quite different than classes. They simply organize requirements and do not provide solution mechanisms (e.g., relationship navigation in a Class Diagram during execution). So I think it is very risky to start modeling uses cases with this sort of complexity. For example, I have no idea what sort of modeling OMG had in mind when introducing isSubstitutable, but it is a non sequitur in OOA/D modeling and just confuses things.

I would also point out that for use case generalization, polymorphic access to specializations really doesn't make much sense. Use cases simply collect individual requirements and those requirements don't actually do anything; the generalization just describes how bunches of requirements are bundled with other bundles of requirements. [I know, UML allows the specialization to override requirements of a concrete parent. Good luck to anyone who wants to step in that quicksand. Simply substituting requirements is a very slippery slope because run time implementations tend to span requirements.]

To answer your question, I would interpret your example to mean that each specialization does have the <<realize>> relationship to R. However, I would bet that if I thought about it, I could come up with a situation where that made no sense in some situations.

The problem is that there is no way to express the content of use cases in UML. In the OOA/D for a solution, one can identify inconsistencies in the Class Diagram by looking at the explicit attributes, behaviors, object state machines, and abstract action language description of methods. But you can't do that for use cases; the correctness is determined externally to the UML diagrams. More important, it is invisible to the developer who has to design a solution. Which is why...

Does it make any difference which version of the UML spec I'm using?

...I don't know because I would avoid such a construct in use cases. B-)

-- 
Life is the only flaw in an otherwise perfect nonexistence
   -- Schopenhauer

Imagine how much more difficult physics would be if electrons had feelings
   -- Richard Feynman

Rene Descartes went into a bar. The bartender asked if he would like a drink. Descartes said, "I think not," and disappeared.

Entropy isn't what it used to be.
   -- mwalshe89

Is it solipsistic in here, or is it just me?

H. S. Lahman
H.la...@verizon.net
website: http://www.hslahman.com/
software blog: http://pathfinderpeople.blogs.com/hslahman/index.html
software book: Model Based Development, Addison-Wesley, 2011
geology book: The Evolution and Utilization of Marine Resources, MIT Press, 1972

[Remy Fannader]

Hi,
I agree with H.S., ucs are not classes and they should be modelled with the <include>/<extend> operators. Yet, if you insist with generalization, the semantics should not relate to contents but to the conditions that trigger the use cases.
http://caminao.wordpress.com/how-to-implement-symbolic-representations/patterns/functional-patterns/use-case-patterns/
http://caminao.wordpress.com/how-to-represent-objects-and-activities/abstractions/specialization/
Rémy.

[david reye]

John,

I think the simple rule that applies here is described in the Semantics section of Generalization (UML2.4.1 spec):

“…any constraint applying to instances of the general classifier also applies to instances of the specific classifier”.

Thus if Use Case X participates in a Relationship R, then specialised use cases A, B and C can also participate in R.

Looking at the description of “isSubstitutable”, it seems that it is intended to relate the behaviours of the specific and general classifiers,

so that the execution traces of the latter are a superset of the former if isSubstitutable=true. I don’t think it applies to your question about

participation in relationships.

I don’t think inheritance is relevant here. Only the Classifier’s members (e.g. structural and behavioural features) can be inherited and the 

Relationships you are thinking of would not confer an inheritable feature onto the Classifier. However, that will depend on the specific type of Relationship (e.g. Association does have inheritable members).

David

--
--
You received this message because you are subscribed to the Google
Groups "UML Forum" group.
Public website: www.umlforum.com
To post to this group, send email to umlf...@googlegroups.com
To unsubscribe from this group, send email to
umlforum+u...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/umlforum?hl=en?hl=en
 
---
You received this message because you are subscribed to the Google Groups "UML Forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to umlforum+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

David Reye

Software Systems Consultant

email: david...@codeworks.com.au

mobile: +61 404 471451

[Ashley at Metamaxim]

Hi David

I know this off-topic, but ...
 

> Looking at the description of “isSubstitutable”, it seems that it is intended to relate the behaviours of the
> specific and general classifiers, so that the execution traces of the latter are a superset of the former if
> isSubstitutable=true.

I think it has to be the other way round. If the specific (the child) is to be substitutable for the general (parent) then it must have at least all the execution traces of the parent. So the traces of the specific must be a superset of traces of the general.

Regards
Ashley

On 02/03/2014 21:53, david reye wrote:

[david reye]

Ashley,

Of course you are right. My mistake.

Cheers,

David 

--
--
You received this message because you are subscribed to the Google
Groups "UML Forum" group.
Public website: www.umlforum.com
To post to this group, send email to umlf...@googlegroups.com
To unsubscribe from this group, send email to
umlforum+u...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/umlforum?hl=en?hl=en
 
---
You received this message because you are subscribed to the Google Groups "UML Forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to umlforum+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Ashley at Metamaxim]

Hi David

It is, I think, counter-intuitive that the child (the specific) should have a wider, and therefore arguably more general, set of behaviours than the parent (the general). So your mistake is quite forgivable.

It is not to the credit of the authors of UML that they propose counter-intuitive concepts, and so I think this area merits re-examination.

Regards
Ashley  

[John Bromell]

Hi all,

Many thanks for your replies. I realise that use cases are not the same as classes, but they are both classifiers and so I would have thought that they would have the same generalization semantics - unless the UML explicitly says that they don't. If I said that a, b and c were classes and were specializations of the class X (no use cases in sight) and that X has a realization relationship to a class R, would classes a, b, and c automatically have the realization relationship to R?

The main reason for asking is that the UML modelling tool that I'm using - which claims to conform to UML 2.4.1, does not confer X's relationship to R on a, b and c (regardless of whether we are talking about use cases or classes). I thought it should, so I checked with the tool vendor and got the reply "With UML modeling of a Generalization, whether it be Use Case or a Class - the relationships to other entities are not implicit in the inherited details of the Specialized elements" - the opposite of what some of you have said.

Do any of you happen to know of any UML tools that do treat specific classes as having the same relationships as the class to which they have a generalization relationship?

Thanks,

John

[Cris Kobryn]

Hello Ashley,

> It is, I think, counter-intuitive that the child (the specific) should have a wider, and therefore arguably more 

> general, set of behaviours than the parent (the general). So your mistake is quite forgivable.

While I recognize that intuition tends be subjective, in this case you appear to be conflating Generalization relationship semantics with the Inheritance and Substitution mechanisms associated with popular OOPLs. In particular, your assertion that UML Class Specializations ("children" of Class Generalization relationships) "should have a wider, therefore arguably more general, set of behaviors" clause is, indeed, quite disputable. Since the Object paradigm is based on a supposedly *intuitive* anthropomorpic paradigm, let's see if we can come up with a reasonable modeling domain example that appeals to our "real world" intutions.

Consider an example from the Medical problem domain where a GeneralPractioner Class is Specialized by Cardiologist, OrthopedicSurgeon, and Psychiatrist sub-Classes ("children"), so that the GeneralPractioner Class is a Generalization (pun intended) of the Cardiologist, OrthopedicSurgeon, and Psychiatrist sub-Classes which share (via the Inheritance mechanism) the Properties and Behaviors of their super-Class ("parent"), but also add their own Properties and Behaviors as needed. It appears commonsensible here in this Medical domain model, consistent with real-world MD licensing laws, that one of the Specialized sub-Class "children" with additional or augmented (cf. "wider") Properties and Behaviors should be able to replace the Generalized super-Class "parent" if the need arose. (e.g. A Board-Certified Psychiatrist MD is properly licensed to perform General Practitioner type Behaviors, such as perform physical exams and prescribe flu medicine, if the need arises.)

> It is not to the credit of the authors of UML that they propose counter-intuitive concepts, and so I think this 

> area merits re-examination.

BTW, as the Chair and Chief Editor of the UML 1.x, UML 2.0, and open source SysML specification teams I accept full responsibility for everything wrong and bad, and accept no credit for anything correct or good, with all these visual modeling language specifications. So while I am *painfully* aware of numerous counter-intuitive concepts in both languages and accept full blame for all of them, for reasons that I have explained above, I don't list your issue among them.

Best,

Cris

__________________________________________________

Cris Kobryn

Editor, UML Forum

mailto:edi...@UMLforum.com

www.UMLforum.com 

[H. S. Lahman]

Responding to Ashley...

It is not to the credit of the authors of UML that they propose counter-intuitive concepts, and so I think this area merits re-examination.

<Hot Button>
Right. When the language gets big and complex, the right hand often does not know what the left hand is doing.
</Hot Button>

[Ashley at Metamaxim]

Hi Cris

Thanks for your reply.

I think you right that two concepts get conflated here. However, they appear to be conflated in UML. The UML User Guide says (page 61) in reference to generalization in class hierarchies:

"Generalization means that objects of the child may be used anywhere the parent may appear, but not the reverse. In other words, generalization means that the child is substitutable for the parent."

and on page 76:

"Generalization implies the Liskov substitution principle"

This appears to bind "generalization" and (Liskov) "substitutability" quite tightly.

Perhaps the literature is causing the trouble!

Best regards
Ashley

[H. S. Lahman]

Responding to Kobryn...

I really don't want to get into this discussion, but...

Consider an example from the Medical problem domain where a GeneralPractioner Class is Specialized by Cardiologist, OrthopedicSurgeon, and Psychiatrist sub-Classes ("children"), so that the GeneralPractioner Class is a Generalization (pun intended) of the Cardiologist, OrthopedicSurgeon, and Psychiatrist sub-Classes which share (via the Inheritance mechanism) the Properties and Behaviors of their super-Class ("parent"), but also add their own Properties and Behaviors as needed. It appears commonsensible here in this Medical domain model, consistent with real-world MD licensing laws, that one of the Specialized sub-Class "children" with additional or augmented (cf. "wider") Properties and Behaviors should be able to replace the Generalized super-Class "parent" if the need arose. (e.g. A Board-Certified Psychiatrist MD is properly licensed to perform General Practitioner type Behaviors, such as perform physical exams and prescribe flu medicine, if the need arises.)

Alas, I am afraid that I really don't like this example. A Cardiologist is not a General Practitioner. That is, the is-a notion of OO generalization does not exist in the problem space between them. The generalization would be better formed with a Physician parent and your four classes as siblings. Thus the prerequisite of becoming a Psychiatrist is that one is a Physician, not a General Practioner. IOW, a cardiologist could be trained as a Psychiatrist, but a Psychiatrist is not a Cardiologist or a General Practioner. In an OOA/D context, there is a more rigorous view of the correctness of your model than problem space interpretation...

There is a common problem in many practical OO generalizations. Quite often we encounter subclass sets that are mutually exclusive, yet there are members of the superclass set that are not in any of the subclass sets. That is a no-no for OO generalization because the union of subset members of an OO generalization must be a complete set of the members of the superset. In your example, the General Practioner parent has members that are not in any subset. Trying to name a subclass for those "extra" superclass members becomes difficult in the problem space, so we need to introduce the notion of Physician as the superclass. IOW, the General Practioner is a necessary sibling of the other subsets to account for the "extra" members of the Physician superset.

The reason I don't want to get into this discussion is because of how it relates to the direction OMG is taking UML. That the union of subset members must be a complete set of superclass members is an absolute rule in OOA/D because it it necessary for unambiguous mapping to Turing world executables. (It is also very important psychologically to prevent defects, but that's another story...) However, in other modeling contexts, such a restriction would not be necessary. That is the crux of the problem that I see in OMG trying to make UML into the Mother of Modeling Languages. We encounter situations where your model is valid in some other context, but it is incorrect in an OOA/D context. IMO, trying to resolve those kinds of conflicts in the UML meta semantics is a hopeless task. (Nor do I think it can be done with MDA Profiles because if those profiles change the semantics of the meta model, it becomes a different language. IOW, MDA becomes translation of different semantics of a single representation, rather than a translation from one representation to another of the same semantics.)

[Cris Kobryn]

Dear H.S.,

> I really don't want to get into this discussion, but...

Please spare the histrionics and recall the context of the fiber (sub-thread) I was responding to (Ashley's March 3rd "I know this off-topic, but ..."): the "counter-intuitive[ness] that the child (the specific) should have a wider, and therefore arguably more general, set of behaviours than the parent (the general)."

Consequently, the simple object domain model that I described was meant to address the intuitive vs. counter-intuitive issue that Ashley raised, not digress further still into executable semantics and Turing Machine equivalency. While you raised several good points in your critique, your bias toward Shlaer-Mellor type approaches and your failure to systematically separate Object Analysis, Object Design, and Implementation (Execution) <<view>>'s and semantics detracts from your arguments.

If you want to discuss any of these topics further, please raise a new topic thread, since this fiber is wearing thin!

> The reason I don't want to get into this discussion is because of how it relates to the direction 

> OMG is taking UML...

What OMG MDA "direction" for UML are you imagineering here? MDA? Consider the following analogy: MDA:UML :: Agile:Java

Stated otherwise, the problem UML faces is *lack* of direction, rather than *wrong* direction. Why do you think there hasn't been a major revision of UML2 for over a decade? (We completed the bulk of the technical work for the UML2 major revision nearly 11 years ago.)

/ck

__________________________________________________

Cris Kobryn

Editor, UML Forum

mailto:edi...@UMLforum.com

www.UMLforum.com

--
--
You received this message because you are subscribed to the Google
Groups "UML Forum" group.
Public website: www.umlforum.com
To post to this group, send email to umlf...@googlegroups.com
To unsubscribe from this group, send email to
umlforum+u...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/umlforum?hl=en?hl=en

---
You received this message because you are subscribed to the Google Groups "UML Forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to umlforum+u...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.