Organizing components into hierarchies
You can organize components into hierarchies. Each component can have multiple subcomponents (children) and a component can be shared by multiple parent components.
About this task
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 you view the history of a parent component that has child components, the history view displays change sets only from the parent component.
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. When working with changes made in a component hierarchy, you can configure the Pending Changes view to show components as a hierarchy. 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. You can deliver or accept all pending changes for all components in an entire component hierarchy in one step by using the Deliver to Hierarchy or Accept from Hierarchy options available in the context menu of Pending Changes view. 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. Engineering Workflow Management source control allows circular dependencies in component hierarchies but marks them so that you can find and fix them.