Transcript Analyzer – Requirements Analysis Document
Authors:
Duc Duong
Jason Morris
Nicholas Lloyd
([email protected])
([email protected])
([email protected])
1. Introduction
1.1 Purpose of the system
A central task that a student performs when planning for their own graduation is the
analysis of their transcript records and how the courses they have taken satisfy the
graduation requirements set by their program of study in the University. By evaluating
where they are lacking with respect to graduation a student can better plan the future of
their academic career in order to graduate in a timely manner. Faculty Advisors to these
students also perform this task in order to better understand the current needs of their
advisees. However, manually checking and rechecking transcript records against written
requirements within University catalogs is a tedious and time consuming task.
Additionally, graduation requirements change within each department and program from
time to time, adding another level of complication. Some of the systems used by the
registrar require automatic evaluation of a student’s transcript for assigning warnings to
different students in danger of not graduating or losing financial aid. In these situations
the transcript needs to be evaluated through limited requirements simply to determine
how many requirements are missing or, more frequently, how many classes have been
failed (No Record, NR).
The purpose of the Transcript Analyzer is to provide both students and faculty advisors
with a tool that will automatically evaluate a student’s transcript using current or previous
graduation requirements. This evaluation should show the user what requirements have
been satisfied for the student in question, and for those requirements unsatisfied
information regarding what credits and/or courses are missing. The Transcript Analyzer
should also allow University administrators to create, review, update, and delete
graduation requirement sets for the different programs and majors.
1.2 Scope of the system
The Transcript Analyzer is a reporting tool only for performing detailed and unofficial
analyses of student transcripts against graduation requirements. They are unofficial
precisely because regardless of the accuracy of their reports, they should not supersede
the authority of the University officials directly responsible for evaluating students for
graduation. As a reporting tool on a given student’s academic progress its intended nonadministrative users include students and any faculty member who is either an advisor or
requires special access to the student’s progress information, as is the case for ROTC
officers. Administrative access to create, modify, and delete graduation requirements
within the system is intended for University personnel who are responsible for
performing the formal degree evaluations prior to a student’s graduation.
1.3 Objectives and success criteria of the project
The objectives of Transcript Analyzer are to:
 Provide advisors and students a fast, adequate, accurate, and reliable report on the
status of a student toward his/her undergraduate degree at Worcester Polytechnic
Institute based on a given transcript and a set of degree requirement rules.
 Enable the registrar office to manage the set of degree requirement rules easier
and more efficiently through a simple and friendly interface.
The success of the Transcript Analyzer project is based on the ability to minimize the
time and effort needed to manage degree requirement rules, as well as to help professors
save time on advising their students. The future system has to provide these advantages in
order to be accepted and replace the current one.
1.4 Definitions, acronyms, and abbreviations
A transcript is a listing of all the courses and projects a student has completed or failed to
complete for University credit over the period of their studies. A transcript is analyzed,
or “audited,” by applying a set of constraints represented as program graduation
requirements (and departmental requirements) to the information contained within the
transcript. If all constraints are satisfied by the courses and projects completed by the
student, as detailed in the transcript, then the student is allowed to graduate. Any
unfulfilled constraints indicate where the student is lacking in their academic career.
A program graduation requirement, which will be referred to simply as a Program,
consists of the following:
 A collection of Areas representing groups of similar requirements, such as
globally applied University requirements and Major specific requirements
 An Area representing a collection of Major specific requirements may be
associated with additional collections of requirements called Groups which
represent Concentrations within a Major area of study.
 Areas and Groups consist of Rules which are conditional (AND/OR) relationships
between courses provided by the University as well as a number indicating how
many credits (in other words how many valid courses) are required to satisfy the
Rule.
A transcript is complete if it satisfies all requirements for the student’s specific program
of study, incomplete if otherwise. When a transcript is incomplete, there is a set of
uncompleted areas, together with counts of the degree to which these individual areas
have been partially satisfied based upon credits satisfying the requirement areas.
Additional terms include:
 Course numbers – human readable unique identifiers for each course offered, they
