Wirtschaftsinformatik: Anwendungsorientierte Einführung [2., völlig neu bearb. und erw. Aufl. Reprint 2018] 9783486791129, 9783486238280

Citation preview

Wirtschaftsinformatik Anwendungsorientierte Einführung

Herausgegeben von

Professor Dr. Walter O. Riemann unter Mitarbeit von Prof. Dr. Manfred Goepel, Prof. Dr. Klaus Kruczynski, Prof. Dr. Dr. Christian-Andreas Schumann, Prof. Dr. Bernd Stöckert, Prof. Dr. Rolf Urban, Prof. Dr. Lothar Wagner, Prof. Dr. Sabine Winkelmann, Prof. Dr. Jürgen F. H. Winkler

2., völlig neu bearbeitete und erweiterte Auflage

R. Oldenbourg Verlag München Wien

Die Deutsche Bibliothek - CIP-Einheitsaufnahme Wirtschaftsinformatik : anwendungsorientierte Einführung hrsg. von Walter O. Riemann. Unter Mitarb. von Manfred Goepel...- 2., völlig neu bearb. und erw. Aufl. - München ; Wien : Oldenbourg, 1996 1. Aufl. u.d.T.: Riemann, Walter O.: Betriebsinformatik ISBN 3-486-23828-0 NE: Riemann, Walter O. [Hrsg.]; Goepel, Manfred

© 1996 R. Oldenbourg Verlag GmbH, München Das Werk einschließlich aller Abbildungen ist urheberrechtlich geschützt. Jede Verwertung außerhalb der Grenzen des Urheberrechtsgesetzes ist ohne Zustimmung des Verlages unzulässig und strafbar. Das gilt insbesondere für Vervielfältigungen, Übersetzungen, Mikroverfilmungen und die Einspeicherung und Bearbeitung in elektronischen Systemen. Gesamtherstellung: R. Oldenbourg Graphische Betriebe GmbH, München ISBN 3-486-23828-0

Vorwort Die vorliegende zweite Auflage der ursprünglichen "Betriebsinformatik", deren Titel der heute üblichen Terminologie entsprechend nun "Wirtschaftsinformatik" lautet, trägt den neueren Entwicklungen und Tendenzen im Bereich der Wirtschaftsinformatik Rechnung. Sie ist aber gegenüber der ersten nicht nur in Details aktualisiert. Wesentliche Änderungen sind: 1 Relativ systemnahe Themen wie Programmierung und physische Datenorganisation werden kürzer behandelt, Fragen des Informationsmanagements, der Modellierung von Informationssystemen, des Einsatzes von Personal Computern im Rahmen der sogenannten "Individuellen Datenverarbeitung" und aktuelle Fragen wie Kommunikation, Multimedia, CASE Tools werden intensiver erörtert. Daraus resultierte eine neue Gesamtgliederung. Das überarbeitete Konzept beruht auf einer Gliederung nach • Informatikgrundlagen (Teil I), • Planung und Gestaltung betrieblicher Informationssysteme (Teil II) und • Individueller Datenverarbeitung mit Hinweisen zu sinnvoller Nutzung und Vermittlung von Systemgrundlagen dazu (Teil III). Teil III hat nicht Lehrbuchcharakter, er ist vielmehr eine Anleitung zur praktischen Arbeit mit PC's für den, der damit noch nicht vertraut ist. 2 Der Autor, nun Herausgeber, konnte mehrere Kollegen zur Mitwirkung gewinnen. Damit wurde • einerseits die Überarbeitung bzw. Aktualisierung auf mehrere Personen verteilt, ohne daß die Autoren den Ehrgeiz hätten, in ihrem jeweiligen Teilgebiet zu sehr in die Tiefe zu gehen, • anderseits erreicht, daß verschiedene Lehr- und Praxiserfahrungen in den Text eingegangen sind Es wurde nicht versucht, Darstellungsweise und Stil der Autoren um jeden Preis zu vereinheitlichen. Ebensowenig wurde verhindert, daß einzelne Themen zum Teil mehrfach, aber unter unterschiedlichen Gesichtspunkten, betrachtet werden. Unverändert geblieben ist die Zielsetzung, das notwendige Wissen anwendungsorientiert und praxisnah, weniger durch grundsätzliche Erörterungen, sondern mehr anhand von Fallbeispielen zu vermitteln. Wirtschafts-Informatik wird mit Schwergewicht auf dem ersten Teil des Wortes interpretiert, die Informatik wird als Instrument zur Lösung oder Unterstützung der Lösung wirtschaftlicher Probleme betrachtet. Adressaten sind Studenten der Wirtschaftswissenschaften, der Informatik sowie Praktiker. Ich danke den Mitautoren für ihre Bereitschaft zu engagierter Mitwirkung und fiir die Einhaltung der eng gesetzten Termine. Insbesondere aber danke ich Frau Andrea Höhlig für Organisation und Verwaltung des Projektes, für Korrekturlesen und für Gestaltung und Aufarbeitung des Textes bis zur druckreifen Vorlage. Walter O. Riemann

IV THEMEN/AUTOREN :

Thema Teil I Informatik-Grundlagen 1 Grundbegriffe 2 Hardware 3 Software 3.1 Betriebssysteme 3.2 Systemnahe Software 3.3 Anwendungssoftware 4 Kommunikation und Rechnerverbundsysteme 5 System-Konfiguration 6 Datenorganisation 6.1 Organisation von Plattendateien 6.2 Datenbanken 6.3 Datenschutz/Datensicherheit 7 Einführung in die Programmierung 7.1 Prozedurale und nichtprozedurale Programmierung 7.2 Objektorientierte Programmierung 7.3 Programmentwicklung 8 Multimedia Teil II Betriebliche Informationssysteme 1 Grundlagen 2 Architektur 3 Software Engineering 3.1 Systemplanung 3.2 Vorgangskettenanalyse 3.3 Datenmodellierung 3.4 Funktionsmodellierung 3.5 Prozeßmodellierung 3.6 Objektorientierte Modellierung 3.7 EDV-gestützte Vorgehensmodelle und SoftwareWerkzeuge 4 Informationsmanagement Teil III: Individuelle Datenverarbeitung/persönliche Nutzung von PC's 1 Systemgrundlagen 2 Selbständiger Einsatz (Stand Alone) 3 Einsatz in Verbundsystemen

Autor Wagner Schumann -

Urban Urban Riemann Winkelmann Kruczynski -

Riemann Wagner Winkelmann -

Winkelmann Winkler Winkelmann Schumann

Riemann Stockert -

Riemann Stockei! Riemann Goepel Stöckert Winkler Riemann Riemann

Urban Riemann Urban

V Autoren: Prof. Dr. Manfred Goepel, Hochschule für Technik und Wirtschaft Zwickau, Fachbereich Physikalische Technik/Informatik, Lehrgebiet Wirtschaftsinformatik Prof. Dr. Klaus Kruczynski, Hochschule für Technik, Wirtschaft und Kultur Leipzig, Fachbereich Wirtschaftswissenschaften, Lehrgebiet Wirtschaftsinformatik Prof. Dr. Walter O. Riemann, Hochschule für Technik und Wirtschaft Zwickau, Fachbereich Wirtschaftswissenschaften, Lehrgebiet Wirtschaftsinformatik Prof. Dr. Dr. Christian-Andreas Schumann, Hochschule für Technik und Wirtschaft Zwickau, Fachbereich Wirtschaftswissenschaften, Lehrgebiet Wirtschaftsinformatik Prof. Dr. Bernd Stöckert, Technische Universität Chemnitz, Fakultät für Wirtschaftswissenschaften, Lehrstuhl Wirtschaftsinformatik Prof. Dr. Rolf Urban, Hochschule für Technik und Wirtschaft Zwickau, Fachbereich Physikalische Technik/Informatik, Lehrgebiet Betriebssysteme Prof. Dr. Lothar Wagner, Hochschule für Technik und Wirtschaft Zwickau, Fachbereich Wirtschaftswissenschaften, Lehrgebiet Wirtschaftsinformatik Prof. Dr. Sabine Winkelmann, Hochschule für Technik und Wirtschaft Zwickau, Fachbereich Wirtschaftswissenschaften, Lehrgebiet Wirtschaftsinformatik Prof. Dr. Jürgen F. H. Winkler, Friedrich-Schiller-Universität Jena, Fakultät für Mathematik und Informatik, Institut für Informatik, Lehrstuhl Softwaretechnik

VI

Inhalt TEIL I INFORMATIK GRUNDLAGEN

1

1.

GRUNDBEGRIFFE

1

1.1 1.2 1.2.1

Wirtschaftsinformatik - Begriff und Gegenstand Information, Kommunikation und Codierung Erfordernisse des Informationsaustauschs im RIS als MenschMaschine-System Informationsaustausch zwischen Mensch und Computer Nutzung von Zahlensystemen...! Dualsystem Dezimalsystem Komma- und Vorzeichendarstellung Hexadezimalsystem Interne Datendarstellung und Datenformate Das Byte Das Wort

1 4

1.2.2 1.2.3 1.2.3.1 1.2.3.2 1.2.3.3. 1.2.3.4 1.2.4 1.2.4.1 1.2.4.2

4 5 8 11 12 12 13 14 15 15

2

HARDWARE

17

2.1 2.2 2.2.1 2.2.2 2.2.3 2.2.4 2.2.5 2.2.6 2.2.7 2.3 2.3.1 2.3.2 2.3.3 2.3.4 2.3.5 2.4 2.4.1 2.4.2 2.4.3 2.4.4 2.4.5 2.5

Bedeutung der Hardware Hardwarearchitektur Grundaufbau Rechnerarchitektur Chips Prozessoren Speicherbausteine Busse Schnittstellen Hardwareperipherie Klassifizierung Eingabe Speicherung Ausgabe Übertragung Rechnerklassen Übersicht Großrechner Mittlere Systeme und Workstations Personalcomputer Portables Auswahl der Hardware

17 18 18 19 23 25 28 29 31 33 33 34 37 41 45 47 47 49 51 52 53 54

3.

SOFTWARE

55

3.1 3.1.1 3.1.2 3.1.3 3.1.4

Betriebssysteme Was ist ein Betriebssystem? Die Aufgaben eines Betriebssystems Einige Grundbegriffe Betriebsart und Nutzungsform

55 55 57 59 60

VII 3.1.4.1 3.1.4.2 3.1.4.3 3.1.4.4 3.1.5 3.1.6 3.1.6.1 3.1.6.2. 3.1.6.3 3.1.6.4 3.1.6.5 3.1.6.6 3.2 3.2.1. 3.2.2 3.3

Ein-oder Mehrprozeßbetrieb Stapel- oder Dialogbetrieb Mehrnutzerbetrieb Mehrprozessor- und Netzbetriebssysteme Struktur von Betriebssystemen Charakteristik von Betriebssystem Betriebssysteme für Großrechner Betriebssysteme der Mini-Rechner-Stmkturen Die UNIX-Welt PC-Betriebssysteme: MS-DOS Im Kampf um die DOS-Nachfolge: MS - Windows und OS/2 Ausblick: Betriebssysteme mit neuen Eigenschaften Systemnahe Software Dienstprogramme Übersetzungsprogramme Anwendungssoftware

60 62 64 64 65 67 67 71 71 75 77 78 79 79 81 85

4

KOMMUNIKATION UND RECHNERVERBUNDSYSTEME

4.1 4.2 4.3 4.4 4.5

Anliegen und Grundbegriffe Kommunikationsdienste im Überblick Online-Informationsdienste Architekturstandards von Rechnernetzen Realisierungen von Rechnernetzen

87 89 92 99 105

87

5

SYSTEM-KONFIGURATION

112

5.1 5.1.1 5.1.2 5.1.3 5.1.4 5.2 5.2.1 5.2.2

Konfiguration der Komponenten eines DV-Anwendungssystems ..112 Grundlagen des Konfigurierens 112 Hardware-Konfiguration 114 Software-Konfiguration 116 Darstellungstechniken 117 Gesamtsysteme 119 Netz-Konfiguration 119 Zusammenfassendes Beispiel 122

6

DATENORGANISATION

124

6.1 6.1.1 6.1.2 6.1.3 6.1.4 6.1.4.1 6.1.4.2 6.1.5 6.1.5.1 6.1.5.2 6.1.5.3 6.1.6 6.1.7 6.1.8 6.2 6.2.1

Organisation von Plattendateien Datenhierarchie Verwaltungs- und Verarbeitungsfunktionen Sequentielle Datei Random Datei Direkte Datei Hash-Datei Datei mit Index Einstufiger, linearer Index Index-sequentielle Datei Index als B-Baum Adreßverkettung in Dateien Invertierte Datei Entscheidungskriterien zur Dateiorganisation Datenbanken Begriff und Konzept

124 124 126 127 128 129 130 131 131 133 137 142 145 145 147 147

VIII 6.2.2 6.2.3 6.2.3.1 6.2.3.2 6.2.3.3 6.2.3.4 6.2.3.5 6.2.4 6.2.4.1 6.2.4.2 6.2.4.3 6.2.4.4 6.2.4.5 6.2.4.6 6.2.4.7 6.2.5 6.2.5.1 6.2.5.2 6.2.5.3 6.2.5.4 6.2.5.5 6.2.6 6.3 6.3.1 6.3.2 6.3.3 6.3.4 6.3.4.1 6.3.4.2 6.3.4.3 6.3.5 6.3.6

Architektur von Datenbanksystemen Logische Datenbankorganisation Das semantische Datenmodell..: Das hierarchische Datenmodell Das Netzwerkmodell Das relationale Modell Objektorientierte Datenbanken Die Aufgaben des Datenbankverwaltungssystems (DBMS - Data Base Management System) Zugriffsvermittlung Datenbeschreibung Transaktionssicherung und Wiederanlauf. Integritätssicherung Konsistenzsicherung Zugriffssicherung Dienstfunktionen Datenbank-Entwurf (Datenbank-Design) Anforderungsanalyse Konzeptioneller Entwurf Logischer Entwurf. Physischer Entwurf Implementierung Datenbanksprache SQL Datenschutz und Datensicherheit Anliegen von Datenschutz/Datensicherheit Rechtsgrundlagen des Umgangs mit Daten Normung und Prüfung der Computersicherheit Datensicherheit im Unternehmen Hauptziele Ursachen für Defizite Betriebliche Datensicherheitsstrategie Verschlüsselung und Sicherheit in Rechnernetzen Maßnahmen zur Abwehr von Software-Manipulationen, z. B. durch Computer-Viren

150 152 153 154 155 156 157 158 159 161 161 162 164 164 165 165 167 168 169 169 170 170 176 176 179 181 183 183 183 184 190 193

7

EINFÜHRUNG IN DIE PROGRAMMIERUNG

199

7.1 7.1.1 7.1.1.1 7.1.1.2 7.1.1.3 7.1.1.4 7.1.2 7.1.2.1 7.1.2.2 7.1.2.3 7.1.3 7.2 7.2.1

Prozedurale und nichtprozedurale Programmierung Rolle von Algorithmen Was ist programmieren Optimierung von Algorithmen Bewertung wichtiger Algorithmen Quicksort als rekursiver Algorithmus Strukturelemente von Algorithmen Prinzip der strukturierten Programmierung Elemente einer Programmiersprache Kontrollstrukturen (Steuerkonstrukte) Prozedurale versus nichtprozedurale Programmierung Objektorientierte Programmierung Modellierungs- und Realisierungsebene

199 200 200 201 202 203 205 205 205 206 211 213 213

IX 7.2.1.1 7.2.1.2 7.2.1.3 7.2.2 7.2.2.1 7.2.2.2 7.2.2.3 7.2.3 7.2.3.1 7.2.3.2 7.2.3.3 7.2.3.4 7.2.3.5 7.2.3.6 7.2.3.7 7.2.3.8 7.2.3.9 7.2.3.10 7.2.3.11 7.2.3.12 7.2.3.13 7.2.3.14 7.2.3.15 7.2.3.16 7.3 7.3.1 7.3.2 7.3.3

Entwicklungsschritte Modellieningsebene Realisieningsebene Grundlagen der Objektorientierung Entstehung der Objektorientierung Charakteristika der Strukturierten Software Charakteristika der Objektorientierten Software Objektorientierung auf der Realisierungsebene Objekt Öffentliche und interne Komponenten Objektrumpf und Datenkapselung Objekttyp / Klasse Konkrete Programmbeispiele Allgemeinheit des Ansatzes Ableitung / Typerweiterung / Vererbung Ableitungsklausel und Erweiterung Mehrfachableitung Reimplementierung / Modifikation Basistyp als Zusammenfassung von gemeinsamen Komponenten Polymorphismus Polymorphismus und Reimplementierung Dynamische Typabfrage Benutzungsbeziehung Merkmale der Objektorientierung auf Realisierungsebene Programmentwicklung Zustandekommen lauffahiger Programme Modularisierung von Programmen Testen von Programmen

213 213 214 214 214 216 216 217 217 218 219 220 222 224 224 225 226 226 . 228 229 231 232 232 234 234 234 235 236

8

MULTIMEDIA

239

8.1 8.2 8.2.1 8.2.2 8.2.3 8.3 8.3.1 8.3.2 8.3.3 8.3.4 8.4 8.4.1 8.4.2 8.5

Einführung Multimediasysteme Definition und Inhalt Bedarf und Einsatzfelder Basistechnik und -technologien Multimediaentwicklung und Einsatz Vorgehensmodell Planung Realisierung Controlling Beispiel einer Multimedia-Anwendung Objektbeschreibung und Anwendungsziele Entwicklung und Einsatz Multimediatrends

239 240 240 243 245 250 250 251 253 254 255 255 257 259

TEIL II BETRIEBLICHE INFORMATIONSSYSTEME

261

1

GRUNDLAGEN

261

1.1

Systeme

261

X 1.1.1 1.1.2 1.1.3 1.1.4 1.1.5 1.2 1.3 1.3.1 1.3.2 1.3.3

Begriff und Eigenschaften Regelung Modelle Zweck der Modellbildung / Vorgehensweise Instrumente der Modellierung Der Betrieb als System Das betriebliche Informationssystem Einbindung und Gliederung Integration Sichten von Informationssystemen

261 263 266 268 268 270 271 271 276 280

2.

ARCHITEKTUR

281

2.1 2.2 2.3

Konzepte Das ARIS-Konzept von Scheer ARIS-Informationsmodell

281 282 286

3

SOFTWARE ENGINEERING

287

3.1 3.1.1 3.1.2 3.1.2.1 3.1.2.2 3.1.2.3 3.1.2.4 3.1.2.5 3.1.2.6 3.1.2.7 3.1.3 3.1.4 3.1.5 3.1.6 3.1.7 3.1.8 3.2 3.3 3.3.1 3.3.2 3.3.3 3.3.4 3.3.4.1 3.3.4.2 3.3.4.3 3.3.5 3.3.6 3.4 3.4.1 3.4.2 3.4.3 3.4.4 3.4.4.1

Systemplanung Vorbemerkungen Phasenmodell Vorschlagsphase (Initialphase) Definitionsphase Konzeptphase Entwurfsphase Realisierungsphase Implementierungsphase Zusammenfassung Software Lebenszyklus Prototyping Ein modifiziertes Vorgehensmodell Projektorganisation Personell/organisatorische Fragen Software Konfigurations Management Vorgangskettenanalyse Datenmodellierung Probleme der Datenorganisation in Informationssystemen Phasen der Datenmodellienmg Methoden der Datenmodellierung Entity-Relationship-Modell (ERM) Allgemeine Regeln und Konventionen der Darstellung Generalisierung Bedingte Abhängigkeiten Normalisierte Relationen Fallbeispiel zur Datenmodellierung Funktionsmodellierung Probleme der Funktionssicht in Informationssystemen Arbeitsweisen der Funktionsmodellierung Module und Modularisierung Darstellungsmittel und -methoden der Funktionsmodellierung Funktionsbaum-Darstellung

287 287 289 291 292 293 295 296 297 297 298 299 301 303 306 307 308 310 310 312 314 315 315 322 324 326 332 343 343 346 351 355 355

XI 3.4.4.2 3.4.4.3 3.4.4.4 3.4.4.5 3. 5 3. 5. 1 3. 5. 2 3.6 3.6.1 3.6.2 3.7 3.7.1 3.7.2

HIPO-Methode Structured Analysis (SA) Structured Analysis and Design Techniques (SADT) Zusammenfassung zu den Darstellungsmitteln und -methoden Prozeßmodellierung Aufgaben der Prozeßmodellierung Darstellung von Geschäftsprozessen Objektorientierte Modellierung Notationselemente für die OO-Modellierung Fallbeispiel EDV-gestützte Vorgehensmodelle und Software-Werkzeuge Begriff. CASE-Tools

358 359 364 367 368 368 369 374 374 380 382 382 383

4

INFORMATIONSMANAGEMENT

388

4.1 4.2 4.2.1 4.2.2 4.2.3 4.2.4 4.2.5 4.2.6 4.3 4.4 4.5 4.6 4.7 4.7.1 4.7.2 4.7.3

Begriff und Hauptfunktionen Ziele der Systemplanung und -gestaltung Zielklassifikation Allgemeine Nutzenziele Spezielle Nutzenziele Software-Qualitätsziele Kosten- und Zeitziele Zielkonkurrenz Prioritäten für IT(Informationstechnologie)-Projekte Systemplattformen Softwarestrategie Ausgliederung von Funktionen der Informationsverarbeitung Verfahren der Systemauswahl Rahmenbedingungen Entscheidungsvorbereitung/-kriterien Beispiel zur Systemauswahl

3 88 391 391 391 391 392 3 94 395 395 397 399 402 404 404 405 407

TEIL M INDIVIDUELLE DATENVERARBEITUNG / PERSÖNLICHE NUTZUNG VON PC'S

410

1

SYSTEMGRUNDLAGEN

410

1.1 1.2 1.2.1 1.2.2 1.2.3 1.2.4 1.3 1.4 1.4.1 1.4.2 1.4.3 1.4.4

Systemvoraussetzungen Arbeit mit dem Betriebssystem MS-DOS Einschaltvorgänge Das Dateisystem Dateien Verschiedenes zu DOS-Kommandos Nützliche Werkzeuge unter MS-DOS MS-Windows Grundlagen Der Programmanager Der Dateimanager Datenaustausch

410 411 411 411 413 414 415 415 415 417 420 420

2

SELBSTÄNDIGER EINSATZ (STAND ALONE)

421

XII 2.1 2.2 2.3 2.4 2.5 2.6

Individuelle Datenverarbeitung Textveraibeitung Tabellenkalkulation Präsentationsgrafik (DTP) PC-Datenbanken Weitere ausgewählte Anwendungen

3

EINSATZ IN VERBUNDSYSTEMEN

3.1 3.2 3.2.1 3.2.1 3.2.2 3.2.3 3.3 3.4 3.5

Systemvoraussetzungen Das Internet Einstieg FTP - File Transfer Protocol Im Dialog auf fernen Rechnern: Remote-Login Weitere Internet-Dienste Compuserve E-Mail und die Mailboxen Allgemeines zum Arbeiten in Computernetzen

Literaturverzeichnis Register

421 422 424 428 429 436 437

437 438 438 439 440 440 441 442 443 446 463

Teil I Informatik Grundlagen

1

Teil I Informatik Grundlagen 1. Grundbegriffe Der rapide technische Fortschritt in der Erfassung, Verarbeitung, Speicherung und Übertragung von Informationen sowie die ständige Ausweitung und Vertiefung des Anwendungsbereiches führen zu immer neuen Begriffen und zum Bedeutungswandel bereits existierender Begriffe. Oft werden in der Literatur bestimmten Begriffen unterschiedliche Bedeutungen oder partiell abweichende Inhalte beigemessen, mitunter werden auch für den gleichen Sachverhalt verschiedene Bezeichnungen verwendet. Es kann nicht Anliegen des vorliegenden Buches sein, sich mit den unterschiedlichen Auffassungen und Auslegungen dieses oder jenes Begriffes auseinanderzusetzen und davon die eigene Auffassung "wissenschaftlich" begründet abzuleiten. Der Leser muß jedoch wissen, in welchem Sinne die verschiedenen Begriffe hier verwendet werden. Diesem Anliegen dient in hohem Maße der Abschnitt 1.

1.1 Wirtschaftsinformatik - Begriff und Gegenstand Informatik (engl.:Computer Science / Informatics) ist die Wissenschaft von der Verarbeitung von Informationen. Sie beschäftigt sich vor allem mit • • •

den Möglichkeiten und Erfordernissen einer systematischen und automatisierten Verarbeitung, der Informationstechnik und deren Anwendung sowie den grundsätzlichen Verfahren der Verarbeitung, Speicherung und Übermittlung von Informationen.

Wesentliche Teilgebiete der Informatik sind daher • • • • • •

Theorie und Funktionsweise informationsverarbeitender technischer Systeme, insbesondere Computer Rechnerarchitekturen und -konfigurationen {Hardware), Computersprachen und Programme (Befehlsfolgen) zur Steuerung von Computern (Software) Verwaltung von Datenbeständen in elektronischen Speichermedien Prinzipien, Methoden, Verfahren und Werkzeuge zur Entwicklung von rechnergestützten Systemlösungen (Software Engineering) sowie die Anwendungen und Auswirkungen des Einsatzes von Anwendungssystemen.

Diese sog. Kerninformatik wird allgemein in drei Teildisziplinen untergliedert: •

Theoretische Informatik mit

Automatentheorie, Schaltwerktheorie, formale Sprachen

2

1 Grundbegriffe

•

Technische Informatik mit

•

Praktische Informatik mit

Schaltungstechnologie, Mikroprogrammierung, Rechnerorganisation Programmierungstechnologie, Betriebssysteme, Übersetzerbau

Neben der Kerninformatik haben sich zunehmend Angewandte Informatiken" (sog. Bindestrich-Informatiken) herausgebildet und eine relativ eigenständige Bedeutung erlangt. Sie beschäftigen sich mit den Besonderheiten der Computeranwendung in verschiedenen Bereichen (z.B. Ingenieurwesen, Medizin, Recht). Als eines der umfangreichsten Anwendungsgebiete hat sich bereits seit den 60-er Jahren die Wirtschaftsinformatik (ursprünglich als Betriebsinformatik bezeichnet) entwickelt. Die Wirtschaftsinformatik ist als interdisziplinäres Fachgebiet im Grenzgebiet zwischen den Wirtschaftswissenschaften (insbesondere der Betriebswirtschaftslehre) und der Informatik angesiedelt. Sie befaßt sich mit der Nutzung der Informations- und Kommunikationstechnik in Wirtschaß und Verwaltung und damit mit einem weiten Feld von Problemen, mit denen sich weder die BWL noch die (Kern-)Informatik auseinandersetzen. Dabei gibt es Überschneidungen sowohl mit der BWL als auch mit der (Kern-)Informaük.

Wesentliche Betätigungsfelder der Wirtschaftsinformatik sind: •

Konzeption, Entwicklung und Anwendung von Systemen zur rechnergestützten Informationsverarbeitung als Mensch-Machine-Systeme.

Sie werden i. allg. als rechnergestützte Informationssysteme, EDV-Systeme oder auch als betriebliche (EDV-)Anwendungssysteme bezeichnet und implizieren • • • •

die aufeinander abgestimmte Nutzung von Hardware und Software, die organisatorischen Regelungen, Methoden und Werkzeuge zur Gestaltung der rechnergestützten betriebswirtschaftlichen Abläufe (Orgware) und den Menschen als Systembenutzer (mitunter als Manware bezeichnet).

Im Industrieunternehmen handelt es sich dabei z.B. um Anwendungssysteme für Beschaffung, Produktion, Marketing, Vertrieb u.dgl. Hierbei rückt immer stärker die integrierte Lösung der Informationsverarbeitung für den Betrieb als Ganzes in den Vordergrund: CIM (Computer Integrated Manufacturing). •

Entwicklung von Computerprogrammen für betriebliche Anwendungssysteme unter Nutzung des Software Engineering.

Teil I Informatik Grundlagen • • • •

• • •

3

Analyse und Modellierung von Datenstrukturen zur rationellen Speicherung der betrieblichen Datenbestände (Datenorganisation). Ergonomische Gestaltung computergestützter Arbeitsplätze. Einsatz moderner Kommunikationstechnik, insbesondere zur Büroautomation. Effiziente Organisation der Beschaffung, Bereithaltung/Speicherung, Transformation und Bereitstellung der für die Betriebsführung relevanten Informationen, deren Behandlung als vierter Produktionsfaktor (Informationsmanagement). Entwicklung von wissensbasierten Systemen für die Entscheidungsunterstützung in betrieblichen Funktionsbereichen ("Expertensysteme"). Kriterien zur Auswahl geeigneter Hard- und Software für EDVAnwendungen im betriebswirtschaftlichen Bereich. Verfahren zur Ermittlung der Wirtschaftlichkeit von EDV-Anwendungen.

In den voranstehenden Aufzählungen wird wiederholt der S^siem-Begriff verwendet (Vgl.auch Teil II, Kapitel 1). •

Aus der Sicht der Kybernetik, insbesondere der System- und der Informationstheorie, kann ein Betrieb als komplexes, dynamisches, selbstregulierendes System aufgefaßt werden. In einem solchen System sind die Elemente (z.B. Menschen, Maschinen, Informationstechnik; auch Aufgaben bzw. Funktionen wie Beschaffung, Produktion, Vertrieb) durch irgendwelche Beziehungen miteinander verknüpft (Stoff, Energie, Information).

Betrieb •

•

•

Ein System, bei dem die Beziehungen zwischen den Elementen auf dem Austausch von Mitteilungen beruhen, die miteinander kommunizieren, wird als Kommunikationssystem (KS) bezeichnet. Sind diese Kommunikationsprozesse formalisiert, d.h.existieren genaue Regeln, die festlegen wie Mitteilungen beschafft und ausgetauscht werden, dann handelt es sich um ein Informationssystem (IS). In diesem Sinne kann ein Informationssystem in ein größeres Kommunikationssystem eingebettet sein. Wird die Formalisierung der Kommunikationsprozesse so weit getrieben, daß sie automatisierbar sind und auf dieser Basis der Austausch und die Verarbeitung der Informationen mit Hilfe der Informationstechnik (Hardware, Soft-

4

1 Grundbegriffe wäre) abgewickelt, dann spricht man vom rechnergestützen Informationssystem (RIS) synonym zu {EDV-) Artwendungssystem oder EDV-System.

Damit werden 3 Stufen fortschreitender Formalisierung sichtbar (Abb. 1-1.1-2).

1.2 Information, Kommunikation und Codierung 1.2.1 Erfordernisse des Informationsaustauschs im RIS als Mensch-Maschine-System Bei der Nutzung der Informatik zur effektiven Lösung von Aufgaben in der Wirtschaft ergeben sich für den Betriebswirtschaftler vor allem 3 Aufgabenkomplexe: a) Das Erfassen. Bereitstellen und ständige Aktualisieren der Informationen • sowohl über die eingesetzten Betriebsmittel, Werkstoffe und Arbeitskräfte • als auch über den geplanten und den tatsächlichen Ablauf der Wirtschaftstätigkeit. Dabei geht es inbesondere um die Fragen • •

der Darstellung der Informationen (wie für Mensch und Maschine lesbar?) und der Verwaltung der Informationen (übersichtliches und redundanzarmes Speichern, rasches Wiederauffinden gewährleisten).

b) Das logisch-algorithmische Formulieren des Lösungsprozesses für die verschiedenen betriebswirtschaftlichen Aufgaben. Hierbei werden 2 Arten von Algorithmen benötigt: •

Algorithmen für den determinierten (rechnerexternen) Arbeitsablauf zur Lösung der betriebswirtschaftlichen Prozeßabläufe im Unternehmen innerhalb und zwischen den Fachbereichen (bereichsübergreifende Aufgaben).

Hierzu dienen Darstellungsmethoden wie Prozeßablauiketten, Datenflußdiagramme, Datenflußpläne, Blasendiagramme u.a.m. (siehe Abschnitt II-3.1). •

Algorithmen zur Steuerung des rechnerinternen Bearbeitungsablaufs.

Für die Planung des Bearbeitungsablaufs im Computer, dh. für den Programmentwurf, werden Darstellungsmethoden genutzt wie Programmablaufplan, Struktogramm, Pseudocode u.a.m. (siehe Abschnitt 1-7.1). c) Die betriebswirtschaftliche Wertung und Auswertung der DV-Ergebnisse anhand der Rechnerausdrucke und Bildschirmanzeigen. Hierbei geht es um das zweckmäßige Aufbereiten und übersichtliche Darstellen der ermittelten Ergebnisse für das Ableiten fundierter Entscheidungen und Handlungen.

Teil I Informatik Grundlagen

5

Eine grundlegende Voraussetzung fiir die Nutzung des Computers zur Lösung anstehender Aufgaben ist folglich die Möglichkeit des Austauschs von Informationen zwischen dem Menschen und dem Computer. Einerseits müssen Informationen in maschinell lesbarer Darstellung an den Computer übergeben werden, sowohl die Informationen über den betriebswirtschaftlichen Prozeßablauf als auch die Algorithmen zur Bearbeitimg dieser Informationen. Andrerseits müssen die Ergebnisse des maschinellen Bearbeitungsprozesses in einer vom Menschen auswertbaren Form zur Verfugung stehen.

1.2.2 Informationsaustausch zwischen Mensch und Computer Informationen (im Sinne der Informatik) sind Aussagen über einen Teilbereich der Realität (Personen, Gegenstände, Prozesse / Sachverhalte / Vorgänge), die in einer beliebigen Vielfalt auftreten können. Die Darstellung und Weitergabe von Informationen ist stets an materielle Träger (z.B. Schallwellen, Lichtwellen) gebunden. Diese werden als Signale bezeichnet. Auch im Computer wird die Speicherung, Verarbeitung und Übertragung von Informationen durch physikalische Signale (z.B. elektrische, magnetische Größen) realisiert. Eine besondere - vom Menschen entwickelte - Signalform, die er zum Informationsaustausch nutzt, sind Zeichen (Schrifitzeichen, grafische Zeichen). Zeichen

sind vom Menschen vereinbarte Elemente zur Darstellung von Informationen.

Die zwischen den Menschen vereinbarten Zeichen können auch zur Verständigung zwischen Mensch und Computer genutzt werden, wenn die zwei Grundbedingungen jeglichen Informationsaustauschs erfüllt sind: a) Die Elemente zur Darstellung der Informationen (Signale, Zeichen) müssen zwischen Sender und Empfänger vereinbart bzw. beiden bekannt sein, d.h., Sender und Empfänger müssen den gleichen Signal- bzw. Zeichenvorrat besitzen. Ein Zeichenvorrat ist eine endliche Zeichenmenge, von der jedes Zeichen in seiner Bedeutung bekannt ist. Er wird auch als Alphabet bezeichnet. Bsp.: Lateinisches Alphabet A ... Z, a ... z Ein mit dem Computer vereinbarter Zeichenvorrat wird als kommunikativer Zeichenvorrat oder als Maschinenalphabet bezeichnet. Dabei handelt es sich stets nur um eine Teilmenge der im täglichen Leben verwendeten Zeichen. Das Maschinenalphabet heutiger Computer beinhaltet i.allg. das lateinische Alphabet, die Ziffern 0 ...9 und Sonderzeichen.

6

1 Grundbegriffe

b) Zwischen Sender und Empfänger müssen die Regeln vereinbart bzw. bekannt ein, nach denen die Zeichen zur Darstellung der Informationen angeordnet werden (Syntax). Zum Informationsaustausch mit dem Computer wird allgemein die englische Sprache genutzt. Deshalb müssen die für diese Sprache (bzw. für die darauf beruhenden Programmiersprachen) geltenden Regeln für die Anordnung der Zeichen des Maschinenalphabets verwendet werden, z.B:

P RI N T DRUCKE

Computer reagiert keine Reaktion.

Hieraus ist zu entnehmen, daß der Informationsgehalt durch vereinbarte Folgen von Zeichen dargestellt und übertragen wird, d.h.. Computer verarbeiten lediglich Zeichenfolgen. Die Bedeutung (Semantik) dieser Zeichenfolgen können sie nicht erkennen. Die vorrangig zum Zwecke der Verarbeitung gebildeten Zeichenfolgen werden als Daten bezeichnet. Zum Zwecke der Weitergabe gebildete Informationen sind Nachrichten. Diese und viele weitere Grundbegriffe der Informationsverarbeitung sind in der DIN 44300 vom November 1988 definiert. Speziell für den Informationsaustausch mit einem Computer muß noch eine weitere Bedingung erfüllt werden. c) Die Zeichen bzw. Zeichenfolgen müssen in Signale umgewandelt werden, die der Computer verarbeiten kann. Mit der heutigen Informationstechnik können zwei verschiedene Zustände relativ leicht realisiert und sicher unterschieden werden (Strom an/aus, magnetisiert/nicht magnetisiert). Zur Kennzeichnung dieser beiden Zustände werden die Binärzeichen 0,1 (oder 0,L) genutzt. Der rechnerinterne Zeichenvorrat besteht daher nur aus den zwei Zeichen 0 und 1. Deshalb werden jeweils mehrere Binärzeichen benötigt, um ein Zeichen des Maschinenalphabets eindeutig darstellen zu können. Zur rechnerinternen Darstellung und Verarbeitung der Daten muß jedem Zeichen des Maschinenalphabets eine Binärzeichenkombination (Folge von O/l-Zeichen) zugeordnet werden. Bei jeder Ein- oder Ausgabe von Daten ist eine Umformung aus der externen in eine interne Darstellungsform und umgekehrt notwendig. Die Zuordnung der Zeichen eines Zeichenvorrats zu den Zeichen eines anderen Zeichenvorrats wird als Code und die Umformung als Codierung bezeichnet. Weil es sich hierbei um die Zuordnung von intern realisierbaren Zeichen zu den (externen) Zeichen des Maschinenalphabets handelt, werden hierfür die Begriffe interner Code oder Maschinencode verwendet.

Teil I Informatik Grundlagen

7

Für den Informationsaustausch zwischen Mensch und Computer ergibt sich damit der in Abb. 1-1.2-1 skizzierte Sachverhalt. Mensch

Informationen

Verständi eun esbereich Mensch / Maschine

M— — •

Daten Zeichenfolge

- Alphabet und Ziffern - Vielzahl weiterer Zeichen Alle vom Menschen zur Kommunikation genutzten Zeichen

Maschine (intern)

—•

Signale

elektr., pneumat. oder Lichtimpulse

0...9; A...Z, a...z Sonderzeichen

0,1 (0,L)

Maschinenalphabet

Binärzeichen

Abb. I- 1.2-1: Verständigung zwischen Mensch und Computer Eine einzelne Stelle einer Binärzeichenfolge wird als Bit (binaiy digit) bezeichnet. Je nach Anlagentyp wird jeweils eine bestimmte Anzahl von Bits für die eindeutige Darstellung der Zeichen des Maschinencodes genutzt und bei der internen Verarbeitung als Ganzes behandelt. Anfangs wurden Bitgruppen verwendet, welche vier Bits (Tetrade) umfassen. Im Rahmen der damit möglichen = 16 Bitkombinationen können die 10 Ziffern des Dezimalsystems intern dargestellt werden. Zu Beginn der Entwicklung von Computern für den Einsatz im kommerziellen Bereich wurde bevorzugt eine Einheit mit 6 Bits (Hexade) genutzt. Die damit verfügbaren 2 6 = 64 Bitkombinationen gestatten, neben den 10 Ziffern, auch die Zeichen des lateinischen Alphabets (unter Verzicht auf die Kleinbuchstaben) und Sonderzeichen intern darzustellen. Gegenwärtig wird allgemein eine Gruppe von 8 Bits (Byte) verwendet (siehe Abschnitt 1.2.4.1). Damit können 28 = 256 verschiedene Zeichen binär codiert werden. Zur Darstellung der Zeichen des Maschinenalphabets dienen heute standardisierte Codes, die auf dem Byte (Abb.I-1.2-2) und einer Verschlüsselung beruhen, bei der eine Dezimalzahl nicht als Ganzes, sondern jede ihrer Ziffern einzeln, binär codiert wird (siehe BCD-Codierung, Abschnitt 1.2.3.2).

8

1 Grundbegriffe

1 Byte Zonenteil

Ziffernteil

2 Halbbyte 8 (Daten-)Bit Bitpositionen

Aufruf („Ansprechen") des Byte im Arbeitsspeicher Abb. 1-1.2-2: Das Byte Gegenwärtig werden fast ausschließlich der EBCDI-Code (Extended Binary Coded Decimal Interchange Code) bei Großrechnern und der ASCII-Code (American Standard Code for Information Interchange) bei Mikrocomputern verwendet. Zu diesem Zweck wird das Byte in zwei Halbbytes zu je 4 Bits geteilt (siehe Abb.I-1.2-2). Das rechte Halbbyte ist der Ziffernteil, weil für die Darstellung der 10 Ziffern des Dezimalsystems im Prinzip nur diese 4 Bits benötigt werden. Das linke Halbbyte wird als Zonenteil bezeichnet. Zur vereinfachten, übersichtlichen Darstellung der Bitgruppe eines Halbbytes werden vielfach die Ziffern des Hexadezimalsystems (siehe Abschnitt 1-1.2.3.4) genutzt. Die beiden Tabellen in den Abb. 1-1.2-3 und 1-1.2-4 veranschaulichen, wie die Buchstaben des lateinischen Alphabets, die Ziffern des Dezimalssystems und die wesentlichsten Sonderzeichen bei diesen Maschinencodes binär codiert dargestellt werden. Durch die Verwendung von 8 Bits je bei diesen Codes werden in einigen Fällen mehr Stellen belegt, als zur eindeutigen Codierung erforderlich. Mit Hilfe spezieller Verschlüsselungstechniken könneh Zeichen bzw. Zeichenfolgen auch durch weniger Bits dargestellt werden. Eine solche Datenkomprimierung wird vor allem bei der Datenübertragung in öffentlichen Netzen (siehe Abschnitt 1-4.), bei der Datenspeicherung in Datenbanken (siehe Abschnitt 1-6.2) und bei der Datensicherung, insbes. beim Backup (siehe Abschnitt 1-6.3) angewendet.

1.2.3 Nutzung von Zahlensystemen Für die Durchführung arithmetischer Operationen sind Positions- bzw. Stellenwertsysteme besonders geeignet. Bei derartigen Zahlensystemen kommt den zur Darstellung einer Zahl verwendeten Ziffern (neben ihrem Ziffernwert) ein Stellenwert zu. Dieser hängt von der Position der Ziffer innerhalb der zur Darstellung der Zahl verwendeten Ziffernfolge ab.


vi

•a £ 3 Q 2 T

o -

u j f—1 ci

JD

t/5 CQ

«

-

O

VD f - 00 Ov < m U Q w ti.

iH

y

=ïl =!t • 8 C

H "O X

—

X X X

«U

•o ir dl

•

-

®

•

•

4- h* « -iL. t= a •iu_ 0

w O u 3 -ni o e

—

m o c —T~ i —Il W —

o M u CA «0

T Q H •o -

o

-

B=

£ oc 5: O -3 0 f=

•o tu > t»

£

—

S M

=1 U -

N •4) O r —

M

NOV « >

- 00

-H >

•—

Ui •4)

JL- =4 c V)

-

•=

=

o BETWEEN... AND... LIKE IS NULL IN EXISTS

Bedeutung gleich kleiner als größer als kleiner gleich größer gleich ungleich zwischen ... und... wie NULL-Wert / unbesetzt in einer Menge von Werten existiert in einer Menge von Zeilen

Abb. 1-6.2-12: SQL-Vergleichsoperatoren •

Von besondere Bedeutung ist die Möglichkeit zur Erzeugung einer neuen Tabelle aus vorhandenen Tabellen durch eine Verbundoperation (Join):

Beispiele:

• SELECT kunde.knr,firma,angnr,liefschl FROM künde,angebot WHERE künde.knr= angebot.knr; • SELECT angebot. artnr,bezeich,bestand,angnr,knr FROM angebot, artikel WHERE angebot.artnr=artikel.artnr;

Die weiteren optionalen SELECT-Komponenten bieten folgende Möglichkeiten: •

GROUP BY (Wonach gruppieren?) Angabe von Attributen.

Damit können ausgewählte Zeilen zu Gruppen zusammengezogen und mit einer Gruppenoperation (z.B. Summieren, Durchschnitt bilden) verknüpft werden. Jede Spalte, die in der SELECT-Klausel auftritt, muß in der GROUP BY-Klausel aufgeführt sein. Beispiel:

SELECT bezeich, SUM (bestand) FROM artikel

Teil I Informatik Grundlagen

175

GROUP BY bezeich; •

HAVING (Unter welcher Bedingung gruppieren?) Angabe von Bedingungen.

Mit der HAVING-Klausel können zusätzlich noch Bedingungen zu Summenausdrücken an die Gruppenbildung gestellt werden. Beispiel:

•

• SELECT bezeich, SUM (bestand) FROM artikel GROUP BY bezeich HA VING SUM (bestand) >100000;

ORDER BY (Wonach das Ergebnis ordnen?) Angabe von Attributen.

Damit kann das Ergebnis der Abfrage nach bestimmten Attributen geordnet werden. Beispiele:

• SELECT firma,knr FROM künde ORDER BY firma; • SELECT bezeichnung,artnr,preis_me FROM artikel ORDER BY bezeichnung;

Insgesamt ermöglicht SQL folgende Operationen fiir Datenabfragen: • Projektion.

Auswahl bestimmter Spalten aus einer Tabelle.

• Selektion:

Auswahl bestimmter Zeilen aus einer Tabelle.

• Verbund:

Erzeugen einer neuen Tabelle aus vorhandenen Tabellen.

• Vereinigung:

Erzeugen einer neuen Tabelle aus allen Zeilen vorhandener Tabellen mit gleichen Strukturen.

• Durchschnitt: Erzeugen einer neuen Tabelle aus den Zeilen vorhandener Tabellen, welche in allen vorhandenen Tabellen vorkommen. • Differenz:

Erzeugen einer neuen Tabelle aus den Zeilen einer vorhandenen Tabelle, welche in einer bestimmten anderen Tabelle nicht vorkommen.

d) Zur Datenkontrolle und zur Steuerung das Ablaufs einer SQL-Sitzung verfügt SQL über eine Reihe weiterer Befehle. Hierbei geht es vor allem darum, die Datenbank vor unerwünschten Veränderungen zu schützen, z.B. durch das Gewähren oder Entziehen von Nutzerrechten und durch Befehle zur Behandlung von Transaktionen wie SET TRANSACTION Konsistenzebene u.a. festlegen COMMIT Transaktion beenden ROLLBACK Transaktion abbrechen . e) Darüber hinaus stehen zur Steuerung der Arbeit mit dem Server verschiedene SET-Anweisungen zur Verfugung, welche die zu verwendenden Kataloge, Schemas u.dgl. definieren.

176

6 Datenorganisation

Im Vergleich zu den prozeduralen Sprachen der 3. Generation (z.B. COBOL, PASCAL, C) können mit deskriptiven, nicht prozedurale Sprachen (wie SQL) verschiedene Berechnungen und komplizierte Anfragen nicht realisiert werden. Auch ihr Sprachumfang schränkt die Entwicklung von benutzergerechten Anwendungen mit Menüfuhrung, Erfassungsmasken u.a. ein. Andrerseits weisen die prozeduralen Sprachen Eigenschaften auf, die die Auswertung umfangreicher Datenbestände erschweren (z.B. Beschränkungen bezüglich der Verarbeitung von Mengen, eine Vielzahl von Datentypen). Um die Vorteile beider Spracharten zu nutzen werden Anweisungsfolgen für Datenbankoperationen in prozedurale Sprachen eingebunden. Hierfür gibt es verschiedene Möglichkeiten. Bezüglich der hier zu betrachtenden Sprache SQL hat sich das sog. „Embedded SQL" bewährt. Ein embedded ^ ¿ - P r o g r a m m besteht aus den Anweisungen einer prozeduralen Wirts-Sprache und darin eingebetteten SQL-Anweisungen. Beispiel:

.... EXEC SQL...; SELECT kunde.knr,firma,angnr,liefschl INTO :H_knr, :H_firma, :H angnr, :H_liefschl FROM künde,angebot WHERE kunde.knr=e_knr; END EXEC ...;

e knr besagt:

die eingegebene Kundennummer

Abschnitt II-2 enthält ein Beispiel zu embedded SQL in Gestalt eines dBaseProgramms mit eingebundenen SQL-Anweisungen.

6.3 Datenschutz und Datensicherheit 6.3.1 Anliegen von Datenschutz/Datensicherheit Die Hauptaufgabe des Informationsmanagement, das erforderliche Bereitstellen von Daten, berührt weitere Aspekte wie den Zeitpunkt der Bereitstellung, den erforderlichen Umfang der Daten und die Korrektheit. Daten sind in immer stärkerem Maße Betriebsmittel eines Unternehmens und haben mindestens den gleichen Stellenwert wie • •

Personal Kapital.

Ihre mangelnde Verfügbarkeit kann die Existenz von Unternehmen substantiell bedrohen, wie amerikanische Untersuchungen von 1988 zeigen:

Teil I Informatik Grundlagen

177

Nach einem Totalverlust der Rechentechnik sinkt die Funktionsfähigkeit nach 5,5 Tagen • •

in der Industrie gesamt auf in der Versicherungsbranche auf

28 %, 41%.

Eine andere Sicht vermitteln folgende Daten: Die Überlebensdauer von Unternehmen nach Totalverlust des Rechenzentrums beträgt bei Banken: Handel: Produktion: Versicherung:

2,0 2,5 5,0 5,5

Tage Tage Tage Tage.

Die jährlichen Kosten aus Verletzung der logischen Datensicherheit belaufen sich nach [SB92] auf rund 530 Mio. englische Pfund. Dabei geht es nur um "direkte" Kosten und nicht um jene, die mittel- und langfristig aus Imageverlust, Kundenabwanderung und anderen Wettbewerbsbeeinträchtigungen entstehen und nur schwer zu ermitteln sind. Für deutsche Unternehmen liegen keine vergleichbaren Zahlen vor, die Situation ist jedoch zweifelsfrei analog, da die meisten Fälle von Computerkriminalität erst gar nicht zur Anzeige gelangen aus Furcht vor Imageverlusten und so in keiner Kriminalstatistik auftauchen. Die potentiellen Gefahren für die Sicherheit von Daten wachsen erheblich mit dem rasanten Tempo des PC-Einsatzes und deren Vernetzung: •

•

• • •

die offene Architektur und leichte Bedienbarkeit von PC machen sie besonders anfällig für unberechtigten Zugriff, unkontrollierten Datenimport (eventuell gegen Viren) und -export. Es gibt keine Funktionstrennung zwischen Anwendung, Programmierung und Systemverwaltung, so daß Manipulationen von Daten und Anwendungsprogrammen relativ leicht möglich sind. durch Mangel einer Zwangsprotokollierung ist die Rekonstruktion der Vorgänge zur Verletzung der Datensicherheit sehr erschwert. Laptops und Notebooks fordern durch ihren dezentralen Einsatz das Diebstahlsrisiko von sensiblen Daten, Die Vernetzung von PC zieht einen höheren internen und externen Datenaustausch im Unternehmen nach sich; die dabei eingesetzten Verbindungsleitungen und Vermittlungsrechner stellen eine neue, separat zu schützende Komponente der Informationssysteme dar.

Die skizzierte Situation muß in der Unternehmensfuhrung privater Unternehmen sowie in öffentlichen Einrichtungen ein existentielles Interesse an der Sicherheit benötigter Daten begründen, auch wenn kein quantifizierbarer betriebswirtschaftlicher zusätzlicher Nutzen sichtbar ist, sondern bestenfalls ein Vermeidungsnutzen (es werden Umsatzeinbußen, zusätzliche Kosten oder Imageverluste vermieden).

6 Datenorganisation

178

Darüber hinaus ist jeder Betrieb und jede Behörde in den Deutschland- und EGweiten Rahmen der Datenschutz-Gesetzgebung eingebunden. Das Grundanliegen des Datenschutzes ist ein wesentlich anderes. Der Mißbrauch personenbezogener Daten von Bürgern, insbesondere die unbefugte Weitergabe, erfuhr mit der digitalen Speicherung in Dateien und den damit verbundenen weitreichenden Auswertungsmöglichkeiten eine erhebliche Steigerungsmöglichkeit. In Deutschland und anderen europäischen Ländern entstanden daher schrittweise Gesetze, die einen Ordnungsrahmen zur Handhabung personenbezogener Daten setzten und in Deutschland das Recht des Bürgers auf "informationelle Selbstbestimmung", d. h. die freie Entscheidung über die Preisgabe seiner Daten im Einklang mit behördlichen Erfordernissen, festschrieben. Ein Beispiel soll dieses Anliegen verdeutlichen: Mit der Einfuhrung des ISDNTelefons wäre es rein technisch möglich, die Telefonnummer des Anrufers auf dem Display des Angerufenden zu zeigen, was Telefonterror verhindern könnte. Dem Einwand der Datenschützer, daß damit Bürger bloßgestellt werden könnten, die telefonische Dienste nur unter der Voraussetzung der Anonymität in Anspruch nähmen, wie Telefonseelsorge oder Aids-Beratung, mußte jedoch stattgegeben werden. Als Ergebnis fand sich der Kompromiß, als weiteres Leistungsmerkmal dem Anrufer freizustellen, ob er per Knopfdruck die Nummernanzeige unterdrücken möchte. Im weiteren wird von folgender Begrififsabgrenzung ausgegangen: Datenschutz: umfaßt alle gesellschaftlichen und rechtlichen Aspekte sowie juristische Maßnahmen von Gesetzgebung und Rechtssprechung, die bei der Informationserfassung, -Verarbeitung und -weitergäbe die schutzbedürfiigen Belange von Personen zum Inhalt haben, mit dem Zweck, den Bürger vor den Folgen von Zweckentfremdung, Mißbrauch und totaler Erfassung seiner Daten zu schützen. Hingegen umfaßt Datensicherheit alle Maßnahmen, die beliebige Daten vor Verlust ihrer • • •

Vertraulichkeit Integrität Verfügbarkeit

während ihrer Verarbeitung schützen sollen. Sie bezieht sich auf alle maschinell verarbeiteten Daten, auch soweit sie nicht personenbezogen sind und werden von den Unternehmungen im begründeten eigenen wirtschaftlichen Interesse des Erhalts von Arbeitsfähigkeit und Wettbewerbsfähigkeit unternommen. Gelegentlich würde unter Datenschutz auch das Copyright an Computerprogrammen verstanden, d. h. das ausschließliche Recht des Verfassers an wirtschaftlicher Verwertung seines Produkts. Da der Verfasser den Datenschutzbegriff nur in og. Sinn versteht, wird hierauf nicht eingegangen.

Teil I Informatik Grundlagen

179

6.3.2 Rechtsgrundlagen des Umgangs mit Daten In Deutschland regeln das "Gesetz zur Fortentwicklung der Datenverarbeitung und des Datenschutzes" vom 20. 12. 1990 [BDSG] und die Datenschutzgesetze der einzelnen Bundesländer den Datenverkehr. Das BDSG beinhaltet Regelungen für Erhebung, Speicherung, Nutzung und Übermittlung von Daten durch • • •

die öffentlichen Stellen des Bundes (Behörden, Rechtspflege etc.), den nichtöffentlichen Bereich (private Wirtschaft, Banken etc.), Sondervorschriften für Statistik, Medizin, Medien.

Die Landesdatenschutzgesetze gelten für die öffentlichen Stellen der Länder und Kommunen. Es wirkt nach dem Subsidiaritätsprinzip, d. h. es greift nur ein, wenn nicht bereits andere Regelungen existieren, wie in vielen speziell geregelten Bereichen (Sozialgesetzgebung, Steuergesetzgebunga, Betriebsverfassungsgesetz etc.) Die Grundaussagen: a) Verbotsprinzip mit Erlaubnisvorbehalt (alles ist verboten, außer was im Gesetz explizit geregelt) b) nur personenbezogene Daten betroffen c) nur in auswertbaren Dateien befindliche Daten betroffen d) Zweckbindung der Daten, d. h. Daten dürfen nur für einen bekannten Zweck erhoben und auch nur für diesen verarbeitet werden e) Behörden u. a. öffentliche Stellen dürfen die für ihre Arbeit erforderlichen Daten erheben f) der Bürger hat das Recht auf • Mitteilung der Speicherung seiner Daten • Mitteilung der Weitergabe seiner Daten • Sperrung/Löschung seiner Daten • Korrektur unrichtiger Daten. Damit ist die Datenverarbeitung im öffentlichen Bereich streng reguliert. Private Stellen dürfen personenbezogene Daten speichern und weitergeben, wenn BDSG oder andere Rechtsvorschriften es erlauben oder der Betroffene eingewilligt hat. Dies kann geschehen • • •

im Rahmen der Zweckbestimmung eines Vertragsverhältnisses (Kaufvertrag, etc.) oder vertragsähnlichen Vertrauensverhältnisses (z. B. Bewerbung) mit dem Betroffenen oder soweit es zur Wahrung berechtigter Interessen der speichernden Stelle erforderlich ist und kein Grund zur Annahme besteht, daß dadurch schutz-würdige Belange des Betroffenen verletzt werden.

180

6 Datenorganisation

Die Weitergabe an Dritte darf zur Wahrung berechtigter Interessen des Empfängers oder der Allgemeinheit erfolgen, sofern keine schutzwürdigen Belange des Betroffenen beeinträchtigt werden und der Empfänger ein glaubhaftes Interesse an den Daten dargelegt hat. Damit ist die Tätigkeit von Handels- und Wirtschaftsauskunfteien und Kredit-Schutzorganisationen wie Schufa , Creditreform, Auskunfteien Bürgel u. a. eingebunden, da die Kenntnis über die Bonität eines Kunden im glaubhafen Interesse eines Kaufhauses bzw. eines Kreditinstituts liegt. Ebenfalls generell zulässig ist die Übermittlung und Nutzung, wenn es sich um listenmäßig oder anders zusammengefaßte Daten über Angehörige einer Personengruppe handelt, die sich auf • • •

die Zugehörigkeit des Betroffenen zu dieser Personengruppe Berufs-, Branchen- oder Geschäftsbezeichnung Namen, Titel, akademische Grade, Anschrift und Geburtsjahr beschränken.

Dagegen besteht bei personenbezogenen Daten, die sich auf gesundheitliche Verhältnisse, strafbare Handlungen, Ordnungswidrigkeiten, religiöse und politische Anschauungen und arbeitsrechtliche Sachverhalte beziehen, i. allg. ein schutzwürdiges Interesse des Betroffenen, das die Weitergabe ausschließt. Konstruktive Unterstützung zur Einhaltung dieser Grundsätze wird in den "10 Geboten des Datenschutzes" (Anlage zu § 9 BDSG) gewährt durch die Forderung technisch-organisatorischer Maßnahmen: „Werden personenbezogene Daten automatisiert verarbeitet, sind Maßnahmen zu treffen, die ... geeignet sind: 1. Unbefugten den Zugang zu Datenverarbeitungsanlagen, mit denen personenbezogene Daten verarbeitet werden, zu verwehren (Zugangskontrolle), 2. zu verhindern, daß Datenträger unbefugt gelesen, kopiert, verändert oder entfernt werden können (Datenträgerkontrolle), 3. die unbefugte Eingabe in den Speicher sowie die unbefugte Kenntnisnahme, Veränderung oder Löschung gespeicherter personenbezogener Daten zu verhindern (Speicherkontrolle), 4. zu verhindern, daß Datenverarbeitungssysteme mit Hilfe von Einrichtungen zur Datenübertragung von Unbefugten genutzt werden können (Benutzerkontrolle), 5. zu gewährleisten, daß die zur Benutzung eines Datenverarbeitungssystems Berechtigten ausschließlich auf die ihrer Zugriffsberechtigung unterliegenden Daten zugreifen können (ZugrifTskontrolle), 6. zu gewährleisten, daß überprüft und festgestellt werden kann, an welche Stellen personenbezogene Daten durch Einrichtungen zur Datenübertragung übermittelt werden können (Übermittlungskontrolle), 7. zu gewährleisten, daß nachträglich überprüft und festgestellt werden kann, welche personenbezogenen Daten zu welcher Zeit von wem in Datenverarbeitungssysteme eingegeben worden sind (Eingabekontrolle),

Teil I Informatik Grundlagen

181

8. zu gewährleisten, daß personenbezogene Daten, die im Auftrag verarbeitet werden, nur entsprechend den Weisungen des Auftraggebers verarbeitet werden können (Auftragskontrolle), 9. zu verhindern, daß bei der Übertragung personenbezogener Daten sowie beim Transport von Datenträgern die Daten unbefugt gelesen, kopiert, verändert oder gelöscht werden können (Transportkontrolle), 10. die innerbehördliche oder innerbetriebliche Organisation so zu gestalten, daß sie den besonderen Anforderungen des Datenschutzes gerecht wird (Organisationskontrolle)." Ihre Bedeutung geht weit über die Gewährleistung des Schutzes personenbezogener Daten hinaus. Ihre konkretisierte Anwendung stellt bereits ein Minimalprogramm zur generellen Garantie der Sicherheit sensibler betrieblicher Daten dar, das im Folgenden ergänzt wird. Die Verantwortung für die Verhinderung nicht gesetzeskonformer Handlungen liegt primär bei Herstellern und Betreibern von EDVA. Strafrechtlich von Belang sind insbesondere folgende kriminellen Handlungen: • Computerbetrug (Manipulation von Daten oder Programmen), • Computersabotage (Vernichtung von Daten oder Programmen), • Computerspionage (unberechtigtes Erlangen und Verwenden von Programmen). Ihre Verfolgung geschieht nach den Paragraphen 202 a (Ausspähen von Daten), 263 a (Computerbetrug), 269 (Fälschung beweiserhcblicher Daten), 270 (Täuschung im Rechtsverkehr bei DV), 303 a (Datenveränderung) und 303 b (Computersabotage) der 2. Änderung des Gesetzes zur Bekämpfung der Wirtschaftskriminalität.

6.3.3 Normung und Prüfung der Computersicherheit Im europäischen Gegenstück zur Orange-Book-Initative des USA-DoD [DoD] sind auf deutscher [ZSI] bzw. europäischer Ebene fITSEC] Standards für Sicherheitseigenschaften von EDV-Systemen und Prüfkriterien zu deren Verifizierung erarbeitet worden. Da die europäischen Standards sich eng an die deutschen anlehnen, werden hier die deutschen Standards referiert. Folgende Grundfunktionen werden betrachtet: 1. Identifikation und Authentisierung Die sicherheitsrelevanten Subjekte und Objekte sind zu bestimmen, geeignet zu identifizieren (z. B. durch eindeutige Benutzernamen, und eine geeignete Authentisierungsmethode ist festzulegen, damit nicht unter einem nicht zutreffenden Benutzernamen unrechtmäßigerweise Zugang zum System gewährt wird, sondern geprüft werden kann, ob der Eingangsbegehrende deijenige ist, der er zu sein vorgibt (z. B. Kenntnis eines persönlichen Paßwortes). 2. Rechteverwaltung (Autorisierung)

182

6 Datenorganisation Identifizierbare Subjekte können Rechte bezüglich anderer identifizierbarer Subjekte besitzen. Diese Rechte müssen verwaltet werden können, also im Zeitverlauf zuerkannt oder aberkannt. Diese Rechte können Lese- oder Schreibrechte auf bestimmte Dateien, Geräte oder Bereiche sein.

3. Rechteprüfung Mechanismus, der bei versuchter Ausübung eines Rechts prüft, ob dieses Recht überhaupt zugebilligt ist, und ggf. Zugriffe unterbindet. 4. Beweissicherung Protokollierung über erfolgte oder versuchte Ausübung von Rechten. 5. Wiederaufbereitung Werden Betriebsmittel, z. B. Haupt- oder Peripheriespeicher nacheinander von verschiedenen Subjekten oder Objekten benutzt, findet dazwischen eine Maßnahme statt, die verhindert, daß die dort stehenden Informationen vom Nach-nutzer gelesen werden können (z. B. beim Löschen einer Datei zwangsweises Überschreiben mit Nullen). 6. Fehlerüberbrückung Begrenzung von Folgen des Fehlverhaltens von Systemen (z. B. durch ein redundantes, parallel mitlaufendes Festplattenlaufwerk, so daß bei Ausfall eines Laufwerkes unmittelbar mit dem anderen weitergearbeitet werden kann). 7. Gewährleistung der Funktionalität Es ist festzulegen, welche Funktionalität eines Systems unbedingt gewährleistet sein muß und welche Mechanismen ggf. allein zu dem Zweck installiert werden, um diese unter allen Bedingungen aufrecht zu erhalten (Bsp.: Scheduler in Prozeßrechnern, Anti-Deadlock-Mechanismen in Betriebssystemen). 8. Übertragungssicherheit Bei verteilten Systemen sind zusätzliche Sicherheitsmechanismen vorzusehen, die Besonderheiten der Datenübertragung Rechnung tragen und die durch bishher erwähnte Rechtsvergabe- und -prüfungstechniken nicht abgedeckt werden. Sie zielen auf • • • • • • •

zeitliche Verfügbarkeit von Nachrichten Verhindern des Mehrfacheinspielens von Daten (Bankwesen) Datenintegrität/ -Vertraulichkeit auf Übertragungswegen Verhindern des Ableugnens der Urheberschaft einer Nachricht Verhindern des Ableugnens des Empfangs einer Nachricht Verhindern von Nachrichtenflußanalysen Authentisierung auf Partnerebene (daß tatsächlich die gewünschten Partner kommunizieren).

Systeme werden danach bewertet, welche dieser Grundftinktionen (die je nach Zweckbestimmung nur ausgewählt werden) in welcher Stärke vorhanden sind.

Teil I Informatik Grundlagen

183

Darüber kann vom Bundesamt für Sicherheit in der Info-Technik ein Zertifikat ausgestellt werden.

6.3.4 Datensicherheit im Unternehmen 6.3.4.1

Hauptziele

Die Hauptziele der Datensicherheit im Betrieb sind •

Verfügbarkeit der Daten, d. h. bedarfsgerechte Bereitstellung in Umfang und Zeit

•

Integrität der Daten, d. h. Unverfalschbarkeit und sachliche Richtigkeit der Daten

•

Vertraulichkeit der Daten, d. h. Datenkenntnisnahme nur durch Befugte.

Dabei tritt nach Art der Daten das eine oder andere Hauptziel mehr in den Vordergrund und ein anderes zurück (z. B. bei Produktionssteuerdaten Verfügbarkeit, bei Personaldaten Vertraulichkeit). 6.3.4.2

Ursachen für Defizite

Ursachen für Defizite der betrieblichen und zwischenbetrieblichen Informationssicherheit liegen meist nicht in spektakulären Aktionen externer Eindringlinge, sondern in innerbetrieblichen Organisations-, Qualifikations- und Motivationsmängeln. Bedrohungen der innerbetrieblichen Datensicherheit lassen sich klassifizieren in •

vom Menschen ausgehende Bedrohungen, die ihrer Natur nach

•

vorsätzlich sind (und damit strafrechtlich relevant) wie

•

•

• •

vorsätzliche Manipulationen von Daten vorsätzliche Manipulation von Software (durch Viren, Würmer, trojanische Pferde o. a. Angriffe)

•

Raubkopien oder

fahrlässig sind wie • Bedienfehler (falsche Befehlsreihenfolge) • Leichtfertigkeit (Fehlerursachen nicht tief analysiert) • Gleichgültigkeit (auf Fehlersignale nicht reagiert) • Spieltrieb (Einbringen ungeprüfter Programme) durch Umwelteinflüsse oder Versagen der Technik hervorgerufene Bedrohungen.

Bei schuldhaftem Verhalten kann der betreffende Mitarbeiter mit Regreßforderungen rechnen. Obwohl Datenverarbeitung als "gefahrengeneigte" Tätigkeit gilt,

6 Datenorganisation

184

hat der Arbeitnehmer generell eine Schadensersatzpflicht in Form einer Beteiligung am Aufrechnen der Schadensfolgen, die in Abwägung des Verschuldens des Arbeitnehmers gegen das allgemeine Betriebsrisiko des Unternehmers (§ 254 BGB) geteilt werden. Bei grober Fahrlässigkeit und natürlich bei Vorsatz haftet der Arbeitnehmer in vollem Umfang bis zu einer Größenordnung, die ihn in seiner wirtschaftlichen Existenz gefährdet. Die Bedrohung der Datensicherheit tritt im wesentlichen in fünf Formen auf: a) b) c) d) e)

Schaden durch Datenverlust (unbefugtes Löschen) unbefugtes Verändern und Manipulieren betriebswichtiger Daten (Sabotage) unbefugte Nutzung (Lesen, Kopieren) von betrieblichen Daten (Diebstahl) Manipulation von Software (durch Viren, Würmer, etc. siehe [BRU91.]) durch Zerstörung , Diebstahl der Datenverarbeitungsanlagen selbst.

Jede Bedrohung kann gleichzeitig mehrere der o. g. Ziele der Datensicherheit verletzen, z. B. die Manipulation von Software sowohl die Integrität als auch die Verfügbarkeit. Wie gravierend eine der o. g. Bedrohungen ist, hängt von den betroffenen Daten ab; so bedeutet unbefugte Kenntnisnahme bei einer sowieso öffentlichen Online- Datenbank einen wesentlich geringeren Schaden als bei Daten über die Marketingdaten eines neuen Produktes. Einzeln wie auch in ihrer Gesamtheit kann man diesen Bedrohungen wirksam begegnen durch Kenntnis der konkreten Risiken der eigenen betrieblichen Datenverarbeitung und darauf aufbauend ein konzeptionelles klares, realisierbares System von Schutz- und Abwehrungsmaßnahmen.

6.3.4.3 Betriebliche

Datensicherheitsstratesie

Die erforderliche betriebliche Datensicherheitsstrategie umfaßt 4 Schritte Schritt 1: Schritt 2: Schritt 3:

Schritt 4:

Risikoanalyse im Betrieb, Identifikation der Sicherheitssobjekte Bewerten des Risikos Planung geeigneter Maßnahmen zur Abwehr des Risikos (Präventation), Minderung des Risikos und Notfallplan für den Fall stattgefundener Sicherheitsverletzung Durchsetzung des Maßnahmeplanes

6.3.4.3.1 Schritt 1: Risikoanalyse jekte

im Betrieb, Identifikation

der

Sicherheitsobjekte sind • das DV-System und seine Komponenten • das Betriebssystem und seine Komponenten • die Systemdaten (Bibliotheken, Initialisierungsdateien etc.) • Benutzerdaten • Benutzerprogramme • Datentechnik (Kassetten, Disketten, Wechselplatten etc.)

Sicherheitssob-

Teil I Informatik Grundlagen

185

Die Benutzerdaten sollten weiter nach dem Grad ihrer Vertraulichkeit klassifiziert werden. Folgend sei ein Beispiel gegeben: Sicherheitsklasse I (Intern): Telefonverzeichnis Richtlinien Handbücher Sicherheitsklasse II (vertraulich): personenbezogene Daten Umsatz-, Kosten-, Gewinnzahlen Entwicklungsdaten, Produktpläne Sicherheitsklasse III (streng vertraulich): langfristige Planung Marktanalysen Termine für neue Produkte Sicherheitsklasse I V (geheim): Marketing Pläne Strategie Konsolidierte Angaben über Key-Produkte

6.3.4.3.2 Schritt 2: Bewerten des Risikos Benutzerdaten und Datenverarbeitungsanlagen müssen einer Bewertung nach Wert (Wiederbeschaffungswert bzw. bei immateriellen Schäden einer Abschätzung des potentiellen Schadens in Form von Umsatzausfall, Kundenabwanderung u. ä.) auf Einzelobjektbasis unterzogen werden. Daraus erfolgt die Gruppierung der Daten und Datenverarbeitungsanwendungen bei Verlust in •

existenzbedrohend

•

schwerwiegend

•

zu verkraften.

Entsprechend differenziert müssen die Schutzmaßnahmen ausgewählt werden, denn •

nicht alle Daten benötigen besonderen Schutz

•

Datensicherung verursacht (hohe) Kosten

•

Datensicherheit kostet viel Geld, keine fallweise wesentlich mehr!

6.3.4.3.3 Schritt 3: Planung geeigneter Maßnahmen zur Abwehr des Risikos Es kommen als geeignete Maßnahmen in Frage: •

organisatorische Maßnahmen

•

personelle Maßnahmen

•

bauliche Maßnahmen

6 Datenorganisation

186 • •

informationstechnische Maßnahmen Abschluß von Versicherungen zum Auffangen der Kosten bei der Behebung von bereits eingetretenen Schäden

6.3.4.3.3.1 Organisatorische

Sicherheitsmaßnahmen

•

sind generell angemessen zu gestalten, um Mitarbeiter zu motivieren, nicht einsehbare Vorschriften verleiten zu ihrer Umgehung,

•

müssen immanenter und expliziter Bestand der schriftlichen betrieblichen Organweisungen sein, nicht nebenher oder aufgepfropft, weil sie dann nicht beachtet werden; jeder betroffene Mitarbeiter muß schriftlich seine Kenntnisnahme bestätigen,

•

klare Verantwortungsbereichszuordnung in Fragen der Datensicherheit,

•

Unterstellung des Sicherheitsbeauftragten direkt unter die Finnenleitung (Sicherheit als Managementaufgabe),

•

strikte Funktionstrennung zwischen • Programmierung/Nutzung von Programmen, um zu sichern, daß Programme nicht im illegalen Interesse des Nutzers manipuliert werden • Anwendungsprogramm - Nutzer/ Verfügungsgewalt über systemnahe Programme mit weitreichenden Manipulationsmöglichkeiten • Verantwortlichen für Vorgabe und Kontrolle der Sicherheitsstrategie / Ausfuhrende

•

Festlegen der Tätigkeiten, die nur nach dem Vier-Augen-Prinzip vollzogen werden dürfen

•

Definition von Stellvertretern für alle sicherheitsrelevanten Aufgaben (für den Fall von Krankheit, Urlaub etc.)

•

klare schriftliche Festlegungen, welche Mitarbeiter wie (lesend, schreibend, löschend, neuanlegend) auf welche Datenbestände zugreifen dürfen. Es gilt das Prinzip: "Alles ist verboten, Rechte werden ausdrücklich zugebilligt".

•

absolutes Verbot der Fremdnutzung der Rechner sowie des Einbringens von lizenzierter und unbekannter Software (Virengefahr!, vgl. 6.3.6), (ggf. Einrichten eines Quarantänerechners) sowie Verbot jeglicher Software, die nicht zur Arbeitsaufgabe gehört

•

Katastrophenplanung Es ist vorauszudenken, wie im Notfall welche Anwendungen in welcher Reihenfolge wieder in Gang zu bringen sind • wie dies zu erfolgen hat (durch externe Dienstleister, Ausweichpartner, mobile Rechenzentren, eigene "kalte" Rechenzeitkapazität, Wiederbeschafiung etc.) • Verträge abzuschließen

Teil I Informatik Grundlagen • • • • •

187

Wiederherstellen des eigenen Datenverarbeitungsbetriebs: durch Wiederbeschaffung von Hardware bzw. Software welche Systemdateien sind in welcher Reihenfolge wieder einzuspielen Notfalldatenträger mit Mini mal ausstattung vorbereiten (PC-Rettungsdiskette mit Betriebssystem, minimaler autoexec.bat) Sicherheitskopien der Anwendersofitware vorbereiten, nur mit diesen arbeiten, die Originale im Panzerschrank aufbewahren

Organisation der Sicherheitskopien von Daten (Backup-Organisation): • wo befinden sich die aktuellen Datenbestände, in welcher Reihenfolge sind sie einzuspielen • Kopien der wichtigen Daten und Handbücher für den Notfall sind vorzusehen und räumlich getrennt von den Originalen aufzubewahren

Geeignetes Medium für heutzutage anfallende Datenmengen sind StreamerTapes anstelle von Disketten mit Kapazitäten im GB-Bereich. Backup-Software ermöglicht eine Zeitvoreinstellung für den Sicherungslauf (nachts oder in Pausen), so daß der Betrieb kaum behindert wird. Die ausgewählten Datenbestände werden in hochkomprimierter Form auf dem Datenträger geschrieben, können nur als Ganzes auf die HD zurückgeschrieben, aber nicht einzeln selektiert und bearbeitet, z. B. gelesen, werden. Dies unterscheidet Backup-Software von Archivierungssoftware und -datenträger, wo die Kapazitätsleistung zurücktreten gegenüber dem Erfordernis, auf jedes Datum zuzugreifen, um es unverändert reproduzieren zu können. Hierfür sind geeignete optische, einmal beschreibbare Datenträger (WORM, CD-R). Zum Sicherungskonzept gehören weiter die Festlegung der Zahl der Sicherungskopien (Generationen) und der Aufbewahrungsmodus. Als Faustregel empfiehlt sich tägliche Sicherung mit 5 Generationen und eine Zweiwochensicherung, wobei eines der Tagesbänder, z. B. das Freitagsband, doppelt geführt und erst nach 3 Wochen überschrieben wird, so daß im Fall des Falles auf einen relativ weit zurückliegenden konsistenten Datenbestand zurückgegriffen werden kann. Je nach Bewertung der Wichtigkeit korrekter Datenbestände (z. B. im Bankwesen) können wesentlich mehr Generationen und länger zurückliegende Perioden vorgesehen sein. Wird die Generationenzahl zu klein gehalten, besteht die Gefahr, daß die alten, korrekten Daten bereits überschrieben wurden, bevor der Fehler erkannt wurde. Der Wiederaufbau erfolgt ausgehend von einem als korrekt erkannten Datenbestand durch "Forward Recovery", d. h. nochmaliges Erfassen der zwischenzeitlich erfolgten Datenveränderungen anhand der (in jedem Fall aufzubewahrenden) Primärbelege. Ist kein konsistenter Datenbestand mehr verfügbar, kann in wenigen seltenen Fällen durch "Backward Recovery", d. h. Setzen der Daten auf plausible Werte, z. B. 0, ein arbeitsfähiger Bestand zum Weiterarbeiten erzeugt werden. Die Sicherungskopien sind an einen vom Rechner getrennten geschützten Ort aufzubewahren, damit sie bei evtl. Havarien (Bränden u. ä.) nicht mit zerstört

6 Datenorganisation

188

werden. Dieser Dienst, verbunden mit z. B. garantierten Bereitstellungszeiträumen, wird auch von externen Dienstleistern angeboten. Es ist ein Sicherungstagebuch zu führen, in dem die jeweiligen Sicherungszeitpunkte und der Stand der Daten notiert werden, damit die Daten bei Bedarf exakt rekonstruiert werden können. 6.3.4.3.3.2 Personelle

Sicherungsmaßnahmen

Auch mit Verarbeitung von Daten befaßte Mitarbeiter bewegen sich im Spannungsfeld zwischen Pflicht zur qualitätsgerechten Arbeit und Bequemlichkeit, nicht einsehbare Regelungen zu umgehen sowie Spieltrieb, Nachlässigkeit und Unkenntnis. Da die Hauptgefahr für die Sicherheit der Daten nicht von externen Saboteuren, sondern von dem eigenen Personal ausgeht, sind daher überlegte Personalauswahl nach Qualifikation und Motivation sowie Pflege eines guten Betriebsklimas "Pflicht". Alle Betroffenen sind eingehend über die Notwendigkeit angemessener Datensicherungsmaßnahmen und den Umgang damit zu informieren, um ihre Akzeptanz zu bewirken. Die Abhängigkeit von einzelnen Experten, z. B. Systemprogrammmierern ist, auch aus Gründen der Kontinuität der Arbeit bei Urlaub, Krankheit, Kündigung, zu vermeiden, indem möglichst das 4-Augen-Prinzip angewendet wird, Mitarbeiter sich gegenseitig kontrollieren und ihre Arbeit dokumentieren auch im System und schließlich auch Vorgesetzte über EDV-Kenntnisse verfügen sollten, damit ihnen das Heft des Handelns und Beurteilens, z. B. von Aufwand, nicht aus der Hand genommen wird. Mitarbeiter externer Betriebe sind, z. B. bei Wartungsarbeiten, genau zu beaufsichtigen. Eigenen Mitarbeitern, denen gekündigt wurde, ist auf der Stelle der Zugang zum Rechner zu verwehren, da hier Fälle von Computersabotage aus Frust bekannt sind. Dies bedingt, einen geeigneten kompetenten Ersatz zur Verfügung zu haben. 6.3.4.3.3.3 Bauliche Sicherungsmaßnahmen Es ist zu achten auf • • •

Verschließbarkeit der Räume, in denen Rechentechnik steht einbruchhemmende Fenster präventiven Brandschutz entsprechend üblicher deutscher Sicherheitsvorschriften und Bereithalten spezieller Feuerlöscher für Rechner, um Schäden durch Rauchentwicklung und Löschmittel zu vermeiden (C02-Löscher)

•

Auslagerung leicht entflammbarer Materialien, z. B. Papier aus Druckerräumen Installation einer USV (unabhängige Stromversorgung), insbesondere beim Betrieb von Rechnernetzen, um bei Netzbetriebsstörungen eine geordnete Beendigung des Rechnerbetriebs (Rücksetzen unbeendeter Transaktionen, Schreiben von Pufferinhalten auf Festspeicher etc.) zu ermöglichen.

•

Teil I Informatik Grundlagen

6.3.4.3.3.4 Informationstechnische

189

Sicherheitsmaßnahmen

Wenngleich der korrekten Arbeitsdurchführung und -Organisation die höchste Bedeutung bei der Datensicherheit zukommt, gewinnen in die Hard- und Software eingebettete Mechanismen zur Erzwingung bestimmter Arbeitstechniken und -beschränkungen immer stärker an Bedeutung. Dazu zählen •

Ausschluß des Nutzers von der vollen Funktionalität des Betriebssystems und seiner gefahrenträchtigen Funktionen sowie von der Nutzung mächtiger Tools und eigener Exe-Dateien durch Zwischenschaltung zusätzlicher speziell konfigurierter Benutzeroberflächen nach dem Rechnerstart (geeignet vor allem im Einzelplatzbetrieb, MS-DOS-Betrieb, wo aus historischen Gründen keine Sicherheitsmechanismen implementiert sind).

•

im Netzbetrieb bei konkurrierendem Zugriff auf gleiche Rechnerressourcen sind bereits vom Betriebssystem verschiedene Modi des Zugriffs auf Dateien und Verzeichnisse (lesend, schreibend, ausführend) vorgesehen (vgl. 5.3.2), die in individueller Kombination jedem einzelnen Nutzer bzw. Gruppen von Nutzern mit gleichen Rechten zugebilligt werden und bei jeder versuchten Ausübung geprüft werden (Rechteverwaltung und -prüfung). Kritisch bleibt, daß diese Rechte nur von einem Mitarbeiter mit allumfassenden Rechten (dem Systemadministrator) vergeben werden können, dem damit eine extreme Vertrauensstellung zukommt.

•

jeder zugelassene Nutzer muß im System registriert sein und bei seinem Login beweisen, daß der derjenige ist, der er zu sein vorgibt und dessen Rechte er in Anspruch nehmen will (Authentisierung von Personen). Dies erfolgt durch Abfrage einer Information, über die eigentlich nur der Betreffende verfugen kann, • entweder durch Besitz • oder durch Wissen • oder durch biologische Eigenschaften.

Besitz kann sein eine Magnetkarte o. ä.; Wissen betrifft am häufigsten Paßwörter, aber auch Kenntnis von Algorithmen. Zu den biologischen Verfahren zählen Unterschrift, Fingerabdruck, Augenhintergrund, Sprachmuster, sie befinden sich noch nicht im Zustand der Praxisreife. Auch kombinierte Verfahren (Hybridverfahren), z. B. aus Magnetkarte und Paßwort (PIN = Personal Id. N) werden angewandt. Für die Wahl eines einigermaßen sicheren Paßwortes ist zu beachten: • •

Mindestlänge 6 Zeichen in einer Mischung von Buchstaben und Sonderzeichen keine Paßwörter mit Bedeutungen aus dem Umfeld des Besitzers (Namen von Familienangehörigen, Automarke, Zigarettenmarke etc.)

190 • •

6 Datenorganisation erzwungener Wechsel in regelmäßigen Abständen (z. B. in Software realisiert) keinesfalls Weitergabe und Notieren am Arbeitsplatz (das Paßwort des Systemadministrators muß jedoch im verschlossenen Umschlag im Panzerschrank des Betriebes für Notfälle verfügbar sein!)

Um leichte Merkbarkeit beizubehalten, werden bekannte Worte empfohlen, in denen die Vokale weggelassen werden (Pppnhmr) oder Zahlen, die sich durch einen einfachen Algorithmus aus z. B. einem Geburtstag ergeben (z. B. 5.5.48 zu 585548 durch Summe der Einzeldaten). Dennoch sind reine Paßwortverfahren nicht sicher vor Ausspionieren. Im Bereich des electronic banking werden Einmal-Paßwörter angewandt (die TAN: Transaction Code Numbers). Jede Überweisung wird durch eine neue TAN gesichert, so daß auch Abhören keinen Sinn macht. Die Verwaltung ist jedoch aufwendig.

6.3.4.3.4 Schritt 4: Durchsetzung des Maßnahmeplanes Der Maßnahmeplan kann nur unter aktiver Einbeziehung und Motivierung aller Mitarbeiter erfolgreich umgesetzt werden. Seine Einhaltung bedarf strenger Kontrolle. Unterstützung bei der Einarbeitung geben im Bedarfsfall externe Sicherheitsberatungen.

6.3.5 Verschlüsselung und Sicherheit in Rechnernetzen Eine spezielle zentrale bereits aus der Antike bekannte Technik der Datensicherheit ist Verschlüsselung (Kryptographie). Ihr ist der nächste Abschnitt gewidmet. Eine Alternative zu aufwendiger Kontrolle und Beschränkimg des Zugriffs zu Daten ist ihre Verschlüsselung, die bewirkt, daß ohne Kenntnis des Schlüssels auch bei unbefugter Kenntnisnahme/Diebstahl von Daten ihre inhaltliche Bedeutung nicht reproduziert werden kann. Das gleiche gilt für den Dateniluß in Rechnerverbund- und Kommunikationssystemen, so daß dem Autor diese Technik als zukunftsträchtigste im Bereich der Datensicherheit gilt. Entsprechend versuchen regierungsamtliche Stellen, durch Setzen von Standards etc. den Fuß in der Tür zu behalten (vgl. Clipper-Initiative USA [CLI]). Zur Verschlüsselung dienen Kryptosysteme. Kryptosysteme sind hardware- oder softwaremäßig realisierte Algorithmen, die mit Hilfe von Parametern (Schlüssel, Key) die Zeichen einer Nachricht derart transformieren, daß aus der transformativen Nachricht nicht auf den Inhalt des Originals geschlossen werden kann. Dabei kann der Algorithmus durchaus allgemein bekannt und publiziert sein. Der sensible Punkt ist die Erzeugung und Kenntnis des Schlüssels bzw. seine Geheimhaltung. Das Key-Management unterscheidet den Vorgang der Ver-

Teil I Informatik Grundlagen

191

Schlüsselung von dem der Codierung, wo nur Zeichen in das Alphabet eines anderen Codes transformiert werden, aber die Rückführung ohne Problem möglich ist. Man unterscheidet je nach der Möglichkeit der Rückgewinnung der Information reversible Chiffrierung. irreversible (Einweg) Die irreversible Chiffrierung findet Anwendung in dem Fall, wo Daten zu ihrer Sicherheit verschlüsselt werden müssen, aber Entschlüsselung nicht erforderlich ist, z. B. beim Vergleich von Nutzerpaßworten. Reversible Chiffrierung ermöglicht die Rückgewinnung der originalen Information. Je nach Zahl der benötigten Schlüssel handelt es sich um symmetrische Chiffrierung unsymmetrische

^ ^

Bei herkömmlichen symmetrischen Verfahren wird ein und derselbe Schlüssel zur Verschlüsselung und Entschlüsselung einer Information verwendet. Sei mit K (Info) die Verschlüsselung bezeichnet, so gilt K (K(Info)) = Info. Soll der verschlüsselte Text einem Empfanger zugesandt werden, z. B. über ein Kommunikationsnetz, stellt sich das Hauptproblem, dem Empfänger auch den Schlüssel ohne Kenntnisnahme Dritter zukommen zu lassen, z. B. durch Kuriere oder getrennte Übersendung von Chipkarte und PIN. Eine grundlegende neue Möglichkeit des Schlüssel-Managements unter Vermeidung dieses Problems bietet sich bei unsymmetrischen Verfahren durch Anwendung zur Verschlüsselung bzw. Entschlüsselung an. Bei diesen Public-KeySystemen wird ein Schlüsselpaar erzeugt (Kp, Kg), wofür

gilt

K p (K§ (Info)) =

Info

und

K§ (Kp (Info)) =

Info;

der Nutzer erhält seinen geheim zu haltenden "secret Key"; das "Gegenstück" Kp, der "public Key" dieses Nutzers, kann sogar in einem öffentlich zugänglichen Register (Directory) veröffentlicht werden. Damit kann einem Empfanger gezielt eine verschlüsselte Information gesandt werden, ohne ihm gleichzeitig auf unsicheren Kanälen den Schlüssel übergeben zu müssen, indem der Sender den ohnehin bekannten "public Key" des Empfängers benutzt und nur dieser bereits im Besitz des zugehörigen privaten „secretKey" ist, der das Entschlüsseln erlaubt. •

Die bekannteste Implementierung symmetrischer Verfahren ist der DESAlgorithmus [DES], der Schlüssel der Länge 64 bit verwendet und sowohl hard- als auch sofitwarebasiert sehr schnell arbeitet. Trotz heutigen Lei-

192

6 Datenorganisation

stungsstandes der Technik gilt er als sicher und als Methode der Wahl bei der Dateiverschlüsselung, wenn der Schlüssel über einen sicheren Kanal zu übergeben ist. •

Die bekannteste Implementierung unsymmetrischer Verfahren ist der RSAAlgorithmus [ RSA], dem ein komplizierter mathematischer Sachverhalt zugrunde liegt, weswegen er langsamer als symmetrische Verfahren arbeitet und daher ungeeignet für die Übermittlung von großen Datenmengen, speziell im Netz, bleibt. Er bietet jedoch eine Lösung für das Schlüsselmanagement bei symmetrischen Verfahren an, indem • die eigentliche Information symmetrisch verschlüsselt wird (schnell) • der Schlüssel mit dem public Key des Empfangers verschlüsselt übertragen wird (hybrides Schlüssel-Management).

Darüber hinaus können asymmetrische Verfahren zur elektronischen Nachbildung der Unterschrift (electronic signature) dienen und damit eine Aufgabe lösen, die als zwingende juristische Ergänzung der technischen Möglichkeit dient, Dokumente mit rechtlicher Tragweite nicht länger in Papierform zu versenden, sondern digitalisiert (Bestellungen, Zahlungsanweisungen, Verträge etc.). Man fordert von diesen Dokumenten, daß sie • • •

einem Verursacher unableugbar zuzuordnen sind, den Willen des Verursachers ausdrücken, ausgedrückt durch Unterschrift, integer sind, d. h. der Wille des Verursachers nicht von anderen modifiziert oder verkürzt wurde.

Dazu wird a) eine Prüfsumme über das Dokument gebildet (Details in [SB92]), b) diese Prüfsumme mit dem secret key des Verursachers verschlüsselt, c) dieser "Header" zusätzlich zum Dokument mit versandt. Beim Empfänger kann a) jedermann anhand des public key-Verzeichnisses prüfen, ob der angegebene Absender stimmt, b) man mittels des public key den originalen Wert der Prüfsumme reproduzieren, c) aus dem vorliegenden Dokument in unabhängiger Weise die Prüfsumme neu ermitteln. Bei Gleichheit beider Prüfsummen wird auf die Unversehrtheit der Nachricht geschlossen. Diese Technik deckt jedoch nicht die Forderung nach Vertraulichkeit der Übermittlung ab, sondern muß mit einer der o. g. Techniken kombiniert werden. Mit dem gleichen Prinzip bietet sich auch eine hochwertige Lösung des Authentisierungsproblems gegenüber einem Rechner mittels eines Challenge-ResponseVerfahrens. Der Rechner muß hierzu die public key der potentiellen Nutzer kennen. Er produziert bei gewünschtem Zugriff eine Zufallszahl, die mittels des

Teil I Informatik Grundlagen

193

secret key des Nutzers verschlüsselt wird. Bereitstellung des secret key und Chiffrierung können von einer Chipkarte übernommen werden. Im Rechner kann die Verschlüsselung mittels des public key rückgängig gemacht werden und im Fall der Übereinstimmung beider Zufallszahlen wird Zugriff gewährt [ISO 9798], Offen ist derzeit die unfälschbare unverwechselbare Zuordnung eines Schlüsselpaares zu einem Individuum, was nur durch eine landesweite Vergabeinstanz (Trusted Third Party) garantiert würde und noch Diskussionen unterliegt. Nur lokale Implementierungen (auf Organisationsebene) sind bekannt.

6.3.6 Maßnahmen zur Abwehr von Software-Manipulationen, z. B. durch Computer-Viren Gefahren drohen der Datenverarbeitung nicht nur durch Nachlässigkeit von Mitarbeitern, sondern auch durch vorsätzlich manipulierte Software, die nicht mehr ausschließlich ihre vorgesehene Aufgabe erfüllt, sondern Nebeneffekte besitzt, die vom einfachsten Fall, der spaßigen Ausschrift am Bildschirm bis zum vorsätzlichen Löschen von Dateien und zum Systemabsturz reichen. Ursprünglich aus dem Studium verschiedener Programmiertechniken entstanden, hat sich bedauerlicherweise eine ganze Gemeinde junger Programmierer aus falsch verstandenem Sportsgeist dem Herstellen immer raffinierterer zerstörerischer Programme verschrieben. Zum heutigen Zeitpunkt sind nicht weniger als 6000 bekannt. Nach ihren Eigenschaften wird solche Manipulations-Software (SabotageSoftware, schadenstiftende Software ) gegliedert in • • • • • • •

Wanzen Minen und Pilze Bomben Hintertüren Würmer Trojanische Pferde Viren

den sog. Virenzoo. "Wanzen" oder "bugs" sind Programmierfehler, die einen Unterschied zwischen Spezifikation und Realisation eines Programmes bewirken. Sie können Manipulationsmöglichkeiten zur Folge haben, insbesondere wenn sie absichtlich in ein Programm eingebracht werden (z. B. Erlangung der Rechte des Systemadministrators). "Minen" sind Programme, die ihre lästigen, zerstörerischen Wirkungen beim Start oder nach Eintritt einer bestimmten Auslösebedingung entfalten, aber keinen Fortpflanzungsmechanismus haben.

194

6 Datenorganisation

"Pilze" sind Minen, die darüber hinaus die Fähigkeit besitzen, sich auf weitere Datenträger und in fremde Systeme zu kopieren, "Bomben" fuhren die erwartete Programmleistung solange aus, bis durch Erfulltsein einer Bedingung ("Zündung") das - vom Programmierer gewollte Fehlverhalten wirksam wird. "Hintertüren" sind Programme, die zusätzlich einen nichtautorisierten Zugang besitzen, mit dem man die Zugangs- und Rechteprüfung umgehen und sich unzulässige Privilegien aneignen (bzw. behalten) kann. "Würmer" sind Programme, die aktiv in Netze eindringen, sich im Hauptspeicher eines Rechners vervielfältigen und starten. Ihre Hauptaktivität ist die Weiterverbreitung, wobei Rechner auch mehrfach befallen werden können, und ihr Hauptschaden das "Verstopfen" der Hauptspeicher und der Verbrauch der Prozessorleistung zu ihrer Reproduktion, statt der normalen Jobs, was zu erheblicher Verlangsamung der Systeme fuhrt. Bekanntestes Exemplar ist der Internet-Wurm (1988). "Trojanische Pferde" sind Programme, die neben ihrer seriösen bekannten Funktion weitere nicht dokumentierte, vom Manipulator vorsätzlich zugefiihrte schadensstifitende Funktionen haben (im Gegensatz zu "Wanzen", deren Schadenfunktion unbeabsichtigt entsteht). Sie reproduzieren sich nicht selbständig. Häufig wird der Nutzer mit einem interessanten Erstzweck getäuscht, z. B. als Antivirenprogramm oder als Benchmarktest, das dann selbst einen Virus verbreitet. "Computer-Viren" sind unselbständige Programmstücke (Routinen), die sich (wahlfrei oder gezielt) an Anwenderprogramme ankoppeln können. Durch Selbstverschlüsselung können sie sich oder andere Maßnahmen gegen Entdekkung tarnen und durch Mutation ihr Aussehen stark verändern. Sic rufen typische Wirkungen hervor, wobei entweder vorübergehende oder dauerhafte Schäden beobachtet werden. Da Viren stets die bekannten Funktionen des von ihnen befallenen Anwenderprogramms ändern, stellen sie stets eine Manipulation dar [Bru91], Grundaufbau eines Virus: 1. Initialisierung Dieser Teil prüft, ob im anvisierten Programm der Virus bereits vertreten ist, veranlaßt nur bei negativem Ausgang den Befall und kennzeichnet ihn durch gewisse Merkmale (Bitfolgen, Veränderung in Datei-Informationen, wie Erstellungszeit u. ä.). 2. Infektionsteil Dieser Teil bewirkt, daß bei Aufruf des Trägerprogramms der Virus an ein weiteres startbares Programm kopiert wird. 3. Ereignisüberwachung (Trigger)

Teil I Informatik Grundlagen

195

Der Schadenseffekt wird nicht bei jedem Start des Trägerprogrammes ausgelöst, sondern in Abhängigkeit von gewissen Bedingungen (Datum, Anzahl, Systemaufrufe etc.). 4. Wirkteil Dieser Teil ist für das eigentliche Ziel des Virus, einen Schaden oder Schabernack anzurichten, zuständig. Die Effekte reichen von harmlosen BildschirmAnschriften über das Herunterfallen von Buchstaben bis zum unkontrollierten Zerstören von Dateien. Der Aufbau widerspiegelt genau die Intentionen der Virenprogrammierer, die bestehen in •

möglichst starker Verbreitung, verbunden mit hoher Tarnung, damit der Virusbefall nicht vorzeitig auffallt, erreicht durch triggergesteuerte Auslösung der Wirkung, so daß ein Virus bereits lange Zeit im System existieren und sich verbreiten kann, ohne daß er durch seine Wirkung bemerkt wird,

•

effizienter Verbreitung, indem gesichert ist, daß ein Programm nicht mehrfach von einem Virus infiziert wird, was aber nicht ausschließt, daß es von mehreren Viren gleichzeitig befallen werden kann.

Um die Vielzahl existenter Viren überschauen zu können, werden sie nach der Art und Weise der Infektion klassifiziert:

Abb. 1-6.3-1 Virenklassifikation Hier sind mehrere Klassifikationen parallel dargestellt. Es kann also z. B. einen Bootvirus geben, der den Bootsektor befallt und sich Stealth-Mechanismen be-

196

6 Datenorganisation

dient oder einen Linkvirus, der sich zusätzlich resident installiert und StealthTechniken nutzt. Überschreibende Viren kopieren sich auf den Anfang einer ausführbaren Datei. Da hierbei der Original-Code des Programms zerstört wird, ist der Virus bald auch ohne Wirkteil offensichtlich. Diese Viren sind nahezu ausgestorben. Nicht überschreibende Viren kopieren ihren Code ans Ende des betroffenen Programms oder eine ähnlich sichere Stelle und setzen nur einen Sprungbefehl auf sich selbst an den Anfang des Programms, so daß zuerst ihr Code abgearbeitet wird, danach das eigentliche Programm. Auf jeder formatierten Diskette steht im 1. Sektor (dem Bootsektor) ein kurzes Programm, mit dem weitere Sektoren an eine bestimmte Adresse im Speicher geladen werden, das mit dem Format-Befahl erzeugt wird, gleichgültig, ob eine Systemdiskette oder nicht erzeugt wird. Bei Festplatten ist der Bootsektor nicht festgelegt, sondern wird der Partitiontabelle entnommen. Da Rechner fast immer zuerst von Laufwerk A: booten, schreibt sich bei jedem Zugriff auf den Bootsektor ein eventueller Bootvirus sofort in den Hauptspeicher (auch wenn danach evtl. die Meldung erscheint: "Keine Systemdiskette .... "o. ä.) und infiziert danach den Partitionsektor, wobei er vorhandene Dateien an eine andere Stelle auf dem Datenträger umspeichert. Der Virus lauert dann auf einen Diskettenwechsel und infizierte jedoch nicht verseuchte Diskette. Wurde der Rechner ausgeschaltet, wird beim Einschalten der Virus im Partitionsektor aktiviert. Da Bootviren bereits vor dem eigentlichen Laden des Betriebssystems die volle Kontrolle übernehmen, ist der Einsatz von Virensuchprogrammen schwierig. Es ist äußerst wichtig, bei ihrem Einsatz den Rechner von einer garantiert virenfreien, schreibgeschützten Systemdiskette zu booten. Hybridviren verfugen über beide genannte Mechanismen und müssen daher an beiden Fronten gleichzeitig bekämpft werden. Directory-Viren ändern den Zeiger auf den 1. Cluster einer infizierten Datei auf sich selbst und sichern den ursprünglichen Wert. Beim Start der infizierten Dabei wird dann zuerst der Virus aktiviert, der wiederum das ursprüngliche Programm nachlädt. Dadurch entfallen Dateilängenveränderungen, die von vielen Antivirenprogrammen beobachtet werden. Andererseits würde ein Aufruf von Chkdsk melden, daß viele Cross-Links vorhanden sind, da der erste Cluster aller verseuchten Dateien nun gleich ist. Die tatsächlichen Startcluster dieser Dateien können nach Entfernen des Virus nicht wiederhergestellt werden. Im Gegensatz zu nichtresidenten Viren installieren sich residente Viren zusätzlich resident im Hauptspeicher und "verbiegen" die Interruptvektoren, d. h. die Startadressen häufig benutzter Systemprogramme, z. B. das Timer-Interrupt 08H oder Int 13H (BIOS-Lesen/Schreiben). Der Interrupt zeigt dann zunächst auf den Virus-Code und erst nach dessen Start wird die eigentlich zugehörige Routine aktiviert. Daraus resultiert eine besondere Aggressivität der residenten Viren, da sie sich im Gegensatz zu nichtresidenten, nicht nur per Zufall, sondern in Ver-

Teil I Informatik Grundlagen

197

bindung mit sehr häufig vorkommenden Systemoperationen weiterverbreiten. Die Mehrzahl aller bekannten Viren ist speicherresident. Tarnmechanismen ermöglichen den Stealth-Viren, ihre Existenz zu verschleiern: bei allen Zugriffen auf verseuchte Programme bzw. Bootsektor wird nur der Originalinhalt incl. Länge und Attribute zurückgegeben, indem die OriginalSektoren auf "schlechte" Sektoren ausgelagert werden. Polymorphe Viren schließlich als modernste Gattung lassen sich so modifizieren, daß durch mutierende Verschlüsselung keine Kopie ihrem Vorgänger gleicht und im Prozeß für jede denkbare Kopie ein eigener Suchalgorithmus entworfen werden muß, so daß ihre Entdeckung extrem erschwert wird. Eine Übersicht gegenwärtig aktueller Viren übersteigt den Rahmen dieses Buches und kann in Spezialliteratur [Bru91] gefunden werden. Von hohem praktischen Interesse ist dagegen ein Schutzkonzept gegen Virenbefall: Wie im biologischen Bereich, werden 3 Ebenen unterschieden: a) Prophylaxe b) Diagnose c) Bekämpfung Alle Maßnahmen müssen sich in die klassischen Datenschutzstrategie des Unternehmens integrieren bzw. andersherum: wenn die bisher genannten Datenschutzmaßnahmen konsequent und motiviert durchgesetzt werden, ist ein großer Teil Virenprophylaxe erreicht. Zur Prophylaxe zählen: a) Aufklärung und Sensibilisierung der Mitarbeiter und Führungskräfte b) regelmäßige Backups von Daten und Programmen c) nur Programme aus zuverlässigen Quellen verwenden, grundsätzliches Verbot privater Disketten d) Software nur von Kopien der Originaldisketten installieren e) Test von eingehender Software auf isolierten Testrechnern f) Disketten permanent schreibschützen (außer bei gewolltem Schreibzugriff) g) Daten- und Programmdisketten trennen h) Dateien auf Festplatte mit Lage, Länge und Erstellungszeit protokollieren i) Plan anlegen, welche Programme und Daten in welcher Reihenfolge im Notfall reinstalliert werden (Havarietraining) j) keine Diskette beim Booten im Laufwerk A: belassen k) nie von Diskette booten bzw. bei Anti-Viren-Software ausschließlich von schreibgeschützter Original-Betriebssystem-Diskette booten 1) Programme verschlüsseln und nur für Programmablauf entschlüsseln m) regelmäßige Überprüfung von Festplatten und Disketten mit Anti-VirenSoftware n) Einsatz von Viren-Warnprogrammen und/oder Hardwareschutz Ein Großteil ordnet sich in die üblichen organisatorischen Sicherheitsmaßnahmen ein. Hinzu kommen technische Möglichkeiten, die über Anti-Viren-

198

6 Datenorganisation

Software realisiert werden. Auch gehört zur Prophylaxe, auf Unregelmäßigkeiten bei Programmausführung zu achten, z. B. • • • • • • • • •

Auftauchen von Dateien, die weder Nutzer noch System erzeugt haben spurloses Verschwinden von Dateien Anzahl schlechter Sektoren nimmt sprunghaft zu Verlängerung befallener Programme verlängerte Startzeit des Betriebssystems vermehrte Lesefehler des Betriebssystems unmotivierte Anzeige, daß Speicherplatz zur Neige geht unmotivierte Systemabsturze und natürlich Auffälligkeiten wie unerwartete Bildschirm-Ausschriften, Melodien etc.

Virenpanik ist jedoch unangebracht, die meisten Effekte können auch ganz gewöhnlichen Bedienfehlern, wie Formatieren, zuzurechnen sein. Bei Antiviren-Software gibt es drei grundsätzliche Funktionsprinzipien, die in den käuflichen Produkten in verschiedenen Kombinationen verwirklicht sind: a) Viren-Scanner b) Prüfsummenprogramme c) Viren-Wächter (~ Warnprogramme) Scanner verwenden zur Suche nach vorhandenen Viren typische Bytesequenzen (Signaturen). Für die Qualität eines Scanners ist ausschlaggebend, möglichst viele Virenkennungen einzuschließen. Jedoch ist die Diagnose eines Virenscanners nie vollständig, sondern erfaßt nur die zu einem bestimmten Zeitpunkt bekannten Viren, ist also ständig im Nachtrab und veraltet extrem schnell. Etwa aller 3 Monate muß ein Update eines Scanners gekauft werden. Bei Prüfsummenprogrammen wird bei der Ersterfassung ftir jede angegebene Datei eine charakteristische Zahl (Prüfsumme, Fingerabdruck) gebildet und gespeichert, die bei jedem weiteren Lauf des Prüfprogrammes mit den aktuell gebildeten Prüfsummen verglichen werden. Sehr nützlich in bezug auf die Erkennung von Bootviren ist die Einbeziehung der Bootsektoren und Partitionstabelle (n). Jedoch wird nur festgestellt, daß eine Manipulation vorliegt, nicht aber, durch welchen Vorgang. Dieser kann ebenso durch Updates von Programmen oder Neucompilation geschehen. Wächterprogramme schließlich installieren sich speicherresident und überwachen kritische Aktivitäten, die von Viren ausgelöst sein könnten, wie Schreiboperationen auf Diskette, indem sie die entsprechenden Systemaufrufe (z. B. Interrupts 21H, 27H) auf sich umlenken und Alarm schlagen. Es kann aber für den Nutzer sehr lästig sein, ständig zu entscheiden, ob eine Schreiboperation gewollt ist oder nicht.

Teil I Informatik Grundlagen

199

Es empfiehlt sich eine Kombination von einem Prüfsummenprogramm sowie mehreren Virenscannern. Die Phase der Bekämpfung muß überlegt und frei von Panik stattfinden. Die komplette Grundformatierung der Festplatte richtet gewöhnlich mehr Schaden an als der Virus jemals. Folgende Schritte haben sich bewährt: a) b) c) d) e) f)

Computer ausschalten ("tötet" Viren im Hauptspeicher) von schreibgeschützter Orignal-Systemdiskette neu booten keinen Programmstart von der Festplatte!! falls nicht vorhanden, Backup aller Daten der Festplatte herstellen die Art des Virus mittels Scanner genau bestimmen bei Dateiviren betreffende Programme löschen und von Originaldisketten neu installieren, die delete-Option der Anti-Virenprogramme kann evtl. Schaden anrichten! g) Bei einem Bootvirus den Bootsektor mittels der Übertragung eines sauberen Systems wieder neu aufbauen h) erneuter Test mit mehreren Antivirenprogrammen, um den Erfolg zu testen i) Stillschweigen über den Vorfall bewahren! Es sind schon Betriebe in Schwierigkeiten gekommen, weil Virenbefall bekannt wurde.

Detaillierte Strategien kann man der zahlreich vorhandenen Literatur [Bru91] entnehmen. Schließlich besteht die Möglichkeit, externe Hilfe in Anspruch zu nehmen, so • • • • •

Bundesamt für Sicherheit in der Informationstechnik Bonn Virus-Test-Center Universität Hamburg Micro-BIT-Virus-Center in Karlsruhe "European Institute für Computer Anti-Virus-Research" ECIAR in München und" „Computer Anti-Virus Research Organization" (CARO) in Hamburg.

7. Einführung in die Programmierung 7.1 Prozedurale und nichtprozedurale Programmierung Dieser Teil bezweckt nicht die detaillierte Vermittlung der Syntax einer Programmiersprache, da seit dem Ersterscheinen sowohl Angebot als auch Technologien der Programmiersprachen so an Komplexität zugenommen haben, daß weder eine eindeutige Empfehlung, noch eine hinreichende Darstellung mehr möglich sind (vgl. auch Kap. 3.2). Wohl aber wird der Leser mit Konzepten, Grundstrukturen und Darstellungsmitteln in dem Maße vertraut gemacht, das der Betriebswirt braucht, um seine zu programmierende

200

7 Einführung in die Programmierung

Aufgabenstellung in ihrer Logik zu erkennen und eindeutig in einer Form niederzulegen, die dem professionellen Programmierer die Umsetzung in eine passende Programmiersprache ermöglicht. Es geht also um das Erlernen der gemeinsamen "Schnittstelle" zwischen Auftraggeber und Programmierer. Die Phase der Formulierung der Logik betrieblicher Prozesse ist als Teil eingebettet in den Gesamtvorgang von Entwurf bis Implementation betrieblicher Informationssysteme (vgl. Teil II).

7.1.1 Rolle von Algorithmen 7. /. 1.1 IVas ist programmieren Bevor es zum Programmieren kommt, muß neben der Problemanalyse und der Zielstellung die organisatorische Lösung des Problems in etwa feststehen. Dies erfordert sowohl erhebliches Vertrautsein mit den fachlichen Gegebenheiten und Möglichkeiten als auch das Vermögen, verschiedene Wege zum Ziel gegeneinanderzustellen und frei für alternative Wege zu sein. Diese Fähigkeit kommt vorrangig dem Fachwirt, niemals dem Programmierer isoliert zu. Teams haben sich bewährt. Aus dieser Situation wird der Lösungsweg mehrstufig in immer stärker formalisierter Weise niedergeschrieben: Programmieren heißt, für eine gestellte Problemklasse unter ausschließlicher Zuhilfenahme zulässiger Aktionen einen Lösungsalgorithmus zu finden. Ein Algorithmus ist eine endliche eindeutige Schrittfolge von Aktionen, die als allgemeines Verfahren die Lösung einer Klasse von Problemen zum Ziel hat. Der Umfang der Beschreibung ist endlich. Der Algorithmus selbst kann im Prinzip unendlich viele Schritte haben. Es muß dann eine Abbruchbedingung, z.B. die minimale Größe einer noch zu erzielenden Verbesserung einer Zielfunktion, eingefugt werden, um ein Ergebnis in endlicher Zeit zu erhalten. Auf jeder Stufe des Algorithmus ist der nächste Schritt unmißverständlich formuliert. Der Algorithmus ist eindeutig und deterministisch. Probleme einer Klasse besitzen die gleiche logische Struktur, sie unterscheiden sich nur in ihren Daten. Der Algorithmus darf nicht von einer konkreten Datenkonstellation abhängen, um allgemein zu sein. Aktionen sind zulässig im Sinne der sachlichen Richtigkeit und Möglichkeit im fachlichen Kontext, im Sinne der gewählten Programmiersprache, d. h. die Aktion muß als Konstrukt der Sprache existieren oder sich aufbauen lassen, sie muß exakt die inhaltliche Aktion widerspiegeln und sie muß effizient sein (siehe unten) im Sinne des Programmierstils (vgl. 7.2) (z. B. keine goto) In einem 2. Schritt kann der Algorithmus verfeinert werden, ehe er schließlich im 3. Schritt 1:1 in die Konstrukte der Programmiersprache übertragen wird (Codierung des Algorithmus). Erfahrungsgemäß werden diese Schritte mehrfach wiederholt, wenn sich erweist, daß das lauflahige Programm nicht exakt der

Teil I Informatik Grundlagen

201

Vorgabe entspricht, oder, was wahrscheinlich ist, während der Algorithmierungs- und Codierungsphase sich die Vorgaben für das Programm geändert haben. Ein Programm ist die Darstellung der Aktionen eines Algorithmus in einer für die Aufgabenstellung geeigneten Programmiersprache, in der es für die Aktionen des Algorithmus geeignete Sprachelemente gibt.

7.1.1.2 Optimierung

von

Algorithmen

Wichtiger Bestandteil des Algorithmierens ist die Verwirklichung zeitoptimaler Lösungen, weil auch durch rasante HW-Entwicklung (immer schnellere Prozessortaktungen) nicht die Nachteile aufgewogen werden können, die durch wenig intelligente Algorithmen entstünden. Algorithmen gliedern sich aus dieser Sicht in Abschnitte, die aus fachlichen Gründen in einer eindeutigen Weise ablaufen müssen und kaum optimierungsfähig sind, und in Abschnitte, in denen allgemeine, in mathematischer Formulierung vorliegende Verfahren auf die konkrete fachliche Aufgabe angewendet werden. Hiermit sind hauptsächlich • • •

allgemeine Zugriffsverfahren auf Datenbestände Sortierverfahren Verfahren des Operations Research

gemeint. Für jede dieser Aufgaben gibt es mehrere Verfahren mit unterschiedlichem Zeitverhalten. Hier muß ein Verfahren mit günstigem Zeitverhalten ausgewählt werden, um den gesamten Algorithmus zu optimieren. Die Bewertung von Algorithmen erfolgt durch die Rechenzeit T(n) in Abhängigkeit von der Zahl n der bearbeiteten Datenelemente. Vereinfacht dargestellt drückt man die Bewertung durch eine asymptotische Aussage T ( n ) ~ O(foD) aus, die bedeutet, daß für immer mehr Datenelemente n die Rechenzeit nicht stärker als die Funktion f (n) wächst, f (n) eine obere Schranke darstellt. Bekannte obere Schranken sind log (n), n * log (n), n, n2 und exp (n). Die Zeitkomplexitäten 0 (f (n>) verhalten sich wie 0 (log (n) )
1_000.00 T H E N . . .

Abb. 1-7.2-4 Objekt „Konto 1 '

Die Manipulation erfolgt dadurch, daß die in der Definition von Kontol als Komponenten definierten Operationen auf Kontol angewendet werden. Das generelle Schema einer solchen Manipulation ist:

Objektidentifikation. Operationsidentifikation (Parameter)

Im obigen Beispiel wird auf Kontol zuerst eine Gutschrift mit dem Betrag 2 350.75 ausgeübt und dann eine Lastschrift mit dem Betrag 225.30. Der Kontostand beträgt dann also 2 125.45. Die anschließende Abfrage in der Fallunterscheidung „IF Kontol .Konstostand() > 1_000.00" ist daher erfüllt, und es wird die Aktion nach THEN ausgeführt. 7.2.3.2 Öffentliche

und interne

Komponenten

Betrachtet man die Definition von Kontol in Abb. 1-7.2-2 genauer, dann stellt man fest, daß die Komponenten von Kontol in zwei Abschnitten notiert sind: zwischen OBJECT und INTERNAL und zwischen INTERNAL und END OBJECT. Der erste Abschnitt wird als öffentlicher Abschnitt bezeichnet und infolgedessen die darin notierten Komponenten als öffentliche Komponenten. Im Beispiel sind dies der Typ BetragsTyp und die Prozeduren Gutschrift, Lastschrift, Kontostand und Kontoinhaber. Im Programmtext außerhalb der Definition von Kontol können nur die öffentlichen Komponenten verwendet werden. Die Benutzung der Prozeduren wurde bereits gezeigt. Der Datentyp BetragsTyp kann z.B. folgendermaßen verwendet werden:

Teil I Informatik Grundlagen

219

VAR Kaufpreis : Kontol .BetragsTyp; Kaufpreis := 425.30; Kontol .Lastschrift(Kaufpreis);

Die Komponenten im zweiten Abschnitt werden als interne Komponenten bezeichnet. Sie sind im Programmtext außerhalb der Variablendefinition nicht ansprechbar, d.h. die folgende Anweisung ist fehlerhaft: Kontol .Akt_Kontostand := 10.0;

- Fehler !!!!

und wird daher vom Compiler zurückgewiesen. Diese internen Komponenten können nur intern in der Definition von Kontol verwendet werden, und daher rührt auch die Bezeichnung interne Komponenten. In Abb. 1-7.2-3 ist allerdings keine Benutzung zu erkennen. Dies liegt daran, daß lediglich die Spezifikation des Objektes Kontol dargestellt ist, welche im wesentlichen die Information enthält, die zur Benutzung und Manipulation des Objektes benötigt wird. Die dargestellte Spezifikation muß noch durch einen Implementierungsteil ergänzt werden, der häufig auch als Rumpf bezeichnet wird. 7.2.3.3 Objektrumpfund

Datenkapselung

Ein Rumpf für Kontol ist in Abb. 1-7.2-5 dargestellt. VAR Kontol:

OBJECT BODY P R O C E D U R E Gutschrift (Betrag: IN BetragsTyp) IS Akt_Kontostand := Akt_Kontostand + Betrag; END Gutschrift; P R O C E D U R E Lastschrift (Betrag: IN BetragsTyp) IS Akt_Kontostand := Akt_Kontostand - Betrag; END Lastschrift; FUNCTION Kontostand () R E T U R N KontostandsTyp IS R E T U R N Akt_Kontostand; END Kontostand; FUNCTION Kontoinhaber 0 RETURN NamensTyp IS R E T U R N Akt_Kontolnhaber; END Kontoinhaber; E N D OBJECT;

Abb. 1-7.2-5 Rumpf von Kontol Die internen Datenkomponenten können nur über die in der öffentlichen Schnittstelle exportierten Operationen (Prozeduren und Funktionen) manipuliert werden. Aus Abb. 1-7.2-5 geht hervor, daß Akt Kontostand durch die Operationen Gutschrift und Lastschrift verändert werden kann. Die Komponente AktKontoInhaber kann aber nur mit der Operation Kontoinhaber abgefragt werden und hat stets den in der Initialisierung bei Erzeugung der Variablen Kontol festgelegten Wert. Die so bewirkte Abschottung interner Datenkomponenten nach außen wird auch als Datenkapselung bezeichnet und ist ein wichtiges Hilfsmittel zur Erstellung korrekter Programme.

220

7 Einfuhrung in die Programmierung

7.2.3.4 Objekttyp / Klasse Benötigt man weitere Konten, dann kann man weitere Variablen dieser Art definieren. In Abb. 1-7.2-6 ist die Variable Konto2 definiert. Es ist nur der Spezifikationsteil gezeigt, da der Rumpf textuell identisch ist zu dem von Konto 1 (s. Abb. 1-7.2-5). VAR Konto2 : OBJECT TYPE BetragsTyp = RANGE 0.0 .. 999 999.99; TYPE KontostandsTyp = R A N G E 0.0 .. 999_999.99; P R O C E D U R E Gutschrift (Betrag: IN BetragsTyp); P R O C E D U R E Lastschrift (Betrag: IN BetragsTyp); FUNCTION Kontostand () RETURN KontobestandsTyp; FUNCTION Kontoinhaber () RETURN NamensTyp; INTERNAL VAR Akt_Kontostand : KontostandsTyp INIT := 10_000.0; VAR Aktjnhaber: NamensTyp INIT := "EDV Besch 1"; E N D OBJECT;

Abb. 1-7.2-6 Definition der Variablen Konto2 Eine Manipulation von Konto2 ist analog wie bei Konto 1 möglich: Konto2.Gutschrift (50_000.00); Konto2.Lastschrift (5_350.00);

Benötigt man viele Konten, dann ist das hier gewählte Vorgehen, jedesmal eine solche Variable zu definieren, umständlich, da jedesmal die gesamte Beschreibung (Spezifikation und Rumpf) zu wiederholen ist, obwohl sich die verschiedenen Variablen nur im Variablennamen (Konto 1, Konto2) und den Intialwerten für Kontostand und Kontoinhaber unterscheiden. Dieses Problem kann auf zweierlei Art gelöst werden: • mit einer OCCURS-Klausel wie in COBOL • mit einer Typdefinition Die OCCURS-Klausel von COBOL stellt nur eine eingeschränkte Lösung dar, da sie es nur erlaubt, mehrere Exemplare von ähnlichen Variablen an einer Stelle im Programm zu erzeugen, nämlich dort, wo die OCCURS-Klausel steht. Im Rahmen der Fortentwicklung ist aber im Gespräch, auch in COBOL Typdefinitionen einzuführen [BS 95], Der zweite Weg, eine Typdefinition, wird in vielen Programmiersprachen verwendet und ist auch der in der Objektorientierung üblicherweise benutzte Ansatz. Letzten Endes ist dieser Weg nicht spezifisch für Programmiersprachen oder für Software. Es handelt sich um die in vielen Gebieten bewährte Technik, die Komplexität einer Beschreibung dadurch zu reduzieren, daß Teile durch Namen abgekürzt werden, und dann diese Namen anstelle der jeweiligen Teilbeschreibung verwendet werden. In Abb. 1-7.2-7 ist nun eine Typdefinition für den Typ KontoTyp angegeben.

Teil I Informatik Grundlagen

221

TYPE KontoTyp = OBJECT T Y P E BetragsTyp = RANGE 0.0 .. 999_999.99; T Y P E KontostandsTyp = RANGE 0.0 .. 999_999.99; P R O C E D U R E Gutschrift (Betrag: IN BetragsTyp); P R O C E D U R E Lastschrift (Betrag: IN BetragsTyp); F U N C T I O N Kontostand ( ) R E T U R N KontostandsTyp; F U N C T I O N Kontoinhaber ( ) R E T U R N NamensTyp; C O N S T R U C T O R KontoTyp (Inhaber: IN NamensTyp; Anfangsstand: IN KontostandsTyp); INTERNAL VAR Akt_Kontostand: KontostandsTyp; VAR Akt_Kontolnhaber: NamensTyp; E N D OBJECT; TYPE KontoTyp = OBJECT BODY P R O C E D U R E Gutschrift (Betrag: IN BetragsTyp) IS Akt_Kontostand := Akt_Kontostand + Betrag; END Gutschrift; P R O C E D U R E Lastschrift (Betrag: IN BetragsTyp) IS Akt_Kontostand := Akt_Kontostand - Betrag; END Lastschrift; F U N C T I O N Kontostand ( ) R E T U R N KontostandsTyp IS R E T U R N Akt_Kontostand; END Kontostand; F U N C T I O N Kontoinhaber ( ) R E T U R N NamensTyp IS RETURN Aktjnhaber; END Kontoinhaber; C O N S T R U C T O R KontoTyp (Inhaber: IN NamensTyp; Anfangsstand: IN KontostandsTyp) IS Akt_Kontostand := Anfangsstand; Akt_Kontolnhaber := Inhaber; END KontoTyp; E N D OBJECT;

Abb. 1-7.2-7 Definition des Typs KontoTyp Ein Typ von der Art KontoTyp kann naheliegenderweise als Objekttyp bezeichnet werden. Diese Bezeichnung findet sich auch bereits ab und zu, z.B. bei Borland-Pascal [Bor 93] und bei CORBA [OMG 91]. Häufig findet sich auch noch der Ausdruck Klasse für einen solchen Typ. Da der Ausdruck Klasse aber auch für Verwirrung sorgen kann [Win 92], wird hier der sinnfälligere Ausdruck Typ bzw. Objekttyp verwendet. Die Definition des Typs KontoTyp ist weitgehend identisch mit den Definitionen der Variablen Konto 1 und Konto2. Der wesentliche Unterschied besteht darin, daß der Typ KontoTyp eine weitere Operation mit dem Namen „KontoTyp" enthält, die mit dem Schlüsselwort CONSTRUCTOR gekennzeichnet ist. Dies besagt, daß diese Operation automatisch bei der Vereinbarung einer Variablen V vom Typ KontoTyp auf diese Variable V angewendet wird. Der Hauptverwendungszweck dieser Konstruktoren ist die Initialisierung der neu geschaffenen Variablen. Da Konstruktoren auch Parameter haben können, ist damit eine sehr flexible Initialisierung möglich. Ein solcher Konstruktor darf meist nur in dieser Rolle innerhalb einer Variablendeklaration verwendet werden. In Abb. 1-7.2-7 liegt eine Entsprechung zwischen den Parametern des Konstruktors KontoTyp und den Datenkomponenten des Typs KontoTyp vor.

222

7 Einführung in die Programmierung

Dies ist zufällig in diesem Beispiel so, darf aber nicht als eine allgemeine Regel interpretiert werden. Als Pendant zu den Konstruktoren ist es in der Regel auch möglich Destruktoren zu definieren, die automatisch beim Vernichten einer Variablen ausgeführt werden. Im vorliegenden Beispiel ist kein Destruktor formuliert. Der Typ KontoTyp kann nun folgendermaßen verwendet werden: VAR Konto 1 : KontoTyp (Inhaber => "Egon Müller GmbH", Anfangsstand => 0.0);

(1)

Dadurch wird eine Variable Konto 1 definiert, die ebenso aufgebaut ist wie die in Abb. 1-7.2-3 definierte Variable gleichen Namens. Das Auftreten des Namens „KontoTyp" in (1) hat nun zwei Bedeutungen: (a) einmal sagt es aus, daß Kontol den Typ KontoTyp hat, d.h. entsprechend der Struktur des Typs KontoTyp aufgebaut ist, (b) andererseits ist „KontoTyp(lnhaber => "Egon Müller GmbH", Anfangsstand => 0.0)" der Aufruf des Konstruktors. Dies bewirkt hier die Initialisierung der internen Datenkomponenten der Variablen Kontol. Entsprechend kann die Variable Konto2 definiert werden: VAR Konto2 : KontoTyp (Inhaber => "EDV Besch 1", Anfangsstand => 10_000.0);

Auf diese Weise kann man nun beliebig viele andere Konten definieren, deren Gemeinsamkeiten in der Typdefinition des Typs KontoTyp festgelegt sind. Die Manipulationen der Variablen Kontol und Konto2 erfolgen dann ganz genauso wie bereits weiter oben gezeigt. Statt von Variablen eines Objekttyps wird in der Literatur auch von der Instanz eines Typs oder der Instanz einer Klasse gesprochen. Da in Programmiersprachen, welche Typdefinitionen erlauben, der Ausdruck Variable praktisch durchgängig verwendet wird, wird dieser Bezeichnungsweise hier der Vorzug gegeben. 7.2.3.5 Konkrete

Prosrammbeispiele

Zum Abschluß dieses Abschnittes ist das obige Beispiel noch in den Sprachen Borland-Pascal mit Objekten (Abb. 1-7.2-8) und C++ (Abb. 1-7.2-9) dargestellt. UNIT Konten; INTERFACE T Y P E BetragsTyp = 0 .. 999_999; T Y P E KontostandsTyp = 0 .. 999_999; T Y P E KontoTyp = O B J E C T P R O C E D U R E Gutschrift (Betrag: BetragsTyp); P R O C E D Ü R E Lastschrift (Betrag: BetragsTyp); FUNCTION Kontostand : KontostandsTyp; FUNCTION Kontoinhaber: NamensTyp; C O N S T R U C T O R Init (Inhaber: NamensTyp; Anfangsstand: KontostandsTyp); PRIVATE Akt_Kontostand: KontostandsTyp; Akt_Kontolnhaber: NamensTyp; END;

Teil I Informatik Grundlagen

223

IMPLEMENTATION P R O C E D U R E KontoTyp.Gutschrift (Betrag: BetragsTyp); BEGIN Akt_Kontostand := Akt_Kontostand + Betrag; E N D ; P R O C E D U R E KontoTyp.Lastschrift (Betrag: BetragsTyp); BEGIN Akt_Kontostand := Akt_Kontostand - Betrag; END; F U N C T I O N KontoTyp.Kontostand: KontostandsTyp; BEGIN Kontostand := Akt_Kontostand; END; F U N C T I O N KontoTyp.Kontolnhaber: NamensTyp; BEGIN Kontoinhaber := Aktjnhaber ; END; C O N S T R U C T O R KontoTyp.Init (Inhaber: NamensTyp; Anfangsstand: KontostandsTyp); BEGIN Akt_Kontostand := Anfangsstand; Akt_Kontolnhaber := Inhaber; END; END.

Abb. 1-7.2-8 Definition des Typs KontoTyp in Borland-Pascal Die Definition und Manipulation der Variablen Konto 1 und Konto2 erfolgt so: V A R Konto 1, Konto2 : Konten.KontoTyp; Kontol .Init ("Egon Müller GmbH", 0); Konto2.lnit ("EDV Besch 1", 10000); Kontol .Gutschrift (2350); Kontol .Lastschrift (225); IF Kontol .Kontostand > 1000 T H E N ...

Die Definition in C++ ist ähnlich strukturiert. Des wesentliche Unterschied ist der, daß der Objekttyp („class") direkt als Baustein auftritt und nicht in einen anderen Baustein eingeschachtelt ist, wie dies in Abb. 1-7.2-8 der Fall ist. class KontoTyp { protected: float Akt_Kontostand; NamensTyp Akt_Kontolnhaber ; public: void Gutschrift (float Betrag) { if (Betrag > 0.0 && Akt_Kontostand+Betrag 0.0 && Akt_Kontostand - Betrag >= 0.0) Akt_Kontostand = Akt_Kontostand - Betrag; eise "melde Fehler"; } float Kontostand ( ) { return Akt_Kontostand; } NamensTyp Kontoinhaber ( ) { return Akt_Kontolnhaber; } KontoTyp (NamensTyp Inhaber, float Anfangsstand) { if (Betrag >= 0.0 ) Akt_Kontostand = Anfangsstand; eise "melde Fehler"; } }

}

Abb. 1-7.2-9 Definition des Typs KontoTyp in C++ Vereinbarung und Manipulation der Variablen Kontol und Konto2 erfolgt folgendermaßen: KontoTyp Kontol ("Egon Müller GmbH", 0.0); KontoTyp Konto2 ("EDV Besch 1", 10000.0); Kontol .Gutschrift (2350.75);

224

7 Einführung in die Programmierung

Konto 1 .Lastschrift (225.30); if (Kontol .Kontostand() > 1000.0)

...

In den Programmen in Abb. 1-7.2-8 und 1-7.2.9 sind auch eine Reihe von sprachspezifischen Besonderheiten enthalten. Auf diese soll hier nicht weiter eingegangen werden, es soll dem Leser lediglich ein Eindruck vermittelt werden, wie dieses Beispiel in realen Programmiersprachen aussehen kann. 7.2.3.6 A llgemeinheit

des A nsatzes

Die in den vorstehenden Beispielen realisierten Objekte Kontol und Konto2 sind relativ „klein" und einfach aufgebaut. Generell kann man feststellen, daß sich beliebig „große" und komplexe Objekte auf diese Art und Weise realisieren lassen; z.B. solche wie in Abb. 1-7.2-1 erwähnt. Techniken zur Unterstützung der Kooperation unterschiedlicher Anwendungen auf unterschiedlichen Plattformen wie z.B. COM, SOM und CORBA [Adl 95] basieren auch auf dem Objektparadigma. Der Leser sei noch darauf hingewiesen, daß es manchmal Schwierigkeiten bei der Verwendung von Objekttypen geben kann, und zwar dann, wenn symmetrische Operationen zu realisieren sind, d.h. wenn eine Operation mehrere Objekte des betreffenden Objekttyps als Eingabe verarbeitet (z.B. bei der Multiplikation zweier Matrizen). Wie solche Fälle im Rahmen der Objektorientierung zu behandeln sind, ist derzeit noch Gegenstand der Diskussion unter den Fachleuten. 7.2.3.7 Ableitung / Typerweiterung / Vererb ung

Bei der SW-Entwicklung tritt häufig die Situation auf, daß Größen von leicht unterschiedlichem Typ gebraucht werden. Dies kann in der Problemstellung von Anfang an enthalten sein oder sich im Laufe der Zeit bei der Fortentwicklung ergeben. Im Rahmen der Objektorientierung ist ein Mechanismus entwickelt worden, mit welchem man leicht neue Objekttypen definieren kann, die eine Erweiterung bestehender Objekttypen sind. Wenn z.B. auch Konten benötigt werden, die gesperrt werden können, dann kann dies durch eine Typdefinition wie in Abb. 1-7.2-10 erfolgen. Dabei ist zu beachten, daß Abb. 1-7.2-10 nur den Spezifikationsteil enthält und auf der Abb. I7.2-7 aufbaut. Die Sperre soll so wirken, daß die Operationen Gutschrift und Lastschrift auf ein gesperrtes Konto keine Wirkung haben sollen. TYPE KontoMitSperreTyp = OBJECT BASED_ON KontoTyp - Ableitungsklausel PROCEDURE Gutschrift (Betrag: IN BetragsTyp); - Änderung PROCEDURE Lastschrift (Betrag: IN BetragsTyp); - erforderlich PROCEDURE Sperren (); - zusatzliche PROCEDURE EntSperren 0; FUNCTION Gesperrt () RETURN Boolean; - Operationen CONSTRUCTOR KontoMitSperreTyp (Inhaber: IN NamensTyp; - neuer Anfangsstand: IN KontostandsTyp; Sperre: IN Boolean); - Konstruktor

225

Teil I Informatik Grundlagen INTERNAL VAR Konto_Gesperrt: Boolean; END OBJECT;

-

zusätzliche Datenkomponente

Abb. 1-7.2-10 Spezifikationsteil des Typs KontoMitSperreTyp Die Spezifikation des Typs KontoMitSperreTyp zeigt nun alle Merkmale, die üblicherweise bei der Ableitung neuer Objekttypen von existierenden vorkommen. 7.2.3.8 Ableitungsklausel

und

Erweiterung

Nach

dem Schlüsselwort OBJECT ist die Ableitungsklausel „BASED_ON angegeben, die festlegt, daß KontoMitSperreTyp von KontoTyp abgeleitet ist. Die Wirkung der Ableitungsklausel ist nun so, daß so getan wird, als seien alle Komponenten, die in KontoTyp definiert sind, auch in KontoMitSperreTyp definiert. Ausgenommen sind hier meist die Konstruktoren und Destruktoren. Man sagt auch, daß KontoMitSperreTyp die Komponenten von KontoTyp übernimmt oder erbt. Dies ist in Abb. 1-7.2-11 dargestellt, in welcher die übernommenen Komponenten als Kommentare (beginnend mit „--") eingeblendet sind. KontoTyp"

TYPE KontoMitSperreTyp = OBJECT BASED_ON KontoTyp - Ableitungsklausel - TYPE BetragsTyp = RANGE 0.0 .. 999_999.99; - übernommen - TYPE KontostandsTyp = RANGE 0.0 .. 999_999.99; - übernommen PROCEDURE Gutschrift (Betrag: IN BetragsTyp); - Änderung PROCEDURE Lastschrift (Betrag: IN BetragsTyp); - erforderlich - FUNCTION Kontostand ( ) RETURN KontostandsTyp; - übernommen - FUNCTION Kontoinhaber ( ) RETURN NamensTyp; - übernommen PROCEDURE Sperren ( ) ; - zusätzliche PROCEDURE EntSperren ( ) ; FUNCTION Gesperrt ( ) RETURN Boolean; - Operationen CONSTRUCTOR KontoMitSperreTyp (Inhaber: IN NamensTyp; - neuer Anfangsstand: IN KontostandsTyp; Sperre: IN Boolean); - Konstruktor INTERNAL - VAR Akt_Kontostand: KontostandsTyp; - übernommen - VAR Akt_Kontolnhaber: NamensTyp; — übernommen VAR Konto_Gesperrt: Boolean; - zusätzliche Datenkomponente END OBJECT;

Abb. 1-7.2-11 Spezifikationsteil des Typs KontoMitSperreTyp mit übernommenen Komponenten Vergleicht man Abb. 1-7.2-7 und 1-7.2-11, dann stellt man fest, daß abgesehen vom Konstruktor der Typ KontoMitSperreTyp eine Erweiterung des Typs KontoTyp ist; dies gilt sowohl für den öffentlichen wie auch für den internen Teil. D.h. sowohl der öffentliche wie auch der interne Teil enthalten hier neue, zusätzliche Komponenten. Daher wird auch oft von einer Typerweiterung gesprochen. Der Typ KontoTyp wird als Basistyp von KontoMitSperreTyp bezeichnet und umgekehrt KontoMitSperreTyp als ein von KontoTyp abgeleiteter Typ. Man

226

7 Einführung in die Programmierung

spricht auch davon, daß beide Typen in der Ableitungsbeziehung zueinander stehen. Diese Bezeichnungen werden auch verwendet, wenn die Ableitung über mehrere Stufen erfolgt. Man spricht auch davon, daß Basistyp und abgeleiteter Typ in der Ableitungsbeziehung stehen (auch Vererbungsbeziehung genannt). Diese Ableitungsbeziehung ist eine der wichtigen Beziehungen zur Strukturierung objektorientierter SW. Aus der Darstellung der Ableitung (s.o. Abb. 1-7.2-11) geht hervor, daß die Ableitungsbeziehung eine enge Kopplung zwischen Basistyp und abgeleitetem Typ bewirkt, da der abgeleitete Typ alle Komponenten des Basistyps (externe und interne) übernimmt. Insbesondere die Übernahme der Externschnittstelle des Basistyps hat einen großen Einfluß auf den abgeleiteten Typ. Die zweite wichtige Beziehung zwischen Programmbausteinen ist die Benutzungsbeziehung, die weiter unten erläutert wird.

7.2.3.9 Mehrfachableitung In den oben aufgeführten Beispielen hat ein abgeleiteter Objekttyp stets genau einen Basistyp. In manchen Programmiersprachen und Entwurfsnotationen ist es möglich, daß ein Objekttyp unmittelbar von mehreren Basistypen abgeleitet wird. Dies wird auch als Mehrfachvererbung bezeichnet. Dabei treten jedoch eine Reihe von Komplikationen auf. Daher befindet sich dieses Konzept derzeit noch in der Diskussion und kann noch nicht als abgeklärt angesehen werden. 7.2.3.10 Reimplementieruns

/ Modifikation

Da die Operationen Gutschrift, Lastschrift und Kontostand bei einem gesperrten Konto keine Wirkung haben sollen, müssen ihre Rümpfe modifiziert werden. Daher enthält die Spezifikation in Abb. 1-7.2-11 erneut Spezifikationen der entsprechenden beiden Prozeduren. Abb. 1-7.2-12 enthält den Rumpf von KontoMitSperreTyp. Dieser Rumpf enthält einerseits die Rümpfe der neuen Operationen und die neuen Rümpfe der beiden modifizierten Operationen. Da man Rümpfe oft auch als Implementierungsteile bezeichnet, werden Prozeduren mit neuen Rümpfen auch als reimplementierte Prozeduren bezeichnet. In der Literatur findet man dafür auch den Ausdruck „redefinierte Prozeduren". Dies ist aber eher mißverständlich, da die Definition, d.h. der Prozedurkopf (Prozedurspezifikation) völlig unverändert ist. Ein neuer, unterschiedlicher Prozedurkopf führt ja eine völlig neue Operation ein.

Teil I Informatik Grundlagen

227

TYPE KontoMitSperreTyp = OBJECT BODY PROCEDURE Gutschritt (Betrag: IN BetragsTyp) IS - neue IF NOT Gesperrt() T H E N Konto.Gutschrift (Betrag); - Rümpfe END IF; END Gutschrift; - für PROCEDURE Lastschrift (Betrag: IN BetragsTyp) IS IF NOT Gesperrt() - Gutschrift THEN Konto.Lastschrift(Betrag); - und END IF; END Lastschrift; - Lastschrift PROCEDURE Sperren ( ) IS - Rümpfe für Konto_Gesperrt := True; END Sperren; PROCEDURE EntSperren ( ) - zusätzliche Konto_Gesperrt := False; END Entsperren; FUNCTION Gesperrt ( ) RETURN Boolean IS - Operationen RETURN Konto_Gesperrt; END Gesperrt; CONSTRUCTOR KontoMitSperreTyp (Inhaber: IN NamensTyp; - neuer Anfangsstand: IN KontostandsTyp; Sperre: IN Boolean); - Konstruktor Konto.Konto (Inhaber, Anfangsstand); Konto_Gesperrt := Sperre; END KontoMitSperreTyp; END OBJECT;

Abb. 1-7.2-12 Rumpf des Typs KontoMitSperreTyp Im Rumpf in Abb. 1-7.2-12 wird in den Situationen, in welchen es möglich ist, in den reimplementierten Rümpfen auf die Rümpfe der entsprechenden Prozeduren im Basistyp Konto zurückgegriffen. Um Namenskonflikte zu vermeiden, ist dann der Prozedurname mit dem Namen des Basistyps qualifiziert. Beispiele dafür sind: „Konto.Gutschrift (Betrag);" im Rumpf von Gutschrift und „Konto.Konto (Inhaber, Anfangsstand);" im Rumpf des neuen Konstruktors KontoMitSperreTyp. Im letzteren Falle ist diese Qualifizierung zwar nicht unbedingt erforderlich, wurde aber der Deutlichkeit wegen auch hier gemacht. Diese Wiederverwendung der Rümpfe des Basistyps hat im allgemeinen den Vorteil, daß Vorgänge nicht unnötigerweise mehrfach programmiert werden müssen. Im vorliegenden Beispiel, welches gegenüber der Praxis stark vereinfacht ist, sind die Rümpfe sehr klein. Bei größeren Rümpfen ist der Vorteil dieser Wiederverwendung natürlich entsprechend größer. Der Typ KontoMitSperreTyp kann nun ganz entsprechend wie der Typ Konto verwendet werden. Zusammenfassend können in einem abgeleiteten Typ folgende Modifikationen gegenüber dem Basistyp vorgenommen werden: • Aufnahme neuer (zusätzlicher) Komponenten • Reimplementierung von Prozeduren Weglassen von Komponenten ist normalerweise nicht möglich. Dies hängt mit dem Polymorphismus zusammen, der im nächsten Abschnitt behandelt wird.

228

7 Einführung in die Programmierung

7.2.3.11 Basistyp als Zusammenfassung von gemeinsamen

Komponenten

Der Ableitungsmechanismus kann auch dadurch zum Einsatz kommen, daß in mehreren existierenden Objekttypen Gemeinsamkeiten festgestellt werden, welche in einem Basistyp zusammengefaßt werden können. T Y P E KontoMitSperreTyp = OBJECT BetragsTyp KontostandsTyp Gutschrift Lastschrift Kontostand Kontoinhaber Sperren EntSperren Gesperrt KontoMitSperreTyp INTERNAL Akt_Kontostand Akt_Kontolnhaber Konto_Gesperrt E N D OBJECT;

TYPE KontoTyp = OBJECT BetragsTyp KontostandsTyp Gutschrift Lastschrift Kontostand Kontoinhaber KontoTyp INTERNAL Akt_Kontostand Akt_Kontolnhaber E N D OBJECT;

T Y P E KontoMBuTyp = OBJECT BetragsTyp KontostandsTyp BuchgTyp Gutschrift Lastschrift Kontostand Kontoinhaber DruckeBuchungn KontoMBuTyp INTERNAL Akt_Kontostand Akt_Kontolnhaber Akt_Buchungen E N D OBJECT;

Abb. I-7.2-12a KontoTyp, KontoMitSperreTyp und KontoMBuTyp als unabhängige Typen In den folgenden Beispielen werden die Objekttypen nur schematisch dargestellt, da die Details wie Parameter von Operationen für den darzustellenden Sachverhalt nicht wichtig sind. In Abb. 1-7.2-12a sind die drei Typen KontoTyp, KontoMitSperreTyp und KontoMBuTyp so dargestellt, als seien sie unabhängig voneinander entstanden. KontoTyp und KontoMitSperreTyp seien wie bisher. KontoMBuTyp sei wie KontoTyp und habe die Zusatzfunktion, daß alle Buchungen in der Variablen Akt_Buchungen gespeichert werden. Mit der Operation DruckeBuchungn können diese Buchungen ausgedruckt werden.

Teil I Informatik Grundlagen

229

Man erkennt nun, daß alle drei Typen eine Reihe von dem Namen nach gleichen Komponenten enthalten. Zur Betonung sind diese gemeinsamen Komponenten in Abb. I-7.2-12a kursiv geschrieben. Bei Inspektion der vollständigen Typdefinitionen würde man feststellen, daß BetragsTyp, KontostandsTyp, Kontostand, Kontoinhaber, Akt_Kontostand und AktKontoInhaber in beiden Typen identisch sind; Gutschrift und Lastschrift haben zwar den gleichen Prozedurkopf, haben aber unterschiedliche Rümpfe.

Abb. 1-1.7-12b KontoTyp, KontoMitSperreTyp und KontoMBuTyp bei Einsatz der Ableitung Die Typerweiterung („BASED ON") kann nun ausgehend von der Situation in Abb. I-7.2-12a so eingesetzt werden, daß ein Basistyp definiert wird, der die gemeinsamen Komponenten enthält und von welchem die ursprünglichen Typen abgeleitet werden. In Abb. I-7.2-12a liegt insofern eine besondere Situation vor, als einer der Typen nur gemeinsame Komponenten enthält. Dies wird im allgemeinen nicht der Fall sein. Nach diesem Herausfaktorisieren der gemeinsamen Komponenten ergibt sich die in Abb. I-7.2-12b dargestellte Situation. Diese Situation tritt in der Praxis ebenfalls häufig auf, da sich bei der Programmentwicklung die genauen Komponenten von Objekten und Objekttypen erst bei der Detaillierung ergeben und entsprechend festgelegt werden. 7.2.3.12

Polymorphismus

In einem Anwendungsfall werden meistens nicht nur zwei einzelne Konten benötigt, wie weiter oben dargestellt, sondern größere Anzahlen. Diese wird man

230

7 Einführung in die Programmierung

nicht als einzelne Variablen definieren sondern z.B. als Reihung (Array). Wenn man dies versucht, stößt man aber auf eine Schwierigkeit. Wenn man definiert: C O N S T Anzahl_Konten = 1000; KontenA: ARRAY(1..Anzahl_Konten) OF KontoTyp;

dann sind alle Elemente der Reihung KontenA vom Typ KontoTyp. Dies ist hinderlich, wenn man sowohl einfache Konten als auch Konten mit Sperrmöglichkeit verwalten will. Der Grund liegt in der in den üblichen Programmiersprachen vorhandenen strengen Typbindung, die im allgemeinen sehr nützlich ist, weil sie es ermöglicht, daß Compiler viele fehlerhafte Konstruktionen erkennen können, wie z.B. KontenA(1).Gutschrift ("ABC");

Dies ist fehlerhaft, da die Prozedur Gutschrift einen Ausdruck mit einem Zahlenwert als Parameter verlangt und keine Zeichenkette. Dieser Fehler wird bereits vor Einsatz des Programmes bei der Übersetzung erkannt. Selbst wenn man Verweise (Pointer) als Elemente der Reihung verwendet, kommt man nicht weiter: KontenB: ARRAY(1 ..Anzahl_Konten) OF POINTER TO KontoTyp;

Auch hier müssen dann alle Elemente vom Typ „POINTER TO KontoTyp" sein. Wenn man bei den üblichen Typregeln bliebe, könnte man die Idee, in einer Reihung Konten von beiden Arten zu verwalten, nicht realisieren. Daher ist in objektorientierten Sprachen die Typisierungsregel für Verweise folgendermaßen geändert: Verweis_Variable : POINTER TO KontoTyp;

Die Variable VerweisVariable darf nun Verweise auf Variable des Typs KontoTyp und Verweise auf Variable eines von KontoTyp abgeleiteten Typs auf nehmen. Wendet man diese neue Typregel auf die Variable KontenB an, dann ist folgendes möglich: KontenB(1) := N E W KontoTyp ("XYZ AG", 0.0); KontenB(2) := N E W KontoMitSperreTyp ("ABC GmbH-, 10_000.0, False); KontenB(3) := N E W KontoTyp ("Rela AG", 5_000.0);

Dadurch wird eine neue Variable vom Typ KontoTyp erzeugt und mit dem Konstruktor initialisiert und dann ein Verweis auf diese neue Variable in KontenB(l) gespeichert. Dem Reihungselement KontenB(2) wird hingegen ein Verweis auf eine Variable des Typs KontoMitSperreTyp zugewiesen und KontenB(3) wieder ein Verweis auf ein einfaches Konto. Zu einem späteren Zeitpunkt könnte auch KontenB(3) einen Verweis auf ein Konto mit Sperrmöglichkeit aufnehmen: KontenB(3) := N E W KontoMitSperreTyp ("Wilram KG", 50_000.0, True);

Daß eine Verweisvariable nun Verweise auf Variable unterschiedlicher (aber verwandter) Typen aufnehmen kann, wird als Polymorphismus (Vielgestaltigkeit) bezeichnet.

Teil I Informatik Grundlagen

231

Der Polymorphismus ermöglicht auch die gemeinsame Manipulation unterschiedlicher Variablen. Wenn z.B. von allen Konten in KontenB Kontoinhaber und Kontostand ausgedruckt werden sollen, kann dies folgendermaßen erfolgen: FOR I IN 1..Anzahl_Konten LOOP Drucke ( KontenB(l)->.Kontolnhaber ( ) , KontenB(l)->.Kontostand ( ) ) , END LOOP;

7.2.3.13

Polymorphismus

und

Reimplementieruns

Selbst wenn die angewendete Operation in den vorkommenden Typen unterschiedlich implementiert ist, kann eine gemeinsame Manipulation erfolgen; wenn z.B. auf alle Konten in KontenB eine Gutschrift von 1000.0 erfolgen soll: FOR I IN 1..Anzahl_Konten LOOP KontenB(l)->.Gutschrift(1000.0);

END LOOP;

In diesem Beispiel treffen nun Polymorphismus und Reimplementierung zusammen. Da die Verweise in KontenB auf Objekte unterschiedlichen Typs verweisen können (z.B. KontoTyp oder KontoMitSperreTyp), stellt sich hier die Frage, welcher Rumpf der Prozedur Gutschrift in „KontenB(l)->.Gutschrifl(1000.0)" aufgerufen wird, denn beide Typen haben ja jeweils einen eigenen Rumpf für diese Prozedur. Was passiert ist das, was man generell erwartet: verweist der Verweis KontenB(l) auf ein Objekt vom Typ KontoTyp, dann wird der in KontoTyp definierte Rumpf von Gutschrift ausgeführt und im Falle von KontoMitSperreTyp der in diesem Typ definierte Rumpf von Gutschrift. D.h. beim Prozeduraufruf über eine polymorphe Verweisvariable wird jeweils der Rumpf ausgeführt, der zu dem Typ des Objektes gehört, auf das die Verweisvariable gerade verweist. Diese Situation wird durch folgendes Programmfragment verdeutlicht: VAR VerweisAufKonto : POINTER TO KontoTyp; IF Bedingung THEN VerweisAufKonto := NEW KontoTyp ("XYZ AG", 0.0); ELSE VerweisAufKonto := NEW KontoMitSperreTyp ("ABC GmbH", 10_000.0, False); END IF; VerweisAufKonto-».Gutschrift(2500.0);

Wird der THEN-Zweig durchlaufen, dann wird KontoTyp.Gutschrift ausgeführt und im Falle des ELSE-Zweiges KontoMitSperreTyp.Gutschrift. Diese Vorschrift wird manchmal auch als „dynamisches Binden" bezeichnet. Trotz dieses Namens hat dieser Vorgang mit dem üblichen Binden von Programmteilen nichts zu tun. Aufgrund dieser mißverständlichen Ausdrucksweise, wurde schon häufig vermutet, daß der Aufruf von Prozeduren über polymorphe Verweisvariable besonders aufwendig sei. Dies ist aber nicht der Fall. Normalerweise wird die Vorschrift, daß jeweils die zum Typ der aktuellen Variablen gehörige Implementierung ausgeführt wird, durch einen indirekten Prozeduraufruf realisiert, der nur unwesentlich aufwendiger ist als ein direkter. Es ist unmittelbar verständlich, daß nur die von KontoTyp exportierten Operationen in dieser Situation verwendet werden dürfen, denn die zusätzlichen, nur in KontoMitSperreTyp sind ja in den Variablen vom Typ KontoTyp nicht enthalten. D.h. das folgende ist fehlerhaft:

232

7 Einführung in die Programmierung FOR I IN 1..Anzahl_Konten LOOP KontenB(l)->.Sperren(); END LOOP;

-

!!!!

Umgekehrt garantiert die Vorschrift, daß im abgeleiteten Typ keine Komponenten des Basistyps weggelassen werden können, das sichere Zusammenspiel von Polymorphismus und Reimplementierung. 7.2.3.14 Dynamische Typab frage Falls es erforderlich ist, auch die nur in abgeleiteten Typen enthaltenen Prozeduren (oder anderen Komponenten) anzusprechen, dann muß festgestellt werden, von welchem aktuellen Typ die Variable ist, auf die eine polymorphe Verweisvariable verweist. Dafür werden in manchen objektorientierten Sprachen ebenfalls Sprachelemente angeboten. Im Rahmen dieser einführenden Darstellung kann darauf aber nicht eingegangen werden. 7.2.3.15

Benutzunssbeziehung

Neben der Ableitungsbeziehung, die zwischen Objekttypen bestehen kann, gibt es auf der Realisierungsebene noch eine zweite Beziehung zwischen Programmbausteinen: die Benutzungsbeziehung. Diese kann zwischen allen üblichen Programmbausteinen bestehen, also zwischen Objekttypen, Objekten / Modulen und Prozeduren: eine Prozedur kann einen Objekttyp benutzen oder ein Objekttyp kann ein Modul benutzen. Manchmal wird auch der Ausdruck „Baustein A importiert Baustein B" dafür benutzt. Abb. 1-7.2-13 zeigt eine Prozedur, die den Typ KontoTyp importiert. PROCEDURE Hauptprogramm IS IMPORT KontoTyp; - KontoTyp darf wie ein Typ verwendet werden CONST Anzahl_Konten = 1000; VAR Konten: ARRAY(1..Anzahl_Konten) OF KontoTyp; BEGIN Konten(5).Gutschrift(15_000.0); END Hauptprogramm;

Abb. 1-7.2-13 Prozedur benutzt Objekttyp Die Prozedur Hauptprogramm importiert den Typ KontoTyp und kann ihn dann intern wie einen Typ benutzen. Hier werden 1000 Konten vom Typ KontoTyp definiert und manipuliert. Die Verwendung eines importierten Objekttyps zur Definition entsprechender Variablen ist die typische Benutzung bei Import eines Typs. Die vom importierten Objekttyp selbst exportierten Größen werden dann in der Regel bei der Manipulation der entsprechenden Variablen benutzt; z.B. in Abb. 1-7.2-13 in der Anweisung ,,Konten(5).Gutschrift(15_000.0);". Bei Import eines Objektes / Moduls hingegen, werden die von diesem Objekt / Modul exportierten Größen im importierenden Baustein direkt benutzt. Dies ist in Abb. 1-7.2-14 zu sehen, welche ein Pascal-Hauptprogramm zeigt, welches den in Abb. 1-7.2-8 definierten Modul (unit) Konten importiert.

Teil I Informatik Grundlagen

233

PROCEDURE Hauptprogramm2 IS IMPORT Konten; CONST Anzahl_Konten = 1000; VAR Kontenliste: ARRAY(1..Anzahl_Konten) OF Konten.KontoTyp; Betrag: Konten.BetragsTyp; BEGIN Betrag := 15_000.0; Kontenliste(5).Gutschrift(Betrag); END Hauptprogramm;

Abb. 1-7.2-14 Prozedur benutzt Modul Ein Objekttyp kann auch andere Objekttypen importieren und benutzen. Abb. I7.2-15 zeigt einen Objekttyp KontoFuehrungsTyp, der die weiter oben definierten Typen KontoTyp und KontoMitSperreTyp benutzt. TYPE KontoFuehrungsTyp = OBJECT IMPORT KontoTyp, KontoMitSperreTyp; CONST Anzahl_Konten = 10_000; TYPE KontoNummerTyp = 1..Anzahl_Konten; PROCEDURE KontoEinrichten (Inhaber: IN KontoTyp.NamensTyp; Anfangsstand: IN KontoTyp.KontostandsTyp; MitSperre: IN Boolean KontoNr: O U T KontoNummerTyp); PROCEDURE KontoLoeschen (Inhaber: IN KontoTyp.NamensTyp; KontoNr: IN KontoNummerTyp); PROCEDURE Ueberweisen ( Von: IN KontoNummerTyp; Auf: IN KontoNummerTyp; Betrag: IN KontoTyp.BetragsTyp); INTERNAL VAR Konten: ARRAY(KontoNummerTyp) OF REF KontoTyp; END KontoFuehrungsTyp;

Abb. 1-7.2-15 Objekttyp KontoFuehrungsTyp benutzt die Objekttypen KontoTyp und KontoMitSperreTyp Betrachtet man die Abb. 1-7.2-13, 14 und 15 genauer, dann stellt man fest, daß die Benutzungsbeziehung keinen direkten Einfluß auf den Auibau des benutzenden Bausteins hat. Das Importieren eines Bausteins bedeutet, daß der importierende Baustein die in der Externschnittstelle des importierten Bausteins definierten Komponenten benutzen kann. In Abb. 1-7.2-13 werden der importierte Typ KontoTyp und die in dessen Externschnittstelle definierte Prozedur Gutschrift verwendet. In Abb. 1-7.2-15 werden der importierte Typ KontoTyp und die in dessen Externschnittstelle definierten Typen BetragsTyp und KontostandsTyp verwendet. Der Importeur ist aber nicht verpflichtet, etwas bestimmtes zu benutzen. Daher sagt auch die Importklausel selbst nichts näheres über die aktuelle Verwendung des importierten Bausteins aus. Vergleicht man nun Ableitungs- und Benutzungsbeziehung, dann stellt man fest, daß die Ableitungsbeziehung eine relativ enge Kopplung der beteiligten Objekttypen zur Folge hat, während die Benutzungsbeziehung eine lose

234

7 Einführung in die Programmierung

Kopplung der beteiligten Bausteine mit sich bringt. Beide Beziehungen beschreiben Aspekte der statischen Programmstruktur. Dynamik und Funktionalität sind mehr implizit im Programmtext enthalten. 7.2.3.16 Merkmale der Obiektorientierune

aufRealisierunesebene

Objekt / Objekttyp:

Kombination von Daten und Operationen (Aggregierung)

Interne Komponenten :

Datenkapselung / Abstraktion

Ableitung / Vererbung :

Erweiterung / Modifikation (Reimplementierung) Schnittstellenmonotonie

Polymorphismus :

einheitliche Manipulation von Variablen verschiedenen Typs

Ableitungsbeziehung

enge Kopplung

Benutzungsbeziehung:

lose Kopplung

Abb. 1-7.2-16 Merkmale der Objektorientierung auf Realisierungsebene

7.3 Programmentwicklung 7.3.1 Zustandekommen laufiahiger Programme Jedes Programm ist zunächst nur die Notation des Algorithmus in einer der Arbeitsweise des Menschen (nämlich der Umgangssprache) angepaßten Form. Diese Notation muß in den Befehlsvorrat der zugrunde gelegten Maschine übertragen werden, um ein lauffähiges Programm zu erhalten. Moderne Programmiersprachen stellen die dazu erforderlichen Werkzeuge in einer integrierten Entwicklungsumgebung bereit: Editor Compiler Linker Interpreter Debugger Die erforderlichen Schritte sind

Fehler-\

h

Maschinenprogramm

j

Programm erfassen

Programm übersetzen

Programm ausführen

Teil I Informatik Grundlagen

235

Abb. 1-7.3-1: Arbeitsschritte zum Erstellen eines Maschinenprogramms Ein Editor ist Texterfassungssystem zum Erfassen und Korrigieren/ Editieren von Programmen. Es entsteht das Quellprogramm (Source Code). Ein Interpreter übersetzt ein in einer höheren Programmiersprache geschriebenes Programm Schritt für Schritt in ausführbaren Maschinencode und fuhrt diesen sogleich aus. Beim Interpretieren entsteht kein ausführbares, abzuspeicherndes Maschinenprogramm als Ganzes. Bei jeder weiteren Programmabarbeitimg muß wieder neu übersetzt werden, so daß Quelltext und Interpreter während der Ausfuhrung im Hauptspeicher anwesend sein müssen. Vorteile bietet die Arbeit mit einem Interpreter vor allem in der Testphase eines Programmes, weil man das Programm schrittweise (zeilenweise) auf Korrektheit testen kann. Dazu stehen wesentlich längere Abarbeitungszeiten durch die Übersetzungszeit entgegen. Auch früher rein interpreterorientierte Programmiersprachen (BASIC) bieten daher heute Compiler zum Gebrauch nach der Testphase an. Ein Compiler ist ein Übersetzungsprogramm, das ein in einer höheren Programmiersprache geschriebenes Programm als Ganzes in Maschinencode übersetzt. Beim Compilieren entsteht eine speicherfähige Datei, die Objektdatei ....obj. Der Quelltext als Hilfsmittel wird überflüssig und braucht nicht an den Kunden weitergegeben zu werden. Allerdings ist der Objektcode noch unvollständig, da der Code für benutzte Systemroutinen fehlt, und daher nicht laufiahig ist. Ein weiteres Dienstprogramm, der Linker, ist erforderlich: Ein Linker ist ein Dienstprogramm, das den Objektcode einer bestimmten Sprache durch das Einbinden der Systembibliothek dieser Programmiersprache in lauffahigen Maschinencode umsetzt. Es entsteht die ....exe-Datei; in dieser Form werden Sofitwareprodukte gehandelt. Compilierte Programme sind schnell in ihrer Ausführung, da keine erneute Übersetzung erfolgt und Compiler meist optimierende Eigenschaften haben. Einziger Nachteil besteht darin, daß man das Programm erst nach fehlerfreier Compilierung auf Korrektheit prüfen kann, was lange dauern kann, denn bei jedem Compilierfehler fallt man in den Editor zurück, um Fehler zu korrigieren. Nach der Beseitigung der syntaktischen Fehler, die aus falscher Anwendung der Sprachregeln der Programmiersprache entstehen und vom Compiler angezeigt werden, müssen in den meisten Fällen Denkfehler (semantische Fehler) gefunden werden, die sich erst beim Lauf als Diskrepanz zwischen Programmiervorgaben und -verhalten zeigen.

7.3.2 Modularisierung von Programmen Eine weitere Zielgröße bei der Erarbeitung des Algorithmus für eine gestellte Aufgabe ist die Strukturiertheit des Algorithmus. Es ist aus Gründen

236 • •

7 Einführung in die Programmierung der leichten inhaltlichen Überschaubarkeit des Anwenders der Möglichkeit der Arbeitsteilung beim Programmieren

zwingend erforderlich, die Gesamtaufgabe in Teilaufgaben zu zerlegen, die entsprechend von einzelnen Bausteinen (Moduln) in der Programmiersprache realisiert werden. Aufsatzpunkt der Modularisierung bei der Programmierung ist die Umsetzung der Elementarfunktionen des Funktionsmodells (II-3.2) in separat compilierbare und gebundene Programmbausteine. Dieser Schritt ist vorrangig von systemtechni sehen Gesichtspunkten bestimmt, speziell von den Ausdrucksmöglichkeiten der einzelnen Programmiersprachen für Module. Als Element eines strukturierten Algorithmus muß ein Modul folgende Eigenschaften besitzen: 1. Er ist eine funktionell abgeschlossene Einheit des Algorithmus 2. Die von ihm realisierte Funktion ist ausschließlich über die Schnittstelle (Interface) des Moduls nutzbar. Über dieses Interface werden an den Modul aktuelle Daten übergeben und berechnete Größen zurückgegeben. 3. Die programmtechnische Realisierung der Funktion bleibt dem Nutzer verborgen und darf von ihm nicht ausgenutzt werden (information hiding). Auf diese Weise konzipierte Module besitzen wesentliche Vorteile: 1. Austauschbarkeit gegen „bessere" Bausteine gleicher Funktion (z. B. Sortiermodule) bei gleichbleibender Schnittstelle 2. unabhängige, zeitlich parallele Bearbeitbarkeit durch verschiedene Programmierer, was überhaupt erst Teamarbeit beim Erarbeiten großer Programme ermöglicht Die Architektur eines Programmsystems ist die Art und Weise, in der die spezifizierten Anforderungen durch das Zusammenspiel der einzelnen Bausteine (Module) realisiert werden. Es gibt stets ein Top-Modul, das dieses Zusammenspiel bewerkstelligt, und i. a. in mehreren Ebenen, nachgeordnete Module, die von Top-Modul zur Erfüllung seiner Aufgaben genutzt werden. Nachdem die Modularstruktur eines Programmsystems entworfen ist, werden die Teilalgorithmen für die einzelnen Module notiert, die zusammen den Algorithmus als Grundlage der Codierung bilden.

7.3.3 Testen von Programmen Um Fehler in den Algorithmen oder den daraus resultierenden Programmen aufzudecken, werden Tests aufgewandt. Als Test wird das gezielte und systematische Erproben eines Algorithmus bzw. eines Programmes mittels ausgewählter Testdaten bezeichnet. Zunächst gilt sinngemäß der kluge Satz, daß jeder Text bestenfalls Fehler auffinden, nie aber Fehlerfreiheit beweisen kann. Dennoch kann eine Menge zum Erreichen fehlerfreier Programme getan werden.

Teil I Informatik Grundlagen

237

Man unterscheidet grob zwei Arten von Fehlern: syntaktische Fehler, die durch falschen Gebrauch der Sprachregeln entstehen und vom Compiler angezeigt werden semantische Fehler, die sich in einer Diskrepanz zwischen den vorgegebenen und den tatsächlichen Funktionen eines Programms äußern und die durch Denkfehler des Programmierers entstehen; sie sind häufig wesentlich schwieriger zu finden, da sie sich manchmal nur bei bestimmten Konstellationen der Daten zeigen (im Extremfall spricht man von „Bananen-Software, die erst beim Kunden reift") Im weiteren schränken wir uns auf semantische Fehler ein. Ausführliche Tests sind wichtig, weil sie den Grad der Korrektheit der Software bestimmen. Mangelnde Korrektheit eines Softwareproduktes kann ein Grund für gerichtliche Auseinandersetzungen sein. Darüber hinaus wächst unsere Abhängigkeit von korrekter Software, wesentliche Lebensvorgänge in der öffentlichen Verwaltung, dem Verkehrs- und Gesundheitswesen, der Lohnzahlung etc. gehen von korrekter Software aus. Ein erster Schritt in die Richtung möglichst korrekter Programme wird bereits in frühen Phasen des Programmentwurfs (vgl. II.3) durch eine möglichst genaue Programmspezifikation getan. Analysen der Fehlerbehebungskosten ergaben, daß 82 % auf unzureichende Anforderungsdefinitionen zurückzuführen sind. Grundsätzlich existieren zwei verschiedene Testformen: a) Trockentests (statische Tests) b) Tests am ausführbaren Programm (dynamische Tests) Die erste Stufe ist der Trockentest, bei dem in Form einer „Code-Inspection" am Schreibtisch der in einer bestimmten Notation (Pseudocode, Struktogramme, höhere Programmiersprache u. ä.) vorliegende Algorithmus auf Evidenz, Übereinstimmung mit der Spezifikation und auf programmtechnisch kritische Aktionen (Deklaration von Variablen vor Benutzung, Schleifenterminierungen, fehlende Initialisierungen, Datentypkonflikte etc.) geprüft wird, die ggf. auch nicht vom Compiler als fehlerhaft gemeldet würden. Vorzugsweise sollte der Trockentest von einem vom Entwickler unabhängigen Fachmann ausgeführt werden, um Betriebsblindheit möglichst zu vermeiden. Er kann bereits in frühen Phasen begleitend einsetzen, und kann i. a. nur Fehler grob ausfiltern. Die zweite Stufe geht nun zu den Maschinentests über, die ein syntaktisch fehlerfreies, lauftahiges Maschinenprogramm voraussetzen. Sie folgen den Ansätzen: • • •

ablaufbezogenes Testen datenbezogenes Testen funktionsbezogenes Testen.

238

7 Einführung in die Programmierung

Ablaufbezogene Tests (white-box-Tests, Structured Testing) sind charakterisiert durch das Bereitstellen solcher Testfalle, daß möglichst • • • • •

Ausführung aller Anweisungen (Statementtest) Ausführung aller Ablaufzweige (Zweigtest) Erfüllung aller Bedingungen Wiederholung aller Schleifen Kombination aller Programmverzweigungen (Pfadtest)

und

Programmschleifen

erfolgt. Da Software möglichst bald verfügbar sein soll, der Aufwand hier jedoch kombinatorisch wächst, sind Kompromisse unvermeidlich. Darüber hinaus läßt sich nur eine bestimmte Klasse von Fehlern finden, nämlich grobe Abbruchsfehler, unerreichbare Zweige, Endlosschleifen und unvollständige Bedingungen. Vergessene Funktionen, unberücksichtigte Daten und insbesondere Abweichungen von der Spezifikation bleiben unerkannt, da das Programm nur gegen sich selbst getestet wird, aber nicht dahingehend, was es tun soll. So ist strukturiertes Testen für sich allein nicht ausreichend. In datenbezogenen Tests liegt das Hauptaugenmerk im Bereitstellen fachlich sinnvoller Datenkombinationen durch Fachabteilung und Spezialisten gemeinsam, die möglichst alle vorkommenden Situationen simulieren. Sinnvoll erscheinen jeweils • • •

ein repräsentativer Wert aus der „Mitte" des Wehrbereichs einer Eingabe jeweilige Grenzwerte (z. B. 0 und ein sehr großer Wert) ein unzulässiger Wert einer Eingabe

für eine repräsentative Überdeckung Wertanalyse").

einer Eingabegröße

(„repräsentative

Die Textdaten sind zu dokumentieren und stabil zu halten, um bei Programmkorrekturen genau die Effekte zu isolieren und nicht mehrere Effekte, darunter den zufallig anders gewählter Daten, zu überlagern. Inhaltlich kann die Festlegung der Testdaten in der Phase des Pflichtenheftes erfolgen. Beim funktionsorientierten Testen tritt der eigentliche Programmtest in den Hintergrund (black box testing); jede in der Spezifikation festgelegte Funktion wird isoliert auf korrekte Ausführung getestet. Andere Programmcode-Abschnitte werden ausgeblendet. Zu einem repräsentativen Satz von Eingabedaten werden die Ausgabedaten durch das Programm ermittelt und verglichen mit solchen, die theoretisch bei korrekter Funktionsausführung entstehen müssen. Allein dieser Ansatz erfüllt das eigentliche Anliegen von Testen, nämlich das Programm gegen die Spezifikation zu prüfen. Die Ergebnisse von Einzeltests einzelner Funktionen werden schrittweise zusammengeführt und im Integrationstest, wo nach jedem Hinzufugen einer

Teil I Informatik Grundlagen

239

Funktion das Zusammenspiel neu getestet werden muß, um isoliert evtl. neu auftretende Probleme auf die unmittelbar vorausgehende Aktion zurückzuführen. Der abschließende System- und Abnahmetest muß die korrekte Erbringung aller spezifizierten Funktionen vor den Augen der aktiv partizipierenden Fachabteilung nachweisen. Moderne Sprach-Entwicklungsumgebungen unterstützen auch die Textphase durch Testhilfen, die sog. Debugger, welche ermöglichen • • •

die schrittweise Abarbeitung der Programme (tracing) das Beobachten der Variablenbelegungen das Setzen testtechnisch interessanter Werte fiir Variable.

8 Multimedia 8.1 Einführung Multimedia ist trivial gesagt, das synchronisierte Aufeinandertreffen von unterschiedlichen Medien wie Text, Graphik, Ton, Bild, Video, die als Einzelmedium oder in Kombination der Kommunikation dienen. Basis der menschlichen Zivilisation ist der Austausch von Informationen durch Kommunikation. Der Zugang zu Informationen ist zu einem Schlüsselproblem bei der Entwicklung individueller und kollektiver Leistungs- und Wettbewerbsfähigkeit geworden. Um im Informationszeitalter mittels informationslogistischer Strategien: • • • • •

zum richtigen Zeitpunkt am richtigen Ort in der richtigen Menge in der richtigen Qualität an die richtige Information

zu gelangen, werden verschiedene, neue Technologien eingesetzt, die zudem bewirken sollen, daß der Einzelne sowohl im privaten als auch im geschäftlichen Bereich in der Lage ist, die exponentiell wachsenden Informationsflut zu beherrschen. Technologien aus folgenden Branchen spielen in diesem Sinne eine Rolle: • Computersysteme • Telekommunikation • Unterhaltungselektronik. Der Mensch nimmt Informationen über eine Kombination von Sinneswahrnehmungen auf. Die Verbindung von visueller und akustischer Wahrnehmung in einer bestimmten Art und Form in Komplexion hat sich im Laufe seiner Entwicklung als optimal für den Erfolg der Aufnahme von Informationen erwiesen. Genau an diesem Punkt setzt Multimedia als

240

8 Multimedia

Befähigungstechnik [RaF91] an der Schnittstelle zwischen mehreren bestehenden Technologien an. Die bisher technisch bedingte Trennung verschiedener Medienarten wird überwunden. Es ist möglich, mediale Präsentationen dem menschlichen Aufnahmevermögen besser angepaßt zu erzeugen. Multimedia wirkt damit auf das erwähnte Kernproblem der Informationsbeherrschung direkt ein. Es ist damit nicht nur eine Frage der besseren Sinnesbefriedigung, sondern vielmehr zentrales Entwicklungsproblem für Individuum, Unternehmen und Gesellschaft. In dieser Aussage unterscheidet sich Multimedia nicht von den es tragenden Technologien aus Computertechnik, Kommunikation und Elektronik. Der Unterschied besteht jedoch darin, daß es Synergieeffekte auf einem höheren Entwicklungsniveau durch Kombination mehrerer Technologien erschließt, also ein Entwicklungsstadium in der Evolution der Medien ist. (Abb. 1-8.1-1)

Abb. 1-8.1-1: Evolution der Medien [Mat94]

8.2 Multimediasysteme 8.2.1 Definition und Inhalt Wie viele Begriffe im Bereich der Informationsverarbeitung unterliegt auch Multimedia unterschiedlichen Auslegungen, die zudem im Laufe der Zeit mit zunehmenden Erkenntnisgewinn verändert werden. Problematisch sind Versuche, den Begriff orientiert am heutigen Stand der Technik auf bestimmte Methoden, Techniken, etc. einzugrenzen, da im Umgang mit Multimedia vielfaltige Entwicklungstrends erkennbar, aber nur teilweise überschaubar sind.

Teil I Informatik Grundlagen

241

Im Folgenden soll deshalb eine sehr weit abstrahierte Definition Grundlage der Erörterungen zum Thema sein. Multimedia ist eine elektronisch unterstützte Informations- und Kommunikationstechnologie, die auf mindestens zwei miteinander synchronisierten Medien basiert. Medium ist ein Mittel, das Träger von Informationen sein kann. Die Frage, die nicht abschließend beantwortet werden kann und soll, ist, welche Arten von Medien Multimedia zuzurechnen sind. Heutige Multimediasysteme sind eindeutig durch akustische und visuelle Medien geprägt. Dabei konzentriert sich die Akustik auf Geräusche, Musik und Sprache, während visuelle Darstellungen in textuelle, bildhafte und graphische unterteilt werden. Bilder können in Einzel- und Bewegtbilder differenziert werden. (Abb. 1-8.2-1)

Abb. 1-8.2-1: Klassifikation von heutigen Multimedia-Medien Alle akustischen Medien sind an Schallwellen gebunden. Trotzdem ist es sinnvoll, eine weitere Unterteilung vorzunehmen, da für Sprache und Musik definierte Bildungs- und Beschreibungsvorschriften existieren, die es gestatten, an der Schnittstelle zwischen Mensch und Computer entweder • •

aus Akustik digitale und analoge Daten zu erzeugen, die später wieder in Musik bzw. Sprache gewandelt werden können oder generativ aus digitalen und analogen Daten Sprache bzw. Musik zu erzeugen.

Auf dieser Basis kann beispielsweise auch Sprache in Text und Musik in Noten oder umgekehrt gewandelt werden. Durch diese Spezifik unterscheiden sich Sprache und Musik von den Geräuschen. Geräusche können jedoch auch

242

8 Multimedia

Informationen vermitteln. Deshalb sind sie dem Medienarten von Multimedia zuzurechnen. Zum Beispiel ist ein Warnton weder Sprache noch Musik, in bestimmten Fällen als Geräusch jedoch von Wichtigkeit. Akustische Medien sind auf Grund ihrer physikalischen Bindung an Schallwellen generell zeitabhängig. Im visuellen Medienbereich ist Text eine Spezielle Art als Abbild der Sprache. Text als Informationsmittel nimmt bei der Informationsaufnahme und dem Informationsaustausch eine wichtige Position ein. Graphiken stammen aus dem Bereich der generativen Computergraphik, d.h. der künstlichen Erzeugung von Darstellungen mittels definierter mathematischer Beschreibungsmittel. Im Gegensatz dazu reflektieren Bilder visuelle Erscheinungsformen von realen Objekten. Visuelle Medien können zeitabhängig (z.B. Video, Animation) oder zeitunabhängig (z.B. Standbild, Druckbild) sein. Interessant sind Wandlungsmöglichkeiten zwischen den verschiedenen Medien, die als Medientranslationen [Mey91] an Medienbrüchen bezeichnet werden. Zunächst ist die Wandlung in einer Gruppe von Medienarten möglich, wie zum Beispiel bei der Transformation eines Textes in ein Pixelbild im visuellen Bereich. Aber auch Transformationen zwischen den Gruppen sind üblich. Beispielsweise kann Sprache als akustisches Medium in Text als visuelles Medium gewandelt werden, wie es in Systemen zur Spracherkennung und generativen Spracherzeugung praktiziert wird. (Abb. 1-8.2-2)

Abb. 1-8.2-2: Beispiel einer Media-Translations-Kette Im Rahmen von Multimedia werden mehrere voneinander relativ unabhängige Informationsflüsse, die von unterschiedlichen Medien getragen werden, zeitlich synchronisiert und bei Bedarf transformiert. Das Ergebnis ist ein multimediales Produkt, das als Multimediaapplikation bezeichnet wird. Da eine Multimediaapplikation theoretisch zeitlich nicht begrenzt ist, kann sie in einzelne Blöcke, sogenannte Informationseinheiten, strukturiert werden. Eine Informationseinheit enthält verschiedene Komponenten. Damit eine Nutzersteuerung einer Multimediaapplikation überhaupt möglich wird, werden die Informationskomponenten mit Interaktionskomponenten verbunden. Über die Interaktionskomponenten kann der Nutzer zeitlichen und inhaltlichen Einfluß auf den Ablauf der Multimediaapplikation nehmen.

Teil I Informatik Grundlagen

243

Das logisch/physische Abbild einer Multimediaapplikation wird in Multimediadatenstrukturen abgelegt, die auch als Multimediadokumente bezeichnet werden. Im Zuge der Ergänzung und Verdrängung manueller Datenträger durch elektronische erscheint die BegrifFswahl „Dokument" gerechtfertigt, da sie dem komplexen Charakter von Multimedia entspricht. Grundlage für die Erstellung, Speicherung, Wiederauffindung, Übertragung Darstellung von Multimediaapplikationen unter Verwendung Multimediadokumenten sind Multimediasysteme. Multimediasysteme komplexe Hardund Softwarelösungen zur Behandlung Multimediadokumenten. [Mei94] Sie sind durch Kombination Unabhängigkeit der Medien sowie Rechnerunterstützung Kommunikationsfähigkeit der Systeme charakterisiert. [Ste93]

und von sind von und und

8.2.2 Bedarf und Einsatzfelder Der Bedarf nach Multimedia leitet sich aus dem Zwang zu Kommunikation und zur Beherrschung der damit verbundenen Informationsflut ab. Auch aus wirtschaftswissenschaftlicher Sicht ist Multimedia wegen wachsender Kommunikations- und Informationsanforderungen zu forcieren, wobei folgende Spezifika u.a. wirken: • • • • • •

Dynamik von Wissenschaft und Technik Internationalisierung der Märkte Globalisierung von Produktion und Dienstleistung Kosten- und Produktivitätsdruck Arbeitsteilung und Kooperation Ausschöpfung des Humankapitals.

Als einfaches Beispiel seien Videokonferenzen erwähnt. Durch die Möglichkeit der Durchfuhrung von Arbeitsberatungen mittels Videoübertragung, d.h. ohne Ortsveränderung der beteiligten Personen, können beispielsweise: • • • • •

Arbeitszeit in Form von Reisezeit eingespart Verfügbarkeit von Entscheidungsträgern im Stammhaus gesichert Reisekosten reduziert Reaktionszeiten in veränderten Situationen reduziert Zugriffe auf Stammhausinformationen durch den einzelnen Teilnehmer verkürzt und vereinfacht

werden, ohne daß der persönliche, visuelle Kontakt als eine wesentliche Komponente menschlicher Kommunikation verloren geht. Die Ansprüche an Multimedia werden im Anforderungsprofil zusammengefaßt, das verschieden Anforderungskomplexe umfaßt. (Abb. 1-8.2-3) Dabei sind zwei Sichten zu unterscheiden:

244 •

•

8 Multimedia

Der Nutzer fertiger Multimediaprodukte stellt seine Anwenderforderungen an die Multimediaapplikation, die auf einem System basieren muß, das wiederum den Ansprüchen der Applikation gerecht wird. Der Multimediaentwickler hat Forderungen an das Multimediasystem selbst.

Die Anforderungskomplexe beider Sichten sind im Prinzip kongruent, da es sich um generelle Anforderungen an informationsverarbeitende Systeme handelt. Funktionalität ist auf die Erfüllung der vom Nutzer benötigten Funktionen, wie optimale Kommunikation, realitätsnahe Präsentation, effiziente Speichening usw., gerichtet. Wirtschaftlichkeit beinhaltet Fragen wie Preis/Leistungsverhältnis, laufende Kosten, Amortisationszeit usw. Entwicklungsfähigkeit erfordert Flexibilität der Applikation bzw. des Systems, d.h. Erweiterbarkeit, Anpassungs - und Lernfähigkeit etc.

Abb. 1-8.2-3: Anforderungsprofil für Multimedia Vorhandene Multimedialösungen sind auf Einsatzfelder konzentriert und bieten dem Nutzer die Möglichkeit für spezifische Problemkreise seine Anforderungen zu erfüllen. Multimediaapplikationen aus informeller Sicht können wie folgt gegliedert werden: [Mei94] • • • • •

multimediale multimediale multimediale multimediale multimediale

Informationssysteme (Point of Information) Präsentationssysteme Lern- und Schulungsysteme Unterhaltungssysteme Kommunikationssysteme.

Teil I Informatik Grundlagen

245

Applikationen sind in allen Wirtschaftssektoren, d.h. in privaten Haushalten, Unternehmen, staatlichen Einrichtungen und Banken, zu finden. In [Sil] wird zum Beispiel das Spektrum von Inhalten für Multimedia im Marketing beschrieben. Einsatzfelder sind: [Sil] • • • • •

•

•

Absatzmarketing inklusive: Präferenz- und Einstellungsforschung, Reaktionsmessungen Produktentwicklung inklusive: Virtual Prototyping, Kommunikation der Produktentwickler Produktgestaltung inklusive: Produktbestandteil, Produktinformation, Service Produktpräsentation inklusive: Produktdarstellungen, Produktinformation Verkauf inklusive: Automatenverkauf, Schaufensterverkauf, Teleselling, Buchungen, Home Banking Nachkauf-Service inklusive: Bedienanleitung, Fehler- und Verschleißdiagnose, Produktprüfung, Schadensregulierung, Reparaturunterstützung, Dokumentation inklusive: Erstellung, Verwaltung, Archivierung

Multimediaanwendungen in Form von Präsentationssystemen für die Verkaufsunterstützung, Lernsystemen und Videokonferenzen sind typische Beispiele, die bereits relativ weit verbreitet sind.

8.2.3 Basistechnik und -technologien Multimedia basiert als komplexe Befahigungs- und Integrationstechnik auf mehreren Basistechniken und -technologien. Es wurde erst möglich, nachdem eine Reihe von Einzeltechniken und -technologien in ihrer Entwicklung soweit fortgeschritten waren, daß eine Integration sinnvoll und effizient wurde, d.h. sogenannte Synergieeffekte entstanden. Vor allem wurden Voraussetzungen für Multimedia durch leistungsfähigere Rechner, neue Standards beispielsweise für Massenspeicher und graphische Benutzeroberflächen geschaffen. Da Multimedia auf komplexen Hardware- und Softwaresystemen basiert, sind natürlich aus beiden Bereichen Schwerpunkte als Basis für Multimedia zu nennen, die auch in Zukunft die Multimediaentwicklung mitbestimmen werden. Auf dem Gebiete der Technik (Hardware) sind besonders relevant: [Mei94] [Ste93] • •

Audiotechnik (Abb. 1-8.2-4) inklusive Spracheingabe, Sprachübertragung und Sprachausgabe Videotechnik (Abb. 1-8.2-5) mit der Verbindung von digitaler Rechnentechnik und Fernsehen

246 • • • •

8 Multimedia

Speichermedien auf optischer Basis wie CD-ROM, CD-I, CD-ROM/XA, WORM- und MO-Platten Rechentechnik mit neuen Prozessoren, Speichersystemen, Busarchitekturen etc. sowohl im Internen als auch in der Peripherie Kommunikationstechnik vor allem Hochgeschwindigkeitsbzw. Breitbandnetze Unterhaltungselektronik wie Lautsprecher, Kameras, Mikrophone, usw.

SEQUENZER-SOFTWARE

MO-SMPTE-ANSCHLUSSBOX SWTE " f O " MIDI IN

VIDEORECORDER

Abb. 1-8.2-4: Multimedia unter Nutzung Audio [PCP92]

MIDI-INTERFACEKATRE

SMPTE-MODU

Teil I Informatik Grundlagen

247

Abb. 1-8.2-5: Multimedia-Videokarte / Anschlußmöglichkeiten [PCP92] Zwei grundlegende Trends für Hardware sind ersichtlich, einerseits steigende Leistung der Geräte an sich und andererseits die Entwicklung leistungsfähiger Peripherie gerichtet auf Multimedia. Darauf aufbauend werden spezielle Multimedia-Arbeitsplatzrechner als Portable, Personalcomputer oder Workstation konfiguriert. Zu unterscheiden ist zwischen Anwendungssystemen und Entwicklungssystemen sowie zwischen hybriden und digitalen Systemen. Hybride Systeme umfaßt analoge und digitale Komponenten, ein digitales digitale. [StH91] Bei Anwendungssystemen reicht u.U. eine reduzierte, Präsentationsanforderungen angemessene Konfiguration Entwicklungssysteme umfassen in der Regel alle Komponenten, die Einbeziehung und Bearbeitung der derzeit beherrschbaren, visuellen akustischen Medien ermöglichen. (Abb. 1-8.2-6)

nur den aus. die und

248

8 Multimedia

Tastatur

Desktop Bus

Maus TouchScreen

Rainbow Q

Graphikkarte

20" Bildschirm

17" Monitor mit Touch-Screen

HiFiAnlage

Mikrophon

Audiokarte Aktivboxen

Videokamera

Video / ScreenMachine

r

• Video-Recorder

Videoplayer TV Dmckemetzwerk

Netzwerkanbindung Scanner

Ethernet

Laser-/Farbd rucker

Netzwerkanbindung

SCSI

Speicher- und Transfermedien: CD-ROM, WP-Laufwerk, exteme/inteme Festplatte

Abb. 1-8.2-6: Multimedia-System auf Apple Macintosh [Sil] MPC ist Warenzeichen und zugleich Standard für Multimedia-PCs, das aus der Sicht eines MPC-Konsortiums definiert, was zu einem multimediafahigen PC gehört. [Die93] Der Multimedia-PC ist Kern einer Multimediakonfiguration, die abgestimmt auf die Anwendung ausgelegt wird. (Abb. 1-8.2-7)

Teil I Informatik Grundlagen

(Abruf aktualisierter Informationen)

Abb. 1-8.2-7: Point-of-Sale-Anwendung: Video-Dialogsystem von VW [Sil] Die Entstehung neuer Standards ist eng verbunden mit der Entwicklung oder veränderter Technologien als Basis für Multimedia. Dazu zählen u.a.: • • • • • • • •

Kodierungsverfahren Kompressionsverfahren Speichertechnologien Datenformatierung Synchronisationsverfahren Digitalisierungsverfahren Mischtechniken Übertragimgsverfahren

in Verbindung mit neuen Entwicklungen aus den Bereichen: • • • • • • • • •

Betriebssysteme Datenbanksysteme Kommunikationsdienste wie ISDN Spracherkennung und Sprachgenerierung Bildaufbereitung und Bildverarbeitung Musikverarbeitung Hypertext und Hypermedia. Digitales Fernsehen und Video Daten- und Benutzerschnittstellen.

250

8 Multimedia

Aufbauend auf Multimediatechnik und -technologie wird spezielle Multimediasoftware entwickelt. Wie in anderen Anwendungsgebieten der Informationsverarbeitung wird auch bei der Software in Entwicklung und Anwendung differenziert. In Analogie zu anderen Bereichen gibt es ebenfalls Entwicklungsunterstützung als Funktionen und Routinen in einer Programmierumgebung, in die komplexe Tools (Utilities) eingebettet werden können. Diese Tools werden bei Multimedia als Autorensysteme bezeichnet. Entwickler-Software und/oder Autorensysteme sind Grundlage für die eigentliche Software, die der speziellen Multimedia-Anwendung zuzuordnen ist. (Abb. 1-8.2-

Abb. 1-8.2-8: Software im Multimediabereich [Die93]

8.3 Multimediaentwicklung und Einsatz 8.3.1 Vorgehensmodell Prinzipiell gilt das klassische Phasenmodell [Rie88] aus dem Softwareengineering auch für die Entwicklung und den Einsatz von MultimediaAnwendungen. Allerdings ist es auf Grund der Komplexität der Aufgabe zu eng gefaßt, um zu befriedigenden Ergebnissen zu gelangen. Das objektorientierte Vorgehensmodell nach [Vet93] kommt den Anforderungen der MultimediaEntwicklung schon näher. Allerdings ist es methodisch auf Multimedia zugeschnitten zu untersetzen. Bei der Entwicklung einer MultimediaAnwendung darf keine zum klassischen Softwareengineering analoge Abgrenzung zwischen Hard- und Software vorgenommen werden.

Teil I Informatik Grundlagen

251

Bekannte Methoden des Softwareengineerings versagen in der Regel, weil Multimedia u.a. erfordert: • • • • •

dynamische Prozeß- und Informationsflußgestaltung wechselnde Kombination von Hard- und Softwarekomponenten neue Datentypen und Datenbanken multimediale Synchronisation und Kommunikation Bruch hierarchischer Strukturen und Übergang zu lose Informationseinheiten.

verketteten

Multimedia bedingt ein systemtheoretisches, objektorientiertes Vorgehen. Bei der Entwicklung einer Multimedia-Anwendung werden Methoden des Projektmanagements, des Systemsengineering und der Modellierung in Kombination angewandt. Neue Modellierungsmethoden und Beschreibungsmittel werden eingesetzt. [Mei94][Ste93] Wesentlich mehr Aufmerksamkeit wird den Modellierungs- und Designaktivitäten zu widmen sein. Eine rein auf das Problem Erzeugung von Multimedia-Anwendungen bezogene Vorgehensweise [Mei94] behandelt im Kern die Gestaltung der Strukturierung und Ablaufsteuerung von Informationseinheiten, ohne unbedingt klassische Phasenmodelle zu berücksichtigen. (Abb. 1-8.3-1) Drehbuch Strukturbeschreibung

Seiteninhaltsbeschreibung 7 Med en v 7 Screendesign

7 Dialogstr uktur 7 Anwendung

Abb. 1-8.3-1: Erzeugung einer Multimedia-Anwendimg [Mei94] Nachfolgend wird eine Vorgehensweise beschrieben, die sich zwar an bekannten Vorgehensmodellen orientiert, bei der jedoch in den Phasen eine auf die Belange von Multimedia zugeschnittene Untersetzung erfolgt.

8.3.2 Planung Strategische und konzeptionelle Aktivitäten werden im Rahmen der Planung der Multimedia-Anwendung verwirklicht. Nach [Sil] wird in Grob- und Feinplanung differenziert. Die Grobplanung (Abb. 1-8.3-2) beinhaltet die strategischen Überlegungen bis hin zu einer Rahmenkonzeption. Die Feinplanung (Abb.I-8.3-

252

8 Multimedia

3) umfaßt die Untersetzung der Rahmenkonzeption bis hin zur detaillierten Beschreibung der Entwicklungsprozesse für das Multimedia-Produkt.

C

Ziele / Aufgaben

I Einsatzfelder

Hard- und Softwarebedarf

tö©

Grobhonzeptc

© ö

Abb. 1-8.3-2: Grobplanung [Sil]

(

C

Grobkonzept

3

Zielgaippen- und Umfeldanalyse

( Protokollierungsfunktion

J)

Vernetzung / Hard- und SoftwareKonfiguration / Termingestaltung

G c

Konzeptüberprüfung / Zeitplanung

Detailkonzept

Abb. 1-8.3-3: Feinplanung [Sil]

J

>

Teil I Informatik Grundlagen

253

Unter dem Aspekt Multimedia sind Spezifika zu beachten. Besonderheiten existieren beispielsweise bei: [Sil] •

•

•

•

Aufwand für die Entwicklung Zentrale Stellung bezüglich zeitlicher, personeller und kostenmäßiger Aufwand nimmt in vielen Fällen die Videoentwicklung ein. Zusammenstellung des Projektteams Zusätzlich zu den in der Softwareentwicklung tätigen Fachpersonal sind Hardwarespezialisten, Filmproduzenten, Tontechniker, Graphiker und Photographen einzubeziehen. Storyboarderstellung Das Storyboard enthält die Beschreibung der kreativen Idee, den thematischen und inhaltlichen Leitfaden für die Produktion einschließlich der Fixierung der Aufgaben und Funktionen der einzelnen Medien sowie deren Zusammenwirken. Als Produktionsunterlagen werden zusätzlich Skripten erstellt, die im Detail jede einzelne Aktion für die Produktion strukturell, inhaltlich und zeitlich untersetzt. Skripten werden für jedes Medium einzeln sowie fiir deren Integration geschrieben. Für Storyboard und Skripten wird auch der Begriff Drehbuch verwendet. Hard- und Softwarekonfiguration Hard- und Software wird als Einheit konfiguriert. Rechnerplattform, Betriebssystem und Datenspeicherung werden unter dem Aspekt Multimedia betrachtet und ergänzt durch multimediale Komponenten wie Autorensystem und Audio-/Videoeinheiten.

8.3.3 Realisierung Die Realisierung wird in den Etappen Entwicklung, Erprobung/Anpassung und Einfuhrung durchgeführt. [Sil] Die Entwicklung beschränkt sich nicht nur auf Programmierarbeiten wie bei herkömmlichen Softwareprodukten. Zusätzlich sind Produktionsarbeiten durchzuführen, um die einzubindenden Informationen auf entsprechenden Medien (z.B. Video, Tonband) zur Verfügung zu haben und diese dann entsprechend zu integrieren. Im einzelnen werden in der Regel folgende Tätigkeitskomplexe eingebunden: • • • • •

• •

Herstellung informativer Texttafeln und von Begleittexten Entwicklung aussagekräftiger, übersichtlicher Graphiken Aufnahme und Auswahl von Bildern Videoaufnahmen und -schnitt Erstellung des Tonmaterials mit Sprache zur gezielten Information zum Problem sowie Musik/Geräuschen für Untermalung, Realitätsnähe und Akzentuierung Entwicklung von Animationen Verdichtung des visuellen Materials zu Informationseinheiten

254 • • •

8 Multimedia

Integration aller beteiligten Medien zu Informationseinheiten Zuschaltung von Interaktionskomponenten für die Mediensteuerung und Nutzung von Metaphern (z.B. Piktogramme) bei Bedarf Bindung der Informationseinheiten unter Regie der interaktiven Anwendungssteuerung im Rahmen der Anwendung

Nach Klärung der Fragen des strukturellen und zeitlichen Ablaufes steht die Gestaltung der Anwendung im Mittelpunkt. Ausreichend Zeit ist für die Erprobungs- und Anpassungsarbeiten vorzusehen, da durch die besonders hohe Komplexität Änderungen an der Endversion aufwendig sind. Im einzelnen sind zu überprüfen und ggf. anzupassen: • • • •

Verständlichkeit und Bedienbarkeit Benutzerführung und Zeitverhalten Wirkung der Medien einzeln und komplex inhaltliche Aussagen und fehlerfreie Ausführung.

Beim Einsatz der Anwendung sind Besonderheiten gegenüber herkömmlichen Softwareprodukten zu beachten. Während ein normales Lemprogramm zum Beispiel in einem Computerkabinett gleichzeitig an mehreren Arbeitsplätzen mit zeitlichem Versatz abgearbeitet werden kann, würden bei Einsatz von Ton und gleicher Verfahrensweise erhebliche gegenseitige Störungen der Lernenden auftreten. In dem Beispiel ist zu überdenken, ob zusätzlich: • • • •

Kopfhörer installiert werden Arbeitsplätze akustisch gekapselt werden Lautstärkeregulierung vorzusehen ist oder andere geeignete Maßnahmen zu treffen sind.

8.3.4 Controlling Leider wird in der Praxis oftmals die Erfolgskontrolle einer eingesetzten Lösimg vernachlässigt. Zugeschnitten auf Multimedia-Anwendungen werden nach [Sil] folgende relevanten Entscheidungsfelder für die Erfolgskontrolle hervorgehoben: • • •

Kontrollebenen Kontrollpunkte Indikatoren.

Kontrollpunkte und Indikatoren sind anwendungsspezifisch. In jedem konkreten Fall ist zu entscheiden, welche Punkte und Indikatoren als aussagekräftig zu beurteilen sind. Abstrahiert werden können die zu betrachtenden Ebenen. In der Entscheidungsebene erfolgt die Kontrolle der Wirkung der Anwendung aus der Sicht der Unternehmensleitung, in der Einsatzebene aus der Sicht der Mitarbeiter und in der Zielgruppenebene aus der Sicht der Endverbraucher.

255

Teil I Informatik Grundlagen

8.4 Beispiel einer Multimedia-Anwendung 8.4.1 Objektbeschreibung und Anwendungsziele Fabrikinformationssysteme sind vernetzte, offene und dynamische Systeme, die auf rechnerintegrierten Informationsflüssen in Betrieben basieren. Sie umfassen den kompletten Bereich der Produktionsinformationssysteme und realisieren die Vernetzung mit anderen betrieblichen Informationssystemen wie zum Beispiel mit betriebswirtschaftlichen Informationssystemen sowie betrieblichen Umweltinformationssystemen. Für Forschungs- und Ausbildungszwecke wurde das Fabrikinformationssystem Chemnitz aufgebaut. [Fab94] (Abb. 1-8.4-1)

Fabrikinformationssysfem Chemnitz FIS/C mtimmxmmtm

10 Manufaeturing C a l l s including 8 i W B H ^ f t t Systems

Abb. 1-8.4-1: Überblick Fabrikinformationssystem Chemnitz

7

256

8 Multimedia

Für die Weitergabe von Informationen über das Fabrikinformationssystem waren klassische Methoden der Wissensvermittlung nur begrenzt einsetzbar, weil: • • • •

die Informationsmenge über das System sehr groß ist unterschiedliche Weiterbildungsformen wie Selbststudium, Gruppenunterricht und Fernstudium zu beherrschen sind Datenschutz und Datensicherheit vor allem für Forschungsprojekte zu gewährleisten ist auf die Subsystem nicht immer direkt zugegriffen werden kann.

Abb. 1-8.4-2: Multimedia-Views auf das Fabrikinformationssystem [SRS95] Multimedia erwies sich als geeignete Methode für die fixierten Ziele: Beherrschung der Informationsflut, zielgerichtete Informationsaufbereitung, ständige Verfügbarkeit von Informationen, Datensicherheit und Datenschutz.

Teil I Informatik Grundlagen

257

Das Fabrikinformationssystem umfaßt eine Entwicklungs- und eine Anwendungsebene. Zur Informationsweitergabe sind vertikale und horizontale Sichten als Überblicks- oder Detailfenster auf das System erforderlich. Unter Beachtung der genannten Ziele entstanden mehrere MultimediaAnwendungen, die in aufbereiteter Form genau die Informationen enthalten, die der Nutzer für das spezielle Problem erhalten muß und soll. [SRS95] Damit gewährt Multimedia nicht nur aus Nutzersicht den Informationszugang, sondern kontrolliert auch den Informationsabgang aus Betreibersicht. Dieser Doppeleffekt ist für Nutzer und Betreiber gleichermaßen wichtig. (Abb. 1-8.4-2) Die entstandenen Multimedia-Anwendungen werden in eine entsprechende Library eingestellt und können bei Bedarf entweder für das Selbststudium am Rechner, für Distance Learning über Netze oder den Klassenunterricht beispielsweise über Rechner/Beamer genutzt werden.

8.4.2 Entwicklung und Einsatz In Anlehnung an [PGA94], das eine umfangreiche Beschreibung für multimediale Ausbildungsprogramme enthält und das prinzipiell zwischen Planung und Entwicklung beim Einsatz von Multimedia in der Lehre unterscheidet, sowie in Analogie zur bereits beschriebenen Vorgehensweise wurden auch die Multimedia-Anwendungen für das Fabrikinformationssystem verwirklicht. Im Laufe der Entwicklung haben sich bestimmte Schwerpunkte abgezeichnet, die eine Schlüsselbedeutung für die Qualität der Multimedia-Anwendungen haben. (Abb. 1-8.4-3)

Selection of Suitable Objects for the P r e s e n tation

Definition of K i n d and V o l u m e of A c o u s t i c Support Integration of Video and Photo Technologies

Abb. 1-8.4-3: Kernfragen bei der Multimedia-Entwicklung [ScR94]

258

8 Multimedia

Step 1 : Separate Medium Application Video Application

Acoustic Application

Computer Graphics

Step 2: Slide Show Continuous Show of Computer Graphics

Step 3: Slide Show with Acoustic Support

Music

— *

Slide Show

4 —

Language

Step 4: Multimedia Application Graphics

Music

Language

Text

Multimedia Animation

Video

Photography

Abb. 1-8.4-4: Zugangsvariante zur Multimedia-Entwicklung [ScR94] Als zentrales Dokument bei der Entwicklung vor allem größerer Anwendungen hat sich das Drehbuch erwiesen. Da es sowohl Struktur als auch Inhalt der

Teil I Informatik Grundlagen

259

Multimedia-Anwendung im Detail definiert, entscheidet seine Qualität im wesentlichen über die Qualität der Anwendung. Da professionelle MultimediaAnwendungen interdisziplinär entwickelt werden, muß der Spezialist sich auf die Sinnfalligkeit der Drehbuchanweisungen verlassen. Der Skriptschreiber muß über ausreichend Kenntnisse der Einzelmedien verfügen, um durch ihre Kombination zu einer optimalen Gesamtlösung zu kommen. Natürlich kann er bei Bedarf auf die Kenntnisse der Spezialisten zurückgreifen. Spezialisten werden in der Regel aus den Bereichen Graphik/Animation, Videotechnik/Photographie und Tontechnik einbezogen. Eine weitere wichtige Erfahrung ist, daß es sowohl inhaltlich als auch methodisch sinnvoll ist, von einfachen Vorformen multimedialer Anwendungen schrittweise zu komplexeren Formen zu gelangen. Anspruchsvolle Lösungen auf höchstmöglichem Niveau basieren auf profunden Erfahrungen im Umgang mit den Einzelmedien und sind auch aus Kapazitäts- und Kostengründen nicht immer notwendig. Deshalb wurde eine Step-by-Step-Strategie verfolgt. (Abb. I8.4-4) Die für das Fabrikinformationssystem realisierten Anwendungen wurden als Informationssysteme in verschiedenen Lehrformen und als Präsentationssysteme in Fachgremien sowie auf Fachveranstaltungen eingesetzt. Die positiven Erfahrungen haben zur Entscheidung geführt, durch zusätzliche Investitionen die Professionalität der Anwendungsentwicklung weiter zu verbessern.

8.5 Multimediatrends Da Multimedia eine Wachstumsbranche ist, unterliegt es einer besonderen Entwicklungsdynamik. Folgende Schwerpunkte werden die weitere Ausbreitung wesentlich beeinflussen: • • • • • • • • •

der Ausbau der Netzdienste (insbesondere ISDN) und Netzinfrastruktur [Rol94][Sie93][Gas95] der Übergang von Hypertext zu Hypermedia [Müh91][Bog92] und von Electronic-Mail zu Multimedia-Mail [Web94] verbesserte Rechenleistungen und Spezialhardware für Multimedia (Prozessoren, Karten, etc.) [PCP92] neue Multimedia-Entwicklungssoftware und Autorensysteme [Gas95] multimediale Dokumente und Standards [Bor91] Multimedia-Datenmodellierung und -Datenbanken [Mey91 ] [Gas95] Entwicklung der Speichertechnik und Unterhaltungselektronik neue oder weiterentwickelte Betriebssysteme[Sil] verbesserte Visualisierungstechniken [Bou93] und virtuelle Realität [ABF91/l][ABF94/2]

Wird über den zukünftigen Ausbau von Multimedia gesprochen, dann wird in der Regel an visuellen und akustischen Medien gedacht. Damit werden zwar die

260

8 Multimedia

Sinne des Menschen angesprochen, die hauptsächlich für die Perzeption von Informationen eingesetzt werden: Sehen und Hören. Der Mensch verfugt jedoch über weitere Möglichkeiten der Perzeption mittels Riechen, Schmecken und Fühlen. Sicherlich werden diese Sinne für die breite Multimedia-Nutzung in naher Zukunft noch von untergeordneter Bedeutung sein. Allein die Tatsache, daß bisher nur zwei Sinne durch Multimedia angesprochen werden, verdeutlicht anschaulich die weiteren Entwicklungsmöglichkeiten dieser „Befahigungstechnik" aus der Sicht der komplexen Informationserzeugung und Informationsaufnahme durch den Menschen.

Teil II Betriebliche Informationssysteme

261

Teil II Betriebliche Informationssysteme I Grundlagen 1.1 Systeme 1.1.1 Begriff und Eigenschaften Ein System ist ein zielgerichtetes und organisiertes Ganzes. Es besteht aus Elementen, die ihrerseits häufig wieder Systeme sind und dann als Subsysteme des übergeordneten Systems bezeichnet werden. Zwischen den Elementen eines Systems bestehen Beziehungen, deren Gesamtheit man als Struktur des Systems bezeichnet. Das vorgegebene Ziel bestimmt die Struktur des Systems. Die Abbildungen II-l.l-l bis II-1.1-3 zeigen in einfacher, schematischer Form wesentliche Systemmerkmale, II-l. 1-1 das System als Black Box im Kontext, II1.1-2 den hierarchischen Aufbau und II-1.1-3 die Beziehungen zwischen Elementen des Systems und seinen externen Partnern, d. h. seiner relevanten Umwelt. ^ — \

( ^

1-1

E-2

) '

— — 1-2

Abb. II-1.1-1: System als Black Box im Kontext

Abb.: II-1.1-2: Hierarchischer Aufbau eines Systems

262

1 Grundlagen

Ein System ist nur dann sinnvoll konzipiert, wenn es die vorgegebenen Ziele erreicht oder zur Erreichung beiträgt und wenn es in das übergeordnete System integriert ist und zur Erreichung von dessen Zielen beiträgt. Man unterscheidet insbesondere • statische und dynamische Systeme, • offene und geschlossene Systeme, • deterministische und stochastische Systeme.

Abb. II-1.1-3: Systemstruktur Dynamische Systeme ändern sich im Zeitablauf. Offene Systeme stehen in Beziehungen zu ihrer Umwelt (vgl. Abb. II-l.l-l und Abb. II-1.1-3). Statische und geschlossene Systeme sind demnach wenig realistisch Das Verhalten stochastischer Systeme ist im Gegensatz zu deterministischen durch Eingabegrößen nicht eindeutig bestimmt und daher nicht eindeutig vorhersagbar. Technische Systeme sind i. d. R. deterministische, soziale Systeme durchwegs stochastische Systeme. Ein System wird als komplex bezeichnet, wenn zwischen seinen Elementen eine große Zahl von Beziehungen besteht. Komplexe Systeme sind schlecht darzustellen, zu erfassen und zu gestalten. Um komplexe Systeme übersichlicher darzustellen, versucht man, sie klar zu gliedern, zu strukturieren und in Bausteine (Module) zu zerlegen. Hinsichtlich der Gliederungsgesichtspunkte ist Willkür nicht ganz auszuschließen, es gibt dazu aber keine echte Alternative. Das System Betrieb und betriebliche Informationssysteme sind durchwegs stochastische, offene, dynamische und höchst komplexe Systeme. Sie müssen sinnvoll in das jeweils übergeordnete System integriert sein. Dies gilt auch für Teile des

Teil II Betriebliche Informationssysteme

263

Informationssystems und fiir einzelne Programme. Aus der allgemeinen Systemtheorie werden wertvolle Erkenntnisse für Systemplanung/Vorgehen, Methoden der Modellierung und der Gestaltung von Informationssystemen gewonnen.

1.1.2 Regelung Das Erreichen der Systemziele wird durch Regelkreise sichergestellt. Ein Regelkreis ist ein geschlossenes Rückkoppelungssystem: Das Ergebnis der Transformation, einer Tätigkeit oder eines Schrittes wird erfaßt und mit dem vorgegebenen Ziel verglichen. Im Falle einer Abweichung wird entweder der Systeminput verändert oder das Transformationsverfahren modifiziert (letztlich auch aufgrund von Input). Ein Regelkreis ist Teil des zu regelnden Systems und besteht aus • dem Objekt der Regelung (Regelstrecke, RS), • einem Teilaggregat zur Messung des Output (Rezeptor, RZ), • dem Regler selbst (R) und • einem Teilaggregat zur Umsetzung des Ergebnisses des Ziel/Istvergleichs in Input, der aber im physischen Sinne nicht von außen zu kommen braucht (Effektor, E). Die Beziehungen zwischen den Elementen des Regelkreises werden durch die schematische Darstellung Abbildung II-1.1-4 zum Ausdruck gebracht. Input

RS E TNT

RZ

Ziele Abb. II-1.1-4: Regelkreis (A)

264

1 Grundlagen

Input

Ziele Abb. II-1.1-5: Regelkreis (B) Die Varianten A und B sind gleichwertig. Durch die gestrichelten Linien sind die (logischen) Systemgrenzen gekennzeichnet. Die Pfeile stellen materiellen Fluß und/oder immaterielle Beziehungen (Informationsfluß) dar. Ein Beispiel eines mechanisch realisierten Regelkreises bildet der Fliehkraftregler für Dampfmaschinen (Watt). Häufig erfolgt die Regelung eines realen Prozesses durch ein Informationssystem unter Einschaltung von Menschen als Regler (z.B. wirtschaftliche Systeme). Rückkoppelung und Regelkreise sind ein wesentliches Merkmal der Struktur von Systemen. Häufig enthält ein System mehrere vermaschte und überlagerte Regelkreise, wodurch insbesondere hohe Sicherheit und die Möglichkeit frühzeitiger Korrekturen erreicht werden sollen. Wichtige Fragen im Zusammenhang mit der Regelung sind die nach den Meßstellen (etwa die Frage, ob Rückkoppelungen bereits in früheren Phasen und nicht erst nach Beendigung einer Verarbeitung vorzusehen sind) und die Frage, ob der Output eines Systems oder eines Subsystems kontinuierlich oder zu bestimmten Zeitpunkten gemessen werden soll. Informationssysteme haben i. d. R. die Aufgabe, als Modelle (s. u. Abschnitt 1.1.3) reale Systeme abzubilden. So kann das Verhalten des realen Systems simuliert werden. Damit wird eine Art der Regelung möglich, die das Eintreten von Störgrößen in das System verhindert oder ihre Wirkungen von vornherein kompensiert und nicht erst nachträglich ihre negativen Auswirkungen korrigiert. Dem kommt in betrieblichen Informationssystemen besondere Bedeutung zu. Die folgende Darstellung eines Regelkreises entspricht der Realisierung in sozialen Systemen [nach Ulr70]:

Teil II Betriebliche Informationssysteme

265

Ziele

EntscheidgsInstanz f

\

Regler /

Input

Aktivität

IST-WertErfasser

J^t Output

A

Störungen Abb. II-1.1-6: Regelkreis in sozialen Systemen Der "Regler" hat hierin die Aufgabe, den gemessenen Ist-Wert mit dem Ziel - das gewöhnlich durch einen SOLL-Wert repräsentiert wird, der aber nicht immer dem echten Ziel entsprechen muß - zu vergleichen und eine eventuelle Abweichung an die Entscheidungsinstanz zu melden. Aber auch eine direkte Aktion bzw. Reaktion des Reglers ist in vielen Fällen sinnvoll (delegierte oder automatisierte Routineentscheidung). Charakteristisch für soziale Syteme ist aber die Verkettung oder Vermaschung von Regelkreisen, insbesondere aber eine hierarchische Verkettung: Die Tätigkeit (Aktivität) innerhalb des untergeordneten Regelkreises wird durch Ziele (Vorgaben, Planzahlen, Anweisungen) bestimmt, die die übergeordneten setzen. Dieser Sachverhalt zieht sich durch mehrere hierarchische Ebenen im Sinne der folgenden Darstellung [vgl. Ulr70], hier um eine Hierarchiestufe verkürzt):

266

1 Grundlagen

ARBEITER A ... Aktivität,

IWE ... bt-Wertirfasser,

MEISTER R ... Regler, EI ... Entscheidung; ins tanz

Abb. II-1.1-7: Vernaschte Regelkreise in sozialen Systemen Für IWE 2 ist zusätzlich zur Information von der untergeordneten EI eine weitere Informationsquelle (Statistik, Betriebsabrechnung) vorzusehen. Bei der Konzipierung von Informationssystemen sind sowohl Regelkreise innerhalb des Informationssystems (z. B. das System der Doppik in der Finanzbuchhaltung) als auch die Reglerfunktion des Informationssystems für das Gesamtsystem zu beachten!

1.1.3 Modelle Man unterscheidet zwischen realen und abstrakten Systemen, wobei abstrakte Systeme reale darstellen [vgl. Kla69], Derartige abstrakte Systeme, die reale darstellen oder abbilden, bezeichnet man als Modelle. Modelle sind, einfach und deutlich gesagt, Abbildungen von Systemen. Die Abbildungen II-l.l-l bis II-l.l7 sind in diesem Sinne Modelle. Es ist gewöhnlich nicht möglich und im Interesse der Anschaulichkeit auch nicht wünschenswert, ein System mit allen seinen Eigenschaften und Merkmalen als Modelle darzustellen. Klaus klassifiziert Modelle nach den Aspekten des Objekts, die Analogien im Modell besitzen (beispielsweise Funktions-, Struktur- und Verhaltensmodelle). Systeme werden als isomorph bezeichnet, wenn sie formgleich und austauschbar sind. Die Isomorphie - Beziehung ist umkehrbar. Besteht zwischen einem System und einem Modell Isomorphie, dann erfaßt das Modell alle Asppekte des Objekts und stellt nur ein bestimmtes System dar. Dieser Fall ist in Bezug auf komplexe wirtschaftliche Systeme bzw. Modelle unrealistisch.

Teil II Betriebliche Informationssysteme

267

Die Modellbildung muß in derartigen Fällen auf einer Vereinfachung, einer Abstraktion beruhen. Zwischen System und Modell besteht dann Homorphie. Unter einem bestimmten Gesichtspunkt wesentliche Aspekte werden hervorgehoben und durch das Modell dargestellt, andere vernachlässigt. Dominierend ist meist der formal-funktionale Aspekt, nicht die undividuelle inhaltliche oder materielle Realisierung. Ein Modell ist bestimmt durch seine Beziehung zu dem, wovon es Modell ist, und zu dem, wozu es Modell ist [vgl. Kla69], Darin liegt eine gewisse Willkür und eines der Hauptprobleme der Modelltechnik. Häufig erweisen sich nachträglich Aspekte, von denen abstrahiert wurde, als wesentlich. Es besteht die Gefahr, daß Modelle nicht die relevanten Merkmale des Systems darstellen, aber auch die, daß ein Modell das System, dessen Modell es sein sollte, nicht richtig abbildet. Modelle müssen daher verifiziert werden, d.h. sie sind auf ihren Wahrheitsgehalt hin zu überprüfen. Im Sinne Poppers darf Verifizieren nicht den direkten Versuch bedeuten, die Wahrheit oder Richtigkeit zu beweisen, sondern es muß vielmehr der ernsthafte Versuch unternommen werden, das Modell zu falsifizieren, d.h. zu beweisen, daß es unrichtig ist. Ein Sachverhalt oder eine These können als brauchbar angenommer werden, wenn mehrere ernsthafte Falsifizierungsversuche mißlungen sind. Streng betrachtet ist eine Verifizierung nicht möglich. Im weiteren soll das Wort "verifizieren" in diesem Sinne (mißlungene ernsthafte Falsififierungsversuche) verwendet werden. Als Regelinstrument verwenden Systeme häufig innere oder interne Modelle ihrer Umwelt. Ein Beispiel dafür bildet ein guter Schachspieler oder ein schachspielender Automat, der das Systemverhalten bei bestimmten Eingabegrößen (Zügen) anhand seines inneren Modells simuliert, bevor er eine Aktion setzt. Die meisten Entscheidungen intelligenter Menschen werden zuvor anhand eines derartigen Modells simuliert. Wenn der Regler über ein internes Modell des Systems (einschließlich der Umwelt) verfugt, kann die Qualität der Regelung wesentlich verbessert werden, weil unerwünschte Zustände gar nicht eintreten. Das System erreicht dann eine hohe Stabilität. Die Verifikation derartiger Modelle und ihre Anpassung an eine sich ändernde Umwelt sind besondere Probleme. Wichtige Fragen sind: • Was wird modelliert? • Wozu wird modelliert? Gegenstand und Methoden der Modellierung sind abhängig vom Zweck oder Ziel der Modellierung. Hier stehen im weiteren vor allem Organisation- und Informationsmodelle zur Diskussion. Zu modellieren sind insbesondere Funktionen, Prozesse, Daten und Beziehungen dazwischen.

268

1 Grundlagen

1.1.4 Zweck der Modellbildung / Vorgehensweise Die korrekte, anschauliche und zweckmäßige Darstellung erweist sich von großer Wichtigkeit für Analyse und Gestaltung von Systemen. Dabei mag es sich um betriebliche Informationssysteme, Grundlagen volkswirtschaftlicher bzw. wirtschaftspolitischer Entscheidungen, den Bau von Automaten, Raumfahrtsprojekte u.v.a.m. handeln. Ein gutes Modell des zugrunde liegenden Sachverhalts trägt wesentlich zur Lösung von Problemen bei. Weil ja die ganze reale Welt als Gefüge von Systemen betrachtet werden kann, ist auch das Arbeiten mit Modellen geradezu universell anwendbar. Modellierung von Systemen dient dazu, • Rückschlüsse auf das modellierte System zu ziehen, • Ergebnisse, Verhalten vorwegzunehmen (vgl. inneres Modell), • ein besseres Verständnis des Systems zu gewinnen, • das modellierte System zu gestalten. Daraus läßt sich folgern, daß Planung und Entwicklung von Informationssystemen letztlich eine Folge von Modellierungsschritten sind. In Zyklen verläuft die Entwicklung vom realen System über mehrere Modellierungsphasen zurück zum realen System. Modellierung des Informationssystems ist Voraussetzung für die Nutzung von Informatiktechnologien.

1.1.5 Instrumente der Modellierung Nach formalen Gesichtspunkten kann man vier Möglichkeiten zur Darstellung eines Sachverhalts (Systems) und damit Arten von Modellen unterscheiden. Systeme können • verbal, • durch Abbildung (Fotographie), • schematisch und • algorithmisch dargestellt werden. Die verbale Erläuterung bietet alle Möglichkeiten. Sie erlaubt vage und präzise, mehr oder weniger verständliche Formulierungen, fast beliebige Realitätstreue, Detaillierung und Abstraktion. Die Darstellung durch Abbildung kann nur als Ergänzung zur Veranschaulichung genannt werden. Die schematische und die algorithmische Darstellung haben sich in der Systementwicklung als besonders nützlich erwiesen, die schematische durchgehend, die algorithmische (formelmäßige) besonders für die Formulierung von Details in der Entwicklung konventioneller Anwendersysteme und in der Systemtheorie: Ein System gilt als identifiziert, wenn es algorithmisch dargestellt werden kann.

Teil II Betriebliche Informationssysteme

269

Durch schematische Darstellungen können Sachverhalte präzise und anschaulich dargestellt werden. Schematische Darstellungen sind gut zu verifizieren, sie sind geeignete Mittel zur Einbeziehung der Fachabteilungen, wenn diese damit vertraut gemacht wurden. Grundsätzlich müssen Modelle den Forderungen nach • Anschaulichkeit, • Verständlichkeit und • Komplexitätsminderung entsprechen. Dem letzten Gesichtspunkt trägt die derzeit in der Betriebswirtschaftslehre geradezu dominierende Lean-Diskussion Rechnung, denn die Komplexitätsminderung sollte bereits im Realsystem beginnen! Als Instrumente der Modellierung sind beispielsweise und vor allem zu nennen: •

Dekompositionsdiagramme (oder Hierarchie- oder Baumdiagramme) benutzt man für die Darstellung hierarchischer Strukturen von Funktionen, Prozessen, Zielsystemen, Organisationseinheiten umfassender Konzepte, aber auch für deren schrittweise Verfeinerung (Abschnitte 3.4 und 4);

•

Datenflußdiagramme zeigen Beziehungen zwischen Elementen, die beispielsweise in Dekompositionsdiagrammen dargestellt werden; Ein/Ausgabemodelle oder Kontextdiagramme als Sonderform der Datenflußdiagramme zeigen in übersichtlicher Weise Ein- und Ausgangsgrößen eines Systems und damit seine Einbindung in den Kontext (Abschnitt 3.4);

•

Prozeß-, Ablaufketten und Datenflußpläne zeigen auch zeitliche Zusammenhänge zwischen den dargestellten Elementen und Beziehungen zwischen Organisationseinheiten, Daten und Ablauffunktionen (Abschnitt 3.5);

•

Entity Relationship-Diagramme (ERD) sind ein geeignetes Instrument zur Darstellung von Datenmodellen (Abschnitt 3.3);

•

Matrizen bringen in übersichtlicher Weise Beziehungen zwischen zwei Objekttypen zum Ausdruck, beispielsweise Herkunft und Verwendung von Daten, Funktionen und Daten, Funktionen und Personen (Abschnitt 4);

•

Entscheidungstabellen dienen zur Darstellung von Bedingungskombinationen und daran geknüpfte Aktionen (Beispiel: Wann wird eine Rechnung zur Zahlung freigegeben?).

In den folgenden Abschnitten zeigen wir die sinnvolle Nutzung der Modellierungsinstrumente im konkreten Zusammenhang.

270

1 Grundlagen

1.2 Der Betrieb als System Die Abbildungen II-1.2-1 und II-1.2-2 zeigen analog den Abbildungen I I - l . l - l und II-1.1-2 in einfacher, schematischer Form das System Betrieb als Black Box im Kontext bzw. den hierarchischen Aufbau des Betriebes.

Abb. II-1.2-1: Der Betrieb als Black Box im Kontext

Abb. II-1.2-2: Hierarchischer Auibau des Betriebes Das System Betrieb kann nach unterschiedlichen Gesichtspunkten in Subsysteme aufgegliedert werden. Man findet allgemein organisatorische Gliederung nach den folgenden Gesichtspunkten vor: • • • • • • •

nach Verrichtungen bzw. Leistungs- oder Funktionsbereichen (z.B. Einkauf, Verkauf, Materialwirtschaft, Rechnungswesen usw.), nach Objekten der Tätigkeit, z. B. Produkten oder Produktgruppen, nach dem Rang der Tätigkeit, d.h. nach Leitung und Ausfuhrung, nach der Phase der Tätigkeit, d.h. Planung-Realisierung-Kontrolle, nach der Zweckbeziehung, d.h. Primäraufgaben und (sekundäre) Verwaltungsaufgaben, regional/räumlich, nach Betriebsmitteln, z.B. Rechenzentrum.

Der Kern dieser Gliederung geht auf Kosiol zurück, im übrigen sind Bleicher und Schwarz zu nennen. Meffert weist in diesem Zusammenhang besonders auf funktionale Gesichtspunkte (Beschaffung, Produktion, Rechnungswesen usw.), Machtausübung (Führung, Ausführung) und Prozeßphasen (Planung, Realisierung, Kontrolle) hin.

Teil II Betriebliche Informationssysteme

271

Zweckmäßig erscheint die Gliederung des Betriebes nach • realem System (realem Betriebsprozeß), • sozialem System und • Informationssystem.

1.3 Das betriebliche Informationssystem 1.3.1 Einbindung und Gliederung Das Informationssystem bildet das reale System ab. Es dient in der Regel zur Steuerung von realen Systemen. Das Informationssystem kann nach denselben Gesichtspunkten gegliedert werden wie der Betrieb selbst, den es abbildet, in der Regel nach Verrichtungen bzw. Funktionen und nach Objekten. In den letzten Jahren hat die prozeßorientierte Betrachtung an Bedeutung gewonnen, d. h. eine Gliederung nach den durch das Informationssystem unterstützten Unternehmensprozessen. Letztlich werden durch die "Gliederung" die für die jeweilige Betrachtimg relevanten Gesichtspunkte hervorgehoben, andere in den Hintergrund gestellt. Diese Fragen wurden bereits oben (Abschnitt 1.1.3) erörtert. Hier gehen wir zunächst von der "klassischen", im wesentlichen funktional orientierten Betrachtimg aus. Eine grundsätzliche Alternative zu diesem Vorgehen bzw. dieser Betrachtungsweise ist die objektorientierte Methode (vgl. dazu Teil I, Abschnitt 7.2 und Teil II, Abschnitt 3.6). Innerhalb des betrieblichen Informationssystems unterscheidet man das operative und das dispositive Informationssystem. Aufgabe des operativen Informationssystems sind Erfassung und kurzfristige Regelung des betrieblichen Durchsatzprozesses. Das operative Informationssystem hat somit die Massenarbeit des Tagesgeschäfts zu bewältigen. Zu den Funktionen des operativen Informationssystems gehören Dispositionen innerhalb der Routineabläufe (z.B. Maschinenbelegung, Versanddisposition, Zahlungsverkehr), als entsprechende Funktionen des dispositiven Informationssystem kann man die Unterstützung von Investitionsentscheidungen, Entscheidungen über Versandarten und -wege und zur Mittelbeschaffung oder Verwendung anführen. Operative Informationssysteme werden auch als Administrationssysteme bezeichnet [Mer93]. Das dispositive Informationssystem dient zur mittel- und langfristigen Planung und Optimierung des Prozesses der Leistungserstellung. Es umfaßt Modelle für Optimierung und Simulation, "Führungsinformationssysteme" für alle Funktionsbereiche, ein Frühwarnsystem. Betriebsinterne und -externe Daten werden einbezogen. Die hier getroffene Begriffsbestimmung des "dispositiven" Informationssystem orientiert sich an den Funktionen des dispositiven Faktors, d.h. der Unternehmensführung. Die Unterstützung von Aufgaben eines Versand- oder Materialdis-

272

1 Grundlagen

ponenten wird dem operativen Informationssystem zugeordnet. Wichtige Ziele des operativen Informationssystem sind die Automatisierung von Massenarbeiten und die Automatisierung/Unterstützung von Routineentscheidungen, des dispositiven die Unterstützung von Führungsentscheidungen. Im operativen Informationssystem werden Basisdaten gepflegt, fortgeschrieben und für das dispositive Informationssystem bereitgestellt, das letztere übergibt Planzahlen an das operative Informationssystem. So besteht eine wechselseitige Beziehung über gemeinsam benutzte Basisdaten, die im weiteren bei der Erläuterung von Informationsbeziehungen nicht mehr besonders hervorgehoben wird. Dispositive Aufgaben sind individuell ausgeprägt. Sie sind schlecht in starre Regeln zu kleiden. System- und Programmentwicklung auf dem Wege wie hier beschrieben stoßen auf Schwierigkeiten. Gut geeignet für derartige Entwicklungen sind Programmiersprachen der vierten Generation, PC-Datenbanken und Spreadsheet-Programme. Mertens/Griese unterscheiden die vier Hauptklassen [Mer93, MeG93] • Administrations-, • Dispositionssysteme, • Planungs- und • Kontrollsysteme. Dazu kommen • Textverarbeitung und -gestaltung, Graphik und • Kommunikation. Administrationssysteme zielen auf die Rationalisierung der Massendatenverarbeitung in der Verwaltung und damit auf Rationalisierungsnutzen [Mer93], Über die reine Administration hinaus haben Dispositionssysteme die Aufgabe, entweder menschliche Entscheidungen vorzubereiten oder sie zu erübrigen, indem die Rechenanlage die Entscheidung selbst trifft [Mer93], Es handelt sich dabei i. d. R. um Routineentscheidungen. Planungssysteme kann man als Weiterentwicklung von Dispositionssystemen betrachten. Sie unterstützen i. d. R. die interaktive Bearbeitung schlecht strukturierter und nicht voll automatisierbarer Probleme bzw. Aufgabenstellungen. Kontrollsysteme ergänzen Planungssysteme und sollen die Planeinhaltung unterstützen. Wir benutzen im weiteren die anerkannte und verbreitete Gliederung nach Mertens/Griese. Dem oben so bezeichneten operativen Informationssystem entsprechen Administrations- und Dispositionssysteme (AuD-Systeme), dem dispositiven Informationssystem Planungs- und Kontrollsysteme (PuK-Systeme). Informationssysteme können auch nach anderen Gesichtspunkten gegliedert werden, beispielsweise • Datenbasis und Zugriff • Ein-/ Ausgabe

Teil II Betriebliche Informationssysteme •

273

Verarbeitung.

Diese Gliederung erscheint besonders auf Programmebene sinnvoll, weil so Wünsche zur individuellen Gestaltung der Benutzeroberfläche (Masken, Listbilder) ohne Veränderung (Beeinträchtigung) der fachlichen Substanz der Programme relativ leicht realisiert werden können, anderseits aber auch relative Beweglichkeit hinsichtlich der Verwendung von Datenbanken oder Dateiverwaltungssystemen besteht. Größte praktische Bedeutung haben die Gliederung nach Funktionen und die nach Objekten, wie Sparten, Kunden- oder Produktgruppen: Es können sich beispielsweise völlig andersartige Lösungen eines Warenwirtschafitssystems ergeben, wenn man •

•

als Gliederungsmerkmal Geschäftsbereiche (Sparten) zugrundelegt und für jede Sparte ein auf ihre Besonderheiten zugeschnittenes Konzept entwickelt oder ein funktional gegliedertes (zentrales) Konzept mit Berücksichtigung der Besonderheiten der Sparten auf tieferer Stufe zugrundelegt.

In der Regel ist ein System auf unterschiedlichen Ebenen nach unterschiedlichen Gesichtspunkten gegliedert, in den folgenden Beispielen (Abb. II-1.3-1 bis II-1.33) etwa auf oberster Ebene nach AuD-, PuK-Systemen, Textverarbeitung/Graphik und Kommunikation, darunter nach Funktionen.

Abb. II-1.3-1: Hierarchische Struktur (Dekompositionsdiagramm) des betrieblichen Informationssystems/gesamt (beispielhaft) In den Abbildungen II-1.3-1 bis II-1.3-2 gehen wir systematisch von oben nach unten vor (Top Down) mit schrittweiser Verfeinerung. Abbildung II-1.3-1 zeigt die oberste Ebene, die neben dem operativen und dem dispositiven Informationssystem auch die heute üblichen Bausteine Textverarbeitung/Graphik und Kommunikation enthält, als einstufige, die übrigen zeigen mehrstufige Hierarchien. Die Verfeinerung nach unten erfolgt nicht generell, sondern nur für ausgewählte (Funktions-) Bereiche. Einen weiteren Verfeinerungsschritt in einer etwas geänderten Darstellungsweise zeigt Abbildung II-1.3-4 für den Bereich der Verkaufsabwicklung.

274

1 Grundlagen

Abb. II-1.3-2: Hierarchische Struktur (Dekompositionsdiagramm) des administrativen/dispositiven Teils des Informationssystems (1. Verfeinerung von Abb. II-1.3-1)

Eine derartige hierarchische Strukturierung durch Dekomposition ist grundsätzlich nach allen Gliederungsgesichtspunkten des Systems, nicht nur nach Funktionen, möglich.

Teil II Betriebliche Informationssysteme

275

Lamingsu. Kontrollsysteme (PuK)

PuK Wertschöpfungsprozess

Know HowDaten

PuK Verwaltung i. w. S.

-

PatentVerwaltung

Marktdatenerfassung

Werbeplanung

Absatz-/ Produktionsplanung

Konfiguration Verkaufsprodukte

Mifri. Finanzplanung

Kufri. Finanzplanung

Investitionsplanung

Abb. II-1.3-3: Hierarchische Struktur (Dekompositionsdiagramm) des Planungsund Kontrollsystems (1. Verfeinerung von Abb. II-1.3-1)

Verkaufsabwicklung Stammdtpflge Vertrieb VerkaufsParameter Kundenverkaufsdaten Artikelverkaufsdaten Verkaufspreise Verkaufs-Sonderkonditionen

Auftragserfassung Erfassen im Dialog DFUÜbemahme Druck Auftrgbestätigung Erfassen Gutschrift

Auftragsabwicklung Terminüberwachung Versandplanung Rückmeldung IST-Versand Drucken Lieferschein Freigabe Fakturierung Druck Rechnungen

Auswertungen Vertrieb Umsätze Auftragseingang Auftragsbestand Preisentwicklung Kundenbeurteilung

Abb. II-1.3-4: Hierarchische Struktur Verkaufsabwicklung (2. Verfeinerung von Abb. II-1.3-1)

276

1 Grundlagen

1.3.2 Integration Das Beispiel der Abbildungen II-1.3-1 bis II-1.3-4 macht auch deutlich, daß jedes Teilgebiet (Subsystem) sinnvoll in das Gesamtsystem eingegliedert sein muß. Neben der Forderung nach Strukturierung ist die nach Integration die zweite für die praktische Systemplanung besonders wichtige Konsequenz aus den systemtheoretischen Grundbegriffen. Die Subsysteme müssen sowohl horizontal (auf derselben Ebene, z. B. Fakturierung und Debitorenbuchhaltung) als auch vertikal (in das übergeordnete System) integriert sein. Diese Forderungen bedeuten auch, daß das Informationssystem unter Berücksichtigung des Realsystems in das Gesamtsystem eingebunden sein muß. Abbildung II-1.3-5 zeigt stark verdichtet Teilbereiche des betrieblichen Informationssystems und seine Einbindung in das Realsystem in schematischer Darstellung:

Abb. II-1.3-5: Gesamtintegration des betrieblichen Informationssystems Integration ist somit ein zwingendes Erfordernis der Systemplanung und -gestaltung. Bezogen auf integrierte Informationsverarbeitung, nennt Mertens [Mer93] die folgenden Integrationsziele, die wir in geraffter Form wiedergeben: •

Durch integrierte Informationsverarbeitung werden die negativen Auswirkungen der Abteilungsgrenzen im Betrieb zurückgedrängt

•

Der manuelle Eingabeaufwand kann auf ein Minimum reduziert werden, weil die einzelnen Funktionen Daten automatisch austauschen (dies zeigte sich deutlich im vorhergehenden Abschnitt).

•

Der verminderte Eingabeaufwand führt dazu, daß moderne betriebswirtschaftliche Konzeptionen besser oder überhaupt erst realisiert werden können, weil auf ohnedies gespeicherte Daten zurückgegriffen werden kann.

•

Durch die Reduzierung manueller Eingaben reduziert sich die Gefahr von Erfassungsfehlern.

Teil II Betriebliche Informationssysteme

277

•

Da Folgemaßnahmen fest programmiert sind, wird nichts "vergessen", beispielsweise die Veibuchung einer Ausgangsrechnung.

•

Die Mehrfachverwendung von Daten führt dazu, daß eventuelle Fehler mit höherer Wahrscheinlichkeit entdeckt werden.

•

Integrierte Informationsverarbeitung trägt zur Vermeidung lokaler Suboptima bei, die dem Gesamtoptimum entgegenstehen können.

Wir betrachten nach der Integration des gesamten Informationssystems nun speziell die horizontale Integration im Bereiche der AuD-Systeme und beschränken uns auf die Funktionsbereiche, die vom Arbeitsanfall her die größte Bedeutung haben und in denen sich daher die positiven Effekte der Integration am meisten auswirken. Wir gehen aus von Abbildung II-1.3-2 und fassen für diese Betrachtung die AuD- Systene für den Bereich der Wertschöpfung und den der Verwaltung im weiteren Sinne (i. w. S.) zusammen. Die Finanzbuchhaltung umfaßt • Debitoren-, • Kreditoren- und • Sachkontenbuchhaltung, die • • •

Kosten- und Leistungsrechnung umfaßt Kostenstellenrechnung, Kostenträgerrechnung und Ergebnisrechnung.

Abb. II-1.3-6: Horizontale Integration im Bereich der AuD-Systeme

278

1 Grundlagen

Der Funktionsbereich Personalwesen - wozu auch Personalinformationssysteme (PIS) gehören - wurde hier reduziert auf die Lohnabrechnung, was diesem Aufgabengebiet keineswegs gerecht wird, im vorliegenden Zusammenhang (Integration) aber vertretbar erscheint. Das Rechnungswesen und seine Teilbereiche stehen in Beziehung zu den Funktionsbereichen des Wertschöpfungsbereichs. Die Fertigungssteuerung ist - im Interesse der Komplexitätsminderung - nur über die Materialwirtschaft mit den übrigen Teilfunktionsbereichen der Ablaufregelung verknüpft. Dies ist sicherlich nicht in allen Betrieben realisierbar. Auch hier ist das Personalwesen nicht berücksichtigt. Damit kommen wir zu einer Darstellung gemäß Abbildung II-1.3-6. Formal handelt es sich hier um ein Datenflußdiagramm im Sinne der Strukturierten Analyse (vgl. Abschnitt 3.4). Die Verknüpfungen (Schnittstellen) zwischen den Funktionsbereichen sind dort jeweils nur kurz durch Angabe von Quelle und Ziel gekennzeichnet. LuG an KOR bedeutet, daß der Funktionsbereich LuG (Personalwesen) Daten an den Funktionsbereich KOR (Kosten- und Leistungsrechnung) übergibt. "Übergeben" ist hier nur im logisch-konzeptionellen Sinne zu verstehen, damit wird keine Aussage zur physischen Realisierung gemacht: Die tatsächliche Realisierung erfolgt i. d. R. so, daß die Daten vom Sender in der Datenbank abgestellt, vom Empfanger von dort gelesen werden. Inhaltlich bedeuten die Verknüpfungen - stichwortartig - im einzelnen: LuG an KOR:

LuG an Fibu:

Fibu an KOR: Ek an Fibu: Vk an Fibu: Mat an Fibu: Vk an KOR: Mat an KOR:

Vk an Mat:

Mat an Vk:

Lohnstunden und/oder Fertigungslöhne als Bezugsgröße für die Kostenstellenabrechnung, Gemeinkostenlöhne nach Kostenarten und Kostenstellen ebenfalls für die Kostenstellenabrechnung, Fertigungsstunden und -löhne nach Kostenträgern für Kostenträger- und Ergebnisrechnung Lohnsummen (des Lohnjournals) mit Arbeitgeberanteilen, Nettolohnzahlung, Verbindlichkeiten an Finanzamt, Rentenund Krankenversicherung usw. Verteilung der Gemeinkosten aus der Finanzbuchhaltung Geprüfte Eingangsrechnungen Ausgangsrechnungen Materialbestand und -einsatz (Fakturierte) Kostenträgererlöse Materialeinsatz nach Kostenträgern an die Kostenträgerrechnung, Verbrauch von Gemeinkostenmaterial an die Kostenstellenrechnung Eingeplante (bestätigte) Kundenaufträge sind in der Materialwirtschaft (Disposition) als Reservierungen zu fuhren, Lieferungen an Kunden fuhren zu einer Löschung der entsprechenden Reservierung und zu einer Abgangsbuchung Aussagen über die Verfügbarkeit werden von der Disposition bereitgestellt

279

Teil II Betriebliche Informationssysteme Mat an KOR: EK an Mat:

Mat an Ek: PPS an Mat:

Mat an PPS: PPS an LuG:

Preisabweichungen, Bestandsveränderungen Eingeplante Bestellungen sind in der Materialwirtschaft (Disposition) als geplante Zugänge zu führen, Wareneingänge aufgrund von Bestellungen fuhren zu einer Löschung der entsprechenden Bestellung und zu einer Zugangsbuchung, Rechnungseingänge werden an die Materialwirtschaft zur Bewertimg der Bestände übergeben Bestellvorschläge kommen von der Disposition Produktionsaufträge werden analog den Kundenaufträgen (und zwar der Bedarf für Produktionsaufträge gemäß Stücklistenauflösung) bzw. den Bestellungen (hinsichtlich des durch den Auftrag herzustellenden Produktes) als Reservierungen bzw. als geplante Zugänge an die Disposition übergeben, Lagerbewegungen führen jeweils zu einer Löschung der entsprechenden Disposition Bestellvorschläge kommen von der Disposition Leistungsnachweise für Bruttolohnabrechnung

Die Darstellung gemäß Abb. II-1.3-6 läßt sicherlich fachliche Fragen offen, hier soll vor allem die Methode der Darstellung derartiger Sachverhalte gezeigt werden. Die Verknüpfungen in Abbildung II-1.3-6 beruhen zum größten Teil auf der reinen Übergabe von Daten von einem an den anderen Funktionsbereich. Dazu kommen Verknüpfungen durch gemeinsam benutzte Datenbestände. Diese Verknüpfungen erscheinen in Abbildung II-1.3-6 bereits in den Beziehungen Ek an Mat, Vk an Mat und PPS an Mat. Sie werden nun in starker Vereinfachung insgesamt durch die Matrix Abbildung II-1.3-7 zum Ausdruck gebracht werden. Die letztgenannte Verknüpfung ist die intensivere und problematischere. Funktionsbereiche

Datenbestände Artikelstamm Kunden- / Debitorenstamm Lieferanten-/ Kreditorenstamm Stücklisten Kundenaufträge Lieferanten-bestellungen Produktions-aufträge

Finanzbuchhaltung

VertriebMarketing

X X

Beschaffung/ Einkauf

Materialwirtschaft

X

X

PPS

X

X

X

X X X

X X

X X

X

Abb. II-1.3-7: Verknüpfung Funktionsbereiche/Datenbestände Die Betrachtung von Informationssystemen auf die Art wie dargestellt ist Voraussetzung dafür, daß komplexe und integrierte Systeme in einfachere Bausteine zerlegt werden, die dann relativ gut realisiert werden können, wobei die Integration durch Berücksichtigung der Schnittstellen, d. h. der Informationsbeziehungen gemäß Abbildung II-1.3-6 bzw. der gemeinsam benutzten Datenbestände gemäß

280

1 Grundlagen

Abbildung II-1.3-7 gewahrt bleibt. So ist die Realisierung integrierter Informationssysteme auch auf verteilten Rechnersystemen möglich.

1.3.3 Sichten von Informationssystemen Die Komplexität von Informationssystemen zwingt - vgl. unsere entsprechenden Aussagen dazu oben in Abschnitt 1.1.3 - zur Abstraktion von für die jeweilige Betrachtung nicht relevanten Tatbeständen. Man spricht dann von Sichten. Sichten sind unterschiedliche Betrachtungsweisen desselben Systems. Sichten sind Subsysteme besonderer Art, weil sie letztlich i. d. R. keine Eigenständigkeit besitzen. Auch das Informationssystem ist eine Sicht des Systems Betrieb. Das betriebliche Informationssystem ist ohne das entsprechende Realsystem bedeutungslos, ebenso ist aber auch das Realsystem ohne Informationssystem nicht eigenständig existenzfähig. Aus der Einbindung des Informationssystems in den Betrieb kommt man zu einer Betrachtung bzw. Gliederung des Informationssystems, wobei die Sichten in Schichten angeordnet sind: Im weitesten Sinne werden die Unternehmensziele durch das Realsystem des Betriebes (oder das Basissystem, d. h. das System der Leistungserstellung) unterstützt, dies allerdings nicht unmittelbar, sondern mittels des betrieblichen Informationssystems. Unternehmensziele

Betriebliches Informationssystem

7K Basissystem des Betriebes

Abb. II-1.3-8: Unterstützung der Unternehmensziele durch das Informationssystem Abb. II-1.3-8 ist dahingehend zu interpretieren, daß das betriebliche Informationssystem die Ressourcen des Betriebes nutzt, um die Unternehmensziele zu unterstützen. Verfeinert man den mittleren Block, nämlich das Informationssystem, so kann man präzisieren: Die Unterstützung der Unternehmensziele erfolgt unmittelbar durch Unternehmensprozesse (vgl. dazu unten den Abschnitt 3.5). Unternehmensprozesse enthalten oder benutzen Funktionen, die ihrerseits auf Daten zugreifen oder Daten benutzen. Daraus resultieren eine Gliederung nach Daten-, Funktions- und

Teil II Betriebliche Informationssysteme

281

Prozeßsicht und eine schichtenmäßige Darstellung dieser Sichten des betrieblichen Informationssystems gemäß Abb. II-1.3-9. Unternehmens Prozesse

\ /

Funktionen

i T

benutzen

unterstützen

Daten

Abb. II-1.3-9: Schichtenmäßige Darstellungen von Sichten des Informationssystems Die Datenbasis dient nicht unmittelbar den Unternehmenszielen, sie ist aber Voraussetzung für die Realisierung von Funktionen und von Unternhemensprozessen und der in der Praxis wichtigste Teil des EDV-gestützten Informationssystems. Die Gliederung des Informationssystems nach Sichten dient der Komplexitätsminderung. Es handelt sich insgesamt um ein bewährtes Prinzip, das besondere Bedeutung in der Systemplanung und im "klassischen" Software Engineering (s. u. die Gliederung von Kapitel 3 Software Engineering) hat. Ein Problem liegt allerdings in der Zusammenfuhrung der zunächst gesondert betrachteten Funktions-, Daten- und Prozeßsichten. Scheer (Sce92) unterscheidet Organisations-, Vorgangs- oder Funktions- und Datensicht, die durch die Steuerungssicht verknüpft werden. Dazu kommt die (IT-) Ressourcensicht, die wegen ihrer Systemnähe hier nicht weiter betrachtet wird. Auf die darauf aulbauende Architektur von Informationssystemen wird im folgenden Kapitel 2 eingegangen.

2. Architektur 2.1 Konzepte Die im vorhergehenden Kapitel beschriebene Integration betrieblicher Anwendungssysteme führt zu einer hohen Komplexität der Informationssysteme in den Unternehmen. Für die notwendige arbeitsteilige Planung, Entwicklung und Einführung solcher Systeme sowie ihren Betrieb und die Anpassung an sich verändernde Geschäftsprozesse ist daher eine Beschreibung notwendig, die sowohl die Komplexität

282

2 Architektur

durch geeignete Zerlegungen reduziert als auch die Kommunikation zwischen den Mitarbeitern der Fachabteilungen und den DV-Spezialisten ermöglicht. Ein Regelsystem, das die Zerlegung eines Informationssystems in einzelne Bausteine und ihr Zusammenwirken beschreibt, nennt man Architektur des Informationssystems. Von einer brauchbaren Architektur wird man nach dem vorangehenden außerdem eine Unterstützimg des Vorgehens zur Entwicklung und der Anpassung von Informationssystemen fordern. Vorschläge für Architekturen und Methoden zum Entwurf konkreter Informationssysteme nach diesen Regelsystemen wurden von mehreren Autoren und Expertengruppen entworfen. Eine Übersicht dazu findet sich in dem Buch von Scheer [Sce92, S. 24], in dem er selbst die „Architektur integrierter Informationssysteme" (ARIS) entwickelt. Wir werden uns im weiteren speziell mit dem ARIS-Konzept befassen, das insbesondere aufbau- und ablauforganisatorische Aspekte des im Informationssystem abgebildeten Unternehmensbereichs in den Vordergrund rückt. Im Abschnitt 3.6 wird dann noch auf ein objektorientiertes Konzept, das „Semantische Objektmodell" (SOM) von Ferst/ und Sinz [Fes94], eingegangen.

2.2 Das ARIS-Konzept von Scheer Ziel der ARIS-Architektur ist die ganzheitliche Beschreibung (Modellierung) von Geschäftsprozessen als Basis für die Entwicklung und Anpassung komplexer Informationssysteme. Ausgangspunkt sind dabei die konkreten Geschäftsprozesse des Unternehmens, aus denen die Modellbausteine und ihre Beziehungen entwickelt werden. In einer tiefgehenden Analyse wird dann das theoretische Fundament der Architektur ein Metamodell für Informationssysteme - entwickelt. Wir stellen im weiteren den ersten Teil dieses Weges in Anlehnung an Scheer ([Sce92]) dar. Der zweite Teil - die Ableitung des Metamodells - wird nur kurz und im Hinblick auf seine Bedeutung besprochen. Betrachtet man innerhalb des Geschäftsprozesses „Auftragsbearbeitung" einen Teil der Vorgangskette für einen konkreten Auftrag, so ist für das weitere folgende Darstellung nützlich (Abb. II-2.1-1). Mit einer Klassifikation der zeitpunktbezogenen Tatbestände (Auftrag, Auftragsbestätigung) als Ereignisse, der zeitverbundenen Aktivitäten als Vorgänge (Auftragsannahme, Auftragsverfolgung, Produktion) und der Beschreibung des Umfeldes der Vorgänge als Umweltzustände (Kundendaten, Artikeldaten) ergibt sich eine abstrakte Beschreibungsmöglichkeit für Elemente von Geschäfitsprozes-

Teil II Betriebliche Informationssysteme

283

sen, wie sie in den allgemeinen Bezeichnungen und Symbolen der Abb. II-2.2-2 dargestellt ist.

Abb. II-2.2-1 Ausschnitt aus der Vorgangskette „Auftragsbearbeitung" (nach Scheer [Sce92, S. 9]) Datensichl

Abb. II-2.2-2 Sichten des Vorgangskettenmodells [Sce92, S. 14] In dieser Abbildung ist zugleich eine mögliche Reduktion der Komplexität von Elementen und ihre Beziehungen aus der Sicht der Informationsverarbeitung eingezeichnet. Die Zerlegung der Vorgangsketten in • •

eine Sicht auf die durch Daten dargestellten Elemente (Datensicht), eine Sicht auf die zu realisierenden Funktionen (Funktionssicht) und

284

2 Architektur

•

eine Sicht auf die Träger dieser Funktionen die Organisationseinheiten {Organisationssicht) sowie • eine Sicht auf die für die Informationsverarbeitung notwendigen Ressourcen der Informationstechnik (Ressourcensicht). Der in dieser Darstellung nicht mehr sichtbare güterliche Transformationsprozeß von Werkstoffen ist über seine Widerspiegelung durch Daten (als Änderung des Umweltzustandes eines entsprechenden Vorgangs) in die Datensicht eingeordnet. D.h., Abb. II-2.2-2 stellt die Elemente von Geschäftsprozessen aus der Sicht der Beschreibung der Informationstransformation dar. Werden nun - wie beabsichtigt - zur Reduktion der Komplexität diese Sichten getrennt beschrieben, so ist •

eine vierte Sicht - die Steuerungssicht - zur Koordination der Daten-, Funktions- und Organisationssicht für die einzelnen Geschäftsprozesse mit ihren vielfaltigen Verflechtungen (in struktureller und zeitlicher Hinsicht) notwendig.

Auf diese Weise entsteht die Struktur der ARIS-Architektur, wie sie in Abb. II2.2-3 dargestellt ist.

Abb. II-2.2-3 ARIS-Zerlegungssichten für Vorgangsketten Mit der nicht explizit dargestellten Ressourcensicht aus Abb. II-2.2-2 wird wie folgt verfahren: Ausgehend von der Erfahrung, daß die Implementierung von Daten, Funktionen und organisatorischen Strukturen betrieblicher Vorgänge sowie ihrer Steuerung auf einer konkreten Hardware nicht direkt erfolgt, sondern über verschiedenen

Teil II Betriebliche Informationssysteme

285

Phasen vorbereitet wird, ist es sinnvoll, diese Phasen in geeigneter Weise mit in die obigen Sichten einzubauen und so die Anbindung der Daten, Funktionen und Organisationsstmkturen an die Ressourcen der Informationstechnik zu beschreiben. Scheer benutzt dazu die Phasen: • • •

Erstellung eines Fachkonzepts, Umsetzung des Fachkonzepts in ein DV-Konzept, Technische Implementierung des DV-Konzepts auf einer konkreten Hardware.1

Auf diese Weise entsteht als Modell für die Beschreibung von Informationssystemen - der Ansatz des ARIS-Konzeptes - wie er in Abb. II-2.2-4 widergegeben ist.

Abb. II-2.2-4 ARIS-Architektur Die theoretische Untersetzung des bisher nur intuitiv abgeleiteten ARISKonzeptes durch ein Metamodell (vgl. Abschnitt 2.3) zeigt, daß die Bezeichnung „Architektur" in dem oben beschriebenen Sinn gerechtfertigt ist.

1 Diese Phasendefinition unterstützt die mit der Veränderung der Geschäftsprozesse und der Informationstechnik einhergehende Veränderung des Informationssystems besonders effizient, indem sie die fachliche Abbildung der Geschäftsprozesse von ihrer DV- und informationstechnischen Realisierung trennt und so Veränderungen in den beiden letzten Bereichen unter Beibehaltung des Fachkonzepts möglich macht

286

2 Architektur

Zunächst möchten wir aber den Stand der Beschreibung von Informationssystemen, wie er mit dem ARIS-Modell möglich ist, zusammenfassend darstellen. Die ARIS-Architektur definiert zur ganzheitlichen Beschreibung von Informationssystemen vier Beschreibungssichten und drei Beschreibungsebenen, in denen die einzelnen Bausteine und ihre Beziehungen beschrieben werden. Auf der Ebene des Fachkonzepts werden die durch das Informationssystem zu unterstützenden Geschäftsprozesse des Unternehmens formalisiert dargestellt, und zwar in der Funktionssicht alle Funktionen, die innerhalb der Geschäftsprozesse ausgeführt werden, mit einer hierarchischen Anordnung und Fachbegriffszuordnungen, die die Kommunikation mit den betrieblichen Fachbereichen erleichtern, Datensicht alle auftretenden Daten mit ihren Beziehungen in Form strukturierter Datenmodelle mit entsprechenden erläuternden Informationen,

Organisationssicht alle organisatorischen Einheiten und Mitarbeiter des Unternehmens sowie ihre Beziehungen und Strukturen, Steuerungssicht alle Verbindungen der anderen Sichten. (Diese Verbindungen werden über die Betrachtung der Vorgangsketten bestimmt, vgl. Anfang von Abschnitt 2.2). Beim Übergang in die Ebene des DV-Konzepts erfolgt dann die Übertragimg des Fachkonzepts in eine DV-orientierte Begriffswelt (z. B. Datenobjekte Tabellen, Funktionen -> Module, Prozesse -» Ablaufstrukturen, Organisationskonzepte Netztopologien usw.) Auf der Ebene der Implementierung wird das DV-Konzept auf konkrete Komponenten der Hard- und Software übertragen.

2.3 ARIS-Informationsmodell Mit der Festlegung der ARIS-Architektur ist bisher eine sinnvolle Beschreibung für integrierte Informationssysteme abgeleitet worden. Die Weiterentwicklung dieser Beschreibungsmöglichkeit zu einem formalen Modell, dem ARISInformationsmodell, bildet den Gegenstand der Monografie von Scheer [See 92]. Wir können hier nur das Vorgehen, das Ergebnis und seine Bedeutung grob beschreiben.

Teil II Betriebliche Informationssysteme

287

Ausgehend von den festgelegten Bausteinen der einzelnen Sichten - Funktionen, Datenobjekte, Organisationseinheiten - und ihrer Beziehungen zueinander als Elemente eines Modells wird ein formales Schema der Architektur in der Sprache der konzeptionellen Datenmodellierung (vgl. Abschnitt 3.3) entwickelt. Dieses Schema, d. h. ein abstraktes Modell in dem die Bausteine der Architektur und ihre Beziehungen formal einwandfrei beschrieben sind (Metamodell), bildet einerseits eine formalisierte Darstellung für die ARIS-Architektur und andererseits die konzeptionelle Grundlage für eine Speicherung von konkreten Informationssystemen, die nach dem ARIS-Konzept beschrieben sind, in Datenbanken. Dieses Metamodell {Informationsmodell der ARIS-Architektur) ist auch die Grundlage eines Software-Werkzeuges, des ARIS-Toolsets, das die Beschreibung, Analyse und Entwicklung von integrierten Informationssystemen unterstützt. Mit diesem Werkzeug wurden standardisierte Informationssysteme für die Industrie und andere Wirtschaftszweige abgebildet, die als Referenzmodelle für konkrete Informationssysteme verwendet werden können (vgl. [Sce94]).

3 Software Engineering 3.1 Systemplanung 3.1.1 Vorbemerkungen Während in den beiden ersten Kapiteln von Teil II das betriebliche Informationssystem als Ganzes und hinsichtlich seiner Struktur, Architektur, Gestaltung und Integration betrachtet wurde, steht nun die Entwicklung konkreter Anwendungssysteme - und das sind immer Teilbereiche des betrieblichen Informationssystems - von den ersten Überlegungen bis zur praktischen Einführung im Mittelpunkt der Betrachtung. Das Vorgehen wird wohl inhaltlich durch die Architektur des betrieblichen Informationssystems bestimmt, hier behandeln wir aber die Abiaufschritte und ihre Folge. Die Überlegungen gelten für Neu- und Weiterentwicklung. Kompliziertheit und Komplexität EDV-gestützter Informationssysteme wuchsen mit zunehmender Leistungsfähigkeit der Systeme und wachsenden Anforderungen der Benutzer. Methoden zur Planung und Entwicklung hielten damit zunächst nicht Schritt. Das Vorgehen der "Pioniere" erwies sich als ungeeignet. Engagierte Programmierer versuchten, raffinierte und effiziente Lösungen zu erarbeiten, dies auch unter den durch die Hardware gegebenen Restriktionen, man hat aber zunächst die Entwicklung und Einfuhrung betrieblicher Informationssysteme nicht als interdisziplinäre, umfangreiche und hochkomplexe Projekte erkannt. Fehler, Kosten- und Terminüberschreitungen waren die Regel, Konsequenzen wurden relativ spät gezogen. Auch heute noch werden EDV-Projekte häufig mit erheblichen Kosten- und Terminüberschreitungen und nicht immer im Sinne der ursprünglichen Ziele und

288

3 Software Engineering

Vorstellungen abgeschlossen. Ein überraschend hoher Anteil fertiggestellter Softwareprodukte wird überhaupt nicht oder nur mit erheblichen Änderungen eingesetzt. Dazu kommt, daß der Aufwand fiir nachträgliche Änderungen, Modifikationen und allgemein die Wartung bestehender Programme nicht selten ein Vielfaches dessen der Entwicklung beträgt. Die Kosten der Software haben die der Hardware bei weitem überschritten. Das Wort "Skandal" wurde gebraucht; man sprach und spricht von der "Software-Krise". In Unternehmen, die seit längerer Zeit Software (Individualsoftware) einsetzen, fallen 60 bis 80% der personellen EDV-Kosten für die Wartimg bestehender Programme an. Für neue Entwicklungen stehen demnach nur 20 bis 40% der personellen Kapazität zur Verfugung. Folge davon ist der "Anwendungsstau". Man zitiert in diesem Zusammenhang auch Murphy's Gesetze und Gallaher's Kommentar dazu: Murphy's Laws: 1. Things are more complex than they seem to be. 2. Things take longer than expected. 3. Things cost more than expected. 4. If something can go wrong it will. Gallaher's Corollary: Murphy is an Optimist! Das entsprechende Problembewußtsein fehlte lange Zeit. Die ersten Veröffentlichungen zu diesem Thema waren "How I did it"-Berichte, nicht aber systematische Aufarbeitungen. Inzwischen wurde das Problem erkannt, aufbereitet und bearbeitet. Man spricht heute in diesem Zusammenhang von Software Engineering. Unter Software Engineering (SE) versteht man die systematische und fundierte Anwendung von Methoden, Verfahren, Standards und Werkzeugen zur Planung, Entwicklung, Realisierung und Wartung von Software-Produkten. Durch diese Bezeichnung soll auch zum Ausdruck gebracht werden, daß Software ingenieurmäßig und fiir Dritte transparent und nachvollziehbar, nicht aber gleichsam als "Kunstwerk" zu entwickeln ist. CASE bedeutet Computerunterstützung (Computer Aided) des SE. Man kann zwar auch heute - und wohl auch in der Zukunft - nicht die Fehlerfreiheit von EDV-Programmen gewährleisten, es gibt auch kein allgemein anerkanntes Patentrezept fiir die Systementwicklung, aber eine Vielzahl von Ansätzen, die sich im wesentlichen nahezu decken. Es gilt als erwiesen, daß nicht nur EDV-fachliche Fragen und Gesichtspunkte für Planung und Entwicklung von EDV-gestützten Informationssystemen von Bedeutung sind. In diesem Sinne betrachtet man heute als Voraussetzungen für wirtschaftliche Systemplanung und -entwicklung:

Teil II Betriebliche Informationssysteme

289

a Systemdenken bzw. der systemtheoretische Ansatz und die daraus abzuleitenden Konsequenzen, insbesondere die Strukturierung des Systems auf allen Stufen und in allen Phasen, die Integration der Subsysteme und das Regelkreisprinzip; b die Beachtung von Zielen der Systemgestaltung; c eine Vorgehensweise im Sinne einer Folge deutlich abgegrenzter Einzelschritte (Phasenmodell) und nach straffer Planung; d die Durchführung der eigentlichen fachlichen Arbeit durch interdisziplinäre Gruppen, während eine gesonderte Instanz Punkt c überwacht und allgemein steuert, kontrolliert und entscheidet (Projektorganisation). Die Fachabteilungen, die künftigen Benutzer des Systems, wirken dabei mit; e die Beachtung gewisser personell/organisatorischer Grundsätze; f die Anwendung geeigneter Techniken, Instrumente und Verfahren und die Benutzung geeigneter Werkzeuge zur Unterstützimg von Vorgehen und Methoden ("Tools" wie Generatoren, Testhilfen, maschinellle Unterstützung für Strukturierung, Dokumentation u.a.m.). Gesichtspunkt a wurde innerhalb des vorliegenden Textes (Teil II) in Kapitel 1 behandelt, b, d und e in Kapitel 4, f in Kapitel 3. In diesem Kapitel gehen wir auf c ein. Zur Veranschaulichung benutzen wir durchgehend als Beispiel das Bestellwesen eines Betriebes.

3.1.2 Phasenmodell Bereits in den ersten systematisch-wissenschaftlichen Arbeiten zur Systemanalyse wurde phasenweises Vorgehen als Voraussetzung wirtschaftlicher Systementwicklung bezeichnet. Wohl alle derzeit eingesetzten Vorgehensmodelle beruhen auf Phasenmodellen. Man versteht darunter ein Vorgehen in definierten und abgegrenzten Schritten mit klaren und prüfbaren Zwischenergebnissen und mit einem laufenden Wechsel von fachlicher Arbeit und Entscheidungen; die Schritte werden geplant und kontrolliert. In jeder Phase entsteht ein definiertes Zwischenprodukt als Teil des Endprodukts, am Ende einer jeden Phase wird das Ergebnis diskutiert, und es wird darüber entschieden. Die Dokumentation erfolgt projektbegleitend. Allerdings läuft die EDV-Einsatzplanung nicht in einem einzigen Phasenmodell ab, sondern es befinden sich vielmehr im Regelfalle Teilgebiete in unterschiedlichen Phasen. Dies kann sich auf Projekte insgesamt beziehen (die Materialwirtschaft wird bereits implementiert, während sich die Auftragsverwaltung in der Entwurfsphase befindet), aber auch auf Teilbereiche eines Einsatzgebietes (für die Materialwirtschaft werden bereits die Artikelstammdaten erfaßt, während sich die Verarbeitung von Zu- und Abgängen in der Realisierungsphase befindet). Die Systemplanung nach dem Phasenmodell läuft auch im übrigen nicht voll sequentiell ab, es liegt dabei vielmehr ein iterativer Prozeß vor. Das bedeutet hier,

290

3 Software Engineering

daß mit Rücksprüngen innerhalb von Phasen, aber auch nach früheren Phasen gerechnet werden muß. So kann sich beispielsweise im Zuge des Entwurfs herausstellen, daß das Konzept modifiziert werden muß. Derartige Rücksprünge müssen sich natürlich bei qualitativ guter Arbeit in Grenzen halten, sie sind aber nicht auszuschließen. Unter Berücksichtigung des Software Lebenszyklus (vgl. unten 3.1.3) ergibt sich zwangsläufig ein iteratives Modell. In den folgenden Ausführungen wird nicht der Anspruch erhoben, daß ein neues Modell präsentiert werde. Es handelt sich hier vielmehr um nach dem derzeitigen Stand des Software Engineering gesichertes Wissen, wobei Elemente aus Schrifttum und Praxis eingeflossen sind. Auf Literaturhinweise kann daher weitgehend verzichtet werden. Wir stellen zunächst ein mehr oder weniger "klassisches" Phasenmodell vor, zu dem wir dann kritische Anmerkungen und Hinweise auf neuere Ansätze bringen. Das Vorgehen nach dem Phasenmodell ist grundsätzlich auch auf die Einsatzplanung von Standard-Software anzuwenden. Es ergeben sich Abweichungen im Detail, auf die wir jeweils eingehen werden. Die nachstehende Phasengliederung scheint zunächst dem ARIS-Phasenkonzept (Sce92) nicht zu entsprechen, dies wird jedoch später (s. u. Abschnitt 3.1.5) noch erörtert. Die Phasengliederung trägt auch dem Vorrang der fachlichen Lösung vor dem Instrument EDV Rechnung. In diesem Sinne wird das Projekt durch die fachliche Problemstellung ausgelöst, es folgen die Analyse des IST-Zustandes und die Entwicklung eines fachlichen Konzepts. Erst danach kommt es zum EDVKonzept und zum Systementwurf, zur Realisierung, wozu die Programmierung zählt, und zur Einführung des Systems. Die Phasen werden hier als 1. 2. 3. 4. 5. 6.

Vorschlagsphase Definitionsphase Konzeptphase Entwurfsphase Realisierungsphase Einführungs- oder Implementierungsphase

bezeichnet. Die Arbeitsschritte, die durch die Phasen des Vorgehens dargestellt werden, sind grundsätzlich erforderlich, auf keinen kann verzichtet werden. Einen davon zu unterlassen, kann später zu hohen Kosten fuhren, etwa dann, wenn sich gekaufte Software als ungeeignet erweist. Aber auch hier gelten wirtschaftliche Gesichtspunkte, denn abhängig von Art und Umfang der Aufgabe sind Dauer und Arbeitsumfang der Schritte: Während ein kleines EDV-Projekt in wenigen Wochen abgeschlossen sein kann, kann sich die Durchführung größerer Projekte (EDV-Gesamtkonzept oder Umstellung einer Fertigungssteuerung) über Jahre erstrecken. Sinnvoll ist die Gliederung großer Projekte nach überschaubaren Umstellungseinheiten, was letztlich bedeutet, daß Projekte aus einem Rahmenprojekt, das

291

Teil II Betriebliche Informationssysteme

Koordination und Integration sichert, und einer Zahl kleinerer Projekte bestehen sollten. Aus der Praxis eines Beratungsunternehmens stammen die folgenden Daten zur Verteilung der Projektkosten auf die Phasen:

Prozentanteil Kosten

Phasen Definitionsphase, Konzeptphase und fachlicher Entwurf (Zusammenfassung der organisatorischen Vorarbeiten)

30%

Systementwurf

18%

Modul-/Programmentwurf

14%

Programmierung

14%

Test

24%

EDV-Projekt ohne Einführungskosten

100%

Für die Wartung des erstellten Software-Produktes fällt zusätzlich während der Lebensdauer des Produktes die dreifache Summe an. General Electric veranschlagt den Testaufwand mit 40 bis 50% des Entwicklungsaufwandes. Gute Qualität der in früheren Phasen erbrachten Leistungen tragen zu überproportionaler Einsparung in späteren Phasen und vor allem in der Wartung bei.

3.1.2.1

Vorschlagsphase

(Initialphase)

Die Initialphase kommt i. d. R. ungeplant zustande. Der Vorschlag oder Anstoß zum Projekt kann von der Geschäftsleitung, der Organisation/EDV oder von einer Fachabteilung, also einem Benutzer oder künftigen Benutzer kommen. Er wird gewöhnlich ausgelöst durch Unmutsäußerungen oder die Kenntnis analoger Probleme, die besser gelöst erscheinen, etwa nach Besuchen von Ausstellungen oder anderer Betriebe. Häufig entsteht erst nach und nach das Problembewußtsein, verbunden mit dem Wunsch nach kritischer Überprüfung und letztlich Änderung des unbefriedigenden Zustandes. Der erste eigentliche Schritt des Vorgehens ist die Formulierung der Aufgabenstellung, verbunden mit einer Zielvorstellung. Zu diesem Zeitpunkt werden auch schon gewisse Lösungsansätze erörtert. Vor allem ist zu prüfen, ob das Problem wesentlich oder teilweise, ausschließlich oder begleitend durch organisatorische Maßnahmen zu lösen ist. Ist dies der Fall, so

292

3 Software Engineering

sind die kleineren Maßnahmen nach Plan durchzuführen, zu einem Projekt im eigentlichen Sinne kommt es nicht. In einer Voruntersuchung, d. h. einer kurzen Analyse durch einen externen oder internen Fachmann, ist in diesem Sinne zu klären, ob es überhaupt sinnvoll ist, das Projekt zu starten. Die Voruntersuchung soll Grundlagen für die Systemabgrenzung und die Grobplanung des gesamten Projekts liefern sowie eine erste Aussage zur Wirtschaftlichkeit des Projekts. Das Ergebnis der Vorschlagsphase ist die Grundsatzentscheidung auf der Basis der Voruntersuchung. Damit wird ein Projekt eingerichtet und der Projektleiter benannt, verbunden mit der Auftragserteilung an eine Personengruppe. Gegenstand der weiteren Ausführungen dieses Kapitels ist das Projekt.

3.1.2.2

Definitionsphase

Der IST Zustand des umzugestaltenden Systems ist zu erfassen und zu analysieren (System Requirement Analysis), das System ist präzise abzugrenzen. Man beginnt mit der Analyse der Vorgangsketten (vgl. Abschnitt 3.2), zweckmäßigerweise mit personenbezogenen Aufnahmen des IST-Zustandes durch Interviews und/oder Fragebogenauswertung und/oder Beobachtung, dazu kommen Erfassung der Abläufe, der Struktur des gesamten Verfahrens, der Datensichten, der Datenbestände und des Mengengerüsts. Man spricht auch an dieser Stelle von einer Modellbildung, und meint damit eine geeignete Abbildung des IST-Zustandes. Als zweckmäßiges Vorgehen bei derartigen Modellbildungen gilt: • • • • •

Sammeln von Informationen (ohne Kritik und ohne eigene Vorstellungen hineinzuinterpretieren), Ordnen der Informationen, Darstellung als Modell, Verifikation (IST-Zustand korrekt erfaßt ?), Kritik, Analyse, Verbesserungsvorschläge, Analyse des über den IST-Zustand hinausgehenden Informationsbedarfs.

Aus der IST-Analyse folgen die endgültige Systemabgrenzung, wobei die oben behandelten Fragen der Gliederung von Bedeutung sind, und das Festlegen der Ziele unter Berücksichtigung etwaiger Zielkonkurrenz, möglichst mit Quantifizierung der Ziele. Zur Systemabgrenzung gehören auch Aussagen darüber, was nicht Gegenstand des Projektes ist. Neben besonderen fachlichen Zielen (vgl.. Abschnitte 4.2.2 und 4.2.3) sind auch allgemeine Ziele für das Projekt zu formulieren. Das folgende Beispiel zeigt eine Formulierung derartiger allgemeiner Ziele aus der Praxis: • •

Die Flexibilität des Betriebes soll auch bei Einsatz der EDV erhalten bleiben. Es soll keine größere personelle EDV-Kapazität aufgebaut werden.

293

Teil II Betriebliche Informationssysteme • • •

Es soll in kleinen Schritten und immer unter dem Gesichtspunkt der Wirtschaftlichkeit vorgegangen werden. Einfache, klare Lösungen haben Vorrang vor raffinierten Konstruktionen. Die letztlich betroffenen Mitarbeiter sollen bei der Gestaltung mitwirken.

Nach der Definitionsphase müssen Thema und Zielsetzungen fixiert sein.

3.1.2.3

Konzeptphase

Ziel und Ergebnis dieser Phase ist die Entscheidung auf der Grundlage einer Beschreibung des Konzepts des geplanten Systems. Das Konzept ist Vorgabe für die weiteren Schritte. Das Konzept resultiert aus der IST-Analyse unter Einbeziehung von Zielen und "Idealvorstellungen". Man arbeitet heute mit Referenzmodellen, die allgemeingültige, bewährte und allgemein anerkannte Lösungen (allgemeingültiger) Probleme darstellen. Die Abbildungen II-1.3-1 bis II-1.3-4 mit weiterer Verfeinerung können als Teil eines Referenzmodells betrachtet werden. Zu erarbeiten ist erst das fachliche Konzept, das durch sehr generelle Berücksichtigung der wirtschaftlichen Möglichkeiten der EDV (hier insbesondere Speicherung von Datenbeständen, Zugriff darauf, automatische Verarbeitung gespeicherter Daten) und nach der Durchführbarkeitsstudie (Feasibility Study) zu einem EDV- Gobkonzept wird. Das SOLL-Grobkonzept (Preliminary Design) beruht auf der IST-Analyse und auf Idealvorstellung hinsichtlich der (optimalen) Lösung. Man spricht hier auch häufig von einem "Pflichtenheft". Ein Konzept ist auch dann sinnvoll, wenn der Einsatz von Standard-Software beabsichtigt ist. Aus dem Konzept resultieren die Anforderungen an die StandardSoftware. Die Schritte bis einschließlich der Konzeptphase sind somit weitgehend unabhängig von der Art der späteren Realisierung. Standard-Software stellt hier eine zu untersuchende Alternative dar. Das fachliche Konzept besteht nach dem "klassischen" Ansatz vor allem aus schematischen Darstellungen mit kurzen verbalen Erläuterungen, und zwar aus • • •

dem Funktionsmodell (Datenflußdiagramme gramme), dem Datenmodell (ERD) und dem Prozeßmodell (Ablauf- oder Prozeßketten)

und

Dekompositionsdia-

des zu realisierenden Informationssystems. Funktions- und Datenmodellierung haben mehr analytischen Charakter, während die Prozeßmodellierung der Synthese dient. Werden Modelle, z. B. Funktions- oder Datenmodelle, in einer Datenbank für das Informationsmodell abgelegt, um so die Möglichkeit für weitgehend automatisierte Gewinnung (Generierung) letztlich von Programmen und der Datenbank

294

3 Software Engineering

für die Anwendung zu schaffen, so bezeichnet man die erstgenannte Datenbank als "Repository". Das Konzept wird in den folgenden Phasen verfeinert. Aus dem Funktionsmodell resultieren letztlich die lauflahigen Programme, aus dem Datenmodell die Datenbank und aus dem Prozeßmodell die Einbindung des Informationssystems in die betriebliche Organisation. Das Konzept muß auch für Nicht-Informatiker verständlich sein, was in vielen Fällen durch Prototypen des künftigen Systems zu unterstützen ist (vgl. Abschnitt 3.1.4). Eine Alternative zum "klassischen" bildet der objektorientierte Ansatz. In der Durchführbarkeitsstudie sind erforderliche Hardware, Software, "Manpower" zu ermitteln. Soweit möglich, sollte auch das Konzept verifiziert werden, d. h. es sollte der Nachweis der Durchführbarkeit erbracht werden, etwa durch Tests, anhand von Demonstrationen oder durch Simulationen. Erarbeitung und Bewertung von Alternativen der Durchführbarkeitsstudie sollten verlangt werden, damit die Arbeit nicht zu früh in eine bestimmte Richtimg gelenkt und der Entscheidungsspielraum zu sehr eingeschränkt wird. Alternativen sollten sich auf den gesamten Lösungsweg, nicht nur auf einzelne Funktionen beziehen. Das Konzept ist dahingehend zu prüfen, ob es den gesetzten Zielen entspricht. Die Integration in das Gesamtsystem und eventuelle Schnittstellen sind zu beachten. Schließlich muß das neue System gerechtfertigt werden, dies i. d. R. durch den Wirtschaftlichkeitsnachweis. Die Wirtschaftlichkeit ist nachzuweisen mittels Verfahren der Investitionsrechnung, insbesondere der Berechnung der Rentabilität des investierten Kapitals (Return Of Investment, ROI). Die Entscheidungsgrundlagen zur Systemauswahl sollten durchwegs auch die Wirtschaftlichkeit des neuen Systems nachweisen. Dazu ist ein Realisierungsplan vorzulegen. Am Ende dieser Phase müssen somit die grundsätzlichen Fragen geklärt sein, die schwerwiegendste Entscheidung, nämlich die Auswahlentscheidung für Hardware und System- und Anwendersoftware, ist als letzter Schritt dieser Phase zu treffen. Das Ergebnis dieser Phase wird von Geschäftsführung und Projektleitung abgenommen. Bei negativer Entscheidung kommt es zum Abbruch des Projekts. Wenn von vornherein Prioritäten zugunsten von Standard-Software gesetzt sind, ist ein Einfluß der Standard-Software auf das Konzept nicht auszuschließen, was auch nicht unbedingt unerwünscht sein muß. Die nachfolgende Entwurfsphase stellt die Weiterentwicklung des Konzepts dar und baut darauf auf. Dabei können sich grundsätzlich Fragen der Abgrenzung ergeben, weil eine Verfeinerung des Konzepts sich mit einem frühen Entwurfsschritt decken kann. Die grundsätzliche Abgrenzung ist dadurch gegeben, daß

Teil II Betriebliche Informationssysteme

295

das Konzept soweit zu verfeinern ist, wie dies für eine fundierte SystemauswahlEntscheidung erforderlich ist. 3.1.2.4 Entwurfsphase Auch in der Entwurfsphase (Detailed Design) sind jeweils zuerst die fachlichen, danach die EDV-Probleme zu lösen. Man kann die Entwurfsphase weiter aufgliedern nach der Erarbeitung des fachlichen (a) und des Systementwurfs (b), wobei (a) Voraussetzung für (b) ist, und organisatorisch/planerischen Maßnahmen (c). (a) und (b) entfallen weitgehend bei Einsatz von Standard-Software, nicht aber die organisatorisch/planerischen Maßnahmen. a) Fachlicher Entwurf Der fachliche Entwurf ist eine Verfeinerung der Konzept-Alternative, zu deren Gunsten die Entscheidung getroffen wurde. Man bezeichnet ihn häufig als "Fachinhaltsbeschreibung" oder Spezifikation, wobei eine Spezifikation grundsätzlich das Ergebnis einer Phase ist, das für die nächste zur Vorgabe wird. Bei einer Abweichung zwischen den Anforderungen des Betriebes und der Realisierung in der ausgewählten Standard-Software ist zu entscheiden, ob die Software modifiziert wird oder ob der Betrieb sich organisatorisch anpaßt. Der fachliche Entwurf umfaßt die Darstellung der zu realisierenden Funktionen bis ins Detail mit Bildschirmmasken und Listebildern und die verfeinerte "logische" Datenorganisation, sowie die Verknüpfung von Funktionen und Daten (Welche Daten werden in welchen Funktionen benötigt?). b) Systementwurf Der Systementwurf ist i. d. R. nur bei Neuentwicklung erforderlich. Der Systementwurf wird aus dem fachlichen Entwurf abgeleitet und enthält die Gliederung des Systems nach Programmen bzw. Modulen (Systementwurf im engeren Sinne) und die Struktur der Programme/Module (Modulentwurf). Dazu kommt die physische Datenorganisation. Integration und Schnittstellen sind hier im besonderen zu berücksichtigen. c) Organisatorisch/planerische

Maßnahmen

Dazu zählen Maßnahmen zu Datenschutz und Datensicherung, Klärung von Berechtigungen, die Regelung der Ablauforganisation einschließlich vor- und nachgelagerter Arbeiten und die Verfeinerung des Realisierungsplanes für die weiteren Phasen. Häufig sind Benummerungssysteme neu aufzubauen oder umzugestalten. Der Aufwand dafür wird fast immer unterschätzt. Zum Ende der Entwurfphase muß volle Klarheit hinsichtlich der neuen Abläufe bestehen. Die dokumentierten Lösungen werden von Fachleuten abgenommen,

296

3 Software Engineering

insbesondere von den künftigen Benutzern des Systems. Der Entwurf ist sehr gut durch Walk Throughs zu verifizieren.

3.1.2.5

Realisierunesphase

In dieser Phase erfolgen Programmierung bzw. Anpassung von StandardSoftware, Programm- und Systemtest, Schulung/Einweisung der Mitarbeiter, Stammdatenübernahme, Probeläufe. Erweist sich die Anpassung von Standard-Software als erforderlich, so versucht man zunächst, durch Setzen der entsprechenden Parameter aus den in der Standard-Software enthaltenen Funktionen die den Anforderungen entsprechenden zu realisieren. Ist dies nicht möglich, sind die Programme selbst zu modifizieren. Anpassung durch Setzen von Parametern (Tabellen) erlaubt die Anpassung hochkomplexer und mächtiger Software an die Gegebenheiten beim Kunden. Dies ist zu einem Konstruktionsprinzip moderner, leistungsfähiger StandardSoftware geworden. Diese Anpassung wird beim Branchenführer SAP als "Customizing" bezeichnet. Die Modifikation von Programmen ist nicht nur an sich schwierig; besonders problematisch ist die Übernahme der Modifikation, wenn eine neue Version des Standards (ein neues Release) ausgeliefert wird. Auch der Aufwand für Tests wird gewöhnlich unterschätzt (vgl. dazu die Angaben oben im Abschnitt 3.1.2). Tests werden oft fälschlicherweise nicht als wichtiger zu planender Schritt, sondern als Nebensache betrachtet. In der Realisierungsphase müssen Konzept und Entwurf längst verifiziert sein; zu testen sind hier zunächst die Programme für sich (Programmtest, Unit Testing) und danach in ihrem Zusammenwirken (Systemtest, Integration Testing) einschließlich vor- und nachgelagerter Arbeiten. Die ersten Tests erfolgen generell durch den, der die Arbeit gemacht hat, nach und nach erweitert sich der Kreis der Tester über die Mitglieder des Projekteams und die Kontaktpersonen (vgl. unten Abschnitt 3.1.7) bis zu den Fachabteilungen. Tests sind zu planen. Neben der Testanordnung und den Testdaten sind auch die gewünschten Ergebnisse zu planen und zu dokumentieren. Zum Teil müssen auch alte Programmversionen aufbewahrt werden. Festgestellte Fehler müssen lokalisiert und dann beseitigt werden. Zur Lokalisierung von Fehlern stehen heute gewöhnlich leistungsfähige Testhilfen zur Verfügung, insbesondere DEBUG- und TRACE-Funktionen, aber auch interpretierende Programmausführung mit Eingriffsmöglichkeiten wie Zurücksetzen, Ändern von Variableninhalten u.a.m. Zur Erstellung von Testdaten werden Testdatengeneratoren eingesetzt.

Teil II Betriebliche Informationssysteme

297

Konkrete Ergebnisse der Realisierungsphase sind Programmabnahmen durch die Fachabteilungen und Vollzugsmeldungen über erfolgte Einweisungen, Stammdatenübernahme usw. 3.1.2.6

Implementierunssphase

Unter Implementierung versteht man die volle Einführung des Systems. Für die Einführung/Umstellung sind präzise Detailpläne erforderlich. Die wichtigsten Aufgaben dieser Phase sind Übernahme der Bestandsdaten und die Einführung/Umstellung. In dieser Phase ist besonders deutlich zu erkennen, wie die auf abstraktanalytischem Wege zustandegekommenen Programme/Module und die Datenbank durch die Prozeßgestaltung sinnvoll zusammengeführt und in das Organisationssystem eingebunden werden. Auf spezielle, dabei auftretende Probleme gehen wir in den folgenden Abschnitten ein. 3.1.2.7

1) • • •

Zusammenfassung

Vorschlagsphase Formulierung der Aufgabenstellung mit Zielvorstellung, Voruntersuchung, Grundsatzentscheidung

2) Definitionsphase • Ist-Analyse (Sammeln, Ordnen und Darstellen von Informationen zum ISTZustand), • Systemabgrenzung, • Festlegen der Ziele unter Berücksichtigung etwaiger Zielkonkurrenz, möglichst Quantifizierung 3) • • • • • • • •

Konzeptphase Erarbeitimg erst des fachlichen, dann des EDV-Konzepts (Grobkonzept), Prüfung auf Integration und Zielkonformität, Erarbeitimg und Bewertung von Alternativen, Durchfiihrbarkeitsstudie (erforderliche Hardware, Software, "Manpower" usw), Wirtschaftlichkeitsnachweis, Verifikation (Simulation, Demonstration), Auswahlentscheidung für Hardware und System- und Anwendundssoftware, Realisierungsplan

4) • • • •

Entwurfsphase Detailentwurf mit Spezifikation (Fachinhaltsbeschreibung, Pflichtenheft), Ablauforganisation einschließlich vor- und nachgelagerter Arbeiten, Benummerung, Datenorganisation, Datenschutz und Datensicherung,

298

3 Software Engineering

• •

Programmorganisatiom, Programmiervorgaben, Verfeinerung des Realisierungsplanes für die weiteren Phasen

5) • • • • •

Realisierungsphase Programmierung bzw. Anpassung von Standardsoftware, Programm- und Systemtest, Schulung / Einweisung der Mitarbeiter, Stammdatenübernahme, Probeläufe

6) • • •

Implementierungsphase Übernahme der Bestandsdaten, Einführung des Systems, Umstellung, Prüfung und Verbesserung des Betriebsverhaltens.

3.1.3 Software Lebenszyklus Der Software Lebenszyklus (Life Cycle) umfaßt Planung (Definition), Entwicklung (Development) und Wartung (Maintainance) des Software-Produkts. Er stellt eine umfassendere Betrachtung dar als das Phasenmodell, das die Wartung nicht oder nur am Rande berücksichtigt, und somit dessen Erweiterung. Wartung umfaßt • Stabilisierung (Beseitigung von Fehlern, Verbesserung der Zuverlässigkeit usw.), • Optimierung (Verbesserung von Effizienz und Funktionen) und • Anpassung an neue Erfordernisse. Ihr unterliegen nicht nur Programmme, sondern auch Konzept und Entwurf. Der Tatbestand, daß die Wartung von Software-Produkten im Gegensatz zur Entwicklung oft stiefmütterlich behandelt wird, darf als bekannt gelten. Die Lebenszyklus-Betrachtung trägt auch dem bereits skizzierten Umstände Rechnung, daß 60 bis 80% der personellen Kapazität und der Software-Kosten für die Wartung bestehender Software-Produkte anfallen. Sie berücksichtigt auch die Tatsache, daß Wartung bestehender Produkte und Projekte zur Entwicklung neuer Produkte nicht immer ohne weiteres abgrenzbar sind. Innerhalb des Software Lebenszyklus wird das Phasenmodell mehrfach durchlaufen, zunächst vollständig im Zuge der Entwicklung, danach mehrfach und mehr oder weniger unvollständig im Zuge der Wartung. Setzt man zum Ende des Phasenmodells (nach der Implementierung) die Frage, ob das ursprünglich gesetzte Ziel erreicht wurde bzw. ob noch Fragen offen sind, so wird man im Regelfalle früher oder später, in manchen Fällen sogar vor der vollen Einfuhrung, ein neues Projekt initiieren oder im Sinne des Software Lebenszyklus in die erste Phase zurückspringen, was letztlich eine Frage der Betrachtungsweise ist.

299

Teil II Betriebliche Informationssysteme

Geeignet erscheint daher der Ansatz, die Software-Entwicklung als Schleife zu definieren, die mehrfach durchlaufen wird, in der aber jede Phase und auch einzelne Schritte innerhalb der Phase übergangen werden können. Nach der Implementierung erfolgt der Rücksprung zum Beginn. Die Schleife wird erst mit dem Ende des Einsatzes des Software-Produktes verlassen (Abb.II-3.1-1). Projektanfang wiederhole bis Ende des Lebenszyklus Nein Nein

Nein

Nein Nein

Nein

^Handlungsbedarf d. Phase? 1 Aktivitäten der Vorsehl aesphase ^Handlungsbedarfd. Phase? _ 1 Aktivitäten der Definitionsphase ^Handlungsbedarfd. Phase? Aktivitäten der Konzeptphase ^Handlungsbedarf d. Phase? . Aktivitäten der Entwurfsphase ^Handlungsbedarf d. Phase? _ 1 Aktivitäten der Realisierunesphase ^Handlungsbedarfd. Phase?

Ja

Ja

Ja

Ja Ja

Ja

Aktivitäten der Implementierungsphase Ende des Einsatzes des Software-Produkts Abb. II-3.1-1: Struktogrammm Software-Lebenszyklus

3.1.4 Prototyping Prototyping wird oft als Antithese zum klassischen Phasenmodell betrachtet, was aber zumindest nicht voll zutrifft. Sinnvoll ist die Synthese dieser Ansätze, d.h. die Einbindung des Prototyping in das Phasenmodell für die Entwicklung individueller Software. Auch bei konventionellem Vorgehen versucht man, den künftigen Benutzer des Software-Produkts in die Systementwicklung einzubeziehen. Insbesondere soll er bei der Erarbeitung des fachlichen Entwurfs federführend sein. Mit Vorliegen des Entwurfs soll das System abstrakt und schematisch, wie es der Aufgabenstellung entspricht, so weitgehend und exakt beschrieben sein, daß es durch Programmierer unmittelbar in lauffahige Programme umgesetzt werden kann. In der Realität bestehen aber häufig erhebliche Kommunikationsschwierigkeiten zwischen den künftigen Anwendern und den Informatikern: Der künftige Anwender ist nicht in der Lage - oder nicht bereit -, das abstrakt/sehematisch dar-

300

3 Software Engineering

gestellte Modell des Software-Produkts zu verstehen oder bei der Erarbeitung desselben wesentlich mitzuwirken, was Voraussetzung für den Erfolg des Vorgehens nach dem Phasenmodell wäre. Grundlage der Programmierung bilden somit nicht korrekte Vorgaben. Erst zu einem späten Zeitpunkt - etwa beim Testen der Programme - erkennt der künftige Anwender unter Umständen, daß die Lösung wenig nützlich ist bzw. daß es sich nicht um die Lösung des eigentlichen Anwendelproblems handelt, was zu aufwendigen Änderungen oder zu einer weitgehenden Wiederholung vorhergegangener Schritte führt. Nach der "Philosophie" des Prototyping versucht man, dem Anwender zu einem möglichst frühen Zeitpunkt nicht nur ein abstraktes, sondern ein anschauliches Modell (Prototyp) des künftigen Systems zu zeigen. Ein Prototyp wird in der Konzept-, häufiger in der Entwurfsphase angeboten. Neben der Veranschaulichung des im übrigen abstrakten Konzepts benutzt man das Prototyping bewußt zur Ermittlung der konkreten und präzisen Anforderungen des Anwenders. Bei Einsatz von Standard-Software liegt gewissermaßen von Anfang an ein besonders leistungsfähiger "Prototyp" vor, nämlich das fertige Produkt. Der Prototyp zeigt Benutzeroberfläche und allgemeine Handhabung, ihm liegen im wesentlichen die Datenstukturen des Konzepts zugrunde, es sind aber i. d. R. nicht alle Funktionen realisiert. Er wird auf einem Computer vorgeführt und soll dem künftigen Anwender das System verdeutlichen. Effizienz, Sicherheit und Zuverlässigkeit werden vernachlässigt, nicht realisierte Funktionen ersetzt man durch "Dummies". Von "Rapid Prototyping" spricht man dann, wenn der Prototyp rasch entwickelt wurde, nach Genehmigung durch den künftigen Anwender nicht mehr weiterentwickelt wird und somit im wesentlichen eine anschauliche Ergänzung des Entwurfs bildet. Dieser Prototyp wird gewöhnlich in einer anderen Systemwelt, insbesondere auf PC's realisiert. Danach beginnt die Entwicklung des "echten" Systems, wofür nun gute Voraussetzungen bestehen. Für derartige Prototypen können integrierte Produkte oder PC-Datenbanken eingesetzt werden (beispielsweise dBase). Arbeitet man mit einfachen Maskengeneratoren in der Zielwelt des Systems (etwa auf einem Unix- oder einem Großrechner), so kann man rasch Prototypen bauen, die inhaltlich weniger aussagen, die man aber bis zum fertigen Produkt weiterentwickeln kann (evolutionäres Prototyping). Höhere Produktivität bei der Entwicklung bringen erweiterte Generatoren, durch die auch Datendefinitionen und Algorithmen in des "echte" System übernommen werden können. Leistungsfähige Datenbanksysteme (beispielsweise Oracle oder Informix) oder Programmiersprachen der vierten Generation in Verbindung mit Datenbanken (beispielsweise Natural und Adabas) fuhren zu einer weiteren Produktivitätssteigerung.

Teil II Betriebliche Informationssysteme

301

3.1.5 Ein modifiziertes Vorgehensmodell Die Aussagen zum Phasenmodell oben in Abschnitt 3.1.2 sind wohl grundsätzlich zutreffend, sie entsprechen aber nicht immer voll der Realität. Probleme liegen vor allem in der Mitwirkung des Anwenders bei Konzept/Entwurf und in der Philosophie des phasenmäßigen Vorgehens im Sinne eines Wasserfallmodells, das nach Abschluß des Projekts zu einem beständigem und "stillen" Wasser, nämlich geeigneten und korrekten Programmen fuhrt, die längere Zeit unverändert eingestetzt werden. Lösungsansätze wurden bereits in Form des Life Cycle/-Ansatzes und des Prototyping diskutiert. Es erweist sich in der Praxis auch als sinnvoll und zweckmäßig, erste Schritte der Realisierung bereits mit der Konzeptphase in Angriff zu nehmen. Besonders interessant ist das Rapid Application Development (RAD): Im Sinne des RAD bekommt der Anwender zu einem frühen Zeitpunkt ein noch nicht fertiges, aber für ihn bereits nützliches Produkt gewöhnlich für Teilbereiche, das laufend nach seinen erst dann präzisierten Wünschen verbessert wird. Der Anwender arbeitet schon mit den ersten Teilsystemen produktiv. Ein Entwicklungszyklus im Sinne von RAD dauert maximal sechs Monate, Verbesserung (Maintainance) und Weiterentwicklung (neuer Teilprojekte) erfolgen in weiteren Zyklen. Man plant gewissermaßen die Wartung von vornherein ein. Bei ansonsten üblichen Zyklen von einem bis zwei Jahren paßt häufig ein entwickeltes SW-Produkt nicht mehr zum Realsystem bzw. das SW-Produkt entspricht nicht den Anforderungen. RAD setzt die entsprechenden Werkzeuge (Tools) voraus. Wir reduzieren - einem heute vielfach praktiziertem Vorgehen entsprechend und auch in Anlehnung an die ARIS-Architektur (Sce92) und an häufig eingesetzten CASE-Werkzeuge, insbesondere das Produkt IEW/ADW von Knowledgeware die Elemente des Vorgehensmodells auf die Phasen I Analyse (Analysis), II Entwicklung (Design), III Realisierung (Construction) und IV Implementierung. Als Phase Null ist eine Planungsphase (Planning) als Gegenstand des Informationsmanagements zu ergänzen, die wir aber nicht hier, sonden unten in Abschnitt 4 betrachten. In tabellarischer Form stellen wir nun das auf Phasen mit ganz konkreten Ergebnissen reduzierte und komprimierte Phasenmodell gemäß Abb. II-3.1-1 dar. Unter Objekten wird dabei das der Betrachtung unterzogene System verstanden. Das reale System, für das das Software-System zu entwickeln ist, bildet Ausgangs- und Zielpunkt des Vorgehens. Die Aktivitäten der Phase I sind mehr intuitiv und semantisch strukturiert, die der Phasen II und III mehr formal und

302

3 Software Engineering

abstrakt mit der Gefahr der Entfernung vom Realsystem. Man strebt Minderung der Abstraktion durch geeignete Methoden, insbesondere durch Prototyping an.

SE-Phasen

Aktivitäten

Objekte

Phasen ergenissse

Realsystem I Analyse

II Entwicklung (Design)

III Konstruktion

IV Implementierung

Requirement Analysis, Preliminary Design, IST-Analyse und fachliche Entwicklung und Gestaltung

Modell I des Informationssystems

Funktions-, Datenund Prozeßmodell, Feasibility Study,

Detailed Design, Feinkonzept

(Konzept)

Wirtschaftlichkeit, Systementscheidung

systemtechnische Entwicklung

Modell II des Informationssystems

physische Datenorga-nisation, Modulgliederung und -struktur,

Realisierung, Aufbau der Datenbank, Programmierung,

(Entwurf)

Data Base, Software Base

Test

Modell III

lauffahige und getestete Programme

Rückführung des entwickelten Software-

(Software-Produkt)

Datenbank

Produkts in das Realsystem

Realsystem

Abb. II-3.1-2: SE-Phasen (reduziert) Die Darstellung bringt deutlich zum Ausdruck, daß Systemplanung eine Folge von Modellierungsschritten ist. Neben dem realen System spielen abstrakte Systeme (die Modelle I, II und III) eine große Rolle. Dies ist zwingend erforderlich, muß jedoch als Gefahr für den Praxis- und Realitätsbezug gesehen werden. Ausgehend vom Realsystem wird aufgrund der Analyse (Phase I) das Modell I des Informationssystems entwickelt. Modell I bildet die Eingangsgröße der zweiten Phase (Entwicklung), woraus Modell II resultiert, das wiederum Eingangsgröße für Phase III ist usw. Die Phasen bzw. ihre Ergebnisse Modell I (Konzept), Modell II (Entwurf) und Modell III (Software-Produkt) entsprechen weitgehend dem Fachkonzept, dem DV-Konzept und der Implementierung nach dem ARIS-Konzept (Sce92). Jedes der Modelle ist innerlich strukturiert gemäß Abb. II-2.2-4. Abbildung II-3.1-3 bringt diese Gedanken in realitätsgerechter zyklischer Darstellung zum Ausdruck. Von Seiten der Umwelt, des Marktes und der Unternehmensplanung, aber auch von der Entwicklung der modernen Informationstechno-

Teil II Betriebliche Informationssysteme

303

logie, geht ein dauernder Wandel aus, der zu Maßnahmen der Systemplanung zwingt. Die zyklische Anordnung der Phasen und Phasenergebnisse (Modelle) zeigt deutlich - und auch dies der Realität entsprechend daß man sich in den Phasen I und II vom Realsystem entfernt und daher in den Phasen III und IV gezwungen ist, sich (mühsam) wieder dem Realsystem zu nähern, um schließlich dort einzumünden. Wegen der Dynamik der Umwelt, des Marktes, der Unternehmensplanung und der modernen Informationstechnologie, aber auch wegen der Notwendigkeit einer raschen Rückkoppelung zum Realsystem müssen die Zyklen kurz sein, nach Möglichkleit im Umfange von drei bis sechs Monaten. Fachliches Konzept/ Entscheidung

I

Umwelt-

/

anforderungen

Reales

Informations-

System

system

EDV-Weit

Ergebnisse Aktivitäten

Abb. II-3.1-3: Zyklisches Modell der SE-Phasen

3.1.6 Projektorganisation EDV-Projekte dürfen hinsichtlich ihres Umfanges und ihrer Bedeutung für das Unternehmen nicht unterschätzt werden. Planung und Realisierung des EDVEinsatzes verursachen erhebliche und zum Teil nicht ohne weiteres sichtbare Kosten, binden in erheblichem Maße Kräfte, vor allem aber wird der Betrieb selbst durch das eingesetzte EDV-System erheblich verändert. Ein gut funktionierendes EDV-System kann einem Betrieb positive Impulse verleihen, ein schlecht geplantes System kann Aktivitäten behindern, ja sogar blockieren. Sorgfältige Planung unter Mitwirkung der Geschäftsführung erscheint daher geboten, was aber natürlich nicht dazu führen darf, daß das Projekt in der Phase der

304

3 Software Engineering

Planung steckenbleibt und nicht zur Realisierung kommt. Man wird zu einem bestimmten Zeitpunkt zu akzeptieren haben, daß man weder die künftge Entwicklung des Betriebes (mit EDV) noch die des EDV-Marktes voll übersieht, und trotzdem das Projekt weiter vorantreiben. Eine Projektgruppe wird am Ende der Vorschlagsphase - bei grundsätzlicher Entscheidung für das Projekt - eingerichtet. In der Projektgruppe (Team) müssen die folgenden Funktionen wahrgenommen werden, wobei nicht immer eine Funktion einer "full-time"- Position entspricht: • • • • • • • • •

Projektleiter-1, Projektleiter-2, Organisator, Datenbankadministrator, Systemanalytiker, Programmierer, Operator. Projektsekretär und Kontaktpersonen der Fachabteilungen.

Projektleiter-1 ist der Manager mit Verantwortlichkeit und Kompetenz hinsichtlich Personaleinsatz, Kosten, Zeit. Projektleiter-2 ist der fachliche Leiter des Projekts, es kann sich dabei um einen externen Fachmann handeln. Im übrigen sind die Funktionen der folgenden Tabelle zu entnehmen. Die Kontaktperson der Fachabteilung bildet die Brücke zwischen den Informatikern und der Fachabteilung, der sie angehört. Funktionen der Systemplanung werden heute zunehmend in die Fachabteilungen verlagert. Zu beachten sind aber Größe und Art des Projekts. So kann in kleineren Projekten der fachliche Leiter zugleich Organisator und Systemanalytiker sein (dies vielleicht in mehreren Projekten), ebenso können die Funktionen des Systemanalytikers und die des Programmierers durch eine Person wahrgenomen werden u.a.m. Anderseits sind in großen Projekten beispielsweise mehrere Programmierer tätig. Aufgabe des Datenbankadministrators ist die funktionsübergreifende Definition der Daten innerhalb der Datenbank, d.h. die Umsetzung der konzeptionellen Datenorganisation in die "physische" mittels der Datenbank. Der Projektleitung obliegen Zeit- und Kostenplanung und -Überwachung. Den geplanten Einzelaufgaben ist der jeweilige Bedarf an personeller und Anlagenkapazität zuzuweisen, dies quantitativ und qualitativ. Darauf aufbauend, muß das Projekt mittels geeigneter Techniken (Netzpläne oder Balkendiagramme, wobei die letzteren in den meisten Fällen ausreichen) gesteuert werden. Bei der Zeitplanung ist auf gut meß- und prüfbare Kontrollpunkte (Meilensteine) zu achten. Aussagen wie die, eine Aufgabe sei zu 80 % erledigt, sind hier wertlos. Zum Gesamtplan kommen Pläne fiir umfangreichere Teilaufgaben.

305

Teil II Betriebliche Informationssysteme

Die Zuordnung der Funktionen innerhalb des EDV-Projekts an Stellen ergibt sich aus der Tabelle Abb. II-3.1-4. Bei der Organisationsform des Chief Programmer Team sind Team und Aufgaben auf den Chief Programmer ausgerichtet, der ein erfahrener und qualifizierter Software-Spezialist ist und nicht nur Führungsaufgaben wahrnimmt, sondern auch fachlich anspruchsvolle Aufgaben löst (Realisierung schwieriger Aufgaben).

Mitwirkende: Geschäftsführung Projektleiter-1 Projektleiter-2 Organisator Systemanalytiker Datenbankadmini strator Programmierer Kontaktperson der Fachabteilung Fachabteilung Funktionen: Entscheidung zur Projekteinrichtung Gesamtplanung und -Überwachung Phase I: Voruntersuchung Grundsatzentscheidung IST-Analvse Entwicklung fachliches Konzept Entwicklung EDV-Konzept Rechtfertigung Realisierungsplan Svstemauswahl Phase II: Entwicklung fachlicher Entwurf Entwicklung Systementwurf Entwicklung physische Datenorganisation Phase m : Gestaltung Ablauforganisation Programmierung Test Phase IV: Schulung/Einweisung Datenübemahme Probelauf Organisation der Umstellung Umstellung/Einführung Abb. II-3.1-4: Zuordnung Funktionen / Stellen

X X

X X X

X

X

X X

X

X

X X

X X

X

X X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

306

3 Software Engineering

Für größere Projekte erweist sich die Einrichtung eines Projektbeirats, dem Projektleiter-1 und Projektleiter-2 berichten, als zweckmäßig. Abbildung II-3.1-5 zeigt Gesichtspunkte des zyklischen Modells gemäß Abb. II3.1-4 und wichtige Mitwirkende in schematischer Darstellung. Dabei wird zwischen dem Organisation- und dem Informationssystem und den jeweils entsprechenden Modellen unterschieden: Das Informationssystem ist das Subsystem, das durch "Architekten", die in der Literatur [Gil91] auch als "Infotekten" bezeichnet werden, in das Organisationssystem einzugliedern ist. Hier kommt wieder der Vorrang der betriebswirtschaftlich-fachlichen Seite gegenüber dem Instrument Informationstechnologie zum Ausdruck.

Abb. II-3.1-5: Modellierung des Informationssystems

3.1.7 Personell/organisatorische Fragen Betroffene Mitarbeiter stehen häufig aus persönlich plausiblen Gründen neuen Systemen ablehnend gegenüber; geringe Akzeptanz kann zum Scheitern führen. Mitarbeiter, die durch neue Systeme den alten Arbeitsplatz, Mitarbeiter, Arbeitsmonopole (z.B. Informationen zu einem Thema nur über ihre Unterlagen) und

Teil II Betriebliche Informationssysteme

307

damit Ansehen verlieren, werden auch einer sachlich guten Lösug negativ gegenüberstehen. Arbeitsbedingungen ändern sich oft so grundlegend, daß nur ein intensiver Umlemprozeß die Umstellung ermöglicht; vor allem ältere Mitarbeiter fürchten, dem nicht mehr gewachsen zu sein. Zwischen den Spezialisten, die das System gestalten, und den Mitarbeitern, die mit dem ihnen aufgezwungenen System leben müssen, bestehen auch aus diesem Grunde Konflikte. Nicht nur wegen abzusehender Mehrarbeit während der Einfiihrungs- und Umstellungsphase, wegen zu erwartender Fehler, die erst nach der Umstellung entdeckt und beseitigt werden und der damit verbundenen Unruhe, auch wegen irrationaler Ablehnung eines in allen Konsequenzen nicht zu überblickenden Systems stehen Menschen dem neuen skeptisch gegenüber. Die Technik der Organisations-Entwicklung ist hier nur in Grenzen einsetzbar, weil den Betroffenen gewöhnlich das Fachwissen fehlt, ihr System selbst zu gestalten. Zur Verbesserung der Akzeptanz können die folgenden Maßnahmen beitragen: • • • • • • • •

Verständliche Darstellung des Projekts, seiner Zielsetzung und seiner Bedeutung für das Unternehmen, Darstellung des Nutzens für die Mitarbeiter, Hervorheben des Projekts als Gemeinschaftsleistung von Spezialisten und Fachabteilung, das nur bei positivem Mitwirken aller gelingt, laufende Information über den Projektfortschritt, Begründung der Lösungen und Maßnahmen, Gelegenheit zur Mitwirkung, Vermittlung von Sicherheit (Arbeitsplatzgarantien, Umschulung), keine überstürzte Einführung von Änderungen, insbesondere nicht ohne vorherige Ankündigung und Diskussion, Veränderungen sollten die Regel sein, positiv gesehen werden und laufend stattfinden (nicht nur selten große Projekte !).

3.1.8 Software Konfigurations Management Im Zuge des Lebenszyklus eines Software-Produkts ensteht eine Vielzahl von Dokumenten, Berichten, Protokollen, Auflistungen u.s.w. Diese Sammlung von Daten bzw. Unterlagen, die das Software-Produkt gewissermaßen darstellen, bezeichnet man als Software-Konfiguration. Aufgabe des Software Konfigurations Management ist die Verwaltung und Überwachung dieser Unterlagen. Jede Phase und jeder Schritt innerhalb des Lebenszyklus eines Software-Produkts führt zu Ergebnissen, die zu dokumentieren sind. Gegenstand der Dokumentation sind • das Projekt und • das herzustellende Produkt.

308

3 Software Engineering

Die Dokumentation sollte grundsätzlich projektbegleitend erfolgen, dabei ist besonders darauf zu achten, daß die Dokumentation mit dem tatsächlichen Lösungsstand übereinstimmt, was bei häufigen Änderungen/Verbesserungen im Zuge der Entwicklung nicht selbstverständlich ist. Hinsichtlich des Projektes sind zu dokumentieren: • • • • • •

Die Entwicklung, Entscheidungen und ihre Begründungen, Rechtfertigung des Systems, Gespräche/Besprechungen (Protokolle), Testverläufe und -ergebnisse, Abnahmen (Protokolle), Zeit und Kosten SOLL und IST.

Das Produkt ist anhand der Phasen seiner Entwicklung zu dokumentieren: • • • • • • • • • • •

Ziele, fachliches Grobkonzept, EDV-Grobkonzept, Schnittstellen, Datenorganisation, Fachinhaltsbeschreibungen, Beschreibung der Programmfunktionen, der Ein- und Ausgaben, Programmdokumentation (in den Quellenprogrammen selbst), Bedienungsanleitungen, Operatoranweisungen, Anweisungen zur Implementierung.

Teilweise Überschneidungen zwischen Projekt- und Produktdokumentation sind nicht zu vermeiden.

3.2 Vorgangskettenanalyse Ausgangspunkt der Systementwicklung ist wie in Abschnitt 3.1.2.2 bereits beschrieben eine zusammenhängende Darstellung der betriebswirtschaftlichen Problemstellung, die möglichst viele Tatbestände über zu verarbeitende Daten, zu realisierende Funktionen, beteiligte Organisationseinheiten und die Abläufe der Geschäftsprozesse erfassen sollte. Desweiteren sollte es möglich sein anhand dieser Darstellung Schwachstellen in den IST-Abläufen und ihrer Computerunterstützung zu erkennen sowie davon ausgehend wesentliche Punkte eines SollKonzeptes für das zu entwickelnde Anwendungssystem zu beschreiben. Eine für diese Zielstellung geeignete Abbildung von Geschäftsprozessen wird mit dem von Scheer [See 90, S. 39] eingeführten Vorgangskettendiagramm (VKD) erreicht. Abb. II-3.2-1 zeigt als Beispiel eine solche Darstellung für den IST-Ablauf einer Kundenauftragsbearbeitung und Beschaffung.

Teil II Betriebliche Informationssysteme

DV-UNTERSTUTZT Vorgänge DATENBASIS

MANUELL

BEARBEITUNG BATCH

309

DATENBASIS

DIALOG

BEARBEITUNG

Abteilung

Auftragsklärung Auftragsdatenerfassung (evtl Lotwbearbeitungsauftrag auslösen) Auftragserfassung

Kunde

-5 «-Ol

O.K. Einkaut

Freigabe Kuidenauftragsbestätigung Auftragseröffnung durch Arbeosuxberetung im System • Erfassen Fertigungsauftrag im System Eingeplant (J/N) Teonin Dispomenge reservieren vom System

lottnbtmlM»tung-xMjlong

*5-J

tm^M^M^,

s

•

Sublieferant

•

Kunde

Arbeitsvorbereitung

-CK--

Formular "AufbagsowiqanQ" Formulai tur Bouqnjppon und Eip«nlortiglOMO

i

Beschaffung Ermittlung Einkaufstelle Kunden-Aufträge

Kofi« Formular AuKrngso»wj tnKaui salotto dm KO-AufkQ.

Feststellen Bedarfssituation Dikld der Bestellungen (Manuelle Bestelmengeneimitllung)

Einkauf

-II

Einkauf

r>5

Erstellen Bestellung aus Tonbandautzeichnung und Weitergabe an Waren-, einkaut, Versand

Erfassung der Bestellung als offene Bestellung (manuelle Lageftjuchungen)

DwMtog

Einkauf

liutfcjnj Lieferant Wareneinkauf. Versand für Einkaufteile

o

Einkauf ' [ P M ]

Abb. II-3.2-1 Ist-Ablauf Kundenauftragsbearbeitung und Beschaffung als Vorgangskettendiagramm ( V K D ) [Sce92, S.58]

310

3 Software Engineering

Dabei werden im Raster eines spaltenorientierten Diagramms der zeitlichlogische Ablauf der einzelnen auszuführenden Funktionen, die beteiligten Organisationseinheiten und die Datenversorgung bzw. Datenerzeugung der Funktionen dargestellt. Desweiteren gibt die Rasterung über die DV-Unterstützung der Funktionen Auskunft: Dialog-, Batch- bzw. manuelle Bearbeitung der ausgeführten Funktionen. Durch zusätzliche Spalten, z. B. für die in den Funktionen eingesetzten DV-Anwendungssysteme ist eine weitere Detaillierung der Beschreibung möglich. In einer Analyse von Vorgangsketten, die durch VKD beschrieben sind, können leicht • • •

Medienbrüche zwischen einer DV-unterstützten und manuellen Bearbeitung, Mehrfacherfassungen von Daten und Datenredundanzen im Gesamtablauf, Zeitverzögerungen zwischen Abarbeitungsschritten aufgrund des Wechsels der verantwortlichen Organisationseinheit

erkannt werden (vgl.Abb. II-3.2-1). Die Beseitigung dieser Schwachstellen in den IST-Abläufen des betrachteten Unternehmensbereichs, z. B. durch Erweiterung der DV-Unterstützung, Einführung einer einheitlichen Datenbasis und Optimierung des Prozeßablaufs, wird dann mit den anderen festgelegten Zielen der Systementwicklung (vgl. Abschnitt 3.1.2.2) Grundlage des SOLL-Konzepts für das neue DV-System sein (vgl. Abschnitt 3.1.2.3). Neben der Darstellung der betriebswirtschaftlichen Ausgangssituation für eine Systementwicklung durch Vorgangskettendiagramme gibt es auch andere Möglichkeiten, die Definitionsphase eines DV-Projekts durch graphische Hilfsmittel zu unterstützen. Diese sind jedoch oft auf die Methodik der Modellierung in den nachfolgenden Phasen abgestimmt, z. B. Kontextdiagramme (vgl. Abschnitt 3.4.4.3), Objektschemata (vgl. Abschnitt 3.6).

3.3 Datenmodellierung 3.3.1 Probleme der Datenorganisation in Informationssystemen Objekte und Beziehungen zwischen Objekten des entsprechenden realen Systems werden im Informationssystem durch Daten abgebildet. Das Datenmodell ist Teil des Konzepts bzw. des Fachkonzepts, seine Verfeinerung kann schon dem Entwurf zuzuordnen sein. Es ist Kern des Fachkonzepts der Datensicht nach Abb. II2.2-4 (ARIS). Die Bedeutung der Datenorganisation für Informationssysteme kann nicht überschätzt werden. Die geeignete Datenorganisation ist eine der Voraussetzungen für Verarbeitungen und Auswertungen und für die Verknüpfung unterschiedlicher Aufgabengebiete (Integration). Insbesondere Online-Verarbeitung und die

Teil II Betriebliche Informationssysteme

311

Notwendigkeit der Abfrage aktueller Daten im Dialog setzen die geeignete Datenorganisation voraus. Datenbestände werden gewöhnlich in mehreren und unterschiedlichen Aufgabengebieten benutzt - was sachlich geboten und gleichzeitig wünschenswert ist dies aber in der Regel nach unterschiedlichen Ordnungs- und Verarbeitungskriterien. Wir veranschaulichen die Problematik anhand von zwei Beispielen:

Beispiel I: Die in einer Abrechnungsperiode angefallenen Kosten werden - vereinfacht dargestellt - innerhalb des betrieblichen Rechnungswesens verarbeitet • •

•

nach Kostenarten, beispielsweise Materialeinsatz, Löhne, Instandhaltungen, Betriebsstoffe, nach Kostenstellen, d.h. nach Abteilungen oder Verantwortlichkeitsbereichen wie beispielsweise Fertigung/Dreherei, Fertigung/Montage, Wareneingang, Lager, Vertrieb Innendienst, und nach Kostenträgern, d.h. Aufträgen, Produkten oder Produktgruppen, für die Leistungen erbracht worden und Kosten angefallen sind.

Ein entsprechender Datenbestand möge die in einer Abrechnungsperiode (Monat) angefallenen Kosten enthalten. Ergänzend gehen wir davon aus, daß zusätzlich zu den "angefallenen Kosten" jeweils Stamminformationen (Bezeichnungen, Verrechnungsart und -sätze u.a.m.), Planzahlen und dergleichen nach Kostenarten, Kostenstellen und Kostenträger gespeichert werden. Die dargestellte Aufgabe scheint relativ leicht lösbar zu sein, wenn man mehrere Sortiervorgänge (des Datenbestandes der angefallenen Kosten) und eventuell auch redundante Speicherung in Kauf nimmt. Gegen diese Art der Lösung und insbesondere gegen das Vorgehen spricht, daß das Problem nicht zunächst "logisch" bzw. konzeptionell bearbeitet wurde, sondern daß sofort auf Gesichtspunkte der physischen Realisierung eingegangen wird. Beispiel 11: Problematischer ist die Darstellung von Bestellungen an Lieferanten im Datenmodell. Hier tritt der Fall auf, daß der Datenbestand der Bestellungen Teil mehrerer hierarchischen Ordnungen ist und gleichzeitig auch auf anderem Wege als über die Hierarchie darauf zuzugreifen ist. Noch nicht ausgelieferte - aber auch ausgelieferte - Bestellungen an Lieferanten sind Elemente der Hierarchie Lieferanten - Bestellungen, wovon aber auf Bestellungen auch unabhängig von Lieferanten zuzugreifen ist. Dazu kommt, daß innerhalb des Datenbestandes der Bestellungen Elemente variabler Größe und/oder Anzahl auftreten. Derartige nicht-atomare oder nichtskalare Elemente oder Wiederholgruppen wie hier z. B.: Positionen einer Bestel-

312

3 Software Engineering

lung, mehrere Wareneingänge zu einer Bestellposition stellen eine weitere Komplizierung des Sachverhalts dar. Andere Beispiele für derartige variable Element sind mehrere Provisionspruppen abhängig von Produktgruppen, mehrere Preise im Zeitablauf, eine variable Anzahl möglicher Lieferanten für einen Artikel, die Verteilung des Lagerbestandes eines Artikels auf eine variable Zahl von Lagerorten (verteiltes, "chaotisches" Lager) usw. Den Bestellbestand des Betriebes (den Bestand noch nicht ausgelieferter Bestellungen an Lieferanten) benutzen beispielsweise als Aibeitsgrundlage: • • • •

Die Sachbearbeiter des Einkaufs überwachen die Bestellabwicklung, insbesondere auch hinsichtlich termingetreuer Lieferung; der Disponent benötigt neben Lagerbeständen und Bedarf den Zugriff auf Bestellbestände nach Artikeln und Liefertermin, um die Lieferbereitschaft zu sichern, der Wareneingang benötigt den Bestellbestand zur Vorbereitung der Warenannahme, die Einkaufsleitung gewinnt Entscheidungsgrundlagen über das Lieferverhalten (Qualität, Termintreue) der Lieferanten.

Abbildung II-3.3-1 zeigt diese Anforderungen, die wir als Datensichten bezeichnen und die keineswegs vollständig sind, in schematischer Form.

Abb. II-3.3-1: Konzeptionelle Datenorganisation

3.3.2 Phasen der Datenmodellierung Wenn wir den Sachverhalt verallgemeinern, kommen wir zur Darstellung gemäß Abb. II-3.3-2. Die Problematik wurde bereits in Teil I, Abschnitt 6.2 angesprochen, dort allerdings als vorgelagerte Aufgaben des physischen Datenbankdesigns. Anstelle von Datensicht verwenden wir die übliche Bezeichnimg "Subschema", die Gesamt-Datenorganisation bezeichnen wir als "Schema". Subschemen und Schema sind Gegenstand der semantischen, "logischen" oder konzeptionellen Datenorganisation oder des "konzeptionellen Schemas". Wir be-

Teil II Betriebliche Informationssysteme

313

trachten diese Begriffe als synonym. Man spricht auch vom "logischen" oder konzeptionellen Datenbankdesign. Um die Beziehung zu Teil I zu verdeutlichen, haben wir die physische Datenorganisation ergänzt. Hier behandeln wir die Schritte bis zur Erarbeitung der konzeptionellen Datenorganisation bzw. des konzeptionellen oder semantischen Schemas (oder einfach des "Schemas").

Abb. II-3.3-2: Phasen der Datenorganisation in betrieblichen Informationssystemen Dies entspricht einem Bottom Up-Vorgehen, einem Vorgehen von unten nach oben bzw. vom Detail zum Ganzen. Es erscheint sinnvoller und auch realistischer [vgl. auch Vet91], davon auszugehen, daß ein sachkundigen Entwickler für ein konkretes Aufgabengebiet sofort das grobe Datenmodell erkennt (Top Down). Dieser Rahmen ist dann Bottom Up zu ergänzen oder auszufüllen. Nur die Umsetzung der "logischen" Datenorganisation in die physische ist im engeren Sinne ein EDV-Problem, die Entwicklung der Subschemen und des Schemas ist ebenso sehr eine fachliche Aufgabe im Sinne der Anwendung wie der Datenverarbeitung. Die Unterscheidung zwischen "logischer" und physischer Datenorganisation erweist sich für die Entwicklung von Konzepten für Anwendersysteme als vorteilhaft und ist heute absolut unumstritten. •

Man unterstellt die physische Realisierbarkeit, betrachtet die Art der physischen Realisierung aber als "Black Box" und setzt sich so zunächst konzentriert mit den Sachfragen auseinander.

•

Die Datenorganisation bleibt damit nicht nur den EDV-Spezialisten vorbehalten.

314

3 Software Engineering

•

Dies erleichtert und vereinfacht die Vorgehensweise und präjudiziell nicht die sachliche Lösung durch die physische Realisierung. Der Vorrang der Sache gegenüber dem Instrument wird deutlich zum Ausdruck gebracht.

•

All dies erleichtert die Mitwirkung der Fachabteilungen und fordert so die Akzeptanz des DV-Systems.

•

Nicht zuletzt zwingen grundsätzliche und systematische Aspekte zur Trennung der sachlogischen Lösung und ihrer konkreten Realisierung mittels eines bestimmten Instruments (EDVA).

3.3.3 Methoden der Datenmodellierung Die oben in Teil I, Abschnitt 6.1 verwendten, herkömmlichen Begriffe Datei (für einen geschlossenen Datenbestand, z. B. Lieferantendatei), Satz (für ein Element daraus, ein Lieferant) und Feld (für Elemente eines Satzes, z. B. Lieferantennummer, Firmenbezeichnung, Saldo, Zahlungsbedingung) sind nicht ganz klar, weil man sie sowohl auf die "logische" Datenorganisation als auch auf die physische Realisierung im Computer beziehen könnte. Zur Beschreibung der "logischen" Datenorganisation und zur Abgebzung gegenüber der physischen werden daher im Interesse der Klarheit die folgenden Begriffe verwendet: Objekte der realen Welt, die im Informationssystem abzubilden sind, bezeichnet man als Entity oder als Entität. Beispiele für Entitäten sind (jeweils 1) Artikel, Kunde, Auftrag, Stücklistenposition, Konto, Buchungssatz u.s.w. Entitäten gleichen Typs werden nach Klassen (Entity-Typen, Entity- oder Entitätsklassen) zusammengefaßt, also Artikel, Kunden, Aufträge, Stücklistenpositionen, Konten, Buchungssätze u.s.w. Im weiteren werden wir auch Entitätsklassen einfach als Entitäten bezeichnen, weil unsere Überlegungen und Aussagen grundsätzlich nicht nur für eine Entität, sondern jeweils für die ganze Klasse gelten. Zu den Entitäten kommen Beziehungen zwischen Entitäten (Relationships), wie beispielsweise "Kunde erteilt Auftrag", "Buchungssatz gehört zu Konto" u.s.w. Zur Abbildung einer Entität (Beispiel: Lieferant) gibt man deren Attribute (Eigenschaften) an, z. B. Lieferantennummer, Firmenbezeichnung, Zahlungsbedingung. Ein Attribut besonderer Art ist das Schlüsselattribut. Ein Tupel von Attributen, darunter das Schlüsselattribut, bildet somit eine Entität ab. Eine Menge gleichartiger (homogener) Tupel wird als Relation bezeichnet. Ein Entity-Typ ist somit gekennzeichnet und eindeutig beschrieben durch eine Attributskombination, ein Entity durch eine Attributwertkombination. Die Entities eines Typs kann man als Relation über den Wertebereich der entsprechenden Attribute bei beliebiger Anordnung auffassen (hier unterscheiden wir zwischen Entity und Entity-Typ).

Teil II Betriebliche Informationssysteme

315

Als Instrumente zur Darstellung der logischen Datenorganisation, die EDV- und damit auch insbesondere hardwareunabhängig ist, benutzt man das Entity-Relationship-Modell (ERM) bzw. ER-Diagramme (ERD) nach Chen [Che76] und normalisierte Relationen nach Codd [Cod70 bzw. Cod72]. Relationen sind allerdings - im Gegensatz zum ERM - nicht unabhängig vom Konzept der physischen Realisierung, insbesondere dem Konzept der eingesetzten Datenbank, sie entsprechen aber der heute üblichen Technologie, sind sehr nützlich und besonders in der Darstellung als Tabellen sehr anschaulich. Derselbe Sachverhalt wird so zweimal dargestellt. Redundanz ist hier sinnvoll und erwünscht, weil unterschiedliche Gesichtspunkte hervorgehoben werden und weil Sicherheit und Korrektheit erhöht werden. Es ergeben sich die nachstehenden Entsprechungen: ER-Diagramm

Normalisierte Relationen Relation

Tabellendarstellung der Relationen Tabelle

Entitätsklasse (Entity-Typ) Beziehung (Relationship)

eigene Relation oder

eigene Tabelle oder Fremd-

Entität

Fremdschlüssel 1 Tupel von Attributen

schlüssel 1 Tabellenzeile

Attribut

Attribut

Tabellenspalte

3.3.4 Entity-Relationship-Modell (ERM) 3.3.4.1

Allgemeine

Regeln

und Konventionen

der

Darstellung

Für das ERM gibt es einen Quasi-Standard und eine Vielzahl von Erweiterungen, die Schwächen des Standards beseitigen, aber sich nicht allgemein durchgesetzt haben. Wir behandeln hier den "Standard". Auf einige interessante Erweiterungen gehen wir bei der Diskussion von Sonderproblemen kurz ein. Entitäten werden durch das Symbol des Rechtecks dargestellt. Dazu kommen eine verbale Beschreibung der Entität, die dem semantischen Gesichtspunkt Rechnung trägt, und die Angabe des Primärschlüsssels und der Nichtschlüsselattribute. Der Wert aller Nicht-Schlüsselattribute muß eindeutig durch den des Schlüsselattributs bestimmt sein. Man bezeichnet das als die volle funktionale Abhängigkeit aller Nicht-Schlüsselattribute vom Schlüsselattribut. Beziehungen (Relationships) werden durch einen Rhombus dargestellt. Jede Beziehung ist analog der Entität verbal zu beschreiben. Dabei ist dem semantischen Aspekt Rechnung zu tragen. Häufige Beziehungen sind:

' Eine Beziehung entspricht i . d R . dann einer eigenen Relation, wenn sie vom Typ m:n ist, oder wenn sie NichtSchlüsselattribute enthält (was wir für unzweckmäßig halten, siehe unten); andernfalls kommt sie durch FremdschlQssel in Relationen zum Ausdruck. Der Sachverhalt wird unten in Abschnitt 3.3.5 verdeutlicht.

316 "hat" "gehört zu" "ist ein"

3 Software Engineering z. B.: Lieferant hat Offene Posten, Bestellung hat Bestellpositionen z. B.: Offener Posten gehört zu Lieferant, Bestellung gehört zu Lieferant, Bestellposition gehört zu Bestellung z. B.: Bestellposition ist ein Artikel

Zu jeder Beziehung ist auch der Typ anzugeben (1:1, l:n, m:n). Diese Darstellung des Beziehungstyps ist nicht ausreichend klar; sie läßt beispielsweise die Frage offen, ob n auch den Wert Null annehmen kann. Als zweckmäßig erweist sich die sogenannte Minimax-Notation: Dabei wird zu jedem Entity angegeben, wie oft es mindestens und höchstens in einer Beziehung auftreten kann. Die Beziehung "0, n" vom Lieferanten zur Bestellung in Abb. II-3.3-3 bedeutet, daß einem Lieferanten keine Bestellung zugeordnet zu sein braucht, die Obergrenze ist eine beliebige Zahl (viele). "l,n" würde zum Ausdruck bringen, daß es zu einem Lieferanten mindestens eine Bestellung geben muß. "1,1" entspricht der obigen verbalen Formulierung, daß jede Bestellung zu genau einem Lieferanten gehört.

Entität Lieferant enthält die Stamminformationen des Lieferanten Primärschlüssel (PS) ist die Lieferantennummer Nichtschlüsselattribute (NSA) sind Firma, Anschrift uam Entität Bestellung enthält die Daten, die für eine Bestellung als Ganzes gelten Primärschlüssel (PS) ist die Bestellnummer Nichtschlüsselattribute (NSA) sind Bestelldatum. Name des Einkäufers uam Relationship 1: ein Lieferant erhält eine variable Zahl von Bestellungen/ eine Bestellung gehört zu einem Lieferanten

Abb. II-3.3-3: ERD Lieferant - Bestellung/1 Die Darstellung gemäß Abbildung II-3.3-4 stellt denselben Sachverhalt in einer Form dar, die man häufig in CASE-Tools findet und die dieselben Aussagen liefert. Lieferant

erhält k-gehört zu

0 X >

Bestellung

Abb. II-3.3-4: ERD Lieferant - Bestellung/2

Entsprechungen zeigt die folgende Tabelle: einfacher Pfeil doppelter Pfeil 0 I

Maximum = 1 Maximum = viele Minimum = 0 Minimum = 1

Teil II Betriebliche Informationssysteme

317

Bezeichnungen werden sofort in das Diagramm geschrieben, auch dabei ist auf den semantischen Aspekt zu achten. Wir stellen nun das obige Beispiel I (Kostenrechnung) als ERD (Abb. II-3.3-5) dar.

Abb. II-3.3-5: ERD Kostenrechnung Die Entitäten in Beispiel I, Kostenrechnung, Abb. II-3.3-5, sind wie folgt zu beschreiben: Enti tat

Beschreibung

Kostenart

enthält die Stamminformationen der Kostenarten PS: Kostenartenschlüssel NSA: Kostenartenbezeichnung, Verrechungsart uam

Kostenstelle

enthält die Stamminformationen der Kostenstelle PS: Kostenstellenschlüssel NSA: Kostenstellenbezeichnung, Verantwortlicher, Verrechungsart uam

Kostenträger

enthält die Stamminformationen des Kostenträgers PS: Kostenträgerschlüssel (Auftragsnummer) NSA: Kostenträgerbezeichnung, Beginn und Ende der Arbeiten uam

angefallene Kosten (Kostenbeleg)

enthält die angefallenen Kosten je Periode PS: Belegnummer NSA: Belegdatum, Abrechnungsperiode, Betrag uam

Die Beschreibung der Beziehungen in Beispiel I, Kostenrechnung, Abb. II-3.3-5, liefert bereits interessante Aussagen:

318

3 Software Engineering

Beziehung 1

Beschreibung

2

angefallenene Kosten können einer Kostenstelle zugeordnet sein sie müssen aber nicht, wie beispielsweise gewisse Einzelkosten, eine Kostenstelle hat eine variable Zahl (unter Umständen auch keine) zugehöriger Kostenbelege

3

angefallenene Kosten können einem Kostenträger zugeordnet sein - sie müssen aber nicht, wie beispielsweise Gemeinkosten, ein Kostenträger hat eine variable Zahl (unter Umständen auch keine) zugehöriger Kostenbelege

angefallenene Kosten sind immer genau einer Kostenart zugeordnet, eine Kostenart hat eine variable Zahl (unter Umständen auch keine) zugehöriger Kostenbelege

Das obige Beispiel II (Bestellwesen) führt zum ERD gemäß Abbildung II-3.3-6.

Abb. II-3.3-6: ERD Bestellwesen Die Entitäten im Beispiel des Bestellwesens, Abb. II-32.6, sind wie folgt zu beschreiben: Entität

Beschreibung

Lieferant

enthält die Stamminformationen des Lieferanten PS: Lieferantennummer NSA: Firma, Anschrift uam

Bestellung

enthält die Daten, die für eine Bestellung als Ganzes gelten PS: Bestellnummer (eigene) NSA: Bestelldatum, Name des Einkäufers

Teil II Betriebliche Informationssysteme

319

Bestellposition

enthält die Daten, die für eine Bestellposition, d. h. einen bestellten Artikel, gelten PS: Bestellnummer (eigene) + Positionsnummer NSA: bestellter Artikel, bestellte Menge, Liefertermin uam

Artikel

enthält die Stamminformationen des Artikels PS: Artikelnummer NSA: Artikelbezeichnung,

Die Beziehungen im Beispiel des Bestellwesens, Abb. II-3.3-6, sind wie folgt zu beschreiben: Beziehung

Beschreibung

1

einem Lieferanten kann eine variable Zahl von Bestellungen erteilt werden, eine Bestellung gehört zu genau einem Lieferanten

2

eine Bestellung hat eine variable Zahl von Bestellpositionen (mindestens eine), eine Bestellposition gehört zu genau einer Bestellung

3

eine bestellte Position ist ein Artikel, ein Artikel kann eine variable Zahl von Bestellpositionen als Bestellbestand haben (wodurch der verfugbare Bestand des Artikels erhöht wird)

Eine Entität wie die Bestellposition wird auch als "schwache" Entität bezeichnet, weil sie nur in Verbindung mit der Bestellung eine Berechtigung hat und Sinn ergibt. In Abbildung II-3.3-7 erscheint sie überhaupt nicht. Sie ist dort keine Entität, sondern ein Relationship zwischen Lieferant und Artikel, allerdings ein Relationship mit eigenen Attributen (bestellte Menge, Liefertermin). Ein Entität, die anstelle einer m:n-Beziehung mit eigenen Attributen tritt und sie in zwei 1 inBeziehungen auflöst, bezeichnet man auch als "assoziative" Entität.

Abb. II-3.3-7: ERD Bestellwesen, zweite Version

320

3 Software Engineering

In Literatur und Praxis bestehen unterschiedliche Auffassungen darüber, ob Relationships Attribute enthalten sollen oder dürfen. Gemeint sind hier NichtSchlüsselattribute, denn Schlüssel sind implizit in der Beziehung enthalten. ERD werden klarer und einfacher, wenn auch umfangreicher, wenn man Relationships grundsätzlich keine (Nicht-Schlüssel)-Attribute zuordnet. Dies wird im nächsten Abschnitt deutlich. Auch der Rückfluß aus der Praxis, nicht zuletzt dargestellt durch CASE-Tools (vgl. Abschnitt 3.7) spricht dafür, Relatonships nur als Beziehungen und ohne eigene Attribute zu definieren und gegebenenfalls eigene Assoziative Entitäten zu definieren. Auch das Beispiel der Bestellposition dürfte diese Auffassung stützen. Wir erweitern nun das ERD Abb. II-3.3-6 um die Beziehung zwischen Artikel und Lieferanten. Ein Artikel wird von keinem (bei eigener Produktion), von einem oder mehreren Lieferanten bezogen. Ein Lieferant liefert keinen (wenn es sich um einen Anbieter von Dienstleistungen handelt), einen oder mehrere Artikel. Der Sachverhalt kann durch eine im Einkauf geführte Kartei etwa gemäß Abb. II-3.3-8 veranschaulicht werden. Artikel-Nr

Artikel-Bezeichnung:

02

Hollandrad

Produktgruppen -Schlüssel Ol

ProduktgruppenBezeichnung Fahrzeug

Preis 286.-291,50 280,50

Kondition frei frei aWk

Bezugsmöglichkeiten: Lieferant-Nr L-l L-2 L-3

Firma H. Schulze Koch & Krug Hermann GmbH

Abb. II-3.3-8: "Bezugsquellenkartei" der Fachabteilung Die Darstellung Abb. II-3.3-9 enthält die Beziehung

Abb. II-3.3-9: "Bezugsquellenkartei" als ERD Die Beziehung 1 widerspricht den obigen Ausführungen, denn sie enthält eigene Attribute wie beispielsweise den Preis eines bestimmten Artikels bei einem bestimmten Lieferanten, Lieferzeiten, Sonderzuschläge, Rabatte, die Nummer und

Teil II Betriebliche Informationssysteme

321

die Bezeichnung des Artikels beim Lieferanten, allgemein: alle artikel- und lieferantenabhängigen Daten. Wir fuhren daher eine Entität Bezugsquelle ein und kommen so zum ERD gemäß Abb. II-3.3-10. Eine Bezugsquelle bringt die Möglichkeit des Bezugs eines Artikels bei einem Lieferanten zum Ausdruck, nicht aber eine erteilte Bestellung. Der Primärschlüssel derartiger assoziativer Entitäten setzt sich häufig aus den Primärschlüsseln der Entitäten, zwischen denen die "Assoziation" hergestellt wird, zusammen, hier also aus Artikelnummer und Lieferantennummer.

Abb. II-3.3-10: ERD Bestellwesen/erste Erweiterung Die Entitäten bzw. Beziehungen in Abb. II-3.3-10 sind wie folgt zu beschreiben, soweit dies nicht bereits zuvor geschehen ist: Entität

Beschreibung

Bezugsquelle

Enthält die artikel- und lieferantenabhängigen Daten für das Bestellwesen PS.Artikelnummer + Lieferantennummer NSA: Artikelnummer und -bezeichnung beim Lieferanten, Einkaufspreis

Beziehung

Beschreibung

4

Für einen Artikel gibt es keine, eine oder mehrere Bezugsquellen, eine Bezugsquelle gehört zu genau einem Artikel

5

Ein Lieferant kann keine, einen oder mehrere Artikel liefern, eine Bezugsquelle gehört zu genau einem Lieferanten

Das ERD in Abbildung Abb. II-3.3-11 enthält ein Relationship, das zwar einen grundsätzlichen Zusammenhang zeigt (ein Artikel wird bei einem Lieferanten für einen Kunden beschafft), doch gehen ganz offensichtlich wesentliche betriebs-

322

3 Software Engineering

wirtschaftliche Aussagen verloren (beispielsweise das Bestellwesen und die Kundenauftragsverwaltung, handelt es sich um eine grundsätzliche Strukturbeziehung oder um konkrete Aufträge/Bestellungen?). Wir haben bereits gezeigt, daß wir eine Auflösung dieses Relationships 1 in Aufträge und Bestellungen für sinnvoll halten.

Abb. II-3.3-11: ERD Warenwirtschaft 3.3.4.2

Generalisieruns

Von Generalisierung spricht man, wenn ein Entitätstyp ein Subtyp eines anderen Entitätstyps ("Supertyp") ist. Dabei wird i. d. R. auch gefordert, daß jede Entität des Supertyps auch eine Entität (mindestens) eines Subtyps ist. Das ist durch die folgenden Beispiele zu veranschaulichen: • Ein Kunde oder ein Lieferant (Subtypen) sind Geschäftspartner (Supertyp). Jeder Geschäftspartner ist entweder Kunde oder Lieferant, unter Umständen beides. • Ein Kunde (jetzt Supertyp) kann beispielsweise Warenempfänger, Auftraggeber, Rechnungsempfanger (Subtypen) sein. Eventuelle Integritätsbedingungen (entspricht einem Supertyp immer genau ein Subtyp? Oder auch mehreren? Muß es mindestens einen Subtyp geben?) sind nur teilweise durch das "klassische" ERM darzustellen. Interessante Erweiterungen behandeln Ferstl/Sinz als SERM (Strukturiertes Entity-Relationship-Modell) [FeS94] und Zehnder [Zeh89], Die Abbildungen II-3.3-12 und II-3.3-13 zeigen Darstellungsmöglichkeiten der Generalisierung nach dem "klassischen" Modell.

Abb. 11-32.12: ERD Generalisierung

Teil II Betriebliche Informationssysteme

323

Die Entitäten bzw. Beziehungen in Abb. II-3.3-12 sind wie folgt zu beschreiben: Entität

Beschreibung

Geschäftspartner

enthält die Stamminformationen, die für alle Geschäftspartner (Kunden, Lieferanten gelten - das Prinzip wäre zu erweitern auf Banken, Vertreter, Behörden usw.) PS: Geschäftspartnernummer NSA: Firma/Name, Adresse

Kunde

enthält die Stamminformationen des Kunden PS: Kundennummer NSA: Lieferanschrift, vereinbarte Verkaufskonditionen, Zuordnung zu Debitorensammelkonto

Lieferant

enthält die Stamminformationen des Lieferanten PS: Lieferantennummer NSA: Lieferwerk, Herkunftsnachweis,vereinbarte Einkaufskonditionen, Zuordnung zu Kreditorensammelkonto

Beziehung

Beschreibung

I

ein Geschäftspartner kann Kunde sein, jeder Kunde ist auch Geschäftspartner

2

ein Geschäftspartner kann Lieferant sein, jeder Lieferant ist auch Geschäftspartner

In Abbildung II-3.3-12 wird zwar zum Ausdruck gebracht, daß jeder Lieferant oder Kunde auch Geschäftspartner ist. Offen bleiben die Fragen: Ist jeder Geschäftsppartner Kunde oder Lieferant? Kann er beides zugleich sein?

>

O.n

Geschäftspartncrtyp

Abb. II-3.3-13: ERD Geschäftspartnerklassifikation Die Entität Geschäftspartnertyp und die Beziehung in Abb. II-3.3-13 sind wie folgt zu beschreiben:

324

3 Software Engineering

Entität

Beschreibung

Geschäftspartnertyp

enthält das Verzeichnis der Geschäftspartnertypen und deren Stamminformationen PS: Geschäftspartnertypnummer NSA: Geschäftspartnertypbezeichnung, Steuerungsund Abrechnungsregeln für Geschäftspartner

Beziehung

Beschreibung

1

ein Geschäftspartner kann Kunde sein, jeder Kunde ist auch Geschäftspartner

In der Darstellung gemäß Abbildung II-3.3-13 haben alle Geschäftspartner, d. h. Kunden und Lieferanten, dieselben Attribute (aber natürlich andere Attributwerte). Ein Geschäftspartner kann nur Kunde oder Lieferant sein. Man nutzt das Prinzip der Generalisierung, um Attribute (oder auch sonstige Merkmale wie etwa Programmfunktionen) auf hoher Ebene zuzuordnen und auf meherere Subtypen zu vererben (vgl. dazu Abschnitt 3.6). 3.3.4.3 Bedingte A

bhänsiskeiten

Zur Darstellung bedingter Abhängigkeiten greifen wir auf das Beispiel des Bestellwesens (Abb. II-3.3-10) zurück und erweitern es zunächst um die Erfordernisse der Kontierung: Zur automatischen Zuordnung von Eingangsrechnungen zu Einkaufs- oder Bestandskonten stellen wir eine Beziehung zwischen Artikel und Sachkonto wie folgt her: Ein Artikel gehört zu einer Artikelgruppe, der Artikelgruppe ist ein Einkaufskonto zugeordnet (Abb. II-3.3-14).

Abb. II-3.3-14: ERD Einkaufskontenzuordnung zu Artikel Die Entitäten bzw. Beziehungen in Abb. II-3.3-14 sind wie folgt zu beschreiben:

325

Teil II Betriebliche Informationssysteme Enti tat

Beschreibung

Artikel

bereits bekannt

Artikelgruppe

enthält die Stamminformationen von Artikelgruppen (für statistische Auswertungen oder für die Gruppe gültige Konditionen usw.) PS: Artikelgruppenschlüssel NSA: Artikelgruppenbezeichnung, Abrechnungsund Auswertunsgmerkmale

Sachkonto

enthält die Stamminformationen der Sachkonten der Finanzbuchhaltung PS: Kontonummer NSA: Kontenbezeichnung, Zuordnung zu Bilanz/ Gu V-Rechnung

Beziehung

Beschreibung

1

jeder Artikel gehört zu genau einer Artikelgruppe, eine Artikelgruppe faßt eine variable Zahl von Artikeln zusammen

2

jede Artikelgruppe gehört zu einem Bestandskonto der Finanzbuchhaltung (damit wird die Beziehung zwischen der Bestandsführung im operativen System der Materialwirtschaft und der Finanzbuchhaltung hergestellt), ein Konto kann die Bestände einer variablen Zahl von Artikelgruppen erfassen

Zur Darstellung des Problems bedingter Abhängigkeiten in ERD anhand eines Fallbeispiels modifizieren wir die ursprüngliche Annahme, daß jede bestellte Position ein Artikel sein muß: Eine bestellte Position kann, muß aber nicht ein (lagermäßig geführter) Artikel sein, es kann sich auch um (nicht lagermäßig geführtes) Gemeinkostenmaterial oder um eine Dienstleistung handeln. Wir bezeichnen die letztgenannten einfach als "Gemeinkosten-Bestellposition". Auch Eingangsrechnungen über die letztgenannten Bestellpositionen ("GemeinkostenBestellposition") müssen kontiert werden, i. d. R. auf Kostenkonten. Buchungen auf Kostenkonten müssen außerdem einer Kostenstelle zugeordnet (belastet) werden. Da der Weg über Artikel und Artikelgruppe nun nicht mehr möglich ist, ist eine derartige Bestellposition direkt einem Konto und einer Kostenstelle zuzuordnen. Abbildung II-3.3-15 "klassisches" ERD.

zeigt die

Darstellung des

Sachverhalts

durch

ein

326

3 Software Engineering

Abb. II-3.3-15: ERD Einkaufskontenzuordnung zu Bestellposition Die Entitäten von Abbildung II-3.3-15 wurden durchwegs bereits beschrieben, die folgende Beschreibung der Relationships geht auf Integritätsbedingungen leider nur verbal ein: Beziehung

Beschreibung

3

eine Bestellposition kann einem Sachkonto zugeordnet sein, und zwar dann, wenn es sich um eine "Gemeinkosten-Bestellposition" handelt (sie muß dann auch gemäß Relationship einer Kostenstelle zugeordnet sein, darf aber dann nicht ein lagermäßig geführter Artikel sein); zu einem Konto kann es eine variable Zahl von Bestellpositionen geben

4

eine bestellte Position kann ein Artikel sein, ein Artikel kann eine variable Zahl von Bestellpositionen als Bestellbestand haben (wodurch der verfügbare Bestand des Artikels erhöht wird)

5

es gilt analog die Beschreibung zu Relationship

Das Beispiel könnte betriebswirtschaftlich um kostenträgerbezogene Bestellungen erweitert werden; die Problematik dürfte aber auch so bereits zu erkennen sein. Auch zu diesen Fragen behandeln Ferstl/Sinz [FeS94] und Zehnder [Zeh89] interessante Erweiterungen des "klassischen" Ansatzes.

3.3.5 Normalisierte Relationen Relationen, anschaulich dargestellt als Tabellen, sind ein geeignetes Instrument zur Darstellung von Datenstrukturen, implizieren allerdings weitgehend die Realisierung mittels einer relationalen Datenbank. Wir haben bereits oben Tabellen als anschauliches Instrument zur Darstellung von Dateien benutzt.

Teil II Betriebliche Informationssysteme

327

Auch die komplexesten Datenstrukturen können auf derartige einfache Tabellen zurückgeführt werden. Relationen können zudem durch drei einfache Operationen ausgewertet werden (Selektion, Projektion, Vereinigung oder Join, s. o. Teil I, Abschnitt 6.2). Innerhalb der Attribute, die eine Entität abbilden, unterscheidet man konzeptionell zwischen Schlüssel- und sonstigen oder Nicht-Schlüsselattributen. Hinsichtlich der Manipulation von Relationen durch relationale Algebra ist diese Unterscheidung nicht relevant, alle Attribute sind dafür gleichwertig. Der Erst- oder Primärschlüssel dient zur eindeutigen Identifizierung einer Tabellenzeile. Insgesamt wird über die Art des Zugriffs (sequentiell, wahlfrei, Sortierfolge) hiermit aber keine Aussage getroffen. Derartige Aussagen kann man ergänzend als nüzliche Informationen zur späteren physischen Realisierung vermerken. Entitäten entsprechen, wie bereits oben gezeigt wurde, Relationen oder Tabellen. Relationships des ERM werden im relationalen Modell durch Fremdschlüsselbeziehungen zum Ausdruck gebracht. Ein Fremdschlüssel ist ein Attribut, das Erstschlüssel einer anderen Relation ist und durch diese Wiederholung eine Beziehung (Relationship) zwischen Relationen abbildet. Fremdschlüssel sind NichtSchlüsselattribute besonderer Art. Die oben im ERD Abb. II-3.3-3 enthaltene Beziehung

wird im relationen Modell durch den Fremdschlüssel Lieferantennummer in der Relation Bestellung zum Ausdruck gebracht. Ein Fremdschlüssel kann immer nur eine zu eins-Beziehung darstellen. Er verweist immer eindeutig auf einen Primärschlüssel. Eine m:n-Beziehung ist aufzulösen durch eine dazwischengesetzte Relation (wenn nicht bereits aus oben erläuterten Gründen das m:nRelationship zu einer eigenen Entität gemacht wurde, womit ohnedies aus der m:n-Beziehung zwei l:n-Beziehungen gemacht wurden). Der Schlüssel dieser neuen Relation setzt sich aus den Primärschlüsseln der Relationen zusammen, zwischen denen sie die Beziehung herstellt. Eine derartige Relation wird teilweise als Nestrelation bezeichnet, vgl.dazu den Begriff "assoziative" Entität. Ein besonderer Vorteil des Relationenmodells liegt in den Regeln für die Normalisierung nach Codd [vgl. hierzu Vet91]. Nicht normalisierte Relationen können zu fehlerhaften Konzepten, zu Inkonsistenz, Verletzimg von Aussagen führen. Normalisierung sichert auch weitgehend semantische Korrektheit der Datenstrukturen und ist zwingend erforderlich. Durch Interpretation im Sinne des relationalen Konzepts und Normalisierung können ERD verifiziert werden. Die Normalisierungsschritte sind an sich so einleuchtend, daß sie intuitiv von jedem Analytiker angewandt werden. Wir wollen sie daher nicht im einzelnen erörtern, sondern veranschaulichen sie anhand des folgenden Beispiels:

328

3 Software Engineering

Wir beziehen uns wieder auf den Bereich EinkaufTBestellwesen und zwar auf die oben in Abbildung II-3.3-8 als "Bezugsquellenkartei" bezeichnete Arbeitsunterlage der Fachabteilung. Derselbe Sachverhalt kann auch als nicht normalisierte Relation mit nicht skalaren Attributen (Abb. II-3.3-16) oder als nicht normalisierte Relation mit Wiederholgruppen (Abb. II-3.3-17) dargestellt werden. Artikel

Artikelgruppe

Lieferant

Nr Bezeichnung

S1 Bezeichng

Nr

02 Hollandrad

01

Fahrzeug

2 8 6 . - frei 291,50 frei 280,50 aWk

05 Rennrad 10Gang

01

Fahrzeug

L-l H. Schulze L-2 Koch & Krug L-3 Hermann GmbH L-2 Koch & Krug L-3 Hermann GmbH L-4 Schmidtmeyer L-2 Koch & Krug L-3 Hermann GmbH L-2 Koch & Krug L-l H. Schulze L-4 Schmidtmeyer

408,50 aWk

11 Mittelzugbremse

02

12 Tachometer

03 Zubehör

13 Fahrradcomputer

03 Zubehör

25 Fahrrad-Dynamo

02

Ersatzteil

Ersatzteil

Preis

Kond

Firma

410,50 frei

5,85 5,95 12,60

aWk frei aWk

24,30 25,10 5,40

frei frei aWk

Abb. II-3.3-16:Bezugsquellen als nicht normalisierte Relation mit nicht skalaren Attributen

Artikel Nr Bezeichnung

Artikelgruppe S1 Bezeichng

Lieferant Nr Firma

Preis

Kond

02 02 02

Hollandrad Hollandrad Hollandrad

01 Fahrzeug 01 Fahrzeug 01 Fahrzeug

286.-291,50 280,50

frei frei aWk

05

Rennrad 10Gang Rennrad 10Gang Mittelzugbremse Mittelzugbremse

01 Fahrzeug

L-l H. Schulze L-2 Koch & Krug L-3 Hermann GmbH L-2 Koch & Krug

410,50

frei

L-3 Hermann GmbH L-4 Schmidtmeyer L-2 Koch & Krug

408,50

aWk

5,85 5,95

aWk frei

05 11 11

01 Fahrzeug 02 Ersatzteil 02 Ersatzteil

329

Teil II Betriebliche Informationssysteme 12

Tachometer

13 13 25

Fahrradcomputer 03 Zubehör Fahrradcomputer 03 Zubehör Fahrrad-Dynamo 02 Ersatzteil

03 Zubehör

L-3 Hermann GmbH L-2 Koch & Krug L-l H. Schulze L-4 Schmidtmeyer

12,60

aWk

24,30 25,10 5,40

frei frei aWk

Die Lieferanten L-l und L-2 liefern grundsätzlich frei Haus, die Lieferanten L-3 und L-4 ab Werk. Abb. II-3.3-17: Bezugsquellen als nicht normalisierte Relation mit Wiederholgruppen Relationen in erster Normalform Die Forderungen zum ersten Normalisierungsschritt lauten: Attribute müssen in jeder Zeile in derselben Reihenfolge auftreten, sie dürfen nur skalare oder atomare Werte und keine Wiederholgruppen enthalten (was lediglich einer anderen Betrachtungsweise entspricht, vgl.Abb. II-3.3-16 und Abb. II3.3-17). Im Beispiel treten mehrere Lieferanten je Artikel auf bzw. die mehrfachen Lieferanten je Artikel verursachen Wiederholgruppen. Die Lösung liegt in der Bildung einer neuen Relation zur Darstellung der artikelund lieferantenabhängigen Attribute. Wir haben die entsprechende Entität oben in Abbildung II-3.3-10 als "Bezugsquellen" bezeichnet. Abbildung II-3.3-18 zeigt die Relationen des Beispiels in erster Normalform. Relation Artikel Artikel Nr Bezeichnung

Artikelgruppe Bezeichng S1

02 05 11 12 13 25

Ol Ol 02 03 03 02

Hollandrad Rennrad 10-Gang Mittelzugbremse Tachometer Fahrradcomputer Fahrrad-Dynamo

Relation Bezugsquellen ArtikelNr Lieferant Nr 02 L-l 02 L-2 02 L-3 05 L-2 05 L-3 11 L-4 11 L-2

Firma H. Schulze Koch & Krug Hermann GmbH Koch & Krug Hermann GmbH Schmidtmeyer Koch & Krug

Fahrzeug Fahrzeug Ersatzteil Zubehör Zubehör Ersatzteil

Preis 286.291,50 280,50 410,50 408,50 5,85 5,95

Kond frei frei aWk frei aWk aWk frei

330 12 13 13 25

3 Software Engineering L-3 L-2 L-l L-4

Hermann GmbH Koch & Krug H. Schulze Schmidtmeyer

12,60 24,30 25,10 5,40

aWk frei frei aWk

Abb. II-3.3-18: Bezugsquellen als Relationen nach dem ersten Normalisierungsschritt bzw. als Relationen in erster Normalform. Relationen in zweiter Normalform Die zweite Normalform baut auf der ersten auf. Der zweite Normalisierungsschritt fordert zusätzlich die Beseitigung funktionaler Abhängigkeiten von Attributen von Untermengen des Schlüssels. In der Relation Bezugsquellen unseres Beispiels dürfen weder nur artikel- noch nur lieferantenabhängige Attribute dargestellt werden. Die Einkaufspreise sind, weil artikel- und lieferantenabhängig, dieser Relation zuzuordnen, nicht aber die Firmenbezeichnung und die Kondition, die nur lieferantenabhängig und daher einer zu bildenden Relation Lieferant zuzuordnen sind (Abb. II-3.3-19).

Relation Artikel Artikel Nr Bezeichnung 02 Hollandrad 05 Rennrad 10-Gang 11 Mittelzugbremse 12 Tachometer 13 Fahrradcomputer 25 Fahrrad-Dynamo Relation Bezugsquellen ArtikelNr Lieferant Nr 02 L-l 02 L-2 02 L-3 05 L-2 05 L-3 11 L-4 11 L-2 12 L-3 13 L-2 13 L-l 25 L-4

Preis 286.291,50 280,50 410,50 408,50 5,85 5,95 12,60 24,30 25,10 5,40

Artikelgruppe Bezeichng S1 Ol Fahrzeug Ol Fahrzeug 02 Ersatzteil 03 Zubehör 03 Zubehör 02 Ersatzteil

Teil II Betriebliche Informationssysteme Relation Lieferant Lieferant Nr Firma L-l H. Schulze L-2 Koch & Krug L-3 Hermann GmbH L-4 Schmidtmeyer

331

Kondition frei frei aWk aWk

Abb. II-3.3-19: Bezugsquellen als Relationen nach dem zweiten Normalisierungsschritt bzw. als Relationen in zweiter Normalform Relationen in dritter Normalform Die dritte Normalform baut auf der zweiten auf. Im dritten Normalisierungsschritt sind zusätzlich funktionale Abhängigkeiten zwischen Attributen (also auch von Nicht-Schlüssel-Attributen) untereinander zu beseitigen. Im Beispiel ist die Bezeichnung der Artikelgruppe vom Artikelgruppenschlüssel abhängig. Die Lösimg liegt in der Bildung einer Relation Artikelgruppe, in den Artikelstamm (Relation Artikel) wird nur der Artikelgruppenschlüssel als Fremdschlüssel aufgenommen (Abbildung II-3.3-20). Relation Artikel Artikel

Artikelgruppe

Nr 02 05 11 12 13 25

S1 Ol Ol 02 03 03 02

Bezeichnung Hollandrad Rennrad 10-Gang Mittelzugbremse Tachometer Fahrradcomputer Fahrrad-Dynamo

Relation Artikelgruppe Artikelgruppe Bezeichng S1 Ol Fahrzeug 02 Ersatzteil 03 Zubehör Relation Bezugsquelle ArtikelNr Lieferant Nr 02 L-l 02 L-2 02 L-3 05 L-2 05 L-3

Preis 286.291,50 280,50 410,50 408,50

332 11 11 12 13 13 25

3 Software Engineering L-4 L-2 L-3 L-2 L-l L-4

Relation Lieferant Lieferant Nr Firma L-l H. Schulze L-2 Koch & Krug L-3 Hermann GmbH L-4 Schmidtmeyer

5,85 5,95 12,60 24,30 25,10 5,40

Kondition frei frei aWk aWk

Abb. II-3.3-20: Bezugsquellen als Relationen nach dem dritten Normalisierungsschritt bzw. als Relationen in dritter Normalform Wir kommen zum selben Ergebnis wie im ERM. Nach der Normalisierung ist das ER-Diagramm eventuell zu überarbeiten, dann nämlich, wenn im ursprünglichen Diagramm Verstöße gegen Normalisierungsregeln enthalten waren. In der Literatur [Vet92, ScS] werden als weitere Normalisierungsschritte die Boyce-Codd-Normalform sowie die vierte und die fünfte Normalform diskutiert, die aber geringe praktische Bedeutung haben. Volle funktionale Abhängigkeit der NSA vom PS bzw. die Normalisierung von Relationen sichern die Entitätsintegrität. Die referentielle oder Verweisintegrität ist Ausdruck korrekter Abbildung der Beziehungen zwischen Entitäten (Beziehungstyp, Kardinalität) bzw. korrekter Fremdschlüsselverweise, d. h. eindeutiger Verweis auf gültige PS, in Relationen.

3.3.6 Fallbeispiel zur Datenmodellierung Wir führen nun das Beispiel der Datenmodellierung für den Einkaufsbereich weiter, um in die Nähe eines realitätsgerechten Modells zu kommen. Den Ausgangspunkt bildet Abbildung II-3.3-10 mit der Erweiterung gemäß Abbildung II-3.315. Wir beziehen nun im Sinne von Bottom Up-Vorgehen weitere Datensichten ein. Die Entität "Lieferant" stellt für die Finanzbuchhaltung Kreditoren dar. Wir nehmen hier der Einfachheit halber an, daß Lieferant = Kreditor ist. Als Kreditor muß der Lieferant einem Verbindlichkeiten-Sammelkonto zugeordnet werden. Um die Schnittstelle des Bestellwesens zur Finanzbuchhaltung geschlossen darzustellen, erweitern wir Abbildung II-3.3-15 um die Lieferantenzuordnung zum Sachkonto (Abbildung II-3.3-21) und ergänzen die verbalen Beschreibungen.

Teil II Betriebliche Informationssysteme

333

Abb. II-3.3-21: ERD Beziehungen zwischen Bestellwesen und Finanzbuchhaltung Beziehung

Beschreibung

6

jeder Lieferant gehört zu einem Sammelkonto (Verbindlichkeiten) der Finanzbuchhaltung (dies ist eine der Voraussetzungen für die automatische Verbuchung von Eingangsrechnungen aus dem Bestellwesen in der Finanzbuchhaltung), ein Konto kann Sammelkonto für eine variable Zahl von Lieferanten sein

In Abb II-3.3-10 sind wir davon ausgegangen, daß die Bezugspreise lieferantenund artikelabhängig sind. Preise sind häufig auch abhängig von der bestellten Menge: In dem Falle wäre der Schlüssel dieser Entität um die Menge zu erweitern, wozu aber dann die sonstigen Nichtschlüsselattribute (Artikelnummer und bezeichnung beim Lieferanten) nicht passen würden, weil sie nicht mengenabhängig sind, so daß die Entität Bezugsquelle ohne das NSA Einkaufspreis bestehen bliebe und eine zusätzliche Entität, deren Schlüssel die Menge enthält, zur Darstellung der Einkaufspreise zu ergänzen wäre. Wir verfolgen diesen Gedanken hier aber nicht weiter und unterstellen, daß die Einkaufspreise nicht mengenabhängig sind (also keine Staffelpreise).

334

3 Software Engineering

Abb. II-3.3-22: ERD mit Darstellung von Einkaufspreisen im Zeitablauf Eine eigene Entität zur Darstellung der Einkaufspreise ist aber in der Regel aus einem anderen Grunde zwingend: Preise ändern sich im Zeitablauf. Die Darstellung lediglich der aktuellen Preise bringt nicht nur organisatorische Probleme, sie beschränkt auch Vergleichs- und Auswertungsmöglichkeiten, die den Zeitablauf berücksichtigen, beispielsweise die Entwicklung der Einkaufspreise im Zeitablauf. Die Entität zur Darstellung der Einkaufspreise muß somit einen Zeitbezug enthalten, beispielsweise das Datum, von dem an der Preis gilt 1 . Das Datum muß ein gültiges Datum im Sinne des für den Betrieb gültigen Kalenders, etwa eines Fabrikkalenders, sein. Wir kommen damit zu Abbildung II-3.3-22 mit erläuternden Beschreibungen:

Entität

Beschreibung

Bezugsquelle

enthält die artikel- und lieferantenabhängigen Daten für das Bestellwesen PS: Artikelnummer + Lieferantennummer NSA: Artikelnummer und -bezeichnung beim Lieferanten enthält die artikel-, lieferanten- und zeitabhängigen Einkaufspreise PS: Artikelnummer + Lieferantennummer + Datum NSA: Einkaufspreis

Einkaufspreis

' Die hier angestellte Überlegung kann auch ganz allgemein auf die Darstellung von Stammdaten im Zeitablauf angewandt werden. Wir gehen darauf aber nicht näher ein.

335

Teil II Betriebliche Informationssysteme Zeitachse

enthält die Stamminformationen zu Zeitraster und Planungsperioden des Betriebs PS: Datum /gregorianisch NSA: Datum nach Fabrikkalender, Zuordnung zu Saison und/oder Planungsperioden (d. h. Bezug auf entsprechende Entitäten, die hier nicht weiter verfolgt werden), Merkmal, ob Arbeitstag, Feiertag, Betriebsurlaub usw.

Beziehung

Beschreibung

5

zu einer Bezugsquelle gibt es eine variable Zahl von Einkaufspreisen im Zeitablauf, ein Einkaufspreis ist immer genau einer Bezugsquelle zugeordnet

6

zu einem Datum der Zeitachse gibt es eine variable Zahl von Einkaufspreisen (fiir Artikel/Lieferanten), ein Einkaufspreis ist immer genau einem Datum der Zeitachse zugeordnet

Um das Beispiel kompakt und übersichtlich zu halten, gehen wir auf weiteren Zeitbezug anderer Entitäten, etwa der Bestellposition, nicht mehr ein. Der Abwicklungsstand einer Bestellung (oder auch einer Bestellposition, was wir aber hier ebenfalls nicht weiter verfolgen) wird durch einen Abwicklungs-Status zum Ausdruck gebracht, beispielsweise: Statuswert

Bezeichnung

0 1 2 3 4 5

Bestellung erfaßt Bestellung gedruckt Bestätigung des Lieferanten erfaßt Lieferung avisiert Lieferung erfolgt Wareneingang geprüft

Die definierten Statuswerte werden in einer Entität dargestellt. Gleiches gilt für Bestellarten, beispielsweise: BestellartenSchlüssel

Bestellarten-Text

0 1 2

Normalbestellung Rahmenbestellung Abruf

TerminBestel- berücksichtilung gen in Be- Überwadrucken standsführung chung J J J

J N J

J N J

336 3 4 5

3 Software Engineering Barkauf wertm. Belastung mengenm. Belastung

N N N

J N J

N N N

Abwicklungs-Status und Bestellart sind im ERD Abbildung II-3.3-23 dargestellt..

Abb. II-3.3-23: ERD mit Darstellung von Abwicklungs-Status und Bestellart

Enti tat

Beschreibung

Abwicklungs-Status

enthält die gültigen Abwicklungs-Status und die davon abhängigen Steuerungsmerkmale PS: Status-Schlüssel NSA: Bezeichnung des Status, Folgestatus, Steuerungsmerkmale für Programme in Abhängigkeit vom Status (beispielsweise: In welchem Status ist noch eine Änderung der Bestellung zulässig? Kann ein Status übergangen werden?) enthält die gültigen Bestellarten und die davon abhängigen Steuerungsmerkmale PS: Bestellarten-Schlüssel NSA: Bezeichnung der Bestellart, Steuerungsmerkmale für Programme in Abhängigkeit von der Bestellart (siehe Beispiele in obiger Tabelle)

Bestellart

Beziehung

Beschreibung

2

jede Bestellung hat zu einem Zeitpunkt einen definierten Abwicklungs-Status, ein Abwicklungs-Status gilt für eine variable Zahl von Bestellungen

Teil II Betriebliche Informationssysteme

337

jede Bestellung gehört zu einer definierten Bestellart, eine Bestellart gilt für eine variable Zahl von Bestellungen Aus den im Beispiel angeführten NSA erkennt man, daß in derartigen Entitäten wichtige Parameter zur Steuerung der Programmlogik hinterlegt werden können. Das System wird so sehr flexibel, weil Änderungen der Funktionalität nicht Programmänderungen bedingen, sondern lediglich Änderung der in diesen Entitäten hinterlegten Attributwerte, also gewissermaßen nur die Änderung von Stammdaten. Wenn Anwendersoftware im Sinne des nur andeutungsweise skizzierten Beispiels zur Bestellart konzipiert (parametrisiert) ist, kann sie leicht an wechselnde Anforderungen angepaßt werden. Nach diesem Prinzip kann aber auch Standardsoftware von sehr großem Funktionsumfang erstellt werden, die durch Setzen der Parameter individuellen Anforderungen angepaßt wird. Ein Beispiel dafür ist das Produkt des Marktlührers SAP R/3 (aber auch schon R/2). Die Anpassung an individuelle Anforderungen wird dort als "Customizing" bezeichnet. Wir gehen nun auf die Darstellung von Wareneingängen ein. Wenn es zu einer Bestellung grundsätzlich einen Wareneingang und zu einer Bestellposition grundsätzlich eine Wareneingangsposition gibt, sind die Attribute des Wareneingangs Attribute der Bestellung, d. h. •

in die Bestellung sind als Attribute beispielsweise Beleg-Nr. und Datum des Wareneingangs aufzunehmen,

•

in die Bestellposition ist als Attribut beispielsweise die gelieferte Menge aufzunehmen.

Abb. II-3.4-24: ERD Bestellwesen mit Wareneingängen

338

3 Software Engineering

Dies wäre aber keine realitätsgerechte Lösung, weil mit Teilliefeningen sowohl zu einer Bestellung als auch zu einer Bestellposition gerechnet werden muß. Wir fuhren daher eine neue Entität "Wareneingang" ein, die der Bestellung gemäß Abbildung II-3.3-24 zugeordnet ist, und analog eine Entität "Wareneingangsposition".

Entität

Beschreibung

Wareneingang

enthält die Kopfdaten eines Wareneingangs (die also für den gesamten Wareneingang gelten), d. h. einer vollen, Teil- oder Restlieferung zu einer Bestellung PS: Wareneingangsnummer NSA: Datum des Wareneingangs, Lieferscheinnummer des Lieferanten (Die Bestellnummer wäre Fremdschlüssel im Sinne des relationalen Modells)

Wareneingangsposition

enthält die Daten einer Wareneingangsposition, d. h. einer vollen, Teil- oder Restlieferung zu einer Bestellposition PS: Wareneingangsnummer + Wareneingangspositionsnummer NSA: gelieferte Menge

Beziehung

Beschreibung

3

zu einer Bestellung gibt es eine variable Zahl von Wareneingängen, ein Wareneingang gehört zu genau einer Bestellung

4

zu einer Bestellposition gibt es eine variable Zahl von Wareneingangspositionen, eine Wareneingangsposition gehört zu genau einer Bestellposition

5

ein Wareneingang hat ein variable Zahl von Wareneingangspositionen, eine Wareneingangsposition gehört zu genau einem Wareneingang

Gemäß der Forderung nach redundanzfreier Darstellung im Datenmodell dürfen ableitbare Daten nicht dargestellt werden. Der Zyklus Bestellung - Bestellposition - Wareneingangsposition - Wareneingang erweckt den Eindruck, daß hier ableitbare Daten dargestellt sind. Dies ist aber nicht der Fall: Wenn zum Ausdruck gebracht werden soll, daß ein Wareneingang mit den zugehörigen Positionen immer zu genau einer Bestellung gehört (was wir unterstellen - wir lassen also keine Zusammenfassung der Lieferung auf mehrere Bestellungen in einem

Teil II Betriebliche Informationssysteme

339

Wareneingang zu), ist keine der Beziehungen im Zyklus ableitbar bzw. redundant. Die letzte Erweiterung unseres Fallbeispiels im Interesse von Realitätsnähe bezieht sich auf die Bestandsführung. Im einfachsten Falle könnte man den Lagerbestand als Attribut des Artikels sehen, doch würden damit wesentliche Informationen verlorengehen, beispielsweise: •

Die Darstellung der Chronologie der Bestandsentwicklung,

•

die Erfassung der Bestandsführung mit verteiltem Lager,

•

der Nachweis der Herkunft von Bestandspositionen von Produkten im Interesse der Qualitätssicherung (und zur Erleichterung der Bearbeitung von Reklamationen).

•

Wir wollen nun die folgenden Forderungen als gegeben annehmen und ihnen durch das Datenmodell Rechnung tragen:

•

Bestände eines Artikels setzen sich aus Lagerbestandspositionen zusammen. Lagerbestandspositionen eines Artikels können verteilt auf mehrere Lagerorte (Palettenstellplätze, Halle-Regal-Platz im Regal usw.) geführt werden.

•

Lagerbestandspositionen resultieren aus • • Lagerzugangspositionen, die aus Wareneingangspositionen stammen und deren Herkunft über die Kette Wareneingangsposition - Wareneingang Bestellung - Lieferant oder Wareneingangsposition - Bestellposition - Bestellung - Lieferant nachgewiesen werden kann, und • • Lagerabgangspositionen (Lagerentnahmen).

•

Aus organisatorischen Gründen können Wareneingangspositionen auf mehere Lagerorte verteilt werden und so zu mehreren Lagerbestandspositionen führen.

•

Lagerbestände werden nach Qualität klassifiziert (Reinheit, Farbton, Charge, Verwendungsmögllichkeit usw).

Wir kommen für den nun diskutierten Teil des Datenmodells zum ERD gemäß Abbildung II-3.3-25.

340

3 Software Engineering

Abb. II-3.3-25: ERD Bestandsführung mit verteiltem Lager und Herkunftsnachweis Enti tat

Beschreibung

Lagerzugangsposition

enthält die Daten eines Zugangs an einen Lagerort aus einer Wareneingangsposition PS: Wareneingangsnummer + Wareneingangspositionsnummer + laufende Nummer NSA: Zugangsmenge

Lagerort

enthält die Stamminformationen des Lagerorts PS: Lagerort-Schlüssel NSA: Lagerort-Bezeichnung, Lage/Koordinaten, Fassungsvermögen, Zugänglichkeit

Qualitätsklasse

enthält die Stamminformationen der Qualitätsklassifikation PS: Qualitätsklassen-Schlüssel NSA: Qualitätsklassen-Bezeichnung, Qualitätsmerkmale (Reinheit, Farbton, Charge, Verwendungsmögllichkeit usw)

Teil II Betriebliche Informationssysteme

341

Lagerabgangsposition

enthält die Daten eines Lagerabgangs PS: Beleg-Nr. des Lagerabgangs NSA: Menge (Bezug zum Verursacher der Entnahme wird hier nicht verfolgt)

Beziehung

Beschreibung

3

zu einer Wareneingangsposition gibt es eine variable Zahl von Lagerzugangspositionen (bedingt durch die Vertreilung der Wareneingangsposition auf Lagerorte), eine Lagerzugangsposition stammt immer aus genau einer Wareneingangsposition

4

eine Lagerzugangsposition lagert immer an genau einem Lagerort, ein Lagerort kann eine variable Zahl von Lagerzugangspositionen aufnehmen

5

eine Lagerzugangsposition ist immer von genau einer definierten Qualitätsklasse, zu einer Qualitätsklasse kann es eine variable Zahl von Lagerzugangspositionen geben

6

zu einer Lagerzugangsposition gibt es eine variable Zahl von Lagerabangspositionen , eine Lagerabangsposition gehört immer zu genau einer Lagerzugangsposition

Der "lange" Weg vom Artikel zu den Lagerbeständen des Artikels bedeutet für das physische Datenbankdesign, daß man die Relationen nicht 1:1 in Datenbanktabellen umsetzen wird, sondern daß man wohl in die Lagerzugangsposition auch die Artikelnummer als Fremdschlüssel übernehmen wird, um schneller die Verknüpfung zwischen dem Artikel und seinen Beständen herstellen zu können. Eine Beziehung zwischen Artikel und Lagerzugangsposition im ERD wäre aber nicht korrekt, weil sie ableitbar wäre. Um das gesamte Fallbeispiel zusammenzufassen, zeigen wir als Abbildung II3.3-26 das Gesamt-ERD ohne die Entität "Zeitachse". Es wurde mit dem CASETool (vgl. unten Abschnitt 3.7) IEW/Analysis erstellt und bietet zugleich in Verbindung mit den vorhergehenden Abbildungen noch einmal die Gegenüberstellung der häufigsten Darstellungsweisen von ERD.

342

3 Software Engineering

w oo 5 . 2o s•

Q

m Vi

M ' hatSaiiuneUconto

o CD U o(N I r-i

bietet an

gehört zu

Teil II Betriebliche Informationssysteme

343

3.4 Funktionsmodellierung 3.4.1 Probleme der Funktionssicht in Informationssystemen Die hier zu untersuchende Funktions- und Prozeßsicht geht von der in Abschnitt 2 zur Architektur betrieblicher Informationssysteme genannten Voraussetzimg aus, daß Funktions-, Daten-, Organisations- und Steuerungssicht die Grundlage der Entwicklung derartiger Informationssysteme sind.Bezogen auf das in Abb. II2.2-4 enthaltene Schema sind die hier zu betrachtenden Probleme in das Fachkonzept der Steuerungs- und der Vorgangs- oder Funktionssicht einzuordnen. Der Begriff der Funktion wird, wie viele andere Begriffe in Betriebswirtschaft, Informatik u.a. Wissensgebieten auch, leider nicht einheitlich benutzt. In unserem Verständnis soll er im Sinne der Vorgangssicht auf einen Geschäftsprozeß (siehe Abb. II-2.2-2) als Arbeitsaufgabe, Aktivität, bzw. Tätigkeit betriebswirtschaftlichen Inhalts aufgefaßt werden.Ein gesamter Geschäftsprozeß kann also als komplexe Funktion angesehen werden. Ausgehend von einer zumeist relativ allgemein beschriebenen Ausgangssituation zum Vorgang macht die Funktions- und Prozeßsicht somit Struktur und Inhalt betriebswirtschaftliche Aufgaben und die Tätigkeiten zu ihrer Lösung einschließlich der dabei vorhandenen bzw. aufzubauenden wechselseitigen Verflechtungen sichtbar.

Abb. II-3.4-1: Prinzip der Funktionssicht Die Abb. II-3.4-1 zeigt einen Ausschnitt der betriebswirtschaftlichen Funktionen eines Unternehmens in ihrer statischen hierarchischen Struktur, die die zur Realisierung der globalen Unternehmensziele erforderlichen Aufgabenkomplexe zum Inhalt haben. Das in der Abb. II-3.4-2 enthaltene Funktionsschema stellt die funktionellen Zusammenhänge, die sich für die Bestandsführung erforderlich machen, ohne hierarchische Beziehungen dar.

344

3 Software Engineering

Abb. II-3.4-2: Funktionsschema der Bestandsführung

Ziel der

Funktionsmodellierung

Ziel der Funktionsmodellierung ist es, die in der Praxis sehr komplexen Aufgaben- und Tätigkeitssysteme von Unternehmen in eine beherrschbare Anzahl von präzise voneinander abgegrenzten Elementen aufzulösen. Diese Elemente sind dabei gleichzeitig durch definierte Schnittstellen miteinander zu verbinden. Mit dieser Verfahrens- und Darstellungsweise soll die Strakturierung, Detaillierung und damit das Beherrschbarmachen eines großen und komplexen betrieblichen Aufgabensystems in einer funktionsfähigen Struktur erreicht werden. Seine Komplexität wird dadurch, wie im Abschnitt 1 begründet, reduziert. Diese in praktischen betriebswirtschaftlichen Aufgabensystemen a priori gegebene sehr große Komplexität in einer Vielzahl von Systemelementen hat zur Folge, daß •

sie schwer zu überschauen und zu verstehen sind,

•

sie wachsende Fehlerraten verzeichnen,

•

ihre Beherrschung durch Menschen darunter leidet, daß in der Regel ein Mensch nur 5 - 9 Elemente simultan auffassen kann. Durch eine Reduzierung der Komplexität wird daher angestrebt:

•

eine Aufgabe von hoher Komplexität in mehrere Teilaufgaben geringerer Komplexität, die getrennt einfacher zu lösen sind, zu zerlegen,

Teil II Betriebliche Informationssysteme

345

•

die Vielzahl an Lösungselementen und die vielfältige Beziehungen zwischen den Elementen in einer komplexen Lösung überschaubar zu machen und beherrschbar zu verteilen,

•

durch getrenntes Bearbeiten weniger Fehler zu verursachen,

•

durch das getrennte Lösen aller Teilaufgaben letztendlich die Gesamtaufgabe zu lösen.

Unternehmensfunktionsmodell Das Funktionsmodell eines Unternehmens ist eine strukturierte Form der Zusammenstellung aller Funktionen des Unternehmens. Mit Hilfe des Unternehmensfunktionsmodells (UFM) wird dokumentiert, welche Aufgaben des Unternehmens im einzelnen gelöst werden müssen, um die unternehmerischen Zielstellungen zu erreichen. Damit ist die Konstruktion des Unternehmensfunktionsmodells eine strategische unternehmerische Aufgabe. Sie stellt für das zu modellierende Informationssystem im Zusammenhang mit dem Computereinsatz im Unternehmen eine Zielgröße dar, an die eine ständige Annäherung erfolgt, die sich jedoch nie vollständig erreichen läßt. Inhalt der

Funktionsmodellierung

Inhaltliche Aufgabe der Funktionsmodellierung ist es, die im Pflichtenheft formulierten Anforderungen an die zu erreichenden Leistungen des Informationssystems in Funktionen zu fixieren. Die Ergebnisse der Funktionsmodellierung müssen dazu beschreiben: •

die Zusammensetzung des Informations- und Kommunikationssystems aus Funktionen als seinen aktiven Komponenten,

•

das inhaltliche Zusammenwirken und die Abhängigkeiten der Funktionen über entsprechende Schnittstellen (Input-/ und Output-Daten), woraus sich Beziehungen zum Datenmodell (siehe Abschnitt 3.3) ergeben,

•

die Anforderungen an die Ausfuhrung der einzelnen Funktionen (Transformation von Input- zu Outputdaten als interne Leistung und Leistung gegenüber den Anwendern),

•

die zeitlichen Abhängigkeiten zwischen verschiedenen Funktionen als Ablauffolge,

•

Entscheidungskompetenzen gegenüber nachgelagerten Funktionen.

Die interne Ablauflogik der Funktionen wird von der Funktionsmodellierung als Fachkonzept im allgemeinen nicht beschrieben. Sie ist Gegenstand des weiterführenden DV-Konzeptes und der darauf aufbauenden Implementierung.

346

3 Software Engineering

Eine spezielle Problemstellung der Funktionsmodellierung besteht in der Ableitung der Funktionen, deren eindeutige Zuordnung nicht gegeben ist, weil •

eine Funktion als die Teilleistung des Informationssystems einen oder mehrere Arbeitsgänge von Anwendern unterstützen kann,

•

ein Arbeitsgang des Anwenders jedoch auch durch eine oder mehrere Funktionen des Informationssystems unterstützt werden kann.

Solche relativ allgemeinen Funktionen lassen sich also nicht immer zuordnen, was sowohl für ihre Ableitung, die Zusammenfassung zu Funktionsgruppen, ihre Einordnung in das Beziehungsgefuge der Funktionen und die Festlegung der Verantwortlichkeit problematisch ist. Die theoretisch richtige Herangehensweise wäre, eine Betrachtung der Funktionen zuerst unabhängig von den damit befaßten Stmktureinheiten vorzunehmen. Dies stößt in der Praxis auf erhebliche Schwierigkeiten, da die Bearbeitung funktioneller Inhalte sofort mit der möglichen Konsequenz späterer Organisationsanpassungen verbunden wird. Hieraus resultieren oft erhebliche Vorbehalte. Problematisch ist auch die Zuordnung solcher Funktionen, die sich nicht aus der Anwendersicht und deren Anforderungen direkt ergeben, sondern die ihren Ursprung in der erforderlichen systeminternen Organisation des Informationssystems selbst haben (z.B. erforderliche Kontrollen/Prüflingen). Als Anforderungen an die Ergebnisse der Funktionsmodellierung stehen: •

sie müssen für alle individuellen Sichten der beteiligten Entwickler die erforderlichen Informationen vollständig bereitstellen,

•

sie müssen für Entwickler und Nutzer gleichermaßen verständlich sein,

•

sie müssen die Sachverhalte eindeutig und widerspruchsfrei darstellen,

•

der Feinheitsgrad muß für die Funktionsbeschreibung und ihre Prüfung ausreichend, aber nicht mit Realisierungsdetails überfrachtet sein.

3.4.2 Arbeitsweisen der Funktionsmodellierung Das Ziel der Funktionsmodellierung besteht, wie schon mehrfach betont, darin, sehr komplexe Aufgaben- und Tätigkeitssysteme in eine beherrschbare Anzahl von präzise voneinander abgegrenzten Elementen aufzugliedern und diese dabei gleichzeitig durch exakt definierte Schnittstellen miteinander zu verbinden. Wie schon im Abschnitt 1.3.1 angerissen, gibt es dafür zwei prinzipiell mögliche Verfahrensweisen: 1. Top-Down-Strategie als Dekomposition, bei der durch die analytische Tätigkeit des Zerlegens eines Ganzen (Gesamtsystem) die Teile (Einzelelemente) abgeleitet werden, 2. Bottom-Up-Strategie

Teil II Betriebliche Informationssysteme

347

als Komposition, bei der durch die synthetische Tätigkeit des Zusammenfuhrens von Teilen (Einzelelementen) das Ganze (Gesamtsystem) konstruiert wird. Top-down-Strategie Bei der Top-down-Vorgehensweise erfolgt die Dekomposition, bei der durch das Zerlegens eines Ganzen in Teile ausgehend vom Gesamtsystem die Einzelelemente abgeleitet werden, d.h. es wird von einem Gesamtsystem als der zu lösenden Gesamtaufgabe ausgegangen.Die Bearbeitung wird von der Gesamtaufgabe als der obersten Ebene bis hin zu den Elementarfunktionen als der untersten Ebene vorgenommen. Die dabei vorzunehmende schrittweise Verfeinerung wird zumeist in einem Hierarchiediagramm dargestellt, wobei auf jeder Hierarchieebene durch weiteres Aufgliedern von Elementen in weiterer Subelemente die Bearbeitung im Sinne der Funk-tionsteilung erfolgt. Die Anzahl der Gliederungsebenen kann dabei in Abhängigkeit von der Komplexität der Aufgabenstellung sehr unterschiedlich sein.Unter dem Aspekt der Beherrschbarkeit durch Entwickler und Nutzer ist eine Auflacherung eines Elementes in mehr als sieben nachgeordnete Elemente nicht sinnvoll, weil damit die menschliche Auffassungsfähigkeit überfordert wird. Die Abb. II-3.4-3 stellt das Prinzip der Top-down-Verfeinerung an ausgewählten Funktionen der Materialwirtschaft dar, wobei aus Gründen der Übersichtlichkeit nur einige Funktionen beispielhaft aufgeführt sind. Die dabei benutzte Vorgehensweise ist eigentlich selbsterklärend: Aus der Gesamtaufgabe Materialwirtschaft werden auf der nächsten Ebene die vier Teilfunktionen Verwaltung der Stammdaten, Bestandsführung, Einkauf und Rechnungsprüfung spezifiziert. Aus der Funktion Einkauf werden wiederum auf einer nächsten Ebene die drei Subfiinktionen Zusammenarbeit mit Lieferanten, Bestellbearbeitung und Einkaufsinformationssystem gebildet. Jede dieser Subfiinktionen wird dann wieder in ihre eigenen Teilfunktionen zerlegt, was bei der Bestellbearbeitung zu den Teilfunktionen Bestellanforderungen, Bestellabwicklung und Bestellüberwachung führt. Dieser Zerlegungsprozeß wird fortgesetzt, bis bei jedem entstandenem Zweig eine weitere Aufteilung nicht mehr sinnvoll möglich ist. Die Teilung eines Elementes in untergeordnete Elemente erfolgt hierbei also unter dem Gesichtspunkt des logischen Zusammenhanges Ganzes - Teil. Andere Gesichtspunkte der Bearbeitung der Aufgaben, wie z.B. die zeitliche Reihenfolge der einzelnen Teilaufgaben, der inhaltliche Umfang der Elemente oder programmtechnische Fragen der Gliederung in Modulen u.ä. spielen in dieser Phase noch keine Rolle.

348

3 Software Engineering

Problematisch bei dieser Strategie ist, daß es keine feststehenden Kriterien für die Zerlegung gibt und es oft eine Ermessensentscheidung ist, wann auf eine neue Stufe überzugehen ist.

Abb. II-3.4-3: Prinzip der Top-down-Verfeinerung

Bottom-up-Strategie

Die Bottom-up-Vorgehensweise ist eine andere, allerdings weniger benutzte Arbeitsweise. Bei ihr werden, in Umkehrung des Top-down-Vorgehens, ausgehend von der untersten Hierarchieebene durch Aggregation von elementaren

Teil II Betriebliche Informationssysteme

349

Aufgaben bis zur Spitze des Funktionsbaumes immer komplexere Funktionen erzeugt. Als Komposition, bei der durch das Zusammenfuhren von Teilen zum Ganzen ausgehend von den Einzelelementen das Gesamtsystem aggregiert wird, wird damit letztlich ebenfalls die Gesamtaufgabe in ihren Bestandteilen gelöst. Charakteristik von Funktionen In Anlehnung an Scheer [Sce95] ist zu Funktionen festzustellen: •

eine Funktion enthält eine betriebswirtschaftlich-fachliche Aufgabe bezüglich eines betrieblichen Objektes mit dem Ziel des Erreichens von Unternehmenszielen;

•

alle wichtigen Teilaufgaben sind dazu als Funktionen einzeln und explizit darzustellen; die implizite Darstellung durch reine Erwähnung innerhalb einer anderen Funktion ist inkonsequent und gefährlich, weil damit die erforderliche spätere konkrete Ausarbeitung der nur erwähnten Funktion vergessen werden kann;

•

eine Funktion ist eine Soll-Leistung, die durch entsprechende Prozeßaktivitäten erreicht wird;

•

der Umfang der Beschreibung von Funktionen reicht von der anfänglichen einfachen Benennung bis zur späteren umfangreichen Beschreibung des Inhaltes, d.h. auch die Dokumentation entwickelt und vervollkommnet sich;

•

es erfolgt eine Trennung von Funktion und funktionserfüllender Struktur;die Funktion verbirgt ihren inneren Arbeitsablauf, nur das Verhalten nach außen wird sichtbar;

•

Funktionen beziehen sich auf Informationsobjekte, zu denen eine auszuführende Tätigkeit angegeben wird (Bestellung auslösen, Rechnung prüfen) beziehen; das bearbeitete Informationsobjekt muß im entsprechenden Datenmodell als Cluster, Entity-/Beziehungstyp oder Attribut enthalten sein;

•

Funktionen können auf unterschiedlichen Hierarchieebenen beschrieben werden, wobei der Begriff „Funktion" überall verwendet wird;

•

Funktionen auf höheren Verdichtungsstufen (in der Nähe der Spitze der Hierarchie) repräsentieren größere Aufgabengruppen, die als Sammelbezeichnung verwendet werden (Finanzierung, Kostenstellenrechnung, Bestellwesen).

Elementarfunktionen In den entstandenen Funktionshierarchien sind die sogenannten Elementarfunktionen diejenigen, die auf der jeweils untersten Hierarchieebene eines Zweiges stehen. Dies muß nicht unbedingt die allerunterste Hierarchieebene des gesamten Funktionsbaumes sein. Es ist auch möglich, daß die Dekomposition eines Zweiges schon auf einer Ebene in der Mitte der Hierarchie beendet ist, weil keine weitere Zerlegung erfolgt.

350

3 Software Engineering

Eine elementare betriebswirtschaftliche Funktion ist somit eine Aufgabe bzw. Teilaufgabe, die nicht weiter sinnvoll aufgeteilt werden kann und die als solche insgesamt vollständig ausgeführt werden muß. Elementarfunktionen sind also solche Funktionen, • • •

die aus betriebswirtschaftlicher Sicht sinnvoll nicht weiter zerlegbar sind, deren Bearbeitung im allgemeinen an einem Arbeitsplatz erfolgt, die eine festgelegte Ablaufstruktur ohne Bearbeitungsalternativen besitzen.

A usfiihrungsanforderungen Für die auf die beschriebene Art und Weise entwickelten Funktionen müssen als Ausfuhrungsanforderungen eine Reihe von Aspekten herausgearbeiteten werden: •

Ausfilhrungsart, in Abhängigkeit von den erforderlichen Reaktions- und Antwortzeiten sowie im Zusammenhang mit den Eingriffsmöglichkeiten des Nutzers in den Ablauf der jeweiligen Funktionen:

• • Dialogfunktionen laufen synchron mit der Tätigkeit des Benutzers ab und liefern diesem unmittelbar nach ihrer Beendigung das Ergebnis. Aus der Sicht der Nutzer sind dazu die Forderungen bezüglich durchschnittlicher und maximaler Antwortzeiten zu erfassen. • • Batchfunktionen laufen asynchron zu den Arbeiten der Benutzer und liefern diesen die Ergebnisse erheblich (Stunden bis Tage) später; aus der Sicht der Nutzer sind die Forderungen bezüglich einzuhaltender Termine, maximaler Bearbeitungszeiten und der Zeiten zwischen Anfor-derung und Ergebnisbereitstellung vorzugegeben. • • Manuelle Funktionen werden zur Komplettierung des Funktionsumfanges und wegen der erforderlichen Einordnung in das gesamte Funktionsmodell ebenfalls benannt und eingeordnet. •

zeitliche Abhängigkeit zu anderen Funktionen, insbesondere die Parallelität, d.h. die Möglichkeit, unterschiedliche Funktionen gleichzeitig ausführen zu können: • • für Dialogfunktionen wird damit festgelegt, ob sie jeweils nur voneinem Nutzer oder von mehreren Nutzern gleichzeitig (parallel) ausgeführt werden können. • • bei datenverändernden Funktionen ist für die systemtechnische Umsetzung darauf zu achten, daß durch Zugriffssperren organisiert werden muß, daß Inkonsistenz der Daten oder

Teil II Betriebliche Informationssysteme

351

Verklemmungen durch gleichzeitigen ändernden Zugriff vermieden werden. • • für alle Funktionen ist die mögliche zeitliche Parallelität mit anderen Funktionen, die zu eventuellen Störungsmöglichkeiten führen kann, auszuschließen (z.B. bei Datenerfassungen, Transporten aus anderen Verarbeitungen, erforderlichen Verbuchungen). •

Datenschutz/Datensicherung zur Gewährleistung von technischer, organisatorischer und benutzungsmäßiger Ordnungsmäßigkeit der Funktionen: • • Berechtigung zum lesenden Ausfuhren einer Funktion, • • Berechtigung zum schreibenden Ausfuhren einer Funktion, • «Berechtigung zum Zugriff auf zur Funktion gehörende Daten und Ergebnisse, • • Aufbewahrungsmodalitäten von Belegen und Daten.

•

Inhalt von Schnittstellen, die den Datenaustausch zwischen Funktionen sowie zwischen Funktionen und Umwelt gewährleisten (der in integrierten Systemen praktisch auf dem Weg über Datenbanken hergestellt wird): • • Erforderliche Inputdaten (Quelle, grundsätzlicher Inhalt, ggfls. Eingabegerät), • • Herzustellende Outputdaten (Grundsätzlicher Inhalt, Ziel), • • Regeln/Vorschriften, die zur korrekten Ausführung der Funktion erforderlich sind (Integritätsbedingungen/Prüfvorschriften).

Die Arbeitsweise der Funktionsmodellierung unterstützt damit auch sinnvoll Prinzipien, die für die Softwareentwicklung generell postuliert werden: Arbeitsteilung wird ermöglicht, weil eine komplexe Entwicklungsaufgabe in Teilaufgaben zerlegt wird, die von verschiedenen Bearbeitern gelöst werden können.Das macht Parallelarbeit möglich und verkürzt Entwicklungszeiten, erfordert jedoch eine sehr gute Kommunikation in den Arbeitsteams. Nachnutzbarkeit resultiert aus der klaren funktionellen Abgrenzung, Übersichtlichkeit und leichten Austauschbarkeit. Ein potentiellen Kunden angebotenes Funktionsmodell kann die Bereitschaft zur Nachnutzung fördern.

3.4.3 Module und Modularisierung Die Komplexitätsreduzierung, die als wesentlicher Inhalt der Funktionsmodellierung auf der Fachkonzeptebene eingeordnet ist, wird auch nach dem Erreichen

352

3 Software Engineering

von Elementarfunktionen konsequent weitergeführt. Dem dient im Übergang zur informationstechnologischen Lösung die Modularisierung. Aus den Erläuterungen zu Abb. II-2.2-4 (vgl. Abschnitt 2.2) geht hervor, daß die Einordnung von Modulen in die Ebene des DV-Konzeptes erfolgt, auf der die in der Implementation fortgesetzte Prozeßspezifikation beginnt. Es werden Module erarbeitet, die eine Menge in sich geschlossener und voneinander unabhängiger sowie leicht austauschbarer und wiederverwendungsfähiger Lösungsbausteine darstellen, aus denen sich eine übersichtliche und praktikable Gesamtlösung zusammensetzt. Als Vorteile werden dadurch erwartet: •

durch Modularisierung entsteht eine gut beherrschbare modulare Hierarchie mit eindeutigen Schnittstellen-Beziehungen, die für den Systementwurf und die Softwareprodukte eine geeignete Gliederung darstellen.

•

die enstandene Software wird flexibler, verständlicher, leichter wartbar,

•

fehlerhafte, modifizierte oder neue Teile des Systems sind auswechsel- bzw. einfügbar, ohne andere Bausteine zu verändern,

•

an unterschiedlichen Stellen mehrfach benötigte Aktivitäten werden zur Redundanzminimierung nur einmal wiederverwendungsfähig angelegt,

•

die Schaffung einer integrierten Dokumentation wird unterstützt.

Modulbegriff Eine einheitliche Definition des Begriffs Modul bzw. eine feste Vorschrift für die Konstruktion eines Moduls existiert nicht. In unserem Verständnis ist das Modul ein selbständiger Systembaustein auf der Ebene der Verbindung von Funktionsmodellierung und Implementierung, der durch eine Reihe von Eigenschaften bzw. Inhalten gekennzeichnet ist. Eine Elementarfunktion wird im allgemeinen durch die Abarbeitimg mehrerer zusammenhängendas Module realisiert. Moduleigenschaften sollen sein: •

Modulunabhängigkeit, nach der die Module weitgehend unabhängig voneinander zu gestalten sind; daher sollen an der Leistungserfüllung der Funktion eines Moduls nur eigene Modulbestandteile beteiligt sein; die Unabhängigkeit der Module wird erreicht, indem man die Bindungen innerhalb der einzelnen Module selbst verstärkt und Modulbestandteile nicht an Leistungen anderer Module mitwirken; die definierte Leistimg eines Moduls wird demzufolge immer nur von ihm selbst und nicht (auch nicht teilweise) von anderen Modulen erbracht.

•

Geheimhaltung des Modulinhaltes

Teil II Betriebliche Informationssysteme •

353

Modulinhalte, die in einer Prozeßspezifikation beschrieben sein können, sollen sein: • • eine Folge von Aktionen zur Erfüllung eines funktionalen Hauptzwecks, • • Fehlerbehandlung, • • eine klare Datenschnittstelle als einfache und zugleich möglichst präzise Verbindung des Moduls zur Umwelt.

Datenschnittstelle Die geforderte klare Datenschnittstelle als präzise Verbindung des Moduls zur Umwelt besteht aus • Parameterübergaben bei Modulanfang und -ende, • Benutzungsanweisungen für modulexterne Datenbereiche, • Ein- und Ausgaben über periphere Geräte. Die Datenschnittstellen werden als Export- und Importschnittstelle eines Moduls festgelegt (Prinzip der vollständigen Schnittstellendefinition). Die Exportschnittstelle sagt aus, was das Modul nach außen in das System abgeben kann, wenn es aufgerufen wird. Es stellt dort Funktionen inklusive Parameter zur Verfügung. In der Importschnittstelle beschreibt das Modul ebenfalls in Form von Funktionsköpfen, was es von anderen Modulen des Systems an Hilfestellung zur Erfüllung der eigenen Aufgaben braucht. Geheimhaltung des Modulinhaltes Dadurch, daß an der Schnittstelle nur die Funktionsköpfe nach außen bekannt werden, ist das Geheimhaltungsprinzip des Moduls realisiert. Ziel dieses Prinzips ist es, die Kopplung zwischen den Modulen zu minimieren, d.h. die Unabhängigkeit der einzelnen Module so gut wie möglich einzuhalten. Die Grundidee des auch als „Information hiding" oder Datenkapselung bezeichneten Prinzips sieht vor, daß Datenstrukturen und Module so beschrieben werden sollen, das diese internen Informationen nicht nach außen gehen. Man legt lediglich die Schnittstellen zur Umwelt des Moduls fest, die interne Funktionsweise bleibt verborgen. Mit anderen Worten, Module sollten so entworfen und gehandhabt werden, daß die in einem Modul enthaltene Information (Prozeduren und Daten) für andere Module und natürlich auch andere Nutzer, die diese Information nicht benötigen, unzugänglich ist. Prinzip der schmalen Datenkopplung Zur Wahrung dieses Prinzips der schmalen Datenkopplung müssen Kopplungsmechanismen (Call-Schnittstellen), Schnittstellenbreite (Anzahl der Parameter, Datentyp der Parameterelemente) und Kommunikationsart untersucht werden.

354

3 Software Engineering

Damit wird auch ein Gefuge unabhängiger Module angestrebt, dessen optimale Modularität dadurch erreicht wird, daß nur die zur Erfüllung der Funktion notwendige Informationen ausgetauscht werden. Gleichzeitig sinkt auch die Gefahr, daß Fehler eines Moduls auf andere Module übertragen werden, und die Fehlersuche wird vereinfacht. Modulordnung

und -abhängigkeit

Die Ordnung der Module und ihre prinzipiell beliebige Kombinieibarkeit durch gegenseitigen Aufruf ist eine wichtige Aufgabe in einer Modulhierarchie.Bei einfachen Systemen ist die streng baumorientierte Hierarchie durch die bekannte top-down- bzw. bottom-up-Arbeitsweise auch bei der Modulkonstruktion realisiert. Größere Systeme sind dadurch gekennzeichnet, daß bestimmte Module auf beliebige andere Module zugreifen können, d.h. es sollten auch solche Module direkt erreicht werden, die nicht zur benachbarten Hierarchiestufe gehören. Dies betrifft insbesondere multivalente Funktionen betriebswirtschaftlicher, mathematisch/statistischer oder informationstechnologischer Natur (mathematisch statistische Grundfunktionen, Dialogbausteine, gerätespezifische Funktionen, Tabellen- und Dateiarbeiten etc.), die an verschiedenen Stellen der Funktionshierarchie gleichermaßen benötigt werden und die daher in gesonderten Modulen anzusiedeln sind. Der erforderliche Cross-Zugriff wird durch die Bestimmung der Abhängigkeit zwischen Modulen mit Hilfe der „Benutzt-Relation" von Parnas als günstig gekennzeichnet: „Ein Modul A benutzt eine Modul B, wenn die korrekte Ausfuhrung von B Voraussetzung dafür sein kann, daß A die als seine Aufgabe spezifi zierte Funktion erfüllt." Prozeßspezifikation

Zur Beschreibung des Inhaltes von Elementarprozessen, die in Modulen enhalten sind, wird die Prozeßspezifikation benutzt.Die Beschreibung des Prozesses erfolgt durch die im Abschnitt zur Einführung in die Programmierung vorgestellten Methoden, z.B. Struktogramme oder Pseudocode.Die zum Prozeß gehörigen Daten sind ebenfalls zu beschreiben. Hierzu sollen zweckmäßigerweise Verbindungen zu Datenablagen (siehe 3.4.4.3) oder zur Datenmodellierung (siehe 3.3) genutzt werden. Die Arbeit mit Modulen erfolgt in der Ebene des DV-Konzeptes, auf der die in der Implementation fortgesetzte Prozeßspezifikation beginnt.

Teil II Betriebliche Informationssysteme

355

3.4.4 Darstellungsmittel und -methoden der Funktionsmodellierung Die Auswahl der „richtigen" Darstellungsmittel und -methoden für die Funktionsmodellierung auf der Fachkonzept-Ebene ist eine Entscheidung, die nicht aus rein objektiver Sicht zu treffen ist. Da die unterschiedlichen Methoden jeweils an verschiedenen Stellen andere Stärken und Schwächen haben, ist ein Vergleich zwangsläufig in starkem Maße von subjektiven Präferenzen und Gewohnheiten bei Entwicklern und/oder Anwendern geprägt. In jedem Falle sollte die gewählte Methode eine wirkungsvolle Computerunterstützung durch geeignete Werkzeuge besitzen, damit ihre Handhabung mit dem geringsmöglichen Aufwand erfolgen kann. Damit können sowohl die Entwicklungsarbeiten als auch der Änderungsdienst rationell durchgeführt werden. Als Darstellungsmethoden und -mittel sollen im Weiteren betrachtet werden: • • • •

Funktionsbaum-Darstellung HIPO-Methode Strukturierte Analyse SADT

3.4.4.1

Funktionsbaum-Darstellune

Auf das Darstellungsmittel des Funktionsbaumes wurde in den bisherigen Ausführungen zur Funktionsmodellierung schon mehrfach Bezug genommen. Im Abschnitt 3.4.2 und den Abbildungen II-3.4-1 und II-3.4-3 wurde bereits mit der Verfahrensweise der Funktionsbaum-Darstellung gearbeitet. Funktionsbäume sind für die Darstellung genereller und großer Funktionszusammenhänge prädestiniert. Andere, für die Funktionsmodellierung geforderte Aussagen, z.B. zu Schnittstellen und Ausführungsanforderungen, lassen sich mit ihr nicht darstellen. Im ARIS-Konzept werden auf der Ebene des Fachkonzeptes die betriebswirtschaftlichen Funktionen aus der Beschreibung eines komplexen Geschäftsprozesses heraus als „semantisches Modell" in einem Funktionsbaum gegliedert. Diese Funktionsbäume werden dabei in Abhängigkeit von den angewandten Gliederungskriterien unterschieden in • • •

objekt-orientierte Funktionsbäume, prozeß-orientierte Funktionsbäume, verrichtungs-orientierte Funktionsbäume.

Objektorientierte

Funktionsbäume

werden benutzt, wenn, wie in Abb. II-3.4-4 dargestellt, die Bearbeitung des gleichen Objektes in verschiedenen Funktionen mit unterschiedlichen Verrichtungen erfolgt.

356

3 Software Engineering

Abb. II-3.4-4: Funktionsbaum mit objektorientierter Zerlegung

Prozeßorientierte

Funktionsbäume

werden benutzt, wenn sie, wie in Abb. II-3.4-5 dargestellt, Ergebnisse der Modellierung von Geschäftsprozessen sind. Verbunden durch die Zugehörigkeit zum gleichen Prozeß, erfolgt die Bearbeitung verschiedener Objekte in verschiedenen Funktionen mit unterschiedlichen Verrichtungen. Verrichtungsorientierte

Funktionsbäume

werden benutzt, wenn, wie in Abb. II-3.4-6 dargestellt, die Bearbeitung unterschiedlicher Objekte in verschiedenen Funktionen mit gleichen Verrichtungen erfolgt.

Teil II Betriebliche Informationssysteme

Abb. II-3.4-5: Funktionsbaum mit prozeßorientierter Zerlegung Objekte ändern

^

verrichtungsorientiert übergeordnet | Kundenauftrag ändern ( Fertigungsauftrag' ändern

;

\

Produktionsplan ändern Personaleinsatzplan ändern Prüfplan ändern

N

Abb. II-3.4-6: Funktionsbaum mit verrichtungsorientierter Zerlegung

357

358

3 Software Engineering

3.4.4.2 HIPO-Methode HIPO (Hierarchy Input process Output) ist eine Methode, die in den letzten Jahren vielfach nicht mehr sehr positiv beurteilt wird. Sie kann jedoch für die im Zusammenhang mit den Zielstellungen der Funktionsmodellierung angesprochenen Aufgaben durchaus ausreichende Ergebnisse erbringen, weshalb sie kurz angerissen werden soll: Als Verfahren zur hierarchischen Strukturierung informationeller Prozesse ermöglicht sie die grafische Darstellung von Funktionen, die ein System ausfuhrt.

Abb. II-3.4-7: HIPO-Hierarchiediagramm

Teil II Betriebliche Informationssysteme

359

Weiterhin stellt sie die Beziehungen zwischen Eingabe, Verarbeitungsstufen und Ausgabe dar. In einem ersten Entwurfsschritt werden aus der vorgegebenen Problemstellung Teil- und Unteraufgaben zusammen mit ihren hierarchischen Beziehungen abgeleitet und im Strukturdiagramm festgehalten. Dieses Strukturdiagramm (Abb II-3.4-7) ist praktisch mit einem Funktionsbaum identisch, wie sich unschwer aus dem Vergleich mit dem Funktionsbaum in Abb. II-3.4-3 erkennen läßt. In einem zweiten Entwurfsschritt von HtPO wird für jede Strukturkomponente des Hierarchiediagramms in Übersichts- bzw. Detaildiagrammen die Menge der einzelnen Arbeitsprozesse definiert, die notwendig sind, um diese Aufgabe zu lösen. Dabei werden für jeden Prozeß des Strukturdiagramms die folgenden Details festgelegt: • • •

Input - Section zur Definition der Eingabedaten Process - Section zur Darstellung der Verarbeitungsinhalte Output - Section zur Festlegung der Ausgabedaten

Das Beziehungsgefüge zwischen den 3 Sectionen wird durch Pfeile symbolisiert. Detaildiagramme werden nur für "Blätter" des Strukturbaumes, d.h. für Elementarfunktionen erarbeitet. Mit Detaildiagrammen wird somit die noch vorhandene Komplexität der im Übersichtsdiagramm enthaltenen Sectionen aufgelöst.

3.4.4.3 StructuredAnalysis

(SA)

Mit der strukturierten Analyse steht eine einfache und allgemeinverständliche graphische Darstellungsform für die Entwicklung von Funktionsmodellen zur Verfügung. Entsprechend der bei der Funktionsmodellierung üblichen Vorgehensweise erfolgt dabei eine funktionelle Zerlegung. Bei der SA-Methode wird nach dem topdown-Ansatz von einer komplexen Ausgangssituation und Aufgabenstellung ausgegangen und eine schrittweise Dekomposition über mehrere Stufen vorgenommen. Endpunkt ist die Ebene der elementaren betriebswirtschaftlichen Prozesse, die nicht mehr weiter sinnvoll zerlegbar sind und die durch eine Prozeßspezifikation beschrieben werden können. Im Unterschied zur rein funktionellen Betrachtung und Arbeitsweise bei Funktionsbäumen wird bei der strukturierten Analyse auch eine Bestimmung und Detaillierung der Datenelemente vorgenommen, die dann zum Datenmodell zusammengefasst werden können.In der Einbeziehung der Daten liegt einerseits ein Vorteil, weil dadurch frühzeitig die erforderlichen Zusammenhänge zwischen Daten und Funktionen beachtet werden. Andererseits steigen dadurch Umfang

360

3 Software Engineering

und Kompliziertheit der Arbeiten, was auch mit sinkender Übersichtlichkeit und erhöhtem Änderungsaufwand einhergeht. Modellbeschreibung Die Komponenten der mit Hilfe der strukturierten Analyse erzielte Modellbeschreibung machen die Funktionalität und Datenstruktur mit ihren Schnittstellen sichtbar. Welche konkreten Ausprägungen dabei erreicht werden, ist, wie bei den anderen Methoden auch, sehr stark von den Vorstellungen und Wünschen der Anwender abhängig. Eine mit der strukturierten Analyse erstellte Modellbeschreibung besteht aus •

Datenilußdiagrammen zur Darstellung von fließenden Datenmengen, die in Funktionen verarbeitet, in Datenablagen gespeichert und mit Datenquellen und -senken ausgetauscht werden;

•

einem Datenlexikon zur Dokumentation und Verwaltung der Elemente von Datenflüssen und -ablagen, die in den Datenilußdiagrammen enthalten sind;

•

Prozeßspezifikationen zur Beschreibung des Inhaltes von Elementarprozessen.

Datenfluß-Diagramme

(DFD)

Die mit DFD darzustellenden Datenflüsse sind informationelle Verbindungen, die durch Nachrichten, Belege u.a. Komponenten den Austausch innerhalb des zu modellierenden Systems und auch mit seiner Umwelt realisieren. Elemente dieser graphischen Darstellung sind: •

Funktionen, die als einfache Kreise dargestellt werden und die Verarbeitungsprozesse der Daten beschreiben. Sie sind als Datenquelle Entstehungsort als auch als Datensenke Endpunkt von Datenflüssen (bzw. Informationsflüssen oder Infoflüssen).

•

Sender/Empfanger von Daten, die als einfache Rechtecke dargestellt werden, sind die Schnittstellen der zu modellierenden Aufgabe zu ihrer Umwelt. D.h. diese auch als Terminatoren bezeichneten Datenquellen und -senken gehören selbst nicht zum Modellsystem, stehen jedoch als Personen, Organisationseinheiten usw. mit diesem in enger informationeller Beziehung.

•

Datenflüsse, die durch Pfeile dargestellt werden, sind gerichtete und bezeichnete Darstellungen der Bewegungen von Datenmengen zwischen Funktionen bzw. auch von und zu Terminatoren und Datenspeichern. Existieren zwischen zwei Funktionen unterschiedliche Datenflüsse, sind zwischen Funktionen auch mehrere Datenfluß-Pfeile zulässig.

•

Datenablagen, die in Form von zwei parallelen Strichen dargestellt werden, sind die verschiedensten in betrieblichen Informationssystemen vorkommenden Informationsbestände (Datenbasen), wie z.B. Dateien, Karteien, Archive. Eine genauere inhaltliche oder technische Spezifizierung der jeweils benutz-

Teil II Betriebliche Informationssysteme

361

ten Speichermedien erfolgt in der strukturierten Analyse nicht. In der Datenmodellierung (vgl. Abschnitt 3.3) wird ihr Inhalt z.B. mit ERM beschrieben. Vorgehensweise Als Vorgehensweise der strukturierten Analyse hat sich, wie zumeist in der Funktionsmodellierung, die schrittweise Top-Down-Strategie bewährt, d.h. die Zerlegung der Funktionen in Teilfunktionen, die wiederum auch zu neuen Infoflüssen fuhren. Daraus ergibt sich eine hierarchische Struktur mehrstufiger Dateniluß diagramme: • Kontextdiagramm In einem ersten Schritt werden für die Gesamtaufgabe in einem Diagramm die Schnittstellen mit der Umwelt fixiert, d.h. die ein- bzw. ausgehende Informationsflüsse mit den dazugehörigen Terminatoren als Sendern bzw. Empfängern. Das hierbei entstehende Diagramm, in dem noch keine Datenablagen enthalten sind, wird auch als Kontextdiagramm bezeichnet. Abb. II-3.4-8 zeigt beispielhaft und vereinfacht ein Kontextdiagramm der strukturierten Analyse zur betriebswirtschaftlichen Funktion „Materialwirtschaft". Als Terminatoren fungieren neben den Lieferanten die anderen betrieblichen Funktionen Produktion, Buchhaltung und Absatz, die über die benannten Datenflüsse mit der Funktion Materialwirtschaft verbunden sind.

Abb. II-3.4-8: Kontextdiagramm der strukturierten Analyse zur Funktion „Materialwirtschaft" • Datenflußdiagramm-Ebene 0 In einem zweiten Schritt erfolgt das Verbinden der Datenmengen und -flüsse aus dem ersten Schritt mit den dazu erforderlichen Verarbeitungsvorgängen. Das

362

3 Software Engineering

hieibei entstehende Diagramm der ersten noch sehr allgemeinen Ansätze der Funktionen des Modells wird auch als Parentdiagramm bezeichnet. In Datenflußdiagrammen, die auf der Ebene 0 angelegt werden, sind dann keine Terminatoren mehr enthalten. Die Abb. II-3.4-9 zeigt ein Datenflußdiagramm der Ebene 0, in dem die Funktion Einkauf in ihre Teilfunktionen Zusammenarbeit mit Lieferanten, Bestellbearbeitung, Einkaufsinformationssystem aufgesplittet wurde (vgl. Abb. II-3.4-3), wobei nun für die folgenden Betrachtungen der Einkauf die Wurzel des Baumes bildet. Als Datenbasis fungieren die Einkaufsdaten, die von den Funktionen benutzt und verändert werden.

Angebot . Li eferantenstammdateiA

Lieferanten

Einkaufsdaten

Abb. II-3.4.-9: Datenflußdiagramm der Ebene 0 für den Einkauf • Datenflußdiagramm-Ebene 1 In weiteren Schritten der beschriebenen top-down-Verfeinerung erfolgt die Detaillierung und Vervollständigung, indem jede Funktion in der genannten Art und Weise wiederum in ihre Teilfunktionen zerlegt wird. Deren graphischeDarstellung wird auch als Childdiagramm bezeichnet und in der Hierarchie von Datenfluß-Diagrammen eingeordnet

Teil II Betriebliche Informationssysteme

363

Die Abb. II-3.4-10 zeigt ein Datenilußdiagramm der Ebene 1, in dem wiederum die Teilfunktion Bestellbeaibeitung aus der vorhergehenden Ebene (Abb. II-3.49) in ihre Subfunktionen Bestellanforderungen, Bestellabwicklung und Bestellüberwachung aufgesplittet wurde.

Marktinformationen

Abb. II-3.4-10: Datenilußdiagramm der Ebene 1 für die Bestellbearbeitung • Datenflußdiagramm-Ebene n (Elementarfunktion) Das Ende der Detaillierung ist erreicht, wenn auf der Ebene der elementaren betriebswirtschaftlichen Prozesse die weitere Zerlegung in Subfunktionen nicht mehr sinnvoll ist.

Kontextdiagramm

Ebene 0

Abb. II-3.4-11: Diagrammhierarchie der strukturierten Analyse

364

3 Software Engineering

3.4.4.4 Structured Analysis and Design Techniques {SADT) Der SADT-Entwurfsprozeß läuft so ab, wie es in den prinzipiellen Forderungen der Funktionsmodellierung postuliert wurde: •

er beginnt mit einer Darstellung des Gesamtsystems (A-O-Diagramm),

•

diese Gesamtdarstellung wird durch wiederholte Aufspaltung von Aufgaben in Teilaufgaben top-down verfeinert (Ax-Diagramme: A-l/2/3/...),

•

der Zerlegungsprozeß ist beendet, wenn Elementarfunktionen erreicht sind, d.h. die Teilaufgaben nicht mehr teilbar und klein genug sind, um in Programme umgesetzt zu werden.

SADT-Diagramme Die SADT-Diagramme verwenden zu Darstellung eine sehr einfache Symbolik, die auch ohne spezielle Tools mit einfachen graphischen Systemen realisiert werden kann: •

ein rechteckiges Kästchen als Symbol für Tätigkeit, die im allgemeinen durch das entsprechende Verb bezeichnet wird;

•

einen Pfeil als Symbol für das Hießen von Daten, aber auch für zu berücksichtigende Voraussetzungen und/oder Randbedingungen, die im allgemeinen durch das entsprechende Substantiv bezeichnet werden.

Die vier Seiten der rechteckigen Kästchen werden mit den an ihnen ankommenden Pfeilen zur Darstellung der Verbindungen der angegebenen Tätigkeit mit ihrer Umwelt benutzt: •

die linke Seite eines Kästchens ist die Inputseite für die Daten, die in die Funktion eingehen und von der angegebenen Tätigkeit benutzt, verbraucht bzw. transformiert werden;

•

die rechte Seite eines Kästchens ist die Outputseite für die Daten, die in der Funktion entstehen, von der angegebenen Tätigkeit erzeugt werden und als Datenfluß die Funktion verlassen;

•

die obere Seite ist für das Einbinden von bei der Funktionsausführung zu berücksichtigenden Steuerungs- und Regelungselementen (Constraints), wie z.B. gesetzliche Bestimmungen, betriebsinterne Vorschriften, Kontrollgrößen, Grenzwerten, Voraussetzungen vorgesehen;

•

die untere Seite wird für die Angabe von für die Funktionsausführung erforderlichen Hilfssystemen und Einrichtungen (Ressourcen), wie z.B. Dateien, Datenbanken, Systemroutinen, Software benutzt.

A-O-Diagramm Entsprechend des Ablaufes der Funktionsmodellierung beim top-down-Vorgehen beginnt der Entwicklungsprozeß mit einer Darstellung des Gesamtsystems als A-

Teil II Betriebliche Informationssysteme

365

O-Diagramm (A-minus-Null-Diagramm), wie in Abb. II-3.4-12 am Beispiel der Bestellbeaibeitung demonstriert. Aus Gründen der Übersichtlichkeit erfolgt eine Reduzierung auf die Inputs II und 12, die Outputs O l , 0 2 und 0 3 sowie den Constraint Cl und die Ressource Rl:

C l Regelungen zur Arbeit mit Lieferanten

Ol Bestellungen an Lieferanten

II Bedarfsanforderungen Bestellbearbeitung

0 2 Bestelldatei zur Überwachung

12 Lieferantenangebote 0 3 Antworten auf Dialoganfragen zum Einkauf

Rl Lieferanten-Datenbank

Abb. II-3.4-12: SADT-A-O-Diagramm zur Funktion „Bestellbearbeitung"

Schwerpunkt dieser Darstellung sind die Beziehungen des zu entwickelnden Anwendungssystems zu seiner Umwelt, im Sinne des Erreichens einer richtigen und vollständigen Erfassung und Gestaltung der In- und Output-Schnittstellen. In den weiteren Entwicklungsschritten ist deren Ausprägung an dieser A-O-Diagramm-Darstellung zu überprüfen. A O-Diagramm Diese Gesamtdarstellung im A-O-Diagramm wird durch die weitere Aufspaltung der Aufgaben in Teilaufgaben nach der top-down-Strategie zerlegt, die in einem neuen Diagramm dargestellt werden. Es entsteht das AO-Diagramm (A-Null) zur Darstellung des ersten Verfeinerungsschrittes mit • neuen Tätigkeitskästchen • neuen internen Datenverbindungspfeilen. In Abb. II-3.4-13 ist die Dekomposition der Aufgabe Bestellbearbeitung in die Teilaufgaben Lieferantenauswahl, Bestellabwicklung und Bestellüberwachung erfolgt. Die Konsistenz des AO-Diagramms zum übergeordneten A-O-Diagramm wird daran geprüft, ob die In- und Outputbeziehungen des AO-Diagramms nach außen

366

3 Software Engineering

mit denen des übergeordneten A-O-Diagramm übereinstimmen. Ist das nicht der Fall, müssen die fehlenden Verbindungen ergänzt werden. C l Regelungen zur Arbeit mit Lieferanten

II Maiktinformationen

•W1 V

LieferantenLiefen auswahl Ol Bestellungen an Lieferanten

12 Lieferantenböililigtin-

Bestellabwicklung

Bestellüberwachung

0 2 Bestelldatei zur Überwachung

03 Mahnungen

M l Lieferanten-Datenbank

Abb. II-3.4-13: SADT-AO-Diagramm mit Subfunktion zur „Bestellbearbeitung" A 1-Diagramm Die mit der Herstellung des AO-Diagramms beschriebene Verfeinerung kann für die neu entstandenen Tätigkeiten in AI-Diagrammen wiederholt werden.

367

Teil II Betriebliche Informationssysteme AO

• •• • ED

•

•

AI

0

A2

J3

• • m Q 0 S A12

A3

| A22

A31

•

A33

0

s

Abb. II-3.4-14 SADT-Diagrammhierarchie Durch die analoge Weiterführung der Detaillierung der neu entstandenen Tätigkeiten in Ax-Diagrammen ergibt sich insgesamt eine Diagrammhierarchie, wie in Abb. II-3.4-14 dargestellt. Dieser hierarchisch organisierte Aufbau ermöglicht sowohl das schrittweise Nachvollziehen des gesamten Verfeinerungsvorganges als auch den direkten Zugriff auf jede gewünschte Detaillierungsebene. Die Grenzen von SADT liegen in Restriktionen der Diagrammsprache: •

zeitliche Beziehungen sind nicht ausdrückbar,

•

die Pfeile sagen nichts aus über die spätere Implementierung von Datenströmen (als physische Datei, Datenbank, Folge von Bildschirm-Masken, Folge von Unterprogrammen). Solche Informationen lassen sich nur über die Benennungen in das Diagramm einbauen. es gibt keine Ausdrucksmittel für programminterne Abläufe, wie z.B. Sequenz, Entscheidung und Wiederholung.

•

Der Vorteil von SADT liegt in der bewußten Beschränkung der Ausdrucksmittel, die den Entwurf im Großen von später zu treffenden Implementierungsentscheidungen hinsichtlich Datenorganisation, Programmlogik usw. separiert. 3.4.4.5 Zusammenfassung zu den Darstellunzsmitteln

und -methoden

An dieser Stelle kann und soll kein exakter Vergleich der vorgestellten Darstellungsmittel und -methoden vorgenommen werden. Es soll lediglich auf eine Reihe von Gemeinsamkeiten verwiesen werden, die sich logischerweise aus dem

368

3 Software Engineering

gemeinsamen Grundanliegen der Darstellung des fachlichen Inhaltes der Funktions- und Prozeßmodellierung ergeben. Bei allen angeführten Darstellungsmitteln und -methoden kommt das Prinzip der Dekomposition bzw. Komposition zur Anwendung, was sich in den jeweiligen Funk-tionshierarchien und den daraus resultierenden Diagrammhierarchien ausdrückt. Die dabei benutzten unterschiedlichen Termini wie • • • •

Hierarchiediagramm/Funktionsbaum/Parentdiagramm, Detaildiagramm/Sohndiagramm/Childdiagramm, Elementarfunktion/Grundftuiktion/Primitivprozess, Datenlexikon/Datenkatalog

sollten nicht darüber hinweg täuschen, daß sie jeweils einen relativ ähnlichen Inhalt besitzen. Damit ist ein Streit um die „besten Darstellungsmittel und -methoden" letztendlich müßig, weil generell mit jedem Darstellungsmittel die gewünschten Ziele erreicht werden können. Die unterschiedlichen Stärken und Schwächen der Mittel und Methoden liegen jeweils an verschiedenen Stellen, was einen echten Vergleich problematisch macht. Bei der Entscheidung für ein anzuwendendes Arbeitsmittel spielen eine Rolle: •

Verständigungsmöglichkeit mit den Personen, die in die erforderliche Kommunikation einbezogen werden müssen,

•

Vorhandensein wirksamer Software-Tools, die die Anwendung von Mittel und Methode unkompliziert und schnell machen,

•

persönliche Prioritäten, die aus Erfahrungen und Sympathien resultieren.

3. 5 Prozeßmodellierung 3. 5. 1 Aufgaben der Prozeßmodellierung Nachdem grundlegende Methoden für die Beschreibung und Entwicklung des Daten- und des Funktionsmodells von Anwendungssystemen besprochen worden sind, kehren wir wieder zur Betrachtung der Geschäftsprozesse zurück. Während im Abschnitt 3.2 bei der Analyse der betriebswirtschaftlichen Ausgangssituation für die Systementwicklung viele Details im Ablauf der Geschäftsprozesse unterdrückt werden konnten und auch nicht in den Vorgangskettendiagrammen erfaßt wurden, so ist jetzt nach einer spezifizierenden Daten- und Funktionsmodellierung eine detaillierte Zusammenführung von Datenobjekten, Funktionen und den sie tragenden Organisationseinheiten zu Ablaufmodellen (Prozeßmodellen) notwendig. In dieser Synthese können einerseits Inkonsistenzen, die durch die getrennte Betrachtung von Daten- und Funktionssicht eventuell entstanden sind, beseitigt und andererseits die präzise Steuerung der Abläu-

Teil II Betriebliche Informationssysteme

369

fe des geplanten Informationssystems entwickelt werden. (Scheer bezeichned daher die Prozeßdarstellungen eines Informationssystems als Steuerungssicht, vgl. Abschn. 2.2). Diese unter dem Aspekt des Softwareengineerings abgeleiteten Aufgaben von Prozeßmodellen sind: • •

•

•

Beschreibung der Geschäftsprozesse als Ausgangspunkt für die Systementwicklung, Zusammenführung der Daten-, Funktions- und Organisationssicht eines Informationssystems zu den in der Software abzubildenden Geschäftsprozessen, sind aktuell auch unter weiteren Gesichtspunkten interessant. So werden im Rahmen der Anpassung von Geschäftsabläufen an neue Anforderungen des Marktes, die Beschreibung der Geschäftsprozesse als Ausgangspunkt für ihre Reorganisation (Geschäftsprozeßoptimierung) und im Rahmen von Softwareentscheidungen, die Beschreibung der Geschäftsprozesse als Grundlage für die Auswahl, Anpassung und Enführung von Standardsoftware benutzt.

Die Verwendung von Geschäftsprozeßmodellen in den genannten Aufgaben wird durch angebotene Softwaretools erleichtert, die die Aufstellung, Bearbeitung, Speicherung und den Vergleich von Prozeßmodellen unterstützen. Für eine große Zahl von Branchen wurden inzwischen Referenzmodelle für die wichtigsten Geschäftsprozesse entwickelt (vgl. z.B. [Sce94]].

з. 5. 2 Darstellung von Geschäftsprozessen Entsprechend der Begriffsbestimmung im Abschnitt 2.2 - Geschäftsprozeß als ereignisgesteuerter Ablauf betrieblicher Funktionen in Form von Vorgangsketten - wird hier als adäquate Beschreibungsform die ereignisgesteuerte Prozeßkette (EPK) vorgestellt. Bezüglich anderer Darstellungen wie z. B. dem objektorientierten SOM-Ansatz von Ferst! und Sinz ([VOB96], S. 47ff.) und der INCOME-Methode von Stucky и.a. ([VOB96], S. 141ff.) wird auf die angegebene Literatur verwiesen. Als Grundelemente der EPK werden zur Abbildung konkreter betrieblicher Funktionen der Objekttyp Funktion, zur Abbildung der Voraussetzungen für den Start einer Funktion bzw. für das Ergebnis einer Funktion der Objekttyp Ereignis und zur Steuerung von Verzweigungen die logischen Verknüpfungsoperatoren A, v, xor („und", „oder", „exclusiv oder") verwandt, so daß sich mit den entsprechenden Symbolen folgender schematischer Grundaufbau einer EPK ergibt (vgl. Abb. II-3.5-1).

370

3 Software Engineering

Eraptis 1

Abb. II-3.5-1 Grundaufbau einer EPK Dabei ist zu beachten, daß sich definitionsgemäß Sechsecke (Objekttyp Ereignis) und abgerundete Rechtecke (Objekttyp Funktion) längs der Abiaufrichtung immer abwechseln müssen und niemals zwei oder mehrere Funktionen bzw. zwei oder mehrere Ereignisse direkt aufeinander folgen können. Die inhaltliche Bestimmung einer EPK läßt es zu, daß mehrere Ereignisse - verknüpft durch die logischen Operatoren zu einem zusammengesetzten Ereignis eine Funktion auslösen können und andererseits eine Funktion auch ein zusammengesetztes Endereignis haben kann (vgl. Abb. II-3.5-2). Dabei sind im Fall der Ereignisverknüpfung alle drei logischen Operatoren möglich, in der Abbildung wird exemplarisch nur der A-Operator betrachtet.

;

-

\ >

D

ganosdMn

\

AiiiA


Lwtfrtfi

f

pnA^g

-è \

\

\

\ ">

B«sle*sctT8 yy. Hierbei wird die beim TYPE-Befehl übliche Bildschirmausgabe unterdrückt und statt dessen alle Daten in die neu entstehende Datei yy ausgegeben. Mit »Datei erfolgt die Umleitung ans Ende einer schon bestehenden Datei. Ausgabeumleitungen ermöglichen es, die Bildschirmausgaben eines Programmes aufzufangen und in einer Datei zu speichern.

Teil III Individuelle Datenverarbeitung/persönliche Nutzung von PC's 415 Eingabeumleitungen werden mit