Author
Topic: USE CASE Cookbook (Read 12912 times)

Since I'm swamped and have to focus on what we need to do, one of my employees had a great idea that I would love to do but can't. Perhaps it could be accomplished in conjunction with this forum.

We do not believe that there is an adequate "Use Case Cookbook"... one that had an index on something like (System - System, Time triggered / User - System / et cetera). Nothing more than a) the USE CASE document, USE CASES, and USE CASE diagrams for a TON of business problems.

Like I said, it's the type of book I would love to write but my authoring days are on hold at the moment.

Firstly, (after the university) I thought that use-cases are very important and there must be all from the project included. Nowadays, I think that use-cases aren't so important as teacher say. I partly agree with Robert C. Martin from the ObjectMentor Inc. who said in his Book "UML for Java Programmers" (2002) that use-cases represent only behavioral requirements. Thay are only a textual description and no diagram. He thinks, that use-cases are less important.See following link: http://www.objectmentor.com/resources/articleIndex (Use-Case section)

In my opinion, use cases are important to communicate with the customer on the top level of the system. Use-cases could help the customer to check what the programmer want's to do. But they are changing all the time and there is no system, which generates classes automatically from use-cases!

I agree to a point. I'm more keen to the complete UML model than just USE CASE Documents. However, more than just the "user" verifying what is being done, I've seen first hand how Use Case documents that are signed off by the "user" in turn used by the QA, Testing, and Support departments. They don't need the complete UML Model but they can use the documents as a base line for testing, assuring quality, and as a base-line for support on what to expect.

Steve

Quote

Hi Steve,

Firstly, (after the university) I thought that use-cases are very important and there must be all from the project included. Nowadays, I think that use-cases aren't so important as teacher say. I partly agree with Robert C. Martin from the ObjectMentor Inc. who said in his Book "UML for Java Programmers" (2002) that use-cases represent only behavioral requirements. Thay are only a textual description and no diagram. He thinks, that use-cases are less important.See following link: http://www.objectmentor.com/resources/articleIndex (Use-Case section)

In my opinion, use cases are important to communicate with the customer on the top level of the system. Use-cases could help the customer to check what the programmer want's to do. But they are changing all the time and there is no system, which generates classes automatically from use-cases!

I agree with Steve, and give me a chance to convince you why I've found use cases to be so useful, and why I consider the technique to be one the greatest contributions on systems analysis, design and construction.

1. Use cases try to depict a sequence a events (either "as is" or "projected system") that produces a useful product or service. So, first of all, you are identifying the "useful product or service" as your project's real objective. During the project, I have to keep repeating to myself: "Listen, burrito, it's the useful service or product that you're after, not the technology or the nice tools you're using".

2. They present the sequence events from the point of view of the user. This is of high value, because they directly point to the need of a good user interface, and good user-friendly design. "Listen... this is for the customer/user, not for the programmer...."

3. They bring the nice and clear side of object reuse to the fore, because they help break-up your system (current or projected) into meaningful sequences. Many of these sequences can be reused by other use cases via <<include>>, <<extend>> or generalization/inheritance relationships. (There are postings on this in the General EA forum: search for "extend".) You can save lots and lots of time by taking advantage of this.

4. They help in project planning, by assigning resources to the different use cases; for instance, "Developer 1, who's strong on user interface, should take care of the portal opening..; Developer 2, who's a real ace in RDBMS, should take care of the transactional use cases", and so forth...

5. The use case model is the best way I know of delineating project scope and helping you break-up a big project into stages.

6. Use cases are the way I've found to drive the next stage of your modeling, because they can be directly mapped to sequence diagrams; and these sequence diagrams are a sure-shot way of detecting the classes for your first-cut class model (which will evolve into both your user interface model and your static class or database model).

7. They are great aides for your technical architecture alternatives discussions. The first-cut answer to the question "Should I use a package or custom development?" can be answered by mapping the proposed package components to use case events.

8. Use cases can easily be derived into test scripts.

And there are many more reasons, but I hope these suffice for the moment.

ComputerWorld Mexico published in 1998 a somewhat long article I wrote on use cases, and I'll gladly submit a more updated version of it as a contribution to the cook-book (it is my intelectual property, so no problem with copyrights). It develops, step by step, a simple use case model. The only problem is that it is in Spanish, but I'll EMail it to anybody who volunteers to translate it.

Also, I would have no gripes if the article is torn apart and re-made (or whatever) into the core of the cook-book.

Finally, having praised use cases, let me now make a criticism: the user case model is not user-friendly, and you will not communicate your ideas to senior management with a use case model. To communicate with users and senior management, you should use a process model (see EA's document on process modeling).

Tim Camp

This may not be the appropriate time or place but I have to ask. Steve_Straley, are you an old Clipper guru, who used to do conferences? Were you at the one in California when there was a small tremor right after they announced the new version of Clipper?

I thought I recognized the name. If you are the gentleman I am thinking of, I really enjoyed your seminar that I went to.

Yes, I hate to admit it, but I am one in the same. Even more appropriate now is the adjective "old" <ROFL>. And yes I was at that conference with the earthquake in the middle of Larry H's keynote during the tremor when he said, "Well, was that as good for you as it was for me?"

I thank you for remembering and the kind words. May the holiday blessings be upon you and your family!

Steve

Quote

This may not be the appropriate time or place but I have to ask. Steve_Straley, are you an old Clipper guru, who used to do conferences? Were you at the one in California when there was a small tremor right after they announced the new version of Clipper?

I thought I recognized the name. If you are the gentleman I am thinking of, I really enjoyed your seminar that I went to.

Everyone,One of the things I struggle with at times is, "What do I do when?". I would like to know how other folks tie UML into their analysis process. Would someone mind listing the steps they use in their analysis and a brief description of each step? After the steps are defined then please show what UML elements you use for notation at each analysis step. I have my own set that I use but I would really like to compare notes with someone else.

If there is a good book that explains this I would also be interested in the name of the book.

As far as the Cookbook, how about starting with a General Ledger system? I think I have written about 4 of these. GL is simple and straightforward and might make a good starting point. I'll even volunteer to glean the information from the thread and make a complete document out of it and provide a link to it for everyone to download. We could use the GL system as a template for future postings.

The idea of the cook book I had was based on the system I'm doing at GE. There are over 300 UC documents with over 1120 UC steps. Now, the interesting thing about this is system-to-system, actor-to-system, web method and pub/sub integration, et cetera... The idea of the cook book was to have so MANY different types of systems, more than even a complete accounting system or ERP system, that you could find a similar scenario, see how it was mapped out, and emuluate. I've got 37 different types of packages in this endeavor, web methods, BPM stuff, and rules engine beans... squirly doesn't do it justice.