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.
On Dec 5, 2:23 pm, fatass <freeman3...@gmail.com> wrote:
> 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.
> On Dec 5, 11:22 am, The_Ghost <var...@gmail.com> wrote:
> > 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.
> > On 4 Дек, 17:30, fatass <freeman3...@gmail.com> wrote:
> > > 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.- Hide quoted text -
> > - Show quoted text -
