\section{THE DEMETER METHOD WITH VISITORS}
\index{Demeter Method}%

The following artifacts are derived from the use cases.
A use case describes a typical use of the software to be built.
\bi
\item
Derive a class dictionary.

Start with requirements, written in the form of use cases and
a high-level structural object model that describes the structure of
application objects. The structural object model provides
\index{use case}%
the vocabulary for expressing the use cases.
From the high-level structural object model we derive a \cd\ 
to describe
the structure of objects. The \cd\ has secondary importance since,
after the project is complete, it is replaceable by many other \cds\
without requiring changes or only a few changes to the rest of the software.

\item
Derive interfaces, traversals, visitors and host/visitor diagrams.

For each use case,
focus on subgraphs of collaborating classes that implement the use case.
Focus on how the collaborating classes cluster objects together.
\index{collaborating classes}%
Express the clustering in terms of traversal specifications
and visitors which transport the objects.
Express the traversal specifications robustly, focussing on
longterm intent.
The traversal specifications and visitors
give an implicit specification of the group of collaborating
classes, focusing on the classes and relationships that are
really important for the current use case.

The host/visitor diagram summarizes important object interactions.
The rows consist of host classes, the columns visitor classes.
Th host classes are the "important" classes  visited during
the traversal. They are the classes which have at least 
one method defined in some visitor class attached to the traversal.
Each host class has a before and after entry, unless that
row is going to be empty.
The start class of the traversal is included in the set of host classes.

An entry ! in (C before,V) means that some 
before method of class V modifies
an instance variable of class C. (Same for after methods.)
An entry ? in (C before,V) means that some 
before method of class V reads
an instance variable of class C. (Same for after methods.)
An entry !V2 in (C before,V) means that some 
before method of class V modifies
an instance variable of class V2. (Same for after methods.)
An entry ?V2 in (C before,V) means that some 
before method of class V reads
an instance variable of class V2. (Same for after methods.)


Summary:
host and visitor classes
! to host
? from host
!v to visitor v
?v from visitor v

Example:
host/visitor diagram
====================
Check capacity example
C=CheckingVisitor
S=SummingVisitor
- means: no instance variables

		C-	S 	
           ------------------------
 before		!
Container
 after		?,?S

 before			?,!S
Weight
           ------------------------

Since C reads S, it is necessary to nest S in C.

\item
Derive details of visitors.

Enhance the visitors by spelling out the details
of the visitor methods.
Derive test inputs from use cases
and use them to test the system.
\index{testing}%
\ei


The fundamental problem of method design:
Identify the colloraborating objects needed for the method.
Identify suitable traversals and visitors to collect them.
Minimize the number of methods not calling traversals.

The fundamental problem of class dictionary design:
Structural/Behavior:
Arrange the classes so that it is easy to use traversal specifications
to collect the collaborating objects needed for expressing the behaviors.
Structural/Grammar:
Arrange the classes so that there is a syntax extension which produces
natural, English-like descriptions of all the objects.

The fundamental problem of traversal specification:
What are the groups of collaborating classes for a given task?
Write a strategy which captures the long-term intent behind the
group of collaborating classes.

The fundamental problem of visitor design:
What are the classes which do the interesting work
for a given task?
Arrange the visitor objects in such a way that
the visitor methods of class V have all the necessary
data in classes reachable from V. If V gets complex, use
traversals to get to the visitor objects robustly.
Get another layer of visitors. Tower of visitors?

C = Class Dictionary
G = Grammar
M = Method
T = Traversal
V = Visitor
D = Design

OOD = CD + GD + MD + TD + VD 

CD strongly influences: GD,TD,VD
VD strongly influences visitor part of CD 


Style rules:

CALLS-DETERMINE-NESTING
Calling dependencies between visitor classes determine nesting.
If V1 calls V2, and V2 does not call V1, nest V2 in V1.
If V1 calls V2, and V2 also calls V1, introduce
  a new visitor class V3 which contains both V1 and V2 objects.

TRAVERSAL-CONSISTENT-WITH-NESTING
Each visitor class V has a subgraph as traversal observer scope S(V)
and if V2 is nested in V1 then S(V2) is contained in S(V1).

