As mentioned previously, the need to have accurate and up-to-date documentation available at all times is a primary reason for implementing CASE technology. For example, suppose that specifi cations are produced manually. A member of the development team has no way of telling whether a particular specifi cation document is the current version or an older version. There is no way of knowing if the handwritten changes on that document are part of the current specifi cation or merely a suggestion later rejected. On the other hand, if the
1 The fact that a specifi c CASE tool is cited in this book in no way implies any form of endorsement of that CASE tool by the author or publisher. Each CASE tool mentioned in this book has been included because it is a typical example of the class of CASE tools of which it is an instance.
138 Part A Software Engineering Concepts
specifi cations of the product are produced using a CASE tool, then at any time there is only one copy of the specifi cations, the online version accessed via the CASE tool. Then, if the specifi cations are changed, members of the development team can easily access the document and be sure that they are seeing the current version. In addition, the consistency checker will fl ag any design changes without corresponding changes to the specifi cation document.
Programmers also need online documentation . For example, online help informa-tion must be provided for the operating system, editor, programming language, and so on.
In addition, programmers have to consult manuals of many kinds, such as editor manuals and programming manuals. It is highly desirable that, wherever possible, these manuals be available online. Apart from the convenience of having everything at one’s fi ngertips, it is generally quicker to query by computer than to try to fi nd the appropriate manual and plow through it to fi nd the needed item. In addition, it usually is much easier to update an online manual than to try to fi nd all hard-copy versions of a manual within an organization and make the necessary page changes. As a result, online documentation is likely to be more accurate than hard-copy versions of the same material—another reason for providing online documentation to programmers. An example of such online documentation is the UNIX manual pages [Sobell, 1995]. CASE also can assist with communication among team mem-bers. E-mail is as much a part of an offi ce today as a computer or a fax machine. There are many advantages to e-mail. From the viewpoint of software production, storing copies of all e-mail relevant to a specifi c project in a particular mailbox provides a written record of the decisions made during the project. This can be used to resolve confl icts that may arise later.
Many CASE environments and some CASE workbenches now incorporate e-mail systems.
In other organizations, the e-mail system is implemented via a World Wide Web browser such as Chrome or Firefox. Other tools that are equally essential are spreadsheets and
word processors .
The term coding tools refers to CASE tools such as text editors, debuggers, and pretty printers designed to simplify the programmer’s task, reduce the frustration many program-mers experience in their work, and increase programmer productivity. Before discussing such tools, three defi nitions are required. Programming-in-the-small refers to software development at the level of the code of a single module, whereas programming-in-the-large is software development at the module level [DeRemer and Kron, 1976]. The latter includes aspects such as architectural design and integration. Programming-in-the-many refers to software production by a team. At times, the team works at the module level; at times, at the code level. Accordingly, programming-in-the-many incorporates aspects of both programming-in-the-large and programming-in-the-small.
A structure editor is a text editor that “understands” the implementation language. That is, a structure editor can detect a syntax fault as soon as it has been keyed in by the programmer, speeding the implementation because time is not wasted on futile compilations. Structure edi-tors exist for a wide variety of languages, operating systems, and hardware. Because a structure editor has knowledge of the programming language, it is easy to incorporate a pretty printer (or formatter ) into the editor to ensure that the code always has a good visual appearance.
For example, a pretty printer for C++ ensures that each } is indented the same amount as its corresponding {. Reserved words are automatically put in boldface so that they stand out, and indentation has been designed to aid readability. Nowadays, structure editors of this kind form part of numerous programming workbenches, such as Visual C++ and JBuilder.
sch76183_ch05_124-153.indd 138
sch76183_ch05_124-153.indd 138 04/06/10 6:42 PM04/06/10 6:42 PM
Now consider the problem of invoking a method within the code, only to discover at linkage time that either the method does not exist or it has been wrongly specifi ed in some way. What is needed is for the structure editor to support online interface checking . That is, just as the structure editor has information regarding the name of every variable declared by the programmer, so it must also know the name of every method defi ned within the product. For example, if the programmer enters a call such as
average = dataArray.computeAverage (numberOfValues);
but method computeAverage has not yet been defi ned, then the editor immediately responds with a message such as
Method computeAverage not known
At this point, the programmer is given two choices, either to correct the name of the method or to declare a new method named computeAverage. If the second option is chosen, the programmer also must specify the arguments of the new method. Argument types must be supplied when declaring a new method because the major reason for having online interface checking is precisely to be able to check full interface information, not just the names of methods. A common fault is for method p to call method q passing, say, four arguments, whereas method q has been specifi ed with fi ve arguments. It is more diffi cult to detect the fault when the call correctly uses four arguments, but two of the arguments are transposed. For example, the declaration of method q might be
void q ( fl oat fl oatVar, int intVar, string s1, string s2) whereas the call is
q (intVar, fl oatVar, s1, s2);
The fi rst two arguments have been transposed in the call statement. Java compilers and linkers detect this fault but only when they are invoked later. In contrast, an online inter-face checker immediately detects this and similar faults. In addition, if the editor has a help facility, the programmer can request online information as to the precise arguments of method q before attempting to code the call to q. Better yet, the editor should generate a template for the call, showing the type of each argument. The programmer merely has to replace each formal argument with an actual argument of the correct type.
A major advantage of online interface checking is that hard-to-detect faults caused by calling methods with the wrong number of arguments or arguments of the wrong type are immediately fl agged. Online interface information is important for the effi cient pro-duction of high-quality software, particularly when the software is produced by a team (programming-in-the-many). It is essential that online interface information regarding all code artifacts be available to all programming team members at all times. Furthermore, if one programmer changes the interface of method vaporCheck, perhaps by changing the type of one argument from int to fl oat or by adding an additional argument, then every component that calls vaporCheck must automatically be disabled until the relevant call statements have been altered to refl ect the new state of affairs.
Even with a syntax-directed editor incorporating an online interface checker, the programmer still has to exit from the editor and invoke the compiler and linker. Clearly, there can be no compilation faults, but the compiler still has to be invoked to perform code
140 Part A Software Engineering Concepts
generation. Then the linker has to be called. Again, the programmer can be sure that all external references will be satisfi ed as a consequence of the presence of the online interface checker, but the linker is still needed to link the product. The solution to this is to incorporate an operating system front end within the editor. That is, a programmer should be able to give operating system commands from within the editor. To cause the editor to invoke the compiler, linker, loader, and any other system software needed to cause the code artifact to be executed, the programmer should be able to type a single command, named go or run, or use the mouse to choose the appropriate icon or menu selection. In UNIX, this can be achieved by using the make command (Section 5.11) or by invoking a shell script [Sobell, 1995]. Such front ends can be implemented in other operating systems, as well.
One of the most frustrating computing experiences is for a product to execute for a sec-ond or so, and then terminate abruptly, printing a message such as
Overfl ow at 506
The programmer is working in a high-level language such as Java or C++, not a low-level language like assembler or machine code. But when debugging support is of the Overfl ow at 506 variety, the programmer is forced to examine machine code core dumps, assembler listings, linker listings, and a variety of similar low-level documentation, thereby destroying the whole advantage of programming in a high-level language. A similar situa-tion arises when the only informasitua-tion provided is the infamous UNIX message
Core dumped or the equally uninformative
Segmentation fault Here again, the user is forced to examine low-level information.
In the event of a failure, the message shown in Figure 5.10 is a great improvement over the earlier terse error messages. The programmer immediately can see that the method failed because of an attempt to divide by 0. Even more useful is for the operating system to enter edit mode and automatically display the line at which the failure was detected, line 6, together with the preceding and following four or fi ve lines. The programmer probably can then see what caused the failure and make the necessary changes.
Another type of source-level debugging is tracing. Before the advent of CASE tools, programmers had to insert appropriate print statements into their code by hand that, at execution time, would indicate the line number and the values of relevant variables. This now can be done by giving commands to a source-level debugger that automatically causes trace output to be produced. Even better is an interactive source-level debugger .
OVERFLOW ERROR
Class: cyclotronEnergy Method: performComputation
Line 6: newValue = (oldValue + tempValue) / tempValue;
oldValue = 3.9583 tempValue = 0.0000 FIGURE 5.10
Output from a source-level debugger.
sch76183_ch05_124-153.indd 140
sch76183_ch05_124-153.indd 140 04/06/10 6:42 PM04/06/10 6:42 PM
Suppose that the value of variable escapeVelocity seems to be incorrect and that method computeTrajectory seems to be faulty. Using the interactive source-level debugger, the programmer can set breakpoints in the code. When a breakpoint is reached, execution stops and debugging mode is entered. The programmer now asks the debugger to trace the vari-able escapeVelocity and the method computeTrajectory. That is, every time the value of escapeVelocity subsequently is either used or changed, execution again halts. The program-mer then has the option of entering further debugging commands, for example, to request that the value of a specifi c variable be displayed. Alternatively, the programmer may choose to continue execution in debugging mode or return to normal execution mode. The program-mer similarly can interact with the debugger whenever the method computeTrajectory is entered or exited. Such an interactive source-level debugger offers almost every conceivable type of assistance to the programmer when a product fails. The UNIX debugger dbx is an example of such a CASE tool.
As has been pointed out many times, it is essential that documentation of all kinds be available online. In the case of programmers, all documentation they might need should be accessible from within the editor.
What has now been described—a structure editor with online interface checking capa-bilities, operating system front end, source-level debugger, and online documentation—
constitutes an adequate and effective programming workbench.
This sort of workbench is by no means new. All these features were supported by the FLOW software development workbench as far back as 1980 [Dooley and Schach, 1985].
Therefore, what has been put forward as a minimal but essential programming workbench does not require many years of research before a prototype can be tentatively produced.
Quite the contrary, the necessary technology has been in place for over 30 years, and it is somewhat surprising that there are programmers who still implement code the “old-fash-ioned way,” instead of using a workbench like Sun ONE Studio.
An essential tool, especially when software is developed by a team, is a version-control tool.