Chapter 17: CORBA/IDL Code Generation and Reverse Engineering

Unidirectional Associations

As with bidirectional associations, Rose will generate attributes to support unidirectional associations. With a unidirectional association, however, an attribute is generated at only one end of the relationship.

For the Class_A and Class_B classes above, code similar to the following would be created:

interface Class_A {

attribute Class_B Class_B_Role; };

and

Interface Class_B

{

};

As you can see, Rose will generate a private attribute for the relationship at only one end of the association. Specifically, it will generate an attribute in the client class, but not in the supplier class.

For each of the other CORBA types (typedef, enumeration, const, exception, struct, or union), Rose will generate code as shown in the bidirectional associations sections above. The only difference with a unidirectional association is that the attribute will be created on only one side of the relationship.

Note that the multiplicity here is one to one. Let's take a look at how code is affected when the multiplicity settings are changed.

Associations with a Multiplicity of One to Many

In a one−to−one relationship, Rose can simply create the appropriate attributes to support the association. With a one−to−many relationship, however, one class must contain a set of the other class.

To begin, let's look at an example.

595

Chapter 17: CORBA/IDL Code Generation and Reverse Engineering

In this case, we have a one−to−many relationship. As we saw earlier, Class_B can generate an attribute that is simply a pointer to Class_A, but a simple pointer attribute in the Class_A class won't be enough. Instead, the attribute generated in Class_A must use some sort of container class as its data type. In IDL, there are two container classes you can use: a sequence or an array. By default, Rose will use a sequence.

For this example, Rose will generate code similar to the following:

interface Class_A {

typedef sequence <Class_B> Class_B_Roledef;

attribute Class_B_Roledef Class_B_Role;

};

and

interface Class_B {

attribute Class_A Class_A_Role;

};

As you can see, Class_B includes a simple pointer to Class_A, as we saw earlier. However, a container class was used in Class_A when generating the Class_B attribute.

The full code generated for Class_A is:

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

#ifndef CLASS_A_DEFINED #define CLASS_A_DEFINED

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

#include "Class_B.idl"

interface Class_A {

typedef sequence <Class_B> Class_B_Roledef;

attribute Class_B_Roledef Class_B_Role;

};

#endif

596

Chapter 17: CORBA/IDL Code Generation and Reverse Engineering

Again, Rose will use a sequence as the default container class. To use an array instead, open the relationship specification and change the BoundedRoleType property to Array. To use an array for all relationships with a multiplicity greater than one, select Tools → Options from the menu. On the CORBA tab, select Role from the drop−down list box and change the value in the BoundedRoleType property to Array.

One−to−Many Associations Generated for a TypeDef

If the stereotype of Class_A is CORBATypeDef, an #include statement will be added to the code, but an attribute will not be generated in Class_A to support the relationship with Class_B. The code generated for Class_A is as follows:

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

#ifndef CLASS_A_DEFINED #define CLASS_A_DEFINED

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

#include "Class_B.idl"

typedef sequence <Class_B> Class_A;

#endif

One−to−Many Associations Generated for an Enumeration

As with a typedef, Rose will not generate attributes to support the relationship if Class_A is an enumeration. There will, however, be an #include statement in the code generated for Class_A. The code for Class_A is as follows:

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

#ifndef CLASS_A_DEFINED #define CLASS_A_DEFINED

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

#include "Class_B.idl"

enum Class_A {

};

#endif

One−to−Many Associations Generated for a Constant

If Class_A is a constant, it will have an #include statement for Class_B, but will not have an attribute for the relationship. The code for Class_A is shown below:

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

#ifndef CLASS_A_DEFINED

597

Chapter 17: CORBA/IDL Code Generation and Reverse Engineering

#define CLASS_A_DEFINED

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

#include "Class_B.idl"

const long Class_A = 4;

#endif

One−to−Many Associations Generated for an Exception

If Class_A is an exception, an attribute will be created inside it to support the relationship to Class_B. In a one−to−many relationship, Rose will use a container class when generating this attribute. By default, as with one−to−many relationships between interfaces, Rose will use a sequence as a container. You can change the container class to use an array by changing the BoundedRoleType role property to Array.

The following code is generated for Class_A when its stereotype is set to CORBAException and Class_A has a one−to−many relationship with Class_B.

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

#ifndef CLASS_A_DEFINED #define CLASS_A_DEFINED

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

#include "Class_B.idl"

exception Class_A {

sequence <Class_B> Class_B_Role;

};

#endif

One−to−Many Associations Generated for a Structure

When the stereotype of Class_A is set to CORBAStruct, and Class_A has a one−to−many relationship with Class_B, an attribute will be created in Class_A to support that relationship. As with the other one−to−many relationships, Rose will use a container class when creating the attribute. By default, a sequence is used. To use an array instead, change the BoundedRoleType role property.

The following is the code generated for Class_A:

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

#ifndef CLASS_A_DEFINED #define CLASS_A_DEFINED

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

#include "Class_B.idl"

struct Class_A {

598