dumphres@blackbird.afit.af.mil (David A. Umphress) (08/14/90)
Can someone offer advice? I seem to be having some conceptual difficulties an aspect of object-oriented analysis (OOA): How does OOA differ significantly from OOD? After having read Coad's book, Shlear & Mellor's book, etc. and having attended an EVB course, I'm still unsure of OOA as a "requirements analysis" technique. In performing an OOA, we concentrate on identifying objects and, in the case of Coad and EVB, operations on objects. It seems to me that in doing so we are really designing a solution to a problem rather than looking at the "requirements." For instance, suppose I was asked to implement a system for transporting people from point A to point B in xx minutes. If I started out with an OOA, I'd identify, say, a plane object then describe its attributes, constituent parts, and how it interacts with other objects in the system (I'm oversimplifying, but you get the idea). In doing so, though, I've designed a solution. The other alternative is to describe a "transportation" object. But this feels like a functional (vice OO) approach. In short, it appears OOA is more of a preliminary design approach than a requirements analysis technique. Help! David Umphress Air Force Institute of Technology e-mail: umphress@ajpo.sei.cmu.edu
ikluft@uts.amdahl.com (Ian Kluft) (11/06/90)
[Please post followups to comp.object.] Books discussed in this posting: Object Oriented Design with Applications by Grady Booch Object Oriented Analysis by Peter Coad and Edward Yourdon (also Object Oriented Analysis and Information Modeling by Shlaer and Mellor) In article <3634@vela.acs.oakland.edu> rdthomps@vela.acs.oakland.edu writes: > If you are looking for a brainstorming session on how to > draw sketches of objects and the relationships between > them -- get Coad/Yourdons book (Haahmmm). > > However, if you are looking for a very well written book > on Concepts, Methods, and Applications of the object > oriented model -- GET BOOCHS book. The comparison here is between apples and oranges. There are two major reasons why the books are different. One of them also explains why Booch's book appears to be better in several ways. First, they are different mostly because Coad/Yourdon's book is about object- oriented *analysis*. Booch's book is about object-oriented *design*. OOA is an advance in systems analysis. It's where system requirements come from. You should have requirements before you start to design. It's a big deal to large systems developers. (Note: Yourdon has been one of the biggest names in systems analysis for over a decade.) Second, the Coad/Yourdon book is from 1988; Booch's was published this year. One of Booch's references was Coad/Yourdon (and also Shlaer/Mellor's OOA book). So one should not be surprised that Booch has improved on the object diagram- ming notation. But the content of the books are different. I don't think it's fair to say one is better than the other. If you really want the whole picture, get both. I also strongly recommend Shlaer & Mellor's book. [Extra disclaimer: These are my independent views and recommendations. This is not to be interpreted as an endorsement or opinion of Amdahl Corporation.] -- Ian Kluft ----------------------------- # Another flying fanatic UTS Systems Software \ |--*--| / # PP-ASEL Amdahl Corporation C - 172 /\___/\ Skyhawk # Member AOPA, ACM, UPE Santa Clara, CA o o o #include <std-disclaimer>
eberard@bse.com (Edward V. Berard) (11/06/90)
In article <2bH=02SFe1zd01@amdahl.uts.amdahl.com>, ikluft@uts.amdahl.com (Ian Kluft) writes: > > Books discussed in this posting: > Object Oriented Design with Applications by Grady Booch > Object Oriented Analysis by Peter Coad and Edward Yourdon > (also Object Oriented Analysis and Information Modeling by Shlaer and Mellor) > > In article <3634@vela.acs.oakland.edu> rdthomps@vela.acs.oakland.edu writes: > > If you are looking for a brainstorming session on how to > > draw sketches of objects and the relationships between > > them -- get Coad/Yourdons book (Haahmmm). > > > > However, if you are looking for a very well written book > > on Concepts, Methods, and Applications of the object > > oriented model -- GET BOOCHS book. > > The comparison here is between apples and oranges. Agreed. > > First, they are different mostly because Coad/Yourdon's book is about object- > oriented *analysis*. Booch's book is about object-oriented *design*. True. > OOA is > an advance in systems analysis. It's where system requirements come from. > You should have requirements before you start to design. It's a big deal to > large systems developers. (Note: Yourdon has been one of the biggest names in > systems analysis for over a decade.) Generally true. > Second, the Coad/Yourdon book is from 1988; Booch's was published this year. > One of Booch's references was Coad/Yourdon (and also Shlaer/Mellor's OOA book). > So one should not be surprised that Booch has improved on the object diagram- > ming notation. Although Booch may share a few things in common with Shlaer/Mellor (and virtually nothing in common with Coad/Yourdon), it would be inaccurate to say that Booch "improved" on existing diagramatic techniques. If you examine Booch's original work in object-oriented design (circa 1980), and his subsequent work, you will find that he has taken a substantially different path than either Coad/Yourdon or Shlaer/Mellor. > But the content of the books are different. I don't think it's fair to say > one is better than the other. If you really want the whole picture, get > both. I also strongly recommend Shlaer & Mellor's book. > Here is where I must speak. There are at least 3 different general trends in object-oriented methodologies. The first trend is made up of those people who have a strong background in object-oriented programming languages (oopls). These people seem to have a fairly good grasp of object-oriented concepts, but very little in the way of software engineering experience. Hence, their attempts at object-oriented design seem very "touchy-feely." (You might say that they are attempting to evolve "up" from the programming language level.) The second trend is composed of former "structured" advocates, e.g., Shlaer/Mellor and Coad/Yourdon. These people bring a lot of baggage with them, e.g., data flow diagrams and entity-relationship diagrams. They may have a grasp of more traditional software engineering approaches, but are only beginning to understand object-oriented concepts. (To their credit their later work shows an increased understanding of things object-oriented.) Therefore, their approaches seem wonderfully familiar to those with a more traditional background, and somewhat strange to those with a strong object-oriented background. The third trend (where I put Booch) is characterized by those with both a good understanding of object-oriented concepts, and a good understanding of software engineering. Further, those in this trend have attempted to modify some of the more traditional software engineering concepts to bring them into synchronization with object-oriented concepts. One of the distinguishing aspects of this group is the amount of time they have invested in object-oriented software engineering. Compared with Booch, Shlaer/Mellor and (definitely) Coad/Yourdon are relative newcomers to object-oriented technology. To be sure, there are things I can recommend from all trends. However, I make the following observations: 1. If you are not predisposed to rigorous software engineering, and you have a traditional object-oriented programming background, you will probably feel most comfortable with things like CRC (Class, Responsibilities, Collaboration) cards and responsibility-driven design. [These approaches do introduce a good deal of object coupling and do not seem to work well with medium to large projects.] 2. If you come from a more traditional software engineering background (e.g., structured and data modeling approaches), you will find Coad/Yourdon and Shlaer/Mellor to be more comfortable. You will also find, however, that these approaches are only partially object-oriented. (Although, they are evolving.) This means that some of the promised advantages of an object-oriented approach may not be fully realized. 3. Even if you feel most comfortable with Booch's new book, there will be pieces missing. Booch does not address the beginning of the life-cycle in depth, for example. -- 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 | ----------------------------------------------------------------------------
jhugart@umaxc.weeg.uiowa.edu (Jacob Hugart) (11/07/90)
From article <2bH=02SFe1zd01@amdahl.uts.amdahl.com>, by Ian Kluft: > ... > Second, the Coad/Yourdon book is from 1988; Booch's was published this year. > ... Correction: the copyright date in my book is 1991. (My software engineering class uses Smalltalk-80 and Booch's book is the text.) Seems Booch sort of jumped the gun! Jacob -- ----- Jacob Hugart <jhugart@umaxc.weeg.uiowa.edu> Database Consulting Group, Weeg Computing Center, University of Iowa
hansen@pegasus.att.com (Tony L. Hansen) (11/07/90)
< Jacob Hugart <jhugart@umaxc.weeg.uiowa.edu> < < Correction: the copyright date in my book is 1991. (My software < engineering class uses Smalltalk-80 and Booch's book is the text.) < Seems Booch sort of jumped the gun! All books published after July 1 in a given year have a copyright date of the following year. If you look at my book (The C++ Answer Book), which came out in Oct '89, you'll see that it has a 1990 copyright. This is standard practice in the book industry. (Don't ask me why.) Tony Hansen att!pegasus!hansen, attmail!tony hansen@pegasus.att.com
B.J.King@newcastle.ac.uk (Brian King) (11/07/90)
Folks....., I am following this discussion with interest, but I seem to have lost the full description of Booch's and Yourdon's book (ie publisher, ISBN # etc.. ). Could someone please oblige ?? Many thanks and apologies for the plebian request. Regards Brian Brian J. King | Voice: +44 91 222 6000 XT7241 Fax: +44 91 261 1182 Dept. of Chemical Engineering | JANET: B.J.King@uk.ac.ncl Newcastle University | UUCP : B.J.King%newcastle.ac.uk@ukc.uucp Tyne and Wear NE1 7RU UK | Internet: B.J.King%newcastle.ac.uk@cunyvm.cuny.edu -- Brian J. King | Voice: +44 91 222 6000 XT7241 Fax: +44 91 261 1182 Dept. of Chemical Engineering | JANET: B.J.King@uk.ac.ncl Newcastle University | UUCP : B.J.King%newcastle.ac.uk@ukc.uucp Tyne and Wear NE1 7RU UK | Internet: B.J.King%newcastle.ac.uk@cunyvm.cuny.edu
dch@aeg.dsto.oz.au (Dave Hanslip) (11/09/90)
eberard@bse.com (Edward V. Berard) writes: >... However, I make the following observations: > 1. If you are not predisposed to rigorous software engineering, and > you have a traditional object-oriented programming background, > you will probably feel most comfortable with things like CRC (Class, > Responsibilities, Collaboration) cards and responsibility-driven > design. [These approaches do introduce a good deal of object coupling > and do not seem to work well with medium to large projects.] > 2. If you come from a more traditional software engineering background > (e.g., structured and data modeling approaches), you will find > Coad/Yourdon and Shlaer/Mellor to be more comfortable. You will > also find, however, that these approaches are only partially > object-oriented. (Although, they are evolving.) This means that > some of the promised advantages of an object-oriented approach > may not be fully realized. > 3. Even if you feel most comfortable with Booch's new book, there > will be pieces missing. Booch does not address the beginning of > the life-cycle in depth, for example. > -- 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 | >---------------------------------------------------------------------------- As one currently grappling with applying OOD to a very large project, I must agree with the final sentence of para 1. I recall a statement I saw on the net some months back that large system design should proceed sequentially through steps of SA/SD and OOD. In my experience, with a laand very complex system, if one commences with OOD, one is overwhelmed by complexity. Commencing with SA/SD allows smaller less complex subsystems to be identified to which OOD (a la CRC cards) can then be applied. SA/SD (or functional decomposition if you like) is then again applied within classes to member functions. With regard to Booch's new book, I found guidance on subsystem selection and subsequent integration of subsystems to be missing. Also, how to achieve this integration (both organisationally and practically) using a language such as C++. Course, I'm not complaining, it's exciting working in a new area, breaking new ground, going boldly where no man has gone before (sorry, boldly going where nobody has gone before!). 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
eberard@bse.com (Edward V. Berard) (11/09/90)
In article <1289@fang.dsto.oz>, dch@aeg.dsto.oz.au (Dave Hanslip) writes: > I recall a statement I saw on the net some months back that large system > design should proceed sequentially through steps of SA/SD and OOD. In my > experience, with a laand very complex system, if one commences with OOD, one is > overwhelmed by complexity. Cencing with SA/SD allows smaller less complex > subsystems to be identified to which OOD (a la CRC cards) can then be applied. > SA/SD (or functional decomposition if you like) is then again applied within > classes to member functions. 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. -- 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 | ----------------------------------------------------------------------------
cws@janus.Quotron.com (Craig W. Shaver) (11/11/90)
In article <0B010001.imp7d9@bse.com>, eberard@bse.com (Edward V. Berard) writes: ... other stuff .... berard reply follows ... > > 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. > > -- Ed This is a blanket statement and sounds a little religious to me. 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. 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. Craig W. Shaver ================================================================ Legend Systems Inc. | Phone: (206) 348-0713 | uucp: hacgate!janus!cws Post Office Box 40297 | craig@tradr2.quotron.com Bellevue, WA 98004 ================================================================
eberard@bse.com (Edward V. Berard) (11/23/90)
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 | ----------------------------------------------------------------------------