The tool provides a number of facilities for building a bug tracking system:
Any software organization large enough to need defined controls over the bug tracking process will find the CASEVision/Tracker tool useful. It is particularly appropriate for those organizations that need to comply with the 2167A standards.
The designer must identify all information required for the bug reporting system and decide on the view(s) to be provided. If different applications are to be run on the same data, then separate PDL files must be created.
The users start up the application by invoking the CASEVision/Tracker tool with the name of the PDL file.
After the bug tracking system is up and running, the administrator (or users with permission) can perform special queries on the bug database, using DML. DML is a high-level query language that uses the following general format:
select | insert | update field1 from bug where field2 = value
There are thus three operators, select, insert, and update, that can operate on the specified field field1 for all bug reports meeting the specified condition. Note that field2 can be the same as field1.
The bug report definitions are entered into a PDL file to be compiled later to produce the application. A PDL file has the general format shown in Figure 12.
FIGURE 12. Format for PDL FIle
fields { a_Id: int; //alpha bug ID Commit_date: short-text; // date Description: long-text; Engineers_pri: int; Newsgroups: short-text; // enum? Priority: one-of P1, P2, P3, P4, P5, OBSERVE; Product: short-text; // product Project: one-of CASE, CASEVision/ClearCase, Coltrane, Explorer, NetVisualyzer, IrisVision, Aspen, Birch, Cypress, Dogwood ...; References: short-text; Resp_engineer: short-text; // list-of person Subject: short-text; Submit_date: short-text; // date Submitter: short-text; // person Type: one-of BUG, RFE, TAKEN, CLOSED, NOTE ...; }
Each declaration shows the field variable on the left and its type on the right. The pre- defined short-text type is used for short one-line fields. The description field requires more space and uses the long-text type. Variables with a defined set of values use the one-of designator followed by the set of values and optionally an ellipsis (...) if the user can enter values outside the set.
For example, in a matrix of fields, the fields are declared in the row in which they appear from left to right. The label for the field is entered first, enclosed in single quotes, followed by the name of the field as declared at the beginning of the PDL file. The following code segment shows the declaration of a typical bug view. Figure 13 ties the code to the resulting view window (Figure 14).
FIGURE 13. Typical Formatting Declarations in the Views Section of a PDL File The view uses the label "AlphabugView." The reason for the label is that there can be multiple views that access the same bug data. Furthermore, the Views menu in the view window uses these labels as selections for displaying the other view windows.
The part of the window directly under the menu bar can be used to display information identifying the current bug report. To use this feature, the designer enters the information inside parentheses following the view label. In the example, the following fields are displayed there: the current bug report's ID, type, engineer, product, a space for formatting, and the priority. These fields are defined in the fields declarations portion of the PDL file.
Below the identification bar is the transition bar, which contains a menu of operations that can be performed on the bug report and the Commit button, which confirms the operation.
Next, the subwindows are defined. In this example, there are two subwindows: "Header" for short entries and "Description" for entries of indeterminable length. Note the use of commas in the "Header" declaration. Commas used in the row declaration define the columns. Where commas are not provided, the fields are displayed, next to each other according to an algorithm that attempts a proportionate fit.
FIGURE 14. View Declaration Code Segment with Resulting Window and Transitions Menu
FIGURE 15. Example of Field Information Type was declared in the PDL file as follows:
Type: one-of BUG, RFE, TAKEN, CLOSED, NOTE ...;
The ellipsis (...) at the end means that entries outside of the set of values provided can be made.
The following code segment shows how the transition entitled SUBMIT is defined for this example:
transitions { . . . SUBMIT(=>Open) { rules { Subject.isSet; Type.isSet; Description.isSet; } actions { Submitter.setValue($USER.value); } } . . . }
As you can see, the SUBMIT transition is declared in the transitions section of the PDL file. Following the declaration of the name, the transition is defined inside parentheses. In this case, SUBMIT changes the state of the bug report from null status (it doesn't exist yet) to "Open". Following the state transition, the rules, if any, are declared inside braces, preceded by the keyword "rules". In this example, SUBMIT requires that a condition called "isSet" be TRUE for the Subject, Type, and Description fields. This simply means that there must be values in these fields for SUBMIT to take place. Finally, the designer defines any actions (effects) that result. The example shows that the submitter field is set automatically to the current user.