Modularity 2015 - Submissions: October 10, 2014

Modularity 2015 second round submission deadline: October 10th, 2014

More information: Modularity 2015 - Research Results Track

PSC track submission deadline: 26th September

PSC (Programming for Separation of Concerns) Track of ACM Symposium on Applied Computing deadline: September 26th.

Details on the CFP at http://www.dmi.unict.it/~tramonta/sac/

Call for papers: Modularity 2015

Modularity 2015

 Call for Papers: Modularity '15 Research Results

         March 16-19, 2015, Ft. Collins, Colorado, USA

First round due date: August 4, 2014. Second round due date: October 10, 2014.

Modularity is a key property for scalability of software processes, including debugging, maintenance, reasoning, and testing. Modularity influences system diversity, dependability, performance, evolution, the structure and the dynamics of the organizations that produce systems, human understanding and management of systems, and ultimately system value. Yet the nature of and possibilities for modularity, limits to modularity, the mechanisms needed to achieve it in given forms, and its costs, benefits, and tradeoffs remain poorly understood. Significant advances in modularity thus are possible and promise to yield breakthroughs in our ability to conceive, design, develop, validate, integrate, and evolve modern information systems and their underlying software artifacts.

Modularity at the semantic as well as the syntactic level is a key enabler for the expression of high quality software systems. One of the most important techniques for complexity reduction is abstraction. Novel concepts and abstraction mechanisms, including but not limited to aspect-oriented techniques, are a focus point for improvements in the support for modularity. The scope of this effort covers all perspectives on software systems in all their life-cycle phases, for instance application domain analysis, programming language constructs, formal proofs of system properties, program state visualization in debuggers, performance improvements in compiler algorithms, etc. As the premier international conference on modularity, Modularity'15 continues to advance our understanding of these issues and the expressive power of known techniques.

The Modularity'15 conference invites full, scholarly papers of the highest quality on new ideas and results. Papers are expected to contribute significant new research results with rigorous and substantial validation of specific technical claims, based on scientifically sound reflections on experience, analysis, experimentation, or formal models. Compelling new ideas are especially welcome, which means that the requirements in the areas of validation and maturity are higher for papers that contribute more incremental results.

Modularity'15 is deeply committed to publishing works of the highest caliber. To this aim, two separate paper submission deadlines and review stages are offered. A paper accepted in any round will be published in the proceedings and presented at the conference. Promising papers submitted in the first round that are not accepted may be invited to be revised and resubmitted for review by the same reviewers in the second round. Authors of such invited resubmissions are asked to also submit a letter explaining the revisions made to the paper to address the reviewers' concerns. While there is no guarantee that an invited resubmission will be accepted, this procedure (similar to major revisions requested by journals) is designed to help authors of promising work get their papers into the conference. Submission to both rounds is open for all, and authors who submit to the first round may of course choose to resubmit a revised version in the second round without such an invitation, in which case new reviewers may be appointed. Finally, the same paper cannot be simultaneously submitted to other conferences or journals. In case of doubt, please contact the Program Chair.

Research Topics

Modularity'15 is looking for papers in all areas of software modularity. Topics of interest include, but are not limited to, the following:

* Varieties of modularity: Context orientation; feature orientation; generative programming; aspect orientation; software product lines; traits; families of classes; meta-programming and reflection; components; view-based development.

* Programming languages: Support for modular abstraction in: language design; verification, specification, and static program analysis; compilation, interpretation, and runtime support; formal languages and calculi; execution environments and dynamic weaving; dynamic languages; domain-specific languages.

* Software design and engineering: Requirements and domain engineering; architecture; synthesis; evolution; metrics and evaluation; empirical studies of existing software; economics; testing and verification; semantics; composition and interference; traceability; methodologies; patterns.

* Tools: Crosscutting views; refactoring; evolution and reverse engineering; aspect mining; support for new language constructs.

* Applications: Data-intensive computing; distributed and concurrent systems; middleware; service- oriented computing systems; cyber-physical systems; networking; cloud computing; pervasive computing; runtime verification; computer systems performance; system health monitoring; enforcement of non-functional properties.

