Realisierung einer verteilten prozeßgesteuerten Arbeitsumgebung mit ESCAPE+/Merlin Ulrich A. Nickel, Dr. Sabine Sachweh, Prof. Dr. Wilhelm Schäfer, Jörg Wadsack Universität Paderborn Fachbereich 17 AG Softwaretechnik Warburger Straße 100 33098 Paderborn

1 Einleitung Aufgrund der heutigen technischen Möglichkeiten erfolgt Forschung oft in Teams, die häufig verteilt an verschiedenen Orten arbeiten. Die Koordination der Aktivitäten von Forschern im Hinblick auf Versionierung, Konfiguration und Konsistenz bearbeiteter Dokumente ist daher unverzichtbarer Bestandteil einer Arbeitsumgebung. Diese Koordination basiert normalerweise auf einem instituts- oder forschungsbereichsspezifischen Vorgehensmodell, das in diesem Zusammenhang z.B. Verantwortlichkeiten und Abläufe bei der Ableitung und Freigabe von Teilergebnissen an andere Mitglieder des Forschungsteams oder der Konstruktion von Konfigurationen der gemeinsam erarbeiteten Ergebnisse festlegt. Die Konsistenz der Arbeitsergebnisse und damit insbesondere die Koordination nebenläufiger Zugriffe sollte soweit wie möglich automatisch sichergestellt werden, da i.a. die einzelnen Versionen an verschiedenen Orten von verschiedenen Wissenschaftlern erstellt werden und dementsprechend eine manuelle Konsistenzsicherung einen erheblichen Aufwand bedeutet. Diese Aufgabe kann von einer verteilten prozeßgesteuerten Arbeitsumgebung übernommen werden, in die Konfigurations- und Transaktionsmanagementkonzepte integriert sind. Mit Konfigurationsmanagement bezeichnet man im allgemeinen eine oder mehrere der folgenden drei Funktionalitäten: Versionierung von Dokumenten, Verwalten von Konfigurationen, und Verwalten von Änderungen, die auf Dokumenten oder Konfigurationen durchgeführt wurden. Der Begriff Transaktionsmanagement stammt aus dem Datenbankbereich und bezeichnet die Koordination nebenläufiger Zugriffe auf Daten, die von mehreren Personen genutzt werden. Da die Wissenschaftler in einer Arbeitsumgebung gemeinsam auf den Daten, die innerhalb eines bestimmten Projekts erstellt werden, arbeiten, ist eine geeignete Transaktionsmanagement-Unterstützung erforderlich, die nebenläufige Zugriffe auf die unterschiedlichsten Projektdaten synchronisiert.

1

1.1 Allgemeine Ziele des Projektes Die AG Softwaretechnik der Universität-GH Paderborn hat sich im Rahmen des Projektes ‘Multimedia NRW: Die virtuelle Wissensfabrik’ mit der Entwicklung einer Prozeßsteuerungskomponente für eine prozeßgesteuerte, multimediale Arbeitsumgebung (Process Support for Cooperative Work-Umgebung) beschäftigt, die die Zusammenarbeit von Wissenschaftlern nach verschiedenen Vorgehensmodellen (bzw. Prozeßmodellen) koordiniert. Die Koordination basiert auf der Verwaltung von Abhängigkeiten (Hyperlinks) zwischen Dokumenten und der Propagation von Statusänderungen entlang dieser Abhängigkeiten. Die Prozeßsteuerungskomponente wird durch eine Konfigurationsverwaltungskomponente unterstützt, welche die Entwicklung des jeweiligen Projekts protokolliert, die Konsistenz der erstellten Dokumente verwaltet und eine kooperative Bearbeitung von versionierten Projektdaten unterstützt. Bedingt durch die kooperative Bearbeitung der Projektinformation sind Nebenläufigkeitskonflikte unvermeidbar. Diese werden durch ein speziell für diesen Anwendungskontext entwickeltes Transaktionsmanagementkonzept behandelt. Zum Zwecke der Parametrisierung der Arbeitsumgebung wurde eine dedizierte, formal definierte Spezifikationssprache, die auch von Nicht-Informatikern zur Definition von Vorgehensmodellen eingesetzt werden kann, entwickelt. Diese Sprache erlaubt die Definition von Vorgehensmodellen auf einer hohen Abstraktionsebene. Hierbei handelt es sich um eine UML-ähnliche Notation ([BJR97]). Im Gegensatz zu UML wurde die Semantik dieser Sprache jedoch formal definiert. Darüber hinaus wurde im Rahmen dieses Projektes durch die Prozeßsteuerungskomponente ein Interpreter zur Auswertung dieser Vorgehensmodell-Spezifikationen entwickelt, so daß die Spezifikationen direkt ausgeführt werden können. Existierende Sprachansätze zur Beschreibung von Vorgehensmodellen für prozeßgesteuerte Arbeitsumgebungen wie z.B. Marvel [KPBS94], Melmac [Gru91], ARCADIA [TSY+88] oder Merlin [GJW94], haben im Vergleich zum oben skizzierten Ansatz den Nachteil einer sehr programmiersprachennahen Notation. Darüber hinaus fehlt ihnen die Unterstützung durch vordefinierte Basiskonzepte, wie zum Beispiel ein Konfigurations- oder Transaktionsmanagement, was die Komplexität der Spezifikationen signifikant erhöht und oft kaum noch wartbar macht. Ziel dieses Teilprojekts war daher die Entwicklung einer Prozeßsteuerungskomponente mit integriertem Konfigurations- und Transaktionsmanagement für eine prozeßgesteuerte, multimediabasierte Arbeitsumgebung, welche die Zusammenarbeit von Wissenschaftlern nach verschiedenen Vorgehensmodellen (bzw. Prozeßmodellen) koordiniert sowie die Entwicklung einer geeigneten Prozeßmodellierungssprache zur Parameterisierung der Umgebung mit einem bestimmten Vorgehensmodell.

2

