8.8 Integration verschiedener Sichten

Neben der Aufdeckung von Interessenskonflikten, also Konflikten zwischen Wünschen, ist das Aufdecken von Beschreibungsinkonsistenzen von Interesse, also inhaltlichen Konflikten zwischen verschiedenen Beschreibungen des Ist-Zustands oder des Soll-Zustands. Diese können Interessenkonflikte sein, sind es oftmals aber nicht. Zur Unterstützung dieser Tätigkeit wäre es nützlich, wenn alle Beteiligten den Zustand aus der Perspektive (Sicht) schildern könnten, die ihnen am geläufigsten und die für sie am relevantesten ist. Es wird dann maschinelle Unterstützung dafür gebraucht, diese verschiedenen Sichten auf eine gemeinsame Sicht abzubilden, in der nach Widersprüchen zwischen den einzelnen Beschreibungen gesucht werden kann.

Eine Möglichkeit hierfür sind sogenannte Metamodellierungssysteme, von denen eines (und seine Anwendung) in diesem Abschnitt kurz vorgestellt werden soll.

8.8.1 Metamodellierung

Die abstrakte Beschreibung eines Zustandes ist ein Modell dieses Zustands. Informatiker erfinden zur Aufstellung und Manipulation solcher Beschreibungen typischerweise eine Modellierungssprache. Eine solche Sprache ist ihrerseits ein Modell, das aber zur Beschreibung von Modellen, nicht von Zuständen der wirklichen Welt dient, also ein Metamodell. Solche Sprachen erlegen ihren Benutzern normalerweise eine bestimmte Weltsicht auf, indem sie einen gewissen Beschreibungsrahmen vorgeben. Das ist einerseits praktisch, weil es die Modellierungsarbeit vereinfacht, andererseits aber auch unerwünscht, weil es die Flexibilität beim Ausdrücken der Zustände beschränkt.

Deshalb kann man eine Modellierungssprache vorsehen, mit der nicht direkt der Zustand beschrieben werden soll, sondern stattdessen die Modellierungssprache, in der dann erst der Zustand ausgedrückt wird. Eine solche Sprache stellt also ein Modell eines Metamodells dar, ein Metametamodell (M2-Modell). Sie heißt deshalb Metamodellierungssprache.

Ist eine solche Metamodellierungssprache flexibel genug, so können mit ihr auch beliebige höhere Meta-Ebenen betreten werden. Insbesondere lassen sich dann die Beziehungen zwischen Metamodellen beschreiben, was die Grundlage für die Integration verschiedener Sichten bei der Anforderungsbestimmung bildet, denn diese Sichten (genauer: die Sichtweisen) sind Metamodelle.

8.8.2 Beispiel: Telos

Ein Beispiel für eine Metamodellierungssprache ist Telos, das auf nur zwei Entitätstypen und drei Beziehungstypen basiert:

• Entitätstyp 1 sind Objekte, die über einen Namen identifiziert werden.
• Entitätstyp 2 sind Zusicherungen, also Formeln.
• Beziehungstyp 1 sind Attribute. Ein Objekt kann Attribut eines anderen Objekts sein.
• Beziehungstyp 2 ist die Klassifikation mit der ,,in``-Beziehung. Ein Objekt (Instanz oder Klasse) kann Mitglied eines anderen Objekts (Klasse) sein.
• Beziehungstyp 3 ist die Regelbeziehung. Eine Zusicherung ist eine Regel für ein Objekt. Hier gibt es zwei Fälle, nämlich Deduktionsregeln zur Ableitung von neuen Zusicherungen und Zwänge zur Beschränkung der Eingabe (oder Herleitung) von Daten.

Die Klassifikation von Telos ist sehr flexibel. Sie erlaubt nicht nur die Beschreibung von Klassen in einer Klassenhierarchie, sondern auch die Beschreibung von Instanzen, Metaklassen, Metametaklassen, etc. Außerdem können mehrere gleichzeitige Klassifikationen für dieselben Objekte existieren, um beispielsweise mehrere Abstraktionen derselben Welt zu beschreiben. Die Deduktion erlaubt das Ableiten von Klassenzusicherungen (,,Objekt o ist Mitglied der Klasse c``) und von Attributwerten (,,Attribut a von Objekt o hat Wert x``). Damit entspricht die Ausdruckskraft von Telos der einer deduktiven relationalen Datenbank.

Beispiele für Telos-Deklarationen:

Department in Class with
  attribute
    head: Manager 
end

Employee in Class with
  attribute
    name: String;
    salary: Integer;
    dept: Department;
    boss: Manager
end

Manager in Class isA Employee 
end

Employee with
  rule
    BossRule:$
      forall e/Employee m/Manager
        (exists d/Department (e dept d) and (d head m)) ==>
        (e boss m) $

Dies deklariert eine Klasse Department mit einem Attribut head aus der Klasse Manager und analog eine Klasse Employee mit diversen Attributen. Drittens eine Instanz Manager zur Klasse Employee; somit ist Manager sowohl eine Klasse als auch eine Instanz einer Klasse und folglich Employee eine Metaklasse. Schließlich gibt die letzte Deklaration eine Deduktionsregel an, die beschreibt, wann ein Angestellter e den Manager m zum Chef hat: dann nämlich, wenn e zur Abteilung d gehört und m der Leiter von d ist. (Diese Beispiele haben übrigens nichts mit dem weiter unten besprochenen Projektbeispiel zu tun.)

So einfach wie Telos erscheinen mag: Aufgrund der Deduktionsregeln und der mehrfachen Klassifikation ist es sehr mächtig. In der gegenwärtigen Telos-Implementation werden die Deklarationen mittels partieller Auswertung in Prolog umgesetzt, so daß der Prolog-Interpretierer Teile der eigentlichen Deduktionen erledigt.

8.8.3 Vorgehen zur Sichtenintegration

Das grundsätzliche Vorgehen zur Integration verschiedener Systemsichten mit Hilfe eines Metamodellierungssystems sieht etwa folgendermaßen aus:

1.

Definiere ein M2-Modell, das eine Terminologie bereitstellt, mit der sich alle verschiedenen Sichten beschreiben lassen.

2.

Definiere alle gewünschten Sichten anhand des M2-Modells.

3.

Ermittle Ist-Zustand und Soll-Zustand (Anforderungen) in Interviews mit den diversen Beteiligten. Verwende zur Beschreibung jeweils diejenige Sicht, die dem Beteiligten am angenehmsten ist. Es ist erwünscht, daß sich die Beschreibungen stark überlappen.

4.

Definiere Abbildungen von einer Sicht in eine andere anhand des M2-Modells. Nun können die Beschreibungen eines Beteiligten auch in anderen Sichten betrachtet werden als derjenigen, in der sie abgegeben wurden.

Der Wechsel zwischen Sichten kann nun benutzt werden, um in einem Interview mit einem Beteiligten auf Beschreibungen eines anderen Beteiligten zurückzugreifen, der eine andere Sichtweise benutzt hat, um sie abzugeben. Außerdem bietet die Integration der Sichten eine gute Grundlage für eine Analyse der Beschreibungen (siehe den nächsten Abschnitt).

Einige Bemerkungen zum M2-Modell sind zu machen:

• Seine Aufstellung stellt in der praktischen Anwendung einen erheblichen Aufwand dar.
• Es entscheidet darüber, wie flexibel die Modellierungssprachen werden können, die sich integrieren lassen.
• M2-Modelle können in späteren Projekten unterschiedlich gut wiederverwendet werden. Ein M2-Modell kann schwerlich sowohl so präzise sein, daß es wesentliche Anforderungskonflikte zu erkennen erlaubt, als auch zugleich so allgemein, daß es in allen möglichen Anwendungen wiederbenutzt werden kann. Sehr wohl gibt es aber M2-Modelle, die in einer Reihe von ähnlich gelagerten Projekten mit nur geringen Änderungen benutzt werden können.
• Ein gutes M2-Modell muß einfach sein; es darf nur sehr wenige (z.B. unter zehn) Grundkonzepte aufweisen.
• Dann wird es bei der Anforderungsbestimmung zu einem wichtigen Kommunikationshilfsmittel, weil es die Ausdrucksweise vereinheitlicht und damit Mißverständnisse vermeiden hilft.

8.8.4 Anforderungsanalyse durch Sichtenintegration

Wie schon gesagt, bemüht man sich, viel Überlappung zwischen den Sichten zu haben und viel redundante Information von den Beteiligten zu erhalten. Solche Redundanz bietet nämlich die Gelegenheit zur Entdeckung von Mißverständnissen oder Konflikten zwischen den Beteiligten und von Fehlern beim Anforderungsbestimmungsprozeß. Die Redundanz wird ausgenutzt, indem man die miteinander integrierten Sichten auf Konsistenz prüft.

