Use case versioning - Best practices?

[Pascal]

Hi,

One of the organisations I work at has EA running on a central repository. They now want to start using it for analysis in a serious project. An information analist will describe the use cases, based on which other project members will do their work.

Now the analist wants to add or change something in a use case others are working on. However, the others should not be confronted with this change until the next iteration.

My question: how do you best distinguish between these two versions of a use case (in order to let the analist work on his new version and the others work on the old version at the same time)?

Thanks!

Pascal

P.S. Version control is the first thing that came to my mind. I have not used it yet on a repository-based EA implementation, and I'm guessing that it is not possible for two groups of users to work on a different version of the same package, since everyone shares the same version of the whole repository, right?

[sargasso]

Very interesting question.  However, I am not sure whether I've got the whole gist of what you are trying to do.

You seem to be saying that the use case is changing between system releases?  

On my planet this can not occur, by definition.  My use cases define the outcomes (C**kburn's "goals") desired/obtained through an interaction between the actors and the system.  UC: "Get Coffee" remains the same, even if the system component "coffee_provider" changes.  If rel2 will, say, support the delivery of x different varieties of coffee based on some operational parameter, then I will create a new parameterised use case "Get CoffeeType", perhaps initially by copying the exisent rel1 use case.  In rel1, coffee_provider is (should be, could be) implemented with a single UI component, lets say a button labelled "Press me for coffee".  In rel2, this component will be gorn!, replaced (perhaps) with multiple UI buttons labelled "Press me for cappucino", "Press me for Latte", etc (or perhaps with a voice actuated selector?)

IOW, I cant see how a use case can change in between releases.  I can see how it can be replaced.  So, I would use a different use case - setting the EA Phase attribute appropriately.

So I reckon: simplify what you need to achieve.  There is no need to implement a domestic argon laser appliance to cut a slice of bread.


bruce

[Pascal]

Bruce,

Thanks for your quick input! I can see how copying the release A use case to a release B use case and updating it with the new or changed functionality can solve this problem.

The only drawback I currently see with this is that dependencies other model elements have on release A of the use case, will, at some time have to be moved over to release B of the use case. I'm thinking of things like <<trace>> dependencies between the use case realisations and the use case. Then again (I'm thinking while I'm typing [who said men cannot do two things at once   ]), this is probably more of a benefit, since this helps the person doing the use case realisations to explicitely track if he has updated the realisations for release B. Hmmm....

I'd still be eager to hear if others manage this problem differently, though.

Thanks do far!

Pascal.

[Rob_M]

I made the following suggestion for localized versioning - more for requirements, but I think the same idea still applies.

http://www.sparxsystems.com.au/cgi-bin/yabb/YaBB.cgi?board=UMLPRO;action=display;num=1078329780;start=4#4

[Pascal]

Rob,

Thanks a lot for pointing that topic out to me. Indeed, we will encounter this problem not only when modeling use cases, but with all model elements, so the mentioned solutions are very appropriate.

One thing I'm wondering: the thread is 1.5 years old so I'm guessing you've worked with the method suggested by yourself quite a bit since then. I can imagine that by now you've perfected your method. If so, can you share what new insights you've gained since then?

Thanks a lot!

Pascal.

[Rob_M]

Geez, has it been that long since I wrote that?

Actually, I still use pretty much that same method. I had a client send me a version B of a requirements document in which some requirements were changed, some were new, and some remained the same.

I suffixed the new and changed requirements with a -B to indicate that these requirements were new or modified and copied the old requirements as children of new ones. I then cut and pasted the new text.  It becomes very apparent which requirements were changed since the last version. We are now up to version E.

Works for me.

Sorry, I haven't developed any plugins to help with this. I've been waiting for Sparx to come out with 'element versioning'.


Rob

[Kevin Brennan]

Yes, use cases can change between versions, particularly if you're developing concrete rather than essential use cases.

My advice is to model the new functionality as a use case that <<extends>> the original.

[thomaskilian]

Hi Kevin,
would you also model it in this way, if the new functionality actually "removes" parts of the UC description. I also could think of cases where one would either break a single UC into many or vice versa to join multiple in a single UC.