Development Components

Definition

A development component (DC) represents a software unit that you develop. A DC is always assigned to a certain software component (SC). The DC contains the information for the software unit itself, for the relations with the different DCs and the parts they share - that is, the metadata of the development.

A development object is the part of the DC that you change or develop; it provides the DC with a certain part of its functionality. For example, a development object can be a Java class, a Web Dynpro view, a table definition, a JSP page, and so on. In the DC, you can perform different types of development - for example, you can develop a Java project or a Web Services project.

A DC can also be described as a frame shared by a number of objects, which are part of the software. A DC presents a well-defined interface to the outside world, while its interior life remains invisible. The DCs can use one another by referring to the public interfaces of other DCs. Due to these characteristics, DCs form the basic reusable units of the model.

Use

Naming DCs

Every DC has a globally unique name. DC names are structured hierarchically and contain a unique vendor ID.

Visibility Concepts of DCs

DCs protect their inner life based on the black box principle. Their development objects are not visible to the outside world.

Example

Within a DC, a Java class is declared as public, because a number of other classes from different packages need to access it. In Java, there is no way of denying the use of this class to a user from outside and, simultaneously, allowing unrestricted use inside. This can be solved by embedding the classes into an SAP NetWeaver component: the class concerned is not visible to any user from outside of the component, unless it has explicitly been added to a public part of its component.

If you want to make a part of the software visible to the outside world (that is, other DCs to be able to use it), you have to declare it in a so-called public part of the DC. Then other DCs are able to use the development object of your DC.

Dependencies Between DCs

DCs can depend on one another and use each other. This allows you to organize your software in small, comprehensive and reusable units, which are based on each other and communicate using well-defined interfaces. The dependencies between DCs are defined together with the DCs. To define that a DC wants to use the functionality of another DC, you have to explicitly declare it.

DC Hierarchies

Besides development objects, one DC can contain other DCs, that is, the DCs can be nested . An inner or child DC is invisible to the outside world and protected by the outer or parent DC. A DC can contain any number of inner DCs, and inner DCs can themselves contain inner DCs. This allows you to create DC hierarchies. The root of such a hierarchy is called a top-level component . The enclosing DC is called the parent DC, while the embedded DC is the child DC. 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.

You can restrict the access by using ACLs in the DC definition.
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 public part entity of the child DC visible outside the parent DC, 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.

Example
The figure below shows two examples of DCs. DC A consists of two packages and a set of classes that are not members of a package, whereas DC B encloses two inner DCs, a package, and a package-free class.

Figure 1: Nested development components

Component Build

Development objects must be built before they can be deployed in a runtime system or before other DCs can use them. The build process can require several steps or phases and depends on the types and technologies of the development objects in question and on the desired product.

To build the available component types, the SAP NetWeaver Developer Studio provides build scripts, which relieve you of the task of writing the corresponding make files, ANT files, and so on.

Structure

A DC contains:

The data required by the Developer Studio to set up the development project in the Developer Studio.
The metadata that is required for the relations with other DCs, and for definitions of public parts.
The data required for the development itself - for example, in the Java development this are the sources, the files and folders, the packages and all relevant development information - this is what we call the development object.

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.

Recommendation
We recommend you to choose the DCs in such a way that the involved developers are working in the same team and at the same location.
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.