* Complex systems: Works that explore and establish connections across disciplinary boundaries, bridging to such areas as biology, economics, education, infrastructure such as buildings or transport systems, and more.

* Composition. Component-based software engineering; Composition and adaptation techniques; Composition algebras, calculi, and type systems; Model-driven composition; Dynamic composition and reconfiguration; Large-scale component-based systems; Cloud, service-oriented architectures; Business process orchestration; Visual composition environments; Performance optimization of composite systems.

Important Dates

* First round:

Submission: August 4, 2014 (23:59 Baker Island / UTC-12)

Notification: September 14, 2014

* Second round:

Submission: October 10, 2014 (23:59 Baker Island / UTC-12)

Notification: December 7, 2014

* Camera ready: February 15, 2015

Submission Guidelines

Modularity'15 is deeply committed to eliciting works of the highest caliber. To this aim, two separate paper submission deadlines and review stages are offered. A paper accepted in any round will be published in the proceedings and presented at the conference. Promising papers submitted in the first round that are not accepted may be invited to be revised and resubmitted for review by the same reviewers in the second round. Authors of such invited resubmissions are asked to also submit a letter explaining the revisions made to the paper to address the reviewers' concerns. While there is no guarantee that an invited resubmission will be accepted, this procedure (similar to major revisions requested by journals) is designed to help authors of promising work get their papers into the conference. Submission to both rounds is open for all, and authors who submit to the first round may of course choose to resubmit a revised version in the second round without such an invitation, in which case new reviewers may be appointed. Finally, the same paper cannot be simultaneously submitted to other conferences or journals. In case of doubt, please get in touch with the Program Chair.

All submissions must conform to both the ACM Policy on Prior Publication and Simultaneous Submissions and the SIGPLAN Republication Policy.

Papers are to be submitted electronically to CyberChair.

Please use http://cyberchairpro.borbala.net/modularitypapers/submit/ to submit your paper. Submissions should use the SIGPLAN Proceedings Format using 9 point font. Please include page numbers in your submission as this will be helpful for the reviewers and also for you when reading their reviews. (If your submission is written using LaTeX, please set the preprint option in the LaTeX \documentclass command to generate page numbers.) Please also ensure that your submission is legible when printed on a black and white printer. In particular, please check that colors remain distinct and font sizes are legible.

To ensure that papers stay focused on their core contributions, the main part of the paper should be no longer than 12 pages. There is a 4 page limit for appendices, and, therefore, for the overall submission must be less than 16 pages. If the paper is accepted, the final submission will be limited to 16 pages, including appendices.

However, it is the responsibility of the authors to keep the reviewers interested and motivated to read their submission. Reviewers are under no obligation to read all or even a substantial portion of a paper if they do not find the initial part of the paper compelling. The committee will not accept a paper if it is unclear that the paper will fit in the Modularity'15 Proceedings.

All submitted papers are peer-reviewed. Accepted papers from all tracks will appear in the Modularity'15 Proceedings in the ACM Digital Library. Submissions will be judged on the potential impact of the ideas and the quality of the presentation.

Program Committee Chair

Gary T. Leavens, University of Central Florida, USA (leavens@cs.ucf.edu)

Program Committee

Don Batory, University of Texas at Austin

Eric Bodden, Fraunhofer SIT and TU Darmstadt

Paulo Borba, Federal University of Pernambuco

Walter Cazzola, Università degli Studi di Milano

Cynthia Disenfeld, Technion -- Israel Institute of Technology

Robert Dyer, Bowling Green State University

Erik Ernst, Aarhus University

Matthew Flatt, University of Utah

Michael Haupt, Oracle Labs

Marieke Huisman, University of Twente

Cristina Lopes, University of California Irvine

Tiziana Margaria, University of Potsdam

Linda Northrop, Software Engineering Institute

Nate Nystrom, University of Lugano

Bruno C. d. S. Oliveira, The University of Hong Kong

Awais Rashid, Lancaster University

Henrique Rebêlo, Federal University of Pernambuco

Martin Rinard, Massachusetts Institute of Technology

Norbert Siegmund, University of Passau

Murali Sitaraman, Clemson University

Kevin Sullivan, University of Virginia

External Review Committee

Marsha Chechik, University of Toronto

