User Tools

Site Tools


padl

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

padl [2014/02/16 08:34]
yann
padl [2019/10/06 20:37]
Line 1: Line 1:
-====== PADL ====== 
  
-PADL stands for Pattern and Abstract-level Description Language. It is a meta-model to describe programs at different levels of abstractions. 
- 
-===== Levels of Models ===== 
- 
-There are three 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 ''​padl.analysis.repository.AACRelationshipsAnalysis'',​ and some extra data have been added, for example the length of the methods, obtained using ''​padl.statement.creator.classfiles.LOCModelAnnotator'',​ or information about conditional statements, obtained using ''​padl.statement.creator.classfiles.ConditionalModelAnnotator''​. 
- 
-    * 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. 
- 
-{{:​abstractmodels2.jpg|Abstract Models}} 
- 
-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 [[http://​www.db4o.com/​|DB4O]] and [[http://​neodatis.wikidot.com/​|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 and source code as well as other programming languages, such as C/C++. 
- 
- 
- 
-===== Binary Class Relationships ===== 
- 
-The PADL meta-model includes an extensive hierarchy of interfaces to describes binary class relationships. The following figure highlights these relationships. 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. 
- 
-{{:​relationships.gif|Relationships}} 
- 
-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 AACRelationshipsAnalysis. 
- 
- 
- 
-===== Generators and Walkers ===== 
- 
-The PADL meta-model provides you with two distinct but related visitors: IWalker and IGenerator. Both visitors inherit from IVisitor but provide different methods to retreive the results of the visit: getResult() and getCode() respectively. A typical example of using one of these visitors is: 
- 
-<​code>​ 
-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());​ 
-</​code>​ 
- 
-Obviously, the class InheritanceImplementationCounter implements IWalker. 
- 
- 
- 
-===== Method Invocations ===== 
- 
-As part of an effort to improve code representation in PADL. The concept of method invocation has been added since 2004-2005. An interface 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 IMethodInvocation (and its reference implementation) includes: 
- 
-    * a IMethod container that is the calling method (in which the method invocation can be found.) (Dirty Hack.) 
- 
-    * a int cardinality that describes the cardinality of the call 
-      * 1 = unique call; 
-      * 2 = repetitions of the call; 
- 
-    * a int type 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]].) 
- 
-    * IEntity targetEntity:​ the entity declaring the called method. ([[Dirty Hack]].) 
- 
-    * int visibility: the visibility of the called method. ([[Dirty Hack]].) 
- 
-    * IAbstractMethod calledMethod:​ a reference to the called method. 
- 
-    * List callingFields:​ a list of the fields (if any) through which the called method is invoked. ([[Fragile Code]].) 
- 
-    * IEntity fieldDeclaringEntity:​ a reference to the IEntity declaring the (last) field through which the called method is invoked. ([[Dirty Hack]].) 
- 
- 
- 
-===== ''​getName()''​ and ''​getPath()''​ Methods ===== 
- 
-Although the getID(), getName(), and getPath() methods form a trio, they have different semantics. The getID() must return a unique identifier for each constituent in a model. The getName() returns the 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. (Their ID must still be unique, though.) 
- 
-Here are some examples of getID() : 
- 
-    * padl for a package; 
- 
-    * getName() for a method; 
- 
-    * setName(java.lang.String) for a method; 
- 
-    * addA(int, padl.example.aggregation.A) for a method; 
- 
-    * name for an attribute. 
- 
-    * Member for a member class, member interface, or member ghost. 
- 
-Here are some examples of getName() : 
- 
-    * padl for a package; 
- 
-    * getName for a method; 
- 
-    * setName for a method; 
- 
-    * addA for a method; 
- 
-    * name for an attribute. 
- 
-    * Member for a member class, member interface, or member ghost. 
- 
-The paths are used to represent how to get to a constituent within a model. 
- 
-The paths start with a '/'​ and the name of the model (optional). 
- 
-Then, each constituent to go through until the target is specified the same way: 
- 
-   - the '​|'​ character, 
-   - the (simple) name of the interface in padl.kernel of the constituent (or one of its super-interface,​ but always in padl.kernel),​ 
-   - the ':'​ character, 
-   - a constituent specific part: 
-     * If the constituent is an Operation, its name, a '​(',​ the list of the TypeName of the types of its arguments separated by a ','​ (if any), a '​)'​ 
-     * Its name otherwise 
- 
-The class padl.path.Finder can be used to walk the paths. 
padl.txt ยท Last modified: 2019/10/06 20:37 (external edit)