Home

Thesis - RWTH Publications

1. ceeeeeeeeeeseeeeeeeeeeeeneeseeeeeeeeeees 167 7 1 Die PRIME Gesamtarchitektur ussssssosssonsssosssnnssnssnnnsnnnsnnnsnonsnnnsnonnnne 168 7 1 1 Framework basierter Entwurfsansatz ssessennsenneennsenneennnenn een 168 7 1 2 berblick ber die Gesamtarchitektur eeeeeeennnen 170 7 1 2 1 Werkzeuge der Durchf hrungsdom ne eeeeneen 171 TL22 Prozessm schine s c nes hereain ehe 172 7 1 2 3 Kommunikationsmanager usessensennsensennnnnneennennnnnnnennnnen 173 7 1 2 4 Prozessspuren Server ccccececcceesseceeeceeseeeeeaeceeneeceeeeeaeceeeeeseneeesas 173 7 1 2 5 Prozessbeobachter Klienten cccceescceeseesseeeseeeseeeseeseenseceseenseenes 175 7 1 2 6 Administrations und Metamodellierungswerkzeuge 177 7 1 2 7 Prozess RePOSItOLY erneiere e a e E E AE a 181 7 2 Interaktionsprotokoll zwischen den Prozessdomanen sseeseeee 182 Inhaltsverzeichnis 7 2 1 Dynamische Sicht der Durchf hrungsdom ne eeen 183 7 22 Dynamische Sicht der Leitdom ne useneneeneenneennnennnnnnnnnnn 188 7 2 3 Rolle des Kommunikationsmanagers cuncneeneeneenseenseenneennnnnnnnnnnnnenn 190 PDAs Zusammenfassung kein Lak kasikkeiernkenkilemmanees 194 7 3 GARPIT ein Framework fiir prozessintegrierte Werkzeuge 195 7 3 1 Anforderungen an das GARPIT Framework ccccccscesseeeteeeteeeteeeseees 195 7 3 1 1 Funk
2. Die Nachrichtentypen die zwischen einem Werkzeug und dem Kommunikati onsmanager ausgetauscht werden sind im Teilsystem Message zusammengefasst Die Klasse CmsgMessageObject bildet die Basisklasse von der alle weiteren Nach richtentypen abgeleitet werden Die wichtigste Eigenschaft aller Nachrichtenob jekte besteht darin dass sie sich selbst in eine Zeichenkette serialisieren k nnen bzw aus einer Zeichenkette rekonstruieren k nnen Dazu definiert die Klasse CmsgMessageCbject die beiden Methoden asString und createByString die von jeder konkreten Nachrichtenklasse zu implementieren sind Mithilfe dieser Metho den ist der CommunicationChannel in der Lage Nachrichten als Zeichenkette zu verschicken bzw eine als Zeichenkette erhaltene Nachricht in ein Nachrichtenob jekt umzuwandeln ohne die Semantik und Struktur der ausgetauschten Nachrich ten kennen zu m ssen Die konkreten Nachrichtentypen gliedern sich in eine Gruppe administrativer Nachrichten CmsgConnect CmsgDisconnet CmsgPing CmsgStart und weitere und in solche Nachrichtentypen die im Rahmen des Interaktionsprotokolls aus Ab schnitt 7 2 ausgetauscht werden Wichtig sind hier insbesondere die CmsgCon textRequest und CmsgContextResponse Klassen die eine Kontextanforderung bzw das Resultat einer Kontextausf hrung verkapseln Diese Nachrichtentypen 7 3 GARPIT ein Framework f r prozessintegrierte Werkzeuge 207 sind generisch in dem Sinne dass sie dur
3. abort invalid Situation abort destroy gt Situation not valid a create start finished evaluating Situation valid Situation suspend resume Das Zustandsdiagramm in Abb 67 definiert das Ausf hrungsmodell der Klasse Process und otientiert sich an verbreiteten Zustandsmodellen f r Workflows wie z B JaBu96 BMCJ98 Die abgebildeten Zust nde werden von den spezialisierten Klassen EC Process CC Process und PC Process geteilt so dass hier eine ber greifendes Ausf hrungsverhalten dargestellt wird Um den unterschiedlichen Ausf hrungssemantiken der drei Kontextarten des Kontextmodells gerecht zu werden werden die einzelnen Zust nde je nach Kontextart in weitere Unterzu st nde verfeinert die Verfeinerung des Zustandes Running f r die Klassen PC Process und CC Process wird weiter unten dargelegt Im Folgenden wird zun chst die Bedeutung der bergeordneten Zust nde erl utert Q Ready Ein Prozess im Zustand ready ist instanziiert und kann ausgef hrt werden Zu diesem Zeitpunkt sind alle f r die Ausf hrung relevanten Da ten pr sent Im Falle von PC_Process ist das Fragment welches das Ver halten des Prozesses definiert bereits geladen und initialisiert Im Falle von EC Process und CC Process sind die auszuf hrende Werkzeugaktion bzw die Kontextalternativen des Entscheidungskontextes geladen und die ent sprechende Werkz
4. Anwendungs umgebung 2 IRD Definition Level Pair IRD Level Pair Application Level Pair Entwicklungs und An wendungs umgebungen im IRDS Rahmenwerk 66 3 Integrationsansatze von Applikationen Dazu werden die Daten die bei der Anwendungsbenutzung und entwicklung anfallen innerhalb von vier Instanziierungsebenen organisiert die wir im Folgenden von unten nach oben skizzieren Q Der IRD Application Level dokumentiert die Nutzung eines Anwen dungssystems d h er umfasst alle konkreten Produkt und Ausf h rungsdaten die bei der Verwendung eines Anwendungssystems entstehen Diese Ebene korrespondiert mit der Instanzenebenen Klassen basierter Programmier Sprachen Q Der IRD Level dokumentiert die Entwurfs und Entwicklungsergebnisse bei der Erstellung eines Anwendungssystems d h er beinhaltet Daten bank Schemata und Anwendungsprogramme sowie alle Zwischenprodukte Anforderungsspezifikationen Architekturdiagramme etc und Beschrei bung manueller Aktivit ten Workflow Beschreibungen Auf dem IRD Level sind auch Prozessspuren d h Daten die die bei der Anwendungser stellung ausgef hrten Entwicklungst tigkeiten dokumentieren angesiedelt Der IRD Level entspricht der Klassenebene Klassen basierter Sprachen Q Der IRD Definition Level spezifiziert die Sprachen in der Schemata An wendungsprogramme und intermedi re Spezifikationen definiert werden Auf dieser Ebene werden au erdem m gliche stat
5. atomareAktivit t zusammengesetzteAktivit t sprachneutrale Prozesssprachen j Darstellung Konzept 7 N i sprachneutrale Prozesssprachen Darstellung Konzept BehalterBindung Schnittstellenbindung Aktivitatsbindung besteht_aus_SB PSM2 Modell besteht_aus_BB V Bindung besteht_aus_AB BM2 Modell Datenbeh lterbindung F r den Anschluss einer Kontextkomponente an den Datenfluss in einer berge ordneten PK Komponente m ssen deren Schnittstellenparameter durch entspre chende Konzepte der spezifischen Prozesssprache dargestellt werden Dazu bindet die Instanz einer Beh lterbindung das Komponentenkonzept Situationsteil an ein Datenbeh lter Konzept einer spezifischen Prozesssprache Die Parameterbin dung assoziiert daher zwei Instanzen der M2 Klasse Datenbeh lter eine f r das Schnittstellenmetamodell und eine f r die jeweilige Prozesssprache Schnittstellenbindung Auf hnliche Weise bindet eine Schnittstellenbindung das Komponentenkonzept einer Schnittstelle an ein entsprechendes Schnittstellen Konzept der Prozess sprache Mit der Instanziierung einer Schnittstellenbindung k nnen Situations schnittstellen in der Verwendungssprache abgebildet werden F r die Abbildung m ssen nicht nur das Konzept der Schnittstelle selbst sondern auch die entspre chenden Datenbeh lter in den verschiedenen Rollen der Schnittstelle abgebildet we
6. A ObjectTable IntentionTable ctionTable Generic Model T_DB Interface a Q I O gt l v S 2 Generic DB x kit l c l Interface assoc l 2 contract garp vl E I I N I i 9 gt 6 N l x l D N 2 l l Fa l I l N N I fe IPC DB Container GUI 8 Mechanism Lib Toolkit ei Be BSD Sockets Sybase LEDA ILOG Views ig Winsock MS SQL Server Microsoft Foundation ToolTalk MS Access Classes ODBC Das Paket T Actions implementiert die im Werkzeugmodell definierten Aktionen eines Werkzeugs Aktionen werden als eigenst ndige Klassen mit einer execute Methode realisiert die Erzeugungs Anderungs und L schoperationen auf dem internen Produktmodell und der Benutzeroberfl che ausf hren und somit die Pr sentationsebene T_GUI T Model verkn pfen Die mit der internen logischen Produktmodellebene Aktionen verf gen ber kein eigenes Ged chtnis und fungieren lediglich als so genannte Kontrollobjekte JCJO92 oder funktionale Module T_Actions Realisierung der Werkzeugaktionen 200 Anbindung an das Framework Uber abstrakte Oberklassen ContextManager Interpretation des Umgebungsmodells Map Verkntipfung zwischen Laufzeitobjekten und Repository Identifikato re
7. O WfRequester WfRequester sind Entit ten die die Ausf hrung eines Pro zesses anfordern Dazu geh ren sowohl Prozessmaschinen als auch exter ne Applikationen Die Zustands nderungen der Prozessausf hrung wie z B die Termination eines Prozesses k nnen an den Requester weiter geleitet werden OQ WfProcess Prozesstypen werden durch die Entitat WfProcess repr sentiert die eine Schnittstelle f r die Prozesssteuerung anbietet wie z B das Star ten Beenden oder Suspendieren Ein WfProcess setzt sich aus mehreren WfActivities zusammen die die Subschritte des Gesch ftsprozesses dar stellen Instanzen eines Gesch ftsprozesstyps werden durch Objekte mit der Schnittstelle WfProcess repr sentiert 6 2 Interoperabilitat in prozessbasierten Systemen 137 DO WfProcessManager Ein WfProcessManager ist eine Fabrik f r die Erzeu gung einer Instanz eines Prozesstyps und h lt Metainformationen ber die verschiedenen Gesch ftsprozesstypen O WfActivity Eine WfActivity ist ein atomarer Geschaftsprozess der von ei nem Agenten ausgef hrt wird Die Aktivit t kann Teil eines bergeordne ten Gesch ftsprozesses sein der einen weiteren Gesch ftsprozess ausf hrt In diesem Fall ist die Aktivit t ein WfRequester eines weiteren Gesch fts prozesses die die Ausf hrung eines Prozesses anfordett O WfExecutionObject Ein W ExecutionOlject vereinigt die Konzepte WfProcess und WfActivity O WfResource W Resourcen stellen die f
8. schen Entwicklungspro berhaupt erst Vorgehensweisen die ohne sie gar nicht denkbar oder viel zu zessen und Werkzeugen arbeitsintensiv und daher zu kostspielig w ren z B die durchg ngige Dokumenta tion von Entwicklungst tigkeiten ber den gesamten Projektlebenszyklus Pohl99 Umgekehrt gilt dass der von einer Organisation verfolgte Entwicklungsprozess ob er nun explizit spezifiziert ist oder nur implizit in den K pfen der Mitarbeiter vorliegt die Funktionalit t der ben tigten Werkzeuge determiniert Jacobson et al sprechen in diesem Zusammenhang von Prozessen als den use cases of the tools JaBR99 Werkzeugunterst tzung in einer Entwurfsumgebung muss also flexibel an sich weiter entwickelnde und ge nderte Prozesse anpassbar sein So fordern Jacobson et al At every release of process there must also be a release of tools Um Prozessaspekte in einer Entwurfsumgebung sichtbar und anpassbar zu ma 3 chen m ssen die zu unterst tzenden Prozesse zun chst geeignet konzeptualisiert Prozesszentrierte Entwicklungs werden In diesem Zusammenhang hat sich in den letzten etwa 15 Jahren mit der umgebungen Software Prozessmodellierung DeKW99 FiKN94 FuWo96 AmCF97 eines der aktivsten Teilgebiete innerhalb der Softwaretechnik etabliert In so genannten prozesszentrierten Entwicklungsumgebungen bilden formale Prozessmodelle die Grund lage f r die Steuerung des Entwicklungsprozesses Der wesentliche Vorteil pro
9. Hilfesysteme Individuelle Hilfesysteme an Benutzerbed rfnisse angepa te Information Passive Hilfesysteme wird ausgel st durch explizite Benutzeranfrage Aktive Hilfesysteme wird gegeben wenn Hilfesystem Bedarf feststellt Hilfesysteme variieren in ihrer Unterst tzungsleistung sehr stark Im einfachsten Fall wird nach dem Bet tigen einer Hilfetaste in einem Werkzeug nur das entspre chende Kapitel aus dem Benutzerhandbuch des Werkzeugs angezeigt Weiterge hende Hilfesysteme ber cksichtigen den aktuellen Arbeitskontext unterst tzen jeden Benutzer individuell und initiieren Hilfeleistungen zum Teil selbstst ndig ohne Zutun des Benutzers Abb 3 zeigt eine Klassifikation von Hilfesystemen vgl BaSc88 Balz96 Zum einen wird sich zwischen statischen und dynamischen Hilfesystemen unter schieden Ein statisches Hilfesystem zeigt unabh ngig vom aktuellen Arbeitssitua tion und der tats chlichen Dialogsituation immer die gleiche Hilfeinformation an Auf dieselbe Frage des Benutzers gibt es stets die gleiche Antwort unabh ngig vom Kontext Im Gegensatz dazu ber cksichtigt ein dynamisches Hilfesystem bei seinen Erkl rungen die spezifische Situation dahingehend dass aktuell irrelevante Teile der Antwort herausgefiltert werden bzw eine allgemeine Antwort konkreti siert wird Als weiteres Unterscheidungsmerkmal von Hilfesystemen wird manchmal ihre F higkeit herangezogen die Hilfeleistung auf den jeweiligen Ben
10. Dagegen setzt der ContextExecutor die Darstellungsart von Attribu ten und Beziehungstypen auf nicht selektierbar hier grau da diese aufgrund der Prozessdefinition nicht zu g ltigen Situationen der aktuell m glichen Alternativ kontexte beitragen k nnen ContextMatcher Die Aufgabe des ContextMatchers besteht im Abgleich der Benutzerinteraktionen Kommando und Produktauswahlen mit den Definitionen der zum aktuellen Entscheidungskontext geh renden Alternativen Sobald die aktuelle Kommando und Produktauswahl einem im aktuellen Entscheidungskontext erlaubten Alterna tivkontext entspricht wird ein ContextMatched Ereignis an den StateManager geschickt Entsprechend der Unterteilung einer Kontextdefinition in einen Intentions und Situationsteil muss der ContextMatcher die Aktivierung von Intentionen einerseits und Situationen andererseits erkennen Wie beim ContextExecutor werden durch Benutzerinteraktionen ausgel ste Zustands nderungen von Kom mandoelementen und Produktinstanzen ber die IntentionTable und die Object Table zwischen den Teilsystemen ContextManager und T GUI kommuniziert Die Intentionserkennung ist trivial da es zwischen einem aktivierten Kom mandoelement und der entsprechenden Intention eine direkte Zuordnung gibt Etwas schwieriger ist die Situationserkennung da sich eine Situation in der Regel aus mehreren Produktinstanzen bestimmter Produkttypen zusammensetzt Situationssprache Au
11. InitValue ReadData ReadValue Creating Start Situation valid Situation not valid Starting ValidSituation InvalidSituation Aborting Suspending AfterRead handleAbort Resuming Prepare Write Write Destroy Finished WriteValue Destroy Destroy Destroy Ready EvaluatingSituation MakeStep commitStep handleError Running Done Suspended Aborted InvalidSituation InvalidSituation 7 5 4 Verwandte Ansatze In der Literatur finden sich nur wenige Ans tze die allgemeine objektorientierte Frameworks f r die Entwicklung von Interpretern bereitstellen Nach HaHK97 ist dies darauf zur ckzuf hren dass Architekturen f r die Sprachimplementierung d h bersetzer sich eher an den einzelnen bersetzungsphasen orientieren als an den Sprachelementen selbst Ausnahmen bilden das TaLE Framework HaHK97 das Etyma Framework BaLi96 und ein in KoM695 beschriebenes Framework f r Interpreter von numerischen Ausdr cken Diese Interpreterrahmenwerke bilden die Sprachstruktur d h die Syntax voll st ndig oder teilweise auf Klassen ab Diese Vorgehensweise ist naheliegend da Syntax und Klassenstruktur auf gleiche Weise ein Sprach Schema vorgeben dessen Instanzen gerade die S tze einer Sprache sind d h aus einer Menge von assoziierten Objekten bestehen Die Semantik eines Spra
12. Insbesondere hat sich die Frage welche Schl sseleigenschaften eine integrierte Entwurfsumgebung kennzeichnen als erstaunlich schwierig herausgestellt Wass90 ThNe92 Sche93 Bro 94 Ganz generell verbindet man mit Integration in einer Entwurfsumgebung den Wunsch nach besserer Koordination und starke rer Vereinheitlichung von zun chst unabh ngigen Einzelkomponenten Insbeson dere steht hinter dem Integrationsbegriff die Erwartung dass eine integrierte Entwurfsumgebung ihren Verwendern d h den Entwicklern effizientere Arbeits abl ufe erm glicht und somit einen h heren Nutzwert bietet als die Summe ihrer Einzelkomponenten ThNe92 Wass90 Sche93 Kelt93 Was bedeutet Integration Um die Integriertheit und Integrierbarkeit in Entwurfsumgebung besser unter suchen zu k nnen sind in der Literatur eine Reihe von Klassifikationsmodellen vorgeschlagen worden Diese liefern einen konzeptuellen Rahmen in dem ver schiedene Aspekte des Integrationsproblems einer getrennten Betrachtung unter zogen werden k nnen aber auch Querbez ge zwischen einzelnen Integrationsas pekten untersucht werden k nnen Im Folgenden diskutieren wir kurz die wich tigsten dieser zum Teil aufeinander aufbauenden Klassifikationsmodelle 3 1 1 Integration als Informationsmanagement Eine Sichtweise die die Architektur vieler Entwurfsumgebungen insbesondere aus dem akademischen Bereich gepr gt hat betrachtet das Integrationsproblem in erster Linie als ei
13. Schach S R Classical and Object Oriented Software Engineering IRWIN 1996 Schefstr m D System Development Environments Contemporary Concepts In Schefstr m D und Broek G van den Htsg Tool Integration Environments and Frameworks John Wiley amp Sons 1993 S 1 95 Scheer A W ARIS Modellierungsmethoden Metamodelle Anwendungen Springer Berlin 1998 Schill A Remote Procedure Call Fortgeschrittene Konzepte und Systeme ein berblick Teil 1 Grundlagen Informatik Spektrum 15 2 S 79 87 1992 Schill A Remote Procedure Call Fortgeschrittene Konzepte und Systeme ein berblick Teil 2 Erweiterte RPC Ans tze Informatik Spektrum 15 3 S 145 155 1992 Schill A DCE Das OSF Distributed Computing Environment Springer Verlag Berlin Heidelberg 1993 Schmidt H Ein Application Framework f r proze orientierte Anwendungssysteme Software technik Trends 16 4 S 44 49 Dez 1996 Schmidt D C Komponentenbasierte Interoperabilitat auf Basis des PRIME ProzefSmetamo dells Diplomarbeit RWTH Aachen 1999 Schreyjak St Coupling of Workflow and Component Oriented Systems In Weck W Bosch J und Szyperski C Hrsg Proceedings of the 2nd International Workshop on Component Oriented Programming WCOP 97 1997 S 364 368 Schulze W Workflow Management f r CORBA basierte Anwendungen Springer Verlag 1999 Schlenoff C Knutilla A und Ray S Unified Process Specifi
14. Clear Insert Product Show dependent objects Start Go To Tool Display Media Object Load trace session with this product Quit Realization of Separation by Destillation Verfeinerung durch Destillationskollone 4 gt Dependent objects shown Der bislang beschriebene Ablauf spielte sich automatisch im Hintergrund ab ohne dass der Verfahrensingenieur die entsprechenden Aktionen selbstst ndig ausf h ren musste Nun wird im Abh ngigkeitseditor der Entscheidungskontext CC DEP SelectDepObjects aktiviert In diesem Entscheidungskontext kann der Verfahrensingenieur entsprechend der Modellierung im M Prozessmodell unter verschiedenen Optionen w hlen Beispielsweise kann der Verfahrenstechniker zu einem ausgew hlten Objekt weiter entlang der Abh ngigkeitsstruktur navigieren Show Dependent Objects oder sich die komplette Entstehungsgeschichte des Objekts als Prozessspur ansehen Load Trace Session with this Product Der Verfahrensingenieur entscheidet sich daf r das Objekt Verfeinerung durch Destillationskolonne genauer zu studieren und w hlt dazu das Kommando Start Go to Tool Da es sich bei dem ausgew hlten Objekt um einen Entschei dungsobjekt handelt aktiviert er mit diesen Interaktionen den Entscheidungskon text CC_DEC InspectDecision Abb 80 zeigt den zu diesem Zeitpunkt erreichten Ausf hrungszustand im bergeordneten Plankontext PC_InspectRelatedObjects 8 A
15. Entit t werden zwei Alternativen definiert Plankontext ErzeugelsALink wird eine Entitat durch eine andere verfeinert indem eine Spezialisierungsbezie hung zwischen diesen beiden Entit ten erzeugt wird Folglich beschreibt die Situa tion des Kontexts ZweiEntities eine Konstellation von zwei vom Benutzer ausgew hlten Entitaten Die andere Alternative von EK Verfeinern Entit t beschreibt die Spezialisierung einer Entit t Plankontext PC_Subtypisierel Entit t der Pulldown Men bietet_Aktion_an bietet_KE_an bungsmodell Ausschnitt f hrt_AK_aus bietet_KE_an ER Editor Werkzeugkategorie 128 5 Integrierte Prozess und Werkzeugmodelle durch die Einf hrung einer neuen Sub Entit t Dieser Kontext ist als Plankontext modelliert da er mehrere Schritte umfasst in der Abbildung nicht dargestellt Erzeugen der Sub Entit t Hinzuf gen von Attributen Einf gen einer Isa Bezie hung zur urspr nglichen Entit t etc Seine Ausgangssituation basiert somit ledig lich auf der zu spezialisierenden Entit t Situation EineEntit t Weiterhin sind im Prozessmodell die zu den Kontexten geh renden Intentionen sowie die Aktion ErzeugelsaLink mit den jeweiligen input und output Produkten dargestellt Der untere Teil von Abb 22 zeigt einen Ausschnitt aus dem Werkzeugmodell Hier ist die Werkzeugkategorie ER E ditor zusammen mit
16. 2 ae lt D amp N p 0 administrativ technisch rechnerbasiert se rechnerbasiert in tegriert statisch dynamisch konfigurierbar nderbar passive Beratung aktive Anleitung automatisierend Methoden und Projekthandb cher Tab 3 zeigt die Einordnung der Prozessunterst tzung durch Projekt und Metho denhandb cher in den Klassifikationsrahmen 2 2 Bewertung existierender Ansatze 27 O Unterst tzte Projektebene Das in Projekt und Methodenhandb chern hinterlegte Prozesswissen kann sowohl die Projektmanagement als auch die Arbeitsplatzebene betreffen O Integrationstiefe Bei der Prozessunterst tzung durch Handb cher han delt es sich um eine Form der externen Prozessunterst tzung d h die in einem Handbuch definierte Prozessanleitung ist nicht direkt in der rechnerba sierten Arbeitsumgebung des Entwicklers zug nglich und sichtbar Bei der Bearbeitung einer Aufgabe kann die im Handbuch definierte Prozessan leitung nur dann wirksam werden wenn sich die Prozessausf hrenden an die Empfehlungen und Anweisungen erinnern und entsprechend handeln Andernfalls wird die im Handbuch definierte Prozessanleitung nicht ge nutzt In der Praxis bedeutet dies dass Projekt und Methodenhandb cher h ufig ignoriert werden und cher als b rokratischer Ballast denn als wirkli che Hilfe angesehen werden Bec 99 O Kontextbezogenheit Die durch Handb cher geleistete Prozessu
17. Als Beispiel f r einen Beratungsdienst betrachten wir die Verfeinerung eines Entit tstypen als Teil eines Prozessmodells f r die In formationssystem Modellierung mit Hilfe der Entity Relationship Me thode ER Als im aktuellen Kontext erlaubte Alternativen seien zwei al ternative Vorgehensweisen im Prozessmodell vorgesehen das Hinzuf gen eines Diskriminatorattributes oder die Spezialisierung des Entit tstypen Sobald dieser Beratungsdienst von der Prozessmaschine aktiviert wird muss das entsprechende ER Modellierungswerkzeug die definierten Alter nativen dem Benutzer anbieten z B als Men kommandos und alle andere Optionen etwa die Partitionierung des Entit tstypen in zwei unabh ngige Entit tstypen ausblenden O Anleitungsdienste Darunter verstehen wir die Ausf hrung von Prozess fragmenten die innerhalb des Prozessmodells definiert werden Anlei tungsdienste definieren Strategien die in der Regel mehrere Werkzeuge in volvieren in denen bestimmte Schritte durch Ausf hrungsdienste automa tisiert werden oder der Benutzer durch Beratungsdienste in der Auswahl des n chsten Schritts unterst tzt wird Daher ist es nicht sinnvoll die Aus f hrung von Anleitungsdiensten einem bestimmten Werkzeug zuzuordnen Vielmehr hat die Ausf hrung von Anleitungsdiensten als Abfolge von Teilschritten die wiederum durch bestimmte Dienste umgesetzt werden koordinierenden Charakter und liegt in der Zust ndigkeit der Leitdom ne d h der
18. Die Realisierung von insgesamt 17 Werkzeugen mit einem Wiederverwendungs grad von durchschnittlich ber 85 und die Einbettung zweier Prozesssprachen interpreter belegen dass sich die zus tzliche Investition in die Entwicklung der Implementierungs Frameworks gelohnt hat Die Werkzeugimplementierung wurde durch das GARPIT Framework signifikant erleichtert da wesentliche Teile der Architektur bereits als wiederverwendbare Komponenten vorlagen Die klare Definition der Variationspunkte und die vollst ndige Kapselung des Kontrollflus ses erlaubte ein einfaches Einklinken werkzeugspezifischer Funktionalit t Insbe sondere brauchten sich die Entwickler nicht mehr um die schwierige architektur elle und technische Integration zwischen Modellierungs Leit und Durchf h rungsdom ne zu k mmern da diese bereits vollst ndig auf Framework Ebene vorweggenommen ist Es zeigte sich dass die Entwickler die Funktionalit t eines Werkzeuges prob lemlos erweitern konnten ohne sich in die Struktur dieses Werkzeuges intensiv einarbeiten zu m ssen bzw es selbst implementiert zu haben Nat rlich erfordert ein Framework einen zus tzlichen Lernaufwand bevor es sinnvoll f r die Ent 9 3 Ausblick wicklung eines konkreten Werkzeugs eingesetzt werden kann Es stellte sich je doch heraus dass dieser Zusatzaufwand relativ moderat ausf llt Studentische Hilfskr fte und Diplomanden die zum ersten Mal mit dem PRIME Framework konfrontiert wurden ware
19. O cistein werkzeugexzerner Ausf hrungs oder Entscheidungskontext d h c ist im Umgebungsmodell einer anderen Werkzeugkategorie zugeord net als der des Werkzeugs in dem c aktiviert wurde Dann geht das Werk zeug in den Zustand External Context Requested ber und setzt dabei eine ExternalECCCRequest Nachricht ab Transition 6 In diesem Zu stand verbleibt das Werkzeug solange bis es eine ExternalECCC Response Nachricht erh lt Diese Nachricht f hrt zu einem Zustands bergang Transition 7 zur ck in den Sub Zustand von User Choice den das Werkzeug zuvor verlassen hatte formal durch einen History Pseu dozustand repr sentiert Dabei werden die Interaktionsm glichkeiten wie der auf die f r den zuvor aktiven Entscheidungs oder Standardkontext de finierten Alternativen angepasst Q cist ein Plankontext In diesem Fall setzt das Werkzeug eine GuidanceRequest c Nachricht an die Leitdom ne ab und geht in Erwartung der LockRequest Nachricht die die Prozessmaschine an alle ben tigten Werkzeuge aussenden wird in den Waiting for Lock Request Zustand ber Transition 8 Dieser Zu stands bergang markiert den Wechsel von der freien in die angeleitete Prozessdurchf hrung Die bislang hier beschriebenen Zustands berg nge aus dem Zustand User Choice werden dutch das endogene Ereignis ContextMatched ausgel st Daneben definiert das Zustandsdiagramm auch die Reaktion eines Werkzeugs auf
20. PED_DBinterface PED_GUI PED_Messagelnterface g Schnittstellen Durchf hrungs u Prozess dom ne Repository Die Pakete PED StateManager und PED MessageInterface realisieren die globale Zustandsverwaltung der Prozessmaschine und die Nachrichtenschnittstelle zur Durchf hrungsdom ne gem dem in Abschnitt 7 2 vorgestellten Interaktionspro tokoll Das Paket PED DBInterface realisiert den Zugriff auf die im Prozess Repository abgelegten Prozessdefinitionen Au erdem ist in der Schnitt stellenschicht das Paket PED GUI angesiedelt das einige rudimentare Benutzerober fl chenfunktionen f r den Start und die Benutzerkontrolle der Prozessmaschine bereitstellt Die Pakete der Schnittstellenschicht basieren auf den gleichen Basis klassen wie ihre Pendants im generischen Werkzeugframework GARPIT vgl 39 Das Pr fix PED steht f r Process Enactment Domain Leitdom ne 236 Abbildung der PSM2 Konzepte aus Abschnitt 6 4 auf Klassenstruktur der Sprachelemente Schicht 7 Das PRIME Rahmenwerk Abschnitt 7 3 2 wir verzichten daher auf eine genauere Beschreibung dieser Teilsysteme Die eigentliche Prozessfragmentinterpretation findet der administrativen Interpreter Schicht und in der Sprachelemente Schicht statt Die Sprachelemente Schicht stellt eine Laufzeitdarstellung der aktuell ausgef hrten Prozessfragmente bereit indem jedes in einem Prozessfragment auftauchende Sprachel
21. Wie bereits in Kapitel 1 motiviert wurde konzentrieren wir uns im Kontext dieser Arbeit auf Prozessunterst tzung f r die fr hen Phasen der Systementwicklung d h f r die Anforderungsanalyse und den Entwurf In diesen Phasen entf llt ein wesentlicher Teil der Entwick lungsaktivit ten auf Modellierungsaufgaben in denen das neu zu entwickelnde oder auch schon bestehende System auf unterschiedlichen Abstraktionsebenen und aus unterschiedlichen Perspektiven analysiert und mit Hilfe geeigneter Model lierungstechniken beschrieben wird 5 F ae Tab 1 Methode Modellierungstechniken een berblick ber die g ngigsten Methoden Gesch ftsprozess Erweitertes Entity Relationship Mo Sche98 modellierung dell Funktionsbaum Organigramm Erweiterte ereignisgesteuerte Prozessketten Wert sch pfungskettendiagramm BSP Gesch ftsprozess Problem Table Process Entity Matrix IBM 84 Business Systems modellierung Process Organization Matrix Process System Planning Matrix System Entity Matrix Sys tem Organization Matrix IDEF strukturiert IDEFO IDEF1 IDEF3 RoSc77 Integration Definition FIPS93a FIPS93b SA SD strukturiert Data Flow Diagram RT Data Flow Diagram YoCo79 Structured Analysis Entity Relationship Diagram Structure Chart GaSa79 and Design State Transition Diagram Your89 McPa84 OOA OOD objektorientiert Object Diagram State Transition Diagram CoYo91a Object Oriented Service Chart CoYo9
22. berpr fung von Konsistenzbedingungen 7 1 Die PRIME Gesamtarchitektur Abb 42 illustriert beispielhaft wie mithilfe des Umgebungsmodell Editors der Entscheidungskontext CC_ER Standard der Werkzeugkategorie ER Editor zuge ordnet wird und dabei die einzelnen Alternativen des Entscheidungskontexts an Kommandoelemente des ER Editors gebunden werden T PRIME Environment Modeler lt ER_Editor CC_ER_Standard gt Document Edit Create Tools Preferences Help Den Alternativen des Entscheidungskontexts CC_ER_Standard lt werden Kommandoelemente des ER Editgrs zugeordnet CC_ER_Standard A EEE EEE EEE ERE ecean CT mm PC_ER_OpenERD amp document Priority Rrlar ment Fr FR Arit Context in menue of tool Menue amp document v Priority Icon name oasen pe Accelerator A Alternatives of a choice context modelled in a tool Choice Context Executable Context 7 1 2 7 Prozess Repository In der Modellierungsdom ne dient das Prozess Repository der persistenten Spei cherung aller Prozess Werkzeug und Produktdaten In der schematischen Dar stellung des Prozess Repositories in Abb 34 auf Seite 170 unterscheiden wir die Teilbereiche des Repositories die Informationen f r die generischen Framework komponenten vorhalten dunkelgrau dargestellt von solchen die erst im Kontext spezifischer Erweiterunge
23. kn pfung zwischen einem Stream und einem VT ProcessDevice erfolgt indem der Connector eines Streams an den Port eines VI ProcessDevice gebunden wird Hierbei ist darauf zu achten dass ein Source Connector nur mit einem Aus gangsport und ein Sink Connector nur mit einem Eingangsport verbunden wird Jeder Connector kann an mehrere Ports gekn pft werden und umgekehrt Das h ngt mit der nachfolgend beschriebenen Verfeinerung von VI ProcessDevices und Streams zusammen Verfeinerungsstruktur Die Verfeinerungsstruktur beschreibt die Detaillierung von VT ProcessDevi ces und Streams Drei wesentliche Arten von Detaillierungsbeziehungen sind zu unterscheiden Dekomposion Anreicherung Konkretisierung und Realisierung Q Dekomposition Dekomposition tritt bei der Verfeinerung eines Verfah renskonzepts auf der Ebene des Grundflie bilds auf Ein VI Process wird dekomponiert in eine Menge von VT ProcessSteps und oder UnitOpera tions sowie Streams Ebenso k nnen VT ProcessSteps und Streams de komponiert werden UnitOperations sind atomare funktionale Einheiten die nicht weiter dekomponiert werden k nnen Der Gesamtprozess In stanz der Klasse VI Process ist stets die Wurzel einer Dekompositions hierarchie kann also selbst nicht als Teil einer Dekomposition auftauchen Q Anreicherung Bei der Anreicherung bleibt eine Gruppe von VT Prozess elementen auch auf der n chsten Verfeinerungsstufe vollst ndig erhalten wird jedoch um zus
24. liert werden Zum anderen muss der Wrapper den Zustand der Benutzeroberfl che manipulieren k nnen und ber relevante Benutzerereignisse informiert wer den Im Einzelnen l sst sich die Funktionalit t der ben tigten APIs unmittelbar aus dem Umgebungsmodell ableiten Insgesamt haben wir sechs Kategorien von erforderlichen Laufzeit APls identifiziert Poh 99 Q A1 Dienstaufruf Bei der Aktivierung eines Ausf hrungskontexts muss der Prozessintegrati ons Wrapper die im Umgebungsmodell zugeordnete feingranulare Aktion aktivieren k nnen Ein Werkzeug sollte daher im Idealfall ber seine 228 7 Das PRIME Rahmenwerk Dienstaufruf API alle Aktionen anbieten die auch ber die interaktive Be nutzerschnittstelle genutzt werden k nnen Q A2 Ergebnis R ckmeldung ber diese Schnittstelle k nnen die Resultate einer Aktionsausf hrung vom Prozessintegrations Wrapper erfragt werden Dies ist erforderlich da nach der Aktivierung eines Ausf hrungskontexts die weitere Prozessmo dellinterpretation im Allgemeinen von den Ergebnissen der aktivierten Werkzeugaktion abh ngt Wenn die Dienstaufruf API in der Form synchro ner entfernter Prozedur oder Methodenaufrufe realisiert ist f llt diese meist mit der R ckmeldungs API zusammen Die Unterscheidung zwi schen den beiden APIs macht aber dennoch Sinn da manche Werkzeuge nur den asynchronen Aufruf von Diensten erlauben oder bis auf einen Fehlercode keine R ckgabewerte liefern
25. rierten Umgebungen 3 3 1 berblick F r die Integration zwischen den Prozessdom nen haben wir insgesamt sechs Anforderungen identifiziert PoWe97 Poh 99 welche die teilweise schon in Wass90 ThNe92 FeOh91 Bro 94 ChNo92 DoFe94 B hm98 BeM 99 ge nannten Integrationsfragestellungen in wesentlichen Punkten pr zisieren und erweitern Im Folgenden geben wir zun chst einen kurzen berblick ehe wir die einzelnen Anforderungen in den Abschnitten 3 3 2 bis 3 3 7 detailliert beleuchten und m gliche L sungsans tze bewerten Bei der Darstellung der Anforderungen orientieren wir uns an der bew hrten Strukturierung in Daten Kontroll und Pr sentationsaspekte 56 3 Integrationsansatze 3 3 1 1 Datenintegration Anforderung 1 Datenintegration zwischen den Prozessdom nen Die Notwendigkeit zur Datenintegration zwischen den Prozessdom nen resultiert aus der Tatsache dass Werkzeuge nicht auf isolierten disjunkten Datenbest nden arbeiten Vielmehr legt das Prozessmodell eine Abfolge von Bearbeitungsschritten fest die im Allgemeinen durch unterschiedliche Werkzeuge abgedeckt werden Da normalerweise Daten von einem Bearbeitungsschritt zum n chsten weitergereicht werden entstehen logische und physische Abh ngigkeiten zwischen Werkzeugda ten Dazu m ssen Werkzeuge zun chst einmal prinzipiell in die Lage versetzt werden untereinander d h innerhalb der Durchf hrungsdom ne und mit der Prozessmaschine d h mit der Leitdom
26. A3 Kommandoerweiterung ber diese Schnittstelle k nnen zus tzliche Kommandos in die Benutzer schnittstelle eines externen Werkzeugs eingef gt werden und an R ckruf Funktionen gebunden werden die im Prozessintegrations Wrapper die Ak tivierung der korrespondierenden Intentionen signalisieren Die Not wendigkeit dieser Schnittstelle resultiert aus der Eigenschaft des Kontext modells dass Entscheidungskontexte extern realisierte Plankontexte und die Kontexte anderer Werkzeuge umfassen k nnen die somit als Kom mandoelemente in der Benutzeroberfl che eines zu integrierenden Werk zeug ad quat abgebildet werden m ssen Q A4 Produktdarstellung ber diese Schnittstelle k nnen Produktinstanzen bei der Durchf hrung von Entscheidungskontexten gem der Modellierung im Werkzeugmodell in der Benutzerschnittstelle als hervorgehoben selektierbar oder deaktiviert dargestellt werden siehe auch Abschnitt 7 3 2 5 QO A5 Selektierbarkeit ber diese Schnittstelle kann bei der Ausf hrung eines Entscheidungs kontexts die Aktivierbarkeit von Produktinstanzen und Kommandos dy namisch eingeschr nkt werden um die Auswahl aktuell nicht erlaubter oder irrelevanter Alternativen durch den Benutzer zu verhindern O A6 Selektionsnotifikation ber diese Schnittstelle k nnen vom Benutzer ausgel ste Selektionsereig nisse Produktinstanzen oder Kommandos an den Prozessintegrations Wrapper gemeldet werden um im Wrapper den Abgle
27. Datenbanktechnologie sowie das nderungsmanagement in Reposito ries haben die Forschung in diesem Bereich dominiert Bro 94 BeDa94 Ber 99 Ortn99 NiJa99 WaJo93 3 1 Perspektiven der Werkzeugintegration 49 3 1 2 Integration als eine Menge von orthogonalen Di mensionen Wasserman s Von Wasserman stammt die wohl einflussreichste Publikation zur Klassifikation Intearstionsaimensi neh des Integrationsproblems Wass90 Die zentrale Idee in Wasserman s Vorschlag Wass90 besteht darin Entwurfsumgebungen bez glich ihrer Integrationsmechanismen entlang mehrerer zueinander orthogonaler Dimensionen zu bewerten Er erwei tert die rein Repository zentrierte Perspektive indem er neben datenbezogenen Aspekten Datenintegration auch die berbr ckung von Hardware Betriebssys tem und Netzwerkheterogenit t P attformintegration die Vereinheitlichung der Benutzeroberfl che Pr sentationsintegration die Steuerbarkeit von Werkzeugen Kontrollintegration und die Einbettung von Werkzeugen in einen definierten Ar beitsprozess Prozessintegration in seine Analyse des Integrationsproblems einbe zieht Ein wichtiges Merkmal in Wasserman s Klassifikationsmodell ist die Fokussie rung auf Integrationsmechanismen d h die Qualit t und Tiefe der Integration wird am Vorhandensein bestimmter Integrationsdienste festgemacht Hierbei konzentriert er sich insbesondere auf die Aspekte Daten Kontroll und Pr sentationsint
28. Herc94 HiKa99 HJKW96 Hoar85 Holl95 Hor 98 HoVe97 Huff96 Hump89 IBM 84 Harsu M Hautamaki J und Koskimies K A Language Implementation Framework in Java In Proc of the European Conference on Object Oriented Technology ECOOP 97 Springer Verlag LNCS 1357 1997 Habermann H J und Leymann F Hrsg Repository Eine Einf hrung Oldenbourg Munchen 1993 Habermann N und Notkin D Gandalf Software Development Environments IEEE Transactions on Software Engineering 12 12 S 1117 1127 1986 Haumer P Pohl K und Weidenhaupt K Requirements Elicitation and Validation with Real World Scenes IEEE Transactions on Software Engineering 24 12 S 1036 1054 12 1998 Harel D Statecharts a visual formalism for complex systems Science of Computer Pro gramming 8 S 231 274 1987 Harmsen F Situational Method Engineering Dissertation Moret Ernst amp Young Utrecht NL 1997 Harmsen F und Saeki M Comparison of four Method Engineering Languages In Brink kemper S Lyytinen K und Welke R Hrsg Method Engineering Principles of Method Construction IFIP Chapman amp Hall 1996 S 209 231 Haumer P Requirements Engineering with Interrelated Conceptual Models and Real World Scenes Dissertation RWTH Aachen 2000 Hayes J G Peyrovian E Sarin S Schmidt M T Swenson K D und Weber R Workflow Interoperability Standards for the Internet IEEE
29. Kontextkomponente setzt sich den drei Teilkomponenten Verhalten Situation 6 3 Komponentenorientierte Darstellung des NATURE Prozessmodells 145 und Intention zusammen Der Situationsteil und der Verhaltensteil stellen selbst wiederverwendbare Komponenten mit einer definierten Ein und Ausgangs schnittstelle dar Situationskomponente Die Eingangsschnittstelle einer Situationskomponente referenziert den Ausschnitt aus dem Produktmodell auf dem die Situation auszuwerten ist Dabei wird die Ein gangsschnittstelle aus einer Menge von getypten Produktteilen gebildet denen je weils spezifische Rolenbezeichner zugewiesen werden k nnen Die Auswertung der Situation erfolgt mithilfe eines S7 wationsausdruck der die Implementierung einer Situationsspezifikation darstellt Der Situationsausdruck formuliert in einer daf r geeigneten Sprache Bedingungen die erf llt sein m ssen damit die an der Ein gangsschnittstelle vorliegenden Produkte eine g ltige Situation bilden Die Aus gangsschnittstelle einer Situation besteht wiederum aus Produktteilen in spezifi schen Rollen Diese Produktteile bilden zusammen die Produktkonstellationen die den Situationsausdruck erf llen Produktteile der Eingangsschnittstelle nennen wir In Produtetteile w hrend wir Datenbehalter der Ausgangsschnittstelle als Our Pro duktteile bezeichnen Der Bezug zwischen den In und Out Produktteilen einer Situationskomponente h ngt von der Art des Situationsausdrucks an
30. R Developing Java Beans O Reilly 1997 Eriksson H E und Penker M UML Toolkit John Wiley amp Sons 1998 Estublier J und Barghouti N Interoperability and Distribution of Process Sensitive Systems In Proceedings of the Conference on Software Engineering for Parallel and Distrib uted Systems PDSE 98 Kyoto Japan 1998 S 103 115 Estublier J Cunin P und Belkhatir N Architectures for Process Support System Interop erability In Proceedings of the 5th International Conference on the Software Process ICSP 5 Chicago Illinois USA 1998 S 137 147 286 Literaturverzeichnis EsDa96 Estu99 Faga76 Faga86 FaSJ99 FeHu93 FeNO92 FeOh91 Fern 93 Fern 93a Fie 99 FIKN94 FIPS93a FIPS93b Flan00 FoKR94 FoN092 Fow186 FrAg96 Fran91 Fro193 FrWa93 FrWe82 Fugg93 Estublier J und Dami L Process Engine Interoperability An Experiment In Proceed ings of the 5th European Workshop on Software Process Technology EWSPT 5 Nancy France Springer Verlag 1996 S 43 60 Estublier J Is a Process Formalism an Architecture Description Language In Proceedings of the International Process Technology Workshop PTW Grenoble Switzerland 1999 S 17 22 Fagan M E Design and Code Inspection to Reduce Errors in Program Development TBM Systems Journal 15 3 S 182 211 1976 Fagan M E Advances in Software Inspections IEEE
31. Stuttgart 1996 Pohl K und Weidenhaupt K A Contextual Approach for Process Integrated Tools In Jazayeri M und Schauer H Hrsg Proceedings of the 6th European Software En gineering Conference ESEC FSE 97 Zurich Switzerland Springer Verlag LNCS 1301 1997 S 176 192 Pree W Essential Framework Design Patterns Object Magazine 7 1 March 1997 Pree W Komponentenbasierte Softwareentwicklung mit Frameworks dpunkt verlag 1997 Pressman R S Software Engineering In Thayer R H Hrsg Software Engineering Project Management IEEE Computer Society Press 1997 S 30 47 Purtilo J M The Polylith Software Bus ACM Transactions on Programming Lan guages and Systems 16 1 S 151 174 1994 Puustj rvi J Tirry H und Veijalainen J Reasability and Modularity in Transactional Workflows Information Systems 22 2 3 S 101 120 1997 Rammig F J und Steinm ller B Frameworks und Entwurfsumgebungen Informatik Spektrum 15 1 S 33 43 1992 Redwine S T Humans and Processes IWSP8 Session Summary In Proc of the 8th Intl Software Process Workshop Wadern Germany IEEE Computer Society Press 1993 S 12 14 Reifer D J Managing the Three P s The Key Success to Software Management In Reifer D J Hrsg Software Management IEEE Computer Society Press 1993 S 2 8 Reiss St Connecting Tools Unsing Message Passing in the Field Environment IEEE Soft ware 7 4 S 57
32. au en aufrufbaren Dienste dargestellt werden In existierenden Prozessmodellierungssprachen werden Werkzeuge meist als monolithische Operatoren betrachtet und nicht als Objekte erster Klasse repr sentiert Werkzeugen werden in Prozessmodellen ad hoc ber cksichtigt d h sie werden auf Prozessmodellierungsebene erst dann sichtbar sobald sie zum ersten Mal innerhalb des Prozessmodells zur Umsetzung einer Aktivit t referenziert werden Zudem werden die Werkzeuge h ufig innerhalb von Wrappern gekapselt In Ans tzen die Werkzeuge feingranular auf der Basis von Kontrollintegrations infrastrukturen wie Object Request Broker und Messsage Server einbinden koe xistieren Prozess und Werkzeugdienstbeschreibungen in voneinander unabh ngi gen Prozess bzw Schnittstellenrepositories ohne eine ausreichende Unterst tzung der Konsistenzsicherung beider Modelle Generative Ans tze zur Werkzeugerstellung gehen ber die reine Werkzeugbe schreibung hinaus und erfordern eine strikte Formalisierung der zugrunde liegen den Produktstrukturen Ihr Einsatzgebiet beschr nkt daher auf sehr gut verstan dene Modellierungstechniken mit einem gro en Automatisierungspotenzial in denen die in dieser Arbeit angestrebte Prozessadaptibilit t f r kreative Entwurfs prozesse ohnehin an Bedeutung verliert 3 3 5 Synchronisation zwischen den Prozessdom nen 3 3 5 1 Motivation Drei Prozesssichten Die Trennung zwischen Modellierungs Leit und Durchf hrungsdo
33. ber einen zentralen Message Server an die Au enwelt bekannt und l st damit implizit entsprechende Reaktionen bei den f r ihn anonymen Empf ngern aus Die Grundidee besteht also darin dass bei Werkzeuginteraktionen nicht der Produzent sondern der Empf nger einer Nachricht die Verantwortung f r den Aufruf der richtigen Dienste tr gt so dass der Kontrollfluss quasi umgedreht wird 0 Prozess Mediierter Aufruf Der Nachteil der bisher skizzierten Ans tze besteht darin dass prozessrelevantes Wissen ber die Reaktion auf be stimmte Ereignisse in den Werkzeugen selbst verankert ist im Sender beim expliziten Aufruf bzw im Empf nger beim impliziten Aufruf Medi atorbasierte Ans tze streben eine Trennung von Werkzeugen einerseits und Interaktionsbeziehungen zwischen Werkzeugen andererseits an Werk zeuge exportieren Notifikationen ber eigene Zustands nderungen und nehmen Kommandoaufrufe von au en entgegen reagieren aber nicht selbst auf Notifikationen und rufen keine Kommandos anderer Werkzeuge auf Die Umsetzung von Notifikationen auf Kommandoaufrufe ist in einer 3 3 Integrationsanforderungen in prozessintegrierten Umgebungen 71 eigenen Komponente dem Mediator gekapselt Der Mediatoransatz ist ein allgemeines Prinzip zur losen d h erweiterbaren und adaptablen Kopplung von Softwarekomponenten das in unterschiedlichsten Auspr gungen auf tritt In einer prozessintegrierten Umgebung bernimmt die Prozessma schine d
34. ckmel dungen ber eine spezifische Benutzerschnittstelle oder Abhorchen von Ereignis sen in der Durchf hrungsdom ne 98 3 Integrationsansatze In den meisten Umgebungen erfolgt die Interaktion mit der Leitdom ne ber spezifische Assistenzwerkzeuge wie Task Manager Agendawerkzeuge Arbeits kontexte etc siche auch Abschnitt 2 2 4 3 ber diese Werkzeuge nimmt der Benutzer Informationen ber anwendbare Schritte entgegen und liefert R ckmel dungen ber beendete Prozessschritte Problematisch ist hierbei zum einen dass der Benutzer neben seinen eigentlichen Werkzeugen mit einer zus tzlichen Benut zerschnittstelle konfrontiert wird Je feiner die Arbeitsschritte und Produkte sind auf die sich die Prozessunterst tzung bezieht desto h her wird der Aufwand f r den Benutzer f r die Interaktion mit den Assistenzwerkzeugen Insbesondere die Eingabe aussagekr ftiger Feedback Informationen erfordert eine Referenzierung von Produktteilen unterhalb der Dokumentebene und ist bei separaten Benutzer schnittstellen sehr schwierig und m hselig Da der Benutzer au erdem selbst f r die R ckmeldungen an die Leitdom ne zust ndig ist besteht die Gefahr der oben genannten Modellabweichungen aufgrund falscher idealisierter oder nicht zeitnah gelieferter Informationen durch den Benutzer Um den Benutzer von der Kommunikationen mit der Leitdom ne zu entlasten Automatische Verfol und au erdem objektivere R ckmeldungen zu entlasten verwend
35. daher nur unvollst ndig Koordinations Architekturbeschreibungs und Skriptsprachen Abschlie end betrachten wir noch einige Ans tze der Aomponentenorientierten Soft ware Enntwicklung Grif98 Szyp98 NiDa95 zu denen sich im Zusammenhang mit der Mediation von Werkzeugbeziehungen eine Reihe von offensichtlichen Quer bez gen ergeben da prozessorientierte Werkzeugintegration ja auch als Spezial fall des allgemeineren Problems der Softwarekomposition verstanden werden kann Estu99 Interessant sind hier vor allem Konfigurations und Kompositionstech niken die die anwendungsspezifische Anpassung und das Zusammenkleben glueing von Softwarekomponenten innerhalb eines gr eren Anwendungskon texts zum Ziel haben sowie die damit verwandten Architekturbeschreibungs und Skriptsprachen Abb 13 Kopplung von Message Broadcasting und Pro zessmaschinen am Beispiel von SPADE BFGL94 BaDF96 Konflikte zwischen Prozessmodellen und hartkodierten Werkzeug reaktionen Ans tze aus der kom ponentenorientierten Software Entwicklung 82 3 Integrationsansatze Der in PaSa96 PaSE97 Satt97 vorgestellte MediatorService ist ein speziell auf die Werkzeugintegration in ingenieurwissenschaftlichen Entwurfsumgebungen zugeschnittener Dienst zur Definition Verwaltung und Steuerung von Kompo nentenbeziehung in einem CORBA basierten Systemumfeld Die Komposition von Werkzeugdiensten wird mit Hilfe der Too Interconnection Languag
36. der Verbindungsschnittstellen der einzelnen Komponenten Die in einer Ausf h rungssicht enthaltenen Komponenten und deren Kopplung ber Verbindungs und Synchronisationskan le k nnen dynamisch durch Funktionen wie z B add Component oder modifyConnection zur Laufzeit modifiziert werden 6 2 3 3 Rollenkooperation In ShWa95 Warb90 wird ein Prozessmodell durch kooperierende Objekte und Rollen dargestellt Generell werden Entit ten der realen Welt durch Objekte repr sentiert die eine oder mehrere Rolle einnehmen oder von einer Rolle benutzt werden um das Rollenziel zu erreichen z B nimmt ein Objekt Person die Rolle Projektmanager ein die zum Erreichen des Rollenziels Projektplanung die Objekte Person Dokument und Werkzeug ben tigt Rollen und Objekte sind Objekte im objektorientiertem Sinn und werden f r jedes Prozessmodell durch Analysemethoden wie CRC Karten identifiziert die Methoden einer Rolle sind die Aktivit ten die in einer definierten Reihenfolge ausgef hrt werden m ssen damit das Rollenziel erreicht wird Die Ausf hrung der Aktivit ten einer Rolle f hrt zu Modifikationen der Objekte und erfordert in der Regel eine Kooperation und Interaktion mit weiteren Rollen Die Kooperation der einzelnen Rollen eines Prozessmodells wird durch ein bergreifendes Petrinetz modelliert deren Transitionen die Methoden einer spezi fischen Rolle repr sentieren Die Verbindung zweier Transitionen durch Stellen und Kanten modell
37. miert wird Ein Subprozess terminiert entweder fehlerfrei fehlerhaft oder wurde zeitweise unterbrochen was sich in den oben erl uterten Zust nde done aborted bzw suspended u ert Die Termination eines Subprozesses stellt ein Ereignis dar welches vom PK Prozess registriert wird und im Folgezustand vom Interpreter best tigt werden muss Der Zustand ExecutingActivities wird verlassen sobald alle abgespaltenen Subprozesse terminiert sind In der dritten Phase muss die Ausf hrung der abgespaltenen und terminierten Prozesse im Zustand CommittingStep best tigt werden Die Best tigung ist erfor derlich da die abgespaltenen Subprozesse nicht zwingend fehlerfrei terminieren Da die Ausnahmebehandlung je nach Prozesssprache unterschiedlich gehandhabt wird und zum Teil auch durch entsprechende Sprachkonzepte unterst tzt wird wird dem Prozesssprachen Interpreter in diesem Zustand die M glichkeit gege ben geeignet auf die Termination der Subprozesse zu reagieren Der Interpretati onsschritt wird entweder best tigt oder f hrt im Falle einer Ausnahme zu einem Abbruch der Interpretation Die drei Phasen werden solange wiederholt bis vom Prozesssprachen Inter preter signalisiert wird dass die Interpretation des Fragmentes beendet ist In diesem Falle verl sst der PK Prozess den Zustand running und geht in den Zu stand done ber der eine erfolgreiche Beendigung repr sentiert Im Gegensatz dazu kann die fehlerhafte Termination des P
38. ne auf der Basis eines unzutreffenden internen Abbilds des realen Pro zesszustands kaum sinnvolle Prozessunterst tzung und kontrolle erwartet werden kann DoFe94 Fern93a Mont94 CDFG96 Cugo98 BaKr95 Wir werden auf die daraus resultierenden Probleme in Abschnitt 3 3 5 noch im Detail eingehen und daraus Anforderungen an eine enge Integration zwischen den Dom nen ableiten 2 2 4 3 Schnittstellen einer PZEU Entsprechend den im vorangegangenen Abschnitt skizzierten Funktionsbereichen lassen sich drei wesentliche externe Schnittstellen einer PZEU identifizieren die sich an die unterschiedlichen Nutzergruppen einer PZEU richten siehe Abb 5 Q die Modellierungsumgebung f r den Prozessmodellierer oder Methodeninge nieuT Q die Administrationsumgebung f r den Projektmanager O das Entwicklerfrontend f r den technischen Entwickler auf der Arbeits platzebene 2 2 Bewertung existierender Ansatze W hrend der Prozessmodellierer nicht unmittelbar durch eine PZEU unterst tzt wird sondern vielmehr f r die Konfiguration einer PZEU durch Bereitstellung und Pflege von Prozessmodellen zust ndig ist profitieren Projektmanager und technische Entwickler bei den auf den jeweiligen Ebenen der Systementwicklung auftretenden Aktivit ten von der Assistenzfunktion einer PZEU Modellierungs dom ne Prozessmodell Definition 4 Modellierungs Umgebung Prozess modellierer Resourcen zuteilung N
39. ne defi nierten und in der Leitdom ne ausgef hrten Prozessmodellen unterordnen be zeichnen wit als prozessintegrierte Werkzenge Anhand unserer Klassifikationskriterien k nnen wir die wesentlichen Merk male einer Unterst tzung durch prozessintegrierte Werkzeuge charakterisieren O Fokussierung auf Arbeitsplatzebene Die in den Werkzeugen stattfin denden Abl ufe werden modellierungsm ig auf feingranularer Ebene be trachtet Dadurch ist es uns m glich anders als bei den meisten Ans tzen aus dem Bereich Prozesszentrierte Entwicklungsumgebungen oder Workflow Managementsysteme die Arbeitsplatzebene in das Zentrum der Unterst tzung zu stellen Prinzipiell lassen sich nat rlich auch Arbeitsab l ufe auf der Projektmanagementebene durch prozessintegrierte Werk zeuge unterst tzen dies ist jedoch nicht Gegenstand dieser Arbeit 2 3 Fazit O Rechnerbasierte integrierte Unterst tzung Die Prozessunterst tzung wie sie durch Prozessmodelle und Prozessmaschine verk rpert wird ist unmittelbar in der Werkzeugumgebung sichtbar und der Benutzer ben tigt keine zus tzlichen Benutzerschnittstellen um mit der Prozessmaschine zu interagieren nderbarkeit und Erweiterbarkeit Prozessintegrierte Werkzeuge ver k rpern kein eigenes hartkodiertes Prozesswissen dieses ist in der Mo dellierungsdom ne in Form explizit modellierter Prozessfragmente offen gelegt Daher k nnen die zu unterst tzenden Abl ufe mit vergleichsweise g
40. ngige Informationen ber die Anforderung und Ausf hrung von Kon texten entgegen bringt diese in einen zeitlichen und logischen Zusammenhang und persistiert die Ausf hrungsinformationen samt Schrittabh ngigkeiten im Prozess Repository Abb 36 illustriert die Arbeitsweise des Prozessspuren Serverts die der eines Transaktionsmonitors f r die B ndelung von Datenbankenanfragen hnelt Einzelheiten zur Realisierung des Prozessspuren Server und zum zugrunde liegenden Prozessspuren Datenmodell werden zur Zeit in einer Diplomarbeit umfassend aufgearbeitet BranO1 7 1 2 5 Prozessbeobachter Klienten Neben der reinen Protokollierung von Prozessspuren bietet der Prozessspuren Server auch einen Notifikationsdienst an ber den sich so genannte Prozessbeob achter Klienten ber das Auftreten aller oder auch nur bestimmter Prozessspur Ereignisse informieren lassen k nnen siehe auch Abb 34 Dieser Notifikations dienst ist gem dem Observer Muster GHJV95 realisiert nutzt CORBA als Kommunikationsplattform und erlaubt daher eine netzwerkweite Verteilung von Prozessspuren Server und Klienten Zurzeit wird der Notifikationsdienst von zwei generischen Werkzeugen des PRIME Frameworks verwendet dem Prozessspu ren Visnalisierer und dem generischen Anleitungswerkzeng Process Tracer Session Simulate CSTR FRE Document Edit Tools Display Preferences Help Ee C_ASP_SimulateGivenRefinement Ausf hrung eines Kontexts PC_FBW_Transf
41. r die Verfeinerung einer Entit t drei alternative Vorgehensweisen zur Auswahl O Hinzuf gen einer Spezialisierungsbeziehung zu einer existierenden Entit t EC_CreateIsALink Q Hinzuf gen eines Diskriminator Attributes EC_AddDiscriminator O Erzeugen neuer Entit tstypen als Subtypen von Publication PC_SubtypeEntity Hierbei entsprechen die ersten beiden Alternativen atomaren werkzeugeigenen Diensten Ausf hrungskontexte w hrend die dritte Alternative ein komplexes 7 3 GARPIT ein Framework f r prozessintegrierte Werkzeuge 211 Prozessfragment darstellt Plankontext Gem den Festlegungen im Umge bungsmodell werden vom ContextManager ber die IntentionTable diese Alter nativen aktiviert d h in das Edit Men eingetragen durch entsprechende Icons in der Toolbar dargestellt und an die definierten Shortkeys gebunden Alle anderen Kommandoelemente werden tempor r ausgeschaltet und sind nicht zugreifbar Aktivierbarkeitsstatus deaktiviert In der Produktregion wird als aktuelle Situa tionsinstanz die Entit t Publication in der Darstellungsart hervorgehoben hier rot dargestellt Die mit den Alternativen assoziierten Situationstypen definieren die Produkttypen deren Instanzen potenziell ausgew hlt werden k nnen In die sem Fall kommen nur noch Entit ten als Bestandteile der m glichen Situationen OneEntity und TwoEntities in Frage Diese werden als selektierbar dargestellt hier wei
42. r die Ausf hrung einer Aktivit t notwendigen Ressourcen wie z B Personen oder Rechnerkapazit ten dar Q WfAssignment Die Zuordnung von Ressourcen zu Aktivit ten wird durch WfAssignments repr sentiert O WfEventAudit Ein WfEventAudit repr sentiert die Ereignisse die w h rend der Ausf hrung eines Prozesses aufgetreten sind Durch die Schnitt stelle kann innerhalb der Historie der Prozessausf hrung navigiert werden so dass zeitliche Informationen wie z B die Termination eines Gesch fts prozesses auch nach der Ausf hrung weiterhin verf gbar sind Das jointFlow Rahmenwerk steht in engem Zusammenhang mit den Standardisie rungsbem hungen der WfMC Die von der WfMC identifizierte Schnittstellen funktionalit t f r die Interoperabilitat zweier Prozessmaschinen wird vom jointFlow Rahmenwerk in Form von Methoden die den einzelnen Klassen zuge ordnet sind und Aufrufprotokollen bernommen Im Gegensatz zur WfMC die sich eher an den Schnittstellen der Teilsysteme eines Workflowmanagement systems orientiert liegt der Schwerpunkt von jointFlow auf den Schnittstellen der Entit ten eines Prozessmodells Weitere Austauschformate Neben WPDL und jointFlow existieren noch weitere Austauschformate wie z B die aus der Fertigungsindustrie stammende Sprache PSL ScKR96 und die im akademischen Umfeld entstandene Sprache PIF LeYo94 Analog zur WPDL werden die Konzepte der Prozessmodellierung bei PIF in einem Metamodell vereinheitlic
43. r verfahrenstechnische M Prozesse im Folgenden genauer beschreiben 8 2 2 1 Stellung des Flie bilds im Gesamtprozess Im Zuge der Verfahrensentwicklung entsteht eine F lle von Informationseinhei ten die st ndig weiter gepflegt und zugriffsbereit gehalten werden m ssen Eine besondere Rolle spielen dabei grafische Darstellungen in Form von F e bildern die Aufbau und Funktion der verfahrenstechnischen Anlage auf unterschiedlichen Abstraktionsniveaus wiedergeben Doug88 Blas97 Um das Flie bild herum lassen sich in nat rlicher Weise andere wichtige Informationseinheiten gruppieren die w hrend des Entwurfsprozesses entstehen z B Simulationsergebnisse Kos tensch tzungen Entscheidungsdokumentationen und sicherheitstechnische Analy sen Abb 70 illustriert die vielf ltigen Querbez ge des Flie bilds zu anderen Infor mationseinheiten innerhalb des vom IMPROVE Projekt betrachteten Anwen dungsszenarios Aufgrund der zentralen Stellung des Flie bilds als Kristallisations punkt vielf ltiger Entwurfsaktivit ten die durch Praxisbeobachtungen Jar 98a untermauert wird kann ein Werkzeug zur Flie bilderstellung besonders von der Assistenzfunktion der M Prozessintegration profitieren 251 8 Anwendungen Abb 70 Stellung des Flie bilds im Entwurfsprozess Extruderauslegung Station re Simulation Aspen Plus Morex Verfahrens Simulations Extruderdaten blockschaltbild parameter Simulations spezifik
44. resultieren die im Pro zessmodell als Entscheidungskontext modellierten Beratungsdienste in ei ner Einschr nkung der Interaktionsm glichkeiten des Entwicklers in sei nen Werkzeugen Der Fokus des Entwicklers soll auf die aktuell relevanten Dienste und Produktteile gelenkt werden und der Zugriff auf nicht er laubte Dienste bzw Produkte soll verhindert werden Weiterhin sollen Prozessfragmente aus der Benutzerschnittstelle eines Werkzeugs aktiviert werden k nnen Die explizite Modellierung der Interaktionselemente eines Werkzeugs ist daher eine Grundvoraussetzung f r eine dynamische und anpassbare Zuordnung zu den im Prozessmodell definierten Alternativen eines Auswahldienstes 5 4 2 PRIME TM Das Werkzeugmetamodell Im Folgenden stellen wir ein Werkzeugmetamodell vor das die Modellierung der oben genannten Werkzeugaspekte erlaubt Es wurde insbesondere mit dem Ziel einer einfachen Integrierbarkeit mit dem in Abschnitt 5 3 vorgestellten Prozessme tamodell entworfen siehe auch Abschnitt 1 5 Im Zentrum des Werkzeugmetamodells steht das Konzept der Werkzeugkate gorie siehe Abb 20 Durch Instanziierung dieser Klasse k nnen die in einer Entwurfsumgebung zur Verf gung stehenden Werkzeuge modelliert werden Zum Modellierungszeitpunkt betrachten wir Werkzeugkategorien lediglich auf der Typebene w hrend zur Laufzeit durchaus mehrere konkrete Auspr gungen einer 5 4 Modellierung von Werkzeugen 119 bestimmten Werkzeugkategorie aktiv s
45. rfnisse sind dann nicht mehr oder nur in schr einge schr nktem Ma e m glich Diese Inflexibilit t ist unter anderem ein Grund daf r warum CASE Werkzeuge bis heute von vielen Entwicklern eher ablehnend be trachtet werden und den seit Anfang der 90er Jahre immer wieder prognostizierten Durchbruch immer noch nicht ganz geschafft haben Roth93 Iiva96 JaHu98 W hrend Referenzmodelle bei der Konfiguration betrieblicher Standardan Referenzmodelle wendungen bereits seit l ngerem mit gro em Erfolg angewendet werden ApRi99 in kreativen BeMS99 wird dieser Anpassungsansatz f r kreative Entwurfsprozesse in techni manen eae gt p 8 P kaum verf gbar schen Dom nen bislang noch kaum genutzt bzw ist gerade erst im Entstehen begriffen sind z B der Unified Process JaBR99 Kruc98 f r die objektorientierte Softwareentwicklung Als wesentlichen Grund daf r kann man anf hren dass in einem hochkreativen und spezialisiertem Bereich wie der Softwareentwicklung der Aufbau eines etablierten Fundus gutverstandener und umfassender Prozesse wesentlich schwieriger ist als bei betrieblichen Standardanwendungen Die Neudefinition und Erweiterung von Prozessen tritt also bei Softwareent wicklungsprozessen wesentlich st rker in den Vordergrund als die Auswahl aus existierenden Prozessen Als Grundvoraussetzung daf r m ssen Konzepte und Mechanismen f r die explizite Modellierung von Prozessen und die Interpretation von Prozessmodellen zur Verf g
46. tsbedingung wird nicht explizit gefordert dass f r die Darstellungselemente auch die oben genann ten Darstellungsarten hervorgehoben selektierbar und deaktiviert existieren Diese Zusatzbedingung ist bereits durch die im UML Modell spezifizierten Kardi nalit tsbedingungen siehe Abb 21 abgedeckt EK2 Aktivierbarkeit der Intentionen Um sicherzustellen dass eine Werkzeugkategorie die Intentionen aller Alternativen eines ihm zugeordneten Entscheidungskontexts darstellen kann muss jede Alter native ber die Assoziation Darstellung Intention mit der Werkzeugkategorie verkn pft sein Attribute Werkzeugkategorie f hrt EK aus with constraint EK2 forall w Werkzeugkategori k Entscheidungskontext k Kontext ke Kommandoelement From w this and To this ek and ek alternative k gt exists ke Kommandoelement w bietet_KE an ke and ke Darstellung Intention k end 5 6 Beispiel fur ein Umgebungsmodell 127 5 6 Beispiel fur ein Umgebungsmodell Abb 22 illustriert anhand eines kleinen Beispiels die Zuordnung der im Prozess modell definierten Ausf hrungs und Entscheidungskontexte zu den im Werk zeugmodell definierten Werkzeugressourcen Der bersichtlichkeit halber haben wir darauf verzichtet die Klassenebene der Umgebungs e amodells explizit darzu App 22 stellen Stattdessen ist in der Darstellung bei den einzelnen Instanzen zus tzlich Beispiel f r ein Umge der N
47. tzliche VT Prozesselemente angereichert O Konkretisierung Bei der Konkretisierung wird ein VI ProcessStep durch einen spezielleren VI ProcessStep oder UnitOperation beschrieben der die gleiche Funktion erf llt dessen Prozessverhalten jedoch konkretisiert wird und der n her an der apparativen Umsetzung ist O Realisierung Die Realisierungsbeziehung beschreibt die apparatetechni sche Umsetzung von VT ProcessSteps und oder UnitOperations mit Hil fe einer Gruppe von Anlagen Abb 71 auf Seite 253 liefert Beispiele f r alle vier Verfeinerungsarten Zur Beschreibung von Verfeinerungen f hren wir das Konzept der VT Pro zessgruppen VT ProcessGroup ein zwischen denen die oben beschriebenen Verfeinerungsbeziehungen eingerichtet werden k nnen mithilfe der Assoziations klasse isRefinedBy und den entsprechenden Subklassen Die Zugeh rigkeit eines VT Prozesselements zu einer VT Prozessgruppe wird durch die Assoziationen inRefinement und inGroup repr sentiert Der Unterschied zwischen diesen Asso ziationen liegt in den jeweiligen Rollen die die betreffenden VT Prozessgruppen innerhalb der Verfeinerungshierarchie spielen inRefinement bedeutet dass das VT Prozesselement zu einer verfeinernden V T Prozessgruppe geh rt Die Assoziati on inGroup dr ckt aus dass das VT Prozesselement einer verfeinerten VT Prozessgruppe angeh rt Ein VT Prozesselement kann zu beliebig vielen verfei nerten VT Prozessgruppen geh ren aber h chst
48. work das die Entwicklung prozessintegrierter und anpassbarer Werkzeuge signifi kant erleichtert Es stellt generische Komponenten f r die Synchronisation mit der Leitdom ne StateManager und MessageInterface und die Interpretation des Umgebungsmodells ContextManager zur Verf gung die das Prozessmodell konforme Verhalten eines Werkzeugs sicher stellen Spezifische Werkzeugfunktio nalit t kann an wohldefinierten Variationspunkten in das Framework eingeklinkt werden Durch die saubere Kapselung der Anbindung an spezifische GUI Biblio theken Datenbankmanagementsysteme und Kommunikationsmechanismen ist das Framework sehr einfach auf neue Plattformen portierbar Die Entwicklung eines prozessintegrierten Werkzeugs wurde anhand eines Entity Relationship Editors illustriert Insgesamt wurden bislang 17 Werkzeuge mithilfe des Frame works erstellt Dabei betrug der Wiederverwendungsgrad bei dem meisten Werk zeugen mehr als 85 7 4 Integration existierender Werkzeuge Das GARPIT Framework ist urspr nglich als ein Ansatz zur a priori Integration von Werkzeugen entwickelt worden Bisher sind wir in dieser Arbeit stets von einer Neuentwicklung der f r eine prozessintegrierte Umgebung ben tigten Werk zeuge mithilfe des Implementierungsframeworks ausgegangen Aus wissenschaftli cher Perspektive bestand unser prim res Ziel darin ein Konzept f r die Prozess integration von Entwurfsumgebungen zu entwickeln und dessen prinzipielle Machbar
49. 116 5 Integrierte Prozess und Werkzeugmodelle der dahinter liegenden Prozesse und bilden zusammen mit dem eigentlichen Pro dukt die so genannte Prozessspur Eine detaillierte Taxonomie f r die unterschiedli chen Kategorien von Produktinformationen ist in D mg99 zu finden Die zur Detaillierung des Produktmodells ben tigten Modellierungskonstrukte werden im Metamodell nicht weiter vorgegeben Wir gegen davon aus dass uns daf r die in der konzeptuellen Modellierung g ngigen Konstrukte und Strukturierungshilfs mittel Attribute Assoziation Aggregation Spezialisierung etc wie sie etwa aus der UML oder O Telos bekannt sind zur Verf gung stehen Intention Der subjektive Anteil eines Kontexts wird durch das Konzept der Intention dargestellt Eine Intention spiegelt ein Ziel wider das der Entwickler verfolgt Genau wie Situationen k nnen Intentionen auf unterschiedlichen Granularit ts ebenen angesiedelt sein Eine globale Intention k nnte lauten ein ER Schema zu erstellen eine lokale Intention k nnte in dem Hinzuf gen eines Attributs zu einem Entit tstypen bestehen Neben der Spezifikation der Situation und Intention zur Angabe seiner Akti vierungsbedingungen ist ein Kontext durch einen dritten Informationsblock die Art seiner Operationalisierung n her bestimmt Das NATURE Prozessmodell unterscheidet drei fundamentale Kategorien der Prozessunterst tzung die durch die Spezialisierungen Ausf hrungskontext Entscheidungsk
50. 1998 Dr schel W Heuser W und Midderhoff R Hrsg Inkrementelle und objektorientierte Vorgehensweisen mit dem V Modell 97 Oldenbourg Verlag M nchen Wien 1998 Emmerich W Arlow J Madec J und Phoenix M Too Construction for the British Airways SEE with the O2 ODBMS Theory and Practice of Object Systems 3 3 S 213 231 1997 Emmerich W Bandinelli S Lavazza L und Arlow J Fine grained Process Modelling An Experiment at British Airways In Proc 4th Intl Conf on the Software Process 1996 S 2 12 Eberleh E Oberquelle H und Oppermann R Hrsg Einf hrung in die Software Ergonomie Walter de Gruyter Berlin New York 1994 Ebenau R G und Strauss S H Software Inspection Process Mc Graw Hill Systems Design amp Implementation Series 1993 Ebert J S ttenbach R und Uhe I Meta CASE in Practice a Case for KOGGE In Olive A und Pastor J A Hrsg Proc 9th Intl Conf on Advanced Information System Engineering CAiSE 97 Barcelona Spain Springer Verlag Berlin Heidel berg LNCS 1250 1997 S 203 216 Eckerson W W Three Tier Client Server Architecture Achieving Scalability Performance and Efficiency in Client Server Applications Open Information Systems 10 1 S 3 23 1995 ECMA Reference Model for Frameworks of Software Engineering Environments Tech Report European Computer Manufacturers Association ECMA TR 55 3rd Edi tion 1993 Eddon G und Edd
51. Abb 2 Integrationstiefe der Prozessunterst tzung mit der rechnerbasierten Arbeitsumgebung Externe Prozessunterst tzung Rechnerbasierte Anleitung Prozess Entwurfsumgebung durchf hrung Entwurfs werkzeuge Prozess Prozess z wissen anleitung A Externe Prozessunterst tzung Prozess Entwurfsumgebung durchf hrung Entwurfs werkzeuge Prozess Prozess anleitung 8 wissen R ckmeldung Sep Anleitungswerkzeug B Rechnerbasierte separate Prozessunterst tzung Entwurfsumgebung Prozess durchf hrung wissen Prozess anleitung amp Prozessintegrierte R ckmeldung Entwurfswerkzeuge C Rechnerbasierte integrierte Prozessunterst tzung Bei der externen Prozessunterst tzung wird Wissen ber die intendierte Prozessausf h rung unabh ngig von der rechnerbasierten Arbeitsumgebung des Entwicklers kommuniziert und tritt dort nicht direkt in Erscheinung Typische Hilfsmittel Prozesswissen au erhalb der eigentlichen Arbeitsumgebung zu vermitteln sind Methoden und Projekthandb cher siehe Abschnitt 2 2 1 in denen Arbeitsplatz anweisungen und Projektrichtlinien aufbereitet sind sowie Trainings und Schu lungsma nahmen Bei der Bearbeitung einer Aufgabe kann daher extern definierte Prozessanleitung nur dann wirksam werden wenn sich der Entwickler an die Empfehlungen und Anweisungen erinnert und entsprechend handelt siehe Abb 2a Andernfalls wird die extern definierte Prozessanleitu
52. Abh ngigkeiten Beobachtungen CSTR a o Abh ngigkeits Editor Mithilfe des grafischen Abh ngigkeitseditor k nnen getypte feingranulare Abh n gigkeiten zwischen beliebigen Produktinstanzen erzeugt und visualisiert werden siehe Abb 35 unten In der grafischen Ansicht des Abh ngigkeitseditors werden die einzelnen Produkte durch produkttypspezifische Symbole angezeigt die durch gerichtete Abh ngigkeitskanten miteinander verbunden sind Mithilfe einer Brow sing Funktion kann der Benutzer ausgehend von einem ausgew hlten Produkt alle abh ngigen Produkte ermitteln und so in einem Netz von Abh ngigkeiten entlang navigieren Abh ngigkeiten k nnen entweder manuell durch den Benutzer oder w hrend des Entwicklungsprozesses automatisch bei der Ausf hrung entspre chender Prozessfragmente angelegt werden 7 1 2 2 Prozessmaschine In der Leitdom ne koordiniert die Prozessmaschine die Ausf hrung von Plan kontexten Analog zu den Werkzeugen wird ein gro er Teil der administrativen Basisfunktionalit t durch das generische Prozessmaschinen Framework GARPEM 7 1 Die PRIME Gesamtarchitektur bereit gestellt Insbesondere realisiert das Framework das in Abschnitt 7 2 be schriebene Interaktionsprotokoll zwischen den Prozessdom nen aus Sicht der Leitdom ne Weiterhin liefert GARPEM die koordinierende Laufzeit Umgebung f r die Ausf hrung geschachtelter verschiedensprachlich definierter Plankontex ten Die Anbindung der daf r erforde
53. Attributb ume Nachrichtenobjekte Kommunikationskanal generische Datenbankklassen generische GUI Klassen Fenster Dialoge Men steuerung etc generische Shape Klassen Interpretation des Umgebungsmodells globale Zustandskontrolle Ereignisbehandlung Verzeichnisklassen f r GUI und Aktionsobjekte Die werkzeugspezifischen Anteile betragen je nach Werkzeug zwischen 4 000 und 41 000 Codezeilen F r ein durchschnittliches Werkzeug sind zwischen 8 000 und 15 000 Codezeilen f r die Realisierung des werkzeugspezifischen Produktmodells der Benutzeroberfl chenelemente und der Aktionen zu veranschlagen Damit ergibt sich bei den meisten Werkzeugen ein Wiederverwendungsgrad von mehr als 85 siehe Tab 15 f r eine Einzelaufstellung 220 Tab 15 Gr e der Werkzeuge und Wiederverwen dungsgrad 7 Das PRIME Rahmenwerk Werkzeug Gr e des werkzeugspezifi schen Codes kloc Wiederverwendung ER Editor Entscheidungs Editor Abhangigkeits Editor Hypertext Editor Ziel Editor MSC Editor Whiteboard Editor Review Manager Produktmodell Editor Flie bild Editor VeDa Editor Task Manager Werkzeugmodell Editor PC Editor SLANG PC Editor Statecharts Anleitungswerkzeug Prozessspuren Visualisierer 7 3 4 Beispielanwendung des GARPIT Frameworks In diesem Abschnitt illustrieren wir die Arbeitsschritte bei der Entwicklung e
54. BaKr95 Feedback und Synchronisationsprotokolle Um Abweichungen zwischen dem realen und dem beobachteten Prozess zu ver meiden muss das Zusammenspiel zwischen Leit und Durchf hrungsdom ne durch ein definiertes und von beiden Seiten respektiertes Synchronisationsprotokoll koordiniert werden Ein solches Protokoll muss nicht nur Aufrufbeziehungen von Synchronisationsproto der Leitdom ne zur Durchf hrungsdom ne im Sinne einer klassischen Client koll zum Abgleich Server Interaktion vorsehen Aufruf einer Werkzeugaktion und Auswertung der Zwischen realem und a beobachtetem Prozess Ergebnisse sondern muss daf r Sorge tragen dass auch sonstige prozessrelevante Ereignisse und Informationen aus der Durchf hrungsdom ne laufend an die Leitdom ne zur ckgeliefert werden Am nat rlichsten lassen sich die prozessrele vanten Ereignisse direkt aus den Werkzeugen in den Durchf hrungsdom ne ableiten da der Zustand der Werkzeuge geladene Dokumente und die dort statt findenden Ereignisse Selektion von Objekten Aktivierung von Kommandos den aktuellen Prozess reflektieren Die erforderlichen R ckmeldungen h ngen vom aktuellen Zustand der Pro zessmodellausf hrung ab Da wir davon ausgehen dass die Prozessunterst tzung nicht durchg ngig sondern nur f r fragmentarisch modellierte Prozessabschnitte aktiv wird m ssen wir zwischen einem reaktiven und einem proaktiven Modus der Prozessunterst tzung unterscheiden BaDF96 Im reak
55. Benutzerdienstebene wird als Adaptionsbeziehung aufgefasst Die zu unterst tzenden Prozesse definieren Richt 3 1 Perspektiven der Werkzeugintegration 51 linien und Einschr nkungen f r die Verwendung von Benutzerdiensten und legen eine Reihenfolge in der Verwendung der Dienste fest Indem entlang eines vorge gebenen Entwurfsprozesses bestimmte Dienste die Eingabe f r nachfolgende Dienste liefern l sst sich identifizieren welche Dienste miteinander interagieren m ssen und welche Schnittstelle sie aufweisen m ssen Der Wert dieser Betrach tungsweise liegt darin dass die Analyse der zu unterst tzenden Entwurfsprozesse dem Umgebungsintegrator Aufschluss dar ber gibt auf welche Integrati onsbeziehungen zwischen Werkzeugen er sich konzentrieren sollte anstatt jedes Werkzeug vollst ndig mit jedem anderen zu integrieren 3 1 4 Fazit Werkzeugintegration kann aus unterschiedlichen Blickwinkeln betrachtet werden W hrend fr he Ans tze Integration haupts chlich als eine Frage des koordinierten Informationsmanagements zwischen Werkzeugen schen hat sich seit dem Klassi fikationsschema von Wasserman Wass90 eine reichhaltigere Sichtweise auf das Integrationsproblem durchgesetzt welche insbesondere auch den Begriff der Prozessintegration umfasst Wasserman verkn pft Prozessintegration mit dem Vorhandensein expliziter Prozessmodelle und einer Prozessmaschine also Elementen der Modellierungs bzw Leitdom ne die mit den Entwicklungs
56. Cooperation Mechanism in Distributed Systems ACM Operating System Review 27 3 S 75 86 1993 Weidenhaupt K und Bayer B Proze integrierte Designwerkzenge f r die V erfabrenstech nik In Proc der Jahrestagung der Gesellschaft f r Informatik Informatik 99 Pa derborn Germany Oct 1999 S 305 313 Weidenhaupt K Adaptabilit t von Entwicklungsumgebungen Modellierung und Programmie rung Diplomarbeit RWTH Aachen 1995 WFMC Workflow Standard Interoperability Abstract Specification Workflow Manage ment Coalition WFMC TC 1012 1996 WEMC Workflow Management Application Programming Interface Interface 2 amp 3 Specifica tion Workflow Management Coalition WFMC TC 1009 Version 2 0 July 98 1998 298 Literaturverzeichnis WFMC98b WFMC W MC Interface 1 Process Definition Interchange Process Model Workflow Man Wije91 WPJH98 XMI 99 YoCo79 Your89 agement Coalition WFMC TC 1016 P 1998 Wijers G Modelling Support in Information Systems Development Dissertation Delft University of Technology 1991 Weidenhaupt K Haumer P Pohl K und Jarke M Scenarios in System Development Current Practice IEEE Software 15 2 S 34 45 3 1998 XMI Partners XML Metadata Interchange XMI 1 1 RTF Final Report Tech Report Object Management Group OMG Document ad 99 10 04 October 20 1999 http www omg org cgi bin doc ad 99 10 04 Yourdon E und Constantine L L Structured De
57. Durchf h cken sowie den synchronen und asynchronen Empfang der in Abschnitt 7 2 defi tings und Leitdom ne nierten Nachrichten Es abstrahiert damit vom konkret eingesetzten Mechanismus zur Interprozess Kommunikation IPC und erlaubt dessen einfache Austausch barkeit Das Teilsystem GenericGUI stellt eine Reihe allgemein verwendbarer Klassen GenericGUI f r Fenster Men verwaltung Dialoge und grafische Objekte Shapes zur Ver Oberfl chenprogram l 3 mierung f gung und abstrahiert dabei vom zugrunde liegenden GUI Toolkit Es sorgt insbesondere f r die Weiterleitung von Benutzerereignissen an den StateManager so dass der StateManager und die restlichen generischen Architekturkomponen ten unabh ngig vom gew hlten GUI Toolkit realisiert werden kann Werkzeug spezifische Benutzeroberfl chen T_GUI kommen weitgehend mit den von Gene ricGUI bereitgestellten Diensten aus und m ssen nur in Ausnahmef llen auf Klas sen eines spezifischen GUI Toolkits zugreifen Das Teilsystem Kit ist eine Sammlung von allgemein verwendbaren Hilfsklas Kit sen die von vielen Teilsystem des GARPIT Frameworks verwendet werden e SEN Neben einer Reihe von Typabstraktionen enth lt dieses Paket vor allem die Teil Attributrepr pakete Contract Assoc und GARP Contract enth lt Hilfsmittel f r das Programmie sentation ren per Vertrag Design by Contract Meye97 Assoc stellt eine Familie von Template Klassen f r
58. ER Editor verwendeten Kommandoelemente Men s Kommando Icons Shortkey Binding festgelegt werden Auch hier bieten das Werkzeugmetamodell und das Framework eine Palette vordefinierter Kommandoelemente f r die g ngigsten Intentionen z B Open Diagram deren konsistente Verwendung in unter schiedlichen Werkzeugen f r ein einheitliches Look and Feel sorgen Aktionsmodellierung Die im Werkzeug modellierten Aktionen definieren die Basisfunktionalit t des ER Editors auf deren Basis sp ter komplexere Prozessfragmente gebildet werden k nnen Die Ein und Ausgabeparameter der Aktionen werden als Situationstypen die auf den zuvor definierten Produkttypen basieren modelliert Zu den typischen Aktionen geh ren Erzeugung und L schoperationen f r die jeweiligen Produkt typen wie z B createEntity deleteEntity aber auch Layout Operation die das Produktmodell unver ndert lassen F r den ER Editor wurde ein Satz von ca 20 Aktionen definiert 7 3 4 2 Phase 2 Implementierung Realisierung des Produktmodells Das Produktmodell wird zun chst in relationales Datenbankschema bertragen Bei dieser Abbildung wird von den generischen Komponenten des Frameworks lediglich verlangt dass die Tabellennamen mit den Klassennamen im objektorien tierten Produktmodell korrespondieren und dass jede Tabelle ber ein Attribut ID zu eindeutigen Identifikation und ein Attribut ExternalName zur textuellen Dar stellung von Instanze
59. ER Editor wird diese Klasse jedoch spezialisiert und mit Werkzeug spezifischen Methoden ange reichert die einen bequemeren Zugriff auf die ObjectTable Funktionalit t erlau ben hier z B CersObjectTable insertRelationship 7 3 4 3 Phase 3 Prozessmodellierung Nach Phase 1 und 2 verf gt der ER Editor zwar im Prinzip bereits ber seine Basisfunktionalit t jedoch ist diese noch nicht in komplexeren Abl ufen und f r andere Werkzeuge nutzbar Dazu m ssen zun chst f r alle Aktionen im Prozessmodell korrespondierende Ausf hrungskontexte modelliert werden wodurch die Funktionalit t des ER Editors auf Prozessmodellierungsebene zug nglich wird Die Ausf hrungskon texte k nnen insbesondere in Plankontexte und Entscheidungskontexte anderer Werkzeuge eingebettet werden so dass der ER Editor werkzeug bergreifend eingesetzt werden kann 7 3 GARPIT ein Framework f r prozessintegrierte Werkzeuge 225 Mithilfe von Entscheidungskontexten werden die Arbeitsmodi des ER Editors modelliert Als Minimalkonfiguration sind ein oder mehrere Standardkontexte erfor derlich die je nach vorliegender Situation z B kein ER Diagramm geladen oder ER Diagramm geladen die verf gbaren Optionen im Standardarbeitsmodus umfassen In die Entscheidungskontexte des ER Editors k nnen durchaus auch Kontexte anderer Werkzeuge deren Aktivierung aus dem ER Editor heraus sinn voll ist aufgenommen werden Ein Ausschnitt aus dem integrierte
60. Einf gen des Zeichenelements in das aktuelle Diagramm durch ein entsprechendes Ereignis informiert Dies konfligiert jedoch mit dem GARPIT Modell der Ereignisabarbeitung bei der nach der Intentionsaktivierung erst der ContextMatcher aktiviert wird und von diesem dann die eigentliche Kontextausf hrung angesto en wird Dies soll von vorneherein eine Abweichung von der intendierten Prozessanleitung verhindern die sich dann erg be wenn die Einf ge Aktion nicht zu den erlaubten Alternativen im aktuellen Entscheidungskontext geh rte und eigentlich gar nicht h tte durchgef hrt werden d rfen In der Visio Integration haben wir dieses Problem dadurch umgangen dass nach dem Ausl sen des Ereignisses Element eingef gt die durchgef hrte Aktion mit Hilfe des ContextManagers nachtr glich auf ihre Zul ssigkeit gepr ft und gegebenenfalls unter Ausnutzung der von Visio angebotenen Undo Funktion r ckg ngig gemacht wird O Wir hatten urspr nglich geplant Visio und den Prozessintegrations Wrap per als zwei getrennte Betriebssystemprozesse zu realisieren wobei Visio als COM Automation Server fungieren und ber seine Automation Schnitt stelle durch den Prozessintegrations Wrapper kontrolliert werden sollte In diesem Modus bietet Visio einem externen Klienten jedoch aus einem f r uns nicht ersichtlichen Grund nicht die M glichkeit sich f r den Erhalt von Men Ereignissen zu registrieren Diese Funktion die essentiell f r die Erkennun
61. Entscheidungskontext ausw hlbaren Al ternativen wiederum anderen Werkzeugen zugeordnet sein k nnen Da 129 130 5 Integrierte Prozess und Werkzeugmodelle durch k nnen aus einem Werkzeug heraus auch Prozessschritte aktiviert werden die nicht von dem Werkzeug selbst operationalisiert werden Mit hilfe der Konzepte Plan und Entscheidungskontext sind somit die we sentlichen prozessrelevanten Aspekte bei der Interaktion zwischen unter schiedlichen Werkzeugen explizit auf der Ebene der Prozessmodellierung repr sentiert und einer einfachen Adaptierbarkeit zug nglich Q A3 Integrierte Prozess und Werkzeugbeschreibung Prozessfrag mente und Werkzeugaspekte werden auf der gleichen konzeptuellen Ebene repr sentiert und ber gemeinsame Konzepte bzw zus tzliche Assoziatio nen im Umgebungsmetamodell zueinander in Beziehung gesetzt Gleich zeitig erlaubt der modulare Aufbau des Gesamtmodells aus einem Prozess und einem Werkzeugmetamodells eine saubere Trennung zwischen pro zesstelevanten und werkzeuginh renten Aspekten Das hei t dass Pro zesswissen in Form von Kontextdefinitionen zun chst unabh ngig von ei ner Beschreibung der Werkzeuge definiert werden kann und umgekehrt Werkzeuge prozessneutral beschrieben werden k nnen Erst durch die Zuordnung zwischen Prozess und Werkzeugmodell wird eine spezifische prozessintegrierte Umgebung konfiguriert Die klare Separierung von Pro zess und Werkzeugaspekten stellt einen wesentlic
62. Entwurfsdaten immer noch die am weitesten verbreitete L sung Werkzeuge legen ihre Daten in Dateien eines gemeinsam benutzten Dateisystems ab die dann von anderen Werkzeugen gele sen werden Dies erfordert dass sich die Hersteller der Werkzeuge auf ein gemein sames Datenformat verst ndigt haben Da dies bei unabh ngig voneinander ent wickelten Werkzeugen jedoch im Allgemeinen nicht der Fall ist werden zus tzli che Konvertierungsprogramme ben tigt die die von einem Werkzeug exportierten Daten in das Format eines importierenden Werkzeugs transformieren Diese Vorgehensweise ist jedoch sehr m hsam und aufw ndig da zum einen die von den Werkzeugen verwendeten Datenformate und schemata h ufig nicht allgemein bekannt sind so dass in diesen F llen keine oder nur eine teilweise Transformation 5 der Daten gelingt Zum anderen werden f r die paarweise beidseitige Integration Das n Konverter 2 Problem von n Werkzeugen insgesamt 2 n n 1 2 n Konvertierungspro gramme ben tigt siehe Abb 8b1 Aus diesem Grunde sind in unterschiedlichen Entwurfsdom nen zahlreiche Standardisierungsinitiativen unternommen worden mit dem Ziel geeignete Aus tauschformate zu entwickeln und zu vereinheitlichen Beim Vorliegen eines von alen Werkzeugherstellern einer Entwurfsdom ne respektierten Austauschstan dards wird f r jedes Werkzeug lediglich ein Import und ein Exportfilter ben tigt um Daten aus dem neutralen Datenformat in d
63. Honolulu Hawaii USA Oct 1998 S 196 199 Garg P Mi P Pham T Scacchi W und Thunquest G The SMART Approach for Software Engineering Processes In Proc 16th International Conference on Software En gineering Sorrento Italy IEEE CS Press Los Alamitos CA 1994 S 341 350 Gane C und Sarson T Structured Systems Analysis Tools and Techniques Prentice Hall Englewood Cliffs New Jersey 1979 Genesereth M und Fikes R Knowledge Interchange Format v 3 Reference Manual Stan ford University 1992 Georgakopoulos D und Hornick M F A Framework for Enforceable Specification of Extended Transaction Models and Transactional Workflows International Journal of Intel ligent and Cooperative Information Systems 3 3 S 225 253 1994 Gamma E Helm R Johnson R E und Vlissides J Design Patterns Elements of Reusable Object Oriented Software Addison Wesley 1995 Gisi M A und Kaiser G E Extending a Tool Integration Language In Proc 1st Intl Conference on Software Process Redondo Beach CA USA Oct 1991 S 218 227 Gotel O und Finkelstein A An Analysis of the Requirements Traceability Problem In Proceedings of the 1st International Conference on Requirements Engineering Colorado Spring Colorado USA IEEE Computer Society Press 1994 S 94 102 Goldberg A Smalltalk 80 The Interactive Programming Environment Addison Wesley Reading MA 1984 GOODSTEP Team The GOODSTEP Proje
64. Integrationsproblems vorge schlagen worden sind In Abschnitt 3 2 diskutieren wir die grunds tzlichen M g lichkeiten und Grenzen der a posteriori und a priori Integration und motivieren warum wir in dieser Arbeit den Schwerpunkt auf letztere legen Die spezifischen Anforderungen an die Integration der Prozessdom nen werden Abschnitt 3 3 zusammen mit m glichen L sungsans tzen ausf hrlich dargestellt Abschnitt 3 4 fasst die Ergebnisse des Kapitels zusammen 3 1 Perspektiven der Werkzeugintegration Die Prozessintegration von Werkzeugen ist keine v llig neue Fragestellung son dern f hrt unterschiedliche Integrationsprobleme zusammen f r die mittlerweile jeweils zum Teil recht ausgereifte L sungsans tze in der Literatur vorliegen In der Tat geh rt die Werkzeugintegration zu den am intensivsten untersuchten Teilge bieten der Forschung ber Entwurfsumgebungen und wird von manchen Autoren aus dem Bereich der Softwaretechnik gar als der heilige Gral der SEE und CA SE Technologie bezeichnet BrEM92 Nichtsdestotrotz hat sich auch nachdem vor nunmehr 20 Jahren mit dem Stoneman Report DoD 80 der Startschuss f r eine systematische Besch ftigung mit integrierten Entwurfsumgebungen gefal len ist das Integrationsproblem einfachen L sungen standhaft widersetzt und gilt 48 3 Integrationsansatze immer noch als eine schwierige Herausforderung fiir Forscher und Praktiker aus diesem Bereich Meye91 ScBr93 Bro 94 Kelt93
65. Internet Computing S 37 45 May June 2000 Henderson Sellers B und Edwards J M Object Oriented Knowledge The Working Object Prentice Hall 1993 Heimbigner D Proscription versus Prescription in Process Centered Environments In Proc of the 6th Intl Software Process Workshop Support for the Software Process Ha kodate Japan Oct 1990 S 99 102 Heimbigner D The ProcessWall A Process State Server Approach to Process Programming In Procs 5th ACM SIGSOFT SIGPLAN Symposium on Software Development Environments Dec 1992 S 159 168 Heimann P Krapp C A und Westfechtel B An Environment for Managing Software Development Processes In Proc 8th Conference on Software Engineering Environ ments Cottbus Germany April 1997 S 101 109 Herczeg M Software Ergonomie Addison Wesley 1994 Hitz M und Kappel G UML Work dpunkt Verlag 1999 Heimann P Joeris G Krapp C A und Westfechtel B DYNAMITE Dynamic Task Nets for Software Process Management In Proc 18th Intl Conf on Software Engi neering Berlin Germany 1996 S 331 341 Hoare C A R Communication Sequential Processes Printice Hall Englewood Cliffs New Jersey 1985 Hollingsworth D The Workflow Reference Model Tech Report Workflow Manage ment Coalition TC00 1003 1995 Horvitz E Bresse J Heckerman D Hovel D und Rommelse K The Lumi re Project Bayesian User Modeling for Inferring the Goals and Needs of Softwa
66. Kommunika tionsmanager erm glicht den Kommunikationspartnern einen Nachrichtenaus tausch auf logisch hohem Niveau indem er das Wissen ber Details der Nach richtenverteilung kapselt Werkzeuge und Prozessmaschine kommunizieren dabei auf der Ebene von Kontextanforderungen und antworten ohne die genauen Adressaten kennen zu m ssen Der Kommunikationsmanager sorgt dabei f r eine Abstraktion von den Empf ngern einer Nachricht und deren Muitiplizit t indem er sich bei der Nachrichtenverteilung zum einen auf die Zuordnung von Kontexten zu Werkzeugkategorien im Umgebungsmodell abst tzt und zum anderen in einer internen Werkzeug Tabelle Buch ber die aktuell laufenden Werkzeuginstanzen f hrt Im Folgenden illustrieren wir anhand einiger charakteristischer Szenarien wie der Kommunikationsmanager im Rahmen des oben dargestellten Interakti onsprotokolls f r eine transparente Nachrichtenverteilung sorgt Guidance Request Kommunikations manager Werkzeug Tabelle Umgebungs modell GuidanceRequest Prozess maschine Aktivierung von Plankontexten Im einfachsten Fall besteht die Funktion des Kommunikationsmanagers in einer blo en Weiterleitung einer Nachricht Diese Situation liegt beispielsweise dann vor wenn ein Werkzeug nach der Aktivierung eines Plankontexts durch den Be nutzer eine GuidanceRequest Nachricht absetzt Diese Nachricht wird vom Kommunikationsmanager an die Prozessmaschine weitergeleitet
67. Meye91 Ein konkreter Bezug zwischen den Daten unterschiedlicher Werkzeug wird immer nur zum Zeitpunkt der Transformation der Daten von einem Werk zeug zu einem anderen mithilfe eines Konverters hergestellt Nachfolgende Bearbeitungen der Daten in einem der betroffenen Werkzeuge k nnen Inkon sistenzen hervorrufen und sind bei einer manuellen Vorgehensweise nicht ohne weiteres zu entdecken und zu beheben Zur Unterst tzung der Konsistenzsicherung voneinander abhangiger Daten in Integratoren des IPSEN unterschiedlichen Werkzeugen sind im Rahmen des IPSEN Projekts Nagl96 eine Projekts Reihe von Integratoren Lefe95 entwickelt worden die im Kern als Erweiterung traditioneller Datei Konverter verstanden werden k nnen Der wesentliche Unter 5 Die Object Management Group ist ein Herstellerkonsortium mit ber 700 Mitgliedern darunter praktisch jedes namhafte Unternehmen der IT Branche mit Ausnahme von Microsoft das sich der F rderung und Etablierung objektorientierter Techniken in verteilten heterogenen Systemumge bungen zum Ziel gesetzt hat 6 XML Metadata Interchange 64 3 Integrationsansatze schied zu einfachen Konvertern besteht in der fortlaufenden Wartung feingranula rer Beziehungen zwischen Inkrementen unterschiedlicher Dokumente ber eine initiale Transformation hinaus Dazu werden Korrespondenzbeziehungen zwi schen Werkzeugdokumenten innerhalb eines eigenen Integrationsdokuments verwaltet anhand dessen nderungen in
68. Modellierung des Typsystems Bei der Modellierung des Typsystems nehmen wir an dass sich die zu integrieren den Modellierungssprachen und das Schnittstellenmetamodell ein gemeinsames Typsystem zur Definition des Produktmodells teilen Diese Vorgehensweise ist naheliegend da wir gem der Anforderung nach Datenintegration davon ausge hen dass das zugrunde liegende Produktmodell ber die gesamte Entwurfsumge bung integriert ist und zentral von Produktmodellierungswerkzeugen bearbeitet werden kann Ein Typ wird somit einmalig global spezifiziert und kann dann in jeder f r die Implementierung von PK Komponenten benutzten Prozessmodell sprache verwendet werden Dies stellt zwar eine Vereinfachung dar da genauge nommen jede Sprache ihr eigenes Typsystem mit Basis und benutzerdefinierten Typen mitbringt Die Abbildung von IDL Spezifikationen auf sprachspezifische Typsysteme in Ans tzen wie CORBA oder COM zeigt jedoch dass dies grund s tzlich ohne schwerwiegende semantische Verluste m glich ist so dass wir die Interoperabilitat von Typspezifikationen zur Produktmodellierung hier nicht weiter untersuchen 150 6 Interoperabilitat von Prozesssprachen Ausgangsschnittstelle von Entscheidungskontext Komponenten Etwas komplizierter als bei Ausf hrungs und Plankontexten ist die Beschreibung der Ausgangsschnittstelle von Entscheidungskontext Komponenten EK Kom ponenten die den Benutzer bei der Auswahl unter einer Menge von Vorgehens alte
69. PC_FBW_RetieveRtefinementPatters PC_FEW_ChoosetitemativeByDevice Ej PRIME Tool Modeler meal Document Edit Create Tools Preferences ce Menue Context za External name CC_FB W_AFDSheetActive ory Type Choice Context CC isana mono E Situation AFDSheetActive Intention NO INTENTION Aeceimat 7 Tool of Choice Context Toot FlowsheetEditor Altematives of a choice context modelled in a tool Pian Context Choice Context Executable Context CC type alternatives I 1 1 _ PC _ASP_SimulateGivenRefinement PC _FBW_ChooseAlternative PC FBW ChooseAlternativeByDevice FBW _CloneSheet FBW_ConnectorDropped C FBW ConnectorReglued PC FBW ContinueRefineExtruder C FBW CreateProject C FBW CreateVersion You can change the alternatives of the Choice Context Pian Context Choice Context FBW RefineReacByCSTR CSTR PC_FBW RefineReacByCSTR CSTR FBW RefineReacByCSTR PFR Unrestricted EC_TMD_ChangeCCAlternative Zun chst wird der neue Plankontext als Alternative zum Entscheidungskontexts CC FBW AFDSheetActive Abb 76 unten links Dies ist ein Standardkontext des Flie bildwerkzeugs der immer dann aktiv ist wenn aktuell ein Grundflie bild geladen ist In einem zweiten Schritt wird festgelegt dass die Intention des neuen Plankontexts im Men Guidance Prozessanleitung als Men punkt erscheinen soll Abb 76
70. Petrinetz orientierten Sprachen oder einfache Zu st nde in Zustandsdiagrammen Die Atomizit t bezieht sich dabei lediglich auf die Darstellung der Komponente im Fragment und nicht auf ihre innere Zusammen setzung denn intern setzen sich Kontextkomponenten selbstverst ndlich aus weiteren Teilkomponenten zusammen die jedoch aus Verwendungssicht nicht sichtbar sind 154 6 Interoperabilitat von Prozesssprachen Ausgang Prozesssprachen M2 Datenbeh lter Meta Schnittstelle SO Aktivit t Modell u ER Eingang OR atomareAktivit t zusammengesetzteAktivit t Zusammengesetzte Aktivit ten bilden die Struktur von Modellierungssprachen ab die eine Dekomposition eines Fragmentes in weitere Teilfragmente erm gli chen und in der sich die Implementierung des Fragments auf die atomaren Aktivit ten als Basiselemente st tzt Durch Komposition von atomaren Aktivit ten kann schrittweise der komplexe Dienst des Fragmentes realisiert werden der ber die Aktivit tsschnittstelle in Anspruch genommen wird Diese Eigenschaft entspricht der Kompositionsstruktur von Plankontexten die sich ebenfalls aus weiteren Kontexten zusammensetzen und ist daher Voraussetzung f r die Integrierbarkeit einer Sprache Neben der Abstraktion der Prozesssprachen Basiskonzepte abstrahiert das PSM2 Modell auch von den Konzepten des Schnittstellenmetamodells Dies ist erforderlich damit bei der Integr
71. Polymorphism Computing Surveys 17 4 S 471 522 1985 Cugola G Di Nitto E Fuggetta A und Ghezzi C A Framework for Formalizing Inconsistencies and Deviations in Human Centered Systems ACM Transactions of Software Engineering and Methodology 5 3 S 191 230 1996 CDGM95 Chen76 ChHJ93 ChN 092 Chr 97 Chu 98 Clem96 C1Os90 CNWLOO CoBe88 CoJa99 CoSc95 CoWe98 CoYo9 1a CoYo91b CuDF98 Cugo98 CuKO88 CuK092 DaEA98 DEC 93 DeGr93 Literaturverzeichnis 283 Cugola G Di Nitto E Ghezzi C und Mantione M How To Deal With Deviations During Process Model Enactment In Proc 17th Intl Conf on Software Engineering Seattle Washington USA May 1995 S 265 273 Chen P P S The Entity Relationship Approach Towards a Unified View of Data ACM Transactions on Database Systems 1 1 1976 Chen P S Hennicker R Jarke M On The Retrieval of Reusable Components In Advances in Software Reuse Selected Papers from the Second International Work shop on Software Reusability Lucca Italy March 24 26 1993 S 99 108 Chen M und Norman R A Framework for Integrated CASE TEEE Computer S 18 22 March 1992 Christie A Levine L Morris E Riddle W Zubrow D Belton T Proctor L Cordelle D Ferotin J E und Solvay J P Software Process Automation Interviews Survey and Workshop Results Tech Report S
72. Process Related Sub Environments In Procs 7th Intl Software Process Workshop 1991 S 124 126 Simmonds 1 Aerospace Systems Software Engineering Environment In Schefstr m D und Broek G van den Hrsg Tool Integration Environments and Frameworks John Wiley amp Sons 1993 S 97 205 Schuster H Jablonski St Heinl P und Bussler Ch A General Framework for the Execution of Heterogenous Programs in Workflow Management Systems In Proc 1st IFCS Conference on Cooperative Information Systems CoopIS Brussels Belgium 1996 S 104 113 Slooten K van und Brinkkemper S A Method Engineering Approach to Information Systems Development In Prakash N Rolland C und Pernici B Hrsg Information Systems Development Process Elsevier Science Publishers Amsterdam NL 1993 S 167 186 Slooten K van und Hodes B Characterizing IS Development Projects In Brinkkemper S Lyytinen K und Welke R Hrsg Method Engineering Principles of Method Construction IFIP Chapman amp Hall 1996 S 29 44 Soley R und Kent W The OMG Object Model In Kim W Hrsg Object Oriented Concepts Databases and Applications ACM Press New York 1995 S 18 41 Sol H G A Feature Analysis of Information Systems Design Methodologies In Olle T W Sol H G und Tully C J Hrsg Information Systems Design Methodologies El sevier Science Publishers Amsterdam NL 1983 S 1 7 Sommerville I Software E
73. Produkten und Kommandos mit den Kontextdefinitionen des Umgebungsmodells abgleichen und die Aktivierung eines Kontextes erkennen O Verwaltung von Kontextdefinitionen Da potenziell jede Benutzerinteraktion mit den externen Kontextdefi nitionen abgeglichen werden muss bergen st ndige Anfragen an das Prozessrepository die Gefahr eines Leistungsengpasses Innerhalb der Werkzeugarchitektur wird daher ein Ged chtnis Baustein ben tigt der die f r ein Werkzeug relevanten Kontextinformationen aus dem Pro zess Repository in einer Laufzeit Datenstruktur organisiert und effi zient verwaltet O Synchronisation mit der Leitdom ne Das Werkzeug muss ber eine Schnittstelle zur Leitdom ne verf gen und Nachrichten mit der Prozessmaschine gem dem Interaktionsprotokoll aus Abschnitt 7 2 austauschen und verarbeiten k nnen Neben Komponenten f r die Umsetzung dieser generischen Anforderungen muss das GARPIT Framework dar ber hinaus Variationspunkte f r die Erweiterung um werkzeugspezifische Produktmodelle und Benutzeroberfl chenelemente vor sehen 7 3 1 2 Nichtfunktionale Anforderungen Zus tzlich zu den oben genannten funktionalen Anforderungen haben eine Reihe nichtfunktionaler Anforderungen die Architektur des GARPIT Frameworks ma geblich beeinflusst O Wiederverwendung Wiederverwendung sowohl auf Kodeebene als auch auf Architekturebene ist die eigentliche Grundmotivation f r die Wahl einer Framework basier ten Entwur
74. Reference Model across Industries In Proceedings IFIP WG 8 2 amp WG 8 6 Joint Working Conference on Information Systems Current Issues and Future Changes Helsinki Finnland 1998 S 471 488 Barghouti N und Kaiser G E Scaling Up Rule Based Software Development Environ ments In Proc 3rd European Software Engineering Conference ESEC 91 Milan Italy Springer LNCS 550 1991 S 380 395 Barghouti N und Krishnamurthy B An Open Environment for Process Modeling and Enactment In Proc Sth Intl Software Process Workshop State of the Practice in Process Technology Wadern Germany March 1993 S 33 36 Barghouti N und Krishnamurthy B Using Event Contexts and Matching Constraints to Monitor Software Processes In Proc 17th Intl Conf on Software Engineering Seattle Washington USA May 1995 S 83 92 Bellissard L Atallah S B Kerbrat A und Riveill M Component based Programming and Application Management with Olan In Briot J und Geib J Hrsg Proceedings of Workshop on Object Based Parallel and Distributed Computation Springer Verlag LNCS 1107 1995 S 290 309 Banavar G und Lindstrom G An Application Framework for Module Composition Tools In Proc of the European Conference on Object Oriented Programming ECOOP 96 Springer Verlag LNCS 1098 1996 Balzert H Lehrbuch der Sofhvare Technik Sofhvare Entwicklung Spektrum Akademi scher Verlag Heidelberg Berlin Oxford 1996 Baum
75. SLANG Netz fest Die SLANG Bindung besteht entsprechend der Struktur des Bindungs M2 Modells aus einer Aktivit tsbindung einer Schnitt stellenbindung und einer Beh lterbindung Die Aktivit tsbindung SLANG AB assoziiert eine Kontextkomponente mit einer Transition Die Verwendung einer Kontextkomponente in einem SLANG Aktivit tsnetz wird somit durch eine Transition repr sentiert Um die Abbildung einer Komponentenschnittstelle in einem SLANG Netz repr sentieren zu k nnen wird eine SLANG Schnittstellen bindung SLANG SB instanziiert Dabei wird eine Ein bzw Ausgangsschnittstelle einer Kontextkomponente durch den Vor bzw Nachbereich einer Transition repr sentiert Die Beh lterbindung SLANG PB dr ckt aus dass ein Produktteil des Schnittstellenmetamodells durch eine Stelle in einem SLANG Netz dargestellt wird Die strukturell korrekte Zuordnung von Produktteilen auf Stellen ist bereits 160 6 Interoperabilitat von Prozesssprachen durch die im vorigen Abschnitt formulierten Metaregeln auf der Ebene des M2 Modells zugesichert komponente Q 0 Eingang a Ausgang sprachneutrale Darstellung Schnittstelle Schnittstellen bindung Q Q 5 SLANG_PB Preehlsiell k Beh lterbindung N Schritt 3 Sprachspezifische Abbildungsregeln Abb 33 SLANG Bindung SLANG_Bindung Bindung Prozesssprachen konzept sprachneutrale Darstellung SLANG_AB Aktivitats bindung Q Vorbe
76. Sche93 Tann94 Ortn99 IRDS90 Der Verwaltung und der Austausch von Daten ber ein Repository weist im Vergleich zum Datenaustausch ber Dateien selbst beim Vorliegen kanoni scher standardisierter Datenformate wie CDIF oder XMI oder bei der Nutzung von Integratoren eine Reihe gravierender Vorteile auf BeDa94 Q Der Aufbewahrungsort der Daten ist bekannt sie befinden sich innerhalb der Repositories und sind nicht ber mehrere Dateien verteilt welche von den einzelnen Werkzeugen unabh ngig verwaltet werden m ssen Q Es gibt lediglich eine Kopie von jedem geteilten Objekt so dass Inkon sistenzen durch die unabh ngige Manipulation und Verwaltung mehrerer Kopien eines Objekts in unterschiedlichen Werkzeugen gar nicht auftreten k nnen Q Information geht beim Datenaustausch zwischen Werkzeugen nicht verlo ren denn selbst wenn ein Werkzeug nicht alle spezifischen Daten eines anderen versteht bleiben diese Informationen im Repository erhalten Q Die Kontrolle der Datenobjekte erfolgt werkzeug bergreifend auf einheit liche Weise Versionierungsmodell Konfigurationsmodell 7 In der IPSEN Terminologie wird stets von einem Dokumentbegriff ausgegangen der eine aus administrativer Sicht mehr oder weniger nat rliche Zusammenfassung zusammengeh riger Daten darstellt als abstrakter Datentyp modelliert wird und h ufig mit dem Begriff einer physischen Datei zusammenf llt 3 3 Integrationsanforderungen in prozessintegrier
77. Transactions on Software Engi neering 12 7 S 744 751 1986 Fayad M Schmidt D C und Johnson R Hrsg Building Application Frameworks Object Oriented Foundations of Framework Design John Wiley amp Sons 1999 Feiler P und Humphrey W S Software Process Development and Enactment Concepts and Definitions In Proc 2nd Intl Conf on Software Process IEEE Computer Society Press 1993 S 28 39 Fernstr m Ch N rfelt K H und Ohlsson L Software Factory Principles Architecture and Experiments IEEE Software S 36 44 March 1992 Fernstr m Ch und Ohlsson L Integration Needs in Process Enacted Environments In Procs 2nd Intl Conf on the Software Process 1991 S 142 158 Fernstr m Ch PROCESS WEAVER Adding Process Support to UNIX In Procs 2nd Conf on the Software Process Berlin Germany Feb 1993 S 12 26 Fernstr m Ch State Models and Protocols in Process Centered Environments In Proc 8th Intl Software Process Workshop State of the Practice in Process Technology Wadern Germany March 1993 S 72 77 Fielding R Gettys J Mogul J Frystyk H Masinter L Leach P und Berners Lee T Hypertext Transfer Protocol HTTP 1 1 IETF RFC 2616 1999 Finkelstein A Kramer J und Nuseibeh B Hrsg Software Process Modelling and Technology RSP John Wiley amp Sons London 1994 FIPS Integration Definition for Function Modeling IDEFO Tech Report Federal Infor
78. Unternehmen dazu Produktentwicklungszyklen zu verk r zen die Kosten von Produktentwicklung und Produktion zu verringern und die Qualit t der Ergebnisse der Entwicklungsprozesse zu erh hen Gleichzeitig steigt die Komplexit t der zu entwickelnden Systeme mit der Proliferation der techni schen M glichkeiten und der Technikdurchdringung immer gr erer Lebensberei che Allgemein hat sich die Erkenntnis durchsetzt dass die Komplexit t heutiger Systeme nur dann bew ltigt werden kann wenn Analyse und Modellierungst tig keiten die der eigentlichen Systemkonstruktion vorangehen bzw iterativ damit verzahnt werden ein angemessener Stellenwert einger umt wird Beispielsweise ziehen Fehler in der Anforderungsanalyse etwa unvollst ndig erhobene oder falsch verstandene Kundenanforderungen sp ter aufw ndige nderungen nach sich und sind h ufiger Grund f r Kosten und Zeit berschreitungen Um Analyse und Entwurf technischer Systeme effizient durchf hren zu k n nen ist der Einsatz systematischer Methoden unabdingbar Produktseitig geben Me thoden dem Entwickler einen Grundvorrat an Modellierungskonzepten und Struk turierungskonstrukten f r die Systembeschreibung an die Hand die in einer pas senden oft grafischen Notation dargestellt werden Aus Prozesssicht definieren Methoden mehr oder weniger strukturierte Vorgehensweisen f r die zielgerichtete Anwendung der Modellierungskonstrukte Methoden Angesichts der Gr e der e
79. Werkzeugmodellierung automatisch mit passenden Men strukturen Kommando Icons einer Statuszeile und einer Inhaltsregion Zeichenfl che angereicht wird Die Inhaltsregion bietet die Funktionalit t eines einfachen grafischen Editors auf Basis eines Prototyp basierten Entwurfsmusters GVJH95 Durch Registrierung einer Menge von vektorbasierten Grundsymbolen Rechtecke Kreise Rauten Pfeile etc erbt die werkzeugspezifische Benutzeroberfl che einen vordefinierten Satz von Basisope rationen inklusive komplexer Einf geoperationen Verschiebe und Layout Ope rationen ohne dass hierf r zus tzliche Code erforderlich ist Ein einfaches Werk zeug wie der ER Editor kommt daher mit einem Minimum spezifischen GUI Codes aus ca 600 Zeilen Bei komplexeren Werkzeugen die grafische Symbole Operationen und Darstellungsarten ben tigen die nicht vom Framework bereit gestellt werden erh ht sich der Aufwand entsprechend Beispielsweise umfasst das werkzeugspezifische GUI Paket des Ziel Editors der PRIME CREWS Umgebung 37 Da an die Struktur des resultierenden Datenbankschemas au er den beiden oben genannten Attributen keine speziellen Anforderungen gestellt werden k nnen f r die Realisierung und Persistenz des Produktmodells auch automatisierte Generierungstechniken zum Einsatz kommen wie sie von CASE Werkzeugen wie etwa Rational Rose oder Together angeboten werden In diesem Fall w rde der Code des Pakets ER Model automatisch erzeugt un
80. auf einfache Weise in das Rahmenwerk zu integrieren Beim Entwurf ist somit das Spannungsfeld zwischen hoher Flexibilit t bei der Integra tion von heterogenen Sprachen zu Lasten eines geringen Wiederverwendbarkeits grades und der breiten Unterst tzung eines speziellen Kontrollflussparadigmas bei Verzicht auf die Allgemeinheit zu ber cksichtigen 7 5 3 1 Ausf hrungsmodell von Kontextkomponenten Wie in Abschnitt 7 5 2 2 erl utert wird die Ausf hrung eines AK EK oder PK Kontextkomponente von einer Instanz der Klasse EC_Process CC_Process bzw PC_Process gesteuert Damit bergeordnete Dienste des administrativen Interpre terrahmens die sich auf Ausf hrungsinformationen beziehen unabh ngig von der Kontextart und der zugrunde liegenden Prozesssprache realisiert werden k nnen ist eine Vereinheitlichung des Ausf hrungsmodells dieser Klassen erforderlich Beispiele f r Dienste die zustandsbasierte Informationen ben tigen sind Kom ponenten zur Prozessausf hrungskontrolle und berwachung sowie die Proto kollkomponente f r die Prozessspuraufzeichnung Eine einheitliche Steuerung der Prozessausf hrung ist dabei bereits durch die Schnittstelle der Klasse Process f r alle drei Kontextarten gew hrleistet vgl Abb 66 Hier bezieht sich die Verein heitlichung jedoch nicht nur auf die Prozessschnittstelle sondern auch auf die Ausf hrungszust nde eines Prozesses 7 5 GARPEM die generische Prozessmaschinenarchitektur 241
81. aufgabenbezogenen Dialogsteuerung verwirklicht Wie bereits in Abschnitt 2 2 3 diskutiert bieten diese Systeme jedoch keinerlei Anpassbarkeit an Prozess nderungen 3 3 7 Werkzeugunterst tzter Aufruf von Prozessfragmen ten 3 3 7 1 Motivation In Abschnitt 3 3 5 hatten wir bereits darauf hingewiesen dass aus einer nur frag mentarischen Modellierung von Prozessen zwei unterschiedliche Ausf hrungs modi resultieren im proaktiven Modus kontrolliert die Leitdom ne das Geschehen in der Durchf hrungsdom ne w hrend im reaktiven Modus kein definiertes Prozessfragment f r die Unterst tzung des aktuellen Prozesses vorliegt und die Leitdom ne somit inaktiv ist F r den bergang vom reaktiven zum proaktiven Modus der aktuelle Prozess 4 f status in der Durchf hrungsdom ne mit den Eintrittsbedingungen der definierten Ubergang vom reaktiven in den proaktiven Prozessfragmente verglichen werden Da sich gerade in den Werkzeugen der Unterst tzungsmodus aktuelle Prozesszustand manifestiert sollten die Werkzeuge den Benutzer bei der Suche nach anwendbaren Prozessfragmenten aktiv unterst tzen und die aktuell anwendbaren Prozessfragmente in der Benutzeroberfl che zur Auswahl z B ber Men punkte anbieten Im Idealfall sollte es daher f r den Benutzer transparent 3 3 Integrationsanforderungen in prozessintegrierten Umgebungen 103 sein ob er eine werkzeugeigene Funktionalit t aktiviert oder die Ausf hrung eines definierten
82. bereitgestellt wurden Einen Schritt weiter gehen Ans tze zur Werkzeuggenerierung die die semi automatische Erzeugung von Werkzeu gen auf Basis einer formalen semantisch angereicherten Spezifikation der zugrun de liegenden Datenstrukturen und Dienste zum Ziel haben Fr he Beispiele f r Werkzeuggenerierungsans tze sind syntaxgesteuerte Edito ren z B der Cornell Program Synthesizer ReTe81 ReTe88 und die Werkzeuge der Umgebungen Gandalf HaNo86 und Mentor DHKL84 Speziell auf den Einsatz innerhalb einer prozesszentrierten Umgebung ausgerichtet ist die im Rahmen des GOODSTEP Projekts GOOD94 entwickelte Werkzeugspezifikationssprache GTSL Emme95 Emme96 EAMP97 GTSL folgt einem datenbankzentrierten Entwurfsparadigma und legt den Schwerpunkt auf die Generierung von Daten bankschemata Konsistenzchecks und darauf basierenden elementaren Werkzeug diensten Die formale Grundlage stellen projektweite abstrakte Syntaxgraphen f r die zu unterst tzenden Entwurfsdokumente dar die auf ein objektorientiertes Datenmodell abgebildet werden Die Laufzeitumgebung eines GTSL basierten Werkzeugs bietet eine Kommunikationsschnittstelle ber die eine externe Pro zessmaschine die generierten Werkzeugdienste und Konsistenzchecks aufrufen kann GTSL liefert somit L sungen f r die Datenintegration und den feingranulare Aufruf von Werkzeugdiensten Die prozesssensitive Anpassung des Dienstange bots eines Werkzeugs gem der Prozessmodellausf hr
83. berwachung von Prozessen die unter der Kontrolle einer PZEU ablaufen so dass der Projektmanager Prozessab weichungen erkennen kann und gegebenenfalls korrigierende Ma nahmen veran lassen kann Au erdem kann der Projekt Manager durch eine Gesamtsicht auf die aktuell laufenden Prozesse die Kooperation zwischen verschiedenen Entwicklern steuern und Abstimmungsprozesse veranlassen Abb 5 Benutzerschnittstellen innerhalb einer PZEU Modellierungsumgebung Administrations umge bung 38 2 Prozessorientierte Unterstutzungsfunktionen Entwickler Frontend Der technische Entwickler am Arbeitsplatz erh lt Prozessunterst tzung durch eine PZEU ber sein Entwickler Frontend siehe Abb 5 Basierend auf der Ausf h rung eines Prozessmodells und unter Ber cksichtigung von prozessrelevanten Informationen aus der Durchf hrungsdom ne liefert die Leitdom ne der Durch f hrungsdom ne Unterst tzung in Form von passiver Prozessberatung aktiver Prozessanleitung Prozesslenkung oder Prozessautomation siehe Abschnitt 2 1 5 F r die Ausgestaltung des Entwickler Frontends also der Schnittstelle zwischen der Leitdom ne und der Durchf hrungsdom ne wurden in PZEUen und den damit verwandten Workflow Managementsystemen eine Reihe zum Teil sehr unterschiedlicher Interaktionsparadigmen entwickelt Unter einem Interaktionspa radigma verstehen wir hierbei die wesentlichen Metaphern und Konzepte mit deren Hilfe die Prozessunterst tzung an den Benutzer
84. bzw seiner Laufzeitumgebung ist zu einem gro en Teil darauf zur ckzuf hren dass es den Umgang mit Microsofts Antomation Technolo gie f r die Fernsteuerung von komponentenbasierten Applikationen im Vergleich zu anderen Sprachen z B C drastisch vereinfacht und die Komplexit t des zugrunde liegenden Component Object Model COM weitgehend verbirgt Obwohl von Microsoft mittlerweile als vollwertige Sprache f r beliebige Anwendungen propagiert eignet sich Visual Basic besonders f r die Automation und Integration von Aktivit ten innerhalb der Microsoft Office Familie Im Zusammenhang mit Internettechniken und der Programmierung von Web Browsern spielen VB Script f f A VB Script JavaScript Lamp99 eine abgespeckte Version von VBA und Netscapes Pendant JavaScript und Tcl Tk Mint97 eine wichtige Rolle Ein weiterer wichtiger Vertreter der Skriptsprachen um den es in letzter Zeit allerdings etwas still geworden ist ist die Tool Command Language Td Oust94 Die historischen Wurzeln dieser Sprache liegen in dem Wunsch einzelne in der Sprache C geschriebene Programme zu fertigen Applika tionen zusammenfassen zu k nnen Ihre eigentliche Popularit t verdankt die Tcl der mitgelieferten Erweiterung Tk einem grafischen Toolkit zur schnellen und plattform bergreifenden Erstellung von Benutzeroberfl chen Visual Basic Gemeinsam ist allen Skriptsprachen dass sie von den angebotenen Ablauf strukturen herk mmlichen prozedur
85. dar Ein solches Typsystem muss Kompatibilitaten zwischen Bausteintypen ent lang mehrerer Dimensionen ausweisen z B dass ein U eine Spezialisierung von V darstellt oder dass X als Teil einer Dekomposition von Y auftreten kann und eine semantisch reichhaltige Charakterisierung einzelner Bausteintypen erlauben z B dass eine Destillationskolonne als Trenngerat nur dann in Frage kommt wenn sich die Siedepunkte der zu trennenden Stoffe um mehr als 10 C unterscheiden Das Typsystem muss anpassbar und erweiterbar sein da sich das Wissen tiber Bausteintypen und ihre Eigenschaften im standigen Wandel befindet AuBerdem soll der Verfahrenstechniker bei der Definition eigener Bausteintypen unterst tzt werden um deren Wiederverwendung in anderen Anwendungskontexten zu for cieren Benutzerdefinierte Bausteintypen entstehen z B durch Parametrierung generischer Bausteine oder Aggregation aus einfacheren Bausteintypen z B die Hintereinanderschaltung mehrerer Kompressoren und W rmetauscher 8 2 2 3 Realisierung Eine Evaluierung kommerzieller Werkzeuge f r den Flie bildentwurf ergab dass keines der verf gbaren Produkte die beschriebenen anwendungsseitigen Anforde rungen auch nur ann hernd erf llte Infolgedessen avancierte die Existenz offener Schnittstellen die neben der M Prozessintegration auch die Umsetzung der 0 8 Anforderungen erm glichen zum entscheidenden Kriterium bei der Auswahl des zu integrierenden Werkzeugs Die Wahl fiel schl
86. das betreffende Werkzeug weitergelei tet 3 3 Integrationsanforderungen in prozessintegrierten Umgebungen User Interaction Environment Durchf hrungsdom ne Werkzeug 1 Werkzeug 2 SPADE Communication Interface SCI user black transition interface place SLANG Interpreter Process Enactment Environment Durchf hrungsdom ne Ein gravierendes Problem ergibt sich jedoch aus der Tatsache dass die eingesetz ten Werkzeuge der DEC Fuse Umgebung nicht eigens f r den Einsatz in der prozesszentrierten Umgebung konzipiert wurden und bereits eigene Reaktionen auf bestimmte Nachrichten realisieren Wenn Nachrichten sowohl an die Werkzeuge als auch an die Prozessmaschine via SCI geleitet werden besteht die Gefahr dass die in einem Werkzeug einkodierten und die im Prozessmodell vorgesehenen Reaktionen auf eine Nachricht miteinander Aonfligieren Ob und wie diese Kon flikte die eine Auspr gung des so genannten process in the tool Syndroms Mont94 AnGr94 darstellen in SPADE aufgel st werden ist der verf gbaren Literatur leider nicht zu entnehmen Ein entscheidender Unterschied zum Forest Ansatz besteht also darin dass der Message Server nicht direkt um prozessorien tierte Politiken angereichert werden sondern dass die Prozessmaschine mit den Prozessmodell neben dem Message Server gleichberechtigt mit den Werkzeugen angesiedelt ist Die Mediation der Werkzeuginteraktion ist also indirekt und gelingt
87. dass Micro soft Excel ebenso wie die anderen Programme des MS Office Pakets ber seine COM Schnittstelle alle ben tigten APIs offen legt so dass im Prinzip eine hnlich vollst ndige Prozessintegration wie beim nachfolgend beschriebenen Werkzeug Visio m glich gewesen w re Unser Hauptinteresse bei den Prozessintegrationsexperimenten galt Visio das die technische Grundlage f r den IMPROVE Flie bildeditor bildet Dieses Werkzeug nimmt innerhalb des IMPROVE Werkzeugverbunds eine zentrale Stellung ein da der Umgang mit flie bildartigen Abstraktionen einer chemischen Anlage im Mittelpunkt einer Vielzahl verfahrenstechnischer Entwicklungsprozesse steht Eine Analyse dieser Prozesse ergab dass abh ngig vom Arbeitsablauf f r den Benutzer nur ein spezifischer Teil der Visio Funktionalit t relevant ist und au erdem eine Reihe von Prozessfragmenten aus dem Flie bildwerkzeug heraus angesto en werden Aus diesem Grund war f r uns neben der Kontrolle von elementaren Visio Aktionen auch die prozesssensitive Anpassung der Interakti onsm glichkeiten d h die Durchsetzung von Entscheidungskontexten und die Aktivierbarkeit von Plankontexten aus Visio heraus essentiell Auf der Modellierungsebene wurden die zu kontrollierenden Aktionen Pro dukte und Kommandoelemente des Visio basierten Flie bild Editors mit den Konzepten des Werkzeugmetamodells beschrieben Aufbauend auf diesen Defini tionen konnten geeignete Ausf hrungs Entscheidungs
88. den beteiligten Werkzeugdokumenten automatisch oder mit Benutzerinteraktion nachgezogen werden k nnen Die in Lefe95 vorgestellten Integratoren sind auf die Konsistenthaltung von jeweils zwei Dokumenten und somit maximal zwei Dokumenttypen beschr nkt Mit zunch mender Anzahl unterschiedlicher Dokumenttypen steigt somit auch der Bedarf an Integratoren zur Konsistenthaltung der Dokumente untereinander Dies ist mit einem erheblichen Realisierungsaufwand verbunden auch wenn sich generische Teile eines Integrators in einem Rahmenwerk verallgemeinern lassen Nicht un problematisch ist auch die Koordination mehrerer Integratoren bei einem komple xen Geflecht unterschiedlicher Dokumenttypen Die Konsistenthaltung von Da ten ist selbst ein Prozess der projekt und organisationsspezifisch entsprechend unterschiedlicher Strategien und Konsistenzbegriffe ausgestaltet werden sollte Diese Prozesse sind in den Integratoren jedoch als komplexe Kommandos kodiert und k nnen nicht ohne weiteres abge ndert und auf das Zusammenspiel mehrerer Integratoren abgestimmt werden Repository basierter Datenaustausch Bei dieser klassischen schon im urspr nglichen Stoneman Report DoD 80 propagierten Datenintegrationsmethode tauschen die Werkzeuge untereinander und mit der Prozessmaschine gemeinsame Entwurfsdaten ber eine logisch zentrale Datenbank aus siehe Abb 8c die im Kontext von Entwurfsumgebungen meist als Repository bezeichnet wird BeDa94 Bro 94
89. der Entwickler seine vom Projektmanagement zugeteilten Aufgaben unter Verwen dung bestimmter Methoden durchf hrt spielen eine besondere Rolle f r die systematisch methodische Aufgabendurchf hrung auf der Arbeitsplatzebene JaBR99 Die verf gbare Werkzeugfunktionalit t bestimmt im hohen Ma e welche Arbeitsprozesse unterst tzt oder berhaupt durchgef hrt werden k nnen So sind der Erstellung und Pflege gro er Modelle enge Grenzen gesetzt wenn Method Tool Companionship dem Entwickler nicht entsprechend leistungsf hige Werkzeuge zur Verf gung FoN092 Tolv98 stehen Aus diesem Grund muss die am Arbeitsplatz erteilte Prozessunterst tzung f r die zu befolgenden Arbeits und Entscheidungsschritte insbesondere auch auf die zur Durchf hrung der Aufgaben zur Verf gung stehenden Werkzeuge ber ck sichtigen Vergleich Prozessunterst tzung auf Projektmanagement Arbeitsplatzebene und Im Zentrum dieser Arbeit steht die Unterst tzung der Arbeitsplatzebene Um diesen Bereich besser eingrenzen zu k nnen haben wir in diesem Abschnitt die spezifi schen Unterst tzungsfunktionen der Arbeitsplatzebene denjenigen der Projektma nagementebene gegen bergestellt Tab 2 fasst die wesentlichen Unterschiede der Prozessunterst tzung auf Projektmanagement und Arbeitsplatzebene zusammen Gegenstandsbereich der Prozessunterst tzung Projektmanagementebene Arbeitsplatzebene Planung Koordination Kontrolle des Gesamtproze
90. der Verfeinerungen RefinementList kann zum einen leer sein falls f r die V T Pro zessgruppe noch keine Verfeinerung angelegt wurde oder beinhaltet mindestens eine Verfeinerung f r die urspr nglich ausgew hlte VT Prozessgruppe Falls keine Verfeinerung existiert dann kann die VI Prozessgruppe ohne R cksicht auf vorhandene Entscheidungen verfeinert werden Dieser Fall wird durch die linke der beiden rot dargestellten Transitionen in Abb 74 abgedeckt Diese Transition dient ausschlie lich der Kontrollflusssteuerung und ist nicht an eine Kontextkom ponente gebunden Falls jedoch bereits eine Verfeinerung existiert soll der Verfahrensingenieur zun chst alle mit dieser Verfeinerung in Zusammenhang stehenden Zusatzinfor mationen betrachten Dieser Vorgang wird durch den Plankontext PC FBW InspectRelated bjects angeleitet rechte der beiden roten Transitionen welcher zu einer gegebenen Menge von Produkten in diesem Fall die zu verfei nernde V T Prozessgruppe alle abh ngigen Produkte ermittelt und dem Benutzer zur Ansicht und Bearbeitung anbietet 262 8 Anwendungen In beiden F llen wird sofern der Plankontext PC FBW InspectRelatedObjects nicht vom Benutzer abgebrochen wurde mit dem Kontext EC_FBW RefineGroup eine Verfeinerung der urspr nglichen VT Prozessgruppe angelegt Nachdem die Verfeinerung im Flie bildwerkzeug angelegt wurde werden Abh ngigkeiten zwi schen der urspr nglichen VT Proz
91. der Modellierung des Kontroll flusses eines kompositen Plankontexts aus einer erweiterbaren Palette eablierter Sprachen jeweils den Formalismus w hlen kann der f r die Modellierung des aktuell betrachteten Ablaufs am geeignetsten ist und der seinen pers nlichen Vorlieben am n chsten kommt Dabei spielen neben der Frage nach den prinzi piellen Ausdrucksm glichkeiten auch nichtfunktionale Anforderungen wie die Angemessenheit der Darstellung eine wichtige Rolle Beispielsweise lassen sich mit Petrinetz artigen Sprachen parallele Abl ufe und Datenabh ngigkeiten sehr an schaulich modellieren w hrend Konstrukte wie Schleifen nur umst ndlich repr sentiert werden k nnen Aus der Verwendung unterschiedlicher Sprachen zur Kontrollflussspezifika tion von Plankontexten und der potenziell beliebigen Schachtelung von Plankon texten ergibt sich das Problem der Inzeroperabilit t heterogen spezifizierter Prozess fragmente In diesem Kapitel besch ftigen wir uns mit den modellierungsseitigen Interoperabilit tsaspekten und entwickeln einen komponentenbasierten Integrati onsansatz auf Basis des NATURE Prozessmodells Die ausf hrungsseitigen Kon sequenzen zur Laufzeit werden in Kapitel 7 beleuchtet wenn wir ein generisches Prozessmaschinen Rahmenwerk f r die Interpretation heterogen spezifizierter Prozessfragmente vorstellen Der Rest des Kapitels ist wie folgt gegliedert In Abschnitt 6 2 geben wir einen kurzen berblick ber existierende A
92. der Situationsausdruck spezifi ziert wird In diesem Fall ist dies SQL in Kapitel 7 stellen wir eine einfache Situati onssprache vor die ber dem aktuellen Zustand der in einem Werkzeug geladenen Produkten ausgewertet wird 18 Wir ignorieren hier und in der weiteren Diskussion den Intentionsteil eines Kontext da wir eine Intention lediglich durch ihren Bezeichner repr sentieren und keine weitere Substruktur d h eine Implementierung des Intentionsbegriffs voraussetzen 146 6 Interoperabilitat von Prozesssprachen Eingangsschnittstelle der Situations Verhaltens Ausgangsschnittstelle der Abb 27 Kontextkomponente komponente Kontextkomponente Kante Kontextkomponente Struktur einer Kontext aus Verwendersicht p p aus Verwendersicht komponente Rollen bezeichner Produkttyp el ER Entity erd ER Diagram Situations Verhaltens Et Ct ES e2 ER Entity spezifikation spezifikation u Produktteil r ER_Relationship Eingangsschnittstelle der Situationskomponente Ausgangsschnittstelle Eingangsschnittstelle der Situations der Verhaltens komponente komponente Ausgangsschnittstelle der Verhaltenskomponente Ausdruck zur Ermittlung g ltiger Spezifikation der Operationalisierung Produktkonstellationen formuliert in der Kontextkomponente wahlfreier Sprache z B als SQL abh ngig von Kontextkategorie Anfrage SELECT e id FROM ER Entity e WHERE e erd erd AND e id NOT IN 7 s SELECT r from Ei
93. die Operatio nalisierung eines Ausf hrungskontexts vorgesehene Aktion von einem der im Werkzeugmodell modellierten Werkzeuge angeboten wird Sei AK ein im Pro zessmodell definierter Ausf hrungskontext A die mit AK assoziierte Aktion und Wi Wn die im Werkzeugmodell definierten Werkzeugkategorien Bei der Zuweisung eines Ausf hrungskontexts zu einem Werkzeug k nnen dann drei F lle auftreten 0 Automatische Zuweisung Es existiert genau eine Werkzeugkategorie W Wu Wr die die Aktion A anbietet In diesem Fall kann eine auto matische Zuordnung zwischen AK und W erfolgen da keine Wahlfreiheit existiert Q Wahl der Zuordnung Es existieren zwei oder mehr Werkzeugkategorien Wir Wiz Wik lt W1 Wr die die Aktion A anbieten In diesem Fall sollte der Methodeningenieur genau eine Werkzeugkategorie W e Wi W 2 Wiy ausw hlen und mit dem Ausf hrungskontext AK verkn pfen Dies ist erforderlich damit die Prozessmaschine sobald der Ausf hrungs kontext AK zur Ausf hrung ansteht das zust ndige Werkzeug aus dem Umgebungsmodell eindeutig bestimmen kann Mangel an Werkzeugunterst tzung Wenn keine Werkzeugkategorie W die erforderliche Aktion A zur Verf gung stellt ist dies ein Indiz daf r dass der im Prozessmodell definierte Ausf hrungskontext von der aktuell im Werkzeugmodell erfassten Werkzeugfunktionalit t der Entwurfsumge bung nicht unterst tzt wird Als Konsequenz muss eine entsprechende Werkzeu
94. die explizite Verwaltung von Assoziationen zwischen Klas sen bereit ohne diese durch unidirektionale Zeiger realisieren zu m ssen GARP ist eine Klassenbibliothek f r die Laufzeitrepr sentation hierarchisch strukturierter Attributb ume und deren Serialisierung Deserialisierung in eine Zeichenketten Darstellung GARP hnelt von seiner Funktionalit t sehr stark dem Document Object Model DOM f r die Laufzeitdarstellung von XML Daten W3C 98 und wird haupts chlich f r das Marshalling Unmarshalling von Nachrichtenparame tern im Teilsystem MessageInterface verwendet Im Folgenden stellen wir die wichtigsten Pakete des GARPIT Frameworks im Detail vor Wir beschr nken uns dabei auf die generischen Teilsysteme StateMana ger MessageInterface und ContextManager da gerade diese Teilsysteme das wesentliche Unterscheidungsmerkmal unseres Ansatzes von anderen Vorschl gen f r generische Werkzeugarchitekturen z B Emme95 Lefe95 darstellen 30 Die komplette Verkapselung eines nativen GUI Toolkits durch entsprechende Adapterklassen ist in der Regel mit einem sehr hohen Aufwand verbunden der auch durch die dadurch gewonnene Portabilit t meist nicht gerechtfertigt wird Ble 99 Ble 99a Wir haben uns daher bewusst auf die Kaspelung der am h ufigsten ben tigten Oberfl chenelemente Standarddialoge Shapes Contai ner Men system im Paket GenericGUI beschr nkt 31 GARP General Attribute RePresentation 202 U
95. diesem Abschnitt haben wir gezeigt dass der PRIME Ansatz keineswegs auf a priori Integrationsszenarien beschr nkt ist sondern sehr wohl auch bei existieren 234 7 Das PRIME Rahmenwerk den Werkzeugen angewandt werden kann und dort zu einer deutlichen Verbesse rung der Integrations und Prozessunterst tzungsqualit t beitragen kann Wir haben insgesamt sechs API Kategorien identifiziert die ein Werkzeug an bieten muss damit es ber einen Wrapper vollst ndig prozessintegriert werden kann F r den Prozessintegrations Wrapper konnten gro e Teile des GARPIT Frameworks wiederverwendet werden Signifikant erleichtert wurde dies durch die saubere Trennung zwischen dem generischen Interpreterkern und den Anschluss stellen f r die werkzeugspezifischen Funktionalit ten in der GARPIT Architektur Die Anbindung an ein externes Werkzeug erfolgt ber Adapterklassen die zwi schen den Variationspunkten des generischen Prozessintegrations Wrappers und den spezifischen Werkzeug APIs vermitteln Der bei den Integrationsexperimenten erreichte Grad der Prozessintegration differiert zwischen den betrachteten Werkzeugen Aspen Plus Microsoft Excel und Visio Dies haben wir zum einen mit der unterschiedlichen Offenheit der Werk zeuge begr ndet und zum anderen mit den spezifischen Rollen die die Werkzeuge in den zu unterst tzenden Prozessen spielen W hrend sich f r Microsoft Excel eine Prozessintegration auf der Ebene von Ausf hrungskontexten al
96. dynamisch konfigurierbar anderbar Assistenten 6 7 u Interface Agenten 2 2 4 Prozesszentrierte Umgebungen Die bislang betrachteten Prozessunterst tzungsmechanismen kommen mehr oder weniger ausgepr gt auch in solchen Entwicklungsumgebungen zum Einsatz die nicht explizit eine prozesszentrierte Unterst tzungsphilosophie verfolgen Seit Mitte der 80er Jahre ist jedoch bei der rechnerbasierten Unterst tzung von Model lierungs und Entwurfst tigkeiten ein Trend weg von cher produktbasierten CA SE Umgebungen hin zu prozesszentrierten Umgebungen zu beobachten FuGh94 DeKW99 FiKN94 Poh 99 2 2 4 1 Prozessmodellierung Die Grundidee prozesszentrierter Entwicklungsumgebungen besteht darin dass der Integration von Prozessaspekten in eine Entwurfsumgebung eine geeignete Konzeptualisierung der zu unterst tzenden Prozesse vorangehen muss In diesem 34 2 Prozessorientierte Unterstutzungsfunktionen Zusammenhang hat sich in den letzten etwa 15 Jahren mit der Software Prozessmodellierung eines der aktivsten Teilgebiete innerhalb der Softwaretechnik etabliert Das zentrales Anliegen dieses Gebiets besteht darin Prozesse mittels Modellierung als explizite Objekte einer systematischen Erforschung und rechnergest tzten Behandlung zug nglich zu machen ABGM93 FiKN94 FuWo96 McCH95 Lonc94a AmCF97 Unter einem Prozessmodell versteht man eine abstrakte Repr sentation einer Familie von Prozessen unter Verwe
97. eine Reihe von exogenen Ereignissen die durch asynchrone Nachrichten von au en d h von ande ren Werkzeugen oder von der Prozessmaschine generiert werden O Transitionen 19 und 21 ExternalECCCRequest Diese Zustands berg nge werden ausgel st wenn ein fremdes Werkzeug einen werkzeugeigenen Kontext c mittels einer ExternalECCCRequest c Nachricht anfordert Handelt es sich beim Kontext c um einen Ausf h rungskontext geht das Werkzeug in den Zustand EC Active on External Request ber Transition 19 und f hrt die mit dem A c assoziierte Aktion durch Nach der Beendigung werden die Resultate der Aktion an das aufrufende Werkzeuge mit einer ExternalECCCResponse Nachricht zur ckgeschickt und das Werkzeug geht in den Zustand Standard Context Active ber Transition 20 Falls c ein Entscheidungskontext ist geht das Werkzeug in den Zustand CC Active on External Request ber Transition 21 Hier werden dann 186 7 Das PRIME Rahmenwerk die Interaktionsm glichkeiten des Benutzers auf die f r c definierten Al ternativen angepasst Nach Auswahl eines alternativen Kontexts a durch den Benutzer geht das Werkzeug je nach Kontextkategorie von ain den Zustand EC Active oder CC Active ber Transition 22 oder 23 In bei den F llen wird die ausgew hlte Alternative dem aufrufenden Werkzeug mithilfe einer ExternalECCCResponse Nachricht bermittelt Q Transition 10 LockR
98. einer prozessintegrierten Umgebung free und angekitete Prozessdurchf hrung In der freien Prozessdurchf hrung aktiviert der Benutzer ohne Einschr nkung in seinen Werkzeugen Ausf hrungs und Entscheidungs kontexte Die Prozessmaschine ist inaktiv d h es findet keine Plankontext Aus 7 2 Interaktionsprotokoll zwischen den Prozessdomanen 183 f hrung statt In Abb 43 wird dies durch den Tool Zustand Unrestric ted Process Performance und den ProcessEngine Zustand Pro cess Enactment Inactive repr sentiert Die Benutzer gesteuerte Aktivierung eines Plankontexts in einem Werkzeug markiert den bergang in die angeleitete Prozessdurchf hrung Guided Process Performance Dieser Zustands bergang wird der Leitdom ne durch eine GuidanceRequest Nachricht signalisiert wo durch die Prozessmaschine die Interpretation des aktivierten Plankontexts startet Process Enactment Active W hrend der Plankontext Ausf hrung kollaborieren Werkzeuge und Prozessmaschine ber ContextRequest ContextResponse Nachrichtenpaare miteinander Die Prozessmaschine kehrt nach Beendigung der Plankontext Ausf hrung in den Zustand Process Enactment Inactive zur ck und gibt dies durch eine EndOfEnactment Nachricht bekannt die bei den Werk zeugen wiederum einen Zustands bergang in den Zustand Unrestric ted Process Performance ausl st Tool gt Abb 43 Unrestricted Process Performance Kopplung der Zust
99. erwarteten R ck meldungen an die Leitdom ne O Werkzeugunterst tzter Aufruf von Prozessfragmenten O Dynamische Anpassung der in den Werkzeugen zugreifbaren Objekte und Dienste gem Prozessmodell und aktuellem Prozesszustand Die Metamodelle f r die Prozess und Werkzeugmodellierung werden in Kapitel 5 vorgestellt O Flexible Ablaufmodellierung Prozessfragmente k nnen in PRIME ausgehend von elementaren Werk zeugdiensten zu komplexen kontextabhangigen Ablaufpl nen aggregiert werden Je nach Modellierungsanforderungen sind unterschiedliche For malismen zur Kontrollflussspezifikation innerhalb eines Teilfragments be sonders geeignet z B Petrinetze oder endliche Automaten In Kapitel 6 diskutieren wir ein Konzept f r die modellierungsseitige Interoperabilit t zwischen verschiedensprachlich spezifizierten Prozessfragmenten das auf dem Prinzip der Schnittstellentransformation in komponentenbasierten Ans tzen basiert 108 4 berblick ber den L sungsansatz O Integrierte Frameworks f r Leit und Durchf hrungsdom ne Basierend auf dem integrierten Umgebungsmodell entwickeln wir in Kapi tel 7 generische Architekturen f r prozessintegrierte Werkzeuge und Pro zessmaschinen Realisiert werden beide Architekturen in Form objektori entierter Implementierungs Frameworks die als Kernkomponenten Inter preter f r die werkzeug bzw prozessrelevanten Anteile des Umgebungs modells beinhalten Das dynamische Zusammenspiel zw
100. eschr nkung der Spezifikation des s rukturellen Situationsaufbaus auf der Ebene von Produkttypen Situationsspezifikation Insbesondere ist keine Formulierung von zus tzlichen Bedingungen unter Ver auf strukturellen Aufbau wendung von Attributen und Methoden des zugrunde liegenden Produktmodells m glich Diese Beschr nkung hat im Wesentlichen den folgenden Grund Der Zugriff auf Attribute und Methoden des zugrunde liegenden Produktmodells w rde naheliegenderweise ber die f r diesen Zweck vorgesehene objektorientier te Zugriffsschicht des werkzeugspezifischen Produktmodell T Model erfolgen In diesem Fall m sste der ContextMatcher jedoch die spezifischen Schnittstellen der T Model Klassen kennen um bei der Situationsauswertung auf die entsprechenden Attribute und Methoden zugreifen zu k nnen Bei der von uns gew hlten Imple mentierungssprache C w rde dies in einem statischen Bezug zwischen dem ContextMatcher und den T Model Klassen resultieren Dies w rde jedoch mit unserer Intention den ContextMatcher als generische Framework Komponente zu realisieren konfligieren Au erdem w rde jede neue Situationsspezifikation die Generierung oder manuelle Implementierung und Rekompilierung entsprechen den Auswertungscodes nach sich ziehen was im Widerspruch zur einfachen An passbarkeit an neue Prozessdefinitionen steht Ein Ausweg k nnte darin bestehen in einer generischen Auswertungskompo Dynamische Bindung nente Attribut und Methode
101. f r v llig neue Prozesse definiert werden kann Entscheidend ist also dass nicht nur eine Auswahl und Konkretisierung innerhalb einer Menge vordefinierter Prozesse m glich ist sondern dass die Pro zessunterst tzung insbesondere erweiterbar ist nderbarkeit und Erweiterbarkeit Zusammenfassend sollte ein Prozessunterst tzungsansatz also Mechanismen zur Verf gung stellen mit denen ohne unvertretbar hohen Aufwand die Prozess unterst tzung an organisations und projektspezifische Besonderheiten und an Prozessverbesserungen die sich im Laufe der Zeit ergeben angepasst werden k nnen Angesichts der immer noch mangelnden Ausreifung von Softwareent ee M wicklungsprozessen laufen inflexible Prozessunterst tzungsans tze Gefahr das heute par a Experimentieren mit neuen Prozessen prohibitiv teuer zu machen und so langfris tig in Hinblick auf die kontinuierliche Prozessverbesserung kontraproduktiv zu wirken MiSc92 Dene93 Allgemein wird jedoch beklagt dass kommerzielle CASE Umgebungen zu starre Prozessvorgaben machen und wenig Spielraum f r 2 1 Ein Klassifikationsmodell fur Prozessunterstutzungsfunktionen 23 Anpassungen und Erweiterungen lassen Dene93 JaHu98 AnGr94 EmFi96 Die Hersteller von CASE Umgebungen orientieren sich haufig eng an den Vorgaben popul rer Methodenhandb cher z B Rational Rose f r UML JaBR99 BoJR99 und kodieren diese fest in ihre Werkzeuge Anpassungen an organisations und projektspezifische Bed
102. finden Die Arbeiten an PRIME PROMENADE bzw PRIME TECHMOD erfolgten aus organisatorischen Gr nden innerhalb eines eigenen Entwicklungs zweigs unabh ngig von der weiter unten beschriebenen Weiterentwicklung des PRIME Frameworks Eine Zusammenf hrung dieses Entwicklungsstrangs mit der Version 2 0 des PRIME Frameworks siehe unten steht zurzeit noch aus Weiter voran getrieben wurde die Weiterentwicklung des PRIME Frameworks im Rahmen des interdisziplin ren Sonderforschungsbereichs IMPROVE an der RWTH Aachen in dem Informatiker Verfahrenstechnik und Kunststofftechnik Ingenieure seit 1997 an einer umfassenden Unterst tzungsumgebung f r den verfahrenstechnischen Entwurf arbeiten Wesentliche Neuerungen der Version 2 0 des PRIME Frameworks sind das auf der generischen Werkzeugarchitektur basie rende Integrationskonzept f r die Einbindung von Fremdwerkzeugen vgl Abschnitt 7 4 die Integration und Interoperabilit t von Prozesssprachen zur Plankontextde finition gem dem in Kapitel 6 vorgestellten Sprachintegrationsansatz sowie eine zentralisierte Erfassung und Visualisierung von Prozessspuren Im Rahmen der Kooperation mit anderen Projektpartnern wurde das PRIME Framework dar ber hinaus mit einer Reihe von zumeist CORBA basierten Schnittstellen zu externen Komponenten versehen Auf Basis des PRIME 2 0 Frameworks wurde die PRI ME IMPROVE Umgebung entwickelt die wir im Folgenden im Detail vorstellen werden 8 2 PRIME IMPROVE 8 2
103. hrt in der Werkzeugtabelle Buch dar ber von welcher Werkzeuginstanz der urspr ngliche GuidanceRequest stammt Im Beispiel aus Abb 49 w rde diese Adressierung zur Werkzeug instanz w aufgel st werden Diese Adressierungsart wird h ufig dann be nutzt wenn ein komplexer aus mehreren Schritten bestehender werkzeug interner Vorgang mittels eines Plankontexts beschrieben wird und durch die Prozessmaschine koordiniert werden soll 28 Ein Beispiel f r eine solche Modellierungssituation ist der Plankontext ReviseDecision der die Revision einer Entscheidung im Entscheidungseditor anleitet Dabei wird in der einen Entschei dungseditor Instanz das urspr ngliche Entscheidungsdokument angezeigt und in der anderen die Revision der Entscheidung durchgef hrt Im Zuge dieses Vorgang kann der Benutzer Positionen und Argumente der alten Entscheidung bernehmen und in das neue Entscheidungsdokument einf gen Hierzu muss die Prozessmaschine gezielt mit beiden Entscheidungseditor Instanzen interagieren Abb 49 Weiterleitung einer ContextRequest Nach richt Logische Adressierung von Werkzeuginstanzen 7 Das PRIME Rahmenwerk 194 0 newTool bei dieser Adressierungsart soll der Kommunikationsmanager grunds tzlich eine neue Werkzeuginstanz der entsprechende Werkzeugka tegorie starten und die ContextRequest Nachricht an die gerade gestar tete Instanz weiterleiten Hierbei ist jedoch zu beachten dass einige Werk zeugkategorien der
104. in der Durchf hrungsdo m ne kommuniziert wird Task oder Agenda Manager stellen in den meisten PZEUen und Workflow Managementsystemen die prim re Schnittstelle zwischen Leit und Durchf hrungsdom ne dar z B in SPADE BaDF96 HP Synervision DGSZ94 Lew DGSZ94 Dynamite HJKW96 HeKW97 Ein Taskma nager verwaltet eine Liste von Aufgaben die gema dem aktuellen Pro zesszustand und der Prozessdefinition fur einen bestimmten Entwickler zut Bearbeitung anstehen Diese Schnittstelle vermittelt dem Benutzer in der Durchf hrungsdom ne somit eine aktivit tsorientierte Sicht auf den f r ihn aktuell relevanten Teil des Entwicklungsprozesses Q Arbeitskontexte Im Gegensatz dazu stellen einige PZEUen die Rolle von Dokumenten oder Arbeitsordnern Folder st rker in den Vordergrund Zum Beispiel basieren die PZEUen Merlin JPSW94 und ProSyt Cug098 auf dem Begriff des Arbeitskontexts Im Fall von Merlin werden Arbeits kontexte in der grafischen Benutzeroberfl che der PZEU als ein Netz von Dokumenten und Abh ngigkeiten zwischen Dokumenten dargestellt Jedes Dokument ist mit einem Men assoziiert das eine Liste von Aktionen an bietet die auf dem ausgew hlten Dokument aufgerufen werden k nnen Q Visualisierung von Regelmengen In der regelbasierten PZEU Marvel BaKa91 wird die Benutzerschnittstelle zur Leitdom ne durch eine Visua lisierung von Benutzer aktivierbaren Rege n realisiert Die Aktivierung einer Regel kann
105. ist 6 2 2 2 APEL Die APEL Architektur f r foderierte prozessbasierte Systeme DaEA98 EsBa98 EsCB98 EsDa96 basiert u a auf den mit ProcessWall gemachten Erfahrung verfolgt aber eine etwas andere Zielrichtung Im Gegensatz zu den zuvor erl uter ten Modellen die auf die Kompatibilit t des Dienstangebots unterschiedlicher prozessbasierter Unterst tzungsdienste ausgerichtet ist sollen in der APEL Ar chitektur mehrere existierende PZEUen mit einem komplement ren Dienstange bot zu einer nach au en hin einheitlich erscheinenden PZEU zusammengef hrt werden Diese virtuelle PZEU bietet dann Dienste z B Arbeitsplatzverwaltungs Benachrichtigungs und Prozess berwachungsdienste an die nicht Teil einer jeden PZEU sind Die einzelnen Dienste werden durch ein explizites Interopera bilit tsmodell zu einem homogenen Dienstangebot zusammengef hrt so dass sich die Dienstausf hrung der virtuellen PZEU auf diese Dienste st tzen kann 6 2 Interoperabilitat in prozessbasierten Systemen 139 6 2 3 Prozesskomponenten Die Abhangigkeit der in Abschnitt 6 2 1 vorgestellten Prozessaustauschformate von Transformationsbeziehungen zwischen Prozesssprachen kann durch Kompo nentenans tze berwunden werden die ber Schnittstellen die interne Ablauflogik eines Prozessfragments und den daf r verwendeten Implementierungsformalismus kapseln Bei der Verwendung eines Prozessfragments als Subkomponente eines anderen Fragments muss nur noch die Schni
106. kontextbasierte Modellierung kreativer Prozesse um Konzepte zur feingranularen Werkzeugmodellierung Mit hilfe anpassbarer Querbez ge zwischen Prozess und Werkzeugmodell wird ein organisations und projektspezifisches Umgebungsmodell konfiguriert das die Aus wirkungen von Prozessen auf das Werkzeugverhalten kl rt und die Grundlage f r interpretative Anpassbarkeit darstellt Das von uns verwendete kontextbasierte Rahmenprozessmodell l sst Aspekte der pr skriptiven Ablaufsteuerung noch bewusst offen Kapitel 6 beschreibt einen Ansatz f r die Einbettung existierender Ablaufformalismen in das Rahmenpro zessmodell Insbesondere erm glicht der Ansatz die Interoperabilitat kompositer verschiedensprachlich definierter Prozessfragmente Umsetzung Framework f r prozessintegrierte Umgebungen Die effiziente Entwicklung prozessintegrierter Umgebungen ist Gegenstand von Kapitel 7 Zur Umsetzung des integrierten Werkzeug und Prozessmodellierungs konzepts haben wir einen Framework basierten Entwurfsansatz gew hlt bei dem gro e Teile einer prozessintegrierten Umgebung in Form eines vorgefertigten leicht erweiterbaren Softwareger stes vorliegen Ziel dieser Vorgehensweise ist insbesondere dass sich der Umgebungsentwickler nicht mehr um die schwierige architekturelle und technische Integration zwischen der Prozessmodellausf hrung und den Werkzeugen zu k mmern braucht sondern nur noch das Framework an den daf r vorgesehenen Stellen um spezifi
107. m glichen Bindungen zwischen sprachneutralen Schnittstellenkonzepten und sprachspezifischen Implementierungskonstrukten werden einerseits ber ein gemeinsames Metametamodell und andererseits ber ein explizites Bindungsme tamodell festgelegt Mithilfe von O Telos Integrit tsbedingungen werden weitere Eigenschaften einer korrekten Bindung zwischen Schnittstellendefinitionen und sprachspezifischen Konstrukten auf der Instanzebene zugesichert Formaler Ansatz 6 3 1 Prozesskomponenten Wie bereits eingangs dieses Kapitels dargestellt besteht ein Kontext als Abstrak tion eines Prozessfragments aus drei unterschiedlichen Komponenten einer In tentionskomponente einer Situationskomponente und einer Verhaltenskompo nente In dieser Arbeit bezeichnen wir Situationskomponenten Intentionskompo nenten Verhaltenskomponenten und daraus aggregierte Kontextkomponenten verallgemeinernd als Prozesskomponenten Dabei sind die Intentionskomponente sowie die Verhaltenskomponente von Ausf hrungs und Entscheidungskontexten durch das Umgebungsmetamodell f r eine Operationalisierung bereits vollst ndig spezifiziert w hrend die Spezifikation von Situationskomponenten sowie von Abl ufen innerhalb von Plankontexten in einer spezifischen Sprache erfolgen kann und durch neutrale Schnittstellen zu kapseln ist Abb 27 illustriert welche Anteile einer Prozesskomponente der Schnittstel lenbeschreibung bzw der Implementierungsdefinition zuzurechnen sind Eine
108. mation Processing Standards Publication 183 FIPS 183 1993 FIPS Integration Definition for Function Modeling IDEF1X Tech Report Federal Information Processing Standards Publication 184 FIPS 184 1993 Flanagan D Java in a Nutshell O Reilly 2000 Fowler G Korn D und Rao H n DFS The Multiple Dimensional File System In Tichy W Hrsg Trends in Software Volume 2 John Wiley amp Sons Chichester UK 1994 S 135 154 Forte G und Norman R J A Self Assessment by the Software Engineering Community Communications of the ACM 35 4 S 28 32 1992 Fowler G In Process Inspections of Workproducts at AT T AT amp T Technical Journal 65 2 S 102 112 1986 Frolund S und Agha G Coordinating Distributed Objects MIT Press Cambridge MA 1996 Frankel B The Too Talk Service Tech Report Sun Microsystems Inc Mountain View California 1991 Frolund S A Language for Multi Object Coordination In Proc of 7th European Conference on Object Oriented Programming ECOOP 93 Springer Verlag Ber lin Heidelberg LNCS 707 1993 S 346 360 Fromme B und Walker J An Open Architecture for Tool and Process Integration In Proc 6th Software Engineering Environments Conference SEE 93 Reading UK IEEE CS Press 1993 S 50 62 Freedman D F und Weinberg G M Handbook of Walkthroughs Inspections and Technical Reviews Evaluating Programs Projects and Products Dorset House Publishing N
109. muss gelten Si P1 pel ist eine Liste von Produktinstanzen mit Typ p lt Ti J k und min lt k lt max Q wenn der korrespondierende Situationsteil r von der Form ri list min max value V ist muss gelten Si Vz Vs ist eine Liste von Werten mit Zyp v Vi J 1 k und min lt k lt max 7 3 GARPIT ein Framework f r prozessintegrierte Werkzeuge 215 Der nachfolgend skizzierte Matching Algorithmus erh lt als Eingabe einen Situati onstypen S und eine Menge P von aktivierten Produktinstanzen Der Algorithmus ermittelt ob S gilt und gibt im Falle eines erfolgreichen Matchings eine g ltige Situationsinstanz s aus Wir betrachten dabei nur solche Situationstypen deren s mtliche m Situationsteile Listen von Produkttypen referenzieren die also von der folgender Form sind situation S with r list min max T Fm list Minm mMaxm Im end Dies ist keine Beschr nkung der Allgemeinheit da zum einen ohnehin nur gegen ber einer Menge in der Benutzeroberfl che aktivierter Produktinstanzen abgegli chen wird so dass Wert basierte Situationsteile z B 7 value integer durch den Situations Matcher nicht gebunden werden brauchen Zum anderen kann ein Produkt basierter Situationsteil als Spezialfall eines Listen basierten Situationsteils aufgefasst werden bei dem die min und max Kardinalit t jeweils auf 1 gesetzt ist d h folgende Situationsspezifikationen S und
110. nicht in den Produktiv betrieb bei British Airways bernommen Als Hauptgrund wurde angef hrt dass der Austausch der bisherigen Umgebung durch die neue Umgebung eine zu radi kale Umstellung f r die Entwickler bedeutet hatte die nicht auf die Benutzerober fl che und den Funktionsumfang der ihnen vertrauten Werkzeuge verzichten wollten Derartige Motivationen stehen hinter einer Reihe von a posteriori Integ rationsans tzen wie sie bei den prozesszentrierten Umgebungen Provence BaKr93 Bakr95 Marvel Oz Barg92 BeKa98 mit den Werkzeugintegrationsprotokollen SEL und MTP VaKa96 oder auch den ingenieurwissenschaftlichen Integrations projekten IMPROVE NaWe99 verfolgt werden Ungeachtet dieser Diskussion befassen wir uns in dieser Arbeit dennoch zu n chst mit der a priori Integration von Werkzeugen Mit dem Ziel des wissen schaftlichen Erkenntnisgewinns geht es uns um die Charakterisierung der Zielvor stellung einet idealtypischen Prozessintegration von Werkzeugen die ber den bei heute existierenden Werkzeugen und Integrationsmethoden erreichbaren Integra tionsgrad hinausreicht Wir besch ftigen uns mit dieser Fragestellung jedoch nicht nur auf der konzeptionellen Ebene Um die prinzipielle Umsetzbarkeit dieser Ziele zu demonstrieren entwickeln wir einen Ansatz der durch explizite Prozess und Werkzeugmodelle und eine konkrete Architektur f r prozessintegrierte Werkzeuge gekennzeichnet ist Ein wesentlicher Beitrag besteht insbe
111. nnen Eventadapter zwischengeschaltet werden die als Filter Verteiler und Zwi Eventadapter schenspeicher dienen und somit eine Rolle hnlich der eines Message Servers in Message Broadcasting Architekturen bernehmen Die Eventadapter m ssen jedoch mit Unterst tzung durch eine entsprechende Entwicklungsumgebung z B durch Sun s JavaStudio explizit ausprogrammiert werden Zudem fehlt der Java Beans Architektur eine offizielle Verteilungsm glichkeit d h JavaBeans k nnen nur lokal innerhalb einer virtuellen Java Maschine kommunizieren Grif98 JavaBeans JEDI ist eine weitere Java basierte Infrastruktur zur Ereignisverteilung die in JEDI ESF Software Bus nerhalb der prozesszentrierten Umgebung OPSS eingesetzt wird CuDF98 Der und Polylith Software Bus des Eureka Software Factory Projekts ESF FeNO92 f llt ebenfalls in die Kategorie der Message Broadcasting Architekturen wobei hier als Besonder heit in Anlehnung an das Model View Controller Paradigma von Smalltalk Gold84 eine strenge Trennung zwischen so genannten Dienstkomponenten service components und Interaktionskomponenten user interaction components propa giert wird Als weiteres System macht Po ith Purt94 Gebrauch von der Metapher eines Software Busses in den Software Komponenten in Analogie zu Hardware Komponenten nach Bedarf hineingesteckt und wieder herausgenommen werden k nnen Auch in CORBA wurde als Teil der so genannten Common Object Services E
112. souscssosssoosesonssssnnnsnsnnssnnnsssnnnnssnnnsnnnnene 25 2 2 1 Methoden und Projekthandb cher sensneenneennnennennnnn 26 22 2 Hilfesysteme 2 2230 ok Ea es nn a a a a a 27 2 2 3 Assistenten usa da ran spe eae bates a dad ted getan 30 2 2 4 Prozesszentrierte Umgebungen uunccneensseseenneenneesnnennneennnennenn nennen 33 2 2 4 1 Prozessmodellierung sonen tinnarona aeia a nn enne 33 2 2 4 2 _ Konzeptueller Aufbau prozesszentrierter Entwicklungsumgebungen 34 2 2 4 3 Schnittstellen einer PZEU sennsensensenssesennensnenne 36 2 3 Ba Zit ss dvscessusssacseussnsvassdsvonseens sseuas dassesauntenosss cevsewkesasestessesscndncssacnsscaseteensedacesecs 40 2 3 1 Vergleich der Prozessunterst tzungsans tze eenenenenenee 41 2 3 2 Einordnung prozessintegrierter Werkzeuge 42 3 INTEGRATIONSANSATZE cscssceccssessesesscseeseetseeseeseeateanseeseesteatenees 47 3 1 Perspektiven der Werkzeuginte gration sssccccsscssccessssecscseseeseese 47 3 1 1 Integration als Informationsmanagement esenenensensessensensennn 48 3 1 2 Integration als eine Menge von orthogonalen Dimensionen 49 3 1 3 Integration im Spannungsfeld von Basismechanismen und Prozessen 49 3 14 Raritan tanken ENE E E E E 51 3 2 Integrationsvoraussetzungen e ssessoessoosesoossoossoossoossooesoossoosssosssosssosssosssoe 52 3 3 Integrationsanforderungen in prozessintegr
113. the 13th International Conference on the Entity Relationship Approach ER 94 Manchester UK Springer Verlag LNCS 881 1994 S 46 63 Donzeau Gouge V Huet G Kahn G und Lang B Programming Environments Based on Structure Editors The Mentor Experience In Barstow D R Shrobe H E und Sandewall E Hrsg Interactive Programming Environments 1984 S 128 1984 Damm Ch H Hansen K M Thomsen M und Tyrsted M Too Integration Experiences and Issues in Using XMI and Component Technology In Proceedings of the TOOLS Europe 2000 Conference Mont Saint Michel St Malo France 2000 S 94 107 Dittrich K und Gatziu S Aktive Datenbanken dpunkt Verlag 2000 Dourish P und Bellotti V Awareness and Coordination in Shared Workspaces In Proceeding of the Conference on Computer Supported Cooperative Work CSCW 92 Toronto Canada ACM Press 1992 S 107 114 US Department of Defense DoD Requirements for Ada Programming Support Environ ments STONEMAN Repott U S Department of Defense High Order Language Working Group AD A100 404 1980 US Department of Defense DoD 2176A Military Standard Defense System Software Development U S Department of Defense 1988 Dowson M und Fernstr m Ch Towards Requirements for Enactment Mechanisms In Proc 3rd Europ Workshop on Software Process Technology Villard de Lans France LNCS 772 Feb 1994 S 90 106 D mges R Pohl K Jarke M Lohman
114. und Plankontexte defi niert werden Der generische Prozessintegrations Wrapper wurde um spezialisierte Adapter klassen in den Paketen ActionAdapter und UIAdapter angereichert die sich auf die von Visio bereitgestellten COM Schnittstellen abst tzen Bei der ansonsten un komplizierten Implementierung stie en wir auf eine Reihe von Detailproblemen die wir hier kurz beschreiben um die typischen Fu angeln einer a posteriori Integration zu illustrieren Jedes Visio Kommando kann potenziell in 14 verschiedenen Men s bzw Icon Leisten auftauchen die folglich alle vom Prozessintegrations Wrap per kontrolliert werden m ssen Dadurch wird der Adapter zwischen der entsprechenden Visio API und der IntentionTable aufgebl ht und schwe rer wartbar O In Visio k nnen Zeichenelemente mittels Drag amp Drop von einer Vorlage auf die Zeichenfl che gezogen und dort eingef gt werden Dieser Vorgang entspricht in der PRIME Terminologie der Aktivierung eines Kontexts Auswahl des Zeichenelements mit impliziter Intention Create und leerer Situation und der anschlie enden Durchf hrung eines 38 Die Erweiterung von Visio um verfahrenstechnische Funktionalit ten wird in Kapitel 8 detailliert beschrieben 7 4 Integration existierender Werkzeuge 233 Ausf hrungskontexts Einf gen des Objekts in die Zeichenfl che In Visio ist dieser Vorgang aus Sicht des Wrappers atomar d h der Wrapper wird erst nach dem
115. von Plankontexten W hrend der Plankontextinterpretation fordert die Pro zessmaschine die Ausf hrung von Ausf hrungskontexten und Entscheidungs kontexten von den Werkzeugen an Der Kommunikationsmechanismus nutzt f r die korrekte Verteilung der Kontextanforderungsnachrichten an die Werkzeuge die im Umgebungmodell definierte Zuordnung zwischen Ausf hrungs Entscheidungskontexten und Werkzeugkategorien Die Werkzeuge rufen bei der Anforderung eines Ausf hrungskontexts die im Umgebungsmodell festgelegte Aktion auf bzw passen bei der Anforderung eines Entscheidungskontexts ihre Benutzeroberfl che entsprechend an Insgesamt l sst sich der Beitrag des Modells zu den Kapitel 3 aufgestellten An forderungen an eine Integration der Prozessdom nen wie folgt zusammenfassen Q Ai Datenintegration Die Datenintegration zwischen den Prozessdo m nen wird durch ein gemeinsames Produktmodell gew hrleistet Die Konsistenzbedingungen AK2 und AK3 stellen den Zusammenhang her zwischen den im Prozessmodell als Situationen definierten Pro duktkonstellationen und den input output Parametern der von den Werkzeugen bereitgestellten Aktionen Q A2 Prozessmediierte Werkzeuginteraktionen Das Wissen ber werk zeug bergreifende Abl ufe wird innerhalb des Prozessmodells durch das Konzept des Plankontexts repr sentiert Spezifische Arbeitsmodi Bera tungsdienste der Werkzeuge werden als Entscheidungskontexte model liert Wichtig ist dass die in einem
116. von Prozesssprachen Analog zu komponentenorientierten Ans tzen aus dem programmiersprachlichen Bereich z B CORBA COM DCE oder SLI weist unser Ansatz zur Interopera bilitat verschiedensprachlicher Prozesskomponenten somit drei wesentliche Cha rakteristika auf Q Es existiert eine strikte Trennung zwischen der Schnittstelle einer Prozess komponente und ihrer Implementierung 0 W hrend die Implementierung einer Prozesskomponente in einer poten ziell beliebigen daf r geeigneten Sprache erfolgt liegen f r alle Prozess komponenten Schnittstellenbeschreibungen in einem einheitlichen sprachneutralen Format vor Q Prozessfragmentkomponenten werden in einer Komponentensammlung abgelegt Dort k nnen sie ber ihre neutrale Schnittstellenbeschreibung aufgefunden werden und in anderen Prozesskomponenten wiederverwen det werden In diesem Abschnitt befassen wir uns mit der Separation von Schnittstellen und Implementierungsaspekten und entwickeln ein Metamodell zur neutralen Schnitt stellenbeschreibung von Prozesskomponenten das die Grundlage eines Kompo nenten Repositories bildet In Abschnitt 6 4 betrachten wir die Transformation und Bindung der Schnittstellen von Prozesskomponenten in spezifischen Pro zessmodellierungssprachen Formal gehen wir dabei so vor dass wir zun chst Metamodelle zur Schnittstellenbeschreibung und f r spezifische Prozessmodel lierungssprachen in Form von Klassenmodellen spezifizieren Die prinzipiell
117. von au en immer noch zuge griffen werden Ausf hrungsmodell von PK Komponenten Die erl uterten Zust nde legen ein bergeordnetes Ausf hrungsmodell von so wohl AK EK als auch PK Prozessen fest Mit der Verfeinerung der Zust nde wird das Ausf hrungsmodell an die drei Prozesstypen angepasst Bei PK Prozes sen findet die Interpretation eines Fragmentes im Zustand running statt dessen Verfeinerung in Abb 68 rechts dargestellt ist und im Folgenden erl utert wird Evaluating Situation Situation valid Verfeinerter Zustand running f r PK Prozesse running Deducing finishedi caller terminated thi Activities done finished caller terminated this a commited ActivitiesDeduced Suspended A Executi ng allProcessesTerminated A e fo run new EC CC PC Subprocess 7 do commitStep not commited terminated Subprocess Handling Aborted Acaller terminated thil do handleError lt error Der Interpretationsvorgang eines Fragmentes erfolgt schrittweise und ist in drei Phasen eingeteilt die durch die Zust nde DeducingActivities ExecutingActivi ties und CommitingStep gekennzeichnet sind Innerhalb eines fehlerfreien Inter pretationsschrittes werden alle drei Zust nde nacheinander durchlaufen Beim Eintritt in den Zustand running ist das Fragment compositeActivity bereits geladen und initial
118. von den Klassen Process und Factory sowie deren Spezialisierungen abgedeckt siehe Abb 66 Die Klasse Factory ist eine Fabrik f r die einzelnen Sprachelemente des In terpreterrahmenwerkes und folgt dem Fabrik Entwurfsmuster von GHJV95 Die von der Fabrik bereitgestellte Schnittstelle erm glicht das Erzeugen spezialisierter Sprachelemente ohne auf den konkreten Klassennamen der Sprachobjekte Bezug nehmen zu m ssen Auf diese Weise werden Abh ngigkeiten zwischen Sprach elementklassen und ihren Klienten d h den Klassen des administrativen Inter preterrahmens vermieden die diese Sprachelemente erzeugen F r jede integrierte Prozesssprache steht eine Fabrik bereit die die spezialisierten Sprachobjekte der Prozesssprache erzeugt So werden z B SLANG Transitionen als Spezialisierung einer atomaren Aktivit t ausschlie lich ber die Methode createAtomicActi vity der SLANG Fabrik erzeugt die den Klassennamen kapselt Die Verwen 7 5 GARPEM die generische Prozessmaschinenarchitektur 239 dung dieses Entwurfsmusters ergibt sich aus dem Umstand dass bei der Integra tion einer neuen Prozesssprache die vom Interpreterrahmenwerk bereitgestellten Sprachelemente spezialisiert werden mussen jedoch die spezialisierten Klassen namen vorab nicht bekannt sind Die Klassennamen sind jedoch f r die Instanzi ierung eines Sprachelements erforderlich so dass sich hier eine mit dem Ent wurfsmuster vermeidbare Abh ngigkeit ergibt Die Anwendun
119. w re jedoch auch bei einem kommerziellen Werkzeug das den in einem bestimmten Prozess ben tigten Funktionsumfang nicht anbietet nicht anders Nach der Kl rung der idealtypischen Prozessintegration im Sinne eines a pri ori Ansatzes stellt sich die dar ber hinaus weisende Frage ob nicht auch existierende Werkzeuge ber Methoden der Greybox Integration also mithilfe entsprechender Wrapper Techniken prozessintegriert werden k nnen Dazu sei an dieser Stelle schon darauf hingewiesen dass die blo e Existenz von programmierbaren Werk zeug APIs noch nicht viel ber die Prozessintegrierbarkeit des Werkzeugs aussagt diese h ngt vielmehr stark vom Funktionsumfang der programmierbaren Laufzeit schnittstellen ab So spielen neben dem Aufruf elementarer Werkzeugdienste auch der Zugriff auf die Interaktionselemente z B Men s und die Art der Datenper sistierung eine wichtige Rolle Die Anforderungen an die erforderlichen Werkzeug APIs werden wir in Abschnitt 7 4 genauer beleuchten Blackbox Integration spielt in dieser Arbeit nur eine untergeordnete Rolle da sich diese Integrationsmethode wie oben bereits diskutiert nur f r leichtgewich tige dight weight Batch artige Werkzeuge eignet EmFi96 Die in dieser Arbeit betrachten kreativen Entwurfsprozesse sind jedoch eher durch den Einsatz schwergewichtiger heavy weight Werkzeuge mit einem hohen Interaktionsgrad gekennzeichnet 3 3 Integrationsanforderungen in prozessinteg
120. weiteren bildet das PSM2 Modell das Fundament f r eine Integrationsmethodik die in Abschnitt 6 4 2 erl utert wird 6 4 Schnittstellenbindung 153 6 4 1 M2 Modell Das M2 Modell besteht aus zwei Submodellen dem Prozesssprachen M2 Modell PSM2 Modell und dem Bindungs M2 Modell BM2 Modell Das PSM2 Modell klassifiziert die Sprachkonzepte der zu integrierenden Prozesssprachen Die In stanziierung des PSM2 Modells sowohl durch das Schnittstellenmetamodell als auch durch das Metamodell der zu integrierenden Sprachen gibt die grunds tzli chen Korrespondenzen zwischen Kontextkomponenten und sprachspezifischen Konzepten bereits vor nur Sprachkonzepte die der gleichen Klasse im PSM2 Modell angeh ren k nnen aneinander gebunden werden Die eigentliche Bindung von Sprachkonzepten wird dann innerhalb des BM2 Modells festgelegt 6 4 1 1 Prozesssprachen M2 Modell Das PSM2 Modell abstrahiert diejenigen Sprachkonzepte die geeignet sind Kon textkomponenten in einer spezifischen Prozessmodellierungssprache darzustellen siehe Abb 29 Da Kontexte hier als Komponenten verstanden werden die ber Schnittstellen einen Dienst kapseln ist es naheliegend die drei Kontextarten einheitlich durch das Konzept einer Aktivit t darzustellen Nahezu jede Prozessmodellierungs sprache kennt dieses Konzept das einen atomaren oder zusammengesetzten Prozessschritt repr sentiert Die Sichtweise das Dienstangebot einer Kontext komponente durch das Akti
121. welches die Daten dann weiter verarbeitet siehe Abb 8a Popul r wurde diese Art der Datenintegration insbesondere in der Unix Programmers Workbench wo sich durch das Zusammenschalten der Aus und Ein gabekanale einfacher Batch Werkzeuge Filter Compiler Linker komplexe und m chtige Transformationswerkzeuge bilden lassen KeRi84 Alternativ zu Shared Memory oder Piping Mechanismen k nnen auch Kommunikationsmechanismen und protokolle wie CORBA OMG 97 oder HTTP Fie 99 zum Datentransfer verwendet werden so dass der Datenaustausch auch in einer r umlich verteilten heterogenen Umgebung m glich ist Die zeitlich getrennte Bearbeitung ist jedoch beim direkten Datenaustausch ebenso wie die Integration von mehr als zwei Werkzeugen mit Schwierigkeiten verbunden Au erdem l sst sich die werkzeug bergreifende Konsistenzsicherung berlappender Daten nur schwer realisieren u a deswegen weil Daten im Allgemeinen nur als uninterpretierte Zeichenstr me d h auf der Tr gerebene oder bestenfalls der lexikalischen Ebene s o ausge tauscht werden und es keine globale Sicht auf die Daten gibt Wir diskutieren zun chst nur den Werkzeug zu Werkzeug Datenaustausch In der Abb 7 be zeichnen A B und C aber beliebige datenhaltende Komponenten also Werkzeuge oder Prozess maschine Abb 8 Datenaustausch mecha nismen 62 3 Integrationsansatze Datei basierter Datenaustausch In der Praxis ist der Datei basierte Austausch von
122. zesszentrierter Ans tze liegt in der expliziten Definition der Vorgehensweisen und der damit verbundenen eichteren Anpassbarkeit an projektspezifische Bed rfnisse 1 2 Ziele und Aufbau der Arbeit Wahrend die formale Prozessmodellierung und die Prozessanleitung mittels rechnergest tzter Modellinterpretation mittlerweile recht gut verstanden sind wurden die Konsequenzen einer zunehmenden Prozessorientierung f r die am Arbeitsplatz verwendeten Entwurfswerkzeuge bisher jedoch kaum betrachtet Interaktive funktional reichhaltige Werkzeuge werden nur grobgranular in Pro zessmodellen ber cksichtigt und mit der Prozessmodellinterpretation integriert Aus der mangelnden Integrationstiefe resultieren schwerwiegende Probleme Der Benutzer wird in seinen Werkzeugen mit f r die aktuelle Aufgabe irrelevanten Funktionen konfrontiert und erf hrt durch das Werkzeug keinerlei a amp rive Unter st tzung bei der methodischen Aufgabendurchf hrung JaHu98 Aufgrund der inkrementellen Arbeitsweise mit interaktiven Werkzeugen steht die eigentliche Aufgabendurchf hrung au erhalb der Kontrolle der Prozessmodellausf hrung B hm98 oder schlimmer noch hartkodierte Prozessannahmen in den Werk zeugen konfligieren mit den Vorgaben aus dem Prozessmodell Process in the Tool Syndrom Mont94 Eine prozessmodellkonforme Arbeitsweise kann so nicht gew hrleistet werden und macht die Prozessmodellinterpretation zumindest auf der feingranularen Ebene des ind
123. zu garantieren m ssen eine EK Komponente und ihre Alternativen jeweils zueinander schnittstellenkompatibel sein Schnitt stellenkompatibilitat ist hier analog zur Verfeinerung von Methodensigna turen in stark typisierten objektorientierten Sprachen zu sehen d h die Ein und Ausgangsschnittstellen der EK Komponente und ihrer Alternati ven m ssen den gleichen strukturellen Aufbau haben und die In Produkt teile der Alternativen m ssen dabei den gleichen oder einen allgemeineren Typ die Out Produktteile den gleichen oder einen spezielleren Typ als die entsprechenden Produktteile der EK Komponente tragen Au erdem muss die Situationsbedingung der Alternativen schw cher sein als die der EK Komponente Durch diese Forderungen entsteht eine Spezialisierungsbeziehung zwischen Kon textkomponenten die festlegt ob eine Kontextkomponente als Alternative einer EK Komponente auftreten darf Die so entstehenden Hierarchien sind jedoch unserer Erfahrung nach relativ flach da nur eng verwandte Kontextkomponenten in einer Spezialisierungsbeziehung angeordnet werden k nnen Diese Erfahrungen wurden auch durch hnliche Arbeiten im Bereich der Ablaufmodellierung f r verfahrenstechnische Entwurfsprozesse best tigt Lohm98 Krob97 Insgesamt wird dadurch die Flexibilit t des Methodeningenieurs bei der Modellierung von EK Komponenten stark eingeschr nkt Vor dem Hintergrund dieser berlegungen haben wir uns bei der Schnittstel lenmodellierung vo
124. zur Interpretation des Umgebungsmodells bereit und erlaubt die flexible Erweiterung um spezifische Werkzeugfunktionalit ten F r die In tegration existierender Werkzeuge wurde das GARPIT Framework zu ei nem generischen Prozessintegrations Wrapper modifiziert und anhand der Integration von insgesamt drei weit verbreiteten Fremdwerkzeugen vali diert In der Leitdom ne steht mit dem GARPEM Framework ein generi scher Rahmen f r die Integration spezifischer Prozessspracheninterpreter 9 2 Erfahrungen und kritische Bewertung 273 zur Verf gung Das GARPEM Framework wurde am Beispiel der Ein bettung eines SLANG und eines UML Statechart Interpreters validiert O Validierung in mehreren Anwendungen Das PRIME Rahmenwerk wurde zur Entwicklung mehrerer prozessintegrierter Umgebung verwendet und dabei erfolgreich validiert Die gewonnenen Erfahrungen haben zur einer steti gen Weiterentwicklung des Rahmenwerks gef hrt Von den bisherigen Anwendungen war die in dieser Arbeit detailliert beschriebene PRIME IMPROVE Umgebung die anspruchsvollste Die besonderen Herausfor derungen lagen hier in einer Einbeziehung existierender Werkzeuge die ei nen unterschiedlichen Grad der Prozessintegrierbarkeit aufwiesen 9 2 Erfahrungen und kritische Bewertung Mit den entwickelten Werkzeug Umgebungen wurden kleinere Nutzerstudien mit Studenten PROART 2 0 und PRIME CREWS bzw Verfahrenstechnik Ingeni euren PRIME IMPROVE durchgef hrt Die dabei gewonnenen
125. 00 BFGL94 Bias91 BiJ087 B B B as97 e 99 e 99a BMCJ98 Boeh84 Boeh88 B hm98 BoJR99 Booc94 Literaturverzeichnis 281 Bernstein Ph und Dayal U An Overview of Repository Technology In Proc 20th Intl Conf on Very Large Data Bases VLDB 94 Santiago de Chile Chile Sept 12 15 1994 S 705 713 Beeri C A Formal Approach to Object Oriented Databases Data Knowledge Engineer ing 4 5 S 353 382 1990 Ben Shaul I Z und Kaiser G E Federating Process Centered Environments The Ox Experience Automated Software Engineering Journal 5 1 S 97 132 1998 Bergstra J und Klint P The Too Bus Coordination Architecture In Ciancarini P und Hankin C Hrsg Coordination Languages and Models Springer Verlag LNCS 1061 1996 S 75 88 Berthold A Mende U und Schuster H SAP Business Workflow Konzept Anwen dung Entwicklung Addison Wesley 1999 Becker J und zur M hlen M Towards a Classification Framework for Application Granularity in Workflow Management Systems In Jarke M und Oberweis A Hrsg Proc of the 11th International Conference on Advanced Information Systems Engi neering CAiSE 99 Heidelberg Springer Verlag LNCS 1626 1999 S 411 416 Bernstein Ph Bergstraesser Th Carlson J Pal S Sanders P und Shutt D Microsoft Repository Version 2 and the Open Information Model Information Systems 24 2 S 71 9
126. 1 berblick ber SFB IMPROVE Unter einem verfahrenstechnischen Prozess versteht man die Verkn pfung physikali scher chemischer biologischer und informationstechnischer Vorg nge um Aus gangsstoffe nach Art Eigenschaft und Zusammensetzung so zu ver ndern dass ein gew nschtes stoffliches Produkt entsteht Dieser Prozess l uft auf einer Anlage ab Der Entwurf oder die Modifikation eines verfahrenstechnischen Prozesses im Folgenden V T Prozess genannt und seiner anlagentechnischen Umsetzung ist Ziel des Modellierungsprozesses im Folgenden M Prozess genannt Ausgehend von einer 4 PROMENADE PRojektspezifische MEthodische Nachvollziehbarkeit von AnferDE rungsspezifikationen 5 TECHMOD Traced Engineering of CHemical process MODels 46 IMPROVE Informatische Unterst tzung bergreifender Entwicklungsprozesse in der Verfah renstechnik 47 Die sprachliche Unterscheidung zwischen VT und M Prozess mag im Text etwas umst ndlich erscheinen hat sich aber in der interdisziplin ren Kooperation mit Verfahrenstechnik Ingenieuren zur Vermeidung von Missverst ndnissen als unverzichtbar erwiesen 8 2 PRIME IMPROVE groben Problemstellung wird im Team eine vollst ndige Spezifikation von VT Prozess und Anlage erarbeitet die damit das Produkt des M Prozesses darstellt Der seit August 1997 von der Deutschen Forschungsgemeinschaft gef rderte SFB IMPROVE entwickelt neuartige informatische Konzepte die die Verbesse rung kooperative
127. 1 1 A Entscheidung contra kontext s 4 a basiert_auf Hat_Subkontext v Q Plankontext lt ndert lt ausgef hrt_durch Argument Produkt Prozessfragmente werden im NATURE Prozessmetamodell mithilfe des zentralen Konzepts Kontext dargestellt Ein als Kontext modelliertes Prozessfragment ist sowohl durch seine Aktivierungsbedingungen als auch durch die Art seiner Ope rationalisierung n her charakterisiert Eine wesentliche Grundidee des NATURE Prozessmetamodells besteht in der expliziten Verkn pfung von Situationen die der Entwickler zu einem Zeitpunkt vorfinden kann mit den Intentionen die er in diesen Situationen verfolgen kann Die Beschreibung der Aktivierungsbedingungen eines Kontextes zerf llt somit in einen objektiven Anteil die Situation und einen subjektiven Anteil die Intention Ein Kontext gilt als aktiviert wenn sowohl sein Situationsteil als auch sein Intenti onsteil g ltig sind Eine Situation beschreibt eine Konstellation des in Entwicklung befindlichen Produkts ber die es Sinn macht eine Entscheidung zu treffen Eine Situation ist somit als eine Abstraktion des aktuellen Produktzustands in einer Werkzeugumge bung zu verstehen In Abb 19 wird die Beziehung zwischen Situationen und Produkten durch eine einfache Assoziation basiert auf repr sentiert In Wirk lichkeit ist diese Beziehung komplexer aufgebaut sie definiert den strukturellen Aufbau einer Produktkon
128. 1 54 1999 Andersen O The Use of Software Engineering Data in Support of Project Management Software Engineering Journal 5 6 S 250 256 1990 Anderson M und Griffiths P The Nature of the Software Process Modelling Problem is Evolving In Proc 2nd European Workshop on Software Process Technology EWSPT 94 Villard de Lans France 1994 S 31 34 Appelrath H J und Ritter N R 3 Einf hrung Methoden und Werkzenge Springer Verlag Berlin Heidelberg 1999 Arbaoui S und Oquendo F PEACE Goal Oriented Logic Based Formalism for Process Modelling In Finkelstein A Kramer J und Nuseibeh B Hrsg Software Process Modelling and Technology Research Studies Press 1994 S 249 278 AT amp T UNIX System V Documenter s Workbench Introduction and Reference Manual 1984 AT amp T DSTC DEC HP ICL Nortel und Novell Trading Object Service OMG RFP5 Submission orbos 96 05 06 Version 1 0 1996 Atkinson M P Bancilhon F DeWitt D Dittrich K Maier D und Zdonik St The Object Oriented Database System Manifesto In Kim W Nicolas J M und Nishio Sh Hrsg Deductive and Object Oriented Databases Proceedings of the First In ternational Conference on Deductive and Object Oriented Databases DOOD S9 Kyoto Research Park Kyoto Japan North Holland Elsevier Science Publishers 1989 S 223 240 Avrilionis D Belkhatir N und Cunin P A Unified Framework for Software Process Enactment
129. 1b Analysis and Design OMT objektorientiert Class Diagram Data Flow Diagram State Rum 91 Object Modeling Transition Diagram Technique OODA objektorientiert Class Diagram State Transition Diagram Booc94 Object Oriented Design Object Diagram Module Diagram Process with Applications Diagram UML objektorientiert Class Diagram Use Case Diagram Collabora RuJB99 Unified Modeling tion Diagram Sequence Diagram State BoJR99 Language Diagram Activity Diagram Component Diagram Deployment Diagram Package Diagram F r das systematische Vorgehen des Entwicklers bei der Erstellung einer Anforde rungs bzw Architekturmodellen f r ein Softwaresystem ist in den letzten 20 Jahren eine schier un berschaubare F lle von Methoden entwickelt worden in denen in der Regel mehrere Modellierungstechniken mehr oder weniger koh rent aufeinander abgestimmt sind Je nach zugrunde liegendem Modellierungspara digma und ziel wird zwischen unterschiedlichen Methodentypen differenziert z B strukturierten und objektorientierten Methoden datenorientierten Methoden oder Methoden f r die Gesch ftsprozessanalyse Tab 1 liefert ohne Anspruch auf Vollst ndigkeit einen berblick ber die prominentesten Vertreter der unter schiedlichen Methodengattungen und ihre jeweiligen Modellierungstechniken Obwohl der Begriff der Methode in der Softwaretechnik Literatur nicht klar Elemente von Methoden umrissen ist und h ufig in un
130. 4 2 Bewertung existierender Ans tze Bei der folgenden Literaturbetrachtung zur konzeptuellen Werkzeugbeschreibung sind drei Bereiche f r uns von besonderer Relevanz Wir diskutieren zun chst allgemeine Beschreibungstechniken f r die Schnittstellen von Werkzeugen bzw Softwarekomponenten generell insbesondere im Kontext heterogener verteilter Systeme Danach wenden wir uns der konzeptuellen Modellierung von Werkzeu gen in existierenden Prozessformalismen zu Insbesondere interessiert uns ob und wie in existierenden prozesszentrierten Umgebungen extern vorliegende Schnitt stellenbeschreibungen von Werkzeugen mit den Konzepten der zugrunde liegen den Prozessmodellierungssprachen integriert werden Als dritten Teilaspekt be trachten wir abschlie end Generierungsans tze die mithilfe von Werkzeugspezifi kationen die auf vergleichsweise hohem logischen Niveau angesiedelt sind die semi automatische Erzeugung von Werkzeugfunktionalit ten erlauben Schnittstellenbeschreibungssprachen Schnittstellenbeschreibungen von Softwarekomponenten treten auf Entwurfs ebene in vielen Modellierungstechniken als zentrale Elemente auf z B in Form von Klassenspezifikationen in objektorientierten Methoden wie OMT oder UML Auf Implementierungsebene stellen Deklarationen von abstrakten Datentypen in nicht objektorientierten Sprachen wie Pascal oder Modula oder Klassen in ob jektorientierten Sprachen wie C Java und Smalltalk die elementarste Form v
131. 5 5 Integration der Modelle 5 5 1 Ziel des Umgebungsmodells Das Prozessmetamodell stellt Konzepte zur Modellierung von Prozessfragmenten als Ausf hrungs Entscheidungs bzw Plankontexte bereit Mit den Konzepten des Werkzeugmetamodells werden Werkzeuge durch ihre Basisfunktionalit ten das zugrunde liegende Produktmodell sowie ihre Interaktionselemente n her beschrieben Ziel des Umgebungsmetamodells ist es die im Prozessmodell defi nierten Kontexte auf die in einer Entwurfsumgebung zur Verf gung stehende Werkzeugfunktionalit t abzubilden und dabei insbesondere den Einfluss von Entscheidungs und Ausf hrungskontexten auf das Werkzeugverhalten festzule gen Wie wir in Kapitel 7 sehen werden werden die im Umgebungsmodell vorge nommenen Zuordnungen zwischen Prozessfragmenten und Werkzeugen von generischen Laufzeitkomponenten der Prozessmaschine des Kommunikations mechanismus und der Werkzeuge bei der Aktivierung Ausf hrung und Koordi nation von Prozessfragmenten interpretiert 5 5 Integration der Modelle 121 5 5 2 PRIME UM Das Umgebungsmetamodell Da das Werkzeugmetamodell in Hinblick auf eine Verkn pfung mit dem Pro zessmodell entworfen wurde ist die Integration von Prozess und Werkzeugme tamodell auf recht einfache Weise m glich Abb 21 zeigt das Umgebungsmetamo dell mit den jeweiligen Anteilen aus dem Prozessmetamodell wei unterlegte Konzepte und aus dem Werkzeugmetamodell schwarz unterlegte Konzepte Konkret erf
132. 66 July 1990 Reiss St Interacting with the Field Environment Software Practice and Experience 20 S1 S 89 115 Juni 1990 Reiter Ch Toolbasierte Referenzmodellierung State of the Art und Entwicklungstrends In Becker J Rosemann M und Sch tte R Hrsg Referenzmodellierung State of the Art and Entwicklungsperspektiven Physica Verlag 1998 S 45 68 Reps T und Teitelbaum T The Cornell Program Synthesizer A Syntax directed Program ming Environment Communications of the ACM 24 9 S 449 477 1981 Reps T und Teitelbaum T The Synthesizer Generator A System for Constructing Language Based Editors Springer New York 1988 Ro1197 RoPB99 RoSB98 RoSc77 RoSc99 RoSM95 Roth93 Royc70 RuJB99 Rum 91 Sarl92 Satt97 ScBr93 Sc ha96 he93 he98 hi92a hi92b hi93 hm96 hm99 hr97 hu99 ScKR96 Literaturverzeichnis 295 Rolland C A Primer for Method Engineering In Proc of the INFORSID Conference INformatique des ORganisations et Syst mes d Information et de Decision Tou louse France 1997 Rolland C Prakash N und Benjamen A A Multi Model View of Process Modelling Requirements Engineering 4 4 S 169 187 1999 Rolland C Souveyet C und Ben Achour C Guiding Goul Modelling using Scenarios IEEE Transactions on Software Engineering Special Issue on Scenario Manage ment 24 12 S 1055 1071 1998 Ro
133. 8 1999 Becker J Rosemann M und Sch tte R Hrsg Referenzmodellierung State of the Art und Entwicklungsperspektiven Physika Verlag Heidelberg 1999 Beydeda S Gruhn V Schneider C Alloui I Oquendo F und Cimpan S Advanced Services for Process Evolution Monitoring and Decision Support In Proceedings of the 7th European Workshop on Software Process Technology Kaprun sterreich Springer Verlag LNCS 1780 2000 Bandinelli S Fuggetta A Ghezzi C und Lavazza L SPADE An Environment for Software Process Analysis Design and Enactment Tech Report GOODSTEP Project TR No 020 1994 Bias R Walkthroughs Efficient Collaborative Testing IEEE Software 8 5 S 94 95 1991 Birman K P und Joseph T A Rehable Communication in Presence of Failure ACM Transactions on Computer Systems 5 1 S 47 76 1987 Blass E Entwicklung verfahrenstechnischer Prozesse Methoden Zielsuche L sungssuche L sungsauswahl Springer Verlag Berlin Heidelberg 1997 Bleek W G Gryczan G Lilienthal C Lippert M Roock S Wolf H und Z llighoven H Frameworkbasierte Anwendungsentwicklung Teil 2 Die Konstruktion inter aktiver Anwendungen OBJEKTspektrum 2 99 S 78 83 1999 Bleek W G Lippert M Roock S Strunk W und Z llighoven H Frameworkba sierte Anwendungsentwicklung Teil 3 Die Anbindung von Benutzeroberflachen und Entwick lungsumgebungen an Frameworks OBJEKTspektrum 3 9
134. 9 S 90 95 1999 Bohm M Meyer Wegener K Cap C und Jablonski St Ein konstruktiver Ansatz zur systematischen Entwicklung von Ansf hrungsanweisungen von Workflows Tech Report Technische Universit t Dresden TUD FI 98 05 April 1998 Boehm B Software Engineering Economics IEEE Transactions on Software Engineer ing 10 1 S 4 21 1984 Boehm B A Spiral Model of Software Development and Enhancement TEEE Computer 21 5 S 61 72 1988 Bohm M Integration externer Applikationen im Workflov Management Infor matik Informatique April 98 S 23 27 1998 Booch G Jacobson I und Rumbaugh J The Unified Modeling Language User Guide Adidson Wesley 1999 Booch G Object Oriented Design with Applications Benjamin Cummings Publishing Company Inc 1994 282 Literaturverzeichnis BoTa96 Bran01 BrD 195 Bre 93 BrEM92 BrEW92 BrFe92 Brin96 BrLW96 BrMc91 Bro 94 Broc95 Brow93 BrPS98 Bus 96 Byrn96 CaFM99 Caga90 Car 93 Cat 00 CaWe85 CDFG 96 Bolcer G A und Taylor R Endeavors A Process System Integration Infrastructure In Proceedings of the 4th International Conference on the Software Process Brighton GroBbritannien 1996 S 76 89 Brandt S Prozessintegration von Fremdwerkzengen am Beispiel der verfahrenstechnischen Entyufsumgebung PRIME IMPROVE Diplomarbeit RWTH Aachen 2001 in Vor bereitung Br hl A
135. 94 Park92 Parker B Introducing ELA CDIF The CASE Data Interchange Format Standard In Proc 2nd Symposium on the Assessment of Quality Software Development Tools New Orleans LA USA May 1992 PaSa96 Paul G und Sattler K U MediatorService Integration von verteilten Objekten durch Beschreibung der Interaktionen In Spaniol O Linnhoff Popien C und Meyer B Htsg Proceedings of the International Workshop Trends in Distributed Sys tems Aachen Germany 1996 S 125 132 PaSE97 Paul G Sattler K U und Endig M An Integration Framework for Open Tool Environ ments In Distributed Applications and Interoperable Systems Proceedings of Inter national Working Conference IFIP WG 6 1 Cottbus Germany 1997 S 193 200 PCCW93 Paulk M C Curtis B Chrissis M B und Weber C V Capability Maturity Model Version 1 1 IEEE Software 10 4 S 18 27 1993 Pint93 Pintado X Gluons a Support for Software Component Cooperation In Nishio S und Yonezama A Hrsg Proc of the International Symposium on Object Technolo OMG 97b 293 294 Literaturverzeichnis PIR095 Poh 99 PoHa95 Pohl94 Pohl95 Pohl96 Poh197 Pohl99 PoSW96 PoWe97 Pree97a Pree97b Pres97 Purt94 PuTV97 RaSt92 Redw93 Reif93 Reis90 Reis90a Reit98 ReTe81 ReTe88 gies for Advanced Software ISOTAS 93 Springer Verlag Be
136. 98 Be M 99 EmFi96 Auch Rahmenmodelle f r integrierte Entwurfsumgebungen Kelt93 wie das so genannte Toaster Modell der europ ischen ECMA EC MA93 das Prisma Modell der amerikanischen NIST NIST93 oder das CAD Referenzmodell Abel95 listen in einem Katalog von Basisdiensten zwar Dienste f r das Prozessmanagement also im wesentlichen Prozessmaschinen und Pro zessmodelle auf ohne jedoch genaueren Aufschluss ber das Zusammenspiel dieser Dienste mit den anderen Basisdiensten und den zu integrierenden Werkzeu gen zu geben 3 2 Integrationsvoraussetzungen Vor einer Diskussion der unterschiedlichen Integrationsanforderungen ist es zun chst wichtig sich ber die u eren Randbedingungen f r die Einbindung eines Werkzeugs in eine prozessintegrierte Umgebung Klarheit zu verschaffen Hier lassen sich im Wesentlichen drei verschiedene Integrationsszenarien unter scheiden die einen wesentlichen Finfluss darauf haben in welcher Granularit t und Tiefe die Integration eines Werkzeugs berhaupt gelingen kann VaKa96 RaSt92 BeM 99 JaBu96 EmFi96 Q Blackbox Integration Bei dieser schw chsten Form der Integration sind Werkzeuge lediglich als ausf hrbare Programme binaries verf gbar Die Einflussnahme von au en beschr nkt sich auf das Starten und Beenden des Werkzeugs wobei gegebenenfalls ber die Kommandozeile oder ber Umgebungsvariablen Startparameter Eingabedaten spezifische Funktio nen bergeben u
137. A6 Werkzeugunterst tzter Aufruf von Prozessfragmenten Da Ent scheidungskontexte insbesondere Plankontexte die der Prozessmaschine zugeordnet sind als Alternativen enthalten k nnen erlangt ein Werkzeug Wissen ber die im aktuellen Prozesskontext verf gbaren Prozessfrag mente und kann so den Aufruf extern definierter Prozessfragmente durch den Benutzer unterst tzen 6 1 Motivation Interoperabilit t von Prozesssprachen 6 1 Motivation Der im vorangegangenen Kapitel vorgestellte Prozess und Werkzeugmodellie rungsansatz repr sentiert werkzeugbezogene Prozessfragmente durch das zentrale Konzept des Kontexts welches drei wesentliche Komponenten zusammenf hrt einen Intentionsteil einen Sitnationsteil und einem Verhaltensteil wobei letzterer je nach Kontextkategorie Ausf hrungskontext Entscheidungskontext Plankontext unterschiedlich aufgebaut ist Damit das Umgebungsmetamodell als ausf hrbare Prozessmodellierungssprache eingesetzt werden kann muss es einem Laufzeitme chanismus alle zur Operationalisierung notwendigen Informationen bereitstellen In der bisher beschriebenen Form l sst sich mit den Konzepten des Umgebungs metamodell jedoch nur die Aktivierung von Intentionen sowie das Verhalten von Ausf hrungskontexten und Entscheidungskontexten vollst ndig spezifizieren Zwei weitere Aspekte die Definition von Situationen und die Festlegung von Abl ufen zwischen den Subkontexten eines Plankontexts sind im Umgebungs met
138. Abh ngigkeiten zwi schen Teilschritten einer Prozessspur Abb 36 Arbeitsweise des Pro zessspuren Servers 7 Das PRIME Rahmenwerk und die Akkumulierung und Nutzung von Erfahrungswissen unterst tzen JPRS94 Grundvoraussetzung hierf r ist die persistente Protokollierung der in den Entwicklungswerkzeugen durchgef hrten Ausf hrungs und Entscheidungs kontexte Aus der Gesamtheit der protokollierten Kontextausf hrungen und der dabei involvierten Produktinstanzen ergibt sich die so genannte Prozessspur anhand derer abgelaufene Prozesse zur ck verfolgt werden k nnen Eine grundlegende Entwurfsentscheidung des PRIME Frameworks besteht darin dass die persistente Auszeichnung von Ausf hrungs und Entscheidungs kontexten jeweils von den Werkzeugen in denen sie durchgef hrt wurden selbst st ndig und automatisch durchgef hrt wird Dies entlastet erstens den Entwickler von einer arbeitsaufw ndigen und fehlertr chtigen manuellen Protokollierung seiner Arbeitsprozesse Zweitens kennen die jeweiligen Werkzeuge die Semantik der aufgezeichneten Arbeits und Entscheidungsschritte am besten so dass hier qualitativ hochwertigere Nachvollziehbarkeitsinformationen gewonnen werden k nnen als bei indirekten Beobachtungsans tzen die wie etwa der in Abschnitt 3 3 5 beschriebene Provence Ansatz zwangsl ufig auf einer systemtechnisch tiefe ren Ebene ansetzen m ssen Um eine semantisch reichhaltige Prozessspur zu erhalten reicht es jed
139. Abh ngigkeitseditor integ riert und erlaubt so die Annotation beliebiger Teilschritte oder sequenzen einer Prozessspur mit informellen Texten Entscheidungsdokumentationen oder belie bigen anderen Produkten einer PRIME basierten Umgebung Anleitungswerkzeug Das generische Anleitungswerkzeug liefert eine alternative Benutzerschnittstelle f r die Aktivierung von Werkzeugkontexten und die Entgegennahme von R ck meldungen Abb 38 Sein Haupteinsatzgebiet liegt in der Einbindung externer Werkzeuge die ber keine geeigneten M glichkeiten zur Anpassung der Benutzer schnittstelle an den aktuellen Prozesszustand und zur R ckmeldung der in diesen Werkzeugen durchgef hrten Aktionen verf gen siehe Abschnitt 7 4 In diesem Fall fungiert das Anleitungswerkzeug als Proxy der gegen ber der PRIME Umge bung die Rolle des externen Werkzeugs einnimmt Kommandos f r simulierte Prozessdurchf hrung Signalisiert Beendigung eines Kontexts mit anschlie ender Entscheidungsdokumentation bzw Hypertextdokumentation Signalisiert Signalisiert Start eines Beendigung Kontexts eines Kontexts Prozess Anleitung est Hilfe REN Pi Z Jeder Reiter enth lt die aktivierbaren Kontexte jeweils einer Werkzeugkategorie Proze fragment angeford za Ey Aspen Plus DECEditor DEP Editor ER Editor FlowsheetEditor GoalEditor HT Editor MSC Ed 4 Liste der im aktuell ausgew hlten SC Spezifiziere das zugrundeliegende Sim
140. Anpassbarkeit von Software Werkzeugen in prozessintegrierten Entwicklungsumgebungen Von der Fakult t f r Mathematik Informatik und Naturwissenschaften der Rheinisch Westf lischen Technischen Hochschule Aachen zur Erlangung des akademischen Grades eines Doktors der Naturwissenschaften genehmigte Dissertation vorgelegt von Diplom Informatiker Klaus Lambert Weidenhaupt aus Immerath jetzt Erkelenz Berichter Universit tsprofessor Dr rer pol Matthias Jarke Universit tsprofessor Dr rer nat Gregor Engels Tag der m ndlichen Pr fung 11 Juli 2001 Diese Dissertation ist auf den Internetseiten der Hochschulbibliothek online verf gbar Kurzfassung i Kurzfassung Komplexe Modellierungsaufgaben wie sie in den fruhen Phasen der Informations systementwicklung aber auch im ingenieurwissenschaftlichen Kontext auftreten erfordern eine geeignete Unterst tzung durch Software Werkzeuge die sich ohne gro en Aufwand an organisations und projektspezifische Methoden und Prozesse anpassen l sst Konventionelle produktorientierte CASE Umgebungen werden in dieser Hinsicht vielfach als zu inflexibel empfunden da sie auf hartkodierten Annahmen ber die zu unterst tzenden Prozesse beruhen Eine verbesserte An passbarkeit versprechen prozesszentrierte Entwicklungsumgebungen die auf formalen austauschbaren Prozessmodellen basieren In existierenden Ans tzen addressiert die Prozessanleitung jedoch prim r die administrative Ebene
141. Benutzeroberfl chen nenenenneenennnnnenne 99 3 3 6 1 Motivatie ahea a a a a E nennen snn nennen 99 3 3 6 2 Bewertung existierender Ans tze uunnsseensenseenseennneennenenne nn 101 33 68 BZA erene aa a a a aat ee EN EEEn neste 102 3 3 7 Werkzeugunterst tzter Aufruf von Prozessfragmenten nn 102 334 1 Motivation a eirean aa ie seat anes 102 3 3 7 2 Bewertung existierender Ans tze unesenseneenneennnennnennnnennnn een 103 3312 46 AZM ea ana A S 103 3 4 ZAG ga ctadar dasa eas disies as ealoaeasvoutvaucesewtiaustass iaseclocetasenees deen tosesivininduseaiaie ease 104 Teil 2 L sungskonzept una Bun 105 4 BERBLICK UBER DEN L SUNGSANSATZ zuueessnsensonsnnnnnnnennsnnnnnnn 107 5 INTEGRIERTE PROZESS UND WERKZEUGMODELLE 109 5 1 Darstellung der Modelle 0 0000200000000000000220002200000000002000000000000000 00 109 SAA UM Esed e a eisen 110 SEZ O TElOS e enne Te E a E e E E TR 110 5 2 Motivation f r integrierte Prozess und Werkzeugmodelle 111 5 3 Modellierung von Prozessfragmenten e esseesseossocssoesoossoossoosssosssosesosssse 113 5 3 1 Ziele und Anforderungen unesssssessensennsennneennennennnenne nennen 113 5 3 2 PRIME PM das NATURE Prozessmetamodell ne 114 5 4 Modellierung von Werkzeugen essssssonssssnnesnnssssnnnsnonnnsnnssesnnnsnsnnnsnnnne 117 5 4 1 Ziele und Anforderungen uueessssseessesnsennseennee
142. Dokumentenorientierte Erweiterung Ein Flie bild definiert lediglich eine tempor re Sicht im Flie bildeditor die der Benutzer durch Einf ge und Navigationsoperationen innerhalb seines Flie bild modell hergestellt hat Aus administrativer Sicht ist es jedoch manchmal erforder lich einen bestimmten Darstellungszustand des Flie bildmodells als festes Flie bild Dokument einzufrieren Aus diesem Grund haben wir das zus tzliche Konzept eines Zeichenblatts Sheet eingef hrt mit dessen Hilfe dem Flie bildmodell eine dokumentenorientierte Sicht aufgepr gt werden kann Ein Zeichenblatt wird zu einem bestimmten Zeitpunkt vom Benutzer angelegt und aggregiert alle aktuell sichtbaren VT Prozesselemente VT ProcessDevices Streams VI ProcessGroups zusammen mit ihren Layout Informationen Ein Sheet kann mit einem Bezeichner benannt werden und jederzeit wieder hergestellt werden Mehrere Sheets k nnen zu einem Projekt Project zusammengefasst werden 8 2 3 Positionierung von PRIME IMPROVE im SFB Prototypen Die PRIME IMPROVE Umgebung ist Teil eines integrierten Prototypen der zusammen mit anderen Teilprojekten des Sonderforschungsforschungsbereich IMPROVE entwickelt wurde und auf der ersten Begehung des SFBs sowie auf mehreren Workshops mit Industriebeteiligung erfolgreich demonstriert wurde Abb 73 gibt einen berblick ber die Grobarchitektur der PRIME IMPROVE Umgebung ber die Integration der vollst ndig und partiell prozessinte
143. E DataEntry DataProcessing End SimpleProcessFragment Activity EnterData EXEC usr bin formedit End EnterData Activity ProceedData EXEC usr bin dataprocessing End ProceedData Bei der Ausf hrung einer Aktivit t z B EnterData wird der Pfad des aufzurufen den Werkzeugs usr bin formedit als Argument der EXEC Anweisung direkt an die Betriebssystemebene zur Aktivierung durchgereicht Das Werkzeug ist also innerhalb des Prozessmodells nicht als konzeptuelles Objekt mit einer festgelegten Schnittstelle sondern lediglich durch einen uninterpretierten String repr sentiert Werkzeuge werden erst Dadurch ist z B unm glich unzul ssige Verwendungen des Werkzeugs etwa durch Referenzierung aufgrund nicht passender Parameterlisten zu entdecken Au erdem existiert keine innerhalb des Prozess yon konkreten Prozessdefinitionen unabh ngige Modellierung der verf gbaren Werkzeuge dells sichtbar ey ET bzw Werkzeugdienste d h ein Werkzeug wird innerhalb des Prozessmodell erst sichtbar wenn es innerhalb einer Call Exec Anweisung referenziert wird Der Prozessmodellierer erh lt somit keine Unterst tzung bei der Suche nach passender Werkzeugfunktionalit t f r einen Prozessschritt was insbesondere in gro en Entwurfsumgebungen mit einer Vielzahl von Werkzeugen die konsistente Zuord nung von Prozessschritten und Werkzeugen erheblich erschwert In vielen F lle
144. Entwurfsentscheidungen vom Frame work abgenommen Die PRIME Architektur folgt einem Framework orientierten Entwurfsansatz d h wesentliche Teile der Architektur liegen als bereits realisiertes Grundger st vor in welches f r eine konkrete Auspr gung einer prozessintegrierten Umgebung mit verh ltnism ig geringem Aufwand nur noch spezifische Funktionsbausteine eingef gt werden m ssen Das Gesamt Framework zerf llt dabei in zwei gr ere Sub Frameworks In der Durchf hrungsdom ne steht dem Entwickler ein Frame work f r prozessintegrierte Werkzeuge zur Verf gung Wesentliches Merkmal dieses GARPIT Generic ARchitecture for Process Integrated Tools genannten Frameworks sind ein generischer Interpreter f r die werkzeugrelevanten Anteile des in Kapitel 5 skizzierten Umgebungsmodells sowie eine Reihe von abstrakten Adapterklassen f r den Anschluss an spezifische Produktmodelle GUI Imple mentationen und Kommunikationsmechanismen Wir stellen GARPIT in Ab schnitt 7 3 im Detail vor Das Gegenst ck zu GARPIT auf Seiten der Leitdom ne ist das GARPEM Generic ARchitecture for Process Enactment Mechanisms genannte Prozessma schinen Framework Dieses Framework stellt allgemein verwendbare Kernfunkti onalit t f r die Ausf hrung von Prozessfragmenten bereit und definiert Schnitt stellen f r die Einbettung spezifischer Prozessspracheninterpreter gem dem in Kapitel 6 vorgestellten Modellierungsansatz zur Integration heterogener Prozes
145. Erfahrungen erm glichen eine Bewertung des Ansatzes aus drei verschiedenen Blickwinkeln denen des Anwenders des Methodeningenieurs und des Werkzeugentwicklers 9 2 1 Sicht des Anwenders Aus Benutzersicht wurde die Anpassung des Werkzeugverhaltens an den aktuellen Prozesskontext und die daf r definierten Prozessmodelle als durchweg sehr hilf reich empfunden Durch die automatische Anpassung der ausw hlbaren Kom mandos und Produkte wurden die Anwender ber die jeweils aktuell anwendbaren Prozessdefinitionen informiert und mussten diese nicht in extern vorliegenden Vorgehensbeschreibungen nachlesen Auch das Ausblenden aktuell nicht relevan ter Kommandos und Produkte wurde als positiv angesehen da dadurch eine klare Fokussierung auf die zu bearbeitende Aufgabe erreicht wurde Es wurde jedoch bem ngelt dass sich beim Wechsel eines Entscheidungskontexts in einem Werk zeug die Positionen der Men eintr ge laufend ndern und sich der Benutzer je weils an ein neues Erscheinungsbild der Men s gew hnen muss Die nahtlose Integration der Prozessanleitung in die Werkzeug Umgebung d h die vereinheitlichte Aktivierung von werkzeuginternen Diensten Diensten anderer Werkzeuge und Prozessfragmenten wurde gegen ber der in prozesszent rierten Umgebungen und Workflow Managementsystemen sonst blichen Inter aktion ber einen separaten Agenda Manager als gro er Vorteil betrachtet So erw hnten mehrere Benutzet dass sie erst im nachhinein real
146. Fremdwerkzeugen in Softbench indem es die Generierung von Wrapper Schnittstellen f r das Versenden und Empfangen von Nachrich ten unterst tzt Dieser Wrapper interpretiert die Ein und Ausgaben eines Werkzeugs wandelt sie in entsprechende Nachrichten um und versieht das Werkzeug bei Bedarf zus tzlich mit einer interaktiven Benutzungsschnitt stelle des zugrunde liegenden Fenstersystems Ohne massiven Eingriff in das zu integrierende Werkzeug funktioniert dieser Ansatz allerdings nur bei einfachen Batch artigen Kommandozeilen Werkzeugen zufriedenstellend Q Ein Execution Manager ist f r das transparente Auffinden und Aktivieren ei ner passenden Werkzeuginstanz zust ndig wenn ein Werkzeug einen be stimmten Dienst angefordert hat Q Es werden neben Anforderungsnachrichten request messages Erfolgsmel dungen success notifications und Fehlermeldungen failure messages unter schieden TooITalk Ein weiterer Vertreter des Message Broadcasting Ansatzes ist Sun s Too Talk Fran91 Suns93 Hier wurde wieder die Grundidee eines zentralen Message Ser vers bernommen Allerdings weist auch ToolTalk einige Besonderheiten auf O Im Gegensatz zur rein prozeduralen Sicht in FIELD und SoftBench gibt ToolTalk einen Migrationsschritt in Richtung Objektorientierung vor Werkzeuge lassen sich als so genannte object descriptions repr sentieren die untereinander ber Nachrichten kommunizieren Durch Anordnung der object descriptions innerhalb ein
147. Ga96 bungssprachen BaCK98 Dono99 stammen eine Reihe von Architekturbeschreibungssprachen so genannte ADLs Clem96 MeTa97 Vest93 KrMa97 deren Ursprung meist in der Entwicklung verteilter Systeme liegt wo sich ebenfalls die Forderung nach unabh ngigen Komponenten mit wohldefinierten Interaktionsbeziehungen ergibt Beispiele sind u a MetaH Vest96 Rapide Luc 95 Wright Alla97 Darwin MDEK95 O an BAKR95a Pohlith MIL Purt94 und Focus M Sc96 Charak teristisch f r diese Sprachen ist die separate Beschreibung von Komponenten Konnektoren und daraus gebildeten Konfigurationen Die meisten dieser Sprachen sind formal fundiert so basiert die Semantik von Darwin auf dem n Kalk l von Milner Miln89 in Wright wird eine Untermenge der Communicating Sequential Processes CSP von Hoare Hoar85 zur Spezifikation des Interaktionsverhaltens von Konnektoren verwendet Gemeinsames Merkmal der genannten Modelle ist die explizite Repr sentation der Interaktion einer Gruppe von Komponenten Die Zielrichtung der eingesetzten Beschreibungstechniken ist allerdings etwas anders gelagert als in unserem Fall Es steht weniger die Ab aufstenerung zwischen Komponenten im Vordergrund als vielmehr der Ausgleich von Schnittstellen und Protokollinhomogenit ten zwi schen verschiedenen Komponenten Interzeption Dies gilt auch f r Interzeptoransatze die beim bergang zwischen verschiedenen Komponentenarchitekturen z B von JavaBeans nach Act
148. Hall 1996 S 1 7 O1 91 Olle T W Hagelstein J Macdonald I G Rolland C Sol H G Van Assche F und Verrijn Stuart A A Information Systems Methodologies A Framework for Understand ing Addison Wesley 1991 OMG 97 OMG The Common Object Request Broker Architecture and Specification Revision 2 0 Tech Report Object Management Group OMG Document 97 07 04 1997 OMG 97a OMG What Is OMG UML and Why Is It Important Tech Report Object Manage ment Group OMG s Press Releases 1997 1997 http www omg org news pr97 umlprimer html OMG CORBAservices Common Object Services Specification Tech Report Object Management Group July 1997 ftp ftp omg org pub docs formal 97 07 04 pdf OMG 97c OMG Meta Object Facility MOF Specification Tech Report Object Management Group OMG Document ad 97 08 14 September 1997 OMG 97d OMG Object Constraint Language Specification Object Management Group OMG Document ad 97 08 08 September 1997 OMG 98a OMG Workflow Management Facility OMG BODTF RFP 2 Submission Tech Report OMG OMG Document Number bom 98 06 07 July 1998 OrHE96 Orfali R Harkey D und Edwards J The Essential Distributed Objects Survival Guide John Wiley amp Sons 1996 Ortn99 Ortner E Repository Systems Teil 1 Mehrstufigkeit und Entwicklungsumgebung Informatik Spektrum 22 4 S 235 251 1999 Oust94 Ousterhout J K Te and the Tk Toolkit Addison Wesley 19
149. Help Editing a situation Unrestricted Plan C Situation descriptor Rolename EntityList Sub type tag List X Detaildefinition eines Situationsteils List List element type ProductT ype X Minimum cardinality 2 Maximum cardinality 100 Product Product type ER_Entity Product state Selected v Abb 39 Der prozessintegrierte Editing 3 stuaton par PRIME NATPROC Editor Unrestricted Pian Context Choice Context Executable Context I _ 1 1 Mithilfe des NATPROC Editors lassen sich alle Kontextinformationen erfassen die unabh ngig von einem konkreten Formalismus zur Plankontextdefinition sind Seine Grundfunktionalit ten bestehen demnach in der Q Definition von Intention Definition von Situationen Kombination von Intentionen und Situationen zu Kontexten Definition von Aktionen und Zuordnung zu Ausf hrungskontexten m m oO m Zuordnung von Alternativen zu Entscheidungskontexten 7 1 Die PRIME Gesamtarchitektur 179 Dar ber hinaus implementiert der NATPROC Editor eine Reihe von Integrit ts checks mit deren Hilfe die Konsistenz der im Prozess Repository abgelegten Kontextmodelle nachgepr ft werden kann sofern dies nicht bereits datenbanksei tig gew hrleistet werden kann Abb 39 zeigt die unterschiedlichen Auswahl und Eingabefenster des NATPROC Editors und vermittelt einen Eindruck von der Funktionalit t des Werkzeugs Plankontext Editoren Wie in Kapitel 6 b
150. Initiator des prozessrelevanten Ereignisses Wi zwar st rker von den anderen Werkzeugen entkoppelt Das Prozesswissen ber die richtige Reaktionen auf Ereignisnachrichten ist jedoch im Code der Nachrichtenschnittstelle des Werkzeugs W2 versteckt Abb 11 Mitte Beide Ans tze f hren zu offensichtlichen Problemen wenn die Interaktion zwischen den Werkzeugen so abge ndert werden soll dass bei Ereignis E der Dienst D durch eine anderen Dienst ersetzt werden soll oder zus tzliche Schritte als Reaktion auf E eingebaut werden sollen Im konkreten Beispiel k nnte bei spielsweise dem Speichern eines Quelldatei erst das Einchecken in ein Versions managementsystem folgen bevor die bersetzung gestartet wird Daraus l sst sich schlussfolgern dass ein Werkzeug zum einen keine direkten Kommandos an andere Werkzeuge sondern nur Notifikationen ber das Auftre ten von Ereignissen verschicken sollte Zum anderen sollten Werkzeuge auf Emp fangsseite keine Notifikationen behandeln m ssen sondern lediglich den direkten Aufruf von Diensten durch explizite Kommandos exportieren In Umgebungen ohne explizite Kontrolle durch des Prozesses durch eine separate Komponente 72 3 Integrationsansatze bedeutet dies einen scheinbaren Widerspruch denn wie soll Interaktion zwischen Werkzeugen stattfinden wenn Sender nur Notifikationen aussenden und Empfan ger nur Kommandos behandeln k nnen Die Grundidee besteht darin dass die Prozessmaschine als
151. K Prozesses zwei Ursachen haben Zum einen kann w hrend eines Interpretationsschrittes ein Fehler im Fragment auftreten Dazu geh ren Fehler die bei unsachgem e Modellierung des Frag mentes auftreten wie z B laufzeitbedingte Typ oder Typzuweisungsfehler Diese treten im Zustand DeducingActivities auf und f hren zun chst zu einer Fehler behandlung im Zustand HandlingError und dann zum Abbruch des PK Prozes ses Zum anderen kann die Ausf hrung eines Prozesses im Zustand ExecutingAc tivities z B vom Benutzer abgebrochen werden Wenn der Interpretations schritt nicht im Zustand CommitStep best tigt wird f hrt dies ebenfalls zu einem Abbruch des PK Prozesses Ausf hrungsmodell von AK und EK Prozessen Analog zum Ausf hrungsmodell der Klasse PC Process kann der running Zu stand von AK und EK Prozessen Klassen FC Process und CC Process verfei nert werden Da die eigentliche Ausf hrung dieser Prozesskomponenten in der Durchf hrungsdom ne stattfindet kann jedoch innerhalb des Interpreterframe works von den Subst nden des Zustands running abstrahiert werden so dass wir hier nicht n her darauf eingehen Nachrichten und Variationspunkte Zwischen dem Ausf hrungsmodell eines Prozesses vgl Abb 67 und den Variati onspunkten des Interpreterrahmenwerkes besteht ein enger Zusammenhang 40 Die Phasen der Ausf hrungs und Entscheidungskontextinterpretation im Zustand running wurden bereits in Abschnitt 7 3 2 5
152. Komplexit t des zu entwickelnden Systems Klarheit und Stabi lit t von Anforderungen Bedeutung des Projekts f r die Organisation Auswit kung auf Gesch ftsprozesse etc Dar ber hinaus identifiziert Madhavji weitere Gr nde die zu einer Anpassung existierender Prozesse f hren k nnen Madh91 Q Der Prozess ist fehlerhaft Kontingenzfaktoren Q Der Prozess ist l ckenhaft d h es fehlen wichtige Schritte Q Der Prozess ist zu generisch und muss konkretisiert werden um im aktuel len Anwendungskontext spezifische Ergebnisse hervorzubringen Q Die Annahmen unter denen ein Prozess entworfen wurde sind durch eine nderung der Randbedingungen nicht l nger g ltig Wir wollen an dieser Stelle nur die durch Organisations und Projektspezifika induzierte Notwendigkeit einer anpassbaren Prozessunterst tzung festhalten und nicht detailliert auf die Interdependenzen zwischen Kontingenzfaktoren und Entwicklungsprozessen eingehen Eingehendere Betrachtungen dar ber sind in der Literatur ber Softwaretechnik z B Somm92 Nagl96 Pres97 Scha96 Software bzw Projektmanagement z B Boeh84 Ande90 Car 93 Sarl92 Reif93 und Prozess und Methodenmodellierung z B Chr 97 Harm97 SIH096 HoVe97 zu finden F r den Spezialfall von Nachvollziehbarkeits und Doku mentationsprozessen im Requirements Engineering wurde in D mg99 ein um fangreiches Referenzmodell entwickelt das den Zusammenhang zwischen ver schiedenen Projekteigen
153. Kontextkomponenten in einer PK Komponente f r einen Ausf hrungsmechanismus festzuhalten Da die in der PK Komponente dargestellte Komponentenschnittstelle nur ein Stellver treter einer Komponente ist die anderweitig implementiert wird muss z B ein SLANG Interpreter unterscheiden ob es sich bei einer zu schaltenden Transition um eine regul re Transition handelt oder ob die Transition eine Komponente repr sentiert die ber ihre Stellvertreterschnittstelle einen Dienst anbietet Ist dies der Fall dann kann der Dienst ber eine externe Prozessmaschine in Anspruch genommen werden d h die Parameter werden an der Schnittstelle bergeben und die mit der Transition gebundene Komponente wird angesprochen 6 4 2 Integrationsmethodik Nach der Formalisierung der Sprachkonzepte der zu integrierenden Prozessspra chen sowie der Bindungskonzepte k nnen wir aus dem M2 Modell nun eine Methodik f r die Integration einer Prozesssprache mit dem Schnittstellenmodell f r Kontextkomponenten ableiten Das Ziel besteht in der Nutzung der Prozess sprache zur Spezifikation von Abl ufen von Plankontexten 6 4 2 1 berblick Abb 31 gibt einen berblick ber die grunds tzliche Vorgehensweise bei der Integration einer Prozesssprache Das Prozesssprachen M2 Modell und das Bin dungs M2 Modell abstrahieren auf der obersten Ebene von den spezifischen Sprachkonzepten des Schnittstellenmetamodells des Metamodells der zu integrie renden Prozesssprache und d
154. Koordination dom ne Administrations Projekt manager te technischer Entwickler Entwurfs werkzeuge Durchf hrungs dom ne F r den Prozessmodellierer stehen in der Modellierungsdom ne eine Reihe von Werkzeugen f r die Definition und Wartung von Prozessmodellen zur Verf gung siehe Abb 5 Dazu geh ren in der Regel Editoren f r den Entwurf und die Bearbeitung von Prozessmodellen und Analyse Werkzeuge mit deren Hilfe die erstellten Prozessmodelle auf syntaktische Korrektheit und andere statische for male Eigenschaften Vollst ndigkeit Erreichbarkeit von Prozessschritten Typ berpr fungen hin berpr ft werden k nnen Manche PZEUen bieten dar ber hinaus M glichkeiten zur berpr fung dynamischer Aspekte von Prozessmodel len i a durch Simulation sowie des Abgleichs von Prozessmodellen mit abgespei cherten Historien bereits durchgef hrter Prozesse mit dem Ziel der Aufdeckung von Schwachstellen und der Verbesserung der existierenden Prozessmodelle Der Projektmanager interagiert mit einer PZEU in der Regel ber eine Admi nistrationsumgebung die der Leitdom ne zugeordnet wird siehe Abb 5 Zu den wesentlichen Funktionen der Administrationsschnittstelle geh ren die Ressourcen und Aufgabenzuteilung bei der Instanziierung von Prozessmodellen Ein weiterer f r das Projektmanagement wesentlicher Dienst einer PZEU ist das so genannte Prozess Monitoring Darunter versteht man die
155. L96 DeKW99 DeMa79 Demi86 Dene93 Dern94 DGSZ94 DHKLS4 DHTT00 DiGa00 DoBe92 DoD 80 DoD 88 DoFe94 D m 96 D mg99 D0n099 D P098 Dorl93 Doug88 Dows93 Deiters W Herrmann T und Loffeler T Identifikation Klassifikation und Unterst t zung semistrukturierter Teilprozesse in proze orientierten Telekooperationssystemen In Kremar H Lewe H und Schwabe G Hrsg Herausforderung Telekooperation Einsatz erfahrungen und L sungsans tze f r konomische und kologische technische und soziale Fragen unserer Gesellschaft DCSCW 96 Stuttgart Hohenheim Springer Verlag Berlin 1996 S 261 274 Derniame J C Kaba B A und Wastell D Hrsg Software Process Principles Methodology and Technology Springer Verlag Berlin Heidelberg LNCS 1500 1999 DeMarco T Structured Analysis and System Specification Prentice Hall Englewood Cliffs 1979 Deming W E Out of the Crisis Massachusetts Institute of Technology Center for Advanced Engineering Study Cambridge USA 1986 Denert E Dokumentenorientierte Software Entwicklung Informatik Spektrum 16 S 159 164 1993 Derniame J C Life Cycle Process Support in PCIS In Proceedings of the PCTE 94 Conference San Francisco USA 1994 S 65 71 Dinkhoff G Gruhn V Saalmann A und Zielonka M Business Process Modeling in the Workflow Management Environment Leu In Proceedings of
156. MC9I8b Daher bieten Austauschformate in der Regel Mechanismen an mit denen die Konzepte der Zwischensprache erweitert und an die jeweiligen Bed rfnisse angepasst werden k nnen Insgesamt m ssen die zu integrierenden Sprachen jedoch eine weitestgehend mit der Zwischensprache vergleichbare Aus drucksst rke haben um eine Transformation zu erm glichen Die Option Intero perabilit t von Sprachen mit Hilfe eines gemeinsamen Repr sentationsformates bzw eines bersetzungsmechanismus zu erzielen ist aufgrund der schlechten Skalierbarkeit hinsichtlich heterogener Formalismen daher als kritisch zu bewerten GaLK98 Interoperabilit t ber Ein weiterer Ansatz besteht darin die Interoperabilit t ber einen zentralisier zentralisierten Prozess ten Prozesszustand in der Leitdom ne zu erzielen Abschnitt 6 2 2 und Abb 25c ze Im Gegensatz zur statischen Zwischensprache spiegelt der zentralisierte Prozess zustand die dynamische Ausf hrung eines instanziierten Softwareprozesses zur Laufzeit wider Damit ist zwar die Interoperabilit t von Prozessmaschinen in der Leitdom ne gew hrleistet jedoch ist unklar wie die Formalismen in der Modellie rungsdom ne interoperabel verwendet werden k nnen Lediglich die Modifikation des Prozesszustandes d h die Auswirkung der Prozessfragmentinterpretation wird integriert und nicht die Modellierungssprachen selbst Da wir jedoch die Aggregation heterogen spezifizierter Plankontexte gerade auch modelhi
157. Mediator in den Nachrichtenverkehr zwischen den Werkzeugen geschaltet wird und die Abbildung von Notifikationen eines Werkzeugs auf Kommandos anderer Werkzeuge vor nimmt sowie Abl ufe auf Basis expliziter Prozessmodelle steuert Abb 11 rechts Dadurch wird Prozesswissen aus den Werkzeugen in die Prozessmaschine bzw die zugrunde liegenden Prozessmodelle verlagert Wir sprechen bei dieser Anfor derungen von der prozessorientierten Mediation der Werkzenginteraktionen 3 3 3 2 Bewertung existierender Ans tze Zur Unterst tzung von Werkzeuginteraktionen im Kontext von Entwurfsumge bungen existieren eine Reihe von Ans tzen die sich grob in folgende Kategorien einordnen lassen Sche93 O Direkte lokale und oder entfernte Prozeduraufrufe Q Object Request Broker Architekturen Q Message Broadcasting Architekturen QO Mediator Ansatze Im Folgenden stellen wir die grundlegenden Merkmale dieser L sungsans tze vor und bewerten ihre Eignung f r den Einsatz in einer prozessintegrierten Umge bung Dabei folgen direkte Prozeduraufrufe und Object Request Broker Ansatze dem Client Server Paradigma w hrend Message Broadcasting Architekturen dem ereignisbasierten Architekturstil zugerechnet werden k nnen Mediator Ansatze kombinieren die St rken der vorgenannten Architekturen und kommen unserer Zielvorstellung einer prozessorientierten Mediation der Werkzeuginteraktionen am n chsten Direkte Prozeduraufrufe Die grundlegendste und
158. P Tolvanen J P Jarke M Pohl K und Weidenhaupt K CASE Environment Adaptability Bridging the Islands of Automation In March S T und Bubenko J Hrsg Proceedings of the 8th Annual Workshop on Information Technologies and Systems WITS 98 1998 S 115 125 Mattsson M Bosch J und Fayad M Framework Integration Problems Causes Solutions Communications of the ACM 42 10 S 81 87 Oct 1999 Malone T und Crowston K The Interdisciplinary Study of Coordination ACM Comput ing Surveys 26 1 S 87 119 1994 Madhavji N H The Process Cycle Software Engineering Journal 6 5 S 234 242 1991 292 Literaturverzeichnis Maes94 MaFS97 Mart98 Maz 94 MBJK90 McCh95 McPa84 MDEK95 MDKW99 Me Ta97 Meye97 Meye90 Meye91 Micr95 Micr97 Miln89 Mint97 MiSc92 Mont94 M Sc96 MyCN92 Nagl90 Nagl96 Maes P Agents that Reduce Work and Information Overload Communications of the ACM 37 7 S 30 40 1994 Mark G Fuchs L und Sohlenkamp M Supporting Groupware Conventions through Contextual Awareness In Prinz W Rodden T Hughes H und Schmidt K Hrsg Proceedings of the Fifth European Conference on Computer Supported Coopera tive Work ECSCW 97 Lancaster UK Kluwer Academic Publishers 1997 S 253 268 Marttiin P Customisable Process Modeling Support and Tools for Design Environment Dissertati
159. P und Dr schel W Hrsg Das V Modell Oldenbourg Verlag M nchen Wien 1995 Breitbart Y Deacon A Schek H J Sheth A und Weikum G Merging Applica tion centric and Data centric Approaches to Support Transaction oriented Multi system Work flows ACM SIGMOD Record 22 3 S 23 30 1993 Brown A Earl A und McDermid J Software Engineering Environments Automated Support for Software Engineering McGraw Hill 1992 Brown A Earl A und Wallnau K Past and Future Models of CASE Integration In Proc 5th Intl Workshop on CASE CASE 92 Montreal Canada July 1992 S 36 45 Brown A und Feiler P An Analysis Technique for Examining Integration in a Project Support Environment In Proceedings of the Fifth ACM SIGSOFT Symposium on Software Development Environments Washington DC USA 1992 S 139 148 Brinkkemper S Method engineering engineering of information systems development methods and tools Information and Software Technology 38 4 S 275 280 1996 Brinkkemper S Lyytinen K und Welke R Hrsg Method Engineering Principles of Method Construction and Tool Support Chapman amp Hall 1996 Brown A und McDermid J On integration and reuse in a software development environ ment In Long F Hrsg Software Engineering Environments Ellis Horwood 1991 S 171 194 Brown A Carney D J Mortis E Smith D und Zarrella P Principles of CASE Tool Integration Oxford Un
160. PEM Frameworks ccccccccscesseesteesteceteenteeneees 235 7 5 2 Beschreibung der wiederverwendbaren Klassen eee 236 1 3 2 1 Sprachliche Klasse Narn erat eona a EEE en ea 236 19 22 Technische Klassen sen a anerkennen ann 238 7 5 2 3 Integration einer neuen Sprache eneneneneenneeenneennnennnnen 239 T gt Konttollmodell 22 0 28 8l netz cken nina 240 7 5 3 1 Ausf hrungsmodell von Kontextkomponenten nneee 240 7 5 4 Verwandte Ans tze eeaeee ne aene AEE a E Eaa a aoa raisates 244 7 35 LUSAMIMENLASSUN genai a a a i 245 7 6 1 EVA i PENNA EAE E AEE EE 245 8 ANWENDUNGEN rer nennen ernennen nennen een 247 8 1 Entwicklungshistorie escsossssoossssnnssnonnesnnssesnnnsnsnnnsnnnnennssssnnnsnsnnnsnnnne 247 8 2 PRIME IMPROYVE ui speak 250 8 2 1 berblick ber SPBIMPROVE u a 250 8 2 2 Werkzeuge der PRIME IMPROVE Umgebung nennen 251 8 2 2 1 Stellung des Flie bilds im Gesamtprozess een 251 8 2 2 2 Anforderungen an das Flie bildwerkzeug e 252 8 2 23 Realisierung 2 eeo re A E AR TAG 254 8 2 3 Positionierung von PRIME IMPROVE im SFB Prototypen 08 258 8 3 Beis piel sit Zune ccccecccsscnssscccssedessesendsdscssseedvccnsededsosocevaccesscessseSeobaoceeacesnsads 259 Inhaltsverzeichnis 8 3 1 Definition eines Prozessfragments unssenneeneeneneeeneennennneennn nenne 259 8 3 1 1 Ziel der
161. PRIME Umgebung z B der Abh ngigkeitseditor und der Produktmodelleditor als so genannte Singleton Werkzeuge deklariert wurden d h es kann von diesen Werkzeugen zu einem Zeitpunkt nicht mehr als eine Instanz dieser Kategorie geben In diesen F llen ist die Ad ressierungsart newTool unzul ssig U scope ProductID bei dieser Adressierungsart wird die Werkzeuginstanz ber einen produktbezogenen G ltigkeitsbereich Scope ermittelt Diese Adressierungsart kann als objektorientierte Adressierung betrachtet wer den F r jede Werkzeuginstanz f hrt der Kommunikationsmanager Buch dar ber welche Produktinstanz die Werkzeuginstanz gerade geladen hat Beispielsweise w rde in Abb 49 die ContextRequest Nachricht bei sco pe p an die Werkzeuginstanz w weitergeleitet Falls aktuell noch keine Werkzeuginstanz mit dem gew nschten G ltigkeitsbereich aktiv ist startet der Kommunikationsmanager zuvor eine neue Instanz mit der ent sprechenden Produktinstanz Mit den hier beschriebenen ogischen Adressierungsarten erreichen wir eine flexible Adressierung von Werkzeuginstanzen die sich in der Praxis f r die nahezu alle Modellierungssituationen als hinreichend pr zise erwiesen hat Die Vorteile der strikten Trennung zwischen logischen Kontextanforderungen und den eigentli chen Erbringern einer Kontextanforderung die auf Architekturebene durch den Kommunikationsmanager und das Umgebungsmodell verk rpert wird bleiben dennoch erhalten da der Pr
162. Plankontext Ausf hrung ruft die Prozessmaschine mithilfe einer ContextRequest Nachricht einen Entscheidungs oder Ausf hrungskontext c bei den Werkzeugen auf Der Kommunikationsmanager ermittelt zun chst anhand der Zuordnung im Umgebungsmodell die f r die Ausf hrung von c zust ndige Werkzeugkategorie hier Werkzeugkategorie A siehe Abb 49 In der Tabelle der aktuell laufenden Werkzeuginstanzen schl gt der Kommunikationsmanager nach ob bereits eine Instanz der entsprechenden Kategorie aktiv ist hier w und w In der Grundeinstellung leitet der Kommunikationsmanager die ContextRequest 27 Tats chlich haben wir in einer fr hen PRIME Version mit der hier beschriebene Alternativl sung experimentiert Es stellte sich allerdings heraus dass die zus tzlich erforderliche Netzwerk kommunikation mit dem Kommunikationsmanager zu mitunter st renden Verz gerungen bei der werkzeuginternen Kontextaktivierung f hrte Mittlerweile verf gen wir jedoch ber eine signifikant effizientere Implementierung der dem Nachrichtenprotokoll zugrunde liegenden Transportschicht so dass Performance Gesichtspunkte nur noch eine untergeordnete Rolle spielen d rften und eine Umstellung auf die beschriebene Alternativl sung durchaus sinnvoll erscheint 7 2 Interaktionsprotokoll zwischen den Prozessdomanen 193 Nachricht an die erste gefundene Instanz hier w weiter und bermittelt die Resultate der Kontextausf hrung zur ck an die Prozessmaschi
163. Prozessfragments in der Leitdom ne anst t Da der Vorrat an definierten Prozessfragmenten in der Modellierungsdom ne sich mit der Zeit ndert darf die Erkennung und Darstellung anwendbarer Pro zessfragmente nicht in den Werkzeugen hartkodiert werden Daher m ssen die Werkzeuge auf die aktuellen Prozessdefinitionen zugreifen k nnen und ber eine entsprechend flexible Kommandoverwaltung z B erweiterbare Men strukturen verf gen 3 3 7 2 Bewertung existierender Ans tze Die Integrationsstrategien in existierenden prozesszentrierten Umgebung und Wokflow Managementsystemen sehen f r die dort eingebundenen Werkzeuge und Applikationen keine aktive Rolle bei der Aktivierung von Prozessfragmenten vor Vielmehr l uft die Interaktion zwischen der Leitdom ne Prozessmaschine und der Durchf hrungsdom ne Werkzeuge in der Regel nach dem Client Server Prinzip ab Hierbei haben die Werkzeuge als reine Diensterbringer keinerlei Kenntnis der Prozessdefinitionen und des aktuellen Zustands der Prozessmo dellausf hrung und k nnen folglich auch nicht die Ausf hrung von Prozessfrag menten initiieren Stattdessen erfolgt die Aktivierung von Teilprozessen entweder explizit durch den Benutzer ber spezielle Benutzerschnittstellen Agenda Mana ger Arbeitskontexte o oder implizit durch das bereits in Abschnitt 3 3 5 disku tierte Abhorchen von Ereignissen in der Durchf hrungsdom ne wie z B in Pro vence und SPADE Die WfMC sieht in ihre
164. Prozessmaschine Gem der Anforderung A6 Werkzeugunter st tzter Aufruf von Prozessfragmenten siehe Abschnitt 3 3 7 m ssen je doch Anleitungsdienste aus den Werkzeugen der Durchf hrungsdom ne aktiviert werden k nnen Als Beispiel f r einen Anleitungsdienst sei das Prozessfragment Spezialisierung eines Entit tstypen angef hrt das aus einer Abfolge mehrerer Schritte in unterschiedlichen Werkzeugen besteht Nach Aktivierung dieses Prozessfragments im ER Editor lenkt und kon trolliert die Prozessmaschine die Durchf hrung des Spezialisierungsvor gangs gem der im Prozessmodell definierten Ablaufdefinition Zusammenfassend l sst sich feststellen dass Informationen ber den Anwen dungskontext von Diensten sowie das Wissen ber Vorgehensauswahlen Bera tungsdienste und ber Schrittfolgen Anleitungsdienste Kernelemente des Pro zessmetamodells darstellen Zus tzlich werden im Prozessmodell elementare Dienste als atomare Prozessschritte referenziert Somit muss das Prozessmetamo dell alle drei Diensttypen geeignet repr sentieren k nnen Das Werkzeugmetamo dell muss geeignete Konzepte f r die Modellierung der Werkzeugfunktionalit ten bereitstellen Dies bezieht sich zum einen auf die elementaren Dienste aber auch auf die Modellierung der Interaktionsm glichkeiten bei der Operationalisierung von Beratungsdiensten 5 3 Modellierung von Prozessfragmenten 113 5 3 Modellierung von Prozessfragmenten 5 3 1 Ziele
165. Prozesstypen steuern je nach Kontextart die Kommunikation mit der Durchf hrungsdom ne f r die Aktivierung eines Ausf hrungs oder Entscheidungskontexts oder starten eine weitere Interpreterinstanz Die Schnittstelle der Process Klasse bietet daher Funktionalit t hinsichtlich der Prozessausf hrung an die das Starten Suspendieren oder Abbrechen des Prozesses steuert Prozesse stehen in einer Aufrufhierarchie da die Ausf hrung eines Prozesses zu weiteren Subprozessen f hren kann W hrend der Interpreta tion eines Plankontextes werden sukzessive Kontexte deduziert die dutch ent sprechende Process Instanzen operationalisiert werden Die Klasse PC_Process als Interpreter eines Prozessfragments ist daher der Aufrufer von weiteren SubPro zessen 7 5 2 3 Integration einer neuen Sprache Die Integration einer Sprache erfolgt indem die sprachlichen und technischen Klassen spezialisiert und die spezialisierten Sprachelemente durch berladen von Methoden ggf angepasst werden Die in Abb 65 und Abb 66 dargestellten Me thoden stellen einen Auszug aus den Variationspunkten der Sprachelemente dar 240 7 Das PRIME Rahmenwerk Die dort dargestellten Basisklassen realisieren bereits ein standardisiertes Verhal ten welches bei der Integration wiederverwendet oder angepasst wird Uber diese Variationspunkte hinaus realisieren die Klassen den Anschluss an die Schnittstel lenschicht der bei der Integration einer Sprache bzw eines Interp
166. Prozessunterst tzung cneensennseeneeneenneenneeennnennen nenne 259 8 3 1 2 Prozessmodellierung u unennenneeennenneenennnnennnnnnennnennn nenne 260 8 3 1 3 Werkzeugmodellierung uusseserseenseeesnensnensnnnnnnnnnennen nennen 264 8 3 2 Ausf hrung eines Prozessfragments ccnenenneeneneennennnnnnnnnnnn ne 264 8 3 3 Zusammenfassung niinn i e A E essen ns sn nen 269 8 4 VA ENTALTEN 270 9 _SCHLUSSBETRACHTUNGEN 4444044RRnn nun nn 271 91 Beitr ge der Arbeit secscocerssnsesonessonenssnn eesnuessnennnnnnssnnnensnnennnersennsssunneeneen 271 9 2 Erfahrungen und kritische Bewertung cccsccscscsscsesesseecsscseseeees 273 9 2 1 Sicht des Anwenders senbeissnsniben din 273 9 2 2 Sicht des MethodeningeniculS cuennsseessnessnnneennennennnnnnennne nennen 274 9 2 3 Sicht des Umgebungsentwicklers sensennseenseennennnennenne nennen 274 9 3 Ausblick E E E E 275 xi Teil 1 Einordnung der Arbeit 1 Teil 1 Einordnung der Arbeit 1 1 Motivation und Problembeschreibung 3 Kapitel Einleitung 1 1 Motivation und Problembeschreibung Die Entwicklung technischer Systeme sieht sich mit wachsenden Herausforderun gen konfrontiert Sowohl bei der Software Entwicklung als auch in klassischen ingenieurwissenschaftlichen Disziplinen Maschinenbau Verfahrenstechnik Elekt rotechnik etc zwingt der mit der allgemeinen Globalisierung immens gestiegene Konkurrenzdruck die
167. S sind quivalent situation S with situation S with re Th hee Vast of Ve dpe Fe Te end end Ziel des Algorithmus BindeSituation ist es die m Situationsteile r von so an Produktinstanzen binden dass die Typbedingungen und die min und max Kardi nalit ten der Situationsteile erf llt sind und dass jede Produktinstanz genau einem Situationsteil zugeordnet wird Eingabe pons es Re orithmus S Situationstyp der folgenden Form RE situation S with r list min max T rm list Minn MaXm Tm 1 end P py Pn Menge von Produktinstanzen Ausgabe Situationsinstanz 7 8 Fm Sn falls Bindung erfolgreich false falls keine Bindung m glich Algorithmus Vorbereitungsphase Sortiere die Situationsteile 77 7m zu Fi gt Fi so dass gilt 216 7 Das PRIME Rahmenwerk 1 V kl e 1 m k lt l Ti lt Ti oder Ti und T stehen nicht in einer Spezialisierungsbeziehung d h Situationsteile mit spezielleren Produktty pen werden nach vorne sortiert 2 V kle 1 m kl T gt i lt i d h die Reihenfolge von Situationsteilen mit gleichem Produkttypen bleibt in der Umsortierung erhalten Phase 1 Bedienung der min Anforderungen jedes Situationsteils forall r 1 lt k lt m do Liste von Produktinstanzen passenden Typs in P zusammenstellen P peP Typ p Ti if P lt min return false else Sortierung gem Einordnu
168. Schnittstellenbeschreibung nicht von Belang sind Eine Kontextkomponente aggregiert genau eine Situations komponente und eine Verhaltenskomponente Je nach Kategorie der an einer Kontextkomponente beteiligten Verhaltenkomponente unterscheiden wir die Klassen Ausf hrungskontextkomponente kurz AK Komponente Entschei dungskontextkomponente kurz EK Komponente und Plankontextkomponente kurz PK Komponente als Spezialisierung der Klasse Kontextkomponente in Abb 28 nicht explizit dargestellt Abb 28 s Ausgang f Schnittstellenmetamodell eee E a Prozesskomponente en mr yy 2 IN Eingang Rolle Situationskomponente 1 m De Kontextkomponente i Produktteil 1 x 5 nf 1 Ber Verhaltenskomponente Verhalten in 1 4 5 1 Ni L 1 an a 4 LA er Typ Kopplung lt gt 4 Situation out PK_Verhaltenskomponente EK_Verhaltenskomponente AK_Verhaltenskomponente Bei der Verkn pfung einer Situations mit einer Verhaltenskomponente wird eine Zuordnung zwischen den Out Produktteilen der Situationskomponente und den In Produktteilen der Verhaltenskomponente mithilfe der Klasse Kopplung defi niert Die bereits oben informell skizzierten Konsistenzbedingungen die f r eine korrekte Kopplung gelten m ssen k nnen wir nun als O Telos Integrit tsbedin gungen formalisieren 6 3 Komponente
169. Semantik der Daten impliziert da der weitere Ablauf der Prozessmodellausf hrung sich h ufig erst aus der Kenntnis und Interpretation der Daten ergibt die von einem Werkzeug als Ergebnis eines Bearbeitungsschritts an die Prozessmaschine zur ckgemeldet werden Datenkonsistenz Ein zweites wesentliches Ziel der Datenintegration ist neben der reinen Dateninte roperabilitat die Gew hrleistung von Datenkonsistenz ber Werkzeuggrenzen hinweg Zwischen den Daten auf denen unterschiedliche Werkzeuge arbeiten existieren in einer integrierten Umgebung im Allgemeinen vielf ltige Abh ngig keiten Diese Abh ngigkeiten k nnen zum einen physischer Natur sein wenn z B zwei Werkzeuge auf der gleichen Datenablage operieren Logische Abh ngigkeiten ergeben sich wenn zwischen den Daten unterschiedlicher Werkzeuge inhaltliche Querbez ge existieren Als einfaches Beispiel betrachten wir logische Datenabh n gigkeiten innerhalb einer UML Werkzeugumgebung wenn in dem von einem Klassendiagramm Editor verwalteten Klassenmodell der Name einer Klasse ge n dert wird muss diese nderung im korrespondierenden Zustandsdiagramm des Verhaltenseditors nachgezogen werden Neben solchen formal modellierbaren strukturellen Abh ngigkeiten zwischen verschiedenen Produktdaten werden durch den Entwicklungsprozess auch weiche Abh ngigkeiten induziert z B zwischen einer als Flie text notierten Anforderungsspezifikation und einem darauf basie renden Klassenmod
170. StateDriver Klassen gewinnen zus tzliche Flexibilit t dadurch dass die Topologie des Zustands Transitionsgraphen auch noch nach der Initialisierung ber entsprechende Methoden Hinzuf gen oder Entfernen von CsttState und CsttTransition Objekten Ver ndern der Verkn pfung zwischen CsttState und CsttTransition Objekten modifiziert werden kann Damit k nnen nderungen des globalen Werkzeugverhalten auf sehr einfache Weise und bei Bedarf sogar dynamisch d h zur Laufzeit adaptiert werden In D mg99 wird beispielsweise eine Erweiterung des Zustandsprotokolls um zus tzliche Interaktionen mit einem Filtermechanismus f r Nachvollziehbarkeitsinformationen beschrieben die auf Architekturebene sehr einfach und an einer Stelle zentralisiert durch Hinzuf gen Dynamische Protokoll anpassungen zur Laufzeit 204 Ereignisverwaltung 7 Das PRIME Rahmenwerk von Objekten einiger neuer CsttState und CsttTransition Objekte zum CsttToolStateDriver umgesetzt werden konnte Die Funktionsweise der CsttStateDriver Klasse ist ereignisgesteuert so dass diese Klasse eng mit dem Event Teilsystem Klassenpr fix Cevt zusammenarbei tet Ereignisse werden entweder durch den Empfang von Nachrichten aus der Leitdom ne im Teilsystem MessageInterface oder durch Benutzerinteraktionen Objekt und Kommandoselektionen im Teilsystem GenericGUI ausgel st Diese Ereignisse werden durch entsprechende EventHandler Objekte CevtMessage EventHandler C
171. TH Aachen Verlag Shaker 1995 Lehmann M M Process Models Process Programs Programming Support In Proc 9th Intl Conf on Software Engineering Monterey California USA 1987 S 14 16 Lehmann M M Software Engineering the Software Process and Their Support Software Engineering Journal Sept 1991 Lee J und Yost G The PIF Process Interchange Format and Framework Tech Report PIF Working Group 1994 Lie mann H Kaufmann Th und Schmitzer B Bussysteme als Schl ssel zur betriebs wirtschaftlich semantischen Kopplung von Anwendungssystemen Wirtschaftsinformatik 41 1 S 12 19 Jan 1999 Lohmann B Verfahrenstechnische Modellierungsabl nfe Dissertation RWTH Aachen VDI Verlag D sseldorf Fortschritts Berichte VDI Reihe 3 Nr 531 1998 Lonchamp J An Assessment Exercise In Finkelstein A Kramer J und Nuseibeh B Hrsg Software Process Modelling and Technology RSP by John Wiley amp Sons 1994 S 335 356 Lott Ch Process and Measurement Support in SEEs ACM SIGSOFT Software Engi neering Notes 18 4 S 83 93 1993 Luckham D Kenney J Augustin L Vera J Bryan D und Mann W Specification and Analysis of System Architecture using Rapide IEEE Transactions on Software Engi neering 21 4 S 336 355 1995 Lyytinen K und Welke R Hrsg Special Issue on Meta Modelling and Methodology Engineering Information Systems 24 2 S 67 69 1999 Lyytinen K Marttiin
172. Trennung Es wird jedoch noch nicht ber die appara tetechnische Realisierung eines Funktionselements entschieden In der grafischen Darstellung verwendet man rechteckige K sten f r die Funktionen und Grund operationen und gerichtete Kanten f r die verbindenden Stoffstr me 48 Dar ber hinaus existiert das Rohr und Instrumentenflie bild das jedoch erst zur detaillierten Ausle gung der Anlagenelemente und zur Spezifikation regelungstechnischer Sachverhalte eingesetzt wird und somit innerhalb der vom SFB betrachteten fr hen Entwurfsphase nur eine nachgeordnete Rolle spielt 8 2 PRIME IMPROVE 253 Das Verfahrensflie bild dient der Darstellung der verfahrenstechnischen An lage auf der Ger teebene Teilfunktionen der Funktionsstruktur werden durch geeignete Apparate und Maschinen realisiert in denen chemische physikalische oder biologische Wirkungsabl ufe stattfinden In der grafischen Darstellung wer den abstrahierte Symbole der f r die Realisierung vorgesehenen Ger te verwendet Abb 71 illustriert die schrittweise Ausgestaltung der VT Prozessstruktur bis hin zur groben anlagentechnischen Umsetzung Der initiale V T Prozess wird zu n chst um eine R ckf hrung von Stoffstr men angereichert und dann in die Teil funktionen VT Process Steps Reaktion und Trennung zerlegt Die Trennung wird spezialisiert in die Grundoperation Unit Operation Fl ssigtrennung die auf der funktionalen Ebene nicht weiter verfeinert wird Umges
173. UI und T Actions realisiert Das Paket T Model liefert eine objektorientierte Zugriffsschicht auf das logische Produktmodell auf dem ein Werkzeug operiert Die Persistierung des Produktmodells im Prozessrepository erfolgt mithilfe werkzeugspezifischer Anfrage und Updateklassen aus dem Paket T DBInterface Diese Klassen sind Spezialisierungen allgemeiner Datenbankklas sen im Paket GenericDBInterface die vom Datenmodell und den Besonderheiten der Klient APIs des zugrunde liegenden Datenbankmanagementsystems abstrahie ren Das Teilsystem T_GUI stellt die f r die Pr sentation erforderlichen Benutzer oberfl chenkomponenten bereit Eine wichtige Entwurfsentscheidung des GAR PIT Frameworks besteht somit in der strikten Trennung zwischen den beiden Paketen T Model und T GUI Dadurch bleibt das logische Produktmodell stabil gegen ber nderungen in der externen Pr sentation oder dem Austausch des verwendeten GUI Toolkits 2 Das Pr fix T steht hier f r ein beliebiges Werkzeug In einem konkreten Werkzeug wird dieses K rzel durch den entsprechenden Werkzeugnamen ersetzt 7 3 GARPIT ein Framework fur prozessintegrierte Werkzeuge 199 GARPIT gt lt lt import gt gt gt lt lt specialize gt gt 2 gt lt lt callback gt gt Abb 50 Architektur des GARPIT Frameworks Context Manager T_Actions
174. Werkzeu gen auf hnliche Weise ber die Einbettung von CoShell Prozeduren in Prozess fragmente CoShell Prozeduren werden in einer an UNIX Shellsprachen ange lehnten Sprache spezifiziert welche ber zus tzliche Bibliotheksfunktionen zum Empfang und Absenden von Nachrichten von bzw an einen Message Server verf gt Mithilfe solcher Mechanismen k nnen Werkzeuge im Vergleich zur reinen Blackbox Integration zwar auf der Ebene individueller Werkzeugdienste integriert werden Bei der Modellierung von Prozessfragmenten steht dem Prozessmodellie rer jedoch kein konzeptuelles Modell der vorhandenen Werkzeugdienste zur Ver f gung Vielmehr koexistieren Prozessbeschreibung in der Modellierungsdom ne z B SLANG Netze und Werkzeugbeschreibungen der zugrunde liegenden Kon trollintegrationsinfrastrukturen z B Message Server Repositories wumnintegriert nebeneinander Das einzige Bindeglied stellen ausprogrammierte Wrapper z B Send Message bei SPADE SLANG oder CoShell Skripte in ProcessWeaver dar Genau wie bei Blackbox Ans tzen geschieht die modellierungsseitige Einbindung von Werkzeugen also ad hoc 3 3 Integrationsanforderungen in prozessintegrierten Umgebungen 93 Werkzeuggenerierung In den bislang diskutierten Ans tzen dienen Schnittstellenbeschreibungen von Werkzeugdiensten lediglich als Grundlage f r die Referenzierung von Dienstaufru fen in Prozessmodellen und deren Bindung an Dienstimplementierungen die von Werkzeugentwicklern
175. Werkzeug bzw die Prozessmaschine die Daten eines anderen Werkzeugs als uninterpretierten Zeichenstrom lesen kann Integrations ma nahmen auf der Tr gerstufe erfordern beispielsweise die Konversion einer Zeichencodierung z B ASCII in eine andere z B UNICODE O Lexikalische Stufe lexical evel Hier herrscht bei den zu integrierenden Werkzeugen ein gemeinsames Verst ndnis ber die grundlegenden lexikali schen Einheiten Ein Beispiel f r Integration auf der lexikalischen Stufe stellen die fr hen Unix Werkzeuge tbl eqn und pic dar die in der Do cumenter s Workbench AT amp T84 zusammengefasst sind Bei diesen Werkzeugen ist zum Beispiel per Konvention festgelegt dass Formatie rungsanweisungen durch einen eingeleitet werden O Syntaktische Stufe syntactical level Auf der syntaktischen Stufe verf gen die zu integrierenden Werkzeuge ber ein gemeinsames Verst ndnis der verwendeten Datenstrukturen bzw der Regeln nach denen die Daten strukturen gebildet werden Offensichtliche Beispiele f r diese Integrati onsstufe finden sich zum Beispiel in eng integrierten Programmierumge bungen z B ReTe81 HaN086 in denen die einzelnen Werkzeuge syn taxgesteuerte Editoren Compiler Debugger auf einheitlichen internen Datenstrukturen Symboltabelle abstrakter Syntaxbaum aufsetzen O Semantische Stufe semantical level Diese Ebene setzt voraus dass die zu integrierenden Werkzeuge nicht nur gemeinsamen Konventionen
176. Werkzeugumgebung aufweisen Die Grundidee prozesszentrierter Umgebung n mlich die Erfassung von Pro zesswissen in expliziten Prozessmodellen bildet also den Ausgangspunkt f r unser L sungskonzept Darauf aufbauend liegt der Hauptbeitrag von Kapitel 3 in der Herleitung von sechs zentralen Integrationsanforderungen die den bergang von einer prozesszentrierten za einer prozessintegrierten Entwicklungsumgebung charakterisie ren In einem breiten Literatur berblick diskutieren und bewerten wir zu jeder die Mangelnde Integrationstiefe in prozesszentrierten Umgebungen 6 1 Einleitung ser Anforderungen existierende Integrationsansatze aus den Bereichen Prozess modellierung Datenintegration Kommunikationsinfrastrukturen komponenten basierte Softwareentwicklung Werkzeugspezifikation Benutzeroberfl chen und Softwareergonomie Der Vergleich ergibt dass zu Teilproblemen zwar L sungsan s tze vorliegen die jedoch noch nicht zu einer integrierten Gesamtl sung zusam mengef hrt worden sind L sungskonzept Integrierte Prozess und Werkzeugmodellierung Kapitel 4 gibt einen kurzen berblick ber den von uns gew hlten L sungsansatz der auf der Grundidee beruht Wissen ber Prozesse und Werkzeuge gleichberech tigt in konzeptuellen Modellen explizit zu erfassen und diese Modelle miteinander zu verzahnen Die modellierungsseitigen Grundlagen werden in Kapitel 5 geschaffen Wir er weitern ein existierendes Rahmenmodell f r die
177. ability Research Studies Press 1997 S 265 302 Jeusfeld M A nderungskontrolle in deduktiven Objektbanken Dissertation Universit t Passau 1992 290 Literaturverzeichnis JPRS94 PSW94 RSD99 KaRo74 Katz90 Kel 98 KeLR95 Kelt93 KeM093 KeRi84 KeSm96 Kipe94 KiSW95 KiRB91 Klam95 Kobr99 Koch93 KoKo84 KoM695 Kr m97 KrMa97 Jarke M Pohl K Rolland C und Schmitt J R Experience Based Method Evaluation and Improvement A Process Modeling Approach In Proceedings of the IFIP 8 1 CRIS94 Working Conference Methods and Associated Tools for the Informations Systems Life Cycle Maastricht Netherlands 1994 S 1 27 Junkermann G Peuschel B Schafer W und Wolf St MERLIN Supporting Cooperation in Software Development through a Knowledge Based Environment In Finkelstein A Kramer J und Nuseibeh B Hrsg Software Process Modelling and Technolo gy Research Studies Press 1994 S 103 130 Jarke M Rolland C Sutcliffe A und Domges R Hrsg The NATURE of Requirements Engineering Shaker Verlag Aachen 1999 Kast F E und Rosenzweig J E Organization and Management A Systems Approach McGraw Hill 1974 Katz R H Towards a Unified Framework for Version Modeling in Engineering Databases ACM Computing Surveys 22 4 S 375 408 1990 Kellner M Becker Kornstaedt U Riddle W Tomal J und Verlage M Process Gui
178. agramm aus Abb 45 auf die Interaktion des Prozessmaschinen Frameworks mit der Durchf hrungsdom ne fokussiert ist die Prozessmaschinen inrerne Interaktion zwischen dem Framework und den einzelnen Interpreter Threads hier nicht von Bedeutung Wir gehen auf diesen Aspekt in Abschnitt 7 5 bei der Beschreibung des Prozessmaschinen Frameworks noch genauer ein 7 2 Interaktionsprotokoll zwischen den Prozessdomanen 189 Zustand Deducing Context tiber Transition 5 Dabei wird das Ergebnis der Kontextausf hrung result an die Plankontext Interpretation bergeben Nach Beendigung des obersten Plankontexts innerhalb der Plankontext Aufrufhierarchie schickt die Prozessmaschine eine EndOfEnactment Notifikation an die Werkzeuge der Durchf hrungsdom ne und kehrt in den Zustand Process Enactment Inactive zur ck Sollte es im Zustand Running zu einer internen Fehlersituation kommen geht die Prozessmaschine in den Zustand Exception Handling ber Transition 7 In diesem Zustand kann eine Fehlerbehandlung erfolgen Falls der Fehler behoben werden kann kehrt die Prozessmaschine in den Zustand Deducing Context zur ck Transition 8 um den n chsten ausf hrbaren Kontext zu ermitteln Andernfalls wird die Plankontext Ausf hrung abgebrochen und die Werkzeuge durch eine EndOfEnactment Nachricht vom Abbruch des Plankontexts informiert Transi tion 9 Tab 11 Zustand Aktivit t Detailspezifikation der Process Enactment Inac
179. aktuell anwendbaren Ar beitsschritte informiert und kann die Ergebnisse von Aktionen Ausf hrungskon texte oder seine Auswahl unter mehreren m glichen Alternativen Entschei dungskontexte an die Prozessmaschine zur ckmelden Der automatisierte Aufruf von Aktionen oder die unmittelbare Anpassung der Interaktionsm glichkeiten in Aspen Plus ist so jedoch nicht m glich Bei Microsoft Excel haben wir die Prozessmaschinen gesteuerte Aktivierang Microsoft Excel von feingranularen Aktionen betrachtet also Prozessintegration auf der Ebene en a x 5 l i er Ebene von Ausf h von Ausf hrungskontexten ber die APIs A1 und A2 Diese Beschr nkung ergab un gskontexten sich prim r aus einer Analyse der in Excel zu unterst tzenden Arbeitsabl ufe In 232 Visio vollst ndige Prozessintegration 7 Das PRIME Rahmenwerk den von uns betrachteten Anwendungsszenarien wird aus den Daten eines Flie bildmodells eine Excel Tabelle f r die Berechung von Massenbilanzen und Kosten erstellt Dieser Vorgang wird mithilfe eines Plankontexts automatisiert der die als Ausf hrungskontexte modellierten Excel Funktionalit ten z B Einf gen eines Wertes oder einer Formel in eine Tabellenzelle ansteuert Nach der automatisier ten Erstellung der Tabellen finden in Excel selbst jedoch keine prozessrelevanten Abl ufe mehr statt so dass eine Anpassung der Interaktionsm glichkeiten in diesem Werkzeug nicht erforderlich war Wir wollen jedoch betonen
180. aktuellen Situationsinstanz geh renden Produktteile hervorgehoben werden Analog zur Ausf hrung von Aktio nen operiert der ContextExecutor nicht direkt auf werkzeugspezifischen Benut zeroberfl chen Objekten sondern ber die Klassen CmapObjectTable und CmapIn tentionTable die eine Indirektion zwischen dem generischen Teilsystem Context Manager und dem werkzeugspezifischen Teilsystem T_GUI herstellen Dadurch k nnen die ContextManager Klassen ausschlie lich ber Prozessmodell IDs auf Produkten und Kommandoelementen arbeiten ohne die werkzeugspezifischen Klassen kennen zu m ssen Die IntentionTable repr sentiert die Menge aller Kommandoelemente eines Werkzeugs und besteht aus Eintr gen der folgenden Struktur ID der Intention Prozessmodell Zeiger auf assoziierte Kommando Aktivierbarkeitsstatus Tab 12 elemente im Teilsystem T_GUI aktivierbar deaktiviert Struktur der IntentionTable Die IntentionTable Eintr ge Instanzen der Klassen CmapCommandDesc assoziie ren also die Prozessmodell ID einer Intention mit den im Umgebungsmodell definierten Kommandoelement Objekten Men punkte Toolbar Icons Shortkey Bindings und dem aktuellen Aktivierbarkeitsstatus Der ContextExecutor aktiviert mithilfe der IntentionTable Methode enableIntention IntentionID alle Inten tionen die zu Alternativen des aktuellen Entscheidungskontexts geh ren und deaktiviert mithilfe der Methode disableIntention Int
181. alb einer MTP Spezifika tion definiert Ans tze wie SEL MTP legen somit zwar die Schnittstellen von Werkzeug WfMC Standards Wrappern f r die Prozessmodellierung offen unterst tzen aber lediglich die Blackbox Integration von Werkzeugen Auch die Workflow Management Coali tion WfMC ein hersteller bergreifendes Gremium das Standards f r die Inter operabilitat von Workflow Managementsystemen vorantreibt beschr nkt sich auf die Blackbox Integration von Werkzeugen Die W MC hat in der Workflow Mana gement API Interface 2 amp amp 3 Specification WFMC98a Schnittstellen f r den Informati onsaustausch zwischen Komponenten eines WFMS insbesondere Prozessma schine und Agenda Werkzeuge einerseits und externen Applikationen andererseits festgelegt hnlich der Integrationsstrategie des oben beschriebenen SEL MTP Ansatzes geht die WfMC davon aus dass die Prozessmaschine nicht direkt auf externe Applikationen zugreift sondern ber Wrapper die in der WfMC Termi nologie als Too Agents bezeichnet werden Die Hauptaufgabe der Tool Agents besteht in der Abstraktion von unterschiedlichen Aufrufmechanismen Komman dozeile RPC CORBA etc f r die einzubindenden Applikationen siehe Abb 17 Workflow System Abb 17 Prozessmaschine und oder WFMC Schnittstellen Zur Agenda Werkzeug Applikationsintegration a es I Standardisierte APIs Tool Agents unterschied liche Aufruf mechanismen Workflow enabled Invoked Applicat
182. alekts SLANG BaFG93 Schritt 1 Identifikation der M2 Konzepte im SLANG Metamodell Im ersten Schritt wird ein Metamodell der zu integrierenden Sprache SLANG erstellt und als Instanz des PSM2 Modells dargestellt F r unsere Zwecke gen gt dazu ein vereinfachtes Metamodell welches fortgeschrittene Sprachmittel z B die reflexiven Eigenschaften von SLANG zur Laufzeit Modifikation von Aktivit ts netzen vernachl ssigt siehe Abb 32 Eine SLANG Aktivit t besteht aus Stellen und Transitionen die ber Kan ten miteinander verbunden sind Dabei werden die Eingangsstellen zum Vorbe reich und Ausgangsstellen zum Nachbereich einer Transition zusammengefasst Im Allgemeinen folgen SLANG Aktivit tsnetze der Petrinetzsemantik wobei die Sprache dar ber hinaus ein W chter und ein Aktions Konzept anbietet Weiterhin k nnen SLANG Aktivit tsnetze in Subaktivit ten dekomponiert werden Gem Schritt 1 der oben skizzierten Integrationsmethodik k nnen die von der Sprache SLANG bereitgestellten Konzepte wie in Abb 32 dargestellt als PSM2 Konzepte instanziiert werden Als zentrales Aktivit tskonzept finden wir 21 Eine analoge Anwendung der Integrationsmethodik f r UML Zustandsdiagramme kann aus Platzgr nden an dieser Stelle nicht eingehend dargestellt werden Hier sei f r eine detaillierte Darstellung auf Schm99 verwiesen 6 4 Schnittstellenbindung 159 die SLANG Aktivitat die in Form einer Transition entweder eine atomare Akti
183. alen Programmiersprachen hneln ansonsten aber in der Regel nur einen sehr geringen Sprachumfang aufweisen Dies gilt insbesondere f r die M glichkeit komplexe Datenstrukturen definieren zu k n nen da ja m glichst auf vorhandene Komponenten und deren Funktionalit ten zur ckgegriffen werden soll Typisierte Variablen und Referenzen fehlen entweder ganz oder es ist bestenfalls eine dynamische Typpr fung vorgesehen Diese Eigen schaften und die Tatsache dass Skriptsprachen normalerweise interpretierte Spra chen sind erlauben andererseits eine sehr flexible Programmierung die insbeson dere f r das Rapid Prototyping gut geeignet ist Insgesamt sind Skriptsprachen jedoch auf einem vergleichsweise niedrigen Abstraktionsniveau angesiedelt so dass sie sich aus Sicht der Prozessmodellierung nur bedingt zur Spezifikation werk zeug bergreifender Abl ufe eignen 12 fr her OLE Automation 84 3 Integrationsansatze 3 3 3 3 Fazit Als wesentliche Grundvoraussetzung die in den Bereich der Kontrollintegration f llt sollte ein Werkzeug alle seine ber die Benutzeroberfl che zugreifbaren Funktionalit ten auch ber eine programmierbare Schnittstelle offen legen Fe Oh91 Poh 99 Erst durch die M glichkeit der programmgesteuerten Interaktion zwischen Werkzeugen lassen sich elementare Werkzeugdienste zu gr eren Abl u fen zusammenf gen Kommunikationsmechanismen wie Object Request Broker oder Message Ser ver erm glichen die In
184. am Beispiel von drei Situati onstypen die f r Kontexte des ER Editors definiert wurden situation TwoEntities with sub entity product Entity super entity product Entity end situation AttributeNameForEntity with entity product Entity attrname value string end situation AtLeastOneERObject with erobjects list 1 product ER Object end 7 3 GARPIT ein Framework f r prozessintegrierte Werkzeuge 213 Die Situation TwoEntities ist gegeben wenn der Benutzer zwei Objekte vom Typ Entity aktiviert hat wobei das eine Objekt die Rolle subentity und das andere die Rolle superentity einnimmt Dieser Situationstyp ist Teil des Kontexts Create IsALink mit dem eine Spezialisierungsbeziehung zwischen zwei Entit ten erzeugt werden In der Situation AttributeNameForEntity hat der Benutzer eine Entit t entity ausgew hlt und einen String attrname vorgegeben Diese Situation ist Teil des Kontexts CreateAttribute mit dem ein neues Attribut mit Namen attrname zur Entit t entity hinzugef gt werden kann Die Situation AtLeast OneERObject ist dann g ltig wenn der Benutzer mindest ein bis beliebig viele ER Objekte ausgew hlt hat Der Produkttyp ER_Object ist hierbei eine Oberklasse f r alle einem ER Diagramm vorkommenden Konstrukte Entit t Beziehung Attribut Spezialisierungsbeziehungen etc Unsere Situationssprache erlaubt in der aktuellen Implementierung nur die 5 5 3 A
185. ame der jeweiligen Klasse bzw Assoziation angegeben Verfeinere besteht_aus_Intention Intention Altern besteht_aus_ besteht_aus_ Subtypisiere Intention PK_SubtypisiereEntit t Situation EineEntitat Intention SPK Situation Legende Zuordnung der Instanzen zu den Teilmodellen Prozessmodell Werkzeugmodell gemeinsame Konzepte Links des Umgebungsmodells EK_VerfeinereEntitat EK ative Alternative besteht_aus_Intention Intention AK_Erzeugelsalink kaueseseessesseseesesesensennenen AK besteht_aus_ Situation Darstellung_Intention basiert_auf ausgef hrt_durch ZweiEntitaten Situation basiert_auf basiert_auf Entitat ErzeugelsaLink Produkt Aktion sub input Entit t hervorgehoben Darstellungsart Entitat selektierbar Entitat_ER Editor Darstellungsart selektierbar Darstellungselement hervorgehoben Farbe wei Form Rechteck deaktiviert RTL Entit t deaktiviert Darstellungsart output IsaLink Produkt Darstellung_Intention Der obere Teil von Abb 22 stellt einen stark vereinfachten Ausschnitt aus einem Prozessmodell zur Entity Relationship Modellierung dar vgl PIRo95 F r den Entscheidungskontext EK Verfeiner n mlich der Ausf hrungskontext AK ErzeugeIsALink und der PK SubtypisiereEntitat Mithilfe des Ausf hrungskontext AK
186. amodell noch bewusst offen gelassen siehe Tab 8 Informationen f r Operationalisierung PRIME UM Kontextkomponente v Aktivierung durch zugeordnete Kommandoele mente Intention PRIME UM spez Situationssprache erforderlich Situation nicht vollst ndig spezifiziert struktureller Aufbau Situationsbedingung Verhalten Ausf hrungskontext PRIME UM Ausf hrung durch zugeordnete Aktion und Werkzeugkategorie Angabe der Alternativen Zuordnung zu Werkzeugkategorie Abbildung der Alternativen auf Interaktions elemente Entscheidungskontext PRIME UM Plankontext PRIME UM nicht vollst ndig spezifiziert nur Angabe der Subkontexte Angabe des Kontroll und Datenflusses zwischen Subkontexten spez Ablaufsprache erforderlich Wir haben bereits bei der Beschreibung des NATURE Prozessmodells in Ab schnitt 5 3 2 darauf hingewiesen dass die durch die Assoziation basiert auf repr sentierte Beziehung zwischen Situationen und Produkten in der Regel we sentlich komplexer aufgebaut ist sie definiert den strukturellen Aufbau einer Produktkonstellation aus atomaren und zusammengesetzten Produktteilen und ist eventuell durch zus tzliche Randbedingungen die zum Vorliegen der Situation 131 Tab 8 Informationen des Um gebungsmodells zur Operationalisierung Spezifikation von Situa tionen 132 6 Interoperabilitat von Prozesssprachen erf llt sein m ssen n her beschrieben Eine k
187. and Improvement In Proceedings of the 4th International Conference on the Software Process ICSP4 1996 Avrilionis D Belkhatir N und Cunin P Improving Software Process Modelling and Enactment Techniques In Montangero C Hrsg Proceedings of the 5th European Workshop on Software Process Technology EWSPT 96 Springer Verlag LNCS 1149 1996 S 65 74 280 Literaturverzeichnis AvFi88 BaCK98 BaCR94 BaDF96 BaFG93 BaG198 BaKa91 BaKr93 BaKr95 BAKR95a BaLi96 Balz96 BaMa98 Barg92 BaRo88 BaSc88 BBFL94 BCTW96 Bec 99 Avison D E und Fitzgerald G Information Systems Development Methodologies Tech niques and Tools Blackwell Oxford UK 1988 Bass L Clements P und Katzman R Software Architecture in Practice Addison Wesley Reading 1998 Basili V R Caldiera G und Rombach D Goa Question Metric Paradigm In Mat ciniak J Hrsg Encyclopedia of Software Engineering Vol 1 John Wiley amp Sons 994 S 528 532 Bandinelli S Di Nitto E und Fuggetta A Supporting Cooperation in the SPADE 1 Environment IEEE Transactions on Software Engineering 22 12 S 841 865 Dec 996 Bandinelli S Fuggetta A und Ghezzi C Software Process Model Evolution in the SPADE Environment JEEE Transactions on Software Engineering 19 12 S 1128 144 Dec 1993 Bauer Ch und Glasson B Extending the Concept of a
188. andenen Anwendungsdomanen noch l ckenhaft und befindet sich im st ndigen Fluss nicht zuletzt wegen der Proliferation der technischen M glich keiten Prozessverbesserungsparadigmen wie Total Quality Management Demi86 TAME BaRo88 das Capability Maturity Model des Software Engineering Insti tutes Hump89 PCCW93 BOOTSTRAP Koch93 und SPICE Dorl93 zielen darauf ab Ist Prozesse kontinuierlich auf Schwachstellen hin zu analysieren und zu bewerten Verbesserungspotenziale zu entdecken und diese in k nftige Prozesse einflie en zu lassen f r eine bersicht ber die unterschiedlichen Prozessverbes serungsans tze siehe z B ThMa97 Dass es einen allgemeing ltigen und durchg ngigen Prozess der den Anforde rungen potenziell beliebiger Organisations und Projektformen gen gt aufgrund der vielf ltigen Unw gbarkeiten bei der Systementwicklung nicht geben kann ist einsichtig und wird auch von vielen Autoren betont vgl CuKO88 Sol 83 Ku We92 AvFi88 Dies gilt sowohl f r projektweite Prozesse die auf der Pro jektmanagementebene betrachtet werden als auch f r arbeitsplatzlokale Prozesse auf der technischen Ebene Zu den so genannten Kontingenzfaktoren KaRo74 SIBr93 die ganz wesentlich die Auswahl und Ausgestaltung von Methoden und damit auch der Prozessunterst tzung beeinflussen geh ren u a SIBr93 Harm97 Oll 91 SIH096 Projekttyp Projektgr e Wissen und Erfahrung der Mitarbeiter Innovativit t und
189. ands berg nge in der Durchf hrungs und Leitdom ne Guided Process Performance GuidanceRequest I ContextRequest 1 EndOfEnactment Process Enactment Active K Process Enactment Inactive Im Folgenden beschreiben wir die nebenl ufigen Teil Zustandsdiagramme der Durchf hrungs und Leitdom ne im Detail Aus pr sentationstechnischen Gr n den betrachten wir die beiden Dom nen getrennt voneinander Dabei sollte man jedoch im Hinterkopf behalten dass die Zustands berg nge in den beiden Dom nen in der Regel nicht unabh ngig voneinander erfolgen sondern durch Austausch von Nachrichten aneinander gekoppelt sind ProcessEngine 7 2 1 Dynamische Sicht der Durchf hrungsdom ne Abb 44 zeigt das Zustandsdiagramm f r die Verhaltensspezifikation eines Tool Objekts in der Durchf hrungsdom ne Ein Werkzeug geht nach seinem Start entweder in den Zustand Stan dard Context Active oder in den Zustand Waiting for Context Request ber abh ngig davon ob das Werkzeug manuell durch den Benutzer Transition 1 oder im Rahmen einer Plankontext Ausf hrung durch die Prozessmaschine Transition 2 gestartet wurde Diese beide Zust nde sind Teil einer Oder Verfeinerung der Zust nde Unrestricted Process Performance bzw Guided Process Perfor mance die wir bereits aus Abb 43 kennen 184 Abb 44 Verhaltensspezifikation der Frameworkklasse Tool 7 Das PRIME Rahme
190. anspruchnahme auf den aktuellen Arbeitskontext zugeschnitten 0 Anpassbarkeit Abschnitt 2 1 4 Ist die Prozessunterst tzung flexibel an organisations und projektspezifische Bed rfnisse anpass und erweiterbar und welcher Aufwand ist daf r erforderlich Q Unterst tzungsmodi Abschnitt 2 1 5 Wie hoch ist der Durchsetzungs grad der Prozessunterst tzung d h wie stark ist der Benutzer an die von der Prozessunterst tzung gemachten Vorgaben gebunden Dieser Kriterienkatalog ist keineswegs vollst ndig und k nnte noch um zus tzliche Facetten erweitert werden die wir im Kontext dieser Arbeit jedoch aus Aufwands gr nden nicht ersch pfend behandeln k nnen und daher bewusst ausblenden Dazu z hlt vor allem die Unterst tzung der Nachvollziehbarkeit GoFi94 abgelaufe ner Entwurfsprozesse als Grundlage f r das nderungsmanagement die Wieder verwendung fallspezifischen Erfahrungswissens und die kontinuierliche Prozess verbesserung Aspekte der Nachvollziehbarkeits Unterst tzung wurden schon in anderen Forschungsarbeiten im Umfeld des hier vorgestellten PRIME Rahmen werks eingehend behandelt hier sei auf die bereits oben erw hnten Dissertationen von K Pohl Repository Unterst tzung f r die Nachvollziehbarkeit von Require Nicht betrachtete ments Engineering Prozessen Pohl95 R D mges Anpassbare Nachvollzieh Klassiikationskniiernn barkeitsstrategien D mg99 und P Haumer Nachvollziehbarkeit zwischen konzeptuellen Modell
191. art Modell des Plankontexts InspectRelatedObjects EC_DEP_getDependentProduct EC_DEP_expandProduct CC_DEP_SelectDepProduct 947 CCAltematfve 4326 CCAltemate CC_DEC_InspectDecision CC_HT_InspectHypertext Welcome to the PRIME plan context editor Plan Context Choice Context Executable Context OO 1 Abb 75 zeigt den Plankontext PC FBW InspectRelatedObjects als UML Zustandsdiagramm dessen Eingangsschnittstelle eine Instanz des generischen Typen Product erwartet und dessen Ausgangsschnittstelle eine Produktliste Pro ductList liefert Um das gew nschte Verhalten des Plankontextes zu realisieren m ssen zun chst diejenigen Produkte ermittelt werden die mit dem Eingangspro dukt in einer Abh ngigkeitsbeziehung stehen EC_DEP GetDependentProducts Die Liste der abh ngigen Produkte wird mit der nachfolgenden Werkzeugaktion EC DEP ExpandProduct im Abh ngigkeitseditor zusammen mit den Beziehungen zu der Verfeinerung angezeigt Daraufhin wird der Abh ngigkeitseditor angewie sen in den Entscheidungskontext CC_DEP Explore berzugehen so dass der Benutzer die angezeigten Produkte mit dem Abh ngigkeitseditor untersuchen kann Dieser Entscheidungskontext besteht aus Kontextalternativen mit dem der Benutzer die Produkte und deren Abh ngigkeiten untersuchen kann hier nicht im Detail dargestellt Der Benutzer kann frei zwischen allen Alternativen w hlen und solange im Ents
192. as propriet re Werkzeugformat zu konvertieren und umgekehrt siehe Abb 8b2 Somit reduziert sich die Anzahl der ben tigten Konvertierungsprogramme auf 2 n Standardisierte Informationsmodelle ODIE CASE Tool Data Im Bereich der Softwaretechnik liegt mit dem von der Electronics Industry Interchange Format Association getragenen CASE Data Interchange Format CDIF Park92 EIA 94 Tann94 ein Standardisierungsversuch mit recht langer Tradition vor hnlich dem weiter unten beschriebenen IRDS Rahmenwerk basiert CDIF auf einer mehrstufigen Modellhierarchie die eine flexible Erweiterung des Standards zum Ziel hat Auf der obersten Ebene Metametamodell werden die prinzipiellen Strukturen und Konstrukte f r die Spezifikation von Modellierungstechniken festgelegt Mithilfe dieser Konstrukte werden auf der n chsten Ebene Schemata Metamodelle f r bestimmte Modellierungstechniken z B Datenflussdiagramme spezifiziert Auf der Modellebene sind die eigentlichen Werkzeugdaten als Instan zen der Metamodelle angesiedelt Bei einem Datentransfer werden sowohl die Modelldaten also z B ein konkretes Datenflussdiagramm als auch die zugeh ri gen Metamodelldaten zwischen den beteiligten Werkzeugen gem einer vom CDIF Standard festgelegten Klartext Syntax ausgetauscht Durch die Ubermitt lung des Metamodells erh lt das Empf ngerwerkzeug Informationen f r die sinn volle Interpretation der Modelldaten was insbesondere f r Metamodell Erweite r
193. at Es wird vorgeschlagen den Prozessschritt durch eine Destillationskolonne zu verfeinern pro argument Die Hauptkomponenten im Eingangsstrom haben eine grosse relative Fliichtigkeit contra argument Komponenten mit einem Mol Anteil unter 0 05 wurden nicht ber cksichtigt und m ssen unter Umst nden separat behandelt werden Edit confirmed stored new value s Der Verfahrensingenieur erkennt dass die bisherige Verfeinerung des VT Pro zessschritts Separation durch eine Destillationskolonne unter der Annahme ge schah dass sich in dem zu trennenden Stoffgemisch au er Wasser und CL keine weiteren nennenswerten Verunreinigungen befinden siche Abb 81 Mittlerweile liegen dem Verfahrensingenieur jedoch die Ergebnisse von Laborexperimenten vor die dieser Annahme widersprechen Also beschlie t er die bisherige Ent scheidung zu revidieren und aktiviert den Plankontext PC_DEC ReviseDecision Dieser Plankontext stellt sicher dass die Revision einer Entscheidung nachvoll ziehbar dokumentiert wird hier nicht im Detail dargestellt 8 3 Beispielsitzung 269 Nach der Entscheidungsrevision geht die Kontrolle wieder auf den als State chart modellierten Plankontext PC_FBW InspectRelatedObjects und von dort auf den als SLANG Netz modellierten Plankontext PC_RefineProcessDeviceWith Decision ber Durch Aktivierung des Ausf hrungskontexts EC_FBW RefineGroup wird im Flie bildeditor eine neue Verfeinerungsgr
194. ation Grundflie bild Simulations ergebnisse ee Strukturmodell Kosten Excel odellierun ModKitl a D Massenbilanzen Verhaltensmodell Spez f r dyn Simulation Dyn Simulation gPROMS Materialmodell Linearisiertes Verhaltensmodell Kostenberech nung grob Kostenberech nung verfeinert A B A basiert auf B 8 2 2 2 Anforderungen an das Flie bildwerkzeug Aus verfahrenstechnischer Sicht ergeben sich zwei zentrale Anforderungen an ein Werkzeug f r den Flie bildentwurf der Umgang mit komplexen Verfeinerungs strukturen und die Organisation von Flie bildbausteinen innerhalb eines reichhal tigen Typsystems Komplexe Verfeinerungsstrukturen Flie bilder werden ber unterschiedliche Abstraktionsniveaus hinweg verfeinert und in jeweils spezifischen Repr sentationen dargestellt Im Rahmen des SFBs haben wir uns besonders f r zwei der drei in DIN 28004 genormten Flie bildvari anten interessiert das Grund und das Verfahrensflie bild a Das Grundflie bild stellt die Gesamtfunktion des VT Prozesses dar Diese kann durch Aufteilung in komplex aufgebaute Teilfunktionen VT Prozessschritte und atomare Grundoperationen Unit Operations sowie das Festlegen von Ver kn pfungen zwischen Teilfunktionen und Operationen hierarchisch strukturiert werden Im Grundflie bild steht die Funktion eines VT Prozesselements im Vor dergrund z B Reaktion
195. ation nicht ganz scharf gezogen siehe z B Kelt93 ScBr93 wobei tendenziell Kon trollintegration als werkzeug bergreifende Programmiertechnik f r die Automa tion kleinerer Arbeitseinheiten verstanden wird w hrend mit Prozessintegration die Abwicklung gr erer Arbeitseinheiten in unterschiedlichen Werkzeugen ver bunden wird Hier besteht jedoch die Gefahr dass unterschiedliche Integrations begriffe mit m glicherweise konkurrierenden Integrationsmechanismen f r hnli che Sachverhalte verwendet werden was das Risiko inhomogener und schwer durchschaubarer Systemarchitekturen birgt Andere Arbeiten wie etwa Tull91 MiSc92 propagieren daher eine strikte Trennung zwischen Kontroll und Pro zessintegration Sie weisen daraufhin dass ein kontrollintegriertes Werkzeug also eines das ber feingranular programmierbare Laufzeitschnittstellen durch andere Werkzeuge aufgerufen werden kann und interne Zustands nderungen nach au en meldet noch nicht unbedingt ein prozessintegriertes Werkzeug darstellt solange keine expliziten Prozessdefinitionen das Werkzeugverhalten und die Interaktionen mit 3 3 Integrationsanforderungen in prozessintegrierten Umgebungen 57 anderen Werkzeugen festlegen In dieser Arbeit schlieBen wir uns dieser Auffas sung an die Dimension der Kontrollintegration definiert somit lediglich Basisin tegrationsdienste f r die h here Ebene der Prozessintegration Das Zusammen schalten von Werkzeugen ber Mechanismen de
196. ation einer Sprache die jeweiligen Konzepte der Modelle assoziiert werden k nnen Die Instanz einer atomaren Aktivit t ist im Schnittstellenmetamodell durch eine Kontextkomponente gegeben da sie analog zu beispielsweise einer SLANG Transition ber ihre Schnittstelle einen Dienst anbietet PK und EK Komponenten sind Instanzen einer zusanmengesetzten Aktivit t da sich beide aus weiteren Kontexten zusammensetzen Weiterhin werden auch die Komponentenkonzepte Schnittstelle und Produktteil als direkte Instanzen der M2 Modellkonzepte dargestellt Tab 9 zeigt die Auspr gun gen der Konzepte des M2 Modells einiger Sprachen die korrespondierenden Konzepte des Schnittstellenmetamodells sind kursiv dargestellt Tab 9 Sprachkonzepte als Instanzen des PSM2 Modells Schnittstellen metamodell Datenbeh lter Produktteil Meta Schnittstelle Situationsschnittstelle Atomare Aktivit t Kontextkomponente Zusammen gesetzte Aktivit t PK_Verhaltens komponente SLANG Stelle Vor bzw Nachbereich Transition Aktivit tsnetz UML Zustands Attribut Aktion Zustand Zustandsdiagramm diagramme Funsoft Kanal Vor bzw Nachbereich T tigkeit T tigkeitsnetz HFSP Attribut Funktionsschnittstelle Subfunktion Funktion 6 4 1 2 Bindungs M2 Modell Bei der Verwendung einer Kontextkomponente innerhalb einer PK Komponente ist es erforderlich dass diese durch eine Stellvertreter
197. ationsmanager Protokollierung prozesssensitive von Kontext Kontrollintegration ausf hrungen Prozessspuren Server Nachrichten Prozessspur beobachtung egister amp Notify Entwicklerwerkzeuge Ks Spezifische Allgemein verwendbare Entwicklerwerkzeuge Entwicklerwerkzeuge W Hypertext Prozessspuren GARPIT Editor Visualisierer W Entscheidungs Anleitungs GARPIT Editor r 1 Abl keits weiter Prozess4 GARPIT Browser Editor 1 Deobachter 4 Administrationswerkzeuge 0 Cc 70 O O i D Cc gt pae C 5 Ee C O pos gt Q Produkt Werkzeug modell Editor modell Editor Kontextdefinitionen und Bindungsinformationen Zuordnung zwischen Werkzeugen und Kontextdefinitionen Plankontextspezifikation in spezifischen Ablaufformalismen A S Umgebungsmodell E Generisches Prozessmodell Generisches Generisches NATPROC Produktmodell Werkzeugmodell Persistenz der Produktdaten Werkzeugdefinitionen und Zuordnung zu Kontexten Persistenz der Prozessspuren Werkzeug Spezifische Produktmodelle Spez Prozess Modell Hypertext Entscheidungs W Modell Plankontexte in Modell Modell SLANG Statecharts no W2 Modell C XYZ Abh ngigkeits Prozessspuren Modell Modell W Modell Modellierungsdomane Abb 34 vermittelt einen berblick ber die Gesamtarchitektur einer PRIME basierten prozessintegrierten Modellierungsumgebung Neben der Identifikation der Hauptkomponenten in den drei Prozes
198. aufender Prozesse er ffnen sich hier jedoch interessante Ankn pfungspunkte f r weitere Forschungsarbeiten Die Administrations und Metamodellierungswerkzeuge sind datenseitig durch die in Kapitel 5 und 6 dargestellten Querbez ge zwischen den einzelnen Metamo dellen Prozessmodell spezifische Plankontextmodelle Werkzeugmodell Umge bungsmodell Produktmodell miteinander integriert Abb 34 illustriert dies durch eine verzahnte Darstellung der entsprechenden Teilmodelle innerhalb des Prozess Repositories Die Definition eines neuen Prozessfragments und dessen Zuordnung zu einer Werkzeugkategorie involviert daher i a mehrere der im Folgenden vorge stellten Werkzeuge Die dabei auftretenden werkzeug bergreifenden Abl ufe werden durch entsprechende Prozessfragmente angeleitet NATPROC Editor Der NATPROC Editor unterst tzt die Verwaltung von Kontextkomponenten und deren Schnittstellen entsprechend den in Kapitel 5 und 6 vorgestellten Meta modellen 177 Nahtlose Verschr nkung von Prozessausf hrung und definition 178 7 Das PRIME Rahmenwerk PRIME NATPROC Modeler See Document Edit Create Tools Preferences Help S EC CC PC Liste der existierenden Kontextkomponenten Contexts ES EC_ER CreateEntity IEC Al F2 ER CreateRelationship c pc ER DovisEdAction pc a EC_ER_NewERD IEC EC ER OpenERD ts Ta a PRIME NATPROC Modeler Mil E G C ER Ope ar Document Edit Create Tools Preferences Help FC FR Quit Detai
199. bei der Darstellung des ContextManager Pakets beschrieben Details zur formalen Zustandsmodellierung sind in Schm99 zu finden 244 Tab 16 Zuordnung der zustands basierten Nachrichtenty pen der Prozessfrag ment Interpretation zu den Variationspunkten der Interpreterklassen 7 Das PRIME Rahmenwerk Durch Offenlegung der Ausf hrungszust nde eines Prozesses k nnen Ereignisse der Prozessausf hrung an den spezialisierten Prozesssprachen Interpreter weiter geleitet werden Dabei entspricht jeder Zustand und Zustands bergang eines Prozesses einem Nachrichtentyp der innerhalb des Interpreterrahmenwerkes versendet wird Die Prozesssprachen Interpreter sind f r die Weiterverarbeitung des Nachrichtentyps verantwortlich und k nnen darauf entsprechend reagieren indem f r jede Nachricht ein Prozesssprachen spezifisches Verhalten implemen tiert wird Die Empf nger der Nachrichtentypen sind die technischen und sprach lichen Klassen f r die jeweils ein spezialisierter Variationspunkt virtuelle Me thode existiert der das Verhalten der Klasse auf den empfangenen Nachrichten festlegt siehe Tab 16 Die Nachrichtentypen der Prozessausf hrung werden f r die Kontrollinversion im Interpreterrahmenwerk genutzt so dass sich der Kon trollfluss im Interpreterrahmenwerk am Prozessausf hrungszustand orientiert Frameworkelement Process Nachrichtentyp Zustands bergang Create Data Container Composite Activity Interface
200. beitsmo dus entspricht dabei einer eingeschr nkten Teilmenge von Diensten unter denen der Benutzer zu einem Zeitpunkt ausw hlen kann Wenn ein Werk zeug von der Prozessmaschine in einen Arbeitsmodus versetzt hat dies be ratende Wirkung da der Benutzer nicht gezwungen wird einen bestimmten Dienst auszuf hren sondern zwischen verschiedenen sinnvollen Prozess alternativen ausw hlen kann Wir sprechen daher auch von Beratungsdiensten die von einem Werkzeug angeboten werden Hier stellt sich die Frage welche Aspekte werkzenginh rent sind also durch ein Welche Aspekte sind gegebenes Werkzeug bereits festgelegt sind und welche Aspekte von der Verwen ee on dung eines Werkzeugs innerhalb eines bestimmten Prozesses abh ngen also Teil essa Gebe sen der Prozessdefinition sein sollten In FeOh91 wird gefordert dass ein Werkzeug einen prinzipiell wodusfreien Zugriff auf seine Funktionalit t erlauben sollte und per se m glichst wenige oder gar keine Annahmen dar ber machen sollte unter wel chen Umst nden seine Funktionalit t exportiert werden kann Einschr nkungen hinsichtlich der Benutzbarkeit einzelner Dienste und die Definition spezieller auf einen bestimmten Prozesskontext zugeschnittener Beratungsdienste sind prozess relevante Aspekte und sollten aus Gr nden der Anpassbarkeit daher logisch als Teil des Prozessmodell aufgefasst werden Die konzeptuelle Modellierung eines Werkzeuges kann sich daher zun chst auf die Angab
201. ben wir im Folgenden einen kurzen Abriss ber die Entwicklungshistorie des PRIME Frameworks und seiner Anwendungen Der zunehmende Reifegrad des PRIME Frameworks wird in Abb 69 durch die immer gr er werdenden dunkelgrauen Fl chen Framework Anteile der einzelnen Framework Versionen symbolisiert 8 Anwendungen Abb 69 Entwicklungshistorie des PRIME Rahmenwerks PROART und PRO ART CE Anwendungen in ee gen ir der Entwurfsdom ne der Eniwurisdomane Framework Simulations Umgebungen requirements f r den Verfahrens Engineering Umgebungen technischen Entwurf PROART PROART CE PROART 2 0 PRIME 1 5 BRINE PROMENADE PRIME CREWS PRIME 2 0 PRIME IMPROVE Den Ausgangspunkt f r die erste Version des PRIME Rahmenwerks bildete die Requirements Engineering Umgebung PROART Pohl96 die im Rahmen des EU Grundlagenprojekts NATURE JRSD99 entwickelt wurde Das Hauptau genmerk dieser Umgebung lag auf der Nachvollziehbarkeit von Requirements Engineering Prozessen auf der Grundlage einer automatisierten prozessbegleiten den Aufzeichnung von feingranularen Abh ngigkeiten zwischen Entwurfspro dukten die in den unterschiedlichen PROART Werkzeugen bearbeitet werden In einer interdisziplin ren Kooperation mit Lehrstuhl f r Prozesstechnik der RWTH Aachen wurde erkannt dass sich die aus dem Requirements Engineering bekann ten Konzepte zur Nachvollziehbarkeitsunterst tzung auch auf den rechnerge st tzten ko
202. ber den DEC Fuse Message Server s o nach dem Prinzip des Message Broadcasting kontrollintegriert sind Abb 13 oben In der Leitdom ne hier process enactment environment genannt inter pretieren hierarchisch angeordnete Prozessmaschinen die Prozessmodelle die in der Petrinetz basierten Sprache SLANG BaFG93 formuliert sind Abb 13 unten Die Verbindung zwischen den beiden Dom nen wird ber eine spezielle Komponente das SPADE Communication Interface SCI hergestellt Abb 13 Mitte Aus Sicht des Fuse Message Servers stellt das SCI lediglich ein weiteres Werkzeug dar das ebenso wie die origin ren Fuse Werkzeuge Nachrichten von anderen Werkzeugen empfangen bzw Nachrichten an diese verschicken kann Die Aufgabe des SCI besteht nun zum einen darin Nachrichten die von den Werkzeugen der Durchf hrungsdom ne generiert wurden abzufangen und in den aktuell interpretierten SLANG Netzen als Token in spezielle Stellen die so ge nannten user interface places abzubilden Hierdurch ist es m glich Ereignisse der Durchf hrungsumgebung in die laufende Prozessmodellinterpretation einflie en zu lassen Umgekehrt lassen sich aus der Prozessmodellinterpretation heraus Werkzeugdienste in der Benutzerumgebung aktivieren Hierzu ist in SLANG das Konzept der black transitions vorgesehen Beim Schalten einer solchen Transition wird ber das SCI eine in der Transition spezifizierte Kommandonachricht an den Message Server abgesetzt und von dort an
203. bertragung des Inter aktionsprotokolls in explizite Zustands und Transitionsklassen Kontrollfunktionalitat in den Methoden der Zustands und Transiti onsklassen 7 Das PRIME Rahmenwerk 7 3 2 3 StateManager Das globale Werkzeugverhalten in Reaktion auf Nachrichtenereignisse aus der Leitdomane und Benutzerinteraktionen wurde in Abschnitt 7 2 mithilfe eines Zustandsdiagramms spezifiziert und muss nun innerhalb der Werkzeugarchitektur umgesetzt werden In der Praxis erfolgt die Abbildung solcherart spezifizierter Dynamikaspekte in einen Klassenentwurf meist nicht auf besonders systematische Weise Generell werden Zustandsdiagramme eher benutzt um auf konzeptueller Ebene das gew nschte Verhalten zu kl ren und dieses dann in korrespondierende ma geschneiderte Codefragmente zu bertragen die h ufig ber Methoden vieler verschiedener Klassen in unterschiedlichen Systemschichten verstreut sind Dabei geht jedoch die Sichtbarkeit der Zust nde und Transitionen im Klassendesign und in der Implementierung verloren Dies hat zur Folge dass bei Protokoll nderun gen die betroffenen Stellen einer Architektur nur schwer zu identifizieren sind HiKa99 Um Wartbarkeit und Erweiterbarkeit des globalen Werkzeugverhaltens in Hinblick auf zuk nftige Anforderungen zu gew hrleisten werden im GARPIT Framework die in Abschnitt 7 2 definierten Zust nde und Transitionen als explizite Klassen in die Architektur bertragen Abb 51 zeigt die resultie
204. beschrieben Analog zur oben beschriebenen Integrit tsbe dingung AK2 bez glich der input Parameter muss f r die output Parameter sicher gestellt werden dass die im Prozessmodell beschriebenen nderungen am Pro duktmodell die im Werkzeugmodell definierten Ausgabeparameter subsummieren Seien also Pc und Po die Mengen der Produkte die ber die ndert bzw output Assoziation mit der Aktion A verbunden sind Dann muss Po lt Pc gelten Diese Forderung l sst sich durch die O Telos Integrit tsbedingung AK3 formalisieren die wiederum der Assoziation Werkzeugkategorie f hrt AK aus zugeordnet wird 124 5 Integrierte Prozess und Werkzeugmodelle Attribute Werkzeugkategorie f hrt AK aus with constraint AK3 forall p Produkt ak Ausf hrungskontext a Aktion From this ak and ak ausgef hrt durch a and a output p gt a ndert p end 5 5 2 2 Abbildung von Entscheidungskontexten auf Interakti onselemente Jeder im Prozessmodell definierte Entscheidungskontext EK wird ber die Assozi ation f hrt EK aus genau einer Werkzeugkategorie zugeordnet Durch die im Prozessmodell spezifizierten Alternativen des Entscheidungskontexts wird somit ein Beratungsdienst f r die Werkzeugkategorie W definiert Die Ausf hrung von EK bedeutet f r das Werkzeug W dass es die Interaktionsm glichkeiten des Be nutzers auf die f r EK definierten Alternativen anpassen muss und dem Benutzer die Auswahl einer Alternative erm glich
205. bez g lich der verwendeten Datenstrukturen folgen sondern auch die Bedeutung der Datenstrukturen in gleicher Weise interpretieren Integration auf der semantischen Stufe kann auf zwei Arten erreicht werden Zum einen k n nen Datenstrukturen und Operationen auf diesen Datenstrukturen vorab spezifiziert werden so dass Werkzeughersteller a priori ber die Bedeutung der einzelnen Datenstrukturen deren Bezeichnungen die Auswirkungen von Operationen auf den Datenstrukturen usw informiert sind Zum an deren k nnen Meta Informationen ber die Datenstrukturen und die zu geh rigen Operationen in einem Repository verwaltet werden Ber 99 Je Pa97 JePa97 Der letztgenannte Ansatz hat den Vorteil der einfachen Er weiterbarkeit da die Meta Daten zur Laufzeit der Werkzeuge angefragt werden k nnen O Methodenstufe method level Auf der obersten Stufe wird die Interaktion und damit der Datenaustausch und die Datenkonsistenz zwischen Werk zeugen im Kontext der zu unterst tzenden Entwicklungsprozesse be trachtet Die Kenntnis der Entwicklungsprozesse hilft die auszutauschen den Daten anhand der werkzeug bergreifenden Abl ufe zu identifizieren 60 3 Integrationsansatze und Politiken unter welchen Umstanden Datenkonsistenz durchgesetzt werden muss festzulegen Im Kontext dieser Arbeit streben wir Datenintegration auf der Methodenstufe an was insbesondere ein gemeinsames Verst ndnis zwischen Werkzeugen und Pro zessmaschine ber die
206. bungen Gebrauch von Kontrollintegrationsinfrastrukturen wie Ob ject Request Broker oder Message Broadcasting Mechanismen Hier lage es nahe die in den Interface Repositories bzw Message Servern vor liegenden Werkzeugbeschreibungen systematisch bei der Modellierung von Pro zessschritten zu ber cksichtigen Dies ist jedoch nicht der Fall wie das bereits weiter oben erw hnte Beispiel der SPADE Umgebung mit der Prozessmodellie Seen rungssprache SLANG zeigt Als Sprachmittel zur Beschreibung der Interaktion von Werkzeugbeschrei bungen in Interface mit der Durchf hrungsdom ne stehen in SLANG die Konzepte black transition und Repositories und Pro user interface place zur Verf gung Das Schalten einer black transition f hrt zur Akti zessmodellen vierung eines externen Programms welches im Implementierungsteil einer schwarzen Transition spezifiziert wird Es ist nicht m glich einen Werkzeugdienst bzw eine beim Message Server registrierte Nachricht direkt in der Spezifikation der schwarzen Transition zu referenzieren Stattdessen ruft die black transition ein Wrapper Programm SendMessage auf welches seinerseits eine Nachricht an den Message Server versendet und so eine Reaktion in der Werkzeugumgebung aus l st Analog verl uft der Empfang von Nachrichten aus der Durchf hrungsdo mane die in user interface places der interpretierten SLANG Netze abgebildet wer den In ProcessWeaver erfolgt die Interaktion mit nachrichtenbasierten
207. cation Language Require ments for Modeling Processes Tech Report NISTIR 5910 National Institute of Stan dards and Technology Gaithersburg MD 1996 296 Literaturverzeichnis SFGJ99 Sha 95 ShGa96 Shne98 hWa95 DN Sieg96 Simm91 Simm93 SJHB96 SIBr93 SIH096 SoKe95 Sol 83 Somm92 SoTM88 Srin99 Stal81 Such87 SuKN96 SuN092 Suns93 Szyp98 Sch fer W Fuggetta A Godart C und Jahnke J Architectural Views and Alterna tives In Derniame J C Kaba B A und Wastell D Hrsg Software Process Prin ciples Methodology and Technology Springer Verlag Berlin Heidelberg LNCS 1500 1999 S 95 116 Shaw M DeLine R Klein D Ross T Young D und Zelesnik G Abstractions for Software Architecture and Tools to Support Them IEEE Transactions on Software En neering 21 4 S 314 335 1995 Shaw M und Garlan D Software Architecture Perspectives on an Emerging Discipline Prentice Hall Upper Saddle River NJ 1996 Shneiderman B Designing the User Interface Addison Wesley 1998 Shams Aliee F und Warboys B Apphying Object Oriented Modelling to Support Process Technology In Proceedings of the 1st World Conference on Design and Process Technology IDPT 1995 S 109 115 Siegel J CORBA Fundamentals and Programming John Wiley amp Sons 1996 Simmonds I Evolving towards Support for
208. ch ein Kontextdeskriptor Objekt CcxtContextDese und eine Situationsinstanz Objekt CcxtSituationInstance parametriert werden Diese Klassen dienen der Laufzeitrepr sentation der im Prozessrepository abgelegten Werkzeugkontexte und situationen und k nnen sich ebenfalls selbstst ndig in eine Stringdarstellung umwandeln bzw daraus konstruie ren Ein Werkzeug kann daher auf Modellierungsebene um weitere Kontext und Situationstypen erweitert werden ohne dass es manuell oder auch generativ etwa im Sinne der Kompilierung einer IDL Spezifikation um neue Nachrichtentypen erg nzt werden m sste Dies ist ein entscheidender Vorteil gegen ber Object Brokern wie CORBA oder COM MessageServer basierten Ans tzen wie Soft bench ToolTalk oder auch dem GTSL Ansatz von Emmerich Emme95 wo f r jede neu exportierte Werkzeugfunktion in unserer Terminologie w re dies ein Kontext ein neuer Nachrichtentyp bzw Methoden Skeletons und Stubs so wohl auf Werkzeug als auch auf Klientenseite realisiert werden muss Das Teilsystem MessageInterface ben tigt keinerlei Adressateninformationen Alle Nachrichten werden an den Kommunikationsmanager geschickt der die f r die Nachrichtenverteilung erforderlichen Informationen aus dem Umgebungsmo dell und der internen Tabelle der laufenden Werkzeug und Prozessmaschinenin stanzen entnimmt und f r die korrekte Weiterleitung der Nachrichten an den richtigen Adressaten verantwortlich ist Die dadu
209. ch komplexe Prozessfragmente wurde insbesondere f r die Pr skription und Automatisierung der Aufzeichnung von Nachvollziehbar keitsinformationen z B Entscheidungsdokumentation als sinnvoll angesehen 9 2 2 Sicht des Methodeningenieurs Die drei Kontexttypen unterst tzten den Methodeningenieur bei der Strukturie rung von Prozessmodellen und zwar unabh ngig von einer konkreten Prozess modellierungssprache wie beispielsweise SLANG Netze oder Statecharts Im Unterschied zu den meisten anderen Modellierungsans tzen wurde der Metho deningenieur angehalten Entscheidungen explizit zu definieren Die Notwendig keit Werkzeugfunktionalit ten in Modellen zu spezifizieren veranlasste die Mo dellierer intensiver ber die geeignete Granularit t von Prozessschritten nachzu denken Dar ber hinaus halfen die Werkzeugmodelle dem Methodeningenieur bei der Prozessmodelldefinition die vorhandene Werkzeugfunktionalit t zu ber ck sichtigen Die Definition von Werkzeug und Prozessmodellen sowie das integ rierte Umgebungsmodell erm glichten eine leichte Anpassung der von der Umge bung angebotenen Unterst tzung Besonders in experimentellen Anwendungen und f r wenig verstandene Prozesse in denen st ndig neue Erfahrungen ber verbesserte Vorgehensweisen gesammelt werden wie in dem oben beschriebenen IMPROVE Projekt erwies sich die Aufwandsminimierung f r die Anpassung der Unterst tzung als essentiell 9 2 3 Sicht des Umgebungsentwicklers
210. ched c send GuidanceRequest c LockRequest send LockOKResponse ContextRequest c ContextExecuted c result result c execute send CCResponse result ContextRequest c result c execute ContextExecuted c result send ECResponse result EndOfEnactment AbortRequested send AbortRequest AbortDenied AbortOK ContextRequest c c ContextT and c Tool ContextExecuted c result send ECResponse result ContextRequest c c Contexti and c Tool gt Ce this ContextExecuted c result result ContextType cc send CCResponse result ContextExecuted c result result ContextType EC send CCResponse result ToolStopped destroy 188 Abb 45 Verhaltensspezifikation der Frameworkklasse Process Engine 7 Das PRIME Rahmenwerk 7 2 2 Dynamische Sicht der Leitdom ne Abb 45 zeigt das Zustandsdiagramm f r die Verhaltensspezifikation der Klasse ProcessEngine die das Prozessmaschinen Framework in der Leitdom ne repr sentiert Nach dem Start die Prozessmaschine wird beim Hochfahren einer PRIME basierten Umgebung als Damonprozess gestartet ist die Prozessma schine zun chst inaktiv Zustand Process Enactment Inactive Der Empfang einer Guidance Request Nachricht aus der Durchf hrungs dom n
211. cheidungskontext CC_DEP Explore arbeiten bis er als Kontextal ternative entweder den Kontext CC DEC InspectDecision oder CC HT InspectHypertext w hlt und damit die wiederholte Aktivierung des Entscheidungskontextes beendet Mit diesen Entscheidungskontexten kann sich der Benutzer Entscheidungs bzw Hypertextdokumente in den jeweiligen Edito ren ansehen und bei Bedarf modifizieren Beispielsweise beinhaltet der Entschei dungskontext CC_InspectDecision den Plankontext PC ReviseDecision mit dem die Revision einer fruheren Entscheidung dokumentiert werden kann 50 Diese beiden alternativen Kontexte haben die gleiche Intention Inspect aber unterschiedliche Situationen DecisionSelected bzw HypertextSelected 264 8 Anwendungen Abb 76 Der neue Plankontext wird als Alternative zum Standardkontext des Flie bildwerkzeugs hinzugef gt 8 3 1 3 Werkzeugmodellierung Damit der neu definierte Plankontext PC _RefineProcessDeviceWithDecision berhaupt aus dem Flie bildwerkzeug heraus aktiviert werden kann muss er ber das Umgebungsmodell mit dem Werkzeugmodell des Flie bildwerkzeugs in Be ziehung gesetzt werden EPRIME Tool Modeler Oo Document Edit Create Tools Preferences Help 2 Choice Context Context CC_FBW_AFDSheetActive EC_FBW CloneSheet EC_FBW_RenameCurrentSheet EC_FBW_DeleteCurrentSheet views EC_FBW_SimulateExcel lt no menue gt
212. chelemente Da die Struktur eines Fragments bereits durch das PSM2 Modell weitestgehend vorgegeben ist ein Fragment besteht aus Aktivit ten Schnittstellen Datenbeh ltern und Datentypen konnte bei der Implementierung des Interpreterrahmenwerkes die Ladefunktion in weiten Teilen sprachneutral realisiert werden so dass sie f r alle Prozesssprachen wiederver wendbar ist Eine Anpassung ist lediglich f r Prozesssprachen spezifische Modell elemente erforderlich die nicht direkt Teil des Interpreterrahmenwerkes sind Die Produktdaten innerhalb eines Fragments werden von der Klasse DataCon tainer gehalten die einen Typ haben k nnen Die Klasse Type ist verantwortlich f r die Verwaltung der Typinformationen und stellt Metainformationen ber ihre Instanzen bereit Dies umfasst Anfragefunktionalit t nach Generalisierungs und Spezialisierungsbeziehung zwischen Typen sowie nach Typattributen Die eigentli chen Produktinstanzen werden in Instanzen der Klasse CcxtSituationPart Instance verkapselt also mithilfe der gleichen Klasse mit der auch in der Durch f hrungsdom ne Produktinstanzen an Situationsteile gebunden werden vgl Ab schnitt 7 3 2 5 So k nnen auf einfache Weise Situationsdaten die in Werkzeugen gebunden wurden mit den Datenbeh lterkonzepten der jeweiligen Prozessspra chen in Beziehung gesetzt werden Die Klasse DataContainer bietet generell Funk tionalitat um Operationen auf Daten auszuf hren und ggf mit Werte
213. chelements wird durch 7 6 Fazit Implementierung des Klassenk rpers definiert und kann mit Hilfe der Spezialisie rungsbeziehung modifiziert werden Die abstrakten Schnittstellen der Sprachele mente entsprechen dabei den Variationspunkten des Interpreterrahmenwerkes Der Grundgedanke die einzelnen Sprachelemente durch Klassen zu repr sentie ren die durch Spezialisierung angepasst werden wurde bei der Entwicklung des GARPEM Interpreterframeworks bernommen 7 5 5 Zusammenfassung In diesem Abschnitt wurde das Interpreterrahmenwerk GARPEM f r die Integra tion von Prozesssprachen Interpretern in die PRIME Umgebung erarbeitet Die wiederverwendbaren Teilkomponenten des Rahmenwerkes wurden identifiziert die durch Spezialisierung und Erweiterung an die spezifischen Bed rfnisse einer Prozesssprache angepasst werden k nnen Das in Kapitel 6 entwickelte PSM2 Modell welches die Sprachelemente einer Prozesssprache identifiziert die f r eine komponentenbasierte Integration erforderlich sind wurde direkt auf die Klassen struktur des Interpreterrahmenwerkes abgebildet und stellt die Basis f r die sprachlichen Teilkomponenten dar Auf diese Weise ist gew hrleistet dass Spra chen die sich f r eine Integration eignen auch einfach integriert werden k nnen und vom Rahmenwerk unterst tzt werden Die Kontrollinversion basiert auf den Ausf hrungszust nden eines Prozesses mit dem deduzierte Kontexte in der PRIME Umgebung operationalisiert
214. chnitt stellensprache unabh ngig von einer spezifischen Verwendungssprache ist Aus Sicht der Verwendung ist die interne Struktur einer Komponente irrelevant da sie 6 5 Fazit zu den Implementierungsdetails zuzuordnen ist und somit nach au en nicht in Erscheinung treten darf Die Interoperabilit t des Schnittstellenmetamodells mit einer Verwendungs sprache wird mit Hilfe des M2 Modells erzielt Das M2 Modell abstrahiert von den Basiskonzepten die erforderlich sind damit eine Prozesssprache integriert werden kann und legt damit einen Integrationsrahmen fest Bei der Integration ist die Existenz eines expliziten Modul und Schnittstellenkonzept der Sprache entschei dend Das M2 Modell stellt dar ber hinaus Bindungskonzepte bereit mit deren Hilfe Stellvertreterschnittstellen in Verwendungssprachen gebildet werden Als etwas problematisch gestaltete sich die Kapselung der Kontextalternativen eines Entscheidungskontexts da auf der einen Seite der Dienst der Benutzeraus wahl ber die Komponentenschnittstelle zu kapseln ist auf der anderen Seite jedoch die Ergebnisschnittstellen der Kontextalternativen aus pragmatischen Gr nden zug nglich sein m ssen Dieser Einblick in die innere Struktur einer Komponente verletzt zwar das Geheimnisprinzip ist jedoch nicht zu vermeiden Aus dem M2 Modell wurde eine Integrationsmethodik abgeleitet die auf die Modellierungssprache SLANG und auf UML Zustandsdiagramme angewandt wurde Beide Sprachen eig
215. cklungspro zesse m glichst vollst ndig zu erfassen und pr skriptiv zu unterst tzen Ein wesentliches Motiv f r diese Fokussierung auf lenkende und automati sierende Unterst tzungsmodi ist in den Schwierigkeiten zu sehen die sich bei der Handhabung von Abweichungen zwischen der tats chlichen und der im Prozessmodell intendierten Prozessdurchf hrung ergeben Im Ge gensatz zur Prozesslenkung und automation kann bei der passiven Pro zessberatung und der aktiven Prozessanleitung die Prozessmaschine nicht davon ausgehen dass die intendierte Prozessausf hrung vom Entwickler auch tats chlich befolgt wird Der aktuelle Prozesszustand kann daher nicht aus der internen Fortschreibung der Prozessmodellausf hrung abge leitet werden sondern muss st ndig mit Zustandsinformationen aus der Durchf hrungsdom ne abgeglichen werden 2 3 Fazit In diesem Kapitel haben wir zun chst ein Klassifikationsschema entwickelt das eine Bewertung prozessorientierter Unterst tzungsfunktionen hinsichtlich der Merkmale unterst tzte Projektebene Integrationstiefe Kontextbezogenheit Anpassbarkeit und Abdeckung des Spektrums unterschiedlicher Unterst tzungsmodi erm glicht An hand dieses Klassifikationsschemas haben wir die Unterst tzungsleistung von Methodenhandb chern Hilfesystemen Assistenten und Interface Agenten sowie 2 3 Fazit prozesszentrierten Umgebungen diskutiert Im Folgenden stellen wir die St rken und Schw chen der untersuchten Ans t
216. ct General Object Oriented Database for Software Engineering Processes In Ohmaki K Htsg Proceedings of the Asia Pacific Software Engineering Conference Tokyo Japan IEEE Computer Society Press 1994 S 410 420 Grundy J Hosking J und Mugridge W B Inconsistency Management for Multiple View Software Development Environments IEEE Transactions on Software Engineering 24 11 S 960 981 Nov 1998 Griffel F Componentware Konzepte und Techniken eines Softwareparadigmas dpunkt Verlag Heidelberg 1998 Grosz G Rolland C Schwer S Souveyet C Si Said S Ben Achour C und Gnaho C Modelling and Engineering the Requirements Engineering Process An Overview of the NATURE Approach Requirements Engineering Journal No 2 S 115 131 1997 Greenwood R M Robertson I und Warboys B A Support Framework for Dynamic Organizations In Proceedings of the 7th European Workshop on Software Process Technology Kaprun Osterreich Springer Verlag LNCS 1780 2000 Grundmann N Realisierung und Visualisierung von UML Modellen in Telos Diplom arbeit RWTH Aachen 1999 Gryczan G Lilienthal C Lippert M Roock S Wolf H und Z llighoven H Frameworkbasierte Anwendungsentwicklung Teil 1 OBJEKTspektrum 1 99 S 90 99 1999 288 Literaturverzeichnis HaHK97 HaLe93 HaN086 HaPW98 Hare87 Harm97 HaSa96 Haum00 Hay 00 HeEd93 Heim90 Heim92 HeKW97
217. d Ein OPC Prozessmodell besteht somit aus einer Anzahl von Komponenten die in durch die Modellschicht beschrankten Beziehungen stehen und deren Interaktion ber definierte Schnittstellen erfolgt 6 2 3 2 Pynode Prozesskomponenten des Pynode Projektes AvBC96 AvBC96a bestehen aus einer Verbindungsschnittstelle und einem Prozessfragment welches die Schnitt stelle in einer wahlfreien Prozesssprache implementiert Die Verbindungsschnitt stelle besteht zum einen aus Verbindungskan len die eine synchrone und asyn chrone Daten bermittlung an die Komponente erm glichen und zum anderen aus Synchronisationskanalen die eine Kopplung des Kontrollflusses zweier Kompo nenten durch einen Rendevouz Mechanismus erm glichen Im Gegensatz zu synchronen erm glichen asynchronen Verbindungskan le einen Datenaustausch w hrend die Komponente sich im Ausf hrungszustand befindet d h w hrend deren Prozessfragment interpretiert wird Die Komposition von Prozesskomponenten erfolgt innerhalb von Ausf hrungs sichten die hnliche Verbindungsschnittstellen haben wie Prozesskomponenten selbst Eine Ausf hrungssicht kann wiederum in anderen Ausf hrungssichten als Komponenten verwendet werden so dass dadurch ein komplexes Prozessmodell modular aus Komponenten aggregiert werden kann Die Instanziierung einer Ausf hrungssicht erfordert ein schrittweises Einrichten von Verbindungs und Synchronisationskan len Hinzuf gen von Prozesskomponenten und Kopplung
218. d Abort Requested tber Falls ein Abbruch des aktuellen Plankontexts nicht m glich ist antwortet die Prozessmaschine mit einer AbortDenied Nachricht und das Werkzeug kehrt zur ck in den zuvor verlassenen Sub Zustand von Guided by PC Transition 17 endet im History Pseudozustand Im Falle eines zul ssigen Plankontext Abbruchs antwortet die Prozessmaschine mit einer AbortOK Nachricht In diesem Fall kehrt das Werkzeug in den Zustand zur ck den es bei der Aktivierung des Plankontexts verlassen hatte Transition 18 Eine ordnungsgem e Beendigung der Plankontext Ausf hrung wird dem Werkzeug durch eine EndOfEnactment Nachricht signalisiert Auch hier geht das Werkzeug in den letzten Sub Zustand vor der angeleiteten Prozessdurchf hrung ber Transition 15 Tab 10 liefert Detailinformationen zu den Zust nden und Transitionen aus Abb 44 F r die Zust nde spezifizieren wir die Aktivit ten beim Eintritt bzw w hrend des Verweilens in dem Zustand Bei den Transitionen geben wir an durch welche Ereignisse sie ausgel st werden welche zus tzlichen Bedingungen gegebenenfalls gelten m ssen und welche Aktionen beim Zustands bergang aus zuf hren sind Die dabei verwendeten Variablen und Argument Bezeichner haben folgende Bedeutung c Kontext this referenziert das durch das Zu standsdiagramm beschriebene Werkzeug result Resultat einer Kontextausf h rung Ereignisse die dem Empfang von Nachrichten entspreche
219. d Message Das Teilsystem CommunicationChannel realisiert den Kommunikationskanal zum Kommunikationsmanager Die Schnittstelle des CommunicationChannel gliedert sich in zwei Teilbereiche Zum einen werden administrative Methoden f r die An und Abmeldung vom Kommunikationsmanager sowie f r die Erkennung von Verbindungsabbr chen und deren eventuelle Wiederherstellung angeboten Zum anderen exportiert der CommunicationChannel Methoden zum synchronen und asynchronen Versand von Nachrichtenobjekten sowie zur Registrierung eines Objekts der Klasse CevtMessageEventHandler ber das der asynchrone Empfang von Nachrichten vom Kommunikationsmanager an den StateManager gemeldet wird siehe Abschnitt 7 3 2 3 Der CommunicationChannel abstrahiert vollst ndig vom zugrunde liegenden Mechanismus zur Interprozesskommunikation Im Laufe der Entwicklung des PRIME Frameworks haben wir zur Realisierung des Comu nicationChannels zun chst BSD Sockets und Sun s ToolTalk unter Unix sp ter dann WinSock sowie CORBA unter Windows NT 9x verwendet Vom Austausch des Kommunikationsmechanismus war lediglich der Implementierungsteil des CommunicationChannel Pakets 33 Das Klassenpr fix Cskt r hrt von Versionen des PRIME Frameworks basierte die Interprozess Kommunikation ausschlie lich auf betroffen w hrend die externen Schnittstellen der urspr nglichen Paketbezeichnung Socket In den ersten BSD Sockets Mittlerweise haben wir jedoch auch andere Kom
220. d das Paket ER DBInterface obsolet werden 7 3 GARPIT ein Framework f r prozessintegrierte Werkzeuge 223 HaPW98 Haum00 knapp 6000 Zeilen wovon allerdings gut die H lfte auf gene rierten Code entf llt Aktionen und ObjectTable T Die Action Objekte im Paket ER Actions repr sentieren die eigentliche Benutzer funktionalit t und implementieren die im Werkzeugmodell definierten Werkzeug aktionen Jedes Aktionsobjekt verf gt ber eine execute Methode die vom Con textExecutor bei der Aktivierung des entsprechenden Ausf hrungskontextes aufgerufen wird und ein Situationsinstanz Objekt als Parameter erh lt und zur ck liefert Der generelle Aufbau der execute Methode ist wie folgt Q Aus der Eingabe Situationsinstanz werden ber die entsprechenden Rol lenbezeichner die IDs der Produktmodellinstanzen extrahiert auf denen die Aktion ausgef hrt werden soll Q In der ObjectTable werden mithilfe der IDs die entsprechenden Laufzeit Objekte des werkzeuginternen Produktmodells und der GUI ermittelt Q Auf den Produktmodell und GUI Objekten werden parallel die erforderli chen Operationen durchgef hrt je nach Funktionalit t der zu implemen tierenden Aktion Erzeugungs Modifikations oder L schoperationen O Eventuell neu erzeugte Produktmodell und GUI Objekte werden der Ob jectTable unter ihrer eindeutigen ID eingetragen Q Als R ckgabewert wird eine Situationsinstanz vom daf r i
221. daher ignoriert werden In solchen F llen m ssen die Werkzeugen aus den proprietaren Datenspeichern entweder in das Repository abgebildet werden oder k nnen nur grobgranular referenziert werden etwa auf Dokumentebene 3 3 3 Prozessorientierte Mediation der Werkzeuginterak tionen 3 3 3 1 Motivation Ein grundlegendes Ziel von Mechanismen zur Kontrollintegration besteht in der programmgesteuerten Wiederverwendung und Rekombination elementarer Werk zeugfunktionalit ten in immer neuen Anwendungszusammenh ngen durch gegen seitige Dienstbereitstellung und nutzung Entscheidend ist vor dem Hintergrund 70 3 Integrationsansatze einer prozessorientierten Anpassbarkeit die Beobachtung dass durch jede Ver schaltung atomarer Werkzeugdienste zu komplexeren Diensten letztendlich Ab l ufe spezifiziert werden in denen potenziell prozessrelevantes Wissen hinterlegt ist und die somit direkt auf die Arbeitsmethodik des Benutzers r ckwirken Hier bei ist es zun chst unerheblich ob die miteinander kombinierten Dienste von ein und dem selben Werkzeug stammen oder ber Werkzeuggrenzen hinweg mitein ander verkettet werden Die Komposition von elementaren zu komplexen Diensten erfolgt durch den Prozessrelevante Roordinierten Aufruf von Werkzeugdiensten der ber geeignete Kommunikations Werkzeugbeziehungen mechanismen zu realisieren ist In Hinblick auf die Adaptabilit t an sich ndernde eee Prozesse ist bei der Bewertung existierender L sung
222. den unterst tzten Kom mandoelementen dem Shortkey Crtl I und dem Pulldown Men Edit darge stellt Weiterhin steht die Werkzeugkategorie ER Editor mit gemeinsamen Kon zepten aus dem Prozessmodell in Beziehung mit der Aktion ErzeugeIsaLink und dem Produkt IsaLink Die Definitionen aus dem Prozess und Werkzeugmodell werden mithilfe der Assoziationen aus dem Umgebungsmodell zueinander in Beziehung gesetzt O f hrt AK aus entsprechend der Konsistenzbedingung AK1 siehe Ab kann der ER Editor automatisch dem Ausf hrungskontext AK ErzeugelsaLink zugeordnet werden da er im aktuellen Umgebungmo schnitt 5 5 2 1 dell die einzige Werkzeugkategorie darstellt welche die mit dem Ausf h rungskontext assoziierte Aktion ErzeugeIsaLink anbietet Konsistenzbe dingung AK2 wird erf llt da die input Produkte der Aktion ErzeugeIsA Link von der Situation des assoziierten Kontexts ZweiEntit ten sub summiert wird In hnlicher Weise gen gt das Modell auch der Konsis tenzbedingung AK3 da die Definition der output Produkte IsaLink im Werkzeugmodell mit der ndert Assoziation im Prozessmodell konform ist in Abb 22 aus Platzgr nden nicht explizit dargestellt OD f hrt EK aus ber einen Link vom Typ f hrt EK aus wird der Entschei dungskontext definiert Bei der Ausf hrung dieses Entscheidungskontexts
223. deninge nieurs und des Umgebungsentwicklers und skizzieren offen gebliebene Fragen die den Ausgangspunkt f r zuk nftige Forschungsarbeiten bilden k nnen Zum Abschluss dieses einleitenden berblicks wollen wir noch auf die Quer bez ge der vorliegenden Arbeit zu mehreren anderen Arbeiten hinweisen die am Lehrstuhl f r Informatik V an der RWTH Aachen entstanden sind In der Disser tation von Peter Haumer wird eine Umgebung zur multimedialen Szenarienanalyse im Requirements Engineering beschrieben Haum00 die auf Grundlage des hier beschriebenen PRIME Frameworks realisiert wurde Ralf D mges untersuchte in seiner Doktorarbeit den zur Prozessintegration und Werkzeuganpassung komple ment ren Aspekt der Nachvollziehbarkeit und Prozessdokumentation D mg99 In der Habilitation von Klaus Pohl wurde ein konzeptuelles Rahmenwerk f r die kontinuierliche Dokumentation von Requirements Engineering Prozessen entwi ckelt welches die in dieser und den vorgenannten Arbeiten entstandenen Ergeb nisse zusammenf hrt Pohl99 2 1 Ein Klassifikationsmodell fur Prozessunterstutzungsfunktionen 9 Prozessorientierte Unterstutzungsfunktionen zur Prozessunterst tzung vor und kontrastieren diese mit unserer Zielvor stellung einer Entwurfsumgebung in der prozessintegrierte Werkzeuge den Ent wickler am technischen Arbeitsplatz feingranular kontextsensitiv und adaptabel unterst tzen n diesem Kapitel nehmen wir eine Bestandsaufnahme existierend
224. der Planung und Koordi nation von Prozessen vgl auch Abschnitt 1 1 1 und aus Sicht des technischen Entwicklers der Prozessunterst tzung zum einen ber PZEU eigene Assistenz werkzeuge wie Agenda Manager oder Arbeitskontexte erf hrt und zum anderen Tab 6 Prozessunterst tzung in durch den automatischen prozessmodellgesteuerten Aufruf von Entwurfswerk pzEUYen zeugen unterst tzt wird Art der Projekt Integrations Kontext Anpassbar Unterst tzungsmodi Prozessunterst tzung ebene tiefe bezogenheit keit rechnerbasiert se rechnerbasiert in passive Beratung aktive Anleitung erzwingend lenkend automatisierend 2 5 5 ao E technisch statisch dynamisch konfigurierbar anderbar PZEU Planung und Koordination Agendamanager Werkzeugaufruf O Unterst tzte Projektebene PZEUen zielen ebenso wie Workflow Managementsysteme f r betriebliche Abl ufe in erster Linie auf das Management von Prozessen ab d h auf die Planung Ressourcenkontrolle und Koordination der Entwicklerkooperation innerhalb eines Projekts Die Konzentration auf die Projektmanagementebene manifestiert sich u a darin dass in PZEUen Entwurfsprodukte nur auf der grobgranularen Dokumentenebene modelliert werden und lediglich gr ere Aufgabeneinheiten wie Erstellung eines ER Modells als atomare Prozessschritte betrachtet werden Die im Allgemeinen grobgranulare Sicht auf den Entwick
225. der Prozessunterst tzung f hren Dennoch lassen sich sogar in den fr hen Phasen der Softwareentwicklung Anforderungsdefinition Entwurf durchaus wohlverstandene Routineaktivit ten mit repetitivem Charakter identifizieren die von einem lenkendem oder gar auto matisierendem Prozessunterst tzungsansatz profitieren k nnen Pohl96 Eine strikte Einflussnahme der Prozessunterst tzung auf die Prozessausf hrung ist auch f r solche Aktivit ten angebracht die aufgrund vertraglicher Vereinbarungen nach bestimmten Vorgaben oder Standards ausgef hrt werden m ssen In vielen Qualit tsstandards wird beispielsweise die Nachvollziehbarkeit der Entwicklung und Wartung systemkritischer Komponenten gefordert vgl z B ISO 9000 3 IISO 91 das V Modell BrDr95 oder den DoD Standard 2176A DoD 88 Um dies zu gew hrleisten k nnte die Prozessunterst tzung den Prozess bei spielsweise dergestalt lenken dass der Entwickler begleitend zu jeder nderung des Systemmodells die zugrunde liegenden Entwurfsentscheidungen zu protokol lieren hat D mg99 2 2 Bewertung existierender Ans tze Wir wollen nun existierende Ans tze zur Prozessunterst tzung anhand des im vorangegangenen Abschnitt vorgestellten Kriterienkatalogs klassifizieren und einander gegen berstellen Unter Prozessunterst tzung kann man zun chst alle organisatorischen und technischen Ma nahmen verstehen die zu einer effizienteren Koordination Kon trolle und Ausf hrung von Ent
226. der entweder einen z ternden oder transformierenden Charakter haben kann Im ersten Fall werden die an der Eingangsschnittstelle vorliegenden Produktteile einfach an die Aus gangsschnittstelle weitergereicht sofern sie den Bedingungen des Situationsaus drucks gen gen Die Ein und Ausgangsschnittstelle haben dann eine identische Struktur d h sie bestehen aus einer gleichen Anzahl von In und Out Produkttei len die in Rolle und Typ jeweils paarweise bereinstimmen Bei einem transfor mierenden Situationsausdtuck referenzieren die In Produktteile einen bestimmten Ausschnitt des Produktmodells innerhalb dessen dann die Produktkonstellationen ermittelt werden die den Situationsausdruck erf llen Abb 27 zeigt ein Beispiel f r eine solche Situationskomponente die Situation UnconnectedEntities soll f r alle Entit ten e innerhalb eines ER Diagramms erd g ltig sein die nicht mit einer anderen Entit t ber eine Beziehung verbunden sind In diesem Fall referenziert das Produkt erd den aktuell relevanten Produkt ausschnitt ein ER Diagramm inklusive aller darin enthaltenen Elemente wie Entit ten Beziehungen Attribute etc Der Situationsausdruck wird durch eine entsprechende SQL Anfrage auf der Produktdatenbank implementiert An der Ergebnisschnittstelle liegen die Entit ten des ER Diagramms erd vor die den Situationsausdruck erf llen d h die Ergebnisse der Anfrage Zu beachten ist dass wir nicht vorschreiben mit welchem Formalismus
227. der werkzeugrelevan ten Anteile des Umgebungs und Werkzeugmodells Die Anwendung des GAR PIT Framework zur Entwicklung spezifischer Werkzeuge wird in Abb 34 durch die Werkzeuge W7 W repr sentiert Die interne Architektur des GARPIT Fra meworks und die Schnittstellen zur Anbindung spezifischer Werkzeugfunktionali t t werden in Abschnitt 7 3 im Detail behandelt Als Grundausstattung sind in PRIME bereits eine Reihe voll funktionsf hi ger GARPIT basierter Werkzeuge enthalten die sich unabh ngig vom konkreten Anwendungsbereich f r unterschiedliche Modellierungsumgebungen als schr n tzlich erwiesen haben und daher allgemein verwendbar sind Diese Werkzeuge sind ebenso wie jedes andere PRIME Werkzeug innerhalb des Werkzeugmodells modelliert erben vom GARPIT Framework eine entsprechende Interpreterkom ponente und die Schnittstelle zur Prozessmaschine und sind somit vollst ndig prozessintegrierbar Im Folgenden skizzieren wir kurz die Funktionalit t dieser Werkzeuge siehe Abb 35 Hypertext Editor F r die Erfassung und Strukturierung von textuellen Dokumenten wie informal notierten Anforderungen und Spezifikationen Sitzungsprotokollen oder Modell und Softwaredokumentationen steht in PRIME ein Hypertext Editor zur Verf gung siehe Abb 35 oben links Hypertexte lassen sich in einzelne Textknoten zerle gen die disjunkte Teilst cke des Textes beinhalten Gruppen von nicht notwen digerweise zusammenh ngenden Hyperte
228. des Effective Guidance for Process Participants In Proc 5th Intl Conf on the Soft ware Process Computer Supported Organizational Work Lisle Illinois USA June 14 17 1998 S 11 25 Kelly St Lyytinen K und Rossi M MetaEdit A Fully Configurable Multi User and Multi Tool CASE and CAME Environment In Procs 7th Intl Conf on Advanced In formation Systems Engineering CAiSE 95 Jyvaskyla Finland June 1995 S 1 21 Kelter U Integrationsrahmen f r Software Entwicklungsumgebungen Informatik Spektrum 16 S 281 285 1993 Kemper A und Moerkotte G Basiskonzepte objektorientierter Datenbanksysteme Informatik Spektrum 16 S 69 80 1993 Kernighan B W und Ritchie R P The UNLX Programming Environment Prentice Hall Englewood Cliffs 1984 Kelly St und Smolander K Evolution and Issues in metaCASE Information and Software Technology 38 S 261 266 1996 Kiper J D A Framework for Characterisation of the Degree of Integration of Software Tools Journal of Systems Integration Vol 4 S 5 32 1994 Kiesel N Schuerr A und Westfechtel B GRAS A Graph Oriented Software Engineering Database System Information Systems 20 1 S 21 51 1995 Kiczales G des Rivi res J und Bobrow D G The Art of the Metaolject Protocol MIT Press 1991 Klamma R Praskriptive Prozessbeschreibungen Definition Implementierung und Validierung in PRO ART Diplomarbeit RWTH Aachen 1995 Kobr
229. des Pro jektmanagements w hrend die Konsequenzen der Prozessmodellinterpretation f r die am Arbeitsplatz zur eigentlichen Aufgabendurchf hrung verwendeten Ent wicklungswerkzeuge bislang kaum betrachtet wurden In solchen Systemen ist das Verhalten der Werkzeuge weitgehend von der modellgesteuerten Prozessanleitung entkoppelt In der vorliegenden Arbeit untersuchen wir wie man von einer Prozesszentrie rung zu einer Prozessintegration von Entwicklungsumgebungen gelangt Ausgehend von sechs zentralen Integrationsanforderungen entwickeln wir einen integrierten Modellierungsansatz bei dem ein existierendes Rahmenmodell f r kreative Pro zesse um Konzepte zur Werkzeugmodellierung angereichert wird Mithilfe anpass barer Querbez ge zwischen Prozess und Werkzeugmodell wird ein organisations und projektspezifisches Umgebungsmodell konfiguriert das die Auswirkungen von Prozessen auf das Werkzeugverhalten kl rt und die Grundlage f r feingranulare interpretative Anpassbarkeit darstellt Umgesetzt wird der Ansatz in Form eines generischen objektorientierten Implementierungs Frameworks bei dem gro e Teile einer prozessintegrierten Umgebung bereits als vorgefertigtes leicht erweiterbares Softwareger st vorliegen Neben der effizienten Neuentwicklung unterst tzt das Framework auch die Ein bindung existierender Werkzeuge was wir am Beispiel von drei weit verbreiteten Fremdwerkzeugen demonstrieren Insgesamt wird die Praktikabilit t des Ansatz
230. di tor die nachtr gliche Modifikation und das Hinzuf gen von L sungsvorschl gen und Argumenten was gegebenenfalls zur Revision einer einmal getroffenen Ent scheidung f hrt Wie beim Hypertexteditor k nnen auch die Teilkomponenten einer Entscheidung Problemstellung L sungsvorschl ge Argumente im Pro duktmodell des Entscheidungseditors feingranular referenziert werden BE Prim Dein ct nu F sse Document Edit Views Links Display Tools Preferences Document Edit Tools Preferences Help Eo fe ENE Fa issue Reaktor Holdup Welche Phasen sollen als Reaktor Holdup ber cksichti decision nur Fl ssigkeit Die Dampiphase soll bei der Bestimmung des Holdups r Die Dampiphase soll bei der Bestimmung des Holdups r soll bei der Bestimmung des Holdups r chosen position nur Fl ssigkeit Die Dampfphase soll bei der Bestimmung des Holdups pro argument Es sind weniger numerische Probleme zu erwarten Hypertext pro argument H20 Zufluss 1 5 contra argument Bei einem hohen Dampfanteil im Reaktor sind falsche Ergebnisse zu erwarten PRIME Dependency Editor Browser Noname Document Edit Tools Preferences Help Context Produkt a i ur Reaktortyp CSTR Es handelt sich um eine Fl ssigphasenreaktion Executable Context Simulation Model CSTR Simulation Result CSR CSTR aboruntersuchung DEP_Banflicts i DEP_Operationalises getypte x
231. die Argumente die f r oder gegen eine weitere Verfeine rungsalternative sprechen modifiziert und erg nzt sowie die damit verbundenen nderungen protokolliert werden 8 3 1 2 Prozessmodellierung Plankontext RefineProcessDeviceWithDecision Die zuvor beschriebene M Prozessanleitung wird durch den in Abb 74 dargestell ten Plankontext RefineProcessDeviceWithDecision realisiert F r die Modellie rung dieses Plankontexts verwendet der Methodeningenieur SLANG Netze Dieser Formalismus eignet sich gut zur Modellierung der in dem Ablauf auftreten den mehrstufigen Datenabh ngigkeiten Notation Transitionen die an eine Kontextkomponente gebunden sind sind dadurch gekennzeichnet dass der Name des Kontextes als Transitionsnamen angegeben ist wohingegen ungebundene Transitionen die z B f r die Modellierung von Verzweigungen erforderlich sind namenlos sind Eine rot dargestellte Transition verf gt ber einen W chter mit dem logische Bedingungen an die Stellen im Vorbereich gestellt werden Der Vor und Nachbereich einer gebundenen Transi tion entsprechen der Ein bzw Ausgangsschnittstelle wobei an der Kante zwi schen der Stelle und der Transition jeweils der Rollenname angegeben ist Stellen die nicht an einen Situationsteil gebunden sind sind dadurch gekennzeichnet dass der Rollenname in lt lt Klammern gt gt steht wohingegen der Rollenname einer Stelle die als Situationsteil einer Stellvertreterschnitts
232. die Planung Koordination und Kontrolle des Gesamt 16 2 Prozessorientierte Unterstutzungsfunktionen prozesses ben tigt wird tritt auf der Arbeitsplatzebene die Anleitung des Ent wicklers bei der Durchf hrung einzelner Aufgaben in den Vordergrund Granularit t der Arbeits Folglich unterscheidet sich die Grannlarit t der betrachteten Arbeitseinheiten auf den einheiten beiden Projektebenen W hrend auf der Projektmanagementebene die im Ent wicklungsprozess auftretenden Aufgaben nur soweit dekomponiert werden wie es f r die Koordination unterschiedlicher Entwickler und die Definition von Meilen steinen erforderlich ist liegt auf der Arbeitsplatzebene der Fokus auf der Unter st tzung feingranularer Arbeitsabl ufe Beispielsweise k nnte eine vom Projekt management definierte Aufgabe lauten ein Klassendiagramm f r ein bestimmtes Teil System zu spezifizieren w hrend sich der Entwickler auf der Arbeitsplatz ebene daf r interessiert welche Optionen ihm bei der Verfeinerung einer Klasse zur Verf gung stehen z B Hinzuf gen eines diskriminierenden Attributs oder Bildung einer Subklasse Granularit t der Ent Als Folge der unterschiedlichen Granularit t der betrachteten Arbeitsschritte wurfsprodukte differiert auch die Granularitat der Entwurfsprodukte die dutch die Prozessunterst t zung ber cksichtigt werden W hrend auf der Projektmanagementebene Produkte typischerweise nur auf Dokumentebene als Einheiten der Arbeitsteil
233. die Prozessunterst tzung in Beziehung zu setzen und die An wendbarkeit bestimmter Handlungsanweisungen zu erkennen Beispielsweise k nnen in einem Projekthandbuch sehr detaillierte Handlungsanweisungen f r die unterschiedlichsten Problemsituationen aufgelistet sein siehe Abschnitt 2 2 1 Dennoch betrachten wir Handb cher als statische Prozessunterst tzungsans tze da es ausschlie lich in der Verantwortung des Entwicklers liegt die aktuell an wendbaren Prozessdefinitionen bestimmen Im Unterschied dazu sprechen wir bei einem kontextsensitiven Hilfesystem von einem dynamischen Unterst tzungssys tem siehe Abschnitt 2 2 2 da dieses bei seinen Erkl rungen den aktuellen Pro zesskontext z B die Dialogsituation in der sich der Benutzer in der Interaktion mit der Entwicklungsumgebung befindet ber cksichtigt Charakterisierung des Zur Charakterisierung der aktuellen Prozesskontexts k nnen eine ganze Reihe Prozesskontexts von Merkmalen herangezogen werden Das prim re Merkmal zur Bestimmung des Prozesskontexts ist der aktuelle Zustand des in Bearbeitung befindlichen Ent wicklungsprodukts Hier kann sich der Zustand auf inhaltlich strukturelle Eigen schaften beziehen z B ob ein SA Modell syntaktischen Bedingungen keine un verbundenen Datenfl sse und heuristisch begr ndeten Richtlinien nicht mehr als sieben Prozesse pro Datenflussdiagramm gen gt auf inhaltlich semantische Eigenschaften z B ob ein ER Modell die in f r eine Anwe
234. digen Informationen beschr nkt Anders als beim Transformationsansatz ist beim Schnittstellenansatz auch eine Laufzeitunterst tzung bei der Kooperation der jeweiligen Prozesssprachen Inter preter erforderlich Wenn ein Komponente A ein Komponente B verwendet dann wird an der Stelle der Verwendung die Ausf hrung an den Interpreter der Sprache B delegiert F r die Integration von Prozesssprachen Interpretern in der Leitdo mane k nnen die von der WfMC oder OMG entwickelten Standards verwendet werden siehe Abschnitt 6 2 1 6 3 Komponentenorientierte Darstellung des NATURE Prozessmodells 143 Der wesentliche Nachteil eines komponentenbasierten Ansatzes besteht darin dass der Verzicht auf einen einheitlichen Basisformalismus die formale Analyse kompositer Prozessfragmente erschwert Es ist jedoch zu erwarten dass sich das Verhalten eines kompositen Prozessfragments hinsichtlich bestimmter kompositio naler Eigenschaften z B Erreichbarkeit des Endzustands aus den Eigenschaften der Komponenten ableiten l sst Auf eine formale Untersuchung solcher Frage stellungen m ssen wir jedoch im Rahmen dieser Arbeit aus Aufwandsgr nden verzichten Da bei uns weniger die Analyse als vielmehr die Ausf hrung von Prozessfrag menten im Vordergrund steht ziehen wir in dieser Arbeit einen auf Schnittstellen basierenden Ansatz einem Transformationsansatz vor Im folgenden Abschnitt erarbeiten wir dazu eine komponentenbasierte Darstellung des NATURE Pro
235. durch Ereignismeldungen ausgel st Das Wissen wie auf ein bestimmtes Ereignis zu reagieren ist liegt bei den Empf ngern Da der Produzent einer Nachricht von den Empf ngern entkoppelt ist besteht ein gro er Vorteil des Ansatz in der einfachen Austauschbarkeit von Werkzeugen und der Erweiterbarkeit um neue Werkzeuge die in den Nachrichtenstrom einge klinkt werden k nnen ohne dass dazu nderungen an den existierenden Werk zeugen erforderlich sind Voraussetzung ist allerdings eine vorherige Einigung auf einen Satz von Standardnachrichten die von allen zu integrierenden Werkzeugen verstanden werden Da Nachrichten in der Regel Parameter beinhalten die auf Produktdaten verweisen ber hrt die Integration ber einheitliche Nachrichten protokolle auch den Bereich der Datenintegration vgl Abschnitt 3 3 2 Erweiterbarkeit Mittlerweile haben Message Broadcasting Mechanismen eine recht weite Verbreitung in einer Reihe von Entwurfsumgebungen gefunden Die unterschied lichen Ans tze unterscheiden sich vor allem durch den Informationsgehalt und Standardisierungsgrad der Nachrichten sowie durch zus tzliche Hilfsmittel zur Einbindung von Fremdwerkzeugen Als Mutter aller Message Broadcasting An s tze gilt die im akademischen Umfeld entstandene FIELD Umgebung die von S Reiss an der Brown University entwickelt wurde Reis90 Reis90a Hierbei handelt es sich um eine Programmierumgebung in der vor allem einfache Kom mandozeilen orientie
236. e Durchf hrungs und die Leitdom ne die ber den Austausch von Nachrichten gekoppelt sind Wir k nnen dadurch sehr sch n beschreiben in welchen Zust n den Nachrichten verschickt werden bzw ankommende Nachrichten sinnvoll interpretiert werden k nnen und welche Zustands berg nge dabei auf Seiten der Durchf hrungs bzw Leitdom ne ausgel st werden Das hier dargestellte Interak tionsprotokoll beruht auf den in Pohl96 Weid95 Klam95 Poh 99 be schriebenen Ans tzen ist jedoch umfassender und bem ht sich gleichzeitig um eine st rkere Vereinheitlichung und Vereinfachung der Zustandsdiagramme und Nachrichtentypen Das Zustandsdiagramm in Abb 43 gibt eine stark vergr berte Sicht auf den Gesamtzustand einer PRIME basierten Umgebung wieder Wir benutzen hierbei das Strukturierungshilfsmittel der Und Verfeinerung durch das wir nebenl ufige gleichzeitig aktive Sub Zust nde darstellen k nnen Die Region oberhalb der gestrichelten Linie repr sentiert das Verhalten des Framework Objekts Tool in der Durchf hrungsdom ne w hrend die untere Region den Zustand des Framework Objekts ProcessEngine in der Leitdom ne beschreibt Diese beiden Objekte kollaborieren miteinander d h Zustands berg nge sind in den beiden konkurren ten Teil Zustandsdiagrammen durch den Austausch von Nachrichten gestrichelte Pfeile miteinander gekoppelt Das NATURE Prozessmodell induziert eine prinzipielle Unterscheidung zwi schen zwei Zust nden
237. e TIL einer Erweiterung der CORBA Interface Definition Language IDL spezifiziert MediatorService Synchronizer Das in Frol93 FrAg96 vorgestellte Synchronizer Konzept ist ein Constraint basiertes Sprachmittel f r die Multiobjekt Koordination Das Haupteinsatzgebiet dieses Ansatzes liegt in der Zugriffssteuerung und kontrolle von Klienten auf einen gemeinsamen Server in Hinblick auf die Atomaritat die temporale Ordnung und den gegenseitigen Ausschluss multipler Aufrufe an den Server Gluonen In Pint93 werden mit den so genannten G uonen spezielle Objekte zur Kom munikationsvermittlung zwischen Objekten eingef hrt Ein Gluon kapselt die Interaktion zwischen einem Client Objekt und einem Server Objekt und kann insbesondere Anpassungen am Interaktionsprotokoll vornehmen Da ein Gluon selbst wieder ein Objekt darstellt kann es seinen Zustand speichern und so die Interaktionshistorie bei der Kommunikationsvermittlung einbeziehen Die Defini tion von Gluonen findet im Gegensatz zu den vorgenannten Ans tzen nicht auf einer Spezifikationsebene sondern auf der programmiersprachlichen Ebene statt Gluonen k nnen in einer Hierarchie angeordnet werden die die Wiederverwen dung und Spezialisierung von Interaktionsprotokollen unterst tzt Als Beispiel wird in Pint93 der Einsatz von Gluonen innerhalb eines Frameworks f r Finanz anwendungen angef hrt Architekturbeschrei Aus dem Bereich der Software Architekturmodellierung Nagl90 Sh
238. e Aktivit t Produkt Dokument Rolle Arbeits kontext etc gepr gt f r eine Gegen berstellung der wesentlichen Elemente ver schiedener Prozessmodellierungssprachen siehe z B Lonc94a ABGM93 88 3 Integrationsansatze McCh95 Lott93 FeHu93 CoJa99 Eine explizite Repr sentation von Werkzeu gen als Objekten erster Klasse findet dagegen im der Regel nicht statt Stattdessen spezifizieren viele prozesszentrierte Umgebungen den Aufruf ex terner Programme Werkzeuge Standardapplikationen in der Leitdom ne ber generische execute oder call Statements deren Argumente die Namen von Werkzeugen und eventuell zus tzliche Startparameter beinhalten Charakteristisch ist dass diese Statements typischerweise als Attribute von Aktivit ten oder in deren Implementierungsspezifikation angegeben werden Werkzeuge werden im Sinne der Blackbox Integration siehe Abschnitt 3 2 nur grobgranular und nicht auf der Ebene einzelner Dienste referenziert Abb 14 zeigt angelehnt an Bohm98 die Referenzierung von Werkzeugen in einem Prozessfragment Die Darstellung bedient sich einer Pseudocode Notation die jedoch die typischen Merkmale der in PZEU und WFMS praktizierten Art der Werkzeugeinbindung gut illustriert Abb 14 ProcessFragment SimpleProcessFragment Werkzeugeinbindung in SubStructures Prozessmodellierungs DataEntry Activity EnterData sprachen Pseudocode DataProcessing Activity ProceedData vgl B6hm98 ControlFlow SEQUENC
239. e Durchf hrung von Entscheidungskontexten in dem Werkzeug m glich Allerdings k nnen die Entscheidungskontexte dann nur die origin re Funktionalit ten des zu integrierenden Werkzeugs als Alternativen ent halten da keine zus tzlichen Kommandoelemente f r extern definierte Plankon texte oder Kontexte anderer Werkzeuge in die Benutzeroberfl che eingef gt werden k nnen 7 4 2 Wrapper Architektur Der Prozessintegrations Wrapper vermittelt die Interaktion zwischen der Pro zessmaschine und dem zu integrierenden Werkzeug Ihm fallen dabei zwei we sentliche Aufgaben zu Er interpretiert erstens die f r das Werkzeug relevanten Anteile des Umgebungsmodells um Kontextaktivierungen durch die Prozessma schine oder den Benutzer selbst auf entsprechende Aktionsaufrufe oder Ein schr nkungen der Interaktionsm glichkeiten umzusetzen und Benutzerereignisse mit existierenden Kontextdefinitionen abzugleichen und gegebenenfalls den Auf ruf eines aktivierten Kontexts zu initiieren Zweitens wickelt der Wrapper die Kommunikation mit der Prozessmaschine gem dem in Abschnitt 7 2 beschrie benen Interaktionsprotokoll ab Diese beiden Aufgaben entsprechen exakt den Funktionen die im GARPIT Framework von den Teilsystemen ContextManager bzw StateMana ger MessageInterface wahrgenommen werden Daher liegt es nahe das GAR PIT Framework als Basis eines generischen Wrapper Frameworks weiterzuver wenden Als u erst hilfreich erweist sich hier dass
240. e L sung bekannt die alle 272 9 Schlussbetrachtungen genannten Anforderungen in einem ganzheitlichen Ansatz zusammenf hrt und umsetzt O Integrierte Prozess und Werkzeugmodellierung Der in dieser Arbeit vorgeschla gene L sungsansatz zur umfassenden Umsetzung der genannten Anforde rungen basiert auf der Grundidee Wissen ber Prozesse und Werkzeuge gleichberechtigt in konzeptuellen Modellen explizit zu erfassen und diese Modelle miteinander zu verzahnen F r die fragmentweise Modellierung kreativer Arbeitsprozesse sind wir von einer existierenden Prozessmodel lierungssprache dem kontextbasierten NATURE Prozessmodell ausge gangen Diese wurde erg nzt um eine Werkzeugmodellierungssprache in der die Werkzeuge durch Definition ihrer Basisfunktionalit ten und ihres Interaktionsverhaltens spezifiziert werden k nnen Der modulare Aufbau des Gesamtmodells aus einem Prozess und einem Werkzeugmodell er m glicht eine saubere Trennung zwischen prozessrelevanten und werk zeuginh renten Aspekten Das hei t dass Prozesswissen in Form von Kontextdefinitionen zun chst unabh ngig von einer Beschreibung der Werkzeuge definiert werden kann und umgekehrt Werkzeuge prozessneut ral beschrieben werden k nnen Erst durch die Zuordnung zwischen Pro zess und Werkzeugmodell innerhalb des so genannten Umgebungsmodells wird eine spezifische prozessintegrierte Umgebung konfiguriert O Interoperabilit t von Prozesssprachen Das NATURE Prozessmodel
241. e der Signaturen aller ber die programmierbare Laufzeitschnittstelle aufrufbaren elementaren Dienste beschr nken Hierbei ist es zun chst gleichg ltig ob 86 3 Integrationsansatze die Signaturen im klassischen prozeduralen Stil dargestellt werden oder im objekt orientierten Sinn als Objektmethoden bestimmter Werkzeugobjekte aufgefasst werden Die Modellierung der Parameter ber hrt den Bereich der Datenintegra tion Es muss sichergestellt werden dass sich die Produkttypen der Dienstpara meter auch im Produktmodell der Modellierungsdom ne ber cksichtigt werden Wie in Abschnitt 3 3 2 bereits erl utert wurde gibt es hier zwei denkbare Vorge hensweisen Entweder arbeiten Prozessmaschine und Werkzeuge auf den gleichen Daten in einem gemeinsamen Repository Die bergebenen Parameter beziehen sich dann direkt auf Daten im gemeinsamen Repository Im anderen Fall wird in Modellierungsdom ne auf der Schemaebene der prozessrelevante Teil der Werk zeugdatenmodelle nachmodelliert wobei dann die Parameter lediglich Referenzen auf externe Daten der Werkzeuge darstellen die nicht direkt im Repository der Modellierungsdom ne verwaltet werden Aufbauend auf einer konzeptuellen Beschreibung der Werkzeugdienste k n nen dann im Prozessmodell elementare Dienste einzelnen Prozessschritten zuge ordnet werden Vorbedingungen f r die Aktivierung von elementaren Diensten festgelegt werden und Beratungsdienste d h Arbeitsmodi definiert werden 3 3
242. e l st den bergang in den Zustand Waiting for Lock Request Transition 2 und damit in den Super Zustand Process Enactment Active aus Dieser Zu stands bergang ist mit dem Versand einer LockRequest Nachricht assoziiert welche die f r die Plankontext Ausf hrung notwendigen Werkzeuge f r die anste hende angeleitete Prozessdurchf hrung vorbereiten soll Sobald die Werkzeuge durch eine LockOKResponse Nachricht ihre Bereitschaft signalisiert haben Tran sition 3 wird f r den angeforderten Plankontext ein Interpreter Thread gestartet und die eigentliche Plankontext Ausf hrung beginnt Zustand Running Process Enactment Active x N Exception Handling Checking Abort Request Im Zustand Deducing Context ermittelt die Prozessmaschine den als n chstes ausf hrbaren Kontext c Handelt es sich bei dem ermittelten Kontext c um einen Plankontext wird ein weiterer Plankontext Interpreter abgespaltet in Abb 45 nicht dargestellt Ansonsten c ist ein Ausf hrungs oder Entscheidungskontext setzt die Prozessmaschine eine ContextRequest c Nachricht an die Durchf hrungsdom ne ab Transition 4 und geht in den Zustand Waiting for Context Response ber Nach Erhalt einer ECResponse result bzw CCResponse result Nachricht geht die Prozessmaschine wieder in den 76 Im Zustand Running interagiert das bergeordnete Prozessmaschinen Framework st ndig mit dem aktuell aktiven Plankontext Interpreter Da das Zustandsdi
243. ecision Da dieses M Prozessfragment in SLANG modelliert ist wird in der Sprachelemente Schicht des Prozessmaschinen Rahmenwerks das entspre chende SLANG Netz geladen und instanziiert Die ersten beiden Schritte des SLANG Netzes entsprechen Ausf hrungskon texten die von der Prozessmaschine automatisch im Flie bildwerkzeug aktiviert werden Dabei wird f r den ausgew hlten VT Prozessschritt Separation eine VT 266 8 Anwendungen Abb 78 Ausf hrung des Plankontexts Refine ProcessDeviceWith Decision Prozessgruppe kreiert bzw eine eventuell schon vorhandene VT Prozessgruppe ermittelt EC_FBW CreateProcessGroup und alle bereits existierenden Verfeinerun gen dieser Gruppe angefragt EC F BW _GetRefinementsOfGroup Im vorliegenden Fall gab es bereits eine Verfeinerung f r Separation so dass der Ausf hrungs kontext EC FBW GetRefinementsOfGroup eine nichtleere Liste von Verfeinerungen RefinementList zur ckliefert Diese enth lt eine Verfeinerungsgruppe mit dem Namen Realization of Separation by Destillation Pki Plan Context Editor PC_FBW_RefineProcessDeviceWithDecision Document Edit Tools Preferences oe SHEE EC_FBW_GetRefinementsOfGroup 4 X gt Welcome to the PRIME plan context editor Abb 78 zeigt den Zustand der Plankontextinterpretation nach diesen ersten bei den Schritten Gem der aktuellen Belegung der Stellen und de
244. ecsaecaecsaeceseenaeenseeees 139 6 2 3 1 Open Process Components cccccceecceeseeceeseceeeeeceeeeeeneceeeeeeeneeeeas 139 6 2 3 2 Bynode senken nenne fea pus kenne 140 6 2 3 3 Rollenkooperation eeesssesseessnesneesnsennnennneenneenneennnennnennnnnnnnnnnnn 140 6 2 4 Diskussion und Schlussfolgerungen uusnseeseeseenneeenneeenee nennen 141 6 3 Komponentenorientierte Darstellung des NATURE Prozessmodells 143 6 3 1 Prozesskomponenten ccccccesccesscessceeseeeeceeeeeeeeeeseeeseeeseecaecaeceseenseenseenes 144 6 3 2 Schnittstellenmetamodell cecccecccesscessceeeceeceeeeeeeseeeseeeeeeaecseeeseeeseens 147 6 3 3 ZusamimMentassun e oss a te ove chesderes Gh ssevdeos bya tede E 152 6 4 Schnittstellenbindung ssesssesssesssesssesssesssessseossesssesssesssecssocssoossosssoosso 152 6 4 1 M2 Mod ll inoars apra aea in San elemente 153 6 4 1 1 Prozesssprachen M2 Modell cccecceesscesseeesceeseeeseessecsseceseeneenseenes 153 6 4 1 2 Bindungs M2 Modell cccecccessceseesseeeeeeeseeeeeeeeeaecssecneeneenseenes 154 6 4 2 Integrationsmethodik inei e e a a a i 157 642 1 berblick cenenunste ninhie 157 6 4 2 2 Beispiel Integration von SLANG Netzen unnenneenenenneesnneennnenn 158 6 5 Fazit ccscsievasssissaseascacsens sasdtceucdssddstenceusesansscsagsastessencssesoeednesuagadeessboscsasensovss 162 Teil 3 Umsetzung und Anwendungserfahrungen 165 7 DAS PRIME RAHMENWERK
245. egra tion f r die er eine Skalierung der entsprechenden drei Integrationsachsen ein Do EN f hrt So wird beispielsweise die Datenintegrationsachse danach unterteilt ob in men einer Entwurfsumgebung das Dateisystem eine Datenbank oder ein dediziertes Objektmanagementsystem zum Austausch von Daten zwischen Werkzeugen verwendet wird Die Position eines Integrationsmechanismus auf der jeweiligen Achse suggeriert zumindest implizit seine G te Je nach den vorhandenen Integra tionsmechanismen lassen sich so unterschiedliche Entwurfsumgebungen innerhalb des dreidimensionalen Raums einordnen Eine solche Einordnung ist f r den Vergleich verschiedener Produkte zwar hilfreich hat aber wegen der groben Ein teilung nur bersichtscharakter 3 1 3 Integration im Spannungsfeld von Basismechanis men und Prozessen Die von Wasserman vorgenommene Separierung der einzelnen Integrationsas pekte wurde von den meisten Autoren als sehr hilfreich empfunden und gilt heute als allgemein akzeptiert Kritik entz ndete sich allerdings daran dass Wasserman bereits die Pr senz bestimmter Integrationsmechanismen mit Integration gleichsetzt ohne auf semantische Aspekte einzugehen Bro 94 ThNe92 Thomas und Nejmeh setzen in ThNe92 zwar auf Wasserman s Klassifikati onsmodell auf machen aber Integration nicht mehr am Vorhandensein bestimm ter Integrationsmechanismen fest sondern fassen sie als Charakteristikum der Beziehung zwischen zwei oder mehreren Komp
246. eile Produkttypen des zugrunde liegenden Produktmodells CcxtProductSitPart Weiterhin sind Basistypen wie integer double string oder boolean CcxtValueSitPart m glich sowie listenwertige Auspr gungen der vorgenannten Typen CcxtListSitPart wobei mithilfe der Attribute min und max die Kardinalit t eines listenwertigen Situationsteils spezifi ziert werden kann CextSituationDesc ordered role CcxtSituationPart A CcxtProductSitPart CcxtValueSitPart CextListSitPart amp ValueType enum Integer Double Boolean String initval amp min Integer max Integer _L7 are based_on gt V CmapProductType Der Methodenmodellierer kann neue Situationstypen entweder direkt mithilfe des NATPROC Editors siehe Abschnitt 7 1 2 1 in das Prozess Repository einpflegen oder auch textuell definieren Textuelle Situationsspezifikationen werden dann von einem Situationscompiler in entsprechende Eintr ge im Prozess Repository ber tragen und m ssen den folgenden in EBNF notierten Syntaxregeln gen gen sit_spec situation identifier with sit part end sit_part identifier sit _part_type sit part type product identifier list num literal num literal sit part type value value type value_type integer double string boolean Abb 57 illustriert die Spezifikation von Situationen
247. eilige Werkzeug zugeschnitten Insbesondere steuern Assistenten in den jeweiligen Werkzeugen automatisch bestimmte Teilfunktionen an bzw fokussieren als meist modale Dialogfenster die Interaktionsm glichkeiten des Benutzers auf die f r den aktuellen Vorgang relevanten Optionen hnlich wie bei Hilfesystemen f hrt die enge Kopplung eines Assistenten mit seinem Werkzeug dazu dass innerhalb eines gr eren Werkzeugver bunds aus dem sich eine Entwicklungsumgebung typischerweise konstitu iert jeweils nur werkzeuglokale Unterst tzung stattfindet w hrend Pro zesse die mehrere Werkzeuge involvieren normalerweise nicht durch As sistenten unterst tzt werden k nnen Ausnahmen bilden sehr eng integ rierte Entwicklungsumgebungen deren Teilwerkzeuge von einem Herstel ler stammen so dass die Grenzen zwischen den Einzelwerkzeugen und der Gesamtumgebung verschwimmen z B Microsofts Visual Studio oder O racle Designer 2000 Q Kontextbezogenheit Sobald ein Assistent aktiviert wurde f hrt er den Benutzer durch den von ihm unterst tzten Vorgang Die dabei geleistete Prozessunterst tzung ist in dem Sinne kontextsensitiv dass der Assistent in Abh ngigkeit von bereits durchgef hrten Teilschritten d h gem aktu ellem Prozessfortschritt eine Auswahl von m glichen n chsten Schritten vorschl gt den Benutzer nach bestimmten Informationen fragt oder Werkzeugaktionen automatisch anst t 0 Anpassbarkeit Assistenten verk rpern
248. ein k nnen z B mehrere laufende ER Editoren Diese bezeichnen wir dann als Werkzeuginstanzen Abb 20 PRIME TM Das Werkzeug metamo dell Poh 99 lt arbeitet_auf Produkt Aktion lt bietet_Aktion_an 1 OKOTE 1 B Kommando kategorie bietet_KE_a Element incomplete Darstellungs Pulldown Kommando Icon Mit Hilfe des Konzepts Aktion werden die von den Werkzeugen bereitgestellten elementaren Dienste modelliert Die Verkn pfung von Aktionen zu den Werk zeugkategorien die diese Aktionen bereitstellen erfolgt ber die Assoziation bietet Aktion an an Aktionen werden durch Angabe ihrer Eingangsprodukte d h ihrer input Pa Prozessneutrale rameter und ihrer Ausgangsprodukte d h ihrer output Parameter n her be Beschreibung von schrieben Im Gegensatz zum Prozessmetamodell werden Aktionen daher durch eer ene ihre unmittelbare Ein Ausgangsschnittstelle beschrieben ohne sie in Bezug zu spezifischen Prozesskontexten zu setzen Aktionen werden aus Werkzeugsicht also prozessneutral definiert Eine Werkzeugkategorie wird indirekt ber die von ihr angebotenen Aktionen die lesend oder schreibend auf bestimmte Produkte zugreifen mit dem zugrunde liegenden Produktmodell verkn pft Dies ist in Abb 20 durch die abgeleitete Assoziation arbeitet auf angedeutet Im korrespondierenden O Telos Modell lassen sich die einer Werkzeugkategorie zugeordneten Produkte mit Hilfe einer deduktiven Regel h
249. eise als Informationsnetze aufbereitet sein und durch Hilfesysteme siehe Ab Anleitungswerkzeuge schnitt 2 2 2 oder Webbrowser innerhalb eines organisations oder projektweiten Intranets f r die Entwickler zug nglich gemacht werden Eine andere Klasse separater Assistenzwerkzeuge repr sentieren so genannte Agenda oder Taskma nager die typischerweise das Entwickler Frontend in prozesszentrierten Umge bungen und Workflow Managementsystemen darstellen siehe Abschnitt 2 2 4 Separate Assistenzwerkzeuge sind somit zwar in der Arbeitsumgebung des Ent wicklers unmittelbar verf gbar jedoch mit der eigentlichen technischen Umge bung des Entwicklers d h den f r die Aufgabenbearbeitung ben tigten im allge meinen interaktiven Werkzeuge nicht oder nur lose gekoppelt s Abb 2b Der Entwickler muss daher mit einer zus tzlichen Benutzerschnittstelle umgehen d h er nimmt einerseits Empfehlungen Hinweise und Vorschriften zur Bearbeitung der Aufgabe vom Assistenzwerkzeug entgegen w hrend er die eigentliche Auf gabe in den interaktiven Entwicklungswerkzeugen erledigt Als Konsequenz ergibt sich dass eine mit den Prozessvorgaben konforme Durchf hrung von Aufgaben auf der technischen Ebene nicht mehr sichergestellt werden kann Dies ist insbe sondere dann kritisch wenn gem der Prozessdefinition in einer bestimmten Situation gewisse Prozessschritte zwingend vorgeschrieben z B die Dokumenta tion eines Entwurfsobjekts bzw verhindert werde
250. eispieltabellen zur Auswahl angeboten die er als Grundlage f r seinen Ta bellenentwurf verwenden kann und aus denen er wiederum die f r seinen Zweck relevanten Datenfelder selektieren kann Im n chsten Schritt kann der Benutzer an allen oder einigen der bernommenen Felder auf seinen Anwendungssachverhalt bezogene Anpassungen vornehmen z B Umbenennung von Feldern Danach weist der Tabellenassistent den Benutzer an die Tabelle zu benennen und einen Prim rschl ssel auszuweisen oder aber die Generierung eines Prim rschl ssels dem Assistenten zu berlassen Im n chsten Schritt wird der Benutzer angeleitet Beziehungen zu bereits existierenden Tabellen der Datenbank zu spezifizieren Schlie lich erzeugt der Assistent aus den vom Benutzer erfragten Information die neue Tabelle F r jeden der genannten Schritte interagiert der Assistent ber jeweils einen hochspezialisierten Dialog der wiederum gegebenenfalls einen oder mehrere Unterdialoge besitzt mit dem Benutzer Das hinter dem angeleiteten Ablauf ste ckende Prozesswissen manifestiert sich somit in der Dialogabfolge und im Aufbau der einzelnen Dialoge des Assistenten Um die Benutzungskomplexit t gegen ber dem zugrunde liegenden Basiswerkzeug zu reduzieren bieten Assistenten h ufig nicht alle Entwicklungsoptionen sondern liefern als Entwurfsresultat h ufig nur ein Grundger st das vom Benutzer mit den Standardfunktionalit ten des Werk zeugs noch angepasst und erweitert muss Im
251. eister M und Marquardt W The Chemical Engineering Data Model VeDa Part 1 The Data Definition Language VDDL Tech Report Lehrstuhl f r Prozesstechnik RWTH Aachen TR 1998 01 1998 Barghouti N Supporting Cooperation in the MARVEL Process Centered SDE In Proc 5th ACM SIGSOFT Symposium on Software Development Environments SIG SOFT Notes 1992 S 21 31 Basili V R und Rombach H D The TAME Project Towards Improvement Oriented Software Environments IEEE Transactions on Software Engineering 14 6 S 758 773 1988 Bauer J und Schwab T Anforderungen an Hilfesysteme In Einf hrung in die Soft ware Ergonomie de Gruyter Verlag Berlin 1988 S 197 214 Bandinelli S Braga M Fuggetta A und Lavazza L The Architecture of the SPADE 1 Process Centered SEE In Proc 2nd European Workshop on Software Process Technology EWSPT 94 Villard de Lans France 1994 S 15 30 Barrett D Clarke L Tarr P L und Wise A A Framework for Event Based Software Integration ACM Transactions of Software Engineering and Methodology 5 4 S 378 421 Oct 1996 Becker Kornstaedt U Hamann D Kempkens R R sch P Verlage M Webby R und Zettel J Support for the Process Engineer The Spearmint Approach to Software Proc ess Definition and Process Guidance In Proc CAiSE 99 1999 S 119 133 BeDa94 Beer90 BeKa98 BeK196 BeMS99 BeM 99 Ber 99 BeRS99 Bey
252. eit fungieren IRD Level Paare als Koordinati onsstellen innerhalb eines verteilten Informationssystems zur Entwurfszeit dienen sie als die eigentlichen Entwurfsdatenbanken ber die die Ent wurfswerkzeuge einer Entwicklungsumgebung integriert werden 3 3 Integrationsanforderungen in prozessintegrierten Umgebungen 67 Q IRD Definition Level Pairs dem gleichen Zweck wie IRD Level Pairs dienen allerdings in Bezug auf die Evolution der Entwicklungsumgebun gen selbst W hrend die miteinander verzahnten Application Level und IRD Level Pairs eine verteilte Anwendungsumgebung bilden stellen die miteinander verzahnten IRD Level und IRD Definition Level Paare eine verteilte Entwicklungsumgebung dat Auf diese Weise stellt die IRDS Architektur die prinzipiellen Konzepte bereit um sowohl Informationen ber die Nutzung als auch die Entwicklung eines verteilten Informa tionssystems miteinander zu integrieren Datengranularit t Bei dem Repository Ansatz sind wir bisher davon ausgegangen dass Werkzeuge und Prozessmaschine jeweils spezifische Sichten auf ein gemeinsames globales Repository Schema haben Dies erlaubt eine gr tm gliche Integration der Werk zeugdaten und der f r die Leitdom ne relevanten Daten auch auf der feingranula ren Ebene siehe Abb 10a Abb 10 Integration von Werk zeugdaten im Prozess Repository Werkzeug 1 integriert Werkzeug 2 integriert Werkzeug 1 Werkzeug 2 Werkzeug 1 e
253. el setzt die Kontextsensitivit t eines Prozessunterst tzungsansatzes einen gewissen Grad der Integration mit den Werkzeugen der Entwicklungsumgebung voraus Nichts destotrotz charakterisiert jedes Kriterium einen spezifischen Aspekt der nicht bereits vollst ndig von einem oder mehreren anderen Kriterien abgedeckt wird 2 1 1 Unterst tzte Projektebene Die in einem Entwicklungsprojekt ablaufenden T tigkeiten lassen sich grob in administrative Aktivit ten auf der Projektmanagementebene und technische Entwick lungstatigkeiten auf der Arbeitsplatzebene unterscheiden NaWe99 W hrend die eigentliche Durchf hrung der Entwicklung auf der Arbeitsplatzebene stattfindet bernimmt die Projektmanagementebene Planungs Verwaltungs und Kontroll aufgaben siehe Abb 1 Ans tze zur Prozessunterst tzung lassen sich danach differenzieren welche der beiden Ebenen sie vornehmlich adtessieren Im Folgen den skizzieren wir grob die auf den beiden Projektebenen anfallenden Aufgaben bereiche und charakterisieren so die aus Sicht der jeweiligen Projektebene ben tigten Prozessunterst tzungsfunktionen 2 1 1 1 Projektmanagement Ebene Prozessunterst tzung f r das Projektmanagement befasst sich mit der Projektplanung und organisation der Ressourcenverwaltung und koordination sowie der Anlei tung und Kontrolle von Entwicklungsaktivit ten ThTh97 siehe oberen Teil von Abb 1 Abb 1 Die zwei Ebenen der Systementwicklung Pro
254. ell die bei der Sicherung der Datenkonsistenz gleichwohl zu ber cksichtigen sind 3 3 2 2 Bewertung existierender Ans tze Bei der Betrachtung konkreter Datenintegrationsmechanismen lassen sich die Ziele Dateninteroperabilit t und Datenkonsistenz nicht immer voneinander tren nen da eine gew hlte Art des Datenaustausch mit bestimmten Techniken zur Konsistenzsicherung und kontrolle einher geht Wir legen daher im Folgenden zun chst den Schwerpunkt auf Mechanismen zur Dateninteroperabilit t zwischen Werkzeugen und diskutieren dann die St rken und Schw chen in Hinblick auf die Sicherung und Kontrolle von Datenkonsistenz F r den Austausch von Daten zwischen Werkzeugen lassen sich im Wesentli chen drei Methoden unterscheiden ChNo92 Bro 94 BeDa94 vgl Abb 8 direkter Datenaustausch Datei basierter Datenaustausch und Repository basierter Datenaustausch 3 3 Integrationsanforderungen in prozessintegrierten Umgebungen A Shared Memeory Pipes CORBA HTTP a Direkter Datenaustausch format A Konverter AB Daten Daten format format Konverter BoA A B b1 Dateibasierter Datenaustausch mit y paarweisen Konvertern Konverter Konverter 1 C gt N NOC T c Repository basierter b2 Dateibasierter Datenaustausch mit Datenaustausch neutralem Austauschformat Direkter Datenaustausch Beim direkten Datenaustausch werden die Ausgabe Daten eines Werkzeugs direkt an ein anderes geleitet
255. ellierung w rde dadurch zum Werkzeug Skriptine degenerieren und in die N he der Makropro grammierung geraten wie sie etwa innerhalb der Microsoft Office Familie mittels VBA Visual Basic for Applications m glich ist In diesem Fall lie e sich ein Werkzeug zwar nahezu beliebig manipulieren jedoch w rden hier Aspekte der Organisation von Arbeitsabl ufen zunehmend durch eher programmiertechnische Aspekte des Verschaltens von Werkzeugfunktionalit ten berlagert Als Schluss folgerung sollten also die f r die Prozessmodellierung relevanten Aktionen eines Werkzeugs mit den in der Modellierungsdom ne betrachteten kleinsten Arbeits einheiten auf Prozessebene korrespondieren Die Kunst bestand dann darin die Granularit t der Basisdienste auf m glichst hohem semantischem Niveau gerade so fein zu w hlen dass deren interne Ablauflogik nicht mehr prozessrelevant ist d h nicht auf Prozessmodellierungsebene adaptabel sein muss Dass es hierf r kein Patentrezept geben kann ist einsichtig Vielmehr mussten hier Kompromisse eingegangen werden die den Trade Off zwischen maximaler Flexibilit t bei der Ausgestaltung von Werkzeugfunktionalit ten einerseits und Klarheit und Einfach heit der Prozessmodelle andererseits ber cksichtigten Trotz der genannten Einschr nkungen konnte mit der Implementierung des PRIME Rahmenwerkes und seiner Beispielanwendungen die Praktikabilitat des in dieser Arbeit entwickelten Adaptabilit ts und Prozessunters
256. ellschichtklassen stellen Schnittstellen bereit mit denen die Beziehungen unter den Prozessentit ten dynamisch hergestellt werden Im Falle der Prozessklasse werden weiterhin ele mentare Dienste der Prozessausf hrung wie z B das Starten Beenden oder Ter minieren eines Prozesses angeboten Auf der Repr sentationsschicht wird die Prozessklasse der Modellschicht in die einzelnen Prozesssprachen Paradigmen spezialisiert und um Schnittstellendienste erweitert die f r den jeweiligen Formalismus erforderlich sind Die Schnittstelle eines Ereignisprozesses als Spezialisierung der Prozessklasse ist z B um die Me thode receiveEvent erg nzt so dass Ereignisse entgegengenommen werden k nnen Die spezialisierten Prozessklassen der Repr sentationsschicht werden dann weiter auf der Komponentenschicht in die eigentlichen Prozesskomponenten verfei nert welche die anwendungsspezifische Ablauflogik in sich tragen Die Klassen der Komponentenschicht stellen die Prozesstypen wie z B Design oder CodeTest dar deren Instanzen mit den Instanzen anderer OPC Klassen wie z B Agenten oder Produkten in Beziehung stehen Durch die geerbte Schnittstellenfunktiona lit t der Modellschicht k nnen die Komponenten auf der Komponentenschicht kommunizieren wobei die Sprache des Prozessfragments welches das Kompo 140 6 Interoperabilitat von Prozesssprachen nentenverhalten spezifiziert auf der Repr sentationsschicht durch die Schnittstel len verborgen wir
257. elnden Werkzeuge f r die Ableitung von kon zeptuellen Modellen aus multimedial erfassten Anwendungsszenarien Hier ver sprach MFC eine bessere technische Unterst tzung f r Multimedia Inhalte Video Bilder Audio etc als das bislang von uns verwendete GUI Toolkit ILOG Views und andere unter Unix frei verf gbare Multimedia Bibliotheken Die auf Basis von PRIME 1 5 entwickelte PRIME CREWS Umgebung erweitert die Funktionalit t von PRO ART 2 0 um einen multimedialen Whiteboard Editor einen Zielmodell Editor einen Message Sequence Chart Editor und ein Werkzeug zur Unterst t zung von Review Prozessen Einzelheiten zur PRIME CREWS Umgebung sind in HaPW98 Haum00 zu finden PRIME CREWS 8 CREWS Cooperative Requirements Engineering With Scenarios 250 8 Anwendungen PRIME PROMENADE Projektspezifische Filterung von Nachvoll ziehbarkeitsinformatio nen PRIME 2 0 Integration von Fremd werkzeugen Interope rabilit t zwischen Prozesssprachen Erfassung und Visuali sierung von Prozessspu ren Im Rahmen der Dissertation von Ralf D mges wurden Erweiterungen in Richtung einer flexiblen Aufzeichnung von Nachvollziehbarkeitsinformationen mithilfe eines projektspezifisch anpassbaren Filtermechanismus vorgenommen Diese PRIME PROMENADE genannte Framework Erweiterung wurde bei der Entwicklung der verfahrenstechnischen Umgebung PRIME TECHMOD einge setzt und validiert N here Informationen sind in D mg99 D6P098 D PS98 zu
258. em den Vorgaben aus der Leitdom ne einschr nken Da durch lassen sich Abl ufe innerhalb eines vom Prozessmodell vorgege benen Korridors lenken ohne die Flexibilit t des Benutzers voll st ndig einzuschr nken O Unterst tzung bei der Aktivierung von Prozessfragmenten passive Prozessberatung und aktive Prozessanleitung Prozessintegrierte Werkzeuge unterst tzen den Entwickler beim Abgleich der aktuell vorliegenden Prozesssitua tion mit den Prozessdefinition und erm glichen so auf Anfrage des Benutzers oder selbst ndig die Aktivierung von Prozessfragmenten Der aktuelle Werkzeugzustand selektierte Produkte aktivierte Kom mandos definiert dabei den Kontext f r die Anwendbarkeit von Pro zessfragmenten Aus Benutzersicht besteht somit kein Unterschied in der Aktivierung einer elementaren Werkzeugfunktion und eines Pro zessfragments 43 44 2 Prozessorientierte Unterst tzungsfunktionen Abb 6 illustriert die Einordnung prozessintegrierter Werkzeuge in den durch die unterschiedlichen Kriterien aufgespannten Raum m glicher Prozessunterst t zungsfunktionen Abb 6 Prozessunterst tzung Einordnung prozessinteg rierter Werkzeuge pe en Unterst tzungs Integrations Kontext Anpass Unterst tzungs ebene tiefe bezogenheit barkeit modi Projekt extern fix Passive management Rechner statisch konfigu Beratung Ebene basiert rierbar z Lenkung separat Akti vO Anleitung Arbeitsplatz Rechnerbasiert dynam
259. em Werkzeug angezeigten Produktinstanzen in drei verschiedene Gruppen einteilen Q Hervorgehoben die Produktinstanzen die zur Situationsinstanz des aktu ell aktivierten Entscheidungskontexts geh ren werden in der Darstel lungsart hervorgehoben repr sentiert 5 5 Integration der Modelle 125 O Selektierbar Instanzen von Produkten die potenziell zu Situationen der Alternativen des aktuellen Entscheidungskontexts beitragen k nnen wer den in der Darstellungsart selektierbar repr sentiert O Deaktiviert Instanzen von Produkten auf denen keine Situation der Al ternativen des aktuellen Entscheidungskontexts basiert werden in der Dar stellungsart deaktiviert dargestellt Zur Modellierung der unterschiedlichen Darstellungsarten werden drei Spezialisie rungen der Assoziation Darstellung zwischen den Klassen Darstellungselement und Darstellungsart eingef hrt Die Menge der in der Darstellungsart hervorgehoben darzustellenden Produkte ergibt sich aus der Situationsinstanz eines auszuf hrenden Entscheidungskontexts Die Mengen der selektierbaren bzw deaktivierten Produktinstanzen lassen sich deklarativ durch folgende O Telos Anfrageklassen bestimmen GenericQueryClass SelektierbareProduktinstanzen isa Class with parameter ek Entscheidungskontext constraint ce exists p Produkt s Situation k Kontext rek Alternative k and k besteht _aus Situation s and s basiert _auf p and this in p end GenericQueryClas
260. emative yDevice P C_ FB W_ RefinePro Projet Sheet Dg PC_FBW_ContinueFlefineE xtuder z 5 ja m Lea Dyce PC_FEW_CieateGroupDependencies I ec cessDeviceWithDecision l Fe Faw Eo rae x PC_FBW_EndRefinement PC_FBW_ExitRefinementPattemn IF No scope pete Generate ll ltematives lt device gt ffom Device Shest nerateAISepAkematives lt project trem Project PC FEW InlegatePtocess6foup PC_FBW_LoadProject PC_FBW_NewProject PC_FBW_RefineByDestillatioh PC_FBW_RefineByFlash PC_FBW_RefineByFlash ndlfombination PC_FBW_RefineE xtruder PC_FBW_RefineProcessDevloewithDecit PC_FBW_RefineProcessDevlces es PC ea 4 PC_FEW_RefineRescByCSTR_CSTR i PC FBW RefineReacByCSTR_PFR cra PU_FBW_HetineHeacByPr Fy PC FBW RefineSeoByDest y Schritt 1 Schritt 2 REProluctList PC_FBW_InspectRelatedObjects REPropuctList Schritt 3 Schritt 4 Set a Guard Loki Set guard for transition PC_FBW_InspectRelatedOpft c r Eau PC_FBW_CreateGroupDependencies lt dgne gt Place Operation Value lt ddne gt REProductList emy v RISS ME OK Cancel Welcome to the PRIME plan context editor x cea Unrestricted Plan Cantext Executable Context Im n chsten Schritt sieht der Plankontext eine bedingte Verzweigung vor die vom Ergebnis des Kontextes EC_FBW GetRefinementsOfGroup abh ngt und durch W chterbedingungen in den adjazenten Transitionen realisiert wird Die Liste
261. emei nen durch unterschiedliche Werkzeuge abgedeckt werden und induziert so logi sche und physische Abh ngigkeiten zwischen Werkzeugdaten Dazu m ssen Werkzeuge zun chst einmal prinzipiell in die Lage versetzt werden untereinander d h innerhalb der Durchf hrungsdom ne und mit der Prozessmaschine d h mit der Leitdom ne Entwurfsergebnisse in Form von Werkzeugdaten auszutauschen Weiterhin muss bei der wechselseitigen Bearbeitung berlappender Datenbest nde daf r gesorgt werden dass die werkzeug bergreifende Integrit t der Daten kon trolliert und gegebenenfalls gesichert wird Mit der Datenintegration innerhalb einer prozessintegrierten Entwurfsumgebung verfolgt man also zwei prim re Ziele Dateninteroperabilitat und Datenkonsistenz 3 3 Integrationsanforderungen in prozessintegrierten Umgebungen 59 Dateninteroperabilitat Unter Dateninteroperabilitat verstehen wir die F higkeit effizient und mit m g lichst geringem Aufwand die Entwurfsergebnisse eines Werkzeugs anderen Werk zeugen sowie der Prozessmaschine in sinnvoller Weise zug nglich zu machen Die dabei auftretenden Br che und entsprechend erforderlichen Harmonisie Stufen der eh rungsmafnahmen kann man gem einem auf Brown und McDermid zur ckgehen Dateninteroperabilat den Klassifikationsschema BrMc91 BrEM92 Brow93 auf f nf unterschiedlichen Stufen charakterisieren O Tr gerstufe carrier level Auf dieser untersten Ebene wird sichergestellt dass ein
262. ement charakterisiert Die abstrakte Oberklasse VT Proces sElement zerf llt in zwei wesentliche Subklassen VT ProcessDevices die die Hauptfunktionalit t eines Verfahrens repr sentieren und Streams die f r den Stoff Energie oder Materialtransport zwischen VI ProcessDevices sorgen Instanzen der Subklassen von VI ProcessDevice werden im Flie bildgraphen als Knoten und Stream Instanzen als Verbindungslinien zwischen den Knoten darge stellt Im Laufe des Modellierungsprozesses werden der Menge von VT ProcessEle ment Instanzen zwei wesentliche Strukturen aufgepr gt die vom Flie bildwerk zeug zu verwalten sind die Verkn pfungsstruktur und die Verfeinerungsstruktur Die Verkn pfungsstruktur gibt an wie VI ProcessDevices ber Streams mit Verkn pfungsstruktur einander verkn pft sind Jeder Stream besitzt zwei Konnektoren Connector von denen einer die Quelle source und der andere die Senke sink des Streams defi niert Dadurch ist die Fluss Richtung eines Streams bestimmt Die Verkn p fungsstellen eines VI ProcessDevice werden als Port bezeichnet Ein VT Process 256 8 Anwendungen Device hat mindestens einen Port Jeder Port ist dadurch naher charakterisiert ob er als Eingangsport oder Ausgangsport Attribut direction fungiert und ob er zwingend erforderlich oder optional ist Die Anzahl der Ports sowie deren Eigen schaften hangen von der spezifischen VI ProcessDevice Subklasse ab Die Ver
263. ement durch ein entsprechendes Objekt repr sentiert wird Die Methoden dieser Objekte realisieren die operatio nale Semantik der jeweiligen Sprachelemente Mithilfe dieser Methoden interpre tieren sich die Sprachelemente sozusagen selbst Die administrative Interpreter Schicht ist f r die Ausf hrungskoordination der Sprachelemente zust ndig Dies umfasst das Laden Instanziieren und Entladen der Objekte der Sprachelemente Schicht die Vermittlung der Interoperation zwischen unterschiedlichen Sprachelementen bei geschachtelten Prozessfragmen ten und die Anbindung an die Funktionalit ten der Schnittstellenschicht Kom munikation Datenbank Benutzeroberfl che In der nachfolgenden Darstellung konzentrieren wir uns auf die Struktur der Sprachelemente Schicht und der administrativen Interpreter Schicht Abschnitt 7 5 2 beschreibt die Klassen der beiden Schichten w hrend Abschnitt 7 5 3 auf das Kontrollmodell eingeht das dem Zusammenspiel zwischen Sprachelemente Schicht und administrativer Interpreter Schicht zugrunde liegt 7 5 2 Beschreibung der wiederverwendbaren Klassen Im Folgenden erl utern wir die wiederverwendbaren Elemente des Interpreter Rahmenwerkes In Abschnitt 7 5 2 1 werden zun chst die sprachlichen Klassen der Sprachelemente Schicht vorgestellt die die Struktur der Prozessmodelle der Mo dellierungsdom ne abbilden In Abschnitt 7 5 2 2 werden dann die technischen Klas sen der administrativen Interpreterschicht beschr
264. en Hier wird also in erster Linie die Integrationsfragestellung wie d h mit welchen Mechanismen in einer Entwurfsum gebung die einzelnen Komponenten miteinander verbunden werden untersucht Basismechanismen Die Ebene der Benutzerdienste korrespondiert mit einer abstrakten Beschreibung der Funktionalit t der Umgebung Integration auf dieser Ebene besch ftigt sich mit der Frage welche Dienste aus Sicht des Benutzers von der Umgebung ange boten werden und in welcher Beziehung diese zueinander stehen Auf dieser Ebene wird die Semantik der unterschiedlichen Integrationsaspekte insbesondere Daten Kontroll und Pr sentationsintegration genauer gekl rt Benutzerdienste Die Prozessebene befasst sich mit den Zielen und Einschrankungen die von den zu unterst tzenden Entwurfsprozessen herr hren und somit einen Kontext f r die Verwendung und Integration der Benutzerdienste aufspannen Prozesse Zwischen den Ebenen existieren im Wesentlichen zwei Wechselwirkungen Die Beziehung zwischen Ebene der Benutzerdienste und der Basismechanismen wird als Realisierungsbeziehung verstanden Hierbei gibt es selbstverstandlich keine ein deutige Zuordnung zwischen Elementen der beiden Ebenen Benutzerdienste werden unter Verwendung unterschiedlicher Basisdienste implementiert w hrend umgekehrt ein Basisdienst bei der Realisierung mehrerer Benutzerdienste verwen det kann Realisierung Adaption Die Wechselwirkung zwischen der Prozess und der
265. en um dort eine vom aufrufenden Werkzeug festgelegte Operation zu veranlassen Kommandos sind in der Regel synchrone Nachrichten d h der Versender der Nachricht wartet auf eine Ant wort und entsprechen im Wesentlichen den in den vorgenannten Ans tzen ange sprochenen entfernten Prozedur bzw Methodenaufrufen mit dem Unterschied dass hier auf nat rliche Weise auch 1 n Beziehungen zwischen aufrufendem und empfangenden Werkzeugen realisiert werden k nnen 3 3 Integrationsanforderungen in prozessintegrierten Umgebungen 75 Die eigentliche Besonderheit des Message Broadcasting Ansatzes stellt jedoch das Konzept der Norifikationen dar mit dessen Hilfe das Prinzip des impliziten Operationsaufrufs SaNo92 Gall90 realisiert werden kann Werkzeuge melden Impliziter Operationsauf asynchron bestimmte Ereignisse oder nderungen ihres Zustands an eine f r sie Yf durch Notifikation anonyme Menge von Interessenten welche dann entsprechend auf diese Meldungen reagieren k nnen Die Ereignisse werden als Nachrichten von einem ereignismel denden Werkzeug an den BMS geschickt und von dort an interessierte Werkzeuge weitergeleitet Um ber das Eintreffen eines bestimmten Ereignisses informiert zu werden muss sich ein Werkzeug vorher beim BMS registriert und sein Interesse durch Angabe entsprechender Nachrichtenmuster bekundet haben Im Gegensatz zu den vorher betrachteten Ans tzen werden Werkzeugdienste also nicht direkt aufgerufen sondern implizit
266. en Datenmodell VeDa Diplomarbeit RWTH Aachen 1997 Kronl f K Hrsg Method Integration Concepts and Case Studies John Wiley amp Sons 1992 Krishnamurthy B und Rosenblum D S Yeast A General Purpose Event Action System IEEE Transactions on Software Engineering 21 10 S 845 857 Oct 1995 Kruchten Ph The Rational Unified Process An Introduction Addison Wesley 1998 Kumar K und Welke R J Methodology Engineering A Proposal for Situation specific Methodology Engineering In Cotterman W W und Senn J A Hrsg Challenges and Strategies for Research in Systems Development John Wiley amp Sons Chichester UK 1992 S 257 269 Lang K und Bodendorf F Gestaltung von Gesch ftsprozessen auf der Basis von Proze bansteinbibliotheken In Business Process Re Engineering dpunkt Verlag Nr 198 Theorie und Praxis der Wirtschaftsinformatik Handbuch der maschinellen Daten verarbeitung 1997 S 83 93 Lamprecht St Programmieren f r das WWW mit JavaScript VBScript XML und SMIL Verlag Carl Hanser 1999 Laurel B Interface Agents Metaphors with Character In Laurel B Hrsg The Art of Human Computer Interface Design Addison Wesley Band 1 1990 S 355 365 Lausen G und Vossen G Models and Langnages of Object Oriented Databases Addison Wesley International Computer Science Series 1997 Lefering M Integrationswerkzeuge in einer Softwareentwicklungsumgebung Dissertation RW
267. en bereits in einem Kooperationsprojekt mit einer Forschergruppe an der Universit t Jyv skyl erarbeitet Hier wurden M glichkeiten und Grenzen einer Integ ration zwischen dem PRIME Rahmenwerk und der CASE Shell MetaE dit diskutiert Lyy 98 O Verzahnung zwischen Prozessdefinition und ausf hrung In den bisherigen PRI ME Anwendungen wurde die verschr nkte Modellierung und Ausf hrung von Prozessfragmenten noch nicht systematisch untersucht Hierf r liegen jedoch bereits alle technischen Voraussetzungen vor da die Admi nistrations und Metamodellierungswerkzeuge ebenso wie alle anderen PRIME Werkzeuge prozessintegriert sind Es w re also denkbar den An wender bei der ad hoc Definition neuer oder der nderung existierender Prozessfragmente durch geeignete Meta Prozessfragmente zu unterst tzen O Absgeschw chte Formen der Prozessintegration Die Prozessintegration im a poste riori Kontext ist erst f r den Fall voll prozessintegrierbarer Werkzeuge vollst ndig verstanden Bei nur eingeschr nkt integrierbaren Werkzeugen sind insbesondere Aspekte der Synchronisation zwischen Prozessanleitung und ausf hrung und der Sicherung der Nachvollziehbarkeit noch weitge hend ungekl rt Diesen Fragestellungen wird zur Zeit in der zweiten F r derperiode des SFB IMPROVE nachgegangen In den in dieser Arbeit betrachteten Anwendungsf llen liegen hinsichtlich der Akzeptanz und Qualit t der Benutzerf hrung durch prozessintegrierte Werkzeu
268. en einige Ans tze gung von Ereignissen in Techniken zur automatischen Verfolgung von Ereignissen die in der Durchf h a eoruhrungsdo rungsdom ne beim Umgang mit den Werkzeugen anfallen Diese Ereignisse wer den dann interpretiert und flie en in die Prozessmodellinterpretation ein In der SPADE Umgebung BBFL94 werden wie bereits oben beschrieben are Nachrichten die von den Werkzeugen der DEC Fuse Umgebung an den Message SLANG Server abgesetzt werden ber das SPADE Communication Interface SCI abge fangen als Token reifiziert und in ser interface places der aktuell interpretierten SLANG Netze abgebildet Auf einer systemtechnisch noch tieferen Ebene als bei SPADE setzt das Er eignis Monitoring in der prozesszentrierten Umgebung Provence BaKr93 BaKr95 an Hier werden auf Betriebssystemebene Dienste des n Dimensional File System n DFS FoKR94 genutzt um Datei und Verzeichniszugriffe und die Ausf hrung von Werkzeugen zu berwachen Diese primitiven Ereignisse werden mit Hilfe von Yeast KrRo95 einem System zur Spezifikation und Auswertung von Ereig Event Montong in nis Aktions Regeln zu komplexeren Ereignissen aggregiert und der Leitdom ne Provence zur Verf gung gestellt Problematisch an diesem Ansatz ist dass Ereignisse vom Betriebssystem Niveau auf die semantische sehr viel h here Ebene der Prozess modellierung abgebildet werden m ssen So ist zum Beispiel aus den verf gbaren Publikationen nicht ersichtlich w
269. en kann siche Diskussion in Abschnitt 6 3 2 Allgemein 6 4 Schnittstellenbindung 161 h ngt die Darstellung davon ab ob in der Prozesssprache das Konzept eines W chters vorhanden ist mit dem Bedingungen ausgedr ckt werden k nnen Ist dies der Fall dann kann bei der Verwendung einer EK Komponente an der EK Ergebnisschnittstelle ein zus tzlicher Datenbeh lter die gew hlte Kontextalterna tive repr sentieren Der Datenbeh lter nimmt zur Laufzeit die Instanz eines Kon trolldatentyps auf dessen Attribut die gew hlte Alternative repr sentiert Mit Hilfe des W chters kann das Attribut berpr ft werden und der Kontrollfluss je nach gew hlter Alternative verzweigen Verf gt die Prozesssprache ber kein W chterkonzept wie es z B in regul ren Petrinetzen und auch in Funsoft Netzen DeGr93 der Fall ist dann muss die gew hlte Alternative auf andere Weise repr sentiert werden Dies kann z B da durch erfolgen dass f r jede Alternative eine eigene Stelle an der Ergebnisschnitt stelle existiert die entsprechend der Kontextwahl zur Laufzeit mit einer Marke gef llt wird Da hier je nach Prozesssprache mehrere M glichkeiten denkbar sind wurden diese Abbildungsregeln nicht auf der M2 Ebene festgelegt sondern wer den auf der sprachspezifischen Ebene durch erweiterte Integrit tsbedingungen der instanziierten Aktivit tsbindung definiert Die Repr sentation der gew hlten Alternative einer EK Komponente erfolgt Repr sentation d
270. en muss Gem der Struktur des Pro zessmetamodells entsprechen die einzelnen Alternativen des Entscheidungskon texts EK wiederum Kontexten Die alternativen Kontexte k nnen beliebigen Typs Ausf hrungs Entscheidungs oder Plankontext sein und selbst wieder einer anderen Werkzeugkategorie oder der Prozessmaschine im Fall von Plankontex ten zugeordnet sein Bei der Operationalisierung eines Entscheidungskontexts kommt es also nur darauf an dass eine Werkzeugkategorie alle Alternativen in der Benutzeroberfl che zur Auswahl anbieten kann Die Aktivierung eines alternativen Kontexts und seine Ausf hrung werden also unabh ngig voneinander behandelt Dadurch kann ein Werkzeug in die Lage versetzt werden dem Benutzer die Funk tionalit ten anderer Werkzeuge oder das Ansto en von Prozessfragmenten anzu bieten Die Informationen wie die Alternativen eines Entscheidungskontexts darzu stellen sind werden aus Gr nden der Anpassbarkeit nicht in der Implementierung der Werkzeuge hartkodiert sondern im Umgebungsmodell explizit repr sentiert so dass ein Werkzeug zur Laufzeit diese Definitionen interpretieren kann Konkret ben tigt das Werkzeug Informationen dar ber wie die aktuell geladenen Pro duktteile darzustellen sind und wie die Intentionen der alternativen Kontexte auf Kommandoelemente des Werkzeugs abgebildet werden Darstellung der Produkte Produktseitig lassen sich bei der Ausf hrung eines Entscheidungskontexts die in ein
271. en stammen k nnen East bietet somit eine prozesssensitive Anpassung der Benutzeroberfl che der Werkzeugumgebung Allerdings beschrei ben Tasks cher gr bere Arbeitseinheiten und sind nicht zur feingranularen Pro zessmodellierung gedacht Daher ndert sich der verf gbare Vorrat an zugreifba ren Daten und ausf hrbaren Operationen auch nicht mehr nachdem sich der Benutzer nach Auswahl einer Aufgabe in die East Umgebung eingeloggt hat 3 3 6 3 Fazit Beim prozesssensitiven Interaktionsparadigma h ngt der dem Benutzer aktuell zur Verf gung stehende Funktionsvorrat anders als beim objektorientierten Paradigma nicht nur vom ausgew hlten Dokumentkontext sondern auch von der Prozessaus f hrung ab Dadurch wird der intendierte Prozess f r den Benutzer direkt in seinen Werkzeugen sichtbar Eine berfrachtung mit irrelevanter Funktionalit t wird vermieden und die Gefahr unbewusster Prozessabweichungen wird redu ziert Die uns bekannten prozesszentrierten Umgebungen und Workflow Manage mentsystem bieten keine Unterst tzung f r die systematische Etablierung prozess sensitiver Benutzeroberfl chen bei den eingebundenen Werkzeugen und Applika tionen Lediglich in der East Umgebung existiert das Konzept aufgabenspezifisch angepasster Werkzeugumgebungen allerdings bezogen auf jeweils relativ grobgra nulare Arbeitseinheiten Die Idee prozesssensitiver Benutzeroberfl chen wird auch von Assistenten und Interface Agenten mithilfe einer stark
272. en und multimedialen Szenarien Haum00 sowie die Habi litationsschrift von K Pohl Pohl99 verwiesen Dar ber hinaus beschr nken wir uns in dieser Arbeit bewusst auf die Unterst tzung individueller Arbeitsprozesse eines einzelnen Entwicklers Die S Aalierbarkeit eines Prozessunterst tzungsansatzes in Richtung einer Kooperationsunterst tzung f r Gruppenprozesse mit m glicher weise mehreren hundert involvierten Entwicklern ist daher ebenfalls nicht Ge genstand unseres Klassifikationsmodells Das gleiche gilt f r die damit verwandte unter dem Stichwort Awareness behandelte Fragestellung wie man im laufenden Entwurfsprozess einzelne Mitarbeiter gezielt auf f r sie relevante Ereignisse au Berhalb ihres Arbeitsbereichs aufmerksam machen kann DoBe92 MaFS97 Im Gegensatz zu anderen Klassifikationsmodellen z B dem Werkzeugintegra tionsmodell von Wasserman Wass90 oder dem Requirements Engineering Mo dell von Pohl Pohl94 sprechen wir bei den einzelnen Kriterien unseres Klassifi kationsmodells nicht von Dimensionen da die Kriterien teilweise nicht v llig orthogonal zueinander sind Das bedeutet dass die Klassifikation eines Unterst t 2 1 Ein Klassifikationsmodell fur Prozessunterstutzungsfunktionen 11 zungsansatzes hinsichtlich eines Kriteriums unter Umst nden seine Einordnung innerhalb eines anderen Kriteriums beeinflusst und dass nicht jede Kombination von Einordnungen unter die jeweiligen Kriterien sinnvoll ist Zum Beispi
273. enannte bubble and arc Notationen sehr gut be schreiben w hrend hierarchisch strukturierte Techniken z B geschachtelte Pa 14 GTSL GOODSTEP Tool Specification Language 94 3 Integrationsansatze ketdiagramme und Diagramme in denen das Layout semantische Information tr gt z B Message Sequence Charts nur schlecht unterst tzt werden Zusammenfassend beruhen existierende Generierungstechniken stark auf einer strikten Formalisierung der einer Methodik zugrunde liegenden Produktstruktur Das generelle Problem generativer Ans tze besteht also darin dass Generatoren erst dann erfolgreich gebaut werden k nnen wenn der adressierte Problembereich sehr gut verstanden ist Dar ber hinaus sind Produkte unterschiedlicher Generato ren h ufig schwer zu integrieren da sie stark von den jeweils zugrunde liegenden Automatismen und Grundger sten gepr gt sind Grif98 Beispielsweise macht der GTSL Ansatz weitreichende Annahmen ber die zugrunde liegenden Dateninteg rationstechnik n mlich die Integration ber projektweite abstrakte Syntaxgraphen und beschr nkt sich auf jeweils syntaxgerichtete und textuelle Werkzeuge 3 3 4 3 Fazit Um die Unterst tzungsleistung der in einer Umgebung vorhandenen Werkzeuge angemessen bei der Modellierung von Prozessfragmenten ber cksichtigen zu k nnen muss eine konzeptuelle Repr sentation der Werkzeuge vorliegen Als Minimalanforderungen sollten Werkzeuge durch Angabe der Signaturen ihrer von
274. end 20 Fur eine Diskussion der so genannten Ko Kontravarianz Problematik siehe z B KeM093 152 6 Interoperabilitat von Prozesssprachen Neben dem Anschluss der Kontextalternativen an den Datenfluss ist es weiterhin erforderlich dass der nachfolgende Kontrollfluss in Abhangigkeit von der ge wahlten Kontextalternative verzweigen kann Da die Kontextalternativen in der verwendenden PK Komponente nicht explizit dargestellt werden muss die Aus wahl ebenfalls indirekt an der Ergebnisschnittstelle der CC Komponente verf g bar sein 6 3 3 Zusammenfassung In diesem Abschnitt haben wir auf Basis des NATURE Prozessmodells ein Me tamodell entwickelt das aus komponentenorientierter Sicht die Schnittstellen von Prozesskomponenten beschreibt Zusammenfassend besteht eine Kontextkompo nente aus einer Situations und einer Verhaltenkomponente Die Situationskom ponente spezifiziert ber einen Situationsausdruck eine Vorbedingung und ist ber eine explizite Kopplung ihrer Ausgangsschnittstelle mit der Verhaltenskompo nente verkn pft Sowohl die Situations als auch die Verhaltenskomponente sind aus Verwendungssicht transparent da beide der internen Struktur einer Kontext komponente zuzuordnen sind Das Dienstangebot der Kontextkomponente ist ber die u ere Komponentenschnittstelle verf gbar Die drei Kontextarten wer den indirekt ber die Verhaltenskomponente abgebildet die je nach Kontextart durch eine Aktion einen Ablauf oder d
275. ens zu einer Gruppe die selbst 8 2 PRIME IMPROVE wieder eine Verfeinerung einer anderen darstellt Die Klasse VT ProcessGroup ist eine Subklasse von VT ProcessDevice Daher hat eine komplexe Gruppe selbst wieder eine Menge von Ports die an Konnektoren von Str men gebunden wer den k nnen Erweiterbares Typsystem Als wichtige Voraussetzung f r ein erweiterbares Typsystem wurden im Daten modell des Flie bildeditors nur die obersten Klassen des Bausteintypsystems explizit festgelegt Auf der Ebene der Grundflie bilder funktionale Sicht sind dies die Klassen VT Process VT ProcessStep und UnitOperation Auf Flie bild ebene wurde lediglich die Klasse VT ProcessEquipment als abstrakte Oberklasse f r konkrete Apparate und Maschinentypen definiert Eine explizite Abbildung konkreter Bausteintypen wie z B Reaktion Trennung Destillationskolonne etc h tte zu einem sehr un bersichtlichen Schema gef hrt Au erdem h tte die dyna mische Erweiterung um neue Bausteintypen jeweils eine Schema nderung nach sich gezogen Konkrete Bausteintypen werden stattdessen implizit mithilfe der Klasse VT ProcessDeviceTypeInfo definiert deren Instanzen die aktuell verf gbaren Bau steintypen beschreiben Die Typbeschreibungen sind dem Flie bildwerkzeug zur Laufzeit zug nglich durch Instanziierung k nnen auf einfache Weise neue Bau steintypen definiert werden Dazu m ssen eine Reihe von Typbeschreibungs merkmalen angegeben
276. entionID alle anderen Die nderung des Aktivierungsstatus wird von der IntentionTable an die eigent lichen werkzeugspezifischen Kommandoelement Objekte gem dem Observer Entwurfsmuster propagiert Auf hnliche Weise erfolgt die Anpassung der Produktregion eines Werkzeugs Hier fungiert die ObjectTable als Schnittstelle zwischen dem ContextExecutor und den werkzeugspezifischen Benutzeroberfl chenobjekten des Teilsystems T GUI Die ObjectTable Eintr ge Objekte der Klasse CmapObjectDesc weisen im Vergleich zur IntentionTable eine etwas kompliziertere Struktur auf ID der ID des Produkt Zeiger auf Zeiger auf Darstellungsart Selektions Tab 13 f Produkt typen der Pr sentations Produkt hervorgehoben status Struktur der ObjectTable instanz Produktinstanz objekt in T_GUI modellobjekt selektierbar nicht selektiert in T_Model selektierbar nicht selektiert Die ID einer Produktmodellinstanz wird hier mit ihrem Produkttypen sowie mit den korrespondierenden Laufzeit Objekten aus den Teilsystemen T Model ob jektorientierte Zugriffsschicht und T_GUI Benutzeroberfl che assoziiert Zudem ist f r jede Produktinstanz die aktuelle Darstellungsart sowie ihr Selektionsstatus vermerkt Bei der Ausf hrung eines Entscheidungskontexts passt der ContextExe cutor die Produktregion des Werkzeugs wie folgt an siehe auch entsprechende Festlegungen im Umgebung
277. equest Dieser Zustands bergang wird durch den Empfang einer LockRequest Nachricht von der Prozessmaschine ausgel st Dieser Fall tritt dann ein wenn die Prozessmaschine zuvor dutch eine GuidanceRequest Nach richt eines anderen Werkzeugs aktiviert worden ist Ein Werkzeug das eine LockRequest Nachricht erhalt quittiert diese Aufforderung durch eine LockOkResponse Nachricht an die Leitdom ne und geht in den Wai ting for Context Request Zustand Dabei deaktiviert es alle M glichkei ten zur Benutzerinteraktion an der Benutzeroberfl che Im Waiting for Context Request Zustand wartet ein Werkzeug auf ContextRe quest c Nachrichten durch die Prozessmaschine Je nach dem ob es sich beim angeforderten Kontext c um einen Ausf hrungs oder Entscheidungskontext handelt geht das Werkzeug in den Zustand Requested EC Active oder Re quested CC Active ber Die Resultate der Aktionsausf hrung bzw der Benut zerauswahl werden durch eine ECResponse bzw CCResponse Nachricht an die Prozessmaschine zur ckgemeldet Transition 13 bzw 12 W hrend sich ein Werkzeug in einem der Zust nde Waiting for Context Request Requested EC Active oder Requested CC Active befindet diese Zust nde sind im Super Zustand Guided by PC zusammengefasst kann der Benutzer einen Abbruch des gerade aktiven Plankontexts anfordern Dabei setzt das Werkzeug eine AbortRequest Nachricht an die Prozessmaschine ab und geht in den Zustan
278. er den die Produkte der aktuellen Situationsinstanz in der Benutzeroberfl che her vorgehoben ber die API A6 werden vom Benutzer ausgel ste Selektionsereig 7 4 Integration existierender Werkzeuge 231 nisse an den UlAdapter zur ck gemeldet und von dort an die Object Table IntentionTable weitergereicht woraufhin eine Kontextauswertung ange sto en wird Wie beim ActionAdapter besteht die Hauptaufgabe des UIAdapters somit in der Kapselung der werkzeugspezifischen APIs und Aufrufmechanismen 7 4 3 Validierung Erste Anwendungserfahrungen hinsichtlich des beschriebenen a posteriori Inte grationskonzepts und der generischen Wrapper Architektur konnten wir im Rah men des Sonderforschungsbereichs IMPROVE sammeln Ziel dieses Projekt ist die umfassende Unterst tzung bergreifender Entwicklungsprozesse in der Ver fahrenstechnik Das f r diese Arbeit relevante SFB Teilprojekt Erfahrungsba sierte Prozessunterst tzung kooperativer Entwicklungsprozesse besch ftigt sich mit der feingranularen Entwickleranleitung in einer verfahrenstechnischen Model lierungsumgebung die aus einer Vielzahl kommerzieller Entwurfs Simulations und Dokumentationswerkzeugen besteht WeBa99 Wir beschreiben in Kapitel 8 noch ein detailliertes Anwendungsbeispiel aus dem IMPROVE Umfeld und be schr nken uns daher hier auf die in diesem Projekt mit insgesamt drei Werkzeugen durchgef hrten Integrationsexperimente Q Aspen Plus Aspen Plus is
279. er Ans tze Um unseren Ansatz der Prozessunterst tzung durch prozessintegrierte Werk zeuge besser in das Gesamtspektrum m glicher prozessorientierter Assistenzfunk tionen einordnen und bewerten zu k nnen entwickeln wir in Abschnitt 2 1 zu n chst ein allgemeines Klassifikationsschema Als wesentliche Charakteristika f r prozessorientierte Unterst tzungsfunktionen betrachten wir die unterst tzte Pro jektebene Abschnitt 2 1 1 die Integrationstiefe der Prozessunterst tzung mit den brigen Komponenten der Entwurfsumgebung Abschnitt 2 1 2 die Kontextbe zogenheit Abschnitt 2 1 3 und Anpassbarkeit Abschnitt 2 1 4 der Prozessunter st tzung sowie den Durchsetzungsgrad in unterschiedlichen Unterst tzungsmodi Abschnitt 2 1 5 Die konkreten Ans tze die am Entwicklungsprozess beteiligten Entwickler mit Informationen ber problembezogene Vorgehensweisen zu versorgen und unterst tzend oder lenkend in den Entwurfsprozess einzugreifen decken ein sehr breites Spektrum ab und werden in Abschnitt 2 2 eingehend behandelt Sie reichen von klassischen Methoden und Projekthandb chern Abschnitt 2 2 1 ber online verf gbare Hilfesysteme Abschnitt 2 2 2 Assistenten oder Interface Agenten Abschnitt 2 2 3 bis hin zu so genannten prozesszentrierten Entwurfsumgebun gen Abschnitt 2 2 4 die auf Basis explizit definierter Prozessmodelle und unter Bereitstellung zus tzlicher Anleitungswerkzeuge den Entwurfsprozess unterst t zen Das
280. er EK in SLANG durch eine zus tzliche Stelle im Nachbereich der Transition Die Stelle Auswahl nimmt zur Laufzeit eine Marke auf deren Wert die gew hlte Alternative darstellt und von einem speziellen Typ Kontrolldaten ist Mit Hilfe eines W chters kann dann eine bedingte Verzweigung ber die Alternativen gebildet werden der den Wert der Marke testet Diese Abbildungsregel f r EK Komponenten wird durch die zus tzliche Integrit tsbedingung ekErgebnis der Aktivit tsbindung sicherge stellt MetaClass Slang AB in Aktivit tsbindung with constraint ekErgebnis forall sab SLANG AB kk Kontextkomponente ek EK_Verhaltenskomponente t Transition b Bereich sab ProzesssprachenKonzept t and t Nachbereich b and svb sprachneutraleDarstellung kk and kk hat_Verhaltenskomponente vk gt exists s Stelle b hatStelle s and s hatTyp Kontrolldaten end Weiterhin werden die Ergebnisschnittstellen einer EK Komponente auf einen Nachbereich einer die EK Komponente repr sentierenden Transition abgebildet Wie bereits in Abschnitt 6 3 2 erl utert unterst tzen EK Komponenten alle Er gebnisschnittstellen ihrer Kontextalternativen Bei der Abbildung der Kompo nentenschnittstelle auf die Sprache SLANG ist zu ber cksichtigen dass SLANG Transitionen lediglich ene Ergebnisschnittstelle haben die durch die Stellen im Nachbereich definiert ist Um die Verwendung von EK Komponenten zu erm g
281. er Kontextkomponente bei det Plankontextdefinition genauer betrachten rechter Teil von Abb 74 Nach der Auswahl der Komponente aus einer sprachneutralen Komponentensammlung wird vom Modellierungswerkzeug eine Stellvertreterschnittstelle erzeugt die die Komponente mit den Konzepten der Verwendungssprache SLANG darstellt Schritt 1 Daraufhin m ssen die Situationsteile an den Datenfluss im Plankontext angeschlossen werden Dazu verbindet der Methodeningenieur die Situationsteile in den Rollen REProduct und REProductList mit existierenden Stellen im SLANG Plankontext Schritt 2 und 3 Dabei muss der Typ der verbundenen Stelle mit dem Typ des Situationsteils bereinstimmen Die abgebildete Stellvertreterkomponente deren Ein und Aus gangsschnittstelle sowie die Situationsteile sind ber Sprachbindungen an die sprachneutrale Schnittstellenbeschreibung gebunden Im abschlie enden Schritt 4 gibt der Methodeningenieur eine zus tzliche Situationsbedingung in Form eines Transitionsw chters an Plankontext InspectRelatedObjects Der Plankontext PC_FBW_InspectRelatedObjects selbst wurde nicht als SLANG Netz sondern als UML Statechart modelliert da seine Struktur nicht von komple xen mehrstufigen Datenabh ngigkeiten sondern von einfachen Steuerbedingun gen gepr gt ist 8 3 Beispielsitzung 263 Fi Plan Context Editor PC_FBW_InspectRelatedObjects Dixi Document Edit Tools Preferences Help Abb 75 UML Statech
282. er Vererbungshierarchie lassen sich die Nach richtenschnittstellen und Interessenprofile zwischen Werkzeugklassen ver erben Q In ToolTalk existiert ein Session Konzept wobei jeweils ein ToolTalk Ser ver mit mehreren Werkzeugen einer Session zugeordnet ist Pro Benutzer k nnen eine oder mehrere Sessions aktiv sein Je nach Nachrichtenspezifi kation erfolgt die Nachrichtenverteilung lokal oder Session bergreifend siehe unten wodurch auch die Kollaboration mehrerer Benutzer unter st tzt werden kann Q Das Nachrichtenformat ist in ToolTalk wesentlich reichhaltiger als in FIELD oder SoftBench Die Attribute aus denen sich eine Nachricht zu sammensetzt umfassen O Address Adressat einer Nachricht kann entweder eine Prozedur ein Betriebssystem Prozess ein Objekt oder ein Objekttyp sein O Class es werden zwei Klassen von Nachrichten unterschieden Anfor derungen request und Notifikationen notice O Operation ber dieses Attribut wird die aufzurufende Operation bei Anforderungen oder das aufgetretene Ereignis bei Notifikationen spezifiziert 3 3 Integrationsanforderungen in prozessintegrierten Umgebungen 77 O Arguments hiermit wird eine Liste von Parametern zu einer Anforde rungs oder Notifikationsnachricht spezifiziert O Scope Mit Hilfe dieses Attributs wird ein G ltigkeitsbereich f r die Ver teilung einer Nachricht definiert M gliche Werte sind session alle Werkzeug innerhalb der lokalen Sitzung j
283. erRefinement Hierarchie EC_FBW_GetParentGroup entsprechend der Ausf hrung geschachtelter 3x EC_PXY_StartIntegrator en PC_ASP_SpecifySimulationModel kontexte CC PO PC_ASP_SpecifyComponents Annotation von es Kontextausf hrungen PE PC_ASP_OptimizeProcess mit Entscheidungs und ZED FBW _SaveT empSnapshot cc 9C_ASP_SelectSimulationRun Hypertextdokumenten EC D EC_ASP_RunSimulation cc 0C_ASP_VaryProcessModel cc 3C_ASP_SpecityComponents EC JEC_ASP_SpecifyMonomer EC ESEC_ASP_SpecifyMonomer E cc ASP_SpecifyProcessModel EC_ASP_SpecifyMonomer 1 Welcome to the PRIME process tracer Prozessspuren Visualisierer Der Progessspuren Visualisierer dient der hierarchischen Darstellung von Prozessspu ren siehe Abb 37 Der Prozessspuren Server leitet jede protokollierte Kontext ausf hrung an den Prozessspuren Visualisierer weiter der die grafische Darstel 175 CORBA basierter Notifikationsdienst f r Prozessbeobachter Klienten Abb 37 Der prozessintegrierte Prozessspuren Visuali sierer 176 Alternative Schnittstelle zur Kontextaktivierung Abb 38 Das generische Anleitungswerkzeug 7 Das PRIME Rahmenwerk lung dynamisch fortschreibt Daneben kann der Prozessspuren Visualisierer auch gespeicherte Prozessspuren fr herer Abl ufe zur Unterst tzung der Nachvollzieh barkeit darstellen ber entsprechende Prozessfragmente ist der Prozessspuren Visualisierer mit dem Hypertext Entscheidungs und
284. eren k nnen w hrend wir umgekehrt die F higkeiten der zur Verf gung stehenden Werkzeuge prozessneutral beschreiben k nnen In einem Integrations schritt werden die Konzepte zur Prozess und Werkzeugmodellierung dann syste matisch zueinander in Bezug gesetzt so dass wir eine explizite und flexibel an passbare Zuordnung von Prozessschritten zu Werkzeugfunktionalit ten erhalten Die wesentlichen Interdependenzen zwischen Prozess und Werkzeugmodel len ergeben sich aus der Modellierung der unterschiedlichen Dienste die der Leit bzw Durchf hrungsdom ne zugeordnet sind und von diesen wechselseitig in Anspruch genommen werden Gem den Anforderungen aus Abschnitt 3 3 4 k nnen drei grundlegende Dienstkategorien in einer prozessintegrierten Entwurfs umgebung unterschieden werden Poh 99 elementare Dienste Beratungsdienste und Anleitungsdienste Diese Dienstkategorien unterscheiden sich modellierungsseitig u a darin ob sie innerhalb des Prozess oder des Werkzeugmodells definiert bzw referenziert werden und ausf hrungsseitig ob die Leitdom ne d h die Prozess maschine oder die Durchf hrungsdom ne d h die Werkzeuge f r ihre Operatio nalisierung zust ndig sind Q Elementare Dienste Dies sind die Basisaktionen die von den Werkzeu gen einer Entwurfsumgebung zur Verf gung gestellt werden und von der Leitdom ne zur Umsetzung atomarer Prozessschritte angefordert werden Beispiele f r elementare Dienste sind das Kompil
285. eringem Aufwand an organisations und projektspezifische Bed rfnisse angepasst werden und sind mit zunehmendem Prozesswissen auch erwei terbar Dynamische Prozessunterstiitzung Der aktuelle Prozesszustand in der Durchf hrungsdom ne l sst sich am besten durch den Zustand der Werk zeuge geladene Dokumente und dort stattfindende Ereignisse Auswahl von Produkten und Kommandos Durchf hrung von Aktionen charakte risieren Prozessintegrierte Werkzeuge gleichen ihren Zustand st ndig mit der Prozessmodellausf hrung in der Leitdom ne ab Dadurch wird ge w hrleistet dass die angebotene Prozessunterst tzung stets auf den aktu ellen Kontext zugeschnitten ist Unterschiedliche Unterst tzungsmodi Die direkte R ckwirkung der Prozessmodellinterpretation auf das Werkzeugverhalten hat mehrere Fa cetten die in unterschiedlichen Unterst tzungsmodi resultieren O Feingranulare Kontrolle Automation es stehen Werkzeugschnittstellen zur Verf gung ber die die Prozessmaschine Aktionen in laufenden Werkzeugen ansto en kann Dadurch k nnen in interaktiven Werk zeuge gut verstandene Abl ufe auch ber Werkzeuggrenzen hinweg au tomatisiert werden O Prozesssensitive Einschr nkung der Interaktionsm glichkeiten Prozessienkung Prozessintegrierte Werkzeuge sind in der Lage die Interaktionsm g lichkeiten des Benutzers dynamisch auf die aktuelle Prozesssituation anzupassen indem sie den Zugriff auf Werkzeugfunktionen und Pro dukte g
286. erleiten MetametaClass Werkzeugkategorie with attribute arbeitet auf Produkt rule r forall p Produkt a Aktion this bietet aktion an a and a input p or a output p this arbeitet auf p end hnlich dem Prozessmetamodell geben wir zun chst keine spezifischen Konzepte f r die Detailmodellierung der den Werkzeugen zugrunde liegenden Produkt strukturen vor sondern greifen auf die in konzeptuellen objektorientierten Mo dellierungssprachen in unserem konkreten Fall UML und O Telos blichen Ausdrucksmittel zur ck Attribute Assoziation Aggregation Spezialisierung etc Das Konzept Produkt steht also stellvertretend f r das einem Werkzeug zugrunde 120 5 Integrierte Prozess und Werkzeugmodelle liegende Produktmodell Da wir das einer Werkzeugkategorie zugeordnete Pro duktmodell immer im Zusammenhang mit den darauf operierenden Aktionen betrachten erhalten wir eine objektorientierte Sicht auf das Produktmodell Modellierungs der Im Gegensatz zu den g ngigen Werkzeugbeschreibungssprachen siehe Ab Interaktionsm glichke schnitt 3 3 4 bezieht unser Metamodell auch die Modellierung der Darstellungs en m glichkeiten f r Produkte und der Interaktionsm glichkeiten des Benutzers mit ein Dies ist erforderlich um sp ter im Umgebungsmodell den Einfluss von Pro zessdefinitionen und des aktuellen Prozesszustands auf die Benutzeroberfl che eines Werkzeugs modellieren zu k nnen siehe Anforderung A5
287. erm glichen m ssen die prozessrelevanten Produkt strukturen die in einem Werkzeug erzeugt gelesen modifiziert oder ge l scht werden k nnen im Werkzeugmodell erfasst werden Da wir auf der Prozessmodellierungsebene inhaltsorientierte Aussagen ber feingranulare Produktkonstellationen treffen m ssen die von einem Werkzeug bearbei teten Produkte im Allgemeinen wesentlich detaillierter als auf der Ebene von Ein und Ausgangsdokumenten modelliert werden Q Basisfunktionalit ten Elementare Dienste die im Prozessmodell als ato mare automatisierbare Prozessschritte referenziert werden werden durch Basisfunktionalit ten der Werkzeuge umgesetzt Dadurch wird im Pro zessmodell gleichsam ein Mindestbedarf an unterst tzender Werkzeug funktionalit t definiert Ein Abgleich mit den tats chlich zur Verf gung stehenden Werkzeugdiensten gelingt nur wenn die Basisdienste der Werk zeuge vollst ndig modelliert werden siehe Anforderung A3 Integrierte Prozess und Werkzeugbeschreibung Abschnitt 3 3 4 Hierbei ist es wich tig dass ein interaktives Werkzeug sowohl aus Benutzer als auch aus Pro zesssicht in der Regel nicht als ein monolithischer Basisdienst angesehen werden kann sondern als eine Sammlung feingranularer prozessrelevanter Dienste O Interaktionsm glichkeiten Gem der Forderung nach prozesssensiti ven Benutzerschnittstellen in prozessintegrierten Werkzeugen siehe An forderungen A5 und A6 Abschnitte 3 3 6 und 3 3 7
288. erst tzungs ae Me H Unterst tzungsmodi modi nicht gegenseitig ausschlie en sondern synergetisch erg nzen Heim90 erg nzen sich BaDF96 Pohl96 DoFe94 WALM99 Daher sollte dem Entwickler in einer Entwurfsumgebung das gesamte Unterst tzungsspektrum von passiver Prozessbe ratung bis hin zu Prozessautomation zur Verf gung stehen Auf welche Art die Prozessunterst tzung in den Entwicklungsprozess eingreifen sollte h ngt in ho hem Ma e von der jeweils zu unterst tzenden Aktivit t ab Generell gilt die Soft wareentwicklung aber auch Entwurfst tigkeiten in anderen Bereichen z B Ver fahrenstechnik als ein offener iterativer und inkrementeller Probleml sungsvor gang der sich einer durchgehenden und umfassenden feingranularen Pr skription entzieht Aktivit ten die durch einen hohen Anteil kreativer Entscheidungssituati onen gekennzeichnet sind oder deren Ergebnisse sich nur schwer vorhersagbar sind lassen sich somit nur schwer pr skriptiv unterst tzen Lehm87 Lehm91 In diesem Fall stellen passive Prozessberatung und ggf aktive Prozessanleitung die ad quateren Unterst tzungsmodi dar Eine wichtige Rolle spielt auch der Erfah rungsstand des Prozessausf hrenden W hrend unerfahrene Entwickler cher darauf angewiesen sind aktiv durch den Prozess gef hrt zu werden kann eine zu restriktive Prozesslenkung bei Experten schnell zu Produktivit tsverlusten und damit zu einer ablehnenden Haltung gegen ber
289. ert dass im jeweils letzten Pull down Men eines Fensters Hilfefunktionen zu finden sind die sich auch ber die Funktionstasten F1 Hilfe bersicht und Crtl F1 kontext sensitive Hilfe aktivieren lassen In den Bereich des so genannten look amp feel f llt auch die Vereinheitlichung des Verhaltens der GUI Elemente z B die Se mantik einer Drag amp Drop Operation die Reaktion auf einen Mausklick mit der linken Taste Objektselektion bzw rechten Taste Aufklappen eines kontextsensi tives Men s oder die konsistente Verwendung der Zwischenablage Clipboard In einem etwas breiteren Sinne verlangt man auch dass hnliche Interaktionen in unterschiedlichen Werkzeugen ann hernd gleiche Antwortzeiten bedingen Im Rahmen dieser Arbeit setzen wir eine einheitliche Gestaltung des visuellen Er scheinungsbilds stillschweigend voraus da hier insbesondere im Desktop Bereich durch die Marktdominanz von Microsoft und durch die Etablierung softwareergo nomischer Gestaltungsrichtlinien Micr95 bereits weitreichende Fortschritte im Vergleich zu fr heren Jahren erzielt worden sind Visuelles Erscheinungsbild 100 3 Integrationsansatze Aus Sicht der Prozessintegration interessanter ist die Frage des verwendeten Interaktionsparadigmas Das Interaktionsparadigma bestimmt die Art und Weise wie Interaktionsparadigmen der Benutzer auf die Entwurfsobjekte und Bearbeitungsfunktionen zugreift Tra ditionell werden das werkzeug funktionsorie
290. erung von Situationen und zur Festlegung eines Kontrollflusses in Plankontexten anbietet Gegenstand des Kapitels war daher insbesondere die Einbettung eines Kontrollmodells in das NATURE Prozessmodell Um Flexibilit t und Anpassbarkeit an dom nenspezifische Bed rfnisse zu ge w hrleisten haben wir das Ziel verfolgt anders als in fr heren Ans tzen nicht mehr nur einen Ablaufformalismus z B Petrinetze oder prozedurale Sprachen fest vorzugegeben oder einen neuen zu erfinden sondern innerhalb gewisser Grenzen die Auswahl aus einer Palette unterschiedlicher Formalismen anzubieten die f r einen betrachteten Ablauf jeweils besonders geeignet sind Hieraus ergab sich das Problem der Inzeroperabilit t verschiedensprachlicher Prozessfragmente f r das in der Literatur im wesentlichen drei L sungsans tze bekannt sind Interope rabilit t ber eine vereinheitlichte Zwischensprache ber einen gemeinsamen Laufzeitzustand oder ber definierte Schnittstellen und Delegation Abschnitt 6 2 Aufgrund der besseren Skalierbarkeit haben wir uns f r einen komponenten basierten Modellierungsansatz entschieden bei dem das NATURE Prozessmodell so erweitert wurde dass Kontexte als Komponenten mit definierten Schnittstellen modelliert und in einer Verwendungssprache unabh ngig von ihrer Implementie rung wiederverwendet werden k nnen Das vorgestellte Schnittstellenmetamodell dient dabei als Komponentenbeschreibungssprache die hnlich einer IDL S
291. erungsseitig beschreiben wollen scheidet diese Option aus Interoperabilit t ber Die beim Transformationsansatz gegebene Abh ngigkeit von einer einheitli Schnittstellen chen Zwischensprache wird durch einen komponentenbasierten Modellierungsan satz berwunden der die einzelnen Formalismen durch definierte Schnittstellen ver birgt siehe Abschnitt 6 2 3 und Abb 25b Um eine Prozesskomponente inner halb einer anderen verwenden zu k nnen muss lediglich die Komponenten schnittstelle mit den Konzepten der jeweiligen Verwendungssprache repr sentiert werden so dass die abgebildete Stellvertreterschnittstelle in der Verwendungsspra che angesprochen werden kann Die Abbildung der Komponentenschnittstelle ist mit der Transformation der Prozessmodelle mit Hilfe einer Zwischensprache vergleichbar wobei die Zwischensprache dabei der Schnittstellenbeschreibungs sprache entspricht Anstelle jedoch eine vollst ndige Transformation des zu ver wendenden Prozessfragmentes vorzunehmen ist hier lediglich die Abbildung der Komponentenschnittstelle erforderlich Semantische Verluste die z B bei der Transformation der Kontrollmodelle der jeweiligen Sprachen auftreten k nnen werden dadurch vermieden Dieser Ansatz ist somit hinsichtlich der Integration von Modellierungssprachen wesentlich skalierbarer als ein Transformationsansatz da die Definition von sprachspezifischen Abbildungsbeziehungen sich auf die f r die Darstellung der Schnittstelle notwen
292. es durch die erfolgreiche Realisierung von vier prozessintegrierten Entwicklungsum gebungen aus den Anwendungsdom nen Requirements Engineering und chemi sche Prozessmodellierung validiert Abstract Abstract Complex modelling tasks in the early phases of information systems development as well as in other engineering domains require suitable software tool support that can be easily adapted to organisation and project specific methods and processes Conventional product oriented CASE tools have often been criticized as being too inflexible as their behaviour is determined by hard coded assumptions of the processes to be supported So called process centred engineering environments which are based on explicit and exchangeable process models allow greater adaptability but mainly address administrative processes at the project manage ment level The consequences of process model enactment on the interactive engineering tools used for the actual task performance have been studied much less In those systems tool behaviour is largely decoupled from process model enactment This thesis investigates the evolution from process centred to process integrated engineering environments Starting with a set of six key integration requirements we develop an integrated modelling approach which extends an existing model for creative processes by additional tool modelling concepts By establishing adaptable cross relationships between the process and the to
293. es Prozesssprachen spezifischen Bindungsmodells Die Konzepte des Schnittstellenmetamodells f r Kontextkomponenten sind dabei bereits vorinstanziiert Schritt 0 siehe auch Tab 9 auf Seite 154 F r die Integra tion einer Prozesssprache m ssen alle Konzepte des PSM2 Modells im Metamo dell der Prozesssprache identifiziert und als PSM2 Konzepte instanziiert werden Schritt 1 Die Integration der Prozesssprache mit dem Schnittstellenmetamodell erfolgt dann durch Instanziierung eines sprachspezifischen Bindungsmodells das die Repr sentation einer Komponentenschnittstelle in der Prozesssprache erm g licht Schritt 2 In einem abschlie enden Schritt werden zus tzliche Abbildungs regeln die nicht schon durch die Struktur bzw die Metaregeln des M2 Modells vorgegeben sind sprachspezifisch auf der Ebene der Sprachkonzepte festgelegt Schritt 3 6 Interoperabilitat von Prozesssprachen Abb 31 Metamodell gesteuerte Integrationsmethodik f r Prozesssprachen Prozesssprachen M2 Modell M2 Ebene Klassifikation von Sprachkonzepten Prozesssprachen Spezifisches Bindungsmodell Meta Ebene i Sprachkonzepte Schritt 3 I 1 Kontext Bindung Aktivit t komponente Prozessmodell Ebene konkrete Prozessfragmente 6 4 2 2 Beispiel Integration von SLANG Netzen Die Instanziierung des M2 Modells und die daraus abgeleiteten Teilschritte der Integrationsmethodik illustrieren wir nun am Beispiel der Einbettung des Petri netz Di
294. es Werkzeugs abgeglichen werden Bet einer erfolgreichen Situationserkennung wird einer oder auch mehrere der in Frage kommenden Situationstypen durch eine passende Konstellation von Pro duktinstanzen instanziiert Der Matching Algorithmus hat folgende Struktur M forall S S ist Situationstyp einer Alternative von EK do M M U BindeSituation S P end falls M Situationserkennung nicht erfolgreich falls M gt 1 w hle eine Situationsinstanz Im Folgenden betrachten wir den Teilalgorithmus BindeSituation genauer Dieser Algorithmus versucht einen Situationstypen S in einer Menge P von Produktin stanzen zu instanziieren Damit ein Situationstyp S instanziiert werden kann muss jeder seiner m Situa tionsteile r i 1 m an einen Wert gebunden sein Wir sagen in diesem Fall dass die Situation g und dass die Bindung s eine Instanz von S ist Formal ist s ein m Tupel 87 5m wobei f r die einzelnen Situationsinstanzteile s i 1 m folgendes gelten muss Q wenn der korrespondierende Situationsteil 7 von der Form ri product T ist muss s eine Produktinstanz sein und Typ s lt T d h s muss eine In stanz vom Produkttypen 7 oder einem seiner Subtypen sein Q wenn der korrespondierende Situationsteil r von der Form ri value V ist muss s ein Wert vom Basistypen V sein Q wenn der korrespondierende Situationsteil r von der Form ri list min Maxi product Tj ist
295. eschrie ben werden die der Benutzer unter Kontrolle der Leitdom ne durchge f hrt hat Ebenso wie der reale Prozess stellt der beobachtete Prozess eine dynamische Sicht dar In einer prozessintegrierten Umgebung m ssen die Sichten in den verschiedenen Prozessdom nen synchronisiert werden und m gliche Abweichungen und Inkon sistenzen vermieden oder geeignet behandelt werden Konflikte zwischen den Prozesssichten k nnen in zwei fundamental verschiedene Kategorien eingeteilt werden Modellinkonsistenzen und Beobachtungsinkonsistenzen Modellinkonsistenzen Eine Modellinkonsistenz tritt auf wenn die reale Prozessdurchf hrung vom er warteten d h laut Prozessmodell erlaubten Verhalten abweicht Dies ist zum Beispiel der Fall wenn ein Entwickler mit der Implementierung eines Quellcode Modules beginnt ohne vorher einen Entwurf f r dieses Modul erstellt zu haben obwohl dies im Prozessmodell so vorgeschen war Eine Modellabweichungen verletzt also im Prozessmodell spezifizierte Randbedingungen und Einschr nkun gen F r das Auftreten von Modellabweichungen gibt es zwei qualitativ unter schiedliche Gr nde Eine m gliche Ursache ist dass ein Entwickler seiner eigenen Urteilskraft hinsichtlich des weiteren Vorgehens mehr vertraut als der Pr skription durch das Prozessmodell oder dass eine Situation auftritt die zum Zeitpunkt der Erstellung des Prozessmodell noch nicht in Betracht gezogen wurde z B wenn aufgrund terminlic
296. eschrieben erfolgt die Definition der Ablaufreihenfolge zwi schen den Teilkontexten eines Plankontexts mithilfe spezifischer Ablaufformalis men Hierzu stehen f r die bislang in das Kontextmodell integrierten Formalismen SLANG Netze und UML Statecharts spezielle Editoren zur Verf gung mit denen der NATPROC Editor bei der Definition oder Modifikation von Plankon texten interagiert Abb 40 ci Plan Context Editor PC_FBW_RefineProc Abb 40 Die prozessintegrierten Plankontext Editoren Slang Editor links SLANG rechts UML Statecharts Pc Plan Context Editor PC_FBW_InspoctRelated bjecte Q Du T Statechart Editor i EC_DEP_getDependentProduct EC_DEP_expandProduct CC_DEP_SelectDepProduct KO a er NEE EC_FBW_RefineGroup PC_FBW_CreateGroupDependencies Choice Context Executable Context Die Plankontext Editoren bieten die folgenden Grundfunktionalitaten an O Grafische Edier und Anzeigefunktionen f r die Sprachelemente der jewei ligen Formalismen Q Auswahl und Import von Kontextkomponenten O Erzeugung von Stellvertreterschnittstellen in der jeweiligen Sprache ge m dem Bindungsmetamodell aus Abschnitt 6 4 O Erzeugung von Bindungsinformationen im Prozess Repository 180 Abb 41 Der prozessintegrierte PRIME Werkzeugmodell Editor 7 Das PRIME Rahmenwerk Q Ablaufvisualisierung bei der Ausf hrung von Plankontexten O SLANG Editor Belegung der Stellen m
297. essgruppe der neu angelegten VT Prozessgruppe und den ggf im Plankontext PC FBW InspectRelatedObjects modifizierten Zusatzinformationen Hypertextdokumente Entscheidungen ange legt Die Aktualisierung der Abh ngigkeitsstruktur erfolgt ber den Plankontext PC FBW CreateGroupDependencies Bei der Aktualisierung sind weiterhin die Benutzerkennung der Aktivierungsmodus des Werkzeuges sowie der Beziehungs typ der Produkte anzugeben die als vorinitialisierten Marken vorliegen Mit der Termination dieses Plankontextes wird die modellierte M Prozessunterst tzung beendet Komponentenbasierte Einbettung existierender Prozessfragmente Obwohl das beschriebene SLANG Netz einen komplexen Ablauf modelliert und mehrere Werkzeuge involviert sind ist der daf r erforderliche Modellierungsauf wand relativ gering und das resultierende M Prozessmodell vergleichsweise ber sichtlich Eine wesentlicher Grund daf r liegt in der sprach bergreifenden Wie derverwendung bereits existierender M Prozessfragmente In dem dargestellten Szenario greift der Methodeningenieur beispielsweise auf die Plankontextkompo nenten PC_FBW CreateDependencies und PC H BW nspectRelatedObjects zur ck die in den Sprachen C bzw UML Statecharts realisiert wurden Einbettung einer Kon Am Beispiel des Plankontexts PC FBW InspectRelatedObjects wollen wir die textkomponente Einbettung ein
298. essintegrierte Werkzeuge 195 Interaktionspartnern in den beiden Dom nen verbirgt und dadurch einen Nachrichtenaustausch auf einem logisch hohem Niveau erm glicht 7 3 GARPIT ein Framework f r prozessinteg rierte Werkzeuge Nachdem wir im vorangegangenen Abschnitt die prozessintegrierten Werkzeuge einer PRIME basierten Umgebung aus der Perspektive ihrer externen Schnittstel len betrachtet haben wenden wir uns nun der internen Architektur des GARPIT Frameworks zu Um die spezifischen Entwurfsentscheidungen besser verstehen zu k nnen skizzieren wir zun chst die wesentlichen funktionalen und nichtfunktio nalen Anforderungen an das GARPIT Framework Abschnitt 7 3 1 Nach einem groben berblick ber die GARPIT Architektur diskutieren wir einzelne Teilsys teme im Detail Abschnitt 7 3 2 7 3 1 Anforderungen an das GARPIT Framework 7 3 1 1 Funktionale Anforderungen Der integrierte Prozess und Werkzeugmodellierungsansatz aus Kapitel 5 und das im vorangegangenen Abschnitt 7 2 definierte Interaktionsprotokoll zwischen den Prozessdom nen bilden das konzeptuelle Fundament f r die Architektur eines prozessintegrierten Werkzeugs Um eine prozessmodellkonforme Prozessdurch f hrung zu gew hrleisten muss das GARPIT Framework die folgenden funktiona en Anforderungen in Form generischer Softwarebausteine umsetzen PoWe97 Poh 99 O Interpretation des Umgebungsmodells Das Werkzeugverhalten wird ma geblich durch die exzernen im Pr
299. eten konnten die Reihenfolge intuitiv aus der Semantik des Kontexts hervorging Anders als in Abb 59 dargestellt ist der Algorithmus in der GARPIT Realisie rung dergestalt optimiert dass die Situationsteile einer Situation bereits vorsortiert sind dies muss nur einmal beim Programmstart getan werden und alle Produktin stanzen zu Beginn des Algorithmus in eine gem ihrer Typzugeh rigkeit sortierte Liste gebracht werden F r die Produktinstanzsortierung betr gt der Aufwand mit den blichen Sortierverfahren O n log n wobei n P ist In den beiden Itera tionen des Algorithmus entf llt somit die Sortierung von P und es k nnen mit konstantem Aufwand jeweils die Kopfelemente von P entfernt und den entspre chenden Situationsinstanzteilen s zugeordnet werden Da m lt n gilt jedem Situa tionsteil muss mindestens eine Produktinstanz zugeordnet werden bringen die ber m laufenden Iterationen in den beiden Hauptphasen des Algorithmus keine zus tzliche Komplexit t mit d h der Aufwand bleibt insgesamt bei O n log n 35 In absteigender Reihenfolge d h der oberste Situationsteil wird an die lteste Produktinstanz gebunden 36 Dar ber hinaus entspricht dieses Verfahren der g ngigen Benutzerf hrung in den meisten Programmen mit Multiobjekt Selektion und asymetrischen Operationen siehe z B die Adgn Funktion in Microsoft Powerpoint 7 3 GARPIT ein Framework f r prozessintegrierte Werkzeuge 219 7 3 3 Implementieru
300. etzt wird der VT Prozess schritt Reaktion durch einen R hrkesselreaktor linkes Symbol in der unteren Ebene von Abb 71 w hrend die Fl ssigtrennung mithilfe einer Destillationskolonne realisiert wird rechtes Symbol in der unteren Ebene von Abb 71 Man erkennt bereits an diesem kleinen Beispiel dass rasch komplexe Verfeine rungsstrukturen entstehen die durch vielf ltige Verfeinerungsbeziehungen zwi schen Flie bildausschnitten charakterisiert sind Dekomposition Anreicherung Spezialisierung Realisierung F r eine korrekte Verfeinerung sind eine Reihe von Konsistenzbedingungen zu beachten z B Balancierungsregeln f r die ein und ausgehenden Str me oder Typkonsistenzen zwischen verfeinerten und verfei nernden Flie bildelementen Beispielsweise w rde es keinen Sinn machen einen Teilfunktion Reaktion durch eine Destillationskolonne zu realisieren Abb 71 Prozess gt Komplexe Flie bildver gt F gt Anreicherung feinerung gt Prozess gt gt gt Dekomposition A v gt Reaktion Trennung gt Spezialisierung v 7 4 Reaktion a Fl ssig lt trennung Realisierung v Reichhaltiges erweiterbares Typsystem f r Flie bildbausteine Ein ausdrucksstarkes Typsystem f r Flie bildbausteine stellt ein unverzichtbares Hilfsmittel zur Steuerung der konsistenten Verfeinerung von Flie bildausschnitten 254 8 Anwendungen
301. euginstanz ausf hrungsbereit EvaluatingSituation Die aktuellen Situationsdaten des Prozesses werden gem dem Situationsausdruck ausgewertet Der Situationsausdruck als Vorbedingung entscheidet dar ber ob mit der Prozessausf hrung fortge fahren oder abgebrochen wird InvalidSituation Dieser Zustand repr sentiert eine ung ltige Situation d h mit der Ausf hrung des Prozesses kann nicht fortgefahren werden Running Im Zustand running wird der Prozess von einem Agenten ausge f hrt Im Falle eines PC_Process wird das Fragment in der Leitdom ne in terpretiert im Falle eines EC_Process wird die entsprechende Werkzeugak tion ausgef hrt und im Falle eines CC_Process die Benutzerauswahl zwi schen den Kontextalternativen vollzogen Suspended Ein Prozess kann w hrend der Ausf hrung unterbrochen wer den und befindet sich dann im Zustand suspended Aborted Im Gegensatz zum Zustand suspended der eine Wiederaufnahme der Prozessausf hrung erm glicht repr sentiert der Zustand aborted ei nen unwiderruflichen Prozessabbruch Dieser kann zum einen aufgrund eines Fehlverhaltens w hrend der Ausf hrung eintreten oder z B durch den Benutzer eingeleitet werden Abb 67 Ausf hrungszust nde der Klasse Process 242 Abb 68 Ausf hrungsmodell der Klasse PC_Process 7 Das PRIME Rahmenwerk O Done Innerhalb des Zustandes done liegen die Ergebnisdaten der Prozess ausf hrung vor und auf den Prozess kann
302. evtCommandSelectionHandler CevtObjectSelectionHandler entgegengenommen in eine einheitliche Form transformiert als Objekte von Subklassen der Basisklasse CevtEvent und in eine Ereignis Warteschlange CevtE ventQueue eingereiht Sobald ein Ereignis im CevtEventQueue Objekt vorliegt wird die Ereignisbehandlung an die Methode handleEvent des CsttStateDriver Objekts delegiert Ausgehend vom aktuell aktiven Zustand werden alle adjazenten Transitionen mithilfe der CsttTransition Methoden checkEvent und checkCondi tion daraufhin gepr ft ob sie schalten k nnen Falls eine schaltbare Transition gefunden wurde wird ein Zustands bergang vollzogen indem nacheinander die doExit Methode des aktuellen CsttState Objekts die doAction Methode der schaltenden Transition sowie die doEntry und doActivity Methode des Zielzu stands aufgerufen werden Dieser Vorgang iteriert solange weitere Ereignisse im CevtEventQueue vorliegen In der g ngigen Framework Terminologie fungiert somit die handleEvent Methode als Template Merbode w hrend die dox Methoden Einschubmethoden darstellen wobei f r letztere zur Laufzeit unter Ausnutzung der Polymorphie jeweils die Auspr gungen der spezifischen Subklassen aufgerufen werden Zusammenfassend k nnen wir festhalten dass die konzeptuelle Spezifikation des Werkzeugverhaltens aus Abschnitt 7 2 1 innerhalb des GARPIT Frameworks als eigener Architekturbaustein Teilsy
303. ew York 1982 Fuggetta A A Classification of CASE Technology Computer S 25 38 Dec 1993 Fugg96 FuGh94 FuW096 Gall90 GaJa96 GaJa96a GaLK98 Gar 94 GaSa79 GeFi92 GeHo94 GHJV95 GiKa91 GoFi94 Gold84 GOOD94 GrHM98 Grif98 Gro 97 GrRWOO Grun99 Gry 99 Literaturverzeichnis 287 Fuggetta A Functionality and Architecture of PSEEs Information and Software Tech nology 38 S 289 293 1996 Fuggetta A und Ghezzi C State of the Art and Open Issues in Process Centered Software Engineering Environments Journal of Systems and Software 26 1 S 53 60 July 1994 Fuggetta A und Wolf A L Hrsg Trends in Software Process John Wiley amp Sons New York Trends in Software vol 4 1996 Garlan D und Ilias E Low cost Adaptable Tool Integration Policies for Integrated Envi ronments S 1 10 1990 Garg P und Jazayeri M Hrsg Process Centered Software Engineering Environments IEEE Computer Society Press 1996 Garg P und Jazayeri M Process Centered Software Engineering Environments In Fug getta A und Wolf A L Hrsg Trends in Software Process John Wiley amp Sons New York Trends in Software Vol 4 1996 S 25 52 Gary K Lindquist T und Koehnemann H Component based Software Process Support In Proceedings of the 13th IEEE International Conference on Automated Software Engineering ASE 98
304. ex ternen Kontext handelt Je nach dem welche Situation vorliegt wird ein interner Kontext aktiviert oder ein GuidanceRequest bzw ExternalECCCRequest abgesetzt Eine konzeptionell etwas elegantere L sung l ge vor wenn die Werkzeuge berhaupt keine Kenntnis der im Umgebungsmodell definierten Zuordnung zwischen Kontexten und Werkzeugen ben tigten und prinzipiell jede Kontextakti vierung Ereignis ContextMatched mithilfe einer ContextRequest Nachricht FR zun chst an den Kommunikationsmanager meldeten Der Kommunikationsmana Veremneitichte Be handlung von werk ger w rde dann je nach Kontextzuordnung im Umgebungsmodell eine Guidance zeuginternen und Request Nachricht an die Prozessmaschine Plankontext eine ExternalECCCRe externen Kontextanfor quest Nachricht an ein anderes Werkzeug werkzeugexterner Kontext oder deringen aber eine ContextRequest Nachricht zur ck an das aufrufende Werkzeug werkzeuginterner Kontext versenden Diese L sung h tte also den Vorzug dass die Zustandssteuerung der Werkzeuge wegen der vollst ndigen Abstraktion von der Kontextzuordnung vereinfacht werden k nnte und lediglich der Kommunika tionsmanager als einzige PRIME Komponente auf die im Umgebungsmodell abgelegten Zuordnungsinformationen zugreifen m sste Dieser Vorteil wird aller dings durch zu erwartende Performanzeinbu en relativiert da dann auch jede 192 Multiplexing Demultiplexing von Nachrich
305. f r die Ausf hrung eines unternehmensweiten Ge sch ftsprozesses nutzen k nnen Aoexistieren ohne sich gegenseitig negativ zu beeinflussen Zwischen den Prozessmaschinen erfolgt jedoch bei der Ausf hrung eines Teilprozesses keine Interaktion so dass die Synchroni sation der Teilprozesse ein manuelles Eingreifen erfordert O Stufe 3 Teilaspekte der Prozessdefinition k nnen von zwei Prozessma schinen geteilt werden indem jeweils ein spezifischer Uberbr ckungsmechanismus den Austausch von z B Produktdaten erm glicht O Stufe 4 Eingeschr nkte Kernfunktionalit ten der Prozessmaschinen k nnen ber offene Schnittstellen wechselseitig in Anspruch genommen werden O Stufe 5 Die volle Funktionalit t eines Workflowmanagementsystems steht ber offene Schnittstellen zur Verf gung so dass die Ausf hrung von Prozess fragmenten auf anderen Prozessmaschinen angesto en werden kann Diese Schnittstelle ist von der WfMC durch den Workflow Definition Interface Standard definiert W MC96 O Stufe 6 Es existiert eine gemeinsame Repr sentation f r Prozessmodelle Die Prozessmodelle k nnen durch ein gemeinsames Austauschformat zwischen den Prozessmaschinen transferiert werden so dass die Wahl der Prozess maschine f r die Ausf hrung nicht relevant ist Dies erm glicht eine Integ 6 2 Interoperabilitat in prozessbasierten Systemen 135 ration der zuvor getrennten Teilprozesse der jeweiligen Prozessmaschinen in einem zentral adm
306. f Kosten von Funktionalit t und Wartbarkeit eingegangen werden m ssen In diesem Zusammenhang werden wir weiter unten auf einige Entwurfsentscheidungen genauer eingehen hinter denen zum Teil Performanz berlegungen stecken 7 3 2 Architektur 7 3 2 1 Darstellung Abb 50 gibt einen berblick ber die wesentlichen Teilsysteme des GARPIT Frameworks Zur Darstellung der Architektur auf dieser relativ groben Detaillie rungsebene verwenden wir zun chst UML Paketdiagramme Sp ter werden wir einzelne Teilsysteme genauer diskutieren und mithilfe von Klassendiagrammen verfeinern Die grau dargestellten Pakete bilden den generischen Anteil des GAR PIT Frameworks In diesen Paketen sind sowohl direkt nutzbare Klassen enthal ten die allgemein verwendbare Funktionalit t fertig implementieren als auch abstrakte Klassen die haupts chlich Schnittstellen f r den Anschluss spezifischer 198 Werkzeugspezifischer Kern Trennung zwischen Prasentationsebene und logischer Produktebene 7 Das PRIME Rahmenwerk Punktionalitat definieren und in spezifischen Werkzeugen durch konkrete Klassen spezialisiert werden m ssen Die werkzeugspezifischen Klassen sind in den wei dargestellten Paketen zusammengefasst Zwischen den Paketen lassen sich drei Arten von Beziehungen identifizieren O allgemeine Importbexiehungen diese Beziehung dr ckt aus dass sich das impor tierende Paket auf Dienste des importierten Pakets abst tzt O Spez alisierun
307. fahr von Beobachtungsabweichungen Indirekt werden damit auch unbewusste Modellabwei chungen verhindert also das Verletzen von Vorgaben des Prozessmodells Aller dings sollten die Werkzeuge auf explizite Anforderung vom Benutzer den gesam ten Funktionsvorrat zu Verf gung stellen und somit bewusste Prozessabweichun gen zulassen 3 3 Integrationsanforderungen in prozessintegrierten Umgebungen 101 3 3 6 2 Bewertung existierender Ansatze Aus Benutzersicht weist das dokumentenorientierte Interaktionsparadigma das in den letzten zehn Jahren besonders im Umfeld Desktop zentrierter Betriebssysteme Windows MacOS starke Verbreitung gefunden hat viele Parallelen zu einem prozessorientiertem Paradigma auf Wie oben bereits angedeutet treten hierbei die eigentlichen Bearbeitungsfunktionen der Werkzeuge in den Hintergrund Das hei t insbesondere dass die Funktionen nicht mehr in Form expliziter Werkzeuge erscheinen sondern sich beispielsweise in kontextsensitiven Men s manifestieren die immer nur dann in Erscheinung treten wenn sie sinnvoll eingesetzt bzw ben tigt werden Dies f hrt dann soweit dass ein Dokument zum intelligenten Assistenten seines eigenen Bearbeiters wird Grif98 Dokumentenmodelle wie z B COM OLE Broc95 oder OpenDoc OrHE96 liefern das technische Fun dament um Dokumentobjekte verschiedener Werkzeuge auch visuell innerhalb eines Fensters als so genannte Compound Documents ineinander schachteln zu k nnen Dadu
308. fe jeweils spezifische Anspr che an einen Formalismus hinsichtlich seiner Ausdrucksst rke d h seines Vorrats an Kontrollflusskonstrukten Ist die Prozess modellierungssprache wie in kommerziellen Workflowmanagementsystemen und den meisten akademischen Ans tzen a priori in Syntax und Semantik unver nder bar festgelegt setzt dies dem Gestaltungsspielraum des Methodeningenieurs enge 17 In diesem Kapitel konzentrieren wir uns auf den Kontrollfluss innerhalb von Plankontexten Wenn von Prozessmodellierungssprachen die Rede ist setzen wir dies daher mit einer Sprache zur Ablanfspezifikation zwischen Teilschritten gleich Eventuell vorhandene andere Konzepte einer Prozessmodellierungssprache Produktmodelle Ressourcenmodelle Organisationsmodelle etc sind somit bei dieser Diskussion ohne Belang 6 2 Interoperabilitat in prozessbasierten Systemen 133 Grenzen denn jeder vordefinierte Sprachumfang bevorzugt eine bestimmte An wendungsdom ne oder eine Klasse von Arbeitsvorg ngen DeHL96 Eine M g lichkeit zur Flexibilisierung bieten Prozesssprachen die dem Methodeningenieur die Einf hrung beliebiger neuer Kontrollflusskonstrukte erlauben BMCJ93 Erkauft wird diese Freiheit jedoch dutch eine erh hte Komplexit t da der Metho deningenieur nun neben der Sprachverwendung auch den Sprachentwurf bew lti gen muss Der in dieser Arbeit verfolgte Ansatz geht einen Mittelweg und erreicht Flexi bilit t dadurch dass der Methodeningenieur bei
309. fgerufen sobald ein dem Werkzeug zugeordneter Kontext aktiviert wurde entweder von au en durch die Prozessmaschine oder durch den ContextMatcher s u Der ContextExecutor exportiert im Wesentlichen die beiden Methoden xecuteChoiceContext CextCCDesc CcxtSituationInstance und executeExe cutableContext CoxtECDesc CcxtSituationInstance f r die Aktivierung eines instanziierten Entscheidungs bzw Ausf hrungskontexts Aktivierung eines Ausf hrungskontexts Bei der Aktivierung eines Ausf hrungskontexts Aufruf der Methode executeExe cutableContext ermittelt der ContextExecutor die ID der Aktion die gem Prozessmodell den Ausf hrungskontext operationalisiert Der ContextCache delegiert den Aktionsaufruf an die Verzeichnisklasse ActionTable weiter in der alle Aktionsobjekte unter ihrer Prozessmodell ID registriert sind Aufgrund dieser Indirektion ben tigt der ContextExecutor keine Kenntnis der werkzeugspezifi schen Action Klassen und kann somit als vollkommen generische Komponente realisiert werden Aktivierung eines Entscheidungskontexts Bei der Aktivierung eines Entscheidungskontexts Aufruf der executeChoiceCon text Methode muss der ContextExecutor die Benutzeroberfl che so anpassen dass nur noch die dem Entscheidungskontext zugeordneten Alternativen vom 7 3 GARPIT ein Framework f r prozessintegrierte Werkzeuge 209 Benutzer ausgew hlt werden k nnen und die zur
310. fied in shell language gt RETURN status code Yl Yn END Aus Sicht der Modellierungsdom ne wird die Durchf hrungsdom ne als eine Menge von Envelopes repr sentiert die dutch die Angabe ihrer Input und Out put Parameter charakterisiert sind Die Typen der Parameter beziehen sich dabei auf das Datenmodell der Modellierungsdom ne also die Objekttypen der in Mar 90 3 Integrationsansatze Abb 16 Werkzeugmodellierung in MTP VaKa96 vel definierten Objektbank Dadurch sind statische Typ berpr fungen von Enve lope Schnittstellen und Regelspezifikationen m glich Der eigentliche Wrapper code der den Aufruf des Werkzeugs sowie die eventuell erforderlichen vor und nachbereitenden Ma nahmen enth lt wird innerhalb des einer blichen Shell Sprache spezifiziert und bei der Ausf hrung an den in der Shell Klausel angegebenen Kommandointerpreter ksh csh oder sh bergeben Als nachteilig erweist sich hier dass in SEL zwar die Envelopes nicht aber die Werkzeuge selbst explizit modelliert werden Dies macht es beispielsweise schwie rig beim Entfernen eines Werkzeugs aus einer Umgebung die Auswirkungen auf die Prozessdefinitionen zu bestimmen End Blocks in Begin Dieser Nachteil wird durch eine Erweiterung von SEL dem Muiti Tool Protocol MTP VaKa96 behoben MTP f hrt als weitere Beschreibungsebene die expli zite Darstellung von Werkzeugen ein siehe Abb 16 Einem Werkzeug zugeord net
311. fsmethodik Wie in Abschnitt 7 1 1 dargestellt besteht das Ziel darin m glichst viele Gemeinsamkeiten zwischen unterschiedlichen Werk zeugen zu identifizieren diese als allgemein verwendbares Werkzeugge r sts heraus zu faktorisieren und wohldefinierte Variationspunkte f r das Einklinken spezifischer Bausteine vorzugeben O Wartbarkeit und Erweiterbarkeit Wartbarkeit und Erweiterbarkeit schl gt sich an unterschiedlichen Stellen der Architektur u a durch Schichtenbildung und durch den Einsatz von Entwurfsmustern nieder Beispielsweise haben wir die Zust nde und Tran sitionen des Werkzeug Zustandsdiagramms aus Abschnitt 7 2 mit Hilfe ei ner Erweiterung des Stare Entwurfsmusters GHJV95 umgesetzt wodurch Umkonfigurierungen und Erweiterungen des Interaktionsprotokolls sogar zur Laufzeit sehr einfach zu realisieren sind Diese und hnliche Entwurfs 7 3 GARPIT ein Framework f r prozessintegrierte Werkzeuge 197 entscheidungen werden wir weiter unten bei der Diskussion der einzelnen Teilsysteme noch eingehend behandeln Des weiteren haben wir im Sinne einer Multi Tier Architektur Ecke95 auf eine strikte Trennung zwi schen Pr sentationskomponenten Produktmodellkomponenten und Ab lauflogik geachtet wobei letztere ja ohnehin au erhalb der Werkzeuge in einfach anpassbaren Prozessmodellen hinterlegt wird Eine etwas andere Art von Schichtenbildung bestimmt das Zusammenspiel zwischen Frame work eigenen Komponenten und Soft
312. g w hlt der Benutzer zun chst eine Task zur Bearbeitung aus Die Task Selektion bilden den Ausgangspunkt f r die Etablierung einen Task speifischen Sub Umgebung in der der Entwickler nur noch den Zugang zu den Daten und Operationen erh lt die zur Erf llung der Aufgabe notwendig sind Aufgabenspezifische Umgebungen in East Eine Task spezifische Sub Umgebung besteht aus zwei Komponenten einer Daten Umgebung die alle Objekte der Objektbasis beinhaltet auf die der Benutzer im Rahmen der ausgew hlten Task Zugriff hat und einer Dienst Umgebung die eine hinreichende Untermenge aller m glichen Operationen umfasst Die Definition der Daten Umgebung erfolgt ber Sichtbarkeitsmechanismen des zugrunde lie genden PCTE Objektmanagementsystems WaJo93 F r jedes Werkzeug und jedes Task Template lassen sich Arbeitsschemata d h eingeschr nkte Sichten auf das Globalschema definieren Die Benutzerschnittstelle aller Werkzeuge wird ber das East User Interface Management System UIMS organisiert wodurch die Pr sentation und der Benutzerdialog von der eigentlichen Funktionalit t des Werkzeugs abgekoppelt wird Eingeschr nkt durch den aktuellen Prozesskontext 102 3 Integrationsansatze unterst tzt das East UIMS einen objektorientierten Interaktionsstil d h die in einem Fenster dargestellten Objekte sind mit einem Pop up Men assoziiert das alle auf einem Objekt anwendbaren Operationen enth lt die durchaus von ver schiedenen Werkzeug
313. g dieses Ent wurfsmuster erm glicht die sprachunabh ngige Realisierung einer wiederverwend baren Funktionalit t Auf diese Weise konnte z B der Ladevorgang d h die In stanziierung eines Prozessfragments generisch realisiert werden da die einzelnen spezialisierten Sprachelemente unabh ngig von einer Prozesssprache erzeugt werden Subprocess Abb 66 Technische Klassen des Interpreterrahmenwerks Process 0 1 Caller start LanguageElement 0 1 suspend atomicActivity gt LanguageElement resume 0 1 Performer abort Product Producer 1 PC Process Factory EC Process CC Process Behavi 1 createActivity makeStep SNAylOUF composite createlnterface commitStep Activity createParameter handleError Int handleAbort interpreten SLANG Process UML Process UML Factory SLANG Factory makeStep makeStep createActivity createActivity commitStep commitStep createlnterface createlnterface createParameter createParameter Die zweite technische Klassenfamilie bilden die Subklassen der Klasse Process Diese werden f r die Ausf hrungssteuerung eines Kontextes ben tigt d h eine Instanz der Klassen EC Process CC Process bzw PC Process operationalisiert jeweils einen Kontext in der PRIME Werkzeugumgebung Die drei
314. g eines Meditiator Message Servers um Konzepts bereits in Forest Gall90 einem fr hen Nachfolger der FIELD Umge policy descriptions bung Anders als bei FIELD werden ankommende Nachrichten insbesondere Notifikationen nicht einfach gem der Registrierung der Nachrichtenmuster an interessierte Werkzeuge weitergeleitet Stattdessen wird die Verteilung durch den Message Server mit Hilfe so genannter policy descriptions gesteuert Diese Regels tze die vom Umgebungsadministrator oder auch vom Benutzer dynamisch ge ndert werden k nnen haben die Form von Event Condition Action ECA Klauseln Der Ereignisteil korrespondiert mit ausgesendeten Nachrichten der Werkzeuge Der Bedingungsteils ist ein Boolescher Ausdruck der sich aus aussagenlogischen Junkto ren A V gt numerischen Ausdr cken vordefinierten Systemfunktionen und benutzerdefinierten Statusvariablen zusammensetzt Der A amp tonsteil kann drei m gliche Formen annehmen Im Normalfall besteht die Aktion im Versenden einer Nachricht an ein Empf nger Werkzeug Diese Nachricht ist dabei in der Regel nicht identisch mit der Nachricht die die Auswertung der policy description verursacht hat Ein typischer Anwendungsfall ist hier dass eine Notifikation eines Werkzeugs auf ein Kommando eines anderen Werkzeugs abgebildet wird Der Vorteil liegt also darin dass ein Werkzeug auf Empf ngerseite nur noch ber eine Kommando Schnittstelle verf gen muss w hrend die Reaktion eines We
315. g mit einer PRIME basierten Umgebung aus Sicht des Methodeningenieurs und des Applikationsingenieurs Abschnitt 8 3 D er PRIME Ansatz wurde bei der Entwicklung und Prozessintegration 8 1 Entwicklungshistorie Ubereinstimmend wird in der Literatur die Framework Entwicklung als ein konti nuierlicher und iterativer Prozess angesehen FaSc99 Grif98 Gry 99 Innerhalb eines Anwendungsbereichs werden ausgehend von einer repr sentativen Applika tion schrittweise Abstraktionen gebildet die in einem Framework generalisiert und Framework Entwicklung f r neue Applikationen wiederverwendet werden k nnen Auf Basis der mit der als iterativer Prozess Framework Anwendung gesammelten Erfahrungen k nnen dann weitere Gemein samkeiten sowie zus tzlich ben tigte Basisfunktionalit ten identifiziert werden die dann als verallgemeinerte Softwarebausteine heraus faktorisiert und in die n chste Entwicklungsstufe des Frameworks aufgenommen werden Auch das PRIME Framework ist das vorl ufige Resultat eines solchen Reife prozesses der sich ber mehrere Iterationen erstreckt hat und in dem sukzessive der Anteil der wiederverwendbaren Komponenten und die Funktionalit t des Frameworks erh ht wurden Um die unterschiedlichen Anwendungen des PRI ME Frameworks die in diesem Kapitel sowie in Pohl96 D m 96 D P098 D mg99 HaPW98 Haum00 Poh 99 WeBa99 JaLW99 genauer beschrieben werden besser in einen Gesamtzusammenhang einordnen zu k nnen ge
316. g von Kontextaktivierungen ist API A6 ist nur f r eine so ge nannte in process extension zugreifbar Aus diesem Grund waren wir gezwungen den Prozessintegrations Wrapper in die Form einer DLL dy namic link library zu transformieren die beim Starten durch einen dyna mischen Lademechanismus zu Visio hinzugebunden wird O Eine Konsequenz der Verschmelzung von Visio und des Prozessintegrati ons Wrappers zu einem Betriebssystemprozess war dass wir zwei konkur rente Ereignisschleifen erhielten eine in Visio und eine im Prozessintegra tionswrapper f r den Empfang von Nachrichten aus der Leitdom ne Da sich diese beiden Ereignisschleifen anfangs gegenseitig blockierten muss ten wir die Ereignisschleife des Prozessintegrations Wrappers leicht modi fizieren Trotz dieser Probleme war die Realisierung des Prozessintegrations Wrappers und die Integration mit den generischen Framework Klassen insgesamt relativ einfach und kanonisch Die geschilderten technischen Schwierigkeiten fallen in die gleiche Kategorie von Problemen die auch andere Autoren GaAO95 MaBF99 Ble 99a bei der Integration unabh ngig voneinander entwickelter Frameworks gemacht haben Wir glauben daher dass die Implementierungsprobleme weniger Ausdruck einer grunds tzlichen konzeptionellen Schw che unseres Modellierungs und Integrationsansatzes sind sondern unvermeidlich sind bei der Integration gr erer Software Einheiten 7 4 4 Zusammenfassung In
317. gaktion zus tzlich realisiert und modelliert werden oder das Pro zessmodell muss so angepasst werden dass die fragliche Werkzeugaktion nicht l nger erforderlich ist Welche der oben skizzierten Situationen vorliegt kann durch folgende generische O Telos Anfrageklasse auf einfache Weise ermittelt werden GenericQueryClass WZ Kategorie f r Aktion isA Werkzeugkategori with _ u u parameter A Aktion constraint AKI this bietet Aktion an A end Je nach dem ob die Anfrage eine mehrere oder keine Werkzeugkategorie als Antwort liefert liegt einer der obigen F lle vor und der Methodeningenieur kann entsprechende Ma nahmen ergreifen Ohne eine explizite Modellierung der Werk zeuge w re ein solcher Abgleich zwischen der im Prozessmodell geforderten Werkzeugunterst tzung und der tats chlichen Werkzeugfunktionalit t nicht m g lich gewesen Dass eine Werkzeugkategorie W die vom Prozessmodell geforderte Aktion A f r die Operationalisierung eines Ausf hrungskontexts AK bereitstellt ist eine 5 5 Integration der Modelle 123 notwendige aber noch keine hinreichende Bedingung f r eine konsistente Zuord nung zwischen W und AK Zus tzlich muss sichergestellt werden dass die input output Relationen zwischen der Werkzeugaktion und den betroffenen Produkten von den entsprechenden Definitionen im Prozessmodell subsummiert werden AK2 Konsistenz bez glich Input Parametern Im Prozessmodell werden die Produkte auf die s
318. ge bislang nur qualitative Aussagen aus ersten Nutzungsexperimenten vor Eine wissenschaftlich fundierte Evaluierung kann nur im Rahmen einer empirischen Untersuchung erfolgen in der erfahrene Entwickler mit einer PRIME Umgebung ein anwendungsnahes Problem bearbeiten Mittlerweile haben die Werkzeuge der PRIME Umgebung einen Grad der Robustheit erreicht die gr er angelegte Nutzerexperimente sinnvoll erscheinen lassen Hierzu werden ebenfalls im Rah men des SFB IMPROVE zur Zeit in Zusammenarbeit mit dem Aachener Lehr stuhl und Institut f r Arbeitswissenschaften entsprechende Evaluationsstudien vorbereitet 9 3 Ausblick Insgesamt haben uns jedoch auch die bereits jetzt vorliegenden Erfahrungen darin bestarkt dass eine an Prozessen ausgerichtete Adaptabilitat von Werkzeug umgebungen dem Anwender viele Vorteile bringt und in Zukunft noch an Bedeu tung gewinnen wird Dieser Trend wird zum Beispiel auch aktuell durch die Tatsa che belegt dass Microsoft in seiner kommenden Betriebssystem Version Windows XP verst rkt auf eine aufgabenorientierte Benutzerf hrung setzt 277 AbAG95 AbCa96 Abel95 ABGM93 Alde91 Alla97 Alo 96 AmCF97 And 99 Ande90 AnGr94 ApRi99 ArOg94 AT amp T84 AT amp T96 Atk 89 AvBC96 AvBC96a Literaturverzeichnis 279 Literaturverzeichnis Abowd G Allan R und Garlan D Formalizing Style to Understand Descriptions of Software Architectu
319. gement ACM Computing Surveys 30 2 S 232 282 1998 Coad P und Yourdon E Object Oriented Analysis Yourdon Press Prentice Hall Englewood Cliffs New Jersey 1991 Coad P und Yourdon E Object Oriented Design Yourdon Press Prentice Hall Englewood Cliffs New Jersey 1991 Cugola G Di Nitto E und Fuggetta A Exploiting an Event based Infrastructure to Develop Complex Distributed Systems In Proc 20th Intl Conf on Software Engineer ing Kyoto Japan IEEE Computer Society Press Aug 1998 S 261 270 Cugola G Tolerating Deviations in Process Support Systems via Flexible Enactment of Process Models IEEE Transactions on Software Engineering 24 11 S 982 1001 Nov 1998 Curtis B Kellner M und Over J A Field Study of the Software Design Process for Large Systems Communications of the ACM 33 11 S 1268 1287 1988 Curtis B Kellner M und Over J Process Modeling Communications of the ACM 35 9 S 75 90 Sept 1992 Dami L Estublier J und Amiour M APEL A Graphical yet Executable Formalism Jor Process Modelling Automated Software Engineering Journal 5 1 S 61 96 1998 Digital Equipment Corporation The DEC FUSE Handbook 1993 Deiters W und Gruhn V Software Process Validation Based on FUNSOFT Nets In Proc 2nd Europ Workshop on Software Process Technology Trondheim Nor way Springer Verlag LNCS 635 1993 S 50 52 284 Literaturverzeichnis DeH
320. gig davon ob die Hilfeleistung statisch ist oder den aktuellen Kontext und oder den Erfahrungsstand des Benutzers ber cksichtigt Da Hilfe Tab 4 systeme au er dem Auslesen von Statusinformationen nicht direkt mit dem Prozessunterst tzung zugrunde liegenden Werkzeug interagieren k nnen Hilfesysteme nicht durch Hilfesysteme lenkend in dem Sinne dass sie den Zugriff auf bestimmte Werkzeugaktio nen verhindern oder gar automatisierend in den Prozess eingreifen Art der Integrations Kontext Anpassbarkeit Unterst tzungsmodi Prozessunterst tzung tiefe bezogenheit rechnerbasiert se rechnerbasiert in passive Beratung aktive Anleitung erzwingend lenkend automatisierend 2 5 L 5 20 E as technisch statisch dynamisch konfigurierbar anderbar Hilfesysteme statisch uniform dynamisch individuell passiv aktiv 2 2 3 Assistenten In modernen Entwicklungswerkzeugen und umgebungen aber auch in Standard applikationen wie Textverarbeitungs und Tabellenkalkulationsprogrammen ist eine stetige Zunahme des Funktionsumfangs zu beobachten Viele Anwender sind 2 2 Bewertung existierender Ansatze 31 mit der damit einher gehenden steigenden Benutzungskomplexit t berfordert Auch die Unterst tzungsleistung von Hilfesystemen wird hier h ufig als unzurei chend empfunden Zum einen ist das Auffinden der relevanten Informationen nicht immer einfach da der Benut
321. glicht Hierbei werden in der Regel abstrakte Klassen die vom Framework vorgegeben sind durch die Frame work Erweiterungen spezialisiert und mit spezifischer Funktionalit t angereichert wobei objektorientierte Mechanismen wie Polymorphie und die sp te Bindung von Methodenaufrufen ausgenutzt werden Ein Framework zielt nicht nur auf reine Code Wiederverwendung ab sondern insbesondere auch auf Architektur Wiederverwendung Gerade aus der letztge nannten Art der Wiederverwendung resultieren nach Ansicht vieler Autoren die bedeutenderen Potenziale f r eine Produktivit tssteigerung bei der Software Ent wicklung Pree97b GHJV95 FaSJ99 Als wichtige Konsequenz aus der durch Frameworks unterst tzten Architektur Wiederverwendung tritt das Ph nomen der 7 1 Die PRIME Gesamtarchitektur Kontrollinversion auf Bei der konventionellen Wiederverwendung auf Basis von Komponenten Bibliotheken erstellt der Applikationsentwickler ein Softwareger st das existierende Komponenten aufruft Bei der Framework basierten Entwicklung schreibt der Applikationsentwickler dagegen Softwarebausteine die an definierten Variationspunkten in das Framework gesteckt und von diesem aufgerufen werden Da das Interaktionsmuster der Teilkomponenten bereits festgelegt ist liegt die Verantwortung f r Steuerung des Kontrollflusses nicht mehr beim Nutzer eines Frameworks sondern beim Framework selbst Dem Anwendungsentwickler werden somit sehr viele und oft schwierige
322. gmodelle Pur die korrekte Zuordnung von Entscheidungskontexten zu Werkzeugkate gorien lassen sich wie bei der Assoziation von Ausf hrungskontexten zu Werk zeugkategorien eine Reihe von Konsistenzbedingungen formulieren Wie oben bereits erl utert muss eine Werkzeugkategorie W die alternativen Kontexte C C eines ihr zugeordneten Entscheidungskontexts EK zwar nicht selbst ausf hren k nnen Es ist jedoch erforderlich dass alle Alternativen potenziell in dem Werkzeug aktiviert werden k nnen EK1 Aktivierbarkeit der Situationen Dazu muss ein Werkzeug zum einen in der Lage sein alle Produkte darstellen zu k nnen die potenziell zu den Situationen der alternativen Kontexte betragen Diese Bedingung wird mithilfe eines O Telos Constraints formalisiert welcher im Umgebungsmodell der Assoziation f hrt EK aus zwischen Werkzeugkategori und Entscheidungskontext zugeordnet wird Attribute Werkzeugkategorie f hrt EK aus with constraint EKl forall w Werkzeugkategori k Entscheidungskontext k Kontext p Produkt s Situation From w this and To this ek and ek alternative k and k besteht _aus Situation s and s basiert auf p gt w Darstellungselement p end Mithilfe der Integritatsbedingung EK1 wird also zugesichert dass f r jedes Produkt das f r die Situationsauswahl in einer Werkzeugkategorie relevant sein k nnte ein entsprechendes Darstellungselement existiert In der Integrit
323. grierbaren Werkzeuge hinaus wurden eine Reihe von Schnittstellen zu den anderen Kompo nenten der SFB Gesamtumgebung realisiert mit deren Hilfe die Unterst tzungs mechanismen der unterschiedlichen SFB Teilprojekte synergetisch verzahnt wer den konnten Beispielsweise bietet die Prozessmaschine eine CORBA Schnittstelle an ber die das Frontend des arbeitsplatz bergreifenden Projekt Administrations systems die Ausf hrung von M Prozessfragmenten in der PRIME IMPROVE Umgebung ansto en und berwachen kann Die Funktionalit t dieser Schnittstel len orientiert sich an dem entsprechenden Standard der W MC 8 3 Beispielsitzun 25 vollstandig prozess partiell prozess integrierte Werkzeuge integrierte Werkzeuge he ESSE lal _ _ _ __ _ _ Metamodellierungs Entwickler werkzeuge werkzeuge Aspen Plus MS Excel Prozess Flie bildwerkzeug Ne meer Repository Werkzeug Abh ngigkeits ee Morex modellierung visualisierung N Prozessintegrations ME GE Wrapper Situations Umgebungs Entscheidungs analyse modellierung dokumentation PDW J Andere SFB m 6 APIs f r Unterst tzungs Prozessintegration z B mechanismen Berka Hypertext Aktionsaktivierung Administrations ankontext bearbeitung Kommando system Frontend Modellierung peee einschr nkung FB Datenmodell multimediale Adhoc 7 s Kommunikat
324. gsbeziehungen diese Beziehung definiert die Variationspunkte des Frameworks indem sie den Bezug zwischen Paketen die abstrakte Framework Klassen beinhalten und werkzeugspezifischen Paketen her stellt Spezialisierungsbeziehungen k nnen als eine besondere Art von Im portbeziehungen aufgefasst werden da die Klassen des spezielleren Pakets via Vererbung Dienste von den Klassen des allgemeineren Pakets in An spruch nehmen O R ckruf Beziehungen Einige Pakete generieren asynchron Ereignisse von de nen Pakete die in der Importhierarchie der Architektur h her angesiedelt sind notifiziert werden m ssen Eine solche Notifikation erfolgt blicher weise ber den Aufruf von R ckruf Operationen oder Objekten Call backs die die an den Ereignissen interessierten Komponenten zuvor bei der Ereignis produzierenden Komponente registriert haben Die dadurch induzierte erst zur Laufzeit entstehende Beziehung zwischen dem Ereig nis produzierenden und Ereignis empfangenden Paket deklarieren wir in der Architektur als R ckruf Beziehung Wir vermeiden dadurch uner w nschte zyklische Importabh ngigkeiten insbesondere werden die Sig naturen der Ruckrufoperationen bzw der Typ der R ckrufobjekte im Er eignis produzierenden Paket definiert so dass keine wechselseitigen Com pilezeit Abh ngigkeiten entstehen 7 3 2 2 Teilsysteme in berblick Der werkzeugspezifische Kern eines GARPIT basierten Werkzeugs wird in den Teilsystemen T Model T G
325. hase die Reihenfolge in der die Zuordnung von Produktinstanzen zu Situationsteilen vorgenommen wird eine wichtige Rolle spielt werden die Situationsteile in einer Vorbereitungsphase vorsottiett Hierbei ist zum einen zu ber cksichtigen dass die Produkttypen in einer Spe Reihenfolge der Situati zialisierungshierarchie angeordnet sind und Produktinstanzen eines bestimmten Onsteilbindung wichtig Typs auch zu Situationsteilen zugeordnet werden k nnen die einen in der Spezia lisierungshierarchie allgemeineren Typen verlangen Substituierbarkeitsprinzip Daher m ssen Situationsteile mit spezielleren Typanforderungen vor solchen mit allgemeineren Typanforderungen an die geforderte min Anzahl von Produktin stanzen gebunden werden Ein Beispiel aus der Situationsmodellierung des ER Editors illustriert die potenziell auftretenden Probleme siehe Abb 60 bei einer falschen Reihenfolge der Situationsteil Bindung Die Situation Ser besteht aus zwei my Situationsteilen r und rz die jeweils eine Produktinstanz vom Typ ER Object bzw ER Entity verlangen wobei ER Object als Wurzel der Produkttyphierarchie des im ER Editors verwendeten Produktmodells alle anderen ER Produkttypen sub summiert ER Entity ER Relationship ER Attribute Die Menge der aktuell g ltigen Produktinstanzen besteht aus dem Objekt book von Typ ER Entity und T lend by vom Typ ER Relati
326. hen Umfeld erlauben keine Methoden und haben ihren Ursprung in um kom plexe Strukturen und Vererbung erweiterten Entity Relationship Modellen Chen76 EINa99 In dem objektorientiert logikbasierten Datenmodell O Telos Jeus92 bernehmen deklarativ formulierte Regel und Integrit tsbe dingungen die Rolle von Methoden O Telos eignet sich aufgrund seiner beliebig erweiterbaren Klassikationshierarchie besonders zur Metamodel lierung Generell kann festgestellt werden dass das relationale Datenmodell gravierende Defizite aufweist hinsichtlich einer ad quaten Darstellung komplexer Strukturen wie sie in Entwurfsanwendungen h ufig auftreten Andererseits haben Daten bankmanagementsysteme f r nicht relationale Datenmodelle den Durchbruch bislang nicht geschafft nicht zuletzt aufgrund immer noch mangelnder Perfor manz und Skalierbarkeit Einen Kompromiss zwischen Modellierungsangemes senheit und Leistung stellen objekt relationale Systeme dar In diesen Systemen liegen Daten zwar immer noch in Tabellenform vor es k nnen jedoch zus tzliche benutzerdefinierte komplexe Datentypen eingef hrt werden Transaktionskontrolle Ein Aspekt der Datenhaltung der durch die Prozessintegration einer Entwurfs umgebung unmittelbar ber hrt wird ist die Transaktionskontrolle Ziel ist hier die Behandlung eines Prozessschritts oder einer Folge von Schritten als eine atomare Ausf hrungseinheit Entwurfsschritte mit einer Vielzahl von Datenoperationen sol
327. hen Fortschritt gegen ber einem fr heren Modellierungsansatz dar der ebenfalls auf dem NA TURE Prozessmodell beruhte und den Ausgangspunkt f r diese Arbeit bildete Weid95 Pohl96 Q A4 Feedback Informationen f r Synchronisation Die f r die Syn chronisation der Prozessdom nen erforderlichen prozesskonformen R ckmeldungen werden durch das Umgebungsmetamodell inh rent vor gegeben bei Entscheidungskontexten durch die vordefinierten Alternati ven bei Ausf hrungskontexten durch die als output definierten Produkte der mit dem Ausf hrungskontext assoziierten Aktion In Abschnitt 7 2 for malisieren wir ein Interaktionsprotokoll das diese durch das Umgebungs metamodell vorgegebene Struktur in den verwendeten Nachrichtentypen widerspiegelt A5 Prozesssensitive Benutzeroberflachen Entscheidungskontexte modellieren Arbeitsmodi die auf einen bestimmten Prozesskontext zuge schnitten sind Bei der Ausf hrung eines Entscheidungskontexts findet ein Werkzeug im Umgebungsmodell alle erforderlichen Informationen dar ber welche Alternativen aktuell angeboten werden sollen und wie die Al ternativen in der Benutzeroberfl che darzustellen sind Darstellung der hervorgehobenen selektierbaren und deaktivierten Produkte Darstellung von Benutzerintentionen durch Kommandoelemente wie Men eintr ge Kommandoicons und Shortkeys Ein Werkzeug wird somit in die Lage versetzt seine Benutzeroberfl che prozesssensitiv anzupassen Q
328. her oder personeller Engp sse Priorit ten neu gesetzt und eigentlich sinnvolle Schritte ausgelassen werden m ssen In diesen F llen weicht Pewusste Prozessab ickl weichungen sollten der Entwic er bewusst von den Vorgaben des Prozessmodells ab Eine prozessin zugelassen und ent tegrierte Umgebung sollte bewusste Modellabweichungen des Benutzers vom vorge sprechend behandelt gebenen Prozess grunds tzlich zulassen und unterst tzen Nachdem fr he Prozess Werden In CDFG96 Cugo98 werden hierf r die Begriffe domain level bzw environment level inconsistencies verwendet 96 3 Integrationsansatze unterst tzungsans tze anfangs stark auf Automatisierung und strikte Prozesslen kung ausgerichtet waren hat sich mittlerweile die Ansicht durchgesetzt dass letzt endlich der menschliche Benutzer das Prozessgeschehen diktieren sollte und nicht das Prozessmodell Redw93 WALM99 Pohl97 Dies trifft gerade in Ent wurfsdom nen mit einer Vielzahl kreativer Entscheidungen zu wo strikte Unter st tzungsans tze schnell als zu unflexibel und rigide abgelehnt werden Hier k n nen Prozessabweichungen vielmehr eine wichtige Informationsquelle f r die Prozessverbesserung darstellen JPRS94 Hump89 Es h ngt allerdings auch vom konkreten Anwendungskontext ab in welchem Ma e Abweichungen vom inten dierten Prozess tolerierbar sind Bei gutverstandenen und repetitiven Abl ufen die vornehmlich in betrieblichen Prozessen im Rahmen von W
329. hinsichtlich der Planbarkeit der zu unterst tzenden Prozesse auf Auf der Projekt managementebene wird die durchg ngige Unterst tzung des gesamten Entwick lungsprozesses angestrebt um ein Instrument f r Arbeitsplanung Ressourcenzu teilung und Fortschrittskontrolle an der Hand zu haben Unterst tzungsans tze f r das Projektmanagement schen sich hier u a mit dem Problem konfrontiert dass auf nderungen der Rahmenbedingungen z B K rzung der Projektlaufzeiten des Budgets Ausscheiden von Mitarbeitern und unerwartete Probleme bei der Pro Durchg ngigkeit jektdurchf hrung entsprechend flexibel reagiert werden muss Die Behandlung Ausnahmebehandlung iS i a ae von Ausnahmesituation in Prozessunterst tzungsans tzen f r die Projektmanage mentebene ist zur Zeit Gegenstand regen Forschungsinteresses siehe z B CDFG96 CDGM95 Ober96 CaFM99 Gemeinsam ist allen Ans tzen jedoch dass eine gewisse Granularit t der betrachteten Aufgaben nicht unterschritten 2 1 Ein Klassifikationsmodell fur Prozessunterstutzungsfunktionen 17 wird um das Prinzip der durchg ngigen Prozessunterst tzung nicht aufgeben zu m ssen Die auf der Arbeitsplatzebene betrachteten Prozesse beziehen sich hinge gen auf feingranulare eng umgrenzte lokale Teil Ablaufe Eine durchg ngige Pr skription aller Arbeitsabl ufe ist hier nicht m glich und wird auch gar nicht angestrebt da ein gro er Teil der in der Softwareentwicklung und insbesondere in den f
330. hlie lich begr nden wir an welche der dargestellten grunds tzli chen Integrationsm glichkeiten wir unser Konzept anlehnen 6 2 1 Standards W hrend im Bereich der Softwareprozessmodellierung noch keine Konsolidierung der unterschiedlichen Modellierungssprachen zu beobachten ist entstand in der Workflowmanagement Praxis mit der nunmehr breiten Verf gbarkeit von Werk zeugen f r die Modellierung Analyse Simulation und Ausf hrung von Gesch fts prozessen der Wunsch die Produkte unterschiedlicher Hersteller miteinander kombinieren zu k nnen Hay 00 Schu99 Als wichtigste Standardisierungsaktivi t ten f r die Interoperabilit t prozessbasierter Systeme sind das Workflow Refe rence Model der Workflow Management Coalition Hol95 und der OMG Workflow Management Facility Standard auch als jointF ow Spezifikation be kannt OMG 98a zu nennen 6 2 1 1 WfMC Referenzmodell Das Workflow Management Referenzmodell der W MC definiert die Interopera bilitat zwischen unterschiedlichen Workflowmanagementsystemen beziehungs weise zwischen deren Teilsystemen Der Grad der Interoperabilit t zwischen den Prozessmaschinen unterschiedlicher Workflowmanagementsysteme wird in insge samt acht Interoperabilit tsstufen eingeteilt O Stufe 1 Auf dieser Stufe existiert eine Interoperabilitat zwischen den be trachteten Workflowmanagementsystemen O Stufe 2 Zwei unabh ngige Prozessmaschinen die die gleiche Hard und Softwareinfrastruktur
331. ht welches aus einer hierarchisch angeordneten Anzahl von Klassen besteht Die Klassenhierarchie wird ausgehend von der Wurzel Enzity in die Klas sen Activity Ressource und Relation spezialisiert und ist in weitere durch PIF vorge gebene Subklassen aufgeteilt Kontrollflusskonstrukte werden in PIF als spezielle Aktivit ten dargestellt die je nach Bedarf verfeinert werden k nnen Somit sind im Gegensatz zu den Transitionskanten der WPDL die Kontrollflusskonstrukte in PIF auch erweiterbar Die Vor und Nachbedingungen von Aktivit ten werden in der Sprache KIF GeFi92 formuliert 138 6 Interoperabilitat von Prozesssprachen 6 2 2 Foderierte Interoperabilitatsansatze 6 2 2 1 ProcessWall Ansatz Prozessaustauschformate erzielen Interoperabilitat zwischen Prozesssprachen durch Transformation tiber eine Zwischensprache d h der Integrationspunkt liegt in der Modellierungsdom ne In Heim92 wird mit der ProcessWall Umgebung ein Interoperabilitatsansatz vorgeschlagen bei dem der Integrationspunkt von der Modellierungs in die Leitdom ne verschoben wird Die wesentliche Idee hinter Interoperabilit t ber diesem Ansatz besteht darin dass der Prozesszustand mehrerer zusammenarbei zentralen Zustandsserver tender Prozessmaschinen von dem Formalismus d h der Ablaufmodellierungs sprache getrennt werden kann der ihn modifiziert Dazu verwaltet ein zentraler Zustandsserver zur Laufzeit den globalen Zustand der Prozessausf hrung Der Prozess
332. i alle Werkzeuge die eine bestimmte Datei bearbeiten d h auch Sitzungs bergreifend both Vereinigungsmenge aus session und file und file session Schnittmenge aus session und file O Disposal Dieses Attribut gibt an was ToolTalk f r den Fall dass kein passender Empf nger einer Nachricht gefunden wird tun soll O State Uber dieses Attribut wird dem Absender einer Nachricht mitge teilt ob ein Empf nger gefunden wurde oder nicht Neben FIELD Softbench und ToolTalk existieren noch eine Reihe weiterer Ans tze und kommerzieller Produkte die auf dem Message Broadcasting Prinzip basieren oder zumindest Architekturen gem diesem Paradigma erm glichen Als kommerzielle Ans tze sind ist die FUSE Umgebung von Digital DEC 93 und die SDE Workbench 6000 von IBM zu nennen Weitere Message Broadcasting Ans tze JavaBeans Engl97 das Komponentenmodell von Sun auf Basis der Program miersprache Java Flan00 definiert einen Ereignismechanismus mit dessen Hilfe sich JavaBeans Komponenten wechselseitig ber Zustands nderungen informie ren k nnen Das zugrunde liegende Ereignismodell basiert auf einer EventSource dem ereignismeldenden Objekt das Ereignisobjekte an ein oder mehrere Event Listener Objekte sendet die eine definierte Schnittstelle implementieren und sich vorher beim EventSource Objekt registriert haben m ssen Zur Entkopplung von Source und Listenerobjekt sowie zur Anpassung inkompatibler Schnittstellen k
333. iX iY 3b create roles and relationship in product model TermRoleList lsperlRoles PCermRole perl PCermEntity pere forall pere lspereEntities create an ermRole object perl new CermRole perm gt connectEntityRole pere perl lsperlRoles append perl create product model object for relationship PCermRelationship perr perm gt insertRelationship lsperlRoles sLabel iX iY 4 insert objects into object table PTmapGrObj pgol perot gt insertRelationship pgo perr list_item roleitem lsperlRoles first forall pgoI lspgoRoleLinks perl lsperlRoles contents roleitem pgo NULL perot gt addConnection pgol pgo pgo perl perr roleitem lsperlRoles succ roleitem 5 create output situation instance CcxtSitData sdRet sdRet setSitDesc _perinERED gt retCxtMgr gt reloadSituation oidST ER OneRelationshipSelected sdRet setProdData perr gt getObjectID oidPT_ER Relationship sSR_ER Relationship return sdRet In Schritt 2 und 4 wird die ObjectTable benutzt um zu einer gegebenen Produkt instanz ID die korrespondierenden Produktmodell und GUI Objekte zu ermit teln bzw um die Korrespondenz zwischen Produktinstanz ID Produktmodell und GUI Objekten dort abzulegen Die Klasse CmapObjectTable aus dem Frame work Paket map bietet hierf r im Prinzip bereits die n tige Funktionalit t in Form generischer Methoden In den meisten Werkzeugen so auch im
334. ich ein Ausf hrungskontext AK bezieht durch die mit AK assoziierte Situation S festgelegt Sei Ps die Menge der so mit AK indirekt assoziierten Produkten Weiterhin sei P4 die Menge der Pro dukte die im Werkzeugmodell ber die Assoziation input mit der Aktion A ver bunden ist Dann muss P4 lt Ps gelten d h die durch die Situation spezifizierte Produktkonstellation subsummiert die f r die Durchf hrung der Aktion ben tig ten Eingangsprodukte P4 kann dabei eine echte Teilmenge von Ps sein da zur Bestimmung der G ltigkeit der Situation S durchaus eine gr erer Produktaus schnitt betrachtet werden kann als zur eigentlichen Durchf hrung der Aktion A erforderlich ist Dies l sst sich in O Telos mithilfe der folgenden Integrit tsbedin gung AK2 formalisieren die zweckm igerweise der Attributkategorie Werkzeugka tegorie f hrt AK aus zugeordnet wird Attribute Werkzeugkategorie f hrt AK aus with constraint AK2 forall p Produkt ak Ausf hrungskontext a Aktion From this ak and ak ausgef hrt durch a and a input p gt exists s Situation ak besteht _aus Situation s and s basiert _auf p end AK3 Konsistenz bez glich Output Parametern Die Effekte einer Aktion A auf das in Bearbeitung befindliche Produkt werden im Prozessmodell durch die Assoziation ndert beschrieben Aus Sicht der Werk zeugmodellierung werden die Ausgabeparameter einer Werkzeug Aktion durch die Assoziation output
335. ich in der Benutzeroberfl che der Werkzeugs wider spiegeln d h ein Werkzeug sollte in der Lage sein die Interaktionsm glichkeiten des Benutzers prozesssensitiv anzupassen indem der Zugriff auf Objekte und Kommandos an der Benutzeroberfl che dynamisch eingeschr nkt wird Abschnitt 3 3 6 Anforderung 6 Werkzeugunterst tzter Aufruf von Prozessfragmenten Die Werkzeug sollten den Entwickler beim Abgleich der im Werkzeug vorliegen den Prozesssituation mit den Prozessdefinitionen unterst tzen und ggf den Auf ruf von Prozessfragmenten direkt aus der Benutzeroberfl che des Werkzeugs erlauben Im Idealfall sollte f r den Entwickler kein Unterschied zwischen der Aktivierung werkzeugeigener Dienste und extern definierter Prozessfragmente bestehen Abschnitt 3 3 7 3 3 2 Datenintegration zwischen den Prozessdom nen 3 3 2 1 Motivation Werkzeuge erzeugen konsumieren modifizieren transformieren und analysieren im Zuge des Entwurfsprozesses auf vielf ltige Art und Weise Datenobjekte Ein Teil der Daten ist nicht persistent und nur f r die Dauer eines Arbeitsschritts relevant In der Regel reicht die Lebensdauer der Daten jedoch ber die eines Bearbeitungsschrittes in einem einzelnen Werkzeug hinaus Die Notwendigkeit zur Datenintegration resultiert somit aus der Tatsache dass Werkzeuge nicht auf isolierten disjunkten Datenbest nden arbeiten Vielmehr legt das Prozessmodell eine Abfolge von Bearbeitungsschritten fest die im Allg
336. ich mit extern defi nierten Kontextdefinitionen vornehmen zu k nnen Wir haben die Anforderungen an die Funktionalit t der Schnittstellen bewusst implementierungsunabh ngig formuliert da man trotz gleicher Schnittstellenfunk tionalit t bei existierenden Werkzeugen jeweils von unterschiedlichen Schnittstel lensignaturen Bindungsmechanismen Aufrufprotokollen etc ausgehen muss Bietet ein Werkzeug s mtliche APIs Al A6 an so kann im Prinzip die glei che Integrationsqualit t erreicht werden wie bei einem Werkzeug das a priori mithilfe des GARPIT Frameworks entwickelt wurde Da das Produktmodell die 7 4 Integration existierender Werkzeuge 229 Aktionen und die Benutzeroberflachenelemente vollstandig offen liegen kann das Werkzeug zun chst im Werkzeugmodell nachmodelliert und darauf aufbauend in Prozessfragmente eingebunden werden Der so erreichbare Grad der Prozessintegration ist als idealtypisch anzusehen Eingeschr nkte Formen Beim Fehlen ein oder mehrerer APIs lassen sich jedoch noch abgeschw chte der Prozessintegration Formen der Prozessintegration realisieren Beispielsweise kann auch ohne die GUI bezogenen APIs A3 A6 immer noch eine Integration erreicht werden bei der die Prozessmaschine feingranular Ausf hrungskontexte im zu integrierenden Werkzeug ansteuern kann Fehlt nur die API A3 Kommandoerweiterung ist sogar eine prozesssensitive Anpassung der Interaktionsm glichkeiten d h die Prozessmaschinen gesteuert
337. ie lich auf Visio dessen St rken in der umfassenden und anpassbaren Symbolbibliothek und den auf COM Schnitt stellen basierenden Erweiterungsmechanismen liegen die den feingranularen Zugriff auf Visios internes Objektmodell durch externe Zusatzkomponenten erlauben Die Anbindung von Visio an die PRIME basierte M Prozessunterst tzung mithilfe des M Prozessintegrations Wrappers wurde bereits in Abschnitt 7 4 3 ausf hrlich beschrieben Wir konzentrieren uns daher an dieser Stelle auf die Erweiterung von Visio um ein verfahrenstechnisches Flie bild Datenmodell das die oben skizzierten Anforderungen erf llt Inhaltsorientiertes Produktmodell In Visio werden technische 2D Zeichnungen wie Flie bilder Schaltbilder oder Diagramme gem einem sehr einfachen Objektmodell als flache Graphen beste hend aus ungetypten Knoten und Kanten verwaltet Dieses Modell repr sentiert eine dokumentenorientierte Sichtweise bei der Pr sentationsaspekte Layoutin formationen im Vordergrund stehen ohne dass eine inhaltliche Strukturierung der zu verwaltenden Information erfolgt Die im vorigen Abschnitt skizzierten Anforderungen an einen Flie bild Da tenmodell k nnen mithilfe des Visio Modells nicht umgesetzt werden da es bei spielsweise nicht ohne Weiteres m glich ist Zeichenelemente mit semantisch reichhaltigen Typinformationen zu versehen sie nach logischen Gesichtspunkten zu gruppieren und in einer Verfeinerungshierarchie anzuordnen sowie Kons
338. ie Angabe der Kontextalternativen imple mentiert werden 6 4 Schnittstellenbindung Das im vorangegangenen Abschnitt vorgestellte Schnittstellenmetamodell ist zun chst unabh ngig von einer spezifischen Prozessmodellierungssprache zu betrachten da es aus Verwendungssicht hnlich einer IDL Schnittstellenbeschrei bungssprache nur als neutrale Beschreibungssprache f r Kontextkomponenten dient Damit eine so beschriebene Kontextkomponente im Rahmen einer Plan kontextspezifikation in einer konkreten Prozesssprache verwendet werden kann ist es erforderlich dass das Schnittstellenmetamodell und das Metamodell der gew hlten Prozesssprache integriert und ber explizite Bindungen zueinander in Beziehung gesetzt werden Eine Bindung dr ckt aus wie eine Kontextkompo nente in einer gew hlten Prozessmodellierungssprache syntaktisch referenziert wird Bei unserem Ansatz erfolgt die Bindung zwischen dem Schnittstellenmetamo dell und den in spezifischen Kontexten jeweils verwendeten Prozessmodellie rungssprache nicht ad hoc sondern wird durch ein Prozesssprachen Metametamodell im Folgenden PSM2 Modell genannt systematisch gesteuert Das PSM2 Modell das in Abschnitt 6 4 1 vorgestellt wird abstrahiert sowohl vom kontextbasierten Schnittstellenmetamodell als auch von den Basiskonzepten einer Prozessmodellie rungssprachen und definiert dadurch gleichzeitig die Mindestanforderungen f r die Integrationsf higkeit einer zu integrierenden Sprache Des
339. ie Aufgabe eines Mediators Abb 11 Verteilung des Prozess wissens bei unterschied lichen Formen der Werk zeuginteraktion Reise Prozess lt Prozess Message Server maschine E gt D modell a Expliziter Aufruf Client Server b Impliziter Aufruf Ereignis basiert c Prozessmediierter Aufruf p Kommandoaufruf he gt Ereignisnotifikation E gt D Ort des Prozesswissens Abb 11 illustriert schematisch die Verteilung des prozessrelevanten Interaktions wissens in den unterschiedlichen Ans tzen Es wird angenommen dass in einem Werkzeug W ein prozessrelevantes Ereignis E auftritt in dessen Folge in einem Werkzeug W2 der Dienst D ausgef hrt werden soll Ein konkretes Beispiel eines solchen Ablaufs w re die Speicherung eines Quelltextes Ereignis E in einem Editor Werkzeug W7 und die nachfolgende bersetzung Dienst D in einem Compiler Werkzeug W Im Falle einer traditionellen Client Server Architektur ruft das Werkzeug W durch ein explizites Kommando direkt den Dienst D beim Werkzeug W2 auf Abb 11 links Dann liegt das Prozesswissen dass bei Eintritt des Ereignisses der Dienst D aufzurufen ist bei Werkzeug W Im Fall eines rein ereignisbasierten Ansatzes l st Werkzeug W den Dienst D in Werkzeug W2 implizit aus indem es eine Notifikation dass E eingetreten ist aussendet Voraussetzung ist dann dass das Werkzeug W2 wei wie das Ereignis E zu behandeln ist Im diesem Fall ist der
340. ie Un terst tzungsvorgaben aus der Leitdom ne in der Durchf hrungsdom ne zumindest zur Kenntnis genommen und je nach Unterst tzungsmodus vgl Abschnitt 2 1 5 auch befolgt werden siehe Pfeil Prozessstenerung und berwachung in Abb 4 Q Da sich die Auswahl zwischen Handlungsalternativen und die Ergebnisse von Arbeitsschritten in der Durchftthrungsdomane i a nicht a priori festle gen lassen informiert die Durchf hrungsdom ne die Leitdom ne ber den eigentlichen Prozessfortschritt siehe Pfeil R ckmeldungen in Abb 4 Die Differenzierung zwischen der Modellierungsdom ne und der Leitdom ne reflektiert den konzeptuellen Unterschied zwischen statischem Prozessmodell und dynamischer Ansf hrung des Prozessmodells in Analogie zur Trennung von Pro grammen und Prozessen im Kontext von Betriebssystemen Die Trennung zwischen Leitdom ne und Durchf hrungsdom ne betont den Unterschied zwischen der Ausf hrung des Prozessmodells und der tats chlichen Prozessausf hrung Diese Unterscheidung ist fundamental denn durch die Aus f hrung des Prozessmodells wird lediglich ein rechnerinternes virtuelles Abbild des realen Prozesszustands gewartet Der Zustand der Prozessmodellausf hrung und der realen Prozessausf hrung m ssen nicht notwendigerweise bereinstim men In der Tat besteht ein grundlegendes Problem in PZEUen in der Synchronisa tion zwischen den Zust nden der Leit und Durchf hrungsdom ne da von der Leitdom
341. ie aus dem Speichern einer Quellcode Datei R ckschl sse auf den aktuellen Arbeitsprozesszustand z B Beendigung einer Fehlerkorrekturaufgabe gezogen werden k nnen zumal als Kontextinformatio nen f r die Ereignisbeschreibung nur der Identifier pid des ereignis ausl senden Betriebssystemprozesses der Name des Besitzers des Betriebssystemprozesses uid sowie der Name des Rechners host auf dem das Ereignis ausgel st wurde zur Verf gung stehen 3 3 5 3 Fazit Eine prozessintegrierte Umgebung kann nur solange sinnvolle Unterst tzungs leistungen liefern wie das Prozessmodell in der Modellierungsdom ne der beo bachtete Prozess in der Leitdom ne und der reale Prozess in der Durchf hrungs 3 3 Integrationsanforderungen in prozessintegrierten Umgebungen 99 domane miteinander im Einklang stehen Insbesondere sollten Beobachtungsin konsistenzen und unbewusste Modellabweichungen vermieden werden Der Informationsaustausch zwischen den Prozessdom nen muss daher durch ein explizites Synchronisationsprotokoll geregelt werden das zwischen reaktivem und proaktivem Unterst tzungsmodus unterscheidet R ckmeldungen bez glich automatisch ausgef hrter Aktionen ebenso wie Benutzerauswahlen ber cksichtigt und Prozessabweichungen oder den Abbruch der Prozessunterst tzung geeignet behandelt In den meisten existierenden prozesszentrierten Umgebungen nimmt die Leit dom ne R ckmeldungen direkt vom Benutzer ber spezielle Assistenzwerk
342. ie softwaretechnische Abstraktion dieses Entwurfsprinzips findet sich z B in Sulliver s Mediator Methode SuN092 SuKN96 Ein Mediator wird hier als ein Konstrukt verstanden das die Interaktionen zwischen Softwarekomponenten kapselt wodurch diese voneinander entkoppelt werden und die Semantik der Interaktionen vollst ndig durch den Mediator definiert wird Auch in der objekt orientierten Entwurfsmethodik begegnet uns die Grundidee des entkoppelten und mediierten Aufrufs immer wieder in Form unterschiedlicher Entwurfsmuster die eine lose Kopplung zwischen Softwarekomponenten mit dem Ziel der Variation be Mediation als Entwurfs prinzip 10 EBI Event Based software Integration 3 3 Integrationsanforderungen in prozessintegrierten Umgebungen 79 stimmter Aspekte erlauben GHJV95 CoSc95 Bus 96 So zielt das Mediator Muster auf die Variation der Komponenteninteraktion indem die Koordination des Zusammenspiels zwischen Komponenten in eine eigenst ndige Komponente verlagert wird In eine hnliche Richtung geht das Observer Muster das eine Varia tion des Ver nderungsverhaltens zwischen beobachteten und beobachtenden Komponenten gem dem in Smalltalk propagierten Model View Controller Paradigma Gold84 erm glicht Entwurfsmuster Mediator und Observer Im Kontext der Werkzeugintegration in Entwurfsumgebungen findet sich eine Eis L orest Erweiterung des echte Erweiterung des Message Broadcasting Ansatzes in Richtun
343. ieben die f r Ausf hrung eines Prozessmodells in der Leitdom ne erforderlich sind Anschlie end wird die Vor gehensweise bei der Integration eines Interpreters f r eine neue Sprache kurz erl utert Abschnitt 7 5 2 3 7 5 2 1 Sprachliche Klassen Im GARPEM Interpreterrahmenwerk bilden die grundlegenden Sprachkonzepte die in Abschnitt 6 4 1 innerhalb des Prozesssprachen Metametamodells PSM2 Modell formalisiert wurden die Basis f r die Wiederverwendung Dort wurden diejenigen Prozesssprachen Konzepte identifiziert die f r die komponentenba sierte Integration einer Sprache erforderlich sind im Wesentlichen Aktivit t Schnittstelle Datenbeh lter Die PSM2 Konzepte und deren Assoziationen werden direkt auf die Klassenstruktur der Sprachelemente Schicht abgebildet siehe Abb 65 vgl auch Abb 29 auf Seite 154 Auf diese Weise ist gew hrleistet dass die Sprachen die sich f r eine Integration grunds tzlich eignen auch durch das Interpreterrahmenwerk unterst tzt werden Zus tzlich wird das Konzept eines W chters und eines Typs vom Interpreterrahmenwerk angeboten Die grunds tzliche Klassenstruktur wurde bereits im Zusammenhang mit den Erl uterungen des PSM2 Modells in Abschnitt 6 4 1 begr ndet Anstelle einer detaillierten Beschreibung der Schnittstellen werden im Folgenden die Verantwort 7 5 GARPEM die generische Prozessmaschinenarchitektur 237 lichkeiten der einzelnen Klassen dargelegt Ausgehend von der Basiskla
344. ientierte Sprache O Telos Jeus92 MBJK90 ver wendet Der Grund f r die Zuhilfenahme einer weiteren konzeptuellen Modellie rungssprache neben UML liegt in der Tatsache dass wir ber die Ausdrucksm g lichkeiten von UML Klassendiagrammen hinaus die Semantik der konzeptuellen Modelle durch Angabe von Integrit tsbedingungen und Regeln weiter pr zisieren wollen Die von den UML Klassendiagrammen bereitgestellten Ausdrucksmittel im Wesentlichen Kardinalit tseinschr nkungen vordefinierte Abh ngigkeitskate gorien Stereotype informelle Notizen sind hierf r nicht m chtig genug bzw im Metamodell der UML nicht hinreichend formal fundiert Die UML stellt zwar mit der Object Constraint Language OMG 97d eine eigene Spezifikationssprache bereit in der jedoch im Gegensatz zu O Telos u a keine Regeln ber mehr als eine Instanziierungsebene formuliert werden k nnen Au erdem steht mit dem deduk tiven Objektmanager ConceptBase Jar 95 eine operationale O Telos Implemen tierung zur Verf gung die durch die automatische berpr fung von Basisaxiomen und benutzerdefinierten Integrit tsbedingungen sowie durch Deduktion intensio nalen Wissens aus Regeln und Anfragen die Erstellung konsistenter konzeptueller Modelle erheblich erleichtert Die Frame basierte Notation von O Telos wird im Folgenden als bekannt vorausgesetzt Aus Gr nden der bersichtlichkeit werden wir zur Darstellung der Modelle haupts chlich grafische UML Diagramme verwenden u
345. ieren eines Quelltextes oder das Erzeugen eines Modellbausteins in einem interaktiven Modellie rungswerkzeug z B einem Entity Relationship Editor ER Editor F r die Ausf hrung elementarer Dienste sind grunds tzlich die Werkzeuge der Durchf hrungsdom ne zust ndig Die definierende Schnittstellenbeschrei bung elementarer Dienste ist Bestandteil des Werkzeugmodells Umge kehrt werden elementare Dienste als atomare Prozessschritte im Prozess modell referenziert O Beratungsdienste Beratungsdienste entsprechen spezifischen Arbeits modi in denen der Zugriff auf die im aktuellen Prozesskontext relevanten bzw erlaubten Dienste und Produkte eingeschr nkt ist Beratungsdienste unterst tzen den Entwickler somit bei der Entscheidung unter den m gli 112 5 Integrierte Prozess und Werkzeugmodelle chen alternativen Vorgehensweisen Beratungsdienste werden logisch als Teil des Prozessmodells d h in der Modellierungsdom ne definiert Die Ausf hrung eines Beratungsdienstes hat jedoch Auswirkungen auf das Ver halten der Werkzeuge in der Durchf hrungsdom ne und liegt daher in der Verantwortung der Werkzeuge Nach Anforderungen durch die Prozess maschine m ssen die Werkzeuge die an der Benutzeroberfl che angebote nen Kommandos und die ausw hlbaren Produkte gem der Definition des Beratungsdienstes und der aktuell relevanten Produktinstanzen anpas sen siche Anforderung Prozesssensitive Benutzeroberfl che in Ab schnitt 3 3 6
346. iert den Nachrichtenaustausch zwischen Rollen Die einzelnen Rollen eines Prozessmodells repr sentiert durch Objektklassen bilden insgesamt 6 2 Interoperabilitat in prozessbasierten Systemen 141 ein Framework in dem der Kontrollfluss der Aktivit ten d h die Reihenfolge der Methodenaufrufe durch das rollen bergreifende Petrinetz spezifiziert wird 6 2 4 Diskussion und Schlussfolgerungen Der Literatur berblick in diesem Abschnitt hat drei wesentliche Eintwurfsalternativen f r die Interoperabilit t von Prozessmodellierungssprachen gezeigt Die berbr ckung der Heterogenit t verschiedensprachlich definierter Prozessfragmente kann entweder durch einen Transformationsansatz einen zentralisierten Prozesszustand oder einen Schnittstellenansatz gel st werden siehe Abb 25 a Interoperabilit t ber eine Zwischensprache b Interoperabilit t durch Schnittstellen und Delegation Abb 25 Interoperabilit tsans tze Aggregiertes im Ver gleich Prozessmodell Schnittstelle C_ i Zwischen Delegation sprache i i Abbildung A Abbildung B i i l i l PMS A PMS B PMS A PMS B Interpreter i Interpreter l i u i te i Fragment A Fragment B Fragment A c Interoperabilit t ber zentralisierten Prozesszustand PMS A Interpreter globaler Prozesszustand Fragment A Zustandsserver 8 PMS B Interpreter Fragment B PMS Prozessmodellierungssprache Bei einem Transformationsansatz wird die Integration der P
347. ierten Umgebungen 55 331 berblick ae raaa E EEN EE 55 3 3 1 1 Dateminte gration cc ceccccccesecesecesecsseceeecseeceeeeeeeeesseeeseeeseeeseectaeeaees 56 3 3 1 2 Kontrollinte gration ccciccsccciscsesteeecvecetvecvcus cave TE ERE 56 3 3 1 3 Prdsentationsinte gration ccccesccesscesscesseeeeceeeeeeeeeeseeeseeeseeeeeeaeeaees 57 3 3 2 Datenintegration zwischen den Prozessdom nen neneneeen 58 vii Vili Inhaltsverzeichnis 3 32 1 Motivations csi ve asien is iss 58 3 3 2 2 Bewertung existierender Ans tze unsensennseeneesneesnnennnnnnne nenne 60 PERS RE 171 UE ae ROHDE ROBERT NER Reo en CT NC E ee Toe Met SER TERN 69 3 3 3 Prozessorientierte Mediation der Werkzeuginteraktionen eee 69 3 33 41 MOUVatOn 2 ee sncaetaad anton ate deastdayetsa mseuasseaetteab saath 69 3 3 3 2 Bewertung existierender Ans tze ucnsensenneeneesennennnnnnennne ne 72 3333s RAM i RER 84 3 3 4 Beschreibung von Werkzeugdiensten cccccecsseesseeteceteceseeeeeeeeeeesneennes 84 33441 Motivation i erreke e E e a e E R S 84 3 3 4 2 Bewertung existierender Ans tze 0 0 ccecscecsseeseceteceneceteeeeeeeseeeeneeeaes 86 3343 zensiert 94 3 3 5 Synchronisation zwischen den Prozessdom nen nenen 94 SESSA Motivations nenn ai Isiiunnnnn ee ein 94 3 3 5 2 Bewertung existierender Ans tze ucsensennseenneesneesnneennnnnnnnnnne ne 97 3303 Fazer en innert E EE 98 3 3 6 Prozesssensitive
348. ifiziert Aus dem Vergleich haben wir gefolgert dass prozesszentrierte Umgebungen grunds tzlich die gerade in kreativen Entwurfsdom nen n tige Flexibilit t hinsichtlich der Definition neuer Prozesse oder der Anpassung existierender Prozesse bieten aber nicht die n tige Integrationstiefe mit der eigentlichen Werkzeugumgebung aufwei sen O Literatur berblick zur Werkzengintegration In einem umfassenden Literatur berblick haben wir existierende Ans tze zur L sung des Integrations problem einer kritischen Bewertung unterzogen Zur Strukturierung der Literaturanalyse wurden zun chst insgesamt sechs Kernanforderungen heraus gearbeitet die den bergang von einer prozesszentrierten Umgebungen hin zu prozessintegrierten Umgebungen kennzeichnen 1 Datenintegration zwi schen den Prozessdom nen 2 Prozessorientierte Mediation von Werk zeuginteraktionen 3 Konzeptuelle Beschreibung von Werkzeugdiensten 4 Synchronisation zwischen den Prozessdom nen 5 prozesssensitive Benutzeroberfl chen und 6 werkzeugunterst tzter Aufruf von Prozess fragmenten Die Betrachtung existierender prozesszentrierter Umgebungen sowie weiterer Ans tze aus den Bereichen Datenintegration Kommunika tionsinfrastrukturen komponentenbasierte Softwareentwicklung Werk zeugspezifikation Prozessmodellierung Benutzeroberfl chen und Soft wareergonomie ergab dass zu Teilaspekten bereits mitunter ausgereifte L sungsans tze vorliegen Uns ist jedoch kein
349. iforme Systeme mit einer Mischung aus statischen und dynamischen Hilfeleistungen Balz96 Wand93 Shne98 Tab 4 ordnet die unterschiedlichen Arten von Hilfesystemen in den Klassifi kationsrahmen f r Prozessunterst tzungssysteme aus Abschnitt 2 1 ein Zur Ver einfachung der Klassifikation von Hilfesystemen haben wir die Unterscheidung zwischen statischen und dynamischen Systemen einerseits sowie uniformen und individuellen Systemen andererseits aufgehoben Diese Sichtweise l sst sich da durch rechtfertigen dass man die Ber cksichtigung von Benutzerprofilen auch als Teil des aktuellen Benutzungskontexts des Hilfesystems betrachten kann In die sem Sinne ist uniforme Hilfe ein Spezialfall statischer Hilfe w hrend individuelle Hilfesysteme immer auch dynamische Hilfesysteme darstellen O Unterst tzte Projektebene Die von einem Hilfesystem bereitgestellte Prozessunterst tzung bezieht sich in erster Linie auf den Umgang mit Softwarewerkzeugen und Anwendungsprogrammen indem z B Informa tionen ber die im aktuellen Kontext w hlbaren Objekte und Funktionen Erkl rungen und Hinweise zu Eingabeaufforderungen Erl uterungen zu Ergebnissen von Funktionsausf hrungen und weiterf hrende Erkl rungen zu Fehlermeldungen geliefert werden Diese Art werkzeugbezogenen Pro zesswissens adressiert in der Regel feingranulare eng umrissene Prozess schritte aus Sicht des technischen Entwicklers Daher kommt die dutch Hilfesysteme geleistete Prozessun
350. im 114 5 Integrierte Prozess und Werkzeugmodelle Prozessmodell erfasster Prozessfragmente ergeben Daher muss das Pro zessmetamodell tiber geeignete Kompositionsmechanismen ftir die Kom position komplexerer Prozessfragmente aus einfacheren verf gen Dabei sollten beratende anleitende und automatisierende Prozessfragmente frei kombiniert werden k nnen Wegen der Konzentration auf arbeitsplatzorientierte Entwurfsprozesse individu eller Entwickler spielen eine Reihe von Modellierungsaspekten die von auf das administrative Projektmanagement ausgerichteten Prozessmodellierungsans tzen betont werden hier nur eine untergeordnete Rolle Dazu geh ren Modellierungs konzepte zur Organisationsmodellierung Verantwortlichkeiten Rollen etc zur Entwicklerkoordination z B Freigabe und Weiterleitung von Dokumenten Auf tragserteilung etc und zur Ressourcenverwaltung z B Kostenmodelle Milesto nes Deadlines etc 5 3 2 PRIME PM das NATURE Prozessmetamodell Zut Modellierung von Prozessfragmenten definieren wir in dieser Arbeit keine neue Prozessmodellierungssprache sondern greifen auf ein Prozessmetamodell zur ck das im Rahmen des ESPRIT Projekts NATURE NATU96 JRSD99 entwickelt wurde Gro 97 RoSM95 Pohl96 RoPB99 Es stellt die oben gefor derten Konzepte zur einheitlichen Modellierung von elementaren Diensten Bera tungsdiensten und Anleitungsdiensten bereit PoWe97 Poh 99 Das NATURE Prozessmodell betont die stwative Natu
351. in Abh ngigkeit vom Zustand der Objektbank das Schalten weiterer Regeln durch Vorw rts und R ckw rtsverkettung ausl sen Mar vel erm glichst dar ber hinaus eine strukturelle Ansicht der manipulierten Artefakte allerdings nur auf der grobgranularen Dokumentebene Einem hnlichen Interaktionsparadigma folgt auch die PZEU PEACE ArOg94 0 Automatischer Werkzeugaufruf Neben den genannten dedizierten Ent wickler Frontends Task Manager Arbeitskontexte visualisierte Regel menge etc ist in den meisten PZEUen die Prozessmaschine lose mit ei gentlichen Entwurfswerkzeugen der Durchf hrungsdom ne integriert Al lerdings beschr nkt sich die Integration in den meisten F llen auf das Star ten von Werkzeugen wobei gegebenenfalls grobgranulare Dokumente als Aufrufparameter bergeben werden W hrend diese Art der Integration zwischen Leit und Durchf hrungsdom ne bei automatischen Abl ufen in Batch artigen Werkzeugen Compiler Linker durchaus angemessen und ausreichend ist f hrt dies bei komplexen interaktiven Werkzeugen zu 2 2 Bewertung existierender Ansatze 39 schwerwiegenden Problemen die in Kapitel 3 noch genauer zu beleuchten sind Tab 6 gibt einen berblick ber die Klassifizierung der Prozessunterst tzung in PZEUen Wir haben die Bewertung unterteilt da man wie im vorangegangenen gesehen die Assistenzfunktion von PZEUen aus unterschiedlichen Blickwinkeln betrachten kann aus Sicht des Projektmanagements bei
352. in der GARPIT Architektur der generische Interpreterkern der von diesen Teilsystemen gebildet wird sauber von den werkzeugspezifischen Architekturbausteinen separiert wurde Abb 63 zeigt die resultierende generische Architektur des Prozessintegrations Wrappers Man erkennt dass wesentliche Teile des GARPIT Frameworks bernommen Anbindung des Fremd werden konnten Neben dem StateManager MessageInterface und dem Context Werkzeugs ber Action Manager sind dies die Teilsysteme ActionTable IntentionTable und ObjectTable UIEOLRORPIEE die dem ContextManager eine abstrakte Schnittstelle zur Aktivierung von Aktionen und zur Interaktion mit der Benutzeroberfl che zur Verf gung stellen Als we sentliche neue Komponenten sind die Teilsysteme ActionAdapter und UIAdapter hinzugekommen die die korrespondierenden Teilsysteme T Actions und T GUI der originalen GARPIT Architektur ersetzen 230 Abb 63 Generische Architektur des Prozessintegrations Wrappers 7 Das PRIME Rahmenwerk Prozessintegrations Wrapper h Prozess maschine Message StateManager Interface DB Interface Action Table Action Adapter ContextManager Context Context Executor Matcher Object Intention Table Table UI Adapter Prozess Repository APIs A1 Dienstaufruf A2 Ergebnis R ckmeldung Operationen A3 Kommandoerweiterung Objektmodell A4 Produktdarstellung Exis
353. in der Leitdom ne den tats chlichen Prozess zustand in der Durchf hrungsdom ne m glichst exakt widerspiegeln Hierzu sind oberhalb der durch einen Kontrollintegrationsmechanismus gegebenen F higkeit zur Interaktion geeignete Synchronisationsprotokolle zwischen den Dom nen zu defi nieren Abschnitt 3 3 5 3 3 1 3 Prasentationsintegration Pr sentationsintegration befasst sich mit software ergonomischen Fragestellungen bei der Verwendung unterschiedlicher Werkzeuge in der Arbeitsumgebung eines Entwicklers Wand93 Aus den Arbeitswissenschaften stammen Bewertungs und Gestaltungskriterien wie Kompetenzf rderlichkeit Handlungsflexibilitat und Aufgabenangemessenheit VDI 90 Diese implizieren eine Vereinheitlichung des Erscheinungsbilds der Werkzeuge einheitliches Look amp Feel und ein gemein sames Interaktionsparadigma der zu integrierenden Werkzeuge Gerade zum letztgenannten Punkt ergeben sich aus der Prozessorientierung zwei wesentliche Aspekte die den Bereich der Pr sentationsintegration ber hren die prozesssensi 58 3 Integrationsansatze tive Anpassung der Interaktionsm glichkeiten des Benutzer und der werkzeugun terst tzte Aufruf von Prozessfragmenten Anforderung 5 Prozesssensitive Anpassung der Interaktionsm glichkeiten Die Prozessdefinitionen und der aktuelle Prozesszustand definieren die zu einem bestimmten Zeitpunkt zu bearbeitenden Objekte und die zul ssigen Aktionen auf den Objekten Diese sollten s
354. in der Rolle superEntity erzeugt Falls die Menge der aktuell aktiven Produkt instanzen aus den ER Entity Objekten book und publication besteht g be es zwei m gliche Bindungen s subEntity book superEntity publication und s2 subEntity publication superEntity book wovon offensichtlich nur s semantisch sinnvoll ist Eine prinzipielle M glichkeit zur Aufl sung solcher Mehrdeutigkeiten besteht darin diese explizit vom Benutzer vornehmen zu lassen etwa ber einen spezielles Dialogfenster Da sich dies jedoch als sehr m hselig erwies erfolgt in der Realisierung des Situations Matchers eine automatische Zuordnung nach folgendem Schema Jede Produktinstanz tr gt einen Zeitstempel der den Zeitpunkt ihrer Aktivierung angibt die Aktivierung mehrerer Produktin stanzen erfolgt durch akkumulatives Selektieren Entsprechend der Reihenfolge der Situationsteile in einer Situationsspezifikation werden dann die Produktinstan zen nach ihrem Alter gebunden Wenn also im obigen Beispiel zuerst book und dann publication selektiert worden w re erg be sich die Situationsinstanz s7 Zu beachten ist dass sich der Benutzer ber die Reihenfolge der Situationsteile in einer Situationsspezifikation im Klaren sein muss damit er die Produktinstanzen in der richtigen Reihenfolge selektiert In der Praxis erwies sich dies jedoch nur selten als Problem da in den wenigen F llen in denen Mehrdeutigkeiten auftr
355. ine korrespondie rende Klassenfamilie CsttProcessEngineStateDriver mit CsttProcessEngi neState und CsttProcessEngineTransition Subklassen die ebenfalls von den hier skizzierten Basisklassen abgeleitet ist CevtToolMessageEventHandler CevtCommandSelectionhandler CevtObjectSelectionHandler Abb 51 Detailstruktur des Teil systems StateManager 7 V CsttState Driver CevtEventHandler handleEvent CevtEventQueue CevtEvent enqueue ba dequeue A ae CsttTransition doEntry checkEvent doActivity N checkCond doExit loAction i iti CevtToolEvent CsttToolState CsttToolTransition A N CsttSCActive CsttCCActive CsttECActive CsttToolTransition_1 CsttToolTransition_n CevtMessageEvent CevtObjectSelectionEvent CsttReqCCActive CsttECActiveOnExtReq CsstReqECActive CsttAbortRequested CsttWaitingForLockReq CsttWaitingForGuidReq Transitionsklassen siehe Abschnitt 7 2 Diverse konkrete CevtCommandSelectionEvent Diverse Subklassen f r Nachrichten ereignisse siehe Abschnitt 7 2 CsttCCActiveOnExtReq Die Cstt
356. ines GARPIT basierten Werkzeugs am Beispiel des ER Editors Der ER Editor ist ein einfaches Werkzeug zur Entity Relationship Modellierung der f r die Require ments Traceability Umgebung PRO ART Pohl96 entwickelt wurde Die Entwicklung eines Werkzeugs gliedert sich in drei Phasen Zun chst wird das Werkzeug gem der Struktur des Werkzeugmetamodells modelliert d h sein Produktmodell die Darstellungsarten der Produkttypen und seine Aktionen wer den festgelegt In der zweiten Phase der Implementierungsphase werden das Produktmodell die Benutzeroberfl che und die Aktionen durch Spezialisierung der Framework Klassen realisiert In der dritten Phase wird das Werkzeug durch die Definition von Entscheidungs und Plankontexten in die zu unterst tzenden Prozesse eingebunden 7 3 4 1 Phase 1 Werkzeugmodellierung Produktmodellierung Den Ausgangspunkt f r die Realisierung eines GARPIT basierten Werkzeugs bildet die Definition des zugrunde liegenden Produktmodells Hier unterscheiden wir zwischen einem Detailmodell in dem alle Klassen mit ihren Attributen Assozia tionen und Methoden vollst ndig spezifiziert sind und einem vergr berten Modell das nur die Klassen und Spezialisierungsbeziehungen des Detailmodells umfasst Abb 61 zeigt das Detailmodell des ER Editors Der strukturelle Anteil des Detail modells wird in ein relationales Datenbankschema bertragen und bildet die Grundlage f r die Persistenz des im Teilsystem ER Model imp
357. inistrierten Gesamtprozess O Stufe 7 Der Aufruf von APIs inklusive bertragung von Prozessmodel len und Arbeitseinheiten Recovery etc wird durch ein standardisiertes Pro tokoll geregelt O Stufe 8 Die Komponenten der zu integrierenden Workflowmanagement systeme weisen eine einheitliche Benutzungsschnittstelle auf Bis einschlie lich Stufe 5 Zugriff auf die volle Funktionalit t ber offene Schnitt stelle orientiert sich die Interoperabilitat cher an den Funktionsbereichen eines prozessbasierten Systems Leitdom ne und weniger an den Konzepten der Pro zessmodellierung selbst Modellierungsdom ne Neben der Schnittstelle zwischen den Prozessmaschinen unterschiedlicher Workflowmanagementsysteme unter scheidet das WfMC Referenzmodell hierzu weitere Teilsysteme eines prozessba sierten Systems Prozessmodellierungswerkzeuge Administrationswerkzeuge und Klientenapplikationen siehe Abb 23 Das Referenzmodell legt Schnittstellen zwischen den einzelnen Teilsystemen fest und definiert daf r jeweils einen Stan dard Die seit der Version 2 zusammengelegten Schnittstellen 2 und 3 f r die Interaktion mit externen Applikation haben wir bereits in Abschnitt 3 3 4 2 Seite 91ff kennen gelernt Abb 23 Das Workflow Referenz modell der WfMC Holl95 Process Definition Tools Workflow Engines Workflow Client Invoked Administration and Monitoring Tools Other Workflow Services Application Application
358. ion Erweiterbarkeit um Baustein Flie bild zB neue Bausteintypen MetaDB DB Flie bildverfeinerung Navigation Flie bild ASPEN Plus Daten Integrator Prozessspuren visualisierung 8 3 Beispielsitzung Wir beschreiben nun eine kurze Beispielsitzung um die Funktionalit t der PRI ME IMPROVE Umgebung und die Vorteile der Prozessintegration aus Be nutzersicht zu demonstrieren Das betrachtete Szenario besteht aus zwei Teilen Der erste Teil behandelt die Definition eines neuen M Prozessfragments und dessen Integration in den Flie bildeditor ber das Umgebungsmodell Der zweite Teil illustriert die methodische Anleitung des Benutzers w hrend der Ausf hrung des vorher definierten M Prozessfragments 8 3 1 Definition eines Prozessfragments 8 3 1 1 Ziel der Prozessunterst tzung Zu den Basisfunktionalit ten des Flie bildeditors geh rt das Anlegen einer Verfei nerungsgruppe f r einen VT Prozessbaustein Diese Funktionalit t wird durch den Ausf hrungskontext RefineProcessDevice realisiert dessen Situation g ltig ist sobald eine Instanz der Klasse VT ProcessDevice vom Benutzer ausgew hlt wur de Die Funktionalit t dieses Ausf hrungskontexts besteht lediglich darin eine neue leere Verfeinerungsgruppe f r den ausgew hlten VT Prozessbaustein zu kreieren und in der grafischen Ansicht auf die Ebene der neu angelegten Gruppe zu navigieren Eine dar ber hinaus gehende Ablaufunterst tzung liefert de
359. ion einer expliziten Ausgangsschnittstelle erfordert Wir haben daher das NATURE Prozessmodell zu einem Metamodell zur Schnitt stellenbeschreibung von Kontextkomponenten umformuliert und erweitert siehe Abb 28 Das zentrale Element des Schnittstellenmetamodells das vollst ndig kompa tibel zum NATURE Prozessmodell ist ist die Prozesskomponente Eine Prozess komponente verf gt ber eine Eingangs und Ausgangsschnittstelle was durch 1 Diese Bedingung verallgemeinert die Konsistenzbedingung AK2 die wir bereits in Abschnitt 5 5 2 1 f r den Spezialfall von Ausf hrungskontexten formuliert hatten 148 6 Interoperabilitat von Prozesssprachen entsprechende Assoziationen zur Klasse Schnittstelle dargestellt ist Eine Schnittstelle selbst aggregiert einen oder mehrere Produktteile in jeweils spezifi schen Rollen Die Datenbeh lter sind durch ihren Typ n her beschrieben Die Klasse Prozesskomponente generalisiert die Klassen Kontextkomponente Situati onskomponente und Verhaltenskomponente und vererbt diesen Klassen somit die F higkeit eine Eingangs und Ausgangsschnittstelle zu besitzen Eine Verhaltens komponente unterteilt sich entsprechend dem NATURE Prozessmodell weiter in die Klassen Plankontext_Verhaltenskomponente Ausf hrungskon text_Verhaltenskomponente und Entscheidungskontext_Verhaltenskomponente Situations und Verhaltenskomponenten verf gen ber spezifische Implementie rungsinformationen die jedoch auf der Ebene der
360. ions Appications Die WfMC unterscheidet zwischen normalen Applikationen die nicht eigens f r den Einsatz innerhalb eines WFMS konzipiert wurden und so genannten Workflow enabled Applications die von Workflow spezifischen Funktionalit ten 13 MFC Microsoft Foundation Classes 92 3 Integrationsans tze Gebrauch machen k nnen Insbesondere f r die letztere Klasse von Applikationen sieht die WAPI Interface 2 amp 3 Specification eine Schnittstelle zu Workflow System vor ber die beispielsweise Informationen ber die aktuell laufenden Aktivit tsinstanzen erfragt werden k nnen W hrend diese Schnittstelle recht reichhaltige Funktionen anbietet ist die Schnittstellenspezifikation f r die Tool Agents nur u erst rudiment r ausgearbeitet und auf die grobgranulare Blackbox Integration von Applikationen ausgerichtet Die dort spezifizierten Funktionen betreffen lediglich das Starten und Beenden einer angegebenen Applikation und das Erfragen aktueller Statusinformationen des Tool Agents Eine inkrementelle Aktivierung individueller Dienste der aufgerufenen Applikation zur Laufzeit ist nicht vorgesehen Die bislang betrachteten Ans tze unterst tzen nur die grobgranulare Blackbox Integration und repr sentieren Werkzeuge wenn berhaupt lediglich als mono lithische Operatoren die gestartet und ggf beendet werden k nnen Wie bereits in Abschnitt 3 3 3 angesprochen wurde macht eine zunehmende Zahl prozesszen trierter Umge
361. isch nder und Ebene integriert erweiterbar Automatisierung 2 3 Fazit 45 3 1 Perspektiven der Werkzeugintegration 47 Kapitel Integrationsans tze tion von Werkzeugen die auf einer st rkeren Ber cksichtigung von Werkzeu gen in prozesszentrierten Umgebungen beruht zu einer Unterst tzung f hrt die direkt in der Arbeitsumgebung des technischen Entwicklers sichtbar ist kon textsensitiv in den Arbeitsprozess eingreift das gesamte Spektrum m glicher Unterst tzungsmodi abdeckt und dar ber hinaus einfach anpassbat ist m vorangegangenen Kapitel haben wir argumentiert dass eine Prozessintegra Ziel dieses Kapitels ist es die Anforderungen an die daf r erforderliche Integ ration zwischen der Modellierungs und Leitdom ne einerseits und der Durchf h rungsdom ne andererseits genauer herauszuarbeiten und mit existierenden Integ rationsstrategien und mechanismen aus der Literatur in Beziehung zu setzen Diese Anforderungen kennzeichnen den bergang von prozesszentrierten Umge bungen denen lediglich die explizite Modellierung von Prozessen zugrunde liegt hin zu prozessintegrierten Umgebungen in denen auch die Werkzeuge der Durchf h rungsdom ne eine prozessmodellkonforme Arbeitsweise aktiv unterst tzen Der Rest des Kapitels ist wie folgt gegliedert In Abschnitt 3 1 geben wir zu n chst einen kurzen berblick ber verschiedene Klassifikationsmodelle die in der Literatur zur konzeptionellen Strukturierung des
362. ische und dynamische Beziehungen zwischen den Sprachen definiert etwa in Form von Sprach abbildungen z B Balancierungs und Transformationsregeln zwischen Sprachen f r Anforderungs und Entwurfsspezifikationen Your89 Jann92 Kron92 oder Prozessmodellen f r die integrierte konsistente Verwendung der Sprachen z B Arbeitsabl ufe f r das Nachziehen einer nderung eines ER Schema in korrespondieren DFD Diagrammen Poh 99 Der IRD Definition Level korrespondiert mit der Metaklassen ebene Q Der IRD Definition Schema Level definiert ein Metameta Modell mit dessen Hilfe die Objekte des IRD Definition Level beschrieben und mit einander in Beziehung gesetzt werden k nnen Wie in Abb 9 angedeutet sind die vier Ebenen in miteinander verzahnten Ebe nenpaaren angeordnet Intuitiv kann ein Ebenenpaar als eine Datenbank verstan den werden wobei die obere Ebene dem Schema und die untere Ebene dem Datenbank Zustand entspricht Innerhalb der IRDS Architektur werden die Ebe nenpaare so miteinander verschr nkt dass die Schemata der unteren Ebenenpaare durch den Datenbankzustand eines Ebenenpaars auf der n chst h heren Ebene kootdiniert werden Auf diese Weise entsteht eine verteilte Datenbank in der Q Application Level Pairs traditionellen Anwendungsdatenbanken entspre chen die aus einem Anwendungsschema und einem Datenbankzustand bestehen QO IRD Level Pairs mit Data Dictionaries oder Meta Datenbanken korres pondieren Zur Laufz
363. ischen den Werk zeugen in der Durchf hrungsdom ne und der Prozessmaschine in der Leitdom ne wird durch ein umfassendes Interaktionsprotokoll geregelt Der Unterschied zwischen einer prozesszentrierten Umgebung wie z B SPADE BaDF96 oder Dynamite HJKW96 und einer prozessintegrierten Umgebung nach dem PRIME Ansatz l sst sich gut anhand der in Abb 18 dargestellten Erweiterun gen des Dom nenmodells von Dowson charakterisieren vergleiche auch Abb 4 auf Seite 35 In der Modellierungsdom ne ist neben dem Prozessmodell auch das damit integrierte Werkzeugmodell angesiedelt Die Interpretation des Werkzeug modells versetzt die Werkzeuge in die Lage ihr Verhalten dynamisch an den aktu ellen Prozesszustand anzupassen und die Ausf hrung von Prozessfragmenten von der Leitdom ne anzufordern Insgesamt kommt den Werkzeugen in der Durch Abb 18 f hrungsdom ne somit eine wesentlich aktivere Rolle bei der Prozessunterst t Erweiterung der Dom PR zung zu die sich auch in erweiterten Interaktionen zwischen der Leit und Durch nenmodells von Dowson N 3 i in einer prozessinteg f hrungsdom ne widerspiegelt rierten Umgebung Modellierungsdom ne Prozessdefinitionen Durchf hrungsdom ne Werkzeugdefinitionen Umgebungsmodell Generische Werkzeug Architektur O Werkzeug modell Prozess modell Kapitel 6 Interoperabilit t von Prozesssprachen Flexibles Kont
364. isiert so dass der Interpretationsvorgang gestartet werden kann Zun chst werden in der ersten Phase im Zustand DeducingAcitvities die Aktivi t ten des Fragmentes bestimmt die in einem Schritt auszuf hren sind Im Falle von rein sequenziellen Sprachen wird maximal eine Aktivit t in einem Interpretati onsschritt deduziert Sprachen die Parallelit t zulassen k nnen in einem Schritt ggf mehrere Aktivit ten bestimmen die dann parallel ausgef hrt werden Welche Aktivit ten deduziert werden h ngt dabei vom Kontrollfluss im Fragment ab Da die Kontrollmodelle der Prozessmodellierungssprachen divergieren wird dieser Zustand je nach Sprache unterschiedlich realisiert m In einer zweiten Phase werden im Zustand ExecutingActivities die zuvor bestimmten Aktivit ten ausgef hrt Wie bereits erl utert repr sentieren die Akti vitaten AK EK oder PK Kontextkomponenten f r deren Ausf hrung eine entsprechende Process Instanz erforderlich ist F r jede deduzierte Aktivit t wird in diesem Zustand ein eigener Prozess abgespalten der die Ausf hrung des ent sprechenden PRIME Kontextes vollzieht Die abgespaltenen Prozesse sind dabei alle Subprozesse des aufrufenden PK Prozesses und werden von diesem gesteuert 7 5 GARPEM die generische Prozessmaschinenarchitektur 243 Die Zustandsanderungen der Subprozesse werden stets an den aufrufenden PK Prozess weitergeleitet so dass dieser insbesondere ber deren Termination infor
365. isierten dass sie gerade von einem Prozessfragment durch einen f r sie unbekannten Ablauf ge f hrt worden waren In manchen F llen f hlten sich die Benutzer nach der Akti vierung eines Plankontextes allerdings auch etwas orientierungslos Hier erwies es sich als nachteilig dass der Benutzer w hrend der Ausf hrung eines Prozessfrag ments in seinen Werkzeugen jeweils nur den berblick ber die als n chstes m g lichen Schritte erh lt Bei komplexeren Prozessfragmenten kann dies dazu f hren dass der Benutzer das Gesamtziel des Prozessfragments aus den Augen verliert und die Notwendigkeit einzelner Schritte bzw deren Abfolge nicht mehr nach vollziehen kann Die M glichkeit sich im Plankontexteditor und im Prozessspu renvisualisierer ber den aktuellen Ausf hrungszustand zu informieren wurde nur 274 9 Schlussbetrachtungen von wenigen Benutzern genutzt die sich vorher mit den entsprechenden Notatio nen vertraut gemacht hatten Nat rlich wurde auch die Frage aufgeworfen ob eine in die Werkzeuge integ rierte Prozessunterst tzung generell f r eine bessere Qualit t des Entwurfs sorgt oder umgekehrt die einem Entwurfsprozess inh rente Kreativit t behindert Hier wurde als positiv hervorgehoben dass PRIME gar nicht erst den Versuch unter nimmt kreative Entwurfsprozesse durchgehend und pr skriptiv anleiten zu wol len sondern auf eine situative Unterst tzung wohlverstandener Teilabl ufe ausge legt ist Die Anleitung dur
366. istenz regeln durchzusetzen Aus diesem Grund wurde das Visio Objektmodell um ein Modell erweitert das sich an der inhaltlichen Verfahrens und Anlagenstruktur orientiert und einzelne Flie bilder in Visio Terminologie Zeichenbl tter als Sichten auf das inhaltliche Modell betrachtet Grundlage dieses Modells ist ein 8 2 PRIME IMPROVE 255 allgemeines Dom nenmodell f r den verfahrenstechnischen Entwurf BaMa93 das in Zusammenarbeit mit dem Lehrstuhl f r Prozesstechnik an der RWTH Aachen berarbeitet wurde isRefinedBy Abb 72 refines 0 1 0 1 refinedBy Datenmodell des Flie bildeditors VT ProcessGrou 0 1 0 n inRefinement inGroup 0 n 0 n Documentview 41 n Documentview 0 n Project Sheet VT ProcessElement ghgwsElement 0 1 0 gource 1 n Stream a 0 1 Connector 5 0 gonnectedTo 0 18ink described_by lt lt metadata gt gt VT ProcessTypeDescription name String shape Shape attribute AttributeDescription refinement_options ChoiceContaxt VT ProcessEquipment UnitOperation VT ProcessStep VT Process N A Konkrete Subklassen implizit mithilfe von VT ProcessTypeDescription modelliert Abb 72 zeigt das Flie bild Datenmodell Ein Verfahrens bzw Anlagenkonzept Prozesselemente ist durch eine Menge von miteinander in Beziehung stehenden VT Prozessele menten VI ProcessEl
367. it Marken Schalten von Tran sitionen O Statechart Editor Aktiver Zustand Schalten von Transitionen O Sprachspezifische Konsistenz berpr fungen Werkzeugmodell Editor Mithilfe des Werkzeugmodell Editors lassen sich Werkzeugkategorien gem dem in Kapitel 5 dargestellten Werkzeugmodell beschreiben Zu der Definition einer Werkzeugkategorie geh ren die Angabe der von ihr unterst tzten O Aktionen und deren Signaturen Kommandoelemente Men s Toolbar Icons Short Keys O Darstellungsarten f r Produkte Abb 41 zeigt die beispielhaft die Modellierung einer Aktion mithilfe des Werk zeugmodell Editors Ej PRIME Tool Modeler Gla Ez Document Edit Create Tools Preferences Help Action External name ACT_ER_createRelationship Output parameter OneRelationshipS elected Tool ER Editor ba Editing an action type Pian Context Choice Context Executable Context CO 1 1 Umgebungsmodell Editor Mithilfe des Umgebungsmodell Editors siehe Abb 42 lassen sich die Querbe z ge zwischen Kontextkomponenten und Werkzeugkategorien festlegen Gem dem in Abschnitt 5 5 dargestellten Umgebungsmodell umfassen die Funktionalit ten des Umgebungsmodell Editors die Q Zuordnung von Ausf hrungskontexten zu Werkzeugkategorien Q Zuordnung von Entscheidungskontexten zu Werkzeugkategorien dabei Zuordnung von Kommandoelementen zu den Alternativen eines Ent scheidungskontexts O
368. itektur vgl Klient Implementation OMG 97 Grif98 Server ORB outinen Skeleton Adapter DSI E ORB Kern Als typischen Vertreter des Broker Ansatzes betrachten wir in Abb 12 die Common Object Request Broker Architecture CORBA deren Spezifikation das Ergebnis der Bem hungen der OMG ist OMG 97 Sieg96 Kram97 Konkurrierende Ans tze wie Microsofts DCOM EdEd98 Tho 97 oder die Voyager Technologie der Firma ObjectSpace folgen in den wesentlichen Elemente ihrer Architektur einem vergleichbarem Aufbau auch wenn bei genauerem Hinsehen hinsichtlich des zugrunde liegenden Objektmodells und der zur Verf gung stehenden Zusatz dienste doch erhebliche Unterschiede existieren f r einen Vergleich zwischen DCOM und CORBA siehe z B OrHE96 Grif98 Chu 98 In einer CORBA basierten Umgebung kommunizieren Werkzeuge tiber den so genannten Object Request Broker ORB miteinander Dazu verwendet das Klient Objekt d h das aufrufende Werkzeug die bei der bersetzung aus einer Schnitt stellenspezifikation erzeugten Coder mpfe szubs Hier findet unter anderem die 74 3 Integrationsansatze Serialisierung der Parameter in einen Uber das Netzwerk verschickbaren Byte strom das so genannte Marshalling statt Der ORB ist f r die transparente Weiter leitung von Operationsaufrufen innerhalb einer heterogenen verteilten System umgebung zust ndig Seine Aufgaben umfassen unter anderen die Generierung und Auswertung v
369. iteraturverzeichnis NATU96 NATURE Team Defining Visions in Context Models Processes and Tools for Requirements Engineering Information Systems 21 6 S 515 547 1996 NaWe99 Nagl M und Westfechtel B Hrsg Integration von Entwicklungssystemen in Ingenieuran wendungen Substantielle Verbesserung der Entwicklungsprozesse Springer 1999 NiDa95 Nierstrasz O und Dami L Component Oriented Software Technology In Nierstrasz O und Tsichritzis D Hrsg Object Oriented Software Composition Prentice Hall London 1995 S 3 28 NiJa99 Nissen H W und Jarke M Repository Support for Multi Perspective Requirements Engineer ing Information Systems Special Issue on Meta Modeling an Method Engineering 24 2 S 131 158 1999 Nils89 Nilsson E G CASE Tools and Software factories In Steinholtz B Solvberg A und Bergmann L Hrsg Proc CASE 89 First Nordic Conference on Advanced Sys tems Engineering Stockholm Sweden May 1989 S 42 60 NIST93 NIST A Reference Model for Project Support Environment Standards Tech Report SEI amp NIST CMU SEI TR 93 23 NIST Report SP 500 213 Nov 1993 Ober96 Oberweis A Modellierung und Ausf hrung von Workflows mit Petri Netzen Teubner Verlag Stuttgart 1996 Odel96 Odell J A Primer to Method Engineering In Brinkkemper S Lyytinen K und Welke R Hrsg Method Engineering Principles of Method Construction IFIP Chap man amp
370. iveX oder von CORBA nach DCOM die zu verkn pfenden Komponenten von Aufrufanpassungen und 1t ADL Architecture Description Language 3 3 Integrationsanforderungen in prozessintegrierten Umgebungen 83 Typtransformationen befreien und semantische Unterschiede zwischen den Kom ponentenarchitekturen z B unterschiedliche Interpretationen von Objektidentifi katoren Bindungsinformationen Sicherheitsschl sseln Fehlern etc kompensie ren Grif98 Die Grundidee ist hier die f r eine heterogene Komponentenbin dung und interaktion erforderlichen Interpretations und Transformationsvor g nge in einer eigenen Infrastrukturkomponente dem Inrerzeptor zu kapseln Bei spiele f r solche Interzeptor Komponenten sind die von JavaSoft angebotene ActiveX Bridge Java98 die die Nutzung von JavaBeans als ActiveX Controls innerhalb von Microsofts Komponentenmodell COM erm glicht oder die COM CORBA Btidge OrbixCOMet Iona00 von Iona Technologies W hrend sich der Begriff der Koordinations und Konfigurationssprachen Skriptsprachen vornehmlich in der wissenschaftlichen Literatur findet ist in der praktischen An wendung meist von S amp riptsprachen die Rede Hier hat in den vergangenen Jahren Microsofts Visual Basic VB und die speziell auf die Steuerung von Applikations programmen zugeschnittene Variante Visual Basic for Applications VBA gro e Popularit t erlangt und sich als Marktf hrer im Windows Umfeld etabliert Der Erfolg von VB VBA
371. iversity Press 1994 Brockschmidt K Inside OLE Microsoft Press 1995 Brown A Control Integration through Message passing in a Software Development Environ ment Software Engineering Journal S 121 131 May 1993 Bray T Paoli J und Sperberg McQueen C M Hrsg Extensible Markup Language XML 1 0 Tech Report W3C REC xml 19980210 Feb 1998 http www w3 org TR REC xm Buschmann F Meunier R Rohnert H Sommerlad P und Stal M Pattern Oriented Software Architecture A System of Patterns Wiley amp Sons 1996 Byrne B IRDS Systems and Support for Present and Future CASE Technology In Pro ceedings of CAiSE 96 DC W4 Heraklion Greece 1996 Casati F Fugini M und Mirbel I An Environment for Designing Exceptions in Work flows Information Systems 24 3 S 255 273 1999 Cagan M R The HP SoftBench Environment An Architecture for a New Generation of Software Tools Hewlett Packard Journal 42 3 S 36 47 1990 Carr M J Konda S L Monarch I Ulrich F C und Walker C F Taxonomy based Risk Identification Tech Report Software Engineering Institute Carnegie Mellon University Pittsburg Pennsylvania USA 1993 Catell R Barry D Berler M Eastman J Jordan D Russell C Schadow O Stanienda T und Velez F Hrsg The Object Data Standard ODMG 3 0 Morgan Kaufmann Publishers 2000 Cardelli L und Wegner P On Understanding Types Data Abstraction and
372. ividuellen Entwicklerarbeitsplatzes wertlos 1 2 Ziele und Aufbau der Arbeit Gegenstand der vorliegenden Arbeit ist die Prozessintegration von Entwicklungs umgebungen Die dahinter stehende Fragestellung lautet Mit welchen Modellen und Mechanismen kann die Arbeitsweise von und mit Softwarewerkzeugen einem definierten Arbeitsprozess untergeordnet werden und auf effiziente Art und Weise an sich ndernde Prozessdefiniti onen angepasst werden Die systematische Ausarbeitung dieser Fragestellung und des vorgeschlagenen L sungskonzepts findet in drei Schritten statt Problemanalyse Vergleich und Bewertung existierender Ans tze Das Ziel des ersten Teils der Arbeit besteht zun chst darin die St rken und Schw chen heutiger Prozessunterst tzungsans tze zu analysieren und diese mit unserer Zielvorstellung einer prozessintegrierten Entwurfsumgebung zu kontras tieren Kapitel 2 Zur Strukturierung der Analyse entwickeln wir ein Klassifikati onsschema das eine Bewertung hinsichtlich der Merkmale unterst tzte Projektebene Integrationstiefe Kontextbezogenheit Anpassbarkeit und Abdeckung des Spektrums unterschiedlicher Unterst tzungsmodi erm glicht Der Vergleich ergibt dass prozess zentrierte Umgebungen grunds tzlich die gerade in kreativen Entwurfsdom nen n tige Flexibilit t hinsichtlich der Definition neuer Prozesse oder der Anpassung existierender Prozesse bieten aber nicht die n tige Integrationstiefe mit der eigent lichen
373. jektmanagementebene Planung amp Organisation Ressourcen verwaltung amp koordination Abweichungen Kontrolle amp Anleitung Aufgabenstatus Ressourcen bedarf Ressourcen status Entwickler informationen Systementwicklung Analyse Entwurf Implementierung Test Arbeitsplatzebene Zu den Aufgaben der Projektplanung und organisation geh rt die Festlegung eines Projektplanung und projektweiten arbeitsplatz bergreifenden Entwicklungsprozesses in einem Pro Organisation jektplan und dessen kontinuierliche Fortschreibung und eventuelle Anpassung im 12 2 Prozessorientierte Unterstutzungsfunktionen Laufe des Projektfortgangs In einem Projektplan werden das Projektziel d h die erwarteten und vertraglich festgelegten Endergebnisse sowie die Einschr nkungen und Randbedingungen denen das Projekt unterliegt Projektdauer Budgetvorga ben Verf gbarkeit von Ressourcen festgehalten Wichtigstes Hilfsmittel der Projektplanung ist die Dekomposition des Gesamtvorhabens in abgrenzbare Phasen und die weitergehende Strukturierung des Entwicklungsprozesses in eine Abfolge einzeln handhabbarer Aufgaben Jede Aufgabe wird durch Angabe der f r die Bearbeitung ben tigten Ressourcen Eingabedokumente der erwarteten Ergebnisse Ausgabedokumente und in der Regel auch durch eine allgemeine Aufgabenbeschreibung n her charakterisiert Explizit festgelegte Abh ngigkeiten zwischen ei
374. k nnen ohne ein durchg ngiges Prozessmodell zu erzwingen La B097 O Kontextbasiertheit In Abschnitt 2 1 3 haben wir von einem Prozessun terst tzungsansatz gefordert dass die Unterst tzungsleistung zum Zeit punkt der Inanspruchnahme auf den aktuellen Prozesskontext zugeschnit ten sein sollte Kontextbezogenheit Wegen der nur fragmentarischen Er fassung des Entwurfsprozesses im Prozessmetamodell kann jedoch nicht davon ausgegangen werden dass in der Leitdom ne Informationen ber den aktuellen Prozesskontext implizit aus dem Ausf hrungszustand eines globalen Prozessmodells abgeleitet werden kann Dies bedeutet aber dass f r jedes modellierte Prozessfragment der Kontext beschrieben werden muss in dem dieses durchgef hrt werden kann Q Kompositionalit t Gerade in kreativen Entwurfsdom nen ist die Akqui rierung und modellm ige Umsetzung von Prozesswissen ein Vorgang der nicht mit der Erstellung eines initialen Prozessmodells abgeschlossen ist sondern den Entwurfsprozess innerhalb eines Projekts und ber Projekt grenzen hinweg st ndig begleitet Unterst tzt durch Prozess verbesserungsinfrastrukturen z B GQM BaRo88 BaCR94 wird hierbei ausgehend von einem anfangs m glicherweise nur rudiment ren Verst nd nis elementarer Prozessschritte d h der Basisfunktionalit ten der unter st tzenden Werkzeug Wissen ber zunehmend komplexere Vorgehens weisen erworben die sich dutch Kombination bereits verstandener und
375. keit und Nutzen zu demonstrieren Der Ansatz einer Framework basier ten Realisierungsplattform stellt dabei ein gewisses Ma sowohl an Entwicklungs effizienz als auch an Robustheit der Implementierung sicher 7 4 Integration existierender Werkzeuge 227 In der Praxis stellt die Fokussierung auf die a priori Integration allerdings eine nur schwer hinnehmbare Einschrankung dar Viele Entwickler sind nicht bereit auf die Werkzeuge ihrer gewohnten Arbeitsumgebung zu verzichten und h ufig wird die Verwendung bestimmter kommerzieller Werkzeuge bereits vertraglich durch den Kunden vorgegeben so dass in der Wahl der Werkzeuge kaum Spiel raum besteht BrMc91 EBLA96 Dar ber hinaus erfordert die Realisierung spegifi scher Funktionalit t bei komplexen Werkzeugen einen erheblichen Aufwand der auch bei einer stark auf Wiederverwendung ausgerichteten Entwurfsmethodik nicht untersch tzt werden darf Ein Ansatz zur Prozessintegration kann also letztendlich nur dann erfolgreich sein wenn er in der Lage ist die in einer Organisation vorgefundene Werkzeug Landschaft einzubeziehen In diesem Abschnitt besch ftigen wir uns daher mit den M glichkeiten und Grenzen existierende Werkzeuge mithilfe geeigneter Verkapselungstechniken Wrapper der Prozessintegration einer PRIME ba sierten Umgebung zug nglich zu machen und beschreiben unsere Erfahrungen mit der a posteriori Integration von drei externen Werkzeugen 7 4 1 Anforderungen an Werkzeugsch
376. komposition und verteilung Verwal tung von Ressourcen Koordination von Entwicklern Prozess berwachung und Fottschrittskontrolle im Vordergrund steht Bei der methodischen Anleitung feingranularer Entwickleraktivit ten weisen prozesszentrierte Umgebung jedoch gravierende Schw chen auf die in erster Linie auf die nur Jose Integration der Modellierung und Leitdom ne mit der Durchf h rungsdom ne d h den Werkzeugen zur ckzuf hren sind Die Kommunikation mit dem Benutzer erfolgt meist ber separate Assistenzwerkzeuge die eine be stimmte Sicht auf den Entwicklungsprozess bieten und manuell vom Benutzer anzugebende R ckmeldungen aus der Durchf hrungsdom ne entgegennehmen Die Integrationstiefe mit den Entwicklungswerkzeugen ist gering und beschr nkt sich in der Regel auf den grobgranularen Aufruf von Werkzeugen wodurch ge wisse Abl ufe automatisiert werden k nnen Die schwierige Kontrolle des Einsat zes und der Verwendung von Werkzeugen durch den Benutzer f hrt dazu dass Prozesslenkung process enforcement d h die prozesskonforme Durchf hrung von Entwicklungsaktivit ten in prozesszentrierten Umgebungen nicht sichergestellt werden kann Dedizierte werkzeugorientierte Unterst tzungssysteme wie Hilfesysteme As sistenten und Interface Agenten bieten zwar eine hohe Unterst tzungsqualit t f r den Benutzer einer Entwicklungsumgebung da sie unmittelbar mit den Werkzeu gen mit denen der Entwickler den eigentlichen Prozes
377. kt befindet Zum anderen lassen sich IDL Spezifikationen in zentrale Speicher f r Schnitt stellenbeschreibungen berf hren die u a Werkzeuge zur Verwaltung von Kom ponentensammlungen oder das Erfragen von Typinformationen zur Laufzeit unterst tzen In CORBA ist das Interface Repository ein spezieller Service f r die Verwaltung von Schnittstellenbeschreibungen der ber standardisierte CORBA Methodenaufrufe den Laufzeitzugriff auf Schnittstellenobjekte erlaubt Eine ver gleichbare Aufgabe zur Beschreibung von Komponenten bernehmen in DCOM die Type Libraries Interface Repository bzw Type Library und IDL Datei sind lediglich zwei unterschiedliche Repr sentationsformen f r die gleiche Information Mithilfe geeigneter Werkzeuge k nnen die Repr sentationen jeweils ineinander berf hrt werden Ein etwas anderer Mechanismus liegt dem JavaBeans Modell zugrunde das Techniken zur Introspektion und Reflexion KiRB91 nutzt und somit eher zur Se bstauskunft von Komponenten zur Laufzeit geeignet ist Interface Repository zur Laufzeitunterst tzung In Message Broadcasting Architekturen siehe auch Abschnitt 3 3 3 sind Werkzeugbeschreibun Werkzeuge durch die Menge aller Nachrichtenmuster f r die sie sich beim Mes gen in Message Broad BEN Be i casting Architekturen sage Server registriert haben und auf die sie somit sinnvoll reagieren k nnen charakterisiert Die Nutzbarkeit der Registrierungsinformationen zur Prozessmo dellier
378. kzeuginteraktion zur Laufzeit besch ftigt und sind zum Schluss ge kommen dass Werkzeuginteraktion in der Durchf hrungsdom ne ber die Leit dom ne d h die Prozessmaschine auf Basis explizit definierter Prozessfragmente vermittelt werden sollte Diese Diskussion erfolgte aus der Perspektive des Werk zeugintegrators und war weitgehend unabh ngig von der Frage wie die F higkei ten eines Werkzeugs zur Definitionszeit repr sentiert und der Prozessmodellierung zug nglich gemacht werden Um sicherzustellen dass die in einem Prozessfragment definierten Arbeits schritte und Arbeitsmodi in der Durchf hrungsdom ne auch umgesetzt werden k nnen m ssen die Werkzeuge bei der Prozessfragmentdefinition geeignet be r cksichtigt werden Dazu ben tigt der Prozessmodellierer Informationen ber die in einer Entwurfsumgebung vorhandenen Werkzeuge ihre Dienste und deren Parameter die Art des Dienstaufrufs etc Diese Informationen bezieht der Pro zessmodellierer typischerweise aus einer Vielzahl von Quellen z B aus Handb 3 3 Integrationsanforderungen in prozessintegrierten Umgebungen 85 chern Programmdokumentationen formalen Schnittstellenbeschreibungen und Typbibliotheken oder auch schlicht aus pers nlichem Wissen und individuellen Erfahrungen Diese Vielfalt von Werkzeugbeschreibungen die in heutigen hetero genen Arbeitsumgebungen eher die Regel als die Ausnahme ist erschwert das Auffinden und die Zuordnung geeigneter Werkzeugunters
379. l kann nicht direkt als ausf hrbare Prozessmodellierungssprache verwendet werden kann da es keine geeigneten Konzepte zur Formalisierung von Situationen und zur Festlegung eines Kontrollflusses in Plankontexten anbietet Daher musste eine geeignete Einbettung eines Kontrollmodells in das NATURE Prozessmodell gefunden werden Um Flexibilit t und Anpassbarkeit an dom nenspezifische Bed rfnisse zu gew hrleisten haben wir das Ziel ver folgt nicht nur einen Ablaufformalismus fest vorzugegeben oder einen neuen zu erfinden sondern die Auswahl aus einer Palette unterschiedlicher Formalismen anzubieten die f r einen betrachteten Ablauf jeweils beson ders geeignet sind Hieraus ergab sich das Problem der Interoperabilitat ver schiedensprachlicher Prozessfragmente Als L sungsansatz haben wir uns f r einen komponentenbasierten Modellierungsansatz entschieden bei dem das NATURE Prozessmodell so erweitert wurde dass Kontexte als Komponenten mit definierten Schnittstellen modelliert und in einer Ver wendungssprache unabh ngig von ihrer Implementierung wiederverwen det werden k nnen O Implementierungs Frameworks Das Konzept zur integrierten Werkzeug und Prozessmodellierung wurde in Form zweier generischer objektorientierter Frameworks umgesetzt In der Durchf hrungsdom ne definiert das GAR PIT Framework die Grundstruktur eines prozessintegrierten Werkzeugs Es stellt vorgefertigte Komponenten zur Synchronisation mit der Leitdo m ne und
380. ldefinition eines Entscheidungskontexts pc ER SpecializeEntity ee Context zer CC_ER_Standard PRIME NATPRO Modeler Document Edit Cr Tools Preferences lt Detaildefinition eines Ausf hrungskontexts Choice Context CC a Situation Intention NO INTENTION m Context L External name EC_ER_CreateRelationship Tool of Choice Context Tool ER Editor v Type Executable Context EC mes CC type alternatives Situation C ER AddAttributeToRelationship aC FR CreateFRLink ER CreateRelationship PC_ER DoVisEdA ction ER NewERD PC_ASP_AddComponent C_ASP_CheckTDCalcMethnd Intention amp ER_createRelationship EC type operatighalized by Action type ACT_ER_createRelationship PC_ASP FinishThisStep PC _ASP_OptimizeProcess PC_ASP_PerformSensitivityAnalysis Cancel RANE o peasr aut Output pargheter GneRelationshipSelected ER Quit C ASP RunSimulation PRI E NATPROC Modeler PC ER SpecializeEntity iCC_ASP_SelectSimulationRun ites GS Boch fees een PC ER createEntity xl PC_ASP_SimSpecifiyComponents HES Detaildefinition eines Situationstypen Ednan E Unrestricted Plan Context Choice Context Executable Context External name OneOrMoreEntitiesSelected Descriptors Type Data promctuist Frenity z Extension PRIME NATPROC Modeler Bel Document Edit Create Tools Preferences
381. lementierten Pro duktmodells siehe unten Das vergr berte Modell wird als Instanz in ein Meta 7 3 GARPIT ein Framework f r prozessintegrierte Werkzeuge 221 schema eingetragen welches Metainformationen ber die vorhandenen Produkt typen und deren Spezialisierungsbeziehungen f r den ContextManager bereitstellt Grafische Symbole Darstellungsarten und Kommandoelemente F r die modellierten Produkttypen werden die zu verwendenden grafischen Sym bole in den Darstellungsarten hervorgehoben selektierbar und deaktiviert definiert vgl Abschnitt 5 4 2 Beispielweise wird f r den Produkttypen ER Entity festgelegt dass Instanzen dieses Typs im ER Editor durch ein Rechtecksymbol mit zentrier tem Text dargestellt werden soll wobei das Rechteck je nach Darstellungsart rot wei oder grau gef llt wird Im Werkzeugmetamodell sind die g ngigsten grafi schen Symbole und Darstellungsarten vordefiniert Diese werden vom Framework bereits zur Verf gung gestellt Ben tigt der Werkzeugmodellierer dar ber hinaus gehende Symbole und Darstellungsarten muss er diese zum Werkzeugmetamodell hinzuf gen und in der Implementierungsphase realisieren Sowohl das Werkzeug metamodell als auch das Framework sehen entsprechende Anschluss und Erwei terungsstellen vor Im Falle des ER Editors kommen wir jedoch mit den vordefi nierten grafischen Objekten aus Zus tzlich zu den grafischen Symbolen f r Produkte m ssen noch die im
382. len gekapselt von den Auswirkungen paralleler Schritte abgeschirmt und im Fehlerfall als Ganzes oder in kontrollierbaren Teilabschnitten zur ckgesetzt wer den Im Gegensatz zu Transaktionen in Standard Anwendungen Bank Applikati onen Buchungssystem u sind Entwurfsprozesse durch langlebige komplexe und interaktive Aufgaben charakterisiert f r die sich die ACID Eigenschaften und Serialisierbarkeitsbegriffe aus Standarddatenbank Anwendungen als ungeeignet 3 3 Integrationsanforderungen in prozessintegrierten Umgebungen 69 erwiesen haben Erweiterte Transaktionsmodelle die die klassischen Serialisierbar keitsbegriffe aufweichen und dazu das in einer prozessintegrierten Umgebung verf gbare zus tzliche Prozesswissen ausnutzen sind Gegenstand des umfangrei chen Gebiets der transactional workflows Aus Aufwandsgr nden k nnen wir jedoch diesen Aspekt in der vorliegenden Arbeit nicht vertiefen und verweisen stattdessen auf weiterf hrende Literatur Bre 93 GeHo94 Alo 96 PuTV97 3 3 2 3 Fazit Datenintegration besch ftigt sich mit Fragen des Datenaustauschs und der Kon sistenzsicherung von Daten in einer Entwicklungsumgebung Es ist das am inten sivsten untersuchte Integrationsproblem f r das mittlerweile ausgereifte L sungs ans tze vorliegen Am weitesten verbreitet ist der Austausch von Daten ber Dateien Da die Da ten in unterschiedlichen Werkzeugen in der Regel in unterschiedlichen Formaten vorliegen ist ein betr cht
383. lf D mges Stefan Zlatinsis J rgen Rack und Ralf Klamma und insbesonde re dem Leiter der Arbeitsgruppe Klaus Pohl O den studentischen Hilfskr ften und Diplomanden Sebastian Brandt Mar kus Hoofe Michael Mattern Tobias R tschke Dirk Schmidt Robert We ber Q den Mitarbeitern und Kollegen in den Projekten CREWS und IMPROVE m meinen Eltern O Barbara Inhaltsverzeichnis Inhaltsverzeichnis Teil 1 Einordnung der Arbeit us4444444 nennen nennen 1 T EINLEITUNG seen en nennen 3 1 1 Motivation und Problembeschreibung rssssnssonssonssonnsnonsnonsnonssnnsnne 3 1 2 Ziele und Aufbau der Arbeit ssesssssssosssonssonssnnssnnssnnssnnnsnnnsnnnsnnnsnonsnnnnnee 5 2 PROZESSORIENTIERTE UNTERST TZUNGSFUNKTIONEN 9 2 1 Ein Klassifikationsmodell f r Prozessunterstiitzungsfunktionen 9 2 1 1 Unterst tzte Projektebene usenssennsenseennennneenneennennnnnnnn nennen 11 2 1 1 1 Projektmanagement Ebene unnseseeseesneesneennenennnennnenne nennen 11 21 2 Arbeitsplatzebene neesanentesesensenauneienaisahane 12 2 1 2 Integrationstiefe esseeeseeensesnsennseenneennennennnennennnnnnn essen nnsesnse nenne 17 2 1 3 K ntextbezogenheit u an ensishkn lkknnhin aehalg 19 2 14 Anp assb rkeit oris reretia i EREC ee idiatecdese 21 2 1 5 Unterst tzungsmodi und Durchsetzungsgrad enenenen 23 2 2 Bewertung existierender Ans tze
384. lgemeinen nicht integrierter Hilfesysteme umgehen muss Als Konsequenz bieten Hilfesysteme bei werkzeug ber greifenden Abl ufen kaum oder gar keine Prozessunterst tzung Q Kontextbezogenheit Gem der oben vorgenommen Klassifizierung von Hilfesystemen stellen dynamische und oder individuelle Hilfesysteme kontextbezogene Prozessunterst tzungsmechanismen dar w hrend stati sche und oder uniforme Hilfesysteme nicht kontextbezogen unterst tzen Passive Hilfesysteme k nnen sowohl statisch als auch kontextbezogen sein Aktive Hilfesysteme stellen von sich aus fest wann Hilfe ben tigt wird und ber cksichtigen somit automatisch den Kontext zum Zeitpunkt der Hilfeleistung O Anpassbarkeit Hilfesysteme sind in der Regel nicht anpassbar oder nur grob konfigurierbar etwa durch Voreinstellung eines Benutzerprofils z B Anf nger fortgeschrittener Benutzer Experte Die Aktualisierung des vom einem Hilfesystem bereitgestellten Prozesswissens geht meistens ein her mit der Installation einer neuen Version des zugeh rigen Werk zeugs Anwendungsprogramms Manche Hilfesysteme erlauben die Anno tation von Hilfeseiten mit eigenen Notizen oder die Definition von benut zerspezifischen Lesezeichen innerhalb des Hilfesystems O Unterst tzungsmodi Gem ihrer Definition bieten passive Hilfesys teme nur Prozessberatung an w hrend aktive Hilfesysteme ohne explizite Benutzeraufforderung anleitend in den Prozess eingreifen Dies ist unab h n
385. lichen werden daher alle Ergebnisschnittstellen auf denselben Nachbereich abge bildet Der Nachbereich ist somit an mehrere Situationsschnittstellen gebunden so dass je nach Auswahl des Benutzers das Ergebnis der gew hlten Kontextalterna 162 6 Interoperabilitat von Prozesssprachen tive dem Nachbereich dynamisch zugewiesen wird Fur jede Alternativschnittstelle existiert eine Bindung an den Nachbereich der Transition die festlegt wie das Ergebnis der Kontextalternative auf die Stellen abgebildet wird Wenn die EK Komponente mehrere verschiedene Ergebnisschnittstellen hat dann muss ftir jede Schnittstelle eine eigene Schnittstellenbindung existieren die die Zuweisung zu den SLANG Nachbereichsstellen vornimmt Integritatsbedingung ekSchnittstelle MetaClass Slang AB in Aktivit tsbindung with constraint ekSchnittstelle forall sab Slang AB kk KontextKomponente vk EK_Verhaltenskomponente sl s2 Schnittstelle kk verhalten vk and kk ausgang sl and kk ausgang s2 and sl s2 gt exists ssbl ssb2 Slang_SB b Bereich ssbl sprachneutraleDarstellung sl and ssbl ProzesssprachenKonzept b and ssb2 sprachneutraleDarstellung s2 and ssb2 ProzesssprachenKonzept b end 6 5 Fazit Ausgangspunkt dieses Kapitels war die Feststellung dass das NATURE Prozess modell nicht direkt als ausf hrbare Prozessmodellierungssprache verwendet wer den kann da es keine geeigneten Konzepte zur Formalisi
386. lichen Ar beitsschritte siehe Abschnitt 2 1 3 Andere Formen der passiven Prozessberatung bestehen darin dem Prozessausf hrenden einen berblick ber den aktuellen Prozesszustand z B Bearbeitungszustand der einzelnen Aufgaben und Doku mente zu geben oder die Auswirkung hypothetisch ausgef hrter Aktionen auf den Prozesszustand untersuchen zu k nnen z B welche Anpassungsoperationen eine nderung eines Produkts nach sich zieht Wesentlich f r die passive Prozessbe ratung ist dass sie nur auf Initiative des Prozessausf hrungen in Aktion tritt und dass im weiteren Prozessverlauf die Ad quatheit der Prozessunterst tzung nicht unbedingt davon abh ngt dass die zuvor angebotene Unterst tzung tats chlich angenommen und befolgt wird Aktive Aktive Prozessanleitung basiert wie die passive Prozessberatung auf R ckmeldun Prozessanleitung gen bzgl der aktuellen Prozessdurchf hrung so dass die Prozessmodellausf hrung dem Prozessausf hrenden Ratschl ge oder Information geben kann die im aktuel len Prozesszustand relevant sind Im Gegensatz zur passiven Beratung tritt die aktive Anleitung nicht erst auf Anfrage des Prozessausf hrenden in Aktion son dern greift in bestimmten Situationen aktiv in den Prozess sein Aktive Anleitung kann darin bestehen neue Aufgaben in die Agenda eines Prozessausf hrenden einzuf gen ihn ber bestimmte Ereignisse in Kenntnis zu setzen z B dass ein von ihm ben tigtes Dokument von einem anderen Tea
387. licher Aufwand f r Dateikonverter erforderlich woran auch standardisierte Austauschformate wenig ndern Da die Leitdom ne mit potenziell allen Werkzeugen interagieren muss stellt eine auf Dateiaustausch basierende Integrationsmethodik eine wenig Erfolg versprechende L sung dar Zudem ist die Konsistenzsicherung bei diesem Verfahren sehr schwierig Die ideale L sung zur Datenintegration in einer prozessintegrierten Umgebung besteht daher in einem logisch zentralen Repository in dem die Daten der Werk zeuge und der Prozessmaschine unter einem globalen Schema integriert sind Wegen der Speicherung der Daten an einem zentralen Ort entfallen als Konsis tenzprobleme die sich aus eine Replikation von Daten in unterschiedlichen Da teien ergeben k nnten Wegen der Notwendigkeit eines gemeinsamen Schemas funktioniert dieser Integrationsansatz allerdings nur bei der a priori Integration von Werkzeugen F r die a posteriori Integration unabh ngig voneinander entstandener Werk zeuge ist eine unmittelbare Integration ber ein Prozess Repository in der Regel nicht m glich Dies w rde eine Einigung auf ein gemeinsames Datenmodell f r die syntaktische Integration und ein globales Schema f r die semantische Integ ration voraussetzen Das Scheitern diverser Standardisierungsinitiativen in den 80er und 90er Jahren hat gezeigt dass allgemeine Standards von den Werkzeug herstellern h ufig als zu komplex und schwerf llig betrachtet werden und
388. lierungs und Leitdom ne einerseits und der Durchf hrungs dom ne andererseits herauszuarbeiten Zur Strukturierung der unterschiedlichen Integrationsaspekte haben wir zu n chst allgemeine Klassifikationsans tze f r die Integration von Entwicklungsum gebungen aus der Literatur vorgestellt Die Diskussion ergab dass der Begriff der Prozessintegration bereits in einer Reihe von Publikationen aufgegriffen wird und als ein Adaptionsproblem unter Nutzung der Dienste tieferer Integrationsdi mensionen Daten Kontrolle Pr sentation verstanden wird Welche konkreten Anforderungen sich aus einer prozessorientierten Sichtweise an die Integration zwischen den Prozessdom nen ergeben gilt jedoch noch als weitgehend unverstan den und wird in den zitierten Publikationen nicht im Detail er rtert Um die Konsequenzen einer engeren Integration der Prozessdom nen n her zu beleuchten haben wir sechs zentrale Integrationsanforderungen hergeleitet m m m m m m Datenintegration zwischen den Prozessdom nen Prozessorientierte Mediation von Werkzeuginteraktionen Konzeptuelle Modellierung von Werkzeugen Synchronisation zwischen Leit und Durchf hrungsdom ne Prozesssensitive Anpassung der Interaktion in den Werkzeugen Werkzeugunterst tzter Aufruf von Prozessfragmenten Die Betrachtung existierender prozesszentrierter Umgebungen sowie weiterer Ans tze aus den Bereichen Datenintegration Kommunikationsinfrastrukturen k
389. lit t die die Situationserkennung im PRIME Framework komplemen tiert Weitergehende Informationen zum Process Data Warehouse und seiner Anbindung an das Flie bild Datenmodell sind in JaLW00 zu finden 4 Implizit bedeutet dies dass zu einer Prozessgruppe eine beliebige Anzahl alternativer Verfeine rungen existieren k nnen w hrend zu jeder Prozessgruppe h chstens eine bergeordnete Gruppe existieren kann Wir erhalten dadurch einen Baum von alternativen Verfeinerungen 257 Metamodellierung der Bausteintypen 258 8 Anwendungen Umgang mit dem Flie bildmodell aus Benutzersicht Die bisher beschriebenen Klassen definieren den Inhalt eines Flie bildmodells das ber beliebig viele Verfeinerungsebenen strukturiert sein kann Im Flie bildwerk zeug kann der Benutzer zu einem Zeitpunkt jeweils nur einen bestimmten Aus schnitt dieses Modells betrachten bei dem die hierarchische Struktur des Modells auf ein flaches Zeichenblatt herunter gebrochen wird Der Benutzer ver ndert den aktuell betrachteten Ausschnitt eines Flie bildmodells indem er neue VT Prozesselemente und gruppen einf gt und zwischen unterschiedlichen Verfeine rungsebenen hin und her navigiert Eine Besonderheit des Flie bildeditors besteht darin dass das Ein und Ausblenden einer verfeinerten VT Prozessgruppe inner halb des gleichen Fensters m glich ist Dadurch bleibt die Umgebung des be trachteten Flie bildausschnitts in der Ansicht erhalten
390. llen in eine XML basierte Darstellung beschreibt XMI wurde in relativ kurzer Zeit auf breiter Front von wichtigen M ein XML basierter Austauschstandard f r Werkzeug Herstellern aufgegriffen z B Rational Rose Together und Argo UML UML Moaelle und scheint sich als der Austauschstandard fir UML Modelle durchzusetzen Bemerkenswert an dieser Initiative ist dass mit XMI im Gegensatz zur bisherigen OMG Philosophie ein komplement rer Mechanismus zum direkten CORBA basierten Datenaustausch in die Standardisierungsbem hungen der OMG aufge nommen wurde In DHTT00 wird der XMI basierte Datenaustausch an einem Fallbeispiel untersucht und mit dem direkten Datenaustausch ber Werkzeug APIs verglichen Hier kommen die Autoren zum Schluss dass sich die XMI basierte Methode prim r in asynchronen Kooperationssituationen eignet w hrend die kontinuierliche inkrementelle Synchronisation zwischen verschiedenen UML Werkzeugen am besten ber den direkten Datenaustausch und Ereignisnotifikati onsmechanismen mithilfe entsprechender Werkzeug APls siehe auch Abschnitt 3 3 3 zu realisieren ist Die Konsistenzsicherung in Datenintegrationsansatzen die auf Dateiaustausch Konsistenzsicherung basieren stellt ein massives Problem dar da die einzelnen Werkzeuge lediglich eine beim Dateiaustausch lokale Sicht auf die Daten haben und keine werkzeug bergreifende Kontrolle der Gesamtkonfiguration der Daten auf der feingranularen Ebene existiert Kipe94
391. ltet wobei jeder ObjectDescriptor den eindeutigen Repository Identifikator eines Produkts mit Referenzen auf die entsprechenden T Model bzw T GUI Laufzeitobjekte verkn pft Auf hnliche Weise assoziiert die IntentionTable logische Intentions Identifikatoren mit entsprechenden Kommandoelementen aus dem Paket T GUI nderungen des Selektions bzw Selektierbarkeitsstatus von Produkten und Kommandoelementen werden zwischen dem ContextManager und der Pr sentati onsschicht ausschlie lich ber ObjectTable und IntentionTable ausgetauscht Die ObjectTable und die IntentionTable liefern dem ContextManager somit eine abstrakte Sicht auf den aktuellen Werkzeugzustand die v llig unabh ngig ist von 7 3 GARPIT ein Framework f r prozessintegrierte Werkzeuge 201 den Klassen des werkzeuginternen Produktmodells und der Benutzeroberfl che ist Das generische Teilsystem StateManager realisiert die globale Werkzeugkon StateManager trolle gem dem in Abschnitt 7 2 definierten Zustandsdiagramm Ereignisse die globale Zustandskon S trolle gem Interakti im StateManager verarbeitet werden werden von den Teilsystemen MessageIn onsprotokoll terface und GenericGUI generiert Das Teilsystem MessageInterface etabliert einen Kommunikationskanal zur Messagelnterface Leitdom ne eigentlich zum Kommunikationsmanager und erlaubt das Verschi Kommunikationskanal k ed b d h Empi derit Abschnitte 72 def zwischen
392. lungsprozess und die damit assoziierten Dokumente gilt auch f r die Sicht des technischen Entwicklers die ihm in den jeweiligen Entwickler Frontends pr sentiert wird Im Gegensatz zum Projektmanager profitiert der technische Entwickler bei der systematisch methodischen Durchf hrung einzelner Aufgaben somit nur eingeschr nkt von der Unterst tzungsleistung durch eine PZEU indem er beispielsweise ber einen Task Manager einen berblick ber die anstehenden Aufgaben erh lt oder Werkzeuge mit den ben tigten Dokumenten gestartet werden Dar ber hinaus gehende feingranulare Prozessunterst tzung wird von PZEUen in der Regel nicht angeboten O Integrationstiefe PZEUen treten in der Arbeitsumgebung eines Entwick lers als zus tzliche rechnerbasierte Assistenzwerkzeuge in Erscheinung Wie oben beschrieben ist die Integration mit den eigentlichen Entwurfs werkzeugen in der Regel jedoch nur rudiment r realisiert Nach dem Start des Werkzeugs steht die Prozessausf hrung innerhalb des Werkzeugs nicht 40 2 Prozessorientierte Unterstutzungsfunktionen mehr unter der Kontrolle der Prozessmaschine und R ckmeldungen ber die Anwendung von Werkzeugen und deren Ergebnisse m ssen manuell ber das Entwickler Frontend an die Prozessmaschine bermittelt werden Q Kontextbezogenheit PZEUen sind dazu pr destiniert kontextbezogene Prozessuntersttitzung liefern da sie dynamisch ein internes Modell des ak tuellen Prozesszustands pflegen Diese Sta
393. m ne in Dowson s Dom nenmodell f r prozesszentrierte Umgebungen DoFe94 siehe Abschnitt 2 2 4 2 hebt den Unterschied zwischen drei fundamentalen Sichten auf den Prozess hervor Cugo98 3 3 Integrationsanforderungen in prozessintegrierten Umgebungen 95 O Prozessmodell Modellierungsdom ne Dies ist ein in einem bestimmten Formalismus notiertes Modell des erwarteten Prozesses und liefert eine stati sche Soll Sicht auf den Prozess O Realer Prozess Durchf hrungsdom ne Dies ist der eigentliche Prozess so wie er in der realen Welt durchgef hrt wird Der reale Prozess l sst sich charakterisieren durch den aktuellen Zustand der Produkte auf denen der Prozess operiert sowie durch die Prozesshistorie also die Abfolge von Er eignissen und Aktivit ten seit der Prozess gestartet wurde Der reale Pro zess ist eine dynamische Entit t d h er ndert sich sobald ein neues Ereignis eintritt z B Beendigung einer Aktion O Beobachteter Prozess Leitdom ne W hrend der Prozessmodellausf h rung hat die Leitdom ne nur eine partielle vergr berte Sicht auf den realen Prozess Der beobachtete Prozess basiert auf Aktionen die der Benutzer unter Kontrolle der Leitdom ne durchf hrt bzw ber die die Leitdom ne explizit informiert wird Alle anderen Ereignisse die den realen Prozess beeinflussen sind f r die Leitdom ne nicht sichtbar Zu jedem Zeitpunkt kann der beobachtete Prozess durch die Historie von Aktivit ten b
394. m Werkzeugmo dell definierten Typ erzeugt und an die IDs der in der Aktion erzeugten oder modifizierten Produktinstanzen gebunden Eine Aktion umfasst typischerweise zwischen 20 und 50 Zeilen Code F r die ca 20 Aktionen die der ER Editor in der aktuellen Version bietet sind etwa 800 Zeilen Code erforderlich Das folgende Beispiel zeigt die etwas umfangreichere Aktion createNewRelationship CcxtSitData CeraCreateNewRelationship execute CcxtSitData sd PRECONDITION correct Sit Type sd retSitDesc gt getObjectID oidST_ER OneOrMoreEntitiesSelected 1 retrieve list of entity objects to be connected from situation data TmapProductDescList lsprodEntities sd getProdListData sSR_ER EntityList 2 retrieve GUI and product model objects from object table TmapGrObjPtrList lspgoEntities GUI objects TermEntityList lspereEntities product model objects CmapProductDesc prod product ID forall prod lsprodEntities PTmapGrObj pgo NULL PCermEntity pere NULL perot gt letEntity pgo pere prod perot is the ER object table lspgoEntities append pgo lspereEntities append pere 3 perform updates in GUI and product model 3a create relationship in GUI interactively TkitString sLabel TkitInt iX iY TmapGrObjPtrList lspgoRoleLinks PTmapGrObj pgo NULL 224 7 Das PRIME Rahmenwerk perw gt createRelationship pgo sLabel lspgoRoleLinks lspgoEntities
395. mat der WPDL deklariert Ebenso wird das Kontrollmodell der jeweiligen Prozesssprache auf bedingte Tran sitionskanten der WPDL abgebildet um so die Ausf hrungsreihenfolge unter den exportierten Aktivit ten festzulegen jointFlow Die WAPI Standards und die WPDL betrachten zwei duale Aspekte bei der Inte roperabilitat von Workflowmanagementsystemen W hrend die WAPI Standards Laufzeitschnittstellen f r die Integration in der Leitdom ne definieren liefert die WPDL eine sprachliche Integrationsbasis in der Modellierungsdom ne Eine Vereinheitlichung der Modellierungs und Ausf hrungssicht strebt das bei der OMG standardisierte jointFlow Objektmodell OMG 98a an Es liefert ein objektorientiertes Rahmenwerk f r die Ausf hrung berwachung und Interope rabilit t von Gesch ftsprozessen und bildet Prozesskomponenten zusammen mit ihrer Ausf hrungsfunktionalit t durch entsprechende Klassendefinitionen ab Das jointFlow Rahmenwerk besteht aus einer Spezifikation der Schnittstellen und Beziehungen der an der Operationalisierung eines Prozesses beteiligten Klassen siehe Abb 24 Abb 24 Das jointFlow gt WfRequester Objektmodell OMG 98a requester we WfProcessMgr performer process WfProcess Fee i source container irre WfEventAudit J history step y assignee WfActivity assignment WfAssignment WfResource activity work_item
396. mehr oder weniger hochspeziali siertes Prozesswissen das in ihrer Implementierung fixiert wurde aber nicht auf einer konzeptuellen Ebene zug nglich und anpassbar ist Im All gemeinen besteht keine M glichkeit die in einem Assistenten hartkodier ten Prozessvorgaben entsprechend organisations und projektspezifischen Bed rfnissen zu konfigurieren z B bestimmte Auswahlm glichkeiten aus zublenden zu ndern z B die vom Assistenten vorgesehene Abfolge von zwei Arbeitsschritten zu vertauschen oder zu erweitern z B zus tzliche Arbeitsschritte einzuf gen Wegen der engen Integration von Assistenten mit ihren jeweiligen Werkzeugen bleibt die Anpassung von Assistenten bzw die Entwickler von Assistenten f r neue Teilprozesse den Werkzeug herstellern vorbehalten Allerdings besitzen manche Werkzeuge z B das Microsoft Office Paket oder Rational Rose plug in Schnittstellen f r die Integration von Assistenten von Drittherstellern F r spezielle Klassen von Assistenten existieren zudem mehr oder weniger leistungsf hige Werkzeu 2 2 Bewertung existierender Ansatze 33 ge mit deren Hilfe sich Assistenten auf einfache Art generieren lassen Ein Beispiel ist der InstallShield Wizard der selbst wieder einen Assistenten f r die Generierung von Installationsassistenten in Windows Umgebungen darstellt O Unterst tzungsmodi Bei der Beurteilung der Unterst tzungmodi eines Assistenten muss man zun chst zwischen verschiedenen A
397. mmitglied freigegeben wurde oder Warnmeldungen auszugeben z B dass die Deadline f r die Erf llung einer Aufgabe n herr ckt Prozesslenkung Bei der Prozesslenkung wird die eigentliche Prozessausf hrung so gef hrt dass sie mit den Prozessvorgaben der Prozessunterst tzung konform bleibt Effektiv ist dies nur durch strikte Kontrolle des Benutzerzugriffs auf Daten und Werkzeug dienste m glich Dies kann indirekt geschehen indem der Zugriff auf eine Teil menge der in einer Umgebung verf gbaren Daten und Werkzeugdienste einge schr nkt wird oder direkt indem die im aktuellen Prozesszustand relevanten und ggf interaktiven Werkzeugdienste auf geeigneten Datenobjekten von der Pro zessmaschine initiiert werden Prozessautomation Prozessautomation bezeichnet die automatische Durchf hrung eines Teils des Prozesses unter Kontrolle der Prozessunterst tzung Prozessautomation ist immer dann angemessen wenn komplexe stereotype Abfolgen von Entwicklungsschrit ten ohne Benutzerintervention und entscheidung von nichtmenschlichen Agen ten d h Werkzeugen abgewickelt werden k nnen Ein guter Kandidat f r Pro zessautomation ist beispielsweise der Buildprozess d h die Aktualisierung des 2 2 Bewertung existierender Ansatze 25 Codes eines ausf hrbaren Programms nach der Anderung eines oder mehrerer Quelldateien der durch ein Make Skript spezifiziert und gesteuert wird In vielen Publikationen wird betont dass sich die einzelnen Unt
398. munikationsmechanismen Tool Talk und CORBA als Implementierungsplattform eingesetzt so dass wir nun die technologieneut rale Bezeichnung CommunicationChannel bevorzugen CommunicationChannel Abstraktion vom zugrunde liegenden Mechanismus zur Inter prozess kommunikation 206 Abb 52 Detailstruktur des Teil systems Messagelnter face Message abstrakte Datentypen f r Nachrichtenobjekte 7 Das PRIME Rahmenwerk erhalten blieben so dass keinerlei nderungen an den brigen Teilsystemen der GARPIT Architektur erforderlich waren CommunicationChannel CsktlpcClient connect disconnect ping registerMsgHandler sendMessage A CsktSocketClient CsktCorbaClient CsktToolTalkClient A l CsktBSDSocketClient CsktWinSockClient CmsgMessageObject asString createByString CmsgAdminMessage CmsgProtocolMessage A CsmgConnect CmsgStart CmsgContextRequest CmsgContextResponse sgLockRequest A A CmsgDisconnect CmsgPing lt CmsgECResponse CmsgCCResponse CmsgLockOKResponse CmsgGuidanceRequest CmsgExternalECCCRequest CmsgExternalECCCResponse CmsgEndOfEnactment CmsgAbortOK CmsgAbortDenied
399. muss der ER Editor die beiden Alternativen AK ErzeugelsaLink und PK Subtypisiere zur Auswahl anbieten Dies erfordert dass der ER Editor die Intentionen EK Verfei ner hier Erzeuge Entitat als Beratungsdienst des ER Editors saLink und ErzeugeSubtyp als Kommandoelemente und die von den Situationen betroffenen Produkte in verschiedenen Darstel lungsarten dars tellen kann O Darstellung Intention Zwei Links vom Typ Darstellung Intention erm glichen die Aktivierung der Intention ErzugeIsaLink mithilfe des Shortkey Crt1 und durch einen Eintrag im Pulldown Men Edit In hnlicher Weise erfolgt die Abbildung der Intention ErzeugeSubtyp auf die entsprechenden Kommandoelemente in Abb 22 nicht dargestellt Somit wird die Konsistenzbedingung EK2 erf llt QO Darstellungselemen Editor das t Darstellungsart Eine Instanz der Assoziati onklasse Darstellungselement liefert Information dar ber wie der ER Produkt Entit t anzeigen soll n mlich als Rechteck Dar ber hinaus geben Instanzen der Klasse Darstellungsart dar ber Auskunft wie eine Entit t in den Zust nden hervorgehoben selek tierbar bzw deaktiviert repr sentiert werden soll Analog wird f r das Produkt IsaLink das Darstellungselement Pfeil festgelegt und mit 5 7 Fazit entsprechenden Informationen ber die
400. n 7 Das PRIME Rahmenwerk Nagl90 Die durch die Aktionen realisierte Art der Verkn pfung zwischen Pro duktmodell und Benutzeroberfl che entspricht dem Mediator Entwurfsmuster GHJV95 Im Vergleich zum f r diesen Zweck ebenfalls h ufig eingesetzten Observer Entwurfsmuster hat dieser Ansatz den Vorteil dass keinerlei Abh ngig keiten zwischen Benutzeroberfl che und Produktmodell auftreten Um zu einem T Model Objekt das entsprechende T GUI Objekt wiederzufin den und umgekehrt st tzen sich die Aktionen auf die Klasse ObjectTable des Pakets Map ab die ein Verzeichnis f r die Zuordnung zwischen T GUI und T Model Objekten bereitstellt mehr dazu weiter unten Die Anbindung der werkzeugspezifischen Pakete T Model T GUI und T Actions an das generische Framework erfolgt ber die korrespondierenden Pakete GenericModel GenericGUI und GenericActions Diese Pakete definieren die Variationspunkte des Frameworks in Form abstrakter oder semiabstrakter Klas sen deren Schnittstellen virtuelle Methoden den generischen Framework Pake ten bekannt sind und die in den werkzeugspezifischen Paketen verfeinert bzw implementiert werden m ssen Der ContextManager realisiert einen Interpreter f r den werkzeugrelevanten Anteil des Umgebungsmodells d h er gleicht Benutzerinteraktionen Produkt und Kommandoselektionen mit den Kontextdefinitionen ab und steuert die Ausf hrung von Ausf hrungs und Entscheidungskontexten siehe A
401. n Anwendungen Basissystemen und den Menschen anzupassen die diese Projekte durchf hren Dene93 S 164 In der Praxis wird jedoch beklagt dass CASE Umgebungen zu inflexibel sind und nur wenig Spielraum f r Anpassungen und Erweiterungen lassen EmFi96 JaHu98 Vielmehr orientieren sich die Hersteller von CASE Umgebungen h ufig eng an den Vorgaben popul rer Methodenhand b cher z B Rational Rose f r UML JaBR99 und kodieren diese fest in ihre Werkzeuge Die Flexibilisierung von Entwurfsumgebungen wurde in den vergangenen 15 Jahren aus unterschiedlichen Perspektiven untersucht Produktorientierte Anpas sungsmechanismen sind Gegenstand der Forschung im Bereich Methodengestal tung method engineering HoVe97 Harm97 Roll97 So genannte MetaCASE Umgebungen oder CASE Shells z B MetaEdit KeLR95 Kogge EbSU97 MetaView SoTM88 bieten Metamodell basierte Interpretations und Generie rungsmechanismen mit deren Hilfe Werkzeugumgebungen relativ einfach an geanderte oder neue Modellierungskonzepte und notationen angepasst werden k nnen Hier liegen mittlerweile ausgereifte L sungsans tze vor so dass wir den produktorientierten Aspekt der Anpassbarkeit in dieser Arbeit nicht weiter vertie fen werden und uns auf prozessbezogene Aspekte konzentrieren Zwischen Prozessen und Entwicklungswerkzeugen existiert eine enge Wech selwirkung JaBR99 JaJa95 Mont94 Mart98 Zum einen erm glichen Werkzeuge Wechselwirkung zwi ii
402. n B und Marquardt W PRO ART CE An Environment for Managing Chemical Process Simulation Models In Proc 10th Euro pean Simulation Multiconference Budapest Hungary 1996 S 1012 1016 D mges R Projektspezifische Methoden zur Nachvollziehbarkeit von Anforderungsspezifikati onen Dissertation RWTH Aachen 1999 Donohoe P Hrsg Software Architecture Proceedings of the 1st Working IFIP Conference on Software Architecture Klawer Academic Publishing Boston 1999 D mges R und Pohl K Adapting Traceability Environments to Project Specific Needs Communications of the ACM 41 12 S 54 62 1998 Dorling A SPICE Software Process Improvement and Capacity dEtermination Informa tion and Software Technology 35 6 7 S 404 406 1993 Douglas J Conceptual Design of Chemical Processes McGraw Hill 1988 Dowson M Software Process Themes and Issues In Proceedings of the 2nd Interna tional Conference on the Software Process Berlin Germany IEEE Computer Soci ety Press 1993 S 54 62 DrHM98 DrHM98 EAMP97 EBLA96 EbOO94 EbSt93 EbSU97 Ecke95 ECMA93 EdEd98 EgKM00 EIA 94 EiMC97 EINa99 EmFi96 Emme95 Emme96 Eng 92 Engl97 ErPe98 EsBa98 EsCB98 Literaturverzeichnis 285 Dr schel W Heuser W und Midderhoff R Hrsg Inkrementelle und objektorientierte Vorgehensweisen mit dem V Modell 97 Oldenbourg Verlag M nchen Wien
403. n den Werkzeugen gemeinsam verwendeten Informationen nicht nur auf die eigent lichen Daten beschr nken sondern auch Metadaten verwendete Datenschemata z B spezielle Datensatz und felddefinitionen Metametadaten verwendete Datenmodelle d h erlaubte Formate f r Datensatz und Felddefinitionen usw umfassen Durch die integrierte Verwaltung von Daten unterschiedlicher Ebenen unterscheiden sich Repositories von Data Dictionary Systemen die typischerweise nur Metadaten d h Datenbankschemata verwalten Prinzipiell impliziert der Begriff eines Repositories keine Beschr nkung der Anzahl der Metaebenen Aller dings konnten Kotteman und Konsynski KoKo84 zeigen dass vier Ebenen ausreichen um sowohl die Verwendung und als auch Evolution eines Entwurfs In formationssystems in integrierter Weise ad quat erfassen zu k nnen Eine hnliche Beobachtung liegt auch der Architektur des ISO Information Resource Dictionary Standard IRDS IRDS90 Byrn96 zugrunde die in Abb 9 dargestellt ist Entwicklungs Abb 9 umgebung Integration von definiert Schema f r definiert Schema f r definiert Schema f r Ziel der IRDS Architektur ist die Verkn pfung von Daten ber eine verteilte Benutzung von Anwendungssystemen mit den Daten ber die verteilte Entwicklung IRD Definition Schema Level IRD Schema Level IRD Level EN EDD IRD Application Level Anwendungs umgebung 1
404. n in generischen Anzeige Werkzeugen wie z B dem Pro duktmodell Editor und Abh ngigkeitseditor verf gt Das relationale Schema wird anschlie end durch das Paket ER Model die ER Editor spezifische Auspr gung des Pakets T Model verkapselt Dieses Paket implementiert eine objektorientierte Zugriffsschicht auf das Produktmodell Die Anbindung an ein relationales Daten 222 Abb 61 Produktmodell des ER Editors 7 Das PRIME Rahmenwerk banksystem st tzt sich auf Hilfsklassen im Paket ER DBInterface ab Dieses Paket spezialisiert die allgemeinen Anfrageklassen im Paket Generic DBInterface und realisiert die ER Editor spezifischen SQL Updates und Anfragen Product ExternalName ER_Object ER_Attribute Type ER_IsALink 0 described_by ER_Diagramm 1 1 0 1 m addEntity ER_Entity 0 ER_Relationship addRelationship addlsALink se a addAttribute contects_entity connects_relationship N E ER_Role 0 Tmin 2 n max Benutzeroberfl che Im Paket ER GUI wird die ER Editor spezifische Benutzeroberfl che realisiert Das Framework stellt f r diesen Zweck im Paket Generic GUI schon einen Gro teil der ben tigten Funktionalit t bereit Dazu geh rt die Erzeugung von Standarddi alogen sowie des Hauptfensters das entsprechend der
405. n und Aktionen die den Versand von Nachrichten nach sich ziehen sind fett gedruckt 7 2 Interaktionsprotokoll zwischen den Prozessdomanen 187 Zustand Aktivitat Standard Context Active adaptUItoStandardContext acceptUserInput matchContext Choice Context Active adaptUItoChoiceContext c acceptUserInput matchContext Executable Context Active result c execute External Context Requested disableUserInput EC Active on Ext Request result c execute CC Active on External Re quest adaptUItoChoiceContext c result c execute Waiting for Lock Request disableUserInput Waiting for Context Request disableUserInput Requested EC Active result c execute Requested CC Active adaptUItoChoiceContext c result c execute Abort Requested lStarted disableUserInput Aktion create Bedingung bStartedByUser lStarted bStartedByUser create Tab 10 Detailspezifikation der Werkzeug Zust nde und Transitionen aus Abb 44 false textMatched c c Contexti and c Tool result c execute textMatched c c Context and c Tool result c execute ContextExecuted c result ContextMatched c c Contexti c Context and c Tool send ExternalECCCRe quest c ExternalECCCResponse c result ContextMat
406. n EK Komponenten zu einer Kompromissl sung entschlos sen die die Nachteile der oben skizzierten Ans tze weitestgehend vermeidet Hierbei schlie t die Ausf hrung einer EK Komponente wie beim letztgenannten L sungsansatz nicht nur die Benutzerauswahl sondern auch die Ausf hrung der gew hlten Alternative ein Wir verlangen jedoch nicht mehr dass die Ausgangs schnittstellen der Alternativen jeweils eine Spezialisierung einer einzigen Ausgangs schnittstelle der bergeordneten EK Komponente darstellen m ssen Stattdessen erlauben wir dass aus Sicht einer verwendenden PK Komponente eine EK Kom ponente nicht nur eine sondern mehrere Ausgangsschnittstellen besitzen kann die genau den Ausgangsschnittstellen der Alternativen entsprechen Je nach Benutzer auswahl wird zur Laufzeit dann die zur ausgew hlten Alternative geh rige Aus gangsschnittstelle aktiv Damit eine EK Komponente zur Modellierungszeit an den Datenfluss innerhalb einer verwendenden PK Komponente angeschlossen werden kann muss garantiert werden dass sie die Ausgangsschnittstellen aller enthaltenen Alternativen umfasst Dies l sst sich formal durch folgende O Telos Regel sicherstellen MetaClass EK Verhaltenskomponente isA Verhaltenskomponente with attribute alternative Kontextkomponente rule berechneAusgang forall vk EK Verhaltenskomponente kk Kontextkomponente s Schnittstelle vk alternative kk and kk Ausgang s gt vk Ausgang s
407. n Ent scheidungskontext schl gt wenigstens zwei Alternativen zur Umsetzung der Benutzerintention in der gegebenen Situation vor Bei der Auswahl einer alternati ven Vorgehensweise findet im Allgemeinen eine Verfeinerung der urspr nglichen Intention und oder der Situation statt Daher werden die Alternativen in rekursi ver Weise selbst wieder als Kontexte modelliert Im Prozessmetamodell werden die Vorgehensalternativen daher durch die Assoziationsklasse Alternative zwi schen Entscheidungskontext und Kontext modelliert Diese Klasse steht ber die pro und kontra Assoziationen zus tzlich in Beziehung mit der Klasse Argument Argumente k nnen zur Beratung des Benutzers bei der Vorgehensauswahl zus tz lich angegeben werden Im Gegensatz zu Automatisierungskontexten haben Ent Alternativen und Argu mente 5 4 Modellierung von Werkzeugen 117 scheidungskontexte keine unmittelbaren Auswirkungen auf das in Entwicklung befindliche Produkt Plankontexte definieren eine aus mindestens zwei Teilschritten bestehende Strategie zur Erf llung einer Intention in einer gegebenen Situation Um einen Plankontext umzusetzen m ssen die einzelnen Teilschritte in einer vorgegebenen Reihenfolge abgearbeitet werden hnlich wie bei Entscheidungskontexten werden die Teilschritte selbst wieder rekursiv als Kontexte modelliert ber die Assoziation hat _Subkontext Anders als Entscheidungskontexte die den Entwickler bei der Vorgehensauswahl beraten unte
408. n Kontexten entspricht einer Oder Verkn pfung w hrend die Assoziation zwischen einem Plankontext und seinen Subkontexten mit einer Und Verkn pfung korrespondiert Ausf hrungskontexte bilden die Bl tter eines aus einer Kontexthierarchie gebilde ten Und Oder Baums 5 4 Modellierung von Werkzeugen 5 4 1 Ziele und Anforderungen Wie in Abschnitt 5 2 motiviert wurde existieren zwischen den Diensten die im Prozessmodell definiert werden und den Werkzeugen die dem Entwickler in einer Entwurfsumgebungen zur Verf gung stehen eine Reihe von Querbez gen Um diese Querbez ge explizit zu machen und eine Zuordnung zwischen Prozessfrag menten und unterst tzenden Werkzeugfunktionalit ten zu erreichen m ssen Werkzeuge zun chst auf der gleichen konzeptuellen Ebene modelliert werden wie Prozesse Poh 99 Aus den in Abschnitt 3 3 aufgestellten Anforderungen lassen sich drei wesentliche Aspekte ableiten die in einem Werkzeugmodell erfasst wer den m ssen O Produktmodell Im Prozessmodell Abschnitt 5 3 werden bestimmte Konstellationen der in Entwicklung befindlichen oder bearbeiteten Pro 118 5 Integrierte Prozess und Werkzeugmodelle dukte als situativer Bestandteil des Kontextbegriffs referenziert Innerhalb der Durchf hrungsdom ne interagiert der Entwickler in erster Linie ber seine Entwurfswerkzeuge mit dem zugrunde liegenden Produktmodell Um die Datenintegration siehe Anforderung Al Abschnitt 3 3 2 mit dem Prozessmodell zu
409. n Prozess und Werkzeugmodell des ER Editors wurde bereits in Abschnitt 5 6 bei der Beschrei bung der Metamodelle vorgestellt Komplexere Abl ufe die die Funktionalit t des ER Editors projekt oder or ganisationsspezifisch erweitern oder anpassen werden mithilfe von Plankontexten modelliert Abb 62 zeigt ein Beispiel f r einen solchen als SLANG Netz model lierten Plankontext Dieser Plankontext definiert methodische Anleitung bei der Verfeinerung eines Entit tstypen im Rahmen eines Vorgehensmodell zur Struktu rierten Analyse Your89 Die Idee des Ablauf besteht darin m glicherweise von der Verfeinerung betroffene Elemente im korrespondierenden Daten flussdiagramm aufzusp ren und gegebenenfalls anzupassen E ay to be Abb 62 ubtyped BS 2 Plankontext ftir die konsistente Verfeinerung eines Entitatstypen Source Object TargetType SuperEntity ede PC_Subtype_ Entity EC_GetDependent Objects DFD Elemens Source Object CC_Select_ DFD_Element DFD DFD Elements Elements PC_Adapt EC_AddTo No Change Quit DFD_Element Tasklist Required Adaptation Der Ablauf sieht vor dass nach der Verfeinerung eines Entit tstypen durch Sub typisierung mithilfe des eingebetteten Plankontexts PC_SubtypeEntity zun chst ermittelt wird ob im zugeh rigen Datenflussdiagramm bestimmte Elemente von dem verfeinerten Entit tstypen abh ngen mithilfe des Ausf hrungskontexts EC GetDependentObjects der vom Abh ngigkeit
410. n Seite k nnen die Hand lungen der Prozessausf hrenden dergestalt eingeschr nkt oder gar automatisiert werden dass die Konformit t der Prozessdurchf hrung mit dem Prozessvorgaben des Prozessunterst tzungssystems garantiert wird In diesem Fall spricht man von einem sehr strikten Durchsetzungsgrad enforcement level der Prozessunterst tzung 24 2 Prozessorientierte Unterstutzungsfunktionen Auf der anderen Seite kann sich die Prozessunterst tzung auf das Erteilen von Ratschl gen beschr nken die aus dem aktuellen Prozesszustand deduziert werden Innerhalb des Spektrums der m glichen Arten der Prozessunterst tzung unter scheidet man im allgemeinen vier verschiedene Unterst tzungsmodi DoFe94 GaJa96a Fern93 Pohl96 passive Prozessberatung aktive Prozessanleitung Prozesslenkung und Prozessautomation Passive Passive Prozessberatung liefert dem Prozessausf hrenden auf Anfrage Informati Prozessberatung onen dar ber welche Handlungen er ausf hren sollte um den Prozessvorgaben der Prozessunterst tzung konform zu bleiben Eine extrem eingeschr nkte Form der passiven Prozessanleitung w re beispielsweise die Bereitstellung eines Hand buchs der organisationsweiten Entwicklungstichtlinien und prozeduren Unter Zuhilfenahme von Informationen ber den aktuellen Prozesszustand kann die passive Prozessberatung kontextsensitive Ratschl ge geben die den aktuellen Prozesszustand ber cksichtigen z B eine Liste der als n chstes m g
411. n darauf operierenden spezifischen Entwurfswerkzeugen und den zu unter st tzenden Prozessfragmenten abstrahiert Die PRIME Architektur identifiziert die Hauptkomponenten einer prozessintegrierten Modellierungsumgebung deren Beziehungen zueinander sowie deren interne Strukturierung in wiederverwendbare und in spezifische Teilsysteme Abschnitt 7 1 gibt einen ersten berblick ber die Hauptkomponenten der PRIME Architektur und deren Zusammenspiel Prozessmodellkonformes Verhalten der Werkzeuge wie es in Abschnitt 3 3 ge fordert wurde setzt eine Synchronisation zwischen der Leitdom ne und der Durchf hrungsdom ne voraus In Erg nzung zur statischen Architektursicht definieren wir daher ein Interaktionsprotokoll das den dynamischen Abgleich der Prozesszust nde zwischen den Prozessdom nen durch den Austausch von Nach richten beschreibt Abschnitt 7 2 Realisiert wurde die PRIME Architektur in Form eines objektorientierten Implementierungs Frameworks das die generischen Anteile einer prozessintegrierten Modellierungsumgebung als vorgefertigte Software Komponenten bereitstellt und anwendungsspezifische Erweiterungen an wohldefinierten Variationspunkten er laubt Das Gesamt Framework zerf llt dabei in ein Werkzeug Framework und ein Prozessmaschinen Framework In Abschnitt 7 3 beleuchten wir das Werkzeug Framework genauer Abschnitt 7 4 besch ftigt sich mit der Weiterentwicklung des Werkzeug Frameworks zu einem generischen Wrapper f r exter
412. n der Leitdom ne steht mit dem GARPEM Framework ein generischer Rahmen f r die Integration spezifischer Prozessspracheninterpreter zur Verf gung Das GARPEM Framework wurde am Beispiel der Einbettung eines SLANG und eines UML Statechart Interpreters validiert 245 246 7 Das PRIME Rahmenwerk Beide Sub Frameworks des PRIME Ansatzes sind durch die gemeinsam ge nutzten Anteile des Umgebungsmodells sowie ber das in diesem Kapitel be schriebene Interaktionsprotokoll aufeinander abgestimmt Somit ist die komplette Integration zwischen den Prozessdom nen bereits auf Framework Ebene vorweg genommen Der Umgebungsentwickler braucht sich somit nicht mehr um die schwierige architekturelle und technische Integration zwischen Modellierungs Leit und Durchf hrungsdom ne zu k mmern sondern muss lediglich die Fra meworks an den daf r vorgesehenen Variationspunkten um spezifische Funktio nalit t anreichern Eine Reihe von vordefinierten Entwicklungs und Metamodel lierungswerkzeugen erleichtern ihm die Arbeit zus tzlich 8 1 Entwicklungshistorie 247 Kapitel Anwendungen mehrerer Werkzeug Umgebungen erfolgreich eingesetzt und validiert In diesem Kapitel geben wir zun chst einen kurzen berblick ber die Entwicklungshistorie des PRIME Rahmenwerks und seiner Anwendungen Ab schnitt 8 1 und gehen dann genauer auf die verfahrenstechnische Entwurfsumge bung PRIME IMPROVE ein Abschnitt 8 2 Eine Beispielsitzung illustriert den Umgan
413. n eine Reihe unterschiedlicher Vorgehensweisen denkbar sind Im Kontext der Strukturierten Analyse schlagen beispielsweise McMenamin und Palmer im Gegensatz zu einem strikten Top Down Vorgehen die so genannte Ereignispartitionierung vor bei der zun chst alle Ereignisse die auf das System einwirken zu identifizieren sind und danach durch Grup pierung von Stimuli und Systemreaktionen eine Partitionierung des Ge samtsystems vorzunehmen ist McPa84 Die methodische Arbeitsplatzunterst tzung muss also sowohl Produktaspekte Ontologie und Notation als auch Prozessaspekte ber cksichtigen Es f llt auf dass sich sowohl bei kommerziellen Methoden z B SA SADT UML etc als auch in der akademischen Forschung ber Methodengestaltung vgl z B 2 1 Ein Klassifikationsmodell fur Prozessunterstutzungsfunktionen 15 BrLW96 Brin96 Roll97 Odel96 BrLW96 LyWe99 das Interesse prim r auf den Produktaspekt beschrankt Wije91 Lyy 98 In dieser Arbeit werden wir uns mit den Aspekten Ontologie und Notation nur soweit befassen wie es die Abhan gigkeit der Prozesse von den Produkten prinzipiell bedingt und konzentrieren uns stattdessen auf methodische Unterst tzung im Sinne einer Prozessanleitung f r die korrekte und effiziente Verwendung von Modellierungskonstrukten einer oder mehrerer Methoden Die in der Arbeitsumgebung zur Verf gung stehenden rechnerbasierten Werk zeuge Editoren Analysewerkzeuge Transformatoren etc mit deren Hilfe
414. n je nach Programmiererfahrung nach ein bis zwei Wochen Einarbeitungszeit in der Lage eigenst ndig ein Werkzeug zu implemen tieren oder ein bestehendes zu erweitern Weiterhin zeigte sich dass die Werkzeugmodellierungskonzepte und deren Verkn pfung zu Ausf hrungs und Entscheidungskontexten zur Definition pro zessintegrierter Werkzeuge grunds tzlich ausreichen Die Definition komplexer Abl ufe innerhalb des Prozessmodells zwang die Werkzeugentwickler Prozesswis sen explizit zu machen und so das Prozess im Werkzeug Syndrom Mont94 zu vermeiden Die Kontextgebundenheit von Benutzereingaben bei Entscheidungs kontexten reduziert m gliche Fehleingaben des Benutzers auf ein Minimum so dass nur schr wenige Konsistenzchecks explizit ausprogrammiert werden mussten Als nicht ganz unproblematisch erwies sich jedoch die Festlegung der richti gen Granularit t der elementaren Werkzeugaktionen die als atomare Bausteine auf der Prozessmodellierungsebene miteinander verschaltet werden k nnen Hier war bisweilen die Tendenz zu beobachten den kompletten Methodenvorrat des internen werkzeugspezifischen Produktmodell in Form von Aktionen der Pro zessmodellierung zug nglich zu machen um h chstm gliche Adaptabilit t auf Prozessmodellierungsebene zu garantieren Bei einer derart feinen Granularit t besteht jedoch die Gefahr dass ein gro er Teil der Werkzeugprogrammierung auf die Ebene der Prozessmodellierung verlagert wird Prozessmod
415. n kann w hrend Multi bedeutet dass das Werkzeug ber Multi User F higkeiten verf gt und von mehreren Benut zern gleichzeitig bedient werden kann Queue legt fest dass zu einem Zeitpunkt nur eine Aufgabe in einem Werkzeug durchf hrt werden kann w hrend bei No Queue ein Werkzeug simultan in mehreren unterschiedlichen Aufgaben verwendet werden kann Die Queue bzw NoQueue Eigenschaft wird im Wesentlichen zur ck gef hrt auf die F higkeit eines Werkzeugs lediglich einen oder mehrere Doku ment Buffer gleichzeitig verwalten zu k nnen analog zur Unterscheidung zwi schen Single Document Interface Applikationen SDI und Multiple Document 3 3 Integrationsanforderungen in prozessintegrierten Umgebungen 91 Interface Applikationen MDI im Windows MFC Rahmenwerk Wichtig ist dass eine direkte Interaktion zwischen dem Wrapper und dem Werkzeug sobald das Werkzeug erst einmal gestartet wurde nicht vorgesehen ist Stattdessen wird der Benutzer ber ein separates Dialogfenster ber Aktionen informiert die er in einem laufenden Werkzeug dann manuell vornehmen muss Wenn beispielsweise gem der Prozessmodellausf hrung die in einem Werkzeug aktuell bearbeitete Aufgabe gewechselt werden soll beim NoQueue Modus wird der Benutzer ber ein Informationsfenster angewiesen im betreffenden Werkzeug den aktuellen Dokument Buffer zu tauschen Der f r ein Werkzeug bzw f r eine Aufgabe spezifische Inhalt des Informationsfensters wird innerh
416. n m ssen spezielle Vor und Nachbereitungsma nahmen f r ei nen externen Werkzeugaufruf getroffen werden so dass ein direktes Durchreichen Vor und Nachbereitung d die Betti ich N des Werkzeugaufrufs es Call Exec Statements an die etriebssystemebene nicht ausreicht Aus diesem durch Wrapper Grund sehen viele Ans tze die Kapselung von Werkzeugen durch Werkzeugum schl ge so genannte Envelopes oder Wrapper vor JaBu96 B hm98 Anstatt das 3 3 Integrationsanforderungen in prozessintegrierten Umgebungen 89 Werkzeug direkt zu referenzieren wird im Call Statement der entsprechende Wrapper angegeben und bei der Ausf hrung der zugeh rigen Aktivit t gestartet Beispielsweise muss ein Wrapper in den F llen in denen die Prozessmaschine und das Werkzeug nicht auf einem gemeinsamen Repository f r die Produktdaten arbeiten bei der Blackbox Integration ist dies fast immer der Fall die im Repo sitory abgelegten Produktdaten vor dem Werkzeugstart zun chst in einen Arbeits bereich transferieren auf den das Werkzeug Zugriff hat Meist geschieht dies in der Form dass die betreffenden Dokumente aus dem Repository kopiert und in einem vorher spezifizierten Pfad des Dateisystem abgelegt werden Analog ist der Wrapper daf r verantwortlich modifizierte oder neu erzeugte Dokumente nach der Werkzeugausf hrung in das Repository zur ckzuspielen Au er zur Daten versorgung des aufgerufenen Werkzeugs werden Wrapper manchmal auch zu wei
417. n sinnvoll interpretiert werden wei dargestellt Daneben greifen die vorgefertigten Framework Erweiterungen die standardm ig Teil jeder PRIME basierten Umgebungen sind Hypertext Entscheidungs und Abh ngigkeits Editor sowie sprachspezifische Plankontext Interpreter auf die hellgrau dargestellten Repository Bereiche zu Das Schema der generischen Repository Schicht besteht aus den Teilschemata Prozessmodell Werkzeugmodell Umgebungsmodell und Produktmodell und realisiert die in den Kapiteln 5 und 6 definierten konzeptuellen Metamodelle Die generischen Interpreter Komponenten der Werkzeug und Prozessmaschinen Frameworks sowie der Kommunikationsmanager greifen ausschlie lich auf die hier abgelegten Informationen zu 24 Beachte in diesem Kontext hat die Differenzierung zwischen generischen und spezifischen Repository Anteilen nichts mit den unterschiedlichen Klassifikationsebenen eines Repositories im Sinne der IRDS Architektur zu tun Schema und Instanzebene werden in Abb 34 nicht explizit unterschieden 181 Abb 42 Der prozessintegrierte PRIME Umgebungsmo dell Editor 182 Formalisierung des Interaktionsprotokolls durch gekoppelte UML Zustandsdiagramme Freie und angeleitete Prozessdurchf hrung 7 Das PRIME Rahmenwerk 7 2 Interaktionsprotokoll zwischen den Prozess dom nen Das integrierte Umgebungsmodell aus Abschnitt 5 5 legt inh rent die Verantwort lichkeiten f r die Ausf hrung von Kontexten z
418. n sollen z B die Modifikation eines Entwurfsobjekts Zur Durchsetzung der Prozessvorgaben sind daher zu s tzliche organisatorische Ma nahmen der Qualit tskontrolle erforderlich z B die Durchf hrung von Inspektionen Reviews und Walkthroughs Faga76 Faga86 EbSt93 FrWe82 Fowl86 Bias91 Prozessintegrierte Werkzenge unterst tzen den Benutzer indem sie ihre Arbeits Prozessintegrierte weise direkt den projekt und organisationsspezifischen Prozessvorgaben unter Werkzeuge ordnen Prozessdurchf hrung und anleitung werden ber die gleiche Benutzer schnittstelle n mlich die der prozessintegrierten Werkzeuge abgewickelt Da dem Entwickler in prozessintegrierten Werkzeugen immer nur die Entwurfsprodukte mit entsprechenden Aktionen zur Bearbeitung angeboten werden die gem der Prozessvorgabe zur Erreichung des aktuellen Prozessziels zweckdienlich bzw zul ssig sind wird der intendierte Arbeitsprozess direkt in den eigentlichen Ent wurfswerkzeugen sichtbar und wirksam siche Abb 2c Der Entwickler wird somit von der Aufgabe entlastet die gem den Prozessvorgaben in einer Prozess situation zul ssigen Aktionen selbst zu bestimmen Bestimmte Routineaufgaben lassen sich als komplexe Sequenzen von Werkzeugaktionen sogar automatisieren siehe auch Abschnitt 2 1 5 Wir wollen an dieser Stelle nur die generelle Unterscheidung zwischen exter ner rechnerbasiert separater und rechnerbasiert prozessintegrierter Prozessunter st tzu
419. n von ER Diagrammen ist es beispielsweise wichtig ob sich im aktuellen ER Diagramme noch unverbundene Entit tstypen befinden Eine Alternative zu beiden vorgenannten Integrationsarten besteht darin dass die Daten von Fremdwerkzeugen ber Transformatoren oder die oben bespro 68 3 Integrationsansatze chenen Integrationswerkzeuge auf feingranularer Ebene in das Prozess Repository abgebildet werden Zusammen mit Werkzeugen die ihre Daten direkt im Reposi tory ablegen erg be sich dann die in Abb Abb 10c dargestellte Situation Datenmodellierung Die Daten in einem Repository k nnen nach unterschiedlichen Datenmodellen strukturiert sein Es lassen sich unter anderem folgende Kategorien von Datenmo dellen unterscheiden Q Relational im relationalen Datenmodell werden Daten als Tupel in Tabel len strukturiert Q Graphbasiert graphbasierte Ans tze bilden Objekte als attributierte Kno ten und Beziehungen zwischen Objekten als Kanten eines Graph ab Ein h ufiges Einsatzgebiet graphbasierter Datenmodelle und Datenbanken KiSW95 ist die Abbildung abstrakter Syntaxb ume Eng 92 And 99 O Objektorientiert Objektorientierte Datenmodelle Cat 00 KeMo93 er weitern Modellierungskonzepte wie Objektidentit t Kasperung von Struk tur und Verhalten Vererbung und Polymorphie um den Aspekt der Per sistenz Strukturell objektorientierte Datenmodelle wie z B PCTE Wa Jo93 und STEP Express ISO 94 aus dem ingenieurwissenschaftlic
420. n zu initiali sieren Typische Funktionen sind hier Zuweisungs und Vergleichsoperationen sowie Konstruktorfunktionen f r Felder und Listen Diese Basisfunktionen sind f r viele Prozesssprachen identisch und werden vom Interpreterrahmenwerk 238 Transformation der Situationsdaten Factory Framework gesteuerte Erzeugung spezifischer Sprachele ment Objekte 7 Das PRIME Rahmenwerk weitgehend sprachneutral bereitgestellt so dass hier der Wiederverwendungsgrad hoch ist Aktivit ten sowohl zusammengesetzte als auch atomare Aktivit ten haben ei ne Schnittstelle die durch die Klasse Interface repr sentiert wird Ein Interface ist allgemein f r die Produktdaten Ein und Ausgabe einer Aktivit t verantwortlich und im Speziellen f r die Transformation von Daten in das sprachspezifische Format des Fragments zust ndig Wie bereits in Abschnitt 6 3 1 erl utert ent spricht ein Interface einer Aktivit t der Stellvertreterschnittstelle einer AK EK oder PK Kontextkomponente Dabei ist die Ausf hrung einer Aktivit t an die Ausf hrung eines Kontextes in der PRIME Umgebung gebunden Bei der Aus f hrung wird eine Transformation zwischen der Prozesssprachen spezifischen Darstellung der aktuellen Situationsdaten in die PRIME spezifische Darstellung vollzogen Dazu werden die aktuellen Schnittstellenparameter in das sprachneut rale Format der PRIME Umgebung transformiert versandt und auf der Empf n gerseite wieder entschl ssel
421. nager R ckmeldungen Prozess mo dell Instanziier ung Prozesssteuerung und berwachung Prozess maschine Prozess modell interpretation Leitdom ne Zusammen mit den traditionellen Arbeitsplatzwerkzeugen lassen sich somit drei konzeptuelle Aufgabenbereiche oder Prozessdom nen innerhalb einer prozesszentrierten Umgebungen voneinander abgrenzen DoFe94 Pohl96 die Modellierungsdomane engl Process Modeling Domain die Leitdom ne engl Process Enactment Do main und die Durchf hrungsdom ne engl Process Performance Domain O Die Modelherungsdomane umfasst alle Aufgaben Konzepte Notationen und Mechanismen f r die Erstellung und Pflege von Prozessmodellen Dort finden Aktivit ten wie Spezifikation Entwurf Implementierung Wieder verwendung Anpassung Analyse Wartung Verwaltung und Verbesserung von Prozessmodellen statt Neben den eigentlichen Prozessmodellen wer den auch die Daten ber die Prozessausf hrung insbesondere die entste henden Produkte in der Modellierungsdom ne verwaltet Q Die Letdom ne umfasst alle Aktivit ten und Mechanismen zur Prozessun terst tzung auf Basis der in Modellierungsdom ne bereitgestellten Pro zessmodelle Verk rpert wird die Leitdom ne durch eine Prozessmaschine die die Laufzeitumgebung f r instanziierte Prozessmodelle bereitstellt Durch dynamische Fortschreibung des Ausf hrungszustand des Prozess modells ist die Pr
422. nd aus Platz gr nden nicht f r jedes UML Konzept die korrespondierenden O Telos Definiti onen auff hren Vielmehr beschr nken wir die Verwendung von O Telos prim r 16 Weitergehende Information zur O Telos Sprachdefinition sind in Jeus92 oder JaJQ99 zu zu finden 5 2 Motivation fur integrierte Prozess und Werkzeugmodelle 111 f r die Formulierung spezieller Integritatsbedingungen Regeln und Anfrageklas sen die im UML Modell nicht darstellbar sind Einzelheiten ber die modellie rungstechnischen Zusammenh nge zwischen der UML und O Telos sind in Grun99 zu finden 5 2 Motivation f r integrierte Prozess und Werk zeugmodelle Die in Kapitel 3 aufgestellten Anforderungen an eine Integration der Prozessdo m nen insbesondere die in Abschnitt 3 3 4 geforderte Aonzeptuelle Beschreibung von Werkzengdiensten die auf der gleichen konzeptuellen Ebene wie die Prozessmodel lierung angesiedelt ist motiviert eine integrierte Betrachtung von Prozessen und Werkzeugen Bei der Entwicklung eines integrierten Prozess und Werkzeugmo dells lassen wir uns von der Grund berlegung leiten dass wir die Kernaspekte der Separierung von pro Prozesse und Werkzeuge zun chst unabh ngig voneinander in spezifischen Teil zessrelevanten und modellen erfassen Diese Vorgehensweise hat den Vorteil dass wir in einem ersten Werkzeuginh renten P ee Aspekten Schritt Prozesse unabh ngig von einer konkret gegebenen Werkzeugumgebung modelli
423. nd nach der Werkzeugausf hrung Ausgabedaten und Sta tus Codes die Aufschluss ber den Erfolg der Werkzeugdurchf hrung ge ben entgegengenommen werden k nnen Blackbox Integration eignet sich nur f r Batch artig arbeitende Werkzeuge wie Compiler Linker etc deren Aktivierungsdauer eineindeutig einem atomaren Prozessschritt entspricht Bohm98 Bei interaktiven Werkzeugen z B Editoren Browser Analyse werkzeuge stellt ein wiederholtes Starten eines Werkzeugs bei jeder An forderung einer Werkzeugfunktion durch die Prozessmaschine in der Regel 2 ECMA European Computer Manufacturers Association 3 NIST National Institute of Standards and Technology 3 2 Integrationsvoraussetzungen 53 eine schlechte Losung dar Dies liegt zum einen an den in der Regel nicht vernachl ssigbaren Anfstartzeiten interaktiver Werkzeuge und zum anderen am inkrementellen Interaktionsstil in solchen Werkzeugen also der sukzessiven Weiterbearbeitung eines einmal geladenen Dokuments und seines komple xen internen Zustands durch den Benutzer berdauert jedoch ein inter aktives Werkzeug die Dauer des Prozessschritts f r dessen Unterst tzung das Werkzeug von der Prozessmaschine aufgerufen wurde verliert die Leitdom ne die Kontrolle ber die Benutzeraktivit ten in diesem Werk zeugen und kann eine definitionskonforme Prozessdurchf hrung nicht mehr sicherstellen B hm98 EmFi96 AnGr94 siehe auch Abschnitt 3 3 5 O Greybox Integration Hier steh
424. nd oder Dateninkonsistenzen f hren w rde Ist der angeforderte Abbruch unzul ssig sendet die Prozessmaschine eine AbortDenied Nachricht an die Durchf hrungsdom ne und kehrt in den zuvor unterbrochenen Sub Zustand von Running zur ck Transition 11 Andernfalls stoppt die Prozessmaschine die Plankontext Ausf hrung sendet eine AbortOK Nachricht an das anfragende Werkzeuge sowie eine EndOfEnactment Nachricht 190 Kommunikationsmana ger kapselt Details der Nachrichtenverteilung Abb 46 Weiterleitung einer GuidanceRequest Nachricht 7 Das PRIME Rahmenwerk an die brigen Werkzeuge und geht in den Zustand Process Fnactment Inactive uber Die Zustande und Transitionen des Prozessmaschinen Zustandsdiagramms sind in Tab 11 mit Detailangaben ber die assoziierten Aktivit ten bzw Ereignis sen Bedingungen und Aktionen aufgelistet Die dem Nachrichtenempfang oder versand entsprechenden Ereignisse und Aktionen sind fett gedruckt 7 2 3 Rolle des Kommunikationsmanagers Die Zustandsdiagramme die das Verhalten von Werkzeugen und Prozessmaschine beschreiben sind wechselseitig ber den Austausch von Nachrichten gekoppelt d h der Versand einer Nachricht in der Durchf hrungsdom ne l st ein Ereignis in der Leitdom ne aus und umgekehrt Allerdings kommunizieren Werkzeuge und Prozessmaschine nicht direkt miteinander sondern sind durch einen zentralen Kommunikationsmanager voneinander abgeschottet Der
425. ndung einer geeigneten Prozessmodellierungs sprache MDKW99 Prozessmodelle bilden die Grundlage f r die Verbreitung von Prozesswissen Entwurf neuer Prozesse Wiederverwendung und Anpassung existierender Prozesse Auswahl zwischen alternativen Prozessen Ausf hrung von Prozessen und die Erfassung und Analyse von Informationen ber abgelaufene Prozesse Huff96 CuKO92 CoJa99 DeKW99 FIKN94 Diese Aktivit ten re flektieren die unterschiedliche Phasen des Lebenszyklus eines Entwicklungspro Ziele der Prozessmodel zesses und dienen drei wesentlichen Zielen die in Publikationen ber Prozessmo lierung dellierung immer wieder genannt werden CuKO92 Dows93 Huff96 Fugg96 FiKN94 GaJa96 O Erh hung des Prozessverst ndnisses und Erleichterung der Kommunika tion ber Prozesse U Prozessverbesserung O Rechnerbasierte Prozessunterst tzung Im Kontext dieser Arbeit konzentrieren wir uns auf den letztgenannten Aspekt die Realisierung prozessmodellbasierter Unterst tzungsdienste in einer Entwick lungsumgebung 2 2 4 2 Konzeptueller Aufbau prozesszentrierter Entwick lungsumgebungen In prozesszentrierten Entwicklungsumgebungen PZEUen bilden explizite Pro zessmodelle die Grundlage f r die anpassbare rechnerunterst tzte Steuerung des Entwicklungsprozesses Entsprechend den Vorgaben aus den Prozessmodellen Prozessmaschine greifen so genannte Prozessmaschinen beratend lenkend oder automatisierend in die Arbeitsproze
426. ndung relevanten Daten ad quat repr sentiert oder auf administrative Attribute z B ob ein Doku ment einen Review erfolgreich passiert hat oder ob es sich in berarbeitung befin det Neben rein produktbezogenen Zustandsattributen spielen zur Bestimmung des aktuellen Prozesskontexts auch die bisherige Prozesshistorie die sich zum Teil nat rlich im Produktzustand widerspiegelt und die aktuell verfolgten Prozessziele eine entscheidende Rolle Au erdem rechnen manche Ans tze auch den Erfah rungsstand des Entwicklers der die Prozessunterst tzung anfordert zum Prozess kontext Hilfesysteme werden beispielsweise danach unterschieden ob sie uni forme d h f r jeden Entwickler einheitliche oder individuelle d h auf die spezifi schen F higkeiten des Entwicklers zugeschnittene Unterst tzungsleitungen erbrin gen Balz96 BaSc88 Wir werden in Abschnitt 5 3 noch genauer auf die zur Cha rakterisierung eines Prozesskontextes relevanten Aspekte eingehen wenn wir den in dieser Arbeit verfolgten kontextbasierten Prozessmodellierungsansatz vorstel len 2 1 Ein Klassifikationsmodell fur Prozessunterstutzungsfunktionen 21 2 1 4 Anpassbarkeit Eine wichtige Voraussetzung f r die Akzeptanz eines Prozessunterst tzungsansat Prozessverbesserung zes ist seine Anpassbarkeit an organisations und projektspezifische Gegebenhei erfordert Anpassbarkeit ten Das Wissen ber Entwicklungsprozesse ist heutzutage selbst in vergleichs weise gut verst
427. ne wi w3 Wa Werkzeug Werkzeug Werkzeug Werkzeugtabelle EC CC N Instanz Kategorie Scope Aufrufer esponse result Kommunikations A Py Ja f manager A Po nein N Werkzeug Tabelle Umgebungs modell x 5 Se 7 Context EC CC Pe Request Response result 4 c receiver Prozess maschine Zu beachten ist dass hierbei die Prozessmaschine bzw der Modellierer des Plan kontexts keinen Einfluss darauf hat welche von m glicherweise mehreren in Frage kommenden Werkzeuginstanzen zur Laufzeit eine ContextRequest Nach richt erh lt Die Erfahrung bei der Modellierung von Plankontexten hat jedoch gezeigt dass die an sich w nschenswerte vollst ndige Abstraktion von den Werk zeuginstanzen in manchen Modellierungssituationen zu Problemen f hrt und stattdessen eine ablaufinharente Unterscheidung zwischen mehreren Instanzen der gleichen Werkzeugkategorie erforderlich ist Die in einem Plankontext eingebetteten Subkontexte k nnen daher mit optio naler Empf ngerinformation versehen werden die einer ContextRequest Nach richt als zus tzliches receiver Attribut bergeben und vom Kommunikationsma nager bei der Nachrichtenverteilung ausgewertet wird Dabei sind die folgenden logischen Adtessierungsarten erlaubt O0 callingTool die ContextRequest Nachricht soll an die Werkzeuginstanz bermittelt werden die den aktuell ausgef hrten Plankontext aktiviert hat Der Kommunikationsmanager f
428. ne Entwurfsergebnisse auszutauschen Weiterhin muss bei der wechselseitigen Bearbeitung berlappender Datenbest nde daf r gesorgt werden dass die werkzeug bergreifende Integrit t der Daten kon trolliert und gegebenenfalls gesichert wird Mit der Datenintegration innerhalb einer prozessintegrierten Entwurfsumgebung verfolgt man also zwei prim re Ziele Dateninteroperabilitat und Datenkonsistenz Abschnitt 3 3 2 3 3 1 2 Kontrollintegration Gegenstand der Kontrollintegration sind Anfrufmechanismen zar unmittelbaren Aktivierung und Steuerung von Werkzeugdiensten ohne dass dazu direkte Ein griffe des Benutzers erforderlich sind und Norifkationsmechanismen mit denen ein Werkzeug andere Komponenten der Entwurfsumgebungen ber nderungen seines Zustands informieren kann Wass90 ThNe92 BCTW96 Brow93 Hierzu ist neben dem reinen Austausch von Entwurfsdaten etwa ber den Im und Ex port von Dateien oder ber ein gemeinsam genutztes Repository eine direkte Interaktion zwischen den Werkzeugen untereinander sowie mit der Prozessma schine zum Austausch von Kontroll und Zustandsinformationen erforderlich Kontrollintegration Die Dimension der Kontrollintegration betrachtet also vor allem dynamische Prozessintegration Aspekte der Steuerbarkeit des Werkzeugverhaltens und steht damit in direktem Zusammenhang mit dem Kernziel der Prozessintegration In der Tat werden in manchen Publikationen die Grenzen zwischen Kontroll und Prozessintegr
429. ne Frage des Informationsmanagements ScBr93 Kern der dahinter stehenden Vision einer integrierten Umgebung ist die Forderung dass die Ent wurfsumgebung dem Entwickler bei seinen allt glichen T tigkeiten einen unmit telbaren und unkomplizierten Zugriff auf jede ben tigte Information erm glichen soll Die effiziente und situative Bereitstellung der richtigen Entwurfsobjekte zum richtigen Zeitpunkt wird als Schl sselfaktor zur Steigerung der Produktivit t ange sehen H ufig werden Hypertext Metaphern d h das Navigieren und St bern Browsing entlang miteinander in Beziehung stehender Informationseinheiten verwendet um die Arbeitsweise in solchen Umgebungen zu charakterisieren Repository zentrierte Auf Architekturebene wird der Integrationsgedanke durch ein so genanntes Sichtweise auf Repository verk rpert welches das R ckgrat der Entwurfsumgebung bildet In dem integration Repository werden alle anfallenden Entwurfsobjekte erfasst strukturiert und zueinander in Beziehung gesetzt seien es Anforderungsmodelle Entwurfsspezifi kationen Software Bausteine Testpl ne oder auch weiche Informationseinhei ten wie Besprechungsprotokolle oder Entwurfsentscheidungen Das Repository erm glicht es den Werkzeugen Informationen in Form von Entwurfsergebnissen auszutauschen Die Suche nach geeigneten Strukturierungskonzepten d h Daten modellen f r Entwurfsdaten deren effiziente technische Verwaltung durch Non Standard
430. ne Werkzeuge In Abschnitt 7 5 beschreiben wir das Prozessmaschine Framework Abschnitt 7 6 fasst die wesentlichen Resultate dieses Kapitels zusammen 22 PRIME Process Integrated Modeling Environments Kapitel 167 168 Merkmale der Frame work basierten Soft wareentwicklung Variationspunkte Architektur Wiederver wendung ftihrt zu Kontrollinversion 7 Das PRIME Rahmenwerk 7 1 Die PRIME Gesamtarchitektur In diesem Abschnitt betrachten wir PRIME zun chst aus der Vogelperspektive Einer Diskussion der zugrunde liegenden generellen Entwurfsphilosophie Ab schnitt 7 1 1 folgt ein grober berblick ber die wesentlichen Architekturbau steine in der Durchftihrungs Leit und Modellierungsdom ne Abschnitt 7 1 2 7 1 1 Framework basierter Entwurfsansatz Vor einer Diskussion der einzelnen Architekturkomponenten wollen wir zun chst kurz auf die generelle Entwurfsphilosophie eingehen die dem PRIME Ansatz zugrunde liegt Wie in der Einleitung zu diesem Kapitel bereits angedeutet wurde ist PRIME selbst noch nicht direkt als spezifische prozessintegrierte Entwurfsum gebung verwendbar sondern stellt vielmehr ein generisches objektorientiertes Frame work zur Verf gung mit dessen Hilfe auf verh ltnism ig einfache und schnelle Weise prozessintegrierte Umgebungen f r unterschiedliche Entwurfsdom nen entwi ckelt werden k nnen Allgemein fassen Frameworks das Wissen ber Funktionsweisen und archi tekturelle Str
431. nen sich f r eine komponentenbasierten Modellie rungsansatz da sie jeweils die M2 Konzepte Aktivit t Schnittstelle und Datenbe halter instanziieren Damit wurde gezeigt dass Kontextkomponenten sprach ber greifend verwendet werden k nnen so dass aus Modellierungssicht die Interope rabilit t von verschiedensprachlichen Prozessfragmenten gew hrleistet ist In diesem Kapitel wurde die szatische Interoperabilit t von Prozessmodellierungsspra chen in der Modellierungsdom ne betrachtet Dynamische Aspekte der interope rablen Ausf hrung verschiedensprachlicher Prozessfragmente werden sind Ge genstand von Abschnitt 7 5 wenn wir uns mit der Integration der Interpreter in der Leitdom ne und dem Entwurf des Interpreterrahmenwerkes besch ftigen 163 Teil 3 Umsetzung und Anwendungserfahrungen 165 Teil 3 Umsetzung und Anwendungserfahrungen 7 Das PRIME Rahmenwerk Das PRIME Rahmenwerk seinem Design stehenden Entwurfs berlegungen Das PRIME Rahmenwerk ist ein Architekturvorschlag f r prozessintegrierte Umgebungen der die in Kapitel 3 erhobenen Anforderungen an eine engere Integration zwischen den Prozessdom nen umsetzt und auf den in den Kapiteln 5 und 6 vorgestellten Mo dellierungsans tzen basiert diesem Kapitel beschreiben wir das PRIME Rahmenwerk und die hinter PRIME ist generisch in dem Sinne dass es von der Entwurfsdom ne einer Modellierungsumgebung und damit von den zugrunde liegenden Produktmodel len de
432. nforderung Interpretation des Umgebungsmodells aus Abschnitt 7 3 1 Der ContextMana ger baut seine internen Laufzeitdatenstrukturen komplett aus den im Prozess Repository abgelegten Modellen auf Das bedeutet insbesondere dass der Con textManager Produkte Intentionen und Aktionen ausschlie lich ber die entspre chenden eindeutigen Identifikatoren im Prozess Repository referenziert und nicht direkt auf den Model GUI und Action Klassen eines spezifischen Werkzeugs operieren darf Dies erfordert zwar eine zus tzliche Indirektion zwischen dem ContextManager und den werkzeugspezifischen Klassen erm glicht uns jedoch den ContextManager als vollst ndig generisches Teilsystem zu realisieren Die Indirektion wird durch die drei Verzeichnisklassen ObjectTable Intenti onTable und ActionTable realisiert die im Paket Map angesiedelt sind Diese Klas sen verwalten die Korrespondenzen zwischen den logischen Repository Identifi katoren und den entsprechenden Laufzeit Objekten eines spezifischen Werkzeugs In der ActionTable registrieren sich die T Action Objekte eines Werkzeugs und k nnen vom ContextManager ber die korrespondierenden Identifikatoren des Umgebungsmodells aufgefunden und aktiviert werden Dadurch ben tigt der ContextManager keinen hartkodierten Bezug zu den werkzeugspezifischen T Action Klassen In der ObjectTable werden Informationen ber die aktuell geladenen Produkte in Instanzen der Klasse ObjectDescriptor verwa
433. ng Das GARPIT Framework wurde wie das gesamte PRIME Framework komplett in C realisiert Die Wahl der Programmiersprache wurde zum Zeitpunkt der initialen Entwicklung des Frameworks im Wesentlichen durch die haupts chlich in C verf gbaren APIs der verwendeten Fremd Software Client Bibliotheken der Datenbankmanagementsysteme GUI Bibliotheken Kommunikationsbibliothe ken allgemeine Containerbibliotheken diktiert Mittlerweile w re sicherlich auch Java eine berlegenswerte Alternative Als Systemplattform diente zun chst Unix Solaris 2 7 sp ter dann Windows NT 4 0 Das Prozessrepository wurde auf Basis der relationalen Datenbankmanagementsysteme Sybase 10 MS SQL Server 7 und MS Access 2000 realisiert Zur Oberfl chenprogrammierung haben wir das por table GUI Toolkit ILOG Views sowie teilweise die Microsoft Foundation Classes unter Windows NT verwendet Die Interprozesskommunikation wurde in unter schiedlichen Varianten realisiert zum einen elementar auf Basis von BSD Sockets unter Unix bzw WinSock unter Windows und zum anderen mithilfe von Sun s Message Server Produkt ToolTalk sowie mithilfe der CORBA Implementierung omniORB Tab 14 gibt einen berblick ber die Pakete des PRIME Rahmen werks Insgesamt umfassen die generischen Anteile des GARPIT Frameworks ca 84 000 Zeilen ausf hrlich kommentierten C Code Tab 14 Gr e der GARPIT Teilsysteme Programmieren per Vertrag Assoziations Templates Generi sche
434. ng in Spezialisierungshierarchie Sortiere P p px so dass gilt Vrs E 1 k r lt s gt Typ p lt Typs der Situationsteilinstanz s werden die ersten min Instanzen in P zugeordnet Si P firstElements min P P P firstElements min else forall Phase 2 Bindung der verbliebenen Produktinstanzen forall ri 1 lt k lt m co Liste von Produktinstanzen passenden Typs in P zusammenstellen P p P Typ p lt S Ti det rj te Situationsteil kann noch maximal max min Produktinstanzen von T aufnehmen if P lt max min s append P P P P else Sip append P irstElements maxi min P P P firstElements maxi min else forall if P 6 return S Sm else es konnten nicht alle Produktinstanzen zugeordnet werden return false 7 3 GARPIT ein Framework f r prozessintegrierte Werkzeuge 217 Der Algorithmus l uft in zwei Phasen ab Im ersten Durchgang wird versucht jedem Situationsteil 7 genau min Produktinstanzen eines passenden Typs zuzu ordnen Falls dies gelingt versucht der Algorithmus in der zweiten Phase die verbliebenen Produktinstanzen so auf die Situationsteile r aufzuteilen dass deren max Kardinalitat nicht berschritten wird In beiden Phasen iteriert der Algorith mus je einmal ber alle Situationsteile Da insbesondere in der ersten P
435. ng nicht genutzt Zwar k nnen extern vorliegende Prozessanweisungen und richtlinien durchaus kon textbezogen formuliert sein vgl Abschnitt 2 1 3 aber es liegt in der Verant wortung des Entwicklers zu erkennen welche Arbeitsschritte gem den Vorga ben der externen Prozessunterst tzung legal und sinnvoll sind und in welchen Situationen sie angewandt werden sollen oder m ssen Zwar k nnen die Prozess ausf hrenden selbstverst ndlich jederzeit ihr Wissen ber Details der intendierten Prozessausf hrung auffrischen aber es unterliegt ihrer Initiative kritische Prozess situationen als solche zu erkennen und entsprechende Vorgehensempfehlungen und Richtlinien nachzuschlagen Der Hauptvorteil rechnerbasierter Ans tze d h separater Assistenzwerkzeuge oder prozessintegrierter Entwurfswerkzeuge besteht darin dass der Entwickler einen im Vergleich zu externer Prozessunterst tzung wesentlich direkteren und kom fortableren Zugang zu den verf gbaren Prozessdefinitionen erh lt Weiterhin liefern rechnerbasierte Ans tze berhaupt erst die Grundvoraussetzung daf r dass nderungen an Prozessdefinitionen ohne gro en Aufwand in die Arbeitsumge 2 1 Ein Klassifikationsmodell fur Prozessunterstutzungsfunktionen 19 bungen aller betroffenen Prozessausf hrenden propagiert werden k nnen und dort sofort sichtbar sind siehe auch Abschnitt 2 1 4 Bei separaten Assistenzwerkzeugen k nnen Prozessdokumentationen beispiels Separate w
436. ng vornehmen Konkrete Auspr gungen von Prozessunterst tzungssyste men unterschiedlicher Integrationstiefe werden wir bei der Untersuchung existie render Ans tze in Abschnitt 2 2 noch detaillierter betrachten 2 1 3 Kontextbezogenheit Ein wichtiges Kriterium f r die G te eines Prozessunterst tzungssystems ist seine Kontextbezogenheit Kontextbezogenheit ist ein Ma daf r wie stark eine Unterst t 20 2 Prozessorientierte Unterstutzungsfunktionen zungsleistung zum Zeitpunkt der Anforderung durch den Entwickler bzw des Eingreifens in den Arbeitsprozess auf die aktuelle Prozesssituation zugeschnitten ist Wir unterscheiden hier szatische Prozessunterst tzungsans tze die unabh ngig von der aktuellen Prozesssituation stets die gleiche Unterst tzung anbieten und dynamische Prozessunterst tzungsans tze die die tats chliche Prozesssituation ber cksichtigen und die im aktuellen Kontext irrelevanten oder nicht anwendbaren Teile der Prozessunterst tzung herausfiltern bzw eine allgemeine Assistenzfunk tion konkretisieren Bei der Differenzierung zwischen statischer und dynamischer Prozessunter st tzung ist es weniger entscheidend dass ein Prozessunterst tzungsansatz prinzi piell Vorgehenswissen bez glich unterschiedlicher Prozesssituationen bereith lt Vielmehr interessiert inwieweit das Unterst tzungssystem den Benutzer von der Last befreit die aktuelle Prozesssituation mit den Randbedingungen der Prozess vorgaben durch
437. ngangsschnittstelle FROM ER Relationship WERBEN HELM Ze dd Mi Ausgangsschnittstelle UNION SELECT r to S FROM ER Relationship Implementierung WHERE r to e id Verhaltenskomponente Ebenso wie Situationskomponenten verf gen Verhaltenskomponenten ber eine Ein und Ausgangsschnittstelle die aus einer Menge von getypten In bzw Out Produktteilen besteht Verhaltenskomponenten haben einen transformierenden Charakter so dass grunds tzlich keinerlei struktureller Bezug zwischen den Ein und Ausgangsschnittstellen gefordert wird Wie bereits eingangs dieses Kapitels erl utert h ngt die Implementierung der Verhaltenskomponente von der Kon textkategorie ab und ist bei Ausf hrungs und Entscheidungskontexten schon vollst ndig auf der Ebene des Umgebungsmetamodells spezifiziert Bei Plankon texten stellt die Spezifikation einer Ablaufreihenfolge in einer wahlfreien Sprache die Implementierung dar Kontextkomponente Eine Kontextkomponente aggregiert eine Situationskomponente und eine Verhal tenskomponente Die aus Verwenderperspektive sichtbare u ere Schnittstelle einer Kontextkomponente wird durch die Eingangsschnittstelle der Situations komponente und die Ausgangsschnittstelle der Verhaltenskomponente gebildet siehe Abb 27 Intern werden Situations und Verhaltenkomponente miteinander verkn pft indem die Out Produktteile der Situationskomponente auf die In Pro duktteile der Verhaltenkomponente abgebildet werden Die Ausgang
438. ngineering Addison Wesley 1992 Sorenson P G Tremblay J P und McAllister A J The MetaView System for Many Specification Environments IEEE Software 5 2 S 30 38 1988 Srinivasan S Design Patterns in Object Oriented Frameworks Computer S 24 32 Feb 1999 Stallman R M Emacs The Extensible Customizable Self Documenting Display Editor SIGPLAN SIGOA Symposium on Text Manipulation Special Issue of SIGPLAN Notices 16 6 S 147 156 1981 Suchman L Plans and Situated Actions The Problem of Human Machine Communication Press Syndicate of the University of Cambridge 1987 Sullivan K Kalet I und Notkin D Evaluating the Mediator Method Prism as a Case Study IEEE Transactions on Software Engineering 22 8 S 563 579 Aug 1996 Sullivan K und Notkin D Reconciling Environment Integration and Component Independ ence ACM Transactions of Software Engineering and Methodology 1 3 S 229 268 July 1992 Sunsoft Too Talk and Open Protocols Inter Application Communication SunSoft Press Prentice Hall Englewood Cliffs NJ 1993 Szyperski C Component Software Beyond Object Oriented Programming Addison Wesley 1998 ace Tann94 TeRc88 ThMa97 ThNe92 Tho 97 ThTh97 Tolv98 Tull91 VaKa96 VD1 90 VeM 97 Vest93 Vest96 W3C 98 WaJo93 WALM99 Wand93 Warb90 Wass90 WaZZ93 WeBa99 Weid95 WFMC96 WFMC98a Literaturverzeich
439. nis 297 Tannenbaum A Implementing a Corporate Repository John Wiley amp Sons New York 1994 Teitelbaum T und Reps T The Cornell Program Synthesizer A Syntax Directed Pro gramming Environment ACM SIGPLAN Notices 14 10 S 75 95 1988 Thomson H E und Mayhew P Approaches for Software Process Improvement Software Process Improvement and Practice 30 S 3 17 Mar 1997 Thomas I und Nejmeh B Definitions of Tool Integration for Environments IEEE Software 9 2 S 29 35 1992 Thompson D Watkins D Exton W Garrett L und Sajeev A S M Distributed Component Object Model In Kr mer B Papazoglou M und Schmidt H W Hrsg Information Systems Interoperability Research Studies Press Tauton Somerset England 1997 S 39 75 Thayer R H und Thayer M C Software Engineering Project Management Glossary In Thayer R H Hrsg Software Engineering Project Management IEEE Computer Society Press 1997 S 506 529 Tolvanen J P Incremental Method Engineering with Modeling Tools Dissertation Univer sity of Jyvaskyla 1998 Tully C J Software Process Issues in Software Engineering Environments In Long F Hrsg Software Engineering Environments Ellis Horwood 1991 S 1 19 Valetto G und Kaiser G E Enveloping Sophisticated Tools into Process Centered Environ ments Journal of Automated Software Engineering 3 S 309 345 1996 VDI VDI Richtlinie 5005 Software Ergon
440. nittstellen Gem den in Abschnitt 7 3 1 formulierten Anforderungen an das GARPIT Framework muss ein prozessintegriertes Werkzeug 1 das Umgebungsmodell interpretieren Ausf hrung von angeforderten Entscheidungs und Ausf hrungs kontexten sowie Erkennung von Kontextaktivierungen und 2 das Interaktions protokoll mit der Leitdom ne zwecks Synchronisation des Prozesszustands reali sieren Ein Werkzeug das ohne Kenntnis des PRIME Ansatzes entwickelt wurde wird diese Anforderungen per se nicht erf llen k nnen Daher muss es geeignete Schnittstellen anbieten damit es dennoch durch einen Wrapper kontrolliert und in seiner Arbeitsweise den Vorgaben aus der Modellierungs und Leitdom ne unter worfen werden kann Da die Prozessmaschine bzw der Prozessintegrations Wrapper mit dem zu in F 22 Inkrementell nutzbare tegrierenden Werkzeug inkrementell zur Laufzeit interagiert muss das Werkzeug aufzeit API erforderlich ber offene programmierbare Lawfzeit Schnittstellen APIs application program ming interfaces verf gen Eine Schnittstelle die lediglich den entkoppelten Zugriff auf die Werkzeugdaten etwa durch Export in ein propriet res oder auch standardisiertes Format erm glicht ist nicht ausreichend Das Werkzeug muss zum einen sein Objektmodell ber eine entsprechende API ffnen Aus dieser API k nnen das Produktmodell und die darauf operieren den Aktionen abgeleitet werden und innerhalb des Werkzeugmodells nachmodel
441. nnamen die in den externen Situationsspezifikation Yon Bedingungsausdr referenziert werden dynamisch an die entsprechenden T Model Attribute und ne Methoden zu binden In C ist dies jedoch nur mit erheblichem Zusatzaufwand schwierig und auf sehr ineffiziente Weise m glich da dies letztendlich in einer kompletten Abbildung der statischen Klassenstruktur in Laufzeit Typobjekte resultieren w r de Wesentlich geeigneter w ren hier Implementierungsplattformen die Me chanismen zur dynamischen Introspektion und Reflexion von Haus aus anbieten wie z B Java Tycoon Matt93 oder das Dynamic Invocation Interface von COR BA Diese Technologien waren jedoch zum Zeitpunkt der Erstellung des PRIME Frameworks nicht verf gbar oder schieden aus anderen Gr nden aus siehe auch Abschnitt 7 3 3 Implementierung F r den Verzicht auf die Spezifikation zu s tzlicher Situationsbedingungen waren also weniger konzeptionelle als vielmehr implementatorische Gr nde ausschlaggebend Es hat sich jedoch bei unseren Beispielanwendungen herausgestellt dass der Verzicht auf die Referenzierung von Attributen und Methoden in der Praxis keine gro e Rolle spielt 214 Abb 58 Grundstruktur des Matchingalgorithmus 7 Das PRIME Rahmenwerk Matching Algorithmus F r die Situationserkennung m ssen die Situationstypen der Alternativen des aktuell aktiven Entscheidungskontexts EK mit der Menge P der selektierten Pro duktinstanzen in der Produktregion ein
442. nneennnnnennennnennnennnnnn 117 5 42 PRIME TM Das Werkzeugmetamodell eseeeeeeseenneeeneeenenen 118 5 5 Integration der Modelle 0ss0s0us0000uesonssesnnsssnnnsnonnssnnssssnnnsssnnnsnnne 120 5 5 1 Ziel des Umgebungsmodells 00 0 0 ee eececseeseeeceeeneeesceeseeceecnsecneenteeneenes 120 5 5 2 PRIME UM Das Umgebungsmetamodell uneenenennnnn 121 5 5 2 1 Abbildung von Ausf hrungskontexten auf Werkzeugkategorien 121 5 5 2 2 Abbildung von Entscheidungskontexten auf Interaktionselemente 124 Inhaltsverzeichnis 5 6 Beispiel fiir ein Umgebungsmodell sssssscssssccccscescessssersscsseseeees 127 5 7 PAZ A E EEE EEEE EEE EE E A EAE E EEE 129 6 INTEROPERABILIT T VON PROZESSSPRACHEN cecseeeeees 131 6 1 Motivation eursssssssssorssonssonssonssonsssnnssnnssnnssnnssnnssnnssnnnsnnnsnnnsnnnsnonsssnsssnnsnannne 131 6 2 Interoperabilit t in prozessbasierten Systemen scssccsscsssesseones 133 6 2 1 Standards a een nee nis heisst 134 6 2 1 1 WEMC Referenzmodell sseseseenseenseenseennennnnsnnnnnenn nennen 134 6 2 1 2 Austauschforma te renier e i e EEr E 135 6 2 2 F derierte Interoperabilit tsans tze nessessenseenseensennnennn nennen 138 6 2 2 1 ProcessWall Ansatz uuneesseesseessnssnssnnesnnsnennenneennennnennnnnnnnnnnenn 138 6 222 APEL ornans eo essen des A eE a AaS 138 6 2 3 Prozesskomponenten cccccesccesscesecessceeeceeeeeeseceseeese
443. norientierte Darstellung des NATURE Prozessmodells 149 MetaClass Kontextkomponente isA Prozesskomponente with constraint korrekteKopplung forall kk Kontextkomponente sk Situationskomponente sa Schnittstelle pta Produktteil t Typ kk hat_Situationskomponente sk and sk Ausgang sa and sa hat_Produktteil pta and pta hat_Typ t gt exists k Kopplung vk Verhaltenskomponente se Schnittstelle pte Produktteil kk hat_Verhaltenskomponente vk and vk Eingang se and se hat_Produktteil pte and kk hat Kopplung k and k Situation out pta and k Verhalten in pte and se hat Typ t end Aus Verwendungssicht ist nur die n ere Schnittstelle einer Kontextkomponente relevant Diese ergibt sich aus der Eingangsschnittstelle der Situationskomponente und der Ausgangsschnittstelle der Verhaltenskomponente und kann durch zwei O Telos Regeln berechneEingang und berechneAusgang hergeleitet werden MetaClass Kontextkomponente isA Prozesskomponente with attribute necessary hat _Situationskomponente Situationskomponente hat_Verhaltenskomponente Verhaltenskomponente rule berechneEingang forall sk Situationskomponente s Schnittstelle this hat _Situationskomponente sk and sk Eingang s gt this Eingang s berechneAusgang forall vk Verhaltenskomponente s Schnittstelle this hat _Verhaltenskomponente vk and vk Ausgang s gt this Ausgang s end
444. notationellen Darstellung definiert die Semantik der Notation Je nach Anwendungs zweck ist eine Notation und ihre Beziehung zur zugrunde liegenden kon zeptuellen Struktur mehr oder weniger formal definiert W hrend Notatio nen die mehr auf das menschliche Verst ndnis und die Kommunizierbar keit von Systemaspekten ausgelegt sind eher auf einen rigorosen formalen Unterbau verzichten k nnen ist eine formale Semantik unerl sslich um bestimmte Eigenschaften eines mit einer Methode erstellten Systemmo dells Vollst ndigkeit Korrektheit Erreichbarkeit etc berpr fen und de duzieren zu k nnen QO Prozess Neben der Festlegung einer Ontologie und einer Notation ist methodisches Vorgehen am Arbeitsplatz insbesondere an das Befolgen prozeduraler Handlungsrichtlinien und heuristiken die mit einer Methode assoziiert sind gekn pft Der Prozessaspekt einer Methode gibt vor wie und in welcher Reihenfolge die gegebenen Konzepte und Notationsele mente zur Erstellung eines Systemmodells angewendet werden sollten Um sinnvolle Resultate zu liefern m ssen sich die Prozessrichtlinien an der konzeptuellen Struktur der Methode orientieren Zum Beispiel spiegelt sich das Konzept der Dekomposition innerhalb der Strukturierten Analyse in einem Modellierungsprozess wider der die Top Down Verfeinerung des Systemmodells beginnend bei dem Kontextdiagramm vorsieht Allerdings gibt die konzeptuelle Struktur nur einen groben Rahmen vor innerhalb desse
445. ns tze zur Interoperabilit t prozessbasierter Systeme und motivieren einen komponentenorientierten Ansatz in dem die Kon zepte des NATURE Prozessmetamodell als sprachneutrale Schnittstellenbeschrei bung heterogener in sich abgeschlossener Prozessfragmente fungieren In Ab schnitt 6 3 definieren wir ein auf dem NATURE Prozessmodell basierendes Meta modell zur Schnittstellenbeschreibung Gegenstand von Abschnitt 6 4 ist ein Bindungsmetamodell das den Zusammenhang zwischen den Konzepten des Schnittstellenmetamodells und den Konstrukten eines konkreten Ablaufformalis mus herstellt Weiterhin skizzieren wir die Schritte einer auf diesem Modell basie renden Sprachintegrationsmethodik und illustrieren diese anhand der Einbindung der Formalismen SLANG und UML Statecharts Abschnitt 6 5 fasst die wesentli chen Ergebnisse des Kapitels zusammen 6 2 Interoperabilit t in prozessbasierten Syste men Dieser Abschnitt gibt einen Literatur berblick ber existierende Interoperabilit ts ans tze mit denen der sprachliche Bruch zwischen unterschiedlichen Prozessmo dellierungssprachen berbr ckt werden kann Wir besch ftigen uns zun chst mit existierenden Standards f r die Interoperabilit t prozessbasierter Systeme gehen 134 6 Interoperabilitat von Prozesssprachen dann auf einige Vorschl ge f r f derative Integrationsans tze ein und betrachten die bertragung komponentenbasierter Spezifikationstechniken auf die Prozess modellierung Sc
446. nterst t zung ist statisch Es liegt in der Verantwortung des Entwicklers zu erken nen welche Arbeitsschritte gem den Vorgaben aus dem Handbuch le gal und sinnvoll sind und in welchen Situationen sie angewandt werden sollen oder m ssen Zwar k nnen die Prozessausf hrenden selbstver st ndlich jederzeit ihr Wissen ber Details der intendierten Prozessausf h rung auffrischen aber es unterliegt ihrer Initiative kritische Prozesssituati onen als solche zu erkennen und entsprechende Vorgehensempfehlungen und Richtlinien in Handb chern nachzuschlagen und zu befolgen O Anpassbarkeit Das in Handb chern niedergelegte Prozesswissen ist fix nderungen in organisations und projektspezifischen Prozessdefinition rufen offensichtliche Probleme hervor die Handb cher m ssen aktualisiert werden jeder von der nderung potenziell betroffene Prozessausf hrende muss von der nderung informiert werden Je nach Art der nderung sind gegebenenfalls erneute Trainingsma nahmen und Schulungen erforderlich O Unterst tzungsmodi Handb cher k nnen lediglich passive Prozessunter st tzung anbieten Ein aktives Eingreifen in den Arbeitsprozess ist wegen der nicht vorhandenen Kopplung mit den Komponenten einer rechnerba sierten Entwurfsumgebung nicht m glich 2 2 2 Hilfesysteme Hilfesysteme sind rechnergest tzte Systeme die den Benutzer durch explizite Erkl rungen und Ausk nfte beim Umgang mit der Mensch Computer Schnitt stelle
447. ntierte oder dokumenten objektorientierte Interaktionsparadigma unterschieden Balz96 Wand93 Beim werkzeug funktionsorientierten Ansatz aktiviert der Benutzer zun chst die f r einen Arbeitsschritt ben tigte Funktion bzw ein Werkzeug mit seinen Funktionen und bestimmt dann auf welchem Objekt oder welchen Objekten die Funktion angewandt werden soll Der Benutzer muss also wissen welche Werk zeuge die seinen Arbeitsschritt unterst tzenden Funktionen anbieten und wie in diesen Werkzeugen der Zugriff auf die zu bearbeitenden Dokumente oder Objekte erfolgt Werkzeug Funktionsorientiert Charakteristisch f r das dokumenten bzw objektorientierte Paradigma ist REED dass der Benutzer zun chst das zu bearbeitende Objekt ausw hlt Aus dem Typ Objektorientiert und Zustand des Objekts ergeben sich dann die m glichen Bearbeitungsfunktio nen die dem Objekt als Methoden zugeordnet sind F r den Benutzer tritt die Frage von welchem Werkzeug eine bestimmte Funktion abgeboten wird in den Hintergrund so dass er sich nicht mehr darum k mmern muss das geeignete Werkzeug auszuw hlen und zu aktivieren Das Hinzuf gen neuer Werkzeuge in die Arbeitsumgebung resultiert aus Benutzersicht in dem Erweitern des Angebots spektrums an verf gbaren Objekttypen und darauf ausf hrbaren Methoden z In Verbindung mit einer Prozesssteuerung kann ein prozesssensitives Interaktions Prozesssensitives Bens A Se Interaktionsparadigma Paradigma ver
448. ntstehenden Systembeschreibungen gilt eine rech nerbasierte Werkzeugunterst tzung f r den praktischen Umgang mit Analyse und p Unterst tzung durch Entwurfsmethoden mittlerweile als unverzichtbar Seit Mitte der 80er Jahre ent peghnerbasierte standen eine Vielzahl akademischer und kommerzieller Entwurfsumgebungen die Werkzeuge dem Entwickler so genannte CASE Werkzeuge oder allgemeiner CAx Werk zeuge zur Erstellung Verwaltung und Konsistenthaltung von Systemmodellen und implementierungen an die Hand geben 1 CASE Computer Aided Software Engineering 4 1 Einleitung CASE Umgebungen haben die hohen Erwartungen in Bezug auf Produktivi t tssteigerung und Qualit tsverbesserung h ufig nicht erf llen k nnen und den seit Anfang der 90er Jahre immer wieder prognostizierten Durchbruch noch nicht ganz geschafft Roth93 Iiva96 Als kritischer Schl sselfaktor f r den Erfolg von Mangelnde Anpassbar CASE Werkzeugen gilt deren Anpassbarkeit an organisations und projektspezifi keit und Prozessunter sche Bed rfnisse Denert hebt beispielsweise hervor dass Methoden des Soft E hae ware Engineering keineswegs so reif sind da man sie mit hohem Aufwand in chen Einsatz von CASE Werkzeuge einbrennen sollte Wir brauchen vielmehr eine Technik die es nicht Umgebungen prohibitiv teuer macht Methoden Sprachen Vorgehensweisen Werkzeuge etc weiterzuentwickeln mit ihnen zu experimentieren sie Unternehmen Projekte
449. nwendungen Abb 80 Ausf hrung des einge betteten Plankontexts PC_FBW_InspectRelate dObjects Abb 81 Entscheidungsrevision im Entscheidungseditor Gi Plan Context Editor PC_FBW_InspectRelatedObjects Document Edit Tools Preferences Help EC_DEP_getDependentProduct EC_DEP_expandProduct ChoiceContext CC_DEC_InspectDecision altl PC_DEC_ReviseDecision alt2 PC_DEP_ShowDependentObjects altN EC_Quit CC_DEP_SelectDepProduct CCAltemative 947 CCAltemative 4326 CCAlt CC_DEC_InspectDecision CC_HT_InspectHypertext Welcome to the PRIME plan context editor Die von der Prozessmaschine angeforderte Ausf hrung des Entscheidungskon texts CC_DEC InspectDecision startet den Entscheidungseditor mit dem ausge wahlten Entscheidungsobjekt Dieser Entscheidungskontext konfiguriert den Entscheidungseditor so dass der Benutzer das Entscheidungsdokument unveran dert lassen oder die getroffene Entscheidung revidieren kann H PRIHE Decision Editor Keine Modellierung des F D Gleichgewichts Peeing Edit Tools Preferences Help New Open Load choice context as decision inerung von Separatio Durch welche Gerate soll Separation verfeinert werden Revise decision e Modellierung des F C f Es wird vorgeschlagen den Prozessschritt durch eine Destillationskolonne zu verfeinern Show dependent objects a Quit erung durch Destill
450. nwerk Unrestricted Process Performance Guided Process Performance External Context Requested Abort Requested Requested EC Active EC Active Der Super Zustand Unrestricted Process Performance beschreibt das Werk zeugverhalten solange die Prozessdurchf hrung nicht durch eine Plankontext Interpretation angeleitet wird Dieser Zustand besteht aus einer Oder Verfeine rung in eine Reihe von Sub Zust nden deren wichtigster der Sub Zustand U ser Choice ist Der Zustand User Choice selbst ist seinerseits unterteilt in die Zust nde Choice Context Active und Standard Context Active die sich jedoch nur geringf gig voneinander unterscheiden In ersterem ist ein Entscheidungs kontext aktiv den der Benutzer zuvor aktiviert hatte Dagegen wird der Zustand Standard Context Active immer dann angenommen wenn dem Werkzeug die aktuelle Intention des Benutzers nicht bekannt ist Formal ist ein Standardkon text allerdings nicht anderes als ein Entscheidungskontext mit einer leeren Intention In beiden Sub Zust nden nimmt das Werkzeug Benutzerinteraktionen Selektion Deselektion von Produkten Aktivierung von Kommandos entgegen und gleicht diese mit den Intentions und Situationsdefinitionen der aktuell er laubten Alternativen ab Entsprechen die aktivierten Kommandos und Produkte der Intention und Si tuation eines vordefinierten Kontexts c wird ein ContextMatched c Ereignis ausgel st Dieses Ereignis initiiert einen von mehre
451. nzelnen Aufgaben z B Datenflussabh ngigkeiten wenn eine Aufgabe die Ergebnisse einer anderen Aufgabe als Eingabedokument ben tigt definieren eine partielle Ordnung zwischen den Aufgaben und bilden die Grundlage f r einen Terminplan in dem innerhalb der festgesetzten Projektdauer Aufgabenanfang und ende festgelegt werden Die Definition von Meilensteilen dient der Beurteilung des Projektfortschritts w hrend der Projektdurchf hrung Da im Projektmanage ment prim r administrative Ziele verfolgt werden wird die Aufgabenstruktur im Allgemeinen nur so weit verfeinert wie es f r die arbeitsteilige Zuordnung von Aufgaben an verschiedene technische Entwickler und deren Koordination erfor derlich und sinnvoll ist Die Internstruktur einzelner Aufgaben wird innerhalb des Projektmanagements nicht weiter betrachtet Ressourcen Im Rahmen der Ressourcenverwaltung und koordination ist das Projektmanagement a und zum einen f r die Festlegung einer Organisationsstruktur verantwortlich die die koordination Verantwortlichkeiten und Qualifikationen des im Projekt zur Verf gung stehenden Personals beschreibt und so eine Zuordnung von Aufgaben zu Prozessausf hren den erlaubt Zum anderen f llt die Beschaffung technischer Ressourcen und die Verwaltung und Koordination der erstellten Dokumente beziehungsweise deren Versionen und Konfigurationen in diesen Bereich Projektdurchf hrung Im Laufe der Projektdurchf hrung wird schlie lich auf Basis des P
452. nzeptuellen Entwurf verfahrenstechnischer Anlagen bertragen lassen JaMa96 Dies wurde anhand der Umgebung PROART CE einer um zus tzli 41 PROART Process and RepOsitory based Approach for Requirements Traceability 42 PROART CE Process and RepOsitory based Approach for Requirements Traceability Chemical Engineering 8 1 Entwicklungshistorie 249 che verfahrenstechnische Werkzeuge erweiterte Version der PROART Umgebung demonstriert D m 96 Bereits die Werkzeuge der PROART bzw PROART CE Umgebung waren in der Lage sich dynamisch an den aktuellen Prozesszustand anzupassen Das diesem Verhalten zugrunde liegende Prozesswissen lag jedoch nicht in Form expliziter Prozessmodelle vor sondern manifestierte sich in hartverdrahteten ber die einzelnen Werkzeuge verteilten Code Abschnitten Entsprechend aufw ndig PRIME 1 0 ee Bo Umsetzung der in gestaltete sich die Umsetzung von neuen Prozessen oder die nderung existie Kapitel 5 beschriebenen render Prozesse Das PRIME Framework in der Version 1 0 setzte erstmals den in Prozess und Werk Kapitel 5 beschriebenen integrierten Prozess und Werkzeugmodellierungsansatz zeugmodellierung um und vereinheitlichte dar ber hinaus die zwischen den urspr nglichen PRO ART Werkzeugen noch sehr heterogene Architektur in Hinblick auf Datenbank Benutzerschnittstellen und Kommunikationsanbindung Erfolgreich validiert wurde das PRIME 1 0 Framework mit der Re Implementierung der Werk
453. oben rechts 8 3 2 Ausf hrung eines Prozessfragments Nachdem wir im vorangegangenen Abschnitt die Modellierung des M Prozess fragments RefineProcessDeviceWithDecision aus Sicht des Methodeningenieurs betrachtet haben schl pfen wir nun in die Rolle des Verfahrensingenieurs der durch das M Prozessfragment bei der Verfeinerung eines VT Prozessbausteins angeleitet wird Das Beispiel betrachtet den Entwurf des Aufbereitungsteils Compounding ei ner Anlage zur Herstellung von Nylon Abb 77 zeigt den Flie bildeditor in dem 8 3 Beispielsitzung 265 der VT Prozessschritt Compounding in einer ersten Verfeinerung zu sehen ist Der Eingangsstrom des Aufbereitungsschritts stammt aus dem vorangeschalteten Reaktionsschritt und f hrt das gew nschte Endprodukt Nylon sowie nicht umge setzte Restanteile der Edukte Wasser und Capro Lactam CL mit sich Innerhalb des Aufbereitungsschritts wird zun chst ein Gro teil der Edukte Wasser und Capro Lactam mit Hilfe eines Wiped Film Evaporator abgetrennt und dann das verbleibende nur noch leicht durch CL verunreinigte Nylon in einem Extruder unter Beigabe von Zusatzsatzstoffen weiterverarbeitet Das im Wiped Film Evapo rator abgetrennte Wasser CL Gemisch Strom 21 wird durch einen weiteren Trennschritt Separation aufgespaltet um den teuren Ausgangsstoff CL wieder der Reaktion zur ckzuf hren w hrend das verbleibende Wasser als Abfallstoff abgef hrt wird Visio Technical PA6 Prozess 15 Demo
454. obigen Beispiel wird der Benutzer die generierte Tabelle im Allgemeinen um weitere Felder erweitern oder Datentyp und Formatdefinitionen existierender Datenfelder an seine Bed rfnisse anpassen Aufgabenspezifische Dialogf hrung Tab 5 gibt einen berblick ber die Charakteristika der von Assistenten und Interface Agenten gelieferten Prozessunterst tzung O Unterst tzte Projektebene Die von Assistenten geleistete Unterst tzung ist wie bei Hilfesystemen sehr stark auf den Umgang mit bestimmten 32 2 Prozessorientierte Unterstutzungsfunktionen Werkzeugen zugeschnitten Daher profitiert haupts chlich die technische Arbeitsplatzebene von der Unterst tzungsleistung durch Assistenten da die Arbeitsprozesse auf dieser Ebene wesentlich st rker als auf der Pro jektmanagementebene durch die Verwendung komplexer Werkzeuge ge pr gt ist Prinzipiell k nnen Assistenten allerdings auch Projektmanage mentprozesse unterst tzen wenn sie zum Beispiel den Umgang mit einem Projektmanagementwerkzeug vereinfachen QO Integrationstiefe Assistenten sind im Allgemeinen keine eigenst ndigen Komponenten einer aus heterogenen Entwicklungswerkzeugen bestehen den Entwicklungsumgebung sondern werden vom jeweiligen Werkzeug hersteller als integraler Bestandteil eines komplexen Werkzeugs oder einer eng integrierten Werkzeugsammlung entwickelt und vertrieben Von daher ist die von einem Assistenten gelieferte Prozessunterst tzung schr eng auf das jew
455. och nicht aus die einzelnen Arbeits und Entscheidungsschritte isoliert voneinander von den Werkzeugen aufzeichnen zu lassen Vielmehr m ssen auch die zeitlichen und logischen Abh ngigkeiten zwischen den einzelnen Schritten erfasst werden Hier ergibt sich das Problem dass die Prozessdurchf hrung ber die unterschiedlichen Werkzeuge der Durchf hrungsdom ne verteilt stattfindet und kein einzelnes Werkzeug ber eine globale Sicht auf die Abh ngigkeiten zwischen den einzelnen Kontextausf hrungen verf gt Auch die Prozessmaschine kommt hier als koordi nierende Komponente f r die Prozessspurenaufzeichnung nicht in Betracht da sie nur w hrend der Ausf hrung eines Plankontexts aktiv ist Werkzeug 1 Werkzeug 2 writeTrace EK 1 executed Aufgezeichnete Prozessspur Prozessspuren Server Prozessmaschine Trace Session writeTrace writeTrace IRRE PK 2 stopped writeTrace AK 3 AK 3 executed writeTrace AK 4 executed writeTrace AK 5 executed Logische Abh ngigkeiten gt zwischen Prozessschritten gt Weitergeleitete Schrittprotokollierung es gt Zus tzliche vom Prozessspuren Server protokollierte Schritt abh ngigkeiten Stattdessen zentralisiert der Prozessspuren Server den Dienst der Prozessspurenpro tokollierung Er nimmt von den Werkzeugen und der Prozessmaschine voneinan 7 1 Die PRIME Gesamtarchitektur der unabh
456. och die Semantik einer EK Komponente abh ngig vom Verwen dungspunkt da bedingte Verzweigung und Parallelit t eine unterschiedli che Bedeutung haben OQ EK Komponenten einerseits und AK bzw PK Komponenten anderer seits weisen eine unterschiedliche Schnittstellenstruktur auf Anders als bei AK und PK Komponenten w rde die Ausgangsschnittstelle einer EK Komponente nicht aus einer Menge getypter Produktteile f r die erzeugten oder modifizierten Produkte bestehen Stattdessen w re das Resultat der Ausf hrung einer EK Komponente die zur Laufzeit ausgew hlte Instanz einer Kontextkomponente und die Ausgangsschnittstelle h tte somit den Typ Kontextkomponente Sinnvoller erscheint daher eine zweite Interpretationsm glichkeit bei der der Ausf hrungsdienst einer EK Komponente die Benutzerauswahl einer Alternative und deren Ausf hrung vollst ndig kapselt Aus Verwendersicht ist demnach nur die Ein und Ausgangsschnittstelle einer EK Komponente sichtbar Diese Sicht weise hat jedoch zwei wichtige Folgerungen Q Am Verwendungspunkt einer EK Komponente ist nicht erkennbar wel che Alternative tats chlich ausgew hlt und ausgef hrt wird Eine EK Komponente muss also zur Laufzeit durch jede ihrer Alternativen substitu ierbar sein und es ist f r die weitere Prozessdurchf hrung unerheblich welche Alternative ausgew hlt und ausgef hrt wurde 6 3 Komponentenorientierte Darstellung des NATURE Prozessmodells 151 Q Um Substituierbarkeit
457. odell bzw das Umgebungsmetamodell jedoch in seiner bisherigen Form aus folgenden Gr nden ungeeignet O Schnittstellen und Implementierungsaspekte werden vermischt Beispiels weise ist es aus Sicht eines Verwenders unerheblich durch welche Aktion ein Ausf hrungskontext operationalisiert wird Solche Informationen sollte daher nicht in einem Metamodell zur Schnittstellenbeschreibung auftau chen bzw davon separiert werden O Kontexte verf gen in Form der assoziierten Situation zwar ber eine Ein gangsschnittstelle nicht jedoch ber eine explizit definierte Ausgangsschmittstelle Die Auswirkungen eines Kontexts sind im Falle eines Ausf hrungskon texts lediglich implizit ber die Ausgangsprodukte der assoziierten Aktion definiert Noch weniger offensichtlich sind die Ausgangsschnittstellen von Entscheidungs und Plankontexten die sich allenfalls aus den Effekten der Alternativ bzw Subkontexte rekursiv ableiten lassen Die nderung eines globalen Datenbestand und die dadurch induzierte implizite Aktivierung neuer Kontexte entspricht der regel oder ausl serbasierten Grundphilo sophie des NATURE Prozessmodells ist jedoch f r die Definition von Plankontexten ungeeignet da Plankontexte ja gerade eine explizite pr skriptive Ablaufreihenfolge ber eine Menge von Subkontexten legen sol len Insbesondere wird dabei der Kontroll und Datenfluss zwischen den Kontexten festgelegt was neben einer Eingangsschnittstelle auch die Defi nit
458. oftware Construction Prentice Hall 1997 Meyer B Introduction to a Theory of Programming Languages Englewodd Cliffs NJ 1990 Meyers S Difficulties in Integrating Multiview Development Systems IEEE Software S 49 57 Jan 1991 Microsoft The Windows Interface Guidelines for Software Design Microsoft Press Rich mond 1995 Microsoft Corp IntelliSense in Microsoft Office 97 Tech Report Microsoft Office White Paper 1997 Milner R Communication and Currency Prentice Hall Englewood Cliffs New Jersey 989 Mintert S JavaScript 1 2 Einf hrung Referenz Praxisl sungen Addison Wesley 1997 Mi P und Scacchi W Process Integration in CASE Environments EEE Software S 45 53 March 1992 Montangero C The Process in the Tool Syndrome is it becoming worse In Proc of the 9th Intl Software Process Workshop Arlie VA USA 10 1994 S 53 56 M ller O und Scholz P Specification of Real Time and Hybrid Systems in FOCUS Tech Report Technische Universitat M nchen TUM I9627 1996 Mylopoulos J Chung L und Nixon B Representing and Using Non Functional Re quirements A Process Oriented Approach IEEE Transactions on Software Engineering 8 6 S 483 497 1992 Nagl M Softwaretechnik Methodisches Programmieren im Gro en Springer Verlag 1990 Nagl M Hrsg Budding Tightly Integrated Software Development Environments The IPSEN Approach Springer Verlag LNCS 1170 1996 L
459. oftware Engineering Institute Carnegie Mellon University Pittsburg Pennsylvania USA CMU SEI 97 TR 008 1997 Chung P E Huang Y Yajnik S Liang D Shih J Wang C Y und Wang Y M DCOM and CORBA Side by Side Step by Step and Layer by Layer C Report 10 1 S 18 28 1998 Clements P A Survey of Architecture Description Languages In Proceedings of the 8th International Workshop on Software Specification and Design Paderborn Ger many IEEE Computer Society Press Los Alamitos CA 1996 S 16 25 Clemm G und Osterweil L A Mechanism for Environment Integration ACM Transac tions on Programming Languages and Systems 12 1 S 1 25 1990 Conradi R Nguyen M N Wang A I und Liu C Planning Support to Software Process Evolution International Journal of Software Engineering and Knowledge Engineer ing 10 1 S 31 47 2000 Conklin J und Begeman M gIBIS A Hypertext Tool for Exploratoy Policy Discussion ACM Transactions on Office Information Systems 6 4 S 303 331 Oct 1988 Conradi R und Jaccheri M L Process Modelling Languages In Derniame J C Kaba B A und Wastell D Htsg Software Process Principles Methodology and Tech nology Springer Verlag Berlin Heidelberg LNCS 1500 1999 S 27 52 Coplien J und Schmidt D C Hrsg Pattern Languages of Program Design Addison Wesley Reading 1995 Conradi R und Westfechtel B Version Models for Software Configuration Mana
460. ol model a specific environment model is configured The environment model defines the effects of the process models on the tool behaviour and lays the foundation for fine grained interpreta tive tool adaptability The approach has been realised in the form of a generic object oriented impk mentation framework that provides a set of prefabricated software components for the rapid development of a process integrated environment The framework also supports the integration of existing legacy tools which is demonstrated with three widespread commercial tools The overall practicability of our approach has been validated through the implementation of four process integrated environments in the application domains of requirements engineering and chemical process engi neering Danksagung V Danksagung Diese Arbeit entstand w hrend meiner T tigkeit als wissenschaftlicher Mitarbeiter am Lehrstuhl f r Informatik V Informationssysteme der RWTH Aachen W h rend dieser Zeit haben zahlreiche Menschen durch fachliche und pers nliche Gespr che Diskussion und Beitr ge Einfluss auf meine Arbeit genommen Mein Dank gilt insbesondere Q Prof Dr Matthias Jarke der mir die Durchf hrung dieser Arbeit erm g lichte und mich in allen Belangen leitete und unterst tzte Q Prof Dr Gregor Engels f r das Interesse an der Arbeit und die Bereit schaft das Koreferat zu bernehmen Q meinen Kollegen aus der Arbeitsgruppe PRIME Peter Haumer Ra
461. olgt die Integration ber ein gemeinsames Metamodell f r die Model lierung von Produkten und Aktionen grau unterlegte Konzepte und ber zus tz liche Assoziationen zwischen Konzepten des Prozess und Werkzeugmodells gestrichelte Assoziationen 2 1 lt besteht_aus_Situation besteht _aus_Intention 1 Abb 21 Situation PRIME UM Das Umge bungsmetamodell basiert_auf hat_Subkontext v Ausf hrungs kontext sia i f hrt_AK_aus Werkzeug i Bi Kommando kategorie bietet_KE_an gt Element Le incomplete Pulldown Darstellungs Darstellungs Men art i element Shortkey Kommando Icon Legende Zuordnung der HR y ooon Konzepte zu den Teilmodellen gemeinsame Assoziationen des Prozessmetamodell Werkzeugmetamodell Konzepte Umgebungsmetamodells 5 5 2 1 Abbildung von Ausf hrungskontexten auf Werkzeug kategorien Um einen Ausf hrungskontext der im Prozessmodell definiert wurde operationa lisieren zu k nnen muss dieser einer Werkzeugkategorie zugeordnet werden Diese Verantwortlichkeit wird repr sentiert durch eine Instanz der Assoziation f hrt AK aus F r eine korrekte Zuweisung von Ausf hrungskontexten zu Werk zeugkategorien lassen sich eine Reihe von Konsistenzbedingungen formulieren 122 5 Integrierte Prozess und Werkzeugmodelle AK1 Existenz der Werkzeugunterstutzung Zun chst muss sichergestellt werden dass die im Prozessmodell f r
462. ollierung von Nachvollziehbar keitsinformationen genauer zu beleuchten Ein Teil dieser Fragestellungen wird zur Zeit in der zweiten F rderperiode des Sonderforschungsbereichs IMPROVE bearbeitet 7 5 GARPEM die generische Prozessmaschinen architektur In diesem Abschnitt beschreiben wir das generische Prozessmaschinen Frame work GARPEM das den Kapitel 6 vorgestellten Ansatz zur interoperablen Ver wendung von Prozesssprachen realisiert Wir geben zun chst einen berblick ber die Grobstruktur des Frameworks Abschnitt 7 5 1 und gehen genauer auf die 7 5 GARPEM die generische Prozessmaschinenarchitektur 235 sprachlichen und technischen Klassen ein Abschnitt 7 5 2 In Abschnitt 7 5 3 beleuchten wir das Kontrollmodell das die Zusammenarbeit zwischen dem admi nistrativen Framework Teil und den spezifischen Sprachinterpretern regelt In Abschnitt 7 5 4 zeigen wir Parallelen zu verwandten Ans tzen auf 7 5 1 Grobstruktur des GARPEM Frameworks Abb 64 zeigt die Grobstruktur des GARPEM Frameworks das in drei Schichten unterteilt ist Die Schnittstellenschicht ist f r die Anbindung der Prozessmaschine an die Durchf hrungs und Modellierungsdom ne zust ndig Abb 64 a Grobarchitektur des GARPEM Frameworks Slang UML Statecharts XYZ Language Language Language Elements Elements Elements x Language Element Sprachelemente Process Factory Fr v2 5 ad 0 O o D ED Ee o 2 PED_StateManager
463. omie in der Biirokommunikation 1990 Verlage M und M nch J Formalizing Software Engineering Standards In Proc 3rd Intern Symposium and Forum on Software Engineering Standards ISESS 97 Walnut Creek CA USA 1997 S 196 206 Vestal S A Cursory Overview and Comparison of Four Architecture Description Languages Tech Report Honeywell Technology Center 1993 Vestal S MetaH Programmer s Manual Tech Report Honeywell Technology Center 1996 W3C World Wide Web Consortium Document Object Model DOM Level 1 Specifica tion W3C Recommendation REC DOM Level 1 19981001 1998 Wakeman L und Jowett J PCTE The Standard for Open Repositories Prentice Hall Englewood Cliffs 1993 Wastell D Arbaoui S Lonchamp J und Montangero C The Human Dimension of the Software Process In Software Process Principles Methodology and Technology Springer Verlag Berlin Heidelberg LNCS 1500 1999 S 165 199 Wandmacher J Software Ergonomie de Gruyter Verlag Berlin New York 1993 Warboys B The IPSE 2 5 Project Process Modelling as a Basis for a Support Environment In Proceedings of the 1st Internatational Conference on System Develeopment En vironment and Factories 1990 S 77 87 Wasserman A Tool Integration in Software Engineering Environments In Proc Intl Workshop on Software Engineering Environments Berlin Germany 1990 S 137 149 Wang X Zhao H und Zhu J GRPC A Communication
464. omponentenbasierte Softwareentwicklung Werkzeugspezifikation Prozessmo dellierung Benutzeroberfl chen und Softwareergonomie ergab dass zu Teilas pekten bereits mitunter ausgereifte L sungsans tze vorliegen Uns ist jedoch keine prozesszentrierte Umgebung bekannt die alle genannten Anforderungen in einem ganzheitlichen Ansatz zusammenf hrt und umsetzt Teil 2 L sungskonzept 105 Teil 2 L sungskonzept 106 4 berblick ber den L sungsansatz 107 berblick ber den L sungsansatz vorgestellten PRIME Ansatz f r prozessintegrierte Werkzeuge der L sungen zu den im vorigen Kapitel angesprochenen Problemen bietet PRIME basiert auf folgenden Kernelementen die in den Kapiteln 5 7 genauer dargestellt wer diesem Kapitel geben wir einen kurzen berblick ber den in dieser Arbeit den O Integrierte Prozess und Werkzengmodellierung In PRIME werden Prozesse und Werkzeuge gleichberechtigt auf einer konzeptuellen Ebene repr sentiert Die Integration von Prozess und Werkzeugmodellen zu einem so genannten Usmgebungsmodell bildet die Grundlage f r O Datenintegration durch die Definition gemeinsamer Produktdatensche mata f r Werkzeuge und Prozessmaschine O Prozessmediierte Werkzeuginteraktionen durch Separierung von Pro zess und Werkzeugaspekten in den jeweiligen Teilmodellen O Uniforme Beschreibung von Werkzeugdiensten und Prozessfragmen ten O Synchronisation durch eine explizite Definition der
465. on H Inside Distributed COM Microsoft Press Redmond Washington 1998 Eggersmann M Krobb C und Marquardt W A Modeling Language for Design Processes in Chemical Engineering Erscheint in Proceedings of the 19th International Conference on Conceptual Modeling ER 2000 2000 EIA The CDIF 1994 Interim Standard Overview Tech Report Electronic Industries Association EIA IS 106 1994 Eisenhauer G Mukherjee B und Codella C On the Implementation of CORBA Event Channels Tech Report T J Watson Reseach Center RC 20947 89322 11AUG97 1997 Elmasri R und Navathe S Fundamentals of Database Systems Addison Wesley 1999 Emmerich W und Finkelstein A Do Process Centered Environments Deserve Process Centered Tools In Montangeto C Hrsg Proc of the 5th European Workshop on Software Process Technology EWSPT 96 Springer Verlag LNCS 1149 1996 S 75 81 Emmerich W Too Construction for Process Centred Software Development Environments based on Object Databases Dissertation University of Paderborn Germany 1995 Emmerich W Too Specification with GTSL In Proc 8th Intl Workshop on Software Specification and Design Schlo Velen Germany 1996 S 26 35 Engels G Lewerentz C Nagl M Sch fer W und Schiirr A Building Integrated Software Development Environments Part I Tool Specification ACM Transactions on Software Engineering and Methodology 1 2 S 135 167 1992 Englander
466. on Schnittstellenbeschreibungen dar Diese Schnittstellenbeschreibungen sind jedoch nur innerhalb einer homogenen programmiersprachlichen Umgebung anwendbar Zentraler Bestandteil von Infrastrukturen f r verteilte objektorientierte Um gebungen wie z B CORBA oder DCOM sind daher so genannte Interface Description Languages IDLs mit deren Hilfe sich Schnittstellen von Softwarekomponenten sprachneutral notieren lassen Auch die oben angesprochenen Architekturbeschrei bungssprachen siehe S 91 bieten Sprachkonstrukte zu programmiersprachen unabh ngigen Beschreibung von Komponentenschnittstellen an Interface Description Language 3 3 Integrationsanforderungen in prozessintegrierten Umgebungen 87 Die Beschreibung einer Objekt Schnittstelle mit einer IDL dient zwei we a Generierung von Client sentlichen Zwecken Zum einen werden solche Spezifikationen mithilfe von Gene Stubs und Server ratoren den so genannten IDL Compilern gem den in standardisierten Sprach Skeletons Bindings festgelegten Abbildungsregeln in Programmcode der Zielsprache trans formiert In CORBA existieren Sprach Bindings f r die g ngigsten Sprachen wie z B C C Java Smalltalk und Ada Dabei wird nat rlich nicht die gesamte Objektfunktionalit t erzeugt sondern nur der Code f r die Stubs und Skeletons s o der erforderlich ist f r den Transport von Methodenaufrufen vom einem Rechner im Netz zu dem anderen auf dem sich das aufgerufene Obje
467. on University of Jyv skyl 1998 Mazza C Fairclough J Melton B Pablo D D Scheffer A und Stevens R Software Engineering Standards 1994 Mylopoulos J Borgida A Jarke M und Koubarakis M Telos Representing Knowl edge about Information Systems ACM Transactions on Information Systems 8 4 S 325 362 1990 McChesney I R Towards a Clssification Scheme for Software Process Modeling Approaches Information and Software Technology 37 7 S 363 374 1995 McMenamin S M und Palmer J F Essential System Analysis Yourdon Press Pren tice Hall Englewood Cliffs 1984 Magee J Dulay N Eisenbach S und Kramer J Specifying Distributed Software Architectures In Sch fer W und Botella B Hrsg Proc 5th European Software Engineering Conference Barcelona Spain Springer Verlag LNCS 989 1995 S 37 153 Montangero C Derniame J C Kaba B A und Warboys B The Software Process Modelling and Technology In Derniame J C Kaba B A und Wastell D Hrsg Software Process Principles Methodology and Technology Springer Verlag Hei delberg Berlin LNCS 1500 1999 S 1 14 Medvidovic N und Taylor R A Framework for Classifying and Comparing Architecture Description Languages In Proc 6th European Software Engineering Conference 5th ACM SIGSOFT Symposium on the Foundations of Software Engineering ESEC FSE 97 Z rich Switzerland 1997 S 60 76 Meyer B Object Oriented S
468. on Objektreferenzen die Aufl sung von Operationsaufrufen method dispatch die Aktivierung und Deaktivierung von Objekten und die Regist rierung des die Objekte implementierenden Codes Serverseitig d h beim diensterbringenden Werkzeug werden die Aufrufe analog von den ebenfalls au tomatisch erzeugten Skeletons entgegen genommen und an die Implementierung des betreffenden Dienstes weitergereicht In die eigentliche Kommunikationsan bindung an das Zielobjekt ist noch so genannter Basic Object Adapter BOA zwischengeschaltet Dieser kann ausgetauscht werden und spezielle Funktionalit ten anbieten um zum Beispiel Serverobjekte nicht als eigene Betriebssystempro zesse sondern als Datenbankobjekte zu realisieren Alternativ zur Anbindung ber zur berserzungszeit bekannte Stubs und Skele tons kann der Operationsaufruf auch ber das Dynamic Invocation Interface DIL erfolgen welches dem Klienten die Angabe der Operation und der Parameter zur Laufzeit erlaubt Die analoge Funktionalit t stellt auf Serverseite das Dynamic Skele ton Interface DSI zur Verf gung Zusammen mit Namensdiensten Sieg96 und Tradingdiensten PoSW96 AT amp T96 kann so das Auffinden und die Aktivierung von diensterbringenden Werkzeugen f r das aufrufende Werkzeug weitgehend transparent gestaltet werden Dynamic Invocation Interface Zu einer prozessadaptablen Komposition von Werkzeugdiensten zu komplexeren Ablauffragmenten tr gt die durch DU DIS Namen
469. onenten einer Entwurfsumgebung auf Sie identifizieren mehrere Arten von Beziehungen zwischen Komponenten die f r Integration von Belang sind Beziehungen zwischen Werkzeugen Bezie hungen zwischen Werkzeugen und Rahmenwerksdiensten Beziehungen zwischen Werkzeugen und Prozessen Su ee f er I Unterscheidung zwi In eine hnliche Richtung gehen die berlegungen von Brown et al die in schen ae BrFe92 Bro 94 eine Analysetechnik f r die Integration in Entwurfsumgebungen und mechanistischen vorschlagen die st rker noch als das Klassifikationsmodell von Thomas und Integrationsaspekten 50 3 Integrationsansatze Nejmeh auf die Unterscheidung zwischen semantischen und mechanistischen Aspekten abzielt Dazu betrachteten sie die drei Ebenen der Basismechanismen der Benutzer dienste and der Prozesse Sie argumentieren dass auf jeder dieser Ebenen und zwi schen den Ebenen jeweils spezifische Integrationsfragestellungen auftreten die eine getrennte Behandlung erfordern vgl Abb 7 Abb 7 Integration im Span nungsfeld zwischen Ziele Randbedingungen Prozessen und Basisme Wartbarkeit Methode chanismen Bro 94 achvoll Zeitrahmen iehbarkei Prozesse Entwicklung Anforderung C Design gt analyse mplemen tierung Die Ebene der Basismechanismen befasst sich mit den prinzipiellen Architekturent scheidungen die einer integrierten Umgebung zugrunde liegen und den f r die Realisierung verwendeten Rahmenwerksdienst
470. onkrete Sprache zur Situationsspezi fikation h ngt wesentlich vom zugrunde liegenden dom nenspezifischen Pro duktmodell und von den zur Verf gung stehenden Mechanismen zur Auswertung von Situationen ab Die Detailspezifikation von Situationen als Sichten auf aktuelle Werkzeugzustande und entsprechende Auswertungskomponenten werden in Kapitel 7 genauer beschrieben Spezifikation von Abl u Hauptgegenstand dieses Kapitels ist der zweite offene Aspekt des Prozessme fen in Plankontexten tamodells der die Ausf hrungsreihenfolge zwischen den Subkontexten eines Plankontexts betrifft ber die Assoziation hat Subkontext l sst sich bislang lediglich modellieren welche Teilschritte zu einem Plankontext geh ren ohne jedoch eine pr skriptive Abarbeitungsstrategie ber der Menge der Subkontexte festlegen zu k nnen Fr here Ans tze zur In fr heren Ans tzen die auf dem NATURE Prozessmodell basieren wurden un des zwei unterschiedliche Wege zur Anreicherung des Modells um Konzepte zur Fr en pr skriptiven Ablaufspezifikation beschritten In RoSM95 Gro 97 wird das NATURE Prozessmodell um zus tzliche Konzepte zur Kontrollflussspezifikation erweitert Die Subkontexte eines Plankontexts werden ber explizite gegebenen falls mit Bedingungen annotierte Pr zedenzkanten in eine definierte Reihenfolge gebracht und bilden einen gerichteten Graphen In Pohl96 wird dagegen auf eine Erweiterung des NATURE Prozessmodells um zus tzliche Kontrollfl
471. onship Wenn zuerst der speziellere Situationsteils r2 und dann r gebunden wird erhalten wir s rj lend by rz book als g ltige Instanz von Wird dagegen zun chst der allgemeinere Teil r gebunden k me entweder book oder lend by als zugeordnete Produktinstanz in Frage Bei der Wahl von book schl gt jedoch die weitere Zuordnung fehl da dann keine pas sende Produktinstanz f r den spezielleren Situationsteil r2 mehr brig ist siehe Abb 60 ER_Entity ER_Attribute I I I I situation S with 1 1 r2 ER Entity and 7 PE sbn a lend_by inkorrekte Bindung Abb 60 Inkorrekte Bindung bei falscher Reihenfolge der Zuordnung Ein weiteres Problem ergibt sich dadurch das bei Situationsteilen die den gleichen Aufl sung von Wahlfrei Typen referenzieren ist Wahlfreiheiten bei der Zuordnung von Produktinstanzen heiten bei der Zuord bestehen Aus semantischer Sicht sind die Situationsteile jedoch h ufig unter an MARIO schiedlich zu behandeln was sich in den Rollenbezeichnern ausdr ckt Verdeut licht wird dies anhand des Situationstypen TwoEntities 218 Aufwandsbetrachtung 7 Das PRIME Rahmenwerk situation SIsa with subEntity product ER Entity superEntity product ER Entity end Diese Situation ist Teil des Kontextes EC_CreateIsaLink der eine gerichtete Spezia lisierungsbeziehung zwischen einer Entit t in der Rolle subEntity und einer Enti t t
472. ontext und Plankontext dargestellt werden Diese Spezialisierungen haben eine spezifische Semantik die sich durch jeweils unterschiedliche Assoziationen zu anderen Konzepten des Prozessmodells ausdr cken Aktion Auf der elementarsten Ebene kann der Arbeitsfortschritt innerhalb eines Pro zessfragments direkt durch die Modifikation des in Entwicklung befindlichen Produkts erzielt werden Eine solche Transformation ist Resultat einer determinis tischen Aktion die automatisiert oder zumindest strikt erzwungen ausgef hrt wird Kontexte die auf diese Art operationalisiert werden k nnen werden im NA TURE Modell als Ausf hrungskontexte bezeichnet und sind ber die Assoziation ausgef hrt durch mit der entsprechenden Aktion verkn pft Die Ausf hrung einer Aktion ndert das Produkt und ruft so das Entstehen neuer Situationen hervor die dann selbst wieder Gegenstand einer nachfolgenden Kontextaktivie rung sein k nnen Beachtenswert ist dass im Prozessmetamodell eine Aktion und der Kontext in dem die Aktion eingesetzt werden kann eigenst ndig modelliert werden Dadurch l sst sich insbesondere ausdr cken dass ein und dieselbe Aktion potenziell zur Umsetzung unterschiedlicher Kontexte mit variierenden Benutzer intentionen und Situationen dienen kann Ausf hrungskontext Entscheidungskontext Entscheidungskontexte modellieren Prozesszust nde in denen eine explizite Benutzerentscheidung ber den weiteren Prozessablauf notwendig ist Ei
473. orgehensweisen an die Prozessbeteiligten und die problembezogene und zielgerichtete Anleitung Lenkung oder Automation von Entwicklungsaktivit ten Als in heutigen Organisationen mehr oder weniger gel u fige Ans tze zur Prozessunterst tzung betrachten wir Methoden und Projekthandbii cher Abschnitt 2 2 1 Hilfesysteme Abschnitt 2 2 2 Assistenten Interface Agenten Abschnitt 2 2 3 und prozesszentrierte Entwicklungsumgebungen Abschnitt 2 2 4 2 2 1 Methoden und Projekthandb cher Die in der heutigen industriellen Praxis immer noch am weitesten verbreitete Methode Prozesswissen zu kommunizieren besteht darin allgemeine Handlungs richtlinien und Softwaretechnik Standards z B ISO 12207 ISO 95 IEEE 1074 TEEE95 PSS 05 Maz 94 V Modell BrDr95 DrHM98 methodenbezogene Vorgehensmodelle z B UML Unified Process JaBR99 Kruc98 ICONIX Uni fied Object Modeling Approach RoSc99 und organisations und projektspezifi sche Arbeitsplatzanweisungen in Form von Handb chern aufzubereiten Die Verbreitung des in den Handb chern hinterlegten Prozesswissens wird im Allge Tab 3 meinen durch Trainingsprogramme und Schulungen begleitet in denen die Pro Prozessunterst tzung zessausf hrenden entsprechend den Vorgaben aus den Handb chern f r die ihnen oe rane se d zugewiesenen Aufgaben qualifiziert werden Art der Integrations Kontext Anpassbarkeit Unterst tzungsmodi Prozessunterst tzung tiefe bezogenheit v c 0 x
474. orkflowsystemen unterst tzt werden ist ein hoher Durchsetzungsgrad der Prozessunterst tzung eher angemessen Das gleiche kann aber auch in kreativen Prozessen gelten wenn die Konformit t der Prozessdurchf hrung zu definierten Prozessmodellen zwi schen Auftragnehmern und Kunden vertraglich vereinbart wurde Dies ist zum Beispiel dann der Fall wenn zur Gew hrleistung von Nachvollziehbarkeit Ent wicklungsaktivit ten prozessbegleitend dokumentiert werden m ssen Pohl99 Domg99 Eine andere Ursache fur das Entstehen von Modellinkonsistenzen kann in ei ner mangelhaften Repr sentation der aktuell g ltigen Prozessvorgaben in der Durchf hrungsdom ne liegen d h es ist f r den Entwickler in seiner Arbeitsum gebung nicht oder nur schwer erkennbar welche Prozessschritte im aktuellen en Prozesszustand prozessmodellkonform sind und welche Schritte im Widerspruch vorgaben zu den Einschr nkungen des Prozessmodells stehen In diesem Fall w rde der Entwickler die Vorgaben aus dem Prozessmodell unbewusst verletzen Im Gegen satz zu beabsichtigten Abweichungen sollten unbewusste Modellabweichungen unbedingt vermieden werden da ansonsten die gesamte Prozessunterst tzung wertlos wird Voraussetzung daf r ist dass die Werkzeugumgebung die aktuell erlaubten Prozessschritte ad quat in der Benutzeroberfl che reflektiert und den Zugriff auf nicht vorgesehene Schritte nur auf explizite und bewusste Anforderung des Benutzers erlaubt Die daraus resul
475. ozess Repository abgelegten Kontextdefinitionen im Umgebungsmodell gesteu ert Um die in Abschnitt 3 1 4 geforderte Modelhierungsadaptabilit t za erf l len reicht es nicht aus diese Spezifikation manuell oder durch Codegene rierungstechniken in entsprechende Werkzeugfunktionalit t zu berf hren Stattdessen ist eine Komponente erforderlich die die externen Kontextde finitionen zur Lanfzeit interpretiert Die Interpreterkomponente muss dazu folgende Teilaufgaben erf llen O Steuerung von Ausf hrungskontexten gem Umgebungsmodell Nach der Aktivierung eines Ausf hrungskontexts muss die Interpreter Komponenten die im Umgebungsmodell assoziierte Werkzeug Aktion ermitteln O Steuerung von Entscheidungskontexten gem Umgebungsmodell Nach der Aktivierung eines Entscheidungskontexts muss die Benut zeroberfl che des Werkzeugs entsprechend angepasst werden d h die Selektierbarkeit und Darstellung von Produkten und Kommandoele menten richtet sich nach den im Umgebungsmodell definierten Alter nativen des Entscheidungskontexts 196 7 Das PRIME Rahmenwerk O Erkennung der Kontextaktivierung durch den Benutzer Im Gegensatz zu traditionellen Werkzeugarchitekturen ist die Reaktion eines GARPIT basierten Werkzeugs auf Benutzereingaben nicht un mittelbar an die Implementierung von Aktionen gebunden etwa durch Callback Mechanismen Stattdessen muss die Interpreter Kompo nente die Interaktionen des Benutzers Selektion von
476. ozessmaschine in der Lage in die eigentliche Pro zessdurchf hrung unterst tzend einzugreifen Q Inder Durchf hrungsdom ne f hren Menschen und oder Softwarewerkzeuge die eigentlichen Entwicklungsvorg nge durch unabh ngig davon ob sie durch die Prozessmodellausf hrung angeleitet werden oder nicht Die von einer PZEU geleistete Prozessunterst tzung l sst sich durch die typischen Beziehungen und Interaktionen der drei Prozessdom nen charakterisieren siehe Abb 4 Q Zur Prozessmodellausf hrung wird eine Kopie des Prozessmodells aus der Modellierungsdom ne in den Ausf hrungsmechanismus der Leitdom ne Abb 4 Die drei Dom nen der Prozessunterst tzung vgl DoFe94 Pohl96 36 2 Prozessorientierte Unterstutzungsfunktionen geladen und Parameter z B Entwurfsprodukte Ressourcen und Zeitvor gaben an projektspezifische Werte gebunden siehe Pfeil Prozessmodel linstanz erung in Abb 4 Charakteristisch ist dass bei der Initiierung der Prozessmodellausf hrung nicht notwendigerweise alle Prozessvariablen bereits bekannt sind sondern mitunter erst im Laufe der Prozessausf h rung an konkrete Werte beispielsweise an die Ergebnisprodukte eines vo rangegangenen Arbeitsschritts gebunden werden O Basierend auf der Interpretation des instanziierten Prozessmodells werden in der Leitdom ne die Aktivit ten der Durchf hrungsdom ne unterst tzt kontrolliert und berwacht Dabei muss sichergestellt werden dass d
477. ozessmodellierer weder die Zuordnung zwischen Kontexten und Werkzeugkategorien kennen noch eine eigene Verwaltung der aktuellen Werkzeuginstanzen vornehmen muss 7 2 4 Zusammenfassung Das in diesem Abschnitt beschriebene Protokoll definiert die dynamischen Beziehungen zwischen der Durchf hrungsdom ne und der Leitdom ne Wir haben dazu das Verhalten der beiden Dom nen mithilfe von Zustandsdiagrammen die ber Nachrichtenausausch miteinander gekoppelt sind spezifiziert Im Gegensatz zu der bei prozesszentrierten Umgebungen und Workflowmanagementsystemen vorherrschenden einseitigen Client Server Beziehung zwischen der Prozessmaschine und den Werkzeugen unterst tzt das Interaktionsprotokoll sowohl einen reaktiven als auch einen proaktiven Unterst tzungsmodus wie es in den Abschnitten 2 1 5 und 3 3 5 sowie von verschiedenen Autoren z B BaDF96 CDFG96 gefordert wird Diese Unterst tzungsmodi werden durch die Zustandspaare Unrestricted Process Performance Process Enactment Inactive bzw Guided Process Performance Process Enactment Active reflektiert Die Synchronisation der Dom nen beim bergang zwischen den Unterst tzungsmodi wird durch spezielle Subprotokolle sichergestellt z B durch das Sperren der ben tigten Werkzeuginstanzen vor dem eigentlichen Start der Plankontext Ausf hrung Ein wichtige Rolle spielt der Kommunikationsmanager der Details der Nachrichtenverteilung vor den 7 3 GARPIT ein Framework f r proz
478. prechenden kommerziellen Werk zeugen fast immer auf Kosten des Funktionsumfangs und der Benutzbarkeit da entsprechende Ressourcen zu deren Realisierung fehlen Die wesentliche Kritik die gegen ber a priori Integrationsans tzen ins Feld gef hrt wird lautet also dass der Aufwand f r die Neuentwicklung Aonkurrenzf higer Werkzeuge bzw f r die Modifikation des Quellcodes existierender Werkzeuge sofern berhaupt verf g bar in keinem vern nftigen Verh ltnis steht zum Vorteil der sich aus der Integ riertheit der Werkzeuge ergibt und somit die Anwendung des Ansatzes prohibitiv teuer macht Ein Beleg hierf r findet sich zum Beispiel in EBLA96 EAMP97 wo die Au toren ber ihre Erfahrungen aus einem Experiment zur Einf hrung von Pro zesstechnologie bei der British Airways BA im Rahmen des GOODSTEP Pro jekts GOOD94 berichten In dieser Studie wurden speziell die Prozesse zum Management von C Klassenbibliotheken bei BA untersucht und durch eine prozesszentrierte Umgebung unterst tzt welche mehrere auf Basis des GTSL Mangelnde Akzeptanz Ansatzes Emme95 Emme96 siche auch Abschnitt 3 3 4 2 neu entwickelte akademischer Ans tze inder Praxis Werkzeuge umfasst Als Resultat des Experiments konnten zwar wertvolle Er kenntnisse ber die Prozessmodellierungssprache SLANG sowie ber die Prozesse bei British Airways selbst gewonnen werden die entstandene prozesszentrierte Umgebung inklusive der neuen Werkzeuge wurde jedoch
479. r hen Phasen Anforderungsanalyse Entwurf auftretenden Prozesse nicht ausreichend verstanden ist und mehr noch als auf der Projektmanagementebene von der Kreativit t der Entwickler gepr gt ist und von seinen situativen Ent F ragmentarische Pro scheidungen und seiner Erfahrungen abh ngen Such87 Das bedeutet aber nicht zessunterst tzung dass auf der Arbeitsplatzebene gar keine ber die reine Aufgabenbeschreibung hinausgehende Prozessunterst tzung m glich w re Bestimmte Teilabschnitte der arbeitsplatzlokalen Arbeitsprozesse lassen sich durchaus als wohldefinierte Abfol gen von Arbeits und Entscheidungsschritten in den unterschiedlichen Entwick lungswerkzeugen beschreiben Prozessunterst tzung auf der Arbeitsplatzebene ist daher als eine Sammlung feingranularer nicht notwendigerweise zusammenh n gender Prozessfragmente aufzufassen RoPB99 Poh 99 2 1 2 Integrationstiefe niri 3 __ Prozesswissen Elementare Grundvoraussetzung f r die Unterst tzung von Entwicklungsaktivi uss wirkun gsvoll t ten ist die wirkungsvolle Kommunikation organisations und projektspezifischer kommuniziert werden Handlungsvorgaben und hilfestellungen an die betroffenen Entwickler am techni schen Arbeitsplatz Um eine ihm zugewiesene Aufgabe korrekt und effizient aus f hren zu k nnen muss der Entwickler mit Wissen ber methodische Vorge hensweisen versorgt werden z B worin das Ziel der Aufgabe besteht welche Ergebnisse z
480. r Definition der W chterbedingungen kann aktuell nur die Transition die den eingebetteten Plan kontext PC FBW InspectRelatedObjects repr sentiert schalten Wie oben be schrieben wurde dieser Plankontext mithilfe von UML Statecharts modelliert so dass das Prozessmaschinen Rahmenwerk das UML Startchart instanziiert und die 5 Die Plankontext Editoren sind in der Lage den Ausf hrungszustand eines Prozessfragments dynamisch zu visualisieren Dazu m ssen sie sich zuvor beim Prozessspurenserver registriert haben der im Hintergrund die verteilte Ausf hrung von Prozessfragmenten protokolliert und Ereignisse wie den Start und das Beenden eines Kontexts an alle registrierten Interessenten weiterleitet 8 3 Beispielsitzung 267 Kontrolle an die entsprechenden UML Interpreterobjekte der sprachspezifischen Schicht tibergibt Innerhalb des Plankontexts PC_FBW_InspectRelatedObjects werden alle Entwurfsobjekte ermittelt die zu der gefundenen Separation Verfeinerung in Beziehung stehen und angezeigt Hierzu werden die Ausf hrungskontexte EC DEP getDependentProduct bzw EC DEP expandProduct im Abh ngigkeits editor von der Prozessmaschine aktiviert so dass sich die in Abb 79 dargestellte Situation ergibt EI PRIME Dependency Editor Browser Noname lel Abb 79 Der Abhangigkeitseditor w hrend der Ausf hrung des Entscheidungs kontexts a CC_SelectDepProduct eg Edit Tools Preferences Help
481. r Kon text nicht Der Methodeningenieur erkennt dass in der vorliegenden Konfiguration des Flie bildwerkzeugs h ufig komplexe Verfeinerungshierarchien mit vielen alternati ven Verfeinerungen f r einen VT Prozessbaustein entstehen wobei sich jedoch die einzelnen Alternativen h ufig nur geringf gig unterscheiden und die Gr nde f r die Auswahl einer Alternative schlecht dokumentiert sind Abb 73 Gesamtarchitektur der PRIME IMPROVE Umgebung 260 8 Anwendungen Um das Anlegen neuer Verfeinerungsalternativen konsistent und nachvoll ziehbar zu machen ersetzt der Methodeningenieur den Ausf hrungskontext Refi neProcessDevice durch einen neuen Plankontext RefineProcessDeviceWithDeci sion Hinter diesem Plankontext steht die berlegung dass die M Prozessunter st tz ung den Verfahrensingenieur bei der Verfeinerung eines VT Prozessbausteins zun chst auf eventuell schon existierende Verfeinerungen hinweisen sollte Wei terhin sollte die M Prozessunterst tzung den Verfahrensingenieur mit allen Hin tergrundinformationen Entscheidungen Argumente informelle Anforderungen Simulationsergebnisse etc versorgen mit denen bereits existierende Verfeinerun gen des betreffenden VT Prozessschritts dokumentiert wurden Eine Analyse dieser Informationen kann dazu f hren dass der Verfahrensingenieur auf das Anlegen einer weiteren Verfeinerung verzichtet Wird dennoch eine Verfeinerung angelegt dann m ssen
482. r Kontrollintegration ist also erst dann als prozessintegriert zu betrachten wenn die Interaktionsmuster zwischen den Werkzeugen auf expliziten und einfach nderbaren Prozessdefinitionen beru hen die in der Modellierungsdom ne abgelegt sind Vor diesem Hintergrund sind bei der Auswahl und Ausgestaltung von Infra strukturen Mechanismen und Beschreibungstechniken f r die Kontrollintegration drei Aspekte von besonderer Bedeutung Anforderung 2 Prozessorientierte Mediation der Werkzeuginteraktionen Hinter Werkzeuginteraktionen verbirgt sich inh rent Wissen ber Arbeitsabl ufe Diese Interaktionsmuster sollten nicht in den beteiligten Werkzeugen hartkodiert sein sondern f r die Werkzeuge transparent in expliziten Prozessdefinitionen in der Modellierungsdom ne verankert sein F r einen Kontrollintegrationsmecha nismus bedeutet dies dass eine Mediation ber die Prozessmaschine einer direkten Werkzeuginteraktion vorzuziehen ist Abschnitt 3 3 3 Anforderung 3 Konzeptuelle Beschreibung von Werkzeugdiensten Um zur Modellierungszeit innerhalb einer Prozessdefinition auf Werkzeuge Bezug nehmen zu k nnen m ssen deren Dienste in geeigneter Weise auf einer konzep tuellen Ebene die von Implementierungsspezifika abstrahiert repr sentiert wer den Abschnitt 3 3 4 Anforderung 4 Synchronisation der Prozessdom nen Als wesentliche Voraussetzung f r sinnvolle Prozessunterst tzung muss der Zu stand der Prozessmodellausf hrung
483. r M Prozesse in der Verfahrenstechnik aus vier unterschiedlichen Blickwinkeln betrachten NaWe99 1 Direkte M Prozessunterst tzung dutch Beo bachtung von Abl ufen bei Entwicklern und Anbieten von f r gut befundenen Abl ufen zur Wiederverwendung 2 indirekte M Prozessunterst tzung durch Siche rung von Struktur und Konsistenzbedingungen der entstehenden komplexen Produkte mit Hilfe von Integrationswerkzeugen 3 informelle multimediale Koopera tion der M Prozessbeteiligten 4 Projektkoordination durch ein reaktives Administ rationssystem Die hier beschriebene PRIME IMPROVE Umgebung wurde im Rahmen des Teilprojekts Direkte M Prozessunterst tzung entwickelt welches sich auf die Erfas sung Formalisierung und Steuerung arbeitsplatzbezogener Entwurfsvorg nge durch feingranulare werkzeugbezogene M Prozessfragmente konzentriert 8 2 2 Werkzeuge der PRIME IMPROVE Umgebung PRIME IMPROVE integriert eine Reihe von Werkzeugen f r die Modellierung Analyse Simulation und Dokumentation verfahrenstechnischer Prozesse Zu diesen geh ren die allgemein verwendbaren Werkzeuge des PRIME Rahmenwerks Abh ngigkeitseditor Hypertexteditor Entscheidungseditor Prozessspurenvisuali sierer Anleitungswerkzeug vgl Abschnitt 7 1 2 die kommerziellen Simulations und Kalkulationswerkzeuge Aspen Plus MS Excel gPROMS und Morex sowie ein auf Basis des CAD Werkzeugs Visio entwickelter Flie bildeditor den wir aufgrund seiner besonderen Bedeutung f
484. r Workflow Management API Interface 2 amp 3 Specification WFMC98a eine Schnittstelle zu Workflow System vor ber die so genannte workflow enabled applications Informationen ber anwendbare Prozessfragmente oder aktuell laufende Aktivit tsinstanzen erfragen k nnen Gedacht ist diese Schnitt stelle allerdings weniger f r die eigentlichen Werkzeuge einer Entwurfsumgebung sondern eher f r prozesszentrierte Administrationswerkzeuge wie Agenda Mana ger Projektmanagement Werkzeuge und Monitoring Werkzeuge Moderne Entwicklungsumgebungen insbesondere aus dem Windows Umfeld bieten Mechanismen zur ad hoc Erweiterung des Funktionsumfangs durch den Benutzer oder durch Dritthersteller Als Beispiele sind die M glichkeiten zur Makroprogrammierung in der Microsoft Office Familie oder die Einbindung von so genannten Add ins in Umgebungen wie Microsoft Visual Studio oder Rational Rose zu nennen Diese Mechanismen die sich intern meist auf COM Schnittstel len des zugrunde liegenden Objektmodells des Werkzeugs abst tzen stellen einen grunds tzlichen Ansatzpunkt f r die werkzeugseitige Integration mit einem Pro zessausf hrungsmechanismus bereit Es ist uns allerdings kein systematischer Ansatz f r eine prozessorientierte Nutzung solcher Erweiterungsschnittstellen bekannt 3 3 7 3 Fazit Der bergang vom reaktiven in den proaktiven Unterst tzungsmodus ist dadurch charakterisiert dass die Durchf hrungsdom ne Prozessunterst tzung von der Lei
485. r den Methodeningenieur bei der Definition und Konfigu ration der Prozess und Werkzeugmodelle unterst tzen Aus einer technischen Perspektive betrachtet basieren die Administrations und Metamodellierungswerk zeuge jedoch genau wie alle anderen Entwicklerwerkzeuge der Durchf hrungsdo m ne auf dem GARPIT Framework und sind daher vollst ndig prozessintegrier bar Somit wird der Prozess der Prozessmodelldefinition durch die Definition ge eigneter Meta Prozessfragmente selbst wieder zum Gegenstand einer prozessinteg rierten Werkzeugunterst tzung Daher profitiert nicht nur der Applikationsent wickler sondern auch der Methodeningenieur von der Assistenzfunktion der Prozessintegration in einer PRIME basierten Umgebung Dar ber hinaus ergeben sich interessante M glichkeiten zur prozessmodellgesteuerten Verschrinkung von Pro zessausf hrung und definition Auf Basis entsprechender Prozessmodelle k nnte beispielsweise der Applikationsentwickler bei der ad hoc Definition neuer Prozess fragmente mithilfe der Prozessmodellierungswerkzeuge und der anschlie enden Einbringung dieser Prozessfragmente in die Janfenden Entwicklungswerkzeuge angeleitet werden In den derzeit existierenden Anwendungen des PRIME Rah menwerks haben wir dieses Potenzial zur Verschr nkung von Entwicklungs und Metaprozess erst in wenigen ausgew hlten Nutzungsszenarien erprobt siehe dazu auch Kapitel 8 Im Kontext des zurzeit viel diskutierten Problems der Evolution l
486. r kreativer Entwurfsprozesse Such87 und legt besonderes Gewicht auf die Modellierung des Kontextes in dem sich der Ent wickler in seiner Arbeitsumgebung befindet auf seine Entwurfsziele und die dabei zu treffenden Entscheidungen Gerade f r kreative Entwurfsprozesse stellt das NA TURE Prozessmodell einen signifikanten Fortschritt gegen ber aktivit ts oder produktzentrierten Prozessmodellierungssprachen dar die sich vorwiegend auf Aussagen ber Ausf hrungsreihenfolgen von Aktivit ten das Wie bzw deren Resultate das Was beschr nken und Entscheidungen und Situationen in denen die Entscheidungen gef llt werden das Warum nur unzureichend repr sentie ren Gro 97 Die Eignung des NATURE Prozessmodells f r die feingranulare Modellierung von Entwurfsmethodiken wurde in verschiedenen Anwendungsdom nen erfolg reich demonstriert z B im Bereich des Requirements Engineering f r die ER Modellierung PIRo95 oder die szenariobasierte Systemanalyse RoSB98 HaPW98 Weitere Anwendungserfahrungen des NATURE Prozessmodells liegen f r Modellierungsprozesse im Bereich der Verfahrenstechnik vor WeBa99 D m 96 Lohm98 EgKMO0 Im Folgenden erl utern wir kurz die wichtigsten Elemente des NATURE Pro zessmetamodells das in Abb 19 in Form eines UML Klassendiagramms darge stellt ist 5 3 Modellierung von Prozessfragmenten 11 1 lt besteht_aus_Situation besteht_aus_Intention 1 Alternative
487. rch gewonnene Verteilungstrans parenz vereinfacht sowohl den Entwurf des MessageInterface Teilsystems als auch dessen Nutzung in h heren Architekturschichten erheblich 7 3 2 5 ContextManager Das Teilsystem ContextManager ist fur die Interpretation der werkzeugrelevanten Anteile des Umgebungsmodells zust ndig Gem den Anforderungen aus Ab schnitt 7 3 1 1 bestehen die Aufgaben des ContextManagers in der effizienten Laufzeitverwaltung der f r ein Werkzeug g ltigen Kontextdefinitionen der pro zessmodellkonformen Steuerung von Ausf hrungs und Entscheidungskontexten sowie der Erkennung von Kontextaktivierungen durch den Benutzer Diese drei Aufgaben werden von den Hauptklassen CcxtContextCache CcxtContextExecutor und CextContextMatcher realisiert Dabei erfolgt die Interaktion des ContextMana ger Teilsystems mit der werkzeugspezifischen Basisfunktionalit t Teilsystem T Actions und Benutzeroberfl che T_GUI ber die Verzeichnisklassen des Teil system Map siehe Abb 53 ContextCache Der ContextCache wird als Objekt der Klasse CcxtContextCache beim Werkzeug ContextCache start erzeugt l dt bei seiner Initialisierung die ben tigten Kontext Intentions Laufzeitverwaltung der und Situationsinformationen aus dem Prozessrepository und repr sentiert diese ae BON mithilfe entsprechender Deskriptorklassen CoxtContextDecs CcxtSituationDesc CoxtIntentionDesc etc Der Konstruktor der CcxtContextCache Klasse
488. rch verwischen die Grenzen zwischen einzelnen Werkzeugen so dass aus Benutzersicht eine bestimmte Funktion nicht l nger einem Werkzeug sondern einem Dokumentobjekt zugeordnet wird Im Unterschied zu einem prozesssensitiven Interaktionsparadigma beruht die Kontextsensitivit t des Funk tionsangebots jedoch allein auf der aktuellen Objektselektion und eventuell dem spezifischen Objektzustand und unterliegt nicht irgend welchen explizit definier ten Prozessmodellen bzw der Prozessmodellausf hrung in der Leitdom ne Kontextsensitivit t in Compound Documents Ans tze aus dem Bereich der prozesszentrierten Umgebungen Workflowma nagementsysteme haben bislang die Auswirkungen der Prozessorientierung auf das Interaktionsparadigma in den verwendeten Werkzeugen und Applikationen weit gehend vernachl ssigt Der Zugriff auf Objekte und Funktionen in den Werkzeu gen kann nicht oder nur grobgranular meist bezogen auf die Daten von der Prozessmodellausf hrung beeinflusst werden woraus schwerwiegende Synchroni sationsprobleme resultieren B hm98 BeM 99 Schm96 Schr97 Eine interessante Ausnahme bildet die im Rahmen des Eureka Software Factory Projekts entwickelte Umgebung East Simm91 Simm93 In East beschreiben als Task Template bezeichnete Prozessmodelle nicht nur die zu bearbeitende Auf gabe sondern auch die charakteristischen Eigenschaften des Daten und Funkti onszugriffs in der Werkzeugumgebung Beim Einloggen in die East Umgebun
489. rde 2 sich ber die daf r vorliegenden Gr nde informieren konnte und 3 bei der konsi stenten Fortschreibung der Entscheidungs und Abh ngigkeitsdokumentation unterst tzt wurde F r den Methodeningenieur wurde die M Prozessfragmentdefinition dadurch erleichtert dass er f r Teilabl ufe existierende M Prozesskomponenten aus einer Komponentensammlung wiederverwenden konnte Hierbei wurde die Einbettung 270 8 Anwendungen eines als UML Statechart definierten Plankontexts in ein SLANG Aktivitatsnetz demonstriert ber entsprechende Definitionen im Umgebungsmodell wurde der neue Plan kontext dem Flie bildwerkzeug zugeordnet Dies erm glichte eine Aktivierung des M Prozessfragmentes aus dem Flie bildwerkzeug heraus ohne dass der Verfah rensingenieur seine gewohnte Arbeitsumgebung verlassen musste Sichtbar wurde die M Prozessunterst tzung f r den Verfahrensingenieur durch die Automatisie rung von Teilabl ufen und die Anpassung der ausw hlbaren Optionen in den Werkzeugen 8 4 Fazit Gegenstand dieses Kapitels waren Beispielanwendungen des PRIME Rahmen werks mit denen wir seine Praktikabilitat nachweisen konnten Wir haben zu n chst die Entwicklungshistorie des PRIME Rahmenwerk ausgehend von der urspr nglichen PROART Umgebung skizziert und sind dann n her auf die im Sonderforschungsbereich IMPROVE entstandene verfahrenstechnische Ent wurfsumgebung PRIME IMPROVE eingegangen Von den bisherigen PRIME Anwendungen war die
490. rden Eine Schnittstellenbindung besteht daher aus mehreren Beh lterbindun 156 6 Interoperabilitat von Prozesssprachen gen die jeweils einen Situationsteil der Komponentenschnittstelle an das identifi zierte Parameterkonzept der Prozesssprache binden Bei der Abbildung muss gew hrleistet sein dass die Komponentenschnittstelle vollst ndig an den Datenfluss in der PK Komponente angeschlossen ist d h dass 1 alle deklarierten Situationsteile tats chlich an eine Datenbeh lter Instanz der Verwendungssprache gebunden werden und dass diese Abbildung 2 injektiv und 3 eindeutig ist Dies kann bereits auf der Ebene des M2 Modells durch O Telos Metaregeln zugesichert werden da alle integrierten Prozesssprachen ein Datenbe h lter und Schnittstellen Konzept instanziieren und so die Metaregel auf deren Instanzen Bezug nehmen kann F r die Formalisierung der dargestellten Integrit tsbedingungen sind drei O Telos Zusicherungen erforderlich von denen hier nur eine exemplarisch dargestellt wird die formale Darstellung der beiden anderen Zusicherungen findet sich in Schm99 MetametaClass SchnittstellenBindung in Class with constraint alleGebunden vgl Schm99 einfacheBindung vgl Schm99 injektiv 7 forall ssb pbl pb2 p1 p2 q91 q92 VAR al a2 a3 a4 a5 a6 11 12 13 14 15 16 VAR SSB SchnittstellenBindung BB BehalterBindung B Datenbeh lter PSB Beh lterBindung prozesssprachenKonzept KKB Beh lterBind
491. rdisierte Protokolle f r vordefinierte Werkzeugklassen ToolTalk objektorientierte Sichtweise auf Nachrichten und Werkzeuge ohne jedoch etwas am grunds tzlichen Integrationsprinzip zu ndern w hrend der Sender einer Nachricht durch die Indirektion ber den Message Server von den m glichen Kommunikationspartnern entkoppelt ist liegt das Wissen ber die tichtige Reaktion auf eine Nachricht d h die Umsetzung einer Nachricht in einen effektiven Dienstaufruf beim Empf nger Werkzeug Dies erschwert die Anpassbarkeit der dadurch inh rent in den Werkzeugen festgelegten Abl ufe erheblich In Hinblick auf die geforderte prozessorientierte Adaptabilit t der Interakti onsbeziehungen zwischen Werkzeugen bzw ihren Diensten f hrt dies zu der en Forderung dass die Interaktionspartner noch st rker voneinander entkoppelt Verarbeitung und en aoe QE Sue ka Sone ies PP Koordination werden m ssen Die auch in ganz anderen Zusammenh ngen MaCr94 anzu treffende L sungsidee besteht in einer konsequenten Trennung und orthogona len Behandlung der Aspekte Verarbeitung Werkzeuge deren Dienste und Ereig nisse und Koordination Organisation des Verhaltens einer Gruppe von Werkzeu gen durch Verwaltung und Steuerung ihrer Dienste Die bei der Komposition von Werkzeugdiensten zu komplexeren Abl ufen auftretenden Interaktionsbeziehun gen sind nicht mehr Teil der Werkzeuge selbst sondern werden in eine eigene Komponente verlagert D
492. re ACM Transactions on Software Engineering and Methodology 4 4 S 319 364 1995 Abadi M und Cardelli L A Theory of Objects Springer Verlag New York 1996 Abeln O CAD Referenzmodell B G Teubner Verlagsgesellschaft Stuttgart 1995 Armenise P Bandinelli S Ghezzi C und Morzenti A A Survey and Assessment of Software Representation Formalisms International Journal of Software Engineering and Knowledge Engineering 3 3 S 410 426 1993 Alderson A Meta CASE Technology In Proceedings of the European Symposion on Software Development Environments and CASE Technology Springer Verlag LNCS 509 1991 S 81 91 Allan R A Formal Approach to Software Architecture Tech Report Carnegie Mellon University CMU CS 97 144 1997 Alonso G Agrawal D El Abbadi A Kamath M Guenthoer R und Mohan C Advanced Transaction Models in Workflow Contexts In Proceedings of the 12th Interna tional Conference on Data Engineering New Orleans Louisiana USA IEEE Com puter Society Press 1996 S 574 583 Ambriola V Conradi R und Fuggetta A Assessing Process Centered Software Engineer ing Environments ACM Transactions of Software Engineering and Methodology 6 3 S 283 328 July 1997 Andries M Engels G Habel A Hoffmann B Kreowski H J Kuske S Plump D Sch rr A und Taenzer G Graph Transformation for Specification and Pro gramming Science of Computer Programming 34 1 S
493. re Users In Proc 14th Conference on Uncertainty in Artificial Intelligence Madison WI 1998 S 256 265 ter Hofstede A H M und Verhoef T F On the Feasibility of Situational Method Engi neering Information Systems 22 6 7 S 401 422 1997 Huff K E Software Process Modeling In Fuggetta A und Wolf A L Hrsg Trends in Software Process John Wiley amp Sons New York Trends in Software Vol 4 1996 S 1 24 Humphrey W S Managing the Software Process Addison Wesley 1989 IBM Business Systems Planning Information Systems Planning Guide Application Manual IBM Corporation 1984 IEEE95 liva96 Iona00 IRDS90 ISO 91 ISO 94 ISO 95 JaBR99 JaBu96 JaDB89 JaJa95 aHu98 aJ Q99 JaL W99 JaMa906 Jann92 Dar 95 Dar 98 Dar 98a Java98 JCJO92 JePa97 Jeus92 Literaturverzeichnis 289 IEEE IEEE Standard for Developing Software Life Cycle Processes Tech Report IEEE 1074 1995 Iivari J Why are CASE Tools not used Communications of the ACM 39 10 S 94 103 1996 Iona Technologies OrbixCOMer 2000 http www iona com products orbix comet htm IRDS Information Technology Information Resource Dictionary System IRDS Framework Tech Report ISO IEC ISO IEC 10027 1990 ISO ISO 9000 3 Quality Management and Quality Assurance Standards International Organization for Standardization Genf Schweiz 1991 ISO Industrial Au
494. rei hi diensteih COS das Konzept der event channels spezifiziert OMG 97b und in einigen CORBA und DCOM Implementationen realisiert EIMC97 In DCOM steht mit den event sinks bzw den connectable objects ein hnlicher Mechanismus zur Ereignisverteilung zur Verf 78 3 Integrationsansatze gung EdEd98 Mit diesen Diensten lassen sich auch in CORBA und DCOM Architekturen nach dem Message Broadcasting Prinzip emulieren allerdings nur auf vergleichsweise niedrigem logischen Niveau CuDF98 PaSa96 F r eine weiterf hrende detaillierte Gegen berstellung verschiedener ereignis basierter Integrationsans tze sei der Leser auf den EBI Klassifikationsrahmen von Barrett et al BCTW96 verwiesen Abschlie end weisen wir noch darauf hin dass sich das hinter dem Message Broadcasting Ansatz steckenden Entwurfsprin zip des impliziten Aufrnfs nicht nur bei der Integration von Entwurfsumgebungen sondern auch in ganz anderen Kontexten z B aktive Datenbanken DiGa00 inkrementelle Attributauswertung TeRe88 automatische Typumwandlung ClOs90 D monen auf Betriebssystemebene HaNo86 oder Blackboard Architekturen in KI Systemen JaDB89 Anwendung findet Mediator Ans tze Die oben skizzierten Ans tze zum impliziten Aufruf zeigen zwar eine ganz deutliche Weiterentwicklung des Message Broadcasting Konzepts hinsichtlich der zugrunde liegenden Nachrichten und Werkzeugmodelle FIELD unstrukturierte Nach richten SoftBench standa
495. reich Nachbereich Q Stelle Prozesssprachen konzept SLANG_SB Prozesssprachen konzept sprachneutrale Darstellung In Schritt 3 werden erganzend zu den bereits durch die M2 Ebene vorgegebenen sprachneutralen Bindungsregeln die eine korrekte Abbildung der Schnittstellen struktur in der Verwendungssprache sicherstellen zus tzliche sprachspezifische Abbildungsregeln hinzugef gt Diese Regeln sind auf der mittleren sprachspezifi schen Ebene in Abb 31 angesiedelt Im konkreten Fall der SLANG Integration m ssen wir die Typsicherheit der abgebildeten Schnittstellenparameter gew hrleisten und die Abbildung von EK Komponenten in einem SLANG Netz festlegen Typisierung der Die Forderung nach Typsicherheit verlangt dass ein im Schnittstellenmodell Beh lterbindung definiertes Produktteil und die Stelle die diesen Produktteil in einem SLANG Netz repr sentiert den gleichen Typ haben Dies wird durch die O Telos Zusiche rung typGleichheit gew hrleistet MetaClass SLANG PB in Beh lterBindung with Constraint typGleichheit forall spb SLANG PB p Produktteil tp ts Lyp spb sprachneutraleDarstellung p and p hatTyp tp and spb ProzesssprachenKonzept s and s hatTyp ts gt tp tSS end Die gew hlte Kontextalternative einer EK Komponente muss in SLANG geeignet repr sentiert werden damit der Kontrollfluss in Abh ngigkeit von der gew hlten Alternative verzweig
496. ren m glichen Zustands ber g ngen aus dem Zustand User Choice Welcher Zustands bergang konkret aus gel st wird h ngt von der Kontextkategorie des Kontexts c und seiner Zuord nung zu einer Werkzeugkategorie ab Es sind folgende F lle m glich O cistein werkzeuginterner Entscheidungskontext Dann geht das Werkzeug in den Zustand Choice Context Active ber Iransition 3 Damit verbleibt das Werkzeug quasi im Super Zustand User Choice Allerdings werden beim Wieder Eintritt in diesen Zustand 25 Es kann pro Werkzeugkategorie durchaus mehrere Standardkontexte geben die sich dann durch ihren Situationsteil unterscheiden Beispielsweise kann die Situation vorliegen dass noch kein Produkt geladen wurde oder die Situation dass bereits ein Produkt eines bestimmten Typs geladen wurde 7 2 Interaktionsprotokoll zwischen den Prozessdomanen 185 die Interaktionsm glichkeiten des Benutzers auf die f r den Entscheidungskontext c definierten Alternativen angepasst O cistein werkzeuginterner Ausf hrungskontext Dann geht das Werkzeug in den Zustand Executable Context Active ber Transition 4 und f hrt die im Umgebungsmodell mit dem Ausf hrungskontext c assoziierte Werkzeugaktion aus Nach Beendigung der Werkzeugaktion kehrt das Werkzeug in den Zustand Standard Context Active zur ck Transition 5 Dabei werden die Interaktionsm glichkeiten des Benutzers auf die f r den Standardkontext definierten Alternativen angepasst
497. rende Detailstruktur des StateManager Teilsystems auf Klassenebene Jeder Zustand und jede Transi tion wird als Subklasse der abstrakten Klassen CsttState bzw CsttTransition realisiert Die Topologie eines aus spezifischen CsttState und CsttTransition Objekten aufgebauten Zustandsdiagramms wird innerhalb der Klasse CsttSta teDriver organisiert Die Zustands und Transitionsklassen steuern den Aufruf der brigen GAR PIT Komponenten z B in den Teilsystemen ContextManager oder MessageInter face Diese Kontrollfunktionalitat wird entsprechend dem UML Standard f r Zustandsdiagramme in den Methoden doEntry doActivity und doExit beim Eintritt in Verweilen in und Verlassen von Zust nden bzw doAction w hrend einer Transition hinterlegt Diese Methoden sind als virtuelle leere Methoden in den Klassen CsttState bzw CsttTransition vordefiniert und werden bei Bedarf in den jeweiligen Subklassen redefiniert und mit spezifischer Funktionalit t gef llt Beispielsweise ruft die doEntry Methode der CsttWaitingForLockRequest Klasse die disableUserInput Methode des Teilsystems GenericGUI auf Jede CsttTran sition Subklasse verf gt weiterhin ber geerbte und evt berschriebene check Event und checkCondition Methoden Mit diesen Methoden realisiert eine CsttTransition Klasse den Test ob das aktuell anliegende Ereignis die Transition schalten kann und ob die eventuell zus tzlich geforderten Bedingungen gelten Tab 10 a
498. reters in das GARPEM Rahmenwerk zwingend erforderlich sind Diese Dienste sind keine Variationspunkte da sie weitgehend unabh ngig von einer spezifischen Sprache sind Dazu geh rt z B die Anbindung an den PRIME Kommunikations mechanismus und die Datenbankanbindung Zur Kl rung wollen wir abschlie end noch einmal betonen dass die Interpre terfunktionalit t auf die sprachlichen und technischen Klassen der Sprachelemen teschicht und der administrativen Interpreterschicht verteilt ist so dass Interpreter hier nicht als eigenst ndige Entit ten innerhalb der GARPEM Architektur auftre ten Die Verteilung der Funktionalit t ist ein Effekt des objektorientierten Ent wurfs da hier die Konzepte der Dom ne sowie deren Verantwortlichkeiten im Vordergrund stehen und keine funktionale Dekomposition des Systems vorge nommen wird Der Interpretationsvorgang zieht daher alle Klassen der oberen beiden Schichten des GARPEM Rahmenwerkes mit ein da ber die Schnittstellen die Verantwottlichkeiten der Klassen realisiert werden 7 5 3 Kontrollmodell Bei der Realisierung eines allgemeinen Rahmenwerkes f r die Integration von verschiedensprachlichen Prozesssprachen Interpretern ist der Kontrollfluss inner halb des Rahmenwerkes von entscheidender Bedeutung Das Interpreterrahmen werk muss sowohl flexibel die unterschiedlichen Kontrollflussparadigmen der einzelnen Prozesssprachen ber cksichtigen als auch gen gend Unterst tzung bieten um Interpreter
499. rk zeugs auf ein Ereignis Notifikation au erhalb des Werkzeugs durch die policy description bestimmt wird Mit Hilfe einer null Aktion wird eine Nachricht kom plett ignoriert Des weiteren k nnen neue Nachrichten an den Message Server selbst geschickt werden wodurch die Auswertung weiterer policy descriptions initiiert wird Die policy descriptions tragen also im Vergleich zu Message Broadcasting Archi tekturen st rker dazu bei Prozesswissen aus den Werkzeug zu ziehen und auf einer externen adaptablen Ebene zu repr sentieren Der Message Server r ckt dadurch von der Rolle eines passiven Nachrichtenverteilers in die eines aktiven Mediators det die Interaktionsbeziehungen zwischen Werkzeugen koordiniert Gea ies Die Mediation des Forest Message Servers kann man jedoch auf Grund der einge riptions schrankten Ausdrucksm chtigkeit der policy description noch nicht als prozessorien tiert bezeichnen Insbesondere lassen sich keine mehrschrittigen Abl ufe steuern da der Message Server bei der Auswertung der policy descriptions immer nur die aktuell eingetroffene Nachricht ber cksichtigt und keinen Ablaufkontext aufbe wahrt Einen von der Grundidee mit Forest vergleichbaren Ansatz verfolgt die Too T Skripte in ToolBus Bus Architektur BeK196 Wie in Forest kommunizieren die Werkzeuge auch hier ber einen Message Server der hier als Too Bus bezeichnet wird Die Interaktion zwischen Werkzeugen wird hier durch so genannte T Skripte gesteue
500. rke relativiert sich jedoch durch die Tatsache dass in PZEUen Prozesse in der Regel lediglich auf der f r das Projektmanagement ausreichenden relativ grobgranularen Ebene mo delliert werden Aus diesem Grund f llt die kontextbezogene Unter st tzung bei der Durchf hrung feingranularer Aufgaben durch den techni schen Entwickler relativ unpr zise aus Au erdem spiegelt sich wegen der mangelnden Integration der Prozessmodellinterpretation mit der eigentli chen Arbeitsumgebung die im aktuellen Prozesszustand g ltige Prozess anleitung nicht im Verhalten der Entwurfswerkzeuge wider 0 Anpassbarkeit Eine wesentliche St rke von PZEUen liegt in ihrer An passbarkeit an Prozess nderungen da f r die zu unterst tzenden Prozesse explizite Prozessmodelle vorliegen Da die Prozessmodelle in der Regel auf vergleichsweise hohem logischem Niveau ansiedelt sind und die Ausf h rung von Prozessmodellen in den meisten Ans tzen durch einen Prozess modell Interpreter erfolgt verursachen Prozess nderungen prinzipiell ei nen verh ltnism ig geringen Aufwand Die nderungsfreundlichkeit der Prozessunterst tzung h ngt allerdings auch davon ab ob der zugrunde lie genden Prozessmodellierungsformalismus auch von Programmiersprachen gew nschte Eigenschaften wie Modularit t Kapselung und Wiederver wendung unterst tzt Q Unterst tzungsmodi Existierende PZEUen bzw die ihnen zugrunde lie genden Prozessmodellierungsans tze tendieren dazu Entwi
501. rlichen sprachspezifischen Interpreter wird in Abschnitt 7 4 im Detail beschrieben bis jetzt wurden auf Basis des GARPEM Frameworks Plankontext Interpreter f r die Formalismen SLANG und UML Statecharts erstellt und integriert Dar ber hinaus ist es bereits seit der ersten Version des PRIME Rahmenwerks m glich Plankontexte als C Methoden zu definieren und in kompilierter Form direkt zum GARPEM Framework zu binden 7 1 2 3 Kommunikationsmanager Wie bereits angedeutet wird das Interaktionsprotokoll zwischen der Prozessma schine und den Werkzeugen vollst ndig von generischen Komponenten der jewei ligen Frameworks realisiert Bei der Interaktion zwischen den Prozessdom nen werden wechselseitig Kontextanforderungen und resultate in Form von Nach richten ausgetauscht Dabei interagieren Prozessmaschine und Werkzeuge aus den in Abschnitt 3 3 3 diskutierten Gr nden nicht in direkten Punkt zu Punkt Beziehungen miteinander sondern ber einen Kommunikationsmanager der die Kommunikationspartner voneinander abschottet Der Kommunikationsmanager entspricht einer Message Server Komponente in Message Broadcasting Architek turen siehe auch Abschnitt 3 3 3 sorgt jedoch im Gegensatz zu Ans tzen wie Field Reis90 Reis90a Softbench Caga90 oder ToolTalk Fran91 Suns93 f r eine prozessmodellkonforme Verteilung der Kontextnachrichten d h die Auslieferung von Kontextnachrichten wird entsprechend der Zuordnung zwischen Kontexten und Werkzeugka
502. rlin Heidelberg LNCS 742 1993 S 43 60 Plihon V und Rolland C Modelling Ways of Workings In Proceedings of the 7th International Conference on Advanced Information Systems Engineering CAISE 95 Jyv skyl Finnland 1995 S 126 139 Pohl K Weidenhaupt K D mges R Haumer P Jarke M und Klamma R PRIME Towards Process Integrated Environments ACM Transactions on Software Engi neering and Methodology 8 4 S 343 410 1999 Pohl K und Haumer P HYDRA A Hypertext Model for Structuring Informal Require ments Representations In Proceedings of the 2nd International Workshop on Requre ments Engineering Foundation of Software Quality Jyvaskyla Finnland 1995 S 118 134 Pohl K The Three Dimensions of Requirements Engineering A Framework and Its Applica tions Information Systems 19 3 S 243 258 1994 Pohl K A Process Centered Requirements Engineering Environment Dissertation RWTH Aachen 1995 Pohl K Process Centered Requirements Engineering Research Studies Press 1996 Pohl K Let s Put the Stakeholders Performing the Process in the Driver s Seat In Proceed ings of the International Workshop on Research Directions in Process Technology Nancy Frankreich 1997 Pohl K Continuous Documentation of Information Systems Requirements Habilitation RWTH Aachen 1999 Popien C Sch rmann G und Wei K Verteilte Verarbeitung in Offenen Systemen B G Teubner Verlagsgesellschaft
503. rnativen beraten Hier muss zun chst gekl rt werden was unter der Ausf hrung einer EK Komponente berhaupt zu verstehen ist Prinzipiell sind zwei Interpre tationsm glichkeiten denkbar Zum einen k nnte man unter der Ausf hrung einer EK Komponente lediglich den Dienst der Auswahl einer Alternative durch den Benutzer nicht aber deren Ausf hrung verstehen Diese Sichtweise die in einer fr heren Version des PRI ME Rahmenwerks eingenommen wurde erwies sich aus einer Reihe von Gr nden als wenig vorteilhaft Q An jedem Verwendungspunkt einer EK Komponente muss die anschlie Bende Ausf hrung der gew hlten Alternative explizit spezifiziert werden Da die Auswahl zudem nichtdeterministisch vom Benutzer abh ngt m s sen jeweils alle potenziellen Alternativen ber cksichtigt werden Dies ist aufw ndig und auch fehlertrachtig wenn eine Alternative zu einer EK Komponente hinzugef gt oder aus dieser entfernt wird m ssen alle PK Komponenten die die EK Komponente verwenden entsprechend ange passt werden Q Da die Alternativen einer EK Komponente am Verwendungspunkt direkt sichtbar sind muss die Alternativenauswahl in der spezifischen Prozess sprache der verwendenden PK Komponente dargestellt werden Hier er gibt sich jedoch die Gefahr semantischer Unterschiede wenn die Alterna tiven z B in imperativen Sprachen durch bedingte Verzweigungen und in Petrinetzsprachen durch parallele Transitionen dargestellt w rden Damit w re jed
504. rojektplans und unter Verwendung der zur Verf gung stehenden Ressourcen das Projektpersonal angeleitet und motiviert sowie der Projektfortschritt und Ressourcenverbrauch kontrolliert vgl Aufgabenbereich Anleitung und Kontrolle in Abb 1 Die Entwickler am Arbeitsplatz werden ber die aktuell anstehenden Aufgaben informiert und mit den daf r erforderlichen Arbeitsanweisungen und Ressourcen versorgt Die zeit und kostengerechte Erf llung der Aufgaben wird anhand der vorher definierten Meilensteine berpr ft Bei Abweichungen werden gegebenenfalls korrigierende Ma nahmen veranlasst z B Anpassungen des Terminplans Budgeterh hungen personelle Ver nderungen oder gar die Redefinition der Projektziele Auf diese Weise wird das Zusammenspiel von Entwicklungsaufgaben und Entwicklern koordiniert und kontrolliert 2 1 1 2 Arbeitsplatzebene Durchf hrung von Prozessunterst tzung auf der Arbeitsplatzebene befasst sich mit der methodischen Aufgaben Anleitung des einzelnen Entwicklers bei der systematischen Durchf hrung von Aufga ben die ihm vom Projektmanagement zugewiesen wurden Die in einem typischen Software Entwicklungsprozess anfallenden technischen Aufgaben lassen sich in unterschiedliche Arbeitsbereiche einordnen u a werden Anforderungsanalyse Systementwurf Implementierung Test Installation Dokumentation Wartung und 2 1 Ein Klassifikationsmodell fur Prozessunterstutzungsfunktionen 13 Qualitatssicherung unterschieden Nagl90
505. rollmodell Einbettung existierender Prozesssprachen jg kontextbasiertes Rahmen Prozessrgpdell Instanziierte J Prozessfragmente a Werkzeug Kapitel 5 definitionen Integrierte Prozess und Werkzeugmodellierung Datenintegration Dienstintegration Grundlage f r x Prozesssensitive UI Generische Korrekte R ckmeldungen A Aufruf von Prozessfragmenten Prozess Kapitel 7 maschinen Generische Frameworks fiir Architektur erkzeuge und Prozessmaschinen Prozesssensitive Werkzeuganpassung Aufruf von Prozessfragmenten Interaktionsprotokoll zwischen Leit und Durchf hrungsdom ne Leitdom ne 5 1 Darstellung der Modelle 109 Integrierte Prozess und Werkzeugmodelle zite Modellierung von Prozessen und Werkzeugen auf der gleichen konzeptu ellen Ebene eine der tragenden Saulen unseres Konzepts fur die Prozessinteg ration von Werkzeugen darstellt Diesen Grundgedanken wollen wir nun vertiefen und geeignete Metamodelle d h Sprachen zur integrierten Definition von Pro zessfragmenten und Werkzeugen vorstellen iE voran gegangenen berblickskapitel haben wir argumentiert dass die expli In Abschnitt 5 1 geben wir als Vorbereitung zun chst einen kurzen berblick ber die Notationen die wir in diesem und den nachfolgenden Kapiteln zur Dar stellung der unterschiedlichen Modelle und Metamodelle verwenden werden Bei der Definition des integrie
506. rozessmodellierungs Interoperabilit t durch sprachen durch eine gemeinsame Zwischensprache wie z B WPDL PIF oder PSL Transformation realisiert die allgemeine Konzepte von Modellierungssprachen subsummiert siehe Abschnitt 6 2 1 2 und Abb 25a Die Integration erfolgt durch die Definition von Transformationsbeziehungen zwischen den Konzepten der zu integrierenden Prozessmodellierungssprachen und der Zwischensprache Bei Verwendung einer Fragmentes wird die Zwischensprache daf r genutzt das Fragment in die Ziel sprache des verwendenden Fragmentes zu bersetzten Verwendet ein Fragment A ein Fragment B dann wird das Fragment B vollst ndig durch Transformation ber die Zwischensprache in die Sprache A bersetzt Der Integrationspunkt liegt beim Transformationsansatz in der Modellierungsdomi ne so dass die Interoperabilit t von Prozesssprachen Interpretern in der Leitdom ne eine untergeordnete Rolle spielt Der Hauptvorteil dieser Vorgehensweise ist darin zu schen dass die Zwischen sprache die einzelnen Formalismen vereinheitlicht und somit verschiedensprachli che Teilprozesse in einem bergreifenden Gesamtprozess einheitlich dargestellt 142 6 Interoperabilitat von Prozesssprachen analysiert und administriert werden k nnen vgl auch Wf MC Interoperabili t tsstufe 6 Abschnitt 6 2 1 1 Die Annahme dass die Zwischensprache in der Lage ist alle Prozessmodellierungskonzepte zu vereinigen ist jedoch idealisiert LeYo94 W
507. rst tzen Plankontexte jedoch l ngerfristige Akti vit ten durch die Angabe einer Reihenfolgebeziehung zwischen Teilschritten Mithilfe von Plankontexten lassen sich somit Dekompositionsstrukturen modellieren w hrend durch Entscheidungskontexte Verfeinerungsstrukturen dargestellt werden Zur Darstellung des Kontrollflusses zwischen den Subkontexten eines Plankon texts wird in RoSM95 Pohl96 das Prozessmodell um explizite Pr zedenzgraphen zwischen Kontexten erweitert In der in Abb 19 dargestellten Version des Pro zessmodells haben wir darauf jedoch verzichtet Stattdessen werden wir in Kapitel 6 ein flexibleres Konzept vorstellen das die Einbettung und interoperable Ver wendung weitgehend beliebiger Kontrollflussformalismen im Rahmen des NA TURE Modells erlaubt Plankontext Aus der Tatsache dass Entscheidungskontexte und Plankontexte selbst wieder rekursiv durch Kontexte beliebigen Typs verfeinert beziehungsweise dekompo f f u BR i 5 Kontexthierarchien niert werden k nnen resultiert eine freie Kombinierbarkeit von automatisierenden pilden Und Oder Ausf hrungskontexten beratenden Entscheidungskontexten und anleitenden B ume Diensten Plankontexten Die durch die Schachtelung von Kontexten gebildeten Hierarchien weisen starke Parallelen zu den aus der Planungstheorie der K nstli chen Intelligenz bekannten Und Oder Zielb umen MyCN92 auf Die Assozia tion zwischen einem Entscheidungskontext und seinen alternative
508. rt T Skripte aggregieren Basisfunktionalitaten von Werkzeugen zu h herwertigen Diensten indem sie eine Folge von Kommunikationsprimitiven f r das Empfangen und 80 3 Integrationsansatze Senden von Nachrichten mit Hilfe der Operatoren Sequenz Alternative und Iteration verketten Die T Skripte werden von den Autoren selbst als prozessorien tiert bezeichnet sind jedoch auf einem sehr niedrigen technischen Abstraktionsni veau angesiedelt Prozessorientierte Mediation in prozesszentrierte Umgebungen Einen Schritt weiter in Richtung einer prozessorientierten Mediation der Werkzeug interaktionen geht die Kombination von Message Broadcasting Architekturen mit Prozessmodellen und maschinen wie sie in einer Reihe von prozesszentrierten Entwicklungsumgebungen z B SPADE BBFL94 BFGL94 BaDF96 Merlin JPSW94 ProcessW eaver Fern93 SMART Gar 94 anzutreffen ist Die wesentli chen Merkmale der Werkzeugintegration innerhalb dieser Klasse von Systemen SFGJ99 lassen sich stellvertretend gut am Beispiel der Architektur der SPADE Umgebung illustrieren siehe Abb 13 die anderen genannten Umgebungen ver folgen eine analoge Integrationsstrategie wobei die zugrunde liegenden Pro zessmodellierungssprachen allerdings stark differieren SPADE In SPADE besteht das user interaction environment also die Durchf hrungsdo m ne aus der DEC Fuse Umgebung einer Sammlung von Programmierwerkzeu gen Editoren Compiler Debugger etc welche
509. rte Werkzeuge f r das Programmieren im Kleinen integriert worden sind Entsprechend simpel ist das Format von Nachrichten und Nachrich tenmustern gehalten Das Softbench Rahmenwerk von Hewlett Packard ist ein kommerzieller Nachfol SoftBench ger der Field Umgebung der eine Reihe interessanter Erweiterungen aufweist Caga90 BrEM92 Bro 94 FrWa93 FIELD DO Werkzeuge werden vordefinierten Werkzeugklassen z B Editor Compiler Debugger zugeordnet f r die jeweils ein Werkzeugprotokoll d h ein Satz von Standardnachrichten spezifiziert wurde die jedes Werkzeug dieser Klasse verstehen sollte Zum Beispiel sollten alle Texteditoren auf die Nachricht dass in einem Textfile in einer bestimmten Zeile ein Fehler auf getreten ist entsprechend reagieren k nnen indem sie die betreffende Textdatei ffnen und an die fragliche Stelle springen Auf diese Art und 8 Da im Allgemeinen nicht alle Werkzeugen an allen Ereignissen interessiert sind w re brigens selektives Musticasting eine korrektere Bezeichnung f r diesen Mechanismus zur Nachrichtenvertei lung als Broadcasting FIELD Friendly Integrated Environment for Learning and Developing 76 3 Integrationsansatze Weise ist ein Mindestma an semantischem Verst ndnis zwischen den Werkzeugen gew hrleistet und Werkzeuge ein und der selben Klasse k n nen untereinander ausgetauscht werden Q Ein spezielles Softbench Werkzeug der Encapsulator erleichtert die Einbin dung von
510. rten Prozess und Werkzeugmodells gehen wir schritt weise vor In Abschnitt 5 2 grenzen wir auf Basis der in Kapitel 3 aufgestellten Anforderungen die Gegenstandsbereiche des Prozess und des Werkzeugmodells voneinander ab und arbeiten auf informaler Ebene die inhaltlichen Querbez ge zwischen den beiden Modellen heraus In Abschnitt 5 3 stellen wir das NATURE Prozessmetamodell vor das uns als Ausgangspunkt f r die kontextbasierte Defini tion von Prozessfragmenten dient Abschnitt 5 4 behandelt die in dieser Arbeit entwickelte Erweiterung des NATURE Prozessmodells um Konzepte zur Werk zeugmodellierung Die Integration des Prozess und des Werkzeugmetamodells innerhalb des so genannten Umgebungsmetamodells wird in Abschnitt 5 5 be schrieben Abschnitt 5 6 illustriert die Verwendung der Metamodelle anhand eines kleinen Beispiels und Abschnitt 5 7 fasst die wesentlichen Beitr ge dieses Kapitels zusammen 5 1 Darstellung der Modelle F r die Darstellung der in diesem und den nachfolgenden Kapitel vorgestellten konzeptuellen Modelle und Metamodelle ben tigen wir geeignete Formalismen Hierbei st tzen wir uns auf allgemein etablierte Basiskonzepte Strukturierungs und Abstraktionsprinzipien des objektorientierten Paradigmas ab und notieren unsere Modelle als UML Klassendiagramme und formalisieren sie sofern erfor derlich und hilfreich zus tzlich mit Hilfe der logikbasierten Modellierungssprache O Telos 110 5 Integrierte Prozess und Werkze
511. s 6 2 1 2 Austauschformate WPDL Die in unserem Kontext relevante Integration von Prozessfragmenten auf Modellie rungsebene wird im WfMC Referenzmodell erst auf der Interoperabilit tsstufe 6 betrachtet Im Rahmen des Workflow Process Definition Interface WAPI 1 siehe Abb 23 hat die W MC dazu die Sprache WPDL definiert die als neutrales Zwi schenformat f r den Im und Export von Prozessfragmenten zwischen den Pro zessmodellierungswerkzeugen unterschiedlicher Workflowmanagementsysteme dient Dazu m ssen auf beiden Seiten entsprechende Konverter vorhanden sein die die in den jeweiligen propriet ren Sprachen formulierten Prozessmodelle in eine WPDL Darstellung berf hren Der Grundgedanke von WPDL sowie weite rer Austauschformate siehe unten besteht darin die Konzepte der Prozessspra chen in einer einzigen Zwischensprache zu vereinigen und zu homogenisieren die dann als Integrationspunkt zwischen den einzelnen prozessbasierten Systemen genutzt 136 6 Interoperabilitat von Prozesssprachen werden kann Die Prozessdefinition in WPDL beschreibt die Elemente eines Workflows und umfasst die Deklaration der beteiligten Aktivit ten Transitionen Applikationen und Prozessdaten Der Kontrollfluss zwischen Aktivit ten wird mit Transitionen spezifiziert die eine sequentielle oder parallele Ausf hrungsreihen folge festlegen F r den Export eines Prozessfragmentes werden die beteiligten Aktivit ten Applikationen und Prozessdaten im For
512. s formalismen Die Detailarchitektur und Realisierung von GARPEM wird in Ab schnitt 7 5 beschrieben Beide Frameworks sind durch die gemeinsam genutzten Anteile des Umge bungsmodells sowie ber das in Abschnitt 7 2 noch zu beschreibende Interakti onsprotokoll aufeinander abgestimmt und st tzen sich konsequenterweise auf eine Reihe gemeinsam verwendeter Basiskomponenten ab Ein wichtiges Kennzeichen des PRIME Rahmenwerks ist dass die komplette Integration zwischen den Pro zessdom nen bereits auf Frameworkebene und durch die modellierungsseitige Verzahnung der Prozess und Werkzeugmodelle im Umgebungsmodell vorwegge nommen ist Ein Umgebungsentwickler der eine prozessintegrierte Entwicklungs umgebung auf Basis des PRIME Rahmenwerks erstellt braucht sich also um die architekturelle und technische Integration zwischen Modellierungs Durchf h rungs und Leitdom ne nicht mehr zu k mmern 169 GARPIT ein Sub Framework f r prozess integrierte Werkzeugen GARPEM ein Sub Framework f r Pro zessmaschinen Das Framework Uber nimmt die architekturelle und technische Integ ration der Prozessdo manen 170 Abb 34 Grobarchitektur einer PRIME basierten Model lierungsumgebung 7 Das PRIME Rahmenwerk 7 1 2 berblick ber die Gesamtarchitektur SLANG Statechart XYZ C Prozess Interpreter Interpreter Interpreter fragmente Generisches Prozessmaschinen Framework GARPEM Nachrichten Leitdom ne Kommunik
513. s und Tradingdienste gewon nene Flexibilit t allerdings nur wenig bei da diese Mechanismen im Wesentlichen die Orttransparenz der Bindung zwischen Werkzeugen beg nstigen d h die Werk zeuge m ssen nicht statisch zur bersetzungszeit ihre Kommunikationspartner kennen Prozessrelevantes Ablaufwissen dr ckt sich jedoch genau wie beim py a direkten Prozeduraufruf immer noch dutch ein Geflecht von Punkt zu Punkt hungen zwischen Beziehungen zwischen den beteiligten Werkzeug Objekten aus Brow93 Gall90 verschiedenen Werk Diese Interaktionsabfolgen sind nicht explizit d h unabh ngig von den beteiligten zeugobjekten Werkzeugen definiert sondern manifestieren sich lediglich implizit in den vom aufrufenden Werkzeug initiierten Bindungen und sind als Codeabschnitte ber die Objektmethoden der einzelnen Werkzeuge verteilt PaSa96 Abl ufe als Geflecht von Message Broadcasting In so genannten Message Broadcasting Architekturen kommunizieren Werkzeuge ber den Austausch von Nachrichten Zentraler Bestandteil von Message Server Architekturen ist ein so genannter Broadcast Message Server BMS der f r die Ent Unterscheidung zwi gegennahme Weiterleitung und Verteilung von Nachrichten sowie die Verwaltung schen Kommandos und der laufenden Werkzeuginstanzen zust ndig ist Nachrichten werden unterschie Nachrichten den in Kommandos und Notifikationen Kommandos werden an ein Werkzeug oder eine Gruppe von Werkzeugen geschickt werd
514. s DeaktivierteProduktinstanzen isa Class with parameter ek Entscheidungskontext constraint ce not this in SelektierbareProduktinstanzen ek ek end Die erste Anfrage verwendet eine so genannte Metaformel mit der Klassenvariab len p da Produktinstanzen referenziert werden m ssen deren Klassen zum Mo dellierungszeitpunkt noch nicht bekannt sind Generell haben die Anfragen jedoch den Nachteil dass sie a e im Repository vorhandenen Produktinstanzen betrach ten Tats chlich sind jedoch nur die aktuell im Werkzeug geladenen und angezeig ten Produktinstanzen von Interesse In der konkreten Implementierung siehe Abschnitt 7 3 nutzen wir diese Einschr nkung aus und k nnen so die betroffenen Produktinstanzen effizient ermitteln Abbildung von Intentionen auf Kommandoelemente Um die Aktivierung der Alternativen C C des Entscheidungskontexts EK in einer Werkzeugkategorie W zu erm glichen muss die Darstellung aller Intentionen von Cj C durch Kommandoelemente von W festgelegt werden Da eine Inten tion z b sche mit mehreren Kontexten z B l sche_Entit t und l sche_Attribut assoziiert sein kann ist eine kontextabh ngige Zuordnung der Intention zu den Kommandoelementen erforderlich Deshalb wird jeder alternative Kontext C und nicht seine Intention ber eine Assoziation vom Typ Darstel lung Intention mit einem oder mehreren Kommandoelementen verkn pft 126 5 Integrierte Prozess und Werkzeu
515. s Werkzeugsicht definiert eine Situation eine Konstellation von Produkten die vom Benutzer in der Benutzeroberfl che des Werkzeugs durch Selektion Markie rung o als aktiv ausgewiesen wurden Um solche Produktkonstellationen cha rakterisieren zu k nnen haben wir als Verfeinerung des Situationsbegriffs des NATURE Prozessmodells eine einfache Situationssprache entwickelt deren Me tamodell in Abb 55 repr sentiert ist Die Beschreibung eines Situationstypen zur Laufzeit repr sentiert durch ein Objekt der Klasse CcxtSituationDesc besteht aus einem oder mehreren getypten Situationsteilen CcxtSituationPart Die 34 Situationstyp Beschreibungen werden im Prozessrepository persistent abgelegt Aus diesen Beschreibungen werden Laufzeit Objektstrukturen der korrespondieren Klassen im Teilsystem ContextManager Paketk rzel Ccxt kreiert 212 7 Das PRIME Rahmenwerk Abb 55 Metamodell fiir Situationstyp Spezifikation Abb 56 Syntax f r Situationstyp Spezifikationen Abb 57 Beispiele fur Situationstypen einzelnen Situationsteile eines Situationstypen sind geordnet und k nnen ber einen Rollennamen Attribut role der Aggregation zwischen CcxtSituationDesc und CcxtSituationPart referenziert werden Situationsteile werden nach der Art ihrer Typisierungen weiter differenziert im Metamodell dargestellt durch die Subklassen CcxtProductSitPart CcxtValueSitPart und CcxtListSitPart Im Normalfall referenzieren Situationst
516. s ausreichend erwies wurde bei Visio der Zusatzaufwand f r eine vollst ndige Prozessintegra tion durch die zentrale Stellung des Werkzeugs im IMPROVE Werkzeugverbund gerechtfertigt Die hier beschriebenen Experimente sollten die grunds tzliche Machbarkeit der Prozessintegration existierender Werkzeuge demonstrieren und sind lediglich als erster Schritt auf dem Weg zu einem umfassenden a posterioti Integrations konzept im PRIME Kontext zu verstehen Es ergeben sich eine Reihe interes santer Ankn pfungspunkte f r weiter gehende Forschungsarbeiten Beispielsweise erfolgt gegenw rtig die Modellierung eines externen Werkzeug im Werkzeugmo dell und die Implementierung der entsprechenden Adapter mannell Hier ist die M glichkeit zu untersuchen ob aus einer gegebenen formalen Schnittstellenbe schreibung des zu integrierenden Werkzeugs z B in Form einer IDL Spezifikation oder einer COM Type Library zumindest semiautomatisch entsprechende PRI ME Werkzeugmodelle und Adapterklassen generiert werden k nnen W n schenswert w re weiterhin ein strukturiertes Rahmenwerk das unterschiedliche Kategorien der Prozessintegrierbarkeit genauer klassifiziert und dem Umgebungs integrator eine Checkliste f r die Bewertung des Integrationspotenzials eines externen Werkzeugs an die Hand gibt Weiterhin sind die Konsequenzen einer unvollst ndigen Prozessintegration auf Aspekte wie die Synchronisation zwischen Leit und Durchf hrungsdom ne sowie die Protok
517. s durchf hrt interagieren Allerdings verk rpern sie Prozesswissen nur in indirekter und hartkodierter Form Zudem sind sie wegen der engen Verschr nkung mit dem jeweiligen zugrunde liegenden Werkzeug nicht f r die Prozessunterst tzung werkzeug bergreifender Abl ufe ausgelegt 41 2 Prozessorientierte Unterst tzungsfunktionen Tab 7 Prozessunterst tzungs ans tze im Vergleich Art der Prozessunterst tzung Hilfesysteme statisch uniform Tab 7 fasst die wesentlichen Merkmale der Prozessunterst tzung durch Handb cher Hilfesysteme Assistenten und prozesszentrierte Entwicklungsumgebungen vergleichend zusammen technisch rechnerbasiert se statisch konfigurierbar nderbar aktive Anleitung erzwingend lenkend automatisierend dynamisch individuell passiv aktiv Assistenten Interface Agenten PZEU Planung und Koordination Agendamanager Werkzeugaufruf 2 3 2 Einordnung prozessintegrierter Werkzeuge Die Hauptthese dieser Arbeit lautet dass durch eine engere Integration der Mo dellierungs und Leitdom ne Prozessmodelle und Prozessmaschine mit der Durchf hrungsdom ne Entwicklungswerkzeuge die Vorteile der flexiblen An passbarkeit prozesszentrierter Umgebungen einerseits und die hohe Unterst t zungsqualit t werkzeugbezogener Assistenten andererseits kombiniert werden k nnen Werkzeuge die ihre Arbeitsweise den in der Modellierungsdom
518. sans tze die Frage wie fest Aufrufbeziehungen zwischen den Werkzeugdiensten in den Werkzeugen selbst zementiert werden von entscheidender Bedeutung Je transparenter f r ein Werkzeug die Kopplung seiner Dienste mit denen anderer Werkzeuge ist desto flexibler l sst sich ein Werkzeug in unterschiedlichen Prozessen einsetzen Bei der Realisierung verteilter Werkzeuginteraktionen lassen sich drei grund legende Entwurfsparadigmen oder Architekturstile Sha 95 ShGa96 AbAG95 LiKS99 differenzieren siehe Abb 11 0 Expliziter Aufruf Client Server Beim traditionellen Client Server Prin zip wird die Interaktion explizit durch ein Werkzeug initiiert das sich als Klient der Dienste eines Server Werkzeugs bedient In einer heterogenen verteilten Umgebung wird dieser Ansatz durch Middleware Mechanismen wie RPC Object Request Broker sowie Namens und Tradingdienste verk rpert die im Wesentlichen f r eine Verteilungs und Ortstransparenz sowie die Unabh ngigkeit von den zugrunde liegenden Programmiersprachen sor gen Die Interaktionsbeziehungen zwischen Werkzeugen haben den Cha rakter expliziter Kommandoanfrufe Das prozessrelevante Ablaufwissen mani festiert sich in den Codefragmenten der jeweils aufrufenden Komponen ten Q Impliziter Aufruf ereignisbasiert In ereignisbasierten Architekturen ruft ein Werkzeug nicht direkt die Dienste anderer Werkzeuge auf sondern gibt lediglich nderungen seines Zustands als Notifikationen
519. schaften und Prozessfragmenten zur Aufzeichnung von Nachvollziehbarkeitsinformationen kl rt 22 2 Prozessorientierte Unterstutzungsfunktionen In dem Ma e in dem die ein Projekt beeinflussenden Kontingenzfaktoren va riieren k nnen muss also auch die von einem Prozessunterst tzungsansatz geleis tete Prozessanleitung flexibel anpassbar sein um eine sinnvolle und hinreichend spezifische Assistenzfunktion auch im Kontext eines konkreten Projekts zu erhal ten Wir unterscheiden drei Auspr gungen der Anpassbarkeit eines Prozessunter st tzungsansatzes fix konfigurierbar und nderbar Fixe Prozessvorgaben Von fixen oder nicht anpassbaren Prozessunterst tzungsans tzen sprechen wir wenn keinerlei Mechanismen f r die Anpassung an ge nderte Prozessvorgaben vorgeschen sind Wenn Prozessunterst tzung beispielsweise durch Methoden und Projekthandb cher vermittelt wird sind der Anpassbarkeit aufgrund der statischen Natur des Mediums Buch enge Grenzen gesetzt Konfiguration durch Konfigurierbare Prozessunterst tzungsans tze stellen Konfigurationsmechanis Customizing men zur Verf gung mit deren Hilfe die angebotenen Assistenzfunktionen inner halb vorgegebener Grenzen auf spezifische Belange zugeschneidert werden k n nen Dieser Anpassungsvorgang wird h ufig als Customizing bezeichnet Charakte ristisch f r den Konfigurationsansatz ist die Idee eines Referenzmodells BeRS99 BaG198 Reit98 worunter eine abstrakte Repr sentation
520. sche Werkzeugfunktionalit t und Pro zessmodelle anreichern muss Besonderer Wert wird in der Darstellung auf soft waretechnische Aspekte der Wiederverwendbarkeit gelegt Framework Architek tur Variationspunkte Zusammenspiel zwischen generischen und spezifischen Architekturkomponenten Kontrollinversion ber die Neuentwicklung von Werkzeugen hinaus eignet sich das Framework auch zum Wrapping existierender Werkzeuge sofern diese hinreichend offen sind Wir leiten zun chst Anforderungen an die Laufzeitschnittstellen von Fremdwerk zeugen her und illustrieren dann die M glichkeiten und Grenzen des Wrappingan satzes anhand der Integration von insgesamt drei weit verbreiteten kommerziellen Werkzeugen Die Praktikabilit t des vorgeschlagenen L sungsansatzes wurde durch die Rea lisierung bzw Einbindung von 17 Werkzeugen in insgesamt vier prozessintegrier 1 2 Ziele und Aufbau der Arbeit ten Entwurfsumgebungen aus den Anwendungsbereichen Requirements Enginee rung und Verfahrenstechnische Modellierung nachgewiesen Kapitel 8 geht speziell auf die im Aachener Sonderforschungsbereich Informatische Unterst tzung bergreifender Prozesse in der Verfahrenstechnik entstandene Umgebung PRI ME IMPROVE ein und illustriert die Anpassung und Nutzung einer solchen Umgebung anhand einer Beispielsitzung In der Schlussbetrachtung unterziehen wir unseren Ansatz einer kritischen Bewertung aus den Blickwinkeln des Anwendungsingenieurs des Metho
521. schnittstelle in der Syntax der Prozessmodellierungssprache der PK Komponente dargestellt werden kann da sie ansonsten mangels einer syntaktischen Repr sentation nicht referenziert werden k nnte Die Regeln f r die Erzeugung der Stellvertreterschnittstelle werden hier mit Hilfe von Bindungen umgesetzt die f r jede Prozessmodellierungssprache festlegen wie eine Stellvertreterschnittstelle mit den sprachspezifischen Konzepten dargestellt wird Die prinzipielle Vorgehensweise entspricht dem CORBA bzw 6 4 Schnittstellenbindung 155 SLI Ansatz da dort ebenso aus einer sprachneutralen IDL Schnittstellenbeschrei bung mithilfe von Sprachbindungen eine Stellvertreterschnittstelle in der Verwen dungssprache erzeugt wird Die Bindungen f r eine Sprache assoziieren jeweils ein Konzept des Schnittstellenmetamodells mit einem korrespondierenden Konzept der Prozess modellierungssprache Um Bindungen auf der Ebene konkreter Prozessfragmente repr sentieren zu k nnen ist es jedoch erforderlich die grunds tzliche Struktur von Bindungsinformationen bereits auf der Metameta Ebene vorzugeben Diese Struktur wird im Bindungs Metametamodell BM2 Modell definiert und umfasst eine Datenbeh lter Schnittstellen und Aktivit tsbindung Ausgang Abb 30 Bindungs M2 Modell Datenbeh lter Meta Schnittstelle Aktivit t Eingang N AN J sprachneutrale Prozesssprachen Darstellung konzept
522. sdom nen und ihrer Beziehungen untereinander liegt das Augenmerk dieser berblicksdarstellung auf einer Unter scheidung des Generizit tsgrades der einzelnen Komponenten Die reinen Frame work Anteile einer PRIME basierten Umgebung sind dunkelgrau dargestellt Diese Softwarekomponenten und Repository Schemata stellen halbfertige Anwendungs ger ste f r prozessintegrierte Entwicklungswerkzeuge bzw Prozessmaschinen dar und m ssen an den daf r vorgesehenen Variationspunkten um spezifische Funkti 7 1 Die PRIME Gesamtarchitektur onalit t erg nzt werden PRIME bringt bereits eine Reihe von vorgefertigten Erweiterungen der Frameworkkomponenten zu lauff higen und allgemein ver wendbaren Anwendungen mit die jeder PRIME basierten Umgebung zur Verf gung stehen Diese sind als hellgraue Architekturbausteine dargestellt Die wei dargestellten Architekturanteile markieren Platzhalter f r spezifische Umgebungs komponenten die in einer konkreten Modellierungsumgebung erst noch als Fra mework Erweiterungen zu entwickeln bzw zu integrieren sind 7 1 2 1 Werkzeuge der Durchf hrungsdom ne In der Durchf hrungsdom ne sind die Entwicklerwerkzeuge angesiedelt deren Grundlage das GARPIT Framework darstellt Die wesentlichen Aufgaben des GARPIT Frameworks in Abb 34 durch die dunkelgrauen Anteile der einzelnen Werkzeugsymbole repr sentiert sind die Koordination der Interaktion mit der Prozessmaschine sowie die Interpretation und Ausf hrung
523. se die bislang anspruchsvollste Die besonderen Herausfor derungen lagen hier in der Heterogenit t der zu integrierenden Werkzeuge und in den Schnittstellen zu externen Unterst tzungsfunktionalit ten Anhand einer Beispielsitzung aus dem IMPROVE Kontext haben wir den Umgang mit einer PRIME basierten Umgebung aus Sicht des Methodeningenieurs und des Anwen ders illustriert 9 1 Beitrage der Arbeit 271 Kapitel Schlussbetrachtungen 9 1 Beitr ge der Arbeit Gegenstand der vorliegenden Arbeit war ein Rahmenwerk f r die Einbindung von Software Werkzeugen in definierte Arbeitsprozesse Ziel war die Unterst tzung und flexible Anpassbarkeit der durch die Werkzeugumgebung unterst tzten Ar beitsabl ufe auf der Basis expliziter Prozess und Werkzeugmodelle Die dabei erzielten Ergebnisse lassen sich wie folgt zusammenfassen Q Vergleich von Prozessunterst tzungsans tzen Wir haben zun chst ein Klassifika tionsschema f r die Bewertung existierender prozessorientierter Unter st tzungsfunktionen hinsichtlich der Merkmale unterst tzte Projektebene In tegrationstiefe Kontextbezogenheit Anpassbarkeit und Abdeckung des Spektrums unterschiedlicher Unterst tzungsmodi entwickelt Anhand dieses Klassifikati onsschemas haben wir die Unterst tzungsleistung von Methodenhandb chern Hilfesystemen Assistenten und Interface Agenten sowie prozess zentrierten Umgebungen diskutiert sowie die Schw chen und St rken der einzelnen Ans tze ident
524. seditor angeboten wird Bei spielsweise k nnte der Entit tstyp mit einem Datenspeicher oder mit Datenfl ssen 226 7 Das PRIME Rahmenwerk korrespondieren Aus den ermittelten Datenflussdiagramm Elementen kann der Benutzer ein Element ausw hlen Entscheidungskontext CC Select DFDElement und sich zwischen folgenden Alternativen entscheiden Q Er kann das DFD Element anpassen beispielsweise durch Verfeinerung des Datenspeichers oder durch Aufsplitten von Datenfltissen Dies ist ein Teilablauf der durch den Plankontext PC_Adapt DFDElement hier nicht im Detail dargestellt angeleitet wird Q Er kann eine neue Aufgabe zur sp teren Erledigung generieren Diese Funktionalit t wird ihm vom Task Manager der PRO ART Umgebung zur Verf gung gestellt Ausf hrungskontext EC _AddToTaskList Q Er kann entscheiden dass bei dem betreffenden Element keine Anpassung erforderlich ist NoChangeRequired Q Er kann den gesamten Anpassungsvorgang beenden QuitAdaptation Das kurze Beispiel demonstriert wie auf einfache Weise die Funktionalit t des ER Editors sobald sie erst einmal auf der Ebene der Prozessmodellierung verf g bar ist in feingranulare werkzeug bergreifende Abl ufe eingebunden werden kann Insbesondere lassen sich somit projekt oder organisationsspezifische Pro zesse in der Werkzeugumgebung durchsetzen 7 3 5 Zusammenfassung Das GARPIT Framework ist ein wiederverwendbares objektorientiertes Frame
525. siehe Abb 46 7 2 Interaktionsprotokoll zwischen den Prozessdomanen 191 Weiterleitung von Kontextanforderungen zwischen Werkzeugen Wenn in einem Werkzeug w ein Ausf hrungs oder Entscheidungskontext c aktiviert wird f r den das Werkzeug nicht selbst verantwortlich ist setzt es eine ExternalECCCRequest Nachricht ab siehe Abb 47 Der Kommunikationsma nager konsultiert dazu das Umgebungsmodell um die zust ndige Werkzeugkate gorie zu ermitteln hier Werkzeugkategorie B und schl gt in der Werkzeugtabelle nach ob aktuell bereits eine entsprechende Werkzeuginstanz l uft hier w Die gefundene oder eventuell neu gestartete Werkzeuginstanz erh lt die ExternalECCC Request Nachricht und f hrt den Kontext aus Das Resultat der Kontextausf h rung wird ber den Kommunikationsmanager an das aufrufende Werkzeug zu r ckgemeldet Abb 47 Weiterleitung einer Kontextanforderung zwischen Werkzeugen 4 External 2 External 1 External 8 9 ECCCRequest c ECCCResponse manager Werkzeug Tabelle Umgebungs modell Wenn man das Werkzeug Zustandsdiagramm in Abb 44 und die hier beschriebe nen Szenarien zur Kontextaktivierung genauer betrachtet fallt auf dass nach dem Erkennen einer Kontextaktivierung Ereignis ContextMatched die Werkzeuge selbst eine Vorauswahl treffen m ssen ob es sich beim dem aktivierten Kontext um einen werkzeuginternen Kontext einen Plankontext oder einer werkzeug
526. sign Fundamentals of a Discipline of Computer Program and Systems Design Prentice Hall 1979 Yourdon E Modern Structured Analysis Prentice Hall Englewood Cliffs 1989 Lebenslauf 299 Lebenslauf Klaus Lambert Weidenhaupt Geboren am 21 02 1968 in Immerath jetzt Erkelenz 1974 1976 Besuch der Grundschule in Brachelen 1976 1978 Besuch der Grundschule in Erkelenz 1978 1987 Besuch des Cusanus Gymnasiums in Erkelenz Abitur am 27 06 1987 1987 1988 Wehrdienst in Essen und Geilenkirchen Okt 1988 Okt 1989 Studium der Chemie an der RWTH Aachen Okt 1989 April 1995 Studium der Informatik an der RWTH Aachen Diplom am 12 04 1995 Mai 1995 Juni 2000 Wissenschaftlicher Angestellter am Lehrstuhl fiir Informatik V der RWTH Aachen Prof Jarke seit Dez 2000 Wissenschaftlicher Angestellter am Philips Forschungslaboratortum Aachen Aachen 23 05 2002
527. smodell Abschnitt 5 5 Q Fur alle Produktinstanzen die zur aktuellen Situationsinstanz geh ren wird die Darstellungsart hervorgehoben gesetzt mithilfe der Object Table Methode setDisplayMode ProductID emphasized Q F r alle potenziell answ hlbaren Produktinstanzen wird die Darstellungsart selektierbar gesetzt Potenziell ausw hlbar sind alle Produktinstanzen deren Produkttyp zur Situation einer Alternative des aktuellen Entschei dungskontexts geh rt Entsprechend ermittelt der ContextExecutor zu n chst alle im aktuellen Entscheidungskontext in Frage kommenden Pro 210 Abb 54 Anpassung der Werk zeugoberflache durch ContextExecutor 7 Das PRIME Rahmenwerk dukttypen und ruft f r diese die ObjectTable Methode setDisplayMode ProductTypeID selectable auf Q Fur alle anderen Produktinstanzen wird die Darstellungsart nicht selek tierbar gesetzt Wie bei der Anpassung der Kommandoregion operiert der ContextExecutor nur mit Identifikatoren des Umgebungsmodells Die Anderung der Darstellungsart der Produktinstanzen dutch den ContextExecutor witd von der ObjectTable an die werkzeugspezifischen T_GUI Objekte propagiert Anhand eines Beispiels wollen wir nun die Arbeitsweise des ContextExecutors bei der Ausf hrung eines Entscheidungskontexts illustrieren Abb 54 zeigt den mithilfe des GARPIT Frameworks entwickelten ER Editor bei der Ausf hrung des Entscheidungskontex
528. sondere in der Bereit stellung eines Implementationsrahmens f r prozessintegrierte Werkzeuge in dem wesentliche Aspekte des Integrationsansatzes als vorgefertigte Softwarekompo nenten vorliegen und der somit die oben angesprochene Aufwandsschwelle f r die Anwendung des Ansatzes betr chtlich absenkt Bei der Einordnung unseres Ansatzes in die oben skizzierten Integrationssze narien muss zudem unterschieden werden zwischen der initialen Erstellung eines Werkzeugs und seiner Einbindung in ewolvierende Prozesse Wie in Abschnitt 3 1 4 deutlich gemacht wurde ist Prozessintegration in erster Linie als Adaptierbarkeit eines Werkzeug an sich kontinuierlich ver ndernde Prozessdefinitionen zu verste 3 3 Integrationsanforderungen in prozessintegrierten Umgebungen 55 hen Bei einem reinen Whitebox Ansatz resultiert jede Prozess nderung in einer Reprogrammierung der betroffenen Werkzeuge um deren Prozessintegration wieder herzustellen Dagegen sind Werkzeuge so sie denn erst mal nach unserem Ansatz entwickelt worden sind per se prozessintegrierbar und lassen sich im Sinne der Greybox Integration ber dann vorhandene Schnittstellen und formale Mo delle an sich ndernde Prozesse anpassen Dies entspricht der in Abschnitt 3 1 4 erhobenen Anforderung nach Modellierungsadaptabilit t Modifikationen an den Werkzeugen auf Programmcodebene sind dann nur noch erforderlich wenn v llig neue dom nenspezifische Grundfunktionalit ten ben tigt werden Dies
529. ss T R und Schoman K E Structured Analysis for Requirements Definition IEEE Transactions on Software Engineering 3 1 S 6 15 1977 Rosenberg D und Scott K Use Case Driven Object Modeling with UML 1999 Rolland C Souveyet C und Moreno M An Approach for Defining Ways of Working Information Systems 20 4 S 337 359 1995 Roth Ch Die Auswirkungen von CASE In Goerke W und Rininsland H Htsg Information als Produktionsfaktor Springer Verlag Informatik aktuell 1993 S 648 656 Royce W W Managing the Development of Large Software Systems In Procs Wescon New York USA IEEE Computer Society Press Nachgedruckt in Proc 9th Intl Conf on Software Engineering 1987 S 328 338 1970 S 1 9 Rumbaugh J Jacobson I und Booch G The Unified Modeling Language Reference Manual Addison Wesley 1999 Rumbaugh J Blaha M R Premerlani W J Eddy F und Lorensen W Object Oriented Modeling and Design Prentice Hall Englewood Cliffs 1991 Sarlan H Managementaspekte bei objektorientierten Entwicklungsprojekten Informatik Spektrum 15 5 S 282 286 1992 Sattler K U A Framework for Component Oriented Tool Integration In Proceedings of the 4th International Conference on Object Oriented Information Systems OOIS 97 Brisbane Australia 1997 S 455 465 Schefstr m D und Broek G van den Hrsg Too Integration Environments and Frameworks John Wiley amp Sons 1993
530. sschnittstelle der Situationskomponente muss dabei die Eingangsschnittstelle der Verhaltens komponente subsummieren d h jedem In Produktteil der Verhaltenskomponente muss jeweils ein Out Produktteil der Situationskomponente zugeordnet werden 6 3 Komponentenorientierte Darstellung des NATURE Prozessmodells 147 wobei die miteinander verkn pften Produktteile jeweils den gleichen Typ haben Es wird jedoch nicht gefordert dass alle Out Produktteile der Situationskompo nente vollst ndig auf In Datenbeh lter der Verhaltenskomponente abgebildet werden m ssen Dies erlaubt eine flexiblere Verkn pfung von Situations und Verhaltenskomponenten auch in solchen F llen in denen einige der Out Pro duktteile der Situationskomponente f r die Verhaltenskomponente irrelevant sind 6 3 2 Schnittstellenmetamodell Nachdem wir im voran gegangenen Unterabschnitt auf informeller Ebene die Schnittstellen und Implementierungsanteile von Kontextkomponenten vorgestellt haben formulieren wir nun ein formales Metamodell zur Schnittstellenbeschrei bung das alle aus Verwendungssicht erforderlichen Informationen ber eine Kontextkomponente bereitstellt Da das Ziel in der Einbettung existierender Prozessmodellierungssprachen in das NATURE Prozessmodell besteht orientieren sich die Konzepte zur Schnitt stellenbeschreibung naturgem an dem durch das NATURE Prozessmodell vorgegebenen Rahmen Als Schnittstellenbeschreibungssprache ist das NATURE Prozessm
531. sse Langua geElement werden alle sprachlichen Konzepte sowohl des Interpreterrahmenwer kes selbst als auch zus tzliche sprachliche Konzepte einer spezifischen Prozess sprache spezialisiert Abb 65 LanguageElement Sprachliche Klassen des eas oe Sprachelemente Schicht Type Guard Activity Interface DataContainer 0 1 1 evaluate ReadData operator 1 1 A 0 4 repareWrite operator A WriteData operator einstange gt 1 1 contains SiuationPart Instance compositeActivit atomicActivity emere esii Load Started UL Init Done Destroy Aborted 1 Suspended SLANG UML SLANG UML SLANG UM SLANG UML Activity Net Statechart Transition State PrePostset nete Place Attribute Das Wissen ber die einzelnen Sprachelemente wird von der Klasse compositeAc tivity gehalten Eine zusammengesetzte Aktivit t d h ein Prozessfragment besteht aus Sprachelementen die das Verhalten des Fragmentes spezifizieren und ist f r deren Instanziierung und Initialisierung verantwortlich Die Schnittstelle der Klasse compositeActivity bietet daher Funktionalit t zum Laden Initialisieren und Entladen eines Prozessfragmentes und dar ber hinaus Funktionalit t zum Navigieren innerhalb der Spra
532. sse der Entwickler ein und unterst tzen den Projektmanager bei der Koordination Kontrolle und Steuerung der Aktivit ten der einzelnen Entwickler F r die prozessmodellgesteuerte Durchf hrung von Projektmanagement und Entwicklungsaktivit ten hat sich im Englischen der Begriff Enactment eingeb rgert der zum einen neutral bez glich Interpretation oder kompilierter Ausf hrung von Prozessmodellen ist und zum anderen zum Ausdruck bringen will dass Prozesse von Menschen und rechnergest tzten Werkzeugen gleicherma en durchgef hrt werden Da Prozessmodelle mechanisch durch eine Prozessmaschine blicher weise interpretierend ausgef hrt werden m ssen Prozessmodelle in einer forma len Sprache mit einer operationalen Semantik spezifiziert werden Die in der Soft waretechnik seit Anfang der 70 er Jahre g ngigen Lebenszyklusmodelle z B das Wasserfallmodell Royc70 das Spiralmodell Boch88 das Font nenmodell HeEd93 das V Modell BrDr95 DrHM98 sind hierf r ungeeignet da sie sich zum einen auf einer extrem grobgranularen Abstraktionsebene bewegen und zum anderen nicht die f r eine mechanische Ausf hrung erforderliche Formalit t aufweisen 2 2 Bewertung existierender Ansatze Modellierungsdom ne Durch fihrungsdom ane Definition Pflege von Prozessmodellen Anwendungsentwicklung Prozessmodell repository zm interaktive W Werkzeuge _ Fo E er Agenda Ma
533. sses Tab 2 Prozessunterst tzung auf systematisch methodische Durch Projektmanagement und f hrung einzelner Aktivit ten Granularit t der betrachteten Arbeitsein heiten grobgranulare Aufgaben keine Betrachtung der Internstruktur Arbeitsplatzebene feingranulare Arbeitsabl ufe Arbeitsschritte unterhalb von Aufgaben Granularit t der betrachteten Entwurfs produkte grobgranulare Dokumente als Einhei ten der Arbeitsteilung feingranulare Produkte unterhalb der Dokumentgrenze Sichtweise auf Ent wurfsprodukte administrative Sichtweise auf Produkte inhaltsorientierte Sichtweise auf Produkte Rolle von Werkzeugen keine oder nur rudiment re Ber ck sichtigung von Werkzeugen als Mittel zur Aufgabenerledigung detaillierte Ber cksichtigung von Werkzeugen bei der Durchf hrung einzelner Arbeitsschritte Planbarkeit der zu unterst tzenden Prozesse Ein prim res Unterscheidungsmerkmal ist der Gegenstandsbereich der Prozess globale und durchg ngige Pr skription entlang eines Projektplans jedoch keine Aussagen ber detaillierte Ausgestaltung der einzelnen Aufgaben innerhalb von Aufgaben i a kreative Arbeitsprozesse daher nur fragmentweise nicht notwendiger weise zusammenh ngende Pro zessunterst tzung f r wohlverstan dene Teilabl ufe Gegenstandsbereich unterst tzung auf den beiden Projektebenen W hrend auf Projektmanagement ebene Unterst tzung f r
534. ssistententypen unterscheiden Passive Assistenten werden erst nach explizitem Aufruf durch den Benutzer aktiv stellen also passive Prozessberatung dar Die in professionellen Entwicklungsumgebungen eingesetzten Assistenten fallen in der Regel in diese Kategorie da erfahrene Benutzer proaktive Assisten ten wegen der oftmals ungenauen Ratschl ge eher als st rend empfinden und die Unterst tzungsleistung von Assistenten lieber gezielt auf eigene Initiative hin in Anspruch nehmen Proaktive Assistenten die Handlungs abl ufe des Benutzers beobachten und selbstst ndig Hilfestellung geben finden sich in Applikationen die in erster Linie von technisch weniger ver sierten Endbenutzern oder Gelegenheitsbenutzern verwendet werden z B Microsoft Office Solche Assistenten leisten aktive Prozessunterst tzung Sobald ein Assistent aktiviert ist erzwingt er eine vordefinierte Prozessaus ns f hrung H ufig werden auch gro e Teile des Prozesses auf Basis der vom Prozessunterst tzung Benutzer gelieferten Informationen automatisiert Der Unterst tzungsmo durch Assistenten und dus h ngt also vom aktuellen Aktivierungszustand eines Assistenten ab Interface Agenten Art der Prozess Projekt Integrations Kontext Anpassbarkeit Unterst tzungsmodi unterst tzung ebene tiefe bezogenheit rechnerbasiert se rechnerbasiert in passive Beratung aktive Anleitung erzwingend lenkend automatisierend 5 5 i E as technisch
535. stellation aus atomaren und zusammengesetzten Pro duktteilen und ist eventuell durch zus tzliche Randbedingungen die zum Vorlie gen der Situation erf llt sein m ssen n her beschrieben Die formale Situations spezifikation wird in Abschnitt 7 2 4 n her erl utert Das Konzept Produkt steht stellvertretend f r das zugrunde liegende Pro duktmodell und fasst alle w hrend des Entwurfsprozesses anfallenden Informatio nen zusammen Im engeren Sinne fallen hierunter zun chst die eigentlichen Ent wurfsartefakte In den von uns betrachteten fr hen Phasen der Systementwicklung sind dies z B konzeptuelle Modelle wie ER Diagramme die wiederum aus einzel nen Modellierungselementen wie Entit tstypen und Beziehungstypen bestehen Auf Produkten aufbauende Situationen k nnen also auf unterschiedlichen Granu larit tsebenen angesiedelt sein komplexe Dokumente individuelle Modellierungs elemente In einer erweiterten Sichtweise z hlen wir auch so genannte Supplemen tarprodukte Dokumentationen von Zielen Entscheidungen Begr ndungen etc die zur Entstehung eines Produkts gef hrt haben Prozessbeobachtungsinformationen Informationen ber abgelaufene Prozesse sowie Abh ngigkeiten zwischen den genannten Informationskategorien zum Produkt Diese zus tzlichen Informatio nen dienen prim r der Nachvollziehbarkeit der entstandenen Spezifikationen und Abb 19 PRIME PM das NATURE Prozess metamodel Pohl96 Situation Produkt
536. stem StateManager realisiert wurde Aus architektureller Perspektive hat diese Entwurfsentscheidung eine Reihe signifikan ter Vorteile O Kapselung der Werkzengkontrolle Alle Dynamikaspekte des Interaktionsproto kolls mit der Leitdom ne und der Reaktion auf Benutzerereignisse sind im StateManager Teilsystem gekapselt nderungen der Verhaltensspezifika tion wirken sich nur lokal auf dieses Teilsystem aus andere Teilsysteme sind nicht betroffen O Flexible Erweiterbarkeit und Anpassbarkeit Die explizite bertragung eines Zustandsdiagramms in eine Klassenstruktur hnelt auf den ersten Blick dem in GHJV95 vorgeschlagenen Entwurfsmuster S a e das eine einfache Variierbarkeit des zustandsbasierten Verhaltens von Objekten zum Ziel hat Im Gegensatz zum S afe Muster werden bei uns jedoch Transitionen nicht in Codefragmenten von State Objekten hart kodiert sondern eben falls explizit repr sentiert Zwar ben tigen wir dann f r jeden Transiti onstypen eine zus tzliche Klasse gewinnen daf r aber erheblich an Flexi bilit t So kann die im CsttStateDriver Objekt verwaltete Verkn pfung zwischen Zustands und Transitionsobjekten sogar dynamisch ver ndert werden um z B Protokoll nderungen zur Laufzeit zu realisieren Diese Eigenschaft wurde u a bei der Einbindung eines Filtermechanismus f r die 7 3 GARPIT ein Framework f r prozessintegrierte Werkzeuge 205 Aufzeichnung von D mg99 Nachvollziehbarkeitsinformationen ausgenu
537. t Auf diese Weise ist die Interoperabilit t verschieden sprachlicher Fragmente gew hrleistet da das Interface die Abbildung der Situati onsdaten von einer sprachneutralen in eine sprachspezifische Darstellung und umgekehrt definiert ber diese Transformation hinaus bietet eine Schnittstelle Variationspunkte an die festlegen wie die Daten der Schnittstellenparameter vor und nach Schreib und Leseoperationen modifiziert werden Vor der Ausf hrung einer Aktivit t werden die aktuellen Daten der Eingangsschnittstelle gelesen und anschlie end die Ergebnisse der Ausgangsschnittstelle zugewiesen Dies f hrt zu einer sprachab h ngigen Modifikation der Inhalte der Datenbeh lter beim Zugriff So werden z B im Falle von SLANG beim Schalten einer Transition die Marken im Vorbereich konsumiert so dass die aktuellen Daten der Eingangsschnittstelle nach der Aus f hrung nicht mehr referenziert werden k nnen Andere Sprachen modifizieren die Daten beim Zugriff nicht oder erfordern u U referenzielle Semantiken Durch Anpassung der Variationspunkte kann jeweils die erforderliche Sprachsemantik umgesetzt werden 7 5 2 2 Technische Klassen Die zuvor erl uterten sprachlichen Klassen repr sentieren Konzepte der Modellie rungsdom ne F r die Ausf hrung und sprachunabh ngige Erzeugung eines Pro zessfragmentes in der Leitdom ne sind dar ber hinaus weitere technische Klassen der administrativen Interpreterschicht erforderlich Diese werden
538. t tzung zu bestimmten Prozessschtitten erheblich Eine wichtige Anforderung an die Prozessintegration von Werkzeugen besteht berbr ckung der daher darin Werkzeuge umfassend und auf der gleichen Abstraktionsebene wie ade Prozessfragmente zu repr sentieren um so die konzeptuelle Distanz zwischen Pro Werkzeugbeschreibun zess und Werkzeugbeschreibungen zu verringern oder gar aufzuheben Dadurch gen wird es m glich einzelne Prozessschritte und Werkzeugdienste systematisch miteinander in Bezug zu setzen und Diskrepanzen etwa das Fehlen einer ben tigten Werkzeugfunktionalit t oder die unzul ssige Zuweisung eines Werkzeug diensts zu einem Prozessschritts aufzudecken Weiterhin erlaubt erst eine integ rierte Modellierung von Prozessen und Werkzeugdiensten ein konsistentes nde rungsmanagement Beispielsweise lassen sich so beim Entfernen eines Werkzeugs bzw beim Austausch durch ein anderes die Auswirkungen auf die Ausf hrbarkeit der existierenden Prozessfragmente analysieren Aus Sicht der Prozessmodellierung sind drei Aspekte eines Werkzeugs von be sonderer Bedeutung O die elementaren Dienste die ein Werkzeug ber seine programmierbare Lauf zeitschnittstelle zum Aufruf durch die Prozessmaschine f r die Umsetzung eines Prozessschritts anbietet Q die Vorbedingungen denen die Ausf hrung eines elementaren Dienstes zu ei nem bestimmten Zeitpunkt unterliegt Q die Arbeitsmodi in die ein Werkzeug versetzt werden kann Ein Ar
539. t tzungsansatzes nachgewiesen werden 9 3 Ausblick Zum Abschluss wollen wir noch einige sinnvolle Erg nzungen und Erweite rungsm glichkeiten des vorgestellten Ansatzes aufzeigen 275 276 9 Schlussbetrachtungen O Werkzeug bergreifender Situationsbegriff Die Ausgestaltung des Situationsbeg riffs ist in der aktuellen Implementierung nicht sehr ausdrucksstark Neben der geringen M chtigkeit der Situationssprache liegt dies vor allem daran dass die Situationsauswertung jeweils werkzeuglokal erfolgt Durch eine erweiterte werkzeug bergreifende Situationsanalyse lie en sich auch kom plexe Produktkonstellationen charakterisieren die ber mehrere Werk zeuge verteilt vorliegen Mit der erweiterten zweistufigen Situationsanalyse unter R ckgriff auf eine Prozessdatenbank wie sie im Flie bildwerkzeug realisiert wurde konnte bereits ein erster viel versprechender Schritt in die se Richtung aufgezeigt werden der jedoch noch systematischer untersucht werden muss O Generierung von Werkzeugdiensten Die Implementierungs Frameworks entlas ten den Umgebungsentwickler von der architekturellen und technischen Integration der Prozessdom nen w hrend die werkzeugspezifische Funk tionalit t jedoch noch weitgehend von Hand ausprogrammiert werden muss Eine weitere Aufwandsminimierung k nnte die semi automatische Generierung von Werkzeugdiensten auf Basis eines verfeinerten Werk zeugsmodells bringen Erste konzeptuelle Grundlagen wurd
540. t werden Vielmehr muss bei der Auswahl und Ausgestaltung von Mechanismen zur Werkzeugintegration ber cksichtig werden dass Prozesse hochgradig dynamisch sind Die daraus resultierende Adaptabilit t bezieht sich dabei auf zwei unter schiedliche Dynamikaspekte Zum einen m ssen sich nderungen des Ausf h rungszustands definierter Prozesse process enactment unmittelbar in einem angepass ten Verhalten der Werkzeuge widerspiegeln Diese Art von Anpassbarkeit nennen 52 3 Integrationsansatze wir Ausf hrungsadaptabilit t Zam anderen m ssen nderungen an den Prozessmo i dellen selbst process evolution auf die Ebene der Benutzerdienste propagiert werden PESTE Hier sprechen wit von Modellierungsadaptabilit t Es sei noch angemerkt dass die adaptabilit t Grenze zwischen Adaptabilitat zur Modellierungs und zur Ausf hrungszeit zu nehmend verschwimmt aktuelle Forschungsans tze widmen sich verst rkt dem schwierigen Problem der Evolution aufender Prozesse BaFG93 BoTa96 Bey 00 GrRW00 CNWL00 Konkrete Anforderungen und Hinweise wie die Prozessintegration von Mo dellierungs und Leitdom ne mit der Durchf hrungsdom ne in einem ganzheitlichen Ansatz auf Basis der Integrationsmechanismen der unteren Ebene auszugestalten ist fehlen jedoch bei den oben genannten Arbeiten ebenso wie in anderen Publi kationen zu diesem Thema ChNo92 FeOh91 DoFe94 GiKa91 und gelten allgemein noch als wenig verstanden Bro 94 JaHu98 SJHB96 Bohm
541. t das marktf hrende Programmpaket f r die statische Simulation chemischer Prozessmodelle Q Microsoft Excel MS Excel wird h ufig in der fr hen Phase der Prozess entwicklung f r die Grobberechnung von Massenbilanzen sowie f r Kos tenkalkulationen verwendet Q Visio Visio ist ein weit verbreitetes Werkzeug f r technische Zeichnun gen das in der Verfahrenstechnik haupts chlich zur Erstellung von Flie bilddiagrammen dem Hauptdarstellungsmittel f r chemische Prozesse bzw Anlagen eingesetzt wird Der geringste Integrationsgrad wurde bei Aspen Plus erreicht Aspen Plus ist ein Aspen Plus weitgehend geschlossenes monolithisches System das nicht ber geeignete Pro ose Integration Anlei 3 es tung in separater Benut grammierschnittstellen zur Prozessintegration verf gt Aspen Plus legt zwar einen Jeyschnittstelle Teil seines Objektmodells ber COM basierte APIs offen jedoch erlauben diese nur lesenden Zugriff so dass beispielsweise die Prozessmaschinen gesteuerte Erzeugung eines neuen Simulationsmodells nicht m glich ist Die unmittelbare Einflussnahme der Prozessmaschine auf Aspen Plus beschr nkt sich daher auf das Starten des Werkzeugs ggf mit einer ber die Kommandozeile bergegebenen Simulationsdatei Arbeitsabl ufe die Aspen Plus einbeziehen werden stattdessen ber das in Abschnitt 7 1 2 5 beschriebene generische Anleitungswerkzeug unter st tzt In diesem Werkzeug wird der Benutzer ber die
542. t der Quellkode des Werkzeugs f r An passungen an die speziellen Anforderungen einer prozesszentrierten Um gebung ebenfalls nicht zur Verf gung Anders als bei der Blackbox Integration stellt das Werkzeug jedoch eine eigene Sprache f r Erweiterun gen z B E Lisp f r den Texteditor emacs Stal81 oder programmierbare Laufzeitschnittstellen Application Programming Interfaces APIs bereit ber die das Werkzeug mit der Leitdom ne interagieren kann Dadurch kann ein Werkzeug auch w hrend seiner Laufzeit mit der Prozessmaschine Daten und Kontrollinformationen austauschen muss also nicht f r jeden Pro zessschritt erneut gestartet werden und erlaubt so die Beibehaltung eines inkrementellen Interaktionsstils Insbesondere k nnen so gezielt individu elle feingranulare Dienste eines Werkzeugs von der Prozessmaschine di rekt aktiviert werden ohne dass der Benutzer zur manuellen Aktivierung dieses Dienstes ber eine spezielle Benutzerschnittstelle der Prozessma schine aufgefordert werden muss O Whitebox Integration Bei dieser Integrationsform wird ein Werkzeug entweder speziell f r den Einsatz in einer Umgebung neu entwickelt oder es steht bei existierenden Werkzeug der Quellcode zur Verf gung um die erforderlichen Modifikationen zur Anbindung und Anpassung an die Leit und Modellierungsdom ne vornehmen zu k nnen Konkret bedeutet dies dass der Werkzeugentwickler von der Leit und Modellierungsdom ne vorgegebene Schnittstellen Pro
543. tdom ne anfordert In diesem Zusammenhang bedeutet Prozessintegration dass die Werkzeuge der Durchf hrungsdom ne hierbei eine aktive Rolle spielen und als Clients der Leitdom ne fungieren Aus Benutzersicht sollte kein Unter 104 3 Integrationsansatze schied zwischen der Aktivierung einer werkzeugeigenen Funktion und eines extern definierten Prozessfragments bestehen Die heute blichen Integrationsstrategien in prozesszentrierten Umgebungen vernachl ssigen diesen Aspekt weitgehend und sehen Werkzeuge lediglich in der Rolle eines Diensterbringers ohne Kenntnis der zu unterst tzenden Prozesse Schnittstellenspezifikationen der WfMC f r workflow enabled applications und Erwei terungsmechanismen in modernen Werkzeugen k nnen aber eine Grundlage f r eine aktivere Rolle der Werkzeuge bieten 3 4 Fazit In dieses Kapitel sind wir mit der Kernhypothese gegangen dass die explizite Modellierung von Prozessen in prozesszentrierten Entwicklungsumgebungen eine gute Grundlage f r die adaptable und kontextsensitive Prozessunterst tzung von Entwickleraktivit ten darstellt Der Fokus solcher Ans tze lag in der Vergangen heit jedoch stark auf den zugrunde liegenden Prozessmodellierungssprachen und Ausf hrungsmechanismen w hrend die Auswirkungen auf die interaktiven Werk zeuge der Entwicklungsumgebung weitgehend ignoriert wurden Ziel des Kapitels war es daher Voraussetzungen und Anforderungen an eine engere Integration zwischen der Model
544. tegorien bzw Prozessmaschine im Umgebungsmodell vorge nommen Zur Laufzeit f hrt der Kommunikationsmanager Buch ber die aktuell laufen den Werkzeuginstanzen und die dort geladenen Produkte Bei Bedarf startet er eine neue Werkzeug oder Prozessmaschineninstanz Die Kapselung des Wissens ber die aktuell aktiven Werkzeug und Prozessmaschineninstanzen im Kommu nikationsmanager reduziert die Komplexit t der Nachrichtenschnittstelle auf Seiten der Werkzeuge und der Prozessmaschine betr chtlich Auf die vom Kom munikationsmanager erm glichte Orts und Namenstransparenz werden wir bei der Darstellung des Interaktionsprotokolls zwischen Leit und Durchf hrungsdo m ne noch genauer eingehen Abschnitt 7 2 ber seine eigentliche Aufgabe als Nachrichtenverteiler hinaus verf gt der Kommunikationsmanager ber eine Benutzerschnittstelle ber die der Benutzer Werkzeuge manuell starten kann 7 1 2 4 Prozessspuren Server Eine prozessintegrierte Umgebung sollte neben einer Anleitung durch pr skriptiv modellierte Prozessfragmente auch die Nachvollziehbarkeit abgelaufener Prozesse 23 Die Werkzeug und Prozessmaschineninstanzen ben tigen initial nur eine Referenz auf den Kommunikationsmanager an den sie sich beim Start binden 173 Prozesskonforme Verteilung von Kontext nachrichten Orts und Namens transparenz Protokollierung von Prozessspuren 174 Aktive Rolle der Werk zeuge bei der Prozess spuraufzeichnung
545. telle gebunden ist unver n dert dargestellt wird Aktivierungsbedingung Der Plankontext RefineProcessDeviceWithDecision wird aktiviert wenn im Flie bildwerkzeug das Projekt Project mit einem Arbeitsblatt Sheet ge ffnet ist d as entsprechende VT Prozesselement Device des Arbeitsblattes selektiert ist Situation und der Verfahrensingenieur M Prozessunterst tzung f r die Verfeine rung der VT Prozessgruppe anfordert Intention Refine Das aktuelle Project Sheet und Device bilden den Vorbereich der Starttransi tion die das SLANG Aktivit tsnetz startet Mit dem Schalten der Transition werden die aktuellen Marken dem Vorbereich des Ausf hrungskontextes EC FI BW CreateGroup zugewiesen Dieser Ausf hrungskontext bestimmt f r ein selektiertes Ger t die zugeh rige VT Prozessgruppe oder legt eine neue an sofern diese noch nicht existiert Im n chsten Schritt werden f r diese VI Prozessgruppe mit dem Ausf hrungskontext EC_FBW GetRefinementsOfGroup alle Verfeinerungen 8 3 Beispielsitzung 261 bestimmt die als Alternativen f r die Realisierungen der VT Prozessgruppe bereits vorhanden sind Rei Plan Context Editor PC_FBW_RefineProcessDeviceWithDecision Abb 74 Document Edit Tools Preferences Context Selection Bee SLANG Modell des aie Adding a context PI k P t PC_EXT_ShowDependencies Fer ankontexts PC_FBW_Choose lternative 4 O PC_FBW_Choose lt
546. ten Abb 48 Transparentes Sperren und Entsperren der Werkzeuginstanzen 7 Das PRIME Rahmenwerk werkzeuginterne Kontextaktivierung eine Netzwerkkommunikation mit dem Kommunikationsmanager verursachen w rde Sperren der ben tigten Werkzeuginstanzen Zum Sperren der f r eine Plankontext Ausf hrung ben tigten Werkzeuginstanzen muss die Prozessmaschine lediglich eine einzelne LockRequest Nachricht abset zen die vom Kommunikationsmanager durch eine geb ndelte LockOKResponse Nachricht welche die Bereitstellung a er ben tigten Werkzeuginstanzen signali siert beantwortet wird Der Kommunikationsmanager abstrahiert aus Sicht der Prozessmaschine somit von der Menge der aktuell zu sperrenden Werkzeuginstan zen und sorgt f r eine transparente Synchronisation der einzelnen LockRe quest LockOKResponse Paare mit den jeweiligen Werkzeuginstanzen siehe Abb 48a Auf hnliche Weise erfolgt die Verteilung einer EndOfEnactment Nachricht die die Prozessmaschine nach Beendigung der Plankontext Ausf hrung absetzt siehe Abb 48b EndOf EndOf Enactment Enactment 1 n 1 LockOK EndOf Response Enactment Request Kommunikations manager Kommunikations manager Werkzeug Werkzeug Tabelle Umgebungs Tabelle Umgebungs modell modell 2 LockOK Response EndOf Request Enactment 1 Lock Prozess b maschine Kontextanforderungen durch die Prozessmaschine W hrend der
547. ten Umgebungen 65 O Geteilte Datenobjekte k nnen inkrementell aktualisiert werden im Gegen satz zum direkten bzw Datei basierten Datenaustausch der inh rent ein Batch artiger Prozess ist Q Daten k nnen werkzeug bergreifend und selektiv angefragt werden um z B die Revisionshistorie eines Objekts oder die Menge der von einem Objekt abh ngigen Objekte zu finden Werkzeuge die ihre Daten innerhalb des Repositories verwalten profitieren also bereits von traditionellen Datenbankfunktionalit ten einem einheitlichen Datenmodell zur Strukturierung der Daten Anfragen zum selektiven Zugriff auf den Reposi tory Inhalt Sichten um die Datenunabh ngigkeit zwischen den auf dem Reposi tory arbeitenden Werkzeugen zu erh hen Integrit tskontrolle zur Konsistenzsiche rung Zugriffskontrolle und Transaktionen Dar ber hinaus werden von einem Repo sitory aber noch zus tzliche Funktionalit ten gefordert die ber reine Datenbank funktionalit t hinausgehen Dazu geh ren unter anderem die Verwaltung okaler Arbeitskontexte zur Abschirmung einzelner Entwickler und check in check out Ope rationen zam Abgleich lokaler Arbeitskontexte mit dem globalen Entwurfsdaten bestand das Versions und Konfigurationsmanagement sowie Notifikationsdienste f r die Propagation von nderungen an interessierte Klienten Abstraktionsebenen innerhalb eines Repositories Ein wichtiges Charakteristikum von Repositories ist weiterhin dass sich die vo
548. teraktion zwischen Werkzeugen auf der Basis programmier barer Laufzeitschnittstellen Die direkte Verwendung solcher Mechanismen f hrt jedoch dazu dass Ablaufwissen als Geflechte von Punkr zu Punkt Beziehungen im Programmcode der Werkzeuge versteckt bleiben Die Interaktion zwischen den Werkzeugen sollte daher auf Basis expliziter Prozessmodelle von der Leitdom ne vermittelt werden In einigen prozesszentrierten Umgebungen wie SPADE oder ProcessWeaver klinkt sich die Prozessmaschine in den Nachrichtenverkehr zwischen den Werk zeugen ein und l sst die empfangenen Nachrichten in die Prozessmodellausf h rung einflie en Problematisch ist hier dass die verwendeten Werkzeugen unab h ngig von ihrer Verwendung in einer prozesszentrierten Umgebung entwickelt wurden und eigene Reaktionen auf bestimmte Nachrichtentypen realisieren In komponentenbasierten Ans tze tritt die Grundidee der Entkopplung von Verarbeitung Komponentenfunktionalit t und Koordination Zusammenspiel der Komponenten in Form von Koordinations und Kompositionssprachen und spezieller Mediatordienste auf Diese sind jedoch ebenso wie Architekturbeschrei bungs und Skriptsprachen nicht eigens f r die Prozessmodellierung entwickelt worden und bewegen sich auf einem relativ niedrigen technischen Abstraktionsni veau 3 3 4 Beschreibung von Werkzeugdiensten 3 3 4 1 Motivation Im vorangegangenen Abschnitt haben wir uns mit unterschiedlichen Mechanismen f r die Wer
549. teren vorbereitenden Ma nahmen Terminal Emulation Login Skripte Aus wahl eines Netzknotens unter dem Gesichtspunkt der Lastbalancierung etc verwendet B hm98 F r die Realisierung von Wrappern werden in der Regel Shell Skripte verwen det Problematisch ist dabei dass wesentliche Werkzeugcharakteristika zum Bei spiel der Bezug zwischen den Werkzeugparametern und den Produktdaten im Prozess Repository ad hoc und innerhalb des Shell Skripts behandelt werden und auf der Prozessmodellierungsebene nicht sichtbar sind da Shell Sprachen keine explizite Deklaration einer Ein Ausgabeschnittstelle vorsehen und lediglich die R ckgabe eines einzelnen Integer wertigen Statuscodes erlauben der nur Auf schluss ber die erfolgreiche oder fehlgeschlagene Ausf hrung des Werkzeugs gibt Die so spezifizierten Referenzen auf externe Werkzeuge haben aus Sicht der Prozessmodellierung keine Semantik Zum Teil werden diese Defizite durch die erweiterte Shell Sprache SEL Shell Envelope Language GiKa91 behoben welche f r die auf einem Regelformalis mus basierende prozesszentrierte Umgebungen Marvel BaKa91 und Oz Be Ka98 speziell zum Blackbox Wrapping von Werkzeugen entwickelt wurde Ein in SEL spezifizierter Envelope hat folgenden Aufbau siehe Abb 15 ENVELOPE name Abb 15 SHELL ksh csh sh Ger st einer SEL Wrap INPUT perspezifikation GiKa91 types X1 pexm Xm OUTPUT typey Y typeyn 7 Yn BEGIN lt Body speci
550. terschiedlichen Bedeutungen verwendet wird werden in den meisten Publikationen zu diesem Thema drei konstituierende Elemente einer Methode genannt vgl z B HoVe97 Oll 91 Tolv98 Jar 98 Lyy 98 Ha Sa96 14 2 Prozessorientierte Unterstutzungsfunktionen Q Ontologie Darunter versteht man die einer Methode zugrunde liegende konzeptuelle Struktur d h den Vorrat an Konzepten und Strukturierungs konstrukten die zur Beschreibung des Systems verwendet werden Kern konzepte im Bereich der Strukturierten Analyse Methoden YoCo79 Y our89 McPa84 DeMa79 sind z B Prozess Datenflnss und Datenspeicher so wie die hierarchische Dekomposition von Prozessen w hrend bei den ob jektorientierten Methoden z B Rum 91 JCJO92 Booc94 BoJR99 die Begriffe Klasse Objekt und Methode sowie die Strukturierungsprinzipien Ver erbung Spezialisierung und Kapselung eine behertschende Rolle spielen Q Notation Die in einer Ontologie definierte Konzeptwelt kann nur dann verwendet werden wenn f r die einzelnen Konzepte und Strukturierungs konstrukte geeignete Repr sentationen definiert werden Gerade in Me thoden f r die fr hen Entwicklungsphasen setzen sich grafische Notatio nen wegen ihrer gr eren Verst ndlichkeit und bersichtlichkeit gegen ber textuellen durch Beispiele sind Datenflussdiagramme im Bereich der Strukturierten Analyse oder Klassendiagramme in objektorientierten Me thoden Die Beziehung zwischen den Konzepten und ihrer
551. terst tzung in erster Linie der techni schen Arbeitsplatzebene zugute obwohl Hilfesysteme prinzipiell auch die Benutzung von Werkzeugen des Projektmanagements unterst tzen k n nen O Integrationstiefe Hilfesysteme sind ihrer Definition nach rechnerbasierte Systeme Sie sind im Allgemeinen von den eigentlichen Werkzeugen der Entwicklungsumgebung entkoppelt in dem Sinne dass ein Hilfesystem nicht direkt auf das Verhalten von Entwicklungswerkzeugen Einfluss nehmen kann sondern dem Benutzer lediglich Empfehlungen und Benut zungshinweise vermitteln kann die der Benutzer dann selbst in den jewei ligen Werkzeugen umsetzen muss Im Fall dynamischer bzw aktiver Hilfe systeme liegt allerdings eine st rkere Kopplung zwischen Hilfesystemen und Entwicklungswerkzeugen vor da das Hilfesystem mit Informationen ber den aktuellen Bearbeitungskontext z B die momentane Dialogsitua tion in einem Werkzeug versorgt werden muss Aber auch bei diesen Ty pen von Hilfssystemen obliegt die Umsetzung der durch das Hilfesystem geleisteten Prozessanleitung im jeweiligen Werkzeugen dem Benutzer Werkzeugbezogene Hilfesysteme sind inhaltlich und systemtechnisch eng mit ihren jeweiligen Werkzeugen verkn pft so dass der Benutzer in ei ner heterogenen Entwicklungsgebung die aus einer gr eren Zahl von Werkzeugen unterschiedlicher Hersteller bestehen mit einer ebenso gro 30 2 Prozessorientierte Unterstutzungsfunktionen en Zahl untereinander im Al
552. tierende Forderung nach prozesssensitiven Benutzerschnittstellen behandeln wir in Abschnitt 3 3 6 Beobachtungsinkonsistenzen Eine Beobachtungsinkonsistenz ist dann gegeben wenn der beobachtete Prozess keine korrekte Sicht auf den realen Prozess wiedergibt Solche Inkonsistenzen sind darauf zur ckzuf hren dass prozessrelevante Ereignisse in der Durchf hrungs dom ne nicht oder nur unkorrekt an die Leitdom ne bekannt gegeben oder dort ber cksichtigt werden Beispielsweise k nnte ein Entwickler den Entwurf f r ein Divergenz zwischen Modul fertiggestellt haben ohne dass die Leitdom ne davon Kenntnis erlangt realem und beobachte W hrend der Entwickler gem dem Prozessmodell aus der Modellierungsdom ne tem Prozess nun eigentlich mit der Implementierung beginnen k nnte wartet die Leitdom ne noch auf die in Wirklichkeit bereits erfolgte Fertigstellung des Modulentwurfs Abweichungen dieser Art werden als Beobachtungsabweichungen bezeichnet Im Gegensatz zu bewussten Modellabweichungen die letztendlich auf einen inhaltli chen Konflikt zwischen Prozessmodell und realem Prozess hindeuten sollten Beobachtungsabweichungen auf jeden Fall vermieden werden da von der Leitdo m ne auf der Basis eines unzutreffenden internen Abbilds des realen Prozesszu 3 3 Integrationsanforderungen in prozessintegrierten Umgebungen 97 stands kaum sinnvolle Prozessunterst tzung und kontrolle erwartet werden kann DoFe94 Fern93a Mont94 CDFG96 Cugo98
553. tierendes Werkzeug Benutzer schnittstelle A5 Selektierbarkeit A6 Selektionsnotifikation Das Teilsystem ActionAdapter bildet die Aktionen die im Werkzeugmodell defi niert wurden auf die Dienstschnittstelle des externen Werkzeugs ab und nimmt R ckmeldungen ber die Ausf hrungsresultate entgegen Dazu nutzt es die oben definierten Schnittstellen Al und A2 Der ActionAdapter ist als eine Sammlung von Klassen organisiert die von der Klasse Action siehe auch Abschnitt 7 3 2 2 abgeleitet wurden und daher direkt in die ActionTable eingetragen werden k n nen Anders als die Action Klassen im originalen GARPIT Framework fungieren die ActionAdapter Klassen jedoch nur als Stellvertreter Proxies die den eigentli chen Aktionsaufruf an das zu integrierende Werkzeug delegieren Dabei nutzen sie die jeweils spezifischen Aufrufmechanismen CORBA COM SOAP o Eine wichtige Aufgabe besteht in der Konvertierung zwischen den als Situationsinstan zen definierten Ein und Ausgabedaten einerseits und den von der Werkzeug API vorgegebenen Datenformaten andererseits Das Teilsystem UIAdapter kommuniziert nderungen zwischen der Object Table und der IntentionTable und der Benutzeroberfl che des externen Werk zeugs Beispielsweise werden bei der Ausf hrung eines Entscheidungskontextes ber die APIs A3 und A5 die Kommandoelemente des Werkzeugs auf die Intenti onen der aktuell ausw hlbaren Alternativen angepasst Mithilfe von API A4 w
554. tionale Anforderungen uncnsensenneenseeneennneenneennnennnnennnnn 195 7 3 1 2 Nichtfunktionale Anforderungen nnnsenenneeenneenneennnnnn 196 1 32 Architektur essen e a a a Sa a 197 7 3 2 1 Darstellung nanen a a a a e Ra 197 332 2 Teilsystemein berbliek sahen 198 1 3 2 3 lt SlateM nager u ren liest ted puede coe welsh es eee ees 202 JADA Messagelntertace un cece seccvtes vacua riate AE EE td date ssatveds 205 1 3 22 COMEXEM ANA GE a riet inkl an insbe 207 1 3 3 Implementierung Rai ao Ee eee 219 7 3 4 Beispielanwendung des GARPIT Frameworks ennnen 220 7 3 4 1 Phase 1 Werkzeugmodellierung eenennnnnn 220 7 3 4 2 Phase 2 Implementierung csensenseeseenseenneennnennneennnnnnennnnnn 221 7 3 4 3 Phase 3 Prozessmodellierung u ceeneneesneeenneennnennnnnn 224 7 3 5 Zusammenfassung usessesssnessneennesnnennsennnennsnnnneennnensnnnnenne nennt 226 7 4 Integration existierender Werkzeuge scccccscccccscesscecssseecsccsesecees 226 7 4 1 Anforderungen an Werkzeugschnittstellen uueeenennenn 227 7 42 Wrapper Architektur ueeeseessesssesnseensennnennneenneennennnennnennnnnnnannnnn 229 7 4 3 NMalidieruing aene scene Aeslsskrnenisten A a A 231 TAA ZUSaMMeENfAassung soeces nae oae ina aE a Tan anah eiS 233 7 5 GARPEM die generische Prozessmaschinenarchitektur 000 234 7 5 1 Grobstruktur des GAR
555. tive idle Prozessmaschinen Waiting for Lock Response z idre N Zust nde und Transition Deducing Context c aus Abb 45 currentPCInterpreter deduceContext Waiting for Context Response idle Exception Handling handleException Checking Abort Request checkAbortRequest Ereignis Bedingung Aktion ProcessEngineStarted create GuidanceRequest c send LockRequest LockOkResponse currentPCInterpreter new PCInterpreter c ContextDeduced c c ContextType send ContextRequest c ECResponse result or CCResponse result PCFinished send EndOfEnactment InternalError currentPCInterpreter suspendEnactment Errorc recoverable Error currentPCInterpreter resumeEnactment ErrorChecked unrecoverable Error send EndOfEnactment AbortRequest currentPCInterpreter suspendEnactment AbortC abort not possible send AbortDenied AbortC abort possible send AbortOK send EndOfEnactment ProcessEngineStopped destroy Wird die Prozessmaschine w hrend der Plankontext Ausf hrung durch eine AbortRequest Nachricht aus der Durchf hrungsdom ne unterbrochen geht sie in den Zustand Checking Abort Request ber Transition 10 In diesem Zustand kann die Prozessmaschine berpr fen ob ein Abbruch zu Abweichungen von zwingend vorgeschriebenen Abl ufen u
556. tiven Modus kann der Benutzer frei mit seinen Werkzeugen interagie ren bis ein bestimmter Zustand erreicht wird in dem ein definiertes Prozessfrag ment zur Unterst tzung zur Verf gung steht und von den Werkzeugen der Durchf hrungsdom ne angefordert wird siehe auch Anforderungen Werkzeug unterst tzter Aufruf von Prozessfragmenten in Abschnitt 3 3 7 Im proaktiven Modus kontrolliert die Leitdom ne das Geschehen in der Durchf hrungsdom ne indem sie Dienste in den Werkzeugen aktiviert oder diese in Arbeitsmodi mit eingeschr nktem Funktionsumfang versetzt Nach dem Aufruf eines Werkzeugdienstes erwartet die Leitdom ne generelle Informationen ber die erfolgreiche bzw fehlgeschlagene Ausf hrung des Dienstes sowie ber die R ck gabewerte des Dienstes Im Falle der Aktivierung eines Arbeitsmodus in einem Werkzeug muss die Leitdom ne dagegen ber die getroffene Benutzerauswahl d h welcher Dienst auf welchen Produkten ausgew hlt wurde informiert werden Weiterhin muss die Leitdom ne ber bewusste Abweichungen von den Vorga ben des Prozessmodells informiert werden um die aktuelle Prozessfragmentaus f hrung abbrechen oder eine Ausnahmebehandlung einleiten zu k nnen 3 3 5 2 Bewertung existierender Ans tze In existierenden prozesszentrierten Umgebungen und Workflowmanagement systemen sind im Wesentlichen zwei Ans tze bekannt um die Leitdom ne mit Informationen aus der Durchf hrungsdom ne zu versorgen Explizite R
557. tokolle Schemata Infrastrukturkompo nenten u ber cksichtigen kann um eine nahtlose Integration zu errei chen In der Literatur findet sich f r die beiden erstgenannten Integrationsformen h ufig A posteriori und auch der Begriff a posteriori Integration siehe z B NaWe99 da das betreffende a Priori Integration Werkzeug nicht speziell f r den Einsatz innerhalb einer prozesszentrierten Umge bung ausgelegt wurde sondern erst 7 nachhinein a posteriori dort eingebunden wird Entsprechend spricht man bei der Whitebox Integration von a priori Integra tion da die Verwendung des Werkzeugs im Kontext einer prozesszentrierten Um gebung bereits bei seiner Entwicklung mit eingeplant wurde bzw die M glichkeit besteht es in seiner internen Struktur anzupassen Es ist nicht zu verkennen dass a priori Integrationsans tze vor allem solche Lohnt sich die Besch f die im akademischen Umfeld entstehen und nicht durch die Marktposition gro er tigung mit a priori Softwarefirmen z B Microsoft oder anerkannter Standardisierungsinitiativen Sen z B die OMG getragen werden in der Praxis h ufig auf nur geringe Akzeptanz sto en BrEW92 Dies mag zu einem wesentlichen Teil daran liegen dass bei a priori entwickelten Werkzeugen lediglich ein spezifischer aus wissenschaftlicher 54 3 Integrationsansatze Sicht interessanter Aspekt hier die Prozessintegration im Vordergrund steht Diese Fokussierung geht im Vergleich zu ents
558. tomation Systems and Integration Product Data Representation and Ex change Part 11 Description Methods The EXPRESS Language Reference Manual Interna tional Organisation for Standardization ISO 10303 11 1994 ISO IEC International Standard Information Technology Software Life Cycle Process Tech Report ISO 12207 1995 Jacobson I Booch G und Rumbaugh J The Unified Software Development Process Addison Wesley 1999 Jablonski St und Bussler Ch Workflow Management Modeling Concepts Architecture and Implementation International Thomson Computer Press 1996 Jagannathan V Dodhiawala R und Baum R S Hrsg Blackboard Architectures and Applications Academic Press New York 1989 Jacobson I und Jacobson St Beyond Methods and CASE the Software Engineering Process with its Integral Support Environment Object Magazine Jan 1995 Jarzabek St und Huang R The Case for User Centered CASE Tools Communications of the ACM 41 8 S 93 99 Aug 1998 Jarke M Jeusfeld M A Quix Ch Hrsg ConceptBase V5 1 User Manual Tech Report RWTH Aachen 1999 Jarke M List Th und Weidenhaupt K A Process Integrated Conceptual Design Envi ronment for Chemical Engineering In Proc 18th Intl Conf on Conceptual Modeling ER 99 Paris Frankreich Springer Verlag Nov 1999 S 520 537 Jarke M und Marquardt W Design and Evaluation of Computer Aided Process Modeling Tools In Davis J F Stephanopo
559. ts CC_RefineEntity Auf der linken Seite ist in Pseudo code Notation der Ausschnitt aus der ContextCache Laufzeitstruktur f r die Pro zessmodelldefinition des Entscheidungskontexts CC_RefineEntity angegeben F r die aktuell aktive Kontextinstanz gibt die Laufzeitstruktur an dass die aktuelle Situationsinstanz an das Produkt Publication vom Produkttypen Entity gebun den ist ChoiceContext CC_RefineEntity related Situation OneEntity Entity_to_be Refined Publication alternative _Contexts EC_CreateIsALink EC_D scriminateEntity C ShbtypeEntity p ExecutableContext EC CreateIsALink Nichtselektierbare display_of_Intention Produktinstanzen Pull Down Menu Edit m m om deaktiviert Shortkey Crtl I CommandIcon createIsaLink xpm related Situation TwoEntities PRO ART 2 0 ERD Editor en ERD SuperEntity Entity Document Edit Tools Prefere ces Ba Entity ISA Link gt LN Hiscrhninate Entity xecutableContext EC_DiscriminateEntity AE TP _suvtype Entity 1 a PlanContext PC_SubtypeEntity r display_of_intention Pull Down Menu Edit Shortkey Crtl S CommandIcon subtypeEntity xpm related_Situation OneEntity Entity_to_be Subtyped Entity Potenziell auswahlbare Aktuelle Situationsinstanz Produktinstanzen hervorgehoben selektierbar Gem der Definition des Entscheidungskontexts stehen dem Benutzer f
560. ttstelle des einzubettenden Fragments in die Sprache des bergeordneten Prozessfragments transformiert und entspre chende Bindungen definiert werden so dass eine entsprechende Laufzeitumge bung vorausgesetzt prinzipiell auch stark heterogene Formalismen interoperieren k nnen Wichtiges Unterscheidungsmerkmal von Komponentenmodellen allgemein sind der zugrunde liegende Komponentenbegriff d h welche Prozessentit ten als Komponenten verstanden werden und wie diese strukturiert sind sowie die Art der Komposition und Interaktion der Komponenten Die Art des Kompositions und Interaktionsmechanismus legt dann fest wie die einzelnen Komponenten gekoppelt werden und wie die Dynamik zwischen den Komponenten spezifiziert wird 6 2 3 1 Open Process Components Das Open Process Components Rahmenwerk OPC GaLK98 ist ein objektorien tiertes Interoperabilit tsmodell f r Prozesskomponenten welches in drei Abstrak tionsschichten gegliedert ist Die oberste Modellschicht basiert auf dem PCTS LCPS Metamodell Dern94 und identifiziert elementare Prozessentit ten als Klassen Die Modellschicht legt m gliche Beziehungen zwischen Prozessentit ten fest Prozesse k nnen aus atomaren Aktivit ten zusammengesetzt werden oder stehen in Beziehung zu einem Subprozess Rollen werden Aktivit ten zugewiesen und k nnen durch Agenten ausgef hrt werden Produkte setzen sich aus Teilen zu sammen und sind Eingabe oder Ergebnis einer Aktivit t Die Mod
561. tzt O Entkopplung zwischen High Level und Low Level Ereignisverwaltung ber die Klasse CevtEventQueue wird eine High Level Ereignisverwaltung realisiert die von den Low Level Ereignisschleifen in externen Subsystemen Nach richtenschnittstellen Benutzeroberfl che weitgehend entkoppelt ist Da durch kann beispielsweise im Zustand CsttWaitingForLockRequest ein o gisch synchrones Warten auf eine Antwortnachricht aus der Leitdom ne emuliert werden obwohl die physischen Ereignisse in Wirklichkeit weiter hin asynchron eintreffen Dies verhindert insbesondere dass Low Level Ereignisse in der grafischen Benutzeroberfl che die f r die globale Werk zeugkontrolle irrelevant sind blockiert werden z B Aktualisierung der Fensterdarstellung nach Ver ndern der Fenstergr e Verschieben des Fensters etc O Wiederverwendung in der Leitdom ne Das von den Klassen CsttStateDriver CsttState CsttTransition und CevtEventqueue gebildete Grundger st konnte in der Leitdom ne zur Realisierung der globalen Prozessmaschi nenkontrolle unver ndert wiederverwendet werden 7 3 2 4 Messagelnterface Das Teilsystem MessageInterface realisiert eine Nachrichten basierte Schnitt stelle ber die das Werkzeug Nachrichten an die Prozessmaschine verschicken und von dort empfangen kann siehe Abb 52 Dieses Paket besteht aus den beiden Teilpaketen Communicat Klassenpr fix Cmsg tionChannel Klassenpr fix Cskt un
562. u erbringen sind aus welchen Teilschritten sich die Aufgabe zusam men setzt in welcher Reihenfolge die Teilschritte abgearbeitet werden sollen welche Handlungsalternativen in bestimmten Problemsituationen in Frage kom men bzw zu favorisieren sind welche unterst tzenden Softwarewerkzeuge zur Verf gung stehen und wie diese zur Durchf hrung von Teilaufgaben innerhalb des Entwicklungsprozesses sinnvoll eingesetzt werden k nnen Die Wirksamkeit der Kommunikation von Prozesswissen h ngt wesentlich von der Integrationstiefe der Prozessunterst tzung ab Darunter verstehen wir den Grad der Interaktion und Beeinflussung der brigen Komponenten der rechnerba sierten Arbeitsumgebung insbesondere der Entwicklungswerkzeuge durch die Prozessunterst tzung Generell gilt dass die Chance dass die angebotene Unter st tzung wahrgenommen wird bzw dass verbindliche Prozessvorgaben tats chlich befolgt werden umso gr er ist je enger die Prozessunterst tzung mit den Kom ponenten der rechnerbasierten Arbeitsumgebung integriert ist Abb 2 illustriert den Zusammenhang zwischen dem durch die Prozessunterst tzung bereitgestell ten Prozesswissen dem Prozessausf hrenden d h dem Entwickler und seiner aus den Entwicklungswerkzeugen bestehenden Arbeitsumgebung Bez glich der Integrationstiefe unterscheiden wir drei Auspr gungen extern rechnerbasiert separat und rechnerbasiert prozessintegriert 2 Prozessorientierte Unterstutzungsfunktionen
563. ugmodelle 5 1 1 UML Zur bersichtsartigen Darstellung der Modelle verwenden wir Klassendiagramme der Unified Modeling Language UML BoJR99 Die Wahl der UML als prim r in dieser Arbeit verwendeter Notation liegt zum einen darin begr ndet dass die UML in einer intuitiven grafischen Darstellung alle wesentlichen Konzepte bereit stellt wie sie etwa in Arbeiten zur Standardisierung von Objektmodellen SoKe95 zu objektorientierten Programmiersprachen CaWe85 Meye90 AbCA96 oder zu objektorientierten Datenbanken Atk 89 Beer90 LaVo97 gefordert werden Zum anderen stellt die UML als Resultat der Vereinigung und Konsolidierung der Obekonenioite Tagua popul rsten Modellierungsnotationen der 80er und fr hen 90er Jahre Rumbaugh s franca OMT Rum 91 Booch s OOAD Booc94 und Jacobson s OOSE JCJO92 einen vorlaufigen Endpunkt im Bereich der konzeptuellen objektorientierten Sprachen dar und hat mit der Standardisierung durch die Object Management Group OMG 97a Kobr99 den Status einer objektorientierten lingua franca erreicht Die Notation und Semantik der in dieser Arbeit verwendeten UML Mo dellierungselemente wird als bekannt vorausgesetzt Weitergehende Informationen sind der UML Sprachdefinition in BoJR99 bzw RuJB99 sowie diversen UML Lehrb chern z B ErPe98 HiKa99 zu entnehmen 5 1 2 O Telos F r eine Formalisierung der in der Arbeit vorgestellten konzeptuellen Modelle wird die logikbasierte objektor
564. ukturen eines Anwendungsbereichs zusammen und kondensieren dieses in einer wieder und weiterverwendbaren Form Grif98 Ein Framework stellt somit ein Anwendungsger st f r die Entwicklung einer bestimmten Klasse von Softwaresystemen dar Das Framework gibt die Architektur bereits in wesent lichen Z gen vor und schafft so einen Kollaborationsrahmen f r existierende und noch zu entwickelnde Teilkomponenten Die generischen Teile eines Frameworks liegen dabei h ufig nicht nur in Form von Spezifikationen sondern bereits als vorgefertigte Softwarebausteine vor Die Austausch und Erweiterbarkeit von Teilkomponenten in Richtung einer konkreten Anwendung l sst sich in einem Framework durch so genannte hot spots kennzeichnen Pree97b An solchen interessanten Variationspunkten im Frame work werden h ufig hnliche aber doch differenzierte Funktionen bzw konkreti sierende Anpassungen ben tigt Dabei bleibt jedoch grunds tzlich der vom Fra mework vorgegebene Architekturrahmen erhalten F r den Anschluss spezifischer Anwendungsfunktionalit t an den Variationspunkten werden h ufig Entwurfs muster GHJV95 Pree97a Srin99 eingesetzt wie zum Beispiel das Factory Muster das die Framework gesteuerte Erzeugung neuer Komponenten die zun chst nicht Bestandteil des Frameworks waren erlaubt oder das Bridee Muster das dem Fra mework einen einheitlichen Zugang zu unterschiedlich realisierten Fremd Komponenten mit hnlicher Funktionalit t erm
565. ulationsmodell Werkzeug aktivierbaren Kontexte EC Angabe der Betriebsbedingungen und der Grohe des Reaktor Angabe der Betriebsbedingungen und der Gr e des Reaktors Das generische Anleitungswerkzeug wurde so entworfen dass es nicht nur externe Werkzeug nachbildet sondern f r alle Werkzeuge also insbesondere auch die origin ren PRIME Werkzeuge eine alternative Schnittstelle zur Kontextaktivie rung und r ckmeldung bereitstellt In der grafischen Benutzerschnittstelle existiert f r jede Werkzeugkategorie ein Teildialog Reiter in der alle aktuell ausf hrba ren Kontexte dieses Werkzeugs aufgelistet sind Um das Verhalten origin rer PRIME Werkzeuge dynamisch nachbilden zu k nnen muss das Anleitungswerk 7 1 Die PRIME Gesamtarchitektur zeug die dort durchgefthrten Aktion nachziehen Zu diesem Zweck registriert sich das Anleitungswerkzeug beim Prozessspuren Server und wird so ber die in den PRIME Werkzeugen durchgef hrten Abl ufe auf dem Laufenden gehalten 7 1 2 6 Administrations und Metamodellierungswerkzeuge Zur Erstellung und Pflege der im Prozess Repository abgelegten Prozess Werk zeug und Produktmodelle existieren eine Reihe von Administrations und Meta modellierungswerkzeugen Wie in Abb 34 angedeutet nehmen diese Werkzeuge eine interessante Zwitterrolle zwischen der Modellierungs und der Durchf h rungsumgebung ein Konzeptuell k nnen sie der Modellierungsdom ne zugeord net werden da sie prim
566. ulos G und Venkatasubramaniam V Hrsg Proc Intl Conf on Intelligent Systems in Process Engineering AIChE Symposium Series Vol 92 No 312 1996 S 97 109 Janning Th Requirements Engineering und Programmierung im Gro en Integration von Sprachen und Werkzeugen Dissertation RWTH Aachen Deutscher Universitatsverlag Wiesbaden 1992 Jarke M Gallersd rfer R Jeusfeld M A Staudt M und Eherer St ConceptBase A Deductive Object Base for Meta Data Management Journal of Intelligent Information Systems 4 2 S 167 192 1995 Jarke M Pohl K Weidenhaupt K Lyytinen K Marttiin P Tolvanen J P und Papazoglou M Meta Modelling A Formal Basis for Interoperability and Adaptability In Kr mer B Papazoglou M und Schmidt H W Hrsg Information Systems Inte roperability Research Studies Press Taunton Somerset England 1998 S 229 263 Jarke M List Th Nissen H W Lohmann B und Hubbuch K Bericht zum Workshop Verfahrenstechnische Datenbanken Interner Bericht Bayer AG 1998 JavaSoft The JavaBeans Bridge for ActiveX Feb 1998 http java sun com products javabeans software bridge Jacobson I Christerson M Jonsson P und Overgaard G Object Oriented Software Engineering A Use Case Driven Approach Addison Wesley 1992 Jeusfeld M A und Papazoglou M Information Brokering In Kr mer B Papazoglou M und Schmidt H W Hrsg Information Systems Interoper
567. und A6 in Ab schnitt 3 3 6 bzw 3 3 7 Darstellungsarten Die grafische Repr sentation eines Produkts wird mithilfe der Assoziations klasse Darstellungselement modelliert Da diese Klasse nicht nur mit der Klasse Produkt sondern auch mit der Klasse Werkzeugkategorie verkn pft ist kann f r jede Werkzeugkategorie in der ein bestimmtes Produkt angezeigt werden kann eine spezifische Darstellung gew hlt werden Die Klasse Darstellungselement selbst dient als Ankerpunkt f r eine detaillierte Modellierung der Repr sentation eines Produkts durch eine bestimmte grafische Form z B Rechteck Kreis Raute etc Weitere Darstellungsattribute Farbe Gr e u die f r unterschiedliche Aktivierungszust nde eines Produkts unterschiedlich gesetzt werden k nnen werden in der Klasse Darstellungsart zusammengefasst Kommandoelemente Der Benutzer interagiert mit modernen interaktiven Benutzeroberfl chen in dem er grafische Repr sentationen der Modellierungsprodukte ausw hlt und eine Funktion auf diesen Produkten durch ein entsprechendes Kommandoelement an st t Welche Kommandoelemente ein Werkzeug bereitstellt wird durch die Assoziation bietet KE_an definiert Die Klasse Kommandoelement unterteilt sich in verschiedene Subklassen In unserer aktuellen Implementierung siehe Kapitel 7 unterst tzen wir als in heutigen Benutzeroberfl chen g ngigste Kommandoele mente Pulldown Men s Popup Men s Shortkeys und Kommando Icons
568. und Anforderungen Die im vorangegangenen Abschnitt vorgenommene Betrachtung der Anforderun gen an eine integrierte Prozess und Werkzeugmodellierung haben ergeben dass das Prozessmetamodell Konzepte zur Spezifikation von Beratungsdiensten Benut zerauswahlen und Anleitungsdiensten Schrittfolgen umfassen muss Weiterhin erforderlich sind Konzepte zur Referenzierung elementarer Dienste die von den Werkzeugen angeboten werden und im Werkzeugmodell genauer spezifiziert werden Im Kontext dieser Arbeit resultieren aus der Fokussierung auf entwicklerori entierte kreative Entwurfsprozesse weitere Anforderungen an die Kernelemente einer geeigneten Prozessmodellierungssprache zu denen im Wesentlichen die fragmentweise Darstellbarkeit von Prozessen Kontextbasiertheit und Kompositi onalit t geh ren Q Fragmentweise Darstellbarkeit von Prozessen Wie in Abschnitt 2 1 1 motiviert wurde entziehen sich kreative Entwurfsprozesse in der Regel ei ner vollst ndigen und durchg ngigen Pr skription Das bedeutet dass es im Allgemeinen nicht m glich ist f r jede denkbare Situation innerhalb des Entwurfsprozesses festzulegen welcher Arbeitsschritt als n chstes ausgef hrt werden sollte Daher gelingt die Prozessmodellierung nur frag mentweise f r gutverstandene Abschnitte des Entwicklungsprozesses Aus diesem Grund muss ein Prozessmodell als eine erweiterbare Sammlung unabh ngiger oder nur lose gekoppelter Prozessfragmente organisiert wer den
569. ung durch die Prozessma schine siehe Abschnitt 3 3 6 sowie die Aktivierung von Prozessfragmenten aus den Werkzeugen siehe Abschnitt 3 3 7 werden jedoch nicht direkt unterst tzt Aus Benutzersicht bieten GTSL basierte Werkzeuge zwar kontextsensitive Men s an Deren Inhalt ist jedoch ausschlie lich durch den aktuellen Zustand des zugrunde liegenden abstrakten Syntaxgraphen das aktuell selektierte Produktin krement und die in der Werkzeugspezifikation angegebenen Aktionsregeln be stimmt GTSL Weitere Beispiele f r Werkzeuggeneratoren kommen aus der Forschung ber MetaCASE Umgebungen Method Engineering und MetaCASE Umgebungen Alde91 KeSm96 Brin96 Das prim re Ziel dieser Ans tze liegt in der schnellen Anpassbarkeit von Werk zeugumgebungen an spezifische Modellierungsnorationen Grundlage der meisten MetaCASE Umgebungen ist die Modellierung der zu unterst tzenden Notationen als Instanz eines generischen Metamodells aus dem eine Menge von spezifischen Werkzeugdiensten zur Modellmanipulation abgeleitet werden Das Dienstangebot eines so generierten Werkzeugs h ngt jedoch nur von der Struktur der jeweiligen Modellierungsnotation ab und ist nicht an explizite Prozessdefinitionen gekoppelt Zudem ist das Spektrum der von einer MetaCASE Umgebung unterst tzten Notationen stark vom zugrunde liegenden Metamodell beschr nkt So lassen sich beispielsweise innerhalb der MetaEdit Umgebung mithilfe des GOPRR Metamo dells KeLR95 lediglich so g
570. ung h ngt stark davon ab ob die Registrierung beim Message Server statisch d h unabh ngig von der Laufzeit eines Werkzeugs oder dynamisch durch ein Werk zeug selbst also z B beim Werkzeugstart erfolgt Im ersten Fall sind die Registrie rungsinformationen au erhalb der Werkzeuge in der Regel in Form von Konfigu rationsdateien zug nglich Die dynamische Registrierung ist zwar flexibler jedoch sind hier die Registrierungsinformation in den Werkzeugen versteckt typischer weise in den Codeabschnitten f r die Anmeldung beim Message Server und somit zur Werkzeugbeschreibung bei der Definition von Prozessfragmenten wertlos Ein Beispiel f r eine rein statische Registrierung ist der Polylith Software Bus w hrend ToolTalk sowohl statische als auch dynamische Registrierung unterst tzt In Fo rest liegen die policy descriptions als erweiterte Werkzeugbeschreibungen explizit vor k nnen aber auch w hrend der Laufzeit ber das Policy Tool modifiziert werden Eine Besonderheit stellen die bereits weiter oben erw hnten Werkzeugprotokolle in SoftBench dar wo der Prozessmodellierer von einem Grundvorrat an standardisier ten Werkzeugschnittstellen f r bestimmte Werkzeugklassen ausgehen kann Werkzeugmodellierung in prozesszentrierten Umgebungen In existierenden prozesszentrierten Umgebungen und Workflow Management Systemen ist die Konzeptwelt der zugrunde liegenden Prozessmodellierungsspra chen durch Modellierungselemente wi
571. ung referen ziert werden z B ein Klassendiagramm muss Prozessunterst tzung auf der Arbeitsplatzebene auch auf einzelne Produktteile innerhalb der Internstruktur von Dokumenten z B einzelne Klassen oder Attribute innerhalb eines Klassendia gramms Bezug nehmen Sichtweise auf Ent Damit einher geht eine unterschiedliche Sichtweise auf die Entwurfsprodukte F r wurfsprodukte den Projektmanager sind in erster Linie administrative Eigenschaften eines Produkts von Belang z B der aktuelle Status eines Software Dokuments in Bearbeitung fertiggestellt gepr ft etc W hrend auf der Ebene der Projektadministration von den konkreten Inhalten eines Dokuments im Allgemeinen abstrahiert wird ist f r die Arbeitsplatzebene ein inbaltsorientierter Umgang mit den in Bearbeitung befindli chen Produkten kennzeichnend Rolle der Entwicklungs Die f r die Prozessdurchf hrung verwendeten Entwicklungswerkzeuge spielen auf werkzeuge den beiden Ebenen eine unterschiedliche Rolle W hrend auf Projektmanage mentebene Werkzeuge nicht ber cksichtigt oder lediglich als eine Ressource zur Aufgabenbearbeitung hnlich wie Dokumente angegeben werden muss auf Arbeitsplatzebene der Umgang mit einzelnen Werkzeugen und die Nutzung spezi fischer Werkzeugfunktionen zur Durchf hrung von Arbeitsschritten detailliert in die Prozessunterst tzung einbezogen werden Planbarkeit der Erhebliche Unterschiede weisen Projektmanagement und Arbeitsplatzebene Prozesse
572. ung sprachneutraleDarstellung DB SchnittstellenBindung hat _beh lterBindung P al ssb 11 pbl and al in DB and P a2 ssb 12 pb2 and a2 in DB and P a3 pb1 13 pl1 and a3 in KKB and P a4 pb2 14 p2 and a4 in KKB and P a5 pb1 15 ql and a5 in PSB and P a6 pb2 16 q2 and a6 in PSB and ql q2 gt pl p2 end Aktivitatsbindung Die Aktivit tsbindung entspricht der hat _Subkontext Beziehung des NATURE Prozessmodells und repr sentiert die Verwendung einer Kontextkomponente in einer PK Komponente Die Aktivit tsbindung bindet das Konzept einer Kontext komponente an das atomare Aktivit tskonzept der Prozessmodellierungssprache F r die vollst ndige Abbildung einer Komponente ist es erforderlich dass die Komponente selbst sowie deren Ein und Ausgangsschnittstelle in der Verwen dungssprache dargestellt wird Daher besteht die Aktivit tsbindung aus weiteren Subbindungen die jeweils die Bindung der Ein und Ausgangsschnittstelle der Kontextkomponente repr sentieren 6 4 Schnittstellenbindung 157 Bindung Eine Bindung fasst alle Informationen zusammen die zur Bindung einer Kontext komponente an die Konzepte einer spezifischen Prozesssprache erforderlich sind Dieses Konzept aggregiert demnach alle zusammengeh renden Aktivitats Schnittstellen und Datenbehalterbindungen Neben dem Aspekt der Formalisierung der Abbildungsregeln dienen Bindun gen dazu die notwendigen Verwendungsinformationen von
573. ung stehen Abschlie end wollen wir noch darauf hinweisen dass nderungen an Prozes sen die durch die Adaptionsmechanismen eines Prozessunterst tzungsansatzes umgesetzt werden sollen zum Teil weitreichende Auswirkungen auf die produkt orientierten Komponenten einer Entwurfsumgebung haben Lyy 98 Wenn beispielsweise der Entwicklungsprozess von strukturierter Analyse auf eine ob jektorientierte Methodik umgestellt werden soll resultiert diese nderung nicht nur in ver nderten Arbeitsprozessen sondern muss nat rlich auch in den verwen deten Werkzeugen ber cksichtigt werden Konkret bedeutet dies dass existierende Werkzeuge f r die Erstellung von Datenfluss und ER Diagrammen durch objekt orientierte Spezifikationswerkzeuge ersetzt werden m ssen Produktorientierte Anpassungsmechanismen sind Gegenstand der Forschung im Bereich MetaCASE Umgebungen oder CASE Shells z B MetaEdit KeLR95 Kogge EbSU97 MetaView SoTM88 Diese Umgebungen bieten Metamodell basierte Interpreta tions und Generierungsmechanismen mit deren Hilfe Werkzeugumgebungen an ge nderte oder neue Modellierungskonzepte und notationen angepasst werden k nnen Innerhalb der vorliegenden Arbeit werden wir diesen Typ von Anpassung einer Umgebung jedoch nicht weiter betrachten 2 1 5 Unterst tzungsmodi und Durchsetzungsgrad Prozessunterst tzungssysteme k nnen in die eigentliche Prozessdurchf hrung auf unterschiedliche Art und Weise eingreifen Auf der eine
574. ungen die ber den CDIF Standard hinausgehen wichtig ist Insgesamt hat CDIF als spezifisches Austauschformat von Seiten der Werk u zeug Hersteller nur z gerliche Unterst tzung erfahren und spielt als konkreter ee as Faclliyder A ustauschstandard heute keine Rolle mehr Allerdings finden sich wesentliche Elemente des CDIF Metametamodells in der Meta Object Facility MOF der 3 3 Integrationsanforderungen in prozessintegrierten Umgebungen 63 Object Management Group OMG wieder OMG 97c MOF ist ein von der OMG standardisierter Mechanismus zur Darstellung von Metadaten und wurde insbe sondere f r die Metamodellierung der ebenfalls zum OMG Standard erhobenen Unified Modeling Language verwendet MOF wird verk rpert durch einen Satz von CORBA APIs ber die Werkzeuge den Austausch von UML Daten realisie ren k nnen In eine hnliche Richtung geht auch das Open Information Model im Microsoft Repository Ber 99 das als eine Sammlung von definierten COM Schnittstellen f r den Austausch von Modell und Metamodelldaten organisiert ist Als Alternative zu API basierten Methoden des Datenaustauschs gewinnt in j ngster Zeit die HTML Erweiterung XML Extended Markup Language BrPS98 immer gr ere Bedeutung sowohl als Beschreibungssprache f r einheit liche Austauschformate als auch zur Darstellung konkreter Austauschdaten Mit XMF XMI 99 liegt mittlerweile ein OMG Standard vor der die Abbildung von MOF bzw MOF kompatiblen UML Mode
575. unterschiedlichen Darstel lungsarten angereichert in Abb 22 nicht dargestellt Insgesamt wird dadurch die Konsistenzbedingung EK1 bez glich der Zuordnung zwi schen der Werkzeugkategorie ER Editor und dem Entscheidungskon text EK_Verfeinerekntit t erf llt d h der ER Editor ist in der Lage alle Produkte die zu Situationen der Alternativen von EK VerfeinereEntit t beitragen k nnen in den entsprechenden Dar stellungsarten zu repr sentieren 5 7 Fazit Die Definition von Prozess und Werkzeugmetamodell sowie deren Integration zu einem Umgebungsmodell bilden das konzeptuelle Fundament f r die Prozessin tegration von Werkzeugen Der Methodeningenieur wird in der Zuordnung der im Prozessmodell definierten Prozessfragmente zu den entsprechenden Werkzeug funktionalit ten unterst tzt hnlich dem Signaturvergleich von algebraischen Spezifikationen ChHJ93 kann die korrekte Zuordnung von Ausf hrungs und Entscheidungskontexten zu Werkzeugkategorien durch berpr fen der als O Telos Constraints formalisierten Konsistenzbedingungen AK1 AK3 sowie EK1 und EK2 gew hrleistet werden Das Umgebungsmodell wird von den aktiven Hauptkomponenten einer pro zessintegrierten Entwurfsumgebung Prozessmaschine Kommunikationsmecha nismus und Werkzeuge zur Laufzeit interpretiert Die Prozessmaschine entnimmt dem Umgebungsmodell Informationen ber Ablaufreihenfolgen bei der Abarbei tung
576. uppe f r den VT Prozessschritt Separa tion angelegt in die der Verfahrensingenieur nun eine Kaskade von Destillations kolonnen statt einer einzelnen Kolonne eintr gt Abschlie end wird durch den Ausf hrungskontext EC_FBW CreateDependencies die Abh ngigkeitsstruktur so aktualisiert dass sich die in Abb 82 dargestellte Situation ergibt Mit der Beendi gung des Plankontexts geht die Werkzeugumgebung wieder in den unangeleiteten Unterst tzungsmodus ber EI PRIME Dependency Editor Browser Noname ioli Abb 82 Aktualisierte Abh ngig Document Edit Tools Preferences Help keitsstruktur nach der Entscheidungsrevision und Durchf hrung einer alternativen Verfeinerung DEP Basen Realization of Separation by Destillation Verfeinerung durcHfDestillationskollone DEP_Raplaces I Realization of Separation by Column Cascade Verfeinerung durch Kolonnenkaskade amp canceled Pian Context Choice Context Executable Context es E 8 3 3 Zusammenfassung In diesem Abschnitt wurde anhand einer Beispielsitzung die Definition und Aus f hrung eines komplexen M Prozessfragments illustriert Gezeigt wurde ein M Prozessfragment f r die systematische Verfeinerung eines VI Prozessschritts Verglichen mit einem unangeleiteten Verfeinerungsschritt hat der durch den Plankontext gesteuerte Verfeinerungsablauf den Vorteil dass der Verfahrensinge nieur 1 vorab auf bereits existierende Verfeinerungen hingewiesen wu
577. us Abschnitt 7 2 1 gibt einen berblick ber die Funktionalit t der einzel nen Werkzeugzust nde und Transitionen Die Klasse CsttStateDriver realisiert eine generische Zustandsmaschine und wurde als Singleron Klasse entworfen d h pro Werkzeuginstanz existiert genau eine Instanz dieser Klasse die beim Werkzeugstart kreiert wird Das CsttStateDriver Objekt verwaltet die Verkn pfungen zwischen einer Menge von CsttState und 32 Alle Klassennamen des PRIME Frameworks tragen ein Pr fix C lt Paketktirzel gt das sich auf das Paket dem die Klasse zugeordnet ist bezieht Das StateManager Paket ist intern in zwei Teilpakete aufgeteilt State mit dem Pr fix Cstt und Event mit dem Pr fix Cevt 7 3 GARPIT ein Framework f r prozessintegrierte Werkzeuge 203 CsstTransition Objekten d h die Beziehungen zwischen CsttState und CsttTransition Objekten sind a priori nicht hartkodiert vorgegeben Als Basis klasse f r spezialisierte StateDriver Klassen implementiert der CsttStateDriver zun chst nur ein leeres Zustandsdiagramm F r ein spezifisches Zustandsdia gramm wird eine Subklasse von CsttStateDriver definiert die in ihrem Kon struktor die ben tigten CsttState und CsttTransition Objekte selbst erzeugt und eine entsprechende Verkn pfungsstruktur initialisiert Innerhalb des GAR PIT Frameworks bernimmt die Klasse CsttToolStateDriver diese Rolle Auf Seiten des Prozessmaschinen Frameworks GARPEM gibt es e
578. usskon strukte und eine operationale Semantik verzichtet und stattdessen die Strategie verfolgt eine existierende Sprache zur Ablaufspezifikation zu verwenden und die Konzepte des NATURE Prozessmodells in dieser Sprache abzubilden Konkret wurden hier Prozessfragmente als Methoden von Plankontext Objekten in der Programmiersprache C formuliert und zur Prozessmaschine hinzugebunden Au erdem wurde die Repr sentation des NATURE Prozessmodells in dem Petri netz Dialekt SLANG untersucht und prototypisch in einer entsprechenden Pro zessmaschine umgesetzt Klam95 Ziel hier Interoperable In dieser Arbeit greifen wir den in Pohl96 Poh 99 beschriebenen Ansatz der Verwendung beliebiger Einbettung des NATURE Prozessmodells in existierende Ablaufformalismen auf Sprachen zur Ablauf 3 A RE ee spezifikation von Plan gehen aber noch einen Schritt weiter und untersuchen wie sich potenziell be ebige kontexten Ablaufformalismen innerhalb des vom NATURE Prozessmodell vorgegebenen Rahmens znteroperabel verwenden lassen Diese Zielsetzung ist durch die mittler weile allgemein anerkannte Tatsache motiviert dass die in den letzten 15 Jahren vorgeschlagenen Prozessmodellierungssprachen jeweils spezifische St rken und Schw chen aufweisen und kein einzelner Formalismus bzw kein Sprachparadigma z B prozedurale Sprachen oder Netzformalismen als ideal anzusehen ist ABGM93 GaLK98 HoVe97 GaJa96a Vielmehr stellen unterschiedliche Ab l u
579. utzer abstimmen zu k nnen Ein wniformes Hilfesystem liefert jedem Benutzer dieselbe Hilfeleistung unabh ngig von seinem Kenntnis und Erfahrungsstand Eine individuelles Hilfe system unterscheidet dagegen verschiedene Benutzergruppen oder modelliert die Eigenschaften eines jeden Benutzers individuell um so gezieltere Hilfestellung geben zu k nnen Ein passives Hilfesystem geht davon aus dass der Benutzer von sich aus aktiv wird und eine Hilfeleistung z B durch Dr cken der Hilfetaste anfordert und eine Anfrage an das Hilfesystem stellt z B durch Eingabe von Schl sselw rtern Navi gation durch Informationsnetze Anfragen in nat rlicher Sprache Ein Benutzer ist immer dann in der Lage passive Hilfe anzufordern wenn er selbst Probleme erkennt bei denen er Unterst tzung ben tigt oder nach bestimmten Informatio nen Funktionen oder Kommandos sucht 2 2 Bewertung existierender Ansatze 29 Ein aktives Hilfesystem beobachtet das Benutzerverhalten und wird von sich aus aktiv um dem Benutzer eine Hilfe zu geben Dies ist besonders dann hilfreich wenn sich der Benutzer selbst nicht dar ber im Klaren ist dass er in eine Prob lemsituation geraten ist oder dass es effizientere Wege zur Erledigung einer Auf gabe gibt Von einem idealen Hilfesystem wird erwartet dass es das gesamte Spektrum der skizzierten Hilfearten abdeckt Tats chlich handelt es sich jedoch bei den heute in der Praxis eingesetzten Hilfesystemen um passive und un
580. vi t t oder als Aktivit tsnetz eine zusammengesetzte Aktivit t verk rpert Uber den Vor bzw Nach Bereich einer SLANG Aktivit t l sst sich in SLANG ein Schnittstellenkonzept realisieren Dabei bernehmen die getypten Stellen die Rolle von Datenbeh ltern Da alle PSM2 Konzepte in der Sprache SLANG identi fiziert werden k nnen kann die Sprache grunds tzlich mit dem Schnittstellenmo dell integriert werden M2 Ebene Abb 32 Klassifikation des SLANG Metamodells Datenbeh lter lt Meta Schnittstelle ai Aktivitat a NT atomareAktivit t zusammengesetzteAktivit t gt Vorbereich 1 1 SLANG Aktivit t Stelle h 3 iS ie Nachbere 1 j 1 1 j I j J 1 I 1 1 1 1 a eae I ie i 1 1 1 j 1 1 1 1 1 Wachter o Aktivitatsnetz gt Transition u Meta Ebene Aktion ER Sprachkonzepte s startet Schritt 2 Verwendungsbindungen f r SLANG Im zweiten Schritt werden die entsprechend dem PSM2 Modell klassifizierten SLANG Konzepte an die Konzepte des Schnittstellenmetamodells gebunden siehe Abb 33 Die komplette Bindungsinformation f r die Verwendung einer Kontextkomponente in SLANG wird durch die Klasse SLANG Bindung repr sen tiert Instanzen dieser Klasse halten den Verwendungspunkt einer Kontextkom ponente in einem
581. vit tskonzept einer Sprache darzustellen ist durchaus konsistent mit dem NATURE Prozessmodell allgemein Neben Ausf hrungs kontexten und Plankontexten die hier als automatisierte Werkzeug bzw Inter pretationsaktivit ten verstanden werden wird die Zielverfeinerung im Rahmen eines Entscheidungskontexts d h der Entscheidungsvorgang als solcher ebenfalls als Aktivit t aufgefasst Wichtig ist dass das Aktivit tskonzept einer Prozesssprache mit einer Schnittstelle einher geht mit der die Dekomposition und Modnlarit t von Aktivi t ten erzielt werden kann und eine Trennung der Implementierung vom Dienstan gebot vorgenommen werden kann Der Datenaustausch zwischen einer Aktivit t und ihrer Umgebung erfolgt ber deren Ein und Ausgangsschnittstelle Dazu werden an der Schnittstelle Datenbe h lter f r die Aufnahme von Produkten in einer spezifischen Rolle deklariert Die Existenz eines Datenbeh lterkonzepts in einer Prozessmodellierungssprache garantiert dass die Aktivit t an den umgebenden Datenfluss angeschlossen werden kann und dass die Implementierung von der Aktivit tsschnittstelle getrennt ist Aktivit ten sind entweder atomare Aktivit ten oder als zusammengesetzte Aktivit ten in weitere Subaktivit ten strukturiert Aus Verwendungssicht werden AK EK und PK Komponenten einheitlich durch das Sprachkonzept einer atomaren Aktivit t einer Prozessmodellierungssprache repr sentiert werden Dazu geh ren z B Transitionen in
582. von Daten Funktions Organisations und Prozessstrukturen f r einen bestimmten Gegenstandsbereich z B Informationsmodellierung Gro 97 oder Anforderungsdokumentation D mg99 verstanden wird Referenzmodelle dienen zur effizienten Ableitung von unternehmens bzw projektspezifischen Strukturen auf der Grundlage vorde finierter Informationsmodelle Reit98 Die Anpassung an spezifische Belange erfolgt durch Auswahl und Parametrierung der f r den jeweiligen Kontext rele vanten Ausschnitte des Referenzmodells Entscheidend f r die Bewertung des Anpassungspotenzials eines Konfigurationsansatzes ist dass das Referenzmodell den Rahmen f r die zur Verf gung stehende Prozessunterst tzung absteckt und dar ber hinaus gehende Prozessunterst tzung zun chst nicht vorgesehen ist In schwach verstandenen Dom nen wie den fr hen Phasen der Software entwicklung in denen Wissen ber ideale Entwicklungsprozesse nur fragment weise vorliegt und durch kontinuierlichen Erfahrungsgewinn st ndigen Verbesse rungen unterworfen ist bieten Konfigurationsans tze immer noch nicht hinrei chende Flexibilit t Stattdessen muss ein Prozessunterst tzungsansatz nderbar sein d h er muss Mechanismen zur Verf gung stellen mit denen die Unterst tzung existierender Prozesse abge ndert werden kann z B die Erg nzung eines Ablaufs zur Informationsmodellerstellung um zus tzliche Dokumentationsschritte vgl auch D mg99 aber auch Anleitung
583. von Werkzeugen und Anwendungssoftware unterst tzen Shne98 Balz96 EbOO94 Wand93 Herc94 Hilfesysteme werden in der Regel als Bestandteil von Anwendungsprogrammen und Werkzeugen ausgeliefert Folglich ist das von solchen Hilfesysteme vermittelte Wissen in der Regel stark werkzeughezogen z B Erl uterungen zu Werkzeugfunktionen Bedeutung von Dialogelementen etc Es gibt jedoch eine Reihe von prozessbezogenen Ans tzen die Prozessdokumenta tion meist in Web basierter Form aufbereiten und strukturieren z B SPEAR MINT Bec 99 Electronic Process Guides Kel 98 V Mode Browser VeM 97 Dazu z hlen auch so genannte Process Asset Libraries PAL die seit einigen Jahren von vielen Firmen systematisch zusammengetragen und den Mitarbeitern innerhalb des 2 Prozessorientierte Unterst tzungsfunktionen Abb 3 Klassifikationsmodell f r Hilfesysteme vgl BaSc88 Balz96 Statische vs dynamische Hilfesysteme Uniforme vs individuelle Hilfesysteme Passive vs aktive Hilfesysteme Firmen Intranets zug nglich gemacht werden H ufig basieren diese Systeme auf Lotus Notes wie zum Beispiel das Produkt aimfirst der Firma aimware das die Orga nisation und Verwaltung von Process Asset Libraries unterst tzt Statische Hilfesysteme Keine Ber cksichtigung des aktuellen Kontexts Dynamische Hilfesysteme Ber cksichtigung des aktuellen Kontexts Uniforme Hilfesysteme f r jeden Benutzer dieselbe Information
584. vsd Aufteilung des Prozesses v5 Abb 7T DEU SAY SHAS OOS RAP SV IDCOXxt Aktivierung des Teej ta en Ar K US SS f ez Siei col Plankontexts Retrieve refinement from PDW 7 Linef Groupwit DIS EB I z F lbereich _ _ tandard Jd z2 Kr al gt A RE te f DY auticiuns des Pix Refine extruder cessDeviceWithDecision E os POPP PTT To n nA Erpat etuder ioio More 3 im Flie bildeditor al Integrate group into Aspen Plus l Write back simulation results Simulate this group ee oe Reaction t Separation Extruder Fibers Filers 1 In dem betrachteten Beispielszenario hat der Verfahrensingenieur die Aufgabe den WT Prozessschritt Separation durch eine apparatetechnische Realisierung weiter zu verfeinern Dazu selektiert er den VT Prozessschritt und ruft im Men Prozessanleitung das Kommando Verfeinere mit dokumentierter Entschei dung auf Diese Auswahl entspricht dem oben definierten Plankontext RefineProcess DeviceWithDecision der nun im Flie bildwerkzeug verf gbar Der Con textMatcher des Flie bildwerkzeugs bzw des Prozessintegrations Wrappers gleicht die Auswahl mit den Kontextdefinitionen im Umgebungsmodell ab und aktiviert den Plankontext Die Prozessmaschine allokiert daraufhin die ben tigten Werkzeuge und startet die Ausf hrung des Plankontexts RefineProcessDevice WithD
585. warekomponenten die wir von Fremdherstellern beziehen Mithilfe von Adapterklassen abstrahieren wir von den Schnittstellen spezifischer Datenbankmodelle und produkte GUI Bibliotheken und Kommunikationsmechanismen wodurch wir gleichzeitig die Portabilit t des Frameworks auf eine andere Systemplatt formen sicher stellen O Stabilitat An Framework Komponenten sind besondere Anforderungen hinsichtlich weitgehender Fehlerfreiheit und Stabilit t zu stellen da diese das R ckgrat einer ganzen Familie von Anwendungen darstellen und kritische Funkti onsbausteine realisieren In der Basisschicht des GARPIT und des GAR PEM Frameworks haben wir daher Mechanismen des Vertragsmodells nach Meyer Design by Contract Meye97 verankert die durchg ngig im ge samten Framework verwendet werden Im Laufe der Entwicklung and Anwendung des Framework konnten wir so sehr schnell Verletzungen von Vor und Nachbedingungen im Framework sowie in den erstellten Werk zeugen aufsp ren und beheben Dar ber hinaus tragen die spezifizierten Vor und Nachbedingungen zu einer zus tzlichen Dokumentation der Framework Klassen und deren Methoden bei Q Performanz Die Forderung nach Performanz steht h ufig im Konflikt zu den bisher genannten Zielen da interpretative Mechanismen und die Bildung von Abstraktionsschichten und Indirektionen die Komponenten voneinander entkoppeln sollen leicht zu inakzeptablen Antwortzeiten f hren so dass bisweilen Kompromisse au
586. wegen ihrer Allgegenw rtigkeit oft gar nicht als solche wahrgenommene Form der Kommunikation zwischen Softwarekomponenten stellen Prozeduraufrufe dar Hierbei wird ein Werkzeugdienst als einzelne Prozedur aufgefasst welche von anderen Werkzeugen oder Umgebungsdiensten aufgerufen werden kann Dies setzt allerdings voraus dass die gesamte Umgebung durch einen Betriebssystemprozess realisiert wird was jedoch leicht zu monolithischen Softwarearchitekturen f hrt die auch unter Performanz Gesichtspunkten schnell an ihre Grenzen sto en Die Verwendung entfernter Prozeduraufrufe Remote Procedure Call RPC Schi92a Schi92b erm glicht auch Aufrufbeziehungen ber Betriebssystemprozessgrenzen hinweg so dass eine Entwurfsumgebung aus unab h ngigen in einem Netzwerk verteilten Werkzeugen gebildet werden kann Die Basis hierf r stellen Middleware Infrastrukturen wie Sun RPC oder DCE RPC Schi93 bereit Diese Infrastrukturen zielen vor allem syntaktische und semanti sche Gleichbehandlung lokaler und entfernter Prozeduraufrufe ab mit Ausnahme Zeiger wertiger Parameter die normalerweise bei entfernten Aufrufen nicht er laubt sind da sie ein tiefes Kopieren deep copy von Speicherstrukturen auf den entfernten Rechner bedingen w rden Als Grundproblem erweist sich jedoch bei Remote Procedure Calls 3 3 Integrationsanforderungen in prozessintegrierten Umgebungen 73 lokalen ebenso wie bei entfernten Prozeduraufrufen die mangelnde Transparen
587. werden F r jeden Zustand und Zustands bergang existiert ein Nachrichtentyp der inner halb des Rahmenwerkes versandt wird Dabei werden zustandsbasierte Ausf h rungsinformationen im Rahmenwerk offengelegt so dass ein spezialisierter Pro zesssprachen Interpreter ein sprachspezifisches Verhalten realisieren kann Bislang wurde innerhalb des GARPEM Frameworks Interpreter f r SLANG Netze und UML Statecharts integriert Der Wiederverwendungsgrad betrug dabei 85 bzw 87 Au erdem gelang es eine fr here Version der Prozessmaschine in der Prozessfragmente als C Methoden formuliert wurden nahtlos in das GARPEM Framework zu integrieren 7 6 Fazit Gegenstand dieses Kapitels war die PRIME Architektur f r prozessintegrierte Werkzeug Umgebungen PRIME setzt die in Kapitel 5 und 6 dargestellten Kon zepte zur integrierten Werkzeug und Prozessmodellierung in Form zweier generi scher objektorientierter Frameworks um In der Durchf hrungsdom ne definiert das GARPIT Framework die Grundstruktur eines prozessintegrierten Werkzeugs Es stellt vorgefertigte Komponenten zur Synchronisation mit der Leitdom ne und zur Interpretation des Umgebungsmodells bereit und erlaubt die flexible Erweite rung um spezifische Werkzeugfunktionalit ten F r die Integration existierender Werkzeuge wurde das GARPIT Framework zu einem generischen Prozessintegra tions Wrapper modifiziert und anhand der Integration von insgesamt drei Fremd werkzeugen validiert I
588. werden z B die Kategorie des Bausteintyps VI Pro cessStep UnitOperation VI ProcessEquipment den Namen das Darstellungs element und eine Liste von Attributbeschreibungen In der aktuellen Implementie rung wurden lediglich getypte Name Wert Paare zur Attributierung von VI Pro cessDevice Subklassen realisiert Ein sehr viel weitergehendes Konzept zur dyna mischen Attributverwaltung wurde in Baum00 entwickelt jedoch aus Aufwands gr nden nicht innerhalb der PRIME IMPROVE Umgebung verwirklicht wurde Hinsichtlich der Verfeinerungsvertr glichkeit zwischen Bausteinen bzw Bau steingruppen sind nur elementare Konsistenzbedingungen im Flie bild Datenmo dell hinterlegt z B dass eine UnitOperation als atomarer Funktionsbaustein nicht weiter dekomponiert sondern nur durch Instanzen von VT ProcessEquipment reali siert werden kann Weitergehende Unterst tzung erh lt der Verfahrensingenieur durch M Prozessfragmente die die systematische Generierung von Verfahrensal ternativen und deren Analyse und Simulation anleiten Das Wissen welche Verfei nerungs Prozessfragmente anwendbar sind ist nicht im Flie bild Datenmodell selbst verankert sondern wird in einem so genannten Process Data Warehouse PDW verwaltet WeBa99 Das Process Data Warehouse aggregiert Informatio nen aus dem Flie bildmodell mit Daten aus anderen Werkzeugen Simulatoren Stoffdatenbanken und realisiert so eine erweiterte zweistufige Situationsanalyse funktiona
589. werden alle Aktivit ten in denen das Werkzeug verwendet wird F r jede Aktivit t ist hier die Angabe eines spezifischen Envelopes mit jeweils eigenen Parameterlisten m glich lt tool name gt superclass TOOL path string architecture sun4 solaris host i ustrang instances integer multi flag Uni Queue Multi Queue Uni NoQueue Multi NoQueue lt activity name gt string lt envelope name gt lt parameters locks gt lt activity name gt string lt envelope name gt lt parameters locks gt end r Dar ber hinaus wird der Aufruf und die Interaktion mit einem Werkzeug durch eine Reihe von zus tzlichen Attributen genauer charakterisiert Die Attribute architecture host und path geben an unter welchen Betriebsystemen das Werk zeug bzw der Envelope l uft auf welchem Netzwerkknoten es gestartet werden soll und unter welchem Netzwerkpfad das Executable zu finden ist Mit dem Attribut instances l sst sich die maximale Anzahl gleichzeitig laufender Werk zeuginstanzen auf einen bestimmten Wert begrenzen etwa aufgrund einer be schr nkten Anzahl von Lizenzen oder um bei ressourcenintensiven Werkzeug eine Uberlast zu verhindern Am interessantesten ist das multi flag Attribut das das Kreuzprodukt aus zwei orthogonalen Dimensionen annehmen kann Uni Queue Uni NoQueue Multi Queue Multi NoQueue Uni zeigt an dass eine Werkzeugin stanz nur von einem Benutzer verwendet werde
590. werkzeugen also der Durchf hrungs dom ne selbst wieder ber Mechanismen der brigen Integrationsdimensionen verbunden sind Prozessintegration ist also f r Wasserman nichts anderes als die Erweiterung einer traditionellen produktorientierten Entwicklungsumgebung zu einer prozesszentrierten Umgebung Dar ber hinaus gibt er keine konkreten Hin weise welche spezifischen Anforderung an die zu integrierenden Entwicklungs werkzeuge bzw an die zugrunde liegenden Integrationsmechanismen zu stellen sind hnlich vage bleiben Thomas und Nejmeh ThNe92 die Prozessintegration dahingehend definieren dass Werkzeuge effektiv zur Unterst tzung eines defi nierten Prozesses interagieren sollen und zwar hinsichtlich der Prozessschritte ereignisse und einschr nkungen die sich aus einer Definition des Prozesses ergeben In der Terminologie von Bro 94 steuert kontrolliert und adaptiert die Pro zessebene Modellierungs und Leitdom ne die Dienste der Benutzerebene Durchf hrungsdom ne unter Verwendung von Basismechanismen und Integra tionstechnologien die sich wieder den Dimensionen Daten Kontroll und Pr sentationsintegration zuordnen lassen Wichtig erscheint uns hier dass Brown et al den Charakter von Prozessintegration als einem Adaptabilititsproblem hervorhe ben Es reicht also nicht aus Werkzeuge in einen einmal definierten Prozess einzu binden Dies k nnte auch durch hartkodierte Integrationsbeziehungen erreich
591. wird dabei mit der ID der betreffenden Werkzeugkategorie paramettiert so dass nur die f r ein Werkzeug relevanten Kontextdefinitionen in den ContextCache geladen werden Relevant f r ein Werkzeug sind alle Ausf hrungskontexte und Entschei dungskontexte inklusive Situationen und Intentionen die im Umgebungsmodell der betreffenden Werkzeugkategorie direkt zugeordnet wurden sowie alle Kon texte die im Umgebungsmodell als Alternativen eines werkzeugeigenen Entschei 208 Abb 53 Klassenstruktur des Teilsystems ContextMa nager ContextExecutor Steuerung der Kontextausftihrung 7 Das PRIME Rahmenwerk dungskontexts definiert wurden Die Klassen CcxtContextExecutor und CcxtCon textMatcher schlagen Kontextinformationen im ContextCache nach und vermei den so st ndige Anfragen an das Prozess Repository CextContextCache CcxtContextExecutor CcxtContextMatcher Init ToolCategory executeChoiceContext matchSituation gory executeExecutableContext matchintention CextIntDesc CcxtContextDesc CextSitDesc BSP CmapObjectTable CmaplintentionTable CmapAction able T_GUI T_Actions ContextExecutor Die Klasse CcxtContextExecutor realisiert die eigentliche Steuerung der prozess modellkonformen Kontextausf hrung Der ContextExecutor wird vom StateMa nager au
592. wirklicht werden Hierbei passen sich die Interaktionsm glichkeiten in einem Werkzeug dynamisch dem aktuellen Zustand der Prozessmodellausf h rung an Dies bedeutet dass in der Werkzeugoberfl che der Zugriff auf die f r den aktuellen Prozesskontext irrelevante Funktionen und Objekte eingeschr nkt wird z B durch Ausblenden von Men punkten oder durch Deaktivieren der Selektier barkeit von Objekten Weiterhin sollte das Werkzeug in der Lage sein Objekte auf die sich ein aktuell von der Leitdom ne angeforderten Prozessschritt bezieht visuell hervorzuheben um die Aufmerksamkeit des Benutzers auf diese Objekte zu lenken Die Realisierung eines prozesssensitiven Interaktionsparadigmas leistet einen wichtigen Beitrag zur Vermeidung von Abweichungen und Inkonsistenzen zwi schen den Prozessdom nen und steht somit in engem Zusammenhang mit der Synchronisation zwischen den Prozessdom nen siehe auch Abschnitt 3 3 5 Da dem Benutzer standardm ig nur die gem Prozessmodell und aktuellem Aus f hrungszustand g ltigen Funktionen und Objekte zur Auswahl angeboten re flektiert das Verhalten der Werkzeuge stets den aktuellen Zustand der Leitdom ne wider Die prozesssensitive Anpassung der Werkzeugoberfl chen verk rpert also den Synchronisationsschritt von der Leitdom ne zur Durchf hrungsdom ne im Gegensatz zur den im vorigen Abschnitt betrachteten R ckmeldungen aus der Durchf hrungsdom ne zur Leitdom ne und vermindert somit die Ge
593. wischen den Prozessdom nen fest W hrend Ausf hrungs und Entscheidungskontexte von den Werkzeugen der Durchf hrungsdom ne realisiert werden erfolgt in der Leitdom ne die Interpreta tion von Plankontexten Die freie Kombinierbarkeit der drei Kontextarten durch Entscheidungskontexte mittels der Alternative Assoziation und Plankontexte mittels der hat Subkontext Assoziation erfordert zur Laufzeit eine Interaktion zwischen den Dom nen In diesem Abschnitt definieren wir ein Interaktionsprotokoll zwischen der Durchf hrungs und der Leitdom ne das die wechselseitige Inan spruchnahme von Ausf hrungsdiensten und die Versorgung mit R ckmeldein formation regelt Das Interaktionsprotokoll stellt insbesondere die Synchronisation zwischen den Prozessdom nen sicher d h es sorgt daf r dass die Interaktions partner jeweils korrekt auf ankommende Nachrichten reagieren ihrerseits Nach richten zum richtigen Zeitpunkt verschicken und somit insgesamt ihre Zust nde aufeinander abgleichen Zur Spezifikation des Interaktionsprotokolls verwenden wir UML Zustands diagramme Bo R99 Diese Modellierungstechnik basiert auf den von Harel einge f hrten Verallgemeinerungen der Konzepte von endlichen Automaten nach Moo re und Mealy Hare87 UML Zustandsdiagramme fokussieren zwar eigentlich auf einzelne Objekte und dienen der Charakterisierung des Intra Objektverhaltens F r unsere Zwecke definieren wir jedoch zwei Zustandsdiagramme je eins f r di
594. wurfsprozessen f hren Macht man sich diese noch sehr allgemeine Definition zu eigen kann man freilich auch die traditionellen produktorientierten Komponenten einer Entwurfsumgebung d h CASE Editoren Fugg93 Nils89 FoNo92 Transformations und Integrationswerkzeuge Lefe95 Nagl96 Entwurfsrepositorien BeDa94 Tann94 Ortn99 HaLe93 IRDS90 26 2 Prozessorientierte Unterstutzungsfunktionen NiJa99 Konfigurations und Versionsmanagementsysteme Katz90 CoWe98 Kommunikationsmechanismen Reis90 OMG 97 Schi93 OrHE96 und andere Infrastrukturkomponenten zur Prozessunterst tzung innerhalb einer Entwurfs umgebung hinzurechnen da die blo e Verf gbarkeit solcher Dienste bereits einen erheblichen Einfluss auf Softwareentwicklungsprozesse hat JaBR99 So w ren beispielsweise Anforderungsdefinitionsprozesse in denen Anforderungsspezifika tionen mit nicht selten Hunderten von grafischen Modellen entstehen ohne Zuhilfenahme moderner CASE Werkzeuge Entwurfsrepositorien sowie Konfigu rations und Versionsmanagementwerkzeuge zur Verwaltung der entstehenden Entwurfsdaten schlichtweg undenkbar Wir wollen uns im Folgenden aber auf solche Unterst tzungskonzepte kon zentrieren die ber die reine Produkterstellung und verwaltung die ja immer Teil der Prozessunterst tzung ist hinausgehen und den Prozessaspekt besonders betonen Dazu z hlen wir insbesondere die effektive Kommunikation von Wissen ber erprobte und anzuwendende V
595. xt Knoten k nnen zu Hypertext Sichten zusammengefasst werden Der Hypertext Editor stellt grundlegende Funktionali t ten zur Edierung von Hypertext Dokumenten und deren Strukturierung in Knoten und Sichten bereit Innerhalb des dem Hypertext Editor zugrunde liegen den Produktmodells k nnen komplette Hypertext Dokumente ebenso wie Sichten oder einzelne Knoten als individuelle Produkte referenziert werden Einzelheiten zu den formalen Grundlagen des verwendeten Hypertextmodells sowie zum Hy pertext Editor selbst k nnen PoHa95 Pohl96 entnommen werden Entscheidungseditor Der Entscheidungseditor dient der strukturierten Erfassung und Darstellung von Entwurfsentscheidungen und Begr ndungshistorien siehe Abb 35 oben rechts 171 172 Abb 35 Die prozessintegrierten PRIME Werkzeuge Hypertext Editor Ent scheidungs Editor und Abh ngigkeits Editor Laufzeit Umgebung f r die Ausf hrung ver schiedensprachlicher Prozessfragmente 7 Das PRIME Rahmenwerk Angelehnt an das IBIS Modell Issue Based Information Systems CoBe88 lassen sich im Entscheidungseditor einer Problemstellung issue eine oder mehrere L sungsvorschl ge positions zuordnen die mithilfe von Pro und Kontra Argumenten diskutiert werden Durch Auswahl eines L sungsvorschlags wird die Problemstel lung einer Entscheidung decision zugef hrt Da sich die Sach oder Erkenntnislage im Laufe des Entwicklungsprozesses ndern kann erlaubt der Entscheidungse
596. xtern extern integriert Werkzeug 2 extern Prozess Prozess Prozess maschine maschine maschine a Feingranulare Integration b Grobgranulare Referenzierung c Abbildung externer Werkzeugdaten Im Prozess Repository Externer Werkzeugdaten in Prozessrepository Mit Ausnahme einiger weniger datenbankzentrierter Ans tze z B GTSL Em me95 Emme96 wird dieses Idealbild in den meisten prozesszentrierten Umge bungen und Workflow Managementsystemen nicht erreicht Hier steht vielmehr die a posteriori Integration von Fremdwerkzeugen im Vordergrund die ihre Daten in eigenen vom Prozess Repository unabh ngigen Datenspeichern typi scherweise Dateien ablegen Die bliche L sung die z B in SPADE BBFL94 BaDF96 Dynamite HJKW96 HeKW97 Marvel BaKa91 Barg92 Provence BaKr93 u a praktiziert wird besteht darin dass die Werkzeugdaten aus Sicht des Prozess Repositories nur grobgranular auf Dokumentebene modelliert und refe renziert werden siehe Abb 10b Der Inhalt dieser Dokumente ist nur den jewei ligen Werkzeugen zug nglich und kann nicht von der Prozessmaschine bei der Prozessmodellinterpretation ber cksichtigt werden F r eine administrative Sicht weise auf den Entwicklungsprozess reicht dies in der Regel aus Die f r die feingranulare Entwicklerunterst tzung relevanten Daten befinden sich jedoch in der Regel unterhalb der Dokumentebene F r die Prozessunterst tzung zur Spezi fikatio
597. yn C UML 2001 A Standardization Odyssey Communications of the ACM 42 10 S 29 37 Oct 1999 Koch G R Process Assessment The BOOTSTRAP approach Information and Soft ware Technology 35 6 7 S 387 403 1993 Kotteman J und Konsynsky B Information Systems Planning and Development Strategic Postures and Methodologies Journal of Management Information Systems 1 2 S 45 63 1984 Koskimies K und M ssenb ck H Designing a Framework by Stepwise Generalization In Proc of the 5th European Software Engineering Conference Springer Verlag LNCS989 1995 Kr mer B Distributed Object Platforms The CORBA Standard In Kr mer B Papa zoglou M und Schmidt H W Hrsg Information Systems Interoperability Re search Press Studies Taunton Somerset England 1997 S 13 38 Kramer J und Magee J Exposing the Skeleton in the Coordination Closet In Garlan D und Metayer D L Hrsg Proceedings of the 2nd International Conference on Co ordination Languages and Models COORDINATION 97 Berlin Germany 1997 S 18 31 Krob97 Kron92 KrR095 Kruc98 KuWe92 LaBo97 Lamp99 Laur90 LaV 097 Lefe95 Lehm87 Lehm91 LeYo94 LiKS99 Lohm98 Lonc94a Lott93 Luc 95 LyWe99 Lyy 98 MaBF99 MaCr94 Madh91 Literaturverzeichnis 291 Krobb C Entwicklung einer Spezialisierungshierarchie f r Modellierungsschritte im objekt orientiert
598. z der Bindung zwischen den interagierenden Werkzeugen Es lassen sich lediglich 1 1 Interaktionsbeziehungen auf niedrigem Abstraktionsniveau direkt abbilden Hier bei muss das aufrufende Werkzeug den genauen Ort und die Schnittstelle des Diensterbringers kennen so dass durch die entstehenden Abh ngigkeiten eine nachtr gliche Erweiterung oder ein Austausch von Werkzeugdiensten mit hohem Aufwand verbunden ist Zudem ist das Ablaufwissen dass zu einem bestimmten Zeitpunkt der Dienst eines anderen Werkzeugs zu aktivieren ist im aufrufenden Werkzeug kodiert So genannte Multicast RPCs BiJo87 WaZZ93 erlauben zwar 1 n Aufrufbeziehungen d h den gleichzeitigen Aufruf einer Prozedur bei einer Gruppe von Servern die die betreffende Schnittstelle exportieren ndern aber nichts an der grunds tzlichen Tatsache dass Ablaufbeziehungen in den interagie renden Werkzeugen selbst verborgen sind Object Request Broker Der Object Request Broker Ansatz stellt eine objektorientierte Erweiterung des entfernten Prozeduraufrufs dar Werkzeuge werden hier als komplexe Objekte aufgefasst die ber eine definierte Schnittstelle ihre Dienste zur Verf gung stellen Gem dem objektorientierten Paradigma verf gt jedes laufende Werkzeug ber eine eindeutige Objektidentit t und einen eigenen Zustand so dass sich anders als beim entfernten Prozeduraufruf mehrere Instanzen eines Werkzeugs unmittelbar unterscheiden lassen Abb 12 Objekt CORBA Arch
599. ze noch einmal zusammenfassend gegen ber Abschnitt 2 3 1 und definieren darauf aufbauend die wesentlichen Charakte tistika prozessintegrierter Werkzeuge Abschnitt 2 3 2 welche die Vorteile existieren der Ans tze vereinigen sollen 2 3 1 Vergleich der Prozessunterst tzungsans tze Einen nur geringen Beitrag zur Prozessunterst tzung k nnen Methoden und Projekthandb cher leisten da das in ihnen dokumentierte Prozesswissen statisch ist und nicht innerhalb der rechnerbasierten Umgebung kontextsensitiv abgerufen werden kann nderungen der in einem Handbuch fixierten Prozessdefinitionen ziehen einen hohen Aufwand nach sich Dagegen besteht die wesentliche St rke prozesszentrierter Umgebungen in ih rer gerade in kreativen Entwurfsdom nen erforderlichen Flexibilit t hinsichtlich der Definition neuer Prozesse oder der Anpassung von existierenden Prozessen da die von ihnen geleistete Prozessunterst tzung auf expliziten und austauschba ren Prozessmodellen basiert Aufgrund der Ausf hrbarkeit der Modelle durch Prozessmaschinen sind prozesszentrierte Umgebungen in der Lage ein internes Modell des aktuellen Prozesszustands in der Leitdom ne dynamisch fortzuschrei ben und somit die Durchf hrungsdom ne kontextsensitiv zu unterst tzen Von der Assistenzfunktion prozesszentrierter Umgebungen profitiert in existierenden Ans tzen allerdings prim r das Projektmanagement da dort die Unterst tzung administrativer Vorg nge wie Aufgabende
600. zer h ufig gar nicht genau wei nach welchem Hilfethema er suchen soll Zum anderen m ssen die durch das Hilfesystem gelie ferten Handlungsanweisungen erst noch in eine Abfolge von manuell anzusto en den Werkzeugaktionen umgesetzt werden Aus der Forschung ber intelligente Benutzerschnittstellen stammt das Kon Interface Agenten zept der Interface Agenten Maes94 Laur90 welche eine Weiterentwicklung aktiver dynamischer Hilfesysteme darstellen Interface Agenten berwachen laufend das Verhalten eines Benutzers beim Umgang mit einer komplexen Applikation versu chen Probleme selbstst ndig zu erkennen und geben gegebenenfalls Hilfestellung ber eine einfache aufgabenbezogene Schnittstelle In der Praxis werden solche Schnittstellen h ufig Assistenten oder Wizards genannt ein bekanntes Beispiel sind die Microsoft Office Assistenten Micr97 die aus den Erkenntnissen des Lumiere Projekts Hor 98 hervorgegangen sind Microsofts Office Assis tenten Aus Benutzersicht sind Assistenten meist als eine Abfolge von Dialogen reali siert die schrittweise die f r einen Vorgang ben tigten Informationen vom Benut zer erfragen und im zugrunde liegenden Werkzeug entsprechende Aktionen ausl sen Als Beispiel sei der mit Microsoft Access 2000 ausgelieferte Tabellenentwurfs Assistent angef hrt Hier wird der Benutzer durch den Prozess der Erstellung eines Datenbankschemas gef hrt Im ersten Schritt wird dem Benutzer eine Liste von B
601. zessmodells mit der Kontexte als Komponenten sprach bergreifend verwendbar sind 6 3 Komponentenorientierte Darstellung des NA TURE Prozessmodells Ein komponentenbasierter Prozessmodellierungsansatz der die Verwendung von mehreren Prozessmodellmodellierungssprachen und die Komposition eines Pro zessmodells aus verschiedensprachlichen Komponenten erm glicht muss grund s tzlich zwischen dem Definitionspunkt einer Komponente und deren Verwendungs punkten unterscheiden Damit eine Prozesskomponente des Definitionspunkt sprach bergreifend in der Modellierungsdom ne eingesetzt werden kann muss bei deren Verwendung stets eine Repr sentation in der Prozessmodellierungssprache des Verwendungspunkts gefunden werden damit die Prozesskomponente dort syntaktisch referenziert und an den Daten und Kontrollfluss angeschlossen wer den kann Eine sprachneutrale Schnittstellenbeschreibung sowie Transformations regeln f r die Abbildung von Komponentenschnittstellen in die Verwendungs sprachen sind hierf r Voraussetzung siehe Abb 26 Definitionspunkt Verwendungspunkt Abb 26 Prozesssprache A Prozesssprache B Komponen tendefinition und verwendung Ablage einer sprachneutralen Schnittstellenbeschreibung in Komponentensammlung Abschnitt 6 2 Transformation und Bindung der Schnittstelle an sprachspezifische Konzepte Abschnitt 6 3 Komponentensammlung Verwaltung und Suche nach Prozesskomponente 144 6 Interoperabilitat
602. zeuge der PROART Umgebung Im Vergleich zur Vorg ngerumgebung zeichnete sich PRO ART 2 0 die PROART 2 0 Umgebung aus Entwicklersicht durch eine stark gesteigerte Wiederverwendung einen damit verbundenen verminderten Entwicklungsauf wand und eine wesentlich gr ere nderungsfreundlichkeit aus In der Anwen dung machte sich das vereinheitlichte Look and Feel der Werkzeuge in einer stark verbesserten Benutzbarkeit positiv bemerkbar Dar ber hinaus war eine signifikant h here Stabilit t und Performanz der Umgebung zu beobachten Dies war darauf zur ckzuf hren dass kritische Komponenten nicht redundant in allen Werkzeuge jeweils spezifisch implementiert wurden sondern als allgemein ver wendbare Framework Komponenten mit besonderer Sorgfalt entworfen realisiert und getestet wurden Basierend auf den Erfahrungen mit der PRO ART 2 0 Entwicklung wurde in der n chsten Iterationsstufe des PRIME Frameworks Version 1 5 der Schwer 3 3 x PRIME 1 5 punkt zun chst auf eine bessere Unterst tzung der Prozess und Werkzeugmodel Erweiterung um Meta lierung durch benutzerfreundliche Metamodellierungswerkzeuge gelegt Zudem modellierungswerk wurde das PRIME Framework von Unix Solaris auf die Windows NT Plattform Zeuge Portierung auf portiert um eine Anbindung an das GUI Framework MFC Microsoft Foundation u 2 en 9 Classes zu erm glichen Dies geschah prim r in Hinblick auf die im Rahmen des nenten EU Projekts CREWS zu entwick
603. zeuge entgegen Diese Art der Interaktion ist f r den Benutzer insbesondere bei feingra nularen Prozessen sehr m hsam und fehlertr chtig Einige Ans tze wie SPADE und Provence umgehen dieses Problem indem sie aus direkt oder indirekt von den Werkzeugen ausgel sten Ereignissen R ckschl sse auf die Prozessdurchf h rung zu ziehen versuchen Diese L sung bewegt sich jedoch auf logisch niedrigem Niveau Au erdem gilt auch hier dass die Interaktion zwischen der Prozessma schine und den Werkzeugen keinem geregelten Protokoll folgt 3 3 6 Prozesssensitive Benutzeroberfl chen 3 3 6 1 Motivation Bei der Beurteilung der Pr sentationsintegration werden blicherweise zwei As pekte unterschieden das visuelle Erscheinungsbild und Verhalten der Werkzeuge sowie die verwendeten Interaktionsparadigmen ThNe92 Sche93 Die Uniformit t des visuellen Erscheinungsbilds f ngt bei der Gestaltung von Grundelementen der grafischen Benutzeroberfl che an Dazu geh ren z B ein heitliche Fensterrahmen Schaltfl chen Auswahllisten etc Von einer pr sentati onsintegrierten Umgebung wird man weiterhin erwarten dass semantisch ver gleichbare Funktionen unterschiedlicher Werkzeuge konsistent benannt werden z B Speichern vs Sichern identische Parameterlisten erwarten an hnlichen Positionen innerhalb der Men hierarchie angeordnet sind und ber gleiche Tasta turk rzel angesprochen werden k nnen Beispielsweise hat sich eingeb rg
604. zustand wird als gerichteter azyklischer Graph repr sentiert in dem Akti vit ten durch Konten dargestellt werden die durch Pr zedenz oder Subaktivit ts kanten miteinander verbunden sind Im Gegensatz zur statischen Repr sentation eines Prozessfragments spiegelt der Graph jedoch den Ausf hrungszustand eines virtuellen ber mehrere Prozessmaschinen verteilten globalen Prozessmodells zur Laufzeit wider Die Modifikation des den Prozesszustand repr sentierenden Graphen erfolgt durch unterschiedliche prozessbasierte Klienten die mit dem Zustandsserver in Verbindung stehen Diese Klienten melden ber einen Nachrichtenmechanismus prozessrelevante Zustands nderungen und k nnen gegebenenfalls selbst auf n derungen reagieren Die Klienten des Zustandsservers werden unterschieden in Prozesskonstruktorklienten Werkzeugklienten und Prozessbeschr nkungsklienten Die Prozesskonstruktorklienten d h die Prozessmaschinen expandieren den Zustandsgraphen indem sie dynamisch Aktivit ten hinzuf gen Die nderung des Graphen wird an interessierte Klienten z B Werkzeuge propagiert so dass diese daraufhin die hinzugef gte Aktivit t wahrnehmen und ausf hren Die erfolgreiche Ausf hrung einer Aktivit t wird wiederum dem Zustandsserver mitgeteilt der dann die Aktivit t aus dem Graphen entfernt Die Prozessbeschr nkungsklienten berwachen den Prozesszustand und greifen gegebenenfalls ein wenn dieser nicht mehr in einem konsistenten Zustand
605. zuvor entwickelte Klassifikationsschema erlaubt eine einfachere Gegen berstellung der einzelnen Ans tze die Identifikation von Schwachstellen heutiger Unterst tzungssysteme sowie die Definition von Merkmalen einer idealtypi schen Prozessunterst tzung durch prozessintegrierte Werkzeuge Abschnitt 2 3 2 1 Ein Klassifikationsmodell f r Prozessunter st tzungsfunktionen Um die in Abschnitt 2 2 vorgestellten Ans tze zur Prozessunterst tzung besser in ein Gesamtspektrum einordnen und den in dieser Arbeit vorgestellten Ansatz 10 2 Prozessorientierte Unterstutzungsfunktionen davon abgrenzen zu k nnen stellen wir in diesem Abschnitt ein einfaches Klassi fikationsschema vor Zur Klassifikation der Unterst tzungsans tze unterscheiden wir folgende f nf Kriterien Merkmale f r O Unterst tzte Projektebene Abschnitt 2 1 1 Adressiert die Prozessun Prozessunterst tzungs terst tzung vornehmlich administrative Planungs und Koordi funktionen nationst tigkeiten des Projektmanagers oder wird die systematisch metho dische Durchf hrung der eigentlichen Entwurfsaufgaben durch den tech nischen Entwickler unterst tzt O Integrationstiefe Abschnitt 2 1 2 Wie eng ist die Prozessunterst tzung mit den brigen Komponenten der rechnerbasierten Entwicklungsumge bung insbesondere den Entwicklungswerkzeugen verschr nkt Q Kontextbezogenheit Abschnitt 2 1 3 Wie pr zise ist die Prozessunter st tzung zum Zeitpunkt der In

Thesis - RWTH Publications

Contents

Download Pdf Manuals

Related Search

Related Contents