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.
SCL specification for the constructor-calls-overridable rule:
In Eclipse, checking SCL rules is as easy as a click of a button:
SCL provides the whole context of an error, not only a single
statement as a compiler does.
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.
Note that virtual2
accesses msg without
initializing it, but virtual1
has no problem as it does not access any instance variable of Sub:
