Entwicklung computergestützter Werkzeuge kommt nicht voran (Teil 2)

Die Software-Entwicklung ist auf bessere Methoden angewiesen

15.03.1991

In den letzten 20 Jahren sind eine Vielzahl von Methoden zur Unterstützung des Software-Entwicklungsprozesses entstanden. Diese Vielzahl hat zu einer hohen Unübersichtlichkeit geführt und die Entwicklung von computergestützten Werkzeugen eher behindert. Deshalb besteht das Bestreben, so August-Wilhelm Scheer*, eine Methodologie (Lehre von den Methoden) für die Entwicklungsmethoden in Angriff zu nehmen.

Auflösung der Ressourcensicht durch ein Phasenmodell

Durch die Vielfalt der Komponenten wie Zentraleinheiten, Peripheriegeräte, Netze, Programmsysteme oder Datenbanksysteme ist die Ressourcensicht eines Informationssystems besonders umfangreich und vielfältig. Andererseits ist diese Sicht aus betriebswirtschaftlicher Sicht nur insoweit von Bedeutung, wie sie als Träger des Informationssystems Rahmenbedingungen für die Beschreibung der anderen Komponenten und ihrer Beziehungen stellt.

Aus diesem Grunde werden die Ressourcen nicht als eigenständiger Beschreibungskreis betrachtet, sondern die Ressourcensicht wird jeweils innerhalb der anderen Komponentenbeschreibungen behandelt. Dazu wird die Beschreibung der anderen Sichten in Abhängigkeit ihrer Nähe zu den informationstechnischen Ressourcen differenziert.

Im dritten Schritt, der Erstellung des DV-Konzeptes (design specification), werden die Fachmodelle an die Anforderungen der Benutzerschnittstellen von Implementierungswerkzeugen (zum Beispiel Datenbanksysteme, Netzwerkarchitekturen oder Programmiersprachen) angepaßt. Dabei wird aber noch kein Bezug zu konkreten Werkzeugprodukten hergestellt.

Im Rahmen des vierten Schrittes, der technischen lmplementierung, wird die konkrete Umsetzung der Anforderungen in physische Datenstrukturen, Hardwarekomponenten und Programmsysteme durchgeführt (implementation description).

Die vier Phasen beschreiben die Erstellung eines Informationssystems und werden deshalb auch als "Build-Time" bezeichnet. Anschließend wird das fertiggestellte System dem Betrieb übergeben, so daß sich als fünfter Schritt eine Betriebs- und Wartungsphase anschließt, die als Run-Time bezeichnet wird.

Dieser Prozeß der Umsetzung betriebswirtschaftlicher Tatbestände in die EDV-technische Realisierung wird häufig durch differenzierte Phasenmodelle beschrieben. Hier wird im folgenden einer fünfstufigen Abschichtung gefolgt.

Im ersten Schritt wird eine EDV-orientierte fachliche Ausgangslösung erstellt. Diese ergibt sich aus einer Ist-Analyse der Vorgangsketten mit darauf aufbauenden Soll-Konzepten. Diese Vorgangskettenanalyse soll den grundsätzlichen Nutzen des Informationssystems sichtbar machen. Aus diesem Grund werden hier auch noch alle Sichten zusammen betrachtet.

Im zweiten Schritt werden in dem Fachkonzept (requirements definition) unabhängig von Implementierungsgesichtspunkten die einzelnen Sichten des Anwendungssystems modelliert. Dabei werden Beschreibungssprachen gewählt, die so weit formalisiert sind, daß sie Ausgangspunkt für eine konsistente EDV-technische Implementierung sein können.

Diese Run-Time-Version des Informationssystems und seine Werkzeugumgebung werden im folgenden nicht weiter betrachtet. Die Arbeit beschränkt sich somit auf die Build-Time-Phaseh von Informationssystemen. Das Fachkonzept ist sehr eng mit der betriebswirtschaftlichen Anwendungswelt verknüpft, wie es die Breite des Pfeiles in Abbildung 5 zeigt.

