|
Prev: Critique of Robert C. Martin's "Agile Principles, Patterns, andPractices"
Next: Booch's book feels too philosophical rather than practical?
From: mwarden on 2 Jan 2007 13:44 I searched the archives and I found some information similar to what I'm looking for, but not exactly. I have an abstract use case "Import Data" and a number of use cases extending this use case, e.g. "Import A Data", "Import B Data", "Import C Data", etc. Dome of these extension cases have amended scenarios, and others have exactly the same scenario as the "Import Data" use case. Is there a common notation for the scenario section of the use case document that essentially says "look at the scenarios for use case X"? Or is there another way to model this that would achieve the same? Is the fact that I'm asking this question indication that I have misused the extends relationship? Thanks for your help.
From: H. S. Lahman on 3 Jan 2007 13:39
Responding to Mwarden... > I searched the archives and I found some information similar to what > I'm looking for, but not exactly. > > I have an abstract use case "Import Data" and a number of use cases > extending this use case, e.g. "Import A Data", "Import B Data", "Import > C Data", etc. Dome of these extension cases have amended scenarios, and > others have exactly the same scenario as the "Import Data" use case. > > Is there a common notation for the scenario section of the use case > document that essentially says "look at the scenarios for use case X"? > Or is there another way to model this that would achieve the same? Is > the fact that I'm asking this question indication that I have misused > the extends relationship? Yes, it is common. You can also use <<includes>> and <<extends>> in addition to or as alternatives to scenarios. You can even use generalization. Cockburn's "Writing Effective Use Cases" describes various alternatives in a quick read. However, use cases are a specification of requirements. The primary goal is to communicate the requirements to the developers in a manner that minimizes implementation errors due to misinterpretation, omission, etc.. So one should use the form or conventions that best convey the requirements to the developers. IOW, use whatever form is likely to be the clearest to the developers for the given problem. ************* 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 |