WI ± State of the Art

Standards zum objektorientierten Paradigma

Stefan Eicker, Michael Nietsch

1 Einleitung Neue AnsaÈtze werden in der Informationsund Kommunikationswelt in rascher Folge vorgestellt. Vielfach fallen sie dem Marketing zum Opfer und werden in ihrer Bedeutung nicht selten uÈberzeichnet, d. h. ihnen wird ein Nutzenpotential zugeordnet, das sie objektiv gesehen nicht bzw. noch nicht besitzen. Ein grundlegender Ansatz, an den auch mehr als ein Jahrzehnt nach seiner Vorstellung noch hochgesteckte Erwartungen geknuÈpft werden, ist die Objektorientierung bzw. das objektorientierte Paradigma. Zwar musste auf der einen Seite auch der urspruÈngliche Anspruch der Objektorientierung in einzelnen Punkten relativiert

Prof. Dr. Stefan Eicker, UniversitaÈt-GH Essen, FB Wirtschaftswissenschaften, Lehrstuhl fu Èr Wirtschaftsinformatik, insb. Betriebliche Kommunikationssysteme, UniversitaÈtsstraûe 9, D-45117 Essen, E-Mail: [email protected]; Dr. Michael Nietsch, WestfaÈlische WilhelmsUniverstitaÈt, Institut fu È r Wirtschaftsinformatik /Betriebliche Datenverarbeitung, Steinfurter Str. 107, D-48149 Mu È nster, E-Mail: [email protected]

358

werden; ein Beispiel ist die uÈberzogene Erwartung in Bezug auf die VerkuÈrzung der Softwareentwicklungszeit. Jedoch ist auf der anderen Seite die Bedeutung der Objektorientierung u. a. dadurch gestiegen, dass man sie nicht mehr nur im Bereich der Programmierung, sondern in allen Phasen der Softwareentwicklung einsetzt. Die eher zoÈgerlichen Schritte in Richtung des breiten Einsatzes der Objekttechnik, auf die sich viele Unternehmen bisher beschraÈnken, resultieren im Allgemeinen nicht aus einer negativen Bewertung der Objektorientierung. Vielmehr warten die Unternehmen auf Produkte, die langfristig eine tragfaÈhige Basis fuÈr den Einsatz der Objektorientierung bilden koÈnnen. FuÈr die weitere Entwicklung der Objekttechnik und fuÈr ihre Ausbreitung in der Praxis sind aus diesem Grund Standards von zentraler Bedeutung. Akkreditierte Normen, d. h. von Normungsinstitutionen, wie in Deutschland das Deutsche Institut fuÈr Normung e. V. (DIN), festgelegte Standards, geben Unternehmen grundsaÈtzlich die groÈsste Planungssicherheit. Jedoch gelingt es in einem dynamischen Bereich wie der Informationstechnologie und aufgrund der SchwerfaÈlligkeit der Standardisierungsprozesse nicht immer, Spezifikationen zu entwickeln und zu verabschieden,

bevor proprietaÈre Implementierungen den Markt segmentieren. Auch besteht bei der Standardisierung die Gefahr, dass versucht wird, allen Anforderungen gerecht zu werden. Die Konsequenz ist dann haÈufig ein komplexer, nur sehr aufwendig in Produkte umsetzbarer und vom Softwareentwickler im Unternehmen nur schwierig vollstaÈndig zu erlernender Standard. Der Entwurf des SQL-3-Standards umfasst beispielsweise mehr als 1300 Seiten, der des C++-Standards auch fast 1000. Als Ausweg bleibt den Unternehmen deshalb teilweise nur, auf Produkte zu setzen, die zwar nicht einer akkredierten Norm entsprechen, die aber eine markt- oder marktsegment-beherrschende Stellung innehaben und insofern einen Quasi-/De-facto-/Industriestandard darstellen. Ziel des vorliegenden Beitrags ist es, den State of the Art der Standards zur Objekttechnik darzustellen. Dies ist allerdings ein schwieriges Unterfangen. Erstens handelt es sich um ein sehr breites Gebiet, zweitens fuÈllt bereits die Beschreibung einzelner Standards ganze BuÈcher und drittens entwickeln sich die Standards rasch weiter. Wir koÈnnen deshalb im Folgenden nur eiÈ berblick geben; dabei konzentrieren nen U wir uns auf den softwaretechnischen Bereich. Das zweite Kapitel widmet sich den Standardisierungsorganisationen im Umfeld der Objektorientierung. Anschlieûend werden im dritten Kapitel Anforderungen an Vorgehensweisen fuÈr eine objektorientierte Softwareentwicklung aufgezeigt. Mit dem Objectory und dem VModell Version 97 werden zwei Vorgehensweisen skizziert, die als moÈgliche zukuÈnftige Quasistandards diskutiert werden. Gleiches gilt fuÈr die UML, die im vierten Kapitel als grafische Beschreibungsprache fuÈr Softwareartefakte vorgestellt wird. Den State of the Art von AnsaÈtzen zum Modeling by Difference als Grundprinzip objektorientierter Softwareentwicklung zeigt das fuÈnfte Kapitel auf. Die Kapitel sechs, sieben und acht beleuchten die Implementierung objektorientierter Anwendungen: Das fuÈnfte Kapitel beschaÈftigt sich mit den AnsaÈtzen fuÈr eine Kommunikationsinfrastruktur/MiddÈ berblick leware. Kapitel sechs gibt einen U uÈber Standards im Bereich der objektorientierten Datenhaltung, Kapitel sieben È berblick uÈber Standards im Bereich einen U der objektorientierten Programmiersprachen.

WIRTSCHAFTSINFORMATIK 41 (1999) 4 S. 358 ± 370

Standards zum objektorientierten Paradigma

Das abschlieûende neunte Kapitel betrachtet kritisch die Vision fuÈr die zukuÈnftige Softwareentwicklung, wie sie insbesondere von der OMG propagiert wird.

