Graph transformation-based Refactorings using Fujaba

Transcription

1 Graph transformation-based Refactorings using Fujaba Leif Geiger 1 Software Engineering Group 1, Department of Computer Science and Electrical Engineering, Wilhelmshöher Allee 73, Kassel, Germany leif.geiger@uni-kassel.de Abstract. This paper describes how refactorings can be implemented using Fujaba. It shows how the given meta model can be imported into Fujaba, how the given GXL files can be loaded and stored, how the refactorings can be implemented and how user interaction is done using Fujaba. Additionally, some benchmarks are presented which shows the usability in real world applications. 1 Import of the meta model First thing needed to implement refactorings in Fujaba is to import the given meta model for the Java Program Graph. This meta model was given as ArgoUML file and as exported XMI. Since Fujaba is not able to import both of the formats we have to find a different way. We converted the ArgoUML file to an ECore model using the Argo2Ecore plugin 1 for eclipse. From such ECore model we generated Java code which could then be imported into Fujaba using the binary import command offered by Fujaba s Refactoring plugin. This way we got the given meta model as class diagram in Fujaba which could then be used to implement the refactorings. 2 Loading and saving of the GXL files Next step is the loading of the instance graph which is given in GXL format for this case study. For this two possibilities exist. First, one could import the GXL file into a Fujaba story pattern and create a method from this pattern which creates the given instance graph at runtime. The second possibility is to write a generic GXL loader which loads the GXL file at runtime and creates the instance graph described in the file then. We choose the second possibility because it is more flexible since one just need to open a new file if one wants 1

2 2 Geiger to load a different program graph instead of a whole import, generate, compile, run cycle. To be able to work on a GXL file we first have to convert it to a graph representation. We used the JAXB compiler 2 for this task. JAXB takes an XML schema as input and creates Java classes for the different types described in this schema. It also creates a Unmarshaller and a Marschaller that is able to load an instance of the XML schema into a instance graph using the created classes and to serialize an instance graph back to XML. The created classes can again be imported to Fujaba using the binary import. Then we need to convert the generic GXL instance graph into the Java Program Graph. The GXL graph e.g. contains nodes of type Node which type attribute points to another Node object which name attribute is Package. For such a structure an object of type Package has to be created in the Java Program Graph. Therefor a mechanism is needed that allows reflective creation of Java classes and reflective changing of attributes since in the example mentioned above the String Package has to be used as class name. We used the feature abstraction module for this purpose S07 since it offers reflective access to many meta models such as Fujaba generated models, EMF models or JMI models. Using this technologies we are able to load a Java Program Graph from GXL. If the Program Graph is changed, we use the same mechanism to convert it back to a GXL graph and then use the JAXB marshaling mechanism to serialize it back to GXL. 3 Refactoring rules As we now have the needed meta model and a mechanism to create an instance graph from a given GXL file, we can now implement refactoring rules that work on this instance graphs. Till now we implemented the Encapsulate field and the Pull up method refactoring. Every refactoring is implemented in a subclass of AbstractRefactoring and has at least the methods checkprecondition() and perform() whereas the parameters of this two methods are the parameters specified for the refactoring in the case study proposal. Figure 4 shows the checkprecondition() method for the EncapsulateField class. In Fujaba a UML activity diagram models the control flow of a given method. Each activity may contain graph transformation visualized as UML collaboration diagram. Left-hand side and right-hand side are combined in Fujaba using create and destroy stereotypes. The first activity in figure 4 now checks if the variable passed as parameter really is a field of the passed class. If this is not the case the method is left and is returned. Otherwise a method is searched which has the same name as the setter or getter method to create and has a different static property as the passed field. If such a method is found the refactoring can t be applied and so the method is again left with. Otherwise all preconditions are met and so 2

