Dependencies Between Components

Dependency relationships are used within component diagrams to indicate that a component refers to services offered by other components. This type of dependency reflects implementation choices. A dependency relationship is represented by a dashed arrow drawn from the client to the supplier.

In a component diagram, dependency relationships generally represent compilation dependencies. The compilation order is given by the dependency relationship graph.

Processes

Processes are objects that have their own control flow (or thread), and as such are special kinds of active objects. Processes may be contained within components, and just as for all model elements, the addition of stereotypes makes it possible to specify the semantics of a dynamic component. The stereotypes «process» and «thread» are predefined by UML.

Subsystems

To speed up the implementation of applications, various components may be grouped within packages according to logical criteria. They are often stereotyped as subsystems to add the concepts of compilation libraries and configuration management to the partitioning semantics already included within packages.

Subsystems organize the implementation view of a system; each subsystem may contain components and other subsystems. By convention, any model component is positioned either at the root level, or within a subsystem. Subsystems should be seen as big bricks for building systems.

Decomposition into subsystems is not a functional decomposition. From the user's standpoint, system functions are expressed within the use case view. Use cases are translated into interactions between objects whose classes are themselves encapsulated in categories. Objects that implement the interactions are distributed into the various categories — the corresponding code is stored in modules and subsystems.

The subsystem in the physical view is the equivalent of the category in the logical view. The following figure shows the correspondence between these two views.

A subsystem provides a means of managing complexity by encapsulating details. Subsystems have a public and a private part. Unless explicitly indicated otherwise, any module positioned within a subsystem is visible from the outside. Subsystems may depend on other subsystems and components, and similarly, a component may depend on a subsystem.