# NLS_MESSAGEFORMAT_VAR

UML-to-CORBA transformation

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). E' possibile utilizzare la trasformazione per realizzare un progetto CORBA dalle specifiche UML 2.0. The transformation also provides an optional, lightweight profile that you can use to model and generate most CORBA elements.


1. Getting started

Before you use the UML-to-CORBA transformation, you should be familiar with creating and editing UML 2.0 models and projects. La procedura illustrata di seguito, mostra le funzioni base della trasformazione CORBA.

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.

 

2. Transformation details

 

2.1 CORBA template model

The CORBA template model can help you start modeling with CORBA quickly. To begin, click File > New > UML Model and select CORBA Model from the available templates. This selection generates a UML model and provides instructions and a basic infrastructure for creating a CORBA model.

 

2.2 Transformation source

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.

2.3 Transformation target

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.

2.4 Optional profile

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:

2.5 Validation of the source model

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.

2.6 Use of a mapping model

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.

3. UML-to-CORBA mapping

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

3.1 UML 2.0 model

A UML 2.0 model does not directly map to any CORBA element. This lack of mapping means that transformation does not generate code for the model element if no components are defined in the model.

3.2 UML 2.0 component

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.

3.3 UML .0 primitive types

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.

3.4 UML 2.0 package

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.

3.5 UML 2.0 interface

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

3.6 UML 2.0 attributes and associations

UML 2.0 attributes and associations map to CORBA attributes. The following table lists how the transformation transforms attribute properties.

UML attribute property

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

3.7 UML 2.0 operation

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. La trasformazione ignora altre operazioni UML 2.0. 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

3.8 UML 2.0 parameter

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

3.9 UML 2.0 enumeration

A UML 2.0 enumeration maps to the CORBA enumeration. An enumeration can contain only enumeration literals.

3.10 UML 2.0 class with the <<CORBA Value>> stereotype

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

3.11 UML 2.0 static attribute

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
.

3.12 UML 2.0 class with the <<CORBA Struct>> stereotype

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.

3.13 UML 2.0 class with the <<CORBA Exception>> stereotype

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.

3.14 UML 2.0 class with the <<CORBA Typedef>> stereotype

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 proprietà (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.

4. CORBA forward declarations and includes

The transformation automatically generates CORBA forward declarations. Non è possibile creare modelli per esse. The transformation rearranges types in IDL to minimize forward declarations. When a type is used before its definition and the type definition cannot be moved before its use, the transformation generates a forward declaration 
of the type in the correct scope.

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.

5. Cross model references

The UML-to-CORBA transformation supports models with cross-references. For example, Interface A in the current model could extend Interface B from 
another model. In such cases, the transformation creates a #include of the IDL file in which the used type appears (Interface B, in this example). 
The transformation does not manage the location of the included IDL files in the file system. You should maintain the relative paths of the generated IDL 
files by using a mapping model.

 

6. CORBA constructs not mapped

The following CORBA constructs do not currently have a mapping in this profile:

7. Support for common transformation technologies

 

7.1 Integration with Team Support

The CORBA transformation provides integration with Team Support so that users can automatically check out and add new files to source control systems.

7.2 Transformation mapping model

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.

7.3 Validation

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.