Tolerierbare Inkonsistenzen in Konzeptbeschreibungen fileTolerierbare Inkonsistenzen in...

Hasso–Plattner–Institut für Softwaresystemtechnikan der Universität Potsdam

Tolerierbare Inkonsistenzen

in

Konzeptbeschreibungen

Dissertation

zur Erlangung des akademischen GradesDoktor der Ingenieurwissenschaften

(Dr.–Ing.)in dem Fachgebiet Software–Engineering

eingereicht an derMathematisch–Naturwissenschaftlichen Fakultät

der Universität Potsdam

vonDipl.–Ing. Rémy Apfelbacher

Potsdam, den 21. Oktober 2007

Erster Gutachter (Betreuer): Prof. Dr.-Ing. Siegfried Wendt

Zweiter Gutachter: Prof. Dr. Heiner Müller-Merbach

Dritter Gutachter: Prof. Dr. Wolfgang Coy

Danksagung

An dieser Stelle möchte ich mich bei Herrn Prof. Dr.–Ing. Siegfried Wendt herz-lich bedanken, der meine Sichtweise auf informationsverarbeitende Systeme ent-scheidend geprägt hat. Sie ermöglicht mir im besonderen Maße den täglichenund beruflichen Umgang mit komplexen programmierten Systemen.

Herrn Prof. Dr. Heiner Müller-Merbach und Herrn Prof. Dr. Wolfgang Coy dankeich sehr für die Übernahme des Koreferats.

Rémy Apfelbacher

Zusammenfassung

Die Komplexität heutiger programmierter Systeme macht eine Arbeitsteilung beiEntwicklung, Betrieb, Evolution sowie Pflege und Wartung unumgänglich. Vor-aussetzung dafür ist eine effiziente Kommunikation zwischen den Beteiligten, daimmer komplexere Systeme in immer kürzerer Zeit zur Marktreife gebracht wer-den müssen. Wegen der hohen Anzahl Beteiligter, die in internationalen Unter-nehmen unterschiedliche Sprachen sprechen und sich in unterschiedlichen Zeit-zonen aufhalten, kann eine effiziente Kommunikation nicht nur mündlich erfol-gen. Abgesehen von den technischen und sprachlichen Voraussetzungen für dieKommunikation ist auch eine verständliche Vermittlung von Konzepten erfor-derlich. Diese Konzeptbeschreibungen bilden die Grundlage der arbeitsteiligenUmsetzung. Bisher fordern alle bestehenden Beschreibungs- und Modellierungs-ansätze in der Literatur völlige Konsistenz in Konzeptbeschreibungen.

Ziel dieser Arbeit ist, diese Forderung zu hinterfragen, da sie praktisch nicht um-setzbar zu sein scheint. Zum Einen sind teilweise inkonsistente Beschreibungennicht völlig unbrauchbar, zum Anderen kann dieser Forderung aufgrund einesungünstigen Aufwand/Nutzen-Verhältnis nicht immer entsprochen werden. Dabisher keine Studien zum Umgang mit Inkonsistenzen in der Praxis vorliegen,wurden vier Projekte in drei Unternehmen unter diesem Aspekt untersucht. DieErgebnisse umfassen die Erstellungsprozesse für Beschreibungen, die durchge-führten Konsistenzprüfungen und die eingesetzten Kriterien zur Bewertung dergefundenen Inkonsistenzen. Die Untersuchung ergab, dass in der Praxis Inkon-sistenzen in Beschreibungen bewusst toleriert werden, um unverhältnismäßigenAufwand zu vermeiden. Insbesondere konnte festgestellt werden, dass eine dif-ferenzierte Gewichtung der Inkonsistenzen vorgenommen wird.

Aufbauend auf den gewonnen Erkenntnissen wird ein Ansatz für die Erstellungund Konsistenzprüfung von Konzeptbeschreibungen unter Berücksichtigung to-lerierbarer Inkonsistenzen vorgestellt. Als Kern kommt das in der Untersuchungidentifizierte Kriterium der Effizienz zum Einsatz. Daraus ergeben sich eine Fo-kussierung auf eine bestimmte Klasse von Inkonsistenzen und ein zusätzlichesKriterium für die Inhalte von Konzeptbeschreibungen. Danach sollten nur solcheInhalte in die Beschreibung einfließen, für deren Auffinden andernfalls wieder-holt ein hoher Aufwand aufgebracht werden müsste. Der vorgestellte Ansatz hatkeinen Anspruch auf Vollständigkeit, da er lediglich einige ausgewählte Schritteund Verfahren bei der Erstellung und Verwendung von Konzeptbeschreibungenanspricht. Er soll vielmehr dazu beitragen, ein Bewusstsein für tolerierbare In-konsistenzen zu schaffen, um unnötigen Aufwand zu vermeiden.

Inhaltsverzeichnis

1 Einleitung 1

1.1 Problembeschreibung . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2 Lösungsansatz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.3 Gliederung der Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2 Grundlagen zum Thema Systemmodelle und deren Beschreibungen 7

2.1 Modellierungsansätze . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.1.1 Fundamental Modeling Concepts (FMC) . . . . . . . . . . . 8

2.1.2 Applied Software Architecture . . . . . . . . . . . . . . . . . 9

2.1.3 Objektorientierte Ansätze . . . . . . . . . . . . . . . . . . . . 11

2.2 Formulierte Systemmodelle . . . . . . . . . . . . . . . . . . . . . . . 12

2.2.1 Charakteristika von Systemmodellbeschreibungen . . . . . 13

2.2.2 Notation von Modellierungsansätzen . . . . . . . . . . . . . 15

2.2.2.1 Fundamental Modeling Concepts (FMC) . . . . . . 15

2.2.2.2 Applied Software Architecture . . . . . . . . . . . . 15

2.2.2.3 Objektorientierte Ansätze und Unified ModelingLanguage (UML) . . . . . . . . . . . . . . . . . . . 16

3 Inkonsistenzen bei der Beschreibung programmierter Systeme 19

3.1 Inkonsistenz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3.1.1 Begriff . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3.1.2 Eigenschaften von Inkonsistenz . . . . . . . . . . . . . . . . 21

3.1.3 Konsistenzprüfung . . . . . . . . . . . . . . . . . . . . . . . . 26

3.1.4 Klassifizierung von Inkonsistenzen . . . . . . . . . . . . . . 30

3.1.4.1 Inkonsistenzen im System . . . . . . . . . . . . . . 31

3.1.4.2 Vorgabenbedingte Inkonsistenzen . . . . . . . . . . 33

3.1.4.3 Modellinkonsistenzen . . . . . . . . . . . . . . . . . 35

i

Inhaltsverzeichnis

3.2 Modellbildung und nicht ideale Modelle . . . . . . . . . . . . . . . 36

3.2.1 Analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

3.2.2 Synthese . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

3.3 Beschreibung programmierter Systeme . . . . . . . . . . . . . . . . 45

3.3.1 Notwendigkeit von Systembeschreibungen . . . . . . . . . . 45

3.3.2 Klassen von Systembeschreibungen . . . . . . . . . . . . . . 48

3.3.2.1 Formbezogene Klasse von Systembeschreibungen 48

3.3.2.2 Inhaltsbezogene Klasse von Systembeschreibungen 53

3.3.3 Dokument als schriftliche Systembeschreibung . . . . . . . . 61

3.3.3.1 Dokument . . . . . . . . . . . . . . . . . . . . . . . 61

3.3.3.2 Struktur von Dokumenten . . . . . . . . . . . . . . 64

3.3.3.3 Nutzung von Dokumenten . . . . . . . . . . . . . . 65

3.3.3.4 Erstellung und Evolution von Dokumenten . . . . 69

3.3.3.5 Inkonsistenzen in und zwischen Dokumenten . . . 77

4 Bestehende Ansätze für den Umgang mit Inkonsistenz 79

4.1 Inkonsistenzen im System . . . . . . . . . . . . . . . . . . . . . . . . 80

4.1.1 Pollution Markers . . . . . . . . . . . . . . . . . . . . . . . . 81

4.1.2 FMC-eCS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

4.1.3 Making inconsistency respectable . . . . . . . . . . . . . . . 82

4.2 Vorgabenbedingte Inkonsistenzen . . . . . . . . . . . . . . . . . . . 83

4.2.1 Lazy Consistency . . . . . . . . . . . . . . . . . . . . . . . . . 83

4.2.2 Smarter Recompilation . . . . . . . . . . . . . . . . . . . . . . 84

4.2.3 Flexible Consistency Model (FCM) . . . . . . . . . . . . . . . 85

4.2.4 Viewpoints . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

4.3 Modellinkonsistenzen . . . . . . . . . . . . . . . . . . . . . . . . . . 87

4.3.1 Synoptic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

4.3.2 Agile Softwareentwicklung und agile Dokumentation . . . 89

5 Umgang mit Inkonsistenz in technischen Systembeschreibungen in derPraxis 91

5.1 Untersuchungsmethode . . . . . . . . . . . . . . . . . . . . . . . . . 92

5.1.1 Ziel der Untersuchung . . . . . . . . . . . . . . . . . . . . . . 92

5.1.2 Explorative Fallstudien und qualitative Analyse . . . . . . . 93

ii

Inhaltsverzeichnis

5.2 Umfang der Untersuchung . . . . . . . . . . . . . . . . . . . . . . . 95

5.3 Gesamtauswertung der Untersuchung . . . . . . . . . . . . . . . . . 96

5.3.1 Konzeptbeschreibungen . . . . . . . . . . . . . . . . . . . . . 96

5.3.2 Prozess der Dokumentationserstellung . . . . . . . . . . . . 98

5.3.3 Konsistenzprüfung . . . . . . . . . . . . . . . . . . . . . . . . 100

5.3.4 Inkonsistenzbewertung . . . . . . . . . . . . . . . . . . . . . 104

5.4 Ergebnis der Untersuchung . . . . . . . . . . . . . . . . . . . . . . . 106

5.5 Vergleichbare Untersuchungen . . . . . . . . . . . . . . . . . . . . . 109

5.6 Aussagekraft der Untersuchung . . . . . . . . . . . . . . . . . . . . 112

6 Ein Ansatz für Konzeptbeschreibungen unter Berücksichtigung tole-rierbarer Inkonsistenzen 115

6.1 Kriterien für tolerierbare und nicht tolerierbare Inkonsistenzen inKonzeptbeschreibungen . . . . . . . . . . . . . . . . . . . . . . . . . 115

6.1.1 Tolerierbare Inkonsistenzen . . . . . . . . . . . . . . . . . . . 119

6.1.2 Nicht tolerierbare Inkonsistenzen . . . . . . . . . . . . . . . 122

6.2 Vorschlag für die Erstellung von Konzeptbeschreibungen . . . . . . 125

6.2.1 Erstellungs- und Evolutionsprozess . . . . . . . . . . . . . . 125

6.2.2 Strukturierung und Inhalte von Konzeptbeschreibungen . . 128

6.2.3 Werkzeugunterstützung . . . . . . . . . . . . . . . . . . . . . 130

6.3 Vorschlag für die Durchführung von Konsistenzprüfungen . . . . . 131

6.3.1 Konsistenzprüfung durch Ersteller . . . . . . . . . . . . . . . 133

6.3.2 Konsistenzprüfung durch Empfänger . . . . . . . . . . . . . 135

7 Fazit und Ausblick 137

Literaturverzeichnis 139

Index 159

A Einzelfallanalysen 167

A.1 Projekt 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167

A.2 Projekt 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171

A.3 Projekt 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174

A.4 Projekt 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178

iii

Inhaltsverzeichnis

iv

Kapitel 1

Einleitung

1.1 Problembeschreibung

Ein wesentliches Merkmal bei der Entwicklung1 komplexer programmierter Sys-teme ist die Vielzahl Beteiligter in unterschiedlichsten Rollen. Aufgrund der ho-hen Komplexität ist es einer einzelnen Person nicht möglich, die enorme Mengean Informationen zu erfassen – ganz abgesehen von der Bewältigung des Ent-wicklungsaufwands alleine. Eine effektive Arbeitsteilung ist deshalb unerläss-lich. Dementsprechend ist der Kommunikationsbedarf über das zu schaffendeSystem zwischen den Beteiligten außerordentlich hoch.

Die Kommunikation zwischen den Beteiligten manifestiert sich in vielen ver-schiedenen Formen, den Beschreibungen. So werden Informationen beispielswei-se durch Gespräche oder Präsentationen ausgetauscht. Bedingt durch die großeZahl Beteiligter wird neben der direkten mündlichen Kommunikation oft dieKommunikation mittels Dokumenten eingesetzt. Häufig halten sich die Betei-ligten an geographisch unterschiedlichen Orten auf und aus organisatorischenGründen ist eine persönliche Kommunikation erschwert oder nicht möglich.Durch die Dokumente wird eine breitere Masse Mitwirkender erreicht und somitder Kommunikationsaufwand auf ein vertretbares Niveau reduziert. Den Bedarfan solchen Dokumenten in der Praxis belegen beispielsweise Untersuchungenvon Keller [Keller 03].

Gerade bei komplexen programmierten Systemen ist es unvermeidlich, dass sichimmer wieder Diskrepanzen zwischen den Systemvorstellungen der Beteiligtenergeben – ungeachtet, ob sich die Beteiligten darüber bewusst sind oder nicht. DieUrsachen sind mannigfaltig. Einige Beispiele sind unvollständige, missverstan-dene oder nicht mehr gültige Informationen. Der Software-Lebenszyklus kom-plexer programmierter Systeme erhöht die Inkonsistenzproblematik weiter. DerHauptaufwand – nach Balzert [Balzert 00] variiert er zwischen 67% und 80%– liegt dabei nicht in der initialen Erstellung, sondern in der Pflege und War-

1An dieser Stelle soll der Begriff „Entwicklung“ ebenfalls die Bedeutung von Wartung, Pflegeinkl. Weiterentwicklung (Evolution) umfassen.

1

Kapitel 1. Einleitung

tung (bzw. Weiterentwicklung). Die Ursache dafür liegt in beachtlichen Investi-tionen der Anbieter und Kunden und den daraus resultierenden langen Einsatz-zeiträumen, die immer wieder Anpassungen erforderlich machen. Das bedeutetfür die Majorität der Beteiligten, die bereits geschaffenen bzw. gedachten Struk-turen gut verstehen zu müssen, um die Änderungen während der Pflege undWartung optimal gestalten zu können. Dies setzt einen Wissensaustausch voraus,der zwangsläufig mit der Inkonsistenzproblematik behaftet ist. Leider befassensich die meisten Ansätze aus dem Bereich des Software Engineerings traditio-nell mit der Erstellung der initialen Version der Systembeschreibung, wie es z.B.in [Parnas et al. 94] und [Gales 98] festgestellt wird, und lassen den eigentlichenHauptaufwand unbeachtet.

Allerdings finden sich für die Entwicklung der ersten Version durchaus vie-le Maßnahmen zur Minimierung von Inkonsistenzen. Darunter fallen die Va-lidation bzw. Verifikation in ihren unterschiedlichsten Ausprägungen (nach[Boehm, Hansen 00] z.B. Anforderungsvalidierung, Designvalidierung und -verifikation, Modultest, Integrationstest, Akzeptanztest). Aber auch die vorge-schlagenen Softwareprozesse selbst stellen Gegenmaßnahmen zum Entstehenvon Inkonsistenzen dar. Das z.Z. prominenteste Beispiel ist hierbei das ExtremeProgramming (XP)2 [Beck 00]. Die wichtigsten Bestandteile des XP zielen eindeu-tig auf eine Reduktion von Inkonsistenzen. Dazu gehören die ständige Kommu-nikation der Entwickler untereinander3 und mit den Kunden bzw. Benutzern, dieSchlichtheit der Strukturen und Lösungsansätze und der fast völlige Wegfall derWartungs-, Pflege- und Weiterentwicklungsarbeiten, wodurch sich der minimaleDokumentationsaufwand ergibt. Für komplexe programmierte Systeme ist die-ser Ansatz zwar nicht konzipiert, er zeigt aber, dass schon in kleineren Maßstä-ben der Schlüssel zum Erfolg in der Lösung der Inkonsistenzproblematik liegt.Der Rational Unified Process (RUP) [Kruchten 04] ist ein Ansatz für komplexeprogrammierte Systeme. Zwar soll dieser den Bedürfnissen eines Projekts bzw.eines Unternehmens angepasst werden, dennoch sind es hier die verschiedenenArtefakttypen (über 80 an der Zahl), die für Klarheit sorgen sollen. Alle Ansätzefordern, dass vor der Realisierung intensive Gedankenarbeit zu Anforderungen,Strukturen des Systems und des Quellcodes etc. zu leisten ist. Außer der Plan-barkeit, Überprüfbarkeit und Machbarkeit soll sich die Qualität von Produkt undZusammenarbeit deutlich erhöhen. Die Abwesenheit von Inkonsistenzen ist folg-lich ein Qualitätsmerkmal. Sie trägt zu einem erheblichen Teil dazu bei, die Zeit-und Budgetplanung sowie die Anforderungen an die Qualität einzuhalten.

Die völlige Konsistenz aller festgehaltenen Informationen wird dabei als selbst-verständliches Ziel erklärt:

„If a change is made, all documentation that is invalidated must2Extreme Programming stellt eine agile Softwareentwicklungsmethode dar, die ausschließlich

für kleine Projekte mit ca. 10 Entwicklern konzipiert ist und hauptsächlich auf Best Practices be-ruht. Wegen der ungeheuren Popularität wird zunehmend versucht XP in komplexeren Projekteneinzusetzen.

3Darunter fällt auch das populäre „Pair-Programming“, bei dem zwei Entwickler gleichzei-tig vor demselben Rechner am selben Arbeitspaket arbeiten. Weiterhin sollen alle Entwickler ineinem einzigen Raum untergebracht werden.

2

1.2. Lösungsansatz

be changed. If a change invalidates a design document, it and all sub-sequent design documents must be faked to look as if the change hadbeen the original design.“ [Parnas, Clements 86] (S. 254-255).

Parnas und Clements erkennen, dass ein systematisches und schrittweises Vor-gehen aus den Anforderungen heraus bis zur fertigen Software, wie es Prozess-modelle suggerieren, nicht durchführbar ist. Sie schlagen vor, durch die im Nach-hinein erzeugten Dokumente einen idealen Verlauf vorzutäuschen.

Die Probleme bei der Entwicklung, Wartung, Pflege und Weiterentwicklung kom-plexer programmierter Systeme liegen also nicht vorwiegend in der Realisierungdes Systems, sondern in der Kommunikation über das zu realisierende System.Das Vorgehen ist folglich maßgeblich durch den Umgang mit Inkonsistenzen inden Beschreibungen bestimmt.

In der Literatur fehlt die Auseinandersetzung mit der Inkonsistenzproblema-tik. Alle existierenden Ansätze gehen von einem Ideal aus, bei dem keine In-konsistenzen auftreten oder selbstverständlich aufgelöst werden, ohne die Fol-gen oder Machbarkeit solcher Aussagen zu prüfen. Weiterhin finden sich häu-fig Behauptungen, dass inkonsistente Beschreibungen gänzlich nutzlos seien. Esgibt einige wenige Ausnahmen im Bereich des Requirements Engineering (sie-he z.B. [Nuseibeh et al. 00], [Fickas et al. 97] oder [Easterbrook, Chechik 01]), diesich im weiteren Sinne mit der Inkonsistenzproblematik befassen. Dies ist ange-sichts der Komplexität und Wichtigkeit der programmierten Systeme nicht aus-reichend und bedarf näherer Untersuchungen. Vor allem ist es äußerst zweifel-haft, ob teilweise inkonsistente Beschreibungen in realistischem Kostenrahmenverhindert werden können und ob sie tatsächlich nutzlos sind. Daher ist die zen-trale Fragestellung der vorliegenden Arbeit die nach dem praktischen Umgangmit Inkonsistenzen, d.h. die Qualität tolerierbarer Inkonsistenzen soll ermitteltwerden. Dabei wird die Abwägung zwischen dem Aufwand zur Behebung vonInkonsistenzen und dem Nutzen aus der daraus resultierenden Konsistenz be-rücksichtigt.

1.2 Lösungsansatz

Ausgangspunkt dieser Arbeit ist die fehlende Behandlung der Inkonsistenzpro-blematik in der Literatur über den kommunikativen Aspekt bei der Entwicklungund Evolution komplexer programmierter Systeme.

Um einen Beitrag zur Klärung der Inkonsistenzproblematik zu leisten, müssenzunächst der Begriff der Inkonsistenz definiert und eine Klassifizierung einge-führt werden. Damit lassen sich erkannte Inkonsistenzen einordnen sowie po-tentielle Quellen und Auswirkungen von Inkonsistenzen angeben. Da die Kom-munikation über komplexe programmierte Systeme zu großen Teilen auf schrift-lichen Beschreibungen beruht, wird eine Klassifikation von Systembeschreibun-gen zur Identifikation relevanter Dokumente im Kontext der Inkonsistenzproble-matik erforderlich.

3


Bereits bestehende Ansätze aus der Literatur, die mit der Inkonsistenzproblema-tik im Allgemeinen in Zusammenhang gebracht werden können, werden zusam-mengefasst und bewertet.

Dies dient als Grundlage, um den Umgang mit Inkonsistenz in der Praxis zu erör-tern. Dafür müssen Studien im industriellen Kontext durchgeführt werden. Die-se lassen Rückschlüsse auf den Umgang mit Inkonsistenzen und eine Bewertungder Wichtigkeit einzelner Inkonsistenzklassen zu. Dabei werden Struktur und In-halte der Dokumente sowie die Vorgehensweise bei Erstellung und Konsistenz-prüfungen untersucht, um Kriterien für tolerierbare Inkonsistenzen zu identifi-zieren.

Mit Hilfe dieser Ergebnisse lassen sich Aussagen über ein Vorgehen für die Er-stellung von Konzeptbeschreibungen ausarbeiten, die tolerierbare Inkonsisten-zen berücksichtigen. Durch die Gewichtung einzelner Klassen von Inkonsisten-zen, soll eine Abwägung zwischen Aufwand und Nutzen zur Identifikation undBehebung von Inkonsistenzen erleichtert werden. Hierbei werden Kriterien fürStrukturen und Inhalte der Systembeschreibungen angegeben.

1.3 Gliederung der Arbeit

Kapitel 2 führt grundlegende Begriffe zum Thema Systemmodelle ein. Die Klä-rung dieser Begriffe ist wichtig für das Verständnis der vorliegenden Arbeit, dadarauf aufbauend Folgebegriffe, speziell für den Bereich Inkonsistenz, definiertwerden.

Kapitel 3 führt den Begriff Inkonsistenz mit näherer Beschreibung der Eigen-schaften und der Konsistenzprüfung sowie eine Klassifizierung ein. Es werdenweiterhin für entdeckte Inkonsistenzen die prinzipiell möglichen Maßnahmenfür deren Umgang dargelegt. Anschließend werden potentielle Quellen für dasAuftreten von Inkonsistenzen aufgeführt. Dazu gehört in erster Linie die Modell-bildung. Weiterhin wird speziell auf die verbreitetste Form von Systembeschrei-bungen, die schriftlichen Systembeschreibungen eingegangen.

Kapitel 4 beschreibt den in der Literatur vorgefunden, aktuellen Stand zum The-ma Umgang mit Inkonsistenzen. Diese werden gemäß den im vorherigen Kapiteldefinierten Klassen von Inkonsistenzen eingeordnet. Kein vorgefundener Ansatzin der Literatur beschäftigt sich mit der Thematik von Umgang mit Inkonsisten-zen im Bereich von Konzeptbeschreibungen.

Kapitel 5 enthält die Beschreibung und Auswertung, der im Rahmen der vorlie-genden Arbeit durchgeführten Untersuchung. Ziel der Untersuchung war es, denStand der Praxis mit dem Umgang von Inkonsistenzen zu erörtern. Dazu wurdenmehrere Fallstudien im industriellen Kontext durchgeführt.

Kapitel 6 stellt einen Ansatz für Konzeptbeschreibungen unter Berücksichtigungder vorgefundenen Ergebnisse der Untersuchung im vorangegangen Kapitel vor.

4

1.3. Gliederung der Arbeit

Es werden dabei vor allem der Aspekt der tolerierbaren Inkonsistenzen berück-sichtigt und ein Kriterium angegeben mit welchem abgeschätzt werden kann,welche Inkonsistenzen toleriert werden können.

Kapitel 7 gibt ein kurzes Fazit wieder. Es gibt zudem einen Ausblick auf weitereUntersuchungsfelder.

5


6

Kapitel 2

Grundlagen zum ThemaSystemmodelle und derenBeschreibungen

Die für diese Arbeit wichtigsten Begriffe zum Themenbereich Systemmodelleund ihre Beschreibungen werden in diesem Kapitel zusammenfassend aufge-listet. Dies dient im späteren Verlauf dazu, Quellen von Inkonsistenzen iden-tifizieren zu können. Die genaueren begrifflichen Grundlagen zum Bereich in-formationelle Systeme und deren Modellierung sind in [Wendt 91], [Wendt 01],[Bungert 98], [Gales 98], [Tabeling 00] und [Tabeling 05] nachzuschlagen. Die vor-liegende Arbeit verwendet die dort definierten Begriffe mit deren Interpretation.

Ausführlicher werden in diesem Kapitel Systemmodelle und deren Beschreibun-gen als die grundlegenden Merkmale einer effizienten Kommunikation vorge-stellt.

2.1 Modellierungsansätze

Im Folgenden werden ausgewählte Modellierungsansätze4, die dem Thema in-formationelle bzw. programmierte Systeme zugeordnet werden können, kurz vorge-stellt. Auf eine umfassende Aufführung von Modellierungsansätzen kann hierverzichtet werden. Die Kriterien bei der Auswahl basieren auf den Ergebnis-sen der Fallstudien von Keller [Keller 03] (S. 59 ff.) und dem von den Begrün-dern des Modellierungsansatzes propagierten Praxisbezug. Kein Modellierungs-ansatz, bis auf die objektorientierten Ansätze, hat der Studie zur Folge eine re-levante Verbreitung. Der Modellierungsansatz Fundamental Modeling Concepts

4Bei einer Modellierung „[...] wird eine Menge von Sachverhalten dadurch untersucht oderbeschrieben, dass eine zweite Menge von Sachverhalten untersucht oder beschrieben wird, undzwischen der zweiten Menge von Sachverhalten und der eigentlich interessierenden ersten Men-ge Analogiebeziehungen bestehen, die eine Übertragung bestimmter Aussagen oder Erkenntnis-se erlauben.“ [Seewaldt 88] (S. 18).

7

Kapitel 2. Grundlagen zum Thema Systemmodelle und deren Beschreibungen

(FMC) wird in dieser Arbeit besonders hervorgehoben, da er als Beispielanwen-dung dient und sich in der Studie als einzige Alternative in nicht standardisierteBereichen zu Ad-hoc-Modellierungen gezeigt hat.

Ein Modellierungsansatz soll bei der Bewältigung des Komplexitätsproblems kon-krete Hilfestellungen geben. Mit Hilfe eines Modellierungsansatzes können idealeinformationelle Systemmodelle56, gebildet werden. Aus diesen Modellen kann dasSystemverhalten begründbar abgeleitet werden. Die Grundlage für die Modell-bildung ist die Begriffswelt des verwendeten Modellierungsansatzes. Sie bestimmtwelche Einheiten und welche Beziehungen relevant sind. Dadurch werden auchdie Grenzen des Modellierungsansatzes festgelegt. Weiterhin wichtig ist das Me-tamodell des Modellierungsansatzes. Mit Hilfe eines solchen Metamodells wirdein Anwender bei der Strukturfindung unterstützt. Sein Nachdenken über dasSystem wird, z.B. durch Fragestellungen, die sich aus dem Metamodell ergeben,gelenkt. Daneben definiert fast jeder Modellierungsansatz eine Notation. Dies istThema des Kapitels 2.2.2. Auf weitere Angaben z.B. im Hinblick auf die Einord-nung in den Schaffungsprozess oder auf den primären Einsatzzweck wird andieser Stelle verzichtet.

2.1.1 Fundamental Modeling Concepts (FMC)

Zweck der Fundamental Modeling Concepts (FMC) ist eine effektive zwischen-menschliche Kommunikation über informationelle Systeme insbesondere pro-grammierte Systeme zu ermöglichen. Dazu stellen sie Hilfsmittel in Form einerwissenschaftlich fundierten Begriffswelt, eines Metamodells und einer Notati-on zur Verfügung (vgl. [Knöpfel et al. 05] und [Keller et al. 02]). Eine umfassendeAuflistung von Veröffentlichungen und weitere Informationen zum Thema FMCsind unter [FMC] zu finden.

Wesentliches Merkmal von FMC ist die Untergliederung eines Modells in dreikomplementäre Strukturen, die auch Aspekte genannt werden:

• Aufbaustruktur,

• Ablaufstruktur und

• Wertebereichsstruktur.

Durch diese Aspekte lässt sich die Komplexität weiter reduzieren. Die Auf-baustruktur (vgl. [Wendt 80b]) spielt eine besondere Rolle, da sie als Referenz-grundlage für die übrigen Strukturen dient. Bei den Aufbaustrukturen wird zwi-

5Ein ideales Systemmodell entspricht einer reinen Teilmenge der Originalsachverhalte des Sys-tems und stellt somit eine Abstraktion des Originalsystems dar. Sinn und Zweck eines solchenModells ist, das System als solches zu begreifen, d.h. sein Verhalten begründbar abzuleiten. Esdient als Grundlage des Verständnisses. Ein ideales Systemmodell ist „das Netz der angenomme-nen Kausalbeziehungen [...], woraus man seine Vorhersagen ableitet.“ [Wendt 91] (S. 137).

6Ein ideales informationelles Systemmodell ist das Ergebnis der Interpretation materiell-energetischer Sachverhalte, also eine neue Menge rein informationeller Sachverhalte des Systems.

8

2.1. Modellierungsansätze

schen aktiven und passiven Komponenten unterschieden. Die aktiven Komponen-ten werden Akteure (vgl. [Wendt 79]) genannt. Sie verursachen Änderungen vonWerten (Informationen) auf den passiven Komponenten7, den Kanälen und denSpeichern, und sind somit für sämtliche Aktivitäten zuständig. Alle Akteure agie-ren potentiell nebenläufig zueinander und können ausschließlich mit passivenKomponenten verbunden sein. Kanäle und Speicher sind (abstrakte) Orte, an de-nen Werte und Wertänderungen beobachtbar sind. Kanäle haben im Gegensatz zuSpeichern flüchtigen Charakter. Weiterhin lässt sich Strukturvarianz, das Entste-hen und Verschwinden von aktiven bzw. passiven Komponenten, modellieren.Aktive und passive Komponenten können beliebig abstrakt sein, d.h. aber auch,dass sie sich durchaus auf konkrete Gebilde beziehen können. Die Ablaufstruk-tur ist die Kausalstruktur (vgl. [Wendt 78]) des Ereignisfolgengeflechts, das sichauf die Operation bzw. Aktivitäten8 der Akteure aus der Aufbaustruktur bezieht.Um weiter die Komplexität zu reduzieren, wird der Systemzustand in Steuer-und Operationszustand getrennt (vgl. [Wendt 98c]). Mit Hilfe von Steuerzustän-den kann die Reihenfolge von Operationen bzw. Aktivitäten angegeben werden.Sie sind daher Gegenstand der Ablaufstruktur. Auf die Operationszustände wirdim Rahmen von Operationen bzw. Aktivitäten Bezug genommen. Die Wertebe-reichsstruktur legt das Repertoire der Wertebelegungen der passiven Komponen-ten aus der Aufbaustruktur fest. Dabei handelt es sich vorwiegend um Operati-onszustände.

Bei FMC wird keine festgelegte Menge an Sichten postuliert, um dem Modellie-rer die notwendige Freiheit zu lassen, die für das System auch nach didaktischenGesichtspunkten bestmöglichen Sichten zu wählen. Die Modelle stehen mitein-ander durch eine Modellhierarchie in Beziehung. Als besonders wichtig wird dieModellbeziehung der Betrachtungsebenenwechsel (siehe [Bungert 98], S. 40 ff.) an-gesehen. So wird bei FMC z.B. immer zwischen Trägersystem und Rollensystemunterschieden. Die restlichen Modellbeziehungen, Systemausschnitts- und Auflö-sungsbeziehungen, werden auch von FMC genutzt. Darüber hinaus werden nochsogenannte Aspektmodelle und Anschauungsmodelle (vgl. [Tabeling 00], S. 26ff.) unterschieden. Ein Aspektmodell ist das durch Abstraktion gewonnene Modelleines Ausgangsmodells unter Berücksichtigung eines bestimmten Aspekts. Es istvor allem zweckdienlich, um allgemeingültige und daher unabhängig betracht-bare Konzepte herauszustellen und so die Komplexität weiter zu reduzieren. EinAnschauungsmodell ist wenig präzise bzw. vollständig und dient vorwiegend demGrobverständnis des Systems.

2.1.2 Applied Software Architecture

Der Ansatz von Hofmeister et al. [Hofmeister et al. 00] hat das Verstehen der Sys-temarchitektur aller Beteiligten zum Ziel. Dazu unterscheiden sie vier Sichten:

• die konzeptionelle Sicht (engl. conceptual view),7Passive Komponenten werden auch als Aktionsfelder bezeichnet.8Eine Operation – ein lesender oder schreibender Zugriff – bildet die atomare Einheit, die ein

Akteur durchführen kann. Eine Aktivität besteht aus mehreren Operationen.

9


• die Modulsicht (engl. module view) und

• die Trägersystemsicht (engl. execution view),

• die Konfigurationsmanagementsicht (engl. code view).

Bei der konzeptionellen Sicht bilden Komponenten (engl. components) und Ver-binder (engl. connector) die wesentlichen Bestandteile. Eine Komponente besitztPorts9, die das Kommunikationsprotokoll (Reihenfolge und Format ein- und aus-gehender Nachrichten) festlegen. Ein Port kann Nachrichten bearbeiten. Die Auf-gaben einer Komponente sind operationeller Natur. Steuerungsaufgaben über-nehmen die Verbinder. Bei den Verbindern werden die Ports Roles genannt. Aus-schließlich über Ports und Roles können Komponenten bzw. Verbinder verbun-den werden. In der konzeptionellen Sicht sind strikte Verfeinerungen (Auflö-sungsbeziehung) möglich. Kompenenten und Verbinder zu unterscheiden, solldie Schaffung wiederverwendbarer Komponententypen fördern. Verbinder sindnicht zu Wiederverwendungszwecken geeignet, da diese die systemspezifischenTeile darstellen. Grundsätzlich lässt sich darin die Unterscheidung von Steuer-und Operationszuständen aus FMC wiederfinden. Daten werden in diesem Mo-dell Komponenten oder Verbindern zugeordnet und werden nicht explizit behan-delt. Im Zentrum der konzeptionellen Sicht steht das Rollensystem – das Gewoll-te. Betrachtungsebenenwechsel werden in dieser Sicht nicht unterstützt.

Die Modulsicht dient der Abbildung der Elemente der konzeptionellen Sicht aufrealisierungsnahe Elemente. Es werden Subsysteme, Module und Schichten un-terschieden. Üblicherweise werden Komponenten, die in der konzeptionellenSicht weiter verfeinert werden, auf Subsysteme abgebildet. Subsysteme könnenModule enthalten. Sie können jedem Element der konzeptionellen Sicht zugeord-net werden und entsprechen programmiersprachlichen Einheiten, wie z.B. demPaket. Weiterhin können Module in Schichten (engl. layer) zusammengefasst wer-den.

Die Trägersystemsicht hat die Auswahl geeigneter Trägersystemelemente zum In-halt. Dazu werden Module der Modulsicht auf Trägersystemelemente, wie z.B.Thread, Prozess, Datei und Socket, abgebildet. Des Weiteren werden die Kom-munikationsmöglichkeiten zwischen den einzelnen Tägersystemelementen undderen Verteilung festgelegt.

Die Konfigurationsmanagementsicht behandelt Strukturen der Software. Dazu ge-hören die Quelldateien sowie deren Kompilate und Auslieferungseinheiten wie z.B.Bibliotheken. Die Quelldateien können dabei auf Modelle abgebildet werden,Auslieferungseinheiten dagegen auf Tägersystemelemente. Die Konfiguration,unter anderem auch die Versionierung, wird ebenfalls berücksichtigt, in dem dieElemente dieser Sicht zu Kodegruppen zusammengefasst werden und ihnen Kon-figuration zugeordnet wird. Diese Kodegruppen lassen sich auch auf die Subsys-teme und Schichten abbilden.

9Um keine Mehrdeutigkeiten durch die Übersetzung der englischen Begriffe Port und Role alsAnschluss zu ermöglichen, sollen die Originalbezeichnungen erhalten bleiben.

10

2.1. Modellierungsansätze

2.1.3 Objektorientierte Ansätze

Die objektorientierten Ansätze lassen sich in drei Bereiche untergliedern: die ob-jektorientierte Analyse (OOA) (engl. object-oriented analysis) [Coad, Yourdon 91a]als Vorbereitung für das objektorientierte Design (OOD) (engl. object-oriented de-sign) [Coad, Yourdon 91b], das schließlich zur objektorientierten Programmierung(OOP) (engl. object-orientied programming) führt10. Ziel der OOA ist eine voll-ständige, konsistente und realisierbare Spezifikation des Gewollten unabhängigvon ihrer konkreten Realisierung. OOD soll hingegen eine konkrete Realisierung,durch Änderungen bzw. Anreicherung der OOA-Spezifikation, als Ergebnis ha-ben. Diese lässt sich auf eine objektorientierte Zielprogrammiersprache direkt ab-bilden. Allen liegt eine gemeinsame Begriffswelt zugrunde, was den Übergangvor allem von OOA nach OOD erheblich erleichtern soll. Im Folgenden sollennur die Grundbegriffe der OOA erläutert werden.

Klasse und Objekt stehen im Mittelpunkt der Betrachtungen. Eine Klasse (engl.class) ist die Beschreibung eines oder mehrerer Objekte. Ein Objekt oder eine In-stanz (engl. object oder instance) wird als Abstraktion eines Gegenstands der Do-mäne definiert. Ein Attribut (engl. attribute) ist ein Datentyp. Somit hat ein Objektdieser Klasse einen bestimmten Wert für das entsprechende Attribut. Eine Opera-tion (engl. service) entspricht dem Verhalten, das ein Objekt anbietet und kannebenfalls einer Klasse zugeordnet werden. Beide Eigenschaften eines Objekts,Attribut und Operation, werden in der Klasse beschrieben. Zwischen Klassenbzw. Objekten kann eine Generalisierungs- bzw. Aggregationsbeziehung beste-hen. Eine Generalisierungsbeziehung oder Vererbungsbeziehung (engl. generalization-specification structure oder inheritance) partitioniert eine Klasse. Die Aggregations-beziehung (engl. whole-part structure oder aggregation) identifiziert, dass ein Objektzusätzlich aus anderen Objekten besteht. Zwischen Objekten können Assoziatio-nen (engl. instance connections oder association) bestehen. Sie sollen den Umstandverdeutlichen, dass ein Objekt von anderen Objekten abhängig ist, um seine Auf-gabe erfüllen zu können. Objekte können untereinander über Nachrichten (engl.messages) kommunizieren. Diese Beziehung wird auch Kollaboration (engl. messageconnection oder collaboration) genannt. Objekte können, gegeben durch bestimmteBelegungen der Attribute, Zustände (engl. object states) einnehmen und wechseln.Kleis diskutiert in [Kleis 99] Zusammenhänge zwischen FMC und der Objektori-entierung und interpretiert ein Objekt als Akteur, Speicher oder als Verbund vonAkteur und Speicher.

Dank der weiten Verbreitung objektorientierter Ansätze erfahren diese ständigErweiterungen. Teilweise dienen diese Erweiterungen auch der Komplexitätsre-duktion. Die „4+1 Sichten“ von Kruchten [Kruchten 95] sind ein bekanntes Bei-spiel und finden auch im Rational Unified Process (RUP) [Kruchten 04] Anwen-dung. Es werden insgesamt fünf Sichten (logical view, development view, processview, physical view und scenarios) definiert. „To describe a software architecture,we use a model composed of multiple views or perspectives.“ [Kruchten 95] (S.

10Historisch gesehen verlief die Entwicklung der Ansätze in umgekehrter Reihenfolge. Die hiergewählte Reihenfolge soll die Idealvorstellung darstellen.

11


42). Dies lässt sich nicht mit der in dieser Arbeit getätigten Definition des Be-griffs „Sicht“ in Einklang bringen, da bei Kruchten die Sichten durch die Partitio-nierung des Modells entstehen, also Aspekten entsprechen. Betrachtungsebenen-wechsel werden nicht unterstützt.

2.2 Formulierte Systemmodelle

Jeglicher zwischenmenschlicher Wissensaustausch basiert auf informationstra-genden Formen. Dabei lassen sich immer zwei Rollen unterscheiden: die des Sen-ders und die des Empfängers. Der Sender will Wissen vermitteln, wogegen derEmpfänger Wissen entgegennehmen will. Der Sender identifiziert das zu Vermit-telnde, damit der Empfänger seine Aufmerksamkeit darauf richtet. Nach Wendt[Wendt 97] können drei Arten der Identifikation unterschieden werden:

• Zeigen,

• Nennen und

• Umschreiben.

Die Identifikation durch Zeigen benötigt das Konkrete, auf das gezeigt werdenkann. Es muss sich im unmittelbaren Umfeld des Senders und des Empfängersbefinden, um wahrgenommen zu werden. Das Nennen setzt die Kenntnis der Be-teiligten über das zu Identifizierende und ein vereinbartes Symbol zur Identifi-kation voraus. Ein Symbol, wie das Wort „Apfel“, ist ein Stellvertreter materiell-energetischer Natur, dem das zu Identifizierende durch Interpretation zugeordnetwird. Das zu Identifizierende muss dabei nicht wahrnehmbar sein. Beim Um-schreiben wird das zu Identifizierende durch Identifikation seiner Eigenschaftenbzw. Beziehungen gewonnen. Meist schließt die Umschreibung Mehrdeutigkei-ten nicht aus. Beispielsweise könnten die durch eine Umschreibung identifizier-ten Eigenschaften eines Apfels auch auf eine Birne zutreffen. Zeigen und Nennenhaben den Vorteil Mehrdeutigkeiten fast völlig auszuschließen. Ihr Nachteil kön-nen die Konkretheit und Verfügbarkeit oder die vorausgesetzte Kenntnis des zuIdentifizierenden sein.

Im Rahmen dieser Arbeit wird das Ziel einer zwischenmenschlichen Kommu-nikation als die Übermittlung der Vorstellung – des Modells – des Senders anden Empfänger verstanden. Dafür muss eine Umschreibung getätigt werden, daModelle laut Definition reine Gedankenkonstrukte darstellen. Diese Umschrei-bung wird auch Beschreibung eines Modells genannt und ist eine Menge wahr-nehmbarer Formen, denen als Interpretationsergebnis das beschriebene Modellzugeordnet werden kann. Die Beschreibung selbst kann nicht als Modellsystemverstanden werden, da sie sich keinerlei materiell-energetische Sachverhalte mitdem System teilt.

Die Erstellung der Beschreibung wird Formulierung genannt. Der Sender formu-liert, d.h. drückt das zu Vermittelnde durch passende Symbole aus. Dies kann

12

2.2. Formulierte Systemmodelle

er beispielsweise durch Sprechen, Schreiben bzw. Zeichnen bewerkstelligen. DerSender sollte sich dabei an eine vom Empfänger bekannte Sprache und Begriffs-welt halten, um ihm die Aufnahme des zu Vermittelnden überhaupt erst zu er-möglichen. Eine Sprache, unabhängig von ihrer konkreten Erscheinungsform,kann in Bezug auf ihre Syntax, Semantik und Pragmatik untersucht werden. DieSyntax gibt an, wie interpretierbare Muster erstellt werden. Mit Hilfe einer Gram-matik kann eine Syntax beschrieben werden. Die Semantik dagegen stellt den Be-zug zwischen interpretierbarem Muster und dessen Bedeutung her. Der BegriffSemantik wird im Software-Engineering Bereich nicht einheitlich benutzt und oftals Synonym zu Bedeutung verstanden, siehe [Harel, Rumpe 00] (S. 16). Syntaxund Semantik werden häufig unter dem Begriff Notation zusammengefasst. Siehaben oft eine enge Bindung, da z.B. eine bestimmte Anordnung von Wörtern dieBedeutung ändern kann. Eine (primäre) Interpretation bezeichnet die Zuordnungder durch die Syntax definierten Muster zu ihrer Bedeutung. Davon zu unter-scheiden ist die sekundäre Interpretation. Sie hat keine materiell-energetischen For-men als Interpretationsgrundlage, sondern die Ergebnisse einer primären Inter-pretation. Die Pragmatik behandelt darüber hinausgehende vom Kontext abhän-gige Belange und spielt vor allem bei natürlichen Sprachen eine wichtige Rolle.

2.2.1 Charakteristika von Systemmodellbeschreibungen

Systemmodellbeschreibungen können sich in verschiedensten Formen äußern.Am weitesten verbreitet sind graphische und textuelle Formen, vor allem wennkeine direkte Kommunikation stattfinden kann. Ein Kriterium einer Beschrei-bung ist ihr Formalisierungsgrad. Es lassen sich nicht-formale, semi-formale undformale Beschreibungen unterscheiden.

Eine nicht-formale Beschreibung besitzt für die genutzte Sprache keine genaueFestlegung der Semantik und ist wenig strukturiert. Nichtsdestotrotz könnenmittels natürlicher Sprachen präzise Beschreibungen erstellt werden, auch wenndie Gefahr des Mißverständlichkeitsproblems (siehe [Wendt 98b]) besteht – das Ver-ständnis des Empfängers deckt sich nicht mit dem des Senders.

Das Gegenstück zu nicht-formalen Beschreibungen sind die formalen Beschrei-bungen. Sie besitzen die Eigenschaft, dass die Syntax und die Semantik der ge-nutzten Sprache genau definiert sind. Man spricht von formalen Sprachen11. So-mit folgen formale Beschreibungen einer Syntax, die einem formalen System ge-nügt. Zwar kann mit formalen Sprachen das Mißverständlichkeitsproblem gelöstwerden, aber das Unverständlichkeitsproblem (siehe [Wendt 98b]) bleibt weiterhinbestehen. In diesem Fall kann der Empfänger aufgrund der Beschreibung keinVerständnis gewinnen. Eng an den Begriff formal ist der Begriff Formalismus ge-knüpft. Ein Formalismus ist definiert als Vorschrift, anhand derer gegebene For-

11Eine formale Sprache ist von einer formalen Semantik zu unterscheiden. Nicht jede formaleSprache hat zwangsläufig eine formale Semantik. Eine Semantik ist formal, wenn das Interpreta-tionsergebnis keine Bedeutung sondern aus dem zugrunde liegenden Formalismus gewonneneFormen darstellt (vgl. [Wendt 98a] S. 10). Dies findet vor allem im Bereich der Programmierspra-chen praktische Anwendung.

13


men zu neuen Formen zusammengestellt werden. Die Formen werden bei die-sem Vorgang nicht interpretiert, um eine möglichst hohe Objektivität und Auto-matisierbarkeit zu gewährleisten. Formalismen selbst sind kein Garant für Kor-rektheit. An den essentiellen Schritten sind Menschen nicht ersetzbar. Zum einenführen sie die Formalismen ein und zum zweiten führen sie zunächst die For-malisierung und zuletzt die Interpretation durch. Dabei können Fehler gemachtwerden, die den kompletten Formalismus in Frage stellen können. Die Formalisie-rung entspricht dem Schritt, das Gedachte in eine Form zu bringen, die einer for-malen Sprache genügt. Nach erfolgreicher Anwendung (automatisierbarer) For-malismen muss schließlich eine Interpretation stattfinden, um einen Gewinn er-zielen zu können. Ein Beispiel für eine formale Beschreibung eines Modells istdie Software selbst. Sie ist gemäß einer formalen Sprache, einer Programmier-sprache, formuliert und soll die Vorstellung der Entwickler widerspiegeln. Lei-der verstehen selbst Entwickler häufig nur schwer das Formulierte. Biggerstaff etal. bezeichnet dies in [Biggerstaff et al. 94] als das „concept assignment problem“.Ob formale Beschreibungen nicht-formalen Beschreibungen vorzuziehen sind, istnicht eindeutig klärbar. Eine Studie von Smidts et al. [Smidts et al. 02] zeigt, dasseine Software-Entwicklung basierend einmal auf einen formalen und einmal aufeinem nicht-formalen Ansatz zu kaum unterschiedlichen Qualitätsergebnissenführte.

Semi-formale Beschreibungen entsprechen dem Mittelweg und halten sich nichtstreng an formale Sprachen. Dabei werden zusätzliche nicht-formale Elementehinzugefügt oder die formale Sprache wird absichtlich verletzt, um eine erhöhteAnschaulichkeit zu ermöglichen. Zumeist besteht auch bei formalen Beschrei-bungen die Möglichkeit, Bezeichner frei zu wählen. Diese werden in der Regelnach Kriterien des Verständnisses gewählt. So wird z.B. in einer Software eineRoutine zur Berechnung der Quadratwurzel der Bezeichner sqrt anstatt abc ver-wendet. Für den Abwickler spielt die Wahl der Bezeichner keine Rolle. Bei semi-formalen Beschreibungen hingegen stellt die Zweckmäßigkeit der gewählten Be-zeichner die Grundlage des Verständnisses dar. Eine vollständige Automatisie-rung ist dabei ohnehin nicht möglich.

Die Strukturierung der Modellbeschreibungen muss keine Entsprechung in denModellstrukturen finden. Die Strukturen der Beschreibungen folgen Zweckmä-ßigkeitsüberlegungen, z.B. kann die Beschreibung eines Modells aufgrund des-sen Komplexität auf mehrere Beschreibungseinheiten aufgeteilt werden.

Eine Modellbeschreibung trifft auf eine Klasse von Systemen zu, da sich bereitsdas Modell selbst durch die Abstraktion eines konkreten Systems auf eine Klassevon Systemen bezieht. In diesem Zusammenhang soll kurz auf die Unterschiedezwischen den Begriffen Menge, Klasse, Typ und Exemplar eingegangen werden.Eine Menge umfasst beliebig wählbare Objekte. Eine Klasse hingegen ist eine Men-ge von konkreten Objekten mit bestimmten gemeinsamen Merkmalen. Ein Typ istein abstraktes Objekt, das nach den Merkmalen der Klassenbildung gewonnenwird. Ein konkretes Objekt einer solchen Klasse wird Exemplar genannt. Folglichdefiniert ein Modell einen Typ12. Dennoch wird in der Regel mit einem Modell

12Das Modell ist ein abstraktes Objekt.

14


ein bestimmtes Exemplar verbunden und nicht eine ganze Klasse. Diese Sicht-weise ist zweckmäßig, da damit die Möglichkeit besteht, Betrachtungen auf derTypebene durchzuführen, was die ohnehin durch starke Abstraktionen geprägteArbeit erleichtert.

2.2.2 Notation von Modellierungsansätzen

Die Notation der meisten Modellierungsansätze ist graphischer Art und erlaubtzumeist beliebige textuelle Beschriftungen. Dabei handelt es sich folglich um se-miformale Beschreibungsansätze. Es existiert zwar eine Reihe von formalen Be-schreibungsansätzen, z.B. die so genannten Architecture Description Languages(ADL) (siehe [Medvidovic, Taylor 00]), deren Notationen ebenfalls häufig graphi-scher Art sind. Sie besitzen aber aufgrund ihrer schwachen Skalierbarkeit nurwenig Verbreitung in der Praxis. Schwerpunkt eines Modellierungsansatzes soll-te die dazugehörige Begriffswelt bilden, da sich eine Notation prinzipiell durchandere ersetzen lässt.

2.2.2.1 Fundamental Modeling Concepts (FMC)

Die FMC-Notation ordnet jedem Strukturtyp einen zugehörigen Diagrammtypzu. Gemeinsames Merkmal dieser Diagramme ist ihre Bipartitheit13. Sie spie-gelt komplementäre Begriffspaare, wie z.B. Akteur und Speicher bzw. Kanal, wi-der. Bild 2.1 zeigt beispielhaft die Notation: Aufbaudiagramme (vgl. [DIN 92])(engl. block diagram) beschreiben Aufbaustrukturen, Petrinetze (vgl. [Petri 62]und [Murata 89]) (engl. Petri net) beschreiben Ablaufstrukturen und Wertebe-reichsdiagramme (vgl. [Chen 76]) (engl. entity relationship diagram) beschreibenWertebereichstrukturen. Für Petrinetze stellt Wendt in [Wendt 80a] eine Erweite-rung zur Darstellung von Rekursion vor.

Prinzipiell können Alternativdiagrammtypen genutzt werden. Solche Alterna-tiven stellen z.B. Zustandsdiagramme zur Beschreibung von Ablaufstrukturenoder Schichtungsdiagramme14 zur Darstellung von Wertebereichstrukturen aufexemplarischer Ebene dar. Ad-hoc-Erweiterungen von Diagrammen sind erlaubt,sollten jedoch kommentiert werden. Das Layout der Diagramme wird bei FMCnicht vernachlässigt, da es die zwischenmenschliche Kommunikation fördernund nicht als zusätzliches Hindernis auftreten soll (vgl. [Apfelbacher et al. 05]).

2.2.2.2 Applied Software Architecture

Ursprünglich nutzte dieser Ansatz eine eigene Notation, siehe [Soni et al. 95]. Seit1998 basiert sie auf der Unified Modeling Language (UML) (siehe folgendes Kapi-tel). Sie nutzt eine Erweiterungsmöglichkeit der UML, die Stereotypes, um neue

13Ein Graph ist bipartit, wenn zwei Knotentypen existieren und nur Knoten unterschiedlichenKnotentyps verbunden werden.

14Ein Schichtungsdiagramm stellt eine quadratische Relation graphisch dar.

15


MH

C

B

A

R

GH

I

J

Aufbaudiagramm Petrinetz Wertebereichsdiagramm

D E

F

a

b

d e

c

K L

N PO

Akteur Speicher Kanal Transition Steuerzustand

mitMarke

Relation Entitätsmenge

ohneMarke

Schreib- undLesekante

Lesekante

Schreibkante

Ort der Struktur-varianz

Partitionierung

orthogonalePartitionierung

Objektifizierung 1:n Beziehung

Bild 2.1: Beispiel - (FMC) Fundamental-Modeling-Concepts-Notation

UML Symbole mit der Bedeutung von z.B. Komponenten und Verbindern anzu-bieten. Bild 2.2 zeigt die verwendete Notation für die konzeptionelle Sicht. Aus-sagen zum Layout sind nicht zu finden.

2.2.2.3 Objektorientierte Ansätze und Unified Modeling Language (UML)

Die Unified Modeling Language (UML) [OMG] und [Booch et al. 98] gilt heuteals de-facto-Notationsstandard im Softwarebereich. Daher verwendet heute derüberwiegende Teil objektorientierter Ansätze diese Notation15. Aufgrund der Po-pularität wird auch das Layout, worüber im Allgemeinen keine Aussagen ge-macht werden, untersucht (vgl. [Purchase et al. 01]). Bild 2.3 zeigt beispielhaftein Klassendiagramm als häufig genutzten Vertreter der 13 Diagrammtypen derUML 2.

15Vor der weiten Verbreitung der UML verwendete jeder Modellierungsansatz seine eigeneNotation. Diese Notationen wurden bei der Festlegung der UML konsolidiert.

16


:A

a c:B

:D

:C

g

h

e

f

b d

Portverfeinerte Komponente

Verbinder

Role

Komponente

Bild 2.2: Beispiel - Applied-Software-Architecture-Notation für die konzeptionel-le Sicht (basiert auf UML)

C

f

c()d()

B

de

a()

Aabca()b()

D

gh

e()

*

E

ij

f ()

Klasse

Attribut

Operation

Vererbung Aggregation

Assoziation

Multiplizität

Bild 2.3: Beispiel - Unified Modeling Language (UML) Notation für Klassendia-gramme

17


18

Kapitel 3

Inkonsistenzen bei der Beschreibungprogrammierter Systeme

Ziel dieses Kapitels ist, eine Begriffswelt im thematischen Umfeld von Inkonsis-tenz sowie der Beschreibung programmierter Systeme einzuführen. Nach grund-sätzlichen Überlegungen über die Begriffsdefinition von Inkonsistenz werdendiese im Hinblick auf die Modellierung und Beschreibung von programmier-ten Systemen untersucht. Neben dem Erstellen von schriftlichen Beschreibungenwird auch das Lesen gesondert hervorgehoben.

Die hier definierten Begriffe sollen als Grundlage für den weiteren Verlauf dervorliegenden Arbeit dienen. Vor allem soll klargestellt werden, dass abstraktereBeschreibungen dringend benötigt werden und sich Inkonsistenzen nicht ver-meiden lassen.

3.1 Inkonsistenz

3.1.1 Begriff

Laut [Müller 82] leiten sich sowohl der Begriff Inkonsistenz (engl. inconcistency)sowie der dazu gegensätzliche Begriff Konsistenz (engl. consistency) aus dem La-teinischen „consistere“ ab, das sich mit stillstehen oder dicht werden übersetzenlässt. Die gängigste Auslegung des Begriffs Konsistenz ist die Beschaffenheit ei-nes Stoffes hinsichtlich seiner Struktur wie z.B. im Bereich der Chemie. DieserBegriff, der auch umgangssprachlich Verwendung findet, hat aber für den weite-ren Verlauf dieser Arbeit keinerlei Relevanz.

Innerhalb der Informatik werden die Begriffe Inkonsistenz und Konsistenz in ver-schiedenen Teilbereichen unterschiedlich verwendet, wie es in [Claus, Schwill 03]festgestellt wird. Häufig werden diese Begriffe in Zusammenhang mit Daten-banksystemen genutzt. Dort besitzt eine Transaktion unter anderem auch dieGrundeigenschaft der Konsistenz. Eine solche Transaktion wird genau dann als

19

Kapitel 3. Inkonsistenzen bei der Beschreibung programmierter Systeme

konsistent bezeichnet, wenn sie die Datenintegrität der Daten bzw. der Daten-bank erhält, wie es Tabeling in [Tabeling 00] (S. 118 ff.) feststellt. Eine konsis-tente Datenhaltung zu ermöglichen, gehört zu den Hauptaufgaben einer Daten-bank. Eine Inkonsistenz tritt bei Verletzung der Datenintegrität auf. Beispielswei-se wenn bei Änderungen von Bankverbindungsdaten die zugehörigen Adress-daten eines Personenstammdatums verloren gehen.

Häufige Verwendung finden die Begriffe Konsistenz bzw. Inkonsistenz in derLogik. Dort ist Inkonsistenz ein Widerspruch zwischen zwei Aussagen. EinerAussage kann immer ein Wahrheitswert zugeordnet werden, so dass sie falschoder wahr sein kann. Das Verständnis des Begriffs Aussage ist im Allgemeinenzweigeteilt. Zum einen wird darunter der Inhalt eines Aussageaktes, zumanderen die Form eines Aussageaktes verstanden. Letztlich kann sich der Wahr-heitswert einer Aussage nur auf den Inhalt beziehen. Bronstein definiert eineAussage als „[...] die gedankliche Widerspiegelung eines Sachverhalts in Formeines Satzes einer natürlichen oder künstlichen Sprache.“ [Bronstein et al. 95] (S.253). Demnach wäre noch nicht Formuliertes, wie z.B. Modelle, im vorhineinvon Konsistenzüberlegungen ausgeschlossen. Ebenso wie die Betrachtung vonGegenständen, die keine Sachverhalte sind. Daher ist für die vorliegende Arbeitdieses Verständnis von Inkonsistenz in der Logik zu eng gefasst, da sich eineAussage dabei stets auf einen Sachverhalt bezieht und bereits eine Formulierungdarstellt.

Im weiteren Verlauf dieser Arbeit soll unter dem Begriff Inkonsistenz derZustand der Unvereinbarkeit zweier in Zusammenhang gebrachter Dinge,von denen mindestens eines abstrakter Natur sein muss, verstanden werden.

Dabei wird davon ausgegangen, dass Inkonsistenz auf der materiell-energetischen Ebene nicht entstehen kann, da die materiell-energetische Weltgegeben ist. Somit sind Konsistenzbetrachtungen zwischen ausschließlich kon-kreten Dingen ausgeschlossen. Ein konkretes und ein abstraktes Ding hingegenkönnen auf Vereinbarkeit geprüft werden. Beispielsweise kann ein (gedachtesund somit abstraktes) Modell mit dieser Welt vereinbar sein oder nicht. Eineandere Möglichkeit der Inkonsistenz besteht zwischen abstrakten Dingen, wiez.B. zwei verschiedenen Modellen. Ein bekanntes Beispiel dafür sind die New-ton’sche und die Einstein’sche Mechanik. Beides sind Modelle, die nicht verein-bar sind, auch wenn die Unterschiede unter bestimmten Voraussetzungen mar-ginal sind: sie vermitteln ein unterschiedliches Verständnis eines Teilbereichs dermateriell-energetischen Welt.

Voraussetzung für die Entdeckung einer Inkonsistenz ist der Akt des Zusam-menbringens von mindestens zwei Dingen, von denen eines abstrakter Natursein muss. Zumeist besteht die Wahl der Dinge sowie die Bezugnahme in derunmittelbaren inhaltlichen Verwandtschaft, wie im Falle der Newton’schen undEinstein’schen Mechanik. Eine andere Möglichkeit diese Dinge miteinanderin Bezug zu setzen, ist sie definitorisch festzulegen, d.h. sie zu fordern. Diesbedeutet zumindest theoretisch, dass alle abstrakten Dinge in Zusammenhanggebracht und Konsistenzbetrachtungen unterzogen werden können. In der

20

3.1. Inkonsistenz

Praxis sollte die Wahl der Dinge aus Zweckmäßigkeitsüberlegungen hervor-gehen. D.h. dass aus dem Wissen um deren Konsistenz ein mittelbarer oderunmittelbarer Nutzen entsteht.

Der Vorgang zwei Dinge in Zusammenhang zu bringen und ihreVereinbarkeit bzw. Unvereinbarkeit festzustellen, soll im folgendenKonsistenzprüfung genannt werden.

Die vorbereitenden Maßnahmen für eine Konsistenzprüfung umfassen die Wahlder zu prüfenden Dinge und die Festlegung des Vereinbarkeitskriteriums. DasVereinbarkeitskriterium bestimmt die Bezugnahme der zu prüfenden Dinge. DasKonsistenzprüfungsergebnis entspricht der Vereinbarkeit oder der Unvereinbar-keit der Dinge gemäß dem Vereinbarkeitskriterium. Bild 3.1 fasst diese Punktegraphisch zusammen.

Konsistenzprüfer

Konsistenz-

prüfungs-

ergebnis

Ding A

(abstrakt)(Bsp.: Einstein'sche Mechanik)

Ding B

(abstrakt oder konkret)(Bsp.: die "Welt")

Wissen um

Zusammenhang

der Dinge A und B

Vereinbarkeits-

kriterium

Bild 3.1: Konsistenzprüfung

3.1.2 Eigenschaften von Inkonsistenz

Nach der Einführung des Begriffs Inkonsistenz, sollen die für diese Arbeit rele-vanten Eigenschaften besprochen werden.

Im folgenden sollen mittels einer Konsistenzprüfung entdeckte Inkonsistenzenals bemerkte Inkonsistenzen bezeichnet werden. Dabei ist sich derjenige, der dieInkonsistenz entdeckt, sich deren Existenz und den dazugehörigen Größen wiedem Vereinbarkeitskriterium bewusst. Davon zu unterscheiden sind unbemerk-te Inkonsistenzen, die zwar existieren aber nicht durch eine Konsistenzprüfungentdeckt wurden, siehe auch Bild 3.2. Prinzipiell sollte immer davon ausgegan-gen werden, dass nicht alle Inkonsistenzen aufgedeckt werden. Gründe für unbe-

21


Inkonsistenz

bemerkte

Inkonsistenz(durch Konsistenzprüfung)

unbemerkte

Inkonsistenz

Bild 3.2: Bemerkte und unbemerkte Inkonsistenz

merkte Inkonsistenzen sind mannigfaltig. Das fehlende Wissen um den Zusam-menhang zweier Dinge ist ein Beispiel dafür. Je mehr Dinge im Rahmen der Be-trachtung herangezogen werden können, desto wahrscheinlicher wird es, dass ei-nige Zusammenhänge nicht mehr berücksichtigt werden. D.h. desto größer wirdder Umfang unbemerkter Inkonsistenzen.

Voraussetzung für das Bemerken von Inkonsistenzen ist ein bestimmtes Inter-esse, das z.B. mit einer Fragestellung oder einem Nutzen einhergeht. Dadurchwerden die zu prüfenden Dinge und deren Zusammenhang identifiziert. Un-terschiedliche Konsistenzprüfer sollten bei gleichen Eingaben das gleiche Resul-tat liefern. Wegen des Umstands, dass unterschiedliche Personen häufig unter-schiedliche Interessen haben, ist davon auszugehen, dass mindestens eine derEingaben unterschiedlich ist. Zur Bewertung von Konsistenzprüfungsergebnis-sen ist es deshalb unerlässlich, die Eingabegrößen zu kennen.

Neben bemerkten und unbemerkten Inkonsistenzen können gewollte und un-gewollte Inkonsistenzen unterschieden werden, siehe auch Bild 3.3. UngewollteInkonsistenzen treten auf, wenn der Zusammenhang zwischen zwei Dingen oderdas Vereinbarkeitskriterium unberücksichtigt blieben, obwohl sie bekannt waren.Solche ungewollte Inkonsistenzen werden auch als Versehen oder Irrtum bezeich-net. Bei gewollten Inkonsistenzen hingegen ist der Zusammenhang oder das Verein-barkeitskriterium bewusst ignoriert worden. Ursachen dafür sind vielfältig undreichen von Hervorhebung eines bestimmten Dinges bis hin zur Überprüfungdes Wissenstands, wie z.B. durch Multiple-Choice-Prüfungen, bei welchen zu ei-ner Frage unterschiedliche Antworten zur Auswahl stehen, wovon mindestenseine korrekt ist. Alternativen sind ebenfalls gewollt inkonsistent. Alternativensind bezüglich eines Ziels konsistent aber untereinander inkonsistent.

Inkonsistenz

ungewollte

Inkonsistenz(Versehen, Irrtum)

gewollte

Inkonsistenz

Bild 3.3: Gewollte und ungewollte Inkonsistenz

Von Versehen zu unterscheiden ist der Begriff Fehler. Bei einem Fehler handeltes sich um eine gewollte oder ungewollte Inkonsistenz. Denn auch bei einem

22

3.1. Inkonsistenz

Fehler existieren immer zwei in Zusammenhang gebrachte Dinge, wovon einesals die Fehlerursache identifiziert wird. Es ist sogar häufig möglich, das fehler-bereinigte Ding anzugeben. Ein Rechtschreibfehler ist ein Beispiel hierfür. DasWissen um die definitorisch festgelegte Schreibweise eines Wortes und die For-derung der Einhaltung dieser Schreibweise wären mit der beobachteten Schreib-weise nicht vereinbar. Es existieren auch Fälle bei denen es nicht trivial ist, dasfehlerverursachende Ding zu identifizieren. Meist liegt die Ursache in einer nichtausreichenden Kenntnis der Zusammenhänge. Im Allgemeinen sind bei einemFehler die Dinge oder der Zusammenhang zwischen den Dingen weitläufig be-kannt. Die Wertung „falsch“ reicht oft aus, um alle Größen zu identifizieren. EineInkonsistenz, bei der die Kenntnis einer Eingangsgröße ausreicht, um aufgrundvon Voraussetzbarem auf die anderen Größen zurückschließen zu können, sol-len im folgenden implizite Inkonsistenz genannt werden. D.h. die weiteren Größensind implizit im Voraussetzbaren vorhanden. Häufig handelt es sich bei etwasals falsch Bezeichnetem um implizite Inkonsistenzen. Gegenteilig dazu soll eineexplizite Inkonsistenz eine Inkonsistenz ausdrücken, bei der alle Größen explizitangegeben werden müssen, da auf sie nicht aus Voraussetzbarem erschlossenwerden können. Fehler sollten nicht als etwas betrachtet werden, das unter al-len Umständen vermieden werden muss. Gerade in Lernphasen sind Fehler bzw.Inkonsistenzen ein unentbehrliches Mittel zum besseren Verständnis, wenn es inkonstruktiver Art und Weise genutzt wird. So können Fehler als Indiz für nichtVerstandenes dienen. Auch im Bereich der Softwareentwicklung wird diese The-se unterstützt. So schreibt Easterbrook„... the most important aspects of inconsis-tency is the learning opportunity it provides.“ [Easterbrook 96] (S. 22). Dort gehtes speziell um die Entwicklung von Methoden und wie Methodenentwickler vonKonsistenzprüfungen profitieren können, um ihre Methoden zu optimieren.

Inkonsistenz

implizite

Inkonsistenzz.B. Fehler

explizite

Inkonsistenz

Bild 3.4: Implizite und Explizite Inkonsistenz

Inkonsistenz zwischen zwei Beschreibungen scheint durch die gewählte Defini-tion zunächst ausgeschlossen. Das eigentliche Interesse gilt aber nicht den Be-schreibungen16 selbst, sondern der von jeder Beschreibung ausgelösten Vorstel-lung. Zwischen den Vorstellungen können Inkonsistenzen im Sinne der Defini-tion bestehen. D.h. bevor die Konsistenz zwischen Beschreibungen getätigt wer-den kann, müssen sie interpretiert werden. Das Ergebnis der Konsistenzprüfungwird anschließend auf die Beschreibungen übertragen. Bild 3.5 verdeutlicht diesgraphisch. Für die Konsistenzprüfung zwischen einer Beschreibung und einemanderen Ding gilt Entsprechendes, d.h. die Beschreibung muss ebenfalls zuvor

16Beschreibungen sind materiell-energetischer Natur.

23


interpretiert werden.

Konsistenzprüfer

Konsistenz-

prüfungs-

ergebnis

Vorstellung A(abstrakt)

Vorstellung B(abstrakt)

Wissen um

Zusammenhang

der Vorstellungen

A und B

Vereinbarkeits-

kriterium

Interpreter für B

Interpreter für ABeschreibung A

(konkret)

Beschreibung B(konkret)

Bild 3.5: Konsistenzprüfung zwischen zwei Beschreibungen

Redundanz wird dabei häufig als Voraussetzung für Inkonsistenzen angesehen.Aber Redundanz selbst hat zunächst nichts mit Inkonsistenz gemein. Denn mitRedundanz bezeichnet man das mehrfach Formulierte einer Information. Dabeikann die Formulierung gleich oder unterschiedlich sein, d.h. die Informationselbst bleibt davon unberührt – sie kann nicht vervielfacht werden – aber sie wirddurch die Formen wiederholt. So ist z.B. der Betrag eines Bankschecks mehrfachin Form von Zahlensymbolen und in ausgeschriebenen Wörtern vermerkt. Un-terscheiden sich die den verschiedenen Formen assoziierten Beträge, so ist strenggenommen keine Redundanz mehr vorhanden. Wie Liu et al. richtig bemerken,kann Redundanz als Quelle für Inkonsistenzen dienen: „One of the most fre-quently occuring inconsistency sources is redudancy [...].“ ([Liu et al. 02], S. 107).Denn eine Änderung einer Formulierung würde den gewollten Zusammenhangzunichte machen. Zur Vermeidung von Inkonsistenz müssten alle weiteren For-mulierung entsprechend angepasst werden.

Das Vereinbarkeitskriterium kann vom inhaltlichen Zusammenhang der Dingebestimmt sein. Sobald dieser inhaltliche Zusammenhang nicht existiert, wirdhäufig ein solcher definitorisch festgelegt. Dies können Gesetze, Vorschriften,Regeln oder die einfache Möglichkeit einer Abbildung (engl. mapping) sein. Sokann der Zusammenhang zwischen zwei Dingen sein, dass Einer Teil des Ande-ren ist. Man denke an die Rechtschreibüberprüfungskomponente eines Textver-arbeitungssystems. Es existieren viele unterschiedliche Möglichkeiten eine solcheAbbildung zu realisieren. Weitverbreitet sind beispielsweise Tabellen mit konkre-ten Belegungen für die Abbildungsvorschrift. Es finden sich aber auch Namens-konventionen. In der Softwareentwicklung werden Abbildungen als Verfolgbar-keit (engl. Traceability) (vgl. [Gieszl 92]) bezeichnet. Dabei geht es um die Her-vorhebung der Zusammenhänge zwischen verschiedenen Modellelementen.

24

3.1. Inkonsistenz

Im Zusammenhang mit Konsistenzbetrachtungen zwischen zwei Beschreibun-gen wird auch der Bedarf nach der Unterscheidung von interner und externerKonsistenz deutlich. Beispielsweise lässt sich nach der inneren Konsistenz einerVorstellung ausgehend von deren Beschreibung fragen. Es ist möglich, dass inder Beschreibung nicht vereinbare Dinge identifiziert werden. Eine interne In-konsistenz ist eine Inkonsistenz zwischen Dingen im Sinne der Inkonsistenzde-finition, die zu einer definiert abgegrenzten Menge gehören. Eine solche Mengekann anhand beliebiger Kriterien gegenüber anderen Dingen abgegrenzt wer-den, wie z.B. die innerhalb einer Beschreibung identifizierten Dinge. Eine Inkon-sistenz zwischen einem Ding innerhalb und außerhalb einer solchen Menge sollals externe Inkonsistenz bezeichnet werden, siehe auch Bild 3.6. Dies deckt sichmit der Definition von Zuck, der als Kriterium für die Abgrenzung die idealenSystemmodelle nutzt (vgl. [Zuck 90], S. 24 ff.). Die interne Konsistenz beziehtsich bei Zuck auf die Systemmodelle, wohingegen sich die externe Konsistenzzwischen Systemmodellen und der Beschreibung des Systems wiederfindet. Einanderes Beispiel kann eine Konversation zwischen zwei Menschen sein, die un-terschiedlicher Meinung sind. Es besteht also externe Inkonsistenz, obwohl ihreStandpunkte intern konsistent sein können.

Inkonsistenz

interne

Inkonsistenzz.B. innerhalb von Systemmodellen

externe

Inkonsistenz

Bild 3.6: interne und externe Inkonsistenz

Die Konsistenz zwischen zwei Dingen ist unveränderlich. Das Ergebnis einerKonsistenzprüfung ist bei gleichen Eingaben stets identisch. Da die Dinge – dieEingaben – veränderlich sein können, ist eine Änderung der Konsistenz ebenfallsmöglich. D.h. die Konsistenz oder Inkonsistenz trifft für einen Zeitpunkt zu, fürandere Zeitpunkte kann sich aufgrund der Eingabeänderung auch die Konsistenzändern. Dabei gibt es Zeitabschnitte, die für Konsistenzbetrachtungen irrelevantsind. Diese Abschnitte sollen im Folgenden Übergangsintervalle genannt wer-den. So ist z.B. jedes Wort, dessen Buchstaben sequentiell aufgeschrieben werden,wie bei einem Textverarbeitungssystem, ab Beginn der Eingabe des ersten Buch-stabens bis vor Abschluss der Eingabe des letzten Buchstabens inkonsistent mitder definierten Schreibweise.

In Zusammenhang mit Konsistenz bzw. Inkonsistenz fällt immer wieder der Be-griff der Vollständigkeit. Die Eigenschaften Konsistenz und Vollständigkeit impli-zieren einander nicht. So ist leicht ersichtlich, dass durch die Hinzunahme ei-nes Dinges zu einer Menge von untereinander konsistenten Dingen zum Zweckeder Vollständigkeit Inkonsistenzen auftreten können. Im Bereich formaler Syste-me konnte Gödel zeigen, dass jedes hinreichend mächtige System nicht zugleichvollständig und konsistent sein kann (vgl. [Gödel 31]). Im Softwarebereich, im

25


Speziellen auf dem Gebiet der Modellierung, wird der Zusammenhang zwischenVollständigkeit und Konsistenz ebenfalls hervorgehoben: „[...], we consider in-completeness to be strongly related to inconsistency.“ ([Lange et al. 03], S.26). Soist bei Konsistenzbetrachtungen stets der Aspekt der Vollständigkeit mit zu be-rücksichtigen.

Inkonsistenz kann auch von der Richtung abhängig sein. Eine Inkonsistenz be-trifft immer zwei Dinge A und B. Der triviale Fall besteht bei Konsistenzbetrach-tungen zwischen den selben Dingen. Diese sind stets konsistent zueinander. Häu-fig besteht auch eine Inkonsistenz zwischen B und A, falls A zu B inkonsistentist. Es sind Fälle möglich, bei denen das nicht gilt. Das ist beispielsweise der Fall,wenn das Vereinbarkeitskriterium funktionalen Charakter besitzt. So lässt sicheine verschlüsselte Nachricht mit dem entsprechenden Schlüssel entschlüsselnaber nicht umgekehrt.

Nicht alle Inkonsistenzen sind gleichermaßen bedeutsam. Es können fast immerKriterien angegeben werden, die die Inkonsistenzen in eine Ordnung bringen. Eskann nach untersuchten Dingen, Typ der Inkonsistenz, Verursacher der Inkonsis-tenz etc. gewertet werden. Beispielsweise kann ein bestimmter Typ Inkonsistenz„Rechtschreibfehler“ generell als unkritischer als einer anderer gesehen werden.Es ist möglich, dass ein Rechtschreibfehler bei einem Deutschlehrer als schwer-wiegender eingestuft wird als bei einem Schüler. In der Regel wird auch einRechtschreibfehler eines „schwierigen“ Wortes als weniger gravierend betrach-tet. Die Bedeutsamkeit von Inkonsistenz sollte immer berücksichtigt werden. Sierichtet sich in der Regel nach der Zweckmäßigkeit der Konsistenzprüfung. EinIndiz für Bedeutsamkeit kann auch der Grad der Vereinbarkeit der Dinge darstel-len. Je geringer der Grad der Vereinbarkeit, desto geringer die Bedeutsamkeit. Solassen sich beispielsweise „der Eiffelturm zu Paris wurde im Jahr 1652 erbaut“und “der Eiffelturm zu Paris wurde im Jahr 1889 erbaut“ einfacher und besserauf Vereinbarkeit prüfen als „Franz spielt gerne Schach mit Peter“ und „Petergewinnt beim Schachspielen immer gegen Franz“.

Es bleibt festzuhalten, dass Inkonsistenz oder Fehler im Allgemeinen nicht etwasist, das auf jeden Fall zu vermeiden ist, sondern ein nützliches und notwendigesMittel zur Hinterfragung und somit Voraussetzung für den Wissensfortschritt.

3.1.3 Konsistenzprüfung

Nach der Besprechung der wichtigsten Eigenschaften von Inkonsistenz und derVorstellung der Konsistenzprüfung soll diese im Folgenden näher untersuchtwerden.

Es können zwei prinzipiell unterschiedliche Arten von Konsistenzprüfungen un-terschieden werden:

• formale Konsistenzprüfungen und

• nicht formale Konsistenzprüfungen.

26

3.1. Inkonsistenz

Bei einer formalen Konsistenzprüfung sind alle Eingangsgrößen Formen, die be-stimmten Vorschriften genügen. Zusammenhänge und Vereinbarkeitskriterienwerden häufig als Konsistenzregeln (engl. consistency rules oder consistencychecking rules) oder Konsistenzbedingungen (engl. consistency constraints) be-zeichnet. Das Ergebnis der Konsistenzprüfung ist ebenfalls eine Form. All dieseFormen müssen interpretiert werden können, damit ein Nutzen entstehen kann.Formale Konsistenzprüfungen sind von besonderem Interesse, da sie rechner-gestützt durchgeführt werden können. Dadurch lässt sich eine große Menge anKonsistenzprüfungen, teilweise bedingt durch eine hohe Anzahl zu prüfenderFormen, automatisiert durchführen. Menschen führen häufig Konsistenzprüfun-gen durch, beispielsweise bei der Wissensaneignung. Der Mensch versucht neuesWissen mit bereits Bekanntem zu vereinbaren. Dabei löst er nicht notwendiger-weise alle Inkonsistenzen auf, d.h. es existieren unbemerkte Inkonsistenzen. Diemeisten Konsistenzprüfungen dieser Art sind nicht formal. Weder die Wahl derDinge, das Vereinbarkeitskriterium noch die Abgrenzungskriterien der Dinge un-terliegen formalen Regeln oder sind selbst Formen.

Die Zusammenhänge zwischen Dingen können komplex sein, so dass mehrereKonsistenzprüfungen durchgeführt werden müssen, um die Vereinbarkeit derinteressierenden Dinge zu bestimmen. Die Abhängigkeiten solcher Konsistenz-prüfungen sollen Konsistenzkette genannt werden. Jede einzelne Konsistenzprü-fung in einer Konsistenzkette muss erfolgreich17 abgeschlossen werden, damitdas Gesamte als vereinbar angesehen werden kann. Eine Konsistenzkette kannim einfachsten Fall „geradlinig“ sein. Eine Konsistenzprüfung ist dann kausalvon genau einer anderen abhängig. Eine Konsistenzkette kann aber auch entspre-chend der Art und der Komplexität der Zusammenhänge der Dinge strukturiertsein. Inkonsistenzen, die innerhalb einer einzigen Konsistenzprüfung aufgedecktwerden können, sollen direkte Inkonsistenzen genannt werden. Indirekte Inkonsis-tenzen dagegen benötigen mehr als eine Konsistenzprüfung.

Falls eine Konsistenzprüfung aus mehreren einzelnen Konsistenzprüfungen be-steht, z.B. bei einer Konsistenzkette oder bei einem großen Repertoire an Konsis-tenzregeln, können zwei Arten von Konsistenzprüfungen durchgeführt werden:

• vollständige Konsistenzprüfung

• partielle Konsistenzprüfung

Die vollständige Konsistenzprüfung bezieht sich hierbei auf den vollen, definiertenUmfang der Konsistenzprüfung, z.B die komplette Konsistenzkette. Bei der par-tiellen Konsistenzprüfung wird nur ein festgelegter Teil der vollständigen Konsis-tenzprüfung durchgeführt. Dies stellt vor allem eine Optimierungsmöglichkeitdar. Aufwandsreduktion oder Konzentration auf ein bestimmtes Merkmal sindBeispiele hierfür.

17Eine einzelne solche Konsistenzprüfung kann abhängig von der betrachteten Konsistenzkettezum Ergebnis „konsistent“ oder „inkonsistent“ führen.

27


Um die Vereinbarkeit zweier Dinge zu prüfen, kann neben den Dingen, dem Zu-sammenhang und dem Vereinbarkeitskriterium, nach der Frequenz und der Dau-er von Konsistenzprüfungen gefragt werden. Dies bestimmt mit der Anzahl derzu prüfenden Dinge die Skalierbarkeit von Konsistenzprüfungen. Die Durchfüh-rung einer Konsistenzprüfung ist ein Prozess, der von mindestens einem Akteurdurchgeführt werden muss. Dieser Vorgang wird häufig als Prüfen oder Testenbezeichnet. Falls Daten daran beteiligt sind, zählt deren Aufarbeitung als Vorbe-reitung der Konsistenzprüfung dazu. Durch geschickte Aufarbeitung und Traver-sierung der Daten besteht Einsparungspotential. Beispielsweise könnten bei einerTraversierung der selben Daten parallel mehrere Konsistenzprüfungen durch-geführt werden. Wenn der Prozess der Durchführung einer Konsistenzprüfungkomplex ist, kann er unter Umständen auf mehrere Konsistenzprüfer aufgeteiltwerden. Eine höhere Anzahl zu prüfender Dinge muss nicht unbedingt einen li-nearen Aufwandsanstieg bedeuten.

Die Frequenz und der Zeitpunkt für den Beginn einer Konsistenzprüfung sindweitere interessante Größen. Bei nicht formalen Konsistenzprüfungen könnenkeine exakten Aussagen dazu gemacht werden. Es kann davon ausgegangenwerden, dass Menschen sehr häufig Konsistenzprüfungen durchführen. Vor al-lem wenn man sich mit einer bestimmten Sache intensiv auseinandersetzt, wer-den viele Eigenschaften und Aspekte der Sache zusammengeführt und auf Ver-einbarkeit überprüft. Beispielsweise fällt einem Menschen beim Lesen eines Bu-ches relativ schnell auf, wenn einige Seiten fehlen. Zur Aufdeckung eines solchenFehlers sind Konsistenzprüfungen notwendig. Auch bei Modellbildung werdenhäufig Konsistenzprüfungen durchgeführt. Üblicherweise werden bei der Expli-zitmachung der Modelle, d.h. wenn die Modelle formuliert werden, immer wie-der Inkonsistenzen aufgespürt. Im Bereich des Formalen sind die Zeitpunkte so-wie die Frequenz der Konsistenzprüfungen festgelegt. So prüft z.B. ein Prozessorvor jeder Division, ob der Dividend sich von Null unterscheidet. Andererseits fin-det eine Konsistenzprüfung eines Dateisystems bei Betriebssystemen in der Regelerst nach entsprechender Aufforderung statt. Eine bei jedem atomaren18 Bearbei-tungsschritt ständig durchgeführte Konsistenzprüfung soll im folgenden Online-Konsistenzprüfung genannt werden. Die Division beim Prozessor oder das Leseneines Buchs sind Beispiele hierfür. Das Gegenstück zu Online Konsistenzprüfun-gen sind Offline-Konsistenzprüfungen. Dabei wird nicht bei jedem Bearbeitungs-schritt eine Konsistenzprüfung durchgeführt. Üblicherweise werden sie bei be-stimmten Bearbeitungsschritten oder nach expliziter Aufforderung angestoßen.

Sind Inkonsistenzen erst einmal aufgespürt, stellt sich die Frage nach der adäqua-ten Reaktion. Auf eine Konsistenzprüfung sollte immer eine Bewertungsphasefolgen, in der abhängig vom Zeitpunkt, der Anzahl und der Klasse der Konsis-tenzprüfung die Bedeutsamkeit der Inkonsistenz bestimmt wird. Damit lässt sicheine passende Reaktion auf die entdeckte Inkonsistenz wählen. Es ist selbstver-ständlich, dass es keine speziellen Reaktionen auf unentdeckte Inkonsistenzengeben kann. Prinzipiell sind folgende Reaktionen auf Inkonsistenzen möglich:

18Ein atomarer Bearbeitungsschritt soll hierbei nicht als absolut definierte Grundgröße verstan-den werden, sondern soll vom Kontext abhängig sein.

28

3.1. Inkonsistenz

Konsistenzprüfung

Formale

Konsistenzprüfung

nicht formale

Konsistenzprüfung

Online

Konsistenzprüfung

Offline

Konsistenzprüfung

Bild 3.7: Übersicht Konsistenzprüfungen

• Korrigieren,

• Verbessern,

• Tolerieren und

• Ignorieren.

Das Korrigieren von Inkonsistenzen stellt die naheliegendste Option dar. Eine In-konsistenz kann nach ihrer Entdeckung direkt oder zu einem späteren Zeitpunktaufgelöst werden. Voraussetzung für die Korrektur einer Inkonsistenz ist, de-ren Ursache zu kennen. Prinzipiell kommt eines der geprüften Dinge dafür inFrage. Andere Quellen sind der Zusammenhang und das Vereinbarkeitskriteri-um. Bei der Entdeckung einer Inkonsistenz muss die Ursache nicht unbedingtbekannt sein. Der Aufwand für die Korrektur einer Inkonsistenz variiert stark,da sie von vielen Faktoren abhängt. So kann der Aufwand für die Korrektur ei-nes Rechtschreibfehlers minimal sein, z.B. für den Autor bei der Erstellung einesSchriftstücks. Wenn das Schriftstück hingegen bereits in großen Stückzahlen ver-legt wurde, ist die Korrektur eines Rechtschreibfehlers in allen Exemplaren fastunmöglich. Für das Auflösen einer Inkonsistenz zwischen Modellen bzw. Vorstel-lungen zweier Personen kann der Aufwand erheblich sein. Voraussetzung dafürist eine Bereitschaft zur Änderung der Modelle bzw. Vorstellungen.

Eine Alternative zur Korrektur von Inkonsistenzen ist ihre Bedeutsamkeit durchVerbesserungen abzuschwächen. Die Verbesserung kann aufgrund des geringerenAufwands der Korrektur vorgezogen werden. Ein einfacher Hinweis, der eineInkonsistenz konstatiert oder durch zusätzliche Erläuterungen für ein besseresVerständnis sorgt, ist ein Beispiel für eine Verbesserung. Verbesserte Inkonsisten-zen bleiben aber Inkonsistenzen und würden bei darauf folgenden Konsistenz-prüfungen wieder identifiziert. Die Verbesserung von Inkonsistenzen kann einennotwendigen Schritt für das Tolerieren oder Ignorieren darstellen.

Beim Tolerieren von Inkonsistenzen findet keine Verbesserung oder Korrekturstatt. Die tolerierten Inkonsistenzen würden wie verbesserte Inkonsistenzen auchin darauf folgenden Konsistenzprüfungen aufgedeckt werden. Bei dieser Art der

29


Reaktion wurde sich bewusst dafür entschieden, die Inkonsistenz zu belassen.Dies geschieht meist nach Abwägung der Bedeutsamkeit und des Aufwands füreine Verbesserung bzw. für die Korrektur einer Inkonsistenz. Im Gegensatz zuignorierten Inkonsistenzen werden tolerierte Inkonsistenzen weiter berücksich-tigt und nicht von weiteren Betrachtungen ausgeschlossen. Nuseibeh et al. unter-scheiden in [Nuseibeh et al. 00] ähnliche Reaktionen auf Inkonsistenzen, wobeidas Tolerieren von Inkonsistenzen immer zur einer Auflösung oder einer Ver-besserung führt. Da die Autoren von einer rechnergestützten Konsistenzprüfungausgehen, führen sie die Änderung der Konsistenzregeln zum Auflösen von In-konsistenzen als besondere Art des Tolerierens auf.

Änderungen der Rahmenbedingungen beeinflussen die Bewertung der Inkon-sistenz und somit auch die Wahl der angemessenen Reaktion. Eine vormalsals gravierend angesehene Inkonsistenz, kann nach einer solchen Änderungaufgelöst sein oder als nicht mehr relevant betrachtet werden. Es ist wichtigfestzuhalten, dass das Aufdecken einer Inkonsistenz, seine Bewertung unddie Reaktion darauf stark kontextabhängig sind. Teilweise genügen verschie-dene Auffassungen zweier Konsistenzprüfer, um voneinander abweichendeBewertungen zu erreichen. Ein Beispiel für eine solche Änderung der Rahmen-bedingungen ist die Einführung einer Priorisierung.

3.1.4 Klassifizierung von Inkonsistenzen

Im Folgenden werden drei Klassen von Inkonsistenzen vorgestellt, die im weite-ren Verlauf der vorliegenden Arbeit eine besondere Rolle innehaben. Diese dreiKlassen sollen als Basis für die weiteren Überlegungen dienen. Für den Bereichder Beschreibung programmierter Systeme stellen sie die grundlegend zu be-rücksichtigenden Klassen dar. Inwiefern eine Inkonsistenz toleriert werden kannoder nicht, hängt mitunter davon ab, welcher Klasse die entdeckte Inkonsistenzangehört.

Eine Übersicht der nachfolgend erläuterten Klassen von Inkonsistenz zeigt Bild3.8.

vorgabenbedingte Inkonsistenz

prozessbedingte

Inkonsistenz

methodenbedingte

Inkonsistenz

notationelle

Inkonsistenz

semantische

Inkonsistenz

syntaktische

Inkonsistenz

werkzeugbedingte

Inkonsistenz

Modellinkonsistenz

interne Modell-

inkonsistenz

externe Modell-

inkonsistenz

Inkonsistenz im System

Verhaltens-

inkonsistenzDateninkonsistenz

Inkonsistenz

Bild 3.8: Übersicht über die Inkonsistenzklassen

30

3.1. Inkonsistenz

3.1.4.1 Inkonsistenzen im System

Inkonsistenzen im System stellen die Ursache für Inkonsistenzen des(informationellen) Systems dar. Sie führen also zu Inkonsistenzen imSystemverhalten, die auch als Fehlverhalten (engl. failure) des Systemsbezeichnet werden.

[Gray, Reuter 93] definieren Fehlverhalten wie folgt: „A failure occurs when theobserved behavior deviates from the specified behavior.“ (S. 98). Nicht jede In-konsistenz im System führt zwangsläufig zu einem Fehlverhalten. Manche habenkeine bemerkbaren Auswirkungen bzw. werden nicht als Inkonsistenzen wahr-genommen. Die meisten jedoch führen zu Fehlverhalten des Systems. Einige kön-nen gravierende Ausmaße annehmen, wie z.B. die komplette Zerstörung des pro-grammierten Systems inklusive Datenverlust.

Innerhalb der Klasse Inkonsistenzen im System kann zwischen Daten- und Ver-haltensinkonsistenzen unterschieden werden. Verhalten zeichnet sich durch diezeitliche Reihenfolge des Erscheinens bzw. Verschwindens von Eingabe- undAusgabedaten aus. Das Fehlverhalten selbst ist eine Verhaltensinkonsistenz. EineVerhaltensinkonsistenz tritt demnach auf, sobald das erwartete vom tatsächli-chen Verhalten abweicht. Dateninkonsistenzen (vgl. [Abramowicz et al. 95]) findentraditionell bei Datenbanksystemen starke Berücksichtigung. Innerhalb von Da-tenbanksystemen werden prinzipiell keine Dateninkonsistenzen geduldet. Diesspiegelt auch die ACID-Eigenschaft19 für Transaktionen wieder. Ein Beispiel fürDateninkonsistenz sind negative Werte für Größenangaben. Häufig bedingenVerhaltens- und Dateninkonsistenz einander. Eine Dateninkonsistenz kann zu ei-ner Verhaltensinkonsistenz führen, da sich die Folgezustände und somit das wei-tere Verhalten anhand der Ein- und Ausgabedaten ergeben. Andererseits könnenaufgrund eines fehlerhaften Verhaltens Daten nicht korrekt verarbeitet bzw. wei-tergegeben werden. Häufig müssen die Ursachen der Inkonsistenz untersuchtwerden, um eine genaue Unterscheidung zwischen Verhaltens- und Dateninkon-sistenz treffen zu können. Bei programmierten Systemen werden diese Ursachenals Softwarefehler (engl. fault oder bug) bezeichnet. Softwarefehler werden in derRegel durch Programmierer eingeführt. Ihnen unterlaufen (ungewollt) Fehler beider Formulierung des Quelltextes. Das nachfolgende Bild 3.9 fasst dies noch ein-mal graphisch zusammen.

Auf bekannte Inkonsistenzen im System können programmierte Systeme in derRegel gut reagieren. Es sind verschiedene Maßnahmen dafür denkbar. So wirdüblicherweise versucht, Systeme möglichst robust gegenüber Dateninkonsisten-zen zu realisieren. Man denke an das Beispiel mit den negativen Größenanga-ben. Bei Änderungen einer Größenangabe könnte z.B. nach oder während einerEingabe überprüft werden, ob sie nicht negativ ist. Solche Maßnahmen als Sys-tembestandteil würden Inkonsistenzen im System erst gar nicht zulassen, dennstreng genommen würde sich das System regulär verhalten bzw. regulär mit denDaten umgehen. Solche Inkonsistenzen würden nicht zugelassen oder nur tem-

19ACID steht für Atomicity, Consistency, Isolation und Durability. Diese Eigenschaften zeich-nen eine Transaktion aus, vgl. [Gray, Reuter 93] S. 166 ff.

31


Inkonsistenz

des Systems

(Fehlverhalten)

Inkonsistenz im System

Verhaltens-

inkonsistenz

Daten-

inkonsistenz

ist

Ursache von

ist

Ursache von

Softwarefehler

(Bug)

Bild 3.9: Inkonsistenzen im System und einige Zusammenhänge

porär geduldet werden. Die anderen bekannten und unbekannten Inkonsisten-zen im System, die nicht durch Maßnahmen behandelt werden, können daher zuFehlverhalten des Systems führen.

Mit Inkonsistenzen im System sind keine Abweichungen zwischen im QuelltextFormulierten und Ausführung des Programms zu verstehen. Es sei denn das un-tersuchte System wäre ein Compiler, Abwickler oder Interpreter. Hier wird le-diglich auf das durch die Ausführung des Programms entstandene System ein-gegangen. D.h. die Inkonsistenzen im System sind Abweichungen zwischen imSystem tatsächlichen vorzufindenden Sachverhalten und erwarteten Sachverhal-ten. Die erwarteten Sachverhalte sind nicht direkt aus dem Quelltext abzuleiten,da dafür zusätzliche Informationen aus anderen Quellen benötigt werden. Anfor-derungen und somit auch die Wünsche der Kunden, das Domänenwissen sowiedie Rationale (vgl. [Yu, Mylopoulos 94]) sind dafür die Hauptquellen.

Prinzipiell kann das Erstellen von Programmen bzw. anderen Dokumenten selbstals informationelles System angesehen werden, in dem Inkonsistenzen auftretenkönnen. Akteure wie z.B. Software-Architekt, Projekt Manager, Software Desi-gner und Programmierer verarbeiten und tauschen Informationen, meist in Formvon Dokumenten, aus. Das dabei erstellte programmierte System stellt das Er-gebnis bzw. ein Teilergebnis dieses informationellen Systems dar. Das program-mierte System und das erzeugende informationelle System sind deshalb nicht zuverwechseln. Ein weiterer Unterschied ist, dass bei diesem informationellen Sys-tem die Kommunikation zwischen Menschen geschieht, d.h. nicht auf formaleMittel beschränkt ist.

32

3.1. Inkonsistenz

3.1.4.2 Vorgabenbedingte Inkonsistenzen

Vorgabenbedingte Inkonsistenzen grenzen sich gegenüber Inkonsistenzen imSystem wie folgt ab: sie treten nicht im programmierten System selbst oder alsFehlverhalten des Systems auf, sondern bei der Vorbereitung und währendder Erstellung der dafür benötigten Software. Es geht um die Einhaltungbestimmter Vorgaben, die bei der Entwicklung eines programmierten Systemsimmer anzutreffen sind.

Vorgaben sind für die Entwicklung komplexer Systeme in der Regel umfangrei-cher als für einfachere Systeme. Beispiele für solche Vorgaben sind ein bestimm-ter Umgang mit Werkzeugen, bestimmte Strukturierung und Layout von Quell-text(en), Arbeitsabläufe. In Theorie und Praxis existiert eine reiche Spannweite anVorgaben. Die grundlegende Funktionalität eines programmierten Systems wirdnicht notwendigerweise durch solche Vorgaben stark verbessert. Vorgaben ha-ben in anderen Bereichen Vorteile, wie z.B. eine Einigung auf eine einheitlicheSprache, verständlichere und leichter wartbare Quelltexte und das Vorhanden-sein bestimmter Dokumente. Im Folgenden werden bestimmte vorgabenbeding-te Inkonsistenzen näher beschrieben.

Entwicklungsprozesse, kurz Prozesse20, bilden einen generellen Rahmen für dieEntwicklung eines programmierten Systems. Ein Prozessmodell definiert eineVielzahl an Vorgaben und stellt häufig selbst ein komplexes Gebilde dar. DasErgebnis eines Prozesses ist das programmierte System bzw. die entsprechendeSoftware dazu. Laut Kruchten hat ein Prozess vier Aufgaben (vgl. [Kruchten 04],S. 15):

1. Hilfestellungen zur Koordinierung von Aktivitäten innerhalb einer Ent-wicklungsmannschaft bereitstellen.

2. Festlegen welche und wann Beschreibungsteile erstellt werden sollten.

3. Aufgaben Einzelner und der Entwicklungsmannschaft festlegen.

4. Kriterien zur Überwachung und Messung von Ergebnissen und Aktivitätenliefern.

Der Rational Unified Process (RUP), ein bekanntes und vielgenutztes Prozess-modell, definiert beispielsweise über 80 Artefakttypen (Typen von Beschrei-bungsteilen), über 30 unterschiedliche Rollen und entsprechend viele Aktivi-täten, Workflows und Disciplines. Jedes allgemein definierte Prozessmodell,wie der RUP, wird in der Regel an die lokalen Bedürfnisse und Anforderun-gen angepasst. Prozessbedingte Inkonsistenzen ergeben sich durch Abweichungendes tatsächlich Durchgeführten von dem durch den Prozess Vorgeschriebenen.Die Nicht-Einhaltung des Workflows durch eine verfrühte, verspätete oder ei-ne nicht durchgeführte Aktion wäre ein Beispiel für eine solche Inkonsistenz.

20Der Begriff Prozess wird an dieser Stelle nicht als Struktur temporal geordneter Ereignisseverstanden, sondern wie im Software Engineering als Entwicklungsprozess, einer Menge vorge-gebener Schritte zur Herstellung von Softwareprodukten, verwendet.

33


Nach [Sommerville et al. 99] lässt sich eine prozessbedingte Inkonsistenz auchals das Erreichen des Gleichen mittels unterschiedlicher Herangehensweisen de-finieren. Unter der Voraussetzung, dass unter dem Begriff Prozessmodell bzw.Prozessbeschreibung nicht eine Vorgabe für Handlungen, sondern, die tatsächli-chen Handlungen verstanden werden. Da sich Inkonsistenzen zwischen den Pro-zessmodellen bzw. den Prozessbeschreibungen aufgrund dieser Definition nichtausschließen lassen, soll im Rahmen dieser Arbeit diese zweite Möglichkeit desVerständnisses von prozessbedingten Inkonsistenzen nicht genutzt werden.

Bei Beschreibungen von Prozessmodellen werden nicht immer Aussagen übereinzusetzende Methoden gemacht, um die Prozessmodelle unabhängig von ak-tuellen Methodenentwicklungen zu halten. Dennoch werden innerhalb gelebterProzesse Methoden analysiert, ausgewählt und angewendet. Die Begriffe Me-thodik bzw. Methodologie sind vom Begriff Methode zu unterscheiden. Sie stel-len übergeordnete Begriffe dar. Für eine weiterführende Behandlung dieser Be-griffe siehe auch [Löhr-Richter 93]. Eine Methode stellt im Rahmen der vorlie-genden Arbeit ein Verfahren dar, das als Regelwerk Hilfestellung für bestimm-te Entwurfsphasen gibt. Ergebnisse von Methoden sind Beschreibungen. Metho-denbedingte Inkonsistenzen treten bei Verstößen gegen solche Regelwerke auf. Einbekanntes Beispiel für eine Methode ist SA (engl. Structured Analysis), siehe[DeMarco 78]. Innerhalb dieser Methode ist ein Beispiel für eine Methodenbe-dingte Inkonsistenz die Gleichheit von Eingang und Ausgang eines Prozesses21.Dies ist bei SA nicht zulässig, da ein Prozess seine Eingangsdaten verarbeitenund verändern muss.

Ergebnis einer angewendeten Methode ist eine Beschreibung. Methoden definie-ren daher die zu nutzenden Notationen oder verweisen auf bereits Existierende.Beim Vorgang des Erstellens der Beschreibung kann gegen die zu nutzende No-tation verstoßen werden. Solche Verstöße sind notationelle Inkonsistenzen. Sie kön-nen weiter in syntaktische Inkonsistenzen und semantische Inkonsistenzen unterteiltwerden. Beispiele für syntaktische Inkonsistenzen sind die Nichteinhaltung derBipartitheit bei Petrinetzen oder Rechtschreibfehler in Textpassagen. Zu einer se-mantischen Inkonsistenz führt beispielsweise die Verwendung eines unbekann-ten Symbols.

Werkzeuge werden fast immer eingesetzt, um die Beteiligten bei Ihrer Arbeit imRahmen der Prozesse und der Methoden zu unterstützen. Die Werkzeuge selbst,häufig selbst programmierte Systeme, definieren ihrerseits eine bestimmte Bedie-nung. Diese ist häufig an Prozesse bzw. an Methoden oder an Abschnitte aus denProzessen oder Methoden angelehnt. Die Beschränkung auf eine bestimmte Be-dienung trifft auch zu, wenn die Werkzeuge allgemeiner einsetzbar sind. Werk-zeugbedingte Inkonsistenzen ergeben sich unter anderem aus der Fehlbedienungoder der Fehlkonfiguration der Werkzeuge.

Bild 3.10 zeigt eine Übersicht der vorgestellten vorgabenbedingten Inkonsisten-zen.

Es bleibt festzuhalten, dass bei der Entwicklung eines programmierten Systems

21Prozess ist hierbei im Sinne der SA zu verstehen.

34

3.1. Inkonsistenz

vorgabenbedingte Inkonsistenz

prozessbedingte

Inkonsistenz

methodenbedingte

Inkonsistenz

notationelle

Inkonsistenz

semantische

Inkonsistenz

syntaktische

Inkonsistenz

werkzeugbedingte

Inkonsistenz

Bild 3.10: Übersicht vorgabenbedingte Inkonsistenzen

eine ganze Reihe von teils expliziten, teils impliziten Vorgaben existieren. Mandenke an gesetzliche Vorgaben die Sicherheit und den Datenschutz betreffendoder an Vorgaben, die durch den Einsatz bestimmter Technologien zustandekommen. An dieser Stelle wurden nur einige wenige herausgegriffen, die im wei-teren Verlauf dieser Arbeit Relevanz haben.

3.1.4.3 Modellinkonsistenzen

Unter Modellinkonsistenzen sollen alle Inkonsistenzen fallen, die den Inhalt –die Bedeutung bzw. den Sinn und Zweck von Modellen – betreffen.Modellinkonsistenzen können innerhalb eines Modells (interneModellinkonsistenzen) oder zwischen Modellen (externe Modellinkonsistenzen)auftreten, siehe auch Bild 3.11.

Zum Beispiel wäre die Zuordnung von immer genau einem Passagier zu einemPassagierflugzeug in einem Systemmodell inkonsistent zum Domänenmodell. Eserlaubt eine Zuordnung von mehreren Passagieren zu einem Passagierflugzeug.Dabei kann das Systemmodell intern konsistent sein. Das Systemmodell wärenur in einigen Ausnahmefällen, wenn tatsächlich nur ein Passagier zugeordnetist, konsistent mit dem Domänenmodell. Modellinkonsistenzen müssen von For-men losgelöst betrachtbar sein. Beispielsweise gehört die kreisförmige Darstel-lung von Modellelementen eines bestimmten Typs zum Bereich der Vorgaben.Abweichungen von dieser Darstellung sind vorgabenbedingte Inkonsistenzenund keine Modellinkonsistenzen.

Modellinkonsistenz

interne Modellinkonsistenz(innerhalb eines Modells)

externe Modellinkonsistenz(zwischen Modellen)

Bild 3.11: Übersicht Modellinkonsistenzen

Modellinkonsistenzen können nur von Menschen aufgedeckt werden, denn nur

35


der Mensch ist in der Lage Modelle zu begreifen. Dies ist die Voraussetzung, umdie Zusammenhänge zwischen Modellen bzw. innerhalb eines Modells sowie dieVereinbarkeitskriterien zu erkennen und folglich auf Vereinbarkeit zu prüfen. DerMensch prüft Modelle in der Regel immer auf inhaltliche Inkonsistenzen. Hier-bei wird davon ausgegangen, dass der Mensch über eine Hierarchie von Mo-dellen verfügt (siehe auch [Bungert 98]), zu denen er ein Modell auf inhaltlicheInkonsistenz prüft. Ein Beispiel hierfür ist das Modell seiner direkten räumlichenUmgebung mit dem er sich sicheren Schrittes bewegen kann. Ein dazugehörigesModell umfasst unter anderem das Wissen um eine Tür und die Notwendigkeiteiner geöffneten Tür, um in einen anderen Raum zu gelangen.

Modellinkonsistenzen lassen sich in der Regel argumentativ begründen, z.B.durch Erfahrungen oder Domänenwissen. So lassen sich beispielsweise bei auf-tragsbearbeitenden Servern unterschiedliche Lösungen finden, die für bestimmteAnwendungsfälle besser geeignet sind als andere (siehe dazu auch [Gröne 04], S.86 ff.). Modellinkonsistenzen können auch durch fehlende Informationen bzw.fehlende Modelle, welche für das Verständnis notwendig sind, hervorgerufenwerden. Auch führen unklare Begriffe bzw. die fehlende Vertrautheit mit Begrif-fen häufig zu Modellinkonsistenzen. Ein Beispiel hierfür ist die unterschiedlicheAuffassung des Begriffs Stoff in der Alchemie und der heutigen Chemie.

Modellinkonsistenzen stellen die bedeutsamste der hier vorgestellten Klassenvon Inkonsistenzen dar. Sie betreffen die inhaltlichen Aspekte von Modellen. Beischwerwiegenden Modellinkonsistenzen sind schwerwiegende Inkonsistenzenim System oder unzweckmäßige Vorgaben kaum vermeidbar.

An dieser Stelle sei auf ideale und nicht ideale Modelle hingewiesen. Diese wer-den im folgenden Kapitel 3.2 näher untersucht. Die wenigsten Modelle sind vonidealer Natur. Sie spiegeln nicht unbedingt Sachverhalte wider, sondern sindsonstige persönliche Vorstellungen. Modellinkonsistenzen treffen gerade auchauf solche nicht idealen Modelle zu.

3.2 Modellbildung und nicht ideale Modelle

Modelle (hier Systemmodelle) ermöglichen dem Menschen, sich durch Ableitenvon Vorhersagen in seiner Umgebung zurecht zu finden. Im bisherigen Verlaufdieser Arbeit wurde von bereits existierenden Modellen ausgegangen.

Die Modellbildung ist der Vorgang, bei dem Menschen Modelle aufgrund ihresWissens und ihren Erfahrungen zusammenstellen bzw. finden. DieserVorgang lässt sich auch als das Bilden und Reifen von Vorstellungenbeschreiben.

Die naheliegendste Modellbildung findet im Kontext der Analyse (hier System-analyse) statt. Dabei werden Strukturen innerhalb der vorhandenen Umgebunggefunden. Systeme, wie informationelle Systeme, werden als Bestandteil der Um-gebung als eigene Struktur erkannt und detaillierteren Untersuchungen unterzo-gen. Eine alternative Modellbildung zur Analyse existiert im Bereich technischer

36

3.2. Modellbildung und nicht ideale Modelle

Systeme und wird als Synthese bezeichnet. Hierbei geht es in erster Linie um dieSchaffung eines technischen Systems ausgehend von bestimmten Vorgaben. Fürdiesen Zweck ist es im Vorfeld der Realisierung eines Systems notwendig, an-gemessene Modelle zu finden. Insbesondere sind Modelle als Grundlage für z.B.Machbarkeitsuntersuchungen und Planung der Arbeitsteilung bei komplexen in-formationellen Systemen unerlässlich.

Bei der Analyse wird die Modellbildung zumeist bei der Aufnahme und Verar-beitung von Modellbeschreibungen, seien sie mündlich, textuell oder anderwei-tig formuliert, durchgeführt. Im Idealfall sind die Modellbeschreibungen für denLeser22 direkt verständlich und beschreiben konsistente Modelle. In den meistenFällen entspricht dies nicht den realen Gegebenheiten. Unterschiedliche Perso-nen, die sogenannten Stakeholder, haben unterschiedliche Interessen und fokus-sieren somit vorwiegend auf die für sie relevanten Aspekte. Die übrigen Aspek-te, die ebenfalls Teil der Modellhierarchie sind, bleiben dabei völlig unbeach-tet. Einerseits kann dies bei der Aufnahme von Modellbeschreibungen zu in-konsistenten Modellen führen, da z.B. relevante Teile einfach ignoriert werden.Andererseits können aufgrund der inkonsistenten Modelle wiederum inkonsis-tente Modellbeschreibungen entstehen. Im Forschungsfeld „mental models“, dasvorwiegend in den 1980er vorangetrieben wurde, gelten inkonsistente Model-le als natürlicher Bestandteil der Modellbildung. Vornehmlicher Untersuchungs-schwerpunkt bei den „mental models“ liegt bei der Modellbildung während derAnalyse eines technischen bzw. natürlichen Systems. Verwendung hat dieses For-schungsfeld vor allem im Bereich der Schnittstellen zwischen Mensch und Ma-schine gefunden (vgl. [Young 83]). Ungeachtet davon sind die Ergebnisse diesesForschungsfeldes gerade für Konsistenzbetrachtungen bei Modellen interessant.Es werden vier grundlegende Begriffe unterschieden (vgl. [Norman 83]):

• das Gegenstandssystem (engl. target system),

• das persönliche Modell (engl. mental model),

• das Konzeptmodell (engl. conceptual model) und

• die Konzeptualisierung (engl. conceptualization).

Das Gegenstandssystem stellt das technische bzw. natürliche System dar, zu demsich jede Person basierend auf ihrem bereits erworbenen Wissen und durch In-teraktion sein eigenes persönliches Modell des Gegenstandssystems bildet. MitPersonen sind im Kontext der mental models Nutzer des Systems gemeint.Die zum Gegenstandssystem gehörenden Konzeptmodelle werden von Inge-nieuren, Wissenschaftlern und Lehrern erfunden. Der Unterschied zwischen ei-nem Konzeptmodell und einem persönlichen Modell liegt in der Vollständigkeitund Konsistenz. Ein Konzeptmodell ist „[...] accurate, consistent, and complete.“([Norman 83], S. 7). Die Konzeptualisierung stellt ein Modell eines persönliches

22Unter dem Begriff Leser sollen Personen verstanden werden, die den Beschreibungen unab-hängig von der gewählten Form Bedeutung zuordnen können. An dieser Stelle sollen dem Leserdie Interpretationsvereinbarungen bekannt sein.

37


Modells dar, geschaffen von einem Mental-model-Wissenschaftler. Bild 3.12 zeigtdie Beziehungen zwischen den Begriffen graphisch zusammengefasst.

Konzeptmodell

(conceptual model)

Gegenstandssystem

(target system)

ideale

Abstraktion

des

persönliches Modell

(mental model)

nicht ideale

Abstraktion

des

Konzeptualisierung

(conceptualization)

ist Modell von

Bild 3.12: Mental Models nach Norman [Norman 83]

Es ist unverständlich, warum sich die praktische Anwendung dieses Forschungs-feldes ausschließlich auf die Gestaltung von Benutzeroberflächen bezogen hat.Hat es doch zum Ziel, die Mechanismen der menschlichen Modellbildung beider Analyse eines Systems zu ergründen, oder wie es Stevens et al. formulie-ren: „Mental models research is fundamentally concerned with understandinghuman knowledge about the world.“ ([Gentner, Stevens 83], S. 1). Jeder Wissen-schaftler, Ingenieur oder Lehrer steht zunächst wie jede andere Person vor ei-nem Gegenstandssystem und versucht, mittels Analyse das System zu begreifen.Aufgrund der Weitergabe und Verbreitung von Wissen über die Jahrhunderteund der intensiven Ausbildung von Wissenschaftlern, Ingenieuren und Lehrernkönnen ihnen ohne weiteres qualitativ höherwertige Modelle zugeschrieben wer-den als vergleichsweise schlechter Ausgebildeten. Das bedeutet keinesfalls, dassdiese Modelle vollständig und konsistent sind. Zu einem Zeitpunkt gültige Vor-stellungen wurden durch nachfolgende Generationen in Frage gestellt, korrigiertoder verworfen. Deshalb sind folgende Beobachtungen von Norman nicht weiterverwunderlich: „[...], lead me to few general observations about mental models:

1. Mental models are incomplete.

2. People’s abilities to "run" their models are severely limited.

3. Mental models are unstable [...]

4. Mental models do not have firm boundaries [...]“ (vgl. [Norman 83], S. 8).

38


"Kunde"

Kunde

Kunde

Architekt und

Projektleiter

Kunde

Entwickler

Systembeschreibungen C

(u.a. Source Code)

Produktionsakteur

programmiertes

System

Zustand

Systembeschreibungen B

(z.B. mündlich oder schriftlich)

Systembeschreibungen A


nicht ideale

Modelle

nicht ideale

Modelle

nicht ideale

Modelle

Bild 3.13: Quellen für Inkonsistenzen und Unvollständigkeiten für nicht idealeModelle anhand einer beispielhaften Darstellung

Deshalb soll an dieser Stelle der Begriff der nicht idealen Modelle eingeführt wer-den.

Nicht ideale Modelle sind im Gegensatz zu idealen Modellen wederkonsistent, vollständig noch korrekt.

Dies spiegelt, wie schon beim Forschungsfeld der mental models festgestellt, denanzutreffenden Zustand wider. Quellen für Inkonsistenzen, Unvollständigkeitenund Abweichungen von Sachverhalten sollen anhand von Bild 3.13 verdeutlichtwerden23. Es sind prinzipiell drei verschiedene Quellen dafür unterscheidbar:

1. bei der Aufnahme von Modellbeschreibungen bzw. bei der Modellbildungwährend der Analyse,

2. bei der Verarbeitung von Modellen bzw. bei der Modellbildung als Bestand-teil der Synthese

3. bei der Formulierung von Modellen als Modellbeschreibungen.

Bei der ersten Möglichkeit handelt es sich um die Modellbildung, die z.B. beimLesen einer Beschreibung oder während der Analyse durchgeführt wird. Hierbeikann es aufgrund teilweise banaler Gründe, wie einer verringerten Aufmerksam-keit oder einer unzureichenden Dauer der Auseinandersetzung, zu Inkonsisten-zen zwischen dem Ergebnis der Modellbildung – den Modellen – und den be-

23Das Bild zeigt eine beispielhafte Konstellation von unterschiedlichen Rollen. In der Praxissind weitere stakeholder beteiligt, wie z.B. Produktmanager, Marketingmitarbeiter, Personen vonder Qualitätsprüfung.

39


schriebenen Modellen in der Modellbeschreibung oder den Sachverhalten kom-men. Das ist ein Phänomen, das im Erfahrungsschatz jeder Person zu finden ist.Daneben existiert noch eine Vielzahl von Gründen für das Entstehen von Inkon-sistenzen bei der Aufnahme von Modellbeschreibungen, wie z.B. uneinheitlicheInterpretationsvereinbarungen und geringes bzw. unzureichendes Domänenwis-sen. Bei Gesprächen oder bei Vorträgen, im Gegensatz zu schriftlichen Modellbe-schreibungen, ist meistens ein Rückkanal der Kommunikation einfach zugäng-lich und möglich. Sofort bemerkte Modellinkonsistenzen können durch gezieltesNachfragen schon während des Gesprächs aufgearbeitet werden.

Dennoch können dabei viele Inkonsistenzen unentdeckt bleiben, wie z.B. auchbei schriftlichen Modellbeschreibungen. Die initial entstandenen Modelle wer-den weiterverarbeitet. Die Modelle werden hinterfragt und es wird versucht siein eine Modellhierarchie einzuordnen. Dadurch können neue Modelle gebildetbzw. bestehende Modelle revidiert oder geändert werden. Interessante Fragestel-lungen führen zu weiterem Bedarf an neuen Informationen, die teilweise mangelsverlässlicher Informationsquellen oder vermeintlicher Eindeutigkeit von den bis-herigen Informationen abgeleitet werden. Die treibende Kraft hinter der Weiter-verarbeitung von Modellen ist die Unzufriedenheit mit dem bisherigen Kenntnis-stand. Sie führt zum Hinterfragen der Modelle. Dieses Hinterfragen ist als Kon-sistenzprüfung der Modelle zu betrachten, die sich intensiv während der geisti-gen Verarbeitung der Modelle ereignet. Während der erstmaligen Aufnahme undEinordnung der Informationen aus der Beschreibung ist eine intensive Auseinan-dersetzung nur eingeschränkt möglich, da die betreffende Person sich zunächsteinen Überblick verschaffen will. Obwohl während dieser Phase der intensivenAuseinandersetzung Konsistenzprüfungen durchgeführt werden, können wei-tere Modellinkonsistenzen entstehen. Dies wird z.B. durch die Erfahrungen mitder betroffenen Domäne, der eingesetzten Technologie etc. bedingt. Ein andererGrund für das Entstehen von Modellinkonsistenzen ist das schlichte Vergessenoder Ignorieren von Informationen.

Die letzte Quelle für Inkonsistenzen stellt der Schritt der Formulierung der Mo-delle als Modellbeschreibungen dar. Bei der Formulierung wird der Beschreiben-de dazu gezwungen, seine Modelle für Andere verständlich zu machen. Dabeiwerden Modellinkonsistenzen häufig zum ersten Mal entdeckt, da zuvor nochnicht über die Modelle nachgedacht wurde bzw. sie nicht hinterfragt wurden.Es ist nicht unüblich, dass Dinge, die völlig klar erscheinen bei der Explizitma-chung sehr viel unklarer werden. Auch diese Konsistenzprüfung ist kein Garantfür konsistente Beschreibungen. Letztlich kann ein Mensch nur seine persönli-chen Modelle oder unreflektierte Informationen weitergeben. Zu unbemerktenModellinkonsistenzen bei der Formulierung kann es bei der Wahl von Symbolenbzw. Zeichen sowie deren Platzierung kommen. Abhängig von den dazu assozi-ierbaren Interpretationen kann es zu Inkonsistenzen zwischen dem vermeintlichWiedergegebenen und dem von anderen Personen Aufgenommen führen. Petrekonnte dies auch bei seinen Untersuchungen von unterschiedlichen Möglichkei-ten der Programmformulierung und Layoutgestaltungen in [Petre 95] feststellenund hat darin den Begriff der „secondary notation“ geprägt. Obwohl es sich beider secondary notation ausschließlich um „oberflächliche“ Layoutmodifikatio-

40


nen handelt, die nicht die formal ableitbaren Aussagen der Darstellung beein-flussen, können ungeschickte oder aus Unkenntnis gewählte Layouts zu Inkon-sistenzen führen (vgl. [Petre 95], S. 35 ff.).

Je mehr Beteiligte bei der Entwicklung eines programmierten Systems beteiligtsind, desto mehr potentielle Kommunikationspfade existieren, wodurch Inkon-sistenzen begünstigt werden. Dies wird weiter durch die notwendige Arbeitstei-lung, die fast zwangsläufig zu Spezialisierung bei den Beteiligten führt, verstärkt.

3.2.1 Analyse

Ziel einer Analyse eines Systems ist es eine bessere Vorstellung des Systems zuerreichen als zuvor. Eine Analyse kann explizit gefordert werden, z.B. für eineEvaluation eines Systems oder wenn ein zusammenhängendes Verständnis ei-nes Systems fehlt. Häufig wird als Resultat eine festgehaltene Beschreibung dereigentlichen Ergebnisse – der Modelle – gefordert, um das gesammelte Wissenund die Modelle anderen Personen zugänglich zu machen. Implizit werden diemeisten Analysen durchgeführt. Man denke an neue Mitarbeiter, die das bereitsbestehende System kennenlernen müssen. Implizite Analysen können aus ver-schiedenen Gründen durchgeführt werden, z.B. wegen der persönlichen Unzu-friedenheit mit dem aktuellen Verständnis bzw. Wissenstand oder zur Bewälti-gung einer gestellten Aufgabe. Es wird dabei in den meisten Fällen nicht erwar-tet, die Modelle in einer geeigneten Beschreibungsform festzuhalten. Es könnendrei Quellen der Informationsbeschaffung unterschieden werden, wie in Bild 3.14aufgeführt (vgl. auch [Häuslein 04]). Neben dem zu analysierenden System kön-nen festgehaltene Systembeschreibungen und an dem System in beliebiger FormBeteiligte konsultiert werden. Mindestens eine der Quellen muss für die Analyseverfügbar sein.

Für gewöhnlich kann die Existenz des zu untersuchenden Systems vorausgesetztwerden. Das System muss schon einmal existiert haben, so dass die Funktionsfä-higkeit des Systems sowie der Zugang zum System nicht erfüllt sein müssen. DerVorteil, das zu analysierende System zugänglich zu haben, liegt darin, die Ana-lyseergebnisse validieren zu können. Die Ergebnisse der Analyse – die Modelle –sind in der Regel Verallgemeinerungen, die auch auf andere Exemplare des glei-chen Systemtyps zutreffen. Leider ist je nach Art des Zugangs die ausschließli-che Beschränkung auf das zu untersuchende System während der Analyse nichtimmer ausreichend, da z.B. ohne Einführung in das System der Zeitaufwand er-heblich wäre oder es schlicht technisch sehr aufwendig ist. Weiterhin würdensich aufgrund der ausschließlichen Nutzung des Systems zur Analyse nur diewährend der Analysephase gesammelten Informationen in den resultierendenModellen widerspiegeln. Es stehen die aktive und die passive Untersuchungs-möglichkeit zur Verfügung. Unter der passiven Untersuchungsmöglichkeit solldas reine Beobachten verstanden werden, wobei auf das zu untersuchende Sys-tem möglichst wenig Einfluss genommen wird. Im Gegensatz dazu existiert dieaktive Untersuchungsmöglichkeit, bei der mit dem System interagiert wird. Da-bei kann es zu den bereits erwähnten Modellinkonsistenzen kommen.

41


Analytiker

Beschreibungen

Wissensträger(z.B. aus

Entwicklung)

System

Zustand

Source Code

sonstige

Unterlagen

Analytiker

Bild 3.14: Möglichkeiten der Informationsbeschaffung bei der Analyse

Auch ohne System lässt sich z.B. durch das Studium festgehaltener Beschrei-bungen, z.B. in Form von Schriftstücken oder Tonaufzeichnungen, eine Analysedurchführen. Die Aussagen in diesen Beschreibungen sind im Gegensatz zum zuuntersuchenden System selbst von den Modellen der Beschreiber abhängig. Dadie festgehaltenen Beschreibungen in der Regel für andere Personen erstellt wur-den, können sie wertvolle Abstraktionen enthalten und verhelfen zu einer rasche-ren Aufarbeitung. Zu den Beschreibungen gehört bei programmierten Systemenauch der Source Code. Da der Source Code und das programmierte System in ei-nem sehr engen Verhältnis stehen, kann der Source Code ähnlich wie das Systemselbst als primäre Quelle angesehen werden. Mit Hilfe von primären Quellen las-sen sich die Modelle überprüfen. Nichtsdestotrotz kann es bei der Interpretationdes Source Codes oder bei Fehlern im Abwickler bzw. Compiler zu Inkonsisten-zen kommen.

Die festgehaltenen Beschreibungen werden von Wissensträgern erstellt. Diesekönnen auch direkt befragt werden. Der Vorteil des direkten Austauschs ist dieMöglichkeit, Unklarheiten direkt auflösen zu können. Wissensträger geben dabeimeist ihre persönlichen Modelle wieder. Theoretisch könnten sie als reine Infor-mationsweitergebende agieren, was aber im Folgenden ausgeschlossen werdensoll, da der Mensch immer versucht sein Wissen einzuordnen. Je nach Rolle desWissensträgers, sei es als Anwender oder als an der Entwicklung Beteiligter, kanndas Wissen über das System stark variieren. Deshalb ist es erforderlich, mehre-re Wissensträger zu befragen. Auch hilft die Mehrfachbefragung bei der Kon-sistenzprüfung, da mehrere Aussagen zur gleichen Thematik verglichen werdenkönnen.

Wie die Modellbildung tatsächlich stattfindet, kann an dieser Stelle nicht beant-

42


wortet werden. Modellierungsansätze geben zwar Unterstützung bezüglich derSortierung der Informationen und der Abstraktionen. Sie helfen auch, den Fo-kus auf bestimmte Dinge zu lenken und Fragestellungen zu finden. Aber die-se unterstützenden Maßnahmen alleine können nicht erklären, wie der Menschverfährt, um das Wesentliche herauszukristallisieren. Die Modellbildung ist einProzess, wobei einzelne Modelle wieder verworfen oder korrigiert werden. DasVorgehen bei der Analyse ist stets iterativ, mit Ausnahme bei der Analyse von tri-vialen Systemen, denn zunächst besitzt der Analytiker keine oder eine sehr vageVorstellung, die nach und nach durch die Auseinandersetzung und durch Expli-zitmachung, z.B. durch Gespräche oder durch die schriftliche und zeichnerischeErstellung von Beschreibungen, „heranreift“.

3.2.2 Synthese

Die Modellbildung ist ein unerlässlicher Schritt bei der Synthese und somit beider Schaffung eines neuen Systems. Bild 3.15 zeigt ein mögliches Szenario fürprogrammierte Systeme, wobei es gilt, ausgehend von Anforderungen die best-mögliche Lösung zu finden. Die Modellbildung ist immer Bestandteil der Syn-these, auch wenn sie nicht explizit stattfindet. Denn ohne geistige Vorbereitung,auch wenn sie erst unmittelbar bei oder kurz vor der Erstellung des Quelltextesbei programmierten Systemen geschieht, kann kein – im Rahmen der Anforde-rungen – funktionierendes technisches System entstehen. Bei komplexeren Syste-men ist es üblich die Anforderungen und den Lösungsansatz in Form geeigneterBeschreibung festzuhalten, um ein gemeinsames Verständnis bei allen Beteilig-ten zu fördern. Häufig finden Teile dieser Beschreibungen auch Verwendung inVerträgen.

Kunde

Anforderungs-

bestimmer

Kunde

Beteiligter an

Entwicklung

formale

Systembeschreibung für

Produktionsakteur

Produktionsakteur

programmiertes

System

Zustand

Systembeschreibungen


Bild 3.15: Synthese anhand einer beispielhaften Konstellation

43


Dass es zwischen den Beteiligten, z.B. Kunden, Anwendern, Requirements En-gineers, Projektleitern, Architekten und Programmieren, während der Synthesezu Missverständnissen kommt, ist bekannt (siehe auch [Beer 00], [Standish 95],[Standish 99], [Standish 01]). Diese entstehen hauptsächlich aufgrund des ver-schiedenen Verständnisses der Anforderungen und der Domäne. Deshalb ist ge-rade im Prozess der Synthese die Analyse mit eines der wichtigsten Bestandtei-le. So stellt auch Jackson fest: „Understanding the problem and structuring thesolution is the primary need.“([Jackson 94], S. 58). Es ist natürlich, dass vor derLösungsfindung das zu lösende Problem ausreichend bekannt sein muss. Geradeim Softwarebereich ist dies ein interessantes Phänomen. Das zu lösende Problembzw. der Zweck des Systems ist fast immer eines, das primär nichts mit Soft-ware zu tun hat. So hat ein Navigationssystem zunächst nichts mit Software zutun, sondern es geht um eine zuverlässige Führung zum Zielpunkt. Die Realisie-rung mittels eines programmierbaren Systems und Software stellt lediglich einewirtschaftlich geeignete Umsetzungsform dar. Da programmierte Systeme wirt-schaftlich immer interessanter werden, wachsen die Einsatzbereiche und somitdie unterschiedlichen Domänen kontinuierlich. Es ist für den Softwareingenieurbzw. dem Softwarearchitekten also unerlässlich sich in die entsprechende Domä-ne mit ihren speziellen Anforderungen einzuarbeiten.

Neben dem Aneignen von ausreichendem Domänenwissen sind auch eine Rei-he technischer Analysen durchzuführen. In der Praxis müssen neue Lösungenim Kontext bereits bestehender Systeme gefunden werden. Dies setzt eine ausrei-chende Kenntnis der existierenden Systeme, der dabei eingesetzten Technologienund die verwendeten Konzepte voraus. Dazu gehören auch die Erwägungen, diezu den Entscheidungen geführt haben und warum gewisse Alternativen nichtgewählt wurden vgl. auch [Yu, Mylopoulos 94] und [Potts, Bruns 88].

Während bei der Analyse klare Informationsquellen existieren, basieren die Ent-scheidungen bei der Synthese auf Erfahrungen. Daher werden neue Lösungenmeist von erfahrenen Entwicklern bzw. Architekten erdacht und bewertet. Daes sehr wahrscheinlich ist, dass andere Personen gleiche oder ähnliche Problem-stellungen zu bewältigen hatten, sind deren Erfahrungen sehr wertvoll. DieseErfahrungen gilt es zu analysieren. Es stehen wieder die bekannten Informati-onsquellen der Analyse zur Verfügung: es können Personen befragt werden, diediese Erfahrungen bereits gemacht haben; bestehende System können begutach-tet werden; oder Beschreibungen konsultiert werden. Interessante Formen vonfestgehalten Erfahrungen sind so genannte Erfahrungsdatenbanken (siehe auch[Ciolkowski et al. 02]) und Patterns (siehe auch [Gröne 04]). Die Erfahrungsda-tenbanken stehen noch am Anfang und müssen ihre Nützlichkeit noch unter Be-weis stellen. Patterns hingegen stellen eine bereits bewährte Form dar, im Bereichder Programmierung spätestens seit [Gamma et al. 95].

Stehen keine Erfahrungswerte zur Verfügung können diese durch „Experimen-tieren“ gewonnen werden. Experimente können auch genutzt werden, um dieErfahrungswerte anderer zu validieren. Üblicherweise wird dazu das Prototy-ping genutzt, wobei das System teilweise oder vollständig realisiert wird. Es gibtunterschiedliche Ansätze Prototypen zu erstellen, z.B. exploratives Prototyping,

44

3.3. Beschreibung programmierter Systeme

evolutionäres Prototyping, experimentelles Prototyping. Die Ansätze unterschei-den sich darin, welche Teile des Systems überhaupt und wie ausführlich dieserealisiert werden. Es könnte z.B. ausreichen, lediglich die als kritisch eingeschätz-ten Teile eines Systems zu realisieren, um die Umsetzbarkeit einer angedachtenLösungsmöglichkeit zu evaluieren.

Resultat dieser Aktivitäten sind Modelle und Wissen um die Realisierungsmög-lichkeiten. Basierend auf den Modellen werden Zeit- und Kostenabschätzungensowie die Arbeitsteilung durchgeführt. Weiterhin können daraus der Bedarf füreinzusetzende Technologien oder benötigte bereits existierende Systeme abgelei-tet werden.

Der Vorgang der Modellbildung kann nicht näher spezifiziert werden. Es gibtdafür keinen konkret beschreibbaren Prozess. Aus nebulösen Vorstellungen wer-den Modelle durch Nachdenken und Ideenfindung gefunden und immer wei-ter verfeinert. So entstandene Modelle können auch wieder verworfen werden.Es existieren eine ganze Reihe von Prozessmodellen (vgl. z.B. [Gales 98] und[Kruchten 04]), die sich, wenn überhaupt, nur am Rande mit der Modellbildungbefassen. Die Tätigkeiten für und während der Modellbildung stellen den krea-tiven Anteil bei der Realisierung eines Systems dar. Die Ergebnisse dieser Mo-dellbildung stellen die eigentliche intellektuelle Leistung dar. Die Modelle undsomit die Konzepte des Lösungsansatzes finden sich häufig nur versteckt in sehrdetaillierten Systembeschreibungen wieder. Dennoch ist das Qualitätsmerkmalder „Ausgereiftheit“ der Modelle ein wichtiger Faktor für realistische Zeit- undKostenabschätzungen. Auch für die Arbeitsteilung ist sie ausschlaggebend. Des-halb werden die Modelle üblicherweise besprochen. Dafür müssen die Modelleexplizit gemacht werden. Dieser Vorgang der Explizitmachung führt schon beider Person, die ihre Modelle beschreibt, zu Konsistenzprüfungen. Im weiterenAustausch mit anderen Personen lassen sich weitere Modellinkonsistenzen auf-decken. Hierbei helfen Modellierungsansätze, die Modelle zu strukturieren undzu beschreiben. Bis zur Einigung auf den Lösungsansatz wird üblicherweise ite-rativ vorgegangen, um die Vorbestellungen möglichst zu konkretisieren.

3.3 Beschreibung programmierter Systeme

3.3.1 Notwendigkeit von Systembeschreibungen

Da jeglicher zwischenmenschlicher Wissensaustausch auf interpretierbaren For-men beruht, ist die Beschreibung eines informationellen Systems, wie z.B. einesprogrammierten Systems, ein wesentlicher Bestandteil der alltäglichen Arbeit ansolchen Systemen. Bei dieser Kommunikation über informationelle Systeme gehtes um die Weitergabe der Modelle von einer Person zu einer anderen, siehe auchBild 3.16. Dafür muss immer der Umweg über interpretierbare Formen der Sys-tembeschreibung gewählt werden. Die interpretierbaren Formen lassen sich inzwei formbezogene Klassen einordnen:

• schriftliche Systembeschreibung und

45


• mündliche Systembeschreibung.

Andere formbezogene Klassen sollen im Verlauf dieser Arbeit keine weitere Be-rücksichtigung finden. In der Praxis finden sich häufig auch Mischformen, beidenen schriftliche und mündliche Beschreibungen zusammen, z.B. in Präsenta-tionen, genutzt werden. Zu den schriftlichen Systembeschreibungen sollen al-le textuellen Darstellungen wie auch Abbildungen, z.B. Zeichnungen, gehören.Das Vorführen oder die Benutzung des Systems hingegen soll selbst nicht alsBeschreibung gelten, sondern wird als unterstützende Maßnahme bei der meistmündlichen Beschreibung angesehen, denn der Sinn der Nutzung des Systemsliegt nicht in der Erläuterung der zugrunde liegenden Modelle, die für die Erstel-lung, Weiterentwicklung, Pflege und Wartung benötigt werden.

SenderEm-

pfänger

Modelle Modelle'

Systembeschreibung

eigentlicher Zweck: Weitergabe von Modellen

Bild 3.16: Zweck einer Systembeschreibung

Die in Bild 3.16 gezeigte Struktur ist stellvertretend, unabhängig von der Anzahlder Personen, die sich in den Rolle des Senders oder des Empfängers befinden. ImExtremfall ist die Person, die die Beschreibung erzeugt und interpretiert die Glei-che, z.B. während der Analyse eines Systems zum persönlichen Verständnis. Beischriftlichen Beschreibungen wird die Formulierung im Allgemeinen als „Schrei-ben“ bezeichnet und die Interpretation als „Lesen“. Auf jeden Fall ist die beider-seitige Kenntnis und Beherrschung der Interpretationsvereinbarungen, wie dereingesetzten Sprache, eine notwendige Voraussetzung für das Gelingen des Wis-sensaustauschs. Weiterhin ist die Anordnung der interpretierbaren Formen zurzweckmäßigen Erkennung sowie inhaltliche Gliederung und Aufbearbeitung da-für nicht zu vernachlässigen.

Da der primäre Zweck einer Systembeschreibung die Weitergabe der Modelleist, müssen diese zunächst formuliert werden. Prinzipiell läuft jede Systembe-schreibung über die Formulierung der Modelle. Somit ist eine starke Kopplungzwischen der Systembeschreibung und den Modellen vorgegeben. Sind Modellewenig ausgewogen, so kann die daraus resultierende Systembeschreibung nichtzufriedenstellend verständlich sein. Sind z.B. die Modelle inhaltlich inkonsistentzueinander, dann wird die Beschreibung unweigerlich diese Inkonsistenzen wie-dergeben, falls diese bei der Formulierung nicht aufgedeckt und die Modelledabei korrigiert wurden. Bestimmte Formen der Beschreibung und deren Dar-stellungen, wie z.B. der Vortragsstil oder unglücklich gewählte Formulierungen,

46


können hinderlich für die Verständlichkeit sein. Dies kann dazu führen, dass dieModelle, die der Empfänger aufbaut, Abweichungen zu den zu vermittelndenModellen aufzeigen.

Es müssen nicht immer alle Modelle beschrieben werden. In der Regel findet diesauch nicht statt. Je nach Schwerpunkt der Kommunikation wird sich auf eine be-stimmte Untermenge von Modellen beschränkt. Die übrigen sind entweder ir-relevant oder werden vorausgesetzt. Bei jeder Kommunikation werden Modellevorausgesetzt, so werden sich z.B. Softwareexperten nicht über die Begriffe Dateioder Verzeichnis austauschen, sondern werden sie wie selbstverständlich nutzenund davon ausgehen, dass der Gegenüber die gleiche Vorstellung davon hat. Diesist im Rahmen der zu besprechenden Thematik für eine effiziente Kommunikati-on unerlässlich, bietet aber Möglichkeiten für Inkonsistenzen. Je nach Kommuni-kationspartner findet dies im Allgemeinen Berücksichtigung. Abhängig vom er-forderlichen Aufwand für die Formulierung von Modellen kann es sinnvoll sein,verschiedene Formulierungsarten, z.B mündlich anstatt schriftlich oder zeichne-risch anstatt textuell, zu nutzen oder anstatt eine Aufzählung vieler zutreffenderPunkte die kürzere Aufzählung der nicht zutreffende Punkte durchzuführen.

Systembeschreibungen stellen den Kern jeder technischen Kommunikation zwi-schen den Beteiligten dar. Das System muss dabei noch nicht existieren, da dieModelle beschrieben werden und nicht direkt das System, was aufgrund derKomplexität und der Menge an Informationen nicht zweckmäßig wäre. Der Be-griff Modellbeschreibung wurde mit Absicht nicht gewählt, da in der vorliegen-den Arbeit die Modelle als Mittel der Komplexitätsbeherrschung gesehen wer-den und die Systeme im Fokus stehen sollen. Im Rahmen der Arbeitsteilungund der damit verbundenen effizienten Nutzung der menschlichen Ressourcen,gerade bei komplexen informationellen Systemen, sind technische Kommuni-kationen mittels Systembeschreibungen eine alltäglich anzutreffende Situation.Die Effektivität des Wissensaustauschs spielt hierbei ein wichtige Rolle. Je hö-her die Anzahl der Beteiligten ist, desto mehr Personen finden sich in der Rolledes Empfängers. Dies spiegelt sich meist auch in der organisatorischen Strukturwider. Bild 3.17 zeigt das qualitative Verhältnis von Empfängern und Sendernzu der Anzahl der Beteiligten. Üblicherweise ist bei der Entwicklung komplexerinformationeller Systeme die Anzahl der Beteiligten hoch, so dass ein erhöhterAufwand für eine qualitativ hochwertige Systembeschreibung zweckmäßig er-scheint. Die Anzahl der Empfänger ist nicht immer ausschlaggebend für das Maßdes Aufwands für eine qualitativ hochwertige Systembeschreibung. Man den-ke an Beschreibungen speziell für Personen mit Entscheidungsbefugnissen, wo-bei es nicht hauptsächlich um technischen Wissensaustausch geht, sondern umstrategische oder wirtschaftliche Überzeugungsarbeit, die nicht im Fokus dieserArbeit steht. Nichtsdestotrotz kann in diesem Kontext eine qualitativ hochwerti-ge Systembeschreibung zu einer vertrauensvollen Atmosphäre zwischen Senderund Empfänger führen.

Systembeschreibungen werden für die Weitergabe der gewonnenen Modelle beider Analyse oder Synthese benötigt, da immer eine Vielzahl von Beteiligten inunterschiedlichsten Rollen involviert sind. Sie sind eine Voraussetzung für eine

47


Anzahl der Beteiligten

Anteil der EmpfängerAnteil der Sender

(Anteil der Empfänger wächst mit steigender Gesamtanzahl)

Bild 3.17: Qualitatives Verhältnis von Empfängern und Sendern von Systembe-schreibungen zur Anzahl der Beteiligten

gelungene technische Kommunikation. Systembeschreibungen können prinzipi-ell für folgende Zwecke genutzt werden:

• das Verstehen des Systems oder bestimmter Systemteilez.B. für die Einarbeitung neuer Beteiligter oder Personen, die für sie neueZuständigkeitsbereiche übernehmen. Je nach Rolle ist ein unterschiedlichtiefes Verständnis erforderlich bzw. möglich.

• als Grundlage für die Entwicklung bzw. Weiterentwicklung des Systemsz.B. für die Prüfung und Planung einer neuen Funktionalität des Systems.

3.3.2 Klassen von Systembeschreibungen

Systembeschreibungen lassen sich in viele verschiedene Klassen aufteilen. Die imFolgenden vorgestellten Hauptklassen von Systembeschreibungen beschränkensich auf die für diese Arbeit relevanten Klassen. Es werden die formbezogeneKlasse und inhaltsbezogenen Klasse von Systembeschreibungen unterschieden.Die Letztere ist die Wichtigere, da sie ebenfalls Einfluss auf die Form der System-beschreibung hat.

3.3.2.1 Formbezogene Klasse von Systembeschreibungen

Bei der formbezogenen Klasse von Systembeschreibungen ist die Form der Systembe-schreibung das ausschlaggebende Kriterium. Die für den weiteren Verlauf dieserArbeit wichtigen Unterklassen sind im folgenden aufgeführt. Das nachfolgendeBild 3.18 zeigt eine Übersicht über die formbezogenen Systembeschreibungen.

48


formbezogene Systembeschreibung

schriftliche/mündliche

Systembeschreibung

medienbezogene

Systembeschreibung

deklarative/deskriptive

Systembeschreibung

formale/semi-formale

Systembeschreibung

sprachbezogene

Systembeschreibung

Bild 3.18: Übersicht formbezogene Systembeschreibungen

Schriftliche und mündliche Systembeschreibungen. Schriftliche Systembe-schreibungen unterscheiden sich von Mündlichen primär durch die genutzten Da-tenträger für Aussagen in einer Sprache: Schallwellen oder Schrift. Der vorwie-gende Teil, der primär für den Menschen gedachten Systembeschreibungen ist innatürlichen Sprachen verfasst, wohingegen Systembeschreibungen für Maschi-nen, z.B. der Quelltext von Programmen, in formalen Sprachen verfasst sind.

Die originale Flüchtigkeit der Daten ist eine weitere Eigenschaft, die mündlicheund schriftliche Systembeschreibungen unterscheidet. Schriftliche Formen sindgespeicherte Aussagen bezüglicher einer Sprache, wohingegen mündliche For-men flüchtig sind. Der Vorteil mündlicher Systembeschreibungen ist, dass siead hoc stattfinden können und individuell angepasst werden können, z.B. durchdie Interaktion mit den Empfängern. Schriftliche Systembeschreibungen sind inder Regel aufwendiger und bedürfen der vorherigen Erstellung. Zeichnungenund andere Darstellungen, wie Abbildungen, gehören ebenfalls zu den schriftli-chen Systembeschreibungen. Im Gegensatz zu mündlichen Systembeschreibun-gen können schriftliche Systembeschreibungen nach der Erstellung nicht mehrindividuell angepasst werden. Sind sie erst einmal geschrieben worden, bleibensie in der Regel unverändert, bzw. es entsteht ein Aufwand bei der Änderung.Der Vorteil schriftlicher Systembeschreibungen ist die einfachere Verteilung derSchriften. Zusätzlich bieten die schriftlichen Systembeschreibungen, durch ihrenspeichernden Charakter, die Möglichkeit immer wieder konsultiert zu werden.Häufig werden mündliche Systembeschreibungen durch Elemente schriftlicherSystembeschreibungen unterstützt, wie z.B. bei Vorträgen.

Prinzipiell lassen sich mündliche Systembeschreibungen in schriftliche (oder zu-mindest dauerhafte) Systembeschreibungen verwandeln (siehe auch Bild 3.19),z.B. durch Transkription oder mittels technischer Vorrichtungen wie Audio- oderVideoaufnahmen. Somit ist die Flüchtigkeit von mündlichen Systembeschreibun-gen nicht mehr gegeben. Dadurch verlieren die allerdings den Vorteil der indivi-duellen Anpassung, da eine Interaktion mit dem Sender nicht mehr möglich ist.Das Entsprechende gilt ebenfalls für schriftliche Systembeschreibungen. Sie kön-nen z.B. durch Sprachsynthese (durch Vorlesen) in mündliche Systembeschrei-bungen gewandelt werden. Die Eigenschaften der schriftlichen Systembeschrei-bung bleiben durch die Möglichkeit der mehrfachen Durchführung der Sprach-synthese erhalten. Nach wie vor sind schriftliche Systembeschreibungen auf-grund der speichernden und visuellen Eigenschaften weiter verbreitet als münd-liche Systembeschreibung, die vor allem im Schulungsumfeld verbreitet sind.

Soll ein größerer Empfängerkreis erreicht werden, sind die schriftlichen odermündlichen Systembeschreibungen in der Regel mit entsprechendem Aufwand

49


Sender

Sender

Empfänger

Empfänger

Synthesesystem(z.B. Sprachsynthese)

Transkriptions- oder

Aufnahmesystem

schriftliche Systembeschreibung

(nicht flüchtig)

mündliche Systembeschreibung

(flüchtig)

Bild 3.19: Überführung von schriftlichen und mündlichen Systembeschreibun-gen

vorbereitet worden. Prinzipiell ist der Aufwand für das Erstellen einer schriftli-chen Systembeschreibung größer als für eine mündliche Systembeschreibung, dader potentielle Empfängerkreis aufgrund der speichernden und visuellen Eigen-schaften größer ist.

Andere als schriftliche und mündliche Systembeschreibungen, wie z.B. durch Ge-bärden beschriebene Systeme, stehen nicht im Fokus dieser Arbeit. Im weiterenVerlauf wird im Besonderen auf schriftliche Systembeschreibungen eingegangen,da sie bei der Entwicklung komplexer informationeller Systeme und der hohenAnzahl der Beteiligten am weitesten verbreitet sind.

Medienbezogene Klasse von Systembeschreibungen. Es können unterschied-lichste Medien für Systembeschreibungen genutzt werden. Dies gilt sowohl fürschriftliche als auch für mündliche Systembeschreibungen. Jede Systembeschrei-bung nutzt mindestens ein Medium. Unterschiedliche Medien unterscheiden sichhinsichtlich ihrer Verbreitung und der Verbreitbarkeit im Rahmen existierenderInfrastrukturen und somit der Kosteneffizienz. Das gewählte Medium kann auchje nach Inhalt bzw. Zielkreis der Systembeschreibung variieren.

50


Zunächst lassen sich elektronische24 und nicht elektronische Medien25 unterscheiden.Bei Verwendung elektronischer Medien wie z.B. Webseiten, E-Mail, Textverarbei-tungsdaten ist eine Verbreitung der Systembeschreibungen relativ einfach undkostengünstig erreichbar. Voraussetzung dafür ist die entsprechende Infrastruk-tur mit der benötigten Hardware (inkl. technischer Kommunikationsmöglichkei-ten, Energieversorgung etc.) und Software. Systembeschreibungen in elektroni-scher Form lassen sich in der Regel einfacher ändern und warten als nicht elek-tronische Medien. Teilweise sind elektronische Medien so kostengünstig, dassBeschreibungen z.B. auf einer DVD26 zu den nicht elektronischen Medien mit-gegeben werden. Vorwiegend wird Papier, ein- oder mehrfarbig bedruckt meistim Buchform, als typisches nicht elektronisches Medium genutzt. Nicht elektro-nische Medien haben den Vorteil der gewohnten Form und des handhabbarerenund zum Lesen bequemeren Formats. Allerdings sind durch das Medium gege-bene Eigenschaften, die Vervielfältigung und Verbreitung bzw. Anschaffung derExemplare in der Regel mit höheren Kosten verbunden. Auch Änderungen kön-nen nach einer Veröffentlichung nur sehr aufwändig realisiert werden.

Elektronische Medien können in verschiedenen sogenannten Formaten auftau-chen, die hauptsächlich Unterschiede in der Kodierung der Daten aufweisen. Bei-spiele hierfür sind schriftliche Systembeschreibungen, die mit einem Textverar-beitungssystem erstellt worden sind und demzufolge in dem Textverarbeitungs-system spezifischen Format abgelegt sind. Diese Systembeschreibung kann, mitidentischem Inhalt, in einem anderen Format existieren. Dieses Vorgehen wirdz.Z. sehr häufig angewendet, man denke an den Export der Systembeschreibungaus einem Textverarbeitungssystem im webseiten- oder druckgerechten Format.Prinzipiell können auch nicht elektronische Medien in verschiedenen Formatenauftauchen, man denke z.B. an Taschenbücher oder an verschiedene Papiergrö-ßen.

Unterschiedliche Medien lassen unterschiedliche Gestaltungen der Systembe-schreibungen zu oder beschränken diese. Es können für eine Systembeschreibungmehrere unterschiedliche Medien genutzt werden. So können z.B. auf einer Web-seite neben Text und Abbildungen auch Video- und Tonaufzeichnungen genutztwerden. Für die besonders geläufige Form von schriftlichen Systembeschreibun-gen als buchähnliches Medium gibt es eine ganze Reihe von Vorgaben und Vor-schlägen für die Gestaltung (vgl. z.B. [Barker 03] und [SigDoc]), um sie möglichstansprechend und die Beschreibung leicht lesbar zu machen.

Die Wahl des Mediums orientiert sich hauptsächlich am Empfängerkreis und denKosten für die Nutzung des Mediums. Üblicherweise werden die meisten Sys-tembeschreibungen in elektronischer Form verbreitet, die dann häufig aufgrundindividueller Vorlieben auf Papier gedruckt werden.

24Bei schriftlichen Systembeschreibungen findet auch der Begriff Online-Dokument (engl. on-line document) Verwendung.

25Bei schriftlichen Systembeschreibungen werden nicht elektronische Medien auch als Offline-Dokument (engl. offline document oder print document) bezeichnet.

26DVD steht für Digital Versatile Disc und stellt ein Speichermedium mit festgelegter Strukturdar, das optisch ausgelesen wird und Mitte/Ende der 90er Jahre weite Verbreitung gefunden hat.

51


Deklarative oder deskriptive Systembeschreibungen. Inhaltlich identischeSystembeschreibungen können sich auf Formebene im verwendeten Stil unter-scheiden.

Deklarative Systembeschreibungen beschreiben das System aus einer Sicht, bei derdas beschriebene System noch nicht existiert. D.h. es wird mit Aussagen über dasSystem gearbeitet, die ein bestimmtes Systemverhalten oder eine bestimmte Sys-temstruktur fordern. Prominentes Beispiel dafür sind Anforderungen (engl. re-quirements), die häufig in einem Lastenheft (engl. requirement document oder re-quirement specification) festgehalten werden. Die Aussagen in solchen Beschrei-bungen haben häufig den Charakter einer Aufzählung. Diese werden z.B. in Ta-bellenform aufgeführt. Das noch nicht existierende System soll oder wird alsodas beschriebene Verhalten aufzeigen.

Im Gegensatz dazu werden deskriptive Systembeschreibungen meist aus der Sicht,bei der das System bereits existiert, beschrieben. Üblicherweise werden alle Sys-tembeschreibungen, bis auf das Lastenheft, in dieser Form verfasst. Dies ent-spricht mehr der natürlichen Herangehensweise, die Vorstellung eines konkretenSystems, das gerade Operationen durchführt, vermitteln zu wollen. Darüber hin-aus weckt es mehr den Eindruck einer validen Systembeschreibung als in Formeiner Aufzählung von Anforderungen, welche das zukünftige System erfüllensoll.

Nicht-formale, semi-formale und formale Systembeschreibungen. Es kannzwischen folgenden Systembeschreibungen unterschieden werden:

• nicht-formale,

• semi-formale und

• formale Systembeschreibungen.

Formale Systembeschreibungen werden fast ausschließlich bei der Verschriftli-chung verwendet. Ein Beispiel für eine formale Sprache, die zumindest in wis-senschaftlichen Kreisen verwendet wird, ist die Spezifikationssprache Z (vgl.[Potter et al. 91]). Jede Systembeschreibung – auch wenn sie formal ist – ist ei-ne Formulierung der persönlichen, nicht idealen Modelle. Daher können auchformale Systembeschreibungen keine konsistente und vollständige Beschreibunggarantieren: „[...] any formalisation of an informal reality is an approximation“[Jackson 00], S. 15. Daher und vor allem, weil sie in der Praxis quasi irrelevantsind, sollen formale Systembeschreibungen im weiteren Verlauf dieser Arbeitnicht weiter berücksichtigt werden. Dies bestätigt auch Kruchten: „Formal me-thods have held the promise of a solution, but at the beginning of the third mill-ennium, they have not gained significant acceptance in the industry except smallspecialized domains.“ [Kruchten 04], Seite 57. Dennoch müssen zu einem be-stimmten Zeitpunkt bei der Entwicklung programmierter Systeme formale Spra-chen und somit formale Systembeschreibungen eingesetzt werden. Das program-mierte System kann erst entstehen, wenn der entsprechende Abwickler die, not-wendigerweise, formale Systembeschreibung – das Programm – erhält.

52


Nicht-formale und semi-formale Systembeschreibungen sind in der Industrie weit ver-breitet und haben sich bewährt (siehe z.B. [Keller 03]). Sie werden sowohl fürschriftliche als auch mündliche Systembeschreibungen verwendet. Im Folgendenwerden diese Klassen von Systembeschreibungen im Besonderen berücksichtigt.

Sprachbezogene Klasse von Systembeschreibungen. Eine Klassifizierung istauch nach der verwendeten Sprache möglich. So gibt es beispielsweise deutscheoder englische Systembeschreibungen. Bei international agierenden Unterneh-men werden schriftliche Systembeschreibungen in der Regel in englischer Spra-che verfasst, um den Mehraufwand für die Übersetzung in verschiedene Spra-chen zu minimieren oder auszuschließen. Die Wahl der Sprache richtet sich pri-mär nach dem Empfängerkreis.

Eine ausreichende Kenntnis der verwendeten Sprache bei Sender und Empfän-ger ist natürliche Voraussetzung für eine funktionierende Kommunikation. Ge-koppelt an die Sprachen sind auch kulturelle Unterschiede, die sich unter Um-ständen häufig in unterschiedlichen persönlichen Modellen der Systeme wider-spiegeln. Dies sind ebenfalls Quellen von Inkonsistenzen, die aber im weiterenVerlauf dieser Arbeit unbeachtet bleiben sollen. Es soll davon ausgegangen wer-den, dass diese Quelle von Inkonsistenzen zunächst nicht relevant ist. Sie solltenim Rahmen soziologischer Untersuchungen Berücksichtigung finden.

3.3.2.2 Inhaltsbezogene Klasse von Systembeschreibungen

Bei dieser Klasse von Systembeschreibungen werden im Gegensatz zur formbe-zogenen Klasse ausschließlich die Inhalte der Beschreibung und wie es zur Wahldieser Inhalte kam als Kriterium zugelassen. Jeder Erzeuger (Sender) von Sys-tembeschreibungen adressiert einen bestimmten Empfängerkreis und stimmt da-nach die Inhalte ab. Die Systembeschreibung soll für den gewählten Empfänger-kreis den entsprechenden Zweck erfüllen, z.B. einen Überblick verschaffen oderbestimmte Detailinformationen wiedergeben. Bezüglich dieses Zwecks werdendie entsprechenden zu beschreibenden Modelle vom Erzeuger gewählt bzw. ge-bildet. Das nachfolgende Bild 3.20 zeigt eine Übersicht über die inhaltsbezogenenSystembeschreibungen.

inhaltsbezogene Systembeschreibung

zweckbezogene

Systembeschreibung

modellbezogene

Systembeschreibung

empfängerbezogene

Systembeschreibung

Bild 3.20: Übersicht inhaltsbezogene Systembeschreibung

Empfängerkreisbezogene Klasse von Systembeschreibungen. Bei der Erstel-lung einer Systembeschreibung wird die Wahl des Inhalts maßgeblich durch

53


den anvisierten Empfängerkreis bestimmt. Der Ersteller sollte optimalerweise,um dem Empfängerkreis gerecht zu werden, über eine konkrete Vorstellung vondessen Voraussetzungen und Interessen verfügen. Der Empfängerkreis kann zu-nächst in menschlichen und maschinellen Empfängerkreis unterschieden wer-den.

Zwar kann bei maschinellen Empfängern keine Rede vom Verständnis des beschrie-benen Systems sein, aber eine Maschine kann das von ihr verlangte Formen-spiel durchführen. Durch die anschließende Interpretation der Formen durch denMenschen erfüllt diese Klasse von Systembeschreibungen ihren Zweck. Das Vor-handensein einer für die Maschine verfassten Systembeschreibung ist Grundvor-aussetzung bei programmierten Systemen. Da Menschen diese Systembeschrei-bung erstellen, pflegen und warten müssen, d.h. auch verstehen müssen, ist esangebracht, auch die für die Maschine gedachte Systembeschreibung so zu ver-fassen, dass sie auch von Menschen entsprechend leicht gelesen und somit ver-standen werden kann. Diese Ansicht teilt auch McConnell in [McConnell 93]:„Programming is communicating with another programmer first, communica-ting with the computer second.“, S. 764. Die Form der Systembeschreibung istentsprechend abhängig vom Abwickler und üblicherweise von der vorgegebe-nen formalen Sprache27. Die Systembeschreibung für den maschinellen Empfän-ger muss entsprechend der Syntax der formalen Sprache konsistent sein und fürden Zweck des programmierten Systems entsprechend vollständig sein.

Der menschliche Empfängerkreis stellt dementsprechend den wichtigsten Empfän-gerkreis dar. An der Entwicklung, inkl. Pflege, Wartung und Weiterentwicklung,partizipieren viele Beteiligte in unterschiedlichsten Rollen. Jede Rolle setzt imSpeziellen unterschiedliche Modelle voraus, da sich die Interessen und somit dieSichten auf das System unterscheiden. Prozessmodelle definieren eine Vielzahlunterschiedlicher Rollen. Häufig vorkommende Rollen sind z.B. Anforderungs-verantwortlicher (engl. requirements engineer oder requirements specifier), Soft-warearchitekt (engl. software architect), Entwickler (engl. implementer), Projekt-manager (engl. project manager) und Tester (engl. tester). Der Nutzer des Systems(engl. user) und die Rollen, die bezüglich der Systemnutzung relevant sind, wieInstallateur und Systembetreiber, sollten dabei nicht vergessen werden. Daherwird der menschliche Empfängerkreis nochmals untergliedert in zwei Personen-kreise:

• – interner Empfängerkreis – dessen primäre Aufgabe die Beteiligung an derEntwicklung, Pflege, Wartung und Weiterentwicklung des Systems ist, und

• – externer Empfängerkreis – dessen primäre Aufgabe die Nutzung des Sys-tems ist. D.h. die Nutzung der Funktionalität des Systems durch den Nut-

27Im Rahmen der Entwicklung komplexer programmierter Systeme wird bei der Beschreibungüblicherweise auf Hochsprachen zurückgegriffen, die komfortablere und leichter zu formulieren-de und damit leichter verständliche Anweisungen bzw. Aussagen erlauben. Die in einer Hoch-sprache angefertigten Beschreibungen müssen meist mittels Werkzeugen in eine vom Abwicklerdirekt verständliche Form transformiert werden, um das entsprechende programmierte Systemzu ermöglichen.

54


zer aber auch die Durchführung der notwendigen administrativen Maß-nahmen oder die Kaufentscheidung.

Nicht jede Rolle muss zwangsläufig für sich isolierte Modelle haben. Im Gegen-teil, viele Modelle überschneiden sich mit Teilen anderer Modelle. Man denkez.B. an die Modelle, die vorwiegend bei den Softwarearchitekten beheimatet sind.Diese müssen sich zu großen Teilen bei den Modellen der Entwickler wiederfin-den lassen. Weiterhin gibt es mit dem System erfahrene Personen, Experten, undunerfahrene Personen, Einsteiger. Eine Unterscheidung zwischen erfahrenen undunerfahrenen Personen ist eine starke Vereinfachung, da sich eine mit dem Sys-tem gänzlich unvertraute Person nach und nach Wissen ansammelt bis zu demPunkt sehr vertraut damit zu sein. Es können, je nach Bedarf, durchaus viele ver-schiedene Stufen der Vertrautheit unterschieden werden. Die jeweiligen persönli-chen Modelle unterscheiden sich bei mit dem System unerfahrene und erfahrenePersonen naturgemäß stark in Hinsicht auf Zusammenhänge und Detaillierungs-grad. Ein für die meisten Beteiligten übergeordnetes Verständnis und die damitverbundenen und beschriebenen Modelle sind für das Gelingen der Kommuni-kation und damit auch für das Gelingen des Projekts äußerst wichtig. D.h. fürbestimmte übergeordnete Modelle gibt es das Bedürfnis diese einem größerenKreis von Beteiligten als Systembeschreibung zugänglich zu machen. Eine Stu-die über die Nutzung und Wartung von schriftlichen Systembeschreibungen vonForward in [Forward, Lethbridge 02] stellt fest: „Overall, the most popular docu-ment was the specification document, whereas quality and low-level documentswere at least consulted [...].“, S. 30. Die Form der Systembeschreibungen sollte aufden menschlichen Empfängerkreis und dessen Bedürfnisse zugeschnitten sein. Inder Praxis wird auf nicht-formale und semi-formale Systembeschreibungen zu-rückgegriffen. Die Systembeschreibungen sind dabei in der Regel weder in dergewählten Form noch der gewählten Sprache konsistent. Hinzu kommen auchinhaltliche Inkonsistenzen bei den Systembeschreibungen, wie auch Parnas et al.in [Parnas et al. 94] festhalten: „Most documentation encountered in industry isvague, inaccurate, and incomplete.“, S. 949.

Zweck- bzw. interessenbezogene Klasse von Systembeschreibungen. Eng mitdem Empfängerkreis verbunden ist der Zweck der Systembeschreibung, ausSicht des Erstellers, und das Interesse, aus Sicht des Empfängers. Über eine kon-krete Reihenfolge, ob bei der Erstellung einer Systembeschreibung zunächst derEmpfängerkreis oder zunächst der Zweck berücksichtigt wird, kann kontroversdiskutiert werden. Auf jeden Fall wirken sich diese beiden Kriterien auf die Er-stellung der Systembeschreibung aus. Je nach Interesse des Empfängers wird die-ser sich eine vielversprechende Auswahl an Systembeschreibungen zusammen-stellen. D.h. ein Empfänger hat durchaus, bedingt durch sein Interesse, bestimmteErwartungen an eine Systembeschreibung. Ein Ersteller der Systembeschreibunghingegen verfolgt einen gewissen Zweck, den er auf die von ihm erwarteten In-teressen der Empfänger abstimmt. Dies ist letztlich eine Quelle von Inkonsisten-zen, da die erwarteten Inhalte von den beschriebenen Inhalten abweichen.

55


Für Systembeschreibungen, wie meist auch für andere Arten von Beschreibun-gen, kann zwischen verschiedenen Detaillierungsgraden unterscheiden werden.Häufig anzutreffen sind

• einführende Beschreibungen,

• fortführende Beschreibungen mit mehr Detailinformationen und

• Beschreibungen zur gezielten Suche

von Informationen (im Falle von schriftlichen Systembeschreibungen sind die-se als Nachschlagewerke bekannt) mit dem höchsten Detaillierungsgrad. Je nachBedürfnis lassen sich weitere Detaillierungsgrade einführen. Prinzipiell hängt dieAnzahl der interessierten Empfänger mit dem Detaillierungsgrad zusammen. Eserscheint natürlich, dass je höher der Detaillierungsgrad ist, desto weniger Emp-fänger interessieren sich dafür bzw. werden angesprochen, wie in Bild 3.21 gra-phisch verdeutlicht. Man denke an den Empfängerkreis der unmittelbar an derEntwicklung Beteiligten. Eine relativ abstrakte Vorstellung des zu entwickelndenSystems sollte bei jedem dieser Beteiligten existieren. Sehr detaillierte Vorstellun-gen betreffen teilweise nur wenige Entwickler und sind für die anderen primäruninteressant.

Detaillierungsgrad der Beschreibung

interessierter Anteil

der Beteiligten

(Je detaillierter die Beschreibung, desto weniger Interessenten)

Bild 3.21: Qualitativer Anteil von Empfängern abhängig vom Detaillierungsgradder Systembeschreibung

Der Begriff Systembeschreibung, bezieht sich auf die Modelle des Systems. D.h.Beschreibungen, die den Aufbau, die Funktionsweise, die Nutzung oder Instal-lation usw. des Systems erläutern, sind Systembeschreibungen. Dem Zweck bzw.dem Interesse entsprechend soll zwischen einer Produktbeschreibung, die vorallem mit der Nutzung des Systems einhergeht, und einer technischen System-beschreibung, die vor allem den Aufbau und die Funktionsweise des Systemsbeleuchtet, unterschieden werden.

Produktbeschreibungen sind primär für den externen Empfängerkreis gedacht. Ty-pische Vertreter dieses Empfängerkreises sind unerfahrene und erfahrenere Nut-zer, Adminstratoren und Käufer, die den Einsatz des Systems entscheiden. Für

56


diesen Empfängerkreis stellen die Beschreibungen die ausschließlichen Quellenfür Informationen dar. Für die Nutzer des Systems gibt es in der Regel drei unter-schiedliche Arten von (schriftlichen) Systembeschreibungen, die sich vorwiegendin ihrem Detaillierungsgrad unterscheiden. Laut Barker in [Barker 03] (S. 19 ff.)sind diese:

• einführende (engl. tutorial),

• unterstützende (engl. procedural) und

• zum Nachschlagen geeignete (engl. reference) Beschreibungen.

Prinzipiell geht es bei der einführenden Beschreibung darum, die grundlegen-den Eigenschaften und Funktionen des Systems zu erläutern und richtet sichvor allem an unerfahrene Nutzer. Die unterstützende Beschreibung stellt auf-wendigere oder selten genutzte Funktionen dar. Für erfahrene Nutzer habensich, die zum Nachschlagen geeigneten Beschreibungen, die die Informationenz.B. im Falle von schriftlichen Beschreibungen alphabetisch sortiert anbieten, be-währt. Im klassischen Fall ist der Nutzer nicht an näheren technischen Beschrei-bungen interessiert. Je nach System sollte dennoch zwischen nicht technischenNutzern und technischen Nutzern unterschieden werden. Für technische Nut-zer, man denke an Systeme wie z.B. an Frameworks, werden die Beschreibun-gen mit sehr viel mehr fachspezifischen Begriffen gefüllt sein. Nichtsdestotrotzsind es Nutzer des Systems, wie es auch Østerbye in [Østerbye 99] (S. 172) fest-stellt. Technischen Nutzern des Systems werden z.B. API28 Beschreibungen alszum Nachschlagen geeignete Beschreibungen angeboten. Diese Beschreibungenunterscheiden sich somit je nach Nutzerkreis stark und haben voneinander sehrabweichende Anforderungen. Die Beschreibungen, insbesondere Schriftliche, ha-ben aufgrund des externen Charakters auch eine gewisse rechtliche Bedeutung.Bei Inkonsistenzen zwischen dem beschriebenen Verhalten des Systems und demtatsächlichen Verhalten des Systems können Garantieansprüche entstehen wie esz.B. Kaner in [Kaner 03] diskutiert, da für die Nutzer die (schriftliche) Beschrei-bung als Ausgangspunkt angesehen wird und nicht das System. Lastenhefte z.B.sind häufig Bestandteil von Verträgen. Für Systemadministratoren sind z.B. In-formationen über Installation und den Betrieb (z.B. Konfigurations- und Einstel-lungsmöglichkeiten des Systems) interessant. Diese werden ebenfalls häufig inmehrere Detaillierungsgrade unterschieden. Für Käufer des Systems sind nebenden Kosten auch die Systembeschreibungen relevant, da die Kaufentscheidungdarauf basiert. Häufig haben diese Beschreibungen einen ungenauen Charakterund bestehen meist aus Aussagen zu den Vorteilen des Systems und wie es sichvon anderen Systemen abgrenzt.

Technische Systembeschreibungen sind vorwiegend für den internen Empfänger-kreis bestimmt. Sie enthalten alle notwendigen Beschreibungen, die für das Ver-ständnis und die Arbeit am System, d.h. an der Entwicklung, Pflege, Wartung

28API steht für Application Programming Interface. Damit sind die vom System angebotenenSchnittstellen zusammengefasst, die von Entwicklern eines anderen Systems verwendet werdenkönnen.

57


und Weiterentwicklung, notwendig sind. Dazu gehören z.B. Anforderungsbe-schreibungen, Beschreibung den konzeptionellen Aufbau und die Funktionswei-se des Systems betreffend, das Design der Systembeschreibung für den maschi-nellen Empfängerkreis sowie Testbeschreibungen. Da es auch bei diesem Emp-fängerkreis mit dem System erfahrene und unerfahrene Personen gibt, wird eineUnterscheidung der Detaillierungsgrade auch bei technischen Systembeschrei-bungen benötigt. Dies bestätigt ebenfalls Sommerville in [Sommerville 02]: „Likeuser documentation, it is important that system documentation [schriftliche tech-nische Systembeschreibungen] is structured, with overviews leading the readerinto more formal and detailed descriptions of each aspect of the system.“, S. 6.Neben den detailreichen Beschreibungen, die vorwiegend zur Lösung konkre-ter Aufgaben beitragen, ist ein übergeordnetes Verständnis des Systems hilfreich,um Entscheidungen und Lösungen optimal in den Gesamtkontext einzubetten.Über ein solches übergeordnetes Verständnis des Systems sollte jeder an der Um-setzung Beteiligte verfügen, wie auch Ameneyro et al. in [Ameneyro et al. 84]befindet und diese Beschreibung als „conceptual nucleus“ einführt. Eine solcheBeschreibung soll im Folgenden als Konzeptbeschreibung bezeichnet werden. Zuden technischen Systembeschreibungen gehören auch Beschreibungen bezüglichder Struktur der formalen Systembeschreibung (das Programm) für den (maschi-nellen) Abwickler. Diese Beschreibungen werden auch als Designbeschreibungenbezeichnet, siehe auch Bild 3.22. Genau betrachtet sind dies Beschreibungen vonBeschreibungen und nicht Beschreibungen eines (informationellen) Systems, dawie Jackson in [Jackson 95] feststellt „Programs are descriptions of desired ma-chines [...]“, S. 285. Aufgrund der Komplexität heutiger Programme, sind derenBeschreibungen auf abstrakter Ebene ein wichtiges Arbeitsmittel für den Um-gang mit den Programmen. Für die abstrakte Beschreibung von Programmenwird heute für die graphischen Darstellungen die Unified Modelling Langua-ge (UML) (vgl. [OMG] und [Booch et al. 98]) als defacto Standard benutzt, wie esKeller in [Keller 03] (S. 45 ff.) feststellt. In der Industrie werden technische Sys-tembeschreibungen praktisch alle in natürlichen Sprachen verfasst und werdenteilweise mit nicht-formalen oder semi-formalen graphischen Darstellungen, wiedie Unified Modelling Language (UML), begleitet. In verschiedenen Studien, wiez.B. von Olsson und Runeson in [Olsson, Runeson 02], wird dies bestätigt.

Mit Hilfe der Produktbeschreibung und technischen Systembeschreibungen, dieletztlich Modelle vermitteln, soll es den Personen ermöglicht werden, bestimm-te Aufgaben zu erledigen. Jeder Empfängerkreis hat ein ganz bestimmtes Auf-gabengebiet inne, daher rührt deren organisatorische Aufteilung. Für jeden ein-zelnen Empfängerkreis können die zugeordneten Aktivitäten beschrieben wer-den, um die Empfänger optimal zu unterstützen. Diese Art der Beschreibungenist als Aufgabenorientierung (engl. task orientation) bekannt, siehe auch Barkerin [Barker 03]. Diese hat vor allem bei Produktbeschreibungen Fuß gefasst, dasich die Nutzungsszenarien (die vom System vorgesehene Interaktion) und derZweck des Systems relativ gut beschreiben lassen. Die Nutzer des Systems sindnicht an einem tieferen Verständnis des System interessiert, sondern suchen nachschnellen Problemlösungen. Interessanterweise gilt dies auch für die technischenNutzer, wie in der Studie von Nykaza et al. in [Nykaza et al. 02] beobachtet wur-

58


technische

Systembeschreibung

Konzept-

beschreibung

Design-

beschreibung

detaillieren

programmiertes

System

formale

Beschreibung(Software)

wird durch

Abwicklung zu

beschreibt

primär

beschreibt

primär

Bild 3.22: Zusammenhänge Konzept- und Designbeschreibung

de. Dennoch ist laut dieser Studie für die technischen Nutzer des Systems einübergeordnetes Verständnis wichtig. Mittels aufgabenorientierten Beschreibun-gen kann man einzelne Personen aus einem bestimmten Empfängerkreis effektivbei der Aufgabenlösung unterstützen, indem die fast komplette Lösung präsen-tiert wird. Man kann jedoch nicht davon ausgehen, dass alle möglichen real auf-tretenden Aufgaben mit ihren Lösungen beschrieben werden. Weiterhin hat nichtjeder Personenkreis leicht beschreibbare Aufgaben. So haben Software Ingenieu-re die Aufgabe konzeptionelle Lösungen zu finden, die z.B. bestehende Systemeberücksichtigen müssen. Diese kreative Arbeit, die Suche nach einer möglichstsinnvollen Zusammenstellung vorhandener Systeme oder Systemteile mit nochzu erarbeitenden Systemen oder Systemteilen stellt eine Herausforderung dar,die mit Nichten als fertige Beschreibung existieren wird. Diese würde die eigent-liche Arbeit der Software Ingenieure überflüssig machen.

Neben Produktbeschreibungen und technischen Systembeschreibungen könnenbegleitende Beschreibungen existieren. Diese soll im Folgenden Prozessbeschrei-bung genannt werden. In der Regel ist dies eine Beschreibung des verwendetenProzesses, die der Entwicklung, Pflege, Wartung und Weiterentwicklung zugrun-de liegt. Ein Prozess (hier soll der Begriff aus dem Software Engineering gelten)ist ebenfalls ein informationelles System. Daher können für seine Beschreibungdie gleichen Kriterien und Ansätze, wie für die Entwicklung eines Solchen, an-gewendet werden. Weiterhin ist jede Produktbeschreibung von einem Prozessabhängig, da ein Prozess definiert, welche Beschreibungen für welchen Empfän-gerkreis wann zu erstellen sind. D.h. es existieren Beschreibungen, die nur füreinen bestimmten Zeitraum für einen bestimmten Personenkreis relevant sind.

Zusammenfassend werden die vorgestellten zweck- bzw. interessenbezogenenSystembeschreibungen in Bild 3.23 dargestellt.

59


zweckbezogene Systembeschreibung

technische

Systembeschreibung(interne Empfänger)

Prozessbeschreibung(interne Empfänger)

Produktbeschreibung(externe Empfänger)

• Tutorial

• Referenz

• Konzeptbeschreibung

• Designbeschreibung

Bild 3.23: Übersicht zweck- bzw. interessenbezogene Systembeschreibung

Eine ähnliche Unterscheidung der Klassen findet sich auch bei Sommerville in[Sommerville 02]. Im weiteren Verlauf dieser Arbeit wird insbesondere auf dietechnischen Systembeschreibungen eingegangen.

Modellbezogene Klasse von Systembeschreibungen. Sind der Empfänger-kreis und der Zweck der Systembeschreibung bestimmt, ist der Inhalt der Be-schreibung relativ eng festgelegt. Die inhaltliche Strukturierung der Beschrei-bung wurde bisher nicht diskutiert. Der Zweck einer Systembeschreibung dientder Vermittlung der beschriebenen Modelle. Andere Beschreibungen, die ohneBerücksichtigung eines Systemverständnisses Informationen weitergeben, wiez.B. reine für das Nachschlagen entstandene Beschreibungen haben andere An-forderungen und werden an dieser Stelle nicht berücksichtigt. Ein Ersteller einerSystembeschreibung greift zur Vermittlung der Modelle auf seine persönlichenModelle zurück und versucht die Auswahl aus seinen persönlichen Modellenanhand der Interessen des Empfängerkreises durchzuführen. Bei diesem Vor-gang sollten idealerweise die bereits vorhandenen Modelle des Empfängerkreisberücksichtigt werden. So ist eine einführende Beschreibung für die mit dem Sys-tem vertrauten Personen unnötig, da diese das beschriebene Verständnis bereitsbesitzen sollten. Damit einher geht auch die Verwendung von Begriffen, die Teilder Modelle sind. Unterschiedliche Begriffe z.B. aus der Domäne, die mit demselben Namen identifiziert werden, sind Quellen für Inkonsistenzen.

Für die Strukturierung einer Beschreibung kann auf die Struktur der Modell-hierarchie zurückgegriffen werden, wodurch sich die beiden Strukturen sehr äh-neln können. Die ausgewählten Modelle und deren Zusammenhänge bestimmendie zu beschreibenden Einheiten, sowie deren Erscheinungsreihenfolge. Beschrei-bungen können somit zur Struktur einer Modellhierarchie zugeordnet werden. Eskönnen somit anhand der Modellhierarchie Beschreibungen unterschieden wer-den, die Modelle passend zu einer bestimmten Sicht, passend zur einer Traversie-rung der Modellhierarchie oder passend zu den Systemausschnitten, Auflösun-gen und Betrachtungsebenen beschreiben.

60


3.3.3 Dokument als schriftliche Systembeschreibung

3.3.3.1 Dokument

Die weitverbreiteste und z.Z. wichtigste Form von Systembeschreibungen ist dieschriftliche Systembeschreibung. Das hängt hauptsächlich mit dem speicherndenCharakter zusammen und mit der Vertrautheit mit dieser alltäglichen Form. DerBegriff Dokument ist allgemein eng mit schriftlichen Beschreibungen verbunden.Laut [Müller 82] ist der Begriff als Urkunde, Schriftstück oder gar als Beweisstückbzw. Beweis zu verstehen. Von diesem Aspekt aus kann die Bedeutung und Wich-tigkeit von schriftlichen Systembeschreibungen nochmals unterstrichen werden.Betrachtet man unterschiedliche Definitionen des Begriffs Dokument, wir z.B. bei[Claus, Schwill 03] oder [Zuck 90], stellt man fest, dass es immer eine Überein-stimmung gibt. Als Oberbegriff für die verschiedensten Arten von Dokumenten(z.B. auch der Dokumentarfilm) geht es um das Festhalten von Informationen fürden späteren Gebrauch. Darunter fällt die Verbreitung von Modellen und Infor-mationen für die Entwicklung aber auch für die Pflege und Wartung sowie dieWeiterentwicklung des Systems. Der Begriff Dokumentation soll als eine Zusam-menstellung von Dokumenten verstanden werden. Die Begriffe Nachdokumenta-tion und Mitdokumentation beziehen sich auf den Zeitpunkt der Erstellung derDokumente in Bezug auf das zu entwickelnde System (siehe auch Bild 3.24). Do-kumente der Nachdokumentation sind nach der Entwicklung des Systems ent-standen und können Ergebnisse der Analyse darstellen, oder sie wurden unmit-telbar im Anschluss an die Entwicklung erstellt. Die Dokumente der Mitdoku-mentation entstehen während der Entwicklung eines Systems und haben zumZiel, die Entwicklung zu begleiten. Jedes Dokument, unabhängig ob es Teil ei-ner Nachdokumentation oder Mitdokumentation ist, kann nur sinnvoll nach derModellbildung entstehen und ist somit immer eine Art von Nachdokumentationder Modelle. Zwar können Modelle durch die Erstellung von Dokumenten nochreifen, aber im Kern existierten sie bereits vor der Erstellung.

Dokumentation(als Erstellung von Dokumenten)

Mitdokumentation(Erstellung während Entwicklung des Systems)

Nachdokumentation(Erstellung nach Entwicklung des Systems)

Bild 3.24: Übersicht Dokumentation

Der Begriff Dokument oder Dokumentation wird bei der Beschreibung program-mierter Systeme weiter unterteilt. Besonders gängig sind Softwaredokumentation(engl. software documentation) bzw. technische Dokumentation (engl. technical do-cumentation) und Systemdokumentation (engl. system documentation). Die Un-terscheidung ist in der Regel die Folgende: Systemdokumente sind technischeSystembeschreibungen, wohingegen die Übrigen Produktbeschreibungen dar-stellen. Leider ist diese Unterscheidung nicht eindeutig, da diese Begriffe un-terschiedlich aufgefasst werden. So wird manchmal der Begriff Softwaredoku-

61


mentation als Oberbegriff über alle Dokumente, die mit einem programmiertenSystem zu tun haben, verstanden. Teilweise wird der Begriff technische Doku-mentation auch als Produktbeschreibung verstanden. Im Allgemeinen lassen sichdiese Begriffe aus dem Kontext sehr einfach und eindeutig technischen System-beschreibungen oder Produktbeschreibungen zuordnen. Weitere Unterteilungensind geläufig, um bestimmte Aspekte mehr hervorzuheben, wie z.B. Software-wartungsdokumentation (engl. software maintenance documentation.) Im wei-teren Verlauf der vorliegenden Arbeit soll unter Dokument eine technische Sys-tembeschreibung verstanden werden.

Die Wichtigkeit von Dokumenten bei der Entwicklung, Wartung, Pflege und Wei-terentwicklung ist vor allem bei komplexen Systemen allgemein anerkannt. Vis-conti und Cook halten in [Visconti, Cook 00] fest: „Empirical studies have shownthat poor quality, out of date, or missing documentation is a major cause of de-fects in software development and maintenance [...]. Thus, documentation is akey component in software quality and improving the documentation processwill have considerable impact on improving the quality of software. “, (S. 2). BeiDokumenten, wie bei anderen Formen von Systembeschreibungen wie z.B. dermündlichen Systembeschreibung, sind zwei Aspekte zu unterscheiden:

• zum Einen die Erstellung von Dokumenten im Kontext des Erstellungspro-zesses für Dokumente eingebettet in herkömmliche Prozesse und

• zum Anderen die Nutzung von Dokumenten. Häufig sind Dokumente dieeinzigen „greifbaren“ Ergebnisse von Analysen und für teilweise langeZeiträume während der Synthese.

Nichtelektronische Dokumente sind auf Texte, Tabellen, Listen, Abbildungen etc.beschränkt. Heute steht ein reichhaltiges Angebot von Medien im Bereich derelektronischen Dokumente zur Verfügung, die auch gemischt innerhalb eines Do-kuments zum Einsatz kommen können. Z.B. können neben Text und Abbildun-gen auch Audio- und Videoaufzeichnung verwendet werden und Dokumentekönnen mit den entsprechenden Anzeigesystem auch interaktiv werden. Unab-hängig von diesen technischen Möglichkeiten bleibt der Sinn und Zweck vonDokumenten unangetastet. Klassische Dokumente (hier schriftliche technischeSystembeschreibungen) bestehend aus Texten, Tabellen, Listen, Abbildungen etc.überwiegen nach wie vor. Vorteile der elektronischen Dokumente sind die leich-tere Verbreitbarkeit, leichtere Wartbarkeit und die gesunkenen Kosten bei der Er-stellung, da einige Arbeitsschritte im Gegensatz zu nicht elektronischen Doku-menten entfallen, wie Holtzman in [Holtzman 93] (S. 123 ff.) festhält.

Dokumente werden erzeugt, damit Personen29 das System verstehen können,idealerweise ohne die Ersteller der Dokumente oder des Systems zu Rate zu zie-hen. Dies würde im idealen Fall bedeuten, dass die Leser der Dokumente zeit-lich und räumlich von den Erstellern der Dokumente bzw. des Systems entkop-pelt sein könnten. Dies hat nach bisherigen Erfahrungen im Software Enginee-ring nicht zufriedenstellend funktioniert, oder ist mit erheblichem Mehraufwand

29Darunter sollen Personen fallen, die zum internen Empfängerkreis gehören.

62


insbesondere im Bereich der Kommunikation verbunden, siehe auch Keller in[Keller 03]. Weiterhin bedeutet ein Verständnis über das System noch lange nicht,dass über alle Informationen über das System verfügt wird. Die Modelle des Sys-tems sind ja Abstraktionen über die Informationen zum System. Zugleich kön-nen Dokumente in der Regel nicht alle Informationen beinhalten, die ein Leser jesuchen wird. Dafür ist der Raum der unterschiedlichen Interessen und Fragestel-lungen der Leser einfach zu groß, vor allem wenn man bedenkt, dass das Lesenüberhaupt erst nach der Erstellung eines Dokuments möglich ist. Zum Beispielwird in keinem Dokument direkt die Antwort enthalten sein, wie ein bestimmterSoftwarefehler zu beheben ist. Dies hängt unter anderem damit zusammen, dassder oder die Ersteller des Dokuments nicht über dieses Wissen verfügten, auchwenn sie die Existenz von Softwarefehlern nicht überrascht hätte. Damit verbun-den ist die Frage nach dem Detaillierungsgrad der Dokumente. Es ist bekannt,dass unterschiedliche Dokumente unterschiedliche Detaillierungsgrade besitzenkönnen und sich der Anteil der interessierten Leser abhängig vom Detaillierungs-grad ändert. Je höher der Detaillierungsgrad ist, desto kleiner der Anteil der inter-essierten Leser. In Abhängigkeit des Detaillierungsgrades variiert auch die Häu-figkeit der Änderung der Sachverhalte, wie Bild 3.25 zeigt.


Häufigkeit der Änderungen der Sachverhalte

(Je detaillierter die Beschreibung, desto häufiger Änderungen)

Bild 3.25: Häufigkeit der Änderungen von Sachverhalten in Abhängigkeit zumDetaillierungsgrads des Dokuments

Die Änderung der Sachverhalte bezieht sich auf das modifizierte System, dasständig gepflegt, gewartet und weiterentwickelt wird. Die Dokumente geben imidealen Fall Sachverhalte bzw. Abstraktionen der Sachverhalte wieder. Es gibt al-so einen Kern, der sich relativ selten ändert. Diesen zu beschreiben ist der Zweckder Konzeptdokumente. Diese Dokumente enthalten also Beschreibungen von Mo-dellen, sich über einen längeren Verlauf der Entwicklung, Weiterentwicklung,Pflege und Wartung relativ selten ändern und für fast alle Beteiligten (internerEmpfängerkreis) wissenswert sind.

Solche Konzeptdokumente werden in der Praxis als Bestandteil der Architekturbe-schreibungen erstellt, wie die Studie von Keller in [Keller 03] ergeben hat (S. 64 ff.).Dort werden sie auch als besonders wichtiger Pfeiler der Architekturbeschreibun-gen gewertet, was sich mit den Überlegungen zur Anzahl der interessierten Leser

63


und Änderungshäufigkeit deckt. Der Begriff Architektur sowie die zugehörigenDarstellungsmittel und damit die Modellierungsansätze sind sehr unscharf. DieStudie hat auch gezeigt, dass für die Erstellung von Konzeptdokumenten vor-wiegend nach der Intuition des Erstellers – dem Architekten – verfahren wird.Laut der Studie gibt es also keinen standardisiert eingesetzten Modellierungs-ansatz außer den Fundamental Modeling Concepts (FMC) für diesen Bereich. Inden, im Rahmen dieser Arbeit, durchgeführten Fallstudien (siehe Kapitel 5) lagenkeine schriftlichen Konzeptbeschreibungen vor, obwohl Umfang und Größe derProjekte vergleichbar sind.

3.3.3.2 Struktur von Dokumenten

Wie der Begriff Dokumentation andeutet, wird bei der Entwicklung und Evolu-tion eines Systems üblicherweise nicht nur ein Dokument erstellt. Die Erstellungmehrerer Dokumente hat viele Gründe. Im Folgenden seien einige der Wichtigs-ten aufgeführt:

• Aufteilung abhängig vom Empfängerkreis30

• Inhaltliche Trennung auch abhängig vom Detaillierungsgrad

• Arbeitsteilung bei der Erstellung von Dokumenten

• Zeitpunkt der Erstellung und dadurch schnellere Befriedigung der Nach-frage

• Aufteilung da der Umfang eines Dokuments zu groß wäre

Daraus ergeben sich eine Reihe von Interdokumentbeziehungen, von Beziehungenzwischen Dokumenten und Dokumentteilen verschiedener Dokumente. Prinzi-piell unterscheiden sich diese nicht von den Intradokumentbeziehungen, also vonden Beziehungen der Dokumentteile innerhalb eines Dokuments. Die Beziehun-gen zwischen Dokumenten und Dokumentteilen haben eine direkte Übereinstim-mung mit den Beziehungen in der Modellhierarchie. Die Modellhierarchie unddie Modelle selbst dienen als das strukturierende Mittel, da sie letztlich den Inhaltbestimmen. Teilweise geben Prozessmodelle auch Beziehungen zwischen Doku-menten vor. Man denke an Forderungen jede Anforderung des Systems auf Desi-gnelemente abbilden zu können. Weitere Interdokumentbeziehungen sind expli-zite Beziehungen wie z.B. ein direkter Verweis aus einem Dokument in ein ande-res. Je nach Modellierungsansatz und teilweise Prozessmodell unterscheiden sichdiese Beziehungen. Es existieren keine feste Regeln wonach eine Aufteilung derSystembeschreibung auf mehrere Dokumente zu erfolgen hat. Es haben sich al-lerdings durch die verschiedenen Prozessmodelle und die Praxis Dokumenttypenetabliert. Beispiele hierfür sind die Architekturbeschreibungen und Designbe-schreibungen. Durchaus zweckmäßig ist es, die Modelle eines Teilsystems bei

30Es wird hauptsächlich der interne Empfängerkreis und dessen weitere Aufsplittung betrach-tet.

64


Wechsel der Betrachtungsebene in eigenständigen Dokumente zu beschreiben.Ein Kommunikationssystem, das das zu entwickelnde System für seine Kommu-nikation nutzt, wurde nicht zwangsläufig nur für dieses konkret zu entwickelndeSysteme erstellt, sondern kann auch für weitere Systeme genutzt werden. DieseEigenschaft des genutzten Kommunikationssystems führt meist zu entkoppeltenBeschreibungen in eigenständigen Dokumenten.

Dokumente selbst besitzen eine Struktur und bestehen aus Teilen. Der Ratio-nal Unifed Process (RUP) definiert den Begriff Artefakt (eng. artifact), siehe[Kruchten 04] (S. 40 ff.), und verbindet damit hauptsächlich festgehaltene Infor-mationen wie Diagramme, Diagrammelemente, Softwarefehlerbeschreibungenund Projektpläne. Der RUP plädiert dafür, aus diesen Artefakten automatischDokumente zu erzeugen. Solch automatisch erstellten Dokumente sind gut alsReferenzdokumente, also zum Nachschlagen von Informationen geeignet. Fürein Dokument, das ein Verständnis für das Systeme vermitteln soll, wie die Kon-zeptdokumente, darf der Erfolg dieses Vorgehens allerdings angezweifelt wer-den. Zumal es weder einen etablierten Modellierungsansatz dafür gibt, noch ei-ne entsprechende Werkzeugunterstützung. Dokumente bestehen aus Teilen, wiez.B. den Artefakten, die nach einer bestimmten Ordnung strukturiert sind. DieseStruktur von Dokumenten ist allgemein bekannt. Sie umfasst z.B. Titel, Zusam-menfassung, Inhaltsverzeichnis, Kapitel, Unterkapitel, Abschnitt, Sätze, Wörter,Anhang, Tabellen, Tabellenzeilen, Listen, Index, Abbildungen, Diagramme undDiagrammelemente. Die inhaltliche Gliederung wiederum wird hauptsächlichvon den beschriebenen Modellen und der Modellhierarchie und somit von dengewählten Modellierungsansätzen bestimmt. Zusätzlich sind u.a. Einführungen,Zusammenfassungen und Glossare zu finden. Die Reihenfolge der Beschreibun-gen wird meist nach dem für das Verständnis benötigte Vorwissen bestimmt, dassich auch in den Modellen bzw. in der Modellhierarchie finden lässt.

3.3.3.3 Nutzung von Dokumenten

Erstellte Dokumente können Ihren Zweck erst erfüllen, wenn sie von Lesern ge-lesen und verstanden werden. Das Bilden und Modifizieren von Modellen gehörtzu den Kernaufgaben bei der Entwicklung und Evolution programmierter Syste-me und stellt die eigentliche Ingenieurleistung dar. Daher gehört neben der Er-stellung von Dokumenten, die die Modelle beschreiben, vor allem das Lesen derDokumente – also die Aufnahme und die sich daraus ergebende Modellbildung –zu den wichtigsten Tätigkeiten. Dies stellt auch Basili in [Basili 97] fest: „[...] rea-ding is a key, if not the key technical activity for verifying and validating softwarework products.“ (S. 7). Generell gilt die Aussage, wie in Bild 3.17 dargestellt, dassmehr Leser eines Dokuments existieren als Ersteller dieses Dokuments. Dies giltauch für die Software selbst, wie Parnas et al. in [Parnas et al. 94] festhalten: „Ifa software product is successful, the program will have many more readers thanwriters and will be studied and revised many times.“ (S. 948). Deshalb solltenernsthafte Erwägungen durchgeführt werden, falls eine verhältnismäßig kleineAnzahl von Lesern absehbar ist, ob und mit welchem Aufwand die Erstellungeines Dokuments vorangetrieben wird.

65


Je nach Detaillierungsgrad des Dokuments ist es nicht dafür konzipiert wordenkomplett von Anfang bis Ende gelesen zu werden, siehe auch Bild 3.26. Mandenke z.B. an Beschreibungen aller programmtechnischen Konstrukte wie Klas-sen (engl. classes) und deren Methoden (engl. methods) und Attribute (eng. attri-butes). Diese Beschreibungen von Anfang bis Ende zu lesen, ist eher langweiligund nicht zweckdienlich, da die meisten Dinge wieder vergessen würden. DerZweck einer solchen Beschreibung ist, sie als Referenz zu benutzen und somitgezielt nachschlagen zu können. Häufig enthalten solche Beschreibungen vor al-lem als Dokument in Buchform noch Einführungen bei denen die Struktur desDokuments erläutert wird, sowie einige grundsätzliche syntaktische Konventio-nen und die Klärung der wichtigsten Begriffe. Auch die Software selbst kann beikomplexen Systemen aufgrund der dafür benötigten Zeit nicht vollständig gele-sen werden. Aber auch bei weniger komplexen Systemen wird die zugehörigeSoftware von einer Person nur in den seltensten Fällen vollständig gelesen. BeiKonzeptdokumenten hingegen sollte das Lesen von Anfang bis zur gewünschtenVerständnistiefe durchgeführt werden. Bei solchen Dokumenten steht anhandder Modellhierarchie ein schrittweiser Aufbau eines grundlegenden Verständ-nisses im Vordergrund. Das bedeutet selbstverständlich nicht, dass solche Doku-mente ausschließlich von Anfang bis Ende gelesen werden können oder müssen.Je nach Vorwissen des Lesers genügen gezielt ausgesuchte Abschnitte. Generellkönnen nach dem ersten Lesen alle Arten von Dokumenten zum Nachschlagengenutzt werden. Die Art und Weise ein Dokument zu lesen, hängt nicht nur vonden Interessen des Lesers ab, sondern auch von der Lesehäufigkeit und der damitverbunden Vorkenntnis.


Eignung als

Referenz

(Je detaillierter die Beschreibung, desto eher als Referenz nutzbar)

Bild 3.26: Eignung der Beschreibung als Referenz in Abhängigkeit des Detaillie-rungsgrads der Beschreibung

Es ist allgemein anerkannt, dass Dokumente in der Pflege-, Wartungs- und Wei-terentwicklungsphase, von besonderer Wichtigkeit sind. Sie sollten alle relevan-ten Informationen enthalten, die für diese Phasen Bedeutung haben. Möglicher-weise arbeiten andere Personen während diesen Phasen am System oder die In-formationen wurden wieder vergessen. Aber auch in den anderen Phasen die-nen Dokumente als Kommunikationsgrundlage. Durch die Weitergabe der Mo-

66


delle können diese besprochen werden und Modellinkonsistenzen können auf-gedeckt werden. Diese Weitergabe ermöglicht u.a. auch die Arbeitsteilung undPlanung wichtiger Ziele (iterative Entwicklung). Es ist im Bereich des Software-Engineerings ein bekanntes Fakt, dass das Erkennen und Beseitigen von Proble-men in einem frühen Stadium sehr viel kostengünstiger ist, als die Beseitigung ineinem späteren Stadium, siehe [Boehm, Papaccio 88]. Die vorgestellten Vorteiledes Einsatzes von Dokumenten in frühen oder späten Phasen garantieren nicht,dass Dokumente erstellt, weitergeführt oder genutzt werden. Zum Beispiel stel-len Forward und Lethbridge in ihrer Studie über die Nutzung von Dokumentenfest: „[...] documentation maintenance, something that is shown to rarely occur.“,[Forward, Lethbridge 02] (S. 26).

Das Verständnis des Gelesenen ist von besonderer Wichtigkeit, denn die Doku-mente sollen die eigentliche Arbeit unterstützen und dabei die Kommunikations-aufgabe erfüllen. Es sind Fälle denkbar, bei denen Dokumente für die „Schubla-de“ erstellt werden und nicht weiter gelesen bzw. beachtet werden. In solchenFällen wird meist dem Wunsch des Auftraggebers, der die Erstellung solcherDokumente angefordert hat, nachgegangen. Die eigentliche Arbeit besteht – überalle Phasen – darin, zweckmäßige Lösungen im Kontext des bestehenden oderdes neuen Systems zu finden und deren Umsetzung sicherzustellen. Traditio-nell wird sich im Bereich des Software Engineerings mit Lesetechniken mit Fokusauf das Lesen von Programmen befasst. Dabei stehen Programmverständnis undInkonsistenzsuche im Vordergrund, siehe auch [Basili 97]. Festzuhalten ist, dasshauptsächlich auf folgende Fragestellung eingegangen wird: „How does the pro-gram reader construct a mental model of a program, whatever the exact nature ofthat model might be?“, [Deimel, Naveda 90], S. 11. Das bedeutet nicht, dass aufdas eigentliche Resultat – die persönlichen Modelle – nicht eingegangen wird.Neben empirischen Vergleichen zwischen verschiedenen Lesetechniken in Bezugauf die Anzahl der gefunden Fehler bzw. Inkonsistenzen, wird auch die Qualitätder persönlichen Modelle durch Verständnisfragen geprüft. Programme lassensich in der Regel schwerer lesen als andere Dokumente, denn der Lesefluß istnicht geradlinig wie in herkömmlichen Dokumenten. Ein komplexes Programmkann nicht einfach von oben nach unten gelesen werden. Es ist erforderlich zwi-schen vielen Stellen hin und her zu springen, da die Definitionen wichtiger Teileverstreut sein können. Gerade die objektorientierte Programmierung erschwertdie Lesbarkeit, da wiederverwendete Abschnitte (Vererbung) in anderen Teilengesucht werden müssen. Die Anwendung dieser Lesetechniken wurde auch fürUML Design Dokumente in [Laitenberger et al. 00] untersucht. Zu den wichtigs-ten Lesetechniken gehören:

• Bottom-Up und Top-Down Lesetechniken31

Bottom-Up und Top-Down sind wohl bekannte Prozesse beim Designent-wurf für Programme. Für die Lesetechniken gilt das Analoge. Bei derBottom-Up Lesetechnik wird durch das Lesen der einzelnen Programmzei-

31Bottom-Up Lesetechniken werden teilweise auch als Lesetechnik der schrittweisen Abstrak-tion (engl. stepwise abstraction) bezeichnet, wohingegen Top-Down Lesetechniken auch als Le-setechnik der schrittweisen Verfeinerung (engl. stepwise refinement) gesehen werden können.

67


len abstrahiert bis ein entsprechendes übergeordnetes persönliches Modellgebildet werden kann. Der umgekehrte Weg wird bei der Top-Down Le-setechnik angewendet. Dabei spielen Hypothesen eine wesentliche Rolle,d.h. es existieren schon persönliche Modelle, die durch das Lesen validiertbzw. nicht validiert werden. Unter Umständen kann ein persönliches Mo-dell nicht direkt überprüft werden. Wenn dies der Fall ist, werden die Mo-delle weiter verfeinert, teilweise durch das bereits gelesene, bis sie durchRückschlüsse direkt validierbar bzw. nicht validierbar sind.In der Praxis vermischen Leser beide Lesetechniken, da die strikte Anwen-dung einer einzigen Lesetechnik eine Einschränkung darstellen würde. BeiDokumenten kann die Bottom-Up Lesetechnik mit den Leserichtungen in-nerhalb eines Dokuments bzw. den Lesereihenfolgen bei mehreren Doku-menten verglichen werden.

• Systematische und bedarfsgesteuerte LesetechnikenHierbei wird unterschieden, welche Teile gelesen werden. Bei der systema-tischen Lesetechnik versucht der Leser alles zu erfassen und zu verstehen.Gerade beim Lesen von Programmen ist die Anwendung der systemati-schen Lesetechnik praktisch nicht anwendbar, wenn man den Umfang derProgramme und den damit verbundenen Detailreichtum berücksichtigt. ImGegensatz dazu wird bei der bedarfsgesteuerten Lesetechnik nur solangegelesen bis ausreichend Verständnis für den aktuellen Bedarf, z.B. einer Än-derung im Programm, aufgebaut ist.

• Szenarienbasierte LesetechnikenDie szenarienbasierte Lesetechnik (engl. scenario-based reading) stellt ge-nau genommen keine eigenständige Lesetechnik dar. Sie ist vielmehr alsGerüst zu verstehen, in dem verschiedenste Faktoren berücksichtigt wer-den sollen. Zu den Wichtigsten gehören die Art des zu lesenden Doku-ments, die Festlegung des Leseziels (Entdecken von Inkonsistenzen, Ver-ständnis aufbauen), die Auswahl der effektivsten Lesetechnik für das Zielund die Gesichtspunkte, nach denen gelesen werden soll. Daraus ergibt sichz.B. für das Lesen von Anforderungsdokumenten das Sicht-basierte Lesen(engl. perspective-based reading), bei dem z.B. aus der Sicht eines Anwen-ders die Anforderungen beleuchtet werden.

• „Schnelllesetechniken“Bei den Schnelllesetechniken geht es vor allem um die Zeitersparnis beimLesen. Dies wird z.B. durch ein Hilfsmittel, wie einem Stift oder Finger, er-reicht, der hilft, die aktuelle Leseposition leichter zu ermitteln. Neben derreinen Zeitersparnis beim Lesen können durch diese Lesetechniken, wie dasQuerlesen, Dokumente auf Relevanz hin evaluiert werden. Dadurch kannes vermieden werden, relativ viel Zeit in das Lesen eines irrelevanten Do-kumentes zu investieren.

Eine genauere Beschreibung der meisten hier vorgestellten Lesetechniken mitweiterführenden bibliographischen Verweisen lässt sich in [Deimel, Naveda 90]

68


und [Bennicke, Rust 04] (Kapitel 4) finden. Die vorgestellten Lesetechniken sindvor allem für Texte bestimmt. Für Abbildungen können nach Hungerford etal. so genannte horizontale und vertikale Lesetechniken identifiziert werden, sie-he [Hungerford et al. 04] und [Travassos et al. 99]. Bei der vertikalen Lesetechnikwerden die Aussagen der Abbildungen und deren direkt zugehörigen Beschrei-bungen z.B. der Architektur bzw. des Designs mit den Aussagen von beispiels-weise Anforderungsdokumenten verglichen. Bei der horizontalen Lesetechnikwerden vor allem Abbildungen und deren Beschreibungen aus derselben Klas-se von Beschreibungen miteinander verglichen. Innerhalb der horizontalen Lese-technik können speziell für das Lesen von Diagrammen noch das nebenläufige undsequentielle Lesen unterschieden werden. Beim nebenläufigen Lesen von Diagram-men werden mehrere Diagramme wechselseitig eingesehen. Beim sequentiellenLesen von Diagrammen wird ein Diagramm nach dem anderen eingesehen, wasin Bezug auf die Anzahl der entdeckten Inkonsistenzen weniger effektiv ist, alsdas nebenläufige Lesen von Diagrammen. Abbildungen, im speziellen Bildern,wird im Allgemeinen eine besonders hohe Aussagekraft zugesprochen. Dies äu-ßert sich z.B. im Sprichwort: „Ein Bild sagt mehr als tausend Worte.“32. Dies ent-spricht jedoch nicht der Erfahrung des Autors, wonach eine Abbildung vielmehreine Gedächtnisstütze bzw. ein Arbeitsmittel darstellt. Zusätzlich zur Abbildungsind weitere Informationen notwendig (abgesehen von der verwendeten Notati-on), um das abgebildete wirklich verstehen zu können. Die primären Erläuterun-gen sind meist in Textform und die Abbildungen fassen die wichtigsten Struk-turen noch einmal graphisch zusammen. Es ist möglich, dass die Abbildungenzusätzliche nicht im Text beschriebenen Informationen preisgeben. Zu ähnlichenAnsichten kommt auch Shook in [Shook 97].

Das Lesen von Dokumenten und damit der Prozess der Modellbildung ist einVorgang, der Zeit des Lesers in Anspruch nimmt. Durch Schnelllesetechnikenkann der Leser die Relevanz des Dokuments schnell einschätzen und kann sichggf. auf bestimmte Abschnitte beschränken. Ist ein Dokument zu umfangreich,kann es dazu kommen, dass es nicht gelesen wird. Dies hält auch Chafin in[Chafin 82] fest: „Another concept that is important is cost/benefit ratio. [...] Ifthe cost perceived to be high because the book is thick, it has excessive material,it is poorly witten, or it is poorly organized, he perceives that it will require agreat amount of effort and he will not use the documentation.“ (S. 37).

3.3.3.4 Erstellung und Evolution von Dokumenten

Dokumenterstellungs- und Evolutionsprozess. Die Erstellung von Dokumen-ten ist ein Prozess ähnlich dem der Entwicklung und Evolution programmier-ter Systeme. Man denke an die vorbereitenden Maßnahmen, die Erstellung ei-nes ersten Entwurfs, die Durchsicht und der Test der Dokumente, die Finali-sierung, die Verteilung der Dokumente und anschließende Pflege der Doku-mente. Da Dokumente nicht losgelöst vom zu erstellenden bzw. zu pflegen-

32Dieser Slogan stammt von einer amerikanischen Werbung in den 20er Jahren und wurdeanschließend zum Sprichwort, siehe [Hepting 99].

69


den und zu wartenden System betrachtet werden können, ist es sinnvoll, denProzess der Erstellung und Evolution der Dokumente in den Prozess der Ent-wicklung und Evolution des Systems einzubinden, siehe auch [Sickler 82] und[Stimely 90]. Bei ausgereiften Softwareentwicklungs- und Evolutionsprozessenist die Erstellung von Dokumenten ein fester Bestandteil, allerdings ohne näherauf den Prozess der Erstellung und Evolution der Dokumente einzugehen. Stime-ly in [Stimely 90] definiert, speziell für Nutzerdokumentation, folgende Phasenfür den Dokumentationerstellungs- und Dokumentationevolutionsprozesses:

1. Product definition: Festlegung welche Dokumente erstellt werden sollen.

2. User view design: Bestimmung des inhaltlichen Grundgerüsts für jeden Do-kumententyp, der erstellt werden soll.

3. Internal Design: Erstellen der Testfälle für die Dokumente. Finalisierung desDokumentenlayouts.

4. Implementation: Festlegung von Inhalt und Struktur der Dokumente. Ent-wurf der Kapitel. Erstellen von Testfällen für die einzelnen Kapitel undDurchführen der Testfälle. Korrekturen an den Kapiteln.

5. Integration: Zusammenstellung der Kapitel in Dokumente und Durchführender letzten Korrekturen. Durchführen der Testfälle für die Dokumente.

6. Acceptance testing: Testen der fast fertigen Dokumente bei potentiellen Nut-zern der Dokumente.

7. Production: Finalisierung der Dokumente, d.h. Erzeugen der finalen Version,die vervielfältigt und verbreitet werden soll.

8. Maintenance: Pflege und Wartung der Dokumente (inkl. Anpassung an neueSysteme).

Der vorgestellte Prozess bezieht sich auf Dokumente für den externen Empfän-gerkreis und berücksichtigt daher nicht andere Dokumenttypen, die für die Ent-wicklung des Systems selbst als Kommunikationsgrundlage dient. Diese werdenin den entsprechenden Phasen der Systementwicklung benötigt. Der vorgestell-te Prozess verdeutlicht aber, dass die Erstellung und Evolution der Dokumenteebenfalls ein Prozess ist, der einige Parallelen zur Softwareentwicklung aufweist.Dies ist natürlich, denn in beiden Fällen werden Beschreibungen erzeugt. Zu-meist sind Inkonsistenzen in Dokumenten weniger kritisch als in Programmen,die z.B. zu Datenverlust oder tatsächlichen Personen- und Sachschäden führenkönnen. Holtzman in [Holtzman 93] (S. 124) identifiziert als schwierigsten Punktim Prozess den Schritt des Designs (hier user view design), bei dem, wie er esnennt, Informationen in bedeutungsvolle Strukturen überführt werden. Dies ent-spricht dem Schritt der Modellbildung.

Ein populärer Ansatz bei der Erstellung von Dokumenten für Produktbeschrei-bungen ist der Minimalism (engl. für Minimalismus). Nicht nur weil die daraus

70


resultierenden Dokumente im Normalfall einen kleineren Umfang haben als Do-kumente, die mit anderen Ansätzen erstellt werden. Sondern auch weil Studienden Lesern solcher Dokumente eine deutlich höhere Arbeitseffizienz attestieren.Laut Brockmann in [Brockmann 90] sind unter historischem Aspekt drei Ansätzezu unterscheiden. Den ersten Ansatz bezeichnet Brockmann als system documen-tation, wobei die Beschreibung auf der Struktur der Software der damit verbun-denen Terminologie aufbaut. Es ist daher nicht verwunderlich, dass diese Artder Beschreibung, die eigentlich den internen Empfängerkreis anspricht, nichtbesonders effektiv für den externen Empfängerkreis ist. In den 1980ern kam dertask-oriented approach (engl. für aufgabenorientierter Ansatz) auf, der das Systemaus Benutzersicht beschreibt und eine der Benutzersicht angepasste Terminolo-gie benutzt. Dadurch werden vor allem die Aufgaben, die der Benutzer des Sys-tems zu lösen hat, mit dem entsprechenden Lösungsweg beschrieben. Es wirdauf ein übergeordnetes Verständnis verzichtet. Studien belegen, dass die Benut-zer das System wesentlich schneller und effektiver nutzen können, als mit demherkömmlichen Ansatz, obwohl die Dokumentation umfangreicher wird. Brock-mann argumentiert weiter, dass der Minimalism die Weiterentwicklung des auf-gabenorientierten Ansatzes ist. Zu den Merkmalen minimalitischer Dokumenta-tion gehört das Weglassen von Dokumentteilen wie Einleitungen und Zusam-menfassungen. Der Fokus wird noch mehr auf die tatsächlichen Aufgaben desBenutzers gelegt. Dabei wird das Vorwissen der Benutzer berücksichtigt und ak-tiv genutzt (z.B. durch das direkte Hervorheben neuer Beschreibungsteile). DerBenutzer wird durch das Weglassen von Informationen dazu ermuntert die Mög-lichkeiten des Systems aktiv zu erforschen, da die Benutzer ihr eigenes Verständ-nis (persönlicher Modell) aufbauen wollen. Den Erstellungsprozess minimalisti-scher Dokumentation beschreibt Carroll in [Carroll 97] (S. 29 ff.) als iterativ, wiebei der Entwicklung programmierter Systeme.

Ursprünglich decken der Minimalism und auch die damit zusammenhängendenStudien schriftliche Produktbeschreibungen ab. Der Begründer des MinimalismCarroll hat seinen Ansatz auch für schriftliche technische Systembeschreibungenin [Carroll 97] untersucht und angepasst. Seine Studien haben ergeben, dass esfür den internen technischen Empfängerkreis nicht sinnvoll ist, alle möglichenund relevanten Fälle und deren Lösungen aufzulisten. Dies äußert sich z.B. in[Carroll 97] durch „Instead, we tried to convey and support meta-skills of thedomain that could help learners make sense on their own.“ (S. 31) oder „Wefound it more useful to provide a higher level of support, for example, critiquingstrategies instead of individual actions.“ (S. 31). D.h. für eine effektive Arbeit imRahmen der Entwicklung und Evolution (inkl. Pflege und Wartung) ist ein über-geordnetes Verständnis notwendig, das sich nicht durch einen Maßnahmenkata-log ersetzen lässt. Der Maßnahmenkatalog lässt sich angesichts der Komplexitätwirtschaftlich nicht rechtfertigen und könnte praktisch nicht erstellt werden.

Eigenschaften von Dokumenten. Neben dem Zeitpunkt der Erstellung undden Inhalten der Dokumente stellt sich auch die Frage, wer eigentlich die Doku-mente erstellt. Traditionell ist dies bei programmierten Systemen die Aufgabe der

71


Entwickler, was sich mit der Beobachtung von Brockmann deckt. Entwickler ha-ben kein besonderes Interesse an der Erstellung von Dokumenten. Sie argumen-tieren, dass das Dokumentieren keinen „Spaß“ mache und die eigentliche Arbeit,die Erstellung des Systems, nicht voranbringt (siehe z.B. auch [McGregor 82]).Diese Haltung wird teilweise auch von den Vorgesetzten geteilt. Die Einstellungvon Entwicklern ändert sich nicht abhängig vom Zeitpunkt der Erstellung derDokumentation, sei es Nach- oder Mitdokumentation. Dass dabei die Möglich-keit der Konsistenzprüfung der persönlichen Modelle sowie der gemeinsameAustausch der Modelle vernachlässigt wird, scheint dabei nicht berücksichtigt zuwerden. Deshalb wird die Erstellung von Dokumenten an eigens dafür eingestell-te oder externe technische Schreiber weitergegeben. Dies ist ebenfalls bei Projek-ten in der Open-Source Gemeinde zu beobachten, siehe [Berglund, Priestley 01].Wie wertvoll technische Schreiber auch schon bei Produktbeschreibungen sind,versucht Mead in [Mead 98] darzustellen. Unter anderem führt Mead auf, dassdurch Mitdokumentation die Qualität des Systems verbessert wird. Inkonsisten-zen zwischen den Beschreibungen und dem Systemverhalten können frühzeitigaufgedeckt werden. Die Kosten lassen sich dadurch stark reduzieren. Gleichesgilt auch für technische Systembeschreibungen.

Einzelne Dokumente können unter Umständen von einer einzelnen Person er-stellt werden. Dies bringt einige Vorteile im Bezug auf die technischen Hilfsmittelzur Erstellung der Dokumente und sorgt meist für einen einheitlichen Sprachstilsowie die Nutzung einer bestimmten Terminologie innerhalb des Dokuments.Gerade für komplexe programmierte Systeme ist eine Menge von Dokumentenerforderlich, die üblicherweise von mehreren Personen teilweise zeitgleich er-stellt werden. Eine andere Möglichkeit besteht darin, dass mehrere Personen beider Erstellung eines umfangreichen Dokuments direkt mitwirken. Auch dabeiwird die Arbeit für die Erstellung aufgeteilt. So kann nach einer gemeinsamenAbsprache die Arbeit auf einzelne Teile des Dokuments zwischen den Erstel-lern verteilt werden. Dabei werden ähnliche Prinzipien wie bei der Erstellungdes Quelltextes angewendet, da beides letztlich schriftliche Systembeschreibun-gen sind. Auf solche Ähnlichkeiten wird auch in der Literatur hingewiesen, siehez.B. [Childs, Sametinger 96]. Davon wird sich eine höhere Wiederverwendbarkeitund eine bessere Wartbarkeit der Dokumente versprochen. So ist es bei Doku-menten, wie auch bei Modulen (z.B. auch programmiertechnische Klassen), sinn-voll, eine hohe Kohäsion einzelner Dokumententeile wie z.B. Kapitel oder auchganzer Dokumente anzustreben. Dies bedeutet letztlich nur, dass Dokumenttei-le oder Dokumente inhaltlich zusammenhängend sind und auf bestimmte In-halte konzentriert sind. Diese Eigenschaft ist auch für Modelle im Allgemeinen,aus denen sich die Dokumente oder Dokumentteile ergeben, und für den Leserder Dokumente erstrebenswert, da dadurch das Verständnis erleichtert wird. Mitder Kohäsion eng verbunden ist die Kopplung. Die einzelnen Teile innerhalb ei-nes Dokuments oder ganze Dokumente sollten nach Möglichkeit eine geringegegenseitige Abhängigkeit besitzen. Dies hat den Vorteil, dass nicht ständig an-dere Dokumentteile oder Dokumente nachgeschlagen und verstanden werdenmüssen, bevor das eigentlich Interessierende verstanden wird. Andere Prinzipi-en, wie z.B. aus der Objektorientierung, finden ebenso Anwendung bei Doku-

72


menten (vgl. auch [Matthews, Grove 92]). Die Vererbung wird ebenfalls benutzt,auch wenn es nicht unbedingt wie objektorientierten Programmiersprachen, spe-zielle Konstrukte dafür gibt. Für die Beschreibung eines Systemteils könnte aufein anderes verwiesen werden und nur noch die Unterschiede erläutert werden.Für solche Dinge ist natürlich auch Werkzeugunterstützung möglich. Die Ideeder Abstraktion, man denke hierbei an den programmiertechnischen Begriff derabstrakten Klasse, lässt sich bei Dokumenten mit Vorlagen (engl. templates) ver-gleichen, wobei eine gewisse Grundstruktur vorgegeben ist, die es mit Leben zufüllen gilt. Dies eignet sich insbesondere für Systemteile mit ähnlichen Struktu-ren. Für die Strukturierung von Quelltexten hat sich, nicht nur durch die Objek-torientierung, auch das Prinzip der Redundanzfreiheit verbreitet. Diese ist ins-besondere bei schriftlichen Konzeptbeschreibung, wo es um die Vermittlung desgrundlegenden Verständnisses geht, nicht immer sinnvoll. Dadurch wird zwardie Wartbarkeit des Dokuments negativ beeinflusst, aber das Verständnis wirdverbessert. Z.B. durch das Wiederholen von Aussagen, um deren Wichtigkeit zuunterstreichen oder durch unterschiedliches Ausdrücken identischer Informati-on, um genau diese mit einer möglichst hohen Wahrscheinlichkeit weiterzuge-ben.

Neben den vorgestellten Eigenschaften und Prinzipien für die Erstellung vonDokumenten, haben Dokumente bestimmte Qualitätsmerkmale. Die Berücksich-tigung solcher Qualitätsmerkmale bei der Erstellung von „guten“ Dokumentenkann hilfreich sein. Eine tiefer gehende Diskussion dieser Thematik wird z.B. bei[Smart 02] geführt. Smart definiert für Produktbeschreibungen folgende Quali-tätsmerkmale:

• Easy to use: inhaltliche Anpassung an den Leserkreis, Konsistenz und Voll-ständigkeit des Dokuments.

• Easy to understand: Klarheit, Konkretheit und Sprachstil des Dokuments.

• Easy to find: sinnvolle Struktur, leichte Auffindbarkeit sowie eine anspre-chende und den Inhalt unterstreichende Gestaltung des Dokuments bzw.der Dokumententeile.

Weiterhin wird zwischen essential quality, conventional quality und attractive qua-lity unterschieden. Diese Unterscheidung dient in erster Linie dazu, zwischenwichtigen und weniger wichtigen Qualitätsmerkmalen zu trennen. Die essentialquality besteht aus Qualitätsmerkmalen, die der Leser nur dann bemerkt, wenndiese Qualitätsmerkmale nicht eingehalten werden. Der Leser ist dann mit demDokument unzufrieden. Sind hingegen die Qualitätsmerkmale der conventionalquality vorhanden, so ist der Leser mit dem Dokument zufrieden. Beim Nichtvor-handensein ist der Leser mit dem Dokument unzufrieden. Im Fall der attractivequality spielt es keine Rolle, ob die zugehörigen Qualitätsmerkmale eingehaltenwerden oder nicht. Falls diese erfüllt werden, wurden die Erwartungen des Le-sers übertroffen und er ist mit dem Dokument sehr zufrieden.

Mit der Erstellung von Dokumenten ist Aufwand verbunden, der sich in Kostenfür den Dokumentenerstellungsprozess sowie Pflege und Wartung niederschlägt.

73


Bild 3.27 zeigt eine qualitative Kurve des Aufwands für die Erstellung sowie Pfle-ge und Wartung eines Dokuments in Abhängigkeit der Anzahl der Leser. DieKurve mit den eingezeichneten Bereichen soll verdeutlichen, dass es durchaussinnvoll ist mehr Aufwand und somit Kosten für die Erstellung von Dokumentenfür eine hohe Anzahl von Lesern zu investieren. Wird der Aufwand auf einzelneLeser umgerechnet, so fällt er für den einzelnen Leser immer kleiner aus je höherder Leserkreis ist.

Anzahl der Leser

Aufwand für

Erstellung sowie

Pflege und Wartung

eines Dokuments

(Je mehr Leser, desto mehr Aufwand für Erstellung gerechtfertigt)

Bild 3.27: Qualitative Kurve für den Aufwand zur Erstellung und Pfle-ge/Wartung eines Dokuments in Abhängigkeit der Anzahl der Leser

In der Regel wird es mehrere Versionen eines Dokuments geben. Dies hängt unteranderem mit der Pflege und Wartung des Dokuments zusammen aber auch mitAnpassungen bezüglich der Weiterentwicklung des Systems. Eine Versionisierungvon Dokumenten wird auch erforderlich durch verschiedene an einem Dokumentarbeitende Ersteller, die unter Umständen zeitgleich daran arbeiten. Oder ganzeinfach durch den Erstellungsprozess selbst, wenn ein Dokument zur Kontrollebei einem Tester vorliegt, der entsprechende Anmerkungen machen will. Auchhier sind die Parallelen zur Softwareentwicklung sichtbar.

Falls die Dokumente ausschließlich gepflegt bzw. gewartet werden, z.B. kleinereKorrekturen durchgeführt werden oder weitere Passagen hinzugefügt werden,die sich noch auf das gleiche System beziehen, ist die Versionisierung der Do-kumente eindeutig. Die Versionisierung ist nicht mehr eindeutig, wenn sich dieÄnderungen nicht mehr auf die Pflege und Wartung des Dokuments beziehen.Hierbei ist es hilfreich die Versionisierung der Dokumente mit der des Systemszu koppeln. D.h. bei der Entwicklung und Weiterentwicklung des Systems wer-den bestimmte definierte Versionen zugrunde gelegt, bei denen bestimmte Än-derungen oder Ziele erreicht wurden. Gemeinsame Grundlage der Änderungensind natürlich die Systemmodelle, die zuerst angepasst werden. Es existieren al-so auch verschiedene Versionen von Modellen. Die persönlichen Modelle wer-den ständig bei Gewinn neuer Einsichten oder Informationen angepasst. Hierbeimacht eine bewusste Versionisierung meistens keinen Sinn, da die Änderungenzu häufig auftreten. Der Mensch vergisst einfach Zwischenversionen und merktsich meist nur wichtigere ältere Versionen und vor allem die aktuelle Version.

74


Auch während der Entwicklung bzw. der Evolution eines Systems werden häufigModelländerungen vorgenommen. Es werden Ideen ausgetauscht, die Machbar-keit diskutiert, einige Modelle oder Teile von Modellen wieder verworfen oderdurch andere Teile ersetzt. Die Modelle sind in diesen Phasen ebenfalls Ände-rungen unterworfen. Bei der Frage ob und wie die verschiedenen Modellversio-nen schriftlich beschrieben werden, sollte eine bezüglich des Aufwand/Nutzen-Kriteriums vernünftige Abwägung berücksichtigt werden.

Unterstützende Hilfsmittel. Bei der Erstellung von Dokumenten existiert einebreite Palette an unterstützenden Hilfsmittel, siehe auch Bild 3.28. Zu den wich-tigsten gehören die Modellierungs- und Dokumenterstellungsansätze, die maß-geblich beim Inhalt der Dokumente zum Tragen kommen. Weiterhin existierenGestaltungsrichtlinien, die eine vereinfachte und somit schnellere Aufnahme desGeschriebenen erlauben. Der Erstellungs- und Evolutionsprozess für Dokumentewird fast immer von Werkzeugen unterstützt.

• Einige Modellierungsansätze wurden zu Beginn dieser Arbeit vorgestellt. DieModelle bilden bei der Beschreibung eines Systems immer die Grundla-ge. Die Modellierungsansätze stellen in der Regel für den entsprechen-den durch den Modellierungsansatz anvisierten Bereich die passende Ter-minologie und Notation zur Verfügung. In der Regel reicht ein Modellie-rungsansatz nicht aus, da neben dem (informationellen) System auch dieGrundstrukturen der Software beschrieben werden müssen, wie Keller in[Keller 03] feststellt. In seinen Studien stellte Keller fest, dass unterschied-liche Notationen von den Lesern mit bestimmten Dingen verknüpft wer-den. Als Beispiel diente, dass Leser als sie Diagramme in der Unified Mode-ling Language (UML) erkannten, diese sofort auf Softwarestrukturen bezo-gen, während Leser Diagramme in der Fundamental-Modeling-Concepts-Notation direkt mit Systemstrukturen assoziierten. Verschiedene Modellie-rungsansätze werden weiterhin von unterschiedlichen Empfängerkreisenunterschiedlich gut verstanden, so dass dies ebenfalls bei der Abwägungüber Modellierungsansätze und Detailtiefe berücksichtigt werden sollte.

• Dokumenterstellungsansätze, wie der task-oriented approach oder minima-lism, bestimmten hauptsächlich die Sprache und die Anpassung der Inhal-te an die Bedürfnisse des anvisierten Leserkreises. Außer Caroll mit sei-nen Untersuchungen seines Ansatzes minimalism für den internen Emp-fängerkreis, scheint es für diesen keine ausgesprochene Dokumenterstel-lungsansätze zu geben. Clements et al. in [Clements et al. 03] beziehen sichauf den IEEE Standard [IEEE 00]. In diesem Standard wird auf die Existenzverschiedener Stakeholder hingewiesen. In [Clements et al. 03] werden die-se weiter ausgeführt und ihre Bedürfnisse erläutert. Daraus ergeben sichaber keine Konsequenzen für einen Dokumenterstellungsansatz. Wie Ca-roll in seinen Untersuchungen festgestellt hat, ist es in einem Bereich, wo eshauptsächlich auf das Verständnis ankommt, nicht ohne weiteres möglich„Kochrezepte“ an die Hand zu geben.

75


• Die Gestaltung von Dokumenten ist ein weiteres Merkmal, das die Lesbar-keit aber auch das Verständnis erleichtern kann. Im Bereich der Program-mierung kann durch Einhaltung bestimmter Gestaltungsrichtlinien einedeutlich höhere Produktivität erreicht werden, da dadurch das Verständnisentsprechend schnell aufgebaut werden kann, siehe dazu [Oman, Cook 90].Auch im Bereich der Dokumentation existieren zahlreiche Gestaltungsricht-linien wie z.B. in [Barker 03], [Shook 97], [Petre 95], [Zimmermann 97] und[Purchase et al. 01]. Solche Gestaltungsrichtlinien berücksichtigen die ko-gnitiven Fähigkeiten und geben Abstände zwischen Sätzen, Anzahl vonBuchstaben in eine Zeile usw. vor. Sie führen meist zu ansprechend gestalte-ten Dokumenten wodurch sich auch die Lesbarkeit verbessert. Die Gestal-tungsrichtlinien beschränken sich aber nicht darauf, sondern geben Hin-weise was vermieden oder verstärkt werden sollte, um die Inhalte mög-lichst transparent zu kommunizieren. Dazu gehört z.B. nicht die willkür-liche Nutzung von Farben, denn einer Farbe sollte auch eine Bedeutungzugeordnet werden können.

• Zur Erstellung von Dokumenten existiert ein reiches Repertoire an unter-stützenden Werkzeugen. Zu den bekanntesten gehören Textverarbeitungs-oder Textsatzsysteme sowie Bildbearbeitungs- oder Zeichensysteme. Siebieten in der Regel alle notwendigen Funktionen, siehe auch [Holtzman 93].Die meisten Werkzeuge bieten die Möglichkeit, Vorlagen zu nutzen, die be-reits gemäß Gestaltungsrichtlinien erstellt worden sind. Sie dienen teilweiseals Checkliste und sichern ein ähnliches Erscheinungsbild sowie bestimm-te Strukturen, die es dem Leser erleichtern sollen, sich in den Dokumen-ten zurechtzufinden. Interessant wäre auch eine Werkzeugunterstützung,die es ermöglichen würde, Hilfestellungen zu und Durchführung von Kon-sistenzprüfungen für die maschinenüberprüfbare Teile von Dokumentenzu geben. Zur Überprüfung syntaktischer und grammatikalischer Regelnbieten die meisten Werkzeuge Überprüfungsmöglichkeiten. Diese könnenmanuell angestoßen werden oder können bei abgeschlossener Eingabe, wiez.B. einem Wort oder einem Satz, automatisch die Überprüfung durchfüh-ren. Andere Konsistenzprüfungen, wie auf methodische Inkonsistenzen,bilden die Ausnahme. Sie lassen sich meist nur in speziellen Werkzeugenwie bei Computer-Aided Software Engineering (CASE) Werkzeugen fin-den, siehe auch [Gryce et al. 02]. Bei den Konsistenzprüfungen stellt sichdie Frage nach der Skalierbarkeit, da Dokumente oder Dokumententeile inunterschiedlichen Systemen gespeichert sein können. Je nach Konsistenz-prüfung kann der Vorgang erhebliche Zeit benötigen. Für die unterschiedli-chen Bedürfnisse kann zwischen Online- und Offlinekonsistenzprüfungenoder einer Mischung gewählt werden. Im Hinblick auf die Anzahl der Be-teiligten am Dokumenterstellungsprozess werden meist Versionisierungs-systeme genutzt. Dies ermöglicht je nach Werkzeug für die Erstellung einesDokuments das zeitgleiche Arbeiten.

Das beste Dokument nutzt natürlich nichts, wenn es nicht aufgefunden werdenkann oder nur sehr schwer zugänglich ist. Daher ist es nach der Erstellung ei-

76


unterstützende Hilfsmittel

Dokumenterstellungsansatz • Standard

• Gestaltung, etc.

Modellierungsansatz • Terminologie

• Notation, etc.

Werkzeug• Textverarbeitungs-, Zeichensystem

• Online/Offlinekonsistenzprüfung etc.

Bild 3.28: Übersicht Hilfsmittel zur Erstellung von Dokumenten

nes Dokuments sehr wichtig, dieses an entsprechend kommunizierten Ablage-orten oder über ein für die Verteilung bzw. das Anbieten von Dokumenten zu-geschnittenes System zu positionieren. Vorteilhaft sind auch Mechanismen, diees für einen potentiellen Leser leicht ersichtlich machen, wann und wo ein neu-es Dokument oder eine neue Version eines Dokuments hinzugefügt wurde. Beineuen Dokumenten sind kurze Zusammenfassungen bzw. eine inhaltliche Ein-gliederung in die Ablagestrukturen für den potentiellen Leser außerordentlichhilfreich. Man denke z.B. an die Suche nach passenden Informationen. HeutigeSysteme bieten häufig auch eine Volltextsuche über die Dokumente an, was abereine Einordnung in eine vom Inhalt bestimmte Struktur nicht ersetzen sollte bzw.kann. Es ist nicht immer der Fall, dass der potentielle Leser von der Existenz ei-nes für ihn interessanten Dokuments weiß. Bei neuen Versionen von Dokumen-ten sind Änderungen zur Vorversion interessant, da sich der Leser der Vorversiondadurch einen Eindruck verschaffen kann, ob dieses Dokument in der neuen Ver-sion für ihn zum Lesen relevant ist oder nicht.

3.3.3.5 Inkonsistenzen in und zwischen Dokumenten

Die in Kapitel 3.1.4 vorgestellten Klassen von Inkonsistenzen gelten auch für dieInkonsistenzen innerhalb und zwischen Dokumenten. Im Folgenden wird dahernur auf die für Dokumente speziellen Inkonsistenzen eingegangen.

Innerhalb von Dokumenten auftretende Inkonsistenzen werden alsIntradokumentinkonsistenzen bezeichnet. Diese Inkonsistenzen stellenVerletzungen der Intradokumentbeziehungen dar.

Dazu gehören z.B. Inkonsistenzen zwischen den Aussagen im Text und denAussagen der entsprechenden Abbildungen. Referenzen innerhalb eines Doku-ments, die zu den falschen Stellen führen oder ungültig sind, stellen ebenfallsIntradokumentinkonsistenzen dar. Die Einordnung in eine entsprechende Klasse(vorgabenbedingte Inkonsistenzen oder Modellinkonsistenzen) ist nicht immereindeutig durchführbar. Man nehme das Beispiel der nicht zusammenpassendenAussagen des Textes und einer Abbildung. Es handelt sich dabei, wie in fastallen Fällen, um Redundanz. Eine Aussage wird in einer Abbildung getroffenund im Text wiederholt. Es ist nicht klar, ob schlicht vergessen wurde dieAbbildung bzw. den Text bei einer Änderung anzupassen – vorgabenbedingteInkonsistenz – oder der Autor z.B. die Abbildung nicht richtig verstanden hatund die Inkonsistenz daher rührt – Modellinkonsistenz. Quellen für diese Artvon Inkonsistenzen sind zahlreich. So kann es beim Erstellen oder beim Lesen

77


zu semantischen Inkonsistenzen kommen, d.h. es wird nicht formuliert bzw.gelesen was beabsichtigt war. Die implizite Verwendung von Synonymen kanndurch den Leser ebenfalls als Inkonsistenz beurteilt werden, vor allem wenner die Verwendung der Synonyme nicht einfach erkennen kann. Durch dasLesen bzw. Erstellen von Dokumenten werden Modelle teilweise zum erstenMal konkretisiert. Dies bietet die Möglichkeit durch entdeckte Intradokumentin-konsistenzen die eigentlichen Modellinkonsistenzen zu identifizieren. Dadurchkönnen die Dokumente ihrem eigentlichen Zweck, dem Transport der Modelle,gerecht werden.

Interdokumentinkonsistenzen sind letztlich inhaltlich sehr ähnlich zu denIntradokumentinkonsistenzen. Dabei werden nur Inkonsistenzen zwischenDokumenten und nicht innerhalb der Dokumente verstanden.

Änderungen an einem Dokument können Interdokumentinkonsistenzen hervor-rufen. Dies kann zum einen an der Redundanz liegen, so dass die redundantenTeile ebenfalls angepasst werden müssen. Zum anderen kann dies auch durchdie Änderungen der Modelle begründet sein.

Die Unterschiede zwischen verschiedenen Dokumentversionen weisen die Behe-bung entdeckter Inkonsistenzen auf.

78

Kapitel 4

Bestehende Ansätze für den Umgangmit Inkonsistenz

Im Folgenden werden ausgewählte Ansätze aus der Literatur für den Umgangmit Inkonsistenz anhand der vorgestellten Klassifikation von Inkonsistenz kurzvorgestellt und kommentiert. Der Umgang mit Inkonsistenz soll hier so verstan-den werden, dass die Reaktion auf Inkonsistenzen nicht automatisch deren Kor-rektur betrifft, sondern auch das Tolerieren. Das Korrigieren von Inkonsistenzenist der klassische Fall.

Die Forderung nach Korrektur rührt daher, dass inkonsistente Beschreibungenals wert- und nutzlos angesehen werden. Es lassen sich zwar auch wenige Ar-beiten finden, bei denen Inkonsistenzen zugelassen werden und Inkonsistenzennicht gleich als etwas Schlechtes dargestellt werden. Aber bei diesen Ansätzensteht immer ein Werkzeug im Vordergrund, das mit Inkonsistenzen in seinemDatenbestand umgehen kann. Gerade im Bereich der Konzeptbeschreibungen,wo vorwiegend auf natürlichsprachliche Beschreibungen zurückgegriffen wird,wird die Inkonsistenzproblematik völlig außer Acht gelassen oder mit einer nichtnäher spezifizierten Konsistenzforderung abgeschlossen. Auch Prozessmodellewie der Rational Unified Process (RUP) machen keine Aussagen über den Um-gang mit Inkonsistenzen in und zwischen Dokumenten. Ohne nähere Erläuterun-gen wird Konsistenz gefordert. Dies ist auch bei Modellierungsansätzen der Fall.Auch in der Literatur über die Dokumentation von Konzepten und Architektu-ren, wie [Clements et al. 03], wird Konsistenz gefordert. Eine mögliche Erklärungdafür ist, dass sich zunächst auf die Modellierung, die Prozesse, die Methodenselbst konzentriert wird. Die restliche Literatur fokussiert auf automatisierbareKonsistenzprüfungen, die Modellinkonsistenzen zwangsläufig unberücksichtigtlassen müssen.

Es gibt viele Ansätze, die versuchen die Entstehung von Inkonsistenzenzu vermeiden. Prozesse und Methoden im Allgemeinen geben zum Teilvor, erstellte Dokumenten zu überprüfen oder das System mit den An-gaben in den Dokumenten zu vergleichen. Werkzeuge helfen dabei undprüfen z.B. auf notationelle Inkonsistenzen. Andere Ansätze zielen dar-auf ab, vorgabenbedingte Inkonsistenzen automatisch zu identifizieren. Bei-

79

Kapitel 4. Bestehende Ansätze für den Umgang mit Inkonsistenz

spiele sind in [Zuck 90], [Hagensen, Kristensen 92], [Robinson, Pawlowski 99],[Kuzniarz et al. 02], [Kuzniarz et al. 03] und [Huzar et al. 04] zu finden. Gemein-sames Merkmal dieser Ansätze ist die anschließende Beseitigung der erkanntenInkonsistenzen. Teilweise wird noch je nach Bedeutsamkeit der entdeckten In-konsistenz abgewägt, wann sie zu beseitigen ist. Einzig im Bereich der Inspektio-nen (siehe auch [Fagan 76], [Porter et al. 95] und [Basili et al. 95]), bei denen Le-setechniken verwendet werden, kann auf Modellinkonsistenzen hin untersuchtwerden.

Inkonsistenzen werden in einigen Ansätzen geduldet und führen nichtautomatisch zum Ignorieren oder zur Auflösung. Werkzeuge, die ent-sprechend diesen Ansätzen gebaut wurden bzw. würden, können bzw.könnten ihre Tätigkeit weiter fortsetzen. Diesen Ansätzen liegt die Er-kenntnis zugrunde, dass Inkonsistenzen praktisch nicht vermieden wer-den können. Teilweise wird versucht, Inkonsistenzen automatisch aufzu-lösen. Gelingt dies nicht, wird der menschliche Nutzer informiert, derüber das weitere Verfahren bestimmen kann. Beispiele für solche Ansätzesind [Grundy et al. 98], [Liu et al. 02], [Cugola et al. 96], [Toffolon, Dakhli 99],[Scheffczyk et al. 04], [Nentwich et al. 03], [Benferhat, Garcia 98]. Keiner dieserAnsätze schlägt jedoch vor, welche Arten von Inkonsistenzen aufgrund vonAufwand/Nutzen-Abschätzungen toleriert werden können. Den Hauptaufwandfür die Erstellung solcher Werkzeuge stellt die Inkonsistenzsuche bzw. die Rea-lisierung der entsprechenden Regelabwickler dar. Bei fast allen Ansätzen sindnoch Bedingungen – teilweise als Regeln bezeichnet – anzugeben, die vom zuerstellenden System und der Domäne abhängen. Damit müssen das System unddie Domäne nochmals modelliert und formalisiert formuliert werden. Es ist deut-lich die Absicht erkennbar, dass der menschliche Nutzer nicht durch Behebungenvon Inkonsistenzen in seinem teilweise kreativen Arbeitsfluss mit dem Werk-zeug behindert werden soll. Es wäre in der Tat kontraproduktiv, würde ein Text-verarbeitungssystem die Eingabe weiterer Wörter verhindern, falls das aktuelleWort nach Angaben des Systems noch einen Rechtschreibfehler enthalten würde.Im Rahmen der International Conference on Software Enginering wurden zweiWorkshops „Living with Inconsistency“ abgehalten, siehe [Fickas et al. 97] und[Easterbrook, Chechik 01]. Weiterhin gab es zu diesem Thema eine sogenanntespecial section in dem Journal IEEE Transactions on Software Engieering, siehe[Ghezzi, Nuseibeh 99]. Eine gute und sehr vollständige Übersicht über den Standder Forschungen bieten Spanoudakis und Zisman in [Spanoudakis, Zisman 01].

4.1 Inkonsistenzen im System

Inkonsistenzen im System stehen nicht im Fokus dieser Arbeit. Im Folgendenwerden dennoch einige Ansätze dafür kurz vorgestellt. Die Vermeidung odertemporäre Duldung von Inkonsistenzen ist das oberste Ziel innerhalb eines Sys-tems. Es ist schließlich nicht gewollt, dass ein System sich nicht den Vorstellungenentsprechend verhält. Es gibt eine ganze Reihe von Maßnahmen, die die Identifi-zierung und eine entsprechende Reaktion auf die identifizierten Inkonsistenzen

80

4.1. Inkonsistenzen im System

umfassen. Im Bereich der Programmierung gibt es z.B. die so genannten asser-tions (siehe auch [McConnell 93]) mit denen Daten- und Verhaltensinkonsisten-zen aufdeckt werden können. Ein weiteres Beispiel ist das exception handling(siehe auch [Goodenough 75]), das es ermöglicht entdeckte Inkonsistenzen auf-zulösen.

Die nachfolgend vorgestellten Ansätze für den Umgang bzw. für die Modellie-rung von Systemen bezüglich der Inkonsistenzen im System werden nicht wei-ter kommentiert. Es ist generell vorteilhaft sich bei der Systementwicklung überMaßnahmen, die die Inkonsistenzen im System reduzieren, leicht identifizierenlassen oder sogar auflösen können, sowie bei der Konzeption des Systems ummögliche Inkonsistenzen im System explizit zu kümmern.

4.1.1 Pollution Markers

Der Ansatz von Balzer in [Balzer 91] stellt so genannte pollution markers bereit,die Dateninkonsistenzen in einem System kennzeichnen. Balzer hebt die Date-ninkonsistenzen in Datenbanken besonders hervor. Durch diese Markierungen,die bei der Entwicklung des Systems eingebaut werden müssen, können die in-konsistenten Daten temporär geduldet werden, bis eine Gegenmaßnahme die In-konsistenzen auflöst. Die Beseitigung aller Dateninkonsistenzen ist das Ziel die-ses Ansatzes. Die Auflösung der Dateninkonsistenzen kann durch das System,ein anderes System oder eine Person erfolgen. Während der Auflösung, die un-ter Umständen mehrere Eingriffe in das System erfordert, kann es zu weiterentemporären Dateninkonsistenzen kommen. Als anschauliches Beispiel nutzt Bal-zer ein Tabellenkalkulationssystem. In einer Tabelle kann ein bestimmter Zusam-menhang zwischen Zellen bestehen. Wird dieser verletzt, so wird dies dem Nut-zer des Systems durch Einfärbung kenntlich gemacht. Wurde die Inkonsistenzdurch den Nutzer aufgelöst, so verschwinden die Einfärbungen wieder.

Balzer sieht den Vorteil dieses Ansatzes bei der Verwendung verteilter Syste-me, bei denen Daten über mehrere physikalische Orte verteilt sein können undvon ebenfalls physikalisch verteilten Systemteilen verwaltet werden können. DieMaßnahmen zur Auflösung der Dateninkonsistenzen können in unterschiedli-cher Reihenfolge von unterschiedlichen Personen oder Systemen erfolgen. ZurAuflösung dieser Inkonsistenzen zeigt Balzer drei Möglichkeiten auf:

1. automatisierte Auflösung der Inkonsistenzen, die meist nur in 5% der Fällefunktioniert.

2. Benachrichtigen der relevanten Personen über das Auftreten und das Ver-schwinden der Inkonsistenzen

3. Erweiterung der 2. Möglichkeit, indem bei einer gewissen Zeitüberschrei-tung die entsprechenden Personen benachrichtigt werden.

81


4.1.2 FMC-eCS

Ein bisher nicht veröffentlichter Ansatz zur qualitativen Modellierung von Kom-munikationssystemen im Besonderen ist das FMC-eCS (Fundamental ModelingConcepts extended for Communication Systems) von Zorn (siehe [Zorn 03]). ImRahmen dieser Arbeit wird der Anteil des Ansatzes, der vom Verhaltens- undDateninkonsistenz handelt, berücksichtigt. Im Folgenden werden die wichtigs-ten Konzepte vorgestellt.

Ein kritisches Aktionsfeld ist ein Speicher oder Kanal, dessen Inhalte durch Dritteohne Vereinbarungen mit den Anderen manipuliert werden können. KritischenInhalte sind Inhalte eines Aktionsfeldes, die für die zugreifenden Akteure (oh-ne Dritte) konsistent sein müssen. Es kann sich folglich auf die Untersuchungvon kritischen Inhalten auf kritischen Aktionsfeldern beschränkt werden. Kriti-sche Aktionen (auch kritische Abschnitte genannt) sind Folgen von Aktionen ankritischen Inhalten auf kritischen Aktionsfeldern, bei denen mindestens ein in-konsistenter Systemzustand eingenommen wird. Als Lösungsmöglichkeit kom-men prinzipiell gesicherte und partiell gesicherte kritische Aktionen in Betracht.Gesicherte kritische Aktionen sind kritische Aktionen, die vor bestimmten Interak-tionen von Dritten geschützt sind. D.h. bei Feststellen einer Inkonsistenz kannimmer in den zuvor bestandenen Zustand gewechselt werden. Nur falls die In-konsistenz aufgelöst werden kann oder es nicht dazu gekommen ist, gelangt manzum Abschluss des kritischen Abschnitts. Partiell gesicherte kritische Aktionen fol-gen dieser Eigenschaft nur gelegentlich. Damit verbunden sind die Begriffe kon-sistenter und inkonsistenter Steuerzustand. Inkonsistente Steuerzustände treten in-nerhalb kritischer Abschnitte auf. Gesicherte kritische Abschnitte beginnen undenden in konsistenten Steuerszuständen auf. Dadurch kann Verhaltens- als auch Da-teninkonsistenz explizit behandelt werden.

FMC-eCS erweitert auch die Notation von FMC durch Hervorhebung von kriti-schen Abschnitten und inkonsistenten Steuerzuständen in Petrinetzen, kritischenAktionsfeldern in Aufbaubildern und kritische Inhalte in Entity-Relationship-Diagrammen in roter Farbe. Konsistente Steuerzustände dagegen werden durchgrüne Farbe hervorgehoben.

4.1.3 Making inconsistency respectable

Der Ansatz von Gabbay und Hunter wird in [Gabbay, Hunter 91] und[Gabbay, Hunter 93] beschrieben. Es geht um das Tolerieren von Dateninkonsis-tenzen in Datenbanken. Die Autoren vertreten den Standpunkt, dass Datenbank-bestände durchaus inkonsistent sein können, da es Abbildungen der „inkonsis-tenten“ realen Welt sind. Als Beispiel dienen Datenbankbestände für ein Flugbu-chungssystem. Die Dateninkonsistenz besteht darin, dass ein Flug überbucht ist,dies aber gesetzlich erlaubt ist. Diese Inkonsistenz kann bis zum Abflugdatumgeduldet werden. Am Abflugdatum müssen entsprechende Gegenmaßnahmeneingeleitet werden, um diese Inkonsistenz aufzulösen. Diese bestehen z.B. dar-in kostenlos in eine höhere Klasse gebucht zu werden oder einen Ausweichflug

82

4.2. Vorgabenbedingte Inkonsistenzen

zu finden. Es werden bei diesem Ansatz Inkonsistenzen kontrolliert zugelassen,indem bei identifizierten Inkonsistenzen bestimmte Operationen durchgeführtwerden. Zu diesen Operationen zählen die Autoren grundsätzlich das Ignorierenund das Auflösen.

4.2 Vorgabenbedingte Inkonsistenzen

Vorgabenbedingte Inkonsistenzen können relativ gut durch Werkzeugunterstüt-zung aufgedeckt werden. Prinzipiell wird der Ansatz verfolgt, aufgedeckte In-konsistenzen durch den Menschen lösen zu lassen. Dies ist in der Regel auchsinnvoll. Für notationelle Inkonsistenzen denke man an ein Textverarbeitungs-system, mit dessen Hilfe eine Rechtschreibüberprüfung durchgeführt werdensoll. Dabei werden von dem System unbekannte Wörter als potentielle Recht-schreibfehler angezeigt. Würde das System diese Wörter automatisch durch vonihm vorgeschlagene Wörter ersetzen, würden inhaltlich inkonsistente Aussagenentstehen.

In Bereichen, bei denen klar definierbare Rahmenbedingungen existieren (wiez.B. bei der Programmierung), können Vorgaben abgeleitet werden. Diese kön-nen durch Werkzeuge überprüft werden und bieten in der Regel eine gute Un-terstützung. Existieren solch klare Rahmenbedingungen nur eingeschränkt, wieim Falle von natürlichsprachlichen Beschreibungen, sind parallel zu den eigent-lichen Beschreibungen noch Vorgaben explizit anzugeben. Dies bedeutet einendeutlich höheren Aufwand. Zusätzlich müssen noch die Vorgaben untereinanderauf Konsistenz geprüft werden.

4.2.1 Lazy Consistency

Narayanaswamy und Goldman führen in [Narayanaswamy, Goldman 92] denAnsatz der lazy consistency ein. Während der Entwicklung und Wartung ei-nes Systems werden von vielen verschiedenen Programmierern Änderungen amQuelltext durchgeführt. Ohne vorherige Absprache kann es durch unkoordinier-te parallele Änderungen zu Zeitverlust kommen. Bestimmte Änderungen müs-sen unter Umständen wieder modifiziert werden, um den Konventionen der Pro-grammiersprachen und der verwendeten Werkzeuge zu genügen und um Inkon-sistenzen im System zu vermeiden.

Der Ansatz der lazy consistency besteht darin, Änderungen vor deren Durchfüh-rung in Schritten, die aus inhaltlich zusammenhängenden Änderungen bestehen,anderen Programmierern vorzuschlagen. Die anderen Programmierer, welche fürdie zu ändernden Teile verantwortlich sind, bewerten die vorgeschlagenen Ände-rungen. Sie können den Schritten prinzipiell zustimmen, sie ablehnen oder modi-fizieren bis sie zu anderen Änderungen passen. Dadurch wird eine Intra-SchrittKonsistenz erreicht. Um eine Inter-Schritt Konsistenz zu erreichen, kann es not-wendig werden, die Schritte zu sequentialisieren oder zusammen zu führen. Zielist letztlich keinerlei Inkonsistenzen im Quelltext zuzulassen.

83


Beurteilung. Bei diesem Ansatz werden keinerlei Inkonsistenzen zugelassen.Es wird vielmehr durch organisatorische Maßnahmen versucht, die Wartung undWeiterentwicklung eines Systems bezüglich der dafür notwendigen Änderungenbesser zu koordinieren. Dies wird durch eine vorherige Arbeitsplanung erreicht.Es ist nicht ganz klar, welche Inkonsistenzen genau angesprochen werden. Än-derungen, die notationell und werkzeugtechnisch konsistent sind, können ohneKollisionen Auswirkungen an anderen Stellen haben. Solche Inkonsistenzen wer-den in diesem Ansatz offenbar nicht berücksichtigt. Vorteilhaft ist prinzipiell derGedanke der Kommunikation vor der Umsetzung. Es ist nicht klar, ob dieser zu-sätzliche Aufwand den Aufwand für die „klassische“ Behebung von Kollisionenwirklich aufhebt. Die Autoren gehen ohnehin von einer geringen Wahrschein-lichkeit für das Auftreten von Kollisionen aus.

4.2.2 Smarter Recompilation

Schwanke und Kaiser stellen in [Schwanke, Kaiser 88] ein Werkzeug namensCONMAN vor, dass bestimmte werkzeugbedingte Inkonsistenzen zulässt. CON-MAN ist ein so genanntes Configuration Management Werkzeug. Es beinhaltetdie für die Programmierung und Erstellung eines maschinenlesbaren Programmsnotwendigen Werkzeuge. Diese Werkzeuge sind teilweise Erweiterungen zu be-reits etablierten Werkzeugen. Es wird zwischen full consistency, type consistency,version consistency, derivation consistency, link consistency und reachable con-sistency unterschieden, die teilweise einander bedingen. Die full consistency setztalle anderen Arten von Konsistenz voraus. Als Beispiel für die erlaubten Inkon-sistenzen soll im Folgenden die version consistency und derivation consistencydienen. CONMAN stellt ausschließlich die derivation consistency sicher und ver-nachlässigt die version consistency. Die version consistency bedeutet, dass allegeänderten Dateien und die damit verknüpften Dateien neu übersetzt werdenmüssen. Bei der derivation consistency ist dies nicht nötig, da nur die geändertenDateien und die damit verknüpften Dateien, die von diesen Änderungen tatsäch-lich betroffen sind, neu übersetzt werden müssen. Dies spart Zeit bei der Über-setzung und kann dadurch die Kosten senken. Dennoch kann das Werkzeug ab-hängig von der Konsistenz nicht in allen Fällen entscheiden, welche Dateien neuübersetzt werden müssen und befragt dazu den Nutzer.

Beurteilung. Der Ansatz von Schwanke und Kaiser lässt bei näherer Betrach-tung keine Inkonsistenzen zu. Es werden vielmehr bestimmte werkzeugbedingteInkonsistenzen anderer Werkzeuge zugelassen, die nicht unbedingt nötig sind.Dadurch kann die anvisierte reduzierte Zeit für die Übersetzung der Quelltexteerreicht werden. Es wird letztlich eine verbesserte Version der Werkzeuge ange-boten, die nichts an den geforderten Konsistenzforderungen von maschinenaus-führbaren Programmen ändern. Heutige Entwicklungssysteme wie Eclipse (siehe[Eclipse 01]) übersetzen den Quelltext während der Eingabe.

84

4.2. Vorgabenbedingte Inkonsistenzen

4.2.3 Flexible Consistency Model (FCM)

Sutton beschreibt in [Sutton 90] das Flexible Consistency Model (FCM). Der Au-tor stellt das FCM im Rahmen eines Werkzeugs zur Unterstützung von Prozess-modellen vor. Das FCM ermöglicht es, Bedingungen zu definieren, die lokal oderglobal gültig sein können. Diese lokalen oder globalen Bedingungen können ein-oder ausgeschaltet werden. Sutton argumentiert, dass Inkonsistenzen in einemProzess natürlich sind, da bestimmte Bedingungen nur in bestimmten Prozess-phasen Sinn machen und nicht überall gelten müssen. Weiterhin ist es nicht mög-lich, schon vor der Erstellung eines Systems alle Bedingungen zu kennen.

Entdeckte Inkonsistenzen, hier sind es Verletzungen der Bedingungen, müssennicht korrigiert werden. Sie können durch manuelle Änderungen der Bedingun-gen toleriert werden. Dies kann erreicht werden, indem die Bedingung so umge-baut werden, dass abhängig vom Prozess die Bedingungen lokal anstatt globaldefiniert werden, oder dass sie nicht mehr eingehalten werden müssen.

Beurteilung. Tolerieren von Inkonsistenzen, hier Verletzung von expliziten Be-dingungen, in diesem Kontext bedeutet letztlich die inkonsistenzverursachendenBedingungen wieder zu entfernen. Sei es durch Modifikation der Bedingungenoder das Löschen. Die Modifikation von Bedingungen mag durch die gewählteSprache für die Formulierung der Bedingungen oder die Möglichkeit der Än-derungen leichter oder komfortabler sein als bei anderen Ansätzen. Dennoch isteine Änderungen von Bedingungen prinzipiell immer möglich. Der Vorteil diesesAnsatzes kann darin gesehen werden, dass sich überhaupt mit der Möglichkeitvon zugelassenen Inkonsistenzen auseinander gesetzt wird und dies bei der For-mulierung von Bedingungen berücksichtigt wird.

4.2.4 Viewpoints

Aus dem Requirements Engineering stammt der Ansatz der Viewpoints mit demes möglich ist, Anforderungen aus Beschreibungen in unterschiedlichsten Nota-tionen von verschiedenen Stakeholdern zu bestimmen, siehe auch [Nuseibeh 94](S. 75 ff.) für weitere Informationen. Ein Viewpoint ist eine Beschreibungseinheit,die folgende Struktur besitzt:

• Eigentümer (engl. owner): Angaben zu Personen, die die Beschreibungsein-heit erstellt haben und weiter pflegen dürfen.

• Domäne (engl. domain): eine kurze Beschreibung der Thematik, meist alsStichwort.

• Arbeitsplan (engl. work plan): Auflistung erlaubter Aktionen zur Erstellungder Spezifikation sowie von Konsistenzregeln für interne (innerhalb einesViewpoints wie z.B. die Verletzung der Notation) und externe (zwischenverschiedenen Viewpoints) Konsistenz.

85


• Notation (engl. representation style): Syntaxbeschreibung der zur verwenden-den Notation für die Spezifikation.

• Spezifikation (engl. specification): eigentliche Beschreibung, die gemäß derNotation geformt ist.

• Historie (engl. work record): sie enthält die bisher durchgeführten Schritte undkann weitere Information enthalten.

Es gibt eine ganze Reihe von Veröffentlichungen über die Nutzung vonViewpoints. Zu den wichtigsten im Rahmen von Inkonsistenzen gehö-ren [Nuseibeh 96], [Easterbrook, Nuseibeh 96], [Nuseibeh, Easterbrook 99],[Nuseibeh et al. 00] und [Finkelstein 00]. Inkonsistenzen werden bei diesemAnsatz als Verletzung der definierten Regeln in den Viewpoints verstanden. Ver-letzungen der Regeln werden bei jeder Änderung der Viewpoints überprüft. DieRegeln können dabei präzisiert werden oder weitere Regeln können hinzugefügtwerden. Den Begründern dieses Ansatzes ist klar, dass es bei der Erstellungkomplexer Systeme praktisch nicht möglich ist, alle Regeln anzugeben. Ent-deckte Inkonsistenzen können korrigiert, verbessert und toleriert33 werden. ImRahmen von Studien musste entgegen den Erwartungen der Autoren festgestelltwerden, dass Inkonsistenzen bei der Entwicklung komplexer Systeme entstehenund nicht zwangsläufig korrigiert werden. Alle Maßnahmen für den Umgangmit Inkonsistenzen müssen in Zusammenhang mit dem Aufwand und Nutzengesehen werden.

Beurteilung. Dieser Ansatz setzt die Einführung von Regeln voraus, deren Ver-letzung eine Inkonsistenz bedeutet. D.h. für jeden Viewpoint muss auf eine for-male oder zumindest semi-formale Notation zurückgegriffen werden. Für no-tationelle Inkonsistenzen ist die Definition von Regeln bei Nutzung standardi-sierter Notationen, wie z.B. UML-Diagrammen, durchaus möglich. Die gewählteNotation darf keine natürliche Sprache sein. Allerdings werden Dokumente inder Praxis nur selten ausschließlich in formalen oder semi-formalen Sprachengeschrieben (siehe auch [Melchisedech 00]). Auch für die sehr viel interessante-ren externen Inkonsistenzen müssen entsprechende Regeln explizit eingeführtwerden. Woher diese Regeln kommen und wie sichergestellt wird, dass dieseRegeln nicht zusätzliche Inkonsistenzen einführen, bleibt offen. Falls auch Mo-dellinkonsistenzen aufgedeckt werden sollen, müssen entsprechende Regeln for-muliert werden, die die Domäne und das System selbst beschreiben. Dies ist dereigentliche Zweck der Beschreibungen. Ziel dieses Ansatzes ist es Inkonsistenzenautomatisch aufzudecken und zu verfolgen und daraufhin eine Aktion zu star-ten. Häufig muss dabei der Nutzer befragt werden. Zwar wurde in den durchge-führten Studien (siehe dazu mehr in Kapitel 5) festgestellt, dass bei Maßnahmen

33In den Veröffentlichungen zum Viewpoint-Ansatz wird ebenfalls der Begriff Toleranz ver-wendet. Im Gegensatz zur Definition in der vorliegenden Arbeit, bedeutet tolerieren dortdas Korrigieren von Inkonsistenzen zu einem späteren Zeitpunkt. Dennoch ist zumindest in[Nuseibeh et al. 00] auch das Tolerieren von Inkonsistenzen im Sinne dieser Arbeit zu finden undwird dort als bleibende Inkonsistenzen bezeichnet.

86

4.3. Modellinkonsistenzen

für den Umgang mit Inkonsistenzen das Aufwand/Nutzen-Kriterium berück-sichtigt werden muss. Es wurden daraus aber keinerlei Konsequenzen für eineEinschränkung der Konsistenzprüfung auf bestimmte Inkonsistenzen gezogen,um auch den Aufwand bei der Konsistenzprüfung bzw. bei der Erstellung derRegeln und somit einer erneuten Formalisierung zu reduzieren.

4.3 Modellinkonsistenzen

Die wenigsten Ansätze für den Umgang mit Inkonsistenzen befassen sich mitModellinkonsistenzen. Prinzipiell unterstützen alle Modellierungsansätze dieIdentifikation von Modellinkonsistenzen. Zum Einen bieten sie die entsprechen-den Denkeinheiten, mit denen ein Modell gebildet wird. Lassen sich Ideen oderangedachte Strukturen damit nicht gut fassen, so ist dies ein solider Hinweisfür eine Modellinkonsistenz. Des weiteren werden in Modellierungsansätzen Zu-sammenhänge zwischen den verschiedenen Denkeinheiten definiert, deren Ver-letzungen ebenfalls Indikatoren sind. Beschreibungen von Mustern (engl. pat-terns) geben auch Hinweise auf Modellinkonsistenzen. Sie halten Erfahrungenfest, in welchem Kontext und für welche Verwendung das betreffende Mustergeeignet oder nicht geeignet ist, siehe auch [Gröne 04]. Auf den Umgang mit Mo-dellinkonsistenzen wird dabei nicht eingegangen.

4.3.1 Synoptic

Mit Synoptic bezeichnet Easterbrook sein Werkzeug in [Easterbrook 91] zur Un-terstützung seines Ansatzes zur Handhabung von Inkonsistenzen im Bereich desRequirements Engineerings. Sein Ansatz basiert ebenfalls auf Viewpoints, die erals Beschreibungsmöglichkeit von Modellen aus mehreren Sichten nutzt. Der Fo-kus liegt dabei auf Modellinkonsistenzen. Er führt den Begriff Konflikt ein, der ei-ne bestimmte Form von Modellinkonsistenzen darstellt. Es handelt sich dabei umeine erkannte und zu behandelnde Modellinkonsistenz zwischen Viewpoints, diewichtig bzw. relevant ist. „A conflict, then, is simply a difference that matters.“([Easterbrook 91], S. 269). Daher hat das Werkzeug vorwiegend eine kommuni-kationsuntersützende Aufgabe. Die Entdeckung von Inkonsistenzen sowie dieMaßnahmen zur Behandlung bleiben daher vollständig dem Menschen überlas-sen.

Easterbrook schlägt folgendes Vorgehen vor:

1. Aufdeckung eines Konflikts: hierbei wird entschieden welche Inkonsistenzen(Konflikte) überhaupt korrigiert werden. Die Korrektur von Inkonsistenzensoll nur bei Konflikten – wichtigen Modellinkonsistenzen – stattfinden. DieAufdeckung eines Konflikts tritt üblicherweise bei der normalen Verwen-dung der Viewpoints auf.

87


2. Analyse des Konflikts (engl. exploration phase): im nächsten Schritt wird ver-sucht die Ursachen des Konflikts aufzudecken. Dies kann zum Beispieldurch das Finden von Übereinstimmungen geschehen, da häufig unter-schiedliche Wörter mit der gleichen Absicht benutzt werden. Teilweise wer-den gleiche Wörter verwendet, die unterschiedlich aufgefasst werden. Alsletzter Teil des Schritts werden die Punkte festgehalten, die zum Konfliktgeführt haben. Weiterhin werden Kriterien festgelegt, nach denen Lösungs-möglichkeiten bewertet werden sollen.

3. Finden von Lösungsmöglichkeiten für den Konflikt (engl. generative phase): in die-sem Schritt werden Lösungsmöglichkeiten zur Behebung des Konflikts zu-sammengetragen. Sie können Kategorien, wie Tabelle 4.1 zeigt, zugeordnetwerden.

4. Auswahl der angemessenen Lösungsmöglichkeit für den Konflikt (engl. evaluationphase): Hier wird nach Berücksichtigung aller Einordnungen, der Überein-stimmungen und der Kriterien der vorangegangenen Schritte die optimaleLösung festgelegt.

5. Lösung des Konflikts: im letzten Schritt wird die ausgewählte Lösungsmög-lichkeit angewendet. Der Konflikt wurde behoben.

inkonsistenteInterpretationen

inkonsistenteModelle

unpassendeNutzung von

Begriffen

nichtüberlappend

Unvollständigkeit,es fehlen Aussagen

in einerBeschreibung

Modelle könnenohne Konfliktevereint werden

unterschiedlicheWörter für

gleichen Begriff

teilweiseüberlappend

teilweise Überein-stimmungen, die

einerKonfliktlösung

bedürfen

Modelle könnennach

Konfliktlösungvereint werden

gleiche Wörter fürähnliche Begriffe

vollständigüberlappend

Widerspruch, eineAussage

widerspricht eineranderen

vollständiginkompatible

Modelle

gleiche Wörter fürunterschiedliche

Begriffe

Tabelle 4.1: Einordnung von Lösungsmöglichkeiten für Konflikte nach[Easterbrook 91]

Das Vorgehen ist nicht als strikte Sequenz zu sehen, sonder vielmehr als Leit-faden. Ergebnisse eines Schritts können Auswirkungen auf die Ergebnisse einesvorherigen Schritts haben. Daher kann es mehrere Iterationen geben. Diese Vor-gehen soll das Lösen von Konflikten verbessern aber auch das gegenseitige Ver-ständnis der Sichten fördern.

88

4.3. Modellinkonsistenzen

Beurteilung. Easterbrook merkt an, dass die meisten Ansätze keine Möglich-keit bieten, mit Inkonsistenzen umzugehen und daher versuchen Inkonsistenzenzu vermeiden. Dies stellt ihm zufolge einen validen Ansatz dar, der aber nicht derPraxis entspricht. Der vorgestellte Ansatz von Easterbrook konzentriert sich aller-dings auf die Auflösung von Inkonsistenzen, den Konflikten. Der Ansatz unter-scheidet zwischen Inkonsistenzen mit niedriger und hoher Bedeutsamkeit. Nurdie Konflikte, Inkonsistenzen mit hoher Bedeutsamkeit, bedürfen einer Auflö-sung. Es wird nicht klar, nach welchen Kriterien eine Inkonsistenz als Konflikt zuidentifizieren ist.

4.3.2 Agile Softwareentwicklung und agile Dokumentation

Um den Aufwand, der mit Prozessmodellen wie der RUP einhergeht, zu redu-zieren, entstanden seit Ende der 1990er einige Ansätze für agile Softwareentwick-lungen, siehe [Beck et al. 01]. Der bekannteste Vertreter ist Extreme Programming(XP) von Beck, siehe [Beck 00]. Es wird zwischen agilen Werten, Prinzipien, Me-thoden und Prozesse unterschieden. Dabei bestehen agile Prozesse aus anzuwen-denden agilen Methoden. Die agilen Methoden sind Verfahren, die auf den agilenPrinzipien beruhen. Diese wiederum basieren auf den agilen Werten. Bestimm-te agile Ansätze unterscheiden sich zwar in einigen Punkten stark, basieren aberalle auf den agilen Werten und Prinzipien.

Die Dokumentation programmierter Systeme bzw. des Programms wird im Rah-men der agilen Softwareentwicklung als agile Dokumentation bezeichnet, sie-he auch [Rüping 03]. Es wird versucht die Konsistenzproblematik zu vermeiden.Dies wird erreicht, indem die Anzahl und der Umfang schriftlicher Beschreibun-gen auf ein Minimum reduziert wird. Der Fokus soll auf langlebigen Strukturenliegen. Es sollen weiterhin nur dann Dokumente erstellt werden, wenn sie tat-sächlich benötigt werden. Alle andere Informationen finden sich im Quelltextwieder oder werden dort in Form von Kommentaren abgelegt, aus denen au-tomatisch Dokumentation erstellt werden kann. Wie Fowler in [Fowler 97] fest-stellt, sollten auch für diese Art von Dokumentation nur die wichtigsten Struk-turen dargestellt werden. Wenn alle von den Programmieren selbst erstelltenKlassen, deren Beziehungen sowie deren Methoden und Attribute, erläutert wer-den, gehen die relevanten Strukturen unter. Auch wenn eine solche Beschreibungschon eine (formale) Abstraktion darstellt.

Die erstellten Dokumente sollen ebenfalls nur so aktuell gehalten werden, wie esbenötigt wird. Es wird nicht als kritisch bewertet, wenn es Inkonsistenzen zwi-schen Aussagen in Dokumenten und im Programm gibt. Es wird argumentiert,dass eine Konsistenz zwischen Dokumenten und Programmen ohnehin praktischnicht durchführbar ist. Als Kriterium, wann ein Dokument aktualisiert werdensollte, dient die Abwägung zwischen dem Aufwand für die Aktualisierung unddem aktuellen Wert des Dokuments.

Beurteilung. Alle agilen Ansätze basieren auf den agilen Werten und Prinzi-pien. Das bedeutet, dass das funktionierende System vor alle anderen Aktivitä-

89


ten, wie z.B. die Dokumentation gestellt wird. Es sollen ausschließlich die da-für relevanten Dinge getan werden. Intensive Kommunikation bildet dafür dieGrundlage. Es bleibt allerdings offen mit welchen Mitteln dies erreicht werdensoll. Es wird z.B. kein Modellierungsansatz für die Architektur angegeben nocheine dafür angepasste Notation. Man soll einfach das nutzen, was für die jewei-lige Aufgabe am besten geeignet erscheint. Es wird festgestellt, dass UML sichnicht zur Darstellung der Architektur eignet und dass durchaus mehrere Mo-dellierungsansätze verfolgt werden müssen. Der bekannteste Ansatz, ExtremeProgramming (XP), eignet sich ausschließlich für eine kleine Anzahl von Betei-ligten. Auch die Einbindung des Kunden wird unter kommunikativen Aspektenals entscheidende Voraussetzung gesehen. Bei der Entwicklung komplexer Sys-teme können viele der agilen Werte oder Prinzipien nicht eingehalten werden, dasich die Randbedingungen unterscheiden.

90

Kapitel 5

Umgang mit Inkonsistenz intechnischen Systembeschreibungenin der Praxis

In den vorangegangenen Kapiteln wurden theoretische Grundlagen und derStand in der Literatur zum Umgang mit Inkonsistenzen erörtert. Im Bereich derKonzeptbeschreibungen existiert in der Literatur kein Ansatz für den Umgangmit Inkonsistenzen. Vielmehr wird eine nicht näher spezifizierte Konsistenz ge-fordert. Für andere Bereiche existieren einige Ansätze. Allerdings konnten für diemeisten dieser Ansätze keine Hinweise auf praktische Anwendungen gefundenwerden. Selbst bei Ansätzen mit solchen Hinweisen wurde in den allerwenigstenFällen eine Auswertung der praktischen Anwendung durchgeführt. Alle Ansät-ze stammen aus dem akademischen Umfeld und werden offenbar nicht intensivin der Praxis angewandt.

In diesem Kapitel werden die im Rahmen der vorliegenden Arbeit durchgeführ-ten Fallstudien vorgestellt, anhand derer der Umgang mit Inkonsistenzen in derPraxis analysiert wird. Ziel der Studie war es, zu identifizieren welche Inkon-sistenzen im Bereich von technischen und schriftlichen Systembeschreibungen,insbesondere Konzeptbeschreibungen, toleriert werden können. Außerdem soll-te festgestellt werden, anhand welcher Kriterien Inkonsistenzen als tolerierbareinzustufen sind. Die anschließenden Überlegungen in Kapitel 6 für den Umgangmit Inkonsistenzen in Konzeptbeschreibungen basieren auf den Ergebnissen die-ser Untersuchung.

In der Literatur sind nur wenige vergleichbare Studien zu finden. Bei diesenStudien geht es darum, einen theoretischen Ansatz in der Praxis zu bestätigen.Die Ansätze stammen aus unterschiedlichen Bereichen, beispielsweise aus demRequirements Engineering und der Programmierung. Es wird dabei nur in ei-nem Fall, im Bereich Softwaredesign/Programmierung, der Frage nachgegan-gen, welche Inkonsistenzen geduldet werden können und welche nicht. Im Be-reich der Konzeptbeschreibungen liegen solche Untersuchungen nicht vor.

Im Folgenden werden zunächst die Untersuchungsmethode und die durchge-führten Fallstudien mit den jeweiligen Einzelfallanalysen kurz vorgestellt. An-

91

Kapitel 5. Umgang mit Inkonsistenz in technischen Systembeschreibungen inder Praxis

schließend werden die Ergebnisse dargelegt. Am Ende dieses Kapitels folgen einVergleich mit anderen Studien und eine Einschätzung über die Aussagekraft dergewonnen Erkenntnisse.

5.1 Untersuchungsmethode

5.1.1 Ziel der Untersuchung

Ziel der empirischen Untersuchung war es, den Stand der Praxis im Umgangmit Inkonsistenzen in schriftlichen und technischen Systembeschreibungen, ins-besondere Konzeptbeschreibungen, zu ermitteln. Dafür wurde im Rahmen derdurchgeführten Untersuchung der Schwerpunkt auf folgende Aspekte gelegt:

1. Vermeidung von Inkonsistenzen in schriftlichen und technischen System-beschreibungen (insbesondere Konzeptbeschreibungen):

(a) Warum werden welche Maßnahmen, abhängig von der Art der Sys-tembeschreibung, zur Vermeidung von Inkonsistenzen durchgeführt?

(b) Wie werden Inkonsistenzen vermieden?

2. Feststellung von Inkonsistenzen in schriftlichen und technischen Systembe-schreibungen (insbesondere Konzeptbeschreibungen):

(a) Welche Inkonsistenzen werden festgestellt?

(b) Warum werden diese Inkonsistenzen festgestellt?

3. Behandlung von bemerkten Inkonsistenzen in schriftlichen und techni-schen Systembeschreibungen (insbesondere Konzeptbeschreibungen):

(a) Wie werden die bemerkten Inkonsistenzen behandelt?

(b) Warum werden bestimmte, bemerkte Inkonsistenzen nicht behandelt?

Diese Fragen stellen den Ausgangspunkt für eine zweckmäßige Wahl der Un-tersuchungsmethode und einen angemessenen Entwurf der Untersuchung dar.Daraus leiten sich die passenden Untersuchungsobjekte in Abhängigkeit der zurVerfügung stehenden Ressourcen und Zeit ab.

Aus den Ergebnissen der Untersuchungen soll ein besseres Verständnis für dieRolle von Inkonsistenzen in technischen und schriftlichen Systembeschreibungengewonnen werden. Daraus sollen bestimmte Verhaltensweisen für den Umgangmit Inkonsistenzen abgeleitet werden können. Dazu gehört die Vermeidung vonkritischen Inkonsistenzen, die Suche nach relevanten Inkonsistenzen sowie eineangemessene Behandlung von Inkonsistenzen.

92

5.1. Untersuchungsmethode

5.1.2 Explorative Fallstudien und qualitative Analyse

Diese Untersuchung soll unter Berücksichtigung des oben beschriebenen Zielsdie industrielle Praxis erörtern. Daraus ergeben sich die möglichen Untersu-chungsobjekte und die passende Untersuchungsmethode.

Als Untersuchungsobjekte werden Software-Entwicklungsprojekte von markt-wirtschaftlich agierenden Unternehmen gewählt, bei denen eine Synthese oderAnalyse durchgeführt wird und somit technische und schriftliche Systembe-schreibungen erstellt werden. Dies stellt den Bezug zur Praxis her. In der Regelschränken solche Projekte die Zugänglichkeit von Informationen sowie möglicheUntersuchungsmethoden ein.

Experimente scheiden als Untersuchungsmethode aus, da sie eine genaue Kon-trolle und Beschränkung der Variablen voraussetzen. Die Variablen sollten imKontext dieser Untersuchung näher bestimmt werden und somit als Vorleistungfür anschließende Experimente dienen. Ähnliches gilt für Umfragen, für welcheebenfalls die Variablen in der Anzahl beschränkt werden müssen. Umfragen ba-sieren auf Theorien, die anhand der Umfrageergebnisse bestätigt oder negiertwerden können. Die durchzuführende Untersuchung kann aufgrund fehlenderanwendbarer Theorien, nicht auf eine bereits existierende Theorie zurückgreifen.Auf die vorhergehende Erstellung einer Theorie soll hier verzichtet werden, dader Stand der Praxis möglichst objektiv erfasst werden soll. Ausgehend von die-sen objektiven Feststellungen sollen Verfahrensweisen für einen Ansatz abgelei-tet werden.

Nach [Yin 94] eignen sich Fallstudien, als empirische Untersuchungsmethode,besonders für eine solche Art der Fragestellung unter den genannten Randbe-dingungen. Da über den Umgang mit Inkonsistenzen in der Praxis nur wenigWissen vorhanden ist, werden explorative Fallstudien durchgeführt. Diese sollenden in der Praxis verwendeten Umgang mit Inkonsistenzen veranschaulichen. ImRahmen der Untersuchung sollen mehrere Projekte explorativ begleitet werden,d.h. es werden Mehrfach-Fallstudien (engl. multiple case studies) durchgeführt.Generell haben Mehrfach-Fallstudien eine höhere Verlässlichkeit und somit einehöhere Aussagekraft, da Ergebnisse einzelner Fallstudien durch andere repliziertwerden. Aufgrund des explorativen Charakters der Fallstudie und der letztlich– bedingt durch den Umfang der einzelnen Fallstudien – kleinen Anzahl durch-geführter Fallstudien, wurde auf eine quantitative bzw. statistische Auswertungverzichtet, siehe auch [Flyvbjerg 07]. Ziel der Untersuchung ist ein besseres Ver-ständnis für den praktischen Umgang mit Inkonsistenzen und somit die Fragennach dem „Wie“ und „Warum“ zu beantworten, anstatt nach dem „Wie viel“ zufragen.

Für die Datensammlung innerhalb der einzelnen Fallstudien standen folgendeQuellen zur Verfügung:

• Teilhabende Beobachtung (engl. Participant-Observation):(siehe auch [Yin 94], S. 87 ff.) aktive Teilnahme des Durchführenden der

93


Fallstudie an der Projektarbeit. Dadurch war es möglich einen tieferen Ein-blick in die Geschehnisse zu bekommen, der sonst verwehrt geblieben wä-re. Für die Analyse der Fallstudien und eine abschließende Bewertung istein tieferes Verständnis der Projektthemen speziell unter dem Aspekt vonModellinkonsistenzen notwendig.

• zur Verfügung gestellte Dokumentation:dazu gehörten in fast allen Fallstudien die Produktbeschreibungen, tech-nische Systembeschreibungen (Designbeschreibung; abstraktere Beschrei-bungen als Präsentationen), Quelltext des programmierten Systems, Be-schreibung des Entwicklungsprozesses.

• Interviews mit unterschiedlichen Projektbeteiligten:dazu gehörten Architekten, Projektleiter, Entwickler, Dokumentations- undProzessverantwortliche.

• Zugang zum entwickelten System (engl. Physical Artifacts):in den meisten Fallstudien war Zugang zum entwickelten System gegeben.

Der teilhabenden Beobachtung und der Auswertung der Dokumente wird inAbhängigkeit der Fragestellung der Untersuchung die höchste Beachtung ge-schenkt. Auf dieser Grundlage lassen sich die Maßnahmen zur Vermeidung, Ent-deckung und Behandlung von Inkonsistenzen feststellen. Eine teilhabende Be-obachtung ist notwendig, um der Frage der bemerkten Inkonsistenzen nachge-hen zu können. Wären ausschließlich die resultierenden Dokumente ausgewertetworden, könnten die Entstehung und die Beweggründe für bestimmte Behand-lungen von Inkonsistenzen nicht berücksichtigt werden. Nur auf Grundlage derfinalen Dokumente ist dies kaum mehr möglich, da sie unter Umständen schondie entsprechenden Korrekturen enthalten. Die Entscheidung für eine teilhaben-de Beobachtung statt einer passiven Beobachtung war pragmatischer Art. DerSchwerpunkt der Untersuchung sollte bei dem „natürlichen“ Umgang mit Inkon-sistenzen liegen. D.h. die Beteiligten an den Projekten, mit Ausnahme des teilha-benden Beobachters, kannten den eigentlichen Schwerpunkt nicht. Dadurch soll-te unter Umständen speziell durch die Untersuchung angeregtes Interesse unddaraus abweichendes Verhalten verhindert werden.

Die entwickelten Systeme wurden zur Einarbeitung und zur Überprüfung derZwischenergebnisse ebenfalls berücksichtigt. Die Interviews wurden in Formvon semistrukturierten Einzel- und Gruppeninterviews, wie von Yin vorgeschla-gen, durchgeführt. Die Interviews waren notwendig für eine Einführung in diejeweilige Projektthematik und unternehmensabhängige Prozesse.

Auf eine Überprüfung von Hypothesen, abgeleitet von einer vorher definier-ten Theorie, soll wegen fehlender Theorien verzichtet werden. Die Auswertungder einzelnen Fallstudien soll gemäß der Methode der Grounded Theory, be-gründet von [Glaser, Strauss 67], durchgeführt werden. Die Grounded Theoryerlaubt die Bildung einer Theorie durch die Auswertung der Daten einer odermehrerer Fallstudien. Die einzelnen Fallstudien werden gemäß des Ansatzes von[Strauss, Corbin 99] ausgewertet. Dies umfasst folgende Schritte:

94

5.2. Umfang der Untersuchung

1. Open Coding:dabei werden aufgrund der gesammelten Daten die vorgefunden Phäno-mene in Form von Stichpunkten identifiziert, benannt, beschrieben undKategorien zugeordnet. Es werden dabei hauptsächlich die Nomen berück-sichtigt. Zusätzlich werden auch Adjektive und Adverbien beachtet, um dieEigenschaften der Kategorien wiedergeben zu können.

2. Axial Coding:dabei werden die aus dem ersten Schritt gewonnen Kategorien und derenEigenschaften durch kausale Abhängigkeiten zueinander in Beziehung ge-setzt. Es wird versucht, diese Beziehungen zu erklären und zu verstehen.Dies hat zum Ziel, die vorgefundenen Phänomene zu verstehen.

3. Selective Coding:Anschließend werden Kernkategorien durch Abstraktion gebildet. Die an-deren gewonnen Kategorien werden den Kernkategorien zugeordnet. Da-bei werden die Kernkategorien auch mittels der Daten überprüft. Basierendauf den Kernkategorien und den gesammelten Daten wird ein Grundkon-zept abgeleitet, das die Phänomene erklärt.

Der Auswertung der einzelnen Fallstudien folgte eine übergreifende Analyse derGesamtuntersuchung, die so genannte Cross Case Analysis. Dabei werden dieunterschiedlichen Fallstudien verglichen, um daraus allgemeine Schlüsse zu zie-hen. Alle Projektpartner erlaubten die Auswertung der Fallstudien ausschließlichunter der Bedingung, die Ergebnisse und die Beschreibungen der einzelnen Fall-studien in anonymisierter Form wiederzugeben.

5.2 Umfang der Untersuchung

Zunächst wird ein kurzer Überblick über die Projekte, die im Rahmen der Fall-studien untersucht wurden, gegeben. Die Einzelfallanalysen der durchgeführtenProjekte sind im Anhang A aufgeführt. Sie umfassen ausführlichere Beschreibun-gen der Beobachtungen und der Ergebnisse.

Die durchgeführte Untersuchung umfasste 4 Fallstudien, siehe Anhang A. Dazugehörten 4 Projekte in 3 Unternehmen. Tabelle 5.1 listet alle im Rahmen der Fall-studien durchgeführten Projekte auf und gibt einige Eckdaten der Projekte an. Esist auffällig, dass ausschließlich Projekte in großen Unternehmen in den Fallstudi-en untersucht wurden. Dies ist auf das besondere Interesse großer Unternehmenan Konzeptbeschreibungen zurückzuführen, das in kleineren Unternehmen fehltoder finanziell nicht unterstützt wird.

Die Einzelfallanalysen werden anhand folgender Struktur beschrieben:

• Übersicht: eine kurze Beschreibung des Projekts und des Kontexts, um einebessere Einordnung zu ermöglichen.

95


• Prozess der Dokumentationserstellung: die Darstellung des verwendeten Pro-zesses für die schriftliche Formulierung von Modellen im Zusammenhangmit Inkonsistenzen.

• Konsistenzprüfung: die verwendeten Verfahren für die durchgeführten Kon-sistenzprüfungen in Abhängigkeit der jeweiligen Inkonsistenzklassen wer-den zusammengefasst.

• Inkonsistenzbewertung: die Zuordnungen der bemerkten Inkonsistenzen zuderen Bewertungen und deren Behandlung in Abhängigkeit der Inkonsis-tenzklassen.

• Sonstige Eigenschaften: weitere Beobachtungen im Zusammenhang mit In-konsistenzen.

5.3 Gesamtauswertung der Untersuchung

Aufbauend auf den Einzelfallanalysen, siehe Anhang A, wird im Folgenden dievergleichende Gesamtauswertung der Untersuchung vorgestellt. Die Strukturder Gesamtauswertung entspricht der der Einzelfallanalysen. Zur Übersicht wer-den die Resultate der Einzelfallanalysen in Tabellenform dargestellt. Obwohl sichdie Domänen der einzelnen Fälle und die verfolgten Ziele der erstellten Kon-zeptbeschreibungen deutlich unterscheiden, lassen sich viele Gemeinsamkeitenbezüglich der Vorgehen und Kriterien zur Bewertung von Inkonsistenzen fest-stellen.

5.3.1 Konzeptbeschreibungen

Alle untersuchten Projekte hatten zum Ziel die zugrundeliegenden Konzepte zudokumentieren. Bedingt durch den Umstand, dass im Vorfeld keine Konzept-beschreibungen existierten, muss davon ausgegangen werden, dass die Doku-mentation von Konzepten selten durchgeführt wird. Alle Projekte wurden ingroßen Unternehmen durchgeführt, die ausgereifte Prozesse vorschreiben. AlleKonzeptbeschreibungen wurden von externen Mitarbeitern angefertigt. Bei denProjekten 2 und 3 wurde die Entscheidung dazu aufgrund fehlender Ressourcengefällt. Bei den Projekten 1 und 4 sollte bewusst auf externes Wissen und Er-fahrungen zurückgegriffen werden. Die folgende Tabelle 5.2 zeigt eine Übersichtüber die beabsichtigte Verwendung der Konzeptbeschreibung innerhalb der ein-zelnen Projekte und die Anzahl externer Mitarbeiter, die an der Erstellung derDokumente mitarbeiteten.

Bei allen Unternehmen wurde die Wichtigkeit von Konzeptbeschreibungen allge-mein anerkannt und gefördert. Die Unternehmen versuchten aktiv den momen-tanen Dokumentationsstand zu verbessern.

96

5.3. Gesamtauswertung der UntersuchungPr

ojek

t1Pr

ojek

t2Pr

ojek

t3Pr

ojek

t4

Unt

erne

hmen

Unt

erne

hmen

1in

tern

atio

nal,

sehr

groß

Unt

erne

hmen

2in

tern

atio

nal,

sehr

groß

Unt

erne

hmen

3in

tern

atio

nal,

sehr

groß

Unt

erne

hmen

1in

tern

atio

nal,

sehr

groß

Dom

äne

Ente

rpri

seR

esou

rce

Plan

ning

Prod

ukti

onsa

utom

ati-

sier

ung

eing

ebet

tete

Syst

eme

Ente

rpri

seR

esou

rce

Plan

ning

Prod

ukta

rtPr

oduk

tent

wic

klun

gPr

oduk

tent

wic

klun

gPr

oduk

tent

wic

klun

gm

itku

nden

spez

ifisc

hen

Anp

assu

ngen

Prod

ukte

ntw

ickl

ung

Prod

uktu

mfa

ngA

nzah

lSys

tem

e:2

Mit

arbe

iter

:34

Anz

ahlS

yste

me:

2A

ufw

and:

>20

0M

JM

itar

beit

er:

>30

Auf

wan

d(S

W):

150

MJ

Auf

wan

d(H

W):

50M

JM

itar

beit

er(S

W):

25(a

ussc

hlie

ßlic

hK

ernk

ompo

nent

en)

Anz

ahlK

ompo

nent

en:8

(Ans

chlie

ßend

Foku

sau

fein

eK

ompo

nent

e)M

itar

beit

er:

>30

0

Proj

ekta

rtA

naly

seun

dSy

nthe

seA

naly

seun

dSy

nthe

seA

naly

seA

naly

se

Proj

ektz

iel

Erst

ellu

ngvo

nSy

stem

besc

hrei

bung

enzu

rve

rtei

lten

Entw

ickl

ung

Dok

umen

tati

onei

nes

Kon

zept

sfü

rdi

eIn

tegr

atio

nzw

eier

Syst

eme

Erst

ellu

ngei

ner

Syst

emdo

kum

enta

tion

Erst

ellu

ngvo

nVo

rgab

enun

dK

ompo

-ne

nten

doku

men

tati

on

Proj

ektu

mfa

ngA

ufw

and:

4M

JM

itar

beit

er:

8A

ufw

and:

5M

JM

itar

beit

er:

9

Auf

wan

d:5

MJ

LOC

:26

0kL

OC

Mit

arbe

iter

:10

Auf

wan

d:3

MJ

Mit

arbe

iter

:ca

.20

resu

ltier

ende

Dok

umen

te

Anz

ahl:

kein

eU

mfa

ng:

–D

iagr

amm

e:17

Anz

ahl:

1U

mfa

ng:

161

Seit

enD

iagr

amm

e:11

8

Anz

ahl:

12U

mfa

ng:

196

Seit

enD

iagr

amm

e:10

4

Anz

ahl:

2U

mfa

ng:

13Se

iten

Dia

gram

me:

2

Abk

ürzu

ngen

:M

JM

annj

ahre

LOC

Anz

ahld

erQ

uellt

extz

eile

n(e

ngl.

Line

sof

Cod

e)kL

OC

Anz

ahld

erQ

uellt

extz

eile

n(e

ngl.

Line

sof

Cod

e)*

1000

HW

Har

dwar

eSW

Soft

war

e

Tabe

lle5.

1:Ü

berb

lick

über

die

Proj

ekte

imR

ahm

ende

rdu

rchg

efüh

rten

Falls

tudi

en

97


Projekt 1 Projekt 2 Projekt 3 Projekt 4

Art TP 1: SyntheseTP 2: Analyse

Analyse undSynthese Analyse Analyse

erstelltdurch

externeMitarbeiter (3)




ver-folgtesZiel

erhöhteEffizienz beider verteiltenEntwicklung

Zusammen-führung zweier

Produkte

Einarbeitungneuer

Mitarbeiter,Erfüllung von

Unternehmens-vorgaben

Erhöhung derWiederver-wendung

AnzahlMo-delle

TP 1: 3TP 2: 4 19 22 1

TP: Teilprojekt

Tabelle 5.2: Verfolgte Ziele der Konzeptbeschreibungen

5.3.2 Prozess der Dokumentationserstellung

Der Prozess der Dokumentationserstellung war bei keinem der Projekte im Vor-feld definiert. Es etablierte sich bei allen Projekten ein sehr ähnlicher Prozess.Tabelle 5.3 zeigt zum einfacheren Vergleich einige Aspekte des Prozesses der Do-kumentationserstellung auf.

Der erste Schritt war bei allen Projekten eine Zieldefinition, bei der die inhaltli-che Ausrichtung bestimmt wurde. Bei allen Projekten wurde eine deutliche undverständliche Beschreibung der übergeordneten Zusammenhänge angestrebt, diesich in relativ kurzer Zeit aneignen lässt. Weiterhin wurde bei allen Projekten eineEinführung in die Systeme bzw. Thematik durch die verantwortlichen Mitarbei-ter der Unternehmen gegeben.

Die Ersteller der Dokumente sammelten bei allen Projekten zunächst Informa-tionen. Dabei kamen prinzipiell die gleichen Informationsquellen zum Einsatz.Hauptinformationsquelle waren Wissensträger, als Interviewpartner. Zusätzlichwurden bereits existierende Unterlagen auf Relevanz geprüft. Es wurden aus-schließlich die als relevant betrachteten Unterlagen ausgewertet. Die Verwen-dung dieser Informationsquellen kam unabhängig von der Art der Auswertung –sei es Synthese oder Analyse – zum Einsatz. Das zu untersuchende System konn-te nur bei der Analyse, d.h. in den Projekten 2, 3, 4 und bei Teilprojekt 2 im erstenProjekt, verwendet werden. Die Quelltexte wurden nur bei Projekt 3 verwendet,da bei Projekt 2 die Quelltexte nicht eingesehen werden durften und bei den Pro-jekten 1 und 4 aus zeitlichen Gründen deren Untersuchung ausgeschlossen wur-de.

Zunächst wurden aufbauend auf den gesammelten Informationen Modelle zu-sammengestellt, die in Form von Diagrammen festgehalten wurden. Bei allenProjekten wurde als Modellierungsansatz die Fundamental Modeling Concepts

98

5.3. Gesamtauswertung der Untersuchung

Projekt 1 Projekt 2 Projekt 3 Projekt 4definierterDokumentationsprozess nein nein nein nein

Informationsquellen

Interviews,Unterla-

gen,System

(nur bei TP2)

Interviews,Unterla-

gen,System

Interviews,Quelltext,

System

Interviews,Unterla-

gen,System

Modellierungsansatz FMC FMC FMC FMC

Werkzeuge zurErstellung

Word,Visio, Po-werPoint




Vorlagen nein nein ja* nein**Sprache Englisch Englisch Englisch EnglischregelmäßigwiederkehrendeÜberprüfungen

TP 1: jaTP 2: nein ja ja ja

finale Überprüfung derDokumente

ja ja ja ja

zentraler Ablageort(nicht verwaltet) ja ja ja ja

*: existierende Vorlagen wurden angepasst**: Vorlagen wurden im Rahmen des Projekts als Projektbestandteil erstellt

Tabelle 5.3: Betrachtete Eigenschaften für den Prozess der Dokumentationserstel-lung für Konzeptbeschreibungen

(FMC) verwendet. Dadurch ergaben sich die Notation der Diagramme und dieFragestellungen für die Modellierung. Während der Erstellung der ersten Dia-gramme überprüften die Ersteller ihre Modelle gegenseitig. Dies geschah vor al-lem bei den Projekten 2 und 3. Dabei wurden die identifizierten Lücken in denModellen, die sich aus den Fragen während der Modellierung ableiteten, bespro-chen. Nur bei den Projekten 1 und 4 wurden Fragenkataloge explizit aus Hy-pothesen und Antithesen erstellt. Bei allen Projekten wurden die noch offenenFragen nach der Erstellung initialer Diagramme an die jeweiligen Wissensträ-ger gestellt. Auf diese Weise wurden die Modelle korrigiert und verfeinert. An-schließend wurden diese Zwischenergebnisse den Empfängern bei den Projekten1 (Teilprojekt 2), 2, 3 und 4, in Form von Präsentationen, vorgestellt und mit ihnenbesprochen. In Projekt 1 (Teilprojekt 1) wurde keine Präsentation durchgeführt,die Diagramme wurden ausschließlich in direkten Gesprächen vorgestellt undbesprochen. Grund dafür war die geringe Teilnehmerzahl an diesem Teilprojekt.Dieser Vorgang des Präsentierens und Besprechens wurde in allen Projekten, au-ßer in Projekt 1 (Teilprojekt 2), in regelmäßigen Abständen wiederholt.

Nachdem alle notwendigen Modelle und die zugehörigen Diagramme erstellt

99


wurden, begann bei den Projekten 2, 3 und 4 die Anfertigung der angestrebtenDokumentation. Bei Projekt 1 wurden ausschließlich die bereits erstellten Dia-gramme überarbeitet. Die eigentliche Anfertigung der Dokumente verlief weit-gehend unabhängig von den anderen Projektbeteiligten. Die Struktur der Doku-mente wurde bei den Projekten 2 und 3 vor Beginn der Anfertigung festgelegt.Weiterhin wurde das Layout der existierenden Diagramme bei allen Projektenaufgebessert und teilweise wurde die Diagramme aus didaktischen Gründen un-terschiedlich aufgeteilt oder zusammengefasst. Bei keinem der Projekte wurdenexistierende Vorlagen verwendet. Nur bei Projekt 3 wurden bereits vorhandeneVorlagen modifiziert, da sie den angestrebten Inhalten nicht genügten. Bei denProjekten 1 und 4 kamen aufgrund der Zielsetzung keine Vorlagen zur Verwen-dung. Bei Projekt 1 wurden bis auf die Diagramme keine weiteren Beschreibun-gen angefertigt. Bei Projekt 4 war die Erstellung einer Vorlage ein Teil des Projekt-ziels. Bei allen Projekten wurden die gleichen maschinengestützten Werkzeugeverwendet, um Texte, Präsentationen und Diagramme zu erstellen. Gleicherma-ßen wurde in allen Projekten die englische Sprache verwendet. Für die Projekte2 und 3, bei denen neben Diagrammen auch ausführliche Textbeschreibungenverwendet wurden, nahm diese Phase etwa die Hälfte der gesamten Dokumen-tationsdauer in Anspruch. Diese relativ lange Zeitspanne für die Erstellung aus-führlicher Beschreibungen ist auf die Verwendung einer Fremdsprache und dieUnerfahrenheit beim Verfassen von Texten zurückzuführen.

Im Anschluss an die Erstellung der Dokumente bzw. die Finalisierung der Dia-gramme wurden diese bei allen Projekten von einigen Mitarbeitern der Unter-nehmen überprüft. Die Ergebnisse dieser Überprüfungen gingen an die Erstellerzurück und wurden mit ihnen besprochen. Die Besprechungen hatten zum Ziel,die Inkonsistenzen zu identifizieren und deren Korrektur zu beschließen. Die ab-gesprochenen Änderungen wurden durchgeführt. Eine erneute Prüfung der letz-ten Version wurde bei keinem der Projekte durchgeführt.

Danach wurden die finalisierten Dokumente oder Diagramme durch die Mitar-beiter der Unternehmen an einem zentralen Ablageort zur Verfügung gestellt.Die weitere Benutzung dieser Dokumente war nicht Bestandteil der Untersu-chung und blieb daher unberücksichtigt.

Zusammenfassend ist der Prozess der Dokumentationserstellung in Bild 5.1 dar-gestellt. Dies dient im späteren Verlauf als Referenz. Er umfasst die gemeinsamenPunkte wie die unterschiedlichen zur Verfügung stehenden Informationsquellen,die Werkzeuge zur Erstellung der Dokumente und die Empfänger der Dokumen-te.

5.3.3 Konsistenzprüfung

Bei allen Projekten wurden während der Dokumentationserstellung wiederholtKonsistenzprüfungen von den Erstellern und den Empfängern der Dokumen-tation durchgeführt. Die Konsistenzprüfungen wurden zu verschiedenen Zeit-punkten von verschiedenen Beteiligten im Prozess der Dokumentationserstel-lung durchgeführt. Eine zusammenfassende Übersicht über die durchgeführten

100


Überprüfung durch EmpfängerDokumenterstelllung

Informationsquellen

Werkzeug

Analytiker

Beschreibungen

Wissensträger(z.B. aus

Entwicklung)System

Zustand

Source Code

sonstigeUnterlagen

Ersteller

RInterview

Werkzeug(z.B. Textverarbetungssystem, Zeichenwerkzeug)

Dokumente

AnalytikerEmpfänger

WerkzeugWerkzeug zur Betrachtung

(z.B. Textverarbetungssystem, Zeichenwerkzeug)

Bild 5.1: Prozess der Dokumentationserstellung

Konsistenzprüfungen ist in Tabelle 5.4 gelistet. Es werden die verwendeten Ver-fahren gemäß den identifizierten Inkonsistenzklassen und der Rolle der Erstellerund Empfänger aufgezeigt.

Die erste erkennbare Konsistenzprüfung wurde bei allen Projekten von den Er-stellern während der initialen Erstellung von Diagrammen durchgeführt. Dabeiwurde von den Erstellern zunächst nicht auf notationelle und vorgabenbeding-te Inkonsistenzen geachtet. Es wurde vielmehr auf interne Modellinkonsistenzengeprüft, was eine ausgiebige Nutzung von maschinenunterstützten Werkzeugenverhinderte. Bei der Prüfung auf interne Modellinkonsistenzen in dieser Phasekonnten beim ersten Projekt keine explizit verwendeten Verfahren festgestelltwerden. Die Ersteller überprüften in allen Projekten die Plausibilität ihrer in Dia-grammen ausgedrückten Modelle. In Projekt 1 Teilprojekt 1, bei dem währendder Interviews Diagramme skizziert wurden, unterstützen die Interviewpartnerdie Überprüfung der Modelle. Sie verglichen die Diagramme und Aussagen derErsteller mit ihrem Wissen. Dadurch wurden interne und externe Modellinkon-sistenzen schon bei der Erstellung der Diagramme aufgedeckt und korrigiert.

Vor der Präsentation der Zwischenergebnisse, zur Überprüfung durch die Emp-fänger, wurden die erstellten Diagramme und Präsentationen durch die Erstel-ler überprüft. Bei allen Projekten wurde auf syntaktische Inkonsistenzen ge-prüft. Dafür wurden die entsprechenden Werkzeuge verwendet. Dies warenRechtschreib- und Grammatikprüfungen für Texte. In Projekt 3 wurden zusätz-lich die Notationsregeln für FMC Diagramme mit einem Werkzeug überprüft.Gefunden Inkonsistenzen wurden in der Regel sofort korrigiert. Andere vorga-benbedingte Inkonsistenzen wurden nicht überprüft. Zufällig entdeckte Inkon-sistenzen solcher Art während der Erstellung wurden bei allen Projekten direktbehoben. Ein zufälliges Aufdecken von Inkonsistenzen soll im Folgenden als„Ad-hoc-Verfahren“ bezeichnet werden. Sie sind nicht geplant und richten sich

101


Projekt 1 Projekt 2 Projekt 3 Projekt 4Prüfung der Dokumentation/Diagramme von den Erstellern auf

vorgabenbedingte I

syntaktische I Werkzeug fürTexte

Werkzeug fürTexte

Werkzeug fürTexte und

Diagramme

Werkzeug fürTexte

semantische I – – – –sonstige I – – – –

MI

interne MIFragenkatalogauf Basis vonHypothesen

PlausibilitätFragenkata-

log,Plausibilität

Fragenkata-log,

Plausibilität

externe MIFragenkatalogauf Basis vonHypothesen

PlausibilitätFragenkata-

log,Plausibilität

Fragenkata-log,

PlausibilitätPrüfung der Dokumentation/Diagramme von den Empfängern auf

vorgabenbedingte Isyntaktische I – – – –semantische I – – – –

sonstige I – –

Checkliste(gegeben

durchausgearbeitete

Vorlage)

Checkliste(gegeben

durchausgearbeitete

Vorlage)MI

interne MIPlausibilität,

(nur TP 2)Vorwissen

Plausibilität,Vorwissen



externe MIPlausibilität,

(nur TP 2)Vorwissen




I: InkonsistenzenMI: ModellinkonsistenzenVorwissen: Experten prüfen aufgrund ihres VorwissensPlausibilität: sonstige Mitarbeiter prüfen aufgrund von Plausibilität

Tabelle 5.4: Explizit durchgeführte Konsistenzprüfungen bezüglich der identifi-zierten Inkonsistenzklassen

102


nicht nach bestimmten Inkonsistenzen. Es wurden immer wieder zufällig Inkon-sistenzen aufgedeckt, die in der Regel sofort behoben wurden. Falls sie nicht so-fort behoben wurden, hing die Korrektur von der Sorgfalt der Person ab, die dieInkonsistenzen entdeckt hat. Aufgedeckte Inkonsistenzen wurden nicht notiert,um sie zu einem späteren Zeitpunkt beheben oder bewerten zu können.

Danach wurden die Diagramme in regelmäßigen Abständen den Empfängernzur Konsistenzprüfung übergeben, außer bei Projekt 1 Teilprojekt 2 wo dies ledig-lich zum Abschluss geschah. Die Empfänger wandten bei allen Projekten keineerkennbaren Verfahren für die Konsistenzprüfungen an. Nur bei den Projekten 3und 4 wurden die Vorgaben, gegeben durch die Vorlagen, durch die projektver-antwortlichen Mitarbeiter des Unternehmens geprüft. Sie verwendeten die Vor-lagen wie Checklisten. Nach Modellinkonsistenzen wurde durch die projektver-wantwortlichen und nicht spezialisierten Mitarbeiter bei allen Projekten, bis aufProjekt 1 (Teilprojekt 1) bei dem alle Beteiligten Experten waren, gesucht. Dazuwurden vornehmlich Plausibilitätsüberprüfungen verwendet, die sich nach all-gemeinem technischen und domänenrelevanten Wissen richten. Das verwende-te Verfahren ist „als Ad-hoc-Verfahren“ einzustufen, da hierbei kein konkret ge-plantes oder wiederholbares Vorgehen zu erkennen war. Die spezialisierten Mit-arbeiter (Experten) konnten durch ihr Vorwissen interne und externe Modellin-konsistenzen entdecken und diese konkret in Bezug zu dem System setzen. DieseArt der Überprüfung soll ebenfalls als „Ad-hoc-Verfahren“ bezeichnet werden,da auch hierbei das Vorgehen nicht geplant oder wiederholbar war. Dies war beiallen Projekten identisch mit Ausnahme von Projekt 4. Dort wurden die Expertennicht mit den Beschreibungen durch das Vortragen oder Lesen konfrontiert, son-dern die Ersteller verwendeten einen Fragenkatalog. Mit dessen Hilfe wurdendie Experten befragt und die Beschreibungen überprüft.

Mit den Kommentaren der Empfänger wurden die Diagramme überarbeitet.Durch die regelmäßig durchgeführten Überprüfungen bei allen Projekten (bisauf Projekt 1 Teilprojekt 2) des aktuellen Standes wurden zeitintensive Überar-beitungen der Diagramme ausgeschlossen. Nach der letzten Überprüfung wur-de bei allen Projekten, bis auf Projekt 1, mit der Erstellung der Zieldokumen-tation begonnen. Von den Erstellern der Dokumentation wurden die inhaltlichabgeschlossenen Dokumente und die darin enthaltenen Diagramme auf syntak-tische Inkonsistenzen geprüft. Hierbei kamen für die textuellen Beschreibungendie gleichen maschinengestützten Werkzeuge zum Einsatz, wie zur Vorbereitungder Diagramme für die Empfänger in den vorangegangenen Schritten. AndereKonsistenzprüfungen wurden nicht durchgeführt.

Die Empfänger überprüften bei allen Projekten die finalisierte Dokumentation.Für die inhaltlichen Belange wurden bei allen Projekten die spezialisierten Mitar-beiter herangezogen. Die Überprüfung von Vorgaben, z.B. bei den verwendetenVorlagen in Projekt 3 und 4, wurde von den verantwortlichen Mitarbeitern durch-geführt. In den Projekten 1 und 2 wurde auf die Überprüfung von Vorgaben ver-zichtet. Teilweise wurden zufällig vereinzelte Inkonsistenzen, z.B. semantischeInkonsistenzen im Projekt 2, aufgedeckt.

Die Tabelle 5.5 fasst die durch die Konsistenzprüfung gefundenen Inkonsisten-

103


Projekt 1 Projekt 2 Projekt 3 Projekt 4Prüfung durch Ersteller auf

vorgabenbedingte Isyntaktische I ja, Werkzeug ja, Werkzeug ja, Werkzeug ja, Werkzeugsemantische I keine keine keine keine

sonstige I keine keine keine keineMI

interne MI keine keine keine keineexterne MI keine keine keine keine

Prüfung durch Empfänger aufvorgabenbedingte I

syntaktische I keine keine keine keinesemantische I keine ja (1), ad hoc ja (3), ad hoc keine

sonstige I keine keine ja (9),Checkliste keine

MI

interne MI keine keine ja (6),Vorwissen keine

externe MI keine keine ja (2),Vorwissen keine

I: InkonsistenzenMI: Modellinkonsistenzen

Tabelle 5.5: Gefundene Inkonsistenzen in der Gesamtdokumentation durch Kon-sistenzprüfungen bezüglich der Inkonsistenzklassen

zen in der Gesamtdokumentation zusammen. Die zum Zwecke der Überprüfungerstellten Diagramme und Präsentationen sind hierbei nicht berücksichtigt. So-weit möglich wird die Anzahl der gefunden Inkonsistenzen und das angewandteVerfahren angegeben.

5.3.4 Inkonsistenzbewertung

In allen Projekten gab es weder bei den Erstellern noch bei den Empfängern expli-zite Kriterien, wonach die gefundenen Inkonsistenzen gewichtet wurden. Den-noch wurde eine Unterscheidung der Bedeutsamkeit der gefundenen Inkonsis-tenzen implizit durchgeführt. Diese entspricht den identifizierten Inkonsistenz-klassen. Da keine expliziten Kriterien existierten, wurden die gefunden Inkonsis-tenzen der Empfänger zusammen mit den Erstellern besprochen und bewertet.

In allen Projekten wurden syntaktische Inkonsistenzen als unkritisch angesehen,da bei allen Projekten nur die Ersteller explizit darauf prüften. Die Empfängersuchten weder explizit danach noch merkten sie welche an. Semantische Inkon-sistenzen wurden bei allen Projekten, bis auf Projekt 1, als wichtiger als syntakti-sche Inkonsistenzen eingestuft. In Projekt 1 wurden semantische Inkonsistenzen

104


nicht gefunden und daher nicht bewertet. In Projekt 4 wurden auch keine seman-tischen Inkonsistenzen gefunden, da zu Beginn des Projekts festgelegt wurde,welche Wörter nicht verwendet werden durften. Sonstige vorgabenbedingte In-konsistenzen wurden in den Projekten 1 und 2 als unwichtig bewertet. In denProjekten 3 und 4 wurden sie als wichtiger eingestuft, da bei beiden ProjektenVorlagen existierten. Bei Projekt 4 sollte ein Vorgabe für Konzeptbeschreibungenerstellt werden. Daher waren dort vorgabenbedingte Inkonsistenzen wichtiger.Die Vorgaben wurden dort immer wieder während des Projekts umgestellt unddie Beschreibungen daran angepasst.

Modellinkonsistenzen wurden im Allgemeinen bei allen Projekten als die bedeu-tendsten Inkonsistenzen angesehen. In den ersten zwei Projekten, wo sich dasfehlende Verständnis der Domäne negativ auf den Projekterfolg auswirkte, wur-de dies von allen Beteiligten als äußert kritisch eingestuft. Aufgrund des fehlen-den Domänenwissens in den Projekten 1 und 2 wurden die externen Modellin-konsistenzen dort als besonders gravierend bewertet. Sonst können keine unter-schiedlichen Bewertungen als Ergebnis der Projekte festgestellt werden.

Tabelle 5.6 listet die Bewertung der durch die Empfänger gefunden Inkonsisten-zen in den vier Projekten bezüglich der Inkonsistenzklassen zusammenfassendauf.

Projekt 1 Projekt 2 Projekt 3 Projekt 4vorgabenbedingte Isyntaktische I - - - -semantische I - o o osonstige I - - o +MIinterne MI + + + +externe MI ++ ++ + +


Symbol Bedeutsamkeit- geringo mittel+ hoch

++ sehr hoch (Domänenwissen)

Tabelle 5.6: Bewertung von Inkonsistenzen bezüglich der Inkonsistenzklassen

Die Bedeutsamkeit der gefunden Inkonsistenzen war ausschlaggebend für ihreBehebung. Da die meisten gefunden Inkonsistenzen schnell zu korrigieren wa-ren, wurden diese behoben. Die gefundenen vorgabenbedingten Inkonsistenzenin Projekt 3 wurden nicht behoben. Die Korrekturen hätten den Rahmen desProjekts deutlich überschritten, da die Vorlage für die Beschreibung von Quell-textstrukturen gedacht war und sie zur Konzeptbeschreibung lediglich erwei-tert wurde. Weiterhin wurden die gefundenen Modellinkonsistenzen in Projekt

105


Projekt 1 Projekt 2 Projekt 3 Projekt 4vorgabenbedingte I

syntaktische I alle (sehrgering)

alle (sehrgering)

alle (sehrgering)

alle (sehrgering)

semantische I – alle (sehrgering)

alle (sehrgering) –

sonstige I – – ~80%(gering) –

MI

interne MI – – alle(gering) –

externe MI – – alle(gering) –


Tabelle 5.7: Behobene Inkonsistenzen bezüglich der Inkonsistenzklassen

4 Phase 1 nicht behoben, da sie nur zur Einarbeitung der externen Mitarbeiterndiente und durch die zu erarbeitenden Beschreibungen ersetzt werden sollten.

Die behobenen Inkonsistenzen innerhalb aller Projekte sind in Tabelle 5.7 bezüg-lich der Inkonsistenzklassen gelistet. Dort ist auch der damit verbundene Auf-wand in Klammern angegeben.

5.4 Ergebnis der Untersuchung

Aufgrund der Gesamtauswertung der Untersuchung in Kapitel 5.3 können fol-gende Erkenntnisse in Bezug auf den Umgang mit Inkonsistenzen in technischenund schriftlichen Systembeschreibungen in der Praxis gewonnen werden:

Entscheidung für die Dokumentation von Konzepten. Die Entscheidung Kon-zepte zu dokumentieren, hängt mit dem Projektreifegrad, der Größe der Projekteund der Notwendigkeit Systemwissen standortübergreifend auszutauschen zu-sammen. Große Unternehmen erkennen die Wichtigkeit von Konzeptbeschrei-bung und unterstützen deren Erstellung. Die Unternehmen besitzen bereits zu-geschnittene Softwareprozesse.

Prozess der Dokumentationserstellung. Der Prozess der Dokumentationser-stellung ist wenig ausgeprägt und nicht explizit definiert, obwohl umfangrei-che Beschreibungen der eingesetzten Softwareprozesse existieren. Es liegen keinepassenden Vorlagen, speziell für Konzeptbeschreibungen, vor. Existierende Vor-lagen aus anderen Bereichen werden angepasst, um allgemeinen Vorgaben zugenügen.

106

5.4. Ergebnis der Untersuchung

Der angewandte Prozess der Dokumentationserstellung ist sehr einfach aufge-baut. Nach der initialen Zieldefinition werden Informationen zum System ge-sammelt. Diese Informationen werden zu Modellen zusammengeführt und über-prüft. Halten die Modelle den Überprüfungen der Beteiligten Stand, werden siein Form eines Dokuments verschriftlicht. Zur Überprüfung des aktuellen Pro-jektfortschritts werden auch in regelmäßigen, teilweise sehr kurzen, AbständenPräsentationen durchgeführt. Die Konsistenzprüfung wird von den Erstellernder Dokumentation und den Empfängern durchgeführt. Das Niederschreibengeschieht weitgehend unabhängig von den restlichen Beteiligten, wie z.B. denProjektverantwortlichen. Nach Fertigstellung der Dokumentation wird diese zurfinalen Überprüfung den Empfängern zur Verfügung gestellt.

Als Werkzeuge werden hauptsächlich standardmäßig verfügbare und allgemeinnutzbare Werkzeuge verwendet. Dies sind unter anderem Textverarbeitungssys-teme, Zeichenwerkzeuge und Präsentationssysteme. Die Ablage von Dokumen-ten ist zumeist lose geregelt und hängt vom Umgang der Beteiligten ab. Es gibtinsbesondere keinen Dokumenationsverantwortlichen, der Dokumente verwal-tet. Somit ist in den Ablagesystemen keine gepflegte Struktur vorzufinden. Dieverwendete Sprache für solche Dokumente ist Englisch. Alle Dokumente wer-den als elektronische Medien gespeichert, wobei die nichtelektronische Form alsAusdruck auf Papier berücksichtigt wird.

Informationssammlung. Die Phase der Informationssammlung unterscheidetsich abhängig davon, ob das Konzept für die Synthese eins Systems oder für dieAnalyse eines Systems beschrieben wird. Bei der Synthese eines neuen Systemsstehen ausschließlich die beteiligten Mitarbeiter zur Verfügung, die befragt wer-den können. Bei der Analyse eines Systems stehen zusätzlich noch die Quelltexte,Dokumentation und das System selbst zur Verfügung. Das System wird zur Ein-arbeitung oder Validierung von Modellierungsergebnissen verwendet. Bestehen-de Dokumente eignen sich selten für eine Einarbeitung oder für die Modellierungvon Konzepten, da sie zu detailliert oder Produktbeschreibungen sind. Quelltex-te stellen die verlässlichste Informationsquelle dar.

Die Art und Weise auf welche Informationen herausgefiltert werden, steht in di-rektem Zusammenhang mit dem angewendeten Modellierungsansatz und denursprünglich verfolgten Zielen. Definierte Vorgehen zur Analyse eines Systemsexistieren nicht.

Prozess der Konsistenzprüfung. Konsistenzprüfungen werden von allen Be-teiligten durchgeführt. Es werden alle Klassen von Inkonsistenzen bei der Über-prüfung berücksichtigt. Es wird aber nicht explizit zwischen Klassen von Kon-sistenzen bzw. Inkonsistenzen unterschieden, d.h. es wird keine fokussierte Kon-sistenzprüfung auf bestimmte Klassen durchgeführt. Selten läuft ein geplantesVorgehen bei der Konsistenzprüfung ab.

Für syntaktische Inkonsistenzen werden während der Erstellung standardmä-ßig werkzeugunterstützte Prüfungen verwendet. Teilweise werden spezialisierte

107


Werkzeuge genutzt, die keine syntaktischen Inkonsistenzen zulassen. Syntakti-sche Inkonsistenzen werden vorwiegend von der Erstellern der Dokument be-merkt. Für die restlichen notationellen und vorgabenbedingten Inkonsistenzenist kein Vorgehen bei der Konsistenzprüfung feststellbar. Semantische Inkonsis-tenzen werden vorwiegend von den Empfängern bemerkt. Vorgabenbedingte In-konsistenzen werden vorwiegend von den projektverantwortlichen Mitarbeiternbemerkt.

Auf Modellinkonsistenzen wird zunächst von den Erstellern und anschließendvon den Empfängern geprüft. Die Empfänger führen die Konsistenzprüfungenentweder während der Interviews und Präsentationen durch oder bei Erhalt derfertiggestellten Dokumentation. Die Anzahl der Präsentationen hat keinen Ein-fluss auf die Anzahl der gefunden Inkonsistenzen. Bei den Konsistenzprüfun-gen werden keine offensichtlichen Techniken verwendet. In wenigen Einzelfällenwerden Antithesen und Hypothesen gebildet und daraus entsprechende Fragen-kataloge erarbeitet. Die dominierenden Überprüfungstechniken sind die Plausi-bilitätsprüfung und Prüfungen auf Basis des Vorwissens. Dies sind beides „Ad-hoc-Verfahren“. Zu den bemerkten Modellinkonsistenzen gehören vor allem in-terne Modellinkonsistenzen. Sie werden während der Erstellung der Diagrammedurch die Ersteller selbst bemerkt. Interne und externe Modellinkonsistenzen,durch Vergleich der beschriebenen Modelle und bestehendem Wissen, werdenvornehmlich von den Empfängern festgestellt.

Bedeutsamkeit entdeckter Inkonsistenzen. Es existieren im Vorfeld keine defi-nierte Kriterien für die Bedeutsamkeit von Inkonsistenzen. Dennoch wird intuitiveine Gewichtung der Inkonsistenzen vorgenommen.

Notationelle und vorgabenbedingte Inkonsistenzen sind praktisch bedeutungs-los. Bedingt durch die einfache, schnelle und teilweise automatische Überprü-fung treten solche Inkonsistenzen kaum auf. Da die Empfänger die Dokumen-te und Diagramme nicht explizit auf syntaktische Inkonsistenzen prüfen, mussdavon ausgegangen werden, dass Dokumente ohne Rechtschreibfehler von denEmpfänger als selbstverständlich angesehen werden. Fälle, bei denen eine star-ke Häufung von notationellen und vorgabenbedingten Inkonsistenzen auftreten,kommen praktisch nicht vor. Einzig semantischen Inkonsistenzen, speziellen no-tationellen Inkonsistenzen, wird eine höhere Bedeutsamkeit zugesprochen. Siestellen für das Verständnis aber kein Hindernis dar, da die passende Bedeutungdurch den Kontext erschlossen werden kann.

Die bedeutendste Klasse der Inkonsistenzen sind Modellinkonsistenzen. Für dieErsteller ist ein ausreichendes Verständnis der entsprechenden Domäne Voraus-setzung, um mit der Erstellung der Beschreibung beginnen zu können. Im Allge-meinen werden entdeckte Modellinkonsistenzen einzeln abgewägt und bewertet.Andere Maßnahmen zur Gewichtung von Modellinkonsistenzen werden nichtangewendet. Die endgültige Beurteilung der Bedeutsamkeit einer Inkonsistenzim gegebenen Kontext wird von den projektverantwortlichen Personen durchge-führt. Die Bedeutsamkeit der entdeckten Inkonsistenz ist für die Entscheidungzur Behebung maßgeblich.

108

5.5. Vergleichbare Untersuchungen

Kriterium für die Behebung entdeckter Inkonsistenzen. Alle beteiligten Per-sonen sind bestrebt alle bemerkten Inkonsistenzen zu beseitigen, um eine mög-lichst hohe Qualität zu erzielen. Es existieren keine vorher definierten Kriteri-en wann, wie und von wem entdeckte Inkonsistenzen zu beseitigen sind. Dieentdeckten Inkonsistenzen werden von den Erstellern der Dokumente beseitigt.Für jede einzelne entdeckte Inkonsistenz von größerer Bedeutung, also semanti-sche Inkonsistenzen und Modellinkonsistenzen, wird deren Behebung abgewägt.Hierbei werden vor allem der Nutzen und der für die Behebung verbundene Auf-wand abgewägt. Die berücksichtigte Größe für den Aufwand ist hauptsächlichdie aufzubringende Zeit.

Der Aufwand zur Behebung unbedeutender Inkonsistenzen ist am geringsten.Syntaktische Inkonsistenzen, zum Beispiel, lassen sich sehr schnell und einfachkorrigieren. Solche Inkonsistenzen werden deshalb vollständig behoben. Sonsti-ge vorgabenbedingte Inkonsistenzen können einen höheren Aufwand erfordern.Je nach zur Verfügung stehender Ressourcen und Zweckmäßigkeit der Vorgabenwerden diese behoben. Die Behebung von Modellinkonsistenzen hingegen ist inder Regel deutlich aufwendiger. Dennoch werden sie aufgrund ihrer Bedeutsam-keit zumeist behoben.

5.5 Vergleichbare Untersuchungen

Nur wenige Untersuchungen zum Umgang mit Inkonsistenz in Sys-tembeschreibungen sind in der Literatur zu finden. Dazu gehören u.a.[Russo et al. 98], [Gervasi, Nuseibeh 02], [Kuzniarz, Staron 03], [Lange et al. 03],[Spanoudakis, Kassis 00] und [Lange, Chaudron 06]. Dabei handelt es sich umFallstudien oder Experimente bestehende Ansätze zu stützen. Diese Unter-suchungen haben also einen anderen Schwerpunkt als die hier vorliegendeArbeit. Die aufgelisteten Studien werden im Folgenden näher beleuchtet undkommentiert. Keine dieser Studien widmet sich dem Thema Inkonsistenzen inKonzeptbeschreibungen.

In [Russo et al. 98] wird eine Fallstudie vorgestellt, die den Ansatz der View-points validieren soll. Dafür wurden zwei existierende Anforderungsdokumentemit einem Gesamtumfang von 24 Seiten gemäß dem Ansatz umformuliert, um-strukturiert und die dazugehörigen Konsistenzregeln definiert. Die ursprüngli-chen Dokumente sind in natürlicher Sprache (hier Englisch) gehalten und enthal-ten ein einziges Ablaufdiagramm. Durch die Explizitmachung der Zusammen-hänge zwischen den Anforderungen durch Konsistenzregeln konnten Inkonsis-tenzen identifiziert werden. Mit Hilfe der Konsistenzregeln und Konsistenzprü-fung wurde auch festgestellt, dass durch fortlaufende Änderungen der Original-dokumente weitere Inkonsistenzen hinzugefügt worden waren. Neue Aussagenund Korrekturen bereits erkannter Inkonsistenzen wurden nicht an allen relevan-ten Stellen der Dokumente eingefügt. Bei dieser Studie wurden keine Aussagenüber die Relevanz der gefunden Inkonsistenzen sowie über deren weitere Be-handlung gemacht. Über die weitere Verwendung der neu erstellten Dokumente

109


gemäß dem Ansatz, außer zur Konsistenzprüfung, werden ebenfalls keine Aus-sagen gemacht.

Im gleichen Projektkontext wie [Russo et al. 98] wurde in [Gervasi, Nuseibeh 02]ein 250 Seiten starkes und in englischer Sprache gehaltenes Anforderungsdoku-ment auf Inkonsistenzen hin überprüft. Das Dokument wurde mittels eines exis-tierenden Werkzeugs eingelesen. Anschließend wurden Konsistenzregeln defi-niert, anhand derer eine Konsistenzprüfung durchgeführt wurde. Ergebnis dieserStudie ist, dass keine syntaktischen Inkonsistenzen gefunden werden konnten. Eswurden vier semantische Inkonsistenzen – hier die Verwendung von Synonymen– gefunden, die in nachfolgenden Versionen des Anforderungsdokuments korri-giert wurden. Dies deckt sich mit den Ergebnissen der im Rahmen dieser Ar-beit durchgeführten Fallstudien. Die restlichen gefunden Inkonsistenzen warenModellinkonsistenzen und basierten auf Vermutungen bezüglich der Funktiondes Systems, die bei der Erstellung der Konsistenzregeln eingeflossen waren. DieRegeln wurden von den Autoren aufgestellt, die keinerlei Kenntnisse über dieDomäne verfügten. Die damit identifizierten Modellinkonsistenzen wurden vonden Autoren als potentiell problematisch eingestuft. Sie wurden aber in den dar-auf folgenden Versionen des Dokuments nicht korrigiert. Gründe dafür wurdennicht angegeben.

Von 2002 bis 2004 wurden drei Workshops zur Konsistenzproblemaktik in derUML-basierten Softwareentwicklung im Rahmen der internationalen Konfe-renzen zur UML abgehalten, siehe [Kuzniarz et al. 02], [Kuzniarz et al. 03] und[Huzar et al. 04]. Ziel dieser Workshops war eine Klassifikation von Inkonsis-tenzen in UML Diagrammen und Möglichkeiten Inkonsistenzen werkzeugun-terstützt aufzuspüren. Daher beschränken sich die Untersuchungen auf nota-tionelle Inkonsistenzen. Die UML Diagramme sollen für Transformationen hinzum Quelltext geeignet sein. Daher sind keine Inkonsistenzen erlaubt. Dennochwird erkannt, dass Inkonsistenzen nicht immer aufgelöst werden müssen: „Thedeveloper may want to know about any inconsistencies in their model [hierUML Diagramm] at any time, but it may not always be convenient or appro-piate to have their resolution enforced.“ ([Gryce et al. 02], S. 128). Es wird nichtweiter untersucht auf welche Inkonsistenzen dies zutrifft. Im Rahmen dieserWorkshops wurden einige Studien durchgeführt. Bei einem Experiment, siehe[Kuzniarz, Staron 03], wird die Beschreibung eines Systems eines Studenten ana-lysiert. Dem Studenten lagen die Anforderungen an das System sowie ein Pro-zess vor, der vorgab welche Dokumente bzw. Diagramme in welcher Reihenfolgezu erstellen waren. Es konnte eine Vielzahl von Inkonsistenzen gefunden wer-den. Dabei wurden keine notationellen Inkonsistenzen gefunden, sondern aus-schließlich Verletzungen von Interdokumentbeziehungen, also vorgabenbeding-ten Inkonsistenzen. Beispielsweise fehlten Attribute oder Methoden in Klassen-diagrammen, die in Sequenzdiagrammen benannt wurden. Es bleibt allerdingsunklar, inwiefern eine zweite Iteration eine Verbesserung erbracht hätte oder obauf Basis der Beschreibungen ein funktionsfähiges Programm erstellt wurde. Diezweite Studie, siehe [Lange et al. 03], hatte einen Umfang von drei Fallstudien imindustriellen Umfeld. Hierbei wurde sich darauf beschränkt die Inkonsistenzenzu quantifizieren. Dazu wurden Konsistenzregeln aufgestellt und die entstan-

110

5.5. Vergleichbare Untersuchungen

denen Dokumente damit überprüft. Es stellte sich heraus, dass Anzahl und Artder Inkonsistenzen stark variieren und die Programmierung trotz bestehenderInkonsistenzen begonnen wird.

Experimente, beschrieben in [Spanoudakis, Kassis 00], sollen den Ansatz der Au-toren zur Bewertung von Inkonsistenzen zwischen Diagrammen in der UML No-tation validieren. Dazu wurden Diagramme, die das Softwaredesign von drei un-terschiedlichen Systemen beschreiben, untersucht. Zwei davon wurden von Stu-denten erstellt, ein anderes ist ein im Internet frei verfügbares Beispiel. Die höchs-te Anzahl der Klassen in einer Software beträgt 59. Hierbei wurden ebenfalls Kon-sistenzregeln definiert, deren Verletzungen als vorgabenbedingte Inkonsistenzenzu werten sind. Zusätzlich zu den Konsistenzregeln werden durch die Entwicklerfestgelegte Vorschriften für die Bedeutsamkeit der entdeckten Inkonsistenzen aufBasis von Softwaremetriken34 bestimmt. Für jede gefundene Inkonsistenz wurdedie jeweilige Bedeutsamkeit bestimmt, womit eine Priorisierung für die Korrek-tur erreicht wurde. Aus der Beschreibung der Experimente geht nicht hervor wiedie Diagramme weiter hätten verwendet werden sollen. Für eine automatischeGenerierung von Quelltext wären die entdeckten Inkonsistenzen kritisch gewor-den bzw. hätten korrigiert werden müssen, um ein funktionierendes System zuerhalten. Bezüglich einer einzigen Regel wurden für ein System 278 Inkonsisten-zen gefunden.

Experimentelle Untersuchungen mit einer sehr ähnlichen Fragestellung, wie sieder hier vorliegenden Arbeit zugrunde liegt, sind in [Lange, Chaudron 06] zu fin-den. Studenten und in der Industrie tätigen Entwicklern wurden mehrere UMLDiagramme und ein Multiple Choice Fragenkatalog zur Verfügung gestellt. Indie UML Diagramme waren zuvor einige Inkonsistenzen eingebaut und Elemen-te aus ihnen entfernt worden, die zu vorgegebenen Inkonsistenz- und Unvoll-ständigkeitstypen passten. Bei allen im Experiment untersuchten Inkonsistenzenhandelt es sich um vorgabenbedingte Inkonsistenzen. Beispielsweise wird eine ineinem Klassendiagramm benannte Klasse in Sequenzdiagrammen nicht referen-ziert. Der Fragenkatalog war so aufgebaut, dass vier alternative Realisierungs-möglichkeiten in Form von Pseudocode zur Verfügung standen. Zusätzlich gabes die Möglichkeit keine der vier Alternativen anzugeben und festzustellen, dassein Fehler in den Diagrammen erkannt worden war. Die Aufgabe bestand al-so darin eine programmiertechnische Umsetzung aus den vorgegebenen UMLDiagrammen anzugeben. Aus den Antworten konnte abgeleitet werden, welcheInkonsistenzen oder Unvollständigkeiten leicht unbemerkt bleiben und mit wel-chen trotzdem ein gemeinsames Verständnis zustande kommt. Das Ergebnis desExperiments ist, dass der überwiegende Teil der Befragten trotz enthaltener Feh-ler in den Diagrammen eine Realisierungsmöglichkeit angibt. Wenn keine Fehlerin Diagrammen enthalten sind, werden auch keine Fehler „erfunden“. Die In-terpretationen der als nicht fehlerhaft erkannten aber tatsächlich fehlerbehafte-ten Diagramme sind überwiegend gleich. Da es um eine programmiertechnische

34Eine Softwaremetrik soll hier als eine Vorschrift, die ausgehend von ausgewählten Merk-malen einer Software (oder eines Programms) einen charakterisierenden Wert liefert, verstandenwerden.

111


Umsetzung ging, sind nicht referenzierte Klassen in Sequenzdiagrammen am zu-verlässigsten erkannt worden. Dafür gab es aber die größte Uneinigkeit über eineRealisierungsmöglichkeit. Ein Klassendiagramm gibt eine statische Sicht wäh-rend das Sequenzdiagramm einen möglichen Ablauf angibt, der für die Imple-mentierung der Methoden unerlässlich ist. Zusätzlich wurde festgestellt, dassin diesem Kontext Sequenzdiagramme und nicht Klassendiagramme als Refe-renz dienten. Dies ist auf die programmiertechnische Aufgabe zurückzuführen.Da die untersuchten Inkonsistenzen vorgabenbedingt waren, hätte man erwartenkönnen, dass das Domänenwissen nicht ausschlaggebend ist. Laut den Autorenhat sich aber gezeigt, dass Domänenwissen sich negativ auf eine einheitliche In-terpretation auswirkt. Da dies nicht im Fokus der Untersuchung lag, bedarf diesin diesem Kontext weiterer Untersuchungen. Es wurde nicht ausgewertet inwie-fern das Verständnis tatsächlich unterschiedlich ist, da durchaus mehrere Reali-sierungsmöglichkeiten zu einem sehr ähnlichen Systemverhalten führen können.

5.6 Aussagekraft der Untersuchung

Im Rahmen der hier vorliegenden Untersuchung wurden vier Projekte in unter-schiedlichen Bereichen und Größen durchgeführt. Ziel war es den in der Pra-xis angewandten Umgang mit Inkonsistenzen bei der Erstellung von Konzept-beschreibungen zu erörtern. Immer wurde auf Inkonsistenzen geachtet und ent-sprechende Gegenmaßnahmen wurden eingeleitet. Der Prozess der Dokumenta-tionserstellung war bei allen Projekten nahezu identisch. Auch bei der Konsis-tenzprüfung und der Inkonsistenzbewertung wurde auf gleiche Art und Weiseverfahren. Für eine umfassendere Beleuchtung der Praxis müssten entsprechen-de umfangreichere Untersuchungen durchgeführt werden. Bei der Hälfte der un-tersuchten Projekte nahmen Studenten teil. Eine Verfälschung durch studentischeTeilnehmer konnte reduziert werden, indem Studenten und professionelles Teil-nehmer nach der gleichen Arbeitsweise vorgingen. Zudem unterlag die studen-tische Arbeit ständigen Kontrollen durch die professionellen Teilnehmer.

Ein Aspekt blieb bei der Untersuchung aufgrund der methodischen Herange-hensweise unberücksichtigt. Inwiefern der angestrebte Leserkreis, nämlich neueMitarbeiter und Mitarbeiter, die auf Basis der Dokumente Pflege- und Wartungs-arbeiten durchführen sollen, die so erstellten Konzeptbeschreibungen wiederumauf Konsistenz überprüfen und welche Inkonsistenzen tolerierbar sind, konnte inAnbetracht des zeitlichen Aufwands nicht berücksichtigt werden. An Stelle deseigentlich angestrebten Leserkreises wurden „Ersatzleser“ herangezogen, die dieLeserrolle zur Überprüfung der Dokumente übernahmen. Zwar waren in allenFällen die „Ersatzleser“ ein Teil des angestrebten Leserkreises, aber die Anzahlder Leser war deutlich geringer und es waren keine neuen Mitarbeiter beteiligt.Auch über die weitere Handhabung der Dokumente, wie deren Pflege (Anpas-sungen an neue Gegebenheiten), konnte im Rahmen dieser Untersuchung keineverwertbaren Aussagen getroffen werden. Dies beinhaltet auch die Bewertungvon Inkonsistenzen, die im Rahmen des Projekts unbemerkt blieben. Es ist durch-aus möglich, dass sich bestimmte unbemerkte oder als unkritisch eingeschätzte

112

5.6. Aussagekraft der Untersuchung

Inkonsistenzen zu einem späteren Zeitpunkt als kritisch erweisen. Es ist prin-zipiell ausgeschlossen, solche Fehleinschätzungen vollständig zu vermeiden, dageänderte oder neue Rahmenbedingungen berücksichtigt werden müssen, die imVorfeld nicht bekannt waren. Weiterhin war das schriftliche Festhalten der Kon-zepte expliziter Bestandteil aller Projekte in dieser Untersuchung. In Interviewswurde von fast allen Beteiligten geäußert, dass Dokumentation bei zeitlich kriti-schen Projekten zuerst vernachlässigt wird, um Zeit zu gewinnen.

Auf der Basis der gewonnen Erkenntnisse dieser Untersuchung und der Ergeb-nisse der vergleichbaren Untersuchungen wird im folgenden Kapitel 6 ein Ansatzzum Umgang mit Inkonsistenzen in Konzeptbeschreibungen vorgestellt.

113


114

Kapitel 6

Ein Ansatz fürKonzeptbeschreibungen unterBerücksichtigung tolerierbarerInkonsistenzen

Ziel dieses Kapitels ist, einen Ansatz für Konzeptbeschreibungen programmier-ter Systeme unter spezieller Berücksichtigung tolerierbarer Inkonsistenzen vor-zustellen. Dieser Ansatz dient als Entscheidungshilfe für die Erstellung von Kon-zeptbeschreibungen und für die Aufwandsminimierung, ohne Reduzierung desNutzens der Beschreibung. Der Ansatz geht davon aus, dass Konzeptbeschrei-bungen durch Inkonsistenzen nicht völlig unbrauchbar werden und ein bestimm-tes Maß an Inkonsistenzen, das das Arbeiten mit dem System ohne zu großenzusätzlichen Aufwand erlaubt, toleriert werden kann.

Der im Folgenden beschriebene Ansatz baut auf den Ergebnissen des vorange-gangenen Kapitels auf und wendet diese an. Maßgebliches Kriterium ist dabeidas in der Untersuchung festgestellte Aufwand/Nutzen-Kriterium. Neben demErstellen von Konzeptbeschreibungen wird auch die Konsistenzprüfung wäh-rend des Lesens der Beschreibungen berücksichtigt.

6.1 Kriterien für tolerierbare und nicht tolerierbareInkonsistenzen in Konzeptbeschreibungen

Durch die Erstellung von Konzeptbeschreibungen wird erheblichen Unvollstän-digkeiten und Modellinkonsistenzen entgegengewirkt, wodurch Unternehmenvor allem die interne Kommunikation verbessern. Im Gegensatz zu anderen Be-schreibungen, wie z.B. den weitverbreiteten aus Kommentaren des Quelltextesgenerierte API Beschreibungen35, entstehen Konzeptbeschreibungen üblicher-

35JavaDoc ist ein Beispiel eines Werkzeugs, das aus speziell geformten Kommentaren in derProgrammiersprache Java gehaltenen Quelltexten API Beschreibungen generiert.

115

Kapitel 6. Ein Ansatz für Konzeptbeschreibungen unter Berücksichtigungtolerierbarer Inkonsistenzen

weise nicht ohne äußere Maßnahmen. Es stellt sich daher die Frage, ab wannüberhaupt Konzeptbeschreibungen notwendig werden und inwiefern der Nut-zungsgrad der Beschreibung durch Inkonsistenzen reduziert wird. Folgende zurAbschätzung gedachte Formeln stellen eine Entscheidungshilfe hinsichtlich derErstellung von Konzeptbeschreibungen dar:

AGKB = AEKB + n · AMKB (6.1)

AGOKB = n · AOKB (6.2)

α(AGOKB, AGKB) =

{ja, wenn AGOKB > AGKB

nein, wenn AGOKB ≤ AGKB(6.3)

mit AOKB � AMKB und AEKB ≈ AOKB

wobei:

AGKB Gesamtaufwand für Erstellung und Verstehen der KonzeptbeschreibungAEKB Aufwand für Erstellung der KonzeptbeschreibungAMKB Aufwand für Verstehen mit KonzeptbeschreibungAGOKB Gesamtaufwand für Verstehen ohne KonzeptbeschreibungAOKB Aufwand für Verstehen ohne Konzeptbeschreibung

n Anzahl Beteiligte

Die erste Formel 6.1 gibt den Gesamtaufwand an, der für die Erstellung einerKonzeptbeschreibung und für Lesen und Verstehen der Beschreibung in Abhän-gigkeit von der Anzahl der Beteiligten entsteht. Formel 6.2 hingegen gibt denGesamtaufwand für das Verständnis des Systems ohne existierende Konzept-beschreibung an. Sobald mehr Aufwand dadurch entsteht, dass alle Beteiligtensich das Verständnis auf anderem Wege aneignen als primär über die Studie derKonzeptbeschreibung, lohnt die Erstellung der Konzeptbeschreibung (siehe For-mel 6.3). Anhand der Formeln wird deutlich, dass sich die Erstellung von Kon-zeptbeschreibungen vor allem bei einer größeren Anzahl Beteiligter rasch positivauswirkt. Es gilt jedoch zu beachten, dass der Aufwand für die Erstellung derKonzeptbeschreibung ohnehin zu großen Teilen durchgeführt werden muss, dadie Festlegung der „Architektur“ die Grundlage der Entwicklung darstellt. Auchwenn keine explizite Modellierungsphase für die Synthese festgelegt wird, er-gibt sich diese spätestens bei Beginn der Programmiertätigkeit. Beispiele in Bild6.1 und dazugehörige Werte in Tabelle 6.1 verdeutlichen die Formeln nochmalsgraphisch.

In den erstellten Konzeptbeschreibungen existieren Inkonsistenzen und neue In-konsistenzen kommen durch Änderungen am System hinzu. Diese Inkonsisten-zen schmälern den Nutzen der Konzeptbeschreibungen. Zwar sind Konzeptbe-schreibungen mit völliger interner und externer Konsistenz theoretisch denkbar,

116

6.1. Kriterien für tolerierbare und nicht tolerierbare Inkonsistenzen inKonzeptbeschreibungen

0

1000

2000

3000

4000

5000

6000

7000

8000

9000

1 3 5 7 9 11 13 15 17 19 21 23 25 27 29 31 33 35 37 39 41 43 45 47 49


Aufw

ände

Aufwand[GKB] Aufwand[GOKB]

(a) mit Aufwand aus den durchgeführten Projekten

0

100

200

300

400

500

600

700

1 3 5 7 9 11 13 15 17 19 21 23 25 27 29 31 33 35 37 39 41 43 45 47 49


Aufw

ände

Aufwand[GKB] Aufwand[GOKB]

(b) mit vermeintlich vorteilhafter Aufwandsverteilung

Bild 6.1: Vergleich Aufwand mit und ohne Konzeptbeschreibung (Beispiele)

117


Beispiel AEKB AMKB AOKB Kommentar(a) 175 5 160 Werte auf Basis der durchgeführten

Projekte (siehe Kapitel 5)(b) 60 10 12 gewählte, vermeintlich vorteilhafte Werte

Tabelle 6.1: Verwendete Werte zu den Beispielen für Aufwand (siehe Bild 6.1)

aber sie scheitern in der Praxis an der beschränkten Verfügbarkeit der Ressour-cen. Dies hat die Untersuchung in Kapitel 5 gezeigt. Zwar werden bei der Erstel-lung und Evolution von Konzeptbeschreibungen intuitiv Maßnahmen zur Ver-meidung und zum Auffinden von Inkonsistenzen durchgeführt. Diese sind al-lerdings wenig konkret und ausgereift. Es existieren auch keine expliziten Krite-rien, nach denen Konsistenzprüfungen und Inkonsistenzbewertungen durchge-führt werden. Bei der Untersuchung im Rahmen dieser Arbeit wurde aber fest-gestellt, dass durchaus ein Kriterium für das Tolerieren von Inkonsistenzen exis-tiert. Wenn der Aufwand für die Behebung einer entdeckten Inkonsistenz höherist als der Nutzen der behobenen Inkonsistenz, wird die entdeckte Inkonsistenztoleriert. Daher sollte versucht werden, den Nutzen der Konzeptbeschreibungangemessen hoch zu halten. Der Nutzen einer (inkonsistenzfreien) Konzeptbe-schreibung liegt in den darin enthaltenen Informationen zum System, aus deneneine Vorstellung von dem System abgeleitet werden kann. Deshalb sind wertvol-le Aussagen in Konzeptbeschreibungen solche, für deren Zusammenstellen bzw.Auffinden – ohne die Verwendung existierender Konzeptbeschreibungen36 – einsehr hoher Aufwand erbracht werden muss. Zusätzliche und damit zu viele In-formationen verhindern das einfache Ableiten von Modellen aus den Konzept-beschreibungen. Im Bereich Designbeschreibungen plädieren [Fowler 97] und[Albers 04] für ein ähnliches Vorgehen.

Daraus lassen sich nachfolgende Formeln ableiten, die eine Einschätzung für dasKriterium vermitteln sollen. Es ist allerdings realistischer Weise anzunehmen,dass diese Formeln keine praktische Verwendung finden werden, da Bewertun-gen von Inkonsistenzen letztlich immer subjektiver Natur sind. Wie auch in denUntersuchungen, werden die Verantwortlichen ihre Entscheidungen, anhand ih-rer persönlichen Einschätzungen treffen.

N = νK(Konzeptbeschreibung)−m

∑i=1

νI(Inkonsistenzi) (6.4)

N!≥ NLIM (6.5)

wobei:

N verbleibender Nutzen der KonzeptbeschreibungνK(KB) Nutzen durch Lesen der Konzeptbeschreibung KB

νI(I) (verlorener) Nutzen durch Inkonsistenz Im Anzahl der bemerkten Inkonsistenzen

NLIM festgelegte Grenze des akzeptierten Nutzens, z.B. 80%

36Hierunter sollen sowohl schriftliche als auch mündliche Konzeptbeschreibungen fallen.

118


Wird die Grenze des festgelegten Nutzens unterschritten, so ist die Behebung derbedeutsamen Inkonsistenzen angemessen.

Konzeptbeschreibungen, die Inkonsistenzen enthalten, sind keineswegs un-brauchbar. Auch wenn dies in der Literatur immer wieder behauptet wird. Vgl.z.B. [Clements et al. 03]: „Documentation that is incomplete or out-of-date doesnot reflect truth, does not obey its own rules for form and internal consistency,[...] is not used. Documentation that is kept current and accurate is used.“ (S.27). Diese Ansicht lässt sich leicht durch ein Beispiel aus dem alltäglichen Lebenwiderlegen. Man denke an einen veralteten – also einen mit dem aktuellen Stadt-gefüge inkonsistenten – Stadtplan. Inkonsistenzen könnten z.B. durch neue oderumbenannte Straßen bedingt sein. Mit Hilfe eines veralteten Stadtplans lässt sichdas gewünschte Ziel in der Regel dennoch problemlos erreichen. Die Inkonsis-tenzen können sich auf das Ziel möglicherweise nicht auswirken – unbemerkteInkonsistenzen – oder die Inkonsistenzen können sich leicht, z.B. durch einfacheSchlussfolgerungen basierend auf der Orientierung, beheben lassen – tolerierba-re Inkonsistenzen. Problematisch wird es erst, wenn die Inkonsistenzen so gra-vierend werden, dass das Auffinden des Ziels nicht oder kaum mehr möglichist – nicht tolerierbare Inkonsistenzen. Diese können z.B. bei sehr alten Stadt-plänen auftreten, wenn durch sie keine Orientierung möglich ist. Entsprechenddem Aufwand/Nutzen-Kriterium wird eine Person ihren tolerierbar inkonsisten-ten Stadtplan nicht aktualisieren. Ähnlich dem Beispiel mit dem Stadtplan soll-te bei der Erstellung oder Modifikation von Konzeptbeschreibungen überprüftwerden, inwiefern die darin enthaltenen Inkonsistenzen toleriert werden könnenoder nicht. Diese explizite Berücksichtigung tolerierbarer Inkonsistenzen, auchbeim Lesen von Dokumenten, soll zusätzlichen Aufwand vermeiden und Über-prüfungen zielgerichteter gestalten.

6.1.1 Tolerierbare Inkonsistenzen

Zu den tolerierbaren Inkonsistenzen zählen, gemäß dem Kriterium desAufwand/Nutzen-Faktors, alle Inkonsistenzen deren Existenz zu keinemerhöhten Aufwand führen. Das Auftreten solcher Inkonsistenzen inschriftlichen Konzeptbeschreibungen verhindert weder das Verständnis desGeschriebenen, noch stellen diese signifikante Hindernisse dar. Es bestehtdann kein zwingender Bedarf, die Inkonsistenz zu beheben.

Nachfolgend wird die Einordnung tolerierbarer Inkonsistenzen mit einigen Bei-spielen bezüglich ihrer Inkonsistenzklasse durchgeführt, siehe auch Tabelle 6.2für eine Zusammenfassung. Diese Einordnung dient als erste Richtlinie, die ent-sprechend spezifischer Projektanforderungen angepasst werden muss.

• Notationelle Inkonsistenzengehören praktisch immer zu den tolerierbaren Inkonsistenzen. Es gibtkaum Fälle bei denen z.B. so viele Rechtschreibfehler oder grammatika-lische Fehler auftreten, dass der Sinn des Textes oder der Diagrammenicht einfach zu erschließen wäre. Beispielsweise sind die meisten Texte

119


mit Rechtschreibfehlern problemlos lesbar. Auch die bekannte beliebigeVertauschung von Buchstaben innerhalb eines Wortes bis auf den Anfangs-und Endbuchstaben stört das Verständnis nicht, siehe auch [Rawlinson 76].Sind die notationellen Inkonsistenzen wider Erwarten nicht tolerierbar,so wird dies sofort beim Lesen des entsprechenden Textes deutlich. Dieskann z.B. geschehen, wenn die gewählte Sprache für die Beschreibung demErsteller oder dem Leser nicht geläufig ist. Eine weitgehende Abwesenheitvon notationellen Inkonsistenzen wird in der Regel von den Empfängerndennoch erwartet und als Qualitätsmerkmal angesehen. Eine möglicheBegründung dafür ist der Rückschluss von der notationellen Qualität aufdie inhaltliche Qualität. Deshalb soll in diesem Ansatz nicht vollständig aufeine Konsistenzprüfung bezüglich notationeller Inkonsistenzen verzichtetwerden (siehe Kapitel 6.2.1).

Beispiel für notationelle Inkonsistenzen:„Deiser Text enthalt Reschtchreibfheler und eingrammatikalischen Fehler.“

• Sonstige vorgabenbedingte Inkonsistenzenschränken, wie notationelle Inkonsistenzen, das Verständnis prinzipiellnicht ein. Insbesondere Verletzungen von Vorgaben, die das Layout vonDokumenten und Diagrammen bestimmen, sind in der Regel unkritisch.So sind beispielsweise vergessene oder ungültige Verweise in Dokumentenzwar nicht gewollt, verhindern aber normalerweise nicht das Auffindender entsprechenden Informationen. Modellierungsansätze bzw. entspre-chende Methoden machen ebenfalls Vorgaben. Neben den Vorgaben,die das Layout betreffen, werden auch Vorgaben aus den dem Model-lierungsansatz zugrundeliegenden Konzepten definiert. So soll z.B. beiFMC-Aufbaudiagrammen die Unterscheidung von passiven und aktivenTeilen eines Systems auch durch deren Bezeichnung deutlich werden.Beispielsweise ist die Bezeichnung eines Speichers als Datenbankmanage-mentsystem eine klare Verletzung einer Vorgabe. Üblicherweise bleibt dasVerständnis davon unberührt. Fast alle Vorgaben sind letztlich Richtlinien,deren Einhaltung eine einheitliche Verwendung der Beschreibungen undsomit eine schnellere Aufnahme der Informationen erlaubt. Teilweisewerden solche Richtlinien absichtlich verletzt, um bestimmte Aussagen zuunterstreichen. Die im Rahmen diese Arbeit durchgeführte Untersuchunghat gezeigt, dass nicht tolerierbare vorgabenbedingte Inkonsistenzenpraktisch nicht vorkommen – auch ohne Werkzeugunterstützung bei derKonsistenzprüfung.

Beispiel für methodenbedingte Inkonsistenz:

120


Verwalter

Flugbuchungen

Datenbank-

managementsystem

(DBMS)

Ein FMC Aufbaudiagramm mit falscher Speicherbezeichnung.

• Modellinkonsistenzenwerden generell geduldet, wenn sie das Verständnis in ausreichendemMaße erlauben oder sie unmittelbar und eindeutig aufgelöst werdenkönnen. Sind die Modellinkonsistenzen nicht einfach und unmittelbardurch den Leser selbst aufzulösen, sollten sie behoben werden. WelcheModellinkonsistenzen leicht lösbar sind und welche nicht, hängt imWesentlichen vom Wissen des Empfängerkreises ab. In der Regel stellenkleinere Ungenauigkeiten, wie z.B. Abweichungen von Kardinalitäten inDiagrammen und Texten, für den Empfänger keine gravierenden Problemedar.

Beispiel für Modellinkonsistenz:

DBMSKorridor (Route)

Cache

Kartendaten

Variante 1:

Cache wird bei Bedarf gelöscht.

Variante 2:

Cacheinhalte werden bei Bedarf

als gelöscht markiert.

• Unbemerkte Inkonsistenzengehören auch zu den tolerierbaren Inkonsistenzen. Da ihre Existenz un-bekannt ist, werden sie zwangsläufig toleriert. Die unbemerkten Inkonsis-tenzen sind relativ zu den empfangenden und erstellenden Personen zubetrachten. So kann eine durch eine Person unbemerkte Inkonsistenz voneiner anderen Person entdeckt werden. Auch unterschiedliche Zeitpunk-te können entscheidend sein für unbemerkte oder bemerkte Inkonsisten-zen. So kann eine bereits existierende Inkonsistenz erst zu einem späterenZeitpunkt im Entwicklungsprozess entdeckt werden, da erst dann die Auf-merksamkeit darauf gelenkt wird. Sobald vorher unbemerkte Inkonsisten-zen entdeckt werden, sollte ihre Inkonsistenzklasse festgestellt werden, umden weiteren Umgang bestimmen zu können.

121


Inkonsistenzklasse Relevanz Kommentar

unbemerkte Inkonsistenzen - bei Entdeckung, Inkonsistenzklassebestimmen

notationelle Inkonsistenzen - nur wenige Fälle, die dasVerständnis beinträchtigen

sonstige vorgabenbedingteInkonsistenzen o schränken das Verständnis

normalerweise nicht ein

Modellinkonsistenzen + tolerierbar, wenn unmittelbar undeindeutig auflösbar

Tabelle 6.2: Tolerierbare Inkonsistenzen

6.1.2 Nicht tolerierbare Inkonsistenzen

Zu den nicht tolerierbaren Inkonsistenzen in Konzeptbeschreibungen gehörenentsprechend des Aufwand/Nutzen-Kriteriums alle Inkonsistenzen, die denAufbau des Verständnis unverhältnismäßig lange hinauszögern oder dasVerständnis nicht ermöglichen.

Nachfolgend wird die Einordnung nicht tolerierbarer Inkonsistenzen mit einigenBeispielen bezüglich ihrer Inkonsistenzklasse durchgeführt, siehe auch Tabelle6.3 für eine Zusammenfassung. Diese Einordnung dient als erste Richtlinie, dieentsprechend spezifischer Projektanforderungen angepasst werden muss.

• vorgabenbedingte Inkonsistenzenim Rahmen der Untersuchung in Kapitel 5 konnte festgestellt werden,dass selten eine hohe Anzahl an verständniserschwerenden vorgabenbe-dingten Inkonsistenzen vorkommt. Dies liegt daran, dass bei den Erstellernausreichende Konsistenzprüfungen durchgeführt wurden. Die Empfängererwarten, dass Beschreibungen keine solchen Inkonsistenzen enthalten(essential quality). Daher würden nicht tolerierbare vorgabenbedingte In-konsistenzen schnell von den Empfängern entdeckt werden. Man denke anein Diagramm, welches konsequent die meisten Vorgaben verletzt. Darinkönnte die Anordnung der Elemente so nachteilig sein, dass die Knotenund deren Verbindung nur durch erheblichen Zeitaufwand zu identifi-zieren sind. Da die Betrachter intuitiv das Aufwand/Nutzen-Kriteriumberücksichtigen, würden sie sich nach einer gewissen Zeit von dem Lesendes Diagramms abwenden. In einem solchen Fall ist die Erstellung desDiagramms in der Gesamtheit sinnlos, da es nicht gelesen und verstandenwird.

Beispiel für vorgabenbedingte Inkonsistenz:

122


Unvorteilhaftes Layout (aus [Yu, Mylopoulos 94]).

• ModellinkonsistenzenZu den interessantesten nicht tolerierbaren Inkonsistenzen gehören Mo-dellinkonsistenzen, die dem Aufwand/Nutzen-Kriterium nicht genügen.Diese Inkonsistenzen führen den Empfänger auf eine „falsche Fährte“ odervermitteln kein zusammenhängendes Ganzes. Sehr veraltete Beschreibun-gen können zu einem falschen Verständnis führen, das die weiterführendeArbeit nicht unterstützt. Das Verwenden von veralteten Beschreibungen istper Definition nicht unnütz, da sie die damals getroffenen Entscheidungenfesthalten. Falls eine Beschreibung die Arbeit aufgrund ihres veraltetenStandes nicht mehr unterstützen kann, sollte eine neue Beschreibungverwendet werden. Da die meisten schriftlichen Beschreibungen mit demDatum der Erstellung versehen sind, ist eine Bestimmung der Aktualitäteinfach. Sehr viele grundlegende Änderungen innerhalb einer kurzenZeitspanne sind unwahrscheinlich. Werden viele Modelle unabhängigvoneinander beschrieben, z.B. durch verschiedenen Gruppen von Erstel-lern bzw. in verschiedenen Dokumenten, sollte darauf geachtet werden,dass bestehende Zusammenhänge zwischen Modellen deutlich gemachtwerden. In der Untersuchung zur vorliegenden Arbeit konnte festgestelltwerden, dass Mitarbeiter eine sehr genaue Vorstellung von ihrem Teilgebiethaben, aber nur vage Vorstellungen von den anderen Teilbereichen undvon den Zusammenhängen der Teilbereiche untereinander. Um diesem Zu-stand entgegenzuwirken, wurden die Konzeptbeschreibungen angefertigt.Es gibt allerdings auch Teile von Systemen, deren Zweck darin besteht,unabhängig vom gegebenen System verwendbar zu sein. Nichtsdestotrotzsollte die spezielle Verwendung des Teilsystems innerhalb des Systemserläutert werden.

123


Beispiel für Modellinkonsistenz:

Client

User

User InterfaceSchnittstelle

(SOAP)

Schnittstelle

(http)

Datenmodell

Adressdienst

R

R

R

Bei diesem Diagramm sind einige Modellinkonsistenzen zu finden, diedas Verständnis unmöglich machen. Auch eine dazugehörige Beschreibungkönnte dieses Diagramm nicht mehr „retten“, wenn es nicht ein besseres,neues Modell beschreiben würde – ohne auf die Elemente und Terminologiedes im Diagram Dargestellten zurückzugreifen. Man kann nur mutmaßen,dass auf Adressen zurückgegriffen wird oder Adressen verwaltet werdensollen. Dies ist ein modifiziertes Beispiel aus Projekt 4, das im Rahmen derUntersuchung zur vorliegenden Arbeit (siehe Kapitel 5) durchgeführt wur-de. Beispiele für Modellinkonsistenzen:

– Aufgabe der „Schnittstellen“ völlig unklar. Sie werden anscheinendnur vom „User Interface“ verwendet, was nicht sinnvoll erscheint.

– Was mit „Datenmodell“ beabsichtigt ist, bleibt unklar (ist es ein Spei-cher, wenn ja für welche Daten?)

– Warum greifen sowohl das „User Interface“ als auch die restlichen„Schnittstellen“ und „Datenmodell“ auf den „Adressdienst“ zu?

Inkonsistenzklasse Relevanz KommentarvorgabenbedingteInkonsistenzen - selten, werden direkt aufgefunden,

wenn vorhanden

Modellinkonsistenzen +nicht tolerierbar, wenn nichtunmittelbar oder eindeutigauflösbar

Tabelle 6.3: Nicht tolerierbare Inkonsistenzen

124

6.2. Vorschlag für die Erstellung von Konzeptbeschreibungen

6.2 Vorschlag für die Erstellung von Konzeptbe-schreibungen

6.2.1 Erstellungs- und Evolutionsprozess

Zu den bestehenden Prozessen für die Erstellung und Evolution von Konzeptbe-schreibungen werden keine größeren Veränderungen vorgeschlagen. Es werdenvielmehr einzelne Punkte ausgewählt, die unter Berücksichtigung tolerierbarerInkonsistenzen weiter konkretisiert werden:

• Planungs- bzw. konstruktionsbegleitende Unterstützung durch Konzeptbe-schreibungen

• Diagrammzentriertheit mit stichwortartigen Beschreibungen

• Durchführung von Konsistenzprüfungen

• Strukturierung der Konzeptbeschreibung

Der hier vorgestellte Ansatz plädiert dafür, die Erstellung der Konzeptbeschrei-bung begleitend zur Planung bzw. Konstruktion eines Systems durchzuführen.Zwar können die Ergebnisse einer Analyse weitaus weniger Inkonsistenzen ent-halten (da nicht primär eine „Idee“ festgehalten wird, sondern das Ergebniseines ganzen Entwicklungsprozesses), aber die begleitende Erstellung mindertoder eliminiert den Bedarf einer nachgelagerten Analyse. Weiterhin visualisie-ren explizite Beschreibungen das Gedachte und helfen dadurch, Klarheit sowieein gemeinsames Verständnis während der Entwicklung zu schaffen. Damit kön-nen nicht tolerierbare Modellinkonsistenzen bereits in frühen Phasen identifiziertwerden. Auch bei Analysen von Systemen wird für eine begleitende Beschrei-bung votiert. Die Empfänger wollen sich in der Regel schnell Wissen über daszu analysierende System aneignen, um z.B. den Einsatz des Systems im Rahmeneines anderen Systems bestimmen zu können.

Eine begleitende Beschreibung kann nur vorgenommen werden, wenn der Auf-wand dafür nicht unverhältnismäßig wird. Denn im Laufe einer Entwicklungoder Analyse können sich die dazugehörigen Modelle rasch ändern. Um dieszu erreichen, sollen Diagramme im Zentrum der Dokumentation stehen. Der Vorteilliegt in einer schnellen und einfachen Darstellung der Zwischenergebnisse, diedennoch umfangreiche Aussagen erlaubt. Häufig wird der zeitliche Aufwand fürdie Erstellung von Dokumenten angeführt, um die Abwesenheit von Konzeptbe-schreibungen zu erklären. Der Gewinn durch ein klares und geteiltes Verständnisbei den Beteiligten durch Konzeptbeschreibungen rechtfertigt diesen Aufwandjedoch. Dennoch reichen Diagramme alleine nicht aus und müssen mit fehlendenInformationen ergänzt werden. Deshalb sollten stichwortartige textuelle Beschrei-bungen die Diagramme begleiten. Dies minimiert im Gegensatz zu herkömmli-chen Beschreibungen den Aufwand. Dies entspricht dem ohnehin praktizierten

125


Kunden Interessenten

Travel organizationReiseunternehmen

Reserv-

ierungen

Kunden-

datenReisedaten

Reisebüro

Reservierungssystem Informationsystem

R Reise buchen,

Tickets abholen

Rinformieren

Übersicht Reisebürosystem mit Umgebung:

Kunden

Reisebuchungen übermittelt

an Reiseunternehmen

dann Austellung Tickets

Interessenten

Zugriff auf Reisedaten über

Informationssystem

Reiseunternhemen stellen

Reisedaten bereit

Bild 6.2: Beispiel für stichwortartige Beschreibung eines Diagramms

Vorgehen, wie es die Untersuchung in dieser Arbeit gezeigt hat. Häufig existie-ren in größeren Unternehmen hauptsächlich Präsentationen, die keine ausführ-licheren textuellen Beschreibungen enthalten. Die Diagrammzentriertheit ist alsoein unterscheidendes Merkmal zu anderen Ansätzen, die ausführliche Beschrei-bungen fordern. Prinzipiell kann mehr Aufwand in eine Konzeptbeschreibunginvestiert werden, je mehr potentielle Empfänger existieren. Sollte eine ausfor-mulierte Dokumentation angestrebt werden, genügt es im Anschluss die stich-wortartigen Beschreibungen auszuformulieren, um eine wohlstrukturierte undinhaltlich geschlossene Dokumentation zu erhalten. Es ist nicht unbedingt not-wendig, schriftliche Konzeptbeschreibungen zu erstellen, es kann durchaus sinn-voll sein Aufnahmen von bereits durchgeführten Präsentationen bereitzustellen,um weiteren Aufwand zu vermeiden. Bild 6.2 zeigt ein Beispiel für eine stich-wortartige Beschreibung eines Diagramms.

Aus dem oben beschriebenen Vorgehen und den Ergebnissen der Untersuchun-gen, die der vorliegenden Arbeit zugrunde liegen, ergeben sich die Art und Rei-henfolge der Konsistenzprüfungen. Kapitel 6.3 beschreibt folgende Punkte für dieDurchführung von Konsistenzprüfungen ausführlicher:

• Festlegung der Bedeutsamkeit von Inkonsistenzen

• Durchführung von Konsistenzprüfungen in umgekehrter Reihenfolge derBedeutsamkeit der Inkonsistenzklassen

• Abstimmung der Häufigkeit der Konsistenzprüfungen auf Bedeutsamkeitder Inkonsistenzklassen

126


• Zeitpunkt der Konsistenzprüfungen

Die Strukturierung von Dokumenten wird erst im Anschluss durchgeführt. Eineerste Version der Dokumentation lässt sich aufgrund der bisher geleisteten Mo-dellierungsarbeit leicht realisieren. Aus den Erfahrungen bei der Untersuchungund anderen Projekten kann gefolgert werden, dass ein Verantwortlicher für dieDokumentation im Sinne einer einheitlichen Strukturierung und Ablage der Do-kumente hilfreich ist. Folgende Punkte werden in Kapitel 6.2.2 weiter erörtert:

• Struktur der Dokumentation an der Modellhierarchie angelehnt

• Ableitung der Inhalte aus den Modellen

• Aufteilung auf mehrere Dokumente

Für die Evolution von Dokumenten, also die Pflege und Anpassung an neue Ge-gebenheiten des Systems, sollten zunächst die Änderungen überprüft werden.Da auch während der Evolution des Systems die Erstellung der Beschreibung,wie oben aufgeführt, begleitend stattfinden sollte, sind Änderungen frühzeitigbekannt und dokumentiert. Es sollte bei den Änderungen vor allem nach exter-nen Modellinkonsistenzen gesucht werden. Vernachlässigt man die Erstellungeiner ausführlich formulierten Beschreibung, ist dieser Schritt völlig transparent.Der Bedarf einer ausführlich formulierten Beschreibung sollte deswegen explizitfestgestellt werden.

Zusammenfassend sind die wichtigsten Schritte für die Erstellung/Evolutionund Konsistenzprüfungen nachfolgend aufgeführt:

1. Entscheidung über Erstellung der Konzeptbeschreibung

2. Vorbereitungen der Konsistenzprüfung

(a) Festlegung der Bedeutsamkeit von Inkonsistenzen

(b) Festlegen der Häufigkeit der Konsistenzprüfungen (Bedeutsamkeit be-rücksichtigen)

(c) Festlegen der Zeitpunkte der Konsistenzprüfungen (Bedeutsamkeitberücksichtigen)

3. Diagramme begleitend erstellen und Prüfung auf bedeutsame Inkonsisten-zen (iterativ)

(a) während Planungs/Konstruktionsbesprechungen

i. Diagramme begleitend erstellenii. Prüfung auf bedeutsame Inkonsistenzen

(b) im Anschluss

i. Ausarbeitung der Beschreibung und Diagramme in elektronischerForm

127


ii. Prüfung auf bedeutsame Inkonsistenzen und Formulierung vonFragen

iii. Bereitstellung an Beteiligte der Planung/Konstruktion

4. Erstellung der abschliessenden Konzeptbeschreibung

(a) Struktur der Dokumentation angelehnt an die Modellhierarchie

(b) Ableitung der Inhalte aus den Modellen

(c) Aufteilung auf mehrere Dokumente, falls nötig

5. Überprüfung unbedeutsamer Inkonsistenzen

6. Vorstellung der Ergebnisse vor einem größeren Empfängerkreis

7. Evolution

(a) Änderungen an Diagrammen bzw. neue Diagramme begleitendenddurchführen

(b) Überprüfung der Änderungen und Einordnung der Relevanz dermöglichen Inkonsistenzen

(c) sonst gleiches Vorgehen wie zuvor

6.2.2 Strukturierung und Inhalte von Konzeptbeschreibungen

Struktur und Inhalte von Konzeptbeschreibungen richten sich in erster Linie nachder Modellhierarchie und den Modellen, die maßgeblich vom Modellierungsan-satz bestimmt werden. Übergeordnete und zusätzliche Punkte ergeben sich meistaus den Vorgaben zur Dokumentation und zu der gewählten Notation. Bild 6.3zeigt ein an den Projekten der im Rahmen dieser Arbeit durchgeführten Untersu-chung angelehntes Beispiel einer Modellhierarchie und die dazu gewählte Auf-teilung auf Dokumente sowie ein Inhaltsverzeichnis eines Dokuments.

Da existierende Beschreibungen meist in Form von Präsentationen festgehaltenwerden und für den internen Empfängerkreis bestimmt sind, wird vorgeschla-gen die Konzeptbeschreibungen stichwortartig anzufertigen. Im Zentrum derBeschreibungen sollten die entsprechenden Diagramme in der Notation des ge-wählten Modellierungsansatzes stehen. Auf eine stichwortartige Beschreibungder einzelnen Diagrammelemente, ähnlich einem Glossar, kann verzichtet wer-den. Vielmehr sollten, gemäß des Aufwand/Nutzen-Kriteriums, die Zusammen-hänge zwischen den Elementen und die Gründe für die technischen Entschei-dungen hervorgehoben werden. Beispielsweise sollte ein FMC-Aufbaudiagrammanhand eines Ablaufs beschrieben werden, worin die Akteure und Speicher ent-sprechend sukzessive vorgestellt werden. Dies hat den Vorteil einer schnellerenErstellung und Anpassung der stichwortartigen Beschreibung, vorausgesetzt dieDiagramme existieren bereits.

128


Übersicht mit Umgebung(1 Diagramm)

Verfeinerung

GrobeÜbersicht(2 Diagamme)

Kommunikations-Möglichkeiten(2 Diagramme)

BEW*

: Modell

: Betrachtungsebenenwechsel

Legende:

: Intermodellbeziehungen

Verfeinerung

Detaillierte Übersicht(1 Diagramm)

AV*

Komponente A(2 Diagramme)

Verfeinerung

DetaillierteKomponente A(1 Diagramm)

Komponente B(2 Diagramme)

AV*

Komponente C(1 Diagramm)

AV*

Komponente C1(2 Diagramme)

AV*

Komponente C2(2 Diagramme)

Verfeinerung

Detaillierte Kompontente C2

(9 Diagramme)

Verfeinerung

Komponente C2.1(4 Diagramme)

AV*

BEW*

Ereignis-behandlung(7 Diagramme)

AV*

Komponente D(2 Diagramme)

Verfeinerung

Detaillierte Komponente D1(10 Diagramme)

BEW*

AV* : Ausschnitt + Verfeinerung

in jedem Dokumentzur Einordnung enthalten

: Dokument

Inhaltverzeichnis (für Komponente D)

1 Einleitung2 Komponente D2.1 Systemumgebung (1 Diagramm)2.2 Komponentenbeschreibung2.2.1 Ziele2.2.2 Aufbaustruktur (1 Diagramm)2.2.3 Ablaufstruktur (1 Diagramm)2.2.4 Wertebereichsstruktur (Verweis auf 1 Diagramm)2.3 Detaillierte Komponentenbeschreibung2.3.1 Aufbaustruktur (1 Diagramm)2.3.2 Ablaufstruktur (9 Diagramme)2.3.4 Wertebereichsstruktur (1 Tabelle)

Bild 6.3: Beispiel Struktur und Inhalte anhand einer Modellhierarchie

Es ist in den meisten Fällen sinnvoll, die Konzeptbeschreibung auf mehrere Do-kumente aufzuteilen, z.B. um die Erstellung durch unterschiedliche Gruppen zuermöglichen und zu koordinieren. Hierbei sollten die gleichen Prinzipien wiebei der Modularisierung von Quelltext angewandt werden: Kohäsion und Kopp-lung. Die Kohäsion innerhalb eines Dokuments sollte hoch sein und die Kopp-lung zwischen den Dokumenten schwach. Um dies zu erreichen sollten die Do-kumente entsprechend der Modellhierarchie aufgeteilt sein. Ein zusätzliches Do-kument als „Metadokument“ könnte eine einführende Übersicht über die Model-le bieten. Primär sollte dort die Modellhierarchie erläutert werden, was letztlichden verfügbaren Dokumenten mit einer knappen Zusammenfassung entspricht.Die Aufgabe der Einführung muss realistisch gesehen von einem eingearbeitetenMitarbeiter durchgeführt werden, da schon das Wissen um die Existenz solcherDokumentationen und die Ablageorte sowie der Zugriff darauf bei einem neuenMitarbeiter nicht vorausgesetzt werden kann.

Hilfreich für das korrekte Verständnis der Beschreibung ist neben der Bestäti-gung von bereits angeeigneten richtigen Annahmen auch die Widerlegung vonfalschen Annahmen. So ist die Aussage, dass ein Domain Name System37 bei un-terschiedlichen Anfragen immer die gleiche IP-Adresse zurückliefert, zunächstunerwartet. Jeder Leser, der diese spezielle Nutzung innerhalb des betrachtetenSystems nicht kennt, würde nach dem Grund dafür fragen, da er eine Modellin-konsistenz vermuten würde. Um die Zusammenhänge zwischen der (abstrakten)Konzeptbeschreibung und weiteren detaillierten Beschreibungen zu verdeutli-

37Domain Name Systeme haben im Internet die Aufgabe zu einem Domänennamen, wie z.B.example.com, eine IP-Adresse (zur Identifizierung eines Rechners) zuzuordnen.

129


Modell ModellhierarchieStruktur

Aufteilung auf Dokumente(Kohäsion und Kopplung) X X

„Metadokument“ Xknappe Struktur (z.B. kein Glossar,

Index) X

InhaltDiagrammzentriertheit Xknappe Beschreibung X

Tabelle 6.4: Einfluss von Modellen und Modellhierarchie auf Struktur und Inhaltevon Konzeptbeschreibungen

chen bzw. zu ermöglichen, sollte eine Konzeptbeschreibung soweit wie möglichkonkretisiert werden. Denn es widerspricht dem Aufwand/Nutzen-Kriterium,wenn zwar das Konzept verstanden wurde, aber eine praktische Nutzung nichtmöglich ist, da alle anderen Beteiligten andere Begriffe nutzen oder die ange-eigneten Modelle nicht auf die konkreten Systemteile bzw. Quelltexte abgebildetwerden können. Ein einfaches Mittel eine Beschreibung zu konkretisieren, ist esdie geläufigen Begriffe und Bezeichner zu verwenden.

Tabelle 6.4 zeigt den Haupteinfluss von Modellen und Modellhierarchie aufStruktur und Inhalte von Dokumenten in einer Übersicht.

6.2.3 Werkzeugunterstützung

In Bezug auf tolerierbare Inkonsistenzen sind maschinengestütze Werkzeuge we-nig relevant, da das Hauptaugenmerk auf Modellinkonsistenzen liegt. Für dasAuffinden und Korrigieren vorgabenbedingter Inkonsistenzen wie z.B. notatio-neller Inkonsistenzen sind herkömmliche maschinengestützte Werkzeuge, wiez.B. Rechtschreibprüfungen von Textverarbeitungssystemen, ausreichend. Den-noch können einige Anmerkungen zu Werkzeugen im Allgemeinen gemachtwerden.

Vorteilhaft wäre ein Dokumentationssystem, das den Lesern und Erstellern er-laubt Änderungen und Anmerkungen auf einfache Art und Weise anzubringen.Bei unbedeutenderen Inkonsistenzen sind Korrekturen in der Regel – aufgrunddes geringen Aufwands – schnell vorzunehmen. Man denke an ein System ähn-lich einem Wiki-System38. Anstatt unbedeutende Inkonsistenzen nicht zu mel-den, könnte der Leser sie direkt beheben. Für bedeutendere Inkonsistenzen könn-te der Leser, der diese Inkonsistenz entdeckt hat, eine für alle ersichtliche An-merkung anbringen. Andere Leser könnten durch solche Hinweise auf Inkon-sistenzen, ggf. mit Beschreibungen von Korrekturen, die Bedeutsamkeit für die

38Wiki-Systeme erlauben es, Änderungen an Webseiten online innerhalb der Webseiten selbstdurchzuführen. Das Wort„Wiki“ entspricht dem hawaiischen Begriff wiki, das schnell bedeutet.

130

6.3. Vorschlag für die Durchführung von Konsistenzprüfungen

persönlichen Zwecke ableiten. Weiterhin würden Mehrfachmeldungen unterblei-ben. Eine weitere interessante Eigenschaft eines Werkzeugs wäre die Möglichkeit,auf einfache Art und Weise Änderungen an den Dokumenten hervorzuheben.Dadurch könnten sich die Leser, die bereits eine ältere Version des Dokumentskennen, auf die Neuigkeiten konzentrieren. Die Dokumente müssten dann vondiesen Personen nicht mehr vollständig gelesen werden. Kein technisches Sys-tem sollte bei der Entdeckung von Inkonsistenzen völlig automatisch Korrektu-ren durchführen oder die Sicherung bzw. Weiterverarbeitung unterbinden. Beiden Eingaben könnte es sich um noch nicht fertige Eingaben handeln oder auchum Eingaben, die das System nicht überprüfen kann.

Wesentliche Hilfsmittel für die Erstellung und Änderung von schriftlichen Be-schreibungen sind nicht maschinengestützt. Das wichtigste Hilfsmittel ist sicher-lich die passende Wahl des Modellierungsansatzes. Er bestimmt maßgeblich dieInhalte, deren Qualität und Strukturierung. Es kann daher durchaus sinnvollsein, mehrere Modellierungsansätze zu verwenden, da sie unterschiedliche Stär-ken und Schwächen haben. So wurden in den untersuchten Projekten teilwei-se FMC und UML basierte Diagramme für unterschiedliche Zwecke verwendet.FMC basierte Diagramme fanden für die Konzeptbeschreibung Anwendung, hin-gegen wurden UML basierte Diagramme für Designbeschreibungen verwendet.Dies entspricht der allgemeinen Wahrnehmung, dass UML basierte Diagrammehauptsächlich für detailliertere Designbeschreibungen verwendet werden. AlleModellierungsansätze besitzen eine Notation und einer Menge von Richtlinienbzw. Regeln. Sie sollen die Erstellung von Beschreibungen unterstützen. Darauslassen sich Checklisten ableiten, mit deren Hilfe sich die wichtigsten Inkonsisten-zen in Bezug auf den Modellierungsansatz finden lassen. Automatisierbare Teilesolcher Vorgaben, sollten in entsprechende maschinengestützte Werkzeuge ein-gebaut werden. Bild 6.4 zeigt ein Beispiel für die automatische Konsistenzprü-fung von FMC Diagrammen, wobei zwischen syntaktischen Fehlern (rote Far-be) und möglichen semantischen Fehlern (orange Farbe) unterschieden wird. DieChecklisten sollten vor allem das Auffinden von Modellinkonsistenzen unterstüt-zen.

6.3 Vorschlag für die Durchführung von Konsistenz-prüfungen

Vor Beginn der Konsistenzprüfungen sollten idealerweise einige Vorbereitungengetroffen werden. Diese Vorbereitungen sollen unnötigen Aufwand verhindernund zu einer klaren Gewichtung, mit Schwerpunkt auf den bedeutsamen Inkon-sistenzen, führen. Dazu sollten die folgenden Punkte berücksichtigt werden:

• Gewichtung der Inkonsistenzen festlegenDie Kriterien für bedeutsame bzw. unbedeutsame Inkonsistenzen solltendefiniert werden. Eine einfache Tabelle sollte für diese Zwecke völlig aus-reichend sein, für ein Beispiel siehe Tabelle 6.5. Abhängig von der System-

131


Automatisierte Konsistenzprüfung für FMC Aufbaudiagramme:

Automatisierte Konsistenzprüfung für FMC Ablaufdiagramme:

Bild 6.4: Beispiel einer automatischen Konsistenzprüfung (vorgabenbedingte In-konsistenzen)

klasse und der Domäne können konkrete Kriterien für bestimmte bedeut-same Inkonsistenzen, vorwiegend Modellinkonsistenzen, erst nach einigenDurchläufen bestimmt werden.

• Reihenfolge der KonsistenzprüfungenEs sollte die umgekehrte Reihenfolge der Bedeutsamkeit der Inkonsistenz-klassen gewählt werden, siehe auch Tabelle 6.5. D.h. zunächst sollten dieModelle ausgereift sein, bevor auf unbedeutende Inkonsistenzen, wie z.B.notationelle Inkonsistenzen, hin untersucht wird. Die Diagrammzentriert-heit ermöglicht es, zunächst auf die Inhalte zu fokussieren und diese zuüberprüfen. Die Ersteller bemerken Modellinkonsistenzen bereits bei derErstellung der Diagramme und der stichwortartigen Beschreibungen. Wei-terhin wird durch diese Art der Beschreibung Anderen eine Prüfung aufModellinkonsistenzen vereinfacht, da sich die Empfänger auf die Inhaltekonzentrieren müssen. Der Aufwand für die Durchführung von Konsis-tenzprüfungen bezüglich unbedeutender Inkonsistenzen wird daher ein-geschränkt und in die Endphase der Erstellung verschoben.

• Häufigkeit der KonsistenzprüfungenEs sollte ebenfalls festgelegt werden, wie häufig welche Mitarbeiter welcheKonsistenzprüfungen durchführen sollen. Nach bedeutsamen Inkonsisten-zen sollte während der Erstellung relativ häufig gesucht werden. Im Ide-alfall werden Konsistenzprüfungen, normalerweise auf interne Modellin-konsistenzen, begleitend während der Erstellung der Diagramme durchge-

132


führt. Anschliessend sollten die Diagramme auf bedeutsame Inkonsisten-zen, normalerweise auf externe Modellinkonsistenzen, untereinander über-prüft werden. Überprüfungen auf unwichtige Inkonsistenzen können ab-schliessend einmalig durchgeführt werden. Tabelle 6.5 zeigt beispielhaftvorbereitende Maßnahmen.

Inkonsistenz GEm* GEr* Prüfungen

syntaktische 0 2durch (nur) Ersteller#Prüfungen 1Zeitpunkt abschliessend

semantische 1 4durch Projektmanagement#Prüfungen 1Zeitpunkt abschliessend

sonstigevorgaben-bedingte

1 5durch Projektmanagement#Prüfungen 1Zeitpunkt abschliessend

interneModellin-konsistenz

4 10

durch Entwicklung (z.B. Architekt,Entwickler)

#Prüfungen ≥ 2, pro KomponenteZeitpunkt begleitend

externeModellin-konsistenz

8 9

durch Entwicklung (z.B. Architekt,Entwickler)

#Prüfungen 1≥ 2, pro KomponenteZeitpunkt begleitend

GEm* : Gewichtung bei EmpfängerGEr* : Gewichtung bei Ersteller

Tabelle 6.5: Beispiel für Gewichtung von Inkonsistenzen mit verantwortlichenKonsistenzprüfern

Konsistenzprüfungen werden von den Erstellern und den Empfängern durchge-führt. Die Ersteller befassen sich während der Erstellung meist länger und inten-siver mit der Gesamtheit der Modelle als die Mehrheit der Empfänger, die sichmeistens – bedingt durch ihre Tätigkeit – ausgewählten Teilen besonders intensivwidmen.

6.3.1 Konsistenzprüfung durch Ersteller

Die Ersteller sollten nach Abschluss der Erstellung der Diagramme und Überprü-fung auf bedeutsame Inkonsistenzen auch die Überprüfung auf unbedeutsameInkonsistenzen vornehmen, wenn möglich mit Hilfe maschinengestützer Werk-zeuge. Zur effizienten Überprüfung auf vorgabenbedingte sowie semantische In-konsistenzen können zuvor angefertigte Checklisten verwendet werden (siehe

133


Bild 6.5 für ein Beispiel einer Checkliste für FMC Aufbaudiagramme). Diese ha-ben den Vorteil wiederverwendbar zu sein, so dass der Aufwand dafür gerecht-fertigt erscheint. Eine einmalige Überprüfung der unbedeutenden Inkonsisten-zen, falls dies zu Beginn als nötig definiert wurde, sollte in der Regel ausreichen.

Während der Erstellung der Konzeptbeschreibung sollte der Schwerpunkt derKonsistenzprüfungen auf den bedeutsamen Inkonsistenzen liegen. Im Normal-fall sind dies interne und externe Modellinkonsistenzen. Dazu sollte schon in derPhase der Informationsbeschaffung bzw. Modellierung auf bedeutsame Inkon-sistenzen hin überprüft werden.

• Konsistenzprüfungen bei AnalyseTreffen mit den Interviewpartnern sollten in Form von semi-strukturiertenInterviews vorbereitet werden. Dazu sollten Fragenkataloge, die auf Ba-sis des bereits erlangten Wissens erstellt wurden, verwendet werden. Da-durch wird eine intensive Auseinandersetzung mit der Thematik erreichtund Modellinkonsistenzen können aufgedeckt werden. Weiterhin könnenAusführungen des Interviewpartners besser verfolgt und eingeordnet wer-den. Es sollten ebenfalls Aufzeichnungen, z.B Ton- und Bildaufzeichnun-gen oder Mitschriften, während der Interviews getätigt werden. Es solltenzusammen mit dem Interviewpartner während des Interviews Diagrammeerstellt werden, die die Inhalte des Interviews wiedergeben. Im Anschlusssollten die Ersteller die Aufzeichnungen und die erstellten Diagramme stu-dieren und darauf aufbauend einen neuen Fragenkatalog erstellen. Es isthilfreich zum gleichen Thema unterschiedliche Personen zu interviewen,da die Konzepte unterschiedlich beschrieben und betrachtet werden. Mög-liche Lücken oder Inkonsistenzen können dadurch einfacher identifiziertwerden. Es sollte vermieden werden, unterschiedliche Personen mit demgleichen Fragenkatalog zu befragen. Vielmehr sollten die jeweilig aktuellenFragenkataloge verwendet werden, um die Anzahl der Interviews zu mi-nimieren und die Modellkonsistenzprüfung zu optimieren. Eine Liste derdurchgeführten Interviews mit den jeweiligen Interviewpartnern hilft häu-fige Mehrfachbefragungen zu vermeiden. Sind Dokumente vorhanden, sosollten begleitend Diagramme skizziert werden. Dies hilft, die Aussagenzu bündeln und zu beurteilen. Es ist ebenfalls sinnvoll die entsprechen-den Passagen in den Dokumenten, aus denen wesentliche Strukturen derDiagramme ermittelt werden konnten, zu markieren. Dadurch können diebesagten Stellen schneller wiedergefunden werden. Darauf aufbauend kön-nen Fragenkataloge erstellt und mit den Experten besprochen werden. Ste-hen zeitweise keine Experten zur Verfügung, kann bei einer Analyse auchder Quelltext herangezogen werden. Durch den bereits angefertigten Fra-genkatalog wird die Suche im Quelltext zielgerichteter. Auch hier solltendie Stellen markiert werden, die Hypothesen bestätigen oder widerlegen.

• Konsistenzprüfungen bei Planung/KonstruktionIdealerweise gibt es während der Planung/Konstruktion eines Systems Ver-antwortliche, die für die Erstellung der Diagramme zuständig sind. Die er-

134


stellten Diagramm sollten als Grundlage der Diskussion dienen, die wei-ter besprochen werden. Dadurch sollten bedeutsame Modellinkonsisten-zen zwischen den Vorstellungen der Beteiligten schon während der Be-sprechungen identifiziert werden können. Dafür sollten die Diagramme al-len Beteiligten sichtbar gemacht werden, beispielsweise an Flipcharts oderdurch Projektion. Der Verantwortliche sollte nach den Besprechungen dieDiagramme, wenn nötig, in elektronische Form bringen und mit stichwort-artigen Beschreibungen versehen. Dabei kann er interne und externe Mo-dellinkonsistenzen feststellen. Auch hierbei sollte der Verantwortliche (Er-steller) Checklisten zur Unterstützung verwenden, siehe Bild 6.5 für einBeispiel. Diese sollten dann den übrigen Beteiligten zur Verfügung gestelltwerden, die dann ebenfalls auf Modellinkonsistenzen überprüfen können.Fallen dem Ersteller bereits Modellinkonsistenzen auf, kann er die dazu-gehörigen Fragen ebenfalls stichwortartig festhalten. Bei den folgendenBesprechungen sollte dann kurz auf die gefundenen Modellinkonsisten-zen eingegangen werden und deren Relevanz bestimmt werden. Für be-deutsame Modellinkonsistenzen sollte nach Lösungsmöglichkeiten gesuchtwerden.Unter Umständen kann eine Auflösung einer Modellinkonsistenzdurch Machbarkeitsstudien (z.B. durch Prototypen) bestimmt werden.

Nach der Erstellung der Diagramme und ihrer Überprüfung sollte die stichwort-artige Beschreibung ebenfalls abgeschlossen sein. Erst danach ist es im Rahmender Konsistenzprüfung sinnvoll, die Ergebnisse einem größeren Kreis, der dieExperten und andere Verantwortliche umfasst, zu präsentieren. Die Anzahl derPräsentationen hängt vom Umfang der Ergebnisse und der Verfügbarkeit der Ex-perten ab. Eine zu häufige Durchführung von Präsentationen ist im Rahmen derKonsistenzprüfung nicht zweckmäßig, da – wie die Untersuchung gezeigt hat –eine hohe Frequenz von Präsentationen keinen erheblichen Einfluss auf die An-zahl der gefundenen Inkonsistenzen hat, sondern vielmehr der Überprüfung desProjektfortschritts dient.

6.3.2 Konsistenzprüfung durch Empfänger

Die Empfänger sollten auf die Überprüfung unbedeutsamer Inkonsistenzen, wiez.B. vorgabenbedingte und speziell notationelle Inkonsistenzen, verzichten. Dieunbedeutsamen Inkonsistenzen können toleriert werden, da sie das Verständnisnicht behindern. Aufgrund des vorgeschlagenen Vorgehens zur Erstellung vonKonzeptbeschreibungen mittels Diagrammen und stichwortartigen Beschreibun-gen, sind beim Lesen besondere Techniken gefragt. Zunächst sollte jedem Leserbewusst sein, dass in der Beschreibung Inkonsistenzen jeder Art enthalten seinkönnen. Standardmäßig sollte der Stand des zu lesenden Dokuments geprüftwerden. Daraus lassen sich schon erste, die Konsistenz betreffende Schlüsse zie-hen. Da hauptsächlich Diagramme zur Darstellung von Konzepten und zugehö-rige stichwortartige Beschreibungen verwendet werden, sollte eine horizontaleLesetechnik mit nebenläufigem Lesen der Diagramme verwendet werden. Dies

135


Checkliste für FMC Aufbaudiagramm

! Notation

" Bipartitheit eingehalten

" Akteure rechteckig?

" Speicher/Kanäle abgerundet?

" Zugriffe # Lesen/Schreiben (gerichtete Kante) # Modifizieren (ungerichtete Kante bzw. Kanten in beiden Richtungen)

" Rechtschreibfehler korrigiert

" Erzeugung/Löschung von Akteuren # Durch modifizierenden Zugriff auf Speicher (Strukturvarianz)

" Kommunikation # Wenn flüchtig Akteure durch Kanal verbunden? # sonst Akteure mit Speicher verbunden?

! Layout und Gestaltung

" Allgemeine Richtlinien # Nicht zu viele Elemente # Farben sparsam verwenden und mit Bedeutung verknüpfen # Unterschiedliche Zeichensätze vermeiden und mit Bedeutung verknüpfen # harmonisches Gesamtbild, z.B. durch Symmetrien und Ausrichtung

" Größe und Form Diagrammelemente # Größe sollte mit Wichtigkeit korrelieren (großes Element = wichtig) # Die Größen der einzelnen Elemente sollten aufeinander abgestimmt werden.

Eine zu große Vielfältigkeit erschwert die Wahrnehmung.

" Anordnung Diagrammelemente # Anordnung der Elemente richtet sich nach Wichtigkeit und

Zusammengehörigkeit (z.B. auch nach Ablauf, „zentrale“ Elemente auch im optisch im Mittelpunkt)

" Lesbarkeit # Anordnung der Elemente (z.B. Clients oben, Datenbanken unten) # Überkreuzungen von Kanten minimieren # Abgerundete Kanten

(a) Auszug - Seite 1

! Inhalt

" Beschriftungen Diagrammelemente # Akteure als (aktive) Nomen, woraus Aufgabe hervorgeht # Speicher als (passive) Nomen, woraus Inhalte hervorgehen # Kanäle mit relevanten Informationen # Sind alle Knoten sinnvoll beschriftet?

" Elemente auf gleicher Abstraktionsebene # sind zwischen allen Elemente sinnvolle Zusammenhänge vorhanden? # sind alle relevanten Elemente zur plausiblen Erklärung vorhanden?

" Gruppierungen # bei Verfeinerung: entspricht der Name des Elements im neuen Diagramm dem

Namen des zu verfeinernden Elements? # Zweck der Gruppierung:

• zeigt Hardwaregrenze, oder • fasst Elemente zusammen, um Kanten zu reduzieren, oder • fasst inhaltlich zusammenhängende Elemente zusammen?

" Aufrufrichtungen kontrollieren

" Kann relevanter Ablauf für gezeigten Ausschnitt mit den Elementen und deren Beziehungen erklärt werden?

! Begleittext

" Verwendung derselben Begriffe wie im Diagramm

" Begleittext enthält erläuternde und zusätzliche Information, nicht das Diagramm in Textform wiederholen

" Stimmt die Beschreibung mit dem Dargestellten überein?

! Abstimmung mit anderen Diagrammen

" Mehrere Diagramme und Beschreibungen # Ergänzen sich die Diagramme? # Stimmen Benennung der Elemente überein? # Können die Diagramme einfach einander zugeordnet werden? # Fehlen Diagramme zum Verständnis? # Bei verfeinernden Diagrammen: gleiches Layout , wie das Ursprüngliche?

" Fehlende Elemente # In anderen Diagrammtypen relevante Elemente, die keine Korrespondenz

haben? • Bsp.: am Ablauf beteiligte Akteure im Aufbau wieder zu finden?

" Modellzusammenhänge zwischen verschiedenen Diagrammen prüfen # Horizontal: Sich ergänzende Diagramme anderer Typen des gleichen Modells

mit gleichem Abstraktionsgrad verwenden # Vertikal: zu Diagrammen gleichen Typs höherer und niedriger

Abstraktionsebene

(b) Auszug - Seite 2

Bild 6.5: Beispiel einer Checkliste für FMC Aufbaudiagramme

dient vor allem dazu, die Zusammenhänge zu erkennen. Für die gewählten Mo-dellierungsansätze können dafür die entsprechenden Checklisten ausgearbeitetund angewendet werden, siehe Bild 6.5 (b) für ein Beispiel. Es ist davon aus-zugehen, dass Empfänger sich eher nicht in der Rolle der Konsistenzprüfer se-hen. Durch die angesprochene Lesetechnik lassen sich aber generell interne undexterne Modellinkonsistenzen identifizieren. Sind die Inhalte dem Leser bereitsbekannt, kann eine vorangegangene Ausarbeitung bzw. explizite Zusammenstel-lung von Modellen und deren Beziehungen helfen, Modellinkonsistenzen undUnvollständigkeiten zu identifizieren.

Es steht dem Empfänger normalerweise frei, Inkonsistenzen zu melden. Idealer-weise sollte das Melden und ggf. die Korrektur von Inkonsistenzen durch geeig-nete Werkzeuge möglichst einfach und ohne administrative Hindernisse möglichsein.

136

Kapitel 7

Fazit und Ausblick

In allen technischen Beschreibungen zu komplexen informationellen Systemenlassen sich Inkonsistenzen finden. Für die Mitarbeiter scheint diese Tatsache inder Regel kein größeres Problem darzustellen. Die theoretische Forderung nachvölliger Konsistenz ist mit der Praxis nicht in Einklang zu bringen. Sie würdejeglichen realistischen Zeit- und Budgetrahmen üblicher praxisbezogener Projek-te deutlich überschreiten.

Die im Rahmen dieser Arbeit durchgeführte Untersuchung zeigt, dass in derPraxis, im Gegensatz zur theoretischen Forderung, Inkonsistenzen bewusst tole-riert werden. Allerdings findet kein geplantes Vorgehen zur Konsistenzprüfungbei Konzeptbeschreibungen statt. Die Beschreibungen werden Plausibilitätsüber-prüfungen und Vergleichen mit bereits Bekanntem unterzogen. Das Hauptau-genmerk liegt dabei auf Modellinkonsistenzen. Andere Inkonsistenzen werdenkaum berücksichtigt. Alle Beteiligten sind bemüht, bei der Behebung der so auf-gedeckten Inkonsistenzen unterstützend mitzuwirken. Vor der Behebung der In-konsistenzen wird überprüft, ob eine Behebung sinnvoll ist. Ist der Aufwand fürdie Änderung im Verhältnis zum Nutzen der Änderung zu hoch, bleibt die Inkon-sistenz bestehen. Die Untersuchung hat gezeigt, dass sich notationelle Inkonsis-tenzen sehr schnell und einfach beheben lassen. Hingegen können andere vorga-benbedingte Inkonsistenzen einen hohen Zeitaufwand erfordern, obwohl derenWichtigkeit eher als gering eingestuft wird. Vergleichbares gilt für Modellinkon-sistenzen. Der Aufwand für ihre Behebung variiert ebenfalls.

Aus den Ergebnissen der Untersuchungen wurde ein Ansatz erarbeitet, der sichvor allem an dem Aufwand/Nutzen-Kriterium orientiert. Daraus lässt sich einKriterium für den Inhalt von Konzeptbeschreibungen ableiten. Dies gibt Anhalts-punkte, welche Inhalte sich in der Konzeptbeschreibungen wiederfinden lassen,und ob sie nach Änderungen des Systems ebenfalls geändert werden müssenoder nicht. Dieses Kriterium stellt den benötigten Aufwand für das Erlangender Informationen ohne Konzeptbeschreibung (Aufwandohne KB) in Zusammen-hang zu dem benötigten Aufwand für das Erlangen der Informationen durchdas Lesen der Konzeptbeschreibung (Aufwandmit KB). Erst wenn Aufwandohne KBsehr viel höher ist als Aufwandmit KB, sollte die entsprechende Information fürdie Konzeptbeschreibung berücksichtigt werden. Dadurch sollten vor allem die

137

Kapitel 7. Fazit und Ausblick

Zusammenhänge, also die übergeordneten Modelle, in Konzeptbeschreibungenbeschrieben werden. Um den Bedarf der Konsistenzhaltung zu ermitteln, solltedieses Kriterium auf Änderungen von Konzeptbeschreibungen angewendet wer-den. Dadurch lässt sich ermitteln, welche Änderungen tatsächlich eingepflegtwerden müssen. Zusätzlich lässt sich überprüfen, wie viel Aufwand die Ände-rungen an der Konzeptbeschreibung bedeuten würden, um den Bedarf der Kon-sistenzhaltung konkreter einschätzen zu können. Dabei sind außerdem Quantitätund Qualität des Empfängerkreises zu berücksichtigen.

Um den praktischen Nutzen des vorgeschlagenen Ansatzes objektiv beurteilenzu können, sind weitere Untersuchungen notwendig. Zum Einen sollte die Ver-wendung der erstellten Konzeptbeschreibungen bei der Benutzung durch Mit-arbeiter, die nicht direkt an der Erstellung beteiligt waren, über einen längerenZeitraum beobachtet und ausgewertet werden. Aus diesen Ergebnissen kann derreale Bedarf an Konsistenzhaltung in Konzeptbeschreibungen objektiv abgeleitetwerden. Damit könnte in Abhängigkeit vom Änderungsgrad bzw. von der Be-deutsamkeit der Änderungen geprüft werden, ob eine Anpassung der Konzept-beschreibung tatsächlich erforderlich ist. Des Weiteren müsste in diesem Rahmenüberprüft werden, inwiefern explizite Angaben für den Übergang von abstrak-ten Konzeptbeschreibungen hin zu den konkreteren Designbeschreibungen undzum Quelltext von den Lesern als notwendig erachtet werden und wie sehr die-se Beschreibungen konsistent gehalten werden müssen. Hierzu müsste in Formvon Experimenten der aufzubringende Zeitaufwand gemessen und in Relati-on zu der zu bewältigenden Aufgabe gesetzt werden. Zum Anderen könntendurch die Einführung und Auswertung explizit durchgeführter Konsistenzprü-fungen wiederkehrende und kritische Inkonsistenzen vermieden werden. Dafürwäre es hilfreich, auf eine beschränkte Anzahl von Modellierungsansätze zurück-zugreifen und Checklisten für diese zu entwickeln. Bei den Checklisten solltenbedeutsame und wiederkehrende Inkonsistenzen besonders berücksichtigt wer-den. Weiterhin wäre es sinnvoll, unterschiedliche Fachgebiete zu untersuchen. Eskönnten sich bestimmte Modellinkonsistenzen für bestimmte Fachgebiete als be-sonders kritisch herausstellen. Diese durch Untersuchungen, vor allem unter Be-rücksichtigung des Aufwand/Nutzen-Kriteriums, zu identifizieren, könnte dieKommunikation in den Projekten weiter positiv beeinflussen. Auch der Einflusseiner dem vorgestellten Ansatz entsprechenden Werkzeugunterstützung auf denUmgang mit Inkonsistenzen sollte untersucht werden. Dadurch lassen sich ge-nauere Anforderungen an die Werkzeuge festlegen. Prinzipiell lassen sich objek-tive Vergleiche zwischen dem herkömmlichen und einem verbesserten Vorgehennur durch Experimente ziehen, die die gleichen Rahmenbedingungen haben. Esdürfte jedoch schwierig werden, finanzielle Unterstützung für solche Vorhabenzu finden, da die Entwicklung eines komplexen Systems ohnehin kostenintensivist und nicht mehrmals von unabhängigen Gruppen entwickelt werden wird.

138

Literaturverzeichnis

[Abramowicz et al. 95] Karol Abramowicz, Birgit Boss, Volkmar Hove-stadt, Jutta A. Mülle und Rose Sturm und PeterC. Lockemann. Konsistenzüberwachung in Daten-banksystemen – Eine Anforderungsanalyse anhandder Entwurfsbereiche Architektur und Schiffbau.In Georg Lausen, Editor, Datenbanksysteme inBüro, Technik und Wissenschaft (BTW), Sei-ten 302–321. Informatik Aktuell Springer, März1995.

[Albers 04] Michael J. Albers. Signal to Noise Ration of Infor-mation in Documentation. In SIGDOC ’04: Pro-ceedings of the 22st annual international con-ference on Documentation, Seiten 41–44. ACMPress, 2004.

[Ameneyro et al. 84] Ricardo Ameneyro, Carolina Arena, Ruben Col-menares, Pedro Cornejo, Rafael Garcia, EloyHernandez, Genaro Mariscal und Socrates Rive-ra. Systems documentation. In SIGDOC ’84: Pro-ceedings of the 3rd annual international confe-rence on Systems documentation, Seiten 29–32.ACM Press, 1984.

[Apfelbacher et al. 05] Rémy Apfelbacher, Andreas Knöp-fel, Peter Aschenbrenner und Sebasti-on Preetz. FMC Visualization Guidelines.http://www.f-m-c.org/viz-guidelines/download/FMC-VisualizationGuidelines.pdf,Januar 2005.

[Balzer 91] Robert Balzer. Tolerating Inconsistency. Procee-dings, 13th International Conference on Softwa-re Engineering (ICSE-13), Austin, Texas, USA.IEEE Computer Society Press, Seiten 158–165,1991.

[Balzert 00] Helmut Balzert. Lehrbuch der Software-Technik, Band 1. Software-Entwicklung aus

139

http://www.f-m-c.org/viz-guidelines/download/FMC-VisualizationGuidelines.pdf

http://www.f-m-c.org/viz-guidelines/download/FMC-VisualizationGuidelines.pdf


Lehrbücher der Informatik. Spektrum Akademi-scher Verlag GmbH Heidelberg Berlin, 2. Aufla-ge, 2000.

[Barker 03] Thomas T. Barker. Writing Software Docu-mentation: A Task Oriented Approach. Allyn& Bacon/Longman Publishers, Zweite Auflage,2003.

[Basili et al. 95] Victor R. Basili, Scott Green, Oliver Laitenber-ger, Forrest Shull, Sivert Sørumgård und Mar-vin V. Zelkowitz. The empirical investigationof perspective-based reading. Technischer Be-richt UMIACS-TR-95-127, University of Mary-land Institute for Advanced Computer Studies,1995.

[Basili 97] Victor R. Basili. Evolving and packaging readingtechnologies. Journal of Systems and Software,Band 38, Nummer 1, Seiten 3–12, 1997.

[Beck et al. 01] Kent Beck, Mike Beedle, Arie van Bennekum,Alistair Cockburn, Ward Cunningham, MartinFowler, James Grenning, Jim Highsmith, An-drew Hunt, Ron Jeffries, Jon Kern, Brian Marick,Robert C. Martin, Steve Mellor, Ken Schwaber,Jeff Sutherland und Dave Thomas. The Agile Ma-nifesto. http://www.agilemanifesto.org/, Fe-bruary 2001.

[Beck 00] Kent Beck. Extreme Programming Explained.Addison-Wesley, 2000.

[Beer 00] Johannes Beer. Systemspezifikation. In PeterBrössler und Johannes Siedersleben, Editoren,Softwaretechnik: Praxiswissen für Software-Ingenieure, Seiten 21–49. Hanser, 2000.

[Benferhat, Garcia 98] Salem Benferhat und Laurent Garcia. A localhandling of inconsistent knowledge and default ba-ses. In A. Hunter und S. Parsons, Editoren, App-lications of Uncertainty Formalisms, Seiten 325–353. LNCS 1455, Springer-Verlag, 1998.

[Bennicke, Rust 04] Marcel Bennicke und Heinrich Rust. Programm-verstehen und statische Analysetechniken im Kon-text des Reverse Engineering und der Qualitätssi-cherung. Technischer Bericht ViSEK/025/D, Vir-tuelles Software Engineering Kompetenzzen-trum, Februar 2004.

140

http://www.agilemanifesto.org/


[Berglund, Priestley 01] Erik Berglund und Michael Priestley. Open-source documentation: in search of user-driven,just-in-time writing. In SIGDOC ’01: Procee-dings of the 19th annual international confe-rence on Computer documentation, Seiten 132–141. ACM Press, 2001.

[Biggerstaff et al. 94] Ted Biggerstaff, Bharat Mitbander und DallasWebster. Program Understanding and the Con-cept Assignment Problem. Communications of theACM, Band 37, Nummer 5, Seiten 72–83, May1994.

[Boehm, Hansen 00] Barry Boehm und Wilfred J. Hansen. SpiralDevelopment: Experience, Principles, and Refine-ments. Technischer Bericht CMU/SEI-2000-SR-008, Carnegie Mellon University, Juli 2000.

[Boehm, Papaccio 88] Barry Boehm und Philip Papaccio. Under-standing and Controlling Software Costs. IEEETransactions on Software Engineering, Band 14,Nummer 10, Seiten 1462–1477, 1988.

[Booch et al. 98] Grady Booch, James Rumbaugh und Ivar Jacob-son. The Unified Modeling Language User Gui-de. Object Techonology Series Addison-Wesley,1998.

[Brockmann 90] R. John Brockmann. The why, where and howof minimalism. In SIGDOC ’90: Proceedingsof the 8th annual international conference onSystems documentation, Seiten 111–119. ACMPress, 1990.

[Bronstein et al. 95] I.N. Bronstein, K.A. Semendjajew, G. Musiolund H. Mühlig. Taschenbuch der Mathema-tik. Harri Deutsch, 2. überarb. und erw. Auflage,1995.

[Bungert 98] Andreas Bungert. Beschreibung programmier-ter Systeme mittels Hierarchien intuitiv ver-ständlicher Modelle. Shaker Verlag, Juni 1998.

[Carroll 97] John M. Carroll. Reconstructing minimalism. InSIGDOC ’97: Proceedings of the 15th annual in-ternational conference on Computer documen-tation, Seiten 27–34. ACM Press, 1997.

141


[Chafin 82] Roy L. Chafin. User manuals: What does the userreally need? In SIGDOC ’82: Proceedings of the1st annual international conference on Systemsdocumentation, Seiten 36–39. ACM Press, 1982.

[Chen 76] Peter Chen. The Entity-Relationship Model - To-ward a Unified View of Data. ACM Transactionson Database Systems, Band 1, Nummer 1, Seiten9–36, March 1976.

[Childs, Sametinger 96] Bart Childs und Johannes Sametinger. Literateprogramming and documentation reuse. In M. Sita-raman, Editor, 4th International Conference onSoftware Reuse, Seiten 205–214. IEEE ComputerSociety Press, 1996.

[Ciolkowski et al. 02] Marcus Ciolkowski, Susanne Hartkopf, Oli-ver Laitenberger und Dieter Rombach. DasViSEK-Projekt: Aufbau einer nationalen empirisch-basierten Erfahrungsdatenbank für Software-Engineering. In Reiner Dumke und DieterRombach, Editoren, Software-Messung und-Bewertung, Seiten 1–12. Gesellschaft für In-formatik (GI), Deutscher Universitätsverlag(DUV), 2002.

[Claus, Schwill 03] Volker Claus und Andreas Schwill, Editoren.Duden Informatik. Bibliographisches Institut, 3.Auflage, 2003.

[Clements et al. 03] Paul Clements, Felix Bachman, Len Bass, DavidGarlan, James Ivers, Reed Little, Robert Nordund Judith Stafford. Documenting Software Ar-chitectures: Views and Beyond. The SEI seriesin software engineering. Addison Wesley, 2003.

[Coad, Yourdon 91a] Peter Coad und Edward Yourdon. Object-Oriented Analysis. Prentice-Hall, Inc., ZweiteAuflage, 1991.

[Coad, Yourdon 91b] Peter Coad und Edward Yourdon. Object-Oriented Design. Prentice-Hall, Inc., 1991.

[Cugola et al. 96] Gianpaolo Cugola, Elisabetta Di Nitto, AlfonsoFuggetta und Carlo Ghezzi. A Framework for For-malizing Inconsistencies and Deviations in Human-Centered Systems. ACM Transaction on Softwa-re Engineering and Methodology, Band 5, Num-mer 3, May 1996.

142


[Deimel, Naveda 90] Lionel E. Deimel und J. Fernando Naveda. Rea-ding computer programs: Instructor ’s guide andexercises. Technischer Bericht CMU/SEI-90EM-3 ADA228026, Software Engineering Institute(Carnegie Mellon University), August 1990.

[DeMarco 78] Tom DeMarco. Structured Analysis and SystemSpecification. Yourdon Press, 1978.

[DIN 92] DIN. DIN 66 200 - Betrieb von Rechensystemen -Begriffe, Auftragsbeziehungen, März 1992.

[Easterbrook, Chechik 01] Steve Easterbrook und Marsha Chechik. 2nd In-ternational Worshop on Living With Inconsistency.In Proceedings of the 23rd International Confe-rence on Software Engineering (ICSE’01), Seiten749–750. IEEE Computer Society, 2001.

[Easterbrook, Nuseibeh 96] Steve Easterbrook und Bashar Nuseibeh. UsingViewPoints for Inconsistency Management. Soft-ware Engineering Journal, Band 11, Nummer 1,Seiten 31–43, Januar 1996.

[Easterbrook 91] Steve Easterbrook. Handling conflict between do-main descriptions with computer-supported nego-tiation. Knowledge Acquisition: An Internatio-nal Journal, Band 3, Nummer 3, Seiten 255–289,1991.

[Easterbrook 96] Steve Easterbrook. Learning from Inconsistency.Proceedings, Eighth International Workshop onSoftware Specification and Design (IWSSD-8),Paderborn, Germany, Seiten 22–23, März 1996.

[Eclipse 01] Eclipse. Eclipse. http://www.eclipse.org/, No-vember 2001.

[Fagan 76] Michael E. Fagan. Design and Code Inspections toReduce Errors in Program Development. IBM Sys-tems Journal, Band 15, Nummer 3, Seiten 182–211, 1976.

[Fickas et al. 97] Stephen Fickas, Jeffrey Kramer und MartinFeather. Workshop on Living With Inconsistency of19th International Conference on Software Enginee-ring (ICSE’97). http://www.icse-conferences.org/1997/workshop/inconsistency.html,1997.

143

http://www.eclipse.org/

http://www.icse-conferences.org/1997/workshop/inconsistency.html

http://www.icse-conferences.org/1997/workshop/inconsistency.html


[Finkelstein 00] Anthony Finkelstein. A Foolish Consistency: Tech-nical Challenges in Consistency Management. InM. Ibrahim, J. Künig und N. Revell, Editoren,DEXA ’00: Proceedings of the 11th Internatio-nal Conference on Database and Expert SystemsApplications, Seiten 1–5. LNCS 1873, Springer-Verlag, 2000.

[Flyvbjerg 07] Bent Flyvbjerg. Five Misunderstandings aboutCase-Study Research, Seiten 390–404. Londonand Thousand Oaks (Sage), 2007.

[FMC] FMC. Fundamental Modeling Concpets (FMC).http://www.f-m-c.org.

[Forward, Lethbridge 02] Andrew Forward und Timothy C. Lethbridge.The relevance of software documentation, tools andtechnologies: a survey. In DocEng ’02: Procee-dings of the 2002 ACM symposium on Do-cument engineering, Seiten 26–33. ACM Press,2002.

[Fowler 97] Martin Fowler. The Almighty Thud.http://martinfowler.com/, Novem-ber/Dezember 1997.

[Gabbay, Hunter 91] Dov Gabbay und Anthony Hunter. MakingInconsistency Respectable 1: A Logical Frameworkfor Inconsistency in Reasoning. In P. Jorrandund J. Kelemen, Editoren, Proceedings of Fun-damentals of Artifical Intelligence Research(FAIR’91), Seiten 19–32. Springer Verlag, 1991.

[Gabbay, Hunter 93] Dov Gabbay und Anthony Hunter. Making In-consistency Respectable: Part 2 - Meta-level hand-ling of inconsistency. In Symbolic and Quantita-tive Approaches to Reasoning and Uncertainty,Seiten 129–136, 1993.

[Gales 98] Frank Gales. Ein Beitrag zur Begriffswelt derSchaffung programmierter Systeme. ShakerVerlag, 1998.

[Gamma et al. 95] Erich Gamma, Richard Helm, Ralph Johnsonund John Vlissides. Design Patterns. AddisonWesley, 1995.

[Gentner, Stevens 83] Dedre Gentner und Albert L. Stevens. MentalModels. Lawrence Erlbaum Associates, Hills-dale, NJ, 1983.

144

http://www.f-m-c.org

http://martinfowler.com/


[Gervasi, Nuseibeh 02] Vincenzo Gervasi und Bashar Nuseibeh. Light-weight validation of natural language requirements.Software Practice and Experience, Band 32,Nummer 2, Seiten 113–133, 2002.

[Ghezzi, Nuseibeh 99] Carlo Ghezzi und Bashar Nuseibeh. Guest Edi-torial: Introduction to the Special Section. IEEETransactions on Software Engineering, Band 25,Nummer 6, Seiten 782–783, 1999.

[Gieszl 92] Louis Gieszl. Traceability for Integration. In Pro-ceedings of the 2nd Conference on Systems In-tegration (ICSI 92), Seiten 220–228. IEEE, 1992.

[Glaser, Strauss 67] Barney Glaser und Anselm Strauss. The Disco-very of Grounded Theory: Strategies for Quali-tative Research. Aldine, Chicago IL, USA, 1967.

[Gödel 31] Kurt Gödel. Über formal unentscheidbare Sätze derPrincipia Mathematica und verwandter Systeme I.Monatsheft für Mathematik und Physik 38, Sei-ten 173–198, 1931.

[Goodenough 75] John Goodenough. Exception Handling: Issuesand a Proposed Notation. Communications of theACM, Band 18, Nummer 12, Seiten 683–696, De-cember 1975.

[Gray, Reuter 93] Jim Gray und Andreas Reuter. TransactionProcessing: Concepts and Techniques. MorganKaufmann Publishers Inc., 3. Auflage, 1993.

[Gröne 04] Bernhard Gröne. Konzeptionelle Patterns und ihreDarstellung. Dissertation, Universität Potsdam,2004.

[Grundy et al. 98] John Grundy, John Hosking und Warwick B.Mugridge. Inconsistency Management forMultiple-View Software Development Envi-ronments. IEEE Transactions on SoftwareEngineering, Band 24, Nummer 11, Seiten960–981, 1998.

[Gryce et al. 02] Clare Gryce, Anthony Finkelstein und Chris-tian Nentwich. Ligthweight Checking for UMLbased Software Development; Workshop on Consis-tency Problems un UML-bases Software Develop-ment. In Ludwik Kuzniarz, Gianna Reggio,Jean Louis Sourrouille und Zbigniew Huzar,

145


Editoren, Workshop on Consistency Problemsin UML-based Software Development, Seiten124–132, 2002.

[Hagensen, Kristensen 92] Torben Mejlvang Hagensen und Bent BruunKristensen. Consistency in software system deve-lopment: framework, model, techniques & tools. InSDE 5: Proceedings of the fifth ACM SIGSOFTsymposium on Software development environ-ments, Seiten 58–67. ACM Press, 1992.

[Harel, Rumpe 00] David Harel und Bernhard Rumpe. Mode-ling Languages: Syntax, Semantics and All ThatStuff. Technischer Bericht MCS00-16, WeizmannScience Press of Israel (Jerusalem), August 2000.

[Häuslein 04] Andreas Häuslein. Systemanalyse. VDE VER-LAG GMBH, Berlin und Offenbach, 2004.

[Hepting 99] Daryl Hepting. What’s a picture really worth?http://www2.cs.uregina.ca/~hepting/research/web/words/index.html, 1999.

[Hofmeister et al. 00] Christine Hofmeister, Robert Nord und DilipSoni. Applied Software Architecture. ObjectTechnology Series, Addison-Wesley, 2000.

[Holtzman 93] Jeffrey K. Holtzman. Ready. Fire!! Aim??? InSIGDOC ’93: Proceedings of the 11th annual in-ternational conference on Systems documenta-tion, Seiten 117–134. ACM Press, 1993.

[Hungerford et al. 04] Bruce C. Hungerford, Alan R. Hevner und Ro-sann W. Collins. Reviewing Software Diagrams: ACognitive Study. IEEE Transactions on SoftwareEngineering, Band 30, Nummer 2, Seiten 82–96,February 2004.

[Huzar et al. 04] Zbigniew Huzar, Ludwik Kuzniarz, GiannaReggio und Jean Louis Sourrouille. Third Work-shop on Consistency Problems in UML-based Soft-ware Development: Understanding and Usage ofDependency Relationships. In <<UML>> 2004Modelling Languages and Applications, Okto-ber 2004.

[IEEE 00] IEEE. IEEE Standard 1471-2000 - IEEE Recom-mended Practice for Architectural Description of

146

http://www2.cs.uregina.ca/~hepting/research/web/words/index.html

http://www2.cs.uregina.ca/~hepting/research/web/words/index.html


Software-Intensive Systems. The Institute of Elec-trical and Electronics Engineers Inc., NY, USA,2000.

[Jackson 94] Michael Jackson. Problems, Methods and Specia-lization. IEEE Software Software EngineeringJournal, Seiten 57–62, November 1994.

[Jackson 95] Michael Jackson. The World and the Machine. inProceedings of ICSE-17; ACM Press, Seiten 283–292, 1995.

[Jackson 00] Michael Jackson. The Real World. in Proceedingsof a Symposium to celebrate the work of C A RHoare, 2000.

[Kaner 03] Cem Kaner. Liability for defective documentation.In SIGDOC ’03: Proceedings of the 21st annu-al international conference on Documentation,Seiten 192–197. ACM Press, 2003.

[Keller et al. 02] Frank Keller, Peter Tabeling, Rémy Apfelbacher,Bernhard Gröne, Andreas Knöpfel, Rudolf Ku-gel und Oliver Schmidt. Improving KnowledgeTransfer at the Architectural Level: Concepts andNotations. In The 2002 International Conferenceon Software Engineering Research and Practice(SERP’02), Seiten 101–107, Juni 2002.

[Keller 03] Frank Keller. Über die Rolle von Architektur-beschreibungen im Software-Entwicklungsprozess.Dissertation, Universität Potsdam, 2003.

[Kleis 99] Wolfram Kleis. Konzepte zur verständlichen Be-schreibung objektorientierter Frameworks. Disser-tation, Universität Kaiserslautern, 1999.

[Knöpfel et al. 05] Andreas Knöpfel, Bernhard Gröne und Peter Ta-beling. Fundamental Modeling Concepts: Effec-tive Communication of IT Systems. John Wiley& Sons Ltd, 2005.

[Kruchten 95] Philippe Kruchten. Architectural Blueprints - The"4+1" View Model of Software Architecture. IEEESoftware 12 (6), Seiten 42 – 50, November 1995.

[Kruchten 04] Philippe Kruchten. The Rational Unified Pro-cess - An Introduction - Third Edition. Addison-Wesley, 2004.

147


[Kuzniarz et al. 02] Ludwik Kuzniarz, Gianna Reggio, Jean LouisSourrouille und Zbigniew Huzar. Workshop onConsistency Problems in UML-based Software De-velopment. In <<UML>> 2002 Model Enginee-ring, Concepts and Tools, Juni 2002.

[Kuzniarz et al. 03] Ludwik Kuzniarz, Zbigniew Huzar, GiannaReggio, Jean Louis Sourrouille und Miros-law Staron. Workshop on Consistency Pro-blems in UML-based Software Development II. In<<UML>> 2003 Modelling Languages and Ap-plications, Oktober 2003.

[Kuzniarz, Staron 03] Ludwik Kuzniarz und Miroslaw Staron. Incon-sistencies in Student Design. In Ludwik Kuzniarz,Zbigniew Huzar, Gianna Reggio, Jean LouisSourrouille und Miroslaw Staron, Editoren,Workshop on Consistency Problems in UML-based Software Development II, Seiten 9–17,Oktober 2003.

[Laitenberger et al. 00] Oliver Laitenberger, Colign Atkinson, MaudSchlich und Khaled El Emam. An Experimen-tal Comparision of Reading Techniques for DefectDetection in UML Design Documents. Tech-nischer Bericht ISERN-00-01 oder IESE-ReportNo. 080.99/E, Fraunhofer IESE, 2000.

[Lange, Chaudron 06] Christian F. J. Lange und Michel R. V. Chaudron.Effects of defects in UML models: an experimentalinvestigation. In ICSE ’06: Proceeding of the 28thinternational conference on Software enginee-ring, Seiten 401–411. ACM Press, 2006.

[Lange et al. 03] C. Lange, M.R.V. Chaudron, J. Muskens, L.J. So-mers und H.M. Dortmans. An Empirical Inves-tigation in Quantifying Inconsistency and Incom-pleteness of UML Designs. In Ludwik Kuzniarz,Zbigniew Huzar, Gianna Reggio, Jean LouisSourrouille und Miroslaw Staron, Editoren,Workshop on Consistency Problems in UML-based Software Development II, Seiten 26–34,Oktober 2003.

[Liu et al. 02] WenQian Liu, Steve Easterbrook und John My-lopoulos. Rule-based detection of inconsistency inUML models. In Gianna Reggio Ludwik Kuz-niarz, Jean Louis Sourrouille und Zbigniew

148


Huzar, Editoren, <<UML>> 2002 Model Engi-neering, Concepts and Tools; Workshop on Con-sistency Problems un UML-bases Software De-velopment, Seiten 106–123, 2002.

[Löhr-Richter 93] Perdita Löhr-Richter. Methodologie - Methodik- Methode. Was steckt dahinter? EMISA Forum,Band 3, Nummer 1, Seiten 39–41, 1993.

[Matthews, Grove 92] Sky Matthews und Carl Grove. Applying Object-Oriented Concepts to Documentation. In SIGDOC’92: Proceedings of the 10th annual internationalconference on Computer documentation, Seiten265–271. ACM Press, 1992.

[McConnell 93] Steve McConnell. Code Complete - A practicalHandbook of Software Construction. MicrosoftPress, 1993.

[McGregor 82] Scott L. McGregor. Improving documentation. InSIGDOC ’82: Proceedings of the 1st annual in-ternational conference on Systems documenta-tion, Seiten 107–119. ACM Press, 1982.

[Mead 98] Jay Mead. Measuring the Value Added by TechnicalDocumentation: A Review of Research and Practice.Technical Communication, Seiten 353–379, 45.3(Third Quarter) 1998.

[Medvidovic, Taylor 00] Nenad Medvidovic und Richard N. Taylor. AClassification and Comparison Framework for Soft-ware Architecture Description Languages. IEEETransactions on Software Engineerin, Band 26,Nummer 1, Seiten 70–93, Januar 2000.

[Melchisedech 00] Ralf Melchisedech. Verwaltung und Prüfung na-türlichsprachlicher Spezifikationen. Dissertation,Institut für Informatik der Universität Stuttgart,2000.

[Müller 82] Wolfgang Müller, Editor. Duden "Fremdwörter-buch". Bibliographisches Institut, 4. neu berab.u. erw. Auflage, 1982.

[Murata 89] Tadao Murata. Petri Nets: Properties, Analysis andApplications. Proceedings of the IEEE, Band 77,Nummer 4, Seiten 541–580, April 1989.

149


[Narayanaswamy, Goldman 92] K. Narayanaswamy und Neil Goldman. "La-zy" consistency: a basis for cooperative software de-velopment. In Proceedings of the 1992 ACMconference on Computer-supported cooperati-ve work, Seiten 257–264. ACM Press (New York,NY, USA), 1992.

[Nentwich et al. 03] Christian Nentwich, Wolfgang Emmerich, An-thony Finkelstein und Ernst Ellmer. Flexible con-sistency checking. ACM Transactions on SoftwareEngineering and Methodology, Band 12, Num-mer 1, Seiten 28–63, 2003.

[Norman 83] Donald A. Norman. Some observations on MentalModels. In Dedre Gentner und Albert L. Stevens,Editoren, Mental Models, Seiten 7–14. LawrenceErlbaum Associates, Hillsdale, NJ, 1983.

[Nuseibeh, Easterbrook 99] Bashar Nuseibeh und Steve Easterbrook. TheProcess of Inconsistency Management: A Frame-work for Understanding. In Proceedings of theFirst International Workshop on the Requi-rements Engineering Process (REP’99), Seiten364–368, 1999.

[Nuseibeh et al. 00] Bashar Nuseibeh, Steve Easterbrook und Ales-sandra Russo. Leveraging Inconsistency in Softwa-re Development. IEEE Computer, Band 33, Num-mer 4, Seiten 24–29, April 2000.

[Nuseibeh 94] Bashar Nuseibeh. A Multi-Perspective Frame-work for Method Integration. Dissertation, Imperi-al College of Science, Technology and Medicine,University of London, Department of Compu-ting, Oktober 1994.

[Nuseibeh 96] Bashar Nuseibeh. To Be and Not to Be: OnManaging Inconsistency in Software Development.Proceedings of 8th International Workshop onSoftware Specification and Design (IWSSD-8),Schloss Velen, Germany, IEEE CS Press., Seiten164–169, March 1996.

[Nykaza et al. 02] Janet Nykaza, Rhonda Messinger, Fran Boehme,Cherie L. Norman, Matthew Mace und ManuelGordon. What programmers really want: results ofa needs assessment for SDK documentation. In SIG-DOC ’02: Proceedings of the 20th annual inter-

150


national conference on Computer documentati-on, Seiten 133–141. ACM Press, 2002.

[Olsson, Runeson 02] Thomas Olsson und Per Runeson. DocumentUse in Software Development: A Qualitative Sur-vey. In SERPS ’02: Second Conference on Soft-ware Engineering Research and Practise in Swe-den, 2002.

[Oman, Cook 90] Paul W. Oman und Curtis R. Cook. TypographicStyle is More than Cosmetic. Communications ofthe ACM, Band 33, Nummer 5, Seiten 506–520,May 1990.

[OMG] OMG. Object Management Group. UML Resour-ce Page. http://www.omg.org/technology/uml/index.htm.

[Østerbye 99] Kasper Østerbye. Minimalist Documentation ofFrameworks. In 3rd ECCOP’99 Workshop onExperiences in Object-Oriented Reengineering,Seiten 172–181. Springer Verlag, 1999.

[Parnas, Clements 86] David Parnas und Paul Clements. A RationalDesign Process: How and Why to Fake it. IEEETransactions on Software Engineering, Band 12,Nummer 2, Seiten 251–257, Februar 1986.

[Parnas et al. 94] David Lorge Parnas, Jan Madey und MichalIglewski. Precise Documentation of Well-Structured Programs. IEEE Transactions on Soft-ware Engineering, Band 20, Nummer 12, Seiten948–976, Dezember 1994.

[Petre 95] Marian Petre. Why Looking Isn’t Always Seeing:Readership Skills and Graphical Programming.Communications of the ACM, Band 38, Num-mer 6, Seiten 33–44, Juni 1995.

[Petri 62] Carl Adam Petri. Kommunikation mit Automa-ten. Dissertation, Technische Hochschule Darm-stadt, 1962.

[Porter et al. 95] Adam A. Porter, Jr. Lawrence G. Votta und Vic-tor R. Basili. Comparing Detection Methods forSoftware Requirements Inspections: A ReplicatedExperiment. IEEE Transactions on Software En-gineering, Band 21, Nummer 6, Seiten 563–575,1995.

151

http://www.omg.org/technology/uml/index.htm

http://www.omg.org/technology/uml/index.htm


[Potter et al. 91] Ben Potter, Jane Sinclair und David Till. Anintroduction to formal specification and Z.Prentice-Hall, Inc., 1991.

[Potts, Bruns 88] Collin Potts und Glenn Bruns. Recording the re-asons for design decisions. In Proceedings of the10th international conference on Software engi-neering, Seiten 418–427. IEEE Computer SocietyPress, 1988.

[Purchase et al. 01] Helen C. Purchase, Jo-Anne Allder und Da-vid Carrington. User Preference of Graph Lay-out Aesthetics: A UML Study. In J. Marks, Edi-tor, Graph Drawing: 8th International Symposi-um, GD 2000, Colonial Williamsburg, VA, USA,September 2000, Band 1984, Seiten 5–18. Lec-ture Notes in Computer Science Springer-VerlagGmbH, 2001.

[Rawlinson 76] Graham Rawlinson. The significance of letter posi-tion in word recognition. Dissertation, UniversitätNottingham, 1976.

[Robinson, Pawlowski 99] William N. Robinson und Suzanne D. Pawlow-ski. Managing Requirements Inconsistency withDevelopment Goal Monitors. IEEE Transactionson Software Engineering, Band 25, Nummer 6,Seiten 816–835, 1999.

[Rüping 03] Andreas Rüping. Agile Documentation - APattern Guide To Producing Lightweight Docu-ments for Software Projects. John Wiley & SonsLtd., 2003.

[Russo et al. 98] Alessandra Russo, Bashar Nuseibeh und JeffKramer. Restructuring Requirements SpecificationsFor Managing Inconsistency And Change: A CaseStudy. In ICRE ’98: Proceedings of the 3rd Inter-national Conference on Requirements Enginee-ring, Seiten 51–60. IEEE Computer Society, 1998.

[Scheffczyk et al. 04] Jan Scheffczyk, Peter Rödig, Uwe M. Borghoffund Lothar Schmitz. Managing inconsistent repo-sitories via prioritized repairs. In DocEng ’04: Pro-ceedings of the 2004 ACM symposium on Docu-ment engineering, Seiten 137–146. ACM Press,2004.

152


[Schwanke, Kaiser 88] Robert Schwanke und Gail Kaiser. Living withinconsistency in large systems. In Proceedings ofthe International Workshop on Software Versionand Configuration Control, Seiten 98–118. B. G.Teubner Stuttgart, Januar 1988.

[Seewaldt 88] Thomas Seewaldt. Die Abbildung zwischen derBeschreibung informationeller Systeme und der Mo-dulstruktur von Programmen großer sequentiellerimperativ programmierter Abwicklersysteme. Dis-sertation, Universität Kaiserslautern, 1988.

[Shook 97] Ronald Shook. Seven graphic sins. In SIGDOC’97: Proceedings of the 15th annual internationalconference on Computer documentation, Seiten249–254. ACM Press, 1997.

[Sickler 82] Geoffrey James Sickler. System documentation assoftware. In SIGDOC ’82: Proceedings of the 1stannual international conference on Systems do-cumentation, Seiten 139–142. ACM Press, 1982.

[SigDoc] SigDoc. ACM Special Interest Group on Design ofCommunication (SIGDOC). http://www.sigdoc.org/.

[Smart 02] Karl L. Smart. Assessing Quality Documents.ACM Journal of Computer Documentation,Band 26, Nummer 3, Seiten 130–140, August2002.

[Smidts et al. 02] Carol Smidts, Xin Huang und James C. Widmai-er. Producing reliable software: an experiment. TheJournal of Systems and Software, Nummer 61,Seiten 213–224, 2002.

[Sommerville et al. 99] Ian Sommerville, Peter Sawyer und Stephen Vil-ler. Managing Process Inconsistency Using View-points. Software Engineering, Band 25, Num-mer 6, Seiten 784–799, 1999.

[Sommerville 02] Ian Sommerville. Software Documentation. InR. H. Thayer und M. I. Christensen, Editoren,Software Engineering, Vol 2: The SupportingProcesses. Wiley-IEEE Press, 2002.

[Soni et al. 95] Dilip Soni, Robert L. Nord und Christine Hof-meister. Software architecture in industrial appli-cations. In ICSE ’95: Proceedings of the 17th in-

153

http://www.sigdoc.org/

http://www.sigdoc.org/


ternational conference on Software engineering,Seiten 196–207. ACM Press, 1995.

[Spanoudakis, Kassis 00] George Spanoudakis und Kuriakos Kassis. AnEvidential Framework for Diagnosing the Signifi-cance of Inconsistencies in UML Models. In Procee-dings of the International Conference on Soft-ware: Theory and Practice, Seiten 152–162, 2000.

[Spanoudakis, Zisman 01] George Spanoudakis und Andrea Zisman. In-consistency Management in Software Enginee-ring: Survey and Open Research Issues, Seiten93–109. World Scientific Publishing, 2001.

[Standish 95] Standish. The CHAOS Report. Technischer Be-richt, The Standish Group International, Inc.,1995.

[Standish 99] Standish. CHAOS: A Receipe for Success. Tech-nischer Bericht, The Standish Group Internatio-nal, Inc., 1999.

[Standish 01] Standish. EXTREME CHAOS. Technischer Be-richt, The Standish Group International, Inc.,2001.

[Stimely 90] Gwen L. Stimely. A stepwise approach to deve-loping software documentation. In SIGDOC ’90:Proceedings of the 8th annual international con-ference on Systems documentation, Seiten 121–124. ACM Press, 1990.

[Strauss, Corbin 99] Anselm Strauss und Juliet Corbin. Basics ofQualitative Research: Techniques and Procedu-res for Developing Grounded Theory. Sage Pu-blications, zweite Auflage, 1999.

[Sutton 90] Jr. Stanley M. Sutton. A Flexible ConsistencyModel for Persistent Data in Software-Process Pro-gramming Languages. In Alan Dearle, Gail M.Shaw und Stanley B. Zdonik, Editoren, Procee-dings of the Fourth International Workshop onPersistent Objects (Implementing Persistent Ob-ject Bases: Principles and Practice), Seiten 305–318. Morgan Kaufmann, September 1990.

[Tabeling 00] Peter Tabeling. Der Modellhierarchieansatzzur Beschreibung nebenläufiger, verteilter undtransaktionsverarbeitender Systeme. ShakerVerlag, 2000.

154


[Tabeling 05] Peter Tabeling. Softwaresysteme und ihre Mo-dellierung: Grundlagen, Methoden und Techni-ken. Springer-Verlag, 2005.

[Toffolon, Dakhli 99] Claudine Toffolon und Salem Dakhli. Human-Centered Systems Development and Use Inconsis-tencies. Conference "Human Centered Process"(HCP’99), Brest, France, September 1999.

[Travassos et al. 99] Guilherme Travassos, Forrest Shull, MichaelFredericks und Victor R. Basili. Detecting de-fects in object-oriented designs: using reading tech-niques to increase software quality. In OOPSLA ’99:Proceedings of the 14th ACM SIGPLAN con-ference on Object-oriented programming, sys-tems, languages, and applications, Seiten 47–56.ACM Press, 1999.

[Visconti, Cook 00] Marcello Visconti und Curtis R. Cook. An Over-view of Industrial Software Documentation Practi-ces. Technischer Bericht Technical Report 00-60-06, Computer Science Department Oregon StateUniversity, April 2000.

[Wendt 78] Siegfried Wendt. Aussagenprozesse und Kausal-strukturen. Technischer Bericht, Universität Kai-serslautern, September 1978.

[Wendt 79] Siegfried Wendt. The Programmed Action Module:An Element for System Modelling. Digital Proces-ses, Band 5, Nummer 3-4, Seiten 213–222, 1979.

[Wendt 80a] Siegfried Wendt. Modified Petri Nets as flowchartsfor recursive programs. Software - Practice andExperience, Band Vol. 10, Seiten 935–942, Mai1980.

[Wendt 80b] Siegfried Wendt. On the Partitioning of Com-puting Systems into Communicating Agencies. InInformatik-Fachberichte GI-NTG FachtagungStruktur und Betrieb von Rechensystemen, Sei-ten 194–204. Springer-Verlag, März 1980.

[Wendt 91] Siegfried Wendt. Nichtphysikalische Grund-lagen der Informationstechnik - InterpretierteFormalismen. Springer-Verlag, Zweite Auflage,1991.

155


[Wendt 97] Siegfried Wendt. Zeigen, Nennen, Umschreiben -die drei Alternativen der Identifiaktion. TechnischerBericht, Universität Kaiserslautern, November1997.

[Wendt 98a] Siegfried Wendt. Die Begriffswelt des Formalen.Technischer Bericht, Universität Kaiserslautern,Februar 1998.

[Wendt 98b] Siegfried Wendt. Formalismen und Anschauung.Technischer Bericht, Universität Kaiserslautern,Februar 1998.

[Wendt 98c] Siegfried Wendt. Opertationszustand versus Steu-erzustand - eine äußerst zweckmäßige Unterschei-dung. Technischer Bericht, Universität Kaisers-lautern, Februar 1998.

[Wendt 01] Siegfried Wendt. Ein grundlegender Begriffs-rahmen für das Wissensmanagement im Software-Engineering. Knowledge Engineering and Ma-nagement (KnowTech ’01), 2001.

[Yin 94] Robert K. Yin. Case Study Research - De-sign and Methods. Applied Social ResearchMethods Series (Volume 5). Sage Publications,zweite Auflage, 1994.

[Young 83] Richard M. Young. Surrogates and Mappings: TwoKinds of Cosnceptual Models for Interactive Devices.In Dedre Gentner und Albert L. Stevens, Edito-ren, Mental Models, Seiten 35–52. Lawrence Erl-baum Associates, Hillsdale, NJ, 1983.

[Yu, Mylopoulos 94] Eric S. K. Yu und John Mylopoulos. Understan-ding "Why" in software process modelling, analysis,and design. In Proceedings of 16th Internatio-nal Conference on Software Engineering, Seiten159–168. IEEE Computer Society Press, 1994.

[Zimmermann 97] Beverly B. Zimmermann. Applying Tufte’s prin-ciples of information design to creating effective Websites. In SIGDOC ’97: Proceedings of the 15th an-nual international conference on Computer do-cumentation, Seiten 309–317. ACM Press, 1997.

[Zorn 03] Werner Zorn. FMC-eCS und FMC-QPN. http://www-ks.hpi.uni-potsdam.de/, 2003.

156

http://www-ks.hpi.uni-potsdam.de/

http://www-ks.hpi.uni-potsdam.de/


[Zuck 90] Wolfgang Zuck. Konsistente Dokumentation beimEntwurf informationsverarbeitender Systeme. Dis-sertation, Universität Kaiserslautern, 1990.

157


158

Index

Ablaufstruktur, 9Aggregationsbeziehung, 11Akteur, 9aktive Komponente, 9

Akteur, 9Analyse, 36, 41

qualitative Analyse, 93Anschauungsmodell, 9Architekturbeschreibung, 63Aspekt, 8, 12Aspektmodell, 9Assoziation, 11Attribut, 11Aufbaudiagramm, 15Aufbaustruktur, 8Auflösungsbeziehungen, 9Auslieferungseinheit, 10Aussage, 20Axial Coding, 95

Bedarfsgesteuerte Lesetechnik, 68Bedeutsamkeit, 26Begriffswelt, 8bemerkte Inkonsistenz, 21Beschreibung, 12

formale Beschreibung, 13nicht-formale Beschreibung, 13semi-formale Beschreibung, 14

Betrachtungsebenenbeziehungen, 9Bottom-Up Lesetechnik, 67

Cross Case Analysis, 95

Dateninkonsistenz, 31deklarative Systembeschreibungen, 52Designbeschreibung, 58deskriptive Systembeschreibungen, 52Diagrammzentriertheit, 126direkte Inkonsistenz, 27Dokument, 61

Dokumenttypen, 64Kohäsion, 72Kopplung, 72Versionisierung von Dokumenten,

74Dokumentation, 61

Mitdokumentation, 61Nachdokumentation, 61

Dokumentationerstellungsprozess, 70Dokumentationevolutionsprozess, 70Dokumenterstellungsansatz, 75

Minimalism, 70task-oriented approach, 71

Dokumenttypen, 64

elektronische Medien, 50empfängerkreisbezogene Klasse von

Systembeschreibungen, 53externer Empfängerkreis, 54interner Empfängerkreis, 54maschineller Empfängerkreis, 54menschlicher Empfängerkreis, 54

Exemplar, 14explizite Inkonsistenz, 23explorative Fallstudie, 93externe Inkonsistenz, 25externe Modellinkonsistenz, 35externer Empfängerkreis, 54

Fallstudie, 93Cross Case Analysis, 95explorative Fallstudie, 93Grounded Theory, 94Mehrfach-Fallstudie, 93qualitative Analyse, 93

Fehler, 22Fehlverhalten, 31FMC, 8formale Beschreibung, 13formale Konsistenzprüfung, 27

159

Index

Konsistenzbedingung, 27Konsistenzregel, 27

formale Semantik, 13formale Sprache, 13formale Systembeschreibungen, 52Formalisierung, 14Formalisierungsgrad, 13Formalismus, 13formbezogene Klasse von Systembe-

schreibungen, 48formbezogene Klassen von Systembe-

schreibungendeklarative Systembeschreibungen,

52deskriptive Systembeschreibungen,

52formale Systembeschreibungen, 52mündliche Systembeschreibungen,

48medienbezogene Klasse von Sys-

tembeschreibungen, 50nicht-formale Systembeschreibun-

gen, 53schriftliche Systembeschreibungen,

48semi-formale Systembeschreibun-

gen, 53sprachbezogene Klasse von Sys-

tembeschreibungen, 53Formulierung, 12Fundamental Modeling Concepts, 8

Ablaufstruktur, 9Akteur, 9aktive Komponente, 9Anschauungsmodell, 9Aspekt, 8Aspektmodell, 9Aufbaudiagramm, 15Aufbaustruktur, 8Kanal, 9Operationszustand, 9passive Komponente, 9Petrinetz, 15Schichtungsdiagramm, 15Speicher, 9Steuerzustand, 9

Strukturvarianz, 9Wertebereichsdiagramm, 15Wertebereichsstruktur, 9Zustandsdiagramm, 15

Generalisierungsbeziehung, 11gewollte Inkonsistenz, 22Grad der Vereinbarkeit, 26Grammatik, 13Grounded Theory, 94

Axial Coding, 95Open Coding, 95Selective Coding, 95

horizontale Lesetechnik, 69

ideales informationelles Systemmodell,8

ideales Modell, 36ideales Systemmodell, 8Identifikation, 12

Nennen, 12Umschreiben, 12Zeigen, 12

Ignorieren von Inkonsistenz, 30implizite Inkonsistenz, 23indirekte Inkonsistenz, 27inhaltsbezogene Klassen von System-

beschreibungenDesignbeschreibung, 58empfängerkreisbezogene Klasse

von Systembeschreibungen, 53externer Empfängerkreis, 54interner Empfängerkreis, 54Konzeptbeschreibung, 58maschineller Empfängerkreis, 54menschlicher Empfängerkreis, 54modellbezogene Klasse von Sys-

tembeschreibungen, 60Produktbeschreibung, 56Prozessbeschreibung, 59technische Systembeschreibung, 57zweck- bzw. interessenbezogene

Klasse von Systembeschreibun-gen, 55

Inkonsistenz, 19, 20Bedeutsamkeit, 26

160

Index

bemerkte Inkonsistenz, 21Dateninkonsistenz, 31direkte Inkonsistenz, 27explizite Inkonsistenz, 23externe Inkonsistenz, 25externe Modellinkonsistenz, 35Fehler, 22Fehlverhalten, 31gewollte Inkonsistenz, 22Grad der Vereinbarkeit, 26implizite Inkonsistenz, 23indirekte Inkonsistenz, 27Inkonsistenzen im System, 31Interdokumentinkonsistenz, 78interne Inkonsistenz, 25interne Modellinkonsistenz, 35Intradokumentinkonsistenz, 77Irrtum, 22Konflikt, 87mental models, 37Methodenbedingte Inkonsistenz, 34Modellinkonsistenz, 35notationelle Inkonsistenz, 34Prozessbedingte Inkonsistenz, 33Quellen von Inkonsistenzen, 39Reaktion auf Inkonsistenz, 28

Ignorieren, 30Korrigieren, 29Tolerieren, 29Verbessern, 29

Redundanz, 24Richtung, 26semantische Inkonsistenz, 34syntaktische Inkonsistenz, 34unbemerkte Inkonsistenz, 21ungewollte Inkonsistenz, 22Vereinbarkeitskriterium, 21Verfolgbarkeit, 24Verhaltensinkonsistenz, 31Versehen, 22Vollständigkeit, 25vorgabenbedingte Inkonsistenz, 33Werkzeugbedingte Inkonsistenz, 34

Inkonsistenzen im System, 31Instanz, 11Interdokumentbeziehungen, 64

Interdokumentinkonsistenz, 78interne Inkonsistenz, 25interne Modellinkonsistenz, 35interner Empfängerkreis, 54Interpretation, 12, 13

primäre Interpretation, 13sekundäre Interpretation, 13

Intradokumentbeziehungen, 64Intradokumentinkonsistenz, 77Irrtum, 22

Kanal, 9Klasse, 11, 14Klassen von Inkonsistenzen

Inkonsistenzen im System, 31Methodenbedingte Inkonsistenz, 34Modellinkonsistenz, 35notationelle Inkonsistenz, 34Prozessbedingte Inkonsistenzen, 33semantische Inkonsistenz, 34syntaktische Inkonsistenz, 34vorgabenbedingte Inkonsistenzen,

33Werkzeugbedingte Inkonsistenz, 34

Klassen von Systembeschreibungendeklarative Systembeschreibungen,

52Designbeschreibung, 58deskriptive Systembeschreibungen,

52empfängerkreisbezogene Klasse

von Systembeschreibungen, 53externer Empfängerkreis, 54formale Systembeschreibungen, 52formbezogene Klasse von System-

beschreibungen, 48interner Empfängerkreis, 54Konzeptbeschreibung, 58mündliche Systembeschreibungen,

48maschineller Empfängerkreis, 54medienbezogene Klasse von Sys-

tembeschreibungen, 50menschlicher Empfängerkreis, 54modellbezogene Klasse von Sys-

tembeschreibungen, 60

161

Index

nicht-formale Systembeschreibun-gen, 53

Produktbeschreibung, 56Prozessbeschreibung, 59schriftliche Systembeschreibungen,

48semi-formale Systembeschreibun-

gen, 53sprachbezogene Klasse von Sys-

tembeschreibungen, 53technische Systembeschreibung, 57zweck- bzw. interessenbezogene


KlassifizierungInkonsistenz, 30

Kodegruppe, 10Kohäsion, 72, 129Kollaboration, 11Kompilat, 10Komponente, 10Konfigurationsmanagementsicht, 10

Auslieferungseinheit, 10Kodegruppe, 10Kompilat, 10Quelldatei, 10

Konflikt, 87Konsistenzbedingung, 27Konsistenzkette, 27Konsistenzprüfung, 21

formale Konsistenzprüfung, 27Konsistenzbedingung, 27Konsistenzregeln, 27nicht formale Konsistenzprüfung,

27Offline Konsistenzprüfung, 28Online Konsistenzprüfung, 28partielle Konsistenzprüfung, 27Skalierbarkeit, 28vollständige Konsistenzprüfung, 27

Konsistenzregel, 27Konzeptbeschreibung, 58

Architekturbeschreibung, 63Konzeptdokument, 63

Konzeptdokument, 63konzeptionelle Sicht, 10

Komponente, 10Port, 10Role, 10Verbinder, 10

Kopplung, 72, 129Korrigieren von Inkonsistenz, 29

Lesetechnik, 67, 68Bedarfsgesteuerte Lesetechnik, 68Bottom-Up Lesetechnik, 67horizontale Lesetechnik, 69Schnelllesetechnik, 68Systematische Lesetechnik, 68Szenarienbasierte Lesetechnik, 68Top-Down Lesetechnik, 67vertikale Lesetechnik, 69

mündliche Systembeschreibung, 45mündliche Systembeschreibungen, 48Medien

elektronische Medien, 50medienbezogene Klasse von Systembe-

schreibungen, 50elektronische Medien, 50

Mehrfach-Fallstudie, 93Menge, 14menschlicher Empfängerkreis, 54

externer Empfängerkreis, 54interner Empfängerkreis, 54

mental models, 37Metamodell (Modellierungsansatz), 8Methodenbedingte Inkonsistenz, 34Mißverständlichkeitsproblem, 13Minimalism, 70Mitdokumentation, 61Modell

Beschreibung, 12ideales informationelles Systemmo-

dell, 8ideales Modell, 36Modellbildung, 36nicht ideales Modell, 36, 38

modellbezogene Klasse von Systembe-schreibungen, 60

Modellbildung, 36Analyse, 36, 41Synthese, 36, 43

162

Index

Systemanalyse, 36Modellhierarchie, 9Modellierung, 8Modellierungsansatz, 8, 75

Begriffswelt, 8Metamodell, 8

Modellinkonsistenz, 35externe Modellinkonsistenz, 35interne Modellinkonsistenz, 35Konflikt, 87

Modul, 10Modulsicht, 10

Modul, 10Schicht, 10Subsystem, 10

Nachdokumentation, 61Nachricht, 11Nennen, 12nicht formale Konsistenzprüfung, 27nicht ideales Modell, 36, 38nicht-formale Beschreibung, 13nicht-formale Systembeschreibungen,

53Notation, 13notationelle Inkonsistenz, 34

Objekt, 11objektorientierte Analyse (OOA), 11objektorientierte Design (OOD), 11objektorientierte Programmierung

(OOP), 11Objektorientierung

Aggregationsbeziehung, 11Assoziation, 11Attribut, 11Generalisierungsbeziehung, 11Instanz, 11Klasse, 11Kollaboration, 11Nachricht, 11Objekt, 11OOA, 11OOD, 11OOP, 11Operation, 11Vererbungsbeziehung, 11

Zustand (Objekt), 11Offline Konsistenzprüfung, 28Online Konsistenzprüfung, 28Open Coding, 95Operation, 11Opertationszustand, 9

partielle Konsistenzprüfung, 27passive Komponente, 9

Kanal, 9Speicher, 9

Patterns, 44Petrinetz, 15Port, 10Pragmatik, 13primäre Interpretation, 13Produktbeschreibung, 56Prototyping, 44Prozess

Dokumentationerstellungsprozess,70

Dokumentationevolutionsprozess,70

Prozessbedingte Inkonsistenz, 33Prozessbeschreibung, 59

qualitative Analyse, 93Quelldatei, 10Quellen von Inkonsistenzen, 39

Reaktion auf Inkonsistenz, 28Ignorieren, 30Korrigieren, 29Tolerieren, 29Verbessern, 29

Redundanz, 24Richtung von Inkonsistenz, 26Role, 10

Schicht, 10Schichtungsdiagramm, 15Schnelllesetechnik, 68schriftliche Systembeschreibung, 45schriftliche Systembeschreibungen, 48secondary notation, 40sekundäre Interpretation, 13Selective Coding, 95Semantik, 13

163

Index

semantische Inkonsistenz, 34semi-formale Beschreibung, 14semi-formale Systembeschreibungen,

53Sicht

Konfigurationsmanagementsicht,10

konzeptionelle Sicht, 10Modulsicht, 10Trägersystemsicht, 10

Skalierbarkeit, 28Softwarefehler, 31Softwaremetrik, 111Speicher, 9sprachbezogene Klasse von Systembe-

schreibungen, 53Sprache, 13Steuerzustand, 9Struktur von Dokumenten

Interdokumentbeziehungen, 64Intradokumentbeziehungen, 64

Strukturvarianz, 9Subsystem, 10Symbol, 12syntaktische Inkonsistenz, 34Syntax, 13Synthese, 36, 43System

informationelles System, 7Systemanalyse, 36Systematische Lesetechnik, 68Systemausschnittsbeziehungen, 9Systembeschreibung, 45

Architekturbeschreibung, 63deklarative Systembeschreibung,

52deskriptive Systembeschreibung,

52Dokumenttypen, 64elektronische Medien, 50empfängerkreisbezogene Klasse

von Systembeschreibungen, 53externer Empfängerkreis, 54formale Systembeschreibung, 52interner Empfängerkreis, 54Konzeptbeschreibung, 58

Konzeptdokument, 63mündliche Systembeschreibung,

45, 48maschineller Empfängerkreis, 54medienbezogene Klasse von Sys-

tembeschreibung, 50menschlicher Empfängerkreis, 54modellbezogene Klasse von Sys-

tembeschreibungen, 60nicht-formale Systembeschreibung,

53Produktbeschreibung, 56Prozessbeschreibung, 59schriftliche Systembeschreibung,

45, 48semi-formale Systembeschreibung,

53sprachbezogene Klasse von Sys-

tembeschreibungen, 53technische Systembeschreibung, 57zweck- bzw. interessenbezogene


SystemmodellBeschreibung, 12ideales Systemmodell, 8Modellbildung, 36nicht ideales Modell, 38

task-oriented approach, 71technische Systembeschreibung, 57

Designbeschreibung, 58Konzeptbeschreibung, 58

Tolerieren von Inkonsistenz, 29Top-Down Lesetechnik, 67Trägersystemelement, 10Trägersystemsicht, 10

Trägersystemelement, 10Typ, 14

Übergangsintervall, 25UML, 16Umschreiben, 12unbemerkte Inkonsistenz, 21ungewollte Inkonsistenz, 22Unified Modeling Language, 16Unverständlichkeitsproblem, 13

164

Index

Verbesserung von Inkonsistenz, 29Verbinder, 10Vereinbarkeitskriterium, 21Vererbungsbeziehung, 11Verfolgbarkeit, 24Verhaltensinkonsistenz, 31Versehen, 22Versionisierung von Dokumenten, 74vertikale Lesetechnik, 69vollständige Konsistenzprüfung, 27Vollständigkeit, 25vorgabenbedingte Inkonsistenz, 33

Werkzeugbedingte Inkonsistenz, 34Wertebereichsdiagramm, 15Wertebereichsstruktur, 9Widerspruch, 20

Zeigen, 12Zustand (Objekt), 11Zustandsdiagramm, 15zweck- bzw. interessenbezogene Klasse

von Systembeschreibungen, 55Designbeschreibung, 58Konzeptbeschreibung, 58Produktbeschreibung, 56Prozessbeschreibung, 59technische Systembeschreibung, 57

165

Index

166

Anhang A

Einzelfallanalysen

Im Folgenden werden die Einzelfallanalysen der im Rahmen dieser Arbeit durch-geführten Studie, siehe Kapitel 5, vorgestellt. Zusammenfassend sind die Projektein Tabelle 5.1 (siehe Seite 97) dargestellt. Die Projekte werden einzeln vorgestelltund analysiert. Die Struktur der Auswertung ist bei allen Projekten identischund gliedert sich in: Übersicht, Prozess der Dokumentationserstellung, Konsis-tenzprüfung, Inkonsistenzbewertung und sonstige Eigenschaften. Alle Projekt-partner erlaubten die Auswertung der Fallstudien ausschließlich unter der Be-dingung, die Ergebnisse und die Beschreibungen der einzelnen Fallstudien inanonymisierter Form wiederzugeben.

A.1 Projekt 1

Übersicht. Das erste Projekt bestand aus zwei Teilprojekten, die zu einer un-ternehmensweiten internen Untersuchung eines großen internationalen auf En-terprise Resource Planning Systeme spezialisierte Unternehmens zur verteiltenEntwicklung gehörten. Ziel der unternehmensweiten Untersuchung war, Verbes-serungsmöglichkeiten für eine verteilte Entwicklung durch die Analyse bereitsexistierender Prozesse zu finden. Darunter fielen Werkzeugunterstützung für ei-ne verteilte Entwicklung, aber auch die Dokumentation von Konzepten, um diesean Mitarbeiter an anderen geographischen Standorten weitergeben zu können. Inden zwei Teilprojekten sollte der Dokumentationsaspekt untersucht werden. Beibeiden sollte an einem Ort durch eine kleine Gruppe von Mitarbeitern das ent-sprechende Konzept ausgearbeitet werden und von jeweils einer anderen Grup-pe von Mitarbeitern umgesetzt werden. In einem Teilprojekt sollte überprüft wer-den, inwiefern die Dokumentation des Konzepts bei der Synthese einer verteiltenEntwicklung hilfreich ist. In dem anderen Teilprojekt sollten vornehmlich bereitsexistierende Konzepte festgehalten werden, um die Kommunikation zwischenden Entwicklern an den verschiedenen Standorten zu verbessern. Das Festhaltender Konzepte sollte durch externe Mitarbeiter geschehen, um Unterstützung imBereich Modellierung von Systemen zu erfahren.

167

Kapitel A. Einzelfallanalysen

Für das erste Teilprojekt wurde der Konzeptentwurf an einem Standort für einneues System begleitet. Es nahmen insgesamt sechs Personen daran teil. Vierwaren Mitarbeiter, die die Konzepte entwarfen. Sie hielten einige wichtige De-signentscheidungen in Form von UML Klassen- und Sequenzdiagrammen fest.Zusätzlich wurden von zwei externen Mitarbeitern die Konzepte in Form vonFMC Diagrammen beschrieben. Alle Beschreibungen wurden den Mitarbeitern,die die Umsetzung durchführen sollten, zur Verfügung gestellt. Im Rahmen die-ses Vorgehens wurden Konsistenzprüfungen bei der Erstellung und Verwendungdurchgeführt.

Im zweiten Teilprojekt wurde das bestehende System analysiert und die Ergeb-nisse wurden in Form von FMC Diagrammen niedergelegt. Der Fokus lag hierbeiauf dem Kernstück des Systems ohne die Darstellungsanteile. Das Kernstück desSystems wurde in der Unternehmenszentrale entwickelt. Die Oberflächenanteile,die auf dem Kernstück des Systems basieren, wurden von Mitarbeitern an ei-nem anderen Standort entwickelt. Die Analyseergebnisse sollten allen beteiligtenMitarbeitern zur Verfügung gestellt werden. Auch hierbei wurden Konsistenz-prüfungen durchgeführt.

Bei beiden Teilprojekten wurden die Informationen hauptsächlich durch Inter-views gesammelt. Beim zweiten Teilprojekt wurden zusätzlich das System undbereits existierende Unterlagen zu Hilfe genommen. Der Quelltext wurde beimzweiten Teilprojekt nicht verwendet, da dessen Untersuchung als zu zeitinten-siv angesehen wurde. Es sollten in möglichst kurzer Zeit qualitativ hochwertigeErgebnisse erzielt werden.

Prozess der Dokumentationserstellung. Zu Beginn des Projekts wurde einWorkshop durchgeführt, um die Ziele der Dokumentation zu definieren undeinen Überblick über die Teilprojekte zu gewinnen. Die Beschreibungen solltendie verteilte Entwicklung unterstützen. Sie sollten leicht verständlich sein unddie Einarbeitungszeit in das jeweilige System deutlich verkürzen. Im Rahmender unternehmensweiten Untersuchung sollten Konzeptbeschreibungen mit mi-nimalen textuellen Beschreibungen angefertigt werden. Daher standen Diagram-me im Vordergrund. Der unternehmensweit vorgeschriebene Prozess machte da-zu keine Vorgaben. Die Erstellung der FMC Diagramme zur Erläuterung derKonzepte wurde durch die externen Mitarbeiter durchgeführt. Hauptsächlichwurden dazu die Beteiligten der Teilprojekte interviewt. Zusätzlich wurden exis-tierende Unterlagen einbezogen.

Im ersten Teilprojekt, bei der eine Synthese angestrebt wurde, wurde begleitendversucht, Diagramme mitzuskizzieren. Die Skizzen wurden danach überarbeitet,mit den Beteiligten besprochen und anschließend zur Überprüfung zur Verfü-gung gestellt. Nach Fertigstellung des Konzepts sollte der technische Projektma-nager den beteiligten Mitarbeitern am anderen Standort die Konzepte mit Hilfeder Diagramme erläutern. Dazu fertigte er entsprechende Unterlagen an. Wäh-rend der Interviews wurden teilweise Skizzen angefertigt, die direkt besprochenwurden. Dabei führten Skizzierende und Interviewpartner Konsistenzprüfungen

168

A.1. Projekt 1

durch. Dadurch konnten Modellinkonsistenzen schon bei der Erstellung aufge-deckt und behoben werden.

Das Vorgehen im zweiten Teilprojekt unterschied sich aufgrund der Analysetä-tigkeit. Nach der Phase der Informationssammlung durch Interviews und dieAnwendung des Systems wurden die entsprechenden Diagramme ausgearbei-tet und mit den jeweilig spezialisierten Mitarbeitern durch einen Fragenkatalogüberprüft. Anschließend wurden die Ergebnisse in Form einer Präsentation vor-gestellt, bei dem die Mitarbeiter abschließend die Möglichkeit hatten auf Inkon-sistenzen hinzuweisen.

Für die Erstellung der Dokumente in dieser Form standen keine Vorlagen zurVerfügung, da der unternehmensweite Prozess dies nicht vorsah. Dies wurdevon den Projektbeteiligten als unwichtig eingestuft. Die Dokumente wurdenmit Werkzeugen wie Microsoft PowerPointTM, Microsoft WordTM und Micro-soft VisioTM erstellt. Zusätzlich kam bei designnahen Dokumenten noch RationalRoseTM zum Einsatz. Alle erstellten Diagramme und die dazugehörigen Präsen-tationstexte wurde in englischer Sprache verfasst, da die Mitarbeiter des Unter-nehmens auf viele internationale Standorte verteilt sind. Aufgrund dessen ist dieenglische Sprache vom Unternehmen als Dokumentationssprache vorgegeben.

Konsistenzprüfung. Zur Aufdeckung syntaktischer Inkonsistenzen wendetendie Ersteller der Diagramme die entsprechenden verfügbaren Werkzeuge, hier ei-ne Rechtschreib- und Grammatiküberprüfung, an. Aus Mangel an Vorgaben wur-de nicht nach vorgabenbedingte Inkonsistenzen überprüft. Zufällig aufgedeckteInkonsistenzen in den durch maschinengestützte Werkzeuge erstellten Diagram-me wurden in der Regel behoben.

Im ersten Teilprojekt wurden die Diagramme entwicklungs- und interviewbe-gleitend erstellt und von den Verantwortlichen schon während der Erstellungüberprüft. Die dabei entdeckten Modellinkonsistenzen basierten hauptsächlichauf dem fehlenden Domänenwissen der externen Mitarbeiter. Schon bei der Skiz-zierung der Diagramme bemerkten die externen Mitarbeiter Lücken in ihren Mo-dellen, so dass schon dabei interne Modellinkonsistenzen auffielen. Nach derÜberarbeitung der Modell und der Diagramme wurden Hypothesen und An-tithesen aufgestellt. Daraus wurden Fragen abgeleitet. Im Anschluss wurden dieMitarbeiter mit Hilfe dieser Fragen interviewt, um die Modelle und Diagrammeauf Modellinkonsistenzen zu überprüfen.

Im zweiten Teilprojekt wurden auf Basis von Fragenkatalogen zur Aufdeckungvon Modellinkonsistenzen gezielt spezialisierte Mitarbeiter interviewt. Weiterhinkonnten die Modelle durch das System teilweise validiert werden.

Bei der Vorstellung der Diagramme bzw. der Präsentationen wurden von denEmpfängern keine offensichtlichen Techniken zur Konsistenzprüfung angewen-det. Alle Kommentare und Fragen bezogen sich direkt auf die Modelle und lie-ßen notationelle und vorgabenbedingte Inkonsistenzen unbeachtet. Der Fokusbei der Konsistenzprüfung lag folglich auf Modellinkonsistenzen. Es fanden Ad-hoc-Techniken Anwendung, da kein konkretes Vorgehen beobachtbar war. Das

169


vorhandene Wissen wurde durch die spezialisierten Mitarbeiter mit dem Vorge-stellten verglichen.

Im ersten Teilprojekt wurden die Diagramme entwicklungs- und interviewbe-gleitend erstellt und von den Verantwortlichen schon während der Erstellungüberprüft. Da die Diagramme skizziert wurden, blieb eine Prüfung auf notatio-nelle und vorgabenbedingte Konsistenz aus. Die Interviewpartner bzw. die ander Entwicklung beteiligten Mitarbeiter blieben in der passiven Rolle und beant-worteten eher Fragen als sich die Skizzen genau anzusehen und zu überprüfen.Erst die von den externen Mitarbeitern als final deklarierten Diagramme wurdengenaueren Prüfungen unterzogen. Dabei wurden keine Inkonsistenzen von denMitarbeitern festgestellt.

Beim zweiten Teilprojekt wurde dies durch Abgleich bestehenden Wissens undPlausibilität durchgeführt. So waren teilweise Fragen oder Kommentare auf an-ders lautende Bezeichnungen zurückzuführen. An anderen Stellen wurden di-rekte Zusammenhänge zwischen dem Arbeitsgebiet des Fragenden und dem Ar-beitsgebiet seines Kollegen in Frage gestellt. Nach kurzer Diskussion konntendiese Fragen geklärt werden. Die Fragen waren zu detailliert, um von den exter-nen Mitarbeiter beantwortet werden zu können. Von den übrigen teilnehmendenMitarbeitern konnten diese Fragen zu Beginn nicht nachvollzogen werden, daauch sie die Details nicht genügend kannten.

Inkonsistenzbewertung. Bei beiden Teilprojekten wurden keine vorher verein-barten Kriterien zur Bewertung von Inkonsistenzen angewendet. Von den Erstel-lern und Empfängern der Skizzen im ersten Teilprojekt wurden notationellenund vorgabenbedingten Inkonsistenzen keine Beachtung geschenkt. Dies hingmit den Skizzen zusammen, die in sehr kurzer Zeit zusammengestellt wurdenund daher keinen Anspruch auf solche Konsistenzen hatte. Die Ersteller der Dia-gramme überprüften sie in beiden Teilprojekten auf notationelle Inkonsistenzen.Bei keinem der Teilprojekte legten die Empfänger Wert auf notationelle und vor-gabenbedingte Inkonsistenzen.

Der Fokus lag auf Modellinkonsistenzen. Im ersten Teilprojekt hatten die Erstell-ter der Diagramme, die externen Mitarbeiter, mit dem fehlenden Domänenwissenzu kämpfen, welches sie für qualitativ hochwertige Diagramme voraussetzten.Daher wurden die entsprechenden Mitarbeiter zur Domäne befragt, bis das Ver-ständnis der externen Mitarbeiter nach eigener Einschätzung ausreichend war.Die Mitarbeiter hatten Verständnis dafür und legten großen Wert auf eine fun-dierte Einarbeitung. Ihrer Ansicht nach wäre das Projekt durch fehlendes Do-mänenwissen gefährdet. Bei beiden Projekten wurden alle aufgedeckten Model-linkonsistenzen einzeln besprochen und noch in der Erstellungsphase korrigiert.Nach der Erstellung wurden keine Modellinkonsistenzen mehr aufgedeckt.

Sonstige Eigenschaften. Obwohl beim ersten Teilprojekt UML Diagramme in-tensiv eingesetzt wurden, wurde der Einsatz von FMC Diagrammen nicht alskontraproduktiv angesehen. Vielmehr wurde es als Komplementär verstanden,

170

A.2. Projekt 2

denn mit Hilfe der FMC Diagramme wurden Strukturen explizit gemacht, die zu-vor nicht leicht zu erkennen waren. Genau dies wurde von den Beteiligten auchbeim zweiten Teilprojekt, bei dem es ebenfalls um die Kenntlichmachung derübergeordneten Zusammenhänge ging, als Zeitgewinn angesehen. Das Übertra-gen der Aussagen der FMC Diagramme auf die Aussagen der UML Diagrammeleisteten die Mitarbeiter des ersten Teilprojekts ohne besondere Anstrengungen.Dabei stellten die Mitarbeiter keine Modellinkonsistenzen fest, die entweder dieUML Diagramme oder die FMC Diagramme betroffen hätten.

Weiterhin konnte besonders im ersten Teilprojekt beobachtet werden, dass dieFMC Diagramme während der Entwurfszeit außerordentlich konstant blieben.Nach den ersten Korrekturen der Skizzen blieben die Diagramme trotz teilweisemassiver Änderungen an den UML Diagrammen unverändert. Dies hatte damitzu tun, dass zwar die Datenstrukturen umgestellt wurden, aber der entworfeneAufbau des Systems unangetastet blieb.

A.2 Projekt 2

Übersicht. Projekt 2 wurde mit der Abteilung für Produktionsautomatisierungeines großen internationalen Unternehmens durchgeführt. Dieses Unternehmenentwickelte eine softwarebasierte Lösung zur Automatisierung und Steuerungvon Produktionsanlagen. Ziel des Projekts war die Ausarbeitung eines Konzeptsfür die Zusammenführung dieser Lösung mit dem durch die Übernahme ei-nes Konkurrenzunternehmens erstandenes System. Das eigenentwickelte Systemwurde kurz vor Beginn dieses Projekts fertiggestellt. Das übernommene Konkur-renzsystem existierte bereits einige Jahre zuvor. Beide Systeme können viele wei-tere spezialisierte Einzelsysteme ansprechen und steuern. Die jeweiligen Vorteileder Systeme sollten berücksichtigt werden. Vorgabe des Unternehmens war fürdas neue System die technische Grundlage der Eigenentwicklung zu verwenden,da sie auf einem aktuell technischen Stand war. Das Konkurrenzsystem setzt aufeine nicht mehr unterstützte technische Basis auf, was die Weiterentwicklung er-schwert.

Um dies zu erreichen, wurden die beiden Systeme und die vom Unternehmenausgewählten Industriestandards analysiert. Die Konformität des neuen Systemszu den vorgegebenen etablierten Industriestandards wäre eine weitere Vorgabedes Unternehmens. Besondere Berücksichtigung fand das eigenentwickelte Sys-tem, da dies als technische Grundlage für das neu zu konzipierende System die-nen sollte. Zur Analyse standen die Systeme selbst, Beispielanwendungen unddie jeweiligen Bedienungsanleitungen zur Verfügung. Zusätzlich standen einigeSpezialisten des Unternehmens zu Verfügung, die befragt werden konnten. DieQuelltexte der Systeme durften nicht eingesehen werden. Im Anschluss sollte einneues System konzipiert werden, das alle Vorteile der beiden Systeme vereintund die Ergebnisse schriftlich festgehalten werden. Am Projekt waren 7 Studen-ten beteiligt, die hauptsächlich an der Hochschule und nicht am Standort desUnternehmens arbeiteten. Es wurde auf externe Mitarbeiter zurückgegriffen, da

171


für die Erarbeitung eines zusammenführenden Lösungsansatzes innerhalb desUnternehmens nicht genügend Ressourcen zur Verfügung standen.

Prozess der Dokumentationserstellung. Vor der Erstellung der Dokumentati-on wurden gemeinsam die Ziele des Projekts und der Dokumentation festgelegt.Die Dokumentation sollte es erlauben, die Konzepte relativ schnell zu erfassenund zu verstehen. Außerdem wurde von den Mitarbeitern der Abteilung eineknappe Darstellung der Domäne gegeben. In dieser Abteilung waren keine Vor-gehensweisen für Analysen bekannt. Daher wurden Präsentationen in regelmä-ßigen Abständen eingeplant, um Modellinkonsistenzen möglichst frühzeitig ent-gegen zu wirken. Für die Ausarbeitung des Konzepts für das neue System, dasvorwiegend auf den Analyseergebnissen basieren sollte, wurde ein schriftlichesDokument erwartet. Es sollte auch die Analyseergebnisse beinhalten. Für die Er-stellung der Dokumentation gab es keinen expliziten Prozess. Alle erstellten Do-kumente wurden auf notationelle Inkonsistenzen überprüft. Vor der Weitergabeoder Präsentation überprüften die Ersteller die Unterlagen gegenseitig auf Mo-dellinkonsistenzen. Aufgrund der größeren zeitlichen Abstände zwischen denPräsentationen wurde versucht eine möglichst hohe Qualität zu erzielen und dieZwischenergebnisse direkt in die Abschlussdokumentation einfließen zu lassen.Die Präsentationen waren inhaltlich dem zu erstellenden Dokument identisch.Sie machten den Mitarbeiter der Abteilung den aktuellen Stand sichtbar und er-möglichten ein frühzeitiges Eingreifen. In dem Dokument sollten die Ergebnis-se der Analyse und die darauf aufbauende Neukonzeption beschrieben werden.Diese wurde von den Mitarbeitern des Unternehmens kurz vor Fertigstellungüberprüft.

Für diese Form der Beschreibung existierten keine Vorlagen des Unternehmens.Dies wurde offenbar von den Mitarbeiter der Abteilung als nicht wichtig einge-stuft. Die externen Mitarbeiter verwendeten neben schriftlichen Beschreibungenauch Diagramme in der Fundamental Modeling Concepts (FMC) und UnifiedModeling Language (UML) Notation sowie Abbildungen der grafischen Ober-fläche und Ad-hoc-Diagramme. Die Verwendung der Ad-hoc-Notation ging aufbereits bestehende Abbildungen zurück und sollte den Bedarf an einer einheitli-chen Notation in der Domäne verdeutlichen.

Als Unterstützung wurden hauptsächlich Microsoft WordTM, MicrosoftPowerPointTM und Microsoft VisioTM als Werkzeuge verwendet. Da auchdie Bedienung des neu zu konzeptionierenden Systems Bestandteil der Aufgabewar, wurde für die Vorschau der grafischen Benutzerschnittstellen eine Ent-wicklungsumgebung verwendet. Sie ermöglichte eine realistische Vorschau mitverhältnismäßig geringerem Aufwand als die Verwendung eines allgemeinenZeichenwerkzeugs. Das entstandene Dokument wurde in englischer Spracheverfasst, um der Internationalität des Unternehmens gerecht zu werden.

Konsistenzprüfung. Von den Erstellern der Dokumentation wurden von Be-ginn der Erstellungsphase an Konsistenzprüfungen durchgeführt. Im Fokus la-

172

A.2. Projekt 2

gen zunächst Modellinkonsistenzen. Dies galt für die Modellbildung in der Ana-lysephase wie auch in der Synthesephase. Die Modellkonsistenzprüfungen folg-ten keinem konkreten Vorgehen, sondern waren Plausibilitätsüberprüfungen.Dies wurde durch das fehlende Verständnis der Domäne offensichtlich. Alle Be-mühungen um die Analyse und Synthese wurden eingestellt, bis die Domäneausreichend plausibel wurde. Erst im Anschluss wurde mit der Analyse der zweiSysteme und dann mit der Synthesearbeit begonnen. Die jeweils gewonnen Zwi-schenergebnisse wurden zur Überprüfung den anderen Beteiligten zunächst in-tern vorgestellt. In der Regel wurde mit Hilfe der Diagramme, versucht die Mo-delle verbal zu erläutern. Notationelle und andere vorgabenbedingte Inkonsis-tenzen blieben im Gegensatz zu vornehmlich internen Modellinkonsistenzen un-beachtet. Mit Hilfe der Kommentare der Empfänger wurden die Erläuterungenund Diagramm überarbeitet. Unvollständigkeiten wurden von den Erstellern derUnterlagen durch Erläuterungen gekennzeichnet. Die überarbeitete Version derUnterlagen wurde dann den Mitarbeitern der Abteilung vorgestellt. Diese wur-den zuvor von den Erstellern auf notationelle Inkonsistenzen überprüft. Im Falleder Rechtschreibung wurden auf die von den verwendeten Werkzeugen ange-botenen Möglichkeiten zurückgegriffen. Die Diagramme hingegen wurden ma-nuellen Konsistenzprüfungen unterzogen. Dabei wurde ohne Checklisten oderähnliches gearbeitet. Hin und wieder wurden zufällig Inkonsistenzen bemerkt,die meistens sofort behoben wurden.

Die Mitarbeiter der Abteilung wendeten während der Vorstellung der Zwischen-ergebnisse keine offensichtlichen Techniken zur Konsistenzprüfung an. Auf no-tationelle und vorgabenbedingte Inkonsistenzen wurde offensichtlich kein Wertgelegt, da alle Kommentare und Fragen sich direkt auf die Modelle bezogen. Diespezialisierten Mitarbeiter verglichen dabei die Ergebnisse mit ihrem Wissen-stand. Andere Mitarbeiter führten Plausibilitätsprüfungen durch. Auffällig warauch, dass das Interesse der Mitarbeiter an den Analyseergebnisse nicht sonder-lich hoch war. Ein System wurde von ihnen selbst erstellt, das Konkurrenzsys-tem sollte eingestellt werden. Während der Vorstellung der Zwischenergebnis-se bezüglich des Konzepts der Zusammenführung der beiden Systeme wurdendie meisten Rückfragen gestellt. Häufig waren dies vorweggenommene Fragen,die im Verlauf der Präsentation geklärt worden wären. Die Dokumentation wur-de von den Mitarbeitern der Abteilung vor der Finalisierung überprüft. Dabeiwurden insgesamt zwei Anmerkungen gemacht. Eine war eine semantische In-konsistenz, da ein Begriff verwendet wurde, der im Unternehmen eine andereBedeutung zugeordnet wurde. Die andere Anmerkung betraf eine Unvollstän-digkeit, bei der ein bereits erstelltes Diagramm in modifizierter Form und nichtin der vorher bekannten Form verwendet wurde.

Inkonsistenzbewertung. Das fehlende Domänenwissen zu Beginn des Projektswurde von allen Beteiligten als äußerst kritisch bewertet, da ein weiteres Vorge-hen des Projekts ohne Domänenwissen nicht sinnvoll gewesen wäre. Daher wur-den aufgrund dieser gravierenden Modellinkonsistenzen mehrere Workshopsdurchgeführt, um diesen Missstand zu beseitigen. Der zeitliche Aufwand dafür

173


bedurfte fast der Hälfte der Gesamtprojektdauer. Dies wurde von Seiten des Un-ternehmens akzeptiert und mit der Leitung und Durchführung der Workshopstatkräftig unterstützt. Die bemerkten Inkonsistenzen wurden alle korrigiert, dasie praktisch keinen Aufwand bedeuteten.

Sonstige Eigenschaften. Die Analyseergebnisse der beiden zu untersuchendenSysteme wurden von den Projektbeteiligten, die an der Analyse direkt beteiligtwaren, als nicht sehr zuverlässig eingestuft. Die Analyse basierte hauptsächlichauf der Untersuchung der Systeme durch Interaktion und die entsprechende Be-nutzerdokumentation. Bei vermutlichen Modellinkonsistenzen wurden immerdie Mitarbeiter des Unternehmens befragt. Dies war unter anderem Bestandteilder durchgeführten Workshops. Durch Bestätigungen und Korrekturen wuchsdas Vertrauen in die Analyseergebnisse. Dennoch wurden insgesamt nur wenigeModellinkonsistenzen durch die Mitarbeiter des Unternehmens entdeckt. Mög-licherweise stand die Analyse für das Unternehmen nicht im Mittelpunkt. Den-noch war eine ausreichende Analyse Voraussetzung für das Verständnis der Do-mäne und die Erstellung eines Konzepts für die Integration der beiden Systeme.

Die Phase der Erstellung der finalen Dokumentation nahm in etwa ein Viertel derGesamtprojektdauer ein.

Bei der Installation der zu untersuchenden Systeme gab es einige Auffälligkeiten,die nicht in der Benutzerdokumentation behandelt wurden bzw. davon abweich-ten. Diese Unvollständigkeiten und Inkonsistenzen konnten innerhalb kürzesterZeit durch gezielte Fragen behoben werden.

A.3 Projekt 3

Übersicht. Das Projekt 3 wurde in einem großen internationalen Automobilzu-lieferungsunternehmen durchgeführt, das eingebettete Systeme entwickelt. DieAufgabe bestand darin, das seit mehr als 20 Jahren entwickelte System zu ana-lysieren und die Analyseergebnisse in Form einer Dokumentation als Konzept-beschreibung verfügbar zu machen. Das Unternehmen erhoffte sich davon, dassdie Mitarbeiter ein gemeinsames Verständnis für das System, an dem sie arbeiten,entwickeln. Weiterhin sollte der Einstieg für neue Mitarbeiter erleichtert werden,den internen Richtlinien zur Dokumentation des Konzepts Folge geleistet werdenund eine Basis für eine tiefergehende Umstrukturierung des Systems geschaffenwerden.

Es wurde sich auf die Analyse der Software-Kernkomponenten beschränkt, dievor etwa 7 Jahren komplett umstrukturiert und seitdem weiterentwickelt wur-den. Diese Kernkomponenten machen das Kernsystem aus, das die komplet-te Hauptfunktionalität ohne die Anzeige von Benutzeroberflächen darstellt. DieSoftware ist vollständig in der Programmiersprache C geschrieben und umfasstetwa 260.000 Zeilen Quelltext (Kommentarzeilen nicht mitgezählt). Die Analyse

174

A.3. Projekt 3

sollte von externen Mitarbeitern durchgeführt werden, da nicht genügend Res-sourcen zur Verfügung standen. Am Projekt nahmen 8 Studenten teil. Die Analy-se wurde in einem zweiwöchigen Rhythmus vor Ort beim Unternehmen und ander Hochschule durchgeführt. Für die Analyse während der Aufenthalte an derHochschule durften keine Unterlagen des Unternehmens mitgeführt und somitauch nicht benutzt werden. Diese Zeit diente vorwiegend dazu, die Modelle zufestigen und zu formulieren. Die Aufenthalte beim Unternehmen vor Ort wurdenintensiv für das Sammeln von Informationen genutzt. Dafür standen hauptsäch-lich der Quelltext und als Interviewpartner Entwickler, Architekten und Projekt-leiter zur Verfügung.

Prozess der Dokumentationserstellung. Zu Beginn des Projekts wurden dieZiele der Beschreibung definiert. Die Beschreibung sollte neuen Mitarbeiter einenumfassenden aber leicht verständlichen Überblick über die wichtigsten Struk-turen geben. Um den Einstieg zu erleichtern, wurde von den Mitarbeitern desUnternehmens eine kurze Einführung in die Domäne und des Systems gegeben.Der dokumentierte Entwicklungsprozess oder sonstige Dokumente des Unter-nehmens enthielten keinerlei Vorgaben für eine Analyse. Deshalb wurde als vor-bereitende Maßnahme ein Analysevorgehen ausgearbeitet. Hauptmerkmal desausgearbeiteten Vorgehens für die Analyse – im Zusammenhang mit Inkonsis-tenzen – war eine regelmäßige und in kurzen Abständen wiederkehrende Prä-sentation der Zwischenergebnisse. Dies sollte zum einen eine Kontrollmöglich-keit über den Fortschritt der Analyse bieten, zum anderen Modellinkonsistenzen,also Fehler bei der Analyse, frühzeitig aufdecken. Die Präsentationen sollten denaktuellen Stand wiedergeben. Auf eine besondere Ausarbeitung der Beschreibun-gen (inkl. der Diagramme) wurde kein großer Wert gelegt, da die Nutzung derPräsentationen nur temporär war. Die Erstellung der Dokumentation wurde andas Ende des Projekts gelegt. Dabei sollten die validierten Modelle textuell undgraphisch so umfassend beschrieben werden, dass möglichst keine Fragen offenblieben. Jedes Dokument sollte mittels einer einmaligen Review durch die jewei-ligen Experten des Unternehmens überprüft werden. Nachdem die Korrektur-vorschläge und Anmerkungen in einer letzten Korrektur berücksichtigt wurden,galten die Dokumente als abgeschlossen.

Da für diese Form von Konzeptbeschreibungen keine Dokumentvorlagen derQualitätsabteilung zur Verfügung standen, wurde eine ähnliche Dokumentvorla-ge modifiziert. Die Modifikationen betrafen die Dokumentstruktur und die Wahleiner konkreten Notation, da in der Ursprungsvorlage keinerlei Empfehlungenausgesprochen wurden. Die Fundamental Modeling Concepts (FMC) sollten Ver-wendung finden. Die Dokumentvorlage enthielt daneben noch Vorschläge zurStruktur. Weiterhin sollten Akronyme und Begriffsdefinitionen aufgeführt wer-den.

Zusätzlich wurden diverse Checklisten zu Dokumenten, Präsentationen und Dia-grammen angefertigt, die hauptsächlich vorgabenbedingte Inkonsistenzen undModellinkonsistenzen zum Inhalt hatten. Eintragungen zu notationellen Inkon-sistenzen waren kaum zu finden und betrafen ausschließlich in sehr rudimentä-

175


rer Form die Notation für FMC-Diagramme.

Als Werkzeuge für die Erstellung der Dokumente und für die Präsentationenwurden hauptsächlich Microsoft WordTM, Microsoft PowerPointTM und Micro-soft VisioTM verwendet. Für die Erstellung der Dokumente, ohne Präsentationenund Diagramme, wurde die Verwendung Microsoft WordTM vorgeschrieben. Umeinen größeren Leserkreis ansprechen zu können, wurde die resultierende Doku-mentation, ohne Präsentation, in der englischen Sprache verfasst. Die Dokumen-tation in verschiedenen Formaten erzeugen zu können, wurde nicht gewünscht.

Konsistenzprüfung. Für die Konsistenzprüfung der Beschreibungen durch dieErsteller konnte eine Reihenfolge festgestellt werden. Eine Überprüfung auf Mo-dellinkonsistenzen erfolgte schon vor Beginn der Erstellung der Dokumentewährend der Analysephase. Dies waren Plausibilitätsüberprüfungen. Teilweisewurden die entsprechenden Modelle anderen Beteiligten, die den betreffendenSystemteil nicht kannten, anhand von Skizzen erläutert. Falls dabei keine drin-genden bzw. offensichtlichen Fragen auftraten, wurden das Diagramm und diezugehörigen Erläuterungen als „gut“ bewertet. Eine andere angewandte Technikwar die Prüfung von Hypothesen durch die Befragung der entsprechenden Ex-perten. Teilweise wurden beide Techniken angewandt. Erst unmittelbar bei derErstellung und kurz vor Fertigstellung des Dokuments wurde auf notationelleInkonsistenzen hin überprüft. Dabei kamen maschinengestützte Werkzeuge, wieRechtschreib- und Grammatiküberprüfung, zum Einsatz. Dies wurde von allenBeteiligten routinemäßig durchgeführt. Für die Diagramme stand ebenfalls einautomatischer Konsistenzprüfer (Prüfung notationeller Inkonsistenzen) zur Ver-fügung, der allerdings nicht so exzessiv wie die Rechtschreibüberprüfung an-gewandt wurde. Dies hing damit zusammen, dass der Konsistenzprüfer ein ge-wisses Maß an Disziplin bei der Erstellung der Diagramme erforderte, was alshinderlich bzw. zu aufwendig angesehen wurde. Für die Präsentationen wurdenkeine sonstigen Konsistenzprüfungen durchgeführt. Für die finale Dokumentati-on wurden die Checklisten anfangs berücksichtigt und später vernachlässigt, daaufgrund der vorhergehenden Prüfungen der Analyseergebnisse durch die Prä-sentationen keine Inkonsistenzen mehr gefunden wurden. In den Präsentationenwurden Unvollständigkeiten in den Modellen stets gekennzeichnet. Die Unvoll-ständigkeiten waren auf die noch nicht abgeschlossene Analyse zurückzuführen.Bei der finalen Dokumentation wurden keine Unvollständigkeiten von den Er-stellern als solche gekennzeichnet und identifiziert. Zufällig erkannte Inkonsis-tenzen wurden in der Regel sofort behoben.

Die Empfänger der Beschreibungen wendeten keine offensichtlichen Technikenzur Konsistenzprüfung an. Es muss daher davon ausgegangen werden, dassbei Dokumenten Ad-hoc-Lesetechniken verwendet wurden. Auch dadurch be-dingt, dass keiner der Beteiligten eine entsprechende Ausbildung erhalten hat-te. Da während der Präsentationen die Inhalte im Vordergrund standen, wurdehauptsächlich auf Modellinkonsistenzen hin überprüft. Die Experten erlangtendies durch Abgleich mit dem bereits erlangtem Wissen. Die übrigen Mitarbeiterüberprüften die Plausibilität der vorgestellten Inhalte. Obwohl die Präsentatio-

176

A.3. Projekt 3

nen bereits Hinweise auf die Unvollständigkeiten enthielt, fragten die Empfän-ger dennoch nach nicht beschriebenen Systemteilen. Diese Fragen wurden stetsmit dem Hinweis auf mögliche Modellinkonsistenzen mit dem bruchstückhaftenWissen und Modellen beantwortet. Das Review der erstellten Dokumente durchdie Experten des Unternehmens erwies sich als problematisch. Von den 12 er-stellten Dokumenten wurde lediglich fünf von Personen aus dem Unternehmenüberprüft. Als Begründung dafür wurde Arbeitsüberlastung angegeben. Ledig-lich zwei Dokumente wurden tatsächlich von den jeweiligen Experten überprüft.Die Experten fokussierten auf Modellinkonsistenzen, die berichteten Inkonsis-tenzen bezogen sich hauptsächlich darauf. Mit einer einzigen Ausnahme, der Bit-te um die Einführung einer Zeilennummerierung, um Kommentare leichter denjeweiligen Stellen im Dokument zuordnen zu können. Die Inkonsistenzen wa-ren hauptsächlich auf Synonyme als semantische Inkonsistenz (ein Begriff wur-de für eine softwarebasierte und für eine hardwarebasierte Systemkomponenteverwendet), Fehler (Fehlinterpretation von Quelltext) und ungenaue Klassifika-tionen als interne Modellinkonsistenzen (z.B. ob ein bestimmtes Verfahren zurBestimmung der Fahrzeugposition als Alternative oder Spezialisierung zu be-trachten ist) zurückzuführen. Die übrigen Überprüfungen führte ein Projektleiterdurch, der nicht als Experte für die Inhalte der untersuchten Dokumente einzu-stufen ist. Er entdeckte keine Modellinkonsistenzen, sondern machte hauptsäch-lich auf fehlende Informationen, also auf Unvollständigkeiten, aufmerksam. ZumBeispiel sollten weitere Informationen in nicht anwendbare Teile der Dokument-struktur eingefügt werden. Die restlichen Mängel betrafen vorgabenbedingte In-konsistenzen, wie bestimmte Abkürzungen in das Glossar aufzunehmen. Keinerder Überprüfer gab Hinweise auf notationelle Inkonsistenzen. Es ist davon aus-zugehen, dass dennoch vereinzelt notationelle Inkonsistenzen in den Dokumen-ten enthalten sind.

Inkonsistenzbewertung. Für die Bewertung der gefunden Inkonsistenzenwurden keinerlei näher definierte Kriterien verwendet. Jede einzelne Inkonsis-tenz wurde einzeln besprochen und abgewägt. Bei eindeutigen Modellinkonsis-tenzen wurde der Aufwand zur Behebung abgeschätzt, der in allen Fällen geringwar. Die vorgabenbedingten Inkonsistenzen wurden als nicht kritisch eingestuft,zumal die meisten nicht im inhaltlichen Kontext standen und daher eine Kor-rektur nicht umsetzbar war. Bestimmte vorgabenbedingte Inkonsistenzen, die imZusammenhang mit der modifizierten Vorlage standen, hätten intensive Zusatz-arbeiten bedeutet. Diese wurden nicht durchgeführt, da sie den Rahmen des Pro-jekts deutlich überschritten hätten. Die restlichen vorgabenbedingten Inkonsis-tenzen wurden dennoch zuerst behoben. Die Korrekturen dafür nahmen insge-samt nur wenige Minuten in Anspruch. Wesentlich aufwändiger waren hingegendie Korrekturen bezüglich der Modellinkonsistenzen. Aber auch hier betrafen dieÄnderungen lediglich isolierte Abschnitte in den Dokumenten, die innerhalb vonzwei Tagen eingepflegt wurden.

177


Sonstige Eigenschaften. Für die Projektdauer kann festgestellt werden, dassetwa 1/4 der Zeit für das Modellieren (Informationsbeschaffung und -verarbeitung) und 1/4 der Zeit für das Erstellen von Diagrammen und Präsen-tationen verwendet wurde. Die restliche Zeit wurde für die Erstellung der Do-kumentation benötigt. Während der Modellierung wurde innerhalb der erstendrei Tage festgestellt, dass der zur Verfügung gestellte Quelltext veraltet war.Es wurde aus dem Versionisierungssystem eine falsche Version bezogen. DieseInkonsistenz wurde bemerkt, da ein angesprochener Teil des Systems nicht imzur Verfügung gestellten Text zu finden war. Der Quelltext gab wichtige Infor-mationen, da praktisch keine Dokumentation existierte. Allein ein ca. 30 Jahrealtes Dokument, das das Verfahren für die Berechnung der Route beschreibt, undzwei Diplomarbeiten konnten zu Rate gezogen werden. Diese wurden als sehrhilfreich erachtet. Sonst existierte vorwiegend Marketingmaterial.

Es gab zwar einen zentralen Speicherort für Dokumente aller Art, der aber nichtin einem festen Verantwortungsbereich lag. Vielmehr wurden für bestimmte Per-sonen interessante Dokumente in personenbezogenen Bereichen abgelegt. Ein füralle Benutzer zugänglicher Bereich mit einer allgemeineren Ablagestruktur undeiner Übersicht der vorhandenen Dokumentation war nicht vorhanden.

Während des Projekts arbeiteten zwei externe Dokumentationsbeauftragte an derErstellung von Dokumenten. Ziel war es dabei, sehr detaillierte Informationenfestzuhalten. Dazu erstellten die Dokumentationsbeauftragten Werkzeuge, mitderen Hilfe automatisch Prozeduren und deren Abhängigkeiten extrahiert wur-den. Auf Knopfdruck konnte die Dokumentation so auf Basis des Quelltexts ak-tualisiert werden. Die extrahierten Prozeduren wurden im Anschluss beschrie-ben.

A.4 Projekt 4

Übersicht. Das vierte Projekt wurde in einem großen internationalen Unterneh-men, das hauptsächlich Enterprise Resource Planning Systeme entwickelt, durch-geführt. Ziel des Projekts sollte die Erstellung von Vorgaben für eine einheitli-che und verständliche Beschreibung der wichtigsten und am häufigsten wieder-zuverwendenden Komponenten des Systems sein. Anschließend sollten für dieidentifizierten Komponenten verbesserte und einheitliche Schnittstellen eingear-beitet werden, um die Wiederverwendung der Komponenten zu fördern. Umdies zu erreichen, sollte anhand von 8 Komponenten in Zusammenarbeit mit denjeweiligen verantwortlichen Architekten die Beschreibungen gemäß den ausge-arbeiteten Vorgaben erstellt werden. Dadurch sollten die Vorgaben validiert undverbessert werden. Die restlichen Komponenten sollten von den anderen Archi-tekten selbständig durchgeführt werden. Die am Projekt beteiligten Architektensollten Erfahrungen und Verfahrensweise bei der Analyse und Beschreibungenden anderen Architekten weitergeben und beratend zur Seite stehen. Die 8 Kom-ponenten des Systems sollten parallel bearbeitet werden, um die Vorgaben fürdie Beschreibungen möglichst für alle auftretenden Fälle zutreffend zu gestalten.

178

A.4. Projekt 4

Zur Beratung und für die Erstellung dieser Vorgaben wurde ein externes Unter-nehmen engagiert.

Prozess der Dokumentationserstellung. Vor dem Start der Erstellung der Do-kumente wurde das Ziel des Projekts besprochen und festgehalten. Ziel desProjekts war eine Beschreibungsvorgabe für die Erstellung einer knappen undauf das Wesentliche beschränkten aber übersichtlichen und leicht verständlichenBeschreibung von Teilkomponenten zu fertigen. Eine Variante einer Beschrei-bung sollte auf einem größeren Papierbogen Platz finden und einheitlich für dasschnellere Finden von Informationen gestaltet werden. Weiterhin sollte der Ge-danke eine Katalogs verfolgt werden, aus dem ein passendes „Bauteil“ gewähltwerden kann. Im Zentrum der Beschreibungen sollten Diagramme stehen, umdie wichtigsten Strukturen der Komponenten zu visualisieren. Im Unternehmenwaren die Fundamental Modelling Concepts (FMC) als Modellierungsansatz eta-bliert. FMC Diagramme sollten daher dafür verwendet werden. Der dokumen-tierte Entwicklungsprozess enthielt aber keinerlei Vorgaben für eine Analyse undErstellung solcher Beschreibungen. Da das Unternehmen über Mitarbeiter in vie-len verschiedenen internationalen Standorten verfügt, sollten die Beschreibun-gen in englischer Sprache verfasst werden. Als eine zweite Variante der Beschrei-bung sollte ein klassisches Dokument mit identischen Inhalten wie in der erstenVariante dienen. Als Werkzeuge kamen hauptsächlich Microsoft WordTMund Mi-crosoft VisioTM zum Einsatz.

Um das Projekt zu beschleunigen, wurde von den Architekten der betroffenenKomponenten vor Beginn des Projekts eine knappe Beschreibung in Form einerPräsentationen erstellt. Die Architekten verwendeten dazu hauptsächlich FMCAufbaudiagramme oder Ad-hoc-Notationen mit schriftlichen Kommentaren undErgänzungen. Mit diesen Präsentationen sollte die Analysephase für das Bera-tungsunternehmen verkürzt werden und die Vorgaben dadurch präzisiert wer-den. Die initialen Vorgaben wurden in Zusammenarbeit der beiden Unternehmenausgearbeitet. Das externe Unternehmen sollte im Anschluss für die jeweiligen 8Komponenten die Vorgaben beispielhaft umsetzen. Die Zwischenergebnisse desexternen Unternehmens sollten in regelmäßigen Abständen vom internationalenUnternehmen durch Präsentationen überprüft und diskutiert werden. Die ver-antwortlichen Architekten sollten die technische Korrektheit der Aussagen über-prüfen. Die Ergebnisse dieser Überprüfungen sollten eine finale Vorgabe sowieBeispielbeschreibungen liefern. Zur Erarbeitung der Beispielbeschreibungen grif-fen die Mitarbeiter des externen Unternehmens hauptsächlich auf Interviews mitden verantwortlichen Architekten zurück. Die Komponenten in einem System-kontext wurden nur kurz besichtigt. Vorhandene Dokumentation wurde eben-falls nur kurz eingesehen, da diese von den verantwortlichen Architekten als zudetailliert für das Projekt charakterisiert wurden.

Konsistenzprüfung. Die Konsistenzprüfung durch Ersteller und Empfängerlässt sich bei diesem Projekt in zwei Phasen einteilen. Zunächst waren die Ar-chitekten die Ersteller der initialen Beschreibungen in Form von Präsentationen.

179


Die Beteiligten des externen Beratungsunternehmen waren die Empfänger. DieseRollen wurden in der anschließenden zweiten Phase vertauscht.

In der ersten Phase, die zur Vorbereitung diente, erhielten die Mitarbeiter desexternen Unternehmens die schriftlichen Unterlagen zu den Präsentationen derArchitekten. Jede inspizierte Beschreibung enthielt mindestens zwei Diagram-me, die vorwiegend in der Notation für FMC Aufbaudiagramme gehalten waren.Die übrigen Diagramme wurden in Ad-hoc Notationen gezeichnet. Die Mitarbei-ter des externen Unternehmens glichen die Aussagen der schriftlichen Passagenmit den Aussagen der Diagramme ab und versuchten diese jeweils einander zu-zuordnen. Bei allen Unterlagen gelang dies. Beim Lesen der FMC Diagrammewurde festgestellt, dass diese teilweise interne Modellinkonsistenzen enthielten.So waren Diagramme sofort auffällig, die z.B. keinerlei Speicher enthielten oderAkteure mit Bezeichnungen, die keine Hinweise auf die Aufgaben der Akteuregaben. Die Nutzung vieler Abkürzungen ohne Erklärungen erschwerte das Ver-ständnis zusätzlich. Nach notationellen oder anderen vorgabenbedingten Inkon-sistenzen wurde nicht gesucht, da dies nicht als Aufgabe des Beratungsunterneh-mens verstanden wurde. Zu den jeweiligen Unterlagen wurden entsprechendeVerständnisfragen notiert, um für die folgenden Präsentationen durch die Archi-tekten vorbereitet zu sein. Die noch nicht geklärten Verständnisfragen wurdennach der Präsentation mit den Architekten geklärt.

Im Anschluss an die Präsentationen der Architekten wurde festgelegt, die Ausar-beitung der Beispielbeschreibung zunächst auf eine einzige Komponente zu be-schränken. Diese Entscheidung wurde aufgrund von Unstimmigkeiten innerhalbdes Unternehmens bezüglich den Beschreibungsvorgaben und der Fertigstellungeiner Beispielbeschreibung innerhalb kürzester Zeit gefällt.

In der zweite Phase, der Kernphase des Projekts, sollten die Mitarbeiter des ex-ternen Unternehmens die Vorgaben ausarbeiten und eine Komponente tiefer-greifend analysieren, um eine beispielhafte Beschreibung gemäß den Vorgabenzur Verfügung zu stellen. Zur Sammlung von Informationen wurden hauptsäch-lich semi-strukturierte Interviews durchgeführt. Zur Vorbereitung der Interviewswurde ein Fragenkatalog, der aufgrund des Studiums der zur Verfügung gestell-ten Unterlagen erstellt werden konnte, verwendet. Während der Interviews wur-den immer wieder Fragen eingestreut, die das nach und nach entstehende Modellbestätigen oder verwerfen sollten. Danach wurden die ersten Diagramme vonden externen Mitarbeiter erstellt. Diese wurden auf ihre Plausibilität hin über-prüft. Weiterhin wurden sie mit den Protokollen der Interviews verglichen, uminterne Modellinkonsistenzen aufzudecken. Bei der Erstellung der Beschreibungwurden, ausser einer Rechtschreibprüfung, keine weiteren erkennbaren Konsis-tenzprüfungen durchgeführt. Teilweise wurden zufällig Inkonsistenzen erkanntund zumeist direkt behoben. Im Anschluss wurden die Diagramme auf Basis ei-nes Fragenkatalogs, der durch Hypothesen und Antithesen gebildet wurde, mitdem Architekten überprüft. Diese Fragen waren nicht immer direkt inhaltlicherNatur. Eine besonders interessante Frage war die nach der Anzahl der Mitarbeiterfür diese Komponente. Das externe Unternehmen schätzte aufgrund der bishergesammelten Informationen und der daraus entstandenen Modelle die Anzahl

180

A.4. Projekt 4

der Mitarbeiter ab. Die Diskrepanz zwischen der geschätzten und der tatsächli-chen Mitarbeiteranzahl war enorm: ein Faktor von ca. 25. Damit war für die Mit-arbeiter des externen Unternehmens klar, dass wesentliche oder große Teile bis-her von der Analyse nicht abgedeckt wurden. Die Begründung des Architektenfür die Nichterwähnung der restlichen Teile der Komponente lag in der Vorgabeseiner Vorgesetzten ausschließlich stark abstrahierte Informationen weiterzuge-ben, um die Projektzeit zu verkürzen.

Von den weiteren projektverantwortlichen Mitarbeitern des Unternehmens wur-de die Beschreibung sowohl nach den Vorgaben als auch nach den Inhalten über-prüft. Da faktisch keine Kenntnis der Komponente bei den Empfänger vorhan-den war, basierte die Modellkonsistenzprüfung auf Plausibilität. Ergänzend zuden gelesenen Beschreibungen wurden noch einige Fragen an die Mitarbeiter desexternen Unternehmens gestellt, die die Aussagen der Beschreibungen unterstüt-zen sollten. Der Fokus der Konsistenzprüfungen lag bei den Vorgaben selbst, dadies die eigentliche Aufgabe dieses Empfängerkreises war. Zum Einen wurdeüberprüft, ob sich die Beispielbeschreibung an die Vorgaben hält. Dafür wur-de jede Vorgabe mit dem entsprechenden Teil der Beispielbeschreibung vergli-chen. Es wurden hierbei keine Inkonsistenzen festgestellt. Zum Anderen wurdeüberprüft, inwiefern die Vorgaben für diese Komponente geeignet waren. DieVorgaben wurden vielfach aufgrund des Beispiels angepasst und aufgrund vonVerbesserungsideen geändert. Der Architekt der Komponente war hingegen ver-antwortlich für die Überprüfung auf Modellinkonsistenzen. Er verwendete kei-ne offensichtlichen Techniken zur Konsistenzprüfung. Aufgrund der intensivenBefragung der Mitarbeiter des externen Unternehmens im Vorfeld, konnte derArchitekt nicht fündig werden.

Inkonsistenzbewertung. Für die Bewertung der vorgefundenen Inkonsisten-zen wurden keine vorher definierten Kriterien herangezogen. Notationelle In-konsistenzen wurden in keiner der beiden Phasen offenkundig erwähnt und be-sprochen.

In der ersten Phase wurden Modellinkonsistenzen in den Diagrammen entdeckt,die das Verständnis beeinträchtigten. Dies betraf vor allem die Zuordnung vonAufgaben zu den Akteuren in FMC Aufbaudiagrammen durch irreführende Be-zeichnungen und fehlende Speicher. Diese wurden nicht korrigiert, da sie derEinführung der externen Mitarbeiter dienen sollten, die die entsprechenden Un-terlagen neu erstellen sollten.

In der zweiten Phase wurden diese Inkonsistenzen, zumindest für die eine Kom-ponente, im Rahmen dieses Projekts behoben, da aufgrund der gründlicherenModellierung neue Diagramme erstellt wurden. Die finalen Diagramme und Be-schreibungen ähnelten denen der ersten Phase kaum, da in der ersten Beschrei-bung dieser Komponente viele Teile fehlten. Die von den Mitarbeitern des exter-nen Unternehmens entdeckten Unvollständigkeiten in der Beschreibung der Ar-chitekten in der ersten Phase wurden von allen Projektbeteiligten als kritisch ein-gestuft. Es wurden immer wieder Änderungen an den Vorgaben durchgeführt.

181


Da die Änderungen in Zusammenarbeit und nach der Erstellung der Beschrei-bungen erfolgten, wurden die im Nachhinein eingeführten Inkonsistenzen alsnicht kritisch gewertet. Es wurde dennoch darauf geachtet die Vorgaben nichtgänzlich umzustellen, da dies nicht in die Zeitplanung des Projekts gepasst hätte.Vorschläge, die zu drastischen Änderungen und somit zu hohen Zeitaufwändengeführt hätten, wurden nicht weiter verfolgt.

Sonstige Eigenschaften. Während der Ausarbeitung, Diskussion und Anwen-dung der Vorgaben wurden Diagramme ohne zusätzliche textuelle Beschreibungals Dokumentation erwägt. Nach sehr kurzer Zeit wurde klar, dass Dokumenteunter ausschließlicher Verwendung von Diagrammen nicht zweckdienlich gewe-sen wären. Die Nutzer einer solchen Dokumentation hätten ausschließlich auf-grund von Diagrammen nicht schnell genug, falls überhaupt möglich, ein Ver-ständnis ableiten können.

Im Anschluss an dieses Projekt wurden die Anstrengungen paralleler Projekteberücksichtigt und die FMC Wertebereichsdiagramme auf Basis der erzeugtenDaten generiert. Die generierten Diagramme waren detailreicher, was aufgrundder einfacheren Erstellung und Aktualisierung akzeptiert wurde. Die FMC Auf-baudiagramme hingegen wurden von allen Beteiligten als nicht generierbar ein-gestuft. Alle Teile der Beschreibung die sich aus bereits existierenden Datenquel-len generieren lassen konnten, wurden automatisch erzeugt. Als Argument fürdiese Vorgehensweise wurde immer die Zeitersparnis bei der Erstellung und derAktualisierung genannt.

Obwohl bei dieser Beschreibung nicht auf notationelle Inkonsistenzen eingegan-gen wurde, wurden sie – insbesondere semantische Inkonsistenzen – innerhalbdes Projekts berücksichtigt. Schon zu Beginn wurden bestimmte Begriffe defi-niert, die nicht verwendet werden durften, da sie im Unternehmen bereits eineandere Bedeutung hatten. In den Beschreibungen wurden von den Beteiligtenkeine notationelle Inkonsistenzen angemerkt.

182

Date post:	20-Jun-2019
Category:	Documents
Upload:	vuonghanh
View:	217 times
Download:	0 times