Xpdian UML Discussion Group Google Group

Documenting use cases

2008-02-26T10:07:15Z

Use cases can be a very powerful mechanism to document specifications
that may be used for as a basis for internal software development, or
to form the basis of a RFP (Request for Proposal) document to be sent
to vendors in the search for that perfect solution.

To properly document such a specification a lot more information is

Diagrams or documentation?

2008-02-04T08:54:07Z

As accomplished modellers we often revel in the beauty of the diagrams
we craft in response to the requirements of our customers. It is so
perfect that we hesitate to add words to it lest it detract from the
wonder of the ageless creations we have wrought.

The abovementioned statement is, of course, made with tongue firmly in

The importance of developing standards

2008-01-09T07:49:49Z

Why is it important to develop UML modelling standards?

As a single modeller on your own it is easy to create models and in
the review of those models, understand the work that you do. This
changes significantly when modelling takes place in the team context
or when models are handed over for maintenance to someone else. The

What UML diagrams should be used for systems modeling

2008-01-07T07:52:32Z

As a follow-up on my previous post: [link]
I would like to take the opportunity to highlight the diagrams useful
for the modelling of systems.

In the context of this post I would like to define systems modelling
as the set of models needed for defining a system on a platform

What UML diagrams should be used for business modeling

2007-12-18T08:28:19Z

When deciding to use UML diagrams a rule that is often forgotten is
that all UML diagrams are optional. Often we model for the sake of
modelling sake and create many unnecessary diagrams that are never
used or referred to again after its creation.

To determine the diagrams you will use on a specific project, or in

Using business use cases to model the basis of business activity diagrams

2007-12-14T09:24:10Z

Often we struggle to define properly our business workflows, both from
the perspective of the level of detail at which it should be modelled
and from a completeness point of view. Another problem that faces us,
as modellers, is the reuse of activities in order to create an
environment that is lean, optimized and as standardized as we possibly

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

2007-12-10T10:11:54Z

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-

Re: How to name use cases and derive classes

2007-12-06T15:00:14Z

Absolutely!

Deriving the classes from the use case nouns is only the first step
towards building the class diagram. When the classes are defined in
this way, we still have to gather the requirements of the stakeholders
in terms of their information requirements. This may bring many more
classes to the fore. The next step would then to do a consistency

Re: How to name use cases and derive classes

2007-12-06T14:47:08Z

Certainly you will derive some classes by this naming
convention.However you may miss others. Also there may be a tendency
to define as a Use Case functionality that would be better expressed
as an operation on a class. e.g. Read Customer. Crash Car etc.

An alternative way of finding the classes (apart from a pure textual

How to name use cases and derive classes

2007-12-06T07:12:08Z

In modeling business use and platform independent use cases, a strong
case can be made for naming use cases with a verb and a noun. The verb
tells us what is done, while the noun tells us to what thing the verb
is done.

As such good use case names would be:

* Authorise user
* Create customer

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

2007-12-05T12:23:28Z

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.

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

2007-12-05T09:22:17Z

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

The process of modeling elementary use cases

2007-12-04T15:33:41Z

A definition:

An elementary use case is a use case which is executed under the
control of one primary actor, that starts and ends without any
intervening time delays.

Modelling elementary use cases - The steps:

1. Functional decomposition. Although a contentious technique to use
in the object oriented world, it serves well as a technique to get to

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

2007-12-04T15:30:25Z

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

Why Use UML?

2007-11-29T08:42:22Z

As the strategic value of software increases for many companies, the
industry looks for techniques to automate the production of software
and to improve quality and reduce cost and time-to- market. These
techniques include component technology, visual programming, patterns
and frameworks. Businesses also seek techniques to manage the