Version 3.15.0

Die wichtigsten neuen Features der Faktor-IPS Version 3.15 sind die Produktbausteine ohne Anpassungsstufen sowie das Konfigurieren von Markern für Validierungsregeln. Außerdem wurden eine reihe kleinerer Verbesserungen und Bugfixes implementiert.

Produktbausteine ohne Anpassungsstufen

Mit Faktor-IPS 3.15 kann pro Produktbausteinklasse festgelegt werden, ob an Produktbausteinen dieses Typs Anpassungsstufen möglich sind. Falls Anpassungsstufen erwünscht sind muss die entsprechende Einstellung im Abschnitt „Allgemeine Informationen“ gesetzt werden:
f10-org-new_3_15_0-new_3_15_0_productcmpttype_changingovertime

Wenn diese Einstellung gesetzt ist verhält sich Faktor-IPS beim Umgang mit Produktbausteinen wie bisher. Sind Anpassungsstufen jedoch für einen Typ deaktiviert, so können an der Produktbausteinklasse keine Eigenschaften definiert werden, die im Zeitablauf veränderbar sind. Vertragsattribute können weiterhin nur von Produktbausteinklassen konfiguriert werden, die auch über Anpassungsstufen verfügen. Produktkonfigurierte Vertragsattribute ohne Anpassungsstufen ist für die nächste Faktor-IPS Version geplant.

Es ist nicht möglich die Einstellung innerhalb einer Hierarchie zu verändern. Faktor-IPS erzeugt in diesen Fällen entsprechende Validierungsfehler.
Ansonsten ändert sich im Wesentlichen das Verhalten des Produktbaustein-Editors. Die bisherigen Schaltflächen und Beschreibungen zu Anpassungsstufen verschwinden.
f10-org-new_3_15_0-new_3_15_0_productcmptnogenerations

Unter dem Reiter „Einstellungen“ können keine Anpassungsstufen angelegt oder bearbeitet werden. Zur Konfiguration des Datums ab dem ein Produkt gültig ist, gibt es ein neues Feld. Für Produktbausteine mit Anpassungsstufen gilt weiterhin das „Gültig ab“ Datum der ersten Generation.

f10-org-new_3_15_0-new_3_15_0_productcmptsettingsnogenerations

Durch die Projekteinstellung (.ipsproject Datei) kann konfiguriert werden, ob neue Produktbausteinklassen mit oder ohne Anpassungsstufen erstellt werden sollen. Die Einstellung befindet sich im Abschnitt AdditionalSettings und wird durch die Migration auf 3.15 in allen migrierten Projekten aktiviert:
<Setting name="changingOverTimeDefault" enabled="true" />
Damit verhält sich Faktor-IPS nach der Migration zunächst wie bisher.

Marker für Validierungsregeln setzen

In Faktor-IPS können Validierungsregeln in Vertragsteilklassen erstellt werden. Oft sind die daraus gewonnenen Fehlermeldungen jedoch nur in bestimmten Zuständen oder in bestimmten Kontexten relevant. Beispielsweise soll unterschieden werden, ob es sich um eine Pflichtfeldverletzung handelt, oder ob durch den Fehler eine Beitragsberechnung verhindert wird. Diese Information könnte dann bei der Anzeige der Meldungen in der Anwendung berücksichtigt werden.

Um diese unterschiedlichen Merkmale an der Validierungsregel zu konfigurieren, gibt es ab Version 3.15 die Möglichkeit sogenannte Marker zu setzen. Dazu muss in der Datei für die Projektkonfiguration .ipsproject die Funktion in den AdditionalSettings eingestellt werden:
<Setting name="markerEnums" enabled="true" value="enums.MarkerEnum" />
Die Funktion wird durch das Attribut enabled aktiviert. Ein Faktor-IPS Enum wird über seinen qualifizierten Namen als Marker Enum eingetragen.

