Chapter 17: CORBA/IDL Code Generation and Reverse Engineering

//Source file: C:/corba/Class_A.idl

#ifndef CLASS_A_DEFINED #define CLASS_A_DEFINED

/* CmIdentification %X% %Q% %Z% %W% */

union Class_A switch() { case 2: Class_A RoleB;

};

#endif

Reflexive Associations Generated for Other CORBA/IDL Types

Because attributes are not generated for a typedef, enumeration, or constant, reflexive associations with these types will not be reflected in the code.

Aggregations

When generating CORBA/IDL, associations and aggregations are treated the same. All of the considerations we've discussed so far (the multiplicity, whether the relationship is unidirectional or bidirectional, and whether or not the relationship is reflexive) apply the same to aggregations as they do to associations. This is true for any of the CORBA types (interface, typedef, enumeration, constant, exception, structure, or union).

For information about how unidirectional aggregations, aggregations with various multiplicity indicators, and reflexive aggregations are generated, please see the corresponding sections on associations.

Dependency Relationships

With a dependency relationship, attributes are not created. If there is a dependency between Class_A and Class_B, attributes will be created in neither Class_A nor Class_B.

The code that is generated will look something like the following:

Interface Class_A

{

};

and

604

Chapter 17: CORBA/IDL Code Generation and Reverse Engineering

Interface Class_B

{

};

Rose will place only one reference to Class_B—an include statement for Class_B.IDL—inside of Class_A. Class_A will not be referenced in Class_B at all.

Because no attributes are generated for a dependency, an attribute will not be created for any of the CORBA types (interface, typedef, enumeration, constant, exception, structure, or union).

Generalization Relationships

A generalization relationship in UML becomes an inheritance relationship in IDL. In your Rose model, an inheritance relationship is shown as follows:

For this type of relationship, Rose will generate something that looks like this:

Interface Parent

{

};

and

Interface Child : Parent

{

};

Let's look at the actual code that is generated. In the code for the parent class, there is no mention of the child class. This helps keep the parent generic; many classes can therefore inherit from it without affecting its code.

In the child class, the code is generated to support its inheritance from the parent class. The code for the child class is as follows:

//Source file: C:/corba/Child.idl

#ifndef __CHILD_DEFINED #define __CHILD_DEFINED

/* CmIdentification %X% %Q% %Z% %W% */

605

Chapter 17: CORBA/IDL Code Generation and Reverse Engineering

#include "Parent.idl"

interface Child : Parent { };

#endif

Generalizations Generated for a TypeDef

If the child class is a typedef, an #include statement will appear in the generated code for the child, but an inheritance relationship will not be shown in the code. The IDL for the child class is as follows:

//Source file: C:/corba/Child.idl

#ifndef __CHILD_DEFINED #define __CHILD_DEFINED

/* CmIdentification %X% %Q% %Z% %W% */

#include "Parent.idl"

typedef Child;

#endif

Generalizations Generated for an Enumeration

The same is true for an enumeration. Although an #include statement is generated, the inheritance relationship itself is not represented in the code. In this case, the generated code looks like this:

//Source file: C:/corba/Child.idl

#ifndef __CHILD_DEFINED #define __CHILD_DEFINED

/* CmIdentification %X% %Q% %Z% %W% */

#include "Parent.idl"

enum Child {

};

#endif

Generalizations Generated for a Constant

As with a typedef or enumeration, a generalization relationship will not be directly implemented in code with a constant. An #include statement will be generated to reference the parent. The code for this example looks like this:

//Source file: C:/corba/Child.idl

606

Chapter 17: CORBA/IDL Code Generation and Reverse Engineering

#ifndef __CHILD_DEFINED #define __CHILD_DEFINED

/* CmIdentification %X% %Q% %Z% %W% */

#include "Parent.idl"

const long Child = 4;

#endif

Generalizations Generated for an Exception

Inheritance is not supported with an exception. Therefore, as in the other cases, an #include statement will be generated, but the generalization itself will not be reflected in the code. The IDL for this situation looks like this:

//Source file: C:/corba/Child.idl

#ifndef __CHILD_DEFINED #define __CHILD_DEFINED

/* CmIdentification %X% %Q% %Z% %W% */

#include "Parent.idl"

exception Child { };

#endif

Generalizations Generated for a Structure

As with the other CORBA types, inheritance is not supported with a structure. An #include statement will be included to reference the parent, but the inheritance relationship will not be reflected in the code. The IDL generated for a generalization with a structure is as follows:

//Source file: C:/corba/Child.idl

#ifndef __CHILD_DEFINED #define __CHILD_DEFINED

/* CmIdentification %X% %Q% %Z% %W% */

#include "Parent.idl"

struct Child { };

#endif

607