In this chapter
The terms “instance” and “object” are largely synonymous, so, for the most part, they may be used interchangeably. An instance is a concrete manifestation of an abstraction to which a set of operations may be applied and which may have a state that stores the effects of the operation.
You use instances to model concrete things that live in the real world. Almost every building block in the UML participates in this class/object dichotomy. For example, you can have use cases and use case instances, nodes and node instances, associations and association instances, and so on.
Suppose you've set out to build a house for your family. By saying “house” rather than “car,” you've already begun to narrow the vocabulary of your solution space. House is an abstraction of “a permanent or semipermanent dwelling, the purpose of which is to provide shelter.” Car is “a mobile, powered vehicle, the purpose of which is to transport people from place to place.” As you work to reconcile the many competing requirements that shape your problem, you'll want to refine your abstraction of this house. For example, you might choose “a three-bedroom house with a walkout basement,” a kind of house, albeit a more specialized one.
When your builder finally hands you the keys to your house and you and your family walk through the front door, you are now dealing with something concrete and specific. It's no longer just a three-bedroom house with a walkout, but it's “my three-bedroom house with a walkout basement, located at 835 S. Moore Street.” If you are terminally sentimental, you might even name your house something like Sanctuary or Our Money Pit.
There's a fundamental difference between a three-bedroom house with a walkout basement and my three-bedroom house named Sanctuary. The former is an abstraction representing a certain kind of house with various properties; the latter is a concrete instance of that abstraction, representing some thing that manifests itself in the real world, with real values for each of those properties.
An abstraction denotes the ideal essence of a thing; an instance denotes a concrete manifestation. You'll find this separation of abstraction and instance in everything you model. For a given abstraction, you can have innumerable instances. For a given instance, there is some abstraction that specifies the characteristics common to all such instances.
In the UML, you can represent abstractions and their instances. Almost every building block in the UML—most notably classes, components, nodes, and use cases—may be modeled in terms of their essence or in terms of their instances. Most of the time, you'll work with them as abstractions. When you want to model concrete manifestations, you'll need to work with their instances.
The UML provides a graphical representation for instances, as Figure 13-1 shows. This notation permits you to visualize named instances, as well as anonymous ones.
An instance is a concrete manifestation of an abstraction to which a set of operations can be applied and which has a state that stores the effects of the operations. Instance and object are largely synonymous. Graphically, an instance specification is rendered by underlining its name.
Note
From common usage, the concrete manifestation of a class is called an object. Objects are instances of classes, so it's excruciatingly proper to say that all objects are instances, although some instances are not objects (for example, an instance of an association is really not an object, it's just an instance, also known as a link). Only power modelers will really care about this subtle distinction.
Instances don't stand alone; they are almost always tied to an abstraction. Most instances you'll model with the UML will be instances of classes (and these things are called objects), although you can have instances of other things, such as components, nodes, use cases, and associations. In the UML, an instance is easily distinguishable from an abstraction. To indicate an instance, you underline its name.
In a general sense, an object is something that takes up space in the real or conceptual world, and you can do things to it. For example, an instance of a node is typically a computer that physically sits in a room; an instance of a component takes up some space on the file system; an instance of a customer record consumes some amount of physical memory. Similarly, an instance of a flight envelope for an aircraft is something you can manipulate mathematically.
You can use the UML to model these physical instances, but you can also model things that are not so concrete. For example, an abstract class, by definition, may not have any direct instances. However, you can model indirect instances of abstract classes to show the use of a prototypical instance of that abstract class. Literally, no such object might exist. But pragmatically, this instance lets you name one of any potential instances of concrete children of that abstract class. This same touch applies to interfaces. By their very definition, interfaces may not have any direct instances, but you can model a prototypical instance of an interface, representing one of any potential instances of concrete classes that realize that interface.
When you model instances, you'll place them in object diagrams (if you want to visualize their structural details) or in interaction and activity diagrams (if you want to visualize their participation in dynamic situations). Although typically not necessary, you can place objects in class diagrams if you want to explicitly show the relationship of an object to its abstraction.
An instance has a type. The type of an actual instance must be a concrete classifier, but an instance specification (that does not represent a single instance) could have an abstract type. In notation, the name of the instance is followed by a colon followed by the type, for example, t : Transaction.
The classifier of an instance is usually static. For example, once you create an instance of a class, its class won't change during the lifetime of that object. In some modeling situations and in some programming languages, however, it is possible to change the abstraction of an instance. For example, a Caterpillar object might become a Butterfly object. It's the same object, but of a different abstraction.
Note
During development, it's also possible for you to have instances with no associated classifier, which you can render as an object but with its abstraction name missing, as in Figure 13-2. You can introduce orphan objects such as these when you need to model very abstract behavior, although you must eventually tie such instances to an abstraction if you want to enforce any degree of semantics about the object.
An instance may have a name that distinguishes it from other instances within its context. Typically, an object lives within the context of an operation, a component, or a node. A name is a textual string, such as t and myCustomer in Figure 13-2. That name alone is known as a simple name. The abstraction of the instance may be a simple name (such as Transaction) or it may be a path name (such as Multimedia::AudioStream) which is the abstraction's name prefixed by the name of the package in which that abstraction lives.
When you explicitly name an object, you are really giving it a name (such as myCustomer) that's usable by a human. You can also simply name an object (such as myCustomer) and elide its abstraction if it's obvious in the given context. In many cases, however, the real name of an object is known only to the computer on which that object lives. In such cases, you can render an anonymous object (such as :AudioStream). Each occurrence of an anonymous object is considered distinct from all other occurrences. If you don't even know the object's associated abstraction, you must at least give it an explicit name (such as agent:).
The name and the type of an object form one string in the notation, for example, t : Transaction. For an object (as opposed to a role within a structured class), the entire string is underlined.
Note
An instance name may be text consisting of any number of letters, numbers, and certain punctuation marks (except for marks such as the colon, which is used to separate the name of the instance from the name of its abstraction) and may continue over several lines. In practice, instance names are short nouns or noun phrases drawn from the vocabulary of the system you are modeling. Typically, you capitalize the first letter of all but the first word in an instance name, as in t or myCustomer.
Not only is an object something that usually takes up space in the real world, it is also something you can do things to. The operations you can perform on an object are declared in the object's abstraction. For example, if the class Transaction defines the operation commit, then given the instance t : Transaction, you can write expressions such as t.commit(). The execution of this expression means that t (the object) is operated on by commit (the operation). Depending on the inheritance lattice associated with Transaction, this operation may or may not be invoked polymorphically.
An object also has state, which in this sense encompasses all the properties of the object plus the current values of each of these properties (also including links and related objects, depending on your viewpoint). These properties include the attributes and associations of the object, as well as all its aggregate parts. An object's state is therefore dynamic. So when you visualize its state, you are really specifying the value of its state at a given moment in time and space. It's possible to show the changing state of an object by showing it multiple times in the same interaction diagram, but with each occurrence representing a different state.
When you operate on an object, you typically change its state; when you query an object, you don't change its state. For example, when you make an airline reservation (represented by the object r : Reservation), you might set the value of one of its attributes (for example, price = 395.75). If you change your reservation, perhaps by adding a new leg to your itinerary, then its state might change (for example, price = 1024.86).
As Figure 13-3 shows, you can use the UML to render the value of an object's attributes. For example, myCustomer is shown with the attribute id having the value “432-89-1783.” In this case, id's type (SSN) is shown explicitly, although it can be elided (as for active = True), because its type can be found in the declaration of id in myCustomer's associated class.
You can associate a state machine with a class, which is especially useful when modeling event-driven systems or when modeling the lifetime of a class. In these cases, you can also show the state of this machine for a given object at a given time. The state is shown in square brackets following the type. For example, as Figure 13-3 shows, the object c (an instance of the class Phone) is indicated in the state WaitingForAnswer, a named state defined in the state machine for Phone.
Processes and threads are an important element of a system's process view, so the UML provides a visual cue to distinguish elements that are active (those that are part of a process or thread and represent a root of a flow of control) from those that are passive. You can declare active classes that reify a process or thread, and in turn you can distinguish an instance of an active class, as in Figure 13-4.
Note
Most often you'll use active objects in the context of interaction diagrams that model multiple flows of control. Each active object represents the root of a flow of control and may be used to name distinct flows.
There are two other elements in the UML that may have instances. The first is an association. An instance of an association is a link. A link is a semantic connection among a list of objects. A link is rendered as a line, just like an association, but it can be distinguished from an association because links connect objects.
The second kind of instance is a static (class-scoped) attribute. A static attribute is, in effect, an object owned by the class that is accessible by all instances of the class. It is therefore shown in a class declaration as an underlined attribute.
All of the UML's extensibility mechanisms apply to objects. Usually, however, you don't stereotype an instance directly, nor do you give it its own tagged values. Instead, an object's stereotype and tagged values derive from the stereotype and tagged values of its associated abstraction. For example, as shown in Figure 13-5, you can explicitly indicate an object's stereotype as well as its abstraction.
The UML defines two standard stereotypes that apply to the dependency relationships among objects and among classes:
When you model concrete instances, you are in effect visualizing things that live in the real world. You can't exactly see an instance of a Customer class, for example, unless that customer is standing beside you; in a debugger, you might be able to see a representation of that object, however.
One of the things for which you'll use objects is to model concrete instances that exist in the real world. For example, if you want to model the topology of your organization's network, you'll use deployment diagrams containing instances of nodes. Similarly, if you want to model the components that live on the physical nodes in this network, you'll use component diagrams containing instances of the components. Finally, suppose you have a debugger connected to your running system; it can present the structural relationships among instances by rendering an object diagram.
Identify those instances necessary and sufficient to visualize, specify, construct, or document the problem you are modeling.
Render these objects in the UML as instances. Where possible, give each object a name. If there is no meaningful name for the object, render it as an anonymous object.
Expose the stereotype, tagged values, and attributes (with their values) of each instance necessary and sufficient to model your problem.
Render these instances and their relationships in an object diagram or other diagram appropriate to the kind of the instance.
For example, Figure 13-6 shows an object diagram drawn from the execution of a credit card validation system, perhaps as seen by a debugger that's probing the running system.
When you model instances in the UML, remember that every instance should denote a concrete manifestation of some abstraction, typically a class, component, node, use case, or association. A well-structured instance
Is explicitly associated with a specific abstraction.
Has a unique name drawn from the vocabulary of the problem domain or the solution domain.
When you draw an instance in the UML,
Render the name of the abstraction of which it is an instance unless it's obvious by context.
Show the instance's stereotype and state only as necessary to understand the object in its context.
If visible, organize long lists of attributes and their values by grouping them according to their category.