If true, on class level, state is not maintained at all. If true, on feature level, the respective attribute or association is not persistent.

Applies to

▸ Model level: ☑ logical model ∙ ☐ technical model

▸ Model elements: ☐ packages ∙ ☑ classes ∙ ☑ attributes ∙ ☐ operations ∙ ☐ association ends ∙ ☐ states

If true, on feature level, the respective attribute or association serves as a primary key (component) of this class, i.e. specifically an ORM will use this attribute instead of generating an artificial internal ID attribute. Note that there is a related property in XMLogic.

Applies to

▸ Model level: ☑ logical model ∙ ☑ technical model

▸ Model elements: ☐ packages ∙ ☐ classes ∙ ☑ attributes ∙ ☐ operations ∙ ☑ association ends ∙ ☐ states

A list of filters, which filter, depending on aspects defined in the current context, the persistent data that is visible.

Applies to

▸ Model level: ☑ logical model ∙ ☐ technical model

▸ Model elements: ☐ packages ∙ ☑ classes ∙ ☐ attributes ∙ ☐ operations ∙ ☐ association ends ∙ ☐ states

If true, the interaction layer (IL) classes (i.e. factories, editors, etc.) will implement hooks to inform the state layer of relevant state events.

Applies to

▸ Model level: ☑ logical model ∙ ☐ technical model

▸ Model elements: ☐ packages ∙ ☑ classes ∙ ☐ attributes ∙ ☐ operations ∙ ☐ association ends ∙ ☐ states

The result of this expression is assigned to persistent members if they are accessed by their getter and have a null value assigned.

Applies to

▸ Model level: ☑ logical model ∙ ☑ technical model

▸ Model elements: ☐ packages ∙ ☐ classes ∙ ☑ attributes ∙ ☐ operations ∙ ☑ association ends ∙ ☐ states

Code, that is inserted in automatically generated state set methods before the actual value is returned.

Applies to

▸ Model level: ☑ logical model ∙ ☑ technical model

▸ Model elements: ☐ packages ∙ ☐ classes ∙ ☑ attributes ∙ ☐ operations ∙ ☑ association ends ∙ ☐ states

Code, that is inserted in automatically generated state set methods before the actual assignment takes place.

Applies to

▸ Model level: ☑ logical model ∙ ☑ technical model

▸ Model elements: ☐ packages ∙ ☐ classes ∙ ☑ attributes ∙ ☐ operations ∙ ☑ association ends ∙ ☐ states

Code, that is inserted in automatically generated state set methods after the actual assignment took place.

Applies to

▸ Model level: ☑ logical model ∙ ☑ technical model

▸ Model elements: ☐ packages ∙ ☐ classes ∙ ☑ attributes ∙ ☐ operations ∙ ☑ association ends ∙ ☐ states

Type of a persistent attribute used to store the corresponding ADO attribute. This persistent attribute is either an additional, hidden attribute in the ADO instance or it is used solely in the TSM layer state class.

Applies to

▸ Model level: ☑ logical model ∙ ☑ technical model

▸ Model elements: ☐ packages ∙ ☐ classes ∙ ☑ attributes ∙ ☐ operations ∙ ☑ association ends ∙ ☐ states

In case of a to-many association, the type of persistent elements this association does point to. This corresponds to the element type of the collection that is used to implement the persistent association.

In case of a normal attribute or a to-one association, it corresponds to XMState/PersistentType.

Applies to

▸ Model level: ☑ logical model ∙ ☑ technical model

▸ Model elements: ☐ packages ∙ ☐ classes ∙ ☑ attributes ∙ ☐ operations ∙ ☑ association ends ∙ ☐ states

An expression, that creates an ADO attribute instance based on a given persistent attribute instance, see "PersistentType". See also "PersistentTypeMapper" and "PersistentTypeReverseMapper".

Applies to

▸ Model level: ☑ logical model ∙ ☑ technical model

▸ Model elements: ☐ packages ∙ ☐ classes ∙ ☑ attributes ∙ ☐ operations ∙ ☑ association ends ∙ ☐ states

An expression, that extracts (or creates) an persistent attribute instance from a given ADO attribute instance, see "PersistentType".

Applies to

▸ Model level: ☑ logical model ∙ ☑ technical model

▸ Model elements: ☐ packages ∙ ☐ classes ∙ ☑ attributes ∙ ☐ operations ∙ ☑ association ends ∙ ☐ states

If true, next to the mapped persistant instance of an attribute it's application domain type instance is kept in the state adapter, too. Reasons might be caching or alternate conversion procedures, e.g. loading into existing instead of creating new values.

Applies to

▸ Model level: ☑ logical model ∙ ☑ technical model

▸ Model elements: ☐ packages ∙ ☐ classes ∙ ☑ attributes ∙ ☐ operations ∙ ☑ association ends ∙ ☐ states

The result of this expression is assigned to application domain type instance members if they are accessed by their getter and have a null value assigned.

Applies to

▸ Model level: ☑ logical model ∙ ☑ technical model

