The original question on this thread was about the granularity of use cases.
People are throwing guidelines without much reason or evidence that I can see. Rational Corp., which is a powerful authority, is quoted as saying that one use case should take about a man-year from idea to tested code. We are told to avoid functional decomposition, but, as usual, we are not told why. In the absence of good reasons, the advice of authorities may be golden, but we should be in search of good reasons, too. So, here's my reasoning, for what it's worth. Stepping into design too early works against analysis. If you have a design in mind, it is very difficult to stop yourself from assimilating every new fact about the requirements into your design. The design becomes a requirement. Which is all dandy, if you had the right design in the first place. The problem is, it is very unlikely that you can produce a requirement-driven design by imposing a design as a driver. This may seem like an abstruse point to some, but it is one key to preventing your becoming deaf to what your clients want. There are exceptions. You may be doing the fifth in a series of truly very similar applications. That is a case in which you may efficiently start with a design and tweak it. Functional decomposition is design, and that is a good reason why you should avoid it in allocating use cases. Use case analysis is intended to produce a description of the behavior of the system, in other words, the action of the system. System action is initiated by an actor, who wants the system to do something, and it is completed when the actor's goal is met (or has to be abandoned). Use case analysis comes in two parts (one of which has been neglected in the UML standard, I believe). One part is decomposing the system into behaviors (which is not the same as functions), and the other part is describing the network of activities that comprise each behavior. The UML gives a good diagram standard for showing the system as a network of related behaviors. In use case diagrams, actors relate to use cases by association, and use cases relate to use cases in a number of ways, chiefly <<include>> and <<extend>> dependencies. The OMG UML Spec. gives sufficient definitions for immediate practical use. I am comfortable with the definition of an action as an atomic, indivisible piece of behavior. A use case would then be a network of actions, which will produce sequences of actions initiated by stimuli from actors and determined by the network and by current conditions. On the face of it, this description suggests that the activity diagram would be the natural representation of the use case. The activity diagram falls short, though, because there is no clear path from the semantics of ordinary language used by the client to the shape of the diagram. This factor makes perfectly logical activity diagrams inadequate. In my opinion, the UML should contain a standard for translating natural language to activity and back. One of my reasons for liking Visual Modeling with Rational Rose 2000 and UML, by Terry Quatrani, is the fact that Quatrani offers a standard format for documenting use cases in natural language. The Quatrani standard forces the developer to express behavior using a pattern of activity that is applicable to every behavioral requirement that I have seen so far. It is not certain that Quatrani's pattern is optimal, but you get tremendous leverage by standardizing on any use case description standard that is serviceable. Describing use cases by using a very small number of generic activity patterns makes a discipline out of the translation into diagrams of natural language about system behavior. A discipline can be studied, optimized, and tooled-up. If you know what sort of thing a use case contains, you are better prepared to divide a system up into use cases. Despite all my grumblings, it is pretty useful to say that a use case contains something that is well represented by an activity diagram. This diagram should capture activity that is meaningful to the user as a single task or a specific goal within the workday. At the bottom line, this leads me to favor use cases like "Create Purchase Order" and "Change Purchase Order," because both the granularity and the meaning are right. It is artificial to create a use case to "Do Purchasing" in order to limit the number of use cases in your system, but the "Create Purchase Order" granularity should not produce hundreds of use cases per typical system, anyway. Last point: Behavioral decomposition of a system will sometimes parallel an "obvious" functional decomposition. This parallelism does not "restore" functional decomposition as a driver of analysis. -Eric "Kesterton, Anthony" wrote: > > I think Haydn has some good points here - I am sure you will get many other > comments about this. > > regards > > anthony > > > -----Original Message----- > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > > Sent: 22 October 2001 13:44 > > To: Manish Didwania > > Cc: Kesterton, Anthony; [EMAIL PROTECTED]; ROSE_FORUM > > Subject: Re: (ROSE) Use Case-confusion > > > > > > > > The naming of the use cases are crucial to the system. In > > the first email > > from you, a use case "Purchase Order" is given as an example. > > However is > > this "purchase an order" or an actual "purchase order"? Rule > > of thumb I > > use is that use cases should be "verb-noun" phrases. > > > > In the example with "Maintain Purchase Orders", this is also > > badly named in > > my opinion. Words like "Manage", "Maintain" and other vague > > terminology > > should really be avoided. A better version would be: > > > > > > Purchase Administrator (Actor) ----> Create Purchase Order (use case) > > > > Two possible alternate paths that could be considered use > > cases in their > > own rights could be: > > Update Purchase Order (use case) -- <<extends>> --> Create > > Purchase Order > > Delete Purchase Order (use case) -- <<extends>> --> Create > > Purchage Order > > > > As for "Maintain GatePass" this (from your description) would > > be best as 2 > > use cases: > > > > "Send Goods" and "Receive Goods". Common sections to these > > use cases may > > exist, like getting customer details, which could be pulled > > out of both and > > placed in another use case which is included by both of these. > > > > The main problem is definitely with the naming of the use > > cases. We had a > > use case called "Manage <<something>>", and off this were > > many includes for > > all the possibilities including add, delete, update, etc. > > > > Functional decomposition should be avoided at all costs. There's a > > document in the www.rational.net site that talks about use cases and > > functional decomposition. You may want to see this because > > it certainly > > turned our project around and many use cases were stripped > > and renamed and > > the whole use case diagram suddenly made sense. > > > > Haydn > > > > > > > > > > > > > > "Manish Didwania" > > > > <mdidwania@amadeusi To: > > "Kesterton, Anthony" > > ndia.net> > > <[EMAIL PROTECTED]>, "ROSE_FORUM" > > Sent by: > > <[EMAIL PROTECTED]> > > owner-rose_forum@ra cc: > > > > tional.com Subject: > > Re: (ROSE) Use Case-confusion > > > > > > > > > > 22/10/2001 12:50 > > > > Please respond to > > > > "Manish Didwania" > > > > > > > > > > > > > > > > > > > > > > Hi, > > It is really helpful, but I still have few doubts as I am > > novice to system > > designing. I have am designing a module to my existing > > application First > > time I decided to do Design using Rational. > > I am adding a stock control/inventory module. What I have > > done so far is > > that I have designed 5 user cases and 2 Actor. > > > > Actor 1 (Purchase Admin) > > link to two user cases > > Maintain Purchase Orders > > Maintain Suppliers Data > > Actor 2 (Store Admin) > > link to three user cases > > Maintain Goods Master > > Maintain Gatepass (to basicly maintain documents for send > > and receive > > goods) > > Execute GatePass (which basicly updates the stock master) > > > > And I have put all details like process for > > updation,deletion, search etc > > in > > the documentation. I agree that one should not go in very > > deep in Use Case. > > But the approach I have used is correct???? > > > > Pls advise. > > > > Regards Manish > > > > ----- Original Message ----- > > From: "Kesterton, Anthony" <[EMAIL PROTECTED]> > > To: "Manish Didwania" <[EMAIL PROTECTED]>; "ROSE_FORUM" > > <[EMAIL PROTECTED]> > > Sent: Monday, October 22, 2001 4:03 PM > > Subject: RE: (ROSE) Use Case-confusion > > > > > > > > > > Hi > > > > > > Different texts disagree about the level you should write > > the use cases. > > > General practise here at Rational (guided by people like > > Ivar Jacobson, > > our > > > colleagues from the old Objectory company, and Rational's general > > > experience) is that you should keep to the one use case for Purchase > > Order, > > > and not break it down into multiple use case as your other example > > suggests. > > > This all depends on the system you are trying to build of course :-) > > > > > > In general, you should have a small number of use cases for > > an average > > level > > > of functionality system - say 10 use cases. The system > > with hundreds of > > use > > > cases is almost always the wrong level of detail. > > > > > > You want to capture a useful end-to-end process in a use case. > > > > > > You do not want use cases where they are one step in a > > daisy-chain of use > > > cases - all of which need to happen before something useful happens. > > This > > > "form" of use cases is better known as functional > > decomposition - and is > > not > > > the purpose of use cases at all. > > > > > > One simple rule-of-thumb (that not everyone agrees with - but really > > makes > > > you think about the level of your use cases) is that you > > might expect a > > use > > > case to take a person-year to complete from idea to tested > > code. At this > > > point - the 200 usecase project start to panic until they > > re-think their > > use > > > cases to the right level. > > > > > > Hope that helps a little. > > > > > > regards > > > > > > anthony > > > > > > > -----Original Message----- > > > > From: Manish Didwania [mailto:[EMAIL PROTECTED]] > > > > Sent: 22 October 2001 09:27 > > > > To: ROSE_FORUM > > > > Subject: (ROSE) Use Case-confusion > > > > > > > > > > > > > > > > I just want to know what is the common practice. In terms > > of putting > > > > Activity Diagram in Use Case. > > > > And at what level one should specify a Use Case. As I was > > > > reading a book on > > > > UML it was dividing a Purchase Order Use Case in 4-5 diff use > > > > case like > > > > Placing an Order, Cancellation of order and so on. And in > > rational few > > > > examples that I had checked they define Use Case for purchase > > > > Order as one > > > > Use Case and then specify the activity in documentation. > > > > > > > > Thanks Manish ************************************************************************ * Rose Forum is a public venue for ideas and discussions. * For technical support, visit http://www.rational.com/support * * Admin.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 * *************************************************************************
