Ansätze zur Aufgabenanalyse für soziotechnische Systeme

Inhaltsverzeichnis

1. Einleitung

2. Graphische Modellierungstechniken
2.1. einfache Techniken
2.2. Die Diagramme aus UML
2.3. Petrinetze

3. Strukturierung der Diagramme
3.1. Zerlegung in Module und in Hierarchiestufen
3.2. Patterns

4. Erweiterungen f ür soziotechnische Systeme
4.1. unpräzise Zusammenhänge in UML
4.2. Interaktion zwischen unabhängigen Abläufen

5. Fazit und Ausblick

1. Einleitung

Soziotechnische Systeme findet man überall dort, wo Menschen mit Maschinen und mit anderen Menschen interagieren. Solche Systeme entstehen meist durch eine Art evolutionären Prozess, das heißt es kommen immer wieder Menschen oder Maschinen hinzu oder verlassen das System. In jedem dieser Wachstumschritte müssen dann die Aufgaben umverteilt werden. Wir wollen hier untersuchen, wie man diese Neuvertei- lung unterstützen und planen kann, vor allem für große Systeme mit vielen Beteiligten.

Vor einem ähnlichen Problem standen die Informatiker auch. Softwareprodukte wurde meist beliebig um Funktionen für neue Anforderungen erweitert und so wuch- sen sie zu Systemen, die sehr schwer gewartet werden konnten. Es wurden Forderungen aufgestellt, dass die Entwicklung einer Software aus den Schritten: Analyse, Design, Implementierung und Test bestehen sollte. In der Analyse wird die gegebene Situation und die Aufgabenstellung untersucht. Es wird dann auch versucht, diese Informatio- nen formal zu beschreiben, um Mißverständnisse zu vermeiden. Im Design wird dann genau festgelegt, wie die Software gestaltet wird, die in der Implementierung erstellt wird. Alle diese Schritte bauen also aufeinander auf.

In den letzten Jahren haben sich einige Techniken herausgebildet, die die Softwareentwickler dabei unterstützen. Wir wollen jetzt zeigen, wie diese Techniken auf soziotechnische Systeme übertragen werden können. Dabei betrachten wir vor allem die Analyse, die dem Design stark verwand ist.

Da gerade in der Analyse Softwareentwickler und Auftraggeber bzw. Nutzer eine gemeinsame Sprache finden müssen, wenn sie über die Anforderungen und Voraussetzungen reden, basieren viele Techniken auf Graphen.

In Abschnitt 2. untersuchen wir zuerst einfache Diagramme und zwei weiterf ührende Ansätze. Danach betrachten wir in Abschnitt 3. Techniken, die zur Vereinfachung und Strukturierung der Diagramme dienen und dann in Abschnitt 4. Ansätze zu Erweiterungen speziell für soziotechnische Systeme.

2. Graphische Modellierungstechniken

2.1. einfache Techniken

Die Ergebnisse der Analyse kann man mit verschiedenen Techniken visualisieren. Dabei gibt es in vielen Anwendungsbereichen bereits etablierte Ausdrucksformen und jede dieser Form kann bestimmte Aspekte besonders gut darstellen.

Am weitesten verbreitet und wohl jedem bekannt sind die Ablaufdiagramme. Gleich ist bei jedem Anwender jedoch nur, das die Pfeile die chronologische Reihen- folge darstellen. Jedoch bereits die Beschriftung kann sich stark unterscheiden: Bei einigen Ausprägungen notiert man in den verbundenen Kästen Tätigkeiten oder Er- eignisse und in anderen werden dort Zwischenergebnisse oder Zustände dargestellt. Ebenso gibt es keine allgemeine eindeutige Syntax für die Darstellung von alternativer und paralleler Abarbeitung. Jedoch basieren alle weiterführenden Techniken zur Dar- stellung von Abläufen auf dieser Art von Diagrammen und ergänzen sie um Techniken zur Kennzeichnung diverser Eigenschaften [Par98].

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1: einfache Darstellungstechniken: Ablaufdiagramm und Baumdiagramm

