Advanced Classes

Classes are indeed the most important building block of any object-oriented system. However, classes are just one kind of an even more general building block in the UML, classifiers. A classifier is a mechanism that describes structural and behavioral features. Classifiers include classes, interfaces, datatypes, signals, components, nodes, use cases, and subsystems.

Classifiers (and especially classes) have a number of advanced features beyond the simpler properties of attributes and operations described in the previous section: You can model multiplicity, visibility, signatures, polymorphism, and other characteristics. In the UML, you can model the semantics of a class so that you can state its meaning to whatever degree of formality you like.

Early in a project, it's sufficient to say that you'll include a Customer class that carries out certain responsibilities. As you refine your architecture and move to construction, you'll have to decide on a structure for the class (its attributes) and a behavior (its operations) that are sufficient and necessary to carry out those responsibilities. Finally, as you evolve to the executable system, you'll need to model details, such as the visibility of individual attributes and operations, the concurrency semantics of the class as a whole and its individual operations, and the interfaces the class realizes.

The UML provides a representation for a number of advanced properties, as below figure shows. This notation permits you to visualize, specify, construct, and document a class to any level of detail you wish, even sufficient to support forward and reverse engineering of models and code.

A classifier is a mechanism that describes structural and behavioral features. Classifiers include classes, interfaces, datatypes, signals, components, nodes, use cases, and subsystems.

Classifiers

When you model, you'll discover abstractions that represent things in the real world and things in your solution. For example, if you are building a Web-based ordering system, the vocabulary of your project will likely include a Customer class (representing people who order products) and a Transaction class (an implementation artifact, representing an atomic action). In the deployed system, you might have a Pricing component, with instances living on every client node. Each of these abstractions will have instances; separating the essence and the instance of the things in your world is an important part of modeling.

Some things in the UML don't have instances for example, packages and generalization relationships. In general, those modeling elements that can have instances are called classifiers (associations and messages can have instances as well, but their instances are not quite the same as the instances of a class). Even more important, a classifier has structural features (in the form of attributes), as well as behavioral features (in the form of operations). Every instance of a given classifier shares the same features.

Classes are not the only kind of classifier, however. The UML provides a number of other kinds of classifiers to help you model:

Graphically, the UML distinguishes among these different classifiers, as shown below:

Visibility

One of the most important details you can specify for a classifier's attributes and operations is its visibility. The visibility of a feature specifies whether it can be used by other classifiers. In the UML, you can specify any of three levels of visibility.

Below figure shows a mix of public, protected, and private figures for the class Toolbar:

Scope

Another important detail you can specify for a classifier's attributes and operations is its owner scope. The owner scope of a feature specifies whether the feature appears in each instance of the classifier or whether there is just a single instance of the feature for all instances of the classifier. In the UML, you can specify two kinds of owner scope.

As below figure (a simplification of the first figure) shows, a feature that is classifier scoped is rendered by underlining the feature's name. No adornment means that the feature is instance scoped.

Abstract, Root, Leaf and Polymorphic Elements

You use generalization relationships to model a lattice of classes, with more-generalized abstractions at the top of the hierarchy and more-specific ones at the bottom. Within these hierarchies, it's common to specify that certain classes are abstract - meaning that they may not have any direct instances. In the UML, you specify that a class is abstract by writing its name in italics. For example, as below figure shows, Icon, RectangularIcon, and ArbitraryIcon are all abstract classes. By contrast, a concrete class (such as Button and OKButton) is one that may have direct instances.

You can also specify that a class may have no children. Such an element is called a leaf class and is specified in the UML by writing the property leaf below the class's name. For example, in the figure, OKButton is a leaf class, so it may have no children.

Less common but still useful is the ability to specify that a class may have no parents. Such an element is called a root class, and is specified in the UML by writing the property root below the class's name. For example, in the figure, Icon is a root class.

Operations have similar properties. Typically, an operation is polymorphic, which means that, in a hierarchy of classes, you can specify operations with the same signature at different points in the hierarchy. Ones in the child classes override the behavior of ones in the parent classes. When a message is dispatched at run time, the operation in the hierarchy that is invoked is chosen polymorphically, that is, a match is determined at run time according to the type of the object. For example, display and isInside are both polymorphic operations. Furthermore, the operation Icon::display() is abstract, meaning that it is incomplete and requires a child to supply an implementation of the operation. In the UML, you specify an abstract operation by writing its name in italics, just as you do for a class. By contrast, Icon::getID() is a leaf operation, so designated by the property leaf. This means that the operation is not polymorphic and may not be overridden.