1.2 Überblick Im folgenden wird zunächst auf die Prozeßsteuerungskomponente Merlin und die Prozeßmodellierungsprache ESCAPE+ eingegangen. Hierzu ist es notwendig, diesen Ansatz mit den bestehenden Basismodellen des Versions- und Konfigurationsmanagement (VKM) zu vergleichen und die verwendeten Konzepte einzuordnen. weiterhin wird auf die spezielle Problematik des Transaktionsmanagement eingegangen, die sich in dieser Anwendungsdomäne ergeben. Schließlich wird die Integration eines WEB-Interface auf Basis des BSCW-Systems (Basic Support for Cooperative Work) beschrieben.

2 Escape+ und Merlin Zur Realisierung der oben erwähnten Projektziele, wurde ein Lösungsansatz, basierend auf einer Prozeßsteuerungskomponente der Merlin-Umgebung sowie der Prozeßmodellierungssprache ESCAPE, die zur Parameterisierung dieser Umgebung eingesetzt wird, gewählt. In den folgenden Absätzen wird motiviert, warum Merlin/ESCAPE als Ausgangsbasis für diese Arbeiten gewählt wurde.

2.1 Ausgangsbasis Ansätze zur formalen und problemadäquaten Beschreibung von Vorgehensmodellen haben im allgemeinen den Nachteil, daß die Spezifikation in einer sehr programmiersprachennahen Notation (z.B. Adele [BMEN92], APPL/A [TSY+88], ASL [KPBS94]) erfolgt. Dieses Vorgehen bedeutet insbesondere, daß das erstellte Modell aufgrund der mangelnden Abstraktionsmöglichkeiten der Programmiersprache sehr umfangreich und damit sehr schwer wartbar wird. Zudem sind die erstellten Modelle oft kaum oder gar nicht formal analysierbar, und es besteht damit eine hohe Fehlerwahrscheinlichkeit. Im Gegensatz zu diesen Ansätzen reduziert die Prozeßmodellierungssprache ESCAPE [Jun95] die Größe der Spezifikationen durch die Idee, Basiskonzepte vorzudefinieren. Dieser Gedanke ist aus dem Bereich der Modellierung von Informationssystemen übernommen. Betrachtet man die Spezifikation von Datenbankschemata, so werden hierbei Funktionalitäten, wie eine effiziente Selektion von Informationen, unter Zuhilfenahme von Datenbankschlüsseln oder eine Transaktionsverwaltung als gegeben vorausgesetzt. Der wesentliche Vorteil dieses Ansatzes liegt somit darin, daß die Spezifikation des Vorgehensmodells auf ein Minimum beschränkt ist, da prozeß-invariante Anteile wie die Synchronisation von Nebenläufigkeit sowie die automatische Übermittlung aller notwendigen Informationen vordefiniert sind und nicht, wie in anderen Ansätzen (z.B. [BMEN92], [KSW94], [Gru91]), bei jeder Modellierung erneut beschrieben werden müssen. Desweiteren ist ESCAPE an UML ([BJR97]) angelehnt. Insbesondere weisen das Objekt- und Koordinationsmodell in ESCAPE große Ähnlichkeiten zu den Model-

3

len object model und dynamic model in UML auf. Da es sich bei UML um eine weitverbreitete Modellierungssprache auf einer hohen Abstraktionsebene handelt, ist diese leichter erlernbar als eine Programmiersprache, wodurch Anwendern von ESCAPE (insbesondere Nicht-Informatikern) der Einstieg erleichtert wird. Vorgehensmodelle, die in ESCAPE spezifiziert sind, können durch die Prozeßsteuerungskomponente der Merlin-Umgebung ausgeführt werden. Die Prozeßsteuerung der Merlin-Umgebung basiert auf der Verwaltung von Dokumenten, die im Rahmen der Projektarbeit anfallen, und Abhängigkeiten (Hyperlinks) zwischen diesen. Basis für die Koordination der Zugriffe auf diese Dokumente sowie für die Konsistenzverwaltung ist der Zustand, der für jedes Dokument verwaltet wird. Abhängig vom Zustand können unterschiedliche Aktivitäten auf einem Dokument ausgeführt werden, was im folgenden an einem kurzen Beispiel aus dem Chemie-Bereich veranschaulicht werden soll (Abbildung 1). Gibt es ein Dokument ’Experiment’, in dem die Ergebnisse eines Experiments festgehalten werden, dann könnte dieses beispielsweise editiert werden, falls der Zustand ’Experiment_nicht_abgeschlossen’ ist, während eine Aktivität ’Analyse’ zur Auswertung der Ergebnisse ggf. erst im Zustand ’Experiment_abgeschlossen’ Sinn macht. Experiment B Experiment A

Daten_überno

mmen_aus

m Daten_überno

Statistik

men_aus

Herr Schmidt

Mrs. Miller

Abb. 1: Beispiel der verteilten Bearbeitung von Dokumenten Der Zustand eines Dokuments kann sich durch den Aufruf einer Aktivität oder durch das Eintreten eines Ereignisses ändern. So könnte die o.g. Aktivität ’Analyse’ zwei mögliche Folgezustände, z.B. ’Grenzwert_überschritten’ und ’Grenzwert_ok’, haben, die nach Ausführung der Aktivität gesetzt werden. Im Gegensatz dazu werden Ereignisse, sog. Events, ausgelöst, wenn ein Zustandswechsel auf einem anderen Dokument ausgeführt wird. Ein Bedingungs-Event wird auf einem Dokument D ausgelöst, wenn Dokumente, die in einer Abhängigkeitsbeziehung zu D stehen, einen bestimmten Zustand einnehmen. Gibt es in dem oben genannten Szenario, wie in der obenstehenden

4

