wyzenbeekm@freefall.UUCP (Mark Wyzenbeek) (02/01/90)
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.
We are considering bringing someone in to spend a day or two talking to
us about OO. We are looking for someone with experience with large ...
(see above) systems. A good communicator who has taught a class before
would be good, but experience is the key. Obviously we already know the
basics and are looking for detailed information. If anyone could suggest
someone who would ge good for this purpose (or if you think you would be
good for this) please let me know.
Please E-mail to the address below. The route that our postnews supplies
will not work. If you think your suggestions are of general interest then
by all means post instead. Some discussion of whether or not our plan is
likely to produce a workable methodology would also be welcome.
Thank you for your attention.
--
Mark Wyzenbeek (wyzenbeekm@gtephx)
UUCP: {ncar!noao!asuvax | uunet!zardoz!hrc | att}!gtephx!wyzenbeekm
AG Communication Systems (formerly GTE CS), Phoenix, AZ
(602) 582-7035lins@Apple.COM (Chuck Lins) (02/02/90)
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.
UH2@psuvm.psu.edu (Lee Sailer) (02/03/90)
In article <38260@apple.Apple.COM>, lins@Apple.COM (Chuck Lins) says: > >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, Is NextStep large? I don't know. The problem with "large" is that as soon as people do it, it isn't anymore. Like the wag who defined AI as the study of programs we haven't figured out how to write, yet. In some ways perhaps the original question is a little naive. It boils down to "We are about to write a huge program, and are trying to decide if we should use an OOPL to write it." Instead, they could take a more exploratory approach, where they build small systems that test their ideas in a couple of different languages, with the idea that the ideas that work best will be translated into encouragement to continue in that style. What's the proverb? Plan to throw the first one away. You will anyway. I bet that they could start this project in AppleSoft Basic, and still switch to a better language later with little loss of time or experience. Likewize, they could start in Eiffel or Object-C, and if that turned out to not be such a good idea later, they could drop back to a language that they already know well. Of course, they could just start in a language they are already compfortable with, but then they'd never know what they might have missed. One last idea. Along with the big name speaker, invite a bunch of local experts and academics. Anyone who'll come, really. I'd go, for example, to hear Cox, Meyer, Berard, or probably even those other guys I didn't recognize (just my parochailism, no comment intended on their expertise), and after the expensive guy had flown away, I'd be a low priced way to kick ideas around. lee