Usage contracts (presented at SATToSE 2014 in L'Aquila, Italy)
2 likes1,124 views
The document discusses usage contracts in software development, which aim to encode and enforce structural regularities within source code. It presents findings from a case study involving an interactive web application developed in Pharo Smalltalk, where various contract violations were identified during validations. The authors advocate for the integration of a proactive tool that offers immediate feedback to developers, enhancing their ability to maintain code quality and consistency.
Usage contracts (presented at SATToSE 2014 in L'Aquila, Italy)
- 1. USAGE CONTRACTS* KIM MENS UNIVERSITÉ CATHOLIQUE DE LOUVAIN (UCL) JOINT WORK WITH ANGELA LOZANO ANDY KELLENS SATTOSE 2014 – L’AQUILA – 9-11.07.2014 * SLIDES LARGELY BASED ON AN EARLIER PRESENTATION MADE BY ANGELA LOZANO
- 2. SOME OF MY RESEARCH INTERESTS Programming languages Context-Oriented Programming Language interoperability between logic and OO (Aspect-oriented programming ✞) Tool support for software development, maintenance and evolution source code mining source-code based recommendation tools structural source-code regularities (e.g. usage contracts)
- 3. USAGE CONTRACTS : MOTIVATION Often you find code comments like ! ! ! ! ! ! ! ! ! ! /** * 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(); } }
- 4. USAGE CONTRACTS : MOTIVATION Often you find code comments like ! ! ! ! We studied JHotDraw for occurrences of “should, may, must, can(not), could, ought, have, has, need, require, ….” and found 22 structural regularities like : ! ! ! ! ! /** * 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(); } } subclassers of this class should call … this class should not do a supercall … must implement … should (not) override methods in this class … only be called by … this method only be called internally be called after …
- 5. USAGE CONTRACTS : GOAL /** * 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
- 6. METAPHOR Provider uses Consumer Usage Contract describes expectations of should comply with
- 7. 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
- 8. 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
- 9. UCONTRACTS : THE LANGUAGE EContract Liable classes •liableClass: regExp / exceptClass: regExp •liableHierarchy: className / exceptHierarchy: className •liablePackage: regExp / exceptPackage: regExp 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 Liable methods •selector: regExp / exceptSelector: regExp •protocol: regExp / exceptProtocol: regExp •/ exceptClass: className selector: selector Contract terms •require: condition •suggest: condition •require: condition if: anotherCondition •suggest: condition if: anotherCondition Contract conditions •assigns: regExp •calls: regExp •references: regExp •returns: expression •doesSuperSend: regExp •doesSelfSend: regExp •inProtocol: regExp •isOverridden: selector •isOverridden •isImplemented: selector •custom: visitor ! •and: cond1 with: cond2 •or: cond1 with: cond2 •not: cond ! •beginsWith: cond •endsWith: cond •does: cond1 after: cond2 •does: cond1 before: cond2
- 10. UCONTRACTS : THE TOOL
- 11. VALIDATION ON AN INDUSTRIAL CASE • An interactive web application for event & resource planning • developed in Pharo Smalltalk • uses the Seaside web development framework. • Medium-sized • Packages: 45 • Classes: 827 • Methods: 11777 • LOCs: 94151
- 12. INDUSTRIAL VALIDATION : SET-UP OF THE EXPERIMENT • Qualitative assessment • Ideally we would have liked the tool to be used directly by the developers, but instead we had to perform an offline experiment. • Together with the developers, during 2 days we defined 13 contracts documenting important regularities in their framework • We checked all contracts in December and reported all contract breaches to the developers • 3 months later, we reverified compliance of the code against the same contracts
- 13. INDUSTRIAL VALIDATION : ABOUT THE CONTRACTS • contracts related to the model of the web application • for 3/5 of them violations were found • 214 liable classes, 88 violations • contracts related to the classes dealing with persistency • for 2/2 of them violations where found • 75 liable classes, 2 violations found • contracts about how the UI is constructed with the Seaside framework • for 4/6 of them violations where found • 598 liable classes, 8 violations found
- 14. INDUSTRIAL VALIDATION : EXAMPLE OF A CONTRACT Private methods should not be called directly liable classes contract
- 15. INDUSTRIAL VALIDATION : EXAMPLE OF A CONTRACT In domain classes, state changes must mark model objects as dirty so that they can be re-rendered liable classes contract
- 16. INDUSTRIAL VALIDATION : EXAMPLE OF A CONTRACT Overridden initialisation methods should start with a super call (and be put in an appropriate protocol) liable classes contract
- 17. INDUSTRIAL VALIDATION : EXAMPLE OF A CONTRACT Certain messages need to be sent at the end of a method cascade liable classes contract
- 18. INDUSTRIAL VALIDATION : EXAMPLE OF A CONTRACT Certain messages need to be sent at the end of a method cascade liable classes contract contract WithInCascadeVisitor extends CustomConditionVisitor
- 19. INDUSTRIAL VALIDATION : RESULTS Contract Liable Methods Exceptions Errors December Errors March Private methods should not be called directly 7410 0 3 2 Marking dirty objects 333 5 7 2 Initialisation methods should 44 0 1 0 start with super Call ordering within method cascade 531 0 0 0
- 20. UCONTRACTS : CONCLUSION • uContracts offer a simple unit-testing like way for letting programmers document and check conformance to structural source-code regularities • using a “contract” metaphor • focus on immediate feedback during development • embedded DSL close to the programming language • tight integration with the IDE • Publication pending: A. Lozano, K. Mens, and A. Kellens, “Usage contracts: offering immediate feed- back on violations of structural source-code regularities”. (submitted to SciCo)
- 21. FUTURE WORK • More validation • Improve / extend the DSL • Port to most recent version of Pharo • uContracts for other languages (e.g., Ruby)