Abstraction - How to model use case diagrams at a consistent level

[fatass]

The OMG UML version 2.1.1 specification defines a use case as follows:

A use case is the specification of a set of actions performed by a
system, which yields an observable result that is, typically, of value
for one or more actors or other stakeholders of the system.

The definition of the use case is wide enough that different modelers
may model at different levels of abstraction. Whereas one modeler may
see: Maintain Customer as a use case, another modeler may see that as
a package containing use cases like: Create Customer, Read Customer,
Update Customer and Delete Customer.

While this may be tolerated in simple environments, it presents
problems in an environment where different modelers may use and
support each others models. The inconsistency of those varying levels
of abstraction also makes for extremely difficult communicatiion with
different stakeholder groups.

One way of solving this would be to clearly define the level to which
use cases should be modeled to. This may be done in the UML standards
of the organization.

A definition that we developed at Xpdian is that of the elementary use
case. An elementary use case is defined as:

A self contained unit of interaction, executed by a single actor, from
start to finish, with no intervening time delay.

The higher level functions can then be shown as packages with use
cases modeled when the above definition becomes true.

[The_Ghost]

Yes, but using different levels of abstraction is a flexibility. It's
good that definition of "elementary use-case" as a bottom level of use-
case abstraction, I agree. But I think that it's not good to remove
higher levels of use-case abstraction. I think that composition of
different abstraction levels is good. In Your example with Maintain
Customer. This high level use-case, could contain Create Customer,
Read Customer and etc. as more detailed description. Or they to extend
Maintain Customer use-case.

[fatass]

I am happy with what you are saying. My approach implies that the
higher level use case is represented with a package which contains the
elementary use cases. In my model of the world - elementary use cases
- use cases are modeled at only one level of abstraction to simplify
the model for the target audience.

Having different levels of abstraction in the same model creates
confusion among the user/customer/developer community and presents a
problem if you want to use the use cases as a basis for project
estimation and planning.

> > cases modeled when the above definition becomes true.- Hide quoted text -
>
> - Show quoted text -

[The_Ghost]

Yes, this approach is detailed one and is easy to read. But what about
if You want to show high level functionality without digging down to
detail. Or You may do capturing requirements first as more coarse way
with the client and then go deep use-case by use case and in the same
moment keep the links between coarse use-case model and detail use-
case model.
Other thing is if You want to present your functionality as new to
lower level architects or implementers. It could be easier to show
first the big picture (as a coarse model) and then go in detail.
My point is that packages are (in my opinion) not best artifacts to
express high level of use-case abstraction. I think that is better to
use traceability between use-case levels as links.
But I supports You about the idea for the lowest level of elementary
use-cases is good to be as a bottom line for use-case model.