Custom UML Stereotypes for .NET Distributed Systems

Chapter 7 - Distributed System Design
byAndrew Filevet al.?
Wrox Press ©2002

	Team FLY

In previous sections, we saw that the .NET infrastructure for distributed systems introduces many programming constructs. Some of those constructs like a Remoting type's Activation mode have no direct mappings in UML. In this section, we'll show you how to extend UML in Visio when the need arises by using .NET Remoting activation mode as an example. We will extend the UML model elements by defining a stereotype called RemotingType for modeling .NET Remoting types.

UML Model Elements for Extension

Extending UML is a very common and necessary practice because of UML's nature of being a general modeling language. In fact, it is so common and necessary that UML is specified with extensibility at its heart. The key model elements in UML for extensibility are: Stereotype, TagDefinition, TaggedValue, and Constraint. If you package a custom set of these model elements defined for a special purpose, that package is called a UML profile. Although we'll briefly cover the basics of those model elements momentarily, we are not going to give detailed and rigorous explanations of the terms like Stereotype, TagDefinition, profile, etc. Readers can refer to the UML Specification (version 1.4, section 2.6 Extension Mechanisms) for strict definitions of those terms. Here is a quick list of some facts about Stereotype, TagDefinition, TaggedValue, and Constraint.

• A stereotype (an instance of Stereotype) is used to add additional properties and constraints to other model elements.

• A stereotype can have multiple TagDefinition instances and multiple Constraint instances.

• A TagDefinition instance (a tag) has a tag name and some tag values.

• Tag values are instances of the TaggedValue model element.

• A tag depending on its multiplicity attribute may have multiple tag values.

• A tag has a tagType attribute and a multiplicity attribute.

• The tagType attribute of a tag specifies the data type of the tag's value.

Overleaf is a figure that shows the declaration of the stereotype we'll create in Visio. The figure gives us a lot of information about the stereotype. First, the name of the stereotype is RemotingType. The stereotype is used to brand the Class model element. In plain words, the stereotype is to used to brand C# classes that are modeled as instances of the UML Class model element. The Class model element in this context is also called the base class of the stereotype. From the figure, we can also tell that the stereotype has a tag (an instance of TagDefinition) called ActivationMode in the Tags compartment. Information about the ActivationMode tag is not fully shown in the figure. The figure shows that the tagType attribute, that is, the data type of the tag's value, of ActivationMode is String. What's not shown here in the figure is the ActivationMode's multiplicity attribute, which should be set to 1 in this case since a .NET Remoting type can have only one activation mode. The stereotype has a constraint as seen in the Constraints compartment. The constraint says that the value of the ActivationMode tag can only be one of the three values: Singleton, SingleCall, or Client-Activated.

Create Custom Stereotype in Visio

Now it is time to see how to create a custom stereotype specific to .NET Remoting in Visio. Open the UML solution we created earlier if it hasn't been opened. To create a custom stereotype, select the UML menu, and then click on Stereotypes.... In the pop-up UML Stereotypes window, click the New button and you'll see a new row is added to the table of existing stereotypes. Click on the new row to make it the active row and then click the Properties... button. The UML Stereotype Properties window pops up. This window is the place where we tell Visio everything about our RemotingType stereotype. A screenshot of the UML Stereotype Properties window is shown below.

To change the name of the Stereotype to RemotingType, select Stereotype in the Categories column and type RemotingType in the Name field. In the Base Class field, click on the drop-down button and select Class. Don't worry about the value in the Full path field if it does not reflect the changes you make to the Name field. The next time you open up the UML Stereotype Properties windows for the RemotingType stereotype, it will show the correct value.

To specify the tags of the RemotingType, select Required Tagged Values if the tag is mandatory or Tagged Values if the tag is optional in the Categories column. Because we want users of the RemotingType stereotype to specify the activation modes of their .NET Remoting types every time they use the stereotype, we made the decision that the ActivationMode tag is mandatory. So select Required Tagged Values in the Categoriescolumn and then click on the New button on the right-hand side to add a new mandatory tag. The UML Tagged Value Properties window pops up. Type ActivationMode in the Tag field. In the Value field, type Singleton, SingleCall or Client-Activated. After completing the above settings, click the OK button to confirm the change. After making the changes, you should see the equivalent of the following screenshot on your computer. Notice that the string we type in the value field is not necessary. You can actually leave the field blank. We chose to type in the string because as we'll see later when branding a type with the RemotingType stereotype, the string in this case serves as a reminder of what values are valid. Notice also that there's no field for us to specify the two attributes, multiplicity and tagType, of the ActivationMode tag in Visio.

To specify the constraints of the RemotingType stereotype, select Constraints in the Categories column and then click the New button on the right-hand side to add a new constraint. A row is added to the Constraints table after you click the New button. Make the row the active row by clicking on it. Then click on the Properties... button.The UML Constraint Properties window pops up. A screenshot of the window is shown overleaf. Fill in the Name field with ActivationMode Value Constraint. Fill in the Body field with ActivationMode should be Singleton, SingleCall, or Client-Activated. Leave the Stereotype field blank as none of the stereotypes listed in the drop-down list is relevant to our constraint. Leave the Documentation fields blank or type whatever you want to say about the constraint for documentation purposes. For the Language field, click the drop-down button and select Text since we are using plain text to express our constraint in the Body field.

The RemotingType stereotype is all set. Click the OK buttons to dismiss the pop-up windows. At this point, you can test the stereotype by dragging the Class shape from the UML Static Structure stencil and dropping it in the drawing area. Double-click on the shape to bring up the UML Class Properties window. Select Class in the Categories column. Then click on the drop-down list button of the Stereotype field. There you'll see our newly created RemotingType appear on the list. If you select RemotingType as the stereotype for the Class shape and then select Tagged Values in the Categories column, you'll see the ActivationMode tag appear in the Tags list box. (If you don't see the ActivationMode tag, you might have to close the window and reopen it again.) Select the ActivationMode tag in the Tags list box and set its value in the Tag ActivationMode value text box below.

After branding the Class shape with the RemotingType stereotype, the Class shape will look like the one shown below if you set the value of ActivationMode to Singleton. If you don't see the tag value, {ActivationMode = Singleton}, appear in the Name compartment of the Class shape, you have to make it visible by right-clicking on the Class shape, select Shape Display Options... in the pop-up menu, and in the UML Shape Display Options window that pops up, check the Properties checkbox under the General options group.

	Team FLY