Bericht aus dem Projekt

Transkript

1 Prof. Dr. Wolfgang Gerken Prof. Dr. Jörg Raasch Fachhochschule Hamburg Fachbereich E/I Berliner Tor Hamburg Bericht aus dem Projekt SEVERS Software-Engineering für die Versicherungswirtschaft Hamburg, im März 1999

2 Vorwort SEVERS steht für Software-Engineering für die Versicherungswirtschaft. Wir bezeichnen damit unser Projekt an der Fachhochschule Hamburg, in dem wir praxisbezonene Forschung im Ausbildungskontext betreiben. Die Arbeiten am SEVERS-Projekt wurden im Wintersemester 1996 aufgenommen. Allerdings betreiben wir keine Forschung zum Selbstzweck. Vielmehr haben wir die Aufgabe, unsere Studierenden am Beispiel von Fragestellungen der Praxis für innovative technische Konzeptionsarbeit auszubilden. In Lehrveranstaltungen behandeln wir Themen, die nach unserer Einschätzung in den nächsten Jahren in Unternehmen eine erhebliche Relevanz gewinnen werden. Für einige Unternehmen sind Inhouse-Workshops durchgeführt worden, in denen wir unsere Ansätze im Vortrag und in der Diskussion dargelegt haben. Ergebnisse unserer Bemühungen präsentieren wir selbstverständlich auch in Konferenzen und Zeitschriftenartikeln. Mit diesem Heft legen wir nun eine Auswahl unserer bisher im Projekt erarbeiteten Veröffentlichungen vor. Wir danken ganz herzlich allen Unternehmen, die unser Projekt unterstützen und begleiten. Ohne die Bereitschaft, die neugierigen Fragen unserer Studierenden immer wieder geduldig zu beantworten, wären einer praxisnahen Projektarbeit enge Grenzen gesetzt. Wir danken weiterhin den Teilnehmern unserer Workshops, die mit ihren kritischen und konstruktiven Einwänden immer bessere Begründungen abgefordert haben und die uns dadurch an ihrer Erfahrung teilhaben ließen. Schließlich gilt unser Dank den Diplomanden und den zahlreichen Studierenden, die in den vergangenen Semestern mit großem Engagement ihre Fragestellungen bearbeitet und am Projekt mitgearbeitet haben und die viele gute Einfälle beigesteuert haben. Wir wünschen uns, die erfolgreichen Kooperationen der letzten Jahre fortsetzen zu können und auf diesem Wege nicht nur ein paar Erkenntnisse und Beobachtungen beitragen zu können. Wir wollen darüberhinaus weiterhin viele gut ausgebildete junge Informatikerinnen und Informatiker ins Berufsleben befördern. (Prof. Dr. Jörg Raasch) (Prof. Dr. Wolfgang Gerken) - 2-

3 Inhalt: In diesem Bericht abgedruckte Beiträge Wolfgang Gerken: Neuronale Netze lösen Klassifikationsprobleme. Versicherungswirtschaft 8/1995, S. 525 ff. Wolfgang Gerken, Jörg Raasch: Anwendungsarchitektur der Versicherungswirtschaft (VAA) im Lichte der Objektorientierung. Versicherungswirtschaft, 8/1996, S. 492 ff. Wolfgang Gerken: Data Warehouse-Informationspool oder Datengrab? Versicherungswirtschaft 8/1997, Wolfgang Gerken: Der Euro als Herausforderung für die DV. Versicherungswirtschaft 5/98 S. 314 ff. Wolfgang Gerken: Modellierungsaspekte eines Data Warehouse.. In: Rainer Bischoff et.al.(hrsg.): Von der Informationsflut zum Information Brokering. Proceedings zum Symposium Information Brokering am 26./ in Leipzig. Proceedings. Braunschweig;Wiesbaden:Vieweg, 1998, pp Jörg Raasch: Komponentenarchitektur für Information-Brokering. In: Rainer Bischoff et.al.(hrsg.): Von der Informationsflut zum Information Brokering. Proceedings zum Symposium Information Brokering am 26./ in Leipzig. Proceedings. Braunschweig;Wiesbaden:Vieweg, 1998, pp

4 In diesem Bericht nicht abgedruckte Beiträge und Vorträge Jörg Raasch, Angela Sack-Hauchwitz: Kooperation, Kommunikation, Präsentation: Lernziele im Software-Engineering- Projekt. In: Software Engineering im Unterricht der Hochschulen SEUH 97. Workshop des German Chapter of the ACM mit der Gesellschaft für Informatik (GI) am 27. und 28.Februar 1997 in Rostock. Stuttgart: Teubner, 1997 (Berichte des German Chapter of the ACM ; Bd 48) S Jörg Raasch: Objektorientierung und die Versicherungsarchitektur der Zukunft. Vortrag auf dem 2. Handelsblatt-Forum zur DV in der Versicherung Informationstechnologie in der Versicherungsbranche. April Wolfgang Gerken: DV-Aspekte der Umstellung auf den Euro und das Jahr Fachkonferenz Von der DM zum Euro der Handelskammer Hamburg am und Jörg Raasch: Eine Komponentenarchitektur für Versicherungsanwendungen. Versicherungswirtschaft 8/98 S.514 ff. Jörg Raasch: Komponentenarchitektur für verteilte Systeme. In: Martin Engelien, Kai Bender (Hrsg.): GeNeMe98, Gemeinschaften in neuen Medien. Tagungsband TU Dresden 1./ , Josef Eul Verlag, 1998, S Wolfgang Gerken: Ein generisches Data Warehouse im Kontext einer Anwendungsarchitektur.Vortrag Fachtagung Modellierung betrieblicher Informationssysteme, Universität Koblenz, 15. und 16.Oktober Tagungen Wir haben Tagungen organisiert, die für unsere Studierenden den jeweiligen Semesterabschluß mit externer Präsentation von Arbeitsergebnissen bedeuteten. Erste SEVERS-Tagung am , FH Hamburg Zweite SEVERS-Tagung am , FH Hamburg Workshop Handelsblatt J. Raasch war auf dem 2. Handelsblatt-Forum zur DV in der Versicherung Informationstechnologie in der Versicherungsbranche am zum Themenfeld Anwendungsarchitekturen - Ansätze und Alternativen Vorsitzender und fachlicher Leiter der Podiumsdiskussion. Workshop Handelskammer Hamburg W. Gerken war auf dem Workshop der Handelskammer Hamburg am zum Thema Von der DM zum Euro: EDV und Software Teilnehmer an der Podiumsdiskussion zur Auswirkung der Währungsumstellung auf die EDV und Software. Chairman Plenum-Institut Köln W. Gerken war Chairman bei der Fachkonferenz "Technologie-Update für Versicherungen" mit Referat über Technologietrends und ihre Optionen, 23. und , Plenum Institut, Köln. - 4-

5 @ACBD E.F GH.I J.E.K!" #$ %& '($ ')%*& +,.-/+102$ ,/7.8.8.%789/7.8:*2<;,.=?>.:$ + Im Versicherungswesen gibt es vielfältige Klassifikationsaufgaben. Dazu gehören z. B. die Klassifikation von Schäden nach bestimmten Merkmalen, die Klassifikation von Kunden, die Bonitätsanalyse oder die Klassifikation von Versicherungsverträgen in z. B. "gute" und "schlechte" Risiken. Alle genannten Fragestellungen haben gemeinsam, daß zwischen den Elementen einer vorgegebenen Menge von Objekten (Verträge, Schäden, Kunden,...) Ähnlichkeiten bzw. Unähnlichkeiten herausgefunden werden sollen, sodaß sich die Elemente hinsichtlich einer Mehrzahl von Klassifikationsmerkmalen in zwei oder mehrere Gruppen einteilen lassen. Bei genauerer Betrachtung sind zwei Fragestellungen zu unterscheiden: 1. Welche Merkmale kommen in Frage, um die Elemente der zu klassifizierenden Menge von Objekten zu Gruppen zusammenfassen zu können? 2. In welche Gruppe soll ein "neues" Objekt, dessen Gruppenzugehörigkeit im voraus nicht bekannt ist, eingeordnet werden? Probleme der ersten Gruppe können mit Verfahren der Clusteranalyse gelöst werden; bei der zweiten Fragestellung kommen die Diskriminanzanalyse und die Nutzwertanalyse zur Anwendung (eine Einführung in multivariate Analyseverfahren gibt z. B. [Backhaus94]). Zunehmend wird in der Literatur, wie z. B. in [Bischoff91] oder [Schumann92], als mögliches Instrument insbesondere für die zweite Fragestellung aber auch der Einsatz von künstlichen Neuronalen Netzen erwähnt. Deren Vorteil ist, daß sie nach Erlernen von Musterbeispielen die Klassifikation durch Verallgemeinerung durchführen. Eine exakte algorithmische Formulierung ist nicht notwendig, weil künstliche Neuronale Netze ein gewünschtes Ein- /Ausgabeverhalten ohne genaue Kenntnis der funktionalen Zusammenhänge zwischen den Ein- und Ausgabedaten erzeugen können. Künstliche Neuronale Netze sind ein seit Mitte der 80er Jahre sich ständig weiterentwickelnder Forschungszweig der Angewandten Informatik, was sich durch einen sprunghaften Anstieg von Veröffentlichungen und Tagungen über dieses Thema belegen läßt [Kratzer90]. Künstliche Neuronale Netze sind als Hard- oder Software realisierte Modelle von Gehirnfunktionen. Sie versuchen, natürliche biologische Neuronale Netze in Struktur und Funktionsweise nachzubilden. Man erhofft sich dadurch einerseits neue Erkenntnisse über menschliche Denk- und Lernvorgänge und andererseits Anregungen für alternative Lösungsansätze komplexer Informationsverarbeitungsaufgaben; auch mit betriebswirtschaftlichem Hintergrund. LMNOPN Q RMSM.TU.M<VWN X R YZMQ.[4X MQ QX\T]^._<MR T/MǸ Y/aN b4mtdc.rt/e f_.n at/sgrtdyzft[4x Q R^_MdhM.aN PT].QMdhM/X b4m ].Q[jilk.SQ R^._M[mV\T.nlM.TUaTS[4SM.oRM/XpURMrqZk.[/aTSrOPTts Q]/[Z[Re R Y/]ZX RPT[u.N PoQMivMTwR i x`mn [R^_MN at/s[/nlm[zmt?o.pn y - 5-

