Development Component Structuring 

Naming DCs

Development Components (DCs) combine functionally-related development objects in reusable groups. Dependencies are defined at DC level. 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, see Tips for Naming Components.

Number and Size of DCs

There is no restriction on 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.

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 time, you can start to nest DCs to get smaller units.

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. See Nested Development Components.

●     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 an entity reference to the parent DC.

To make a particular public part entity of the child component visible outside the parent component, the parent has to include a public part entity reference to a public part of the child DC in one of its own public parts.

Any DC that has access to the DC owning this public part can generate a public part entity reference.

●     To avoid nesting 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. See Public Parts.

●     Make public parts as specific and as small as possible (including the entire content of a DC that is still being changed in a public part increases 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 can 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 to 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

Cyclic dependencies are not allowed. You must avoid cyclic dependencies. The best way is to determine the dependencies between function blocks of your software in the planning phase.

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). The build recognizes the cyclic dependencies 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.

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.