A property is a characteristic 1of a model element. Use properties to define attributes and rules for a given type of modeling element. For example, properties can define the following: attributes representing a project’s start and end dates, a specific textual description of the relationship between a project and the things that make up the project, and a rule that the start date must precede the end date.
Properties are shown as a comma-delimited list of text strings inside a pair of braces ({}) after or below the name of a model element. Each property may be expressed in any natural or computer language. Each text string may be a tag or constraint, both of which are discussed in the next sections.
A tag is an attribute of a model element and its corresponding value — for example, attributes representing a project’s start and end dates.
In the UML, you create a tag definition when defining a stereotype by showing a name for the attribute, called a keyword, followed by a colon followed by the type of the attribute. The tags defined for a stereotype apply to each model element to which the stereotype is applied.
For example, Figure 9-4 updates Figure 9-1 and shows a tag named Start
Date
(which is a string representing a
project’s start date), a tag named
End
Date
(which is a string
representing a project’s end date), and a tag named
Descripton
(which is a string representing a
description of the relationship between a project and a thing that
makes up the project). The Start
Date
and End
Date
tags are defined for the
Project
stereotype, and the
Descripton
tag is defined for the
Made
Of
stereotype.
In the UML, applying a
tag (called a
tagged value) is done when applying a stereotype
by showing the name of the attribute followed by an equal sign
followed by its value, together called
a keyword-value
pair. When no equal sign or default value is used, it is
assumed that the keyword represents a Boolean value of
True
, and the absence of the keyword represents a
Boolean value of False
.
For example, Figure 9-5 updates Figure 9-3 using the tags in Figure 9-4, and shows that the Proj Mngmnt Sys
project starts on January 1, 2003 and ends on December
31, 2003. The Java Deployment
project starts on
December 31, 2003 and ends on January 1, 2003, which is obviously
wrong, because the start date is more recent than the end date.
Constraints are used to ensure that such errors are not allowed and
are discussed in the next section. Figure 9-5 also
shows a description for the Proj
Mngmnt Sys
project’s Made
Of
stereotyped link and indicates that the
description for the Java Deployment
project’s Made Of
stereotyped
link is empty or blank.
A constraint is a rule for a model element—for example, a rule that a project’s start date must precede the project’s end date. The rules defined for a stereotype apply to each model element to which the stereotype is applied, and each model element to which the stereotype is applied must adhere to the rules.
In the UML, a constraint is shown when defining a stereotype as a text string that may be expressed using the Object Constraint Language (OCL), which is discussed in Chapter 10. Constraints may also be expressed using pseudocode or another language. For example, you can express a constraint using Java, C++, C#, or some other programming or nonprogramming language.
Figure 9-6 updates Figure 9-4 and shows the following constraint on projects:
The End Date must be on or after the Start Date.
Figure 9-6 also shows the following constraint on the relationships between a project and the things that make up a project:
The Description must not be empty.
According to these rules, the Proj Mngmnt Sys
project described in Figure 9-5 is considered
valid. It’s start date precedes its end date. On the
other hand, the Java
Deployment
project described in Figure 9-5 is considered
invalid or erroneous because it starts
after it ends.