Zusammenfassung
Die Konstruktion anspruchsvoller Software-Systeme ist ein komplexer Prozeß, der zur zielgerichteten und zweckmäßigen Planung, Durchführung und Kontrolle aller technischen und organisatorischen Aufgaben methodisch umfassend konzipiert sein muß. Elementare Grundlage der methodischen Ansätze ist die Betrachtung im Rahmen eines Lebenszyklus-Konzeptes, das den zeitlich-organisatorischen Aspekt der anfallenden Tätigkeiten in den Vordergrund stellt und die Festlegung einer geordneten und schrittweisen Reihenfolge der Aktivitäten in einem Vorgehensmodell anstrebt.1 Für die Entwicklung von Expertensystemen sind hierzu spezielle Schemata aufgestellt worden, die den Prozeß ihrer Erstellung strukturieren.
This is a preview of subscription content, log in via an institution to check access.
Access this chapter
Tax calculation will be finalised at checkout
Purchases are for personal use only
Preview
Unable to display preview. Download preview PDF.
Literatur
Vgl. Denen, Hesse /Projektmodell und Projektbibliothek! 215 f. und Luft /Bedeutung von Modellen/ 191 f.
Buchanan und Smith bezeichnen diese beiden Vorgehensweisen als case-directed und model-directed; vgl. Buchanan, Smith /Fundamentals of Expert Systems/ 42. Es ist darauf hinzuweisen, daß keine Detailkritik der einzelnen Vorgehensmodelle angestrebt wird, sondern daß ihre Vorstellung auf die Veranschaulichung der beiden Prinzipien der Entwicklung von Expertensystemen abstellt; dementsprechend konzentrieren sich auch die weiteren Ausführungen in diesem Kapitel auf diesen Aspekt.
Dieser Ansatz wird in der Literatur als code-and-fix model bezeichnet; vgl. Boehm /Spiral Model/ 61 ff.
Vgl. Hayes-Roth, Klahr, Mostow /Knowledge Acquisition/ 6 f.
Vgl. Seibt /Phasenkonzept/ 253
Vgl. hierzu Budde u. a. /Konzepte des Prototyping/ 80
Vgl. Boehm /Software engineering economics/ 41 ff.
Vgl. Boehm /Spiral Model/ 63
Vgl. hierzu Dearnley, Mayhew /System Prototypes/
Vgl. Boehm /Spiral Model/ 64 f. Zu einer Diskussion der Integration von Prototyping in ergänzte Software-Lebenszyklen gegenüber der Aufstellung reiner Prototyping-Vorgehensmodelle für den konventionellen Bereich vgl. Schulz /Software-Lifecycle-und Vorgehensmodelle/ 139 f.
Karbach bezeichnet diese Vorgehensweisen als Stufenkonzepte; vgl. Karbach /Knowledge Engineering/ 19. Diese Begriffswahl muß aus Sicht der konventionellen softwaretechnisch-methodischen Entwicklung als irreführend eingestuft werden, da der Begriff des Stufenkonzeptes hier für lineare Phasenschemata verwendet wird; vgl. hierzu Boehm /Spiral Model/ 63.
Vgl. z. B. die Gliederung in knowledge acquisition, knowledge programming und knowledge refinement in Hayes-Roth, Klahr, Mostow /Knowledge Acquisition/ 19 ff.
Vgl. Buchanan u. a. /Constructing/ 140 ff.
Vgl. z. B. Hayes-Roth /Tutorial/ 19; Noelke /Knowledge Engineering/ 112 ff.; Puppe /Einführung in Expertensysteme/ 111.
Es werden auch Checklisten von abstrakten Fragen für die Phasen der Problemidentifikation, Wissenskonzeptionalisierung und Wissensformalisierung angeführt.
Hierbei wird davon ausgegangen, daß aus einem Produkt-Archiv Module gewonnen werden können, die als Bausteine zu einem funktionellen Prototyp-System ohne Berücksichtigung von Speicherressourcen und Laufzeiteffizienz zusammengestellt werden; vgl. hierzu Balzen /Entwicklung von Software-Systemen/ 62 f. Darüber hinaus ermöglichen insbesondere Programmiersprachen der vierten Generation die Konstruktion lauffähiger Vorabversionen des zu entwickelnden Systems; vgl. hierzu Bolkart /Programmiersprachen/ 61 ff.
Vielfach wird die Empfehlung ausgesprochen, so schnell wie möglich mit der Erstellung eines Prototyps zu beginnen. Vgl. hierzu Buchanan u. a. /Constructing/ 161; Feigenbaum, McCorduck /Fünfte Computer-Generation/ 99; Welbank /Knowledge Acquisition Techniques/ 7.
Aus diesem Grund werden viele Vorgehensmodelle der Entwicklung von Expertensystemen als Ansätze für die knowledge acquisition bezeichnet; vgl. z. B. Buchanan u. a. /Constructing/ 140 und Grover /Knowledge Acquisition Methodology/.
Vgl. Mayr, Bever, Lockemann /Interactive Application Systems/ 2
Vgl. z. B. die Entwicklung des Expertensystems XCON (expert configurer). Ausgehend von den Kundenwünschen leistet XCON die Konfiguration der Hardware-Komponenten für Rechner der Firma Digital Equipment Corporation (DEC); hierbei wurde mit der Konfiguration der Systeme VAX-11/780 (_virtual address extended) als Prototyp begonnen. Vgl. McDermott /R1 The Formative Years/ 22. Zu XCON vgl. Barker, O’Connor /XCON and Beyond/.
Die Bezeichnungen gehen zurück auf Keus /Prototyping/ 94 f.
Für das zugrundeliegende Vorgehen wird vielfach auch der Begriff des Rapid Prototyping verwendet, der die besonders rasche Erstellung einer ablauffähigen Version herausstellt; vgl. Wild /Prototyp-Entwicklung/.
Budde u. a. verwenden hierfür auch den Begriff des Pilotsystems; vgl. Budde u. a. /Konzepte des Prototyping/ 87.
Vgl. z. B. Bobrow, Mittal, Stefik /Perils and Promise/ 888 und Guida, Tasso /Building Expert Systems/ 15 ff.
Vgl. Harmon, King /Expertensysteme/ 227
Vgl. z. B. Buchanan u. a. /Constructing/ 146
Die Klassifikation in exploratives, experimentelles und evolutionäres Prototyping geht auf Floyd zurück; vgl. Floyd /Systematic Look at Prototyping/ 6 ff. Law ergänzte diese Einteilung um leistungsbezogenes und organisatorisches Prototyping; vgl. hierzu Mayhew, Dearnley /Alternative Prototyping Classification/ 481 f. Vgl. auch Budde u. a. /Konzepte des Prototyping/ 86 f.
Vgl. Waterman /Expert Systems/ 139 ff. Waterman charakterisiert die Prototypen zusätzlich durch die Angabe einer durchschnittlichen Anzahl von Regeln in der Wissensbasis. Diese Werte werden hier aus verschiedenen Gründen nicht angeführt: zum einen sind Regeln nur ein möglicher Formalismus zur Darstellung von Wissen, und es besteht keine quantitative Zuordnungsmöglichkeit zwischen den Repräsentationskonstrukten eines Formalismus zu denen eines anderen. Zum anderen wird keine Angabe über die Komplexität einer Regel in Form von Anzahl der Aussagen in den Prämissen bzw. Konklusionen und ihren jeweiligen logischen Verknüpfungsmöglichkeiten getroffen. Darüber hinaus bleibt auch die Qualität des Wissens offen, das durch die Beziehung Prämisse - Konklusion ausgedrückt wird.
Vgl. Buchanan u. a. /Constructing/ 132 ff. und Guida, Tasso /Building Expert Systems/ 16
Vgl. Davis, Olson /Management Information Systems/ 564 ff. Der Aspekt des Fehlens von Nutzenvorstellungen ist eine Ergänzung der von Davis und Olson angeführten Punkte, der auf den Einsatz eines Prototyps im Rahmen einer Machbarkeitsstudie abstellt; es sollen Nutzenvorstellungen konkretisiert und somit die Durchführbarkeit eines Projektes abgesichert werden.
Vgl. z. B. Buchanan, Shortliffe /Major Lessons/ 686; Thuy, Schnupp /Wissensverarbeitung/ 249; Weiss, Kulikowski /Designing Expert Systems/ 106.
Als Konsequenz ergibt sich, daß Expertensysteme Fehler machen können; vgl. Waterman /Expert Systems/ 29 f.
Die Fehleinschätzung dieser fundamentalen Charakteristik, die aus der Verwendung von Heuristiken resultiert, führte dreimal zum Abbruch der Entwicklung von XCON; vgl. Bobrow, Mittal, Stefik /Perils and Promise/ 882. Vgl. hierzu auch McDermott /R1 The Formative Years/ 29.
Vgl. Luft /Informatik als Technik-Wissenschaft/ 217 ff.
Vgl. Buchanan u. a. /Constructing/ 146
Hierdurch wird nicht zuletzt der Eigenschaft des Menschen Rechnung getragen, besser etwas Vorgegebenes kritisieren als etwas Vorzustellendes erklären zu können; vgl. Agapeyeff /Nature of expertise/ 156 und Bell, Hardiman /Naturalistic knowledge engineer/ 72.
Diaper weist darauf hin, daß der Einbezug des Benutzers in die Expertensystem-Entwicklung den Benutzer häufig in eine für ihn ungewohnte Position versetzt; vgl. Diaper /Designing expert systems/ 26. Dieses Argument scheint jedoch nur für Unternehmungen gültig, die bislang auch im konventionellen Bereich keine partizipative Systementwicklung praktiziert haben.
Vgl. Floyd /Systematic Look at Prototyping/ 14 f.
Vgl. hierzu Seibt /Probleme und Aufgaben/ 12
Vgl. hierzu Burns, Dennis /Application Development Methodology/ 22
Abel /Une méthode de développement/ 103
Buchanan u. a. berücksichtigen daher in ihrem Ansatz eine separate Phase der Prototyp-Verbesserung; vgl. Buchanan u. a. /Constructing/ 148 f.
Vgl. Bachant, McDermott /R1 Revisited/ 23
Vgl. Bachant, Soloway /Engineering of XCON/
Vgl. Agapeyeff /Nature of expertise/ 157 und Gruber, Cohen /Design for acquisition/ 133
Vgl. Abel /Une méthode de développement/ 104
Vgl. hierzu Dijkstra, Feijen /Methodik des Programmierens/. Abel stellt Prototyping bei Expertensystemen auf eine Stufe mit der GO-TO-Programmierung im konventionellen Bereich; vgl. Abel /Une méthode de développement/ 111.
Vgl. zu den im einzelnen notwendigen Aktivitäten die Darstellung in Bachant, McDermott /Rl Revisited/ 25 ff.
Vgl. Hayes-Roth, Waterman, Lenat /Expert Systems/ 24 ff.
Die Veränderung eines Wissenselementes erfordert zumeist auch eine Anpassung vieler damit in Verbindung stehender Konzepte; die Modularität deklarativer Wissensrepräsentationsformalismen stößt bei Prototyping semantisch häufig an Grenzen. Vgl. Abel /Une méthode de développement/ 107 f. Vgl. Greef, Breuker /Case Study/ 390
Vgl. die Analyse der Abhängigkeit zwischen dem Aufwand zur Fehlerbeseitigung und dem Zeitpunkt der Fehlerentdeckung für den konventionelllen Bereich in Schmitz /Methoden/ 74, die auf den wissensbasierten Sektor übertragen werden kann.
Vgl. Diaper /Designing expert systems/ 26 f.
Vgl. Smith /Development of Commercial Expert Systems/ 69
Vgl. Schachter-Radig /Wissenserwerb und -formalisierung/ 315
Vgl. Hickman u. a. /Analysis/ 38
Vgl. Schreiber u. a. /Modelling in KBS Development/ 7–3
Vgl. Pfeifer /Knowledge Acquisition und Lernen/ 258
Vgl. Budde, Sylla, Züllighoven /Prototyping/ 280
Es ist in diesem Zusammenhang zu berücksichtigen, daß die Idee des Prototyping auf die in den Forschungslabors der Künstlichen Intelligenz gängige Praxis der Systementwicklung zurückgeht, die unter anderen Zielsetzungen erfolgt, als die Entwicklung von Expertensystemen für die Praxis.
Vgl. Abel /Une méthode de développement/ 105
Vgl. Luft /Bedeutung von Modellen/ 189
Vgl. Luft /Bedeutung von Modellen/ 190. Das theoretische Ziel der Künstlichen Intelligenz ist hierfür ein prägnantes Beispiel.
Zur Unterscheidung von analogischen und symbolischen Modellen vgl. Schefe /Künstliche Intelligenz/ 26 f.
Vgl. Gebhardt, Ameling /Objektorientierte Programmierung/ 430
Vgl. hierzu Chen /Entity-Relationship Model/ und Jackson /Systems development/
Vgl. Wedekind /Datenbanksysteme 1/ 34 ff.
Vgl. Luft /Informatik als Technik-Wissenschaft/ 217 ff.
Vgl. Luft /Informatik als Technik-Wissenschaft/ 176 ff., 217 ff. Zur Definition von Konstruktion in der Softwaretechnik vgl. Hesse u. a. /Begriffssystem/ 203 f., 206 f.
Vgl. Inhetveen, Luft /Abstraktion/ 547
Vgl. hierzu auch die pragmatische Definition von Wissen in Kapitel 2.1 sowie die Ausführungen zur Adäquatheit von Expertensystemen und der Möglichkeit ihres Fehlverhaltens in Kapitel 3.2.1.2.
Stefik, Conway /Engineering of Knowledge/ 1
Vgl. zu dieser Metapher z. B. Feigenbaum, McCorduck /Fünfte Computer-Generation/ 95. Diese stark vereinfachende Sichtweise ist Grundlage der meisten Vorgehensmodelle, die ein möglichst rasches Erstellen eines ersten Prototyps propagieren, der inkrementell ausgebaut wird; vgl. hierzu die Ansätze in Kapitel 3.1.
Michié s Ausdruck epistemological engineering deckt auch diese Sichtweise ab; vgl. hierzu Kapitel 1.3.
Vgl. Morik /Sloppy Modelling/. Schefe bevorzugt daher den Begriff Wissensrekonstruktion gegenüber der allgemein verwendeten Bezeichnung Wissensrepräsentation, um die Notwendigkeit konstruktiver Tätigkeit für die Abbildung von Wissen herauszustellen; vgl. Schefe /Rekonstruktion/ 230.
Vgl. hierzu Simon /Sciences of the Artificial/
Diese Forderung wird auch von Vertretern des Prototyping-Prinzips erhoben; vgl. z. B. Buchanan /New research/ 269.
Vgl. Breuker, Wielinga, Hayward /Structuring/ 774
Der Begriff der Spezifikation bezeichnet auch im Bereich der konventionellen Software-Entwicklung insbesondere die Analyse und Re-Konstruktion des Problem-bzw. Aufgabenbereiches; vgl. Inhetveen, Luft /Abstraktion/ 542.
Vgl. hierzu Clancey /Knowledge Bases as Qualitative Models/ und Inhetveen, Luft /Abstraktion/ 543
Vgl. Schachter-Radig, Krickhahn /Strukturen/ 426 ff. und Schreiber u. a. /Modelling in KBS Development/ 7–2 ff.
Diese konzeptionelle Distanz ist Ursache des häufig beklagten knowledge acquisition bottleneck; vgl. Schreiber u. a. /Modelling in KBS Development/ 7–3.
Im Gegensatz zu KADS wird das konzeptionelle Modell Ml aufgrund der hiermit verfolgten epistemologischen Zielsetzung auf einer abstrakteren Ebene angesiedelt als das globale Entwurfsmodell M2, in dem bereits Bezug auf informationstechnische Elemente und Strukturen genommen wird. Zu einer Darstellung nach KADS, die von der vorliegenden Abbildung entsprechend modifiziert wird, vgl. Schachter-Radig, Krickhahn /Strukturen/ 428.
Vgl. Wielinga, Breuker /Interpretation of verbal data/ 11
Vgl. Brachman /Epistemological Status/ 27 ff.
Vgl. Breuker u. a. /Interpretation Models/ 9 und Schreiber u. a. /Modelling in KBS Development/ 7–2 ff. Im Unterschied zu diesen Darstellungen wird jedoch auf die dieser Arbeit zugrundeliegende Terminologie und Sichtweise abgestellt.
Vgl. Breuker u. a. /Interpretation Models/ 5 f.
Wird im Rahmen der vorliegenden Arbeit nur die Modellierung auf der konzeptionellen Ebene angesprochen, so wird dies durch die Herstellung eines expliziten Bezugs zur konzeptionellen Ebene oder dem substantiellen Wissen zum Ausdruck gebracht. Die Bezeichnungen konzeptionelles Modell und Modell werden synonym verwendet.
Vgl. Schreiber u. a. /Modelling in KBS Development/ 7–2 ff.
Vgl. Hickman u. a. /Analysis/ 17 ff. Schachter-Radig und Krickhahn verwenden für M1 die Bezeichnung Analysemodell und unterscheiden hierbei drei konstituierende Elemente: ein konzeptionelles Modell, ein Kooperationsmodell und ein Anforderungsmodell. Vgl. hierzu Schachter-Radig, Krickhahn /Strukturen/ 427 f. Hickman u. a. sehen den gesamten Prozeß der Transformation von Modellen unter der Berücksichtigung externer Anforderungen; ein Einfluß auf den Inhalt des konzeptionellen Modells wird jedoch ausgeschlossen. Vgl. hierzu Hickman u a /Analysis/ 18 f.
Vgl. hierzu Greef, Breuker, Jong /Modality/. Der Zielsetzung dieser Arbeit entsprechend wird hier nur das Modell des Wissens des Experten betrachtet und als konzeptionelles Modell bzw. Modell bezeichnet.
Eine ähnliche Unterscheidung treffen Waterman und Newell, die eine linguistische und eine semantische Ebene der Repräsentation sowie eine psychologische Dimension der Abbildung des Problemlösungsverhaltens aufzeigen; vgl. Waterman, Newell /Protocol Analysis/ 292 ff.
Vgl. Bums, Dennis /Application Development Methodology/ 21
Vgl. Bobrow, Mittal, Stefik /Perils and Promise/ 882
Vgl. Inhetveen, Luft /Abstraktion/ 543
Auch die Vertreter des Prototyping-Prinzips betonen die Notwendigkeit eines Verständnisprozesses beim Knowledge Engineer, den sie nur durch den Einsatz ablauffähiger Prototypen als möglich ansehen. Sie gehen jedoch von einer inkrementellen Anpassung des Prototyps aus, die zu der Vermischung verschiedener Wissensarten führt; eine Explikation und Dokumentation des Verstandenen wird nicht in Betracht gezogen. Vgl. z. B. Partridge /K1/ 103 ff. und Thuy, Schnupp /Wissensverarbeitung/ 252 f.
Durch den Aufbau eines Modells der Kooperation des Benutzers mit dem zu entwickelnden Expertensystem werden auch die diesbezüglichen Anforderungen an die Gestaltung der Dialog-und Erklärungskomponente berücksichtigt.
Reinecke schätzt die Verringerung des Aufwandes auf ca. 80%; Basis dieser Aussage ist ein Vergleich zweier ähnlicher Projekte, von denen eines über Prototyping und eines über Modellierung durchgeführt worden ist. Vgl. Reinecke /Entwicklung/ 149.
Breuker und Wielinga berichten von einer Verringerung des Aufwandes für die Analyse auf ein Drittel; vgl. Breuker, Wielinga /Models of Expertise/ 289.
Diese Zielsetzung modellbasierter Expertensysteme ist eine Weiterführung des Konzeptes des Information Hiding, das von Parnas als Grundsatz einer Software-Methodik gefordert wurde; vgl. Parnas /Module Specification/.
Vgl. Schachter-Radig, Krickhahn /Strukturen/ 432 f.
So weisen die Wissensstrukturen und Problemlösungsvorgänge z. B. bei einer Risikoprüfung im Bereich von Versicherungen sowohl für unterschiedliche Sparten als auch für verschiedene Versicherungsunternehmungen Gemeinsamkeiten auf.
Vgl. z. B. Busche, Krickhahn /Fehlerdiagnose in Industrieanlagen/; Haugeneder, Lehmann, Struß /Knowledge-Based Configuration/ 130; Hayward, Wielinga, Breuker /Structured analysis/.
Vgl. Hickman u. a. /Analysis/ 40. An anderer Stelle betonen die Autoren jedoch, daß ein konzeptionelles Modell als Spezifikation mindestens den gleichen Nutzen für den Systementwickler hat wie ein ablauffähiger Prototyp; vgl. Hickman u. a. /Analysis/ 162.
Z. B. spezielle Editoren, Generatoren oder Testhilfen
Beispielhaft sei hierzu Feigenbaums Einschätzung des von Michie geprägten Terminus epistemological engineering angeführt; vgl. hierzu Kapitel 1.3.
Es wird nochmals darauf hingewiesen, daß kein detailliertes Phasen-und Aktivitätenschema angestrebt wird; das Ziel liegt in der Aufstellung eines Vorgehensmodells, das die beiden bislang im allgemeinen als unvereinbar dargestellten Prinzipien des Prototyping und der Modellierung vereint, und das eine Einordnung der in dieser Arbeit vorgestellten Ansätze ermöglicht.
Vgl. Bums, Dennis /Application Development Methodology/ 22 Vgl. z. B. Karbach /Knowledge Engineering/ 10 ff.
Vgl. z. B. Buchanan, Smith /Fundamentals of Expert Systems/ 42.
Auch das Schema nach KADS schließt in der jüngsten Veröffentlichung Prototyping in die Betrachtungen ein; vgl. Hickman u. a. /Analysis/ 36. In früheren Literaturstellen zu KADS wurde der Einsatz von Prototyping nicht vorgesehen; vgl. z. B. Wielinga, Breuker /Models of Expertise/.
Die zu durchlaufenden Tests für den Einsatz von Prototyping während der Entwicklung eines Expertensystems sind Entwicklungstests, bei Prototyping in der Pflegephase wird dieser Test als Pflege-oder Wartungstest bezeichnet. Sie können jedoch nur Bestandteil der innerhalb jeder Phase des Vorgehensmodells vorzunehmenden Entwicklungs-oder Pflegetests sein. Zu der Notwendigkeit des Testens in allen Phasen des Lebenszyklus von Software-Systemen sowie den unterschiedenen Testarten, die aus dem konventionellen Bereich adaptiert werden können, vgl. Schmitz, Bons, Megen /Software-Qualitätssicherung/.
Für die Entwicklung konventioneller Systeme findet sich ein ähnlicher Ansatz bei Dearnley, Mayhew /System Prototypes/ 39 ff.
Breuker und Wielinga treffen dementsprechend eine Unterscheidung in einen Zyklus aus Orientierung, Problemidentifikation und Problemanalyse; vgl. Breuker, Wielinga /Use of Models/ 22 f.
Es wird noch einmal darauf hingewiesen, daß dem Phasenkonzept ein Wasserfallmodell zugrundeliegt, das ebenfalls Rückkoppelungen vorsieht, da diese in der Praxis nie vollständig auszuschließen sein werden; gerade durch den zielgesteuerten Einsatz von Prototyping zum Abbau von Unsicherheit wird die Notwendigkeit von Rücksprüngen jedoch minimiert.
Ferner ist davon auszugehen, daß während der Durchführung der Erhebung, z. B. im Verlauf eines Interviews, bereits eine erste Analyse und Modellierung des behandelten Wissens durch den Knowledge Engineer erfolgt.
Mit dem Begriff Abnahmetest wird die Überprüfung der Ergebnisse von Software-Projekten aus Sicht des Anwenders bezeichnet; vgl. Schmitz, Bons, Megen /Software-Qualitätssicherung/ 70.
Vgl. z. B. Harmon, King /Expertensysteme/ 229 f. und Waterman /Expert Systems/ 140
Vgl. hierzu z. B. Bachant, McDermott /R1 Revisited/ 25 ff.
Vgl. Schliep /Einführung von Expertensystemtechnik/ 60
Vgl. hierzu auch die Ausführungen über die zunehmende Standardisierung der Entwicklungswerkzeuge in Kapitel 2.3.1
Vgl. hierzu Jordan u. a. /Software Storming/ 47
Rights and permissions
Copyright information
© 1991 Springer Fachmedien Wiesbaden
About this chapter
Cite this chapter
Lenz, A. (1991). Vorgehensmodelle und Prinzipien der Entwicklung von Expertensystemen. In: Knowledge Engineering für betriebliche Expertensysteme. DUV: Datenverarbeitung. Deutscher Universitätsverlag, Wiesbaden. https://doi.org/10.1007/978-3-663-14606-3_3
Download citation
DOI: https://doi.org/10.1007/978-3-663-14606-3_3
Publisher Name: Deutscher Universitätsverlag, Wiesbaden
Print ISBN: 978-3-8244-2023-0
Online ISBN: 978-3-663-14606-3
eBook Packages: Springer Book Archive