▸ Model elements: ☐ packages ∙ ☐ classes ∙ ☑ attributes ∙ ☐ operations ∙ ☑ association ends ∙ ☐ states

Default name of the associated database. This could be overridden, depending on the installation, and by different mechanisms.

Applies to

▸ Model level: ☑ logical model ∙ ☐ technical model

▸ Model elements: ☐ packages ∙ ☑ classes ∙ ☐ attributes ∙ ☐ operations ∙ ☐ association ends ∙ ☐ states

Name of the associated database table. Defaults to class name in uppercase/underscore notation with the prefix "T_".

Applies to

▸ Model level: ☑ logical model ∙ ☐ technical model

▸ Model elements: ☐ packages ∙ ☑ classes ∙ ☐ attributes ∙ ☐ operations ∙ ☐ association ends ∙ ☐ states

If defined, all tables in the respective package will be prefixed with this name.

Applies to

▸ Model level: ☑ logical model ∙ ☐ technical model

▸ Model elements: ☑ packages ∙ ☐ classes ∙ ☐ attributes ∙ ☐ operations ∙ ☐ association ends ∙ ☐ states

If used on classes, the version identifier of the associated database table. Defaults to empty.

If used on packages, it applies to all classes contained in this package.

If used on attributes or associations in the technical model, the version identifier of the associated database table of the attribute type or of the type at the other end of an association. Used to ensure consistency when migrating database schemas.

Applies to

▸ Model level: ☑ logical model ∙ ☑ technical model

▸ Model elements: ☑ packages ∙ ☑ classes ∙ ☐ attributes ∙ ☐ operations ∙ ☐ association ends ∙ ☐ states

If true, during generation of JPA mappings a crosscheck is performed whether a previous mapping for the given table version was already created and whether any referenced tables (according to model associations) have the same versions. If not, an error is reported, explaining that the table version at hand needs to be incremented as well.

Applies to

▸ Model level: ☑ logical model ∙ ☐ technical model

▸ Model elements: ☐ packages ∙ ☑ classes ∙ ☐ attributes ∙ ☐ operations ∙ ☐ association ends ∙ ☐ states

Name of the class to be used as a discriminator in associated database tables. Used in inheritance relationships in the base table to identify the specific derived class. Defaults to the interface name plus possibly an implementation postfix. To save storage space, the use of very short abbreviations can be considered. In that case, typically the size of the corresponding column in relational tables ha to be shorteded, too (e.g. default in JPA/eclipselink is varchar(31)).

Applies to

▸ Model level: ☑ logical model ∙ ☑ technical model

▸ Model elements: ☐ packages ∙ ☑ classes ∙ ☐ attributes ∙ ☐ operations ∙ ☐ association ends ∙ ☐ states

Name of the column in the associated database table. Defaults to attribute name in uppercase/underscore notation.

Applies to

▸ Model level: ☑ logical model ∙ ☐ technical model

▸ Model elements: ☐ packages ∙ ☐ classes ∙ ☑ attributes ∙ ☐ operations ∙ ☐ association ends ∙ ☐ states

Size of a column field in the associated database table.

Applies to

▸ Model level: ☑ logical model ∙ ☐ technical model

▸ Model elements: ☐ packages ∙ ☐ classes ∙ ☑ attributes ∙ ☐ operations ∙ ☐ association ends ∙ ☐ states

Deprecated: please use the more comprehensive solution with Stereotype Unique and and property XMUnique/Groups.

Optionally specifies the name of a group of attributes which have to be unique in conjunction. In other words, all attributes with the same UniquenessGroup name belong to such a group, whose value combinations are restricted by a uniqueness constraint.

Applies to

▸ Model level: ☑ logical model ∙ ☐ technical model

▸ Model elements: ☐ packages ∙ ☐ classes ∙ ☑ attributes ∙ ☐ operations ∙ ☐ association ends ∙ ☐ states

Name of an aggregate to load on demand, which defines instance values for the respective class.

Applies to

▸ Model level: ☑ logical model ∙ ☐ technical model

▸ Model elements: ☐ packages ∙ ☑ classes ∙ ☐ attributes ∙ ☐ operations ∙ ☐ association ends ∙ ☐ states

Name of a script to run on demand, which is intended to setup instances of the respective class.

Applies to

▸ Model level: ☑ logical model ∙ ☐ technical model

▸ Model elements: ☐ packages ∙ ☑ classes ∙ ☐ attributes ∙ ☐ operations ∙ ☐ association ends ∙ ☐ states

Apart from being initialised, the values of this class are not modified, i.e. the respective AllSet is constant. This is typically used with enumerations. Specifically, an underlying database is not required to load these values more than once and keep the respective query result in memory.

Applies to

▸ Model level: ☑ logical model ∙ ☐ technical model

▸ Model elements: ☐ packages ∙ ☑ classes ∙ ☐ attributes ∙ ☐ operations ∙ ☐ association ends ∙ ☐ states

Controls cascading behaviour, i.e. whether the ORM/DBMS shall propagate deletes or refreshes to contained subobjects.

