PADL

PADL stands for Pattern and Abstract-level Description Language. It is a meta-model to describe programs at different levels of abstractions.

There are four different levels of abstractions to model programs, collectively called abstract-level models:

• A ICodeLevelModel represents the “raw” model of a program, including only data directly extractable from the program source representation (Java bytecodes, Java source code, C/C++ source code…);

• A IIdiomLevelModel represents a model of a program where some idioms have been reified, typically binary-class relationships computed using some analyses;

• A IDesignLevelModel represents a model of a program where design information is available. Typical design information is obtained from the idiom-level model, for example occurrences of design motifs or of code and design smells;

• A IDesignMotif represents a design motif, i.e., the solution to a design pattern model in PADL Design Motifs.

The following diagram shows the hierarchy of the interface describing models. (This hierarchy has been built using the project Ptidej UI Viewer Standalone Swing.) The root of the models is the interface IAbstractModel, which describes any model that could be handled by most of Ptidej analyses and tools. This interface abstracts IAbstractLevelModel, which represents models of programs, and IDesignMotif, which represents models of design motifs.

The PADL project also provides the interfaces:

• IAbstractModelSerialiser must be implemented by any algorithm to serialise/deserialise PADL models. A variety of serialisers already exist, including for popular databases, such as DB4O and NeoDatis;

• ICodeLevelModelCreator, along with padl.kernel.ICodeLevelModel.create(ICodeLevelModelCreator), is an implementation of the Builder design pattern, to provide a unified interface to create PADL models. Creators exist for Java bytecodes as well as other representations, such as AOL files, AspectJ lst files, C/C++ and Java source code…

The PADL meta-model includes an extensive hierarchy of interfaces to describes binary class relationships. The following figure highlights these relationships. (This hierarchy has been built using the project Ptidej UI Viewer Standalone Swing.) Of particular interest are the following relationships, presented in order from the most constraining to the least constraining. Whenever a relationship is identified between two entities, the following least constraining relationships are not included. For example, if an aggregation relationships exists between two classes A and B, no corresponding use relationship would exist:

• IContainerComposition describes a relationship between two classes A and B such as A holds the unique reference(s) to (an) instance(s) of B and plays the role of container, providing method to add/remove instances of B;

• IComposition describes a relationship between two classes A and B such as A holds the unique reference(s) to (an) instance(s) of B;

• IContainerAggregation describes a relationship between two classes A and B such as A holds (possibly shared) reference(s) to (an) instance(s) of B and plays the role of container, providing method to add/remove instances of B;

• IAggregation describes a relationship between two classes A and B such as A holds (possibly shared) reference(s) to (an) instance(s) of B;

• IAssociation a relationship between two classes A and B such as A calls some methods of B using (an) instance(s) of B;

• ICreation a relationship between two classes A and B such as A create (an) instance(s) of B;

• IUseRelationship a relationship between two classes A and B such as A uses in some way, for example by declaring a method with a parameter of type B, (an) instance(s) of class B.

The existence of binary class relationships is inferred from an ICodeLevelModel based on the presence of certain fields and methods and method invocations in classes by the padl.analysis.repository.AACRelationshipsAnalysis.

The PADL meta-model provides you with two distinct but related visitors: padl.visitor.IGenerator and padl.visitor.IWalker. Both visitors inherit from padl.visitor.IVisitor but provide different methods to retrieve the results of the visit: getCode() and getResult(), respectively. A typical example of using one of these visitors is:

final IWalker walker = new InheritanceImplementationCounter();
final ICodeLevelModel codeLevelModel =
     Primitive.getFactory().createCodeLevelModel("");
codeLevelModel.create(
    new CompleteClassFileCreator(
        DefaultFileRepository.getInstance(),
        new String[] { path },
        true));
final IIdiomLevelModel idiomLevelModel =
   (IIdiomLevelModel) new AACRelationshipsAnalysis().invoke(codeLevelModel);

walker.reset();
idiomLevelModel.walk(walker);
System.out.println(walker.getResult());

Obviously, the class padl.creator.classfile.test.creator.InheritanceImplementationCounter implements padl.visitor.IWalker.

As part of an effort to improve code representation in PADL. The concept of method invocation has been added since 2004-2005. An interface padl.kernel.IMethodInvocation represents method invocations. This concept is as-of-today not quite clean and is used to describes both method invocations and field accesses. Therefore, the interface padl.kernel.IMethodInvocation (and its reference implementation) includes:

• a padl.kernel.IMethod container that is the calling method (in which the method invocation can be found.) (Dirty Hack.)

• a int cardinality value that describes the cardinality of the call
  • 1 = unique call;
  • 2 = repetitions of the call;

• a int type value that characterises the type of method invocation:
  • CLASS_CLASS: method invocation from a class method to another class method;
  • CLASS_CLASS_FROM_FIELD: method invocation from a class method to another class method through a class variable;
  • CLASS_INSTANCE: method invocation from a class method to an instance method;
  • CLASS_INSTANCE_FROM_FIELD: method invocation from a class method to an instance method through a class variable;
  • INSTANCE_CLASS: method invocation from an instance method to a class method;
  • INSTANCE_CLASS_FROM_FIELD: method invocation from an instance method to a class method through an instance variable;
  • INSTANCE_CREATION: creation of a new instance;
  • INSTANCE_INSTANCE: method invocation from an instance method to another instance method;
  • INSTANCE_INSTANCE_FROM_FIELD: method invocation from an instance method to another instance method through an instance variable;
  • OTHER: other things… such as field accesses! (Dirty Hack.)

• an IEntity targetEntity that references the entity declaring the called method. (Dirty Hack.)

• an int visibility values that is the visibility of the called method. (Dirty Hack.)

• an IAbstractMethod calledMethod that is a reference to the called method.

• a List callingFields that is a list of the fields (if any) through which the called method is invoked. (Fragile Code.)

• an IEntity fieldDeclaringEntity referencing the IEntity declaring the (last) field through which the called method is invoked. (Dirty Hack.)

The getName() always returns the simple name of a constituent. For binary-class relationships and method invocations, the name returned by getName() is less important, it could simply be Method Invocation, for example. For a first-class entity, though, it is important, for example getName() returns IConstituent for padl.kernel.IConstituent. Here are other examples of getName() values:

• padl for a package;

• getName() for a method;

• setName(char[]) for a method;

• name for an attribute;

• NaturalOrderComparator for a member class.

The paths are used to name and address each constituent uniquely within a model but consistently across models. The paths start with a '/' and the name of the model. Then, it includes the name, as in getName(), of each constituent to go through until the name of the current constituent is reached. Here are some examples of getPath() values:

• /PADL|padl for a package;

• /PADL|padl|kernel|padl.kernel.IConstituent|getName() for a method;

• /PADL|padl|kernel|padl.kernel.IConstituent|setName(char[]) for a method;

• /PADL|padl|kernel|impl|padl.kernel.impl.Constituent|name for an attribute;

• /PADL|padl|kernel|impl|padl.kernel.impl.GenericContainerOfNaturallyOrderedConstituents$NaturalOrderComparator for a member class.

The class padl.path.Finder in the PADL project can be used to walk the paths.

The PADL metamodel provide two types of visitors to allow third-party to analyse PADL models. It follows the standard API for visitors but with a twist for the implementation. Understading the PADL visitors is easy!