Using an XMI Description

Modeling Services > Dynamic Modeling Services > Defining a Dynamic Model > Using an XMI Description

Rogue Wave® Server supports an XMI parser for the description of a model. The XMI format is an XML representation of the Unified Modeling Language (UML) currently under standardization by the OMG. The XMI format is already supported by various CASE tools. A number of converters exist to transform most common formats into XMI. Rogue Wave Server supports version 1.0 of the XMI Standard based on UML 1.1.

A dynamic server can read an XML file whose DTD is XMI 1.0 and create the corresponding Rogue Wave Server dynamic model. Any model element read in the XMI description is considered a dynamic element.


Important: When an XMI description is read, any model element that already exists in the server model interpreter (because its has been declared using the standard macros) is not replaced by a corresponding dynamic element. As a consequence, if the XMI description defines a dynamic class that already exists in the Server application as a static class declared to the server model interpreter by the ILS_OBJECT_DECL macro, this static class will not be replaced by the dynamic one. For example if a C++ class Network is declared to the model interpreter and this class is also declared in an XMI file, the resulting class is the union of the C++ class and the dynamic class. The C++ class will be complemented by the dynamic description of this class. The attributes that do not exist in C++ but do exist in the XMI decription are added as dynamic attributes.

Dynamic modeling elements read from an XMI description have a lower precedence order than static model elements. They can complement a static model.

UML-to-Dynamic-Model Mapping

The modeling concepts and rules implemented by Rogue Wave Server are fairly close to the concepts and rules implemented by UML, yet some of them have no equivalent in UML. Such is the case, for instance, for the attributes called entry data members and derived data members in Rogue Wave Server.

A Server dynamic model can be created from a UML description, provided it is complemented by a number of Rogue Wave Server properties used to represent specific Rogue Wave Server concepts that cannot be represented by UML. This section describes the rules you must follow to create a Server dynamic model from a UML description stored in XMI format, taking into account the Server-specific properties.

Types

UML basic types are mapped to Rogue Wave Server basic types as shown in this table:

UML/Server Types Mapping
UML Basic Type	Rogue Wave Server Type
boolean	IlsBoolean
char	char
double	double
float	float
short, int, long	long
string	IlsString
other	Rogue Wave Server type or user-defined type if available

Other Elements

This table shows how UML attributes, associations, classes, generalizations, and methods are mapped to their Rogue Wave Server counterparts.

UML Dynamic Model Mapping
UML	Rogue Wave Server	Comments
Attribute	Dynamic attribute	If the attribute scope is classifier, it is mapped to a dynamic attribute of the static model. These attributes are shared by all instances of the corresponding classes. These attributes are regular, which means that changing their value does not trigger any notification. If an initial value is specified in the UML model, this value will be assigned to the dynamic attribute.
Association	Dynamic relation	See More About the Association/Relation Mapping below.
Class		No dynamic class is created if its static equivalent already exists in the server.
Generalization	Inheritance link	Between two dynamic classes or between a dynamic class and a static class. The Rogue Wave Server dynamic modeling feature does not support multiple inheritance.
Method	Dynamic member function

More About the Association/Relation Mapping

The association must have only one navigable role or the navigable Rogue Wave Server property must be true for only one association end. The navigable association end determines the direct Rogue Wave Server relation. (See Figure 5.1.) The non-navigable association end is the inverse relation.

The navigable association end must be named.

If the non-navigable association end is an aggregate, the Rogue Wave Server relation is an ownership relation; otherwise, it is a use relation.


Note: Rogue Wave Server does not differentiate between the various types of aggregation and considers the relation as an ownership relation both for shared and composite aggregations.

If the multiplicity of the navigable association end is 0..n, the Server relation is n‑ary.

If the multiplicity of the navigable association end is 1 or 0..1, the Server relation is unary.

If the multiplicity of the navigable association end is 1, the Server relation is mandatory.