Es soll aber weitgehend unabhängig von Implementierungsgesichtspunkten erstellt werden, wie es die Pfeilbreite zum DV-Konzept darstellt. Die technische Implementierung sowie der Betrieb und die Wartung sind dagegen eng an die Geräte- und Produktebenen der Informationstechnik gebunden. Änderungen der Informationstechnik wirken sich auf die Art der Implementierung und den Betrieb eines Systems aus.

Die Phasen lassen sich nicht immer exakt voneinander trennen. Deshalb ist die Zuordnung von Methoden, Darstellungen und Ergebnissen des Software-Entwurfsprozesses nicht immer eindeutig. Mit dem Phasenkonzept soll keinesfalls ausgedrückt werden daß einer strengen Abfolge des Entwicklungsprozesses nach dem "Wasserfall Modell" gefolgt wird.

Vielmehr wird ausdrücklich auch eine Prototyping-Vorgehensweise einbezogen. Aber auch bei einer evolutionären Softwareentwicklung sind prinzipiell die Beschreibungsebenen gegeben.

Mit dem Phasenkenzept können die vielfältigen Beziehungen zwischen der Ressourcensicht und den anderen Komponenten vereinfacht werden. Zunächst wird in den beiden ersten Schritten jede Komponente allein aus fachlicher Sicht ohne Implementierungseinschränkungen dargestellt.

Anschließend werden die Sachverhalte im Rahmen des DV-Konzeptes weiter spezifiziert und in der Implementierungsstufe auf konkrete DV-Techniken implementiert. Erst bei der dritten und vierten Phase wirken sich Ressourcengesichtspunkte aus. Die Ressourcen werden deshalb im Rahmen dieser Beschreibungen - soweit erforderlich - charakterisiert.

Da bei der ersten Stufe, der Vorgangskettenanalyse und Bildung des betriebswirtschaftlichen Anwendungskonzeptes die Betrachtungssichten noch nicht getrennt werden, gehört sie eigentlich nicht mit zur Aris-Architektur des Informationssystems. Die zu beschreibenden Komponenten reduzieren sich somit auf das in Abbildung 6 dargestellte Modell aus Organisations-, Vorgangs- und Datensicht in den jeweils drei Beschreibungsebenen Fachkonzept, DV-Konzept und Implementierung.

Mit der Unterteilung des Vorgangsmodells in Sichten gehen die Beziehungen zwischen diesen Komponenten verloren. Da aber elementare Zusammenhänge zwischen Daten und Funktionen und der Organisation bestehen, werden diese in einer eigenen Komponente, die zwischen den Elementen vermittelt, wieder eingeführt. Diese wird als Steuerungssicht bezeichnet.

Da durch die Verbindung der Elemente Bewegungen erzeugt werden (Daten lösen in Form von Ereignissen Funktionen aus oder Funktionen verändern Daten), kann der Begriff Steuerung als Kennzeichnung dieser Dynamik dienen.

Damit kann jede Komponente zunächst für sich beschrieben werden die Beziehungen zu anderen Komponenten werden dann in der Steuerungssicht behandelt. Auch bei der Steuerung werden die drei Beschreibungsebenen bezüglich der Ressourcennähe gebildet. Dadurch können auf jeder der Beschreibungsebenen die Verbindungen zu den anderen Komponenten hergestellt werden.

Abbildung 6 stellt somit die Architektur des Informationssystems dar. Sie besteht aus den Baublöcken Funktionen, Organisation, Daten und Steuerung. Die Komponenten werden jeweils zur Nähe der Ressource Informationstechnik in die Beschreibungsebenen Fachkonzept, DV-Konzept und Implementierung abgeschichtet.

Darstellung von Informationsmodellen

Nachdem die Bausteine der Aris-Architektur zwischen den einzelnen Bausteinen deutlich werden, liegt es nahe, eine einheitliche Beschreibungssprache für alle Bausteine auszuwählen. Zwar sind zur Beschreibung von Daten, Funktionen und Organisationsaspekten eigene Darstellungsmethoden wie Datenmodelle, Hierarchiediagramme, Ablaufdiagramme oder Organigramme entwickelt worden; diese beziehen sich aber auf die Ebene der fachlichen Darstellung.

