A small string describing the ADO instance briefly, typically based on it's attributes. These strings are typically used in technical contexts, in the user interface there are additional preview strings, see XMPresentation/Preview.

See also property 'DefaultToString'.

Applies to

▸ Model level: ☑ logical model ∙ ☑ technical model

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

An alternate format string used in conjunction with the automatically generated default ToString. Normally, the format string describes a comma separated list. With this format string, different formats than comma separated are possible. The advantage of using this property in contrast to XMLogicImplementation/ToString, is, that still the runtime attributes of the XMText are automatically generated, so this is easier to specify.

Applies to

▸ Model level: ☑ logical model ∙ ☐ technical model

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

If no ToString is declared and this property is set to true, a default string is generated which consists of a comma seperated list of all identifier attributes of this instance, i.e. all attributes with a PresentationImportance of "Identifier". This can be overridden by explicitly specifying a

Applies to

▸ Model level: ☑ logical model ∙ ☐ technical model

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

Additional constructors (besides the default constructor) with different sets of additional arguments.

Applies to

▸ Model level: ☑ logical model ∙ ☑ technical model

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

Code, that is inserted directly into the generated class implementation.

Applies to

▸ Model level: ☑ logical model ∙ ☑ technical model

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

Code, that is inserted directly into the generated class implementation, but is specified at attributes, operations or association ends

Applies to

▸ Model level: ☑ logical model ∙ ☑ technical model

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

Like XMLogicImplementation/ClassBody, but only inserted once per name, to prevent duplicates in case this same property is applied multiply via multiple features, usually via a common stereotype.

Applies to

▸ Model level: ☑ logical model ∙ ☑ technical model

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

Code, that is inserted in the on-create-initialiser, after assignment of initial values to attributes.

Applies to

▸ Model level: ☑ logical model ∙ ☑ technical model

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

Code, that is inserted in the on-load-initialiser, after optional assignment of initial values to attributes.

Applies to

▸ Model level: ☑ logical model ∙ ☑ technical model

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

If true, any initialisation attempt of a null value is ignored. This is used in conjunction with bidirectional associations and the factorysite in certain circumstances.

Explanation: in OCPs cyclic references must be handled. To do so, the precreate mechanism of factories is used. In that case, a non-initialised pointer is revealed. In the case of bidirectional associations the adding of these non-initialised instance triggers the bidrectional maintenance in the container, so that the respective attribute of the non-initialised instance is set. Afterwards, when final initialisation of that instance takes place, a setting of a default value of null would cancel the just-created bidrecional relation.

Applies to

▸ Model level: ☐ logical model ∙ ☑ technical model

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

If true, an initialisation attempt is ignored if the corresponding instance attribute is already assigned a value. This is used in cases where the instance attribute can be optionally calculated, but as well by default being set from the factory. This setting then protects against overriding by the factory in case the calculation already took place.

Applies to

▸ Model level: ☐ logical model ∙ ☑ technical model

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

Code, that is inserted in the destroy-method, which is invoked by the finalizer (at least then, if enabled).

Applies to

▸ Model level: ☑ logical model ∙ ☑ technical model

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

Code, that is inserted in the validate-method.

Applies to

▸ Model level: ☑ logical model ∙ ☑ technical model

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

If true, validation is only performed once until the respective attribute is modified via it's set method.

Applies to

▸ Model level: ☑ logical model ∙ ☑ technical model

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

If true, validation is performed on the raw member as it is stored in the instance, i.e. without pre- and post-processing code applied.

Applies to

▸ Model level: ☑ logical model ∙ ☑ technical model

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

Code, that is used to delete an instance. If not specified, the delete call is delegated to the TSM layer, which normally removes the instance from the database. Instead, one might e.g. want to set a delete flag and keep the records for historical reasons.

Applies to

▸ Model level: ☑ logical model ∙ ☑ technical model

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

Code, that is in any case inserted before the respective class deletion code, i.e. independent of the Deletion property.

Applies to

