Examples:

For second half: shortest path semantics
Connector::Component getComponent(Role r){
  {Connector -> Role -> Attachment -> Port -> Component}
}

Better example: Find all Connectors attached to Component:

shortest path semantics: 
Component::Connectors getConnector2() {
{Component -> PortList -> Port:p -> Attachment -> Role -> Connector}
}
 
Should we indicate where p is used? 

=========================================
shortest path semantics: 
Component::{Connector, Role r} getConnector(PortName n) {
{Component -> Port:p -> Attachment -> Role:r -> Connector}
}

An edge means: take the shortest path between the two endpoints.
Problem: might be brittle when certain paths get changed.
But can repair by using additional intermediate classes.

Assumes that along the path one PortName-object and one Port-object 
will be needed.

Syntax and semantics of customized API methods:
CustomizedMethod = Interface LineStrategy.
LineStrategy ~ {Edge}.
Edge = <from> OptLabeledNode “->” <to> OptLabeledNode.
OptLabeledNode = Node [“:” LabelName ].

Semantics: 


Why do we need shortest path semantics? The class graph contains many 
connections between pairs of nodes. With shortest path segments
we can easily select among those paths.

A B C D E F G H
--------------->
|              |
--longer X----->

Want longer path, instead of A -> H, use A -> X -> H.
 
Multiple return values: First one is the one returned by strategy.
Component::{Connector, Role:r, Port:p} getConnector(PortName n) {
{Component -> Port:p -> Attachment -> Role:r -> Connector}
}

refine: 
Component -> Port has method getPort(Name): take name from context 
(argument to APPC)
Attachments -> Attachment has method getAttachment(Port): take port 
from context: the last encountered port p by this strategy

Title: Defining Customized high-level Interfaces 
using Traversal Strategies

Dean Allemang and Karl Lieberherr

Abstract
An application programming interface (API) has to satisfy two 
conflicting requirements: on the one hand it has to be detailed to 
allow fine-grained access to low-level information. On the other hand, 
an API should also provide "common" higher level access methods which 
are expressed in terms of the primitive operations. The tension is that 
the need for high-level methods is application-specific and there is a 
danger of overloading, the API with too many methods. 

In this paper we present a solution to this dilemma which allows for 
convenient customized extension of the basic API. The extension 
technique uses traversal strategies to succinctly define the 
composition of high level methods out of low level methods. The 
specification of methods using traversal strategies is more convenient 
than writing the methods directly in a programming language for two 
reasons: The method specifications are usually shorter and they are 
more robust to changes in the basic API.

Terminology: Short-hand method composition?
             Succinct method compositions?
             Customized API methods?

Introduction
...
Needs for path specification:
Specification of single paths (expect unique path) 
  detailed
  straight-line strategy graphs with stop, select
  straight-line strategy graphs with shortest path 
Specification of multiple paths
  strategy graphs 
...

Our thesis is that we can simplify the task for both API writers and 
users. We prove the thesis using an example that shows the general 
approach. Our approach is applicable to extending interfaces in 
general.

Some strategy theory:

Graphs and strategy graphs: both are labeled graphs.
Path extension.  
Strategy graphs in addition have a constraint map.
-------
Also have a name map N. Distinct nodes in strategy graph may be mapped 
to same classes in class graph.
Name map = identity 
Strategy graph: Role1:r1 -> Role2:r2 -> Role3:r3
Class graph: classes A,B,C

Name map:
Role1 : A
Role2 : B
Role3 : A

Role1 and Role2 are both played by class A.
---------


Shortest path: bypass all edges except the ones on shortest path.

Semantics of a strategy: PathSet[G](S)
Why path set and not a subgraph? Shortcut example.

The compilation algorithm is described in strategy paper.

Improvements:
So far we have written the short hand method compositions against a 
detailed class graph. It is sometimes better to write the method 
compositions against an interface class graph so that they become more 
reusable. The interface class graph is later embedded into the 
implementation class graph using techniques similar to the ones 
presented in this paper. Each edge in the interface class graph is 
expressed either as a short hand method composition or as an adaptive 
program \cite{OOPSLA-paper}.

Note: This paper does not talk about visitors or APPCs. The only 
purpose is to concatenate method calls and not to execute additional 
methods during the traversal.
 
Aspect-oriented use of API: can attach visitors to succinct method 
compositions.

Conclusions:


Paul Denning: connections to Hanscom Air Force Base