Architecting Applications for the Enterprise : UML Diagrams (part 2) - Class Diagrams

- How To Install Windows Server 2012 On VirtualBox
- How To Bypass Torrent Connection Blocking By Your ISP
- How To Install Actual Facebook App On Kindle Fire
6/30/2011 4:22:55 PM

2. Class Diagrams

Class diagrams are probably the most widely used UML diagram. You don’t have to be a a huge fan of UML, or an experienced UML user, to have seen and to recognize a class diagram. A class diagram represents the static structure of a system. The static structure of a system is composed of classes and their relationships. Classes are exactly the classes (and interfaces) to be implemented by the development team. Let’s start with a look at the notation.

2.1. A Look at the Notation

From a notational perspective, the class is a rectangle that is usually vertically partitioned in three areas. The top-most rectangle contains the name of the class. The second area lists the attributes of the class. By attributes, we mean properties and fields you want to see defined in the body of the class. Finally, the bottom area contains class operations. By operations, we mean essentially class methods. (See Table 1.)

Table 1. A class description in a class diagram
+WriteToFile(in fileName:string):int

The name of the class can also be qualified by a namespace. In UML, the concept of a namespace (as we know it from the Microsoft .NET Framework) is expressed through the package. To indicate that a class should be defined within a package, you concatenate the names using double colons (::)—for example, System.Data::DataTable.

Characteristics of the class, attributes, and operations are associated with a modifier. Feasible symbols are listed in Table 2.

Table 2. UML Modifiers
+The attribute or operation is public.
-The attribute or operation is private.
#The attribute or operation is protected.

In Table 2, you see a sample class Table with a property Name and a couple of methods: Clear and WriteToFile. All properties and methods are public.

Note that when you define a UML class, you also specify the type of a property and the signature of a method. The class Table schematized in Table 2-8 can be expressed in pure C# as follows:

class Table
public string Name;

public void Clear()

public int WriteToFile(string fileName)

Special font styles indicate a special meaning, too. In particular, if you use the Italic style with an attribute or operation, you indicate you want it to be a virtual member of the class. The Underlined style indicates a static member.

Finally, UML supplies a specific symbol to refer to parameterized types—that is, .NET generic types. The symbol is similar to a conventional class and includes an extra overlapped dashed rectangle with a placeholder for types. (See Figure 7.)

Figure 7. A generic List<T> class in UML

Let’s delve a bit deeper into the syntax and sematics of attributes and relationships.

UML, Java, and the Two of Us

Like it or not, UML is a bit biased by the Java language. You might have suspected this already from the aforementioned use of the term packagenamespace. But there’s more to the story. instead of

According to UML and the Java language, class attributes should be limited to defining fields. So what about properties? In Java, you don’t even have properties; in the .NET Framework, properties are a pinch of syntactic sugar. As you might know, in the .NET Framework properties are implemented through a pair of getter and setter methods. So UML suggests that you use the same approach for properties.

This is the theory; but what about the practice? In our projects, we use attributes for both properties and fields. We employ a sort of de facto standard notation to distinguish fields from properties. Property names are PascalCase, whereas field names are camelCase. And in general, everything we mark as public is a property.

Likewise, in both UML and the Java language you don’t have events. In Java, a different eventing model is used based on your own implementation of the publish/subscribe pattern. In the .NET Framework, events are merely a system-provided implementation of the same pattern, made even simpler by idiomatic language features such as the event keyword in C#.

So in UML, you have no syntax element to define an event as a class attribute. Yet, our .NET classes might require events. What do we do? We simply use attributes of type EventHandler or any other more specific event delegate type. Developers will understand.

2.2. Attributes

As mentioned, attributes indicate fields of a class, but in a pure .NET context we loosely use them to define properties and events, too. Attributes are made of a line of text. The full notation includes the following:

  • Access modifier.

  • Name of the attribute.

  • Type of the attribute. The type can be either a primitive type or a custom type.

  • Multiplicity of the attribute—that is, the number of objects used to define a value for the attribute.

  • Default value (if any) for the attribute.

Here’s a more complete definition for the Name attribute in a Table class:

+ Name: String = String.Empty

This UML definition might become the following C# code:

public string Name = String. Empty;

The multiplicity is a single number, or an interval, that indicates how many values are required to set the attribute. Numbers appear in square brackets. A single number indicates that a single value or instance is required. The previous example can be rewritten as shown here:

+ Name: String [1] = string.Empty

A collection of values is represented with the following notation:

+ Rows: Row [0..5]

In this case, to initialize the Rows attribute, up to six instances of the Row object are required. In C#, you might have the following:

public Row[6] Rows;

You use the asterisk (*) symbol to indicate an unlimited number, as shown here:

+ Rows: Row[0..*] = List<Row>

This corresponds to the following C# code:

public IList<Row> Rows = new List<Row>();

2.3. Operations

In general, operations in a UML class diagram indicate the actions that instances of a class can take. Operations are essentially methods. Here’s the full notation:

  • Access modifier

  • Name of the operation

  • Parameter list (using the comma as the separator)

  • Return type

Each parameter in the list is represented with a notation close to that of attributes, but with an extra prefix, as shown in Table 3.

Table 3. Direction of a Parameter
InInput parameter
OutOutput parameter
InoutInput and output parameter

If unspecified, the direction is assumed to be in. Look at the following operation:

+ WriteToFile(fileName: string, overwriteIfExisting: bool): int

It corresponds to the following C# code:

public int WriteToFile(string filename, bool overwriteIfExisting)

