My personal preference is to try and come up with a 1<->1 relationship
between use cases and what I think will make sensible test cases.
My use cases turn out to be more detailed than those that I see in RUP
literature, but if I follow the guidelines below [If "it" doesn't add
value, don't do "it". ], I believe I am justified, since I am adding value
to the testing activity.
Les.
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 functions
hiho,
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 functions
Hi 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?
Thanks
Pankaj
************************************************************************
* Rose Forum is a public venue for ideas and discussions.
* For technical support, visit http://www.rational.com/support
*
* Admin.Subscription Requests: [EMAIL PROTECTED]
* Archive of messages:
http://www.rational.com/products/rose/usergroups/rose_forum.jtmpl
* Other Requests: [EMAIL PROTECTED]
*
* To unsubscribe from the list, please send email
*
* To: [EMAIL PROTECTED]
* Subject:<BLANK>
* Body: unsubscribe rose_forum
*
*************************************************************************