Dazu definiert man anhand des M2-Modells sogenannte Abfrageklassen (query classes), von denen jede genau eine Klasse zu erwartender Inkonsistenzen beschreibt. Das Metamodellierungssystem kann die Deduktionen berechnen, die nötig sind, um alle Instanzen dieser Art von Inkonsistenz aufzuspüren. Jede Instanz muß dann einzeln untersucht und auf einen Modellierungsfehler oder einen Konflikt in den Anforderungen zurückgeführt werden.

Neben Inkonsistenzen lassen sich auf die gleiche Weise auch andere Informationen aus den zusammengeführten Sichten automatisch extrahieren. Beispiele für dieses Vorgehen werden wir in folgenden Abschnitt sehen.

8.8.5 Beispiel: PFR mit ConceptBase

Die obenerwähnte Metamodellierungssprache Telos ist Bestandteil eines Metamodellierungssystems namens ConceptBase. Dieses System ist ein deduktives Datenbanksystem mit Telos als Kern und einer Benutzerschnittstelle, die interaktiv Aufbau und Manipulation von Metamodellen und Modellen unterstützt.

In diesem Abschnitt betrachten wir eine Anwendung [NJJ⁺96] von ConceptBase zur Bestimmung und Analyse des Ist-Zustands in einem Unternehmen, das seine Arbeitsabläufe optimieren möchte (workflow analysis, business process reengineering). Die Analyse des Ist-Zustands, die den Ausgangspunkt dieser Optimierung bildet, wird nach der PFR-Methode durchgeführt. PFR (analysis of presence and future requirements) ist eine Analysetechnik, die wie folgt abläuft:

1.

In einer zweitägigen Sitzung entwerfen die Beteiligten eine anfängliche gemeinsame Sicht: Grobe Analyse der gegenwärtigen Geschäftsprozesse, Analyse der Ziele hinter diesen Abläufen, Beschreibung neuer Ziele, grobe Skizzierung besserer Geschäftsprozesse mit Verweisen von Prozeßelementen auf die Ziele, Identifikation zentraler Prozeßelemente.

2.

Die als zentral erkannten Elemente werden dann mit verschiedenen Mitteln genau untersucht: in Einzelinterviews, mit Arbeitsablaufstudien und mit Studien von Dokumentenstrukturen und -inhalten. Dabei werden mehrere verschiedene Perspektiven (die Quellsichten) benutzt.

3.

Die Informationen aus den verschiedenen Sichten werden zusammengetragen und analysiert. Dabei auftretende Lücken und Widersprüche werden in zusätzlichen Interviews aufgeklärt, wobei lokale Zustimmung der Beteiligten angestrebt wird.

4.

In einer zweiten Sitzung werden die Ergebnisse allen Beteiligten mit dem Ziel verständlich gemacht, globale Zustimmung aller Beteiligten zu erhalten. In diesem Prozeß werden zur Darstellung globaler Sachverhalte weitere Sichten (die Zielsichten) benutzt.

ConceptBase kann als Werkzeug zur Unterstützung von PFR benutzt werden. Es erlaubt, die Information aus den verschiedenen Quellsichten in eine einheitliche interne Form zu bringen, dann anhand dieser einheitlichen Form mit Rechnerhilfe Lücken und Widersprüche aufzudecken und schließlich automatisch Darstellungen in beliebigen Zielsichten zu erzeugen.

Ausgangspunkt aller dieser Möglichkeiten ist die einheitliche interne Darstellung, die durch ein M2-Modell beschrieben wird. Für das Beispiel wurde das M2-Modell aufgestellt, das in Abbildung 8.4 schematisch skizziert ist.

Es enthält nur vier Entitätstypen, nämlich die Agenten, die in der Unternehmung Prozesse durchführen, die Aktivitäten, also die elementaren Prozesse selbst, die Medien, die die dabei erzeugte und verarbeitete Information tragen und viertens die Daten, also diese Informationen selbst. Hinzu kommen 12 Beziehungstypen; beispielsweise im Fall des Agenten seine Eigenschaft, der Ausführer einer Aktivität zu sein (von unten kommender Pfeil), Erzeuger oder Benutzer von Medien zu sein (nach rechts weggehende Pfeile) und schließlich einen anderen Agenten mit einem Medium zu versorgen (dreistellige Beziehung, runder Pfeil und von diesem abgehender Pfeil).

