Bis zur Version 2.3. konnten für ein Attribut einer Vertragsklasse drei Arten von Wertebereichen im Modell definiert werden. Die folgende Tabelle beschreibt diese Modellierungsarten und die dazugehörigen Konfigurationsmöglichkeit in Produktbausteinen.

Wertebereiche im Modell für ein Attribut	Konfigurationsmöglichkeiten im Produkt
Bereich (Range). Beispiel: 0 – 10.000	Teilbereich sowie Defaultwert. Beispiel: 0 - 5.000; Default=0
Aufzählung (Enumeration). Beispiel: 0, 150, 300	Eine Teilmenge der aufgezählten Werte sowie Defaultwert. Beispiel: 0, 300; Default=0
Alle Werte (All Values)	Keine Einschränkung der Wertemenge möglich. Lediglich der Defaultwert kann definiert werden.

Wollte man also in Produktbausteinen den Wertebereich eines Attributes konfigurieren können, so musste man bereits im Modell sowohl die Art des Wertebereichs festlegen als auch die konkrete Obermenge der erlaubten Werte. Während man für Bereiche einfach einen unbeschränkten Bereich durch die Angabe von Min=Max=<null> definieren konnte, war dies für Aufzählungen nicht möglich. Das bedeutete, dass zum Beispiel bei der Verwendung „neuer“ Werte in einer neuen Produktgeneration das Modell entsprechend erweitert werden musste. Darüber hinaus war es nicht möglich erst im Produktbaustein über die Art der Wertemenge zu entscheiden. Es musste immer im Modell entschieden werden, ob es sich um eine Aufzählung oder um einen Bereich handelt.

Diese Einschränkungen existieren mit der Version 2.4. nicht mehr. Bei Aufzählungen und Bereichen kann nun im Modell markiert werden, ob im Modell die Obermenge der erlaubten Werte definiert ist, oder ob nur der Typ der Wertemenge festgelegt ist. Die folgenden zwei Abbildungen zeigen die beiden Varianten für Aufzählungen. Die erste Abbildung zeigt dabei die Verwendung einer Obermenge der Werte wie es auch schon in den vorherigen Versionen von Faktor-IPS möglich war.

Durch Entfernen des Hakens an der Checkbox „Specify Bounds/Values“ kann man nun ab Version 2.4 spezifizieren, dass im Modell nur der Typ der Wertemenge (in diesem Fall also Enumeration) festgelegt wird und die konkreten Werte ausschließlich im Produktbaustein.

Der Wertemengentyp AllValues wurde in Version 2.4 umbenannt in Unrestricted. Wählt man diesen Typ, so ist die Checkbox „Specify Bounds/Values“ disabled, da im Modell natürlich keine konkreten Werte hinterlegt werden können. Dies zeigt die folgende Abbildung.

Auswirkungen auf den Produktbaustein-Editor
Der Wertebereich kann im Baustein-Editor gemäß den Einstellungen im Modell definiert werden. Die Bedienung erfolgt im wesentlichen wie bisher, ist aber bei den entsprechenden Einstellungen im Modell flexibler. Zur Eingabe des Defaultwertes bei Attributen mit einem EnumType als Datentyp wird zur Zeit immer eine Combobox verwendet, die alle Werte des EnumTypes enthält. Es werden nicht nur die Werte des im Baustein definierten Wertebereichs angezeigt.

Auswirkungen auf den generierten Code
Bzgl. des generierten Codes ändert sich ausschließlich etwas bei dem Wertemengentyp Unrestricted. Bisher wurde für Attribute, für die die Wertemenge nicht eingeschränkt war, kein Code für den Zugriff auf den Wertebereich generiert. Wird im Attribut nun markiert, dass die Wertemenge im Modell den Typ Unrestricted hat, die Wertemenge aber im Produktbaustein eingeschränkt wird, so wird in der Klasse, die produtkseitig die Anpassungsstufe repräsentiert, eine Methode zum Zugriff auf den Wertebereich definiert. Für ein Attribut Selbstbehalt mit Datentyp Money sieht die Methodensignatur wie folgt aus:

