The Unified Modeling Language User Guide SECOND EDITION [Electronic resources] نسخه متنی

Terms and Concepts

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.

Abstractions and Instances

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.

Types

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.

Names

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.

Operations

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.

State

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.

Note

Because an object may be in several states simultaneously, you can also show a list of its current states.

Other Features

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.

Standard Elements

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: