From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=0.6 required=5.0 tests=BAYES_05,INVALID_DATE autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,8264dac98bc604d8 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 1993-03-14 13:51:47 PST Path: sparky!uunet!haven.umd.edu!news.umbc.edu!nobody From: berman@umbc.edu (Mike Berman) Newsgroups: comp.lang.ada Subject: Re: The actual quote from the Post AAS article Date: 14 Mar 1993 03:24:12 -0500 Organization: University of Maryland, Baltimore County Campus Message-ID: <1nuq3cINNk7@umbc7.umbc.edu> References: <1993Mar12.232510.7619@seas.gwu.edu> <343@fedfil.UUCP> <1993Mar14.003649.24085@seas.gwu.edu> NNTP-Posting-Host: umbc7.umbc.edu Date: 1993-03-14T03:24:12-05:00 List-Id: Hmmm... The intent of making this a separate thread from the original posting on the subject was to avoid a Ted Holden vs. the net flame exchange. Oh well! Straying from the topic of where Ted flies and what he drives... If I remember my chronology correctly, the state-of-the-art in software engineering awareness has matured along with its practice. When FORATRAN was developed, it was considered by many to be a high level _specification language_ which, relative to the machine and assembly code programming of the day, it was. By today's standards of reuse and portability, FORTRAN programs from two or three decades ago are considered rather low level programming (low level meaning application/machine dependent, not any kind of quality statement). During the '70's, Ada was developed to address the software crisis in very specific terms - the question was "Is it possible to design a language which incorporates software engineering features?" (well, one question - standardization on a single DoD programming language was a biggie, too). The answer is yes - Ada and many modern languages are living proof of that. Is is the _entire_ answer? No. The "component-based software society" with its "software ICs" didn't occur in 1983 and is still barely present today. Ada does not solve the software crisis - but its precepts are most certainly a part of that solution. Look at any of the software reuse guidelines developed over the last few years. Language is identified as one relatively small part of the problem. Cultural changes, process, all that Watts Humphrey stuff - those are other key ingredients. The development of OO paradigms has taken a parallel tack. OOPLs like Smalltalk were up first. For large developments going straight to coding isn't wise, hence the need for OOD. But OOD doesn't map well from functional requirements, therefore OOA is needed. The point of this Sunday A.M. rambling is (1) it beats shovelling snow, and (2) nobody up front said "Hey, wouldn't it make things easier if we wrote object-oriented requirements?" Similarly, while Ada may have been envisioned as a "solution" to the software crisis in 1974, we're a lot smarter about software engineering needs in 1993. -- Mike Berman University of Maryland, Baltimore County Fastrak Training, Inc. berman@umbc.edu (301)924-0050