Steven Edwards, Virginia Tech.

Dan Grossman, University of Washington

Görel Hedin, Lund University

Mira Mezini, TU Darmstadt

Peter Müller, ETH Zurich

Hridesh Rajan, Iowa State University

Clemens Szyperski, Microsoft Research

Éric Tanter, University of Chile

Eelco Visser, Delft University of Technology

For additional information, clarification, or answers to questions please contact the Program Committee Chair.

Aspect-oriented Programming (AOP) - around advice

We have discussed before and after advice (After, AOP - 2), it remains to talk about around advice. This kind of advice is very interesting because not only allows adding behavior before and/or after the original joinpoint, but also allows overriding the original behavior, or applying the original behavior multiple times.

For example,

public class C{

  public static void main(){
1    int y = addOne(0);
2    System.out.println(y);
  }

  public static int addOne(int x){
3    return x+1;
  }
}

public aspect A{
4  pointcut callAddOne(int x): call(* *.addOne(int)) && args(x)

5  int around(int x): callAddOne(x){
6    System.out.println("before calling");
7    int tmpValue = proceed(x);
8    tmpValue = proceed(tmpValue);
9    System.out.println("after calling");
10    return tmpValue;
  }
}

In the example, the around advice (line 5) is activated when the pointcut (line 4) matches a joinpoint. The only location in C where this occurs is in line 1, when addOne is called.
Then, the following things happen
i) when matching the joinpoint, the pointcut caputres x as the argument to the call (notices args(x) within the pointcut definition)
ii) the message "before calling" is printed
iii) proceed indicates to apply the original behavior. That is, we are actually calling to addOne with the value x (in the original call was 0, so this is the value within the advice).
iv) tmpValue obtains the return value of the call, in this case 1
v) we call again to the original method! but this time with the argument tmpValue
vi) tmpValue is updated to 2 (it was incremented by the second proceed)
vii) the second message within the advice is printed
viii) the value 2 is returned
ix) y (in line 1) receives 2 and gets printed.


Around-like advice are a very strong mechanism not only to add behavior before or after the original, but also to change the control flow, for instance by making the original joinpoint to be executed multiple times, or none at all! If within the around advice there is no proceed, then the original behavior gets overriden.

The Earth moves around the Sun (but doesn't override it :) )

Aspect-oriented Programming (AOP) - AJDT - First project

To actually define pointcuts (Pointcuts - 1, Pointcuts - 2), advice (Introduction - 2, after advice), and aspects in general, AJDT is a useful tool. According to your eclipse version, download instructions are available in AJDT - download.

That is, you open eclipse, go to Help -> Install new Software ; enter the appropriate update site, and install AJDT.

Once installed, you can define an AspectJ project, with classes and aspects.

Creating an AspectJ project:

In the next window, set the project name.

A project that has not initially been set as an AspectJ project, can later be changed (and an AspectJ project can be changed to a normal java project - but if it has aspects, it will fail to compile)

Add a new class HelloWorldAspectsMain

with the following methods:

public static void main(String[] args) {
foo();
}

private static void foo() {
           System.out.println("in foo"); 
}

Then, create the aspect HelloWorldAspect (new -> Other.. -> Aspect) 

The contents of the created file are:

public aspect HelloWorldAspect {

}

Within the brackets add the following code:

pointcut callFoo(): call(* *.foo());

before(): callFoo(){

System.out.println("Hello");

}

after(): callFoo(){

System.out.println("World!");

}

so that the resulting aspect file is:

public aspect HelloWorldAspect {

pointcut callFoo(): call(* *.foo());

before(): callFoo(){

System.out.println("Hello");

}

after(): callFoo(){

System.out.println("World!");

}

}

Run the code as an AspectJ program (when pressing run, this option should appear), and check what happens!

The expected output is:

Hello

in foo

World!

Aspect-oriented Programming (AOP) - after advice

As we have mentioned in AOP - 2, there are three kinds of advice: before, after, and around.

The before advice is very simple, it allows adding the concern code before the joinpoints matching the pointcut.

I will now focus on the after advice which has some more options.
It can be used as:

1. after( exposed information ) returning [(exposed information)]: pointcut
2. after( exposed information ) throwing [(exposed information)]: pointcut
3. after( exposed information ): pointcut

Notation: the text between brackets means that it is optional

The first one captures when the execution flow returns from the joinpoint (possible exposing information about the returned value).

For example, given the classes:

class C{
  public static void main(){
    D d = new D();
    int x = d.foo();
  }
}

class D {
  public int foo(){
    return 8;
  }
}

and the advice

after() returning: call(* *.foo()){
  System.out.println("after foo");
}

prints the advice message once foo has returned successfully

On the other hand, the advice

after() returning(int x): call(* *.foo()){
  System.out.println("after foo");
  System.out.println(x);
}

also prints the returned value by foo methods of type int

The second option above (2.) captures the exception thrown, so that if we want to add some behavior only when an exception occurred within the joinpoint this kind of advice is very useful.

For example, given the following classes

class C{
  public static void main(){
    D d = new D();
    int x = d.foo(-1);
  }
}

class D {
  public int foo(int i){
    if (i < 0) throw new Exception("did not expect negative value");
    return Math.sqrt(i);
  }
}

The advice
after() throwing: call(* *.foo()){
  System.out.println("exception thrown within foo");
}

captures the problematic situation and prints the message (and the exception is still thrown to the other classes.

The third option captures returning from the joinpoint either correctly or because of an exception.

To think about: How would you write an advice that when returning from foo with an exception, also prints the exception message? (before forwarding the exception to the calling methods?)

The boy throws a rock to the sea, as sometimes methods throw exceptions...

Aspect-oriented Programming (AOP) - Static Pointcuts - Exercises

Try writing the following pointcuts statically capturing some joinpoints:

(According to the posts AOP - Pointcuts 1, AOP - Pointcuts 2)

1. The pointcut that captures any call to any int method containing the word "Method" in its name. For example:

class C{
  public static void main(){
      D d = new D();
1.    d.thisMethodIsCool();
  }
}

class D{
  public int thisMethodIsCool(){
2.    System.out.println("within the cool method");
  }
}

The pointcut should match the call in line 1 of class C.

pointcut callMethod(): call(int *.*Method*(..))

2. The same as before but now capture the execution of the method, i.e., when the eecution flow is within line 2 of class D.

pointcut executeMethod(): execution(int *.*Method*(..))

3. This pointcut should match whenever a String field named "name" is set

pointcut setName(): set(String *.name)

Aspect-oriented Programming (AOP) - Pointcuts - 2

We have mentioned the call and execution pointcuts in the post Pointcuts - 1 .

There are several other useful pointcuts expressions, we will first describe static ones and then dynamic ones. Static ones are those that they can be analyzed at compilation time, and therefore, part of the weaving (applying the aspect at the correct place) is done statically, thus avoiding usual aspect overhead. Dynamic pointcuts expressions depend on the runtime state of the system. A certain joinpoint may match the pointcut at some point of time but not at another.

Some interesting static pointcut expressions (besides call and execution) are:

get/set (fieldPattern) do detect whenever a value read or written to a field (wildcards are allowed here too); 

initialization -> to capture constructors; 

within / withinCode -> to statically check if the pointcut is within a certain class or method name

Some interesting dynamic pointcut expressions are:

cflow(pointcut): captures any joinpoint within the execution flow of the pointcut. 

For example, if there is a pointcut: cflow (call(* *.foo()) and within foo() there is a call to bar(); then that call is within the execution flow of call(foo) therefore the advice with that pointcut will be activated. However, when bar is called within a stack trace where foo has not occurred, the matching advice will not be activated.

this, target, args: All this allow not only capturing dynamic information but also exposing it to be used within the advice. For instance, let's consider the pointcut

call(* *.foo()) && this(C)

This pointcut expresses any call to C where the call is done by an object of class C.

Moreover if we define the pointcut as follows:

pointcut p(C objC):call(* *.foo()) && this(objC)

we are saying the same as before but also saving the reference to the object calling foo in objC.

Similarly, with target we can save the reference of the targeted object, and with args, the arguments with which the call is being made.

Besides static and dynamic pointcut descriptors, more complex pointcuts can be obtained by boolean composition:

&& -> and among pointcuts

|| -> or among pointcut

! -> not pointcut

Aspect-oriented Programming (AOP) - Pointcuts - 1

So far we have talked very little about pointcuts, but there are several syntax keywords that allow capturing different joinpoints.

Here is the whole list: Pointcuts, but I will point out some that are very useful (and used):

call(MethodPattern): whenever a method is called. MethodPattern is an expression (containing wildcards) that may capture different sets. For instance public int C.m(String) is a method pattern capturing the public method m of class C that receives one argument of type String. We can also define the following * *.*(..) which represents, any method of any class of any type with any set of arguments. Something in the middle could be * Cl*.me*(String, ..) which captures methods (of any type) that begin with me, of classes that start with Cl and receive at least one String argument (as the first  argument).

execution (MethodPattern), is similar but represents when we are in the class of the method pattern. To observe the difference between call and execution let's consider the following example:

1. class MainClass {
2.   public static void main(){
3.      C o1 = new C();
4.      o1.m();
5.   }
6. }

1. class C {
2.   public void m(){
3.   }
4. }

the call pointcut matches the location at MainClass, line 4; while the execution pointcut matches the execution within C that is, between lines 2 and 3 of class C.

Aspect-oriented Programming (AOP) - Introduction - 2

In the previous post AOP - 1, I have started describing Aspect-Oriented Programming, that is, a paradigm that allows defining crosscutting concerns modularly. In particular, we have mentioned that it contains a query-like expression defining where the aspect should be applied, and the code representing the actual concern. In order to represent a crosscutting concern there may be several of such pieces of code, each called advice. The query expressing the locations is called pointcut and the actual locations that may match a pointcut are called joinpoints.
Each advice has a type: before, after or around. A before (or after) advice indicates that the code within the advice should be executed before (or after) the joinpoint matching the pointcut. An around advice allows changing the parameters of the original joinpoint, and even making the original call zero or more than once.
Some first (simple) examples are:
1)
before(): call(void *.m(..)){
  System.out.println("before calling m");
}

2)
after(): call(void *.m(..)){
  System.out.println("after calling m");
}

3)

