This week's book giveaway is in the Servlets forum.
We're giving away four copies of Murach's Java Servlets and JSP and have Joel Murach on-line!
See this thread for details.
The moose likes OO, Patterns, UML and Refactoring and the fly likes Detailing use cases Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Murach's Java Servlets and JSP this week in the Servlets forum!
JavaRanch » Java Forums » Engineering » OO, Patterns, UML and Refactoring
Bookmark "Detailing use cases" Watch "Detailing use cases" New topic
Author

Detailing use cases

Peter Braun
Ranch Hand

Joined: Feb 09, 2005
Posts: 57
I need some adivse. I'm going to write use case report or whatever it's called. (basic flow of events, altervtive flow of events, etc.)
For e.g. I want to make a system which handles 3 type of things. All of them have common functionalities but in details they are different. All 3 type of items can be created as new but each requires different input; existing ones selected from list and modified, or deleted.

How should I structure them? Should I create a common "create new" usecase? Because the flow of events is the same for all types but input is different.
Or I have to make a use case for every functionality of all types. It seems to be redundant work for me.

I know,- I read somewhere -, use cases are not object oriented, but there are include and extend relationships among them. So I have confused myself. Please help me.

Thanks,
Peter
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Redundancy in use case texts isn't as problematic as redundancy in code.

The problem is not in the intitial work - copy and paste would work - but in the maintenance. So what you should do depends on what you expect to happen to the use cases after you've written them.

Removing the duplication between them would have the advantage that should you ever need to change them all in the same way, you need to change only one place.

On the other hand, it also makes them harder to read and understand. How much of a problem this is depends strongly on the audience of the use cases - developers will probably be much more comfortable with abstracting commonalities to a common place than your customer and the users of the system will be. If you want to use use cases as a communication medium between developers and customer/users, having the latter feel comfortable reading them might well be worth handling some duplication. (You might still want to indicate that duplication somehow, such as a note along the lines of "this use case is similar to xxx", so that you remember to take a look at the others should you change one.)

Ideally, use cases aren't very detailed early in the project, just containing enough information for rough estimates for the planning. You can add the detail to a use case shortly before implementing it, when you can use the knowledge you gained from implementing earlier use cases to your advantage. If you do that, use cases don't need much maintenance anyway (other than being scrapped or new ones added), so duplication isn't an issue.

Did that help?


The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Peter Braun
Ranch Hand

Joined: Feb 09, 2005
Posts: 57
Thanks for your help.
I thought I have to detail use cases before I analyse them and make sequence diagrams and then I create the architecure. Am I wrong?

Peter
Kishore Dandu
Ranch Hand

Joined: Jul 10, 2001
Posts: 1934
Use cases have good precedense and occupy a lot of significance during inception and Elaboration. Architecture is kind of low key in inception but almost equal or more(in some cases) precedense during elaboration. Architecture some times occupies reasonanble precedense during construction, if it is not well chalked out during initial phases.

If you are tweaking use cases a lot during construction that means there is something wrong with the projects execution style.


Kishore
SCJP, blog
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Peter Braun:
I thought I have to detail use cases before I analyse them and make sequence diagrams and then I create the architecure. Am I wrong?


Going from use cases to sequence diagrams is one common way to do it, though not my preferred way. Not sure what exactly you mean by "analyzing the use cases".

The term architecture isn't well defined enough to comment without knowing more.

Anyway, even if you do that, it doesn't mean that you need to (or even should) detail *all* the use cases before going to sequence diagrams and architecture. That sounds quite waterfallish to me. A more iterative/incremental approach will quite likely work better, unless we are talking about a very small project here, and you know very well what you are doing.
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Kishore Dandu:
Architecture some times occupies reasonanble precedense during construction, if it is not well chalked out during initial phases.


So tell us, what do *you* mean by the term "architecture"?

If you are tweaking use cases a lot during construction that means there is something wrong with the projects execution style.


Quite to the contrary, it might mean that there is something quite good about the projects execution style. It simply might mean that you expose a working system to the users early in the project and feed back their learnings (about what they really need) into the development; or that you are taking advantage of new business opportunities that weren't foreseeable when you started the project. It might mean that at the end of the project you deliver to the customer what he actually needs, not what you thought he might need when the project started.
Kishore Dandu
Ranch Hand

Joined: Jul 10, 2001
Posts: 1934
Originally posted by Ilja Preuss:


Quite to the contrary, it might mean that there is something quite good about the projects execution style. It simply might mean that you expose a working system to the users early in the project and feed back their learnings (about what they really need) into the development; or that you are taking advantage of new business opportunities that weren't foreseeable when you started the project. It might mean that at the end of the project you deliver to the customer what he actually needs, not what you thought he might need when the project started.


Level of use case, extent of its applicability, its creator responsibility etc define the content of use case. I am commenting from my experience's perspective.

If you have different perspective about a use case's applicability in a specific cycle, I respect that( you are probably more of a agile adopter, which I am not at this point). But, I would like to stick to my guns on this comment about the use cases though.
Hu Chong
Greenhorn

Joined: Jun 30, 2003
Posts: 17
Use cases have been misused alot from my project experiences. In a particular project, use cases have to be accurate and document all possible screen flows (i.e. alternative flows). All error messages have to be identified too. As if that is not bad enough, the use cases have to comply to a certain glossary, and you could not use words that is not found inside.

My feel is that you should document enough for you to start some preliminary design and update them in iterations.
[ March 27, 2005: Message edited by: Hu Chong ]
Ryan McGuire
Ranch Hand

Joined: Feb 18, 2005
Posts: 1006
    
    3
Originally posted by Peter Braun:
For e.g. I want to make a system which handles 3 type of things. All of them have common functionalities but in details they are different. All 3 type of items can be created as new but each requires different input; existing ones selected from list and modified, or deleted.

How should I structure them? Should I create a common "create new" usecase? Because the flow of events is the same for all types but input is different.
Or I have to make a use case for every functionality of all types. It seems to be redundant work for me.



It depends on how it looks from the user's point of view. For example, if there is a consistent user interface for all three high-level things that the users will be considering and the method for {creating, delting, modifying, etc.}, then I would say that you should use a "uses" or "includes" relationship on your Use Case diagram. On the other hand, if it doesn't feel like a "uses" relationship to the user then I wouldn't try showing it like that on the Use Case diagram.

If you decide in your subsequent design phases that you should use common methods to create/delete/etc. all three kinds of thing then that should be reflected in the diagrams from those phases. The redundancy from the use case phase will be cleaned up in subsequent phases.

The general rule that I use is that any diagram should be the results of work done up to that point without looking ahead.

[Disclaimer: That's the practice I've followed and it has worked well enough that I feel comforatable suggesting it to others. However it's not something that I recall reading explicitly in a text and can cite the title and page number for. YMMV.]

Ryan
[ March 28, 2005: Message edited by: Ryan McGuire ]
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Detailing use cases
 
Similar Threads
form action
Workflow modelling
Do we need to provide sequence diagram for View Frequent Flyer Miles Use Case?
Requirements for mobile apps.
Question regarding FBN Use Case