Organizing components into hierarchies

The subcomponent relationship can be used to represent a dependency or containment relationship between two components. For example, consider two components that contain source code:

• GPS, which contains source code for a GPS program.
• NavLib, which contains source code for a navigation library.

In this example, the GPS program links with the NavLib library when it is built. You can make NavLib a subcomponent of GPS to show that GPS depends on (and contains) NavLib.

You can organize component into hierarchies to track reuse. If the NavLib program was developed independently by one team and reused by programs that are developed by other teams, the NavLib team can see which other programs reuse NavLib.

Component hierarchy relationships can change over time. When users add or remove relationships between components, those changes are linked to change sets, and can be delivered to other streams and workspaces in the same way as source code changes are delivered.

When a baseline is created on a component that has subcomponents, the full baseline hierarchy is saved. You can view which versions were used together at any point in time. For example, if a problem was reported against a specific version of NavLib, the team can determine which other programs are affected and require a fix by viewing which other component baselines included that NavLib baseline.

In addition to managing reuse and dependencies, component hierarchies help with usability for large-scale development. Component hierarchies can be treated as a unit, so that you can operate on the full hierarchy in one step rather than operating on each component individually. For example, you can add (or remove) a component hierarchy to (or from) your workspace in one step, or accept pending changes for a component hierarchy in one step. This option is useful for component-based development environments, where teams use components that are developed by other teams.

A circular dependency is when two or more components depend on each other. Rational Team Concert source control allows circular dependencies in component hierarchies, but marks them so that you can find and fix them.