User Tools

Site Tools


padl

Differences

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

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
padl [2013/11/13 07:42]
yann
padl [2017/09/06 01:54] (current)
Line 1: Line 1:
 ====== PADL ====== ====== 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 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 [[PADL Analyses|analyses]];​
  
-===== Introduction and Usage===== +    * 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;
-==== Levels ​of Models ====+
  
-There is actually three different levels of abstraction ​to model programs, collectively called abstract-level models:+    * A ''​IDesignMotif''​ represents a design motif, i.e., the solution ​to a design pattern ​model in ''​PADL Design Motifs''​.
  
-    * ICodeLevelModel that represents ​the "​raw" ​model of a programincluding only data directly extractable from the program representation.+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.
  
-    * IIdiomLevelModel that represents a model of a program where some idioms have been reified, typically binary class relationships computed using one of PADL Analyses, and some extra data have been added, for example the length of the methods.+{{:​abstractmodels2.jpg|Abstract Models}}
  
-    * IDesignLevelModel that represents a model of a program where design data is available. Typical design data is extracted from the idiom-level model, for example occurrences of design motifs.+The ''​PADL''​ project also provides ​the interfaces:
  
-    * A fourth model exists ​to describe design motifsused by the Ptidej SolverIDesignMotif.+    * ''​IAbstractModelSerialiser''​ must be implemented by any algorithm ​to serialise/​deserialise PADL models. A variety of serialisers already existincluding for popular databases, such as [[http://​www.db4o.com/​|DB4O]] and [[http://​neodatis.wikidot.com/​|NeoDatis]];​
  
-The following diagram shows the hierarchy of the interface describing models. (This hierarchy has been built thanks to Green.The root of the models is the interface IAbstractModelwhich descibes 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.+    * ''​ICodeLevelModelCreator'',​ along with ''​padl.kernel.ICodeLevelModel.create(ICodeLevelModelCreator)'',​ is an implementation ​of the Builder design patternto provide a unified ​interface ​to create PADL models. Creators exist for [[PADL Creator ClassFile|Java bytecodes]] as well as other representationssuch as [[PADL Creator AOL|AOL]] files, [[PADL Creator AspectJ|AspectJ]] ''​lst''​ files, [[PADL Creator C++ (Eclipse)|C/​C++]] ​and [[PADL Creator JavaFile (Eclipse)|Java]] source code...
  
-{{:​abstractmodels.gif|Abstract Models}}+===== Binary Class Relationships =====
  
-The PADL project also provides IAnalysis interface that must be implemented by any PADL analyses. This interface just requires that an analysis provides a invoke(IAbstractModelmethod ​to return ​new model.+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 ​relationship is identified between two entities, the following least constraining relationships are not includedFor 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'';​
  
-==== How to Create ​PADL Model from Java Bytecodes? ====+    * ''​IAggregation''​ describes ​relationship between two classes ''​A''​ and ''​B''​ such as ''​A''​ holds (possibly shared) reference(s) to (an) instance(s) of ''​B'';​
  
-The PADL meta-model (Pattern and Abstract-level Description Language) is semi-language independent meta-model. It is at the core of the Ptidej Tool Suite. It provides a set of interface ​and a reference implementation ​of the meta-model. It also provides several parsers to create PADL models from various representations of programs: AOL, AspectJ, C++, Java (byte-code), Eclipse JDT Project, and MSE files.+    * ''​IAssociation'' ​relationship between two classes ''​A'' ​and ''​B''​ such as A calls some methods ​of ''​B''​ using (aninstance(s) of ''​B'';​
  
-PADL model is typically created using the following code:+    * ''​ICreation''​ a relationship between two classes ''​A''​ and ''​B''​ such as ''​A''​ create (an) instance(s) of ''​B'';​
  
-<​code>​ +    * ''​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'', ​(aninstance(sof class ''​B''​.
- final ICodeLevelModel codeLevelModel = +
-   ​Factory.getInstance().createCodeLevelModel("​A"​)+
- ​codeLevelModel.create( +
-   new CompleteClassFileCreator( +
-   ​DefaultFileRepository.getInstance(),​ +
-       new String[] { "​dir1/​dir2/​A.class"​ }), true); +
-</​code>​+
  
-In general, a code-level model can be obtain for a system through reverse-engineering/​parsing using:+{{:relationships2.jpg|Relationships}}
  
-<​code>​ +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 Analyses|padl.analysis.repository.AACRelationshipsAnalysis]]''​.
- ​final ​ICodeLevelModel ​codeLevelModel = +
-   ​Factory.getInstance().createCodeLevelModel(A Name); +
- ​codeLevelModel.create( +
-   new A Creator( +
-   A File Repository.getInstance(),​ +
-       new String[{ Some files }), Recurse in directories);​ +
-</​code>​+
  
-where: 
  
-    * A Name can be any String; 
-    * A Creator is any class implementing the ICodeLevelModelCreator interface. A creator is the concrete parser or reverse-engineering algorithm that builds a PADL model from some files. So far, they are creators for AOL, C++, Java, Eclipse JDT Projects, and MSE files. The ICodeLevelModelCreator is a typical implementation of the Builder design pattern. 
-    * A File Repository is any class implementing the IFileRepository interface. A file repository allows the meta-model and the creator to access necessary PADL resources (constituents,​ analyses, etc.) in a platform-independent way. So far, two repositories exist, one to access files on disk, one to access files in a JAR file. 
-    * Some files are any String pointing towards the files/​directories to be parsed, as required by the creator. 
-    * Recurse in directories is a Boolean flag that allow you to specify only the top most directory of a set of source files. 
  
-Each constituent of a model has a unique ID, obtained using the getID() method. Navigation through a model is typically performed using recursive calls to the getIteratorOnActors() ​and getIteratorOnConcurrentActors() methods. (The [[PADL Creator ClassFile]] project provides two methods to retrieve (and create if needed) member entities: Utils.searchForEntity(...) and Utils.searchForEnclosingEntity(...). However, these methods should be used as little as possible as they potentially return new instances of IMemberClass (or IMemberInterface or IMemberGhost). Using these methods outside of the creator would be a Dirty Hack!).+===== Generators ​and Walkers =====
  
- +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:
- +
- +
-==== How to Create a PADL Model from Java Source Code? ==== +
- +
-A third-party project provides a means to create a PADL model from source code (instead of class files). Fetch PADL Creator Java from the SVN and use the following idiom: +
- +
-<​code>​ +
- new padl.creator.CreatorJava(DiagnosticListener,​ +
-                              Options, +
-                              Files) +
-                             ​.create(Model);​ +
-</​code>​ +
- +
-Each argument is described in the JavaDoc of the padl.creator.CreatorJava class. +
- +
- +
- +
- +
-==== How to Traverse a PADL Model using a Visitor? ==== +
- +
-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>​ <​code>​
Line 91: Line 57:
 final ICodeLevelModel codeLevelModel = final ICodeLevelModel codeLevelModel =
      ​Primitive.getFactory().createCodeLevelModel(""​);​      ​Primitive.getFactory().createCodeLevelModel(""​);​
- codeLevelModel.create(+codeLevelModel.create(
     new CompleteClassFileCreator(     new CompleteClassFileCreator(
         DefaultFileRepository.getInstance(),​         DefaultFileRepository.getInstance(),​
Line 104: Line 70:
 </​code>​ </​code>​
  
-Obviously, the class InheritanceImplementationCounter implements IWalker.+Obviously, the class ''​padl.creator.classfile.test.creator.InheritanceImplementationCounter'' ​implements ​''​padl.visitor.IWalker''​.
  
  
  
 +===== Method Invocations =====
  
-===== API ===== +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:
-==== Binary Class Relationships ====+
  
-The PADL meta-model includes an extensive hierarchy of interfaces to describes binary class relationshipsThe following figure highlights these relationshipsOf 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 includedFor example, if an aggregation relationships exists between two classes A and B, no corresponding use relationship would exist.+    * a ''​padl.kernel.IMethod''​ container that is the calling method (in which the method invocation can be found.) (Dirty Hack.)
  
-    ​* 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. +    * a ''​int cardinality''​ value that describes the cardinality of the call
- +
-    * 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. +
- +
- +
- +
- +
-==== 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;       * 1 = unique call;
       * 2 = repetitions of the call;       * 2 = repetitions of the call;
  
-    * a int type that characterises the type of method invocation:​ +    * 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''​: 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_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''​: 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; +      * ''​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''​: 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_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_CREATION''​: creation of a new instance; 
-      * INSTANCE_INSTANCE:​ method invocation from an instance method to another instance method; +      * ''​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; +      * ''​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]].) +      * ''​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]].) +
- +
- +
- +
- +
-==== The getID() and getName() 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;+    * an ''​IEntity targetEntity''​ that references the entity declaring the called method. ([[Dirty Hack]].)
  
-    * getName() for a method;+    * an ''​int visibility''​ values that is the visibility of the called method. ​([[Dirty Hack]].)
  
-    * setName(java.lang.String) for a method;+    * an ''​IAbstractMethod calledMethod''​ that is reference to the called ​method.
  
-    * addA(int, padl.example.aggregation.Afor a method;+    * a ''​List callingFields''​ that is a list of the fields ​(if any) through which the called method is invoked([[Fragile Code]].)
  
-    * name for an attribute.+    * an ''​IEntity fieldDeclaringEntity''​ referencing the ''​IEntity''​ declaring the (last) field through which the called method is invoked([[Dirty Hack]].)
  
-    * Member for a member class, member interface, or member ghost. 
  
-Here are some examples of getName() : 
  
-    * padl for a package;+===== Names and Paths =====
  
-    * getName ​for a method;+The ''​getName()''​ always returns the simple name of 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:
  
-    * setName ​for a method;+    * ''​padl'' ​for a package;
  
-    * addA for a method;+    * ''​getName()'' ​for a method;
  
-    * name for an attribute.+    * ''​setName(char[])'' ​for a method;
  
-    * Member ​for a member class, member interface, or member ghost.+    * ''​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:
  
-==== The getPath() Method and the padl.path.Finder Class ====+    * ''/​PADL|padl''​ for a package;
  
-The paths are used to represent how to get to a constituent within a model.+    * ''/​PADL|padl|kernel|padl.kernel.IConstituent|getName()''​ for a method;
  
-The paths start with a '/' ​and the name of the model (optional).+    * ''​/​PADL|padl|kernel|padl.kernel.IConstituent|setName(char[])''​ for a method;
  
-Then, each constituent to go through until the target is specified the same way:+    * ''/​PADL|padl|kernel|impl|padl.kernel.impl.Constituent|name''​ for an attribute;
  
-   - the '|' character,​ +    * ''/PADL|padl|kernel|impl|padl.kernel.impl.GenericContainerOfNaturallyOrderedConstituents$NaturalOrderComparator'' ​for member class.
-   - 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,​ +
-   ​- ​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.+The class ''​padl.path.Finder''​ in the ''​PADL''​ project ​can be used to walk the paths.
padl.1384328555.txt.gz · Last modified: 2017/09/06 01:54 (external edit)