views:

75

answers:

2

I am doing requirement analysis so I'm writing some use case diagrams. I'll try to clarify what I mean by virtual test case with the following example:

I have a set of operations, for example {create, read, update, delete}. I would like to group them in a kind of virtual use case, so I can later extend it and create a new use case with each operation. Something like:

  o
 -|- ----- ( basic operation ) <---- <<extends>> --- ( read )
 / \

The theory tells me that this is not correct, as the extensions in use cases shall introduce changes in the basic sequence of actions described by the base use case. In my case, the basic operation use case is empty of real meaning, so it has no associated sequence of actions.

This could be useful for grouping actions depending on a menu item:

File Operations = {Save, Save As, Print, Exit}

How would you express something like that?

A: 

Well the UML spec allows for a use case to be abstract. You could use the keyword of <> or italics. I would say virtual and abstract are one and the same at the use case level, this is just like with classes. Use Case is a type of classifier in UML, I think.

You could also use templating and create a template use case and require that any instances then complete the parameters of create, read, update, delete which would need to be filled in. You could still mark the template use case abstract to help clear this up. This is the more serious, captured in the model, not just the diagram, approach. Literal Strings will give you more flexability, operations would require an claas to participate and provide the operation, not as desirable.

You might also consider extension points on use cases, but I know less about these.

Ted Johnson
Do not be fooled by a down vote, this is the correct answer. I have added some details and an alternative.
Ted Johnson
+1  A: 

It appears to me from your question that one of the primary things you are attempting to do is to express a logical relationship between a number of use cases. More specifically, you are attempting to indicate that a number of use cases (e.g. 'Save File', 'Print File', etc.) are functionally related ('File Operations').

You can express such relationships by using UML packages. For example, you could create a 'File Operations' package that contains the relevant use cases: 'Save File', 'Print File', etc.

Brandon E Taylor