ÄhnlichgrundlegendsindStrukturierungsdiagrammemitdenenbaumartigeStruk- turen dargestellt werden können. Dabei werden meist Knoten mit Linien verbunden und die verschiedenen Hierarchiestufen der Knoten durch ihre vertikale Anordnung und die Verbindungslinien dargestellt. Aber es gibt auch andere Darstellungen, in de- nen die Knoten jeweils in dem nächsthöheren Knoten gezeichnet werden. Auch hier gibt es wieder eine Reihe von Ansätzen, die diese Diagramme mit weiteren Informa- tionen anreichern.

Wir wollen aber nur zwei Ansätze weiterbetrachten: Die Modellierungsprache UML und ihre Diagramme, die in der Softwaretechnik eingesetzt wird, sowie Petrinet- ze, die gerne als mathematisches Modell aber auch zur Darstellung von Wirtschaftspro- zessen genutzt werden.

2.2. Die Diagramme aus

Die Unified Modeling Language (UML) ist eine Menge von Diagramm- und Spezifikationstechniken mit der objektorientierte Softwareentwicklung geplant werden kann. Dabei wurden viele Ansätze und Konzepte zusammengefasst, unter anderem aus der Technik Fusion und von Booch.

In UML gibt es Techniken für die Analyse und für das Design. Außerdem können die Diagramme auch noch unterschieden werden, ob sie statische oder dynamische Zusammenhänge beschreiben. Aus diesen beiden Klassen greifen wir uns einige heraus. Die statischen Zusammenhänge beschreibt das Klassen- bzw. Objektdiagramm (class/object diagram) am umfassendsten. Mit Zustandsdiagrammen (state charts) kann das Verhalten eines Objekt und mit Aktivitätsdiagrammen (activity diagram) kann das Verhalten verschiedener Objekte dargestellt werden.

2.2. Die Diagramme aus UML 5

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2: Ein Objektdiagramm aus

Objekte sind die Repräsentanten von realen und gedachten Gegenständen in der Software. Gleichartige Objekte können zu Klassen zusammengefasst werden, daher sind sich Objekt- und Klassendiagramm sehr ähnlich obwohl sie aus verschiedenen Planungsstufen kommen. Ein Objekt wird immer in einem Kasten mit seinem Namen, seiner Klasse, seinen speziellen Eigenschaften - den Attributen - und seinen Funktio- nen dargestellt. Weiter gibt es noch einfache Beziehungen zwischen den Objekten, die mit einen Namen bezeichnet werden. Außerdem existieren die speziellen Beziehun- gen Aggregation und Komposition, die in verschiedenen Stärken eine ,,ist Teil von”- Beziehung darstellen. Speziell für die Klassendiagramme existiert eine Vererbungs- beziehung (Eine Klasse kann dann Attribute, Funktionen und Beziehungen von einer anderen übernehmen). In Abbildung 2 ist ein solches Objektdiagramm zu sehen.

Wenn es ein größeres Programm zu schreiben gilt, wird das Objektdiagramm sehr unübersichtlich. Dieses Problem kann aber mit den Strukturierungstechniken in UML, die in Abschnitt 3.1. vorgestellt werden, umgangen werden.

Wie sich die Objekte in einer bestimmten Situation verhalten gibt das Akti- vitätsdiagramm an. Es ist ein Ablaufdiagramm, in dem Zustände dargestellt werden. Diese Zustände stellen aber eine Verarbeitungssituation im Rechner dar, sie kenn- zeichnen also eher Tätigkeiten. Man nennt sie auch Aktivitätszustände [Par98]. Au-ßerdem sind teilweise an den Verbindungen zu möglichen Nachfolgezuständen Bedin-

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3: Zustandsdiagramm (links) und Aktivitätsdiagramm

gungen angegeben. Der Ablauf ist hierbei klar durch die eindeutige Zuordnung von einem Nachfolgezustand bzw. durch die Bedingungen erkennbar. Wenn der jeweile Aktivitätszustand beendet ist, erfolgt automatisch der Übergang in den nächsten Zu- stand. Wenn die Zustände nach der zeitlichen Abarbeitung untereinander geschrieben werden, kann man das Diagramm horizontal in Streifen teilen. In jeder dieser so ge- nannten Schwimmbahnen werden dann alle Zustände und Übergänge gezeichnet, die zu einem bestimmten Objekt oder Teilsystem gehören. Damit kann man recht einfach Verantwortlichkeiten aufzeigen.

