Development Components – Concepts 

Definition

A development component (DC) is an object in the SAP NetWeaver Developer Studio that 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 between 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. A development object can be a Java class, a Web Dynpro view, a table definition, a JSP page, and so on. Development objects are always stored as “sources” in the DTR repository. In a DC you can perform different types of development – for example, you can develop a Java project or a Web Services project.

Development objects are not runtime objects. They cannot be run directly in a runtime system.

In the SAP NetWeaver Development Infrastructure (NWDI), you store and manage the source files in the DTR, which behaves like a file system and presents its contents in the form of files and folders to you.

A DC can also be described as a frame shared by a number of objects, which are part of the software. A component 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

Within a DC, the development objects are often organized as packages or in namespaces. Just like in Java, the packages have hierarchical names, and the individual parts of a package name are mapped to folders in the file system. This allows you to organize the development objects of different technologies uniquely by namespaces.

A package must not be included in different components simultaneously. The objects of a package always completely belong to a certain component.

Visibility Concepts of DCs

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

This concept is not based on technology-specific encapsulation and visibility mechanisms for the individual objects, but is superior to them.

Within a component, 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 a 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.

DC Hierarchies

Besides development objects, a component can contain other components: components can be nested. An inner or child component is invisible to the outside world and protected by the outer or parent component. A component can contain any number of inner components, and inner components can themselves contain inner components. This allows you to create component hierarchies. The root of such a hierarchy is usually called a top-level component.

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

Nesting development components

For more information, see Nesting Components.

Dependencies Between DCs

Components 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 components are defined together with the components. To define that a DC wants to use the functionality of another DC, you have to explicitly declare it.

The interfaces of a component are called its public parts. A public part consists of a list of development objects offered to other components. All other parts of the component remain invisible.

For more information, see Dependencies Between DCs.

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 will be the sources, the files and folders, the packages and all relevant development information – this is what we call the development object. These development objects are stored in the Design Time Repository (DTR), which is your project repository.