Für die Metaebene, also die Beschreibung der Elemente des Informationssystems selbst, kann dann eine einheitliche Sprache eingesetzt werden, wenn sie in der Lage ist, von den sichtenspezifischen Inhalten zu abstrahieren und die Methoden auf die darzustellenden Objekte mit ihren Beziehungen zu reduzieren. Deshalb wird eine Beschreibungssprache gewählt, die pro Baustein lediglich die zu beschreibenden Elemente und ihre Beziehungen untereinander festlegt.

Zur Darstellung von Objekten und ihren Beziehungen eignet sich generell das Entity-Relationship-Modell (ERM) von Chen. Dieses ist zwar für die Darstellung von Datenstrukturen für Anwendungssysteme entwickelt worden, kann aber auch zur Beschreibung der Metaebene eingesetzt werden.

Mit der einheitlichen Beschreibungssprache des ERM können die Objekte und Beziehungen der einzelnen Sichten einheitlich dargestellt werden. Diese Beschreibung wird als Informationsmodell oder Meta-Informationsmodell bezeichnet.

Gleichzeitig bildet es die konzeptionelle Beschreibung einer Datenbank, in der nach dieser Architektur entwickelte konkrete Anwendungen gespeichert werden können. Das heißt Organisations-, Funktions-, Daten- und Steuerungsmodelle eines Anwendungsgebietes werden als lnstanzen dieser nach dem Informationsmodell gebauten Datenbank geführt.

Die Bedeutung des Repository

Eine solche Datenbank, die derartige Modelle enthält, wird auch als Repository bezeichnet. Der Begriff "Repository" ist ab zirka 1989 mit der Ankündigung des IBM-Software-Entwicklungskonzeptes AD/Cycle populär geworden. Das Repository enthält in der hier entwickelten Aris-Architektur Modelle für Funktionen, Organisationen, Daten und deren Verbindungen. Das Repository wird damit zum Herzen eines Informationssystems, und entsprechende Bedeutung besitzt das Informationsmodell des Repositories, da es die Mächtigkeit der Beschreibungselemente festlegt.

Das ERM besteht aus den Elementen Entity- oder Objekttypen (dargestellt durch Kästchen) und Beziehungstypen (dargestellt durch Rauten). Die Beziehungstypen werden nach den Kardinalitäten 1:n, 1:1, n:m und m:1 unterschieden.

Die einzelnen Sichten sind jeweils stark umrandet. Neben den Sichten Funktion, Daten, Organisation und Steuerung ist auch die Ressourcensicht explizit dargestellt. Das heißt die schrittweise Näherung zur Ressourcenebene ist noch nicht durch ein Phasenkonzept ausgedrückt, sondern wird durch Beziehungstypen "Umsetzung, Ausführung" zwischen dem Entitytyp Ressourcen und den anderen Sichten hergestellt.

Diese Abkürzung besitzt den Vorteil, daß keine Begriffe der Ebenen des DV-Konzeptes sowie der Implementierung aufgenommen zu werden brauchen.

Das Informationsmodell der Abbildung 7 gibt eine erste Einführung in die Darstellungsweise und soll zum Vergleich mit anderen Architekturkonzepten dienen. Es wird später wesentlich verfeinert.

Ausgangspunkt des Funktionsmodells in Abbildung 7 sind die Unternehmensziele, die mit dem Informationssystem beziehungsweise mit den in ihm abgebildeten Vorgangsketten und Problemlösungen angestrebt werden.

Die Unternehmensziele sind in der Regel hierarchisch gegliedert. Aus globalen Zielen wie "Gewinnmaximierung", "Erzielung eines bestimmten Marktanteils" oder "Erreichung bestimmter Wachstumsraten" werden Unterziele wie "Erreichung eines bestimmten Umsatzes", Senkung der Kosten um einen bestimmten Betrag" oder "Erreichung eines bestimmten Qualitätsniveaus der Produkte" abgeleitet. Die Struktur der untereinander verflochtenen Ziele bildet eine m:n-Beziehung innerhalb des Entitytyps Unternemensziele.

