How to model use case variants and solutions ?

[Michel777]

Hi,

we have  different variants certain use cases. E.g.

Use cases A has variants V1 and V2.
use case B V1, V2 and V3
use case C only Variant V1

We are going to build Solutions:

Solution S1 will be composed with use cases V1
Solution S2 will be composed with use cases V2 ( V1 if V2 not present)
Solution S3 will be composed with use cases V3 ( V2 if V3 not present)

How to model the use cases and the Solutions ?

Thanks,

Michel

[qwerty]

I doubt that variants of use cases make much sense. What would that mean? A use case yields some value to its primary actor. The value can not really vary. What you probably mean is that you have different ways to achieve the goal. So you are actually talking about different scenarios. Which in turn can easily modeled in a single use case.

q.

[Michel777]

Hi,

we will have three  solutions  (three versions). In the first version we will implement the use cases very poor (V1). Later better (V2) and in the final version (v3) "perfect".

The simplest way for comparing the solutions seems to build different version of use cases (actually business use cases)

Michel

[qwerty]

In that case you should do it via 3 different Collaborations which each Realize a single Use Case.

(I'm currently writing a book dealing with that topic on how to model such things. Will be published soon.)

q.

[Michel777]

Hi,

in that case: how to  model the collaboration variants for building solutions ?  How to collect all the collaborations  of variant 1 , 2 and 3 ?

Thanks,

Michel

[qwerty]

As I mentioned: it's enough to fill a book :-)

In short: create one Collaboration for each variant and draw a realization to the use case. Then fill in all the sequence diagrams that describe the realization of the use case.

q.

[g.makulik]

Isn't the situation, that the primary use case stays the same in all the versions, but might [size=12]include[/size] additional features (included use cases/scenarios) in future versions?

[Michel777]

Hi q & g.makulik

thanks for your effort.

q: let me know, if you have already a draft, I'd buy it
g.makulik: actually they are business use cases. the differences makes between variants how many "steps" will be supported by the system, e.g.

Use case A has 5 steps ans all of them references an existing system

Variant 1: 2 steps supported, 3 are manual steps
Variant 2: 3 steps supported, 2 are manual steps
Variant 3: 4 steps supported, 1 is manual

What about using different relationships between use cases and the Systems ?

For example:

Self defined realtionships: Variant1 , Variant2 and Variant3 with own attributes describing the kind of using the  systems ?

The five Systems: S1, .... S5
The relations:

UC - V1 -supported -> S1
UC - V1 -supported -> S2
UC - V1 -manually  -> S3
UC - V1 -manually  -> S4
UC - V1 -manually  -> S5

UC - V2 -supported -> S1
UC - V2 -supported -> S2
UC - V2 -supported -> S3
UC - V2 -manually  -> S4
UC - V2 -manually  -> S5

UC - V3 -supported -> S1
UC - V3 -supported -> S2
UC - V3 -supported -> S3
UC - V3 -supported  -> S4
UC - V3 -manually  -> S5

And after them to build diagrams, reports of the construct ?

Thanks,
Michel

[qwerty]

Hi q & g.makulik

thanks for your effort.

q: let me know, if you have already a draft, I'd buy it

I'll try to publish it the next days. It's on my desk since a few months but then other things got higher priority.... I will post a note here when it's out.

q.

[edit] I have published a first version of the book here: https://leanpub.com/EABA
Additionally there are a couple of coupon codes for the first buyers: EABAintro

As usual this is ongoing work. The current state as I see it is 80% completeness. Depends how to look at that. My other books are quite some time at 99% and I still add quite some stuff. Like the progress bar when it seems to get to an end

[AndyJ]

Minor typo in the blurb:

"A business analyst which has to document a system using UML often looses track"

Should be "... often loses track"

[RoyC]

Oh, Ok then:

"A business analyst which has to document ..."

Should be "... who has to document...", although you might get away with "... that has to document...".

[qwerty]

Thanks guys :-) That text was one of the last things I did 2:00 in the night. There are probably some more in the book itself...

Regarding who and which: BAs often feel more like  tool than a person. So which would probably also apply

q.