!--a11y-->
Modeling Development Components 
A development component is a container for development objects; it can contain other development components. A development object is a versioned file (for example, a Java class, a Web Dynpro view, a table definition, or a JSP page). A development component exactly corresponds to one project. A project is of exactly one type or one technology (Java, J2EE, Web Dynpro, Web Service, Java Dictionary).
A development component embedded in another development component can be of another type than the embedding development component. An inner development component always belongs exclusively to the enclosing development component. This means that one development component cannot be the inner development component in two different enclosing development components at the same time. In addition, development components can use one another by referring to the public interfaces of other development components, the so-called public parts. A public part is a list of development objects provided to other development components. All other parts of a development component remain invisible. A development component can define any number of public parts, each of which must have a unique name.
Due to these properties, development components are software modules an application developer can use both to structure the application to be developed and to reuse a finished application. In the documentation on the J2EE Technologies in the SAP Web Application Server, development components and how to model them are introduced in the Developer’s Guide under Working with the Development Infrastructure.
In this step, identify the required development components (both the development components that need to be created and those that can be reused), their hierarchical structure, their dependencies, and the public parts to be published. With the development component diagram, you can model this level of abstraction as described in the Developer’s Guide under Working with the Development Infrastructure. For our example Book2Fly, the following development component diagrams are possible:

Because a development component is a container for any kind of development objects and a development object is part of a software product to be developed (for example, a Java source file, a Web Dynpro view, a table definition, a database content, or a JSP page), the first step is needed to clarify and define from which parts the software product will be made up.
A development component is symbolized both in the development component diagram and in the UML component diagram by a special rectangle that carries the name of the development component. Public parts are symbolized by small rectangles on the development components that carry the name of the public part.
In our example, we need a Web Dynpro project development component Book2FlyProjectDevelopment-Component, which encapsulates the Web Dynpro part. In addition, the development component CustomerProjectDevelopment-Component of the J2EE project enables you to access the customer data using EJBs.
After determining the development components you need to develop the new application, you should find out whether any previously developed development components can be reused for the new application.
In our example, we already have a development component for managing customer data, so we can use the CustomerProjectDevelopment-Component for our needs.
The property that allows a development component to embed other development components, can be used both for structuring the embedding development component and for reusability within the embedding development component.
The embed relation between two development components is represented in the development component diagram by picturing the embedded development component within the embedding development component.
The development component diagram (a) allows you to reuse the CustomerProjectDevelopment-Component even outside of our example, which is reasonable, because customer data must be managed in other applications as well. The development component diagram (b), however, encapsulates the CustomerProjectDevelopment-Component and thus makes it impossible to reuse it outside of the Book2FlyProjectDevelopment-Component, which, in our case, is not reasonable, because customer data must be managed in other applications as well.
The dependency between two development components is symbolized in the development component diagram by a ”depends” edge giving a direction. The edge points to the public part of a development component, on which another development component depends.
In our example, the Book2FlyProjectDevelopment-Component uses the CustomerProjectDevelopment-Component to read and write customer data; therefore, it depends on this component.
A development component can publish development objects from the public parts of an inner development component in its own public parts. This process is called propagation of the public parts. It makes the functions of inner development components available to the outer world. A development component can publish either the entire public part of an inner component or only certain parts of it. This enables the development component to reorganize, enhance, or limit the functions of its inner development component und to combine these functions with its own.
Publishing one public part within another is symbolized in the development component diagram by an edge that gives a direction; it contains the name of the part to be published. If the entire public part is published, the edge contains the label ”propagate”. The edge points from the public part to be published to the public part in which it is published fully or in parts.
In development component diagram (b), the public part of the CustomerProjectDevelopment-Component is not published in the public part of Book2FlyProjectDevelopment-Component. Thus, the functions of CustomerProjectDevelopment-Component are not available outside of Book2FlyProjectDevelopment-Component.
