Section 6.1. Artifacts

6.1. Artifacts

Artifacts represent physical pieces of information related to the software development process. For example, you can use an artifact to represent a DLL needed by your system, a user's manual, or an executable produced when your software is compiled.

Typically artifacts are used to represent the compiled version of a component (see Chapter 5); however, UML 2.0 allows artifacts to represent any packageable element, which includes just about everything in UML. You show an artifact using the classifier rectangle with a dog-eared paper in the upper right. Figure 6-1 shows a basic artifact.

Figure 6-1. A simple artifact

UML allows artifacts to have properties and operations that manipulate the artifact. These are most commonly used when an artifact represents a set of configurable options. For example, deployment specifications, which represent configuration settings for deployed artifacts, frequently use attributes to represent the allowed settings (see "Deployment Specifications"). Figure 6-2 shows an artifact with attributes.

Figure 6-2. An artifact with attributes

6.1.1. Artifact Instances

Like nearly all other UML classifiers, artifacts are really types. This means that technically a physical DLL on a node is an instance of an artifact. For example, you can have an artifact named logging.jar that represents your logging framework implementation. However, you may have several web applications installed on a server, each with their own copy of logging.jar. Each physical copy is an instance of the original artifact.

You show an instance of an artifact by underlining the name of the artifact. Figure 6-3 shows an instance of the logging.jar artifact.

Figure 6-3. An instance of the logging.jar artifact

Typically you can determine whether an artifact is intended to be a type or an instance based on context, so UML allows the normal (nonunderlined) representation of an artifact to be interpreted as an instance of that artifact if the context is clear. Practically speaking, this translates into most models using artifacts as instances, but not underlining the title.

6.1.2. Manifestations

An artifact is a manifestation of another UML element. For example, logging.jar may be a manifestation of the LoggingSubsystem component. You capture the manifestation relationship with a dashed line from the artifact to the element it represents, and label the line with the keyword «manifest». Figure 6-4 shows the LoggingSubsystem manifestation.

Figure 6-4. Showing the manifestation of a component as an artifact

In UML 1.x, manifestations were known as implementations. In UML 2.0 it was decided that implement had been overused, so it has been deprecated in favor of the keyword manifest.