Abstraction - How to model use case diagrams at a consistent level - Xpdian UML Discussion Group

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

fatass

More options Dec 5 2007, 7:23 am

From: fatass <freeman3...@gmail.com>

Date: Wed, 5 Dec 2007 04:23:28 -0800 (PST)

Local: Wed, Dec 5 2007 7:23 am

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

  Reply to author
  |
  Forward
  | Print
  | View thread
  | Show original
  | Report this message
  | Find messages by this author
  

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 -

Reply to author Forward