Der Codegenerator sorgt dafür, dass dieses Enum automatisch das Interface IMarker implementiert. Es können ausschließlich nicht-erweiterbare Enums verwendet werden, da nur diese als Java Enums generiert werden. Wenn die Einstellungen korrekt konfiguriert wurden, gibt es im Dialog für die Validierungsregeln die Möglichkeit einen oder mehrere Werte aus dem Enum als Marker zu setzen.

f10-org-selection_024

In bestehenden Projekten ist die Funktion standardmäßig deaktiviert. Für neu angelegte Projekte ist die Funktion automatisch aktiviert, damit auf die Möglichkeit von Markern an Validierungsregeln hingewiesen wird.

Parallel wurde eine andere, bisher nur wenig genutzte Funktion von Faktor-IPS mit dieser Erweiterung deaktiviert: In Validierungsregeln konnte bisher unter dem Reiter „Benutzung“ eingestellt werden, in welchen Geschäftsvorfällen die Regel zum Einsatz kommt. Diese Option ist – insbesondere in Kombination mit den neuen Markern – nicht sinnvoll. Sie wurde auch durch die unzureichende Dokumentation in der Vergangenheit kaum verwendet. Mit der Umstellung auf Faktor-IPS 3.15 wird sie daher standardmäßig deaktiviert. Wenn die Geschäftsvorfälle im Projekt benötigt werden, kann die Funktion in den AdditionalSettings der Projektkonfiguration (.ipsproject Datei) wieder aktiviert werden:
<Setting name="businessFunctionsForValidationRules" enabled="true"/>

Produktattribute mit abstrakten Aufzählungen als Datentyp

Abstrakte Aufzählungen (Enums) konnten bisher nur als Datentypen in Formeln verwendet werden. Unter bestimmten Voraussetzungen ist es nun auch möglich abstrakte Enums als Datentypen von Produktattributen zu verwenden. Da für abstrakte Enums keine Werte definiert sind, müssen solche Attribute zur Verwendung in Produktbausteinen konkretisiert werden. Abstrakte Enums dürfen daher nur in abstrakten Produktbausteinklassen verwendet werden. In einer konkreten Ableitung dieser Klasse muss das Attribut schließlich überschrieben werden und der Datentyp auf eine konkrete Ableitung des Aufzählungstyps abgeändert werden.

Im generierten Code wird für eine Attribut mit abstraktem Enum Datentyp nur eine abstrakte Getter-Methode generiert. Erst in der Ableitungsklasse werden die weiteren Elemente generiert.

Generierter Code und Runtime

CreateMessage Methode für Validierungsregeln

Mit dem Einführen der Marker für Validierungsregeln wurde der generierte Code zum Erzeugen der Message angepasst. Anstatt direkt den Konstruktor von Message mit immer mehr Parametern zu verwenden, wird jetzt der Message Builder eingesetzt. Damit ändert sich der generierte Code für alle createMessage... Methoden.

Änderung am Builder der Message Klasse

Bei der Verwendung des Message Buildsers kam es bei den Methoden zum setzen der betroffenen Eigenschaften (ObjectProperties) immer wieder zu Verwirrungen. Wir haben uns daher entschlossen die Methoden etwas umzugestalten. Leider war es dabei nicht möglich alle alten Methoden als deprecated markiert stehen zu lassen. Generierter Code wird automatisch angepasst und auf die neuen Methoden umgestellt. Wenn der Message Builder in manuell geschriebenen Code verwendet wurde, wird durch entsprechende Compilefehler auf die falsche Verwendung der Methoden hingewiesen. Weitere Informationen finden sich im JavaDoc des Builders.

Neues Interface ITimedConfigurableModelObject

