Programmer's ROM - The Computer Language Library

home *** CD-ROM | disk | FTP | other *** search

/ Programmer's ROM - The Computer Language Library / programmersrom.iso / ada / news / asr010.doc < prev next >

Wrap

Text File | 1988-05-03 | 53.5 KB | 961 lines

.RR--!----!----!----!----!----!----!----!----!----!----!-------------------R ..po 5 .po 1 .he ASR Newsletter, Issue 10, Feb-Mar 87 .fo Page # Ada (tm) Software Repository (ASR) Newsletter Issue 10, Feb-Mar 87 Richard Conn, Newsletter Editor Published by Echelon, Inc. THIS ISSUE Page I. STARS Common Ada Foundations Workshop and Request for Proposal 2 1. Announcement of Workshop 2 2. STARS Common Ada Foundations RFP 2 II. ASR-RELATED INFORMATION 4 1. Problem Report and Solution on McCabe Complexity Tool 4 2. Information on Forms Generator 5 3. Help Requested on Virtual Terminal 5 4. Data on the WIS/NOSC Tools 6 5. Archive Server and BITNET 6 6. FTP Restrictions During Prime-Time 6 III. SPECIAL TOPIC - SOFTWARE REUSE AND THE DoD 7 1. The Problem and a Specific Case 7 2. Comments and a Perspective 11 3. Software Reuse and STARS 12 IV. ITEMS OF INTEREST 12 1. Software Components Book by Grady Booch 12 2. Ada Integrated Environment/Ada Compilation System Available 13 3. Status of Ada Technology - Call for International Research 14 4. Object-Oriented Design and Requirements Analysis 15 5. Guidance on the Use of INFO-ADA 16 6. COSMIC - A NASA Software Repository 17 V. NEW SUBMISSIONS TO THE ASR 17 --------------------- NOTE: Statements made in this newsletter should generally be considered to be personal opinions of the individuals and not necessarily the opinions of the U.S. government, any specific company, or any particular organization. Books on the Ada Software Repository ----- -- --- --- -------- ---------- The Ada Software Repository and the Defense Data Network: A Resource Handbook by Richard Conn, 203 pp, published by New York Zoetrope, Inc., 838 Broadway, New York, NY 10003, phone 800/242-7546. This book is an introduction to the Ada Software Repository and the Defense Data Network, detailing their use (with numerous examples) and providing details on the resources available through them. The Ada Software Repository Master Index by Richard Conn, 420+ pp, Echelon, Inc., 885 North San Antonio Road, Los Altos, CA 94022, phone 415/948-3820. This loose-leaf book contains details on the contents of the Ada Software Repository, containing abstracts and listings of associated files on each item in the Ada Software Repository. .pa ---------------------------------------------------------------------------- I. STARS Common Ada Foundations Workshop and Request for Proposal A Workshop for the STARS Common Ada Foundations project was held in support of the Request for Proposal (Broad Agency Announcement) that appeared in the March 4 Commerce Business Daily (CBD). 1. Announcement of Workshop [Ed Note: This announcement was also made as a part of the Broad Agency Announcement in the March 4 CBD.] Subject: STARS Common Ada Foundations Workshop From: BBRYKCZYNSKI@ADA20.ISI.EDU To: info-ada@ADA20.ISI.EDU Cc: ada-sw@SIMTEL20.ARPA The Software Technology for Adaptable Reliable Systems (STARS) Program Office, with the Institute for Defense Analyses is hosting a technical (i.e., not marketing) workshop on Ada Foundation Technologies for the STARS program. The areas to be covered include Command Language; Software Design Description and Analysis Tools; Text Processing; Database Management System; Operating System; Planning and Optimization Tools; Graphics; and Network Protocols. This workshop will be useful for possible forthcoming acquisitions. No programmatic information will be discussed. Those wishing to attend the workshop must register with Tracy Poole; Institute for Defense Analyses; Computer and Software Engineering Division; 1801 North Beauregard Street; Alexandria, VA 22311; (703)824-5538, by March 2, 1987. Microfiche copies of documentation that is related to the STARS Foundation Technologies will be given to those attending the workshop. If you wish copies of this documentation, but will not be attending the workshop, it can be ordered by contacting Tracy Poole. The workshop will be held on March 6, 1987 at the Radisson Mark Plaza Hotel, 5000 Seminary Road, Alexandria, VA 22311-1995, (703)845-1010. A block of rooms for those attending this workshop has been set aside. Single rooms are $79.00 including tax. Double rooms are $99.00 inclulding tax. Early registration is suggested. 2. STARS Common Ada Foundations RFP From: Rick Conn <RCONN@SIMTEL20> Subject: STARS Common Ada Foundations Technologies To: ada-sw@SIMTEL20 STARS Common Ada Foundations Workshop sponsored by STARS Joint Program Office and Institute for Defense Analyses The following information is provided in the interests of the Ada community and in promoting the Ada effort. In my opinion, the opportunities provided by the STARS JPO/NRL should be seriously considered by members of the Ada community. Proposals in response to this BAA (see below) are encouraged. The STARS Common Ada Foundations Workshop was held on Friday, March 6, at the Radisson Mark Plaza Hotel in Alexandria, Virginia. One of the main reasons for this workshop was to provide background/supporting information for the proposals to be submitted in response to Broad Agency Announcement in the March 4 Commerce Business Daily. If you were not able to attend the workshop, microfiche copies of documentation that is related to the STARS Foundations Technologies can be obtained by sending a request with your name, title, company affiliation, address, and phone number to: Richard Waychoff Institute for Defense Analyses Computer and Software Engineering Division 1801 North Beauregard Street Alexandria, VA 22311 See below for comments on the content of the microfiche. This announcement, entitled FOUNDATION ADA SOFTWARE FOR RESEARCH IN VIRTUAL INTERFACES: BROAD AGENCY ANNOUNCEMENT (BAA), is abstracted in part: "The government desires firm-fixed price R&D contracts, but reserves the right to negotiate a different type of contract. The DOD Software Technology for Adaptable, Reliable Systems (STARS) Program in co-operation with the Naval Research Lab (NRL) is soliciting proposals for the development of reusable Ada (DOD trademark) software modules with which common foundation area capabilities can be composed in a form suitable for follow-on research and experimentation in the development and application of the virtual function interfaces needed to foster and support a truly machine-independent applications software technology. The goal is to provide Ada building block components for several foundation areas, including, but not limited to: 1) Ada as a common command language, 2) software design, description and analysis tools (including those necessary to support reliability and multilevel security properties), 3) text processing, 4) database management systems, 5) operating systems (including tailorable Ada run time support for embedded and trusted applications), 6) planning and optimization algorithms, 7) graphics, 8) telecommunications and network protocols, or 9) other (consistent with STARS program objectives for virtual interface support and machine independent applications). "As a WIS Joint Program Management Office initiative, the Institute for Defense Analysis (IDA) sponsored team efforts to examine common foundation areas. Resulting IDA reports include an initial 1983 study and a set of 9 volumes published in 1986 intended to provide the basis for many component development contracts. The studies provide a starting point, but are not sufficient for STARS. STARS seeks industry sources to plan, design, develop, integrate and demonstrate research prototypes for several foundation areas. "The Naval Ocean Systems Center (NOSC) contracted for development of about 60 Ada products called NOSC tools [ed note: most of these are in the Ada Software Repository now or are to be placed in the ASR]. These products provide a convenient source of Ada code. Those NOSC products developed by small teams in 90 to 120 days generally achieved schedule and performance objectives; larger efforts often did not. For this reason, offerors are encouraged to use a 'Chief Programmer' approach supported by parallel, small, best-qualified teams (either in-house or subcontracted, but uniquely identified) to develop the individual building block components for an area." MICROFICHE CONTENTS The microfiche mentioned above (for the STARS Common Ada Foundation Technologies) contains several hundred pages of information which the reader may find useful whether or not he is planning to respond to the BAA. The following outlines its content: 1) Overview of Requirements for WIS Prototype Software Development Projects 2) Software Requirements for WIS Command Language Prototypes 3) Software Requirements for WIS Software Design, Description, and Analysis Tools 4) Software Requirements for WIS Text Processing Prototypes 5) Software Requirements for WIS Text Database Management System 6) Software Requirements for WIS Operating System Prototypes 7) Software Requirements for WIS CAS of the WISSAPED 8) Software Requirements for WIS Graphics System Prototypes 9) Software Requirements for WIS Network Protocol Prototypes 10) WIS Implementation Study Report - Vol I - Main Report 11) Software Technology for Adaptable, Reliable Systems (STARS) Technical Program Plan 12) Software Technology for Adaptable, Reliable Systems (STARS) Program Management Plan 13) The WIS Ada Design Language 14) Ada/SQL: A Standard Reliable, Portable Ada-DBMS Interface 15) GKS/Ada CDRL 009 Final Technical Report 16) MIL-HDBK-245B, 1 June 1983 In addition to this microfiche, hardcopy documentation (over two inches thick) of the presentations was distributed at the workshop. IDA has not yet decided if it will also mail copies of this hardcopy; I will let you know when I am advised of their decision. ---------------------------------------------------------------------------- II. ASR-RELATED INFORMATION 1. Problem Report and Solution on McCabe Complexity Tool A problem was reported and resolved with the McCabe Complexity Measures Tool. Dialogue follows: From: dday@mimsy.umd.edu (Dennis Doubleday) Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742 Subject: Problem with McCabe tool on Simtel20 To: info-ada@ada20.isi.edu Maybe somebody out there at Intermetrics or Simtel20 can help me. I retrieved the McCabe Complexity tool and the Intermetrics abstractions packages from Simtel20, from the METRICS and COMPONENTS directories, respectively. However, while attempting to compile the McCabe tool, I realized that two packages were missing: the packages Standard_Interface and Labeled_Binary_Tree_Pkg are named in WITH directives but are nowhere to be found in ABSTRACT.SRC or MCCABE.SRC. According to the documentation, all the code for the tool should be found in these two files. Are these packages somewhere else on Simtel20 or have they been inadvertently left out? Please help. From: dday@mimsy.umd.edu (Dennis Doubleday) Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742 Subject: More missing McCabe To: info-ada@ada20.isi.edu An addition to my previous posting about the McCabe tool from the Simtel20 repository: I am also unable to find a package called Case_Insensitive_String_Comparison which is WITHed by the body of Statements_Pkg. Any help locating this and the other missing packages would be greatly appreciated. REPLIES As you reported, I did not find Standard_Interface or Labeled_Binary_Trees_Pkg in ABSTRACT.SRC. I found them in NEWABS.SRC, however (NEWABS.SRC is also in PD:<ADA.COMPONENTS>). Offhand, it looks like there is an error in the documentation ... NEWABS.SRC should be used with HALSTEAD AND MCCABE rather than ABSTRACT.SRC. Would you try it and let me know? case_insensitive_string_comparison is also in NEWABS.SRC. Thanks for reporting the problem. Rick Conn -- NOTE: a later response indicated that the problem was corrected and NEWABS.SRC is the correct body of code to use. 2. Information on Forms Generator From: Rick Conn <RCONN@SIMTEL20> Subject: Re: ADA Sources Wanted To: tektronix!reed!psu-cs!omepd!pate@UCBVAX.BERKELEY.EDU cc: info-ada@ADA20.ISI.EDU, ada-sw@SIMTEL20 In response to your request for information on a Forms Generator, the Ada Software Repository on SIMTEL20 contains a Forms Generator in PD:<ADA.FORMGEN>. From the abstract: "The forms generator will display and accept input into a form (in a screen-oriented fashion via the virtual terminal) in such a way that this mechanism is transparent to the Ada program using it. ... The system [provides] both an interactive and batch interface that enables an application programmer to design a screen format and save the representation in a machine readable form." The Forms Generator (FORM2*.*) is one of the WIS/NOSC tools. Code is over 270,000 bytes, and all files (code and doc) total to over 470,000 bytes. For the interactive mode, you also need the Virtual Terminal software in PD:<ADA.VIRTERM>, which is another 224,000+ bytes of software with a total of 927,000+ bytes (sw and doc). 3. Help Requested on Virtual Terminal From: arlpsu@nems.ARPA (Jack Sharer) Subject: Virterm Help To: rconn@simtel20 I would like to use the virtual terminal packages in VT2.SRC located in the VIRTERM subdirectory of the Ada Repository on a VAX 8200 running Verdix Ada under VMS. Has anyone rewritten the package body, SYSDEP_BODY.ADA, to work in this environment? Please send any information that may help to: A. F. Niessner, Jr. Applied Research Laboratory Penn State University via arlpsu@nems Thanks Al Niessner 4. Data on the WIS/NOSC Tools From: Rick Conn <RCONN@SIMTEL20> Subject: Re: Need info on NOSC Ada tools To: Bhatt@HI-MULTICS.ARPA cc: ada-sw@SIMTEL20 Info on the WIS/NOSC Ada tools can be found in the Ada Software Repository under PD:<ADA.WIS-ADA-TOOLS>. Data: PD:<ADA.WIS-ADA-TOOLS> Bytes(SZ) ABSTRACT.DOC.1 105309(7) CONTENTS.DOC.1 54324(7) REFFILES.DOC.1 190757(7) Also, Chapter 14 of the ASR Master Index is devoted to these tools. 5. Archive Server and BITNET From: "Frank J. Wancho" <WANCHO@SIMTEL20.arpa> Subject: Archive Server Bit Bucket To: INFO-CPM@AMSAA-SEER.ARPA, INFO-MICRO@BRL.arpa, INFO-IBMPC@C.ISI.EDU The Archive Server attempts to send its replies to the requestor based on the Reply-To: or From: lines of the messages it receives, in that order. Recently, messages coming from BITNET sites through WISCVM.WISC.EDU are being received here without the From: lines being coerced into the form user%host.BITNET@WISCVM.WISC.EDU. As we don't have a table of BITNET hosts, these replies fail. Thus, if you sent in a request from a BITNET host over the last several days and didn't receive a reply, you now know why. When I hear that WISCVM.WISC.EDU has repaired their mailer, I'll pass the word so that you may resume sending your requests. (Alternately, if anyone knows where I can periodically pick up a copy of a complete list of BITNET hosts, I'll try to keep our mailer's database current.) 6. FTP Restrictions During Prime-Time From: Rick Conn <RCONN@SIMTEL20> Subject: ASR Admin To: ada-sw@SIMTEL20 FTP users during prime time have been getting a message when they try to use the ANONYMOUS login to SIMTEL20 that logins are not permitted until after 4PM MST. From: WANCHO@simtel20.arpa To: INFO-CPM@simtel20.arpa, ADA-SW@simtel20.arpa Subject: ANONYMOUS FTP Access Restrictions We have had to temporarily impose restrictions on ANONYMOUS FTP access to SIMTEL20 during our prime-time due to extremely high network and system loads. We hope to be able to reinstate prime-time ANONYMOUS FTP access sometime after 1 April when we expect a large group of our users will have migrated to their own host. Please bear with us. ---------------------------------------------------------------------------- III. SPECIAL TOPIC - SOFTWARE REUSE AND THE DoD The following is the text of a discussion initiated by Ed Berard on INFO-ADA and ADA-SW. Ed also posted his telephone number: Ed Berard (301) 695 - 6960 1. The Problem and a Specific Case Subject: Does the DoD Really Want Reusable Software? From: Edward V. Berard <EBERARD@ADA20.ISI.EDU> To: info-ada@ADA20.ISI.EDU, ada-sw@SIMTEL20.ARPA Nearly two decades after Doug McIlroy described the need for a software components industry, software reusability is finally receiving some attention. One of the promises that the U.S. Department of Defense (DoD) made when it introduced the Ada programming language and its associated technology, was that Ada would help to facilitate software reusability. Apparently, someone within the bowels of the DoD feels that software reusability is an important issue. A quick study of the possible benefits of reusing software reveals that there is much more to be gained than a simple cost savings during the development of a software product. For example, the reuse of a software component which is known to be reliable introduces less risk than re- designing and re-coding the same component for each new application. Efficiency issues can also be more effectively addressed if one can focus attention on optimizing a set of reusable components rather than having to continually re-optimize newly recoded versions of previously existing modules. However, it seems that both the DoD and their contractors are greatly confused about just what an increased emphasis on software reusability might mean. While they both might acknowledge that some existing software development practices will have to change, they seem unaware of which specific items will be different. There are a number of very large roadblocks to software reusability on DoD projects, and it should be useful to mention a few of them. One of the largest roadblocks to software reuse is the cost-plus-fixed- fee (CPFF) style of contract now commonplace among DoD contracting styles. In effect, the more people a contractor can place on a project, the greater the financial reward. Hence there is a great incentive to "re-invent the wheel." While fixed-price contracts would go a long way towards fixing this "problem," we need to examine other alternatives. Current and past DoD software development standards (e.g., DOD-STD- 2167, 490, 1679A, etc.), or their interpretations, are another set of roadblocks to software reuse. While the words "software reusability" might be "buried in the DIDs" (Data Item Descriptions), the standards themselves discourage software reuse on a number of fronts, e.g.,: 1) the encouragement of software development methodologies which do not facilitate reuse (e.g., functional decomposition), while discouraging others that seem to encourage reuse (e.g., object oriented approaches), and 2) requiring that every piece of code produce for a project, be relevant specifically to that project. While this might seem to be a perfectly reasonable demand, it violates one of the axioms of reusability, i.e., generality. While the DoD has standards of acceptance for reusable hardware, there is little in the way of standards or certification mechanisms for reusable software. For example, there is no currently existing organization charged with certifying software for reuse. Yes repositories of "reusable" software exist, but there is no generally recognized (much less mandated) certification mechanism for reusable software components (e.g., an Ada Component Verification Capability (ACVC)). In the past year, I have given a number of presentations on software reusability. During the discussions which followed these presentations, I became acutely aware that either the DoD was actively *discouraging* the concept of software reuse or that the contractors (and the DoD) did not know that an increased emphasis on software reuse would involve significant changes in the state of the practice. Until both the DoD and their contractors come to grips with the fact that software reusability does not mean business as usual, software reusability will be relegated to the status of a buzzword. MORE DETAILS Subject: DoD and Reusable Software - Part 2 From: Edward V. Berard <EBERARD@ADA20.ISI.EDU> To: info-ada@ADA20.ISI.EDU, ada-sw@SIMTEL20.ARPA 1.0 Introduction Earlier, I posted a message about the roadblocks that the U.S. Department of Defense (DoD) is placing in the path of software reusability. This message describes a specific example of how an attempt to encourage the reuse of Ada software on an actual DoD project is being thwarted. Neither the contractor (a very large, well-known west coast aerospace firm) nor the contracting branch of the service (the Navy) has said that software reusability is a bad thing. Both, however, are prevented by well-established DoD regulations from both creating and reusing "reusable software." 2.0 Brief Technical Analogy In the computer hardware industry, reuse is the norm. For example, there are standard CPU chips (e.g., M68020, Intel's 8088, and various versions of the 1750a). There are also standard RAM, mathematical co- processor, and ROM chips. These, and other, chips are used in a wide variety of applications. A long time ago, electronics engineers discovered that one of the most important axioms of reusability was generality. Unlike their software counterparts, electronics engineers do not have to verify, for example, that every "op-code" supported by a particular CPU is executed in a specific application. Nor do they have to demonstrate that every last byte of RAM is utilized. While the reasons for this should be obvious, it would be helpful to point out a few of them: 1) Once a CPU chip is created and verified, a known (and typically very high) level of reliability can be established for the chip. When this chip is reused in another application, its known reliability can be factored into a determination of the overall reliability of the new system. [While a great deal is currently known about software reliability, much more is known about hardware reliability.] 2) If a change is introduced into the software which is running on a particular CPU chip, specifically a change which now requires that a previously unused "op-code" come into use, there is little need to replace (or alter) the CPU chip. [Think of an Ada package as a chip, and the operations in its interface as "op-codes."] A similar argument could be made for the amount of random access memory incorporated in a computer system. 3) As new engineers are assigned to a project, it is likely that they may have experience with standard, reusable chips. Even if they do not have experience with the specific chips being used, there are certain fundamental concepts which are common to particular classes of chips, and the new engineers are likely to be aware of these concepts. 4) With the demand for computer hardware (everything from embedded systems to stand-alone computers) at an ever increasing high level, the cost and time required to custom-design chips so that they are optimized for a specific application is prohibitive. [Notice that since few organizations track real software costs, that it is often difficult to make a similar justification for not overly-customizing software.] How does one apply the above analogy to reusable software? Consider the design of a reusable software component. To be truly reusable, a software component must be usable in some place other than its current specific application (or part of an application). To increase the chances of this happening, the software engineer must make the component more general. In fact, there are well-known ways of increasing the generality of a software component to a very high level. Of course, there are trade-offs. Increasing the generality may decrease the efficiency, or even increase the complexity. These, and other considerations, must be balanced against such factors as the potential increased reliability resulting from using a known verified component, and the cost and times savings resulting from software reuse. 3.0 A Description of the Specific Problem In the past year there has been no shortage of "software reusability" presentations. Those of us on the "Software Reusability Circuit" seem to take our show to an every widening audience. If you have attended any software reusability presentations, or if you have read any of the increasing numbers of articles on the subject, you have probably noticed a pattern. Typically, the presenter or author describes a "research project," or describes what sounds like a good idea, but "hasn't yet been put into practice." This points out one of the interesting human aspects of new technology. Since introduction of new technology requires change, and human beings are, by nature, conservative, it almost always takes a certain minimal amount of time before new technology can actually be introduced into the workplace. So we go about our "dance." We have meeting after meeting on the topic, and everyone seems to be in general agreement (software reusability sounds like a nice idea). However, nothing gets done until someone actually demonstrates the validity of the concept on a "real" project. At my company, we have both discovered (probably re-discovered) and demonstrated some of the fundamental concepts of software reusability. Further, since we often find ourselves in a teaching role, we try to communicate these concepts to our clients during the normal course of our classroom instruction. Almost always, our students have "real projects" to which they must immediately apply the technology covered in our classes. As you are probably aware, teaching in industry must be very pragmatic, and real world oriented. Recently, one of us was describing how to increase the reusability of software components during a class at the previously mentioned large aerospace firm. He was informed that while the techniques he was describing might indeed increase the reusability of Ada software, there were forbidden by specific DoD policy. I asked the instructor to have the students document the problem. What follows is that documentation: 1) MIL-HDBK-272 requires that there be no "extraneous code" in a program that is involved in the Nuclear Safety community. The "extra" functions which might make a software component more general, and hence more reusable, are forbidden. [Notice that this (unknowingly) trades off one kind of software reliability (i.e., the increased reliability resulting from less code in the software product) against another (i.e., the potential increase in software reliability resulting from the use of a known, verified component.] 2) C/SCSC - AFPRO/DCAA (no, unfortunately, I don't know what these acronyms stand for, however they refer to an auditing agency). There are audits to insure that the contractor is only doing what the contract states. [This is part of a classic "Catch 22" phenomenon. Specifically, it may be permissible for a contractor to reuse software (although given the current hostile climate for "extraneous code," this may be difficult), however no new reusable software may be generated on a project if it requires any generality outside of the scope of the immediate problem.] 3) The original contract had *no* requirement for reusable software. If any resources are expended on increasing the reusability of any of the software components, the contractor will not be compensated for these expenditures. [Another axiom of reusability is that the original design, implementation, and verification of a reusable component are more costly than similar processes carried out without reusability in mind. However, the more reusable the component, the quicker the payback and the greater the future savings.] 4) A particular danger, according to the contractor, (one that DCAA/AFPRO will look for) is that if the contractor creates reusable software on a cost-plus-fixed-fee contract, he may not reuse the software on a fixed price contract and charge the government (again) for the software. [This is an interesting paradox. The government would rather pay the much larger cost of a completely original piece of software, than be charged twice for the same reusable software components -- even if the reuse of software components results in a greatly reduced new product.] 5) The cost of documenting and distributing the reusable software would not be an allowable cost on any contract. [Here, I have no sympathy for the contractor. This is merely a cost of doing business, and further, such costs can be factored into the contractors fee.] 4.0 Summary Both the DoD and the contractors which provide software to the DoD will have to change the way they do business if they wish to realize the promised benefits of reusable software. Much more thinking will be required on both sides. In the end, governmental software policies will have to change, or their interpretations will have to become more liberal. The contractors have as much to change (if not more) than the government. Software reusability, unlike a great deal of software engineering technology, can show a payback in a relatively short period of time. I hope that both the government, and the software community as a whole expend the time and effort required. 2. Comments and a Perspective From: BENNETT%sp.unisys.com@RELAY.CS.NET To: ada-sw@SIMTEL20.ARPA Subject: reusability Having just read the two dissertations on reusability submitted by Mr. Berard, I find myself wondering about a couple of things. First, it seems to me that the Cost-Plus-Fixed-Fee contract is not, in itself a barrier to the development and use of reusable software. On the contrary, by making optimum use of reusable modules, I could reduce the level of effort needed for implementation and apply the savings on the front end of the life cycle. The net effort would be the same, but we have reason to believe that increased effort on the front end of the development will lead to a higher quality output. Second, I would like to see some evidence that "object oriented" methods are better than "functional decomposition" at facilitating reuse. It seems that it would be the job of the designer in either case to recognize those functions or objects which are candidates for reuse. I might be convinced if there were a rigorous methodology for either functional decomposition or object oriented design which would result in two different designers producing identical designs from the same input. Third, requiring that "every piece of code produced for a project, be relevant specifically to that project" does not. In itself, preclude implementing reusable modules. If modularity and cohesion are emphasized, it is certainly possible to construct modules (packages, subprograms, ...) that, while they may not be able to be moved intact from one application to another, would need very little to refit them for a different application domain. We must be flexible enough in our definition of reusability to accommodate the range of legal and procedural impedimenta. If the mountain will not come to Mohammed ... Let's start finding ways to use what we have. Let's get everyone up to the level of the current software engineering technology. Let's quit generating excuses and start attacking the problem. Michael P. Meier .pa 3. Software Reuse and STARS From: Rick Conn <RCONN@SIMTEL20> Subject: STARS and Software Reuse To: ada-sw@SIMTEL20 cc: info-ada@ADA20.ISI.EDU I had the pleasure of attending the recent STARS Common Ada Foundations Workshop, sponsored by the STARS JPO and IDA. A lot of useful information was presented in this packed, one-day workshop, and key among it is that STARS is really interested in encouraging softwawre reuse. The recent BAA is an example, in which organizations making proposals are really encouraged to reuse the software in the ASR as much as they can. Several presentations pointed to applicable materials in the ASR. I believe that the government wants to ultimately encourage reuse, but I also believe that this will not happen overnight. Decisions have to be made at the top, directives issued, the services (Army, Navy, Air Force) have to respond to these directives and issue their own regulations, and then the Program Offices will react, interpret the regulations, and implement reuse clauses in their contracts. It will take time. I feel that the AJPO's education initiative, which includes the education of Congressional personnel, Pentagon officials, and other top government leaders is an excellent move to promote understanding at the upper levels and generate support for changes such as directives to promote reusability. But all of this will take time. In the meantime, we also have the other side of the house -- the contractors who are in it to make money. While software reuse may mean a savings to the government, it may also mean a loss of revenues to the contractors (and a corresponding empire reduction). Yet another problem. ---------------------------------------------------------------------------- IV. ITEMS OF INTEREST 1. Software Components Book by Grady Booch "Software Components with Ada" A new book by Grady Booch, due out mid-April Grady Booch, author of "Software Engineering with Ada," has completed a new book, as described below. The following information is provided as a service to the Ada community. From an email message written by Grady (with minor modification): "Software Components with Ada was written with three goals in mind: -- provide a catalog of reusable software components, illustrate how each component was developed, and demonstrate how they collectively may be applied to the construction of complex systems -- offer examples of good programming style using Ada -- continue the development of the object-oriented techniques first presented in Software Engineering with Ada "This book is appropriate for formal courses as well as for self-study. It is intended for use in a software engineering course, for a second course in programming, and for a course in data structures and algorithms. This book may also be used in an advanced Ada course, since it introduces many of the more powerful constructs of the language. For the professional developer, this book offers a practical catalog of reusable software components and a tutorial on the effective use of Ada. For the beginner, this book provides a solid foundation in data structures and algorithms and offers insight in to the program development process. "Software along with this book is available from the author. This includes some 501 components, for a total of just under 150,000 lines of Ada." To obtain Grady Booch's new book, the following is the address and the phone number of the publisher. The price is $32.95 (estimated at this time), and it is not set for release until mid-April. Benjamin/Cummings Publishing Company 2727 Sand Hill Road Menlo PArk, CA 94025 415-854-6020 or 800-227-1936 2. Ada Integrated Environment/Ada Compilation System Available The following information is provided by personnel at Rome Air Development Center. ADA INTEGRATED ENVIRONMENT (AIE) ADA COMPILATION SYSTEM (ACS) ***** Availability & Maintenance Course ***** BACKGROUND The U.S. Air Force's "Ada Compilation System (ACS)" is sponsored by Rome Air Development Center (RADC) at Griffiss AFB, NY. The 400,000-line fully self-compiled Ada compiler was developed by Intermetrics, Inc. The ACS runs on IBM 370, 43XX, and 30XX computers as well as plug- compatible machines such as those made by Amdahl. The UTS operating system (Version 2.3) is a UNIX variant and is available from Amdahl either in "native mode" for Amdahl 580-series machines or on top of VM on IBM machines. The compiler has been validated with ACVC 1.8 and executes at 250 to 400 lpm on the IBM 4341 with an Ada to assembly language expansion ratio of 1 to 4. The compiler contains a comprehensive global optimizer. The ACS performs four major classes of optimizations: o Ada-specific optimizations (such as constraint-check minimization and Haberman-Nassi Tasking), o Classical optimizations (such as common expression elimination and dead code elimination), o Register optimization, and o Branch optimization. Other compiler features include a partial implementation of Ada Chapter Thirteen, extensive syntax error recovery, compilation statistics gathering, and generation of source, object, and symbol/cross-reference listings. Because of the emphasis on optimization, configuration management support, and capacity, the ACS is suitable for developing large, time- critical Ada applications. The ACS was developed in accordance with the Military Standards for software development, and is documented. AVAILABILITY The Data & Analysis Center for Software (DACS) has been authorized by Rome Air Development Center (RADC) to distribute the "Ada Compilation System (ACS)" to any U.S. Government Agency. In addition, the ACS may be distributed to those individuals or enterprises certified and registered as qualified contractors in the Defense Logistics Services Center (DLSC) data base. These are published in DLSC'S "Qualified Contractor Access List (QCAL)." A "Statement of Terms & Conditions" must be completed and approved prior to the release of the AIE software and/or documentation to any nongovernment organization. Contact Ms. Nancy L. Sunderhaft at the DACS for additional information on obtaining the ACS software and/or documentation: Data & Analysis Center for Software RADC/COED Griffiss AFB, NY 13441-5700 ATTN: ACS Compilation System (315) 336-0937 or (AV) 587-3395 DDN: Sunderhaft@RADC-Multics A limited number of licenses for the ACS running on the MVS operating system are available from Intermetrics, Inc. Contact Mr. Donald Mark (see address below) for information on obtaining an MVS version of the ACS. MAINTENANCE COURSE A one week Maintenance Course will be held 23-27 March 1987 at Intermetrics, Inc. in Cambridge, MA. The course will include an overview of the ACS; Host Interface and Virtual Memory Management; the Lexer and Parser; Semantic Analysis; General Instantiation; Retargeting the Compiler; Building the Compiler; Rehosting the Compiler; and the Program Library Manager. There is no fee to attend the Maintenance Course. Participants are responsible for their own transportation, meals, and lodging. Compiler development companies are not eligible to participate in the Maintenance Course. Send a written request (no net messages, please) to participate in the ACS Maintenance Course by 11 March 1987 to Mr. Donald Mark at the following address: Rome Air Development Center Command & Control Software Engineering Branch RADC/COEE Griffiss AFB, NY 13441-5700 (315) 330-3655 or (AV) 587-3655 3. Status of Ada Technology - Call for International Research From: cbatt!cwruecmp!cwruacm@ucbvax.Berkeley.EDU (Kronen Insultants) Organization: CWRU Dept. of Computer Engineering, Cleveland, Ohio Subject: International Cooperation To: info-ada@ada20.isi.edu The Swedish Attache of Technology supports an investigation of the current status of Ada-technology. Special interest will be paid to real time applications for Ada. The investigation will be carried out by Ass. Prof. Lars Asplund, University of Uppsala, Sweden, mail-address ASPLUND@SEMAX51.Bitnet. Fields of interest are aplications, compilers and support for embedded systems. If YOU have a special interest and knowledge in these fields and would like to share this internationally, PLEASE contact Mr. Asplund. Case Western Reserve University Student Chapter of the ACM UUCP: ...!decvax!cwruecmp!cwruacm CSNET: cwruacm@case ARPA: cwruacm%case.csnet@relay.cs.net US Mail:c/o Dept. of Computer Engineering Case Western Reserve University Cleveland, Ohio 44106 4. Object-Oriented Design and Requirements Analysis From: larry@Jpl-VLSI.ARPA Subject: OO and Requirements To: info-ada@ada20.arpa I've been talking recently with several people about the relationship of object orientation to requirements analysis. The following is my answer, which borrows from Russell Abbott's _An Integrated Approach to Software Development_ (John Wiley & Sons, 1986). Abbott is the person to whom Grady Booch gives credit for his particular approach to object-oriented design and programming. My interpretation may differ from Abbott's, but the bottom line is the same: object orientation is essential to requirements study, but is not enough by itself. THE CHINESE BLACK-BOX PROBLEM Abbott splits requirements analysis into two phases (or roles, if as I do you see development as a parallel rather than a serial process.) The needs analysis phase is concerned with the environment of a problem, with WHY a new system of some kind is to be developed. Since no system can solve all problems or garner all profits, the client and analyst(s) prioritizes the pains and gains to be dealt with and drops some of them. Boundary conditions are then set for those that remain. The end product of this phase is a Requirements Specification. The second part of the requirements study is the system synthesis phase, which focuses on WHAT the new system will be. This phase produces a description of a system that will meet the constraints defined earlier. There may be several that would satisfy the client. The one picked becomes the Target Specification. Abbott emphasizes that the Req spec must be kept as loose as possible and distinguished from the Target Spec to keep from painting oneself into a corner. Design is concerned with the insides of the system, with HOW resources are to be partitioned and allocated to make the system real. There may be more than one good way to partition/allocate resources; one must be picked. To manage the complexity inherent in any non-trivial system, design is often broken into a preliminary and one or more detailed phases. This brings to light a confusion that I call the Chinese Black-box Problem. Each target that satisfies a higher-level requirement establishes requirements for the next level down, so how do you know the difference between requirements and design? The resolution is that requirements and design are duals of each other, and are distinguished by whether you are looking up or down abstraction levels. Or put another way: every coin has three sides, the inside, the outside, and the coin-purse. .pa NOUNS/VERBS/ADWORDS Defining important objects is often the first action done at each level of abstraction, whether it be the two requirements phases, two or more design, or the various implementation phases. Most writing makes object orientation sound very esoteric, but in fact the situation is just the opposite. An object is simply an entity with fairly definite boundaries. This is the sole criterion, but in the real world most objects have three other attributes. One is a skin at the boundary that hides/protects some of its interior and shows/exposes other parts. Also, they have relationships with other objects, one of the more important ones being membership in one or more classes. Lastly, they tend to be long-lived or combine to make up larger objects that are long-lived. Each of these characteristics (bounds, skins, relations, longevity) are important because they simplify the thinking of everyone concerned. It is for this reason that objects are often the starting point in each phase. Longevity is also important at the end of the development process: the "maintenance" phase. Enhancement or error correction is much easier when major parts of a system are stable. But a system without time (or with eternal time) is useless. Change is also needed--attributes of objects (color, location, etc.), relationships with other objects (before/after, brighter- or dimmer-than), the creation and deletion and transformation into other objects, etc. This is a procedural orientation. Ed Berard (and I believe Booch) distinguish two types. A mapping from a domain of objects to a range of them (before and after: binary time) is a functional abstraction. More complex temporal changes need an explicit or implicit controller and is labeled a process abstraction. In many cases it makes more sense to start a phase defining the nouns (objects) of a (sub)system being developed, but there are also systems where time is more important and it may be best to start with the system's verbs (functional relationships, attributes, and decomposition). In either case, however, developers will have to deal with both nouns and verbs and rarely will one be more more important than the other in the long run. But there's another linguistic element that needs attention, especially in regards to requirements: adwords (adjectives and adverbs). Ada (or Ada- like) "sentences" can adequately specify the noun and verb elements of a target specification, with expressions on the order of OBJ2 := Func(OBJ1). But how can requirements be specified? What's the Ada equivalent of the following? Size(OBJECT) < MAX and Time(Func) > WAIT 5. Guidance on the Use of INFO-ADA Subject: Guidance on the Use of INFO-Ada From: CASTOR@ADA20.ISI.EDU [ed note: this is an official statement] To: info-ada@ADA20.ISI.EDU INFO-Ada is sponsored by the AJPO to support the promotion and introduction of Ada throughout the Department of Defense (DoD) and the industries supporting DoD. It's primary emphasis is on information exchange among the members subscribing to the mailing list. In order to further facilitate that exchange of information, a bidirectional link between INFO- Ada and the USENET newsgroup comp.lang.ada (formerly net.lang.ada) has been created. The AJPO guidance on the use of INFO-Ada is to strive to keep it for fair usage. This means that no one should take advantage of it for commercial marketing or promotion of any product, company, service, institution, organization, etc. The desire is to avoid any bias (express or implied) on the part of the government with regard to endorsing or showing favoritism to any particular entity. Authoritative, informative, non- commercial messages are considered acceptable. INFO-Ada is normally automatically redistributed without any moderation or censoring. This is the preferred mode of operation. This mode of operation is dependent upon those making submissions to follow the above guidance. The AJPO welcomes any further suggestions and comments on the use and operation of INFO-Ada. Please direct such messages to the administrator of INFO-Ada via info-ada-request@ada20.isi.edu. Virginia Castor (Director, AJPO) 6. COSMIC - A NASA Software Repository From: Rick Conn <RCONN@SIMTEL20> Subject: NASA's COSMIC To: ada-sw@SIMTEL20 Under contract with NASA, the University of Georgia maintains a Computer Software Management and Information Center (COSMIC). COSMIC implements the NASA policy to make available copies of NASA-developed computer programs and related documentation to potential users. COSMIC publishes a catalog of over 300 pages describing available software and its nominal price. COSMIC's address is: COSMIC The University of Georgia Computer Services Annex Athens, GA 30602 Phone: 404/542-3265 ---------------------------------------------------------------------------- V. NEW SUBMISSIONS TO THE ASR 1. PD:<ADA.POINTERS> Bytes(SZ) ADAPLANS.INF.5 47763(7) -- (Jan 15) lists planned Ada implementations COMPILERS.INF.10 29287(7) -- (Mar 1) lists 59 currently-validated Ada Compilers 2. PD:<ADA.EDUCATION> Bytes(SZ) TEXTBOOKS.BIB.4 9163(7) -- a list of Ada language textbooks, alphabetized by title .DOC.4 87973(7) -- abstracts of many of the above texts 3. PD:<ADA.POINTERS> Bytes(SZ) ADAINF.INF.1 16553(7) -- a list of Ada-related documents, incl gov't agency from which each is available .pa 4. PD:<ADA.NEWS> Bytes(SZ) AIC44.DOC.1 32581(7) -- Vol IV, No 4 (Dec 86) issue of the Ada Information Clearinghouse Newsletter ============================================================================== 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