Add and New in UC extend relationship

[spereira]

Hi everyone,

Can somebody help me defining this?:

I have a UC that defines a Process.
Inside of the create Process, I have a functionality to create an Activity. Because of the activity cannot live "outside" of the scope of a process, I will have Create, Edit and Delete Activities from the Process.
This gives me these UC:
Create Process <---(extends)----Create Activity
              <---(extends)----Edit Activity
              <---(extends)----Delete Activity
Then, I have another relationship, a bit more complex.
I will have to be able to create a relationship between Process and Products. But Products also has a relationship to a Customer. Products and Customers could "live outside" the scope of a Process, so each of everyone will have UC related to Create, Edit and Delete. But related to The Process, I will have:
Create Process <---(extends)----Add Product
              <---(extends)----Remove Product
Because of the Customer relates to the Process via Product, I will have a "scenario" inside the UC Add Product that adds  customers to the Product and so on. This is example A.
Another way that I see is to have another UC named Add Customer with an extends relationship to Product. This will be example B.
Which of this ones is right? Or both are wrong and I facing the problem of modelling this incorrectly?

Thanks in advance!

[«Midnight»]

You seem to have more than one 'level' of things happening at once.

Consider factoring out the Product, Customer, and Activity pieces (to avoid any overloaded terms). What's necessary for each? Now consider which ones play a role in the Process piece.

Ask yourself questions, to help you discover relationships between the use cases. For example, do you have any other way to handle a Customer, or is this always done in the context of a Product? Perhaps there is an entire Customer piece that lives on its one, and other use cases only invoke it.

Try this, and see where it leads you.

David

[thomaskilian]

Avoid Include/Extend unless you have VERY good reasons for their use. Remember: it needs to be UC synthesis, not analysis! The bits and pieces come from requirements. Your UC need to show where the value is found in these.

[spereira]

@midnight and @thomaskilian

Yes, ok. But when I send the use cases to Testing Area, they say to me that the required detail contained in the UC aren't sufficient to get the test cases...
But I asked myself the questions and try to put into the use cases the scenarios and information that picture the value given to the user and things like the Add/Remove UC aren't as useful as the Testing Area says it is.

... I ask myself another question: what makes a Use Case complete enough to make the test cases and to give the developers complete documentation (plus the SRS, other docs, etc.) to code it?

And if you avoid all that you can the extend/include relationships... how do you write your UC without getting too much information inside one UC description, and in the cases of having scenarios shared between two UC...?

Thank you very much!

Sebastian

[«Midnight»]

...when I send the use cases to Testing Area, they say to me that the required detail contained in the UC aren't sufficient to get the test cases...
...and things like the Add/Remove UC aren't as useful as the Testing Area says it is.

...what makes a Use Case complete enough to make the test cases and to give the developers complete documentation (plus the SRS, other docs, etc.) to code it?

One often sees test cases and use cases in the same model. However, think about the purpose of each. At the beginning of your process you should be thinking about WHAT the system does - you'll find a lot of posts in this forum about this issue - rather than HOW the system does it. At a later time, usually during another phase of your process, you might go on to describe the HOW in more detail. Still, when you get to this stage you might think about elaborating the use case with a sequence diagram, an activity model, a collaboration diagram, a state model, or some combination of these (among other things).

Now, a test case could also be the next stage in a use case. There's some support for this in EA, but how you go about this depends on your corporate system development (or perhaps life cycle) process. Ask your testers what they are expecting, and why - both questions are important, and reasonable, if you are to be expected to satisfy their expectations. You might want to ask your developers (if they are a different group) the same questions.

This simple exercise might reveal the methodology your 'downstream' group is using, which just might fill in the blanks.

Your move!

David

[KP]

But when I send the use cases to Testing Area, they say to me that the required detail contained in the UC aren't sufficient to get the test cases...

Feedback is always good, so give the Testing Area the gift of letting them know that their feedback isn't useful or helpful. They need to let you know exactly what they expect and what they need. People on this Forum can only guess what is missing; the guys in the Testing Area KNOW, and they need to tell you.

... I ask myself another question: what makes a Use Case complete enough to make the test cases and to give the developers complete documentation (plus the SRS, other docs, etc.) to code it?

How to know when a use case is finished? As a thought exercise, give your actor a human name, call him "Trevor" or something, give him a life story, a job, maybe a wife and kids, and ask yourself why Trevor would be using your system. Then read through your use case again. If you have written anything that Trevor wouldn't know about or care about then you have probably written too much. The use case is Trevor's requirement spec, not your functional design spec.

If you can write a use case with enough detail to keep the Test Area happy but not so much detail that Trevor packs up and goes home, then you've got the balance right!

HTH

[ukmtk]

An approach recommended in "Use Case Driven Object Modeling with UML" is to use the <<precedes>> and <<invokes>> stereotypes rather than <<includes>> and <<extends>>. Note that EA supports these stereotypes by default.

[«Midnight»]

Thus my earlier suggestion to "only invoke" one use case from another.