Multiplicity

Whenever you use a class, it's reasonable to assume that there may be any number of instances of that class. Sometimes, though, you'll want to restrict the number of instances a class may have. Most often, you'll want to specify zero instances (in which case, the class is a utility class that exposes only class scoped attributes and operations), one instance (a singleton class), a specific number of instances, or many instances (the default case).

The number of instances a class may have is called its multiplicity. Multiplicity is a specification of the range of allowable cardinalities an entity may assume. In the UML, you can specify the multiplicity of a class by writing a multiplicity expression in the upper-right corner of the class icon. For example, in below figure, NetworkController is a singleton class. Similarly, there are exactly three instances of the class ControlRod in the system.

Multiplicity applies to attributes, as well. You can specify the multiplicity of an attribute by writing a suitable expression in brackets just after the attribute name. For example, in the figure, there are two or more consolePort instances in the instance of NetworkController.

Attributes

At the most abstract level, when you model a class's structural features (that is, its attributes), you simply write each attribute's name. That's usually enough information for the average reader to understand the intent of your model. As the previous sections have described, however, you can also specify the visibility, scope, and multiplicity of each attribute. There's still more. You can also specify the type, initial value, and changeability of each attribute.

You can also use stereotypes to designate sets of related attributes, such as housekeeping attributes. In its full form, the syntax of an attribute in the UML is:

[visibility] name [multiplicity] [: type]

[= initial-value] [{property-string}]

For example, the following are all legal attribute declarations:

There are three defined properties that you can use with attributes:

Unless otherwise specified, attributes are always changeable.

Operations

At the most abstract level, when you model a class's behavioral features (that is, its operations and its signals), you will simply write each operation's name. That's usually enough information for the average reader to understand the intent of your model. However, you can also specify the visibility and scope of each operation. There's still more: You can also specify the parameters, return type, concurrency semantics, and other properties of each operation. Collectively, the name of an operation plus its parameters (including its return type, if any) is called the operation's signature.

In its full form, the syntax of an operation in the UML is:

[visibility] name [(parameter-list)]

[: return-type] [{property-string}]

For example, the following are all legal operation declarations:

In an operation's signature, you may provide zero or more parameters, each of which follows the syntax:

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

Direction may be any of the following values:

In addition to the leaf property described earlier, there are four defined properties that you can use with operations:

Standard Elements

All of the UML's extensibility mechanisms apply to classes. Most often, you'll use tagged values to extend class properties (such as specifying the version of a class) and stereotypes to specify new kinds of components (such as model- specific components).

The UML defines four standard stereotypes that apply to classes:

Common Modeling Techniques

Modeling the Semantics of a Class

To model the semantics of a class, choose among the following possibilities, arranged from informal to formal:

• Specify the responsibilities of the class. A responsibility is a contract or obligation of a type or class and is rendered in a note (stereotyped as responsibility) attached to the class, or in an extra compartment in the class icon.
• Specify the semantics of the class as a whole using structured text, rendered in a note (stereotyped as semantics) attached to the class.
• Specify the body of each method using structured text or a programming language, rendered in a note attached to the operation by a dependency relationship.
• Specify the pre- and postconditions of each operation, plus the invariants of the class as a whole, using structured text. These elements are rendered in notes (stereotyped as precondition, postcondition, and invariant) attached to the operation or class by a dependency relationship.
• Specify a state machine for the class. A state machine is a behavior that specifies the sequences of states an object goes through during its lifetime in response to events, together with its responses to those events.
• Specify a collaboration that represents the class. A collaboration is a society of roles and other elements that work together to provide some cooperative behavior that's bigger than the sum of all the elements. A collaboration has a structural part, as well as a dynamic part, so you can use collaborations to specify all dimensions of a class's semantics.

Specify the pre- and postconditions of each operation, plus the invariants of the class as a whole, using a formal language such as OCL.

Links for further reading:
http://praveenthomasln.wordpress.com/tag/uml-polymorphism/