Design-Pattern als Kommunikationsmechanismen in der Software-Entwicklung
←
→
Transkription von Seiteninhalten
Wenn Ihr Browser die Seite nicht korrekt rendert, bitte, lesen Sie den Inhalt der Seite unten
Wirtschaftsuniversität Wien
Institut für Informationswirtschaft
PS: Bakkalaureat Wirtschaftsinformatik: Informationswirtschaft - Seminar
mit Bachelorarbeit
Seminarleiter/in: PD Mag. Dr. Stefan Koch
im Wintersemester 2008
Design-Pattern als
Kommunikationsmechanismen in der
Software-Entwicklung
Dalibor Jonic
Bachelorarbeit
Matrikel-Nummer: 0152281
Abgabedatum: 15.02.2009Zusammenfassung
Die Design Pattern (Entwurfsmuster) fördern die effiziente und effektive
Entwicklung von Software. Es gibt viele Gründe für die Verwendung von
Entwurfsmustern, insbesondere auf die Modularität, Wiederverwendbarkeit
und Erweiterbarkeit der Software bezogen. Jede qualitativ hochwertige
Software-Architektur sollte zumindest diese drei Komponenten umfassen.
Durch präzise gewählte Design-Patterns werden Lösungsansätze für
bestimmte Software-Probleme dargestellt. Einer der wesentlichen Vorteile
bei der Nutzung von Software-Design-Patterns ist die verbesserte
Teamkommunikation. Ein gemeinsames Design-Pattern führt zu einer
verkürzten Aufklärungsphase und der ausgewogenen „Getter und Setter“
Anfragen zwischen Gruppenmitglieder während der Entwicklungsphase.
Sowohl fortgeschrittene als auch unerfahrene Entwickler, welche mit
Baustilen oder Design-Paradigmen tätig sind, profitieren von solchen
Mustern. Frameworks, als nicht komplette Softwaresysteme, die von
Experten für Nicht-Experten hergestellt werden, basieren genauso auf
vorgegebenen Design Pattern. Diese Bachelorarbeit beschäftigt sich mit
der Frage, in wie weit sich ein Entwurfsmuster der Kommunikation
zwischen Gruppenmitglieder verbessert und dadurch die tatsächliche
Software-Entwicklung beschleunigt. Es werden mehrere Experimente
berücksichtigt, welche für die Bestätigung der Hypothese herangezogen
werden. Gleiche sind Recherchen und Ergebnisse der Studien von
jeweiligen Autoren. Ein „Best Practice“ Pattern wird auch analysiert und
erörtert.
Stichwörter: Muster, Design, Modell, Wiederverwendung,
Softwareentwicklung, Framework, Beans, Expertenwissen, Konsequenzen
Abstract (English)
Design patterns help in the efficient and effective development of
software. There are many reasons for using design patterns, especially
related to the modularity, re-usability and expandability of software. Each
good software architecture should at least contain these three properties.
Precisely selected design patterns are solutions for certain software
problems. One of the key advantages in the use of software design
patterns is improved team communication. A common design pattern
leads to a shortened developing time and balanced getter and setter
requests between group members, during the development process. Both,
advanced and novice developers, which are involved in designing or
architectural paradigms, get for sure benefit from such patterns. This
bachelor thesis deals with the question of how communication improves
between group members using patterns, and thereby how the whole
software development is getting better. There are several experiments
described, which should confirm the hypothesis on pattern usage. This are
the results of researcher and studies of authors listen below. A best
practice pattern is also analyzed and discussed.
Keywords: Design Pattern, Model, Software Reuse, Development,
2Framework, Beans, Expertise, Consequences
3Inhaltsverzeichnis
Einführung...................................................................................................................................5
2 Pattern Definition und Eigenschaften......................................................................................6
2.1 Konzept der Pattern.....................................................................................................6
2.2 Verwendung von Pattern.............................................................................................7
2.3 Das Design Pattern.......................................................................................................9
2.4 Model, View, Controller Pattern...............................................................................12
2.5 Modelle, Klassifizierung............................................................................................15
2.6 Framework.................................................................................................................17
3 Kommunikation......................................................................................................................19
3.1 Soziale Struktur.........................................................................................................19
3.2 Kommunikation: Argumentation für Maßnahmen....................................................22
3.3 Koordination: die Planung von Aktionen..................................................................25
3.4 Kooperation: Schaffung in dem gemeinsamen Arbeitsumfeld..................................26
3.5 Die Pattern Rolle........................................................................................................29
3.5.1 Auswahl von Pattern ..............................................................................................30
3.5.2 Design Pattern verbessern die Kommunikation......................................................31
3.5.3 Weitere Vorteile, Nachteile von Patterns...............................................................34
4 Praktisches Beispiel...............................................................................................................35
4.2 Fallbeispiel ................................................................................................................35
4.3 Nutzung von Beans....................................................................................................35
5 Zusammenfassung..................................................................................................................39
Literaturverzeichnis.........................................................................................................40
Abbildungsverzeichnis
Abbildung 1: Raum.....................................................................................................................6
Abbildung 2: Integrierte Muster (Mustersprache).......................................................................7
Abbildung 3: Klassifizierung von Muster (nach "The Gang of Four" [GHJ04])......................15
Abbildung 4: Das Kommunikationsmodell von Shannon/Weaver [PRW03] .........................19
Abbildung 5: Die Rollen der Software-Entwicklung................................................................20
Abbildung 6: Die Rollen der Software-Entwicklung ii [CaCo96]............................................21
Abbildung 7: Zentrale und Dezentrale Kommunikationsnetze [ROS87].................................23
Abbildung 8: Lineare-, Hierarchische- und Netzform [ROS87]...............................................24
Abbildung 9: Software-Entwicklungszyklus (Design Pattern unterstützen 3K)[GHJ04].........29
Abbildung 10: Ergebnisse: Kommunikationslinie der Gruppe 1, 3, 4 in der Pre- (links) und
Posttest (rechts) Phase [UNT00]...............................................................................................33
Abbildung 11: Entwicklerumgebung NetBeans IDE, Projektbeispiel......................................36
Abbildung 12: View, Model und Controller Codebeispiel.......................................................38
Tabellenverzeichnis
Tabelle 1: Kollaborations-Technologie [AND03]....................................................................28
Tabelle 2: Pre- und Posttest (nach [UNT00])...........................................................................32
4Einführung
Diese Arbeit ist im Rahmen der Lehrveranstaltung „Informationswirtschaft
VK6“ im WS 2008/2009 an der Wirtschaftsuniversität Wien entstanden.
Der Fokus dieser Arbeit liegt auf der Nutzung von Design Pattern
(Entwurfsmuster) in der Praxis, speziell deren Zusammenhang mit den
Kommunikationsprozessen in der Softwarebranche. Als Beispiel für ein
Entwurfsmuster behandelt diese Bachelorarbeit die MVC (Model, View,
Controller) Pattern, welche ursprünglich von der Programmiersprache
Smalltalk in den 80er Jahren entwickelt wurde und mittlerweile einen
Grobentwurf für viele komplexe Softwaresysteme darstellt.
Nach einer Definition des Begriffs „Design Pattern“ wird im ersten Teil die
Theorie aufgearbeitet und anschließend eine Klassifizierung der Arten von
Entwurfsmuster vorgenommen. Es werden dem Leser Ansätze über die
soziale Struktur, Kommunikation, Kooperation und Koordination in der
Software-Entwicklung näher erläutert. Danach wird es verstärkt in die
Verbreitung und Nutzung von Design Patterns in der Praxis eingegangen,
wobei versucht wird herauszufinden, in welchen Ausmaß die vorgelegten
Entwurfsmuster die Kommunikation der Entwickler begünstigen und
welche Trends hier existieren. Weiters wird die Frage, welchen Einfluss die
Entwurfsmuster auf die Projektteilnahme und welche Intensität die
Nutzung von Software haben, angesprochen.
Design Pattern (Entwurfsmuster) helfen dabei, auf Basis Erfahrungen
anderer, im bestem Fall einer kollektiven Erfahrung der qualifizierten
Experten, Problemstellungen auf ähnliche Weise zu lösen, daher ist diese
Arbeit auch für ein kompaktes Anlernen des Pattern Konzeptes gut
geeignet. Design Pattern erfassen die bestehende Erfahrung einer
Software und fördern mit der Wiederverwendung ein gutes Design in der
Praxis. Jedes Muster befasst sich mit einem bestimmten, immer
wiederkehrenden Problem, welches in der Gestaltung und die Umsetzung
von Software-Systemen auftritt. Diese Patterns sind daher sehr gut für den
Bau von Softwarearchitekturen mit spezifischen Eigenschaften geeignet.
Schließlich gibt es eine Zusammenfassung der Erkenntnisse aus dem
Fallbeispielen welche die Hypothese der Güte von Design Pattern über die
Förderung von Kommunikation in der Software-Entwicklung bestätigen
soll. Ein Resümee am Ende der Arbeit soll dem Leser nochmals einen
Überblick über das behandelte Themengebiet verschaffen und die
Erkenntnisse daraus wieder einmal beleuchten.
52 Pattern Definition und Eigenschaften
2.1 Konzept der Pattern
Im Vordergrund jeder Entwicklung stehen Probleme die zu lösen sind.
Wenn Experten an einem Problem arbeiten ist es sehr unwahrscheinlich,
dass sie komplett neue Lösungsansätze für diese Problemstellung
entwerfen. In den realen Bedingungen wird der Experte ihm bekannte
Lösungswege durch immer wieder Anwenden und womöglich bestimmtes
Erfahrungswissen erneut geltend machen. Dadurch unterscheidet sich
auch der Experte von anderen Menschen [Hah97].
Verallgemeinert werden Muster nach bestimmten Bedürfnissen konzipiert.
Die Patterns wurden zuerst von einem in Wien geborenen Architekt,
Christopher Alexander, in seinem Buch „The Timeless Way of Building“
[Ale79] wie folgt definiert:“Jedes Muster ist eine dreiteilige Regel, die eine
Beziehung zwischen einem bestimmten Kontext, einem Probleme und
einer Lösung beschreibt.“ [Siehe Ale79, S.247] Christopher Alexander
bereitete Pattern für die Planung von Gebäuden und Städten und arbeitete
als Architektur-Professor an der Barkeley Universität. In diesem
Sachverhalt hat weiteres Muster eine bestimmte Menge an Kräften und
eine bestimmte räumliche Konfiguration, in der diese Kräfte ausgeglichen
sind.
Um es abstrakter zu deuten, erklärt Christopher, dass ein Muster zugleich
ein Ergebnis ist, das in globaler Welt stattfindet, aber auch eine Regel,
welche sagt, wie wir das Ergebnis hervorrufen können bzw. wann wir es
tun sollen. Es repräsentiert gleichzeitig ein Objekt, aber auch eine
Beschreibung des Prozesses zur Erzeugung des Objektes [ALE79].
Die Erkenntnisse wurden im Kontext der Bedürfnisse erstellt und dadurch
abstrakte Lösungsansätze entwickelt. Beispielsweise (siehe Abb.1) möchte
sich ein Mensch in Winterzeiten zuhause gern hinsetzen und es sich
bequem machen. Zusätzlich möchte er es in dem Raum warm haben. Es
heißt, man braucht einen Heizkörper in der Nähe. Problem: wenn ein
anderes Raum, in den man am liebsten die Zeit verbringen möchte, über
keine Heizkörper verfügt, so ist dieses Konflikt nicht lösbar. Daher: man
soll in jedem Raum zumindest einen Heizkörper besitzen, um eine
Wärmequelle für einen gemütlichen Sitzplatz zu gewährleisten. Mit der
Abstraktion von Problem-Lösungs-Paaren, erfolgen Ausformulierungen
welche zu Mustern führen. Dadurch wird es sowohl für die Probleme als
auch für die Lösungen ein Muster erkennbar.
Abbildung 1: Raum
6Ein Pattern-Katalog ist eine Sammlung von selbsterklärenden Mustern,
welches keine oder nur wenige Verbindungen zwischen anderen Mustern
beinhaltet. Der bekannteste Musterkatalog ist der von „Gang of Four“
[GHJ04]. Eine Muster-Enzyklopädie ist ein Index von Mustern. Die „Pattern
Almanac“ [RIS00] ist eine Muster-Enzyklopädie, dass alle Muster als
Indizes dokumentiert. Ein Pattern-System ist eine Sammlung
selbsterklärender Muster, wo jedes Muster auch eine Beziehung auf ein
oder alle andere Muster haben, die potentiell bei der Unterstützung helfen
können. Als Hilfe einer schnellen Durchsuchung zu einem bestimmten
Muster, alle Muster sind nach bestimmten Kriterien in einem System
kategorisiert, wie zum Beispiel nach Problemen oder Granularität.
Bekannteste Systemmuster sind die POSA (Pattern-Oriented Software
Architecture) Bücher [BMR+98]. Die Mustersprache (siehe Abb. 2) ist ein
Netz von eng integrierten Mustern, welche zusammen bei der Entwicklung
bestimmter Aufgaben, Teile davon und Anwendungen wirken. Kein Muster
ist für sich selbst isoliert. Der Server-Component Patterns Buch [VSW02]
und die Best Practice Pattern von Smalltalk [BEC96], erläutern am besten
die Mustersprachen.
Abbildung 2: Integrierte Muster (Mustersprache)
2.2 Verwendung von Pattern
Diese Bachelorarbeit beschäftigt sich mit Mustern welche mehr in der
Software-Entwicklung relevant sind, die sogenannten Design Patterns
(Entwurfsmuster). Es wird nicht der objektorientierte Ansatz der
Softwarearchitekturen erklärt, sondern vielmehr die Bedeutung von
Mustern in einem objektorientiertem System.
Die Mustersprache wurde vermutlich von Christopher Alexander und
seinen Mitarbeitern erstmals offiziell als Mittel zur Konstruktion von
Städten und Gebäuden eingesetzt [siehe ASA+75]. Diese Ideen wurden
dann übernommen und erfolgreich in objektorientierten, komplexen
Systemen eingesetzt. Somit stellen die Softwareentwurfsmuster ein Mittel
dar, welches von anderen wissenden Experten und Architekten nutzbar
geworden sind.
Michael Hahsler diskutiert die breite Verwendbarkeit und die Nutzung von
Mustern in unterschiedlichen Disziplinen [Hah01]. Danach sind Patterns
oft unbewusst angewandt und kommen sogar in der Jazzmusik vor. Andere
7Bereiche sind Strategien, Kriegsführung [Tzu, 1983], das Management von
Organisationen und das Verständnis von kognitiven Prozessen, aber diese
kommen auch, einleitend zu dem nächsten Abschnitt 2.3, in die
Entwicklung von wiederverwendbarer Software vor.
Bei der Verwendung von Patterns, sollen diese die unveränderlichen
Merkmale eines Systems zeigen, welche das Problem lösen [ALE79,
S.257], und auch diejenigen Merkmale welche gute von schlechten
Objekten unterscheiden [ALE79, S.260]. Alle Patterns sind durch
Beobachtungen herleitbar. Man geht von positiven und negativen
Beispielen aus. Damit man die Muster voneinander unterscheiden kann,
sind bei der Verwendung vier grundlegende Elemente zu erkennen [nach
GHJ04]:
1. Der Mustername (eng. Name), welches als Stichwort dargestellt
und benutzt wird, das Entwurfsproblem samt Lösungen und
Auswirkungen mit ein oder zwei Worten zu benennen. Durch diese
Benennung ist es einfacher über die Vor- und Nachteile
nachzudenken und diese an andere zu vermitteln. Das
Namenselement ist auch das schwierigste Teil bei der Bestimmung,
weil gute und repräsentative Namen nicht einfach zu finden sind.
2. Als nächstes besitzen Muster den Problemabschnitt, welches das
Problem und seinen Kontext beschreibt. Diese Probleme sind
beispielsweise die Trennung einer Schnittstelle von einer Anzahl
möglicher Implementierungen, die Einbindung von Altsystem-
Klassen oder die Abschirmung eines Aufrufers von Änderungen bei
spezifischen Plattformen. Damit nun die Anwendung des Musters
sinnvoll ist, wird in der Problembeschreibung auch eine Liste von
Bedingungen aufgeführt, welche erfüllt sein müssen, damit ein
Problem zustande kommt.
3. Der Lösungsteil beschreibt die Objekte, aus denen das Pattern
besteht, und wie die Beziehungen, Kräfte (Alexander nennt diese
Forces) sowie Interaktionen zwischen diese Objekte agieren. Eine
bestimmte, konkrete Gestaltung und Umsetzung des Musters wird
nicht erläutert, da ein Muster vielmehr als eine Vorlage dient, welche
in vielen verschiedenen Situationen angewendet werden kann.
4. Der Konsequenzenanschnitt erklärt die Folgen bei den
Anwendungen dieser jeweiligen Muster durch eine Liste von Vor- und
Nachteilen des Endentwurfs. Die Wiederverwendung ist oft ein
bedeutender Faktor in der objektorientierten Systemen, daher
tragen diese Konsequenzen auf einem System eine wesentliche
Rolle für die Modularität, Flexibilität und die Erweiterbarkeit des
Systems. Die Konsequenzenerläuterung ist ein wichtiger Aspekt um
überhaupt die passenden Pattern auszuwählen.
Mit den angesprochenen Charakteristiken werden Mustern verfeinert und
einfacher verstanden. Schließlich bleibt jedem die Freiheit jeweiliges
Muster, nachdem der Konsequenzen-Teil anvisiert wurde, zu verwenden
8oder auch abzulehnen.
2.3 Das Design Pattern
Das Entwurfsmuster sind Lösungsmuster für unterschiedliche Probleme in
der Software Entwicklung, welche wiedererkannt werden. Ein
Entwurfsmuster besteht aus wenigen Klassen, die durch den Einsatz von
Delegation und Vererbung eine robuste und modifizierbare Lösung
ermöglichen. Diese Klassen können für das zu erstellende System
angepasst und verfeinert werden.
Die am breitesten beschriebenen Ansätze über die Design Pattern wurden
im Buch von Erich Gamma und seinen Mitautoren [GHJ04] erläutert. Im
Weiteren werden eingehend auf den vorherigen Abschnitt die
Erweiterungen von Design Pattern gegenüber der allgemeinen Muster
beschrieben. Es werden die zwei Sichten von Frank Buschmann und
Christiane Löckenhoff auf der einen Seite und die von Erich Gamma mit
seinen Kollegen assimiliert, um eine wohlgeformte Form eines Designs
Muster zu erhalten. Diese Pattern sind [nach Gamma et al; BMR+96] in
einer wohlgeformten Form konzipiert und sehen folgendermaßen aus:
1. Name der Pattern
Korrespondiert den letzten Abschnitt, daher werden präzise
ausgewählte Wörter angewandt, welche auf die Essenz der
Entwurfsmuster hindeuten. Jedes Muster soll eine einzigartige
Beschriftung haben, dadurch wird das Muster leicht identifizierbar
und referenzierbar. Eine Klassifizierung nach Typ kann hier auch
erfolgen.
2. Ziel
Hier findet eine Beschreibung des Musterzwecks statt. Es wird
nachgefragt welche Problemarten das Muster behandeln.
3. Auch bekannt als
Alle anderen Bezeichnungen für ein und dasselbe Muster in der
Literatur folgen hier, falls es solche gibt.
4. Motivation
Ein Problem wird mit einem Beispiel beschrieben, welches zeigt, wo
das Muster konkret passen würde.
5. Anwendbarkeit
Es zeigt eine allgemeine Vorstellung von den Situationen (den
Kontext), in denen das Entwurfsmuster angewandt werden kann.
6. Struktur
Eine grafische Darstellung der Struktur des Musters, zum Beispiel
mit Klassendiagrammen und Funktionsdiagrammen.
97. Rollen
Eine Liste von Klassen / Objekten welche für die Muster relevant sind
und deren Rolle beschrieben wird.
8. Interaktionen
Beschreibt die Interaktionen zwischen den Rollenteilnehmer.
9. Folgen
Definieren die Ergebnisse, Nebenwirkungen und Erwägungen bei der
Verwendung und Einsetzung von Muster.
10. Umsetzung
Beschreibt die Umsetzung der Muster, mit einer Diskussion der
verwendeten Technik.
11. Beispiellösung
Es wird eine Beschreibung des Prinzips der Lösung auf der
abstrakten Ebene erläutert.
12. Bekannte Anwendungen
Bekannte Beispiele für Situationen, in denen das Muster angewandt
wird.
13. Verwandte Muster
Beschreibt Muster im Zusammenhang mit dem aktuellen Muster und
in welcher verwandten Beziehung diese stehen (zum Beispiel ist das
Muster als Alternative verwendbar oder kann zusammen mit den
anderen verwendet werden). Es beschreibt auch die Unterschiede
mit ähnlichen Mustern.
Die obige Beschreibung sollte den Entwicklern genügend Informationen
zur Verfügung anbieten für eine Entscheidung anbieten, ob das Muster
(möglicherweise) nützlich für ein Problem sein könnte. Einige der oben
erwähnten Musterelemente sind nicht zwanghaft. Der Rest der
Beschreibung umfasst eine Lösungsstruktur und eine grafische
Darstellung. Die Struktur der Lösung wird in der Regel von Rollen
vorgehen, die verteilt werden sollten (Beispiel Klassen). Ein Szenario
Diagramm, in dem die Kommunikation zwischen den Teilnehmer und eine
textuelle Erklärung angezeigt wird. Für die Lösungserklärung wird in der
Regel ein Diagramm erstellt, dieses setzt die Grundkenntnisse der UML
Sprache (Unified Modelling Language) voraus. Einige Beispiele werden im
nächsten Abschnitt weiter behandelt.
10Eine Lösung, die in den Mustern beschrieben ist, wird in der Regel mit
einer schematischen, strukturierten Darstellung illustriert. In der Literatur
wird der Lösungsabschnitt meist in UML-Format repräsentiert. Der Zweck
solcher Abbildungen ist, dem Leser einen schnellen Überblick zu
gewährleisten und Einblicke in die Rollen, Klassen und Objekte der Muster,
sowie deren Wechselwirkungen Einblicke zu verschaffen. Das Diagramm
unten ist von [Gamma94] und zeigt die Struktur einer Observer Pattern.
Musterbeispiel: Beobachter (Observer) (nach [GHJ04])
Name Beobachtermuster (eng. Observer)
Problem- Aufrechterhaltung konsistenter Zustände bei einem
beschreibung Subjekt und vielen Beobachtern
Lösung Ein Subjekt ist ein Objekt, dessen Hauptaufgabe darin
besteht, einen Zustand zu verwalten - beispielsweise eine
Matrix. Ein oder mehrere Beobachter nutzen den
beispielsweise durch Anzeigen einer Matrix als Tabelle
oder Grafik. Damit entstehen Redundanzen zwischen den
Zuständen des Subjekts und den Beobachtern.
Inkonsistenzen werden verhindert, indem die Beobachter
die meldeAn() -Methode aufrufen, um sich bei einem
Subjekt zu registrieren. Jede KonkreterBeobachter-Klasse
definiert außerdem eine aktualisiere()-
Methode, die den Zustand zwischen dem Subjekt und dem
KonkreterBeobachter-Objekt synchronisiert. Sobald sich
der Zustand von einem Subjekt ändert, ruft es seine
benachrichtigen()- Methode auf, die iterativ jeden
Beobachter aufruft. aktualisiere()- Methode aufruft.
11Konsequenzen ⧫ Entkoppelt ein Subjekt von den Beobachtern.
⧫ Kann viele ungewollte Benachrichtigungen verursachen,
wenn sich der Zustand eines Subjekts ändert, da auch
jene Zustandsänderungen mitgeteilt werden, die für
manche Beobachter nicht von Interesse sind.
Beispiele ⧫ Java stellt das Beobachtermuster mit der Observer-
Schnittstelle und der Observable-Klasse zur
Verfügung.
⧫ Das Beobachtermuster kann eingesetzt werden, um die
Benachrichtigung von Abonnenten in der Modell-Sicht-
Steuerungs-Architektur zu realisieren.
Verwandtes ⧫ Entitäts-, Grenz- und Steuerungsobjekte
Konzept
In dem Musterbeispiel sind vier Rollen (Subjekt, Konkretes Subjekt,
Beobachter, Konkreter Beobachter) und die Beziehungen zwischen ihnen
zu sehen. UML bietet die Möglichkeiten in den Mustern auf die
Rollenkooperationen einzugehen. Die zu kooperierenden Objekte und
deren Kommunikation werden daher in visualisierter Abbildung gebracht.
Man könnte Muster mittels UML auch für sehr große Designs entwerfen.
2.4 Model, View, Controller Pattern
Musterbeispiel: MVC (nach [BMR+98])
Name Model-View-Controller Muster
Problem- Eine Benutzerschnittstelle ändern (womöglich zur
beschreibung Laufzeit). Verschiedene Benutzerschnittstellen
unterstützen, ohne den Kern der Anwendung zu
verändern. Änderungen an den Daten, die sofort in allen
Darstellungen sichtbar werden sollen. Darstellung der
selben Information auf verschiedene Weise.
Lösung Eine Anwendung wird in drei Teilen getrennt.
● View, (die Sicht) kümmert sich um die (graphische)
Ausgabe. View bekommt Daten aus dem Modell. Es
können mehrere Ansichten des Modells dargestellt
werden.
12● Model, (das Modell) kapselt Stammdaten, Methoden
und Funktionalitäten, welche für die Verarbeitung
zuständig sind. Ein Modell ist unabhängig von anderen
Modulen.
● Controller, (die Kontrolle) ist für die Eingabe
zuständig. Der Benutzer interagiert ausschließlich
durch den Controller mit dem System.
Struktur
Rollen
13Dynamik
Der Controller übernimmt die Benutzereingabe in seinem Event-Handling-
Verfahren, interpretiert das Ereignis, und aktiviert einen Dienstverfahren
von dem Modell.
Das Modell führt den angeforderten Dienst aus, was zu einer Änderung der
internen Daten vom Modell führt.
Das Modell teilt allem Views und dem Controller die Änderungen mit,
indem es die Update Methode aufruft.
Der berechtigte Controller ruft Daten aus dem Modell, um diese zu
erlauben oder bestimmte Benutzerfunktionen zu deaktivieren.
Konsequenzen (einige von vielen)
⧫ Mehrere Ansichten des gleichen Modells.
⧫ Ansichten werden für alle Benutzer, falls notwendig,
einfach synchronisiert.
⧫ Die konzeptionelle Trennung in MVC ermöglicht
zwischen Entwicklern Austausch von einzelnen Teilen.
⧫ Framework Potential
⧫ Erhöhte Komplexität
⧫ Im Falle einer MVC Framework oder große
Programmteile sind zusätzliche Anforderungen an die
Plattform notwendig.
Beispiele ⧫ GUI-Bibliotheken, Microsoft Foundation Classes, Java
Server Faces, Smalltalk, dutzende Linux Pakete
Verwandtes ⧫ Dokument-View Architektur
Konzept
142.5 Modelle, Klassifizierung
Wie in Abschnitt 2.1 bereits angedeutet, bietet ein Muster Lösungsansätze
für ein spezifisches Problem. Bei einer breiten Palette von Mustern, welche
für bestimmte Probleme auszuwählen sind, müssen die Patterns in
irgendeiner Weise klassifiziert werden. Die Patterns müssen in eine
Ordnung gebracht werden, um diese schnell zu finden und vergleichen zu
können.
Eine gemeinsame Klassifikation wäre nach der Entwicklungsphase
möglich, welche von mehreren Autoren als Vorschlag gilt: Analyse-,
Architektur-, Design- und Implementierungsmuster. Diese Aufteilung
basiert auf den Typ und Modell in denen die Muster Lösungen anbieten. In
der Praxis erweist sich die Bündelung der entsprechenden Muster in
Mustersprachen nützlich. Es gibt Mustersprachen zur Modellierung von
spezifischen Bereichen, wie z. B. Brandmeldeanlagen [Molin97] oder
Straßenordnung [Foster97]. Es gibt auch Mustersprachen für bestimmte
Familien von Problemen, wie z. B. für das Design einer relationalen
Datenbank der OO-Programme [Brown96], persistente Objekte [Soukup94]
und Kommunikations-Software [Schmidt95].
Weitere Aspekte für die Einstufung (nach Gamma et al. [GHJ04]) sind
Einteilungen nach zwei Klassifizierungskriterien: nach der Aufgabe der
Muster und nach dem Gültigkeitsbereich, welche sich nur in Patterns für
Klassen und für Objekte unterscheiden (siehe Abb. 3).
Aufgabe
Erzeugungsmuster Strukturmuster Verhaltensmuster
klassen- Fabrikmethode Adapter (klassenbasiert) Interpreter
basiert Schablonenmethode
Abstrakte Fabrik Adapter (objektenbasiert) Befehl
Gültigkeitsbe-
reich Erbauer Brücke Beobachter
Prototyp Dekorierer Besucher
Singleton Fassade Iterator
objekten- Fliegengewicht Memento
basiert Kompositum Strategie
Proxy Vermittler
Zustand
Zuständigkeitskette
Abbildung 3: Klassifizierung von Muster (nach "The Gang of Four" [GHJ04])
Die Erzeugungsmuster befassen sich mit Erzeugung von Objekten. Die
Strukturmuster bestimmen die Zusammensetzung von Objekten und
Klassen. Verhaltensmuster beschreiben das dynamische Verhalten von
Objekten und Klassen.
Buschmann et al. [BMR+96] kategorisieren Software relevante Patterns in
drei große Gruppen (berücksichtigt dabei das Granularitätskriterium):
15● Architekturmuster
● Entwurfsmuster
● Idiome
Die Gruppen wurden nach ihrer Abstraktionsebene eingeordnet. Die
Architekturmuster sind auf der obersten Ebene, welche das Fundament der
Softwaresysteme bestimmen. In dieser Gruppe fallen auch die MVC Muster
(diese fallen aber in anderen Behauptungen in die Design Patterns, sind
aber in derselben Entwicklungsphase), welche die Mensch-Computer-
Interaktion unterstützt und hilft. Die verwendeten Subsysteme werden
bestimmt, sowie es eine Spezifizierung ihrer Funktionen und eine
Beziehungen zueinander folgt.
Auf der mittleren Abstraktionsebene befinden sich die Entwurfsmuster
(Design Pattern), welche oben genauer beschrieben wurden. Es wird eine
verfeinerte Abbildung von Subsystemen und Komponenten angezeigt. Die
Entwurfsmuster lösen wiederkehrende Entwurfsprobleme.
Die letzte Abstraktionsebene repräsentieren die Idiome. „Ein Idiom ist ein
programmiersprachenspezifisches Muster und damit ein Muster auf einer
niedrigen Abstraktionsebene. Ein Idiom beschreibt, wie man bestimmte
Aspekte von Komponenten oder Beziehungen zwischen ihnen mit den
Mitteln einer bestimmten Programmiersprache implementiert.“ [BMR+98,
S. 14]
Eine weitere Klassifizierungsdimension nach Buschmann und seinen
Mitautoren [BMR+98], andererseits, folgt an Hand des Problemkriteriums.
Die Muster werden, korrespondierend ihrer Problemgruppe, in den
folgenden Kategorien unterschieden:
● „von Grob zum Struktur“ - Pattern zerlegen Gesamtaufgaben eines
Systems in kleinere Subsystemaufgaben, in sogenannte Subtasks.
● „Verteilte Systeme“ - Muster bieten Lösungen für Anwendungen, bei
denen Komponente verteilt über verschiedene Prozesse und
Subsysteme gibt.
● „Interaktive Systeme“ - Muster mit Mensch-Computer-Interaktion
Problemen.
● „Anpassungsfähige Systeme“ - Lösungsmuster, welche für die
Anwendung anpassbare und erweiterbare Solutionen anbietet.
● „Organisation der Arbeit“ - Pattern, welche definieren, wie
Komponente zusammenarbeiten, um komplexe Aufgabestellungen
zu lösen.
● „Access Control“ - Muster für den Zugriff auf Dienste und die
Überwachung-, Kontrollkomponenten aufweisen.
● „Management“ - Muster, welche die homogenen Objekte, Dienste
16und Komponente in deren Verwaltung unterstützen.
● „Kommunikation“ - Pattern für die Kommunikation zwischen den
Komponenten.
● „Resource Handling“ - Muster welche die gemeinsam genutzte
Komponente und Objekte verwalten.
Die Beschreibung, Visualisierung und Klassifikation von Mustern,
insbesondere der Design Pattern, wurde hiermit erläutert. Der nächste
Abschnitt schafft einen Überblick über Frameworks und deren
Unterschiede zu Patterns.
2.6 Framework
Ein Framework bestimmt in der Regel die Architektur der Software. Ein
Framework ist selbst noch keine fertige Anwendung, sondern stellt den
Rahmen zur Verfügung, innerhalb dessen der Entwickler ein Programm
erstellt. Es ist hiermit klar, dass in dem Framework verwendete
Entwurfsmuster und auch die Struktur der individuellen Anwendung
beeinflusst werden. Frameworks werden insbesondere mit dem Ziel einer
Wiederverwendung von Architekturmustern entwickelt und genutzt. Die
Frameworks (Rahmen) berücksichtigen konkrete Anwendungsdomäne und
werden als solche entworfen, daher sind Frameworks meist
domänenspezifisch und auf einen bestimmten Anwendungstyp beschränkt.
Beispiele sind Frameworks für grafische Editoren, elektronische
Warenhäuser oder Finanz-Buchhaltung Systeme [SGM02].
Die Rahmen, die domänenspezifisch sind, bieten zum Teil vorgefertigte,
wiederverwendbare Codes und Klassenbibliotheken. Es werden Namen
und Aufrufskonventionen verwendet, welche von den Frameworks bereits
bestimmt wurden. Einerseits erspart man sich die Zeit für die
Entwurfsentscheidung, andererseits sind solche Anwendungen schneller zu
entwickeln und weisen ähnliche Strukturen auf. Dadurch lassen sich
Wartungsarbeiten leichter durchführen und stimmen in ihrer Gestalt
überein.
Da Klassenbibliotheken schwer zu entwickeln sind, so sind Frameworks
noch schwieriger. Die Entwickler folgen dabei bestimmten Regeln, der von
ihnen ausgeforschten Entwurfsmuster. Die Schnittstellen sind bei der
Entwicklung besonders sensibel, und jede Änderung an der vorgegeben
Rahmenstruktur verringert die Vorteile der Wiederverwendung. Es soll
ausschließlich von Experten durchgeführt werden.
Patterns und Frameworks haben große Ähnlichkeiten, dennoch gibt es
Unterschiede zwischen diesen beiden Konzepten (nach Gamma et al.
[GHJ04]):
1. Entwurfsmuster sind abstrakter als Frameworks. Jedes Muster muss
neu implementiert werden, wenn man dieses anwenden möchte.
Frameworks besitzen schon Programmteile und bieten die
17Möglichkeit sie auch gleich auszuführen, daher beinhalten
Frameworks bereits ausgewählte Entwurfsmuster. Die Muster
bringen auch eine Erläuterung über die Vor- und Nachteile und deren
Konsequenzen bei der Verwendung mit sich, Frameworks hingegen
nicht im abstrakten Sinne.
2. Frameworks sind größer als Entwurfsmuster. Ein Framework kann
auch mehrere Patterns beinhalten (insbesondere Muster welche als
Idiome eingestuft wurden, die die Probleme mit bestimmten
Aspekten von Komponenten oder Beziehungen zwischen ihnen
beschreiben, z.B. kürzlich erfolgte Probleme).
3. Frameworks sind spezialisierter als Entwurfsmuster. Die Muster
bieten nicht eine Anwendungsarchitektur in jenem Ausmaß, wie
dieses ein Framework anbietet. Die Frameworks haben immer einen
bestimmten Anwendungsbereich und sind domänenspezifisch. Diese
bringt auch den Nachteil der Frameworks, dass diese nicht zur
Gänze in anderen Themengebiete angewendet werden können.
183 Kommunikation
Bei der Software-Entwicklung ist die Kommunikation eine sehr kritische
und zeitraubende Aktivität. Wenn Missverständnisse und Unterlassungen
auftreten, führen diese zu Fehlern und Verzögerungen, welche für die
Behebung und der weiteren Entwicklung sehr kostspielig seien können.
Unter Kommunikation werden alle Aktivitäten zwischen Teilnehmern eines
Systems verstanden, wo ein Austausch von Dokumenten, Modellen,
Arbeitsergebnisse und Berichte stattfindet und wo man über die
Rückmeldungen und Entscheidungen informiert und davon kommuniziert
wird. Es gibt mehrere Faktoren welche zu einer erschwerten
Kommunikation führen können. Einige davon sind: unterschiedliches
Bildungsstand der Teilnehmer, geographische Verteilung, die Komplexität,
der Umfang und die Entwicklungsphase der ausgetauschten Information.
Im Folgenden wird eine wohlgeformte Kommunikation nach
Shannon/Weaver [PRW03] behandelt.
Abbildung 4: Das Kommunikationsmodell von Shannon/Weaver [PRW03]
Die Quelle (siehe Abb.4) produziert eine Information, welche von dem
Sender in Form eines Signals/Nachricht an den Empfänger geschickt wird.
Dort soll diese Nachricht möglichst unverändert ankommen. Während des
Prozesses der Übertragung werden ihr nicht beabsichtigte Zeichen
hinzugefügt oder weggenommen. Diese Störungen werden, wie erwähnt,
Rauschen genannt. Zu vereiteln sind sie kaum, jedoch kann durch
Redundanz, also einem Überschuss an Information, Wiederholung der
Information, die Toleranzgrenze für Störungen jeder Art innerhalb eines
Kanals erhöht werden, sodass die Information doch noch möglichst akkurat
und nachvollziehbar ankommt.
3.1 Soziale Struktur
Oft sind die Ursachen gescheiterter Projekte nicht die technischen
Gegebenheiten, sondern es hängt auch von den sozialen Faktoren ab. Die
soziale Struktur der Softwareteams darf nicht unterschätzt werden. Ein
aktueller Trend ist es, dass die Software-Entwickler sich mit den sozialen
Bedingungen ihrer Arbeit beschäftigen müssen.
Die Design-Patterns zeigen eindeutig klar, dass ein erheblicher Teil des
Wertes von Design-Patterns sozial sind: Sie gewähren es, die eigene Arbeit
kommunizieren zu lassen. Sie erlauben es darüber hinaus, fremde Arbeit
aufzunehmen und in der eigenen Arbeit anzuwenden.
19Laut dem Bericht von Bernhard Scheffold und seinem Kollegen [ScK98],
schicken Firmen wie die Bell Labs Spezialisten für objektorientierte
Technologie (z.B. Jim Coplien) durch ihre Abteilungen, um Design-Patterns
nachzuweisen und die sozialen Bedingungen ihres Einsatzes zu
untersuchen.
Eine andere Vorstellung hat die Firma Systor AG, welche die eigene
Organisation in bewusster Analogie als Framework bezeichnet. Es werden
hier daher Konzepte der Software-Entwicklung auch für die interne soziale
Organisation der Firma angewendet.
Software-Entwicklung ist überwiegend eine soziale Aktivität. Bei der
Software-Entwicklung sind Gruppen, Abteilungen und das eigene
Unternehmen als soziale Einrichtungen zu betrachten. In jeder
Organisation strebt man eine Struktur einzuführen. Eine allgemeine
Definition jeder Organisation, für eine unbestimmte Kultur, wäre [nach
JoWi92] eine Bestrebung zwischen den Akteuren und ihrer Rollen eine
Verbindung zu erhalten, die von einer gemeinsamen Interesse oder Ziel
ausgeht. Diese Organisation ist auch bekannt als „Instrumentale
Organisation“. Eine instrumentale Organisation ist „das Instrument,
welches das organisationales Verhalten der Menschen reguliert“ [JoWi92,
Seite 10]. Jede Organisation hat bestimmte Rollen und damit verbundene
Rechte und Pflichten. Diese Rollen können gleichzeitig von demselben
Akteur besetzt werden. Eine typische Darstellung einer Organisation für
Software-Entwicklung schaut wie folgt aus:
Abbildung 5: Die Rollen der Software-Entwicklung [CaCo96]
Die Stärke der Verbindung repräsentiert die Intensität der Kommunikation
zwischen jeweiligen Rollen. Die Beziehung zwischen Coder und Designer
20Rolle ist [laut CaCo96] meist auf dem höchsten Rang. In vielen kleineren
Organisationen werden diese zwei Rollen von einem Akteur besetzt.
Abbildung 6: Die Rollen der Software-Entwicklung ii [CaCo96]
Die Titel „Coder“ (Programmierer) und „Entwickler“ sind zwei
verschiedene Titel, welche auf dieselbe Rolle hindeuten (siehe Abb. 6). Der
Designer und Programmierer haben überlappende Aufgaben. Die
Wissenschaftler Cain und Coplin [CaCo96] fanden heraus, dass die
Entwicklerrolle nach wie vor die höchste Popularität in fast allen Prozessen
aufweisen; Popularität wird hier als Maß für die Anzahl der Verbindungen
von einer einzigen Rolle zum verbleibenden Rollen im sozialen Netz,
gesehen. In den meisten solcher Organisationen haben die Entwickler, wie
erwartet, auch die höchste Prestigebewertung; Prestige ist hier als Maß,
wie oft die anderen Rollen eine Interaktion mit einer bestimmten Rolle
initiieren. In diesen beiden Diagrammen stellt also die Entwicklerrolle eher
die Mitte des sozialen Netzwerks darn aber wir sehen auch eine zentrale
Rolle der Softwaredesigner welche die Design Patterns auch tatsächlich
umsetzten.
Hiermit einleitend zum Abschnitt „Design Pattern Rolle“ einige
Voraussetzungen [nach ScK98] für erfolgreiche Projekte mit dem
Schwerpunkt auf die soziale Struktur der Organisation:
21● Projektion der technischen und sozialen Architektur über die
Zeitachse. Technische und soziale Anforderungen an die Architektur
werden ausdrücklich gemacht. Die später aufgetauchten sozialen
Rollen und Aufgaben werden von der vorgegebenen Architektur
unterstützt.
● Minimierung sozialer Interaktion durch Framework-Technologie. Wo
es technisch möglich ist, sollten das Verhalten und das Modell des
Systems durch das domänenspezifische Framework vorgegeben
sein. Dies verringert die sozialen Streitigkeiten um technische
Funktionalität enorm und ermöglicht darüber hinaus einen
kategorialen Rahmen der Architektur samt bestimmten
Entwurfsmustern, der ihr Erlernen einfacher macht.
● Maximierung sozialer Interaktion, wo kein Framework möglich ist.
D.h. die technischen Schnittstellen sind nicht erlaubt gleich zur
sozialen Gliederung zu laufen. Die soziale Gliederung nach Gruppen
und Rollen soll sich mit den technischen Interfaces überschneiden.
Dies vereitelt nur die übermäßige Ausbildung eines sozialen und
eines technischen Kategoriensystems.
● Mikroebene der Software-Entwicklung verwenden Einheitliche
Coding-Standards verwenden. Durch Coding-Standards und
Konstruktionsrichtlinien, auch durch vordefinierte Regeln des
verwendeten Frameworks, werden die Strukturen der Architektur
sozial vermittelbar. Es muss parallel eine kurze Dokumentation und
Beschreibung (z.B. durch Kommentare einfügen) bei der Entwicklung
folgen. Coding-Standards verbinden darüber hinaus die Ebene der
Komplexität (sichtbar an der Zeile Source-Code, die gerade
geschrieben wird) mit der abstrakten Ebene (den Strukturen der
Architektur, die auf Basis von der aktuellen Zeile gerade berührt
werden). Da die Ebene der Abstraktion bei der Entwicklung nicht
sichtbar ist, müssen Programmiersprache und Coding-Standards
Hinweise darauf geben.
3.2 Kommunikation: Argumentation für Maßnahmen
Eine Kommunikation gilt dann für den Absender als erfolgreich, wenn der
Absender informiert wurde, dass der Empfänger die Nachricht auch
erhalten hat. Auf der anderen Seite, folgt der Erfolg der Kommunikation
erst, wenn der Empfänger der Botschaft auch diese versteht und
entschlüsseln kann. In der einfachen Welt ist meist die einzige Möglichkeit,
sich mit Hilfe der Beobachtung über den Status zu informieren. Dadurch
lassen sich Aktionen und Reaktionen des Empfängers einsehen. Der
Empfänger erhält die Nachricht und interpretiert sie, dann ändert er seine
bisherigen Kenntnisse. In bestimmter Weise ändert er auch seine
Verpflichtungen. Diese fordern ihn auf, auf Grund der neu erworbenen
Kenntnisse, eine Reaktion abzugeben. Auf diese Weise kommunizieren der
Sender und Empfänger mit gegenseitiger Argumentation, für einen
bestimmten Themengebiet [SCH83].
22In einem Software-Entwicklungsteam lassen sich zwei grundlegende
Strukturen [nach ROS87] für Konversationen unterscheiden:
1. Zentrale Kommunikationsnetze
2. Dezentrale Kommunikationsnetze
Abbildung 7: Zentrale und Dezentrale Kommunikationsnetze [ROS87]
Mit Kanten (Abb. 7) wird die Konversation zwischen Personen (P)
symbolisiert, durch welche Informationen generiert und ausgetauscht
werden. Die Mitglieder einer Organisation werden als Knoten in einer
strukturierten Form dargestellt.
Bei den zentralen Strukturen, wie z.B. dem Stern gibt es zentrale Stellen,
über die die Kommunikation zu laufen hat. Möchte ein Gruppenmitglied P4
in der Y-Struktur beispielsweise mit P1 Kontakt aufnehmen, so muss es
vorher P1 und P2 aktivieren. In der Vollstruktur ist ein direktes Ansprechen
zwischen P3 und P5 möglich. Die Pfeile symbolisieren wer mit wem
Interaktions- und Kommunikationsmöglichkeiten hat. Vereinfacht wird
meist berichtet, dass in zentralisierten Strukturen die Leistung hoch ist,
dass es eine gut identifizierbare zentrale Person gibt und dass die
23durchschnittliche Zufriedenheit gering ist, während sich bei dezentralen
Strukturen das Gegenteil ergibt.
Dezentralisierte Strukturen, wie z.B. die totale Struktur, erlauben jedem
Mitglied einer Gruppe mit jedem anderen in Kontakt zu treten. Eine
zentrale Schaltstelle ist nicht vorgesehen. Alle Gruppenmitglieder befinden
sich in der gleichen Ausgangsposition, mit gleichwertigen
Kommunikationsmöglichkeiten. In der Praxis, die wohl bekannteste und
größte dezentrale Struktur der menschlichen Geschichte, repräsentiert das
Internet.
Die Kommunikation zwischen Mitgliedern bildet den Ausgangspunkt
sämtlicher Kooperationen und Koordination und beinhaltet die
Verständigung mehrerer Personen untereinander [SMT95]. Hierbei kann es
primär zwischen andauernde und geregelte, normierte und offene sowie
direkte und indirekte Kommunikation unterschieden werden [DAM03].
Einige weitere Unterscheidungsmerkmale sind: Personenkreis, der
Vernetzungsgrad und der Grad an Institutionalisierung einer
Kommunikation. Ziel der Kommunikation ist die Absicherung, Ausbau oder
Korrektur von vorhandenen Daten- oder Informationsbeständen. Neben
der reinen Verschiebung der Information ist also auch die Übermittlung
des Kontextes (Meta-Information), in der die Informationen generiert
wurden, von Bedeutung, damit diese korrekt interpretiert werden kann
[DAM03].
Wenn man die Kommunikation für bestimmte Fragestellungen(z. B.
Antwort einer Diskussion) behandeln möchte, so zeigt es in der Software-
Entwicklung drei Formen auf: linear, hierarchisch und in einem Netzwerk.
Diese sind chronologisch dargestellt und berücksichtigen die Zeit seit dem
Beginn der eingetretenen Fragestellung.
Abbildung 8: Lineare-, Hierarchische- und Netzform [ROS87]
Der Diskussionsstartpunkt (siehe Abb.8) beginnt und je nach Verlauf und
Bedürfnis kann sich in dieser drei Formen, gegen die Zeit,
weiterentwickeln. Die lineare Form wird meist auftreten, wenn die
Diskussion kurz andauert, und die Lösung (in Form einer Antwort) der
ausgelösten Diskussion gefunden wurde. Diese dauert am kürzesten und
kostet auch am wenigsten Ressourcen. Die hierarchische Form tritt auf,
wenn die Verhältnisse zwischen Mitteilungen, wie Fragen und Antworten,
24schnell identifiziert werden müssen und sich ständig splitten. Diese
werden aus einem Diskussionspunkt ausgelöst, werden aber später in
divergente Lösungsformen entwickelt. Es gibt keine Möglichkeit einmal auf
einem Pfad zurückzukommen, die Linien laufen auseinander. Die Netzform
tritt auf, wenn die Diskussion auch andere Pfade konvergierend erreicht.
Meist werden diese Wege einer Nachricht in Organisationen oft unbewusst
ablaufen, dennoch existieren sie. Da man ein menschliches Verhalten, auf
eine Nachrichtenreaktion bezogen nicht vorhersehen kann, gibt es keine
Möglichkeit einige Werte (wie z.B. die Laufzeit einer Diskussion) von vorne
zu berechnen.
3.3 Koordination: die Planung von Aktionen
Die Koordination der Team-Mitglieder hängt stark von der Kommunikation
und auch der Kooperation, zusammen. Mit Koordination werden Personen
oder Sachen für die Erfüllung einer bestimmten Aufgabe koordiniert. Einige
Ausprägungen der Koordination sind: Aufteilung in Teilaufgaben,
Zusammenführen der Ergebnisse, Zuordnung der Aufgaben und zeitliche
Ordnung der Aufgaben. Die Koordination ist daher ein Teil der
kollaborativen Aufgaben und bezieht sich auf die Organisation der
Aufgaben [ALT99]. Damit dient die Koordination zur Regelung der
gegenseitigen Abstimmung der Kooperationspartner [DAM03].
Es gibt zwei Phasen, die für eine Koordination notwendig sind. Die erste
Phase ist die Vorartikulation (eng. pre-articulation), welche die Tätigkeiten
schließt, die essenziell sind, um eine Koordination vorzubereiten, wie z.B.
Anbahnung, Vereinbarung. Diese werden, normalerweise, abgeschlossen
bevor die Mitarbeiter anfangen sich mit den Zielen der Aufgabe, den
Diagrammen zu beschäftigen. Die Postartikulation Phase tritt nachdem die
Aufgabe erledigt wurde auf und bezieht eine Auswertung der Analyse von
Aufgaben und die Unterlagen des kooperativen Prozesses mit ein (Bsp.
Kontrolle, Anpassung) [WIN05].
Arbeiten mehrere Menschen an einer Software zusammen, entstehen
bezogen auf die Koordination, zwei substanzielle Fragen: Was soll präzise
die Software sein, an der alle arbeiten? Wie kann der Vorgang des
Arbeitens in der Weise abgestimmt werden, dass Gruppenmitglieder
einander nicht behindert?
Die Koordination selbst ist kontrovers, weil der Koordinationsaufwand bei
gut gelungenen Abstimmungen kleiner ist. Nach Crowston et al. soll eine
Koordination so effektiv gestaltet sein, dass eine weitere Koordination
später nicht notwendig wird. Wenn man die Abhängigkeiten richtig
managt, so ist das Ziel des Managements gerade die Verringerung dieser
Abhängigkeiten [CAH04]. Je deutlichere Koordinationsstrukturen es zu
Projektbeginn gibt, desto besser wird der Projektverlauf durchgeführt.
Massnahmen, wie die Modularisierung des Programmcodes, aber auch das
Meiden von Abhängigkeiten der Entwickler voneinander, sind einige
Beispiele, wie man die Arbeit entwicklungsfähiger macht und das Projekt
25schneller fertig gestellt werden kann. Ein Programmierer kann aus einem
Eintrag der TODO-Liste eine Aufgabe voluntaristisch auswählen und das
dann als „gestartet“ markieren.
Treten fehlerhafte Koordinationsprozesse ein, so müssen diese durch die
Kommunikation der Teilnehmer ausbalanciert werden. Eine reibungslose
Kommunikation ist essenziell für die globale Effizienz. Die konkreten
Koordinationsziele müssen durch die Kommunikation optimiert werden,
dadurch, dass die Kommunikation einfach, vertrauensvoll und schnell
zwischen richtigen Personen aufgenommen werden muss. Die Mitteilung
muss verständlich sein [CAH04]. Bei den untersuchten Projekten von
Crowston et al. ist die Effektivität der Entwicklung oft verschieden, aber
auch widersprüchlich, weil eine große Projektmenge berücksichtigt wurde.
3.4 Kooperation: Schaffung in dem gemeinsamen
Arbeitsumfeld
Die Kooperation bildet grundsätzlich einen strategischen Rahmen der
Kollaboration bzw. der Zusammenarbeit und wird dabei durch die
Kooperationsform bestimmt. Es gibt mehrere Erscheinungsformen einer
Kooperation, welche aus dem Kontext der gemeinsamen Ziele folgt. Die
Mitglieder der Gruppe beschäftigen sich zusammen mit der Erstellung,
Manipulation, Organisation von Daten, Meta-Daten und Informationen. Sie
bearbeiten Objekte wie Dokumente, Tabellen, Grafiken usw. Das
gemeinsame Arbeitsumfeld ist zu teilen und bedingt eine Kooperation, es
bietet auch eine Reihe von Werkzeugen für die Verwaltung der Aufgaben.
Mit den gemeinsamen Prozessen von Informationen, ist die Gruppe in der
Lage auf das kollektive Wertesystem einzugehen und falls notwendig, auf
die Geschichte einer Diskussion oder den Kontext dieser Diskussion, in der
eine Entscheidung gemacht wurde.
Zur Beschreibung der Kooperationsform existiert, wie erwähnt, eine
Vielzahl an Klassifikationskriterien. Im Wesentlichen werden in einer
Kooperation zeitliche Häufigkeit, Dauer, Anzahl der Partner,
Kooperationsrichtung, Bindungsintensität und Befristung sowie die
Partnerherkunft festgelegt. Weitere Kriterien, die strategisch wesenhaft
sind, bilden den Grad der Intensität im Hinblick auf die Motivation,
Vertrauen und Abhängigkeiten zwischen Organisationen sowie die Art der
Kooperationsbereiche z.B. in Bezug auf Unterschiede in der
Kommunikation zwischen sozial orientierten und technologisch orientierten
Bereichen [SMZ03].
Angesichts der Anzahl von Kooperationsteilnehmer existiert meistens
keine Einschränkung in den einzelnen Kooperationsformen. Somit ist
festzusetzen, dass in beinahe jeder Kooperationsform von bilateralen
Beziehungen bis zu komplizierten Netzwerken alle Ausprägungen realisiert
werden können. Dies ist sowohl bei der Gestaltung der Softwareprozesse
als auch bei der Gestaltung der Koordinationsprozesse in einer
Kooperation zu berücksichtigen. Durch das sporadische Eintreten oder
Ausscheiden von Mitgliedern in die bzw. aus der Kooperation, werden neue
26Kooperationsstrukturen entstehen und die Koordinations- und
Kommunikationsprozesse gewinnen an Komplexität bzw. werden
vereinfacht.
Eine Definition nach Altmann, beschreibt die kooperative Software-
Entwicklung [ALT99, S. 20] als
„die Abdeckung der Kommunikations- und Koordinationsbedarfe
innerhalb eines Software-Entwicklungsprozesses, die für die Planung,
Durchführung und Abstimmung aller aufgabenbezogenen, zeitlich und
räumlich verteilten Aktivitäten erforderlich sind. Die kooperative Software-
Entwicklung umfasst dementsprechend alle prozess- und
produktbezogenen Aktivitäten aller Beteiligten, deren gemeinsames Ziel
die Erstellung eines Softwareproduktes ist“.
Damit bekräftigt Altmann, dass alle drei K: Kommunikation, Koordination
und Kooperation erforderlich sind, um eine gemeinsame Aufgabe, im
Rahmen der Softwareerstellung, erledigen zu können. Kooperation führt
häufig zum Nutzen für alle Beteiligten. In manchen Kooperationsformen
kann es auch vorkommen, dass eine Seite mehr oder alle Vorteile aus
dieser Kooperation zieht. Altmann betont auch den positiven Einfluss
sozialer und organisatorischer Unterstützung (siehe Abschnitt Soziale
Struktur) der Mitarbeiter für eine erfolgreiche Zusammenarbeit.
Abschließend ist zu argumentieren, dass der Begriff „Kollaboration“ (auf
Deutsch „Zusammenarbeit“) aus allen drei Elementen (die drei K) in der
Software-Entwicklung besteht: aus der Kommunikation, Koordination und
Kooperation. Andriessen [AND03] bietet feinen Überblick über die
Kollaborations-Technologie in der Softwarebranche (siehe Tabelle 1).
27Support between Support for Support for
encounters: synchronous synchronous
asynchronous electronic electronic
communication encounters encounters
different place/ different place/ same same place/ same
different time time time
Communication fax telephone/ mobile
Systems e-mail audio systems
voice-mail video systems
video-mail chat systems
Information document sharing tele-consultation presentation
sharing systems systems systems systems
message boards co-browser
document co- shared CAD,
authoring whiteboard, word- group decision
Co-operation processor, support systems
systems spreadsheet (meeting
support
systems)
Co-ordination
systems group-calendar notification command and
systems, e.g. control centre
shared planning active batch support systems
shared workflow
management
systems
event manager
subgroup spaces
Social encounter media spaces
Systems virtual reality
Tabelle 1: Kollaborations-Technologie [AND03]
Aus der Tabelle lässt sich erkennen, ob der Ort, die Zeit und die
Verbindung zwischen Mitgliedern synchron oder asynchron ablaufen. Die
entsprechende Kollaborations-Technologie wird dann eingesetzt. Die
Koordination der Gruppenmitglieder erfolgt bei unterschiedlichen Orten
und Zeit über die z.B. beliebten Gruppenkalender Systeme. Die
Kommunikation kann in diesem Fall über Fax, E-Mail, Audio- oder
Videobotschaft erfolgen. Wenn die Zeit und der Ort übereinstimmen,
können durch eine Kooperation mittels dafür bestimmten Meetings
unterstützende Systeme stattfinden.
28Sie können auch lesen
