Dienstag, Juni 24, 2008

Komponenten-Orientierung: Service vs. Funktionsbaustein

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.

Mittwoch, Juni 18, 2008

Alles ist ein Eingabegerät

Ich weiß, ich bin spät dran, wenn schon Spiegel-Online darüber berichtet in "Massenmordversuch an der Maus" (Christian Stöcker, 18. Juni 2008). Aber diese Idee ist so schön und abgefahren, das muss man sich ansehen -- ich habe ein Faible für solche Ideen (siehe auch "Sichtweisen in 3D: Balance halten"). Genug der Worte. Nehmen Sie eine Flasche, einen Tacker, einen Stift, Ihren Fingerverband, was auch immer ... oder eine Maus, und legen Sie los:



Ärgern Sie sich auch darüber, weder selbst darauf gekommen zu sein, noch -- falls Sie die Idee hatten -- es umgesetzt zu haben?

Was könnte man damit alles machen? Haben Sie Ideen?

Freitag, Juni 13, 2008

Von der falschen Rede

Eine kleine Anekdote: In der Vorlesung zu den Grundlagen der Informatik sprach ich heute von Rekursion und Iteration. Ich erklärte, was Rekursion ist. Die Studierenden merkten auf und unterbrachen mich: "Sie meinen Rekursion!". "Wie bitte? Habe ich etwas anderes gesagt?" "Ja, sie sagten Iteration." "Oh sorry, ich meinte Rekursion." Da hatte mir mein Hirn einen Streich gespielt, der mir vollkommen unbemerkt blieb. Ich glaubte mich etwas sagen zu hören, was ich nicht gesagt hatte. Kennen Sie das? Haben Sie bestimmt auch schon einmal erlebt.

Also startete ich einen neuen Versuch "Rekursion ist, wenn sich die Funktion selber wieder aufruft." Und schoss die Frage hinterher: "Habe ich Rekursion gesagt?" "Ja", lautete die Antwort unisono.

Während ich weiter sprach, blieben meine Gedanken an der letzten Frage hängen: Irgendwie war die Frage dumm gewesen. Stellen Sie sich einmal vor, das wäre nur mein Gedanke, meine Sprachabsicht gewesen. Tatsächlich hätte ich aber (fälschlicherweise) gesagt: "Iteration ist, wenn sich die Funktion selber wieder aufruft". Und meine Frage wäre mir ebenso falsch über die Lippen gekommen "Habe ich Iteration gesagt?". Dann wäre die Antwort der Studierenden mit "Ja" ebenso korrekt gewesen. Sprich, meine Nachfrage "Habe ich Rekursion gesagt?" war vollkommen unsinnig und überflüssig. Zumindest aus einer logischen Betrachtungsweise. Wenn mein Hirn mir einen Streich spielt und mir meine gedachten Worte unbemerkt mit der Lautbildung eines anderen Wortes über die Lippen kommen, dann bin ich chancenlos. Oder?

In der Tat bin ich das, wenn mein Gehör die Rede anderer ebenso konsistent falsch hört. Die eigene Rede ist davon ausgenommen, da das Ohr bezüglich der eigenen Rede extrem voreingenommen ist. Es weiß ja, was es hören soll -- und das verführt zu einer gewissen Nachlässigkeit. Also muss das Sprechen und das Hören zeitlich entzerrt werden. Ich muss aktiv Feedback einholen. Und solange die Anteile zur Sprachbildung und Spracherkennung nicht über den gleichen Fehler gekoppelt sind, dann sind Abweichungen erkennbar, wenn man das richtige Feedback einfordert.

Wie hätte nach meiner Erläuterung der Rekursion die Nachfrage lauten sollen? Richtig: "Wie nennt man den Prozess des Selbstaufrufs einer Funktion." Die Studis hätten "Rekursion" gesagt und ich hätte eine Chance zur Fehlererkennung gehabt, da mein Sprechen das Wort nicht wieder falsch einbringen konnte.

Die Moral von der Geschicht? Stellen Sie niemals Ja/Nein-Fragen, wenn Sie Ihren Geisteszustand überprüfen wollen. Oder, um den Bezug zum Software Engineering herzustellen: Stellen Sie einem Kunden, wenn Sie z.B. Anforderungen erheben wollen, möglichst keine Ja/Nein-Fragen. Ja/Nein-Fragen erhöhen das Risiko, dass Sie eigene Inkonsistenzen oder ein irrtümliches Verständnis nicht aufdecken.