public ValueSet<Money> getSetOfAllowedValuesForSelbstbehalt(IValidationContext context);

Die Instanz, die von dieser Methode zurückgegeben wird, ist entweder vom Typ Range<Money> oder vom Typ OrderedValueSet<Money> oder vom Typ UnrestrictedValueSet<Money>, je nachdem was im konkreten Produktbaustein konfiguriert ist. Die generierte Vertragsteilklasse erhält eine Methode mit der gleiche Signatur. Die Implementierung der Methode delegiert an die Produktklasse.

Für Aufzählungstypen, die auch die konkreten Werte enthalten, werden Java Enums generiert (Java 5 vorausgesetzt). Für jeden Wert wird dabei ein eigenes Literal generiert. In Faktor-IPS 2.3 wurde eine Attribut markiert, dessen konkrete Werte als Namen für diese Literale verwendet werden. So konnte man z. B. definieren, dass das Attribut „bezeichnung“ als Literalname im generierten Code verwendet werden soll. Das hatte zur Folge, dass für die konkreten Bezeichnungen die Java-Restriktion für Literalnamen galten. In der Praxis stellte sich das unpraktisch heraus, insbesondere bei der Verwendung von gemeinsamen Basistypen für Aufzählungstypen, die die Werte enthalten, und für solche, die die Werte nicht enthalten. Aus diesem Grund wurde in Faktor-IPS 2.4 bei Aufzählungstypen mit konkreten Werten ein dediziertes Attribut für die Literalnamen eingeführt. Der Defaultname dieses Attributs ist LITERAL_NAME. Es wird automatisch für Aufzählungstypen mit konkreten Werten erzeugt. In dem LITERAL_NAME-Attribut kann ein anderes Attribut angegeben werden, welches zur Vorbelegung des Literalnamen verwendet wird. Hier kann man nun also zum Beispiel das Attribut „Bezeichnung“ hinterlegen.

Sobald man nun in der Tabelle zur Eingabe der Werte die Spalte Bezeichnung verlässt, wird die Spalte LITERAL_NAME vorbelegt. Dies geschieht durch Umwandlung des Inhaltes der Spalte Bezeichnung in Großbuchstaben und Ersetzung von Sonderzeichen durch Unterstriche. Über den Togglebutton mit dem Vorhängeschloss kann man steuern, ob die LITERAL_NAME Spalte editierbar ist, oder nicht. Darüber hinaus kann man über das Kontextmenü die gesamte LITERAL_NAME Spalte auf Basis der Spalte Bezeichnung neu füllen.

Tabelleninhalte und Aufzählungsinhalte können nun auch im CSV Format exportiert und importiert werden. Beim Import von CSV-Dateien werden die zu importierenden Daten im Wizard in einer Vorschau angezeigt.

Bestehende Projekte können über die Migrationsfunktion von Faktor-IPS auf die Version 2.4. umgestellt werden. Die Migration wird im Package-Explorer über das Kontextmenü gestartet.
Im Codegenerator gibt es eine inkompatible Änderungen. Für die maximale Kardinalität (Multiplicity) einer Beziehung wurde bisher folgendes generiert.

/**
 * Maximum cardinality for association Coverage.
 *
 * @generated
 */
public static final IntegerRange MAX_CARDINALITY_FOR_COVERAGE = new IntegerRange(1, 1);

Der Begriff Kardinalität wird nun in Übereinstimmung mit der UML als MULTIPLICITY bezeichnet. Darüber hinaus handelt es sich genau genommenm nicht um die Multiplizität der Assoziation, sondern um die Multiplizität der Rolle. Mit der aktuellen Version wird nun also folgendes generiert.

/**
 * The maximal multiplicity of the association with the role name Coverage.
 * 
 * @generated
 */
public static final IntegerRange MAX_MULTIPLICITY_OF_COVERAGE = new IntegerRange(1, 1);