Development Components – Concepts

A development component (short: component or DC) can 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. Components can use one another by referring to the public interfaces of other components. Due to these characteristics, components form the basic reusable units of the model.

Developement Objects Contained in DCs

A development object is a part of a component that can be changed or developed in some way; it provides the component with a certain part of its functionality. A development object may 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 a repository.

This results in an obvious request concerning the outer form of a development object: There must be some way of mapping it to a file (or a set of files) in a file system. In the development infrastructure, you store and manage source files in the Design Time Repository, which behaves like a file system and presents its contents in the form of files and folders to the outside.

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

Within a component, development objects are often organized as packages or in namespaces. Take the packages in Java or the namespaces in C++ as an example. The component model adopts the term package also for other development objects: packages define unique namespaces for development objects. As in Java, packages have hierarchical names, and the individual parts of a package name are mapped to folders in the file system. This simple rule allows you to organize 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.

However, you are not forced to organize a component by introducing packages. On the other side, it makes sense to introduce namespaces for development objects in order to prevent accidental name collisions.

Visibility Concepts of CDs

Components protect their inner life with the black box principle. Their development objects are invisible 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 dilemma can be solved by embedding the classes into a NetWeaver component: The class concerned is invisible 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.

This diagram shows how DCs and objects in DCs can be nested.

For more information, refer to Nesting Components.

Use Dependencies Between DCs

Components can depend on one another and use one another. This corresponds to the idea of organizing software in small, comprehensive and reusable units, which are based on one another and communicate using well-defined interfaces. Dependencies between components are defined together with the components. A component that wants to use the functionality of another component, must declare its intention explicitly.

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.