Modelling CRUD functions with Use Cases

Modelling CRUD functions with Use Cases

Post by Rafi Bry » Wed, 26 Jan 2000 04:00:00



What is the correct or standard way of specifying CRUD (create, update,
delete)  functions with use cases. The approach I have been taking has been
to specify one use case called 'Manage x' where x is the business object
being acted on (orders, products etc). This makes for a rather cumbersome
use case as the processes and validation rules are slightly different for
each action. I find that I tend to write complicated sentences (eg: 'The
user enters/modifies the customer's address and then prompts the system to
add/update the record')

An alternative approach is to have a seperate use case per action, but this
tends to inflate the number of use cases across the system (while creating
an annnoying repetition within the specification), and also you need to
repeat the common steps such as locating the correct object in the case of a
modify or delete. The advantage is that use case names are more aligned with
the actual user goals.

If anyone has a better approach I would be interested in hearing it.

 
 
 

Modelling CRUD functions with Use Cases

Post by Dr2B_Dou » Wed, 26 Jan 2000 04:00:00


I model use case behavior with message sequence diagrams using either CASE
tools set up for that purpose of Visio Professional 5.0.  (I like PowerPoint
for presentation cartoons, but it is painful to try do any complex diagrams
such as a message sequence diagram and therefore I do not use it for
technical graphics.)

It is easy to copy and paste the redundant parts of the behavior using a
message sequence diagram and then include the varying paths.

Alternatively, on the message sequence diagram, you can annotate the
conditions under which each path or action is taken.


Quote:> What is the correct or standard way of specifying CRUD (create, update,
> delete)  functions with use cases. The approach I have been taking has
been
> to specify one use case called 'Manage x' where x is the business object
> being acted on (orders, products etc). This makes for a rather cumbersome
> use case as the processes and validation rules are slightly different for
> each action. I find that I tend to write complicated sentences (eg: 'The
> user enters/modifies the customer's address and then prompts the system to
> add/update the record')

> An alternative approach is to have a seperate use case per action, but
this
> tends to inflate the number of use cases across the system (while creating
> an annnoying repetition within the specification), and also you need to
> repeat the common steps such as locating the correct object in the case of
a
> modify or delete. The advantage is that use case names are more aligned
with
> the actual user goals.

> If anyone has a better approach I would be interested in hearing it.


 
 
 

Modelling CRUD functions with Use Cases

Post by Clive Haywa » Wed, 26 Jan 2000 04:00:00



>What is the correct or standard way of specifying CRUD (create, update,
>delete)  functions with use cases. The approach I have been taking has been
>to specify one use case called 'Manage x' where x is the business object
>being acted on (orders, products etc). This makes for a rather cumbersome
>use case as the processes and validation rules are slightly different for
>each action. I find that I tend to write complicated sentences (eg: 'The
>user enters/modifies the customer's address and then prompts the system to
>add/update the record')

>An alternative approach is to have a seperate use case per action, but this
>tends to inflate the number of use cases across the system (while creating
>an annnoying repetition within the specification), and also you need to
>repeat the common steps such as locating the correct object in the case of a
>modify or delete. The advantage is that use case names are more aligned with
>the actual user goals.

>If anyone has a better approach I would be interested in hearing it.

Using the 'Manage x' style you could simplify the wording by writing the
main line use case without the slashes (eg: 'The user enters the
customer's address').  Then place the alternative (eg: 'The user
modifies the customer's address') in an extension or variation.

--
Clive Hayward

 
 
 

1. How to model CRUD (Create, Read, Update, Delete) with OOAD?

How does one model CRUD interactions using OOAD?

Most of the documentation I have found says that one should favor use
cases that are more meaningful to a user than to use CRUD use cases.
I believe that this is correct because it gives the stakeholders a
clearer description of what the system is supposed to do.  However, I
am having a difficult time figuring out how one writes a scenario for
a use case that implicitly contains several CRUD interactions.  Take
for example a system that maintains a roster for a football teams and
keeps track of each players salary and position it can then generate
reports such as player summary, salary by player, average salary per
position, etc.

The CRUD use cases would be:
(Create,Read,Update,Delete) Team = 4 use cases
CRUD Player (Update Player may be extended by CRUD Position, CRUD
Salary)

Even with this simple example the 16 CRUD use cases become hard to
manage and the meaningful use cases have not even been identified yet.
All a user cares about is getting a report that is meaningful to them.
 If all of the Team and player information was entered and kept up to
date by magic that would probably be ideal to the user.  Since the
CRUD use case aren't meaningful I remove them.

Assume that some of my "real" use cases are:
Generate Salary Report
Generate Team Roster

Use Case: Generate Salary Report
A scenario could be (Open to suggestions):

1.  The user indicates that they would like a salary report.
2.  The system prompts the user to indicate the teams that they would
like to include in the report and the field to generate the report on
(i.e. player or position)
3.  The user enters the teams and selects the field to generate the
report.
4.  The system generates a salary report based on user inputs.

Assume that the customer is happy with this use case but wonders how
is the team date managed.  Unfortunatly, it isn't magic and it is
based on CRUD interactions.  I compromise and add a use case:
Maintains Teams that implicitly contains all of the 16 CRUD use cases.

How do I write a scenario for Maintain Teams that indicates all of the
CRUD actions?

Possible ideas are:
1.  Have one use case that contains multiple scenarios but I think
that gets messy.
2.  Ignore the details and only say in the scenario that "The user
maintains the teams"
3.  Have Maintain Teams include all 16 CRUD use cases.

At what point in OOA/OOD does one introduce the CRUD interactions if
they are not included in the use case model?

2. XSLT Limitations

3. Task Analysis models --> Use Case-based models....

4. Hello?

5. References: function points and use cases

6. How do you make Solaris see a new array w/o rebooting...

7. Use case model/diagram confusion

8. On-board YCbCr -> RGB conversion on Creator3d - how to use this?

9. Example for Insufficiency of Use Case Model in Requirements Spec

10. Software Automatically Generates Test Cases from SDL Models

11. Generating Object Model : A CASE tool

12. difference between Use case modelling & Formal methods

13. CASE NEEDED for DEC Pent.60 (model #810ww)