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

Terms and Concepts

A package is a general-purpose mechanism for organizing the model itself into a hierarchy; it has no meaning to the execution. Graphically, a package is rendered as a tabbed folder. The name of the package goes in the folder (if its contents are not shown) or in the tab (if the contents of the folder are shown).

Names

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

simple name ; a

qualified name is the package name prefixed by the name of the package in which that package lives, if any. A double colon (::) separates package names. A package is typically drawn showing only its name, as in Figure 12-2. Just as with classes, you may draw packages adorned with tagged values or with additional compartments to expose their details.

Note

A package 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 a package name and the name of its enclosing package) and may continue over several lines. In practice, package names are short grouping nouns or noun phrases drawn from the vocabulary of the model.

Owned Elements

A package may own other elements, including classes, interfaces, components, nodes, collaborations, use cases, diagrams, and even other packages. Ownership is a composite relationship, which means that the element is declared in the package. If the package is destroyed, the element is destroyed. Every element is uniquely owned by exactly one package.

Note

The package owns the model elements declared within it. These may include elements such as classes, associations, generalizations, dependencies, and notes. It does not own elements that are merely referenced within a package.

A package forms a namespace, which means that elements of the same kind must be named uniquely within the context of its enclosing package. For example, you can't have two classes named Queue owned by the same package, but you can have a class named Queue in package P1 and another (and different) class named Queue in package P2. The classes P1::Queue and P2::Queue are, in fact, different classes and can be distinguished by their path names. Different kinds of elements may have the same name.

Note

It is best to avoid duplicate names in different packages, if possible, to avoid the danger of confusion.

Elements of different kinds may have the same name within a package. Thus, you can have a class named Timer, as well as a component named Timer, within the same package. In practice, however, to avoid confusion, it's best to name elements uniquely for all kinds within a package.

Packages may own other packages. This means that it's possible to decompose your models hierarchically. For example, you might have a class named Camera that lives in the package Vision that in turn lives in the package Sensors. The full name of this class is Sensors::Vision::Camera. In practice, it's best to avoid deeply nested packages. Two to three levels of nesting is about the limit that's manageable. More than nesting, you'll use importing to organize your packages.

These semantics of ownership make packages an important mechanism for dealing with scale. Without packages, you'd end up with large, flat models in which all elements would have to be named uniquelyan unmanageable situation, especially when you've brought in classes and other elements developed by multiple teams. Packages help you control the elements that compose your system as they evolve at different rates over time.

As Figure 12-3 shows, you can explicitly show the contents of a package either textually or graphically. Note that when you show these owned elements, you place the name of the package in the tab. In practice, you usually won't want to show the contents of packages this way. Instead, you'll use graphical tools to zoom into the contents of a package.

Note

The UML assumes that there is an anonymous, root package in a model, the consequence of which is that elements of each kind at the top of a model must be uniquely named.

Visibility

You can control the visibility of the elements owned by a package just as you can control the visibility of the attributes and operations owned by a class. Typically, an element owned by a package is public, which means that it is visible to the contents of any package that imports the element's enclosing package. Conversely, protected elements can only be seen by children, and private elements cannot be seen outside the package in which they are declared. In Figure 12-3, OrderForm is a public part of the package Client, and Order is a private part. A package that imports Client can see OrderForm, but it cannot see Order. As viewed from the outside, the fully qualified name of OrderForm would be Client::OrderForm.

You specify the visibility of an element owned by a package by prefixing the element's name with an appropriate visibility symbol. Public elements are rendered by prefixing their name with a + symbol, as for OrderForm in Figure 12-3. Collectively, the public parts of a package constitute the package's interface.

Just as with classes, you can designate an element as protected or private, rendered by prefixing the element's name with a # symbol and a - symbol, respectively. Protected elements are visible only to packages that inherit from another package; private elements are not visible outside the package at all.

Package visibility indicates that a class is visible to other classes declared in the same package but is invisible to classes declared in other packages. Show package visibility by prefixing a ~ symbol to the name of the class.

Importing and Exporting

Suppose you have two classes named A and B sitting side by side. Because they are peers, A can see B and B can see A, so both can depend on the other. Just two classes makes for a trivial system, so you really don't need any kind of packaging.

Now, imagine having a few hundred such classes sitting side by side. There's no limit to the tangled web of relationships that you can weave. Furthermore, there's no way that you can understand such a large, unorganized group of classes. That's a very real problem for large systemssimple, unrestrained access does not scale up. For these situations, you need some kind of controlled packaging to organize your abstractions.

So suppose that instead you put A in one package and B in another package, both packages sitting side by side. Suppose also that A and B are both declared as public parts of their respective packages. This is a very different situation. Although A and B are both public, accessing one of the classes from within the other package requires a qualified name. However, if A's package imports B's package, A can now see B directly, although still B cannot see A without a qualified name. Importing adds the public elements from the target package to the public namespace of the importing package. In the UML, you model an import relationship as a dependency adorned with the stereotype import. By packaging your abstractions into meaningful chunks and then controlling their access by importing, you can control the complexity of large numbers of abstractions.

Note

Actually, two stereotypes apply hereimport and accessand both specify that the source package has direct access to the public contents of the target package. Import adds the contents of the target to the source's public namespace, so you don't have to qualify their names. This admits the possibility of name clashes, which you must avoid to keep the model well-formed. Access adds the contents of the target package to the sources's private namespace. The only difference is that you cannot re-export the imported elements if a third package imports the original source package. Most of the time you'll use import.

The public parts of a package are called its exports. For example, in Figure 12-4, the package GUI exports two classes, Window and Form. EventHandler is not exported by GUI; EventHandler is a protected part of the package.

Interfaces are discussed in Chapter 11 .