Section 13.2. Namespaces and Classes Referring to Each Other

13.2. Namespaces and Classes Referring to Each Other

Breaking up your classes into packages introduces some bookkeeping. If you're a Java programmer, you may have encountered a related issue before. To use an ArrayList in a Java program, you have to specify that ArrayList is located in the java.util package. That is because Java packages define their own namespaces, or naming contexts. If an item is not in the current namespace, you have to specify where it is located.

Similarly, a UML package establishes a namespace. So, if an element in a package wants to use an element in a different package, it has to specify where the desired element is. To specify the context of a UML element, you provide the fully-scoped name, which includes the package name and the element name separated by double colons, as in packageName::className. The fully-scoped name for the class Credentials belonging to the package security is security::Credentials. If you have two classes with the same name in different packages, using the fully-scoped name allows you to distinguish between them.

Elements in a namespace must have unique names. This means the security package cannot have two classes named Credentials, but there can be two classes called Credentials belonging to separate packages, for example security and utils. As discussed previously in "UML Tool Variation," your UML tool may display the classes in Figure 13-8 differently.

Figure 13-8. Representing a class with its fully-scoped name: both the security and utils packages have a class named Credentials

Why does this matter? To specify that a class has a relationship with another class, you may have to specify a namespace.

Classes in the same package are part of the same namespace, so they can refer to each other without using fully-scoped names. Since they are in the same package, IdentityVerifier can have an attribute of type Credentials and not have to specify the package (see Figure 13-9).

Figure 13-9. Classes in different packages have to provide name scope

On the other hand, a class outside the security package, such as User, would have to provide a scope when accessing Credentials, which it can do by using the fully-scoped namesecurity::Credentials. Later, in "Importing and Accessing Packages," you'll see that there are other ways to provide scope when accessing a class in a different package.

In Java, a fully-scoped name corresponds to specifying the Java package, e.g., security.Credentials instead of just Credentials.

In UML, elements in a nested package can refer to elements in the containing package without scoping the name, which in Figure 13-10 means that an element in indexing could refer to an element in search without using the fully-scoped name.

Figure 13-10. In UML, a nested package implies namespace "inheritance," which doesn't apply in some implementation languages

The implication that elements in nested packages have automatic access to elements in containing packages doesn't match with some implementation languages. For example, in Java, if a class in the indexing package uses a class in the search package, it has to provide a scope either by using its fully-qualified name or by importing the search package. Despite the fact that UML semantics of nested packages differ from Java packages, you could still use Figure 13-10 to model a package search.indexing in a Java system.