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.
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 ]
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
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 ]
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
Joined: Oct 01, 2002
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