Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!zaphod.mps.ohio-state.edu!rpi!uupsi!bse.com!eberard From: eberard@bse.com (Edward V. Berard) Newsgroups: comp.object Subject: Re: OOA vs OOD (was: Booch GOOD - Coad/Yourdon BAD) Summary: comments based on experience -- not religion Keywords: experience Message-ID: <0B010001.y9zgpu@bse.com> Date: 22 Nov 90 16:22:55 GMT Reply-To: eberard@bse.com Organization: Berard Software Engineering, Inc. Lines: 51 X-Mailer: uAccess - Mac Release: 1.0.1c In article <651@janus.Quotron.com>, cws@janus.Quotron.com (Craig W. Shaver) writes: > > Edward V. Berard writes: > ... other stuff .... > > Functional decomposition approaches localize information around functions, > > whereas object-oriented approaches localize information around objects. Using > > a functional decomposition approach first breaks apart high level objects > > and scatters information on these objects into different functional components. > > > > It is far better to use an object-oriented decomposition technique to partition > > your system into manageable pieces to which you can then apply other > > object-oriented techniques. > > Craig W. Shaver writes: > This is a blanket statement and sounds a little religious to me. My remarks are based on hard-won experience with large object-oriented software projects. Six or seven years ago, I would have not made these same recommendations. I, and others, have found out the hard way that a functional decomposition approach first, and an object-oriented approach later, on the same project is a recipe for trouble. > I believe the best approach is to take a top down cut as the first design step. > But, keep the analysis/design at a high (very abstract) level. I find this remark very curious. I can only guess that Craig assumes a top-down approach cannot be conducted in an object-oriented manner. (I do not mean to put words in Craig's mouth, so correct me if I am wrong.) For large projects, I usually recommend a chiefly top-down approach. The approach, of course, makes use of object-oriented decomposition. > Then isolate objects and decide what software components you have that may > work, plus what you will have to build. This part of the analysis/design > being more bottom up and detailed. If the information was first partitioned along functional lines, and if each partition was then submitted to an object-oriented approach, there will be problems. Unfortunately, these problems usually do not show up until integration time. -- Ed ---------------------------------------------------------------------------- Edward V. Berard | Phone: (301) 353-9652 Berard Software Engineering, Inc. | FAX: (301) 353-9272 18620 Mateney Road | E-Mail: eberard@bse.com Germantown, Maryland 20874 | ----------------------------------------------------------------------------