TOC PREV NEXT INDEX DOC LIST MASTER INDEX



Imports and Exports

The relationships between library contexts (Apex views in Apex/Summit or Rational subsystems in Apex/ClearCase) are controlled by imports and exports. Imports and exports define the visibility of objects —— which objects from other subsystems can be used by objects in this subsystem. Controlling the interfaces helps maintain the software architecture and avoids unwanted dependencies. This chapter includes the following topics:


Importing and Exporting

Import operations are used to manage the inter-subsystem compilation relationships of library contexts. A client may only compile against the interfaces of a supplier if the client imports the supplier. To establish the import relationships, users specify a set of explicit imports for a client. This client/supplier relationships are illustrated in Figure 5 and Figure 6.

Figure 5 Client and Supplier for Ada

Figure 6 Client and Supplier For C/C++

For source files in a supplier to be visible to a unit in a client, the client must import the supplier and the supplier must export the source file. Source files that are not exported are not visible to the client. In other words, clients are granted visibility only to units that are exported by suppliers.

An export set is a set of compilation units that are exported from suppliers. Units are always exported via a particular export set. Export sets identify different subsets of the same library context so that the export sets in the same library context may contain different units. When a client imports a supplier, the client specifies an export set in the supplier that will be used. The client will have visibility only to the units included in the export set that is being used.

There can be more than one export set in a library context; however, only one export set per library context can be imported. The closure of all the imports needs to be consistent. For the set of library contexts that compose a system, library contexts can import different export sets of a library context, but for Apex/Summit, they all need to import the same view of a particular subsystem. For the set of library contexts that compose a system, a system description may be defined.

System Descriptions

System descriptions describe the logical import relationships for a system independent of specific library contexts. System descriptions contain a specification of the relationships between supplier subsystems and client subsystems, which for Apex/Summit, must be realized in actual views of the subsystems.

System descriptions are represented in files with the extension .sysd. A system description file contains information on:

Typically, system description files are put in a subsystem of their own. They can also be used to define the library contexts of objects in the Rational Rose product. More information on system descriptions can be found in Programming with Apex.

For Apex/Summit, system descriptions are view-independent. They can be used for any views in a set of subsystems. They can also be used to propagate changes between towers (configurations).

Special Export Sets

One special export set is named all_units. This set must be created and deleted like any other export set. However, when this set exists, it automatically contains each program unit in the library context.

Default Export Set

Each library context has a default export set (specified by the switch DEFAULT_EXPORT_SET), which specifies the export set that will be used by clients when they do not specify a set.


Explicit and Implicit Imports

There are two kinds of imports: explicit and implicit. A union of explicit and implicit imports is called a full import set. Implicit imports are the unspecified library contexts that the explicitly imported library contexts need to compile successfully. Implicitly imported library contexts must comply with the following consistency and compatibility checks:

An example of a circular import relationship is illustrated in Figure 7. If library context v1 imports library context v2, which imports library contexts v3, then v3 is not allowed to import v1.

Figure 7 Circular Imports

Note:

For Apex/ClearCase, Rational Subsystems can import Rational subsystems or Summit/CM views. Summit/CM views cannot import Rational Subsystems.


Mutual Importing

Tree-structured, noncircular import relationships are called hierarchical relationships. Hierarchical importing can be relaxed by grouping library contexts into mutual import sets. A mutual import set is a single compilation context distributed across library contexts. Each library contexts in a mutual importing set has:

Once a mutual importing set is formed, an import change to any member results in a change to all members. A library context can be a member of at most one mutual importing set.

Additional information on mutual importing can be found in Programming with Apex.

Design Enforcement

The imports and exports of a system enforce an architecture and a design. If a client file tries to with or include a supplier file that is not exported, an error is generated. If a client file tries to with or include a file in a supplier view that is not imported, an error is generated.

Note: For Apex/Summit, a view in a subsystem cannot be imported into another view in the same subsystem. In other words, only one view per subsystem can be imported in a system.


Rational Software Corporation 
http://www.rational.com
support@rational.com
techpubs@rational.com
Copyright © 1993-2002, Rational Software Corporation. All rights reserved.
TOC PREV NEXT INDEX DOC LIST MASTER INDEX TECHNOTES APEX TIPS