The UML’s out prefix corresponds to the C#’s out keyword, whereas UML’s inout matches C#’s ref keyword. Note that not all languages can accommodate this. Visual Basic .NET. for example, can’t deal with UML’s out prefix directly. To define an output parameter in Visual Basic .NET you have to use the keyword ByRef, which actually corresponds to UML’s inout. In the end, in Visual Basic .NET an output parameter always has to be promoted to an input and output parameter.

2.4. Associations

An association indicates a relationship existing between classes. You can use an association as an alternative syntax to list the properties of a class. In terms of notation, an association is a solid line between classes. Table 4 and Figure 8 express equivalent content.

Table 4. Attributes in the Order class are expressed with a simple notation.
+Customer:Customer +Items[1..*]:OrderItem

Figure 8. Attributes on the Order class expressed via associations

With associations, you can indicate the multiplicity at both ends, and this might make the resulting diagram clearer to read. Because they are logically equivalent, the diagrams in both Table 4 and Figure 8 can be expressed with the following C# code:

class Order
public Customer Customer;
public List<OrderItem> Items;

Two special types of associations are aggregation and composition.

Aggregation specifies a whole/part relationship between two objects, or in other words a has-a relationship. Graphically, it is represented using a connecting line ending with a clear diamond shape on the container class. Figure 9 shows an aggregation where the Order class has a Customer using a one-to-one multiplicity.

Figure 9. Aggregation: the class Order relates to one instance of the Customer class.

Note that in the case of aggregation the contained object is not entirely dependent on the container. If you destroy the container, this might not affect the contained objects. In Figure 9, Order has one and only one Customer, but if the Customer disappears (perhaps goes out of business), the Order remains (perhaps as historical information).

Composition is perhaps a stronger form of aggregation. It specifies that you have a compound object where the container entirely owns the contained object. If you destroy the parent, the children are destroyed as well. You indicate a composition using a connecting line ending with a black diamond shape on the container class. The line can be adorned with multiplicity. (See Figure 10.)

Figure 10. Composition: the class Order owns multiple order items.

2.5. Generalization

The generalization relationship occurs between two classes and indicates that one specializes the other, thus making it a subtype. As you can see, this relationship corresponds to inheritance in C# and other object-oriented languages. The relationship is rendered using a line that ends with a hollow triangle. The line connects the involved classes, and the triangle touches on the parent class, as illustrated in Figure 11.

Figure 11. The relationship generalization between company classes

Generalization defines a relationship of type is-a. With an eye on Figure 11; therefore, we can say that "supplier is a company" and, likewise, that "customer is a company."

2.6. Dependency

A dependency relationship exists between two classes when one class requires another class in order to be implemented. You have a dependency when a change in one class affects the other class.

The notation for a dependency is a dashed line going from the dependent class to the independent class. The line ends with an open arrow touching on the independent class. For example, you might have a line connecting a client to a supplier. This indicates a dependency of the client on the supplier. If you modify the supplier, the client might be broken. (See Figure 12.)

Figure 12. A dependency between a Client class and a Supplier class: the Client depends on the Supplier.


Many UML relationships imply a dependency. For example, a class derived from a parent class is dependent on its base class. Although dependencies between classes (static dependencies) are easy to discover at design time, other forms of dependencies (such as transient relationships) require code inspection or analysis to be discovered.

  •  SharePoint 2010 : Creating and Managing Workflows - Monitoring Workflows
  •  Exchange Server 2010 : Administering Mailbox Content - Monitor and Restrict Communication (part 2) - Apply Common Monitoring and Restriction Scenarios
  •  Exchange Server 2010 : Administering Mailbox Content - Monitor and Restrict Communication (part 1) - Perform Basic Message Policy Configuration
  •  Exchange Server 2010 : Administering Mailbox Content - Protect and Disclose Information
  •  SharePoint 2010 : Workflow Modeling and Development Tools (part 2) - Visual Studio 2010 & Workflow Modeling Tools Comparison
  •  SharePoint 2010 : Workflow Modeling and Development Tools (part 1) - Microsoft Visio 2010 & SharePoint Designer 2010
  •  SharePoint 2010 : Creating and Managing Workflows - Workflows in SharePoint 2010
  •  Exchange Server 2010 : Meet Message Retention Compliance (part 3) - Keep a Record of Email Communications
  •  Exchange Server 2010 : Meet Message Retention Compliance (part 2) - Archive Email
  •  Exchange Server 2010 : Meet Message Retention Compliance (part 1) - Enforce Records Management
    Top 10
    - Microsoft Visio 2013 : Adding Structure to Your Diagrams - Finding containers and lists in Visio (part 2) - Wireframes,Legends
    - Microsoft Visio 2013 : Adding Structure to Your Diagrams - Finding containers and lists in Visio (part 1) - Swimlanes
    - Microsoft Visio 2013 : Adding Structure to Your Diagrams - Formatting and sizing lists
    - Microsoft Visio 2013 : Adding Structure to Your Diagrams - Adding shapes to lists
    - Microsoft Visio 2013 : Adding Structure to Your Diagrams - Sizing containers
    - Microsoft Access 2010 : Control Properties and Why to Use Them (part 3) - The Other Properties of a Control
    - Microsoft Access 2010 : Control Properties and Why to Use Them (part 2) - The Data Properties of a Control
    - Microsoft Access 2010 : Control Properties and Why to Use Them (part 1) - The Format Properties of a Control
    - Microsoft Access 2010 : Form Properties and Why Should You Use Them - Working with the Properties Window
    - Microsoft Visio 2013 : Using the Organization Chart Wizard with new data
    - First look: Apple Watch

    - 3 Tips for Maintaining Your Cell Phone Battery (part 1)

    - 3 Tips for Maintaining Your Cell Phone Battery (part 2)
    programming4us programming4us