Auszug
Es lässt sich konstatieren, dass die Entwicklung von Software hauptsächlich als ein Prozess angesehen werden muss, der stark von der Kreativität menschlicher Entwickler abhängt.541 Es werden hierzu Instrumente benötigt, die den Entwickler in diesem Prozess unterstützen, bspw. durch die Bereitstellung von Wissen über diesen Prozess.542 Ein Vorgehensmodell kann als ein solches Instrument des Wissensmanagements angesehen werden. Vorgehensmodelle sind eine spezielle Form von Referenzmodellen,543 denn Vorgehensmodelle enthalten Empfehlungen.544
Der Verfasser setzt hier voraus, dass Referenzmodelle einen normativen (empfehlenden) Charakter besitzen.
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. Steinmann (2000), S. 19 ff.; Baskerville, Pries-Heje (1999), S. 177.
Vgl. Kneuper (2000), S. 108.
Vgl. zum Begriff „Referenzmodell“ Rosemann, Schütte (1999), S. 23 f.; Scheer (1999), S. 4 ff. und Schütte (1998), S. 69 ff.
Der Verfasser setzt hier voraus, dass Referenzmodelle einen normativen (empfehlenden) Charakter besitzen.
Vgl. zu diesen Ausführungen auch Uschold, King (1995), S. 2.
Vgl. Sommerville (2001), S. 6 f.; Bullinger, Fähnrich (1997), S. 6.
Siche zu den Punkten der Nutzenstiftung S. 32.
Der Begriff „Schnittstellenmanagement“ bezicht sich hier auf den ungehemmten vollstàndigen Informationsfluss zwishen bspw, funktional getrennten Organisationseinheiten eines Unternehmens.
Zum Tailoring, d. h. der Anpassung des Ablaufs eines Vorgehensmodells an spezifische Projektsituationen, vgl. Fischer, Biskup et al. (1998), S. 28 ff.
Es làsst sich an dieser Stelle anmerken, dass sich sàmtliche Vorgehensmodelle in der Regel auf die vier groben Prozessphasen Analyse, Entwurf, Realisierung und Einführung zurückführen lassen oder auf Teilphasen hiervon.
Vgl. zum Begriff „Software-Life-Cycle“ Kapitel 5.1.2.1.1, S. 124, und Pomberger, Blaschek (1993), S. 18 f.
Die genannten Ansàtze finden weiteste Verbreitung in der Fachliteratur und wurden deshalb deshalb ausgewàhlt. Des Weiteren bauen die Ansàtze des Knowledge und des Ontology Engineering auf diesen Ansàtzen auf.
Puppe, Stoyan et al. (2003), S. 599. Diese „moderne“ Definition geht in ihrer Bedeutung weit über die in der Vergangenheit aufgestellten Definitionen hinaus. So wurde von Waterman 1986 das Knowledge Engineering als der Prozess der Erstellung eines Expertensystems bezeichnet (vgl. Waterman (1986), S. 5). Dem folgten umfassendere Definitionen hinsichtlich des Software-Life-Cycles, wie z. B. die von Haun im Jahr 2000, der den gesamten Entwicklungs-und Wartungsprozess eines Expertensystems als Knowledge Engineering definiert (vgl. Haun (2000), S. 188). Vermutlich kann diese Erweiterung damit erklärt werden, dass Erfahrungen mit der Entwicklung von Wissensbasierten Systemen zeigen, dass Wissen in allen Phasen des wissensbasierten Software-Life-Cycles ingenieurmäßig erfasst, verwaltet, verwendet und transformiert werden muss.
Vgl. Haun (200), S. 189.
Vgl. Sowa (2000), S. 452.
Eine Auswahl solcher Erhebungstechniken findet sich bspw. in Alan, Alparslan et al. (2003), insbesondere S. 18 ff.
Vgl. Angele, Fensel et al. (1998), S. 169 f.; Fernández López (1999), S. 4–1 ff.
Zu einer übersicht an Vorgehensmodellen zur Entwicklung Wissensbasierter Systeme vgl. Angele, Fensel et al. (1998), S. 170 ff.
Zu einer ausführlichen Begründung siehe Haun (2000), S. 146 ff.
Vgl. bspw. Puppe, Stoyan et al. (2003), S. 602 ff., und Haun (2000), S. 196.
Vgl. Holsapple, Joshi (2002), S. 43.
In dieser Arbeit werden einige konkrete Beispiele nàher erlàutert (siche hierzu das Ende dieses Kapitels). Hinweise zu ergànzenden Erlàuterungen finden sich bspw. in Fn. 150, S. 33.
Die Notwendigkeit von Vorgehensmodellen zur Entwicklung von Ontologien ist in der Literatur unstrittig. Siehe bspw. Stuckenschmidt, van Harmelen (2005), S. 246.
Vgl. Swartout, Patil et al. (1996). Dieser Ansatz vereinigt u. a. die Ontologien Penman Upper Model, ONTOS sowie WordNet, um aus einer breiten, allgemeinen SENSUS-Ontologie domänenspezifische Ontologien abzuleiten. Siehe hierzu auch Kapitel 5.1.2.3.2.1, S. 149.
Vgl. zum Beispiel Schreiber, Wielinga et al. (1995). Die Autoren von KACTUS, einem Vorgehensmodell, das im Rahmen eines ESPRIT-Projekts entwickelt wurde, gehen von einer bereits bestehenden Wissensbasis aus, aus der durch Abstraktion generelle Ontologien, die schließlich zu einer „Gesamtontologie“ vereinigt werden, entwickelt werden. Siehe hierzu auch Kapitel 5.1.2.3.2.2, S. 150.
Damit geht der Verfasser über die meisten Untersuchungen zu diesem Themengebiet hinaus. So untersuchen bspw. Pinto, Martins (2004) lediglich drei Ansätze (TOVE-Ansatz, Enterprise-Ansatz und METHONTOLOGY-Ansatz) als die „most representative methodologies“ (Pinto, Martins (2004), S. 445). Siehe zusätzlich auch Fn. 727, S. 182.
Die beiden beschbriebenen Vorgehensmodelle Enterprise-Model-Ansatz und TOVE-Ansatz wurden etwa zeitgleich veröffentlicht; hier wird jedoch der Enterprise-Model-Ansatz vorangestellt, weil er von diesen beiden den grundlegenderen Ansatz darstellt.
Vgl. dazu Pomberger, Blaschek (1993), S. 18ff.; Scacchi (2001), S. 5 ff. In dieser Arbeit wird der Begriff „Phasenmodell“ verwendet, wenn lediglich die (verkürzte) Darstellung der einzelnen Hauptschritte eines Vorgehensmodells angesprochen werden soll. Der Begriff „Vorgehensmodell“ bezieht sich hingegen immer auf den Gesamtkomplex der dahinter stehenden Methode, d.h. er umfasst bspw. auch Vorlagen.
In Anlehnung an Pomberger, Blaschek (1993), S. 18. Um eine Vergleichbarkeit der in diesem Kapitel vorgestellten Vorgehensmodelle zu gewährleisten, wird versucht, die Ansätze in eine einheitliche Modelldarstellung zu transferieren. Da der Fokus auf der Vergleichbarkeit liegt, wird auf eine genaue Transformation zu Gunsten der besseren Lesbarkeit verzichtet. Dies bringt mit sich, dass vorwiegend gestrichelte Kanten, die die Hauptflussrichtung von Informationen und die Reihenfolge der Phasen im zeitlichen Ablauf wiedergeben, verwendet werden, um den übergeordneten Bezug darzustellen. Des Weiteren werden einzelne Phasen (auch Hauptphasen, die mehrere Aktivitäten umfassen, und Einzelaktivitäten) durch abgerundete Kästchen dargestellt. Die Darstellung erfolgt gemäß den Quellen und soll jeweils lediglich der Orientierung dienen. Für eine genauere Darstellung (falls vorhanden) sei auf die betreffenden Quellen verwiesen, die jeweils angegeben werden.
Vgl. für die einzelnen Phasen Pomberger, Blaschek (1993), S. 18–20. Die einzelnen Phasen werden als Gruppierungen von Aktivitäten im vorliegenden Fall verstanden.
Vgl. Pomberger, Blaschek (1993), S. 41 f.
Ein Beispiel für ein derartiges Artefakt ist die Unified Modeling Language (UML). UML stellt semiformale sprachliche Ausdrucksmittel bereit, mit denen der Auftraggeber und der Auftragnehmer die Anforderungen an die zu entwicklnde Software eindeutig beschreiben können. Vgl. zu UML Kapitel 5.2, S. 162 ff.
An dieser Stelle wird die Architektur eines Systems als das Zusammenspiel einzelner Komponenten einer Software verstanden.
Die Verifikation untersucht, ob das entwickelte System den nicht-funktionalen Anforderungen entspricht und die Validation untersucht, ob das entwickelte System den funktionalen Anforderungen der Benutzer entspricht. Hierzu werden oftmals die verkürzenden Merksätze „building the system right“ und „building the right system“ für die Verifikation bzw. Validation in der Literatur angeführt (vgl. bspw. Boehm (1989), S. 205, und van Vliet (2000), S. 49).
Vgl. zum Wasserfall-Ansatz Royce (1970).
Vgl. Biethahn, Muksch et al. (2000), S. 206. Bei dieser Darstellung finden sich die Phasen des vorangehenden Software-Life-Cycle-Ansatzes in etwa auf folgende Weise wieder: System-und Software-Anforderungen entsprechen der Problemanalyse und Planung; Analyse entspricht der Systemspezifikation; Entwurf entspricht dem System-und Komponentenentwurf; Kodierung entspricht der Implementierung; Testen entspricht dem Komponenten-und Systemtest; Betrieb entspricht Betrieb und Wartung.
Vgl. Pomberger, Blaschek (1993), S. 24.
Streng genommen findet sich die Rückkopplung erst in jüngeren Varianten des Wasserfall-Ansatzes. In den ursprünglichen Versionen wurde eine Rückkopplung nicht vorgesehen (vgl. Böhm, Wenger (1996), S. 10). In diesem Sinne wäre es präziser, beim Wasserfall-Ansatz von einer Klasse von Vorgehensmodellen auszugehen; für den weiteren Argumentationsverlauf wird diese Unterscheidung außer Acht gelassen, weil sie nur von untergeordneter Relevanz ist.
Vgl. Pomberger, Blaschek (1993), S. 25; Wang (2002), S. 282. Dies ergibt eine zweiteilige Phasenaufteilung für den Prototyp-Ansatz: Prototyp-Spezifikation (Phasen Problemanalyse und Planung sowie Systemspezifikation) und Prototyp-Konstruktion/-Test (Phasen System-und Komponentenentwurf, Implementierung und Komponententest sowie Systemtest).
Bei einer diskreten Softwareentwicklung — wie etwa dem sequentiellen Software-Life-Cycle-Ansatz — wird ein zeitlich getrenntes Durchlaufen der einzelnen Phasen zur Bedingung.
Im Allgemeinen werden beim prototypbasierten Software-Life-Cycle-Ansatz (1) exploratives Prototyping, (2) experimentelles Prototyping und (3) evolutionäres Prototyping unterschieden. Das explorative Prototyping umfasst möglichst die vollständige Systemspezifikation anhand des Ziels (dem Einsatzzweck der Software). Hingegen wird beim experimentellen Prototyping eine vollständige Spezifikation von Teilsystemen (und damit Teilzielen) als Grundlage für die Implementierung angestrebt (vgl. dazu Sommerville (2001), S. 171 ff.). Beim evolutionären Prototyping wird eine initiale Implementierung vom Benutzer getestet und anschließend von den Entwicklern weiter verbessert. Es handelt sich somit um eine inkrementelle Systementwicklung (vgl. Pomberger, Blaschek (1993), S. 4).
Der Spiral-Ansatz geht auf Boehm zurück; vgl. Boehm (1988) und Sommerville (2001), S. 53 ff.
Vgl. Sommerville (2001), S. 53 f.
Vgl. Biethahn (2000), S. 210.
Vgl. Myerson (1996), S. 201 ff. Der Vereinfachung halber wird an dieser Stelle von Spiralen gesprochen. Präziser wäre es jedoch, von einzelnen Zyklen einer Spirale zu schreiben.
Deutlich wird hierbei der Zusammenhang zwischen dem Prototyp-Ansatz des Knowledge Engineering und dem Prototyp-Ansatz des Software Engineering: Beide versuchen möglichst früh ein lauffähiges Software-System zur weiteren Entwicklung zu erzeugen. Puppe, Stoyan und Studer bezeichnen ein solches Transfermodell als „naiv“ (vgl. Puppe, Stoyan et al. (2003), S. 603).
Vgl. Waterman (1986), S. 136.
Vgl. Haun (2000), S. 200 ff. Dieser Ansatz stammt ursprünglich von Waterman (1986), S. 136 ff. Die Vor-und Nachteile des Prototypings wurden bereits in ähnlicher Form im vorhergehenden Unterkapitel zum Software Engineering erläutert. Um auf die spezifischen Unterschiede aufmerksam zu machen, wird an dieser Stelle nochmals darauf eingegangen, auch wenn sich der Verfasser hiermit dem Vorwurf der „Redundanz“ aussetzt; die eingeschätzte Wichtigkeit der Ausarbeitungen rechtfertigt in den Augen desselben jedoch diese Vorgehensweise.
Der Wissensingenieur entwickelt das System,und das Wissen des Experten wird mittels Akquisitions-techniken im System hinterlegt.
Vgl. Puppe, Stoyan et al. (2003), S. 599 f.; Haun (2000), S. 204.
Der hier beschriebene Ablauf ergibt sich aufgrund der historischen Zusammenhänge aus der Erweiterung des Prototyp-Ansatzes (vgl. zur Phasenbeschreibung Haun (2000), S. 204 ff.).
Vgl. Haun (2000), S. 205 f.
Vgl. KBSI (1994), S. 25 ff.
Siehe hierzu auch http://www.idef.com, Zugriff am 18.03.2007.
KBSI (1994), S. 1.
Vgl. http://www.idef.com/idef5.html, Zugriff am 18.03.2007.
Der Ansatz leidet hier, wie auch an anderen Stellen, an begrifflichen Ungenauigkeiten. Die Autoren ge-hen hier davon aus, dass sich aus Daten Wissen für eine Ontologie ableiten làsst. Weil an dieser Stelle die Darstellung des ursprünglichen Ansatzes im Sinne der Autoren im Vordergrund steht, wird dieser Umstand so belassen.
Vgl. KBSI (1994), S. 58.
Die Elaboration Language nutzt KIF als Basis, um eine Wiederverwendung und Integration bestehender Ansätze zu ermöglichen (vgl. KBSI (1994), S. 6). Das Akronym KIF steht für Knowledge Interchange Format, vgl. für eine Darstellung von KIF Genesereth, Fikes (1992). KIF wurde entwickelt, um den Austausch von Wissen zwischen verschiedenartigen Computerprogrammen zu erleichtern.
Siehe Fn. 595, S. 136.
Vgl. Uschold, King (1995), Uschold (1996a), Uschold (1996b).
Vgl. Uschold, Grüninger (1996), S. 56. Für die Entwicklung eines „Enterprise Models“ werden unternehmensweite Daten-, Prozess-und Verhaltensmodelle zu einem konsistenten Modellsystem integriert, um eine Unternehmensrepräsentation zu bilden.
Die Phase der Evaluation bezieht sich gemàß Uschold und King vornehmlich auf die Validation einer Ontologie.
Vgl. Grüninger, Fox (1995), S. 1. Die Autoren berichten hierbei gar vom „Knowledge Engineering zweiter Generation“ im Hinblick auf das zu entwickelnde ontologiebasierte Unternehmensmodell. Für die Autoren gehören dabei Systeme, die lediglich die Regeln von Experten verarbeiten, zur ersten Generation des Knowledge Engineering.
Vgl. Grüninger, Fox (1995), S. 2 ff.
Grüninger und Fox spezifizieren Axiome in einer Ontologie als die Einschränkung von Möglichkeiten der Interpretation zuvor definierter Konzepte (vgl. Grüninger, Fox (1995), S. 11). Der Verfasser bezeichnet in dieser Arbeit einen solchen Sachverhalt als non-deduktive Inferenzregel. Somit sind die genannten „Axiome“ den Inferenzregeln in dieser Arbeit gleichzustellen. Um die originäre Aussage der Autoren nicht zu sehr zu verwässern, wird in diesem Kapitel weiterhin von „Axiomen“ die Rede sein, auch wenn streng genommen Inferenzregeln gemeint sind.
Zur Begründung führen Grüninger und Fox an: without the axioms we cannot express the question or its solution and with the axioms we can express the question and its solutions (Grüninger, Fox (1995), S. 11).
Abermals wàre es angebrachter, die englischsprachlichen Begriffe freier zu übersetzen. Der Begriff Completeness Theorem würde eigentlich passender hier mit Vollstàndigkeitssatz übersetzt werdendenn Theorem ist in diesem Zusammenhang ein veralteter Begriff, der neben dem Englischen lediglich bei seit langem bekannten Sàtzen im Deutschen noch gebràuchlich ist. Um jedoch nicht zu sehr von der originàren Quelle abzuweichen, wird der Begriff Vollstàndigkeitstheorem (nur)an dieser Stelleverwendet.
Vgl. für einen überblick zum METHONTOLOGY-Ansatz Fernández, Gómez-Pérez et al. (1997), S. 33 ff.
Vgl. IEEE 1074:1995.
Vgl. Gómez-Pérez, Fernández et al. (1996), S. 41.
Vgl. Fernández López, Gómez-Pérez et al. (1999), S. 37; Fernández López (1999), S. 4.1 f.
Fernández López, Gómez-Pérez et al. (1999), S. 37.
Vgl. Gómez-Pérez (2001), S. 9.
Fernández, Gómez-Pérez et al. unterscheiden abweichend zu dieser Arbeit Konzepte und Verben als Unterscheidungskriterien für Terme, die sämtliches „Wissen“ einer Domäne zusammenfassen. Verben repräsentieren dabei Aktionen innerhalb der betrachteten Domäne (vgl. Fernández, Gómez-Pérez et al. (1996), S. 38). Der Verfasser betrachtet hingegen auch Verben als Konzepte und vermeidet den Begriff „Term“ in Zusammenhang mit einer Konzeptualisierung (siehe hierzu auch Kapitel 2.1.2.4, S. 28 ff.).
Vgl. Schnurr, Sure et al. (2000), S. 24 ff. Vgl. ferner auch Sure (2002) und Lau, Sure (2002), S. 124 ff.
Vgl. Sure, Staab et al. (2004), S. 118.
Vgl. zu CommonKADS Schreiber (2001) und Kapitel 5.4.3.1, S. 187 ff.
Vgl. Staab (2002), S. 203 ff., und Sure, Staab et al. (2004), S. 120 ff.
Zu Anfang der Ontologieentwicklung soll schnell eine erste Vorstellung von der Ontologie gewonnen werden, um die Anforderungserfüllung frühzeitig justieren zu können und die einzubeziehenden Wissensquellen festzulegen (vgl. Staab (2002), S. 203 f.). Dieses Vorgehen zieht in der Regel eine zumeist unvollständige Ontologie nach sich, die schließlich weiter verfeinert werden muss.
Die Autoren schlagen hierzu Sprachen wie RDF oder DAML+OIL vor. Aktuelle Informationen zu den Sprachen RDF (Resource Description Framework) und DAML+OIL (DARPA Agent Markup Language + Ontology Inference Layer) sind zu finden unter http://www.w3.org/RDF/ bzw. http://www.w3.org/TR/daml/oil+oil-walkthru/ (Zugriffe am 18.03.2007) sowie in den Kapiteln 4.2.2.2.2. bzw. 4.2.2.2.3, S. 108.
Bei der Terminologie-Spezifikation nach Gröninger und Fox, S. 140, wird die Erstellung einer Taxonomie bei der Festlegung der Terme im Gegensatz zu der hier definierten Phase nicht vorrangig behandelt.
Vgl. Schnurr, Sure et al. (2000).
Vgl. Holsapple, Joshi (2002), S. 43.
Vgl. Holsapple, Joshi (2002), S. 44. Die fünf Klassen von Ansätzen können auch miteinander kombiniert werden.
Diese Klassen von Ansätzen können auch für die Klassifizierung der hier behandelten Vorgehensmo-delle zur Ontologieentwicklung verwendet werden.So baut der TOVE-Ansatz bspw.auf der Inspiration auf. Das Konzept der Kollaboration ist in den meisten Ansàtzen zu finden.Auf einer Synthese basieren-de Vorgehensmodelle werden in dieser Arbeit nicht betrachtet,weil die Neuentwicklung von Ontologien im Fokus der Untersuchung liegt.
Siehe zu einem kurzen Aufriss der Vor-und Nachteile Holsapple, Joshi (2002), S. 45.
Da sich außer zum Kollaborativen Ansatz zu den verschiedenen weiteren Klassen von Holsapple und Joshi bisher keine Anwendungen nachweisen lassen, wird im Folgenden lediglich der Kollaborative Ansatz nàher betrachtet. Dieser Umstand liegt wahrscheinlich im zarten Alter der Erkenntnisse von Holsapple und Joshi begründet, die bei den hier betrachteten Ausführungen den jüngsten Ansatz darstellen. Das Phasenmodell Kollaborativer Ansatz kann insofern für alle genannten Ansatzmöglichkeiten von Holsapple und Joshi gelten.
Vgl. Holsapple, Joshi (2002), S. 45.
Die genannten Kriterien wurden Holsapple, Joshi (2002), S. 45, entnommen (dort: comprehensiveness, correctness, conciseness, clarity und utility). Leider bleiben die Autoren eine Operationalisierung ihrer „Gütekriterien“ schuldig, so dass deren Angemessenheit durch Dritte nicht nachvollzogen werden kann.
Vgl. Holsapple, Joshi (2002), S. 45. Wie schon in der voranstehenden Fn. bemängelt, bleiben Holsapple und Joshi eine Präzisierung und Nachvollziehbarkeit ihrer Ausführungen schuldig. So lässt sich für den Leser nicht erschließen, ob alle Evaluationsstandards gleich erstrebenswert sind oder weshalb diese überhaupt erstrebenswert sind.
Vgl. Linstone, Turoff (1975). Die Delphi-Methode ist eine strukturierte Vorgehensweise für die Befragung von Experten und die Sammlung und die Integration der verschiedenen Sichten auf eine bestimmte Problemstellung.
Siehe hierzu Holsapple, Joshi (1999), S. 7 ff., und Holsapple, Singh (2003), S. 215 ff.
Vgl. Bouaud, Bachimont et al. (1994), Bouaud, Bachimont et al. (1995).
Vgl. Bouaud, Bachimont et al. (1994), S. 2. Zum Komplex der konzeptuellen Graphen siehe auch Kapitel 4.1.3.2.4, S. 83, und zur Einführung siehe Sowa (2000), S. 476 ff.
Vgl. Bouaud, bachimont et al. (1995), S. 5.
In dem hier verwendeten Sinn wird mit Typ ein gemeinsames Merkmal, das eine Klasse konstituiert, bezeichnet. Falls bspw.die Oberklasse „familie“ zum Typ „mensch“ gehört, dann muss die mögliche Unterklasse „kind“ ebenfalls zu diesem Typ gehören.
Vgl. Jones, Bench-Capon et al. (1998), S. 9. Diese Zweifel werden vom Verfasser geteilt.
Vgl. Sure (2003), S. 220.
KACTUS gilt als Nachfolgeprojekt zu CommonKADS, das ebenfalls durch Mittel der Europàischen Union ermöglicht wurde. Siehe hierzu auch Kapitel 5.4.3.1, S.187 f.
„Applikationsgetrieben“ bedeutet in diesem Fall grob vereinfacht, dass vorhandene Applikationen als Ausgangspunkt einer Ontologieentwicklung dienen. Dies entspricht einer Umkehrung der üblichen Vorgehensweise, in der eine ontologiebasierte Applikation entwickelt werden soll. Eine Applikation ist ein Computerprogramm, das einem bestimmten Zweck dient. Es wird synonym für den Begriff „Anwendungsprogramm“ verwendet, weil sich aus dem bedeutungsgleichen englischen Begriff „Application“ im allgemeinen deutschen Sprachgebrauch auch die Bezeichnung „Applikation“ als direkte Übersetzung durchgesetzt hat. Der Begriff „Anwendungsprogramm“ steht im Gegensatz zum Betriebssystem und allen System-und Hilfsprogrammen, wie etwa Werkzeugen zur Softwareerstellung, die lediglich den Betrieb einer Software ermöglichen, aber noch keinen darüber hinausgehenden Nutzen für den Benutzer bringen, der nicht selbst Entwickler ist.
Vgl. Schreiber, Wielinga et al. (1995), S. 1; van Heijst, Schreiber et al. (1997), S. 183 ff.
Verwendet man das Verstàndnis zur Existenz von leichtgewichtigen Ontologien, dann scheint es möglich, dieser Auffassung uneingeschrànkt zu folgen, weil sich je nach Betrachtungswinkel in jeder Anwendung Klassen bspw. von Funktionen finden lassen, die in einer Taxonomie dargestellt werden können. Auf weitere Ausführungen hierzu wird an dieser Stelle verzichtet, weil diese Ausführungen zu weit von der Problemstellung dieser Arbeit wegführen würden.
Vgl. Studer, Benjamins et al. (1998), S. 188, zum inkrementellen Vorgehen und Fernández López (1999), S. 4–7; Gómez-Pérez, Fernández-López et al. (2004), S. 124 f., zu den drei Schritten.
Vgl. Schreiber, Wielinga et al. (1995), S. 6.
Wenn bspw. eine Ontologie zur Domàne der Geldinstitute und eine Ontologie zur Domàne der Sitzgelegenheiten gemappt werden, so wird es höchstwahrscheinlich zu einer Doppelnennung des Konzepts „Bank“ kommen. In der vollstàndigen großen Ontologie erweitert sich die Semantik des Konzepts somit auf beide Bedeutungen aus den jeweiligen ursprünglichen Domànen oder es wird in einer Ontologie möglicherweise bei einer Neuinterpretation notwendig, eindeutige Konzepte, die jeweils nur einmal Verwendung finden, festzulegen und somit die alte Verwendungsweise abzuschaffen.
Diese Entscheidung wird bspw. auch durch Gómez-Pérez, Benjamins (1999) gestützt. Die Autoren zählen dort KACTUS nicht zu den Vorgehensmodellen für die Ontologieentwicklung (S. 1.4 f.), sondern zu Applikationen, die Ontologien verwenden (S. 1.6 f.).
Vgl. Swartout, Patil et al. (1996); Swartout, Patil et al. (1997).
Die von den Autoren vorgenommene Unterscheidung wird im Sinne einer Arbeitshypothese von diesen verwendet, denn es erfolgt keine ausreichende Definition hinsichtlich der Eindeutigkeit der Zuordbarkeit. Die Autoren erwähnen lediglich, dass Theorie-Ontologien zu einer höheren Abstraktion tendieren als Domänen-Ontologien (vgl. Swartout, Patil et al. (1997), S. 139). Aus der abstrakteren Sichtweise ergibt sich möglicherweise auch der Grund für die eigenwillige Bezeichnung “Theorie-Ontologien”, die an dieser Stelle eher irreführend wirkt und möglicherweise mit “Common-Sense-Ontologien” oder „Meta-Ontologien“ gelungener erfolgt wäre.
Vgl. Swartout, Patil et al. (1997), S. 138.
Vgl. Knight, Luk (1994), S. 773 ff. Vgl. zum Penman Upper Model Bateman, Kasper et al. (1989) und Bateman, Magnini et al. (1994). Vgl. zu ONTOS Carlson, Nirenburg (1990). Vgl. zu WordNet Fn. 516.
Vgl. Gangemi, Pisanelli et al. (1998), S. 163. Vgl. Ferner Gangemi, Steve et al. (1996).
Vgl. Gómez-Pérez, Fernández-López et al. (2004), S. 164.
Vgl. Gangemi, Pisanelli et al. (1998), S. 163.
An dieser Stelle wird deutlich, dass die Autoren eine abweichende Definition von Ontologien verwenden. In der Arbeitsdefinition dieser Arbeit liegt erst nach der Formalisierung eine Ontologie vor.
Vgl. Jones, Bench-Capon et al (1998), S. 9.
Vgl. Guarino, Welty (2002) und Guarino, Welty (2004).
Vgl. Guarino, Welty (2002), S. 61 und S. 63.
Vgl. Guarino, Welty (2002), S. 61 ff. Ins Deutsche lassen sich die Eigenschaften in „Rigidität“, „Identität“ und „Vollständigkeit“ übersetzen. Eine Eigenschaft eines Konzepts gilt als rigide, wenn sie als essentiell für alle Instanzen des Konzepts angesehen wird (bspw. müssen für die Eigenschaft „menschlich zu sein“ alle Instanzen notwendig menschlich sein). „Identität“ beschäftigt sich mit der Möglichkeit, Konzepte einer Welt als gleich (oder unterschiedlich) zu erkennen und „Vollständigkeit“ beschäftigt sich mit der Möglichkeit, alle Konzepte einer Welt zu identifizieren, die ein bestimmtes (Ober-)Konzept vollständig konstituieren.
Den gesamten Ansatz an dieser Stelle wiederzugeben wird vom Verfasser als nicht zielführend für diese Arbeit erachtet. In Guarino, Welty (2004) findet sich ein anschauliches Beispiel ab S. 157 zur Anwendung von OntoClean.
Vgl. Scheer (1997), S. 7; Lang (1997) S. 21 ff.; Reiter (1999), S. 46 ff.
Vgl. Reiter (1997), S. 34.
Vgl. http://www.ids-scheer.de/germany/31626,Zugriff am 18.03.2007.
Vgl. Scheer (1997), S. 9.
Zur Formalisierung von Vorgehensmodellen siehe Verlage (1998a), S. 61 ff.
Verlage nennt bspw. Appl/A (Ada Process Programming Language with Aspen), MSL (Marvel Strategy Language), MVP-L (Multi View Process Modeling Language), SLANG (Spade Language), Statemate und Tempo (vgl. Verlage (1998b), S. 82 ff.).
Vgl. Verlage (1998b), S. 76 ff., und bedingt auch Schütte (1998), S. 92 ff. Letzterer formuliert eine Sprachauswahl für die Beschreibung von Informationssystemen, die ausgewählten Sprachen können jedoch auch für die Zwecke der Beschreibung von Vorgehensmodellen genutzt werden.
Für (erweiterte) Ereignisgesteuerte Prozessketten (EPKn) ist die Gliederung eines Prozesses in Ereignisse und Funktionen typisch. Eine Funktion entspricht dabei einer (betriebswirtschaftlichen) Aktivität an einem oder mehreren Objekten (bspw. Datenbank, Kundendaten, Organisationseinheit). Ereignisse lösen Funktionen aus und durchgeführte Funktionen erzeugen wiederum Ereignisse. Jeder Prozess beinhaltet mindestens ein Startereignis und ein Endereignis. Funktionen werden mit einem Substantiv (oftmals für das bearbeitete Objekt) und einem die Aktivität charakterisierenden Verb benannt. Ereignisse werden demgegenüber mit einem Substantiv (oftmals für das bearbeitete Objekt) und einem Verb zur Formulierung des Zustands benannt. Es können nur Funktionen und Ereignisse abwechselnd miteinander verbunden werden. Neben direkten Verbindungen kommen auch Konnektoren zum Einsatz. Hauptsächlich lassen sich drei Arten von Konnektoren unterscheiden. Diese können auch kombiniert angewendet werden. Es werden Konnektoren verwendet, die „konjunkt“, „adjunkt“ und „disjunkt“ wirken, das heißt sie wirken als „und“, „inklusives oder“ und als „exklusives oder“. Verschiedene Prozesse (eEPKs) können mit Prozesswegweisern, die in etwa wie Platzhalter wirken, verbunden werden. Zwangsläufig entsprechen dann die Endereignisse des vorlaufenden Prozesses den Anfangsereignissen des nachfolgenden (verwiesenen) Prozesses, dies entspricht einer vertikalen Dekomposition eines Gesamtprozesses (Hierarchisierung zueinander in Verbindung stehender Teilprozesse). Des Weiteren gibt es die horizontale Segmentierung, die miteinander über Prozessschnittstellen verbundene, einzelne Prozessmodelle nebeneinander darstellt. Petri-Netze (PN) sind benannt nach C. A. Petri, der sie 1962 in seiner Dissertation als Modelle für nebenläufige (es besteht die Möglichkeit des parallelen Verlaufs, beliebiger Reihenfolgen und „Verschachtelungen“) Prozesse eingeführt hat. Ein abgebildetes System wird insbesondere durch seine passiven Elemente (Stellen) und seine aktiven Elemente (Transitionen), die in einem kausal-logischem Zusammenhang stehen, gekennzeichnet. In der Wissenschaft sind verschiedene Varianten von Petri-Netzen bekannt, wie Stelle/Transition-Netze, farbige Petri-Netze, hierarchische Petri-Netze, Bedingungs/Ereignisnetze, stochastische und zeitbehaftete Petri-Netze, (erweiterte) Prädikate/Transitions-Netze und Kanal/Instanzen-Netze. Petri-Netze eignen sich insbesondere zur Repräsentation von Wissen, bei dem diskrete Ereignisse auftreten, die von diskreten Objekten verbraucht oder erzeugt werden. Vgl. zu eEPK Seidlmeier (2002), S. 70 ff., und zu Petri-Netzen Baumgarten (1990); Zelewski (1995), S. 25 ff.
Vgl. Ferstl, Sinz (1993), S. 589 ff., und Ferstl, Sinz (1994).
Vgl. OMG (2003) und Rumbaugh, Jacobson et al. (2005). Für eine Verwendung der UML als Repräsentationssprache für Ontologien siehe Guizzardi, Wagner et al. (2004). Stuckenschmidt und van Harmelen gehen in ihren Äußerungen sogar so weit zu behaupten, dass die UML selbst eine Ontologie darstellt (vgl. Stuckenschmidt, van Harmelen (2005), S. 29). Dieser Auffassung schließt sich der Verfasser jedoch nicht an, weil bspw. das UML-Metamodell eine Verwendung des Konzepts „property“ gemäß DAML nicht erlaubt. Erst nach einer Anpassung, wie etwa in Baclawski, Kokar et al. (2002), S. 151 ff., vorgeschlagen, wird es möglich, Ontologien mittels UML darzustellen.
Anforderungen an die Modellierungssprache stellen sich für die wirtschaftswissenschaftliche Problemstellung in Form der Gütekriterien des Kapitels 5.3.3.2, S. 170 ff.
Puri verwendet ebenfalls die UML, um seine semantische Funktionsmodellierung darzustellen (vgl. Puri (2003), S. 82). Er hebt dabei hervor, dass die UML ermöglicht, Entwurf und Entwicklung sowohl von Softwaremodellen als auch von Nicht-Softwaremodellen auf einer gemeinsamen Basis zu diskutieren (ebenfalls S. 82). Leutsch verwendet die UML, um seine prozedurale Wissensunterstützung eines Konstruktionsprozesses in einem Datenmodell darzulegen (vgl. Leutsch (2002), S. 119 ff.). Noack stellt einen Ansatz vor, der in einem durchgängigen Entwicklungsprozess ein Vorgehensmodell vorsieht, das anfänglich als EPK vorliegende Geschäftprozessmodelle in die UML-Notation überführt, weil diese als objekt-orientierte und damit aktuelle Softwareentwicklung für gebotener gehalten wird (vgl. Noack (2000), S. 6 und S. 12 f.).
Siehe S. 243.
Dieser Standpunkt führt zum selben Ergebnis wie die Meinung von Verlage, der die Suche nach einer für sämtliche denkbaren Anwendungsfälle „optimalen“ Modellierungssprache als nicht sinnvoll erklärt, weil etwaige Anforderungen zu unterschiedlich ausfallen (vgl. Verlage (1998b), S. 79).
Vgl. Rumbaugh, Jacobson et al. (2005), S. 6; Borrmann, Komnik et al. (2002), S. 31; Leutsch (2002), S. 175.
Vgl. Eriksson, Penker (2000), S. XV f.
Es handelt sich hierbei um die Software MS Visio 2003 der Microsoft Deutschland GmbH (vgl. http://office.microsoft.com/de-de/FX010857981031.aspx, Zugriff am 15.08.2005).
Vgl. Burkhardt (1997), S. 1 ff.
Vgl. Burkhardt (1997), S. 1 ff.
Vgl. OMG (2003).
Vgl. Booch, Rumbaugh et al. (1999), S. 17.
Vgl. Booch, Rumbaugh et al. (1999), S. 16.
Zu einer Genealogie von Vorgehensmodellen siehe Bremer (1998), insbesondere S. 31.
Eine Marktübersicht zu Modellierungswerkzeugen würde bei weitem den Rahmen dieser Arbeit sprengen, ohne einen substantiellen Beitrag zur Problemstellung der Arbeit leisten zu können. Dem Verfasser stand als proprietàres Werkzeug MS Visio der Microsoft Deutschland GmbH zur Verfügung. Dieses wurde dann auch zur Modellierung eingesetzt.
Vgl. zur Web-Anwenung des KOWIEN-Vorgehensmodells Apke, Dittmann (2004), S. 99 ff. Für weitere Informationen zum Forschungsverbundprojekt KOWIEN (Kooperatives Wissensmanagement in Engineering-Netzwerken) siehe http://www.kowien.uni-essen.de, Zugriff am 4.3.2007, und Zelewski, Alan et al. (2005).
So zum Beispiel bei Ruth (2000), S. 146 und Dimitrov, Schmietendorf et al. (2000), S. 61 ff.
Vgl. Apke, Dittmann (2004), S. 102.
Aus dem Englischen „Activity Diagrams“ übersetzt. Zu Aktivitätsdiagrammen siehe Eriksson, Penker (2000), S. 40 ff.; Fowler (2004), S. 117 ff.; Kahlbrandt (2001), S. 178 ff., und die offizielle Spezifikation OMG (2003), S. 3–155 ff. Für eine genaue Erläuterung sämtlicher Diagrammtypen sei auf die weiterführende Literatur Fowler (2004), Booch, Rumbaugh et al. (1999), Burkhardt (1997) und Oesterreich (2002) neben der offiziellen Spezifikation (OMG (2003)) verwiesen. Auch auf die Veränderung der Diagrammtypen und ihrer Einteilung bei der Umstellung der derzeit gültigen Version 1.5 der UML auf die Version 2.0 sei an dieser Stelle hingewiesen (siehe hierzu für UML 1.5 OMG (2003), S. 2-6 ff., und für UML 2.0 Fowler (2004), S. 12).
Fowler (2004), S. 117. In dieser Arbeit werden im Wesentlichen die grafischen Elemente der Version 1.5 (Aktion, Transition, Objekt, Kontrollfluss, Objektfluss, Verzweigung, Aufspaltung, Vereinigung, Synchronisation, Start-und Endzustand) verwendet; zum einen, weil sie intuitiv verständlicher erscheinen als die grafischen Elemente der Version 2.0, und zum anderen, weil diese — zum Zeitpunkt der Erstellung dieser Arbeit — von der eingesetzten Modellierungssoftware lediglich unterstützt wurden. Drittens wurde die Version 2.0 noch nicht offiziell verabschiedet. Jedoch lassen sich bereits mit der demnächst gültigen Version 2.0 einige Kritikpunkte an der „alten“ UML vermeiden. Bspw. brachte es die Weiterentwicklung der Aktivitätsdiagramme mit sich, dass diese nicht länger als eine Sonderform von Zustandsdiagrammen angesehen, sondern als eigenständiges Verhaltensdiagramm in das Meta-Modell der UML eingeordnet werden. Insgesamt wurde versucht, die Aktivitätsdiagramme zu einer „Petri-Netz-ähnlichen“ Modellierung zu entwickeln (vgl. Rumbaugh, Jacobson et al. (2005), S. 150 und S. 520, sowie Fowler (2004), S. 130 und S. 159). Deshalb wird eine Aktion nicht länger als ein (Aktions-)Zustand (activity state) mit einer internen Aktion angesehen (vgl. OMG (2003), S. 3–158), sondern vielmehr als ein (Aktivitäts-) Knoten (activity node), der eine Zustandsveränderung bewirkt oder einen Wert zurückliefert (vgl. Rumbaugh, Jacobson et al. (2005), S. 136). Die hier im Folgenden vorgestellten Modellierungsprimitive verwenden den Zeichenvorrat und die Syntax der Version 1.5 und teilweise die Semantik der Version 2.0 (das Geschriebene gilt insbesondere für Objekte und Kanten).
In den vorherigen Versionen der UML (kleiner Version 2.0) wurden die Verbindungen zwischen den Aktionen als Transitionen bezeichnet. Dies resultiert aus der Tradition, ein Aktivitätsdiagramm als Sonderform eines Zustandsdiagramms aufzufassen. Transitionen wurden dort dann auch als Zustandsübergänge (ohne Auslöser) bezeichnet (vgl. Booch, Rumbaugh et al. (1999), S. 297). In der Version 2.0 werden Transitionen nur noch für Automaten (state machines) berücksichtigt (vgl. Rumbaugh, Jacobson et al. (2005), S. 657). Die Begriffe Fluss und Kante werden sowohl in der UML-Spezifikation als auch hier synonym verwendet (vgl. Fowler (2004), S. 124).
Vgl. Oesterreich (2002), S. 91.
Um das implizite Wissen nicht unnötig zu erhöhen und die Nachvollziehbarkeit zu erleichtern, wird im OntoFMEA-Vorgehensmodell hierauf verzichtet, d. h. alle Kanten werden explizit dargestellt.
Vgl. Biethahn, Muksch et al. (2000), S. 202.
Abgesehen von der ersten Phase System-Anforderungen, für die mangels Objekt keine Rückkopplung vorgesehen wurde.
In Anlehnung an Haun (2000), S. 197.
Um die Sonderstellung des expliziten Modells, d.h. der Phase der Modellierung innerhalb des Modellbasierten Ansatzes, hervorzuheben, wurde dieser Teil des Vorgehens in der Abbildung 37 mit einer gestrichelten Umrandung hervorgehoben.
Siehe hierzu auch die Ausführungen in Kapitel 2.1.2.5, S. 31 ff.
Insofern sollte an dieser Stelle die bisherige Argumentationsführung deutlich werden: Um das avisierte Vorgehensmodell zu entwickeln, werden nacheinander die Zusammenhànge a maximis ad minima dargelegt, der Weg führt nàmlich vom Software Engineering über das Knowledge Engineering zum Ontology Engineering. Weil insbesondere die Vorgehensmodelle des Ontology Engineering für die Eigenentwicklung von großer Bedeutung sind, werden diese einer genaueren Analyse unterzogen, um die jeweiligen Vor-und Nachteile herauszuarbeiten.
Vgl. Verlage (1998a), S.73, und Moody, Shanks (1994), S. 101 f.
Hierüber làsst sich jedoch vortrefflich streiten, weil auch der Standpunkt vertreten werden kann, dass einem geübten Anwender eine formalsprachliche Beschreibung gerade die Nachvollziehbarkeit erleichtert. Ein weiterer Zielkonflikt làsst sich zwischen den Anforderungen nach allgemeiner Gültigkeit und Vollstàndigkeit eines Vorgehensmodells möglicherweise ausmachen. Dabei wird unterstellt, dass eine allgemeine Gültigkeit sich oftmals nur unter Verzicht einer vollstàndigen Darstellung aller möglichen Aspekte eines Vorgehens erreichen làsst. Je detaillierter spezifische Aspekte eines bestimmten Vorgehens dargelegt werden, desto weniger Allgemeingültigkeit làsst sich im Allgemeinen für eine solche Darlegung reklamieren.
Vgl. Guarino, welty (2002), S. 61.
Auch spezifische Vorgehensmodelle können wiederverwendet werden, wenn die entsprechenden Rahmenbedingungen erfüllt sind. Nur wird die Wahrscheinlichkeit der Wiederverwendung deutlich geringer eingeschàtzt, nicht zuletzt, weil diese Wiederverwendung ursprünglich auch nicht beabsichtigt war.
Vgl. Fernández López (1999), S. 4.3.
Als Anwendungsziele des Vorgehensmodells werden die konkretisierten Mittel, die der Benutzer des Vorgehensmodells im Vorhinein festlegt und die zur erfolgreichen Ontologieentwicklung und zur Implementierung der Ontologien in ein lauffàhiges System dienen, bezeichnet.
Vgl. z. B. Schütte (1997), S. 7. Dort wird ein Modell als vollständig angesehen, wenn es alle im Meta-Modell beschriebenen Beziehungen zwischen den Objekten in der gleichen Form einhält. Moody und Shanks (1994), S. 102, betrachten ein (Daten-) Modell als vollständig, sobald es die Fähigkeit besitzt, alle funktionalen Anforderungen der Benutzer umzusetzen. Diese Definitionen von Vollständigkeit richten sich also ebenfalls nicht nach einem allgemeingültigen Referenzmodell, sondern sind abhängig von dem vorgegebenen Meta-Modell oder von den Benutzern des Modells.
Aus diesem Grund wird das Kriterium der Vollstàndigkeit an dieser Stelle zwar aufgeführt und erlàutert, jedoch nicht zur Beurteilung der dargestellten Ansàtze eingesetzt. Zwar wàre, wie bereits erwàhnt, eine Bewertung der Vollstàndigkeit aus Sicht der Anwender des Vorgehensmodells (also der Ontologieentwickler) möglich (bspw. mittels einer Referenzanwendung). Die Arbeiten hierzu würden aufgrund ihres Umfangs jedoch zu weit vom Fokus dieser Arbeit abrücken. Darüber hinaus versprechen die zu erwartenden Ergebnisse keinen weiteren nicht-trivialen Mehrwert für den Argumentationsverlauf dieser Arbeit.
Siehe Kapitel 5.3.3.3.3, S. 177.
Als Design Rationale wird hier die Zusammenfassung von Merkmalen einer Gestaltungsentscheidung und deren Begründungen verstanden. Vgl. zum Begriff „Design Rationale“ Moran, Carrol (1996), S. 1 ff.
Eine ähnliche Erläuterung geben Moody, Shanks (1994), S. 102. Für die Messung der Komplexität eines Datenmodells schlagen sie vor, die Anzahl der Entitäten und die Menge der Beziehungen im jeweiligen Datenmodell zu addieren. Für Vorgehensmodelle könnten die Anzahl der Phasen und der Detailgrad der Phasenbeschreibungen sowie zusätzlich die Anzahl von Rückkopplungen, von Verzweigungen und von parallel ausführbaren Schritten als Maßstäbe für die Simplizität herangezogen werden.
Die geforderte Einfachheit bezieht sich somit vornehmlich auf die Reduktion der Komplexitàt eines Modells, bspw. sollte die Nebenlàufigkeit nur dann, wenn es unbedingt notwendig erscheint, in einem Modell berücksichtigt werden. Die Nebenlàufigkeit birgt in der Anwendung die Gefahr, dass Zustàndigkeiten und Termine abgewàlzt bzw. verschoben werden, weil davon ausgegangen wird, dass jeweils der andere „Strang“ zustàndig bzw. verantwortlich für die Terminhaltung ist. Eine effiziente Anwendung des Vorgehensmodells wird erreicht, wenn alle Benutzer das Vorgehensmodell akzeptieren und so anwenden, dass möglichst Ressourcen schonend die angestrebten Ergebnisse erreicht werden. Vermeiden von Nebenlàufigkeit und effiziente Anwendung sind somit Bestandteile des Kriteriums „Einfachheit“.
Schütte (1997), S. 10.
Ein besonders hoher Grad an Formalität geht allerdings oft zu Lasten der Nachvollziehbarkeit eines Vorgehensmodells. An dieser Stelle kann die Kombination informaler Ausführungen mit (semi-) formalen Beschreibungen wie Modellen dazu beitragen, dass gleichzeitig die Simplizität und Nachvollziehbarkeit sowie die Klarheit eines Vorgehensmodells gewährleistet sind. Bspw. wäre eine (semi-) formale Vorgehensmodellierung mittels Ereignisgesteuerter Prozessketten (EPK) möglich. Zum Begriff der Ereignisgesteuerten Prozessketten vgl. Scheer (1999). Für eine weitere alternative Darstellungsform siehe Kapitel 5.2, S. 162 ff.
Aus diesem Grund werden auch Anwendungen für das Semantic Web nur mittelbar ermöglicht.
Vgl. Uschold, King (1995), S. 2. Dieses Modell bildet jedoch nur ein Grundgerüst und sollte nach Aussage der Autoren durch entsprechende Erweiterungen sowie durch die Festlegung von Methoden an konkrete Projekte angepasst werden.
Vgl. Uschold, King (1995), S. 4 ff.
Vgl. Fernández López (1999), S. 4.9.
So werden bspw. für die Erhebung der Anforderungen die Erstellung eines Anforderungsspezifikationsdokuments (aus dem Bereich des Software Engineering) sowie zusätzlich die Formulierung von Kompetenzfragen (ein eher ontologieentwicklungsspezifisches Konzept) empfohlen und beide Dokumente auch später als Referenzrahmen bei der Evaluation herangezogen. Vgl. hierzu Sure, Staab et al. (2004), S. 120 f., und Staab (2002), S. 203 f.
Vgl. Fernández López (1999), S. 4.9.
Vgl. bspw. Lau, Sure (2002), S. 125, für die Zuordnung zur “Kickoff”-Phase und Maedche, Staab et al. (2003), S. 326 f., für die Zuordnung zur Phase der „Verfeinerung“.
Ontolingua ist eine Software-Umgebung zur Konstruktion von Ontologien durch verteilt arbeitende Gruppen, die neben einer Bibliothek bestehender Ontologien auch einen Editor für die Generierung und Bearbeitung von Ontologien bereitstellt und diese in verschiedene Sprachen übersetzen kann; vgl. dazu Gruber (1993), S. 203 ff., und Farquhar, Fikes et al. (1996), S. 44.3 ff., sowie Kapitel 4.2.2.1.2, S. 105 f.
Vgl. Fernández, Gómez-Pérez et al. (1997), S. 39.
Vgl. zu WebODE Arpírez, Corcho et al. (2001).
Vgl. Sure, Studer (2002), S. 17 ff.
Legende: (-) entspricht negativ, (o) entspricht durchschnittlich, (+) entspricht positiv. Die scheinbare Doppelbewertung soll den Zwischenfall darstellen. Es ergeben sich somit 5 mögliche ordinale Merkmalsauspràgungen.
Vgl. Apke, Dittmann (2003a), insbesondere S. 59. Dabei wird jedoch bspw. der IDEF5-Ansatz nicht berücksichtigt.
Im Ergebnis siehe hierzu auch Apke, Dittmann (2003b) und Apke, Dittmann (2004).
Vgl. Fernández Lopéz (1999). Die Untersuchung vergleicht Enterprise-Model-Ansatz, TOVE-Ansatz, METHONTOLOGY-Ansatz, KACTUS und SENSUS. Der Verfasser folgt hier nicht der Auffassung von Fernández López, dass es sich bei SENSUS um ein allgemeines Vorgehensmodell zur Erstellung von Ontologien handelt. Vielmehr handelt es sich um eine Anwendung, aus der auch Ontologien entwickelt werden können. Weil SENSUS jedoch auf eine bestehende Ontologie aufsetzt (genau genommen stellt diese Ontologie die Anwendung im engeren Sinne dar), sieht der Verfasser den Einfluss der Ursprungs-Ontologie als zu hoch an, um noch sagen zu können, dass es sich um die Erstellung „neuer“ Ontologien handelt (siehe hierzu auch Kapitel 5.1.2.3.2.1, S. 149 ff.). Ähnliches gilt für die Betrachtung von KACTUS (siehe hierzu auch Kapitel 5.1.2.3.2.2, S. 150 f.).
Zur Auswahl und zu den der Auswahl zu Grunde liegenden Kriterien der generischen Vorgehensmodelle des Software Engineering, des Knowledge Engineering und des Ontology Engineering siehe Kapitel 5.1.1, S. 120 ff.
Siehe hierzu die Ausführungen im folgenden Kapitel.
Siehe hierzu die Ausführungen in Kapitel 5.3.1, S. 165 ff.
Der sequentielle Software-Life-Cycle-Ansatz wird nicht weiter betrachtet, weil der Wasserfall-Ansatz den „elaborierteren“ von beiden Ansàtzen darstellt.
Vgl. hierzu Kapitel 5.3.3.1, S. 169. Die spezielle Konkretisierung „V-Modell“ ist in etwa vergleichbar mit der Darstellung des OntoFMEA-Vorgehensmodells, auf das hier vorgreifend verwiesen wird (vgl. zum OntoFMEA-Vorgehensmodell insbesondere Kapitel 6, S. 193 ff.).
Siehe hierzu den Kapitelverweis in der voranstehenden Fn. Zusàtzlich siehe auch Kapitel 5.3.2, S. 168 ff.
Zu diesem Vorgehensmodell siehe Schreiber; Wielinga et al. (1994) und Schreiber, Akkermans et al. (2001).
Sofern sich in einer jungen Disziplin wie dem Knowledge Engineering und den mit der Jugendhaftigkeit verbundenen Entwicklungssprüngen überhaupt von einem Standard ausgehen làsst, so wird dieser eingeschrànkt als „quasi“ bezeichnet.
Vgl. bspw. Zelewski (2005), S. 177 f.
Dem Verfasser ist kein weiteres derartiges „weniger generisches“ Vorgehensmodell im Bereich des Ontology Engineering bekannt.
Vgl. Bröhl, Dröschel (1995), S. 15.
Vgl. V-Modell (1997), S. 4-1.
Das V-Modell zum Download findet sich unter: http://www.informatik.uni-bremen.de/gdpa/, Zugriff am 16.3.2007. Die Abbildung wurde V-Modell (1997), S. 2.9, entnommen.
Vgl. http://www.informatik.uni-bremen.de/uniform/gdpa/def/def_v/V_MODEL.htm, Zugriff am 16.03.2007.
Vgl. bspw. V-Modell (1997), S. 4.3 ff., für das Submodell Systemerstellung.
Zu diesem Vorgehensmodell vgl. Schreiber, Akkermans et al. (2001).
Der Bereich des Ontology Engineering findet in diesem Zusammenhang innerhalb des Wissens-Modells (Knowledge Model) seine Berücksichtigung. Schreiber, Akkermans et al. verwenden den Begriff „Ontologien“ jedoch abweichend zu dem hier gebrauchten Verständnis. Vielmehr sprechen sie von „domain schemas“ (vgl. hierzu insbesondere Schreiber, Akkermans et al. (2001), S. 91). Ontologien stellen für die Autoren in diesem Zusammenhang „generalized domain schemas“ dar (vgl. Schreiber, Akkermans et al. (2001), S. 331). Die Autoren bleiben jedoch eine Antwort schuldig, worin ihr Unterschied zwischen generalisierten und nicht generalisierten Domänenschemata liegt.
Die beschriebenen Zusammenhànge zwischen den Modellen der Kontext-Ebene finden sich nicht in der Abbildung wieder. Um die Übersichtlichkeit zu wahren, wurde die Abbildung gemàß ihrer Quelle (siehe hierzu die folgende Fn.) dargestellt, d. h. es werden nur die Beziehungen (Kanten) zwischen der Kontext-, Konzept-und Artefakte-Ebene dargestellt.
Vgl. Schreiber (2001), S. 18 f.
Vgl. Angele, Fensel et al. (1993).
Siehe Kapitel 5.1.2.1.4, S. 129.
Vgl. Pierlein (1995), S. 165.
Vgl. Angele, Fensel et al. (1993), S. 6 ff., und Angele, Fensel et al. (1995), S. 17 ff.
Vgl. Angele, Fensel et al. (1995), S. 19, und Pierlein (1995), S. 168.
Vgl. Pierlein (1995), S. 173.
KARL basiert auf F-Logic und damit auch auf Prädikatenlogik (vgl. Angele, Fensel et al. (1995), S. 19 bzw. S. 17). Weitere Informationen zu KARL finden sich in Fensel (1995) und in Fensel, angele et al. (1998).
Vgl. Angele, Fensel et al. (1995), S. 20.
Vgl. Angele, Fensel et al. (1995), S. 20.
Vgl. Angele, Fensel et al. (1995), S. 20.
Vgl. Zelewski, Alan et al. (2005).
Siehe hierzu auch Abbildung 43, S. 199.
Entsprechend den üblichen Definitionen von Ontologien (siehe Kapitel 2.1.2.4, S. 28 ff.) ist eine Dominanz der taxonomischen Strukturierung keineswegs zwingend. Es zeigt sich jedoch, dass es aus Gründen der leichteren Nachvollziehbarkeit durch Benutzer aus der betrieblichen Praxis sinnvoll ist, mit einer taxonomischen Strukturierung zu beginnen, wenn das Vorgehensmodell in der Praxis auf Akzeptanz stoßen soll.
Hierfür wurden bereits Standards, wie etwa der IEEE-Standard 1074:1995, verfasst und auch akzeptiert. Der IEEE-Standard 1074:1995 (vgl. IEEE 1074:1995) beschreibt einen „typischen“ Softwareentwicklungsprozess mit den dabei durchzuführenden Aktivitàten und möglichen einsetzbaren Methoden (vgl. auch Fernández López (1999), S. 4.2). Der Entwicklungsprozess wird gemàß IEEE-Standard unterteilt in Unterprozesse des Softwarelebenszyklusmodells, des Projektmanagements sowie in softwareentwicklungsorientierte und integrale Prozesse.
Rights and permissions
Copyright information
© 2007 Deutscher Universitäts-Verlag | GWV Fachverlage GmbH, Wiesbaden
About this chapter
Cite this chapter
(2007). Vorgehensmodelle. In: OntoFMEA. DUV. https://doi.org/10.1007/978-3-8350-9572-4_5
Download citation
DOI: https://doi.org/10.1007/978-3-8350-9572-4_5
Publisher Name: DUV
Print ISBN: 978-3-8350-0749-9
Online ISBN: 978-3-8350-9572-4
eBook Packages: Business and Economics (German Language)