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

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

Post by Car » Fri, 01 Aug 2003 05:52:52



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?

 
 
 

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

Post by Corn » Fri, 01 Aug 2003 06:48:32



Quote:> How does one model CRUD interactions using OOAD?

--snip, use case discussion--

IMHO, an interaction between a user and a system can have 1 of 2 styles, the
object oriented style in which the user more or less interacts with objects
directly (the CRUD operations; creating an email, closing the application)
and a dialog style (the user does this, the system asks that, the user
responds, the system reports 'foo', 'do you really want to shut down the
computer?'), like having an attendant on the other side of the interface
that does the work on the objects for you.
These 2 are very distinct and should be treated as such. Mixing them up
results in applications that are not intuitive.
Use Cases are very suited to model the dialog style. Dialog styles are
favorable when the user does not have a lot of insight in the *user* model
of the app and/or does not need a lot of control.
Interacting with objects is favorable when the user needs lots of fine
control but does require more comprehension. Use Cases are the wrong tool to
model this style. Better would be to describe the user model; describe which
objects the user can percieve, which properties are either readable and or
updatable and what conditions must be met for the CRUD operations on those.

Corno

 
 
 

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

Post by R Ferguso » Sat, 02 Aug 2003 04:16:38


CRUD is useful but not a set of use cases in my view. CRUD is a method
of analyzing data for purposes of creating a data architecture and
persistant storage. An OO orientation is likely to produce some
different viewpoints. In other words, I would use CRUD analysis to
confirm the completeness and consistency of the persistent storage
model, but not to develop use cases.

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

 
 
 

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

Post by Robert C. Mart » Sat, 02 Aug 2003 12:14:42



this on (or about)  30 Jul 2003 13:52:52 -0700, :

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

As you elaborate the use case scenarios, you are almost certain to
mention all of the CRUD operations.  This is not a bad thing.  Nor
does it have anything at all to do with OOAD.  It's just the way you
describe the details of the use case operations.

As you begin to design the structure of the software, the partitioning
of the CRUD operations becomes important.  You might have Facade
classes that have CRUD interfaces:

public interface PlayerDB {
  public Player createPlayer(PlayerData player);
  public void   deletePlayer(String playerId);
  public Player readPlayer(String playerId);
  public void   updatePlayer(PlayerData player);

Quote:}

Or you may decide to use writeable objects:

public interface Player {
  public void read();
  public void update();
  public void create();
  public void delete();
  // and many other methods

Quote:}

Or you may decide to use any of a dozen other techniques like Proxy,
Stairway to Heaven, etc, etc.

These choices have almost nothing to do with the use cases.  They are
decisions made as part of the architecture of the system.

Robert C. Martin  | "Uncle Bob"                  

PO Box 5757       | Tel: (800) 338-6716        
565 Lakeview Pkwy | Fax: (847) 573-1658           | www.objectmentor.com
Suite 135         |                               | www.XProgramming.com
Vernon Hills, IL, | Training and Mentoring        | www.junit.org
60061             | OO, XP, Java, C++, Python     |

 
 
 

1. Modelling CRUD functions with Use Cases

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.

2. Compare and contrast...

3. Gaylee - read/delete

4. Excel

5. CVS is deleting files during an update - Help!

6. Good Voice over IP course (Re: Steve Evans posting)

7. Reading RL02's created on a PDP11/23 running RSTS

8. COSMOS news group?

9. Delete historial without deleting the goto toolbar

10. CVS: Can "update" be told to create new subdirectories ala "checkout"?

11. What is the difference between create table & create table with disable numerics

12. Problem in Creating Table, Package thr' Deployment > Create Table

13. Training in OOAD