Use Case Metamodel

[zyx]

Hello,

    In the UML 2.1.1 Superstructure Document, on page 598 is the Use Case Metamodel - the metaclasses of this diagram. In there I saw there is two relationships between the UseCase and Extend Metaclasses, the left relationship is a composition and the right a association. The same occurs with the Include Metaclass. I cannot understand why two relationships, what is the function of its two relationships? Just one is not enough?

[son-of-sargasso]

Diagram 16.2 and Section 16.3.3 Associations and Section 16.3.6 Associations.

The composition represents the "parent" Usecase view,

extend : Extend\[*\] References the Extend relationships owned by this use case.

i.e UsecaseX can have lots of extending use cases that are linked by lots of Extends.

The other end of this composition represents the Extend view,

extendedCase : UseCase [1] References the use case that is being extended.

, in this case UsecaseX.

The association represents the Extend view of the target usecase,

extension : UseCase [1] References the use case that represents the extension and owns the extend  relationship.

, in this case UsecaseY, UsecaseZ.

Or in other words, an Extend knows about two usecases, a Usecase knows about a set of Extends.

Any clearer

hth
bruce

p.s. An "extension" Usecase knows nowt about any use case it is an extension of. Thus allowing it to extend any use case. So, the extension Usecase information should not describe anything about the extended use case.  Hmmm, something new everyday learned.

[Paolo F Cantoni]

[size=18]...[/size]
p.s. An "extension" UseCase knows nowt about any use case it is an extension of. Thus allowing it to extend any use case. So, the extension UseCase information should not describe anything about the extended use case.  Hmmm, something new everyday learned.

Perhaps they thought "this truth to be self evident..."

I recall realizing this a LONG time ago (and subsequently not at the top of one's mind) , so it's good be be refreshed/reminded.  There's so many of these somewhat subtle derivatives of the specification, that we need to be reminded of them from time to time.

Paolo

[Geert Bellekens]

bruce,

I'm not sure if I'm following on this one.
If:

Code: [Select]

UsecaseA ---<<extend>>--> UsecaseBDoesn't that mean that UsecaseA owns the extend relation?
Since it owns this relation it also knows the target of this relation.
So UsecaseA knows about UsecaseB and can use that knowledge.

UsecaseB on the other hand should not know anything about UsecaseA or any other extending usecases.

I know UsecaseA could be extending multiple usecases, but I don't see why that should change anything about the knowledge of the extended usecases.

Geert

[son-of-sargasso]

Geert,

Quite a few things here.  

First, we have to remember we are talking about behaviorial aspects here not structural.  As such, and I'm having a bit of trouble expressing this so please bear with me.  The concept of one behavior "owning another" doesn't fit too well.  Hence I prefer to use the term "knows about" or "knows something about".  If we go back to the old cell phone example, usecase:connect call and usecase:time call and usecase:create call charge maybe all somehow related,  but there is no concept that any one of them "owns" another.

BTW I'm talking from the point of view of the cell, not the phone.

So, we better add another usecase:pass connection, which only occurs/is invoked when the cell passes an active call off to another cell.

For the sake of the argument, time call and create call charge are both "includes" of the connect call use case.  Just accept this and lets get back to the extends issue.

pass connection is an extension, its outcome is to "hand off an active connection to the next cell providing all necessary continuity".  It extends connect call and it does only under specific conditions. Like "call is still active" and "(whatever technical blah blah says to hand it off)".  

My (re-)reading of section 16 has now suggested to me that, pass connection knows nothing about the connect call use case, it's goal (outcome) is self contained and its invocation (stimulus) may have come from a connect call or from another pass connection invocation as a result of a call being passed from cell to cell to cell.  That is what I was alluding to.

For some years , I have been writing extending cases as if they automatically "knew" what they were extending.  (Not always, just sometimes.) It was only after curiosity into zyx's quandry that I got the proverbial self-slap on the self-wrist.

The more I thought about the business of the extending case knowing nowt about the extended case, the more it actually makes sense.

It seems to me (tonight) that the relationship knows more about the situation than either of the use cases does.  (Which kinda makes sense to me, because I always had a feeling that it was the extend that knew about the extension point, not the original use case. But better minds than mine have decided otherwise.

anyway, cheers
bruce

[Geert Bellekens]

bruce,

Could you indicate which part of the specs have led you to the conclusion that the extending usecase doesn't know who it is extending? I've read the same chapter (superstructure 2.2) and I can't derive that conclusion.

Another thougt, from a functional (UML user) view it seems pretty obvious that the extending usecase knows about the usecase(s) it extends since the arrow goes in that direction.
Seems to me that, in general, the arrow on a relation indicates who knows about whom. Would this be an exception to that?

Geert

[Paolo F Cantoni]

[size=18]...[/size]
Seems to me that, in general, the arrow on a relation indicates who knows about whom. Would this be an exception to that?

Geert

In general, but NOT always.  Generalization, for example, is the "wrong way round"  If you use the supplier/client viewpoint then most (almost all) the relationships in UML have the client expressing the relationship with the supplier.  Thus client is dependent on supplier, client uses supplier, client extends supplier etc.

However, client (child) does NOT generalize supplier (parent).

Navigability (knowledge) is only valid for Associations.

EA conflates directionality and navigability.  UML says nothing about directionality (since the arc on the piece of paper) could have been drawn in either direction.  However, for over twenty years, I've been very strict with directionality (which end is the origin and which the destination) and written model analysers that "read" this directionality and use it to infer information about the model.

In general, within UML, if you make sure EA directionality equates to client (origin) and supplier (destination) it seems to work well.

The problem that I think bruce is alluding to is that although a particular invocation of the pass connection use case (client) is aware of which use case is its supplier (connect call or pass connection) the definition of the use case can't be written in that way.  

This is because you can (have to be able to) add more extends relationships to other suppliers without changing either the client or the supplier; bruce's point: "that the extend knows more about the situation that either of the use cases does", I think, "hits the nail on the head".

HTH.
Paolo
(sorry for the rambling...)

[zyx]

Thank you for the help. Again I apologize for my bad english...

I don't know if I really understood the explanation (I think not), can I say that the composition, with the roles extend and extension, represents the extended use cases owned by the extending use case (extend role) and the extending use case that owns the extended use case (extending role)? In another words a extending use case may have many extended use cases but a extended use case must be associated just to one extending use case?

But I don't know yet what is the functin of the association, it appears to have little difference of the other relantioship... I see that the navegability is directioned to the use case metaclass, so I think it is a complementation... May I read it like "a exteded use case is a extended case (extendedCase role) of just one use case, but a use case may have many extended use cases? I believe I am not understanding something...

[Geert Bellekens]

In general, but NOT always.  Generalization, for example, is the "wrong way round"  If you use the supplier/client viewpoint then most (almost all) the relationships in UML have the client expressing the relationship with the supplier.  Thus client is dependent on supplier, client uses supplier, client extends supplier etc.

However, client (child) does NOT generalize supplier (parent).

OK, but the arrow goes from the "child" to the "parent". Which means that the "child" knows about the "parent" (and the parent doesn't know about the child).
So the general rule: knowledge follows the direction of the arrows still applies.

Geert

PS. I'm making abstraction of the "client" and "supplier" concepts as used by EA since they are absoluty meaningless.