Yann-Gaël Guéhéneuc

Visits for this page:

Since 07/09/20

Ptidej demo

Introduction

The idea is to have a meta-model to represent design patterns, dedicated to instantiation and detection. Once a design pattern (such as Composite, Facade, Mediator, Singleton so far) has been described using this meta-model, it is possible to instantiate it on a given user code (to adapt the user code to the pattern specifications) and to detect instances of this pattern (with more or less accuracy level) within given pieces of code.

Such a representation has two purposes: design patterns are now first-class entities within the language (in a language-independent way), and it is possible to detect design defects (pieces of code that relate to specific design patterns with very low accuracy or that relate to no known design patterns) to automatically improve the overall design of the application (at a higher level than the Law of Demeter or others) by applying refactorings.

Demo

This page presents a demo of our tool MACRViewer (Model, Analysis, and Constraints Results Viewer). It may take time to load since the jar archive is quite big (you can download this file below).

The tool demonstrates the basics of our research. (This is only a simple demo, the real tool behaves differently on certain actions.)

First, click the Load project button, this will load a simple (demo) application within the tool. This application is represented using a visual notation related to the Class Diagram notation of [GoF94]. The visual notation may be modified to include more or less details by (de)selecting any of the checkboxes located on the bottom right corner of the pane.
The application consists of a Main class, that creates an instance of the Document class, and attaches to it instances of the classes Title, Paragraph, and IndentedParagraph.
Second, click on the Load extra information button. An new diagram similar to the previous application appears. This diagram contains more information: the relationship between the class Document and the interface Element has changed from an association to a composition. The extra information about the dynamic behaviour of the program is obtained using our dynamic analysis tool Caffeine.
Third, click on the Load concrete patterns button. New graphical elements appear on the class diagram. Click on the corner of the box highlighting the class Document:

This highlights the related class and brings up a new element explaining in more details the relationship between these classes.
It means, in our example, that the classes Document, Element, and Paragraph are part of a Composite pattern as described in the [GoF94], with 25% of accuracy. This accuracy value corresponds to the fact that according to the "pure" definition of the Composite pattern, the class Document should implement interface Element, as it is suggested by the line:

XCommand = Composite, Component | javaXL.XClass c1, javaXL.XClass c2 | c1.setSuperclass(c2.getName());
The results presented here have been automatically obtain from our constraints system.
A model of the application augmented with dynamic information is used as domain for a set of constraints dedicated to find instances of the Composite pattern. The constrain solver finds all the possible solutions and also automatically relax constraints to find more solutions with less and less accuracy. This solver, Ptidej Solver, is an extension of the explanation-based contraint programming system PaLM developed by Narendra Jussien on top of the Choco constraints system.
Finally, once a solution (a set of classes that correspond to a specific design pattern with more or less accuracy) is chosen, click on the Modify source structure button to automatically apply the modifications suggested for this group of classes to instantiate at 100% the corresponding design pattern. Thus, the class Document implements interface Element.

		File
28 Jul 04	Jar file for the demo. applet (including the .html file needed to run the demo).	jar