Refactoring

Setup a project

• Open the project created during the Actifsource Tutorial Simple Service or make an new one with the new project with name and namespace ch.actifsource.tutorial.refactoring as shown in this tutorial
• Create a new Package with name refactoring
• Create a Refactoring resource of type ch.actifsource.ui.refactoring.Refactoring with name Refactoring

• You need to convert this project to a Eclipse Plugin Project
• Right click on the project ch.actifsource.tutorial.builtin in the navigator to open the context menu.
• Go into the submenu Configure and click on Convert to Plug-in Projects…

• Check the checkbox in front of ch.actifsource.tutorial.refactoring
• Click Finish

• This will convert the project however there will be some error and warning needed to be fixed.

• Right click on the Actifsource classpath container
• Go into the submenu Build Path and select Remove from Build Path

Create and register a refactoring aspect

• Open the MANIFEST.MF

• Add a dependency to the ch.actifsource.core" and the ch.actifsource.ui.refactoring-Plugin

• Create a new java source folder for the aspect implementation.

• We recommend naming the new source folder src-aspect
• Click Finish

• Create a new java class extending the ch.actifsource.core.model.aspects.impl.AbstractRefactorerAspect class

• Add the following constructor function to the class

public CallGroupRefactoringAspect() {
  super("1.0.0",
        Date.from(LocalDate.of(2024, 1, 6).atStartOfDay(ZoneId.systemDefault()).toInstant()),
        "Call to Callgroup");
}

• The first parameter defines a version string for the aspect. The following three parameters are used to specify the date when the refactoring was written.The last parameter is the name. The arguments are shown in the dialog and used to sort the refactoring aspects.

• Register the java class in the Refactoring instance

• The result should look like above. There must be no more model inconsistencies be present.

• Open the Service class
• Select the call relation and cut the resource by using the clipboard (Ctrl+X)

• Create a new Relation named group with a new Class named “CallGroup” used as the range

• Paste the call relation from the clipboard into the new Callgroup

• Add an additional Attribute named async of type boolean with default value false
• We only use an attribute to keep the tutorial simple. An alternative would be to create a subclass of CallGroup instead.

• First we want to have more convenient access to the resource guids.
• To accomplish this, we need to check a setting in the project settings of ch.actifsource.tutorial.refactoring
• Right-click on the project and select Properties

• Check in the actifsource settings whether the option “generate javamodel” is set

• If the “generate javamodel” option is not set, this can be set or add a the ExportWithoutStatements buildconfig to the src-gen target folder for exporting java classes for the SimpleService packages
• This will generate a class for each package containing a constant for each resource.

-If you cannot use the buildconfig ExportWithoutStatements, check in the Built-in Dependencies tab whether the JAVAMODEL is available. If not, add it via the Add Builtin button.

• Implement the refactor method

• The refactor method has only two parameters an IModifiable and a list of packages. The modifiable provides the context to access the actifsource resources. The package list contains the actifsource packages selected by the user when starting the refactoring. How the packages selection is interpreted is up to the implementer.

• In general you need to use the two classes Select and Update. These are facades providing a convenient way to select and update resource information in a context. To get information about the available methods, open the class and a have a look at the javadoc comments on how to use them.

• The actifsource API works with statements and resources. A Statement is a triple connecting two resources (subject, object) through a property (predicate). The subject is the resource whose type (class) defines the predicate (property). The object is an instance of properties range. This is almost the same you see in the resource editor. In our example Patient is an instance of Service Person refers the Call throw the call defined in the Service class. For example you will get a statement Person (subject), call (predicate), Create (object) because Person refers to Create through the call relation. This is different from the diagram editor where subject and object are represented by their type.

• The old model looked like this

  

  and the new model looks like this now

  

The only thing the refactoring has to do is adding a CallGroup into each Service and move the Call into the group.

• Select all Service instances in packages posted to the refactorer
• The instanceWithPackage method takes an ISelectable and the GUID of a class. The result is an Iterable providing all instances reachable through the selectable. Since each IModifiable is also an ISelectable, you can use the IModifiable passed to the refactorer.

• Create a new CallGroup using the Update-Facade and add it to the Service-Instance
• The Update-Facade always requires an IModifiable to work with. Using the createAndInitializeResource method you can create a new instance of a type in the specific package. If you have a named resource, it is recommended to use the overload taking a name, in this case group. The last parameter defines the default values for the attributes and relations when creating the resource and can be left out. For each property not found in the defaultValue map the default defined in the model will be used.

• Move the Call to the group
• This time the method is located on the RefactorUtil. The reason for this is that the Update-Facade only provides simple modification methods and no selects. The moveStatements method uses methods from both the Select and Update method and is more complex. The moveStatements method take the IModifiable, a Property, the source and the target. It is simply often used when moving a Property from one class to another.
• By using the cut and paste in ResourceEditor, actifsource automatically detected that you have moved the Property call

• Open the Patient to see that it is actually invalid.
• As you can see the group relation that is already there and it would be possible to do change the model by hand.

• Open the context menu on the project or the package containing the Patient service

• Select the Call to Callgroup.
• Press Finish.

• The Patient service is now refactored
• As you can see, the values passed to the constructor are shown in the refactoring dialog. In actifsource we use the aspects to provide refactorings whenever we change the metamodel.

Part IV Update the templates

• The refactoring you have written only updates the instances. This is common practice, writing a refactoring for the service model and the templates makes no sense, since updating the classes is different for each step. The same applies for the templates.
• Open the ServiceImpl template
• Go to the Service.call selector by clicking on the first errormarker
• Change it to Service.group.call

• Add a new line using the async attribute

• Open the generate PatientImpl.java and update the protected regions.