▸ Model level: ☑ logical model ∙ ☑ technical model

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

Code, that is in any case inserted after the respective class deletion code, i.e. independent of the Deletion property.

Applies to

▸ Model level: ☑ logical model ∙ ☑ technical model

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

Code, that is inserted before the respective class deletion code (depending on the Deletion property), but is specified at attributes or association ends.

Applies to

▸ Model level: ☑ logical model ∙ ☑ technical model

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

Code, that is inserted after the respective class deletion code (depending on the Deletion property), but is specified at attributes or association ends.

Applies to

▸ Model level: ☑ logical model ∙ ☑ technical model

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

Code, that is used to declare a member for this attribute. If omitted, a standard declaration is generated based on the attribute type and name.

Applies to

▸ Model level: ☐ logical model ∙ ☑ technical model

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

Code, that is used in automatically generated get methods to retrieve the actual value. If omitted, a default piece of code is generated, simply using the respective member variable.

If provided, this code must define a variable named "result" and assign it the value to return. It must not return this variable by itself, since postprocessing code might be applied.

Applies to

▸ Model level: ☑ logical model ∙ ☑ technical model

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

Code, that is inserted in automatically generated get methods before the actual value is retrieved. If defined on class level, the code is used for each attribute.

Applies to

▸ Model level: ☑ logical model ∙ ☑ technical model

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

Code, that is inserted in automatically generated get methods after the actual value has been retrieved, immediately before it is returned. If defined on class level, the code is used for each attribute.

This code has access to a local variable named "result", which is assigned the value to be returned.

Applies to

▸ Model level: ☑ logical model ∙ ☑ technical model

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

If true, an AfterGetBody is created which automatically anchors the attribute in the enclosing instance before returning it.

Applies to

▸ Model level: ☑ logical model ∙ ☐ technical model

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

Code, that is used in automatically generated set methods to assign the actual value. If omitted, a default piece of code is generated, simply assigning to the member variable.

Applies to

▸ Model level: ☑ logical model ∙ ☑ technical model

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

Code, that is inserted in automatically generated set methods before the actual value assignment takes place. If defined on class level, the code is used for each attribute.

Applies to

▸ Model level: ☑ logical model ∙ ☑ technical model

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

Code, that is inserted in automatically generated set methods after the actual value assignment took place. If defined on class level, the code is used for each attribute.

Applies to

▸ Model level: ☑ logical model ∙ ☑ technical model

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

If true, the respective attribute is not implemented as an attribut, but getters and setters are, respectively. This is useful if the value of this attribute is always calculated, and there's just no need to store this value at all.

Note: if this property is true, a XMLogicImplementation/GetBody and a XMLogicImplementation/SetBody need to be provided.

Applies to

▸ Model level: ☑ logical model ∙ ☑ technical model

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

Code, that is used in operations.

Applies to

▸ Model level: ☑ logical model ∙ ☑ technical model

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

The operation will be implemented synchronized.

Applies to

▸ Model level: ☑ logical model ∙ ☑ technical model

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

The operation will be implemented on class level, i.e. not per instance. In Java, this translates to 'static'.

Applies to

▸ Model level: ☑ logical model ∙ ☑ technical model

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

If true, calls to this method are delegated to the corresponding state instances and thereby implemented in the TSM layer, typically backend specific.

Applies to

▸ Model level: ☑ logical model ∙ ☑ technical model

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

Code, that is inserted in operations at the very beginning before automatically inserted try-statements, but after automatically inserted preparations of local contexts. If declared on class level, it is applied to all operations.

Applies to

▸ Model level: ☑ logical model ∙ ☑ technical model

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

Code, that is inserted in operations at the very end after automatically inserted catch-statements. If declared on class level, it is applied to all operations.

Applies to

▸ Model level: ☑ logical model ∙ ☑ technical model

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

If true, the generated class is implemented as a singleton, i.e. all constructors are made protected, a static member variable manages the one and only instance, and a static method getSingelton is provided.

