Use case and actor inheritance does not work: bug, or not UML standard?

[Glassboy]

But ALL motor vehicles have a motor.  So association between motor vehicle and motor (motor type, power generated, efficiency etc.) would be a good association at the motor vehicle parent class.

If I take the motor out of a motor vehicle (commonly done) does it magically become something else?

[Glassboy]

"A Motor Vehicle has n Wheels(s) - <<Class>>Motor Vehicle related to a <<Class>>Wheel with an Association"

That's just a modeling fault that should be corrected as the model evolves.  Obviously not all motor vehicles have wheels.  The association between motor vehicle and wheel is wrong, it belongs to a child (possibly fairly down the hierarchy) of motor vehicle.

But ALL motor vehicles have a motor.  So association between motor vehicle and motor (motor type, power generated, efficiency etc.) would be a good association at the motor vehicle parent class.

"motor vehicle" isn't your parent class.  Vehicle is your parent class.  Motor is also only one type of power source for your vehicle.  It's not actually that complex an ontology.

[qwerty]

But ALL motor vehicles have a motor.  So association between motor vehicle and motor (motor type, power generated, efficiency etc.) would be a good association at the motor vehicle parent class.

If I take the motor out of a motor vehicle (commonly done) does it magically become something else?

Yes. A wreck.

q.

[Glassboy]

Actually pondering this, "motor vehicle" is probably an externality to the ontology.  It's a set of rules - within a particular jurisdiction - that allows anything with a motor to be given a licence to operated on a public right of way.

Which explains why so much of the conversation to this point has involved a categorical mistake.

[KP]

