Komponentenbasierte Anpassbarkeit

Rheinische Friedrich-Wilhelms-Universität Bonn Diplomarbeit Komponentenbasierte Anpassbarkeit FlexiBeans zur Realisierung einer erweiterten Zugriffskontrolle von Gunnar Stevens Institut für Informatik Abteilung III Betreuer : Prof. Dr. Armin B. Cremers Februar 2002 INHALTSVERZEICHNIS Inhaltsverzeichnis .......................................................................................................... i 1 Einleitung................................................................................................................. 1 2 Gliederung der Arbeit............................................................................................... 5 3 Allgemeine Grundlagen ........................................................................................... 7 3.1 Anpassbarkeit.................................................................................................... 7 3.1.1 Definition................................................................................................. 7 3.1.2 Empirische Studien über die Anpassungsgewohnheiten.......................... 10 3.1.3 Anforderung an die Anpassungsgestaltung ............................................. 14 3.2 Komponentenbasierte Anpassbarkeit ............................................................... 22 3.2.1 Softwarekomponenten............................................................................ 23 3.2.2 Kompositionsbeschreibungssprachen ..................................................... 25 3.2.3 Komponentenbasierte Anpassbarkeit und Anpassungstechniken............. 28 3.3 Der FLEXIBEAN-Ansatz ................................................................................... 30 3.3.1 JavaBeans .............................................................................................. 31 3.3.2 Erweiterungen durch das FlexiBean-Modell ........................................... 33 3.3.3 Component Architecture for Tailorability (CAT).................................... 36 3.3.4 EVOLVE-Plattform und verteilte Anwendungen mittels DCAT ............. 38 3.3.5 Tailoring API und Anpassungsumgebung.............................................. 40 3.4 Der WAM-Ansatz ........................................................................................... 41 3.5 Grundlagen der Zugriffskontrolle .................................................................... 43 3.5.1 Zugriffsmatrix Modell nach Lampson (1974) ......................................... 44 3.5.2 Das Zugriffsmodell von Shen und Dewan (1992) ................................... 45 3.5.3 Gruppenbasiertes Zugriffsmodell nach Sikkel (1997) ............................. 49 3.5.4 Regelbasierte Zugriffskontrolle von Stiemerling (1996) ......................... 51 3.5.5 Vergleich der Zugriffskontroll-Modelle.................................................. 53 3.5.6 Resümee................................................................................................. 55 4 Die Analyse des Anwendungsfelds......................................................................... 57 4.1 Einführung in die Fallstudie und ihre Einordnung in die VO-Diskussion ......... 57 4.2 Forschungsmethodik ....................................................................................... 61 4.3 Analyseergebnisse........................................................................................... 63 4.3.1 Das dialektische Verhältnis von Konkurrenz und Kooperation ............... 63 4.3.2 Chance und Risiko – zwei Kinder des Internets ...................................... 66 4.4 Zusammenfassung der Analyse ....................................................................... 67 4.5 Sonstige Anforderungen an den Prototypen ..................................................... 69 5 Herleitung einer erweiterten Zugriffskontrolle........................................................ 71 5.1 Zugriffskontrolle und Kooperation .................................................................. 71 5.2 Optimistische Zugriffskontrolle....................................................................... 72 5.3 Zugriffskontrolle als Konfliktregelung............................................................. 74 5.4 Zeitpunkt der Kontrolle ................................................................................... 76 5.5 Faktoren für die Zugriffsstrategie .................................................................... 79 5.6 Resümee.......................................................................................................... 80 ii 6 Implementierung des Prototypen ............................................................................ 81 6.1 Umsetzung des WAM-Ansatzes mit Hilfe der FlexiBeans ............................... 81 6.2 Postfach-Metapher .......................................................................................... 84 6.3 Umsetzung, die auf der praktizierten Zugriffskontrolle beruht ......................... 85 6.4 Umsetzung einer erweiterten Zugriffskontrolle................................................ 89 6.4.1 Einstellmöglichkeiten der Sortierer-Komponente ................................... 92 6.4.2 Funktionsweise des Kontrollautomaten .................................................. 94 7 Evaluation.............................................................................................................. 97 7.1 Evaluation des Prototyps ................................................................................. 97 7.1.1 Repräsentations-Ebene ........................................................................... 97 7.1.2 Präsentations-Ebene ............................................................................... 98 7.1.3 Manipulations-Ebene.............................................................................102 7.1.4 Komponentenbasierte Anpassbarkeit und evolutionäre Entwicklung .....102 7.1.5 Resümee................................................................................................103 7.2 Erweiterung des FlexiBean-Ansatz.................................................................103 7.2.1 Persistenz und Identität einer Komponenteninstanz ...............................103 7.2.2 Reflexive Komponenten........................................................................106 7.2.3 WAM-Materialien.................................................................................109 7.2.4 Semantik von SharedObjects .................................................................111 7.2.5 Sonstige Erweiterungsvorschläge ..........................................................116 8 Zusammenfassung und Ausblick ...........................................................................120 Anhang A ..................................................................................................................125 Anhang B ..................................................................................................................126 9 Literaturverzeichnis...............................................................................................128 1 EINLEITUNG Im Bereich des Computer Supported Cooperative Work (CSCW) wird aktuell über das Konzept der Anpassbarkeit diskutiert. Anpassbarkeit wird von einigen Autoren als eine Schlüsseleigenschaft von Groupware-Systemen angesehen [Bentley und Dourish (1995), Oberquelle (1994), Wulf (1997), ter Hofte (1998), Koch und Teege (1999), Stiemerling (2000)]. Ein anpassbares System soll dabei so beschaffen sein, dass es während der Nutzung durch den Anwender an die sich verändernden Situationen angeglichen werden kann, damit die Software besser seinen Bedürfnissen und seinen Vorlieben im jeweiligen Nutzungskontext entspricht. Die Motivation, die hinter der Anpassbarkeit steht, ist sowohl arbeitspsychologischer, wirtschaftlicher, als auch strategischer Natur [Oberquelle (1994)]. Anpassbarkeit soll dabei zum einen der Forderung nach menschengerechteren und selbstbestimmbaren Arbeitsbedingungen nachkommen. Zum anderen wird davon ausgegangen, dass eine bessere Abstimmung von Mensch und Maschine zu produktiveren Systemen führt. Außerdem soll die Software in einer sich wandelnden Umgebung eingesetzt werden können. Dies soll die Flexibilität von Organisationen erhöhen, so wie es von der neueren Organisationstheorie gefordert wird [ Kahler (1995)]. Zusätzlich erhofft man sich, dass ein anpassbares System für solche SoftwareProjekte geeignet ist, bei denen der Einsatzkontext in der Regel nicht präzise beschreibbar ist, und die unterstützenden Aktivitäten so komplex sind, dass die Anforderungen unpräzise und missverständlich sind [Oberquelle (1994), Henderson und Kyng (1991)]. Eine technische Umsetzung des Konzepts besteht in der komponentenbasierten Anpassbarkeit. Hierbei wird eine Anwendung aus Komponenten aufgebaut, die zur Laufzeit des Systems rekonfiguriert werden können. Der FlexiBean-Ansatz stellt ein Rahmenwerk für komponentenbasierte Anwendungen zur Verfügung [Stiemerling (1998), Stiemerling (2000)]. Der Beitrag der vorliegenden Arbeit besteht in der Untersuchung des FlexiBean-Modells unter dem Gesichtspunkt der Anpassung durch den Endanwender. Die Untersuchung stützt sich dabei auf einen Prototyp, der im Rahmen des OrgTech-Projekts vom Autor entwickelt wurde [Iacucci et al. (1998), Nett, Fuchs-Frohnhofen und Wulf (2000)]. Die Implementierung diente dabei dieser Arbeit als Grundlage zur Untersuchung des FlexiBeanModells. Beim OrgTech-Projekt ging es unter anderem darum die Kooperation zwischen einem Stahlwerk und zwei externen Konstruktionsbüros dadurch zu verbessern, dass den Externen 2 ein elektronischer Zugang zu dem firmeneigenen Zeichnungsarchiv des Stahlwerks, ADOS1, ermöglicht wird. Bezüglich des elektronischen Zugangs lagen bei den Beteiligten unterschiedliche Vorstellungen vor, weshalb im Prototyp, ADOS-X2, eine erweiterte Zugriffskontrolle implementiert wurde. Die Modellierungsmöglichkeiten, die durch den FlexiBean-Ansatz gegeben sind, werden anhand der Komponentenzerlegung (Dekomposition) des Prototyps evaluiert. Bei der Dekomposition sind verschiedene Einflussfaktoren zu beachten. Eine grobe Einteilung in drei Einflussfaktoren ist in Abbildung 1-1 dargestellt. Theorie zur Zugriffskontrolle Dekompositions-Methodik Erweiterte Zugriffskontrolle WAM-Ansatz Liefert Richtlinien für anwendungsorientierte Dekomposition Bestimmt die Anforderungen an die Dekomposition Analyse des erhobenen Datenmaterials mit Hilfe der objektiven Hermeneutik Prototyp Test der Dekomposition mit Hilfe der Thinking-Aloud Methode ADOS-X Liefert technisches Rahmenwerk für die Dekomposition Analyse der Prototypimplementierung Komponentenbasierte Anpassbarkeit FlexiBean-Modell Legende: Erkärung : Einflussfaktor : Evaluation verwendete Methodik zur Evaluation Abbildung 1-1 Faktoren, die die Dekomposition beeinflussen und die bei der Arbeit verwendeten Evaluationstechniken In der Arbeit wird die Ansicht vertreten, dass man bei einer Evaluation der Modellierungsmöglichkeiten unter dem Gesichtspunkt Verständlichkeit durch den Endanwender alle drei Einflussfaktoren gemeinsam betrachten muss. Bei der Untersuchung der Dekomposition stehen deshalb drei Fragen im Vordergrund: 1. Bietet die durch die Dekomposition des Systems gegebene Anpassbarkeit an einer für den Anwendungskontext notwendigen Stelle eine angemessene Flexibilität? 2. Ist die gefundene Dekomposition für den Endanwender verständlich? 1 2 ADOS steht für „Anlagen Dokumentations-System“ ADOS-X steht für „ADOS für eXterne“ 3 3. Welche Anforderungen an den FlexiBean-Ansatz lassen sich aus dem Prototyp ableiten? Die in der Arbeit zur Klärung der Fragen verwendeten Evaluationstechniken sind in Abbildung 1-1 als gestrichelte Pfeile dargestellt. Zur Klärung der ersten Frage wird das im Anwendungsfeld erhobene Datenmaterial mit Hilfe der Objektiven Hermeneutik einer soziologischen Analyse unterzogen [Oevermann (1991, 1993, 1996), Wernet (2000)]. Die Analyse dient in der Arbeit dazu, ein Modell zu einer erweiterten Zugriffskontrolle zu entwickeln. In der Arbeit wird anhand der durch den Prototyp realisierten Dekomposition gezeigt, wie sich mit Hilfe der entwickelten Grundkomponenten eine erweiterte Zugriffskontrolle umsetzen lässt. Die Verständlichkeit der durch den Prototyp realisierten Dekomposition wird mit der „Thinking-Aloud“-Methode evaluiert [Nielsen (1992)]. Jedoch wird nicht nur untersucht, ob die Dekomposition für den Anwender verständlich ist, sondern auch der Frage nachgegangen, wie eine Dekomposition gefunden werden kann. Da hier eine Lücke in der komponentenbasierten Anpassbarkeit besteht, wird in der vorliegenden Arbeit deshalb geprüft, ob durch die Übertragung des WAM-Ansatzes3 auf die FlexiBeans diese Lücke gefüllt werden kann. Des Weiteren wird in der Arbeit untersucht, welche Konsequenzen sich aus dem Prototypen für den FlexiBean-Ansatz ergeben. 3 Der WAM-Ansatz ist eine Methode zur anwendungsorientierten Softwareentwicklung und wurde in den 90er Jahren im Arbeitsbereich Softwaretechnik an der Universität Hamburg entwickelt [Budde und Züllighoven (1990), Züllighoven (1992), Kilberth, Gryzan und Züllighoven (1994), Züllighoven (1998)]. WAM steht dabei für Werkzeug, Aspekt und Material. Neuerdings findet man es auch für Werkzeug, Automat und Material. 4 5 2 GLIEDERUNG DER ARBEIT In Kapitel 3 wird der FlexiBean-Ansatz als technische Realisierung des Konzepts der komponentenbasierten Anpassbarkeit eingeführt. Dazu werden zuerst die grundlegenden Arbeiten zum Thema Anpassbarkeit vorgestellt. Dann wird die Idee der Softwarekomponenten erläutert und beschrieben, wie sich Anpassbarkeit mit Hilfe von Softwarekomponenten verwirklichen lässt. Es werden ebenfalls Grundzüge des WAMAnsatzes kurz beschrieben. Wegen der zentralen Bedeutung der Zugriffskontrolle für den Anwendungskontext werden einige der im CSCW-Bereich bekannten ZugriffskontrollModelle dargelegt. Kapitel 1 gibt eine Einführung in den Anwendungskontext und seine Einordnung in die Diskussion über Virtuelle Organisationen (VO). Es werden die Grundzüge der Methode der Sequenzanalyse vorgestellt, mit der das im OrgTech-Projekt erhobene Material untersucht wurde. Anschließend werden die Resultate der Analyse dargestellt und erläutert. Am Ende des Kapitels werden die Konsequenzen für eine zu realisierende Zugriffskontrolle aufgezeigt. In Kapitel 3 wird gezeigt, warum die klassischen Zugriffskontrollsysteme im vorliegenden Fall zu kurz greifen. Es werden alternative Modelle vorgestellt, die qualitativ andere Kontrollmechanismen bereitstellen. Insbesondere wird auf den Ansatz zur Konfliktregelung von Wulf (1997) eingegangen. Aufgrund des untersuchten Anwendungskontexts wird in diesem Kapitel ein eigenes Modell der Zugriffskontrolle entwickelt, das von der Sicht des Kontrolleurs ausgeht und die Kontrollmechanismen nach dem Zeitpunkt einteilt, an dem über die Legitimität des Zugriffs entschieden wird. In Kapitel 6 wird die Implementierung des Prototyps ADOS-X beschrieben. Neben einer Einführung in die Postfach-Metapher, auf der der Prototyp beruht, wird in diesem Kapitel außerdem gezeigt, wie die Grundbestandteile des WAM-Ansatzes sich mit Hilfe der FlexiBeans realisieren lassen. Anschließend werden die Grundkomponenten der Implementierung, die dem WAM-Ansatz folgen, und die daraus zusammengesteckte Komposition beschrieben. Der Prototyp wird in Kapitel 1 evaluiert. Dabei wird geklärt, ob die Dekomposition flexibel genug und für den Endanwender verständlich ist. Sie stützt sich auf das Feedback aus dem Anwendungsfeld und auf Tests, die mit Personen außerhalb des OrgTech-Projekts durchgeführt wurden. Am Ende des Kapitels wird erläutert, an welchen Stellen des FlexiBeanAnsatzes erweitert werden sollte. 6 Den Abschluss der Arbeit bildet eine Zusammenfassung der gewonnenen Erkenntnisse und es wird ein Ausblick auf zukünftige mögliche Forschung im Bereich der komponentenbasierten Anpassbarkeit gegeben. 7 3 ALLGEMEINE GRUNDLAGEN In diesem Kapitel wird der FlexiBean-Ansatz als ein technisches Rahmenwerk zur Entwicklung komponentenbasiert-anpassbarer Systeme eingeführt. Dazu wird zunächst geklärt, was unter Anpassbarkeit zu verstehen ist und welche Anforderungen allgemein an durch den Endanwender anpassbare Systeme gestellt werden. Anschließend wird das Konzept von Softwarekomponenten eingeführt und gezeigt, wie sich Anpassbarkeit mit Hilfe von Softwarekomponenten erreichen lässt. Abschließend wird der WAM-Ansatz als eine Methode zur Anwendungsgestaltung erläutert, die den FlexiBean-Ansatz im Bereich der Dekomposition ergänzt. Der Zusammenhang zu dem implementierten Prototypen ist in Abbildung 3-1 zu sehen. Allgemeine Grundlagen Anpassbarkeit Softwarekomponenten ist grundlegendes Konzept von Zugriffskontrolle KomponentenbasierteAnpassbarkeit wird implementiert durch anwendungsspezifische Grundlage von FlexiBeans WAM-Ansatz stellt technischen Rahmen dar leitet Dekomposition an Technische Umsetzung ADOS-X Abbildung 3-1 Übersicht über den Aufbau des Kapitels und den Zusammenhang zum komponentenbasiertanpassbaren System ADOS-X 3.1 Anpassbarkeit Die Forderung nach Anpassbarkeit wird von verschiedenen Autoren erhoben. In der englischsprachigen Literatur werden für diesen Sachverhalt verschiedene Begriffe gebraucht, z.B. „malleable“, „adaptable“, „customizable“ und häufig auch „tailorable“. Im Deutschen hat sich der Begriff der Anpassbarkeit bzw. der Anpassung durchgesetzt. Im Folgenden wird die Bedeutung des Begriffs, wie er im Bereich des CSCWs gebraucht wird, erklärt. Dazu werden in diesem Abschnitt einige verwendete Definitionen von Anpassbarkeit dargelegt, die die verschiedenen Aspekte der Anpassbarkeit erläutern. Anschließend werden verschiedene empirische Studien zu dem Thema vorgestellt und einige der Anforderungen dargelegt, die an die Gestaltung der Anpassbarkeit gestellt werden. 3.1.1 Definition Viele Arbeiten zur Anpassbarkeit beziehen sich auf die Definition von Henderson und Kyng (1991). Bei ihnen hängt der Begriff des Anpassens stark mit den Aspekten des 8 Wechsels und der Stabilität zusammen. Man passt an, wenn man während der Nutzung stabile Teile eines Artefakts verändert. Damit grenzen sie die Anpassbarkeit gegenüber der Nutzung ab: „If the modifications that are being made are to the subject of matter of the tool then we think of it as use; if the modifications are the tool itself, then it is tailoring“ Henderson und Kyng (1991, S. 224) . In der Tabelle 3-1 sind die Eigenschaften gegenübergestellt, die die Anpassung nach Henderson und Kyng (1991) von der Nutzung abgrenzen. Aspekt Nutzung Anpassung Stabilität Veränderung von während der Aufgabenerledigung unstabilen Aspekten Veränderung von während der Aufgabenerledigung stabilen Aspekten Gegenstand, auf den die Aktion wirkt Veränderung des Dokuments Veränderung des Werkzeugs, das zur Aufgabenerledigung dient Zeitpunkt des Effekts Wirkt sofort auf Aufgabenerledigung Veränderung hat erst später (indirekt) einen Effekt auf die Aufgabenerledigung Tabelle 3-1 Nutzung versus Anpassung bei Henderson und Kyng (1991) [zit. nach Won (1998)] Henderson und Kyng (1991, S. 224) machen zudem darauf aufmerksam, dass der Begriff der Anpassung in Relation zum Anwendungskontext steht. So fällt das, was für den Benutzer das Anpassen eines Programms ist, für den Entwickler unter den Begriff der Nutzung. Einen ähnlichen Unterschied macht Oberquelle (1994), der ebenfalls die Anpassung von der Nutzung abgrenzt. Letzteres gehört zu den primären Tätigkeiten, während die Anpassung zu den sekundären Tätigkeiten des Anwenders gehört. Oberquelle (1994, S. 35) klassifiziert zudem die Anpassungen in vier Kategorien (siehe Tabelle 3-2). Bei der Individualisierung nimmt der Einzelne die Anpassung vor, und nur er ist auch von den Auswirkungen der Anpassung betroffen. Bei der gruppenwirksamen Anpassung betrifft die Anpassung auch andere. Bei der gruppengestützten Individualisierung wird die Individualisierung von einer Gruppe entwickelt, aber von einzelnen umgesetzt. Ein Beispiel dafür stellt ein Makro dar, das von der Gruppe entwickelt, aber nur vom einzelnen genutzt wird. Bei der Gruppenanpassung betrifft die Anpassung die ganze Gruppe und wird von ihr auch umgesetzt. ALLGEMEINE GRUNDLAGEN 9 Akteure Einzelne Betroffene Gruppe Einzelne Gruppe Individualisierung gruppengestützten Individualisierung gruppenwirksame Anpassung Gruppenanpassung Tabelle 3-2 Klassifizierung von Anpassungen [Oberquelle (1994, S. 35)] Muller, Haslwanter und Dayton (2001) stellen die Anpassbarkeit in den Kontext des partizipativen Designs. Anpassbarkeit ist dabei eine Art, den Anwender bei der Softwaregestaltung zu beteiligen. Die Arbeit von Mørch und Mehandjiev (2000) kann man ebenfalls dieser Position zuordnen. Sie sehen die Anpassbarkeit als eine Kooperation zwischen Entwicklern und Anwendern an, welche durch das Softwaresystem vermittelt wird. Anpassbare Systeme stellen für sie eine spezielle Form von CSCW-Systemen dar, die in der „different time, different place“-Ecke der Johansen-Matrix4 einzuordnen sind. Daraus leiten sie einige Punkte für die Anpassungsgestaltung ab, auf die in Abschnitt 3.1.3.11 eingegangen wird. Die Idee des partizipativen Designs findet sich auch beim Ansatz zur Integrierten Organisation und Technikentwicklung (OTE) [Wulf (1994), Wulf und Rohde (1995)]. Dieser Ansatz stellt ein Softwareprozess-Modell dar, bei dem die Anpassung ein integraler Bestandteil des Prozesses ist. Sie wird als eine Tätigkeit im Bereich des Einsatzes betrachtet, die zwischen der Nutzung und der Wartung anzusiedeln ist. Der Ansatz erweitert dazu das Softwareprozess-Modell STEPS5 um die Tätigkeit der Anpassung. Die Anpassung wird dabei als eine gemeinsame Aufgabe von Nutzern und Anpassungsspezialisten gesehen. Der Anpassungsspezialist kann ein Software-Entwickler, aber auch ein Angehöriger der EDV-Fachabteilung der jeweiligen Organisation sein. Die Wartung lässt sich von der Anpassung dadurch abgrenzen, dass die Wartung eine Tätigkeit der Entwickler ist und meist ohne direkte Beteiligung der Nutzer vollzogen wird. Sie zielt darauf ab, dass die in der Systemspezifikation festgelegten Leistungen vollständig erbracht werden. Demgegenüber wird der Anpassungsprozess durch Veränderungen im Anwendungsfeld ausgelöst, die während der Nutzung auftreten. Die Anpassungen zeichnen sich dadurch aus, dass sie mit begrenztem Aufwand und geringer Verzögerung im Anwendungskontext unter maßgeblicher Beteiligung der Nutzer vorgenommen werden können. Auch ist der Eingriff in das Systemverhalten nicht so tief wie bei der Wartung, und die Anpassungen können „nur im Rahmen [der] bei der Herstellung antizipierten 4 5 Die Dimension Zeit und Raum hat Johanson (1998) eingeführt, um CSCW-Systeme zu kategorisieren. Zu STEPS siehe Floyd, Reisin und Schmidt (1989) 10 Möglichkeiten“ [Wulf (1994)] erfolgen6. Bei der Abgrenzung der Anpassung gegenüber der Nutzung folgt der OTE-Ansatz der Definition von Henderson und Kyng. Eine Definition, die ohne Rekurs auf die Nutzung und den Benutzer auskommt, findet man bei Stiemerling (2000, S. 20). Er spricht von einem anpassbaren System, wenn es die folgenden drei Eigenschaften besitzt: 1. Eine Repräsentation der Systemeigenschaften, 2. eine Funktionalität, diese Eigenschaften zu ändern, 3. eine Verbindung zwischen Repräsentation und Systemeigenschaften. Die Anpassbarkeit eines Systems wird durch die Ausprägung dieser drei Punkte bestimmt. Im Folgenden wird von der fachlichen Sicht des Anpassens die Rede sein, wenn die sekundäre Tätigkeit des Anwenders im Sinne von Oberquelle gemeint ist. Dagegen wird von der technischen Sicht der Anpassbarkeit gesprochen, wenn es um die Softwareeigenschaften im Sinne von Stiemerling geht. 3.1.2 Empirische Studien über die Anpassungsgewohnheiten Die Anforderungen, die an die Anpassbarkeitsgestaltung gestellt werden, fußen zum Teil auf empirischen Studien [Rossen (1984), Mackay (1990), Gantt und Nardi (1992), Oppermann und Simm (1994), Trigg und Bødker (1994), Page et al. (1996), Wulf (1999), Biemans, Schuurman und Swaak (2001)]. In diesen Arbeiten wird das Anpassen von bestehenden Systemen durch die Anwender untersucht7. Die Applikationen, bei denen die Anpassungsgewohnheiten der Benutzer untersucht wurden, reichen von Textverarbeitungsprogrammen, Tabellenkalkulationen, CADSystemen, Handys, E-Mail Systemen bis zur Anpassung von Window-Managern und Shellskripten unter UNIX. In diesen Studien wurde eine Reihe von Einflussfaktoren gefunden, die das Anpassen auslösen bzw. behindern. Eine Zusammenfassung der wichtigsten Faktoren ist in Tabelle 3-3 aufgelistet. 6 Jedoch macht Mackay (1990) in ihrer Doktorarbeit darauf aufmerksam, dass Anpassung zwar durch das Design beschränkt wird, jedoch von den Anwendern in einer nicht antizipierten Art und Weise verändert werden kann. Es ist jedoch nur in Ansätzen erkennbar wie Software gestaltet werden muss, damit sie auch nicht antizipierte Anpassungen unterstützt. 7 Bei keiner Untersuchung wird jedoch explizit der Frage nachgegangen, welche Teile der Anwendung der Benutzer wie anpassen würden, wenn er denn könnte. ALLGEMEINE GRUNDLAGEN 11 Auslösende Faktoren Behindernde Faktoren Technologische Be- • Etwas funktioniert nicht mehr • Anpassung ist zu schwierig einflussung • System kennenlernen • Schlechte Dokumentation • Rechner- bzw. Software- • Probleme, die Anpassungsfunktion zu Umgebung wechseln finden • System Upgrade würde Anpassung nichtig machen Beeinflussung durch Organisation oder andere • Etwas bei einem Kollegen • Einhaltung von Firmenstandards gesehen • Anpassung durch jemand anderen Benutzer Beeinflussung • Einführung eines neues Systems durch externe • Einführung einer neuen Version Ereignisse • Wechsel der Aufgabe oder des Berufes Individuelle Faktoren • Sich wiederholende Muster entdecken • Keine Zeit • Kein Interesse • Langeweile, Neugierde • Unzufriedenheit ist nicht groß genug • Wenn dem Benutzer das • Festhalten an alten Mustern Systemverhalten zu lästig wird • Angst, etwas zu zerstören • Überflüssiges löschen • Ästhetische Gründe • Konfrontation mit neuen Dingen Tabelle 3-3 Faktoren, die die Anpassungsgewohnheiten der Benutzer beeinflussen [zit. nach Mackay (1990, S.185), leicht verändert und erweitert] Eine der umfassendsten Studien wurde von Mackay (1990) durchgeführt. Sie untersuchte die Anpassungsgewohnheiten der Mitarbeiter in einer Forschungsabteilung mit über 80 Personen, dem MIT’s Athena Project. Dazu studierte sie das Anpassen des WindowManagers und der Shellskripten unter UNIX durch die Mitarbeiter. Der in der Studie untersuchte Zeitraum erstreckte sich über vier Monate. Die Ergebnisse der Studie beruhen auf den dort gesammelten Eindrücken, der Auswertung von Interviews und von Konfigurationsfiles. Von den beteiligten Personen hatten einige technische, andere nichttechnische Aufgaben. Unterschiede gab es auch hinsichtlich der Erfahrungen mit Computersystemen. Die theoretische Grundlage für ihre Studie bildete das strukturrationale Modell der Technologie nach Orlikowski (1989), das sie in einigen 12 Punkten erweiterte8. Die von ihr gefundenen Einflussfaktoren ordnet sie auf Grund ihres Modells in vier Kategorien ein9: 1. Technische Beeinflussung, 2. Beeinflussung durch die Organisation oder andere Benutzer, 3. Beeinflussung durch externe Ereignisse und 4. individuelle Faktoren. Die unterschiedlichen Einflussfaktoren führen auch zu einem unterschiedlichen zeitlichen Verlauf der Anpassung10. So löst eine neue Version ein einmaliges Retrofitting11 aus, während das Kodieren von wiederkehrenden Mustern12 mit der Zeit eher zu- als abnimmt. Sie zeigt zudem, wie Benutzer das System in einer vorher von den Entwicklern nicht antizipierten Art und Weise umgestaltet haben. Aus ihren Ergebnissen leitet sie Anforderungen an die Softwaregestaltung ab, auf die ich im nächsten Abschnitt eingehe. Die Studie von Rossen (1984) über das Benutzerverhalten bei Textverarbeitungsprogrammen wird von Page et al. (1996) zu zwei Ergebnissen zusammengefasst: Erstens hat Rossen herausgefunden, dass Programmierer die Anpassungsmöglichkeiten intensiv nutzen, während Sekretärinnen dies nicht tun. Zweitens hat sie darüber hinaus einen Zusammenhang zwischen der Erfahrung eines Benutzers und dessen Anpassungsgewohnheiten festgestellt. So ist der Erfahrungshorizont des Anwenders im allgemeinen ein guter Indikator dafür, wie viele er von den Anpassungsmöglichkeiten nutzt. Auch Page et al. (1996) untersuchen das Anpassen eines Textverarbeitungsprogramms und zwar die kommerzielle Anwendung von WordPerfect 6.0a für Windows. Bei ihrer Studie wurden 101 Personen befragt, die über die Software-Registrierungsdatenbank für WordPerfect erhoben und über E-Mail kontaktiert wurden. Neben den zurückgesendeten Fragebögen gehörten zum Datenmaterial die angepassten Konfigurationsdateien und die aufgezeichneten Makros. Der Untersuchungszeitraum betrug 28 Tage. Die Auswertung ergab, dass 92% der Personen anpassten, 86% die generellen Einstellungen änderten, 63% die Möglichkeit nutzten, die Funktionalität durch Makros anzupassen und 16% diese auch selber aufzeichneten. Page et al. (1996) kamen deshalb zu dem Schluss, dass Anpassbarkeit sinnvoll ist und dass die Features dafür einfach, leicht und schnell zu benutzen sein müssen. Außerdem sollten sich die Anpassungsmöglichkeiten in die Arbeit integrieren. Demgegenüber sind Oppermann und Simm (1994) skeptisch, was den Gebrauch von Anpassungsvorrichtungen angeht. Sie haben deren Gebrauch bei Textverarbeitungsprogrammen, Tabellenkalkulationen, Datenbanken und Zeichnungs-Applikationen studiert. Ein Teil der Benutzer meinte, sie hätten einige der Anpassungsmöglichkeiten genutzt. So 8 Vgl. Mackay (1990, Kap. 2). 9 Vgl. Tabelle 3-3. Vgl. Mackay (1990, S. 161). 11 Mit Retrofitting ist gemeint, das neue System so anzupassen, dass es sich möglichst wie das Alte verhält. 12 Z.B. kann man ein häufig verwendeter Befehl mit einem alias versehen werden. 10 ALLGEMEINE GRUNDLAGEN 13 hätten sie globale Optionen geändert und Styles erstellt. Sie gaben an, dass durch Anpassungsoptionen es möglich sei, ihre Arbeit zu vereinfachen und Zeit zu sparen. Einige wenige Benutzer hatten auch Makros aufgezeichnet und die Menüauswahl verändert. Andere meinten jedoch, sie hätten die Dinge nur zum eigenen Vergnügen geändert. Die Arbeit von Wulf (1999) gründet sich auf der empirischen Untersuchung des Anpassens eines Textverarbeitungsprogramms. Hier wurden elf semi-strukturierte Interviews mit Benutzern des Programms Microsoft Word (Version 6 und Office 97) geführt. Die Benutzer hatten unterschiedliche Qualifikationen und auch die von Word unterstützte Arbeit war bei den Beteiligten unterschiedlich. Wulf kommt zu ähnlichen Ergebnissen wie Mackay, was das Retrofitting von Funktionen angeht. Ein anderes Ergebnis, das in fast allen Interviews auftaucht, ist das Problem, die Anpassungsfunktion zu finden. Er unterscheidet hier drei verschiedene Fälle. Im ersten Fall wissen die Benutzer, dass die Anpassungsfunktion existiert, z.B. durch eine vorhergehende Version oder Kollegen, aber sie können sie nicht finden. Im zweiten Fall können die Benutzer sich vorstellen, dass es eine solche Funktion geben müsste. Im letzten Fall wissen die Benutzer weder von der Existenz, noch können sie sich vorstellen, dass es eine solche gibt. Auf die Designimplikation, die er daraus ableitet, gehe ich in Abschnitt 3.1.3.9 ein. Die Studie von Trigg und Bødker (1994) und die Studie von Gantt und Nardi (1992) weichen in der Hinsicht von den oben skizzierten Forschungsarbeiten ab, als dass sie nicht die Anpassung durch den End-Anwender, sondern durch lokale Entwickler untersuchten. Gantt und Nardi (1992) interessierten sich dafür, wie ausgefallene Anpassungs- und Erweiterungsmöglichkeiten bei CAD-Systemen benutzt werden. Dazu beobachteten sie in sieben Betrieben nach der ethnografischen Methode, was die Benutzer von CAD-Systemen faktisch tun. In ihrer Studie führten sie 24 Tiefeninterviews mit 21 Benutzern und 3 Managern. Von den befragten Personen waren sieben Endbenutzer. Gantt und Nardi sammelten und untersuchten Erzeugnisse, die bei der Benutzung des CAD-Systems entstanden (Makroprogramme, Zeichnung, etc.) und studierten die Benutzung des Systems. Sie fanden heraus, dass es in allen Fällen mindestens einen lokalen Experten gab, der andere Benutzer unterstützte. In drei untersuchten Betrieben war die Stelle eines Anpassungsberaters13 offiziell vorgesehen. Vier von den sieben Endbenutzern machten keine Anpassungen. Sie mochten es nicht und da es einen lokalen Experten gab, brauchten sie es auch nicht. Gantt und Nardi diskutieren auch, welche Fähigkeiten der Anpassungsberater besitzen soll, und wie er in eine Organisation integriert werden kann. 13 Gantt und Nardi bezeichnen eine Person, die für andere anpasst bzw. dabei hilft, auch als Gardener bzw. Guru. 14 Das Forschungsinteresse von Trigg und Bødker (1994) liegt zum einen darin, die Anpassungsgewohnheiten der Entwickler und deren begleitende Aktivitäten wie Support, Wartung und Training unter die Lupe zu nehmen. Zum anderen geht es ihnen darum, wie die Arbeitspraxis durch den institutionellen Kontext beeinflusst und beschränkt wird. Sie benutzen wie Gantt und Nardi ethnografische Mittel zur Untersuchung. So haben sie das Arbeitsleben von vier Personen an einer staatlichen Institution durch teilnehmende Beobachtung erforscht. Drei Personen führten dabei Anpassungen für andere durch. Trigg und Bødker zeigen, dass Anpassung neben den technischen Aspekten auch eine organisatorische Aufgabe darstellt und ein betriebs-politischer Aushandlungsprozess ist. Sie stellen vor allem Anforderungen auf, die auf der Ebene des Managements und der Organisationsgestaltung anzusiedeln sind. 3.1.3 Anforderung an die Anpassungsgestaltung In diesem Abschnitt werden einige der Anforderungen formuliert, die in der Literatur im Zusammenhang mit der Anpassbarkeit erhoben werden. Bei den Anforderungen kann man zwischen technischen und nicht-technischen unterscheiden. Hier wird vor allem auf die technischen Anforderungen eingegangen, die an anpassbare Systeme gestellt werden. Die Anforderungen ergeben sich zum einen aus den systematisch durchgeführten empirischen Studien. Zum anderen basieren sie auf Erfahrungen, die bei Forschungsprojekten gesammelt wurden, die meistens aber nicht explizit überprüft worden sind. Auch lassen sich viele der Anforderungen aus dem Unterschied, der zwischen Anpassung und Wartung bzw. Nutzung besteht, ableiten. Da die Anpassung nicht zu den primären Tätigkeiten des Anwenders gehört, muss man davon ausgehen, dass er kein Spezialist in Sachen Systemgestaltung ist. Zudem kann man nicht erwarten, dass auf Seiten des Anwenders eine große Motivation existiert, sich lange in das Thema einzuarbeiten. Auf diesen fachlichen Unterschied von Entwickeln und Anpassen machen Trigg und Bødker (1994) aufmerksam14. 3.1.3.1 Bereitstellung verschiedener Anpassungstechniken und deren Stufung Gantt und Nardi (1992) kommen in ihrer Studie zu dem Schluss, dass das Wissen hinsichtlich des Computers unter den Benutzern ein Kontinuum darstellt. Die Aufgabe der Softwaregestaltung ist es, die Endpunkte des Kontinuums zu bestimmen und den verschiedenen Benutzern eine auf ihre Fähigkeiten abgestimmte Anpassungsumgebung 14 Für sie ist das Software erstellen das Entwickeln von Theorien über den Anwendungskontext. Sie folgen dabei Naur (1992). Im Gegensatz dazu basiert für sie das Anpassen weder auf einem abstrakten Modell des Gebrauchs, noch auf einem formalen Konzept des technischen Artefakts. ALLGEMEINE GRUNDLAGEN 15 bereitzustellen. Gantt und Nardi fordern zudem, dass es eine Stufung der Anpassungsumgebungen geben sollte, damit es für den Benutzer einfacher ist, seine Fähigkeiten zu steigern. Bentley und Dourish (1995) sehen bei den meisten bestehenden Systemen eine Kluft zwischen einer oberflächlichen und einer tiefgreifenden Anpassung, die sich in der Aufteilung der Systemarchitektur in Interface und Funktionalität widerspiegelt. Die Kluft wird von ihnen auch als Anpassungskluft („customization gulf“) bezeichnet. Diese Kluft, die der Praxis des Software-Engineerings entstamme, sei jedoch künstlich und reflektiere nicht die Erfordernisse der Anpassbarkeits-Anforderungen der Benutzer. Sie führe dazu, dass die meisten Systeme kaum flexible Mechanismen für tiefgreifende Anpassungen besitzen. Bentley und Dourish (1995) verweisen auf die Ergebnisse von McLean et al. (1990), die feststellen, dass es bei den meisten Systemen keinen sanften Übergang zwischen einfachem und tiefgreifendem Anpassen existiert. Zu sehen ist die Kluft in den zwei steilen Anstiegen des in Abbildung 3-2 dargestellten Graphs. Der eine liegt zwischen dem „Worker“ und Tinkerer“, der andere liegt zwischen „Change Parameters“ und „Programming Language“. Abbildung 3-2 Zusammenhang zwischen der Mächtigkeit des Anpassungsmechanismus und der notwendigen Qualifikation, den Mechanismus anzuwenden [aus McLean et al. (1990, S. 175)] Die Anpassungskluft ist nach Bentley und Dourish (1995) durch zwei miteinander verschränkte Probleme charakterisiert. Das eine ist der Level der möglichen Anpassung, der meist ziemlich niedrig ist. Das andere ist die Anpassungs-Sprache, die normalerweise dem Anwender kaum Möglichkeiten gibt, seine Anforderungen mit den Fähigkeiten auszudrücken, die er schon besitzt. Beide führen dazu, dass der Anwender keine Möglichkeit hat, in das System einzudringen und es in der Art und Weise anzupassen, dass die Funktionalität des Systems zu der Leistung seiner Arbeit passt. 16 Ein Lösungsansatz, den man bei Bentley und Dourish (1995), aber auch bei anderen Autoren findet, besteht in einer inkrementellen Steigerung der Anpassungstechniken und deren Komplexität. Eine summarische Auflistung von Anpassungstechniken findet sich bei Oberquelle (1994). In Mørch (1997) ist eine Stufung der Techniken vorgenommen15. Die Aufgabe der Techniken, so Mørch, besteht darin, die Distanz zwischen den Präsentationsobjekten, die für den Benutzer zugänglich sind, und der darunter liegenden Implementierung zu überwinden. Bei seiner Analyse hat er drei Stufen ausgemacht: Customization, Integration und Extension (vgl. Tabelle 3-4). Stufe Beschreibung Customization Customization ist das Ändern des Aussehens einer Applikation oder das Editieren von Attributwerten durch das Auswählen einer vordefinierten Menge von Konfigurationsoptionen. Beispiel: Das „Anpassen“ – Menü bei Word Integration Feste Integration: Eine Komponente wird integriert durch „Copy & Paste“-Operationen. (Hier kann noch zwischen textlichen und binären Komponenten unterschieden werden). Beispiel: PlugIns Weiche Integration: Erstellen oder Aufnehmen einer Programmausführung, die eine neue Funktionalität darstellt und die mit der Applikation als Kommando oder Komponente gespeichert wird. Beispiele: HyperTalk, Visual Basic Script oder AppleScript und der Makrorekorder bei Emacs Extension Extension ist eine Anpassungstechnik, bei der die Funktionalität einer Applikation durch das Hinzufügen von einem neuen Code verbessert wird. Beispiel: Subclassing bei streng getypte Sprachen Changing Changing ist das Ändern des Quellcodes einer Applikation. Beispiel: OpenSource-Projekte Tabelle 3-4: Stufen von Anpassungstechniken [vgl. Mørch (1997), Mørch, Stiemerling und Wulf (1992)] Mørch und Mehandjiev (2000) sehen in den Stufungen eine Möglichkeit von einer benutzer-, domain- bzw. aufgabenorientierten hin zu einer systemorientierten Darstellung zu gelangen. Die vierte Stufe unterscheidet sich dabei im technischen Sinne nicht von der Softwarewartung. Jedoch besteht auf der fachlichen Seite der Unterschied, dass die Anpassung nur den lokalen Bedürfnissen Rechnung tragen muss. 15 Vgl. auch Henderson und Kyng (1991, S. 226) ALLGEMEINE GRUNDLAGEN 17 3.1.3.2 Kontextspezifische Anpassbarkeit Der Umstand, dass Anpassungen aufgrund von konkreten Arbeitssituationen geschehen und nicht auf einem abstrakten Modell des Gebrauchs basieren, führt zu unterschiedlichen Forderungen. Trigg und Bødker (1994) leiten daraus die Forderung ab, dass es für die anpassende Person eine Möglichkeit geben muss, einen Schritt zurückzugehen, um einen größeren Blickwinkel und eine abstraktere Sicht auf die Sache zu erhalten. Ansonsten würden, auf lange Sicht gesehen, die jeweiligen Anpassungen zueinander unverträglich werden. Mackay (1990) meint wiederum, dass die „Situiertheit des Gebrauchs”16 bei der Systemgestaltung zu berücksichtigen ist. Am Beispiel von Mail-Filtern zeigt sie, dass es schwierig ist, allgemeine Bedingungen anzugeben, wann diese angewandt werden sollen. In der konkreten Situation können die Benutzer selbst einschätzen, ob es sinnvoll ist, einen Filter zu benutzten. Mackay stellt deshalb die Forderung auf: „Allow users to encode patterns of behaviour and informally include information about their current work contexts” [Mackay (1990, S. 278)]. Eine Möglichkeit dies zu realisieren, besteht darin, dass das Design an den Arbeitskontext anknüpft. Eine solche Idee findet sich auch beim WAM-Ansatz (siehe Abschnitt 3.3). Auch bei Nardi (1993) findet sich die Forderung, dass Programmiersprachen für den Endanwender domainspezifische Sprachkonstrukte mit aufzunehmen haben. Henderson und Kyng (1991, S. 231) fordern, dass der Anwender mit möglichst wenig neuen Mechanismen auskommen sollte. Dadurch könne er Änderungen mit bereits vertrauten Mitteln durchführen. 3.1.3.3 Förderung der Anpassungskultur Von verschiedenen Autoren wurde die Beobachtung gemacht, dass ein entscheidender Faktor für erfolgreiches Anpassen in der Entwicklung einer Anpassungskultur („tailoring culture“) besteht [Carter und Henderson (1990), McLean et al. (1990), Mackay (1990, 1991), Trigg und Bødker (1994)]. Mit dem Entwickeln einer Anpassungskultur ist zum einen gemeint, eine Umgebung zu schaffen, die die Anwender anregt, die Software anzupassen. Zum anderen soll auch eine Kultur etabliert werden, die das kollektive Anpassen fördert. Beide Punkte werden im Idealfall sowohl durch die Organisationsstruktur bzw. das Management als auch durch die Technik unterstützt. 16 Dass jede Art des Gebrauchs in einem essentiellen Sinne im materiellen und sozialen Umfeld verhaftet ist, hat Suchman (1987) gezeigt. Sie spricht in dem Zusammenhang auch von „situated actions“, vgl. Suchman (1987, S. 50). 18 Trigg und Bødker (1994) fanden in ihrem Fall heraus, dass in der Organisation ein informelles „Wer fragt Wen“-Netzwerk existiert. Häufig wird in der Literatur auch eine Person beschrieben, die die Rolle eines Anpassungsberaters einnimmt. Bei Mackay (1990) heißt sie Translator, Gantt und Nardi (1992) sprechen von Gardeners und Gurus. Mackay (1990) fand heraus, dass die Anpassungsberatung keine offiziell vorgesehene Aufgabe ist. McLean et al. (1990) plädieren deshalb dafür, eine solche Stelle, die sie Handyman nennen, einzurichten. Der Handyman hat neben der Beraterfunktion auch die Aufgabe, zwischen Anwendern und Entwicklern zu vermitteln. Ein Befund der Studie von Gantt und Nardi (1992) war der, dass die inoffizielle Position des Anpassungsberaters in einigen Organisationen einer formalen oder semi-formalen Position gewichen ist. Auf der technischen Seite besteht die Hauptanforderung darin, dass Anpassungen zwischen den Benutzern ausgetauscht werden können, z.B. mittels Konfigurationsfiles17. Neben dem Austausch soll es, gerade im Groupware-Bereich, auch möglich sein, Anpassungen kollektiv zu nutzen. Dies führt aber zu dem Problem, den Geltungsbereich einer Anpassung festzulegen (vgl. Abschnitt 3.1.3.5). Beim Austausch von Anpassungen besteht die technische Herausforderung darin, dass die Anpassungen nicht abhängig sind vom Rechnersystem, auf dem sie erstellt worden sind. Eine technische Unterstützung der organisatorischen Probleme kann zum Beispiel darin bestehen, dass man dem Benutzer hilft, fremde Anpassungen oder den richtigen Ansprechpartner zu finden, indem man das „Wer-fragt-wen“-Netzwerk elektronisch abbildet. 3.1.3.4 Anpassbarkeit und Sicherheit McLean et al. (1990) beschreiben so genannte Buttons mit deren Hilfe die Benutzer ihr System anpassen können. Diese Buttons waren in Xerox Lisp geschriebene Skripts, die „drückbar“ („pressable“) aussahen und wenn sie gedrückt wurden, eine Aktion ausführten. Sie konnten mittels E-Mail zwischen den Benutzern ausgetauscht werden. Diese Idee hat auch Eingang in E-Mail-Programme, wie z.B. Outlook, gefunden. Diese Eigenschaft hat in neuerer Zeit jedoch vor allem Schlagzeilen durch die Sicherheitsprobleme gemacht, die dadurch entstanden sind, dass Viren bzw. Würmer dieses Feature ausnutzen. Abbildung 3-3 zeigt die Warnmeldung einer Sicherheitstest-E-Mail, die in ihrem Aufbau dem NimdaVirus versandten Botschaften entspricht. 17 Für Mackay (1990) ist das sogar eine Grundbedingung um überhaupt von Anpassbarkeit zu sprechen. ALLGEMEINE GRUNDLAGEN 19 Abbildung 3-3 Warnmeldung einer Sicherheitstest-E-Mail, die beim Anklicken des mitgelieferten Anhangs erscheint [siehe Siering (2000)] Welche Auswirkungen Viren auf das Konzept der Anpassbarkeit haben, wurde noch nicht genau untersucht18. Jedoch haben die Forderungen der Exploration (3.1.3.6), der Beschränkung des Geltungsbereichs (3.1.3.5) und der Anpassungsmöglichkeiten (3.1.3.7) mit der hier dargestellten Problematik insoweit eine Gemeinsamkeit, als dass sie alle versuchen, Anpassungen zu verhindern, die zu nicht gewünschtem Systemverhalten führen können. 3.1.3.5 Beschränkung des Gültigkeitsbereichs Auf die Konflikte, die beim gemeinsamen Gebrauch von Anpassungen entstehen können, haben schon Henderson und Kyng (1991) hingewiesen. Sie umreißen das Problem eines Anwenders, der eine Änderung am System vornehmen will, wie folgt: “Such coordination requires a user to be able to know who is affected by the change being contemplated and to interact with them. When people do not want to change, it may a1so require more complex mechanisms for supporting out-of-sync evolution of systems, in which systems with different modifications can inter-operate together.” Henderson und Kyng (1991, S. 233) Systematisch haben sich Wulf, Stiemerling und Pfeifer (1999) mit dem Fall befasst, dass Anpassungen nicht gleichmäßig für das gesamte System gelten sollen. Sie fordern, dass es gerade im Groupware-Bereich möglich sein muss, unterschiedliche Gültigkeitsbereiche für die Anpassung zu spezifizieren. Der Geltungsbereich besteht aus einer Teilmenge aller Situationen, in der das System verwendet wird und gibt an, ob die Anpassung angewendet werden soll bzw. darf. Das Festlegen eines Gültigkeitsbereichs kann man als ein Spezialfall der Festlegung von Zugriffsrechten ansehen. Jedoch gibt es bei der Anpassung zusätzlich die Schwierigkeit, 18 Jedoch stellen sie meines Erachtens einen sehr interessanten Untersuchungsgegenstand dar. Denn auf der technischen Ebene sind Viren ein Beispiel für eine nicht antizipierte Möglichkeit, das Computersystem anzupassen. Auf fachlicher Ebene kann man sicherlich nicht von Anpassung sprechen, weil Viren die Kontrolle des Anwenders absichtlich unterlaufen und auch zu keinem besseren Fit führen. 20 herauszufinden, wann zwei Anpassungen hinsichtlich des Systemverhaltens zu einander inkonsistent sind. So können z.B. zwei Anpassungen durch Seiteneffekte zueinander unverträglich sein und unter Umständen dadurch das gesamte System destabilisieren. Der Wunsch, zu überprüfen, ob die Anpassung den gewünschten Effekt hat, führt zu der Forderung des Explorations-Modus (Abschnitt 3.1.3.6). 3.1.3.6 Explorations-Modus Mackay (1990, S. 140) schildert das Problem, dass Anpassungen auch zu „Verschlimmbesserungen“ führen können. Aus diesem Problem leitet sich die Anforderung nach der Explorierbarkeit von Anpassungen ab. Durch die Explorierbarkeit soll es nach Won (1998, S. 25) „einem Benutzer möglich sein, das Verhalten, das sich durch die Anpassung ändert, mit dem intendierten Verhalten zu vergleichen, ohne dass die Anpassung schon tatsächlich in das System integriert wurde.“ Henderson und Kyng (1991, S. 235) fordern unter dem Gesichtspunkt des Lernens ebenfalls einen Explorations-Modus. Dieser würde es dem Anwender erlauben, in einer sicheren Art und Weise mit den Anpassungen zu experimentieren. Unter dem Gesichtspunkt des Lernens wurde der Explorations-Modus auch von Wulf (2000) untersucht. 3.1.3.7 Anpassungsmöglichkeiten beschränken Die obigen Beispiele zeigen, dass die totale Flexibilität nicht unbedingt ein erstrebenswertes Ziel ist. Stiemerling (1997) schlägt deshalb vor, die Anpassung durch „tailoring constraints“ zu beschränken. Er unterscheidet dabei zwischen „static constraints“, die bestimmte Systemzustände verbieten und „transitional constraints“, die bestimmten Systemübergänge verbieten. Das Konzept der „architectural invariants“19 aus dem Bereich der Software-Wartung kann nach Stiemerling als ein Beispiel für „static constraints“ gelten. 3.1.3.8 Direkte Auswirkungen von Anpassungen Obwohl, wie in Tabelle 3-1 aufgelistet, eines der Kriterien der Anpassung bei Henderson und Kyng (1991) die indirekte Auswirkung ist, sollten gerade in Groupware-Systemen Anpassungen zur Laufzeit durchführbar sein, denn die Systeme müssen Tag und Nacht laufen und ein Herunterfahren des Systems würde die Mitarbeiter bei ihrer Arbeit stören [ Won (1998), Stiemerling und Cremers (1998)]. 19 Vgl. Minsky (1997). ALLGEMEINE GRUNDLAGEN 21 3.1.3.9 Direkte Aktivierbarkeit der Anpassungsfunktion Das Konzept der direkten Aktivierung, so Wulf (1999), ist es, das Finden der Anpassungsfunktion in dem Moment zu unterstützen, in dem sie gebraucht wird. Anpassung wird aus der Sicht des Benutzers dann gebraucht, wenn die Benutzung einer Funktion nicht zu dem gewünschten Effekt führt oder zu umständlich zu benutzen ist. Im Fall des normalen Gebrauchs einer Funktion, so nimmt Wulf (1999) an, ist dem Benutzer der Einstiegspunkt der Funktion bewusst. Eine andere Kategorie bilden die Funktionen, die nicht vom Benutzer ausgelöst werden. Diese haben per Definition keinen Einstiegspunkt, so dass nur die Präsentation ihrer Ausführung bzw. ihrer Ergebnisse die einzig wahrnehmbaren Stellen darstellen. Das Konzept der direkten Aktivierung sieht vor, dass die zugehörige Anpassungsvorrichtung einer Funktion an die Einstiegpunkte gekoppelt werden soll. Falls keine Einstiegspunkte vorhanden sind, soll die Anpassungsvorrichtung an den Stellen aktiviert werden können, an denen die Ausführung der Funktion sichtbar wird. Dies kann z.B. über eine wahrnehmbare Präsentation der Aktivierung geschehen oder durch die Möglichkeit, einen speziellen Anpassungsmodus durch eine Tastenkombination zu aktivieren. 3.1.3.10 Rückmeldung über die Anpassungen geben Mackay (1990) sieht im Anpassen eine Investition in die Zukunft, die auf unzureichendem Wissen basiert. So entscheiden sich Individuen zum Anpassen, wenn sie auf interne oder externe Ereignisse reagieren. Diese Entscheidung beruht aber auf einer subjektiven Wahrnehmung und nicht auf dem wirklichen aktuellen Verhalten. Deshalb fordert Mackay (1990, S. 319), dass ein anpassbares System dem Benutzer Rückmeldung darüber geben sollte, wie wirkungsvoll seine Anpassungsentscheidung ist und so ihm die Gelegenheit gegeben wird, über den aktuellen Vorgang des Gebrauchs nachzudenken. Diese Eigenschaft nennt sie reflexiv. Geht es bei Mackay um individuelle Anpassung, beschäftigen sich Henderson und Kyng (1991, S. 235) mit der Rückmeldung bei Gruppenanpassungen. Für sie ist es essentiell, dass der Verfasser einer Änderung von den betroffenen Anwendern und ihren Bedürfnissen eine Rückmeldung bekommt. Sie fordern deshalb, dass Anpassbarkeit nicht unabhängig von den Kommunikationsmechanismen betrachtet werden soll, die das Teilen von Anpassungen und die Rückmeldungen darüber unterstützen. 22 3.1.3.11 Erklärung des Designs mit in das System integrieren McLean et al. (1990, S. 177) konstatieren: “Tailorability shifts some of the system design problems to end users, a role for which they are ill-equipped”. Damit der Anwender nicht allein gelassen wird, ist eine zusätzliche Unterstützung notwendig. Eine Forderung von MacLean et al. ist es deshalb, auch Erläuterungen zum Design der Anwendung mit in das System zu integrieren. Die Forderung von Mørch und Mehandjiev (2000), die indirekte, langfristige Mitarbeit der Entwickler bei der Anpassbarkeit zu unterstützen, zielt in eine ähnliche Richtung20. Bei ihrem Ansatz zur Unterstützung unterscheiden sie zwischen den mehrfachen Repräsentationen („multiple representations“) und Anwendungseinheiten („application units“). Die mehrfachen Repräsentationen sollen den reichen Entwicklungskontext einfangen, so dass dieser mit dem Benutzer geteilt werden kann. Bei den Repräsentationen unterscheiden sie zwischen den benutzerorientierten und den designorientierten. Während die benutzerorientierten Repräsentationen einen abstrakten Überblick über das System geben, und das „How to use“ erklären, dienen die designorientierten Repräsentationen dazu das „Was“ und das „Wie“ zu erklären. Zu den designorientierten Repräsentationen zählen Mørch und Mehandjiev (2000) sowohl Anforderungsspezifikationen, als auch Dokumente, die die Designgründe erläutern. Die Anwendungseinheiten sollen dem Anwender die mehrfachen Repräsentationen während der Nutzung zugänglich machen. Sie enthalten drei Arten von Repräsentationen: 1. die Benutzerschnittstelle, 2. Erläuterungen und 3. den Programm-Kode. Eine Umsetzung des Ansatzes, auf den ich hier nicht eingehe, zeigen Mørch und Mehandjiev (2000) anhand einer Grafikprogramm-Implementierung. 3.2 Komponentenbasierte Anpassbarkeit Eine Motivation für die komponentenbasierte Anpassbarkeit findet sich bei Henderson und Kyng (1991), die in der Dekomposition die wichtigste Aufgabe beim Entwickeln eines anpassbaren Systems sehen. Sie muss auf das Verstehen durch den Anwender ausgerichtet sein. Ihre Aussage über die objektorientierte Gestaltung kann dabei auf Softwarekomponenten übertragen werden: „Object oriented design and implementation are a promising basis for this kind of work since they may allow us to shorten or even bridge the gap between the structure of computer systems and their code on the one hand and the structure of the work and concepts of the application area on the other.” Henderson und Kyng (1991, S. 240) 20 Mørch und Mehandjiev (2000) verstehen Anpassbarkeit als eine durch den Computer vermittelte Kooperation zwischen Benutzer und Entwickler (vgl. S. 9). ALLGEMEINE GRUNDLAGEN 23 Daneben geben die Gemeinsamkeiten von Anpassung und Wartung Anlass dazu, zu prüfen, inwieweit Konzepte, die unter dem Gesichtspunkt der Wartbarkeit von Software entwickelt wurden, auch auf die Gestaltung der Anpassbarkeit übertragbar sind. Eines der Konzepte, von dem man sich eine bessere Wiederverwendbarkeit, aber auch eine bessere Wartbarkeit verspricht, ist die Verwendung von Softwarekomponenten. 3.2.1 Softwarekomponenten Softwarekomponenten werden meist durch einen Vergleich mit den klassischen Ingenieursdisziplinen, wie der Automobilkonstruktion, motiviert. Durch die Wiederverwendung vorgefertigter, genormter Teile lassen sich kürzere Entwicklungszeiten und preiswertere Produktionskosten erreichen, so z.B. Lumpe (1999) und Szyperski (1998). Diese Idee der Komponenten versucht man auf die Softwareentwicklung zu übertragen. Dadurch soll die Wiederverwendbarkeit durch Dritte erhöht werden und zu einer besseren Wartbarkeit des Systems führen. Jedoch existiert keine allgemein anerkannte Definition, was Softwarekomponente zu verstehen ist, wie folgende Zitate demonstrieren21. unter einer “A software component is a static abstraction with plugs.” Nierstrasz und Tsichritzis (1995) „A software component is a unit of composition with contractually specified interfaces and explicit context dependencies only. A software component can be deployed independently and is subject to composition by third party.” Szyperski (1998, S.34) “A component is a physical, replaceable part of a system that packages implementation and provides the realization of a set of interfaces. A component represents a physical piece of implementation of a system, including software code (source, binary or executable) or equivalents such as scripts or command files.” OMG (1999, S. 2-29) In der Definition von Nierstrasz und Tsichritzis kommt der Kern des Konzepts der Softwarekomponenten zum Ausdruck. Szyperski beschreibt hingegen die maßgeblichen Anforderungen, die an eine Komponente gestellt werden. Er definiert damit, was unter einer gelungenen Softwarekomponente zu verstehen ist. 21 Eine längere Zitatensammlung findet sich bei Szyperski (1998, S. 164 ff.). 24 In der vorliegenden Arbeit werde ich weitgehend die Begriffsbestimmung von Stiemerling (2000, S. 45) übernehmen, der von Komponenten-Modellen spricht. Unter einem Komponenten-Modell wird eine Spezifikation verstanden, die festlegt, was unter einer Komponente zu verstehen ist. Das Modell bestimmt, wie ein Stück Software aussehen muss, damit es die Bedingungen erfüllt, die an einen Komponenten-Typ bzw. an eine Komponenten-Instanz gestellt werden. Außerdem wird spezifiziert, wie ein Typ erzeugt wird, wie die Instanzen miteinander interagieren und wie die Interfaces für diese Interaktion aussehen. Die Spezifikation sollte auch beschreiben, welche Annahmen man aufgrund des Interfaces über die implementierende Komponente machen kann. Innerhalb eines Komponenten-Modells ist dann eindeutig festgelegt, was eine Softwarekomponente ist und was nicht. Im kommerziellen Bereich haben sich verschiedene Komponenten-Standards etabliert, die jeweils ein Komponenten-Modell im oben genannten Sinne beschreiben. Die wichtigsten dieser de-facto Standards sind CORBA von der OMG, die (Enterprise) JavaBeans von Sun und COM bzw. COM+ von Microsoft22. Ein Vergleich der, diesen Standards zugrunde liegenden, Konzepte findet sich bei Szyperski (1998). Ciupke und Schmidt (1996) haben die Modelle danach untersucht, welche Methoden sie bereitstellen, um die Abhängigkeit vom Kontext zu verringern. Dabei unterscheiden sie zwischen konzeptionellen und technischen Methoden. Die Abstraktion sehen sie als die wichtigste konzeptionelle Methode an. Sie sieht von konkreten Details ab und fördert damit die Unabhängigkeit in einem konzeptionellen Sinne. In Tabelle 3-5 sind eine Reihe von technischen Eigenschaften aufgelistet, welche die Unabhängigkeit verbessern. CORBA OLE/COM JavaBeans Separate compiling + + + Language independent + + - Processes + + + Distribution + + + Program version planned + + Operation system independent + in future + Tabelle 3-5 Vergleich verschiedener Komponenten-Modelle [Ciupke und Schmidt (1996)] 22 COM bzw. COM+ werden langfristig, nach Aussagen von Microsoft, durch ihre .NET Strategie ersetzt. ALLGEMEINE GRUNDLAGEN 25 In ihr werden die verschieden Standards gegenübergestellt und verglichen, wie diese die technischen Eigenschaften unterstützen. Dass Komponenten einzeln kompiliert werden können („separate compiling“), macht sie von der Implementation anderer Komponenten unabhängig. Dass sie verteilt ausgeführt werden können („distribution“) und nicht von einem bestimmten Betriebssystem abhängen („operation system independent“) erlaubt es, die Komponenten in verschiedenen Einsatzszenarios zu verwenden. Die Parallelität („processes“) erlaubt es einer Anwendung, mehrere Komponenten parallel laufen und sie von verschiedenen Prozessen aufrufen zu lassen. Die Versionierung („program version“) erlaubt es, eine Komponente um zusätzliche Funktionalität zu erweitern, ohne die Anwendung zu verändern. Durch das Sprachunabhängige („language independent“) wird erreicht, dass die Entwicklung einer Komponente von der Wahl der Programmiersprache unabhängig ist. 3.2.2 Kompositionsbeschreibungssprachen Bei den oben genannten Standards steckt die Zusammensetzung der Komponenten, auch „Verdrahtung“ genannt, meist implizit in den Komponenten selbst und kann nur bedingt durch Reengineering-Tools wieder zurückgewonnen werden. Dadurch geht leicht der Überblick über den Aufbau verloren und das Re-Komponieren der Anwendung wird erschwert. Demgegenüber gibt es in der Forschung verschiedene Ansätze, die Verdrahtung durch eine eigene Beschreibung zu spezifizieren. Bei der dafür vorgesehenen Sprache spricht man deswegen auch von der Kompositionsbeschreibungssprache (CDL)23 oder allgemeiner von der Strukturbeschreibungssprache. Das Problem, die Struktur eines Computersystems zu beschreiben, findet man in verschiedenen Bereichen der Informatik. Dies ist der Grund, dass ähnliche Konzepte unter unterschiedlichen Bezeichnungen anzutreffen sind. Neuerdings wird häufig der Begriff der Architekturbeschreibungssprachen (ADL)24 benutzt. In der Forschung sind eine Reihe von ADLs entwickelt worden, die jeweils einen anderen Schwerpunkt setzen. Einige davon sind in Tabelle 3-6 aufgelistet. 23 24 CDL steht für Composition Description Language. ADL steht für Architecture Description Language. 26 Sprache ACME Darwin OLAN Einsatzschwerpunkt ACME dient dazu, Architekturinformationen zwischen verschiedenen ADL-Sprachen auszutauschen. Sie stellt deshalb eine Lingua franca dar, mit der sich verschiedene ADLs vergleichen lassen [Garlan, Monroe und Wile (1997)]. Darwin dient der Analyse verteilter Systeme, deren Komponenten über den Austausch von Nachrichten kommunizieren („message-passing systems“) [Magee et al. (1995), Ng und Kramer (1995), Radestock und Eisenbach (1996)]. OLAN wurde entworfen, um heterogene Altlast-Systeme zu integrieren und sie auf ein verteiltes Netzwerk von Prozessknoten zu verteilen [ Bellissard et al. (1995), Bellissard et al. (1996)]. Wright Picolla EJB Wright dient der Spezifikation und der statischen Analyse von Architekturen [Allen (1997), Allen und Garlan (1997)]. Picolla ist eine experimentelle Kompositionssprache, die dem Paradigma „Application = Components + Scripts“ folgt [Schneider (1999), Achermann et al. (2001), Achermann und Nierstrasz (2001)]. Enterprise JavaBeans (EJB) sind für unternehmenskritische Back-End Anwendungen entworfen worden, bei denen Transaktionen mit persistenten Daten im Vordergrund stehen [Sun Microsystems (2001)]. Tabelle 3-6 Architekturbeschreibungssprachen und ihr Einsatzschwerpunkt In Abschnitt 3.3.3 wird CAT, eine Abwandlung von DARWIN, beschrieben. CAT dient beim FlexiBean-Ansatz als Kompositionsbeschreibungssprache. Ich beschreibe an dieser Stelle allerdings nicht DARWIN, sondern nur die Haupteigenschaften von ACME. Dass die Sprache ACME beschrieben wird, liegt daran, dass sie als eine Lingua franca für ADLs entwickelt wurde, mit deren Hilfe man die unterschiedlichen Ansätze vergleichen kann. ALLGEMEINE GRUNDLAGEN 27 Abbildung 3-4 Die Strukturelemente der ACME [Garlan, Monroe und Wile (1997, S. 53)] Die Struktur einer Komponentenarchitektur ist durch folgende Eigenschaften gegeben: Komponenten („components“) repräsentieren die rechnenden Elemente und die Datenspeicher des Systems. Eine Komponente kann mehrfache Interfaces besitzen, wobei jedes mit einem Port benannt wird25. Ports identifizieren einen Punkt zur Interaktion zwischen einer Komponente und seiner Umgebung. Ein Port kann für ein einfaches Interface oder eine Prozedursignatur, aber auch für ein Protokoll stehen. Verbindungen („connectors“) repräsentieren die Interaktionen zwischen den Komponenten. Verbindungen haben ebenfalls Interfaces, die durch eine Menge von Rollen definiert sind. Eine Verbindung mit zwei Rollen heißt binäre Verbindung. Rolle („role“) ist das Gegenstück zum Port. Jede Rolle einer Verbindung definiert auf der Seite der Verbindung einen Teilnehmer einer Interaktion. Systeme („systems“) sind definiert durch die Komponenten, die Verbindungen und deren Interaktion und sie können durch einen Graphen repräsentiert werden. Systeme können auch hierarchisch sein. Dann repräsentieren Verbindungen und Knoten die „Binnen“-Architektur eines Subsystems. Repräsentation definiert die Außenansicht eines Subsystems. Es ist erlaubt, dass jedes Subsystem mehrere Repräsentationen besitzt. Rep-Maps geben an, wie eine Außenansicht auf eine Binnenarchitektur abzubilden ist26. Neben der Struktur besitzt eine Architekturbeschreibung meist noch weitere Angaben. Das sind vor allem Hilfsinformationen, die Dinge wie Laufzeiteigenschaften, Semantik, Protokolle, Ausführungsbeschränkung und Ressourcenverbrauch festlegen. Um diese zu unterstützen, erlaubt ACME die Strukturbeschreibung zu kommentieren. Dies geschieht 25 ACME ist als Austauschsprache und nicht zur Beschreibung lauffähiger Systeme gedacht. Deshalb muss den Komponenten nicht unbedingt ein Komponenten-Modell zugrunde liegen. 26 Das Subsystem mit Repräsentation und Rep-Map wird beim FlexiBean-Ansatz durch zusammengesetzte Komponenten realisiert. Das Subsystem besteht aus den internen Verbindungen. Eine Repräsentation besteht dann aus den exportierten Ports und durch die Rep-Map werden die exportierten Ports mit internen Ports verbunden (vergleiche dazu auch Abschnitt 3.3.3). 28 durch so genannte Properties. Sie besitzen einen Namen, optional einen Typ und einen von ACME nicht interpretierten Wert. Zudem stellt ACME eine eigene Sprache zur Verfügung27, mit deren Hilfe sich Bedingungen („constraints“) spezifizieren lassen, die die Architektur erfüllen muss. Neben einzelnen Architekturbeschreibungen gibt es auch die Möglichkeit, allgemeine Architekturstile („architecture styles“) bzw. -muster zu spezifizieren. In ACME können solche Stile durch die Angabe eines Typsystems beschrieben werden. Ein Typ besteht dabei aus einem Namen und einer Liste der verlangten Substrukturen, Properties und Bedingungen. 3.2.3 Komponentenbasierte Anpassbarkeit und Anpassungstechniken Die Beschreibung des Systems, die durch die CDL gegeben ist, bietet eine Möglichkeit zur Anpassung. Durch das Ändern der Beschreibung ändert man auch das System. Man kann in diesen Fall also von Anpassung sprechen. Wendet man nun die Definition der technischen Anpassbarkeit von Stiemerling (2000, S. 20) auf komponentenbasierte Systeme an, kommt man zur Definition der komponentenbasierten Anpassbarkeit. Definition der komponentenbasierten Anpassbarkeit [Stiemerling (2000, S.26)]: Ein Computer-System ist komponentenbasiert-anpassbar, wenn es folgende Bestandteile besitzt: 1. ein Komponenten Modell, 2. eine Kompositionsbeschreibungssprache (CDL), 3. eine Funktion, die die in der CDL beschriebenen Komposition auf aktuell erzeugte Komponenten, die das Software-System lauffähig machen, abbildet, 4. die Funktionalität, die Komposition zu verändern. Es bietet sich an, für die in Tabelle 3-4 aufgezählten Techniken äquivalente Techniken im Bereich der komponentenbasierten Anpassbarkeit zu suchen. Eine solche Übertragung der Stufung findet sich bei Stiemerling (2000, S. 56 ff.), der eine dreiteilige Aufgliederung der Techniken vornimmt. Eine leicht geänderte Stufung ist in der Tabelle 3-7 wiedergegeben. 27 Die Sprache basiert auf der Prädikatenlogik erster Ordnung. ALLGEMEINE GRUNDLAGEN Stufe 29 Beschreibung Konfigurieren Das Konfigurieren der Parameter einer einzelnen Komponente entspricht weitestgehend der Technik der Customization. einer Komponente Ändern der Komposition und das Einfügen neuer Komponenten typen Das Ändern der Komposition erlaubt eine größere Möglichkeit, das System anzupassen und auf nicht antizipierte Anforderungen zu reagieren. Diese Stufe verlangt auf der anderen Seite vom Anwender, dass er nicht nur die einzelne Komponente, sondern auch deren Zusammenhang versteht. Reicht das Ändern der Komposition nicht aus, kann der Anwender z.B. bei Kollegen oder auf dem freien Markt nach der passenden Komponente suchen und sie einfügen. Diese Stufe erhöht die Möglichkeit der Anpassung, da der Schreiben neuer Kompo- Anwender nicht darauf angewiesen ist, dass eine passende Komponente schon existiert. Diese Stufe stellt jedoch einen großen nententypen Schritt hinsichtlich der Qualifikation des Anwenders dar, weil sie verlangt, dass er die zu Grunde liegende Programmiersprache beherrscht. Komponenten Das Ändern eines bestehenden Komponententyps stellt deswegen eine eigene Stufe dar, weil die Änderung des Typs sich im typ ändern laufenden System auf alle Instanzen des Typs auswirkt. Tabelle 3-7 Stufen von Techniken bei der komponentenbasierten Anpassbarkeit 30 3.3 Der FLEXIBEAN-Ansatz Der FlexiBean-Ansatz wurde von Stiemerling im Rahmen seiner Dissertation entwickelt [ Stiemerling (2000)]. Der Ansatz definiert ein Rahmenwerk zur Entwicklung komponentenbasiert-anpassbarer Systeme. Die einzelnen Bestandteile und deren Abhängigkeiten sind in Abbildung 3-5 zu sehen. 1 FlexiBeanKomponentenmodell 2 D/CAT KomponentenbeschreibungsSprache 3 4 EvolvePlattform Legende: Spezifikation Tailoring API Produkt Anpassungsumgebung abhängig von Abbildung 3-5 Übersicht über die Bestandteile des FlexiBean-Systems Alle Teile zusammen bezeichne ich als das FlexiBean-System. Es erfüllt dabei die Bedingungen von der Definition über die komponentenbasierte Anpassbarkeit (Seite 28) denn: 1. Das Komponenten-Modell besteht aus dem FlexiBean Komponenten-Modell, das eine Erweiterung des JavaBean Modells ist. 2. Als Kompositionsbeschreibungssprache (CDL) steht CAT28 bzw. DCAT zur Verfügung. Mit ihrer Hilfe können Komponentenhierarchien und verteilte Anwendungen beschrieben werden. 3. Die durch die CDL beschriebene Komposition kann auf der EVOLVE-Plattform29 ausgeführt werden. Die EVOLVE-Plattform bildet die Komposition auf Komponenteninstanzen ab. Falls diese noch nicht existieren, werden sie durch die EVOLVE-Plattform erzeugt. 28 29 CAT ist in Stiemerling (1997b) spezifiziert. Die EVOLVE-Plattform wurde von Hinken (1999) implementiert. ALLGEMEINE GRUNDLAGEN 31 4. Die Plattform stellt eine Tailoring-API zur Laufzeitanpassung zur Verfügung. Über sie kann eine Anpassungsumgebung auf die Komposition zugreifen und verändern30. Nachfolgend wird zunächst das JavaBean Modell dargestellt, anschließend wird auf die einzelnen Teile des FlexiBean-Ansatzes eingegangen. 3.3.1 JavaBeans „The goal of the JavaBeans APIs is to define a software component model for Java, so that third party ISVs can create and ship Java components that can be composed together into application by end users.“ Sun Microsystems (1997, S. 7) Die JavaBeans sind von Sun Microsystems (1997) spezifiziert. Dort werden sie als eine wiederverwendbare Softwarekomponente definiert, die in einer Entwicklungsumgebung graphisch manipuliert werden kann [Sun Microsystems (1997, S. 9)]. Die Spezifikation besagt, dass jede Java-Klasse als Komponente ausgezeichnet werden kann. Sie muss nicht, wie z.B. eine Enterprise JavaBean, von einer bestimmten Klasse abgeleitet sein oder ein bestimmtes Interface implementieren. Durch die Gleichsetzung einer Komponente mit einer Klasse unterscheidet sich das JavaBean-Modell von anderen Modellen wie COM oder CORBA, die das nicht verlangen. Eine „richtige“ Komponente wird eine Java-Klasse aber erst dadurch, dass sie bestimmte Charakteristika aufweist. Die wichtigsten Merkmale einer JavaBean sind Ereignisse (Events), Eigenschaften (Properties) und Methoden. Diese Merkmale werden hauptsächlich durch die Namenskonventionen festgelegt. Hält sich eine JavaBean an diese Konventionen, ist es einer Entwicklungsumgebung mittels Introspektion möglich, die JavaBean zu analysieren und anzupassen. Events werden in Kapitel 6 und 8 der JavaBean Spezifikation beschrieben und stellen eine der Kerneigenschaften der JavaBean Architektur dar. Sie sind der gängigste Mechanismus, um mit Komponenten zu interagieren. Es wird dabei zwischen der Ereignisquelle („Event Source“) und dem Ereignislauscher („Event Listener“) unterschieden. Um eine lose Kopplung zwischen den beiden Komponenten zu erreichen, wird beim Event-Modell eine Variation des in Gamma et al. (1996, S. 257ff.) beschriebenen Observer-Patterns benutzt. Beim Event-Mechanismus spielt die Listener-Schnittstelle das zentrale Element in der Interaktion. Idealerweise ist durch die Spezifikation der Schnittstelle die gesamte Interaktion komplett definiert. 30 Eine 3D-Anpassungsumgebung wurde von Hallenberger (2000) implementiert. 32 Der Event-Mechanismus soll anhand von Abbildung 3-6 erläutert werden. Damit die Quelle JButton, ihre Abnehmer, z.B. MyButtonListener, nicht kennen muss, wird eine eigene Schnittstelle, ActionListener, eingeführt. Der Interessent MyButtonListener muss diese Schnittstelle implementieren, wenn er an den Ereignissen interessiert ist. JButton besitzt die Methode addActionListener, um ActionListeners bei ihm anzumelden bzw. removeActionListener um sie wieder abzumelden. Allgemein ist die Namenskonvention für das An- und Abmelden: void add<listener interface name>(<listener interface name> 1) void remove<listener interface name>(<listener interface name> 1) Falls ein Ereignis auftritt, informiert die Quelle die angemeldeten Abnehmer, indem sie die geeignete Methode der Listener-Schnittstelle aufruft. Wenn z.B. der Button von einem Benutzer gedrückt wird, ruft der JButton die actionPerformed Methode des Listener auf. «interface» java.util.EventListener java.util.Event +getSource() ActionEvent 0..* 0..* «interface» ActionListener +actionPerformed() JButton +addActionListener() +removeActionListener() MyButtonListener Abbildung 3-6 UML-Klassendiagramm, das das JavaBean Event-Modell zeigt Die Spezifikation schreibt vor, dass die Listener-Schnittstelle die Schnittstelle java.ut31 il.EventListener erweitern muss, und per Konvention mit dem Namen Listener endet. Der Marker dient dazu, eine Komponente als Event-Quelle und -Ziel zu identifizieren. Das Ziel wird darüber identifiziert, dass es die durch den Marker gekennzeichnete Listener-Schnittstelle implementiert. Die Quelle kann durch die Namenskonvention erkannt werden. Dieser Mechanismus hat zur Folge, dass eine Komponente für jeden Listener-Typ nur einen Interaktions-Port anbieten kann. Die Listener-Schnittstelle soll aus einer Menge von Ereignisbehandlungsmethoden bestehen, die dem „Standardmuster“ entsprechen sollen. Die Konvention besagt, dass die Signatur folgendem Muster entspricht: void <eventOccurenceMethodName> (<EventStateObjectType> evt). Die Informationen, die bei einer Benachrichtigung mitgeliefert werden, sind im Zustand des Ereignisobjekts evt zu kapseln. Die Konvention besagt, dass die Eventklasse von java.util.EventObject abgeleitet sein soll und mit 31 java.util.EventListener ist eine so genannte Marker-Schnittstelle, weil sie keine Methoden besitzt. ALLGEMEINE GRUNDLAGEN 33 dem Namen Event endet. Der Abnehmer kennt über die im java.util.EventObject deklarierte Methode getSource() indirekt die Quelle. Die Spezifikation verzichtet weitgehend darauf, die Semantik der Interaktion festzulegen. Im allgemeinen ist die Kommunikation aber multicasted, d.h. dass ein Ereignis an mehrere Abnehmer geschickt wird. Jedoch ist die Reihenfolge nicht festgelegt, in der die Listeners aufgerufen werden. Daneben müssen bei ereignis-basierter Kommunikation noch andere Schwierigkeiten beachtet werden, wie zum Beispiel das in Abschnitt 7.2.3 diskutierte ReEntrant Problem. In Kapitel 7 und 8 der JavaBean-Spezifikation werden Properties beschrieben. Sie sind diskrete, benannte Attribute einer JavaBean, die das Verhalten und/oder das Aussehen beeinflussen können. Es gibt einfache, boolsche und indexierte Properties. Sie werden durch getter und setter Methoden von außen zugänglich gemacht. Einfache Properties gehorchen dabei folgendem Muster: void set<PropertyName>(<PropertyType> value) // void setFoo(Wombat w) <PropertyType> get<PropertyName>() // Wombat getFoo() Über Methoden schweigt sich die Spezifikation weitgehend aus. Sie geht davon aus, dass in einer Komponentenumgebung alle öffentlichen Methoden einer JavaBean als äußere Methoden angezeigt werden. Sie sind damit anderen Komponenten oder Scriptsprachen zugänglich. Alle zu einer Komponente zugehörigen Klassen werden zu einem so genannten jarArchiv32 zusammengebunden. Im Archiv wird auch vermerkt, welche Klasse eine Komponente bzw. nur eine Hilfsklasse darstellt. Hält sich eine JavaBean an die oben beschriebenen Konventionen und Muster, so können ihre Properties, Methoden und Ereignisdienste generisch ermittelt werden. Dies geschieht mit Hilfe der Metaprogrammiereigenschaften von Java, die durch die Reflection API zur Verfügung stehen. 3.3.2 Erweiterungen durch das FlexiBean-Modell Anhand einer Fallstudie zeigt Stiemerling (2000, S. 72 ff.) einige Unzulänglichkeiten des JavaBean Modells auf. Zu den Kritikpunkten zählen: 1. dass verteilte Komponenten nicht unterstützt werden, 2. das Fehlen benannter Ports und 3. das Fehlen anderer Interaktionsformen neben dem Ereignismechanismus. Die in Stiemerling (1998) spezifizierte FlexiBeans erweitern die JavaBeans, um diese Schwachstellen zu beheben. 32 Jar-Archive sind komprimierte Dateien. 34 Der erste Kritikpunkt bekommt durch neue Anforderungen an moderne Anwendungssysteme, insbesondere im CSCW-Bereich, eine immer größere Bedeutung. Da die Systeme meistens parallel auf verschiedenen Rechnern laufen, ist es wichtig, dass Komponenten über Rechnergrenzen hinweg interagieren können. In einem Komponentenmodell sollte deshalb die Remote-Fähigkeit explizit enthalten sein. FlexiBeans verbinden deshalb Javas RMI mit dem JavaBean Modell. RMI steht für „Remote Method Invocation“ und ist Javas Standardtechnologie für den Methodenaufruf bei verteilten Objekten. Das Prinzip von RMI beruht darauf, dass auf der Client- und auf der Serverseite Proxies eingeführt werden, die den Remote-Zugriff kapseln. Der clientseitige Proxy wird als Stub, der serverseitige als Skeleton bezeichnet. Sie werden mit Hilfe eines speziellen Compilers erzeugt. Die Serverklasse muss die Methoden, die der Client sehen soll, in einer Schnittstelle deklarieren, die das Interface java.rmi.Remote erweitert. Tritt beim Zugriff auf den fremden Rechner ein Fehler auf, zeigt die aufgerufene Methode dies durch eine java.rmi.RemoteException an. Die Serverklasse selber muss von java.rmi.server.UnicastRemoteObject abgeleitet sein. Das FLEXIBEANModell wird nun so umgewandelt, dass die Objekte remote-fähig sind, die durch die Ports einer Komponente angeboten werden. Die Remote-Fähigkeit schlägt sich in den nachfolgend beschriebenen Konventionen wieder. Der zweite Punkt kritisiert, dass beim JavaBean Modell die Ports einer Komponente nicht benannt werden können. Dies hat zur Folge, dass eine Komponente keine zwei Ports mit dem gleichen Ereignistyp und der gleichen Polarität besitzen kann. Soll z.B. der MyButtonListener aus Abbildung 3-6 die Ereignisse zweier Buttons abhören, müssen sie an den gleichen Port angeschlossen werden. Deshalb muss die Komponente vor der Verarbeitung des Ereignisses zuerst die Quelle bestimmen. Ein anderer Ansatz, den Sun Microsystems (1997, S. 35-37) beschreibt, besteht darin, dass die Ziel-Komponente für jede Quelle einen eigenen Adapter vorschaltet, der mit der Komponente zusammenarbeitet33. Der FlexiBean-Ansatz löst das Problem, indem die Namenskonvention so erweitert wird, dass Ports benannt werden. Beim Listener geht man, wie bei der Quelle, dazu über, diesen mittels einer Namenskonvention zu identifizieren. Die Spezifikation verlangt zusätzlich, dass zwei Ports einer Komponente nicht den gleichen Namen haben dürfen. Dadurch wird das Zusammenstecken der Beans vereinfacht. Der letzte Punkt kritisiert, dass die JavaBeans nur den Ereignismechanismus als einzige Interaktionsform zwischen den Komponenten kennen. Die hinter dem Ereignismechanismus steckende Idee ist die, dass eine Interaktion nach dem Verteilprinzip abläuft. Hierbei geht, wie in Abbildung 3-7 (a) zu sehen ist, die Aktion von der Komponente aus, die auch die Information bereitstellt. Üblicherweise „feuert“ die 33 Eine Kritik daran findet sich in Szyperski (1998, S. 231) und bei Stiemerling (2000, S. 74) . ALLGEMEINE GRUNDLAGEN 35 Komponente ein Event, wenn ihr Zustand sich ändert. Das Ausstrahlen von Radio und Fernsehsendungen ist ein Beispiel, das nach diesem Prinzip abläuft. Mit dem Ereignismechanismus lassen sich dagegen nur schlecht Interaktionen modellieren, bei denen die Kontrolle nicht bei der Komponente liegt, die auch die Information besitzt. Dies betrifft alle Arten von Abfragen, insbesondere bei Datenbanken. Derartige Interaktionen folgen vielmehr dem Holprinzip. Bei ihm stößt der Abnehmer, wie in Abbildung 3-7 (b) zu sehen ist, beim Anbieter eine Anfrage an und erhält als Resultat die gewünschte Information. Abbildung 3-7 Vergleich der Interaktionsformen nach dem Verteil- und den Holprinzip Um die Interaktion mathematisch untersuchen zu können, benutzt Stiemerling (2000) die Theorie der Datenräume zur Modellierung von Softwarekomponenten34. Innerhalb dieser Theorie modelliert er neben dem Ereignismechanismus eine Reihe anderer Interaktionsmechanismen35. Insbesondere widmet er sich der Interaktion durch gemeinsame Variablen. Eine gemeinsame Variable zeichnet sich dadurch aus, dass sie 1. von mehreren geteilt wird und dass sie 2. keinen Kontrollfluss besitzt. Stiemerling (2000) zeigt in seinem formalen Modell, dass „with a combination of JAVA event and shared variable interaction primitives one can always achieve a high quality implementation of arbitrary decompositions“ [Stiemerling (2000, S. 117)]. Aus dieser Analyse entspringt die Designidee, das Komponentenmodell um gemeinsame Variablen zu erweitern. Deshalb besitzen die FlexiBeans so genannte SharedObjects als eine weitere Interaktionsform. SharedObjects sind die objektorientierte Realisierung von gemeinsamen Variablen und kapseln beliebige Daten, auf die alle bei der Interaktion beteiligten Komponenten zugreifen können. Dabei werden die Zugriffsmethoden auf das SharedObjects in einer Schnittstelle deklariert, die vom SharedObject implementiert wird. Da der Zugriff auf den Zustand eines SharedObject über seine Methoden gekapselt ist, hat das zur Konsequenz, dass der Kontrollfluss nur in der Theorie nicht an das SharedObject übergeben wird36. SharedObjects bieten, wie Abbildung 3-8 zeigt, eine symmetrische Interaktionsform an, bei der keine der beteiligten Komponenten ausgezeichnet ist. Im FlexiBean-Modell sind die SharedObjects jedoch keine eigenständigen Einheiten, sondern werden einer Komponente zugeordnet, die für die Erzeugung des SharedObjects verantwortlich ist. Diese ausgezeichnete Komponente wird der Provider des SharedObjects genannt. Die 34 Die Theorie der Datenräume ist in Cremers und Hibbard (1978) beschrieben. Vgl. Stiemerling (2000, S. 88). 36 Auf diesen Umstand wird noch mal genauer in Abschnitt 7.2.3 eingegangen. 35 36 Spezifikation lässt es offen, ob das SharedObject durch ein eigenständiges Objekt oder durch den Provider selbst implementiert wird. Der Provider stellt eine Methode zur Verfügung, über die die anderen Komponenten auf das SharedObject zugreifen können. Wie beim Eventmechanismus werden die Provider- und die Benutzer-Komponente über eine Namenskonvention identifiziert. Abbildung 3-8: Objektorientierte Realisation von gemeinsamen Variablen als weitere Interaktionsform bei FlexiBeans in UML-Notation [Stiemerling (2000, S. 117)] 3.3.3 Component Architecture for Tailorability (CAT) CAT ist eine Komponenten-Beschreibungssprache und wird benutzt, um Anwendungen zu spezifizieren bzw. zu speichern. CAT ist ein Derivat von DARWIN und wurde für lokale Anwendungen entworfen. Später wurde die Sprache DCAT entworfen, um mit ihr verteilte Komponenten zu beschreiben. CAT besitzt zum einen textliche Darstellung, zum anderen hat die Sprache auch eine graphische Visualisierung. Die Grammatik von CAT ist in Stiemerling (1997b) spezifiziert. 3.3.3.1 Atomare Komponenten Eine Java-Klasse, die den oben genannten Konventionen folgt, definiert einen atomaren Komponententyp. Sie ist ausgezeichnet durch ihre Parameter und ihre Ports. Die Ports repräsentieren die Dienste, die die Komponente anbietet bzw. benötigt. Die Ports werden in vier Kategorien aufgeteilt. Man unterscheidet nach der Polung des Dienstes (anbieten/benötigen) und dem Interaktionsmechanismus (SharedObjects/Events). In der vorliegenden Arbeit wird folgende graphische Darstellung für eine Komponente verwendet: Die Komponente wird durch ein geteiltes Rechteck dargestellt, in der im oberen Teil der Typname steht und im unteren Teil die Parameter aufgelistet sind, mit der die Komponente konfiguriert werden kann. Die Beschriftung der Parameter ist <Name> :: <Typ>37. Bei einer Komponenteninstanz steht im oberen Teil neben dem Typ noch der Name. Zusätzlich kann bei einer Instanz den einzelnen Parametern ein Wert zugewiesen werden. Die Ports werden als „Beinchen“ am Rand der Komponente dargestellt. Die Farbe 37 Ist der Typ oder der Name ersichtlich bzw. nicht von Belang, lasse ich diesen weg. ALLGEMEINE GRUNDLAGEN 37 und Form des Beinchens wird durch die Kategorie des Ports bestimmt: SharedObject-Ports sind rechteckig, Event-Ports rund. Wird ein Dienst angeboten, so ist das Beinchen schwarz, anderenfalls weiß gefüllt. Die Beschriftung der Ports ist wie folgt: <Portname> :: <Typ>. Die in Abbildung 3-9 dargestellte atomare Komponente zeigt die vier Fälle. class AtomareBean { void setName(String name){…} SO getSharedSO_Provider(){…} void setSharedSO_Client(SO so){…} IN :: IPostfach void forgetSharedSO_Client() {…} AtomareBean Prov ider:: SO Client :: SO name :: String Ev entSource :: EListener Ev entHandler:: EListener void addEListener_EventSource (EListener el) {…} void removeEListener_EventSource (EListener el) {…} EListener getEListener_EventHandler () {…} } Abbildung 3-9 Atomarer Komponententyp einmal in CAT graphisch dargestellt (links) und einmal als Javaklasse (rechts) Die Ports in CAT entsprechen den Ports bei ACME, wobei die Ports in CAT nur einfache Interfaces repräsentieren können. Jedoch kennen die FlexiBeans keine Verbindungen als eigenständige Einheiten und sie kennen auch keine Rollen. Die Interaktionsmechanismen der FlexiBeans ließen sich aber in ACME durch einen Architekturstil definieren. ACME kennt auch keine Parameter, sie lassen sich aber mit ACME-Properties beschreiben. 3.3.3.2 Zusammengesetzte Komponenten Mittels CAT können aus den bestehenden Komponenten neue definiert werden. Diese stehen dann weiteren Definitionen zur Verfügung. Ein abstrakter Komponententyp besteht wie der atomare Komponententyp aus einem Namen und einer Menge von Parametern und Ports. Sie legen fest, was von der Komponente nach außen sichtbar ist. Ein abstrakter Komponententyp stellt also das dar, was in ACME ein Subsystem heißt. Die Außenansicht ist dabei die Repräsentation des Subsystems. CAT kennt jedoch immer nur eine Repräsentation pro Subsystem. Intern besteht die abstrakte Komponente aus einer Menge von Instanzen bereits definierter Komponenten, einer Menge von Verbindungen und einer Menge von Parameterbelegungen. Eine Instanz besteht aus einem Namen, dem Komponententyp und einer Belegung der Parameter mit Werten. Die Namen der Instanzen sind eineindeutig. Bei 38 den Verbindungen unterscheidet man zwischen internen und externen38. Interne Verbindungen verknüpfen die Ports gleichen Typs und unterschiedlicher Polarität zweier Instanzen. Eine externe Verbindung verknüpft einen Parameter der abstrakten Komponente mit einem Parameter einer Instanz oder einen Port der abstrakten Komponente mit einem Port einer Instanz. Die Parameter müssen gleichen Typs sein, und die Ports müssen den gleichen Typ und die gleiche Polarität haben. Die Parameterbelegung weist einem Parameter einer Instanz einen Wert zu. Ein belegter Parameter einer Instanz ist gebunden und darf nicht exportiert werden. Ein Beispiel eines abstrakten Komponententyps ist in Abbildung 3-10 zu sehen. Der obere Teil (weiß dargestellt) des BandBassFilters zeigt die externe Sichtbarkeit. Der untere Teil (grau dargestellt) zeigt, wie das externe Verhalten auf die zwei Subkomponenteninstanzen filter1 und filter2 abgebildet wird. Die abstrakten Komponententypen und ihre Subkomponenten definieren einen rekursiv gebildeten azyklischen Graphen. Abbildung 3-10 Graphische Darstellung eines abstrakten Komponententyps Im Gegensatz zu ACME kennt CAT neben den Sprachkonstrukten für die Strukturelemente keine weiteren. Es besteht damit weder die Möglichkeit z.B. mittels Properties Teile der Architektur zu kommentieren, noch können benutzerdefinierte (Tailoring-) Constraints in die Architekturbeschreibung mit aufgenommen werden. 3.3.4 EVOLVE-Plattform und verteilte Anwendungen mittels DCAT Beim FlexiBean-Ansatz ist es möglich, mittels DCAT, verteilte Anwendungen zu spezifizieren. Eine Anwendung ist dabei eine ausgezeichnete Komponente, die als Systemkomponente bezeichnet wird. Sie ist ein abstrakter Komponententyp, der keine Ports exportiert. Zusätzlich wird in DCAT den Subkomponenten einer Systemkomponente ein Ausführungsort zugewiesen. 38 Analog zum ACME, bei dem zwischen der Rep-Map und dem Subsystem unterschieden wird. Externe Verbindungen gehören dabei der Rep-Map – interne gehören dem Subsystem an. ALLGEMEINE GRUNDLAGEN 39 Um die Funktionsweise besser zu verstehen, ist es sinnvoll, die Client-Server Architektur der Evolve-Plattform zu betrachten (vgl. Abbildung 3-11). Auf dem Evolve-Server sind alle Programmdaten einer Applikation abgelegt. Diese bestehen aus den jar-Archiven, die die Implementierung der atomaren Komponenten beinhalten, den CAT-Dateien, die die atomaren und abstrakten Komponenten beschreiben und den DCAT-Dateien, die die Systemkomponenten und die Verteilung der Subkomponenten spezifizieren. Das Starten einer Applikation wird von einem Evolve-Client angestoßen, indem er dem Server eine Nachricht sendet, eine DCAT-Systemkomponente zu laden. Beim Starten legt der Server fest, welche Komponente wo erzeugt wird bzw. auf welche schon erzeugten Komponenten referenziert werden soll. Abbildung 3-11 Client-Server Architektur der Evolve-Plattform Das Festlegen des Ausführungsortes geschieht durch die Angabe eines der Schlüsselworte SERVER, LOCAL und USER nach der Deklaration der Subkomponente (vgl. Abbildung 3-12). SERVER meint dabei den Evolve-Server, LOCAL meint den Evolve-Client, von dem aus die Ausführung veranlasst wurde. Beim USER muss man noch den Namen des Benutzers mitangeben. Jeder Client ist einem Benutzer zugeordnet. Existiert der Client des angegebenen Benutzers zur Zeit der Erzeugung nicht, führt dies zu einer Fehlermeldung. s_component BandPassFilter { subcomponent in Cd LOCAL; subcomponent out Headphone LOCAL; subcomponent filter BandPassFilter SERVER { lowerBorderFreq := 10; }; bind filter.in -> in.out; bind filter.out -> out.out; } Abbildung 3-12 Textliche und graphische Darstellung einer DCAT- Systemkomponente 3.3.5 Tailoring API und Anpassungsumgebung Durch die, von der Evolve-Plattform bereitgestellte Tailoring-API kann man zur Laufzeit auf die Komponenteninstanzen und auf die gesamte Kompositionsstruktur zugreifen. Sie 40 legt die von der Evolve-Plattform geleistete Abbildung von einer Kompositionsbeschreibung auf java-Objekte offen. So kann auf die Instanzen, die die Systemkomponenten darstellen, über das IR_DistComponent Interface zugegriffen werden. Die Instanzen, die die lokalen abstrakten und atomaren Komponenten repräsentieren, implementieren das IR_Component-Interface. Der Evolve-Server selbst ist eine Instanz der Klasse Server. Um auf die Systemkomponenten zuzugreifen, stellt die Server-Klasse zwei Methoden zur Verfügung, die ein IR_DistComponent zurückgeben. Das IR_DistComponent- und das IR_Component-Interface besitzen Methoden, um die Subkomponenten und die Verdrahtung zu ermitteln. Das IR_Component besitzt zusätzlich noch Methoden für die Eruierung der Parameter. Mittels dieser Funktionalität ist es der Anpassungsumgebung möglich, die Komponentenstruktur zu ermitteln. Abbildung 3-13 zeigt z.B. eine 3D-Visualisierung einer so ermittelten Komponentenstruktur. Abbildung 3-13 3D-Ansicht der Komponenten einer verteilten Anwendung [Hallenberger (2000)] Neben der Funktionalität zur Ermittelung der Struktur besitzen die genannten Interfaces auch Methoden, diese Struktur zu verändern, bzw. neue (Sub-)Komponenten anzulegen bzw. zu löschen [vgl. Hinken (1999, S. 75 ff.)]. ALLGEMEINE GRUNDLAGEN 41 3.4 Der WAM-Ansatz Der WAM-Ansatz wurde in den 90er Jahren im Arbeitsbereich Softwaretechnik an der Universität Hamburg entwickelt [Budde und Züllighoven (1990), Züllighoven (1992), Kilberth, Gryzan und Züllighoven (1994), Züllighoven (1998)]. Er verkörpert einen Methodenrahmen für eine objektorientierte und evolutionäre Herangehensweise bei der Softwareentwicklung, der stark von der Idee des gegenseitigen Lernens von Anwender und Entwickler geprägt ist39. Er basiert dabei auf der Verwendung allgemein verständlicher Metaphern bei Entwurf, Konstruktion und Einsatz interaktiver Anwendungssysteme. Er integriert verschiedene Konstruktionstechniken aus dem Bereich der objektorientierten Programmierung. Züllighoven umreißt in einer Kurzdarstellung den Ansatz wie folgt: „Die zentrale Idee des Werkzeug & Material-Ansatz ist, die Gegenstände und Konzepte des Anwendungsbereiches als Grundlage des softwaretechnischen Modells zu nehmen. Das Ergebnis soll eine enge Korrespondenz zwischen dem anwendungsfachlichen Begriffsgebäude und der Softwarearchitektur sein. Diese Strukturähnlichkeit hat zwei entscheidende Vorteile: Die Anwender finden die Gegenstände ihrer Arbeit und die Begriffe ihrer Fachsprache im Anwendungssystem repräsentiert. Sie können entsprechend ihre Arbeit in gewohnter Weise organisieren. Die Entwickler können Softwarekomponenten und Anwendungskonzepte bei fachlichen und softwaretechnischen Änderungen zueinander in Beziehung setzen und somit wechselseitige Abhängigkeiten erkennen.“ Züllighoven (1998, S. 5) Diese proklamierte Strukturähnlichkeit zwischen der Begriffswelt und der Softwarearchitektur, die auch bei Henderson und Kyng (1991) gefordert wird, macht den WAMAnsatz so interessant für die komponentenbasierte Anpassbarkeit. Die Hinwendung zum Anwender steckt auch in der Forderung nach kontext-spezifischer Anpassbarkeit (vgl. Abschnitt 3.1.3.2). Das Ziel, das mit der Strukturähnlichkeit verfolgt wird, besteht darin, dem Anwender einen intuitiven Zugang zur Softwarearchitektur zu ermöglichen, damit dieser das System einfacher an seine Bedürfnisse anpassen kann. Bei der Modellierung der Software stützt man sich dabei auf die vorhandenen Arbeitszusammenhänge. Um diese verstehen zu können, hat es sich nach Wulf, M. (1995, S. 13) als tragfähig erwiesen, die Arbeitsgegenstände, die zur Erledigung alltäglicher Aufgaben im Anwendungsbereich verwendet werden, und die Arbeitsmittel, mit denen diese 39 Zur Idee des gegenseitigen Lernens und deren Einbettung in das Software-Engineering vergleiche Floyd (1994). In diesen Punkt zeigt sich auch eine Wahlverwandtschaft zwischen dem WAM-Ansatz und der Auffassung von der Anpassbarkeit als Kooperation zwischen Anwender und Entwickler, wie sie von Mørch und Mehandjiev (2000) vertreten wird. 42 Gegenstände bearbeitet werden, zu analysieren. Bei dieser Analyse wird bewusst eine bestimmte Perspektive eingenommen, die sich auch in dem gewählten Leitbild des „Arbeitsplatz[es] für qualifizierte und eigenverantwortliche Tätigkeiten“ [Züllighoven (1998, S. 5)] äußert. Die eingenommene Perspektive kann man auch als Werkstatt-Perspektive bezeichnen. Aus ihr heraus wurde eine Reihe von Entwurfsmetaphern entwickelt, die als Hilfsmittel dienen, um den Arbeitskontext zu analysieren und zu kategorisieren. Die wichtigsten Metaphern sind die des Werkzeugs, des Materials, des Automats und der Arbeitsumgebung. Die Gestaltung orientiert sich nun an dem „fachlichen motivierten Umgang mit solchen Arbeitsmitteln und –gegenständen und modelliert rechnergestützt Arbeitsumgebungen durch die sinnvolle Zusammenstellung von (Software-)Werkzeugen und (Software)Materialien.“ [Wulf, M. (1995, S. 12)]. Die Analyse mündet in so genannten Konzeptionsmustern, die die für einen Anwender sichtbaren Elemente des Anwendungssystems beschreiben. Sie setzen dort an, wo mit Hilfe der Entwurfsmetaphern die relevanten Gegenstände des Anwendungsfelds identifiziert worden sind. Sie Skizzieren für den Entwickler aus fachlicher Sicht den Entwurf im Großen. Sie bilden deshalb ein Hilfsmittel „an der entscheidenden Nahtstelle zwischen Analyse und Entwurf“ [Züllighoven (1998, S. 163)]. Die Details der technischen Umsetzung einer Entwurfsmetapher werden anhand von Entwurfsmustern beschrieben. Hierbei kommen bekannte Techniken und Muster zum Einsatz, wie sie zum Beispiel bei Gamma et al. (1996) zu finden sind. Ursprünglich bezog sich der WAM-Ansatz auf die Entwicklung von Anwendungssystemen für den einzelnen Arbeitsplatz. Jedoch ist in einigen Arbeiten der Ansatz auch auf den Bereich der kooperativen Arbeit ausgeweitet worden [Wulf, M. (1995), Gryczan (1996), Roock und Wolf (1998)]. Züllighoven (1998) fasst die Arbeiten wie folgt zusammen: „Unsere ersten Erfahrungen in diesem Bereich legen die Schlussfolgerung nahe, dass kooperative Arbeit in ähnlicher Weise durch Arbeitsmittel und -gegenstände unterstützt werden kann, wie wir das für den individuellen Arbeitsplatz gezeigt haben.“ Züllighoven (1998, S. 427-464) Dabei gehen sie von einem Kooperationsmodell aus, das entweder implizit oder explizit die Zusammenarbeit beschreibt und regelt. Eine implizite Kooperation liegt dann vor, wenn ein Benutzer in einer kooperativen Arbeitssituation mit anderen eine Arbeitsumgebung teilt, ohne dass die Kooperation zunächst deutlich wird. Im Gegensatz dazu wird bei der expliziten Kooperation nicht nur die gemeinsame Nutzung von ALLGEMEINE GRUNDLAGEN 43 Ressourcen ermöglicht, sondern die Kooperation wird selbst vergegenständlicht. Entscheidend dabei ist, dass jede Kooperation erst durch ein gegenständliches Kooperationsmittel bzw. -medium möglich ist. Unter einem Kooperationsmittel wird dabei ein fachlich motivierter Gegenstand verstanden, der die Kooperation unterstützt. Er vergegenständlicht die Kooperation oder die dabei notwendige Koordination. Beispiele für Koordinationsmittel sind Vorgangsmappen und Laufzettel. Ein Kooperationsmedium ist ein fachlicher Gegenstand, mit dessen Hilfe Materialien oder Informationen ausgetauscht werden können. Zudem ist es selbst vergegenständlicht. Beispiele für Kooperationsmedien sind Postversandsysteme, Gruppenpostfächer oder ein Notizbrett. 3.5 Grundlagen der Zugriffskontrolle Die Ziele eines Sicherheitssystems sind Vertraulichkeit, Integrität und Verfügbarkeit, die durch Authentifikation, Autorisierung und Zugriffskontrolle erreicht werden sollen. In einer Anwendung, die über offene Netze, wie das Internet, kommuniziert, sind die Punkte Authentifikation und Verschlüsselung besonders wichtig sind. Im Anwendungsfeld lag das größte Konfliktpotential in der Gestaltung der Zugriffskontrolle, weshalb sich die vorliegende Arbeit über Anpassbarkeit auf diesen Aspekt konzentriert. Deswegen wird hier auch nur auf die Zugriffskontrolle eingegangen. Das Thema der Zugriffskontrolle wird in den verschiedenen Teilbereichen der Informatik erforscht. Zu den Bereichen gehören z.B. die Betriebssysteme, die Informationssysteme, der CSCW-Bereich, die Softwareergonomie und nicht zuletzt die Computersicherheit. Im Folgenden werde ich mich hauptsächlich auf Arbeiten aus dem Bereich der CSCWForschung konzentrieren, weil diese zum einen eine stärkere Hinwendung zum Benutzer erkennen lassen. Zum anderen kann man erwarten, dass Zugriffsmodelle aus dem CSCWBereich die Anforderungen, die sich aus der Kooperation ergeben, stärker berücksichtigen. Im Folgenden werde ich vier klassische Zugriffskontroll-Modelle vorstellen. Ihnen besitzen die Gemeinsamkeit, dass sie eine dichotome Aufteilung des Zugriffs in Erlaubt und Verboten besitzen40. Die Darstellung ist weitgehend chronologisch aufgebaut. Man erkennt an den Ansätzen, dass die technische Sichtweise zugunsten einer stärkeren Hinwendung zum Benutzer zurücktritt. Die Modelle werden in Abschnitt 3.5.5 miteinander verglichen. 40 In Stiemerling, Won und Wulf (2000) ist eine Erweiterung des Modells von Stiemerling beschrieben, die das Modell um nicht-klassische Kontroll-Mechanismen ergänzt. Die Erweiterung stützt sich auf Wulfs Ansatz zum Konfliktmanagement. Da dieser in Abschnitt 5.3 vorgestellt wird, werde ich auf die Erweiterungen des Modells von Stiemerling nicht eingehen. 44 Um die Modelle besser miteinander vergleichen zu können, habe ich das Modell von Shen und Dewan und das Modell von Sikkel mittels Graphen dargestellt. Die Regelbasiertheit des Modells von Stiemerling ließ jedoch eine Darstellung mittels Graphen nicht zu. Bei der mathematischen Formulierung des Modells von Shen und Dewan steht man aber vor dem Problem, dass einige Teile des Modells bei Shen und Dewan nur angedeutet, aber nicht ausgeführt werden41. 3.5.1 Zugriffsmatrix Modell nach Lampson (1974) Ein sehr einfaches und weit verbreitetes Zugriffskontroll-Modell geht auf Lampson (1974) zurück. Das Modell besteht aus drei Hauptkomponenten: 1. eine Menge von Objekten o, 2. eine Menge von Subjekten s und 3. eine Zugriffsmatrix oder Zugriffsfunktion A. Die Objekte sind Dinge des Systems, die geschützt werden sollen. Typische Objekte eines bestehenden Systems sind Prozesse, Dateien, Segmente und Terminals. Objekte haben einen globalen Identifizierer, z.B. eine 64-bit Integerzahl. Subjekte sind Dinge, die einen Zugriff auf ein Objekt haben, z.B. einen Benutzer oder einen Prozess. Was genau unter einem Objekt bzw. einem Subjekt zu verstehen ist, hängt von der Sicherheitsanforderung der Anwendung ab. Jeder Eintrag der Zugriffsmatrix besteht aus einer Menge von Strings, die Zugriffsattribute genannt werden. Typische Attribute sind ‚lesen’, und ‚schreiben’. Die Semantik des Modells ist durch die Zugriffsmatrix A festgelegt. Man sagt, ein Subjekt s hat einen ‚z’-Zugriff auf ein Objekt o, falls z ein Element von A[s,o] ist. Abbildung 3-14 zeigt das Beispiel einer Zugriffsmatrix. John File 1 Own R W Alice R Bob R W File 2 Own R W R File 3 Own R W File 4 W W Own R W Abbildung 3-14 Beispiel einer Zugriffsmatrix In großen Systemen wird die Zugriffsmatrix ziemlich groß und ist dünn besetzt. Deshalb wird die Matrix meist nicht als ein zwei-dimensionales Array gespeichert. Sandhu und Samarati (1994) beschreiben die Access Control Lists (ACLs), die Capabilities und die Authorization Relations als verschiedene Implementierungsansätze des Modells. 41 Das hier angegebene Modell ist daher eine mögliche Interpretation, andere Interpretationen sind möglich. So heißt es zum Beispiel zur Semantik des Zugriffs: „[…] access is granted only if F(s,o,r,A) evaluates to true“. Es fehlt jedoch eine Vorschrift, die angibt, wie F den Wahrheitswert berechnet. ALLGEMEINE GRUNDLAGEN 45 3.5.2 Das Zugriffsmodell von Shen und Dewan (1992) Die Arbeit von Shen und Dewan (1992) setzt sich mit den Zugriffskontroll-Modellen für kooperative Systeme auseinander. Sie bemängeln, dass die meisten kooperativen Systeme jedem alles zugänglich machen und die Systemhersteller davon ausgehen, dass allein die soziale Kontrolle durch die Akteure ausreicht. Den Grund dafür sehen sie darin, dass es für den CSCW-Bereich kein generisches Zugriffskontroll-Modell gibt. Sie stellen einige Anforderungen für ein solches generisches Modell für CSCW-Systeme auf, die sie zu sechs Punkten zusammenfassen, die in Tabelle 3-8 aufgelistet sind. Die generischen Modelle aus anderen Bereichen können nicht einfach so übernommen werden, weil sie den aufgelisteten Anforderungen nicht gerecht werden. Insbesondere kritisieren sie das Zugriffsmatrix-Modell, da es keine mehrfachen Rollen gibt und das Festlegen der Zugriffsrechte sich nicht einfach gestaltet. Anforderung Erklärung Mehrfache, dynamische Benutzerrollen Das Modell sollte es erlauben, die Zugriffsrechte des Benutzers aus seiner Rolle abzuleiten. Es sollte dem Benutzer auch erlaubt sein, mehrere Rollen gleichzeitig inne zu haben und diese Rollen dynamisch zwischen verschiedenen Phasen der Kooperation zu ändern. Kooperationsrechte Neben traditionellen Operationen wie ‚lesen’ und ‚schreiben’, sollten alle anderen Operationen, wie z.B. ‚kopieren’, die mehrere Benutzer betreffen könnten, durch Kooperationsrechte geschützt werden. Flexibilität Das System sollte fein granulierte Subjekte, Objekte und Zugriffsrechte unterstützen. Es sollte möglich sein, die Rechte dezidiert für jeden einzelnen Benutzer für ein einzelnes Objekt festzulegen. Zum Beispiel sollte es erlauben, Zugriffsrechte für jede einzelne Zeile in einem Mehrbenutzer-Programmeditor festzulegen. Einfache Handhabung Benutzer sollten die Rechte auf einfache Weise festlegen können. 46 Effizientes Speichern und Auswerten Die Zugriffsdefinitionen sollten effizient gespeichert und die Zugriffsregeln sollten effizient ausgewertet werden. Automation Das Modell sollte einfach zu implementieren und einfach in ein Mehrbenutzersystem zu integrieren sein. Tabelle 3-8 Anforderung an ein generisches Zugriffsmodell für CSCW-Systeme [nach Shen und Dewan (1992)] Ihr eigenes Modell sehen sie als eine Erweiterung des Zugriffsmatrix-Modells. So gibt es die Möglichkeit, negative Rechte zu spezifizieren. Daneben besitzen die Subjekte, die Objekte und die Operationen verschiedene hierarchische Ordnungen, die es erlauben, diverse Gruppierungen zu bilden und Rechte dafür festzulegen. Aus den Gruppenrechten ergeben sich entsprechende Einzelrechte. Durch die negativen Rechte ist es jedoch möglich, widersprüchliche Rechte zu definieren. Bei dem Modell muss zwischen einem konsistenten und einem konfliktfreien Zustand unterschieden werden. Ein konsistenter Zustand liegt vor, wenn die expliziten Rechte sich nicht widersprechen. Konfliktfrei ist der Zustand, wenn auch die abgeleiteten Rechte sich nicht widersprechen. In dem Modell wird ein konsistenter, aber kein konfliktfreier Zustand verlangt. Stattdessen besitzt das Modell einen Konfliktregelungsmechanismus. Dieser Mechanismus besteht darin, die Regeln, mit denen die Zugriffsrechte aus den Gruppenrechten abgeleitet werden, mit einer Priorität zu versehen. Bei einer solchen Methode besteht die Kunst darin, dass die gewählten Prioritäten dem Common Sense entsprechen. Eine solche Common Sense Regel lautet zum Beispiel, dass spezifische Rechte vor allgemein definierten Rechten gelten. Eine mathematische Formulierung des Modells von Shen und Dewan soll das oben Gesagte präzisieren. Das Modell besteht aus zwei Teilen, dem Schutzzustand P („protection state“) und einer Ableitungsgrammatik F, mit der die implizit gegebenen Rechte evaluiert werden. Der Zustand ist durch das folgende 9-Tupel festgelegt: P = ( S , O, R, A, value _ group, include, imply, take, have) gegeben mit: O, die Menge der Objekte, S, die Menge der Subjekte, R die Menge der Operationen, den explizit definierten Zugriffen A ⊆ S × O × R ×{'− ', '+ '} , value _ group : GO ⊂ O × O azyklischer gerichteter Graph mit Bewertung pO : GO → include : TR ⊂ R × R gerichtete Baumstruktur42, imply : GR ⊂ R × R azyklischer gerichteter Graph mit Bewertung pR : GR → , take : GT ⊂ S × S azyklischer gerichteter Graph mit Bewertung pT : GT → , ✁ ✁ 42 D.h. es gilt: (v , w) und (v, w ') ∈ TR ✂ w = w' , ALLGEMEINE GRUNDLAGEN 47 have : GH ⊂ S × S azyklischer gerichteter Graph mit Rechte-Weitergabefunktion vH : GH →℘( R) und Bewertung pH : GH → . Die Ableitungsgrammatik F(P): S × O × R × {'+ ', '− '} → (S × O × R ×{'+ ', '− '}) ∪ {True, False} ergibt sich aus dem Schutzzustand P und ist durch die folgenden Regeln definiert: 0. Regeltyp (Zugriffstest): ( s, o, r , '+ ') → True für ( s, o, r, '+ ') ∈ A und ( s, o, r , '+ ') → False für ( s, o, r, '− ') ∈ A 1. Regeltyp ( Objekt-Vererbung): ( s, o, r, v ) → ( s, o ', r , v ) für (o, o ') ∈ GO 2. Regeltyp ( Rechte-Vererbung I): ( s, o, r, v ) → ( s, o, r ', v ) für (r , r ') ∈ TR 3. Regeltyp ( Rechte-Vererbung II): ( s, o, r, v ) → ( s, o, r ', v ) für (r , r ') ∈ GR 4. Regeltyp ( Subjekt-Vererbung I): ( s, o, r, v ) → ( s ', o, r , v ) für ( s, s ') ∈ GT 5. Regeltyp ( Subjekt-Vererbung II): ( s, o, r ,'+ ') → ( s ', o, r , '+ ') für ( s, s ') ∈ GH und r ∈ vH (( s, s ')) Man sagt: a) P ist konsistent ist, wenn gilt: ∀(o, s, r ) ∈ O × S × R : (o, s, r , '+ ') ∈ A (o, s, r , '− ') ∉ A , b) F(P) ist konfliktfrei, wenn gilt: ∀(o, s, r ) ∈ O × S × R : (o, s, r , '+ ') →*F ( P ) True ¬ ( (o, s, r , '+ ') →*F ( P ) False ) , c) F(P) ist eindeutig, wenn gilt: ∀H , T , T ':H → T ∈ F ( P) ∧ H → T ' ∈ F ( P) T = T ' . ✁ ✂ ✄ Die Definitionen b und c sind mögliche Erweiterungen des Begriffs der Konsistenz auf die implizit gegebenen Rechte. Definition b besagt, dass jede mögliche Ableitung zum gleichen Ergebnis kommt. Definition c ist eine Verschärfung von b, weil zusätzlich verlangt wird, dass jeder Ableitungsschritt eindeutig festgelegt ist. Es gilt die Implikation: F(P) ist eindeutig => F(P) ist konfliktfrei => P ist konsistent. Beim ZugriffskontrollModell wird nicht verlangt, dass die Grammatik F(P) konfliktfrei ist. Um trotzdem eine wohl definierte Zugriffssemantik für die impliziten Rechte zu erhalten, wird mit Hilfe der Bewertungsfunktion eine eindeutige Ableitung erzwungen. Die Semantik des Zugriffs ergibt sich dann mit Hilfe des unten angegebenen Algorithmus IS_ALLOWED. Für P konsistent gilt: Dem Subjekt s ist ein r-Zugriff auf das Objekt o erlaubt, falls IS_ALLOWED((s,o,r), F(P)) = True. Um eine eindeutige Ableitung mit der Grammatik F(P) zu gewährleisten, werden die Regeln mit einer Priorität versehen. Mit Hilfe der Prioritäten kann im Konfliktfall, wenn mehrere Regeln anwendbar sind, eindeutig eine Regel ausgewählt werden. Für die Sortierung der Regeln gilt zum einen, dass die Regeln des Typs i eine höhere Priorität haben, als die Regeln des Typs j für i < j. Zum anderen kann es bei den Regeltypen 1, 3, 4 und 5 vorkommen, dass ein Konflikt innerhalb des Regeltyps vorkommt. Hier gilt, dass die 48 Regeln durch die entsprechenden Wertungsfunktionen pO , pR , pT bzw. pH geordnet werden. So gilt z.B. für die Objekt-Vererbungsregeln, dass die Regel ( s, o, r , v ) → ( s, o ', r , v ) eine höhere Priorität hat als die Regel ( s, o, r , v) → ( s, o '', r , v) , falls pO (o, o ') < pO (o, o '') gilt. Für die anderen Regeltypen gilt entsprechendes. Für den Regeltyp 2 ist ein Konflikt ausgeschlossen, weil TR eine Baumstruktur ist. Wenn P konsistent ist, dann kann beim Regeltyp 0 kein Konflikt auftreten. Der Algorithmus IS_ALLOWED berechnet aus dem Schutzzustand P und der damit gegebenen Ableitungsgrammatik F(P), ob ein Zugriff erlaubt ist. Der Algorithmus terminiert, weil erstens die Anzahl der Ableitungsregeln endlich ist und zweitens bei jedem Rekursionsaufruf in Zeile 10 in dem azyklischen Graphen nach oben gewandert wird. Für P konsistent ist die Sortierung von L in Zeile 1 wohldefiniert und damit der gesamte Algorithmus. Algorithmus IS_ALLOWED IN: ( s , o, r , v ) ∈ S × O × R × {'+ ', '− '} , F(P) Ableitungsgrammatik RETVAL: z ∈ {True, False, Undef } 1 L := Liste der Regeln in F(P) mit ( s , o, r , v ) als Kopf und nach der Priorität der Regeln sortiert 2 z := Undef 3 If (NOT L.IsEmpty) Then 4 ( s , o, r , v ) → T := L.First 5 z := Undef 6 WHILE z = Undef AND NOT L.IsEnd 7 If( T ∈ {True, False} )Then 8 z :=T 9 Else z : = EVAL(T , F ( P )) 10 11 End If 12 ( s , o, r , v ) → T := L.Next 13 WEND 14 End If Auch wenn das Modell den oben aufgestellten Anforderungen entspricht, gibt es verschiedene Kritikpunkte. Das Modell ist durch die verschiedenen Gruppenhierarchien und Konfliktregelungen ziemlich komplex. So kann die Berechnung eines implizit gegebenen Rechts über mehrere Rekursionsstufen gehen. Auch hängt den Konfliktregelungen eine gewisse Beliebigkeit an. So meinen Shen und Dewan (1992, Abschnitt 5.6) selbst: „It is not currently clear to us which conflict resolution method is the most semantically meaningful. Therefore, we choose the method based on the efficiency considerations”. Eine hypothetische Rechte-Modellierung soll dies verdeutlichen. So sei die Gruppe der studentischen Hilfskräfte von der Gruppe der Studenten und der Gruppe der Mitarbeiter abgeleitet. Dem Mitarbeiter sei der Zugriff auf ein bestimmtes Objekt erlaubt. Verbietet man nun den Zugriff für Studenten, sind je nach Vererbungspriorität die studentischen Hilfskräfte davon betroffen oder auch nicht. ALLGEMEINE GRUNDLAGEN 49 3.5.3 Gruppenbasiertes Zugriffsmodell nach Sikkel (1997) Sikkel (1997) kritisiert am Modell von Shen und Dewan, dass es komplizierter sei, als es sein müsse. Die Konfliktregelungen seien nur deshalb nötig, um Mehrdeutigkeiten aufzulösen, die dadurch entstünden, dass positive wie auch negative Rechte gleichberechtigt behandelt werden. Stattdessen gibt Sikkel den negativen Rechten den Vorzug und führt sie auf einer anderen Ebene in sein Modell ein. Wie beim Matrixmodell gibt es Objekte, Subjekte und Zugriffe, jedoch werden die Subjekte und Zugriffe wie Objekte behandelt. Dafür wird bei den Objekten zwischen eigenständigen und abhängigen Objekten unterschieden. Abhängige Objekte sind einem eigenständigen Objekt zugeordnet, und nur über sie kann auf ein abhängiges Objekt zugegriffen werden. Zugriffsattribute sind ein Beispiel für abhängige Objekte. Die Flexibilität des Modells wird, wie bei Shen und Dewan, dadurch erreicht, dass auf den Objekten eine partielle Ordnung definiert ist. Sie entsteht dadurch, dass aus einer Menge von Objekten eine Gruppe gebildet werden kann, die wieder ein Objekt bildet. Diese Gruppenbildung kann mit den dadurch definierten gerichteten, azyklischen Graphen auf den Objekten identifiziert werden. Die Erlaubnis für einen Zugriff auf ein Objekt ergibt sich dann aus der Mitgliedschaft bei dem durch das Objekt induzierten Teilbaum. Auf der Ebene der Mitgliedschaft werden nun die negativen Rechte eingeführt. Sie erlauben es, beliebige Objekte von der Mitgliedschaft auszuschließen. Eine mathematische Formulierung des Modells sieht nun wie folgt aus: Sei R Menge von eigenständigen Objekten. Für r ∈ R sei Attr(r) die Menge der zugeordneten Objekte43. Es gilt, dass die Attributmengen in R untereinander paarweise disjunkt sind. D.h.: ∀r , s ∈ R : Attr(r ) ∩ R = ∅ ∧ (r ≠ s Attr(r ) ∩ Attr(s ) = ∅) . Sei O := R ∪ r∈R Attr(r ) die Menge aller Objekte Sei G ⊂ O × O × {'+ ', '− '} gerichteter azyklischer beschrifteter Graph. Die Kanten (u , v, '+ ') ∈ G heißen zugehörige Kanten und die Kanten (u , v, '− ') ∈ G heißen ✁ ausschließende Kanten. Die Funktion Members G : O →℘(O) bestimmt die Mitglieder einer Gruppe u ∈ O und ist durch folgende rekursive Vorschrift festgelegt44: 43 Um ein Attribut a eines Objekts r zu bezeichnen, wird auch die Punktnotation r.a verwendet. Die Wohldefiniertheit der Funktion kann durch einen Induktionsbeweis über die Knotentiefe gezeigt werden. 44 50 ✁ Members G {u} (u ):= ✂ ✁ ✄✆☎ ( u ,v ,' + ')∈G für ¬∃ v ∈ O, s ∈{'+ ', '− '}: (u , v, s ) ∈ G Members G (v) − ☎ ( u , w,' − ')∈G Members G ( w) sonst Die Semantik des Zugriffsmodells wird mit Hilfe der Member-Funktion definiert: Man sagt für u , o, r ∈ O , dass u einen r-Zugriff auf o hat, falls a ∈ Attr(u ) und u ∈ MembersG (o.r ) gilt. Diese sehr abstrakte Definition soll anhand eines Beispiels erläutert werden. In Abbildung 3-15 ist links der Zugriffsgraph G zu sehen, d1 soll ein Directory, f1 und f2 zwei Files in diesem Directory darstellen. Tim und john sind zwei User, die der Gruppe project angehören und dessen Rechte erben. Die Rechte-Vererbung findet man bei Objekten nicht in deren Beziehung zueinander, sondern auf Seiten ihrer Attribute. So gibt z.B. f1.r sein Recht an d1.r weiter, der wiederum es an die Operationsgruppierung d1.all weitergibt. Man beachte die umgekehrte Pfeilrichtung gegenüber der Vererbung bei den Subjekten. Die Verknüpfung zwischen Subjekten und Objekten wird auch wieder durch die Attribute vermittelt. Dass ken auf d1 Lesend zugreifen darf, drückt der Pfeil von d1.r nach ken aus. project tim john ken d1 r,w r,w r,w r f1 r,w r,w r,w r f2 r,w r,w r,w r Abbildung 3-15 Zugriffsgraph (links) und resultierende Zugriffs-Matrix (rechts) Die Auswirkung negativer Gruppenmitgliedschaft ist in Abbildung 3-16 darstellt. Um john den Schreibzugriff auf das Directory d1 explizit zu verbieten, ist die negative Kante (d1.w, john, ’-’) in den Graph aufgenommen. Damit er trotzdem noch auf dem File f1 Schreibrechte hat, wurde dieses allgemeine Verbot durch ein spezielleres Gebot mittels der Kante (f1.w, john, ’+’) überschrieben. f1 project r,w r,w tim r john r ken d1 r,w r,w r,w r d2 r,w r,w r r Abbildung 3-16 Zugriffsgraph mit negativer Gruppenzugehörigkeit (links) und resultierende Matrix (rechts) ALLGEMEINE GRUNDLAGEN 51 3.5.4 Regelbasierte Zugriffskontrolle von Stiemerling (1996) Stiemerling (1996) geht einen anderen Weg, um die Komplexität der Zugriffskontrolle bei Groupware-Systemen zu meistern. Das von ihm entwickelte System hat als Ausgangspunkt die Handhabung der Zugriffskontrolle im Anwendungsfeld. Bei der Gestaltung des Zugriffsmodells stützt er sich auf die empirischen Untersuchungen, die er im Rahmen seiner Diplomarbeit durchgeführt hat. Das daraus resultierende System ist den in der Untersuchung gemachten Beobachtungen nachempfunden Die Beobachtungen lassen sich wie folgt zusammenfassen: 1. Die Zugriffskontrollstrategien werden in Form von „WennDann“-Regeln beschrieben. 2. Diese Regeln drücken entweder Verbote oder Genehmigungen aus. 3. Allgemeinere Regeln werden durch das Aufstellen von Ausnahmen verfeinert. Der Bereich, in dem eine Regel angewendet wird, ist durch verschiedene Faktoren bestimmt. Eine Auflistung der einzelnen Faktoren, die in der Untersuchung herausgefunden wurden, findet sich bei Stiemerling (1996, S. 75 ff.). In der technischen Umsetzung wurde versucht die entsprechenden Faktoren im verwendeten Groupware-System zu finden45. Der Kern der Zugriffskontrolle besteht aus einer Reihe von „Wenn-Dann“-Regeln. Diese Zugriffsregeln der Form (v, dv) bilden die Menge R. Die Regel (v, dv) ist zu lesen als „Wenn v gilt, dann dv“, wobei v eine Konjugation von Prädikaten ist und die Form hat: f 1 = v1 ∧ ... ∧ fm = vm mit fi Faktor und vi Wert des Faktors. Ein Beispiel dafür ist: „Benutzerrolle = ‚Buchhalter’ ∧ Dokument = ‚Rechnung B’“. Durch dv wird die Aktion angegeben, die ausgeführt werden soll, wenn die Vorbedingung zutrifft. Es gilt dv ∈{"erlaubt", "verboten"} . Aus dem aktuellen Systemzustand S ergibt sich, welche der Vorbedingungen gültig sind46. Z.B ist für eine Anfrage von einem Subjekt s für einen r-Zugriff auf das Objekt o die obige Vorbedingung genau dann gültig, wenn s die Rolle „Buchhalter“ inne hat und das Objekt das Dokument „Rechnung B“ darstellt. Aus den gültigen Regeln muss eine ausgewählt werden, die dann angewandt wird. Dazu benutzt das System eine Auswertungsstrategie, die weiter unten beschrieben ist. Das System lässt sich damit grob in drei Prozesse einteilen: Ermittlung des aktuellen Systemzustands Sakt, der Ermittlung der gültigen Regeln und der Auswahl einer dieser Regeln (vgl. Abbildung 3-17). 45 Vgl. Stiemerling (1996, S. 95). Zur Notation: Für „v gültig in S“ schreibt man auch S |= v. Der Geltungsbereich einer Vorbedingung v ist durch die Menge G (v ) := {S ∈ Systemzustände : S |= v} gegeben. 46 52 Anfrage (s,o,r) Systemzustand Regelmenge R Auswertungsstategie Ermittlung von Sakt Ermittlung von A = {s R: Sakt |= s} Auswahl und Auwertung einer Regel aus A Aktion d Abbildung 3-17 Aufbau des Zugriffssystems [aus Stiemerling, Won und Wulf (2000)] Zur Analyse der Auswertungsstrategie ist es hilfreich, die verschiedenen Beziehungen zu betrachten, in der zwei Regeln R = (r,dr) und V = (v,dv) zueinander stehen können: i) R und V sind konfliktfrei, falls dr = dv oder G(r) ∩ G(v) = ∅ gilt. ii) R ist eine Spezialisierung von V, falls gilt G(r) ⊆ G(v). iii) R und V stehen für die Situation G(r) ∩ G(v) im Konflikt, falls weder i) noch ii) zutrifft. Für eine Auswertungsstrategie ist Fall i) unproblematisch, weil es keinen Systemzustand gibt, bei der beide Vorbedingungen gültig sind oder die daraus resultierende Aktion ist die Gleiche. Im Fall ii) sollte eine Auswertungsstrategie in einer Situation, in der r und v gültig sind, die speziellere Regel (r,dr) anwenden. Im Fall iii) gibt die Empirie keinen Hinweis darauf, welcher der beiden Regeln im Konfliktfall der Vorzug gegeben werden soll. Bei vorherigen Modellen haben wir zwei Strategien kennengelernt, wie mit diesem Fall umgegangen werden kann. Sikkel löst den Fall so, dass einem Verbot immer der Vorrang eingeräumt wird. Shen und Dewan dagegen arbeiten mit Prioritäten, die teilweise fest vom System vorgegeben und teilweise durch den Benutzer gewählt werden. Das Modell von Stiemerling arbeitet ebenfalls mit Prioritäten, die jedoch vollständig vom Benutzer festgelegt werden können. Des Weiteren hat er das Problem dahingehend vereinfacht, dass nur die Subjekte mehreren Gruppen, d.h. in dem Fall Benutzerrollen, zugeordnet werden können. Mathematisch formuliert bedeutet das, wenn S (⋅) |= f = w und S (⋅) |= f = v gilt, dann ist f der Faktor “Benutzerrolle“ oder w = v. Außerdem wird gefordert, dass der Faktor „Benutzerrolle“ höchstens einmal in einer Regel auftaucht. Wenn mehrere Regeln gültig sind, wird die Regel mit der höchsten Priorität angewendet. Die Priorität ergibt sich aus den beiden unten definierten Funktionen π F und π R , wobei zuerst der Faktor, dann die Rolle ausgewertet wird. Formal lässt sich die Priorität P einer Regel (v, dv) wie folgt definieren: Sei V:= Menge der Vorbedingungen, F:= Menge der Faktoren, mit R:= Menge der Rollen, M := {n ∈ : n < | F |} und N := {n ∈ : n ≤ | R |} . Sei π F : F → M bijektive Abbildung, die die Prioritäten der Faktoren festlegt. ✁ ✂ ALLGEMEINE GRUNDLAGEN 53 Sei π R : R ∪ {∅} → N bijektive Abbildung, mit π R(∅) = 0 , die die Priorität der Rolle festlegt. Sei Faktor: V →℘( F ) die Funktion, die die Menge der benutzten Faktoren zurückgibt und sei Role: V → R ∪ {∅} die Funktion, die die benutzte Rolle zurückgibt und sei p ∈ ein benutzerdefinierbarer Prioritäts-Korrekturfaktor. Dann berechnet sich die Priorität durch folgende Formel: P(v) := ✁ f ∈Faktor ( v ) 2π F ( f ) + π ( Role (v )) R N +1 + p. Definition der Semantik Die Semantik des Modells lässt sich nun wie folgt definieren: Sei R eine Regelmenge, dann ist einem Subjekt s ein r-Zugriff auf das Objekt o beim aktuellen Systemzustand Sakt(s,o,r) erlaubt, wenn es ein (v, "Erlaubt") ∈ R gibt mit Sakt(s,o,r) |= v und P(v) = max { P(w) : Sakt(s,o,r) |= w} 3.5.5 Vergleich der Zugriffskontroll-Modelle Zum Vergleich der Zugriffskontroll-Modelle bietet es sich an, die Terminologie von Stiemerling, Won und Wulf (2000) zu übernehmen. Sie unterscheiden bei einem Zugriffskontrollsystem die Aspekte der Repräsentation, der Präsentation und der Manipulation. Bei der Repräsentation geht es darum, dass das Zugriffsmodell flexibel genug sein sollte, so dass sich darin jede für den Anwendungskontext relevante Zugriffsstrategie ausdrücken lässt. Die Präsentation soll dem Benutzer die aktuelle Zugriffsstrategie zugänglich machen. Und zwar soll die Präsentation so sein, dass 1. er die dem Zugriffskontrollsystem zugrunde liegende, Strategie und die daraus resultierenden Entscheidungen des Systems versteht und 2. er die Unterschiede zwischen der tatsächlichen und der von ihm intendierten Strategie erkennen kann. Die Manipulation sollte so gestaltet sein, dass die Zugriffskontrollstrategie einfach und effizient während der Nutzung des Systems an die Arbeitssituation angepasst werden kann. Das Matrixmodell genügt zwar der Anforderung der Repräsentation, nicht aber der der Präsentation und Manipulation. Denn es ist im Prinzip möglich, jede Strategie zu spezifizieren47, weil jede einzelne Zelle der Matrix dezidiert festgelegt werden kann. Aber auf der Ebene der Manipulation und der Präsentation besitzt das Modell diverse Schwachstellen. Ein Defizit auf der Ebene der Manipulation besteht z.B. darin, dass, wenn ein neues Objekt eingefügt wird, für jedes Subjekt entschieden werden muss, welche 47 Abgesehen von Anforderungen, die sich auf etwas beziehen, was nicht durch die Subjekte, Objekte und die Operationen gegeben ist, wie zum Beispiel: „Zugriffe sind nur werktags erlaubt“. 54 Rechte dies auf dem neuen Objekt besitzen soll. Bei der Präsentation besteht das Problem darin, dass das Modell neben der Zugriffsmatrix keine weiteren Strukturen kennt. So kann das System dem Benutzer keine anderen Informationen präsentieren, als die, dass das Subjekt s auf dem Objekt o die Operation r ausführen darf bzw. nicht ausführen darf. Der Grund für diese Entscheidung, z.B. dass der Benutzer der Gruppe g angehört, geht verloren. Sowohl Modell von Shen und Dewan, als auch das von Sikkel, stellt auf der Ebene der Präsentation und vor allem der Manipulation gegenüber dem Matrixmodell einen Fortschritt dar. Wie oben erwähnt, ist bei Shen und Dewan die Berechnung der implizit gegebenen Rechte kompliziert und nicht immer einsichtig. Um sie nachvollziehen zu können, muss der Benutzer die Vererbungshierarchien der Subjekte, der Objekte und der Rechte gleichzeitig erfassen. Dies macht es für den Benutzer schwierig, die Strategie zu verstehen und zu entscheiden, ob die aktuell spezifizierte Strategie der intendierten entspricht. Sikkels Modell vereinfacht die Präsentation, weil es hier nur eine Hierarchie gibt und das Modell ohne Prioritäten auskommt. Es lässt sich feststellen, dass vor allem das Modell von Lampson und das von Shen und Dewan zu wenig Augenmerk auf die Handhabung durch den Benutzer gelegt haben. Stiemerling, Won und Wulf (2000) plädieren deshalb dafür, die drei Aspekte Repräsentation, Präsentation und Manipulation nicht getrennt voneinander zu betrachten. Die Repräsentation der Zugriffskontrollstrategien soll dabei möglichst dicht an den Formulierungen durchschnittlicher Benutzer und deren Sprache anschließen. Sie gehen davon aus, dass dies zu einem Modell führt, „dessen Benutzerschnittstelle für den Benutzer einfach zu handhaben ist, sowohl was die Präsentation als auch was die Manipulation der aktuellen Strategie angeht“ [Stiemerling, Won und Wulf (2000)]. Das System von Stiemerling ist ein Beispiel, das diesem Ansatz folgt. Durch seine empirische Fundierung kann das Zugriffskontrollsystem auch von EDV-Anwendern mit geringen bis durchschnittlichen Kenntnissen benutzt werden [Stiemerling (1996, S. 113)]. Dies kommt dem Modell gerade auf der Ebene der Präsentation und der Manipulation zu Gute. Auf der Ebene der Manipulation kann der Benutzer auf gleiche Weise, auf die er normalerweise seine Zugriffsstrategie beschreibt, auch den Zugriff festlegen, da das Zugriffskontrollsystem ein adäquates Regelreservoir anbietet. Auf der Ebene der Präsentation kann der Benutzer sich alle zu einem bestimmten Gültigkeitsbereich relevanten Regeln anzeigen lassen. Diese sind nach der Priorität sortiert und im umgangssprachlichen Deutsch beschrieben (vgl. Abbildung 3-18). Regeln, die weiter oben stehen, werden zuerst angewandt. ALLGEMEINE GRUNDLAGEN 55 258_ Für den Besitzer ist Reglementieren, Reglementieren des Inhalts erlaubt. 136_ Für ein Mitglied von Mitarbeiter ist Lesen, Finden des Objekts TEXT C erlaubt. 49__ Für Thorsten Engelskirchen ist Lesen, Finden von April bis Juni am Ort Olivers Schreibtisch erlaubt. 2___ Für den Besitzer ist Lesen, Verändern, Löschen, Verweisen, Verweis löschen, Finden erlaubt. 0___ Für jeden ist das Lesen, Verändern, Löschen, Verweisen, Verweis löschen, Finden Reglementieren, Reglementieren des Inhalts verboten. Abbildung 3-18 Präsentation der Zugriffsregeln bei Stiemerling (1996, S. 105) 3.5.6 Resümee Die Kritik, dass das Zugriffsmatrix-Modell zu unflexibel ist, führte dazu, dass Shen und Dewan ein hoch-flexibles, aber auch ein hoch-komplexes Modell entwickelt haben. Das Modell von Sikkel und das Modell von Stiemerling kann man als einen Versuch ansehen, die Komplexität für den Benutzer handhabbar zu machen ohne die Flexibilität einzuschränken. Der grundlegende Mechanismus, die Dichotomie in „erlaubt“ und „verboten“, wurde aber bei keinem Modell in Frage gestellt oder erweitert. In Kapitel 1 wird für den betrachteten Anwendungskontext gezeigt, dass die dichotome Einteilung die Anforderungen, die an die Kontrolle des Zugriffs gestellt werden, nicht erfüllen kann und deshalb die Zugriffskontrolle um andere Mechanismen zu erweitern ist. 56 57 4 DIE ANALYSE DES ANWENDUNGSFELDS „Der Ablauf vieler [Software-]Projekte stellt sich dar als ein Doppelprozess von technischer Entwicklung und ‚politischer’ Verarbeitung (Interessenaushandlung). Beide Prozesse sind auf vielfältige und meist schwer durchschaubare Weise miteinander verwoben.” Weltz, Lullies und Ortmann R.G. (1991) In diesem Kapitel wird zunächst das Anwendungsfeld für das der Prototyp entwickelt wurde erläutert und in die Diskussion der Virtuellen Organisation eingeordnet. Das Anwendungsfeld zeichnete sich dadurch aus, dass die technische mit der betriebspolitischen Ebene während des gesamten Projekts sehr eng verwoben war. Da die Interdependenzen der beiden Ebenen mit den in der Informatik üblichen Methoden zur Anforderungsanalyse nicht erfasst werden können, wurde das empirische Material einer soziologischen Analyse unterzogen. In Abschnitt 4.3 werden die Resultate der Analyse erläutert. In Abschnitt 4.4 werden die Ergebnisse zusammengefasst und die Konsequenzen für eine zu realisierende Zugriffskontrolle aufgezeigt. 4.1 Einführung in die Fallstudie und ihre Einordnung in die VO-Diskussion Der Prototyp wurde im Rahmen des von der Europäischen Union geförderten OrgTechProjekts48 entwickelt [Iacucci et al. (1998), Nett, Fuchs-Frohnhofen und Wulf (2000)]. Ziel des Projekts war es die zwischen Unternehmen bestehenden kooperativen Arbeitsprozesse zu verbessern. Dabei stand eine Steigerung der Wettbewerbsfähigkeit der klein- und mittelständischen Ingenieurbüros im Fokus des Interesses. Deshalb wurde im OrgTech-Projekt versucht, die kooperativen Arbeitsprozesse zwischen zwei Konstruktionsbüros und einem Stahlwerk zu unterstützen. Das Stahlwerk Bausig49 liegt im Ruhrgebiet und ist mit mehreren tausend Mitarbeitern eines der größten in Deutschland und Teil eines größeren Konzerns. Die beiden Konstruktionsbüros haben ihren Sitz ebenfalls im Ruhrgebiet und haben ungefähr 10 – 20 Mitarbeiter. Die beiden Büros erledigen als Subunternehmer Konstruktions- und Dokumentationsaufträge für Bausig. Das Auslagern von Konstruktionsaufträgen begann mit der gleichzeitigen Verkleinerung der eigenen internen Konstruktionsabteilung Mitte der 80er Jahre. Je nach Auftragslage und Konzernstrategie wird dabei das Auslagern von Konstruktionsaufträgen in unterschiedlichen Umfang betrieben. 48 OrgTech steht für „Organizational and Technical Development in the Context of the Introduction of a Tele-cooperation System in Small and Medium-Sized Engineering Companies“. 49 Der Name wurde zur Anonymisierung geändert. 58 Bei den ausgelagerten Aufträgen handelt sich es um Instandhaltungsmaßnahmen von Anlagen, die sich auf dem Werksgelände des Stahlwerks befinden. Innerhalb des Stahlwerks koordiniert die interne Konstruktionsabteilung die Konstruktion und die Dokumentation. Außerdem ist sie für den Kontakt mit den externen Büros und dem Stahlwerk zuständig. Die Kooperation zwischen den Büros und dem Stahlwerk und der Ablauf einer Auftragsbearbeitung ist schematisch in Abbildung 4-1 dargestellt. Stahlwerk Archiv (4), (7) Suche: Zeichnungen (2) Auftragsprüfung (10) Archiv. Projektdokum. Interne Konstruktion (9) Übergabe Projektdokumentation (6) Anforderung weiterer Zeichn. (5), (8) Übergabe von Zeichn. Externe Ingenieurbüros (3) Auftragsvergabe (11) Übergabe Zeichn. Werkstatt: Instandhaltung (1) Auftragsinitiierung Anlagenbetreiber Abbildung 4-1 Ablaufdiagramm der Auftragsbearbeitung Die Kooperationspraxis soll anhand zweier Zitate illustriert werden. In ihnen wird der Arbeitsablauf aus der Sicht der internen Konstruktion und kontrastiv dazu aus der Sicht der externen Büros geschildert. „Der Ablauf sieht so aus, dass wir zunächst einen Konstruktionsauftrag erhalten.[...] Wir prüfen zunächst das Anliegen der Endkunden formal und inhaltlich. Dann müssen wir Kapazitäten und Kompetenzen für die Konstruktion überprüfen, z.B. einen passenden Fremddienstleister suchen. Die Externen erhalten offiziell erst nach dieser internen Prozedur den Konstruktionsauftrag. Bei Eile wird jedoch direkt hin und her telefoniert und ein mündlicher Auftrag erteilt, so dass sich die formale und die tatsächliche Struktur überschneiden. Offiziell dürfen wir keinen Auftrag erteilen ohne offizielle Genehmigung als Ende des offiziellen Wegs. Aber niemand kann DIE ANALYSE DES ANWENDUNGSFELDS 59 verantworten, dass z.B. die Produktion wochenlang stillsteht. Dazwischen spielt sich die Wahrheit ab.” Mitarbeiter der internen Konstruktionsabteilung50 „In der Kooperation mit Bausig gibt es den formalen und den informalen Ablauf. Formell werden die Aufträge von der zentralen Konstruktionsabteilung an die Büros vergeben. Dazu sollte sich der Anlagenbetreiber nach der Morgenbesprechung an den Instandhalter vor Ort wenden. Dieser dokumentiert den Wunsch und vergibt den Auftrag an den kostengünstigeren. Er ist formal auch für die Überwachung und die Abrechnung des Konstruktionsauftrages verantwortlich. Die Ingenieure erhalten je nach Anzahl der Zeichnungen einen bestimmten, für 3 Jahre ausgehandelten Fixsatz. Insofern ist formal der Auftraggeber von Partner & Lange immer die Konstruktion. De facto werden die Aufträge aber ganz anders vergeben: Die Anlagenbetreiber – als die tatsächlichen Endkunden – wenden sich häufig direkt an die Konstruktionsbüros (telefonisch nach der alltäglichen Morgenbesprechung) und machen Termine aus, um anstehende Aufträge zu besprechen.“ Mitarbeiter der externen Konstruktionsbüros51 Wie in Iacucci et al. (1998) dargelegt, gibt es bei der Kooperation von Bausig und externen Büros einige Punkte, die verbessert werden könnten. So beschweren sich die Büros unter anderem über die unzureichenden Vorgaben bei der Auftragsvergabe. Dies macht zusätzliche Besprechungen notwendig, in denen die Unklarheiten geklärt werden müssen. Außerdem gäbe es Probleme mit den von der internen Konstruktionsabteilung zusammengestellten Zeichnungen. Teilweise fehlten einige und andere stimmten nicht mit dem Zustand der Anlagen überein. Es wurde auch das Fehlen eines einfachen Datenaustauschs zwischen ihnen und dem Stahlwerk bemängelt. Aus einem Protokoll eines anfänglichen Arbeitstreffens des OrgTech-Projekts lässt sich entnehmen, dass die externen Büros anregten, das elektronische Zeichnungsarchiv von Bausig nach außen zu öffnen. Die beim OrgTech-Projekt involvierten Mitarbeiter von Bausig hatten eine ambivalente Haltung gegenüber einer elektronischen Öffnung ihres Archivs. Es wird eine missbräuchliche Nutzung des Archivzugangs befürchtet, doch „von Seiten des Archivs steht man einer gewissen Öffnung für den Datenzugriff ‚offen’ gegenüber, da durch derartige Schritte arbeitsintensive Tätigkeiten entfallen könnten / 50 Das Zitat entstammt einem im OrgTech-Projekt angefertigten Gedächtnisprotokoll, das ein Interview mit einem Mitarbeiter der internen Konstruktionsabteilung wiedergibt. 51 Das Zitat entstammt einem im OrgTech-Projekt angefertigten Gedächtnisprotokoll, das ein Interview mit einem Mitarbeiter eines externen Konstruktionsbüros wiedergibt. 60 würden“52. Diese ambivalente Haltung fand sich auch in der Diskussion des Prototyps mit der internen Konstruktionsabteilung wieder, so z.B. im folgenden Zitat: „Ich glaube die Betrachtung von einzelnen tif-Dateien ist das das Problem nicht, ne das ist also, das können sie ruhig machen. Das ist kein Thema [OrgTech-Mitarbeiter: ja klar] Aber tif-Dateien äh rausholen, aus dem Archiv wie gesagt, ist die Frage überhaupt, ne. [Mitarbeiter2: ehm] Der Teil ja ok [unverständliche Textpassage] zu den Externen.“ Mitarbeiter der internen Konstruktionsabteilung bei Bausig53 Diese aus technischer Sicht widersprüchliche Anforderung ergibt jedoch vor dem Hintergrund der Organisationsstruktur einen Sinn. Im Zitat drückt sich eine unterschwellig gegebene Rahmenbedingung aus, die an die Softwareentwicklung im OrgTech-Projekt gestellt wurde. Sie lässt sich mit dem folgenden Satz charakterisieren: Die Fremddienstleister sollen zwar selbständig arbeiten können, aber die Kontrolle muss bei Bausig bleiben54. Das Anwendungsfeld lässt sich unter der Thematik „Kooperation in Virtuellen Organisationen“ einordnen. Dabei stellen Virtuelle Organisationen ein relativ neues Anwendungsfeld der Informatik dar. Der Begriff der Virtuellen Organisation (VO) ist in der Literatur bisher nicht eindeutig bestimmt. Im allgemeinen werden unter diesem Begriff Phänomene erfasst, die mit bisherigen Beschreibungen organisatorischer Modelle nur unzureichend abgedeckt werden. Eine weitgehend akzeptierte Definition beschreibt virtuelle Organisationen als eine Kooperation von rechtlich unabhängigen Firmen oder Einzelpersonen, die ihre Kernkompetenzen in vertikaler oder horizontaler Weise miteinander vernetzen. Die Literatur betont außerdem das Faktum, dass Hierarchien in virtuellen Organisationen flach und zentrale Koordinations- und Kontrollfunktionen nicht etabliert sind. Die meisten Autoren geben an, dass die virtuelle Organisation nur für eine begrenzte Zeit errichtet wird, und dass die Mitglieder einer virtuellen Organisation gewöhnlich geographisch verteilt arbeiten. Die räumliche Distanz soll dabei durch den Einsatz von Informations- und Kommunikationstechniken (I.u.K.-Techniken) 52 Zitat aus dem Protokoll des Arbeitstreffens, das von einem OrgTech-Mitarbeiter angefertigt wurde. Der Mitarbeiter äußerte das Zitat, als zwei Mitarbeitern der internen Konstruktionsabteilung ein Papier MockUp des Prototyps durch die OrgTech-Mitarbeiter vorgestellt wurde (vom Autor transkribiertes Tonbandprotokoll). 53 54 Ein ähnliches Phänomen beschreiben Sydow et al. (1995), die bei interorganisatorischer Kooperation auch von kontrollierter Autonomie sprechen, wenn „den Akteuren bewusst ein gewisses Maß an Autonomie zugestanden wird, die Einhaltung der Autonomiespielräume aber gezielt kontrolliert werden“ [Sydow et al. (1995, S. 62)]. Im vorliegenden Fall ist jedoch nicht klar, wie der Autonomiespielraum aussehen könnte. DIE ANALYSE DES ANWENDUNGSFELDS 61 überwunden werden [Davidow und Malone (1993), Arnold und Härtling (1995), Mertens, Griese und Ehrenberg (1998)]. Mit der Auflösung der organisatorischen und räumlichen Grenzen erwächst die besondere Flexibilität, die man den VOs zuschreibt. Diese Flexibilität stellt einen entscheidenden Wettbewerbsvorteil in sich dynamisch wandelnden Märkten dar. Aus der Kooperation aus rechtlich selbstständigen und räumlich verteilten Partnern ergeben sich aber auch neuartige Unsicherheitsmomente. Diese entstehen häufig aus der widersprüchlichen Einheit von gemeinsamen und unterschiedlichen Interessenlagen der Kooperationspartner55. In klassischen Organisationen können Konflikte, die sich aus divergierenden Interessenlagen zwischen Individuen oder einzelnen Organisationseinheiten ergeben, durch Weisung entlang der Organisationshierarchien (zumindestens prinzipiell) geregelt werden. Solche Regelungsmöglichkeiten bestehen in virtuellen Organisationen typischerweise nicht. Damit ergeben sich aus der Organisationsstruktur Konfliktpotentiale, die bei der Systemgestaltung zu berücksichtigen sind. 4.2 Forschungsmethodik „The conventional design processes are problematic because they are based on subsequent elimation of alternatives and early commitments which reduce the adaptabilty“ Tekinerdogan und Aksit (1996, S. 10) Im OrgTech-Projekt wurden zur Erfassung der Anforderungen Techniken aus dem Partizipativen Design benutzt. So wurden zu Beginn des Projekts ein Workshop unter der Beteiligung von Vertretern Bausigs und den zwei externen Büros veranstaltet. Nach einer Vorstellung der Projektziele wurden per Kartenabfrage Probleme in der zwischenbetrieblichen Kooperation von den Teilnehmern genannt und gemeinsam geordnet. Basierend auf den im Workshop genannten Problemfeldern wurde ein Interviewleitfaden entwickelt und etwa 20 semi-strukturierte Interviews mit Mitarbeitern der drei Organisationen geführt. Zur Rückkopplung der Designideen dienten ein Papier MockUp und ein Workshop, auf dem ein Prototyp vorgestellt wurde. In der Anforderungserhebung zeigten sich diffuse und zum Teil widersprüchliche Vorstellungen über den Zugriff der Externen. Solche Konstellationen dürften, gerade im Anwendungsbereich des CSCW, nicht unüblich sein. Jedoch tut sich die gängige Anforderungsanalyse, wie es auch im Zitat von Tekinerdogan und Aksit (1996) zum 55 So verwundert es nicht, dass in der VO-Diskussion das Thema Vertrauen einen besonderen Stellenwert hat. Picot und Neuberger (1997) sprechen gar von einem „Vertrauensdilemma“, denn „zum einen ist Vertrauen eine notwendige Voraussetzung [für VOs], zum anderen ist diese Voraussetzung jedoch nur sehr schwierig herzustellen“ (zit. nach Schüppler 1998). Auf den Zusammenhang von Vertrauen und Kontrolle weisen Sydow et al. (1995 S.55 ff.) hin. 62 Ausdruck kommt, in solchen Situationen schwer. Sie sind darauf ausgelegt die Vollständigkeit und Widerspruchsfreiheit zu prüfen. Sie liefern aber keine Einsichten, die die Unvollständigkeit und Widersprüchlichkeiten aufklären. Dies liegt daran, dass auftretende Widersprüche und Unklarheiten nur unter dem Gesichtspunkt der technischen Umsetzbarkeit betrachtet und deswegen als Störungen empfunden werden, die es zu eliminieren gilt. Aus diesem Grund wurde das empirische Material zusätzlich mit Mitteln der empirischen Sozialforschung analysiert. Die Analyse diente dazu, die im OrgTech-Projekt intuitiv getroffenen Einschätzungen methodisch abzusichern und genauere Einblicke in das Anwendungsfeld zu gewinnen. In der Arbeit wurde zur Analyse auf die Objektive Hermeneutik zurückgegriffen. Die Objektive Hermeneutik ist „eine theoretisch begründete Methodologie und zugleich eine forschungspraktische Kunstlehre für die systematische Auswertung jeglichen Datentyps innerhalb des Ensemble der Sozial-, Kultur- und Geisteswissenschaften, also der Erfahrungswissenschaften von der sinnstrukturierten Gegenstandswelt“56. Ihr Anliegen „besteht in einer methodischen Kontrolle der wissenschaftlich-empirischen Operation des Verstehens“ [Wernet (2000, S. 11)]. Ihre Grundannahmen sind in verschiedenen Arbeiten dargestellt worden [Oevermann (1991, 1993, 1996)]. Für die Arbeit ist es wichtig, dass die Objektive Hermeneutik sich auch für die Analyse von Gedächtnisprotokollen eignet. Zwar ist der Umstand, dass es sich um ein ediertes Protokoll handelt zu berücksichtigen, jedoch sind editierte und nicht editierte Protokolle für eine Rekonstruktion nicht kategorial verschieden. Beide werden methodologisch als Protokolle aufgefasst und können deshalb mit gleicher Methode analysiert werden57. Im Rahmen der Objektiven Hermeneutik wurde die Sequenzanalyse als eine Methode zur Fallstuktur-Rekonstruktion entwickelt. Eine Einführung in die Methode findet man bei Wernet (2000). Die Prinzipien zur Analyse von Protokollen sind in Tabelle 4-1 aufgelistet. 56 Dieses Zitat entstammt einer Selbstdarstellung (zu finden unter: http://www.rz.unifrankfurt.de/~hermeneu/Reihe.htm). 57 Zur Analyse editierter Texte siehe auch Oevermann (1997). DIE ANALYSE DES ANWENDUNGSFELDS Analyse-Prinzip Erklärung Kontextfreiheit Welche Bedeutungen hat der Text, unabhängig von seinem aktuellen Kontext. Wörtlichkeit Nicht was der Text sagen wollte, sondern was der Text gesagt hat, ist Ziel der Explikation. Sequenzialität Man wandert nicht zwischen Textstellen auf der Suche nach brauchbaren Teilen, sondern folgt das Textprotokoll Schritt für Schritt. Extensivität Prinzipiell müssen alle protokollierten Textelemente berücksichtigt werden. Kein Element darf ausgeschlossen werden. Sparsamkeit Nur diejenigen Lesarten sind erlaubt, die vom Text erzwungen sind. 63 Tabelle 4-1 Die Prinzipen der Sequenzanalyse [nach Wernet (2000, S. 90)] 4.3 Analyseergebnisse Mit Hilfe der Sequenzanalyse wurde der Protokollausschnitt auf Seite 66 analysiert. Die Analyse liefert einen ersten Hinweis darauf, dass die Zusammenarbeit durch ein dialektisches Verhältnis von Kooperation und Konkurrenz geprägt ist. Diese Hypothese wurde durch andere Stellen im Datenmaterial erhärtet. Als Grund für dieses Verhältnis wurde die Organisationsstruktur identifiziert. Im Folgenden beschränke ich mich darauf, die Ergebnisse der Analyse zu präsentieren, soweit sie für den externen Zugriff relevant sind. 4.3.1 Das dialektische Verhältnis von Konkurrenz und Kooperation Zu Beginn des Projekts befand sich das Stahlwerk in einem länger währenden Umstrukturierungsprozess, der auch das Auslagern von Unternehmensteilen enthielt. So wurde die interne Konstruktionsabteilung zugunsten externer Dienstleister verkleinert. Dies, so kann man annehmen, war mit einer Verunsicherung der Betroffenen verbunden58. 58 Vergleiche Peltzer (1998) zu der Thematik von Umstrukturierungsmaßnahmen und der damit verbundenen Verunsicherung. 64 Durch diese Umstrukturierungsmaßnahmen hat sich die Rolle der internen Konstruktionsabteilung gewandelt. Dadurch ist die interne Konstruktionsabteilung in ein strukturelles Dilemma geraten, dass ein Bausig-Mitarbeiter so beschrieben hat: „Wenn der Fremddienstleister direkt die Betreiber kontaktiert, wird die interne Konstruktionsabteilung zwar entlastet, aber bei Problemen trägt sie die Verantwortung ohne beteiligt worden zu sein. [...] Weiterhin geht der Überblick für die interne Abteilung verloren, wenn Dienstleister und Betreiber direkt miteinander (ohne interne Konstruktion) kommunizieren, da die interne Konstruktion u.U. gar nicht erfährt, dass etwas geändert wurde“59. Das Wünschenswerte, Fremddienstleister und Endkunden agieren direkt miteinander, hat kehrseitig das zu Vermeidende zur Folge, nämlich, dass die interne Konstruktion außen vor bleibt. Die strukturellen Probleme, die sich aus der Umstrukturierung ergeben, drücken sich in unterschiedlichen Rollen aus, die die interne Konstruktionsabteilung gegenüber den externen Büros einnimmt und die sich im Widerstreit zueinander befinden. Geklammert werden die verschiedenen Rollen durch das übergeordnete Ziel, im Sinne Bausigs zu handeln. Die Rollen der internen Konstruktionsabteilung sind sowohl die des Auftraggebers, als auch die des eigenständigen Marktteilnehmers. Dementsprechend ist der Externe aus ihrer Sicht sowohl ein Auftragnehmer, als auch ein Konkurrent. Dabei hat die interne Konstruktionsabteilung auch die Rolle des Werkschutzes zu übernehmen. Die Organisationsstruktur von Bausig lässt es aber offen, wie diese Rolle zu interpretieren ist: Soll nur die eigene Abteilung oder das gesamte Unternehmen geschützt werden und vor allem, sind die externen Büros ein Teil von Bausig, die man zu schützen hat, oder sind die Büros etwas, vor dem man sich und Bausig schützen muss? Aus dieser Konstellation ergeben sich die Unwägbarkeiten in der Beziehung, die dazu führen, dass bei der Zusammenarbeit zwischen Internen und Externen immer gleichgerichtete als auch divergierende Interessen vorhanden sind. Diese Gleichzeitigkeit von Kooperation und Konkurrenz hat auch Auswirkungen auf die Gestaltung der Zugriffskontrolle, auf die ich in Kapitel 1 eingehe. Diese Ambivalenz kennzeichnet aber nicht nur die Auftragsvergabe, sondern auch die weitere Auftragsbearbeitung. Insbesondere trifft dies auf die zur Auftragsbearbeitung notwendigen Zugriffe aufs elektronische Zeichnungsarchiv zu. Bei dem Zugriff der Externen auf das Archiv muss man ebenfalls zwischen der offiziellen und der praktizierten Struktur unterscheiden. Die von Bausig beabsichtigte Arbeitsteilung kann grob so skizziert werden: Der interne Sachbearbeiter sucht alle notwendigen Zeichnungen für den Externen heraus und übergibt sie ihm. Dieser überarbeitet sie dann und gibt sie anschließend wieder zurück. 59 Das Zitat entstammt einem im OrgTech-Projekt angefertigten Gedächtnisprotokoll, das ein Interview mit einem Mitarbeiter einer Konstruktionsabteilung wiedergibt. DIE ANALYSE DES ANWENDUNGSFELDS 65 Am Ende werden sie von Bausig noch einer Qualitätskontrolle unterzogen. Ein Mitarbeiter beschreibt dies wie folgt: „Der externe Dienstleister bekommt von uns in der Regel die komplette Dokumentation, zum Teil auch die Problemlösung übergeben. Er verbleibt nach dieser Vorklärung aber ausführendes Organ. Nachher müssen wir neben inhaltlicher und geographischer Prüfung auch noch die Strukturprüfung vornehmen.“ In einem solchen Idealfall besteht nicht das Problem eines externen Zugriffs auf das Archiv. In der Praxis kommt es aber immer wieder vor, dass Unterlagen nachgefordert werden (in Abbildung 4-1 durch Pfeil (6) dargestellt). Dies kann auf verschiedenen Wegen geschehen: Die Zeichnung kann über Telefon, Fax und neuerdings auch E-Mail angefordert werden. Oder aber der externe Ingenieur fährt auf das Werksgelände und sucht dort zusammen mit einem Mitarbeiter von Bausig im Archiv. Er kann allerdings auch alleine mittels eines guest-account im elektronischen Archiv nach der Zeichnung suchen. Im Archivzugriff reproduziert sich dabei der oben beschriebene Grundkonflikt zwischen den Internen und Externen. Die interne Konstruktionsabteilung beschränkt sich bei der Dokumentenübergabe auf das Notwendigste. Damit übernimmt sie eine eigentlich nicht übertragbare Aufgabe. Denn es gehört mit zur Aufgabe des ausführenden Organs, also der Externen Konstruktionsabteilung, zu beurteilen, ob eine Zeichnung für das Problem relevant bzw. nicht relevant ist. Überlässt die interne Konstruktionsabteilung diese Aufgabe den Externen, so dass die Fremddienstleister direkt das Archiv kontaktieren, wird die interne Konstruktionsabteilung zunächst entlastet. Dann entsteht aber wieder das Dilemma, dass sie bei Problemen die Verantwortung trägt, ohne beteiligt worden zu sein. Weiterhin geht der Überblick für sie verloren, wenn der Dienstleister, ohne sie zu kontaktieren, sich direkt die Zeichnung beschafft, da die interne Konstruktionsabteilung unter Umständen gar nicht erfährt, dass etwas geändert wurde. Daran lässt sich die Hypothese festmachen, dass bei der internen Konstruktionsabteilung ein hohes Kontrollbedürfnis besteht. Dabei scheint auf den ersten Blick der guest-account mittels dessen die Externen selbstständig im elektronischen Archiv suchen können im Widerspruch zur Hypothese zu stehen, dass bei Bausig ein hohes Kontrollbedürfnis besteht. Doch um ihn nutzen zu können, muss sich der Externe zu Bausig begeben und sich dafür vorher angemeldet haben. Damit stellt aber das Werkstor als eine räumliche Begrenzung des Zugangs – und das ist hier offenbar entscheidend – eine für das Sicherheitsbedürfnis von Bausig ausreichende Kontrolle dar. Der guest-account kann als ein Indiz dafür gesehen werden, dass nicht die Zeichnungen an sich das eigentlich Sensible darstellen, sondern der unkontrollierte Zugang dazu. 66 4.3.2 Chance und Risiko – zwei Kinder des Internets Vor dem Hintergrund der eben erläuterten Kooperationspraxis zwischen Internen und Externen ist es interessant, wie die Kooperation über das Internet eingeschätzt wird. Ein Auszug aus einem Protokoll eines Workshops aus der Anfangsphase soll die Haltung illustrieren. Bei dem Workshop wurden die Möglichkeiten einer Telekooperation diskutiert. Es waren Vertreter der internen Konstruktionsabteilung, der EDV-Abteilung von Bausig, den zwei externen Büros und Mitarbeiter des OrgTech-Projekts anwesend. „ (Schmidt60 – interne Konstruktionsabteilung, Meier – EDV-Abteilung bei Bausig, Heinrich – externes Konstruktionsbüro) [...] Schmidt: Alles schwierig, Get Admin und so. Es gibt immer Lücken. Programme die dies ausnutzen[sind] schon im Internet. Da wird es immer was geben, was DOS noch nicht abfängt. Meier: Internet können Heinrich: Es gibt keine Rechte, runtergeholte Sachen nicht zu verwenden. Es gibt die Firma X, für die ich früher gearbeitet habe, deren Anlagen kann man mittlerweile in Asien bestellen. Deren ganzer Know-how Vorsprung ist verloren gegangen. Meier: Ja, deshalb müssen wir die folgende Anforderung an das OrgTechProjekt formulieren: Abwehr von Industriespionage: Aus der Sicht von Bausig, aber auch [der] Büros. Heinrich: Über kurz oder lang wird es unüberschaubar, deshalb von vornherein gut aufpassen. Meier: Nach 18 Minuten Betrieb war der erste Hacker in unserem neuen Firewall-Rechner und nach 22 Minuten in unserem Netz. Deshalb haben wir einen neuen Firewall-Rechner bekommen. Heinrich: Trotzdem, E-Mail ist wichtig“. [aus dem Gedächtnisprotokoll eines Workshop aus der Anfangsphase des Projekts] Im Falle Bausig ist es der Externe, also Heinrich, der sowohl die Risiken benennt („es gibt keine Rechte runtergeholte Sachen nicht zu verwenden“), als auch die Chancen sieht: „Trotzdem, E-Mail ist wichtig“. Für die Mitarbeiter stehen demgegenüber die Gefahren im Vordergrund, die im Internet lauern. Diese Risiken machen es für Bausig schwer, sich auf das Internet als neues Kommunikationsmedium einzulassen. 60 Alle Namen wurden zur Anonymisierung geändert. DIE ANALYSE DES ANWENDUNGSFELDS 67 Auf der technischen Ebene drückt sich diese Haltung in einer restriktiven Konfiguration der Firewall aus, die das Intranet von Bausig schützt. Für die Einschätzung des Projekts ist anzumerken, dass die Konfiguration der Firewall außerhalb des OrgTech-Projekts lag. Es gab deshalb die Anforderung, dass bei der Telekooperationslösung nur via E-Mail zwischen Externen und Bausig kommuniziert werden darf. Bei der internen Konstruktion kann es zusätzlich eine Rolle spielen, dass eine Abschottung vom Internet gleichzeitig eine Abschottung gegenüber der Welt bedeutet. Da der elektronische Zugriff der Externen ein tabuisiertes organisationsstrukturelles Problem der Kooperation betrifft, kann eine mögliche Aversion gegen den Zugriff durch eine kritische Haltung gegenüber dem Internet sublimiert werden. Bei der Haltung der EDV-Abteilung ist zu bedenken, dass sie meist den Schwarzen Peter zugeschoben bekommt, wenn etwas schief läuft. Durch ihre Position kommt ihnen die Rolle zu, Veränderungen kritisch zu begleiten. Auch an diesem Punkt zeigt sich der im Eingangszitat des Kapitels von Weltz, Lullies und Ortmann (1991) festgestellte Doppelcharakter der Softwareentwicklung. Dabei kann man ihnen zustimmen, wenn sie meinen: „Ein Symptom des Doppelcharakters der Software-Entwicklungsprozesse, das die Auseinandersetzungen über die Systemgestaltung zweifellos erschwert, ist der Umstand, dass häufig auf der technischen Ebene argumentiert wird, selbst wo es auch oder primär um ‚politische‘ Aspekte geht.“ Weltz, Lullies und Ortmann (1991) Jedoch handelt es sich im Falle des Internets um eine unternehmens-politische Entscheidung, bei der die Chancen gegenüber den Risiken miteinander abgewogen werden müssen. Bei dieser Entscheidung spielen technische Gesichtspunkte zwar eine wichtige Rolle, man kann sie aber nicht auf diese allein reduzieren. So offenbart sich in der weltweiten Verfügbarkeit des Internet das Gemeinsame von Chance und Risiko als das konstituierende Element unternehmerischen Handelns. 4.4 Zusammenfassung der Analyse Aus den Geschäftszielen und dem Aufbau eines Unternehmens ergeben sich dessen Kerngeschäft und das seiner Organisationseinheiten. Angelegenheiten der zwischenbetrieblichen Kooperation, die in diesen Bereich fallen, werden dementsprechend kritischer beurteilt als die, die eher im Randbereich liegen. Beim Stahlwerk Bausig stellt die Regelung des Zugriffs auf das elektronische Archiv ein Privileg der internen Konstruktionsabteilung dar, insbesondere auch im Wettbewerb mit den externen 68 Dienstleistern. Bedroht die Einführung des externen Zugriffs auf das elektronische Archiv diesen „Wettbewerbsvorteil“ kann dies zu besonderen Spannungen führen. Durch die Einführung von Telekooperationssystemen fallen physische ZugriffskontrollMechanismen (beispielsweise das Werkstor von Bausig) weg. Der Wegfall dieser Kontrollmechanismen hat zur Folge, dass interorganisatorische Spannungen virulent werden und dies sogar die Einführung von I.u.K.-Systemen verhindern kann. Bei der Kooperation über das Internet kommt hinzu, dass die weltweite Verfügbarkeit des Internets sowohl Chancen, als auch Risiken in sich birgt. Die Gleichzeitigkeit von Kooperation und Konkurrenz erklärt, warum es zu den unterschiedlichen und diffusen Vorstellungen der Beteiligten hinsichtlich des externen Zugriffs kommt. Dadurch kann der externe Zugriff eine Transformation der Kooperationspraxis bedeuten, dessen Gewinn schwer abzuschätzen ist. Dies wird noch dadurch verstärkt, dass das Internet ein unbekanntes und dadurch potentiell gefährliches Kommunikationsmedium darstellt. Bei der Gestaltung des Zugriffskontrollsystems für Telekooperationssysteme muss die Gleichzeitigkeit von Kooperation und Konkurrenz ebenso beachtet werden, wie die von organisationalen Vorgaben abweichende Arbeitspraxis. Dabei reicht es nicht aus, die momentane Praxis in ein Computersystem zu formalisieren und damit zu fixieren. Damit ließe sich zwar die Kooperation zwischen Bausig und den Fremddienstleistern effizienter gestalten, jedoch würde man das Transformationspotential unberücksichtigt lassen, das die Einführung einer Telekooperationslösung beinhaltet. Das Spannungsverhältnis, gepaart mit der Benutzung unbekannter Technik, macht es aber für die Beteiligten schwer, sich auf eine zukünftige Praxis festzulegen. Nach der in der Arbeit vertreten den Auffassung, sollte die Systemgestaltung in diesem Punkt möglichst offen gehalten werden und den Benutzern einen „Strauss von Möglichkeiten“ anbieten, der eine Kompromisslösung zwischen den Beteiligten unterstützt. Trotz der bestehenden Unklarheiten lassen sich zwei Eckpunkte angeben, die ein Zugriffskontrollsystem für elektronische Archive besitzen muss: Zum einen muss ein solches Zugriffskontrollsystem den einzelnen Akteuren die Möglichkeit geben, eigenständig Zugriffspolitiken für einzelne Zuständigkeitsbereiche des elektronischen Archivs zu definieren. Dies erfordert ein mächtiges, aber intuitiv nutzbares Konfigurationswerkzeug. Zum anderen reicht es nicht aus, die klassischen Zugriffskontrollsysteme in ihrer Handhabung zu verfeinern, sondern es bedarf qualitativ anderer Kontrollmechanismen. Alle diese Mechanismen haben die Gemeinsamkeit, dass sie den Zugriff auf irgendeine Weise anzeigen. Es ist deshalb anzunehmen, dass die DIE ANALYSE DES ANWENDUNGSFELDS 69 Awareness-Forschung auch Auswirkungen auf die Zugriffskontroll-Modelle gerade im CSCW-Bereich haben wird. 4.5 Sonstige Anforderungen an den Prototypen Neben der Gestaltung der Zugriffskontrolle und der von Bausig vorgegebenen Anforderung, dass die Kommunikation zwischen Bausig und den Externen auf dem Mailprotokoll basieren muss, war die Anbindung an das bestehende elektronische Archivsystem ADOS ein anderes Problem, das gelöst werden musste. ADOS ist eine klassische Zwei-Schichten Architektur. Alle persistenten Daten, außer den eigentlichen Zeichnungen, werden bei ADOS in einer Oracle-Datenbank gespeichert. Die eigentlichen Zeichnungen liegen als Dateien vor, wobei der entsprechende Dateiname in der Datenbank vermerkt ist. Die Programmlogik von ADOS steckt in einer in Visual Basic geschriebenen Microsoft Access-Anwendung. Die Funktionalität von ADOS ist in einer Diplomarbeit beschrieben, die bei Bausig angefertigt wurde. 70 HERLEITUNG EINER ERWEITERTEN ZUGRIFFSKONTROLLE 71 5 HERLEITUNG EINER ERWEITERTEN ZUGRIFFSKONTROLLE Im vorliegenden Kapitel wird ein Modell zur erweiterten Zugriffskontrolle entwickelt. In Abschnitt 5.1 wird gezeigt, warum die in Abschnitt 3.5 dargelegte klassische Zugriffskontrolle zu kurz greift. Aus dieser Einsicht wird ein erweitertes Modell zur Zugriffskontrolle entwickelt, das den Akteuren mehr Spielraum in der Gestaltung der Zusammenarbeit ermöglicht. Eine technische Umsetzung des Modells durch den Prototyp ADOS-X wird in Kapitel 6 vorgeschlagen. Abbildung 5-1 Einflüsse, der in Abschnitt 5.4 beschriebenen erweiterten Zugriffskontrolle und der Zusammenhang zum Prototypen ADOS-X 5.1 Zugriffskontrolle und Kooperation Bei einer Arbeit im Bereich der CSCW-Forschung liegt es nahe, den Zugriff der Externen auf das elektronische Archiv aus dem Blickwinkel der Kooperation zu betrachten. Malone und Crowston (1994) merken in ihrer Coordination Theory an, dass beim kooperativen Arbeiten die gemeinsame Nutzung von Ressourcen untereinander abgestimmt werden muss. Sie sprechen in dem Zusammenhang von Koordination, die sie definieren als „managing dependencies between activities” [Malone und Crowston (1994)]. Aus der Sicht eines Beteiligten kann die Gesamtheit der Ressourcen, wie in Abbildung 5-2 dargestellt, in drei Teile aufgeteilt werden. Die privaten Ressourcen, die gemeinsamen Ressourcen, bei denen die Nutzung mit anderen abgestimmt werden muss und solche, bei denen das nicht der Fall ist. Dem äußeren und dem inneren Kreis ist gemein, dass bei beiden keine Koordination mit Anderen notwendig ist. Im ersten Fall liegt es daran, dass andere keinen Zugang zu den Ressourcen brauchen. Im zweiten Fall sieht man selber keinen Koordinationsbedarf, weil z.B. die Ressource für die eigene Arbeit momentan nicht relevant ist. Eine solche Einteilung findet sich auch bei der Kooperation innerhalb Bausigs und könnte anhand der im elektronischen Archiv eingebauten Versionskontrolle illustriert werden. 72 Private Ressourcen Gemeinsame Ressourcen mit Koordinationsbedarf Gemeinsame Ressourcen ohne Koordinationsbedarf Abbildung 5-2 Einteilung der Ressourcen aus der Sicht eines Anwenders Ob sich die drei Bereiche so klar trennen lassen, wie in Abbildung 5-2 suggeriert wird, ist hier nicht der entscheidende Punkt. Wichtig ist nur, dass es einen dritten Bereich gibt, der von der Zugriffskontrolle nicht erfasst wird. Denn versucht man die drei Bereiche auf die duale Aufteilung der klassischen Zugriffskontrolle abzubilden, erkennt man, dass der Bereich der koordinationsbedürftigen Ressourcen in erlaubt und verboten aufgespaltet werden muss. Die „Erlaubt-Verboten“-Dichotomie der klassischen Zugriffskontrolle liegt darin begründet, dass sie die Kategorie der Koordination bzw. die dafür notwendige Transparenz des Zugriffs nicht kennt. Das Fehlen von Koordination ist ein prinzipielles Defizit der klassischen Zugriffskontrolle, jedoch fällt sie im vorliegenden Fall besonders auf. Die Gleichzeitigkeit von Kooperation und Konkurrenz hat zur Folge, dass dieser Bereich besonders groß ist. Denn die Ressourcen gehören weder dem privatem Bereich, noch dem Bereich ohne Koordinationsbedarf an, was sich daran zeigt, dass sich die Externen prinzipiell jede Zeichnung ansehen können, aber der Zugang überwacht wird. Aus der durch die Telekooperation zunehmende Virtualisierung des Zugriffs und dem damit verbundenen Verlust von sozialer Kontrolle, ergibt sich, dass der Bedarf einer systemvermittelten Kontrolle in diesem Bereich besonders groß ist. Die Coordination Theory von Malone und Crowston (1994) macht zwar auf das Problem der Koordination aufmerksam, ihr Artikel liefert jedoch für den betrachteten Anwendungskontext keine brauchbaren Mechanismen zur Zugriffskontrolle61. 5.2 Optimistische Zugriffskontrolle Ein Ansatz, der auf einem anderen Kontroll-Mechanismus beruht, und deshalb für die vorliegende Arbeit interessant ist, ist die optimistische Zugriffskontrolle von Povey (1999). Dieser Ansatz ergibt sich aus einer Analogie aus der Datenbanktechnik. Beim Transaktionsmanagement gibt es verschiedene Verfahren für das Sperren von Objekten. 61 Dies liegt unter anderem daran, dass Malone und Crawston von Voraussetzungen ausgehen, die auf diesen Fall nicht übertragbar sind. So schreiben sie: “Whenever multiple activities share some limited resource, a resource allocation process is needed to manage the interdependencies among these activities“ [Malone und Crowston (1994)]. Im Falle Bausig – Externe müssen zwar die gemeinsamen Ressourcen verwaltet werden, aber der Kern des Problems besteht nicht in der Knappheit der Ressourcen, sondern höchstens darin, dass sie künstlich knapp gehalten werden. HERLEITUNG EINER ERWEITERTEN ZUGRIFFSKONTROLLE 73 Ein pessimistisches Verfahren sperrt vor dem Ausführen einer Transaktion die Objekte, die dabei verwendet werden, damit diese nicht in einer anderen Transaktion benutzt werden. Ein optimistisches Verfahren überprüft erst am Ende einer Transaktion, ob die Verwendung der benutzten Objekte im Konflikt mit anderen Transaktionen steht. Ist dies der Fall, kann die Transaktion nicht erfolgreich beendet werden und muss rückgängig gemacht werden. Diese Idee kann man auf die Zugriffskontrolle übertragen und zwischen pessimistischen und optimistischen Verfahren unterscheiden. Die klassischen Zugriffskontrollmodelle stellen die pessimistischen dar, weil bei ihnen alle Objekte vor einem Zugriff gesperrt werden, bei denen unter Umständen ein Konflikt auftauchen könnte. Im Gegensatz dazu beschreibt Povey die Funktionsweise eines optimistischen Verfahrens wie folgt: „In an optimistic system, enforcement of the security policy is retrospective, and relies on administrators to detect unreasonable access and take steps to compensate for the action. Such steps might include: Undoing illegitimate modifications, taking punitive action (e.g. firing, or prosecuting individuals) or removing privileges.“ Povey (1999) Die Idee der optimistischen Sicherheit entspringt aus folgender Annahme: “Legitimate and optimistic access control takes the approach of assuming that most accesses will relys on controls external to the system to ensure that the organisations security policy is maintained.” Povey (1999) Der Ansatz beruht dabei auf fünf Vorraussetzungen, auf die hier aber nicht näher eingegangen werden soll. Die fünf Voraussetzungen sind die kontrollierten Einstiegspunkte („constrained entry points“), die Zurechenbarkeit („accountability“), die Aufzeichenbarkeit („auditability“), die Wiederherstellbarkeit („recoverability“) und die Androhbarkeit („deterrents“)). Die Unterschiede zwischen der pessimistischen und der optimistischen Zugriffskontrolle sind in Tabelle 5-1 aufgelistet. Der Hauptunterschied zwischen beiden Modellen ist der, dass die optimistische Zugriffskontrolle es einem Benutzer im Notfall erlaubt, auf Objekte zuzugreifen, auf die er eigentlich kein Zugriffsrecht besitzt. Dies macht das Modell flexibler gegenüber der pessimistischen Kontrolle. 74 Eigenschaft Pessimistisch Optimistisch Zugriffsentscheidung prospektiv Retrospektiv Durchsetzungspolitik Verweigerung Wiederherstellen, Androhungen Kosten einer Verletzung keine einige Flexibilität keine in gewissen Maße Tabelle 5-1 Eigenschaften der pessimistischen versus der optimistischen Sicherheitsstrategie [Povey (1999b)] Wann ein Notfall vorliegt, muss vom Besitzer des Objekts entschieden werden. Das Modell kann aber nur in den Fällen funktionieren, bei denen die entsprechenden Sanktionsmittel vorhanden sind. Dies kann aber bei kooperativer Arbeit erwartet werden. 5.3 Zugriffskontrolle als Konfliktregelung Ein breiterer Ansatz zur Thematik der Zugriffskontrolle geht auf Wulf (1997) zurück. Er untersucht in seiner Dissertation das Konfliktpotential bei der Benutzung von Groupware und die Möglichkeiten des (technischen) Konfliktmanagements. Hierbei kann der Zugriff auf gemeinsam genutzte Ressourcen als ein potentieller Konfliktherd angesehen werden. Die oben dargelegten Zugriffsmodelle stellen dann einen Mechanismus zur Konfliktregelung dar. Der zentrale Punkt bei ihm ist der Begriff des Konflikts, den er aus der sozialwissenschaftlichen Konflikttheorie übernimmt und auf die Benutzung von Groupware anwendet. Er charakterisiert ihn dabei wie folgt: „Ein groupware-spezifischer Konflikt ergibt sich durch die Nutzung oder Anpassung von Groupware zwischen mindestens zwei Rollenträgern (Individuen oder Gruppen), wobei mindestens ein Rollenträger [eine] Unvereinbarkeit mit einem anderen Rollenträger in der Art erlebt, dass durch dessen Aktivierung einer Funktion eine Beeinträchtigung seinerseits erfolgt bzw. erfolgen würde, wenn sie ihm bekannt wäre.“ Wulf (1997, S. 44) Den Rollenträger, der die Funktion aktiv nutzt oder anpasst, nennt er auch „Aktivator“ und den, der sich dadurch beeinträchtigt fühlen könnte, nennt er „Betroffener“. Wichtig bei der Charakterisierung ist, dass ein Konflikt auch dann vorliegt, wenn er dem Betroffenen nicht bewusst ist, und damit keiner Konfliktregelung zugänglich ist. HERLEITUNG EINER ERWEITERTEN ZUGRIFFSKONTROLLE 75 Die technische Umsetzung einer Konfliktregelung leitet er wiederum aus der Konflikttheorie her. Er weist auf verschiedene Strategien innerhalb der Konflikttheorie hin. Dahrendorf (1961), so Wulf, unterscheide zwischen der Unterdrückung, der Lösung und der Regelung von Konflikten als Strategie. Dahrendorf hielte jedoch nur letztere für geeignet. Die Aufgabe des Konfliktmanagements bestände deshalb darin, die Bedingungen dafür zu schaffen, dass sich Konflikte manifestieren können. Außerdem seien die Rahmenbedingungen zwischen den Beteiligten zu vereinbaren, nach denen die Konflikte ausgetragen werden sollen. Die technische Umsetzung des Managements auf dem oben beschriebenen groupwarespezifischen Fall besteht im Feststellen, der Darstellung und der Regelung von Konflikten in kooperativen Systemen. Dabei kann die Regelung eines Konflikts auch darin bestehen, den Akteuren die Mittel an die Hand zu geben, mit denen sie den Konflikt selbst regeln können. Bei der Regelung sind die rechtlichen Vorgaben, wie die informelle Selbstbestimmung, als Rahmenbedingungen zu berücksichtigen. Wulf (1997, S. 82) klassifiziert die technischen Mechanismen der Konfliktregelung aus der Sicht des Betroffenen in sechs Kategorien, die in Abbildung 5-3 aufgelistet sind. Abbildung 5-3 Technische Mechanismen der Konfliktregelung im Überblick [Wulf (1997, S. 83)] Das Hauptmerkmal ist dabei, ob der Konflikt dem Betroffenen durch das System angezeigt wird62. Wenn der Konflikt nicht sichtbar gemacht wird und der Betroffene nicht eingreifen 62 Wulf spricht auch von Transparenz im Sinne von durchschaubar, nachvollziehbar. Der Begriff soll hier übernommen werden, auch wenn er etwas unglücklich gewählt ist, weil in der Informatik meist Transparenz im Sinne von durchsichtig, unsichtbar gebraucht wird. Die Sichtbarkeit bezieht sich bei Wulf auf die Perspektive des Betroffenen. Für den Aktivator ergibt sich die Transparenz scheinbar von selbst, da er mitbekommt, ob seine Aktion erfolgreich durchgeführt wurde. Es gibt jedoch bei der Datenbanksicherheit stellenweise die Anforderungen, dass der Aktivator keine Informationen darüber bekommen soll, ob seine Anfrage verweigert wurde. 76 kann, so wird der gesamte Ablauf durch den Aktivator bestimmt. In dem Fall liegt eine einseitige Steuerung vor (Fall 1). Kann der Betroffene eingreifen, so spricht Wulf von der Gegensteuerbarkeit (Fall 2). Die Regelungen, die den Konflikt dem Betroffenen anzeigen, unterteilt man des Weiteren danach, ob sie dem Betroffenen einen Rückkanal hin zum Aktivator anbieten oder nicht. Existiert kein Rückkanal, kann der Konflikt zwischen den Akteuren nicht innerhalb des Systems ausgehandelt werden. Bei der aktivierungsbezogenen Transparenz (Fall 3) besteht der Mechanismus allein darin, den Betroffenen auf den Konflikt aufmerksam zu machen. Es wird weder ein Rückkanal aufgebaut, noch bietet der Mechanismus dem Betroffenen an, die Aktion zu beeinflussen. Die im Fall 3 zusammengefassten Mechanismen unterscheiden sich noch darin, wann sie den Konflikt sichtbar machen: vor, während oder nach dem Ausführen der Aktion. Die Intervenierbarkeit bietet gegenüber Fall 3 dem Betroffenen die Möglichkeit, die Aktion zu beeinflussen. Bei der Kommentierbarkeit (Fall 5) wird eine Aktion dem Betroffenen sichtbar gemacht. Außerdem hat er die Möglichkeit über einen Rückkanal seine Haltung dem Aktivator mitzuteilen. Er hat jedoch keine Möglichkeit die Aktion zu verändern. Diese Möglichkeit besteht erst bei der Aushandelbarkeit (Fall 6). Der Betroffene kann die Aktion vor der Ausführung verändern oder unterbinden. Kann die Änderung der Aktion vor der Ausführung dem Aktivator zurückgeschickt werden, der diese wiederum ändern kann, spricht man von einem mehrstufigen Verfahren. Im Fall Bausig kann man den Zugriff auf das elektronische Archiv als einen Konflikt zwischen der internen Konstruktionsabteilung und den externen Büros ansehen. Es bietet sich deshalb an, bei den vielfältigen Möglichkeiten auf die KonfliktregelungsMechanismen von Wulf zurückzugreifen. Interpretiert man entsprechend den Ansatz von Wulf als Modell für die Zugriffskontrolle sieht man, dass die klassische Zugriffskontrolle nur einen kleinen Teil eines (technischen) Konfliktmanagements abdecken kann. Die klassische Zugriffskontrolle definiert nur einen nicht-transparenten Konfliktregelungsmechanismus. Für eine erweiterte Zugriffskontrolle bietet es sich an, sie um die vier transparenten Mechanismen, Aktivierunsbezogene Transparenz, Intervenierbarkeit, Kommentierbarkeit und Aushandelbarkeit, zu erweitern. 5.4 Zeitpunkt der Kontrolle Einen anderen Ansatz zur Zugriffskontrolle habe ich in Stevens (2001) vorgeschlagen. Bei dem Ansatz treten zusätzlich zu den Kontrollfaktoren die Kontrollmechanismen als eigenständige Gestaltungsdimension in Erscheinung (Abbildung 5-4). Die Klassifizierung geht vom Begriff der Kontrolle in seiner umgangssprachlichen Bedeutung aus. Es wird dabei nicht anhand von technischen Eigenschaften des Systems klassifiziert, sondern es HERLEITUNG EINER ERWEITERTEN ZUGRIFFSKONTROLLE 77 wird versucht, die praktizierten Kontrollmechanismen entlang des Zeitpunktes, an dem die Kontrolle ausgeführt wird, zu ordnen. Erst im nächsten Schritt wird geschaut, wie man die Mechanismen technisch unterstützen kann. Abbildung 5-4 Kontrollfaktoren und Kontrollmechanismen als Dimensionen einer erweiterten Zugriffskontrolle Man kann drei Zeitpunkte unterscheiden, an denen die Legitimation festgelegt wird: Eine ex-ante Kontrolle liegt dann vor, wenn vor dem Zugriff festgelegt wird, ob er legitim bzw. illegitim ist. Eine uno-tempore Kontrolle liegt dann vor, wenn während des Zugriffs festgelegt wird, ob er legitim bzw. illegitim ist. Eine ex-post Kontrolle liegt dann vor, wenn nach dem Zugriff festgelegt wird, ob er legitim bzw. illegitim war. Die klassischen Zugriffskontroll-Systeme fallen in den Bereich der ex-ante Kontrolle. Überträgt man die Erkenntnisse aus Abschnitt 5.1 auf die ex-ante Kontrolle sieht man, dass man mit der ex-ante Kontrolle den Bereich festlegen kann, in der keine Koordination notwendig ist. Dadurch kann der Kontrollaufwand verringert werden, weil im verbotenen und im uneingeschränkt erlaubten Bereich der Zugriff der Externen nicht überwacht werden muss. Bei dem Bereich des unkontrollierten Zugriffs sollte man zusätzlich unterscheiden, ob der Bereich als erlaubt ausdrücklich festlegt wurde oder ob er sich als das Residuum des durch die Zugriffskontrolle nicht erfassten Bereichs ergibt. Nur im ersten Fall kann man von einer ex-ante Kontrolle sprechen. Ein Beispiel für eine uno-tempore Kontrolle kann man bei Kindern beobachten, die grundsätzlich darauf bestehen, dass man nachfragt, bevor man eines ihrer Spielzeuge ausleiht. Dabei steht nicht die Frage der Legitimation im Vordergrund, denn hier geht es weniger darum, den ‚Zugriff’ zu verweigern, sondern vielmehr geht es darum, die Besitzverhältnisse zu demonstrieren. Jedoch muss die Demonstration immer wieder aufs Neue vollzogen werden und kann deshalb nur uno-tempore passieren. Diese Gemeinsamkeit von Kontrolle und Machtdemonstration findet man auch bei der 78 momentanen Kooperationspraxis von Internen und Externen bei Bausig wieder. Wenn der Externe eine Zeichnung mittels einer E-Mail anfordert, so ist die manuelle Bearbeitung dieser Anfrage durch den Sachbearbeiter, wie die Analyse zeigt, nicht nur eine lästige Tätigkeit, sondern stellt gleichzeitig eine uno-tempore Kontrolle dar. Die ex-post Kontrolle findet sich in der Formulierung: „Der Missbrauch wird bestraft“ wieder. Die Kontrollstrategie die dahinter steht beruht darauf, dass drei Voraussetzungen erfüllt sind: 1. Es gibt einen Gebrauch, denn sonst gäbe es kehrseitig auch kein Missbrauch. 2. Ein Missbrauch ist erkennbar. 3. Ein Missbrauch kann bestraft werden. Povey (1999) sieht in den Nothalt- oder Feueralarm-Schaltern ein Beispiel, das auf der expost Kontrolle beruht. Diese Schalter stecken hinter einem Schutzglas, das im Notfall eingeschlagen werden kann. Das hat den Vorteil, dass zum einen ein versehentlicher Missbrauch verhindert wird, zum andern kann die Schutzhülle mit einer Warnung versehen werden, die beschreibt, wie ein Missbrauch geahndet wird. Ein anderes Beispiel für eine ex-post Kontrolle sind die Sicherheitskameras in Banken oder Tankstellen. Sie bieten zwar keinen aktiven Schutz gegenüber einem Raubüberfall, doch helfen sie, den Raubüberfall aufzuklären und zu ahnden. Bei der Untersuchung des Anwendungsfelds wurde ein solcher Mechanismus zwar nicht angetroffen, jedoch besitzt Bausig gegenüber den Externen ein Drohpotential. So könnte ein Missbrauch durch die Externen durch Abbruch der Geschäftsbeziehung bzw. in einer Einschränkung der Handlungsfreiheit der Externen geahndet werden. Insofern ist dieser Mechanismus auch für Bausig sinnvoll. Der ex-post Kontroll-Mechanismus beruht darauf, dass die Historie des Zugriffs dem Kontrolleur zur Verfügung steht. Ein Kontrollmechanismus, der ebenfalls darauf beruht, dass die Historie des Zugriffs zur Verfügung steht, besteht in der Einführung eines Kontingents. Diesen Sicherheitsmechanismus findet man in der Praxis z.B. bei manchen Bibliotheken, die eine Obergrenze für die Anzahl der gleichzeitig ausgeliehenen Medien festsetzen. Auch in der Festsetzung einer Obergrenze für das Abheben an einem Geldautomaten findet man diese Strategie. Aber obwohl der Mechanismus auf dem Verlauf des Zugriffs beruht, stellt er eine ex-ante Kontrolle dar, weil das Verhalten des Mechanismus vorher festgelegt wird. Im Fall Bausig findet man in den Interviews Hinweise darauf, dass auch dort diese Art der Kontrolle helfen könnte. Denn zum einen besteht die Befürchtung, die auch in der zitierten Stelle des Workshop-Protokolls auf Seite 66 zum Ausdruck kommt, dass das Archiv „leergesaugt“ werden könnte. Zum anderen kam aus den Interviews heraus, dass die einzelne Zeichnung „nicht das Problem sei“. In der Festlegung eines Kontingents könnte der Sachbearbeiter den automatischen Zugriff der HERLEITUNG EINER ERWEITERTEN ZUGRIFFSKONTROLLE 79 Externen begrenzen. Dadurch könnten Vorbehalte gegen einen automatischen Zugriff bei Bausig abgebaut werden. 5.5 Faktoren für die Zugriffsstrategie Die Faktoren, die für die Zugriffskontrolle aus der Sicht der Mitarbeiter von Bausig für die Regelung des Zugriffs relevant sind, sind in Tabelle 5-2 aufgelistet. Parameter Faktor Beschreibung Objekt Inhalt Merkmale bei den beschreibenden Daten zu einer Zeichnung (Zeichnungs-Nr., Basis-Nr., ...). Status der Zeichnung Ist die Zeichnung aktuell in Bearbeitung? Subjekt Benutzer Von wem geht der Zugriffswunsch aus? Situation Zeitangaben Projektabhängiger Verfall von Zugriffsrechten. Auftrag Zuordnung vom Objekt/Subjekt zu einem Auftrag. Priorität Welche Priorität hat der Auftrag? Art des Zugriffs Nur beschreibende Daten lesen, die eigentliche Zeichnung lesen oder diese Daten modifizieren? Operation Tabelle 5-2 Relevante Faktoren für die Zugriffskontrolle beim OrgTech-Projekt Interessanterweise wurden in diesem Anwendungsfeld die Zugriffsdimensionen der Benutzerrolle, Organisationseinheit und Gruppenzugehörigkeit als nicht relevant erachtet. In einer früheren Untersuchung in der öffentlichen Verwaltung wurde dagegen diesen Dimensionen eine wichtige Rolle zugemessen [vgl. Stiemerling, Won und Wulf (2000)]. Dies könnte daran liegen, dass bei zwischenbetrieblicher Kooperation die persönliche Ebene eine wichtige Rolle spielt. Ebenso unterscheiden sich die Faktoren, die sich auf das zuzugreifende Objekt beziehen. Im Falle des Stahlwerks wurde auf Zeichnungen zugegriffen, die in einer relationalen Datenbank gespeichert waren. Dabei kam den dort abgelegten beschreibenden Daten zu den Zeichnungen eine besondere Bedeutung zu. Zu den beschreibenden Daten zählten insbesondere die Zeichnungsnummern und die Basisnummern, mit denen die Zeichnungen inhaltlich gruppiert wurden. Demgegenüber waren in der Studie von Stiemerling, Won und Wulf (2000) die folgenden Faktoren besonders relevant für die Vergabe von Zugriffsrechten: Name des Dokuments, Inhalt des Dokuments, Entwicklungsstand des Dokuments, Objektlage und Elektronische Signatur. In Anwendungsfeldern, bei denen mit semi-strukturierten Dokumenten gearbeitet wird, können die objektbezogenen Faktoren 80 wiederum anders aussehen. Zusammenfassend kann man wohl davon ausgehen, dass in jedem Anwendungsfeld die zur Zugriffsregulation relevanten Faktoren unterschiedlich ausgeprägt sein werden. 5.6 Resümee In Abschnitt 5.1 wurde gezeigt, warum die klassische Zugriffskontrolle im vorliegenden Fall zu kurz greift. Deshalb sollte eine Telekooperationslösung die Kontrolle zu allen drei Zeitpunkten unterstützen. Insbesondere sollte eine uno-tempore Kontrolle berücksichtigt werden, da die momentan praktizierte Kontrolle darauf beruht. Bei der Unterstützung der ex-ante Kontrolle sollte es aus den auf Seite 78 genannten Gründen das System auch ermöglichen ein Kontingent für den automatischen Zugriff festzulegen. Durch die Unterstützung der ex-post Kontrolle ergibt sich als Nebeneffekt, dass das Vertrauen in die Telekooperation erhöht werden kann. Denn durch die Protokollierung des Zugriffs und die Darstellung der Historie kann der Sachbearbeiter nicht nur die Externen, sondern auch das Computersystem kontrollieren. Dies ist gerade in den Fällen besonders wichtig, wenn, wie hier, auf eine unbekannte Technik vertraut werden muss63. 63 Auf den Zusammenhang zwischen hohe Kontrollgrad und positiver Chancenbewertung der Technik hat Rudinger et al. (1999) hingewiesen. IMPLEMENTIERUNG DES PROTOTYPEN 81 6 IMPLEMENTIERUNG DES PROTOTYPEN Nachdem in den vorherigen zwei Kapiteln herausgearbeitet wurde, an welcher Stelle eine Softwarelösung anpassbar sein muss, wird in diesem Kapitel eine Implementierung vorgestellt, die diese Anforderung realisiert. Bei der Modellierung des Systems steht man vor der Schwierigkeit, dass der FlexiBean-Ansatz zwar ein technisches Modell zur komponentenbasierten Anpassbarkeit besitzt, darüber hinaus aber keine Methode zur Dekomposition bereitstellt. In diesem Kapitel wird gezeigt, wie der WAM-Ansatz die FlexiBeans in diesem Punkt ergänzt und wie dessen zentrale Idee der engen Korrespondenz zwischen dem anwendungsfachlichen Begriffsgebäude und der Softwarearchitektur zur Dekomposition herangezogen werden kann. In Abschnitt 6.1 wird gezeigt, wie sich die wichtigsten Entwurfsmuster des WAMAnsatzes mit Hilfe der FlexiBeans realisieren lassen. In Abschnitt 6.2 wird die Postfachmetapher vorgestellt, mit der in Abschnitt 6.3 ein elektronischer Zugang der Externen realisiert wird, der an die momentane Arbeitspraxis bei Bausig und den Externen anschließt. In Abschnitt 6.4 wird das System durch Bereitstellung neuer Komponententypen so modifiziert, das es der im vorherigen Kapitel erhobenen Forderung nach einer erweiterten Zugriffskontrolle gerecht wird. Auf die Modellierung des Materials durch FlexiBeans wird erst im Abschnitt 7.2.3 eingegangen, da sie noch einen offenen Punkt in der Softwaregestaltung darstellt. Die hier dargestellte Version von ADOS-X ist eine Erweiterung der ursprünglichen, im Anwendungsfeld benutzten Dekomposition. Die Erweiterung resultiert aus der Analyse des Anwendungsfeldes und den daraus resultierenden Überlegungen, dass es die Möglichkeit geben sollte, den automatischen Zugriff zu kontingentieren. Die ursprüngliche Dekomposition, die auch implementiert wurde, ist in Anhang A zu finden. Da die einfache Erweiterung eine wichtige Eigenschaft des FlexiBean-Ansatzes ist, wird hier die erweiterte Dekomposition vorgestellt. In der Evaluation komme ich auf diesen Punkt noch einmal zurück. 6.1 Umsetzung des WAM-Ansatzes mit Hilfe der FlexiBeans In diesem Abschnitt wird gezeigt, wie die wichtigsten Entwurfsmetaphern des WAMAnsatzes, die im Folgenden kurz charakterisiert werden, sich mit Hilfe von FlexiBeans realisieren lassen. Die Kurzcharakterisierungen sind aus Züllighoven (1998) entnommen, die angegebenen Beispiele stammen von dem implementierten Prototyp. Die vorgeschlagene Umsetzung kann jedoch nur als ein erster Anhaltspunkt für eine Softwaremodellierung dienen. So wurden bei dem Prototypen einige Komponenten 82 eingeführt, die keinen fachlichen Bezug zum Anwendungskontext haben. Diese wurden vor allem für die Modellierung der Benutzerschnittstelle gebraucht. Bei der Modellierung des Materials mittels FlexiBeans herrscht sicherlich noch ein größerer Forschungsbedarf. Werkzeug: Ein Werkzeug unterstützt wiederkehrende Arbeitsabläufe und -handlungen. Es ist bei unterschiedlichen Aufgaben und Zielsetzungen nützlich. Ein Werkzeug wird von seinem Benutzer je nach den Erfordernissen einer Situation gehandhabt oder wieder zur Seite gelegt. Es schreibt keine festen Arbeitsabläufe vor. Als Softwarewerkzeug ermöglicht es den interaktiven Umgang mit den Arbeitsgegenständen (Materialien) [Züllighoven (1998, S.6)]. Ein Beispiel eines WAM-Werkzeugs stellt der Anfragenbearbeiter im ADOSX dar. Modellierung des Werkzeugs im FlexiBean-Ansatz: Für ein Werkzeug ist die Interaktion mit dem Benutzer konstitutiv. Es wird deshalb durch eine sichtbare Komponente modelliert, die auf dem Client ausgeführt wird. Wie auf Seite 84 erläutert wird, lagern Materialien in Behältern, die durch ein SharedObject zugänglich gemacht werden. Das Werkzeug kann durch einen SharedObject-Client an den Behälter gekoppelt werden. Dadurch kann das Werkzeug auf das zu bearbeitende Material zugreifen. Des Weiteren kann es sinnvoll sein, dass ein Werkzeug auf äußere Ereignisse reagiert. Beispielsweise kann an das Werkzeug ein Event gesendet werden, dass ein bestimmtes Material bearbeitet werden kann. Ebenso kann das Werkzeug Events aussenden, z.B. dass es die Bearbeitung beendet hat. Material: Materialien sind die Arbeitsgegenstände, die schließlich zum Arbeitsergebnis werden. Materialien werden mit Werkzeugen entsprechend bearbeitet. Softwarematerialien verkörpern »reine« anwendungsfachliche Funktionalität. Sie werden niemals direkt benutzt und stellen sich auch nicht selbst dar. Ein Softwarematerial ist durch sein Verhalten, nicht durch seine Struktur charakterisiert [Züllighoven (1998, S.6)]. Die Anfragen, die die Externen an ADOS schicken, sind ein Beispiel für ein Material. Modellierung des Materials im FlexiBean-Ansatz: Die Materialien bilden den dynamischen Teil einer Anwendung. Sie werden deshalb auch nicht in der durch die CATFiles spezifizierten statischen Architektur erfasst. Materialien, wie z.B. die Anfrage-EMails, sind vielmehr das, was durch die Komponenten fließt bzw. verarbeitet wird. Sie werden durch ein SharedObject eines Behälters zur Verfügung gestellt und sind erst durch die Werkzeuge für den Benutzer zugänglich. Bei ihnen muss zwischen der Bearbeitung und der Anpassung unterschieden werden. Anpassung bedeutet dabei, einen neuen Materialtypen zu erzeugen. Auf das Problem der Anpassung eines Materials gehe ich in Abschnitt 7.2.3 ein. IMPLEMENTIERUNG DES PROTOTYPEN 83 Automat: In einer Büroumgebung gibt es nicht nur Werkzeuge und Materialien. Viele lästige Arbeitsroutinen werden heute maschinell, d.h. automatisch, erledigt. Deshalb wurde die Entwurfsmetapher des Automats eingeführt. Ein Automat erledigt eine vorab vollständig festgelegte Aufgabe und produziert ein definiertes Ergebnis. Einmal eingestellt, kann ein Automat über einen längeren Zeitraum ohne Eingriff von außen ablaufen. Softwareautomaten laufen meist im Hintergrund. Sie werden von ihren Benutzern am Anfang eingestellt oder im Notfall gestoppt und haben darüber hinaus keine interaktive Schnittstelle. [Züllighoven (1998, S.6)]. Der Post-Versandautomat und -Empfangsautomat sind zwei Beispiele aus ADOS-X, die die Anbindung an einen Mailserver bewerkstelligen. Modellierung des Automaten im FlexiBean-Ansatz: Automaten werden ähnlich wie Werkzeuge als eigenständige FlexiBeans realisiert. Im Unterschied zu Werkzeugen bedürfen sie keiner Interaktion mit dem Benutzer, sondern können autonom arbeiten. Sie sind deshalb keine sichtbaren Komponenten und müssen auch nicht auf dem Client des Benutzers ausgeführt werden. Die serverseitige Ausführung erlaubt es dem Benutzer wiederkehrende Aufgaben an den Automaten zu delegieren, die dieser auch in seiner Abwesenheit ausführen kann. Aus dieser Autonomie resultiert auch eine andere Fehlerbehandlungsstrategie als bei Werkzeugen, da nicht davon auszugehen ist, dass der Benutzer bei einem Fehler eingreifen kann64. Das Konfigurieren des Automaten geschieht mit Hilfe der Anpassungsumgebung, die das FlexiBean-System bereitstellt 65. Arbeitsumgebung: Die Metaphern Werkzeuge, Automaten und Materialien benötigen einen Ort, an dem sie bereitgestellt, angeordnet und aufbewahrt werden. Dies leistet die Metapher der Arbeitsumgebung. Eine Arbeitsumgebung ist der Ort, an dem Arbeitsaufgaben erledigt und die dazu benötigten Arbeitsgegenstände und -mittel bereitgestellt werden. Arbeitsumgebungen verkörpern ein Raumkonzept und Ordnungsprinzipien. Im WAM-Ansatz wird zwischen den persönlichen Arbeitsplätzen, die Privatheit und eine individuelle Anordnung der Dinge ermöglichen, und den allgemein zugänglichen Räumen einer Arbeitsumgebung unterschieden [Züllighoven (1998, S.6)]. Modellierung der Arbeitsumgebung im FlexiBean-Ansatz: Durch die hierarchische Komposition der FlexiBeans ist schon ein Ordnungsprinzip vorgegeben, das mit Hilfe der Anpassungsumgebung von Hallenberger (2000) in eine dreidimensionale Raumordnung umgesetzt wird. Durch die Client-Server Architektur der Evolve-Plattform wird auch eine erste Unterscheidung von privat und öffentlich vorgenommen, die sich auch im 64 Dieses Problem wurde bei der Modellierung erkannt, aber in der vorliegenden Arbeit wurde keine allgemeine Lösung dafür entwickelt. 65 Das Anpassen durch spezielle Anpassungs-Werkzeuge, wie dies beim der Sortierer-Komponente nötig ist, wird derzeit vom FlexiBean-Ansatz nicht unterstützt. Ein Lösungsansatz hierzu wird in Abschnitt 7.2.2.2 gezeigt. 84 Raumkonzept widerspiegelt. Jedoch ist auf der Serverseite eine Differenzierung in private und öffentliche Bereiche wünschenswert. Mit Hilfe von öffentlichen Bereichen ließe sich auch die in Abschnitt 3.1.3.3 geforderte Anpassungskultur verbessern. Behälter: Ein (fachlicher) Behälter ist eine spezielle Arbeitsumgebung für Materialien. Er kann sie aufnehmen, verwalten, ordnen und herausgeben. Dazu führt der Behälter oft Verzeichnisse. In einem Behälter können viele gleichartige oder ein definierter Satz von unterschiedlichen Gegenständen verwahrt werden. Behälter vergegenständlichen oft Prozesse als so genannte Vorgänge und dienen der Kooperation und Koordination. Die Postfächer, die die Anfragen an das elektronische Archiv aufnehmen, sind ein Beispiel für einen Behälter [Züllighoven (1998, S.6)]. Modellierung des Behälters im FlexiBean-Ansatz: Behälter werden in FlexiBeans als unsichtbare Komponenten modelliert, in denen die Materialien gelagert sind. Die Materialien werden nach außen durch SharedObjects angeboten. Das SharedObject sollte neben dem Zugriff auf die Materialien auch, wie oben beschrieben, verschiedene Suchund Auflistungsmethoden besitzen. Damit die Materialien auch dauerhaft gespeichert werden können, sollten sie über einen Persistenzmechanismus verfügen. Auf das Problem der Persistenz bei FlexiBeans wird in Abschnitt 7.2.1 eingegangen. 6.2 Postfach-Metapher In diesem Abschnitt wird das Konzept der Postfach-Metapher vorgestellt. Mit Hilfe dieser Metapher lässt sich ein System für den externen Zugang zum elektronischen Archiv modellieren, das die Struktur der momentanen Arbeitspraxis von Bausig und den Externen widerspiegelt. Wulf, M. (1995) untersuchte in ihrer Diplomarbeit die Bedeutung von Postfächern für die kooperative Arbeit. Sie hat herausgefunden, dass Postfächer in der Praxis als ein Koordinationsmedium benutzt werden. Die Bedeutung des Postfachs hängt dabei von seinem Standort und seinem Gebrauch ab. Grob kann man hier zwischen öffentlichen und privaten Postfächern unterscheiden. Ein Beispiel für öffentliche Postfächer sind die bei Stiemerling und Wulf (2000) beschriebenen, allgemein zugänglichen Fächer in einer Zeitungsredaktion. Ihre Funktionsweise hängt stark mit der allgemeinen Sichtbarkeit des Zugriffs auf die Fächer zusammen. Private Postfächer erhalten durch ihre Benennung eine Bedeutung im Arbeitskontext des Benutzers, der den Gebrauch präsupponniert. Wenn z.B. ein Postfach mit „Anfragen Projekt Kran“ beschriftet ist, wird es eine ganz andere Bedeutung für den Benutzer besitzen, als wenn es z.B. mit „Papierkorb“ bezeichnet wird. IMPLEMENTIERUNG DES PROTOTYPEN 85 Mackay (1990, Kapitel 3) zeigt am Beispiel von InfoLens, einem E-Mail-Programm, wie mit Hilfe von elektronischen Postfächern und dem Aufstellen von IF-THEN-Regeln die Anwender das System auf vorher nicht antizipierte Art und Weise angepasst haben. Ein ähnliches Konzept bilden hier die Postfach-Komponenten zusammen mit den SortiererKomponenten. Jedoch ist der Anwendungskontext in beiden Fällen unterschiedlich. Bei InfoLens ging es um eine bessere Strukturierung der E-Mail-Korrespondenz, während es hier darum geht, den Zugriff auf eine gemeinsam benutzte Ressource zu kontrollieren. Auf der software-technischen Seite stellen die Postfächer einen Behälter im oben beschriebenen Sinne dar. Bei der Implementierung wurde die Modellierung von M. Wulf übernommen. Sie unterscheidet zwischen Eingangs- und Ausgangspostfächern. Technisch ausgedrückt bieten die Postfächer ein IN- und ein OUT-SharedObject an, dessen Schnittstellenbeschreibung in Abbildung 6-1 zu sehen ist. Das Interface Message wird von den Anfrage-Objekten implementiert. Auf das Message-Interface wird in Abschnitt 7.2.3 eingegangen. Die Unterscheidung in IN und OUT hat den Vorteil, dass man nach Außen nur das IN-Fach exportieren kann und das Postfach dann wie ein Briefkasten funktioniert, bei dem man etwas hineinwerfen kann, ohne aber an den Inhalt zu kommen. «interface» PO_box «interface» IN +add() «interface» Message «interface» OUT +getAndRemove() +listMsgs() +get() Abbildung 6-1 UML-Klassendiagramm der SharedObjects eines Postfachs 6.3 Umsetzung, die auf der praktizierten Zugriffskontrolle beruht Im Folgenden sollen zuerst die einzelnen Komponenten und die ADOS-Anfragen vorgestellt werden, bevor auf die Komponentenkomposition eingegangen wird. FlexiBean Beschreibung Postfach: Das Postfach ist der Aufenthaltsort für Dokumente. Über den Eingang-Port können Dokumente hinein- und über den AusgangPort, herausgenommen werden. Wenn sich der Zustand des Postfachs ändert, wird über den Geändert-Port ein Event gesendet. Der StorePort dient dazu, dass alle Postfächer sich einen gemeinsamen Persistenzmechanismus teilen können66 66 Auf den Store-Port wird erst in Abschnitt 7.2.1 eingegangen, da der Port nur für die Persistenz der Postfächer wichtig ist und die Persistenz ein noch offnes Problem im FlexiBean-Ansatz darstellt. 86 Empfangsautomat und Versandautomat: Der Empfangs- und der Versandautomat stellen die Verbindung zum Mailserver her. Beim Empfangsautomat kann am Eingang-Port ein Postfach angeschlossen werden, in dem der Automat die empfangene Post hineinlegt. Bekommt der Automat ein Empfange-Event, schaut er beim Mailserver nach neuer Post. Der Wert des Parameters Häufigkeit gibt an, wie häufig der Automat, in Millisekunden gemessen, nach neuer Post schauen soll. Soll er nicht selbstständig die Post abholen, muss der Wert auf Null gesetzt werden. Der Parameter Protokoll gibt das verwendete Mailserver-Protokoll an (POP3 oder IMAP)67. Beim Empfangsautomat muss das Kennwort im CAT-File abgespeichert werden, damit keine Interaktion mit dem Benutzer beim Initialisieren der Verbindung zum Mailserver notwendig ist. Am Versandautomat kann ein Postfach angeschlossen werden, dessen Dokumente versendet werden sollen. Der Versand wird durch ein Verschicke-Ereignis ausgelöst. ✦ ✗ ✘ ✙ ✖ ✚ ✛ ✌ ✜ ✣ ✢ ✤ ☛ ✎ ✎ ✥ ☛ ✓ ✔ ✡ ✕ ✖ ✎ ✏ ✎ ✂ ✄ ★ ✯ ✵ ✁ ✒ ✧ ✮ ✲ ☎ ✩ ✰ ✶ ✬ ✆ ✧ ✁ ✧ ✬ ✩ ✲ ✫ ✳ ✠ ✡ ✑ ✭ ✭ ✴ ✫ ✞ ✑ ✬ ✩ ✧ ✝ ✏ 67 ✪ ✱ ☛ ✟ ☞ ✌ ✍ ✎ ✎ Visualizer und Anfragenbearbeiter: Der Visualizer ist eine abstrakte Komponente, die den eigentlichen Anfragenbearbeiter enthält. Der Visualizer wird über den GeändertPort aktualisiert. An der Postfächer-Raute68 werden die Postfächer angeschlossen, die visualisiert werden sollen. In das Postfach, das am Erlaubt-Port angeschlossen ist, kann der Benutzer die Anfragen weiterleiten, bei denen ein Zugriff gestattet werden soll. Zum ZurückPort werden die Anfragen geleitet, die direkt an den Empfänger zurück geschickt werden sollen. Aus der Sicht des Benutzers wäre die Einstellung des Parameters Protokoll weniger fehlerträchtig, wenn man nur aus einer vordefinierten Menge auswählen könnte. Ein solcher Enumeration-Typ wird aber vom FlexiBean-Modell nicht unterstützt. 68 Auf die Semantik der Raute wird im Abschnitt 7.2.3 eingegangen. IMPLEMENTIERUNG DES PROTOTYPEN 87 ADOS: Die ADOS-Komponente stellt die Verbindung zum bestehenden elektronischen Archiv, ADOS, her. Dazu greift die ADOSKomponente auf die Datenbank zu, in der die Archivinformationen gespeichert sind. Das Postfach mit den Zugriffsanfragen wird am Eingang-Port angeschlossen. Die Komponente fragt die Datenbank ab, erstellt eine Antwort, hängt diese an die Anfrage an und leitet sie dann an den Ausgang-Port weiter. Tritt bei der Bearbeitung ein Fehler auf, so wird die Anfrage an den Ausg_Fehler-Port weitergeleitet. Durch den Bearbeite-Port kann die ADOS-Komponente veranlasst werden, die Anfragen, die im angeschlossenen Eingangspostfach liegen, zu entnehmen und zu bearbeiten. Retoure: Die Retoure -Komponente dient dazu, eine Anfrage an den Empfänger zurückzuschicken. Sie transportiert dazu die Anfragen, die im Eingangspostfach liegen, an den Ausgang und vertauscht bei diesem Vorgang Absender und Empfänger. Durch ein Geändert-Event wird der Sortierer veranlasst, im Eingang nach Anfragen zu schauen und diese weiterzuleiten. Tabelle 6-1 Grundkomponenten für einen externen Zugriff auf das elektronische Archiv Mit Hilfe der oben genannten Komponenten kann ein System für den externen Zugriff auf das elektronische Archiv so modelliert werden, dass es die praktizierte Kontrolle des Zugriffs widerspiegelt. Die Dekomposition begreift die Randbedingung, dass nach draußen nur über E-Mail kommuniziert werden darf, nicht als eine Einschränkung, sondern integriert sie in das Modellierungskonzept. Die gefundene Lösung kann man als asynchrone, auf dem Versandprinzip beruhende CSCW-Anwendung klassifizieren. Sie besteht aus einem Mailclient für die Bausig-Mitarbeiter und einem für die Externen. Beide sind jeweils aus den oben genannten Komponenten aufgebaut. Die Funktionsweise des Systems, im Folgenden ADOS-X genannt, ist wie folgt: Der Externe initiiert eine Suche im elektronischen Archiv, in dem er mit Hilfe seines Mailclients eine Anfrage erstellt und sie an seinen internen Sachbearbeiter schickt. Die Anfrage sieht für den Anwender wie eine E-Mail aus, bei der er aber keinen Text eingibt, sondern ein spezielles Suchformular ausfüllt. Das Aussehen der Suchformulare ist dabei den Eingabemasken von ADOS nachempfunden worden. Ein solches Suchformular ist in 88 Abbildung 6-2 zu sehen. Dadurch soll erreicht werden, dass gerade für die Internen ADOS-X leicht zu erlernen ist. Abbildung 6-2 Ein Screenshot eines Suchanfrage-Formulars Die Funktionsweise des Mailclients für die interne Konstruktionsabteilung bei Bausig wird anhand des internen Aufbaus (Abbildung 6-3) dargestellt. Empfangsautomat Eingang Eingang Ausgang Eingang Anfragenbearbeiter Zurück Eingang Geändert Geändert Erlaubt Eingang Nach Ados Ausgang Geändert Eingang Bearbeite ADOS Fehler Eingang Fehlerhafte Ausgang Eingang RetourePf. Ausgang Eingang Geändert Geändert Retoure Ausgang Eingang Ausgang Eingang Ausgang Geändert Geändert Versandautomat Abbildung 6-3 Komposition des Mailclients für den Bausig-Sachbearbeiter IMPLEMENTIERUNG DES PROTOTYPEN 89 Die Anfrage wird durch den Versandautomaten in eine E-Mail nach RFC 822 Standard transformiert und an ein spezielles E-Mailkonto bei Bausig geschickt. Hier steht sie dem Empfangsautomaten, wie in Abbildung 6-3 zu sehen ist, zur Verfügung. Er holt die Mail ab und legt sie ins Eingangspostfach. Die Anfrage wird dann vom Sachbearbeiter geprüft. Ist sie in Ordnung kann er sie über den Erlaubt-Port an das Postfach „Nach ADOS“ weiterleiten. Aus diesem Postfach entnimmt sich die ADOS-Komponente die Anfrage, generiert eine SQL-Abfrage und hängt das Ergebnis an die Anfrage an. Danach leitet die Komponente sie über den Ausgang-Port an das Retoure-Postfach weiter. In dem anderen Fall, bei dem die Anfrage nicht in Ordnung ist, kann der Sachbearbeiter sie entweder entsprechend abändern oder er leitet sie direkt über den Zurück-Port an das Retoure-Postfach weiter. Vom Retoure-Postfach werden die Anfragen von der RetoureKomponente in das Ausgang-Postfach transportiert. Dabei vertauscht er den Absender mit dem Empfänger, so dass der Versandautomat die (beantworteten) Anfragen als Mail an die Empfänger zurückschickt. 6.4 Umsetzung einer erweiterten Zugriffskontrolle Die in Abschnitt 6.3 beschriebene Lösung stellt eine Verbesserung des Status quo dar, weil die Zusammenarbeit zwischen Internen und Externen effizienter gestaltet wird. So muss der Sachbearbeiter die Anfrage nicht mehr per Hand in ADOS eingeben und das Ergebnis in eine E-Mail transformieren. Jedoch bleibt sie hinter den technischen Möglichkeiten zurück, weil für sie jede Anfrage nur einen uno-tempore Kontrollmechanismus (Kontrolle während des Zugriffs) zulässt. Im Folgenden soll gezeigt werden, wie ADOS-X durch Bereitstellung neuer Komponenten so umgestaltet werden kann, dass das System diverse Zugriffskontrollmechanismen unterstützt. Die Grundidee besteht darin, dass die Zugriffskontrolle durch das selektive Weiterleiten von Anfragen geregelt werden kann. In der zuvor beschriebenen Lösung geschieht dies manuell durch den Sachbearbeiter. Wenn er eine Anfrage zum Retoure-Postfach weiterleitet, dann bedeutet es, dass der Zugriff verweigert wurde. Durch den Sortierer kann das Weiterleiten automatisiert werden. Dabei stellt der Sortierer ein klassisches Zugriffskontrollsystem dar, auf dessen Konfiguration in Abschnitt 6.4.1 eingegangen wird. Zunächst werden wieder die Grundkomponenten vorgestellt. Aus diesen Grundkomponenten lässt sich die in Abbildung 6-4 dargestellte abstrakte Komponente, der KontrollAutomat, zusammensetzen. Auf die Funktionsweise des Kontroll-Automaten wird in Abschnitt 6.4.2 eingegangen. 90 FlexiBean Beschreibung Sortierer69: Mit dem Sortierer können die Anfragen weitergeleitet werden. Dazu besitzt der Sortierer einen Eingang und zwei Ausgänge, die jeweils an ein Postfach angeschlossen werden können. Je nach Einstellung der Sortierer wird ein Dokument aus dem Eingangs-Port in den OKbzw. in den KO-Port transportiert. Durch den Geändert-Port kann wie bei der Retoure-Komponente die Verarbeitung angestoßen werden. Kontingentierer: Der Kontingentierer zählt, wie viele Anfragen er bisher in einem bestimmten Zeitraum weitergeleitet hat. Ist das eingestellte Kontingent erreicht, leitet er die Anfrage in den KO-Port weiter. Ansonsten wird die Anfrage in die OK-Port geleitet. Durch den Geändert-Port kann, wie bei der Retoure-Komponente, die Verarbeitung angestoßen werden. Kopierer: Beim Kopierer kann man am Eingang-Port ein Postfach anschließen. Die Anfragen, die in diesem Postfach liegen, werden dann vom Kopierer dupliziert. Das Original wird dabei in das am Original-Port angeschlossene Postfach transportiert, die erstellte Kopie wird in das am Kopie-Port angeschlossene Postfach gelegt. Der Kopierer wird über ein Geändert-Event aktiviert. Tabelle 6-2 Grundkomponenten für eine erweiterte Zugriffskontrolle Der Kontroll-Automat (Abbildung 6-4) wird auf dem Evolve-Server erzeugt und kann dann eigenständig den Zugriff auf ADOS kontrollieren. Die Ports auf der linken Seite werden mit dem Visualizer verbunden. Über die Einstellung-Ports auf der rechten Seite können die Sortierer konfiguriert werden. Auch sie werden mit dem Visualizer verbunden, der dementsprechend angepasst werden muss. Ein Empfangsautomat kann an den Eingang, ein Versandautomat an den Ausgang angeschlossen werden. 69 Bei dem implementierten Prototypen heißt die Komponente MOVER. Die Bezeichnung „Sortierer“ hat jedoch den Vorteil, dass sie im Deutschen zwei Anwendungsmöglichkeiten ausdrücken kann. Die eine Anwendungsmöglichkeit, ist die E-Mail-Korrespondenz wie bei InfoLens mittels Regeln zu sortieren. Die andere Möglichkeit ist die Zugriffskontrolle. Hier werden durch die Komponente kritische Anfragen aussortiert. IMPLEMENTIERUNG DES PROTOTYPEN 91 Abbildung 6-4 Eine abstrakte Komponente, die eine erweiterte Zugriffskontrolle ermöglicht Die Visualizer-Komponente, wie in Abbildung 6-5 zu sehen, wurde dem Look&Feel bestehender Mailprogramme, wie dem Netscape Messanger, nachempfunden. Beim Visualizer werden die angeschlossenen Postfächer links unten angezeigt. Daraus kann eines ausgewählt werden, dessen Inhalt dann rechts unten angezeigt wird. Mit den unteren Buttons können Aktionen angestoßen werden, die sich auf die aus der Liste selektierte Anfrage beziehen. Der Öffne-Button öffnet ein Fenster, in dem die Anfrage bearbeitet werden kann. Die anderen Buttons transportieren die Anfrage in entsprechende Postfächer. Über den Menüpunkt Zugriffsverwaltung können die Einstellungswerkzeuge für die Sortierer geöffnet werden. Es erscheint dann ein Dialogfenster, wie es in Abbildung 6-7 zu sehen ist. Auf den internen Aufbau des Visualizers wird hier nicht eingegangen, weil sein Aufbau nicht im Schwerpunkt der Dekomposition stand. 92 Abbildung 6-5 Ein Screenshot des Visualizers für den Sachbearbeiter bei Bausig 6.4.1 Einstellmöglichkeiten der Sortierer-Komponente Bevor die Funktionsweise des Kontroll-Automaten erläutert wird, wird zuerst auf die Einstellmöglichkeiten der Sortierer eingegangen. Durch die Einstellung des Sortierers kann bestimmt werden, welche Anfrage automatisch beantwortet werden soll und welche nicht. Durch seine duale Entscheidungsmöglichkeit, KO oder OK, entspricht der Sortierer einem klassischen Zugriffskontrollsystem. Durch die Einstellung des Sortierers wird dabei die Zugriffsstrategie festgelegt. Prinzipiell kann man zur Modellierung des Sortierers auf die in Abschnitt 3.5 beschriebenen klassischen Zugriffsmodelle zurückgreifen. So ist in Abbildung 6-6 skizziert, wie eine Sortierer-Komponente aussehen könnte, die auf dem in Abschnitt 3.5.4 beschriebenen Zugriffsmodell von Stiemerling (1996) basiert. Über das SharedObject Systemzustand könnte der Sortierer den aktuellen Systemzustand ermitteln70. Bei Zugriffsmodellen mit negativen Rechten bietet es sich an, einen dritten Ausgang 70 Hier müsste jedoch zunächst ermittelt werden, was alles zum Systemzustand gehört und wie er als SharedObject zugänglich gemacht werden kann. Im vorliegenden Fall wäre es vermutlich der Zustand des elektronischen Archivs. IMPLEMENTIERUNG DES PROTOTYPEN 93 einzurichten. In diesen Ausgang werden alle Anfragen transportiert, wenn weder ein Verbot noch eine Erlaubnis vorliegt. Abbildung 6-6 Das Zugriffsmodell von Stiemerling, modelliert als Sortierer-Komponente Bei dem Prototyp wurde, vor allem um den Aufwand klein zu halten, nur ein rudimentärer Sortierer implementiert. Ein wichtiger Unterschied zum oben beschriebenen Sortierer besteht dabei darin, dass der Sortierer bei seiner Entscheidung, in welches Postfach er die Anfrage transportiert, nicht auf einen aktuellen Systemzustand zurückgreift. Er entscheidet allein aufgrund der eingestellten Regelmenge und den Informationen, die in der Anfrage enthalten sind. Bei den Faktoren für die Zugriffskontrolle, die in Abschnitt 5.5 erläutert sind, wurden nur die zwei in diesem Anwendungsfeld wichtigsten Gesichtspunkte berücksichtigt. So können Zugriffsregelungen beim Sortierer hinsichtlich der auszuführenden Operation und dem zugreifenden Subjekt spezifiziert werden. Aus der Sicht der externen Kooperationspartner sind die wichtigsten Operationen der Zugriff auf die eigentliche Zeichnung (“Anschauen von Zeichnungen”), der Zugriff auf die zu einer Zeichnung gehörigen, beschreibenden Daten (“Beschreibende Daten”) und die Sperrung einer Zeichnung für die Modifikationen (“Sperren von Zeichnungen”). Das Dialogfenster zur Einstellung eines Sortierers ist in Abbildung 6-7 zu sehen. Das Einstellen des Sortierers erfolgt dann in folgender Weise: Der Sachbearbeiter legt zunächst die Personen fest, die überhaupt für einen Zugriff in Frage kommen. Für diesen Personenkreis ist der Zugriff erstmal gesperrt, der Sachbearbeiter kann dann dem Einzelnen den Zugriff freischalten. Im Screenshot ist ein solches „Freischalten“ für den Zugriff auf beschreibende Daten dargestellt. Durch ein Klicken auf den „<“-Button würde die Person „Wulf“ von der Liste der gesperrten Personen auf die Liste der Personen geschoben, denen ein Zugriff gestattet ist. 94 Abbildung 6-7 Ein Screenshot der Einstellmöglichkeiten des Erlaubt-Sortierers Für den FlexiBean-Ansatz ist vor allem von Belang, dass der Sortierer ein Beispiel für eine Komponente darstellt, die eines eigenständigen Anpassungs-Werkzeugs bedarf. Ein solcher Fall wird momentan nicht von dem FlexiBean-Ansatz abgedeckt. In Abschnitt 7.2.2.2 wird ein Lösungsansatz vorgeschlagen. 6.4.2 Funktionsweise des Kontrollautomaten Die Funktionsweise des Kontrollautomaten soll anhand der verschiedenen Kontrollmechanismen, die sich durch ihn realisieren lassen, erläutert werden. 1. Fall „Über Zugriff wird vom Sachbearbeiter manuell entschieden!“ ADOS-X kann so konfiguriert werden, dass alle Anfragen vom Sachbearbeiter entschieden werden müssen. Dazu müssen die Sortierer ERLAUBT und PROTOKOLL so eingestellt werden, dass sie alle eingehenden Dokumente in den KO-Ausgang befördern. Dadurch wandert das Dokument, das sich im Postfach EINGANG befindet, erst mal in das NICHT ERL. Postfach, um von dort in das ANFRAGEN Postfach weitergeleitet zu werden. In dieser Einstellung entspricht der Kontroll-Automat dem in Abschnitt 6.3 beschriebenen System. 2. Fall „Zugriff ist erlaubt, er wird aber überwacht!“ Stellt man den PROTOKOLL Sortierer so ein, dass die Dokumente nicht in den KO-, sondern in den OK-Ausgang transportiert werden, werden die einzelnen Anfragen zur Ausführung an die ADOS-Datenbank weitergeleitet, aber der Sachbearbeiter erhält eine Kopie der Anfrage. Der Vorgang ist analog zu Fall 1, nur dass die Anfragen nun im Postfach ZUM KOPIEREN landen. Die Kopierer-Komponente leitet eine Kopie des Dokuments in das PROTOKOLL Postfach, das Original in das NACH ADOS Fach. Die ADOS-Komponente verarbeitet die Anfrage und leitet sie zum KONTIGENT Postfach weiter. IMPLEMENTIERUNG DES PROTOTYPEN 95 Dadurch, dass die Aktionen der Externen aufgezeichnet werden, sind sie für den zuständigen Mitarbeiter des Stahlwerks einer nachträglichen Kontrolle zugänglich. Mittels dieser Konfiguration wird ein „ex-post“-Kontrollmechanismus (nachträglich Kontrolle) realisiert. 3. Fall „Zugriff ist erlaubt“ Der Umweg über den Kopierer kann abgekürzt werden, indem man den ERLAUBTSortierer entsprechend einstellt. Dies geschieht dadurch, dass die Aktion für bestimmte Personen freigeschaltet wird. Darf der Ingenieur Meier beispielsweise Zeichnungen anschauen, so muss im Dialog beim Reiter „Zeichnung anschauen“ der Name Meier in die Liste der Freigeschalteten aufgenommen werden. Anfrage-Dokumente des Typs „Zeichnung anschauen“ von der Person Meier werden dann über den OK-Ausgang direkt an ADOS geschickt. Auf diese Weise wird ein klassischer „ex-ante“ Zugriffsmechanismus realisiert. 4. Fall „Beschränkung des automatischen Zugriffs durch die Festlegung eines Kontingents“ Wird die Anfrage automatisch bearbeitet (Fall 2 und 3) landet sie im KONTIGENT Postfach und wird, bevor sie an den Ausgang weitergeleitet wird, vom Kontingentierer erfasst. Durch das Einstellen des Kontingentierers auf z.B. 10 Anfragen pro Tag, kann der automatische Zugriff durch den Externen auf ein festgelegtes Maß reduziert werden. Dies verhindert, dass das elektronische Archiv von außen „leergesaugt“ wird. Ist das Kontingent erreicht, dann werden die Anfragen im KONTIGENT Postfach nicht mehr zum Retoure-Postfach sondern zum „Kontingent überschritten“-Postfach transportiert. Hier kann es dann manuell durch den Sachbearbeiter zurückgeschickt werden. 96 97 7 EVALUATION Durch den Prototyp sollte geklärt werden, wie sich mit Hilfe der durch den FlexiBeanAnsatz gegebenen Modellierungsmöglichkeiten eine für den Endbenutzer verständliche Dekomposition realisieren lässt. Die Realisierung diente dabei auch der Evaluation des FlexiBean-Ansatzes. Der Frage, ob der Prototyp eine angemessene und verständliche Dekomposition besitzt, wird in Abschnitt 7.1 nachgegangen. Abschnitt 7.2 geht auf Modellierungsschwierigkeiten ein, die bei der Entwicklung des Prototyps auftraten. Dieser Abschnitt bietet einen Ausblick darauf, wo beim FlexiBean-Ansatz noch Erweiterungsbedarf besteht. Der Abschnitt geht auch auf das noch nicht befriedigend gelöste Problem ein, wie sich anpassbare WAM-Werkzeuge und WAM-Materialien durch FlexiBeans realisieren lassen. 7.1 Evaluation des Prototyps Bei der externen Evaluation des Prototyps beschränke ich mich auf die Dekomposition der erweiterten Zugriffskontrolle. Bei der Evaluation der Anpassbarkeit aus der Sicht des Benutzers übernehme ich die von Stiemerling, Won und Wulf (2000) getroffene Unterscheidung in Repräsentation, Präsentation und Manipulation (vgl. dazu Abschnitt 3.5.5). Bei der Repräsentation geht es darum, dass die Anwendung flexibel genug ist, so dass darin alle für den Anwendungskontext relevanten Änderungswünsche vollzogen werden können. Die Präsentation soll dem Benutzer das aktuelle System zugänglich machen. Deshalb soll die Präsentation so sein, dass er erstens die, der Anwendung zugrunde liegende, Dekomposition und das daraus resultierende Verhalten des Systems versteht und er zweitens die Unterschiede zwischen dem tatsächlichen und dem von ihm intendierten Verhalten erkennen kann. Die Manipulation sollte so gestaltet sein, dass das System einfach und effizient während der Nutzung des Systems an die Arbeitssituation angepasst werden kann. Die Evaluation basiert dabei auf der im Vorfeld gesammelten Empirie, der Diskussion anhand eines Papier MockUps und einer Live-Vorführung des Prototyps auf einem Workshop und auf Test mit Personen außerhalb des OrgTech-Projekts. Der Papier MockUp wurde zum einen mit zwei Sachbearbeitern von Bausig, zum anderen mit einem Fremddienstleister diskutiert. Bei dem Workshop waren verschiedene Abteilungen von Bausig und ein Fremddienstleister anwesend. Die Diskussion des Papier MockUps mit den internen Sachbearbeitern sollte klären, ob die Dekomposition verständlich ist. Außerdem sollte überprüft werden, ob die Dekomposition aus der Sicht der Sachbearbeiter die gewünschte Funktionalität besitzt. Bei der Diskussion mit dem externen Konstrukteur ging 98 es hauptsächlich um den letzten Punkt. Beim Workshop ging es darum, zu sehen, wie die konfligierenden Parteien auf den Prototypen reagieren und ob die vom Prototypen angebotenen Kompromissmöglichkeiten von den Beteiligten aufgenommen werden. 7.1.1 Repräsentations-Ebene Bei der Evaluation auf der Repräsentations-Ebene gilt es zu klären, ob die in Abschnitt 6.3 beschriebene Dekomposition für das Anwendungsfeld die gewünschte Flexibilität bereithält. Dabei müssen im Falle von gruppenwirksamer Anpassbarkeit nicht nur die Wünsche der Benutzer und der von der Anpassung betroffenen Personen berücksichtigt werden, sondern auch für die konfligierenden Interessen Wege bereitgestellt werden, die eine Kompromisslösung unterstützen. Im Falle des OrgTech-Projekts liegen die unterschiedlichen Interessen, wie in Kapitel 1 dargelegt, beim Zugriff auf das elektronische Archiv. Diese kamen auch bei der Vorstellung des Prototyps zum Vorschein. Bei der Diskussion der Funktionalität am Papier MockUp mit dem Mitarbeiter eines externen Büros meinte dieser, dass für die Externen die Arbeit durch einen lesenden Zugriff auf das Archiv vereinfacht werde. Im Gegensatz dazu wurde von den Sachbearbeitern hervorgehoben, dass für sie wichtig sei, dass die Kontrolle bei Bausig und bei den Sachbearbeitern verbleibe. Für sie ist entsprechend eine Lösung aus Abschnitt 6.3 ausreichend, solange die durch die „manuelle“ Zugriffskontrolle entstehende Mehrarbeit von Bausig honoriert wird. Die unterschiedlichen Vorstellungen traten auch bei der Präsentation des Prototyps auf dem Workshop hervor. So bemängelte der Vertreter der Externen, dass die Einstellmöglichkeit bei der der interne Sachbearbeiter jeden einzelnen Zugriff erlauben muss, nicht den Vereinbarungen entsprach, die anfänglich ausgemacht waren. Ein interner Sachbearbeiter verteidigte diesen Zugriffsmodus damit, dass die Kontrolle bei Bausig verbleiben müsse. Die Extrempositionen, die sich gegenüberstanden, waren dabei nicht „erlaubt“ versus „verboten“ sondern „automatischer Zugriff“ versus „manuelle Kontrolle“. Die vermittelnde Instanz, der protokollierte Zugriff71, wurde von keiner der Parteien abgelehnt, jedoch wurde sie auch nicht als mögliche Kompromisslösung aufgenommen. Die Analyse des Anwendungsfelds legt die Vermutung nahe, dass die Beteiligten zu diesem Zeitpunkt zu einer Kompromisslösung keine Stellung beziehen wollten, und sie sich deshalb nicht genauer mit dem Mechanismus beschäftigten. Somit konnte auf dem Workshop nicht geklärt werden, ob die Möglichkeiten, die sich durch den Prototyp ergeben, auch in der Praxis angewendet werden. Für die Evaluation reicht es an dieser Stelle aber aus, dass der Prototyp an einer für die Praxis notwendigen 71 Der kontingentierte Zugriff ergab sich erst aus der nachträglichen Analyse des empirischen Materials und stand deshalb nicht als möglicher Kompromiss zur Verfügung. EVALUATION 99 Stelle anpassbar ist. Bei der Telekooperationslösung geht es entsprechend darum, wie gut das System Kompromisse zwischen den Extrempositionen unterstützt. Hier wäre sowohl ein System, das nur eine klassische Zugriffskontrolle implementiert, als auch ein System, bei dem der Zugriff immer neu ausgehandelt werden muss, zu unflexibel. Dagegen unterstützt, wie in Kapitel 1 gezeigt, die durch den Prototyp umgesetzte, erweiterte Zugriffskontrolle die Beteiligten besser, einen für beide Seiten tragfähigen Kompromiss umzusetzen. 7.1.2 Präsentations-Ebene Bei der Evaluation auf der Präsentations-Ebene gilt es zu klären, ob die Dekomposition und das daraus resultierende Systemverhalten verständlich sind. Im vorliegenden Fall muss man bei der Evaluation versuchen, die Frage der Präsentation von der vorher beschriebenen Repräsentation zu trennen. Mit den Sachbearbeitern wurde die Dekomposition, die in Anhang A beschrieben ist, anhand eines Papier MockUps diskutiert. Die Diskussion diente unter anderem dazu, herauszufinden, ob die Dekomposition von den zukünftigen Benutzern, also den internen Sachbearbeitern, erfasst wurde. Im Nachhinein hat es sich allerdings als ungünstig erwiesen, bei der Diskussion des Papier MockUps aus „Effizienzgründen“ die Frage nach der Präsentation mit der Frage der Repräsentation zu koppeln. Denn bei der Frage der Präsentation sollte der Sachbearbeiter möglichst davon absehen, dass der Prototyp an seinem Arbeitsplatz eingeführt wird72, damit er nicht die Dekomposition unter interessenbezogenen Gesichtpunkten betrachtet. Im Gegensatz dazu fordert die Frage nach der Repräsentation den Benutzer dazu auf, sich vorzustellen, wie seine Interessen in einem zukünftigen System berücksichtigt werden können. So zeigte sich in der Diskussion, dass sich die Sachbearbeiter eine zukünftige Nutzung nur schwer vorstellen können, aber nach eigenem Bekunden die Dekomposition verstehen. Um Herauszufinden, ob es sich um eine allgemeinverständliche Dekomposition handelt, wurde sie noch mit insgesamt fünf Personen außerhalb des OrgTech-Projekts getestet. Damit bot sich die Möglichkeit an, die durch die Analyse gewonnenen Erkenntnisse in die Evaluation mit einzubeziehen. Deshalb wurde nicht die Dekomposition aus Anhang A, sondern die erweiterte Dekomposition aus Abschnitt 6.4 (Seite 91) getestet. Da sich in den ersten beiden Tests zeigte, dass die kryptische Benennung der Komponenten und die doppelten Verbindungen zwischen Postfächern und Sortierern die Tests erschwerten (was 72 Für die Evaluation in diesem Punkt wäre der ideale Proband eine Person mit gleicher Qualifikation und ähnlichen Arbeitsaufgabe außerhalb des OrgTech-Projekts. 100 zu Nachfragen führte), wurde die Dekomposition zu der in Anhang B dargestellten verändert73. Die Tests lehnten sich an die „Thinking-Aloud“-Methode an, deren wesentliche Elemente in Nielsen (1992) beschrieben sind. Die Grundidee der Methode ist, den Probanden konkrete Aufgaben zu stellen und sie dann während des Tests anzuhalten, über ihre Handlungen zu sprechen und ihre Gedanken bei der Lösungsfindung laut zu äußern. Hinsichtlich des Qualifikationsniveaus der Probanden lassen sich die Tests wie folgt einteilen: Die Test mit der Dekomposition aus Abschnitt 6.4 (Seite 91) wurden mit Studenten anderer Fachrichtungen (durchschnittlichen Computernutzern) durchgeführt. Die Dekomposition von Abschnitt B wurde mit einem Informatikstudenten (Computerexperte), einem Studenten aus einem anderen Fachbereich (durchschnittlicher Nutzer) und einer Person getestet, die sich selbst als Computerlaie bezeichnet. Die Grundlage der Tests war ein Papier MockUp, der auf der Dekomposition aus Abschnitt 6.4 bzw. aus Anhang B beruhte. Zu Anfang der Tests wurde die Bedeutung der einzelnen Grundkomponenten erklärt und die Dekomposition ähnlich wie in Abschnitt 6.4.2 erläutert. Die Funktionsweise wurde anhand des Verlaufs einer Beispielanfrage durch die Dekomposition illustriert. Nach dieser kurzen Erläuterung, wurden zwei Kontrollaufgaben gestellt: 1. Wie kann die Dekomposition so eingestellt werden, dass alle Anfragen mitprotokolliert werden? 2. Wie kann die Dekomposition so eingestellt werden, dass auch die Antworten der Anfragen mitprotokolliert werden? Diese erste Aufgabe zielte darauf ab, ob die Einstellungsmöglichkeiten verstanden wurden. Dekomposition neu verdrahtet werden. Damit Dekomposition als Ganzes verstanden hatten, verändern. Funktionsweise der Sortierer und seine Bei der zweiten Aufgabe musste die wurde getestet, ob die Probanden die und ob sie in der Lage waren, sie zu Die gemachten Beobachtungen wurden zu fünf Thesen zusammengefasst: 1. Die herkömmliche Bedeutung wird auf die Dekomposition übertragen. 2. Die Benennung von Ports und Komponenten tragen stark zum Verständnis bei. 73 Bei der Dekomposition wurde auch ein linearer Aufbau gewählt, damit bei der Erfassung der Bedeutung möglichst nur der unmittelbare Kontext betrachtet werden muss. EVALUATION 101 3. Verbindungen und Ports, die keine unmittelbare Bedeutung haben, wirken verwirrend. 4. Dass zwischen zwei Sortierern ein Postfach geschaltet werden muss, wird als nicht intuitiv angesehen. 5. Für die Sachbearbeiter der internen Konstruktionsabteilung liegt die Schwierigkeit darin, sich eine neue Kooperationspraxis vorzustellen. Insgesamt lässt sich feststellen, dass die Thesen eine gewisse Plausibilität besitzen. Es bedarf aber noch weiterer, systematische Untersuchungen, um von gesicherten Thesen zu sprechen. Die herkömmliche Bedeutung wird auf die Dekomposition übertragen: Die Stärke bei der Verwendung des WAM-Ansatzes besteht darin, die Komponenten an die Alltagswelt anzuknüpfen. Dadurch wird es dem Benutzer ermöglicht, die Bedeutung aus der Alltagswelt auf die Komponenten zu übertragen. Bei den Tests drückte sich dies darin aus, dass ein Proband beim Zusammenstecken sagte: „Dann verbinde ich die Kopie des Kopierers mit dem Postfach oder das Original? Ach, eigentlich egal.“ Die Aussage ist interessant, da sie zeigt, dass die Funktionsweise der Kopierer-Komponente erfasst wurde. Der Komponente wird aber nicht die Bedeutung eines üblichen Kopierers zugeschrieben, sondern es wird schon von einer elektronischen Kopie ausgegangen, die mit dem Original identisch ist. Entsprechend muss man bei der Modellierung nach dem WAM-Ansatz aufpassen, dass die Übertragung der üblichen Bedeutung(en) auf die Komponente nicht zu einem antiquierten Verständnis führt. Die Benennung von Ports und Komponenten tragen stark zum Verständnis bei: Die Benennung spielt eine wichtige Rolle beim im Verständnis der Dekomposition. Zum einen liegt das daran, dass der Benutzer bei einer atomaren Komponente nicht hineinschauen kann bzw. will, um herauszufinden was die Komponente tut. Zum anderen erlaubt es eine gute Bezeichnung, dass die Bedeutung der Komponente direkt erfasst wird, ohne auf den umliegenden Kontext zu schauen. Bei den ersten Tests fiel dies z.B. negativ bei den Namen der Sortierer auf. So stellt das Wort „Erlaubt“ bzw. „Protokoll“ nur eine starke Verkürzung von „Prüfe, ob der Anfrage ein direkter Zugriff auf ADOS erlaubt ist“ und „Prüfe, ob der Anfrage ein protokollierter Zugriff auf ADOS erlaubt ist“ aus. Durch die verkürzte Bezeichnung konnte die Aufgabe, die die beiden Sortierer erledigen, nicht mehr ausdrückt werden. Dies zeigt sich daran, dass die Arbeitsweise der beiden Sortierer näher erläutert werden musste. 102 Da es aber nicht immer möglich ist, ein aussagekräftiges Schlagwort für eine Komponente zu finden, spricht dies dafür, die in Abschnitt 7.2.5 geforderte Annotierbarkeit von Komponenten, Ports und Verbindungen einzuführen. Verbindungen und Ports, die keine unmittelbare Bedeutung haben, wirken verwirrend: Komponenten, Ports und Verbindungen die im Anpassungskontext keinen unmittelbaren Zweck haben, wirken bei der Anpassung eher störend und verwirrend. So lenkten die nach außen führenden Verbindungen und die dazugehörigen Ports erstmal von der eigentlichen Aufgabe ab. Auch wirkte die Verbindung zur Eventverarbeitung zwischen dem Geändert-Port des Sortierers und dem Geändert-Port des Postfachs verwirrend. Dies liegt wahrscheinlich daran, dass diese Verbindung technisch motiviert ist. Für den vorliegenden Fall könnte, wie in Anhang B dargestellt, diese Verbindung mit der SharedObject-Verbindung zusammengezogen und dem Benutzer als alleinige Verbindung angeboten werden. In diesem Punkt zeigt sich, dass Steckverbindungen eine sinnvolle Erweiterung des FlexiBean-Ansatzes darstellen (vgl. 7.2.5). Auch sind benutzerspezifische Anpassungsumgebungen sinnvoll, die je nach Qualifikation des Anpassers und durchgeführte Anpassungsaufgaben bestimmte Komponenten, Ports und Verbindungen ausblenden, wenn sie für den Anpassungsprozess nicht notwendig sind. Dass zwischen zwei Sortierern ein Postfach zwischengeschaltet werden muss, wird als nicht intuitiv angesehen: Beim Einbau des zusätzlichen Kopierers in die Dekomposition muss zusätzlich ein Hilfspostfach eingebaut werden74. Dies wurde als störend empfunden, da dies nichts mit der eigentlichen Aufgabe zu tun hatte. Um dem Anwender einen intuitiveren Zugang zu ermöglichen, sollten die verarbeitenden Komponenten, wie Kopierer und Sortierer, erweitert werden, so dass es möglich ist, sie in Reihe zu schalten. Für die Sachbearbeiter der internen Konstruktionsabteilung liegt die Schwierigkeit darin, sich eine neue Kooperationspraxis vorzustellen: Insgesamt kann man festhalten, dass von den Probanden die Funktionalität der Grundkomponenten erfasst wurde. Sie konnten auch das aus der Dekomposition resultierende Systemverhalten nachvollziehen. Da auch die Sachbearbeiter nach eigenem Bekunden die Dekomposition verstanden, kann 74 Der Grund liegt darin, dass ein SharedObject-Client nur mit einem Provider verbunden werden darf. Da Sortierer nur SharedObject-Clients besitzen, können sie nicht direkt verbunden werden. An dieser Stelle zeigte aber auch eine technische Herangehensweise des Informatikstudenten. Er merkte beim Umstecken der Komponenten zu den Postfächern an: „Das ist wohl eine Designentscheidung, dass die E-Mail immer zwischengespeichert wird.“ EVALUATION 103 man vermuten, dass eine für den Endbenutzer verständliche Dekomposition gefunden wurde. Die Schwierigkeiten für die Sachbearbeiter sich eine Nutzung vorzustellen, müssten dann woanders liegen. Ein Grund für die Schwierigkeiten könnte darin bestehen, dass die Sachbearbeiter sich nicht zugleich eine neue Anwendung, eine durch die veränderte Zugriffskontrolle neue Kontrollpraxis und eine durch die Virtualisierung neue Kooperationsform vorstellen können. Abschnitt 7.1.4 zeigt, wie durch evolutionäre Entwicklung diese Gleichzeitigkeit entkoppelt werden könnte. 7.1.3 Manipulations-Ebene Eine Evaluation auf der Manipulations-Ebene hätte zu klären, ob durch die Anpassungsumgebung die Dekomposition einfach an Bedürfnisse angepasst werden kann. Da hierin nicht der Schwerpunkt der Arbeit lag und entsprechend nicht evaluiert wurde, kann hierzu keine Aussage gemacht werden. 7.1.4 Komponentenbasierte Anpassbarkeit und evolutionäre Entwicklung Ein anderes Vorgehen, um mit dynamischen und unsicheren Anforderungen im Softwareprozess umzugehen, besteht im evolutionären Entwickeln, wie es z.B. auch von Floyd, Reisin und Schmidt (1989) propagiert wird. Auch im vorliegenden Fall bietet es sich an, zunächst nur die in Abschnitt 6.3 beschriebene Lösung zu entwickeln. Diese erlaubt es, den Prototypen ohne die Dynamik des Aushandlungsprozesses und die damit verbundenen Sicherheitsaspekte im Anwendungsfeld einzuführen und zu testen. Dies entkoppelt die Einführung einer neuen Kooperationsform von der Einführung einer neuen Kontrollpraxis. Die Dekomposition aus Abschnitt 6.4 zeigt, dass die eingeführte Lösung zu einem System mit erweiterter Zugriffskontrolle ausgebaut werden kann. Hierbei offenbart sich ein Vorteil der FlexiBeans, die durch den Komponentenaufbau die evolutionäre Entwicklung unterstützten. Dies zeigt sich auch darin, dass bei dem implementierten Prototypen ohne großen Aufwand eine Kontrolle durch Kontingentierung mittels der Kontingentier-Komponente integriert werden kann. 104 7.1.5 Resümee Aufgrund der Evaluation des Prototyps kann man vermuten, dass die erweiterte Zugriffskontrolle einen für die Praxis relevanten Punkt darstellt, und dass hier eine für den Endbenutzer verständliche Dekomposition gefunden wurde. Die Verständlichkeit der Dekomposition liegt wahrscheinlich daran, dass, sämtliche Bestandteile der Dekomposition, wie Komponenten, Ports und Verbindungen, sich leicht mit Hilfe der Anfrage-E-Mail illustrieren lassen und dass eine E-Mail für den Anwender ein verständliches Objekt ist. In diesem Punkt kann man sagen, dass die Verwendung des WAM-Ansatzes sich bewährt hat. Die Fallstudie zeigt aber auch die Grenzen des WAM-Ansatzes auf. Den automatischen Zugriff der Externen auf das Archiv, der eine echte Transformation der Arbeitspraxis bedeutet, können sich die Sachbearbeiter trotz verständlicher Dekomposition nicht wirklich vorstellen. Für die Methodik der Anforderungserhebung und damit auch für die Evaluation wirft die Fallstudie die Frage auf, wie mit Interessenskonflikten umgegangen werden soll, zumal der Entwickler durch das Softwaresystem in diesen Konflikt interveniert. 7.2 Erweiterung des FlexiBean-Ansatz Im Folgenden werden einige Erweiterungsvorschläge des FlexiBean-Ansatzes erläutert. Abschnitt 7.2.1 widmet sich dem Problem, wie der Zustand einer Komponente gespeichert werden kann. In Abschnitt 7.2.2 wird die Idee der reflexiven Komponenten eingeführt. Es wird gezeigt, wie sich damit anpassbare WAM-Werkzeuge und anwendungsspezifische Anpassungsumgebungen realisieren lassen. Abschnitt 7.2.3 erläutert die Schwierigkeiten, die bei der Modellierung von anpassbaren WAM-Materialien entstehen. Den Abschluss bilden der Abschnitt über die Semantik der SharedObjects und ein Abschnitt in dem weitere Erweiterungsvorschläge stichpunktartig zusammengefasst werden. 7.2.1 Persistenz und Identität einer Komponenteninstanz Problembeschreibung: Bei ADOS-X ergab sich das Problem, dass die Anfragen, die in den Postfächern lagen, nach dem Herunterfahren der Evolve-Plattform nicht verloren gehen durften. Ein ähnliches Problem ergab sich bei der Speicherung der (Aus-)Sortierungsstrategien des Sortierers, auf die ich aber im nächsten Abschnitt gesondert eingehe. Allgemein formuliert besteht die Aufgabe darin, bei einer Komponenteninstanz, neben der durch das CAT-File gegebenen Konfiguration, den Zustand einer Instanz oder Teile davon persistent zu machen. EVALUATION 105 Implementierte Modellierung: Bei ADOS-X wurde der Inhalt der Postfächer außerhalb der Evolve-Plattform abgespeichert. Um den Persistenz-Mechanismus von der Postfachlogik zu trennen wurde eine eigene Komponente, das FileArchiv eingeführt. Das Zusammenspiel der beiden Komponenten ist in Abbildung 7-1 zu sehen. In der Abbildung kann man auch das Verfahren dieser Modellierung erkennen. import java.rmi.*; public interface Store extends Remote { void saveMsg(Msg msg, String postfachID) throws RemoteExpection, StoreException; void deleteMessage(Msg msg, String pfID) throws RemoteExpection, StoreException; void Msg[] loadMessages(String pfID) throws RemoteExpection, StoreException; } Abbildung 7-1 Persistenz-Mechanismus bei ADOS-X. Links die beteiligten Komponenten, rechts die Schnittstelle, über die die beiden Komponenten gekoppelt sind Um den Speicherort eines Postfachs von dem Speicherort eines anderen Postfachs zu unterscheiden, bedarf es einer Postfach-ID75. Die einzige Möglichkeit diese ID innerhalb der Evolve-Plattform zu speichern besteht darin, sie als eine Property der Komponente künstlich einzuführen. Schwachstellen der Modellierung und alternative Lösungsansätze: Beim FlexiBeanAnsatz ist es nicht möglich, Constraints an die Architektur zu stellen. Deshalb kann nicht verhindert werden, dass mehrere Postfächer die gleiche ID besitzen und damit bei einem Neustart die gleichen Anfragen laden, was unter anderem eine Sicherheitslücke darstellt. Aus diesem Grund sollte der FlexiBean-Ansatz einen eigenständigen PersistenzMechanismus besitzen. Die minimale Anforderung an einen solchen Mechanismus ist die, dass eine Komponente einen „archimedischen Punkt“ besitzt. Dieser könnte in einer für jede Instanz eineindeutigen und unveränderlichen ID bestehen76. Das Modell der Enterprise JavaBeans (EJB) setzt sich mit der Persistenz von Komponenten auseinander. Deshalb soll hier näher darauf eingegangen werden. Der EJBAnsatz wurde für die Modellierung von Server-Applikationen, wie z.B. Online-Shops, entwickelt, bei denen viele User die gleiche Anwendung mit unterschiedlichem Inhalt ausführen. Der Persistenz-Mechanismus der EJBs lässt sich jedoch nicht ohne weiteres auf die FlexiBeans übertragen. Denn ein grundlegender Unterschied zwischen EJBs und 75 Würde das Postfach sich selbst abspeichern, bedürfte es ebenfalls einer ID um herauszufinden, wo es sich hingespeichert hat. 76 Die Eineindeutigkeit der ID könnte prinzipiell auch dadurch erreicht werden, dass der FlexiBean-Ansatz anwendungsspezifische Constraints erlaubt, wie in Abschnitt 7.2.5 kurz erläutert wird. 106 FlexiBeans besteht darin, dass beim EJB-Ansatz Komponenten nicht auf der Instanz-, sondern auf Typ-Ebene verdrahtet werden77. Erst zur Laufzeit wird ermittelt, welche Instanzen miteinander verbunden werden. Dabei gibt es zwei Arten von Komponententypen: SessionBeans und EntityBeans. Hier sind vor allem die EntityBeans interessant, denn sie zeichnen sich dadurch aus, dass ihre Instanzen einen persistenten Zustand haben. Typischerweise repräsentieren sie Daten aus einer Datenbank. Bei den EntityBeans unterscheidet man nochmals zwischen den Beans, die ihre Persistenz selbst verwalten und jenen, bei denen dies durch die Umgebung geschieht. Im Folgenden werde ich mich auf den ersten Fall beschränken. Die Spezifikation schreibt vor, dass eine EntityBean eine Menge von Methoden implementieren muss, die man in die Bereiche Zustandsmanagement, Identitätsverwaltung und Anwendungslogik aufteilen kann. Das Zustandsmanagement ist unter anderem für das Wiederherstellen einer persistenten Bean verantwortlich. Es besteht dabei aus drei Phasen: 1. das Erzeugen der Komponente, 2. das Identifizieren und 3. das Laden des Zustands. Das Identifizieren geht mit Hilfe einer der EntityBean zugeordneten Klasse, die die Identität bzw. den Primarykey (PK) einer Instanz darstellt. Mit der Identitätsverwaltungs-Methode ejbCreate wird ein Primarykey geschaffen. Dabei ist die Komponente selbst dafür verantwortlich, dass der PK eineindeutig ist. Der Primarykey steht über den EntityContext zur Verfügung. Hierüber greift die Zustandsmanagement-Methode Load zu, um den Zustand zu laden. Den Primarykey speichert sich der Client einer EntityBean, um zu einem späteren Zeitpunkt die EntityBean über die Identitätsverwaltungs-Methode ejbFindByPrimarykey wieder zu finden. Daneben kann ein EntityBean noch weitere Find-Funktionen haben, um eine Instanz zu identifizieren. So kann z.B. eine KundenBean eine ejbFindByKundenNummerMethode besitzen. Der Client greift jedoch nicht auf die EntityBean direkt zu, sondern stellt seine Anfrage an die EJB-Plattform, auch Application-Server genannt, und bekommt von dieser ein Proxy-Objekt auf die Bean zurück. Bei der Übertragung der Idee auf den FlexiBean-Ansatz fallen wegen der instanzorientierten Verdrahtung die find-Methoden durch den Client weg. Was sich aber übernehmen lässt, ist die Idee der serialisierbaren Primarykey-Klasse. Bei der Generierung des Primarykeys sollte es neben dem Fall, ihn von der Komponente selbst generieren zu lassen, auch die Möglichkeit geben, dass die Evolve-Plattform eine eineindeutige ID erzeugt. 77 Dieser Unterschied resultiert daraus, dass die Anpassbarkeit für den Server-Administrator, in der EJBSpezifikation auch Deployer genannt, und nicht für den Endbenutzer, im Falle eines Online-Shops also den Kunden, ausgelegt ist. EVALUATION 107 Daneben muss bei der Entwicklung eines Persistenz-Mechanismus geklärt werden, wie eine Komponente auf die ID zugreifen kann. Dabei sind zwei Methoden vorstellbar. Bei der ersten Methode wird die Verbindung zwischen Plattform und Komponente nicht explizit in der Architektur angezeigt. Diese Methode ist analog zum EJB-Ansatz und verlangt, dass eine persistente Komponente ein bestimmtes Interface implementiert. Über dieses Interface kann die Evolve-Plattform den Kontext der Komponente setzen, worüber die Komponente ihre ID erfragen kann. Bei der anderen Methode wird die Verbindung explizit angezeigt und kann durch die, im nächsten Abschnitt dargestellten, reflexiven Komponenten realisiert werden. Hier kann eine Komponente auf ihre eigene Repräsentanz in der Evolve-Plattform zugreifen. Dadurch ist es prinzipiell möglich, dass eine Komponente auf ihre eineindeutige ID zugreifen kann. Da aber der EJB-Ansatz schon ein Konzept für den gesamten Lebenszyklus einer persistenten Komponente und ein Protokoll dafür besitzt, wie die Übergänge im Zyklus zu realisieren sind, bietet es sich an, sich weitgehend an den EJB Persistenz-Mechanismus zu halten. Ein noch genauer zu untersuchendes Phänomen entsteht durch persistente FlexiBeans, bei denen sich der persistente Zustand aus zwei Teilen zusammensetzt. Der eine Teil des Zustands ist durch die Konfiguration im CAT-File gegeben, der andere wird außerhalb der Evolve-Plattform gespeichert. Damit stellt sich die noch zu beantwortende Frage, was passieren soll, wenn eine angepasste Anwendung, die momentan durch das CAT-File gegeben ist, mit einem Kollegen ausgetauscht wird. 7.2.2 Reflexive Komponenten Die Reflexivität des FlexiBean-Modells beschränkt sich darauf, nur dem Benutzer die Systemarchitektur durch eine Anpassungsumgebung zugänglich zu machen. Aus einer Komponente heraus, kann auf die Architektur nicht zugegriffen werden. Dies könnte dadurch geändert werden, dass die Evolve-Plattform die Kompositionsstruktur nicht nur der Anpassungsumgebung, sondern auch den Komponenten zur Verfügung stellt. Dies führt zu dem Modell einer reflexiven Komponente. Definition einer reflexiven Anpassungs-Komponente i) Eine FlexiBean heißt reflexiv, wenn sie auf ihre eigene durch die EvolvePlattform gegebene Repräsentation zugreifen kann. ii) Eine FlexiBean ist eine reflexive Anpassungs-Komponente, wenn sie zusätzlich noch auf die Kompositionsstruktur zugreifen und die sie anpassen kann. 108 Technisch kann eine reflexive Anpassungskomponente dadurch realisiert werden, dass im CAT-File auf die Evolve-Plattform als eine atomare Komponente verwiesen werden kann. Die Evolve-Komponente stellt dabei ein SharedObject, in Abbildung 7-2 EVOLVEContext genannt, zur Verfügung, über dass zum einen eine Komponente auf ihre eigene Repräsentation zugreifen kann, zum anderen ermöglicht das SharedObject auf der Kompositionsstruktur zu navigieren und sie anzupassen. Dabei kann auf die schon vorhandene Tailoring-API aufgebaut werden. reflexive Anpassungs-Bean EVOLVEContext EVOLVEContext EVOLVE Abbildung 7-2 Realisierung von reflexiven Anpassungs-Komponenten durch eine atomare EvolveKomponente 7.2.2.1 Anpassbare WAM-Werkzeuge Ein Problem beim FlexiBean-Ansatz besteht darin, dass mit ihm keine anpassbaren WAMWerkzeuge modelliert werden können. Dies liegt daran, dass Werkzeuge in Abhängigkeit der Materialien dynamisch erzeugt werden. Bei ADOS-X stellte sich das Problem so dar, dass eine Anfrage-E-Mail (WAM-Material) in einem eigenen Fenster78, (WAM-Werkzeug) bearbeitet werden kann. Da in einem Postfach unbegrenzt viele E-Mails liegen können, ist es auch möglich, unbegrenzt viele Werkzeuge zu öffnen. Da aber der FlexiBean-Ansatz keine Möglichkeit besitzt aus einer Komponente eine neue FlexiBean zu erzeugen, kann das Werkzeug nicht durch ein CAT-File beschrieben werden. Bei der Implementierung hat das zur Konsequenz, dass das Fenster anpassbar ist. Lösungsansatz: Die Abbildung 7-3 zeigt, wie mit Hilfe der reflexiven AnpassungsKomponente es technisch möglich ist, anpassbare Werkzeuge zu modellieren. Abbildung 7-3 Abstrakte Komponente, die anpassbare Mini-Applikationen ermöglicht 78 Ein solches Fenster ist im oberen Teil von Abbildung 6-5 zu sehen. EVALUATION 109 Die zentrale Komponente der Modellierung ist die reflexive Anpassungs-Komponente MiniApp. Am Port JDesktop79 kann ein SharedObject angebunden werden, dass eine graphische Oberfläche besitzt, auf der die Mini-Anwendungen angezeigt werden. JComp bietet ein Objekt an, in das graphische Komponenten eingehängt werden können. Die Ports Start und Exit dienen dazu, eine Mini-Applikation zu starten bzw. zu beenden. Das Starten bewerkstelligt die MiniApp-Komponente wie folgt: Zuerst besorgt sie sich die sie umschließende, abstrakte Komponenteninstanz. In Abbildung 7-3 ist dies die ViewerApp-Komponente. Von dieser Instanz erzeugt sie eine neue Kopie. Anschließend werden die Ports der Kopie so verbunden, dass die Verbindungen denen des Originals entsprechen. Diese Verbindungen stellen die Anbindung einer Mini-Applikation an den Kontext her. Ist z.B. der Erlaubt-Port der ViewerApp an ein Postfach angeschlossen, so teilen sich alle durch die MiniApp gestarteten ViewerApps dieses Postfach. Für den Fall, dass die abstrakte Komponente ein SharedObject anbietet, wird jedoch diese Verbindung nicht dupliziert. Denn der gegenüberliegende SharedObject-Client kann nur höchstens mit einem Provider verbunden werden. Dieser Fall ist jedoch keine große Einschränkung, weil mit dieser Konstruktion WAM-Werkzeuge modelliert werden sollen, die hauptsächlich SharedObjects benötigen. Das Beenden erfolgt so, dass die MiniApp sich wieder die, sie umschließende, Komponente, die ViewerApp, geben lässt und diese von der Evolve-Plattform entfernt. Das hat zur Folge, dass die MiniApp sich selbst löscht. Dies gilt es bei der Umsetzung des Lösungsansatzes zu beachten. 7.2.2.2 Anwendungsspezifische Anpassungsumgebung Mittels reflexiven Anpassungs-Komponenten können auch anwendungsspezifische Anpassungsumgebungen bzw. Anpassungswerkzeuge realisiert werden. Bei der Implementierung von ADOS-X taucht das Problem auf, dass die (Aus-)Sortierstrategie nur dann im CAT-File gespeichert werden kann, wenn sie eine Property der Komponente ist. Das bedeutet aber, dass sie 1. in einen String verwandelt werden muss und 2. die Sortierstrategie nur über die 3D-Anpassungsumgebung geändert werden kann. Beides zusammen ist nicht sehr anwenderfreundlich. Deshalb wurde bei ADOS-X die Zugriffsstrategie außerhalb des CAT-Files in einer Datenbank gespeichert mit den in Abschnitt 7.2.1 beschriebenen Problemen. Die Strategie konnte durch ein AnpassungsWerkzeug geändert werden80. 79 Die graphische Modellierung bei ADOS-X wurde durch das Wrappen von java-Swing Klassen in FlexiBeans erreicht. Auf die Swing-Klassen kann durch gleichnamige SharedObjects zugegriffen werden. 80 Das Benutzer-Interface des Anpassungs-Werkzeugs ist in Abbildung 6-7 zu sehen. 110 Durch die reflexive Anpassungs-Komponente wäre es möglich, dass das AnpassungsWerkzeug auf die Repräsentation des angeschlossenen Sortierers zugreifen kann, und damit die (Aus-)Sortierungsstrategie im CAT-File zu speichern. Eine Dekomposition, die das Anpassen eines Sortierers mit Hilfe einer reflexiven Anpassungsumgebung erlaubt, ist in Abbildung 7-4 dargestellt. Zur Änderung der Strategie lässt das SortiererAnpassungswerkzeug sich über den EVOLVE-Context seine Repräsentation in der EvolvePlattform geben. Dadurch, dass der Sortierer über den Einstellen-Port mit dem Werkzeug verbunden ist, kann das Werkzeug auch auf die Repräsentation des Sortierers zugreifen. Das Werkzeug kann dann durch die Strategie-Property des Sortierers auf die Sortierstrategie zugreifen und sie für den Benutzer in einer für ihn angemessenen Form anzeigen, so dass er sie einstellen kann. Über die Tailoring-API kann die StrategieProperty auf die geänderte Sortierstrategie gesetzt werden. Sortierer Anpassungswerkzeug EVOLVEContext EVOLVEContext EVOLVE Einstellen Einstellen Sortierer Strategie :: String Abbildung 7-4 Realisierung eines Anpassungswerkzeugs, mit dem man einen Sortierer einstellen kann Das Prinzip kann auch auf abstrakte Komponenten übertragen werden. Für atomare Komponenten kann alternativ der in Sun (1997, Kapitel 9) spezifizierte Ansatz zur komponentenspezifischen Anpassung übernommen werden. Die Spezifikation legt über Interface-Definitionen, fest wie ein komponentenspezifisches Anpassungswerkzeug aussehen muss. Durch die Standardisierung ist es einer Entwicklungsumgebung81 möglich das Anpassungswerkzeug bei der Konfiguration der Komponente aufzurufen. Idealerweise werden beide Ansätze, reflexive Komponenten und festgelegte Schnittstellen für Anpassungswerkzeuge, miteinander verknüpft. 7.2.3 WAM-Materialien Ein noch ungelöstes Problem stellt die Modellierung von anpassbaren WAM-Materialien durch FlexiBeans dar. In diesem Abschnitt werde ich auf die Probleme eingegehen, die sich bei der Modellierung ergeben. Im Falle von ADOS-X stellen die Anfrageobjekte ein Material in Sinne des WAMAnsatzes dar. An die Anfrageobjekte gab es verschiedene Anforderungen, die hier 81 Im Falle des FlexiBean-Ansatz ist es nicht die Entwicklungs-, sondern die Anpassungsumgebung. EVALUATION 111 stichpunktartig aufgelistet sind: Zunächst einmal muss dem Benutzer eine Anfrage als ein Suchformular angezeigt werden, so dass er sie bearbeiten kann. Daneben muss sie sich über einen E-Mail-Server verschicken lassen. Dabei ist zu beachten, dass auch die Zeichnungen, die als binäre Daten vorliegen, transportiert werden können. Zusätzlich muss die ADOS-Komponente aus der Anfrage eine Datenbankabfrage generieren und die Antwort in die Anfrage integrieren. Zusätzlich muss die Anfrage durch die SortiererKomponente analysiert werden können, damit der Sortierer entscheiden kann, welche er wohin weiterleiten soll. Daneben sollte es möglich sein, nachträglich neue Anfragetypen einzuführen. Implementierte Modellierung: Beim Prototypen wurde auf das JavaMail Package von Sun Microsystems (1998) aufgebaut, zumal es Anbindung an einen E-Mail-Server sicherstellte. Eine E-Mail wird im JavaMail Package durch ein Objekt der Klasse javax.mail.internet.MimeMessage präsentiert. Die Anfragen bei ADOS-X werden durch diese Klasse realisiert. Im Folgenden soll die Funktionsweise von JavaMail erläutert werden. Wie Abbildung 7-5 zeigt, arbeitet das Package eng mit dem Java Activation Framework (JAF) zusammen. Die Mail besteht aus zwei Bestandteilen, den Headers und dem Content. Dem Content ist ein Mimetyp zugeordnet. Über ihn kann das JAF ermitteln, welche java-Klasse den ContentData verarbeiten kann. Durch die Klasse, die von javax.activation.DataSource abgeleitet sein muss, kann auf den Inhalt zugegriffen werden. Der DataSource ist ein DataHandler zugeordnet. Die Funktionsweise von DataHandler, CommandMap und CommandObject soll anhand eines Beispiels aus ADOS-X erläutert werden. JavaMail Java Activation Framework MimeMessage DataSource DataContentHandler Headers Content DataHandler Command Map Command Object <mime-type> ContentData # Command Map für ADOS-X multipart/* ; ; x-java-view = com.adosx.co.MultipartViewer; \ x-java-edit = com.adosx.co.MultipartEditor text/plain; ;x-java-view = com.adosx.co.TextViewer; \ x-java-edit = com.adosx.co.TextEditor image/tiff; ;x-java-view=com.adosx.co.TifViewer; java-serialized-object/x-zngsuche ; ; x-java-view = com.adosx.co.ZngSucheViewer; \ x-java-edit = com.adosx.co.ZngSucheEditor; \ x-java-adosexecute = com.adosx.adosdb.co.ZngSucheExecute ... Abbildung 7-5 Realisierung von Anfragen durch MimeMessages und deren Zusammenspiel mit dem Java Activation Framework 112 Der Anfragenbearbeiter lässt sich von einer MimeMessage den DataHandler geben. Anschließend erfragt der Anfragenbearbeiter vom DataHandler, ob er zum edit-Befehl ein CommandObject besitzt. Dazu lässt der DataHandler sich vom JAF die CommandMap geben82 und erstellt daraus die Liste der zum Mimetyp vorhandenen CommandObjects. Dann erstellt er die zum edit-Befehl eingetragene Klasse, initialisiert sie mit der DataSource und gibt sie zurück. Der Anfragenbearbeiter veranlasst dann das zurückgegebene CommandObject, sich anzuzeigen. Nach dem gleichen Prinzip kann die ADOS-Komponente sich ein CommandObject geben lassen, das dann die Datenbank abfragt und daraus eine Antwort erstellt. Schwachstellen: Damit ist die implementierte Lösung zwar erweiterbar, aber die in der CommandMap referenzierten CommandObjects sind durch den Benutzer nicht mehr anpassbar. Ein anderes Problem besteht darin, dass die CommandMap für das gesamte System gilt. Dies kann insbesondere bei einem Mehrbenutzersystem zu unerwünschten Effekten führen. In der vorliegenden Arbeit wurde jedoch kein allgemeiner Lösungsansatz für die Gestaltung von WAM-Materialien entwickelt. Es besteht ein entsprechender Forschungsbedarf, wie durch den Benutzer anpassbare Materialien modelliert werden sollen, wie diese in den FlexiBean-Ansatz integriert werden können und wie eine für den Benutzer geeignete Interaktionsform aussehen könnte. Insbesondere bedarf es eines Mechanismus, durch den das Material mit einem anpassbaren Werkzeug gekoppelt wird. Für einen solchen Mechanismus bietet es sich an, auf die reflexiven Komponenten zurückzugreifen. Beim Datenformat bietet es sich an, XML als erweiterbare Beschreibungssprache zu verwenden. 7.2.4 Semantik von SharedObjects Bei der Semantik von SharedObjects ist für die Benutzer vor allem von Belang, dass ein SharedObject-Client nicht mit mehreren SharedObject-Providern verbunden werden kann. Auf die Auswirkung, die diese eingeschränkte Kardinalität vom SharedObject-Provider auf die Modellierungsmöglichkeiten hat, gehe ich auf Seite 116 ein. Im Folgenden gehe ich auf die informal gegebene Semantik ein, da sie einen wichtigen Bestandteil des FlexiBean-Modells betrifft. Die Semantik ergibt sich daraus, dass SharedObjects, wie in Abschnitt 1.2 erläutert, die objektorientierte Umsetzung der Idee von gemeinsamen Variablen darstellen sollen. 82 Der CommandMap-Eintrag hat dabei die Form: <mimetype>/<subtype> ; ; x-java-<command> = <classname> EVALUATION 113 Gemeinsame Variablen zeichnen sich unter anderem dadurch aus, dass sie keinen Kontrollfluss besitzen. Da die Umsetzung beim Zugriff auf das SharedObject einen Methodenaufruf verlangt, wird jedoch die Kontrolle auf das SharedObject übertragen. Eine Umsetzung, die einer passiven Variablen am Nächsten kommt, verlangt von den kapselnden Methoden, dass in ihnen keine anderen Methoden aufgerufen werden. Eine weniger strenge Umsetzung verlangt nur, dass die Kontrolle innerhalb des SharedObjects bzw. in der Komponente bleibt. Diese schwächere Anforderung ermöglicht es aber immer noch, dass der Entwickler einer Komponente den Überblick darüber hat, welche Eigenarten sich aus dem Kontrollfluss ergeben. Werden keine Anforderungen an den Kontrollfluss gestellt, so verkompliziert sich die Komponentenentwicklung insbesondere dadurch, dass hier das Zusammenspiel von Komponenten unterschiedlicher Hersteller beachtet werden muss. Dadurch, dass der Kontrollfluss die Komponente verlässt, ergibt sich das von Szyperski (1998, Kapitel 5) untersuchte Phänomen des Re-Entrance. Er versteht unter Re-Entrance „the situation in which an object’s method is invoked while another method is still executing“ [Szyperski (1998, S. 64)]. Das Problem des Re-Entrance besteht in der Beobachtung eines Objekts, das sich einer Zustandsänderung unterzieht, bei der inkonsistente Zwischenzustände sichtbar werden. In Abbildung 7-6 ist ein Beispiel für ein Re-Entrance gezeigt. Die ClientBean1 ruft eine Methode des SharedObjects auf (1). Damit wird der Kontrollfluss an die ProviderBean übergeben. Diese führt die SharedObject-Methode aus (2). Während der Ausführung sendet die ProviderBean ein Event, so dass der Kontrollfluss die Bean wieder verlässt (3). Über Umwegen erhält so die ClientBean2 den Kontrollfluss, die wiederum eine SharedObject Methode aufruft (5). Dadurch sieht die ClientBean2 unter Umständen einen nicht konsistenten Zwischenzustand des SharedObjects. ProviderBean (3) (2) (1) (5) (4) ClientBean1 Legende: ClientBean2 Kontrollfluss Abbildung 7-6 Beispiel eines Re-Entrance, wie er sich im FlexiBean-Modell darstellt Es spricht also einiges dafür, von SharedObjects zu verlangen, dass der Kontrollfluss auf die eigene Komponente beschränkt bleibt. Diese Anforderung kann jedoch zu monolithischen Komponenten führen, deren interne Struktur nicht mehr anpassbar ist. Zum 114 anderen erschwert diese Anforderung das Design nach dem „seperation of concerns“Prinzip83. Ein Beispiel dafür findet man in Abbildung 7-1. Hier delegiert das Postfach das Speichern des Inhalts an die FileArchiv-Komponente. Bei solchen Modellierungsmustern ist es jedoch notwendig, aus einer SharedObject-Methode auf SharedObjects anderer Komponenten zuzugreifen, weshalb eine Semantik in diesem Punkt nicht zu restriktiv sein sollte. Lösungsansatz: Der hier vorgeschlagene Ansatz ist nicht so streng, dass er verlangt, dass der Kontrollfluss auf die Komponente beschränkt bleibt. Aber unter bestimmten Vorraussetzungen kann gezeigt werden, dass das Problem des Re-Entrance bei der Ausführung einer SharedObject-Methode nicht auftreten kann. Wobei ich unter Berücksichtigung des java Thread-Modells Re-Entrance etwas anders definiere. Ein Thread stellt in java einen eigenen Kontrollfluss dar. Existieren mehrere Kontrollflüsse, so spricht man von Multi-Threading. Beim Multi-Threading stellt sich das Problem des ReEntrance so dar, dass ein Thread auf einen inkonsistenten Zwischenzustand eines Objekts zugreifen kann. Um dies für einen fremden Thread zu verhindern gibt es in java das Konstrukt der Synchronisation [Sun (1996)], weshalb ich mich hier auf den Fall des Single-Threads beschränke. Definition des Re-Entrance eines SharedObjects: Ich verstehe deshalb unter dem Re-Entrance eines SharedObjects die Situation, bei der während der Ausführung einer Methode des SharedObjects im gleichen Thread auf das SharedObject von außerhalb zugegriffen wird. Ein SharedObject heißt reentrance-sicher, wenn kein Re-Entrance auftreten kann. Ist ein SharedObject reentrance-sicher, so sieht es im Falle des Single-Threads nach außen so aus, als ob seine Methoden atomar sind. Wie oben erläutert, sollte es erlaubt sein, innerhalb einer SharedObject-Methode auf andere SharedObjects zuzugreifen. Auf der anderen Seite ist es für das SharedObject bzw. dessen Provider nicht notwendig aus einer SharedObject-Methode Events zu senden, da dies für die Event-Quelle selbst keinen Informationszuwachs bedeutet. Deshalb dürfte die folgende Forderung keine allzu große Einschränkung der Modellierungsmöglichkeiten darstellen. Auf der anderen Seite gewinnt man eine größere Klarheit bei der Komponentenentwicklung, weil der Zugriff auf ein SharedObject und die Eventverarbeitung besser getrennt ist. Anforderung an ein SharedObject: Eine SharedObject-Methode darf innerhalb des eigenen Threads keine Events senden. 83 Dieses Prinzip besagt, dass eine Komponente sich auf eine einzelne Aufgabe konzentriert und Teilaufgaben, die sich nicht direkt auf diese Aufgabe beziehen, an andere Komponenten delegieren soll. EVALUATION 115 Diese Forderung impliziert, dass während des Zugriffs auf ein SharedObject nicht in den Modus der Eventverarbeitung gewechselt werden darf. Satz über Re-entrance-Sicherheit: Falls eine Anwendung eine „saubere“ und hinsichtlich der SharedObjects eine geschichtete Architektur besitzt und wenn die SharedObject-Methoden die obige Forderung erfüllen, dann ergibt sich, dass SharedObjects reentrance-sicher sind. Erläuterung und Beweis: Um zu zeigen, dass der Satz gilt, muss zuerst geklärt werden, was unter einer „sauberen“ Architektur zu verstehen ist. Saubere Architektur besagt, dass es keine versteckten Wege gibt, um auf eine Komponente zuzugreifen. Ein solcher versteckter Weg besteht z.B. darin, in einer Event-Methode eine Referenz auf die Quelle mitzugeben (vgl. Abschnitt 3.3.1). Durch diese Referenz ist es möglich auf QuellKomponenten zuzugreifen, obwohl dies nicht aus der Kompositionsbeschreibung ersichtlich ist. Anders ausgedrückt: Sei G = ( N ,V ) ein gerichteter Graph mit N die Menge der Instanzen der atomaren Komponenten und V ⊆ N × N die Menge, der durch die Verbindungen der Ports induzierten Kanten. D.h. n, m ∈ N hat genau dann eine Kante in V, wenn n ein Port p und m Port q besitzt, die miteinander direkt oder indirekt verbunden sind84. Die Richtung der Kante ergibt sich aus dem Typen des Ports, ist p ein SharedObject-Client oder ein Event-Quelle, dann geht die Kante von n aus, d.h. (n, m) ∈ V . Andernfalls geht die Kante nach n ein, d.h. (m, n) ∈ V . Sind n und m SharedObjects spricht man auch von einer SharedObject-Kante. Eine saubere Architektur bedeutet dann, dass der Kontrollfluss eine Komponente nur über die ausgehenden Kanten verlassen kann. Durch den Graphen lässt sich auch definieren was unter geschichteter Architektur hinsichtlich der SharedObjects zu verstehen ist. Es bedeutet, dass der durch die SharedObject-Kanten induzierte Teilgraph azyklisch ist. Der Beweis läuft nun wie folgt: Wenn der Kontrollfluss eine Komponente über eine SharedObject-Kante betreten hat, dann kann er wegen der sauberen Architektur und der Bedingung, dass innerhalb eines SharedObjects keine Events geschickt werden dürfen, die Komponente nur über eine SharedObject-Kante wieder verlassen. Damit verbleibt er während der gesamten Zeit der Ausführung einer SharedObject-Methode innerhalb des durch die SharedObjects induzierten Teilgraphs. Da dieser aber nach Voraussetzung azyklisch ist, kann es zu keinem Re-Entrance kommen. 84 „Indirekt“ bedeutet dabei, dass die Ports über abstrakte Komponenten miteinander verbunden sind. Auf eine rekursive Definition der Verbindung wird hier verzichtet. 116 Anwendung des Lösungsansatz: Anhand zweier Modellierungen soll gezeigt werden, wie man die obige Forderung bei der Gestaltung von FlexiBeans umsetzen kann. Im ersten Fall (Abbildung 7-7) ist das Propagieren der Änderung ganz in der Verantwortung der Provider-Komponente. Abbildung 7-7 Weitertransport einer Anfrage bei ADOS-X mit impliziter Änderungspropagierung Im zweiten Fall (Abbildung 7-8) wird die Änderungspropagierung von der ClientKomponente angestoßen. Im Folgenden werden die beiden Modellierungen erläutert. Abbildung 7-8 Weitertransport einer Anfrage bei ADOS-X mit expliziter Änderungspropagierung In Abbildung 7-7 bekommt der Sortierer ein Triggersignal. Daraufhin entnimmt er die Messages aus Postfach A und legt sie in Postfach B. Das Entnehmen und das Einfügen haben als Seiteneffekt, dass das betroffene Postfach einen eigenen Thread startet, der die Änderung über den PfChanged-Port anzeigt. Nach Außen sieht es so aus, als ob dieser Thread die ganze Zeit das SharedObject beobachtet und jede Änderung propagiert. Bei der Modellierung, die in Abbildung 7-8 zu sehen ist, wird das Propagieren der Änderung explizit angestoßen. Der Ablauf sieht ähnlich aus wie in Abbildung 7-7. Jedoch werden beim Zugriff auf das SharedObject von diesem keine Events generiert. Stattdessen sendet der Sortierer nach getaner Arbeit den Provider-Komponenten eine probChangeNachricht. Dies veranlasst das Postfach die Änderungen ihres SharedObjects weiterzugeben. EVALUATION 117 Die erste Modellierung hat den Vorteil, dass sie mit weniger Verbindungen auskommt und es damit weniger Möglichkeiten gibt, beim Zusammenstecken einen Fehler zu machen. Auch ist sie einfacher zu implementieren, weil die ganze Eventverarbeitung in einer Komponente gekapselt ist. Auf der anderen Seite sind Threads im allgemeinen teure Konstrukte und sie können zu Deadlocks führen. Zum anderen erlaubt die zweite Modellierung eine größere Kontrolle durch den Client. Z.B. ist im obigen Beispiel ein konsistenter Systemzustand erst dann erreicht, wenn die entnommenen Anfragen in das andere Postfach eingefügt werden. Erst danach sollte der neue Zustand der SharedObjects veröffentlicht werden. Ein anderer Punkt, der mit der Semantik der SharedObjects zusammenhängt, ist die Kardinalität der an einen SharedObject-Client angeschlossenen SharedObject-Provider. Die FlexiBean-Spezifikation legt fest, dass ein Client höchstens mit einem Provider verbunden werden darf. Hierin drückt sich eine gewisse Symmetrie zwischen der Clientund der Provider-Komponente aus. Bei den Prototypen bedurfte es jedoch einer Komponente, die die Postfächer-Instanzen zusammenfasst und dem Benutzer anzeigt, damit er aus der Liste ein Postfach auswählen kann. Eine Modellierung dafür, ist in Abbildung 7-9 zu sehen. Abbildung 7-9 Komponente, die es erlaubt, aus einer Liste von Postfächern eins auszuwählen Auf der linken Seite können die Postfächer bei dem Auswähler eingesteckt werden. Auf der rechten Seite wird dann der Inhalt des ausgewählten Postfachs (grau markiert) durchgeschleift. Da jedoch ein Client nur mit einem Provider verbunden werden darf, musste bei der gefundenen Lösung ein Adapter vorgeschaltet werden, der die Polarität umdrehte. Statt mit solchen technischen Tricks zu arbeiten, sollte es auch ein Konstrukt geben, dass es erlaubt SharedObject-Clients mit mehreren Providern zu verbinden. Graphisch kann ein solcher Client wie in Abbildung 7-9 durch eine unausgefüllte Raute gekennzeichnet werden. 7.2.5 Sonstige Erweiterungsvorschläge In diesem Abschnitt werden weitere Punkte kurz angerissen, die sich bei der Auseinandersetzung mit dem FlexiBean-Ansatz ergaben: Annotationen: Wie in Abschnitt 3.1.3.11 angemerkt, sollte der Benutzer beim Anpassen dadurch unterstützt werden, dass das Systemdesign durch zusätzliche Informationen 118 erläutert wird. Kehrseitig dazu sollte der Benutzer seine Anpassung kommentieren können. Deshalb sollte das CAT-Format auch Kommentare erlauben, auf die auch durch die Tailoring-API zugegriffen werden kann. Die Struktur der Kommentare sollte das Annotieren von ganzen Komponenten, aber auch einzelner Komponenteneigenschaften oder Verbindungen erlauben. Eine mögliche Umsetzung kann sich an die durch javadoc gegebene Kommentarstruktur orientieren [Gosling, Joy und Steele (1996, Kapitel 18)]. Zusätzlich sollte eine umfassende Lösung festlegen wie die Dokumentation, die zu den implementierten Komponenten vorliegt, in das System integriert werden kann. Anpassungsprozesse und Bedingungen („constraints“): Bedingungen stellen in Gewisserweise einen Spezialfall von Kommentaren dar. Sie können sich auf eine einzelne Komponente beziehen oder komponenten-übergreifend gelten. In ACME und vor allem in Wright sind Bedingungen ein Grundbestandteil des Komponentenansatzes85. Für anpassbare Systeme wurde von Stiemerling der „tailoring constraints“ gebraucht (Abschnitt 3.1.3.7). Bei der Umsetzung des Konzepts im FlexiBean-Ansatz sollte zwischen der Darstellung der Bedingungen im CAT-Format und der Überprüfung der Bedingungen unterschieden werden. Nur der erste Teil muss allgemein spezifiziert werden. Die Überprüfung könnte einer (anwendungsspezifischen) Anpassungsumgebung überlassen werden. Bei der Überprüfung von Bedingungen ist zu beachten, dass Anpassung ein dynamischer Prozess ist. Kopiert man z.B. ein Postfach und wird die ID mitkopiert, so wird die Bedingung der Eineindeutigkeit zeitweilig verletzt. Ein anderes Beispiel einer Inkonsistenz ergibt sich beim Prototyp, wenn bei einem Sortierer an einen Ausgang (OK- bzw. KO-Port) kein Postfach angeschlossen ist86. Man sollte deshalb bei der Einführung von Bedingungen auch festlegen, wann die Bedingungen gültig sind, z.B. am Ende eines Anpassungsprozess. Dafür sollte ein Protokoll spezifiziert werden, dass festlegt, wie ein Anpassungsprozess auszusehen hat. Dieses Protokoll müsste auch einen Transaktionsmechanismus beinhalten, so dass ein Anpassungsvorgang, der zu Inkonsistenzen führt, wieder rückgängig gemacht werden kann. Späte Verdrahtung: Bei Verdrahtung der Komponenten sollte ausgenutzt werden, dass die Komponenten erst zur Laufzeit verbunden werden. Damit kann eine dynamische Konsistenzprüfung unter zur Hilfenahme der beteiligten Komponenten erfolgen. Da diese Prüfung erst zur Laufzeit geprüft wird, kann man auch von einer späten Verdrahtung sprechen. Sinnvoll ist es auch, ein Protokoll festzulegen, mit der die 85 Ein Beispiel für eine Bedingung, die sich auf das gesamte System bezieht, besteht in der Forderung nach einer eineindeutigen Postfach-ID (Abschnitt 7.2.1). 86 Bei der Implementierung wird so verfahren, dass in dem Fall passende Anfragen nicht weitertransportiert werden. Stattdessen wird durch das Anschließen eines Postfachs der Weitertransport aktiviert. Dieser Seiteneffekt kann aber in einem Anwendungsszenario, bei dem der Weitertransport explizit durch den Benutzer ausgelöst werden soll, zu unliebsamen Seiteneffekten führen. EVALUATION 119 beteiligten Komponenten einen Verbindungstyp untereinander aushandeln können und falls dies fehlschlägt, eine Fehlermeldung produzieren. Glue Code: Durch ein solches Protokoll kann auch die starke Typisierung gelockert werden, die manchmal dazu zwingt, neue Adapter-Komponenten einzuführen. Trotzdem wird es sich nicht vermeiden lassen, dass es gerade bei Komponenten von verschiedenen Herstellern zu „compositional mismatches“ kommt. Achermann et al. (2001) sprechen auch vom Glue bzw. glue code, der dazu dient, die Unverträglichkeit von Komponenten zu überwinden. Sie fordern deshalb, dass eine Skriptsprache ein Grundelement einer CDL sein sollte. Der glue code kann dann mit Hilfe dieser Skriptsprache geschrieben werden. Inwieweit eine solche Skriptsprache für den Benutzer sinnvoll ist, damit er im Notfall möglichst einfach selber einen ad hoc Adapter schreiben kann, und wie sie im Falle des FlexiBean-Ansatz aussehen soll, ist eine offene Frage. Steckverbindungen: Die Evaluation der Dekomposition ergab, dass zu viele Verbindungen für den Anwender verwirrend wirken. Deshalb sollten sie zusammengefasst werden. Eine technische Lösung besteht darin, dass es im FlexiBeanAnsatz nicht nur erlaubt ist, abstrakte Komponenten zu definieren, sondern auch abstrakte Ports und Verbindungen. 120 121 8 ZUSAMMENFASSUNG UND AUSBLICK In der vorliegenden Arbeit wurde gezeigt, wie sich mit Hilfe des FlexiBean-Ansatzes eine erweiterte Zugriffskontrolle realisieren lässt. Die Realisierung durch einen Prototyp diente in der Arbeit dazu, die Modellierungsmöglichkeiten, die durch den FlexiBean-Ansatz gegeben sind, zu untersuchen. Ein besonderes Augenmerk lag auf der Frage, ob die Modellierungsmöglichkeiten eine für den Endanwender verständliche Dekomposition ermöglichen. Hinsichtlich der Frage, inwieweit die Anpassungsmöglichkeiten des Prototyps für den Anwendungskontext relevant sind, konnte durch die Analyse des im Anwendungsfeld erhobenen Materials gezeigt werden, dass in der Gestaltung der Zugriffskontrolle das größte Konfliktpotential lag. Die Analyse zeigte zudem, dass die Beziehung zwischen den externen Büros und der internen Konstruktionsabteilung87 durch ein dialektisches Verhältnis von Kooperation und Konkurrenz geprägt ist. Aus dieser Dialektik entspringt bei der internen Konstruktionsabteilung ein erhöhtes Kontrollbedürfnis. Diesem Umstand kommt bei der Gestaltung eines Telekooperationssystems besondere Bedeutung zu, weil hier durch die Virtualisierung andere Kontroll-Mechanismen (wie z.B. die soziale Kontrolle) wegfallen. Bei der Frage nach der Angemessenheit der Anpassungsmöglichkeiten konnte durch die Analyse gezeigt werden, dass der Mechanismus der klassischen Zugriffskontrolle mit seiner dichotomen Einteilung in „erlaubt“ und „verboten“, für diesen Anwendungsfall nicht adäquat ist. Denn die Extrempositionen, die sich im Falle externe Büros – interne Konstruktionsabteilung gegenüberstanden, sind nicht „erlaubt“ versus „verboten“, sondern „automatischer Zugriff“ versus „manuelle Kontrolle“. In der Arbeit wurde aufgrund dieser Erkenntnis ein Ansatz zur Kontrolle entwickelt, der von der Sicht des Kontrolleurs ausgeht, und der die Kontrollmechanismen in drei Kategorien einteilt. Nach dem Modell gibt es Mechanismen zur ex-ante (vor), zur uno-tempore (während) und zur ex-post (nach) Kontrolle. Die Einteilung erfolgt dabei nach dem Zeitpunkt, an dem über die Legitimität des Zugriffs entschieden wird. Der Mechanismus der klassischen Zugriffskontrolle stellt dabei eine ex-ante Kontrolle dar, die manuelle Kontrolle gehört der uno-tempore Kategorie an. Durch eine Protokollierung kann der Zugriff einer ex-post Kontrolle unterzogen werden. Durch den Prototyp wurden diese Kontrollmechanismen realisiert. In der Arbeit konnte gezeigt werden, dass in diesem für den Anwendungskontext wichtigen Punkt der Zugriffskontrolle der Prototyp gegenüber der klassischen Zugriffskontrolle eine größere 87 Auf der Seite des Stahlwerks war die interne Konstruktionsabteilung formal für die Kooperation zuständig. 122 Flexibilität besitzt und für den Anwendungsfall adäquatere Kontrollmechanismen bereithält. Eine spezielle Form der ex-ante Kontrolle besteht darin, vorweg eine Obergrenze für einen automatischen Zugriff festzulegen. Für den Anwendungsfall kann ein solches Kontingent hilfreich sein, weil damit der Befürchtung entgegengetreten werden kann, dass das Archiv von außen „leergesaugt“ wird. In der vorliegenden Arbeit wurde gezeigt, wie der Prototyp mit Hilfe eines neuen Komponententyps, dem Kontingentierer, um diesen Kontrollmechanismus erweitert werden kann. Damit wurde gezeigt, dass der Prototyp hinsichtlich der Zugriffskontrolle nicht nur anpassbar, sondern auch erweiterbar ist. Bei der Frage nach der Verständlichkeit der Dekomposition zeigte sich, dass die bestehenden Interessenkonflikte die Evaluation im Anwendungsfeld erschwerten, da sich die technischen nicht von den betriebspolitischen Aspekten trennen ließen. Deshalb wurde die Dekomposition zusätzlich mit Hilfe der „Thinking-Aloud“-Methode mit verschiedenen Testpersonen außerhalb des OrgTech-Projekts evaluiert. Die Tests lassen die These berechtigt erscheinen, dass eine für den Endanwender verständliche Dekomposition gefunden wurde. Denn die Probanden konnten sowohl die Funktion der einzelnen Komponenten, als auch die Arbeitsweise der Dekomposition nachvollziehen. Es zeigte sich, dass die Bedeutung einer Komponenteninstanz vor allem über die Benennung und weniger über die Verdrahtung erschlossen wird. Als Konsequenz sollte sich die Funktionsweise der Komponente möglichst vollständig aus der Benennung ergeben, so dass nicht auf die Verdrahtung Bezug genommen werden muss. Damit hat die Arbeit für den Fall der Zugriffskontrolle gezeigt, dass es im FlexiBeanAnsatz möglich ist, eine aufgabenorientierte Sicht bis hinunter zu den Grundkomponenten aufrechtzuerhalten. Da das Zerlegen des Systems vom WAM-Ansatz gelenkt wurde, stellt er einen möglichen Ausgangspunkt für eine Methodik zur Gestaltung von komponentenbasiert-anpassbaren Systemen dar, der die Kluft zwischen Anwendung und Systemarchitektur verringert. Denn die Dekomposition folgt mit ihrem aufgabenorientierten Aufbau und ihrer Aufteilung entlang der WAM-Metaphern88 den Grundprinzipien des WAM-Ansatzes. Eine zentrale Rolle bei der Umsetzung bestand darin, dass eine Zugriffsanfrage als eine E-Mail realisiert wurde. Durch die E-Mail konnte eine Zugriffsanfrage in einer für den Benutzer verständlichen Form dargestellt werden. Zudem konnte so an die bestehende Praxis angeknüpft werden. Mit Hilfe der Anfrage-E-Mail konnte nicht nur die Funktion der 88 Die wichtigsten WAM-Metaphern sind Werkzeug, Material, Automat, Arbeitsumgebung und Behälter ZUSAMMENFASSUNG UND AUSBLICK 123 einzelnen Komponenten, sondern auch die Verbindungen zwischen den Komponenten erklärt werden. Jedoch bedarf es noch weiterer Forschung in anderen Anwendungsfeldern, um aus dem WAM-Ansatz eine allgemeine Methodik zur Gestaltung von komponentenbasiertanpassbaren Systemen zu entwickeln. Insbesondere sollte man die in der Arbeit nicht untersuchte Gestaltung der Benutzerschnittstelle und deren Anbindung an die Funktionalität des Systems analysieren. Außerdem besteht bei der Modellierung von anpassbaren WAM-Werkzeugen und anpassbaren WAM-Materialien noch Forschungsbedarf. In der Arbeit konnte gezeigt werden, dass dazu der FlexiBean-Ansatz erweitert werden sollte. Aus der Analyse des Prototyps ergaben sich vor allem zwei Punkte, in denen der FlexiBean-Ansatz erweitert werden sollte: 1. Reflexive Anpassungskomponenten und 2. ein Persistenz-Mechanismus. Die Forderung, den FlexiBean-Ansatz um reflexive Anpassungskomponenten zu erweitern, ergab sich aus dem Versuch, ein anpassbares WAM-Werkzeug zu modellieren. So zeigte sich, dass es der FlexiBean-Ansatz momentan nicht zulässt, aus einer Komponente heraus auf die, durch die Evolve-Plattform erzeugte, Komponentenstruktur zuzugreifen und zu verändern bzw. neue Komponenteninstanzen zu erzeugen. Wie in der Arbeit gezeigt, hat dies zur Folge, dass anpassbare Werkzeuge sich nur eingeschränkt modellieren lassen. In der Arbeit wurde ein Lösungsansatz zur Erweiterung des FlexiBean-Ansatzes aufgezeigt, der es einer Komponente ermöglicht, auf ihre eigene, durch die Evolve-Plattform gegebene, Repräsentation und auf die Kompositionsstruktur zuzugreifen und sie anzupassen. Eine solche Komponente wurde in der Arbeit als reflexive Anpassungskomponente bezeichnet. Neben der Modellierung von anpassbaren WAMWerkzeugen ermöglicht es diese Art von Komponenten auch anpassungsspezifische Anpassungsumgebungen zu modellieren. Die Forderung nach einem Persistenz-Mechanismus ergab sich daraus, dass es im FlexiBean-Ansatz nicht möglich ist, den Zustand einer Komponenteninstanz so abzuspeichern, dass keine andere Instanz darauf zugreifen kann. Im Falle des Prototyps sollte der Zustand der Postfach-Komponente gespeichert werden. Deshalb sollte der FlexiBean-Ansatz um einen Persistenz-Mechanismus erweitert werden. Es wurde gezeigt, dass eine minimale Anforderung an einen solchen Mechanismus in der Bereitstellung einer eineindeutigen Komponenteninstanz-ID liegt. Ein kompletter Persistenz-Mechanismus sollte aber den gesamten Lebenszyklus einer persistenten Komponente unterstützen, so wie dies z.B. bei den Enterprise JavaBeans (EJBs) der Fall ist. 124 Forschungsbedarf besteht ebenfalls noch in der Anpassung der Dekomposition durch die 3D-Anpassungsumgebung. Sie wurde in der vorliegenden Arbeit nicht untersucht, aber die Analyse des Prototyps und die Tests mit dem Papier MockUp legen nahe, dass es sinnvoll ist, wenn anwendungs- und benutzerspezifische Anpassungsumgebungen in die generische Anpassungsumgebung integriert werden können. Zum Abschluss sei hier noch ein Ausblick auf die Gestaltung und den Entwicklungsprozess bei gruppenwirksamer Anpassbarkeit geworfen. Die vorliegende Arbeit ist unter diesen Gesichtspunkten interessant, weil sie die Frage aufwirft, wie mit Konflikten bei gruppenwirksamer Anpassbarkeit im Software-Prozess umgegangen werden kann. Hierbei ist zu berücksichtigen, dass bei der Gestaltung von gruppenwirksamer Anpassbarkeit, die Systemgestaltung keine alleinige Angelegenheit des zukünftigen Anwenders, sondern ein doppelter Aushandlungsprozess der vom System betroffenen Personen ist. So muss die Gestaltung zwischen den Beteiligten ausgehandelt werden und dies vor dem Hintergrund, dass beim Gebrauch des Systems sich dieser Aushandlungsprozess bei der Anpassung des Systems durch den Benutzer wiederholt. Diese Zukunftsoffenheit macht es aber schwierig, vor dem Einsatz in der Praxis zu beurteilen, ob die Anpassungsmöglichkeiten, die aufgrund des ersten Aushandlungsprozess in die Systemgestaltung eingeflossen sind, im zweiten Aushandlungsprozess auch tatsächlich wahrgenommen werden. Der Arbeit lag die Hypothese zu Grunde, dass es bei gruppenwirksamer Anpassbarkeit nicht ausreicht, die verschiedenen Anforderungen als Alternativen in das System zu integrieren89. Das System sollte auch Wege bereitstellen, die eine Kompromisslösung unterstützen. Die Hypothese besitzt zwar eine gewisse Plausibilität, ihr fehlt aber noch die empirische Bestätigung. Für die Praxis bietet sich zudem die evolutionäre Softwareentwicklung an. So sollte man bei der Einführung des Prototyps in die Praxis aus verschiedenen Gründen zunächst nur die in Abschnitt 6.3 beschriebene „kleine“ Lösung, die nur eine manuelle Kontrolle erlaubt, verwirklichen. Diese Lösung, und das ist für die Einführung wichtig, hält aber die Option bereit, dass sie zu einer „großen“ Lösung mit einer erweiterten Zugriffskontrolle – wie in Abschnitt 6.4 dargestellt – ausgebaut werden kann. Gäbe es diese Option nicht, so würde von allen Beteiligten zu Recht kritisiert, dass das Telekooperationssystem einen zu geringen Mehrwert besitzt. Hierbei zeigt sich der Vorteil, dass der Komponentenaufbau 89 Im Gegensatz dazu würde es bei der Individualisierung theoretisch ausreichen, die verschiedenen Anforderungen als Alternativmöglichkeiten anzubieten. Deshalb macht es Sinn, bei einer Methodik zur Gestaltung von Anpassbarkeit die unterschiedlichen Kategorien der Anpassbarkeit, die Oberquelle (vgl. Seite 8) aufgestellt hat, zu berücksichtigen. ZUSAMMENFASSUNG UND AUSBLICK 125 des Systems nicht nur die Anpassbarkeit, sondern auch die evolutionäre Entwicklung unterstützt. 126 ANHANG A Abbildung A-1 Ursprüngliche Dekomposition ohne die Kontingentierer- und Retoure-Komponente ANHANG B 127 ANHANG B Eingang Eingang Ausgang Ausgang Nicht erlaubte Anfragen Einstellungen Eingang Eingang NEIN Darf Anfrage auf ADOS zugreifen ? JA Eingang Kont.Postfach Ausgang Eingang Ausgang Geändert Kontingent überschritten ✂ JA Eingang ✄ ✄ Ist Kontigent überschritten? Einstellungen NEIN Eingang Kont. OK Postfach Ausgang Einstellungen Eingang Soll Anfrage protokolliert werden ? NEIN JA Eingang Zum Kopierer Ausgang Ausgang Prokollierte Anfragen Eingang Eingang Kopie Lege Kopie zur Protokollierung an ! Orginal Eingang Nach Ados Ausgang Eingang Frage ADOS ab ! Ausgang Eingang Retour Ausgang Eingang ✁ Vertausche Absender und Empfänger ! Ausgang Eingang Ausgang Ausgang Abbildung B-1 Dekomposition mit aussagekräftigeren Bezeichnungen, zusammengefassten Verbindungen und linearen Aufbau 128 129 9 LITERATURVERZEICHNIS Achermann et al. (2001) ACHERMANN, F. ; LUMPE, M. ; SCHNEIDER, J. ; NIERSTRASZ, 0.: Piccola - a Small Composition Language. In: BOWMAN, H. ; DERRICK, J. (HRSG.): Formal Methods for Distributed Processing, an Object Oriented Approach. Cambridge : University Press, 2001 - in Druck Achermann und Nierstrasz (2001) ACHERMANN, F. ; NIERSTRASZ, O.: Applications = Components + Scripts - A Tour of Piccola. In: ASKIT, M. (HRSG.): Software Architectures and Component Technology. : Kluwer, 2001 - in Druck Allen (1997) ALLEN, R.: A Formal Approach to Software Architect. Doktorarbeit : School of Computer Science Pittsburg, Carnegie Mellon University, 1997 Allen und Garlan (1997) ALLEN, R. ; GARLAN, D.: A Formal Basis for Architectural Connection. ACM Transactions on Software Engineering and Methodology, Bd. 6(4), 1997 Arnold und Härtling (1995) ARNOLD, O. ; HÄRTLING, M.: Virtuelle Unternehmen: Begriffsbildung und -diskussion. Arbeitspapiere der Reihe Informations- und Kommunilationssystem als Gestaltungselement virtueller Unternehmen; 1995 Bellissard et al. (1995) BELLISSARD, L. ; ATALLAH, S. ; ALAIN KERBRAT ; RIVEILL, M.: Component-based Programming and Application Management with Olan. In: Proceedings of the Fifth European Software Engineering Conference. Barcelona, 1995 Bellissard et al. (1996) BELLISSARD, L. ; BEN ATALLAH, S. ; BOYER, F. ; RIVEILL, M.: Distributed Application. In: Proceedings of the 16th International Conference on Distributed Computing Systems (ICDCS’96). Hong Kong, 1996 Bentley und Dourish (1995) BENTLEY, R. ; DOURISH, P.: Medium versus mechanism: Supporting collaboration through customisation.. In: Proceedings of European Computer-Supported Cooperative Work (ECSCW). Stockholm : Kluwer, S. 133148, 1995 Biemans, Schuurman und Swaak (2001) BIEMANS, M. ; SCHUURMAN, J. ; SWAAK, J.: Evaluation of user customisation in e-mail and mobile telephones. Präsentiert auf der First Conference on Universal Access, part of HCI-International 2001. 5-10 August, New Orleans, USA, 2001 Budde und Züllighoven (1990) BUDDE, R. ; ZÜLLIGHOVEN, H.: Software-Werkzeuge in einer Programmierwerkstatt. Berichte der GMD, Bd. 182, 1990 Carter und Henderson (1990) CARTER, K. ; HENDERSON, A.: Tailoring Culture. In: Proceedings of 13th IRIS, 1990 Ciupke und Schmidt (1996) CIUPKE, O. ; SCHMIDT, R.: Components as ContextIndependent Units of Software. In: BERKMANNS, R. ; COINTE, P.(HRSG.): 130 Proceedings of ECOOP Workshop on Composability Issues in Object Orientation / CIOO ´96. Linz : Springer-Verlag, 1996 Cremers und Hibbard (1978) CREMERS, A. ; HIBBARD, T.: Formal Modeling of Virtual Machines. IEEE Transactions on Software Engineering, 4(5) S. 426-436, 1978. Dahrendorf (1961) DAHRENDORF, R.: Elemente einer Theorie sozialen Konflikts. In: DAHRENDORF, R.(HRSG.): Gesellschaft und Freiheit. München, 1961 Davidow und Malone (1993) DAVIDOW, W. ; MALONE, M.: The Virtual Corporation. New York : Harper Collins, 1993 Floyd (1994) FLOYD, C.: Sooftware Engineering - und dann? Informatik Spektrum, 17, S. 29-37, 1994 Floyd, Reisin und Schmidt (1989) FLOYD, C. ; REISIN, F. ; SCHMIDT, G.: STEPS to software development with users. In: ESEC'89 - 2nd European Software Engineering Conference. Bd. 387. Heidelberg : Springer, 1989 Gamma et al. (1996) GAMMA, E. ; HELM, R. ; JOHNSON, R. ; VLISSIDES, J.: Entwurfsmuster : Elemente wiederverwendbarer Software. Bonn : Addison-Wesley, 1996 Gantt und Nardi (1992) GANTT, M. ; NARDI, B.: In: Human Factors in Computing Systems (CHI `92). Monterey, 1992 Garlan, Monroe und Wile (1997) GARLAN, D. ; MONROE, R. ; WILE, D.: Acme: An architecture description interchange language. In: Proceedings of CASCON'97. , 1997 Gosling, Joy und Steele (1996) GOSLING, J. ; JOY, B. ; STEELE, G.: The Java Language Specification. Massachusetts : Addison-Wesley, 1996. ftp://ftp.javasoft.com/docs/specs/langspec-1.0.pdf Gryczan (1996) GRYCZAN, G.: Prozeßmuster zur Unterstützung kooperativer Tätigkeit. Wiesbaden : Deutscher Universitätsverlag, 1996 Hallenberger (2000) HALLENBERGER, M.: Eine 3D Benutzerschnittstelle für komponentenbasierte Anpassbarkeit. Diplomarbeit : Rheinische FriedrichWilhelms-Universität, Institut für Informatik III, Bonn, 2000 Henderson und Kyng (1991) HENDERSON, A. ; KYNG, M.: There's No Place Like Home: Continuing Design in Use. In: GREENBAUM, J. ; KYNG M.(HRSG.): Design At Work. Hillsdale, New Jersey : Lawrence Erlbaum Associates, Publishers, S. 219 – 240, 1991 Hinken (1999) HINKEN, R.: Verteilte komponentenbasierte Anpassbarkeit von Groupware - Eine Laufzeit- und Anpassungsplattform. Diplomarbeit : Rheinische FriedrichWilhelms-Universität, Institut für Informatik III, Bonn, 1999 Iacucci et al. (1998) IACUCCI, G. ; PETERS, R. ; STIEMERLING, O. ; WULF, V.: Telecooperation Systems in Engineering Companies Supplying the Metallurgy Industry The Experience of the OrgTech Project. In: Globlization of Manufacturing LITERATURVERZEICHNIS 131 in the Digital Communications Era of the 21st Century -Innovation, Agility, and the Virtual. Dordrecht : Kluwer, S. 107 – 119, 1998 Johanson (1998) JOHANSON, R.: Groupware: Computer Support for Business Teams. New-York : The Free Press, 1998 Kahler (1995) KAHLER, H.: From Taylorism to Tailorability : Supporting organizations with tailorable software and object orientation. In: Symbiosis of Human and Artifact, Proceedings of HCI'95. Amsterdam : Elsevier, S. 995-1000, 1995 Kilberth, Gryzan und Züllighoven (1994) KILBERTH, K. ; GRYZAN, G. ; ZÜLLIGHOVEN, H.: Objektorientierte Anwendungsentwicklung - Konzepte, Strategien, Erfahrungen. Wiesbaden : Vieweg, 1994 Koch und Teege (1999) KOCH, M. ; TEEGE, G.: Support for Tailoring CSCW Systems: Adaptation by Composition. In: Proc. 7th Euromicro Workshop on Parallel and Distributed ion Languages and Models. Funchal, Portugal : IEEE Press, S. 146152, 1999 Lampson (1974) LAMPSON, B.: Proctection. ACM Operation System Review, 8, S. 18 – 24 1974 Lumpe (1999) LUMPE, M.: A pi-Calculus Based Approach for Software Composition. Doktorarbeit : University of Bern, Institute of Computer Science and Applied Mathematics, Bern, 1999 Mackay (1990) MACKAY, W.: User and customizable Software: A co-Adaptive Phenomenon. Doktorarbeit : MIT, Bosten, 1990 Mackay (1991) MACKAY, W.: Triggers and barriers to customizing software. InProceedings of ACM CHI '91 Human Factors in Computing Systems. New Orleans, Louisianna : ACM/SIGCHI, S. 153-160, 1991 Magee et al. (1995) MAGEE, J. ; DULAY, N. ; EISENBACH, S. ; KRAMER, J.: Specifying Distributed Software Architectures. In: Proceedings of the Fifth European Software Engineering Conference. Barcelona, 1995 Malone und Crowston (1994) MALONE, T. ; CROWSTON, K.: The Interdisciplinary Study of Coordination. ACM Computing Surveys, 1, 1994 McLean et al. (1990) MCLEAN, A. ; CARTER, K. ; LOVSTRAND, L. ; MORAN, T.: Usertailorable systems: Pressing the issues with buttons. In: Proceedings of CHI '90. Seattle, Washington, S. 175 - 182, 1990 Mertens, Griese und Ehrenberg (1998) MERTENS, P. ; GRIESE, J. ; EHRENBERG, D.: Virtuelle Organisationen und Informationsverarbeitung. Heidelberg : Springer, 1998 Minsky (1997) MINSKY, N.: Towards Architectural Invariants of. Rutgers University, 1997 132 Mørch (1997) MØRCH, A.: Three Levels of End-user Tailoring: Customization, Integration and Extension. In: KYNG, M. ; HERNDERSON, H.(HRSG.): Computers and Design in context. : MIT, S. 51 – 76, 1997 Mørch und Mehandjiev (2000) MØRCH, A. ; MEHANDJIEV, N.: Tailoring as Collaboration: The mediating Role of Multiple Representations and Application Units. Computer Supported Cooperative Work (CSCW), 2000 Mørch, Stiemerling und Wulf (1992) MØRCH, A. ; STIEMERLING, O. ; WULF, V.: Tailorable Groupware. SIGCHI Bulletin, 2, 1992 Muller, Haslwanter und Dayton (1992) MULLER, M. ; HASLWANTER, J. ; DAYTON, T.: Participatory practices in the software lifecycle. In: In: HELANDER, M. ; LANDAUER, T. ; PRABHU, P.(HRSG.): Handbook of Human-Computer Interaction. Amsterdam : Elsevier, S. 255 – 313, 1997 Nardi (1993) NARDI, B.: A Small Matter of Programming - Perspective on end user computing. Cambrigde : MIT-Press, 1993 Naur (1992) NAUR, P.: Programming as Theory Building. Computing: A Human Activity, 1992 Nett, Fuchs-Frohnhofen und Wulf (2000) NETT, B. ; FUCHS-FROHNHOFEN, P. ; WULF, V.: Obstacles to Telecooperation in Engineering Networks of the Building Industry. In: Proceedings of the Participatory Design Conference 2000. New York, S. 143 – 147, 2000 Ng und Kramer (1995) NG, K. ; KRAMER, J.: Automated Support for Distributed Software Design. In: Proceedings of 7th International Workshop on Computer-aided Software Engineering (CASE 95). Toronto, Canada, 1995 Nielsen (1992) NIELSEN, J.: Evaluating the thinking aloud technique for use by computer scientists. In: HARTSON, H. ; HIX, D.(HRSG.): Advances in Human-Computer Interaction. Norwood : Ablex Publishing, S. 75-88, 1992 Nierstrasz und Tsichritzis (1995) NIERSTRASZ, O. ; TSICHRITZIS, D.: Object-Oriented Software Composition. New Jersey : Prentice Hall, 1995 Oberquelle (1994) OBERQUELLE, H.: Situationsbedingte und benutzerorientierte Anpassbarkeit von Groupware. In: HARTMANN, A. ; HERRMANN, T. ; RHODE, M. ; WULF, V.(HRSG.): Menschengerechte Groupware - Software-ergonomische Gestaltung und partizipative Umsetzung.. Stuttgart : Teubner, S. 31-50, 1994 Oevermann (1991) OEVERMANN, U.: Genetischer Strukturalismus und das sozialwissenschaftliche Problem der Erklärung der Entstehung des Neuen. In: MÜLLER-DOOHM STEPHAN(HRSG.): Jenseits der Utopie: Theoriekritik der Gegenwart. Franfurt a.M. : Suhrkamp, S. 267-336, 1991 Oevermann (1993) OEVERMANN, U.: Die objektive Hermeneutik als unverzichtbare methodologische Grundlage für die Anaylse von Subjektivität. Zugleich eine Kritik der Tiefenhermeneutik. In: JUNG, T. ; MÜLLER-DOOHM STEPHAN(HRSG.): LITERATURVERZEICHNIS 133 "Wirklichkeit" im Deutungsprozeß: Verstehen und Methoden in den Kultur- und Sozialwissenschaften. Franfurt a.M., S. 106-189, 1993 Oevermann (1996) OEVERMANN, U.: Strukturale Soziologie und Rekonstruktionsmethodologie. Vortrag am 11. November im Rahmen der Ringvorlesung 'Zentrale Themen der Soziologie und Politologie in Frankfurt' zum 25jährigen Bestehen des Fachbereichs Gesellschaftswissenschaften an der Johann Wolfgang Goethe-Universität, Frankfurt am Main;1996. http://www.objektivehermeneutik.de/Fachb-Vortrag-1996.PDF Oevermann (1997) OEVERMANN, U.: Thesen zur Methodik der werkimmanenten Interpretation vom Standpunkt der objektiven Hermeneutik. ; vorlegt bei: 4. Arbeitstagung der Arbeitsgemeinschaft objektive Hermeneutik e.V.; Frankfurt a. M.; April 1997. http://www.rz.uni-frankfurt.de/~hermeneu/Werkimman-Interpret-1997.rtf OMG (1999) OMG: Unified Modeling Language Specification Version 1.3, June 1999. Technischer Bericht; 1999 Oppermann und Simm (1994) OPPERMANN, R. ; SIMM, H.: Adaptability: user-initiated individualisation. In: OPPERMAN, R.(HRSG.): Adaptive user support, Ergonomic design of manually and automatically adaptable software. Hillsdale : Lawrence Erlbaum, 1994 Orlikowski (1989) ORLIKOWSKI, W.: The Duality of Technologie: Rethinking the concept of technology in organizations. Unveröffentlichtes Manuskript, 1989 Page et al. (1996) PAGE, S. ; JOHNSGARD, T. ; ALBERT, U. ; ALLEN, D.: User Customization of a Word Processor. In: Proceedings of CHI '96, S. 14-66, 1996 Peltzer (1998) PELTZER, U.: Auswirkungen neuer Organisationsform. In: SPIEß, E.(HRSG.): Formen der Kooperation: Bedingungen und Perspektiven. Göttingen : Verl. Für Angewandte Psychologie, S. 169-176, 1998 Povey (1999) POVEY, D.: Optimistic Security: A new access control paradigm. In: Proceedings of the 1999 New Security Paradigms Workshop, 1999 Povey (1999b) POVEY, D.: Optimistic Security: A new access control paradigm. Panel Presentation: Highlights of the 1999 New Security Paradigms Workshop. National Information Systems Security Conference (NISSC). Arlington, Virginia, 1999. http://security.dstc.edu.au/staff/povey/presentations/optimistic.ppt Radestock und Eisenbach (1996) RADESTOCK, M. ; EISENBACH, S.: Semantics of a Higher-Order Coordination Language. In: Proceedings of the First International Conference in Coordination Languages and Models. Cesena, Italy, 1996 Roock und Wolf (1999) ROOCK, S. ; WOLF, H.: Die Raummetapher zur Entwicklung kooperationsunterstützender Softwaresysteme für die Organisation. Diplomarbeit : Universität Hamburg, Fachbereich Informatik, Arbeitsbereich Softwaretechnik, Hamburg, 1999 134 Rossen (1984) ROSSEN, M.: The effects of experience on learning, using and evaluating a text-editor. Human Factors, 26, S. 723-728, 1984 Rudinger et al. (1999) RUDINGER, G. ; ESPEY J. ; HOLTE H. ; NEUF H.: Der menschliche Umgang mit Unsicherheit, Ungewissheit und (technischen) Risiken aus psychologischer Sicht. In: G. MÜLLER K. STAPF.(HRSG.): Mehrseite Sicherheit in der Kommunikationstechnik. Bonn : Addison-Wesley, S. 69 – 97, 1999 Sandhu und Samarati (1994) SANDHU, R. ; SAMARATI, P.: Access Control: Principles and Practice. IEEE Communications Magazine, Bd. 9. , 1994 Schneider (1999) SCHNEIDER, J.: Components, Scripts, and Glue: A conceptual framework for software composition. Doktorarbeit : University of Bern, Institute of Computer Science and Applied Mathematics, Bern, 1999 Shen und Dewan (1992) SHEN, H. ; DEWAN, P.: Access Control for Collaborative Environments. In: Proceedings of Computer-Supported Cooperative Work. S. 5158, 1992 Siering (2000) SIERING, P.: E-Mail sicher machen : Sicherheitseinstellung unter Windows. c't, 12, 2000 Sikkel (1997) SIKKEL, K.: A Group-based Authorization Model for Cooperative Systems. In: Proc. European Conf. on Computer Supported Cooperative Work (ECSCW'97). Lancester, S. 345 – 360, 1997 Stevens (2001) STEVENS, G.: Elektronische Archive in Organisationsnetzwerken : Neue Erfordernisse für die Zugriffskontrolle. In: ROHDE, M. ; RITTENBRUCH, M. ; WULF, V.(HRSG.): Auf dem Weg zur virtuellen Organisation : Fallstudien, Problembeschreibungen, Lösungsansätze. Heidelberg : Physica-Verlag, 2001 Stiemerling (1996) STIEMERLING, O.: Anpaßbarkeit von Groupware : Ein regelbasierter Ansatz. Diplomarbeit : Rheinische Friedrich-Wilhelms-Universität, Institut für Informatik III, Bonn, 1996 Stiemerling (1997) STIEMERLING, O.: Supporting Tailorability in Groupware through Component Architectures. In: Proceedings European Conf. on Computer Supported Cooperative Work (ECSCW'97). Lancester, S. 53-57, 1997 Stiemerling (1997b) STIEMERLING, O.: CAT : Component Architecture for Tailorability. Rheinische Friedrich-Wilhelms-Universität, Institut für Informatik III, Bonn, 1997 Stiemerling (1998) STIEMERLING, O.: Komponentenbasierte Anpaßbarkeit von Groupware. In: Proceedings of DCSCW ’98. Dortmund, 1998 Stiemerling (1998) STIEMERLING, O.: FlexiVeans Specifikation : Version 2.0. Rheinische Friedrich-Wilhelms-Universität, Institut für Informatik III, Bonn, 1998 Stiemerling (2000) STIEMERLING, O.: Component-Based Tailorability. Doktorarbeit : Rheinische Friedrich-Wilhelms-Universität, Institut für Informatik III, Bonn, 2000 LITERATURVERZEICHNIS 135 Stiemerling und Cremers (1998) STIEMERLING, O. ; CREMERS, A. B.: The Use of Cooperation Scenarios in the Design and Evaluation of a CSCW System. IEEE Transactions on Software Engineering, 24, S. 1171-1181 1998 Stiemerling und Wulf (2000) STIEMERLING, O. ; WULF, V.: Beyond 'Yes or No' Extending Access Control in Groupware with Awareness and Negotiation. Group Decision and Negotiation 9, Kluwer Academic Publishers, 2000 Stiemerling, Won und Wulf (2000) STIEMERLING, O. ; WON, M. ; WULF, V.: Zugriffkontrolle in Groupware : Ein nutzerorientierter Ansatz. WIRTSCHAFTINFORMATIK, 4, S. 318 – 328, 2000. Suchman (1987) SUCHMAN, L.: Plans and Situated Actions. Cambridge, England : Cambridge University Press, 1987 Sun Microsystems (1997) SUN MICROSYSTEMS: Java Beans : Version 1.01. Technischer Bericht, 1997 Sun Microsystems (1998) SUN MICROSYSTEMS: JavaMail (TM) API Design Specification Version 1.1. Technischer Bericht, 1998 Sun Microsystems (2001) SUN MICROSYSTEMS: Enterprise JavaBeans(TM) 2.0 Specification Final Release. Technischer Bericht, 2001 Sydow et al. (1995) SYDOW, J. ; WINDELER, A. ; KREBS, M. ; LOOSE, A. ; VAN WELL, B.: Organisation von Netwerken : Strukturationstheoretische Analysen der Vermittlungspraxis in Versicherungsnetzwerken. Opladen; : Westdeutscher Verlag, 1995 Szyperski (1998) SZYPERSKI, C.: Component Software : Beyond Object-Oriented Programming. Massachusetts : Addison-Wesley, 1998 Tekinerdogan und Aksit (1996) TEKINERDOGAN, B. ; AKSIT, M.: Adaptability in ObjectOriented Software Development: Workshop Report. In: Special Issues in ObjectOriented Programming - Workshop Reader of the 10th European Conference on Object-Oriented Programming ECOOP '96. S. 7-11, 1996 ter Hofte (1998) TER HOFTE, H.: Working Apart Together - Foundations for Component Groupware”,. Doktorarbeit : Enschede, the Netherlands: Telematica Instituut, , 1998. - http://www.trc.nl/publicaties/1998/wat/wath.pdf Trigg und Bødker (1994) TRIGG, R. ; BØDKER, S.: From implementation to design: tailoring and the emergence of systemization in CSCW. In: Proceedings of the conference on Computer Supported Cooperative Work. S. 45-54, 1994 Weltz, Lullies und Ortmann R.G. (1991) WELTZ, F. ; LULLIES, V. ; ORTMANN R.G.: Häufig geht es bei der Software-Entwicklung gar nicht so sehr um die Sache. COMPUTERWOCHE, 3, 1991 Wernet (2000) WERNET, A.: Einführung in die Interpretationstechnik der Objektiven Hermeneutik. Opladen : Leske + Budrich, 2000 136 Won (1998) WON, M.: Komponentenbasierte Anpaßbarkeit : Anwendung auf ein Suchtool für Groupware. Diplomarbeit : Rheinische Friedrich-Wilhelms-Universität, Institut für Informatik III, Bonn, 1998 Wulf (1994) WULF, V.: Anpaßbarkeit im Prozeß evolutionärer Systementwicklung. GMDSpiegel, 3, 1994 Wulf (1997) WULF, V.: Konfliktmangement bei Groupware. Braunschweig : Vieweg, 1997 Wulf (1999) WULF, V.: On Search of Tailoring Functions : Empirical Finding and Implication for Design. Präsentiert auf der OzCHI `99, 28-30 November 1999. http://www.csu.edu.au/OZCHI99/full_papers/wulf.doc Wulf (2000) WULF, V.: Ecploration Environments: Supporting Users to Learn Groupware. Interacting with Computers, 2, S. 265-299, 2000 Wulf und Rohde (1995) WULF, V. ; ROHDE, M.: Towards an Integrated Organization and Technology Development. In: Proceedings of the Symposium on Designing Interactive Systems. S. 55 - 64, 1995 Wulf, Stiemerling und Pfeifer (1999) WULF, V. ; STIEMERLING, O. ; PFEIFER, A.: Tailoring Groupware for Different Scopes of Validity. Behaviour &Information Technology, 18(3), S. 199 – 212, 1999 Wulf, M. (1995) WULF, M.: Konzeption und Realisierung einer Umgebung rechnergestüzter Tätigkeiten in kooperativen Aarbeitsprozessen. Diplomarbeit : Universität Hamburg, Fachbereich Informatik, Arbeitsbereich Softwaretechnik, Hamburg, 1995 Züllighoven (1992) ZÜLLIGHOVEN, H.: Umgang mit Software oder: Software als Werkzeug und Material. In: COY, W. ; NAKE, F. ; PFLÜGER, J. ; ROLF, A. ; SEETZEN, J. ; SIEFKES, D. ; STRANSFELD, R.: Sichtweisen der Informatik. Braunschweig : Vieweg, S. 141-156, 1992 Züllighoven (1998) ZÜLLIGHOVEN, H.(HRSG.): Das objektorientierte Konstruktionshandbuch nach dem Werkzeug- & Material-Ansatz. Heidelberg : dpunkt, 199 137