Abbildung angedeutet, beispielsweise ein Dokument ’Statistik’, in das einzelne Experiment-Daten übernommen werden sollen, falls der Zustand ’Grenzwert_ok’ des Experiments erreicht wird, so kann dies über ein Bedingungs-Event ausgedrückt werden. Dieses Event muß bewirken, daß die ’Statistik’ in den Zustand ’zu_aktualisieren’ wechselt, sobald ein ’Experiment’, dessen Daten in die Statistik einfließen (Abhängigkeit: ’Daten_übernommen_aus’), den Zustand ’Grenzwert_ok’ annimmt. Jeder Benutzer arbeitet in einer individuellen Arbeitsfläche, in der nur die Dokumente anzeigt werden, auf denen Arbeiten für ihn anliegen (Abbildung 2). Die Arbeitsfläche stellt somit eine Sicht auf das Gesamtprojekt dar, d.h. auf alle Dokumente, die vom jeweiligen Wissenschaftler zum gegenwärtigen Zeitpunkt im Rahmen des Projektes bearbeitet werden müssen. Der Vorteil dieses Sichtenkonzeptes besteht vor allem darin, daß die Benutzer nicht durch eine zu große Menge von Dokumenten ’erschlagen’ werden, sondern nur den für sie relevanten Ausschnitt eines Projektes sehen. Darüber hinaus kann ein Benutzer sofort erkennen, wo Arbeiten anstehen, ohne sich erst einen Überblick über den Stand des gesamten Projekts verschaffen zu müssen.











































































Abb. 2: Die Schnittstelle aus Benutzersicht Ergeben sich jedoch Änderungen auf dieser Arbeitsfläche durch externe Einflüsse (z.B. durch Events), so wird dies durch ein Update-Flag in der Arbeitsfläche angezeigt, so daß der Benutzer entsprechend auf die eingetretene Änderung reagieren kann. Für das obige Beispiel bedeutet dies, daß der Statistiker ’Schmidt’ darüber informiert wird, wenn seine Kollegin ’Miller’ ein Experiment abgeschlossen hat, dessen Daten er weiterverarbeiten muß. Events ermöglichen auf diese Weise Zustandsänderungpropagatio-

5

nen entlang der verwalteten Abhängigkeiten zwischen Dokumenten, um so die Konsistenz innerhalb des Projektes sicherzustellen und anstehende Arbeiten zu koordinieren.

2.2 Versions- und Konfigurationsmanagement 2.2.1 Basismodelle Für das VKM existiert eine Vielzahl von Ansätzen. In [Fei91] werden vier Basismodelle definiert, die es erlauben, die existierenden Ansätzen zu strukturieren und bzgl. ihrer Funktionalität zu vergleichen. Diese Basismodelle stammen aus dem Bereich des Softwarekonfiguratinsmanagement. Die nachfolgenden Beschreibungen sind aus [Sac99] entnommen.

Checkin/Checkout-Modell In einem Repository wird die Entwicklungsgeschichte der einzelnen Komponenten eines Softwaresystems verwaltet. Um die einzelnen Komponenten zu bearbeiten holt ein Benutzer Versionen aus dem Repository (Checkout) und stellt sie danach zurück (Checkin). Die Versionen können nur in den benutzereigenen Arbeitsbereichen verändert werden. Während eine Version im Arbeitsbereich des Benutzers liegt, steht sie nicht unter Kontrolle: d.h. andere Benutzer können auf diese Version nicht zugreifen. Konkurrierende Zugriffe werden durch Sperren kontrolliert. Sperren werden auf einzelnen Versionen oder auf Pfaden gesetzt. Hält ein Benutzer eine Sperre, kann nur dieser Änderungen vornehmen. Desweiteren wird die Vergabe von Zugriffsrechten für das Repository, d.h. der eingeschränkte Zugriff auf Versionen, von einigen Werkzeugen unterstützt. Beispiele für dieses Modell sind SCCS [Roc75] und RCS [Tic82].

Kompositions-Modell Dieses Modell ist eine Erweiterung des Checkin/Checkout-Modells. Die versionierten Komponenten des Repositorys werden in einem zweistufigen Ansatz konfiguriert. Die Komponenten eines Systems werden in der ersten Stufe festgelegt. In der zweiten Stufe werden dann Versionsauswahlregeln definiert. Durch die Anwendung dieser Regeln wird dann für jede Komponente eine Version ausgewählt. Die Systemversion besteht dann aus diesen ausgewählten Versionen jeder Komponente (Abbildung 3). Beispiele hierfür sind Shapetool [ML88a], [ML88b], Adele [BMEN92], DSEE [LCS88] und ClearCase [Leb94].

6

V 1.0

V 1.0

V 2.0

V 3.0

V 3.1

V 4.0

V 2.0

V 1.0

V 2.1

V 2.0

V 3.2

V 3.0

V 3.0

V 4.1

V 4.0

V 4.0

Komponente 1

Komponente 2

V 2.1

V 2.2

V 3.1

Komponente 3

Systemversion 1.1 Abb. 3: Kompositions-Modell

Transaktions-Modell Wie das vorangegangene Modell, erweitert das Transaktions-Modell das Checkin/ Checkout-Modell um das Konfigurieren von Komponenten. Allerdings werden hier Versionen des Gesamtsystems verwaltet, d.h. die explizite Konstruktion von Systemversionen entfällt. Die einzelnen Versionen der Komponenten werden implizit verwaltet. Eine neue Systemversion entsteht, wenn eine Komponente (dementsprechend eine Version davon) hinzugefügt wird oder eine Komponente modifiziert wird, d.h. eine neue Komponentenversion entsteht (Abbildung 4). Beispiele für das Transaction Modell sind TeamTools [Mac95], DaSC [Mac95], NSE [AHM89], [Mil89], PIE [GB80] und Gandalf [KMS89].

Change-Set-Modell Dieses Modell basiert auf der Versionierung von Änderungen, und nicht wie die bisher beschrieben auf Versionen von Komponenten. Die Änderungen werden in Mengen (Change-Set) verwaltet. Ein Change-Set ist eine logisch zusamenhängende Menge von Änderungen, die an den einzelnen Komponenten durchgeführt wurden. Wie bei dem Composition Modell werden die Systemversionen explizit zusammengestellt. Eine Systemversion besteht dann aus der Basis und mehreren Change-Sets, die auf die Basis angewendet werden. Da Change-Sets aufeinander aufbauen können, müssen komplexe Abhängigkeiten verwaltet werden. In Abbildung 5 beispielsweise darf bzw. kann der

7

V 1.0