6 z{c }.~..ƒ}< }/ 4} Dieser Abschnitt gibt eine Einführung in die Theorie der künstlichen Neuronalen Netze (das Adjektiv 'künstlich' wird im folgenden weggelassen); insbesondere werden zwei ausgewählte Netztypen näher vorgestellt. Vgl. zum folgenden die einführenden Werke [Hoffmann91], [Hoffmann93], [Ritter91] und [Rojas93]. 2.1 Ein Neuron. ˆŠ.Œ Žˆ. /? 4. / Œ.. š œ žÿ.ÿš / 4 Ÿ /.Ÿ Ÿ/..Ÿ œÿ 4 v Ÿ/.Ÿª «` ±² ³. Źµ /. ± Z <¹ ² º.» ¼`½¾ ÀÁÂÃÁÄ.½Á Å4þ ÆWÃÇ.½.Á.Èl½ÉÊWÀ Á<Ë̾ ÍÏÎÌÁŠÐ.À ÁÑ ÃÁÂ<ÆWÃ.ÒZÄÓ.Á/ĽÁÔ Ein Neuron wandelt die an seinen n Eingängen anliegenden Werte x i (i=1.. n), die typischerweise aus der Menge {0,1} oder dem Intervall [0,1] kommen, in einen Ausgangswert a um. Dazu wird mit Hilfe von den einzelnen Eingängen zugeordneten Gewichten ω i ein effektiver Eingangswert e = ω i * x i berechnet. Dieser effektive Eingangswert bestimmt die Aktivität c des Neurons. Die Berechnung der Aktivität erfolgt durch eine Aktivierungsfunktion c(e). Beispiele für mögliche Aktivierungsfunktionen sind 1. die Identität c = e 2. eine Funktion mit Gedächtnis c neu = c alt + s*e - d*(c alt - c 0 ) Im zweiten Fall ist 0<s ein Skalierungsfaktor, 0<d<=1 eine Abklingkonstante und c 0 der Ruhewert der Neuronaktivität. Mit den Werten s=d=1 und c 0 =0 ergibt sich wieder die Identität. Die Ausgangsfunktion a(c) stellt den funktionalen Zusammenhang zwischen der Aktivität eines Neurons und seinem Ausgangswert her. Sie muß monoton wachsend sein, bei einigen Netzen nach unten und oben begrenzt oder nur aus zwei Werten bestehend. Beispiele für Ausgangsfunktionen sind: 1. eine lineare Ausgangsfunktion, 2. eine Sprung- oder Stufenfunktion, 3. eine Fermi-Funktion. Für die Sprungfunktion gilt z. B. a(c)=0 für c<θ bzw. a(c)=1 für c>=θ. Wenn die Aktivität c den Schwellwert Θ überschreitet, wechselt das Neuron vom Ruhe- in den Aktivzustand; man sagt, es "feuert". Die Fermi-Funktion wird insbesondere dann verwendet, wenn die Ausgangsfunktion differenzierbar sein muß. In ihrer einfachsten Form lautet sie a(c)=(1+exp(-c)) -1. Durch geeignete Wahl spezieller hier nicht angeführter Parameter läßt sich eine Annäherung an eine Treppenfunktion oder, in einem bestimmten Intervall, an eine lineare Funktion erreichen. Die einzelnen Neuronen werden zu Netzen zusammengeschaltet. Die Eingänge eines Neurons sind dabei entweder mit den Eingabewerten des Netzes oder bei mehrschichtigen - 6-

7 R e ¾ R bzw. rückgekoppelten Netzen mit den Ausgängen anderer Neuronen belegt. Die Ausgänge des Netzes werden aus den Ausgängen einiger Neuronen gebildet. ÕÖ ÕØ ÙÚ.Û Ü.ÝÞß Ù? Ùà ázùlâ ãåä æùzû æß â ç/è é ê.ëì íî.ï.ðêñé ê/ò ó4êõôlêì ö.êîî øù/òdúì í.ûì ï.ü?ü? êì ò ývþ/íî/öê.ì îÿþ êì ê.ïzû êì êî îÿê îê.ì íîñ ù.ì êì ò ì ë 4ò ëìšëî/ö ù.ì êü ú ï ùîû ûêî.ý öê î ê.ì ò êî ëî/ö ì êú.ì í.öë.ó/ ê.ì.ïì êîê þ4ê ï/ëgö ê ùîê.î ózëûê ù.ì ò êî î íì ülïzò íîê.î ï/þêþzíî/öêì ê /ê é êëì íî.ï.ðêî<é ê/ò ó4êî< þ4òï.ðþ/í!"$#%" " &('! )"* +",.-/ "6720 6%8 2"4$9.:;%;%244"1 <=8?>@ A A;B8 C401 5$;%2"1 4D EF GH GI JGJ$KLEM"G"N%KJJO G"P$Q F JTSUGL I V JXW KJYG"H O$YF GXKJXE%G"F JG"J F JZ [JZ"G"J\KJ"H F GZ"G"JY"G"J]^Z"GWF _`O GO G"JbacG"I O GXd F P F O F H f GgG"F JGIihjNBO F k F G"I L JZEBf L J"NBO F V"Jl_m GniL"JYlG"F JGIihoLE%Z"KJZEBf L J"NBO F V"JlKm _npf JqG"F JG"J hjle%z KJZ"EW.GI O^L P$QsrtFGvu?GWF _`O G ωwux"y"zoy w { y"} { y {~ y z { y { y"z x"y {vƒ ~ y w { y w { y"z y"z {ˆ" Š y Œy w { y y"} } Ž x Š x wy y. { y { Ž ƒ z y y y { y { B Š yx Š y { xy ~ y z {Š }y {~ y y. } w? ˆ w Š }yz z y w yz x"y { Bei der Arbeit mit einem Neuronalen Netz gibt es folglich zwei Phasen: 1. die Lernphase zur Bestimmung der Gewichte und 2. die Reproduktionsphase "zur Anwendung des Gelernten" Die Methode, nach denen ein Netz lernt, heißt Lernregel š š œ jž Ÿ "ž žo B "ž "ž " " œb œª " «ž µ Ÿ " % œ s " "±g² "œ. "ž cÿ "± ³jŸœB "œ. "ž c œ Ÿ ž œ. %Ÿ$ "ž œb ž % "¹º " $ " žj²» Ÿ " "žš³jÿœb " " º¼ ½ Ÿ "ž ¼Bªš œ ± o " "± ¹c "ž À " sind, so soll das Gewicht ω i um einen Betrag ω i vergrößert werden. ω i neu = ω i alt + ω i Die verschiedenen Lernregeln unterscheiden sich im wesentlichen darin, welche Aktivierungsfunktionen und Eingabe-Wertebereiche vorausgesetzt werden und wie evtl. vorhandene Differenzen zwischen dem Ist-Output und dem (gegebenen) Soll-Output des Netzes in die Lernregel einfließen. Bekannte Lernregeln sind 1. die Hebb'sche Lernregel, 2. die Delta-Lernregel und 3. die Backpropagation-Lernregel. In den folgenden beiden Abschnitten wird im Zusammenhang mit den beiden Netztypen Perzeptron bzw. Muster-Assoziator und Backpropagation-Netz auf diese Lernregeln näher eingegangen. 2.3 Das Perzeptron und der Muster-Assoziator Das Perzeptron besteht aus m parallelen Neuronen, die alle jeweils n Eingabeleitungen besitzen und darüber Eingabemuster zugeführt bekommen. Ein Eingabemuster ist ein Vektor x=(x 1,..., x n ) und gehört genau einer von m disjunkten Musterklassen an. Das Perzeptron soll in einer Lernphase durch Anpassung der Gewichte ω ki (k=1..m, i=1..n) die korrekte - 7-

8 Ñ Ñ Ñ Klassifikation ausgewählter Beispiel-Mustervektoren erlernen. Dazu werden dem Netz diese Mustervektoren zusammen mit der Angabe ihrer jeweiligen Klasse eingegeben. Jedem Neuron ist genau eine Musterklasse zugeordnet und es soll nur bei den Eingabemustern seiner Klasse feuern und sonst nicht. Als Lernregel wird die Delta-Lernregel verwendet. Die Gewichtsänderung ω ki für Neuron k, Eingang i ist dabei eine Funktion 1. der Lernrate r>0, mit der die Stärke der Gewichtsänderung festgelegt wird, 2. des Eingangswerts x i, 3. des aktuellen Neuron-Outputs a k und 4. des Ausgabe-Sollwerts s k. ω ki = r * x i * (s k - a k ) Das Gewicht ω ki eines Neuron-Eingangs wird also nur dann geändert, wenn der Ausgang fehlerhaft ist, d. h. s k <>a k und der Eingangswert zur Bildung des Ausgangswerts beigetragen hat, d. h. x i <>0. Nach dem Perzeptron-Konvergenzsatz [Minski69] findet der Perzeptron-Algorithmus mit der Lernrate r=1/ x nach endlich vielen Adaptionsschritten eine Lösung, wenn die Klassifikationsaufgabe mit geeigneten Gewichten lösbar ist, was dann der Fall ist, wenn die durch die Musterklassen im m-dimensionalen Merkmalsraum festgelegten Punktwolken durch Hyperebenen linear separierbar sind, und wenn die Merkmalsvektoren x alle beschränkt sind, d. h. x <M. Der mit einem Perzeptron vergleichbare Muster-Assoziator besteht ebenfalls aus einer einzigen Schicht von m parallelen Neuronen. Er hat die Aufgabe, Beziehungen zwischen Musterpaaren herzustellen. Wird an seinen Eingängen ein bestimmtes Eingangsmuster (x 1,..., x n ) angelegt, so soll an seinen Ausgängen das zugehörige Ausgangsmuster (s 1,..., s m ) erscheinen. Typische Anwendungen dieses Netztyps sind die assoziative Speicherung oder das Erkennen von Buchstaben. Als Lernregeln werden die Hebb'sche Lernregel und ebenfalls die Delta-Lernregel angewendet. Bei der Hebb'schen Lernregel ist, im Gegensatz zur Delta-Lernregel, die Gewichtsänderung ω ki eine Funktion der Lernrate r, des Eingangswerts x i und des Ausgabe-Sollwerts s k. Der aktuelle Istwert der Ausgabe wird nicht berücksichtigt. ω ki = r * x i * s k Sowohl für das Perzeptron als auch für den Muster-Assoziator gibt es Lernsituationen wie z. B. die Exklusiv-Oder-Verknüpfung, in denen diese Netze versagen, das im folgenden vorgestellte Backpropagation-Netz aber nicht. 2.4 Das Backpropagation-Netz Das Backpropagation-Netz [Rummelhart86] ist ein mehrschichtiges Netz ohne Rückkopplung. Mit einem Neuronalen Netz dieses Typs Á ÂBÃ.ÄÂcÅ.ÆÇÈ Á ÉÊ"Ë(ÌtÄ"ÍÄÎ ÏÈ Á ÂÁ Ä"Î Ð"ÍÇÄ"Í Ð Î ÉÊÒ%ÐÓ Ô"Ê"Î Ä"ÍÕ^ÖÂ\ ÄÂBà Ä"ÊÃÏкÄ"Á ÍÄ"ÎØ ÍÙÐÃ Ú Ë^Ä"Á ÍÄ"Î.Û Ä"ÎÅ^Ä"ÊÎ Ä"Î Ä"Í ÜÝÁÂÉÊÄ"ÍÚ$Ð"Í Ä"Á ÍÄ"Î - 8-

9 Þjßà áßà â ãäå"æäåà ç.ètéäå ê"æ ëê"ì$í%êì ëá"åéîbêtêì ïbêßðà ñ"éîtèšêà ï\éßò ñæêsóæ ëð"éôêtê"æ ëêîsõ ë"áßà â ö ßîBà ê"ì îså"æ ësñ éîø ù éåì îäåê"æ ë"ú æ äåîbà ê Þoßà áßà â ö ßîBà ê"ì çûšéï%ß ù.ê"ì ñ"ê"ësñ"ê"ügèšêà ïøæ ëøñ"êì í%ê"ì ëá"åéî%êþý"ê"æ îá"æ ê"ú ñ"é%à ê"ëþü æ àÿì êéú æ îæ êì à ê"ë Œñ çœå ç ôê %éëëà ê"ë õ ë"áßà â ß"ëñ Þjßà áßà â ö ßîBà ê"ì áééì êëïbßð"êò "å"ì à çûtæ ê tê"ì ô"æ ëñ"ß ëð"ê"ëtï%ùæ îäåêëtñ"ê"ëtñ ì ê"æ ñ"ê"ìü^ê"åì ãäå"æ äåà êë ù.ê"ì ñ"êëtæ ë\ñ"êì í%ê"ì ë"áåéî%ê î ü ñæ ò æ ïæ êì à ñ é ôê"æ?ðêð"êôê"ëê"ü õ ëáßà â ö ßîBà ê"ì.ñ"ê"ìêå"ú êì ï%ùæîäåê"ë ñ"ê"ügþjßà áßà â ö ßîBà ê"ì ñ"éî ü èšêà ïøá"ì ñ ßïæê"ì à ùæ ì ñß ëñiñê"ülðêð"êôê"ëê"ë Þjßà áßà â ö ßîBà êì ñ éî.ï%ß ü õ ë"áßà â ö ßîBà ê"ìuð"êå "ì àtü æ ë"æ ü æ êì àjùæ ì ñ çšûtæ êîbê"ì?èšêà ï à á$ò æ ëñ"êà(ßçué ç Anwendung bei Optimierungs- bzw. Klassifikationsproblemen; als spezieller Einsatzbereich sei die Aktienkursprognose [Rehkugler91] erwähnt. Als Lernregel kommt das sogenannte Backpropagation-Verfahren zur Anwendung, von dem das Backpropagation-Netz auch seinen Namen hat. Backpropagation sucht ein (lokales) Minimum der Fehlerfunktion, die definiert ist als Summe der quadrierten Differenzen zwischen Soll- und Ist-Output, durch Abstieg in der Gradientenrichtung. Diese Regel setzt eine differenzierbare Ausgangsfunktion a(c) wie die Fermi-Funktion voraus. Die Gewichtsänderungen ergeben sich wie folgt (vgl. [Hoffmann91]): ω ki = r * f k * x i Die Gewichtsänderung ist also eine Funktion der (bereits bekannten) Lernrate r, des Eingabewerts x i und eines Fehlermaßes f k. Für die Neuronen der Ausgangsschicht ist f k =(s k - a k ) * a'(c k ) und für innere Neuronen gilt f k = a'(c k ) * j f j *ω jk. Dabei ist a' die Ableitung da/dc der Aktivierungsfunktion a(c), j ein Index für die Neuronen der Nachfolgeschicht und ω jk das Gewicht der Verbindung vom j-ten Neuron dieser Schicht zum betrachteten Neuron k. Diejenigen Gewichte der Neuronenverbindungen, die den Berechnungsfehler minimieren, werden als die Lösung des Lernproblems betrachtet. "!$# %'& ( )+*,"-"."/ ) 0 /,"%, ;:=<$>2? A B2C DE2FG$H I$J KML N2O K H K"FFK'E NQPK R H I N E SK NMPK2O T6K NMS UK2G OR=V=E V=W E H UNMX2K"GH Y$N2W K2O Z[W$E J]\ UÖ U ^ N"K N'K U N _`K H at K R GbTR Hc+K H d Y G R$N2GeF6O K ^2O ZfW$E2FgK"FgK H \h G$S Ui"^2O ZjkR"d G E X"K N"F6O K S SR N"G K NbT6RlX2K E H X"K UO K N Z W K H K NQm2h F2R N"G]\ UOnO H E2WUO UI N"K S SK N Z+o H I GH E \ \ UK H O K N'jSG$I H UO ^ \ K NQE"R"dD[cqp jn SE2G K NMN Ui ^2OI W K H N R$HF2i ^ rk Hn\h"GS Ui"^]UF6Os th K a6k S uv"w V+DqUK"F'UF6Ö U N"F2X"K"FI$N2W K H K]U\ \ K HqW$E"N N'W K Hkx2E S S Z+rK N N'W K H d R$N a6o UI$N E SKzyR F2E \ \ K N ^ E"N"GeTrUF2i"^"K NzW K Ne{ U N2p R$N"WejkR F6G$E X2K"W$EO K NeN Ui ^2OQX"K a2e"n N2OQX"Tr'V d I$H \R$S UK H X E HMUF6Ò R N"W N R H]} R F6O K H X2K UF"o UK SKl~ I$H S UK"G K NV= $o UF2i"^"KjN rk N2W$R N"G FG K X UK2O Kd Y$H PK R$H I$N E SK'PK2O T6K F"UN2W] ~ GSV$T V [V=s ƒi" E2F"u$ w Zs ƒ=uo O K H uv"w Zqs i"^ h$n2k X"R$H Gu$ w[i W K H[E"R i"^'s_bluv"w ˆ Š 6Œ Ž Ž Š " 'Š$ 2 ' Ž $ " 6Š$ 2 2 š šœ ž$ÿ2 = 2 " 2 ª$«6± ²$³2 $ 2µ $ ± - 9-

10 ¹$º ¹"» ¼ ½ ¾6» ¼" ¼ ½ $À2Á[ à ÀÄ ¼ ÀÆÅ ¼ ½ ¼ ÇÈ"É ÊË=Ì;¾"ÇÎ Ç Ï2Í» ǹ$À$ÊÐÁ ¼ É Ñ ½»`Í" È ÉÄ Í2¾lÉ Ç¼ ½'Ò ¹$½ Á ¼"¾6» ¼ Ì Ì» ¼ÔÓ ½ ¹"Õ ¼ Ï6» Ö Ä $½ È"ÉÄ Í2¾ $À2» ¼ ½ ¾ È É2»Ùؼ ½ Ä ¼ ÀÚ¾¹$Ì Ì» ¼ Ö;¹$ºÜÛ¼ ½ ¹ À Í Ì¼ÜÛ¼2» Ý6¼Üº"¼ ÇÞÄ ¼ ½àßÑ ¾2 À"ÁÜÒ ¹ À Ë=ÌÍ2¾¾"ÇÎ Ç Ï2Í» ǹ$À"¾"á ½ ¹ º ̼ â ¼ À Ç âã+¼ ½ ¾"ÇÈ É2¼ ½ $À"Á ¾2ؼ2¾¼ À ¼ Ç À2Á ¼"¾¼2» Ý»nؼ ½ Ä ¼ À ÏÑ$À À2¼ À Š¼ Ç"Ä ¼ À ¼ â á ǽ Ǿ2È É2¼ À ã+¼ ½ ¾ È"É"¼ À É Ç¼ ½ Ý 'Ø $½ Ä ¼ À ä º"¼ ½ ØǼ2Á ¼ À2ÄMÍ2 ¾Ä½ ¼ Ç$Û¼" $½ ¹$À"¼ À"å æè É ÇÈ É2» ¼ À º"¼"¾6» ¼ É"¼ À"Ä ¼çÛ[¼2» Ý6¼lÒ ¹$âéè=ê$áÆÊ6Å$Í"È Ï"á ½ ¹ á Í2Á Í» ǹ$À$Ề Ò ¼ ½ ؼ À"Ä ¼2»  ëì¾ æ¹"î» Ø Í ½ ¼l¾6» Í À2ÄÄ$Í2¾ $À2» ¼ ½ì æ$å ízç À2Ä$¹ ؾ`º"ÝØ'Âîæ$ï ðeìí" "Î ¼ À2Ä ¼zÓ ½ ¹ Á$½ Í â â á Í Ï6¼2»QÛ¼ ½ Í ÌnÛ¼2» Ø ¹$½ ÏÐñ[» Ç Ì Ç» êlò Û+Û+ñó Ò ¹$À à ÅìôÝ ½fã+¼ ½ Î ä Á $À"Áeõ à Åì ö "Í"ø Ö õ à Åì ö º ø Âkì Ç» Û+Û+ñÔÏÑ$À À"¼ ÀÐÛ¼2» Ýؼ ½ Ï6¼gÎ ä$½kî ¹$ÌÁ ¼ À"Ä ¼ Ó ½ ¹$º ̼ âf» ê$á"¼ ÀùÍ2 "» ¹$âÍ» Ǿ2È ÉúÁ ¼ À"¼ ½ Ǽ ½»Ôؼ ½ Ä ¼ À Ö Ø¹$º"¼ Ç`â ¼ É ½ ¼ ½ ¼ûì¹"Ä ¼ Ì Ì¼ ÖÇ À"¾2º"¼"¾¹$À2Ä ¼ ½ Å$Í"È Ï"á ½ ¹$á ÍÁ$Í» ǹ À Ö=Ý6 $½=ã+¼ ½ Î ä"á$ À"Á ¾6» ¼ É"¼ Àü ý=þÿ ÿ! " # $%&'( ") * +-,. /01 2 / : ;=< >?6@ AB CDC< E?6A%F G%H IKJLNM%O P O Q R S TVUXWXY T P Q ZR SZW[%T W G%H I%H \NJP QY T Q']XT OQ M%O T ^ _a`t P Y P b [ Q c^b Q Q O d Ocb Y O ew f ghg i jjk lnmo k lp g mqr kts'lp ulovwi xnlyo l{zxj g gy} y~ k yioni on =lp gyqr lp m o g lp k p loƒyo mk l v oi p ' jl mou g qrjlqr k l =lp k p l ykvˆ=yj} lwi oš lmp i o jlo -l k Œ6loŠ ' %jyqr yg6k Ž ylg l =lp k p g xls'lp k mo nxœ svžv lp k p g~j g gy} y~ k yi o ~ oo yohg lœ yljjlo X p k lo lulmk m o r x lõ xly ulp Xš šœ žÿ ª «±² ³ ² ± µ % ¹º»¼½ ¾ ¹À¼½ Á Â Ã Ä Å ¼ Æ=¼½ Ç ½ È Ã¾ ºÉÈ ¾ ¾ Ê º È Ç Ë ¼½ Ê Ë ÉÃÇ ¼nÈÁÊaÌͽ ÁÂÎÏ»ËÂnÐ Ñ'¼ Ò%½ Ç ¼½ ¼ÂÓº Ô Á  Î{ºÕ Ä Å ¼¾ ¼ ÒX½ Ç ¼½ ¼Â º ÖÂÂ Ç ¼Â ÐÄÙØ ÄÍÎ È ¾wÚ Û ÜÀ½ É ¹À¼Ý Þ½ Üß ¼ÂÈ ÁÊ º Ë ß ßN¼Â ÁÂΊÎ% ¼ Èà¾ Ë É ÁÇ ¼ÂŠàÐ ÑVÄÙÈÁÊ Î È ¾aÞ½ å Üß ¼ÂÈ ÁÊ º Ë ß ßN¼Âtà¼Ð Ëü ¼ÂáV½ ¼É È Ç»¼ÂâÆ=¼½ ¾ ¹À¼½ Á Â Ã¾É ¼ ¾6Ç Á  üÂã ä%èàé Á ÂüÂa¾ ¼ Â Ä Â¼â¼»Ç É ÄNüÑæ ¹À Ç ¼ Ç ¼ Ò%Á ß'Á É ¼½ ÁÂÃç ༽ ÐÄ Ø Ä'Î% ¼çÉ ¼ Ç Ð Ç ¼ÂaÎ%½ ¼ ÙèÈÀ½ ¼ ¾6Ç ß'ÖÃ%É ¹ÀtÁÂÎ ¾ ÂÂ»Ë ÉÉ Äêé  ëùààüâ Ã% Ã%º6¼ Ç'»Ë ß ì ¼½ Ç ¼íÈȽ'Ú º Ôá ºÕ ÝîÑæ ½ Î ¼  Æ=¼½ Ç ½ È ÃwÈɾ à ÁÇ áùâë½ ß'ÈÉ-Ëμ½ ¾ ¹Àɼ¹À ÇaºÉÈ ¾ ¾ Ê Ð ¼½ Ç ÄïÆ ¼½ ÈÉÉüßN¼  ¼½ ÇŠ¾6Ç ¼ÉÉÇŠ¾ ¹ÀhÎ% ¼¾ ¼hëêÁÊ ÃÈà¼h¾ Ë Î È½ á Î Èðϼ ÂÏÂñ Î% ßN¼Â¾ ËÂÈÉ ¼½ %È Á ßçÎ Á½ ¹Àæ¼ Â¼ üº ½ ß ßîÇ ¼VòÉ Ü ¹À¼  РÑ'¼ óx¼ É ½ ÜÁ ßN¼ ü Ç ½ ¼Â ÇÍÑæ ½ Î Ä ô õö øù ú%û6ü ý þ ÿ ù þ ÿ6ü ÿ û ú ù - 10-

11 ! " #%$& % ' " (*) +, ).-/ )425 " (67 #98 #98&#;:< * >=?*)A@<1 23 3, B= CD E " 6FBGHIA =56% 5 #&$9 % 6%J K( EL9 K( *( ", +/)M* N; 53 ON; P6% QCSR 5 +,TU VN; 5 ' )U?OW>" 5 ),X!3 3 % 3 E ), (3 = 3,=5 #X (3 ) B) +/)M*) 1" Y Z> J 7 *) 6[ \ H&+? ]256_^53 3Y ZB J +F " ( )< ) DIQ <` H&+%?a + 6b6c/#&H9#?4 K( #B$9 53 ) 4W> 3) Q F),2 ) Q8 K=J 5J 5Y N; # R dlb d) SW " d " (0) +< 6fe9 ge K ( U b) K(3 K ( EL9! E,8 K(,= K ( /L!Ë ( # ô õö øù ú%û6ü ú%û6ü õ øü øý þÿ ý þ ÿ ù þ ÿ6ü ÿ û ú ù R V( "hj ) VN; 53 VN; ' " ( )dvcur Y +4@U V)dG W> 5,(9) *6 3 K( IA =56% 5 % 3 37 (3 3 # $& Q d h (3 P= b )g )g " Q) gr N; 53 ;N; "Ë K ( 3 K( ij K ( #/1 %) 6VX %5(3),R 3,3% K( ) /j/ ",) Bk J 5 )=" 5 J( 6% >!3 3 4 " %!(3 4lE" J 46% >#&8&#;=? m n&o pnn/q%rs tou v w x&y z{x/ }~; 9ƒ" < ˆy Š0 ˆ O Œ Ž ; ƒ" P % ŽQ Ž h ˆ ˆ yd ˆ h V ŽD Ž d & Ž ƒ ˆ yqž d ˆ ˆ Ž ˆ y& /};ˆ}, " > ˆ 4šŽ ƒ" ƒ% ŽB " Ž Aœ Ž Œ" * ˆ - 11-

12 ž Ÿ 9 4ª «D D «7 «Dž 4 ± ²< ³U µ Ÿ«²,± ² ª% Ÿ«² «E 4 E Ÿ² %¹& Ÿ Ÿ % «Ÿ«º Ÿ " ¼ ¾ ¼ ±ž"«¼»; ± º Ÿ «" ½ µ Ÿ º Ÿ «" ½ µ Ÿ ž Ÿ «ž Ÿ «ÀÁ ÁàÀÁ9 ÁÁÁ À Ä/Å < ÀÆ ÀÁ ÁàÀÁ9 ÁÁÁ ÀÇÅ < ÀÁÁ ÁàÀÁ9 ÁÁÁ À àÀÆ ÀÁÁ ÁàÀÁ9 ÁÁÁ ÀÈÅ ÆQ À ÁÁÁ ÀÀÅ ÉQ ÀÁ9 ÁÁÁ ÀÁ&Å ÇQ ÀÆ À ÁÁÁ ÊÅ ÇQ ÀÁ9 ÁÁÁ ÊÅ ËQ Ç& ÁÁÁ ÄÌ ÀÁ9 ÁÁÁ Ä/Å ÇD ÀÆ Ç& ÁÁÁ ÄÌ ÀÁ9 ÁÁÁ Ä/Å ËQ ÍÎ ÏÎ ÏDÐ9ÑFÒÓ Ô ÒÕÖ/ÒÓÕ ÓÒØÙ;Ú/ÛÜÝÒÜÞ Øß ÕÕÓ à ÓÞ ßÔ ÓáÜ â ãåäæ ã äçgèéäæê äãfëì íîäïéðç ñäòñæäfëç óôõäö7î"ê äõ õ ðã ï ä øã ñäç ê ù_ãðãåîóõ õê äïäæ ã ä úðã ñäãû õíîîæü æ ûíê æóãåý þ ð ê þÿó ñäç[þ î ìõä ìê þ bñðçì äü ìç ê éäç ñäã 9æäïúðãñäã ô äðç ê äæ õ ðã 4äç ü óõ ê ä4ö%æê æ õü äóã*î æäô äãdú/ç æê äç æäã é%óô äæ ä ñä îeäæ ãäã*ñäçqäç ê ä íãã äìö7äãaûóããê ä æãúðã ñäaé%ðç ñäqñíããaè Bíõî<þ î ìõäìê þô äðç ê äæ õê Féäãã<ô äæ æäç ñæä îäç9î æäô äã4ú/ç æê äç æäã,ñäç!qäç ê"#óç ûíö 9æä îädú/õíîî æü æ ûíê æóãûí ãããíê ç õ æì*í ð ìãí ì ðã î ìøç ü äç äã%$ä äõã_äç ü óõ äã OéEæä_ä îgè & PôäæDäæ ã äö'$ û" ç æü üsí ð ü(óç õ æä äã ñä ) íìô ä íç ô äæê äç äãê î ì äæñðã äã,íõî+*"äç ãñíê äã,ö-, õ æì,é%ø ç ä 9æä<ü óõ äã ñä/.ôôæ õñðã Päãê î"ê íã ñoô äæ ñäç0.>ç ô äæê4ö%æê ä è äæ ê4æî"ê*ñäç-8 äç õí ð ü*ñäç 9äìõäç ûðç ä æ ãgñäç:*äç ã;ìíîä < &ä ð ê õ æì[ûíãã öí ã_ñäã%*äç ãü óç ê î ìç æê ê.ñäî%1;äê è"ä î äç ûäãã äã4ñäçqî æìuæãsñäç#.ôãíìö7äsñäîhöí =æ öíõäã>9äìõäç î Qñäü æ ãæäç ê0íõî? 9æü ü äç äã è èéeæî ì äã ) óõ õ ê ; ð ê îäæê ñäç9õäê è ê äã6 äéeæ ìê îøã ñäç ðã /è äæ ê äæñäã*äö0;æç æî ìäãa/ä î"ê îæ ã*ñæä î"äç èéäæê äãdëç ó äû"ê ;ì íîä 9ñäçúðãñäãû õíîî æü æ ûíê æóã; íô ä îdæ ãê äç ä îîí ãê äb ç äôãæî"îä 5æ ãc1;äê èdö%æê+d<æã í ã î ãäðç óã äã 5óãDñäã äã# äñä î#1;äðç óã íõîó<äæ ã äãaäç ê%èéeæî ìäã<aðãñ&0íããäìö7äã<ûóããê ä Fè"äæ ê*ãí ìaäæ ã äç-*äç ã;ìíîäcóã - 12-

13 EF GHJIK L MEG MNM OPQ RGH M>STLU F HG EGMVK GW WGME GVNXOMY G F Z GMSYGF Q [ WK GM \B]![TZGZ GMN^0[FBEHG _TGF M `Q[ VTGJaGH GH MGb>c G K Sb0HKd!e2f H MZ[ M ZVMGL F O MG Mg3aGHEGbhEHG#f H M Z [ M ZVH M U OF b-[tk HO MG M ah M if<p O EHG F K(^0[ F GMg&aG F GHK VNM [PQ%jkmlH M LK GM [azg V P QWO VTVTG M\Cn"WWG%f H MZ[ agb-lvk GF ^0L F EG MoF HP Q K HZ2RW[ VTVHU HS HG F K p![ LPQE[ MM g!^-g MMJHM+EGF_TG F M `Q [ VGoM L Fqr s2grks O EG F5dr s EGF!b-t ZW HPQGMd!euq#l+L VK GF[MZG a OK GM^0L F E GM pv G ^-GH WV0SLU i W W HZ2[ L VTZ G ^0i QWK \!] [ Vc G K S+HVK [ WV O&VK [ah W\7wGH3[ M EG F GM:fM K V P QGHE L M ZVF GZGW M/SGHZ K G&VHP Q/GH M&i Q MW HP Q GVBx3G F Q[ WK GM\-f H M G ah M if GBy!O EHG F LMZBYOM&f HMZ[ MZ VH M U O F b-[tk HOMGMV PQGH M K0[ WV OCZ zmvk HZG FSTLBVTGHM<{ SL b0h ME GVK agh w [PR`F O `[ Z [TK HOM} c!g K SG M~LME~EG FZGZ GaGM GM IOU K ^0[ F G g [ WVƒMHP Q K POEHGF K G f H MZ[ MZVHM U O F b-[tk HOMGM p [ LPQ^-GM M0E [ EL F PQ0E [ V+c G K S7Z F t GF ^+H F E\ ˆ Š Œ Ž T h B š œ 2žŸ! œ Ÿ >! -ž œª «œ? Ÿ ŸT œ T 7 œo š±3 œª ²- T œ+ œ ª T ²- ž œj T œœ œ ³! ²0 ž J ŸT ª ª µ ³ ž +±3 ŸTª Ÿ T TŸT œ+ œ ž ³ ž J œž œ Ÿ ŸT œo¹ 0 œ ž Ÿ œoº0 -Ÿ œ» ³ < œ ž œ œª¼ª T ¾½ :À <Á œ œ œ À ³! /ž T ½ C Ÿ œ& œ : œªÿ œª - 0 œ ž< œ/â5 Tª Ÿ œ œ< 0 ž œ< - ª œ ÃC œcäå œžš ³! C œ œ/ œ «œ/æ ²- /¹«ª ³7Ç º0µ ÈÄÉ»- + B ª œ ž Ÿ ÅÊ ž h há œ œåž Å œš! Å 0 œ 2 œœ œhë C œ ²- ž œì Ÿœœ ³%!Ÿ 0 TŸ œœê ž Í œž œ œ ª ž Ο m œ ¾ ž Ÿ œ Ïœ -ŸT œ œ<ÿ Ÿ +²0Ÿ Bª œ 5ž ÁŸ " -ž & œ:! œ Ÿ <! / Ÿ ²- ž œ³ T 7ª µ Ÿ o Ÿ T ŸT œ 7 œÿ œ ª ª«šÂœ ²- œž œ ª T ª³ Â" ž œª ²+ ž<žÿ / ÐÆ ²- BŸ œ ª ª œ <! C T + ѳÃ/ /ž / œ Ò <ª ª B Ÿ œ 2 TŸ œœ: µ o ÅÂ"œ ²- œ ž œª œåž T h Ñ T C²- T œ ž <²- ž œ³ ŸT & œ C ª œ ž Ÿ?ž T œ šž > T œ«ªÿ œ ª ²- T œ 0«œ+ œ ª ª œ œ+ó ž œªž œ ª Ÿ ž ŸT œÿ œª ³ Ô ž œõ œ~ª œ Ÿœœ œô Ÿ T ŸT œ 7 ž ~±3 Ÿ ª Í œžôž œž œ Ÿ T ŸT œ T œœ œ<«œž œ(²- ž œ o œž Ö ž ±3 Ÿ ª Ÿ T ŸT œ œ Î œž œ œ ª¼ 0 % œ ³N!Ÿ 0 % ª % Ÿ œ ž ª œ ž Ÿ ž Ø Ù Ú ÛÜÝÛ Þ Üæ á ÝÛ å!ýàá àæä ç Þ Üæ á ÝÛ Ù Ú ÛÜÝÛ Þ ß ÝÚ àá ÝâãÚ Ûä äútá ê ç èé ãý èétá å!ýàá àæä ç Þ ß ÝÚ àá ÝâãÚ Ûä ç äútá è é ãý èétá ê - 13-

14 ëìí îï ðtí ñ ï ò ó ô ðõ ö ðñ øùúû3üýð ñ ø+ô ðõö ð ñ øþ ôîï ÿ ï ìõ ø ÿþ Bñ ý ý ì ÿötîþ ý îìî ï þ+ñ ýí ìðï ìðtí î "ÿ ð ý øî7î í îÿþï ìÿ îïîï ýðjþ!ôîï ýì ÿ îìîý î ï î "! ï ö # ùùú ó ôìø õ ù$#û $%ôìø õ þ&'%ôýîì ýî þ(%)5ï ðð ý ø þ* î ï ì ÿø ðtí +,!î ñï ÿð ýîï$!î í +î-+ñ ï î í ï ìî ø +ì ï í ø õ ð í ý ìõ î ÿjü î ÿÿ+tð ýî ÿ ð ÿð ý øtî þcìÿò /ì ï í ø õ ð í ø. ì ÿ ï-ðtí ì ö-/0 ù$# þ$$%213/4 þìî-î43îï ýð 5# ùù$# ó6ôù$#ðû % 7% þ!î ñï ð ý î í, ï ö,8 í ì ý ìí þ$8!øtî ï 9ø:)5ñ ìîþ6ôþ$ õ îøí î ï # ùù$# ó6ôù$# û % 7% þ!î ñï ð ý î í, ï ö,8 í ì ý ìí þ$ ï ï ð,7î ï 9ø- î îï îÿõ îþ$6ôþ õ îøí î ï # ùù$# ó -ð ÿÿù$#û % -ð ÿÿ þ$ì-ñ ýðtí ì ÿ!îñ ï ÿ ð ýîï î í +îþìî-î43îï ýð þ ôï ðñ ÿøtõ -îì;# ùù$# ó -ð ÿÿù 1û % -ð ÿÿ þüýîìÿîø-!ð ÿ ñ õ î ñï ÿð ýîï!î í +îþìî-î 3î ï ýð þ ôï ðñ ÿøtõ -îì;# ùù 1 ó üï ðtí +îï ù<û ü$%. % üï ðtí +î ï þ!î ñï ÿ ð ýî4!î í +îþð ÿøîï3îï ýð þ-=ÿ õ î ÿ># ùù< ó üï îötî ý ù$#û *'% üï î ötîý þ!î ñï ÿ ð ýî4!î í +îoìÿ,îï"ÿ-î ÿ ñ ÿ þ!ìÿò /ì ï í ø õ ð í ø. ì ÿ ï-ðtí ì ö-/0 ù$# þ$$% 1/ 1 þìî-îîï ýð5# ùù$# óì ÿøöì?ù û 2%ì ÿøöìþ$$% ðî ï í þ$ îï õtî í ï ÿø þ$6@. ï îøtøþ&!ð,ï ìîa+ð ø%b # ù?ù ó-= ý ýîï ù<û ô%-= ý ýîï þ(% îìÿ ð ï í þ!îñ ï ð ý!î í, ï öøþ$ï ì ÿ î ï3î ï ýð þ!ôî ï ý ì ÿ!îìîý îï!î "!$ ï ö# ùù< ó î ötñýî ï ù$#û % î ö ñýîï þ@c% ìþü = ÿøí ý ìõ î!îñ ï ÿ ð ýî!î í +îì ÿ,î ï D ì ÿ ð ÿ+ð ÿ ð ý øtî ò ìÿîÿîñ î-eï ð:î ï3üñï ø ï ÿ øtîÿ F7ì ÿ ò /ì ï í ø õ ð í øì ÿ ï-ðtí ì ö,/0 ù$# þ$$%21?/4 þìî-îîï ýð5# ùù$# óìí í îï ù$#û %ìí í îï þ@c%+ð ï í ì ÿ î í + þü$%õ ñ ýí î ÿþ!î ñï ÿ ð ýî!î í +îþ'ìø ÿ. Cîøýîþ!ô ÿÿ,= ÿ õ îÿ # ùù$# ó Gð øù 1û $% Gð î ï ìî,î ï!ÿî ñï ÿ ð ýî ÿ!î í +î þ$ ï ì ÿîï3î ï ýð þ!ôîï ý ìÿ!îìîý îïh î "! ï ö2# ùù 1 óñ,7îý ð ï í I? ûj*'% %ñ,7îý ðï í þ)7% %3ì ÿ í ÿþ$%(% /ì ý ý ìð7øþ!ëtîð ï ÿ ì ÿ îï / 11 îøîÿ í % ðtí ì ÿø,oô ðõ ök. ï ð ðtí ì ÿ ï ï ï øþðtí ñ ï î41l 1;A # ù I? B þ$$% óõ Mÿîñ ïù 1ûN6ÿ ñøí ï ìîý ýî,"ÿ-îÿ ñÿ2!î ñï ÿ ð ýî ï!î í +î þ'ìø ÿ. îøýîþ!ô ÿÿ # ùù 1 óõ ñ -ðÿÿùl ûo2%õ ñ -ðÿÿ þ@c%ë ï ðõ þ$ %ô P ï ø þîï øtñõ î-+tñï3üï îìí,= ïì. ötîìí øï ÿ øtî40ìí"ü= ÿøí ý ìõ îÿ î ñï ÿð ýîÿ4!î í +îÿ þïîìí ø ðìî ïï % LþQ í îì ýñÿ- /ì ï í ø õ ð í øì ÿ ï-ðtí ì ö466 îï)3î ï.ñ ñ øí. 8ÿì î ï øìí PTí )'Mí í ì ÿîÿ # ùùl õ -îïñ ÿöí í î-ðò!îñ ï ÿ ð ýî!î í +îì ÿ,îï"ÿ-î ÿñ ÿ þ ó R6ù$#û /ìï í ø õ ð í øìÿ ï-ðtí ìö,/0 ù$# þìî-î 3î ï ýð - 14-

15 Anwendungsarchitektur der Versicherungswirtschaft (VAA) im Lichte der Objektorientierung Prof. Dr. Wolfgang Gerken und Prof. Dr. Jörg Raasch Fachhochschule Hamburg Fachbereich Elektrotechnik / Informatik Berliner Tor 3, Hamburg {gerken,raasch}@informatik.fh-hamburg.de Überblick Branchenspezifische Referenzmodelle für die Modellierung betrieblicher Geschäftsprozesse und die Entwicklung unternehmensweiter Datenmodelle sind nicht neu (siehe für Industriebetriebe z.b. /SCHEER-95/). Das Besondere und Begrüßenswerte an VAA - der Anwendungsarchitektur der Versicherungswirtschaft - ist, daß sich hier mehrere Versicherungsunternehmen zusammengetan haben, um gemeinsam ein versicherungswirtschaftliches Referenzmodell zu entwickeln. Dies geschah vor dem Hintergrund, daß zukünftige DV-Anwendungssysteme der Versicherungsunternehmen unter anderem zügig neue Geschäftsstrategien umsetzen lassen müssen, zentral und dezentral auf verschiedenen Plattformen verfügbar und kunden-, sparten- und vorgangsorientiert sein sollten. In diesem Artikel wird zu Beginn eine kurze Einführung in die VAA gegeben. Da derartige Referenzmodelle einerseits getätigte Investitionen sichern, anderseits aber sich auch an modernen und gesicherten Trends der Informatik messen lassen müssen, wird anschließend die VAA aus dem Blickwinkel der Objektorientierung betrachtet. Den Abschluß bildet die Vorstellung des Projektes SEVERS (Software-Engineering in der Versicherungswirtschaft) an der Fachhochschule Hamburg. Die Anwendungsarchitektur der Versicherungswirtschaft (VAA) Prinzipien der VAA Die VAA (vgl. zum Folgenden /GDV-95/) ist ein übergreifendes Konstruktionsprinzip zur Definition und Entwicklung von Standardbausteinen als Basissoftware und zur betriebswirtschaftlichen Definition von Anwendungsbausteinen. Innerhalb dieses genormten, offen zugänglichen Rahmens können Softwareanbieter und Versicherungsunternehmen wiederverwendbare S Software entwickeln, auswählen und in ihre Anwendungen einbinden. Die T Grundprinzipien der VAA sind: U Geschäftsprozeßorientierung, V Schichtung der Anwendung, W Bildung von wiederverwendbaren Bausteinen, X fachliche und technische Konfigurierbarkeit der Bausteine, Unterstützung der verteilten Verarbeitung und Verwendung internationaler, offener Standards zur Entkopplung der Systemsoftware. Gesamtarchitektur Die Anwendungsarchitektur besteht grob gesehen aus 5 Teilen: 1. dem Prozeßmodell, 2. dem Funktionsmodell, 3. dem Datenmodell, 4. der Bausteinschicht und - 15-

16 5. der Entkopplungs- und Schnittstellenschicht. Im Prozeß-, Funktions- und Datenmodell wird die fachliche Architektur beschrieben; die technische Architektur wird aus einem über den Systemplattformen liegenden Schichtenmodell bestehend aus einer Baustein- und einer Entkopplungs- /Schnittstellenschicht gebildet. Die folgende Abbildung stellt diese Komponenten und ihre Beziehungen zueinander dar. Bausteinschicht Daten- modell Funktionsmodell Arbeitsebene Realwelt Steuerungs- ebene Prozeßmodell Dienstebene Entkopplungs- und Schnittstellenschicht Systemplattform(en) - Systemsoftware - Hardware fachliche Architektur technische Architektur Das Datenmodell Im Datenmodell werden die zur Durchführung der Geschäftsprozesse notwendigen Datenstrukturen festgelegt. Man unterscheidet zwischen dem relativ abstrakten Unternehmensdatenmodell (UDM), daraus abgeleiteten Bereichsdatenmodellen und den wiederum aus den Bereichsmodellen abgeleiteten Anwendungsmodellen, auf denen letztendlich die DV-Anwendungssysteme operieren. Kern-Entitäten (des UDM) sind die Geschäftsobjekte Versicherungsvertrag, Partner, Schaden/Leistung, Geschäftsprozeßdokumentation, Produkt, Konto, Versicherungsobjekt und Dokument/Schriftstück/Datenträger. Diese Entitäten können und müssen in den Bereichsmodellen weiter verfeinert werden. So ist z. B. ein Partner entweder ein Versicherungskunde, ein Leistungspartner, ein Vertriebspartner, ein Mitarbeiter, ein Geschäftsbetriebspartner, ein Kapitalgeber oder eine interne organisatorische Einheit

17 Das Funktionenmodell Nach /FARNY-95/ können die betriebswirtschaftlichen Funktionen eines Versicherungsunternehmens wie folgt gegliedert und klassifiziert werden: 1. Unternehmen führen/leiten, 2. Produktionsfaktoren beschaffen, 3. Leistungen erstellen (Produktion), 4. Produkte absetzen, 5. Finanzierung sichern, 6. Unternehmen verwalten. Im Funktionenmodell werden alle diese betriebswirtschaftlichen Funktionen eines Versicherungsunternehmens betrachtet und mit Hilfe einer Funktion/Teilfunktion-Beziehung hierarchisch angeordnet. Funktionsbaum Das Prozeßmodell Die Prozeßsicht betrachtet Funktionen - im Gegensatz zur Funktionssicht - nicht statisch, sondern dynamisch, in der Reihenfolge ihres Einsatzes im Rahmen betrieblicher Prozesse. Ein Prozeß wird durch ein Ereignis gestarten und besteht evtl. selbst wieder, hierarchisch über mehrere Ebenen gegliedert, aus mehreren Teilprozessen, die einzelnen Funktionsbausteinen des Funktionsbaumes entsprechen. Die Aufgabe eines Prozesses besteht darin, den im Start-Ereignis enthaltenen Geschäftsprozeß-Auftrag funktional vollständig abzuarbeiten. Es gibt sieben versicherungsspezifische Geschäftsprozesse auf oberster Aggregationsebene: 1. Produkt entwickeln, 2. Produkt vertreiben, 3. Antrag bearbeiten, 4. Vertrag bearbeiten / Bestände verwalten, 5. Schaden / Leistung bearbeiten, 6. Be- und Abrechnung durchführen, 7. Abrechnung mit Dritten durchführen. dicker Pfeil: Standardablauf dünner Pfeil: mögliche Variante Die Bausteinschicht Diese Schicht dient zur DV-technischen Umsetzung der im Prozeßmodell beschriebenen Geschäftsprozesse. Die Steuerungsebene hat als Teil der Bausteinschicht die Aufgabe, den Ablauf der einzelnen Geschäftsprozesse zu steuern und zu überwachen. Die Arbeitsebene enthält die Implementierung der einzelnen betriebswirtschaftlichen Funktionen. Die Dienstebene stellt den beiden anderen Ebenen innerhalb der Bausteinschicht generell - 17-

18 benötigte Dienste zur Verfügung. Hier sind insbesondere ein Datenbank-Manager und ein Präsentations-Manager zu nennen. Die Entkopplungs- und Schnittstellenschicht Diese Schicht dient als Schnittstelle zwischen der Bausteinschicht und der Systemplattform, d.h. der Hard- und Systemsoftware (wie z.b. das DBMS), auf der das Anwendungssystem läuft. Man erreicht dadurch eine Portierbarkeit der Bausteinschicht auf verschiedene Systemplattformen. Die Trennung von Daten und Funktionen VAA geht in seiner bisher vorliegenden Beschreibung (vgl. /GDV-95/) von einer Trennung von Daten und Funktionen aus. Diese ist in der Vergangenheit oft als angemessenes Mittel zur Bewältigung der Kompliziertheit von Anwendungssystemen propagiert worden, gerade auch im Zusammenhang mit unternehmensweiter Datenmodellierung (vgl. z.b. /VETTER- 87/). Es sollte erreicht werden, daß die gesamte Datenbasis des Unternehmens der Anwendungsprogrammierung verfügbar gemacht wird. Programme sollten unter Wahrung der Datenkonsistenz und Zugriffsberechtigung auf alle Daten zugreifen können. Dies ist selbstverständlich vom Inhalt her ein wichtiges Ziel. Die Trennung von Daten und Funktionen beinhaltet jedoch wesentliche Probleme (vgl. /JACOBSEN-et.al.92/ S.75ff): 1. Alle Funktionen müssen das Wissen implementieren, wie die Daten gespeichert sind und nach welchen Regeln mit ihnen umzugehen ist. 2. Es gibt meistens einen Unterschied zwischen semantischer Datenmodellierung und der Implementierung, die Datenbank-spezifischen Randbedingungen zu genügen hat. 3. Systeme werden meist im Hinblick auf eine sehr spezielle Aufgabe entwickelt. Wenn dies auf die internen Strukturen durchgreift, dann werden die Wartbarkeit und auch die Wiederbenutzbarkeit beeinträchtigt. Diese Überlegungen, die im Software-Engineering seit einiger Zeit abgeschlossen sind, legen dringend nahe, die Trennung von Daten und Funktionen zu überwinden und in Objekten sowohl die Struktur als auch das typische Verhalten gemeinsam zu realisieren und für den Nutzer zu abstrahieren. Entscheidende Zielsetzungen für die Datenkapselung sind das Information-Hiding (/PARNAS-72/) und das Lokalitätsprinzip (vgl. z.b. /BALZERT-82/). Auf die Daten können nur exclusive Funktionen zugreifen, die mit den Daten (eines Objekts) eine untrennbare Einheit bilden. Die dadurch entstehenden Datenkapseln (Objekte) kommunizieren miteinander über Nachrichten, können aber nicht die Schutzgrenzen überschreiten, die durch extern verfügbar gemachte Schnittstellen realisiert sind. Bezogen auf VAA bedeutet dies, daß man eine zukunftsträchtige Architektur nicht auf dem heute schon veralteten Prinzip der Trennung von Daten und Funktionen aufbauen sollte sondern eher auf Objektorientierung. Diese enthält weitere Konzepte und Vorteile, die im nächsten Abschnitt angesprochen werden sollen. Objektorientierung Was ist Objektorientierung? In der Literatur sind außerordentlich viele, auch unterschiedliche Definitionen zu finden. Wir werden an dieser Stelle keine weitere Definition versuchen, sondern mit Rückgriff auf Literatur die wichtigsten Konzepte wenigstens ansprechen. Eine vertiefte Darstellung kann in der Kürze natürlich nicht geleistet werden. Kennzeichen für objektorientierte Systeme Die meisten Autoren sind sich einig, daß folgende Eigenschaften zu einem objektorientierten System hinzugehören (vgl. z.b. /MEYER-88/ Kap. 4.9): 1. Datenkapselung: Software wird als Kollektion von diskreten Objekten organisiert, die sowohl Struktur als auch Verhalten kapseln 2. Objektbasierte modulare Struktur: Systeme werden auf der Grundlage ihrer Datenstrukturen modularisiert

19 3. Klassen und Klassifikation: Objekte werden zu Objektmengen mit gleichem Verhalten und gleicher Struktur zusammengefaßt. Umgekehrt liefert eine Klassifikation der für eine Anwendung relevanten Gegenstände eines Anwendungsverfahrens Objektmengen (Klassen), deren Elemente (Objekte) gleiche Struktur und gleiches Verhalten haben. Wichtig ist, daß man die Eigenschaften der relevanten Gegenstände genau untersucht und adäquat modelliert (vgl. /COAD-YOURDON-91a/ Kap ). Klassen werden häufig mit dem Typbegriff in Verbindung gebracht. Mit Klassen lassen sich Typen implementieren. 4. Vererbung, Generalisierung/Spezialisierung: Eine Klasse kann als Einschränkung (Spezialisierung) oder Erweiterung (Generalisierung) einer anderen Klasse definiert werden. Damit kann die Begriffswelt des Anwenders unter Benutzung der isa-semantik (Typvererbung) angemessen nachgebildet werden (Ein Kunde ist ein Partner, d.h. ein spezieller Partner, ein Partner mit zusätzlichen definierenden Eigenschaften). Vererbung ist auch nützlich in der Implementierung bei Wiederbenutzung bereits fertiger Technologieoder Anwendungsklassen (kindof-semantik) 5. Polymorphismus und dynamische Bindung: Programm-Elemente dürfen sich auf Objekte aus mehr als einer Klasse beziehen, und Operationen dürfen unterschiedliche Realisierungen in verschiedenen Klassen haben. Erst mit dieser Eigenschaft werden typabhängige Fallunterscheidungen, die in älteren Entwicklungsumgebungen eine häufige und überaus lästige Fehlerquelle darstellen, entbehrlich. Man kann einem Empfängerobjekt eine Nachricht schicken, dieses Objekt weiß selber am besten, wie diese Nachricht beantwortet werden muß und kann entsprechend reagieren. Es macht keinen Sinn, den Absender der Nachricht mit derartigem Detailwissen über Struktur und Verhaltensimplementation der Empfängerobjekte zu belasten. Analyse und Design objektorientiert Objektorientierung ist nicht nur ein Mittel zur Systemrealisierung, bei dem die wesentlichen Grundsätze des Information-Hiding und der Lokalität, die schon seit sehr langer Zeit bekannt und gefordert sind, endlich zum integralen, unverzichtbaren Bestandteil der Systementwicklung gemacht werden. Auch auf Ebene der Anwendungsspezifikation ergeben sich durch Nutzung objektorientierter Vorgehensweisen Veränderungen, die insgesamt als Verbesserung wirken können. Zunächst ist dringend zu empfehlen, durchaus im Unterschied zu bisher üblichen Vorgehensweisen, in den erforderlichen Gesprächen mit Anwendern die durch DVspezifische Beschreibungsmittel entstehenden Modellmonopole zu vermeiden. Der Anwender kann sich oft nicht in der Sprache der Anwendungsentwickler artikulieren und damit auch nicht seine Gedanken zum Anwendungssystem geltend machen. Stattdessen beschränke sich der Anwendungsentwickler auf das Zuhören und auf die verbindliche Rekonstruktion einer Projektsprache (vgl. /KILBERTH-et.al.-94/). Es gilt, die vom Anwender beschriebenen Beispiele zu verstehen und zu dokumentieren und alle auftretenden Begriffe einvernehmlich zu definieren. Dies ist in jedem Fall eine verläßliche Basis für die Entwicklung. Das weitere Vorgehen ist geprägt von evolutionärer Entwicklung und von Prototyping. Im Ergebnis entstehen neben dem implementierten System die Spezifikation der Anwenderanforderungen im fachlichen Klassendesign und die Spezifikation der Nutzung von vorgefertigten Komponenten im technischen Klassendesign. Entscheidend ist, daß durch Objektorientierung die Chance eröffnet wird, die Semantik der Aufgabenstellung präzise zu erfassen und direkt als Basis für die Implementierung des Systems heranzuziehen. Technische Hilfskonstruktionen, in deren Kompliziertheit die ursprüngliche Absicht nicht mehr erkennbar ist, sollten der Vergangenheit angehören. Durchgängigkeit der Systementwicklung ist ein wesentliches Kriterium für die Entwicklungsumgebung. Sie wird eigentlich erst mit Objektorientierung möglich. Ältere Vorgehensweisen, z.b. die Strukturierten Methoden (vgl. /RAASCH-93/), beinhalten einen - 19-

20 sehr komplizierten und vor allem meist irreversiblen Schritt in der Vorgehensweise beim Übergang vom Analysemodell zum Designmodell. Dieser Übergang ist dadurch gekennzeichnet, daß sowohl technische Aspekte und Implementierungsdetails hinzugefügt werden als auch, besonders schmerzlich, die Beschreibungsmittel gewechselt werden. Dadurch ist im Modulentwurf und erst recht im implementierten Programm oft nicht mehr erkennbar, auf welche Anforderung sich ein Implementierungsdetail bezieht. Erforderliche Programmänderungen können nicht so leicht im Analysemodell nachvollzogen werden und bei Änderungen des Analysemodells ist nicht immer klar, welche Implementierungskomponenten verändert werden müssen. Diese Probleme sind Praktikern hinlänglich bekannt. Auf der Suche nach neuen Software-Entwicklungsumgebungen besitzt daher die Durchgängigkeit eine besondere Bedeutung. In der Objektorientierten Analyse wird man nun Klassen identifizieren, die in gleicher Weise auch später im implementierten System anzutreffen sind. So wird man in Gesprächen mit Anwendern sofort darauf kommen, daß etwa ein Vertrag ein für die Anwendung überaus wichtiges Objekt ist. Dieses wird in Struktur und Verhalten differenziert besprochen und geplant und ist dann später im objektorientiert implementierten System als Klasse Vertrag wiedererkennbar. Diese Klasse definiert dann auch Struktur und Verhalten von Verträgen, so wie es in Abstimmung mit dem Anwender festgelegt wurde. Bei der Realisierung wurden sicher Implementierungsdetails hinzugefügt, aber der Vertrag als wesentlicher Anwendungsbaustein blieb erhalten, ohne daß sich die Modellstruktur wesentlich verändert hat. Die im Rahmen der Objektorientierten Analyse erkannten Klassen werden genauso wie die im Rahmen von Design-Aktivitäten entwickelten Klassen mit speziell auf die Objektorientierung abgestimmten Beschreibungsmitteln wie etwa OMT (vgl. /RUMBAUGHet.al.-91/) spezifiziert. Hierfür stehen auch CASE-Werkzeuge bereit, die allerdings noch eine Weiterentwicklung verdienen. Immerhin wird in solchen Werkzeugen aufgrund der guten Durchgängigkeit der objektorientierten Methodik der Weg zum implementierten System auch durch Funktionen der Codegenerierung erleichtert. Hier darf man sich aber keinen Illusionen hingeben! Codegenerierung heißt hier allenfalls so etwas wie Besitzstandswahrung : Was schon einmal spezifiziert worden ist, kann man in anderen Formaten auch wieder vom Werkzeug ausgeben lassen. Natürlich sind bisher und auch in absehbarer Zukunft verfügbare Werkzeuge nicht in der Lage, aus einer nicht-formalen Semantik-Beschreibung Programmcode abzuleiten. Vorgehensmodelle Die Entwicklung von Systemen erfolgt bisher in der Praxis zumeist, wenigstens nominell, innerhalb einer Vorgehensweise nach dem sogenannten Wasserfallmodell, das natürlich jedem Praktiker bekannt ist. Vom Wasserfall abgeleitete Vorgehensmodelle gehen alle letzlich auf (/ROYCE-70/) zurück. Damals, 1970, war weder die Größenordnung heute üblicher Systeme noch der erforderliche Integrationsgrad noch die verfügbare und tatsächlich eingesetzte Technologie auch nur in Umrissen ahnbar. Seit vielen Jahren hat das Wasserfallmodell seine Grenzen deutlich gezeigt. Alle Vorgehensmodelle vom Wasserfall-Typ gehen von den folgenden beiden Voraussetzungen aus (vgl. /LORENZ-93/ S.8,9): Y Perfect understanding assumption: Das Wasserfallmodell geht davon aus, daß zu einem gewissen Zeitpunkt etwa die Analyse abgeschlossen werden kann, weil die Analytiker die Aufgabenstellung vollständig und in allen Details verstanden haben. Das Erwachen kommt in der Realisierung, wenn man merkt, daß mit dem Anwender in vielen Punkten eben doch nicht präzise genug gesprochen wurde. Nicht selten werden extrem teure Konzeptionsänderungen erforderlich, oder man entwickelt ein System, von dem schon vor Einführung bekannt ist, daß es partiell an den wahren Anforderungen des Anwenders vorbeigeht. Heutige Systeme sind den Beteiligten offensichtlich immer nur bis zu einem gewissen Durchdringungsgrad vertraut. Am besten bemüht man sich - 20-

21 Z gemeinsam mit dem Anwender um das für die Systemneugestaltung erforderliche Kompetenzniveau. No change assumption: Das Wasserfallmodell geht weiterhin implizit davon aus, daß nach Ende der Analyse bis zur Einführung des Systems, also im Laufe vielleicht eines halben oder ganzen Jahres, keine Änderungen der Anforderungen des Anwenders auftreten. Also keine Änderungen von Gesetzen, Tarifen, Vorschriften, auch keine verbesserte Artikulationsfähigkeit des Anwenders in bezug auf das neue System. Die Folge ist, daß Eigenschaften, die bereits in der ersten Version verfügbar sein müßten, verspätet bereitgestellt werden und daß die Entwickler immer nur auf die nächste Version verweisen. Die Folge ist auch, daß Änderungen der Anwenderanforderungen als Störung empfunden und auch so behandelt werden. Eine partnerschaftliche Kommunikation zwischen Anwender und Entwickler wird dadurch gar zu oft zerstört. In konkreten Projekten sind beide Voraussetzungen bis zur Unerträglichkeit unerfüllt. Dies wird von erfahrenen Praktikern auch nicht geleugnet. Weitere Punkte könnten mühelos ergänzt werden. Aktuelle Bemühungen, etwa durch das V-Modell des Bundesverteidigungsministeriums (vgl. BRÖHL-DRÖSCHEL-93/) den Wasserfall zu konservieren, gehen am Kern der Entwicklungsprobleme vorbei. Ein Fortschritt ist nur durch Abkehr vom viel zu starren Wasserfall möglich. Hier stehen evolutionäre Vorgehensweisen, etwa nach dem Spiralmodell (/BOEHM-86/), im Vordergrund, die ergänzt durch Prototyping in besonderer Weise die objektorientierte Anwendungsentwicklung unterstützen (vgl. /BUDDEet.al.-92/, /KILBERTH-et.al.-94/). Vorteile der Objektorientierung Die Vorteile objektorientierter Anwendungsentwicklung liegen klar auf der Hand, wenn auch manche Details ergänzt und präzisiert werden könnten. Hier seien nochmal genannt: 1. Information-Hiding und Lokalität als integraler Bestandteil der Entwicklung 2. Direkte Repräsentierung der Semantik der Aufgabenstellung in den Modellen und im implementierten System sind erreichbar 3. Vereinfachung der Analyse durch kooperativere Umgangsformen mit dem Anwender, realistische Einschätzung des Informationsgehalts von Anwendergesprächen und geradlinige Verwendung aller Informationen in der Systemspezifikation 4. Durchgängigkeit in der Entwicklung Zu ergänzen wären unter anderem noch: 1. Die Realisierung von Client/Server-Anwendungen legt durch die Realisierungshilfsmittel Objektorientierung nahe 2. Auf Dauer ist größere Produktivität der Anwendungsentwicklung möglich (Ausbildungsproblem) 3. In zunehmendem Maße stehen objektorientierte Realisierungsumgebungen zur Verfügung, die sowohl Client/Server-Entwicklung wie auch etwa die Anbindung gängiger Datenbanksysteme, aber auch die echte binärkompatible Verteilung von Objekten über unterschiedliche Hardware-Plattformen hinweg ermöglichen. Mitunter wird vorgebracht, daß Objektorientierung nicht neu ist. Das stimmt, ein Anfang ist in der Entwicklung der Sprache Simula (Ende der 60er Jahre) zu sehen. Seitdem wurde Objektorientierung in den Labors und etwa in Anwendungen der Künstlichen Intelligenz erfolgreich genutzt. Erst als die in der kommerziellen Anwendungsentwicklung benutzten Methoden ihre Grenzen klar aufgezeigt hatten, fand die Objektorientierung einen kommerziellen Durchbruch, der aber nicht als Erfindung sondern eher als Entdeckung zu werten ist. Das zweite wesentliche Motiv, die Entwicklung ergonomischer grafischer Benutzungsschnittstellen, setzte billig verfügbare Workstation-Hardware voraus,- diese Voraussetzung ist erst seit kurzem erfüllt. Auch wird gelegentlich von Praktikern eingewandt, daß sie schon lange objektorientiert programmiert hätten. Gemeint sind dann oft nur Datenzugriffsfunktionen und andere Maßnahmen, mit denen Datenunabhängigkeit und Unabhängigkeit von Datenbanksystem - 21-