File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
Win a copy of Soft Skills: The software developer's life manual this week in the Jobs Discussion forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

UML - Use Case

 
Pappu Kumar
Ranch Hand
Posts: 69
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Please explain how the following tasks would appear in a USE CASE.
Tasks :
1.)Add/Modify/Delete Client
2.)Assign category to client
3.) Assign Client Address
4.) Assign contact person info...
the client entity in the DB stores all these details. Does it make sense to have only three use cases (add,modify,delete) and then break down modify into (Assign category to client,Assign Client Address,Assign contact person info)..or
just have all these above mentioned in one diagram.
Please suggest a good use case diagram for this.
 
Stan James
(instanceof Sidekick)
Ranch Hand
Posts: 8791
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I might make a case for a single use case - Administer Client Profiles - with a number of flows. Others might argue for a separate use case for each flow. If you get all the requirements, there is hardly a right or wrong answer.
One thing about a flow, whether the use case has one or many, is to accomplish a useful business objective. Start with a goal, go through the steps to make something happen, get to a good end state.
Add, modify and delete might be good flows. The modify one could get the user to the edit page, allow the user to change any field, and save the changes. It would be no fun to have a bunch of flows with five identical steps to get to the edit page, one step different for the field you change, and four more identical steps to save.
Focus on capturing all requirements and making the thing readable and usable by your friends. Don't focus on the strict rules of some UML book or other. You don't get points for long, formal sentences unless you are trying to impress a professor.
Oh, and don't mention the database until you get to design.
[ May 21, 2003: Message edited by: Stan James ]
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Rahul Kumar:
Please explain how the following tasks would appear in a USE CASE.
Tasks :
1.)Add/Modify/Delete Client
2.)Assign category to client
3.) Assign Client Address
4.) Assign contact person info...
the client entity in the DB stores all these details. Does it make sense to have only three use cases (add,modify,delete) and then break down modify into (Assign category to client,Assign Client Address,Assign contact person info)

It depends on your actual needs. What are doing the use cases for?
For example, at the start of a project, you would probably want to use them to get a first rough estimate for the whole project. For that, you need a well balanced granularity - to big use cases, and your estimates will be rather dim; to many use cases and you will dissipate your energies.
A different focus might be prioritization - when you want to find out which features are important to the customer and therefore architecturally critical. If a use case contains both important and unimportant parts, it makes sense to split it in this phase to give them different priorities.

Please suggest a good use case diagram for this.

The use case *diagram* is secondary; use cases are textual - and even less important than the actual conversation with the customer and early acceptance testing.
[ May 24, 2003: Message edited by: Ilja Preuss ]
 
Pappu Kumar
Ranch Hand
Posts: 69
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
This is in continuation of the posts i had made earlier.
I use Rational Rose for Java for my modelling.
I have a requirement where the user does many operations on a entity(ex. Client). In my use case diagram i was able to bundle all these operations under add/modify/delete client. But the clients wants to see all operations under those three use cases. I added another use case diagram under those three use cases as (add details/modify details/delete detaiils). Is that a good technique ? If try to display all use cases in the Main use case diagram....it gets too too congested and hard to read.
My questions are :
1.) Was my approach right ?
2.) Should i use Sequence Diagrams ? instead of having a detail Use Case Diagram inside every Use Case , i would have a Sequence Diagram for each (add/modify/delete use case) ?
3.) Any suggestions as to whats the right way to implement this ? and also letting the client see all their operations
 
It is sorta covered in the JavaRanch Style Guide.
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic