CS 541 Meeting -*- Outline -*- for Java

* Problems with Obliviousness

    reference:   Curtis Clifton and Gary T. Leavens.
       Obliviousness, Modular Reasoning, and the Behavioral Subtyping
       Analogy.  ISU Com S TR 03-01a, March 2003.

** What is modular reasoning?

------------------------------------------
        WHAT IS MODULAR REASONING?

"it should be possible to study
 the system one module at a time"
     -- Parnas

def: a language L supports
  modular reasoning if the actions of
  every module M written in L
  can be understood based solely on:

  - the code contained in M
    and the code surrounding M, 

  - the signature and behavior
    of any modules referred to by
    the code in M and surrounding M.

E.g., in Java:
      module = compilation unit

------------------------------------------

        Q:  How to specify behavior?

** the behavioral subtyping analogy
*** behavioral subtyping deals with obliviousness in OOP
------------------------------------------
         OBLIVOUSNESS IN OOP

public class Point {

  private /*@ spec_public @*/ int pos;

  public /*@ pure @*/ final int getPos() {
    return pos;
  }

  /* ... */

  //@ requires true;
  //@ assignable pos;
  //@ ensures getPos() ==
  //@      dist + \old(getPos());
  public void move(int dist) {
    pos = pos + dist;
  }
}

public void client(Point p) {
  /* ... */
  assert p != null && p.getPos() == 0;
  p.move(-10);
  assert p != null && p.getPos() == -10;
}
------------------------------------------

        This should be valid, and is if there are no subclasses of Point.

------------------------------------------
       A SUBCLASS

public class RightMovingPoint
        extends Point 
{
  public void move(int dist) {
    if (dist < 0) super.move(-dist);
    else super.move(dist);
  }
}
------------------------------------------

        Q:  What happens if this class is included?
            it breaks the client

        Q:  How can we prevent that?
            use a discipline, like behavioral subtyping

*** similar problem in AOP
------------------------------------------
         ANALOGY IN ASPECTJ

public aspect MoveLimiting {
  void around(int dist):
    call(void Point.move(int))
      && args(dist)
  {
    if (dist < 0) proceed(-dist);
    else proceed(dist);
  }
}
------------------------------------------

        Q: What discipline, like behavioral subtyping, would allow
        modular reasoning in AOP?

** spectators and assistants

*** what needs to be supported in AOP
------------------------------------------
            USES OF (DYNAMIC) AOP

superimposition stories:

   - combining modules
     for separate concerns
     without surprising behavior

evolution stories:

   - modifying behavior
     of existing programs
     without changing their code

------------------------------------------

*** spectators support superimposition

------------------------------------------
   SPECTATORS SUPPORT SUPERIMPOSITION

Def: spectators are aspects that
are prohibited from changing the behavior
of the modules they advise.

How?

------------------------------------------

        This is the tricky question

        - limit the state that they can mutate, using an alias
          controlling type system.

        - place the burden on the programmer to prove this

*** assistants support evolution

------------------------------------------
    ASSISTANTS SUPPORT EVOLUTION

Def: assistants are aspects that
can do anything.

How to support reasoning?

  Make their use acceptance explicit
  in the language.
------------------------------------------