If true, the class maintains an attribute controlling which notifications are sent.

Applies to

▸ Model level: ☑ logical model ∙ ☑ technical model

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

If true, invocations entering the business logic need an application specific current thread class loader. In this case, the VUI sets this class loader before invoking business logic methods.

Applies to

▸ Model level: ☑ logical model ∙ ☑ technical model

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

If true, the class maintains an attribute controlling whether runtimestep levels are used.

Applies to

▸ Model level: ☑ logical model ∙ ☑ technical model

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

If true, the class will be instrumented with stop watches.

Applies to

▸ Model level: ☑ logical model ∙ ☑ technical model

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

If true, the class maintains and holds a location context.

Applies to

▸ Model level: ☑ logical model ∙ ☑ technical model

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

If provided, specifies how to create or retrieve a base LocationContext. The local LocationContext then is built based upon that one.

Applies to

▸ Model level: ☑ logical model ∙ ☑ technical model

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

If true, the class is derived from a class that maintains and holds a location context and maintains it, too, but does not hold it.

Technically, this implies that at entry of all relevant methods the current call context is merged with the location context of instances of this class.

Applies to

▸ Model level: ☑ logical model ∙ ☑ technical model

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

If true, the class can be dumped (see Dumpable).

Applies to

▸ Model level: ☑ logical model ∙ ☑ technical model

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

If true, the class provides a method to return a unique, textual instance identifier, which is created from the class name (see also XMTechnical/InstanceIdentifierClass) and the string values of all identifier attributes.

Applies to

▸ Model level: ☑ logical model ∙ ☐ technical model

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

If provided, this String is used as the class name in the XMTechnical/InstanceIdentifier. If not provided, the fully qualified class name, including the package path, is used.

Applies to

▸ Model level: ☑ logical model ∙ ☐ technical model

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

If true, the class can be serialized to an OCP (see OCPSerialisable).

Applies to

▸ Model level: ☑ logical model ∙ ☑ technical model

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

If true, the feature is only serialized to an OCP (see OCPSerialisable) if the respective condition evaluates to 'true'.

Applies to

▸ Model level: ☑ logical model ∙ ☑ technical model

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

If true, the respective model attribute is serialised as a reference to an already existing instance via an OCP RETRIEVER, instead of construction data to be used for creating a new instance via an OCP CLASS or an OCP FACTORY.

Applies to

▸ Model level: ☑ logical model ∙ ☑ technical model

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

Evaluates to the class name of a retriever which can be used as a RETRIEVER tag attribute inside the OCP. Retrievers are used if respective attributes shall be serialised as references instead of contruction data.

Applies to

▸ Model level: ☑ logical model ∙ ☑ technical model

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

Evaluates to the class name of a factory which can be used as a FACTORY tag attribute inside the OCP. Factories are used if respective attributes shall be serialised by construction data instead of references.

In contrast to retrievers, factories are optional, since classes can also be constructed with help of the constructor of the implementation class.

Applies to

▸ Model level: ☑ logical model ∙ ☑ technical model

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

If true, the respective model attribute is used as an OCP construction attribute, in case of contruction via an OCP CLASS or an OCP FACTORY.

Applies to

▸ Model level: ☑ logical model ∙ ☑ technical model

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

If true, the respective model attribute is used as an OCP retriever attribute, in case of referencing via an OCP RETRIEVER.

Applies to

▸ Model level: ☑ logical model ∙ ☑ technical model

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

In case of serialisation via an OCP CLASS or OCP FACTORY, this property provdides an alternative class or factory attribute name, instead of the default model attribute name itself.

Applies to

▸ Model level: ☑ logical model ∙ ☑ technical model

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

In case of serialisation via an OCP RETRIEVER, this property provdides an alternative retriever attribute name, instead of the default model attribute name itself.

Applies to

▸ Model level: ☑ logical model ∙ ☑ technical model

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

If true, the respective model attribute of type String is serialised as an indented CDATA text block.

Applies to

▸ Model level: ☑ logical model ∙ ☑ technical model

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

If true, on class level, the class supports serialisation as JSON (see JSONSerialisable).

Applies to

▸ Model level: ☑ logical model ∙ ☑ technical model

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

If provided, this feature is serialised if the requested serialisation format (OCP, JSON etc.) matches the given pattern. If not provided, it is not excluded in general, but further restrictions may apply, see e.g. XMTechnical/SerialisationRules.

Applies to

▸ Model level: ☑ logical model ∙ ☑ technical model

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

If provided, this feature is serialised if the requested serialisation format (OCP, JSON etc.) does not match the given pattern. If not provided, it is not excluded in general, but further restrictions may apply, see e.g. XMTechnical/SerialisationRules.

Applies to

▸ Model level: ☑ logical model ∙ ☑ technical model

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

In case rules are provided, these are evaluated against the current serialisation state and serialistation continues according to the respective new state settings.

If provided on class level, these rules are evaluated once at the beginning of a serialisation pass of an instance. If they are provided on feature level, they are evaluated for that specific feature.

See also XMTechnical/SerialisationRulesForEachFeature and

Applies to

▸ Model level: ☑ logical model ∙ ☑ technical model

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

In case rules are provided, these are evaluated against the current serialisation state and serialistation continues according to the respective new state settings.

These rules are provided on class level, but are evaluated seperately for each single feature.

See also XMTechnical/SerialisationRules and

Applies to

▸ Model level: ☑ logical model ∙ ☑ technical model

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

If provided, these defaults are used to decide whether features are included in serialisation. The array provides, in this order, defaults for attribute inclusion, attribute exclusion, owning association end inclusion, owning association end exclusion, non owning association end inclusion, non owning association end exclusion.

Can be provided on class level and on feature level, feature level defaults take precedence over class level defaults.

Applies to

▸ Model level: ☑ logical model ∙ ☑ technical model

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

Optionally, an expression that is used to convert a value before it is serialised.

The expression is expected to be a (JavaCode) Template, which is provided with a parameter 'value' when evaluated, which refers to the value to be serialised, and which evaluates the converted result.

Applies to

▸ Model level: ☑ logical model ∙ ☐ technical model

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

If true, a createAnchor method is generated according to the Anchorable) interface. The method creates an Anchor implemented by an AnchorInterceptor and a Proxy.

Applies to

▸ Model level: ☑ logical model ∙ ☑ technical model

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

A list of (Package)Initialisers which will be statically initialised by this class.

Applies to

▸ Model level: ☑ logical model ∙ ☑ technical model

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

If true, the generated class gets an application domain identifier (see ADObjectId).

Applies to

▸ Model level: ☑ logical model ∙ ☑ technical model

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

If true, the generated class provides application domain versioning information (see ADObjectVersion).

Applies to

▸ Model level: ☑ logical model ∙ ☑ technical model

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

An additional prefix, that is used to augment the main classname and all constructors, but not where the class is referenced (e.g. in factories).

It is intended to substitute instances of this class with instances of a class derived from in general. This can be an "emergency measurement" to overrule generated behaviour.

Applies to

▸ Model level: ☑ logical model ∙ ☑ technical model

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

An expression that retrieves a StringPool. StringPools are used as resource pools for texts which are identified by a text id.

If no string pool is specified, strings are retrieved from the StringContext by id, which provides a contextual StringPool (typically the current application string pool).

Applies to

▸ Model level: ☑ logical model ∙ ☑ technical model

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

If true, texts from the model will not be written into Java source code, but collectively into some string pool. This pool may serve as a centralised source for translation of texts into additional human languages and might be easier readable and accessible then texts distributed over the model.

Applies to

▸ Model level: ☑ logical model ∙ ☑ technical model

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