2. Objektorientiertes Software-Engineering

2.1 CASE - OOCASE

Bevor jedoch hier der Schritt zu objektorientiertem Software-Engineering gemacht wird, soll der Begriff SE noch einmal kurz definiert und der Schritt zu CASE vorweggenommen werden.

Software-Engineering ist letztlich die Disziplin der Informatik, die sich mit Verfahrensweisen beschäftigt, die das Erstellen größerer Software-Projekte mit hohem Qualitätsanspruch erleichtert. SE bezeichnet genauso das Gebiet der Anwendung wie auch das Gebiet der Entwicklung dieser Verfahrensweisen.

CASE steht nun für Computer Aided Software Engineering. Hier wird versucht, computergestützte Werkzeuge zu erstellen, mit denen bestimmte Prozesse im SE erleichtert oder gar automatisiert werden können. Es dürfte kaum schwer sein, zu erkennen, daß gerade im Bereich der Modellierung und Repräsentation von Problemen und deren Lösungen Software selber ein hilfreiches Werkzeug sein kann.

Es haben sich verschiedene Vorgehensweisen beim Zerlegen einer Aufgabenstellung aus der realen Welt herausgebildet, die alle jeweils nach unterschiedlichen Schwerpunkten des Problembereiches suchen, und diese in einer speziellen Notation darstellen (siehe Methoden weiter unten). Hier können Tools benutzt werden, die die Arbeit der Modellierung vereinfachen, indem sie den Ingenieur auf die jeweilige Notation festlegen, ihm das Verwalten der Daten abnehmen und andere Hilfsmittel zur Verfügung stellen, wie das automatische Anbinden von Dokumentation an die dargestellten Sachverhalte, das Ausblenden gerade nicht gewünschter Detailinformationen aus den Diagrammen und das Verteilen der Daten an weitere Personen.

Natürlich können CASE-Tools auch andere Tätigkeitsbereiche unterstützen, die weniger die erstellte Software betreffen, jedoch auch zum SE gerechnet und als Qualitätsfaktoren für Software angesehen werden. Hierzu gehört das Verwalten der nötigen Ressourcen wie Personen, Zeit und Geld genauso wie das Erstellen gut strukturierter Dokumentation für den Endanwender, Versionskontrolle und die sichere Speicherung aller wichtigen Informationen. Es gibt sicherlich keinen Tätigkeitsbereich des SE, der nicht von computergestützten Werkzeugen profitieren kann.

Im allgemeinen Trend in der Informatik objektorientiert zu denken, gibt es nun auch eine ganze Reihe von Methoden, die einzelnen Arbeitsschritte im SE an den Datenobjekten des Problembereichs orientiert durchzuführen und zu dokumentieren (siehe Abb. 4).

Methode	Object-Oriented Design (OOD)	Object-Oriented Analysis (OOA)	Object-Modeling Technique (OMT)	Object-Oriented Software Engineering (OOSE)
Vertreter	Grady Booch	Peter Coad, Edward Yourdon	James Rumbaugh, u.a.	Ivar Jacobson
Vorgehensweise	1) Klassen und Objekte identifizieren  2) Semantik der Klassen und Objekte identifizieren  3) Beziehungen zwischen Klassen und Objekten identifizieren  4) Klassen und Objekte implementieren	1) Klassen und Objekte identifizieren  2) Strukturen identifizieren  3) Subjekte identifizieren  4) Attribute definieren  5) Services definieren	1) Erste Problembeschreibung schreiben oder besorgen  2) Objektmodell erstellen  3) Dynamisches Modell entwickeln  4) Funktionales Modell konstruieren  5) die drei Modelle prüfen und verfeinern	1) Anwendungsfälle konstruieren  2) Schnittstellen spezifizieren  3) Objektmodell des Problembereiches erstellen  4) Objektmodell verfeinern
Anmerkungen	Haupteinfluß auf Unified Method  OOD ist hier eine Methode und hat nichts mit OOD zu tun!	Beziehungen zwischen Klassen werden Strukturen genannt.  Klassen, die durch Strukturen verbunden sind, werden zu Subjekten zusammengefasst.  OOA ist hier eine Methode und hat nichts mit OOA zu tun!	Das dynamische Modell beinhaltet Zustandsdiagramme (siehe 4.2) u.ä., während das funktionale Modell den Daten- und Kontrollfluß modelliert.	Das Anwendungsfallorientierte Vorgehen ist nennenswert, und wurde auch in die Unified Method übernommen (Use Cases).      OOSE ist hier ......  (siehe OOD und OOA)

 

