A Degree Audit is performed by comparing a student’s academic record (i.e., the courses they’ve taken, waived or transferred, including grades) against the degree audit object. The rules are considered a Transformation Operation, as they “transform” the original audit object by adding temporary work data to that object. Note in the diagram to the right of the audit object that there are several work attributes, with names starting with lower case “w”, which are defined for the “CourseType1or2” entity, which is highlighted in red. These work attributes are built during the transformation process and are displayed to show the results of the audit.

The input to the process is another object, which contains the student’s current academic record. Actually, the input doesn’t have to be a particular object, but can be any object that contains the correct structure for defining that student’s academic record. It also doesn’t have to contain information only from the database. In order to handle “what if” scenarios, the data in the input object can be temporarily modified prior to the audit. This makes it very easy to use the same rules defined for an official audit to be reused for less-than-official situations.

During this process, the Degree Audit object acts as a “work-in-progress” object, meaning that, after activation, the object sits in memory and is modified as the transformation rules are executed in sequence. As noted below, that work-in-progress object can then be examined by the Object Browser to evaluate the proper functioning of the rules.

The primary rule statement used to construct the transformation is a “SET CURSOR”. Basically, the degree audit involves simply looping through each course taken within a student’s academic record object (using a “FOR EACH” statement) and trying to position on that course within the degree audit object (using a “SET CURSOR” statement). If the course is not found within a group, it is considered an elective. If it is found, it goes to meet the requirements of that group. In reality, of course, it is must more complex than that. As expected, complexities revolve primarily around the many exceptions. For example, some courses are validly repeated for credit, while other courses are being repeated to improve a grade.

The example to the upper right presents a section of the audit rules. Note the basic statement,

which tries to position on any course within the audit object by course id.

A key issue in defining such complex rules is determining their accuracy (i.e., debugging). A critical aid to this process is the AOA Object Browser, which allows the developer to examine the process of the transformation through a pictorial diagram of the current state of the audit object (shown in the diagram on the right). Sometimes, a transformation error leads to an automatic break in the execution and the presentation of an error message. At other times, the developer inserts a break at a logical point to allow the state of the input object and the output object to be examined. In any case, the browser is the vehicle through which the user evaluates the success of the rules. Again, as noted earlier in this presentation, the structure of the object during debugging is exactly the same as that during the earliest stages of design.