V 1.0

Systemversion 1.0

V 1.0

V 1.0

V 2.0

Systemversion 2.0

V 2.0

V 1.0

V 2.0

Systemversion 3.0

V 2.1

V 1.0

V 2.1

Systemversion 3.1

V 2.1

V 1.0

V 2.2

Systemversion 3.2

SV 1.0

SV 2.0

SV 3.0

SV 3.1

SV 3.2

Abb. 4: Transaktions-Modell Change-Set C2 des Change-Set 2 nur angewendet werden, wenn die Änderungen des Change-Set C1 (im Change-Set 1) vorgenommen wurden, d.h. die Version V 2.0 muß vorliegen. Bei größeren Systemen erhöht sich dementsprechend die Komplexität der Abhängigkeiten. Ein Beispiel für dieses Modell ist Aide-de-Camp von Software Maintenance and Development Systems Inc. [Mac95]. V 1.0

Baseline V 1.0

Change-Set

V 1.0

SV 1.0

Baseline

+

C1

Baseline Change-Set 1

SV 2.0

+

SV 3.0

V Change-Set

C1

C2

V 2.0 Komponente 1

Baseline

+

Change-Set1 Change-Set2

V 3.0 Komponente 2

Komponente 3

Abb. 5: Change-Set-Modell

Zusammenfassung Das Versions- und Konfigurationsmanagement wird von den vier Basismodellen auf unterschiedliche Weise und in unterschiedlichem Umfang unterstützt. Das Checkin/ Checkout-Modell unterstützt nur das Versionsmanagement, während die drei anderen Modelle auch das Konfigurationsmanagement unterstützen. Das Kompositions-Modell und das Transaktions-Modell bauen bezüglich der Versionierung auf das Checkin/ Checkout-Modell auf, während das Change-Set-Modell Versionen von Änderungen

8

verwaltet. Für das Konfigurationsmanagement verfolgen das Komposition-, das Transaktion- und das Change-Set-Modell drei verschiedene Ansätze. Sie sind jeweils Komponenten-, System- und Änderungsorientiert. Die Konsistenzsicherung bei der Teamarbeit fällt bei dem system- und änderungsorientierten Konfigurationsmanagement leichter, weil auf Konfigurationen gearbeitet wird. Bei dem komponentenorientierten Ansatz ist die feine Granularität von Vorteil bezüglich der Teamarbeit. Durch das Arbeiten auf „kleinen“ Komponenten wird die Anzahl der Personen, die eine Komponente bearbeiten, geringer. Grobe Granularität führt dementsprechend häufiger zu Nebenläufigkeitskonflikten. Eine umfassende Unterstützung des VKM kann nur gewährleistet werden, wenn die Vorteile der vier Basismodelle miteinander kombiniert werden. Ein ausführlicher Überblick über das VKM in der Softwareentwicklung ist in [CW98] gegeben.

2.2.2 Der Ansatz von Merlin/ESCAPE+ Merlin ist ein Prototyp einer prozeßorientierten Software-Entwicklungsumgebung, der auf Basis der Entwicklung der Spezifikationssprache ESCAPE+ entstanden ist. Das Kompositions- und das Transaktions-Modell sind in diesem Ansatz kombiniert, um eine umfassende Unterstützung des VKM in der Softwareentwicklung zu erreichen. Zuerst werden wir die Sprache ESCAPE+ kurz vorstellen und anschließend auf die Umgebung Merlin eingehen.

ESCAPE+ ESCAPE+ ist eine an UML angelehnte Spezifikationssprache und eine Erweiterung von ESCAPE1 ([Jun95]). Eine objektorientierte Prozeßspezifikation bietet sich an, um eine VKM-technisch sinnvolle Modellierung von Prozeßmodellen zu unterstützen: Das Konzept der Objektorientierung ermöglicht VKM-spezifische Vorgaben in vordefinierten Klassen zu verkapseln. Wenn der Prozeßmodellierer dann im Rahmen der Prozeßbeschreibung Unterklassen der vordefinierten Klassen anlegt, wird die Einhaltung die VKM-spezifischen Vorgaben gewährleistet. ESCAPE+ nutzt die Vererbung für die Festlegung firmenspezifischer Strategien zur Konfigurationsverwaltung, um damit den Aufwand einer projektspezifischen Anpassung zu minimieren. ESCAPE+-Spezifikationen bestehen aus drei Komponenten: dem Objektmodell, dem Koordinationsmodell und dem Organisationsmodell (Abbildung 6). Die Übersichtlichkeit einer Spezifikation wird durch diese Dreiteilung erhöht. Die Trennung der strukturellen und dynamischen Anteile des zu spezifizierenden Prozesses hat den Vorteil, daß dedizierte Sprachanteile logisch voneinander getrennt beschrieben werden.

1. EER-model and Statecharts Combined for an Advanced Process Engineering

9

Koordinationsmodell: dynamischer Aspekt

Prozeß beschreibung

Organisationsmodell: organisatorischer Aspekt

Objektmodell: struktureller Aspekt

ist Bestandteil von wechselseitige Abhängigkeit

Abb. 6: Die drei Modelle einer ESCAPE+-Prozeßbeschreibung Das Objektmodell ist in zwei Modelle unterteilt: das Dokumentenmodell und das Systemmodell (Abbildung 7). Das Objektmodell beschreibt im wesentlichen die Dokumentklassen (wie z.B. Spezifikation, Module oder Testpläne), die während des Prozesses entstehen, im Dokumentenmodell. Im Systemmodell können, zur besseren Strukturierungen, die Dokumentklassen zu Systemklassen zusammengefaßt werden. Das Dokumentmodell und das Systemmodell bestehen aus einer Klassenhierarchie im Sinnen eines objektorientierten EER-Modells. Der Prozeßspezifizierer definiert Dokumentklassen und Systemklassen als Unterklassen der vordefinierten Klassen. Einzelheiten über die Beziehungen zwischen den Klassen sind in [SS96] und [Sac99] beschrieben. Dokument

Subsystem

darstellung: icon =

editierbares Dokument