consist of…
o 2 letter program code – for instance CS for Computer Science.
o 4 digit course number – four numbers to further specify the course, the
first of which indicates the level of difficulty (from 1 to 4) of the course.
 Course Registration Number (CRN0 – special serial numbers used internally for
the registrar that represent specific courses.
1.5 References
The current system employed by WPI for transcript analysis, among other things, is the
Banner system by Sungard (http://www.sungardhe.com/default.aspx?id=80). In
particular the transcript analysis portion is a part of the Banner Student component in the
Banner system (http://www.sungardhe.com/default.aspx?id=94). Documentation is
available online for this system and its different components.
1.6 Overview
2. Current system
The current transcript analysis (also referred to as degree audit) system used by WPI is
Sungard’s Banner system (see the References section). This system permits the
construction of rule representations of graduation requirements. Rules are constructed
using simple conditional logic (AND, OR, NOT operations) with course numbers stored
within the system. Similar rules are grouped together into collections known as groups
and areas (see the Definitions, acronyms, and abbreviations section). Groups and areas
are connected with Programs which represent the different degree programs offered by
the University. Records of previous requirement sets from older University catalogs are
updated by directly copying old records, updating the requirements that have changed,
and saving the modified copies as new records.
3. Proposed system
3.1 Overview
In order to develop an improved Transcript Analyzer tool, the new implementation must
be built upon the current Banner system. While the Banner system offers a variety of
functionality, appropriate interfaces to allow more powerful rule editing and report
presentation must be developed. Additionally, rule development in the new system must
use more advanced rule representations beyond simple conditional logic.
3.2 Functional requirements
The Transcript Analyzer supports three types of users:
 The student should be able to see analysis reports of their own transcripts as
applied to different program requirements, by year or major. Only one report may
be received at a time by the student.


The advisor should be able to see the same reports a student can see for any
student they currently advise. Advisor users include faculty as well as ROTC
officers that need to see reports on the progress of their students.
The administrator should be able to create, modify, delete, and view requirements
within the system as well as produce the same reports that the student user can to
assist in the formal degree audit process.
o New requirement sets are associated with the course catalog for a
particular academic year, identifying what University set requirements the
requirements written in the system represent.
o Certain requirement sets are identified as being “global” indicating that
they are University requirements applied to all degree programs while
other requirement sets are “local” to a particular degree program.
For the report capabilities of the Transcript Analyzer, available to all three user types, the
system must receive information regarding who the student is in order to obtain their
transcript data, and what requirement sets to apply to their transcript. The latter consists
of an academic year and a program of study (i.e. major). The analyzer then performs the
analysis by applying the rules contained within the requirement sets to the transcript
information, generating a report detailing what requirements have been satisfied and what
requirements have not been satisfied. For unsatisfied requirements the system details in
its report what rules have not been satisfied by the current transcript. These unsatisfied
requirements are displayed by area and, where applicable, group (see Transcript Analyzer
Report mockup screenshots, Figures 2 and 3 in section 3.4.2.1).
The report presented to the requesting user presents a brief summary of information
regarding the student and the specified area of study as well as overall credits completed
and total credits required at the top of the report. The rest of the report is a listing of each
requirement section, from global University requirements to more specific program
requirements, detailing what courses that have been taken satisfy which condition within
a rule of the requirement and what courses are missing for unsatisfied conditions.
Additionally each section will show the number of course credits required as well as the
number completed, thus the user will be able to see by the unsatisfied conditions what
courses they can choose from to satisfy the missing conditions.
The report system is constrained for the advisor user such that the advisor is limited to
only selecting programs of study for a given student that they are qualified to advise. The
student user, however, may select any program of study in order to simplify instances
where a student user may wish to change programs.
The administrator user is the only user capable of creating, viewing, modifying, and
deleting requirement rule sets. As such a special Rule Editor interface is available to the
administrator user where said user may choose to either view an existing requirement
rule set by choosing the desired academic given year, program of study, and associated
requirement set (see section 3.4.2.2 for details on rule editing and the Rule Editor
interface). For globally applied University requirements only the academic year is
necessary to bring up the list of all global requirement sets. For all other requirement sets
the program of study is necessary input. With a retrieved requirement set the
administrator may edit the current set, copy the set, or delete the set from the system.
Creating a new set does not require the user to request a previously constructed set; they
just use the editor interface and specify a name and academic year for their new set.
The copy function for the Rule Editor is available in order to simplify the updating of
requirements for new academic years where the requirements of the previous year differ
by a small margin. In this situation it is easier to copy the previous requirements and then
to edit the rules and the academic year for the copy in order to produce the new
requirement set.
3.3 Nonfunctional requirements
3.3.1 Usability
General usability is a high-priority attribute of the Transcript Analyzer. For all actors
who are also users of the system, particular attention will be paid to the following
features and conditions.
3.3.1.1
Assumed user expertise
Users are not assumed to be expert computer users nor even technically competent
computer users. Therefore, the application will not require special knowledge of fields
including but not limited to: programming languages, computer science theory, database
querying, database administration, or internet programming. It is expected that a user can
access and manipulate a modern web browser and manipulate common windowing GUI
elements such as text boxes, drop-down lists, radio buttons, etc. It is also assumed that
the user can navigate a standard windowing file system and be able to perform basic
operating system tasks including but not limited to opening a file, printing a file, locating
a file, and navigating to a web page.
3.3.1.2
Interface standards
The user interface shall be minimalist in design, meaning that it will use the minimum
number of graphical user interface (GUI) elements and human-computer interaction
(HCI) principles to produce a transcript analysis. The style and color scheme shall
conform to the other currently installed Banner applications so that continuity of
presentation is maintained.
The interface will be renderable and manipulable without any additional plugins,
controls, or other downloadable components (i.e., Flash, Java Applets, ActiveX controls,
etc.). The user will not be burdened with the overhead of downloading large JavaScript
libraries to the client browser, consequently client-side scripting will be used sparingly.
If client-side scripting is required, care will be taken to avoid performance degradation on
the lowest common denominator client system (see hardware standards). Any client-side
scripting that places a performance tax upon the client (i.e., AJAX, DoJo, etc.) will be
carefully scoped to minimize the effect.
The interface itself will be determined by the browser in which the application is
rendered. Obviously, there will be some variation among the supported browsers.
SunGard Higher Education has completed testing with the following browsers:
Table 1 Supported browsers in Banner 7.01
Banner Version
Internet-native Banner
7.02



Browser Comments
Microsoft Internet Explorer 6.0 (with Oracle JInitiator
1.3.1.18)
Netscape 7.0x (with Oracle JInitiator 1.3.1.18)
Macintosh client - Safari 1.2 (Sun plug-in 1.4.2) for Mac
OS X (1.4 JDK); must use Forms patch set patch2
(9.0.4.2)
Internet-native Banner
via the Luminis Portal


Microsoft Internet Explorer 6.0
Macintosh client - Safari 1.2 (Sun plug-in 1.4.2) for Mac
OS X (1.4 JDK); must use Forms patch set patch2
(9.0.4.2)
Self-Service Banner 7.0






Microsoft Internet Explorer 6.0
Netscape 7.01
Netscape 7.2
Mozilla 1.7
Microsoft Internet Explorer 5.2 for Macintosh OS X
Macintosh client - Safari 1.2 for Mac OS X
Self-Service Banner via
the Luminis Portal



Microsoft Internet Explorer 6.0
Netscape 7.2
Macintosh client - Safari 1.2 for Mac OS X
At this time, the following browsers are not supported:





1
2
Browser Java for INB
SUN Java Plugin/WebStart for INB
AOL's repackaged browser
LINUX desktop browsers
Other non-Windows browsers
See www.wvnet.edu/banner/ban7upg/Banner7FAQ05-26-06.doc
See http://www.oracle.com/technology/products/forms/htdocs/10g/clientsod_forms10g.html
3.3.1.3
Online help and documentation
The system shall feature an online, HTML-based help system in accord with existing
Banner stylistic guidelines (See Banner help documentation for an example). The online
help shall be created and compiled using a standard help authoring tool such as JavaHelp,
RoboHelp, or MS HTML Workshop. Help shall implement search by index, search by
keyword, and search by category. All help and end-user documentation shall be printable
in PDF format. The PDF format for the documentation shall allow copy and paste
functionality so that users may create their own custom annotations and sub-documents.
Online documentation in PDF form shall be available outside of the Banner context so
that end-users are not required to log into Banner in order to view them.
3.3.2 Reliability
The general ability of the system to perform its required functions under specified
conditions (during normal operation) and over a given time period is described below.
3.3.2.1
Reliability, availability, and robustness
Under normal operating conditions, the system will have a reliability, or meantime until
failure, equal to or greater than the meantime for the server hosting the system to require
rebooting. That is, the system is expected to have at least 3-sigma (99.99 %) uptime. It
is expected the system will be continuously available, except for routine maintenance
periods to be specified later. Before these maintenance periods, all system users and
administrators shall be notified, preferably by email, that the system will be unavailable
for use.
Times of peak use often coincide with times of greatest need for analysis (i.e., at the end
of Spring term/semester of any given year). During times of peak use, the system should
accommodate the theoretically largest number of concurrent users (i.e., The sum of all
possible users, administrators, advisors, etc. simultaneously trying to access the system
plus some margin of error factor).
In all cases, the system will robustly reject incorrect inputs and selections to preserve data
integrity. All user interfaces will have both client-side and server-side form validation as
well as database validation in the case of new data being added to the system (i.e. new
auditing rules.).
3.3.2.2
Fail-over restarting
If the server hosting the application requires a reboot, then the system shall send an email
notification to all affected users, administrators, etc. that the system will be restarted in an
stipulated time period. System administrators shall monitor the system for software
failures that require the application to be reloaded. If this situation occurs, the system
administrators shall issue a similar warning for a hardware reboot.
3.3.2.3
Fault tolerance
In general, the system shall have the ability to gracefully recover from non-fatal faults
(i.e., incorrect data input, wrong button presses, etc.) without causing an application
restart. In all cases, the system should restore its previous state before the error occurred
and return the user to the GUI view that was visible before the error. Users will not need
to exit the system and re-enter for any but the most unforeseen and severe errors.
3.3.2.4
Safety requirements
The system is not required to be mission-critical because the loss of life, property, or
other valuable items will not result if the system (either the software or its hardware) fails
catastrophically at any time.
3.3.2.5
Security requirements
Though the system is not mission-critical in the purest sense, it does require a secure and
encrypted login procedure and mechanism to preserve the confidentiality and privacy of
users. Only systems administrators and department administrators are allowed to edit,
update, modify, or delete auditing rules. Under no circumstances are students or advisors
to be allowed to edit, update, modify, or delete auditing rules. All auditing rules are to be
stored on a secure database server with restricted access privileges. Login shall use a
typical username and password combination identical to the current WPI Banner
requirements. Password fields on the login form shall be encrypted.
3.3.3 Performance
Web applications have more liberal performance ranges than native client (fat client)
applications. These are enumerated below.
3.3.3.1
Responsiveness
The system will respond to all requests in less than or equal to the time to execute the
most complex analysis at peak use time and at peak load. An estimate of this time is
fifteen (15) seconds. Actions that do not involve initiating an analysis and that are simply
input/output or communications with the application server should be on the order of less
than or equal to five hundred (500) milliseconds.
3.3.3.2
Time-critical tasks
A user will not be kept waiting for more than 30 seconds to complete an analysis. If the
system cannot fulfill a request in that time, the system will notify the user that that system
has become busy and will prompt the user to re-submit the request. If an audit rule
editing session is opened, it shall timeout in 30 minutes if the system does not detect any
activity. If an analysis session is opened, it shall timeout in 30 minutes if the system does
not detect any activity.
3.3.3.3
Concurrent users
The system shall accommodate a number of concurrent users equal to the current number
supported by the BANNER system.
3.3.3.4
Data store
The data store shall remain Oracle-based as per the specifications of the current
BANNER system.
3.3.3.5
Maximum latency
Latency is a function of the pooling used to connect to the database, therefore the system
will employ dynamic database connections. Complex data processing will be done on the
database server rather than in application code as much as possible to leverage existing
database optimizations.
3.3.4 Supportability
It is vital to have a system that can scale as WPI's needs evolve and grow. Therefore, it is
necessary that the system have the following capabilities.
3.3.4.1
Extensions and augmentations
The system will be able to support augmentations and extensions via some high-level
language, preferably Java, via a public API. The system administrators will work with
the system users to determine which APIs are likely to evolve rapidly and to ensure that
those are engineered in the most flexible way. A key component of this initiative is the
BANNER API itself, which has only been made public since version 7.0. The system
administrators will work closely with the BANNER vendors to ensure that system
developers have access to sufficient technical documentation and vendor expertise to
assist them in their work.
3.3.4.2
Maintaining and updating system
It is recommended that the oversight for the transcript analysis system rest with a
university-level committee, that in addition to administering and controlling the general
university graduation requirements, also administers and controls the system updates of
the various WPI departments. Furthermore, each department shall form a committee
headed by a chair whose duty it will be to collate and finalize graduation rules for that
department. The chair will then update those rules in the transcript analyzer system or
designate an agent who is more familiar with the system's user interface. The universitylevel administration will perform annual audits of the overall university rule base to
ensure data integrity as well as term-by-term partial audits and reminders to individual
departments to test and validate their own rule bases before the printing of the next
course catalog.
3.3.4.3
Portability to other platforms or hardware
It is not a requirement at this time that the system be portable to another platform or
hardware set.
3.3.5 Implementation
3.3.5.1
Hardware constraints
The general system has no hardware constraints at this time. The client-side interface
will be displayable on all modern personal computer platforms.
3.3.5.2
Maintenance constraints
There are no general maintenance constraints at this time.
3.3.5.3
Testing constraints
There are no general testing constraints at this time.
3.3.6 Interface
3.3.6.1
System integration with existing systems
The transcript analysis system is highly constrained by the existing BANNER system,
and it will be made to integrate with BANNER's existing interfaces and API. There is no
anticipation that this requirement will change in the foreseeable future.
3.3.6.2
Data imported/exported
BANNER is a closed system with regard to data input and output due to the nature of the
personal data that it holds. All import and export functionality will be securely password
protected and only administrative-level access will be granted. Non-FERPA sensitive
data will have a batch processing mechanism for upload and download to be specified at
a later date.
3.3.6.3
Supported client standards
All client standards are governed by the existing look and feel of the BANNER system.
The appearance of the system to users via the client interface should be transparent with
respect to the existing BANNER system (i.e., placement of common controls, color
scheme, etc.)
3.3.7 Operation
3.3.7.1
System management
The system shall be managed at the university level by the current managers of the
BANNER system. Individual WPI departments shall be responsible for creating,
managing, and uploading their own graduation rules to the main system.
3.3.7.2
System troubleshooting and support
The current WPI help desk shall be given instruction and documentation to provide
support for the new transcript analysis system to the WPI community. Online help will
be integrated into the system's user interface. The university shall schedule one in-house
training session per term to educate new administrators on the correct procedures for
creating, managing, and uploading rules.
3.3.8 Packaging
3.3.8.1
Installation procedure
The installation shall consist of deploying a Java *.JAR or *.WAR file containing the
transcript analysis code to the BANNER server. It is expected that BANNER
administrators are familiar with this procedure.
3.3.8.2
Installation time constraints
There are no installation time constraints at this time.
3.3.8.3
Concurrent access availability
If the system becomes unavailable due to application error, server error, or other errors
within BANNER, the system shall generate log entries that indicate the error and its root
cause. If possible, any clients that are still in communication with the system shall be
notified either through the client interface or via email that the system has become
unresponsive and that that actions are being taken to correct the problem. Consequently,
an email will be sent to the system administrators notifying them of the problem.
In general, the system shall be designed so as to accommodate the peak server load at the
peak usage time as designated elsewhere in this document (See Performance).
3.3.9 Legal
3.3.9.1
Legal access
Only authorized WPI administrators, staff, and designated faculty shall have access to the
personal data and rule administration functions of the transcript analysis system.
3.3.9.2
Licensing
Since BANNER is already a licensed application at WPI and this transcript analysis
system is proprietary sub-system, there should be no further general licensing issues.
3.3.9.3
Intellectual property
All inventions, devices, and algorithms used in transcript analysis system are property of
WPI. All intellectual property developed as a result of this project are copyrighted by
WPI.
3.3.9.4
Royalties or fees for proprietary components
Should a rule based approach be used, the de facto standard for rule engines implemented
in Java is Jess. Jess is proprietary software that is licensed by Sandia Corporation, and a
commercial license for its inclusion in the transcript analysis system would need to be
negotiated and purchased.
3.3.9.5
Family Educational Rights and Privacy Act (FERPA)
constraints
Under all circumstances, the FERPA guidelines and requirements shall be enforced by
the administrators of the transcript analysis system. No person shall have access to
confidential student information without the express permission and foreknowledge of
the university-level administration and the department-level administration involved.
The system shall provide tie-ins to the BANNER system to allow senior systems
administrators the ability to grant various levels of access rights to those requesting such
rights.
3.4 System models
3.4.1 Use Case Model
Rule Management System (RMS)
Delete Rule
Create Rule
Student
Degree Evaluation System (DES)
<<include>>
<<include>>
Registrar
Validate Rule
Retrieve Course
<<include>>
Evaluate Transcript
<<include>>
Advisor
<<include>>
<<include>>
<<include>>
Update Rule
<<include>>
Retrieve Rule
Copy Rule
<<include>>
Retrieve Transcript
<<include>>
<<include>>
View Rule
Figure 1: Use Case Diagram of the Transcript Analyzer
Use case name
Evaluate Transcript
Participating actor
Flow of events
Initiated by Advisor or Student
Step
Action
1
The Advisor (or Student) selects “Evaluate Transcript” function for a
student
The Advisor (or Student) selects a desire degree
2
DES loads the transcript and associated rules
Initiate “Retrieve Transcript”
Initiate “Retrieve Rule”
3
DES shows a report on current statues of the student toward the selected
degree
Entry
condition
Exit success
condition
The Advisor (or Student) logged in to DES
The Advisor (or Student) receives a report on the given transcript

The Advisor (or Student) receives a message indicating why DES cannot
retrieve the needed rules OR
The Advisor (or Student) receives a message indicating why DES cannot
retrieve the transcript
DES has to provide a accurate evaluation
DES has to show a missing courses or requirements
Exit failure
condition

Quality
requirements


Use case name
Retrieve Transcript
Participating actor
Flow of events
Initiated by Advisor or Student
Step
Action
1
DES receives a request to load a transcript
2
DES retrieves the transcript, changes state to ready, and waits
Entry
condition
Exit success
condition
Exit failure
condition
Quality
requirements
The Advisor or Student logged into DES and initiated “Evaluate Transcript”
DES changes the state to ready
DES could not retrieve the transcript
Use case name
Create Rule
Participating actor
Flow of events
Initiated by Registrar
Step
Action
1
The Registrar activates the Create Rule function
2
RMS prepares a list of courses for the new rule and displays a rule
definition form
Initiate “Retrieve Course”
3
The Registrar defines a new rule and then submits the form
4
RMS receives form and validates the new rule.
Initiate “Validate Rule”
5
RMS saves it and sends confirmation message back to the Registrar
Step
Branch Action
5a
RMS takes the Registrar back to step 3 and shows a warning message if
the new rule conflicts with some existing rule
Extensions
Entry
condition
Exit success
condition
The Registrar logged in to RMS
The Registrar receives a confirmation message that a new rule was created

Quality
requirements
The Registrar receives a message indicating RMS cannot retrieve the list of
courses OR
 The Registrar receives a message indicating why RMS cannot save the rule
even it was valid
RMS has to present a rule definition form that allows the Registrar with no
knowledge of programming skills and rule description languages to define the rule.
Use case name
Validate Rule
Participating actor
Flow of events
Initiated by Registrar
Step
Action
1
RMS receives a request to validate a rule
2
RMS retrieves all associated rules and compares each of them with the
input rule
Initiate “Retrieve Rule”
3
RMS prepares the validation result, changes state to ready, and waits
The Registrar logged in to RMS and initiated either “Create Rule”, “Update Rule”,
or “Copy Rule”
Exit failure
condition
Entry
condition
Exit success
condition
Exit failure
condition
Quality
requirements
RMS changes the state to ready
RMS could not retrieve one or some rules


RMS has to show all the detail conflicts if exist.
RMS has to find out if the input rule is implied by one or some existing rules
or reverse
Use case name
Retrieve Rule
Participating actor
Flow of events
Initiated by Registrar, Advisor, or Student
Step
Action
1
RMS receives a request to load a rule
2
RMS retrieves the rule from database, changes state to ready and waits
The Registrar logged in to RMS and initiated one of the following use-cases “View
Rule”, “Update Rule”, “Copy Rule”, or “Create Rule”
The Advisor or the Student logged in to DES and initiated use-case “Evaluate
Transcript”
Entry
condition
Exit success
condition
Exit failure
condition
Quality
requirements
The rule was retrieved and the state changed to ready
RMS could not retrieve the rule and changed its state to fail with an error message
Use case name
Retrieve Course
Participating actor
Flow of events
Initiated by Registrar
Step
Action
1
RMS receives a request to load a course
2
RMS retrieves the course, changes state to ready and waits
The Registrar logged in to RMS and initiated either “Create Rule” or “Update
Rule”
Entry
condition
Exit success
condition
Exit failure
condition
Quality
requirements
RMS changes the state to ready
RMS could not retrieve the course and changed its state to fail with an error
message
Use case name
View Rule
Participating actor
Flow of events
Initiated by Registrar
Step
Action
1
The Registrar selects a rule to view
2
RMS gets the rule definition and describes it in a human understandable
method
Initiate “Retrieve Rule”
Entry
condition
Exit success
condition
Exit failure
condition
Quality
requirements
The Registrar logged in to RMS
The Registrar sees the rule described in a human understandable method

The Registrar receives a message indicating RMS cannot retrieve the rule

The rule has to be described in some meaningful sentences
Use case name
Copy Rule
Participating actor
Flow of events
Initiated by Registrar
Step
Action
1
The Registrar activates Copy Rule function
2
RMS presents a form with a list of original rules and a list of destinations
3
The Registrar selects a set of rules and destination
4
RMS retrieves rules from the source and validates them at the new location
Initiate “Retrieve Rule” and “Validate Rule”
5
RMS saves rules to the new location
Entry
condition
Exit success
condition
Exit failure
condition
Quality
requirements
The Registrar logged in to RMS
The Registrar receives a confirmation message that rules were copied


The Registrar receives a message indicating that there is no rule to copy OR
The Registrar receives a message indicating why RMS cannot copy rules to
new location because of conflict with current rules there OR
 The Registrar receives a message indicating why RMS cannot copy rules even
there is no conflict
RMS has to allow the Registrar to select a set of rules by filtering them by year,
department, or major
Use case name
Update Rule
Participating actor
Flow of events
Initiated by Registrar
Step
Action
1
The Registrar selects a rule to modify
2
RMS gets the rule, prepares a list of courses, and displays a rule definition
form with the specified rule information
Initiate “Retrieve Rule”
Initiate “Retrieve Course”
3
The Registrar modifies the rule and then submits the form
4
RMS receives form and validates the rule.
Initiate “Validate Rule”
5
RMS saves it and sends confirmation message back to the Registrar
Step
Branch Action
5a
RMS takes the Registrar back to step 3 and shows a warning message if
the modified rule conflicts with some existing rule
Extensions
Entry
condition
Exit success
condition
The Registrar logged in to RMS
The Registrar receives a confirmation message that the rule was modified

Quality
requirements
The Registrar receives a message indicating RMS cannot retrieve the list of
courses OR
 The Registrar receives a message indicating why RMS cannot retrieve the rule
OR
 The Registrar receives a message indicating why RMS cannot save the rule
even it is valid
RMS has to present a rule definition form that allows the Registrar with no
knowledge of programming skills and rule description languages to define the rule.
Use case name
Delete Rule
Participating actor
Flow of events
Initiated by Registrar
Step
Action
1
The Registrar selects a rule to delete
2
RMS asks the Registrar to confirm the deletion
3
The Registrar decides to delete
4
RMS deletes the rule and sends confirmation message back
Exit failure
condition
Entry
condition
Exit success
condition
Exit failure
condition
Quality
requirements
The Registrar logged in to RMS
The Registrar receives a confirmation message that the rule was deleted


The Registrar decides not to delete the rule in step 2 OR
The Registrar receives a message indicating why RMS cannot delete the rule
3.4.2 User interface
3.4.2.1
Transcript Analyzer Report Screen
Figure 2: Upper portion of the Transcript Analyzer Report, adapted from the
current Banner system report to be more usable.
Since the new Transcript Analyzer will be built upon the current Banner system, it is
reasonable to expect the interface components to be similar in format but improved in
content. Figure 2, displayed above, depicts a mockup of the first portion of a Transcript
Analysis Report for the new system showing basic information regarding a given
student’s activity. This information includes the student’s chosen Program, requirements
set to evaluate against (based upon catalog term), when the transcript data was last
updated, and current credit hour totals compared against required credit hour totals.
Figure 3: Areas portion of a Transcript Analyzer Report, adapted from the current
Banner system report to be more usable.
While the upper portion of a report will display basic information regarding the student,
their program, and the requirement set being applied in this analysis to their current
transcript, the power of a Transcript Analyzer Report is in the sections that follow.
Figure 3 above shows a mockup of a potential Computer Science student’s Transcript
Analysis Report. The report is broken up into a listing of the different Area requirement
sets of varying complexity. Every area section shows in its title a color coded label
indicating whether or not the requirement area has been satisfied. If the area has been
satisfied then the details for the course taken by the student that satisfies this requirement
is recorded in the table, along with a grade if the course has been completed (as opposed
to courses currently in session). Depending upon the specificity of the requirement set, a
section of each Area table, the Required Courses section, shows what courses can be
taken to satisfy this requirement. Note that the last Area displayed in the figure is only
partially satisfied, thus showing the single course of 5 total required that satisfies this
requirement area.
3.4.2.2
Rule Editor Interface
3.4.2.2.1 Using Rules, Rule Engines, and Rule Editing
In general, a rule is a compact representation of a set of logical conditions and the actions
to be performed when those conditions are met. Rules are similar to procedural IFTHEN statements, but they are never called in a procedural or algorithmic manner.
Rather, rules operate automatically and opportunistically on data as they are made
available to a rule-based program.
When, in the course of analyzing the business logic needs for a given software project, it
becomes apparent that decisions will be made by many complex modules, classes, or
other constructs using copious IF-THEN type code, the use of a rule-based approach
makes good sense. The maintainability and scalability of business logic that depends
upon such IF-THEN code is well-documented to be poor at best. In all cases, if changes
to the business logic need to be made, source code must be checked out of source control,
edited, tested, and then checked back in. This cycle is time-consuming, it requires a
programmer to edit the code, and has a high probability of introducing side effects due to
code dependencies.
For these reasons, rules are well-suited for the implementation of the general transcript
analysis functionality. Changes can be made on-the-fly as production code is running.
Rules can be edited by non-programmers. Most importantly, rules are generally
independent of one another, and with good programming practice their effects can be
localized to well-defined modules and data namespaces. Such an implementation would
most likely be enabled by an existing component technology that provides rule-based
programming support. This component or sub-system technology would then be
transparently embedded in the main transcript analyzing system. Such a sub-system
would be composed of a:



Rule engine: a software component capable of applying rules to data.
Rule base: a database of rules that represents the knowledge for analyzing a
transcript.
Rule manager: a software component that acts as the interface between the rule base
and those who create, edit, update, and delete rules.
The general problem of allowing plain-English create, edit, update, and delete
functionality for any given rule in a particular rule language is a non-trivial programming
project. Most implementations begin with some sort of restricted language – a subset of
the complete programming operations from which one can form rules in a given formal
rule language3. This restricted language is implicitly enforced by the rule manager GUI.
3
See Jess http://herzberg.ca.sandia.gov/jess/ and CLIPS http://www.ghg.net/clips/CLIPS.html
A full treatise on rules, rule-engines, and rule-based declarative programming is beyond
the scope of this document. Those who require more details are recommended to read the
references listed in the foot notes to this section. What follows is a brief description of
possible rule types, editing interfaces, and other issues encountered while analyzing a
given transcript for compliance.
3.4.2.2.2 Implementation issues
The holy grail of all rule-based implementations is that the rules will be creatable and
manageable by non-programmers. While this goal is noble and understandable, there are
significant practical problems that must be overcome to allow non-programmers to
construct rules outside of a formal rule language and in plain language. It is impractical
to attempt to expose the richness of a given computer programming language via a finite
set of grammars and productions rendered via a finite set of GUI components. In the
limit, one simply ends up creating a general integrated development environment and
unmanageable amount of complexity. However, it is reasonable to expose a subset of a
rule based language via a GUI that regulates what kinds of rules can be constructed.
In general, the more complex the rule, the more difficult it will be to map its plain
language source to its rule language equivalent. As an example, consider the following
plain language rule:
Choose any five (5) courses from {BB, BME, CE, CH,CHE ECE,ES,GE,ME,PH}
where at least three (3) are from { BB, CH,GE, PH } and two (2) are
from { BB|CH|GE|PH }
In Figure 4, observe what happens when one encodes the above plain language rule in
Jess:
(defrule SCIENCE::check-for-general-science-requirement
"General set BB, BME, CE, CH, CHE, ECE, ES, GE, ME, PH"
?ctrl<-(science-is_unsatisfied)
?bc<-(MAIN::bin-count (bin science) (count ?c))
?course1<-(MAIN::course (crn ?crn1) (department
?dept1&BB|CH|GE|PH))
?course2<-(MAIN::course (crn ?crn2&~?crn1)
(department ?dept2&BB|CH|GE|PH&:(eq ?dept1 ?dept2)))
?course3<-(MAIN::course (crn ?crn3) (department
?dept3&~?dept2&BB|CH|GE|PH))
?course4<-(MAIN::course (crn ?crn4) (department
?dept4&BB|BME|CE|CH|CHE|ECE|ES|GE|ME|PH))
?course5<-(MAIN::course (crn ?crn5&~?crn4) (department
?dept5&BB|BME|CE|CH|CHE|ECE|ES|GE|ME|PH))
=>
(modify ?bc (count 5))
(printout t "
Science units now satisfied by:" crlf)
(printout t "
" ?dept1 " " ?crn1 crlf)
(printout t "
" ?dept2 " " ?crn2 crlf)
(printout t "
" ?dept3 " " ?crn3 crlf)
(printout t "
" ?dept4 " " ?crn4 crlf)
(printout t "
" ?dept5 " " ?crn5 crlf)
(retract ?course1 ?course2 ?course3 ?course4 ?course5 ?ctrl))
Figure 4: A hypothetical Jess rule for WPI CS department science requirements.
Clearly, the logic needs to reflect constraints that are not explicitly stated in the plain
langauge rule (i.e., that although two course must come from the same department they
also must not have the same course number). It is these types of details that are hard to
abstract for the benefit of the non-programmer users. Therefore, to the extent that it is
possible, it is recommended that each department comb its existing rules and determine
as many rule meta-types as possible. This will facilitate the development of the richest
rule managing interface while capturing and cataloging rule templates for future re-use.
3.4.2.2.3 Rule meta-types
In constructing a rule editor for allowing non-programmers (i.e., system administrators,
registrar officers, department heads, etc.) to create, edit, update, and delete rules, there are
frequently occurring patterns in the rules. An exhaustive study should enumerate all the
patterns exhibited by all the current rules in the undergraduate catalog and would also
classify them. The following table summarizes the more modest taxonomy for the
Computer Science department rules as they appear in the 2006-2007 WPI catalog.
Select n courses from set of
available courses, {C} (n  1)
Quantified n courses from set of
available courses, {C}
Qualified n courses from set of
available courses, {C}
Arguably, the most frequently encountered pattern.
Select one or more of a set of available courses.
Quantifying phrases:
 At most 1 (only 1)
 At least 1 (1 or more)
 At least n (n or more)
 At most n (no more than n)
 At least n and at most m (between n and m)
 With n or more units
 With at least n units
Qualifying phrases:
 At academic level L
 At or above academic level L (not below
academic level L)
Choose one but not both options from a set of two.
The exclusive (XOR) course
selection
Other complex patterns
Complex patterns can be built from nesting of
selection patterns and the attachment of qualifying
and quantifying attributes.
Examples:
 Select [at most n (no more than n)] from {C}
 Select [at least n (n or more)] from {C} where
[at or above academic level L]
3.4.2.2.4 Interface Concepts
A convenient way to represent rules is in a hierarchical tree control as shown in Figure 5.
Clicking on entities in the tree control allows a rule creator to access more detailed
editing dialogs for setting attributes and properties. Without having detailed
requirements regarding the meta-types of rules that need to be supported, it is difficult to
envision what a fully functional rule editor interface would look like.
Project View
-
+ X
RULE BASE PROJECT
Clicking would activate a meta-properties
editor dialog. This would be dockable in the
general editing application view.
RULE MODULE 1




RULE MODULE 2
Editable fields would include:
Rule name
Rule description
Rule author
Rule creation date
RULE MODULE n
Rule 1
Rule 2
Clicking would activate editing pallet for this
type of pattern. Rule authors can drag and
drop pattern components onto the editing
dialog and fill in their attributes to complete
the pattern.
Rule n
LHS
Pattern 1
Pattern 2
Pattern n
RHS
Action 1
Clicking would activate the action
selection pallet. Rule authors would
be able to choose from a selection of
actions and set their attributes.
Available actions may include:

Scheduling a meeting

Sending a notifying email

Initiating a form request
Action 2
Action n
Figure 5: Tree view for a rule based project in the transcript analyzer.
A general application framework is readily available by leveraging Eclipse4, and a typical
rule editing GUI might look like Figure 6.
TITLEBAR
MENU BAR
TOOLBAR(S)
PROPERTIES
DIALOG
EDITING DIALOG
PROJECT
TREE
VIEW
ATTRIBUTES
DIALOG
STANDARD I/O, TESTING CONSOLE,
AND BANNER INTERFACE
Figure 6: A typical rule editing GUI in Eclipse.
4. Glossary
For definitions of common terms refer to section 1.4 of this document.
5. Appendix
What follows are rules written in the JESS language for the JESS rule engine
(http://www.jessrules.com/jess/index.shtml). These rules represent the Computer Science
Undergraduate Program’s requirements, grouped into different areas (called modules in
JESS terminology). Sample transcripts have been constructed as well. These are
presented as an example of what the new system will construct with respect to the
requirements:
;=======================================================
; ta.clp
; Transcript Analyzer
; Author : Jason Morris
; Date : 2/7/2007
; Course : CS 509 Software Systems Design
4
See http://www.eclipse.org
;=======================================================
;Transcript Analyzer works by asserting a set of course facts
;into working memory representing the individual courses taken by a student.
;These facts are a direct reflection of the student's transcript.
;
;Each required "bin" is processed by a dedicated Jess rule module. As course facts
;satisfy the audit rules, they are removed from working memory
;so that they cannot activate rules in subsequent modules. This prevents courses
;from being double counted. To efficiently use courses that might satisfy multiple
;requirements, a "utility" slot was added to store the total number of times
;that a course appeared the various bins. When multiple courses could satisfy a
;constraint, the one having the smallest utility was chosen to retain the
;most flexibility for later decisions.
;=======================================================
; WPI COURSE PREFIXES
;=======================================================
;ACC =
ACCOUNTING
;AR =
HUMANITIES AND ARTS
;AS =
AIR FORCE AEROSPACE STUDIES
;BB =
BIOLOGY AND BIOTECHNOLOGY
;BME =
BIOMEDICAL ENGINEERING
;BUS =
BUSINESS
;CE =
CIVIL AND ENVIRONMENTAL ENGINEERING
;CH =
CHEMISTRY
;CHE =
CHEMICAL ENGINEERING
;CS =
COMPUTER SCIENCE
;ECE =
ELECTRICAL AND COMPUTER ENGINEERING
;ECON =
ECONOMICS
;EN =
ENGLISH
;ES =
ENGINEERING SCIENCE INTERDISCIPLINARY
;ETR =
ENTREPRENEURSHIP
;FIN =
FINANCE
;FP =
FIRE PROTECTION ENGINEERING
;FPE =
FIRE PROTECTION ENGINEERING
;GE =
GEOSCIENCES
;GN =
GERMAN
;GOV =
POLITICAL SCIENCE, GOVERNMENT AND LAW
;HI =
HISTORY
;HU =
HUMANITIES
;ID =
INTERDISCIPLINARY
;IMGD =
INTERACTIVE MEDIA AND GAME DEVELOPMENT
;MA =
MATHEMATICAL SCIENCES
;ME =
MECHANICAL ENGINEERING
;MIS =
MANAGEMENT INFORMATION SYSTEMS
;MKT =
MARKETING
;ML
;MU
;OBC
;OIE
;PE
;PH
;PSY
;PY
;RBE
;RE
;RH
;SD
;SOC
;SP
;SS
;STS
;WR
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
MILITARY SCIENCE
MUSIC
ORGANIZATIONAL BEHAVIOR AND CHANGE
OPERATIONS AND INDUSTRIAL ENGINEERING
PHYSICAL EDUCATION
PHYSICS
PSYCHOLOGY
PHILOSOPHY
ROBOTICS ENGINEERING
RELIGION
RHETORIC
SYSTEM DYNAMICS
SOCIOLOGY
SPANISH
GENERAL SOCIAL SCIENCE
SOCIETY/TECHNOLOGY STUDIES
WRITING
;=======================================================
; INIT
;=======================================================
(clear)
;(watch all)
;=======================================================
; GLOBALS
;=======================================================
; Task priorities
(defglobal ?*print-header* = 1000)
(defglobal ?*satisfaction-check-priority* = 500)
(defglobal ?*remediation-priority* = 100)
; Unit constraints
(defglobal ?*core-min-units* = 6)
(defglobal ?*systems-min-units* = 1)
(defglobal ?*theory-languages-min-units* = 1)
(defglobal ?*design-min-units* = 1)
(defglobal ?*social-implications-min-units* = 1)
(defglobal ?*advanced-level-min-units* = 5)
(defglobal ?*MQP-min-units* = 3)
(defglobal ?*science-min-units* = 5)
(defglobal ?*mathematics-min-units* = 7)
(defglobal ?*mathematics-max-1000-units* = 4)
(defglobal ?*statistics-min-units* = 1)
(defglobal ?*probability-min-units* = 1)
; Course lists
(defglobal ?*core-courses* = (create$ 1101 1102 2011 2022 2102 2223 2303 3013 3041
3043 3133 3733)) ; must have any six
(defglobal ?*core-used* = (create$))
(defglobal ?*systems-courses* = (create$ 3013 4513 4514 4515)) ; must have at least one
(defglobal ?*systems-used* = (create$))
(defglobal ?*theory-languages-courses* = (create$ 3133 4123 4533)) ; must have at least
one
(defglobal ?*theory-languages-used* = (create$))
(defglobal ?*design-courses* = (create$ 3041 3431 3733 4233)) ; must have at least one
(defglobal ?*design-used* = (create$))
(defglobal ?*CS-social-implications-courses* = (create$ 3043)) ;\
(defglobal ?*CS-social-implications-used* = (create$))
;\
; \
(defglobal ?*STS-social-implications-courses* = (create$ 2208)) ; +--- ; must have at
least one
(defglobal ?*STS-social-implications-used* = (create$))
; /
;/
(defglobal ?*GOV-social-implications-courses* = (create$ 2314)) ;/
(defglobal ?*GOV-social-implications-used* = (create$));
(defglobal ?*advanced-systems-courses* = (create$ 3013 4513 4514 4515)) ; must have
at least one
(defglobal ?*advanced-systems-used* = (create$))
(defglobal ?*advanced-theory-languages-courses* = (create$ 3133 4123 4533)) ; must
have at least one
(defglobal ?*advanced-theory-languages-used* = (create$))
(defglobal ?*advanced-design-courses* = (create$ 3041 3431 3733 4233)) ; must have at
least one
(defglobal ?*advanced-design-used* = (create$))
(defglobal ?*CS-advanced-social-implications-courses* = (create$ 3043))
(defglobal ?*SS-advanced-social-implications-courses* = (create$ 2208 2314))
(defglobal ?*advanced-social-implications-used* = (create$))
(defglobal ?*statistics-courses* = (create$ 2611 2612))
(defglobal ?*statistics-used* = (create$))
(defglobal ?*probability-courses* = (create$ 2621 2631))
(defglobal ?*probability-used* = (create$))
;=======================================================
; MODULE MAIN
;=======================================================
;Deftemplates
(deftemplate MAIN::course
(slot department)
(slot crn)
(slot utility)
(slot units) ; assumed to be in one-thirds
(slot grade))
(deftemplate MAIN::MQP
(slot id)
(slot units) ; assumed to be in one-thirds
(slot grade)
(slot term)
(slot year))
(deftemplate MAIN::bin-count
(slot bin)
(slot count))
; Deffacts
(deffacts load-bin-counts
(MAIN::bin-count (bin advanced-design) (count 0))
(MAIN::bin-count (bin advanced-theory-languages) (count 0))
(MAIN::bin-count (bin advanced-social-implications) (count 0))
(MAIN::bin-count (bin advanced-systems) (count 0))
(MAIN::bin-count (bin core) (count 0))
(MAIN::bin-count (bin design) (count 0))
(MAIN::bin-count (bin mathematics) (count 0))
(MAIN::bin-count (bin MQP) (count 0))
(MAIN::bin-count (bin probability) (count 0))
(MAIN::bin-count (bin science) (count 0))
(MAIN::bin-count (bin social-implications) (count 0))
(MAIN::bin-count (bin statistics) (count 0))
(MAIN::bin-count (bin systems) (count 0))
(MAIN::bin-count (bin theory-languages) (count 0)))
(deffacts load-control-facts
(MAIN::systems-is-unsatisfied)
(MAIN::core-is-unsatisfied)
(MAIN::design-is-unsatisfied)
(MAIN::social-implications-is-unsatisfied)
(MAIN::theory-languages-is-unsatisfied)
(MAIN::advanced-design-is-unsatisfied)
(MAIN::advanced-systems-is-unsatisfied)
(MAIN::advanced-social-implications-is-unsatisfied)
(MAIN::advanced-theory-languages-is-unsatisfied)
(MAIN::computer-science-MQP-is-unsatisfied)
(MAIN::mathematics-is-unsatisfied)
(MAIN::statistics-is-unsatisfied)
(MAIN::probability-is-unsatisfied)
(MAIN::science-is-unsatisfied))
(deffacts load-sample-transcript-core-only-SATISFIED
(MAIN::course (department CS) (crn 1101) (grade B) (units 1) (utility 1))
(MAIN::course (department CS) (crn 2022) (grade A) (units 1) (utility 1))
(MAIN::course (department CS) (crn 3133) (grade B) (units 1) (utility 1))
(MAIN::course (department CS) (crn 2303) (grade A) (units 1) (utility 1))
(MAIN::course (department CS) (crn 3041) (grade C) (units 1) (utility 1))
(MAIN::course (department CS) (crn 3013) (grade B) (units 1) (utility 1)))
;(deffacts load-sample-transcript-core-only-NOT-SATISFIED
; (MAIN::course (department CS) (crn 1102) (grade B) (units 1) (utility 1))
; (MAIN::course (department CS) (crn 3133) (grade B) (units 1) (utility 1))
; (MAIN::course (department CS) (crn 3041) (grade C) (units 1) (utility 1))
; (MAIN::course (department CS) (crn 3013) (grade B) (units 1) (utility 1)))
;(deffacts load-sample-transcript-ALL-SATISFIED
;
; (MAIN::course (department CS) (crn 1102) (grade B) (units 1) (utility 1))
; (MAIN::course (department CS) (crn 2022) (grade B) (units 1) (utility 1))
; (MAIN::course (department CS) (crn 2102) (grade B) (units 1) (utility 1))
; (MAIN::course (department CS) (crn 3041) (grade B) (units 1) (utility 1))
; (MAIN::course (department CS) (crn 3043) (grade B) (units 1) (utility 1))
; (MAIN::course (department CS) (crn 3733) (grade B) (units 1) (utility 1))
;
; (MAIN::course (department CS) (crn 4514) (grade B) (units 1) (utility 1))
;
; (MAIN::course (department CS) (crn 4123) (grade B) (units 1) (utility 1))
;
; (MAIN::course (department CS) (crn 4233) (grade B) (units 1) (utility 1))
;
;
;
;
;
;
;
;
;
;
;
;
;
;
;
;
;
;
;
;
;
;
;
;
;
;
;
;
(MAIN::course (department GOV) (crn 2314) (grade B) (units 1) (utility 1))
(MAIN::course (department CS) (crn 4513) (grade B) (units 1) (utility 1))
(MAIN::course (department CS) (crn 3133) (grade B) (units 1) (utility 1))
(MAIN::course (department CS) (crn 4331) (grade B) (units 1) (utility 1))
(MAIN::course (department CS) (crn 4533) (grade B) (units 1) (utility 1))
(MAIN::course (department STS) (crn 2208) (grade B) (units 1) (utility 1))
(MAIN::MQP (id 1) (year 2006) (term A) (grade A) (units 1))
(MAIN::MQP (id 2) (year 2006) (term B) (grade A) (units 1))
(MAIN::MQP (id 3) (year 2006) (term B) (grade A) (units 1))
(MAIN::course (department PH) (crn 2204) (grade B) (units 1) (utility 1))
(MAIN::course (department PH) (crn 2198) (grade B) (units 1) (utility 1))
(MAIN::course (department CH) (crn 2001) (grade B) (units 1) (utility 1))
(MAIN::course (department CH) (crn 1005) (grade B) (units 1) (utility 1))
(MAIN::course (department GE) (crn 1200) (grade B) (units 1) (utility 1))
(MAIN::course (department MA) (crn 2204) (grade B) (units 1) (utility 1))
(MAIN::course (department MA) (crn 1100) (grade B) (units 1) (utility 1))
(MAIN::course (department MA) (crn 1220) (grade B) (units 1) (utility 1))
(MAIN::course (department MA) (crn 1005) (grade B) (units 1) (utility 1))
(MAIN::course (department MA) (crn 2621) (grade B) (units 1) (utility 1))
(MAIN::course (department MA) (crn 3440) (grade B) (units 1) (utility 1))
(MAIN::course (department CS) (crn 4032) (grade B) (units 1) (utility 1))
)
; Deffunctions
(deffunction print-list (?list)
(foreach ?item ?list
(printout t " " ?item crlf)))
(deffunction print-social-implications ()
(printout t "Social implications units now satisfied by: " crlf)
(if (> (length$ ?*CS-social-implications-used*) 0) then
(printout t "CS " ?*CS-social-implications-used* crlf))
(if (> (length$ ?*STS-social-implications-used*) 0) then
(printout t "STS " ?*STS-social-implications-used* crlf))
(if (> (length$ ?*GOV-social-implications-used*) 0) then
(printout t "GOV " ?*GOV-social-implications-used* crlf)))
;=======================================================
(defmodule CORE_COURSES)
;=======================================================
(defrule CORE_COURSES::header
(declare (salience ?*print-header*))
=>
(printout t crlf "ANALYZING CORE COURSES NOW..." crlf)
(printout t "-------------------------------------------------" crlf))
(defrule CORE_COURSES::check-for-CS-1101-or-1102
"Checks for CS 1101 or 1102 in core requirements"
?bc<-(MAIN::bin-count (bin core) (count ?c))
?course <-(MAIN::course (department CS) (crn ?crn&1101|1102))
=>
(modify ?bc (count (+ ?c 1)))
(bind ?*core-used* (insert$ ?*core-used* (+ 1 (length$ ?*core-used*)) (create$ ?crn)))
; appends this course to the used core list
(printout t " Core requirements partially satisfied by: CS " ?crn "" crlf)
(retract ?course))
(defrule CORE_COURSES::check-for-CS-2011
"Checks for CS 2011 in core requirements"
?bc<-(MAIN::bin-count (bin core) (count ?c))
?course <-(MAIN::course (department CS) (crn ?crn&2011))
=>
(modify ?bc (count (+ ?c 1)))
(bind ?*core-used* (insert$ ?*core-used* (+ 1 (length$ ?*core-used*)) (create$ ?crn)))
; appends this course to the used core list
(printout t " Core requirements partially satisfied by: CS 2011" crlf)
(retract ?course))
(defrule CORE_COURSES::check-for-CS-2022
"Checks for CS 2022 in core requirements"
?bc<-(MAIN::bin-count (bin core) (count ?c))
?course <-(MAIN::course (department CS) (crn ?crn&2022))
=>
(modify ?bc (count (+ ?c 1)))
(bind ?*core-used* (insert$ ?*core-used* (+ 1 (length$ ?*core-used*)) (create$ ?crn)))
; appends this course to the used core list
(printout t " Core requirements partially satisfied by: CS 2022" crlf)
(retract ?course))
(defrule CORE_COURSES::check-for-CS-2102
"Checks for CS 2102 in core requirements"
?bc<-(MAIN::bin-count (bin core) (count ?c))
?course <-(MAIN::course (department CS) (crn ?crn&2102))
=>
(modify ?bc (count (+ ?c 1)))
(bind ?*core-used* (insert$ ?*core-used* (+ 1 (length$ ?*core-used*)) (create$ ?crn)))
; appends this course to the used core list
(printout t " Core requirements partially satisfied by: CS 2102" crlf)
(retract ?course))
(defrule CORE_COURSES::check-for-CS-2223
"Checks for CS 2223 in core requirements"
?bc<-(MAIN::bin-count (bin core) (count ?c))
?course <-(MAIN::course (department CS) (crn ?crn&2223))
=>
(modify ?bc (count (+ ?c 1)))
(bind ?*core-used* (insert$ ?*core-used* (+ 1 (length$ ?*core-used*)) (create$ ?crn)))
; appends this course to the used core list
(printout t " Core requirements partially satisfied by: CS 2223" crlf)
(retract ?course))
(defrule CORE_COURSES::check-for-CS-2303
"Checks for CS 2303 in core requirements"
?bc<-(MAIN::bin-count (bin core) (count ?c))
?course <-(MAIN::course (department CS) (crn ?crn&2303))
=>
(modify ?bc (count (+ ?c 1)))
(bind ?*core-used* (insert$ ?*core-used* (+ 1 (length$ ?*core-used*)) (create$ ?crn)))
; appends this course to the used core list
(printout t " Core requirements partially satisfied by: CS 2303" crlf)
(retract ?course))
(defrule CORE_COURSES::check-for-CS-3013
"Checks for CS 3013 in core requirements"
?bc<-(MAIN::bin-count (bin core) (count ?c))
?course <-(MAIN::course (department CS) (crn ?crn&3013))
=>
(modify ?bc (count (+ ?c 1)))
(bind ?*core-used* (insert$ ?*core-used* (+ 1 (length$ ?*core-used*)) (create$ ?crn)))
; appends this course to the used core list
(printout t " Core requirements partially satisfied by: CS 3013" crlf)
(retract ?course))
(defrule CORE_COURSES::check-for-CS-3041
"Checks for CS 3041 in core requirements"
?bc<-(MAIN::bin-count (bin core) (count ?c))
?course <-(MAIN::course (department CS) (crn ?crn&3041))
=>
(modify ?bc (count (+ ?c 1)))
(bind ?*core-used* (insert$ ?*core-used* (+ 1 (length$ ?*core-used*)) (create$ ?crn)))
; appends this course to the used core list
(printout t " Core requirements partially satisfied by: CS 3041" crlf)
(retract ?course))
(defrule CORE_COURSES::check-for-CS-3133
"Checks for CS 3133 in core requirements"
?bc<-(MAIN::bin-count (bin core) (count ?c))
?course <-(MAIN::course (department CS) (crn ?crn&3133))
=>
(modify ?bc (count (+ ?c 1)))
(bind ?*core-used* (insert$ ?*core-used* (+ 1 (length$ ?*core-used*)) (create$ ?crn)))
; appends this course to the used core list
(printout t " Core requirements partially satisfied by: CS 3133" crlf)
(retract ?course))
(defrule CORE_COURSES::check-for-CS-3733
"Checks for CS 3733 in core requirements"
?bc<-(MAIN::bin-count (bin core) (count ?c))
?course <-(MAIN::course (department CS) (crn ?crn&3733))
=>
(modify ?bc (count (+ ?c 1)))
(bind ?*core-used* (insert$ ?*core-used* (+ 1 (length$ ?*core-used*)) (create$ ?crn)))
; appends this course to the used core list
(printout t " Core requirements partially satisfied by: CS 3733" crlf)
(retract ?course))
;=======================================================
(defmodule SYSTEMS)
;=======================================================
(defrule SYSTEMS::header
(declare (salience ?*print-header*))
=>
(printout t crlf "ANALYZING SYSTEMS COURSES NOW..." crlf)
(printout t "-------------------------------------------------" crlf))
(defrule SYSTEMS::check-for-CS-3013-or-4513-or-4514-or-4515
"Checks for computer science systems requiement"
?ctrl<-(MAIN::systems-is-unsatisfied)
?bc<-(MAIN::bin-count (bin systems) (count ?c))
?course<-(MAIN::course (department CS) (crn ?crn&3013|4513|4514|4515))
=>
(modify ?bc (count (+ ?c 1)))
(bind ?*systems-used* (insert$ ?*systems-used* (+ 1 (length$ ?*systems-used*))
(create$ ?crn))) ; appends this course to the used systems list
(printout t " Systems requirements partially satisfied by: CS " ?crn crlf)
(retract ?course ?ctrl))
;=======================================================
(defmodule THEORY_AND_LANGUAGE)
;=======================================================
(defrule THEORY_AND_LANGUAGE::header
(declare (salience ?*print-header*))
=>
(printout t crlf "ANALYZING THEORY AND LANGUAGE COURSES NOW..."
crlf)
(printout t "-------------------------------------------------" crlf))
(defrule THEORY_AND_LANGUAGE::check-for-CS-3133-or-4123-or-4533
"Checks for computer science theory and language requirement"
?ctrl<-(MAIN::theory-languages-is-unsatisfied)
?bc<-(MAIN::bin-count (bin theory-languages) (count ?c))
?course<-(MAIN::course (department CS) (crn ?crn&3133|4123|4533))
=>
(modify ?bc (count (+ ?c 1)))
(bind ?*theory-languages-used* (insert$ ?*theory-languages-used* (+ 1 (length$
?*theory-languages-used*)) (create$ ?crn))) ; appends this course to the used theorylanguages list
(printout t " Theory and languages requirements partially satisfied by: CS " ?crn crlf)
(retract ?course ?ctrl))
;=======================================================
(defmodule DESIGN)
;=======================================================
(defrule DESIGN::header
(declare (salience ?*print-header*))
=>
(printout t crlf "ANALYZING DESIGN COURSES NOW..." crlf)
(printout t "-------------------------------------------------" crlf))
(defrule DESIGN::check-for-CS-3041-or-3431-or-3733-or-4233
"Checks for computer science design requirement"
?ctrl<-(MAIN::design-is-unsatisfied)
?bc<-(MAIN::bin-count (bin design) (count ?c))
?course<-(MAIN::course (department CS) (crn ?crn&3133|4123|4533))
=>
(modify ?bc (count (+ ?c 1)))
(bind ?*design-used* (insert$ ?*design-used* (+ 1 (length$ ?*design-used*)) (create$
?crn))) ; appends this course to the used design list
(printout t " Design requirements partially satisfied by: CS " ?crn crlf)
(retract ?course ?ctrl))
;=======================================================
(defmodule SOCIAL_IMPLICATIONS)
;=======================================================
(defrule SOCIAL_IMPLICATIONS::header
(declare (salience ?*print-header*))
=>
(printout t crlf "ANALYZING SOCIAL IMPLICATIONS COURSES NOW..." crlf)
(printout t "-------------------------------------------------" crlf))
(defrule SOCIAL_IMPLICATIONS::check-for-CS-3043
"Checks for CS 3043 in social implications requirements"
?bc<-(MAIN::bin-count (bin social-implications) (count ?c))
?course <-(MAIN::course (department CS) (crn ?crn&3043))
=>
(modify ?bc (count (+ ?c 1)))
(bind ?*CS-social-implications-used*
(insert$ ?*CS-social-implications-used* (+ 1 (length$ ?*CS-social-implicationsused*)) (create$ ?crn)))
; appends this course to the CS-social-implications-used list
(printout t "SOCIAL IMPLICATIONS REQUIREMENTS PARTIALLY satisfied by:
CS 3043" crlf)
(retract ?course))
(defrule SOCIAL_IMPLICATIONS::check-for-STS-2208
"Checks for STS 2208 in social implications requirements"
?bc<-(MAIN::bin-count (bin social-implications) (count ?c))
?course <-(MAIN::course (department STS) (crn ?crn&2208))
=>
(modify ?bc (count (+ ?c 1)))
(bind ?*STS-social-implications-used*
(insert$ ?*STS-social-implications-used* (+ 1 (length$ ?*STS-social-implicationsused*)) (create$ ?crn)))
; appends this course to the used STS-social-implications-used list
(printout t "SOCIAL IMPLICATIONS REQUIREMENTS PARTIALLY SATISFIED
BY STS 2208" crlf)
(retract ?course))
(defrule SOCIAL_IMPLICATIONS::check-for-GOV-2314
"Checks for GOV 2314 in social implications requirements"
?bc<-(MAIN::bin-count (bin social-implications) (count ?c))
?course <-(MAIN::course (department GOV) (crn ?crn&2314))
=>
(modify ?bc (count (+ ?c 1)))
(bind ?*GOV-social-implications-used*
(insert$ ?*GOV-social-implications-used* (+ 1 (length$ ?*GOV-socialimplications-used*)) (create$ ?crn)))
; appends this course to the GOV-social-implications-used list
(printout t "SOCIAL IMPLICATIONS REQUIREMENTS PARTIALLY satisfied by:
CS 3043" crlf)
(retract ?course))
;=======================================================
(defmodule ADVANCED_LEVEL_COURSES)
;=======================================================
(defrule ADVANCED_LEVEL_COURSES::header
(declare (salience ?*print-header*))
=>
(printout t crlf "ANALYZING ADVANCED CS COURSES COURSES NOW..." crlf)
(printout t "-------------------------------------------------" crlf))
(defrule ADVANCED_LEVEL_COURSES::check-for-advanced-design-requirement
"Checks for computer science advanced design requirement"
?ctrl<-(MAIN::advanced-design-is-unsatisfied)
?bc<-(MAIN::bin-count (bin advanced-design) (count ?c))
?course <-(MAIN::course (department CS) (crn ?crn&3041|3431|3733|4233))
=>
(modify ?bc (count (+ ?c 1)))
(bind ?*advanced-design-used*
(insert$ ?*advanced-design-used* (+ 1 (length$ ?*advanced-design-used*)) (create$
?crn)))
; appends this course to the used STS-social-implications-used list
(printout t "ADVANCED DESIGN REQUIREMENTS PARTIALLY satisfied by: CS
" ?crn crlf)
(retract ?course ?ctrl))
(defrule ADVANCED_LEVEL_COURSES::check-for-advanced-systems-requirement
"Checks for computer science advanced systems requirement"
?ctrl<-(MAIN::advanced-systems-is-unsatisfied)
?bc<-(MAIN::bin-count (bin advanced-systems) (count ?c))
?course <-(MAIN::course (department CS) (crn ?crn&3013|4513|4514|4515))
=>
(modify ?bc (count (+ ?c 1)))
(bind ?*advanced-systems-used*
(insert$ ?*advanced-systems-used* (+ 1 (length$ ?*advanced-systems-used*))
(create$ ?crn)))
; appends this course to the used advanced-systems list
(printout t "ADVANCED Systems requirements partially satisfied by: CS " ?crn crlf)
(retract ?course ?ctrl))
(defrule ADVANCED_LEVEL_COURSES::check-for-advanced-theory-languagesrequirement
"Checks for computer science advanced theory and languages requirement"
?ctrl<-(MAIN::advanced-theory-languages-is-unsatisfied)
?bc<-(MAIN::bin-count (bin advanced-theory-languages) (count ?c))
?course <-(MAIN::course (department CS) (crn ?crn&3133|4123|4533))
=>
(modify ?bc (count (+ ?c 1)))
(bind ?*advanced-systems-used*
(insert$ ?*advanced-theory-languages-used* (+ 1 (length$ ?*advanced-theorylanguages-used*)) (create$ ?crn)))
; appends this course to the used advanced-theory-languages list
(printout t "ADVANCED THEORY AND LANGUAGES REQUIREMENTS
PARTIALLY satisfied by: CS " ?crn crlf)
(retract ?course ?ctrl))
(defrule ADVANCED_LEVEL_COURSES::check-for-advanced-social-implicationsrequirement
"Checks for computer science advanced social implications requirement"
?ctrl<-(MAIN::advanced-social-implications-is-unsatisfied)
?bc<-(MAIN::bin-count (bin advanced-social-implications) (count ?c))
?course<-(or
(MAIN::course (department ?dept&CS) (crn ?crn&3043))
(MAIN::course (department ?dept&SS) (crn ?crn&2208|2314))); end OR
=>
(modify ?bc (count (+ ?c 1)))
(bind ?*advanced-social-implications-used*
(insert$ ?*advanced-social-implications-used* (+ 1 (length$ ?*advanced-socialimplications-used*)) (create$ ?crn)))
; appends this course to the advanced-social-implications-used list
(printout t "ADVANCED SOCIAL IMPLICATIONS REQUIREMENTS
PARTIALLY SATISFIED BY " ?dept " " ?crn crlf)
(retract ?course ?ctrl))
;=======================================================
(defmodule COMPUTER_SCIENCE_MQP)
;=======================================================
(defrule COMPUTER_SCIENCE_MQP::header
(declare (salience ?*print-header*))
=>
(printout t crlf "ANALYZING MQP UNITS NOW..." crlf)
(printout t "-------------------------------------------------" crlf))
(defrule COMPUTER_SCIENCE_MQP::check-for-MQP-requirement
"Tally all MQP units and compare to minimum"
?bc<-(MAIN::bin-count (bin MQP) (count ?c))
?mqp <-(MAIN::MQP (id ?id)(units ?u) (year ?y) (term ?t) (grade ?g))
=>
(modify ?bc (count (+ ?c 1)))
(printout t "MQP REQUIREMENTS PARTIALLY SATISFIED BY MQP[id:" ?id "
year:" ?y " term:" ?t " grade:" ?g "]" crlf)
(retract ?mqp))
;=======================================================
(defmodule SCIENCE)
;=======================================================
(defrule SCIENCE::header
(declare (salience ?*print-header*))
=>
(printout t crlf "ANALYZING SCIENCE UNITS NOW..." crlf)
(printout t "-------------------------------------------------" crlf))
(defrule SCIENCE::check-for-general-science-requirement
"General set BB, BME, CE, CH, CHE, ECE, ES, GE, ME, PH"
?ctrl<-(science-is_unsatisfied)
?bc<-(MAIN::bin-count (bin science) (count ?c))
?course1<-(MAIN::course (crn ?crn1) (department ?dept1&BB|CH|GE|PH))
?course2<-(MAIN::course (crn ?crn2&~?crn1) (department
?dept2&BB|CH|GE|PH&:(eq ?dept1 ?dept2)))
?course3<-(MAIN::course (crn ?crn3) (department ?dept3&~?dept2&BB|CH|GE|PH))
?course4<-(MAIN::course (crn ?crn4) (department
?dept4&BB|BME|CE|CH|CHE|ECE|ES|GE|ME|PH))
?course5<-(MAIN::course (crn ?crn5) (department
?dept5&BB|BME|CE|CH|CHE|ECE|ES|GE|ME|PH))
=>
(modify ?bc (count 5))
(printout t " Science units now satisfied by:" crlf)
(printout t " " ?dept1 " " ?crn1 crlf)
(printout t " " ?dept2 " " ?crn2 crlf)
(printout t " " ?dept3 " " ?crn3 crlf)
(printout t " " ?dept4 " " ?crn4 crlf)
(printout t " " ?dept5 " " ?crn5 crlf)
(retract ?course1 ?course2 ?course3 ?course4 ?course5 ?ctrl))
;=======================================================
(defmodule STATISTICS)
;=======================================================
(defrule STATISTICS::header
(declare (salience ?*print-header*))
=>
(printout t crlf "ANALYZING STATISTICS UNITS NOW..." crlf)
(printout t "-------------------------------------------------" crlf))
(defrule STATISTICS::check-for-statistics-requirements
"Checks for computer science statistics requirement"
?ctrl<-(MAIN::statistics-is-unsatisfied)
?bc<-(MAIN::bin-count (bin statistics) (count ?c))
?course<-(MAIN::course (department MA) (crn ?crn&2611|2612))
=>
(modify ?bc (count (+ ?c 1)))
(bind ?*statistics-used*
(insert$ ?*statistics-used* (+ 1 (length$ ?*statistics-used*)) (create$ ?crn)))
; appends this course to statistics-used list
(printout t "STATISTICS REQUIREMENTS SATISFIED BY MA " ?crn crlf)
(retract ?course ?ctrl))
;=======================================================
(defmodule PROBABILITY)
;=======================================================
(defrule PROBABILITY::header
(declare (salience ?*print-header*))
=>
(printout t crlf "ANALYZING PROBABILITY UNITS NOW..." crlf)
(printout t "-------------------------------------------------" crlf))
(defrule PROBABILITY::check-for-probability-requirements
"Checks for computer science probability requirement"
?ctrl<-(MAIN::probability-is-unsatisfied)
?bc<-(MAIN::bin-count (bin probability) (count ?c))
?course<-(MAIN::course (department MA) (crn ?crn&2621|2631))
=>
(modify ?bc (count (+ ?c 1)))
(bind ?*probability-used*
(insert$ ?*probability-used* (+ 1 (length$ ?*probability-used*)) (create$ ?crn)))
; appends this course to the probability used list
(printout t "PROBABILITY REQUIREMENTS SATISFIED BY MA " ?crn crlf)
(retract ?course ?ctrl))
;=======================================================
(defmodule MATHEMATICS)
;=======================================================
(defrule MATHEMATICS::header
(declare (salience ?*print-header*))
=>
(printout t crlf "ANALYZING MATHEMATICS UNITS NOW..." crlf)
(printout t "-------------------------------------------------" crlf))
(defrule check-for-math-requirement
"Checks for computer science basic mathematics requirements"
?ctrl<-(mathematics-is-unsatisfied)
?pbc<-(MAIN::bin-count (bin probability) (count ?pc))
?sbc<-(MAIN::bin-count (bin statistics) (count ?sc))
?mbc<-(MAIN::bin-count (bin mathematics) (count ?mc))
?course1 <-(MAIN::course (department ?dept1&MA) (crn ?crn1&:(> ?crn1 999))) ; \
?course2 <-(MAIN::course (department ?dept2&MA) (crn ?crn2&~?crn1&:(> ?crn2
999))) ; \_____ four must be 1000 or higher
?course3 <-(MAIN::course (department ?dept3&MA) (crn ?crn3&~?crn1&~?crn2&:(>
?crn3 999))) ; /
?course4 <-(MAIN::course (department ?dept4&MA) (crn
?crn4&~?crn1&~?crn2&~?crn3&:(> ?crn4 999))) ; /
?course5 <-(or
(MAIN::course (department ?dept5&MA) (crn ?crn5&:(> ?crn5 1999))) ; a fifth
must be MA > 2000 OR a CS from 2022|4032|4033
(MAIN::course (department ?dept5&CS) (crn ?crn5&2022|4032|4033)) ;
); end OR
=>
(modify ?mbc (count (+ ?pc ?sc 5)))
(printout t " Mathematics units now satisfied by:" crlf)
(printout t " " ?dept1 " " ?crn1 crlf)
(printout t " " ?dept2 " " ?crn2 crlf)
(printout t " " ?dept3 " " ?crn3 crlf)
(printout t " " ?dept4 " " ?crn4 crlf)
(printout t " " ?dept5 " " ?crn5 crlf)
(retract ?course1 ?course2 ?course3 ?course4 ?course5 ?ctrl))
;=======================================================
(defmodule AUDITOR)
;=======================================================
(defrule AUDITOR::header
(declare (salience ?*print-header*))
=>
(printout t crlf "PERFORMING AUDIT NOW..." crlf)
(printout t "-------------------------------------------------" crlf))
(defrule AUDITOR::all-core-units-satisfied
"Mark when core requirements are met"
(declare (salience ?*satisfaction-check-priority*))
(MAIN::bin-count (bin core) (count ?*core-min-units*))
=>
(assert (MAIN::core-units-satisfied))
(printout t " Core units now satisfied by: CS courses: " ?*core-used* crlf))
(defrule AUDITOR::all-systems-units-satisfied
"Mark when systems requirements are met"
(declare (salience ?*satisfaction-check-priority*))
(MAIN::bin-count (bin systems) (count ?*systems-min-units*))
=>
(assert (MAIN::systems-units-satisfied))
(printout t " Systems units now satisfied by: CS courses: " ?*systems-used* crlf))
(defrule AUDITOR::all-theory-languages-units-satisfied
"Mark when theory and languages requirements are met"
(declare (salience ?*satisfaction-check-priority*))
(MAIN::bin-count (bin theory-languages) (count ?*theory-languages-min-units*))
=>
(assert (MAIN::theory-languages-units-satisfied))
(printout t " Theory and languages units now satisfied by: CS courses: " ?*theorylanguages-used* crlf))
(defrule AUDITOR::all-design-units-satisfied
"Mark when design requirements are met"
(declare (salience ?*satisfaction-check-priority*))
(MAIN::bin-count (bin design) (count ?*design-min-units*))
=>
(assert (MAIN::systems-design-satisfied))
(printout t " Design units now satisfied by CS courses: " ?*design-used* crlf))
(defrule AUDITOR::all-social-implications-units-satisfied
"Mark when social implications requirements are met"
(declare (salience ?*satisfaction-check-priority*))
(MAIN::bin-count (bin social-implications) (count ?*social-implications-min-units*))
=>
(assert (MAIN::social-implications-units-satisfied))
(print-social-implications))
(defrule AUDITOR::all-advanced-units-satisfied
"Mark when advanced CS requirements are met"
(declare (salience ?*satisfaction-check-priority*))
(MAIN::bin-count (bin advanced-systems) (count ?c1))
(MAIN::bin-count (bin advanced-design) (count ?c2))
(MAIN::bin-count (bin advanced-social-implications) (count ?c3))
(MAIN::bin-count (bin advanced-theory-languages) (count ?c4&:(>= (+ ?c1 ?c2 ?c3
?c4) ?*advanced-level-min-units*)))
=>
(assert (MAIN::advanced-units-satisfied)))
(defrule AUDITOR::all-MQP-units-satisfied
"Mark when MQP requirements are met"
(declare (salience ?*satisfaction-check-priority*))
(MAIN::bin-count (bin MQP) (count ?c&?*MQP-min-units*))
=>
(assert (MAIN::MQP-units-satisfied)))
(defrule AUDITOR::all-computer-science-requirements-satisfied
(MAIN::core-units-satisfied)
(MAIN::systems-units-satisfied)
(MAIN::theory-languages-units-satisfied)
(MAIN::design-units-satisfied)
(MAIN::social-implications-units-satisfied)
(MAIN::advanced-units-satisfied)
(MAIN::MQP-units-satisfied)
=>
(MAIN::computer-science-satisfied))
(defrule AUDITOR::all-science-units-satisfied
"Mark when science requirements are met"
(declare (salience ?*satisfaction-check-priority*))
(MAIN::bin-count (bin science) (count ?*science-min-units*))
=>
(assert (MAIN::science-units-satisfied)))
(defrule AUDITOR::all-science-units-satisfied
"Mark when science requirements are met"
(declare (salience ?*satisfaction-check-priority*))
(MAIN::bin-count (bin science) (count ?*science-min-units*))
=>
(assert (MAIN::science-units-satisfied)))
(defrule AUDITOR::all-mathematics-units-satisfied
"Mark when general mathematics requirements are met"
(declare (salience ?*satisfaction-check-priority*))
(MAIN::bin-count (bin mathematics) (count ?c1))
(MAIN::bin-count (bin probability) (count ?c2&?*probability-min-units*))
(MAIN::bin-count (bin statistics) (count ?c3&?*statistics-min-units*&:(>= (+ ?c1 ?c2
?c3) ?*mathematics-min-units*)))
=>
(assert (MAIN::mathematics-units-satisfied)))
(defrule AUDITOR::transcript-meets-all-requirments
"Fires if student has met all graduation requirements in CS departement for 20062007"
(declare (salience ?*satisfaction-check-priority*))
(MAIN::computer-science-satisfied)
(MAIN::science-satisfied)
(MAIN::mathematics-satisfied)
=>
(printout t
"===============================================================
============" crlf)
(printout t "STUDENT HAS SUCCESSFULLY MET ALL CS DEPARTMENT
REQUIREMENTS FOR GRADUATION" crlf)
(printout t "ACCORDING TO THE 2006-2007 UNDERGRADUATE CATALOG."
crlf)
(printout t
"===============================================================
============" crlf)
)
(defrule AUDITOR::is-missing-core-requirement
(declare (salience ?*remediation-priority*))
(not (MAIN::core-units-satisfied))
(MAIN::bin-count (bin core) (count ?count))
=>
(printout t "STUDENT IS MISSING " (- ?*core-min-units* ?count) " CORE
REQUIREMENT(S)" crlf)
(printout t " Please select from the following CS CORE COURSES: "
(complement$ ?*core-used* ?*core-courses*) crlf))
(defrule AUDITOR::is-missing-systems-requirement
(declare (salience ?*remediation-priority*))
(not (MAIN::systems-units-satisfied))
(MAIN::bin-count (bin systems) (count ?count))
=>
(printout t "STUDENT IS MISSING " (- ?*systems-min-units* ?count) " systems
REQUIREMENT(S)" crlf)
(printout t " Please select from the following CS systems COURSES: "
(complement$ ?*systems-used* ?*systems-courses*) crlf))
(defrule AUDITOR::is-missing-design-requirement
(declare (salience ?*remediation-priority*))
(not (MAIN::design-units-satisfied))
(MAIN::bin-count (bin design) (count ?count))
=>
(printout t "STUDENT IS MISSING " (- ?*design-min-units* ?count) " design
REQUIREMENT(S)" crlf)
(printout t " Please select from the following CS design COURSES: "
(complement$ ?*design-used* ?*design-courses*) crlf))
(defrule AUDITOR::is-missing-theory-languages-requirement
(declare (salience ?*remediation-priority*))
(not (MAIN::theory-languages-units-satisfied))
(MAIN::bin-count (bin theory-languages) (count ?count))
=>
(printout t "STUDENT IS MISSING " (- ?*theory-languages-min-units* ?count) "
theory-languages REQUIREMENT(S)" crlf)
(printout t " Please select from the following CS theory-languages COURSES: "
(complement$ ?*theory-languages-used* ?*theory-languages-courses*) crlf))
(defrule AUDITOR::is-missing-social-implications-requirement
(declare (salience ?*remediation-priority*))
(not (MAIN::social-implications-units-satisfied))
(MAIN::bin-count (bin social-implications) (count ?count))
=>
(printout t "STUDENT IS MISSING " (- ?*social-implications-min-units* ?count) "
social-implications REQUIREMENT(S)" crlf)
(printout t " Please select from the following CS social-implications COURSES: "
(complement$ ?*CS-social-implications-used* ?*CS-social-implications-courses*)
crlf)
(printout t " Please select from the following STS social-implications COURSES: "
(complement$ ?*STS-social-implications-used* ?*STS-social-implicationscourses*) crlf)
(printout t " Please select from the following GOV social-implications COURSES: "
(complement$ ?*GOV-social-implications-used* ?*GOV-social-implicationscourses*) crlf))
(defrule AUDITOR::is-missing-advanced-CS-requirements
(declare (salience ?*remediation-priority*))
(not (MAIN::advanced-units-satisfied))
(MAIN::bin-count (bin advanced-design) (count 1))
(MAIN::bin-count (bin advanced-theory-languages) (count 1))
(MAIN::bin-count (bin advanced-social-implications) (count 1))
(MAIN::bin-count (bin advanced-systems) (count 1))
=>
(printout t "STUDENT IS MISSING " (- ?*theory-languages-min-units* ?count) "
theory-languages REQUIREMENT(S)" crlf)
(printout t " Please select from the following CS theory-languages COURSES: "
(complement$ ?*theory-languages-used* ?*theory-languages-courses*) crlf))
; PROGRAM
(reset)
(focus
CORE_COURSES
SYSTEMS
THEORY_AND_LANGUAGE
DESIGN
SOCIAL_IMPLICATIONS
ADVANCED_LEVEL_COURSES
COMPUTER_SCIENCE_MQP
SCIENCE
MATHEMATICS
STATISTICS
PROBABILITY
AUDITOR
)
(run)