Hi Doug:

we need a concept of compatibility between strategies and class graph.
A simple example of a strategy S which is not compatible with a class graph G
is if S refers to a class which does not exist in G. (I assume the default name
map).

For the traversal specifications of Demeter/C++
we used the following concept of compatibility:

A traversal specification D is compatible with class graph G if for any 
subspecification D' of D there is a path in G from Source(D')
to Target(D'). (see my book page 470 or the paper with Jens.)

How does this concept generalize to strategies?

Proposal (Boaz):
A strategy graph S is compatible with a class graph G under the default
name map if for all strategy graph edges e of S there is a path in G
from Source(e) to Target(e).

Source(e) is the class graph node corresponding to the source of e. 
Target(e) is the class graph node corresponding to the target of e.

This way we need to check compatibility only for the "building blocks"
of the strategy (the edges) and not for all subgraphs of the strategy.

Compatibility can be checked by inspecting the traversal graph.

Incompatibility is viewed as a fatal error since the program does
not make sense.

How do we deal with the edge constraints attached to strategy edges,
i.e., the negative path constraints?

You use bypassing and only-through: For bypassing an edge which does not
exist in the class graph, we should only give a warning and not a fatal error.

What about only-through?
What is your definition of only-through? You said it is the negation
of bypassing. Please can you refresh my memory.

-- Karl
Are there strategies in the new Demeter/Java
which are not compatible with any class graph?