2 Standardisierungorganisationen Standards fuÈr den Bereich der Objektorientierung entwickeln erstens akkreditierte Normierungsinstitutionen, zweitens Konsortien und drittens einzelne Hersteller/Anbieter von IT-Produkten. Als Vertreter fuÈr Normierungsinstitutionen sind insbesondere The International Organization for Standardization (ISO; http:// www.iso.ch) und das American National Standards Institute (ANSI; http:// www.ansi.org) zu nennen. Die von den Normierungsinstitutionen im Bereich der Objektorientierung verabschiedeten Standards beziehen sich bisher vor allen Dingen auf Programmiersprachen. Das bekannteste, erfolgreichste und mit uÈber 800 Mitgliedern neben dem ATM-Forum wohl groÈûte Konsortium im IT-Bereich ist die Object Management Group (OMG; http://www. omg.org). Die OMG ist eine 1989 gegruÈndete internationale Organisation; sie besteht aus Anbietern von Informationssystemen, Softwareentwicklern und Anwendern. Ihr Ziel besteht darin, auf der Basis der Objekttechnik einen einheitlichen Rahmen fuÈr die Entwicklung verteilter Anwendungen zu schaffen. Zwar kann die OMG ± wie alle Konsortien ± nur Spezifikationen und keine akkreditierten Normen definieren; jedoch werden zum einen die Spezifikationen, insbesondere zur Common Object Request Broker Architecture (Corba), aufgrund ihrer Bedeutung am Markt von der IT-Community wie ein Standard aufgenommen und deshalb auch als solcher bezeichnet. Zum anderen arbeitet die OMG mit den Normierungsinstitutionen zusammen, um entsprechende Normen zu schaffen. Zwei OMG-Spezifikationen, die Interface Definition Language und der Trader, sind bereits als ISO-Normen verabschiedet. Ein weiteres wichtiges, inhaltlich und durch gemeinsame Mitglieder sehr eng mit der OMG verknuÈpftes Konsortium ist die Object Database Management Group (ODMG; http://www.odmg.org). Die ODMG entwickelt Spezifikationen fuÈr ob-

jektorientierte Datenbankmanagementsysteme. Desweiteren beschaÈftigen sich diverse Konsortien, die offene ± d. h. herstellerunabhaÈngige ± Architekturen/Plattformen definieren wollen, zumindest indirekt mit der Objektorientierung. Zu solchen Konsortien zaÈhlen die Anfang 1996 aus der Open Software Foundation (OSF) und der X/Open Company Ltd. hervorgegangene (The) Open Group (http://www.opengroup.org), die Open Application Group (OAG; http://www. openapplications. org) und das Xconsortium. Die OMG hat mit diesen Konsortien im Allgemeinen die gegenseitige Aufnahme von RepraÈsentanten vereinbart und È bereinkuÈnfte uÈber gemeinschriftliche U same Aufgaben zur Objekttechnologie getroffen. Industriestandards schafft heute im Softwarebereich v.a.D. die Firma Microsoft. Mit der COM/DCOM-Architektur hat sie insbesondere fuÈr Windows-Systeme ein Konkurrenzprodukt zu der Corba-Architektur der OMG geschaffen, das sich zu einem Industriestandard entwickelt. IBM versucht dagegen nicht, mit seiner DSOMArchitektur einen eigenen Weg zu gehen,

sondern hat die Architektur an die CorbaArchitektur angepasst. Die fuÈr die Objekttechnik definierten Spezifikationen/Standards beziehen sich in allererster Linie auf den softwaretechnischen Bereich. In juÈngerer Zeit wachsen allerdings die Bestrebungen, anwendungsnaÈhere Festlegungen insbesondere in Gestalt von Referenzmodellen zu entwickeln. Als Organisation ist hier vor allem das bereits genannte Konsortium OAG mit seinen Open Applications Group Integration Specifications (OAGIS) zu nennen.

3 Objektorientiertes Vorgehensmodell 3.1 Anforderungen Ein Vorgehensmodell beschreibt ein methodisches Vorgehen und definiert im Sinne eines Ablaufmodells, in welcher Beziehung Aufgaben und Produkte bei der Softwareentwicklung zueinander stehen. Es zerlegt den Entwicklungsprozess typi-

Kernpunkte für das Management Software muss sicherer, austauschbarer, granularer und unabhängiger werden, ihre Entwicklung effizienter und besser kalkulierbar. Der objektorientierte Ansatz verspricht, diese Anforderungen besser zu erfüllen als traditionelle Ansätze. Der Beitrag beleuchtet hierzu in den Bereichen Vorgehensmodell, Modellierungssprache, Referenzmodell, Kommunikationsinfrastruktur, Datenhaltung und Programmiersprache konkrete und zukünftige Standards. Als Ergebnis lassen sich insbesondere folgende Aussagen ableiten: · Die Objektorientierung ist zentraler Bestandteil der Vision einer zukünftigen Softwareentwicklung. · Investitionen in Standards und in Software, die auf Standards basiert, rechnen sich; insbesondere lässt sich ein ¹Plug & Playª für Softwarekomponenten ohne Standards nicht realisieren. · Die bisher definierten Standards konzentrieren sich auf (software-) technische Fragestellungen. · Standards für die Darstellung von Semantik sowie fachliche/betriebswirtschaftliche Standards müssen weiter vorangetrieben werden. Stichworte: Standards, OO-life cycle, Pattern, Modeling by Difference, Middleware, Business Objects, Components, Frameworks, OODBMS, OO-Programming

359

Stefan Eicker, Michael Nietsch

scherweise in plan- und kontrollierbare BloÈcke von Aufgaben, die als Phasen bezeichnet werden (vgl. auch die Norm ISO 9001: 1994 ISO TC 176/SC 2). Auûerdem besitzen Vorgehensmodelle als Bestandteil einer Methodik eine Methodenzuordnung, die festlegt, mit welchen Methoden die Aufgaben des Vorgehensmodells jeweils durchzufuÈhren sind. Betriebliche Anwendungssysteme zeichnen sich in Bezug auf ihre technische Realisierung und ihre organisatorische Einbettung durch eine sehr hohe HeterogenitaÈt aus. Konkrete Vorgehensmodelle weisen deshalb in starkem Maûe Projektspezifika auf, wodurch ihre Standardisierung erheblich erschwert wird [vgl. auch Soef97]. Zu den grundlegenden Anforderungen, die an ein standardisiertes Vorgehensmodell fuÈr die Softwareentwicklung zu stellen sind, gehoÈrt deshalb die Anpassbarkeit (das Tailoring) an die Organisation, an den Anwendungsbereich sowie an die im Entwicklungsprozess verwendeten Notationen/ Modellbeschreibungssprachen. Sowohl bei der objektorientierten als auch bei der traditionellen daten- und funktionsorientierten Softwareentwicklung zerfaÈllt der monolithische Block des Softwaresystems in kleinere Einheiten. Die Aufteilung in Subsysteme und Komponenten ergibt sich jedoch bei objektorientierten Entwicklungen nicht zwangslaÈufig aus der funktionalen Zerlegung der Problemstellung, sondern aus den in der AnwendungsdomaÈne identifizierten Objekten. Verschiedene der Komponenten koÈnnen bereits durchgefuÈhrten Projekten oder zugekauften Bibliotheken entnommen und wiederverwendet werden. Die anderen gilt es parallel oder inkrementell/ evolutionaÈr selbst zu entwickeln. Jede der zu entwickelnden Komponenten durchlaÈuft idealtypisch einen eigenen, von den anderen Komponenten grundsaÈtzlich unabhaÈngigen Entwicklungsprozess, der aus den Phasen Analyse, Entwurf und Realisierung besteht. Der Entwicklungsstand des Gesamtsystems ergibt sich entsprechend aus den (unterschiedlichen) EntwicklungszustaÈnden der zugehoÈrigen Komponenten. Dadurch verschwimmt die scharfe Trennung zwischen den Phasen, die die Festlegung von Meilensteinen als Basis der klassischen ProjektmanagementaktivitaÈten ermoÈglicht. Deshalb befuÈrchten viele Projektmanager, bei einer an Komponenten ausgerichteten Softwareentwicklung die Projektkontrolle zu verlieren. Eine besondere Anforderung an Vorgehensmodelle fuÈr

360

Bild 1 Unterstützung der inkrementellen Entwicklung im V-Modell 97 [DHMi98, S. 54]

objektorientierte Projekte besteht somit darin, die technisch an Komponenten ausgerichtete Realisierung mit einer an uÈberpruÈfbaren Zwischenergebnissen interessierten Managementperspektive zu verbinden [Koch98, S. 66]. Aufbauend auf dem Urvater vieler Vorgehensmodelle, dem Stagewise Model von Benington (1956), und dem darauf basierenden Royce'schen Wasserfall-SW-Life Cycle Model (1970) [Royc70] sind fuÈr die klassische daten- und funktionsorientierte Softwareentwicklung verschiedene EntwuÈrfe fuÈr ein standardisiertes Vorgehensmodell entwickelt worden. Aufgrund seiner Bedeutung fuÈr die Praxis ist hieraus das V-Modell besonders herauszuheben. Das Modell enthaÈlt in seiner aktuellen Version Erweiterungen, die es fuÈr eine objektorientierte Softwareentwicklung nutzbar machen sollen. Auf Seiten der reinen objektorientierten Vorgehensmodelle wird zur Zeit vor allem der auf den Arbeiten von Ivar Jacobson aufbauende Rational Unified Process der È hnlich wie bei Firma Rational diskutiert. A der Unified Modelling Language (UML; vgl. unten) versuchen hier die sog. ,,drei Amigos`` ± Rumbaugh, Booch und Jacobson ± das Beste aus ihren Methoden OMT, BOOCH und OOSE zu einer neuen Vorgehensweise zu vereinen und diese zusammen mit der UML als De-facto-Methodenstandard zu etablieren.

Neben diesem moÈglicherweise zukuÈnftigen Standard existieren verschiedene Vorgehensmodelle fuÈr die objektorientierte Softwareentwicklung [vgl. z. B. Hesse98]; dazu zaÈhlen insbesondere das Cluster-Modell von Meyer [Meye89] und das FountainModell von Hendersen-Sellers und Edward [HeEd90]. Die Praxistauglichkeit der Modelle konnte zwar nachgewiesen werden, zu einem Standard hat sich jedoch bisher keines der Modelle entwickeln koÈnnen.

3.2 Das V-Modell 97 Das V-Modell, 1991 als Softwareentwicklungsstandard der Bundeswehr veroÈffentlicht, ist heute fuÈr den gesamten Bereich der Bundesverwaltung verbindlich vorgeschrieben. Es wird daruÈber hinaus von vielen Unternehmen als Hausstandard zur Softwareentwicklung verwendet, nicht zuletzt deshalb, weil es die Forderungen der ISO 9001-Norm erfuÈllt und auûerdem auf eine revisionsfaÈhige, planbare und optimierte Nutzung von Entwicklungsressourcen ausgerichtet ist. FuÈr die DurchfuÈhrung eines Projekts muÈssen Aufgaben (im V-Modell AktivitaÈten), Ergebnisse (im V-Modell Produkte) und Verantwortliche (im V-Modell Rollen) festgelegt werden. AktivitaÈten erzeugen

Standards zum objektorientierten Paradigma

3.3 Objectory/Unified Process

Bild 2 Zusammenhang zwischen Phasen, Iterationen und Aufgabenschwerpunkten des Objectory Process [Koch98, S. 66]

oder veraÈndern Produkte; diese stellen beliebige ,,Artefakte`` der Softwareentwicklung ± Code, Entwurfsdokumente, ProjektplaÈne etc. ± dar. Im Juni 1997 wurde mit dem V-Modell 97 eine im Hinblick auf die objektorientierte Entwicklung erweiterte Version des V-Modells herausgegeben. Zu den Erweiterungen gehoÈren u. a. die inkrementelle Entwicklung von IT-Systemen, die explizite Nutzung von fertigen Softwarekomponenten (Commercial of the Shelf-Products) und die UnterstuÈtzung des BoÈhm'schen Spiralmodells im Rahmen eines risikogesteuerten Projektmanagements. DaruÈber hinaus ist das V-Modell 97 im Sinne eines ,,Lean-Standards`` gegenuÈber seinem VorgaÈnger insbesondere in seinem Regelungsteil schlanker und einfacher anwendbar geworden [vgl. DHMi98]. Bild 1 zeigt die UnterstuÈtzung einer inkrementellen Entwicklung anhand der AktivitaÈten des Projektmanagements (PM) und der Systementwicklung (SE) im V-Modell 97. Aufbauend auf einer bei jedem zyklischen Spiraldurchlauf zu treffenden risikogesteuerten DurchfuÈhrungsentscheidung, wird das Gesamtsystem schrittweise in den Inkrementen T1 bis TN entwickelt. Bei Bedarf ist im Vorfeld einer Inkremententwicklung ein Abgleich uÈber die zu realisierenden Anforderungen mit dem Anwender in Form eines ,,(An-)Forderungscontrollings`` durchzufuÈhren.

Das V-Modell 97 beschreibt neben einem Phasenmodell auch moÈgliche Zuordnungen von Aufgaben zu ,,Basismethoden``. FuÈr die verwendeten Methoden, beispielsweise Zustandsdiagramme, Use Cases oder Interaktionsdiagramme, existieren im Allgemeinen entsprechende Notationen der UML; deshalb sind das VModell 97 und UML gut zusammen einsetzbar [vgl. auch Rein97]. Auûerdem spezifiziert das V-Modell 97 Anforderungen an Werkzeuge zur UnterstuÈtzung der Softwareentwicklung in Gestalt entsprechender funktionaler Eigenschaften. Die Anpassung an unterschiedliche Organisationen erfolgt im V-Modell 97 durch die Belegung organisationsneutraler Rollen, beispielsweise die des Systemanalytikers oder die des QualitaÈtsbeauftragten, mit konkreten Verantwortlichkeiten und Kompetenzen. Zur UnterstuÈtzung einer komponentenbezogenen Softwareentwicklung koÈnnen Szenarien mit einer spezifischen AktivitaÈtenfolge definiert und den zugehoÈrigen AktivitaÈten jeweils eine Methode zugeordnet werden.

Der Rational Objectory Process, auch ,,Rational Unified Process`` oder kurz ,,Objectory`` genannt, spezifiziert Aufgaben und Verantwortlichkeiten im Kontext einer professionellen objektorientierten Softwareerstellung. Objectory soll die Entwicklung einer komponentenbasierten, qualitativ hochwertigen Software unter Einhaltung eines vorgegebenen Zeit- und Kostenrahmens sicherstellen. Es repraÈsentiert eine Sammlung von ,,best practices``, welche auf die speziellen BeduÈrfnisse eines konkreten Softwareentwicklungsprojekts bzgl. des Projektmanagements, der ProjektgroÈûe, QualitaÈtsanforderungen, der Zielsprache etc. angepasst werden koÈnnen. Hierzu sind neben diversen Prozesskomponenten fuÈr Entwicklungsaufgaben und projektunterstuÈtzenden Aufgaben auch der zeitliche Ablauf des Projekts zu definieren (vgl. Bild 2). Die zeitliche Einteilung in Phasen und Iterationen entspricht der Managementperspektive, waÈhrend die an den Komponenten ausgerichteten TaÈtigkeiten das komponentenzentrierte Vorgehen der Entwickler widerspiegeln. Eine Phase bezeichnet keine ausschlieûliche, sondern die in einem Zeitraum dominierende TaÈtigkeit. Die objektorientierte Softwareentwicklung wird grob klassifiziert in eine zunaÈchst hauptsaÈchliche Spezifikationsphase, eine anschlieûende hauptsaÈchliche Entwurfsphase, eine hauptsaÈchliche Implementierungsphase und eine Phase, in der hauptsaÈchlich die Komponenten zu Subsystemen integriert werden [vgl. auch Dene92, S. 55]. Jede Iteration innerhalb einer Phase fuÈhrt zu einem getesteten Zwischenergebnis, welches im Sinne eines Meilensteins den Projektfortschritt dokumentiert. Um moÈglichst fruÈh die kritischen Fragen eines Projekts beantworten zu koÈnnen, kann ± wie beim V-Modell 97 ± eine risikoorientierte Iterationsplanung entsprechend dem BoÈhm'schen Spiralmodell vorgenommen werden. Eine Iteration umfasst jeweils den vollstaÈndigen Entwicklungszyklus von der Anforderungsermittlung bis hin zum Testen. Im Laufe der Iterationen verschiebt sich der Aufgabenschwerpunkt von Analyse- und EntwurfstaÈtigkeiten hin zu Implementierungs- und TestaktivitaÈten. Die

361

Stefan Eicker, Michael Nietsch

Aufgaben auf Seiten der Prozesskomponenten (vertikale Perspektive in Bild 2) werden jeweils durch die Angabe von AktivitaÈten, Verantwortlichen und Ergebnissen ergaÈnzt. Aus der Zuordnung einer Prozesskomponente zu einem (Ergebnis-) Modell ergibt sich die Methodenzuordnung des Objectory-Vorgehensmodells. Als Notation zur Darstellung der Modelle ist die Beschreibungssprache UML vorgesehen. Zur UnterstuÈtzung der Kommunikation zwischen Projektverantwortlichkeiten kann den Beteiligten das angepasste ObjectoryVorgehensmodell in Form von HTML-Seiten online zur VerfuÈgung gestellt werden. Ziel ist es, dass sich alle Beteiligten prozessbegleitend via Browser uÈber Aufgaben, Verantwortliche und Ergebnisse informieren. Eine weitergehende technische UnterstuÈtzung im Sinne eines Workflows wird seitens Objectory derzeit nicht angeboten. Hingegen kann durch den Kauf dedizierter Analyse-, Design-, Test- und Dokumentationstools der Firma Rational das Vorgehensmodell mit einer durchgaÈngigen, integrierten WerkzeugunterstuÈtzung versehen werden. Auf eine detaillierte Offenlegung der Werkzeugschnittstellen hat Rational bisher leider verzichtet.

4 Standardisierte Modellbeschreibungssprache UML Der Erfolg eines Softwareentwicklungsprozesses haÈngt entscheidend von der QualitaÈt der Kommunikation zwischen den beteiligten Personen und zwischen den verwendeten Werkzeugen ab: Innerhalb der AnwendungsdomaÈne bildet eine adaÈquate Kommunikation die Grundlage fuÈr eine exakte und treffende Anforderungsdefinition. Die Kommunikation zwischen dem Anwender und dem Entwickler stellt eine Voraussetzung fuÈr die È bersetzung der AnwenderwuÈnkorrekte U sche in Systemspezifikationen dar; die È berfuÈhrung der Spezifikation in stimmige U eine Implementierung wird wiederum sowohl von der GuÈte der Kommunikation der Entwickler untereinander als auch von der InteroperabilitaÈt der eingesetzten Werkzeuge bestimmt. Die Wiederverwendung von Systemartefakten erfordert schlieûlich noch einen effektiven Informationsaustausch uÈber die einzelnen Ent-

362

Bild 3 Kommunikation bei der Softwareentwicklung

wicklungprojekte hinweg. Bild 3 fasst die genannten Facetten der Kommunikation in einer schematischen Darstellung zusammen. Ein Grundproblem der klassischen daten- und funktionsorientierten Softwareentwicklung besteht in der mangelnden DurchgaÈngigkeit der verwendeten Notationen (Datenflussdiagramme, Funktionsdekompositionsdiagramme, ER-Diagramme etc.) uÈber die Entwicklungsphasen hinweg. Die daraus resultierenden NotationsbruÈche und semantischen LuÈcken erschweren sowohl die Kommunikation zwischen den Phasen als auch allgemein die Kommunikation innerhalb der EntwicklerdomaÈne. Die objektorientierte Softwareentwicklung besitzt gegenuÈber der klassischen Softwareentwicklung den Vorteil, dass mit der Klasse ein durchgaÈngiges Modellelement zur VerfuÈgung steht. Dieser Vorteil wurde allerdings anfaÈnglich durch die uneinheitlichen Notationen der objektorientierten Methoden teilweise kompensiert, so dass sich aÈhnliche Kommunikationsprobleme wie bei der klassischen Softwareentwicklung ergaben. Insbesondere war die fehlende einheitliche Notation kontraproduktiv zur angestrebten projektuÈbergreifenden Wiederverwendung von Softwareartefakten und erschwerte die InteroperabilitaÈt von oo-CASE-Werkzeugen. Zur LoÈsung des Problems wurde von einem groûen Firmenkonsortium unter FederfuÈhrung von Booch, Rumbaugh und Jacobson eine universelle objektorientierte Modellierungssprache entwickelt. 1997 reichte das Konsortium die

Unified Modeling Language (UML) als Vorschlag fuÈr eine einheitliche Notation bei der OMG ein; die Sprache wurde noch im selben Jahr in die Object Management Architecture (OMA) der OMG aufgenommen. Die Konkurrenten der UML aus dem wissenschaftlichen Bereich waren bereits im Vorfeld durch die OMG-Forderung nach einer kommerziellen VerfuÈgbarkeit innerhalb eines Jahres ausgeschlossen worden. Prominentes Beispiel ist die Open Modeling Language (OML) [vgl. FiHG98; Open98] des OPEN Consortiums (Objectoriented Process, Environment and Notation) um Don Firesmith, Brian HendersonSellers und Ian Graham. Die UML ist, da ein Vorgehensmodell fehlt, eine Notation und keine Methode [vgl. auch Verst98]. Sie versucht, fuÈr alle Aufgaben der objektorientierten Softwareentwicklung, d. h. insbesondere fuÈr die Visualisierung, Spezifizierung, Konstruktion und Dokumentation von Software-Artefakten, Modellelemente bereitzustellen. Dazu umfasst sie neun sich teilweise in ihrem Einsatzbereich uÈberschneidende Diagrammarten, mit denen statische und dynamische Aspekte uÈber alle Entwicklungsphasen hinweg dargestellt werden koÈnnen [vgl. BoRJ98; FoSc97; Oest97; Rati98]. Die Beschreibung der Sprache erfolgt semi-formal in Form objektorientierter Metamodelle in UML-Notation. Nachteile der UML werden zum Einen in der sich aus dem UniversalitaÈtsanspruch ergebenden KomplexitaÈt sowie in der aus ihr resultierenden mangelnden VerstaÈndlichkeit und Handhabbarkeit der Notation gesehen. Fowler und andere raten deshalb dazu, die UML in Projekten jeweils einzu-

Standards zum objektorientierten Paradigma

schraÈnken und genau festzulegen, welche Aspekte mit welchen Diagrammen zu modellieren sind. Nachteilig ist zum Anderen, dass die UML trotz der Vielfalt der Diagrammarten nicht alle Modellbereiche abdeckt. Beispielsweise fehlt die UnterstuÈtzung dedizierter GeschaÈftsprozessmodelle [vgl. ScSc97] ebenso wie die MoÈglichkeit, Class Responsibility Collaboration (CRC)-Karten in UML abzubilden. Spracherweiterungen sind zwar uÈber sogenannte Stereotypen grundsaÈtzlich moÈglich, jedoch werden dem Anwender nur unzureichende Hilfsmittel zur Formulierung der Erweiterungen angeboten. In der Praxis wird die UML deshalb nicht selten um weitere Diagrammarten ergaÈnzt. Insgesamt bleibt die UML zur Zeit sicherlich noch weit hinter den hochgesteckten Erwartungen zuruÈck [vgl. FrPr97; Soef97]. Trotzdem hat sie sich in relativ kurzer Zeit zu einem De-facto-Standard entwickelt und konnte eine Vereinheitlichung der verwendeten Notationen erreichen. Auûerdem wird kontinuierlich an Verbesserungen gearbeitet: Im September 1997 wurde die UML Rational Version 1.1, in die VorschlaÈge und Konzepte der Mitbewerber eingeflossen waren, bei der OMG eingereicht und Ende 1997 (unverstaÈndlicherweise als OMG-Version 1.0) verabschiedet [vgl. Omg98]. Zur Zeit arbeitet die OMG an der Version 1.2; ihre BemuÈhungen um eine standardisierte Prozessbeschreibungssprache hat sie mit der Workflow Management Coalition (WfMC) koordiniert.

5 Softwareentwicklung auf der Basis bestehender Lösungen und Erfahrungen 5.1 Modeling by Difference Die systematische Nutzung bereits existierender LoÈsungen und Erfahrungen ± Merkmal einer gereiften Ingenieurdisziplin ± etabliert sich zunehmend auch im Bereich der Softwareentwicklung, insbesondere bei der objektorientierten Softwareentwicklung. Der urspruÈnglich fuÈr die objektorientierte Programmierung geltende Leitsatz Programming by Difference wird heute in der Form Modeling by Diffe-

rence auf den gesamten Softwareentwicklungsprozess uÈbertragen. Softwareentwicklung beinhaltet die systematische Modellerstellung und -transformation ausgehend von einem Anforderungsmodell bis hin zum Implementierungsmodell. Deshalb erscheint es naheliegend, einflieûende LoÈsungen und Erfahrungen ebenfalls als Modelle bzw. ± entsprechend ihrer Zielsetzung ± als Referenzmodelle i.w.S. zu bezeichnen. Bei den BemuÈhungen um eine effizientere Softwareentwicklung sind verschiedene AuspraÈgungen solcher Referenzmodelle entstanden, die in der Literatur unter folgenden Schlagworten diskutiert werden: W W W W

Components und Componentware, Business Objects (GeschaÈftsobjekte), Frameworks (Rahmenapplikationen), Pattern (Muster) und Pattern Language (,,Muster im Zusammenhang``).

Allen AuspraÈgungen gemeinsam ist das Streben nach QualitaÈtsverbesserung, EntwicklungszeitverkuÈrzung und ErhoÈhung der Wartbarkeit bei gleichzeitiger massiver Reduzierung der Entwicklungs- und Wartungskosten. Zur Erreichung der Ziele folgen sie dem Building Blocks-/kompositionellen Ansatz. Er besteht darin, dass vorgefertigte Softwarekomponenten, -pakete, -funktionen oder andere Dokumente zur Konstruktion einer neuen Software herangezogen werden [vgl. RoMH90; Niet96, S. 45ff.].

5.2 Components und Componentware Components repraÈsentieren speziell im Hinblick auf Wiederverwendung entworfene und implementierte Softwarebausteine. Ein Baustein stellt eine Menge von oÈffentlichen Diensten zur Nutzung bereit, beispielsweise Datenbankanbindungen, E-mail-Funktionen, Transaktionsschutz, Druckdienst etc. Daneben koÈnnen auch anwendungsnaÈhere Bausteine wie ,,Kunde``, ,,Rechnung``, ,,Konto`` etc. angeboten werden. Wenn eine neue Anwendung als Componentware, d. h. auf der Basis von Components, realisiert werden soll, ist grundsaÈtzlich lediglich der Kontrollfluss als der steuernde Rahmen fuÈr die eingesetzten Komponenten zu implementieren (sog.

,,Component Assemblings``). Dieses idealtypische Vorgehen geht davon aus, dass Components ± obwohl unabhaÈngig voneinander entwickelt ± ohne Kenntnis ihres Quellcodes integriert und ohne unerwuÈnschte globale Effekte auf ihre Umgebung ersetzt werden koÈnnen [GrPf98, S. 38]. Voraussetzungen fuÈr eine derartig weitreichende Umsetzung des kompositionellen Ansatzes sind: W

W

W

W

W

Die Existenz weitestgehend standardisierbarer, allgemeinguÈltiger Teilprobleme sowie deren LoÈsung in Form von Komponenten. Eine genormte Sprache zur Spezifikation sowohl der Syntax als auch der Semantik der durch eine Komponente angebotenen und geforderten Dienste [Olaf96] sowie zur Beschreibung der KontextabhaÈngigkeiten von Komponenten [GrPf98]. Ein SchluÈssel (Interface Identifier, IID) zur eindeutigen Identifizierung einer Schnittstelle einer Komponente. Eine Laufzeitumgebung (,,Middleware``), die die prozess- und unter UmstaÈnden plattformuÈbergreifende Zusammenarbeit von Komponenten ermoÈglicht. Eine Entwicklungsumgebung, die die Herstellung wiederverwendbarer Komponenten und die Zusammenstellung der Komponenten zu Anwendungen (,,componentware-systems``) unterstuÈtzt.

Components sind trotz zahlreicher Gemeinsamkeiten mit Objekten der objektorientierten Programmierung von diesen insbesondere in Bezug auf die GroÈûe abzugrenzen, bestehen meist nicht aus einem, sondern aus einer Menge von Objekten. Beispielsweise wird die Dateimanager-FunktionalitaÈt unter Windows im wesentlichen durch eine Komponente bereitgestellt, entweder durch die Komponente ,,ListControl`` oder alternativ durch die Komponente ,,WebBrowser-Control``. Auûerdem muss die Realisierung von Components nicht notwendigerweise objektorientiert erfolgen; vielmehr muss eine Component nur eine dem objektorientierten Paradigma folgende Schnittstelle besitzen (d. h. objektbasiert sein). Von verteilten Objekten sind Components durch den unterschiedlichen Fokus abzugrenzen: Fragestellungen wie beispielsweise ParallelitaÈt oder Transparenz der Kommunikation, die aus der Sicht ver-

363

Stefan Eicker, Michael Nietsch

teilter Objekte hohe Relevanz besitzen, spielen im Zusammenhang mit Components allenfalls sekundaÈr eine Rolle. Ein Standard fuÈr Components existiert derzeit noch nicht. Grosse Bedeutung fuÈr die Componentware besitzen die von der Firma Sun in Java geschriebenen und als ,,Java-Beans`` bezeichneten Components. Die Firma Microsoft hat angekuÈndigt, ihre Components (,,ActiveX-Controls``, der Standard in der Microsoft-Welt) an JavaBeans anzupassen; die OMG arbeitet an einem zu Java-Beans kompatiblen Standard. Als Ersatz fuÈr eine standardisierte Component-Architektur werden bisher z. T. die Kommunikationsinfrastrukturen fuÈr verteilte Objekte genutzt (dies mag der Grund sein, weshalb Components haÈufig mit verteilten Objekten verwechselt werden). Allerdings sind die AusdrucksmoÈglichkeiten, die die Infrastrukturen zur Definition der Objektschnittstellen zur VerfuÈgung stehen, fuÈr die Beschreibung der Semantik der Schnittstellen von Components unzureichend [GrPf98]. Aus diesem Grund koÈnnen zur Zeit Components noch nicht direkt eingesetzt werden, sondern erst, nachdem ein entsprechender Anpassungscode (sog. ,,Glue Code``) entwickelt wurde.

5.3 Business Objects Der Begriff Business Object wird in der Literatur noch uneinheitlich verwendet [vgl. z. B. SAP98; Sche98; OPENG]. Mehr und mehr setzt sich jedoch die Definition der Business Object Domain Task Force (BODTF) der OMG durch. Sie versteht unter einem Business Object die RepraÈsentation eines Gegenstands aus dem realen GeschaÈftsleben. Die RepraÈsentation umfasst neben der Artbezeichnung und der Beschreibung Angaben uÈber Attribute, Verhalten, Beziehungen und Regeln [vgl. OMG99]. Als kleinster gemeinsamer Nenner unterschiedlicher Begriffsbildungen erlaubt die OMG Definition keine klare Abgrenzung zu anderen Software-Artefakten, wie etwa Components oder Objekte einer objektorientierten Analyse. Anforderungen an Business Objects, die im Hinblick auf eine solche Abgrenzung diskutiert werden, sind: (1) Inhaltlich handelt es sich bei Business Objects um fachliche Objekte; typi-

364

(2)

(3) (4)

(5)

sche Beispiele fuÈr Dinge, die durch Business Objects dargestellt werden, sind Produkte, Rechnungen, Angestellte etc. Business Objects sind nicht an eine konkrete Aufgabenstellung gebunden, sondern allgemeinguÈltig bzgl. eines oder mehrerer GeschaÈftsfelder. Business Objects ,,leben`` solange, wie ihre realen GegenstuÈcke in der AnwendungsdomaÈne existieren. Business Objects stellen inhaltliche Standards in ihrem Anwendungsumfeld dar; dies setzt allerdings die Existenz weitestgehend standardisierbarer, allgemeinguÈltiger Teilprobleme sowie deren LoÈsbarkeit in Form von Business Objects voraus. Die Beschreibung der Business Objects erfolgt in einer standardisierten Sprache. Die Sprache erlaubt die Spezifikation sowohl der Syntax als auch der Semantik der durch ein Business Object angebotenen und geforderten Dienste, insbesondere der KontextabhaÈngigkeiten von Business Objects. Die BODTF entwirft zur Zeit mit der Corba Component Definition Language (CDL) eine solche Sprache fuÈr Corba.

Modelliert werden Business Objects im Rahmen einer objektorientierten Analyse. WaÈhrend jedoch bei einer objektorientierten Anwendungsentwicklung die in der Analyse erkannten Objekte in eine konkrete Applikation einflieûen, werden im Zuge der Business Objects-Entwicklung zu den Analyse-Objekten entweder eigenstaÈndige Softwarekomponenten realisiert oder abstrakte Entwurfsfragmente geschaffen. Man spricht auch von einer ,,Objektorientierung im Groûen``, weil das OO-Prinzip der Kapselung von Daten und Funktionen nicht nur innerhalb eines Anwendungssystems (,,OO im Kleinen``) angewendet wird, sondern systemuÈbergreifend auf der Ebene der Unternehmensinfrastruktur. Dadurch entsteht eine eigene unternehmensweite Systemarchitektur, die durch die Struktur der AnwendungsdomaÈne gepraÈgt ist [vgl. RoÈsc95]. Business Objects koÈnnen als abstrakte Komponenten zur Abbildung von Entwurfsinformationen genutzt werden. Wenn eine Umsetzung in Laufzeitobjekte durchgefuÈhrt wird, erfolgt diese Implementierung in Form von autonomen Components; die Implementierung muss nicht zwingend vollstaÈndig erfolgen.

Neben ihrer ZugehoÈrigkeit zu einem oder mehreren GeschaÈftsfeldern (Common Domain Business Objects, Common Business Objects) werden Business Objects hinsichtlich ihres Typs in Entity, Process und Event Business Objects unterteilt [Shel97]. Der Entity-Typ beinhaltet die in einem GeschaÈftsfeld wesentlichen Objekte, sog. ,,business nouns`` wie Personen, Orte, Dinge oder Konzepte. Ein Process Business Object, beispielsweise ein Objekt ,,Auftragsbearbeitung``, verkoÈrpert einen GeschaÈftsprozess, einen Workflow oder allgemein eine Aktion (,,business verb``). Initiator oder Ergebnis eines Process Object sind Ereignisse, die als Event Business Objects spezifiziert werden.

5.4 Frameworks Frameworks (Rahmenapplikationen) sind ein Ansatz zur UnterstuÈtzung der Wiederverwendung auf der Entwurfsebene [vgl. Niet96, S. 118 ff.]. Ein Framework wird in Anlehnung an eine abstrakte Klasse als abstrakte Architektur, d. h. als Referenzarchitektur fuÈr eine Familie von Softwaresystemen verstanden. Die Architektur soll die grundlegenden Strukturen und Kommunikationsmechanismen einer DomaÈne festlegen, die Details eines konkreten Entwurfs jedoch offenlassen [vgl. Hodg92, S. 185]. Deshalb sind die einzelnen Komponenten (,,Entwurfsfragmente``) eines Frameworks jeweils nur soweit konkretisiert, wie sie in der DomaÈne allgemeinguÈltig sind. Insbesondere realisiert ein Framework die Kontrollstruktur der Anwendungssysteme. Anders als bei der Verwendung prozeduraler oder objektorientierter Bibliotheken ruft der Framework die Methoden des Entwicklers auf und nicht umgekehrt (vgl. Bild 4). Wenn ein Framework fuÈr die Entwicklung einer konkreten Anwendung genutzt wird, muss ,,lediglich`` der vom Framework aufzurufende Code geschrieben werden. Die entsprechenden Entwurfsfragmente (sog. Hot Spots [vgl. Pree95]) macht der Framework explizit bekannt. Anpassungen des Frameworks an die konkrete Aufgabenstellung erfolgen im Idealfall durch VeraÈnderung/Verfeinerung bestehender Komponenten. Bei der Unterklassenbildung soll man sich grundsaÈtzlich an der bereits im Framework enthaltenen Vererbungsstruktur orientieren;

Standards zum objektorientierten Paradigma

Bild 4 Das Hollywood-Prinzip bei Rahmenapplikationen: ¹Don©t call us, we call youª [in Anlehnung an NN 1995, S. 14].

in Praxi muÈssen allerdings haÈufig auch neue Komponenten hinzugefuÈgt werden. Hinsichtlich ihrer AnpassungsmoÈglichkeiten werden Rahmenapplikationen in White-box- und Black-box-Frameworks, hinsichtlich ihrer inhaltlichen Ausrichtung in grundlegende und anwendungsbezogene Frameworks (application frameworks) unterschieden. Letztere koÈnnen weiter nach ihrer DomaÈnenzugehoÈrigkeit differenziert werden. Die Entwicklung von Rahmenapplikationen stellt aufgrund der geforderten Generalisierung eine noch groÈûere Herausforderung dar als die Entwicklung eines konkreten Softwaresystems. Sie verlangt ein gut ausgebildetes und erfahrenes Entwicklerteam und eine iterative Evaluation des Frameworks in der Praxis. Die Investition in eine Rahmenapplikation amortisiert sich erst mittel- bis langfristig und ist wegen der notwendigen organisatorischen Anpassungen und der schnellen VeraÈnderung der systemtechnischen Rahmenbedingungen mit einem erheblichen Risiko verbunden. Dem stehen als betraÈchtliche Vorteile ein hoher Wiederverwendungsgrad und eine Standardisierung der Anwendungsarchitektur gegenuÈber.

5.5 Pattern Seitdem 1992 Coad die ersten Muster, damals Entwurfsmuster (engl. Design pattern), einem breiten Fachpublikum vorgestellt hat [Coad92], sind sie Thema

zahlreicher Kolumnen, BuÈcher, Workshops und Konferenzen. Eine ausfuÈhrliche Begriffsdiskussion findet sich bei Riehle [Rieh97]; er definiert Patterns aus der Sicht der Softwaretechnik [Rieh97, S. 30]: ,,Ein Muster ist eine in einem bestimmten Kontext erkennbare Form. Es dient als Vorlage zum Erkennen, Vergleichen und Erzeugen von Musterexemplaren. Ein Muster ist die Essenz aus Erfahrung und Analyse immer wiederkehrender Situationen. Es besitzt eine innere Struktur und Dynamik.`` Muster repraÈsentieren somit Wissen in Form von Beschreibungen (paperware), nicht Software, die direkt Bestandteil des zu entwickelnden Systems sein kann [vgl. Busc98a]. Sie sind weder in ihrer GroÈûe noch in ihrem Abstraktionsgrad beschraÈnkt. Muster entstehen durch Erfahrungen, durch Reflexion und durch Analyse von abstrakten oder physischen Artefakten. Vlissides sieht in der Reflexion die wichtigste AktivitaÈt [Vlis95], insbesondere deshalb, weil sie das mit Mustern verbundene QualitaÈtsverstaÈndnis praÈgt. Nach der sog. Faustregel von Drei sollte ein Muster erst dann aufgeschrieben werden, wenn mindestens drei Exemplare in unterschiedlichen Systemen gefunden wurden. (Diese Faustregel sollte grundsaÈtzlich fuÈr jede Art von Referenzmodellen zutreffen, da durch die konkrete Nutzung die Einsetzbarkeit von Referenzmodellkandidaten validiert wird!) Charakteristisch fuÈr Muster und damit grundlegendes Schema zu ihrer Beschreibung ist der aus der Architektur uÈbernommene, von Alexander definierte Problem-

Kontext-LoÈsung-Bezug [Alex79]. Diese drei Grundelemente einer Musterbeschreibung werden von verschiedenen Autoren fuÈr den Softwarebereich jeweils um spezifische Abschnitte erweitert, beispielsweise um Konsequenzen der Nutzung, andere Muster, ImplementierungsratschlaÈge oder Musterexemplare. Speziell Fowler gewichtet eine sinnvolle Namensgebung hoÈher als eine vorgegebene feste Beschreibungsstruktur, da Namen erheblich zur Bildung einer gemeinsamen Fachsprache beitragen. Desweiteren gehoÈrt nach Meinung vieler Autoren die Diskussion sog. auf die LoÈsung einwirkender KraÈfte (engl. Forces) zu einer guten Musterbeschreibung [Busc98]. Hierunter sind uÈber die eigentliche Problemstellung hinausgehende Anforderungen, wie etwa Wartbarkeit, EfÈ ber die Bedeufizienz etc. zu verstehen. U tung der genannten und weiterer Musterbestandteile wird in Fachkreisen noch diskutiert. Gleiches gilt fuÈr die Form, in der Muster zu beschreiben sind (textuell, graphisch, formal informell). Zur Zeit erfolgt die Darstellung uÈblicherweise in der Umgangssprache; fuÈr die Beschreibung der Struktur und der dynamischen Aspekte werden zum Teil auch Diagramme eingesetzt. Hinsichtlich ihres inhaÈrenten Abstraktionsgrads/Gegenstands werden drei Arten von Mustern unterschieden: W W W

Interpretations- und Gestaltungsmuster, Entwurfsmuster und Programmiermuster (Idiome).

Zu den Interpretations- und Gestaltungsmustern zaÈhlen beispielsweise Analyse-, Meta- und Anwendungsmuster [vgl. IvPri98, S. 81 f.]. Entwurfsmuster koÈnnen weiter bzgl. ihrer Aufgabe in erzeugende, strukturorientierte und verhaltensorientierte Muster differenziert werden [vgl. GHJV96, S. 11]. Streng genommen gehoÈren Idiome nicht mehr zu Mustern, da sie haÈufig programmiersprachenspezifische Aussagen zur Realisierung einer bestimmten Komponente (Klasse) im Kontext mit anderen Komponenten beinhalten. Die Palette der in der Literatur vorgestellten Muster reicht von den kooperierenden Objekten ± beispielsweise die der ,,Gang of Four`` (Gamma, Helm, Johnson und Vlissides [vgl. GHJV96]) ± uÈber die Organisationsprinzipien von Coplien [vgl. Copl95] und den Gestaltungsrichtlinien von Fowler bis hin zu den Managementmustern von Cockburn [Cock98]. Bekannte Musterkata-

365

Stefan Eicker, Michael Nietsch

gemeint ist. Riehle und Johnson vermeiden daher den Ausdruck ,,Sprache`` und sprechen von ,,Mustern im Zusammenhang`` bzw. einfach von Mustern in der Mehrzahl (engl. patterns). Als bedeutendste Konferenzen wird die jaÈhrlich stattfindende PoLP ± Pattern Langugage of Programming [vgl. MaRB98] ± angesehen. Zum Abschluss der Vorstellung von Referenzmodellen stellt Bild 5 noch einmal die wesentlichen Charakteristika der verschiedenen AuspraÈgungen einander gegenuÈber.

6 Kommunikationsinfrastruktur für verteilte Objektsysteme

Bild 5 Gegenüberstellung von Referenzmodelltypen des objektorientierten Paradigmas

loge finden sich in Coad95, GHJV96, BMRSS96, Fowl97, MaRB98. Zu den wichtigsten Quellen uÈber Patterns zaÈhlen die Pattern-Homepage von Aamod Sane (http://hillside.net/patterns/patterns.html) sowie die Pattern-Serien von Addison-Wesley (http://hillside.net/patterns/books). Insgesamt wird durch Muster praktisch das gesamte Spektrum der Software-

366

entwicklung abgedeckt [vgl. Busc95b, S. 69]. Von Pattern zu trennen sind Pattern Languages. Der von Alexander verwendete Begriff der Sprache ist allerdings etwas verwirrend, da nicht eine Notation zur Beschreibung von Pattern, sondern das Zusammenwirken von Mustern (formal: eine Ordnungsrelation auf der Pattern-Menge)

Als Folge der Computervernetzung spielen in den Unternehmen verteilte Systeme eine immer bedeutendere Rolle. Die Realisierung verteilter objektorientierter Anwendungssysteme ± sog. ,,verteilte Objektsysteme`` ± erfordert eine Kommunikationsinfrastruktur/Middleware, uÈber die ein (Client-)Objekt eine Methode eines entfernten (Server-)Objekts aufrufen kann [vgl. z. B. Derv96, S. 209 ff.]. Sie abstrahiert vom Kommunikationsprotokoll des zugrunde liegenden Netzwerks und von der physischen Verteilung des Clientund des Server-Objekts. Die Kommunikation zwischen den entfernten Objekten erfolgt auf der Basis von Stellvertreterobjekten (vgl. Bild 6); man spricht deshalb von der ,,Proxy-Kommunikation`` (bzw. vom ,,Broker Pattern``). Zur Zeit existieren drei Kommunikationsinfrastrukturen fuÈr verteilte Objektsysteme, Corba, COM/DCOM und Java RMI. Sie werden im Folgenden kurz vorgestellt. Die Common Object Request Broker Architecture (Corba) wurde von der OMG entwickelt. Als die OMG 1989 gegruÈndet wurde, bestand eine wichtige Zielsetzung des Konsortiums darin, eine Kommunikationsinfrastruktur fuÈr verteilte Objektsysteme zu spezifizieren. Die Infrastruktur sollte die problemlose Interaktion von Objekten in heterogenen Umgebungen unabhaÈngig davon erlauben, in welcher Sprache die Objekte programmiert wurden. Die Corba-Spezifikation beschreibt die FunktionalitaÈt und die Schnittstellen, die ein ORB nach der Auffassung der OMG bereitstellen muss [vgl. z. B. Stal97]. Die

Standards zum objektorientierten Paradigma

Bild 6 Prinzip der Proxy-Kommunikation

Schnittstellen eines ORB beschreibt die OMG in der programmiersprachenunabhaÈngigen Interface Definition Language (IDL), die in Bezug auf lexikalische Konventionen und Syntax weitestgehend mit C++ uÈbereinstimmt. Die Abbildung der IDL-Schnittstellen in eine konkrete Programmiersprache wird in einem sog. Language Mapping definiert. Ein solches Mapping wurde bisher fuÈr sechs Programmiersprachen (C, C++, Smalltalk, Cobol, Ada und Java) festgelegt. Die konkrete Realisierung von ORBs uÈberlaÈsst die OMG Softwareherstellern. Diese muÈssen nicht die gesamte Spezifikation umsetzen, da verschiedene Teile der Spezifikation optional sind. MarktfuÈhrer bei Implementierungen sind der Orbix C++ von IONA Technologies und der Visibroker for C++ der Inprise Corporation (ehemals Borland und Visigenic). Die Hersteller Corba-kompatibler ORBs koÈnnen fuÈr die ORB-interne Kommunikation beliebige Protokolle einsetzen. Dadurch kann ein InteroperabilitaÈtsproblem entstehen, wenn ORBs miteinander verknuÈpft werden. Seit der Version 2.0 ist deshalb die InteroperabilitaÈt von ORBs Teil der Corba-Spezifikation: Die Interoperable Object Reference (IOR) identifiziert CorbaObjekte uÈber alle Corba-Plattformen hinweg; das Internet Inter-ORB Protocol

(IIOP), das auf TCP/IP aufsetzt, definiert, wie ORBs miteinander kommunizieren. Das Component Object Model (COM) ist das Objektmodell fuÈr die MicrosoftWelt auf der Systemebene und stellt dort einen Quasistandard fuÈr die Kommunikation zwischen Objekten dar [vgl. z. B. Stal98]. Wie Corba arbeitet COM nach dem Prinzip des Broker Pattern (zu einem detaillierten Vergleich von COM/DCOM und Corba vgl. [CHYL98]). Es unterstuÈtzte zunaÈchst nur die Kommunikation auf einer Maschine. Mit der ErgaÈnzung um das Distributed COM (DCOM) wurde diese BeschraÈnkung aufgehoben, da DCOM eine netzwerkweite Kommunikation erlaubt. Die Kommunikation ist nicht auf die Microsoft-Welt beschraÈnkt, da in Gestalt des Produkts EntireX von der Software AG [vgl. PaKoÈ97] eine COM/DCOMImplementierung fuÈr Unix-Systeme verfuÈgbar ist. Unter der Bezeichnung ,,COM+`` ist seit Herbst 1997 eine Nachfolgeversion von COM/DCOM (,,COM+``) angekuÈndigt, die voraussichtlich fester Bestandteil zukuÈnftiger Windows-Versionen sein wird [vgl. Kirt98]. Sie soll sich stark an den Anforderungen von Java orientieren und Werkzeuge enthalten, mit denen die Entwicklung von COM/DCOM-Anwendungen erleichtert wird.

Seit der Version 1.1 besitzt das Java Development Kit als Bestandteil seiner Klassenbibliothek einen Mechanismus zur Realisierung von uÈber Prozesse und Rechner hinweg verteilten Java-Anwendungen: Die sogenannte Remote Method Invocation (Java RMI) ist ein herstellerspezifischer ± nicht Corba-kompatibler ± ORB von Sun; er erlaubt Methodenaufrufe zwischen verteilten (Java-)Objekten, jedoch nicht die Interaktion mit Objekten anderer È berProgrammiersprachen [vgl. Sun98]. U mittelt werden Methodenaufrufe auf der Basis von TCP/IP uÈber sog. ,,Java Sockets``. RMI kann deshalb auch zur Entwicklung von verteilten Java-Anwendungen im Internet eingesetzt werden. Beispielsweise koÈnnen Java-Objekte mit einem Applet in einen Web Browser geladen werden und uÈber RMI Methoden von Java-Objekten auf einem Server-Rechner aufrufen. Mit der Version 1.2 des JDK ist Java RMI um benutzerdefinierte Socket-Typen und um einen Mechanismus zur Aktivierung von Objekten (aÈhnlich dem Portable Object Adapter in CORBA) erweitert worden. Mit dieser Version des JDK stellt Sun allerdings in Gestalt von Java IDL auch einen Corba-kompatiblen ORB zur VerfuÈgung.

7 Objektorientierte Datenhaltung Zur Bereitstellung objektorientierter Konzepte im Bereich der Datenhaltung werden zwei unterschiedliche AnsaÈtze verfolgt [vgl. z. B. Heue97]. Der eine Ansatz besteht darin, Datenbankmanagementsysteme auf der Basis des objektorientierten Paradigmas neu zu entwickeln; die entstehenden Systeme bezeichnet man als objektorientierte Datenbankmanagementsysteme (ODBMS oder OODBMS). Ein anderer Weg wird von verschiedenen Anbietern relationaler Datenbankmanagementsysteme gewaÈhlt. Sie erweitern ihre Systeme um objektorientierte Konzepte zu objektrelationalen Datenbankmanagementsystemen (ORDBMS). È bergang von ORDBMS zu ODBMS Der U ist flieûend: Einige urspruÈnglich relationale Datenbankmanagementsysteme wie OpenODB und Odapter verwenden relationale Strukturen und Operationen nur noch intern zur Realisierung der objektorientierten Konzepte. D. h., die relationale Struktur wird vollstaÈndig durch die

367

Stefan Eicker, Michael Nietsch

objektorientierte Schnittstelle gekapselt, weshalb die Systeme auch ,,Wrapper`` genannt werden. Mit dem ODMG-Standard in der Version 2.0 ± ,,ODMG-97`` ± liegt eine Normierung fuÈr ODBMS vor [vgl. CaBa97]. Der Standard basiert auf dem Objektmodell der OMG und erweitert dieses um einige wenige Konstrukte, insbesondere um Beziehungen und um Sammelobjekte. Sprachanbindungen liegen fuÈr C++, Smalltalk und Java vor, wodurch die Definition und Manipulation von Daten direkt aus den Sprachen heraus erfolgen kann. Leider fehlt dem ODMG-Standard eine wichtige Eigenschaft eines Standards, naÈmlich die BestaÈndigkeit: Konzepte werden von Version zu Version veraÈndert, neu hinzugefuÈgt oder auch entfernt. Ein Ausblick auf zukuÈnftige Erweiterungen, wie er noch Bestandteil der Version 1.0 war (,,ODMG-9X``), ist in der aktuellen Version 2.0 nicht mehr enthalten. Vorzuwerfen ist dem Standard auch, dass verschiedene Konzepte aus der Forschung (z. B. im Bereich der Anfragesprachen oder fuÈr Sichten) bisher keinerlei BeruÈcksichtigung fanden. Der fuÈr ORDBMS relevante Standard SQL-3 wurde noch nicht endguÈltig verabschiedet. Der Standardisierungsvorschlag ist sehr komplex; sein Umfang ist ± wie bereits angesprochen ± auf uÈber 1300 Seiten angewachsen. SQL-3 ist im Vergleich zum ODMG-GegenstuÈck ausgereifter. Insbesondere wurde die Semantik der SQL-3Klauseln genauer spezifiziert als die Semantik der Anfragesprache OQL (Object Query Language) der ODMG. Auf der anderen Seite sind verschiedene objektorientierte Konzepte in SQL-3 eher umstaÈndlich realisiert; z. B. werden Objektbeziehungen sowohl in Tabellenhierarchien als auch in Typhierarchien abgebildet. Auûerdem muss SQL-3 in die jeweils verwendete objektorientierte Sprache eingebettet werden, wodurch in einem Programm zwei unterschiedliche Arten von Konzepten verwendet werden muÈssen, einerseits die Konzepte der Sprache und andererseits die Konzepte von SQL-3 (sog. ,,Impedance Mismatch``).

Bild 7 Objektorientierte Programmiersprachen im Überblick

8 Objektorientierte Programmiersprachen Analog zum Bereich der Datenhaltung ist bei objektorientierten Programmiersprachen zwischen ,,reinen`` objektorientierten Sprachen auf der einen Seite und um ooKonzepte erweiterten Sprachen (,,Hybridsprachen``) auf der anderen Seite zu unter-

368

È berblick uÈber scheiden. Bild 7 gibt einen U standardisierte objektorientierte Programmiersprachen beider Gruppen in alphabetischer Reihenfolge. Aus der Gruppe der objektorientierten Sprachen ist Java besonders hervorzuheben, da die Sprache im Sog von Internet und Intranets eine stuÈrmische Entwicklung erlebt. Entworfen wurde Java von Sun unter der Maxime ,,write once, run

Standards zum objektorientierten Paradigma

anywhere``; die Sprache ist deshalb auf jeder Hardware-Plattform ± selbst auf Chips zur Steuerung von HaushaltsgeraÈten ± ablauffaÈhig. Realisiert wird die PortabilitaÈt durch das Konzept der virtuellen Maschine (Java Virtual Machine, JVM): FuÈr jede Plattform wird jeweils eine Art Softwareprozessor bereitgestellt, der den vom JavaCompiler erzeugten Bytecode unter BeruÈcksichtigung der Charakteristika der Plattform in ein ausfuÈhrbares Programm uÈbersetzt und dieses ausfuÈhrt. C++ gilt ± trotz der Konkurrenz von Smalltalk in der Vergangenheit ± als QuasiStandard fuÈr die objektorientierte Programmierung in der Praxis. Insbesondere mit Java ist C++ allerdings eine andere starke Konkurrenz gewachsen. Prognosen fuÈr die zukuÈnftige Marktverteilung sind sehr schwierig, da die QualitaÈt der einzelnen Sprachen, insbesondere der in ihr realisierten OO-Konzepte, sicherlich nicht allein uÈber den Markterfolg entscheidet. Argumente lassen sich insbesondere fuÈr die Nutzung folgender Sprachen anfuÈhren: W

W

W

W

W

Ada-95 ist sehr universell ± insbesondere bei groûen Systemen ± einsetzbar. Viele Unternehmen haben C++ als Programmiersprache ausgewaÈhlt und entsprechende Investitionen getaÈtigt (Schulung/Ausbildung, Entwicklungsprodukte). Java bildet bereits den De-facto-Standard bei der Erstellung von InternetApplikationen und erobert den Markt der Embedded Systeme und der Consumer-GeraÈte (Smart-Cards, Anlagensteuerungen, etc.). Auûerdem hat Sun in das JDK 1.2 IIOP aufgenommen und Java als die Sprache fuÈr die Anbindung von Corba-Middleware positioniert. OOCOBOL erlaubt die einfache Einbindung der (zumeist in Cobol geschriebenen) Altsystem-Programme. Visual Basic profitiert von der marktbeherrschenden Stellung Microsofts.

Andere objektorientierte Sprachen (einschlieûlich Smalltalk) werden ± soweit dies heute absehbar ist ± in der Praxis nur eine untergeordnete Rolle spielen. Zwar kann, sofern sich die Broker-Architektur durchsetzt und damit alle Sprachen miteinander kombinierbar sind, die Entscheidung fuÈr eine Sprache grundsaÈtzlich jeweils individuell und abhaÈngig vom Anwendungsbereich erfolgen. Auf der anderen Seite erhoÈht der simultane Einsatz mehrerer Programmiersprachen die Kosten fuÈr Ent-

wicklungswerkzeuge sowie fuÈr Aufbau und Pflege des notwendigen Know-hows.

9 Ausblick Nach der Groûrechner-zentrierten Phase und der Desktop-zentrierten Phase beginnt fuÈr die computergestuÈtzte Informationverarbeitung die Zeit des Netware Computing. Kennzeichnend fuÈr sie ist, dass die Computer unabhaÈngig von ihrer Art global vernetzt sind; jedermann hat vielfaÈltigen Zugang zu diesem Netz und kann es fuÈr unterschiedliche Zwecke nutzen. Experten sagen als Folge des Netware Computing VeraÈnderungen fuÈr praktisch alle Bereiche des gesellschaftlichen Lebens voraus. Weitreichende Implikationen ergeben sich auch fuÈr die Softwareentwicklung. Nach einer Vision der OMG werden im naÈchsten Jahrtausend Softwareanbieter mit der Kenntnis des Marktes Softwarebausteine entwickeln und in Form von Components, Business Objects oder Frameworks uÈber das Netz vertreiben. ,,Softwarebroker`` ermitteln fuÈr Interessenten Softwarekomponenten mit den gewuÈnschten Spezifika. Eine tragende Rolle spielt in der OMGVision die Objektorientierung: Standards zur Kommunikationsinfrastruktur fuÈr verteilte Objekte, im Bereich der Softwareentwicklung (Patterns und Frameworks) sowie im Bereich der AnwendungsdomaÈne (Business Objects, Application Frameworks) bilden die Voraussetzung fuÈr die angestrebte Softwareentwicklungskultur. Die z. T. euphorischen Bewertungen der Fortschritte in den genannten Bereichen duÈrfen allerdings nicht daruÈber hinweg taÈuschen, dass die bisherigen Standards technisch ausgerichtet sind und deshalb lediglich Enabler, nicht aber Garant fuÈr die Umsetzung der Vision sein koÈnnen. Denn zum Einen erfordert der Markt fuÈr wiederverwendbare Softwareartefakte die Schaffung verschiedener Rahmenbedingungen. Diese betreffen insbesondere Fragen des Versionsmanagements, des Billings sowie des Urheberrechts und sind teils softwaretechnischer, teils rechtlicher, teils organisatorischer Natur. Zum Anderen muÈssen aus fachlich-betriebswirtschaftlicher Sicht die Voraussetzungen fuÈr eine Normierung und damit fuÈr eine Wieder-/Mehrfachverwendung im Sinne der Vision geschaffen werden. Zu

klaÈren ist, wie Standards/Spezifikationen auf betriebswirtschaftlicher Ebene das Zusammenpassen (,,Plug & Play``) von Softwarekomponenten ermoÈglichen koÈnnen. Welche Informationen muss beispielsweise eine Fakturierungskomponente an eine Kundenverwaltungskomponente geben, damit sie die richtige Rechnungsadresse erfaÈhrt? Denn eine Rechnung geht nicht unbedingt an die Adresse des Auftraggebers, sondern etwa abhaÈngig von der Art der Leistung oder der HoÈhe der Rechnung an eine andere Adresse/organisatorische Einheit des Auftragsgebers oder sogar an einen anderen GeschaÈftspartner, beispielsweise an eine Versicherung. Legt auûerdem die Fakturierungskomponente die Rechnungsnummer eigenstaÈndig fest, erhaÈlt sie dazu von Zeit zu Zeit ein entsprechendes Nummernkontingent oder existiert ,,irgendwo`` eine Komponente, die Belegnummern fuÈr Angebote, AuftraÈge, Rechnungen etc. zentral definiert? Erforderlich ist ein globales ± d. h. nichtprojekt-/unternehmensspezifisches ± Requirements Engineering und eine Umsetzung in Spezifikationen bzw. Normierungen. Hierzu muÈssen im ersten Schritt die betriebswirtschaftlichen Wiederverwendungs-,,Claims`` identifiziert und dann systematisch erschlossen werden; in diese Richtung arbeitet in erster Linie die OAG [vgl. auch Mert98]. Auûerdem sind Implikationen, die sich im Rahmen des globalen Requirements Engineering fuÈr die softwaretechnische Ebene ergeben, zu analysieren und als Ergebnis eventuell neue Anforderungen an die Ebene zu formulieren.

Literatur [Alex79] Alexander, C.: The Timeless Way of Building. New York 1979. [BoRJ98] Booch, G.; Rumbaugh, J.; Jacobson, I.: The Unified Modeling Language User Guide. Reading et al. 1998. [Busc98] Buschmann, F.: Falsche Annahmen. In: OBJEKTspektrum (1998) 3, S. 82-85. [Busc95b] Buschmann, F.: Welche Arten von Entwurfsmustern gibt es? In: OBJEKTspektrum (1995) 4, S. 68-69. [Busc95a] Buschmann, F.: Was ist ein Entwurfsmuster? In: OBJEKTspektrum (1995) 3, S. 8285. [BMRSS96] Buschmann, F.; Meunier, R.; Rohnert, H.; Sommerlad P.; Stal, M.: Pattern-Oriented Software Architecture ± A System of Patterns. Chichester et al. 1996.

369

Stefan Eicker, Michael Nietsch

[CaBa97] Cattell, R.; Barry, D. (Hrsg.): The Object Database Standard: ODMG 2.0. Morgan Kaufmann Publishers 1997. [CHYL98] Chung, P. E.; Huang; Y.; Yajnik, S. ; Liang, D.; Shih, J.; Wang, C.-Y.; Wang, C.-M.: DCOM and CORBA, Side by Side, Step by Step, and Layer by Layer. In: C++ Report (1998) January, S. 18-29. [Coad92] Coad, P.: Object-Oriented Patterns. In: Communications of the ACM 35 (1992) 9, S. 152-159. [Coad95] Coad, P.: Object Modells: Patterns, Strategies and Applications. Englewood Cliffs 1995. [Cock98] Cockburn, A.: Surviving Object-Oriented-Projects ± A Manager's Guide. Reading et al. 1998. [Copl95] Coplien, J.: A Generative DevelopmentProcess Pattern Language. In: Coplien, J.; Schmidt, D.: Pattern Language of Programm Design; Reading MA et al. 1995, S. 183-237. [Dene92] Denert, E.: Software Engineering. Berlin et al. 1992. [Derv96] Dervon, A.: Client/server architecture, 2 nd Ed. New York et al. 1996. [DHMi98] DroÈschel, W.; Heuser, W.; Midderhoff, R.: Inkrementelle und objektorientierte Vorgehensweise mit dem V-Modell 97. MuÈnchen Wien 1998. [FiHG98] Firesmith, D.; Henderson-Sellers, B.; Graham, I.: Open Modeling Language (OML) Reference Manual. Cambridge 1998. [FoSc97] Fowler, M.; Scott, K.: UML-Distilled. Reading et al. 1997. [Fowl97] Fowler, M.: Analysis Patterns, Reusable Object Models. Menlo Park et al. 1997. [FrPr97] Frank, U.; Prasse, M.: Zur Standardisierung objektorientierter Modellierungssprachen: Eine kritische Betrachtung des State of the Art am Beispiel der Unified Modeling Language. In: Rundbrief des GI-Fachausschusses 5.2, 4 (1997) 1, Bamberg. [GHJV96] Gamma, E.; Helm, R.; Johnson, R.; Vlissides, J.: Design Patterns: Elements of Reusable Object Oriented Software. Reading È bersetzung 1996). 1995 (deutsche U [Gepp95] Geppert, I.: ADC ± Ein echtes Framework fuÈr Benutzungsschnittstellen in Visual Works. In: OBJEKTspektrum (1995) 5, S. 2835. [Gilb96] Gilbert, M.: Is Object COBOL a Framework for Reuse, http://www.sigs.com, (1996) May, S. 42-47. [GrPf98] Gruntz, D.; Pfister, C.: Komponentensoftware und ihre speziellen Anforderungen an Standards. In: OBJEKTspektrum (1998) 4, S. 38-42. [HeEd90] Hendersen-Sellers, B.; Edwards, J.: The Object-Oriented Systems Life Cycle. In: Communications of the ACM 33 (1990) 9, S. 142-159. [Hesse98] Hesse, W.: Vorgehensmodelle fu È r die objektorientierte Softwareentwicklung. In: Kneuper, R.; MuÈller-Luschnat, G. M.; Oberweis, A.: Vorgehensmodelle fuÈr die betriebli-

370

che Anwendungsentwicklung. 1998, S. 110151. [Heue98] Heuer, A.: Objektorientierte und objekt-relationale Datenbanksysteme ± Kriterien und Vergleichsmerkmale. In: OBJEKTspektrum (1998) 1, S. 73-77. [Heue97] Heuer, A.: Objektorientierte Datenbanken ± Konzepte, Modelle, Standards und Systeme, 2. Aufl., Bonn et al. 1997. [Hodg92] Hodgson, R.: The impact of software reuse on object-oriented methods. In: Hall, P. (Hrsg.): Software Reuse and Reverse Engineering in Practice; London et al. 1992, S. 159-205. [IvPr98] Ivanov, E.; Preiûel, H.: Werkzeugunterstu È tzte Wiederverwendung mit der UML. In: Objekt Fokus (1998) 7/8, S. 81-87. [John92] Johnson, E.: Documenting Frameworks using Patterns. In: OOPSLA'92, ACM SIGPLAN Notices 27 (1992) 10, S. 63-70. [Klost98] Kloster, R.: Entwicklung verteilter Objektsysteme auf der Basis von Corba und Java ± Vergleich der Object Request Broker Java IDL und Java RMI, Diplomarbeit an der UniversitaÈt-Gesamthochschule Essen, 1998. [Kirt98] Kirtland, M.: COM+: Eine neue Umgebung fuÈr Komponenten. In: Microsoft System Journal (1998) 2, S. 24-30. [Koch98] Kocher, H.: Management objektorientierter Projekte. In: OBJEKTspektrum (1998) 3, S. 65-70. [MaRB98] Matrin, R.; Riehle, D.; Buschmann, F.: Pattern Languages of Programm Design 3. Reading et al. 1998. [Meye89] Meyer, B.: From Structured Programming to Object-Oriented Design: The Road to Eiffel. In: Structured Programming 10 (1989) 1, S. 19-39. [Mert98] Mertens, P.: Wirtschaftsinformatiker an die Normungsfront. In: Wirtschaftsinformatik 40 (1998) 4, S. 271. [Niet96] Nietsch, M.: Wiederverwendungsorientierte Softwareentwicklung. Wiesbaden 1996. [NN95] NN.: Vorteile objektorientierter Frameworks. In: OBJEKTspektrum (1995) 5, S. 10È bersetzung des White-Paper ,,Lever16; U aging Object-Oriented Frameworks`` von Taligent. [Oest97] Oestereich, B.: Objektorientierte Softwareentwicklung mit der Unified Modeling Language, 3. Aufl., MuÈnchen, Wien 1997. [Omg99] OMG: Business Object Component Architecture, Revised Proposal. ftp://ftp.omg. org/pub/docs/bom/98-07-01.pdf. Abruf am 1999-01-07. [Omg98] OMG: http://www.omg.org/about/ rfpxplan.htm. [OPENG] Open Engineering Inc.: http://www. openeng.com. [Open98] The Open Group: http://www.csse. swin.edu.au/cotar/OPEN/OPEN.html. [PaKoÈ97] Parthier, S.; KoÈnigs, E.: Unternehmensweite Middleware, Objekt Fokus (1997) 11/12, S. 90-91.

[Pree95] Pree, W.: Design Patterns for ObjectOriented Development. Reading et al. 1995. [Rati98] Rational: http://www.rational.com/ uml/documentation.html. [Rein97] Reinhold, M.: Die UML und das standardisierte Prozessmodell ,,V-Modell '97``: Warum reicht eine Modellierungssprache alleine nicht aus? In: OBJEKTspektrum (1997) 5, S. 70-76. [Rieh97] Riehle, D.: Entwurfsmuster fuÈr Softwarewerkzeuge. Bonn et al. 1997. [Rieh95] Riehle, R.: Ada 95 ± The new objectoriented standard. In: Object Magazine (1995) May, S. 44-48. [RoÈsc95] RoÈsch, M.: Sein und Schein von Business-Objekten. In: OBJEKTspektrum (1995) 6, S. 10-14. [RoMH90] Rossak, W.; Mittermeir, R.; HochmuÈller, E.: Reuse of Software-Components. In: Norman, R.; Van Ghent, R. (Hrsg.): Fourth International Workshop on Computer-Aided Software Engineering; Los Alamitos (Calif.) 1990, S. 350-351. [Royc70] Royce, W.: Managing the Development of Large Software Systems: Concepts and Techniques; Proceedings WESCON. San Francisco 1970. [SAP98] N. N.: Die richtigen Rahmenbedingungen schaffen; SAP-White Paper. In: Client Server Computing (1998) 9, S. 34-40. [Sche98] Scheer, A.: ARIS ± vom GeschaÈftsprozess zum Anwendungssystem. Berlin et al. 1998. [ScSc97] Schwegmann, A.; Schlagheck, B.: Integration der Prozessorientierung in das objektorientierte Paradigma. Klassenzuordnungsansatz vs. Prozessklassenansatz. In: Becker, J.; Grob, H. L.; Klein, St.; Kuchen, H.; MuÈller-Funk, U.; Vossen, G. (Hrsg.): Arbeitsberichte des Instituts fuÈr Wirtschaftsinformatik, Arbeitsbericht Nr. 60, 1997. [Shel97] Shelton, R.: Business Objects and Business Engineering, Beitrag bei der DB Expo. San Francisco 1997. [Soef97] Soeffky, M.: Auf dem Weg zum Standard? Gedanken zur Unified Modelling Language. In: Objekt Fokus (1997) 9/10, S. 18-24. [Stal98] Stal, M.: COMmunication everywhere ± È berblick. In: OBMicrosoft DCOM im U JECTspektrum (1998) 1, S. 78-87. [Sutt98] Sutter, H.: C++ State of the Union. In: C++ Report, (1998) January, S. 51-65. [Sun98] Sun Microsystems: Java Remote Method Invocation, JDK 1.2 Beta 3 Documentation 1998. [Verst98] Versteegen, G.: Nicht nur Technik. In: iX (1998) 9, S. 126-131. [Vlis95] Vlissides, J.: Reverse Architecture, Dagstuhl Seminar 9508 Position Paper. 1995. [Well97] Wells, D.; Stevenson, M.: Object/relational Databases, OVUM-Marktstudie. IT Research GmbH 1997. [WiJo90] Wirfs-Brock, R.; Johnson, R.: Surveying Current Research in object-oriented Design. In: Communications of the ACM 33 (1990) 9, S. 104-124.