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

Chapter 15: Visual Basic Code Generation and Reverse Engineering

Again we have the Passenger and FrequentFlyerAccount classes, but this time the relationship is unidirectional. An attribute will be created inside Passenger, but not inside FrequentFlyerAccount. The following lines of code are from Passenger:

'##ModelId=39614F990350

Private Account As FrequentFlyerAccount

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.

The code generated in the supplier class includes all of the code lines discussed in the previous section about bidirectional associations. With a bidirectional association, each class is given a new attribute, and the code discussed in the previous section is included in both classes. With a unidirectional association, the code is included only in the client class.

Again, 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.

In this case, we have a one−to−many relationship. As we saw in the previous section, Flight can simply generate an attribute that is a reference to Passenger. However, a simple attribute in the Flight class won't be enough. Instead, the attribute generated in Flight must use a sort of container class or an array as its data type. (Rose will use a collection as the default.) The following code is generated in the Flight class:

'##ModelId=396154B0001F Public Passenger As Collection

Rose provides you with the Collection type as a container class. If you would rather, you can use an array by specifying the Subscript role property. To do so, open the specification window for the relationship and select the Visual Basic A or Visual Basic B tab. Then specify a value for the Subscript code−generation property. Here, we use a subscript of 3:

'##ModelId=396154B0001F

Public Passenger(3) As Passenger

Associations with a Multiplicity of Many to Many

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

534

Chapter 15: Visual Basic Code Generation and Reverse Engineering

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 two classes.

First, the Flight class will contain:

'##ModelId=396154B0001F Public Passenger As Collection

Next, the Passenger class will contain:

'##ModelId=396154B00021 Public Flight As Collection

Again, Rose uses a collection class as the default container, but you can change this to an array by modifying the Subscript code−generation property in the relationship specification window.

Reflexive Associations

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

this code is generated:

'##ModelId=3961578B0369

Public NewProperty As Collection

As with a regular association, an attribute is created inside the class to support the relationship. If the multiplicity is one, a simple attribute is created. If the multiplicity is more than one, a container class is used.

As you can see, the code generated here is very similar to the code generated in a typical one−to−many relationship. In this situation, Class A contains an attribute of type Collection.

Aggregations

There are two types of aggregation relationships: by value and by reference. With a by−value relationship, one class contains another. With a by−reference relationship, one class contains a reference to another. Both

535

Chapter 15: Visual Basic Code Generation and Reverse Engineering

of these types of relationships are generated identically in Rose Visual Basic.

The code generated for an aggregation relationship is the same as the code generated for an association relationship. Let's look at an example:

The aggregation relationship tells us that, conceptually, a fleet is made up of many aircraft. When we generate code, however, Rose doesn't care whether there is an association or an aggregation between the classes. The Fleet class will contain a collection of Airplanes:

'##ModelId=396159720233

Public NewProperty As Collection

Dependency Relationships

With a dependency relationship, no attributes are created. If there is a dependency between ClassA and ClassB, no attributes will be created in either ClassA or ClassB.

Generalization Relationships

A generalization relationship in UML becomes an inheritance relationship in object−oriented languages. However, Visual Basic does not support inheritance. Instead, a generalization can become an implements delegation in Visual Basic. In your Rose model, a generalization relationship is shown as follows:

No special code will be inserted into the parent class. This allows it to be reusable and independent of the child class.

The child class contains three special areas of code. First, an Implements Parent statement is added. Second, an instance of the parent class is created inside the child class. Finally, copies of the parent's public methods are inserted into the child class.

Option Explicit

536