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 ]