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

Getting Started

The end product of a construction company's work is a physical building that exists in the real world. You build logical models to visualize, specify, and document your decisions about the building envelope; the placement of walls, doors, and windows; the routing of electrical and plumbing systems; and the overall architectural style. When you actually construct the building, these walls, doors, windows, and other conceptual things get turned into real, physical things.

These logical and physical views are both necessary. If you are building a disposable building for which the cost of scrap and rework is essentially zero (for example, if you are building a doghouse), you can probably go straight to the physical building without doing any logical modeling. If, on the other hand, you are building something enduring for which the cost of change or failure is high, then building both logical and physical models is the pragmatic thing to do to manage risk.

It's the same thing when building a software-intensive system. You do logical modeling to visualize, specify, and document your decisions about the vocabulary of your domain and the structural and behavioral way those things collaborate. You do physical modeling to construct the executable system. Whereas these logical things live in the conceptual world, the physical things live in the world of bitsthat is, they ultimately reside on physical nodes and can be executed directly or can, in some indirect manner, participate in an executing system.

In the UML, all these physical things are modeled as artifacts. An artifact is a physical thing at the level of the implementation platform.

In software, many operating systems and programming languages directly support the concept of an artifact. Object libraries, executables, .NET components, and Enterprise Java Beans are all examples of artifacts that may be represented directly in the UML. Not only can artifacts be used to model these kinds of things, they can also be used to represent other things that participate in an executing system, such as tables, files, and documents.

The UML provides a graphical representation of an artifact, as Figure 26-1 shows. This canonical notation permits you to visualize an artifact apart from any operating system or programming language. Using stereotypes, one of the UML's extensibility mechanisms, you can tailor this notation to represent specific kinds of artifacts.