Allen Methoden ist freilich gemein, daß der Problembereich nach Dingen durchsucht wird, denen gewisse Eigenschaften, wie Zustand o. ä. gemeinsam sind (Attribute), mit denen auf ähnliche Weise umgegangen werden kann (Methoden in C++) und die von ihrer Struktur her einander verwandt erscheinen. Diese können in Klassen gekapselt werden, und wenn es möglich ist, auf gemeinsame "Basisklassen" zurückgeführt werden. Hierbei kann sehr leicht erreicht werden, daß die identifizierten Objekte über festgelegte Schnittstellen angesprochen werden können, ohne die Details deren Implementierung kennen zu müssen. Dieses Vorgehen steigert die Datenkapselung, Modularisierung und Abstraktion, was der Wiederverwertbarkeit, Wartbarkeit und Fehlerbehebung zu Gute kommt. Die Auswirkungen sind nicht nur für spätere Projekte, sondern auch für den iterativen Verfeinerungsprozeß eines einzelnen Projektes von Vorteil.

Alle genannten Eigenschaften zeichnen sicherlich auch das objektorientierte Programmieren aus, jedoch werden die verwendeten Vorgehensweisen bei SE im größeren Rahmen, und vor allem auch losgelöst von der endgültigen Implementierung angewendet. So werden zum Beispiel logisch, also von ihrer Position im Problembereich her ähnliche Klassen oder Objekte oft zu eigenen Paketen "zusammengeschnürt" um das Modell übersichtlicher zu halten, selbst wenn die jeweilige Implementierung nachher zum Beispiel in der gleichen Quellcodedatei landet. Überhaupt ist es, wenn auch nur schwer, grundsätzlich möglich, als Implementierungssprache eine nicht objektorientierte Sprache einzusetzen.

2.2 Object Oriented Analysis und Object Oriented Design

Zwei Begriffe , die immer wieder auftauchen, sind OOA und OOD. Obwohl beides auch Bezeichnungen zweier spezifischer Methoden des OOSE sind, stehen sie allgemein für zwei grundlegende Teilgebiete jeder OOSE Vorgehensweise (siehe Abb. 5). OOA, was für Object Oriented Analysis steht, beschränkt sich darauf, Darstellungen und Abstraktionen des Problembereiches zu schaffen, und so diesen ausreichend zu modellieren, während Object Oriented Design, also OOD, die entwickelten Modelle um diejenigen Abstraktionen erweitert, die notwendig werden, um das Gesamte in eine Implementierung abbilden zu können. Dazu gehört das Entwerfen von Klassen zur Benutzerführung, Ein-/Ausgabe der Daten, Speicherung und ähnlichen Aufgaben. Die Einteilung in OOA und OOD ist aber oft gar nicht einfach, die Grenze wird bei den unterschiedlichen Methoden an verschiedener Stelle gezogen und bestimmte Methoden sehen gar nicht vor, das Identifizieren von Klassen des Problemraumes von dem der Klassen des Lösungsraumes zu trennen.

Was das alles konkret bedeutet, was man genau unter den einzelnen Methoden zu verstehen hat und wo sich die OO-Vertreter noch uneins sind, kann hoffentlich in noch folgenden Beispielen erläutert werden.