3 Refactorings using Fujaba 3 is returned. Nodes where the class name is not shown are so called bound objects as e.g. the two nodes in the first activity. Such nodes are not searched but instead are reused from previous matches or given by parameters. Note, that the precondition does not check for a valid signature of a probably existing access method since this keeps the method simpler and was not asked in the case study proposal. Figure 6 shows the method that really does the Encapsulate field refactoring. In the first activity the method described above that checks the precondition is called and if it passes the refactoring is actually applied. The second activity binds the local variables type and visibility and the third activity sets the visibility of the field to private. The fourth activity checks if a setter method with the correct signature exists. We use negative objects (objects that are crossed-out) to ensure the right number of parameters here. If no setter method is found in that activity, one is creates in the activity right to it. Note, that in that activity the node type is displayed with a dashed border. That means that that node is an optional node because a return type can exist but is null if the return type is void. So, the type edge from the param node is only creates if such a type object exists. To set the visibility of the setter object another method is called which handles the user interaction. This is discussed in the next chapter. The next two activities create a getter method if needed. The next activity is a so-called for-each activity. Such an activity performs the graph transformation for every possible match. This activity calls the encapsulate() method for every Update node that updates the given field and that is not inside the setter body. The check if this operation is inside the setter body is done using a so-called path expression (the double arrow). The used path expression revexpression* visits every node that is reachable by traversing the expression edge in opposite direction zero to many times starting at the update node. If none of the found nodes is the previously bound setterblock node the pattern was applied fully and so the method call is performed. The match is skipped otherwise. The next activity does the same for the Access nodes. Note, that we extracted the functionality that really encapsulates an Access or Update node to another method to avoid code duplication. Figure 5 shows this method. 4 User interaction To visualize the Java Program Graph we use the object browser edobs GZ06. edobs visualizes the Java heap structure as graph. Since it also uses the feature abstraction layer mentioned above, edobs is able to access various models. Figure 1 shows an excerpt of the Java Program Graph in edobs. This generic presentation of the Program Graph is usable but due to its huge size somehow hard to view. It would be possible to create a Swing or SWT interface which better displays the important parts of the graph. Such UI can easily be integrated

4 4 Geiger with the Fujaba generated code since Fujaba generates standard Java code. Due lack of time, we have not yet written such a UI. Fig. 1. edobs visualzing the Java Program Graph To now perform a refactoring one has to create an object of the class implementing that refactoring in edobs. Then one may call the perform() method on that object. edobs asks for the parameter of that method. Given a set of parameters the method is then executed. Figure 3 shows a screenshot of edobs parameter dialog. The case study not only asks for a way to interactively invoke refactorings but also to ask for user feedback during the refactoring process. We solved this task by implementing a small Swing UI and integrated it into the Fujaba graph transformation rules. This UI can either be generated using UI editors as the eclipse Visual Editor or coded by hand. Figure 7 shows the askforvisibility() method that decides which visibilities for the access methods are possible and then if there is more than one possibility asks the user which one to choose. The last activity in Figure 7 contains the Java code pasted from a UI editor. This code opens a dialog as the one shown in Figure 3 during a refactoring.

5 Refactorings using Fujaba 5 Fig. 2. Method call in edobs Fig. 3. Visibility dialog shown during a refactoring 5 Performance The presented refactoring solution is fast enough to be usable in real world applications. We benchmarked it using the GXL file for the simplified example in version 1.0. The benchmarks were performed on a Pentium M with 1.8GHz, 2GB Ram under Java 1.6 on a Windows XP system. Loading of the GXL file takes approximately 2000ms. Applying the Encapsulate field refactoring on all possible fields (12) takes 110ms. Applying the Pull up method refactoring

6 6 Geiger on all possible methods (4 out of 5) 3 takes 120ms. Writing the result back to file takes 320ms. edobs is fast enough to display all nodes of the example file in less than seconds. But to work fluently with edobs, e.g. move around nodes etc., one has to disable the shortest path edge layouter and use a trivial node to node layouter. Otherwise edobs reacts rather slowly. 6 Conclussions This paper presented a solution to the refactoring case study using Fujaba. It shows that the more sophisticated features of Fujaba such as negative and optional nodes and edges, path expressions, for-each activities are really useful to create understandable rules. The possibility to model complex control flow and to extract subfunctionality to methods is a must-have when implementing such rather complex refactorings. The possibility to easily integrate external Java libraries such as JAXB, the feature abstraction layer or Swing is a real advantage for this case study. The code generated by Fujaba is definitely fast enough to be used also on big program graphs. Additionally edobs offers a graph editor and browser which is fast enough to handle such big graphs. References FNT98 T. Fischer, J. Niere, L. Torunski: Konzeption und Realisierung einer integrierten Entwicklungsumgebung für UML, Java und Stroy-Driven-Modeling (german), Diploma thesis, Universität-Gesamthochschule Paderborn, Fu07 Fujaba Homepage, Universität Paderborn S07 C. Schneider: CoObRA: Eine Plattform zur Verteilung und Replikation komplexer Objektstrukturen mit optimistischen Sperrkonzepten (german), PhD Thesis, GZ06 L. Geiger, A. Zündorf: edobs - Graphical Debugging for eclipse, 3rd International Workshop on Graph-Based Tools (GraBaTs), The example GXL file contains only one generalisation in contrast to the Java source code.

