Stereotypes and Model Properties

The next step is to study how the model is prepared for code generation. Most of the implementation details of the Visual Basic code are specified in the class, relationship, and method dialogs, but some detailed implementation decisions, specific to the Visual Basic programming language, must be entered as stereotypes or model properties of the model elements.

Note   Other words for "model properties" are "code generation properties" or "code generation options".

Examining Class Stereotypes

The stereotype of a class is used to indicate a mapping to which type of Visual Basic project item the class corresponds. When generating code for a class, Visual Modeler creates a Visual Basic item of the specified type.

To examine the stereotype of a class:

1. In the browser, expand User Services, and double-click on the dlg_Order class. The specification for the class then opens with the General tab displayed.

   

2. As you can see, the stereotype is set to "Form". Thus, the dlg_Order class represents a form in the corresponding Visual Basic project. To get a list of other class stereotypes, click the arrow in the Stereotype field.
   
   
3. Now, close the specification for dlg_Order.

Note   Visual Modeler can reverse engineer most types of Visual Basic items, but the application cannot generate code for all types. For example, Visual Modeler can reverse engineer forms but not generate them.

Examining Naming Conventions

To examine the naming convention for a relationship:

1. Open the specification of the Order class by double clicking on the class.
   
   
2. Select the Relations tab.
   
   
3. Double-click on pOrderrows to open the specification of that relationship. Note that relationships have two code generation tabs, Visual Basic A and Visual Basic B, one for each role.
   
   
4. Select the Visual Basic A tab to view the model properties for role A.

   

5. Take a look at the value of DataMemberName, which is "$relationship". This value means that the generated Visual Basic property will get the same name as the relationship, that is Orderrows.
   
   
6. Also, note that NameIfUnlabeled is set to "the$supplier". This setting instructs the code generator to generate the variable name theOrderRow if the role is unnamed. In this particular case, role A is named Orderrows, so this option is not activated.
   
   
7. To reuse specific model property settings between classes, Visual Modeler lets you define model property sets and attach a whole set to a class. In the Set field you can see that the "default" model property set is currently attached to this role. Also, in the Source field you can see that the values of all model properties, except NameIfUnlabeled, override the attached set, but the value of NameIfUnlabeled is the default value.
   
   
8. Close the specifications.
   
   
9. Close the Visual Modeler application by choosing Exit from the File menu.