Page 1 of 8 Unit-4: System Software Tools
INTRODUCTION
• A software tool is a system program which • Interfaces a program with the entity generating its input data, or • Interfaces the results of a program with the entity consuming them. • The entity generating the data or consuming the results may be: • a program • a human user • a repository of data • a library. • The tasks performed by software tools vary from very simple (e.g., Reformatting Data) to sophisticated one (e.g., Debugging the Program).
SOFTWARE TOOLS RELATED TO PROGRAM DEVELOPMENT
• The fundamental steps in program development are: 1. Program Design, Coding, and Documentation 2. Preparation of Program in Machine-readable Form 3. Program Translation, Linking, and Loading 4. Program Testing and Debugging 5. Performance Tuning 6. Source Code Management and Versioning 7. Reformatting the data and/or results of a program to suit other programs.
Step-3 requires use of Language Processors.
1. Tools for Program Design, Coding, and Documentation
Program generators • A program generator generates a program which performs a set of functions described in its specification. • In specification, a programmer has to only specify what functions a program should perform rather than how the functions should be implemented. • Hence, the use of program generator saves efforts involved in design & coding.
Programming environment • A Programming Environment supports program coding by incorporating (including) awareness of the syntax and semantics of a programming language in an Editor. • Its use saves efforts involved in coding & testing.
2. Tools for Program Entry and Editing
• Text editors or more sophisticated programs (with text editors as front ends) are used for program entry and editing. • The editor works in two modes: the command mode and the data mode. • In the command mode, it only accepts editing commands from a user. In this mode, the user can not enter data. Page 2 of 8 • In the data mode, the user can type in the text to be added. The user cannot perform editing operations in this mode. • One approach to recognize and switch between these two modes is the use of special control keys (e.g., vi Editor of UNIX uses Esc key to switch to the command mode and few data entry operation keys such as i (for Insert) to enter into the data mode from the command mode). • Another popular approach is to use the screen mode (also known as what-you-see-is-what-you-get mode), wherein the editor is in the data mode most of the time. The user can use some special keys (sometimes along with control key) to signify commands to perform some operation (e.g., Turbo Editor on PC).
3. Tools for Program Translation, Linking, and Loading
These tools include Translators and Linkers for a specific programming languages, and Operating System specific Linkers and Loaders.
4. Tools for Program Testing and Debugging
• Important activities which are performed under program testing & debugging are: 1. Selection of several sets of test data 2. Analysis of test results 3. debugging • A test data generator determines the conditions which must be satisfied by program’s input for control to flow along a specific path. • Automated test drivers help in regression testing. Regression testing is performed to verify program’s correctness after each modification. • Debug monitors hemp in obtaining more information for localization of errors.
5. Tools for Program Performance and Tuning
• Efficiency of a program depends on two factors: efficiency of the algorithm and efficiency of the code (which part of code consumes how much of execution time). • It is observed that less than 3% of a program code generally consumes more than 50% of its execution time. • Thus, we should try to improve performance of such parts. • A performance tuning tool helps in identifying such parts. • A profile monitor collects information about the execution behavior of a program.
6. Tools for Source code management & version control
• A program undergoes several modifications while it is being developed and used. • A modification involves changes in many statements and insertion & deletion of statements. • Hence, cancelling modification is a complex task that can not be achieved by simple undo facility of an editor. • A source code management system is a software tool that ensures consistent program modifications. • A version control system maintains: A base version of the program code, and Information about the sequence of modifications made for obtaining each version of the program.
7. Tools for reformatting the data and/or results of a program to suit other programs
These tools include the programs that changes the format of input data so that it can be consumed by a program or the programs that changes the format of output data of a program so that it can be used by other programs. Page 3 of 8 For example, Natural Language Query to SQL converter so that the input can be used by RDBMS (a program) such as Oracle, and “Save As Text File” Option of MS-Word so that the output of MS-Word (a program) can be used by simple editor like Notepad (another program).
SOFTWARE TOOLS RELATED TO USER INTERFACES
USER INTERFACES (UI)
• A UI simplifies the interaction of a user with an application. • UI functionalities have two important aspects: issuing of commands and exchange of data. • A UI can be visualized to have two components: a dialog manager and a presentation manager. • The dialog manager manages the conversations between the user and the application. This involves prompting the user for a command and transmitting the command to the application. The application, then, interprets the user commands and implements them by invoking different modules. • The dialog manager is also responsible for online help and error messages. • The presentation manager displays the data produced by the application in an appropriate manner on the user’s display or printer device. Thus, it is responsible for managing the user’s screen and presenting results.
Structure of a User Interface
• The UI consists of two main components: (1) the presentation manager and (2) the dialog manager. • The presentation manager is responsible for Managing the user’s screen Accepting data and Presenting results. • The dialog manager is responsible for interpreting user commands implementing them by invoking different modules of the application code. error messages and online help functions organizing changes in the visual context of the user. • The following figure shows a UI schematic (diagram) using a standard graphic package.
User Interface
User
Command Dialogs
• Commands are issued to an application through a command dialog. • Command dialogs can be implemented in the following three ways: 1. Command languages 2. Command menus 3. Direct manipulation. Page 4 of 8 • Command Languages are similar to command languages for OS. A command language involves use of a fixed set of commands (some of them accept additional parameters/options). • A practical difficulty in the use of command languages is the need to learn it before using the application. This requires investing (putting) time & efforts by the user. • Online help can provide some relief in the sense that the user need not have to memorize the syntax of the commands. • Command menus provide a direct way to accomplish most of the tasks with the help of menu choices (i.e., a Menu containing commands to perform basic functionalities of the application). • The user need not have to learn and memorize commands. The user can simply select a menu option to execute a specific command. • A hierarchy of menus can be used to guide the user into more detailed functionality. • Pull-down menus and context-sensitive menu further simplifies the use of menu system. Most Turbo compilers use pull down menus. • A direct manipulation system provides the user with a visual display of the universe of the application (part/area of interest to the application, e.g., application data and commands to manipulate these data) • The display shows the important objects in the universe. • Actions or operations over objects are indicated using a pointing device such as a cursor or a mouse. (e.g., Lotus 1-2-3)
Principles of command dialog design Some of the principles of command dialog design to ensure its effectiveness are: 1. Ease of use 2. Consistency in command structure 3. Immediate feedback on user commands 4. Error handling 5. Online help to avoid memorizing command details 6. Undo facility 7. Shortcuts for experienced users
Command menus are better than command languages on the basis of principles 1, 2 and 5. Command languages are better on the basis of principle 7.
Presentation of Data
• Data can be input through free-form typing. • Alternatively, a form filling (Fill-in) approach (by designing appropriate data entry screen) may be used when large volume of data is involved (e.g., so many records are to be collected from users). • Application results (output) can be represented in the form of tables. • Summary data can be presented in the form of graphs, pie charts, etc.
Online Help
• Online help is very important to promote & sustain interest in the use of an application. • It reduces the need for initial learning of commands. • It also avoids distraction (interruption) involved in consulting a printed help document for resolving every doubt. • Online help can be provided in the form of online explanations, demonstrations, tutorials or manuals. • The on line facility should provide efficient way to locate/search the desired information. • Online help can also be provided through context-sensitive help, which directly presents related help options (or help text) depending on the current position of the user in the application.
Hypertext
• Hypertext visualizes a document (or a set of documents) to consist of a hierarchical (or network) arrangement of information units, and provides a variety of means to locate the required information. Page 5 of 8 • A hypertext document is a structured document that consists of text and means to locate related documents/information at different levels of detail. • The means used to point to (locate) related documents/information include • Hyperlinks (means to navigate within document and among the documents) • Tables & indexes • String searching functions and • Backtracking facilities. • Effectiveness of a hypertext document depends on the care with which it is organized. • Various hypertext authoring systems are available to make this task easy. • The WWW is the most extensive example of hypertext documents. It uses HTML and HTTP.
User Interface Management Systems (UIMS)
A User Interface Management System (UIMS) automates the generation of User Interfaces. The UIMS accepts specification of the presentation and dialog semantics to produce the presentation and dialog managers of the UI (User Interface) respectively. The presentation and data managers could be generated programs specific to the presentation and dialog semantics. Alternatively, the presentation and dialog managers could use interpretive schematics to implement the presentation and dialog semantics.
A variety of formalisms have been used to describe dialog semantics. These include grammars, event descriptions and finite state machines.
In a grammar based description, the syntax and semantics of commands are specified in a YACC-like manner. Thus, the interface is activated when a user type in a command.
The event based approach uses a visual model of the interface. A screen with icons is displayed to the user. Selection of an icon by clicking the mouse on it causes an event. The action specified against the event is now performed.
The grammar and event description approaches lack the notion of a sequence of actions. The finite state machine approach can efficiently incorporate this notion. The basic principle in this approach is to associate a finite state machine with each window or each icon. Actions are specified on the basis of conditions involving the states of these machines (concurrent activities in different windows).
In the following we describe two UIMSs using the event description approach.
Menulay
Menulay is an early UIMS using the screen layout as the basis for the dialog model. The UI designer starts by designing the user screen to consist of a set of icons. A semantic action is specified for each icon. This action is performed when the icon is selected. The interface consists of a set of screens. The system generates set of icons tables given the name and description of an icon, and a list of (event, function_id) pair indicating the application function to be called when an event is selected.
Hypercard
This UIMS from Apple incorporates object orientation in event oriented approach. A card has an associated screen layout containing buttons and fields. A button can be selected clicking the mouse on it. A field contains editable text. Each card has a specific background, which itself behaves like a card. Many cards can share the same background. A HyperCard program is thus a hierarchy of cards called a stack. A UI behavior is specified by associating an action, in the form of a HyperTalk script, with each button, field and card. The action for an event is determined by using the hierarchy of cards as an inheritance hierarchy. HyperCard uses an interpretive schematic to implement a UI.
DEBUG MONITORS
Debug monitors provide the following facilities for dynamic Debugging: 1 Setting break points in the program Page 6 of 8 2 Initiating a debug conversion when control reaches a breakpoint 3 Displaying values of variables (Watch) 4 Assigning new values to variables 5 Testing user defined assertion and predicates involving program variables.
The debug monitor function can be easily implemented in an interpreter. However, it should be kept in mind that an interpreter takes more time to execute a program. A Debug monitors therefore rely on the instrumentation of a compile program to implement its functions.
To enable use of debug monitors the user must compile the program under the debug option. The compiler now inserts the following instruction
a few no-op instruction of the form no-op
in place of the no-op instruction preceding no-op 100.
The compiled code for the program execute directly on the CPU until it reaches an . This signifies a debug interrupt. (Alternatively the debug monitor can use a BC ANY, DEBUG_MON instruction instead of
The sequence of the step involved in dynamic debugging of a program is as follows:
1. The user compiles the program under the debug option. The compiler produces two files - the compiled code file and debug information file. 2. The user activates the debug monitor and indicates the name of the program to be debugged. The debug monitor opens the compiled code and debug information file for the program. 3. The user specifies his debug requirements – a list of breakpoints and actions to be performed at breakpoints. The debug monitor instruments the program, and builds a debug table containing the pairs (statement number, debug action). 4. The instrumented program gets control and executes up to a breakpoint. 5. A software interrupt is generated when the
UNIX supports two debuggers – sdb which is PL level debugger and adb which is assembly language debugger. Debug of IBM PC is an object code level debugger.
Producing Debug Information
Classically, localization and removal of errors has been aided by special purpose debug information. Such information can be produced statically by analyzing the source program or dynamically during program execution. Statically produced debug information takes the form of cross reference listings, lists of undefined variables and unreachable statements, etc. All these are useful in determining the cause of a program malfunction. Techniques of data flow analysis are employed to collect such information. Page 7 of 8
Example: the data flow concepts of reaching definitions can be used to determine whether variable x may have a value when execution reaches statement 10 in the following program.
No. Statement 09 …………… 10 Sum : = x + 10; 11 ……………….
If no definitions of x reach statement 10, then x is surely undefined in statement 10. If some definition(s) reach statement 10, then x may have a value when control reaches the statement. Whether x is defined in a specific execution of the program would depend on how control flows during the execution.
Dynamically produced debug information takes the form of value dumps and execution traces produced during the execution of a program. This information helps to determine the execution path followed during an execution and the sequence of values assumed by a variable. Most programming languages provide facilities to produce dynamic debug information.
Example: The following figure illustrates the trace and dump facility supported by most FORTRAN compilers. Debug unit specifies the kind of dynamic debug information desired, and the file in which it is to be written. The at specification is used to enable or disable the production of trace and display data when control reaches a specified statement during program execution.
1. Debug unit () : trace of assignment made to each variable in
Subchk(
) : subscript range check; report error if subscript in any reference to an array in
is out of bounds. 2. At
Trace on : trace is enabled. Trace off : trace is disable. Display : value of variables in the list are written in the debug file.
Figure: trace and dump facility in FORTRAN
Use of trace and dump facilities is cumbersome due to the volume of information produced. To improve the effectiveness of the debugging, it should be possible for the user to dynamically control the production of debug information, i.e., to dynamically specify the trace or dump action. These facilities can be provided by the language compiler or interpreter, or by a language independent tool.
Example: The figure below illustrates the use of dynamic debugging facility supported by many basic interpreters. The programmer can set break points at many statements using the stop on command. The system initiates a debug conversation with the programmer when control reaches any break point during program execution. During a debug conversation, the programmer can display or change value of variables and can set or remove breakpoints.
A debug monitor is software which provides debugging supports for a program. The debug monitor executes the program being debugged under its own control. This provides execution efficiency during debugging. It also enables the monitor to perform dynamically specified debugging action. A debug monitor can be made language independent, in which case it can handle programs written in many languages. The dynamic debugging technique (DDT) of dec-10 is a well known example of this approach. The working principles of debug monitors are discussed in section 8.3. Page 8 of 8
1. Break point and dump facilities: (a) Stop on Sets breakpoint(s) at labeled statement(s). (b) Dump at
display : display value of variables set =
Figure: debugging facilities in basic
PROGRAMMING ENVIRONMENTS
A programming environment is a software that provides integrated facilities for program creation, editing, execution, testing and debugging. It consists of the following components:
1. A syntax directed editor (which is a structure editor) 2. A language processor (a compiler, interpreter or both) 3. A debug monitor 4. A dialog monitor.
All components are accessed through the dialog monitor. The syntax directed editor incorporates a front end for the programming language. As a user keys in his program, the editor performs syntax analysis and converts it into an immediate representation (IR), typically an abstract syntax tree. The compiler (or interpreter) and the debug monitor share the IR. If a compiler is used, it is activated after the editor has converted a statement to IR. The compiler works incrementally to generate code for the statement. Thus, program execution or interpretation can be supported immediately after the last statement has been input. At any time during execution the programmer can interrupt program execution and enter the debug mode or return to the editor. In the latter case he can modify the program and resume or restart its execution.
The main specification for the user is the easy accessibility of all functions through the dialog monitor. The system may also provide other program development and testing functions. For example, it may permit a programmer to execute a partially completed program. The programmer can be alerted if an undeclared variable or an incomplete statement is encountered during execution. The programmer can insert necessary declarations or statements and resume execution. This permits major interfaces in the program to be tested prior to the development of a module. Some programming environments also support reversible execution, whereby a program’s execution can be ‘stepped back’ by one or more statements.