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

[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!

[qwerty]

While I don't have a problem with generalizing Actors, I don't think that this is a meaningful concept for UCs since a UC should be a unique added value for the SUC. Generalization would be a contradiction to that paradigm and (in all cases I saw so far) just start of functional decomposition.

Anyhow, in V13.5 I see the inherited tags for actors. Probably a V15 issue.

q.

P.S. Just looked into V15.1 which also shows the inherited tag.

P.P.S. Cant tell anything about the RM since I never use it.

[Richard Freggi]

Thanks for quick reply, it helped!  p.s. I use v 1310.
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.
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.

[Richard Freggi]

p.s. I think it's a Sparx bug - inheritance of associations should be implemented!

[Modesto Vega]

Although I fully agree wit this:

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 am having some trouble visualising this:

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.

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?

 

[Richard Freggi]

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?

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".
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.

[Modesto Vega]

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?

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".
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.

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.

With regards to the "bug or UML standard" question, I am not sure if what you described is as per the UML standard and, somehow, have my doubts it is supported by the standard (but cannot yet articulate why). Somehow, this does not sound right:

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:

• B specialises A
• A has and association to X
• Therefore B should inherit the association to X

I am not sure transitivity applies here, I am not sure the standard supports transitivity. Somehow transitivity does not sound right.

[Paolo F Cantoni]

[SNIP]

The inheritance is likely to be indirect, through the generalisation and not direct. If you are suggesting the following:

• B specialises A
• A has and association to X
• Therefore B should inherit the association to X

I am not sure transitivity applies here, I am not sure the standard supports transitivity. Somehow transitivity does not sound right.

B has a derived relationship to X via traversal.

Paolo

[Richard Freggi]

Yes if A's association with X is a property of A, then B should inherit it I think

[Modesto Vega]

[SNIP]

The inheritance is likely to be indirect, through the generalisation and not direct. If you are suggesting the following:

• B specialises A
• A has and association to X
• Therefore B should inherit the association to X

I am not sure transitivity applies here, I am not sure the standard supports transitivity. Somehow transitivity does not sound right.

B has a derived relationship to X via traversal.

Paolo

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.

Yes if A's association with X is a property of A, then B should inherit it I think

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:

• 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

It would not be a good idea to inherit 1 between Submarine and Wheel, because the model is incorrect.

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 on a incorrect model.

[Paolo F Cantoni]

[SNIP]
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:

• 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

It would not be a good idea to inherit 1 between Submarine and Wheel, because the model is incorrect.

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.

As Mrs Beaton is reputed to have said (she actually didn't - I checked):

"To make Rabbit pie, first, catch your rabbit".

Define motor vehicle (your definition implies that it has AT LEAST one wheel)

A submarine has NO wheel (of this conceptualisation) therefore it CANNOT be a motor vehicle (via the Bjelke-Petersen "Duck" principle")

If a motor vehicle can have NO wheels, then a submarine is, INDEED, a motor vehicle with NO wheels.

I case my reset...

Paolo

[qwerty]

A hover craft is a motor vehicle, isn't it? Does it have wheels?

q.

[Paolo F Cantoni]

A hovercraft is a motor vehicle, isn't it? Does it have wheels?

q.

FWIW, in English speaking countries, a motor vehicle is "an automobile, truck, bus, or similar motor-driven conveyance."

However, that's NOT the point I'm making.  If (as Modesto at least implied) a motor vehicle must have at least one wheel, then by definition (the "Duck" principle") then neither a submarine nor a hovercraft is a motor vehicle.  If a motor vehicle may have no wheels, then the relationship between a motor vehicle and wheels is moot (and, essentially, irrelevant) and therefore the problem "reductio ad absurdum".

Paolo

[Richard Freggi]

"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.

[Modesto Vega]

I was missing a thread like this.

The choice of example was not accidental, but you may have guessed this already.

A motor vehicle is indeed "an automobile, truck, bus, or similar motor-driven conveyance", and conveyance is "the action or process of transporting or carrying someone or something from one place to another". So a submarine, a hovercraft, or a line cruiser are all motor vehicles because they "transport or carry something using" using a motor (and none of the have wheels).

Of course the model in the example is faulty, the fault was deliberately introduced to illustrate an example, but I am sure we all have being around long enough to see faulty models.

My point is that if you allow inheritance on a faulty model, you will get an even faultier model. Hence, I don't think that associations should be inherited when specialising and I don't think the standard supports this.