Der späte Triumph der Objektorientierten Analyse

Der IT-Hype der neunziger Jahre des vergangenen Jahrhunderts war die Objektorientierung. Was wurde da nicht diskutiert und gestritten über Einfach- und Mehrfachvererbung, über Polymorphismus, über Datenkapselung und über Information Hiding?!

Jede einschlägige Veranstaltung, jedes Fachbuch musste zumindest im Titel das Wort „Objektorientierung“ enthalten. Zahlreiche Studien „bewiesen“, dass objektorientiertes Vorgehen gewaltige Vorteile gegenüber herkömmlichem Vorgehen hätte und, dass es sich „jetzt aber wirklich“ durchgesetzt hätte – oder es zumindest bald tun würde. Und wehe, jemand hätte sich diesem Trend widersetzt – er wäre in der Branche als hoffnungslos veraltet betrachtet worden. Nun, der Hype ging vorüber, der Rauch hat sich gelegt. Geblieben ist die Objektorientierung in den Programmiersprachen; und auch da in der eher pragmatischen Form von Java, C++ und C#. Die puristische Form, wie sie etwa in der Programmiersprache Smalltalk vorlag, konnte sich nicht durchsetzen. Ebenso wenig wie die damals viel diskutierten Objektorientierten Datenbanken. Und auch von der „Objektorientierten Analyse“ ist nicht viel geblieben.

Was bedeutet „Objektorientierung“?

In der Software-Entwicklung haben wir es mit zwei unterschiedlichen Bereichen zu tun: Die Welt der Dinge und die Welt der Aktivitäten. Herkömmlich wird jede der beiden Welten für sich betrachtet: In der Analyse wird ein Datenmodell entwickelt und – davon weitgehend unabhängig – ein Prozessmodell. In einer CRUD-Matrix (= Create, Read, Update, Delete) können die beiden Bereiche miteinander verknüpft werden.

In der Objektorientierten Analyse wird nun der Welt der Daten klarer Vorrang eingeräumt. Das Arbeitsgebiet wird primär in die darin vorkommenden Dinge gegliedert, die – vereinfacht ausgedrückt – als „Klassen“ bezeichnet werden. Die Prozesse sind nicht etwas, das außerhalb oder neben den Klassen abläuft, sondern die einzelnen Aktivitäten werden so organisiert, dass sie in den Klassen bzw. den daraus abgeleiteten Objekten stattfinden. Diese Aktivitäten werden „Methoden“ genannt. Jedes Objekt „tut“ also etwas – und ruft dabei Methoden anderer Objekte auf – die Objekte „sprechen“ miteinander.

Aktuelle Programmiersprachen, wie etwa Java, arbeiten genau so. Auch für die Analyse wurde ein derartiges Vorgehen propagiert, weil das die „natürlichere“ Sicht der Dinge sei. Durchgesetzt hat sich diese Vorgangsweise in der Analyse allerdings nicht. Einer der Gründe dafür liegt wohl darin, dass die Klassen und die Objekte nicht wirklich etwas Reales sind, sondern theoretische Konstrukte, die zwar Realitäten abbilden, aber keine solchen sind.

… und jetzt das Internet der Dinge

Was bedeutet das für die IT-Analyse?

Zunächst einmal: Auch die Entwicklung dieser Systeme wird es erfordern, dass man vor der Entwicklung denkt. Auch hier gibt es Anforderungen, die zu erheben sind. Auch hier müssen diese Anforderungen in Lösungen umgesetzt werden. Es gibt genauso Daten, die gespeichert werden müssen und Prozesse, die zu analysieren sind. So gesehen wird sich gar nicht allzu viel ändern.

Was sich aber ändern wird, ist die Art und Weise, wie wir diese Analyse machen, in welche Bestandteile ein Fachgebiet zerlegt und wieder zu einem System zusammengesetzt werden wird. Hier kommt wiederum die fast schon vergessene Objektorientierte Analyse ins Spiel. Die Klassen und Objekte, die früher nur gedankliche Konstrukte waren und lediglich im Arbeitsspeicher eines Computers und einer Datenbank existiert haben, sind jetzt real. Prozesse, die sie auszuführen haben, werden tatsächlich in Prozessoren ausgeführt, die in den Dingen sind – und sonst nirgends.

Analyse, die sich auf das IoT bezieht, muss eine objektorientierte sein – anders ist es gar nicht möglich. IT-Analytiker, die schon lange genug tätig sind, dass sie noch Bücher über Objektorientierte Analyse im Bücherschrank stehen haben – so wie der Autor dieses Artikels – können diese wieder hervorholen und abstauben. Aber natürlich ist die Zeit nicht stehen geblieben. Und ganz so einfach ist es auch nicht, dass ein „Ding“ im IoT einfach mit einem Objekt einer Klasse im Sinne der Objektorientierung gleichgesetzt werden kann. Eine Klasse setzt sich zusammen aus einer Menge von Attributen und den Methoden, die diese Attribute verändern. Die Struktur eines Objektes im IoT wird aber in den meisten Fällen komplexer sein.

In manchen Fällen ist wahrscheinlich ein eigenes Datenmodell erforderlich, sodass man mit einer einzigen Klasse nicht das Auslangen finden wird. Hier kann eine weitere Entwicklung der jüngeren Zeit unterstützen: Die so genannten NoSQL-Datenbanken, oder dokumentenorientierten Datenbanken, erlauben Datenobjekte mit einer weit komplexeren Datenstruktur als in der herkömmlichen relationalen Welt. Auf diese Weise kann auch eine komplexere Datenstruktur eines „Dings“ in einer Entität, die man in diesem Fall „Dokument“ nennt, abgebildet werden.

Literatur zum Thema

http://www.faz.net/aktuell/wirtschaft/ cebit/cebit-was-eigentlich-ist-das-internet-der-dinge-13483592.html