Wenn man sich mit Komponenten-Orientierung befasst, wird man feststellen, dass es zwei "Schulen" gibt, die etwas unterschiedliche Sichten auf den Komponenten-Begriff haben. Die eine Denkschule hat die Enterprise Applications vor Augen. Bei den Unternehmensanwendungen stehen Themen wie Persistenz, Transaktionen, Verteilung, Webservices etc. im Vordergrund. Im Systems Engieering dominieren hingegen Gesichtspunkte der Modularisierung und Komposition.
Für einen Systems Engieer kann jede Software-Komponente grundsätzlich auch durch einen funktionsgleichen Baustein aus Hardware ersetzt werden -- und umgekehrt. Für Enterprise-Entwickler wird eine Komponente als Software-Einheit gesehen, die vielmehr einen Service realisiert, der zur Erfüllung definierter Aufgaben herangezogen werden kann. Der Systems Engineer baut Systeme, die er aus Komponenten und Subsystemen zusammensetzt. Der Enterprise-Entwickler baut Netze von Mehrwertdiensten, die aus der Kollaboration (möglicherweise transparent verteilter) mehrerer Services entstehen.
So erklärt sich auch, dass in der Enterprise-Welt etwa im Java Kontext die Plain Old Java Objects (POJOs) als Basis für eine Komponente vollauf genügen. Vom Entwickler wird lediglich gefordert, seine POJOs so weit als möglich nur gegen Interfaces zu programmieren. Komponenten-Frameworks wie Spring erledigen dann den Rest. Sie kümmern sich um die Verschaltung von Komponenten, um das Lifecycle-Management und bieten einfache Anbindungen an andere Service-Komponenten, die Persistenz, Zugriffssteuerung etc. ermöglichen.
Systems Engineers benötigen einen konzeptionellen Überbau, wenn Software-Einheiten als Komponenten fungieren sollen. Denn die meisten objekt-orientierten Programmiersprachen bieten keine Komposition an. Objekte lassen sich via Referenzen zwar zu Kollaborationsnetzen verschalten (die Denke der Enterpriseler), nicht jedoch zu Kompositionsbeziehungen. Eine Komponente ist ein Container, der andere Komponenten kapselt und verwaltet. In der Kommunikation zwischen Komponenten arbeiten Systems Engineers typischerweise mit Nachrichten, nicht mit Methoden-Aufrufen. Methoden-Aufrufe sind zu software-spezifisch; Nachrichten taugen in einem Harware- wie auch in einem Software-Umfeld zur Kommunikation. Sie machen alle Kommunikation per se asynchron und frei von impliziten Objekt-Referenzen.
Es ist wichtig, von dieser Unterscheidung zu wissen. Die UML 2 bietet beiden "Schulen" Möglichkeiten zur Modellierung von Komponenten an. Nur kümmert sich die UML nicht darum, den Werkzeugkasten zur Modellierung in die Fächer "Service-Komponenten" und "Komponenten als Funktionsbausteine" zu zerlegen. Darum muss sich der Modellierer selber kümmern.
Für einen Systems Engieer kann jede Software-Komponente grundsätzlich auch durch einen funktionsgleichen Baustein aus Hardware ersetzt werden -- und umgekehrt. Für Enterprise-Entwickler wird eine Komponente als Software-Einheit gesehen, die vielmehr einen Service realisiert, der zur Erfüllung definierter Aufgaben herangezogen werden kann. Der Systems Engineer baut Systeme, die er aus Komponenten und Subsystemen zusammensetzt. Der Enterprise-Entwickler baut Netze von Mehrwertdiensten, die aus der Kollaboration (möglicherweise transparent verteilter) mehrerer Services entstehen.
So erklärt sich auch, dass in der Enterprise-Welt etwa im Java Kontext die Plain Old Java Objects (POJOs) als Basis für eine Komponente vollauf genügen. Vom Entwickler wird lediglich gefordert, seine POJOs so weit als möglich nur gegen Interfaces zu programmieren. Komponenten-Frameworks wie Spring erledigen dann den Rest. Sie kümmern sich um die Verschaltung von Komponenten, um das Lifecycle-Management und bieten einfache Anbindungen an andere Service-Komponenten, die Persistenz, Zugriffssteuerung etc. ermöglichen.
Systems Engineers benötigen einen konzeptionellen Überbau, wenn Software-Einheiten als Komponenten fungieren sollen. Denn die meisten objekt-orientierten Programmiersprachen bieten keine Komposition an. Objekte lassen sich via Referenzen zwar zu Kollaborationsnetzen verschalten (die Denke der Enterpriseler), nicht jedoch zu Kompositionsbeziehungen. Eine Komponente ist ein Container, der andere Komponenten kapselt und verwaltet. In der Kommunikation zwischen Komponenten arbeiten Systems Engineers typischerweise mit Nachrichten, nicht mit Methoden-Aufrufen. Methoden-Aufrufe sind zu software-spezifisch; Nachrichten taugen in einem Harware- wie auch in einem Software-Umfeld zur Kommunikation. Sie machen alle Kommunikation per se asynchron und frei von impliziten Objekt-Referenzen.
Es ist wichtig, von dieser Unterscheidung zu wissen. Die UML 2 bietet beiden "Schulen" Möglichkeiten zur Modellierung von Komponenten an. Nur kümmert sich die UML nicht darum, den Werkzeugkasten zur Modellierung in die Fächer "Service-Komponenten" und "Komponenten als Funktionsbausteine" zu zerlegen. Darum muss sich der Modellierer selber kümmern.