p.s. Qwerty, generalizations are very useful in use case diagrams (requirement analysis and stakeholder identification/categorization). You can generalize the common use case or actor and specialize the unique little variants that are important to different business models, geography etc. Then when you negotiate/build consensus on requirement implementation you can divide and conquer the commonalities vs. the specialized needs. This is why I need to show all inherited properties in my use case reports. I'll write a custom query for this - cheers.
I tried and tagged values are inherited by children, I was wrong. What is not inherited is , but not associations (not shown in relationship matrix or in Relationship tab). Since relationships are not inherited, relationship tagged values are also not inherited.If I specialise or generalise an Actor and any associated use cases, I would not expect the generalised (or specialised) use case to have inherited all elements that make the use case being generalised (or specialised), including the relationship between the original Actor and Use Case.
Yes, if there is a further specialization of Mortgage Applicant (e.g. "Priority applicant"), then the Relationship window should show a relationship between Apply for a Mortgage and Priority applicant, because Priority applicant has inherited this association from its parent "Mortgage applicant".
If I specialise or generalise an Actor and any associated use cases, I would not expect the generalised (or specialised) use case to have inherited all elements that make the use case being generalised (or specialised), including the relationship between the original Actor and Use Case.
For example, if I have an general Applicant actor consuming an "Applying for (something)" use case, and specialised the actor and use case twice, once as Mortgage Application and Applying for a Mortgage and again as Credit Card Applicant and Applying for a Credit Card, I would expect stand alone empty use cases as a result. Hence, not inhering the tagged values of any associations involving the specialised use cases and actors.
Am I missing something?
You are right, insofar, as Sparx does not behave this way. We have tried something similar with v13 and it does not behave the way you described.Yes, if there is a further specialization of Mortgage Applicant (e.g. "Priority applicant"), then the Relationship window should show a relationship between Apply for a Mortgage and Priority applicant, because Priority applicant has inherited this association from its parent "Mortgage applicant".
If I specialise or generalise an Actor and any associated use cases, I would not expect the generalised (or specialised) use case to have inherited all elements that make the use case being generalised (or specialised), including the relationship between the original Actor and Use Case.
For example, if I have an general Applicant actor consuming an "Applying for (something)" use case, and specialised the actor and use case twice, once as Mortgage Application and Applying for a Mortgage and again as Credit Card Applicant and Applying for a Credit Card, I would expect stand alone empty use cases as a result. Hence, not inhering the tagged values of any associations involving the specialised use cases and actors.
Am I missing something?
Same for the use case: if there is a specialization use case "Apply for business facility mortgage", it should show an association with both Mortgage Applicant and Priority applicant, because it inherited them from its parent.
You would not want to show these associations in diagram, but you should see inherited properties in the window (and in the relationship matrix) so you can work on them.
then the Relationship window should show a relationship between Apply for a Mortgage and Priority applicant, because Priority applicant has inherited this association from its parent "Mortgage applicant"The inheritance is likely to be indirect, through the generalisation and not direct. If you are suggesting the following:
[SNIP]B has a derived relationship to X via traversal.
The inheritance is likely to be indirect, through the generalisation and not direct. If you are suggesting the following:I am not sure transitivity applies here, I am not sure the standard supports transitivity. Somehow transitivity does not sound right.
- B specialises A
- A has and association to X
- Therefore B should inherit the association to X
If we were dealing with certain types of relationships in ArchiMate 3 - e.g., dependencies - I am tentatively inclined to agree with you. But we are dealing with UML and, specifically, with generalisations and associations. Generalisations and associations are very different from dependencies, they are characterising.[SNIP]B has a derived relationship to X via traversal.
The inheritance is likely to be indirect, through the generalisation and not direct. If you are suggesting the following:I am not sure transitivity applies here, I am not sure the standard supports transitivity. Somehow transitivity does not sound right.
- B specialises A
- A has and association to X
- Therefore B should inherit the association to X
Paolo
Yes if A's association with X is a property of A, then B should inherit it I thinkThis is the bit I am not sure about. I am not sure inheritance of associations should be automatic. Take the following example, if I had chosen to create a model like:
[SNIP]As Mrs Beaton is reputed to have said (she actually didn't - I checked):
This is the bit I am not sure about. I am not sure inheritance of associations should be automatic. Take the following example, if I had chosen to create a model like:It would not be a good idea to inherit 1 between Submarine and Wheel, because the model is incorrect.
- A Motor Vehicle has n Wheels(s) - <<Class>>Motor Vehicle related to a <<Class>>Wheel with an Association
- A Car is a Motor Vehicle - <<Class>>Car related to a <<Class>>Motor Vehicle with a Generalisation
- A Submarine is a Motor Vehicle - <<Class>>Submarine related <<Class>>Motor Vehicle with a Generalisation
I am sure the same can be done with Use Case but cannot think of a good example.
In short, inheriting certain types of relationships can result in an incorrect model.
A hovercraft is a motor vehicle, isn't it? Does it have wheels?FWIW, in English speaking countries, a motor vehicle is "an automobile, truck, bus, or similar motor-driven conveyance."
q.
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.
"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.
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?
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!
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.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.
Which explains why so much of the conversation to this point has involved a categorical mistake.
[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.
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.
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).
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.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.
Which explains why so much of the conversation to this point has involved a categorical mistake.
[SNIP]Precisely what do you mean here Modesto?
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.
(via the Bjelke-Petersen "Duck" principle")You had to be there, see DuckSpeak (https://en.wiktionary.org/wiki/duckspeak) and Duck Test (https://en.wikipedia.org/wiki/Duck_test).
[SNIP]Hi Glassboy,
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.
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 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.
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.
[SNIP]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.
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.
[SNIP]
Precisely what do you mean here Modesto?
[SNIP]
I don't see a use case for copying "inherited" anythings to the child entities.
[SNIP]2) Paraphrase you, inheritance is traversal and should be used in a very controlled way
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.