Добавил:
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Mastering UML with Rational Rose 2002.pdf
Скачиваний:
137
Добавлен:
02.05.2014
Размер:
9.68 Mб
Скачать

Chapter 17: CORBA/IDL Code Generation and Reverse Engineering

sequence <Class_B> Class_B_Role; };

#endif

One−to−Many Associations Generated for a Union

If Class_A is a union, both an #include statement and an attribute will be generated in Class_A to support the relationship with Class_B. 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" union Class_A switch() {

case 1: sequence <Class_B> Class_B_Role;

};

#endif

#endif

Associations with a Multiplicity of Many to Many

The code generated here is similar to that created for a one−to−many relationship. With a many−to−many relationship, however, Rose will generate container classes on both ends of the relationship.

Let's look at the code generated for the following relationship:

In this situation, container classes are used at both ends of the relationship. The code that is generated will look something like the following:

interface Class_A {

typedef sequence <Class_B> Class_B_Role_def;

599

Chapter 17: CORBA/IDL Code Generation and Reverse Engineering

attribute Class_B_Role_def Class_B_Role; };

and

interface Class_B {

typedef sequence <Class_A> Class_A_Role_def;

attribute Class_A_Role_def Class_A_Role; };

The complete code generated for Class_A will look exactly as it did in the previous section. The difference is that now the code for Class_B will also include an attribute with a container type. The code generated for Class_B is:

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

#ifndef CLASS_B_DEFINED #define CLASS_B_DEFINED

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

#include "Class_A.idl"

interface Class_B {

typedef sequence <Class_A> Class_A_Roledef; attribute Class_A_Roledef Class_A_Role;

};

#endif

Many−to−Many Associations Generated for Other CORBA Types

The code generated for a many−to−many relationship with other CORBA types will look exactly like the code we examined in the previous section. The only difference is that Class_B will now contain an attribute of type Class_A.

Associations with Bounded Multiplicity

An association with bounded multiplicity is one that has a range of numbers at one end of the relationship. For example, the following relationship has bounded multiplicity:

600

Chapter 17: CORBA/IDL Code Generation and Reverse Engineering

In this example, each instance of Class_A is related to 2–4 instances of Class_B.

The two types of bounded relationships we will examine are bounded associations and fixed associations. Bounded associations have a multiplicity range, like 2..4. Fixed associations have a single number in the multiplicity. For example, a multiplicity of 4 is fixed.

For the example above, Rose will generate something like this:

interface Class_A {

typedef sequence <Class_B, 4> Class_B_Roledef; attribute Class_B_Roledef Class_B_Role;

}; and

interface Class_B {

attribute Class_A Class_A_Role; };

As with one−to−many and many−to−many relationships, Rose uses container classes when generating the attributes. By default, Rose will use a sequence, but you can change the container to an array. You make this change by selecting the CORBA A or CORBA B tab of the relationship specification and then changing the BoundedRoleType property to Array. To change the container class for all bounded relationships, select Tools → Options from the menu. On the CORBA tab, select Role from the drop−down list box. Change the value in the BoundedRoleType property to Array.

Bounded Associations Generated for an Exception

If Class_A is an exception, the code generated will include an attribute to support the relationship to Class_B. In this case, a simplified version of the generated code will look something like this:

Exception Class_A

{

sequence <Class_B, 4> Class_B_Role; };

As with other relationships where the multiplicity is greater than one, Rose will use a sequence as the default container class. To use an array, change the BoundedRoleType property to Array.

601

Chapter 17: CORBA/IDL Code Generation and Reverse Engineering

Bounded Associations Generated for a Structure

The code generated for a structure will include an attribute to support the relationship between Class_A and Class_B. A simplified version of the code is as follows:

Struct Class_A

{

sequence <Class_B, 4> Class_B_Role; };

Again, a sequence is the default container. To use an array instead, you can change the Bounded−RoleType role property to Array.

Bounded Associations Generated for a Union

If Class_A is a union and has a bounded association with Class_B, an attribute will be created in Class_A to support the relationship. By default, the container used in this attribute is a sequence. Here, we have a sequence length of 4.

union Class_A switch(int) {

case 3: sequence <Class_B, 4> Class_B_Role; };

Bounded Associations Generated for Other CORBA/IDL Types

If types other than interface, exception, structure, or union are used, no attributes will be generated to support the relationship. However, #include statements will be placed in both Class_A and Class_B.

Reflexive Associations

A reflexive association is treated much the same as an association between two classes. For the following situation:

code similar to this is generated:

interface Class_A {

typedef sequence <Class_A> RoleAdef; attribute Class_A RoleB;

attribute RoleAdef RoleA;

};

The first two lines support the 0..* end of the relationship. They include a container class that will support this multiplicity. The third line supports the end of the relationship with a multiplicity of one.

The full code generated for Class_A is as follows:

602

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% */

interface Class_A {

typedef sequence <Class_A> RoleAdef;

attribute Class_A RoleB; attribute RoleAdef RoleA;

};

#endif

Reflexive Associations Generated for an Exception

If Class_A is stereotyped as an exception, only one attribute will be generated for the relationship. In this example, an attribute is generated to support the one end of the one−to−many relationship. The code for Class_A is shown below:

//Source file: C:/corba/Class_A.idl #ifndef CLASS_A_DEFINED

#define CLASS_A_DEFINED /* CmIdentification

%X% %Q% %Z% %W% */ exception Class_A { Class_A RoleB;

};

#endif

Reflexive Associations Generated for a Structure

If Class_A is a structure, an attribute will be created inside of it to support the reflexive relationship. If the relationship looks like the previous reflexive association, then the following code will be generated.

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

#ifndef __CLASS_A_DEFINED #define __CLASS_A_DEFINED

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

struct Class_A { Class_A RoleB; };

#endif

Reflexive Associations Generated for a Union

If Class_A is a union, a single attribute will be created inside the class to support the reflexive relationship. The following code is generated for Class_A:

603