Umfragen bestätigen, daß viele Firmen zumindest angeben, sich jetzt schon mit Objekttechnologie zu befassen. Beim Nachfragen kommen allderings oft Zweifel auf. Das akurate Erfassen, wie viele Firmen tatsächlich Objekttechnologie einsetzen, ist fast unmöglich.
Eine jüngste Umfrage der Zeitschrift OBJEKTSpektrum zeigt die folgenden Trends:
Bei der sd&m GmbH & Co. KG München realisieren wir derzeit eine große Client/Server-Anwendung für die Deutsche Bahn AG in einer rein objektorientierten Umgebung:
Es wird angestrebt, in einer der nachfolgenden Ausgaben der Softwaretechnik-Trends einen ausführlichen Erfahrungsbericht zu veröffentlichen.
Die breite Einführung von Objekttechnologie erfordert in den Unternehmen die Lösung einer Reihe von Aufgaben, die der Analyse und dem Entwurf nachgeordnet sind, und die für Wirtschaftlichkeit, Qualität und die strategische Einführung ausschlaggebend sind. Wichtige Aufgaben dieser Art sind:
In letzter Zeit ist ein zunehmendes Interesse der Anwender an der Verbindung
relationaler Datenbanken auf der Datenseite mit objektorientierten
Softwaretechniken auf der Schemaentwurfs- und Anwendungsentwicklungsseite zu
beobachten.
Erklärtes Ziel ist es, die bewährte und ausgereifte relationale
Technologie mit der sich rasch entwickelnden objektorientierten Technologie
zum Nutzen von Entwicklern und Endanwendern zu verbinden.
Im Vortrag wird der Stand der Technik in bezug auf Entwicklungsstrategien,
einsetzbare Werkzeuge und Forschungsarbeiten charakterisiert. Zukünftige
Arbeiten konzentrieren sich auf die Implementierung objektorientierter Modelle
durch relationale Datenbanken, Reengineering durch Migration und
Wiederverwendungsaspekte.
Entwurfsmuster sind die Fortsetzung des Wiederverwendungsprinzips auf einer höheren Stufe der Wertschöpfung: Sie dokumentieren Expertenwissen. Das Phänomen des "außergewöhnlichen Entwerfers" ist in der Mustererkennung angesiedelt ("great designer" nach Frederick P. Brooks). Der Experte entwirft musterorientiert: kreativ und zugleich hocheffizient. Sein Fundus an Mustern bestimmt, wann der Entwurf in sich stimmig ist. Muster als "kognitive Skripte" sind ein zentrales Thema der Kreativitäts- und Gedächtnisforschung.
Wie kann der unerfahrene Entwerfer die Erfahrung der Experten nutzen? Wie läßt sich Entwurfserfahrung für die Wiederverwendung dokumentieren? Entwurfsmuster stehen für das Wissenspaar aus "Problem & Lösung", das sich in einem bestimmten Entwurfskontext als zeitlos gültig und effizient erwiesen hat. Der Architekt Christopher Alexander zum Beispiel lehrt den Gebäude-Entwurf mit Hilfe von ca. 250 Mustern. Bei der Siemens-AG werden entsprechende Anstrengungen für die Softwaretechnik unternommen. International erforscht und diskutiert die "Hillside-Pattern-Group" (AT&T Bell Labs, IBM) Software-Entwurfsmuster.
Die Muster-Bewegung in der Informatik ist ein Phänomen ohnegleichen in ihrer Disziplin: Musterbücher für den objektorientierten Software-Entwurf werden zu Bestsellern. Jede Fachkonferenz zur objektorientierten Softwaretechnik ist mit diesem Thema besetzt (OOPSLA, ECOOP, OOP). Eigene internationale Workshops gibt es bereits, wie PLoP oder EuroPLoP: "Pattern Languages of Programming". Die wissenschaftliche Gemeinschaft, die Design Pattern zum Terminus technicus erhebt, surft im Internet: Ausgangspunkt ist die Pattern-Homepage (http://st-www.cs.uiuc.edu/users/patterns/patterns.html). Die theoretischen und praktischen Aspekte werden in einer Mailing-Liste diskutiert, die bezüglich ihrer Frequentierung ihresgleichen sucht (http://iamwww.unibe.ch/~fcglib/WWW/OnlineDoku/archive/DesignPattern).
Von besonderem Interesse ist der didaktische Wert eines Entwurfsmusters: In der akademischen Lehre (Übungen und Seminare) und in der industriellen Schulung (Training) lassen sich mit diesem Lehr- und Lernvehikel Anfänger effizient auf das Erfahrungsniveau eines Experten bringen. Es wäre zu diskutieren, welche Mindestmenge an Entwurfsmustern für welche Entwurfskategorie (Frameworks, Standard-Architekturen etc.) als Lehr- und Ausbildungsziele gefordert werden sollte. Weitere Ziele eines eigenständigen Arbeitskreises Entwurfsmuster oder eines gemeinsamen Arbeitskreises Frameworks und Entwurfsmuster wären: Grundlagen (Skill-Erwerb), Beschreibungsschemata (narrativ oder formal), Software-Musterbücher (Studium und Rezension) und Ansätze für eine Didaktik der objektorientierten Software-Entwicklung.
Objektorientiertes Testen unterscheidet sich vom Test klassischer, imperativer Programme:
Software und die zu ihrer Entwicklung erforderliche Technologie sind zu einem
strategischen Feld geworden, um auch künftig die Wettbewerbsfähigkeit
von Unternehmen auf dem Weltmarkt zu sichern. Dabei spielen die Qualität
der Software-Produkte und des Software-Entwicklungsprozesses eine entscheidende
Rolle. Seit Mitte der siebziger Jahre wurden verstärkte Anstrengungen
unternommen, um die Qualität von Software beurteibar, nachweisbar und
steuerbar zu machen.
Der Vortrag gibt einen Überblick über Maßnahmen - insbesondere
Metriken und Test-Verfahren - die zur Erfüllung von
Qualitätsanforderungen in der objektorientierten Software-Entwicklung
durchgeführt werden. Außerdem zeigt er auf, daß die Anwendeung von Metriken für die Optimierung der Qualität von Software-Produkten
und -Prozessen nicht ausreichend ist, sondern eine zielgerichtete und
systematische Qualitätsverbesserung durchgeführt werden muß.
Das objekt-orientierte Paradigma beschreibt eine Reihe von Techniken, die Design, Spezifikation und Implementierung umfangreicher Software-Systeme unterstützen. Es erlaubt die Entwicklung modularer, verteilter Programmsysteme, unabhängig von organisatorischen und technischen Randbedingungen wie verwendeten Werkzeugen, Betriebssystemen und Protokollarchitekturen. Durch die Anwendung standardisierter Objektmodelle in Verbindung mit zugehöriger Laufzeitunterstützung profitieren sowohl die Entwickler als auch Vertreiber und Nutzer der Programmsysteme von den positiven Auswirkungen eines objekt-orientierten Systementwurfs.
Ist die reale objekt-orientierte Welt jedoch so ideal, wie es viele euphorische Berichte vermuten lassen? Gerade im Umfeld offener Verteilter Systeme läßt sich diese Fragestellung umfassend behandeln. In einer verteilten Umgebung müssen viele derjenigen Aspekte explizit betrachtet werden, die im nicht verteilten Fall implizit durch Sprach-Compiler und Laufzeitsystem behandelt werden. Speziell in Verteilten Systemen sind weiterhin alle diejenigen Probleme zu beachten, die sich aus einem Miteinander verschiedener Objektmodelle, Laufzeitsysteme und Protokollarchitekturen ergeben.
Insbesondere in Verteilten Systemen ist eine Unterscheidung zwischen Klassifikationsmethoden zur Designphase eines Systems (Typen) und zur Laufzeit eines Systems (Klassen) erforderlich. Es sind zugehörige Vererbungstechniken zu entwickeln und zusammen mit Regeln für das dynamische Binden von Objekt-Schnittstellen zu einem homogenen Gesamtmodel zu vereinen. Auf diesem Gebiet dürfte auch zukünftig eine enge Zusammenarbeit zwischen der Entwicklung theoretischer Grundlagen der Objektorientiertheit und der Entwicklung objektorientierter Verteilter Systeme erforderlich sein. Die Arbeiten im Bereich des Open Distributed Processing - ODP des JTC1/SC21 der International Standardisation Organisation - ISO stellen dabei ein zu beachtendes Beispiel für ein theoretisches Fundament dar. Daneben sind eher praktische Ansätze wie das Component Object Model - COM (Stichwort: OLE) von Microsoft oder insbesondere die universelle Object Management Architecture - OMA (Stichwort: CORBA) der Object Management Group - OMG besonders zu beachten.
Ob die Phase der oo-Euphorie in eine Phase der Ernüchterung übergeht, sobald in großen Projekten festgestellt wird, daß die Anwendung objektorientierter Konzepte kein Allheilmittel zur Beherrschung komplexer Probleme ist, bleibt abzuwarten. Sicher dagegen ist, daß insbesondere im Bereich Verteilter Systeme Fragestellungen wir die Interoperabilität verschiedener Objektsysteme, der Wunsch nach Programmportabilität, die Schnittstellenstruktur von Objekten (multiple interfaces) und letztendlich auch die Fähigkeit zur Behandlung multimedialer Datenströme (Audio/Video-Streams) eine gewichtige Rolle spielen werden.
Die Objektorientierte Modellierung hat das Ziel, einen Informationsbereich zu erfassen und wiederzugeben. Die Verwertungsmöglichkeiten der Ergebnisse der Modellierung sind dabei Eigenschaften der Methode, nicht erst des Werkzeugs. Allerdings müssen alle drei Aspekte im Umfeld der Modellierung - das (methodenspezifische) Vorgehensmodell, die Methode selbst und das unterstützende Werkzeug - aufeinander abgestimmt sein, um gut miteinander zu harmonieren. Die repräsentierten objektorientierten Modelle verfügen über statische und dynamische Aspekte, letztere sind in gängigen Methoden häufig unterrepräsentiert. Dies gilt in besonderer Weise für den Verwertungsaspekt Modellüberprüfung.
Das in Ilmenau in einer Dissertation entstandene und seitdem in zahlreichen Diplomarbeiten und zwei weiteren Dissertationen weitergeführte Objekt-Prozeß-Modell (OPM) ist eine voll objektorientierte Notation für dynamische Aspekte, in der neben Objekten und Prozessen insbesondere Vor- und Nachbedingungen, aber auch Zeiten und Prioritäten abgelegt werden. Der methodenspezifische Modellierungsprozeß heißt Objektorientierte Prozeßmodellierung und deckt auch die statischen Aspekte ab - allerdings in etablierter Notation. Die U_berprüfung der OPMs ist über generierte Petri-Netze simulativ und über in den Quellcode des ausführbaren Programms generierte Tests zur Laufzeit möglich. Die Umsetzung erfolgte in der Objekttechnologie-Werkbank. (Weiter Informationen unter: http://www.prakinf.tu-ilmenau.de/proinf/otw.html)
Heutzutage weit verbreitete objektorientierte Analyse- und Designmethoden wie
die sogenannte "Unified Method" von Booch oder die darin eingeflossenen
Methoden OMT von Rumbaugh et al. und Objectory von Jacobson bieten eine fast
nicht mehr überschaubare Vielfalt von Diagrammarten und
Modellierungskonstrukten an.
So ist dem Benutzer der entsprechenden Methode oft nicht klar (und den
entsprechenden Veröffentlichungen ggf. auch nicht zu entnehmen), welche
Wechelsbeziehungen zwischen verschiedenen Diagrammarten und zwischen den
Konstrukten einer Diagrammart existieren können. So wurden im Vortrag
exemplarisch Mehrdeutigkeiten bei der Verwendung der Paare
Vererbung/Assoziation, Assoziation/Aggregation und
Sichtbarkeitsgraphen/Klassendiagramme vorgestellt. Des weiteren wurde auf
Defizite der meisten Methoden in punkto Modularisierung (oberhalb der Ebene
einzelner Klassen) hingewiesen.
Ziel dieser Ausführungen war es, Argumente für einen Arbeitskreis
"Grundlagen von OOA- und OOD-Methoden" zu liefern, der sich nunmehr in der
Gründungsphase befindet.
Die Größe und Komplexität heutiger Softwaresysteme und die Anforderungen an diese Systeme erfordern die Unterstützung der Softwareentwicklung im Bereich des Prozeßmangegements und des Konfigurationsmanagements. Ein integrierter Ansatz, der beide Bereiche unterstützt, koordiniert die Aktivitäten der Entwickler im Hinblick auf Versionierung, Konfigurierung und Konsistenzsicherung.
Um die Unabhängigkeit der Arbeitsumgebung von einem konkreten Vorgehensmodell zu gewährleisten, haben wir einen Ansatz gewählt, in dem das Vorgehensmodell nicht fest in der Umgebung verdrahtet wird, sondern die Arbeitsumgebung und damit auch das zugrundeliegende Konfigurationsmanagement mit einem konkreten Vorgehensmodell parameterisiert wird. Dazu haben wir eine dedizierte formal definierte Spezifikationssprache ESCAPE+ entwickelt, die wir hier kurz vorstellen.
In diesem Vortrag wurden Fragestellungen der Software-Entwicklung diskutiert, wie sie sich durch den Einsatz objektorientierter Frameworks ergeben. Nach einer kurzen Darstellung der wesentlichen Ziele bei der Verwendung von Frameworks (Wiederverwendung größerer Einheiten, kürzere Entwicklungszeiten, vereinfachte Variantenbildung) wurde auf die (ungenügende) Unterstützung framework-orientierter Software-Entwicklung durch existierende objektorientierte Methoden und Werkzeuge hingewiesen. Z.B. werden Analyse und Entwurf von Anwendungssystemen bei Verwendung existierender Frameworks von diesen Methoden kaum betrachtet.
Nach dieser Einleitung wurden Framework-Engineering-Aufgaben beschrieben, wie sie sich im industriellen Kontext ergeben. Zwei wesentliche Aufgaben sind: (1) die Migration von Altsystemen in Frameworks und (2) die Definition eines Entwicklungsprozesses, der die Evolution von Frameworks unterstützt. Bei (2) ist u.a. das Verhältnis von Framework-Entwicklung und Framework-Anwendung zu klären, z.B. unter der Annahme, daß diese Aufgaben von verschiedenen Entwicklungsteams wahrgenommen werden. Es ist zu klären, wie Verbesserungen des Frameworks bei seiner Anwendung in die Framework-Entwicklung zurückfließen können. Anforderung an eine Werkzeugunterstützung für diesen Prozeß wurden am Ende des Vortrages beschrieben.
letzte Änderung: 28.11.97