voll_editierbares Dokument

darstellung: icon =

vollgeneriertes_ Dokument

Design_ System

Implementierung

teilgeneriertes_ Dokument

Dokumentmodell

Subsystemmodell

Abb. 7: Beispiel eines Objektmodells

10

Das Koordinationsmodell (Abbildung 8) beschreibt die Dynamik des Prozeßmodells durch Statecharts [Har87]. In ESCAPE+ werden die Statecharts zur Beschreibung der Koordination auf Typebene eingesetzt. Für jede Klasse des Objektmodells enthält das Koordinationsmodell ein Statechart. Die Vererbungsbeziehungen zwischen den Klassen des Objektmodells spiegeln sich im Koordinationsmodell wieder. Das Statechart einer Klasse muß die Verfeinerung des Statecharts der Oberklasse sein. Weitere Einzelheiten sind wiederum in [SS96] und [Sac99] beschrieben. Dokument [*]

/löschen

/generieren

/anlegen existent [*]

/bearbeiten

/propagieren

Abb. 8: Beispiel eines Koordinationsmodells der Klasse Dokument

Das Organisationsmodell legt die Organisation eines Entwicklungsteams, d.h. den organisatorischen Aspekt des Prozesses, fest. Welche Rollen anderen vorgesetzt sind, wird in einer Rollenhierarchie definiert (Abbildung 9). Die Verantwortlichkeiten jeder Rolle in der Rollenhierarchie werden in einer Rollendefinition konkret festgelegt. Die mit den Rollen in Zusammenhang stehenden Lese- und Schreibrechte werden ebenfalls in der Rollendefinition vorgegeben. Ausführliche Beschreibungen dieses Modell finden sich in [Jun95] und [Sac99].

ROOT

ProjectManager

Rolle ChiefDesigner

Rolle+Änderungsmanager

ChiefDeveloper

hat_manager Designer

Developer

Abb. 9: Die Rollenhierarchie des Organisationsmodells

11

Die Anbindung der Prozeßmodellierungssprache ESCAPE+ and die Prozeßsteuerungskomponente Merlin erfolgt über die Generierung von Prologfakten, welche von den in Merlin vordefinierten Regeln zur Ausführung gebracht werden (Abbildung 10).

ESCAPE+

Prologfakten Merlin

Prologregeln Das Konfigurationsmanagementsysteme Merlin bietet eine ähnliche Unterstützung wie viele andere vorhandene VKM-Umgebungen. Der wesentliche Vorteil von Merlin ist jedoch seine Abb. 10: Integration von Merlin und hervorragende Anpaßbarkeit aufgrund ESCAPE+ von ESCAPE+ Spezifikationen. Dabei stützt sich Merlin auf folgende Konzepte: Versionsmanagement, Konfigurationsmanagement, Prozeßverwaltung, benutzerspezifische Arbeitsflächen und Transaktionsmanagement. Das Versionsmanagement in Merlin verwaltet Versionen von Dokumenten und Systemen. In Merlin sind die Vorteile der komponenten- und systemorientierten Ansätze kombiniert. In Hinblick auf die Entwicklung im Team ist ein wesentlicher Vorteil von Merlin, daß der Entwickler auf einer Version des gesamten Systems arbeitet. Dieser Vorteil, der von dem systemorientierten Ansatz herrührt, wird noch durch einen koordinierten Zugriff auf geteilte Informationen auf verschiedenen Granularitätsebenen untermauert. Flexibilität wird durch den komponentenorientierten Ansatz erreicht. Die Möglichkeit, im Sinne der Wiederverwendung, Komponenten aus verschiedenen Versionen eines Gesamtsystems oder aus verschiedenen Gesamtsystemen zu kombinieren, ist in Merlin gegeben. Eine ausführliche Beschreibung der Arbeitsflächen (Benutzeroberflächen) und der Unterstützung des Prozeßspezifizierer in Merlin, wird in [JPSW94] beschrieben. Durch die in Merlin vordefinierten Regeln, werden die in ESCAPE+ vorgenommenen Spezifikationen um ein vielfaches vereinfacht, da der Benutzer anwendungsspezifische Sachverhalte, wie z.B. das Transaktionsmanagement für das verteilte Arbeiten, nicht mehr explizit definieren muß. Dadurch bleiben die Statecharts überschaubar. Die Transaktionsmanagement-Unterstützung wird im folgenden näher beschrieben.

12