void after(): call(void *.m(..)){
  System.out.println("before calling m");
  proceed();
  System.out.println("after calling m");
}

In the first example, before calling to any void method m (belonging to any class, with any set of arguments), the message "before calling m" is printed.
The second example is similar, but only prints the message after m has been called (and returned either successfully or because of an exception)
The third example surrounds the call with the two messages.

Aspect-oriented Programming (AOP) - Introduction - 1

In this post I will start writing a bit about Aspect-oriented programming, in a future post about aspect implementation in AspectJ, and I hope later explain about some ideas of combining formal methods with this paradigm.
I assume that you all know what object-oriented programming is, and in particular know some object-oriented language. Basically, we define classes from which we can instance objects, which are the fields and type of each instance of the class, and to which messages / methods the object responds and how.
However, when implementing an application there are crosscutting concerns that affect multiple objects, and get tangled in their implementation, and scattered along many objects [1]. Typical examples are logging, persistence, transaction management, gui updates. These are examples of aspects [2] applicable to multiple systems, but there could be aspects defined specifically for each application, when are the points updated in a game, which discounts to apply to a purchase, etc..
To represent this crosscutting concerns modularly aspects indicate where the particular code should be applied, and what should be do. For example, we could say "every time a public method is called, log it". This is expressed in a different module that looks like a class (but is an aspect), and the locations are expressed as a query. For example in AspectJ (an aspect-oriented extension for Java), that location is expressed as call(* public *(..)), i.e. call to a public method (first *: for any return type; second *: for any method name; ..: for any set of arguments).

References:
[1] Tarr, Peri, Harold Ossher, William Harrison, and Stanley M. Sutton Jr. "N degrees of separation: multi-dimensional separation of concerns." In Proceedings of the 21st international conference on Software engineering, pp. 107-119. ACM, 1999.
[2] Kiczales, Gregor, John Lamping, Anurag Mendhekar, Chris Maeda, Cristina Lopes, Jean-Marc Loingtier, and John Irwin. Aspect-oriented programming. Springer Berlin Heidelberg, 1997.