Browse Prior Art Database

User-Directed Rules Checking

IP.com Disclosure Number: IPCOM000104915D
Original Publication Date: 1993-Jun-01
Included in the Prior Art Database: 2005-Mar-19

Publishing Venue

IBM

Related People

Slisz, RL: AUTHOR

Abstract

A method for allowing a user to direct a programming language analyzer's rule checking via a rules file is disclosed. The rules file coexists in the same library control system as the source parts being checked.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 45% of the total text.

User-Directed Rules Checking

      A method for allowing a user to direct a programming language
analyzer's rule checking via a rules file is disclosed.  The rules
file coexists in the same library control system as the source parts
being checked.

      The user directs a programming language analyzer's rule
checking via a rules file.  In a development environment that has
hundreds of programmers, there are many interpretations of the
severity of rule violations.  When a language analyzer sets a default
severity that is unacceptable to all parties, the diagnostic message
for that rule violation is either removed from the analyzer or
assigned the lowest possible severity (i.e., "informational").  This
usually results in a failure to detect error conditions.

      After the initial release of a language analyzer, there is
often a significant number of requests to add new rules to be
checked.  The rules file provides a mechanism to direct the language
analyzer to check those new rules that are applicable for the user.
This satisfies the needs of the requester and prevents any impact to
the majority of users.

      The rules file coexists in the same library control system as
the source parts being checked.  This provides the capability to
define new severity levels for product release n versus release n-1
without requiring a language analyzer change.  Within the development
cycle of a release, if the defined rule severity changes, all parts
affected by this change will be automatically recompiled.

      Users are given an interface that is flexible enough to allow
the rule severity to be defined per part, per component and/or per
product in that precedence order.  The user is given the option of
telling an analyzer NOT to check a specific rule.  The language
analyzer will not perform a rule check by default.  If the scope of
the rule is product wide, the analyzer can be told to validate the
rule via the product level rules file.  If the scope of the rule is
component wide, the analyzer can be told to validate the rule via the
component level rules file.  If the scope of the rule is part
specific, the analyzer can be told to validate the rule via the part
level rules file.

      To illustrate the invention, the implementation for a code
analyzer ("module checker") that is optionally invoked during a
compile process is described.  If the code analysis option was
specified, the compile process looks for a rules file in the library
control system.  The rules file has a pre-defined part type, for
example, "MODCHECK", that makes it unique in the library.  (Assume
that parts in the library control system are identified by product
name, version name, part type name and part name.)

      Users can create one rules file for an entire product by making
the MODCHECK part name the same as the product name.  Users can
create one rules file for a component by making the MODCHECK part
name the same as the compo...