In use case diagram, some use cases are shown as specialization of other use cases (Generalization relationship) and some actors are shown as specialization of other actors.
But neither specialized use case or actor inherits the associations or tagged values of the parent: nothing is visible in the relationship matrix (use case/actor using use case as link type), nor in the tagged value or relationships windows.
Is this a Sparx bug, or is this correct per UML standard  (I don't think so  but I may be wrong)?  Thanks!

The Relationship Matrix doesn't show inherited associations (or any kind of connector), nor does the Relationships window. This is true for any kind of element: use case, actor, class etc. Doesn't mean that the association isn't inherited though; it is, but to find out what associations are inherited you will need to traverse the inheritance tree.

Inherited tagged values are listed in the "Tags" tab of the Properties window for all element types, and will be displayed on diagrams if you enable the compartment (you may need to switch to Rectangle notation).

[Modesto Vega]

Actually pondering this, "motor vehicle" is probably an externality to the ontology.  It's a set of rules - within a particular jurisdiction - that allows anything with a motor to be given a licence to operated on a public right of way.

Which explains why so much of the conversation to this point has involved a categorical mistake.

Interesting comment and thanks for bringing it up, there is some externality to this ontology. It is possible that in certain jurisdictions an electric bicycle or a motorised scooter could be categorised as motor vehicles. But I also think that there is more to this ontology than just externality: horses, mules and even humans - think humans carrying babies on their backs - can be used to “convey somebody or something” and they probably will not be classed as vehicles.

2 other points.

Firstly, the same model without the deliberate categorical mistake could look like
“Vehicle” relating to a “Conveying something or somebody Use Case”
“Motor Vehicle” specialising “Vehicle”, associated to or composed of “Motor”, and using a “Conveying something or somebody by motor” Use Case
“Car” specialising “Motor Vehicle”, associated to/or composed of “Wheel” and using a “Conveying something or somebody by car”
“Non Motor Vehicle” specialising “Vehicle” and using a “Conveying something or somebody without using a motor”
“Sail Boat” specialising “Non Motor Vehicle”, associated to or composed of “Sail” and using a “Conveying something or somebody by sail boat” Use Case

In this example, Richard´s inheritance will work perfectly but this is just because the model is not faulty.

Secondly, I am not sure what KP means with this

[SNIP]
Doesn't mean that the association isn't inherited though; it is, but to find out what associations are inherited you will need to traverse the inheritance tree.

But KP is alluding to an important and subtle difference between inheritance and  traversing the inheritance tree. My understanding is that this thread is about inheritance and not about traversing the inheritance tree. Being able to traverse the inheritance tree does not mean that an element at the bottom of the tree will inherit relationships to something at the top of the tree.

[Richard Freggi]

In use case diagram, some use cases are shown as specialization of other use cases (Generalization relationship) and some actors are shown as specialization of other actors.
But neither specialized use case or actor inherits the associations or tagged values of the parent: nothing is visible in the relationship matrix (use case/actor using use case as link type), nor in the tagged value or relationships windows.
Is this a Sparx bug, or is this correct per UML standard  (I don't think so  but I may be wrong)?  Thanks!

The Relationship Matrix doesn't show inherited associations (or any kind of connector), nor does the Relationships window. This is true for any kind of element: use case, actor, class etc. Doesn't mean that the association isn't inherited though; it is, but to find out what associations are inherited you will need to traverse the inheritance tree.

Inherited tagged values are listed in the "Tags" tab of the Properties window for all element types, and will be displayed on diagrams if you enable the compartment (you may need to switch to Rectangle notation).

Thank you.  I understand the relationship matrix limitation.  But I'm querying the tags by SQL and I'm checking the tags in the use case properties and in my case (EA v. 1310) they are definitely NOT inherited for use cases and/or actors as described in my original post.

[Geert Bellekens]

In EA the "inherited" tags are only a visual GUI thing.
The tags are never really duplicated, which you see when you query the database.

And I think that is a good thing. If I you need "inherited" tags in your SQL queries you'll have to climb the inheritance tree yourself (which is completely doable)

Same goes for inherited associations, attributes or operations. EA might sometimes visually show them (attributes and operations at least) but they still are only defined on the parent.
I don't see a use case for copying "inherited" anythings to the child entities.

Geert

[Glassboy]

Actually pondering this, "motor vehicle" is probably an externality to the ontology.  It's a set of rules - within a particular jurisdiction - that allows anything with a motor to be given a licence to operated on a public right of way.

Which explains why so much of the conversation to this point has involved a categorical mistake.

Interesting comment and thanks for bringing it up, there is some externality to this ontology. It is possible that in certain jurisdictions an electric bicycle or a motorised scooter could be categorised as motor vehicles.

Anything with a motor using a road is generally captured under the legislation.  There's generally specific rules on bicycles and scooters.  However things like ride-on lawn mowers and motorised sofas do run into trouble all the time.

You may have thought I was being flippant, but I worked for central government for a long time and it is a really common to see problems with data models because people have assumed a common language definition not a legal definition.  For example people might assume a building is something with a roof, whereas the law regards it as something capable of bearing a load.

No business or industry is free of regulation and at some stage assumptions will bite hard.

[Paolo F Cantoni]

[SNIP]

But KP is alluding to an important and subtle difference between inheritance and traversing the inheritance tree. My understanding is that this thread is about inheritance and not about traversing the inheritance tree. Being able to traverse the inheritance tree does not mean that an element at the bottom of the tree will inherit relationships to something at the top of the tree.

Precisely what do you mean here Modesto?

A couple of points...
1.  I've held true to the old UML injunction, a named association end IS an Attribute.
2.  Inheritance includes the ability to remove non-essential attributes from the descendent as well as adding and modifying attributes.

Consequently, if there is a different set of attributes in the descendent than the ancestor, then the relationship set WILL differ - but in a very controlled way. 

In this view, just enunciated, inheritance and the traversal of the inheritance tree are (more or less) one and the same.

Paolo

[skiwi]

(via the Bjelke-Petersen "Duck" principle")

You had to be there, see DuckSpeak and Duck Test.

[Paolo F Cantoni]

[SNIP]
 
Anything with a motor using a road is generally captured under the legislation.  There are generally specific rules on bicycles and scooters.  However, things like ride-on lawnmowers and motorised sofas do run into trouble all the time.

You may have thought I was being flippant, but I worked for central government for a long time and it is really common to see problems with data models because people have assumed a common language definition, not a legal definition.  For example, people might assume a building is something with a roof, whereas the law regards it as something capable of bearing a load.

No business or industry is free of regulation and at some stage, assumptions will bite hard.

Hi Glassboy,

It's usually pretty clear when you're being flippant - and this wasn't one of them.

Your point is well taken about "common" language definitions.  Firstly there's NO such thing.  Secondly, the definition has to be consistent with the structure of the model.  ("It's better to be consistently wrong than inconsistently wrong" - Paolo Cantoni)

This is why for decades now, I have included a formal, rigorous (and, I hope, industrial-strength) ontology with my models. So it's as crystal clear as I can make it as to what is meant and their interrelationships.

Regulatory and Statutory inputs are vital to that process.  I am always amazed at the lack of awareness of businesspeople as to the models of the statutes, regulations and rules that impact their business.

"if you control the portion of the model, you can be a bit lax in your modelling, if you DON'T own that portion, you have to be more rigorous in your modelling (and obtain input from the owner of that portion)"  - Paolo Cantoni

Paolo

[KP]

Secondly, I am not sure what KP means with this

[SNIP]
Doesn't mean that the association isn't inherited though; it is, but to find out what associations are inherited you will need to traverse the inheritance tree.

I think I was making the point that inheritance may not look how the OP expects it. Sometimes it just looks like a Generalization connector between two elements. The point of inheritance is not for the modeling tool to bring everything down the inheritance tree and show it all in the one place; it's to arrange the complexity so each individual element only shows its differences.

But I'm querying the tags by SQL and I'm checking the tags in the use case properties and in my case (EA v. 1310) they are definitely NOT inherited for use cases and/or actors as described in my original post.

Yes, they will only appear in the t_objectproperties table if explicitly overridden. Otherwise you will need to recurse up the tree to get the full list of inherited tagged values.

[Richard Freggi]

Thank you very much, now I understand.  I had the wrong expectation and did not know as Geert points out, that In EA the "inherited" tags are only a visual GUI thing.
It makes sense now.  I need to rely on "you will need to traverse the inheritance tree" as KP says.

Secondly, I am not sure what KP means with this

[SNIP]
Doesn't mean that the association isn't inherited though; it is, but to find out what associations are inherited you will need to traverse the inheritance tree.

I think I was making the point that inheritance may not look how the OP expects it. Sometimes it just looks like a Generalization connector between two elements. The point of inheritance is not for the modeling tool to bring everything down the inheritance tree and show it all in the one place; it's to arrange the complexity so each individual element only shows its differences.

But I'm querying the tags by SQL and I'm checking the tags in the use case properties and in my case (EA v. 1310) they are definitely NOT inherited for use cases and/or actors as described in my original post.

Yes, they will only appear in the t_objectproperties table if explicitly overridden. Otherwise you will need to recurse up the tree to get the full list of inherited tagged values.

[Modesto Vega]

[SNIP]
You may have thought I was being flippant, but I worked for central government for a long time and it is a really common to see problems with data models because people have assumed a common language definition not a legal definition.  For example people might assume a building is something with a roof, whereas the law regards it as something capable of bearing a load.

No business or industry is free of regulation and at some stage assumptions will bite hard.

Glassboy, I did not think that you were flippant. I know from experience, similar to yours, that you raised a very important point (even when you removed the motor because at that point the motor vehicle may become waste, even a hazard, and there are  of regulations about waster.

So no worries there and thanks for bringing that important point up.

[SNIP]
Precisely what do you mean here Modesto?

Well I am going to
1) quote/paraphrase here (and hopefully I would not get in trouble):

[SNIP]
I don't see a use case for copying "inherited" anythings to the child entities.

[SNIP]
The point of inheritance is not for the modeling tool to bring everything down the inheritance tree and show it all in the one place.

2) Paraphrase you, inheritance is traversal and should be used in a very controlled way

3) And, add inheritance is not transversal, the inheritance tree is traversed via generalisations/specialisations and only structural characteristics of the traversed objects (including operations) are inherited. Inheriting other relations, the things at their end together with their properties is potentially transversing (jumping to) to another semantic area nor traversing. In short, inheritance has to be kept within a semantic area.