Note: The Server relation is not mandatory if the mandatory Server property attached to the navigable role is false.

A Server inverse relation is created if the inverse association end is named.

If the multiplicity of the inverse association end is 1 or 0..1, the Server inverse relation is unary.

If the multiplicity of the inverse association end is 0..n, the Server inverse relation is n‑ary.

You can override the UML multiplicity of an association end using the Server property multiplicity.

Additional Properties

In addition to the standard UML specification elements, a number of Rogue Wave Server properties are necessary to describe a well-formed dynamic model. These properties can be represented as UML elements using standard extension mechanisms supported by UML (such as tagged values, for instance). These Rogue Wave Server properties are described in the following tables:

Table 5.3 Class Properties

Table 5.4 Attribute Properties

Table 5.5 Method Properties

Table 5.6 Role Properties

Class Properties

This table shows the class properties that can be used to complement the UML representation of an Rogue Wave Server dynamic model.

Class Properties
Property	Possible Values	Default Value	Comment
dynamic	true, false	true	All classes described in the provided UML model are registered to the server model interpreter. If the corresponding class does not exist, it will be declared as a dynamic class. Existing static classes in the dynamic Server application will not be replaced by dynamic classes. Use this property to hide internal classes. The hidden classes must not be the targets of any relations specified in the UML description.
identifier	<attribute name>		If this property exists, it must designate an attribute of the class that will be used as the object identifier. See “Identified Objects”..
useDictionary	true, false	false	Specifies whether instances of this class must be stored in a global dictionary.

Attribute Properties

This table shows the attribute properties that can be used to complement the UML representation of an Rogue Wave Server dynamic model

Attribute Properties
Property	Possible Values	Default Value	Comment
dynamic	true, false	true	By default, all attributes are considered dynamic attributes if they do not already exist in the server model interpreter.
type	entry, derived, regular	regular	Specifies the Server attribute type. Regular attributes do not trigger notification when modified.
check	true, false	false	When this property is set, Rogue Wave Server invokes a check function before the attribute is assigned. See “Check Functions”..

Method Properties

This table shows the method properties that can be used to complement the UML representation of an Rogue Wave Server dynamic model.

Method Properties
Property	Possible Values	Default Value	Comment
dynamic	true, false	true	By default, all methods are considered dynamic methods and declared to the server model interpreter.

Association-End (role) Properties

This table shows the role properties that can be used to complement the UML representation of an Rogue Wave Server dynamic model.

Role Properties
Property	Possible Values	Default Value	Comment
dynamic	true, false	true	By default, all associations are considered as dynamic relations. If the direct role of an association (i.e. the navigable one) is marked as not dynamic, the corresponding association is not dynamic.
navigable	true, false	-	By default, the UML property value is used. This property can be used to force navigability of the role.
mandatory	true, false	true	Available only for navigable roles and if the relation is unary. Specifies whether the unary relation is mandatory or not. By default, the UML multiplicity is used to distinguish between mandatory (1) and not mandatory (0..1) relations. This property can be used to force the Server relation property.
ownership	true, false	true	Specifies whether the relation is an ownership relation. If this property is missing, the relation type is determined by the UML aggregation property of the relation.
multiplicity	unary, nary	-	Specifies whether the relation must be unary or n-ary. If this property is missing, the relation type is determined by the UML multiplicity: if the UML multiplicity is "1" or "1..1" or "0..1", the relation is considered unary, otherwise it is considered n-ary.
implementation	list, set, pointer	list	Specifying pointer for this property means that the underlying relation will not be implemented as a Server relation. Only available for unary relations, this value allows you to specify a simple relation implemented as a direct pointer with no inverse relation. Specifying list or set for n-ary relations determines their underlying implementation. Moreover, if you specify set, the n-ary relation will be implemented as a set relation and in this case, the target class must have an identifier attribute whose value is non-null. specifying sortedList for the implementation allows to have a sorted relation. The objects in this relation must be identified and the relation is sorted on the identifier in alphanumeric order.
check	true, false	false	When this property is set, Rogue Wave Server invokes a check function before the relation is assigned. See “Check Functions”..

