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

Getting Started

Suppose you've set out to build a house for your family. By saying "house" rather than "car," you've already begun to narrow the vocabulary of your solution space. House is an abstraction of "a permanent or semipermanent dwelling, the purpose of which is to provide shelter." Car is "a mobile, powered vehicle, the purpose of which is to transport people from place to place." As you work to reconcile the many competing requirements that shape your problem, you'll want to refine your abstraction of this house. For example, you might choose "a three-bedroom house with a walkout basement," a kind of house, albeit a more specialized one.

When your builder finally hands you the keys to your house and you and your family walk through the front door, you are now dealing with something concrete and specific. It's no longer just a three-bedroom house with a walkout, but it's "my three-bedroom house with a walkout basement, located at 835 S. Moore Street." If you are terminally sentimental, you might even name your house something like Sanctuary or Our Money Pit.

There's a fundamental difference between a three-bedroom house with a walkout basement and my three-bedroom house named Sanctuary. The former is an abstraction representing a certain kind of house with various properties; the latter is a concrete instance of that abstraction, representing some thing that manifests itself in the real world, with real values for each of those properties.

An abstraction denotes the ideal essence of a thing; an instance denotes a concrete manifestation. You'll find this separation of abstraction and instance in everything you model. For a given abstraction, you can have innumerable instances. For a given instance, there is some abstraction that specifies the characteristics common to all such instances.

In the UML, you can represent abstractions and their instances. Almost every building block in the UMLmost notably classes, components, nodes, and use casesmay be modeled in terms of their essence or in terms of their instances. Most of the time, you'll work with them as abstractions. When you want to model concrete manifestations, you'll need to work with their instances.

The UML provides a graphical representation for instances, as Figure 13-1 shows. This notation permits you to visualize named instances, as well as anonymous ones.