"CRUD"ing in Use Cases

[mhdhallak]

Hi

This question is regarding best practices for developing use cases. For those of you familiar with the term CRUD, which stands for Create Retreive Update Delete, my question is:

Do we model each operation independently or is it a wrong practice to combine them all in one use case for the sake of brevity?

Say for example, the process of creating, retreiving, updating and deleting user accounts (or possibly any other data which is considered as Reference data).

Any thoughts?

[jeshaw2]

Unless a company is a data processing service bureau, they don't have CRUD as a business goal.  As Use Cases are goal oriented, I don't Model CRUD at all;  focus on the goals of the business actors.  Restate your goals a business goal not as a data processing goal.

my 2 cents.

[mhdhallak]

Unless a company is a data processing service bureau, they don't have CRUD as a business goal.  As Use Cases are goal oriented, I don't Model CRUD at all;  focus on the goals of the business actors.  Restate your goals a business goal not as a data processing goal.

Sounds convincing. I keep stumbling and making developers' mistakes (having been one).

Thanks!

[«Midnight»]

Let's look at this a bit differently...

In your planned application, is it likely in the normal course of business that some user (or process) will drop by and create a record, review the record, edit that record, and then delete it, all in a single session. If the answer is "yes" then you should have a use case to accomplish this. [You might also want to consider reviewing the busienss case for the system; there might be savings in personnel and computer costs if it were not built.]

If the above case seems unlikely, then don't create a use case.

Of course, it is likely that each of the components of CRUD will be addressed. While they are all parts of the life cycle of a datum, they are likely to be performed at separate times, perhaps by different people or systems (i.e. Actors). Sometimes a component may be performed multiple times - reading or updating perhaps - by different means. Sometimes a component likely occurs only once - creation or deletion - althought possibly by different means (for example, creation might be through a dialog, bulk upload, copying another datum, etc.). Each of these is a candidate for a use case at some level or another.

When taken together, the suite of use cases which involve this datum (or the higher level element it is part of) should illustrate the live cycle of the datum. They should (also) show the way in which the datum interacts with users or agents at the boundaries of the system (or some subset thereof) at the various levels of abstraction that are necessessary for and meaningful to the description of the system.

IMHO YA 0.02 CAD.

David

[mhdhallak]

When taken together, the suite of use cases which involve this datum (or the higher level element it is part of) should illustrate the live cycle of the datum. They should (also) show the way in which the datum interacts with users or agents at the boundaries of the system (or some subset thereof) at the various levels of abstraction that are necessessary for and meaningful to the description of the system.

IMHO YA 0.02 CAD.

David

I honestly did not get what you're trying to say here. Are you suggesting we break out the CRUD into seperate use cases if that's meaningful in the context of the system we're modelling?



p.s, what's "IMHO YA 0.02 CAD"  

[«Midnight»]

Yes I am. Unless of course there is a reasonable scenario where someone (or something) would do all four at one sitting.