The built-in XMI parser specifies where these properties should be stored in the XMI tree.

Specifications of the Rogue Wave Server XMI Parser

The XMI parser included with Rogue Wave Server supports XMI version 1.0 and uses a specific set of standard XML tags to retrieve information to build a Server Dynamic Model.

If an XMI file references another XMI file and if an element of the referenced file is used in the model description, then the referenced XMI file will also be loaded.

An identified XMI element is an XMI tag which has an attribute named xmi.id. Note that this identifier is local to the current XMI document.

A reference XMI element is an XMI tag which has an attribute named xmi.idref. The value of this attribute is equal to the value of the xmi.id attribute of the referenced element.


Important: XMI tags, attributes, and values are case-sensitive for the Rogue Wave Server XMI parser.

Class Tags

Unlike in UML—where classes are included in packages (which can themselves be included in higher-level packages—containment is not relevant for Rogue Wave Server dynamic models. Starting from a class subtree, the XMI parser searches for:

attributes (features): Attributes are contained in the class.

Methods (operations): Operations are contained in the class.

References to generalizations

References to association ends

The following tags and attributes are used to read classes and their properties.

Class Tags
XMI Tag	Mandatory Attribute	Comment
Foundation.Core.Class	xmi.id	This tag defines a new class.
Foundation.Core.ModelElement.name		Mandatory child class name
Foundation.Core.Generalization	xmi.idref	Reference to a generalization
Foundation.Core.AssociationEnd	xmi.idref	Reference to an association end

Generalization Tags

The following tags and attributes are used to read class attributes and their properties.

Generalization Tags
XMI Tag	Mandatory Attribute	Comment
Foundation.Core.Generalization	xmi.id	This tag defines a new generalization relation between two classes. The generalization relation is stored at package level. This relation is referenced by the supertype class and the subtype class.
Foundation.Core.Generalization.supertype		Mandatory child of Foundation.Core. Generalization, this tag references the supertype of the generalization. This tag must have a child that is a reference to a class.

Attribute Tags

The following tags and attributes are used to read class attributes and their properties.

Attribute Tags
XMI Tag	Mandatory Attribute	Comment
Foundation.Core.Attribute	xmi.id	This tag defines a new attribute for the current class.
Foundation.Core.ModelElement.name		Mandatory child. attribute name
Foundation.Core.StructuralFeature.type		Mandatory child. The first child of this tag references the attribute type as a primitive data type or an existing class. See Table 5.13.
Foundation.Core.Feature.ownerScope	xmi.value	This tag is used to specify whether the attribute scope is instance or classifier. An attribute with “classifier” scope will be mapped to a Server static dynamic attribute.
<Foundation.Core.Attribute.initialValue> <Foundation.Data_Types.Expression> <Foundation.Data_Types<Expression.body> defValue</Foundation.Data_Types.Expression.body> </Foundation.Data_Types.Expression> </Foundation.Core.Attribute.initialValue>		This tag is used to specify an initial value for the attribute.

Method Tags

The following tags and attributes are used to read class methods and their properties.

Method Tags
XMI Tag	Mandatory Attribute	Comment
Foundation.Core.Operation	xmi.id	This tag defines a new method for the current class.
Foundation.Core.ModelElement.name		Mandatory child. method name
Foundation.Core.BehavioralFeature. parameter		Mandatory child of Foundation.Core.Operation. This tag introduces the subtree of the operation parameter.

Parameter Tags

The following tags and attributes are used to read method parameters and their properties.

Parameter Tags
XMI Tag	Mandatory Attribute	Comment
Foundation.Core.Parameter	xmi.id	This tag defines a new parameter for the current method.
Foundation.Core.ModelElement.name		Mandatory child. Parameter name, if any
Foundation.Core.Parameter.kind	xmi.value	Optional child of Foundation.Core.Parameter. If the value of xmi.value is “return”, the corresponding parameter is the return parameter of the current method.
Foundation.Core.Parameter.type		Mandatory child. Its only child is a reference to the primitive data type or the class that is the type for this parameter.

Association-End Tags

The following tags and attributes are used to read association ends and their properties. Association ends are referenced in the class XMI subtree but are defined in their own association subtree. The association subtrees are defined at package level.

Each association defines two association ends. One end is considered as the “opposite role” of the other.

Note that an association end is always referenced by the class that is the target class of this association end.

Example

Figure 5.1 Associations and Relations

In this example, the domains association end is referenced by the class Domain while the network association end is referenced by the class Network.

As only one role is navigable, the Server relation is defined from Network to Domain. The relation name is domains in the class Network. Because the inverse role is named, an inverse relation named network is declared in the class Domain.

If the role name of an inverse association end is unnamed (that is, it is empty or it contains the "$UNNAMED" string), then the inverse relation is not declared.

Note that the Rogue Wave Server XMI parser supports only unidirectional associations, namely associations with one and only one navigable role.

Association-End Tags
XMI Tag	Mandatory Attribute	Comment
Foundation.Core.AssociationEnd	xmi.id	This tag defines a new association end. If directly referenced by a class, this association end is considered to be the opposite role of the corresponding association for this class. The other association end of the association is the direct role.
Foundation.Core.ModelElement.name		Mandatory child. role name if any.
Foundation.Core.AssociationEnd.type		Mandatory child of the direct role. The first child of this tag references the target type of the association. It must be an existing class.
Foundation.Core.AssociationEnd. isNavigable	xmi.value	Mandatory child of the direct role. If xmi.value is true, the association is considered a direct relation for this class. Otherwise, it is considered an inverse relation.
Foundation.Core.AssociationEnd. aggregation	xmi.value	Mandatory child of the opposite role. If xmi.value is “none”, the direct relation is considered an ownership Server relation. Otherwise, the relation is considered a Server use relation. Inverse relations cannot be aggregated.
Foundation.Core.AssociationEnd. multiplicity		Mandatory child of the direct role. The supported values are: 0..*: the Server relation is n-ary. 0..1: the Server relation is unary and not mandatory. 1: the Server relation is unary and mandatory

Rogue Wave Server Properties

The Rogue Wave Server XMI parser supports a set of Rogue Wave Server properties which extends UML core elements to describe the Rogue Wave Server dynamic model. Each UML element (class, attribute, association, and so forth) has a tagged value subtree. This subtree stores properties that are not specified by UML, such as code generation properties, documentation, and others. This is where Rogue Wave Server searches for its specific properties. This subtree is introduced by the XML node: Foundation.Core.ModelElement.taggedValue.

The Rogue Wave Server property should be placed in the value part of a tag value and must be prefixed by ilog.server. The property value must be enclosed in quotation marks, like this:

ilog.server.type="entry"

The quotation marks are mandatory and there should be no space between the property name and the = symbol, nor between the = symbol and the property value.

If they cannot be found in the tagged-value subtree, the Server-specific properties are searched for in an XMI.extension subtree, if any.

Keep in mind that since the documentation of a UML element is a standard tagged value, the Server-specific properties can be specified in the documentation part of the UML element.

Type-Matching Table

This table gives the correspondence between UML types and Rogue Wave Server types.

UML/Server Types Mapping
UML Basic Type	Rogue Wave Server Type
any, Any, IlsAny	IlsAny
bool, boolean, IlsBoolean, Boolean	IlsBoolean
char, Char	char
float, Float	float
double, Double	double
long, int, short, Integer	long
string, String, IlsString	IlsString

Unnamed Elements

A model element is considered unnamed if its name is empty or contains the string "$UNNAMED".

Version 5.8