7 Refactorings using Fujaba 7 7 Appendix 7.1 Rules of EncapsulateField EncapsulateField::checkPrecondition (container: Class, var: Variable, gettername: String, settername: String, useaccessors: Boolean): Boolean // does the variable belongs to the given container? var container // if a setter or getter is found that has a different static property then the refactoring can't be applied container body:methodbody method :Operation isstatic!= var.isisstatic() gettername.equals (method.getname()) settername.equals (method.getname()) Fig. 4. checkprecondition() method for the Encapsulate field refactoring EncapsulateField::encapsulate (container: Class, accessmethod: Operation, accessor: Expression, useaccessorsalways: Boolean): Void else containingclass:class containingbody:methodbody container useaccessorsalways accessor revexpression* containingblock:block accessor call :Call actualparameter parent :Expression expression expression child:expression actualparameter expression actualparameter settercall :Call link accessmethod Fig. 5. Helper method to encapsulate a update or access

8 8 Geiger Fig. 6. perform() method for the Encapsulate field refactoring

9 Refactorings using Fujaba 9 EncapsulateField::askForVisibility (visibility: String, name: String): String "public".equals (visibility) else visibility 1: StringArray choice := nul "private".equals (visibility) 1: choice := new String "public", "default", "protected", "private" else 1: choice := new String "public", visibility visibility final JDialog dialog = new JDialog(); dialog.settitle("visibility for " + name); JRootPane rootpane = dialog.getrootpane(); JPanel panel = new JPanel(); panel.setlayout(new FlowLayout()); rootpane.setlayout(new BorderLayout()); rootpane.add (BorderLayout.CENTER, panel); ButtonGroup group = new ButtonGroup(); for (String text : choice) JRadioButton button = new JRadioButton(text); button.setselected(text.equals(visibility)); group.add(button); panel.add(button); JButton button = new JButton("OK"); button.addactionlistener(new ActionListener() public void actionperformed(actionevent e) dialog.setvisible(); ); rootpane.add(borderlayout.south, button); dialog.setmodal(); dialog.pack(); Dimension screensize = dialog.gettoolkit().getscreensize(); Dimension size = dialog.getsize(); int y = (screensize.height - size.height) / 2; int x = (screensize.width - size.width) / 2; dialog.setlocation (x, y); dialog.setvisible(); Enumeration<AbstractButton> elements = group.getelements(); while (elements.hasmoreelements()) AbstractButton abstractbutton = (AbstractButton) elements.nextelement(); if (abstractbutton.isselected()) visibility = abstractbutton.gettext(); break; Fig. 7. Method with user interaction

10 10 Geiger 7.2 Rules of PullUpMethod PullUpMethod::checkPrecondition (source: Class, : Class, method: MethodBody, makeabstract: Boolean, keepmethods: HashSet): Boolean source _extends* method op:operation type type:classifier name!= source.getname() samebody: MethodBody sameop :Operation signature(sameop).equals(signature(op)) revextends* subclass : Class subop type type method each time signature(sameop).equals(signature(op)) name subop:operation == op.getname() subbody:methodbody end method block : Block expression* expression :Expression each time test (expression, ) end Fig. 8. checkprecondition() method for the Pull up method refactoring

11 Refactorings using Fujaba 11 PullUpMethod::test (expression: Expression, container: Class): Boolean access := (Access) expression link var : Variable access _this == update := (Update) expression link var : Variable update _this == parent :Access _this == call := (Call) expression link op:operation var clazz :Class xpression expression call _this == parent :Access _this == expression call revextends* container maybe container == clazz op _interface :Interface container revextends* superclass :Class implements _interface maybe container == superclass op body:methodbody clazz :Class maybe container == clazz revextends* container Fig. 9. Helper method to for checkprecondition()

12 12 Geiger PullUpMethod::perform (source: Class, : Class, method: MethodBody, makeabstract: Boolean, keepmethods: HashSet): Boolean method op: Operation checkprecondition (source,, method, makeabstract, keepmethods) else makeabstract method isabstract := newop := copyoperation( op, ) isabstract := source revextends* subclass :Class each time subclass keepmethods name subop:operation == op.getname() subbody:methodbody subop link subbody link op call :Call end subop visibility == "private" visibility := "protected" makeabstract revextends* superclass :Class isabstract == extends each time newop := copyoperation( op, subclass newbody:methodbody subclass :Class isabstract == newblock :Block else subop:operation name == op.getname() subbody:methodbody maybe == superclass end // TODO "use destination type where possible" Fig. 10. perform() method for the Pull up method refactoring

13 Refactorings using Fujaba 13 PullUpMethod::copyOperation (op: Operation, : Class): Operation newop :Operation newbody:methodbody isabstract := op.isisabstract() isstatic := op.isisstatic() name := op.getname() isfinal := op.isisfinal() visibility := op.getvisibility() op type type type:classifier op parameter param : Parameter type newop parameter type newparam :Parameter type:classifier end newop Fig. 11. Helper method that copies a operation PullUpMethod::signature (op: Operation): String 1: String signature := op.getname() + "(" op parameter param :Parameter type classifier :Classifier 1: signature := signature + classifier.getname() + "," end signature + ")" Fig. 12. Helper method that calculates a operation s signature