Dieses Modell ist hinreichend einfach, um als M2-Modell brauchbar zu sein. Die Terminologie ist so simpel, daß dieses M2-Modell leicht Grundlage einer gemeinsamen Sprachregelung werden kann. Die Aufstellung dieses Modells ist alles andere als einfach. Die Unterscheidung zwischen Daten und Medien wurde beispielsweise aufgrund der Beobachtung gemacht, daß oftmals Unternehmensprozesse daran leiden, daß Informationen mehrfach von einem Datenträger auf einen anderen wechseln (z.B. aus einem Rechner auf ein Blatt Papier, dann über ein Fax auf ein anderes Blatt Papier und von dort von Hand wieder in einen Rechner), oder daß Daten überflüssigerweise mehrfach einer Aktivität zugänglich gemacht werden. Die Unterscheidung wurde als das einfachste und beste Hilfsmittel erkannt, um diese Situationen modellieren zu können.

Auf Basis dieses Metamodells können nun verschiedene Sichten von Unternehmensprozessen beschrieben werden. Im vorliegenden Fall wurden unter anderem folgende drei Sichten definiert: Die Aktivitätsfolgensicht aus Abbildung 8.5 stellt Handlungssequenzen in den Mittelpunkt der Betrachtung und beschreibt darüber hinaus, wer jeweils eine Handlung ausführt und welche Information dabei benutzt oder erzeugt wird.

Die Informationsaustauschsicht aus Abbildung 8.6 beschreibt lediglich, welche Untereinheiten des Unternehmens an welche anderen Untereinheiten welche Medien (Datenträger) liefern. Diese Sicht beschreibt also isoliert den physischen Kommunikationsfluß.

Die Dokumentenstruktursicht aus Abbildung 8.7 ist noch einfacher und beschreibt nur, welche Dokumente (Medien) welche Information enthalten. Diese Sicht legt also die Datenstrukturen im Unternehmen und ihre physische Realisierung offen.

Beachte, daß die obigen Abbildungen nur die logische Struktur einer Sicht wiedergeben. Die bei den Sitzungen eingesetzte Notation wird davon unabhängig definiert. Für alle drei Sichten steht neben einer textuellen Darstellung auch eine jeweils angemessene graphische Notation zur Verfügung.

Es werden nun von den Beteiligten Informationen über die Geschäftsprozesse eingeholt, wobei sich die Informationen von verschiedenen Beteiligten überlappen. Die bewußte Mehrfacherhebung von Informationen, oft mit Widersprüchen, ist beabsichtigt, denn sie stellt eine wichtige Grundlage für die Analyse der Anforderungen dar. Die Redundanz in den Informationen ermöglicht die Aufdeckung zahlreicher Fehler und Konflikte.

Diese Analyse kann bei der Verwendung von ConceptBase wie schon erwähnt mit Hilfe von Abfrageklassen erfolgen. Eine solche Abfrageklasse sucht gezielt nach einer bestimmten Art von Widersprüchen. ConceptBase gibt über jede Instanz der Abfrageklasse, die in der vorhandenen Informationsmenge gefunden wird, genug Information aus, um das Problem identifizieren zu können, so daß man es dann korrigieren kann.

Hier ein Beispiel: Wir suchen nach allen Medien, die an einen Agenten geliefert werden, obwohl dieser keine Aktivität ausführt, die die auf dem Medium befindlichen Daten benutzt.

QueryClass UnbenutztesMedium isA Medium with
  attribute
    nichtbenutzer : Agent
  constraint
    c:$ exists belieferung
          (belieferung in Agent!beliefert) and 
          (belieferung an nichtbenutzer) and
          (belieferung mit this) and
          not exists aktion, info
            (aktion ausgefuehrt_von nichtbenutzer) and
            (this enthaelt info) and
            ((aktion hat_als_eingabe info) or
             (aktion hat_als_ausgabe info)) $
end

Eine solche Anfrageklasse liefert als Ergebnis eine Menge von Paaren aus Medium UnbenutztesMedium und Agent nichtbenutzer. Jedes solche Paar kann verschiedene Bedeutungen haben:

• Fehler: Eine vorhandene Eingabe- oder Ausgabebeziehung für eine Aktivität ist bei der Analyse nicht erfaßt worden.
• Sichtenabweichung: Verschiedene Beteiligte (oftmals Management einerseits und Sachbearbeiter andererseits) sehen den Prozeß unterschiedlich.
• Vermeidbar: Die Situation ist tatsächlich so, daß der Agent das Medium überhaupt nicht benötigt. Der Prozeß kann optimiert werden.
• Korrekt: Die Aktivität, die das Medium empfängt, benötigt tatsächlich keine Information von diesem Medium, ist aber dennoch sinnvoll (z.B. Träger sammeln und gebündelt weitergeben).

