Home arrow Practices arrow Page 3 - Classes

Attribute and Operation Details - Practices

In this article you will learn about the Unified Modeling Language (UML) by examining basic modeling of things and concepts in the real world. It is excerpted from the book Fast Track UML 2.0, written by Kendall Scott (Apress, 2004; ISBN: 1590593200)

  1. Classes
  2. Discovering Classes
  3. Attribute and Operation Details
  4. Abstract Classes
  5. Internal Class Structure
  6. Other Stereotypes on Classes
By: Apress Publishing
Rating: starstarstarstarstar / 11
April 27, 2005

print this article



The UML offers a variety of constructs that allow you to specify details for attributes and operations. These constructs are discussed in the following subsections.


Encapsulation is the principle of data hiding: An object hides its data from the rest of the world and only lets outsiders manipulate that data by way of calls to the object’s methods. The degree to which the elements of a class are encapsulated within that class depends on the level of visibility that’s been assigned to the elements. The visibility of an attribute or an operation specifies whether objects that belong to other classes can “see” that attribute or operation.

The UML supports the following four levels of visibility:

  • Package visibility (shown with a tilde [~]) means that objects belonging to any class in the same package as the given class can see and use the given class it. (Packages are discussed in Chapter 5.)

  • Public visibility (+) means that objects belonging to any class can use the given attribute or operation.

  • Protected visibility (#) means that only objects that belong to subclasses of the given class (at any level below that class) can use the attribute or operation. (Subclasses are discussed in Chapter 2.)

  • Private visibility (–) means that only objects belonging to the class itself can use the attribute or operation.

Figure 1-6 shows visibility adornments on example attributes and operations.

Figure 1-6Visibility

The assignRating operation of the CustomerReview class is public, which means that objects of any other class can use it. The record operation of Review is protected, so CustomerReview objects and EditorialReview objects can use it, and objects of any subclasses of those two classes would be able to use it as well, but objects of classes outside that hierarchy cannot use record. The emailAddress, ID, and password attributes of Account are private: Only Account objects have access to these attributes. Similarly, CustomerReview objects are the only ones that can use the computeAvgRating operation.

NOTE The Review class and its record operation are abstract. Abstract classes and operations, which appear in italics to differentiate them from “concrete” classes and operations, are discussed in the section “Abstract Classes,” later in this chapter.

More About Attributes

The full form of a UML attribute declaration is as follows:

[ visibility] [/] name [: type] [ multiplicity] [= default] [{ property-string}]

The rectangular brackets surround optional items, which means that only the name is required. However, UML diagrams generally show details about attributes once serious design work commences on a project.

Visibility was discussed in the previous section. A forward slash appearing before the name of the attribute means that a value of the attribute can be derived from the values of one or more other attributes. For instance, if an object has an attribute named dateOfBirth and another attribute named age, the value of the latter attribute could be computed based on the value of the former.

Examples of built-in attribute data types include Double, Int (short for Integer), and String (which appeared in Figure 1-3). An attribute type can also be a user-defined type or the name of a class.

Multiplicity indicates how many of one thing can exist relative to another thing. A multiplicity expression can take several forms, including the following:

  • A fixed value (such as 1 or 3)

  • An asterisk (*), which means “many”

  • A range of values, expressed as lower..upper (for instance, 0..1 or 3..*)

  • A set of values (for example, [1, 3, 5, 7])

A multiplicity value on an attribute indicates how many instances of that attribute are present for each instance of the class. The multiplicity of an attribute appears between square brackets after the attribute name.

A default value of an attribute for a class means that each instance of that class has that initial value for the given attribute.

The most important property you can attach to an attribute declaration is readOnly, which indicates that you can add possible values for the attribute, but you can’t change existing values.

Figure 1-7 shows details of some of the attributes of an example class.

Figure 1-7Attribute details

NOTE An object belonging to the Account class can have from one to three email addresses. Each Account object has an ID that can’t be deleted; you might think of this as being the equivalent of the key within a database table. And, there’s an initial value for an Account object’s password, which the Customer is likely to change but which is useful in case the Customer forgets to define a password when he or she sets up an Account.

More About Operations

The full form of a UML operation declaration is as follows:

[ visibility] name [( parameter-list)] [{ property-string}]

As with attributes, the rectangular brackets surround optional items.

A discussion of visibility appeared earlier in this chapter. The parameters of an operation, which appear in a list separated by commas, represent the data provided by the caller of the operation, the data that the operation returns to the caller, or both. The full form of a parameter declaration is as follows:

[ direction] name : type [ multiplicity] [ = default-value]

A parameter can have one of the following three directions:

  • in (The operation can’t modify the parameter, so the caller doesn’t need to see it again.)

  • out (The operation sets or changes the value of the parameter and returns it to the caller.)
  • inout (The operation uses the value of the parameter and may change the value; the caller expects to see an inout parameter again.)

Types work the same way for parameters as they do for attributes. See the section “More About Attributes,” earlier in this chapter, for a discussion of multiplicity. A default value of a parameter for an operation means that each call to that operation includes that value for the given parameter.

One property that you can attach to an operation declaration is isQuery, which indicates that the operation doesn’t change the values of any attributes. There are three other properties that relate to concurrency, which has to do with how a method that implements a given operation responds in the context of multiple threads of activity. The three possible concurrency values are as follows:

  • concurrent (Multiple method calls, from multiple threads, may come in simultaneously to the method, and these calls can all proceed concurrently.)

  • guarded (Multiple calls may come in simultaneously, but only one can pro ceed at a time.)

  • sequential (Only one call may come in at a time.)

Figure 1-8 shows some details of operations belonging to an example class.

Figure 1-8.  Operation details

The checkAvailability operation receives a Book object (see Figure 1-3) and returns a value of the user-defined type OrderStatus. The isFulfilled operation is a query that returns True if everything the customer ordered is in place or False otherwise.

You can add precision to your modeling of operations by indicating con straints, which specify conditions that must hold true in a given context. You show a constraint as a Boolean expression between curly brackets.

NOTE The UML defines a separate language, called the Object Constraint Language (OCL), that you can use to specify constraints. Using the OCL enables you to reach a certain level of rigor in your modeling without side effects. In other words, the evaluation of OCL expressions can’t alter the state of the executing system. See The Object Constraint Language5 for more information about the OCL.

Two kinds of constraints are of particular interest in the context of operations: preconditions and postconditions.

A precondition specifies a condition that must hold true before an operation starts executing. Figure 1-9 shows an example of a precondition contained within a note, which you can use to record comments about a model without affecting the content of the model.

Figure 1-9Precondition

Note that the triangular brackets (called guillemets) around the word precon dition indicate the presence of a stereotype. This is a mechanism for building a modeling construct that isn’t identified in the core UML but that’s similar to things that are part of the core. Stereotypes of various kinds appear throughout this book; some of them are built in to the UML, while others are user defined.

A postcondition specifies a condition that must hold true before an operation starts executing. Figure 1-10 shows an example of a postcondition.

Figure 1-10Postcondition


You can also specify which exceptions a given operation raises. One way to do this is to create a note with «exception» at the top followed by a list of exception types relevant to the operation. (You read about other ways to specify exceptions in Chapter 6.)

>>> More Practices Articles          >>> More By Apress Publishing

blog comments powered by Disqus
escort Bursa Bursa escort Antalya eskort


- Calculating Development Project Costs
- More Techniques for Finding Things
- Finding Things
- Finishing the System`s Outlines
- The System in So Many Words
- Basic Data Types and Calculations
- What`s the Address? Pointers
- Design with ArgoUML
- Pragmatic Guidelines: Diagrams That Work
- Five-Step UML: OOAD for Short Attention Span...
- Five-Step UML: OOAD for Short Attention Span...
- Introducing UML: Object-Oriented Analysis an...
- Class and Object Diagrams
- Class Relationships
- Classes

Developer Shed Affiliates


Dev Shed Tutorial Topics: