Section 13.5. Importing and Accessing Packages

13.5. Importing and Accessing Packages

When a package imports another package, elements in the importing package can use elements in the imported package without having to use their fully scoped names. This feature is similar to a Java import, in which a class can import a package and use its contents without having to provide their package names.

In an import relationship, the imported package is referred to as the target package . To show the import relation, draw a dependency arrow from the importing package to the target package with the stereotype import (see Figure 13-14).

Figure 13-14. The package users imports security, so classes in users may use public classes in security without having to specify the package name

A package can also import a specific element in another package instead of the whole package, as shown in Figure 13-15.

Figure 13-15. The users package imports only the Credentials element from the security package

When importing a package, only public elements of the target package are available in the importing namespace. For example, in Figure 13-16, elements in users can see Credentials and IdentityVerifier but not MD5Crypt.

Figure 13-16. Private visibility causes a class not to be seen even though its package is imported

Not only do elements have visibilitythe import relation itself has visibility. An import can be a public import or private import with public as the default. A public import means imported elements have public visibility inside the importing namespace; a private import means imported elements have private visibility inside the importing namespace. You show a private import with the stereotype access instead of import.

The difference between import and access arises when a package imports a package that imports or accesses others. Imported elements have public visibility in the importing package, so they get passed on with further imports, whereas accessed elements do not.

In Figure 13-17, package B imports C and accesses D, so B can see public elements in C and D. A imports B, so A can see public elements in B. A can also see public elements in C because C is publicly imported into B, but A cannot see anything in D because D is privately imported into B.

Figure 13-17. Package A can see public elements in C but not D

Import and access relationships can be used to model the programming world concepts of importing of classes into another namespace so that elements in the importing namespace may refer to elements in the target namespace without scoping the name. For example, the package relationships in Figure 13-14 could be used to model the Java code example in Example 13-2.

Example 13-2. Because the User class imports the security package, it can refer to the Credentials class without using the fully qualified name security

 package users;   // importing all public elements in the security package import security.*;   class User {     Credentials credentials;     ... } 

The element import in Figure 13-15 corresponds to the Java implementation shown in Example 13-3.

Example 13-3. Only the Credentials class is imported from the security package

 package users;   // importing only the Credentials class import security.Credentials;   class User {     Credentials credentials;       ... } 

Many modelers don't bother with specifying the import and access relationships, and instead show generic package dependencies, discussed earlier in "Package Dependency."