Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uwm.edu!uakari.primate.wisc.edu!brutus.cs.uiuc.edu!apple!lins From: lins@Apple.COM (Chuck Lins) Newsgroups: comp.object Subject: Re: Looking for an OOD speaker/teacher Message-ID: <38260@apple.Apple.COM> Date: 1 Feb 90 17:59:58 GMT References: <485f5932.146d0@freefall.UUCP> Distribution: na Organization: Apple Computer Inc, Cupertino, CA Lines: 55 In article <485f5932.146d0@freefall.UUCP> wyzenbeekm@freefall.UUCP (Mark Wyzenbeek) writes: >Here at AGCS we have a small group that is investigating object orientation >for the purpose of generating an OOD methodology for large, real-time >critical, fault tolerant systems. We have no in-house experience with OO. >Our plan is to research different author's methods and opinions, group >like methods, and divide into 3 sub-teams to test the methods on a case >study. (We are now at this point in the plan.) We will then examine the >advantages and disadvantages of each sub-group's methods and attempt to >create a method that will work for us. > >Some of the authors we have researched are : >Paul Ward, Brad Cox, Norm Kerth, Andy Rudmik, Grady Booch, Ivar Jacobson, >Bertrand Meyer, Shlaer and Mellor, and, of course, Ed Berard. > [stuff deleted about speaker qualifcations] >-- >Mark Wyzenbeek (wyzenbeekm@gtephx) >UUCP: {ncar!noao!asuvax | uunet!zardoz!hrc | att}!gtephx!wyzenbeekm >AG Communication Systems (formerly GTE CS), Phoenix, AZ >(602) 582-7035 IMHO, this is one of the central problem areas with OOP today - nobody's done really large systems with it for critical applications. (If you have done so, please post to correct my erroneous knowledge base.) Don't get me wrong, I'm very much in favor of OOP/OOD, and consider it a very promising technology. I myself have been involved in a 100,000 loc application developed in a team of 5 people over a 6 month period and using MacApp (TM). This is not a large piece of software these days. There are software projects with millions of loc. No OOP design technique *that I know of* (important qualification) has proven itself in projects of the size mentioned. Let me rephrase this. With the current state-of-the-art in object-oriented programming and design, we do not know how to build such systems. The techiques advocated today (with all the hype that expert systems had) may not be scalable. They may not produce maintainable systems. Remember 79% or more of the total life cycle cost for software will be spent in maintenance (that should have been 70%). Program understanding alone may consume as much as 35% of the total life cycle cost. (Program understanding means that the unfortunate soul who takes your position after you've moved on to bigger and better things now has to figure out what was going on in this guys/gals head when they wrote the software.) Would you trust that nuclear power plans operating software any more just because it was object oriented? How about the aircraft control software? What about the ATM software? [If this doesn't stir up debate on comp.object, nothing will]. -- Chuck Lins | "Exit left to funway." Apple Computer, Inc. | Internet: lins@apple.com 20525 Mariani Avenue | AppleLink: LINS Mail Stop 41-K | Cupertino, CA 95014 | "Self-proclaimed Object Oberon Evangelist" The intersection of Apple's ideas and my ideas yields the empty set.