This article describes how to create a CORBA model, i.e. a UML model that represents CORBA IDL constructs. From such a model you can later generate IDL files as described in Generating IDL files.
The easiest way to get started is to use the CORBA template model. It is a skeleton model that you can use as a starting point for creating a CORBA model from which IDL files can be generated. Perform these steps:
Your new CORBA model will be created in your workspace. The diagram called Instructions contains information about how to use the template.
If you want to create a CORBA model without using the CORBA template model you can do so by creating an empty UML model and then apply the CORBA Transformation profile to it.
Then you can create CORBA model elements in the top package of this model as explained in Creating CORBA Model Elements. It can also be a good idea to import the package 'CORBAPrimitiveTypes' so that you easily can reference all primitive types that correspond to basic IDL types (such as long, octet etc).
We use the term "CORBA Model Element" to denote a UML model element which will be translated to an IDL construct using the UML-to-CORBA IDL transform. A CORBA model element is a regular UML model element, in some cases with a stereotype applied (either a standard UML stereotype or more commonly a stereotype from the CORBA Transformation profile).
All CORBA elements should be placed under a Component which represents the IDL file in which the corresponding IDL construct should be generated.
If you don't see the command for creating components in the Add UML context menu, you may first have to enable the support for components. Do this by
The IDL file that is generated for the component will by default have the same name as the component itself and it will be placed in the root of the target project. You can use a Mapping Model to specify another name or location for the IDL file.
Once you have created a component that represents the IDL file to generate, you can create various model elements in that component. Each such model element will be transformed to a specific IDL construct in the IDL file. In some cases you also have to apply stereotypes from the CORBA Transformation profile to the model elements for specifying what the generated IDL should look like.
To learn how the various IDL constructs should be represented in the UML model refer to the sections below.
An IDL module is represented by a UML package. UML elements in the package will be translated to IDL constructs that are scoped by the module.
Example:
// File: BuilderComponent.idl
#ifndef _BUILDERCOMPONENT_IDL_
#define _BUILDERCOMPONENT_IDL_
module MyModule {
interface Builder {
const long long id = 1234;
boolean build(in string task );
};
};
#endif /* #ifndef _BUILDERCOMPONENT_IDL_ */
An IDL interface is represented by a UML interface. Use generalization relationships between UML interfaces to represent inheritance between IDL interfaces.
To model a local IDL interface, set the visibility of the UML interface to private. To model an abstract IDL interface, set the 'Abstract' property of the UML interface.
Example:
// File: Interfaces.idl
#ifndef _INTERFACES_IDL_
#define _INTERFACES_IDL_
#include "ParentComponent.idl"
abstract interface Child :
Parent {
long getId();
};
#endif /* #ifndef _INTERFACES_IDL_ */
Note that the IDL file where the referenced parent interface is defined gets automatically included.
An IDL struct is represented by a UML class with the stereotype «CORBAStruct» applied.
An IDL union is represented by a UML class with the stereotype «CORBAUnion» applied. This stereotype has an attribute 'switchType' which should specify a valid IDL discriminator type for the switch clause of the union. Attributes in the class are translated to cases in the IDL union. Apply the stereotype «switch» on these attributes to specify a constrant expression for the case. The type of this expression must match the specified discriminator type. The «switch» stereotype is also used for specifying which of the attributes that should represent the default case of the union.
An IDL enum is represented by a UML enumeration. The literals of the UML enumeration are translated to enumerated names in the IDL enum.
Example:
// File: ComplexTypes.idl
#ifndef _COMPLEXTYPES_IDL_
#define _COMPLEXTYPES_IDL_
enum Color {
Red,
Green
};
struct Time {
long sec;
long nano_sec;
};
union EitherOr switch(short) {
case 1 : long a;
case 2 : long long b;
default : boolean c;
};
#endif /* #ifndef _COMPLEXTYPES_IDL_ */
Use a UML class with the stereotype «CORBAValue» applied to represent an IDL value type. Attributes in the class should have the «CORBAState» stereotype applied and will then be transformed to state members of the value type. They will be either private or public depending on the visibility of the attributes.
Operations in the «CORBAValue» class that have the «create» stereotype applied will be transformed to initializers (a.k.a. "factory operations").
Make the class abstract to get an abstract value type in IDL.
A truncatable value type is represented by means of a generalization relationship between two «CORBAValue» classes, where the generalization has the «CORBATruncatable» stereotype applied.
You can specify that a value type uses custom marshalling by setting the property 'specification' to "custom" in the «CORBAValue» stereotype. If you instead set it to 'boxed' you will get a boxed value type.
Example:
// File: ValueTypeExample.idl
#ifndef _VALUETYPEEXAMPLE_IDL_
#define _VALUETYPEEXAMPLE_IDL_
valuetype Base {
public string stringRep;
};
valuetype Status : truncatable Base {
public short currentVal;
factory newStatus();
};
#endif /* #ifndef _VALUETYPEEXAMPLE_IDL_ */
An IDL exception is represented by means of a UML class with the stereotype «CORBAException» applied. Such exception classes may be used when defining an operation, to declare that a call of the operation may raise the specified exception(s). See Operation for an example.
All basic IDL types (e.g. short, boolean, octet etc) are represented using primitive types in UML. If you use the CORBA Template Model you find these primitive types in the class diagram called 'Shortcuts to CORBA primitive types'. The types are placed in a package 'CORBAPrimitiveTypes' which is automatically imported when you use the CORBA Template Model.
If you create your CORBA model from scratch (see Creating a CORBA model from scratch) you can either import this package, or you can simply create your own primitive type named as the corresponding IDL basic type.
An IDL typedef is represented by means of a UML class with the stereotype «CORBATypedef» applied. The class should have a «substitute» relationship to a type that corresponds to the IDL type of the typedef.
Example:
// File: TypedefExample.idl
#ifndef _TYPEDEFEXAMPLE_IDL_
#define _TYPEDEFEXAMPLE_IDL_
typedef long double MyTypedef;
#endif /* #ifndef _TYPEDEFEXAMPLE_IDL_ */
IDL attributes are represented by UML attributes or associations. If the UML attribute is specified to be read-only, the IDL attribute will be declared with the readonly keyword.
If a UML attribute is defined as static and has a default value specified, then it will be transformed to an IDL constant. To place the IDL constant directly in a file or in a module you must use a container UML class with the «CORBAConstants» stereotype applied.
Example:
// File: Attributes.idl
#ifndef _ATTRIBUTES_IDL_
#define _ATTRIBUTES_IDL_
const float pi = 3.14;
interface Observer {
readonly attribute short regCount;
};
#endif /* #ifndef _ATTRIBUTES_IDL_ */
IDL operations are represented by UML operations. They may have parameters with a direction specified (in, out and inout). In addition they may have a return parameter whose type decides the return type of the IDL operation.
Apply the stereotype «CORBAOneway» to model a oneway IDL operation.
If you want the IDL operation to have a context expression, apply the stereotype «CORBAOperation» to the UML operation, and edit the stereotype property 'context'. Its value is a list of string literals.
An operation may reference one or many exception classes to specify that a call of the operation may raise those exceptions.
Example:
// File: Operations.idl
#ifndef _OPERATIONS_IDL_
#define _OPERATIONS_IDL_
#include "Attributes.idl"
exception Error {
short errCode;
};
interface Vehicle {
boolean register(inout string key ,in Observer observer ,out boolean isDuplicate ) raises (Error);
oneway void scheduleUpdate();
long double opWithContext() context ("sys_time","sys_location");
};
#endif /* #ifndef _OPERATIONS_IDL_ */
You should give names to your UML model elements that are valid IDL names. If the UML-to-CORBA IDL transform detects a name in the model that is not valid in IDL, it will change it. Some examples of when this will happen are:
interface, enum or Object)Illegal characters will be replaced with an underscore (_) and names that are invalid will get the string "_renamed" appended in the generated IDL.