Programmer's ROM - The Computer Language Library

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

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

Wrap

Text File | 1988-05-03 | 69.4 KB | 1,533 lines

||||||||||||||||||||||||| ||||||||||||||||||||||||| ||||||||||||||||||||||||| ||||||||||||||||||||||||| ||||||||||||||||||||||||| Technical Report on Tools Designed by Texas Instruments ========================= Forms Generator Spelling Checker Style Checker Virtual Terminal Prepared for: ||||||||||||||||||||||||| ||||||||||||||||||||||||| NAVAL OCEAN SYSTEMS CENTER (NOSC) ||||||||||||||||||||||||| United States Navy ||||||||||||||||||||||||| San Diego, Ca 92152 ||||||||||||||||||||||||| ||||||||||||||||||||||||| Contract No. N66001-84-R-0030 ||||||||||||||||||||||||| ||||||||||||||||||||||||| ||||||||||||||||||||||||| ||||||||||||||||||||||||| ||||||||||||||||||||||||| ||||||||||||||||||||||||| ||||||||||||||||||||||||| ||||||||||||||||||||||||| ||||||||||||||||||||||||| ||||||||||||||||||||||||| ||||||||||||||||||||||||| ||||||||||||||||||||||||| ||||||||||||||||||||||||| ||||||||||||||||||||||||| ||||||||||||||||||||||||| ||||||||||||||||||||||||| ||||||||||||||||||||||||| Equipment Group - ACSL ||||||||||||||||||||||||| P.O. Box 801, M.S. 8007 ||||||||||||||||||||||||| McKinney, Texas 75069 ||||||||||||||||||||||||| 15 April 1985 ||||||||||||||||||||||||| ||||||||||||||||||||||||| TEXAS INSTRUMENTS INCORPORATED ||||||||||||||||||||||||| ||||||||||||||||||||||||| ||||||||||||||||||||||||| ||||||||||||||||||||||||| ||||||||||||||||||||||||| CONTENTS CHAPTER 1 INTRODUCTION CHAPTER 2 ADA LANGUAGE DESIGN ISSUES INTRODUCTION . . . . . . . . . . . . . . . . . . . 2-1 VISIBILITY . . . . . . . . . . . . . . . . . . . . 2-1 With/Use Statement . . . . . . . . . . . . . . . 2-1 Renames/Subtype Usage . . . . . . . . . . . . . 2-2 SUBTYPES OF ENUMERATION TYPES . . . . . . . . . . 2-3 "MONGOLIAN HORDES" . . . . . . . . . . . . . . . . 2-4 OVERLOADING . . . . . . . . . . . . . . . . . . . 2-5 USES OF "SEPARATE" . . . . . . . . . . . . . . . . 2-7 Example Of Ideal Use Of Separates . . . . . . . 2-7 Adding Separate Elements To The System . . . . . 2-7 Dangers Of Separates . . . . . . . . . . . . . . 2-7 Separate Supporting Different Implementations Of A Body . . . . . . . . . . . . . . . . . . . . . 2-8 OBJECT-ORIENTED DESIGN AND OFFLOADING . . . . . . 2-8 CHAPTER 3 SOFTWARE PRODUCTIVITY INFORMATION REUSABILITY OF SOFTWARE . . . . . . . . . . . . . 3-1 SOFTWARE LIFE CYCLE LABOR DISTRIBUTION . . . . . . 3-3 PRODUCTIVITY (LOC) . . . . . . . . . . . . . . . . 3-4 CHAPTER 4 IMPLEMENTING IN THE ADA DEVELOPMENT ENVIRONMENT (ADE) INTRODUCTION . . . . . . . . . . . . . . . . . . . 4-1 PERFORMANCE CONSIDERATIONS . . . . . . . . . . . . 4-1 THE DEBUGGER . . . . . . . . . . . . . . . . . . . 4-3 WORKAROUNDS . . . . . . . . . . . . . . . . . . . 4-4 UNCHECKED DEALLOCATION . . . . . . . . . . . . . . 4-5 THE PREDEFINED PACKAGE "CURRENT_EXCEPTION" . . . . 4-5 CHAPTER 5 TRANSPORTABILITY ISSUES INTRODUCTION . . . . . . . . . . . . . . . . . . . 5-1 SYSTEM DEPENDENCIES . . . . . . . . . . . . . . . 5-1 DATA GENERAL VS DIGITAL EQUIPMENT . . . . . . . . 5-1 Physical Transportation Problems . . . . . . . . 5-2 Towers Of Hanoi . . . . . . . . . . . . . . . . 5-2 CHAPTER 6 TOOL EXTENSION TOPICS INTERACTIVE FORM/BATCH GENERATOR . . . . . . . . . 6-1 Automated Form Generation . . . . . . . . . . . 6-1 Page 2 Key Mapping Interface . . . . . . . . . . . . . 6-1 More Display Renditions . . . . . . . . . . . . 6-1 More Field Types . . . . . . . . . . . . . . . . 6-1 STYLE CHECKER . . . . . . . . . . . . . . . . . . 6-2 SPELLING CHECKER . . . . . . . . . . . . . . . . . 6-3 CHAPTER 1 INTRODUCTION Texas Instruments is pleased to submit this final technical report for contract N66001-84-R-0030, Ada(tm) tools for the WIS program. Under this contract, Texas Instruments Ada Technology Branch has developed the following tools: - Ada Style Checker - Virtual Terminal - Batch/Interactive Forms Generator System - Spelling Corrector This report will cover several topics: - Experiences in using various features of the Ada language. - Specific circumstances in implementing these tools on the Data General Ada Development Environment (ADE). - Transportability issues, which will be addressed from the consolidated viewpoint of all the above tools. - Possible tool extensions, addressed for each tool individually. - The software development process used on this contract in terms of productivity (lines of code), activities in the software life cycle, and examples of software reuse. Texas Instruments established a data gathering program at the beginning of this effort in order to make such evaluations possible. CHAPTER 2 ADA LANGUAGE DESIGN ISSUES 2.1 INTRODUCTION This chapter addresses issues pertaining to the design of software written in Ada. These issues include: - the application of visibility - problems in using subtypes of enumeration types - effective application of personnel en masse - overloading - application of separate compilation - object-oriented design and offloading of the design and coding efforts 2.2 VISIBILITY 2.2.1 With/Use Statement The Texas Instruments' Ada Programming Standards recommend the use of the WITH statement without the USE statement. This guideline is recommended for understandability and clarity of locations of program units. Following this guideline produces very long names which helps the understandability of the program unit. However, one undesirable side effect of this guideline is that infix operators are no longer valid for types defined in other packages. Using the function call syntax for operators rather than the infix operator syntax really distracts from the readability of the expression, as shown in the following example: ADA LANGUAGE DESIGN ISSUES Page 2-2 package ENUM_PACKAGE; type ENUM is (VALUE_1, VALUE_2); end; -- without USE procedure EXAMPLE(E : in ENUM_PACKAGE.ENUM) is begin if ENUM_PACKAGE."="(E, ENUM_PACKAGE.VALUE_1) then null; end if; end EXAMPLE; -- with USE with ENUM_PACKAGE; use ENUM_PACKAGE; procedure EXAMPLE(E : in ENUM) is begin if E = VALUE_1 then null; end if; end EXAMPLE; 2.2.2 Renames/Subtype Usage In defining a system of packages, it may be desirable to define a set of global types and constants in a package. Other packages can then be defined which define operations involving objects of these global types. Finally an application routine or package wants to use the operations defined in the intermediate packages. In this case the application routine or package must either WITH the global package which defines the types and constants, or the intermediate package must pass the global information through. The WITH of the global package may not be desirable because we want to hide the existence of the global package to the application routine or packages. Types are normally renamed by using the SUBTYPE statement. Even though an enumeration type is renamed using this mechanism, the value names are not made visible. These values must be made visible by using the CONSTANT statement which defines a new local name for each constant. The following is a simple example of this problem. ADA LANGUAGE DESIGN ISSUES Page 2-3 procedure SUBTYPE_EXAMPLE is package PACKAGE_ONE is type TYPE_ONE is (VALUE_1, VALUE_2); end PACKAGE_ONE; package PACKAGE_TWO is subtype TYPE_TWO is PACKAGE_ONE.TYPE_ONE; VALUE_ONE: constant TYPE_TWO := PACKAGE_ONE.VALUE_1; VALUE_TWO: constant TYPE_TWO := PACKAGE_ONE.VALUE_2; end PACKAGE_TWO; VALUE: PACKAGE_TWO.TYPE_TWO; begin VALUE := PACKAGE_ONE.VALUE_1; VALUE := PACKAGE_TWO.VALUE_TWO; end SUBTYPE_EXAMPLE; 2.3 SUBTYPES OF ENUMERATION TYPES A method that has become increasingly popular is the use of subtypes to "rename" a type from another package. One must be cautious when attempting to use subtypes for this purpose. In particular, one should be aware that the specification of a subtype of an enumeration type does not make the enumeration literals visible. The enumeration literals must be explicitly renamed as in the following example. package HIDDEN_PACKAGE is type ENUMERATION is (ONE, TWO, THREE); end HIDDEN_PACKAGE; with HIDDEN_PACKAGE; package VISIBLE_PACKAGE is subtype ENUMERATION is HIDDEN_PACKAGE.ENUMERATION; function ONE return ENUMERATION renames HIDDEN_PACKAGE.ONE; function TWO return ENUMERATION renames HIDDEN_PACKAGE.TWO; function THREE return ENUMERATION renames HIDDEN_PACKAGE.THREE; end VISIBLE_PACKAGE; The problem with this mechanism is that it not only hides the enumeration literals, but it also hides the ordering information associated with the enumeration literal. The user of ADA LANGUAGE DESIGN ISSUES Page 2-4 VISIBLE_PACKAGE doesn't know whether all of the literals of subtype ENUMERATION are visible or not. Thus, objects of subtype ENUMERATION may have values that the package user cannot express as a literal. 2.4 "MONGOLIAN HORDES" TI was able to successfully apply the "Mongolian hordes" programming approach to the coding of some of the software for the spelling checker tool. Success in this case is measured by the fact that the tool works and was delivered on-time. This showed that adding more programmers to a given task in order to get the task done faster can succeed, but with restrictions. The restrictions: * The design needed to be complete before the programmers could be brought in. All of the interfaces needed to be well-defined between the various packages. Such was not the case originally, and time was expended in resolving several design issues after coding began. * Object-oriented design techniques were applied. This divided the programming effort into a group of packages, each package coded by one programmer and each package providing all the operations on and access to a particular object (such as a document or spelling dictionary). Also, each object-controlling package can be unit-tested extensively by a "testing" person. Two people work on each object-oriented package: one codes and another tests. * Any problems with the interface specifications were ironed out in design reviews, progress reviews, and code walkthroughs. All individuals involved with coding and testing were present at the reviews, and a package of common constants and interface parameters was developed and made available to all coders at this time. Package interface definitions were rigidly enforced, and any changes to these interfaces were carefully considered and discussed during these reviews. The spelling corrector was the only tool this technique was applied to. Unlike the other three tools worked on by TI, the spelling corrector encountered problems with personnel turnover (including the loss of one designer/programmer and a change in leadership on the tool) and a gap in schedule in which no work was done. The spelling corrector project had many more code walkthroughs than the other three projects. Note that its productivity figures (see Chapter 3 of this report) significantly differ from the other three tools. Some key differences are: ADA LANGUAGE DESIGN ISSUES Page 2-5 Metric Spelling Corrector Other Tools (Average) ================== ================== ===================== Lines of Source Code (semicolons) per Day 14.5 17.4 Lines of Source Code (semicolons) per Manmonth 311.0 374.2 Comment Lines 2626 1437 (590 to 2013) Conclusions: * Productivity was lower for the "Mongolian hordes" application, but it was still relatively high (versus some "rule of thumb" figures of 7 or 8 LOC/day). * Inline documentation was greater for the "Mongolian hordes" application. Perhaps this was caused by the greater need for each coder and tester to communicate with each other and to document the interfaces as precisely as possible. * The application of "Mongolian hordes" can work if the circumstances are right. * A contractor does not want to find himself in the position of having to apply this technique on a project. If the situation arises, Ada provides a good mechanism to help achieve success. 2.5 OVERLOADING One of the often criticized features of Ada is that the output facilities are very rigid and the predefined I/O facilities are limited. Experience producing an output report has shown us that this need not be so. Overloading subprograms and good use of default parameters can create I/O which is much easier to use than the predefined TEXT_IO functions. In the process of producing the Style Checker output, a set of output routines supporting various formats were created (see the following code for examples). These were all given the same overloaded name. Whenever possible, the parameters of these subprograms were given default values. These allowed us to produce general output lines in a variety of formats without having to do multiple detailed TEXT_IO.PUTs to generate each line. ADA LANGUAGE DESIGN ISSUES Page 2-6 procedure PUT_REPORT_LINE(INDENTION : in NATURAL; HEADER : in STRING; ASTERIK_NEEDED : in BOOLEAN := FALSE; EXCLAMATION_NEEDED: in BOOLEAN := FALSE) is procedure PUT_REPORT_LINE(INDENTION : in NATURAL; STYLE_ISSUE : in STRING; SUB_HEADING : in STRING; LEAD_IN : in CHARACTER; COUNT : in NATURAL; UNITS : in STRING; ASTERIK_NEEDED : in BOOLEAN := FALSE; EXCLAMATION_NEEDED: in BOOLEAN := FALSE) is procedure PUT_REPORT_LINE(INDENTION : in NATURAL; STYLE_ISSUE : in STRING; SUB_HEADING : in STRING; LEAD_IN : in CHARACTER; COUNT : in FLOAT; UNITS : in STRING; ASTERIK_NEEDED : in BOOLEAN := FALSE; EXCLAMATION_NEEDED: in BOOLEAN := FALSE) is procedure PUT_REPORT_LINE(INDENTION : in NATURAL; STYLE_ISSUE : in STRING; SUB_HEADING : in STRING; LOWER_BOUND : in NATURAL; UPPER_BOUND : in NATURAL; UNITS : in STRING; ASTERIK_NEEDED : in BOOLEAN := FALSE; EXCLAMATION_NEEDED: in BOOLEAN := FALSE) is procedure PUT_REPORT_LINE( KEYWORD_REPORT : in STYLE_PARAMETERS.KEYWORD_USE_DESCRIPT; KEYWORD_COUNT : in NATURAL; KEYWORD_USAGE : in FLOAT; KEYWORD_TYPE : in TOKENIZER.TOKEN_TYPE) is This allows easy output without the user having to worry about detailed formatting problems. If used indiscriminately, overloading can make a program unreadable by allowing different operations to be called with the same name. In our case, all the functions were performing the same operation, merely with different types on inputs and with slightly different formats. Overloading can be useful if functions are being created which perform the same operation with only minor variations, where these variations are not likely to become confused. ADA LANGUAGE DESIGN ISSUES Page 2-7 2.6 USES OF "SEPARATE" The "separate" capability allows a subunit to be compiled independently from the parent unit. The separate feature eases program development once the user realizes that the separate unit must be compiled AFTER the parent unit is compiled. Poorly used separates (used in a poorly planned development) can cause the process of compilation to become confusing and difficult. Well used separates can make the process of modifying a system simple. 2.6.1 Example Of Ideal Use Of Separates The ideal use for separates is to enable easy top-down development of a well-designed system. A candidate system would be a large unit which contains many smaller subunits. In a small system, or one where most of the system consists of "withed" packages, it is not as important to break out pieces for separate compilation. The top level of this system should be well-defined, especially the interfaces. To start development, the top level is composed, including "is separate" references to ALL the subunits. A null stub for each of the separate subunits is created. Now the system can be compiled. There may be no functionality to the system, but it can be incrementally developed. 2.6.2 Adding Separate Elements To The System When the user is ready, any of the separate subunits can be developed. To add this to the system it is only necessary to compile the subunit and re-link the system. If the separate decomposition has been done properly, the addition of subunits can be done easily. Note that the entire system did not have to be recompiled when another subunit was added. This is the advantage of separates in that adding to the system only requires compiling the new subunit and linking! 2.6.3 Dangers Of Separates The goal of separates is to allow changes without massive recompilation. If the parent unit is not well specified and frequent changes are necessary to that unit, even more compilation will be necessary. Each time the parent unit is changed, all of the separate subunits have to be compiled again. The parent unit must be well-defined for separate compilation to be productive. ADA LANGUAGE DESIGN ISSUES Page 2-8 2.6.4 Separate Supporting Different Implementations Of A Body Another possible use of separate would be to allow a change in an implementation merely by relinking. This would be done by having a fixed specification to a unit and have different separate bodies in different libraries. Then the implementation methods would depend on which of the libraries was used to link the system. An example of this might be to have bodies of two sort procedures using different methods available. The user could choose which type of sort to use by selecting the library from which to link. Unfortunately this was not available for our use since the Data General Ada Development Environment does not support bodies which exist in different libraries than their specifications. 2.7 OBJECT-ORIENTED DESIGN AND OFFLOADING Offloading is the delegation of segments of a project to separate computers, such as personal computers. This reduces the load on main computers and may increase productivity by increasing the responsiveness of the computer to the user and providing the user with a dedicated resource. With the reduction in hardware costs and the increase in personnel costs, offloading may be a cost-effective approach to software development. For very large projects, especially when a good CM system or library management system is NOT available to keep the libraries in sync, offloading may not be feasible. However, there are many situations in which offloading (at least during unit coding and testing) is quite feasible. In the Spelling Checker program, a small- to medium-sized effort, the design was oriented around two major objects: the DOCUMENT to be checked and the DICTIONARY (there can be more than one) to check against. There are two packages which deal with these objects, DOCUMENT_HANDLER and DICTIONARY_MANAGER, and each package was assigned to one person to code and unit test. The specifications, which, of course, were subject to change, were planned during the design phase, and the development (including coding and unit testing) of the bodies was done in complete independence. Such development could easily have been offloaded to a PC if an Ada compiler existed for one. The only requirement for this would be that the MACHINE_DEPENDENCIES packages be duplicated on each PC. Each package was in complete control of its object; the DOCUMENT_HANDLER was given the name of a file containing a document and provided words and context information to its user. The DOCUMENT_HANDLER is the object manipulator of objects known as documents (which realize physical implementations as files). The user was never concerned with details of document structure or manipulation. ADA LANGUAGE DESIGN ISSUES Page 2-9 The object-oriented design approach is useful: * It localizes problem areas. When a bug is reported, the source of the bug can be quickly isolated to a particular object manipulator. * It supports complete unit testing. If the interfaces are well-known and each unit is thoroughly tested, the later integration can go quite smoothly. TI has had noticable success in this area in its design of the NOSC tools, particularly the spelling checker which was designed by five people over the course of the project and integrated in half a day. * It provides a clean break for division of the work. Each object manipulator is independent of the other routines in the system and its interface is well-defined. Hence, one person could design and code it without interfacing with others until integration time. The second point supports offloading. The object manipulator can be designed on a personal computer and tested with a validated Ada compiler on that PC. Test programs can be written locally, and the object manipulator can be unit tested extensively. Once complete, it can be uploaded to the host computer for integration into the system and system testing. The cost savings of this development technique can be substantial. Many Ada compilations can be performed on the personal computer at a less cost than those performed on the host machine. Also, the productivity of the designer and coder can be greater due to the increased availability and dedication of the personal computer resource. CHAPTER 3 SOFTWARE PRODUCTIVITY INFORMATION In this chapter, Texas Instruments reports on Software life cycle labor distribution (as gathered from our labor collection system), productivity (LOC) and experiences with software reuse. 3.1 REUSABILITY OF SOFTWARE Reusability of software played a useful role in the development of the NOSC tools. Ada software written for other projects was imported (in some cases without modification) into the NOSC tools, and software written for one tool was sometimes used on another. Some requirements had to be met in order for this reusability to be feasible for this contract (which was only of six months duration): * The existence of the software had to be known. There was not time during the project to search for whatever software was available and then determine if it was suitable for application. Designers/programmers had to know in advance that the software was available, what it did, and if it was general-purpose enough to be reusable. A minimum of effort had to be expended in order to determine this information. * The reliability of the software had to be assured. The designers/programmers had to be sure that the software would work as advertised. It was not desirable to spend time in debugging software components which were supposedly "correct." The following are some recommendations for those readers considering the establishment of a repository of Ada software components. * A small team of individuals should be formed to act as a filter for the local repository. The team's purpose is to examine incoming software, test it, examine its documentation, and document it in a standard fashion. SOFTWARE PRODUCTIVITY INFORMATION Page 3-2 * Software for the repository can come from a variety of sources. These include the Ada Repository on the SIMTEL20 host computer of the DoD's Defense Data Network, company projects and contracts, commercial software repositories, and individual contributions. * The repository should contain at least two classes of software. The first is the software component, which is mainly generic in nature and can be instantiated for a variety of applications. The second is the software tool, which can be used to assist the software designer/programmer in a variety of ways, including the reduction of his documentation overhead and the adoption of standards (with as little additional overhead imposed as possible) that aid in creating more reusable, maintainable software. * The activity of the repository team should be performed before a project is undertaken and assumed as overhead (for all projects) by the organization. This overhead investment could result in substantial schedule and cost savings in the long run, and it has to be viewed as a long-term investment. Of the software which was reused during the development of the NOSC tools, the online documentation system (HELP) was the most significant. This system was used for both the Spelling Checker/Corrector and Style Checker tools. Originally developed for the AIM (APSE Interative Monitor) project at TI, the HELP system was imported and adapted to both tools in approximately two man-days. No new development was required, and relatively little redesign was involved. The size of the HELP system is illustrated in the following table: File Name Statements Comments Lines HELPINFO_SPEC.ADA 40 59 146 HELPINFO_BODY.ADA 62 104 239 HELP_SPEC.ADA 12 27 51 HELP_BODY.ADA 42 31 117 HELP_DIS_ALL.ADA 17 26 66 HELP_EXIT.ADA 5 26 41 HELP_FIND.ADA 21 30 86 HELP_GET.ADA 25 23 81 HELP_INIT.ADA 69 67 238 HELP_ME.ADA 99 76 328 HELP_MENU.ADA 47 44 165 HELP_PROMPT.ADA 27 34 110 HELP_RESET.ADA 4 25 39 HELP_TEXT.ADA 7 23 43 HELP_FILE_SPEC.ADA 11 22 37 HELP_FILE_BODY.ADA 33 25 95 ==== ==== ==== Totals => 521 642 1882 SOFTWARE PRODUCTIVITY INFORMATION Page 3-3 This is significant in that several manmonths worth of work was saved via reuse. The HELP system, however, was not originally designed with reuse in mind. Some components of the NOSC tools designed by TI were designed with the intention of reusing them, and, as was observed by reusing the components designed for one tool in other tools, the overhead of reusing these components in the future will be even less than that observed with the HELP system. Some of the software components employed in the NOSC tool designs which were originally designed for general-purpose use at an earlier time included the following: File Name Statements Comments Lines character_set.ada 162 34 301 cline_handler.ada 20 26 74 cline_iface.ada 119 109 317 ==== ==== ==== Totals => 301 169 692 3.2 SOFTWARE LIFE CYCLE LABOR DISTRIBUTION In order that proper tracking of project hours could be accomplished, we established labor categories reflective of the SW life cycle within our labor reporting system. As the engineers advanced thru the life cycle, time was charged to the charge number corresponding to the phase. Analysis of the data indicates hours were spent as follows. Several numbers in this data may appear suspect; this is how the labor system recorded it; the accuracy of this data is subject to the normal problem of humans inputting the correct data. Virtual Spelling Style Batch/Forms Terminal Corrector Checker Generator ======== ========= ======= =========== Requirements System Spec 11 Preliminary Design 458 416 397 Users manual 16 100 35 35 Detailed design 344 40 148 223 Implementation 634 604 517 559 Training 8 8 12 8 Integration 4 Qaulity Assurance 26 Testing 594 226 273 79 Data management 4 Configuration Mgt 1 3 3 1 ------------------ Sub Total 1627 1450 1404 1306 Program Management 76 76 75 75 ------------------ Grand Total 1703 1526 1479 1381 Manmonths 9.84 8.82 8.58 7.98 SOFTWARE PRODUCTIVITY INFORMATION Page 3-4 While a manmonth is contractually approximated at 173 hours, many hours in excess of an 8 hour day were worked. Since this program was managed as 1 contract with 4 task elements, program management time was accumulated as an aggregate; the hours spent are allocatable to the whole program, not any one tool in particular. Total program management hours was 303. In the above table, these hours were allocated equally across each tool. Requirements and System specification had little charges because the proposals written for these tools were written with the intent that they serve as the requirements and specifications documents Configuration management is low because some of the CM function was handled by a support group (not allocated to this project) and some was accomplished after the data was extracted for this report. In any case, all Software and documents have been CM'd and a retrievable according to standard TI procedures. 3.3 PRODUCTIVITY (LOC) TI used the PAGER tool from the Ada repository as a vehicle by which to count Ada statements, comments and total text lines in the tools. This tool considers an Ada statement to be terminated by a semicolon. As such, a text line can contain one Ada comment, one or more Ada statements, or one or more Ada statements and an Ada comment. Following is a table indicating the lines of Ada source, comments, text lines and testing code in each of the tools written. Note that in the batch/form generator and the virtual terminal, testing code had to be written to exercise the various interfaces; this code was also written in Ada. SOFTWARE PRODUCTIVITY INFORMATION Page 3-5 Virtual Spelling Style Batch/Forms Terminal Corrector Checker Generator ======== ========= ======= =========== Ada Source: 2421 2743 3189 2869 Comments: 590 2626 2013 1707 Text Lines: 6300 9458 9762 8307 Test Source 1218 163 Comments: 155 200 Text Lines: 1762 1398 --------- Totals: Ada Source: 3639 2743 3189 3032 Comments: 745 2626 2013 1907 Text Lines: 8062 9458 9762 9705 Any figures regarding lines of code/day must consider the way lines of code is determined. Some techiques consider every text line in a program to be a line for measurement purpose, others only count executable statements and exclude comments and data definition. Since there seems to be no universal agreement on the proper technique, for the purposes of this report, we will compute LOC based on both the total number of text lines and the total number of Ada source statements. In all cases, testing code will be counted. Virtual Spelling Style Batch/Forms Terminal Corrector Checker Generator ======== ========= ======= =========== Ada Source: 3639 2743 3189 3032 manmonths 9.84 8.82 8.55 7.98 LOC/mm 369.8 311.0 372.98 379.9 LOC/day 17.2 14.46 17.34 17.67 Text Lines: 8062 9458 9762 9705 manmonths 9.84 8.82 8.55 7.98 LOC/mm 819.3 1072.3 1141.75 1216.16 LOC/day 38.13 49.87 53.10 56.56 LOC/day assumes 21.5 work days per month. It should be noted that these tools did require some Mil-Std documentation, such as design specs, test plans/procedures, users manuals. Where nothing was mandated in the CDRL list, internal TI documentation standards were used. CHAPTER 4 IMPLEMENTING IN THE ADA DEVELOPMENT ENVIRONMENT (ADE) 4.1 INTRODUCTION The software written by TI under this contract was written on a Data General MV10000 under the ROLM Ada Development Environment (ADE) version 2.2. This environment includes a validated Ada compiler, a symbolic debugger, a pretty-printer, and some other tools. This chapter discusses some items of interest in working under the ADE. 4.2 PERFORMANCE CONSIDERATIONS Many things may influence performance of developed software. 1. inherent algorithmic complexity, 2. quality and size of the compiler-generated object code, 3. coding techniques, 4. options specified to suppress certain boundary and range checking code when compiling and linking. While developing software in the Ada Development Environment, these performace consideration arose. The Data General Ada compiler and linker presently have some significant problems that impact the performance of software compiled and linked using them. It is our understanding that DG has plans to remedy many of these problems in upcoming releases. 1. Static storage allocation. The DG Ada compiler/linker generates one 32-bit word for every elementary data object. In addition to requiring large amounts of storage, such storage allocation causes performance degradation, extra software to be written, and productivity decreases as system developers had to determine storage allocation figures, interfaces with system services, etc. Even boolean objects occupy 1 32-bit word! Arrays of any kind have a 16-word (32 bits each) overhead associated with them. Strings are stored as an array of characters, each character occupying the upper IMPLEMENTING IN THE ADA DEVELOPMENT ENVIRONMENT (ADE) Page 4-2 8-bits of a 32-bit word, each array having that 16-word overhead. When making calls to system services, strings had to be packed to pass in, and unpacked when returned. When performing slice assignment and passing slices as parameters, it is expensive to move 4 to 32 times as much storage around as actually is required. 2. Dynamic storage allocation. The Ada run-time support for Ada programs does not recover lost storage. Neither does unchecked_deallocation work. And, aggregates are constructed from heap space that is not automatically deallocated after use. This caused the storage_error exception to be raised often. 3. Pragma INLINE. Performance should be enhanced with the use of the pragma inline. However, we found the debugger had extensive problems when dealing with procedures that were marked as in_line'able. It couldn't recognize that they existed and tended to make the program completely unrecognizable in the debugger. 4. DG Tasking. Performing an Input/Output operation on a terminal causes not only the task requesting the operation, but the entire program to block until completion of the operation. 5. DG System Services. The System Services were for the most part undocumented, making discovery of how to access the services very difficult. Access to the services was compounded by the lack of representation specifications that were necessary for using some of the system services. 6. Representation Specifications. The "optional" Ada feature of representation specifications was not operational on the DG. 7. Unchecked_conversion. It is a useful practice when building interface libraries to build on other existing packages. For example, two specs to consider: IMPLEMENTING IN THE ADA DEVELOPMENT ENVIRONMENT (ADE) Page 4-3 PACKAGE early_interface IS TYPE color IS (blue, red, green); PROCEDURE a( a_color : IN OUT color ); FUNCTION b RETURN color; END early_interface; -- ---------------------------------- PACKAGE newer_interface IS TYPE color IS (blue, red, green); PROCEDURE a( a_color : IN OUT color ); FUNCTION my_new_function RETURN positive; END newer_interface; What we have here is a early interface that contains a procedure we want to make visible in the newer_interface. However we do not want to have the spec of newer_interface WITH the spec of early_interface and, we do not want to change the early interface. So, we can define identical named types and procedures in the newer_interface providing a "window" into the early interface. In the body of newer_interface we should simply type convert the newer_interface types into the early_interface types and pass them along. This cannot be done in the DG Ada compiler. Unchecked_conversion does not work and it will not simply convert using the standard Ada syntax. The error message states simply "cannot convert". There can be a severe performance penalty in converting a structure with arrays and records and combinations of arrays and records. 4.3 THE DEBUGGER The debugger proved to be an absolutely invaluable tool in producing debugged code. Among the many capabilities of the DG debugger are: * evaluating the values of objects and changing them, IMPLEMENTING IN THE ADA DEVELOPMENT ENVIRONMENT (ADE) Page 4-4 * reading debugger scripts from files, * assigning a "logical" name to a long identifier making debugging fast and the chance for typing errors small, * displaying the program as reconstructed from the Diana intermediate form (comments removed, code reformatted), * displaying the calling stack, * tracing down through pointer references to the objects that they point to, * examining tasks and their execution characteristics, * forking back to the CLI to perform some operations (like debugger script creation) then coming back into the debugger into the same location that you were originally, With this tool in place, the debugging of Ada programs became an absolute breeze. It became even more important in the testing phase when the errors were insidious and difficult to track down. There were far fewer compiles and links, and little effort was made to include such debugging aids as put_line's and the like. There simply was no need. In summary, an Ada source level debugger can significantly increase the productivity of programmers. 4.4 WORKAROUNDS Some basic problems and inconsistencies continue to present themselves in the use of TEXT_IO. One particular problem is that GET_LINE from the console is not implemented in the same way for all Ada compilers. GET_LINE for DEC Ada, for example, permits editing of the input before it is accepted (delete previous character, delete entire entry, etc, are allowed). GET_LINE for the Ada in the ROLM ADE does not, and this was "worked around" by writing an implementation of GET_LINE which had the same specification as GET_LINE for TEXT_IO. This new GET_LINE used a SYSDEP (System Dependencies) package for I/O support, so immediate single-character I/O without echo was assured. Yet another workaround was in providing a GET character for files which had the same specification as the GET in TEXT_IO but returned the ASCII.CR character when the end of a line was encountered. To complement this, an UNGET was also implemented. GET and UNGET combine very conveniently in parsing algorithms and greatly simplify the algorithm in some cases (similar to algorithms commonly used under UNIX which employ GET_CHAR and UNGET_CHAR). IMPLEMENTING IN THE ADA DEVELOPMENT ENVIRONMENT (ADE) Page 4-5 The following problems in the DG Ada compiler were "worked around" in order to get the Virtual Terminal software to execute: * END_ERROR raised incorrectly for text files * Poor elimination of constraint checking * /SUPPRESS option raises exceptions * Placing the specification in one library and the body in another does not work 4.5 UNCHECKED DEALLOCATION UNCHECKED_DEALLOCATION is not implemented under the ADE. Consequently, releasing of objects created dynamically was not possible. To maintain compatability with other Ada compilers for which this feature is available, UNCHECKED_DEALLOCATION is implemented as a procedure stub which includes a comment as to what the proper implementation should be. 4.6 THE PREDEFINED PACKAGE "CURRENT_EXCEPTION" The Data General Ada Development Environment supplies a package which has proved very useful to debugging. The package CURRENT__EXCEPTION supplies a value: CURRENT__EXCEPTION.NAME which contains the description of an exception when it has been raised. To use this, as a default for the exception handler use: exception when others => TEXT_IO.PUT("Inside procedure X -- exception: "); TEXT_IO.PUT_LINE(CURRENT_EXCEPTION.NAME); raise; Whenever a program arrives at an unanticipated error, this exception handler will output the name of the exception and its location. Then it raises the exception and it should trace its exit path. This provides immediate debug information without having to add any extra code. The disadvantage of this is that CURRENT__EXCEPTION is not a standard package, and when the source is transported, the CURRENT__EXCEPTION references have to be removed. CHAPTER 5 TRANSPORTABILITY ISSUES 5.1 INTRODUCTION Texas Instruments Ada Technology Branch has a Data General MV10000 (running the ROLM Ada Development Environment) and a Digital Equipment Corporation VAX 11/785 (running the beta test version of the DEC Ada compiler). This environment allowed us to examine first-hand some of the problems encountered in transporting Ada software from one host computer environment to another. 5.2 SYSTEM DEPENDENCIES A standard design technique used by TI on these tools has been to evaluate system dependencies in one (or a set of) packages. Using this technique significantly enhances the transportability of the program (or package or tool set) since all changable items are localized. System dependencies includes such things as: * file names and forms, * operating system calls, * underlying implementation assumptions (such as word size and representation, floating point accuracy, etc), * system specific Ada packages (see the section on current_exception). 5.3 DATA GENERAL VS DIGITAL EQUIPMENT The transportation of software between two dissimilar host computers presents a variety of problems. TI ported several pieces of Ada software between the Data General MV10000 and the DEC VAX 11/785, and the following outlines some of the problems encountered. TRANSPORTABILITY ISSUES Page 5-2 5.3.1 Physical Transportation Problems The problem of physically transporting the software between these two machines was resolved in two ways. The first was the use of a personal computer as an intermediary, and the second was the use of magnetic tape as the tranfer medium. TI has its DG MV10000, its DEC VAX 11/785, and numerous TVI970 terminals and TIPC computers interconnected via a local area network (LAN). This LAN provided a reliable, noise-free communication path which proved to be a useful medium for the transfer of files between the two host computers. By simply typing out a file on the DG and recording the screen displays on a personal computer via a communications program, the file could be transferred from the DG to the PC. Once on the PC, the file could then be uploaded to the DEC via the KERMIT file transfer protocol. Due to buffer overflows on the DEC, uploading via a "type" transfer is not feasible. KERMIT cannot (yet) be used on both ends because the only available KERMIT implementation for the DG is written in FORTRAN, and we do not have a FORTRAN compiler on the DG. In performing tape transfers between the two machines, the tape formats are incompatable, so a program had to be written to read tapes (only one file allowed per tape) created on the DG. The PAGER tool, which concatenates several files into one larger file, was used to create a file on the DG and then to disassemble it on the DEC. In both cases, the validity of the file transfer could always be questioned. PAGER provided a mechanism to check such validity. PAGER can compute a checksum of the file on the DG and then compute a checksum of the file after transfer to the DEC. If the checksums match, the file transfer can assumed to have been successful. PAGER also counts the number of Ada statements, Ada comments, and text lines in the file. 5.3.2 Towers Of Hanoi During the development of the NOSC tools, the issue of code quality and efficiency of generated code came up. Having a beta test copy of the DEC Ada compiler and an official Data General ADE we wished to compare them. The first attempt at this comparision was to compile and execute an identical program on both. The program we selected was a recursive implementation of the Towers of Hanoi problem. The program consists of two packages, a vt100 routine (83 lines) and the Towers of Hanoi package (213 lines). The execution of the two programs was observed by running the same program on both machines on adjacent terminals. The VAX version ran significantly faster (at least twice as fast for a tower of 8 disks). This difference could be attributed to ineffeciencies in the implementation of TEXT_IO, in the call handling overhead, and some of the factors indicated in section 4.2. Further analysis is necessary. CHAPTER 6 TOOL EXTENSION TOPICS This chapter briefly addresses some additional ideas about capabilities which could be included in each of these tools. 6.1 INTERACTIVE FORM/BATCH GENERATOR 6.1.1 Automated Form Generation An automated means of generating forms was suggested by Col. Whitaker at our Critical Design Review. One way of accomplishing this would be to write an Ada declaration processor which would take record type declarations and build the forms which correspond to them. For instance the types of the individual fields could be used to specify valid values for the fields. 6.1.2 Key Mapping Interface Currently the mapping from terminal keys to internal Form Generator functions is handled via the Terminal Capabilities File (TCF) of the Virtual Terminal (VT). A special entry named "fgs" is used to map key sequences to VT functions and in turn Form Generator functions. A user interface could be developed to assist in the building of the TCF. This utility could prompt for the key sequence to enable each internal function. This would then be used to build the entries in the TCF. 6.1.3 More Display Renditions Currently the Virtual Terminal (VT) only supports Normal and Reverse display renditions. Logically it could support more as long as the terminal interface supported them. Some terminals support highlighted, underline, and blinking fields as well as colors. An invisible rendition was suggested by Col. Whitaker for entering things like passwords. 6.1.4 More Field Types Currently the Form Generator supports Alphabetic, Alphanumeric, Numeric, and Not Limited input character types. The numeric field types could be enhanced to differentiate between integer, floating point, and fixed point. General arithmetic expression handling TOOL EXTENSION TOPICS Page 6-2 could be added. Numeric fields could be restricted to a range of values. Any field could be given a list of valid values which could be entered. 6.2 STYLE CHECKER The possible set of style characteristics which could be checked is large. What seemed to be the most important were included in the delivered Style Checker, however there were others which surfaced during the project and were not able to be implemented within the delivery time. This notes the most important of the possible extensions to the style. 1. Better Universal checking. The current system counts the number of universals versus all other types. The measurement of all other types is still vague. This definition could be made more specific. The universal checking for integer, float, and boolean or enumeration types could be done individually. 2. Scope. Processing to determine the scope of part of the input would add the possibility to add other style checks. The first check might be to measure the number of local objects used in a subprogram vs. the number of global references. This gives a measurement of independence. Scoping would make it possible to do other metrics involving object and type declarations. 3. Comment Indentation. It would be good to include the ability to check the indentation of comments in more flexible fashion. This flexibility is necessary since there are so many different styles of commenting code. 4. Use statement frequency. It would be desirable to check how many "withed" units are also "used". Currently the frequency of "uses" is checked independant of the "withs". 5. Pre-defined Type formatting. It seems common for users to assume predefined types are reserved words. The users then treat them as reserved words for the case of the word and indentation. It might prove useful to add a parameter allowing predefined types to be treated as reserved words. 6. Efficiency. Another measure of a program is its efficiency. This might be a counterpart to the transportability style issues. This would measure input statements, blocks, and units and judge the efficiency of the code. The biggest difficulty here is that the efficiency would be dependent on the compiler and, the efficiency of most compilers is not yet known. 7. Speller. Interface stubs exist to add in the spell-checking tool to check individual variable names against a project dictionary. To add this, the spell-checking packages (dictionary) would have to be obtained, the interfaces should TOOL EXTENSION TOPICS Page 6-3 be checked again, and a dictionary would have to be completed. 8. Metrics. Software metrics could apply to style-checking. The best approach would be to obtain an existing metrics package in Ada (or convert one to Ada) and modify the report generator to include the metrics. 9. Parser. The decision was made early in the style-checker development that it was not necessary to parse all of Ada to obtain the style results. In reality, most of the cases of Ada syntax has to be handled in one place or another. It would make this tool more expandable to have a complete Ada parser driving the style checking. 10. Requirements. It would be useful to use this tool to check several existing Ada projects and see what style features prove of most use, and whether any style features should be discarded. Several times in the development, new style features were added when it became obvious that the new feature was useful. There should be a continuing search for more applicable style features. 11. Handling incorrect Ada. The current style-checker depends on the input being correct Ada code. It would make the system more usable if it were able to handle erroneous Ada code for the input. 12. STYLE Summary. It would be useful if a metric were implemented to summarize the entire style report in one or two numbers. This would be something like: "The Input is 98 percent compliant with the Ada style." 6.3 SPELLING CHECKER Various extensions should be considered for the Spelling Corrector Tool, as indicated below: 1. Since the Master dictionary is quite large (about 45K words) and the present program calls for it all to be read into memory, other techniques should be considered. One technique is that during execution, parts of the dictionary are stored in main memory. When the dictionary is searched the main memory portion would be searched first. If the word was not found in the main memory portion a search of the file would be instituted. When and if the word was located it would be moved to the main memory dictionary. Many algorithms for the search and replace functions are available and are generally used in "cache memory" systems. Such techniques would have significant effect on the representation and structure of the dictionary files on disk. TOOL EXTENSION TOPICS Page 6-4 2. Under the Data General/Rolm Ada Development Environment, which was the development environment used on this tool, UNCHECKED_DEALLOCATION is not implemented. Code implementating a form of garbage collection has been included in the tool but is commented out at this time. Given a compiler which does implement UNCHECKED_DEALLOCATION, a useful extension would be the inclusion of this code as a functional entity. The size of the dictionary structures makes some form of garbage collection mandatory if the tool is to run for any amount of time in any given environment. 3. The idea of defining an abstract entity called a token has already been partially implemented. That is, the Speller team has defined a type called Token Type that is being used by all members of the team. However, the internals of that type are made available to all (i.e. it is not private). The possibility exists of defining this type to be private and of defining the operations that are available for that type in one package. This would ensure that all operations on this type would be performed consistently. Operations that are candidates for inclusion in this extension are: 1. Equality 2. Less than, Greater than 3. Read a token 4. Write a token 5. Convert a string to a token 6. Convert a token to a string This would also allow for the centralizing of operations and ease possible changes to the token definition itself. 4. Reducing storage requirements: As a corollary to the previous suggestion, the problem of the amount of storage could be lessened by the inclusion of a package that allows for the creation of storage through the use of discriminant records. The discriminant used at the creation of each new record node would be the length of the token string. This would lessen the burden placed on the machine's storage capacity by approximately one-half due to varying word lengths. There are various dynamic string packages available which use a similar technique for the storing of data. This extension would necessitate an enhancement of the dynamic string packages and would involve changing the definition of token. TOOL EXTENSION TOPICS Page 6-5 5. The addition of an error reporting file in the Dictionary Manager package should also be considered. At the present time errors in the file data used for the building of dictionary structures are recognized and the particular record discarded so as not to cause problems in the internal structure. These errors are not reported. A dictionary error reporting file could be created within the package and maintained during any given run of the tool. This file could then be read by the user for the purpose of verifying the validity of the dictionary file. Complications could be caused by the various environments and the way that files are created and handled. This file would necessarily be created with each run. The decision pertaining to the extension of the tool in this matter should be made on the basis of the value of the dictionary file information.