Developers often encode design knowledge through structural regularities such as API usage protocols, coding idioms and naming conventions. As these regularities express how the source code should be structured, they provide vital information for developers (re)using that code. Adherence to such regularities tends to deteriorate over time when they are not documented and checked explicitly. Our uContracts tool and approach allows to codify and verify such regularities as ‘usage contracts’. The contracts are expressed in an internal domain-specific language that is close to the host programming language, the tool is tightly integrated with the development environment and provides immediate feedback during development when contracts get breached, but the tool is not coercive and allows the developer to decide if, when and how to correct the broken contracts (the tool just highlights the errors and warnings in the integrated development environment). In spirit, the approach is very akin to unit testing, except that we do not test behaviour, but rather verify program structure. The tool, of which some screenshots can be found below, was prototyped in the Pharo dialect of the Smalltalk programming language.
This work was conducted by Angela Lozano, Andy Kellens and Kim Mens.
OpenChain - The Ramifications of ISO/IEC 5230 and ISO/IEC 18974 for Legal Pro...
Usage contracts in a nutshell
1. USAGE CONTRACTS*
KIM MENS
UNIVERSITÉ CATHOLIQUE DE LOUVAIN (UCL)
JOINT WORK WITH
ANGELA LOZANO
ANDY KELLENS
DAGSTUHL SEMINAR – “THE FUTURE OF REFACTORING”
LIGHTNING TALK – 21.05.2014
* SLIDES LARGELY BASED ON AN EARLIER PRESENTATION MADE BY ANGELA LOZANO
2. USAGE CONTRACTS
/**
* Deactivates the tool. This method is called whenever the user switches to another tool
* Use this method to do some clean-up when the tool is switched.
* Subclassers should always call super.deactivate.
* An inactive tool should never be deactivated.
*/
public void deactivate() {
if (isActive()) {
if (getActiveView() != null) {
getActiveView().setCursor(new AWTCursor(java.awt.Cursor.DEFAULT_CURSOR));
}
getEventDispatcher().fireToolDeactivatedEvent();
}
}
• We want a tool that allows encoding such regularities and offering immediate
feedback on violations of such structural source-code regularities
• The tool should be proactive (violations reported ‘on the fly’ during coding)
• The tool should be “developer-friendly” (like unit testing but for usage expectations)
• desired regularities expressed in the same programming language
• tight integration with the integrated development environment
• not coercive
3. METAPHOR
Provider
uses
Consumer
Usage
Contract
describes
expectations
of
should
comply
with
4. EXAMPLE
copyFrom: anEntity within: aVisitor
inherits
from
copyFrom: anEntity within: aVisitor
super copyFrom: anEntity within: aVisitor
...
All overriders of
copyFrom:within:
should start with a
super call
describes
expectations
of
should
comply
with
5. EXAMPLE
copyFrom: anEntity within: aVisitor
inherits
from
copyFrom: anEntity within: aVisitor
super copyFrom: anEntity within: aVisitor
...
All overriders of
copyFrom:within:
should start with a
super call
describes
expectations
of
should
comply
with
EContract
classesInFAMIXSourcedEntityHierarchy
<liableHierarchy:#FAMIXSourcedEntity>
FAMIXSourcedEntityContract
classesInFAMIXSourcedEntityHierarchy
copyFromWithinWithCorrectSuperCall
Liable
entity
copyFromWithinWithCorrectSuperCall
<selector:#copyFrom:within:>
contract
require:
condition beginsWith:
(condition doesSuperSend: #copyFrom:within:)
if: (condition isOverridden)
Contract
term
Contract
conditions