Design Rules for Increasing Modularity with Caesar J

Design Rules for Increasing Modularity with Caesar. J Carlos Eduardo Pontual Advisor: Paulo Borba 17/06/2010

Aspect-Oriented Software Development ____________________________ • Better modularize the crosscutting-concerns • Distribution, persistence, transaction management • Aims to increase Software Modularity 2

Does AOP increase Modularity? ____________________________ What if I change set. X to Point does not update change. X? Display? • Compromises class comprehensibility • Changes in a class might break aspects intents • Parallel development is difficult 3

So, AOP… ____________________________ Increases Crosscutting Modularity But… Harms Class Modularity. Is it possible to avoid that? 4

Improving Modularity OO/AO ____________________________ • Brief specification of relations/restrictions between classes and aspects • Design Rules • Interfaces: Information Hiding • Decouple classes and aspects • Guide developers • Existing solutions (XPIs, LSD) • Aspect. J 5

Caesar. J ____________________________ • Increase support for aspect modularity • Aspects implementation and binding • No difference between classes and aspects • Aspect: cclass with pointcuts/advice • Aspectual polymorphism • Aspect Collaboration Interface (ACI) • ACIs can be partially implemented • Composition using mixins 6

ACI Example ____________________________ public cclass Graph { public cclass Edge { Node start, end; } public cclass Directed. Edge extends Edge { int direction; } public abstract cclass Node { public abstract void get. State(); } } 7

Hypothesis ____________________________ The specification of proper DRs in Caesar. J allow a modular (independent) development of OO and AO code Is it possible to specify proper DRs with Caesar. J constructs/mechanisms? 8

Motivating Example ____________________________ • Tetris games SPL for mobile phones • Difficulty feature: Easy and normal variations, among others. 9

Variation details ____________________________ 10

Implementations ____________________________ • Multiple implementations of the Difficulty Feature • Different modularization techniques / mechanisms • Template Method • Extended • Mixin Composition • For each mechanism, two implementations: with or without using ACIs 11

Enhanced TM __________ • Roles not well defined on the interface (P 2) • Not enough for parallel (independent) development • No independent compilation of common/variant code (inheritance) (P 3) 12

Mixin composition – ACI ____________________________ • Common and Variation code are independent (solve P 3) • Virtual class overhead (P 4) 13

ACI – Mixin Composition ____________________________ • • Common and variation code are independent (solve P 3) Overhead of virtual classes – P 4 Developers handle instances of Mixin classes – P 5 Mixin allow the specification of roles on different hierarchies • Caesar. J compiler does not enforce all ACI roles – P 6 14

Summary of the implementations ____________________________ According to the implementations, the Caesar. J interfaces have modularity problems Previous work propose the use of Design Rules to increase modularity, but not for Caesar. J How can we provide support for increasing Caesar. J modularity? 15

Our Proposal ____________________________ • Caesar. J+: Extension that aims to increase Caesar. J modularity • Set of constructs on top of Caesar. J • Specification of Design Rules • Syntax-based rules (restrictions) • Caesar. J+ restrictions are automatically verified 16

Design Rule construct ____________________________ dr Next. Piece. DR[Common, Canvas] abstract cclass Common { … } abstract cclass Canvas { … } } • Establish a contract • Roles must have an implementation • Design purpose • Parameters abstracting roles • Increase reuse 17

Complements construct ____________________________ dr Next. Piece. DR [Common, Variation, Canvas] { abstract cclass Common { abstract void paint(); … } abstract cclass Variation complements Common { abstract void update. Piece(); … } abstract cclass Canvas { abstract void init() } } • Implementation of a class on multiple modules • Develop parts of a class in parallel (independently) • Bi-directional class relationship: mutual visibility • Only the complemented role can be instantiated • One concept implemented on more than one module 18

Design Rule implementation ____________________________ cclass Next. Piece implements Next. Piece. DR [Common] { void paint() {. . . } } cclass Easy. Variation implements Next. Piece. DR [Variation] { void update. Piece() {. . . } } cclass Tetris. Canvas implements Next. Piece. DR [Canvas] { void initialization(); } Must provide init()! • Associates the contract (DR) with classes responsible for roles implementations • Checks the restrictions 19

Implementation – OO Template Method ____________________________ abstract cclass Next. Piece { void paint() { … paint. Box(); . . . } void draw. Piece() {. . . } abstract void update. Piece(); abstract void paint. Box(); } cclass Easy. Variation extends Next. Piece { void update. Piece() { … } void paint. Box() { … } } cclass Normal. Variation extends Next. Piece { void update. Piece() { … } void paint. Box() { … } } • Design (abstract signatures) and implementation tangling (P 1) • The variation part can only be implemented after the implementation of the common code 20

First idea of interface using ACI (TM) ____________________________ • States that two roles must be implemented (solves P 1) • Common (Next. Piece. Base) and Variation (Next. Piece. Variation) • No mutual role dependency • Common role methods cannot see variation’s 21

TM with ACI – Mutual dependency ____________________________ • Signatures duplicated • Roles not well defined 22

Implementation – TM ACI ____________________________ 23

Problems – TM Implementation ____________________________ 24

