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

Terms and Concepts

A note is a graphical symbol for rendering constraints or comments attached to an element or a collection of elements. Graphically, a note is rendered as a rectangle with a dog-eared corner, together with a textual or graphical comment.stereotype is an extension of the vocabulary of the UML, allowing you to create new kinds of building blocks similar to existing ones but specific to your problem. Graphically, a stereotype is rendered as a name enclosed by guillemets (French quotation marks of the form « »), placed above the name of another element.tagged value is a property of a stereotype, allowing you to create new information in an element bearing that stereotype. Graphically, a tagged value is rendered as a string of the form name = value within a note attached to the object.constraint is a textual specification of the semantics of a UML element, allowing you to add new rules or to modify existing ones. Graphically, a constraint is rendered as a string enclosed by brackets and placed near the associated element or connected to that element or elements by dependency relationships. As an alternative, you can render a constraint in a note.

Notes

A note that renders a comment has no semantic impact, meaning that its contents do not alter the meaning of the model to which it is attached. This is why notes are used to specify things like requirements, observations, reviews, and explanations, in addition to rendering constraints.

A note may contain any combination of text or graphics. If your implementation allows it, you can put a live URL inside a note, or even link to or embed another document. In this way, you can use the UML to organize all the artifacts you might generate or use during development, as Figure 6-3 illustrates.

Other Adornments

Adornments are textual or graphical items that are added to an element's basic notation and are used to visualize details from the element's specification. For example, the basic notation for an association is a line, but this may be adorned with such details as the role and multiplicity of each end. In using the UML, the general rule to follow is this: Start with the basic notation for each element and then add other adornments only as they are necessary to convey specific information that is important to your model.

Most adornments are rendered by placing text near the element of interest or by adding a graphic symbol to the basic notation. However, sometimes you'll want to adorn an element with more detail than can be accommodated by simple text or graphics. In the case of such things as classes, components, and nodes, you can add an extra compartment below the usual compartments to provide this information, as Figure 6-4 shows.

Note

Unless it's obvious by its content, it's good practice to name any extra compartment explicitly so that there is no confusion about its meaning. It's also good practice to use extra compartments sparingly, because if overused, they make diagrams cluttered.

Stereotypes

The UML provides a language for structural things, behavioral things, grouping things, and notational things. These four basic kinds of things address the overwhelming majority of the systems you'll need to model. However, sometimes you'll want to introduce new things that speak the vocabulary of your domain and look like primitive building blocks.

A stereotype is not the same as a parent class in a parent/child generalization relationship. Rather, you can think of a stereotype as a metatype (a type that defines other types), because each one creates the equivalent of a new class in the UML's metamodel. For example, if you are modeling a business process, you'll want to introduce things like workers, documents, and policies. Similarly, if you are following a development process, such as the Rational Unified Process, you'll want to model using boundary, control, and entity classes. This is where the real value of stereotypes comes in. When you stereotype an element such as a node or a class, you are in effect extending the UML by creating a new building block just like an existing one but with its own special modeling properties (each stereotype may provide its own set of tagged values), semantics (each stereotype may provide its own constraints), and notation (each stereotype may provide its own icon).

In its simplest form, a stereotype is rendered as a name enclosed by guillemets (for example, «name») and placed above the name of another element. As a visual cue, you may define an icon for the stereotype and render that icon to the right of the name (if you are using the basic notation for the element) or use that icon as the basic symbol for the stereotyped item. All three of these approaches are illustrated in Figure 6-5.

Note

When you define an icon for a stereotype, consider using color as an accent to provide a subtle visual cue (but use color sparingly). The UML lets you use any shape for such icons, and if your implementation permits it, these icons might appear as primitive tools so that users who create UML diagrams will have a palette of things that look basic to them and speak the vocabulary of their domain.

Tagged Values

Every thing in the UML has its own set of properties: classes have names, attributes, and operations; associations have names and two or more ends, each with its own properties; and so on. With stereotypes, you can add new things to the UML; with tagged values, you can add new properties to a stereotype.

You define tags that apply to individual stereotypes so that everything with that stereotype has that tagged value. A tagged value is not the same as a class attribute. Rather, you can think of a tagged value as metadata because its value applies to the element specification, not to its instances. For example, as Figure 6-6 shows, you can specify the required capacity of a server class or require that only one kind of server be used in a given system.

Tagged values are placed in a note attached to the affected element, as shown in Figure 6-7. Each tagged value comprises a string that includes a name (the tag), a separator (the symbol =), and a value (of the tag).

Note

One of the most common uses of tagged values is to specify properties that are relevant to code generation or configuration management. For example, you can use tagged values to specify the programming language to which you map a particular class. Similarly, you can use tagged values to specify the author and version of a component.

Constraints

Everything in the UML has its own semantics. Generalization (usually, if you know what's good for you) implies the Liskov substitution principle, and multiple associations connected to one class denote distinct relationships. With constraints, you can add new semantics or extend existing rules. A constraint specifies conditions that a run-time configuration must satisfy to conform to the model. For example, as Figure 6-8 shows, you might want to specify that, across a given association, communication is secure; a configuration that violates this constraint is inconsistent with the model. Similarly, you might want to specify that among a set of associations connected to a given class, a particular instance may have links of only one association in the set.

Note

Constraints may be written as free-form text. If you want to specify your semantics more precisely, you can use the UML's Object Constraint Language (OCL), described further in

The Unified Modeling Language Reference Manual .

A constraint is rendered as a string enclosed by brackets and placed near the associated element. This notation is also used as an adornment to the basic notation of an element to visualize parts of an element's specification that have no graphical cue. For example, some properties of associations (order and changeability) are rendered using constraint notation.

Standard Elements

The UML defines a number of standard stereotypes for classifiers, components, relationships, and other modeling elements. There is one standard stereotype, mainly of interest to tool builders, that lets you model stereotypes themselves.

You'll use this stereotype when you want to explicitly model the stereotypes you've defined for your project.

Profiles

Often it is useful to define a version of UML tailored to a particular purpose or domain area. For example, if you want to use a UML model for code generation in a particular language, it is helpful to define stereotypes that can be applied to elements to give hints to the code generator (like an Ada pragma). The stereotypes you define would be different for Java and C++, however. As another example, you might want to use UML for modeling databases. Some of the UML capabilities, such as dynamic modeling, are less important, but you want to add concepts such as candidate keys and indexes. You can tailor UML using profiles.

A

profile is a UML model with a set of predefined stereotypes, tagged values, constraints, and base classes. It also selects a subset of the UML element kinds for use so that a modeler is not confused by element kinds that are not needed for the particular application area. A profile defines, in effect, a specialized version of UML for a particular area. Because it is built on ordinary UML elements, it does not represent a new language, and it can be supported by ordinary UML tools.

Most modelers will not construct their own profiles. Most profiles will be constructed by tool builders, framework builders, and similar designers of generic capabilities. Many modelers will use profiles, however. It is the same as traditional subroutine libraries-a few experts built them but many programmers used them. We expect profiles to be constructed for programming languages and databases, for different implementation platforms, for different modeling tools, and for various business domain application areas.