Extending use cases

[wgenuit]

I am trying to extend use case U2 from use case U1. Is there a possibility to show the constraints of U1 inside U2. It seems I am not able to do this.
Any suggestions?

[peter.zrnko]

There is no such possibility. And I think there is no need for such functionality.

You can provide more details, why do you want such functionality.

Your formulation "to extend use case U2 from use case U1" sounds a little bit strange. What exactly do you want to achieve?

[Eve]

Show the U2 using rectangle notation. (Right click, Advanced | Use Rectangle Notation)
Open set feature visibility dialog.  (http://www.sparxsystems.com.au/EAUserGuide/index.html?setfeaturevisibility.htm) and check Inherited Constraints.

[wgenuit]

Thanks for the answer, it does what I wanted it to do.

[Paolo F Cantoni]

Thanks for the answer, it does what I wanted it to do.

Hi,

It is good that it does what you want it to do.  

However, I agree with Peter - what (in English) you appear to be attempting to do is NOT what you should be doing with Use Cases.  Perhaps Peter and I have misunderstood what you are trying to do.

Is U2 an extension Use Case?  What type of relationship have you created between U2 and U1?

Paolo

[wgenuit]

Hi,

Basically I have two use cases that should share the same post conditions.
Something like:
Use case 1: Produce a car in USA
Use case 2: Produce a car in Europe

The post conditions for both use cases should be the same, something like:
- engine test: positive result
- safety test: positive result
- etc.

I would like to have an 'empty' use case that has the post conditions and then have Use case 1 and 2 generalize that 'empty' use case, so that I do not have to maintain the post conditions at two different places (and keeping them in sync ..)

[sargasso]

 :-/  Lightning strike !!!

I have (over the last day been fighting with sort of exactly the same thing.  I am currently exploring use case generalization as a solution.  If I have any joy I'll ley you know.

Basically, my scenario is that I have a set of very similar use cases in two directions - they differ only in the business object they work on, their behaviour is the "same" and similarly, they have differing relationships with both actors and other use cases (as extensions).  The approach I'm attempting is to create "template" cases containing the bhaviour and constaints and "template" usecase "instances" for the behaviour diagrams.

Thus repairProduct and repairProduct_OnSite have the same behavioral constraints, so I dont want them in two places either. So, I use repairProduct as the generalization and add a third useCase repairProduct_RTB (specializing reparProduct) and add a generalization from repairProduct_OnSite to repairProduct.  This seems to work OK conceptually, I have not yet worked it through to the final concusion, which is to generate everything down to and including the testcases for the system.  I'll let you know...

The other dimension is a bit trickier to describe and relates  to the Hamlet thread (http://www.sparxsystems.com.au/cgi-bin/yabb/YaBB.pl?board=UMLPRO;action=display;num=1174402057).  The invocation of usecaseX has crosscutting concerns with a subset "A" of the systemwide use cases, similarly usecaseY crosscuts a different, maybe intersecting subset "B" of the use cases.  There is specific behaviour that must be exhibited by any and all of the usecases in "A" and likewise specific behaviour for the "B" subset.

What I'm tryig to do is to simplify the model (and lower the effort) by specifying another set of template use cases, one for the "A" behaviour and one for the "B" - and have the use cases inherit the relevant behaviours depenfing on their (multiple) parentage.  Note this is a bit different from using <<includes>> as what I'm trying to do is NOT have to include and maintain the <<includes>> relationships throughout this ever-growing model.  So once I define a usecase as being an "A" or a "B" or both I dont need to worry about the includes anymore.....  or so I hope.

I'll be watching closely, let us know how you go.


bruce

[Paolo F Cantoni]

:-/  Lightning strike !!!

I have (over the last day been fighting with sort of exactly the same thing.  I am currently exploring use case generalization as a solution.  If I have any joy I'll let you know.

bruce,

I agree that Use Case generalization (once you've defined what that means) might well be a possible solution to the problem you've indicated.

However, (I think) you'll agree that it isn't Use Case extension.  Extension has a special meaning in (certainly) Use Case contexts.

Use Case extension should be orthogonal to generalization.  Should it not?

Paolo

[«Midnight»]

Orthogonal or non-congruent, we can debate which is more accurate later. I agree with Paolo nonetheless.

David

[thomaskilian]

I always thought it's meant to keep the extension points. So it is not a UC of its own but only a container for additions to another UCs. Generalization on UC terms does not seem to make so much sense, does it?

[sargasso]

Yes, what I'm talking about is different from extension, which as we have discussed (optionally) inserts specific behaviour into a use case execution at a specific defined point.

This is generalization of the use case properties themselves.   Viz "performAppendectomy" and "performSomeotherectomy" and performEveryOtherectomy" all have the ongoing constraint "patient is properly anaethetised".  Now there's a bod in the surgery whose sole job is to watch dials and twiddle nobs and ensure that the patientstate remains duly unconscious, on a exeption event raised should a state transition to "waking up" or "fading away" occur, said bod takes immediate control and every other usecase involving the patient going on MUST pause - no matter what execution point they are at.

I've got big mobs of these ectomy-like use cases, and some that are not ectomy-like.  So I create a parent do_ectomy use case constained by the patient state condition and having an extension case "stopEverything"..  All nicely contained and expressed in a single logical place.

doAppendectomy, doTonsilectomy, etc are all specializations of doEctomy and should thus exhibit the properties and behaviours of it automatically without having to maintain a zillion links between the real use cases and a "watchPatient" extension.


... or that's what I'm hoping anyway.


(Orthogonality has been blacklisted in my conceptual rule book since I attended a seminar last year on orthogonal arrays and came back totally confused.)


bruce

[sl@sh]

I wonder if all those "performXYectomy" use cases you are talking about could be modeled as variants of just one use case. But I've got to admit it's been some time that I last used variants and I'm not sure that would be a proper way to deal with your problem.

[Jan ´Bary´ Glas]

I don't like concept of generalization/specialisation of use case at all. Though UML specification defines it.

I treat every use case as a specific goal-centric use of a system (no matter if SW or other). This brings another point of view to post-condidtions that should be the same for more usecases. These are one use case for me. I do not care about implementation of an usecase, when defining it. I have an actor, a goal, post-conditions and scenarios. (and pre-conditions, system boundaries,...)

For the car manufacturer it can be like this:
Use Case: Produce a Car
Actor: BeHeWhoHeMay
Scenarios:
 Basic Flow: Produce in Europe
 Alternate: Produce in US (More cars produced makes the flow basic for me.)
Post-conditions:
etc.

HTH, Bary

[thomaskilian]

I liked what Bittner/Spence stated in their book Use Case Modeling: It's more use case synthesis, not analysis. Once you get that point, you automatically stop splitting use cases into these specialized/generalized forms. And things get much clearer.