If "it" doesn't add
value, don't do "it". You might be trying to fit a square peg in a round
hole. An alternative might be to utilize requirements and business rules
for specifying the technical details of what your CRUDing. It is alright
to have test cases that map to requirements rather than use cases. Some
may think I'm speaking blaspheme, maybe I am, maybe I'm not. I agree that
generally speaking, its better to avoid CRUD style use cases in favor of more
logical or business oriented activities. It can be difficult when the
users of a system are technically minded and they actually think in CRUD
terms. In that case, you are probably better off keeping things in the
terms they are comfortable with, and use CRUD use cases. You can strive
for theoretical ideals, but, theory or not, if you get stuck with "analysis
paralysis", you may be out of a job. Better to have a job than have it
text book perfect!
Gary
Gary E. Sibbitts
Object Technology Specialist
The
Federated Software Group, Inc.
-----Original
Message-----
From: Romuald Restout
[mailto:[EMAIL PROTECTED]]
Sent: Tuesday, January 30, 2001 8:23
AM
To: 'Brian G. Lyons'; Pankaj Chatterjee; 'Rose
Forum'
Subject: RE: (ROSE) Use Case for CRUD
functions
Hi,IMHO Use case stands for the way a user will use the system.Does delete act the same as create? I don't think so.At first, pre and post conditions may be different. But business rules may be different too.If in one use-case, you have so many scenarios that do not look like each other, what is the added-value for that use-case?When you talk about "maintain blah" you're not use-case driven, you're entity-driven.Romuald Restout
Chief of Methodology
Recruitsoft - Powering Enterprise Recruiting
[EMAIL PROTECTED]-----Original Message-----
From: Brian G. Lyons [mailto:[EMAIL PROTECTED]]
Sent: Monday, January 29, 2001 3:20 PM
To: Pankaj Chatterjee; 'Rose Forum'
Subject: RE: (ROSE) Use Case for CRUD functionshiho,I'm with R. Maksimchuk here on the suspicion that your use case model is not centered around the real goals of the actors. For some articles that specifically mention this issue with respect to CRUD operations see: http://www.evanetics.com/Presentations/UC-Part1-demo.pdf and http://www.sdmagazine.com/articles/2000/0001/0001d/0001d.htm.When you are really in a pinch and you need to specify that something gets Created/Read/Updated/Deleted and there is no possible business-centric place in which this belongs, then you can fall into the "Maintain Blah" as a better option than having the four separate use cases.You are right that the pre and post conditions are notably different, but one usually finds significant business rule overlap (when you create Blah it typically must be just as valid as when you update Blah). And it never feels good to have a use-case model so blown out with four use cases for each major Blah that must be maintained.-------- b--
Brian G. Lyons
Number Six Software - Voted Rational's Best Complementary Service Provider
1655 North Fort Myer Drive, Suite 1100
Arlington, VA 22209-3196
http://www.numbersix.com-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Pankaj Chatterjee
Sent: Monday, January 29, 2001 3:55 AM
To: 'Rose Forum'
Subject: (ROSE) Use Case for CRUD functionsHi everyone,How does one depict the CRUD (create, retreive. update, delete) functions associated with database? Suppose the application I am building is related to data management, I have created a use case 'Create File', 'Remove File' for creating and removing files, but what do I do about the CRUD function required to be performed on a file? Do I draw 4 separate use cases or just one 'Edit File'? There can be a huge amount of processing logic, pre and post condition associated with each of the CRUD functionalities. Documenting this as a single use case would become quite tedious. What is the general opinion?ThanksPankaj
