• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

UML - Use Case

 
Ranch Hand
Posts: 69
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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.
 
(instanceof Sidekick)
Posts: 8791
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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 ]
 
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
 
reply
    Bookmark Topic Watch Topic
  • New Topic