Sparx Systems Forum

Discussion => Uml Process => Topic started by: mhdhallak on May 23, 2006, 03:01:02 am

Title: "CRUD"ing in Use Cases
Post by: mhdhallak on May 23, 2006, 03:01:02 am
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?

Title: Re: "CRUD"ing in Use Cases
Post by: jeshaw2 on May 23, 2006, 03:42:20 am
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.
Title: Re: "CRUD"ing in Use Cases
Post by: mhdhallak on May 23, 2006, 04:13:21 am
Quote
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!
Title: Re: "CRUD"ing in Use Cases
Post by: «Midnight» on May 23, 2006, 04:20:03 am
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
Title: Re: "CRUD"ing in Use Cases
Post by: mhdhallak on May 23, 2006, 04:38:11 am
Quote
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"  ???
Title: Re: "CRUD"ing in Use Cases
Post by: «Midnight» on May 23, 2006, 04:45:20 am
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.
Title: Re: "CRUD"ing in Use Cases
Post by: mhdhallak on May 23, 2006, 05:22:12 am
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?
Title: Re: "CRUD"ing in Use Cases
Post by: «Midnight» on May 23, 2006, 05:27:03 am
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."
Title: Re: "CRUD"ing in Use Cases
Post by: thomaskilian on May 23, 2006, 05:27:50 am
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
Title: Re: "CRUD"ing in Use Cases
Post by: «Midnight» on May 23, 2006, 06:03:49 am
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.]
Title: Re: "CRUD"ing in Use Cases
Post by: jeshaw2 on May 23, 2006, 06:34:21 am
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 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
Title: Re: "CRUD"ing in Use Cases
Post by: mhdhallak on May 23, 2006, 07:08:30 am
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
Title: Re: "CRUD"ing in Use Cases
Post by: jeshaw2 on May 23, 2006, 07:17:17 am
UML allows extentions to the language also  ;D
Title: Re: "CRUD"ing in Use Cases
Post by: Weedman on May 23, 2006, 07:53:51 am
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.
Title: Re: "CRUD"ing in Use Cases
Post by: TrtnJohn on May 23, 2006, 09:13:36 am
Quote
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.

Title: Re: "CRUD"ing in Use Cases
Post by: thomaskilian on May 23, 2006, 01:46:12 pm
Indeed :)
But just to turn the sense of my previous post inside out. What if you model the business of some IT management? They care about CRUD and how it is performed. So it certainly also depends on the level/boundary you're in.

Another 0.02€
Title: Re: "CRUD"ing in Use Cases
Post by: sargasso on May 23, 2006, 05:20:52 pm
20c AUD!  ;D

Occassionally, I have found that it is helpful to add constraints (postconditions) to use cases that annotate the CRUD effects of the use case.  For example, UC "Join Frequent Traveller Club", in our current system does not Create a member record - that record is automatically created when they make their first booking. This use case Updates the record.

Caveat!  The model has been created for test design purposes, not for system design!!  So these facts are pre-ordained by the system not by any design logic.

bruce
Title: Re: "CRUD"ing in Use Cases
Post by: jeshaw2 on May 23, 2006, 07:18:47 pm
Quote
Indeed :)
But just to turn the sense of my previous post inside out. What if you model the business of some IT management? They care about CRUD and how it is performed. So it certainly also depends on the level/boundary you're in.

Another 0.02€
I believe I made provision for that in my first post in this thread.  ;)
Title: Re: "CRUD"ing in Use Cases
Post by: thomaskilian on May 24, 2006, 12:24:38 am
Quote
I believe I made provision for that in my first post in this thread.  ;)

I may have forgotten that meanwhile. I'll take back my 0.02€ ;D
Title: Re: "CRUD"ing in Use Cases
Post by: mhdhallak on May 24, 2006, 12:49:26 am
Quote

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.



This is a bit off topic, but how can I speed up this transformation of mindset. That is, technically-inclined developer to business-focused architect.

Any books, websites, articles etc you recommend to help in this process? What I'm concenrned with here is the best practices for doing things in software analysis and architecture world. I mean, I already grasped most of the theory behind tools such as UML, but what remains are the best practices which usually come through life-time work experience.

AL
Title: Re: "CRUD"ing in Use Cases
Post by: thomaskilian on May 24, 2006, 12:57:09 am
I know you will get a quite number of recommendations. Mine is for Bittner's Writing Use Cases (which I choosed from a recommendation here earlier). It opens your mind on what should be the focus. And it is written from a daily practice.

However, nothing will beat your own practice  ;)
Title: Re: "CRUD"ing in Use Cases
Post by: Paolo F Cantoni on May 24, 2006, 01:02:45 am
Quote
However, nothing will beat your own practice  ;)
Right on Thomas,

This reminds me of the aphorism:

