The UML-to-CORBA transformation transforms Unified Modeling Language (UML) version 2.0 model elements into Common Object Request Broker Architecture (CORBA) Interface Definition Language (IDL). You can use the transformation to seed a CORBA project from UML 2.0 specifications. The transformation also provides an optional, lightweight profile that you can use to model and generate most CORBA elements.
Before you use the UML-to-CORBA transformation, you should be familiar with creating and editing UML 2.0 models and projects. The following procedure shows the most basic use of the CORBA transformation.
To transform a UML model to CORBA:
1. Ensure that you are in the Modeling perspective.
2. In the Model Explorer view, create a UML component, named "Component1", and inside the component, create an interface, named "Interface1".
3. Right-click the component; then click Transform > Run Transformation > UML 2 CORBA.
4. In The Run Transformation window, click Create target container.
5. In The New project window, specify Sample as the project name and click Finish.
The new project contains an IDL file named "Component1.idl", and that file has an interface defined, which is named Interface1.
The transformation can also perform several other, more complex functions, such as overriding names without modifying the source model, validating the UML model for potential transformation problems, and so on.
You can specify a UML model, a component, a package that contains components, or a combination of these elements as the source for each application of the transformation. The transformation generates a single IDL file for each UML component in the hierarchy of the specified source. Each IDL file contains code only for the elements that the corresponding UML component owns. The transformation ignores elements that are not owned by a UML component. If you specify any other element as the source for the transformation, the transformation fails during validation.
When you apply the CORBA profile, you can control the UML components in your model for which the transformation generates code. You can exercise this control by setting the generateCode property to true or false. When you set the property to false, the transformation ignores the components when it generates code.
The target for each application of the transformation is a simple Eclipse project resource. The project contains the IDL file or files which are considered Eclipse workspace resource files.
You can model the following CORBA types without using a profile:
An optional profile provides stereotypes to model more specific CORBA types such as the following ones:
The CORBA transformation profile defines constraints on stereotypes. To evaluate these constraints and report any errors on a source model, you can use the "Run Validation" command. The CORBA transformation also performs additional validation on the portion of the model to which the transformation applies.
You can rename modeled elements in the generated code by using a mapping model. Except for components, you can only rename UML elements with simple identifiers. You can rename UML components with either a simple identifier or with a valid partial path that is relative to the target container in which the IDL file is generated. The path should end with the name of the IDL file. For example, if you rename Component A as dirA\A, the transformation generates A.idl in the directory named dirA, instead of in the top level of the target container.
The following table lists how the transformation maps UML 2.0 model elements to CORBA IDL.
UML 2.0 element |
CORBA IDL element |
Model |
Nothing |
Component |
IDL file |
Primitive types |
Basic types |
Native |
|
Package |
Module (if the package is in a component) |
Ignored (if the package is not in a component) |
|
Interface |
Interface |
Attribute or association |
Attribute |
Operation |
IDL operation |
Parameter |
Parameter of the IDL operation |
Enumeration |
Enumeration |
Class <<CORBAValue>> |
Value type |
Custom value type |
|
Boxed value type |
|
Static attribute |
Constant |
Class <<CORBAStruct>> |
Struct |
Class <<CORBAException>> |
Exception |
Class <<CORBATypedef>> |
Typedef |
Array |
|
Sequence |
A UML 2.0 component maps to a single CORBA IDL file. The IDL file for a component contains all the CORBA elements that the component owns.
A UML 2.0 primitive type maps to either a CORBA basic type or a CORBA native type. A UML 2.0 type library that contains all the CORBA basic types as UML 2.0 primitive types is available to import into the model. Alternatively, you can create a UML 2.0 primitive type with the same name as an existing CORBA basic type to use for type selection in the model. The following list shows the available CORBA basic types in the type library:
A UML 2.0 primitive type named anything other than the
types specified in the list represents a CORBA native type.
A CORBA native type generates the native
definition in the
IDL file and is available for type selection in the
model.
A UML 2.0 package contained in a UML 2.0 component maps
to the CORBA module. The transformation ignores UML 2.0
packages that are not in a
UML 2.0 component.
A UML 2.0 interface maps to the CORBA interface. A UML 2.0 generalization of UML 2.0 interfaces maps to the inheritance of CORBA interfaces. The following table lists how the transformation transforms interface properties.
|
UML interface property |
Transformation result |
|
Name |
New CORBA interface in the IDL with the specified name, with any illegal characters removed |
|
Visibility, public |
Normal interface |
|
Visibility, private |
Local interface |
|
Abstract |
Abstract CORBA interface |
|
Leaf |
Ignored |
UML 2.0 attributes and associations map to CORBA attributes. The following table lists how the transformation transforms attribute properties.
|
Transformation result |
|
|
Name |
CORBA attribute with the same name |
|
Type |
CORBA attribute with the specified basic type |
|
"Is Static" and "default" value |
CORBA constant |
|
Read only |
Read-only CORBA attribute |
|
Ordering |
IDL order |
The following table lists how the transformation transforms association properties.
UML association property |
Transformation result |
Name |
CORBA attribute with the same name |
Type |
CORBA attribute with the type as the supplier of this association |
"Is Static" and "default" value |
CORBA constant |
Read only |
Read-only CORBA attribute |
Ordering |
IDL order |
A UML 2.0 operation that is declared in a UML interface, or in a UML class with the <<CORBAValue>> stereotype, directly maps to the IDL operation. The transformation ignores other UML 2.0 operations. The following table lists how the transformation transforms operation properties.
|
UML operation property |
Transformation result |
|
Name |
New CORBA operation with the specified name |
|
Return type |
Return type of the CORBA operation |
|
All other properties |
Ignored |
|
Operation with the <<CORBAOneway>> stereotype |
One-way IDL operation |
|
<<create>> stereotype on operation in <<CORBAValue>> UML class |
Maps to a CORBA value initializer operation |
A UML 2.0 parameter maps to the parameter of the IDL operation. The following table lists how the transformation transforms parameter properties.
|
UML parameter property |
Transformation result |
|
Name |
New parameter with the specified name |
|
Direction (in, out, inout) |
Corresponding parameter in the IDL; 'return' is ignored |
|
Type |
Parameter with the specified type |
|
Visibility |
Ignored |
A UML 2.0 enumeration maps to the CORBA enumeration. An enumeration can contain only enumeration literals.
A UML 2.0 class with the <<CORBAValue>>
stereotype maps to a CORBA value type. The
<<CORBAValue>> stereotype comes with a property
named
specification and typed with the enumeration {"none",
"custom", "boxed"}. The default value is
"none".
If you set the specification property to "custom", it
maps
to a CORBA custom value. If you set the
specification property to "boxed", it maps to a CORBA
boxed value.
A CORBA value type is an entity that has an optional state and an initializer method that are separate from the properties of an interface. The state members of a CORBA value type are represented by the UML 2.0 attributes with the <<CORBAState>> stereotype and the initializer methods are represented by applying the <<create>> stereotype from the basic profile that comes with product.
The following table lists how the transformation transforms class properties.
|
UML class property |
Transformation result |
|
Stereotype |
<<CORBAValue>> |
|
Name |
New value type with the specified name. |
|
Visibility |
Ignored |
|
Abstract |
Abstract value type |
|
Attributes with <<CORBAState>> with public or private visibility |
CORBA state member of the CORBA value type, with public or private visibility |
|
Operation with <<create>> |
CORBA factory method of the non-abstract value type |
A CORBA constant declaration can appear in the scope of an IDL file, a module, an interface, or a value type.
A CORBA constant that appears in the scope of an interface
or value type can be represented by the UML static
attribute in the corresponding UML
interface or
class.
A CORBA constant that appears in the scope of a CORBA
module or in the scope of an IDL file must be an attribute
in a UML class with the
<<CORBAConstants>>
stereotype that appears in the UML package (for a module
constant) or in the UML component (for a IDL scope
constant).
The name of this class is
ignored. Each
attribute of the class with the
<<CORBAConstants>> stereotype represents
a constant declaration
.
A UML 2.0 class with the <<CORBAStruct>> stereotype maps to a CORBA struct. This class is constrained to have only attributes and no operations. The struct members are represented by the UML attribute or association of the class.
A UML 2.0 class with the <<CORBAException>> stereotype represents an exception definition. This type of class can optionally contain attributes.
In CORBA 2.4, only a CORBA operation can raise an
exception, and a CORBA attribute cannot raise an exception. Therefore, if a CORBA
operation raises an exception it is
represented in the RaisedException property of the
corresponding UML operation.
The transformation uses the CORBA typedef to give a new
name to an existing CORBA type. A UML 2.0 class with the
<<CORBATypedef>>
stereotype maps to the CORBA
typedef. A UML 2.0 substitution relationship from this
class to the existing CORBA type is the complete notation
that represents the CORBA typedef.
The CORBA 2.4 specification deprecates the anonymous
declaration of a CORBA array and sequence
type. This
mapping does not support anonymous
CORBA arrays or
sequences. You should name an array or sequence type
by using a typedef declaration. The
<<CORBATypedef>> stereotype that
extends
the UML 2.0 class contains a specification property
(whose values are "none", "array", and "sequence",
with "none" as the default) and a
dimensions property
(whose default is empty) that contain the array or
sequence dimensions.
A CORBA array is modeled as a UML 2.0 substitution
relationship from a class with the
<<CORBATypedef>> stereotype to the UML element
that
represents the type of array
element.
The "specification" property of the stereotype is set
to "array" and the "dimensions" property is set to
the string that
represents the array dimensions (for
example, "[3][5]"). An association from a constructed
type to the class with the
<<CORBATypedef>> stereotype models
a
member in the constructed type with the type as CORBA
array.
A CORBA sequence is modeled as a UML 2.0 substitution
relationship from a class with the
<<CORBATypedef>> stereotype to the UML element
that
represents the type of sequence element. The
"specification" property of the stereotype is set to
"sequence" and, optionally, the "dimensions" property
is
set to the string value that represents the upper bound of
the sequence (for example, "12").
An association from a constructed type to the class with
the <<CORBATypedef>> stereotype models a member
in the constructed type with the type as CORBA
sequence.
The transformation automatically generates a #include
when a type is used whose definition appears in a different
component. Most CORBA IDL files
need to include the ORB.idl
file. When you need to force a #include in a generated IDL
file of another external IDL file that is not modeled, you
must
create a dependency from the current component to a
newly created component that represents the external IDL
file. You can avoid generating code
for the newly created
component by setting the generateCode property to false.
This property comes with the component's stereotype from the
CORBA profile. For example, to generate
a "#include <ORB.idl>" in an IDL file, you should
create a dependency from the component that models
the
current IDL file to a new component named ORB. Also, to
prevent the transformation from generating code for the new
component named ORB,
set its generateCode property to
false.
The following CORBA constructs do not currently have a mapping in this profile:
The CORBA transformation provides integration with Team Support so that users can automatically check out and add new files to source control systems.
If you do not want to modify a source model for a
transformation, you can specify alternate names for the
target elements of the transformation.
You might also want
to specify alternate names if you want to include
CORBA-specific details in platform-independent models, such
as naming
restrictions. To support alternate target names
without modifying the source model, create a model
mapping.
To create a mapping model:
1. Ensure that you are in the Modeling perspective.
2. In the Model Explorer view, click a UML model.
3. From the menu bar, click Modeling > Transforms
> Configure Transforms.
4. Create a new UML 2.0 to CORBA transformation (for
example, name the transformation
Create mapping
).
5. On the Mapping page, click Only create mapping model
(no transformation).
6. Specify a file name and click Run.
When you use the transformation mapping feature, the CORBA
transformation creates a mapping model, which is a
separate model that has an artifact for each transformable
element. The artifact refers to and has the same name as
the original transformable element. To specify an alternate
name for the original element,
type a new name in the file
name property of the artifact. If you do not change the
artifact's file name property, the transformation generates
the element with the
artifact's default name. The following
table lists examples of alternate names.
|
UML source |
Mapping artifact file name |
Generated CORBA |
|
Component1 |
"" |
Component1.idl file |
|
Component2 |
"myIDL" |
myIDL.idl file |
|
Component3 |
"myDir\myIDL2" |
myIDL2.idl file in the "myDir" folder. |
To use a mapping model:
1. Ensure that you are in the Modeling perspective.
2. In the Model Explorer view, click a UML model.
3. From the menu bar, click Modeling > Transforms
> Configure Transforms.
4. Create a new UML 2.0 to CORBA Transform (for example,
name the transformation
Use mapping
).
5. On the Mapping page, click Use Mapping
Model.
6. Click the mapping model that you created earlier and
click Run.
When the transformation runs, it uses any alternate names
that you specified in the mapping model.
The CORBA transformation plug-in provides functionality
to validate models for potential transformation problems.
For example, circular generalization relationships and
naming conflicts cause compilation errors in the generated
IDL file. To see a list of potential problems that can
occur in the
generated code, apply the profile to the
source model and run the validation feature.
The following table lists some of the potential transformation problems.
|
Category |
Potential transformation problems |
|
CORBAValue Stereotype |
A value type should not have any nested classifiers other than typedef, struct, exception, or enumeration. |
|
A value type should have members with unique names. |
|
|
A value type should have unique inherited attributes. |
|
|
A value type should have unique inherited operations. |
|
|
A value type can support at most one non-abstract interface. |
|
|
An abstract value type should only inherit from other abstract value types. |
|
|
A value type cannot inherit from the same class more than once. |
|
|
A value type with state members can only inherit from a single value type with state members. |
|
|
An abstract value type cannot have state members and cannot be a boxed value type. |
|
|
A boxed value type cannot take part in inheritance. |
|
|
A boxed value type should have exactly one association or attribute. |
|
|
CORBAConstants Stereotype
|
The CORBAConstants class must not have operations. |
|
The CORBAConstants class should not have any nested classifiers. |
|
|
The CORBAConstants class should have members with unique names. |
|
|
CORBAException Stereotype |
The CORBAException class should not have any nested classifiers. |
|
CORBAStruct Stereotype |
A struct should not be an owner of generalization or implementation relationships. |
|
A struct should not have any nested classifiers. |
|
|
A struct should not have any operations. |
|
|
CORBATypedef Stereotype |
A typedef should not have any generalization relationships. |
|
A typedef should have one substitution relationship. |
|
|
A typedef should not have any associations, attributes, or operations. |
|
|
A typedef should not have any nested classifiers. |
|
|
CORBAState Stereotype |
A state member attribute should have a value type class as its owner. |
|
CORBAOneway Stereotype |
A one-way operation should not have parameters with the type in or inout. |
|
A one-way operation should have a return type of void. |
|
|
A one-way operation must have an interface as its owner. |
|
|
A one-way operation must not raise any exceptions. |
|
|
Enumeration |
An enumeration should have enumeration literals with unique names. |
|
Component |
A component should not contain a nested component. |
|
All packages in the component should have unique names. |
|
|
Interface |
An interface should have members with unique names. |
|
An interface should not contain a nested interface, package, value type, or component. |
|
|
An unconstrained interface cannot inherit from a local interface. |
|
|
An interface should have unique inherited operations. |
|
|
An interface should have unique inherited attributes. |
|
|
An interface cannot inherit from the same interface more than once. |
|
|
An abstract interface can only inherit from other abstract interfaces. |
|
|
General |
A model should not have elements named with CORBA keywords (for example, packages, classes, interfaces, operations, properties, parameters, and enumerations). |
|
A model should not have classes or interfaces with circular generalization or implementation relationships. |
|
|
A model should not have duplicate element names. |
|
|
A model should not have a badly formed hierarchy such as one that contains a nested component. |