I started drawing the UCD to visualize, but a couple of things occurred to me before I could finish.
Firstly, "Assign A Care Coordinator" does not sound like a business goal to me. It sounds like a method. Depending on complexity, it might be one activity within an activity or state diagram, or it might be something that you would capture in class operations. Any use case that is promiscuously <<include>>ed or <<extend>>ing with other use cases is suspect in the same way, I guess. Painful as it may be, you have to ask yourself, "Is this use case, my brainchild, engaging in dependencies where no use case should? Is it, in fact, a deviant use case, with improper goals?" You have to be strong. Getting serious for a second, this begins to look like functional decomposition to me. If I'm right, do Department of Health guys respond by saying "Doh!"? (I beg you to forgive me for this pun, on grounds that I have not seen it 5000 times before, as you must have.) Secondly, I'm assuming that you are making a use case model of the system, and not a business model. The business model is done less often, and less well understood than the system model (which is what the UML was made for), but it is clear that these two models will differ. The presence of an activity in the business model does not guarantee (IMO) the presence of a corresponding activity in the system model. This point is academic if the first point solves your problem. -Eric > [EMAIL PROTECTED] wrote: > > Yup... here it is at a "high level" > Initiate Care use case (UC A ) does a number of things in the basic > flow, including Assigning a Care Coordinator (UC C). I could stretch > it to say that this is optional, conditional behaviour and extend it > here as well, but it really isn't. This has a real-world equivalent in > the business. (I get the opportunity to work with approximately 10 > users full time, then another 20 to validate!) > > Update Care Plan's (UC B) basic flow adds tasks to a care plan, and > under certain circumstances, this task is to Assign a Care > Coordinator. Its not part of the basic flow, just an extension point. > Again, real-work equivalent in the business! > > I had a suggestion from a co-worker to make it an alternate flow, and > "include" the use case in this fashion. Still doesn't seem quite > right. I've tried rethinking this in other ways, but this fits the > best, and can't see how its functional decomposition. All have clear > cut goals. > > I agree, strange. Hence my question. Gotta hate circumstances like > this - like the easy ones much better!!!! > > -----Original Message----- > From: Eric D. Tarkington [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, October 15, 2002 7:27 PM > To: [EMAIL PROTECTED] > Subject: Re: (RUP) a use case that is both an includes and an extends > to > other use cases? > > Obviously, the UML notation supports the relationships that you > suggest, > but one begins to wonder whether these are real use cases (which > deliver > something valuable, in themselves, to the business). Functional > decomposition creeps in too easily. > > Do you have some real-world use cases that relate as you describe? > > -Eric > > [EMAIL PROTECTED] wrote: > > > > Has anyone ever come across the following scenario? > > > > Use Case A includes Use Case C (definitely part of basic flow). > > Use Case B is extended by Use Case C. > > > > Is this valid "use case-ness"? Should use case C instead be included > > > in Use Case B?? > > > > Deniz Franck (850) 245-4444 x3262 > > Mission: To promote and protect the health and safety of all people > > > in Florida > > through the delivery of quality public health services and promotion > > > of health care standards. > > Please note: Florida has a very broad public records law. Most > > written communications to or from state officials regarding state > > business are public records available to the public and media upon > > request. Your e-mail communications may therefore be subject to > > public disclosure. ************************************************************************ * Rose Forum is a public venue for ideas and discussions. * For technical support, visit http://www.rational.com/support * * Post or Reply to: [EMAIL PROTECTED] * Subscription Requests: [EMAIL PROTECTED] * Archive of messages: * http://www.rational.com/support/usergroups/rose/rose_forum.jsp * Other Requests: [EMAIL PROTECTED] * * To unsubscribe from the list, please send email * To: [EMAIL PROTECTED] * Subject: <BLANK> * Body: unsubscribe rose_forum *************************************************************************