Applies to

▸ Model level: ☑ logical model ∙ ☑ technical model

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

If true, the generated class is implemented as an abstract class.

Applies to

▸ Model level: ☑ logical model ∙ ☑ technical model

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

If true, this indicates that the respective EMOS1 class is not abstract. In this case, the getEMOS1 method is implemented independent of whether the given (EMOS2) class is abstract or not.

Applies to

▸ Model level: ☑ logical model ∙ ☑ technical model

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

If true, the generated attribute is not implemented in this class (but should be in derived classes).

Applies to

▸ Model level: ☑ logical model ∙ ☑ technical model

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

If true, the generated operation is not implemented in this class (but should be in derived classes).

Applies to

▸ Model level: ☑ logical model ∙ ☑ technical model

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

Classes, that will be initialised also if this class is initialised.

Applies to

▸ Model level: ☑ logical model ∙ ☑ technical model

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

Exceptions, that will be declared as throwable from constructors and initialisation code.

Applies to

▸ Model level: ☑ logical model ∙ ☑ technical model

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

Exceptions, that will be caught and handled by the given code. If declared at operation level, it applies to the operation, if declared at class level, it applies to every method of the class.

Applies to

▸ Model level: ☑ logical model ∙ ☑ technical model

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

Preparing code - i.e. typically declarations - which must be accessible within exception handlers as well as the normal operation body. If declared at operation level, it applies to the operation, if declared at class level, it applies to every method of the class.

Applies to

▸ Model level: ☑ logical model ∙ ☑ technical model

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

Code which is executed always, whether an exception is thrown or not.

Applies to

▸ Model level: ☑ logical model ∙ ☑ technical model

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

Termination code after complete try block. Might e.g. contain a return statement, that shall be executed after normal completion as well as after caught and handled exceptions. If declared at operation level, it applies to the operation, if declared at class level, it applies to every method of the class.

Applies to

▸ Model level: ☑ logical model ∙ ☑ technical model

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

If true, the class has a constructor without arguments. Such a constructor is typically used only if an object is reinstantiated from a database or from a remote system. Those systems cannot provide a context and often require a default constructor.

Applies to

▸ Model level: ☑ logical model ∙ ☑ technical model

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

If true, the respective attribute in the technical model corresponds to an association end in the logical model.

Applies to

▸ Model level: ☐ logical model ∙ ☑ technical model

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

If this attribute represents an association end, this property characterises the multiplicity.

Applies to

▸ Model level: ☐ logical model ∙ ☑ technical model

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

Used in the EMOS1Adapter to convert EMOS2 instances to EMOS1 counterparts.

Applies to

▸ Model level: ☑ logical model ∙ ☑ technical model

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

Used in the EMOS1Adapter to convert EMOS1 instances to EMOS2 counterparts.

Applies to

▸ Model level: ☑ logical model ∙ ☑ technical model

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

The respective feature is not implemented in the EMOS1Adapter.

Applies to

▸ Model level: ☑ logical model ∙ ☑ technical model

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

If true, the respective attribute can be set into an "ignore" mode, which causes validation to be skipped and the attribute is disabled in the adapter. It is e.g. used by bidirectional associations to allow creation of a disconnected side since one object needs necessarily to be able to be invalid during establishing the link.

Applies to

▸ Model level: ☐ logical model ∙ ☑ technical model

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

If true, the respective attribute provides an auxiliary member of the same type, so that in respective auxiliary code during construction or editing, like retrieval of appropriate choice sets, the not-yet-set value can be used already. It is used by bidirectional associations to allow creation of a disconnected side since one object needs necessarily to be able to be invalid during establishing of the link.

Applies to

▸ Model level: ☐ logical model ∙ ☑ technical model

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

If true, the respective attributes' type is an implementation level enumeration. This information is used to create a choice set based on the enumeration values as a fallback if no explicit choice set is defined.

Applies to

▸ Model level: ☐ logical model ∙ ☑ technical model

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