DAJβ Documentation


DAJβ is an implementation of Demeter Interfaces in DAJ. The documentation that follows is presented as an extension to the ideas found in Adaptive Programming and more specifically in their implementation inside DAJ. Adaptive programs in DAJβ consist of four kinds of files :

  1. class dictionary files (.cd)
  2. traversal files (.trv)
  3. visitor files (.java)
  4. demeter interface files (.di)

Class dictionaries (cd-doc), traversal files (traversal strategies and trv-doc) and visitor files (visitor-doc) are borrowed from DAJ (with minor extensions) and their documentation is still applicable.


A Demeter Interface (DI) resides between a class dictionary and the implementation of adaptive behavior, i.e., adaptive methods and visitor implementations. A DI defines an interface class graph as well as a list of traversal file names each defining strategies, traversal and constraints for each strategy. A traversal file further defines a list of visitor class names that are used in its traversal definitions. A class dictionary has to provide a mapping between the entities in each interface class graph (ICG) in each DI and its class graph.

Setup Image

With the introduction of DIs development of Adaptive programs can be separated into two phases. Having agreed upon a DI definition development of adaptive code (traversal files and visitor definitions) can happen separately from the class dictionary definition. In fact DAJβ reflects this separation in its compilation phases. Adaptive code can be developed and tested having only the DI definition, trv files and visitor files. This phase generates code that can be then retrofitted to a class dictionary that implements the specific DI. During both phases, strategies and traversals are checked against their constraints for validity.

Language Reference

Traversal Files

Traversal files are extended to deal with the definition of constraints attached to strategies and the explicit definition of the list of Visitors used by the traversal file. The set of predefined constraints (e.g., unique, nonempty, subset and equal) is used to define the structural properties that the adaptive code assumes in order to function correctly. For example in the sample trv file below, the strategy definedIdent is restricted to have a unique path from Definition, via DThing to Thing.

          // SemanticChecker.trv File 
          aspect SemanticChecker with DVisitor{ 
            declare strategy: gdefinedIdents: "from ESystem via DThing to Thing". 
            declare strategy: gusedIdents: "from ESystem via UThing to Thing".
            declare strategy definedIdent: "from Definition via DThing to Thing". 

            declare traversal: void printDefined(): gdefinedIdents(DVisitor); 
            declare traversal: void printUsed(): gusedIdents(DVisitor); 

            declare constraints: 

The syntax for traversal (.trv) files is defined below.

                 aspect AspectName [ with VisitorName*]{ Declarationsopt }
                  Declarations Declaration
                  declare traversal : MethodHeader : Strategy ( VisitorName ) ;
                  declare strategy : StrategyName : StrategyString ;
                  declare constraints : Constraints.
                  CPrimSingle(StrategyName) | CPrimDouble(StrategyName, StrategyName)
                  unique | nonempty | multiple
                  subset | equiv

DI Files

The syntax of DI files is a superset of the Class Dictionary files (cd-doc). In short, the Class Dictionary is wrapped around a header which specifies the Demeter Interface name and the list of Traversal Files that use this DI.

                di DiName with AspectName* { ClassDictionary }

In the example below ExprICG is a DI and SemanticChecker is the trv file that uses ExprICG.

          // ExprICG.di 
          di ExprICG with SemanticChecker{ 
              ESystem = List(Definition).
              Definition = 
              <def> DThing "=" <body> Body. 
              Body = List(UThing).
              UThing = Thing. 
              DThing = Thing. 
              Thing = . 
              List(S) ~ "(" S ")". 

Extension to the Class Dictionary

Class Dictionaries now have a header that specifies which DIs (if any) the Class Dictionary implements. Mappings for each of the implemented DIs need to be provided. Mappings specify which DI entities correspond to which Class Dictionary entities. By entities we mean either a Class to a Class, an Edge to an Edge or a Strategy to a Strategy etc. The mapping must map all of the DI entities. The Class Dictionary that follows maps the DI ExprICG to the Class Dictionary InfixEQSystem.

          cd InfixEQSystem implements ExprICG {
            EquationSystem  = <eqs> List(Equation).
            List(S) ~ "(" {S} ")".
            Equation = <lhs> Variable "=" <rhs> Expr.
            Expr : Simple | Compound.
            Simple : Variable | Numerical.
            Variable = Ident.
            Numerical = <v> Integer.
            Compound = <lrand>List(Expr) <op> Op <rrand>List(Expr).
            Op : Add | Sub | Mul | Div.
            Add = "+".
            Sub = "-". 
            Mul = "*". 
            Div = "/". 

            for ExprICG (
                use EquationSystem as ESystem, 
                use Equation as Definition, 
                use Expr as Body, 
                use (->*,lhs,Variable) as DThing, 
                use (->*,rhs,* to Variable) as UThing, 
                use Variable as Thing

In the mapping above, EquationSystem is mapped to ESystem while the edge (->*,lhs,Variable) is mapped to DThing. The grammar for the extended version of Class Dictionaries is given below (ClassDictionary refers to the original Class Dictionary grammar from DAJ).

                  cd ClassDictionaryName implements DIName* { ClassDictionary MappingDecl* }
                  for DIName ( MapDefinition* )
                  use StrategyString as  StrategyString