Project Title


SCL: the Structural Constraint Language

Follow the procedure below to get a quick taste of SCL:

(1) download the SCL jar file and copy it into your Eclipse plugins directory.

(2) download the sclDemo.tar.gz file and import it into your workspace as an Eclipse Java project. This project contains a set of SCL rules (in files ended with .scl) for the equals/hashCode contracts.

(3) Restart Eclipse. You should see a red-bug button appearing on the tool bar. Click it to invoke SCL checking on the sclDemo project. You should see an error message on the Point2D class that says it misses hashCode().

Project Goals


Software developers often fail to respect design intent due to either missing or ignored documentation of intent. SCL (Structural Constraint Language) helps capture and confirm aspects of design intent by using structural constraints on a program model extracted through static analysis. The original designer expresses design intent in terms of constraints on the program model using the SCL language, and the SCL conformance checking tool examines developer code to confirm that the code honors these constraints.

There are several goals for SCL. We want SCL to be as expressive as possible so that it can be used to specify a wide range of constraints. The SCL checker must be efficient, but we are willing to trade performance for stronger analysis. Finally, SCL must have a formal foundation so that on which a reliable checker can be built, and more importantly, users can predict and reason about its behavior.

SCL has been used to specify and check constraints for an industrial project, several open-source projects, and by a dozen of graduate students on a number of course projects. We are interested in applying SCL in more real-world projects.


If you want to discuss the SCL for Java, send Daqing Hou an email (dhou clarkson edu).

References

[1] Using SCL to Specify and Check Design Intent in Source Code. Daqing Hou, H. James Hoover. IEEE Transactions on Software Engineering, June 2006.
[2] Specifying Framework Constraints with FCL. D. Hou et al. In proceedings of CASCON 2004.
[3] Specifying the Law of Demeter and C++ Programming Guidelines with FCL. D. Hou et al. In proceedings of SCAM 2004.

A Demo: Constructors calling overridable methods

In Java, if a constructor invokes a method that is overridden by a method in a subclass, and if the override accesses an instance variable of the subclass without initializing it, then it is likely that a program failure will occur. In order to avoid this kind of an error, some textbooks go so far as to advise ``Constructors must not invoke overridable methods, directly or indirectly.'' Such a formulation of a rule is too coarse-grained as not all invocations of overridable methods by constructors are illegal. In reality we have seen developers following this rule religiously, causing them to produce sub optimal designs that are error prone for clients to use.

The following are a series of screen shots that demonstrate how SCL foregoes legitimate invocations of overridable methods and detects the illegal ones.

Source listing for Super.java

Source listing for Sub.java


SCL specification for the constructor-calls-overridable rule:


Source listing for the SCL rule


In Eclipse, checking SCL rules is as easy as a click of a button:


invoking SCL in Eclipse



SCL provides the whole context of an error, not only a single statement as a compiler does.


SCL provides detailed diagnostics. 



In this case, Super(int) indirectly invokes virtual1 and virtual2. Because virtual2 is overridden in Sub, and the override accesses msg without initializing it, both Super(int) and virtual2 are marked as part of the error.


Super.java after checking


Note that virtual2 accesses msg without initializing it, but virtual1 has no problem as it does not access any instance variable of Sub:


Super.java after SCL checking