2.3 Transaktionsmanagement-Unterstützung Da die Wissenschaftler in dieser Arbeitsumgebung gemeinsam auf einer Version des Gesamtprojekts arbeiten, ist eine geeignete Transaktionsmanagement-Unterstützung erforderlich, die nebenläufige Zugriffe synchronisiert, um einen inkonsistenten Datenbestand zu vermeiden. Ziel dieses Transaktionsmanagements ist eine intensive Kooperation, die auf das Vorgehensmodell abgestimmt ist und auf die aktuelle Projektsituation angepaßt werden kann. Gleichzeitig muß das Transaktionsmanagement auch die Konsistenz der verwalteten Daten sicherstellen. Die Vermeidung nebenläufiger Zugriffe, die innerhalb verschiedener Transaktionen durchgeführt werden, basiert in Transaktionsmanagement-Ansätzen im allgemeinen auf der Vergabe von Sperren. Wie bereits zu Beginn dieses Berichts erwähnt, reichen die aus dem Bereich der Datenbanken bekannten Konzepte bzgl. der zu vergebenden Sperren sowie der Lösung von Konflikten nicht aus, um eine maximale Kooperation der Projektmitarbeiter zu gewährleisten. Daher werden in dem Ansatz der Wissenschaftler-Arbeitsumgebung neben pessimistischen Lese- und Schreibsperren auch optimistische Lese- und Schreibsperren und eine Lese/Schreibsperre unterschieden. Wird letztere Sperre beispielsweise auf einer Objektversion O von einer Transaktion eines Wissenschaftlers ’Schmidt’ gehalten, so dürfen andere Benutzer parallel temporäre Varianten von O anlegen und diese bearbeiten, während jedoch ausschließlich die Version von ’Schmidt’ dem Gesamtprojekt angehört und somit direkt zurückgeschrieben wird. Die Arbeiten der Kollegen können jedoch anschließend durch eine Mischoperation mit der Arbeit von ’Schmidt’ integriert werden. Eine optimistische Schreibsperre ist der Lese/Schreibsperre sehr ähnlich. Der Unterschied besteht im wesentlichen darin, daß mehrere Benutzer auf temporären Varianten arbeiten und die Arbeit desjenigen Benutzers ins Gesamtprojekt aufgenommen wird, der zuerst fertig ist. Auf die anderen Sperren soll an dieser Stelle nicht weiter eingegangen werden, da deren Semantik analog zu Sperren aus dem DB-Bereich ist. Neben verschiedenen Sperren werden auch mehrere Transaktionstypen, die mit verschiedenen Prioritäten belegt sind, unterschieden: konsistenzsichernde, Design- und automatisierende Transaktionen. Der Typ einer Transaktion bestimmt die Lösung eines Konfliktfalls. Sind an einem Konflikt Transaktionen verschiedenen Typs beteiligt, so gewinnt die Transaktion mit der höheren Priorität. Ist die Priorität gleich, so ist die Lösung abhängig von den gesetzten Sperren und ihrer Kompatibilität. Im Rahmen einer konsistenzsichernden Transaktionen laufen Aktivitäten und Statusänderungspropagationen ab, die zur Konsistenz des Gesamtprojekts beitragen sollen. Daher besitzt dieser Transaktionstyp die höchste Priorität. Prioritätsmäßig darunter liegen die Designtransaktionen, die Aktivitäten beinhalten, in denen ein Wissenschaftler interaktiv Daten bearbeitet. Die geringste Priorität besitzen die automatisierenden Transaktionen, in denen die Prozeßsteuerungskomponente Aktivitäten ausführt, um den Prozeß voranzutreiben, wie z.B. komplizierte Rechnungen durchzuführen, die keine Benutzer-

13

interaktion erfordern. Muß aufgrund der oben beschriebenen Konfliktlösung eine Designtransaktion abgebrochen werden, so wird auf jeden Fall die Arbeit des Wissenschaftlers in einer temporären Variante gesichert, so daß sie nicht verloren ist und zu einem späteren Zeitpunkt ggf. wieder in das Projekt eingebracht werden kann. Da durch das spezifizierte Vorgehensmodell bekannt ist, auf welche Objektversionen durch eine Aktivität zugegriffen werden und wie (lesend oder schreibend) der Zugriff erfolgt, kann das Transaktionsmanagement sehr genau darauf abgestimmt werden. Prinzipiell ist es jedoch jederzeit während des Projektablaufs für einen Benutzer möglich, den so bestimmten Transaktionsschutz zu verschärfen.

2.4 BSCW-Anbindung Zur Realisierung einer Arbeitsumgebung zur Unterstützung der kooperativen Zusammenarbeit von Wissenschaftlern (Process Support for Cooperative Work), wurde die Prozeßsteuerungskomponente der Arbeitsumgebung mit einem ein Web-Interface ausgestattet, das den Zugang zur Arbeitsumgebung für einen Wissenschaftler darstellt. Da die GMD mit BSCW bereits eine gute Basis für eine Web-basierte Arbeitsumgebung geschaffen hatte, sollte die Benutzungsschnittstelle der prozeßgesteuerten Wissenschaftler-Arbeitsumgebung durch das BSCW-System realisiert werden. Dazu mußte eine Anbindung zwischen BSCW und der Prozeßsteuerungskomponente geschaffen werden, über die alle für die Interaktion mit dem Wissenschaftler benötigten Daten ausgetauscht werden können. Der BSCW-Ansatz basiert auf dem Kompositions-Modell und unterstützt verteiltes Arbeiten an einem Softwaresystem. Das Ziel des BSCW Systems ist das flexible Teilen von Information innerhalb einer räumlich verteilten Arbeitsgruppe unabhängig von dem Typ der Information. Das BSCW System basiert auf der Idee des geteilten Arbeitsraumes (shared workspace), der von den Mitgliedern einer Gruppe eingerichtet wird, um ihre Arbeit zu organisieren und zu koordinieren. In BSCW ist der geteilte Arbeitsraum durch ein Repository realisiert, welches mit Kennungen und Passwörtern von den Mitgliedern erreichbar ist. Ein BSCW Server verwaltet mehrere solcher Arbeitsräume für verschiedenen Gruppen. Ein Benutzer kann Mitglied von mehreren Arbeitsräumen sein, z.B. kann jeweils ein Arbeitsraum mit einem Projekt des Benutzer übereinstimmen. Der BSCW-Server ist ein Web-Server, der von dem BSCW-System, mit Hilfe von CGI (Common Gateway Inteface), erweitert ist. Ein Arbeitsraum kann verschiedene Informationen enthalten, wie Dokumente, Bilder, Referenzen (links) zu Web-Seiten oder FTP sites, usw. Der Inhalt eines Arbeitsraumes wird durch Informationsobjekte, die in einer Verzeichnisstruktur angeordnet sind, repräsentiert. Die Mitglieder können die Informationen von ihren Rechnern in den Arbeitsraum transferieren und Zugriffsrechte bzgl. der Sichtbarkeit und Ausführbarkeit auf die Informationen setzen. Mitglieder können über eine HTML-Referenz Informationsobjekte runterladen, verändern und weitere Einzelheiten über diese anfragen. Nach jeder ausgeführten Arbeitsraum-Operation auf

14