Applies to

▸ Model level: ☑ logical model ∙ ☑ technical model

▸ Model elements: ☐ packages ∙ ☐ classes ∙ ☑ attributes ∙ ☐ operations ∙ ☑ association ends ∙ ☐ states

Database index definition

Applies to

▸ Model level: ☑ logical model ∙ ☑ technical model

▸ Model elements: ☐ packages ∙ ☑ classes ∙ ☑ attributes ∙ ☐ operations ∙ ☐ association ends ∙ ☐ states

A list of changes of the respective feature or element, ordered by occurence, from first change to latest change. For each change, the respective table version is given.

The list is used to automatically create migration scripts which can be used to move data from an existing database to a database with a new version and a respective modified schema.

Applies to

▸ Model level: ☑ logical model ∙ ☐ technical model

▸ Model elements: ☑ packages ∙ ☑ classes ∙ ☑ attributes ∙ ☑ operations ∙ ☑ association ends ∙ ☑ states

A list of BLC events when this feature will be automatically read into the current TSM transaction scope.

Applies to

▸ Model level: ☑ logical model ∙ ☐ technical model

▸ Model elements: ☐ packages ∙ ☐ classes ∙ ☑ attributes ∙ ☐ operations ∙ ☑ association ends ∙ ☐ states

Indicates whether, and if so, how, the data of the respective model element is prepared to be versioned at runtime.

This property must be specified only once at respective base classes, it must not be repeated at derived classes.

Applies to

▸ Model level: ☑ logical model ∙ ☐ technical model

▸ Model elements: ☐ packages ∙ ☑ classes ∙ ☑ attributes ∙ ☐ operations ∙ ☑ association ends ∙ ☐ states

Indicates whether, and if so, derived classes of this class are also automatically prepared to be versioned at runtime, and inherit the scheme defined by XMState/Versioning, which must be defined by some base class.

Note: for versioning to function correctly, all involved classes of a versioning aggregate need to be prepared for versioning, including all involved base and derived classes.

Applies to

▸ Model level: ☑ logical model ∙ ☐ technical model

▸ Model elements: ☐ packages ∙ ☑ classes ∙ ☑ attributes ∙ ☐ operations ∙ ☑ association ends ∙ ☐ states

Indicates versioning realms within which instances are connected via this relation and thereby form a versionised aggregate. Specifically, revision control operations like branch setup, commit and revert follow this association, if they are executed within one of the listed realms.

Note, that for most applications there will be only one realm.

Note, that by restricting revision control operations to marked associations, it is possible to versionise limited aggreates within the database separately, practically enabling multiple "repositories" within one database. This is in contrast to other approaches which always versionise the full database as a whole.

Applies to

▸ Model level: ☑ logical model ∙ ☐ technical model

▸ Model elements: ☐ packages ∙ ☐ classes ∙ ☐ attributes ∙ ☐ operations ∙ ☑ association ends ∙ ☐ states

If provided, the annotated class serves as a root for a versioning aggregate. Specifically, for such classes special UI transactions and toolkits will be provided to enable revision control on them in respective user interface parts.

The provided string defines the realm name of this aggregate. It is matched against XMState/VersioningRealms on associations, so that these are followed only for the same realm. Usually, there is only one realm in an application, but advanced use cases may require more than one.

This can be further dynamically limited via XMState/VersioningRootConstraint.

Applies to

▸ Model level: ☑ logical model ∙ ☐ technical model

▸ Model elements: ☐ packages ∙ ☑ classes ∙ ☑ attributes ∙ ☐ operations ∙ ☑ association ends ∙ ☐ states

In addition to XMState/VersioningRoot this is a condition that must be fulfilled for this instance to become a versioning repository root. E.g., while XMState/VersioningRoot might provide a strucural constraint that only Packages in general can become roots, this dynamic property here can limit this further to Packages which are at the root of the package hierarchy, i.e. which have no parent.

Applies to

▸ Model level: ☑ logical model ∙ ☐ technical model

▸ Model elements: ☐ packages ∙ ☑ classes ∙ ☑ attributes ∙ ☐ operations ∙ ☑ association ends ∙ ☐ states

If true, this is the additional implementation class that is used to store all revisions of a given instance.

Applies to

▸ Model level: ☐ logical model ∙ ☑ technical model

▸ Model elements: ☐ packages ∙ ☑ classes ∙ ☐ attributes ∙ ☐ operations ∙ ☐ association ends ∙ ☐ states

Indicates an aggregate realm to which this class and it's instances belong. Realms indicate that the contained items belong logically together, typically they are used, stored, loaded, imported and exported as a bundle, while items outside the realm might just be referenced in some way.

This concept is related to DDD's 'Bounded Contexts'.

Applies to

▸ Model level: ☑ logical model ∙ ☐ technical model

▸ Model elements: ☐ packages ∙ ☑ classes ∙ ☐ attributes ∙ ☐ operations ∙ ☐ association ends ∙ ☐ states