Sign in / up

back to article Vague and ambiguous use cases revisited

Oh no, not again: the industry's gone and divided into two camps. In Camp Purity, there's the group insisting that use cases must be abstract and free of any specific technology or UI feature. Simply heavenly! Useless, but heavenly. Then in Camp Gritty, there's the group politely whispering that use cases work better when they' …

COMMENTS

House rules Send corrections
This topic is closed for new posts.
  1. AndyB

    I'm for camp Realistic.

    The very fact that Use Cases are written by "a non-technical person who spends a lot of time talking to the customers and end-users" is the best argument against 'Camp Gritty'.

    You often (usually, in my experience) end up with a project that is driven by the customer's expectations of the UI rather than the business logic the application is supposed to model.

    The upshot of this is software engineers (coders) trying to bang together business objects and UI that are as incompatible as the proverbial square peg and round hole.

    I cannot count how many WTF moments I've had when a Use Case or functional spec describes a UI operation that is either:

    Not available in the standard UI toolkit requiring the purchase of 3rd party components or the design of a custom component (neither of which has been costed)

    OR

    Is totally incompatible with the underlying business objects and/or logic.

    Then you either have to try to explain to the customer why they can't have the UI they were sold OR ask them to pay more OR swallow the additional costs and time involved in making the UI the customer was sold.

    0 0
  2. Kurt Guntheroth

    design walkthroughs

    I've heard these detailed, implementation-specific "use cases" called design walkthroughs. Writing down a natural-language description of what happens when you push to "do it" button can be very helpful. It starts out "The U process wakes on windows event V, and calls the W method of class X. X.W calls Y.Z to do the actual processing...

    When you try to write an active-voice text narrative of your design, you quickly find out if you know all the responsibilities of all the classes in your system, because otherwise you have sentences in the design walkthrough that look like "then magic happens from out of nowhere and..."

    In my practice I use use cases as tools to elicit user needs (so they need to be implementation-free). I use design walkthroughs to test the completeness of a selected design (so they need to be detailed and specifid). I don't do a lot of UML modeling. Since I use text narratives for two quite different purposes, I think of them as two different things. Maybe there is confusion in the user community about what we're trying to accomplish.

    0 0
  3. Brian Miller

    Hallucinating Morons

    While it is true that you need paperwork to complete a project, at some point you have to realize there are individuals who don't actually want to get anything done. It doesn't matter that you have reasonable specifications and you have a reasonable design that leads to a reasonable solution. They are in whalesong nirvana, and no matter what they aren't leaving it. Projecturbation is all they care about.

    In order to have an agile project, you have to have agile minds. Without agile minds, everything gets hung up on a zillion stupid specifications and statistics. When you have people who don't understand the basic problem, don't expect them to come up with a solution.

    We've been writing software for about maybe fifty years. What do we have to show for it? Nothing. According to Adm. Grace Hopper, COBOL was supposed to have libraries of code written by industry organizations. That didn't happen. Do we have any real software engineering yet? No.

    What we have are a plethora of languages that try to restrict the programmer into using good techniques. Take a look at F# and Haskell. Notice how much similarity they bear to Jackson Structured Programming. Hello! JSP was designed for COBOL. But what do we see? The programmers have to be coerced into using good techniques by the language. Therefore C is bad and F# and its ilk are good. Design and problem-solving techniques have to be put into the fundamental use of the language before the programmer will use them. (Do you know how much supposedly object-oriented C++ code I've seen that still uses goto? Leave 1967 behind!)

    We have plenty of good design practices. But does anybody care about putting them to use? No. Why? Perhaps because it takes work. Yes, that horrible thing, work. Now we are trying to put good design practices into use by incorporating them into a language. And the language has to be made inscrutable in order to implement a design technique. The *design* concepts behind OO and functional programming are simple. But they have spawned horrific languages to implement simple techniques.

    Now what attrocity will be spawned in the industry's various semantic wars? Obviously there are no lessons learned from our past adventures. The question of "how much hard data should a use case contain" sparks a big debate. Worthless! Leave the whalesong, projecturbation, bongs, goto's, and crack out of the project and the software.

    0 0
  4. Andy Davies

    Brian Miller...

    has said it all really - what goes around comes around, still wrong!

    Actually, if he's been in 'Data Processing' as long as he says he has it's mildly surprising we haven't met <bg>.

    AndyD 8-)#

    0 0
  5. Simon Parmenter

    Anyone for applying AOP to use cases?

    I find myself agreeing (mostly) with Brian Miller again. Although I would like him to give a few examples of his 'horrific languages".

    Er, I've used a goto in a compiled as C++ program. I'm not religious about this or any other aspect of coding.

    I wonder what Brian thinks of AOP? The new paradigm for solving all of software's ills. It can be applied to every aspect of software production. One aspect that it is applied currently to some frameworks is the the garbage collector. The garbage collector, odd term don't you think? Makes one wonder about the term 'garbage in - garbage out'. Now on a two weekly collection.

    Now then, where are we supposed to put the braces?

    0 0
This topic is closed for new posts.