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
Next revision Both sides next revision
padl [2014/02/16 09:39]
yann
padl [2014/04/17 11:09]
yann
Line 5: Line 5:
 ===== Levels of Models ===== ===== Levels of Models =====
  
-There are three different levels of abstractions to model programs, collectively called abstract-level 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 ''​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...);
Line 15: Line 15:
     * A ''​IDesignMotif''​ represents a design motif, i.e., the solution to a design pattern model in ''​PADL Design Motifs''​.     * 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 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}} {{:​abstractmodels2.jpg|Abstract Models}}
Line 27: Line 27:
 ===== Binary Class Relationships ===== ===== Binary Class Relationships =====
  
-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:+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;+    * ''​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;+    * ''​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;+    * ''​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;+    * ''​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;+    * ''​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;+    * ''​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.+    * ''​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''​.
  
 {{:​relationships2.jpg|Relationships}} {{:​relationships2.jpg|Relationships}}
Line 51: Line 51:
 ===== Generators and Walkers ===== ===== 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:+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:
  
 <​code>​ <​code>​
Line 57: 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 70: Line 70:
 </​code>​ </​code>​
  
-Obviously, the class InheritanceImplementationCounter implements IWalker.+Obviously, the class ''​padl.creator.classfile.test.creator.InheritanceImplementationCounter'' ​implements ​''​padl.visitor.IWalker''​.
  
  
Line 76: Line 76:
 ===== Method Invocations ===== ===== 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:+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 IMethod container that is the calling method (in which the method invocation can be found.) (Dirty Hack.)+    * a ''​padl.kernel.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+    * a ''​int cardinality''​ value 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 targetEntitythe entity declaring the called method. ([[Dirty Hack]].)+    * an ''​IEntity targetEntity''​ that references ​the entity declaring the called method. ([[Dirty Hack]].)
  
-    * int visibilitythe visibility of the called method. ([[Dirty Hack]].)+    * an ''​int visibility''​ values that is the visibility of the called method. ([[Dirty Hack]].)
  
-    * IAbstractMethod calledMethoda reference to the called method.+    * an ''​IAbstractMethod calledMethod''​ that is a reference to the called method.
  
-    * List callingFieldsa list of the fields (if any) through which the called method is invoked. ([[Fragile Code]].)+    * a ''​List callingFields''​ that is 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]].)+    * an ''​IEntity fieldDeclaringEntity''​ referencing ​the ''​IEntity'' ​declaring the (last) field through which the called method is invoked. ([[Dirty Hack]].)
  
  
  
-===== ''​getName()'' ​and ''​getPath()''​ Methods ​=====+===== Names and Paths =====
  
-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.)+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:
  
-Here are some examples of getID() :+    * ''​padl''​ for a package;
  
-    * padl for a package;+    * ''​getName()'' ​for a method;
  
-    * getName() for a method;+    * ''​setName(char[])'' ​for a method;
  
-    * setName(java.lang.String) ​for a method;+    * ''​name'' ​for an attribute;
  
-    * addA(int, padl.example.aggregation.A) ​for a method;+    * ''​NaturalOrderComparator'' ​for a member class.
  
-    * name for an attribute.+The paths are used to name and address each constituent uniquely within a model but consistently across modelsThe 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:
  
-    * Member ​for a member class, member interface, or member ghost.+    * ''/​PADL|padl'' ​for a package;
  
-Here are some examples of getName() ​:+    * ''/​PADL|padl|kernel|padl.kernel.IConstituent|getName()''​ for a method;
  
-    * padl for a package;+    * ''/​PADL|padl|kernel|padl.kernel.IConstituent|setName(char[])'' ​for a method;
  
-    * getName ​for a method;+    * ''/​PADL|padl|kernel|impl|padl.kernel.impl.Constituent|name'' ​for an attribute;
  
-    * setName ​for a method;+    * ''/​PADL|padl|kernel|impl|padl.kernel.impl.GenericContainerOfNaturallyOrderedConstituents$NaturalOrderComparator'' ​for a member class.
  
-    * addA for a method; +The class ''​padl.path.Finder'' ​in the ''​PADL'' ​project ​can be used to walk the paths.
- +
-    * 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)