Use cases and baselines?

[miksko]

Sparx lets you create baselines on elements in a package. That works well with requirements, information classes and other single elements.
Unfortunately the same can't be said about use cases, which are in themselves containers/packages. A use case may contain 100 activities and local requirements. A package of use cases may contain 50 or more use cases. That means 5000 elements in the same baseline, which takes quite some time for Sparx to digest!

So, what strategy do others use:
1. One package per use case?
2. Packages of use cases that are logically grouped together? (And in that case: What logic have you found to work the best, since you want to avoid a situation where multiple modelers work in the same package.)
3. Something else?

[qwerty]

I always wonder what the UC for baselines is for different users. Is it some kind of backup (there are other possibilities)? Do they compare with past states (for what purpose then)? Were they in the belief to do something good using it (then why)?

q.

[Geert Bellekens]

We don't use package baselines at all, but the idea that a use case contains activities and requirements feels weird to me.

My use cases generally only contain a single Activity that is used to visualize the scenario's; nothing else.

But regardless, if your use cases contain a lot of stuff, it's a good idea to use the "one package per use" case approach.
If not for baselines, its useful for document generation, search queries, relationship matrices, etc...

Geert

[miksko]

>>My use cases generally only contain a single Activity that is used to visualize the scenario's; nothing else.

Geert, can you please develop this subject a bit further?
We once tried scenarios and let Sparx generate activity diagrams from them, but that resulted in one activity per scenario step. We decided to leave that method for other reasons: Most scenario changes force you to regenerate the diagram, often resulting in a hideous layout you still have to adjust manually. Instead we produce the activity diagrams by modelling them, adding one activity per scenario step.

But either way you will get as many activities as there are scenario steps.

[Geert Bellekens]

You have to choose the option "Activity diagram with Actions" to get a valid UML activity diagram.

So that means one action per scenario step. When regenerating you can choose to leave the layout intact.
For small scenario changes that is fine. Bigger scenario changes usually require a full regeneration of the diagram.

Geert