Fälle von ,,Fehler`` und ,,Sichtenabweichung`` zeigen Probleme in der Anforderungsbestimmung an, die beseitigt werden müssen und entsprechen genau der Intention der Abfrage. ,,Vermeidbar`` zeigt quasi nebenbei eine Optimierungsmöglichkeit an. Fälle von ,,Korrekt`` sind unerwünschte Ausgaben, die deshalb auftreten, weil die Modellierung nicht alle Aspekte berücksichtigt.

Solche Abfragen können einen großen Teil aller Schwierigkeiten aufdecken, der in den ermittelten Informationen steckt. Dabei muß die Bereinigung solcher Schwierigkeiten natürlich nach wie vor von Hand gemacht werden, jedoch fällt nur noch wenig Handarbeit für die Entdeckung an, was die Sache erstens beschleunigt (und damit verbilligt) und zweitens sehr viel zuverlässiger macht. Die Abfragen lassen sich überdies meist wiederverwenden, wann immer das gleiche M2-Modell benutzt wird.

Abfragen können auch eingesetzt werden, um gezielt nach Verbesserungsmöglichkeiten im Prozeß zu suchen. Beispielsweise sucht die folgende Abfrageklasse nach Agenten, die ein Dokument erhalten, das nur solche Daten enthält, die sie auch noch auf anderen Medien erhalten.

QueryClass MehrfachVersorgter isA Agent with
  attribute
    redundant : Medium
  constraint
    c:$ exists belieferung
          (belieferung in Agent!beliefert) and 
          (belieferung an this) and
          (belieferung mit redundant) and
          forall info
            (redundant enthaelt info) ==>
              exists zweitmedium
                (zweitmedium <> redundant) and 
                (zweitmedium enthaelt info) $
end

Wiederum lassen sich die Paare aus Agent Mehrfachversorgter und Medium redundant auf mehrerlei Weise erklären:

• Unnötig: Die Versorgung wird tatsächlich als redundant angesehen und kann optimiert werden.
• Auswahl: Der Agent soll frei zwischen den Medien wählen können. Es fragt sich, ob und wann das ein sinnvoller Aufwand ist.
• Prüfung: Der Agent soll eine Gleichheitsprüfung der Daten auf den verschiedenen Medien vornehmen. Das könnte bei geeigneten Medien automatisiert werden.
• Dopplung: Der Agent soll dieselbe Tätigkeit getrennt für die gleiche Information auf verschiedenen Trägern durchführen.

Fälle von ,,Unnötig`` zeigen eine Verbesserungsmöglichkeit an. ,,Auswahl`` und ,,Prüfung`` zeigen an, daß Verbesserungsmöglichkeiten vorliegen, wenn gewisse Entscheidungen geeignet getroffen werden. Fälle von ,,Dopplung`` sind unerwünschte Ausgaben, die darauf zurückzuführen sind, daß das M2-Modell diesen Fall nicht explizit darstellen kann.

In dem hier skizzierten Beispielprojekt wurden insgesamt etwa 80 solcher Anfrageklassen benutzt, um Inkonsistenzen in den Daten, die zunächst bei der Erfassung absichtlich zugelassen wurden, konstruktiv im Analyseprozeß einzusetzen. Davon zielten 10 auf sehr spezielle Fragestellungen ab, die übrigen 70 sind so allgemein, daß sie in gleicher oder ähnlicher Form auch in anderen Projekten mit ähnlicher Fragestellung Verwendung finden können.

Zusammenfassend kann man sagen, daß ein Metamodellierungssystem von der Ausdruckskraft von ConceptBase ein leistungsfähiges Werkzeug bei der Anforderungsbestimmung darstellt. Für umfangreiche Mengen von Anforderungen bewirkt es eine enorme Arbeitsersparnis bei der Analyse der Anforderungen und erhöht die Zuverlässigkeit, mit der Probleme entdeckt werden. Allerdings muß zum Erzielen dieser Vorteile eine geeignete Metamodellierung gefunden werden, was nicht einfach ist. Schließlich kann der Deduktionsmechanismus eines solchen Systems bei größeren Datenmengen leicht zum Leistungsengpaß werden, weil nach jeder Korrektur alle oder zumindest viele der zahlreichen Suchanfragen erneut durchlaufen werden müssen.