Disadvantages of Use Cases
mosh...@hotmail.com
presented by Jacobson ?
Thanks
Tal Moshaiov
<mosh...@hotmail.com>
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
Mr Williams
> Can anyone specify the disadvantages of the Use Case model as
> presented by Jacobson ?
Moshailov,
There are no such disadvantages.
--
len
if you must email, reply to:
len bel at world net dot att dot net (no spaces, ats2@, dots2.)
JRStern
>Can anyone specify the disadvantages of the Use Case model as
>presented by Jacobson ?
I'd have to haul out the book, but use cases are generally produced
only for a few illustrative purposes, not for all possible paths
through the system.
The problem that presents should be obvious, ... except that it is not
really meant to BE an exhaustive technique. It's good for what it is.
J.
Reini Urban
>Can anyone specify the disadvantages of the Use Case model as
>presented by Jacobson ?
if you are a single developer and have everything in your head it's
waste of time.
if you are in a team and can communicate the use case scenario strictly
verbal to your team members it's also a waste of time to write it down
formally.
if it's badly written (which happens most of the time) this WAS a 50%
waste of time, but better something than nothing.
--
Reini Urban
http://xarch.tu-graz.ac.at/autocad/news/faq/autolisp.html
Thomas Letzkus
(Reini Urban):
I kind of disagree, since in my opinion, documenting your work is
*never* a waste of time.. you could call it 'not that urgent' but even
this might be dangerous.
As a single developer, did you never have the realisation that you did
no longer understand parts of your code ?? The same could as well
happen to the model in your head...
One of my main the mottos is 'If it is not written down, it does not
exist'
If you reduce communication to 'strictly verbal' you always risk that
(a) the person with the idea in his head is ill or on vacation or
about to quit the job
(b) everybody just understood little details wrong. And a system that
does approximately what it was built for is often hard to use and
seldom worth the money and time spent.
So the most important thing for me always is to write things down. If
the job is done badly, you have at least something to improve !!
Greetings from Switzerland
Thomas Letzkus
-----------------------------------------------------------------------------------------------------
eMail: Thomas....@writeme.com
-----------------------------------------------------------------------------------------------------
NB: Delete TTT from the address to reply
Jason White
unintuitive and stilted in the absence of a well-defined user role.
We develop both user interfaces and back-end processing systems for internal
use. Use Case analysis has made the most sense when there are well-defined
users of the system (as is usually the case with user interfaces), whereas
for back-end systems, we often trip up trying to define actors for the
various server-side components, etc.
HTH
--
Jason White
Staff Software Architect
Interliant - Building Global Communities
<mosh...@hotmail.com> wrote in message news:7oja8i$7eu$1...@nnrp1.deja.com...
> Can anyone specify the disadvantages of the Use Case model as
> presented by Jacobson ?
Administrator
Use Case diagrams can provide one of many perspectives to a problem. Like
other methods of visual modelling, it is only effective if others
understand it and if you can accurately define the design specifications
from the perspective of actors, actor roles, object interactions in
sequence or collaboratively.
Whether in a one man development environment or team environment, there
should always be a distinction between the roles of the Architect and the
Engineer. In modeling from an architectural perspective, you need to
provide a communication media for ideas that you need to share with your
client or user / business representatives. At an engineering level, you
need to provide technical level information and it is always the role of
the architect to provide the documentation in the form of models and
notations. While the Use Case diagrams can provide both a user and
technical perspective of a system, I think that you need to consider your
audience and how a single model has to be interpreted as an architectural
model and as an engineering blue print. They are inherently two different
things and may require more than one model or diagram. The art is really in
being able to abstract the real world business objects in an architectural
model to a system level component. I think Use Cases are a good way to
define business logic thats why I like to start off with Use Cases. In my
experience, I prefer to apply Use Cases as an architectural model to a
fairly simple level and then detail it further or use other modelling
techniques to create the system blue print. Like CRCs, I think Use Cases
are a good way of beginning the OOAD phase of the development lifecycle.
RS
Thomas Letzkus <TTTThoma...@writeme.com> wrote in article
<37b7b1d6...@news.imtf.ch>...
> Am Tue, 10 Aug 1999 10:13:54 GMT schrieb rur...@xarch.tu-graz.ac.at
> (Reini Urban):
>
> >mosh...@hotmail.com wrote:
Ben Kovitz
> Can anyone specify the disadvantages of the Use Case model as
> presented by Jacobson ?
JRStern answered:
> I'd have to haul out the book, but use cases are generally produced
> only for a few illustrative purposes, not for all possible paths
> through the system.
>
> The problem that presents should be obvious, ... except that it is not
> really meant to BE an exhaustive technique. It's good for what it is.
and Jason White answered:
> In my (very limited) experience, Jacobson Use Case analysis can get
> unintuitive and stilted in the absence of a well-defined user role.
>
> We develop both user interfaces and back-end processing systems for internal
> use. Use Case analysis has made the most sense when there are well-defined
> users of the system (as is usually the case with user interfaces), whereas
> for back-end systems, we often trip up trying to define actors for the
> various server-side components, etc.
Excellent points, IMO. Indeed, to write a program, you need to
know the desired output for every possible sequence of inputs.
For machine-to-machine interfaces, this means defining a complete
communication protocol, not a single, linear path through system
functionality. For human-to-machine interfaces, this means
defining the response to every possible sequence of mouse clicks
and keyboard events, not just a high-level sketch of an operating
procedure--valuable as that can be at one stage of interface design.
Here's a list of difficulties with use cases, or perhaps not so
much with use cases themselves, but with what people have been
led to expect from them:
Written during the requirements phase, use cases prematurely
redirect attention away from the problem and toward the
solution. The subject matter of typical use cases is system
behavior and user responsibility. But the proper subject
matter of requirements is the problem domain and effects to be
achieved there: to cause machinery to act according to
specified rules, to generate reports and queries that
accurately reflect some part of the real world, etc. Only
when you understand the problem domain are you in a position
to intelligently design and evaluate operating procedures and
communication protocols.
A use case involving human actors is really a high-level
user-interface design, or a high-level design of operating
procedures. Asking the customer to supply you a set of use
cases amounts to asking the customer to do a major element of
software engineering for you. It also prematurely rules out
different sorts of approaches to solving the customer's real
problem--approaches that a UI designer could think up but
that a customer might never think of.
Handing off a set of use cases to programmers--as is often
done--amounts to asking them to do most of the work of UI
design as an afterthought to programming. To put it another
way, one does not implement a use case by programming.
Rather, one completes the user-interface design: one chooses
controls and menu options and writes error messages and all
the details that completely specify a screen. Then a
programmer has something to implement.
Use cases can easily have a hodgepodge quality about them.
How can you tell when they're complete? Something I've seen
is that once the customer is trained to tell you requirements
by coming up with use cases, they come up with more, and more,
and more, and more. Because use cases don't map in a simple
way to either system functionality or the problem domain, it's
difficult to tell when they overlap or when you have a
complete set of them. When a customer "asks for" a use case,
what exactly is he asking for?
Different people have radically different interpretations of
the term 'use case'. Actually, this is a problem with a great
deal of software-engineering terminology. But with regard to
use cases, interpretations range from simple, linear dialogues
between actor and system that fit into a simple paragraph, to
genuinely complete and rigorous activity diagrams that cover
all possible paths and even include multiple pathways that
take place independently of the system.
I don't know why this is, but on virtually every project I've
seen where requirements were written with use cases, there
have been strange, useless semantic arguments about what
constitutes an "actor". Jason White seems to have had this
same experience. It always seems to surround the non-human
actors.
People sometimes try to estimate development effort based on
use cases. But the effort to "implement" a single use case
can vary from a day to a year. Also, if you go with the
one-paragraph approach to use cases, there is enormous room
for ambiguity. I recently watched a single, innocent-sounding
use case turn out to map to (at least) four very complex
screens--and an enormous underestimate in the size of the
project.
The single-path approach to use cases often results in several
use cases starting with the same events. For example, "call
to off-hook phone" and "call to on-hook phone" both start by
picking up the receiver and dialing. This causes enormous
confusion, since you can't tell, by looking at each event in
the use case, whether it's an event that you are assuming will
happen or only one of many possible events that can happen.
You can see this same problem in UML's sequence diagrams.
(The obvious solution is activity diagrams, state-transition
diagrams, or a sequence-selection-iteration description of
events, such as BNF, Warnier-Orr diagrams, or Jackson
diagrams--whichever approach fits the subject matter.)
The single-path approach, as JRStern noted, is not conducive
to exhaustive, rigorous coverage of a complete set of
alternatives. Failure to think through complete sets of
alternatives and address each one is of course the main way
that bugs appear in software. Interestingly, in
_Object-Oriented Software Engineering_, p. 159, Jacobson et al.
write that "the collected use cases specify all the existing
ways of using the system." But I think it's clear that a
one-path-at-a-time or one-dialogue-at-a-time approach just
isn't sufficient for fully specifying a software system.
The use-case concept is so extremely generalized that it
provides almost no guidance. With a state-transition diagram,
you can ask, for each state, "What inputs are possible now?"
and address each one. With structured analysis, you can
follow the data flows to verify that every output has
corresponding inputs. With Jackson's problem frames, you know
to fill in all of the principal parts of the problem type,
and to check for connection domains that could introduce
distortion or delay. But with use cases, you simply make up
system functionality and actor behavior, with few criteria to
help you see if you've left something out or made a mistake.
(A number of people, such as Alistair Cockburn, have been
working on this problem with use cases, adding new concepts in
order to create a more rigorous framework.)
In summary, use cases are a strange approach to engineering,
almost directly opposed to every other description technique in
every engineering field. Whereas usually, especially in
software, we are trying to systematically cover a set of
alternatives exhaustively and with mathematical precision, one
complete subject matter at a time, use cases are a
one-case-at-a-time approach that favors sketchiness and blurs
problem domain with solution domain. A number of major thinkers
in the field, such as Bertrand Meyer and Michael Jackson, have a
lot of misgivings about them.
All that said, I do think that use cases can be valuable. I
think that the sanity of the developers is far more important to
a project's success than which of the major methodologies they
use. As long as the developers rigorously cover complete sets of
alternatives, and are flexible rather than doctrinaire in the way
they apply the methodology, they'll do good work. Use cases can
provide helpful, simple overviews that put the complexity of a
system into perspective, and they're a helpful first cut at
designing and documenting operating procedures--a frequently
omitted step (causing great frustration to people who write
on-line help and user's manuals). The problem is not use cases
themselves, but asking more of them than they can deliver.
Here are some other sources on disadvantages of use cases:
A Critique of Use Cases (interesting transcript of a discussion
on comp.object)
http://www.kinetica.com/ootips/use-cases-critique.html
The Use Case Principle (a critique by Bertrand Meyer, with
emphasis on the clash between use cases and the benefits of
object-orientation)
http://www.elj.com/elj/v1/n2/bm/use-cases/
Use-Cases Considered Harmful When... (Peter Coad warns against
using them to shape an object model)
http://www.oi.com/coad-letter-archive/34
Also, there's a wonderful article by Edward V. Berard, titled "Be
Careful with 'Use Cases'". I can't find it anymore, but it used
to be at http://www.toa.com/pub/html/use_case.html . If anyone
knows where it is now, please post!
--
Ben Kovitz <apt...@chisp.net>
Author, _Practical Software Requirements: A Manual of Content & Style_
http://www.amazon.com/exec/obidos/ASIN/1884777597
http://www.manning.com/Kovitz