Guideline: Import Dependency in Implementation
Handling dependencies between subsystems is an important aspect of structuring the implementation model. This guideline describes how to go about it.
Related Elements
Main Description


Handling dependencies between subsystems is an important aspect of structuring the implementation model. A element in a client subsystem can only compile against elements in a supplier subsystem, if the client subsystem imports the supplier subsystem. To express such dependencies use the import dependency from one subsystem to another, to point out the subsystem on which there is a dependence.


The following component diagram illustrates the import dependencies between implementation subsystems.

Diagram described in accompanying text.

The subsystem Telephone Banking has an import dependency to the subsystem Trading Services, allowing elements in Telephone Banking to compile against public (visible) elements in Trading Services.


Architectural Control

An important usage of the import dependency is to control the visibility between subsystems, and to enforce an architecture on the implementers. When the import dependency is defined by the software architect early in the development, the implementers are only allowed to let their implementation elements reference (compile against) public elements in the imported subsystems. Controlling the imports helps maintain the software architecture and avoids unwanted dependencies.

Subsystems Can Be Organized in Layers

The implementation model is normally organized in layers. The number of layers is not fixed, but vary from situation to situation. The following is a typical architecture with four layers:

  • The top layer, application layer, contains the application specific services.
  • The next layer, business-specific layer, contains business specific components, used in several applications.
  • The middleware layer contains components such as GUI-builders, interfaces to database management systems, platform-independent operating system services, and OLE-components such as spreadsheets and diagram editors.
  • The bottom layer, system software layer, contains components such as operating systems, interfaces to specific hardware, and so on.

Diagram described in accompanying text.

An example of a layered implementation model for a banking system. The arrows shows import dependencies between subsystems.