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
*
*************************************************************************

Reply via email to