Using Aspects to Support the Software Process: XP over Eclipse Oren Mishali and Shmuel Katz Technion, Israel Institute of Technology

The idea …

Aspects for Software Process support 1/14 Software product SP-aspects support the Software Process (SP) Are woven into the development environment

Process management support The problem: (defined process) – (actual process) > 0 The solution: Software Process Management SP-aspects add management support The use of AOP for that purpose is novel Flexible support, no scattering and tangling 2/14

Process modeling support A need for a formal abstract representation of the process Facilitates automation, helps to define the process Promotes process understanding, training … SP-aspects can be a process model A novel non-functional role of aspects Special design considerations 3/14

Our Vision …

SP-aspects repository Supports different development methodologies SP-aspects use the ontology of the methodology key-events, entities, activities, predicates Platform-independent, general and abstract A variety of concrete forms Users can generate concrete SP-aspects 4/14

Generating concrete SP-aspects 1. Specify Methodology & Platform 2. Choose refinements to the abstract parts e.g. activity part  management strategy Measurement Enforcement Automation 5/14

So far… SP-aspects Repository –Generator Using Aspects to Support the Software Process: XP over Eclipse

A case-study: XP over Eclipse Extreme Programming (XP) Values Communication, feedback, simplicity and courage Basic-principles e.g. ‘ rapid feedback ’, ‘ honest measurement ’ Practices e.g. ‘ pair programming ’, ‘ test first ’, ‘ collective ownership ’ 6/14

A case-study: XP over Eclipse Extreme Programming (XP) Values Communication, feedback, simplicity and courage Basic-principles e.g. ‘ rapid feedback ’, ‘ honest measurement ’ Practices e.g. ‘ pair programming ’, ‘ test first ’, ‘ collective ownership ’ XP-aspects are defined using AspectJ Prototype implementation over Eclipse 6/14

An Example …

Test-first Tests should be written before the code Is not an easy practice TestFirst aspect: Upon creation of a coding-element there should already be a corresponding unit-test 7/14

public abstract aspect TestFirst { protected abstract pointcut creationOfUnitTests(UnitTest test); protected abstract pointcut creationOfCodingElements(CodingElement element); after(UnitTest test): creationOfUnitTests(test){ existingUnitTests.add(test); } before(CodingElement element): creationOfCodingElements(element){ if(!hasUnitTest(element, existingUnitTests)) disapproval(element); } protected abstract boolean hasUnitTest(...); protected abstract void disapproval(...); … } Ontology: Key-events Predicates Activities Entities 8/14

public abstract aspect TestFirst { protected abstract pointcut creationOfUnitTests(UnitTest test); protected abstract pointcut creationOfCodingElements(CodingElement element); after(UnitTest test): creationOfUnitTests(test){ existingUnitTests.add(test); } before(CodingElement element): creationOfCodingElements(element){ if(!hasUnitTest(element, existingUnitTests)) disapproval(element); } protected abstract boolean hasUnitTest(...); protected abstract void disapproval(...); … } Ontology: Key-events Predicates Activities Entities 8/14

public abstract aspect TestFirst { protected abstract pointcut creationOfUnitTests(UnitTest test); protected abstract pointcut creationOfCodingElements(CodingElement element); after(UnitTest test): creationOfUnitTests(test){ existingUnitTests.add(test); } before(CodingElement element): creationOfCodingElements(element){ if(!hasUnitTest(element, existingUnitTests)) disapproval(element); } protected abstract boolean hasUnitTest(...); protected abstract void disapproval(...); … } Ontology: Key-events Predicates Activities Entities 8/14

public abstract aspect TestFirst { protected abstract pointcut creationOfUnitTests(UnitTest test); protected abstract pointcut creationOfCodingElements(CodingElement element); after(UnitTest test): creationOfUnitTests(test){ existingUnitTests.add(test); } before(CodingElement element): creationOfCodingElements(element){ if(!hasUnitTest(element, existingUnitTests)) disapproval(element); } protected abstract boolean hasUnitTest(...); protected abstract void disapproval(...); … } Ontology: Key-events Predicates Activities Entities 8/14

public abstract aspect TestFirst { protected abstract pointcut creationOfUnitTests(UnitTest test); protected abstract pointcut creationOfCodingElements(CodingElement element); after(UnitTest test): creationOfUnitTests(test){ existingUnitTests.add(test); } before(CodingElement element): creationOfCodingElements(element){ if(!hasUnitTest(element, existingUnitTests)) disapproval(element); } protected abstract boolean hasUnitTest(...); protected abstract void disapproval(...); … } Ontology: Key-events Predicates Activities Entities 8/14

XP-Elements: public interface XPElement { public boolean isArtifact(); public String getName();... } public interface Artifact extends XPElement { public static final int PLANNING = 1; public static final int DESIGN = 2; public static final int CODING = 3; public static final int TESTING = 4;... public int getPhase();... } public interface CodingElement extends Artifact { public static final int CLASS = 1; public static final int METHOD = 2;... public int getKind();... } public interface PairProgrammers extends XPElement { public String getPilotName(); public String getNavigatorName();... } 9/14

A reminder… “SP-aspects have abstract and general definition and can be realized in a variety of concrete forms”

public abstract aspect TestFirst { protected abstract pointcut creationOfUnitTests(UnitTest test); protected abstract pointcut creationOfCodingElements(CodingElement element); after(UnitTest test): creationOfUnitTests(test){ existingUnitTests.add(test); } before(CodingElement element): creationOfCodingElements(element){ if(!hasUnitTest(element, existingUnitTests)) disapproval(element); } … } What kind of coding-elements are affected? What kind of management strategy is taken? 10/14

EclipseTestFirst extends TestFirst Upon creation of a coding-element there should already be a corresponding unit-test 11/14

EclipseTestFirst extends TestFirst Upon creation of a Java class there should already be a corresponding JUnit test-case named Test{ClassName} disapproval( … ) enforces the practice XP-Elements are connected using inter-type declarations The weaving is done using AJEER Load-time weaving 11/14

Implementation notes Finding the join-points is difficult Join-points are not extension-points XP-aspects can be changed The way that abstract policies are realized Modifications of the underlying environment 12/14

Related work Process Centered Engineering Environments (PCEs) Consider a process model as an input No seamless integration Eclipse-based solutions AOP and the software process 13/14

Aspects for software process support Aspects for XP over Eclipse are only one case-study RUP-aspects … A construction of a fuller set for XP has begun Refactoring, Continuous integration Preliminary experiments with users Enforcement can be irritating Automation is most popular Except setup, XP-aspects do not affect service 14/14

Thanks… Questions?