Structuring Development Components 

DCs combine functionally related development objects in reusable groups. On the DC level dependencies are defined. DCs are the units the CBS builds. The names of DCs determine the hierarchy of the folders in the DTR; they cannot be changed. For more information on DC names, see Tips for Naming Components.

You cannot delete DCs.

Number and Size of DCs

Generally, there is no restriction to the size of a DC. Since DCs represent the units for the build process, DC size considerations can speed up the development process.

·        Choose the DC structure according to its function and not according to the organization structure of the responsible developers.

¡        If possible, choose the DCs in such a way that the involved developers are working in the same team and at the same location – only with these prerequisites can you use the inactive state of objects, which is mandatory for distributed responsibilities.

·        For generic functions, create individual DCs to facilitate their reusability. Try to collect all required elements of the function in this DC.

·        Spend sufficient time with planning the API and separate API and implementation. You can:

¡        Add the API to a public part of your DC.

·        After a change, the entire DC must be rebuilt. Therefore, choose the size carefully so that it does not contain too many objects. If a DC grows too much over the time, you can start to nest DCs to get smaller units.

 

As a rule of thumb, DCs can reach a size, where up to four developers are responsible for development objects (Java classes, interfaces, table definitions). If DCs grow bigger than that, the developers usually get in each other’s way.

Nesting DCs

DCs can contain development objects or other DCs. The enclosing DC is called the parent DC while the embedded DC is the child DC. For the visibility of the embedded DCs the same rules apply as for development objects.

·        You can use the nesting technique if a DC has become too large. Create a child DC and publish the functions needed on the outside in the public parts of the parent DC. You can now change and build the new smaller units.

If you nest DCs, the content of the child DCs is visible only to their parent and “sibling” DCs. To make functions available outside of the parent DC, you must add the public parts of the child DC as entity reference into the parent DC.

·        To avoid the nesting of DCs, you can restrict the access by using ACLs in the DC definition.

Public Parts

Objects released for the use by other DCs are contained in the public parts. They can have the purposes Assembly and Compilation.

·        Make public parts as specific and small as possible (including the entire content of a DC, which is still being changed, into a public part increases the system load considerably): The automatic rebuild of used DCs is necessary only if in your change you use a public part that refers to the used DC. You can avoid unnecessary rebuilds by publishing objects that will probably be used by different DCs to different public parts: Every DC can contains several public parts – even of the same type.

·        The same reason that recommends you to make public parts small and specific also applies for the use – to avoid unnecessary rebuilds. Whenever possible, refer to public parts and not directly to their DCs.

Use Dependencies

You must define use dependencies between DCs if you want your DC to use objects from a public part of another DC. Use dependencies are checked by the DC build.

Dependency Type

We distinguish between four phases in the development cycle of a DC.

·        Design Time

·        Build Time

·        Deploy Time

·        Runtime

The use of a DC specifies the phase at which a DC is needed. You can combine different uses. However, not all uses and combinations make sense. For more information, see Dependencies Between DC Types.

If you nest DCs, the content of the child DCs is visible only to their parent and “sibling” DCs. To make functions available outside of the parent DC, you must add the public parts of the child DC as an entity reference into the parent DC.

Cyclic Use Dependencies

A cyclic use dependency is a dependency of the type “DC A uses DC B and DC B uses DC A“ (the cyclic use can also include more intermediate steps, like DC A  ® DC B ® DC C ® DC A). Cyclic dependencies are not allowed; the build recognizes them and does not build them. The reason is that there is no clear definition of which DC to build first and that a use dependency would have to be violated.

Avoiding Cyclic Dependencies

You must avoid cyclic dependencies. The best way is to determine the dependencies between function blocks of your software as early as in the planning phase, even before you realize the structure in the JDI.

Resolving Cyclic Dependencies

Cyclic dependencies may occur if a DC has become too large. In this case, you can distribute the development objects needed outside of the DC to several public parts, but all using DCs still have a dependency to the same DC. If you have accidentally defined a cyclic dependency because several DCs have dependencies to different objects of the same DC, you can resolve it by evacuating functions of the DC into a new DC.

In this process, it may be useful to distribute implementation and API of a DC to two DCs. An example is the separation of Java interface and implementing class.