hugh@slee01.srl.ford.com (Hugh Fader) (06/20/91)
It seems as though every reference I read encourages a bottom-up (or maybe more appropriately middle-down, middle-up) type of design approach for object oriented programming -- i.e. do your program design by developing objects, then use the objects to develop the system. This approach may be OK for small one or two programmer projects but seems inadequate for larger ones. Are Yourdon/DeMarco/Page-Jones structured analysis and design techniques now obsolete? If not, how have people modified them to work with OOP? If these techniques are obsolete, what are people using in their place? I am also interested in references anyone may have for analysis and design of object oriented systems. -- Hugh Fader hugh@slee01.srl.ford.com
victor@concour.cs.concordia.ca (KRAWCZUK victor) (06/21/91)
In article <44056@fmsrl7.UUCP> hugh@slee01.srl.ford.com (Hugh Fader) writes: >It seems as though every reference I read encourages a bottom-up (or >maybe more appropriately middle-down, middle-up) type of design >approach for object oriented programming -- i.e. do your program >design by developing objects, then use the objects to develop the >system. > >This approach may be OK for small one or two programmer projects but >seems inadequate for larger ones. I totally agree with the above two paragraphs. I've read numerous "OO Design" books (eg. Object Oriented Design by Booch, Designing Object-Oriented Software by Wirfs-Brock et al, OO Analysis by Yourdon, Intro to OO Programming by Budd, etc...) and what I've found clearly lacking in all books is a tested and proven (to a reasonable extent :-) ) OO/SE methodology for large OO projects involving more than 3 people (possibly dozens), including design, analysis, programming, the complete shbang! It seems the main problem is in the design phase, due to the fact that design starts in the "middle" and goes middle-up and middle-down. If the project is "small", the obvious solution is to have one or at most two people tackle this area (design), in order to cut down on "communication" overhead, and then assign the implementation of various classes to various programmers. But if the project is of any significant size, the design phase can become too much of a task for one or two people. Adding more people without a war plan (like top-down design teams for non-OO programming) to the design team is obviously fruitless. Has anyone had any experience good in this realm? Or, can anyone recommend a good book or article on how the design phase of an OO project can be managed when the design must be done in a hurry, and the task is too involved for 1 or 2 people who can tap each other on the shoulder, since the boss expects quality work but can't wait until the 21st century? The solution doesn't seem to be as obvious as the traditional non-OO case. -- ----------------------------------------------------------------------- | Victor Krawczuk (e-mail : victor@concour.cs.concordia.ca ) | | Concordia University, Dept. of Computer Science (H-961) | | 1455 De Maisonneuve Blvd. W., Montreal, Quebec, Canada, H3G 1M8 |
dch@aeg.dsto.oz.au (Dave Hanslip) (06/22/91)
victor@concour.cs.concordia.ca (KRAWCZUK victor) writes: >But if the project is of any significant size, the design phase can >become too much of a task for one or two people. Adding more people >without a war plan (like top-down design teams for non-OO programming) >to the design team is obviously fruitless. Has anyone had any >experience good in this realm? Or, can anyone recommend a good book >or article on how the design phase of an OO project can be managed >when the design must be done in a hurry, and the task is too involved >for 1 or 2 people who can tap each other on the shoulder, since the >boss expects quality work but can't wait until the 21st century? We have been wrestling with this problem for some time. As with any large problem, one must decompose the problem into smaller ones, analysable, designable and implementable by small teams. There is no guidance anywhere as far as I know on how to do this best from an OO point of view. As Booch notes, non-problem space matters impinge on this too, such as implementation by different contractors and one's schedule. In our case we have a small team and long schedule. This means incremental development and this too impacts how one structures the design. I have just been reading a paper by Shlaer and Mellor, "Recursive Design and its Effect on the Project Life Cycle" in which they propose breaking the problem into loosely coupled "domains" that enclose "specific and separate subject matter". "Domain" may or may not equate to "subsystem". I need to cogitate more on this. Right now "domains" as identified in the paper don't spring to mind for our project. We have actually ended up with a subsystem breakdown that is based primarily on encapsulation and information hiding. We are now firmly committed to the principles expounded by Booch and are using his notation. A CASE tool would definitely be useful here! I am structuring the system using an approach that I have not seen elsewhere in that I am using the static objects to structure both the design and the documentation. This is difficult to explain in a text only forum. For example though, we have an object called theUserInterface. It consists of objects such as theDisplaySubsystem, theAlertSubsystem, theCueSubsystem, theKeyboard etc. theUserInterface has a member function displayCue. It passes on the message to theCueSubsystem. It assembles characters from theKeyboard into aCueResponse. theUserInterface also has a member function sendCueResponse. theCueSubsystem sends a message to theUserInterface: theUserInterface -> sendCueResponse(&CueResponse); theUserInterface then notifies the appropriate object of the cue response. This is simplified but essentially it allows theCueSubsystem to be designed and implemented independently. The structure we end up with looks like this: A----------------------------------------R / \ / \ / \ / \ B C S T / \ / \ / \ / \ / | | \ / | | \ D E F G U V W X This is an object diagram, with A an aggregate of the classes below it, and R an aggregate of the classes below it. All classes are "static" in that they exist for the life of the application. Messaging between classes below A and below B could be handled by making them visible to each other but we have elected to route messages up and down through the hierachies. The hierarchies of static objects we end up with are a bit like a functional decomposition structure but they are objects not functions. The static objects manage, operate on or dispatch around the system, the dynamic objects such as, in our case, cues, alerts and radar contacts. Since the A and R objects above are loosely coupled and equate with subsystems, the amount of communication between them should not be great. We now have a decomposition which allows design and implementation by a team followed by an integration phase. This also provides us with a natural way of assembling the system. Hope this helps. David C. Hanslip E-mail: dch@aeg.dsto.oz.au Aeronautical Research Laboratory Phone: +61 8 259 5792 DSTO Salisbury, South Australia Fax: +61 8 259 5507
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!"