Modeling Services > Dynamic Modeling Services > Defining a Dynamic Model > Using an XMI Description
 
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
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 Associations and Relations.) 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 UML/Server Types Mapping.
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
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 6.3
Copyright © 2018, Rogue Wave Software, Inc. All Rights Reserved.