[There might be cases where you want to show something as if this were the case, for presentation purposes, but I'm talking about design here.]

Im My Humble Opinion, Yet Another 2 cents (in my local currency = Canadian Dollars) worth.

[mhdhallak]

I see.

Off the record, why do people around here keep count of how much their answers are worth ? Are you eventually getting paid for these answers or is it like a point system as in Experts Exchange?

[«Midnight»]

No, it is a function of the bulletin board application (YABB).

This is primarily a forum for user participation. Ask questions, and perhaps another of us, or the Sparx people, can answer them. Perhaps your questions or concerns have been expressed before, and the earlier responses will save you time and hair-pulling.

You can also express opinions, provide suggestions and requests (thus the appropariate forum section) etc.

It is another case of "what goes around comes around."

[thomaskilian]

David, what you are telling is that there should be a single UC called Maintain Whatever. Inside you will find the CRUD, of course. And what all people are praying is NOT to create 4 UCs called C Whatever, R Whatever, U Whatever and D Whatever. Hopefully we're no the same line?

My 0.02 EUR
Hu. Too slow. I wish I'd get payed for this

[«Midnight»]

Thomas,

Depending on the level of abstraction and the intended audience.

I don't advocate a single scenario for CRUD, at least as far as, say, how a given user will interact with the system. It is doubtful that in a single session all of these functions would occur to the same item.

The create scenario(s) is(are) likely to be performed once per item, and in only one way for any particular item (although there may be many ways collectively). Read and Update are likely to occur zero to many times, with potentially many ways applicable to an item over its lifetime. Deletion is also likely to be only one (again, from some number of possibilities) for each item.

There may also be several different actors involved. Perhaps the roles that create and edit items are different than those who mearly read them. Perhaps yet other roles perform the eventual deletion.

In a given use case model one might see all of these, at least at a high level. But I maintain that it is unlikely that a single scenario will encompass them at a practical level. [Thus my point about presentation versus design.]

[jeshaw2]

The term CRUD relates to transactions (not goals) that maintain a database of information, be it a manual or automated repository.  Processing these transactions is very low level use case stuff and is not of much interest to stakeholders; because they have difficulty relating these transactions to business goals...they see it is somehow needed, but they can't assign much value to it beyond its being a necessary evil and a cost of doing business.  They don't see CRUD as a competitive weapon that adds value to the business proposition.  Therefore, they will not become fully engaged with you on repository issues, they will "leave all of that stuff to you" to figure out on your own.

Lets consider a sales system.

Obviously, the system needs to create account records for new customers in the data base.  But ask yourself why??  Is it because:

• The business needs to define the terms of its business relationship with that customer?
• The business wants to communicate those terms to employees?
• These terms impact the processing of customer orders
• etc.?
  

The high level goal of the business is to make persistent & available the defined terms of doing business with a given customer and to apply those terms as policy governing on-going interactions with that customer.  The goals define what is to be achieved, not how the system achieves it.

This "stuff" about defining business relationships and policy that governs business transactions is the heart and sole of what a manager does and they will become fully engaged in that discussion.

If you say to a stakeholder, in a use case, that the system will create and store an account master record in the database, the stakeholder's eyes will cross and they will nod their head knowingly and say "fine".

If, on the other hand, you say that the system will record the terms of the business relationship, the stakeholder will want to discuss specify, just what kind of terms you are dealing with.

In my mind CRUD is not a business goal, making critical information persistent and available is a business goal.  As I said before, restate CRUD in business terms, not EDP terms;   you'll get better funding for your project that way.  

[mhdhallak]

I sort of agree with jeshaw2's point of view on this matter. CRUDing use cases would obscure overall business goals and should therefore be avoided and replaced with simple statement that says what the CRUD is saying in simple business terms.

Later on in the design stage, this use case will be expanded and the requirements to achieve this use case will be identified and subsequently CRUDed.

lol, I just made up a whole new word and a verb to go with it. Don't you just love English :p

[jeshaw2]

UML allows extentions to the language also  

[Weedman]

We do use case for CRUD but during the design/implimentation phase of the project as CRUD comes to light based on the implimentation of the use cases.

The users/stakeholders get a view of use case to signoff on which are fairly implimentation free, and if CRUD is in them they are high level black box use cases.

Of course my opinion.

[TrtnJohn]

The term CRUD relates to transactions (not goals) that maintain a database of information, be it a manual or automated repository.  Processing these transactions is very low level use case stuff and is not of much interest to stakeholders; because they have difficulty relating these transactions to business goals...they see it is somehow needed, but they can't assign much value to it beyond its being a necessary evil and a cost of doing business.  They don't see CRUD as a competitive weapon that adds value to the business proposition.  Therefore, they will not become fully engaged with you on repository issues, they will "leave all of that stuff to you" to figure out on your own.

Lets consider a sales system.

Obviously, the system needs to create account records for new customers in the data base.  But ask yourself why??  Is it because:

• The business needs to define the terms of its business relationship with that customer?
• The business wants to communicate those terms to employees?
• These terms impact the processing of customer orders
• etc.?

The high level goal of the business is to make persistent & available the defined terms of doing business with a given customer and to apply those terms as policy governing on-going interactions with that customer.  The goals define what is to be achieved, not how the system achieves it.

This "stuff" about defining business relationships and policy that governs business transactions is the heart and sole of what a manager does and they will become fully engaged in that discussion.

If you say to a stakeholder, in a use case, that the system will create and store an account master record in the database, the stakeholder's eyes will cross and they will nod their head knowingly and say "fine".

If, on the other hand, you say that the system will record the terms of the business relationship, the stakeholder will want to discuss specify, just what kind of terms you are dealing with.

In my mind CRUD is not a business goal, making critical information persistent and available is a business goal.  As I said before, restate CRUD in business terms, not EDP terms;   you'll get better funding for your project that way.  ;D

Great post Jim!!

Every developer turned architect should print this out and paste it to their wall.  This simple example really highlights one of the biggest problems we have in systems design today.  Failure to focus on the true business requirements and benefits of a system is the #1 cause of product failure.