AFTER USE
Use an after method in visitor class V only if the traversal
of S(V) involves a back edge in the master traversal.

CONSISTENT INITIALIZATION
If a visitor class uses its data in a visitor method 
m-use which is only initialized in a visitor method m-init,
all traversal paths to VisitorClass(m-use) must go through
VisitorClass(m-init).
 
Design ideas:

RECURSIVE PARTIAL RESULTS
If a method m which returns a value for a class R needs to
compute the value of m for all R-objects contained in R:
Traverse the R-object and
store the value of m before entering each R-object r in r
and "subtract" this value after the traversal of r.
The visitor class will write to and read from a host class.

Examples:
Store the free variables for each subexpression in a program
Check the capacity of each nested container

Examples of host/visitor diagrams:

running average:
S = SummingVisitor
C = CountingVisitor

host/visitor diagram

            	S 	C 	A
Container

  before	?,!S	!C      ?S,?C,!A
Weight

An alternative description of visitors and traversals.

Software systems should be described using representations that clearly separate the core behavioral pieces of an application from their interconnections. This separation of aspects (behavior and interconnections) is a theme studied by Aspect-Oriented Programming. The Demeter Method provides separate language entities for representing software behavioral pieces and interconnections. The intelligence of an application, the core behavioral pieces, are defined in visitor classes. The visitor classes connect to the rest of the system in a two-tiered approach: we have a ``buffer'' called ``traversal specifications'' which describes the interconnection strategy, not the details of the interconnections. A class graph, similar to a UML or OMT class diagram, describes the details of the interconnections.

Many object-oriented software development methods use the following
approach:

   ANALYSIS		DESIGN			IMPLEMENTATION

BEHAVIOR
   Use Cases		Collaboration		Method
			Diagrams		Bodies


STRUCTURE
   Analysis-oriented	Design-oriented		Class
   Class Diagrams	Class Diagrams		Definitions


with the flow from left to right.

The Demeter Method uses a variation of this approach with the following
improvements:

Collaboration diagrams are not structure-shy; therefore, we replace
them by traversals and visitors. Tree-objects are represented
by sentences instead of constructor call statements.


PROGRAMMING IN THE LARGE

In Demeter/C++ we used components to encapsulate a group of
collaborating propagation patterns. In Demeter/Java we
are using adaptive components to encapsulate a group
of collaborating traversals and class  behaviors without making
a commitment to a detailed class organization.
An adaptive component can be instantiated with renaming
and used in many different class dictionaries.

An adaptive component has the following ingredients:
(following pages 228-229 of the AP book)

sample class dictionaries: a list of sample 
class dictionaries which may also be used for testing
the adaptive component.

constraints:
classes
edge patterns
sets of classes
directives
cardinality constraints

list of class behaviors (as defined by Demeter/Java)

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

Adaptive components are similar to non-adaptive components.
So we can reuse the insights from the Andersen Consulting
Component Model (which seems to be representative for many component
models).

An adaptive component is a significant functional unit 
which can either be atomic or composite. 
Each component has a provided and a required interface.
The provided interface specifies what the component
offers to other components. The provided interface is
like a Java interface.
The required interface specifies what the component needs
from the environment.
The required interface goes beyond an ordinary required interface
which exposes operation invocations that a component makes to other
components.
All the constraints of the component are part of the required interface.

The Anderson Consulting interface notation also supports 
pre- and post-conditions, invariants and states on top of CORBA IDL.

Components can be connected together to form composite components.
A connection is realized by binding a required interface of one component
with a provided interface of another component. The notion
of subtyping is important.

component AveragingApplication {
  Summing s;
  Counting c;
  Averaging a;
  bind (a.required,(s.provided,c.provided));
}

AveragingApplication is an application which is still adaptive:
a commitment to a specific class structure has not yet been made.

Should the binding construct have control over the traversals?
parallel or sequential?

For reusing components, the concept of component refinement
is important. before a component is instantiated with a cd,
it might have to be refined first.

How should the Demeter/Java syntax be extended to allow for
adaptive components?

To have a refinement concept for components will make it easier 
to maintain families of components for growing sequences
of class dictionaries.

A component has the flavor of a "feature". Adding a component
to an application adds one or more features by extending
the interfaces. The feature interaction problem is relevant.