3.4 Symbols

The authors of the UML have made an effort to avoid overwhelming the user with too many distinctive symbols, and have also tried to provide notational similarities among conceptually related symbols (packages and classes, for example).

UML symbols can have content or just be iconic. Actually, the UML distinguishes between what it calls, awkwardly, two-dimensional symbols and icons:

Icons
Fixed in size and shape, icons do not have to be attached to paths (but can be terminators: icons on the end of a path that qualify the meaning of the path symbol). They may be located within symbols.
Two-dimensional symbols
Having the capability to shrink or grow, two-dimensional symbols can have compartments as well. Some two-dimensional symbols are also graphs they contain nodes connected by paths.

3.4.1 Actor

An actor is something or someone outside the system that interacts directly with it typically, a user of the system or another system/subsystem (see Figure 3.2). An actor participates in use cases and may be represented in other types of diagrams anywhere in the system model.

Figure 3.2. Actor.

3.4.2 Use Case/Collaboration

A use case is a sequence of interactions by an actor with the system, which yields observable value to the actor (see Figure 3.3). By the way, this is not the UML definition, which is deplorably fussy and technical, and seems to be an effort to make use cases into a type of class and what the UML calls a "behavioral thing."

Figure 3.3. Use case.

A collaboration a collection of objects that interact to implement behavior (see Figure 3.4). Typically, a collaboration can be used to specify the realization of a use case or an operation. A collaboration can also be used to specify a software pattern, and a parameterized collaboration (that is, one with abstract participants that are replaced when the pattern is used) can specify an architectural pattern.

Figure 3.4. Collaboration.

3.4.3 Class/Object/Type/Active Class

A class is an abstraction of a set of possible objects that share the same attributes, operations, methods, relationships, and semantics (see Figure 3.5). A class may use a set of interfaces to specify collections of operations it provides to its environment. A type is a representation of a collection of objects without specifying the physical implementation as a class. Class and type use the same symbol in the UML.

Figure 3.5. Class.

An object is an instance of a class or an example of a type the same symbol as class, but with the name underlined (see Figure 3.6).

Figure 3.6. Object.

An active class is a set of objects, each of which owns a thread of control (that is, it can initiate, control, and terminate a process or thread). (See Figure 3.7.)

Figure 3.7. Active class.

3.4.4 Interface

An interface describes the visible operations of a class, component, or package (see Figure 3.8). It defines the services available from the implementing element.

Figure 3.8. Interface.

3.4.5 Component

A component is a physical, replaceable part of a system that packages implementation and provides the realization of a set of interfaces (see Figure 3.9). A component represents a physical piece of implementation of a system, including software code (source, binary, or executable) or equivalents such as scripts or command files (Rational Software Corporation1999, B-5).

Figure 3.9. Component.

3.4.6 Node

A node represents a processing resource that exists at run time, with at least a memory and often processing capability as well (see Figure 3.10). Nodes comprise computing devices and any other physical resources used in a system, such as people or machines.

Figure 3.10. Node.

3.4.7 Package

A package (see Figure 3.11) is a UML container used to organize model elements (refer to Section 3.2, "Packages," earlier in this chapter).

Figure 3.11. Package.

3.4.8 State

A state is the condition, status, or situation of an object as part of its lifecycle and/or as the result of an interaction (see Figure 3.12). A state may also be used to model an ongoing activity.

Figure 3.12. State.

3.4.9 Note

A note is used to provide explanatory text, such as comments in a model (see Figure 3.13). A note can also be used in specific ways, depending on the modeling dialect you adopt (requirements are a good example).

Figure 3.13. Note.