Meaningless Drivel is fun!
The moose likes OO, Patterns, UML and Refactoring and the fly likes CRUD based use cases Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Engineering » OO, Patterns, UML and Refactoring
Bookmark "CRUD based use cases" Watch "CRUD based use cases" New topic

CRUD based use cases

Ranch Hand

Joined: Nov 22, 2008
Posts: 18944
We are working on a generic table maint. application that is to be "everything to everybody" .. so we are having trouble deciding how to draw up use cases .. since many books suggest that we shud not be drawing up use cases based on CRUD (Create/Retrieve/Update/Delete)model, we are having a tough time deciding use cases based on functionality. Since Add update delete will be the generic user requirements ..
does anybody have any ideas, link, books t suggest ??
John Wetherbie

Joined: Apr 05, 2000
Posts: 1449
If you have requirements/the need to do CRUD on something in your system then you should write use cases for these interactions. There hasn't been a system I've worked on that hasn't had these types of use cases. Do what you need to do to make your system successful!

The only reason for time is so that everything doesn't happen all at once.
- Buckaroo Banzai
Junilu Lacar

Joined: Feb 26, 2001
Posts: 6529

Alistair Cockburn (pronounced Co-burn, long o) discusses this in his book "Writing Effective Use Cases"
His approach is to lump everything together in a "Manage whatever" use case and then write subordinate use cases as needed for any operation that gets too complex to lump in with the others.

Junilu - [How to Ask Questions] [How to Answer Questions]
Mark Herschberg

Joined: Dec 04, 2000
Posts: 6037
Can you get your end-users to write up use-cases? I firmly believe initial use cases should only show what is happening from a users perspective. Also, if this is a "everything to everybody," then this will help you understand your user's biggest needs, and what needs to be quickly acessible to the user.
One way to do this requires training them what use cases are, and then having them write this up. That might take too much time.
A second way might be to simply ask them to give examples of what they want to happen. You'll need to giv ehtem a little guidance, like "how many steps from login to <data retrival>". Then you need to go thorugh all the use cases, and fix them up, make them clearered, and fractor out the common cases.
A third method might be to have a facilitator sit down with groups of users and "play computer." Think of it like an old faschion computer adventure game, like Zork. The facilitator stands in front of a white board and draws a login screen. The user says, "I enter my username and password, and press enter." The facilitator than draws the first data screen. The user says, "I use my flaming sword +2, er, I mean, I press the select database button." The facilitator draws a dialog with a list of databases, etc. This type of work will usually only give you mainlines, you'll need to add exception cases yourself. You should inso include some metric as youwak through it, sinc eht euser may not be awaythat he had to navigate through 4 screens to get somewhere, when he really wanted only to go through 2.
David Roberts
Ranch Hand

Joined: Nov 03, 2000
Posts: 142
I am pro-CRUD. I submitted a suggestion Allistair Cockburn that a new terminology be defined to described making a Extension a Extension Use Case. This also applies to CRUD, when you use an Extension that starts to become to important to be part of the CRUD Use Case. You can see a blurb about my concept at:
It's also a good site to check out...
David Roberts, SCJP2

David Roberts - SCJP2,MCP
I agree. Here's the link:
subject: CRUD based use cases
It's not a secret anymore!