davidm@uunet.UU.NET (David S. Masterson) (06/24/91)
Note the Followup-to line as there has been some good talk on OO design methods in comp.object. >>>>> On 21 Jun 91 19:51:13 GMT, dch@aeg.dsto.oz.au (Dave Hanslip) said: Dave> victor@concour.cs.concordia.ca (KRAWCZUK victor) writes: Victor> But if the project is of any significant size, the design phase can Victor> become too much of a task for one or two people. Adding more people Victor> without a war plan (like top-down design teams for non-OO programming) Victor> to the design team is obviously fruitless. Has anyone had any Victor> experience good in this realm? At one time, Ed Berard (who started comp.object) had posted many good articles on many aspects of OOA, OOD, OOP, etc. Last I heard, they had been put up in a mail server (uunet!seer!mserv - I believe). You might try sending a "help" message to that address and see if the mail server is still active. Dave> We have been wrestling with this problem for some time. As with any Dave> large problem, one must decompose the problem into smaller ones, Dave> analysable, designable and implementable by small teams. There is no Dave> guidance anywhere as far as I know on how to do this best from an OO Dave> point of view. As Booch notes, non-problem space matters impinge on this Dave> too, such as implementation by different contractors and one's schedule. Dave> In our case we have a small team and long schedule. This means Dave> incremental development and this too impacts how one structures the Dave> design. As I've found in my project, OOP is often a middle out process because objects can "encapsulate" more meaning than is usually expressed in functional decomposition. What is often missed by people new to OOP (and I've seen some old timers miss it as well) is that decomposition along functional lines can often break things up that would naturally go together in an object oriented world. Dave> I have just been reading a paper by Shlaer and Mellor, "Recursive Design Dave> and its Effect on the Project Life Cycle" in which they propose breaking Dave> the problem into loosely coupled "domains" that enclose "specific and Dave> separate subject matter". "Domain" may or may not equate to "subsystem". Dave> I need to cogitate more on this. Right now "domains" as identified in Dave> the paper don't spring to mind for our project. Where "domains" may come in more is in doing what is known as Object Oriented Domain Analysis. Domain analysis seeks to unify all the different domains within a project in order to make objects as useful in as many domains as is logically possible. In a large object oriented project, someone should be assigned to this duty (but it does take talent). Finding a good breakdown for an object-oriented project is difficult and still seems to be an art form. Most people I've talked to (and analysis of our project) seems to suggest that this breakdown will go through at least 3 radical shifts throughout the life of the project. The key to a good project seems to be to plan for these shifts rather than trying to prevent them by getting it right the first time. This is part of the iterative process of object oriented development. -- ==================================================================== David Masterson Consilium, Inc. (415) 691-6311 640 Clyde Ct. uunet!cimshop!davidm Mtn. View, CA 94043 ==================================================================== "If someone thinks they know what I said, then I didn't say it!"