9.3 PropertiesA 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. 9.3.1 TagsA tag is an attribute of a model element and its corresponding value — for example, attributes representing a project's start and end dates. 9.3.1.1 Defining tagsIn 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. Figure 9-4. Defining stereotypes and tags9.3.1.2 Applying tagsIn 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. Figure 9-5. Applying stereotypes and tags9.3.2 ConstraintsA 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. Figure 9-6. Defining stereotypes, tags, and constraints |