Use Cases
in [OOP]
|
Prev: Double Dispatch Problem: Mobile Creatures and Projectiles ina Game World
Next: Metaphor-oriented programming
From: bui on 30 Mar 2007 13:19 Everything I've read tells me that "Log On" isn't a good use case either because it doesn't yield value or because nobody would only want to "Log On". This seems reasonable. So the "Log On" bit has to appear inside other use cases. Does this mean its description has to be repeated over and over? If it is a "chunk of function" that can be reused, what is this called? It can't be a use case because that has to yield value. Or you might have a state of "Logged On". How do you get to this state if you aren't allowed a "Log On" use case? How do you stop the business analysts rolling their eyes and laughing hysterically when you mention "state"?
From: H. S. Lahman on 30 Mar 2007 17:32 Responding to Bui... > Everything I've read tells me that "Log On" isn't a good use case > either because it doesn't yield value or because nobody would only > want to "Log On". This seems reasonable. I've worked with systems where pushing the ON button had 100 KLOC of code behind it. It all depends on what functionality is associated with "Log On". If "Log On" involves a dozen distinct, logically related activities then those activities deserve to have their own use case. The point of use cases is to organize requirements in a manner that facilitates correct implementation of the requirements. So, in the end, whatever does that is the right thing to do. FWIW, I would expect "Log On" to be a use case almost always. It is hard to think of such a process that would not involve a special UI element (e.g., a GUI login dialog for user ID and password), saving some state information (i.e., the user's identifier), AND causing a particular display to be presented in the UI once the login is completed. In addition, if there is a need for a login procedure at all, there will very likely also be a need for some sort of user verification (e.g., password authentication) and privilege allocation or infrastructure initialization. However, ... > So the "Log On" bit has to appear inside other use cases. Does this > mean its description has to be repeated over and over? If it is a > "chunk of function" that can be reused, what is this called? It can't > be a use case because that has to yield value. The "Log On" use case probably isn't a primary standalone use case. I would expect it to be included in other use cases that perform more general activities. IOW, executing the "Log On" activities is an annoying prerequisite for what the user really wants to do with the software. ************* There is nothing wrong with me that could not be cured by a capful of Drano. H. S. Lahman hsl(a)pathfindermda.com Pathfinder Solutions http://www.pathfindermda.com blog: http://pathfinderpeople.blogs.com/hslahman "Model-Based Translation: The Next Step in Agile Development". Email info(a)pathfindermda.com for your copy. Pathfinder is hiring: http://www.pathfindermda.com/about_us/careers_pos3.php. (888)OOA-PATH
From: bui on 31 Mar 2007 07:45 On 30 Mar, 22:32, "H. S. Lahman" <h.lah...(a)verizon.net> wrote: > Responding to Bui... > > > Everything I've read tells me that "Log On" isn't a good use case > > either because it doesn't yield value or because nobody would only > > want to "Log On". This seems reasonable. > > I've worked with systems where pushing the ON button had 100 KLOC of > code behind it. It all depends on what functionality is associated with > "Log On". If "Log On" involves a dozen distinct, logically related > activities then those activities deserve to have their own use case. > > The point of use cases is to organize requirements in a manner that > facilitates correct implementation of the requirements. So, in the end, > whatever does that is the right thing to do. > > FWIW, I would expect "Log On" to be a use case almost always. It is hard > to think of such a process that would not involve a special UI element > (e.g., a GUI login dialog for user ID and password), saving some state > information (i.e., the user's identifier), AND causing a particular > display to be presented in the UI once the login is completed. In > addition, if there is a need for a login procedure at all, there will > very likely also be a need for some sort of user verification (e.g., > password authentication) and privilege allocation or infrastructure > initialization. However, ... > > > So the "Log On" bit has to appear inside other use cases. Does this > > mean its description has to be repeated over and over? If it is a > > "chunk of function" that can be reused, what is this called? It can't > > be a use case because that has to yield value. > > The "Log On" use case probably isn't a primary standalone use case. I > would expect it to be included in other use cases that perform more > general activities. IOW, executing the "Log On" activities is an > annoying prerequisite for what the user really wants to do with the > software. > > ************* > There is nothing wrong with me that could > not be cured by a capful of Drano. > > H. S. Lahman > h...(a)pathfindermda.com > Pathfinder Solutionshttp://www.pathfindermda.com > blog:http://pathfinderpeople.blogs.com/hslahman > "Model-Based Translation: The Next Step in Agile Development". Email > i...(a)pathfindermda.com for your copy. > Pathfinder is hiring:http://www.pathfindermda.com/about_us/careers_pos3.php. > (888)OOA-PATH I agree with everything you said. So why do the books I've read (Fowler, Spence & Bittner, Muller, Alhir, Eriksson & Penker) all trash the idea?
From: H. S. Lahman on 31 Mar 2007 11:18
Responding to Bui... > I agree with everything you said. So why do the books I've read > (Fowler, Spence & Bittner, Muller, Alhir, Eriksson & Penker) all trash > the idea? I can't say because I don't have a context; I haven't read those books. B-( My epiphany to uses cases was through Jacobson and Cockburn. ************* There is nothing wrong with me that could not be cured by a capful of Drano. H. S. Lahman hsl(a)pathfindermda.com Pathfinder Solutions http://www.pathfindermda.com blog: http://pathfinderpeople.blogs.com/hslahman "Model-Based Translation: The Next Step in Agile Development". Email info(a)pathfindermda.com for your copy. Pathfinder is hiring: http://www.pathfindermda.com/about_us/careers_pos3.php. (888)OOA-PATH |