dem BSCW Server, schickt der Server eine neue HTML-Seite mit dem aktuellen (neuesten) Stand des Arbeitsraumes zurück. Ausführliche Beschreibungen des BSCW Systems finden sich in [BHST95], [BAB+97], [BA97], [BHT97] und [HB97]. In Zusammenarbeit mit der GMD wurde zunächst die konzeptionelle Definition einer Schnittstelle erstellt, die in eine konkrete Spezifikation in einer CORBA-IDL ähnlichen Notation umgesetzt wurde. Bedingt durch die veränderte Benutzungsphilosophie eines Web-Browser basierten Front-Ends gegenüber der bisherigen Benutzungsschnittstelle, mußte die an der Schnittstelle angebotenen Funtionalität und das über die Schnittstelle abgewickelte Protokoll speziell angepaßt werden. Basierend auf dieser Definition wurde zunächst die alte Kommunikations-Schnittstelle der Prozeßsteuerungskomponente reimplementiert sowie eine Implementierung der erweiterten und neuen Nachrichten vorgenommen. In der Folge ergab sich, daß die vollkommen verschiedenen Basiskonzepte der (ehemaligen) Benutzungsschnittstelle mit der die Prozeßsteuerungskomponente kommuniziert hat und der neuen Schnittstelle zu BSCW, zu geänderten Anforderungen an die Prozeßsteuerung führten. So war die Prozeßsteuerung mit alter Schnittstelle, die jederzeit in einem kontrollierten Zustand war, zum Beispiel in der Lage, bestimmte Annahmen über die Gültigkeit von Anfragen von der Benutzungsschnittstelle an die Prozeßausführungskomponente zu machen - im wesentlichen gab es keine ungültigen Anfragen. Diese Voraussetzung gilt nun nicht mehr, da in WWW-Browsern z.B. durch den beliebten ‘Back‘-Button im Sinne der Prozeßausführung nicht mehr gültige Seiten und damit nicht mehr gültige Daten zurückgeholt und entsprechend auch nicht gültige Anfragen gestellt werden können.

Prozeßspezifikation

Prozeßsteuerungskomponente

Die Prozeßsteuerungskomponente übernimmt die Ausführung einer ESCAPE+-Spezifikation und realisiert damit die dynamische Semantik der Sprache (Abbildung 11). Um die Vollständigkeit der Sprachdefinition von ESCAPE+ zu überprüfen wurde bereits während der Sprachdefinition die dynamische Semantik dieser Konstrukte in der Prozeßsteuerungskomponente realisiert.

Prozeßsteuerungskonzepte (Prolog-Spezifikation)

Prolog-Interpreter Schnittstelle zu BSCW

Abschließend sei noch erwähnt, Abb. 11: Integration von Merlin/ESCAPE+ daß Merlin in der Lage ist feingraund BSCW nulare Abhängigkeiten zwischen Dokumenten zu verwalten. Die Möglichkeit syntaxgesteuerte Werzeuge auzunutzen ist also in Merlin gegeben. Diese

15

wesentlich bessere Unterstützung wurde durch die Ausrichtung des Versions- und Konfigurationsmanagement dieser Werkzeuge auf die Kooperation und Konsistenzsicherung erreicht ([SS95]).

3 Ausblick In diesem Bericht wurde die Realisierung einer verteilten prozeßgesteuerten Arbeitsumgebung beschrieben, welche auf der Integration der Prozeßmodellierungssprache ESCAPE+ und der Prozeßsteuerungskomponente Merlin basiert. Dabei wurden unter anderem die drei Sichten einer ESCAPE+-Spezifikation vorgestellt. Insbesondere die Ähnlichkeit einer ESCAPE+-Spezifikation mit Teilen der UML legt die Integration weiterer UML-Diagramme zur Spezifikation von Vorgehensmodellen nahe. Hierzu wurde in der AG-Softwaretechnik ein Werkzeug entwickelt (FUJABA), welches außer Statecharts und Klassendiagrammen auch Kollaborationsdiagramme und Sequenzdiagramme unterstützt. Hiermit wäre es möglich, Szenarien zu spezifizieren, welche zur Formulierung von Anforderungen an das Vorgehensmodell oder zur Generierung von Testfällen verwendet werden könnten. Das Werkzeug FUJABA generiert z.Z. aus UML ausführbaren JAVA-Code. Um die Merlin-Prozeßsteuerungskomponente weiterhin nutzen zu können und somit eine langsame Migration von der ESCAPE+ zu der neuen FUJABA-Umgebung zu ermöglichen, wäre es notwendig, die für die Generierung von JAVA-Code verantwortliche „JAVAFactory“ durch eine entsprechende „Prolog-Factory“ zu ersetzen.

16

Literatur [AHM89]

E. W. Adams, M. Honda, and T.C. Miller. Object Management in a CASE Environment. In Proc. of the 11th International Conference an Software Engineering, Pittsburg, Penn., pages 154-163. IEEE Computer Society Press, 1989.

[BJR97]

Booch, G., Jacobson, I. und Rumbaugh, J., Unified Modeling Language (UML), Rational Software Corporation, Santa Clara, CA, version 1.1 edition, 1997

[BA97]

R. Bentley and W. Appelt. Designing a System for Cooperative Work on the World-Wide Web: Experiences with the BSCW System. In Proc. of HICSS‘30: The Hawaii International Conference on the System Sciences, Maui, Hawaii. IEEE Computer Society Press, 1997.

[BAB+97]

R. Bentley, W. Appelt, U. Busbach, E. Hinrichs, D. Kerr, S. Sikkel, J. Trevor, and G. Woetzel. Basic Support for Cooperative Work on the World Wide Web. In International Journal of Human-Computer Studies 46(6): Special issue on Innovative Applications of the World Wide Web, p. 827-846. Academic Press, 1997.

[BHST95]

R. Bentley, T. Horstmann, K. Sikkel, and J. Trevor. Supporting Collaborative Information Sharing with the World Wide Web: The BSCW Shared Workspace System. In The World Wide Web Journal: Proceedings of the 4th International WWW Conference, Issue 1, pages 63-74. O‘Reilly, 1995

[BHT97]

R. Bentley, T. Horstmann, and J. Trevor. The World Wide Web as enabling technology for CSCW: The case of BSCW. In Computer-Supported Cooperative Work: Special issue on CSCW and the Web, Vol. 6. Kluwer Academic Press, 1997.

[BMEN92]

N.Belkhatir, W. L. Melo, J. Estublier, and A. M. Nacer. Supporting software maintenance evolution process in the Adele system. In C. M. Pancake and D. S. Reeves, editor, Proceedings of the 30th Annual ACM Southeast Conference, Raleigh, NC. ACM, pages 165–172, 1992.

