.RR--!----!----!----!----!----!----!----!----!----!----!-------------------!-R .po 5 ..po 1 .he ASR Newsletter, Issue 12 Supplement, Oct 87 .fo Page # Ada (tm) Software Repository (ASR) Newsletter Issue 12 Supplement, Oct 87 Richard Conn, Newsletter Editor Published by Echelon, Inc. THIS SUPPLEMENT Theme: Ada Education, Software Engineering, and Reuse I. Ada Education and Training ................................. 2 A. Part 1 ........ 2 D. Comments on Parts 1-3 ........ 8 B. Part 2 ........ 4 E. Part 4 ....................... 14 C. Part 3 ........ 6 F. Comments on Parts 1-4 ........ 17 II. The Human Element in Software Engineering .................. 19 III. The DoD and Software Reuse ................................. 21 A. Part 5 ................................................ 21 B. Comments on Part 5 .................................... 23 ----------------------------------------------------------------------------- I wish to thank the following people for sharing their insights and opinions on the Defense Data Network: Drew Adams Mike Feldman Laboratories de Marcoussis Department of EE & CS Centre de Recherche de la The George Washington University Compagnie Generale d'Electricite Sam Harbaugh Ed Berard Bob Munck EVB Software Engineering, Inc. The MITRE Corporation Carsten Bormann Lt. Scott A. Norton, USN Communications and Operating Naval Postgraduate School Systems Research Group Technical University of Berlin Pat Rogers University of Houston at Clear Lake Lawrence Crowl Computer Science Department Pete Schilling University of Rochester ALCOA Laboratories Dennis Doubleday D. Schimisky Department of Computer Science Naval Air Development Center University of Maryland Stanley Shebs Dick Dunn University of Utah NASA Ames Research Center Craig Wylie Department of Computing University of Lancaster, UK -- Richard Conn, Editor ASR Newsletter 12 Supplement --------------------- NOTE: Statements made in this supplement should generally be considered to be personal opinions of the individuals and not necessarily the opinions of the U.S. government or any specific company or organization. .pa ============================================================================== I. A. Ada Education and Training - Part 1 Date: 1 May 1987 04:12:44 PDT Subject: Ada Education and Training - Part 1 From: Edward V. Berard It has happened again. Some DoD contractor has contacted our company for some "Ada training," and has described a "recipe for disaster." Let me fill you in on the details: 1. Apparently this contractor was awarded a contract even though there is little evidence to suggest that anyone working on the software has any real Ada experience. (You know how this works - pick a scenario: a) the contractor added the word "Ada" to the list of languages on the resumes at the back of the winning (?) proposal; b) the contractor assured the naive contracting office that the technical staff would have "adequate Ada training" by the time any software was written; c) the contractor used resumes of "qualified" individuals who are too busy on other projects to be assigned to the current project, so management thought that they could either hire someone with the needed skills by the time the coding started, or provide some absolute minimum of training to the people actually assigned to the project.) 2. Not realizing that Ada technology impacts the entire software life- cycle (including business practices), management has waited until the coding is about to start to train their technical staff in what, to the management, is "just another programming language." 3. Not wanting to waste any money on "software foolishness" (after all, the management believes that it is the hardware engineering/mathematics/science that is the "real work"), management has dictated that the "Ada education" will consist almost entirely of one week of classroom instruction. Being somewhat generous, management has also provided some "Booch books" and some "Alsys tapes" which the technical staff can look at, on their own time. (I am not knocking the quality or usefulness of these products, just their misuse.) 4. Since the only computer that has an Ada compiler on it is tied up with useful work, the one week of training they wish us to provide is a "hands-off" course. We may provide the students with some small "paper exercises," but we are being encouraged to forego any labs so that we can "cram as much of the language into the heads of the participants as possible." 5. The management is not open to any suggestions on how to improve the quality of the Ada training. It also happens that some other well-known Ada experts have attempted to enlighten the management, but have been rebuffed. The results of this project can be foretold quite easily.: - The programmers will find the Ada language to be "large, complex and confusing." The code they produce will be "AdaTRAN" at best. There will be a great deal of time spent trying to understand that "dumb reference manual." Ada books that emphasize syntax to the exclusion of software engineering will become prized possessions. Especially valuable will be books and references which treat Ada as "a superset of Pascal." - The programmers will find that the Ada development system is confusing to use. Since it is likely that the design will be in a constant state of revision, the specification parts of the Ada program units will change fairly often, necessitating frequent re-compilation and relinking. As the amount of code grows, the time spent re-compiling and relinking will quickly reach an intolerable level. Frequent references will be made to the large amount of object code produced, and its inefficient running speed. But after all, isn't that what one would expect from such a large language? - The programmers will find many features of the Ada language to be extremely bothersome. There will be frequent complaints about strong typing, private types (if they are used at all), the time for task rendezvouses, and those strange generic things. - More source code will be produced than for a comparable project written in FORTRAN or Pascal. The detractors of Ada will gleefully point to this as an expected result. - The project will be late, overbudget, and the software will not perform at anywhere near the original specifications. Looking for a scapegoat, management and the technical staff will grab the first inanimate object they can find (you guessed it -- Ada), and blame it for any shortcomings or project failures. The contracting office, being equally naive about Ada technology, will accept without question that Ada is the culprit. There will, of course, be many other problems, but let us now focus our attention on the root causes. The Ada language was designed by first identifying a number of desirable software engineering features (e.g., data abstraction, information hiding, and encapsulation), and then incorporating these features into a programming language. Since a good number of these concepts are foreign to most programmers and managers, it comes as no surprise that the concepts are often abused, if they are used at all. Many advocates of Ada technology have pushed the language, and ignored the software engineering. Yes, there have been some people within the DoD, and outside of the DoD, who have stressed software engineering, but their voices have been lost in the din. [Note the on-again, off-again funding for STARS.] Part of the blame lies at the feet ofthe DoD for not stressing software engineering strongly enough. Within the Ada Joint Program Office (AJPO) is the Ada Software Engineering and Education and Training (ASEET) group. Hopefully, one of ASEET's goals is to define minimal qualifications for an Ada software professional. This should be in addition to definitions for course content in an industry targeted Ada and software engineering training curriculum. Without any guidance, contractors are free to train (or not train) their technical staffs in any manner they choose. Further, contracting offices continue to have no idea as to what constitutes a qualified Ada professional. Of course, I am not going to let the contractor's management off the hook. Unfortunately, they learned a long time ago that software quality was little more than a buzzword. (Note: Much is known about software quality, including how to measure it. Sadly, this technology seems to be largely ignored.) They seem to get paid regardless of the "quality" of the software product. Is it any wonder why they view software as a necessary evil, and software engineering training as a useless luxury? So what if the software fails, so long as the hardware holds up. There is a one-word definition for learning: change. The hope behind Ada technology is that this change will be for the better. Until there is a greater recognition that Ada education and training is different, the change may not be what the proponents of the new technology have predicted. -- Ed Berard (301) 695-6960 ============================================================================== I. B. Ada Education and Training - Part 2 Date: 1 May 1987 05:20:10 PDT Subject: Ada Education and Training - Part 2 From: Edward V. Berard Some years ago, when I began offering one of the first hands-on Ada courses, I invited some of the members of the Ada Joint Program Office (AJPO) to sit in on the course. Those that accepted my proposition gave me some interesting feedback. It seem to the AJPO folks that my Ada courses were severely lacking in software engineering. I was puzzled. I had incorporated sections on structured programming and coding style into my notes. What more did they want? I now know that my first attempt at an Ada course was little more than a glorified Pascal seminar. I gave short coding examples for labs, and treated packages, tasks, and generics as "advanced features." There was little discussion of abstraction, information hiding, and encapsulation. The message eventually got through to me that a "syntax course" was a "no no," and that software engineering was much more than just structured programming. However, there was still a major problem. As you know, the software community, as a whole, is initially not very receptive to software engineering concepts. Managers and programmers alike are obsessed with code. The sooner you can get down to coding the more comfortable they feel. Software engineering is mockingly referred to as "software religion" by many. Management continually assures me that there may be time to learn something other than coding "later." Let me assure you that it takes a great deal of persuasion ("singing and dancing," cajoling) to get management and the technical staff to consider software engineering as an important part of Ada training. Fortunately, I have two things going for me. First, most software professionals want to do a good job. If I can show them a way which will make their software products better, and justify my reasoning, they will generally accept the idea. Second, software types are extremely goal oriented. Given proper goals, they will work hard to achieve them. Unfortunately, there are those Ada trainers who are not as persuasive as myself. They are easily bullied by their client's management and technical staff into giving syntax-only courses. Since their clients are often blissfully ignorant of the impact of poor software engineering, especially on an Ada project, the clients often see no immediate benefit from the incorporation of software engineering technology into an Ada training course. In a perfect world, software contractors would want to do everything in their power to produce a quality product. Unfortunately, many DoD contractors seem to be primarily driven by money and DoD regulations which must be adhered to to ensure the continued flow of money. (Don't get me wrong. I am very much a capitalist.) This implies that one way to improve the current state of Ada education and training might be some gentle prodding by the DoD. Say, in the form of some recommendations from the Ada Software Engineering and Education and Training (ASEET) group. Two months ago, I received a message from Doug Bryan who, among other things, teaches an Ada course at Stanford University. I think you will find his message to be of general interest. ------------------- Message Follows ------------------------ I tried something new (and costly) with my Stanford class this year. Usually I teach abstraction -> misc. s/w eng -> OOD -> reuse -> the details of Ada This year I tried reversing it since "the powers above" wanted it to be more of a programming class and less of a Software Engineering class. So, I taught the details of Ada -> abstraction -> OOD (OOx) -> reuse I'm now grading some of the final projects and realizing this was a real mistake. Their code is terrible and it's my fault. Their packages are best classified as "collections of stuff"; Private types, generic formal parameters, and decent use of attributes are practically non-existent; most every subprogram is a procedure, all parameters of which are mode in out; ... the list goes on and on. It was costly, but I have seen first hand empirical evidence of what the Ada community has been telling itself (and others) for years: Ada without a software engineering foundation is MIL-STD Pascal. live and learn... ------------------ End of Message -------------------- -- Ed Berard (301) 695-6960 .pa ============================================================================== I. C. Ada Education and Training - Part 3 Date: 3 May 1987 12:23:12 PDT Subject: Ada Education and Training - Part 3 From: Edward V. Berard Recently, an instructor at one of the military academies told me how she had selected a book for an introductory Ada class. She had rejected Booch's book (Software Engineering With Ada) in favor of another text. It was not so much the text she had selected that bothered me, as it was her reason for rejecting Booch's book. "Booch takes too long to get to any code.", she said, "I want to see something like 'Hello World' real quick." [For those of you who have never programmed in C, or, more precisely, read Kernighan and Ritchie's book on the C programming language, the "Hello World" program is the first C program covered in many introductory C courses.] Kernighan and Ritchie (K&R) and Booch represent two very different views on teaching programming. K&R stresses the age old thinking which says that students of software must see, write, and execute code before anything else will be meaningful. Booch, on the other hand, stresses that students should know what they are doing before they attempt to write code. The K&R approach has its roots in software antiquity. Programming code is the "cocaine" of the software world. To many programmers and managers it is all that matters. While software is being designed, managers wait nervously and the programmers/coders wait impatiently. One the design document is finished, the "real work" can begin. With any luck the code which is produced may closely resemble what is described in the design documentation. To an outsider this infatuation with code seems strange. One hears from many sources that coding usually takes up only 10 to 15 percent of the software life-cycle. Why then do we focus so much attention on the syntax and semantics of the programming language? Several reasons come to mind: 1) Many of those who are already programmers and instructors believe strongly that, only if one is intimately familiar with code, can one fully understand the implications of any other part of the software life-cycle. 2) Some in the Ada community feel that the software engineering embodied in the Ada language will either be obvious to the neophytes or that through constant use of the Ada language, good software engineering concepts will be absorbed "via osmosis." 3) The concept of "instant gratification" is very much entrenched in modern software production. Sitting at their terminals in their offices or cubicles, programmers very much resemble "rats in Skinner boxes" who continually press a lever (the RETURN key) for constant reenforcement of their behavior. We are only now beginning to see tools which will allow us to "execute a design." 4) Software people have little faith in those concepts that come before the coding phase. "How can anyone possibly describe something which is not yet coded?", they reason. There is little emphasis on non-coding tasks in most commonly available training. It seems that most people have not understood the intentions of the U.S. Department of Defense (DoD) regarding the Ada effort. It is better engineered software that is desired, not merely "FORTRAN rewritten using the syntax and semantics of the Ada language." Too much emphasis has been placed on a tool (Ada) and not on the task (better software). Learning the details of the Ada language is at the "noise level" of most software projects. In fact, only a very small part of any "Ada education effort" needs to focus on the language itself. Concepts like configuration management, software design methodologies, data abstraction, concurrency, software testing, and project management must be an important part of any Ada training effort. Of course, there are many problems which must be solved, for example: - Contracting offices and project managers must recognize that the least significant part of any Ada training effort is the learning of the syntax and semantics of the language. Yes, it is important for programmers to learn the Ada language, but this is a trivial task compared to learning about modern software engineering. - Many of those who "teach" the Ada language are unfamiliar with the bulk of modern software engineering. For example, most may only have familiarity with functional decomposition approaches to software development. Few can name any references on software quality assurance. A surprising number cannot cite any studies which correlate coding style with debugging and testing efficiency. - When software engineering concepts are introduced into an Ada curriculum, it is often introduced in a very "watered down" form. This is so that those least prepared to develop quality software can maintain their positions -- managers *and* programmers. - There is still a widely-held belief that all that is involved with transitioning to Ada technology is a change of programming language. In reality, software development and maintenance practices will have to change, in-house and government software standards will be impacted, and business practices will change. [It is often those in the commercial sector who pick this up more readily than those in the defense sector. Further, those doing business applications using Ada technology more quickly see the impact of Ada technology than those doing scientific and engineering applications.] I would recommend that those charged with procuring Ada training, and who determine the Ada qualifications of a potential contractor, beyond mere coding ability. We must recognize that probably the greatest effort facing the advocates of Ada technology will be reformation of "code junkies." -- Ed Berard (301) 695-6960 .pa ============================================================================== I. D. Comments on Parts 1-3 Date: Mon, 4 May 1987 09:48 EST From: mike feldman Subject: Ed Berard's postings on education Nice going again, Ed. A cynic's view of all this might be that some of these contractors (and their opposite numbers in the DoD project offices) may - precisely - _want_ Ada to fail so they can continue with business as usual or find a convenient excuse for a waiver. You might accuse me of coming from a self-serving position, which I am, but I'm still convinced that the "Ada community" is still going about this in a short-term fashion. Ada and modern software engineering will succeed in the long run if we make it pervasive in the education process, which means - in the long run - pervasive in university/college computing education. This means a number of things: 1. Get the computer science and computer engineering accreditation bureaucracies to recognize that software engineering is a legitimate discipline for undergraduates. It's no coincidence that most software engineering teaching is done at the grad level - you don't have to satisfy accreditation bean-counters because graduate programs aren't accredited, only undergrad (did you know that?). 2. Get the recognized textbook authors and mainstream publishers to write books that will fit university curricula, which will not change overnight. _Very few_ Ada-oriented books fit into the right undergrad pigeonholes. I tried to do that with my Data Structures book, which sneaks Ada and software engineering into a mainstream undergrad course - where is my competition? Booch's new components book is _wonderful_ but probably too voluminous and overtly Ada-oriented to work in undergraduate courses, although I would love to be proved wrong. 3. The Ada compilers-and-tools industry is also taking the let's-get-the short-term-bucks approach. This is a well-known hobbyhorse of mine, so I won't bore you with it again - but until the schools can get into Ada and Ada environments without going broke in the process, they'll stick to good ol' Pascal or whatever (Modula-2 _is_ starting to catch fire, though: do you think most of the same software engineering can be done with packages but no other Ada goodies?).The quality of PC and Mac tools for Pascal and C oriented education gets better every day. And students can buy it for $35-50 a copy. Where is the _software engineering_ education tool stuff? Where is Ada for the Mac? Does anyone seriously believe that a school will plunk down $10000 for _one_ copy of AdaGraph,even if you buy into the Pamela culture? Does anyone seriously think a school will invest heavily in Alsys systems? We have _30_ AT's in a lab. Shall we put Alsys on 30 machines, or spend the same money to buy 30 Macs or PS2/50's? If you were the guy making a recommendation to University managers (who are _really_ naive about software engineering), what would you recommend? This is not a hypothetical question: I am in in _exactly_ that position. Ed, and all the rest of you on the net: I'm not asking you for a handout. I've spent the last five years building grassroots support for Ada in my own school. I got it, but boy was it hard work, and I am not sure I would invest the effort again, because 5 years ago I thought industry would recognize the need to do this nationally, but boy have I been disillusioned! Ada and modern software engineering have _tremendous_ potential, and not just in the military community. I have spent five years as a computer-science professor trying to realize some of this potential. Industry: a few of us in the schools out here are really workin' hard to help you out; anybody ready to help _us_? Michael Feldman, Professor Department of Electrical Engineering and Computer Science The George Washington University Washington, DC 20052 202-994-7593 MFELDMAN@GWUVM.BITNET MFELDMAN%GWUVM.BITNET@WISCVM.WISC.EDU --------------------------------------------------------------------------- Date: 13 May 87 07:45:04 GMT From: hao!ico!rcd@ames.arpa (Dick Dunn) Subject: Re: Ada Education and Training - Part 3 In one part of a rather lengthy article, Edward Berard takes on Kernighan & Ritchie's _The_C_Programming_Language_. He was talking about an introductory text, so I'm not sure why he's picking on K&R, but he compares their book with Booch: > Kernighan and Ritchie (K&R) and Booch represent two very different > views on teaching programming. K&R stresses the age old thinking which > says that students of software must see, write, and execute code > before anything else will be meaningful. This is nothing more than an unthinking cheap attack on K&R. It would seem that Mr. Berard believes that K&R intends to teach programming simply because he thinks it ought to do so. However, if one manages to read as far as the fourth paragraph of the Preface, one finds: "This book is not an introductory programming manual; it assumes some familiarity with basic programming concepts..." Perhaps this was overlooked--after all, the Preface of a book may not be good reading (unless you want to know the purpose of the book:-), so let's have a look at the beginning of the "real" text. If we read as far as page 1 of "Chapter 0" we find the following terms used without prior definition: programming language, operating system, text-processing, data-base, characters, character strings, addresses, storage allocation, heap, garbage collection, file-access methods, single-thread control flow, coroutines I cannot, in my wildest dreams, imagine a normal neophyte being able to read this section...; he won't even be able to parse some of the sentences. It is not the case that K&R present the "programming first, thinking later" approach. They have set out to provide a ready introduction and reference for a particular programming language, and have succeeded in doing so. K&R have been set up. "We want an introductory text. We will label them an introductory text. Then we will demonstrate that they have failed." [Hey, look, the shop manual for my car doesn't provide spiritual guidance either.] A somewhat worse confusion over teaching "programming" (I would rather a less loaded term implying "the complete process of constructing functioning software") immediately follows in Berard's article: >...Booch, on the other hand, > stresses that students should know what they are doing before they > attempt to write code... The reality of teaching lies in between the code-first approach (mis- attributed to K&R, but it does exist elsewhere) and an approach which holds off the code until the concepts are ingrained...because the fact of the matter is that very few students can hang on to a substantial abstract framework without something concrete to which they can relate it. This is easy to observe in engineering and physical science undergraduate curricula. In the first year the students will be taking (let us say) calculus and some substantial classical physics which requires calculus. If the calculus courses follow a purely mathematical development of functions, series, limits, etc. without adequate illustration of the application of the concepts, the math instructors find that their students are learning calculus better--and faster--in their physics courses. (There are, of course, areas where it's hard to find the concrete material-- for example, some concepts in topology--but the production of software is not such an area.) I'm not going to argue that the coding should come first. That's not what I'm saying and it's not even in the back of my mind. It would be silly to teach that way...but it's equally silly to think that you can (let alone should) teach the concepts first and the programming later. That's as absurd (and antiquated) as the "waterfall model" of software lifecycle. Consider it an overreaction to the "code first" approach. It's all too simple: Teach the two together. Start developing the idea of a programming language and a programming environment as you develop the first concepts. By the time you've got enough concepts to think about interesting problems, you've also got enough concrete information to show what an actual solution to a simple problem might look like. And, I know it's heresy in this group where so many people think that there is One True Language, but you can use a couple of different programming languages to illustrate examples--if you're careful, that can prevent students getting hung up on one language. (This is somewhat how I was first taught. Perhaps the two languages were not the best choices--FORTRAN and BASIC--but hey, that was twenty-odd years ago, and it worked then.) Another way to look at what I'm saying: overemphasizing the coding is bad; ignoring it is just as bad. A little more from Berard's article: > Programming code is the "cocaine" of the software world. To many > programmers and managers it is all that matters... Replace "cocaine" with "currency". To many clients in the commercial world, the code is [almost!] all that matters, because they aren't interested in plans and studies except insofar as they help produce the end result, and they don't believe that they can sell specs-by-the-pound. The methodology is not the end product. >...While software is > being designed, managers wait nervously and the programmers/coders > wait impatiently... So get some good managers! Sheeeesh! As for the programmers/coders: If you divide your world into "those who design" and "those who implement the design" you have created a caste system. You have a social problem and you cannot solve it by waving methodology about. >...To an outsider this infatuation with code seems strange. One hears > from many sources that coding usually takes up only 10 to 15 percent > of the software life-cycle... This is a favorite litany of the methodology mavens...but if you think about it, it's only reasonable. Why is coding only 10-15%? Well, one set of reasons is that the code produced is so often late, inefficient, not robust, inscrutable, unadaptable, and nonportable. We spend the bulk of our time screwing around with code that's already written because it was lousy code in the first place...somehow I don't buy the idea that the solution is to improve our ability to screw around with the code! Couldn't we try just a little to reduce the need to screw around with it? If we had done a good job with the 10-15% of the work, a lot of the 85-90% remaining wouldn't have been necessary. A couple more comments from Berard: > 4) Software people have little faith in those concepts that come > before the coding phase. "How can anyone possibly describe > something which is not yet coded?", they reason... Rubbish. These aren't software people. > It seems that most people have not understood the intentions of the > U.S. Department of Defense (DoD) regarding the Ada effort. It is > better engineered software that is desired, not merely "FORTRAN > rewritten using the syntax and semantics of the Ada language." Too > much emphasis has been placed on a tool (Ada) and not on the task > (better software). I agree with this in a perverse sense: I do not understand it to be the intent of DoD to produce better engineered software instead of a new language. If that is what they desired, why did the requirements used in Ada development (the *man sequence) specify nitty details of syntax and semantics instead of focusing on requirements? Why did they spend a decade screwing around with a programming language before getting on to the environment? Berard is quite right that "too much emphasis has been placed on a tool...and not on the task..." - and the nature of the development of Ada is the best example of that misplaced emphasis. -- Dick Dunn {hao,nbires,cbosgd}!ico!rcd (NOT CSNET!) (303)449-2870 --------------------------------------------------------------------------- Date: Thu, 14 May 87 17:06:02 PDT From: "LT Scott A. Norton, USN" <4526P%NAVPGS.BITNET@wiscvm.wisc.edu> Subject: Re: Ada Education and Training - Part 3 In <1061@ico.UUCP>, hao!ico!rcd@ames.arpa (Dick Dunn) remarked, "A somewhat worse confusion over teaching 'programming' (I would rather a less loaded term implying 'the complete process of constructing functioning software') immediately follows in Berard's article:" I think the term he wants is "software engineering." The hard part about teaching software engineering is that the need for good engineering is not apparent at the classroom level. The programs that are written by individuals in an undergraduate software course are less than a thousand lines. They can be fully understood by one person. They do not undergo maintenance, and do not have to adapt to changes in the environment, new hardware, or changed specifications. They usually do not need to be robust, since they are not used by many different users or under tight constraints. There is certainly a skill called "Programming." Selecting algorithms and data structures, making loops start and stop in the right places, avoiding deadlocks; they are all part of programming. But, when you move to programs of over one million lines, the problems you face are different. Consistancy of the specification becomes more difficult. Testing and debugging become more difficult ( some people say impossible ) Training new staff is necessary as the work progresses. As people leave the project, the knowledge they have must be passed down to the remaining staff. Its not a difference in scale, its a difference in kind. If you teach a course in programming, you expect people to come out of it knowing how to write code. Give them clear specifications and they should be able to write modules that will meet the specs. But writing the specs, making the design decisions that determine the specs, managing the programmers, designing tests, chasing down the requirements that the system must meet, developing the documentation, training the staff ( not how to code, but what the project is supposed to do ) are part of the larger world of software engineering. Its a different dicipline, and can't be taught in a single course. Ada is supposed to be a language that makes it easier to match modules to specs, design tests, eliminate some tacit assumptions about interfaces, and make code more readable to ease the problems of bringing new people into a project or of doing maintenance. Ada will be successful if it improves not only coding, with its 15% of the load, but also these other areas. Programming : Software Engineering :: Word Processing : Writing a novel When I was in fourth grade, I thought that higher math was being able to do, like, really big long division problems. LT Scott A. Norton, USN Naval Postgraduate School Monterey, CA 93943-5018 4526P@NavPGS.BITNET --------------------------------------------------------------------------- Date: 6 May 87 08:56:00 GMT From: mcvax!unido!tub!cabo@seismo.css.gov Subject: Re: Ada Education and Training - Part 3 - (nf) In an otherwise very reasonable article in comp.lang.ada, ucbvax!EBERARD (probably wrong address) writes: () [...] K&R stresses the age old thinking which () says that students of software must see, write, and execute code () before anything else will be meaningful. Booch, on the other hand, () stresses that students should know what they are doing before they () attempt to write code. The K&R approach has its roots in software () antiquity. K&R is a book about a programming language (a good one at that, by the way). Grady Booch's book is a book about software design in a programming language. These are two entirely separate subjects. You can learn software engineering methods without learning the syntax of the Ada language at the same time, and you can learn programming in C without simultaneously learning software engineering methods. A book that both teaches software engineering and a programming language seems to assume that the intended audience still needs to learn both subjects. Probably a reasonable assumption for many people who are now learning Ada. Even more so in that Ada does have a few fine points that only can be unleashed in conjunction with knowledge about software engineering. For the C language novice in 1978 (when K&R was written), such an assumption would have been invalid; I would have been bored if K&R had placed more emphasis on the methods I already had been comfortable with in languages like Simula etc. that I had used before. Its successor, the book about the C++ language (Bjarne Stroustrup 1986) still assumes some basic knowledge about software engineering when giving rules of thumb for the use of C++. The Ada Reference Manual (which is comparable to the reference sections of both K&R and BS) also does not give any guidelines for design and testing methods (and we all agree it should not do that), but if you know anything about design you immediately understand what packages and all these Ada concepts are about, although these are complex enough that a good text will help you use the right concept at the right time. For the software engineering novice (as opposed to the C language novice that K&R addresses), it is an interesting issue (e.g. see comp.edu) whether some early experience in simple programming helps understand software engineering concepts later or just helps people to start programming without design. For university education, I still prefer first to learn to put letters on paper (i.e. programming) before learning to write entire books (i.e. software design). However, just being able to put letters on paper does not make you a writer (i.e. just being able to program does not make you a programmer). Carsten Bormann, Communications and Operating Systems Research Group Technical University of Berlin (West, of course...) ============================================================================== I. E. Ada Education and Training - Part 4 Date: 7 May 1987 04:27:38 PDT Subject: Ada Education and Training - Part 4 From: Edward V. Berard You might say that this is a discussion of the "dynamics of Ada technology education." First, a few simple ground rules: 1) Education is different from training. To be crude about it, training is what you do with dogs, education is what you do with people. Seriously, training of people works best with material which is extremely simple and has well-defined ("black and white") rules. If something can be done by rote, then training is appropriate. Education of people is what is required when the rules and guidelines of a technology do not easily lend themselves to simplistic ("black and white") interpretations. There may be many possible answers to a single problem, and the identification of a specific acceptable set of solutions will change depending on the particular constraints you put on the problem. 2) A consequence of the above is that education may require certain skills and aptitudes that are not necessary for training. For example, while training might be appropriate for an electronics technician, education is what is required for an electronics engineer (here, an electronics engineer is taken to mean someone with at least a bachelors degree in electronics engineering). 3) A one-word definition for learning is: change. Both education and training require change. Often this change is not limited to the mental state of the individual being educated or trained, but also extends to the working environment of that individual. 4) Two very different paths are taken with the activities associated with training and education. Since training is appropriate for situations requiring little original human thought or judgment, the activities for which a human is trained can often be easily automated. (Consider, for example, the training of a welder on an assembly line, and the eventual replacement of that welder by robots.) Activities requiring education, on the other hand, usually involve many constantly varying pieces of information. The tools, techniques, and methods used to handle situations for which education is appropriate, may themselves be quite complex. (Consider, for example the use of mathematics to calculate the dynamics of the liquid fuel in a rocket during take-off.) Typically, situations requiring education lend themselves to being assisted by, but not replaced by, automation. There are many players in the dynamics of Ada technology education. In the case of U.S. Department of Defense (DoD) related efforts, the player farthest removed from the actual engineering of the Ada software is the customer, i.e., the DoD. These people must be educated to the point where they realize that training is NOT appropriate for Ada technology, but that education is required. Many of us have been denying the truth for years. We may have felt that software production and maintenance required training, not education. This is not true. In fact, we should have been educating our technical and managerial personnel in software engineering technology all along. The DoD's Ada effort is the collection agent, and it is here to collect all our past due software engineering education. This is what makes Ada technology education so difficult. Ada educators must not only teach the syntax and semantics of Ada, but they must also educate their students in software engineering technology. Closer to home, we have the management of the organization requiring the Ada technology education. Management must understand that they must help and encourage Ada technology education. They must provide the tools and people necessary for good Ada technology education. They must let the people they manage know that they take software seriously. It is management which can make or break an Ada technology education effort. Two contrasting examples are necessary here. At Magnavox in Ft. Wayne, Indiana, Management was seriously committed to the concept of Ada technology education: - Management required themselves to go through the same training that they put their technical staff through. This began to make them aware of what their technical could expect, and gave management a chance to ask questions in context. - Management had themselves trained first. This gave them the lead time to begin preparing themselves and their staff for the changes which were to come. - Training was from 7:30 A.M. to 4:30 P.M. every day with one-half hour off for lunch. The class participants were already working on their labs when the instructor arrived, and continued to work after the instructor left for the day. - No one was allowed to disturb the class. Unless it was a truly life- and-death matter, the best that anyone could do was to place a note on the classroom door if they wanted to get the attention of a class participant. - Management made sure that tools (e.g., an Ada compiler) were procured as early as possible, and that all that needed to, had access to the tools. Another organization (unfortunately, a well-known name in the Ada business) had management which did about everything they could do to prevent Ada education from happening: - They delayed any kind of Ada technology education until shortly before the coding was to start on the project. - They did not allow their technical staff to participate in classroom activities on a regular basis. The number of students in the class room varied from zero to about seven. (That's right, one day the instructor showed up, and there were no students in the class for most of the day.) - Management themselves kept well away from the classroom. - During the first course which required the use of an Ada compiler, the labs were delayed because the compiler was not even installed until the middle of the week. Even when the compiler was installed, it was installed so badly that it was all but unusable. In summary, management can either aid the dynamics of Ada technology education, or ensure the failure of Ada technology transfer. Inside the classroom, we have another set of dynamics, specifically the relationship between the instructor and the students. A good instructor knows that "education is a two-way street." The instructor must listen to the students and be sensitive to their needs. The instructor must make reasonable attempts to reach most, if not all of the people in the class. In industry (as opposed to academia), at least fifty percent of an instructor's job is leadership. An instructor must both listen to and understand the needs of the people he or she is charged with educating. However, it is the instructor who must motivate and lead the class. This is especially crucial in the case of Ada technology education. Many students arrive at their first Ada class fully expecting a syntax course. It takes work and a good deal of persuasion to foster a desire for software engineering as opposed to just learning the syntax of "just another language." Some Ada instructors are bullied by their students into providing a syntax- only course. (I remember advising one of these instructors to "get up early on Sunday morning and watch some of the TV evangelists for inspiration.") Just getting into the classroom can be a challenge. The perspective instructor must successfully persuade management that software engineering is a good thing, and is more important than Ada syntax. The instructor must not insult the intelligence of his or her students. Students are fully capable of learning about software engineering on the very first day of instruction. The belief that students must know code syntax before software engineering will make any sense is just plain wrong. Software engineering instructors have two things going for them. First, software professionals are very "goal oriented." Once proper goals are set perspective software engineers will strive for them. Second, most software engineers want to to the best job they possible can. Showing how each piece of software engineering technology aids in achieving this goal helps the Ada technology instructor get the job done. If, however, the instructor does not have a firm grasp of software engineering technology, he or she cannot hope to convey the technology to the students. Merely saying the words "abstraction" and "information hiding" a few times does not merit being called a software engineering approach. Software engineering is an enormous discipline encompassing methodologies, metrics, mathematics, computer science, engineering disciplines, analytical and logical thinking, communication skills, and other factors. The classroom dynamics I have just described also work in academia. Having taught in college classrooms for regular college courses myself, I can attest that from the first day in their freshmen classes, college students are fully capable of understanding engineering disciplines. Consider the freshman who is an electronics engineering student. He or she may have entered college thinking that electronics engineering was little more than "building Heath kits." However, engineering students soon find themselves in classes on complex analysis, differential equations, physics, chemistry, statics, dynamics, strength of materials, English, history, and other disciplines. The same kind of thinking holds for software engineering students. They may enter a university thinking that software engineering is "glorified hacking," but they are just as capable as the electronics engineering student of learning the full discipline, not just the least significant part (i.e., coding). -- Ed Berard (301) 695-6960 ============================================================================== I. F. Comments on Parts 1-4 Date: Mon 18 May 87 08:33:24-PST From: CONTR47@NOSC-TECR.ARPA Subject: Thoughts provoked by Ed Berard's articles I always enjoy reading Ed Berard's articles because they are very thought provoking. I usually agree with his observations and usually disagree with his conclusions and recommendations. The recent 4 part discourse is not unusual in that respect. While reading I mentally composed pages of response and wondered which responses, if any would be worthy of net resources. Then I received a paper from the SEI by Watts S. Humphrey titled "Software Process Management" which contains a concluding thought that seems to sum up my possible responses to Ed's articles. "There is a definition of insanity that applies to software development. It is said that insane persons believe they can continue doing the same thing over and over and get different results". Upon reading that I realized that I have been insane most of my career. I was insane when I expected engineers and managers to immediately see the advantage of transistors over vacumn tubes. I was insane when I expected them to see the advantage of computers over analog control. I was insane when I expected them to see the advantage of Ada over Fortran until I said to myself "Self- That's enough- Only deal with people who have already accepted that there is an advantage and want help realizing the advantage." This happened about the same time I started my own company and became interested in profit. i.e.: There isn't much profit in missionary work. I have a placard that says "Never try to teach a pig to sing: It will waste your time and it annoys the pig." I believe that Ed is attempting to teach pigs to sing as I have often done. It is a form of insanity according to Humphrey. It takes 14 or so years for a new technology to be widely used in practice according to SEI (from my memory) and I think it will be so for modern software engineering/Ada and there isn't much Ed or I can do about it. Hopefully the SEI can do something about it through the software engineering curriculum design. So Ed, my reaction to your discourse is to not criticize anyone for not immedialtely seeing the advantages of Ada, work with the ones who ask for help. The 14 years will pass quickly and you'll be working on the next new technology by then. regards, sam harbaugh --------------------------------------------------------------------------- Date: Tue, 19 May 87 23:32 CDT From: "Pat Rogers, High Tech Lab" Subject: Software Engineering education, etc Of all people, I think Niccolo Machiavelli said it best: Nothing is more difficult to carry out, nor more doubtful of success, nor more dangerous to handle, than to initiate a new order of things. For the reformer has enemies in all those who profit by the old order, and only lukewarm defenders in all those who would profit by the new order, this luke- warmness arising partly from ... the incredulity of mankind, who do not truly believe in anything new until they have had actual experience in it. (The Prince) While Sam is correct in saying that missionaries do not usually turn a profit (recent televangelists notwithstanding), the missionary's position, if you'll pardon the pun, is that preaching to the choir is a lot easier but doesn't address the audience most in need. This is actually a worthwhile attitude, when one considers the importance of some of the projects now or soon-to-be underway. More than a few people I've run across sound like the people with which Machiavelli tangled, back in the early 1500's. (We can only assume that they are not the same people.) In all seriousness, I don't always agree with the things I read about Software Engineering education either, but it is important work, and is worthy of our support. Regards, Pat Rogers PRogers@Ada20 .pa ============================================================================ II. The Human Element in Software Engineering Date: 19 May 1987 04:31:13 PDT Subject: The Human Element in Software Engineering From: Edward V. Berard There is a good deal of wisdom in Sam Harbaugh's response to my recent four- part article on Ada Education and Training. I especially agree with his citing of the old adage: "Never try to teach a pig to sing: it will waste your time and it annoys the pig." In fact, another old saying: "Neither cast ye your pearls before swine." (Matthew 7:6) also came to mind regarding the natural human tendency to reject new technology. Technologists, in general, very often ignore the human element in technology. Many erroneously believe that it is technology that advances technology, when, in fact, it is economics, politics, and sociology which are the main causes of technological change. Nowhere is the attempt to remove human considerations from technology so blatant as it is in the state-of-the-practice of software engineering. Consider the following: 1) Although people such as Barry Boehm have been telling us for years that the greatest improvements in technology will occur when we improve the capabilities of the humans involved in the process (See the front cover of Barry's book, "Software Engineering Economics."), we continually ignore this advice. It seems we much more comfortable creating new automated tools than we are with measuring and improving the capabilities of the humans who will be using the tools. 2) Sociologists tell us that while bringing a group of people one generation ahead in technology is difficult, bringing a group of people ahead two generations of technology is all but impossible. In the area of software engineering, the state-of-the-practice is easily two or more generations behind the state-of-the-art. This leads to some interesting results. For example, while we currently possess the technology to increase our software engineering productivity by at least an order of magnitude, we cannot expect people to begin using this technology on a large scale for at least a decade. (Yes, Sam, I do agree with your observation.) 3) New technology is seldom what people expect it to be. I used to give a seminar on "Measuring and Improving Programmer Productivity." This seminar was attended chiefly by managers who expected me to tell them how to make their programmers code faster in the programming language of their choice. When they heard that the largest gains in productivity required such items as a shift to fourth-generation languages, off-the-shelf software, and smaller technical staffs, the managers often refused to accept the facts, *even when presented with documented evidence supporting the facts.* 4) Even when people claim that they are ready to accept new technology, or even to enthusiastically pursue new types of technology, they often spend enormous amounts of resources (in most cases, the majority of their resources) "re-inventing or re-discovering the wheel." The concept of a simple literature search is beyond most of the people in the software business today. Even those who are capable of even feeble scanning of the technical literature are ill- equipped to understand, much less accurately interpret, what they find. Recently, someone from one of the more prestigious centers of software engineering technology transfer called to ask me about a methodology. This person was part of a group which was researching software development methodologies. This person was shocked when I told him that the work he was charged with had been done at least six times before. Indeed, in addition to numerous government sponsored reports available on the topic, five or six IEEE tutorials, at least three hardback books, numerous foreign government studies, and several publicly available industry and academic studies, there is at least one public seminar on the topic he was researching. 5) Technical people seem very uncomfortable with concepts of ethics, morals, and responsibility. For example, few software engineering courses discuss the ethical implications of a managerial or technical decision. Although there are quite a number of courses and seminars about software law, most deal with the protection of copyrights -- as opposed to the legal responsibilities of the author of the software if reasonable use of the software results in damage to the user. As I have stated before, most people are more comfortable talking about technological change than doing anything about it. As a consultant, I am often asked to pose solutions to any number of software engineering problems. It is a sad fact that most of the people who pose the problems to me are "insane." (Insane by W.S. Humphrey's definition: "There is a definition of insanity that applies to software development. It is said that insane persons believe they can continue doing the same thing over and over and get different results.") They do not want to hear the best, or even a correct, answer. They want to hear more of the same. Sam is also right on another point. The financial rewards of being on the leading edge of technology are meager at best. It is little comfort to realize two years later that you did indeed accurately predict the technological future, but will have to wait another two years to take economic advantage of your prediction. In Greek mythology, a woman named Casandra was cursed by the gods. She was given the power to accurately predict the future. However, the gods made sure that no one would believe her predictions. There is, however, another view. Without people motivating and cajoling the technical population, there would be little work for people like Sam. So, in the future, I will continue in my attempts to "teach pigs to sing." I guess what motivates me is that I have had some success with changing pigs into quasi-rational human beings. (Another of the ancient Greeks, Homer, told us about Circe, a sorceress who turned men into animals. You might say that I am attempting to "reverse the curse.") -- Ed Berard (301) 695-6960 .pa =========================================================================== III. A. The DoD and Software Reuse - Part 5 Date: 15 Jun 1987 03:13:47 PDT Subject: DoD and Software Reuse - Part 5 From: Edward V. Berard Recently, I have had a number of conversations with DoD contractors regarding software reuse. While they all refuse to have their names used, they were very honest with me about their opinions on the future of software reuse within the DoD. Some points you might find interesting are: 1. Software reuse is something which is virtually meaningless to the highest levels of management in most organizations doing business with the U.S. Department of Defense (DoD). When these high-level managers are told about software reuse, they have one primary question: "How does it affect the bottom line?" In other words, is this a concept which will make the company more money? Given the current state of affairs, the answer is "no." 2. One of the reasons that the answer is currently "no," is cost-plus- fixed-fee (CPFF) contracting practices. Specifically, the more people put on a project, the more money a contractor makes. Making reuse of software actually costs the company money. Fixed price contracts, as they currently exist, are not an obvious inducement to reuse software because, as more than one contractor told me, "once we get a fixed price contract, we can always get the government to give us additional money." 3. At a briefing for contractors, an Army general said that "Ada appeared to be "taking off" in the commercial (non-military) sector." "One of the reasons for this," the general continued, "was because of the software reusability benefits that Ada provides. We think that our contractors will also see these same benefits and begin to make software reuse the normal practice." Some of the contractors at the briefing felt that the general was very naive about the ways of government contracting to make such a statement. So what can we learn from the above? The first thing we must realize is that organizations which develop software are run by people whose primary interest is profit. "Ignoring the concepts of ethics and morality," one contractor told me, "it does not seem to be currently in the best interests of a contractor to develop the most cost effective solution for any government software contract." We must also recognize that the commercial sector and the government software sector are two very different animals. In the commercial sector, a developer often pays all the costs for product development, hoping to more than recoup these costs based on sales of the product. With this type of scenario, software reuse makes a great deal of sense, i.e., the lower the development costs, the lower the risks and the greater the potential profit. On the government side, the software developer has little risk. The software developer is being paid to develop a product, not to sell it. The greater the development costs, the more money the contractor makes. If the product fails, or is never completed, the only one who loses is the government. (To add insult to injury, many contractors take the technology they have developed under government contract and turn it into viable commercial products.) "In order for software reusability to take hold in government contracting organizations," another contractor told me, "it must be made meaningful to the highest levels of contractor management." If they are aware of it, software reusability is often only a phrase to the upper levels of contractor management. Since it is the highest levels of management who can most effectively make software reusability a reality, the government must seek ways to make software reusability "real" (and profitable) to these people. -- Ed Berard (301) 695-6960 .pa --------------------------------------------------------------------------- III. B. Comments on Part 5 Date: Mon 15 Jun 87 17:55:19-PST From: CONTR47@NOSC-TECR.ARPA Subject: comments on Ed Berard's S/W reuse part 5 1. I believe that the contractors skill at S/W reuse will provide him the most advantage at bid time. The Government is *very* considerate of price when awarding contracts. The contractors who are most skilled at reuse will win the most contracts while those who bid all new code in order to collect the higher fees will suffer. 2. My experience at a large DoD contractor was contrary to what is being told to Ed. It was *very* difficult to get add-on money to either CPFF or FFP contracts unless the Government was clearly getting additional value for the money. I have heard extreme examples of rip-offs during the Vietnam war but all the time I worked there it was not under war emergency conditions and the Government was a *tough* customer. 3. My personal opinion is to question the data being told to Ed by "management". My experience has been that administrative management doesn't always know what is going on; The program manager does but he wouldn't tell so unless you have some clout (like work for the Defense Contract Audit Agency) you are not going to know "the facts". The work I recently did on Ada cost modelling showed us that very few people really knew what was going on. Only by careful recall on the part of the development manager could he remember why certain costs were unusual values. It was the unusual values that caused him to recall that reuse played an *important* part in S/W actual costs. Since we have now come full circle back to the value of reuse I'll sign-off. regards, Sam Harbaugh -------------------------------------------------------------------------- Date: 16 Jun 1987 02:17:55 PDT Subject: Putting Software Reuse in the RFP From: Edward V. Berard I have had some interesting responses to my most recent posting on reusability. Some are along the lines of "you are belaboring the obvious." Others are similar to the response that Sam Harbaugh provided, i.e., "your 'facts' are not on target." What this mixture of responses seems to demonstrate is the confusion over the "real" impact of software reuse on government procurements. One point that is worth mentioning is that lower price alone is not an indicator of software reuse. The government needs to know what they are getting for their money. For example, one could bid a lower price by limiting the scope of the delivered product, underestimating the actual costs, or "buying" a contract (purposely bidding less than what you know what the true cost of the contract will be, most often for some future profit motive). One approach that some government agencies have begun to use is to make software reuse highly visible in the original RFP (Request For Proposal). For example, bidders are required to provide some estimate of the size of the delivered software -- typically in "lines of code." In addition, the bidders must provide an estimate of how much reusable software will be incorporated into the delivered product, and they must also describe how this "reused software" will impact the cost, quality, etc. of the product. Given this, and other, information, the requester can begin to get a better understanding of what the different bidders are proposing. Suppose one bidder estimates the size of project at "50,000 lines of code," while another estimates the size to be "100,000 lines of code." There could be many reasons for the difference, but it will be likely that the bidder with fewer lines of code will submit a lower bid. If, however, two, or more, bidders provide similar estimates as to the size and scope of the delivered product, a more accurate picture of the impact of software reuse is possible. Everything else being equal (Yes, I know, it seldom is.), the bidder who plans to incorporate significantly more reusable software into the delivered product should be able to submit the lower bid. One government agency told me that they recently acquired an Ada application which was about 100,000 "lines of code" in size with an expended effort of "significantly less than a man-year." This was possible because of the heavy reuse of software on the project. (One very large company I talked with, told me that they might "optimistically" bid this same contract at "20 man-years" of effort.) -- Ed Berard (301) 695 - 6960 --------------------------------------------------------------------------- Date: Tue, 16 Jun 87 11:14 EDT From: Pete Schilling <"VAXTSD::SCHILLING1%atc.alcoa.com"@RELAY.CS.NET> Subject: Software Reuse This may seem incredibly naive to those who have long experience in the Defense contracting game, but it deserves saying anyway: If the benefits of software reuse are real, then -- - A product that makes significant reuse of software should be ready sooner than one that represents all new code. - Saying than another way, a product that makes significant reuse of software could be started later in the system development cycle. - The reliability of a product that makes significant reuse of software should be higher that an equivalent product that represents all new code. - Other quality characteristics of a product that makes significant reuse of software should be much more predictable than one that represents all new code. - The maintenance cost of the product that makes significant reuse of software should be lower. If all of the above is really true, then the customer should be willing to pay MORE for a product that makes significant reuse of software than for one that represents all new code. Pete Schilling CSNET: SCHILLING@ATC.ALCOA.COM Technical Specialist PHONE: 412/337-2724 Process Control and PAPER MAIL: Aluminum Co. of America Computer Technology Divn. Alcoa Center, PA 15069 Alcoa Laboratories USA --------------------------------------------------------------------------- Date: Wed, 17 Jun 87 07:43:22 EDT From: schimsky@nadc.arpa (D. Schimsky) Subject: Re: Software Reuse As a "Government" manager of major software developments, let me offer that most of comments I've seen here relative to "re-use" appear academic. 1. No, I would NOT pay more for a product that takes advantage of re-use, since virtually my entire concern is to LOWER the price of software development. There is no way, short of pushing my nose in it, that I will believe a paper analysis showing me how much I will save tomorrow if only I give you more today. 2. Short of absolute mandate (translate to "I order you to...") the detailed methods employed in the development of software are made on a very local level by the people first in line for the responsibilty. These are the Project Engineers, or Program Officers, or some equivalent title. I believe I know what their opinion is concerning re-use, but it would be interesting to hear them speak. 3. By what magic do you expect an organization as large and diverse and, sometimes, divergent, to adopt a methodology that begs for standardization, cooperation, flexibility and a non-parochial attitude, when you would do well to find one, small, isolated group, anywhere, doing the same? ---------------------------------------------------------------------------- Subject: Re: Software Reuse Date: Thu, 18 Jun 87 12:55:43 EDT From: Bob Munck I don't know if I've ever seem a more straightforward explanation of the DoD's Software Crises than this: > As a "Government" manager of major software developments, ... There > is no way, short of pushing my nose in it, that I will believe a > paper analysis showing me how much _I_ will save tomorrow if only I > give you more today. Remember that the _I_ (underlining mine) is really "the poor slob who'll be maintaining this system years after I get a job in Industry." Remember too, that EVERYBODY'S project is too important (major) to take the risk of being the first to use any new technique. Of course, with FORTRAN, JOVIAL, CMS-2, and/or the Chinese Army approach to programming, there's no risk. We KNOW that it will be late, over budget, and buggy. No surprises, no risks. -- Bob Munck, MITRE .pa ---------------------------------------------------------------------------- Date: 18 Jun 87 08:46:36 GMT From: mcvax!ukc!dcl-cs!craig@seismo.css.gov (Craig Wylie) Organization: Department of Computing at Lancaster University, UK. Subject: Software Reuse -- do we really know what it is ? There have been a couple of articles recently on Software Reuse and its likely acceptance by Defence Contractors. In considering Software Reuse in general, not just with reference to Ada and DoD, do we know what it is? The scale of software that Ada allows the programmer to reuse seems to be primarily that of the package (in Modula-2 the Module). Is this sufficient? If we leave aside for the time being the question of whether Ada is an object oriented language and accept that if it isn't then you can do a reasonably good job faking it, reuse in Ada seems to be stuck at the level of the Abstract data type. Furthermore the lack of any easy (or apparent) way to derive WHAT an Ada program is doing rather than HOW it is doing it, does put a large amount of the responsibility for recovering reusable components on the programmer. In summary I would like to offer a few statements for discussion to see if we can clarify reuse. 1. We don't really know what it is. 2. It probably isn't a thing at all, but rather a collection of things depending on the scale at which the reuse is to take place. 3. Languages such as Ada and Modula-2, and imperative languages in general are unsuitable for writing reusable software because of their concentration on the HOW rather than the WHAT. 4. Reuse of Design isn't considered at all by any current applications language. 5. Nobody can force programmers to write good reusable code. 6. Even if they do write reusable code how the **** do we ever find it again so that we can reuse it ? All responses appreciated. Craig. UUCP: ...!seismo!mcvax!ukc!dcl-cs!craig| Post: University of Lancaster, DARPA: craig%lancs.comp@ucl-cs | Department of Computing, JANET: craig@uk.ac.lancs.comp | Bailrigg, Lancaster, UK. Phone: +44 524 65201 Ext. 4476 | LA1 4YR --------------------------------------------------------------------------- Date: Sat 20 Jun 87 12:27:45-PST From: CONTR47@NOSC-TECR.ARPA Subject: reuse - suggestion to include usage history in metrics You don't write reusable code, you write useable code, use it, then it becomes reusable. The reason I make such a statement is to set the stage for making the suggestion that reuseable code's useage history is an important attribute and one which I would like to see the reuseabilty research people include in their reusability metrics. For examples just think of selecting a spreadsheet, etc., to reuse (buy at the software store). I suspect that most software being touted as reuseable today ( at Simtel20 repository for instance) is not reuseable because it hasn't been used for the first time. regards, sam harbaugh --------------------------------------------------------------------------- Date: 22 Jun 1987 04:00:27 PDT Subject: Software Reuse -- We Know More Than You Think From: Edward V. Berard This is response to an honest question by Craig Wylie. Wylie asks a series of general questions about software reuse. He has also inadvertently tripped over one of my pet peeves. Let me quietly explain, and then I will get on with my answer to his questions. ******************** Personal tirade -- Can be ignored ************ We often ignore the technical nature of software engineering. By that I mean that we assume there is little to software engineering other than writing code and opinion. Concepts which are accepted as normal practice in other technical disciplines (e.g., literature searches, the application of mathematical and engineering disciplines, and quantitative metrics) are not yet accepted by the masses as being relevant for software engineering. Take the issue of software reuse. Ignoring any work in this area prior to Doug McIlroy's article at the 1968 NATO Conference on Software Engineering, software reusability has a history of almost two decades of research and implementation. This research and implementation knows no geographical or political bounds. For example, the Japanese have an organization called SIGMA to deal with software reuse. The IEEE has recently published and entire tutorial on software reuse. A number of recent issues of IEEE Software have carried articles on software reuse. Two entire issues of the IEEE Transactions on Software Engineering were devoted to software reusability. Even a feeble search of the software engineering literature would turn up hundreds of articles on the topic. (The quality of these articles ranges from dismal to excellent.) Many of these articles offer definitions, metrics, taxonomies, and reusability systems. Some of the items which we now know about software reusability are: - Much more than source code can be reused. In fact, designs, plans, test data, and documentation (among others) can be reused. The smallest gains in productivity, reliability, etc., are obtained by only reusing source code. Reusing the documentation associated with "reusable source code" greatly enhances any gains associated with merely reusing the source code. - Reusability is not a concept that is limited to the coding phase of the software life-cycle. It must be a highly visible item from requirements analysis to the retirement of the product. - Research seems to indicate, and practice seems to show, that the majority of many software products can be assembled from reusable components. - There are any number of metrics associated with software reuse. They include metrics which measure the sheer bulk of source code and documentation reused in an application, to metrics which measure the affects of software reusability, e.g., software productivity metrics. My image of the current state-of-the-practice in software engineering is one of a series of blind and deaf individuals surrounded by massive amounts of software engineering technology. All too often when some of this technology is brought to the attention of one of these "handicapped" individuals, it is dismissed as "buzzwords," "academic," "theoretical," or "mere opinion." *********************** End of tirade ******************************* Wylie asks if we know what software reuse is. There are two answers to this question. The vast majority of today's software practitioners either do not know what it is, or assume that it is "yet another buzzword." There is a small minority of individuals and organizations who are researching and implementing various aspects of software reuse. [I am reminded of the anecdote about the monks in their abbies who preserved the knowledge of mankind during the dark ages while "the winds of ignorance howled outside."] No, Ada's package concept is not enough. Grady Booch has been pointing out for years that some higher level concept (e.g., Rational's subsystems) is necessary. By the way, virtually all existing programming languages (with the exception of some very high-level fourth-generation languages) lack attributes which make them directly applicable to programming-in-the-large. Reuse in Ada is not "stuck at the level of the abstract data type." However, few software engineers know how to go beyond this concept (in any language). There are a number of ways to derive the "what" from a piece of Ada software, and to divorce this from the "how." The mechanisms for doing this range from crude (e.g., include the "what" in the comments), to innovative (e.g., consider David Luckham's ANNA). Further, the recovery of reusable components can be handled in a number of ways: - level 0: the use of a hierarchical file system - level 1: the use of a relational DBMS (data base management system) or a hypertext system - level 2: the use of an expert system or some other artificial intelligence tool - level 3: incorporation of reusable components in an application generator (a type of fourth-generation language) These approaches have also been modified to include such things as documentation, test data, designs, and plans as well as source code. Software reusability technology is indeed a collection of things. These things include reusable components, taxonomies, reusability systems, composition concepts, methodologies, and others. This technology is more coupled with the size of the software product than it is with "the scale at which the reuse is to take place." The issue of language suitability for reuse is an interesting one. Stating that imperative languages are unsuitable for reuse shows a lack of understanding of software reuse technology. (But then again, I have heard any number of Ada people make similar misstatements about languages such as LISP and most fourth-generation languages.) One might re-phrase the observation by stating that the mere use of the Ada language does not guarantee reuse. The language must be accompanied by software reuse technology (e.g., tools and methodologies). One item which seems to have escaped the understanding of many in the Ada community is that one of the primary motivations behind the Ada language is "to build tools to build tools." Ada was designed with the intention that it be used as a bootstrap. Specifically, it is to be used to create libraries of reusable components (the first "tools"). These reusable components are to be used to create fourth-generation languages and "software factories" (the second "tools"). Using the Ada language as if it were Pascal, C, FORTRAN, COBOL, or assembly language is tantamount to abuse. Software design methodologies do play an important part in software reuse. Some methodologies enhance software reuse, others discourage it. We have known for some time that software designs should be constructed so that they can easily be modified. We are only now beginning to understand that by bringing software reusability issues to the first phases of the software life-cycle, we can greatly enhance the impact of software reusability. Finally, by studying the designs of many systems within a particular application domain we are finding designs are very much reusable, e.g., consider the basis for many fourth-generation languages. Nobody can force programmers to write good reusable code. However, programmers, as a whole, want to do a good job and are very goal-oriented. Getting programmers to write good reusable code is in part a motivating and educational process. Finally, in addition to the technical problems which must be addressed, we have to consider many other connected issues. Political, managerial, legal, cultural, financial, marketing, and productization issues must also be considered. -- Ed Berard (301) 695-6960 --------------------------------------------------------------------------- Date: 22 Jun 87 18:59:41 GMT From: crowl@cs.rochester.edu (Lawrence Crowl) Organization: U of Rochester, CS Dept, Rochester, NY Subject: Re: Software Reuse -- do we really know what it is ? In article <4658@utah-cs.UUCP> shebs@utah-cs.UUCP (Stanley Shebs) writes: ]... software people fume and gnash their teeth over "wasted space". ... All ]the techniques for modules, objects, etc, tend to slow things down. Again, ]software types tear their hair out and vow to recode everything into one ]assembly language procedure. Worse, other software types admire them for ]doing so! ... ] ]In article <374@sol.ARPA> crowl@rochester.UUCP (Lawrence Crowl) writes: >>In article <371@dcl-csvax.comp.lancs.ac.uk> >>craig@comp.lancs.ac.uk (Craig Wylie) writes: )))3. Languages such as Ada and Modula-2, and imperative languages in ))) general are unsuitable for writing reusable software because of ))) their concentration on the HOW rather than the WHAT. >> >>Clearly, we need more concentration on WHAT, but we should not abandon the ] ^^^^^^^^^^^^^^^^^^^^^^^^^ >>efficiency of HOW. ] ^^^^^^^^^^ ] ]QED! Let me clarify my position. I can specify a sort as a set of predicates and let the system figure out how to satisfy those predicates. This is the WHAT approach used in languages such as Prolog. Another approach is to write a algorithm for sorting, e.g. quicksort. This is the HOW approach used in languages such as Ada. Yes, the packaging of the sort will result in some loss of efficiency. However, it will be substantially faster than the WHAT approach. I am advocating an approach in which a package interface describes WHAT and the implementation of the package describes HOW. Because I wish to keep the macro-efficiency of algorithmic languages, do not accuse me of wishing to keep the micro-efficiency of hand-tuned assembler. ]3. In general, hardware types have standards for every imaginable sort of ]interface, and they stick to them remarkably well. You can plug boards into ]a standard bus with only a small chance of sparks flying everywhere as the ]boards fry. In software, standards are strictly for lip service to managers; ]only a novice would consider combining programs from several different ]sources without planning a few hours or days of debugging! Programmers to this sort of program combination many times a day in the Unix shell. There ARE approaches to software reuse that CAN work. We need to provide this kind of capability within a language. ]In short, I believe there are no technical problems or issues with reuse; ]it's the software culture that has to change. At present, the prevailing ]attitude is that the densely-coded, highly-optimized, do-everything program ]is a sort of ideal to which everyone aspires. Until this attitude changes, ]software reusability will continue to be a bad joke among those who actually ]write programs. There are technical problems. For instance, how do you insure that the parameters to a generic package are appropriate. Performance will always be a goal. However, it must be balanced against cost. Most programming done today is in a high-level language. In the early sixties, most programming was done in assembler. So, the software attitude has changed. Modular code also allows changes in representation that can lead to orders of magnitude performance improvements. Non-modular code strongly inhibits such representational changes. In short, the micro-efficiency of non-modular code leads to the macro-INefficiency of poor algorithms and representations. )))5. Nobody can force programmers to write good reusable code. >> >>True. But no one need buy code that is not both good and reusable. I >>believe there is a market for such code. ] ]Manufacturers seem to think their interest is in maintaining secrecy of code. Again, let me clarify. I meant that the reusable software would be written by software houses and sold to companies which write applications. For instance, Reusable Software Inc. sells a sort package to Farm Software Inc. which uses it in its combine scheduling program. Farm Software Inc. need not divulge its algorithms or its use of packages written by Reusable Software Inc. ]Customers only care about speed and features. Read Infoworld and see if they ]ever say anything positive about a program that is slower but more modular. You forgot cost. Modular code will cost substantially less in the long run. Lawrence Crowl 716-275-5766 University of Rochester crowl@rochester.arpa Computer Science Department ...!{allegra,decvax,seismo}!rochester!crowl Rochester, New York, 14627 ---------------------------------------------------------------------------- Date: 22 Jun 87 15:40:19 GMT From: shebs@cs.utah.edu (Stanley Shebs) Organization: PASS Research Group Subject: Re: Software Reuse -- do we really know what it is ? In article <374@sol.ARPA> crowl@rochester.UUCP (Lawrence Crowl) writes: >In article <371@dcl-csvax.comp.lancs.ac.uk> >craig@comp.lancs.ac.uk (Craig Wylie) writes: >>1. We don't really know what it is. > >Well, I find a glimering of re-use in reading Knuth's books. I will point at >an analogy though. Board level designers constantly use circuits designed by >others. They are packaged in integrated circuits. An interesting analogy. It says a lot about prevailing software culture: 1. Available chips do not always meet requirements exactly. For instance, a board might need 3 NAND gates, but the 7400 has 4. EEs just ignore the extra gate, or tie its pins to something stable. In a similar situation, software people fume and gnash their teeth over "wasted space". 2. Running wires around boards loses some performance, relative to cramming everything onto a single chip. All the techniques for modules, objects, etc, tend to slow things down. Again, software types tear their hair out and vow to recode everything into one assembly language procedure. Worse, other software types admire them for doing so! Come to think of it, the advent of VLSI tools promotes the same idea for hardware, and we're seeing lots of specialized chips these days... >>3. Languages such as Ada and Modula-2, and imperative languages in >> general are unsuitable for writing reusable software because of >> their concentration on the HOW rather than the WHAT. > >Clearly, we need more concentration on WHAT, but we should not abandon the ^^^^^^^^^^^^^^^^^^^^^^^^^ >efficiency of HOW. ^^^^^^^^^^ QED! 3. In general, hardware types have standards for every imaginable sort of interface, and they stick to them remarkably well. You can plug boards into a standard bus with only a small chance of sparks flying everywhere as the boards fry. In software, standards are strictly for lip service to managers; only a novice would consider combining programs from several different sources without planning a few hours or days of debugging! In short, I believe there are no technical problems or issues with reuse; it's the software culture that has to change. At present, the prevailing attitude is that the densely-coded, highly-optimized, do-everything program is a sort of ideal to which everyone aspires. Until this attitude changes, software reusability will continue to be a bad joke among those who actually write programs. >>5. Nobody can force programmers to write good reusable code. > >True. But no one need buy code that is not both good and reusable. I believe >there is a market for such code. Manufacturers seem to think their interest is in maintaining secrecy of code. Customers only care about speed and features. Read Infoworld and see if they ever say anything positive about a program that is slower but more modular. > Lawrence Crowl 716-275-5766 University of Rochester stan shebs shebs@cs.utah.edu .pa ---------------------------------------------------------------------------- Date: 23 Jun 87 17:28:26 GMT From: shebs@cs.utah.edu (Stanley Shebs) Organization: PASS Research Group Subject: Re: Software Reuse -- do we really know what it is ? In article <378@sol.ARPA> crowl@rochester.UUCP (Lawrence Crowl) writes: >>>Clearly, we need more concentration on WHAT, but we should not abandon the >] ^^^^^^^^^^^^^^^^^^^^^^^^^ >>>efficiency of HOW. >] ^^^^^^^^^^ >] >]QED! > >Let me clarify my position. I can specify a sort as a set of predicates and >let the system figure out how to satisfy those predicates. This is the WHAT >approach used in languages such as Prolog. Another approach is to write a >algorithm for sorting, e.g. quicksort. This is the HOW approach used in >languages such as Ada. Yes, the packaging of the sort will result in some >loss of efficiency. However, it will be substantially faster than the WHAT >approach. I am advocating an approach in which a package interface describes >WHAT and the implementation of the package describes HOW. > >Because I wish to keep the macro-efficiency of algorithmic languages, do not >accuse me of wishing to keep the micro-efficiency of hand-tuned assembler. I wasn't accusing anybody of anything, just pointing out that like any other culture, the software culture is very pervasive and people in it (us) don't always recognize when we're behaving according to those cultural norms. For instance, if I were to post some inefficient sort to the net, there are maybe ten computer people in the world who could look at it and not get at least a twinge of "Gee, why not use a better algorithm?" As I said, it's part of the culture. Not completely bad, but frequently dominates our thinking. Your typical serious C hacker will get unhappy about the overhead of a function call, let alone the extra functions involved in "packaging"! After several years of extensive Lisp hacking, I've managed to overcome resistance to defining lots of little data abstraction functions, and only feel guilty once in a while :-). An additional obstacle to using the "packaging" is that in the past, some systems (such as Simula and Smalltalk) were orders-of- magnitude slower than procedural languages, and there is perhaps a lingering perception that data abstraction costs a lot in performance. Requiring both WHAT and HOW is a pretty controversial thing to do. The biggest problem to me is the potential for inconsistency, since many things will be stated twice, but in different terms. That's the rationale for making the computer figure out the HOW itself, but that is an elusive and perhaps unreachable goal. (Doesn't stop me from trying though!) >Programmers [do] this sort of program combination many times a day in the Unix >shell. There ARE approaches to software reuse that CAN work. We need to >provide this kind of capability within a language. Unix is a counterexample, that's why I didn't mention it :-). A closer look is worthwhile. Unix tools offer basically one interface - a stream of bytes. More complicated interfaces, such as words, nroff commands, or source code, are less well supported; it's unusual to be able to pass C source through many filters in the way that data files can be passed. Also, at least in the groups of Unix users I've observed, pipes and filtering sequences longer than about 3 stages are relatively uncommon, and are about as difficult for many people to compose as a C program. Of course, my sample is not scientific, and I'm sure there are lots of Unix hacks that will be glad to tell me all about their 15-stage pipe processes! What other *working* approaches are there? >There are technical problems. For instance, how do you insure that the >parameters to a generic package are appropriate. Use something higher-level than Ada? This seems like an issue only for some languages, not a major obstacle to reuse. >Performance will always be a goal. However, it must be balanced against cost. >Most programming done today is in a high-level language. In the early sixties, >most programming was done in assembler. So, the software attitude has changed. This is how us language people justify our salaries. On the other hand, I've been wondering if the change was caused by other factors not directly related to level of language, such as sites getting a wider variety of hardware (thus making non-portable assembly language impractical). C is very popular for new applications nowadays, but many consider C to be a "portable assembly language". >Modular code also allows changes in representation that can lead to orders of >magnitude performance improvements. Non-modular code strongly inhibits such >representational changes. In short, the micro-efficiency of non-modular code >leads to the macro-INefficiency of poor algorithms and representations. I agree 100% (especially since my thesis relates to this!) BUT, flaming about the wonders of data abstraction is not going to change anybody's programming practices. Demonstrations are much more convincing, although a DoD project to demonstrate reusability is probably much less influential than Jon Bentley's CACM column. Many recent C books have been introducing substantial libraries for reuse, although the books' stated policies on copying are not consistent. More of this sort of thing would be great. >Again, let me clarify. I meant that the reusable software would be written by >software houses and sold to companies which write applications. For instance, >Reusable Software Inc. sells a sort package to Farm Software Inc. which uses >it in its combine scheduling program. Farm Software Inc. need not divulge its >algorithms or its use of packages written by Reusable Software Inc. I hadn't thought about that. Here's my reaction as a Farm Software Inc. programmer - "How do I know if their stuff is good enough!? ... But the interface isn't right! ... How can we fix the bugs without sources!" Reuse can't happen until the seller *guarantees* critical characteristics - they have to be able to say that their sort package will sort M data values in N seconds, and that the software will have bugs fixed within a certain number of days of being discovered, and so forth. This is old hat for other kinds of engineers, but software companies these days will only promise that there is data on the disk somewhere :-(. (I'm sure there are places that will certify performance - anybody got good examples?) >[...] Modular code will cost substantially less in the long run. I sort of believe that too, but it's hard to substantiate. Anecdotes are easy to come by, but this is a field where cost depends primarily on programming skill, and we don't have a precise measure of that skill. The other cost win is when a module can be used in some other program, but the extra cost of making code reusable can only be justified if your company has another program to use it in! BTW, at Boeing I proposed an engineer-maintained library of aerospace-related subroutines, so people didn't have to continually reinvent spherical geometry formulas, Zakatov equations, and the like. But management rejected the idea, because it would be "too difficult to coordinate" (it was supposed to cut across individual projects). No mention of costs... People interested in promoting software reuse should look at how expert systems developed as a field. Although the first ones appeared in the mid- 70s, it wasn't until 1980 when the expert system R1 that configured Vaxen for DEC was published. DEC claimed to have saved millions of dollars in the first year of using it. From then on, the expert system business grew exponentially, although it's not clear whether anybody else has ever profited from an expert system so dramatically... > Lawrence Crowl 716-275-5766 University of Rochester stan shebs shebs@cs.utah.edu ---------------------------------------------------------------------------- Date: 25 Jun 87 17:32:39 GMT From: dday@mimsy.umd.edu (Dennis Doubleday) Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742 Subject: Software Reuse In article <4658@utah-cs.UUCP> shebs@utah-cs.UUCP (Stanley Shebs) writes: >An interesting analogy. It says a lot about prevailing software culture: > >1. Available chips do not always meet requirements exactly. For instance, >a board might need 3 NAND gates, but the 7400 has 4. EEs just ignore the >extra gate, or tie its pins to something stable. In a similar situation, >software people fume and gnash their teeth over "wasted space". > I've seen this standardized circuits analogy to software packages a number of times, and I don't really buy it. Software people are attempting to deal with a much larger and less well-defined problem domain than hardware people. Otherwise, we wouldn't even need software. We could just design hardware to handle every application. >2. Running wires around boards loses some performance, relative to cramming >everything onto a single chip. All the techniques for modules, objects, etc, >tend to slow things down. Again, software types tear their hair out and >vow to recode everything into one assembly language procedure. Performance is an important issue in many time-critical applications. I don't know anybody who wants to code everything in assembler. I do know people who are WILLING to code in assembler if it's the only way timing constraints can be met. >In short, I believe there are no technical problems or issues with reuse; >it's the software culture that has to change. At present, the prevailing >attitude is that the densely-coded, highly-optimized, do-everything program >is a sort of ideal to which everyone aspires. I don't think you're up to date on what's happening, at least in the Ada community. I just completed a 13.5K source line Ada program, of which 7.5K source lines were contributed by reusable utility packages that I got from the Ada repository (abstract string, stack, list, counted ordered set, and binary tree data types as well as packages for command line interface, lexical analysis of Ada, and parsing). UUCP: seismo!mimsy!dday Dennis Doubleday CSNet: dday@mimsy University of Maryland ARPA: dday@brillig.umd.edu College Park, MD 20742 Fan of: Chicago Cubs, Chicago Bears, OU Sooners (301) 454-6154 --------------------------------------------------------------------------- Date: 2 Jul 87 07:55:43 GMT From: mcvax!prlb2!crcge1!adams@seismo.css.gov (Drew Adams) Organization: Laboratoires de Marcoussis (CGE) - France Subject: Re: Software Reuse -- do we really know what it is ? Let me play provocateur and recommend a little known paper introducing another point of view regarding software reusability and modularity: Hughes, John, "Why Functional Programming Matters", Report 16, Programming Methodology Group, University of Goteborg and Chalmers University of Technology, Goteborg, Sweden, 1984, ISSN 0282-2083 Here's the abstract: "As software becomes more and more complex, it is more and more important to structure it well. Well-structured software is easy to write, easy to debug, and provides a collection of modules that can be re-used to reduce future programming costs. Conventional languages place conceptual limits on the way problems can be modularised. [Purely f]unctional languages push those limits back. In this paper we show that two features of functional languages in particular, higher-order functions and lazy evaluation, can contribute greatly to modularity. As examples, we manipulate lists and trees, program several numerical algorithms, and implement the alpha-beta heuristic (an algorithm from Artificial Intelligence used in game-playing programs). Since modularity is the key to successful programming, functional programming is vitally important to the real world." Hughes argues that the usual "advantages" of declarative languages over imperative ones (no assignment, no side effects, no flow of control) are negative expressions of some of the problems with imperative languages, but that they leave unexplained 1) why these problems are problems and, more importantly, 2) what are the real POSITIVE advantages of declarative programming. To quote from the introduction: If omitting assignment statements brought such enormous benefits then FORTRAN programmers would have been doing it for twenty years. It is a logical impossibility to make a language more powerful by omitting features, no matter how bad they may be. Even a functional programmer should be dissatisfied with these so-called advantages, because they give him no help in exploiting the power of functional languages. One cannot write a program which is particularly lacking in assignment statements, or particularly referentially transparent. There is no yardstick of program quality here, and therefore no ideal to aim at. Clearly this characterisation of functional programming is inadequate. We must find something to put in its place - something which not only explains the power of functional programming, but also gives a clear indication of what the functional programmer should strive towards. Hughes finds that the importance of functional languages is that they allow program modularisation in ways which imperative languages cannot. To quote again: "... recent languages such as Modula-II [Wirth 82] and Ada [DOD 80] include features specifically designed to help improve modularity. However, there is a very important point that is often missed. When writing a modular program to solve a problem, one first divides the program into sub-problems, then solves the sub-problems and combines the solutions. The ways in which one can divide up the original problem depend directly on the ways in which one can glue solutions together. Therefore, to increase one's ability to modularise a problem conceptually, one must provide new kinds of glue in the programming language. "... functional languages provide two new, very important kinds of glue [(higher order functions and lazy interpretation)].... This is the key to functional programming's power - it allows greatly improved modularisation. It is also the goal for which functional programmers must strive - smaller and simpler and more general modules, glued together with the new glues...." If you only read one article about (purely) declarative languages, let it be this one. You won't be disappointed.-- Drew ADAMS, Laboratoires de Marcoussis, Centre de Recherche de la Compagnie Generale d'Electricite, Route de Nozay, 91460 MARCOUSSIS, FRANCE Tel. 64.49.11.54, adams@crcge1.cge.fr .pa ---------------------------------------------------------------------------- Date: 1 Jul 87 08:30:40 GMT From: mcvax!ukc!dcl-cs!craig@seismo.css.gov (Craig Wylie) Organization: Department of Computing at Lancaster University, UK. Subject: Software reuse -- how do we reuse The recent discussion on software reuse has highlighted several points that I would like to take further. The question of what it is has been quite well covered - basically it is what ever you want it to be regarding the reuse of any part of the the software design process. I would like now to concentrate on one small area of reuse, reuse of Software Components, and more particularly the recovery of a component from some form of catalogue. Many of the replies, both to me personally, and to the net have cited 'Libraries', 'Browsers', and 'Intelligent Systems' as methods of retrieving software. I think that the analogy to lending libraries and online bibliographic retrieval is not a poor one but that it does require considerably more thought. Consider an example, in my research into distribution and software engineering I can go to a terminal, call up a bibliographic data base, and search on terms such as 'Reuse', 'Software Engineering', 'Distribution', 'Concurrency' etc.. The fact that these terms are very high level makes the retrieval process much easier, authors may well have included these terms in their keywords or abstracts. The provision of a synonyms dictionary will enhance the system. How can we provide similar power for components ? Obviously the keywords of a text can be mimiced by the provision of keywords from the authors of the software component (or the authors of the design work or any other object that might be reused), however there is no point in retrieving on whether the program contains a FOR loop. The automatic generation of keywords might also help, if not definitive it might certainly act as an aid. Yet how can we do this from languages such as Ada, it is far from proven that it is possible. One of the great powers of bibliographic retrieval is the fact that any paper retrieved will have a list of references, so if the paper found isn't exactly applicable then perhaps one of the referenced papers will be. How might this be mimiced? If we are to continue to use the library analogy then we must derive a way for talking about programs that is accessible to all. Remember even Math is not perfect - there can be more than one mathematical description of the same piece of software. Fuzzy logic and browsers have their place, but rather than citing them as answers we should be looking on them more as techniques once we know what we are dealing with. Sorry about the rather bitty nature of this article -- it has been a flow of thought article, the views are entirely my own. Craig UUCP: ...!seismo!mcvax!ukc!dcl-cs!craig| Post: University of Lancaster, DARPA: craig%lancs.comp@ucl-cs | Department of Computing, JANET: craig@uk.ac.lancs.comp | Bailrigg, Lancaster, UK. Phone: +44 524 65201 Ext. 4476 | LA1 4YR ============================================================================== Ada is a registered trademark, U.S. Government - Ada Joint Program Office. The following are trademarks of Digital Equipment Corporation: DEC, DECSYSTEM-20, ULTRIX, VAX, VMS. UNIX is a trademark of AT&T Bell Laboratories. The following are trademarks of Data General Corporation: AOS, ROLM. Verdix is a trademark of Verdix Corporation. TeleGen2 and TeleSoft are trademarks of TeleSoft. The Ada Software Repository Newsletter is Copyright 1986, 1987 Echelon, Inc. All Rights Reserved. Permission to reprint, wholly or partially, is automatically granted if source credit is given to Echelon. Echelon, Inc. 885 N. San Antonio Road Los Altos, CA 94022 USA Telephone: 415/948-3820