An amateur practices until they get it right.

A professional practices until they can't get it wrong...   8)

Paolo
Title: Re: "CRUD"ing in Use Cases
Post by: mhdhallak on May 24, 2006, 02:03:27 am
Sumbled upon this site

http://www.pols.co.uk/use-case-zone/use-case-papers.html

Got some great papers on use cases.
Title: Re: "CRUD"ing in Use Cases
Post by: «Midnight» on May 24, 2006, 04:56:27 am
Or, perhaps to take you back to the original question...

Take a look at Use Cases: Patterns and Blueprints, but Overgaard and Palmkvist. This goes into CRUD models, and uses non-trivial examples.
Title: Re: "CRUD"ing in Use Cases
Post by: jeshaw2 on May 24, 2006, 06:36:21 am
Quote
This is a bit off topic, but how can I speed up this transformation of mindset. That is, technically-inclined developer to business-focused architect.
Harrumph!  An architect is still on the development side and still needs a technical mind set to function well.  Architects are use case readers, not use case writers.  An architect's strength still lies with deep technical knowledge of an even broader range of technologies.  A business analyst has a management mind set and credentials to earn the respect of other managers.  In my experience, a business-focused architect is an oxymoron.  If I found one, I suspect it would be someone trying to live in both worlds and not doing well in either.  There are, however, some exceptions to be found in this forum   ;)

The best practice for developing a management mind-set is to "walk the walk" not just "talk the talk", nor "read the book".  To become a Business Analyst, become a manager with profit making responsibilities.  Give up that security blanket of deep technical IT knowledge and commit to learning deeply what a manager desperately needs in order to be successful.  It only takes a few weeks, of being in fear of losing one's job because you can't get the past-due shipments out the door, to make the mind-set switch. ;D

Management skills are completely different from IT developer skills.  Read management books written by leading managers, not ones written by leading technical gurus.  ReadAsk your management for a three month transfer to a line management position as part of your training to become an business analyst;  they'll think that a smart thing to do if they support your career goals.  In its heyday, the Pennsylvania Rail Road required its software developers to be railroaders first and developers second, not the other way around.  If you are in a large corporation, check out their managent trainee program; see if you can get into it.

Well anyhow, that's how I did it.  I now yield my soap-box to other pontificators. ;)  
Title: Re: "CRUD"ing in Use Cases
Post by: Paolo F Cantoni on May 24, 2006, 06:59:59 am
Don't forget Peter F. Drucker...

Paolo
Title: Re: "CRUD"ing in Use Cases
Post by: «Midnight» on May 24, 2006, 07:26:40 am
I'm from Canada; we can never forget Drucker...
Title: Re: "CRUD"ing in Use Cases
Post by: thomaskilian on May 25, 2006, 12:07:05 am
As we are in it: Brooks Mythical Man-Month and of course almost all of Tom DeMarco's books (esp. Peopleware).
Title: Re: "CRUD"ing in Use Cases
Post by: mhdhallak on May 25, 2006, 12:14:38 am
Thanks jeshaw2. That was pretty helpful.
Title: Re: "CRUD"ing in Use Cases
Post by: Kevin Brennan on May 25, 2006, 08:22:41 am
Must...resist...urge...to...self-promote...

In terms of books I would recommend David Aaker's Developing Business Strategies over Porter..it's less dense and covers the same ground.

The British Computer Society has a book on Business Analysis that looks to have pretty good coverage of topics (warnign: I haven't read it yet, so can't endorse it).
Title: Re: "CRUD"ing in Use Cases
Post by: TrtnJohn on May 25, 2006, 10:26:50 am
Quote
Harrumph!  An architect is still on the development side and still needs a technical mind set to function well.  Architects are use case readers, not use case writers.  An architect's strength still lies with deep technical knowledge of an even broader range of technologies.  A business analyst has a management mind set and credentials to earn the respect of other managers.  In my experience, a business-focused architect is an oxymoron.  If I found one, I suspect it would be someone trying to live in both worlds and not doing well in either.  There are, however, some exceptions to be found in this forum   ;)

The best practice for developing a management mind-set is to "walk the walk" not just "talk the talk", nor "read the book".  To become a Business Analyst, become a manager with profit making responsibilities.  Give up that security blanket of deep technical IT knowledge and commit to learning deeply what a manager desperately needs in order to be successful.  It only takes a few weeks, of being in fear of losing one's job because you can't get the past-due shipments out the door, to make the mind-set switch. ;D

Management skills are completely different from IT developer skills.  Read management books written by leading managers, not ones written by leading technical gurus.  Read
  • Porter on Strategy
  • Mintzberg on Organizational Structure
  • Eli Rat's The Goal
  • Books and Reviews from the Haavad Business School
  • Textbooks used in your local college's MBA degree program
  • just to name a few...
