The Unified Modeling Language User Guide SECOND EDITION [Electronic resources] نسخه متنی

Common Modeling Techniques

Modeling Comments

The most common purpose for which you'll use notes is to write down free-form observations, reviews, or explanations. By putting these comments directly in your models, your models can become a common repository for all the disparate artifacts you'll create during development. You can even use notes to visualize requirements and show how they tie explicitly to the parts of your model.

To model a comment,

• Put your comment as text in a note and place it adjacent to the element to which it refers. You can show a more explicit relationship by connecting a note to its elements using a dependency relationship.

• Remember that you can hide or make visible the elements of your model as you see fit. This means that you don't have to make your comments visible everywhere the elements to which it is attached are visible. Rather, expose your comments in your diagrams only insofar as you need to communicate that information in that context.

• If your comment is lengthy or involves something richer than plain text, consider putting your comment in an external document and linking or embedding that document in a note attached to your model.

• As your model evolves, keep those comments that record significant decisions that cannot be inferred from the model itself, andunless they are of historic interestdiscard the others.

For example, Figure 6-9 shows a model that's a work in progress of a class hierarchy, showing some requirements that shape the model, as well as some notes from a design review.

In this example, most of the comments are simple text (such as the note to Mary), but one of them (the note at the bottom of the diagram) provides a hyperlink to another document.

Modeling New Properties

The basic properties of the UML's building blocksattributes and operations for classes, the contents of packages, and so onare generic enough to address most of the things you'll want to model. However, if you want to extend the properties of these basic building blocks, you need to define stereotypes and tagged values.

To model new properties,

• First, make sure there's not already a way to express what you want by using basic UML.

• If you re convinced there's no other way to express these semantics, define a stereotype and add the new properties to the stereotype. The rules of generalization applytagged values defined for one kind of stereotype apply to its children.

For example, suppose you want to tie the models you create to your project's configuration management system. Among other things, this means keeping track of the version number, current check in/check out status, and perhaps even the creation and modification dates of each subsystem. Because this is process-specific information, it is not a basic part of the UML, although you can add this information as tagged values. Furthermore, this information is not just a class attribute either. A subsystem's version number is part of its metadata, not part of the model.

Figure 6-10 shows three subsystems, each of which has been extended with the «versioned» stereotype to include its version number and status.

Note

The values of tags such as version and status are things that can be set by tools. Rather than setting these values in your model by hand, you can use a development environment that integrates your configuration management tools with your modeling tools to maintain these values for you.

Modeling New Semantics

When you create a model using the UML, you work within the rules the UML lays down. That's a good thing, because it means that you can communicate your intent without ambiguity to anyone else who knows how to read the UML. However, if you find yourself needing to express new semantics about which the UML is silent or that you need to modify the UML's rules, then you need to write a constraint.

To model new semantics,

• First, make sure there's not already a way to express what you want by using basic UML.

• If you re convinced there's no other way to express these semantics, write your new semantics in a constraint placed near the element to which it refers. You can show a more explicit relationship by connecting a constraint to its elements using a dependency relationship.

• If you need to specify your semantics more precisely and formally, write your new semantics using OCL.

For example, Figure 6-11 models a small part of a corporate human resources system.

This diagram shows that each Person may be a member of zero or more Teams and that each Team must have at least one Person as a member. This diagram goes on to indicate that each Team must have exactly one Person as a captain and every Person may be the captain of zero or more Teams. All of these semantics can be expressed using simple UML. However, to assert that a captain must also be a member of the same team is something that cuts across multiple associations and cannot be expressed using simple UML. To state this invariant, you have to write a constraint that shows the manager as a subset of the members of the Team, connecting the two associations with a constraint. There is also a constraint that the captain must be a member for at least 1 year.