Zustandsdiagramm sind vom Aufbau her gleich. Jedoch kennzeichnen sie nur das Verhalten eines einzelnen Objektes. Die Zustände hier sind eher Wartezustände, da ein Übergang immer nur bei einem extern oder intern ausgelösten Ereignis erfolgt also nicht automatisch wie bei dem Aktivitätsdiagramm. Durch diesen Übergang können wieder Ereignisse und Berechnungen ausgelöst werden. Da in einem komplexen Ob- jekt sehr viele Zustände zu betrachten sind, ist es hier auch möglich, einen Teilablauf zu einem allgemeineren Zustand zusammenzufassen. So kann man zuerst eine grobe Übersicht über die allgemeinen Zustände geben und dann direkt in den Zustandskästen die eigentlichen Abläufe zeichnen. Wenn jetzt ein Objekt mehrere Abläufe paralell verarbeitet, werden die jeweiligen Teildiagramme durch eine gestrichelte Linie abge- grenzt. Ein anderer Ansatz, der aber schon eine Erweiterung der UML-Technik ist, ist es einen Übergangspfeilmit zwei Zielen mit einem schwarzen Balken zu kennzeich- nen. Dieser teilt den Kontrollfluß auf, ein Pfeil mit zwei Anfängen und einem Ziel vereinigt die Kontrollflüsse wieder.

Dagegen stellt das Aktivitätsdiagramm das Verhalten des Gesamtsystems dar. Auch ist bei Zustandsdiagrammen vorgestellte Strukturierung hier eigentlich nicht erlaubt, dazu aber in Abschnitt 3.1. mehr.

Die weiteren Diagramme und Wege zu ihrer Erstellung werden zum Beispiel in [Par98] oder in einem der vielen anderen Bücher zu UML aufgeführt. UML ist das Er- gebnis der Bemühungen Design und Analyse von Softwareprojekten zu vereinfachen. Jedoch wurde in UML darauf verzichtet, den Diagrammen zu viel Aussagekraft zu

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4: Ein Petrinetz vor und nach dem Schalten von zwei Transitionen

geben. UML definiert nur den Syntax der Diagramme, um offen für zukünftige Ent- wicklungen zu sein. Das können wir nutzen, um die UML-Techniken für die Analyse von soziotechnischen Systemen zu nutzen. So lassen sich die Objekte im Objektdia- gramm auch als Stellvertreter für Menschen oder Maschinenschnittstellen betrachten und in den Aktivitätsdiagrammen auch Handlungsabläufe darstellen. In Abschnitt 4.1. werden wir eine entsprechende Erweiterung für Aktivitätsdiagramme untersuchen.

2.3. Petrinetze

Petrinetze wurden in den 60er Jahren von Carl Adam Petri entwickelt und stellen eine exakt definierte Art von Ablaufdiagrammen dar. [Pet62] Besonders parallel ablaufende Prozesse lassen sich damit gut nachbilden.

Die Idee ist, verschiedene Arten von Knoten für Zustände und Tätigkeiten ein- zuführen. Es gibt also Kreise - die Stellen - die Zustände darstellen und es gibt Recht- ecke - die Transitionen - die Tätigkeiten darstellen können. Es gibt gerichtete Verbin- dungen von Stellen zu Transitionen. Die Stellen, die so mit einer Transition verbunden sind, heißen Vorbereich der Transition. Außerdem gibt es gerichtete Verbindungen von Transitionen zu Stellen, diese Stellen heißen dann Nachbereich der Transition. Die Net- ze heißen daher auch Stellen-Transitions-Netze oder Place-Transition-Nets (PT-Nets).

Eine weitere Besonderheit sind die Token - meist kleine schwarze Punkte - die sich auf Stellen befinden können. Zu jedem Petrinetz gibt es eine Anfangsbelegung mit Token. Dann kann jede Transition schalten, bei der auf jeder Stelle im Vorbereich ein Token liegt. Wenn eine Transition schaltet, wird ein Token von jeder Stelle im Vorbereich abgezogen und je ein Token auf die Stellen im Nachbereich verteilt. Wenn mehrere Transitionen schalten könnten, ist nicht definiert welche schaltet, hier kann der Zufall entscheiden.

[...]