Zur Erreichung der Ziele müssen bestimmte Funktionen durchgeführt werden. Funktionen sind zum Beispiel Auftragsbearbeitung, Fertigung oder Controlling. Auch diese können wiederum durch abgeleitete Teilfunktionen unterstützt werden. Die Verknüpfung von Funktionen untereinander sowie der Unterstützungscharakter von Funktionen zu Zielen führt zu der n:m-Beziehung innerhalb des Entitytyps Funktion sowie einer n:m-Beziehung zwischen Funktion und Unternehmenszielen.

Auf der linken Seite ist das Modell der Datenstrukturen dargestellt. Der Entitytyp Informationsobjekt bezeichnet das Objekt, das durch Attribute in einer Datenbasis beschrieben werden soll. Er umfaßt Ereignisse und Zustände, die durch Daten repräsentiert werden.

Zwischen Informationsobjekten wie Aufträge, Kunden und so weiter bestehen Beziehungen (zum Beispiel welcher Kunde welche Aufträge erteilt hat). Diese werden durch eine n:m-Beziehung innerhalb des Begriffes Informationsobjekt ausgedrückt.

Informationsobjekte eines inhaltlich zusammengehörenden Bereiches können zu einem Datenmodell zusammengefaßt werden. Da sich diese überschneiden können, besteht eine n:m-Beziehung zwischen Datenmodell und dem Informationsobjekt.

Das Modell der Organisationssicht hat als zentralen Begriff die Organisationseinheit. So kann die Abteilung, Stelle oder größere Einheit wie Betriebsbereich bis hin zum gesamten Unternehmen definiert werden. Die strukturellen Entscheidungsberechtigungen oder Zugehörigkeitsbeziehungen zwischen diesen Bereichen führen zu einer n:m-Beziehung innerhalb des Entitytyps Organisationseinheit.

Die n:m-Beziehung läßt somit wieder zu, daß ein Bereich mehreren Bereichen untergeordnet sein kann. Dieses ist beispielsweise dann der Fall, wenn ein Betrieb für mehrere übergeordnete Produktbereiche zuständig ist.

Die Beziehungen der drei Komponenten untereinander werden durch die Steuerungssicht berücksichtigt. Funktionen können als Transformation von Eingangs- zu Ausgangsdaten interpretiert werden. Ereignisse starten Funktionen und sind auch Ergebnis von Funktionen. Diese drei Zusammenhänge sind als Beziehungen zwischen Informationsobjekt und Funktion dargestellt. Der Zusammenhang zwischen Organisationseinheit und Funktion wird durch die Bearbeitungszuordnung ausgedrückt. Organisationseinheiten können bestimmte Sichten auf Informationsobjekte zugeordnet werden, die durch den Beziehungstyp Datensicht ausgedrückt werden.

Die Informationstechnik wird durch den Entitytyp IT-Ressorcen repräsentiert. Er wird nicht weiter aufgelöst, da die Beschreibung der Beziehungen im Vordergrund steht. Der Beziehungstyp Umsetzung, Ausführung ist jeweils den drei Modellen zugeordnet, so daß entsprechend der entwickelten Architektur ihre Beschreibung innerhalb der Sichten durch das Phasenmodell erfolgt.

Zur Darstellung dieser Zusammenhänge wird das einfache ERM nach Chen erweitert, da Beziehungen zwischen den Beziehungstypen der Steuerungssicht und dem Entitytyp Ressourcen gebildet werden. Die Beziehungstypen werden dazu vorher zu Entitytypen umgeformt und mit Kästchen umrandet. Das Meta-Informationsmodell als ERM beschreibt somit die Objekte (Entitytypen) und der zwischen ihnen bestehenden Beziehungen eines Informationssystems. Es beschreibt alle Sichten der hier entwickelten Aris-Architektur (Funktionen, Organisation, Daten und ihre Steuerung) über die Entwicklungsebenen (Vorgangskettenanalyse, Fachkonzept, DV-Konzept und Implementierung).

Es ist gleichzeitig das konzeptionelle Schema einer Datenbank des Repositories zur Speicherung der entsprechenden Modelle auf der Anwendungsebene. Damit sind die vier Komponenten der Metaebene

- Allgemeines Vorgangsmodell,

- Aris-Architektur,

- Beschreibungssprache und Aris-Informationsmodell,

- Repository

entwickelt (vergleiche Abbildung 8) und können zum Vergleich mit anderen Architektur-Konzepten dienen. +