(responding to Eric D. Tarkington)
> 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. The question of decomposition of Use Cases arose as a side issue in an OTUG discussion a few months ago; chief protagonists, myself and H.S.Lahman. > 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. Agreed. In as much as we had any conclusions, the important thing is that the right decisions should be made by the right people at the right time. (Personally, I espouse making decisions as late as possible, because then one will have to hand the maximum possible information). In short, any decomposition of the Use Case may be taken as a hint to the analysts and designers that follow, but should not be taken as a decision. It was noted that where the Use Case was decomposed in order that part of it may be used in multiple places, then the writer of Use Cases is correct in bringing this to the attention of subsequent analysts and designers. However, assignment of responsibilities to abstractions is the responsibility of the Domain Modeller, and subdivision of responsibilities into operations is the responsibility of the Designer. If decomposition of Use Cases were to be treated as requirements, i.e. decisions that must stand, this may obstruct the proper subsequent analysis and design work. > 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. In this case, the 'hints' are likely to be taken. > 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). Your conclusion concurs with mine. > 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. I would suggest that it is the Domain Modeller who has responsibility for assigning 'behaviours' to abstractions. Somebody needs to map the behaviour required by the Use Case onto the behaviours provided by those abstractions with whom the relevant responsibility lies. I'm not sure how your 'two parts' map onto my view. I suspect my 'somebody' is taking care of your 'second part'. > 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. Again there's the problem of distinguishing between the things that must be as shown in the activity diagram, and those that are potentially design decisions. It is hard to show necessary sequence and necessary atomicity without implying sequence and atomicity in places where it is not necessary. It is not clear to me that anyone breaking the Use Case out into an activity diagram will do this in a way that suits the optimum assignments of responsibilities to abstractions. I believe using an activity diagram runs the risk of tying a particular process into a Use Case, and thus should be used with care. > 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. Paul Oldfield any opinions expressed herein are not necessarily those of Mentors of Cally. ************************************************************************ * 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 * *************************************************************************
