Index 
Welcome
Search

Info.
Personal
Publications
Ph.D. thesis
References
Teaching
Tutoring
Conferences
RDT

Ptidej
Introduction
Reengineering
Modification
Analysis
Detection
Demo
Download

Caffeine
Introduction
Download

PatternsBox
Introduction
Download

Eclipse
Prolog
Claire
Ptidej

LaTeX
Bibex
Multilingual.bst
Vertical Line

Misc.
Amiga
Capoeira
Citations
Red Flag
Human Rights
Titrax
BusClock

Private
Conferences
Shared files
Pictures
Downloads

    
Visits for this page:
8440
Since 07/09/20

Valid HTML 4.01!
   Static and dynamic analyses of programs 
In addition to the graphic framework, the JTU archive contains three examples of visualisation tools. The first one, jtu.tests.RepositoryViewer, simply displays the design patterns implemented using the meta-model defined into the package patterns.repository of PatternsBox.
The second tool, jtu.tests.SolutionViewer, involves the detection of design patterns. Java code is analyzed and instances of design patterns are detected (from the design patterns defined into patterns.repository). The instances found are then displayed into the tool.
The third tool, jtu.tests.AACViewer, is somewhat more advanced. It required interaction with the user. It introduces an algorithm of dynamic class analysis. Here is an example of its usage:

(The following example assumes that you have extracted PatternsBox and JTU into E:\PatternsBox\ and that you have the JRE 1.2.2 (minimum) installed on your computer)
  • First, the tool needs to know where is the set of classes to analyse. Click on "Load files", choose the file E:\PatternsBox\PatternsBox.ini (it is the directory where this file is located that is important).
  • Then, the tool needs to know which classes to analyse in particular. For this example, choose E:\PatternsBox\jtu ests\observer2\Main.class. Once the choice made, the tool loads the classes of the selected package and display them:

    The program model with an association relationship.

  • Now, it is possible to find out if the relationships among the classes are associations, aggregations or compositions. To do so, the dynamic behavior of certain classes must be analyzed. Click on the classes Composite and Main names, then click on "Add observers". The corresponding files on the disk will be modified to monitor the life and death of the instances of classes ComponentA, ComponentA and Composite. Now, click on the class Main name, then on "Create runner". A new class is created, its role is to run the Main class while supporting the monitoring.

    The program model with class Document selected.

  • It is now needed to run the class Main using the newly created class: (in a console)
    E:\Patternsox\> java -classpath . jtu.tests.observer2.MainRunner
    Additional pieces of information are printed into the console and saved on the disk into E:\PatternsBox\
  • Back to the tool, click on the class Composite name, then on "Load information". Choose the file E:\PatternsBox\jtu.tests.observer2.Composite.ini. The tool clones the current model and update the copy according to the pieces of information found into E:\PatternsBox\jtu.tests.observer2.Composite.ini. These pieces of information indicate if the relationships among classes ComponentA, ComponentB and Composite are associations, aggregations or compositions:

    The program model with a composition relationship.

  • Here, the relationship between ComponentA and Composite is a composition, the relationship between ComponentB and Composite is an aggregation (displayed in a UML-like notation).
This tool is far from perfect. No static analysis is performed to prove that the dynamic analysis is correct, i.e. that two consecutive executions give the same results. It is easy to find examples where relationships change depending on the execution (user entries, timing, system configuration, and so on).
The idea was to prove the feasibility of such a system using the meta-model aforementioned. Lot of things have still to be done on static and dynamic analyses.