Section 4.4. Class State: Attributes

4.4. Class State: Attributes

A class's attributes are the pieces of information that represent the state of an object. These attributes can be represented on a class diagram either by placing them inside their section of the class boxknown as inline attributes or by association with another class, as shown in Figure 4-11. Associations are covered in more detail in Chapter 5.

Figure 4-11. The BlogAccount class contains two inlined attributes, name and publicURL, as well as an attribute that is introduced by the association between the BlogAccount and BlogEntry classes

It doesn't matter if you are declaring an inline or associated attribute. At a minimum, your attribute will usually have a signature that contains a visibility property, a name, and a type, although the attribute's name is the only part of its signature that absolutely must be present for the class to be valid.

4.4.1. Name and Type

An attribute's name can be any set of characters, but no two attributes in the same class can have the same name. The type of attribute can vary depending on how the class will be implemented in your system but it is usually either a class, such as String, or a primitive type, such as an int in Java.

Choosing Attribute Names

Remember, one of the primary aims of modeling your system is to communicate your design to others. When picking names of attributes, operations, classes, and packages, make sure that the name accurately describes what is being named. When naming attributes, it's worth trying to come up with a name that describes the information that the attribute represents.

Also, if your class is to be implemented in a specific software language, check to make sure that the name meets the conventions of that language. In Java, it is common to use an uppercase character for each word in your class's names, e.g., BlogAccount, while Java packages are usually named all in lowercase (see Chapter 13).

In Figure 4-11, the name attribute is declared as private (indicated by the minus (-) sign at the beginning of the signature) and after the colon, the type is specified as being of the class String. The associated entries attribute is also private, and because of that association, it represents a number of instances of the BlogEntry class.

If the BlogAccount class in Figure 4-11 was going to be implemented as a Java class in software, then the source code would look something like that shown in Example 4-1.

Example 4-1. Java inline and by-association attributes

 public class BlogAccount {    // The two inline attributes from Figure 4-11.    private String name;    private URL publicURL;      // The single attribute by association, given the name 'entries'    BlogEntries[] entries;      // ... } 

It's pretty clear how the two inline attributes are implemented in the BlogAccount Java class; the name attribute is just a Java String and the publicURL attribute is a Java URL object. The entries attribute is a bit more interesting since it is introduced by association. Associations and relationships between classes are covered in Chapter 5.

4.4.2. Multiplicity

Sometimes an attribute will represent more than one object. In fact, an attribute could represent any number of objects of its type; in software, this is like declaring that an attribute is an array. Multiplicity allows you to specify that an attribute actually represents a collection of objects, and it can be applied to both inline and attributes by association, as shown in Figure 4-12.

Figure 4-12. Applying several flavors of attribute multiplicity to the attributes of the BlogAccount and BlogEntry classes

In Figure 4-12, the trackbacks, comments, and authors attributes all represent collections of objects. The * at the end of the trackbacks and comments attributes specifies that they could contain any number of objects of the TRackback and Comment class, respectively. The authors attribute is a little more constrained since it specifies that it contains between one and five authors.

The enTRies attribute that is introduced using an association between the BlogAccount class and the BlogEntry class has two multiplicity properties specified at either end of the association. A * at the BlogEntry class end of the association indicates that any number of BlogEntry objects will be stored in the enTRies attribute within the BlogAccount class. The 1 specified at the other end of the association indicates that each BlogEntry object in the enTRies attribute is associated with one and only one BlogAccount object.

Those with a keen eye will have also noticed that the trackbacks, comments, and entries attributes also have extra properties to describe in even more detail what the multiplicity on the attributes means. The TRackbacks attribute represents any number of objects of the TRackback class, but it also has the unique multiplicity property applied to it. The unique property dictates that no two TRackback objects within the array should be the same. This is a reasonable constraint since we don't want an entry in another blog cross-referencing one of our entries more than once; otherwise the list of TRackbacks will get messy.

By default, all attributes with multiplicity are unique. This means that, as well as the trackbacks attribute in the BlogEntry class, no two objects in the authors attributes collection in the BlogAccount class should be the same because they are also declared unique. This makes sense since it specifies that a BlogAccount can have up to five different authors; however, it wouldn't make sense to specify that the same author represents two of the possible five authors that work on a blog! If you want to specify that duplicates are allowed, then you need to use the not unique property, as used on the comments attribute in the BlogEntry class.

The final property that an attribute can have that is related to multiplicity is the ordered property. As well as not having to be unique, the objects represented by the comments attribute on the BlogEntry class need to be ordered. The ordered property is used in this case to indicate that each of the Comment objects is stored in a set order, most likely in order of addition to the BlogEntry. If you don't care about the order in which objects are stored within an attribute that has multiplicity, then simply leave out the ordered property.

4.4.3. Attribute Properties

As well as visibility, a unique name, and a type, there is also a set of properties that can be applied to attributes to completely describe an attribute's characteristics.

Although a complete description of the different types attribute properties is probably a bit beyond this bookalso, some of the properties are rarely used in practiceit is worth looking at what is probably the most popular attribute property: the readOnly property.

Other properties supported by attributes in UML include union, subsets, redefines, and composite. For a neat description of all of the different properties that can be applied to attributes, check out UML 2.0 in a Nutshell (O'Reilly).

If an attribute has the readOnly property applied, as shown in Figure 4-13, then the value of the attribute cannot be changed once its initial value has been set.

Figure 4-13. The createdBy attribute in the ContentManagementSystem class is given a default initial value and a property of readOnly so that the attribute cannot be changed throughout the lifetime of the system

If the ContentManagementSystem class were to be implemented in Java source code, then the createdBy attribute would be translated into a final attribute, as shown in Example 4-2.

Example 4-2. Final attributes in Java are often referred to as constants since they keep the same constant value that they are initially set up with for their entire lifetime

 public class ContentManagementSystem {    private final String createdBy = "Adam Cook Software Corp."; } 

4.4.4. Inline Attributes Versus Attributes by Association

So, why confuse things with two ways of showing a class's attributes? Consider the classes and associations shown in Figure 4-14.

Figure 4-14. The MyClass class has five attributes, and they are all shown using associations

When attributes are shown as associations, as is the case in Figure 4-14, the diagram quickly becomes busyand that's just to show the associations, nevermind all of the other relationships that classes can have (see Chapter 5). The diagram is neater and easier to manage with more room for other information when the attributes are specified inline with the class box, as shown in Figure 4-15.

Figure 4-15. The MyClass class's five attributes shown inline within the class box

Choosing whether an attribute should be shown inline or as an association is really a question of what the focus of the diagram should be. Using inline attributes takes the spotlight away from the associations between MyClass and the other classes, but is a much more efficient use of space. Associations show relationships between classes very clearly on a diagram but they can get in the way of other relationships, such as inheritance, that are more important for the purpose of a specific diagram.

One useful rule of thumb: "simple" classes, such as the String class in Java, or even standard library classes, such as the File class in Java's io package, are generally best shown as inline attributes.