Version 3.4.0

In Faktor-IPS ist es möglich, Validierungsregeln an Vertragsteilklassen zu definieren. Mit Faktor-IPS 3.4 können diese Regeln im Produktbaustein aktiviert bzw. deaktiviert werden. Im Modell wird eingestellt, ob die Regel konfigurierbar ist.

Im Editor für Produktbausteine kann nun eingestellt werden, ob die Regel ausgeführt werden soll oder nicht.

In Faktor-IPS wird für jeden Produktbaustein automatisch eine Anpassungsstufe angelegt. Die Konfiguration eines Bausteins findet daher immer direkt in der Anpassungsstufe statt. Damit ist es prinzipiell möglich, alle Daten in einer späteren Anpassungsstufe zu ändern. Mit der Version 3.4 ist es möglich, Produktbausteinattribute auch ohne diese Möglichkeit zu definieren.

Dies hat verschiedene Vorteile. Zum einen ist für die Produktdefinition damit sichergestellt, dass sich bestimmte invariante Werte tatsächlich nicht ändern. Bisher musste das über Prüfungen sichergestellt werden. Dem Fachanwender werden diese Attribute mit einem gelben S kenntlich gemacht.

Auf der anderen Seite erleichtert es die Arbeit für den Entwickler. Dieser muss für feste Attribute nicht erst die richtige Anpassungsstufe ermitteln um an den korrekten Wert zu gelangen.

In Faktor-IPS 3.4 wurde die Refactoring-Unterstützung weiterentwickelt. Attribute können nun nicht nur umbenannt, sondern auch innerhalb einer Klassenhierarchie „hochgezogen“ werden (Pull Up). Diese Funktion wird momentan für Attribute von Produktbausteinklassen, Vertragsteilklassen und Aufzählungstypen angeboten und ist über das entsprechende Kontextmenü erreichbar.

Zur Konfiguration des Refactorings öffnet sich – wie aus den anderen Refactorings bereits bekannt – ein spezieller Wizard. Der Benutzer muss hier lediglich die gewünschte Zielklasse auswählen.

Im Beispiel steht nur eine mögliche Zielklasse zur Verfügung, nämlich die Vertragsteilklasse Vertrag. Diese ist die Superklasse von HausratVertrag, in welcher sich das Attribut versSumme befindet. Ein Klick auf Finish bewirkt, dass das Attribut versSumme aus HausratVertrag entfernt, und in Vertrag angelegt wird.

Bei dem Refactoring werden Referenzen auf das ursprüngliche Attribut in Vertrag automatisch auf das neue Attribut in HausratVertrag umgeleitet. Auch der für das hochzuziehende Attribut generierte Java-Quellcode wird automatisch in die entsprechende Java-Superklasse verschoben.

Es kann nicht immer gewährleistet werden, dass der Java-Quellcode nach dem Refactoring frei von Kompilierungsfehlern ist. In diesem Fall wird der Benutzer aber rechtzeitig über diesen Umstand informiert. Beispiel: Das Attribut plz der Klasse HausratVertrag (siehe Tutorial-Projekte) soll in die Superklasse Vertrag hochgezogen werden. Die Methode setPlz(String) wurde manuell bearbeitet:

 
      /**
     * {@inheritDoc}
     * 
     * @generated NOT
     */
    @Override
    public void setPlz(String newValue) {
        String oldPlz = plz;
        this.plz = newValue;
        notifyChangeListeners(new PropertyChangeEvent(this, PROPERTY_PLZ,
                oldPlz, plz));
        notifyChangeListeners(new PropertyChangeEvent(this, 
                PROPERTY_TARIFZONE, null, getTarifzone()));
    }

In der letzten Zeile wird die Methode getTarifzone() aufgerufen. Die Methode getTarifzone() wird aber vom Refactoring nicht automatisch in die Superklasse verschoben. Daher wird es in der Methode setPlz(String), die in die Superklasse Vertrag verschoben wird, zu Kompilierungsfehlern kommen, nachdem das Refactoring ausgeführt wurde. Der Refactoring-Wizard weißt den Benutzer rechtzeitig auf diesen Umstand hin (siehe Abbildung unten). Nach dem Refactoring läuft außerdem der Codegenerator. Wenn der Code nicht manuell angepasst wurde, kann der Codegenerator im allgemeinen die Fehler selbst beheben.

