Section 15.2. Deployed Software: Artifacts


15.2. Deployed Software: Artifacts

The previous section showed a sneak preview of some of the notation that can be used to show the software and hardware in a deployed system. The 3dpacman.jar software was deployed to a single hardware node. In UML, that JAR file is called an artifact.

Artifacts are physical files that execute or are used by your software. Common artifacts you'll encounter include:

  • Executable files, such as .exe or .jar files

  • Library files, such as .dlls (or support .jar files)

  • Source files, such as .java or .cpp files

  • Configuration files that are used by your software at runtime, commonly in formats such as .xml, .properties, or .txt

An artifact is shown as a rectangle with the stereotype <<artifact>>, or the document icon in the upper right hand corner, or both, as shown in Figure 15-5. For the rest of the book, an artifact will be shown with both the stereotype <<artifact>> and the document icon.

Figure 15-5. Equivalent representations of a 3dpacman.jar artifact


15.2.1. Deploying an Artifact to a Node

An artifact is deployed to a node, which means that the artifact resides on (or is installed on) the node. Figure 15-6 shows the 3dpacman.jar artifact from the previous example deployed to a Desktop PC hardware node by drawing the artifact symbol inside the node.

Figure 15-6. The 3dpacman.jar artifact deployed to a Desktop PC node


You can model that an artifact is deployed to a node in two other ways. You can also draw a dependency arrow from the artifact to the target node with the stereotype <<deploy>>, as shown in Figure 15-7.

Figure 15-7. An alternate way to model the relationship deployment


When you're pressed for space, you might want to represent the deployment by simply listing the artifact's name inside the target node, as shown in Figure 15-8.

Figure 15-8. A compact way to show deployment is to write the name of the artifact inside the node


All of these methods show the same deployment relationship, so here are some guidelines for picking a notation.

Listing the artifacts (without the artifact symbol) can really save space if you have a lot of artifacts, as in Figure 15-9. Imagine how big the diagram would get if you drew the artifact symbol for each artifact.

But be careful; by listing your artifacts, you cannot show dependencies between artifacts. If you want to show that an artifact uses another artifact, you have to draw the artifact symbols and a dependency arrow connecting the artifacts, as shown in Figure 15-10.

15.2.2. Tying Software to Artifacts

When designing software, you break it up into cohesive groups of functionality, such as components or packages, which eventually get compiled into one or more filesor artifacts. In UML-speak, if an artifact is the physical actualization of a component, then the artifact manifests that component. An artifact can manifest not just components but any packageable element, such as packages and classes.

Figure 15-9. Listing artifact names inside a node saves a lot of space compared to drawing an artifact symbol for each artifact


Figure 15-10. A deployment notation that uses artifact symbols (instead of listing artifact names) allows you to show artifact dependencies


The manifest relationship is shown with a dependency arrow from the artifact to the component with the stereotype <<manifest>>, as shown in Figure 15-11.

Figure 15-11. The artifact mycomponent.jar manifests the component MyComponent


Since artifacts can then be assigned to nodes, the manifest relationship provides the missing link in modeling how your software components are mapped to hardware. However, linking a component to an artifact to a node can result in a cluttered diagram, so it's common to show the manifest relationships separate from the deployment relationships, even if they're on the same deployment diagram.

You can also show the manifest relationship in component diagrams by listing the artifacts manifesting a component within the component symbol, as discussed in Chapter 12.


If you're familiar with earlier versions of UML, you may be tempted to model a component running on hardware by drawing the component symbol inside the node. As of UML 2.0, artifacts have nudged components toward a more conceptual interpretation, and now artifacts represent physical files.

However, many UML tools aren't fully up to date with the UML 2.0 standard, so your tool may still use the earlier notation.




Learning UML 2.0
Learning UML 2.0
ISBN: 0596009828
EAN: 2147483647
Year: 2007
Pages: 175

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net