[CW98]

R. Conradi, B. Westfechtel. Version models for software configuration management. ACM Computing Surveys 30, 2 (June), 1998, pp. 232282.

[Fei91]

P. H. Feiler. Configuration Management Models in Commercial Environments. Technical Report CMU/SEI-91-TR-7, ESD-9-TR-7, 1991.

[GB80]

I. P. Goldstein and D. G. Bobrow. A Layered Approach to Software Design. Technical Report CSL-80-5, XEROX PARC, PaloAlto, 1980.

[GJW94]

W. Schäfer, G. Junkermann, B. Peuschel and S. Wolf. MERLIN: Supporting Cooperation in Software Development through a Knowledgebased Environment. In A. Finkelstein, editor, Advances in Software Process Technology. John Wiley & Sons, pages 103–129. 1994.

17

[Gru91]

V. Gruhn. The Software Process Management Environment MELMAC. In A. Fugetta, R. Conradi and V. Ambriola, editors, Proceedings of the 1st European Workshop on Software Process Modeling, Milan, Italy. A.I.C.A. Press, pages 191–201, May 1991.

[Har87]

D. Harel. Statecharts: A visual formalism for complex systems. Science of Computer Programming, 8, pages 231-274, 1987.

[HB97]

T. Horstmann and R. Bentley. Distributed Authoring on the Web with the BSCW Shared Workspace System. In ACM Standards View 5(1). ACM Press, 1997.

[JPSW94]

G. Junkermann, B. Peuschel, W. Schäfer, and S. Wolf. Merlin: Supporting Cooperation in Software Development through a Knowledge-based Environment. Software Process Modelling and Technology, A. Finkelstein, J. Kramer, and B. Nuseibeh (Editors), Research Studies Press, John Wiley & Sons, pages 103-129, 1994.

[Jun95]

G. Junkermann. ESCAPE - Eine graphische Sprache zur Spezifikation von Software-Prozessen. Dissertation Universität Dortmund, Fachbereich Informatik, 1995.

[KMS89]

C. W. Krueger, D. B. Miller, and R. G. Stockton. An Inverted Approach to Configuration Management. In J. F. H. Winkler and W. F. Tichy (Editors), Proc. of the 2nd International Wokshop on Software Configuration Management, Princeton, USA. ACM, pages 1-4, 1989.

[KPBS94]

G. E. Kaiser, S. Popovich, and I. Z. Ben-Shaul. A Bi-Level Language for Software Process Modeling. In W. F. Tichy, editor, Configuration Management. John Wiley & Sons, pages 39–72, 1994.

[KSW94]

N. Kiesel, A. Schürr, and B. Westfechtel. GRAS, a Graph-Oriented Database System: Data Model, Functionality and Applications. In R. King, editor, Workshop on the Intersection Between Databases and Software Engineering, Sorrento, Italy. IEEE Computer Society Press, pages 6468, 1994.

[LCS88]

D. B. Leblang, R. P. Chase, and H. Spilke. Increasing Produktivity with a Parallel Configuration Manager. In J. F. H. Winkler (Editor), Proc. of the 1st International Wokshop on Software Version and Configuration Control, Grassau, FRG. Teubner, pages 21-38, 1988.

[Leb94]

D. B. Leblang. The CMChallenge: Configuration Management that Works. In W. F. Tichy (Editor) Configuration Management. John Wiley & Sons, pages 1-37, 1994.

[Mac95]

S. A. MacKay. An Evaluation of Configuration Management Systems and Tools. In Proc. of the 5th Software Configuration Management Workshop, April 24-25, Seattle, USA, 1995. Unpublished.

[Mil89]

T. Miller. Configuration Management wiyh the NSE. In G. Goos and J. Hartmanis (Editors), Proc. of the International Workshop on Environments, Chinon, France. Springer, LNCS 467, 1989.

18

[ML88a]

A. Mahler and A. Lampen. An Integrated Toolset for Engineering Software Configurations. In P. Hendersons (Editor), Proc. of the ACM SIGSOFT/SIGPLAN Software Engineering Symposium on Practical Software Engineering Environments, Boston, MA. SIGPLAN NOTICES 24(2), pages 191-200, 1988.

[ML88b]

A. Mahler and A. Lampen. An Object Base for Attributed Software Objects. In Proc. of the EUUG Autumn ‚88 Conference, Cascais, Portugal, pages 95-105. European UNIX User Group, London, 1988.

[Roc75]

M. J. Rochkind. The Source Code Control System. In IEEE Transactions on Software Engineering, 1(4), pages 364-370, 1975.

[Sac99]

S. Sachweh. Ein Kooperatives Konfigurationsmanagementsystem. Dissertation Universität Paderborn, Fachbereich Mathematik/Informatik, 1999.

[SS95]

S. Sachweh and W. Schäfer. Version Management for tightly integrated Software Engineering Environments. In M. Verall (Editor), Proc. of the 7th International Conference on Software Engineering Environments, Noordwijkerhout, The Netherlands. IEEE Computer Society Press, pages 21-31, 1995.

[SS96]

S. Sachweh, W. Schäfer: Objektorientierte Spezifikation und Realisierung einer Umgebung für das Konfigurationsmanagement. Softwarerechnik (ST) ‘96, Koblenz, 1996.

[Tic82]

W. F. Tichy. Design, Implementation, and Evaluation of a Revision Control System. In Proc. of the 6th International Conference on Software Engineering, pages 58-67, ACM, 1982.

[TSY+88]

R. N. Taylor, R. W. Selby, M. Young, F. C. Belz, L. A. Clarce, J. C. Wileden, L. Osterweil, and A. L. Wolf. Foundations of the Arcadia Environment Architecture. In R. N. Taylor, editor, Proceedings of the ACM SIGSOFT/SIGPLAN Software Engineering Symposium on Practical Software Development Environments, Boston, Massachusetts. Software Engineering Notes, 13(5), pages 1–13, November 1988.

19