DR Instantiation ____________________________ • Different classes on different contexts can be responsible for a DR • Instantiation: specifies these classes at a given context • A specific DR is generated for each DR instance Instantiated DR dr Next. Piece. Easy = Next. Piece. DR [Next. Piece, Easy. Variation, Tetris. Canvas] Instance Name Classes implementing DR roles dr Next. Piece. Normal = Next. Piece. DR [Normal. Variation, Next. Piece, Tetris. Canvas] Invalid instance: wrong parameters 25

Enhancing Expressiveness ____________________________ • Exact requisites x Minimum requisites • Wildcard on method signatures (*, . . ) • Advice restrictions dr Display. Example. DR [. . . Point. Role, Log. Role, . . . ] {. . . public abstract cclass Point extends Figure. Element { public void set*(int); } public abstract cclass Log. Role { pointcut point. Change(Point p): target(p) && (call(void Point. set*(. . )); after(Point p, . . ): point. Change(p). . ; }. . . } 26

Implementation details ____________________________ • Evaluate the proposed constructs • Proof of concept • Caesar. J+ compiler • Transforms Caesar. J+ constructs into Caesar. J valid code • Stratego/XT language and toolkit for program transformation 27

Transforming Design Rules ____________________________ dr Next. Piece. DR [Common, Variation, Canvas] { abstract cclass Common { abstract void paint(); update(): call(* Canvas. *side. Boxes()); } abstract cclass Variation complements Common { abstract void update. Piece(); } abstract cclass Canvas { abstract void init(); } } Caesar. J+ DR Generic ACI abstract cclass Next. Piece. DR { abstract cclass Common { abstract void paint(); update(): call(* Canvas. *side. Boxes()); abstract void update. Piece(); } abstract cclass Variation extends Base { abstract void update. Piece(); } abstract cclass Canvas { abstract void side. Boxes(); 28 }

Transforming DR Implementation ____________________________ • DRs mapped to ACIs DR roles are virtual classes • Create collaboration • Organize inheritance • Created collaboration inherits from DR – Class from role • Update references cclass Next. Piece implements cclass Next. Piece. DR implements [Common] Next. Piece. DR { [Common] { void paint() {. . . } } } cclass Next. Piece_Cjp extends Next. Piece. DR { cclass Next. Piece extends Common { void paint() {. . . } } } 29

Transforming DR Instantiation ____________________________ • Generates specific ACI for each instance • Create a new mixin for each instantiation • Inner mixins for complemented roles • Update references dr Next. Piece. Easy = Next. Piece. DR [Next. Piece, Easy. Variation, Tetris. Canvas] public cclass Next. Piece. Easy extends Next. Piece_Cjp & Easy. Variation_Cjp & Tetris. Canvas_Cjp { private static Next. Piece. Easy next. Piece. Easy ; public static Next. Piece. Easy get. Instance() { if (next. Piece. Easy == null) next. Piece. Easy = new Next. Piece. Easy(); return next. Piece. Easy; } public cclass Next. Pice extends Easy. Variation { } } 30

Evaluation ____________________________ • • Comparison between Caesar. J+ and Caesar. J Tetris SPL difficulty feature Observer design pattern Health Watcher concern • Transaction concern • LSD comparison 31

Evaluation Criteria ____________________________ • Language expressiveness: quantifies the degree in which a language is able to express a restriction • It is a three level factor - a language supports, does not support, or partially supports a specific rule • Language conciseness: measures how simple is to express a restriction in a language. • Number of tokens required to express a restriction 32

Tetris SPL Difficulty Feature ____________________________ SC = Statically checked, PC = Partially checked N = Not checked * = Compromised Comprehensibility 33

Tetris Restrictions ____________________________ R 5 – An advice which uses at least pointcut match. Canvas (R 4) must be implemented on the invariant operations. • Might be an after advice R 6 – Classes and methods used by match. Canvas pointcut must exist (have an implementation) 34

Observer Design Pattern ____________________________ R 1 – Two abstractions (roles) on the aspects: Subject and Observer R 3 – Aspect implementation separated from binding • Subject implementation – add. Observer, remove. Observer, update; Binding – get. State • Observer Binding - notify 36

HW Transaction Concern ____________________________ R 4 – Advice must exist call specific transaction methods (behavior) R 5 – Calls to specific methods must occur only inside the aspect (behavior) 38

Evaluation Results ____________________________ • Caesar. J+ allows the specification of restrictions which could not be expressed with ACIs (expressiveness) • Static checking • Similar number of tokens (concision) 39

Related work ____________________________ • Aspect. J abstract aspects • Aspects restrictions only • No advice restrictions • XPIs • Complex specifications • Natural language • Language for Specifying Design Rules – LSD • More expressive (behavioral, quantification) • Aspect. J only 40

Conclusion ____________________________ • An analysis of the use of Caesar. J ACIs focusing on the specification of modular interfaces for OO and AO code • Caesar. J+, an extension that enables the specification of design rules for increase Caesar. J modularity • A compiler for Caesar. J+, which allows the static checking of the restrictions specified on the DRs 41

Future work ____________________________ • Finish compiler implementation • Complements pointcuts updates • Accepts only a single file • wildcards / advice restrictions • More examples and evaluation • Introduce new constructs • LSD behavioral rules • Quantification mechanisms for rules (all, none, one) • DR inheritance 42

Future work (2) ____________________________ • Improove tool support • Eclipse plugin • Integration with other works • DR generator • ECaesar. J 43

Thank you! Questions _____________________ Design Rules for Increasing Modularity with Caesar. J Carlos Eduardo Pontual ceplc@cin. ufpe. br