Übersetzung der Fachsprachen ist unerläßlich

Methode: Suche nach geeigneter Sprache

26.07.1991

Wer ein CASE-Projekt starten will, muß sich nach Einschätzung von Hans-Dieter Bremer* zu allererst über die Methode klar sein, über die sich die Beteiligten verständigen können und nach der verfahren werden soll. Erst dann ist es sinnvoll, sich für entsprechende Werkzeuge zu entscheiden.

Gravierende Probleme in der Software-Entwicklung bestimmen den DV-Alltag, und das Unternehmensmanagement fordert massiv den Abbau des berühmt-berüchtigten "Anwendungsstaus" bei der Entwicklung von Anwendungslösungen. Dabei wird CASE oft als mächtiger "Geist in der Flasche" gehandelt, der mit Zaubertricks alle Sorgen und Nöte der Software-Entwickler in schlüsselfertige Anwendungspakete umsetzen kann.

Aus werbewirksam gestalteten Hochglanzbroschüren wird von Lösungssuchenden der Inhalt nur danach ausgewertet, ob das Werkzeug einer Strategie folgt, von denen oft gerade nur die ersten acht Buchstaben bekannt sind, und ob es auf der bereits vorhandenen Hardwareplattform ablauffähig ist. Ein weiteres Auswahlkriterium besteht darin, ob das Produkt Codes für die installierte Datenbankumgebung erzeugt.

Abteilungen müssen sehr eng kooperieren

Kaum glaubhaft, aber wahr: Auf der Grundlage dieses wenig fundierten Absicherungsgerüsts wird ein CASE-Produkt oft als geeignetes Werkzeug ausgewählt. Der Anwender ist dann auch noch fest davon überzeugt, durch das vollständige Ausfüllen der Bildschirm-Masken ("Das Tool verlangt/ermöglicht hier eine Eingabe"), ein CASE-Tool für die Lösung der Probleme der 90er Jahre zu besitzen, das die Realisierung aller anstehenden Anwendungspakete automatisch garantiert. Die Softwarelizenz liefert den Schlüssel zum Erfolg, so zumindest die weit verbreitete Illusion. Das Verständnis dafür, ob und warum ein Diagramm gezeichnet oder eine Maske ausgefüllt wird, ist oft nur ungenügend ausgeprägt.

CASE soll uns zunächst Systemwelten analysieren, beschreiben, begreifen, designen und redesignen helfen (Upper-CASE). Dieser Bereich ist der wichtigste und zugleich der schwierigste. Der schwierigste Einzelschritt deshalb, weil hier unterschiedliche Personen wie Fachanwender, Organisatoren und Programmierer beteiligt sind, die in ihren jeweiligen Welten verschiedene "Sprachen" herausgebildet haben. Die "Übersetzung" in andere Begriffswelten ist für eine Verständigung und eine Ausrichtung auf gemeinsame Ziele unabdingbar, dabei aber sehr anspruchsvoll und äußerst anfällig für Fehlinterpretationen.

Eine überaus feine und präzise Nivellierung auf ein gemeinsames Niveau ist von hoher Bedeutung, denn hier gemachte Fehler sind folgenschwer und teuer. Schließlich kann aus einem falschen Design niemals ein rundum passendes Programm geschneidert werden. Unverstandene beziehungsweise unartikulierte Bedürfnisse sind durch keine Software abzudecken. Ein wie auch immer angepriesener stromlinienförmiger "Super-Turbo-Code-Generator" kann mit diesen nicht anwendungsgerechten Definitionen seine Aufgabe für die Erzeugung korrekter und vollständiger Codes auf gar keinen Fall in voller erforderlicher Bandbreite erfüllen.

Im ersten Schritt beim CASE-Einstieg muß also allen Beteiligten die Gelegenheit gegeben werden, die Anforderungen in ihrer eigenen Sprache zu definieren. Denn in seiner eigenen Welt kann sich jeder Betroffene am besten bewegen und ausdrücken.

