API Navigation (Persephone)

This paper applies the idea of strategies (succinct navigation specifications) to the problem of navigating through the methods of an API. The benefit of the paper is that a high level API can be defined without hard-wiring the details of the low-level API into the implementation of the high-level API. This makes it easier to maintain high-level APIs in the presence of shifting low-level APIs.

This paper is mainly an applications paper but it also makes two new contributions to the body of knowledge on AP: It proposes a useful shortest path semantics and it proposes a powerful way to handle the transmission of method arguments.

The paper is about a particularly useful special case of Demeter, called Persephone. It uses straight-line traversal strategies without visitors to define nested method calls.

Persephone = OOP + Persephone Methods.
Persephone Method =
  sequence of shortest paths + object transportation +
    argument management for derived edges.

The paper is available in the formats:


Bibtex entry:

@TECHREPORT{api-navig:allemang,
AUTHOR       = "Dean Allemang and Karl J. Lieberherr",
TITLE        = "{Softening Dependencies between Interfaces}",
INSTITUTION  = "College of Computer Science, Northeastern University",
YEAR         = 1998,
MONTH        = "April",
NUMBER       = "{NU-CCS-98-07}",
ADDRESS      = "Boston, MA"
}

Project ideas related to this paper:

Design and implement Persephone for Demeter/Java

Persephone uses a special kind of traversal strategies currently not supported by Demeter/Java. Implement this special kind. Use AP library developed by Doug Orleans. Demeter/Java already supports derived edges to express APIs. Traversal through derived edges is also supported. But the shortest path semantics and object transportation is missing. This project is about improving Demeter/Java with: 1. shortest path semantics for traversal strategies using derived edges, 2. object transportation

Design and implement Persephone for Java

Instead of improving Demeter/Java, this project is about adding a Persephone-like language to Java and to generate Java code from the extended Java. This is easier than extending Demeter/Java and focusses only on Persephone. The implementation is best done with Demeter/Java.

Tasks:
1. Define a class dictionary for Persephone methods.
Those methods are described by example in the paper and consist
of shortest path specifications, object transportation
and argument management.

You may want to generalize the language in the paper based on ideas in:


Interaction Graphs: A System for Specifying and Generating
Object Interactions

You could have multiple line strategies per Persephone method.


2. Write a Demeter/Java program to translate Persephone methods
into several Java methods. Use the Demeter/Java weaver to
update the appropriate Java classes.
For information about the weaver, see:
http://www.ccs.neu.edu/home/jayantha/usermanual/node6.html

(To see examples of weaver files, use a Demeter/Java example
and call "demjava generate".)

3. Write the examples from the paper using Persephone and run the
examples with your Persephone extension of Java.

Many users of Java are faced with numerous APIs they need to use. They need to build applications on top of those APIs. If the application needs to traverse the graph of the API in a linear fashion (one path at a time), Persephone can be used effectively.

Some further context when Persephone is not good enough: If the application needs to traverse the graph of the API in more complex ways, Demeter/Java or APPCs ( Adaptive Plug-and-Play Components for Evolutionary Software Development ) or ( Class Graph Views ) can be used successfully. A simple example of an API is given by a class dictionary that defines the getters and setters. A traversal "from A to B" can be viewed as a concatenation of getters.

Apply Persephone to the XML library from Javasoft

http://developer.javasoft.com/developer/earlyAccess/xml/index.html

The paper shows the usefulness of Persephone in the context of the ACME software architecture description language. Instead of the ACME API use the XML library API to demonstrate the usefulness of Persephone and build a Persephone version specialized for the XML API. The purpose of Persephone/XML is to make it easy to define high-level APIs on top of the XML API.

Apply Persephone to XML DTDs (proposed by Dean Allemang)

An XML document contains a DTD (Data Type Definition?) similar to a class graph. To write software for analyzing documents of a given DTD its is necessary to navigate through the DTD or class graph. Use Persephone to produce an API for traversing a particular XML document.

Task 0:
Figure out just how DTDs fit in to the whole story.  I
think they play the role of class graphs, but there might be another
twist (since these standards change fast).

Task 1: 
Do an example by hand. Choose a DTD and produce an API manually.

Follow the tasks of the project:
"Design and implement Persephone for Java"
shown above.

If you combine Persephone with
a flexible parser like the XML/DTD one from Sun, what you get is a
parser with a high level API - i.e., the result of this project, which
is Persephone + Sun's API,  will do both parsing and traversing.

NOTE:
Besides Persephone, the complete features of Adaptive Programming
are useful for manipulating XML documents in a structure-shy
manner.

Further information about the paper:

There is a general theme behind this paper which should be researched further: DEFINING A HIGH-LEVEL ARTIFACT IN TERMS OF A LOW-LEVEL ARTIFACT WITHOUT COMMITTING TO THE DETAILS OF THE LOW-LEVEL ARTIFACT IN THE DEFINITION OF THE HIGH-LEVEL ARTIFACT. The low-level artifact serves as parameter to the definition of the high-level artifact. The approach works if the low-level artifact has a structure that can be used to define the high-level artifact succinctly.

The paper deals with the case: ARTIFACT = API. Other applications of this idea are:

ARTIFACT = Object: Extracting information from objects.

ARTIFACT = Class Graph: Defining a view of a class graph.

HIGH-LEVEL ARTIFACT = program LOW-LEVEL ARTIFACT = class graph

The paper: ftp://ftp.ccs.neu.edu/pub/people/lieber/derived-edges.ps is not referenced in the paper but is related work. It talks about more general navigation through an API but does not provide a solution to the argument passing problem.