Der Refactoring-Wizard zum Verschieben von Objekten wurde verbessert. Es ist ab jetzt möglich, den Wizard aufzurufen, auch wenn mehrere Objekte selektiert wurden. Im Wizard wird noch einmal angezeigt, wie viele Elemente verschoben werden. Die Objekte können hierbei aus unterschiedlichen IPS-Paketen stammen. Objekte, die sich bereits im ausgewählten Ziel-Paket befinden, werden vom Refactoring ignoriert.

Faktor-IPS generiert Artefakte in zwei verschiedene Ordner: Ein Ordner für Dateien, die vom Entwickler angepasst werden können und ein Ordner für 100% generierte Dateien. Die 100% generierten Dateien wurden bisher automatisch als Derived Files markiert. Da sich in bestimmten Umgebungen damit Problemen ergaben, kann dieses Verhalten nun in den Einstellungen des Generators deaktiviert werden.

Folgende Änderungen ergeben sich im bestehendem generierten Code.

Für produktkonfigurierte Compositionsbeziehungen wird eine Methode generiert, mit der ein neues Kind direkt mit dem passenden Produktbaustein erstellt werden kann. Diese Methode verwendete bisher den Konstruktor mit dem Produktbaustein als Parameter. Der neue Code verwendet die passende Factory-Methode am Produktbaustein.

Bisher war es nicht möglich die generierten TableRow Klassen mit manuellem Code zu ergänzen oder zu verändern. Zukünftig werden auch in TableRow-Klassen die JavaDoc Custom Tags @generated verwendet und manuelle Änderungen gehen nicht mehr verlohren. Bestehende TableRow-Klassen werden vom Generator nicht überschrieben. Damit der Generator sie neu generiert müssen Sie zunächst gelöscht werden. Da sich am Inhalt des generierten Codes nichts geändert hat, ist dieser Schritt nicht unbedingt notwendig, wird aber empfohlen.

Bisher wurde das JavaDoc von Klassen nicht vom Generator überschrieben. Das war notwendig, da andernfalls die zusätzlich eingeführten Custom-Tags (z.B. @implements zum hinzufügen von Interfaces) überschrieben wurden. Mit dieser Version werden alle Kommentare bis zum Custom-Tag @generated vom Generator überschrieben. Vom Entwickler hinzugefügte Kommentare oder Custom-Tags müssen daher nach @generated eingefügt werden.

Für die Version 3.4 ist eine Migration der Projekte notwendig. Die automatische Migration von Faktor-IPS passt die Modellklassen für die neuen Funktionen an. Die bestehenden Validierungsregeln werden als nicht konfigurierbar markiert. Außerdem wird an allen bestehenden Produktbauattributen eingestellt, dass diese in Anpassungsstufen änderbar sind. Manuell sollten folgende Schritte unternommen werden:

• Beim überschreiben von Attributen im Faktor-IPS Modell kam es vor, dass im XML das Description-Element doppelt erstellt wurde. An betroffenen Modellobjekten wird eine entsprechende Warnung angezeigt. Diese doppelten Description-Elemente müssen manuell im XML entfernt werden.
• Um bestehende TableRow Klassen mit den @generated Tag zu generieren müssen diese zunächst gelöscht werden. Manueller Code war in diesen bisher nicht möglich. Die Klassen heißen <Tabellenname>Row.java (siehe Änderungen am Codegenerator)
• Die Java-Klassen sollten überprüft werden ob im JavaDoc @implements oder @extends vor einem @generated steht. Nach der Migration werden diese überschrieben. Zur Suche kann man mit Eclipse alle *.java Dateien mit folgender Regular Expression durchsuchen: (@implements|@extends)[\s\S]*@generated[\s\S]*(class|interface)