Um dabei von den Partnern aus anderen Bereichen verstanden zu werden, bedarf es der vorherigen Übersetzung in gemeinsame Sprach-Plattformen, die wir Methoden nennen. Als Kommunikationsebene zwischen Fachanwendern und Systemanalytikern bieten sich zum Beispiel die "Dataflow Diagrams" aus der Methode SADT System Analysis & Design Technic (SSADM) oder das "Kommunikationsdiagramm" der Methode "Isotec" von Ploenzke an.

Erst nach der Auswahl und Definition der geeigneten "Sprache" (Methode), die zum Beispiel vom Anwender in der Fachabteilung benutzt wird, um seine Aufgabenstellung zu beschreiben, können Organisatoren die einzelnen Begriffe in eine Organisationssprache umsetzen. Diese übertragen DV-Fachleute in eine DV-Konzeptsprache, etwa um ein physisches Datenbankdesign zu transferieren. Dazu werden Werkzeuge benötigt, welche die Schnelligkeit und Leistungsfähigkeit eines Rechners dazu nutzen, den gewählten Weg (Methodenverbund) von der Aufgabenstellung bis zu Organisation und Programm zu unterstützen.

Diese Werkzeuge müssen aber dann in der Lage sein, die individuell ausgewählten Methoden und deren Kombinationen genügend und mit sauber definierten Übergängen zu unterstützen. Die von vielen namhaften in- und ausländischen CASE-Experten schon lange immer wieder geforderten Werkzeuge sind heute als in ihren "Sprachen" (Methoden) frei definierbaren Tools am Markt verfügbar. Mit diesen Tools lassen sich Diagramme, Tabellen, Icon-Layouts, Objekt(meta)daten, Dokument-Zusammenstellungen und, als wichtigstes Element, die gesamte Begriffswelt, vollkommen frei definieren.

Ein in der Methode "Isotec" erfahrener Systemspezialist kann beispielsweise seine Datenmodellierung in einem "Informations-Strukturdiagramm" durchführen und Informationsobjekte und deren Beziehungen zueinander angeben. Diese Informationsobjekte können spezialisiert und deren Detailinformationen in einem Informationsobjekt-Katalog sowie in Freitext (zum Beispiel mit Word von Microsoft) angegeben werden. Alle Begriffe sind exakt in der Form dargestellt und verknüpft, wie es die gewählte Methode vorschreibt.

Anwender müssen ihre Methode finden

Ein Praxisbeispiel aus jüngster Zeit verdeutlicht die gravierenden Vorteile eines Werkzeuges mit den beschriebenen Eigenschaften. Ein in Isotec geübter Anwender aus dem Landesamt für Datenverarbeitung in einem Stadtstaat war nach einer zirka zweistündigen Einführung in das Handling des Werkzeugs "Developer" von der Düsseldorfer Sterling Software GmbH, in der Lage, ohne Reibungsverluste mit dem Tool zu arbeiten.

Nur wenige Wochen vorher hatte genau dieser Anwender wegen der hohen Gewöhnungsbedürftigkeit an die einzelnen Begriffe einer anderen im Developer implementierten Methode die Arbeit mit dem Werkzeug als äußerst schwierig empfunden. Damals mußte er sich ja auch noch mit Begriffen wie "Entity-Relationship-Diagramm", "Entity" und "Entity Details" herumschlagen.

Auf der anderen Seite werden viele Leser dieses Beitrags zum erstenmal mit den Begriffen "Informations-Strukturdiagramm" oder "lnformationsobjekt" konfrontiert und haben ihrerseits ebenfalls Verständnisprobleme mit dieser Begriffszuordnung.

Als Fazit bleibt die Feststellung: Jeder Anwender muß den zu ihm passenden ersten CASE-Schritt wählen, die Methode(n). Nur ein erfolgreicher erster Schritt ermutigt zu einem weiteren auf dem Weg zu einer kompletten CASE-Lösung.