Ask your management for a three month transfer to a line management position as part of your training to become an business analyst;  they'll think that a smart thing to do if they support your career goals.  In its heyday, the Pennsylvania Rail Road required its software developers to be railroaders first and developers second, not the other way around.  If you are in a large corporation, check out their managent trainee program; see if you can get into it.

Well anyhow, that's how I did it.  I now yield my soap-box to other pontificators. ;)  


Can I work where you do?????

I wish we had BAs that had a clue.  But, every company I end up at usually only have a marketing department that can support trade shows and functions.  Another reality of business is many organizations are ad-hoc and you end up wearing many hats.  Technical people are left to analyze business requirements and line managers try and make technical decisions.  (Usually creating a mess in the process).  Your post is right on the money but does not reflect reality in small to mid sized companies.  (In my experience).    In those environments much of the use case analysis is left to the technical team.  Who, typically over-engineer and miss the true business requirements.  Us poor souls stuck in this mess can learn alot from a true BA as yourself.  Thanks for the insight and references!!

John
Title: Re: "CRUD"ing in Use Cases
Post by: mhdhallak on May 25, 2006, 03:30:46 pm
Quote

Can I work where you do?????

I wish we had BAs that had a clue.  But, every company I end up at usually only have a marketing department that can support trade shows and functions.  Another reality of business is many organizations are ad-hoc and you end up wearing many hats.  Technical people are left to analyze business requirements and line managers try and make technical decisions.  (Usually creating a mess in the process).  Your post is right on the money but does not reflect reality in small to mid sized companies.  (In my experience).    In those environments much of the use case analysis is left to the technical team.  Who, typically over-engineer and miss the true business requirements.  Us poor souls stuck in this mess can learn alot from a true BA as yourself.  Thanks for the insight and references!!

John


Good point, John. I was gonna say that but I refrained coz I was afraid I wasn't gonna speak for the public masses. Anyhow, I think ya'll will like it when I tell ya that this project i'm in, no else's on it. Yep baby, I'm doin everythin from business analysis down to development and deployment. Isn't that just a treat! I've been with this company for 3 months now, they're understaffed and they're supposedly working on this issue.

Anywho, I think they're pretty much aware (I made it clear) the enormous risks associated with this resource allocation technique, but they're willing to accept that for the sake of moving multiple projects in parallel.
Title: Re: "CRUD"ing in Use Cases
Post by: jeshaw2 on May 25, 2006, 05:37:26 pm
John & mhdhallak;

You both make good points.  I admit that most of my BA work has either been inside multi-billion dollar corporations or with $30 million dollar divisions of such corporations; both as an employee and as an external consultant.

However, in the situations you describe, I would suggest that such companies can ill afford to take the risks associated with doing the job incorrectly.  If you don't get it right the first time, in the long run you'll get bogged down fixing the installed applications at the expense of developing new capabilities.  At that point, you become a maintenance programmer who can't "seem to get it right" or "can't seem to make any progress" and stop being a multi-hatted guru.

Your management probably does not understand the value of CIM & PIM modeling and are pushing you for evidence of progress that they can understand--stuff running on the computer.  I would suggest the following tactics:
Hope this helps...
Title: Re: "CRUD"ing in Use Cases
Post by: TrtnJohn on May 31, 2006, 12:59:24 pm
Jim,

Thanks for all the input.  I hear exactly what you are saying and agree 100%.  But, in my current company’s case, there is no consistency in anything.  In reality the problems are even deeper than you realize.    Fixing these problems, just as in development, must also be implemented iteratively.   If I came to some of our management with your post and insisted on such things in all cases they'd run me out of here with torches and pitchforks.  It's going to require baby steps to climb out of our current ad-hoc process.  Ironically enough, all my complaining at my current company has netted me the privilege of being promoted into marketing as what they call a Product Manager.  I will take this opportunity to try and evangelize and enact some change.  (AKA The Big Flame Out).   I've only been in my new position for a month and it has gone surprisingly well.  Upper management is disturbed by many of the symptoms you described and I have been the only one to present any kind of case on why things are the way they are.  I completely realize that any one of the principles of the company could easily torpedo this whole effort.  But, IMO it is the right fight to fight.

PS.  I must be a bit demented as I do enjoy these types of challenges...
Title: Re: "CRUD"ing in Use Cases
Post by: jeshaw2 on May 31, 2006, 09:46:55 pm
I shall hold you in my prayers...for awhile  ;D
Title: Re: "CRUD"ing in Use Cases
Post by: TrtnJohn on June 01, 2006, 01:43:54 pm
Quote
I shall hold you in my prayers...for awhile  ;D


Thanks!

Maybe we ought to be placing bets on how long it will take me before I start begging for my development job back?