Konfigurierte Vertragsteilklassen implementieren das Interface IConfigurableModelObject. Bisher verfügte der Produktbaustein hinter einer konfigurierten Vertragsteilklasse immer über Anpassungsstufen. Die Methode getProductCmptGeneration() in IConfigurableModelObject konnte dazu genutzt werden die konfigurierende Anpassungsstufe zu ermitteln.
Mit der Einführung von Produktbausteinen ohne Anpassungsstufen ändert sich diese Situation. Eine konfigurierte Vertragsteilklasse basiert in diesem Fall nicht mehr auf den Daten einer Anpassungsstufe. Die Methode getProductCmptGeneration() kann dann kein sinnvolles Ergebnis mehr liefern. Aus diesem Grund wurde ein neues Interface ITimedConfigurableModelObject eingeführt, welches von IConfigurableModelObject erbt und von allen konfigurierten Vertragsteilklassen implementiert wird, bei denen die konfigurierende Produktbausteinklasse über Anpassungsstufen verfügt.
Die Methode getProductCmptGeneration() wurde in IConfigurableModelObject deprecated. Wird die Methode an einem Objekt aufgerufen, welches kein ITimedConfigurableModelObject ist, so wird eine UnsupportedOperationException geworfen. Da es bisher noch keine Produktbausteine ohne Anpassungsstufen gibt, kann dieser Fall in bestehendem Code nicht auftreten. Beim Umstieg auf diese Faktor-IPS Version sollten dennoch alle Aufrufe angepasst werden, um Problemen in der Zukunft vorzubeugen.

Änderungen an IProductComponent

Wenn eine Produktbausteinklasse keine Anpassungsstufen unterstützt, werfen die Methoden getGenerationBase(Calendar) und getLatestProductComponentGeneration() eine UnsupportedOperationException. Über eine neue Methode isChangingOverTime() kann abgefragt werden, ob die aktuelle Produktbausteinklasse Anpassungsstufen unterstützt.

Weitere Änderungen bzgl. Produktbausteinklassen ohne Anpassungsstufen

Für Produktbausteinklassen ohne Anpassungsstufen wird der Code an einigen Stellen anders generiert: zum Beispiel wird keine Klasse für die Anpassungsstufe generiert. In Projekten muss diesbezüglich nichts berücksichtigt werden, da bisher noch keine Produktbausteinklassen ohne Anpassungsstufen existieren. Werden bei einer bereits existierenden Produktbausteinklasse Anpassungsstufen deaktiviert, so wird der Codegenerator die Klasse für die Anpassungsstufe nicht löschen. Stattdessen wird die Anpassungsstufenklasse als deprecated gekennzeichnet. Dies ermöglicht die Migration von manuell geschriebenem Code.
Das zuvor beschriebene Verhalten gilt ebenfalls für das Interface der Anspassungsstufe.

Änderung bei der Erzeugung von Vertragsinstanzen über die Produktbausteinklasse

Die Methode createVertragsteil() an Produktbausteinklassen hat bisher die initialize() Methode der neu erzeugten Vertragsinstanz nicht aufgerufen. Diese wurde bisher nur aufgerufen, wenn die Vertragsinstanz aus einer Anpassungsstufe erzeugt wurde. Dieser Fehler wurde behoben.

Abhängigkeiten der Runtime Bibliothek zu JUnit

Die Laufzeitbibliothek „faktorips-runtime“ beinhaltet auch die Ausführung der Faktor-IPS Testfälle. Dazu ist eine Abhängigkeit zu der JUnit Bibliothek notwendig. Im produktiven Betrieb werden allerdings keine Testfälle ausgeführt und diese Abhängigkeit ist daher störend.

Eine saubere Trennung in eine separate Runtime-Test Bibliothek war leider noch nicht möglich. Um die Runtime dennoch ohne die Abhängigkeit zu JUnit verwenden zu können, wurde die Abhängigkeit sowohl im OSGi Bundle als auch im Maven Artefakt als „Optional“ markiert. Wenn die Abhängigkeit zu JUnit in der Laufzeitkonfiguration nicht vorhanden ist, dann können keine Testfälle ausgeführt werden. Zum ausführen der Testfälle muss JUnit explizit als Abhängigkeit gesetzt werden – in üblichen Testsettings ist das bereits der Fall.

Migration

Beim Umstieg auf Faktor-IPS 3.15 muss eine automatisierte Migration durchgeführt werden. Diese Migration stellt sicher, dass bei allen existierenden Produktbausteinklassen die Einstellung „Produktbausteine haben Anpassungsstufen“ aktiv gesetzt wird, so dass diese der bisherigen Semantik entsprechen. Desweiteren werden alle weiter oben erwähnten AdditionalSettings in die .ipsproject Dateien geschrieben. Zusätzlich führt die Migration Aufräumarbeiten im XML aller Faktor-IPS Objekte durch falls notwendig.

Faktor-IPS Plug-In API

Der folgende Abschnitt ist vor allem für die Entwicklung von eigene Erweiterungen für Faktor-IPS interessant. Darin werden wichtige Änderungen der Plug-In API beschrieben.

Umgang mit Produktbausteinklassen ohne Anpassungsstufen

Für Produktbausteinklassen ohne Anpassungsstufen werden auf Meta-Modell-Ebene keinerlei Funktionen entfernt. In sämtlichem Code – sowohl in Faktor-IPS selbst, als auch in umliegenden Plug-ins – wurde bisher die feste Annahme getroffen, dass es immer mindestens eine Anpassungsstufe gibt. Damit dieser Code auch weiterhin funktioniert werden alle bis auf eine Anpassungsstufen aus den Produktbausteinen entfernt und es wird bei der Neuanlage von Produktbausteinen eine Dummy-Anpassungsstufe erzeugt.
Allerdings sind diese Anpassungsstufen leer, wenn die Produktbausteinklasse keine Anpassungsstufen unterstützt.

Das Leeren oder Befüllen der Anpassungsstufen nach einer Veränderung der Einstellung „Produktbausteine haben Anpassungsstufen“ erfolgt bei der Aktion „Unterschiede beheben“.

Release Notes – Faktor-IPS – Version 3.15.0

Bugs

  • newAddDelta ohne Children (FIPS-2479)
  • Leerstring lässt sich nicht als erster Wert einer Wertemenge speichern (FIPS-4102)
  • getLinkFor… führt zu NullPointerException bei nicht gefüllter 0..1-Beziehung (FIPS-4127)
  • Container im IpsObjectPath funktioniert nur an letzter Stelle (FIPS-4201)
  • createMessage* Methoden werden falsch generiert. (FIPS-4226)
  • Leerstring als erster Wert bei MultiValue Attributen (FIPS-4234)

Improvements

  • Rename-Refactoring von ValidationRules (FIPS-834)
  • Jump To Sourcecode Menü optimieren (FIPS-1104)
  • Letzte Suchen in der Produktbaustein-Suche anzeigen (FIPS-1431)
  • ReadonlyTableOfContents sollte auch getEnumContentTocEntries() haben (FIPS-3980)
  • null in Ranges sollte im Bausteineditor direkt angezeigt werden (FIPS-4010)
  • Abstrakte Enums als Datentypen an Produktattributen erlauben (FIPS-4125)
  • Trim auf Strings bei CSV-Import (FIPS-4167)
  • ModelObjectDelta ohne IDeltaComputationOptions (FIPS-4224)
  • API Message Builder verbessern (FIPS-4242)

New Features

  • Produktbausteine ohne Anpassungsstufen (FIPS-3571)
  • Definition von Markern an ValidationRules (FIPS-3572)
  • Erweitern der IDeltaComputationOptions zur Definition eigener equals Implementierungen (FIPS-3921)
  • Import von Validierungsnachrichten aus einem Excel-File (FIPS-3966)

Tasks

  • Entfernen des Suffix ‚java5‘ aus der Runtime Bibliothek (FIPS-3792)