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

Terms and Concepts

A system, possibly decomposed into a collection of subsystems, is a set of elements organized to accomplish a purpose and described by a set of models, possibly from different viewpoints. A subsystem is a grouping of elements of which some constitute a specification of the behavior offered by other contained elements. Graphically, a system and a subsystem are rendered as a stereotyped component icon. A model is a simplification of reality, an abstraction of a system, created to better understand the system. A view is a projection of a model, which is seen from one perspective or vantage point and omits entities that are not relevant to this perspective.

Systems and Subsystems

A system is the thing that you are developing and for which you build models. A system encompasses all the artifacts that constitute that thing, including all its models and modeling elements, such as classes, interfaces, components, nodes, and their relationships. Everything you need to visualize, specify, construct, and document a system is part of that system, and everything you don't need to visualize, specify, construct, and document a system lies outside that system.

In the UML, a system is rendered as a stereotyped component, as shown in Figure 32-1. As a stereotyped component, a system owns elements. If you zoom inside a system, you'll see all its models and individual modeling elements (including diagrams), perhaps further decomposed into subsystems. As a classifier, a system may have instances (a system may be deployed in multiple instances in the real world), attributes and operations (actors outside the system may act on the system as a whole), use cases, state machines, and collaborations, all of which may specify the behavior of the system. A system may even realize interfaces, which is important when you are constructing systems of systems.

A subsystem is simply a part of a system and is used to decompose a complex system into nearly independent parts. A system at one level of abstraction may be a subsystem of a system at a higher level of abstraction.

The primary relationship between a system and its subsystems is composition. A system (the whole) may contain zero or more subsystems (the parts). You can also have generalization relationships among subsystems. Using generalization, you can model families of subsystems, some of which represent general kinds of systems and others of which represent specific tailorings of those systems. The subsystems have various connections among themselves.

Note

A system represents the highest-level thing in a given context; the subsystems that make up a system provide a complete and non-overlapping partitioning of the system as a whole. A system is a top-level subsystem.

Models and Views

A model is a simplification of reality, in which reality is defined in the context of the system being modeled. In short, a model is an abstraction of a system. A subsystem represents a partitioning of the elements of a larger system into independent parts; a model is a partitioning of the abstractions that visualize, specify, construct, and document that system. The difference is subtle but important. You decompose a system into subsystems so that you can develop and deploy these parts somewhat independently; you partition the abstractions of a system or a subsystem into models so that you can better understand the different aspects of the thing you are developing and deploying. Just as a complex system such as an aircraft may have many parts (for example, the airframe, propulsion, avionics, and passenger subsystems), those subsystems and the system as a whole may be modeled from a number of different points of view (such as from the perspective of structural, dynamic, electrical, and heating/cooling models, for example).

A model contains a set of packages. You'll rarely need to model models explicitly, however. Tools need to manipulate models, however, so a tool will typically use package notation to represent a model as seen by the tool.

A model owns packages that, in turn, own elements. The models associated with a system or subsystem completely partition the elements of that system or subsystem, meaning that every element is owned by exactly one package. Typically, you'll organize the artifacts of a system or subsystem into a set of nonoverlapping models, covered by the five views of software architecture that are described elsewhere.

A model (for example, a process model) may contain so many artifacts (such as active classes, relationships, and interactions) that in systems of scale, you simply cannot embrace all those artifacts at once. Think of a view as a projection into a model. For each model, you'll have a number of diagrams that exist to give you a peek into the things owned by the model. A view encompasses a subset of the things owned by a model; a view typically may not cross model boundaries. As described in the next section, there are no direct relationships among models, although you'll find trace relationships among the elements contained in different models.

Note

The UML does not dictate which models you should use to visualize, specify, construct, and document a system, although the Rational Unified Process does suggest a proven set of models.

Trace

Specifying relationships among elements such as classes, interfaces, components, and nodes is an important structural part of any model. Specifying the relationships among elements such as documents, diagrams, and packages that live in different models is an important part of managing the development artifacts of complex systems, many of which may exist in multiple versions.

In the UML, you can model the conceptual relationship among elements that live in different models by using a trace relationship; a trace may not be applied among elements in the same model. A trace is represented as a stereotyped dependency. You can often ignore the direction of this dependency, although you'll typically direct it to the older or more-specific element, as in Figure 32-2. The two most common uses for the trace relationship are to trace from requirements to implementation (and all the artifacts in between) and to trace from version to version.

Note

Most of the time you will not want to render trace relationships explicitly but, rather, will treat them as hyperlinks.