Ansätze zur Aufgabenanalyse für soziotechnische Systeme

INHALTSVERZEICHNIS

2

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 . . . . . . . . . . . . . 9

3.2. Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

4. Erweiterungen f ¨ ur soziotechnische Systeme 13

4.1. unpr¨ azise Zusammenh¨ ange in UML . . . . . . . . . . . . . . . . . . 13

4.2. Interaktion zwischen unabh¨ angigen Abl¨ aufen . . . . . . . . . . . . . 15

5. Fazit und Ausblick 18

3

1. Einleitung

Soziotechnische Systeme findet man ¨ uberall dort, wo Menschen mit Maschinen und mit anderen Menschen interagieren. Solche Systeme entstehen meist durch eine Art evolution¨ aren Prozess, das heißt es kommen immer wieder Menschen oder Maschinen hinzu oder verlassen das System. In jedem dieser Wachstumschritte m¨ ussen dann die Aufgaben umverteilt werden. Wir wollen hier untersuchen, wie man diese Neuvertei- lung unterst¨ utzen und planen kann, vor allem f¨ ur große Systeme mit vielen Beteiligten. Vor einem ¨ ahnlichen Problem standen die Informatiker auch. Softwareprodukte

wurde meist beliebig um Funktionen f¨ ur 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¨ andnisse 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 Soft- wareentwickler dabei unterst¨ utzen. Wir wollen jetzt zeigen, wie diese Techniken auf soziotechnische Systeme ¨ ubertragen werden k¨ onnen. 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¨ ussen, wenn sie ¨ uber die Anforderungen und Vorausset- zungen reden, basieren viele Techniken auf Graphen.

In Abschnitt 2. untersuchen wir zuerst einfache Diagramme und zwei weiter-

f¨ uhrende Ans¨ atze. Danach betrachten wir in Abschnitt 3. Techniken, die zur Verein- fachung und Strukturierung der Diagramme dienen und dann in Abschnitt 4. Ans¨ atze zu Erweiterungen speziell f¨ ur soziotechnische Systeme.

2. Graphische Modellierungstechniken

2.1. einfache Techniken

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

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¨ agungen notiert man in den verbundenen K¨ asten T¨ atigkeiten oder Er- eignisse und in anderen werden dort Zwischenergebnisse oder Zust¨ ande dargestellt. Ebenso gibt es keine allgemeine eindeutige Syntax f¨ ur die Darstellung von alternativer und paralleler Abarbeitung. Jedoch basieren alle weiterf¨ uhrenden Techniken zur Dar- stellung von Abl¨ aufen auf dieser Art von Diagrammen und erg¨ anzen sie um Techniken zur Kennzeichnung diverser Eigenschaften [Par98].

2. GRAPHISCHE MODELLIERUNGSTECHNIKEN

4

Abbildung 1: einfache Darstellungstechniken: Ablaufdiagramm und Baumdiagramm

¨ Ahnlich grundlegend sind Strukturierungsdiagramme mit denen baumartige Struk- turen dargestellt werden k¨ onnen. 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¨ achsth¨ oheren Knoten gezeichnet werden. Auch hier gibt es wieder eine Reihe von Ans¨ atzen, die diese Diagramme mit weiteren Informa- tionen anreichern.

Wir wollen aber nur zwei Ans¨ atze 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 UML

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

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

2.2. Die Diagramme aus UML

5

Abbildung 2: Ein Objektdiagramm aus UML

Objekte sind die Repr¨ asentanten von realen und gedachten Gegenst¨ anden in der Software. Gleichartige Objekte k¨ onnen zu Klassen zusammengefasst werden, daher sind sich Objekt- und Klassendiagramm sehr ¨ ahnlich 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¨ arken eine ,,ist Teil von”- Beziehung darstellen. Speziell f¨ ur die Klassendiagramme existiert eine Vererbungs- beziehung (Eine Klasse kann dann Attribute, Funktionen und Beziehungen von einer anderen ¨ ubernehmen). In Abbildung 2 ist ein solches Objektdiagramm zu sehen.

un¨ ubersichtlich. 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¨ atsdiagramm an. Es ist ein Ablaufdiagramm, in dem Zust¨ ande dargestellt werden. Diese Zust¨ ande stellen aber eine Verarbeitungssituation im Rechner dar, sie kenn- zeichnen also eher T¨ atigkeiten. Man nennt sie auch Aktivit¨ atszust¨ ande [Par98]. Au- ßerdem sind teilweise an den Verbindungen zu m¨ oglichen Nachfolgezust¨ anden Bedin-

2. GRAPHISCHE MODELLIERUNGSTECHNIKEN

6

Fehlerbehandlungs-

Verarbeitungs-

Abbildung 3: Zustandsdiagramm (links) und Aktivit¨ atsdiagramm

gungen angegeben. Der Ablauf ist hierbei klar durch die eindeutige Zuordnung von einem Nachfolgezustand bzw. durch die Bedingungen erkennbar. Wenn der jeweile Aktivit¨ atszustand beendet ist, erfolgt automatisch der ¨ Ubergang in den n¨ achsten Zu-

stand. Wenn die Zust¨ ande 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¨ ande und ¨ Uberg¨ ange gezeichnet, die

zu einem bestimmten Objekt oder Teilsystem geh¨ oren. Damit kann man recht einfach Verantwortlichkeiten aufzeigen.

Zustandsdiagramm sind vom Aufbau her gleich. Jedoch kennzeichnen sie nur das Verhalten eines einzelnen Objektes. Die Zust¨ ande hier sind eher Wartezust¨ ande, da ein ¨ Ubergang immer nur bei einem extern oder intern ausgel¨ osten Ereignis erfolgt also nicht automatisch wie bei dem Aktivit¨ atsdiagramm. Durch diesen ¨

Ubergang k¨ onnen wieder Ereignisse und Berechnungen ausgel¨ ost werden. Da in einem komplexen Ob- jekt sehr viele Zust¨ ande zu betrachten sind, ist es hier auch m¨ oglich, einen Teilablauf zu einem allgemeineren Zustand zusammenzufassen. So kann man zuerst eine grobe ¨ Ubersicht ¨ uber die allgemeinen Zust¨ ande geben und dann direkt in den Zustandsk¨ asten die eigentlichen Abl¨ aufe zeichnen. Wenn jetzt ein Objekt mehrere Abl¨ aufe 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 ¨ Ubergangspfeil mit zwei Zielen mit einem schwarzen Balken zu kennzeich- nen. Dieser teilt den Kontrollfluß auf, ein Pfeil mit zwei Anf¨ angen und einem Ziel vereinigt die Kontrollfl¨ usse wieder.

Dagegen stellt das Aktivit¨ atsdiagramm 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¨ ucher zu UML aufgef¨ uhrt. UML ist das Er- gebnis der Bem¨ uhungen Design und Analyse von Softwareprojekten zu vereinfachen. Jedoch wurde in UML darauf verzichtet, den Diagrammen zu viel Aussagekraft zu