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

Terms and Concepts

A artifact is a physical part of a system that exists at the level of the implementation platform. Graphically, an artifact is rendered as a rectangle with the keyword «artifact».

Names

Every artifact must have a name that distinguishes it from other artifacts. A name is a textual string. That name alone is known as a

simple name ; a

qualified name is the artifact name prefixed by the name of the package in which that artifact lives. An artifact is typically drawn showing only its name, as in Figure 26-2. Just as with classes, you may draw artifacts adorned with tagged values or with additional compartments to expose their details, as you see in the figure.

Note

An artifact 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 an artifact name and the name of its enclosing package) and may continue over several lines. In practice, artifact names are short nouns or noun phrases drawn from the vocabulary of the implementation and, depending on your target operating system, include extensions (such as java and dll).

Artifacts and Classes

Classes and artifacts are both classifiers. However, there are some significant differences between artifacts and classes.

• 
  Classes represent logical abstractions; artifacts represent physical things that live in the world of bits. In short, artifacts may live on nodes, classes may not.

  
  

• 
  Artifacts represent the physical packaging of bits on the implementation platform.

  
  

• 
  Classes may have attributes and operations. Artifacts may implement classes and methods, but they do not have attributes or operations themselves.

  
  

The first difference is the most important. When modeling a system, deciding whether you should use a class or an artifact involves a simple decisionif the thing you are modeling lives directly on a node, use an artifact; otherwise, use a class. The second difference also makes this clear.

The third difference suggests a relationship between classes and artifacts. In particular, an artifact is the physical implementation of a set of logical elements, such as classes and collaborations. As Figure 26-3 shows, the relationship between an artifact and the classes it implements can be shown explicitly by using a manifestation relationship.

Kinds of Artifacts

Three kinds of artifacts may be distinguished.

First, there are

deployment artifacts . These are the artifacts necessary and sufficient to form an executable system, such as dynamic libraries (DLLs) and executables (EXEs). The UML's definition of artifact is broad enough to address classic object models, such as .NET, CORBA, and Enterprise Java Beans, as well as alternative object models, perhaps involving dynamic Web pages, database tables, and executables using proprietary communication mechanisms.

Second, there are

work product artifacts. These artifacts are essentially the residue of the development process, consisting of things such as source code files and data files from which deployment artifacts are created. These artifacts do not directly participate in an executable system but are the work products of development that are used to create the executable system.

Third are

execution artifacts . These artifacts are created as a consequence of an executing system, such as a .NET object, which is instantiated from a DLL.

Standard Elements

UML's extensibility mechanisms apply to artifacts. Most often, you'll use tagged values to extend artifact properties (such as specifying the version of a development artifact) and stereotypes to specify new kinds of artifacts (such as operating system-specific artifacts).

The UML predefines standard stereotypes that apply to artifacts:

1. executable