Development-Components – Konzepte 

Eine Development-Component (kurz: Komponente oder DC) ist – vereinfacht ausgedrückt – eine gemeinsame Hülle für eine Menge von Objekten, die Teil der Software sind. Eine Komponente hat eine wohldefinierte Schnittstelle nach außen und ein „Innenleben“, das von außen unsichtbar ist. Komponenten können einander verwenden, indem sie sich auf die öffentlichen Schnittstellen anderer Komponenten beziehen. Aufgrund dieser Eigenschaften sind Komponenten die elementaren wiederverwendbaren Einheiten des Modells.

In DCs enthaltene Entwicklungsobjekte

Ein Entwicklungsobjekt (englisch „Development Object“) ist ein Bestandteil einer Komponente, das dieser einen Teil ihrer Funktionalität verleiht und in irgendeiner Weise verändert oder entwickelt werden kann. Dies kann eine Java Klasse sein, ein Web Dynpro View, eine Tabellendefinition, eine JSP Seite, usw. Entwicklungsobjekte werden grundsätzlich als „Quellen“ in einem Repository gespeichert.

Daraus ergibt sich eine naheliegende Forderung an die „äußere Form“ eines Entwicklungsobjekt: Es muss sich in irgendeiner Weise auf eine Datei (oder eine Menge von Dateien) in einem Dateisystem abbilden lassen. In der Entwicklungsinfrastruktur speichern und verwalten Sie Quelldateien im Design Time Repository, das sich nach außen hin wie ein Dateisystem verhält und seine Inhalte in Form von Dateien und Verzeichnissen präsentiert.

Entwicklungsobjekte sind keine Laufzeitobjekte. Sie sind nicht direkt in ein Laufzeitsystem einspielbar.

Entwicklungsobjekte sind innerhalb einer Komponente oft als Pakete oder in Namensräumen organisiert. Ein Beispiel hierfür sind die Packages in Java, oder Namespaces in C++. Das Komponentenmodell übernimmt den Begriff des Pakets auch für andere Entwicklungsobjekte: Pakete definieren eindeutige Namensräume für Entwicklungsobjekte. Analog zu Java haben Pakete hierarchische Namen, und die einzelnen Teile eines Paketnamens werden im Dateisystem auf Verzeichnisse abgebildet. Diese einfache Regel erlaubt es, Entwicklungsobjekte verschiedener Technologien einheitlich nach Namensräumen zu organisieren.

Ein Paket darf nicht gleichzeitig in mehreren Komponenten eingebunden sein. Die Objekte eines Pakets gehören immer vollständig zu einer bestimmten Komponente.

Es ist nicht zwingend erforderlich, eine Komponente durch Einführung von Paketen zu strukturieren. Andererseits ist die Einführung von Namensräumen für Entwicklungsobjekte sinnvoll, um zufällige Namenskollisionen zu vermeiden.

Sichtbarkeitskonzepte von DCs

Komponenten schützen ihr „Innenleben“ nach dem Black Box-Prinzip. Ihre Entwicklungsobjekte sind zunächst für die Außenwelt unsichtbar. Dieses Konzept basiert nicht auf den eventuell vorhandenen technologiespezifischen Mechanismen für Kapselung und Sichtbarkeit der einzelnen Objekte, sondern ist diesen übergeordnet.

Eine Java Klasse wird innerhalb einer Komponente als öffentlich (public) deklariert, weil verschiedene andere Klassen aus unterschiedlichen Packages darauf zugreifen müssen. Es gibt in Java keine Möglichkeit, einem außenstehenden Verwender die Nutzung dieser Klasse zu verbieten, gleichzeitig aber die uneingeschränkte Verwendung im Inneren zu erlauben. Dieses Dilemma kann durch Einbettung der Klassen in eine NetWeaver Komponente gelöst werden: Die kritische Klasse ist unsichtbar für jeden Verwender außerhalb der Komponente, es sei denn, sie wird explizit zu einem Public Part ihrer Komponente hinzugefügt.

Hierarchien von DCs

Eine Komponente kann neben Entwicklungsobjekten auch andere Komponenten enthalten, d.h. Komponenten sind schachtelbar. Eine innere Komponente ist für die Außenwelt zunächst unsichtbar und wird durch die sie umgebende Komponente geschützt. Eine Komponente kann beliebig viele innere Komponenten enthalten, und innere Komponenten können ihrerseits innere Komponenten enthalten. Im Prinzip lassen sich so ganze Komponentenhierarchien erzeugen. Die Wurzeln einer solchen Hierarchie werden gewöhnlich als Top-Level-Komponenten bezeichnet.

Die nachfolgende Abbildung zeigt zwei Beispiele von Komponenten. Komponente A enthält zwei Pakete und einer Menge von Klassen, die nicht zu einem Paket gehören; Komponente B umfasst zwei innere Komponenten, ein Paket und eine paketfreie Klasse.

Diese Grafik zeigt die Schachtelung von DCs und in DCs enthalten Objekte.

Weitere Informationen finden Sie unter Schachtelung von Komponenten.

Verwendungsbeziehungen zwischen DCs

Komponenten können voneinander abhängen und einander gegenseitig benutzen. Dies entspricht dem Gedanken, Software in kleine, überschaubare und wiederverwendbare Einheiten zu strukturieren, die aufeinander aufbauen und über wohldefinierte Schnittstellen kommunizieren. Abhängigkeiten zwischen Komponenten werden zusammen mit den Komponenten definiert. Eine Komponente, die Funktionalität einer anderen Komponente benützten möchte, muss dies explizit deklarieren.

Die Schnittstellen einer Komponente werden als ihre Public Parts bezeichnet. Ein Public Part umfasst eine Liste von Entwicklungsobjekten, die anderen Komponenten zur Verfügung gestellt werden. Alle anderen Bestandteile einer Komponente bleiben verborgen.

Weitere Informationen finden Sie unter Abhängigkeiten zwischen DCs.