Home

Prozessorientierte Integration von Softwarekomponenten durch XML

1. A viewOf javax swing ServiceStateVertexAdapter JComponent p A javax swing 1 JPanel A current AbstractStateComponentView A 0A paintYou graphics Graphics Void ServiceStatePanelView updateView Void ServiceStateComponentView savelnput Void paintYou graphics Graphics Void 1 1 A listensTo listensTo gt 1 1 lt listensTo ServiceStateActionListener StateMouseListener StateMouseMotionListener mousePressed Void mouseDragged Void mouseReleased Void 1 1 Abb 9 15 MVC Klassen f r Service Zust nde Auf der linken Seite der Abbildung sieht man die Klassen die die Eingabemaske eines Service Zustands realisieren Die analogen Klassen f r einen Service wurden bereits im Abschnitt 9 3 2 beschrieben Daneben existiert nun als zweite View Komponente die Klasse ServiceStateComponentView Sie erbt indirekt von der Swing Klasse JComponent die die notwendigen Methoden enth lt um ein grafisch darstellbares Ele ment der Benutzungsoberfl che zu implementieren Die wichtigste Methode von ServiceStateComponentView ist paintYou Sie wird jedes Mal aufgerufen wenn 9 3 Implementierung des Prozesseditors 209 das Swing System feststellt dass der Zustand neu gezeichnet werden muss Als Para meter bekommt sie ein Objekt der Swing Klasse Graphics bergeben die elementare Zeichenfunktionen anbietet um damit
2. ordered N taggedValue referenceTag constraint Constraint TaggedValue Fl from Core dataValue String GeneralizableElement from Core stereotypeConstraint typedvalue xor stereotype type Stereotype 0 1 TagDefiniti constrainedStereotype agDetinition 1 icon Geometry owner definedTa tagType Name baseClass Name mulitplicity Multiplicity Abb 7 2 Erweiterungsmechanismen der UML aus Omg01 2 6 2 7 2 1 Stereotypen Das wohl wichtigste Konstrukt zur Spracherweiterung sind die Stereotypen Omg01 2 6 3 2 Mit ihnen lassen sich neue virtuelle Metaklassen mit eigenen Attributen und Semantiken definieren und dem erweiterten Metamodell hinzuf gen vgl Alh99 S 12f Auf der Modell Ebene k nnen die so definierten Stereotypen zur Klassifizierung der Elemente benutzt werden Aus diesem Grund sind auch Namenskonflikte mit ande ren Elementen der Klassifizierungshierarchie nicht erlaubt Jedes Stereotyp basiert auf einem schon existierenden im Metamodell wohldefinierten Element der sogenannten Basisklasse Von diesem Basiselement erbt das Stereotyp gleichsam alle Attribute Operationen und Assoziationen Allerdings kann es diese um weitere Attribute Tag Definitions semantische Bedingungen Constraints und optional um eine neue grafi sche Darstellung erg nzen Jedes Element der Modellebene das mit einem Stereotyp
3. une 161 8 2 Vorhandene XML Formate f r Prozessmodelle nne 164 8 2 1 Beschreibung von Prozessen mit XLANG ursnrsnnesnsernenennnen nen 164 8 2 2 Der XML Metadata Interchange Standard XMD e 166 8 2 3 Bewertungs Eau 170 8 3 Process Markup Language PML esse 172 8 3 1 Beschreibung von P rts cn a see 172 8 3 2 Beschreibung des statischen Modells 2200022400ssssnennennnnnn 176 8 3 3 Beschreibung von Prozessen usuustsnentindehlulssns 179 8 3 4 BEWERTE re 186 8 4 Werkzeuge f r die PML Verarbeitung 2202204022ssenseneensnneennnennnnn 187 8 4 1 PML Imp rler u 0usensuninkkan enge Ai E EA 187 8 4 2 PM ExPoter essen e a a Eae 188 9 Modellierungswerkzeug f r Prozessdiagramme sessooesoocssocsssecssocesocesocessse 191 9 1 Der Proz ss dit r Ana nei a A a E T E 191 9 2 Bedienung des Prozesseditors uueseieeeenentniinin sa 192 9 2 1 Verwaltung in Projekten 22a 193 9 2 2 Ansicht des Projektbaums 2 22 u Ba 193 9 2 3 Ei ngabemasken runs sans ann 195 9 2 4 Eingabe von Porn uns are 196 9 2 5 Konstruieren eines Prozesses ns Eee 197 9 3 Implementierung des Prozessedit rs 2er 205 9 3 1 Klass AppFraMe ut ienee ee a o 205 9 3 2 Anwendung des Model View Controller Konzepts eeeseeseeecesreereee 206 9 3 3 Die Prozesszeichenfl che narn aia n i NE aiaa S 208 4 Inhaltsverzeichnis 10 Ausf hrung von XML Prozessen
4. si E x1 s3 x1 gt x2 x3 3 x2 s2 XIX S x2 Abb 5 2 Petri Netz mit individuellen Marken Bei einer solchen Konstellation wie in der Abbildung dargestellt k nnte nur die Marke 3 verarbeitet werden da die Transition fordert dass Marke x2 aus Stelle s2 kleiner sein muss als die Marke x1 aus der Stelle s1 in diesem Fall 4 F r die Marke 5 trifft diese Bedingung nicht zu Wenn die Transition schaltet w rden die Marken 3 und 5 aus ihren Stellen entfernt und stattdessen eine Marke mit dem Wert 3 in der Stelle s3 erzeugt da die Transition festlegt dass die Marke x3 den Wert von x2 erh lt Eine zweite wichtige Erweiterung stellt die Modellierung von zeitlichem Ver halten dar Klassische Petri Netze gehen davon aus dass eine Transition schaltet sobald sie aktiviert ist und dass die Ausf hrung des Schaltvorgangs keine Zeit in Anspruch nimmt Solche Bedingungen sind in der Praxis so gut wie nie erf llt Vielmehr muss man spezifizieren k nnen dass Marken sich eine bestimmte Zeit lang in einer Stelle aufhalten bevor sie diese verlassen oder dass eine Aktion also das Schalten einer Transition eine gewisse Zeit dauert Auch Aussagen wie Wenn eine Marke sich eine bestimmte Zeit lang in einer Stelle befindet ohne von den zust ndigen Transitionen bearbeitet worden zu sein schaltet eine spezielle Transition und lenkt die Marke auf einen anderen Weg sind denkbar und m ssen modellierbar se
5. 17 2 3 2 Vorgangsmodellierung und dynamische Modelle u u 18 2 3 3 Analyse und Simulation der Modelle uuur2uurs0nrsnnennnnessnersnneennen 18 2 4 Unterst tzung durch Software 2 2u 2uu 22a ee 19 Anforder ungsanalyse u eies insg een aneen Fresse rege 23 3 1 Fallstudie E Business Plattform eines gro en Finanzunternehmens 23 3 1 1 P ojekt iel s eisie e E E R 23 3 1 2 Anforderungen ua 24 3 1 3 Architekturvorschlag esse ea 26 3 2 Anforderungen an Workflow Systeme im E Business eeeeceseeeeeeeeeeeree 28 3 3 Anforderungen an Workflow Modellierungssprachen u ee 31 3 4 Zielsetzungen dieser Arbeit 33 Evaluierung vorhandener Workflow Systeme ssesssecssocesoocsooesssecssocesocesooseso 35 4 1 Microsoft BizTalk Server 2000 essseeseseseeseesrssreeseessrserssresseseresresseseresees 35 4 1 1 Systemarchitektur von BizTalk Server 2000 uu222002200r ser snneenneennnenen 37 4 1 2 Komponentenintegration mit BizTalk Server 2000 u uur sun 38 4 1 3 Workflow Modellierung mit BizTalk Server 2000 2202200 0 38 4 1 4 Workflow Ausf hrung mit BizTalk Server 2000 220r nenn 39 4 2 Komponentenkonfiguration mit WARP eesesessesesesseseesresresrreseessesrrssresseesr 40 4 2 1 Systemarchitektur von WARP ssseessessessessesseseresresseserssressessresresseesresres 40 4 2 2 Komponentenintegration mit WARP s esssseseseesessrseresres
6. 0000000000000000000000000000000000000000000000 237 11 1 Vergleich der L sungsans tze 2 2 2 ui 237 11 2 Erf llung der Anforderungen uuusanaeensuuessinsatisenn es 243 12 Schl ssbetrachtungen ae Eee 245 121 Ausa A aS T nasse 245 122 Alsblieck sangen e ae a a aS R Eira ees 250 Literatur und Quellen sseoeessesecsscsecsesscceesssocecssccecsscseceessececssccecsseccecsssoeceesseceesseseesse 255 1 Einleitung Ein Blick in die Historie des Internets zeigt dass wir uns am Beginn einer neuen Peri ode befinden Bislang war das Internet von der Kommunikations ra gepr gt vgl Mic00 S 2 der ersten ra der Internetgeschichte Sie legte den Grundstein f r die beraus erfolgreiche Verbreitung der Internetkommunikation durch die Schaffung ent sprechender Infrastrukturen und einheitlicher Protokolle die auf offenen Standards basieren Dies war der erste notwendige Schritt zur Etablierung der elektronischen Gesch ftsabwicklung E Business Doch diese Infrastruktur allein gen gte noch nicht zur Umsetzung vollst ndiger elektronischer Gesch ftsbeziehungen Vielmehr waren zun chst E Mail Kommunikation und Datenpr sentation auf Websites die haupts ch liche Anwendung der neuen Kommunikationsinfrastruktur Dies er ffnete den Benut zern in den ersten Jahren eine neue und bisher nicht da gewesene M glichkeit zum Informationsaustausch Aber die neuen Technologien erreichten schnell auch ihre Gren zen Die Beschreibungsspra
7. self incoming gt isEmpty and self outgoing gt size 1 OCL Mengenoperationen Der vordefinierte Datentyp Collection bietet eine Reihe von Operationen um auf die Elemente der Menge oder Liste zuzugreifen Die wich tigsten und sp ter benutzten Mengenoperationen sollen in der nachstehenden Tabelle kurz vorgestellt werden vgl Omg01 6 8 2 1 7 1 Das UML Metamodell 125 size Integer Liefert die Anzahl der Element in der Collection isEmpty Boolean Liefert true wenn die Collection leer ist exists expr OclExpression Boolean Liefert true wenn es in der Collection wenigs tens ein Element gibt f r das der angegebene Ausdruck wahr wird one expr OclExpression Boolean Liefert true wenn es in der Collection genau ein Element gibt f r das der angegebene Ausdruck wahr wird select expr OclExpression Set Liefert die Teilmenge der Elemente aus Collection f r die der angegebene Ausdruck wahr wird forAll expr OclExpression Boolean Liefert true wenn der angegebene Ausdruck f r alle Elemente der Colleciton wahr wird includes object OclAny Boolean Liefert true wenn object in der Collection ent halten ist includesAll c2 Collection Boolean Liefert true wenn alle Elemente aus c2 in der Collection enthalten sind Tab 7 1 OCL Mengenoperationen Definition von Variablen und Funktionen Um OCL Ausdr cke bersichtlicher zu ges
8. Pr zise Eindeutige Semantik O 1 Bisher nicht gefordert aber im Rahmen von Werkzeugunterst tzung leicht sicherzustellen 2 Nicht implizit vorgesehen aber mit vorhandenen Mitteln realisierbar 3 Mit Hilfe von UML Klassendiagrammen erf llt nicht erf llt o teilweise erf llt Tab 5 3 Bewertung vorhandener Workflow Modellierungssprachen 72 Kapitel 5 Evaluierung vorhandener Workflow Modellierungssprachen Zun chst scheint es dass sich Petri Netze aufgrund ihrer exakt definierten Semantik zur Modellierung und Ausf hrung von XML Prozessen eignen Es ergeben sich jedoch einige Nachteile die gegen ihre Verwendung sprechen Petri Netze neigen dazu schnell komplex und un bersichtlich zu werden siehe B h95 S 12 Das liegt zum einen daran dass jeder Zustands bergang durch einen eigenen Knoten Transition und min destens zwei Kanten dargestellt wird Damit besitzen die Netze etwa doppelt so viele Knoten wie Diagramme vergleichbarer Modellierungssprachen die lediglich eine gerichtete Kante als Zustands bergang verwenden Zum anderen f hren Erweiterungen der klassischen Petri Netze h ufig zu textuellen Erg nzungen oder Anmerkungen inner halb der grafischen Darstellung siehe Wen00 S 39 Sowohl die gro e Anzahl an Knoten als auch textuelle Beschriftungen widersprechen dem Ziel der leichten Ver st ndlichkeit und Lesbarkeit der Modelle Weiterhin ergeben sich bei XML Prozessen spezielle Anforderungen wie
9. 4 5 bh I ic 9 4 Service S bt d k N 74 Er nt z N S S RO en Prozessdiagramm ps amp t2 Es gilt En a ca b cc ccodcd ceficf IN Offener Port N gt durch das statische Modell definierter bergang Abb 6 23 Bindung offener Ports im Prozessdiagramm Die Identit ts Transition Standardm ig sei ein Transitionstyp vorgegeben der benutzt werden kann wenn Quell und Zielport der Transition zueinander kompatibel sind und keine Anpassungs transformation durchgef hrt werden muss Solche Transitionen werden dentit ts Transition genannt und mit dem Schl sselwort idle engl leerlaufend unt tig gekennzeichnet weil sie das Migrationsdokument ohne jede Ver nderungen an den Zielport weiterreichen Der Identit tstyp hat als Eingangsport den Platzhalter any als Ausgangsport die Platzhalter copyRoot und copySubs offener Port au erdem kein Stylesheet bzw als Transformationsfunktion die mathematische Identit tsfunktion die jedes Dokument auf sich selbst abbildet Identit t Bere Ne s4 gt copyRoot copySubs Transitiontyp idle any N gt Abb 6 24 Der Typ der Identit ts Transition Einbindung in Prozessdiagramme Wie schon erw hnt stellen die Transitionstypen neben den Services und Konnektoren einen weiteren Bestandteil des statischen Modells dar ber einen eindeutigen Namen der zudem durch eine Package Hierarchie gegliedert sein kan
10. Eine Stelle s hei t Eingangsstelle einer Transition t wenn es eine gerichtete Kante von s nach t gibt Analog dazu handelt es sich um eine Ausgangsstelle wenn eine Kante in der umgekehrten Richtung also von t nach s existiert Um die Dynamik von Petri Netzen zu beschreiben werden sogenannte Marken verwendet Jede Stelle eines Netzes enth lt zu jeder Zeit keine eine oder mehrere Mar ken Diese werden grafisch durch schwarze Punkte innerhalb der Stelle dargestellt Eine Transition gilt dann als aktiviert wenn jede ihrer Eingangsstellen mindestens eine Marke enth lt Jede aktivierte Transition kann schalten In diesem Fall wird aus jeder ihrer Eingangsstellen genau eine Marke entfernt und in jeder Ausgangsstelle je eine neue Marke erzeugt Die folgende Abbildung zeigt ein einfaches Petri Netz vor und nach dem Schaltvorgang der Transition t2 52 Kapitel 5 Evaluierung vorhandener Workflow Modellierungssprachen e Q Abb 5 1 Petri Netz vor und nach einem Schaltvorgang Mit Hilfe dieser klassischen Form von Petri Netzen lassen sich zwar bereits einfache Prozesse modellieren es fehlen jedoch m chtigere Sprachkonstrukte um die Semantik eines Modells verfeinern zu k nnen Aus diesem Grund gibt es viele Ans tze zur Erweiterung von Petri Netzen die je nach Einsatzgebiet zus tzliche Sprachelemente definieren Solche speziellen Varianten von Petri Netzen werden unter dem Begriff High Level Petri Netze zusammengefasst Im folgenden A
11. 1 am r Al amp Abb 9 10 Eingabemaske eines Service Zustands Zu beachten ist dass nach dem Bet tigen der Schaltfl chen f r Service und Subaktivi t tszustand nicht unmittelbar die grafischen Elemente in das Prozessdiagramm einge 202 Kapitel 9 Modellierungswerkzeug f r Prozessdiagramme f gt werden Zuvor erscheint jeweils ein modaler Dialog in dem der gew nschte Service bzw Subprozess ausgew hlt werden muss F r Service Zust nde existiert eine weitere Besonderheit Beim Erzeugen eines solchen Zustands werden zun chst die Ports des Service aus dem statischen Modell bernommen Der Modellierer kann jedoch in der Eingabemaske die Ports manuell anpassen wenn er zum Zeitpunkt der Prozessmodellierung mehr Informationen ber die Dokumentstrukturen besitzt als bei der Definition des statischen Modells vgl Ab schnitt 6 3 1 Einbindung von Ports in Prozessdiagramme Zu beachten ist dabei jedoch dass die Teilportbedingungen aus 6 3 1 nicht verletzt werden d rfen Der Editor gibt in diesem Fall eine Fehlermeldung aus Hinzuf gen von Transitionen Zust nde die nach dem weiter oben beschriebenen Verfahren angelegt wurden m ssen mit Hilfe von Transitionen mit dem restlichen Prozessdiagramm verbunden werden damit das Diagramm einen Sinn ergibt Da eine Transition immer genau zwei Zust nde verbindet m ssen auch in der Zeichenfl che zwei Zust nde selektiert werden um sie zu verbinden Zun chst muss durch Dr
12. 2 2 Prozesse in einem Unternehmen 15 Verantwortung f r die Aufrechterhaltung der Konsistenz von Daten und Prozessablauf Die meist hochautomatisierten Prozesse enthalten statt Aufgaben die einem Mitarbeiter zugeordnet werden Aktivit ten die von Softwarekomponenten ausgef hrt werden Die ausf hrende Instanz also das WFMS kontrolliert die Software Aktionen bei gar keiner oder nur gelegentlicher Benutzer Intervention und muss die Abarbeitung des Workflows gem der zugeh rigen Workflow Modelle und Definitionen gew hrleisten vgl Geo95 S 128 Transaktionale Workflows Wird gefordert dass die Workflows Transaktionseigenschaften wie Atomarit t Kon sistenz Isolation und Dauerhaftigkeit ACID Eigenschaften siehe Bac98 S 440 erf llen sollen spricht man von transaktionalen Workflows Die bekannten ACID Eigenschaften k nnen in der Regel nur bei systemorientierten Workflows eingefordert werden Bei Gesch ftsprozessen auf h herer Ebene die oft viel langlebiger sind kann es zu einem Spannungsfeld zwischen den Transaktionseigenschaften und den Anfor derungen an das Workflow Management kommen So ist hier die Forderung nach Atomarit t problematisch denn es w re beispielsweise nicht sinnvoll den monate oder jahrelangen Prozess der Entwicklung einer neuen Maschine auf den konsistenten Start zustand zur ckzusetzen wenn ein Teil des Systems abgest rzt ist vgl Wen00 S 179 Im Bereich technischer systemorientierter Wor
13. Um dieses Ziel zu erreichen wird der Transition die die beiden inkompatiblen Ports miteinander verbindet eine Transformationsvorschrift zugeordnet nach der die Ausgaben des Quellservice so transformiert werden dass sie zum Eingangsport des Zielservice der Transition passen Diese Transformationsvorschrift kann als Stylesheet in der Sprache XSLT siehe XSLT99 formuliert werden Stylesheet xy Service _ i Service S Abb 6 19 Transition mit Transformation Durch die Zuordnung solcher Transformationsvorschriften zu Transitionen kommen als Nachfolger einer Aktivit t mit einem Ausgangsport x nicht nur Aktivit ten mit einem Eingangsport y in Frage f r den x c y gilt sondern auch solche f r die es eine Trans 6 3 Modellierung der Dokumenttypen 105 formationsvorschrift x y gibt die der Transition zwischen den Aktivit ten zugeord net werden kann Damit ist eine gr ere Flexibilit t bei der Verkettung von Aktivit ten zu Kontrollfl ssen gegeben die umso st rker w chst je mehr Transformations vorschriften definiert bzw in Form von Stylesheets angelegt werden Konsistenz und Wiederverwendbarkeit Konsistenz und Wiederverwendbarkeit sind zwei sehr wichtige Ziele der Software entwicklung die auch bei der Modellierung von Workflow Modellen h chst relevant f r eine fehlerfreie und effiziente Arbeit des Modellierers sind Sie sollten daher so weit wie m glich bereits durch die hier definierten Prozessdiagr
14. typedValue referencedValue oclAsType OpenPort binding pre isSubsetOf outputPort endif Erl uterung Zust nde die als stateWithPorts klassifiziert sind modellieren die Zust nde in einem Pro zessdiagramm Die Ports dienen der Typisierung und Konsistenzpr fung im Zusammenhang mit dem XML Fluss Darstellung Die Ports werden im Prozessdiagramm nicht dargestellt Ein Modellierungswerkzeug hat daf r zu sorgen dass sie passend repr sentiert werden und visualisiert werden k nnen Tag inputPort Stereotyp stateWithPorts Typ ProcessDiagrams Port Multiplizit t 1 Erl uterung Dieser Port spezifiziert die Menge von Dokumenten die in diesen Zustand flie en k nnen Tag outputPort Stereotyp stateWithPorts Typ ProcessDiagrams Port Multiplizit t 1 Erl uterung Dieser Port spezifiziert eine Menge von Dokumenten die alle m glichen Ausgabedokumente dieses Zustandes enth lt Tab 7 6 Definition des Stereotyps stateWithPorts 7 3 UML Profil f r Prozessdiagramme 139 Aktivit ten zur Komponentenintegration F r die Aktivit ten im Prozessdiagramm wird das Stereotyp serviceState definiert Es basiert auf der Basisklasse CallState die dazu gedacht ist die Methode einer Klasse aufzurufen siehe Abschnitt 6 2 1 Bei einem serviceState wird die Einschr nkung gemacht dass nur eine als service deklarierte Operation aufgerufen werden darf
15. Aktivit tendiagramme gen gten den zuvor aufgestellten Anforderungen jedoch nur ein geschr nkt und besonders bei Petri Netzen und den EPK zeigten sich Schw chen hin sichtlich der leichten Verst ndlichkeit oder der M glichkeit zur Integration vorhandener Softwarekomponenten Weil UML Aktivit tendiagramme die Anforderungen am besten erf llen und sie au erdem als Standard in Industrie und Wissenschaft anerkannt sind wurden sie als Grundlage f r die Modellierungssprache ausgew hlt und unter Ausnut zung der UML Erweiterungsmechanismen zur Umsetzung der XML basierten Workflow Modelle erweitert siehe Kapitel 6 und 7 Um die neuen Konzepte wie Dokumentmigration und Komponentenintegration in die Modellierungssprache zu integrieren wurden Stereotypen zur Erweiterung des UML Metamodells definiert um Syntax und Semantik der Aktivit tendiagramme anzu passen siehe 7 3 Daraus entstand ein eigenes UML Profil f r Prozessdiagramme zur Modellierung der XML basierten Workflows Dabei repr sentieren die Interfaces im statischen Modell die verf gbaren Konnektoren mit ihren Services zur Integration der vorhandenen Softwarekomponenten Diese K nnen in den Aktivit ten des dynamischen Modells aufgerufen werden Dem Migrationsmodell entsprechend implizieren die Tran sitionen zwischen den Zust nden gleichzeitig die berleitung des XML Migrationsdo kuments Au erdem wurde ein Konzept zur Modellierung der Dokumenttypen ausgear beitet und in die Mod
16. Beschreibt eine Transformation von einem Eingangszustand in einen Ziel Funktion zustand Was soll gemacht werden zwischen Ereignissen und Funktionen Beschreibt die logischen Verbindungen Verkn pfungsoperatoren a a gt Beschreibt die zeitlich sachlogischen Ab Kontrollfluss h ngigkeiten von Ereignissen und Funk tionen Zeigt als Navigationshilfe die Verbindung zu einem bzw von einem anderen Pro zess Prozesswegweiser Beschreibt ein Element der Gliederungs Organisatorische Einheit struktur eines Unternehmens Ein Informationsobjekt ist eine Abbildung Informationsobjekt eines Gegenstandes der realen Welt z B Gesch ftsobjekt Entit t Informationsfluss Beschreibt ob von einer Funktion gele L00 sen oder geschrieben wird Zuordnung Von gt yalenk Die Zuordnung beschreibt welche Ein organisationseinheiten heit Mitarbeiter die Funktion bearbeitet Tab 5 1 Elemente einer Ereignisgesteuerten Prozesskette Kel99 S 161 Bei den Verkn pfungsoperatoren wird zwischen den Operatoren f r und oder und exklusives oder unterschieden Wenn mehrere Pfeile eingehen darf nur ein Pfeil aus gehen Verkn pfer wenn mehrere Pfeile ausgehen darf nur ein Pfeil eingehen Ver teiler ber gemeinsame Ereignisse kann man zwischen verschiedenen Prozessen navi gieren Mit dem Konstrukt des Prozesswegweisers sollen solche Verbindungen schnell 5 2 Ereignisgesteuerte Proz
17. OMG Unified Modeling Language Specification Version 1 3 M rz 2000 ftp ftp omg org pub docs formal 00 03 01 pdf Object Management Group OMG Unified Modeling Language Specification Version 1 4 September 2001 ftp ftp omg org pub docs formal 0 1 09 67 pdf Peter Rittgen Modified EPCs and their formal semantics Arbeitsberichte des Instituts f r Wirtschaftsinformatik Nr 19 Universit t Koblenz Landau 1999 http www uni koblenz de rittgen Nr19 pdf Peter Rittgen Quo vadis EPK in ARIS Ans tze zu syntaktischen Erweiterungen und einer formalen Semantik WIRTSCHAFTSINFORMATIK 42 Heft 1 Vieweg Verlag 2000 http www uni koblenz de rittgen ZW1I00 pdf August Wilhelm Scheer ARIS Vom Gesch ftsproze zum Anwendungssystem Springer Verlag Berlin 1998 Martin Gudgin et al SOAP Version 1 2 W3C World Wide Web Consortium Working Draft 9 Juli 2001 http www w3 org TR 2001 WD soap12 20010709 S amp N AG sunShine http www sundn de produkte sunshine sunshine htm Satish Thatte XLANG Web Services For Business Process Design Microsoft Corporation 2001 http www gotdotnet com team xml_wsspecs xlang c default htm XMI00 XML00 XPath99 XQL98 261 Object Management Group OMG XML Metadata Interchange XMI Specification Version 1 1 November 2000 ftp ftp omg org pub docs formal 00 11 02 pdf Tim Bray Jean Paoli C M Sperberg McQueen Eve Maler Extensible Markup Languag
18. ber eine URL bei einem Webserver angesprochen werden kann Es wird dann ein XML Dokument aus einer bestimmten Quelle gelesen das anschlie end mit beliebig vielen Transformern verarbeitet werden kann bevor es an das anfragende Endger t bermittelt wird Wir haben uns entschieden diese flexible M glichkeit der XML Verarbeitung zu nutzen um den Prozessinterpreter in sunShine zu integrieren Dazu wurde eine Klasse SunflowTransformer entwickelt die f r die Definition von Ressourcen verwendet werden kann F r die Auswahl des auszuf hrenden Prozesses sind zwei M glichkeiten vorge sehen Zum einen kann der Prozess direkt an die Ressource bzw die URL gebunden sein Er l sst sich dann beispielsweise durch Aufruf der URL http beispielser ver de executeProcessi ansprechen Dies hat den Vorteil dass der Webserver nur die Prozesse nach au en hin anbietet f r die eine Ressource definiert wurde Zum anderen l sst sich der Prozess auch innerhalb der URL durch den Wert des Parameters process ausw hlen Der Aufruf k nnte dann die Form http beispielserver d processinterpreter process Process1l haben Bei dieser Variante ist jedoch zu beachten dass alle Prozesse die dem System bekannt sind und nicht nur eine genau definierte Auswahl von au en aufgerufen werden k nnen Als XML Eingabedokument dienen die XML Daten die der SunflowTransfor mer beim Aufruf der Ressource vom Webserver erh lt Er bergibt die Daten an den Prozessinter
19. grationsproblematik im E Business auf die Grundlagen des Workflow Managements ein Es werden einige begriffliche Grundlagen aus dem Bereich der Gesch ftsprozess und Workflow Modellierung erl utert und eine Klassifizierung der in einem Unterneh men m glichen Prozesse vorgenommen Besondere Beachtung finden die Aspekte der Workflow Modellierung und der Unterst tzung des Workflow Managements durch Softwarewerkzeuge 2 1 Prozessorientierte Integration im E Business Die Integration vorhandener Softwaresysteme ist f r viele Unternehmen eine zuneh mend wichtige Herausforderung um ihre Konkurrenz und Wettbewerbsf higkeit zu erhalten Derzeit sind die einzelnen Gesch ftsanwendungen in vielen Firmen noch von einander isoliert Zur Verkn pfung dieser Insell sungen innerhalb der betrieblichen Gesch ftsprozesse sind meistens manuelle Schritte n tig was vermeidbare zus tzliche Finanz und Zeitressourcen beansprucht vgl MohOl S 4 Durch den elektronischen Handel und die daf r installierten E Business Systeme sollen Firmenangebote f r Kunden und Handelspartner ber das Internet bereitgestellt werden In diesem Bereich gewinnt die Kopplung von betriebswirtschaftlichen Gesch ftsprozessen mit informationstechnischen Netzwerken wie dem Internet oder unternehmenseigenen Intranets zunehmend an Bedeutung Um konkurrenzf hig zu bleiben m ssen Unternehmen ihre Gesch ftsvorf lle durch eine flexible E Business Infrastruktur unterst tze
20. liche Intentionen verfolgen und durch die semantische L cke voneinander getrennt sind Wie sp ter gezeigt wird haben wir einen Ansatz gew hlt der beide Alternativen miteinander kombiniert Es findet zwar eine bersetzung des visuellen Prozessmodells in eine formale XML basierte Prozessbeschreibung statt damit diese berwindung der semantischen L cke aber nicht zu Fehlern f hrt wird die verwendete Modellierungs sprache zuvor mit ausreichend Details angereichert Au erdem erleichtert der Einsatz von wohldefinierten Schnittstellen zu den im Workflow angesprochenen Software komponenten sowie eine feine Granularit t der Vorg nge eine automatisierte Aus f hrung Nach der Modellierungsphase kann bei der Analyse des Modells auf Werkzeuge zur ckgegriffen werden die bei den in Abschnitt 2 3 3 vorgestellten Tests und Simula tionen helfen Danach wird ein Workflow Management System eingesetzt um die spezifizierten Prozesse w hrend der Durchf hrung zu kontrollieren Im Sinne des CSCW unterst tzt ein WFMS damit zeitlich und r umlich verteilte Arbeitsabl ufe In Verbindung mit den Modellierungsschritten hilft es bei der Trennung von Arbeits organisation und durchf hrung Au erdem l sst sich mit einem WFMS der Ablauffort schritt eines Prozesses berwachen Das WFMS interpretiert die Spezifikation des Prozesses aus dem Workflow Modell und steuert die Ausf hrung indem der Vorgang sukzessive von Aufgabe zu Aufgabe bzw zu den jeweilige
21. ten wichtigen Informationen sollten jedoch in dem Migrationsdokument abgelegt wer den So kann eine Aktivit t auch Nachrichten in dem Dokument ablegen die von einer nachfolgenden Aktivit t interpretiert werden k nnen Das verwendete strukturierte Da tenformat sollte es auch erlauben neue Teildokumente in das Migrationsdokument ein zuf gen so wie ein Sachbearbeiter ein neues Dokument der Umlaufmappe hinzuf gt Das Migrationsdokument hat somit mehrere Funktionen Es dient zur Eingabe der f r die Ausf hrung des Workflows n tigen Parameter R ckgabe der Ergebnisse nach der Workflow Ausf hrung Kommunikation einer Aktivit t mit nachfolgenden Aktivit ten Sammlung von Zwischenergebnissen die schlie lich zum Endergebnis zusam mengesetzt werden k nnen sowie zur e Repr sentation des augenblicklichen Zustandes des Workflows Nach der vollst ndigen Ausf hrung sollte das Migrationsdokument alle n tigen Infor mationen und Daten zur Beantwortung der Anfrage also das Ergebnis der Workflow Ausf hrung enthalten Vor der R ckgabe dieses Ergebnisses ist gegebenenfalls noch eine R cktransformation aus dem intern verwendeten strukturierten Datenformat in das gew nschte Zielformat n tig Dokumentmigration im Kontrollfluss versus expliziter Datenfluss Beim Dokumentmigrationsmodell fallen Kontroll und Datenfluss zusammen weil das Migrationsdokument von einer Aktivit t entsprechend dem Kontrollfluss der Prozess ausf hrung z
22. Abb 8 19 PML Schema Fragment f r Transitionen 8 3 Process Markup Language PML 185 Zum Abschluss zeigt Abbildung 8 20 die verk rzte PML Beschreibung des aus Abschnitt 8 2 2 bereits bekannten einfachen Prozessdiagramms exampleAction lt process name de sundn sunflowexamples transactional false gt lt inputPort gt lt inputPort gt lt outputPort gt lt outputPort gt lt state id id1 gt lt inputPort gt lt inputPort gt lt outputPort gt lt outputPort gt lt initial gt lt next ref id2 transitionType lt initial gt lt state gt lt state id id2 gt lt inputPort gt lt doctype gt lt root element namespace gt lt doctype gt lt inputPort gt lt outputPort gt lt outputPort gt lt service gt lt callservice component methode exampleAction gt lt next ref id3 transitionType gt lt service gt lt state gt lt state id id3 gt lt inputPort gt lt inputPort gt lt outputPort gt lt outputPort gt lt final gt lt state gt lt process gt Abb 8 20 Ein kleines Prozessdiagramm als PML Dokument 186 Kapitel 8 Beschreibung von Prozessen in XML 8 3 4 Bewertung Nachdem die einzelnen Sprachbestandteile von PML in den letzten beiden Abschnitten vorgestellt wurden soll nun eine Bewertung der Sprache erfolgen Da PML speziell f r die textuelle Repr sentation von Prozessdiagrammen entwickelt wur
23. Ansatz dar der die verschiedensten Ein und Ausgabeger te unterst tzt Dadurch kann das WFMS nicht nur mittels eines Web Browsers sondern beispielsweise auch per Handy angesprochen werden Als Ausgabe eines Prozesses k nnte neben HTML Dokumenten auch WML PDF usw erzeugt werden Neben der Anbindung von Softwarekomponenten kann es in Workflow Modellen auch notwendig sein menschliche Bearbeiter w hrend der Ausf hrung in den Prozessablauf einzubeziehen um Teilaufgaben zu erledigen Das WFMS sollte Mechanismen enthalten mit denen eine solche Benutzerinteraktion realisierbar ist Workflow Client Application Interface vgl Wmc95 S 21 Es sollte eine Administrator Schnittstelle zur Verf gung stehen ber die die Ausf hrungskontrolle der einzelnen Prozessinstanzen m glich ist siehe Wmc95 S 44 Denkbar ist hier sowohl eine direkte L sung in Form einer Benutzungs schnittstelle als auch eine API Schnittstelle Application Programming Interface Im Architekturvorschlag der Fallstudie ist ausdr cklich eine Regelmaschine geplant die anhand einer Regelmenge entscheidet welchem Service ein Eingabe dokument mit einem bestimmten Vorgangstyp bergeben wird Dabei handelt es sich um eine spezielle Anforderung die nicht als allgemeing ltig angesehen wer den kann Ein WFMS muss allerdings flexibel genug sein um solche Gesch fts regeln umzusetzen was aber nicht unbedingt in Form einer Regelmaschine erfol gen muss sondern auch durch
24. Das EPK Modell ist im Kontext der von Scheer entwickelten Architektur integrierter Informationssysteme ARIS entstanden Bei diesem Ansatz wird die Gesamtsicht auf ein Unternehmen in f nf Teilsichten aufgeteilt Die vier Sichten Funktionssicht Organi sationssicht Datensicht und Leistungssicht spiegeln die Struktur des Systems wider w hrend die Steuerungs bzw Prozesssicht die dynamischen Verhaltensaspekte von Gesch ftsprozessfl ssen behandelt vgl Sch98 S 36f F r die Modellierung der f r die Steuerungssicht relevanten Prozesse wird bei ARIS das EPK Modell benutzt Dabei dient die EPK in dieser Sicht als eine integrative Darstellung die neben den dynami 60 Kapitel 5 Evaluierung vorhandener Workflow Modellierungssprachen schen Aspekten auch funktionale und datenorientierte Zusammenh nge aufzeichnet siehe Wen00 S 33 Eine EPK wird als ein Vorgangskettendiagramm dargestellt Das Grundprinzip ist dabei der zeitlich sachlogische Ablauf von Ereignissen und Aufgaben Kel99 S 158 Bei der Darstellung werden Elemente als Knoten eines Graphen gezeichnet deren Beziehungen als Kanten in diesem Graph erscheinen Mit Verkn pfungsoperato ren l sst sich die Ablauflogik des Kontrollflusses abbilden Die Sprachkonstrukte im Einzelnen sind in der folgenden Tabelle nach Kel99 S 161 aufgef hrt Bezeichnung Symbol Definition Beschreibt einen Zustand der eine Folge Ereignis bewirkt Wann soll etwas gemacht wer den
25. Es erscheint dann ein Dialog in dem sich eines der geladenen Packages ausw hlen l sst in das der Typ verschoben werden soll Darunter kann man ein Stylesheet definieren mit dem Migrationsdokumente transformiert werden sollen wenn sie ber eine Transition dieses Typs laufen Es kann entweder eine URL f r ein Stylesheet angegeben eine Datei mit Hilfe der Schaltfl che Select File ausgew hlt oder ein Stylesheet direkt in der Eingabemaske eingegeben werden Im letzten Fall pr ft der Editor beim Bet tigen von Save automatisch ob die 9 2 Bedienung des Prozesseditors 199 Benutzereingabe ein g ltiges XSL Stylesheet enth lt Falls nicht werden die gefunde nen Fehler in einer Fehlermeldung ausgegeben Auf der rechten Seite befinden sich die aus 9 2 4 bekannten Felder zur Eingabe des Quell und Zielports des Transitionstyps D Tai D Paaa re anne Be Trad ips Cesis Bp Tranio hot in H E Cergereniccesetior jPaniing H C Cirnea nnm Meg a Mara wei Paz knger fa IUR pri Bee PrE Burgen Hra aymaras Feier Fr er T h h Prapti ui O Daia PERTE TS IE oe TE IT malmit atip fual atpleobert Abb 9 7 Eingabemaske f r einen neuen Transitionstyp Erzeugen eines neuen Prozessdiagramms Um ein neues Prozessdiagramm anzulegen w hlt man mit der rechten Maustaste das Package im Projektbaum aus das den neuen Prozess enthalten soll Es erscheint ein Popup Men in dem die Aktion New Process gew
26. Grafische Sprache Als grafische Sprache sind Petri Netze recht intuitiv und einfach zu erlernen Zudem lassen sich grafische Darstellungen im Allgemeinen besser verste hen und bieten eine geeignete Grundlage zur Diskussion nicht nur zwischen Spezialis ten sondern in gewissem Ma e auch mit Laien Formale Semantik Petri Netze und ihre zahlreichen Erweiterungen besitzen eine mathematisch exakt definierte formale Semantik Diese erm glicht nicht nur die pr zise Beschreibung der zu modellierenden Sachverhalte sondern ist auch die Grundvoraus setzung um solche Modelle automatisiert interpretieren und ausf hren zu k nnen Ausdrucksst rke Besonders durch die Vielzahl an Erweiterungen gegen ber den klas sischen Netzen verf gen Petri Netze ber nahezu alle erforderlichen Sprachkonstrukte die f r die Beschreibung komplexer Systeme und Prozesse notwendig sind Analysem glichkeiten Aus der mathematischen Basis der Theorie von Petri Netzen ergeben sich vielf ltige Analysem glichkeiten konkreter Netze Es lassen sich Aussa gen ber Erreichbarkeit Antwortzeiten Deadlocks und andere Eigenschaften beweisen Auf diese Weise hat man m chtige Mittel zur Hand um Netze verifizieren oder opti mieren zu k nnen Herstellerunabh ngigkeit Schlie lich ergibt sich ein Vorteil daraus dass Petri Netze nicht von einem bestimmten Hersteller abh ngen Sie bilden einen unabh ngigen Rah men f r die Modellierung und Analyse von Prozessen der nic
27. Oes97 Use Case Diagramme dienen im Allgemeinen dazu die Sicht eines externen Benutzers auf ein System zu modellieren Dies geschieht in Form von Anwen dungsf llen die beschreiben welche Aktionen von au en am System ausgel st werden k nnen Im Bereich von Gesch ftsprozessen eignen sich Use Case Diagramme um in einem ersten Schritt alle Gesch ftsprozesse zu erfassen die in einem System vorkom men Dabei lassen sich auch die Beziehungen der Prozesse zu den beteiligten Akteuren sowie zu anderen Prozessen beschreiben Auf diese Weise kann man den gesamten Kontext eines Gesch ftsprozesses modellieren Als n chster Schritt nach der Erfassung aller Prozesse durch Use Case Diagramme muss ein statisches Modell der beteiligten Objekte erstellt werden Dies k nnen aktive Personen oder Systemkomponenten ebenso sein wie Daten die innerhalb des Prozesses erzeugt oder verarbeitet werden In UML bieten sich daf r Klassendia gramme an in denen sich nicht nur Eigenschaften der einzelnen Objekte sondern auch ihre Beziehungen untereinander beschreiben lassen Klassendiagramme sind somit ein geeignetes Mittel f r die Daten und Organisationssicht siehe Sch98 S 36 auf einen Gesch ftsprozess F r die Modellierung der dynamischen Aspekte eines Gesch ftsprozesses Kennt die UML mehrere Diagrammarten Sowohl Sequenz als auch Kollaborations diagramme veranschaulichen den Nachrichtenaustausch zwischen den beteiligten Objekten W hrend jedoch in Se
28. Port inputPort Port outputPort Port outputPort Port transactional Boolean 1 subProcess i SubactivityStateVertex PseudoStateVertex ServiceStateVertex serviceState parameter initialState i LYI InitialStateVertex DecisionStateVertex SynchStateVertex SynchforkStateVertex SynchjoinStateVertex FinalStateVertex MergeStateVertex ForkStateVertex JoinStateVertex Al fork _____ iein 1 0 1 service 1 Argument service parameter value Service P Parameter value String 1 ordered 1 F image String inputPort Port outputPort OpenPort Abb 7 10 Klassendiagramm f r verschiedene Zustandsarten 152 Kapitel 7 Metamodell f r Prozessdiagramme SubactivityStateVertex Die Klasse SubactivityStateVertex bernimmt die Rolle der ServiceStateVertex Argument PseudoStateVertex InitialState Vertex FinalStateVertex DecisionStateVertex MergeStateVertex UML Metaklasse SubactivityState siehe Abbildung 7 6 durch die ein Subprozess in ein Prozessdiagramm eingebettet werden kann daher auch die Assoziation zur Klasse ProcessDiagram Die Klasse ServiceStateVertex vereinigt die Eigenschaften des Stereotyps serviceState aus Abschnitt 7 3 2 und dessen Basis klasse CallState aus dem UML Metamodell siehe Abbil dung 7 6 Im UML Metamodell ist die Klasse CallState von State abgeleitet die wiederum ber eine Assoziation mit einer Action verbunden ist bei der es sich um eine CallActio
29. Sprachkonstrukte von XLANG werden insbesondere die Anforderungen aus Abschnitt 8 1 ber cksichtigt Statisches Modell Bevor ein Workflow Ablauf mit XLANG beschrieben werden kann m ssen die zu integrierenden Softwarekomponenten in einem statischen Modell spezifiziert werden Dies geschieht mit Hilfe von WSDL wobei f r jede Komponente sogenannte Ports definiert werden Jeder Port ist dabei eine Menge von Nachrichtentypen die von der Komponente versendet oder empfangen werden k nnen Die Spezifikation der Nach richtentypen geschieht mit Hilfe von XML Schemata Dieser Ansatz ist f r die Umset zung des Port Konzepts in XML Prozessen nicht optimal geeignet da es Komponenten geben kann die keine genau festgelegte Dokumentstruktur fordern sondern lediglich bestimmte enthaltene Elemente vgl Abschnitt 6 3 1 Das von uns eingef hrte Port Konzept ist somit flexibler und kann nicht auf WSDL abgebildet werden 8 2 Vorhandene XML Formate f r Prozessmodelle 165 Beschreibung der Prozessabl ufe Aufbauend auf dem statischen Modell kann nun der Ablauf eines Workflows festgelegt werden Grundbaustein bei der XLANG Beschreibung eines Prozesses ist die soge nannte Aktion Dabei handelt es sich um das Ansprechen eines bestimmten Ports und der Auswahl einer seiner Operationen Eine Operation ist dabei das Senden oder Empfangen einer Nachricht Alternativ stehen auch Aktionen zur Verf gung mit denen sich zeitliches Verhalten modellieren l sst wie
30. ber Webformulare oder andere Schnittstellen zu veranlassen 3 1 2 Anforderungen Vereinfacht gesehen sollen auf der geplanten E Business Plattform die elektronischen automatisierten Vorg nge in folgenden f nf Schritten ablaufen 1 Eingang eines Dokuments das den Vorgang ausl st und die n tigen Eingabeparameter f r den Vorgang enth lt Identifizierung des Dokumenttyps dadurch eindeutige Klassifizierung des Vorgangstyps Bei unbekanntem Typ wird eine entsprechende Fehlerbehandlung durchgef hrt 2 Transformation des Dokuments in ein internes XML Format 3 Archivierung des transformierten sowie des originalen Dokumentes in einem Dokumentenarchiv Datenbank 4 Verarbeitung des Dokumentes durch Weiterleiten an einen bestimmten Service Dort Anbindung der Back End Systeme und deren Nutzung Diese Aufgabe wird von einem Workflow Management System bernommen das den zust n digen Service anhand von Regeln bestimmen kann Dieser Schritt wird so lange wiederholt bis das Dokument alle n tigen Bearbeitungsschritte durchlaufen hat Alle Zwischenstufen des Dokumentes sowie das Endergebnis werden in dem Archiv gespeichert 5 Schlie lich Transformation in das gew nschte Ausgabeformat und Ausgabe des Dokuments Bei der Verarbeitung der Dokumente sollen verschiedenste Datenformate unterst tzt werden F r die Eingabe eines Dokumentes ist beispielsweise ein HTTP Aufruf ber das Internet oder eine E Mail mit den standardm ig bekannten
31. copySubs rootExceptions subExceptions root rootExceptions E falls root CopyPlaceholder mit root e rootExceptions F r die Bindung eines offenen Ports an einen nicht offenen Port wird die folgende Funktion binding definiert die Dokumenttypen aus dem zu bindenden Port bernimmt wenn sie keinen Platzhalter enthalten und anderenfalls durch Aufruf der Hilfsfunktion binding an alle Dokumenttypen bindet die in dem nicht offenen Port enthalten sind 6 3 Modellierung der Dokumenttypen 117 Als Ergebnis wird ein neuer Port zur ckgeliefert bei dem alle copyRoot und copySubs Platzhalter durch konkrete XML Elemente ersetzt wurden Def 6 15 Die Bindungsfunktion binding binding OpenPorts x Ports Ports Yoe OpenPorts Ype Ports binding o p o o e om DocTypes U binding 0 p 0 o OpenDocTypes DocTypes p p Transitionstypen und typisierte Transitionen Wie in Abschnitt 6 3 2 dargelegt werden im statischen Modell Transitionstypen defi niert die zur Typisierung von Transitionen benutzt werden m ssen Demnach hat jeder Transitionstyp einen Quellport einen Zielport und eine Transformationsvorschrift trans die Dokumente aus der Dokumentenmenge des Quellports auf Dokumente aus der Dokumentenmenge des Zielports abbildet Da es sich bei dem Zielport um einen offe nen Port handelt ist der Wertebereich der Funktion trans die Vereinigungsmenge aller sinnvollen Bindungen des Zielport
32. dass der Prozessinterpreter aus schlie lich Prozesse ausf hren kann die in Form einer PML Beschreibung vorliegen Es kann jedoch nicht davon ausgegangen werden dass das UML Werkzeug mit dem ein Prozess modelliert wurde als Ausgabe ein PML Dokument erzeugen kann Mit XMI siehe Abschnitt 8 2 2 existiert ein Industriestandard der als einheitliches Format zum Austausch von UML Modellen zwischen verschiedenen Modellierungssystemen dient Im Rahmen der Verbreitung von XMI nutzen immer mehr UML Werkzeuge diese Sprache zur Speicherung von UML Diagrammen Wenn ein Prozessdiagramm also mit einem anderen Werkzeug als dem Prozesseditor entworfen wurde k nnte es zun chst in Form eines XMI Dokuments abgelegt werden Man ben tigt dann eine 252 Kapitel 12 Schlussbetrachtungen Konvertierungsm glichkeit zwischen den beiden Formaten XMI und PML Da es sich bei beiden um XML Sprachen handelt liegt es nah zu diesem Zweck XSL Stylesheets zu verwenden Man m sste ein Stylesheet entwickeln das aus einer XMI Datei ein PML Dokument konstruiert welches dann als Eingabe f r den Interpreter verwendet werden kann Ebenso k nnte es sinnvoll sein ein zweites Stylesheet zu realisieren das ein PML Dokument in eine XMI Datei bersetzt Dies w rde es erm glichen ein Pro zessdiagramm das mit Hilfe des Prozesseditors erstellt wurde in einem anderen UML Werkzeug zu bearbeiten Quellcodegenerierung Als Alternative zur Ausf hrung von Prozessdiagrammen dur
33. die als sogenanntes XLANG Schedule von dem BizTalk XLANG Scheduler ausgef hrt werden kann 4 1 4 Workflow Ausf hrung mit BizTalk Server 2000 Bei der Ausf hrung von Workflows spielt der XLANG Scheduler eine zentrale Rolle Die XLANG Scheduler Engine f hrt die einzelnen Instanzen eines durch einen XLANG Schedule definierten Workflows aus Der Start eines Ablaufs wird dabei durch den Auf ruf einer Windows spezifischen URL dem sogenannten moniker ausgel st siehe Moh01 S 29 Bei der Ausf hrung greift der Scheduler auf die serverinternen Messa ging Services zur ck um den notwendigen Nachrichtenaustausch zu realisieren Au er dem verwaltet er die Ressourcen f r die Instanzen was besonders wichtig wird wenn es sich um langlebige Prozesse handelt die ber viele Tage laufen k nnen und eine gro e Anzahl solcher Prozesse aktiv ist Muss ein Prozess lange auf eine bestimmte Nachricht warten wird er im aktuellen Zustand eingefroren bis die Nachricht eingetroffen ist In dieser Zeit k nnen die Betriebsmittel von anderen Instanzen genutzt werden vgl Moh01 S 28 Das Workflow Konzept von BizTalk Server ist sehr stark datenorientiert und fokussiert die Kommunikation per Austausch von XML Nachrichten Die daf r benutzten Messaging Services verwenden BizTalk Dokumente als XML Container um neben XML auch andere Datenformate darin zu speichern insbesondere wird EDI Electronic Data Interchange der bisherige Standard beim gesch ftlich
34. die sich jeweils auf den R ckgabewert beziehen der von der Regel maschine bei der Ausf hrung des vorausgegangenen Zustandes erzeugt wurde M glich ist die Angabe eines Zielintervalls oder eines Operators wie lt S 2 gt zusammen mit einem Operand als Vergleichswert Wenn der R ckgabewert die Un Gleichung erf llt wird die entsprechende Aktion ausgew hlt Der folgende Auszug aus dem Regelwerk verdeutlicht die Anwendung der Entscheidungswerte an einem Beispiel zum Lesen von Kundeninformationen aus einer Datenbank Die Regeln beschreiben einen Prozess dessen zweite Aktion von dem R ckgabewert der ersten Aktion abh ngt In der ersten Aktion werden Kundendaten aus einer Datenbank eingelesen Ist der R ckgabewert dieser Aktion gleich null was einer fehlerfreien Ausf hrung entspricht werden als n chstes die Kundendaten angezeigt ansonsten Standardaktion wird eine Fehlerverarbeitung angesto en 11 1 Vergleich der L sungsans tze 241 lt Prozesstyp name Kundeninfo gt lt Zustand id 0 name Start start Ja gt lt StandardAktion final Nein folgeid 1 name Kundeninfo gt lt Url url http sunshine kundeninfo lesen xml gt lt StandardAktion gt lt Zustand gt lt Zustand id 1 name Ergebnisbehandlung start Nein gt lt SyncAktion final Ja name Kundendaten anzeigen gt lt Url url http sunshine ergebnis ok kundeninfo xml gt lt Entscheidungswerte gt lt Ausdruck operator e
35. h95 S 5 vorgestellt Bei der Beschreibung der Aktivit ten sollte nicht mehr explizit auf eine Konkrete Person sondern auf eine Rolle oder Stelle verwiesen werden Das Workflow Management System kann dann zur Laufzeit anhand des statischen Organisations modells entscheiden welcher Bearbeiter auszuw hlen ist vgl B h95 S 8 Eine analoge Abstraktion kann auch bei der Modellierung der hier betrachteten Workflows zur Integration von Softwarekomponenten benutzt werden Die Konnekto ren realisieren wie im vorausgehenden Abschnitt dargestellt die Verbindungen zu den existierenden Softwarekomponenten Abstrakte Repr sentanten der Konnektoren werden in einem statischen Modell aufgef hrt um dort ihre genaue Schnittstelle gegen ber dem WFMS zu spezifizieren Zur Laufzeit kann das WFMS dann beliebige ver f gbare Implementierungen f r einen Konnektor einsetzen solange die Implemen 82 Kapitel 6 XML Prozesse und Prozessdiagramme tierung die spezifizierte Schnittstelle erf llt Die Schnittstelle bezieht sich hier zum einen auf die Signatur der aufrufbaren Methoden zum anderen auf den verwendeten Dokumenttyp f r die ein und auszugebenden Daten Diese Spezifikation reicht aus um das Workflow Modell aufzustellen auch wenn es zum Zeitpunkt der Modellierung noch keine konkrete Implementierung f r einen der spezifizierten Konnektoren gibt Um aber eine Instanz des Workflow Modells vom WFMS ausf hren zu lassen m ssen f r alle benutzten
36. i ial meae i PseudoState State Hop ji StateMachine De A i N j A H H H metaclass metaclass metaclass metaclass i 0 1 CompositeState SimpleState SynchState ActivityDiagram N metaclass i metaclass i BehavioralFeature i N N MN Interface i A i i i i i i A i P i metaclass metaclass metaclass H 1 i SubmachineState ActionState FinalState i i i metaclass i i l i Parameter H N A 1 i metaclass i t Operation H j i i N l metaclass metaclass i f SubactivityState CallState 1 stereotype stereotype I stereotype H stereotype estereotipo es 7 H H P SER E Ei i i i i i i t ii i 1 i H stereotype stereotype SoA stereotype i service stateWithPorts stereotype componentConnector i H typedTransition 3 Tags Tags Tags i image Geometry 0 1 inputPort Port 1 Tags inputPort Port 1 outputPort Port 1 i l outputPort OpenPort 1 H T l 1 1 i 1 i i i stereotype H serviceState 1 stereotype stereotype i H transitionType Tags processDiagram type g Tags Tags IE 4444444 mamma A Hmmm R Fr sourcePort Port 1 taggedValue en az m targetPort OpenPort 1 st rt Pe I l transformation Expression 0 1 outputPort Port 1 Abb 7 6 UML Metamodell f r Prozessdiagramme Da kein allgemeines UML Metamodell sondern ein spezielle
37. in der die meisten Transitionen durch die Beendigung der vorhergehenden Aktion und nicht durch externe Ereignisse getriggert wird siehe Omg01 3 157 An activity diagram is a special case of a state diagram in which all or at least most of the states are action or subactivity states and in which all or at least most of the transitions are triggered by completion of the actions or subactivities in the source states Da in Prozessdiagrammen neben Pseudozust nden grunds tzlich nur Aktions und Subaktivit tszust nde erlaubt sind erschien uns die Verwendung von Ereignissen nicht als zentrale Anforderung Aus Zeitgr nden haben wir daher darauf verzich tet eine Ereignisbehandlung in Prozessdiagramme zu integrieren Das zentrale Ziel von XML Prozessen ist die Integration bestehender Systeme in einen Workflow Ablauf der Schritt f r Schritt vom Workflow Management System abgearbeitet wird Das einzige Bindeglied zwischen den Systemen besteht dabei aus Sicht des WFMS in dem Migrationsdokument Falls zus tzlich dazu Ereignisse oder Nachrichten ausgetauscht werden m ssen so geschieht dies innerhalb der Systeme jedoch transparent f r das WFMS Eine explizite Modellierung im Prozessdiagramm ist daher nicht erforderlich Objektflusszust nde Da XML Prozesse so konzipiert sind dass das Migrations dokument die einzige gemeinsame Datenquelle aller Aktivit ten ist die dem Workflow Management System bekannt ist wurde im Abschnitt 6 1
38. lt auftraggeber gt lt empfaenger gt lt konto gt 67890 lt konto gt lt bankleitzahl gt 47260121 lt bankleitzahl gt lt name gt Hans Meier lt name gt lt empfaenger gt lt betrag waehrung DM gt 5000 lt betrag gt transaktion typ ueberweisung V transactional transaktion auftraggeber name Itransaktion empfaenger name and not Itransaktion empfaenger bankleitzahl SQL 47262703 Operation else else X transaktion empfaenger b nkleitzahl 47262703 SQL Anfrage SQL o Operation Mail senden Sa CORBA Komponente lt transaktion gt Abb 6 5 Beispiel eines Prozessdiagramms 86 Kapitel 6 XML Prozesse und Prozessdiagramme Zun chst wird der Typ der Transaktion berpr ft Nur wenn es sich um eine berwei sung handelt verzweigt die Ausf hrung in den dargestellten Teilprozess In den Guards der Verzweigung werden XPath Ausdr cke verwendet um entsprechend die Daten des XML Dokuments abzufragen Es werden nun zwei Prozessstr nge erzeugt die parallel abgearbeitet werden Der linke Teilprozess ist f r die eigentliche Ausf hrung der berweisung zust ndig Da es sich dabei um eine atomare Folge von Aktionen handeln muss wird mit Hilfe eines Subaktivit tszustands ein Unterprozess gebildet welcher transaktional d h entweder vollst ndig oder gar nicht ausgef hrt wird Diese Forderun
39. lt copyRoot gt lt except element root2 namespace gt lt copyRoot gt lt copySubs gt lt copySubs gt lt doctype gt Abb 8 8 Beispiele f r die PML Beschreibung von Dokumenttypen Datentypen Port und OpenPort Ein Port schlie lich ist eine Menge von DocTypes ein OpenPort eine Menge von OpenDocTypes Diese Definition ergibt direkt die Umsetzung f r das PML Schema dataType OpenPort types OpenDocType binding bindTo Port Port dataType Port Constraints self types gt forAll t ocllsTypeOf DocType isSubsetOf super Port Boolean union port Port Port lt xsd complexType name OpenPortType gt lt xsd sequence gt lt xsd element name doctype type OpenDoctypeType maxOccurs unbounded gt lt xsd sequence gt lt xsd complexType gt lt xsd complexType name PortType gt lt xsd sequence gt lt xsd element name doctype type DoctypeType maxOccurs unbounded gt lt xsd sequence gt lt xsd complexType gt Abb 8 9 PML Schema Fragment f r Ports 176 Kapitel 8 Beschreibung von Prozessen in XML 8 3 2 Beschreibung des statischen Modells Sowohl die Bestandteile des statischen Modells von XML Prozessen d h Komponen ten und Transitionstypen als auch die Prozesse selbst sind in Anlehnung an UML in Packages gegliedert vgl Abschnitt 7 4 Dies f hrt zu einer wesentlich besseren Beherrschbarkeit umfangreic
40. muss die Nachricht lediglich verstehen die n tigen Aktionen ausf hren und gegebenenfalls seinerseits mit einer Nachricht antworten Grundsatz ist somit eine Integration durch lose gekoppelte Kommunikationsprozesse Im Einzelnen definiert das BizTalk Framework eine Reihe von XML Elemen ten die sogenannten BizTags siehe Moh01 S 15 die f r den Einsatz der XML Formate bei der Anwendungsintegration und dem Nachrichtenaustausch n tzlich sind BizTalk gibt zum Beispiel XML Tags vor die Informationen f r das Versenden von Nachrichten zwischen den betrieblichen Anwendungssystemen enthalten die soge nannten message elements Ein Dokument das mit diesen speziellen Marken angerei chert ist stellt eine Erweiterung eines SOAP Dokuments dar und wird BizTalk Dokument genannt Inzwischen hat Microsoft die Festlegung und Definition der BizTalk XML Elemente an das Internet Standardisierungsgremium W3C bergeben siehe Biz01 Ein registrierter Benutzer kann nach der BizTalk Framework Spezifi kation ein g ltiges XML Schema entwerfen und dieses BizTalk konforme Format auf der BizTalk org Plattform ver ffentlichen um es seinen Gesch ftspartnern bekannt zu machen BizTalk org Mit der Webseite BizTalk org Biz01 wird ein f r jedermann nach einer Registrierung zug nglicher Raum geschaffen in dem man sich auf gemeinsame XML Formate ver st ndigen und diese austauschen kann Diese zentralisierte Speicherung der XML Formatdefinitionen i
41. r lassen sich die vorhande nen Nachrichtendienste mit den Aktionen des Workflows koppeln Die in Mic00 S 7 vorgestellte Any To Any Integration soll ber Adaptoren zu COM Komponenten Skript Komponenten und zu Anwendungen Dritter realisiert werden Des Weiteren las sen sich durch Einsatz des SOAP Protokolls andere Komponenten aufrufen die dieses Protokoll unterst tzen Mit diesen Schnittstellen m chte Microsoft ihren Server als Integrationsplattform f r heterogene Umgebungen platzieren Unter dem Stichwort der dynamischen Prozesse ist es m glich abstrakte Stell vertreter f r Komponenten oder Organisationseinheiten zu definieren und zun chst nur diese in einem Workflow Modell zu benutzen Erst zur Laufzeit erfolgt dann die Aus wahl einer konkreten Instanz oder Implementierung der Komponente die dann jedes Vorkommen des abstrakten Stellvertreters ersetzt vgl Mic00 S 7 Die in den Anfor derungen aus Abschnitt 3 2 geforderte dynamische Bindung von Komponenten wird dadurch also erf llt 4 1 3 Workflow Modellierung mit BizTalk Server 2000 Das in BizTalk Server integrierte grafische Modellierungswerkzeug f r Workflows ist der Orchestration Designer vgl Moh01 S 27ff der auf Microsoft Visio basiert Das Werkzeug erlaubt die visuelle Definition der Prozessmodelle und der Bindung der Aktionen an vorhandene Softwarekomponenten jedoch nicht dar ber hinausgehende Analysefunktionen zur Optimierung und Konsistenzpr fung Zun chst w
42. siehe Abschnitt 9 2 3 Dieser Grundaufbau des Editors bleibt w hrend der gesamten Bearbeitung bestehen Beim Aufruf einiger Aktionen erscheinen Dialoge in denen zun chst die jeweiligen Eingaben get tigt werden m ssen bevor die restliche Benutzungsoberfl che wieder aktiviert wird siehe Abschnitt 9 2 4 Solche Dialoge werden blicherweise als modale Dialoge bezeichnet 9 2 Bedienung des Prozesseditors 193 Abb 9 1 Hauptfenster des Prozesseditors 9 2 1 Verwaltung in Projekten Die gesamte Verwaltung der Workflow Modelle mit Hilfe des Prozesseditors geschieht in Form von sogenannten Projekten von denen jeweils h chstens eines zur gleichen Zeit im Editor ge ffnet ist Das Projekt das zur Zeit ge ffnet ist sei der Einfachheit halber im Folgenden das Projekt genannt Wie im Abschnitt 8 3 erl utert wurde sind alle Bestandteile der Workflow Modelle d h Konnektoren Transitionstypen und Prozesse in Packages organisiert Ein Projekt besteht nun aus einer Menge solcher Packages Der Benutzer kann jederzeit Packages in das Projekt aufnehmen die er bear beiten m chte oder entfernen wenn er sie nicht bearbeiten m chte Die Arbeit mit verschiedenen Projekten bietet den gro en Vorteil dass im Editor niemals alle Workflow Modelle gleichzeitig sichtbar sind in denen sich der Benutzer m glicher weise nur schwer zurecht findet sondern immer nur diejenigen Bestandteile die zur Zeit f r seine Arbeit relevant sind Wichtig zu e
43. sondern nur den Parallelstrang in dem dieser Service aufgerufen wurde Um dennoch eine vollst ndige Abarbeitung des Prozesses zu erreichen m sste die Ausf h rung des abgebrochenen Prozessstrangs wiederholt werden Dabei kann der Fehler zwar erneut auftreten was aber nicht zwingend der Fall sein muss vor allem dann nicht wenn er beim ersten Mal nur deshalb aufgetreten ist weil eine zeitlichen Schwankungen unterworfene Bedingung geherrscht hat Als Beispiel k nnte hier die zeitlich wech selnde Auslastung bzw berlastung eines Kommunikationsnetzwerkes genannt werden die etwa die Arbeit eines verteilten Systems behindern kann Handelt es sich um eine solche Art von Fehlern k nnte mit dem Wiederholungsversuch der Prozess doch noch korrekt abgearbeitet werden Zur Umsetzung des Konzepts m sste zu Beginn jedes parallelen Teilstrangs eine Sicherungskopie vom aktuellen Migrationsdokument angelegt werden um f r die Wiederholung gleiche Voraussetzungen hinsichtlich der Daten bereitzustellen Es gibt bei der Wiederholung eines Teilstrangs allerdings zus tzlich das Problem dass die vor der fehlerhaften Komponente bereits ausgef hrten Services Seiteneffekte und nde rungen an externen Datenquellen verursacht haben k nnten die nicht ohne Weiteres durch eine Sicherungskopie r ckg ngig gemacht werden k nnen Werden diese Servi ces beim Wiederholungsversuch ebenfalls ein zweites Mal mit ihren Nebeneffekten ausgef hrt kann das unter Umst nd
44. sprachen nur zu betrachten wenn sie bereits vorhanden sind aber keine neuen Ans tze in dieser Richtung vorstellen Die sich aus der Modellierung ergebenden Prozessdefinitionen sollen ebenfalls in einem XML Format abgelegt werden k nnen vgl Kapitel 8 Dies ist neben der Plattformneutralit t der XML Sprachen besonders wegen der Kompatibilit t von XML zu g ngigen Kommunikationsprotokollen im Internet von Vorteil weil sich so Prozess beschreibungen ber das Netz leicht austauschen lassen F r eine solche XML basierte Prozessbeschreibung muss eine ausreichend formale Definition gefunden werden damit das WFMS die Beschreibung zwecks Ausf hrung interpretieren kann Der Entwicklung von komfortablen Hilfswerkzeugen zur Analyse und Optimie rung der Workflow Modelle schenken wir aus Zeitgr nden keine Beachtung Gleiches gilt f r eine umfangreiche Schnittstelle zur Administration laufender Prozesse Diese Anforderungen siehe Punkte 2 und 11 in Abschnitt 3 2 k nnen prinzipiell sp ter durch entsprechende Erg nzungen erf llt werden F r die Anforderung der Zusicherung von Transaktionseigenschaften und zur Behandlung von Ausnahmen nach Fehlerzust nden k nnen in dieser Arbeit wegen des Umfangs und der Schwierigkeit dieses Problemfel des nur entsprechende Konzepte angedacht aber nicht tiefergehend behandelt werden vgl Abschnitt 10 3 und 10 4 Trotzdem soll jedoch zumindest die sp tere Erg nzung durch vorausschauenden Entwurf des Modellko
45. 1 der impli zite Datenfluss entlang des Kontrollflusses eingef hrt Eine explizite Modellie rung mit Hilfe von Objektflusszust nden ist daher in Prozessdiagrammen nicht vorgesehen Bahnen Bei XML Prozessen existiert keine Organisationshierarchie von Rollen die f r die Ausf hrung von Aktionen zust ndig sind und f r die erst zur Laufzeit konkrete Akteure gefunden werden vgl Abschnitt 2 3 1 Stattdessen wird f r jede Aktion explizit eine passende Softwarekomponente angegeben Aus diesem Grund erschien es uns als nicht notwendig Bahnen zur Verdeutlichung von Zust ndigkeiten in Prozessdiagrammen zu verwenden Dynamische Zust nde In Aktivit tendiagrammen ist es m glich die Aktionen innerhalb von Zust nden mehrfach parallel auszuf hren wobei die Anzahl der Ausf hrungsinstanzen dynamisch zur Laufzeit ermittelt wird Dies dient in der Regel dazu Mengen von Eingabedaten m glichst effizient zu verarbeiten Da in Prozessdiagrammen die Eingabe einer Aktion aus einem einzigen Migrations dokument besteht schien es nicht notwendig zu sein dieses Sprachkonstrukt zu unterst tzen Wir haben allerdings aus Zeitgr nden auf eine tiefergehende Unter suchung verzichtet das Konzept der XML Prozesse lie e sich bei Bedarf aber sicherlich um dynamische Zust nde erg nzen 92 Kapitel 6 XML Prozesse und Prozessdiagramme 6 3 Modellierung der Dokumenttypen Im vorausgegangenen Abschnitt wurden die verschiedenen Konzepte zur Modellierung vo
46. 130 Kapitel 7 Metamodell f r Prozessdiagramme 7 3 1 Umsetzung des Port Konzepts in UML Datentypen Die bei der formalen Definition von Ports in Abschnitt 6 3 3 definierten Mengen werden im Folgenden als Datentypen im UML Metamodell repr sentiert Jede dort definierte Menge entspricht dabei einem Datentyp jedes Element einem Wert dieses Datentyps Die nachstehende Abbildung zeigt die Datentypen in der grafischen UML Notation Sie werden in den folgenden Stereotyp Definitionen als Attributtypen benutzt dataType Placeholder abstract dataType XmiElement namespace String r dataType dataType SlemNamaz sting AnyPlaceholder CopyPlaceholder abstract rootExceptions XmlElements dataType dataType CopyRoot CopySubs subExceptions XmlElements dataType OpenDocType root XmlElement 0 1 Heer placeholder Placeholder 0 1 subs XmIElement p binding bindTo DocType DocType Constraints types OpenDocType binding bindTo Port Port self root size self placeholder size 1 dataType Port dataType Constraints DocType self types gt forAll j tt ocllsTypeOf DocType Constraints self root isEmpty implies isSubsetOf super Port Boolean placeholder ocilsTypeOf AnyPlaceholder union port Port Port Abb 7 3 UML Datentypen zur Repr sentation von Por
47. 14 validateAgainstPort document state getInputPort 15 document execute state 6 validateAgainstPort document state getOutputPort 7 while not state is JoinState or state is FinalState 8 if this is parallel subsection then 19 notifyParentSection document 20 end if getFollowing state 21 if state is DecisionState then 22 states state getSuccessors 23 for i 1 to states length do 24 following states i 25 transition getUsedTransition following Transition ber die der Folgezustand erreicht wurde 26 guard transition getGuard 27 if quard isElse then 28 elseState following 29 else if quard isTrue then 30 return following 31 end if 32 end for 33 return elseStat 216 Kapitel 10 Ausf hrung von XML Prozessen 34 else if state is ForkState then 35 return state getCorrespondingJoinState 36 Si 37 else Zustand mit genau einer ausgehenden Transition 38 return state getSuccessor 39 end if execute state 40 if state is ForkState then 41 states state getSuccessors 42 for i 1 to states length do parallel 43 successor states i 44 transition getUsedTransition successor Transition ber die der Folgezustand erreicht wurde 45 if transition getGuard isTrue then 46 executeSection successor document clone 47 end if 48 end for 49 documents waitForSubSections 50 document create
48. 3 Modellierung der Dokumenttypen 113 Nachdem wir nun Ports und ihre grundlegenden Eigenschaften definiert haben fehlt noch die in Abschnitt 6 3 1 geforderte Teilmengen Beziehung mit der sich konsistente Portverkettungen berpr fen lassen F r einen Port wird die spezielle Teilmengen Relation c wie folgt definiert Def 6 9 Teilmengen Relation f r Ports Vp pz2e Ports P lt P2 lt Vt4 root subs1 e p1 3 t2 rootz subs2 e p2 root root v rootze AnyPlaceholder A subs c subs Ein Port hei t also Teilport eines anderen Port wenn es zu jedem Dokumenttyp einen Dokumenttyp im anderen Port mit gleichem Wurzelelement oder dem Platzhalter any und einer Menge von Unterelementen gibt die alle auch in der eigenen Menge von Unterelementen enthalten sind Beispiele Alp Bip q lt anylp Al Blq c A BI A p Bipgl anylp gl Al Blql z All Diese Port Relation soll benutzt werden um festzustellen ob zwei Ports zueinander kompatibel sind das hei t ob jedes Dokument das zur Dokumentmenge des einen Ports geh rt auch zur Dokumentmenge des anderen Ports geh rt Dass dies immer gegeben ist wenn eine Teilport Beziehung vorliegt zeigt der folgende Satz Durch ihn wird die Teilmengen Relation f r Ports zur zentralen Funktion um zwei Ports auf Kompatibilit t zu pr fen F r je zwei Ports gilt also der folgende Kompatibilit ts Sarz Satz 6 10 Kompatibilit ts Satz Vp4Pp2e Ports p c p2 gt L
49. 4 3 3 realisiert werden Dadurch wurde eine einfache Integration der vorhandenen Systeme m glich In diesem Abschnitt wollen wir die bisherige L sung mit sunShine und die Modellierungsm glichkeiten mit Prozessdiagrammen gegen berstellen Der Vergleich soll die Vorteile zeigen die eine visuelle Modellierungssprache bietet Dazu orientiert dich der Vergleich im Folgenden an den Basiskonstrukten f r Workflow Modelle Sequenz Prozessschachtelung bedingte Verzweigung und Parallelit t 238 Kapitel 11 Evaluierung anhand einer Fallstudie Sequenzen und Subprozesse Zur sukzessiven Verarbeitung der XML Dokumente wurde f r sunShine eine Vielzahl kleiner Pipelines definiert die in der Regel jeweils nur einen Verarbeitungsschritt des Gesamtprozesses abbilden Durch eine regelbasierte Steuerung wurden die einzelnen Pipelines dann zum Gesamt Workflow verkn pft Regelmaschine sunShine A B C Back End Systeme Pipelines oy Regelwerk A gt C gt B D gt E K gt G gt W A Abb 11 1 Regelbasierte Workflow Management Architektur mit sunShine Eine einzelne Pipeline erledigt normalerweise einen Prozessschritt indem sie das aktu elle Dokument aus dem Archiv l dt an einen Transformer zur Anbindung an die Back End Systeme weiterleitet das Ergebnis gegebenenfalls durch die Anwendung eines Stylesheets transformiert und dann wieder im Archiv ablegt Folgende Pipeline dient zum Beispiel zum Schreiben ei
50. Durch Verwendung des Elements lt service gt l sst sich ein Zustand mit dem UMIL Stereotypen serviceState beschreiben Neben der Transition zu einem Nachfol gezustand ohne Guard enth lt es ein Unterelement lt callservice gt mit dem ein Service aufgerufen wird In seinen Attributen component und method wird der Name eines Konnektors einschlie lich des Package sowie einer seiner Services ausgew hlt Diese Bestandteile m ssen selbstverst ndlich eine Entsprechung in der statischen PML Beschreibung des Package haben Zu jedem Parameter des ausgew hlten Service muss lt callservice gt ein Unterelement lt argument gt enthalten In seinem Attribut parameter gibt man an zu welchem Parameter es geh rt Als Textinhalt des Elements muss ein Ausdruck angegeben werden der vom Prozessinterpreter ausgewertet werden kann vgl dazu Abschnitt 10 2 4 lt service gt lt callservice component de sundn sunflowexamples IComponent1 method serviceA gt lt argument parameter parl gt lt argument gt lt callservice gt lt next gt lt next gt lt service gt Abb 8 18 Aufruf eines Service Synch Ein Synchronisationszustand wird durch das Element lt synch gt definiert Er ent h lt mittels lt next gt eine Transition zum zugeh rigen Synchjoin Zustand siehe unten die keinen Guard enthalten darf Synchfork Unter einem Synchfork Zustand verstehen wir einen UML Fork Zustand dessen einer Nachfolger
51. Einschr nkungen sondern lediglich Hilfsfunktionen zum Zugriff auf die Attribute Constraints context transitionType def let sourcePort Port self definedTag gt select name sourcePort typedValue referencedValue oclAsType Port let targetPort Port self definedTag gt select name targetPort typedValue referencedValue oclAsType Port 2 Einschr nkungen an die Transformationsfunktion Um die Anwendbarkeit des Migrationssatzes 6 18 sicherzustellen muss die durch das Tag transformation spezifizierte Transformationsfunktion die in Def 6 16 getroffenen Einschr nkun gen erf llen Erl uterung transitionType ist ein Stereotyp zur Definition von Transitionstypen Die Attribute sourcePort und targetPort spezifizieren die Schnittstellen einer typisierten Transitionen transformation die gegebenenfalls notwendige Konvertierungsfunktion zwischen diesen Ports Darstellung Da die Basisklasse des Stereotyps Classifier keine eigenen Darstellung hat wird ein transitionType in Anlehnung an eine Transition als Pfeil dargestellt versehen mit dem Zusatz transitionType und dem Namen des Classifiers Der Pfeil verbindet nicht zwei Zust nde sondern wird kontextfrei dargestellt Die Ports und die Transformationsfunktion werden im Prozessdiagramm nicht explizit gezeichnet M glich ist aber eine Darstellung als UML Kommentar oder ein Modellierungswerkzeug hat daf r zu sorgen dass sie passend repr sen tiert
52. Ha mespace Element Klame Element ame Abb 9 5 Eingabedialog eines Dokumenttyps 9 2 5 Konstruieren eines Prozesses Im vorausgegangenen Abschnitt wurden die einzelnen Teile der Benutzungsoberfl che und grundlegende Bedienungstechniken erkl rt Darauf aufbauend soll nun hier in einer Art Tutorial schrittweise erl utert werden wie sich mit Hilfe des Prozesseditors ein Workflow Modell entwerfen l sst Dazu muss zun chst der Editor gestartet und das gew nschte Projekt geladen oder neu angelegt werden siehe Abschnitt 9 2 1 Erzeugen neuer Konnektoren Wie bereits mehrfach erw hnt bestehen die statischen Bausteine von Prozessdiagram men aus Konnektoren und Transitionstypen Diese m ssen entweder vor der Modellie rung des Prozesses oder bei Bedarf definiert werden sofern nicht schon alle f r den Prozess ben tigten Komponenten existieren Falls sich das Package in dem ein neuer Konnektor oder Transitionstyp enthalten sein soll noch nicht im Projekt befindet muss 198 Kapitel 9 Modellierungswerkzeug f r Prozessdiagramme es zun chst geladen werden siehe Abschnitt 9 2 2 Um einen neuen Konnektor anzulegen bet tigt man mit der rechten Maustaste das Package im Projektbaum das den neuen Konnektor enthalten soll Es erscheint ein Popup Men in dem die Aktion New Connector gew hlt werden muss siehe Abbil dung 9 6 Der Editor legt dann einen neuen Konnektor an der sofort im Baum sichtbar wird und bereits selektier
53. Inamespace1 elemC b copyRoot_except http namespace2 elemC copySubs http Inamespace1 errorMessage Einbindung von Ports in Prozessdiagramme Eine Einbindung von Ports als grafische Elemente in UML Aktivit tendiagramme bzw die darauf basierenden Prozessdiagramme ist nicht einfach wenn gleichzeitige Einbu en bei der bersichtlichkeit vermieden werden sollen Grund daf r ist die doch recht technische und textlastige Notation mit Angabe von Namensr umen und Namen aller vorkommenden XML Elemente Vorstellbar w re es sie in Prozessdiagrammen als UML Kommentare an die entsprechenden Schnittstellen der Services und Aktivit ten anzuf gen In der Regel sollten sie aber intern von einem CASE Tool gespeichert und verwaltet werden Der Modellierer k nnte dann ber Eingabedialoge des Werkzeugs die Ports f r die einzelnen Schnittstellen spezifizieren Bleibt schlie lich noch die Frage zu kl ren wo berall im Prozessdiagramm und Workflow Modell Ports spezifiziert werden m ssen Vor allem f r jeden Service im statischen Modell ist jeweils ein Eingangs und ein Ausgangsport anzugeben Da bei einigen Services die Ausgabetypen offen sind aber von der Eingabe abh ngen k nnen f r den Ausgangsport eines Service offene Ports benutzt werden Im dynamischen Teil der Workflow Modelle hat prinzipiell jeder Zustand also jeder Knoten des Prozessdiagramms einen Eingangs und einen Ausgangsport Diese Notwendigkeit ergibt sich aus
54. Kapitel 11 hat gezeigt welches Potenzial in den entwickel ten Konzepten und Werkzeugen steckt Die Konzepte der Arbeit wurden bei der Imple mentierung vollst ndig umgesetzt so dass die erstellte Software nach geringen Optimie rungen in realen Projekten und Produkten eingesetzt werden kann Die Resonanz der Projektingenieure der S amp N AG die im Bereich E Business t tig sind war durchweg positiv und l sst in der Zukunft eine feste Integration der in dieser Arbeit entwickelten Konzepte in ihre Entwicklungsprozesse erwarten Da sich die Werkzeuge zur Modellie rung und Ausf hrung besonders f r die einfachere Entwicklung flexibler Pipelines eig net ist eine Integration in das Open Source Projekt Cocoon siehe Apa01 der Apache Organisation denkbar weil auch dieses Projekt auf der erw hnten Pipeline Architektur basiert In jedem Fall sind die gewonnenen Ergebnisse von solcher Praxis relevanz dass sie in Zusammenarbeit mit der S amp N AG weiterentwickelt und ent sprechend der im folgenden Ausblick angedeuteten Ideen fortgedacht werden sollen 250 Kapitel 12 Schlussbetrachtungen 12 2 Ausblick Aufgrund des beschr nkten Zeitrahmens einer Diplomarbeit konnten wir leider nicht alle Ideen und Aspekte ersch pfend betrachten und umsetzen Im Folgenden soll eine Reihe solcher offenen Fragen angedacht und erste berlegungen dazu angestellt wer den Es handelt sich aber nicht um fertige Konzepte sondern lediglich um Ideen wie eine m gl
55. Kombination aus Tran sitionstyp und Service oder Prozess aussuchen die dann im Diagramm erzeugt wird 204 Kapitel 9 Modellierungswerkzeug f r Prozessdiagramme ai Add Zucmeren Berite St be Subacinahr Stade Auallablae Buccessors Transition Type Sense ia de sundn prod suncima sunik ende Bankier drei Ale de sundr gris de sundn peod sunshina sundo aram pks Cra alaMail de sundn prod sunshine sunis aiarnmpias Mailing sandal unsne samika deae Danir daar Abb 9 12 Eingabedialog zum Erzeugen eines Folgezustands Das sukzessive Anwenden dieser Aktion ausgehend vom Startzustand erlaubt es dem Benutzer auf einfache und komfortable Weise konsistente Prozessmodelle zu entwer fen Besonders wenn nach einiger Zeit eine gr ere Menge von vordefinierten Services Transitionstypen und Sub prozessen zur Verf gung steht d rfte die Aktion ein sehr effizientes Modellieren erlauben Validieren von Prozessdiagrammen Der Benutzer kann jederzeit berpr fen ob sein Workflow Modell ein g ltiges Pro zessdiagramm darstellt Dazu w hlt er mit der rechten Maustaste den gew nschten Prozess im Projektbaum aus und ruft im Popup Men die Aktion Validate Process auf Der Prozesseditor berpr ft das Diagramm dann auf jede Art von Fehlern und Inkonsistenzen Dazu verwendet er den im Abschnitt 7 5 beschriebenen Validierungs algorithmus Anschlie end erscheint ein Ergebnisdialog in dem sich ggf Meldungen ber gefunde
56. Komponenten sollen durch den Workflow konfiguriert und in die E Business Umge bung integriert werden Dazu ist ein ausreichendes Ma an Interoperabilit t der beste henden Systeme mit dem WFMS und der E Business Plattform erforderlich Zur Kopplung der Komponenten m ssen mit ihnen Daten ausgetauscht werden die in einem anwendungsneutralen Format vorliegen m ssen In dieser Arbeit wollen wir dazu den derzeitigen Standard XML zu Grunde legen und untersuchen wie sich XML Konstrukte und Technologien in das Workflow Management integrieren lassen In diesem Zusammenhang wird davon ausgegangen dass ein Workflow seine Workflow relevanten Daten durch Eingabe eines XML Dokumentes erh lt und sein Ergebnis ebenfalls als XML Dokument zur ckliefert Wenn diese Verarbeitung der Dokumente intern durch den Fluss des Dokumentes durch die einzelnen Verarbeitungsaktivit ten realisiert wird wollen wir im Folgenden von einem XML Prozess sprechen F r die Konzeption und Realisierung von XML Prozessen sei auf die Kapitel 6 und 7 verwie sen 34 Kapitel 3 Anforderungsanalyse Ein besonderes Augenmerk wird auf der Modellbildung von Workflows liegen Insbesondere sollen schon bei der Modellierung die Eigenheiten von XML Prozessen das sind vor allem die Einbindung von Softwarekomponenten und die Verarbeitung von XML Dokumenten ber cksichtigt werden Darum muss eine Modellierungssprache gefunden werden mit der sich Modelle der XML Prozesse als sogenannte
57. Konnektoren konkrete Implementierungen vorliegen Das WFMS muss deshalb in der Lage sein zur Laufzeit eine Instanz f r jeden in dem Workflow Modell verwendeten Konnektor zu erzeugen Dazu m ssen Informationen ber die verf gbaren Konnektorklassen vorhanden sein sowie eine Abbildung die die Repr sentanten des statischen Modells auf konkrete Konnektorimplementierungen abbildet Auf der Ausf hrungsebene werden die abstrakten Elemente der Modellebene also an konkrete Instanzen gebunden Vorteile der Abstraktion und Modellbildung sind ein besseres Verst ndnis der Zusammenh nge und Prozesse was vor allem durch grafische Modelle gef rdert wird Bei genauer Spezifikation der Schnittstellen lassen sich Planungen Simulationen und Optimierungen bereits durchf hren auch wenn die konkrete Implementierung einer Softwarekomponente oder eines bestimmten Konnektors noch nicht vorhanden ist Ohne Tests mit den echten Komponenten durchf hren zu m ssen kann man bereits anhand des Workflow Modells Fehler und Konsistenzbr che feststellen Vor allem wird durch die Abstraktion aber eine hohe Wiederverwendbarkeit der Modelle gew hrleistet ndert sich etwas an der internen Implementierung einer konkreten Komponente bzw eines Konnektors so m ssen nicht alle Workflow Modelle ge ndert werden die diese Komponente benutzen So lange weiterhin die spezifizierte Schnittstelle von der Kom ponente angeboten wird Kann die Implementierung beliebig ausgetauscht un
58. Menge XmlDocs enth lt somit alle XML Dokumente die entsprechend XML00 Abschnitt 2 1 wohlgeformt und nach XML00 Abschnitt 2 8 g ltig bez glich ihrer Typdeklarationen DTD XML Schemata sind Au erdem sind f r Elemente dieser Menge folgende Funktionen definiert r XmIDocs gt XmilElements V doc e XmlIDocs r doc w amp w ist Wurzelelement von doc c XmIDocs P XmilElements y doc e XmlIDocs c doc x e XmlElements x ist in doc enthalten Die Funktion r root liefert also das Wurzelelement der Baumstruktur zur ck die sich aus einem XML Dokument ergibt Die Funktion c content liefert alle XML Elemente die in dem Dokument enthalten sind 6 3 Modellierung der Dokumenttypen 111 Def 6 3 Der any Platzhalter AnyPlaceholder any Die Menge AnyPlaceholder enth lt als einziges Element das Schl sselwort any zur Repr sentation eines beliebigen XML Elements Bei der folgenden Definition der Dokumenttypen kann dieser Platzhalter anstelle eines Wurzelelements benutzt werden Syntax Der any Platzhalter wird in der EBNF Grammatik durch das Terminal Symbol any repr sentiert Def 6 4 Die Menge der Dokumenttypen DocTypes root subs root e XmIElements U AnyPlaceholder subs c XmlElements XmlElements U AnyPlaceholder x P XmlElements Ein Element aus der Menge DocTypes beschreibt den Typ eines XML Dokumentes durch Angabe des ben tigten Wurzelelementes und obligatorisch enthaltener
59. Menge m glicher Nachfolger einer Aktivit t mit einem bestimmten Ausgangsport eingeschr nkt Um von Anfang an Konsistenzbr che und damit fehlerhafte Modelle zu vermeiden sollte ein Modellierungswerkzeug f r Prozessdiagramme den Modellierer daran hindern von einem Port x eine Transition zu einem Port y zu ziehen wenn weder x lt y gilt noch ein Stylesheet vorhanden ist das die Inkompatibilit t zwischen x und y durch Transformation der Migrationsdokumente berbr cken k nnte M chte der Modellierer trotzdem x und y durch eine Transition verbinden m sste er zuerst ein solches Stylesheet anlegen um die Verbindung ber haupt zu erm glichen hnlich wie bei dem Ziel der Wiederverwendbarkeit ist es somit 106 Kapitel 6 XML Prozesse und Prozessdiagramme auch f r die automatisierte Konsistenzunterst tzung notwendig dass eine Sammlung von Portpaaren jeweils zusammen mit einem Stylesheet verwaltet wird Typisierte Transitionen Die angesprochene und als notwendig angesehene Sammlung von Stylesheets in Verbindung mit Portpaaren k nnte Bestandteil des statischen Modells von Prozess diagrammen werden so dass sie an beliebigen Stellen in Prozessdiagrammen wieder verwendet werden k nnen Im Prozessdiagramm werden sie dann jeweils einer Transi tion zugeordnet die gerade diese Ports miteinander verbinden soll Man kann davon ausgehen dass jede Transition mit einer solchen Transformationsvorschrift ausgestattet wird Wenn keine Transfor
60. Petri Netz mit den folgenden Erweiterungen Jeder Stelle ist ein GXSL Schema also eine DTD zugeordnet die den Typ der zul ssi 5 2 Ereignisgesteuerte Prozessketten 59 gen Dokumente spezifiziert Daher k nnen Stellen als Container f r XML Dokumente interpretiert werden welche g ltig bez glich der zugeordneten DTD sind Der Fluss von XML Dokumenten durch das Netz entsteht durch das Schalten von Transitionen Jede Kante zwischen einer Stelle und einer Transition besitzt ein gegen ber dem Schema der Stelle erweitertes GXSL Schema Nur XML Dokumente in der Stelle die dem erweiterten GXSL Schema entsprechen k nnen von der Transition verarbeitet werden Auf diese Weise lassen sich Verzweigungsbedingungen realisieren Jeder Kante zwischen einer Transition und einer Stelle ist ein XManiLa Ausdruck zugeordnet Dabei handelt es sich um eine grafische Sprache zur Spezifikation von Manipulationen an XML Dokumenten Beim Schalten der Transition werden die so beschriebenen nderungen an dem zu verarbeitenden XML Dokument vorgenommen XML Netze sind f r die Modellierung der XML Prozesse aus einigen Gr nden nicht optimal geeignet In XML Prozessen soll die Manipulation der Daten nicht im Modell spezifiziert werden Es wird lediglich angegeben welche Softwarekomponente die Daten verarbeiten soll Dabei ist f r jede Komponente bekannt welche Anforderun gen sie an ihre Eingabedaten stellt und welche Ausgabedaten sie erzeugt Was genau intern gesc
61. Ports f r die einzelnen Zust nde im Prozessdiagramm bleibt dem Benutzer erspart Lediglich bei den Service Aktivit tszust nden kann der Benutzer noch Anpassungen 7 6 Automatische Portberechnung 157 gem Abschnitt 6 3 1 vornehmen Der folgende Abschnitt erkl rt die Realisierung der automatischen Portberechnung anhand des daf r implementierten Algorithmus Der Algorithmus kann f r den Benutzer transparent von einem Modellierungs werkzeug aufgerufen und so das gerade bearbeitete Prozessdiagramm st ndig in einen bez glich der Ports Konsistenten Zustand gebracht werden vgl Abschnitt 9 1 Da beim Einsatz offener Ports vgl Abschnitt 6 3 1 und deren Bindung sowie bei den Ports von Zusammenf hrungszust nden wie merge und join das Ergebnis der Portberechnung vom Kontext abh ngt in dem sich die Zust nde befinden und sich die nderung eines Ausgangsports sukzessive auf nachfolgende Zust nde auswirken kann sollte die Port berechnung jeweils neu angesto en werden wenn sich der Diagrammkontext durch Hinzuf gen oder L schen einer Transition ge ndert hat Eine solche Neuberechnung ist auch ratsam wenn der Benutzer Portvorgaben im statischen Modell ndert da dies immer auch Auswirkungen auf die Ports in denjenigen Workflow Modellen hat in denen diese statischen Elemente wie Services und Transitionstypen benutzt werden Im Folgenden wird das Vorgehen bei der Portberechnung etwas n her skizziert Dabei wird zwar davon ausgegangen d
62. Sie implementiert die beiden geforderten Methoden indem sie sich intern das Dokument merkt Es gibt nun zwei M glichkeiten eine Konnektor Klasse zu reali sieren Die bequemste Variante ist es diese von der Klasse AbstractXMLConnector 234 Kapitel 10 Ausf hrung von XML Prozessen erben zu lassen Sie muss dann lediglich die Service Methoden enthalten die vom Konnektor Interface hier IKonnektorl und IKonnektor2 gefordert werden Sie haben ber die geerbte Methode getXmlDocument jederzeit Zugriff auf die XML Daten vgl Konnektorl Falls dies nicht m glich ist weil beispielsweise die Konnektor Klasse bereits eine Oberklasse besitzt muss sie das Interface IXMLConnector direkt implementieren Neben den Service Methoden muss sie dann auch die beiden Methoden des Interface in geeigneter Weise realisieren vgl Konnektor Zugriff auf die Prozessumgebung Im Abschnitt 6 2 2 wurde beschrieben dass es eine Prozessumgebung geben kann in der sich zus tzliche Daten befinden Es kann nun prinzipiell vorkommen dass ein Konnektor nicht nur ber ggf vorhandene Service Parameter sondern direkten Zugriff auf diese Prozessumgebung ben tigt In einem solchen Fall muss der Konnektor zus tzlich zu IXML Connector auch das Interface EnvironmentDependent und damit die Methode setEnvironment implementieren Der Prozessinterpreter bergibt ihm dann vor Aufruf des Service mit Hilfe dieser Methode eine Instanz der Klasse AbstractEnvironment di
63. Sprachelemente die seltener zum Einsatz kom men sie seien hier jedoch kurz erw hnt Zum einen k nnte sich die Frage stellen wel che Systemkomponente f r die Ausf hrung einer bestimmten Aktivit t zust ndig ist Um dies im Diagramm darzustellen verwendet man vertikale Bahnen engl swim lanes von denen jede genau einer ausf hrenden Komponente zugeordnet ist Alle Aktivit ten die von dieser ausgef hrt werden erscheinen dann innerhalb der entspre chenden Bahn Des Weiteren gibt es in Aktivit tendiagrammen Elemente um explizit das Senden und Empfangen von Signalen auszudr cken Laut OmgOl 3 91 und 3 91 2 l sst sich dies jedoch auch durch gew hnliche Aktivit ten realisieren Schufa Beauftragter Sachbearbeiter Kredit Abteilung Filialleiter Kundendaten erfassen 21 Kundendaten Kunde beurteilen Konditionen i bestimmen 30 0000M _ Filialleiter lt 30 000DM beurteilt akzeptiert Schufa Anfrage stellen lehnt ab SE A DEEDE BEE EAER EEEE DES EEE BEE SR EREE ENGEN Schufa negativ Kredit Kredit ablehnen gew hren Abb 5 10 Beispiel eines UML O EE o ka positiv 5 3 UML Aktivit tendiagramme 69 5 3 2 Gesch ftsprozessmodellierung mit UML Die UML enth lt neben Aktivit tendiagrammen eine Reihe weiterer grafischer Spra chen die sich f r die Modellierung von Gesch ftsprozessen unterschiedlich gut eignen vgl
64. Unter elemente Der Platzhalter any aus der Menge AnyPlaceholder kann alternativ zum Wurzelelement gesetzt werden und steht f r ein beliebiges XML Element Syntax Ein Element aus DocTypes wird durch Ableitung des Nicht Terminals Doctype der EBNF Grammatik notiert Sei dazu ein beliebiger Dokumenttyp type gegeben mit type root subs DocTypes und subs s sn Dann schreibt man den Ableitungsregeln der Grammatik entsprechend root S1 sn Beispiele any http namespacel elementA http namespace 2 elementB http namespace3 elementC http namespace3 elementC http namespace2 elementB Die zu einem Dokumenttyp konformen Dokument Instanzen sind definiert durch Def 6 5 Dokumentmenge eines Dokumentsyps L DocTypes gt P XmiDocs Y type root subs e DocTypes L x subs falls roote AnyPlaceholder L type lt xe XmlElements doc e XMLDocs r doc root a subs c c doc sonst L type hei t Dokumentmenge vom Typ type Die Funktion L liefert also alle Doku mente die einer Typspezifikation aus DocTypes gen gen Dazu muss ein Dokument das angegebene Wurzelelement besitzen und alle in subs angegebenen Unterelemente enthalten Ist subs amp entspricht L type der Menge aller g ltigen XML Dokumente mit dem Wurzelelement root Ist root e AnyPlaceholder bzw root any Kann die 112 Kapitel 6 XML Prozesse und Prozessdiagramme Dokumentinstanz ein beliebiges XML Element als Wurzel bes
65. Unternehmensaktivit ten an betriebswirtschaftlichen Gesch ftsabl ufen soll die Effizienz und Produktivit t des Unternehmens erh hen Diese Gesch ftsprozesse durch Informationssysteme unterst tzen zu lassen ver spricht weitere Produktivit tssteigerungen bedarf aber auch einer Kombination von Workflow Management und Integration der betrieblichen Softwaresysteme 3 Wie berwindet man beim Kontroll und Datenfluss Systemgrenzen ohne vermeid baren Ressourcenverbrauch Sollen die heterogenen Systeme gekoppelt werden m ssen sie Daten miteinander austauschen k nnen so verarbeitet vielleicht der Dienst des einen Systems die Resultate des anderen Systems Ohne Integration w rden daf r zus tzliche Ressourcen und Zeit ben tigt weil zum Beispiel das Personal die Daten manuell vom einen System in das andere bertragen m sste Besser w re es wenn solche Kontroll und Datenfl sse m glichst automatisiert abliefen und manuelle Interventionen der Benutzer vermieden werden k nnten 4 Wie bietet man den Kunden und Partnern flexible Zugangsm glichkeiten zu den eigenen Systemen an Sind die eigenen Systeme und Prozesse nach der Integration ber das Internet aufrufbar sollte dies mit den verschiedensten Endger ten und Protokollen m glich sein um eine m glichst gro e Zahl von Anwendern zu errei chen Neben den blichen Web Browsern ist in Zukunft mit einem gro en Bedarf an Unterst tzung mobiler Ger te zu rechnen Au erdem sind neben m
66. Workflow Modellen repr sentiert eine bestimmte Softwarekomponente die Transformationen auf den XML Daten und gegebenenfalls andere Aktionen wie das Versenden von Nachrichten oder Datenbankbefehle ausf hrt Mit der Modellierungssprache m ssen solche Aktivit ten in den Workflow eingef gt wer den k nnen Transitionen modellieren den Kontrollfluss zwischen den einzelnen Aktivit ten Wenn bestehende Applikationen in einen Workflow integriert werden m ssen bei ihrem Aufruf komplexe Startparameter bergeben werden siehe B h95 S 15 Die Modellierungssprache muss es daher erm glichen Parameterein stellungen f r eine Aktivit t bzw die mit ihr korrespondierende Softwarekompo nente anzugeben Die den Parametern zugewiesenen Werte sind entweder statisch oder aus den verf gbaren XML Daten entnommen Dazu muss auf eine Stelle im XML Dokument verwiesen werden k nnen Einer Aktivit t kann auch ein schon definierter Workflow zugeordnet werden Somit muss es mit der Modellierungssprache m glich sein die Prozesse in einer hierarchischen Struktur zu schachteln Diese M glichkeit sorgt nicht nur daf r dass die Modelle von komplexen Prozessen bersichtlich und beherrschbar blei ben vgl Aal97 sondern erm glicht auch das Einbinden von bereits vordefi nierten Elementarprozessen Beim Erreichen einer solchen Aktivit t bei der Aus f hrung des Workflows wird der Teil Workflow wie ein Makro aufgerufen Die Akteure innerhalb ein
67. XML Eingabedokument XML Prozess Interpreter aa 4 A amp Software Komponenten i Back End Systeme Abb 6 3 Die Architektur des WFMS f r XML Prozesse Der Prozessinterpreter erh lt als Eingabe die Beschreibung eines Prozesses in PML sowie ein Eingabe Dokument auf dem eine Instanz des gew hlten Prozesses ausgef hrt werden soll Durch die Speicherung der Prozessdefinition in PML ist es nicht nur m g lich die Spezifikation aus einer Datenbank oder Prozessbibliothek zu entnehmen son dern es ist auch vorstellbar die Prozessbeschreibung in das XML Eingabedokument zu integrieren Somit kann jemand der einen ganz speziell von ihm gew nschten Prozess ausf hren lassen m chte diesen Prozess selbst entwerfen und als PML zusammen mit den Eingabedaten an den Prozessinterpreter zur Ausf hrung bergeben Der Prozessinterpreter ist das zentrale Element dieses Workflow Management Systems Er muss die PML Spezifikationen interpretieren die einzelnen Teilprozesse ansto en und synchronisieren das XML Eingabedokument entsprechend dem Prozess modell von Komponente zu Komponente weiterleiten und so f r die Integration der verschiedenen Softwarebausteine sorgen Wie im vorausgegangenen Abschnitt vorge stellt werden die Komponenten dabei ber ihre Konnektoren angesprochen Ziel der Arbeit ist auch die Integration des Prozessinterpreters und der zugeh rigen Werkzeuge in eine E Business Plattform um damit f r web
68. aber auch propriet ren Datenformaten denkbar Bei der Ausgabe des Ergebnisdokuments wird eine flexible Unterst tzung verschiedener Formate verlangt um den Anwender in der Vielzahl m g licher Endger te nicht einzuschr nken Derzeit vorgesehen sind HTML Seiten f r Web Browser E Mails XML Daten bis hin zu WML f r WAP f hige Handys Man spricht in diesem Zusammenhang auch von Multi Channel L sungen Die E Business Plattform steht nicht unabh ngig von den existierenden Syste men da Vielmehr soll sie eine Br cke zwischen den neuen Kommunikationsm glich keiten und den bestehenden Anwendungen schlagen Zu den wichtigsten Anforderun gen z hlt daher eine gute Einbindung und Integration der bereits vorhandenen Back End Systeme und Softwarekomponenten Bei der Realisierung der Plattform sollen derzeitige und zuk nftige Standards und Technologien ber cksichtigt werden Dies garantiert eine m glichst lange Lebens dauer des Systems und die Nutzung des aktuellen Stands der Technik Explizit gefordert 3 1 Fallstudie E Business Plattform eines gro en Finanzunternehmens 25 wird in diesem Zusammenhang der Einsatz von Java und XML als Kerntechnologien Java als Programmiersprache und XML als Grundlage der Datenformate eignen sich beide f r heterogene Umgebungen da sie sich durch hohe Plattformunabh ngigkeit auszeichnen Die E Business Plattform wird eine solche heterogene Umgebung dar stellen da verschiedene Systeme eingebunden werden m
69. amp N AG mit der die Diplomarbeit in intensiver Zusammenarbeit praxisnah und als Gruppenarbeit erstellt wurde Die S amp N AG ist vor allem als IT L sungsanbieter im Bereich Finanzdienstleistungen t tig und legt in j ngster Zeit einen neuen Schwerpunkt auf die Entwicklung von E Business Systemen unter Einsatz von XML und Open Source Technologien Aus den Erfahrungen des Unternehmens lie en sich Anforderun gen ableiten deren Erf llung zur praktischen Einsetzbarkeit der in dieser Arbeit entwi ckelten Konzepte und Systeme wesentlich beigetragen hat Die vorliegende Arbeit gliedert sich in drei Teile Der erste Teil umfasst die Kapitel 2 bis 5 und behandelt zun chst Workflow Management und Softwareintegration im Allgemeinen Nach der Besch ftigung mit den Grundlagen werden in einer Fall studie die besonderen Anwendungsm glichkeiten im E Business sichtbar Die sich daraus ergebenen Anforderungen dienen als Grundlage f r die sich anschlie ende Eva luierung ausgew hlter vorhandener Systeme Besonderes Augenmerk liegt dabei auf der M glichkeit Workflows durch ausf hrbare grafische Modelle zu definieren anstatt sie zu programmieren In diesem Kontext werden bekannte visuelle Modellierungs sprachen wie Petri Netze Ereignisgesteuerte Prozessketten und UML Aktivit ten diagramme auf ihre Brauchbarkeit f r diese Anwendung untersucht Im zweiten Teil der mit den Kapiteln 6 bis 8 den wichtigsten Teil der Arbeit darstellt werden die selbst
70. beispielsweise das Verz gern des Ablaufs um ein bestimmtes Zeitintervall Im Abschnitt 8 1 wurde gefordert dass Aktio nen parametrisierbar sein m ssen Zwar ist es in XLANG m glich zu einer Operation eine Menge von Parametern zu definieren als Werte k nnen jedoch nur Inhalte der Nachrichten bergeben werden die bei Ausf hrung der Operation ausgetauscht werden Die Aktionen einer Prozessbeschreibung k nnen durch verschiedene XML Elemente zu beliebigen Abl ufen aggregiert werden XLANG kennt zu diesem Zweck Kontrollfluss konstrukte wie sie aus Programmiersprachen bekannt sind Tabelle 8 1 zeigt die wich tigsten XLANG Elemente F r eine detaillierte Beschreibung aller Sprachelemente sei auf Tha01 verwiesen XML Element Kontrollfluss lt xlang sequence gt Sequenz lt xlang switch gt bedingte Verzweigung lt xlang all gt Parallele Ausf hrung lt xlang while gt Iteration lt xlang exception gt Fehler bzw Ausnahmebehandlung Tab 8 1 Sprachelemente von XLANG Es ist in XLANG nicht m glich Ablaufbeschreibungen graphorientiert anzugeben d h als Menge von Aktionen mit Transitionen untereinander Ebenfalls kann f r den ber gang von einer Aktion zur n chsten keine Typisierung der Transition angegeben werden Dies w re jedoch zur Umsetzung des Konzepts der typisierten Transitionen unbedingt notwendig Um eine Schachtelung von XLANG Beschreibungen zu errei chen k nnen lediglich XLANG Elemente in ein and
71. cken der linken Maustaste der Zustand selektiert werden von dem die Transition ausgehen soll Anschlie end wird der Zielzustand der Transition bestimmt indem er bei gedr ckter Shift oder Strg Taste mit der linken Maustaste angew hlt wird Nun muss die Schaltfl che links oben in der Zeichenfl che bet tigt werden Es erscheint dann der folgende modale Dialog Eill nate maw vos Iranen Saure Sale Target Sirie Deris on Etale Final State Swap Fosskla Tanstion Typos EEE Garn i KPaih Egrbsson Abb 9 11 Eingabedialog zum Erzeugen einer Transition Oben im Dialog wird der Quell und Zielzustand der anzulegenden Transition ange zeigt Die beiden Zust nde lassen sich mit Hilfe von Swap vertauschen falls sie in der falschen Reihenfolge markiert wurden Darunter muss der gew nschte Transitions typ ausgew hlt werden Durch das Konzept der Ports ist es dem Editor hier m glich zu pr fen welche Typen an dieser Stelle des Prozesses berhaupt einsetzbar sind Nur sol 9 2 Bedienung des Prozesseditors 203 che werden in die Auswahlliste des Dialogs aufgenommen und stehen daher zur Verf gung Eingesetzt werden d rfen Typen genau dann wenn die resultierende Transition eine Transition im Sinne von Def 6 17 siehe Abschnitt 6 3 3 ist Der Migrationssatz 6 18 Abschnitt 6 3 3 besagt dass in diesem Fall die Verwendung des jeweiligen Tran sitionstyps zu einer konsistenten Portverkettung f hrt Es
72. cs00s00000s0000ss00nsssennssnennsssnnnsssennsnsssnsssnsnnnee 211 10 1 Semantik von Prozessdiagrammen u02220sssssesssnsensnnnensennnnnnnnennn nn 211 10 2 Der Brozessinterpreter ohren Bee Be 217 10 2 1 Interne Datenstruktur zum Zugriff auf Prozessmodelle 217 10 2 2 Ausf hrende Klassen rannte asian ea he 219 19 23 Synchronisationsmechanismus nase 222 10 24 Auf von SeIvioessuseae ni EEEN S EEES S 223 10 3 x Fehlerbehandime un ee es ae 225 10 3 1 Fehlertoleran2 u 2uu unne aa 226 10 3 2 _ Explizite Modellierung von Fehlerbehandlungen 227 10 4 Transaktionale Prozessausf hrung 0u002200sssnenennnensnnnenennnnnnn nn 228 10 4 1 Eigenschaften von Transaktionen eeseseeeseeeseseesesressessrseresresseseresresss 228 10 4 2 Transaktionen in XML Prozessen sssesssessesssesseseessresseessessereseeeessees 229 10 4 3 Fehler bei der Ausf hrung von Services uuennensnersnenneennnersnersnne nn 230 10 4 4 Ausfall des Prozessinterpreters 22200022000snsnneennnesnnnesnnnnnennnnnennnennnnn 231 10 5 Entwicklung von Konnektoren uuursssesssseessnnenssnnensnnnennnnnennnnnennn nn 233 10 6 Integration insunshine 22 22 a ii a 235 10 6 1 Der Suntlow Transtormer enter 235 10 6 2 sunShine Prozessumgebung ssssessssessessseessereseetesseessresseesseeesseeessees 235 11 Evaluierung anhand einer Fallstudie
73. dem in Abschnitt 6 3 2 vorgestellten Konzept der typi sierten Transitionen Dabei wird n mlich vorausgesetzt dass eine Transition stets zwei Ports miteinander verbindet Auf den Zusammenhang von Ports und Transitionen wird dort im Detail eingegangen An dieser Stelle wollen wir die verschiedenen Zustands typen des Prozessdiagramms betrachten Am wichtigsten sind dabei sicherlich die gew hnlichen Aktivit tszust nde in denen bei Prozessdiagrammen jeweils ein Service aufgerufen wird F r die Ein und Ausgangsports der Aktivit tszust nde werden die Ports des angesprochenen Service aus dem statischen Modell bernommen Dabei wird 6 3 Modellierung der Dokumenttypen 101 der offene Ausgangsport des Service an den gem dem Kontrollfluss vorausgehenden Ausgangsport gebunden In einem vollst ndigen Prozessdiagramm sind daher alle offenen Ports durch Bindungen in nicht offene Ports umgewandelt Dem Modellierer bleibt f r einen Aktivit tszustand die M glichkeit die aus dem statischen Modell vorgegebenen Ports einzuschr nken Dies ist zum Beispiel sinnvoll wenn der Eingangsport eines Service vom Wert eines Parameters abh ngt Da Para meterbelegungen im statischen Modell noch nicht bekannt sind bleibt dort unter Umst nden nur das Setzen des unbeschr nkten Ports mit any Im Aktivit tszustand w rde dieses any zun chst aus dem statischen Modell bernommen k nnte aber vom Modellierer durch einen spezifischeren Teilport ersetzt werden w
74. denkbar woher solche Angaben stammen k nnen Aufgrund dessen ist es notwendig zus tzlich zum Wert eines Parameters anzugeben auf welche Variante er sich bezieht Statische Werte Zum einen ist es m glich dass die Werte von Parametern bereits zum Zeitpunkt der Modellierung des Prozesses bekannt sind Dabei k nnte es sich z B um einen Server mit einer festen Adresse handeln von dem Daten angefordert werden sol len oder eine ganz bestimmte E Mail Adresse die eine Nachricht erhalten soll Solche Informationen k nnen fest in der Prozessbeschreibung verankert und vom Prozessinter preter bei der Ausf hrung an den Service der Komponente bergeben werden Werte aus dem XML Dokument Weiterhin k nnen sich die ben tigten Werte in dem XML Dokument befinden das durch den Prozess wandert Dort k nnte beispielsweise eine Liste von E Mail Adressen vorliegen die alle eine Nachricht erhalten sollen Um auf bestimmte Stellen innerhalb eines XML Dokuments zuzugreifen dient die Sprache XPath siehe XPath99 Bei der Modellierung des Prozesses muss f r jeden Parameter ein XPath Ausdruck angegeben werden der festlegt wo sich zur Laufzeit die Daten befinden werden Der Prozessinterpreter kann dann bei der Ausf hrung die Daten mit Hilfe eines XPath Prozessors aus dem XML Dokument auslesen und an die Kompo nente bergeben Neben XPath sind auch andere Anfragesprachen f r XML Daten wie XQL siehe XQL98 oder XQuery siehe XQueryOl denkbar die
75. die Nachrichtenformate siehe Mic00 S 3 Das BizTalk Konzept von Microsoft besteht im Wesentlichen aus den drei Teilen BizTalk Framework der Internetplattform BizTalk org und den BizTalk Servers Ziel ist es mit diesen Systemen eine Infrastruktur f r unternehmensinterne wie bergreifende Integration von Anwendungen und Gesch ftsprozessen durch den Aus tausch von Daten in wohldefinierten und unter den Teilnehmern abgestimmten XML Formaten anzubieten 36 Kapitel 4 Evaluierung vorhandener Workflow Systeme BizTalk Framework Das BizTalk Framework definiert Regeln zur Erzeugung von BizTalk konformen XML Schemata die die Struktur von austauschbaren Nachrichten festlegen vgl Moh01 S 14f Das Konzept basiert auf dem XML Standard und dem offenen Nach richtenaustauschprotokoll SOAP Simple Object Access Protocol siehe SOAPO1 das vom W3 Konsortium zum Informationsaustausch und Funktionsaufruf in heterogenen verteilten Umgebungen standardisiert worden ist Damit ist es nicht mehr n tig f r die verschiedenen Anwendungen Interoperabilit t durch gemeinsame Protokolle gleiche Programmiersprachen gleiche Betriebssysteme und hnlichem herzustellen Dieser Ansatz scheitert allein durch die Heterogenit t der eingesetzten Systeme Die Zusam menarbeit der Applikationen soll bei BizTalk vielmehr auf dem Aufruf von Funktionen durch das Erzeugen und Versenden einer XML Nachricht beruhen Der Empf nger in diesem Fall ein BizTalk Server
76. die Workflow Modelle als Akteure eingebunden werden Bei der Ausf hrung der Modelle werden sie dann an reale Komponenten oder Objektinstanzen gebunden siehe 3 2 Anforderung 7 Vorteil dieses Verfahrens ist die hohe Flexibilit t durch die dynamische Bindung zur Laufzeit und die leichte Erweiterbarkeit weil sich einfach neue Konnektoren in die Bibliothek der vorhandenen Konnektoren einf gen lassen um so neue Back End Systeme zu integrieren Als weiteres Ziel der Diplomarbeit sollte untersucht werden welche M glich keiten und Vorteile die Benutzung von XML Dokumenten bringen k nnte weil XML gerade im Bereich E Business weit verbreitet ist und sich als plattformneutrales Daten format f r den Datenaustausch in heterogenen Systemen gut eignet Die Anforderungen der Fallstudie siehe 3 1 haben die Praxisrelevanz von XML gezeigt Dort wurde ex plizit der Einsatz von XML gefordert Dieser Wunsch wurde auch f r unseren Ansatz bernommen und ein Konzept XML basierter Workflows entwickelt Dabei werden die zuvor genannten Konnektoren als Akteure in Workflow Modellen angeordnet die jeweils ein XML Dokument verarbeiten und das Ergebnis ihrerseits als XML Doku ment weiterreichen Dies f hrt zum Konzept der Dokumentmigration siehe 6 1 bei dem die Kontrollfl sse eines Workflows gleichzeitig den Datenfluss eines XML Migrationsdokuments implizieren Dieses Migrationsdokument enth lt alle Workflow relevanten Daten siehe 3 2 Anforderung 4 und tran
77. die auf Eingaben des Benut zers bzw Ereignisse in der Oberfl che reagiert In unserem Fall besteht das Model aus den Klassen des Datenmodells siehe Abschnitt 7 4 die Views aus den Eingabemasken und die Controller aus sogenannten ActionListener Klassen die die Benutzeraktionen auswerten F r jeden Knotentyp des Projektbaums gibt es eine MVC Einheit Im Folgenden soll die Umsetzung des Konzepts f r Services erl utert werden f r alle anderen Datenklassen gibt es analoge Bestandteile im Prozesseditor so dass diese Klassenstruktur das zentrale Muster innerhalb des Editors ist Abbildung 9 14 zeigt die Klassen zur Verwaltung eines Service javax swing JPanel A View javax swing ServicePanelView AbstractModel tree TreeNode ElementAdapter interface updateView Void IN A java awt event inputlsConsistent Boolean ActionListener savelnput Void interface J AbstractTreeNodeAdapter N A listensTo gt current gt ServiceAdapter children Enumeration getAllowsChildren Boolean ServiceActionListener actionPerformed event ActionEvent Void Controller Model Abb 9 14 MVC Klassen f r Services 9 3 Implementierung des Prozesseditors 207 Model Das Model besteht aus der Klasse ServiceAdapter die einen Service repr sentiert Es kann hier nicht direkt die Klasse Servic
78. die jeweils eine logische Einheit bilden wie beispielsweise zur Definition aller Elemente eines bestimmten Diagrammtyps Im folgenden Abschnitt sollen die wichtigsten Bestandteile des Metamodells vorgestellt werden die relevant f r Aktivit tendiagramme sind und f r die Erstellung von Prozessdiagrammen erweitert werden m ssen 7 1 2 Metamodell f r Aktivit tendiagramme Aktivit tendiagramme werden in der UML Spezifikation als Spezialfall von Zustands maschinen angesehen Aus diesem Grund beruht auch ihre Definition im Metamodell auf der von Zustandsmaschinen welche um zus tzliche Elemente erg nzt wird Abbil dung 7 1 zeigt einen Ausschnitt aus dem abstrakten Syntaxgraphen des Metamodells mit den wichtigsten Meta Elementen von Aktivit tendiagrammen 1 outgoing 0 ER 1 0 1 StateVertex Transition Guard A 1 incoming gbard PseudoState State I 0 1 StateMachine A 0 1 entry i 0 1 CompositeState SimpleState Action ActivityDiagram BR p p yb ag 0 ObjectFlowState ActionState CallAction UninterpretedAction Abb 7 1 Metamodell f r Aktivit tendiagramme Danach besitzt jede Zustandsmaschine StateMachine und damit auch jedes Aktivit tendiagramm genau einen Zustand State in der obersten Ebene vgl Omg01 2 152 Bei Zust nden werden zwei Arten unterschieden CompositeState und SimpleState Ein CompositeState besitzt
79. diesem Zweck mussten eine Reihe weiterer sunShine Komponenten ber die Klasse SunshineEnvironment bekannt gemacht werden da sie von den vorhandenen Transformern ben tigt werden Es ist uns auf diese Weise gelun gen tats chlich jeden beliebigen Transformer mit Hilfe von Konnektoren als Aktivit t in ein Prozessdiagramm integrieren zu k nnen 11 1 Vergleich der L sungsans tze 237 11 Evaluierung anhand einer Fallstudie Zu Beginn der Diplomarbeit wurde in Abschnitt 3 1 eine Fallstudie durchgef hrt die die Anforderungen der Deutschen Bausparkasse Badenia AG an eine E Business Plattform behandelt die in diesem Finanzdienstleistungsunternehmen installiert werden sollte Die S amp N AG hat unter Einsatz ihrer Integrationsplattform sunShine eine L sung f r dieses Problem entwickelt und implementiert Da dabei allerdings nur sunShine in seiner bisherigen Form also ohne die hier entwickelten Modellierungskonzepte und werkzeuge Verwendung fand wollen wir diese Fallstudie noch einmal aufgreifen und untersuchen ob die L sung durch Einbeziehung der Konzepte dieser Arbeit noch verbessert werden k nnte Am Ende dieses Kapitels erfolgt schlie lich eine Bewertung der Ergebnisse und Konzepte anhand der allgemeinen Anforderungen die im Ab schnitt 3 2 an ein System zur prozessorientierten Integration im E Business gestellt wurden 11 1 Vergleich der L sungsans tze Zur Erinnerung sei hier die Fallstudie aus Abschnitt 3 1 kurz zusammen
80. durch ein verbessertes Zusammenspiel der einzelnen T tigkeiten und Verarbeitungsschritte im Unternehmen gesteigert wird ist dies auch durch die Integra tion der Softwaresysteme m glich Ein zweiter wichtiger Aspekt von Softwareintegra tion im Zeitalter des E Business ist die Anbindung der vorhandenen Systeme an das Internet so dass sie auch ber das Netz von Kunden Mitarbeitern und Partnern aufgeru fen werden k nnen Diese Integrationsschritte bilden die Voraussetzung f r eine unter nehmens bergreifende Integration bei der die Softwaresysteme mehrerer Unternehmen zum Beispiel der Beteiligten in einer Lieferkette miteinander vernetzt werden Grundlage f r diese Entwicklung von der Kommunikation zur Integration ist neben der bereits bestehenden Kommunikationsinfrastruktur die Entwicklung geeigne ter Technologien zum Austausch strukturierter Daten durch die sich die verschiedenen Anwendungssysteme miteinander koppeln lassen Einen starken Schub bei der Umset zung dieser Ziele brachte die Einf hrung der Extensible Markup Language XML siehe 6 Kapitel 1 Einleitung XML00 Ende der neunziger Jahre XML stellt seitdem quasi das Alphabet beim Datenaustausch im E Business dar vgl Mic00 S 2f Da XML jedoch nur eine Tech nik ist um die unterschiedlichsten Datenformate individuell zu definieren bedarf es f r den Austausch von XML Dokumenten ber lokale Grenzen eines Unternehmens hin weg der Abstimmung gemeinsamer XML Formate f
81. ein Synchronisationszustand ist Wir treffen diese Unterschei dung aus technischen Gr nden damit der Zustand sich auf einfache Weise von einem gew hnlichen Fork Zustand unterscheiden l sst Durch die Unterscheidung bereits auf Modellebene werden Fallunterscheidungen beispielsweise zur Ausf hrungszeit des Pro zessinterpreters vermieden Das Element lt synchfork gt hat Transitionen zu genau zwei Nachfolgern wobei es sich um einen Synchronisationszustand und einen anderen Zu stand handeln muss Dabei sind keine Guards erlaubt 184 Kapitel 8 Beschreibung von Prozessen in XML Synchjoin Dabei handelt es sich um einen Join Zustand dessen einer Vorg nger ein Synchronisationszustand ist Wie schon beim Synchfork bringt diese Unterscheidung auf Modellebene Vorteile mit sich Das Element lt synchjoin gt hat eine Transition zu einem Nachfolger wobei keine Guards erlaubt sind Stereotyp typedTransition Wie bereits angedeutet dient zur Verkettung der verschiedenen Zust nde eines Prozess diagramms das Element lt next gt Eine solche Verkettung entspricht einer UML Transi tion mit dem Stereotyp typedTransition Dabei ist zu unterscheiden zwischen Transi tionen mit und ohne Guard Zun chst besitzt das Element lt next gt ein Attribut ref vom XML Datentyp IDREF Es l sst sich damit auf ein Element lt state gt als Zielzustand der Transition verweisen das ja als eindeutige Identifikation ein Attribut id besitzt Au er
82. einem Startereignis ein bergeordnetes abstraktes Startereignis einf hren das auf die urspr nglichen Startereignisse verzweigt und bei den Endereignissen analog verfahren Bei der EPK ist keine Ein und Ausgabe von XML Daten vorgesehen da die Sprache f r beliebige Gesch ftsprozesse konzipiert wurde und nicht die Besonderheiten einer XML Unterst tzung ber cksichtigt Somit fehlen zun chst Konstrukte f r den Zugriff auf XML Inhalte sowie die Beschreibung ihrer Struktur Insbesondere ist es nicht so einfach m glich den Kontrollfluss in Abh ngigkeit der Daten zu lenken Die Steuerung des Kontrollflusses durch Bedingungen ist nur durch Definition und Einf gen entsprechender Ereignisse m glich die Verkn pfung von Kontrollflusskanten mit logischen Ausdr cken wie den aus UML Aktivit tendiagrammen bekannten Guards ist nicht vorgesehen siehe Abschnitt 5 3 1 Durch die Kernelemente einer EPK werden Ereignisse und Aufgaben zu einem Vorgang miteinander verkettet Die Forderung nach einer aktivit tenbasierten Modellie rung kann also erf llt werden F r die Aufgaben in einer EPK k nnen durchaus bestimmte Systemkomponenten vorgesehen werden so dass ein prozessorientierter Integrationsansatz realisierbar scheint blicherweise werden bei der Modellierung mit einer EPK keine Attribute f r die Aufgaben angegeben obwohl das formale Modell solche Attribute ausdr cklich f r die Knoten und Kanten der EPK zul sst Aufsetzend auf diesen Attrib
83. erf llt es die Anforderung dass durch Einf hrung der neuen E Business Plattform nicht ein vollst ndig neues System entwickelt werden soll sondern die bestehenden Back End Systeme eingebunden und weiterhin verwendet werden Der ausdr ckliche Wunsch nach dem Einsatz von XML als internes Datenformat stellt kein Problem dar da BizTalk selbst in gro en Teilen auf XML Technologien setzt Ein Workflow Management System das die Ausf hrung und Kontrolle der Prozesse bernimmt steht zur Verf gung Ein Mangel von BizTalk besteht darin dass es keine integrierte Portalfunktiona lit t besitzt Da jedoch beispielsweise in der Fallstudie ein wesentliches Element der E Business Plattform ein Web Auftritt mit Multi Channel F higkeit ist m sste zu diesem Zweck auf ein separates Produkt zur ckgegriffen werden das in das BizTalk System eingegliedert wird Im Gegensatz zur Fallstudie geht es bei BizTalk eher um langlebige Gesch ftsprozesse als um systemorientierte Informationsprozesse im Sinne von Ab 4 4 Bewertung 49 schnitt 2 2 2 Weiterhin kann die Forderung nach Plattformunabh ngiskeit nicht erf llt werden da das BizTalk System stark von Microsoft Produkten abh ngig ist Demgegen ber fokussiert WARP st rker diesen Bereich des Workflow Management wobei das vorrangige Ziel die Konfiguration und Integration heterogener Komponenten ist Es w re daher kein Problem bestehende Back End Systeme zu inte grieren Nachteilig wirkt sich allerdi
84. ftspartner die die elektronischen Informations und Vertriebskan le nutzen m chten verspricht sich das Finanzunternehmen von der Durchf hrung au er dem eine Optimierung der internen Workflows die somit von Anfang bis Ende voll st ndig elektronisch abgewickelt werden k nnen Beide Gr nde sind entscheidende Faktoren um im zuk nftigen E Business Zeitalter gegen ber den Konkurrenten wett bewerbsf hig zu bleiben Die Straffung und Optimierung der Workflows sowie ihre vollst ndig elektronische und automatisierte Abwicklung kann zudem bereits mittelfris tig zu Kosteneinsparungen f hren Zielgruppen f r die neue Plattform sollen sowohl Teile der Kunden als auch die Mitarbeiter des Unternehmens im Innen und Au endienst sein Als Beispiele f r m g liche Anwendungen durch den Kunden werden Funktionen wie die nderung der Daten 24 Kapitel 3 Anforderungsanalyse ber den Einzug regelm iger Beitr ge von einem anderen Konto oder die Erfassung bzw nderung von Freistellungsauftr gen genannt Gerade durch Rationalisierungen im Filialsystem m ssen Finanzinstitute ihren Kunden immer mehr die M glichkeit bie ten ihre Bankgesch fte per Internet von zu Hause aus zu erledigen Mit wachsender Verbreitung der Internetnutzung in der Bev lkerung w chst gleichzeitig bei den Kun den die Akzeptanz dieser Kommunikationsm glichkeit F r Mitarbeiter des Unterneh mens wird es einfacher Vorg nge oder nderungen in bestimmten Datens tzen
85. geschieht im Zusam menhang mit Verzweigungen des Prozesses durch Guard Bedingungen in denen XPath Ausdr cke angegeben werden Ein Ausdruck wird zur Laufzeit vom Prozess interpreter im Bezug auf das XML Dokument oder die Prozessumgebung ausgewertet und so der nachfolgende Aktivit tszustand ermittelt 6 2 5 Behandlung von parallelen Teilprozessen Sowohl Aktivit ten als auch Prozessdiagramme erlauben es Teilabl ufe zu bilden die parallel ausgef hrt werden Bei Prozessdiagrammen ergeben sich jedoch aufgrund des impliziten Dokumentflusses Probleme Das Dokument muss zeitgleich durch die Kom ponenten aller parallelen Str nge flie en Diese k nnen Manipulationen daran vorneh men welche anschlie end korrekt zusammengef hrt werden m ssen damit wieder ein einzelnes Dokument entsteht Dieses durchl uft dann den restlichen Prozess Grund s tzlich sind zwei verschiedene Ans tze zur L sung dieses Problems denkbar Zum einen k nnten alle Teilprozesse Referenzen auf ein und dieselbe Instanz des XML Dokuments erhalten Da aber der Zugriff der Komponenten auf die gemein same Datenbasis einen kritischen Abschnitt darstellt m ssten die Zugriffe synchroni siert werden damit keine inkonsistenten Sichten auf die Daten entstehen vgl Bac98 S 241ff Um dies zu leisten m sste eine Art Sperrenmechanismus auf dem XML Baum entwickelt werden Dieser Ansatz erweist sich jedoch als nicht realisierbar da mit XML Prozessen heterogene Softwarekom
86. glich sein gew nschte Prozess nderungen mit dem bekannten Modellierungswerkzeug vornehmen zu k nnen Nach der vorausgegangenen Einf hrung in die Thematik des Workflow Managements sollen im Rest der Arbeit bestehende Ans tze zur prozessorientierten Integration heterogener Softwaresysteme vorgestellt und verglichen sowie neue unter besonderer Einbeziehung von XML Technologien entwickelt werden Dazu werden im folgenden Kapitel zun chst anhand einer praktischen Anwendung Anforderungen her ausgearbeitet die heute an ein Workflow Management System in Verbindung mit einer E Business Plattform gestellt werden wenn damit gleichzeitig existierende Software komponenten in die Workflows integriert werden sollen 22 Kapitel 3 Anforderungsanalyse 3 1 Fallstudie E Business Plattform eines gro en Finanzunternehmens 23 3 Anforderungsanalyse Mit der folgenden Anforderungsanalyse sollen die Ziele dieser Diplomarbeit abgesteckt werden Neben allgemeinen Anforderungen f r Workflow Management Systeme wer den aus einer Fallstudie heraus spezielle Anforderungen aufgezeigt die von besonderer Relevanz beim praktischen Einsatz solcher Systeme im E Business sind Da der Model lierung von Workflows eine gro e Bedeutung zukommt werden die Anforderungen an eine passende Modellierungssprache gesondert betrachtet Am Ende des Kapitels folgt schlie lich eine Gewichtung der einzelnen Anforderungen und die sich daraus erge bende Zielsetzung f r die sp te
87. hren soll eine passende Schnittstelle zur Verarbeitung der XML Daten In der grafischen Darstellung jedes Konnektors werden die m glichen Operationen der zugeh rigen Komponente angegeben im Falle des SQL Konnektors beispielsweise 6 2 Modellierung mit Prozessdiagrammen 85 executeOperation Diese Operationen die im Prozessdiagramm zur Erf llung einer Aktivit t genutzt werden k nnen werden im Folgenden Services genannt und im stati schen Modell durch ein hochgestelltes S gekennzeichnet Jedem Service kann des Weiteren ein Symbol zugeordnet werden das im Prozessdiagramm verwendet wird Wie im Abschnitt 6 3 1 beschrieben sollen die konkreten Implementierungen der Kon nektoren erst zur Laufzeit gebunden und nicht schon im Modell festgelegt werden Daher handelt es sich bei den im statischen Modell aufgef hrten Konnektoren lediglich um Interfaces die die Service Operationen und ihre Parameter spezifizieren Abbildung 6 5 zeigt einen Ausschnitt aus dem Prozessdiagramm der die Bear beitung einer berweisung beschreibt Dabei handelt es sich um ein UML Aktivit ten diagramm in dem zus tzliche Konstrukte enthalten sind die f r die Beschreibung des Prozesses erforderlich sind In einem konkreten Fall k nnte der Prozess folgendes XML Dokument von einem Kunden als Eingabe erhalten lt transaktion gt lt typ gt ueberweisung lt typ gt lt auftraggeber gt lt konto gt 12345 lt konto gt lt name gt Hans Meier lt name gt
88. i i i i i i i i metaclass metaclass i metaclass i 0 1 CompositeState SimpleState l ActivityDiagram i metaclass i l metaclass l BehavioralFeature A i A Interface i i i ik N i i j i metaclass 1 i i ActionState i i i metaclass Parameter f A metaclass i i 1 i Operation i i i H H stereotype smene erst H H i A N typ CallState 1 stereotype 1 stereotype stereotype 1 stereotype i i l j stereotype i A i i RELE ARRIE TACA P E ES E TNE EE S A De AEA E EE TOUR E E T A E A E ATS AE A T 1 7 T f F 1 l 1 1 fi 1 f t i 1 l 1 1 l k 1 stereotype 1 i i f stereotype stereotype f i stereotype i service stateWithPorts l stereotype i componentConnector i typedTransition i i Tags Tags i Tags y image Geometry 0 1 inputPort Port 1 i Tags i i inputPort Port 1 outputPort Port 1 i i outputPort OpenPort 1 N i T 1 i i 1 1 ji i stereotype l serviceState H i i i ter stereotype Tags proceseDiagram transitionType type l i 1 l Tags Tags IEE 2 24 n j sourcePort Port 1 taggedValue isTransactional Boolean 1 s inputPort Port 1 targetPort OpenPort 1 outputPort Port 1 transformation Expression 0 1 pi BE Abb 7 5 Stereotypen des Profils Elemente des statischen Modells Das statische Modell spezifiziert di
89. in der Regel die Vorgaben aus dem statischen Modell bernommen werden Transitionen verbinden die einzelnen Aktivit ten zu einem Kontrollfluss Dadurch verkn pft eine Transition den Ausgangsport ihrer Quellaktivit t mit dem Eingangsport der nachfolgenden Aktivit t Eine solche Verkn pfung die bei der Ausf hrung die Migration eines XML Dokumentes impliziert kann nat rlich nur erlaubt sein wenn Quell und Zielport zueinander kompatibel sind also das Ergebnis der ersten Aktivit t als Eingabe f r die nachfolgende Aktivit t genutzt werden kann F hrt diese Konsis tenzpr fung zu einem negativen Resultat kann die Inkompatibilit t zwischen Quell und Zielport der Transition durch eine Transformation des Dokumentes berwunden werden Dazu m sste f r die Transition eine Transformationsvorschrift angegeben wer den die ein Dokument das zum Quellport konform ist so umwandelt dass es danach zum Zielport passt Stylesheets der Transformationssprache XSLT XML Stylesheet Language Transformations siehe XSLT99 eignen sich sehr gut f r die Definition solcher Transformationen Um zu vermeiden diese Transformationsvorschriften bei Transitionen mit hnli cher Konstellation jeweils neu angeben zu m ssen wird in Abschnitt 6 3 2 das Konzept der typisierten Transitionen vorgestellt Dabei soll eine gr ere Wiederverwendbarkeit und Konsistenz dadurch gef rdert werden dass jeder Transition ein wiederverwend barer Typ zugewiesen wird der f
90. isSubsetOf super Port Boolean Expression GopyRoot CopySubs DocType union port Port Port Tan Constraints u subExceptions XmlElements self root isEmpty implies placeholder oclisTypeOf AnyPlaceholder Abb 7 7 Klassendiagramm f r die Datentypen Da diese Klassen die Funktion von Datentypen bernehmen werden keine Assoziatio nen zu diesen Klassen gezogen sondern sie k nnen einfach als Typen der Attribute anderer Klassen benutzt und im mittleren Fach der jeweiligen Klassensymbole notiert werden Die spezifizierten Methoden wie binding oder isSubsetOf m ssen entsprechend der zugeh rigen Definitionen aus Abschnitt 6 3 3 implementiert werden LogicSet Die Hilfsklasse LogicSet wird benutzt um eine logische Menge von Elementen abzubilden die zwei gleiche Elemente jeweils nur einmal enthalten kann Die Bezeichnung gleich bedeutet hier nicht nur identisch sondern schlie t auch Objekte ein die nicht identisch sind aber den gleichen Typ und gleiche Attributwerte haben LogicSet kommt bei den Datentypen immer dann intern zum Einsatz wenn ein Attribut die unbeschr nkte Kardinalit t besitzt weil damit laut formaler Definition in Ab schnitt 6 3 3 eine logische Menge von Elementen gemeint ist Expression Der Datentyp Expression entspricht dem gleichnamigen UML Datentyp und erlaubt die Angabe einer Sprache und eines Aus drucks der entsprechend der Syntax und Semantik dieser Spra che
91. ist damit zu rechnen dass in einer zuk nftigen 168 Kapitel 8 Beschreibung von Prozessen in XML Version von XMI die bei XML Schemata vorgesehene Verfeinerung der Datentypen und die explizite Definition von Vererbungsmechanismen zu einer verbesserten Abbil dung der Metamodelle auf XML Formate f hren wird F r die Speicherung von Prozessdiagrammen in einem XML Format bieten sich mit XMI zwei m gliche Ans tze Als erweitertes UML Diagramm k nnte man ein Pro zessdiagramm als XMI Dokument speichern das den Spezifikationen der standardi sierten UML DTD siehe XMI00 A 1 gen gt oder man generiert aus dem Metamo dell f r Prozessdiagramme eine eigene DTD und erzeugt dazu g ltige XMI Dokumente Zun chst soll auf Letzteres eingegangen werden Das Metamodell f r Prozessdiagramme siehe Abschnitt 7 3 ist im Wesentli chen eine Teilmenge des UML Metamodells erg nzt um einige Stereotypen die man als virtuelle Metaklassen auffassen kann Virtuell bedeutet in diesem Fall dass sie bei der Modellierung zwar zur Klassifizierung von Elementen in der Modellebene benutzt werden k nnen quasi so als seien sie selbst Elemente des Metamodells In Wirklichkeit befinden sich die Stereotyp Definitionen als Auspr gungen der Metaklasse Stereotype jedoch nicht in der Metamodell Ebene sondern ebenfalls in der Modellebene Es handelt sich bei dem Profil f r Prozessdiagramme als Erweiterung gem den vorgegebenen Erweiterungsmechanismen also nur um eine
92. jeweils Erweite 88 Kapitel 6 XML Prozesse und Prozessdiagramme rungen von XPath darstellen Im Folgenden kommt ausschlie lich XPath zum Einsatz es kann aber grunds tzlich auch jede andere Sprache verwendet werden falls die M g lichkeiten von XPath nicht ausreichen sollten oder sich k nftig eine andere Anfrage sprache zum Standard entwickelt Werte aus der Prozessumgebung Als dritte M glichkeit ist es denkbar dass den Komponenten externe Werte bergeben werden m ssen die aus dem Kontext des Pro zessablaufs stammen Dies k nnte beispielsweise die aktuelle Systemzeit oder hnli ches sein Da XML Prozesse im Anwendungsbereich von Web Applikationen zu sehen sind liegt es nah die Technik der sogenannten Sessions zu benutzen In der Spezifika tion des Java Servlet Technologie siehe CowOl S 52 ist eine M glichkeit festgelegt wie sich eine Web Anwendung Statusinformationen zu einen bestimmten Client ber mehrere Anfragen hinweg merken kann Zu diesem Zweck k nnen Attributwerte unter einem eindeutigen Namen an ein sogenanntes Session Objekt gebunden werden von dem es genau eines pro anfragendem Client gibt Aufgrund des Einsatzes von XML in E Business Anwendungen ist es denkbar dass in diesem Session Objekt auch XML Daten abgelegt werden In sunShine siehe Abschnitt 4 3 beispielsweise wurde dieser Ansatz dahin gehend erweitert dass beliebig viele XML B ume gespeichert werden k nnen Jeder XML Baum ist dabei unter einem ei
93. k nnen einige Nachteile der bisher vorgenommenen Fragmentierung in Pipelines und Regelwerk beseitigt oder zumindest abgemildert werden Zu diesen Nachteilen der bisherigen L sung z hlen eine schlechtere Kontrolle des Gesamtablaufs durch Verteilung der Ablaufsteue rung auf Regelmaschine und Pipeline Ausf hrung damit verbundene Einbu en bei der Ablaufgeschwindigkeit schwierigere Verwaltung und Wartung der Prozessbeschreibungen schwierigere Fehlerbehandlung und transaktionale Ausf hrung weil die einzel nen Pipelines nichts voneinander wissen und es daher im Fall eines Abbruchs schwierig ist den gesamten Prozess ber den Abbruch zu informieren und zu r ckzusetzen Bedingte Verzweigungen Zur Abbildung flexibler Gesch ftsregeln in den Workflow Modellen ist der Einsatz von bedingten Verzweigungen unverzichtbar In dem Regelwerk der Badenia AG kann man dazu f r jeden Zustand mehrere alternative Aktionen angeben und mit einem Entschei dungswert versehen Es wird in einem Zustand dann nur diejenige Aktion ausgef hrt f r die der Entscheidungswert wahr wird Die Entscheidungswerte d rfen sich nicht berschneiden so dass h chstens einer der Ausdr cke wahr werden kann Au erdem kann eine Aktion als Standardaktion gekennzeichnet werden die standardm ig dann ausgef hrt wird wenn aufgrund der Entscheidungswerte keine der alternativen Aktio nen durchgef hrt werden konnte Die Entscheidungswerte beinhalten triviale logische Ausdr cke
94. leitet sich aber keine feste semantische Bedeutung ab siehe Esh01 S 12 Insbesondere l sst sich auf diese Weise kein Rollen bzw Rechtekonzept realisieren siehe Oes97 Es k nnen zwar die Aktivit ten mit Hilfe von Bahnen einzelnen Rollen zugeordnet werden sowohl eine berlappung von Rollen als auch die Zuordnung konkreter Akteure zu Rollen l sst sich aber nicht ohne Weiteres modellieren In komplexen Workflow Modellen k nnen Bahnen die gew nschte Zuordnung von Aktionen zu Organisationseinheiten daher nicht leisten 5 3 3 Eignung f r Prozessdiagramme Im Abschnitt 3 3 wurden Anforderungen aufgestellt die eine Sprache erf llen muss um damit XML Prozesse modellieren zu k nnen Bei Aktivit tendiagrammen handelt es sich um eine visuelle Sprache zur Beschreibung und Darstellung von dynamischen Abl ufen Seit die UML durch eine offizielle Spezifikation standardisiert wurde siehe Omg01 ist aus Aktivit tendiagrammen ein Quasi Industriestandard im Bereich der Softwareentwicklung geworden Damit sind die Grundvoraussetzungen f r einen Ein satz bei XML basierten Workflow Modellen gegeben Des Weiteren sind alle vier grundlegenden Kontrollflusskonstrukte vorhanden Es k nnen problemlos sequentielle und verzweigte Abl ufe sowie Schleifen beschrie ben werden wobei Schleifen auf Verzweigungen abgebildet werden F r die Behand lung von Parallelit t verf gen Aktivit tendiagramme ber flexible M glichkeiten die sowohl das Erzeu
95. liegt und wie stark sie sich kontrollieren lassen spricht man von unstrukturierten oder gut strukturierten Prozessen Diese Klassifizie rung korrespondiert mit der Einteilung von Informationsprozessen in eher Mensch orientierte auf der einen Seite und systemorientierte Prozesse auf der anderen Seite Diese Prozesstypen bilden bei der in Geo95 vorgestellten Charakterisierung die Extrema auf einer kontinuierlichen Skala mit flie enden berg ngen Transaktionale Workflows Mensch System orientiert I orientiert kommerzielle WFMS kommerzielle Transaktionssysteme Abb 2 2 Kontinuum von Mensch orientierten zu systemorientierten Workflows aus Geo95 Bei den Mensch orientierten Informationsprozessen geht es um die Unterst tzung von Mitarbeitern die an einem Prozess beteiligt sind gemeinsam eine Aufgabe zu l sen haben und ihre Aktivit ten koordinieren m ssen Da hierbei Menschen und nicht Soft waresysteme in berw ltigender Mehrheit Aufgabentr ger sind zeichnen sich die Pro zesse durch einen hohen Grad an Interaktivit t der Benutzer mit dem WFMS aus Eine Modellierung solcher Prozesse und die anschlie ende rechnerbasierte Unterst tzung bei der Ausf hrung soll die Zusammenarbeit der betroffenen Personen und ihre Interaktion mit dem Computer erleichtern Eine wesentliche Aufgabe des Prozessmodells ist es daher eine Zuordnung der Teilaufgaben an einzelne Aufgabentr ger vorzunehmen Dabei m ssen sowohl die jeweilig
96. mit dem Ausgangsport des Quellzustands der Transition und sein Zielport mit dem Eingangsport des Zielzustands der Transition bereinstimmen Dabei wird jedoch nicht vollkommene Gleichheit sondern lediglich Kompatibilit t in Form der Teilmengenbeziehung gefordert vgl Ab bildung 6 22 6 3 Modellierung der Dokumenttypen 107 Stylesheet Statisches Modell Typ t A x gt y _ mit Transitionstyp Es muss gelten x cx y cy Prozessdiagramm mit typisierter Transition Service S t Abb 6 22 Zusammenhang zwischen Ports der Transition und des Transitionstyps Gelten die Beziehungen x c x und y c y so kann man sich einen g ltigen Fluss des Migrationsdokuments von x nach y ber die Portkette x c x y c y denken was eine wohldefinierte Transition darstellt Dies wird innerhalb des formalen Modells aus Abschnitt 6 3 3 durch den Migrationssatz 6 18 allgemein bewiesen Offene Ports bei Transitionstypen Das Stylesheet eines Transitionstyps wird w hrend der Ausf hrung des Workflows von einem Stylesheet Prozessor auf das Migrationsdokument angewandt Insofern k nnte dieser Schritt wie ein Service ebenfalls als Aktivit t angesehen werden die das Migra tionsdokument manipuliert Darum gelten f r die Quell und Zielports von Transi tionstypen hnliche berlegungen wie f r die Ein und Ausgangsports von Services vgl Abschnitt 6 3 1 Insbesondere k nnen Stylesheets sehr allgemein gestaltet se
97. miteinander Guard Die Klasse Guard entspricht der gleichnamigen UML Meta klasse aus Abbildung 7 6 Ein Guard ist immer einer Transition zugeordnet In dem Attribut expression kann die Transitions bedingung angegeben werden TypedTransition Die Klasse TypedTransition realisiert das Stereotyp typedTransition aus Abschnitt 7 3 2 mit dem alle Transitio nen eines Prozessdiagramms ausgezeichnet werden m ssen Sie erbt alle Eigenschaften der Oberklasse Transition und erh lt zus tzlich eine Assoziation zu TransitionType mit der jedem Transitions Objekt ein Typ aus dem statischen Modell zugewie sen werden kann Diese Assoziation koppelt somit f r den Bereich der Transitionen den statischen mit dem dynamischen Modellteil Klassendiagramm f r die verschiedenen Zustandsarten In Prozessdiagrammen k nnen verschiedene Arten von Zust nden vorkommen Aus diesem Grund muss die allgemeine Abstraktionsklasse StateVertex aus dem Klassen diagramm f r dynamische Modellelemente siehe Abbildung 7 9 weiter spezialisiert werden Das folgende Klassendiagramm zeigt s mtliche Unterklassen von StateVertex und gegebenenfalls ihren Zusammenhang mit den anderen Klassen des Metamodells 7 stateVertex ProcessDiagram PP State Vertex inputPort
98. ngt werden In der Port Notation l sst sich das als Liste von Unterelementen darstellen die auf jeden Fall unter dem Wurzelelement lt join gt zu finden sind Wenn die eingehenden Transitionen von Ports mit mehr als einem Dokumenttyp ausgehen wie in der folgenden Abbildung dargestellt gibt es verschiedene M glichkeiten welcher Dokumenttyp nun wirklich am Ende der Transition vorliegen kann und unter das neue lt join gt Element geh ngt wird Um alle M glichkeiten zu ber cksichtigen m ssen alle Dokumenttypen der eingehen den Ports wechselseitig miteinander kombiniert werden Dies geschieht indem das kartesische Produkt der Mengen gebildet wird Jedes Element dieses kartesischen Produktes f hrt zu einem neuen Dokumenttyp im Ausgangsport des join Zustandes mit den Eintr gen des Elements als Unterelementliste unter dem Wurzelelement join vgl Abbildung 6 18 join u x join u y join u z join v x Jeinivyl join vz Service x y AA S3 iz Ji Abb 6 18 Ports bei einer Und Zusammenf hrung join 6 3 Modellierung der Dokumenttypen 103 In der folgenden Tabelle sind noch einmal alle in einem Prozessdiagramm m glichen Arten von Zust nden zusammen mit den Ports aufgef hrt die diesen Zustandstypen im Prozessdiagramm beigeordnet werden Eingangsport Ausgangsport Prozessdiagramm Benutzer definiert Ausgangsport des Endzustands Service Aktivit t Service Teilport des Eingangs po
99. siehe Constraint 1 Beim Aufruf des Service m ssen Werte f r geforderte Parameter bergeben werden Das UML Metamodell siehe Omg01 2 9 2 3 sieht als Wert f r ein Argument einen beliebigen Ausdruck vor Es wird keine Einschr nkung bez glich der m glichen Sprache getroffen Somit sind f r die Argumente auch Ausdr cke m g lich die f r das WFMS verst ndlich sind und vor Aufruf der Methode ausgewertet wer den k nnen um etwa Daten aus dem Migrationsdokument oder der Prozessumgebung vgl Abschnitt 6 2 2 zu bernehmen Stereotyp serviceState Basisklasse UML ActivityGraphs CallState Ober Stereotyp stateWithPorts Tag Definitionen keine Einschr nkungen 1 Die zugeordnete Operation muss vom Stereotyp service sein Constraints context serviceState inv let state CallState self extendedElement oclAsType CallState state entry oclAsType CallAction operation isStereotypedAs service Erl uterung CallStates die als serviceState klassifiziert sind symbolisieren die Ausf hrung einer kompo nentenbasierten Aktivit t Jedem serviceState ist ein service zugeordnet an den die Ausf hrung der Aktivit t delegiert wird Darstellung Standardm ig wie ein CallState Wenn der zugeh rige service im Tag image ein Symbol spezifiziert kann dieses zur Darstellung benutzt werden Tab 7 7 Definition des Stereotyps serviceState Die Ausf hrung der korrespondierende
100. solcher transitionType zugeordnet ist Jede Transition eines Prozessdiagramms muss mit diesem Stereotyp klassifiziert sein Die Einschr nkungen des Stereotyps stellen die korrekte Umsetzung der Definition 6 17 einer typisierten Transition aus Abschnitt 6 3 3 sicher Dort wird verlangt dass der Eingangsport der Transition ein Teilport des Quell ports des zugeordneten Transitionstyps ist Constraint 2 und dass der gebundene Ziel port des Typs ein Teilport des Ausgangsports der Transition sein muss Constraint 3 Dies sind die Voraussetzungen zur Anwendung des Migrationssatzes Satz 6 18 der einen konsistenten Dokumentfluss ber die Transition sicherstellt 142 Kapitel 7 Metamodell f r Prozessdiagramme Stereotyp typedTransition Basisklasse UML StateMachines Transition Ober Stereotyp Tag Definitionen type Einschr nkungen 1 Keine Einschr nkungen sondern lediglich Hilfsfunktionen zum Zugriff auf die Attribute Constraints context typedTransition def let type transitionType self definedTag gt select name type typedValue referencedValue oclAsType transitionType let inputPort Port self extendedElement oclAsType Transition source stereotype oclAsType stateWithPorts outputPort let outputPort Port self extendedElement oclAsType Transition target stereotype oclAsType stateWithPorts inputPort let boundTarget Port self type targetPort binding self inputPort context
101. ssen die teilweise auch auf unterschiedlichen Hardware Plattformen laufen Mit XML lassen sich anwendungs neutrale Datenformate definieren die zum Austausch von Informationen zwischen den einzelnen Komponenten der Plattform benutzt werden k nnen Mit der wachsenden Verbreitung des XML Standards sind inzwischen auch eine umfangreiche Anzahl von Werkzeugen zur XML Verarbeitung vorhanden insbesondere f r den Einsatz in Kom bination mit Java Software Nach der bersetzung eines eingegangenen Dokuments in das interne XML Format ist zur weiteren Verarbeitung ein Workflow Management System n tig ber eine Sammlung von Regeln soll es feststellen wem das Dokument als n chstes zuge wiesen werden muss Nach jedem Verarbeitungsschritt soll der neue Zustand des Dokuments in einem Archiv protokolliert werden Dazu werden Kopien des Dokuments in einer eigenen Datenbank abgelegt Weitere jedoch eher technische Anforderungen des Finanzunternehmens sind eine Verf gbarkeit des Systems rund um die Uhr mit gleichzeitig hoher Ausfallsicher heit Au erdem sind Mechanismen zur Authentisierung und Autorisierung sowie zur Verschl sselung kritischer Daten n tig um ein ausreichendes Sicherheitsniveau zu erreichen Die E Business Plattform soll im Zusammenhang mit einem erweiterten Internetauftritt durch den Aufbau eines sogenannten Portals eingef hrt werden Hierf r sind geeignete Werkzeuge zur Verwaltung der Informationsinhalte auf den Web Seiten n tig D
102. type xsd string use required gt lt xsd complexType gt lt xsd complexType name ArgumentType gt lt xsd simpleContent gt lt xsdiextension base xsd string gt lt xsd attribute name parameter type xsd string use required gt lt xzsd iextension gt lt xsd simpleContent gt lt xsd complexType gt Abb 8 16 PML Schema Fragment f r Zust nde Initial Durch das Element lt initial gt wird der Startzustand eines Prozesses bestimmt Es besitzt ein Unterelement lt next gt mit dem eine Transition ohne Guard zum Nachfolge zustand definiert wird Final Das Element lt final gt bestimmt den Endzustand des Prozesses Es erlaubt keine Unterelemente Fork Mit Hilfe des Elements lt fork gt werden parallele Teilprozesse beschrieben Durch lt next gt k nnen beliebig viele Nachfolgezust nde definiert werden mindestens jedoch zwei Dabei k nnen Guards angegeben werden um bedingte Parallelit t auszudr cken Join Mit dem Element lt join gt lassen sich parallele Teilprozesse wieder vereinigen Es muss eine Transition zu einem Nachfolgezustand angegeben werden die keinen Guard enthalten darf Decision Unter einem solchen Zustand mit dem Element lt decision gt verstehen wir einen UML Zustand vom Typ junction mit dem der Prozessablauf in einen von meh reren alternativen Str ngen verzweigt Daher sind wie schon bei Fork beliebig viele Nachfolgezust nde erlaubt mindestens jedoch zwei Es m ssen G
103. und JunctionStates haben als Eingangsport den unbeschr nkten Port if state oclIsTypeOf SynchState or state oclIsTypeOf FinalState or state oclIsTypeOf PseudoState and state oclAsType PseudoState kind fork or state oclAsType PseudoState kind join or state oclAsType PseudoState kind junction then inputPort ist any endif 5 SynchStates FinalStates ForkStates und DecisionStates haben als Ausgangsport den gebundenen Zielport ihrer eingehenden Transition if state oclIsTypeOf SynchState or state oclIsTypeOf FinalState or state oclIsTypeOf PseudoState and state oclAsType PseudoState kind fork or state oc1lAsType PseudoState kind junction and state incoming gt size 1 then predecessors gt forAll p p outputPort endif 6 MergeStates haben als Ausgangsport die Vereinigungsmenge der gebundenen Zielports ihrer eingehenden Transitionen siehe auch Abbildung 6 17 if state oclIsTypeOf PseudoState and state oclAsType PseudoState kind junction and state incoming gt size gt 1 then predecessors types gt forAll t JoutputPort types gt includes t endif 7 JoinStates haben als Ausgangsport stets nur Dokumenttypen mit dem ausgezeichneten Wurzelelement Join Jeweils ein Element aus den eingehenden gebundenen Zielports der eingehenden Transitionen bilden die Menge der obligatorischen Unterelemente von Join Da jedes Element des einen Zielports mit jedem des anderen Zielports kombiniert w
104. und Vereinigung ist es m glich abh ngig von Bedingungen unterschiedliche Ausf hrungswege zu w h len die sich sp ter wieder zu einem einzigen Strang vereinigen Die Bedingungen f r die einzelnen Wege werden als sogenannte Guards in eckigen Klammern an den Aus gangstransitionen der Verzweigung notiert Um Nebenl ufigkeit in einem Aktivit tendiagramm auszudr cken steht der schwarze Balken zur Verf gung Wenn er eine Eingangs und mehrere Ausgangs transitionen besitzt Fork Zustand werden mehrere Ausf hrungsstr nge gestartet die parallel abgearbeitet werden Sie k nnen durch einen schwarzen Balken wiedervereinigt werden in den alle Str nge hineinlaufen aber nur eine Ausgangstransition existiert Join Zustand Eine solche Stelle dient zugleich als Synchronisationspunkt da die Ausf hrung erst dann fortf hrt wenn alle parallelen Str nge am schwarzen Balken angekommen sind 5 3 UML Aktivit tendiagramme 67 Bezeichnung Symbol Definition Aktivit t Transition Verzweigung Vereinigung Nebenl ufigkeit Synchronisations zustand Bahnen Objekt Objektfluss Signal senden Signal empfangen ofo Zustand in dem eine bestimmte Aktivit t ausgef hrt wird Beschreibt den Kontrollfluss zwischen den einzelnen Aktivit ten des Diagramms Beschreibung einer Verzweigung des Kontrollflusses in Abh ngigkeit von bestimmten Bedingungen Guards Erlaubt die Erzeugung und Synchronisat
105. verhindern Die folgende Abbildung zeigt ein schematisches Beispiel f r Zyklen im Prozessdiagramm Bei der Breitensuche w rde zun chst die Zusammenf h rung A und sp ter die Verzweigung B bearbeitet werden was wiederum Auswirkungen auf A als Nachfolger von B haben kann ndert sich dabei der Ausgangsport von A wird der Zyklus erneut durchlaufen 7 6 Automatische Portberechnung 159 Abb 7 15 Zyklen bei der automatischen Portberechnung Bei der Betrachtung der verschiedenen Zustandsarten f llt auf dass der Ausgangsport eines Zustands nicht kleiner werden kann wenn die vorgelagerten Ports bez glich der Anzahl ihrer Dokumenttypen gr er werden Angenommen bei jedem Zyklendurchlauf w rden sich die Ausgangsports immer wieder ndern was f r eine Endlosschleife der Fall sein m sste Dann k nnte sich der Ausgangsport von Zustand A h chstens jedes Mal vergr ern da er alle eingehenden Ports vereinigt Da nun aber innerhalb der Ports die im Zyklus berechnet werden nur endlich viele XML Elemente verwendet werden gibt es auch nur endlich viele M glichkeiten diese zu Dokumenttypen zu kombinieren so dass sp testens dann die Bearbeitung der Schleife abgebrochen wird wenn der maximale Port mit allen m glichen Dokumenttypen im Zustand A erreicht wurde Somit terminiert die Breitensuche und damit der Algorithmus zur automatischen Port berechnung nach einer endlichen Anzahl von Rechenschritten 160 Kapitel 8 Beschreibung vo
106. wichtige Werkzeuge f r die Analyse Trans 162 Kapitel 8 Beschreibung von Prozessen in XML formation und andere Operationen auf den Dokumenten bereits enthalten muss Au er dem ist XML ein plattformneutrales Format was besonders bei heterogenen E Busi ness Plattformen relevant ist und die Plattformunabh ngigkeit des gesamten WFMS unterst tzt Als weit verbreiteter Standard ist XML zudem kompatibel zu den g ngigen Kommunikationsprotokollen des Internets und damit besonders gut f r den unterneh mens bergreifenden Austausch geeignet Damit wird der Grundstein f r eine gegen seitige bermittlung von Prozessdefinitionen zwischen Gesch ftspartnern gelegt Es ist zum Beispiel denkbar dass mit dem eingehenden Migrationsdokument nicht ein vorhandener Prozess des WFMS aufgerufen wird sondern dass die Prozessbeschrei bung selbst ein Bestandteil des Dokuments ist und vom WFMS interpretiert wird Damit k nnten Klienten eigene individuelle Prozesse definieren und als XML Dokument zusammen mit der Dateneingabe an das WFMS bermitteln Als weiterer Vorteil sei noch erw hnt dass sich die XML Dokumente mit vorhandenen Transformationskon zepten leicht in ein anderes Datenformat konvertieren lassen So w re mit einem pas senden XSL Stylesheet zum Beispiel die Generierung von Programmcode in einer beliebigen Programmiersprache denkbar mit dem sich das Modell ebenfalls ausf hren lassen k nnte Alle diese Gr nde haben dazu gef hrt dass in letz
107. 1f e die genauere Spezifizierung der informellen oft verbal beschriebenen Aktivit ten besonders wenn es sich um automatisierbare Aktionen handelt e die Strukturierung der Daten in Entit ten und Attribute und die Festlegung der Datenfl sse e die genaue Definition der logischen Regeln zu Verzweigungen der Kontroll fl sse auch in Abh ngigkeit von den Auspr gungen der Datenstruktur e die Einordnung der Bearbeiter in ein Rollen und Qualifikationskonzept zwecks eindeutiger Zuordnung der Aufgaben Bei der Umwandlung eines Gesch ftsprozessmodells in ein Workflow Modell kommen zwei Vorgehensweisen in Frage Einerseits k nnte man zur Modellierung der Gesch ftsprozesse eine Sprache benutzen die so detailliert und formal ist dass die mit ihr erzeugten Modelle als Workflow Modelle angesehen und als Eingabe f r eine ausf hrende Einheit genutzt werden k nnen Dabei muss allerdings ein h heres Ma an Komplexit t bei der Modellierung in Kauf genommen werden Andererseits k nnte man die beiden Modelle getrennt voneinander in zwei ver schiedenen Sprachen mit unterschiedlichem Abstraktionsgrad aufstellen Mit einem Konvertierungswerkzeug w rde man um sich das Aufstellen des zweiten formaleren Modells zu sparen das abstraktere Modell weitgehend automatisch in die Workflow Spezifikation konvertieren Dabei kann es allerdings unter Umst nden zu Konvertie rungsfehlern kommen weil das Quell und Zielformat der Konvertierung unterschied
108. 3 262 Literatur und Quellen WieOl Wmc95 Wmc99 Rik Eshuis Roel Wieringa An Execution Algorithm for UML Activity Graphs Proceedings at the 4 International Conference Toronto Canada 2001 Lecture Notes of Computer Science 2185 S 47ff Springer Verlag Berlin 2001 Workflow Management Coalition The Workflow Reference Model WfMC TC 1003 Version 1 1 Januar 1995 http www wfmce org standards docs tc003v11 pdf Workflow Management Coalition Terminology amp Glossary WfMC TC 1011 Version 3 Februar 1999 Spezifikation der Workflow Management Coalition http www wfmce org standards docs TC 1011_term_glossary_v3 pdf WSDLO1 Erik Christensen et al Web Services Description Language WSDL 1 1 W3C World Wide Web Consortium Note 15 Mai 2000 http www w3 org TR 200 NOTE wsdl 20010315 Anmerkungen Bei den genannten Firmen und Produktnamen handelt es sich zum Teil um eingetragene Warenzeichen Im Sinne der besseren Lesbarkeit ist dies jedoch nicht explizit gekennzeichnet Alle angegebenen Internetadressen entsprechen dem Stand von Dezember 2001 Zwischenzeitliche Anderungen sind nicht auszuschlie en A Anhang A 1 Abk rzungsverzeichnis ACID API ARIS B2B B2C BPMI BPML CASE COM CORBA CRM CSCW DB DOM DTD EAl ebXML EDI EPK ERP GWMA GXSL HTML HTTP MOF MSL OCL OMG PDF PML RFC RMA RMI SAP SAX SMA SMTP SOAP SQL UML URL WSC WAP WARP Atomicity Consistency Isola
109. 3 Ein Dokumenttyp kann somit durch die Angabe eines globalen XML Elements spezifiziert werden Alle XML Dokumente die jenes Element als Wurzelelement haben sind damit von diesem Dokumenttyp Bekannt ist diese Konvention vom Verweis auf ein globales DTD Element im Tag lt DocTYPE gt siehe XML00 Punkt 2 8 zu Beginn lterer XML Dokumente die noch anhand einer DTD validiert wurden Durch die Angabe eines Dokumenttyps in den Workflow Modellen wird dieser 6 3 Modellierung der Dokumenttypen 93 Typ selektiert und damit der Bereich der g ltigen Dokumentinstanzen auf diejenigen eingeschr nkt die die im zugeh rigen Schema definierte Struktur aufweisen In Prozessdiagrammen ist die Einschr nkung auf bestimmte Dokumenttypen an mehreren Stellen n tig Vor allem muss f r jeden Service angegeben werden welche Dokument typen er als Eingabe verarbeiten Kann und welche Dokumenttypen der Service als Aus gabe an die nachfolgende Komponente bergibt Diese Ein und Ausgabeschnittstellen der Services werden in Prozessdiagrammen durch sogenannte Ports spezifiziert Ein Port ist dabei im Wesentlichen eine Menge von Dokumenttypen Im nachfolgenden Abschnitt wird dieses Konzept im Detail vorgestellt Neben der Schnittstellenspezifikation f r Services im statischen Modell werden Ports im Workflow Modell eingesetzt um analog die Ein und Ausgabeformate der einzelnen Aktivit ten zu spezifizieren wenn dort ein Service ausgef hrt wird Dazu k nnen
110. A sen Universit t Paderborn Fachbereich 17 Informatik Prozessorientierte Integration von Softwarekomponenten durch XML basierte Workflow Modelle Diplomarbeit f r den integrierten Studiengang Informatik nach Diplompr fungsordung 4 von Bj rn L tkemeier und Sebastian Th ne vorgelegt bei Prof Dr Gregor Engels Lehrstuhl f r Datenbank und Informationssysteme Paderborn 5 Dezember 2001 Danksagung Diese Diplomarbeit entstand im Rahmen unseres Informatikstudiums an der Universit t Paderborn Sie wurde durch Prof Dr Gregor Engels und Dipl Inform Dipl Phys Ralph Depke betreut F r ihre Hilfen und Ratschl ge bei der Erstellung der Arbeit sind wir sehr dankbar Besonderen Dank sagen wir auch der S amp N AG in Paderborn da diese Arbeit in enger Kooperation mit dem Unternehmen entstanden ist F r die betreuende Hilfestellung insbesondere durch Matthew Langham sowie die bereitgestellten Hilfsmittel und Arbeitspl tze bedanken wir uns ganz herzlich Au erdem danken wir der Deutschen Bausparkasse Badenia AG die uns freundlicherweise Dokumentationen und Quellcodes zu ihrem E Business Projekt zur Verf gung gestellt hat Allen anderen die zum Erfolg dieser Diplomarbeit beigetragen haben gilt ebenfalls unser herzlicher Dank Paderborn im Dezember 2001 Bj rn L tkemeier amp Sebastian Th ne Erkl rungen Ich versichere dass ich die kenntlich gemachten Teile dieser Diplomarbeit die als Gruppenarbeit mit Sebastian T
111. Ab schnitt 3 3 Punkt 8 Zu diesem Zweck besitzt jedes Diagramm ein Tag isTransactional welches entweder den Wert TRUE annehmen kann wenn Transak tionalit t sichergestellt werden soll oder FALSE falls dies nicht notwendig ist Um nur einen Teil eines Prozesses als Transaktion ausf hren zu lassen muss dieser als eigenes 7 3 UML Profil f r Prozessdiagramme 135 Prozessdiagramm modelliert werden und mit Hilfe eines Subaktivit tszustands in das bergeordnete Diagramm eingebettet werden Die folgende Tabelle zeigt die Definition des Stereotyps processDiagram Stereotyp processDiagram Basisklasse UML ActivityGraphs ActivityGraph Ober Stereotyp Tag Definitionen isTransactional inputPort outputPort Einschr nkungen Constraints 1 Es gibt genau einen Initialzustand let topState State let states Set State topState oc1lAsType CompositeState subvertex self extendedElement oclAsType StateMachine top states gt one oc11sTypeOf PseudoState and kind initial 2 Es gibt genau einen Endzustand states gt one oc11sTypeOf FinalState Erl uterung Aktivit tendiagramme die als processDiagram klassifiziert sind modellieren ein Prozess diagramm mit dem ein XML basierter Workflow spezifiziert wird Darstellung Falls der Eigenschaftswert von isTransactional wahr TRUE ist wird der Startzustand mit dem Text transactional versehen Die P
112. Ausf hrung ben tigt um die Konsistenz von Dokumenttypen zu gew hrleisten 9 Typisierung von Transitionen Wie in Abschnitt 6 3 2 vorgestellt werden die Tran sitionen in Prozessdiagrammen typisiert Demzufolge m ssen in der XML Beschrei bung der Workflows die m glichen Transitionstypen sowohl entsprechend ihrer Defi nition in Kapitel 6 und 7 festgelegt als auch den einzelnen Transitionen zugewiesen werden k nnen 10 Repr sentation aller sonstigen Sprachelemente von Prozessdiagrammen Da in der XML Beschreibung Prozessdiagramme kodiert werden sollen ohne dass Informa tionen verloren gehen m ssen au er den bis jetzt genannten Punkten auch alle weiteren Sprachelemente die in Kapitel 7 definiert wurden in dem XML Dokument gespeichert werden Hierunter fallen zum Beispiel Informationen ber die Transaktionseigenschaf ten eines Prozesses 11 Format m glichst als bekannter Standard Es w re von Vorteil wenn die Pro zessbeschreibungssprache nicht propriet r entwickelt w rde sondern auf einem allge mein anerkannten Standard beruhte Dadurch w rde sowohl die Unterst tzung durch andere Werkzeuge als auch die Austauschbarkeit mit anderen Partnern erleichtert 12 Konkrete Dokumente f r Benutzer m glichst verst ndlich und lesbar Zwecks besserer Wartbarkeit sollten die zu dem Beschreibungsformat geh rigen XML Doku mente f r einen Benutzer lesbar und verst ndlich sein so dass er prinzipiell leichte nderung auch direkt a
113. Berechnung auf einem Gro rechner vgl B h95 S 8 Um verschiedene Abstraktionsebenen einf hren zu k nnen ist bei den meisten Modellierungsans tzen eine M glichkeit zur Schachtelung von Aufgaben enthalten So kann eine Aufgabe in einer Hierarchisierung in immer feinere Teilaufgaben zerlegt werden bis diese schlie lich als atomare Dienste vorhandener Systeme oder mensch licher Aufgabentr ger in Anspruch genommen werden k nnen Die Modelle auf einer h heren Abstraktionsstufe fassen mehrere Teilaufgaben zu einem Teilprozess zusam men und erlauben so einen besseren berblick besonders bei umfangreichen Workflow Modellen siehe Geo95 S 135 Ein Vorgangs oder Workflow Modell ist die Grundlage f r die nachfolgende Analysephase in der logische Fehler und Engp sse bei der Prozessdurchf hrung gefun den und beseitigt werden sollen Hilfreich ist hierbei die Erweiterung des dynamischen Modells um eine zeitliche Komponente um f r einzelne Aufgaben oder Prozesse zeit liche H chstdauern sowie Start oder Endzeitpunkte festzulegen Nach der Analyse phase dient das Modell und die darin enthaltene Prozessdefinition dem Workflow Management System als Ausgangspunkt f r die Durchf hrung des Workflows 2 3 3 Analyse und Simulation der Modelle Im Rahmen der Modellanalyse unterscheidet man zwischen Testen Analysieren und berwachen von Workflows siehe Geo95 S 136 Durch die Eingabe von Beispiel Daten kann man die Ausf hrung ein
114. Channel F higkeit Benutzerinteraktion 1 1 Administrator Schnittstelle 0 0 Flexibles Workflow Modell f r Gesch ftsregeln Transaktionsunterst tzung O Plattformunabh ngigkeit 1 Behandlung nicht implizit vorgesehen aber mit vorhandenen Mitteln realisierbar 2 Im Modell k nnen nur bereits vorhandene Komponenten verwendet werden vorhanden nicht vorhanden o ansatzweise vorhanden Tab 11 1 Bewertung von bisherigem und neuem System im Vergleich Zum Vergleich zeigt die Tabelle die Erf llung der Anforderungen sowohl f r das bishe rige System sunShine der S amp N AG wie es in Abschnitt 4 3 vorgestellt wurde als auch f r das neue System sunFlow das in sunShine integriert worden ist Dadurch werden die erzielten Verbesserungen gegen ber der fr heren Situation offensichtlich Es zeigt sich dass die wesentlichen Ziele und Anforderungen an die prozessorientierte Integra tionsumgebung erf llt werden konnten 12 1 Zusammenfassung 245 12 Schlussbetrachtungen Im letzten Teil der Diplomarbeit wurde die praktische Umsetzung der entwickelten Konzepte dokumentiert Damit schlie t sich der Kreis von Anforderung Konzeption und Umsetzung Zum Schluss wollen wir in diesem Kapitel die erzielten Ergebnisse zusammenfassen und einen Ausblick auf die noch offenen Fragen geben 12 1 Zusammenfassung Ausgangspunkt in der Einleitung zur Diplomarbeit vgl Kapitel 1 waren die folgenden Problemstellungen und
115. Dateiname einge geben oder eine existierende Datei ausgew hlt werden die berschrieben werden soll Die Datei in der das Projekt gespeichert wird erh lt automatisch die Dateiendung sfp sunEFlow project file Save Project As Es erscheint ein Dateiauswahldialog in der ein Dateiname eingege ben oder eine existierende Datei ausgew hlt werden kann die berschrieben werden soll Das Projekt wird dann in dieser Datei die automatisch die Dateiendung sfp sunElow project file erh lt gespeichert Close Project Schlie t das Projekt Zuvor erscheint eine Sicherheitsabfrage ob das Projekt gespeichert werden soll New Package Durch diese Aktion l sst sich ein neues Package anlegen Es erscheint ein Eingabedialog in dem der Name einschlie lich aller bergeordneten Packages in denen es enthalten sein soll jeweils durch Punkt getrennt eingegeben werden muss 9 2 Bedienung des Prozesseditors 195 Load Package Hier l sst sich ein existierendes Package dem Projekt hinzuf gen um seine Bestandteile zu bearbeiten Es erscheint ein Eingabedialog in dem der Name ein schlie lich aller bergeordneten Packages jeweils durch Punkt getrennt eingegeben werden muss 9 2 3 Eingabemasken Je nachdem welche Komponente im Projektbaum mit der Maus ausgew hlt wurde erscheint im rechten Bereich des Editors eine zugeh rige Eingabemaske In ihr werden alle Informationen die mit der Komponente verkn pft sind angezeigt und k nnen dort auc
116. DocTypes Def 6 12 OpenPort alllnstances c OpenPorts Def 6 13 Abb 7 4 Zusammenhang zwischen Datentypen und Mengen Die Vererbungsrelation von DocType zu OpenDocType f hrt dazu dass jede DocType Auspr gung gleichzeitig vom Typ OpenDocType ist Dies spiegelt die in Def 6 12 angegebene Relation DocTypes c OpenDocTypes wider Analoges gilt f r die Verer bungsbeziehung zwischen Port und OpenPort vgl Def 6 13 Die Methode binding bindTo DocType DocType des Datentyps OpenDocType ist eine Umsetzung der in Def 6 14 definierten Hilfsfunktion binding Sie muss ent sprechend dieser Funktion mathematisch korrekt implementiert werden Analoges gilt f r die Methode binding bindTo Port Port des Datentyps OpenPort die der Funktion aus Def 6 15 entsprechen muss Die Methode isSubsetOf super Port Boolean des Datentyps Port liefert genau dann true zur ck wenn die Teilmengen Beziehung f r Ports entsprechend Def 6 9 erf llt ist Die Methode union port Port Port dient zur Bildung eines Ports der die Dokumenttypen zweier Ports vereinigt Sie wird bei der Berechnung eines Ausgangsports von Oder Zusammenf hrungen siehe n chster Ab schnitt ben tigt F r den Datentyp Port wird in OCL die folgende Hilfsfunktion is any defi niert die untersucht ob ein Port allein aus der Angabe des Platzhalters any besteht und damit L p XmlDocs gilt Ein solcher Port hei t unbeschr nkter P
117. Element namespace String elemName String lt xsd complexType name ElementType gt lt xsd attribute name element type xsd string use required gt lt xsd attribute name namespace type xsd string gt lt xsd complexType gt Abb 8 5 PML Schema Fragment f r XmlElement 8 3 Process Markup Language PML 173 Platzhalter Statt konkrete XML Elemente zu spezifizieren k nnen in Ports auch sogenannte Platz halter vorkommen Es gibt drei Arten zu denen die in Abbildung 8 6 dargestellten XML Typen Any CopyRoot und CopySubs geh ren F r CopyRoot und CopySubs kann jeweils durch lt except gt eine Menge von XML Elementen definiert werden die beim Binden nicht bernommen werden sollen Es ist zu beachten dass zur Beschrei bung eines CopySubs Platzhalters in PML zwei XML Elemente der Typen CopyRoot Type und CopySubsType kombiniert werden m ssen damit sowohl das Attribut rootExceptions als auch subExceptions abgebildet werden kann vgl Abbildung 8 8 dataType Placeholder abstract dataType dataType AnyPlaceholder CopyPlaceholder abstract rootExceptions XmlElements dataType dataType CopyRoot CopySubs subExceptions XmlElements lt xsd complexType name AnyType gt lt xsd complexType name CopyRootType gt lt xsd sequence gt lt xsd element name except type ElementType minOccurs 0 maxOccurs unbo
118. Element aus OpenDocTypes wird durch Ableitung des Nicht Terminals OpenDoctype der EBNF Grammatik notiert Sei dazu ein beliebiger offener Dokumenttyp type gegeben mit type root subs OpenDocTypes DocTypes und subs s Sn Dann schreibt man a copyRoot_except re rem S4 Sn falls root copyRoot rootExceptions e CopyPlaceholder und rootExceptions re rem b copyRoot_except re4 rem copySubs_except se4 se S1 Sn falls root copySubs rootExceptions subExceptions e CopyPlaceholder und rootExceptions re rem und subExceptions se se c Das Postfix _except kann entfallen wenn die Menge der Ausnahmen leer ist d h rootExceptions bzw subExceptions Beispiele copyRoot http namespacel elementA http namespace 2 elementB copyRoot copySubs_except elementA elementB copyRoot_except elementC Def 6 13 Offene Ports OpenPorts P OpenDocTypes Ein offener Port ope OpenPort ist ein Port bei dem durch den Gebrauch von Platz haltern die sp ter an konkrete Werte gebunden werden die Dokumentmenge der konformen XML Dokumente offen gehalten werden kann Die Platzhalter wurden 116 Kapitel 6 XML Prozesse und Prozessdiagramme durch die hier verwendeten offenen Dokumenttypen eingef hrt Aus der Beziehung DocTypes c OpenDocTypes folgt direkt die Beziehung Ports c OpenPorts Syntax Wie im Nicht Termin
119. Evaluierung vorhandener Workflow Systeme L tkemeier bis auf 4 1 Microsoft BizTalk Th ne Evaluierung vorhandener Workflow Modellierungssprachen L tkemeier bis auf 5 2 Ereignisgesteuerte Prozessketten Th ne XML Prozesse und Prozessdiagramme 6 1 Konzeption von XML Prozessen Th ne 6 2 Modellierung mit Prozessdiagrammen L tkemeier 6 3 Modellierung der Dokumenttypen Th ne 6 4 Bewertung L tkemeier Metamodell f r Prozessdiagramme 7 1 Das UML Metamodell L tkemeier 7 2 UML Erweiterungsmechanismen Th ne 7 3 UML Profil f r Prozessdiagramme Th ne 7 4 Implementierung des erweiterten Metamodells Th ne 7 5 Validierung von Prozessdiagrammen L tkemeier 7 6 Automatische Portberechnung Th ne Beschreibung von Prozessen in XML 8 1 Anforderungen an Prozessbeschreibungssprachen Th ne 8 2 Evaluierung vorhandener Prozessbeschreibungssprachen Th ne bis auf 8 2 1 Beschreibung von Prozessen mit XLANG L tkemeier 8 3 Process Markup Language PML L tkemeier 8 4 Werkzeuge f r die PML Verarbeitung L tkemeier Modellierungswerkzeug f r Prozessdiagramme L tkemeier Ausf hrung von XML Prozessen L tkemeier bis auf 10 3 Fehlerbehandlung Th ne Evaluierung anhand einer Fallstudie Th ne Schlussbetrachtungen 12 1 Zusammenfassung Th ne 12 2 Ausblick L tkemeier
120. JoinedDocument documents 51 else if state is ServiceState then 52 document state getService invoke document 53 else 54 end if 55 return document Abb 10 2 Algorithmus f r die Ausf hrung eines Prozesses Aus Platzgr nden zeigt die Abbildung nur auszugsweise die wichtigsten Bestandteile des Ausf hrungsalgorithmus Die zentrale Methode ist executesection die sowohl dazu verwendet wird einen gesamten Prozess als auch parallele Str nge im Zusammenhang mit Fork Zust nden auszuf hren Sie arbeitet Schritt f r Schritt den Prozess ab und veranlasst die notwendigen Aktivit ten wie Transformation des Migra tionsdokuments Zeile 11 Validierung gegen Ports Zeile 14 und 16 usw F r jeden Zustand wird mit Hilfe der Methode getFollowing der Folge zustand bestimmt Zeile 7 Die Abbildung zeigt die dazu notwendigen Berechnungen f r Decision Fork und solche Zust nde die genau einen Nachfolger haben Bei Fork Zust nden wird hier der zugeh rige Join Zustand zur ckgegeben in dem die parallelen Teilstr nge wieder zusammengef hrt werden Ihre Ausf hrung geschieht in der Methode execute indem f r jeden Strang rekursiv die Methode executeSection aufgerufen wird Sind alle Str nge gestartet wartet die Ausf h rung auf ihre Terminierung Zeile 49 Jeder Strang meldet sich sobald er beendet ist und bergibt dabei zugleich sein Migrationsdokument Zeile 19 Erst wenn alle Str nge bis zum Ende abgearbeitet
121. Kann auch passieren dass die beiden ausgew hlten Zust nde sich berhaupt nicht verbinden lassen In diesem Fall erscheint im Editor eine entsprechende Meldung Der Benutzer muss dann zun chst einen geeigneten Transitionstyp erzeugen dessen Stylesheet das Migrationsdokument so transformiert dass eine Verbindung der Zust nde m glich wird Dieses Vorgehen bietet den Vorteil dass Inkonsistenzen im Prozessdiagramm von vornherein vermieden werden indem stets darauf geachtet wird dass nur Ports verkettet werden die die Teilport Bedingung erf llen Aus dem Kompatibilit tssatz 6 10 Abschnitt 6 3 3 folgt dann dass die Verarbeitung des Dokuments durch die Services des Diagramms konsis tent ist Zu beachten ist dass im Editor aus Gr nden der bersichtlichkeit nur die Transitionstypen zur Verf gung stehen deren Package sich im Projekt befindet Falls ein anderer Typ verwendet werden soll muss zun chst sein Package in das Projekt aufgenommen werden F r den Guard einer Transition sind drei F lle zu unterscheiden 1 Wenn der Quellzustand ein Fork Zustand ist kann f r die Transition ein Guard angeben werden Im Dialog kann man dann im Feld XPath Expression den gew nschten XPath Ausdruck angeben 2 Wenn der Quellzustand ein Decision Zustand ist muss f r die Transition ein Guard angeben werden Im Dialog muss man entweder im Feld XPath Expression den gew nschten XPath Ausdruck angeben oder else ausw hlen um zu si
122. Men in dem die m glichen Aktionen angeboten werden Alle Elemente lassen sich au erdem bei gedr ckter linker Maustaste beliebig verschieben und neu positionieren Hinzuf gen von Zust nden Einem Prozessdiagramm lassen sich bei Bedarf neue Zust nde hinzuf gen Dazu dienen die Schaltfl chen oben in der Zeichenfl che Dort finden sich Schaltfl chen zur Erzeu gung von Service Subactivity Fork Join Decision und Merge Zust nden Eine Besonderheit stellen Synchronisationszust nde dar Mit Hilfe der Schaltfl che ganz rechts f gt man eine komplette Synchronisationsstelle bestehend aus Synchfork Synchjoin und Synch Zustand in das Prozessdiagramm ein Diese lassen sich auch nur als Ganzes wieder l schen da sie ausschlie lich in dieser Konstellation erlaubt sind Nach dem Bet tigen einer Schaltfl che wird der gew nschte Zustand oben links in der Zeichenfl che eingef gt er kann dann mit der Maus an die gew nschte Stelle verschoben werden Um seine Eigenschaften anzusehen bzw zu editieren muss er in der Zeichenfl che oder im Projektbaum selektiert werden Wenn dann auf den Kartei reiter Properties umgeschaltet wird erscheint die passende Eingabemaske Abbildung 9 10 zeigt die Maske eines Service Zustands fi a kre Pre ide Mii m Fia u u E Tei Deny Prager i Pkk duran prinrabira Si fegh PE CA Ski Gerd Tini Ab Pisa ay a Terai ii i Ta LET ali 4 WE Euer F Yi T LET LEN Aia Taisia Dee
123. Mit einer EPK und ihren Konstrukten f r Informationsobjekte und organisatorische Einheiten lassen sich Daten Aufgaben und Organisationen verbinden Diese Methode bildet somit das zentrale Element innerhalb des Business Process Engineerings Kel99 S 160 Die EPK muss dabei aber immer im Zusammenhang mit anderen Teilmodellen des Unternehmens gesehen werden mit denen etwa die Struktur von Organisation und Daten modelliert werden So ergibt sich ein umfangreiches Gesamt modell des Unternehmens Zur Definition der Zusammenh nge mit anderen Modellen findet sich in Kel99 S 164f der Verweis auf ein Metamodell zur EPK Struktur das eine bersicht ber und ein grundlegendes Verst ndnis f r den Modellaufbau erm glicht 5 2 Ereignisgesteuerte Prozessketten 63 F r eine EPK gibt es verschiedene Darstellungsstrategien auf verschiedenen Abstraktionsstufen H ufig sieht man zum Beispiel die so genannte schlanke EPK eine Variante bei der zum besseren berblick zun chst nur der Kontrollfluss zwischen den Ereignissen und Aufgaben zusammen mit den Verkn pfungsoperatoren beschrieben wird Die sonst blichen organisatorischen Einheiten und Informationsobjekte werden dabei vorerst ausgelassen siehe Kel99 S 160f Zur Analyse und Modellierung eines Unternehmens und der dort auszuf hren den Abl ufe werden sogenannte Referenzmodelle angeboten Dabei handelt es sich um Bibliotheken von Prozessmodellen die von Beratungsuntern
124. ModelElement erm glicht ist Die Angabe eines Datentyps f r jeden Paramter ist nicht n tig weil f r Prozessdiagramme zun chst nur der Datentyp String vorgesehen ist vgl Ab schnitt 6 2 2 Klassendiagramm f r das dynamische Modell Zum dynamischen Modell geh ren die einzelnen Prozessdiagramme mit ihren Zust n den und Transitionen vgl Abschnitt 6 2 Das folgende Klassendiagramm zeigt den Ausschnitt aus dem Metamodell durch den die dynamischen Modellelemente realisiert werden sollen 150 Kapitel 7 Metamodell f r Prozessdiagramme ContainerElement ProcessDiagram ModelElement name String 1 source outgoing inputPort Port outputPort Port transactional Boolean stateVertex lt 1 0 1 name State Vertex Transition Guard 1 0 1 FREE inputPort Port 1Harget tincoming expression String outputPort Port TransitionType sourcePort Port targetPort OpenPort transformation Expression Atransitions TypedTransition type 1 Abb 7 9 Klassendiagramm f r das dynamische Modell ProcessDiagram StateVertex Die Klasse ProcessDiagram realisiert das Stereotyp processDiagram aus Abschnitt 7 3 2 mit dem UML Aktivit tendiagramme als Prozessdiagramme ausgezeichnet werden Diese Klasse bernimmt damit die Rolle der Metaklasse ActivityDiagram Die Vererb
125. Modell des Prozesses Die Verkettung der einzelnen Zust nde entsprechend der Transitionen geschieht mit Hilfe eines Elements lt next gt das jeweils auf einen Nachfolgezustand verweist Es steht innerhalb der typabh ngigen PML Elemente und wird im Zusammenhang mit Transitionen weiter unten beschrieben Das Stereotyp stateWithPorts besitzt eine Reihe von Constraints die Aussa gen ber die Ports in Abh ngigkeit vom Typ des Zustands machen Diese Einschr n kungen lassen sich nicht in einem XML Schema ausdr cken da es sich dabei um eine Grammatik handelt die lediglich die Struktur sowie die Wertebereiche der Inhalte von XML Dokumenten spezifiziert Es existiert jedoch kein Mechanismus mit dem sich Bedingungen an die konkreten Inhalte eines Dokuments formulieren lassen Eine PML Dokument kann daher im Prinzip unzul ssige Zustandsbeschreibungen enthalten Aus Platzgr nden sind in der folgenden Abbildung mehrere XML Typen nicht dargestellt sie k nnen auf der CD ROM zur Arbeit nachgesehen werden 8 3 Process Markup Language PML 181 stereotype stateWithPorts Tags inputPort Port 1 outputPort Port 1 lt xsd complexType name StateType gt lt xsd sequence gt lt xsd element name inputPort type PortType gt lt xsd element name outputPort type PortType gt lt xsd choice gt lt xsd element name initial type InitialType gt lt xsd element name final type FinalType gt
126. PML DOM in die interne Objektstruktur ist dann nur ein mal zu investieren Das Einlesen und Umwandeln von PML Dateien bernimmt die aus Abschnitt 8 4 1 bekannte Klasse PMLImporter Schnittstellen zu den Klassen des Metamodells Um einen Prozess anhand der internen Datenklassen ausf hren zu k nnen ben tigt der Interpreter zus tzliche Funktionalit t von diesen Klassen die in ihnen zun chst nicht enthalten ist Zu diesem Zweck verwenden wir das Entwurfsmuster Adapter mit dem sich die Schnittstelle der Datenklassen anpassen l sst vgl Gam96 S 171 Abbildung 10 3 verdeutlicht den Einsatz des Musters 218 Kapitel 10 Ausf hrung von XML Prozessen AbstractStateAdapter getFollowing AbstractState validatelnputPort boolean UMLStateAdapter 1 adapts gt 1 getFollowing AbstractState gt StateVertex validatelnputPort boolean Abb 10 3 Adapterklassen Durch die Verwendung der abstrakten Klasse AbstractStateAdapter wurde die M glich keit offengelassen sp ter ein anderes Datenmodell zu Grunde zu legen ggf doch den PML DOM Baum falls dies sinnvoller erscheint Es muss dann lediglich die Klasse UML StateAdapter die die Anpassung f r unsere Datenstruktur realisiert durch eine andere Implementierung ersetzt werden Der Rest des Interpreters bleibt dabei unver n dert Leider konnte zur Anpassung der Datenstruktur in diesem Fall nicht die aus Abschnitt 7 4 bekannte K
127. Parameter besitzen Ihre Namen im UML Modell in der Metaklasse Parameter festgelegt werden durch das Attribut name der Elemente lt parameter gt bestimmt Die Angabe eines Typs ist nicht erforder lich da implizit der Typ String vorausgesetzt wird vgl Abschnitt 6 2 2 Es ist jedoch darauf zu achten dass die Reihenfolge der lt parameter gt Elemente mit der Rei henfolge der Parameter in der zugeh rigen Methodensignatur bereinstimmen muss stereotype service Tags image Geometry 0 1 inputPort Port 1 outputPort OpenPort 1 lt xsd complexType name ServiceType gt lt xsd sequence gt lt xsd element name image type ImageType minOccurs 0 gt lt xsd element name inputPort type PortType gt lt xsd element name outputPort type OpenPortType gt lt xsd element name parameter type ParameterType minOccurs 0 maxOccurs unbounded gt lt xsd sequence gt lt xsd iattribute name method type xsd string use required gt lt xsd complexType gt Abb 8 11 PML Schema Fragment f r Services 178 Kapitel 8 Beschreibung von Prozessen in XML Abbildung 8 12 zeigt beispielhaft die Beschreibung eines Konnektors lt package name de sundn sunflowexamples gt lt components gt lt component interface IComponent1 gt lt service method serviceA gt lt image href gt lt inputPort gt lt inputPort gt lt outputPort gt lt out
128. Port mag f r viele Services ausreichend sein es gibt aber auch Services die nicht nur einen sondern mehrere verschiedene Dokumenttypen verarbeiten oder als Ergebnis produzieren k nnen Um auch solche Serviceschnittstellen durch Ports spezifizieren zu k nnen soll ein Port aus einer beliebig gro en Menge von XML Elementen bestehen Der Port mit nur einem XML Element ist damit nur noch ein Spezialfall des allgemeineren Konzepts Insbesondere kann es auch Services geben die jedes beliebige XML Dokument 6 3 Modellierung der Dokumenttypen 95 verarbeiten k nnen Dies ist zum Beispiel dann der Fall wenn der Service die Doku mentinhalte nicht direkt analysiert und verarbeitet sondern das Dokument als Siche rungskopie in einer Datenbank archiviert F r derartige Services kann der Port den Platzhalter any enthalten der ausdr ckt dass beliebige Dokumente f r diese Schnitt stelle erlaubt sind http namespace1 elemA http namespace1 elemA any http namespace1 elemB http namespace2 elemB erlaubt alle g ltigen XML erlaubt alle g ltigen XML erlaubt alle g ltigen XML Dokumente mit Wurzelelement Dokumente mit Wurzelele Dokumente mit beliebigem elemA aus dem Namensraum ment elemA oder elemB aus Wurzelelement http namespace1 http namespace1 oder mit elemB aus http Inamespace2 Tab 6 1 Beispiele f r Ports Existenz optionaler Unterelemente Wie bereits dargelegt wird f r ein XML Element im z
129. Prozess diagramme beschreiben lassen vgl Kapitel 6 Die Prozessdiagramme sollen von ihrer Semantik her so gut definiert sein dass sie sich ggf nach automatisierten Konvertierun gen als Eingabe f r eine maschinelle Ausf hrung der XML Prozesse durch das Workflow Management System eignen Somit ist es ein wichtiges Ziel die Implemen tierung der Workflows und die damit verbundene Konfiguration der Komponenten auf die Erstellung eines graphischen Modells zu beschr nken Alles brige kann von den Werkzeugen automatisiert erledigt werden Die gew hlte Modellierungssprache muss die im Abschnitt 3 3 gestellten Anfor derungen erf llen Lediglich die Forderung nach einem Zeitmodell ist bei der Modellie rung der systemorientierten Informationsprozesse nicht von entscheidender Wichtigkeit Aussagen ber Starttermine wie fr hestens am oder Endtermine wie sp testens bis zum und die damit vom WFMS zu leistende termingerechte Vorlage des Auftrags beim zust ndigen Bearbeiter finden sich vor allem bei interaktiven Prozessen mit menschlichen Sachbearbeitern vgl B h95 S 8 Bei den hier zu betrachtenden systemorientierten Workflows ist es lediglich ein Ziel die gesamte Ausf hrungszeit zu minimieren Aus den praktischen Anforderungen der Fallstudie ergeben sich keine Anzeichen f r einen dringenden Bedarf an einer ausf hrlichen Zeitmodellierung Aus diesen Gr nden werden wir uns darauf beschr nken Zeitmodelle bei Modellierungs
130. Prozessdia gramms Zwecks effizienteren Zugriffs gibt es eine unidirektio nale Referenz von ProcessDiagram auf ein Objekt der Klasse Diese Klasse repr sentiert eine Oder Verzweigung Diese Klasse repr sentiert eine Oder Zusammenf hrung 7 4 Implementierung des erweiterten Metamodells 153 SynchState Vertex Diese Klasse repr sentiert einen Synchronisationszustand vgl Omg01 2 12 2 15 und entspricht der UML Metaklasse SynchState SynchforkStateVertex Diese Klasse repr sentiert eine Und Verzweigung vor einem Synchronisationszustand vgl Abschnitt 8 3 3 SynchjoinStateVertex Diese Klasse repr sentiert eine Und Zusammenf hrung nach einem Synchronisationszustand vgl Abschnitt 8 3 3 ForkState Vertex Diese Klasse repr sentiert eine Und Verzweigung Die Assozia tion zum zugeh rigen JoinStateVertex dient dem effizienteren Zugriff auf die korrespondierende Zusammenf hrung JoinStateVertex Diese Klasse repr sentiert eine Und Zusammenf hrung Die Assoziation zum zugeh rigen ForkStateVertex dient dem effi zienteren Zugriff auf die korrespondierende Verzweigung Flexible Zugriffsschicht auf Elemente des Datenmodells Das soeben vorgestellte Datenmodell erlaubt eine einfache Implementierung von Pro zessdiagrammen in objekt orientierten Programmiersprachen Im Rahmen der Diplom arbeit wurde das Modell mit Java umgesetzt Um eine m glichst hohe Wiederverwend barkeit zu gew hrleisten bietet es sich an diese Implementier
131. Rollen ist dabei n tzlich um die Definition der einzelnen Workflow Modelle zu anonymisieren also unabh ngig von konkreten Mitarbeitern zu gestalten Vielmehr werden Aufgaben an abstrakte Stellen delegiert denen mit Hilfe des Organisationsmodells konkrete Per sonen zugeordnet sind In B h95 werden au erdem verschiedene Arten von Bezieh ungen zur Beschreibung der Organisationselemente in der statischen Struktur erg nzt Dazu geh ren Aspekte der Unternehmenshierarchie Zugeh rigkeit zu Arbeitsgruppen Bestimmung von Vorgesetzten und Vertretern sowie von Kompetenzen und Zust ndig keiten Die Forderung nach einem ausf hrlichen Unternehmens oder Organisations modell ist vor allem zur Realisierung betriebswirtschaftlicher Gesch ftsprozesse von gro er Bedeutung bei denen eine automatische Zuordnung von Aufgaben an daf r zust ndige Stellen und geeignete Bearbeiter gew hrleistet werden muss Bei system orientierten Prozessen wie sie in dieser Arbeit betrachtet werden sollen schwindet dagegen die Bedeutung der Mitarbeiter als Aufgabentr ger zugunsten von Software komponenten die mit der Erf llung der einzelnen Aktivit ten beauftragt werden Trotzdem ist f r das Workflow Management System ein strukturelles bzw sta tisches Modell der Aufgabentr ger n tig auch wenn es sich bei diesen Aufgabentr gern um Softwarekomponenten handelt Nur solche Komponenten die im Strukturmodell aufgef hrt sind k nnen bei der Definition des Workf
132. Softwarekomponente jeweils die Schnittstellen dieser speziellen Komponente unterst tzen In GruO1 findet sich ein hnliches Konzept unter der Bezeichnung Adaptoren Dort hei t es Since the interfaces used to access the external systems are very diffe rent each one is connected to the central middleware backbone via an individual adaptor siehe Gru01 S 4 Es ist au erdem nicht davon auszugehen dass alle zu integrierenden Software komponenten das vom WFMS intern benutzte Datenformat unterst tzen Damit ergibt sich als zweite wichtige Aufgabe f r die Konnektoren eine Transformation des internen Datenformats in ein f r die Softwarekomponente verst ndliches Format mit anschlie Bender R cktransformation Die folgende Grafik zeigt exemplarisch wie ein SQL Konnektor als Verbin dungsbr cke zu einer Datenbank eingesetzt wird um SQL Befehle auszuf hren die in dem Migrationsdokument spezifiziert sind Der Konnektor hat eine Schnittstelle zum WFMS die das dort f r die Migrationsdokumente verwendete Datenformat versteht sowie eine Schnittstelle zum Datenbanksystem die unter Umst nden auf anderen For maten oder Protokollen basiert Datenbank gt Dokument SQL Konnektor WFMS Transformiertes Dokument Abb 6 2 Prinzip eines Konnektors Da der Konnektor in diesem Beispiel speziell die Umsetzung zwischen WFMS und Datenbank vornimmt ist er nur f r die Einbindung der Datenbank gee
133. Zur Zeit arbeiten mehrere Unternehmen an entsprechenden Realisierungen siehe Moh01 S 18 Das augenblicklich einzige fertig gestellte und auch bekannteste Pro dukt in diesem Bereich ist der von Microsoft entwickelte BizTalk Server 2000 der im Folgenden n her vorgestellt werden soll 4 1 1 Systemarchitektur von BizTalk Server 2000 Microsofts BizTalk Server 2000 erlaubt neben der Interpretation von BizTalk Doku menten und Nachrichten auch die Entwicklung komplexer Gesch ftsprozessmodelle und deren Ausf hrung Das dabei eingesetzte Workflow Management System basiert auf dem Austausch von BizTalk Nachrichten und dem damit verbundenen Aufruf von Funktionen anderer gegebenenfalls auch externer Systeme Der Fortschritt der Abl ufe kann ber Wochen und Monate hinweg verfolgt werden BizTalk Server will damit langlebige lose gekoppelte Fl sse in verteilten Umgebungen wie einer unternehmens bergreifenden Wertsch pfungs oder Lieferkette unterst tzen Obwohl das System Anwendungen auf verschiedenen Plattformen integrieren soll ist es selbst nicht plattformunabh ngig Die Systemvoraussetzungen zum Einsatz des BizTalk Servers sind vielmehr stark von Microsoft Basisprodukten wie dem Betriebssystem Windows 2000 gepr gt siehe MicO1 Wie in MohOl S 19 dargestellt handelt es sich bei BizTalk Server 2000 im Wesentlichen um eine Sammlung verschiedener Werkzeuge zur effizienten Anwen dungsintegration Zur Workflow Modellierung kann man das gr
134. abe einer unterschiedlichen Anzahl von Dokumenten vorgesehen werden muss Aus diesen Gr nden favorisieren wir das Doku mentmigrationsmodell mit einem impliziten Datenfluss entlang des Kontrollflusses Dokumentmigration versus zentraler Datenspeicher Um die Workflow relevanten Daten f r alle Aktivit ten zugreifbar zu machen sind prinzipiell zwei verschiedene Ans tze denkbar Bei dem in dieser Arbeit zu Grunde liegenden Dokumentmigrationsmodell findet wie bereits beschrieben ein Dokument fluss durch die Aktivit ten des Prozesses statt der mit dem Kontrollfluss bereinstimmt Im Workflow Referenz Modell wird in diesem Zusammenhang von direktem Daten austausch gesprochen Danach werden durch geeignete Mechanismen die Daten an sich und nicht eine Referenz darauf an die Aktivit ten bergeben data is physi cally transferred to the next activity as part of the activity navigation within the pro cess aus Wmc95 S 26 Nach Ausf hrung einer Aktion m ssen die Daten wieder zur ck an das WFMS bertragen werden 6 1 Konzeption von XML Prozessen 79 Demgegen ber befinden sich im Falle eines indirekten Datenaustauschs die Workflow relevanten Daten in einem gemeinsamen zentralen Speicher der beispiels weise durch eine Datenbank realisiert werden k nnte Jede Komponente des Prozesses erh lt einen Zugriffspfad mit dessen Hilfe sie die Daten lesen oder ver ndern kann Auf diese Weise sind die f r die Ausf hrung des Prozesse
135. ablauforientierte Modelle mit bedingten Verzwei gungen wie etwa Zustandsmaschinen realisiert werden kann vgl z B Oes97 Ein Workflow Management System muss die Behandlung von Ausnahmezust n den vorsehen damit das System stets in einen konsistenten Zustand verbleibt vgl B h95 S 13ff Diese Forderung kann als Einhaltung von Transaktionseigen schaften bezeichnet werden Dazu z hlt beispielsweise das Wiederaufsetzen abgebrochener Prozesse nach einem Systemausfall oder das R ckg ngigmachen von Prozessen bei deren Ausf hrung ein Fehler aufgetreten ist Zu diesem Zweck kann es notwendig sein die Prozessabl ufe zu protokollieren Das WFMS sollte plattformunabh ngig sein damit es nach m glichen nderun gen an der Systemumgebung weiterhin einsatzf hig bleibt 3 3 Anforderungen an Workflow Modellierungssprachen 31 3 3 Anforderungen an Workflow Modellierungssprachen Um den Modellierungsprozess f r Workflow Modelle systematisch zu unterst tzen bedarf es einer geeigneten Sprache mit der ein Systemingenieur die Modelle spezifizie ren kann Im Zusammenhang mit den im vorherigen Abschnitt definierten Forderungen an Workflow Management Systeme bzw deren Workflow Modelle ergeben sich bestimmte Anforderungen die eine geeignete grafische Modellierungssprache erf llen muss Die Modellierungssprache sollte eine visuelle Sprache sein damit man sich ein anschauliches Bild von den modellierten Prozessen machen kann Eine textuel
136. achbearbeiter bleibt dann die weitere Bearbeitung berlassen Er k nnte z B Informationsmaterial ber attraktive Anlagem glichkeiten an den Kunden verschicken oder ein pers nliches Beratungsgespr ch vereinbaren Sobald beide Teilprozesse beendet sind kann ein Ergebnisdokument an den Kunden ausgegeben werden damit er ber Erfolg oder Scheitern seines Auftrags infor miert wird Falls Fehler aufgetreten sind wurden diese von den verschiedenen Kompo nenten in die XML Daten geschrieben Lag kein Fehler vor k nnte das XML Ausgabe dokument beispielsweise folgenderma en aussehen lt transaktion gt lt status gt noError lt status gt lt transaktion gt In den folgenden Abschnitten sollen diejenigen Sprachelemente von Prozessdiagram men die eine Erweiterung von UML Aktivit tendiagrammen darstellen in Bezug auf ihre Semantik ausf hrlich betrachtet werden Dabei entspricht jeder Abschnitt der Umsetzung einer Anforderung aus Kapitel 3 6 2 Modellierung mit Prozessdiagrammen 87 6 2 1 Aktivit ten zur Komponentenintegration Der Sinn jedes Aktivit tszustandes in einem Prozessdiagramm ist es eine bestimmte Softwarekomponente in den Workflow zu integrieren Sie ist aus Sicht des Prozess interpreters als Black Box anzusehen die als Eingabe das XML Dokument das durch den Prozess wandert erh lt und beliebige Daten daraus lesen Ver nderungen daran vornehmen und externe Aktionen ausf hren kann Beim Beenden der Aktivit t n
137. afische Werkzeug Orchestration Designer benutzen Die damit erstellten Ergebnis Modelle werden in das XML Format XLANG bersetzt und vom XLANG Scheduler ausgef hrt Der Scheduler ruft bei der Durchf hrung die BizTalk Messaging Services auf In Verbindung mit einem Messaging Manager wird damit der Austausch von XML Nachrichten und BizTalk Dokumenten als Basiskonzept des BizTalk Servers realisiert Als Administra tionsschnittstelle zur Verwaltung der Server Eigenschaften und der laufenden Prozess instanzen dient das Server Administration Tool Die Verfolgung einzelner Nachrichten kann mit dem Document Tracking geschehen Des Weiteren gibt es einen Editor zur visuellen Definition der Nachrichtenformate und einen Mapper zur Definition von Abbildungen zwischen zwei verschiedenen Dokumentformaten Diese Abbildung kann mit Hilfe von XSLT automatisch in eine Konvertierungsroutine umgesetzt werden BizTalk Server 2000 bietet keine Integration eines Internet Portals mit dem wie in Abschnitt 3 2 gefordert die Prozesse ausgel st und ihre Resultate pr sentiert werden k nnten Insbesondere wird in diesem Zusammenhang kein Multi Channel Ansatz verfolgt um verschiedene Typen von Endger ten bedienen zu k nnen 38 Kapitel 4 Evaluierung vorhandener Workflow Systeme 4 1 2 Komponentenintegration mit BizTalk Server 2000 Durch das Versenden von BizTalk Dokumenten und Nachrichten spricht der BizTalk Server andere Komponenten und externe Systeme an Daf
138. al OpenPort der EBNF Grammatik aus Abschnitt 6 3 1 definiert wird ein offener Port schlicht durch die Auflistung der enthaltenen Doku menttypen notiert Um die Bindung eines offenen Ports an einen nicht offenen Port zu definieren wollen wir zun chst die Bindung eines offenen Dokumenttyps mit Platzhaltern an einen nicht offenen Dokumenttyp als Hilfsfunktion definieren Dazu m ssen mehrere F lle unter schieden werden 1 Wenn der offene Dokumenttyp nur den Platzhalter copyRoot tr gt und das zu bin dende Wurzelelement nicht in die Menge der Ausnahmen f llt bernehme dieses Wurzelelement anstelle des Platzhalters ii Wenn der offene Dokumenttyp beide Platzhalter copyRoot und copySubs enth lt und das zu bindende Wurzelelement nicht in die Menge der Ausnahmen f llt verfahre wie bei i und bernehme zus tzlich die Unterelementliste abz glich der spezifizierten Ausnahmen iii Wenn das zu bindende Wurzelelement in die Menge der Ausnahmen f llt wird das leere Wort zur ckgegeben Als formale Definition ergibt sich somit Def 6 14 Die Hilfsfunktion binding binding OpenDocTypes DocTypes xDocTypes gt DocTypes Vo root subs e OpenDocTypes vd root subs e DocTypes root subs falls root CopyPlaceholder mit root copyRoot rootExceptions root rootExceptions roota subs U subs subExceptions binding 0 d falls root CopyPlaceholder mit root
139. alen Ereignisgesteuerten Prozessketten lie e sich dieses Ziel ohne Verfeinerung des Modells nicht erreichen Au erdem ist abzuw gen inwiefern die Fokussierung auf die Ereignissteuerung bei einer EPK f r XML Prozesse berfl ssig oder vielleicht sogar st rend sein k nnte Sind Ereignisse f r den Entwurf von Prozessdiagrammen nicht unbedingt n tig und w rden sie nur eingef gt weil das Modell der EPK diese fordert k nnte die Darstel lung unn tig kompliziert und aufgebl ht werden Dies h tte negative Einfl sse auf die berschaubarkeit und Verst ndlichkeit der Entw rfe Trotz der Erfolge des EPK Modells im Bereich der Gesch ftsprozessmodellierung ist es daher zweifelhaft ob sie die beste Grundlage zum Entwurf XML basierter Workflow Modelle sind UMIL Aktivit tendiagramme sind ein geeignetes Mittel zur visuellen Beschrei bung von nahezu beliebigen dynamischen Abl ufen in komplexen Systemen Im Rah men der Verbreitung der UML haben sie sich sowohl im wissenschaftlichen als auch im praktischen Bereich als weithin bekannter Standard etabliert Im Vergleich mit anderen Modellierungssprachen wie Petri Netzen und Ereignisgesteuerten Prozessketten schei nen Aktivit tendiagramme die bersichtlichste Variante zu sein Sie sind daher auch f r 5 4 Bewertung 73 technisch weniger kundige Personen verst ndlich In Bezug auf die Modellierung von Workflows im Allgemeinen und XML Prozesse im Speziellen hat sich gezeigt dass Aktivit tend
140. alidierung von Prozessmodellen siehe Ab schnitt 7 5 der in das Werkzeug integriert wurde zeigt dem Benutzer Verletzungen der Wohlgeformtheit und Inkonsistenzen an und unterst tzt ihn so bei der Integrit tswah rung Dabei greift der Algorithmus auf das entwickelte und ebenfalls in das Modellie rungswerkzeug integrierte Port Konzept zur ck Der im Hintergrund arbeitende Algo rithmus zur automatischen Portberechnung reduziert zus tzlich den Mehraufwand des Benutzers zur Modellierung der Ports auf ein Minimum 12 1 Zusammenfassung 249 Im Prozesseditor werden die Prozessmodelle intern in einer Java Implementie rung des Metamodells f r Prozessdiagramme verwaltet siehe 7 4 Diese direkte Umsetzung der Metaklassen aus dem Metamodell siehe 7 1 in Java erlaubt eine effi ziente Arbeit der Werkzeuge auf den Prozessmodellen Ein ebenfalls entwickelter PML Exporter bzw Importer siehe 8 4 dient zur wechselseitigen Konvertierung zwischen PML Beschreibungen und der Metamodellimplementierung Die in PML vorliegenden Prozessbeschreibungen k nnen von dem in Ab schnitt 10 2 vorgestellten Interpreter eingelesen und auf Basis einer Zustandsmaschine ausgef hrt werden Er nimmt dabei eingehende XML Dokumente an leitet sie nach dem Migrationskonzept entsprechend der Prozessbeschreibung an die jeweiligen Kon nektoren zur Verarbeitung weiter nimmt sie nach jedem Verarbeitungsschritt wieder entgegen und f hrt so lange fort bis der gesamte Prozess ab
141. allel gt K Bed 1 verzweigt gt Bed 2 Bed iterativ a ot gt Abb 5 4 Kontrollflusskonstrukte in Petri Netzen Sequentielle Aktionsfolgen werden durch einfache Hintereinanderschaltung von Stellen und Transitionen erreicht Um Parallelit t zu erreichen erzeugt eine Transition mehrere Marken in ihren Ausgangsstellen Dieser Vorgang wird auch AND Split genannt Jede Marke l uft nun parallel durch einen eigenen Aktionsstrang um schlie lich durch einen AND Join wieder mit den anderen zusammengef hrt zu werden Auf diese Weise findet eine Synchronisation der parallelen Teilprozesse statt da die Transition erst dann schalten kann wenn alle Marken in den Eingangsstellen der Transition angekommen sind Es ist auch m glich verschiedene parallele Ausf hrungsstr nge an beliebigen Stellen zu synchronisieren Das Basiskonstrukt dazu ist in Abbildung 5 5 dargestellt 5 1 Petri Netze 57 t1 Prozess 1 lt gt gt Prozess 2 t2 Abb 5 5 Synchronisation von parallelen Teilprozessen Wenn Prozess 1 am Synchronisationspunkt angekommen ist erzeugt seine Transition tl eine Marke in der Stelle s Damit wird dem Partnerprozess die Ankunft signalisiert Wenn Prozess 2 am Synchronisationspunkt angekommen ist kann er erst dann weiter laufen nachdem die Marke vom Partnerprozess erzeugt wurde Das Schalte
142. amm Sprachkonstrukte unterst tzt werden Wiederverwendbarkeit wird vor allem durch die Elemente des statischen Modells gef rdert denn die dort definierten Services k nnen in allen Prozessen benutzt werden hnlich verh lt es sich mit bereits definierten Prozessen die als Teilprozesse in beliebigen anderen Prozessen eingebaut werden k nnen Im Zusammenhang mit Tran sitionen ist es nun w nschenswert auch die Transformationsvorschriften und Style sheets zur berbr ckung inkompatibler Ports m glichst oft wiederzuverwenden insbesondere wenn gleiche Paare von Ports durch eine Transition verbunden werden sollen Um diese Wiederverwendbarkeit zu erreichen reicht es nicht die Transforma tionsvorschriften und Stylesheets so abzulegen dass sie zum Beispiel per Referenz auf die gleiche Quelle wiederverwendet werden k nnen sondern es m ssen zu jedem Stylesheet auch Informationen abgelegt werden welche Ports es miteinander verbinden kann siehe Abbildung 6 20 Erst mit dieser Zusatzinformation ist es m glich zu einer bestimmten Portkonstellation an einer Transition ein passendes Stylesheet aus der Sammlung bereits vorhandener Transformationsvorschriften automatisiert herauszu suchen und wiederzuverwenden Stylesheet Service Service S S2 Abb 6 20 Transformationsvorschrift mit Definitions und Wertebereich Zur Wahrung der Konsistenz sind wie bereits beschrieben nur bestimmte Verkettungen von Ports erlaubt Damit wird die
143. amten Prozesses ber nommen hnliches gilt f r Subaktivit tszust nde bei ihnen m ssen die Ports mit den Ein und Ausgangsports des Prozesses bereinstimmen der durch die Subaktivit t eingebettet wird Die brigen Zust nde im Prozessdiagramm wie die Verkn pfungen junction fork join oder der Synchronisationszustand k nnen alle Dokumenttypen weiterleiten und haben daher als Eingangsport den unbeschr nkten Port any St rker differenzie ren muss man dagegen bei den jeweiligen Ausgangports Verzweigungen decision und 102 Kapitel 6 XML Prozesse und Prozessdiagramme fork sowie der Synchronisationszustand leiten das Dokument unver ndert weiter und haben als Ausgangsport daher stets den offenen Port copyRoot copySubs der im Kontext des konkreten Prozessdiagramms an die jeweiligen Eingangstypen gebunden wird Nach einer Oder Zusammenf hrung merge k nnen Dokumenttypen aus einem der zusammengef hrten Zweige vorliegen Daher wird hier als Ausgangsport die Verei nigung aller eingehenden Ports gesetzt vgl Abbildung 6 17 Port A Service u Abb 6 17 Ports bei einer Oder Zusammenf hrung merge Nach einer Und Zusammenf hrung join paralleler Str nge m ssen die Migrations dokumente aus den einzelnen Zweigen zusammengef gt werden vgl Abschnitt 6 2 5 Dazu wird ein neues Migrationsdokument mit dem Wurzelelement lt join gt erstellt an das die einzelnen Teildokumente mit ihren Wurzelknoten angeh
144. andteile wei dargestellt solche die zur Anbindung einer Komponente neu zu implementieren sind grau interface IXMLConnector setXmIDocument document Document Void getXmIDocument Document AbstractXMLConnector document Document setXmIDocument document Document Void getXmIDocument Document interface IKonnektor2 interface i IKonnektor1 l serviceB Void serviceA Void 7 Konnektor2 Konnektor1 setXmIDocument document Document Void getXmIDocument Document serviceA Void serviceB Void Abb 10 12 Konnektor Klassen Zun chst gibt es das Interface I XMLConnector das von allen Konnektoren erf llt werden muss Es fordert die Methode setXmlDocument mit der der Prozessinter preter dem Konnektor das Migrationsdokument bergibt Der Konnektor muss sich dieses Dokument intern merken damit es von einem anschlie end aufgerufenen Service verarbeitet werden kann Wenn der Service beendet ist ruft der Prozessinterpreter die Methode getxmlDocument auf Sie muss das vom Konnektor manipulierte Dokument liefern das an den n chsten Prozesszustand bergeben werden kann Als Datentyp f r das Dokument wird das Interface org w3c dom Document aus dem DOM Modell des World Wide Web Konsortiums verwendet siehe DOMO1 Vom Interface IXMLConnector abgeleitet ist die Klasse AbstractXML Connector
145. anlassen k nnen Dadurch geht die Kontrolle und Steuerung durch eine zentrale Managementkomponente verloren Um das zu verhindern werden die Dokumente bei unserem Ansatz nicht mit impliziten Informationen ber den Ablauf ihrer Verarbeitung ausgestattet Diese Infor mationen befinden sich vielmehr in dem jeweiligen Workflow Modell das zur Verar beitung des Dokumentes herangezogen und von einem zentralen Interpreter ausgef hrt wird Trotzdem lassen sich bei den Dokumentmigrationen Analogien zu dem Prinzip der Umlaufmappen erkennen das in B h95 S 9 vorgestellt wird Diese fr her in B ros blichen Mappen enthalten alle Informationen ber den aktuellen Stand eines Vorgangs sowie alle f r diesen Vorgang relevanten Dokumente Jeder Sachbearbeiter kann Dokumente bearbeiten oder die Mappe um neue Dokumente erg nzen Nach Erle digung seines Anteils an der Vorgangsbearbeitung leitet er die Mappe an einen anderen Kollegen oder eine andere Instanz weiter die dann mit dem n chsten Schritt der Bear beitung fortf hrt bis schlie lich der gesamte Vorgang erledigt ist Ein hnlicher Gedanke liegt dem Dokumentmigrationsmodell zu Grunde Das Eingangsdokument wird vom WFMS entgegengenommen und in ein internes struktu riertes Datenformat transformiert Von diesem Zeitpunkt an repr sentiert das Dokument 6 1 Konzeption von XML Prozessen 77 die Umlaufmappe die vom WFMS als zentraler Steuerungskomponente von Aktivit t zu Aktivit t weitergereich
146. ann der Prozessdiagramme ausf hrt muss man sich Gedanken dar ber machen welche Semantik solche Diagramme berhaupt besitzen Daher soll in diesem Abschnitt eine Semantik festgelegt werden Die Aufgabe des Prozessinterpreters besteht dann darin ein vorgegebenes Diagramm dementspre chend auszuf hren Die Beschreibung erfolgt zun chst informell anhand der in Abschnitt 7 3 definierten Stereotypen Anschlie end geben wir einen Algorithmus in Pseudocode Notation an der die Ausf hrung gem dieser Semantik leistet Diese semi formale Form der Semantikdefinition reicht aus um die Funktionsweise des Pro zessinterpreters so genau zu spezifizieren dass eine Implementierung m glich wird Da UML Aktivit tendiagramme in der UML Spezifikation OmgOl als Spezial fall von Zustandsmaschinen angesehen werden leitet sich auch ihre Semantik aus der von Zustandsmaschinen ab Die Besonderheit von Aktivit tendiagrammen sind dabei die sogenannten Aktionszust nde In Omg01 2 184 wird ihnen folgende Semantik zugeordnet Sobald eine eingehende Transition eines Aktionszustands ausgel st wird beginnt die Ausf hrung der Aktion die mit dem Zustand verkn pft ist Wenn die Aktion beendet ist werden die ausgehenden Transitionen des Zustands aktiviert Da Pseudozust nde die zweite wichtige Zustandsart in Aktivit tendiagrammen keine zugeordnete Aktion besitzen werden ihre ausgehenden Transitionen sofort aktiviert sobald eine eingehende bzw im Falle e
147. ansformer 1 Transiomer 2 E Serializer Abb 4 5 Beispiel der Ausf hrung einer Pipeline Im Zusammenhang mit der Ausf hrung von Pipelines bietet sunShine Ans tze einer Administratorschnittstelle Sie enth lt einfache Funktionen wie die berwachung von Prozessinstanzen durch Logging Mechanismen oder ihre Erzeugung ber eine API Schnittstelle 4 3 3 Komponentenintegration mit sunShine Die Integration von Komponenten und existierenden Back End Systemen geschieht durch die Transformer innerhalb von Pipelines die die XML Daten verarbeiten Jeder Transformer ist dabei eine Java Klasse deren Schnittstelle nach au en hin aus den Ope rationen des SAX Ereignismodells zur Verarbeitung von XML Daten besteht siehe Meg00 Ein Transformer erh lt nun der Reihe nach alle SAX Ereignisse des zu ver arbeitenden Dokuments Als Java Klasse kann er in Abh ngigkeit davon alle beliebigen Aktionen ausf hren die in Java m glich sind Insbesondere lassen sich vorhandene Systemkomponenten ansprechen Der Transformer kann die Ereignisse so an den jeweils n chsten Transformer der Pipeline weitergeben wie er sie erhalten hat Dadurch w rden die XML Daten von ihm nicht ver ndert Ebenso kann er aber auch andere SAX Ereignisse an seinen Nachfolger senden wenn die Daten manipuliert werden sollen So ist es beispielsweise denkbar dass bestimmte Daten des Dokuments heraus gefiltert oder neue hinzugef gt werden die der Transformer aus irgendeiner
148. apitel 4 Evaluierung vorhandener Workflow Systeme 4 4 Bewertung Nachdem exemplarisch die drei Systeme vorgestellt wurden soll nun eine Bewertung erfolgen Dabei wird berpr ft inwieweit sie den im Abschnitt 3 2 aufgestellten Anfor derungen gerecht werden In Tabelle 4 1 sind alle Anforderungen und die Bewertung der einzelnen Systeme in Kurzform aufgelistet Anforderung BizTalk WARP sunShine Modellierungswerkzeug Analyse Optimierung und Konsistenzpr fung Anbindung von Back End Systemen Workflow relevante Daten 2 2 Verarbeitung von XML Dokumenten Workflow Beschreibungen in XML Zuord von Workflow Elementen auf reale Komp 3 3 Kontrolle und Ausf hrung der Prozessinstanzen Portalfunktionalit t Multi Channel F higkeit Benutzerinteraktion 2 2 2 Administrator Schnittstelle 1 o Flexibles Workflow Modell f r Gesch ftsregeln e Transaktionsunterst tzung Plattformunabh ngigkeit 1 Keine positive Information auffindbar also vermutlich nicht vorhanden 2 Behandlung nicht implizit vorgesehen aber mit vorhandenen Mitteln realisierbar 3 Im Modell k nnen nur bereits vorhandene Komponenten verwendet werden vorhanden nicht vorhanden o ansatzweise vorhanden Tab 4 1 Bewertung vorhandener Workflow Systeme Das Ziel von BizTalk ist die Integration von bestehenden heterogenen Systemen Damit
149. arallelit t bietet die EPK den gestrichelten Pfeil und die vorge stellten Verkn pfungsoperatoren AND OR und XOR an Die Operatoren OR und XOR dienen in der Regel zur Modellierung von bedingten Verzweigungen der AND Ope rator zur Modellierung von parallel eintretenden Ereignissen die verschiedene parallele Teilprozesse ausl sen Die folgende Abbildung zeigt wie man zwei parallele Teilpro zesse durch die AND Verkn pfung synchronisieren kann Abb 5 7 Synchronisation von parallelen EPK Str ngen Im Fall a synchronisieren sich beide Parallelprozesse und werden wieder zu einem Strang verschmolzen Fall b zeigt einen Modellausschnitt bei dem der untere Strang mit der Ausf hrung an dem AND Operator wartet bis der obere Teilprozess den Kon trollpunkt mit dem AND Operator erreicht hat Auf diese oder hnliche Weise lassen sich Prozesssynchronisationen mit der EPK Methode modellieren Die in der Anforderungsanalyse geforderte zweite Eigenschaft der eindeutig definierten Start und Endpunkte kann mit einer EPK erf llt werden da besondere Ereignisse als Start oder Endereignisse angesehen werden k nnen Allerdings ist es nicht obligatorisch sich auf ein eindeutiges Start oder Endereignis festzulegen So kann eine EPK auch durch mehrere solcher Ereignisse angesto en bzw abgeschlossen werden Zur Modellierung der XML Prozesse m sste dieser Freiheitsgrad eliminiert werden Das ist im Allgemeinen kein Problem denn man k nnte bei mehr als
150. ass ein Prozessdiagramm in Form der Daten struktur aus Abschnitt 7 4 vorliegt die Konzepte lie en sich aber ohne Weiteres auch f r andere Implementierungen umsetzen Zun chst erh lt die Klasse StateVertex aus diesem Datenmodell die beiden abstrakten Methoden calculateInputPort und calculateOutputPort die von allen Unterklassen implementiert werden m ssen und die einen Ein bzw Ausgangsport den formalen Vorgaben entsprechend berechnen und zur ckgeben Dem objekt orientierten Konzept der dynamischen Methodenbindung folgend wird bei Aufruf dieser Methoden die Implementierung der jeweiligen Unter klasse aufgerufen So k nnen die verschiedenen Unterklassen von StateVertex je nach ihrem Typ die passende Bedingung zum Beispiel aus den Constraints des Stereotyps stateWithPorts siehe Abschnitt 7 3 2 umsetzen Beispielhaft soll die Klasse MergeStateVertex betrachtet werden Gem den Bestimmungen aus 7 3 2 f r Oder Zusammenf hrungen merge liefert die Methode calculateInputPort f r den Eingangsport hier stets den unbeschr nkten Port any calculateOutputPort f r den Ausgangsport die Vereinigung aller eingehenden Ports zur ck Die Implementierung der beiden Methoden ist eine grundlegende aber noch nicht hinreichende Voraussetzung f r die Durchf hrung der automatischen Portberech nung Es reicht n mlich nicht aus f r jeden Zustand eines Prozessdiagramms einmal die beiden Methoden aufzurufen sondern die Aufrufe m ssen v
151. asse als Singleton Die einzige Objektinstanz der Klasse ist im Attribut theInstance gespeichert und man erh lt Zugriff darauf indem man die Methode get aufruft Das direkte Erzeugen einer Instanz mittels Konstruktoraufruf ist von au en hingegen nicht m glich 206 Kapitel 9 Modellierungswerkzeug f r Prozessdiagramme Weiterhin besitzt die Klasse AppFrame zu jedem Knotentyp der im Projekt baum vorkommen kann genau eine Instanz der zugeh rigen Eingabemaske Dazu z hlt beispielsweise eine Maske f r Services ServicePanelView eine f r das Projekt ProjectPanelView usw Immer wenn im Baum ein Knoten markiert wird wird die passende Maske in den rechten Bereich des Fensters eingeblendet und die Daten des Knotens als aktuelle Werte in die Maske eingetragen Das Einblenden einer Maske im Fenster geschieht mit Hilfe der Methode swapworkingAreaTo Um die gew nschte Maske auszuw hlen existieren die vordefinierten Konstanten PANEL _ von denen man die passende als Parameter an die Methode bergibt 9 3 2 Anwendung des Model View Controller Konzepts F r die Realisierung der Benutzungsoberfl che und ihr Verhalten haben wir das soge nannte Model View Controller Konzept MVC eingesetzt siehe Gam96 S 5 Die Grundidee dieses Ansatzes ist es in Softwaresystemen drei Aspekte voneinander zu trennen Die Daten und Funktionen selbst auf denen das System arbeitet ihre Darstel lung in der Benutzungsoberfl che und die Programmlogik
152. at dies den Vorteil dass im Prozessdiagramm sofort ersicht lich wird an welchen Stellen Ereignisse verarbeitet werden Einsatz als Infrastruktur f r Webservices Mit dem Simple Object Access Protocol SOAP siehe SOAPO1 scheint eine Technologie zu existieren die sich aufgrund ihrer M glichkeiten zu dem Standard bei der Kommunikation zwischen Softwaresystemen in heterogenen Netzwerken insbesondere dem World Wide Web entwickeln wird SOAP erm glicht es laut SOAPOI plattformunabh ngig Informationen auszutauschen ohne R cksicht auf systemspezifische Eigenschaften der beteiligten Kommunikationspartner zu nehmen indem XML als gemeinsame Sprache verwendet wird Mit Hilfe von SOAP lassen sich sogenannte Webservices siehe BetOl realisieren die bestimmte Funktio nen im Netz zur Verf gung stellen Diese k nnen von beliebigen ebenfalls SOAP f hi gen Systemen in Anspruch genommen werden Diese Form der Koppelung von Soft waresystemen vermeidet eine Reihe von Problemen die sich bei der Benutzung alter nativer Technologien wie Java RMI oder CORBA ergeben so dass man hier gro e Erfolgsaussichten sieht Es lohnt sich daher zu untersuchen auf welche Weise sich XML Prozesse mit den M glichkeiten von SOAP verbinden lassen Auf den ersten Blick sind hier zwei verschiedene Ans tze denkbar Zum einen K nnte man nach einer M glichkeit suchen Webservices als Aktivit ten innerhalb von Prozessdiagrammen zu verwenden Da sowohl XML Prozessen a
153. atement Konsistente Portverkettungen Werden Services durch die Transitionen des Prozessdiagramms miteinander verkettet so muss f r ein konsistentes Modell gelten dass bei jeder Transition die m glichen Ausgabedokumente des Quellservices als Eingabe f r den Zielservice erlaubt sind Dazu muss eine Bedingung formuliert werden die sicherstellt dass der Ausgangsport des Quellservice der Transition kompatibel zum Eingangsport des Zielservice ist In der formalen Definition von Ports in Abschnitt 6 3 3 wird eine Teilmengen Beziehung f r Ports definiert eine Berechnungsm glichkeit gezeigt und bewiesen dass sie als Krite rium f r die Kompatibilit t von Ports benutzt werden kann siehe Abschnitt 6 3 3 Kompatibilit tssatz Danach lassen sich zwei Ports p und p2 miteinander verketten wenn p Teilport von p ist p S p2 P S P2 Abb 6 8 Kompatibilit tsproblem bei Port Schnittstellen Um m glichst viele Services flexibel miteinander verketten zu k nnen ist es daher sinnvoll die Ausgangsports der Services m glichst einzuschr nken und wirklich nur die Menge der m glichen Ausgabedokumente zu typisieren Insbesondere sollte der Platz 6 3 Modellierung der Dokumenttypen 97 halter any bei Ausgangsports weitgehend vermieden werden Umgekehrt sollten die Eingangsports der Services eine maximale Menge von Eingaben definieren Gut geeig net sind Services die im Eingangsport ein any besitzen denn sie k nnen nach jedem an
154. auch der Umgang mit Fehlern gekl rt werden die bei der Ausf hrung der zu integrierenden Komponenten und Anwendungen auftreten oder die sich durch die Kopplung und Kommunikation des Interpreters mit diesen Komponenten ergeben Die im Rahmen der Diplomarbeit durchgef hrte Java basierte Implementierung des Prozessinterpreters benutzt zur grundlegenden Fehlerbehandlung das bekannte in Java integrierte Verfahren der Ausnahmebehandlung Exception Handling Die folgende Tabelle gibt einen berblick ber die wichtigsten Ausnahmetypen die im Prozessinterpreter vorkommen k nnen InvalidPMLDocumentException Ein Fehler ist beim Laden der Prozessbeschreibung aus einem PML Dokument aufgetreten vermutlich aufgrund von Unstimmigkeiten oder inkonsistenten Daten im Dokument InvalidDocumentStructureExc Das Migrationsdokument entspricht nicht den Typvorgaben eines Ports GuardEvaluationException Die Auswertung eines Guards ist fehlgeschlagen weil der Ausdruck nicht g ltig oder auf das Migrationsdokument nicht anwendbar war DocumentTransformationExc Die Transformation eines Dokuments durch einen Style sheet Prozessor schlug fehl oder das gesuchte Stylesheet konnte nicht gefunden werden CreateConnectorException Beim Suchen bzw Erzeugen einer Konnektorinstanz ist ein Fehler aufgetreten m glicherweise konnte die Klasse nicht gefunden werden CallServiceException Beim Aufruf eines Service ist ein Fehler aufgetreten entwe der weil di
155. aum selektiert wird Da jedoch die Klassen des Java Swing Systems recht umfangreich sind w rde dadurch ein hoher Speicherbedarf des Prozesseditors entstehen was besonders bei komplexen Workflow Modellen Probleme bereiten k nnte Wir haben uns aus diesem Grund gegen diese Variante entschieden Stattdessen besitzt die Klasse AppFrame wie bereits in 9 3 1 erw hnt genau eine Eingabemaske die von allen Services genutzt wird In Abbildung 9 14 sieht man daher dass zwar eine Instanz von ServicePanelView immer eine Assoziation zu einem ServiceAdapter besitzt current umgekehrt aber nicht jeder ServiceAdapter in einer Maske angezeigt wird Nachdem diese Current Assoziation ver ndert wurde da der Benutzer einen anderen Service ausgew hlt hat erfolgt ein Aufruf der Methode updateview Sie ist daf r zust ndig die Daten aus dem neuen Service auszulesen und in die grafischen Bedien elemente der Maske einzutragen Controller Damit Aktionen die der Benutzer in der Oberfl che ausf hrt vom Prozesseditor verar beitet werden k nnen besitzt ServicePanelView eine Assoziation zur Klasse ServiceActionListener Diese erf llt das Swing Interface ActionListener und implemen tiert seine Methode actionPerformed Die Methode wird vom Swing System aufgerufen sobald eine Benutzeraktion erfolgt Innerhalb der Methode muss dann anhand des Event Objekts das als Parameter bergeben wurde festgestellt werden um welche Aktion es sich handelt In den E
156. auszuwerten ist Expression wird bei Prozessdiagrammen vor allem benutzt um XML spezifische Ausdr cke in Sprachen wie XSL oder XPath anzugeben 148 Kapitel 7 Metamodell f r Prozessdiagramme Klassendiagramm f r das statische Modell Zum statischen Modell geh ren die Konnektoren mit ihren Services und die Transi tionstypen Hinzu kommt die Verwaltung dieser Elemente in Packages vgl Ab schnitt 8 3 2 Das folgende Klassendiagramm zeigt den Ausschnitt aus dem Meta modell durch den die statischen Modellelemente realisiert werden sollen elemen container 0 Sue v1 ContainerElement ModelElement name String connector J name Package TransitionType ComponentConnector name Service Parameter 1 service service parameter 0 1 1 ordered sourcePort Port image String targetPort OpenPort inputPort Port transformation Expression outputPort OpenPorf ProcessModel Abb 7 8 Klassendiagramm f r das statische Modell ModelElement ContainerElement Package ProcessModel TransitionType Alle verwendeten Klassen sind direkt oder indirekt von der gemeinsamen Oberklasse ModelElement abgeleitet Dadurch erh lt jedes Modellelement einen eigenen Namen Die Unterklasse ContainerElement dient als Abstraktion f r alle Modellelemente die in einem Package als Container enthalt
157. baren Systemkompo nenten f r die Funktionen repr sentiert werden Dabei ist allerdings zu ber cksichtigen dass die statischen Modelle im Umfeld der EPK eigentlich zur Abbildung organisatori scher Einheiten eines Unternehmens eingef hrt worden sind und nicht zur Darstellung einer Sammlung von Softwarekomponenten die innerhalb eines integrativen Workflows angesprochen werden sollen Dies macht eventuell einige nderungen an den Modellen n tig Die letzte Forderung nach einem Konstrukt zur Modellierung von Transaktionen ist bislang von der EPK Theorie nicht erf llt Dies k nnte daran liegen dass Transak tionen vor allem im Bereich der Ausf hrung von Softwareprozessen eine Rolle spielen und weniger bei betriebswirtschaftlichen Prozessen Um diese Anforderungen dennoch zu erf llen m sste ein geeignetes Element erst neu definiert und eingef hrt werden 66 Kapitel 5 Evaluierung vorhandener Workflow Modellierungssprachen 5 3 UML Aktivit tendiagramme Die Unified Modeling Language UML ist eine von der Object Management Group OMG standardisierte grafische Sprache zur Visualisierung und Modellierung der Eigenschaften objektorientierter Softwaresysteme Die UML Spezifikation beschreibt verschiedene Diagrammarten die sich f r unterschiedliche Anwendungsgebiete eignen Aktivit tendiagramme sind eine von mehreren M glichkeiten dynamische Abl ufe darzustellen Laut Oes97 sind in ihnen Ans tze einiger anderer Sprachen vereinigt da
158. basierte und andere elektronische Gesch ftsabl ufe ein System zu entwickeln mit dem diese auf komfortable Art in die bestehenden Softwaresysteme integriert bzw an diese gekoppelt werden k nnen Der Prozessinterpreter kann dabei als eine Ressource innerhalb der Plattform genutzt werden vgl Abschnitt 10 6 Nach dem Aufruf der zugeh rigen Adresse zum Beispiel aus einem Portal heraus kann mit dem Interpreter ein umfangreicher XML Prozess 84 Kapitel 6 XML Prozesse und Prozessdiagramme durchlaufen werden beim dem die Daten gesammelt und aufgearbeitet werden bevor sie an die aufrufende Einheit z B den Web Browser zur ckgegeben werden F r die Realisierung der hier umrissenen Konzeptideen gehen wir in den folgen den Abschnitten und Kapiteln zun chst auf die Frage nach einer geeigneten Modellie rung der XML Prozesse ein und stellen danach das System zur Ausf hrung der Workflows vor Kapitel 10 Dabei sollen stets die sich aus der praktischen Anwendung ergebenen Anforderungen vgl Kapitel 3 an das System ber cksichtigt werden 6 2 Modellierung mit Prozessdiagrammen Die Beschreibung von XML Prozessen mit Prozessdiagrammen einer Erweiterung von UMIL Aktivit tendiagrammen soll nun zun chst anhand eines Beispielprozesses erfol gen wie er in der Praxis gegeben sein k nnte Anschlie end werden allgemein die einzelnen Aspekte und Sprachkonstrukte von Prozessdiagrammen definiert F r das Beispiel sei folgendes Anwendungsgebiet geg
159. ben siehe Abschnitt 6 2 3 In Prozessdiagrammen wird abk rzend auf die explizite Darstellung von Objektfl ssen verzichtet und statt dessen ein spezielles Stereotyp typedTransition f r Transitionen eingef hrt der ihnen neben der Kontrollfluss Semantik auch die eines Dokumentflusses verleiht Die Transitionen sind durch einen Typ transitionType klassifiziert der durch einen Quellport einen Zielport und eine Transformationsvorschrift spezifiziert wird siehe Abschnitt 6 3 2 Der Quellport gibt an welche Dokumenttypen ber die Transition flie en k nnen Der Zielport hilft bei der Bestimmung der Zust nde deren Eingangsports zu dieser Transi tion kompatibel sind Der Eingangsport eines nachfolgenden Zustands muss eine Ober menge des Zielports der Transition sein damit alle von der Transition bergebenen Dokumente zum nachfolgenden Zustand konform sind Mit der Transformations vorschrift werden ber den Quellport eingegangene Dokumente falls n tig so transfor miert dass sie konform zum Zielport des Transitionstyps werden siehe 6 3 2 und 6 3 3 Migrationssatz Um den Migrationssatz Satz 6 18 anwenden zu k nnen muss die durch das Tag transformation spezifizierte Transformationsfunktion die in Def 6 16 getroffenen Einschr nkungen erf llen Stereotyp transitionType Basisklasse UML Core Classifier Ober Stereotyp Tag Definitionen sourcePort targetPort transformation Einschr nkungen 1 Keine
160. bestimmter Entscheidungswerte abh ngig machen Der folgende Auszug aus dem Regelwerk zeigt den kleinen Beispielprozess aus Abbildung 11 4 erg nzt um die parallele Ausf hrung einer zweiten Aktion die nebenl ufig eine Best tigung des Pr fvorgangs Auditing absendet lt Prozesstyp name Auditing gt lt Zustand id 0 name Auditing schreiben start Ja gt lt StandardAktion final Nein folgeid 1 name Auditing gt lt Url url http sunshine auditing schreiben xml gt lt StandardAktion gt lt Zustand gt lt Zustand id 1 name Auditing Antwort start Nein gt lt AsyncAktion name Auditing Best tigung gt lt Diese Aktion wird parallel ausgef hrt gt lt Entscheidungswerte gt lt Ausdruck operator eq wert 0 gt lt Entscheidungswerte gt lt Url url http sunshine auditing best tigung xm1 gt lt AsyncAktion gt lt StandardAktion final Ja name Auditing Antwort gt lt Url url http sunshine auditing antwort xml gt lt StandardAktion gt lt Zustand gt lt Prozesstyp gt Abb 11 8 Regeln mit paralleler Ausf hrung nach BadO1 Genau wie in Prozessdiagrammen k nnen beliebig viele Aktionen parallel durchgef hrt werden gegebenenfalls auch in Abh ngigkeit von Entscheidungswerten siehe oben Diese M glichkeit gibt es in Prozessdiagrammen durch die Verwendung von Guards an den ausgehenden Transitionen einer Parallel Verzweigung fork Die folgende Abbil du
161. bindung zwischen Dienst und Dienstnehmer hergestellt damit die Interaktion durchgef hrt werden kann Diese M glichkeiten der Jini Technologie k nnen f r das Suchen von Konnek tor Klassen durch den Prozessinterpreter genutzt werden Alle Klassen die vom Workflow System genutzt werden sollen m ssten sich dann beim Jini System anmel den so dass sie im Verzeichnis vermerkt sind Wenn nun eine Interpreterinstanz zur Ausf hrung eines Service einen Konnektor ben tigt kann anhand des Verzeichnisses eine passende Klasse ermittelt werden die das im Prozessmodell verwendete Interface erf llt Da die Konzepte von XML Prozessen und der Jini Technologie offenbar gut zusammenpassen sollte eine Implementierung des Ansatzes keine gro en Probleme bereiten Unterst tzung anderer Modellierungswerkzeuge Prozessdiagramme als Sprache zur Modellierung von XML Prozessen lassen sich wie in Kapitel 7 gezeigt vollst ndig als Erweiterung der UML beschreiben Wir haben den Prozesseditor entwickelt um dem Modellierer eines Workflows ein speziell auf Prozessdiagramme zugeschnittenes Werk zeug zur Verf gung zu stellen mit dem sich solche Diagramme komfortabel entwerfen lassen Prinzipiell lie en sich aber mit jedem beliebigen UML Werkzeug Prozessdia gramme erstellen sofern es die gesamten M glichkeiten von UML Aktivit ten diagrammen und der Erweiterungsmechanismen insbesondere das Konzept der Stereo typen unterst tzt Es ergibt sich dabei das Problem
162. brochen Alle Aktionen wie Aufruf eines Service oder Erzeugen der ProcessSections f r parallele Str nge geschieht bei der Ausf hrung des aktuellen Zustands currentState Wenn der Folgezustand des aktuellen Zustands bestimmt wird m ssen ggf Guard Ausdr cke ausgewertet werden um zu pr fen welchen Ausf hrungspfad der Prozess nehmen soll Dazu existiert die Hilfsklasse GuardEvaluator Ein Guard muss immer folgenden Aufbau haben damit er vom Interpreter ausgewertet werden kann lt Basis gt lt XPath gt Dabei ist lt XPath gt durch einen g ltigen XPath Ausdruck zu erset zen lt Basis gt muss entweder das Wort document sein um zu signalisieren dass sich der XPath Ausdruck auf das Migrationdokument beziehen soll oder ein anderer Name der f r ein XML Dokument innerhalb der Prozessumgebung steht vgl Abschnitt 10 5 auf das der XPath Ausdruck angewendet wird Erlaubte Ausdr cke sind also beispiels weise document root element1 wert envl local name root element1 10 2 3 Synchronisationsmechanismus Prozessdiagramme erlauben es mit Hilfe von Synchronisationszust nden eine Synchro nisation zwischen unterschiedlichen parallelen Teilprozessen zu realisieren Im Ab schnitt 6 2 5 wurde beschrieben dass dabei nicht nur eine zeitliche Abstimmung sondern auch ein Austausch des Migrationsdokuments stattfindet F r die Umsetzung im Prozessinterpreter wurde auf das Konzept der sogenannten Monitore zur ckgeg
163. bschnitt werden einige Erweiterungen vorgestellt die besonders f r den Bereich der Gesch ftsprozessmodellie rung von Bedeutung sind 5 1 2 High Level Petri Netze Im Zusammenhang mit der Modellierung von Gesch ftsprozessen wurden vor allem drei wichtige Erweiterungen der klassischen Petri Netze vorgeschlagen um m chtigere Ausdrucksm glichkeiten zur Verf gung zu haben Dabei handelt es sich um individu elle Marken Zeit und Hierarchie Eine gravierende Schw che herk mmlicher Petri Netze ist die Tatsache dass alle Marken gleichwertig und damit nicht unterscheidbar sind Beim realen Einsatz von Petri Netzen zur Modellierung von Prozessen stellen Marken jedoch h ufig Objekte dar die am Prozess beteiligt sind Dies k nnen Menschen Ressourcen Dokumente o sein Es ist nun w nschenswert Aussagen ber bestimmte Eigenschaften solcher Objekte zu machen sei es als Vorbedingung zum Schalten einer Transition oder als Spezifizierung ihres Ergebnisses Um dies modellieren zu k nnen stellt Bau96 S 195 folgenden Ansatz vor Jede Marke in einem Petri Netz ist ein wohldefiniertes mathematisches Objekt also beispielsweise eine Zahl Zeichenkette ein Tupel usw Auf diese Weise werden Marken unterscheidbar d h individuell und es l sst sich sogar mit ihnen rech nen F r jede Transition lassen sich nun Aussagen ber die Marken in ihren Eingangs und Ausgangsstellen machen Abbildung 5 2 zeigt ein einfaches Beispiel 5 1 Petri Netze 53
164. ch Addison Wesley Longman Ltd 2 Auflage 1999 Markus B hm Wolfgang Schulze Grundlagen von Workflow Managementsystemen Wissenschaftliche Beitr ge zur Informatik TU Dresden 8 1995 Heft 2 S 50 65 http wwwdb inf tu dresden de dokumente ls dokumente wfgrundl pdf Danny Coward Sun Microsystems Inc Java Servlet Specification Version 2 3 http java sun com aboutJava communityprocess first jsr053 index html Computer Zeitung Modell senkt Folgekosten f r eine einheitliche IT Computer Zeitung Nr 32 vom 9 August 2001 S 14 Konradin Verlag Leinfelden Umeshwar Dayal et al A Transactional Model for Long Running Activities Proceedings of the 17th International Conference on Very Large Data Bases 1991 http www vldb org conf 1991 P113 PDF R Depke M Langham B L tkemeier S Th ne Ein Konzept zur Spezifikation von XSL Transformationen und dessen Anwendung bei Bankselbstbedienungssystemen Tagungsband zu Net Object Days 2000 Hrsg Net ObjectDays Forum Philippe Le H garet et al Document Object Model DOM Level 3 Core Specification Version 1 0 W3C Working Draft 13 September 2001 http www w3 org TR 200 WD DOM Level 3 Core 20010913 DumOl EbX01 Esh01 Gam96 Geo95 Gru01 Gso01 Hei00A Hei00B 257 Marlon Dumas Arthur H M ter Hofstede UML Activity Diagrams as a Workflow Specification Language Proceedings at the 4 International Conference Toronto Canada 2001 L
165. ch den Prozessinterpreter ist es vorstellbar aus einem Diagramm eine Java Klasse zu gene rieren die eine automatisch erzeugte Implementierung des modellierten Prozesses dar stellt Es bietet sich an als Konzept f r die generierte Klasse auf das Prinzip einer Zustandsmaschine zur ckzugreifen Es k nnte beispielsweise ein XSL Stylesheet ent wickelt werden das ein PML Dokument in Java Quellcode transformiert der dann nur noch bersetzt werden m sste Prinzipiell ist dies mit der Sprache XSL m glich Es ist zu untersuchen inwieweit ein solches Vorgehen zu Effizienzsteigerungen gegen ber dem Konzept der Ausf hrung von Prozessen durch einen Interpreter f hrt Unterst tzung von Benutzerinteraktion Im Rahmen dieser Arbeit haben wir uns auf die Untersuchung rein systemorientierter Workflows beschr nkt vgl Abschnitt 2 2 2 bei denen als Akteure ausschlie lich Softwarekomponenten bzw systeme zum Einsatz kommen Je nach Einsatzgebiet unterst tzen verf gbare Workflow Management Systeme aber auch die Interaktion mit menschlichen Teilnehmern Es ist zu untersu chen inwieweit im Bereich des E Business solche M glichkeiten von Bedeutung sind Denkbar ist beispielsweise dass innerhalb eines XML Prozesses an bestimmten Stellen R ckfragen an den Benutzer gestellt werden m ssen der die Ausf hrung des Prozesses veranlasst hat Es m ssten Konzepte entwickelt werden wie sich solche Situationen in Diagrammen modellieren lassen und wie sie te
166. ch Timeouts ber cksichtigt wird Dabei ginge ein Service nach Ablauf eines bestimmten Zeitintervalls davon aus dass der Interpreter ausge fallen ist Er muss dann im Rahmen des sogenannten Terminierungsprotokolls selb st ndig aktiv werden und in Kontakt mit den anderen betroffenen Services treten Auch diese Forderung ist bei XML Prozessen bislang nicht erf llt da Services stets passive Komponenten sind die lediglich durch einen Methodenaufruf von au en angesprochen werden k nnen Da wird auf die Implementierung von transaktionalem Verhalten verzichtet haben m chten wir es bei der Aufz hlung dieser Schwierigkeiten belassen und im Rahmen dieser Arbeit keine L sungen f r dieses recht komplexe Problemgebiet entwickeln 10 5 Entwicklung von Konnektoren 233 10 5 Entwicklung von Konnektoren Im Abschnitt 6 1 2 wurde erl utert warum sich vorhandene Softwarekomponenten in der Regel nicht direkt in einen Workflow integrieren lassen Als L sung dieses Problems wurde das Konzept der Konnektoren vorgestellt die als Bindeglied zwischen den Komponenten und dem Workflow Management System dienen Sie stellen dem WFMS eine f r alle Komponenten einheitliche Schnittstelle zur Verf gung Bei XML Prozessen besteht die Hauptaufgabe dieser Konnektorschnittstellen darin das XML Migrationsdokument entgegenzunehmen und Methoden f r die einzelnen Services anzubieten Abbildung 10 12 zeigt die dazu relevanten Klassen Dabei sind alle vorhan denen Best
167. che HyperText Markup Language HTML siehe HTML99 dient in erster Linie zur Formatierung und Pr sentation von Texten und Grafiken die elektronische Post E Mail zum einfachen Versenden von Textpaketen und Dateien Keine dieser beiden Technologien erm glicht es jedoch den Gesch fts partnern strukturierte Daten zum Beispiel ber Auftrags und Rechnungseingang miteinander auszutauschen so dass sie direkt von den eigenen Anwendungssystemen verarbeitet werden k nnten Nur der Ansatz des elektronischen Datenaustausches ber EDI Electronic Data Interchange verfolgt dieses Ziel wird aber durch propriet re und zweckgebundene Netzwerke und Protokolle realisiert vgl Mic00 S 2 was sich nachteilig auf die Flexibilit t und Offenheit der Gesch ftsbeziehungen auswirkt In der zweiten ra des Internets der Integrations ra vollzieht sich seit Ende der neunziger Jahre ein allm hlicher Wandel von der einfachen Kommunikation zwischen Gesch ftspartnern hin zur Integration ihrer Anwendungssysteme und Gesch ftspro zesse Mit dem Begriff Integration ist hier die Kopplung der meist heterogenen Teil systeme eines Unternehmens gemeint die oft als Insell sungen unabh ngig voneinan der und nebeneinander existieren Damit diese Systemkomponenten Daten und Infor mationen austauschen k nnen sind entsprechende Schnittstellen und Protokolle n tig So wie bei der betriebswirtschaftlichen Gesch ftsprozessoptimierung die Unterneh mensproduktivit t
168. cher offenen Ports mit der sie in nicht offene Ports berf hrt werden k nnen Dies f hrt uns schlie lich zum Einsatz offener Ports bei Transitionstypen ihrer Bindung bei der Verwendung der Typen f r konkrete Transitionen und dem Migrationssatz mit dem sich die konsistente Migration eines XML Dokuments ber eine solche typisierte Transition beweisen l sst Def 6 11 Die Platzhalter bei offenen Ports CopyPlaceholder copyRoot rootExceptions copySubs rootExceptions subExceptions rootExceptions subExceptions c XmlElements Wie bereits in Abschnitt 6 3 1 erl utert k nnen bei offenen Ports die Platzhalter copyRoot und copySubs verwendet werden Dabei kann entweder nur copyRoot allein oder copyRoot zusammen mit copySubs stehen Der erste Fall wird durch das erste Element der Menge CopyPlaceholder der zweite Fall durch das zweite Element der Menge repr sentiert Das Schl sselwort copyRoot kann in den Dokumenttypen eines offenen Ports statt eines Wurzelelements angegeben werden Ein solcher Doku menttyp legt dann kein konkretes Wurzelelement fest sondern bestimmt h chstens eine Menge obligatorischer Unterelemente Sp ter kann der Platzhalter an eine Menge von konkreten XML Elementen gebunden werden indem er durch die Wurzelelemente eines anderen Ports ersetzt wird vgl Def 6 14 Zus tzlich kann mit dem Platzhalter copySubs auch die bernahme von Unterelementen gefordert werden Erg nzt werden die Schl sse
169. chnisch umgesetzt werden K nnen Ereignisbehandlung Bislang stellt jeder XML Prozess einen in sich geschlossenen Workflow dar dessen Instanzen sukzessive ausgef hrt werden Es ist jedoch keine Kommunikation mit anderen Prozessen vorgesehen Auch ein Austausch von Nach richten zwischen den Aktivit ten einer Prozessinstanz ist nur mit Hilfe des Migrations dokuments realisierbar Beide Varianten lassen sich zwar ohne Weiteres innerhalb der aufgerufenen Services realisieren die Modellierung eines solchen Informations austauschs im Prozessdiagramm ist jedoch nicht m glich Falls dies in bestimmten Situationen w nschenswert w re k nnte auf das Konzept der Ereignisse die in UML Aktivit tendiagrammen existieren zur ckgegriffen werden Es ist zu untersuchen wie sich dieses Konzept f r die Gegebenheiten von XML Prozessen anpassen l sst Wenn Prozessdiagramme um eine solche M glichkeit zur expliziten Beschreibung von Ereig nissen erweitert werden m sste voraussichtlich eine Art Ereignisbehandlung in den Prozessinterpreter integriert werden ber den der Informationsaustausch zwischen Prozessinstanzen stattfinden kann Vergleiche dazu auch WieOl Statt das bisherige Konzept zu erweitern K nnte auch eine spezielle Ereignis komponente implementiert werden die entsprechende Services anbietet um Ereignisse auszul sen oder zu verarbeiten Gegen ber der Methode Informationen intern in den 12 2 Ausblick 253 Services auszutauschen h
170. cht des Instituts f r Wirtschaftsinformatik der Universit t des Saarlandes Heft 89 Januar 1992 http www iwi uni sb de iwi hefte heft089 zip Gerhard Keller amp Partner SAP R 3 proze orientiert anwenden Iteratives Proze Prototyping mit Ereignisgesteuerten Prozessketten und Knowledge Maps Addison Wesley Longman Verlag GmbH 1999 Qinzheng Kong Graham Chen Transactional Workflow For Telecommunication Service Management IEEE IFIP Network Operations and Management Symposium 1996 http www citr com au pdfs 96journ 96p3 pdf Lau00 Len01 L t00 Mak01 Med93 Meg00 Mic00 Mic01 MOF00 Moh01 259 Brett McLaughlin Java and XML O Reilly Juni 2000 http www oreilly com catalog javaxml chapter ch09 html Kirsten Lenz Andreas Oberweis Modeling Interorganizational Workflows with XML Nets Proceedings of the Hawaii International Conference On System Sciences IEEE 2001 ftp kina wiwi uni frankfurt de pub publikationen tagungen t50 pdf Bj rn L tkemeier Sebastian Th ne Entwicklung eines bersetzers von Nachrichtenaustauschformaten f r Bankselbstbedienungssysteme in XML Formate Universit t Paderborn Fachbereich Informatik Studienarbeit Mai 2000 http home vr web de thoene studium studienarbeit pdf Makoto Murata Dongwon Lee Murali Mani Taxonomy of XML Schema Languages using Formal Language Theory Extreme Markup Languages 2001 Montreal Canada August 2001 http
171. complexType name ProcessType gt lt xsd sequence gt lt xsd element name inputPort type PortType gt lt xsd element name outputPort type OpenPortType gt lt xsd element name state type StateType minOccurs 0 maxOccurs unbounded gt lt xsd element name extensions type ExtensionsType minOccurs 0 gt lt xsd sequence gt lt xsd attribute name name type xsd string use required gt lt xsd iattribute name transactional type xsd boolean use required gt lt xsd complexType gt lt xsd complexType name ExtensionsType gt lt xsd sequence gt lt xsd any minOccurs 0 maxOccurs unbounded gt lt xsd sequence gt lt xsd complexType gt Abb 8 15 PML Schema Fragment f r Prozessdiagramme Stereotyp stateWithPorts Jedes Element lt state gt beschreibt einen Zustand dem das Stereotyp stateWithPorts zugeordnet ist Gem diesem Stereotypen existieren zwei Unterelemente lt inputPort gt und lt outputPort gt um die Ports des Zustands anzugeben Als drittes Unterelement steht eines der weiter unten beschriebenen PML Elemente die jeweils den Zustandstyp widerspiegeln der sich aus der UML Metaklasse des Zustands ergibt Schlie lich haben wir aus technischen Gr nden ein Attribut id eingef hrt Dieses ist vom XML Daten typ ID und muss eine innerhalb des Prozesses eindeutige Identifizierung des Zustands erlauben Es hat jedoch keine Entsprechung im UML
172. d sorgt so f r die Kontrolle und Ausf hrung der Prozess 244 Kapitel 11 Evaluierung anhand einer Fallstudie instanzen Durch die vorhandenen XML Technologien und die Integration in das sunShine E Business System werden Portalfunktionalit t und Multi Channel Ansatz realisiert Die Anforderungen bzgl Benutzerinteraktion und Administrator Schnittstelle wurden f r die Ziele dieser Arbeit als weniger relevant angesehen vgl Abschnitt 3 4 und daher auch nicht oder nur teilweise gel st Konzepte f r die Transaktionsunter st tzung konnten aufgrund der begrenzten Zeit nur umrissen aber nicht in die Tiefe gehend behandelt werden vgl Abschnitt 10 4 Durch die Verwendung der Prozess diagramme k nnen flexible Workflow Modelle f r die Gesch ftsregeln der Abl ufe aufgestellt werden Die Implementierung in der Programmiersprache Java sichert die Plattformunabh ngigkeit des Systems und damit die Einsetzbarkeit in verschiedenen heterogenen Umgebungen Die folgende Tabelle zeigt die Erf llung der Anforderungen noch einmal im berblick Anforderung sunShine a Modellierungswerkzeug Analyse Optimierung und Konsistenzpr fung Anbindung von Back End Systemen Workflow relevante Daten Verarbeitung von XML Dokumenten Workflow Beschreibungen in XML Zuord von Workflow Elementen auf reale Komp 2 Kontrolle und Ausf hrung der Prozessinstanzen Portalfunktionalit t Multi
173. d ver ndert werden denn die konkrete Komponente wird erst zur Laufzeit vom WFMS gebunden 6 1 4 Management von XML Prozessen Bei den in den vorausgehenden Abschnitten vorgestellten Konzepten wurde bereits mehrfach das strukturierte Datenformat angesprochen das intern vom WFMS f r die Speicherung und Strukturierung der Migrationsdokumente verwendet werden soll Gem den in Kapitel 3 formulierten Anforderungen setzen wir dazu XML ein Des Weiteren wird XML benutzt um die Prozessbeschreibung nach der Modellierung abzu speichern Dazu definieren wir in Kapitel 8 eine entsprechende XML Sprache unter dem Namen Process Markup Language PML Nach der Modellierung eines XML Prozesses wird das visuelle Modell nach PML bersetzt Dieses Beschreibungsformat des Prozesses kann dann von einem Prozessinterpreter vgl Kapitel 10 verstanden und ausgef hrt werden Bei der bersetzung nach PML handelt es sich nicht um die Kon vertierung von einer hohen Abstraktionsebene auf ein feineres Niveau mit genauerer Semantik denn die visuelle Sprache besitzt bereits eine eindeutige Semantik So werden Fehler durch Konvertierung und berwindung einer semantischen L cke vermieden vgl auch Abschnitt 2 4 Die folgende Abbildung zeigt einen berblick ber die Architektur des geplanten WFMS 6 1 Konzeption von XML Prozessen 83 Modellierung Prozessagramm PML Prozessbeschreibung l gt Ausgabedokument
174. dar Das WFMS ist ber die Nutzung von Services bzw Konnektoren in der Lage die bestehen den Komponenten in die Verarbeitung zu integrieren Eingebettet wird das WFMS in einen Rahmen von Systemen zur Anbindung an Kommunikationsnetze wie das Internet Dazu werden ein Webserver sowie ein Applikationsserver vorgeschaltet die alle Anfra gen entgegennehmen und gegebenenfalls an das WFMS zur Verarbeitung weitergeben Ein Portal Management System im Zusammenhang mit einem Content Management System zur Aufbereitung der Informationsinhalte runden die gesamte Architektur ab 28 Kapitel 3 Anforderungsanalyse 3 2 Anforderungen an Workflow Systeme im E Business Im vorangegangenen Abschnitt wurden die Ideen und Konzepte f r den Einsatz eines Workflow Management Systems innerhalb der E Business Plattform eines gro en Finanzinstituts vorgestellt Daraus ergeben sich spezielle Anforderungen die ein sol ches System erf llen muss An dieser Stelle soll von den spezifischen Bedingungen der Fallstudie abstrahiert werden Vielmehr soll eine allgemeine Liste der wichtigsten Anforderungen an Workflow Management Systeme formuliert werden Zu diesem Zweck wurde die spezielle Situation der Fallstudie mit dem Workflow Referenz Modell aus Wmc95 verglichen Dadurch ergeben sich einige zus tzliche Forderungen die in der Fallstudie nicht explizit aufgef hrt wurden Besondere Ber cksichtigung bei den folgenden Betrachtungen soll das Anwendungsgebiet E Business fi
175. das gew nschte Symbol f r einen Service Zustand zu zeichnen Weiterhin sind der Klasse ServiceStateComponentView zwei Controller Komponenten zugeordnet StateMouseListener und StateMouseMotion Listener Sie reagieren auf alle Mausereignisse die auftreten wenn der Benutzer den Service Zustand mit der Maus anw hlt verschiebt usw Sie m ssen intern herausfinden welches Ereignis ausgel st wurde und die entsprechenden Aktionen durchf hren 210 Kapitel 10 Ausf hrung von XML Prozessen 10 1 Semantik von Prozessdiagrammen 211 10 Ausf hrung von XML Prozessen Im vorherigen Kapitel wurde das im Rahmen dieser Arbeit entwickelte Modellierungs werkzeug vorgestellt mit dem sich XML Prozesse in Form von Prozessdiagrammen entwerfen lassen In den folgenden Abschnitten soll nun betrachtet werden wie sich die so definierten Prozesse ausf hren lassen Als Basis f r die Ausf hrung dienen die Prozessbeschreibungen in der Sprache PML vgl Kapitel 8 die vom Modellierungs werkzeug erzeugt wurden Zun chst erfolgt eine Betrachtung zur Semantik von Prozess diagrammen bevor dann der Interpreter vorgestellt wird der die Ausf hrung ber nimmt Anschlie end wird darauf eingegangen was bei der Entwicklung von Konnek toren zu beachten ist die die statischen Komponenten der Prozessdefinitionen darstellen und als Aktivit ten in den Prozessen verwendet werden k nnen 10 1 Semantik von Prozessdiagrammen Bevor ein Interpreter entwickelt werden k
176. de sind alle Muss Bestimmungen erf llt Es lassen sich alle Sprachelemente von Prozessdiagrammen in PML ausdr cken und rekonstruieren um aus einer PML Beschreibung wieder ein visu elles Modell zu generieren Die einzige Forderung die nicht erf llt werden konnte ist die nach einer bekannten oder sogar standardisierten Sprache Falls Workflow Modelle mit Hilfe einer solchen bekannten Sprache wie beispielsweise XMI beschrieben werden sollen muss ggf die M glichkeit einer Konvertierung zwischen PML und dieser Spra che geschaffen werden Dazu k nnte beispielsweise ein XSL Stylesheet entwickelt werden Aufgrund der Eigenschaften von XML Schemata lie en sich nicht alle Ein schr nkungen bzw Bedingungen die f r Prozessdiagramme als OCL Constraints formuliert wurden in der Definition der Sprache PML umsetzen Daher ist es prinzipiell m glich mit PML Prozesse zu beschreiben die keine g ltigen Prozessdiagramme darstellen Nachdem also ein PML Dokument maschinell eingelesen wurde sollte vor der weiteren Verarbeitung mit Hilfe eines geeigneten Validierers siehe Abschnitt 7 4 2 berpr ft werden ob es ein korrektes Modell enth lt Tabelle 8 3 fasst noch einmal alle Aspekte im Bezug auf eine Prozessbeschreibungssprache zusammen U Anforderung XML Format Graphorientierte Beschreibung des Kontrollflusses Aufruf vorhandener Services bzw Komponenten bergabe von Parametern an Komponenten Beschreibung von N
177. dem muss mit Hilfe des Attributs transitionType ein existierender Transi tionstyp mit Package ausgew hlt werden der den Typ des Zustands bergangs festlegt Wenn ein Guard erlaubt ist so hat lt next gt zus tzlich ein Unterelement lt guard gt dessen Textinhalt ein Ausdruck ist der vom Prozessinterpreter ausgewertet werden kann vgl Abschnitt 10 2 2 Dazu wird mit Hilfe der Vererbung mittels lt xsd extension gt der XML Typ GuardedNextType definiert Die beiden Constraints des Stereotyps die Aussagen ber die G ltigkeit der Ports machen k nnen wie bereits weiter oben argu mentiert nicht im XML Schema umgesetzt werden da sie sich auf Inhalte und nicht die Struktur eines PML Dokuments beziehen stereotype typedTransition Tags i type n taggedValue 1 V stereotype transitionType Tags sourcePort Port 1 targetPort OpenPort 1 transformation Expression 0 1 lt xsd complexType name NextType gt lt xsd attribute name ref type xsd IDREF use required gt lt xsd attribute name transitionType type xsd string gt lt xsd complexType gt lt xsd complexType name GuardedNextType gt lt xsd complexContent gt lt xsd extension base NextType gt lt xsd sequence gt lt xsd element name quard type xsd string gt lt xsd sequence gt lt xzsd extension gt lt xsd complexContent gt lt xsd complexType gt
178. der Umgang mit XML Dokumenten oder die Integration externer Softwarekomponenten Die Umsetzung solcher Anforderungen durch eine formale Erweiterung von Petri Netzen w re nicht ohne Weiteres m glich Das Konzept der XML Netze hierzu kann ebenfalls nicht verwendet werden Das entscheidende Argument gegen den Einsatz von Petri Netzen ist jedoch dass sie zwar weitl ufig bekannt sind sich aber in der Praxis nie durchsetzen konnten Laien empfinden sie h u fig als zu technisch und unhandlich Die Ereignisgesteuerten Prozessketten sind in der Betriebswirtschaft ein bew hrtes Mittel zur Modellierung betrieblicher Abl ufe und Gesch ftsprozesse Besonders wegen ihrer recht einfachen und leicht verst ndlichen Darstellungsweise eignen sie sich f r die Anwendung durch technisch nicht geschultes Personal das damit Prozesse auf hohem Niveau modellieren kann Dieser Vorteil wird allerdings um den Preis einer fehlenden oder nicht ausreichenden formalen Festlegung von Semantik der Modelle erkauft Zwar haben einige wissenschaftliche Arbeiten in dieser Richtung Verbesserungen und Erg nzungen gebracht doch gibt es immer noch eine semantische L cke zwischen dem Gesch ftsprozessmodell und einer Spezifikation die von einem Workflow Management System ausgef hrt werden k nnte Ziel dieser Arbeit ist es aber ein Konzept aufzuzeigen mit dem XML Prozesse so modelliert werden k nnen dass sie anschlie end automatisch ausgef hrt werden k nnen Mit den semi form
179. der Workflows und steht im Widerspruch zur Forderung nach einer visuellen Modellierung von Prozessabl ufen Zum anderen m sste eine Erweiterung des Pipeline Konzepts stattfinden um Transfor mer flexibler als bisher verketten und somit komplexe Workflow Modelle wie bei spielsweise die Klassifizierung der Dokumenttypen in der Fallstudie aufbauen zu k nnen Die Betrachtung der ausgew hlten Systeme die den augenblicklichen Stand der Technik widerspiegelt hat gezeigt dass bisher noch keine umfassende L sung f r die sich unter anderem aus der Fallstudie ergebenen Anforderungen an eine prozessorien tierte Integration von Softwarekomponenten im Bereich des E Business existiert Trotz dem ist deutlich geworden dass der Einsatz von Workflow Modellen und deren rechnerunterst tzte automatisierte Ausf hrung einen guten Ansatz darstellt um die Integration und Anbindung bestehender Software Anwendungen eines Unternehmens an elektronisch abzuwickelnde Gesch ftsvorf lle und Prozesse voranzutreiben Im weiteren Verlauf dieser Arbeit soll daher sunShine um eine Workflow Management Komponente erweitert werden die die flexible Modellierung und Ausf hrung von Gesch ftsprozessen in realen E Business Systemen erm glicht siehe Kapitel 9 und 10 50 Kapitel 5 Evaluierung vorhandener Workflow Modellierungssprachen 5 1 Petri Netze 51 5 Evaluierung vorhandener Workflow Modellierungssprachen Im vorangegangenen Kapitel wurden drei Workflow Syste
180. der nicht funktionalen Sicht eingegangen Die Trennung in funktionale und nicht funktionale Sicht folgt dabei laut Bla00 S 4 dem Prinzip der aspektorientierten Programmierung Ein Global Workflow Manager Agent GWMA nimmt schlie lich diese Spezi fikationen des Workflow Modells entgegen und konvertiert sie in die interne Daten struktur Dabei handelt es sich jedoch nicht um ein XML Format so wie es in Abschnitt 3 2 gefordert wurde Anschlie end legt er die Modelle in der gemeinsamen Datenbank ab damit sie von den brigen Agenten zur Konfiguration und zur Ausf hrung der Workflow Modelle benutzt werden k nnen 4 2 4 Workflow Ausf hrung mit WARP F r das Erzeugen von Workflow Instanzen und die Kontrolle ihrer Ausf hrung sind die Agenten der Anwendungsschicht zust ndig Damit die modellierten Workflows ausge f hrt werden k nnen startet der GWMA f r jedes Workflow Modell eine Instanz des Workflow Manager Agent WMA Dieser bernimmt die Aufgaben die sich aus dem nicht funktionalen Modell des Prozesses ergeben wie Fehlerbehandlung Transaktions eigenschaften und hnliches Ein WMA bernimmt dabei nicht die vollst ndige Kon trolle einer Workflow Instanz sondern erg nzt lediglich die von den nicht funktionalen Eigenschaften geforderten Aufgaben Die Aufgabe der verschiedenen RMA besteht darin f r die Ausf hrung der Aktivit ten innerhalb der einzelnen Prozessinstanzen zu sorgen Aufgrund ihres Wis sens ber die verf gbar
181. deren Service folgen Um m glichst oft die Bedingung p lt p2 erf llen zu k nnen sollte p also minimal p maximal gew hlt werden wobei die Gegebenheiten der Servi ces nat rlich ber cksichtigt werden m ssen Offene Ports und Bindungen Die berlegungen aus dem vorausgegangenen Absatz f hren zu einem neuen Problem Viele Services deren Eingangsport mit any gekennzeichnet ist weil sie beliebige Dokumenttypen verarbeiten k nnen haben in der Regel auch einen gro en Variations bereich bei den Dokumenttypen ihrer Ausgaben Der oben erw hnte Archivierungs service w rde etwa beliebige Dokumente in einer Datenbank als Kopie sichern und das Dokument danach an den nachfolgenden Service weitergeben Daher m sste auch der Ausgangsport dieses Service mit any gekennzeichnet sein was laut vorausgegangener Betrachtung jedoch m glichst vermieden werden sollte Bei genauerer Analyse dieser Art von Services f llt auf dass zwar prinzipiell ein beliebiger unvorhersehbarer Dokumenttyp ausgegeben wird dieser Typ aber einge schr nkt werden kann wenn man den Service im Kontext des gesamten Prozess diagramms insbesondere der vorausgehenden Service Aktivit ten betrachtet Die folgende Abbildung zeigt noch einmal den Archiv Service in einem Prozessdiagramm Ausschnitt Inn Archivz 2 any Service a Service u Abb 6 9 Offener Port im Diagrammkontext Durch die Einbettung in diesen Diagrammkontext wird klar dass die A
182. des Workflow Managements und automatisierung nach der lediglich 18 Prozent aller Internet Anwendungen bislang in unternehmensweite Anwendungen integriert sind Hier bietet sich daher noch ein gro es Optimierungspotenzial was sich auch in den Planungen der befragten Unternehmen niederschl gt Die Fraunhofer Umfrage zeigt dass 38 Prozent der befragten Unternehmen gerade planen ihre Einkaufsm rkte zu integrieren 18 Prozent wollen das mit ihren Web Shops tun 30 Prozent der Unternehmen sind bereit ihren Kunden und Lieferanten einen Internet basierten Zugang zu Informationen aus ihrem ERP System zu bieten aus HenOl Damit wird klar dass in der zweiten Phase der E Business Welle die gerade beginnt der Schwerpunkt auf Web Enabling und Integra tion liegt ebd Die Thematik der unternehmensweiten Integration der verschiedensten alten legacy und neuen E Business Anwendungen wird unter dem Schlagwort Enterprise Application Integration EAI gehandelt Den meisten EAI Ans tzen gemein sind die drei Ebenen Anwendungsintegration Transformation und Gesch ftsprozessabbildung die in dieser Reihenfolge eine Abstufung des erzielbaren Integrationsgrads im Unter nehmen widerspiegeln aus CZO1 Bei der Anwendungsintegration wird ber ein heitliche Schnittstellen die Kommunikation zwischen den Anwendungen vereinfacht Da dies aber nicht immer m glich ist werden Transformationen ben tigt damit jede Einzelanwe
183. desto mehr zahlt es sich aus visuelle und damit bersichtlichere und besser handhabbare Modelle zu benutzen F r komplexe Prozessmodelle scheinen sich die Pipelines gar nicht mehr zu eignen weswegen bei der Projektl sung auch nur einzelne Prozessschritte durch Pipelines umgesetzt wurden Um dennoch das geforderte Workflow Management zu realisieren musste man eine Regel maschine als Java Servlet Applikation entwickeln mit der die Zustands berg nge zwischen den einzelnen Prozessschritten durchgef hrt werden k nnen Die Regeln f r diese Regelmaschine werden in einer eigens daf r entworfenen XML Sprache beschrie ben und entsprechen im Wesentlichen der Definition von Zust nden in denen eine bestimmte Pipeline aufgerufen wird und der Bestimmung von Folgezust nden hnlich wie bei den Pipelines gibt es auch f r die Definition der Regeln keine grafische Repr sentation und kein visuelles Modellierungswerkzeug so dass die sehr technisch formu lierten Regeln manuell vom Entwickler eingegeben werden m ssen Um einen kleinen Eindruck von der Syntax dieser Regelsprache zu vermitteln soll hier ein kleiner bereits vereinfachter Auszug gezeigt werden ohne im Detail auf die Semantik einzugehen lt Prozesstyp name Auditing gt lt Zustand id 0 name Auditing schreiben start Ja gt lt StandardAktion final Nein folgeid 1 name Auditing gt lt Verweis auf die Pipeline gt lt Url url http sunshine auditing schreib
184. die Transaktion best tigt werden konnte Er muss sich dann darauf verlassen dass die Teilnehmer intern sicherstellen dass die drei anderen Eigenschaften Konsistenz Isolation und Dauerhaftigkeit eingehalten werden beispielsweise indem sie selbst interne Transaktionen verwenden um auf Daten von Back End Systemen zuzugreifen Aufgrund dieser Gegebenheiten beschr nken sich die folgenden berlegungen ausschlie lich auf die Einhaltung der Atomarit t eines transaktionalen Prozesses Transaktionsf hige Services Damit ein Prozess berhaupt als Transaktion ausgef hrt werden kann m ssen alle verwendeten Services bestimmte Eigenschaften besitzen Beispielweise m ssen sie die Nachrichten ber Erfolg oder Scheitern der Transaktion empfangen k nnen oder wie bereits erw hnt so implementiert sein dass sie Konsistenz Isolation und Dauerhaftig keit gew hrleisten k nnen Sicherlich wird es nicht m glich oder erw nscht sein dass alle Services diese Eigenschaften besitzen F r Prozessdiagramme m sste daher die zus tzliche Bedingung formuliert werden dass innerhalb von transaktionalen Prozessen ausschlie lich geeignete Services verwendet werden d rfen Falls diese Einschr nkung nicht akzeptabel ist k nnte die Semantik eines transaktionalen Prozessdiagramms auch so definiert werden dass nur die nderungen von Services atomar ausgef hrt werden die Transaktionen unterst tzen alle anderen Services d rfen zwar ebenfalls verwendet we
185. die wiederverwendet werden kann Nur wenn dies nicht der Fall ist wird eine neue Instanz erzeugt Zur Erl uterung des Interface IXMLConnector siehe Abschnitt 10 5 Als Alternative zu einer solchen festen Zuordnung von Klassen zu Konnektor Interfaces k nnten auch intelligente Suchmechanismen zum Einsatz kommen Einen interessanten Ansatz in dieser Richtung stellt die neue Java Technologie Jini dar siehe JinO1 Sie stellt eine Infrastruktur zur Verwaltung dynamischer Dienste in Netzwer ken zur Verf gung Die Dienste k nnen sich beim System an und abmelden Kompo nenten die einen bestimmten Dienst in Anspruch nehmen m chten k nnen diesen im Netzwerk anhand eines Interfaces suchen den der Dienst erf llen soll Wir haben uns 224 Kapitel 10 Ausf hrung von XML Prozessen aus Zeitgr nden auf die einfache Variante der Klasse PropertyConnectorFactory beschr nkt Der Interpreter ist jedoch so ausgelegt dass sich jederzeit ohne gravierende nderungen eine andere L sung integrieren l sst Zum Aufruf eines Service dient die Hilfklasse ServiceCall Im Prozessmodell wird f r jeden Service Zustand der Name eines Konnektor Interfaces sowie einer seiner Service Methoden angeben Mit Hilfe der oben beschriebenen ConnectorFactory erlangt die Klasse ServiceCall die Instanz eines Konnektors der das geforderte Interface erf llt Anschlie end l sst sich in Java dynamisch ein Methodenaufruf der angegebenen Methode generieren Dazu m ssen Werte
186. dungsvorschriften umge setzt und entsprechene Werkzeuge implementiert die ein PML Dokument einlesen und die dort gespeicherten Prozessmodelle in der Datenstruktur f r das Metamodell siehe Abschnitt 7 4 ablegen PML Importer bzw eine Instanz des implementierten Meta modells als PML Dokument abspeichern k nnen PML Exporter Abschnitt 8 4 beschreibt Aufbau und Arbeitsweise dieser n tzlichen Werkzeuge 8 1 Anforderungen an Prozessbeschreibungssprachen Als Ma stab f r die sich anschlie ende Evaluierung vorhandener XML Beschreibungs formate f r Workflow Modelle und als Richtlinie f r den Entwurf von PML wurden die in diesem Abschnitt aufgef hrten Anforderungen aufgestellt Die einzelnen Punkte ergaben sich dabei aus den Zielsetzungen des Workflow Management Systems den Eigenschaften von Prozessdiagrammen oder einer besonders dargelegten Motivation Sie gliedern sich in Muss Bestimmungen Punkte 1 bis 10 und Soll Bestimmungen Punkte 11 bis 13 Eine Beschreibungssprache eignet sich demnach nur dann f r die Beschreibung von Prozessdiagrammen wenn sie mindestens alle Muss Bedingungen erf llt 1 XML Format Eine Prozessbeschreibung sollte als XML Dokument abgelegt werden F r die Forderung nach einem XML Format als Kodierung der Workflow Beschreibung gibt es mehrere Gr nde XML bietet sich aus Homogenit tsgr nden an weil das Workflow Management System insgesamt f r die Verarbeitung von XML Dokumenten ausgelegt ist und demnach
187. e XML 1 0 Second Edition W3C World Wide Web Consortium Recommendation 6 Oktober 2000 http www w3 org TR 2000 REC xml 20001006 James Clark Steve DeRose XML Path Language XPath Version 1 0 W3C World Wide Web Consortium Recommendation 16 November 1999 http www w3 org TR 1999 REC xpath 19991116 Jonathan Robie et al XML Query Language XOL W3C World Wide Web Consortium September 1998 http www w3 org TandS QL QL98 pp xql html XQueryOl Don Chamberlin et al XSch01 XSLT99 WenO00 WesOl Wet93 XQuery 1 0 An XML Query Language W3C World Wide Web Consortium Working Draft 07 Jun 2001 http www w3 org TR xquery David C Fallside XML Schema Part 0 Primer W3C World Wide Web Consortium Recommendation 02 Mai 2001 http www w3 org TR 200 REC xmilschema 0 20010502 James Clark XSL Transformations XSLT Version 1 0 W3C World Wide Web Consortium Recommendation 16 Nov 1999 http www w3 org TR 1999 REC xslt 19991116 R diger Wenski Eine objektorientierte Systemkomponente zur Workflow Modellierung und Ausf hrung unter besonderer Ber cksichtigung der Telekooperation Diss Heinz Nixdorf Institut Paderborn HNI Verlagsschriftenreihe 2000 Berthold Wesseler Integration Server automatisieren Gesch ftsprozesse und sparen Zeit Computer Zeitung Nr 32 vom 9 August 2001 S 14 Konradin Verlag Leinfelden Horst Wettstein Systemarchitektur Carl Hanser Verlag M nchen Wien 199
188. e Konnektoren vgl Abschnitte 6 1 2 und 6 2 und die von ihnen angebotenen Services mit denen bestimmte Softwarekomponenten in den Workflow integriert werden k nnen Ein Konnektor wird durch das Stereotyp componentConnector modelliert das auf dem UML Element Interface basiert Dieses Element erlaubt die Definition von Operationen die bei einer Realisierung des Inter faces von einer konkreten Konnektor Klasse implementiert werden m ssen 7 3 UML Profil f r Prozessdiagramme 133 Stereotyp componentConnector Basisklasse UML Core Interface Ober Stereotyp Tag Definitionen Keine Einschr nkungen Constraints Erl uterung Interfaces die als componentConnector klassifiziert sind spezifizieren Konnektoren zu vor handenen Softwarekomponenten Eine Sammlung solcher Interfaces bildet das statische Modell f r Prozessdiagramme siehe processDiagramm In den Konnektoren k nnen bestimmte Operationen siehe service definiert werden die von Aktivit ten siehe serviceState im XML Prozess aufgerufen werden Darstellung Darstellung des blichen Symbols f r Interfaces Die sonst f r Interfaces bliche Angabe interface wird durch componentConnector ersetzt componentConnector Name Operationen des Interface Tab 7 3 Definition des Stereotyps componentConnector Da die Operationen die von einem componentConnector als Services zum Aufruf in Prozessdiagram
189. e Sprache zu schaffen die keine unanschauliche mathematische Syntax hat sondern die vielmehr auch von Laien ohne fundiertes mathematisches Wissen leicht zu lesen und schreiben ist Dabei ist zu beachten dass OCL keine Programmiersprache sondern eine reine Ausdruckssprache ohne Seiten effekte ist d h die Auswertung eines OCL Ausdrucks kann keine Manipulationen am zu Grunde liegenden Modell ausl sen Die Erl uterungen zur OCL sollen beispielhaft anhand des Klassendiagramms aus Abbildung 7 1 erfolgen Dabei wird nur auf die OCL Sprachkonstrukte eingegan gen die f r diese Arbeit relevant sind Vergleiche zu OCL auch Omg01 6 1ff Eine formale Grammatik der Object Constraint Language in EBNF Notation findet sich in Omg01 6 96ff Kontext Zun chst muss in jedem OCL Ausdruck bestimmt werden auf welches Modellelement sich seine Aussagen beziehen Dazu wird der Klassenname des Elements hinter dem Schl sselwort context angegeben Wenn sich eine Aussage also auf das Element PseudoState bezieht sieht der Ausdruck folgenderma en aus context PseudoState inv Das Wort inv gibt dabei an dass es sich bei dem Ausdruck um eine Aussage ber das angegebene Element handelt die f r alle Exemplare des Elementtyps erf llt werden 124 Kapitel 7 Metamodell f r Prozessdiagramme muss Innerhalb des Ausdrucks wird mit Hilfe des Schl sselworts sel auf die Instanz des Elements verwiesen Logische Operatoren Zur Formulierung des Ausdrucks s
190. e aus dem Datenmodell verwendet werden da der Editor zus tzliche Funktionalit t ben tigt Daher wird mit Hilfe des in Abschnitt 7 4 Absatz Flexible Zugriffsschicht auf Elemente des Datenmodells beschriebenen Adapter Mechanismus die Schnittstelle der Klasse Service erweitert Zu diesem Zweck erbt ServiceAdapter indirekt von der Klasse AbstactModelElementAdapter Zus tzlich erf llt sie die vom Interface TreeNode geforderte Schnittstelle die aus Methoden wie children getAllowsChildren usw besteht Dieses Vorgehen erlaubt es Objekte der Klasse ServiceAdapter direkt als Knoten in den Projektbaum des Hauptfensters einzuf gen Die Methoden werden vom Swing System dazu benutzt die grafische Dar stellung des Baums zu generieren View Die Darstellung eines Service geschieht mit Hilfe einer Eingabemaske die durch die Klasse ServicePanelView implementiert wird Sie ist von der Swing Klasse JPanel abgeleitet die die notwendigen Methoden anbietet um eine solche Maske zu erstellen Im Konstruktor von ServicePanelView werden alle ben tigten grafischen Elemente wie Eingabefelder Listen Schaltfl chen usw erzeugt Es gibt prinzipiell zwei verschiedene M glichkeiten die Darstellung eines Modellelements zu realisieren Zum einen k nnte man f r jeden konkreten Service eine komplette MVC Einheit im Speicher anlegen D h jeder Service h tte seine eigene Eingabemaske die in das Hauptfenster eingeblendet wird sobald der Service im Projektb
191. e entsprechende Methode nicht gefunden wurde oder weil intern im Service ein Fehler aufgetreten ist der nicht abgefangen werden konnte ProcessExecutionException Ausnahme die die anderen Ausnahmen kapselt und nach au en an die bergeordnete Instanz weitergibt Tab 10 1 Typen von Ausnahmen beim Prozessinterpreter Wenn aufgrund eines Fehlers eine dieser Ausnahmen auftritt kann die Prozessausf h rung in der Regel nicht ohne Weiteres zu Ende gef hrt werden Die Abarbeitung wird dann zwangsl ufig gestoppt und der Fehler an die aufrufende Instanz gemeldet Nun kann es aber vorkommen dass Fehler bei einem Service auftreten die nicht unbedingt den Abbruch des gesamten Prozesses bedingen m ssen Vielleicht gibt es zum Beispiel alternative Prozesszweige die statt des fehlerhaften Teils ausgef hrt werden k nnten Die folgenden Abschnitte enthalten Betrachtungen ber M glichkeiten solche Fehler zu behandeln und diskutieren die Zweckm igkeit entsprechende Vorkehrungen im Prozessinterpreter zu treffen 226 Kapitel 10 Ausf hrung von XML Prozessen 10 3 1 Fehlertoleranz Die Grundidee fehlertoleranter Systeme ist dass sie selbst dann korrekte Ergebnisse liefern wenn w hrend der Abarbeitung ein Fehler aufgetreten ist Im Zusammenhang mit Prozessdiagrammen w re eine einfache M glichkeit zur Herstellung von Fehlertole ranz beim Auftreten eines Fehlers in einem Service nicht den ganzen Prozess abzubre chen
192. e sich der Konnektor intern merken muss Diese Klasse geht davon aus dass sich in der Prozessumgebung eine Menge von XML Dokumenten befindet die sich jeweils durch einen eindeutigen Namen identifizieren lassen Je nachdem in welcher Systemumgebung der Prozessinterpreter zum Einsatz kommt muss eine konkrete Implementierung von AbstractEnvironment erstellt werden Der Konnektor kann dann durch Aufruf der Methode getxML auf die XML Daten zugreifen Vergleiche zur Prozessumgebung auch Abschnitt 10 6 2 interface F lEnvironmentDependent AbstractEnvironment setEnvironment A environment AbstractEnvironment Void getXml name String Node Konnektor setEnvironment environment AbstractEnvironment Void serviceA Void Abb 10 13 Zugriff auf die Prozessumgebung 10 6 Integration in sunShine 235 10 6 Integration in sunShine Der Prozessinterpreter wurde zun chst als v llig selbst ndiges System entwickelt so dass er prinzipiell in jeder Umgebung eingesetzt werden kann Beispielhaft sollte er unter dem Namen sunFlow in die E Business Plattform sunShine integriert werden vgl Abschnitt 4 3 In diesem Abschnitt wird beschrieben wie diese Integration vorgenom men wurde und welche Schritte dazu notwendig waren 10 6 1 Der Sunflow Transformer Im Abschnitt 4 3 wurde das Konzept der Transformer von sunShine vorgestellt Damit ist es m glich eine Ressource zu definieren die
193. e typisierten Transitionen in Zusammenhang mit ihren Ports formal definiert Der Beweis des Migrationssatzes zeigt abschlie end dass durch die typisierten Transitionen konsistente berg nge zwischen den einzelnen Diagrammzust nden vorgenommen werden k nnen Die folgenden Betrachtungen fu en im Wesentlichen auf elementarer Mengen lehre und versuchen ber die Definition verschiedener Mengen der in den vorausge henden Abschnitten vorgestellten Syntax f r die Notation von Ports eine eindeutige Semantik beizuordnen Die Abs tze die sich explizit mit den Zusammenh ngen zur Syntax besch ftigen beziehen sich dabei auf die beiden EBNF Grammatiken aus Abschnitt 6 3 1 vgl Abbildungen 6 7 und 6 15 Def 6 1 Die Menge aller XML Elemente XmilElements ns s 3 XML Schema in dem ein Element mit dem Namen s f r den Namensraum ns namespace global deklariert wird Die Menge XmlElements enth lt somit alle durch irgendein Schema definierten XML Elemente Jedes Element wird durch seinen Namensraum und seinen Namen eindeutig identifiziert Das Element muss global definiert sein weil nur f r globale Elemente die Eindeutigkeit des Elementnamens gew hrleistet ist siehe XSchO1 Abschnitt 3 3 Syntax Ein Element aus XmlElements wird durch Ableitung des Nicht Terminals Element der EBNF Grammatik notiert Def 6 2 Die Menge aller XML Dokumente XmiDocs doc doc ist ein wohlgeformtes und g ltiges XML Dokument Die
194. eben Eine Bank bietet ihren Kunden die M glichkeit mit Hilfe eines Online Banking Systems verschiedene Kontotransaktionen im Internet auszuf hren Ein Applet beim Kunden generiert jeweils ein XML Dokument das die gew nschte Transaktion beschreibt und an den Webserver der Bank bermittelt Dort soll es einen XML Prozess durchlaufen der die notwendigen Verar beitungsschritte durchf hrt In unserem Beispiel stehen drei Softwarekomponenten und die zugeh rigen Konnektoren zur Verf gung die als Akteure innerhalb des Prozesses dienen sollen Dieses statische Modell des Prozesses ist in Abbildung 6 4 dargestellt componentConnector Mail en Eee MailConnector senden Ze QLConnector P EEN sendMail S BT executeOperation S 1 executeQuery S _ receiveMail ____ mai O zen 5 EE Em In SQL fangen Anfrage componentConnector CORBAConnector executeTransfer S lt Abb 6 4 Statisches Komponentenmodell des Prozesses Es existiert eine Komponente die in der Lage ist auf eine Datenbank zuzugreifen eine Komponente zum Ansprechen von entfernten Systemen mittels CORBA sowie eine Mail Komponente zum Versenden und Empfangen von E Mails Die Komponenten werden nicht direkt in den Prozess integriert sondern mit Hilfe von sogenannten Konnektoren angesprochen Diese Konnektoren bieten dem Prozessinterpreter der den Prozess ausf
195. ebenl ufigkeit und Synchronisation Entscheidungsbedingungen an Verzweigungen Schachtelung von Prozessteilen Angabe von XML Dokumenttypen mit Ports Typisierung von Transitionen Repr sentation sonstiger Sprachelemente Bekanntes Format oder Standard Dokumente verst ndlich und lesbar Keine Definition nicht ben tigter Elemente vorhanden nicht vorhanden Tab 8 3 Bewertung von PML bez glich der Anforderungen 8 4 Werkzeuge f r die PML Verarbeitung 187 8 4 Werkzeuge f r die PML Verarbeitung Im vorhergehenden Abschnitt wurde die Abbildung zwischen dem in 7 3 eingef hrten Metamodell und der Sprache PML definiert Um beide Formate in realen Systemen nut zen zu k nnen ben tigt man Werkzeuge die die Formate entsprechend den Abbil dungsvorschriften ineinander berf hren k nnen Dazu werden im Folgenden die von uns entwickelten Werkzeuge f r jede der beiden Transformationsrichtungen vorgestellt 8 4 1 PML Importer Zun chst soll der PML Importer beschrieben werden der in der Lage ist eine PML Beschreibung einzulesen und daraus eine Objektstruktur entsprechend den Datenklassen aus Abschnitt 7 4 aufzubauen Mit Hilfe des Importers k nnen Prozesse oder Packages importiert werden wobei sich die resultierenden Objekte sowohl in ein bereits im Spei cher befindliches zu einem fr heren Zeitpunkt importiertes Prozessmodell einf gen als auch zum Aufba
196. ecture Notes of Computer Science 2185 S 76ff Springer Verlag Berlin 2001 UN CEFACT OASIS ebXML http www ebxml org Rik Eshuis Roel Wieringa A Formal Semantics for UML Activity Diagrams Formalising Workflow Models CTIT Technical Report 01 04 University of Twente Februar 2001 http www ub utwente nl webdocs ctit 1 0000004e pdf Erich Gamma Richard Helm Ralph Johnson John Vlissides Entwurfsmuster Elemente wiederverwendbarer objektorientierter Software Addison Wesley 1996 D Georgakopoulos M Hornick A Sheth An Overview of Workflow Management From Process Modeling to Workflow Automation Infrastructure Distributed and Parallel Databases 3 S 119 153 1995 Kluwer Academic Publishers Boston Volker Gruhn Lothar Sch pe A Software Process for an Integrated Electronic Commerce Portal System 8 European Workshop on Software Process Technology EWSPT 2001 Lecture Notes of Computer Science 2077 S 90ff Springer Verlag Berlin 2001 http ls10 www informatik uni dortmund de schoepe artikel ewspt pdf Goldene Seiten Online Portale und virtuelle Marktpl tze Was ist ein Portal http www gso at service handelsportale wasisteinportal html Hans Ulrich Hei Kommunikation zwischen Prozessen Skriptum zur Vorlesung Konzepte und Methoden der Systemsoftware 7 2 Universit t Paderborn 2000 http www uni paderborn de cs ag heiss lehre kms kms_7_4 pdf Hans Ulrich Hei Transaktionen in
197. edTransition kann daher zwecks besserer berschaubarkeit entfallen Tag type Stereotyp typedTransition Typ ProcessDiagrams transitionType Multiplizit t 1 Erl uterung Verweis auf den Typ einer Transition Tab 7 9 Definition des Stereotyps typedTransition Guard Bedingungen Um den Kontrollfluss eines Prozesses zur Laufzeit beeinflussen zu k nnen werden Ausdr cke einer XML Anfragesprache wie XPath XQL oder XQuery in Guards ver wendet Ein Guard wird einer Transition zugeordnet wobei diese Transition nur genutzt werden kann wenn sich sein Ausdruck als wahr erf llt In UML Metamodell besitzt 7 3 UML Profil f r Prozessdiagramme 143 das Element Guard ein Attribut vom Typ BooleanExpression Ein solcher boolscher Ausdruck besteht aus zwei Teilen der Angabe einer Sprache in der die Bedingung formuliert ist und der Bedingung selbst in Form eines Strings Um nun beispielsweise XPath Ausdr cke in Guards zu erm glichen muss lediglich als Sprache des Ausdrucks XPath angegeben werden Die Auswertung eines konkreten Ausdrucks erfolgt erst bei der Ausf hrung durch den Prozessinterpreter Es ist also nicht erforderlich das UML Metamodell hierf r zu erweitern 7 3 3 Wohlgeformtheitsregeln Neben den vorgenommenen Erweiterungen des UML Metamodells gibt es folgende Einschr nkungen die f r Prozessdiagramme eingehalten werden m ssen damit sich eine korrekte Semantik ergibt 1 Zust nde im P
198. eennnneennnennsnnnsnsnnnsnsnenennnen 66 5 3 1 Basiskonstrukte von Aktivit tendiagrammen uusseeneenenenennnn 66 5 3 2 Gesch ftsprozessmodellierung mit UML ssseseeesseseesersresrersersrerrreserssee 69 5 3 3 Eignung f r Prozessdiagramme sssessseesseseesseesseessersseesseresseeessresseesse 70 5 4 Bewertime nn NEE 71 XML Prozesse und Prozessdiagramme e esssccessosecesssooeessooeessooecesssscossssoosseso 75 6 1 Konzeption von XML Prozessen uursunesnnesnneesnnersnnesnnennnnennnennnnnsnnennnennne en 75 6 1 1 D k mentmisratien gr 75 6 1 2 Komp onentenintegrati n nes 79 6 1 3 Modell und Ausf hrungsebene 20u02200sssnneessnnesnnnennnnnennnn 81 6 1 4 Management von XML Prozessen uuessssessssesssnneessnnesnnnnnennnnnenn nennen 82 6 2 Modellierung mit Prozessdiagrammen u rnuursssesnnersnnensnersnnennnennnn ernennen 84 6 2 1 Aktivit ten zur Komponentenintegration uu 22200220er ner snneennennnnen nennen 87 6 2 2 Parametrisierung von Komponenten uu nsuersnersnnesnnersnersnnennnennnnennnen non 87 6 2 3 Transitionen als XML Dokumentfluss 2220022002202 sn essen nnnen nennen 88 6 2 4 Guard Bedingungen east ee ren 89 6 2 5 Behandlung von parallelen Teilprozessen 24422044222 nennen 89 6 2 6 Einschr nkungen gegen ber Aktivit tendiagrammen ne 90 6 3 Modellierung der Dokumenttypen u 222uussssesssnsenssnnensnnnnnn
199. egeben Obwohl das EPK Modell graphbasiert ist haben sich die Autoren entschieden die Syntax nicht operativ durch Graphgrammatiken sondern deklarativ durch Spezifikatio nen anzugeben Danach ist ein EPK Modell EPKM ein typisierter attributierter gerichteter zusammenh ngender Graph der durch folgendes 7 Tupel gegeben ist EPKM ld V K T Tk amp Ox dabei ist Id die eindeutige Identifizierung des EPKM v die endliche Menge der Knoten einer EPK wobei Ivl 2 3 da jede EPK mindestens ein Startereignis eine Funktion und ein Endereignis enth lt K die Kantenrelation die die Verbindungen zwischen den Knoten be schreibt K c vxv T die Abbildung die jedem Knoten einen Typ zuweist Tt V Funktion Ereignis Prozesswegweiser Oder Konnektor Tk die Abbildung die jeder Kante einen Typ zuweist Tk K Kontrollflusskante Informationsflusskante 0A die Abbildung die jedem Knotentyp seine Attribute zuweist Ok die Abbildung die jedem Kantentyp seine Attribute zuweist Mit diesem Formalismus lassen sich weitere Begriffe wie Nachbarschaftslisten Kno tengrade und genauere Partitionierungen der Knoten und Kantenmengen bestimmen In Kel99 sind aufbauend auf diesen und weiteren Definitionen Konsistenzbedingungen f r ein EPK Modell formuliert worden die eine EPK einhalten muss um bez glich des Kontrollflusses korrekt zu sein vgl Kel99 S 172f 5 2 3 Gesch ftsprozessmodellierung mit EPK
200. ehmen oder Software herstellern wie SAP entwickelt und geliefert werden SAP stellt zum Beispiel ber 800 Prozessbausteine zur Verf gung mit denen ein Unternehmen an seine Bed rfnisse angepasst seine Wertsch pfungsketten modellieren kann Oft gibt es f r bestimmte Branchen bereits spezielle Varianten f r nur dort bliche Prozesse Nach der Auswahl von Prozessbausteinen m ssen diese allerdings meistens noch individualisiert und dem jeweiligen Unternehmen angepasst werden So wird aus dem Referenzmodell ein unter nehmensbezogenes Modell vgl Sch98 S 61ff Bei der Aufgabenbeschreibung mittels der EPK Methode ist ein nicht unwichti ges Teilelement die organisatorische Zuordnung von Aufgaben zu betrieblichen Auf gabentr gern bzw Unternehmensorganisationseinheiten Kel99 S 160 Dieser Aspekt wird bei den Modellierungstechniken die in der vorliegenden Arbeit angewandt werden sollen allerdings keine wichtige Rolle spielen weil dort systemorientierte Pro zesse betrachtet werden bei denen Softwarekomponenten und nicht betriebliche Aufga bentr ger die Aktionen ausf hren 5 2 4 Eignung f r Prozessdiagramme Die Ereignisgesteuerte Prozesskette ist eine oft benutzte Methode zur Modellierung von Gesch ftsprozessen Inwiefern sie auch den Anforderungen an eine Modellierungs sprache zur L sung der in dieser Arbeit behandelten Thematik gen gt soll im Folgen den durch einen Abgleich mit den Anforderungen aus Abschnitt 3 3 darge
201. eht die zweite Art von Prozessfehlern in Ausnahmesituationen innerhalb des Prozessinterpreters in seiner Rolle als Transaktionsverwalter Dabei sind gew hnliche Laufzeitfehler relativ unkritisch da der Interpreter lediglich so implementiert werden muss dass dann die Transaktion mit Abort abgebrochen und dies allen betroffenen Services mitgeteilt wird Dies ist mit Hilfe des Mechanismus der Java Exceptions einfach m glich Als weitaus problematischer erweisen sich Ausf lle des Interpreters die durch einen Absturz der Systemumgebung hervorgerufen werden k nnen Entsprechend der Semantik von Transaktionen muss auch in einem solchen Fall die Einhaltung der ACID Eigenschaften sichergestellt sein Dabei besteht eine Reihe von Problemen f r die L sungskonzepte entwickelt werden m ssen 232 Kapitel 10 Ausf hrung von XML Prozessen 1 Eine unerl ssliche Ma nahme zur Behandlung von Systemausf llen ist die Proto kollierung der Prozessausf hrung durch den Interpreter vgl Bac98 S 484ff damit er beim Wiederanlaufen des System ermitteln kann an welcher Stelle eines Prozesses der Ausfall stattgefunden hat und dementsprechende Ma nahmen ergrei fen kann 2 Ein grundlegendes Problem besteht darin dass nach einem Ausfall des Prozess interpreters alle Objektinstanzen der Konnektoren auf denen Services aufgerufen wurden verloren sind Nach dem Wiederanlaufen m sste der Interpreter sich neue Instanzen besorgen vgl Abschnitt 10 2 4 Dabei
202. ei XML Prozessen in Form des Prozess interpreters der Fall ist Innerhalb jedes beteiligten Systems gibt es jedoch einen lokalen Transaktionsverwalter der f r die Verwaltung der dort vorhandenen Daten zust ndig ist Die lokalen Verwalter werden vom zentralen Verwalter ber Erfolg oder Scheitern von Transaktionen benachrichtigt und m ssen dementsprechende Ma nahmen ergreifen vgl Bac98 S 495ff Zus tzlich dazu ist bei XML Prozessen die Situation gegeben dass das Work flow Management System d h der Prozessinterpreter gar keinen direkten Zugriff auf alle Daten besitzt Die einzigen Daten von denen der Interpreter Kenntnis hat ist das Migrationsdokument Alle anderen Datenquellen werden ausschlie lich innerhalb der Services eines Prozesses angesprochen die f r den Interpreter jedoch Black Boxen darstellen Der Interpreter kann also gar nicht selbst daf r sorgen dass die ACID Eigen schaften nicht verletzt werden Weiterhin ist f r das Migrationsdokument keine Trans aktionskontrolle erforderlich da niemals mehrere Services gleichzeitig darauf zugreifen und es zudem keinen persistenten Datenbestand im eigentlichen Sinne darstellt Die Rolle des Prozessinterpreters als Transaktionsverwalter muss sich aus diesen Gr nden auf die Sicherstellung der Atomarit t beschr nken indem er entweder im Falle eines Scheiterns des Prozesses alle betroffenen Systeme benachrichtigt damit sie ihre nderungen zur ckf hren oder ihnen mitteilt dass
203. ei das XSL Stylesheet des Transitionstyps der der Transition zugeordnet ist Es wird im Attribut transformation des Stereotyps transitionType festgelegt Interpretation von Prozessdiagrammen Nachdem nun eine Semantik f r Prozessdiagramme festgelegt wurde kann ein System entwickelt werden dass ein XML Eingabedokument und eine Prozessbeschreibung als Eingabe erh lt und diese Schritt f r Schritt abarbeitet Aufgrund dieser Funktionsweise sprechen wir in dieser Arbeit von einem Prozessinterpreter Alternativ k nnte f r die Ausf hrung auch ein bersetzer zum Einsatz kommen Dieser w rde die PML Beschreibung eines Prozesses einlesen und daraus ausf hrbaren Code also beispielsweise eine Java Klasse erzeugen der dann direkt ausgef hrt wer den k nnte ohne dass ein Interpreter den Prozess schrittweise abarbeitet Die Verwen dung eines bersetzers bedeutet vor allem f r solche Prozesse Effizienzverbesserungen die einmal definiert und dann h ufig ausgef hrt werden Es ist jedoch auch denkbar dass ein Benutzer einen individuellen Prozess modelliert und diesen gemeinsam mit dem Eingabedokument an die ausf hrende Instanz sendet Ein solcher Prozess w rde vermutlich nur einmal ausgef hrt so dass eine zuvor notwendige bersetzung in eine Java Klasse zus tzlichen und unn tigen Rechenaufwand bedeutete Ein weiterer Nach 10 1 Semantik von Prozessdiagrammen 215 teil der bersetzung ist dass bei jeder nderung eines Pr
204. eichender Unterst tzung bei der Modellierung flexibler Workflow Modelle und dem vollst ndigen Fehlen eines visuellen Modellierungswerkzeugs erge ben Eine M glichkeit zur visuellen Modellierung ist jedoch Voraussetzung f r die Ein beziehung informationstechnisch nicht geschulten Personals in das Workflow Manage ment siehe 2 3 Somit hat sich gezeigt dass bisher noch keine umfassende L sung f r die Anforderungen an eine prozessorientierte Integration von Softwarekomponenten im Bereich des E Business existiert Im zweiten Teil der Arbeit wurden darum eigene Kon zepte entwickelt die die Anforderungen erf llen und einen prozessorientierten Ansatz zur Softwareintegration in E Business Systemen erm glichen Erstes Ziel und eine wichtige Anforderung siehe oben Punkt 1 und Ab schnitt 3 2 Punkt 3 war die Einbindung bestehender Softwarekomponenten Dazu wurde in Abschnitt 6 1 die Idee der Konnektoren vorgestellt Dabei handelt es sich um kleine Softwaremodule die eine Br ckenfunktion zu den heterogenen Systemen ber nehmen Zur E Business Plattform bzw zum Workflow Interpreter bieten sie eine ein heitliche Schnittstelle f r den Datenaustausch und konvertieren diese Daten in Formate die f r die anzuschlie enden Back End Systeme verst ndlich sind Jeder Konnektor kann verschiedene Services anbieten Jeder Service kapselt eine bestimmte Back End Funktionalit t Auf der Modellebene k nnen die Services durch abstrakte Repr sen tanten in
205. ell z B UML Modell XMI Dokument Abb 8 2 Zusammenhang zwischen XMI XML MOF und UML Die Produktionsregeln zur Abbildung eines Metamodells in eine DTD enthalten Gene rierungsschablonen mit denen sich die Grundprimitive des MOF wie Klassen Attribute und Assoziationen in XML Strukturen berf hren lassen vgl Jec00 Dabei wird zum Beispiel f r jede Klasse und f r jedes Attribut der Klasse ein eigenes XML Element unter Beibehaltung der eindeutigen Namensgebung definiert Die Elemente f r die Attribute sind dem Element f r die Klasse untergeordnet und werden von diesem umschlossen Als Inhaltsmodell werden soweit m glich die Attributdatentypen des Klassendiagramms beibehalten skalare Datentypen werden als PCDATA definiert Aufz hlungsdatentypen werden durch ein leeres Element mit einem Attribut abgebildet bei dem der DTD Aufz hlungsmechanismus benutzt wird ber den jeweiligen Rollen namen lassen sich auch Assoziationen zu anderen Klassen als Unterelement eines Klas senelements definieren wobei im Inhaltsmodell auf ein Element f r die assoziierte Klasse verwiesen wird Dadurch k nnen im XMI Dokument die Auspr gungen der Klassen entsprechend ihrer Beziehungen hierarchisch geschachtelt werden Verer bungsbeziehungen werden im Wesentlichen durch einfaches Kopieren der Elemente aus der Elternklasse realisiert Derzeit laufen Initiativen zur Portierung der XMI Prinzipien von DTDs auf den Nachfolgestandard XML Schema Es
206. elle auf eine detaillierte Betrachtung dieser Prozessbeschreibungssprachen verzichtet werden 8 2 2 Der XML Metadata Interchange Standard XMI Der von der OMG spezifizierte Standard XML Metadata Interchange XMI siehe XMI00 stellt einen L sungsversuch f r die Austauschproblematik objektorientierter Modellierungssprachen dar ber die Festlegung auf einen gemeinsamen Industrie standard f r die textuelle Darstellung von objektorientierten Modellen hinaus handelt es sich um einen generativen Ansatz mit dem sich f r verschiedene Metamodelle automa tisch XML Formate erzeugen lassen Daher soll an dieser Stelle untersucht werden inwiefern mit diesem Standard ein Format f r das Speichern von Prozessdiagrammen gewonnen werden k nnte Bei der Entwicklung von XMI wurde urspr nglich ein einheitliches Textformat gesucht mit dem sich in UML erstellte Modelle zwischen verschiedenen Modellie rungswerkzeugen und CASE Tools austauschen lie en Bei dem Entwurf eines entspre chenden XML Formats kam man schnell zu der Notwendigkeit eines generativen Ansatzes um der raschen Weiterentwicklung von UML Rechnung zu tragen und auch zuk nftige Erweiterungen flexibel in das Austauschformat integrieren zu K nnen vgl Jec00 So ist ein Konzept entstanden mit dem sich f r alle derzeitigen und zuk nfti gen Sprachen die auf der Meta Object Facility MOF siehe MOFO0 der OMG basie ren ein Austauschformat f r Metadaten erzeugen l sst MOF ist dabe
207. ellierungssprache bzw das Metamodell f r Prozessdiagramme integriert siehe 6 3 Die Modellierung der Dokumenttypen durch die sogenannten Ports leistet einen bedeutenden Beitrag zur Konsistenzerhaltung und Fehlervermeidung bei der Modellierung Mit diesem Typsystem k nnen an den Ein und Ausgabeschnitt stellen der Services die Dokumenttypen spezifiziert werden die der Service als Eingabe verarbeiten bzw als Ausgabe produzieren kann Werden die Services miteinander zu einem Workflow verkettet muss sichergestellt sein dass die Ausgabe eines Service als Eingabe des nachfolgenden Service benutzt werden kann Wenn im Modell die entspre chenden Ports bereits zueinander kompatibel sind kann auch die Kompatibilit t der Dokumente zur Ausf hrungszeit gew hrleistet werden Die dem Port Konzept zu Grunde liegende Theorie erlaubt eine algorithmische Suche nach inkonsistenten Zustands berg ngen bei inkompatiblen Port Schnittstellen in einem Prozessdiagramm Bei entsprechender Tool Unterst tzung Kann der Modellierer dadurch von vornherein an der Erstellung fehlerhafter Modelle gehindert und bei der Modellierung g ltiger 248 Kapitel 12 Schlussbetrachtungen Modelle unterst tzt werden siehe oben Punkt 5 Der Zusatzaufwand bei der Modellie rung der sich aus der Ber cksichtigung der Dokumenttypen und den Ports ergibt kann durch den Algorithmus f r die automatische Portberechnung siehe 7 6 auf ein Mini mum reduziert werden Wenn in einem Proze
208. ementsprechend soll ein Portalmanager in Verbindung mit einem Content Management System eingesetzt werden Eine besondere Herausforderung ist dabei die Personalisierung der Inhalte so dass jedem Anwender und Kunden eine individuell f r seine Sicht zusammengestellte Informationsmenge angeboten werden kann 26 Kapitel 3 Anforderungsanalyse 3 1 3 Architekturvorschlag Um die aufgestellten Anforderungen zu konkretisieren wurde von der Informatik abteilung des Finanzinstituts ein erster Architekturvorschlag unterbreitet der schema tisch in folgender Abbildung wiedergegeben wird Eingabedokument HTTP Request e Mail propriet res Format WFMS 1 Identifizierung des Eingabedokuments 4 gt Archiv und Workflow Zwischen Managementsystem speicher f r 2 Transformation in XML Format XML Parser Pa XSL Prozessor 3 Ablegen einer Kopie im Archiv w gt si Regelmaschine gt 4 Weiterleiten anhand der Regeln mit Regelwerk Verarbeitung durch Services 5 Transformation ins Ziel Format Ausgabedokument Service Service Sanice Pr HTML Seite Dokumente e Mail Middleware o XML Daten WML f r WAP L Back End Gesch fts N Systeme C COBOL Abb 3 1 Architekturvorschlag f r eine E Business Plattform Als zentrale Komponente der Plattform kann das Workflow Management System ange sehen werd
209. en Parametereinstellungen an diesen Komponenten vorzunehmen die bei der Ausf hrung der zugeh rigen Aktivit t ber cksichtigt und an die Komponente bergeben werden Die M glichkeit Prozesse durch Bausteine aggregieren bzw in Teilprozesse aufspalten zu k nnen ist durch das Konstrukt der Subaktivit tszust nde gegeben in denen ein komplettes Teildiagramm in ein bergeordnetes integriert werden kann Die letzte Forderung nach einem Konstrukt zur Spezifizierung von Aktionsfolgen als Trans aktion ist in Aktivit tendiagrammen bisher nicht umgesetzt worden 5 4 Bewertung Nachdem in den vorangegangenen Abschnitten die ausgew hlten Modellierungs sprachen ausf hrlich gegen ber den einzelnen Anforderungen evaluiert wurden soll nun ein zusammenfassendes Fazit gezogen werden Dazu sind in Tabelle 5 3 alle Anforderungen aus Abschnitt 3 3 bzw 3 4 und die Bewertung der einzelnen Sprachen in Kurzform aufgelistet Anforderung Petri Netze EPK UML Aktiv Visuelle Sprache Allgemein akzeptiert 0 Leicht Intuitiv verst ndlich O Ablauforientiert Alle Basiskontrollfluss Konstrukte Ein Start und ein Endpunkt 1 1 1 XML Dokumentfluss 2 2 2 Zugriff auf XML Dokumente 2 2 2 Integration von Softwarekomponenten Parametrisierung der Komponenten Geschachtelte Prozesse Hierarchie Statisches Modell der Komponenten 3 Transaktionale Prozesse
210. en Darauf basierend definieren Dokumenttypen eine bestimmte Menge von XML Dokumenten Eine Menge von Dokumenttypen wiederum spezifiziert einen Port Jeder Port kann mit den zugeh rigen Dokumenttypen die zul ssigen Eingaben eines Modellelements oder dessen m gliche Ausgaben definieren Au erdem muss es m glich sein einen Port auf Kompatibilit t gegen ber einem anderen Port zu pr fen Damit l sst sich feststellen ob die Ausgabe des einen Elements Eingabe des nachfol genden Elements sein kann und sie daher problemlos als Nachfolger innerhalb eines Workflows angeordnet werden k nnen F r diese Kompatibilit tspr fung wird eine spezielle Teilmengen Beziehung auf Ports definiert Der daraufhin vorgestellte Kompatibilit ts Satz beweist das diese Teilmengen Beziehung tats chlich als Kriterium f r eine konsistente Verkettung von Ports herangezogen werden kann Schlie lich muss auch die theoretische Fundierung des Port Konzepts gen gend Flexibilit t bieten um damit Schnittstellen definieren zu k nnen die nur teilweise 110 Kapitel 6 XML Prozesse und Prozessdiagramme bekannt sind oder offene Schnittstellen die erst im Kontext eines konkreten Prozess diagramms vollst ndig gebunden werden k nnen Der zugeh rige Teil dieses Abschnitts definiert wie eine solche Bindung exakt vorgenommen werden muss und liefert damit eine wichtige Grundlage f r die sp tere Implementierung des Port Konzepts Zum Schluss des Abschnitts werden auch di
211. en sein k nnen Ein Package ist ein Container f r ContainerElement Objekte Dementsprechend hat die Klasse Package eine qualifizierte 1 n Assoziation zu ContainerElement und kann damit eine Menge beliebiger Objekte enthalten deren Typ von ContainerElement abgeleitet ist Da Packages ineinander verschachtelt sein k n nen ist auch die Klasse Package selbst eine Unterklasse von ContainerElement Entsprechend dem _ Entwurfsmuster Composite siehe Gam96 S 239 kann so eine baumartige Package Struktur entstehen an deren Bl ttern Container elemente wie Konnektoren oder Transitionstypen h ngen Die Klasse ProcessModel als spezielles Package soll als Wurzel knoten dieser Baumstruktur benutzt werden und quasi ein Ursprungspackage darstellen in dem alle anderen Packages ent halten sind Damit st nde ein Objekt vom Typ ProcessModel an der Spitze des gesamten Modells Die Klasse TransitionType realisiert das Stereotyp transitionType mit seinen entsprechenden Attributen f r die Bedeutung der einzelnen Attribute siehe Abschnitt 7 3 2 Die ComponentConnector Service Parameter 7 4 Implementierung des erweiterten Metamodells 149 Attributtypen Expression Port und OpenPort wurden bereits als Datentypen vorgestellt Die Zuordnung eines Transitionstypen zu Transitionen erfolgt sp ter bei der Betrachtung der dynami schen Modellelemente Die Klasse ComponentConnector realisiert das Stereotyp componentConnector aus Abschnit
212. en welches die eingehenden Dokumente entgegennimmt und deren weitere Verarbeitung steuert bis schlie lich die entsprechende Antwort als Ausgabedokument auf die Anfrage geliefert wird Dabei benutzt das WFMS andere Komponenten um die Teilaufgaben der Formattransformation der Archivierung des Parsens und des Weiter leitens an spezielle Services mit Verbindung zu den Back End Systemen zu erf llen Das WFMS berwacht und steuert die automatisierte Verarbeitung des Gesch fts vorfalls bis zum Ende Der Vorgang und sein augenblicklicher Zustand wird dabei jeweils durch das aktuelle Dokument repr sentiert Da das eingehende Dokument entsprechend den Anforderungen in sehr ver schiedenen inkompatiblen Formaten vorliegen kann ist nach der Erkennung des Dokumentes zun chst eine Transformation in ein einheitliches internes Format n tig Als Grundlage f r dieses Format wird XML benutzt Werkzeuge wie ein XML Parser und ein Stylesheet Prozessor f r die Transformationssprache XSLT eXtensible Style sheet Language Transformation siehe XSLT99 helfen bei der Konvertierung in das interne Format Sie werden auch nach der Verarbeitung benutzt um die Dokumentdaten wieder in das vom Klienten geforderte Format zu konvertieren Nicht eindeutig erkenn bare oder falsch formatierte Dokumente werden ausgesondert und m ssen manuell 3 1 Fallstudie E Business Plattform eines gro en Finanzunternehmens 27 berpr ft werden Daten die bereits im richtigen F
213. en Dienste und ihre Rollen sind sie in der Lage den jeweils pas senden Dienst anzusprechen Die dazu ben tigten Informationen entnehmen sie aus der gemeinsamen Datenbank in der sich alle notwendigen Modelle und Daten befinden Um ber anfallende Aufgaben w hrend der Ausf hrung benachrichtigt zu werden bzw selbst Auftr ge an andere Agenten zu verteilen bedienen sich die Agenten des zentralen Event Servers Dieses Zusammenspiel der einzelnen Systembestandteile f hrt zu einer korrekten Abarbeitung der zuvor vom Prozessdesigner definierten Workflow Modelle 4 3 E Business Plattform sunShine 43 4 3 E Business Plattform sunShine Bei sunShine handelt es sich laut Sun01 um eine Integrationsplattform f r B2C und B2B Anwendungen Mit seiner Hilfe l sst sich sowohl das Layout als auch die Gesch ftslogik von Webauftritten realisieren Im Folgenden wird zun chst sunShine allgemein vorgestellt und daran anschlie end detaillierter auf die Systemkomponenten eingegangen die f r die Modellierung und Ausf hrung von Gesch ftsprozessen rele vant sind Das wichtigste Ziel von sunShine ist die Realisierung von Portalen Nach Gso01 ist ein Portal eine Website die ihre Besucher beim individuellen Aussuchen von Informationen und Produkten unterst tzt indem es eine Vielzahl von personalisier baren Informationen und Dienstleistungen rund um das spezielle Thema bietet die nicht nur aus dem Unternehmen bzw vom Betreiber stammen m ssen Wenn
214. en Nachrichten austausch unterst tzt siehe Moh01 S 21 Empf ngt BizTalk Server eine solche Nachricht leitet er sie dem Nachrichtentyp entsprechend an eine bestimmte Organisa tionseinheit oder Komponente weiter Damit ist eine flexible Verarbeitung von XML Dokumenten m glich und durch den Nachrichtenaustausch werden die einzelnen Kom ponenten gleichzeitig mit den n tigen Workflow relevanten Daten versorgt 40 Kapitel 4 Evaluierung vorhandener Workflow Systeme ber die Konzepte Port und Channel werden f r die einzelnen sendenden wie empfangenden Komponenten Eigenschaften wie zum Beispiel das zu Grunde liegende Protokoll festgelegt die f r einen reibungslosen Nachrichtenaustausch ben tigt werden Die Nachrichten bertragung erfolgt entweder per Windows spezifischer Kommunika tion oder ber offene Internetprotokolle wie SMTP und HTTP siehe Moh01 S 22ff Warteschlangen Konzepte erlauben das Puffern von Nachrichten was die Zuverl ssig keit und Skalierbarkeit des Systems verbessert vgl Moh01 S 26 Wird bei der Modellierung ein Prozessteil als Transaktion gekennzeichnet ist daf r ein Kompensationsprozess zu beschreiben der ausgef hrt werden soll wenn der Prozessteil aufgrund eines Fehlers scheitert oder nicht vollst ndig ausgef hrt werden konnte vgl Mic00 S 9 Dieses Konzept erm glicht zwar eine recht einfache Umset zung einer Transaktionsunterst tzung w nschenswert w re aber eine automatische R cksetzung e
215. en gleichen Ausgangsport wie der Endzustand des eingebetteten Prozesses if state oclIsTypeOf SubactivityState then let embeddedFinal FinalState state oclAsType SubactivityState subvertex gt select s s ocl1sKindOf FinalState outputPort embeddedFinal stereotype oclAsType stateWithPorts outputPort endif 10 Ein FinalState hat als Ausgangsport den Ausgangsport des zugeh rigen Prozess diagramms if state oclIsTypeOf FinalState then outputPort state incoming stateMachine stereotype oc1lAsType processDiagram definedTaqg gt select name outputPort typedValue referencedValue oclAsType Port endif 11 Ein ServiceState hat einen Eingangsport der Teilport des Eingangsports ist der f r den angesprochenen Service im statischen Modell deklariert wurde siehe Abbildung 6 16 if state oclIsTypeOf CallState then inputPort isSubsetOf state entry oclAsType CallAction operation stereotype oclAsType service definedTaqg gt select name inputPort typedValue referencedValue oclAsType Port endif 12 Ein ServiceState hat einen Ausgangsport f r den der gebundene Ausgangsport der f r den angesprochenen Service im statischen Modell deklariert wurden ein Teilport ist siehe Abbil dung 6 16 if state oclIsTypeOf CallState then predecessors gt forAll pre state entry oclAsType CallAction operation stereotype oc1lAsType service definedTaqg gt select name outputPort
216. en menschlichen F higkeiten als auch die Anfor derungen der Aktivit ten ber cksichtigt werden Auch die Gegebenheiten in den B ros und an den Arbeitspl tzen sowie die jeweils bliche Art der Zusammenarbeit haben Auswirkungen auf die Auspr gung der Mensch orientierten Prozessmodelle vgl Wen00 S 6f Solche Fragestellungen der teamorientierten Aufgabenabwicklung sind Gegenstand des Forschungsgebietes des Computer Supported Cooperative Work CSCW Dort wird die spezielle Klasse von Computersystemen untersucht die Gruppenarbeit und andere Formen der menschlichen Zusammenarbeit durch Koor dination Kooperation und Kommunikation unterst tzen Daher befasst sich CSCW auch mit dem Management von Mensch orientierten interaktiven Workflows Mensch orientierte Workflow Modelle haben Informationen ber die Prozess semantik d h sie wissen zum Beispiel in welcher Abfolge ein Dokument weitergeleitet werden muss Das Prozessmodell impliziert aber kein genaues Wissen ber die Daten inhalte des Dokuments und die Semantik der zu verarbeitenden Daten Darum kann ein Workflow Management System hier nicht die inhaltliche Konsistenz der Daten sicher stellen Diese Aufgabe muss von den beteiligten Menschen wahrgenommen werden Bei den systemorientierten Prozessen dagegen kann man in das Modell des Workflows Informationen ber die Semantik und die Struktur der zu verarbeitenden Daten integrieren Dadurch gewinnt das WFMS bei der Ausf hrung des Modells an
217. en xml gt lt StandardAktion gt lt Zustand gt lt Zustand id 1 name Auditing Antwort start Nein gt lt StandardAktion final Ja name Auditing Antwort gt lt Verweis auf die Pipeline gt lt Url url http sunshine auditing antwort xml gt lt StandardAktion gt lt Zustand gt lt Prozesstyp gt Abb 11 4 Auszug aus dem Regelwerk zur Ablaufsteuerung nach BadO1 Die Idee und Konzeption des Regelwerks in Verbindung mit der Regelmaschine erin nert an die Interpretation der PML Dokumente vgl Kapitel 8 durch den in Kapitel 10 vorgestellten Prozessinterpreter In der Tat gibt es einige Parallelen in den beiden zu Grunde gelegten XML Formaten allerdings besteht der wohl gravierendste Unterschied darin dass mit PML die Prozessbeschreibungen einheitlich vorliegen und nicht in Regelwerk und Pipelines zerst ckelt werden Bei Prozessdiagrammen kann zwar auch durch hierarchische Anordnung von Subprozessen eine Gliederung vorgenommen wer den man bleibt aber in einem einheitlichen homogenen Modell Die oben abgedruckte Regel k nnte zum Beispiel so modelliert werden 240 Kapitel 11 Evaluierung anhand einer Fallstudie Auditing schreiben Auditing Antwort Abb 11 5 Prozessdiagramm f r eine Regel zur Ablaufsteuerung In den Subaktivit tszust nden werden die Prozesse eingebunden die bisher durch eine Pipeline siehe Abbildungen 11 2 und 11 3 realisiert wurden Durch dieses abgeschlos sene Konzept
218. en zu Konsistenzverletzungen f hren Eine Verbesserung des Verfahrens hinsichtlich dieser Problematik best nde darin nicht einen ganzen Teilstrang zur ckzusetzen sondern nur den einzelnen Service erneut aufzurufen bei dem die Ausf hrung versagt hat Das Problem der Seiteneffekte ist dann zwar kleiner aber noch nicht g nzlich gel st weil auch innerhalb der Service ausf hrung bis zu der Stelle an der der Fehler aufgetreten ist Nebeneffekte verursacht worden sein k nnen die nicht r ckg ngig zu machen sind Au erdem sind jetzt viel fter Sicherungskopien anzulegen was zu Lasten der Performanz geht Unter Ber cksichtigung der Tatsache dass nicht f r alle Services gleich hohe Erfolgsaussichten f r die Umgehung eines Fehlers durch dieses Verfahren gegeben sind erscheint es sehr zweifelhaft ob diese Methode vom Prozessinterpreter standard m ig bei allen Service Fehlern angewandt werden sollte Der Sinn der Methode h ngt vielmehr von den Fehlertypen der einzelnen Services ab je nach dem ob sie durch einen Wiederholungsversuch behoben werden k nnten oder nicht Da der Interpreter diese Informationen ber einen Service nicht kennt erscheint es uns am zweckm igs ten solche Ma nahmen zur Fehlertoleranz vom Interpreter auf die einzelnen Konnekto ren selbst zu verlagern Der Entwickler der die Interna des Service genau kennt kann einen Toleranzmechanismus mit Wiederholungsversuch in den Konnektor einbauen wenn ihm dies sinn
219. enden Agen ten in der Anwendungsschicht Als gemeinsamer Datenspeicher der verschiedenen Agenten dient eine Datenbank Aus den dort abgelegten Konfigurationsinformationen zu einem Workflow k nnen sich die Agenten der Anwendungsschicht selbst konfigurie ren bevor sie die Ausf hrung des Workflows und die Kommunikation mit den Soft warediensten bernehmen Neben der Datenbank existiert ein sogenannter Event Server Dabei handelt es sich um einen f r alle zug nglichen Punkt zur Kommunikation zwischen den verschiedenen Agenten Jeder Agent kann dort bei Bedarf Ereignisse und Nachrichten platzieren die dann von den zust ndigen anderen Agenten verarbeitet werden 4 2 2 Komponentenintegration mit WARP F r die Integration von Komponenten sind die Agenten der Konfigurationsschicht zu st ndig Die Site Manager Agenten SMA stellen Informationen ber die verf gbaren Dienste Services zur Verf gung Bei WARP erfolgt die Analyse der Services dabei nicht durch Untersuchung des Quellcodes sondern es werden Introspektionsmechanis men benutzt um an Informationen ber die Zugriffsm glichkeiten und Schnittstellen der Komponenten zu gelangen siehe Bla00 S 1 Die so gewonnenen Daten werden in der gemeinsamen Datenbank abgelegt F r die verf gbaren Services erzeugt der SMA anschlie end Instanzen des Role Manager Agenten RMA die die Funktionalit t der ihm zugeordneten Dienste in die Workflows einbringen kann Nachdem bekannt ist welche Dien
220. enge von Tasks Tasks wiederum bilden die Basisbauelemente f r Workflows Ein Task ist eine partiell oder vollst ndig geordnete Menge von Operationen Anweisungen f r von Menschen auszuf hrenden Aufgaben oder anderen Tasks Hierarchisierung Ein Task besteht auf unterster Hierarchieebene aus Aktivit ten die von Aufgabentr gern ausgef hrt werden Diese Definition erkl rt einen Workflow als hierarchisch strukturierte geordnete Menge von Aufgaben die letztlich auf unterster Ebene als Aktivit ten beschrieben werden die von einer Instanz ausgef hrt werden k nnen Als Aufgabentr ger k nnen sowohl Menschen als auch technische Systeme und Software in Frage kommen Leider wird in dieser Definition die Abgrenzung zur vorausgegangenen Definition eines Gesch fts prozesses nicht sehr deutlich Bei einem Workflow geht es um die Umsetzung und Aus f hrung eines Gesch ftsprozesses Im Rahmen dieser Arbeit liegt ein besonderer Fokus auf der computer und softwaregest tzten Automatisierung der Prozessdurchf hrung In diesem Kontext sei daher erg nzend die Workflow Definition aus dem Workflow Referenzmodell der Workflow Management Coalition WFMC zitiert die Workflows bewusst im Zusammenhang mit informationstechnischer Ausf hrung betrachtet In Wmc95 S 6 hei t es zur Definition des Workflow Begriffs Ihe computerized facilitation or automation of a business process in whole or part Als Workflow soll im Folgenden daher eine d
221. enn er weitere Infor mationen ber die Parameterbelegung hat Wie in der folgenden Abbildung 6 16 illus triert muss dabei aber immer gelten dass der Eingangsport x der Aktivit t Teilport des Eingangsports x des Service ist und der gebundene Ausgangsport y des Service immer Teilport des Ausgangsports y der Aktivit t ist Nur dann ist ein konsistenter Dokumentfluss von x nach y m glich Der Service definiert den bergang von x zu y bzw nach der Bindung des offenen Ports zu y Somit ergibt sich als g ltiger Doku mentfluss die Portkette x c x gt y c y InputPort OutputPort SR Be Statisches Modell gt Service s 7 Y a offener Port Es muss gelten gebunden x cx y E y Prozessdiagramm Abb 6 16 Einschr nkung von Service Ports aus dem statischen Modell Neben den einzelnen Zust nden muss auch f r den Prozess als Ganzes ein Eingangs und ein Ausgangsport gesetzt werden um zu spezifizieren welche Dokumenttypen von diesem Prozess verarbeitet und welche ausgegeben werden k nnen Dazu wird der Ein gangsport des Prozesses vom Modellierer bestimmt und als Dokumenttyp des eingehen den Dokuments auf den Startzustand des Prozesses bertragen Nach vollendeter Modellierung der Prozessaktivit ten auf diesem Dokumenttyp bestimmt der Ausgangs port des Endzustands den Dokumenttyp nach Durchlaufen des Prozesses Darum wird dieser Ausgangsport des Endzustands als Ausgangsport des ges
222. enschlichen Benutzern auch die Informationssysteme anderer Institutionen als m gliche Empf nger mit ihren speziellen Formaten und Protokollen in Betracht zu ziehen Die Frage ist also welche M glichkeiten es gibt die Forderung nach einem solchen Multi Channel Ansatz umzusetzen 5 Wie k nnen Entwickler und Systemingenieure des Unternehmens bei den Aufga ben der Softwareintegration unterst tzt werden Diese Frage ist zu betrachten weil mit wachsender Gr e und Anzahl der vorhandenen Systeme die zu l senden Inte grationsaufgaben schnell sehr komplex und schwierig beherrschbar werden k nnen Die vorliegende Diplomarbeit behandelt vorgenannte Fragestellungen und fokussiert dabei einen prozessorientierten Ansatz der sowohl die Anforderungen der Software integration als auch der Abbildung der Gesch ftsprozesse ber cksichtigt Das prozess orientierte Vorgehen bei der Integration der vorhandenen Softwarekomponenten erm glicht n mlich eine einfache Einbeziehung der im Unternehmen ablaufenden Vor g nge Untersucht werden soll wie sich im Rahmen eines Workflow Management Systems die existierenden Systemfunktionen als Aktivit ten der Workflow Modelle nutzen lassen Die Abwicklung der betrieblichen Gesch ftsprozesse w rde dadurch effizienter schneller kosteng nstiger und auch sicherer weil softwaregest tzte Kon sistenzpr fungen in die Vorgangsbearbeitung eingebaut werden k nnten Au erdem geht die Arbeit der Frage nach wie die Pr
223. ente Datenstruktur die durch ihre Analogie zum Metamodell f r einen Kenner des Metamodells leicht zu handhaben und in andere Werkzeuge zu integrieren ist Au erdem stellt die Anlehnung an das Metamodell sicher dass sich alle syntaktischen Elemente der Diagramme aber auch alle Einschr nkungen in der Implementierung des Metamodells wiederfinden und so eine fehler und verlustfreie Speicherung von Prozessdiagrammen in dieser Daten struktur m glich ist Die Dokumentation der Implementierung erfolgt anhand von UML Klassendiagrammen Diese Notation eignet sich als Grundlage f r die Implemen tierung des Metamodells auch in einer anderen objekt orientierten Sprache als Java Einschlie lich der notwendigen Werkzeuge siehe Abschnitte 7 5 und 8 4 umfasst die Umsetzung in Java etwa 10 000 LOC lines of code Wie schon erw hnt besteht das Metamodell f r Prozessdiagramme aus dem UML Metamodell f r Aktivit tendiagramme siehe Omg01 2 12 bzw Zustands diagramme siehe Omg01 2 13 und den in Abschnitt 7 3 daran vorgenommenen Erweiterungen und Einschr nkungen Die bereits aus Abschnitt 7 3 bekannte Abbil dung 7 6 gibt noch einmal einen berblick ber dieses den Prozessdiagrammen zu Grunde liegende Metamodell Der obere Teil der Abbildung ist ein Auszug aus dem UML Metamodell vgl Omg01 Abb 2 24 und 2 30 bei dem bereits einige Klassen ausgelassen wurden wenn sie f r die Darstellung von Prozessdiagrammen nicht relevant sind Dazu geh
224. entsprechende Konzepte im Prozessinterpreter umzusetzen Ein Prozessdiagramm l sst sich also zwar als transaktional festlegen dies hat aber keine Auswirkung auf die Ausf hrung mit Hilfe des von uns entwickelten Interpreters In den folgenden Abschnitten sollen jedoch Vorschl ge gemacht werden wie sich dies prinzipiell integrieren lie e Vergleiche dazu auch Abschnitt 2 2 2 ber transaktionale Workflows 10 4 1 Eigenschaften von Transaktionen Eine Transaktion ist laut Bac98 S 483 eine Folge von Operationen auf einer Menge von Daten mit den sogenannten ACID Eigenschaften Atomicity Entweder werden alle Operationen einer Transaktion ausgef hrt oder gar keine d h die Transaktion wird entweder ganz oder gar nicht abgearbeitet nicht jedoch teilweise Falls w hrend der Ausf hrung ein Fehler oder Systemausfall auftritt m ssen alle bis dahin vorgenommenen nderungen an den Daten r ckg ngig gemacht werden Consistency Jede Transaktion berf hrt das System aus einem konsistenten Zustand wiederum einen konsistenten Zustand d h eine Transaktion darf die Daten nicht in einem ung ltigen Zustand hinterlassen Isolation Alle nderungen die die Operationen der Transaktion vornehmen d rfen erst dann f r den Rest des Systems sichtbar werden wenn die Transaktion korrekt bis zum Ende gef hrt und best tigt wurde siehe unten Durability Wenn eine Transaktion korrekt beendet wurde muss sichergestellt werden dass alle ihre nd
225. entwickelten Konzepte zur L sung der Probleme und Erf l lung der Anforderungen ausgearbeitet und vorgestellt Um die im ersten Teil festge stellten L cken bei den vorhandenen Ans tzen zu schlie en wird eine Erweiterung f r UMIL Aktivit tendiagramme definiert Diese sogenannten Prozessdiagramme erlauben die visuelle Modellierung ausf hrbarer Workflow Modelle Da den Workflows eine implizite Verarbeitung von XML Dokumenten zu Grunde liegt werden Typkonzepte f r XML Dokumente entwickelt Diese dienen als Grundlage f r typisierte Schnitt stellen zu den verwendeten Softwarekomponenten und typisierte Transitionen als berg nge zwischen den einzelnen Aktivit ten Dadurch l sst sich ein sehr hohes Ma an Wiederverwendbarkeit und Typkonsistenz f r den gesamten Workflow sicherstellen Der dritte Teil schlie lich enth lt in den Kapiteln 9 bis 11 eine Beschreibung der praktischen Umsetzung der zuvor eingef hrten L sungsans tze Ein im Rahmen der Diplomarbeit entwickelter Editor hilft bei der Erstellung und Konsistenzpr fung der Modelle ein Prozessinterpreter kann die Modelle ausf hren Durch die Implementie rung dieser Werkzeuge und ihre Einbettung in die vorhandene E Business Plattform wird die praktische Anwendbarkeit der erarbeiteten Konzepte verdeutlicht 2 1 Prozessorientierte Integration im E Business 9 2 Grundlagen des Workflow Managements Zu Beginn der Arbeit gehen wir in diesem Kapitel nach einer Einf hrung in die Inte
226. er Farben Die Zahlen geben dabei an in welcher Reihenfolge die Zust nde von der Tiefensuche besucht wurden Momentan wird Knoten 9 berpr ft Sowohl die Transition zum Zustand 7 als auch zum wei en Zustand stellt kein Problem dar Die Transition zum Zustand 4 f hrt jedoch zu einem Zustand der nicht die gleiche Farbe besitzt und somit nicht zum gleichen parallelen Abschnitt geh rt so dass diese Konstruktion nicht wohlgeformt ist i 2 6 gt 0 Abb 7 12 Verwendung von Farben im Validierungsalgorithmus In Abbildung 7 13 ist der Validierungsalgorithmus in Ausz gen abgebildet Dabei sind alle Anweisungen f r Pr fungen von Ports Anzahl der Transitionen usw nicht darge stellt da sie zum Teil sehr technisch sind und nicht zum allgemeinen Verst ndnis des Algorithmus beitragen Stattdessen soll der Ablauf der Tiefensuche und das Verfahren des F rbens von Zust nden verdeutlicht werden Es handelt sich um einen rekursiven Algorithmus in dem der Begriff Section verwendet wird Darunter verstehen wir einen Prozessabschnitt der aus einem Zustand und einem Rest Abschnitt besteht Ein gesamtes Prozessdiagramm besteht demzufolge aus dem Startzustand und einem Rest welcher alle brigen Zust nde umfasst validateProcess process 1 states process getAllStates 2 for i 1 to states length do Alle Zust nde wei f rben 3 state states i 4 color state WHITE 5 end for 6 colorOfSection det
227. er L sung l ge in der einfachen Integration vorlie gender PML Prozessbeschreibungen Man m sste sie lediglich parsen und k nnte dann 192 Kapitel 9 Modellierungswerkzeug f r Prozessdiagramme direkt auf den Daten arbeiten Analog w re es sehr einfach PML Dokumente zu erzeu gen Man br uchte nur die interne Struktur zu serialisieren und als XML Dokument abzuspeichern Trotzdem haben wir uns gegen diese L sung entschieden weil die hierarchische Struktur der PML Dokumente nicht f r eine effiziente Verarbeitung innerhalb der Prozessmodellierung geeignet ist Man m sste st ndige Suchanfragen an und Traversierungen ber den PML Baum durchf hren was die Implementierung erschwert und zudem h here Laufzeiten erzwingt Au erdem sind vorhandene Imple mentierungen f r das DOM bislang noch sehr speicherineffizient Aus diesen Gr nden wird stattdessen die im Abschnitt 7 4 vorgeschlagene Implementierung des erweiterten UML Metamodells f r Prozessdiagramme verwendet Sie ist f r die Zwecke des Editor effizienter als die direkte XML Verarbeitung da alle Beziehungen zwischen den Elementen eines Prozesses direkt durch Assoziationen zwischen den Datenklassen realisiert sind Da somit f r die interne Datenstruktur keine PML Dokumente zu Grunde gelegt werden ergibt sich jedoch die Notwendigkeit f r Konvertierungswerkzeuge zwischen PML Dokumenten und dem internen Datenmodell F r diese Aufgaben wurden im Abschnitt 8 4 die beiden Werkzeuge PML Impo
228. er angegebenen Randbedingung 6 16 gen gen Die hiermit abgeschlossenen Betrachtungen zur formalen Definition von Ports haben f r alle syntaktischen Elemente zur Notation von Ports vgl Abschnitt 6 3 1 eine passende Semantik definiert und diese in Bezug zum Konzept der Dokumentmigration vgl Abschnitt 6 1 1 und der typisierten Transitionen vgl Abschnitt 6 3 2 gesetzt Dadurch ist ein formales Gesamtkonzept f r die Modellierung der Dokumenttypen 6 4 Bewertung 119 durch Ports und offene Ports die Bindung offener Ports sowie den Einsatz typisierter Transitionen entstanden das als Grundlage f r die Implementierung des Typkonzepts im Metamodell vgl Abschnitt 7 4 im Modellierungswerkzeug vgl Kapitel 9 und im Prozessinterpreter vgl Kapitel 10 benutzt wird 6 4 Bewertung Nachdem in den vorherigen Abschnitten das Konzept der XML Prozesse vorgestellt und ihre Modellierung mit Hilfe von Prozessdiagrammen beschrieben wurde soll an dieser Stelle eine Evaluierung stattfinden Dabei soll berpr ft werden inwieweit durch diesen Ansatz die im Abschnitt 3 4 vorgenommene Zielsetzung erf llt wird Im Hin blick auf den Einsatzbereich E Business waren die beiden wichtigsten Anforderungen an ein Workflow Management System die Integration heterogener Back End Systeme und die XML Unterst tzung bez glich der Workflow relevanten Daten Anforderung Prozessdiagramme Visuelle Sprache Allgemein akzeptiert Leicht Intuitiv ve
229. er verlangt F r jeden Parameter ist im Prozessdiagramm entweder ein stati scher Wert oder ein XPath Ausdruck angegeben der sich auf das Migrationsdokument oder die Prozessumgebung bezieht vgl Abschnitte 6 2 2 Jedes Argument wird aus gewertet und sein Ergebnis beim Aufruf an den Service bergeben Nachdem der Service terminiert ist wird berpr ft ob das Dokument bez glich des Ausgangsports des Zustands g ltig ist Wenn dies nicht der Fall ist muss davon ausgegangen werden dass sich die Komponente nicht wie erwartet verhalten hat In dieser Fehlersituationen ist die Konsistenz des Prozessdiagramms nicht gewahrt und seine Ausf hrung muss abgebrochen werden Stereotyp typedTransition In Prozessdiagrammen bedeutet jede Transition neben dem Kontrollfluss auch einen Datenfluss d h das Migrationsdokument wird an den oder die Folgezust nde weiterge reicht Besitzt eine Transition einen Guard so bezieht sich dieser entweder auf das Migrationsdokument oder die Prozessumgebung vgl Abschnitt 6 2 4 Bei der Ausf h rung des Prozesses muss der Guard jeder Transition ausgewertet werden Nur wenn er wahr ist kann die zugeh rige Transition schalten Weiterhin kann mit einer Transition eine Transformation des Migrationsdokuments verkn pft sein Bei der Ausf hrung muss daf r gesorgt werden dass diese durchgef hrt wird bevor das Dokument an den Zielzustand der Transition bergeben wird Die auszuf hrende Transformation bestimmt dab
230. erden muss wird das kartesische Produkt gebildet siehe auch Abbildung 6 18 Es ist bisher nicht gelungen dieses Constraint in OCL auszudr cken Eine Implementierung in Java liegt vor kann aber nicht auf OCL bertragen werden da OCL nicht die Bildung geschach telter Mengen erlaubt siehe Omg01 6 5 13 Die Bildung des kartesischen Produkts als OCL Ausdruck ist hier schwierig weil die Anzahl der in das Produkt einflie enden Mengen Ports beliebig gro sein kann Exemplarisch wird daher im folgenden Constraint davon ausgegangen dass nur ber genau zwei eingehende Transitionen vorgelagerte Ports vorhanden sind predecessors gt forAll pl p2 not pl p2 implies pl types gt forAll tl p2 types gt forAll t2 outputPort types gt exists doctype doctype root elemName join and doctype subs gt includes tl root and doctype subs gt includes t2 root and doctype subs gt includesAll tl subs and doctype subs gt includesAll t2 subs 8 Ein SubactivityState hat den gleichen Eingangsport wie der Startzustand des eingebetteten Prozesses if state oclIsTypeOf SubactivityState then let embeddedInitial PseudoState state oclAsType SubactivityState subvertex gt select s s oclIsKindOf PseudoState and s oclAsType PseudoState kind initial inputPort embeddedInitial stereotype oclAsType stateWithPorts inputPort endif 138 Kapitel 7 Metamodell f r Prozessdiagramme 9 Ein SubactivityState hat d
231. eren sollten verschiedene Ausgabeformate unterst tzt werden sunShine erf llt diese Forderung indem bei einer Anfrage an den Webserver ermittelt wird mit welchem Endger t die Anfrage gestellt wurde Abh ngig davon k nnen die 44 Kapitel 4 Evaluierung vorhandener Workflow Systeme Daten als HTML ausgegeben werden wenn es sich um einem Browser handelte als WML falls die Anfrage von einem WAP Handy kam o Schlie lich ist es notwendig dass sich jeder Benutzer mit einem pers nlichen Zugang am Portal anmeldet Er hat dann die M glichkeit das Aussehen oder die Informationsangebote in bestimmten Grenzen seinen Bed rfnissen entsprechend anzupassen Diese Konfigurationen werden persistent gespeichert so dass bei jeder Anmeldung sofort die individuelle Sicht vorhanden ist 4 3 1 Systemarchitektur von sunShine sunShine stellt eine Erweiterung des Open Source Projekts Cocoon der Apache Organi sation dar Ausgangspunkt dieses Projekts war die Beobachtung dass bei der Realisie rung von Web Anwendungen der Inhalt von Dokumenten ihr Layout sowie die n tige Gesch ftslogik meistens von unterschiedlichen Personengruppen entwickelt werden siehe Apa01 und LauO00 Bestehende Technologien wie HTML vermischen jedoch h ufig diese drei Aspekte indem beispielsweise Anweisungen die zur Darstellung eines Dokuments dienen direkt im Inhalt notiert werden siehe HTML99 Dies f hrt zu Problemen sowohl bei der Lesbarkeit und Wartbarkeit als auc
232. ererbung Fallunterscheidungen und Kardinalit ten die f r XML Schemata zur Verf gung stehen umgesetzt Dadurch kann von vornherein ausgeschlos sen werden dass eine PML Beschreibung bestimmte Fehler im Modell enth lt oder zumindest w rden diese bereits von einem XML Parser beim Einlesen eines PML Dokuments erkannt Die folgenden Beschreibungen gehen jeweils von den aus Abschnitt 7 3 bekannten UML Stereotypen aus und geben die zugeh rige Umsetzung nach PML in Form eines XML Schema Fragments an Das vollst ndige PML Schema ist auf der CD ROM zu dieser Diplomarbeit zu finden Damit die Erl uterungen m glichst anschaulich und leicht nachvollziehbar werden ist zu jedem Stereotypen ein beispiel hafter PML Abschnitt angegeben Zun chst soll betrachtet werden wie die von uns eingef hrten Ports in PML beschrieben werden Es handelt sich dabei um ein wichtiges Konzept von Prozessdiagrammen das in mehreren Stereotypen zum Einsatz kommt Anschlie end wird die PML Beschreibung des statischen Modells und schlie lich von Prozessen selbst vorgestellt 8 3 1 Beschreibung von Ports Datentyp XmlElement Der Grundbaustein f r die Beschreibung eines Ports sind XML Elemente die durch den UML Datentyp XmlElement repr sentiert werden sollen Dieser besitzt die beiden Attribute elemName und namespace die den Namen und den Namensraum des Elements angeben Daraus leitet sich folgender Typ im XML Schema f r PML ab dataType Xmi
233. eres XLANG Dokument eingebet tet nicht jedoch auf ein anderes XLANG Dokument verwiesen werden Abbildung 8 1 zeigt als Beispiel einen Ausschnitt des Prozesses aus Abschnitt 6 2 wie er als XLANG Beschreibung aussehen k nnte lt switch gt lt branch gt lt case gt transaktion type ueberweisung lt case gt lt sequence gt lt all gt lt sequence gt lt switch gt lt branch gt lt case gt transaktion auftraggeber name transaktion empfaenger name and not transaktion empfaenger bankleitzahl 47262703 lt case gt 166 Kapitel 8 Beschreibung von Prozessen in XML lt sequence gt lt action operation SQLQuery gt lt action operation SendMail gt lt sequence gt lt branch gt lt switch gt lt sequence gt lt sequence gt lt sequence gt lt all gt lt action operation XSLTTransformer gt lt sequence gt lt branch gt fee kei Abb 8 1 XLANG Beschreibung eines Beispielprozesses Es gibt eine Reihe weiterer XML Sprachen f r die maschinelle Ausf hrung von Workflows wie beispielsweise die Business Process Modeling Language BPML siehe Ark01 die von der Business Process Management Initiative BPMI entwickelt wurde Die BPMI ist eine Organisation mehrerer IT Unternehmen die sich zum Ziel gesetzt hat Workflow Management Technologien zu standardisieren BPML und ande ren Sprachen liegen hnliche Ans tze wie XLANG zu Grunde Aus diesem Grund soll an dieser St
234. erfassen Schufa An frage stellen lehnt ab Konditionen bestimmen gt 30000DM Filialleiter beurteilt QO a lt 30000DM akzeptiert Schufa positiv Kredit Kredit ablehnen gew hren Abb 5 3 Beispiel eines Petri Netzes 5 1 4 Eignung f r Prozessdiagramme Im Abschnitt 3 3 wurden Anforderungen an die Workflow Modellierungssprachen im Anwendungsgebiet der Integration von Softwarekomponenten mit Hilfe von XML Technologie formuliert die von einer geeigneten Sprache erf llt werden m ssen Daher soll nun der Reihe nach untersucht werden inwieweit die Theorie der Petri Netze die einzelnen Forderungen erf llt und damit f r die Modellierung verwendet werden kann Als visuelle Sprache zur Beschreibung von Prozessabl ufen kommen Petri Netze grunds tzlich in Frage Sie erlauben eine anschauliche und leicht zu verstehende Darstellung Im Zusammenhang mit Gesch ftsabl ufen treten vier verschiedene Basis konstrukte bez glich des Kontrollflusses auf sequentielle Abarbeitung von Aktionen bedingte Verzweigung des Prozesses iterative Ausf hrung von Aktionsfolgen sowie 56 Kapitel 5 Evaluierung vorhandener Workflow Modellierungssprachen parallele Verarbeitungsstr nge Alle vier M glichkeiten k nnen in Petri Netzen pro blemlos ausgedr ckt werden Nach Aal97 existieren dazu die Grundbausteine die in der folgenden Abbildung dargestellt sind sequentiell gt gt par
235. ermine color WHITE 7 validateSection process getInitialState color colorOfSection validateSection state color colorOfSection lt 8 c color state 9 if c WHITE then 10 color state colorOfSection 11 f hre zustandsabh ngige Pr fungen durch 1 2 156 Kapitel 7 Metamodell f r Prozessdiagramme 13 validateSuccessorStates state color colorOfSection 14 else if c colorOfSection 1 5 korrekte Schachtelung Knoten wurde bereits validiert 16 else ung ltige Schachtelung 17 createErrorMessage 18 end if validateSuccessorStates state color colorOfSection 19 if state is ForkState 20 states state getAllSuccessors validiere parallele Str nge 21 for i 1 to states length do 22 c determine new unique color 23 validateSection states i color c 24 end for 25 else if state is SynchState 26 BAT NEE 28 else Knoten mit genau einer Ausgangstransition 29 validateSection state getSuccessor color colorOfSection 30 end if Abb 7 13 Validierungsalgorithmus 7 6 Automatische Portberechnung Bei der Modellierung von Prozessdiagrammen ist eine umfangreiche Menge von Ports zu spezifizieren um damit die Dokumentstrukturen der Workflows vollst ndig zu modellieren Jeder Service und jeder Transitionstyp im statischen Modell muss mit einem Ein und einem Ausgangsport versehen werden Genauso bedarf im dynamischen Modell jedes Prozessdiagram
236. erungen auch im Falle eines Systemausfalls dauerhaft im Daten bestand gespeichert werden Um die Einhaltung dieser Eigenschaften sicherstellen zu k nnen existieren in Trans aktionssystemen h ufig zwei Operationen zur Verwaltung der Transaktionen vgl Bac98 S 438 Mit Commit wird eine Transaktion best tigt d h sie konnte ohne Feh ler und Konsistenzverletzungen bis zum Ende ausgef hrt werden mit Abort l sst sich eine Transaktion abbrechen falls Fehler oder Konsistenzverletzungen aufgetreten sind Jede Transaktion muss entweder mit Commit oder Abort beendet werden Dabei kann ein Abort entweder von der Transaktion selbst ausgel st werden falls ein Fehler auf tritt oder vom Transaktionssystem falls sonst die oben genannten ACID Eigenschaften nicht eingehalten werden k nnten Es m ssen dann alle Ver nderungen die die Trans aktion bis dahin an den Daten vorgenommen hat r ckg ngig gemacht werden 10 4 Transaktionale Prozessausf hrung 229 10 4 2 Transaktionen in XML Prozessen Im Zusammenhang mit XML Prozessen liegen sogenannte verteilte Transaktionen vor Dabei existiert nicht ein einzelner Datenbestand sondern die Daten auf denen die Operationen arbeiten k nnen sich auf verschiedenen Systemen befinden Im Laufe einer Transaktion k nnen dann Zugriffe auf Daten mehrerer Systeme stattfinden Eine M glichkeit zur Realisierung verteilter Transaktionen besteht in der Existenz eines zentralen Transaktionsverwalters wie dies b
237. es Agen tensystem vorgestellt Bevor die Prozesse von den Agenten ausgef hrt werden k nnen m ssen zwei Schritte vorausgehen Zun chst m ssen die verf gbaren Komponenten bzw Dienste analysiert werden Nachdem bekannt ist welche Dienste zur Verf gung stehen muss ein Workflow Designer eine Spezifikation des Prozesses als objektorientiertes UML Modell aufstellen Dies Kann dann den Agenten bergeben und von ihnen ausgef hrt werden 4 2 1 Systemarchitektur von WARP Die Architektur des Systems besteht aus zwei Schichten der Schicht zur Konfiguration des Systems und Spezifikation neuer Prozesse Automated Configuration Layer sowie die Schicht zur Ausf hrung der Workflows und zur Steuerung der vorhandenen Dienste 4 2 Komponentenkonfiguration mit WARP 41 Application Coordination Layer Die folgende Abbildung zeigt die WARP Architektur im berblick Automated Configuration Layer Application Coordination Layer I Global Workflow nstanzien gt Manager Agent GWMA Workflow Manager Agent WMA Event N Role Manager Role M Agent RMA Site Manager nstanziiert gt ole Manager Agent SMA i Agent RMA Role E l E RMA Verf gbare Dienste Introspektion Abb 4 2 WARP Architektur aus Bla00 Die in der Konfigurationsschicht t tigen Agenten interpretieren neue oder ge nderte Prozessspezifikationen und erzeugen dazu passende Instanzen der ausf hr
238. es Workflow Modells d h Softwarekomponenten und Sub Workflows sollen durch ein statisches Modell repr sentiert werden vgl dazu Abschnitt 2 3 1 Eine Modellierungssprache sollte geeignete Konstrukte zur grafischen Darstellung eines solchen Modells besitzen Bei der Ausf hrung von systemorientierten Workflows muss h ufig die Konsis tenz der beteiligten Daten sichergestellt werden siehe B h95 S 14 Die Model lierungssprache sollte daher ein Konstrukt enthalten mit dem sich Anfang und Abschluss von Transaktionen definieren lassen Eine Transaktion ist dabei als Teil eines Workflows anzusehen der atomar abl uft also entweder ganz von Anfang bis Ende oder gar nicht vgl Abschnitt 2 2 2 3 4 Zielsetzungen dieser Arbeit 33 9 Mit einem Zeitmodell wie es in Geo95 S 135 und B h95 S 8 f r die Modellierungssprachen gefordert wird k nnen Angaben ber die Dauer von Aktivit ten sowie ihre Start und Endzeitpunkte gemacht werden Durch diese Spezifikation kann ein WFMS die Terminvorgaben berwachen und bei deren Verletzung entsprechende Warnungen ausgeben oder Gegenma nahmen ergrei fen 3 4 Zielsetzungen dieser Arbeit Nachdem in den vorausgegangenen Abschnitten auf die Anforderungen an Workflow Management und insbesondere die Modellierung von Workflows eingegangen wurde wollen wir hier die Zielsetzungen der Arbeit verdeutlichen und dabei eine Gewichtung der Anforderungen vornehmen Das Hauptziel ist die Konzeption ein
239. es Workflows simulieren um logische Fehler zu finden und die erwartete Ausf hrungsdauer abzusch tzen bliche Testverfahren aus der Software Entwicklung k nnen auf Workflow Modelle bertragen werden Entweder gibt es eine formale Spezifikation zu einem Workflow oder man testet gegen das vom Modellierer intendierte Verhalten Verschiedene Testf lle sollen m glichst alle Pfade des Workflows mindestens einmal abdecken Auch Ausnahmezust nde und Sonderf lle sollen dabei untersucht und bewusst erzwungen werden um das Verhalten des WFMS in diesen Situationen zu simulieren 2 4 Unterst tzung durch Software 19 Bei der Analyse von Workflow Modellen ist das Ziel m gliche Engp sse bei der Ausf hrung aufzudecken Neben der Untersuchung der Modell Spezifikation k n nen Statistiken ber bisherige Ausf hrungen und Simulationen herangezogen werden Diese Statistiken enthalten zum Beispiel Angaben ber die Ausf hrungsdauer oder den Durchsatz an Daten durch eine bestimmte Aktivit t des Workflows Als Ergebnis der Analyse k nnen Verbesserungsvorschl ge gemacht werden an welchen Stellen das Workflow Modell optimiert werden k nnte Nach Simulation und positiver Analyse eines Modells kann es vom WFMS ausgef hrt werden Bei der Ausf hrung muss das Fortschreiten des Prozesses berwacht werden Dadurch k nnen tempor r entstehende Engp sse entdeckt und durch ent sprechende Gegenma nahmen aufgel st werden W hrend der berwachung werden daz
240. es durchg ngigen Verfahrens zum Mana gement von Workflows von der Modellierung bis zur Ausf hrung Neben den Konzep ten soll ebenso die Umsetzung in entsprechende Software und Werkzeuge durchgef hrt werden Da es sich beim Workflow Management um ein beraus weitl ufiges For schungsgebiet handelt wollen wir uns in dieser Arbeit auf die Anforderungen konzen trieren die sich im Zusammenhang mit E Business Plattformen ergeben Das resultie rende WFMS ist daher besonders f r den Einsatz im E Business und das Management der dort anfallenden Workflows konzipiert Bei diesen Workflows liegt der Schwer punkt sehr stark auf rein systemorientierten Prozessen zur Verarbeitung von Daten und Informationen Es geht nicht um die Koordinierung der menschlichen Zusammenarbeit in einem Unternehmen die durch eine Vorgangssteuerung wie man sie bei der soge nannten Groupware findet unterst tzt werden soll Aus diesem Grund k nnen wir die Problematik der Benutzerinteraktion bei unseren Betrachtungen weitgehend ausklam mern Das Resultat sollen Workflows sein die vollst ndig automatisiert ablaufen und die auf der E Business Plattform aufgerufenen Funktionen zum Beispiel von einem Kunden aus einem Web Portal heraus abarbeiten k nnen Daher ist eine Anbindung des WFMS an ein Portal vorzusehen Die Aufgabentr ger der einzelnen Aktivit ten sind also nicht Mitarbeiter eines Betriebes sondern Software Einheiten und existierende Back End Systeme Diese
241. ess Abb 10 7 Schachtelung von Prozessabschnitten zur Laufzeit Abbildung 10 8 zeigt ein grobes Aktivit tendiagramm des Algorithmus in der Methode run aus der Klasse ProcessSection in dem aus Platzgr nden nicht alle Feinheiten aufgef hrt sind Es zeigt die Abl ufe innerhalb der Methode die zur Ausf hrung eines Prozessabschnitts bzw eines gesamten Prozesses dienen vgl Abschnitt 10 1 Setze currentState lt Anfangszustand des Prozessabschnitts gt Setze currentState lt Folgezustand des currentState gt currentState ist Anfangszustand des Abschnitts Wende Stylesheet der eingehenden Transition auf Dokument an Validiere Dokument gegen Eingangsport des currentState F hre Aktionen des currentState aus Validiere Dokument gegen Ausgangsport des currentState O else currentState ist Final oder JoinState Sende Dokument an bergeordneten Prozessabschnitt Abb 10 8 Ausf hrung eines Prozessabschnitts 222 Kapitel 10 Ausf hrung von XML Prozessen Um das Migrationsdokument gegen einen Port zu validieren generiert der Interpreter einen XPath Ausdruck Dieser berpr ft ob das Wurzelelement des Dokuments zu mindestens einem Dokumenttypen des Ports konform ist vgl Abschnitt 6 3 Ist dies der Fall ist das Dokument typkonsistent andernfalls ist ein Fehler aufgetreten und die Ausf hrung des Prozesses wird abge
242. essen grunds tz lich in Frage Sie ist zudem f r einen menschlichen Leser recht gut verst ndlich und kann aufgrund ihrer Verwendung in Microsoft BizTalk als bekannte Sprache angesehen werden XLANG ist jedoch sehr stark auf die Beschreibung von Webservices und insbesondere die Interaktion per Nachrichtenaustausch fokussiert Beide Aspekte sind im Zusammenhang mit XML Prozessen nicht unmittelbar von Bedeutung Dadurch erg be sich bei der Repr sentation von Prozessdiagrammen in XLANG ein Overhead da die XLANG Beschreibung viele nicht erforderliche Elemente enthalten w rde Weiterhin erfolgt die Spezifizierung der Workflow Abl ufe nicht graphbasiert dies wurde jedoch im Abschnitt 8 1 ausdr cklich gefordert Insgesamt gesehen ist XLANG daher f r die Beschreibung von XML Prozessen nicht optimal geeignet Dagegen erf llt die UML DTD der XMI Spezifikation alle Muss Bestimmungen des Anforderungskataloges Weil jedoch f r die Definition von Prozessdiagrammen ein ganz kleiner Teilbereich des gesamten UML Metamodells ausreicht und die Benutzung der langen und daher unleserlichen Elementnamen sowie das Abspeichern vieler UML Details vermieden werden soll werden wir trotz der sonst positiv bewerteten Eigen schaften von XMI im folgenden Abschnitt mit PML ein eigenes angepasstes XML Format definieren Da XMI und die darin enthaltene UML DTD aber ein allgemein anerkannter zunehmend wichtiger Industriestandard ist und inzwischen von vielen CASE Tools al
243. essketten 61 ersichtlich sein Die folgende Abbildung zeigt ein Beispiel einer EPK Kreditantrag gestellt I I I Kundendaten erfassen i Daten erfasst I i Basisinfo Sachbearbeiter akte Kredit Abteilung Filial Beurteilung ce lt akzeptiert gt lt abgelehnt gt T T I Sachbearbeiter Antrag erledigt Abb 5 6 Beispiel f r eine Ereignisgesteuerte Prozesskette 5 2 2 Formale Beschreibung der Syntax Als Schwachpunkt des EPK Modells in der originalen Fassung siehe Kel92 wird h ufig die fehlende oder unvollst ndige formale Definition von Syntax und Semantik 62 Kapitel 5 Evaluierung vorhandener Workflow Modellierungssprachen angegeben In Rit00 zum Beispiel hei t es dazu Den Vorteilen stehen auch signi fikante Nachteile gegen ber vor allem die Mehrdeutigkeit und Ungenauigkeit der Methode S 2 Da sich die EPK im Paket mit der betriebswirtschaftlichen Standard software SAP R 3 aber sehr stark verbreitet hat und quasi zu einem Standard in der industriellen Praxis geworden ist wurde in zahlreichen Arbeiten versucht das Modell nachtr glich durch formale Definitionen zu beschreiben Solche Ans tze finden sich zum Beispiel in den Ver ffentlichungen von P Rittgen Rit99 Rit00 der sich dort mit der Problematik der Semantik von Prozessketten auseinandersetzt In Kel99 S 166ff wird zumindest f r die Syntax der EPK eine formale Beschreibung g
244. etaillierte Beschreibung von Prozessen den darin enthaltenen Aktivit ten sowie den Ablaufbeziehungen der Aktivit ten unter einander verstanden werden Der Begriff Workflow wird dabei h ufig als Bezeichnung sowohl f r die Beschreibung des Vorgangs als auch f r den Vorgang selbst benutzt Ist eine explizite Unterscheidung n tig kann man von Workflow Modell auf der einen Seite und Workflow Instanz auf der anderen Seite sprechen Wenn wie in der Definition der Workflow Management Coalition gefordert ein Workflow durch Informationssysteme unterst tzt werden soll indem zum Beispiel die Abfolge der einzelnen Arbeitsschritte gesteuert und berwacht sowie entsprechende Aufgabentr ger f r die Aktivit ten zugewiesen werden ben tigt man ein Workflow Management System WFMS Ein solches System wird im Referenzmodell siehe Wmc95 S 6 definiert als A system that completely defines manages and executes workflows through the execution of software whose order of execution is driven by a computer representation of the workflow logic Im sp ter folgenden Abschnitt ber die Unterst tzung durch Software Werkzeuge wer den wir auf die Anforderungen und Eigenschaften eines solchen Systems noch n her eingehen 14 Kapitel 2 Grundlagen des Workflow Managements 2 2 2 Klassifizierung von Informationsprozessen Je nach dem wie gut sich Informationsprozesse durch Rechner unterst tzen lassen wie hoch der Grad ihrer Wiederholbarkeit
245. ete XML Werkzeuge ver wenden um zu einem Prozess der ausgef hrt werden soll die PML Beschreibung ein zulesen Er h tte anschlie end beispielsweise einen DOM Baum vorliegen und k nnte direkt anhand dieser Datenstruktur den Prozess schrittweise abarbeiten und die notwen digen Daten aus dem DOM auslesen Da jedoch der Zugriff auf XML Daten insbeson dere mit Hilfe von XPath Operationen vergleichsweise viel Rechenzeit in Anspruch nimmt und zudem ein DOM Baum hohen Speicherbedarf besitzt ist diese Variante zu ineffizient Wir haben uns daher entschieden die PML Dateien zun chst mit Hilfe eines Parsers einzulesen und anschlie end in das implementierte Metamodell f r Prozess diagramme vgl Abschnitt 7 4 zu berf hren Diese Objektstruktur erlaubt effizientere Zugriffe auf die Prozessmodelle und kann zum Beispiel die Nachfolgezust nde eines Zustands durch direktes Auswerten des zugeh rigen Objektattributs bestimmen Auch f r das Modellierungswerkzeug wurde schon diese Datenstruktur verwendet vgl Ka pitel 9 Der Vorteil dieses Vorgehens kommt besonders dann zum Tragen wenn der Interpreter nicht bei jeder Prozessausf hrung die PML Beschreibung einliest und trans formiert sondern einen Pufferungs Mechanismus Caching vgl Abschnitt 12 2 ver wendet der die internen Prozessbeschreibungen im Speicher h lt so dass sie bei der Abarbeitung anderer Prozessinstanzen wiederverwendet werden k nnen Die Rechen zeit f r die Umwandlung des
246. ets John Wiley amp Sons Ltd 1995 Sinan Si Alhir UML in a Nutshell O Reilly September 1998 Sinan Si Alhir Extending the Unified Modeling Language UML Januar 1999 http home earthlink net salhir ExtendingTheUML PDF Apache Software Foundation Cocoon User Documentation http xml apache org cocoon userdocs index html Assaf Arkin Business Process Modeling Language BPML Business Process Management Initiative M rz 2001 http www bpmi org bpml spec esp Jean Bacon Concurrent Systems Addison Wesley Longman Ltd 1998 Deutsche Bausparkasse Badenia AG Interner Anforderungskatalog f r ein E Business Projekt des Unternehmens sowie diverse Quellcodes einer Realisierung Bernd Baumgarten Petri Netze Grundlagen und Anwendungen Spektrum Akademischer Verlag 1996 Urban Bettag Web Services Informatik Spektrum Band 24 Heft 5 Oktober 2001 Springer Verlag Berlin 256 Literatur und Quellen Bla00 Biz01 Bo099 B h95 CowOl CZ01 Day91 Dep00 DOMO1 M Brian Blake WARP An Agent Based Process and Architecture for Workflow Oriented Distributed Component Configuration Proceedings of the 2000 International Conference on Artificial Intelligence IC AI2000 Las Vegas Juni 2000 http mason gmu edu mblake icai2000 pdf BizTalk org BizTalk Framework Web Site http www biztalk org home framework asp Grady Booch Jim Rumbaugh Ivar Jacobson Das UML Benutzerhandbu
247. externen Quelle abgerufen hat Es ist ihm prinzipiell m glich das XML Dokument in beliebiger Weise zu transformieren Abbildung 4 6 zeigt das allgemeine Modell eines Trans formers 4 3 E Business Plattform sunShine 47 XML Eingabe XML Ausgabe dokument Transformer i dokument sa Externe Aktionen Externe Datenquellen Nachrichten usw Abb 4 6 Modell eines Transformers sunShine bietet eine Reihe von vorgefertigten Transformern an die als Grundbausteine f r die Festlegung eigener Pipelines verwendet werden k nnen Dabei handelt es sich um Komponenten zum Senden und Empfangen von E Mails zum Einbinden von Daten anderer Server oder Datenbanken insbesondere zur Anwendung von XSL Stylesheets auf die XML Daten usw Es ist aber auch m glich bei der Entwicklung von Web Anwendungen eigene Transformer Komponenten zu entwickeln die dann in sunShine integriert werden Durch die einheitliche SAX Schnittstelle aller Transformer ist es m glich sie sequentiell hintereinander zu schalten Sogenannte Selektoren erlauben auch einfache Verzweigungen innerhalb solcher Pipeline Prozesse anhand bestimmter Bedingungen wie beispielsweise der Art des anfragenden Endger ts oder der aktuellen Uhrzeit Durch das Konzept der Pipelines lassen sich also mit sunShine bereits ansatz weise Workflows realisieren Ein flexibles Workflow Modell sowie die Unterst tzung von Transaktionen sind bislang jedoch nicht vorhanden 48 K
248. f hrung von Prozessdiagrammen zugeschnitten ist Neben dem Fehlen von Ereignissen sind in Prozessdiagrammen folgende Konstrukte von Aktivit tendiagram men nicht erforderlich vgl Abschnitt 6 2 6 l Prozessdiagramme erlauben neben Pseudozust nden ausschlie lich Aktions und Subaktivit tszust nde Daher ergeben sich die folgenden beiden Ausf h rungsregeln Sobald die eingehende Transition eines Aktionszustands geschaltet hat wird die zust ndige Softwarekomponente mit der Ausf hrung beauftragt Wenn sie terminiert wird die ausgehende Transition des Zustands aktiviert Sobald die eingehende Transition eines Subaktivit tszustands geschaltet hat wird der Ausf hrungsalgorithmus f r den referenzierten oder eingebetteten Prozess gestartet Wenn er terminiert wird die ausgehende Transition des Zustands aktiviert 10 1 Semantik von Prozessdiagrammen 213 2 Da mit dem XML Migrationsdokument ein impliziter Datenfluss gegeben ist ist eine explizite Modellierung mit Hilfe von Objektflusszust nden nicht vorgese hen Damit entf llt f r Prozessdiagramme auch die Semantik dieser Zust nde 3 Weil in XML Prozessen keine Organisationshierarchie gegeben ist sondern als Akteure ausschlie lich Softwarekomponenten zum Einsatz kommen werden zur Modellierung keine Bahnen Swimlanes verwendet Neben diesen Einschr nkungen enthalten Prozessdiagramme Erweiterungen f r die wir im Folgenden die Semantik festlegen Wie schon die Erweite
249. f r alle Parameter der Methode bergeben werden Zu diesem Zweck wurden in der Prozessbeschreibung Ausdr cke f r jeden Parameter des Service angegeben Diese m ssen folgenden Aufbau haben damit sie vom Interpreter ausgewertet werden k nnen lt Basis gt lt Ausdruck gt F r lt Basis gt sind drei F lle zu unterscheiden die denen im Abschnitt 6 2 2 entsprechen Falls f r lt Basis gt das Wort static eingesetzt wird so bergibt der Interpreter den Text f r lt Ausdruck gt direkt als Argumentwert an den Service Auf diese Weise lassen sich feste Werte in der Prozessbeschreibung verdrahten Wenn f r lt Basis gt das Wort document angegeben wird interpretiert der Interpreter lt XPath gt als XPath Ausdruck der auf das Migrations dokument angewendet wird In allen anderen F llen geht er davon aus dass sich in der Prozessumgebung vgl Abschnitt 10 5 ein XML Dokument mit dem angegebenen Namen befindet f r den der XPath Ausdruck ausgewertet werden soll G ltige Argu mentausdr cke sind also beispielsweise static wert document root elementl env1 local name root 10 3 Fehlerbehandlung 225 10 3 Fehlerbehandlung F r die Robustheit des Prozessinterpreters und des Workflow Management Systems ist es sehr wichtig dass auch unvorhergesehene Fehlersituationen eingeplant werden die gerade bei der Integration von heterogenen Anwendungen auftreten k nnen Denn neben den Programmfehlern des Interpreters selbst muss
250. f die gleiche Weise geht der Interpreter im Falle eines Sub aktivit tszustandes vor Auch hier wird f r den eingebetteten Prozess eine eigene ProcessSection gestartet Durch diesen Mechanismus ist es auf einfache Weise m glich beliebig tief geschachtelte Prozesse korrekt abzuarbeiten Die Methode executeProcess aus der Klasse ProcessInterpreter wird von der Systemumgebung aus verwendet um ein Prozessmodell auszuf hren Sie startet und initialisiert den obersten Thread in der Hierachie der Prozessabschnitte Wenn dieser terminiert ist die Abarbeitung des gesamten Prozesses beendet und die Methode liefert als Ergebnis das resultierende Migrationsdokument Abbildung 10 7 zeigt ein verein fachtes Prozessdiagramm und die zugeh rige Objektstruktur zur Ausf hrungszeit Auf der obersten Ebene befindet sich der ProcessInterpreter der aus der Umgebung heraus gestartet wurde um den Prozess auszuf hren F r jeden der beiden parallelen Str nge wird eine eigene ProcessSection als Kind an ProcessInterpreter angeh ngt Dieser f hrt erst dann fort wenn beide Kinder terminiert sind Da der linke Strang aus einem Sub prozess besteht wird f r diesen ebenfalls eine ProcessSection als Kind des linken Strangs erzeugt 10 2 Der Prozessinterpreter 221 RER RES Processinterpreter gesamter Prozess ProcessSection ProcessSection linker Strang rechter Strang E Ca ProcessSection Subproz
251. g wird durch die Angabe transactional notiert Als erstes wird durch eine SQL Anweisung die von der SQL Komponente ausgef hrt wird der berweisungsbetrag vom Konto des Auftraggebers abgebucht Danach unterscheidet der Prozess zwei F lle Falls die Bankleitzahl des Empf ngers mit der Bankleitzahl dieser Bank bereinstimmt es sich also um eine interne berweisung handelt kann direkt mit Hilfe einer weiteren SQL Anweisung der Betrag dem Empf ngerkonto gutgeschrieben werden Sie wird wiederum von der SQL Komponente ausgef hrt Falls jedoch die berweisung zu einem fremden Geldinstitut erfolgen soll wird mit Hilfe der CORBA Komponente ein Auftrag an dieses Geldinstitut gesendet Damit ist der linke Teilprozess beendet und kann mit dem parallelen rechten vereinigt werden Im rechten Strang erfolgt eine Pr fung der berweisung Falls der Name des Auftraggebers mit dem des Empf ngers bereinstimmt und zudem eine unterschiedliche Bankleitzahl angegeben wurde kann davon ausgegangen werden dass der Kunde ein Konto bei einer anderen Bank besitzt Dies ist bei der beispielhaften berweisung der Fall Daher soll die Customer Relationship Management Abteilung CRM benachrich tigt werden Zu diesem Zweck erfolgt zun chst eine Datenbankanfrage die die aktuelle E Mail Adresse des CRM Beauftragten ermittelt und in die XML Daten schreibt Anschlie end wird mit Hilfe der Mail Komponente eine entsprechende Mail an den Sachbearbeiter versendet Dem S
252. ge Kontext in dem der Konnektor beschrieben wird Daneben enth lt ein Konnektor eine Menge von Services als Metho den des Interface siehe n chster Absatz Der Aufbau des XML Elements ist im Schema folgenderma en definiert metaclass Interface i L i stereotype l l stereotype componentConnector Tags lt xsd complexType name ComponentType gt lt xsd sequence gt lt xsd element name service type ServiceType minOccurs 0 maxOccurs unbounded gt lt xsd sequence gt lt xsd attribute name interface type xsd string use required gt lt xsd complexType gt Abb 8 10 PML Schema Fragment f r Konnektoren 8 3 Process Markup Language PML 177 Stereotyp service Um die Services einer Komponente zu definieren dient das Element lt service gt inner halb der Beschreibung eines Konnektors Sein Attribut method spezifiziert den Namen der zugeh rigen Methode im Interface der Komponente Jeder Service hat nun vier Bestandteile die sich aus den Werten des UML Stereotyps service ergeben Im Attribut href des Elements lt image gt kann eine URL bestimmt werden die auf eine Grafik zeigt Diese wird im Modellierungswerkzeug zur Darstellung des Service verwendet Die Elemente lt inputPort gt und lt outputPort gt legen die Ein und Ausgangsports des Service fest Ihr Aufbau entspricht der Definition aus Abschnitt 8 3 1 Schlie lich kann ein Service beliebig viele
253. gearbeitet ist und das Ergebnis als XML Dokument zur ckgegeben werden kann Der Prozessinterpreter setzt somit die Workflow Modelle um und dient als Bindeglied zwischen der E Business Plattform und den nachgelagerten Back End Systemen die in den Aktivit ten der Workflows vom Prozessinterpreter aufgerufen werden Zus tzlich wurden in Ab schnitt 10 3 Konzepte zur Fehlerbehandlung und in 10 4 zur transaktionalen Ausf h rung von Prozessen diskutiert Die implementierten Werkzeuge umfassen insgesamt 193 Java Klassen mit etwa 30 000 LOC lines of code Sowohl bei der Software Modellierung als auch bei der Implementierung hat sich der intensive Gebrauch von Entwurfsmustern bew hrt So konnte bei der Konstruktion des Datenmodells dem flexiblen Zugriff ber Schnittstel len auf die Datenstrukturen der Realisierung der grafischen Benutzungsoberfl che und an vielen anderen Stellen auf Standardl sungen und bew hrte Programmiererfahrung in Form von Entwurfsmustern zur ckgegriffen werden Im Rahmen der Zusammenarbeit mit der S amp N AG in Paderborn wurden die so implementierten Werkzeuge in die E Business Plattform sunShine des Unternehmens integriert Bisher war es dort nicht m glich Workflows graphisch zu modellieren und dann automatisiert auszuf hren Statt dessen m ssen die in Abschnitt 4 3 vorgestellten Pipelines manuell wie mit einer Programmiersprache kodiert werden Die zu Anfang betrachtete und am Schluss aufge griffenen Fallstudie siehe
254. gefasst f r Details siehe dort Gew nscht wurde als E Business Plattform ein Workflow Management System zur Verarbeitung von XML Dokumenten Zur Realisierung eines Multi Channel Ansatzes sollten verschiedene Ein und Ausgabeformate unterst tzt aber die Dokumente jeweils in ein internes XML Format transformiert werden Eine Regelmaschine sollte je nach ausgew hltem Prozess und Zustand des Dokumentes daf r sorgen dass das Dokument zur Weiterverarbeitung an den richtigen Nachfolgeservice weitergeleitet wird Die vorhandenen Services sollten dann die nachgelagerten Back End Funktionalit ten aufrufen und so die vorhandenen Anwendungs und Datenbank systeme integrieren Die Realisierung der E Business Infrastruktur erfolgte im Rahmen eines Projektes der S amp N AG Bei der Beschreibung der umfangreichen Projektrealisierung wollen wir uns auf die Aspekte des Workflow Managements konzentrieren und Rand probleme wie die kontinuierliche Archivierung von Zwischenergebnissen und die Transformation von und nach anderen Datenformaten zur Umsetzung des Multi Channel Ansatzes an dieser Stelle ausklammern In den Projektanforderungen wurde explizit die Verarbeitung von XML Dokumenten gew nscht Daher eignet sich die in Abschnitt 4 3 vorgestellte XML basierte Software sunShine f r diese Aufgabe sehr gut Die Anbindung der Back End Systeme und auch der Archivierungsdatenbank konnte durch die Entwicklung passender sunShine Transformerklassen siehe Abschnitt
255. gen Kapitel vorgestellten Erweiterungen von UML Aktivit tendiagram men sollen formal als Erweiterungen des UML Metamodells definiert werden Dazu erl utert der folgende Abschnitt zun chst die erforderlichen Grundlagen des allgemei nen UML Metamodells Danach folgt ein Einblick in die Erweiterungsmechanismen die die UML Spezifikation zur Erg nzung des Metamodells zur Verf gung stellt Unter Ausnutzung dieser Erweiterungsmechanismen beschreibt Abschnitt 7 3 das speziell zur Repr sentation von Prozessdiagrammen erweiterte Metamodell als eigenes UML Profil f r Prozessdiagramme Der vierte Abschnitt dokumentiert die Implementierung dieses Metamodells in der Programmiersprache Java die als Grundlage f r die im dritten Teil der Arbeit vorgestellten Werkzeuge fungiert Daran anschlie end zeigen die Ab schnitte 7 5 und 7 6 Algorithmen f r dieses Metamodell mit denen sich Prozesse vali dieren und Ports automatisch berechnen lassen 7 1 Das UML Metamodell Bei dem sogenannten UML Metamodell handelt es sich laut OmgOl 2 3 um ein implementierungsunabh ngiges Modell das zur deklarativen Festlegung der Semantik aller UML Sprachelemente dient Jedes Element wird dabei unter drei Sichtweisen betrachtet Durch einen abstrakten Syntaxgraphen welcher selbst aus einem UML Klassendiagramm besteht erfolgt die Festlegung der Syntax aller UML Elemente in ihrem jeweiligen Kontext Auf diese Weise definiert sich die UML nach dem Prinzip des Bootstrappi
256. gen der anderen Prozesse eingebaut werden m ssen F r die Realisierung von XML Prozessen haben wir uns f r eine Variante der letztgenannten M glichkeit entschieden Zun chst bekommt jeder Teilprozess eine eigene Kopie des Migrationdokuments bergeben und seine Aktivit ten k nnen belie bige Transformationen daran vornehmen Bei der Wiedervereinigung der Str nge wird jedoch nicht versucht die einzelnen Dokumente zusammenzuf hren sondern es werden einfach alle Dokumente als Unterelemente an ein neues XML Wurzelelement ange h ngt Dabei kann es nat rlich passieren dass bestimmte Daten doppelt in dem zusam mengesetzten Dokument vorkommen Dem Workflow Management System fehlen jedoch die n tigen Hintergrundinformationen um dies automatisiert zu vermeiden Stattdessen kann bei Bedarf hinter den Join Zustand eine Transformation geschaltet werden die das zusammengesetzte Dokument sozusagen bereinigt und in eine Struktur berf hrt die an den Rest des Prozesses weitergeleitet wird Dieses Vorgehen ist vergleichbar mit dem Konzept der Umlaufmappen aus dem Dokumentmigrationsmodell siehe Abschnitt 6 1 1 Dabei k nnte es ebenfalls vorkommen dass Teile der Umlauf mappe an verschiedene Sachbearbeiter gegeben werden die zeitgleich daran arbeiten Die Ergebnisse werden sp ter wieder eingesammelt und in die Mappe eingegliedert Dabei kann der Sachbearbeiter der f r diese Zusammenf hrung zust ndig ist den Inhalt der Mappe anpassen bevor er
257. gen und Wiedervereinigen von parallelen Teilstr ngen erlauben als auch die zwischenzeitliche Synchronisation an bestimmten Ausf hrungspunkten Prinzipiell ist es in Aktivit tendiagrammen erlaubt die Ausf hrung an mehreren Stellen in verschiedenen Systemzust nden zu beenden Mit Hilfe eines grafischen Werkzeugs f r das Erstellen von Diagrammen ist es aber leicht sicherzustellen dass nur je eine Start bzw Endaktivit t existiert Es m ssen lediglich alle Systemzust nde in denen die Abarbeitung enden soll durch Transitionen mit einem neuen eindeutigen Endzustand verbunden werden Aktivit tendiagramme bieten die M glichkeit Objektfl sse zwischen einzelnen Aktivit ten zu spezifizieren Dies ist ein Ansatzpunkt f r die Verarbeitung von XML Dokumenten durch die Aktionen eines Diagramms Zus tzlich wurde gefordert dass f r jede Stelle innerhalb eines Prozessmodells Angaben ber die Struktur des XML Dokuments gemacht werden k nnen Abschnitt 3 3 Punkt 3 Solche G ltigkeitsaus sagen sind bislang nicht vorgesehen 5 4 Bewertung 71 Die UML Spezifikation erlaubt verschiedene M glichkeiten um den Inhalt von Aktivit ten zu spezifizieren Da in XML Prozessen jede Aktivit t eine Systemkompo nente repr sentiert die XML Daten verarbeiten und ggf manipulieren Kann muss hier eine Einschr nkung definiert werden damit nur zugelassene Komponenten verwendet werden k nnen In diesem Zusammenhang muss eine M glichkeit geschaffen werd
258. genau einen Start und einen End punkt haben muss ist zwar durch Petri Netze prinzipiell nicht erf llt Dies kann aber einfach als zus tzliche Bedingung an ein Petri Netz gestellt werden Im Rahmen eines Modellierungswerkzeugs l sst sich diese Eigenschaft eines Netzes leicht berpr fen und sicherstellen Durch die Erweiterung von Petri Netzen um Hierarchie d h die M glich keit Subnetze zu definieren die aus einem bergeordneten Netz heraus aufgerufen wer den ist es m glich vordefinierte Basisprozesse zu einem neuen Gesch ftsvorgang zu aggregieren In Petri Netzen wird durch das Schalten von Transitionen der Durchlauf von Objekten durch einen Arbeitsablauf beschrieben Wie bereits beschrieben lassen sich verschiedene Kontrollfl sse modellieren wie parallele Ausf hrung Synchronisation usw Es wird jedoch nicht formal spezifiziert welche Aktivit t sich hinter der Ausf h 58 Kapitel 5 Evaluierung vorhandener Workflow Modellierungssprachen rung einer Transition verbirgt W hrend klassische Netze sogar davon ausgehen dass das Schalten keine Zeit in Anspruch nimmt Kann man mit h heren Netzen Aussagen ber solchen Zeitverbrauch machen Derartige explizite Angaben ber die Ausf h rungsdauer von Prozesskomponenten ist f r unseren Anwendungsbereich nicht erfor derlich Stattdessen muss definiert werden welche Komponente in welchem Zustand des Prozesses angesprochen werden soll um die Verarbeitung zu bernehmen Da sich Petr
259. gnalisieren dass bei der Ausf hrung dieser Weg genommen werden soll falls alle anderen Guards nicht erf llt sind 3 Inallen anderen F llen ist kein Guard erlaubt Das zugeh rige Feld im Dialog ist daher deaktiviert Folgezustand bestimmen Alternativ zu dem bisher beschriebenen Vorgehen bei dem zun chst einzelne Zust nde in ein Prozessdiagramm eingef gt werden die anschlie end mit passenden Transitionen verbunden werden bietet der Prozesseditor auch die M glichkeit direkt zu jedem Zustand einen Nachfolgezustand zu erzeugen Dazu w hlt man den gew nschten Zustand mit der rechten Maustaste an und ruft die Aktion Add Successor auf Es erscheint ein modaler Dialog mit zwei Karteireitern einer zum Anlegen eines Service und der andere zum Anlegen eines Subaktivit tszustands Anhand der Ports berpr ft der Editor welche Services und Prozesse an dieser Stelle des Prozesses aufgerufen werden k nnen Dabei werden auch die Transitionstypen ber cksichtigt die aufgrund ihrer Stylesheets den Aufruf von Services und Prozessen erm glichen deren Port eigentlich nicht kompatibel zum Ausgangsport des gew hlten Zustands sind Der Prozesseditor bietet also nur solche Services und Prozesse an deren Verwendung die Bedingungen des Kompatibilit tssatzes und des Migrationssatzes siehe Ab schnitt 6 3 3 erf llen so dass sich ein konsistenter Dokumentfluss durch das Diagramm ergibt Der Benutzer kann sich aus der so generierten Liste eine
260. gungen die ein mit dieser UMIL Erweiterung formuliertes Modell einhalten muss um wohlgeformt zu sein Die Einhaltung muss dabei in jedem stabilen Systemzustand gew hrleistet sein das ist immer dann wenn gerade keine atomare Operation ausgef hrt wird Die entsprechende berpr fung wird dabei an das jeweilige Modellierungswerkzeug delegiert Die Constraints k nnen in einer beliebigen Sprache sowohl formal z B durch OCL oder eine Programmiersprache als auch nat rlichsprachlich angegeben werden Die jewei lige Interpretation der Regeln sollte der Sprache inh rent sein Constraints K nnen allen Elementen des UML Metamodells zugewiesen werden insbesondere nat rlich den Stereotypen Wurde f r ein Stereotyp durch ein Constraint eine entsprechende Regel definiert so muss sie f r alle Instanzen dieses Stereotyps eingehalten werden 7 2 3 Profile Nachdem f r ein bestimmtes Anwendungsgebiet eine UML Erweiterung als Menge von Stereotypen Tagged Values und Constraints definiert worden ist Kann man sie in einem speziellen UML Package zusammenfassen Ein solches Package erh lt das in UML vordefinierte Stereotyp Profile Zus tzlich kann man in einem Profil die f r die Erweiterung neu eingef hrten Datentypen spezifizieren sowie eine Teilmenge der UML Sprachdefinition angeben die bei der Anwendung der Erweiterung f r das 7 3 UML Profil f r Prozessdiagramme 129 spezielle Anwendungsfeld relevant ist Reichen die drei Erweiterungsmec
261. h ne entstanden ist selbstst ndig angefertigt und keine anderen als die angegebenen Quellen und Hilfsmittel benutzt habe Alle Stellen die dem Wortlaut oder dem Sinne nach anderen Werken entnommen sind habe ich unter genauer Angabe der Quelle deutlich als Entlehnung kenntlich gemacht Paderborn Dezember 2001 Bj rn L tkemeier Ich versichere dass ich die kenntlich gemachten Teile dieser Diplomarbeit die als Gruppenarbeit mit Bj rn L tkemeier entstanden ist selbstst ndig angefertigt und keine anderen als die angegebenen Quellen und Hilfsmittel benutzt habe Alle Stellen die dem Wortlaut oder dem Sinne nach anderen Werken entnommen sind habe ich unter genauer Angabe der Quelle deutlich als Entlehnung kenntlich gemacht Paderborn Dezember 2001 Sebastian Th ne Inhaltsverzeichnis 1 2 Einlatune au nenne enlekeneheelrennehehen ah keerehesen 5 Grundlagen des Workflow Managements ssssssssessossessonsessnssessnnsnnssnsenssnnennee 9 2 1 Prozessorientierte Integration im E Business uussuersnersnnesnneennnennnnesnne nn 9 2 2 Prozesse in einem Unternehmen u 22a Ne 11 2 2 1 Der Begriff Workflow anna anna 12 2 2 2 Klassifizierung von Informationsprozessen ursnersnnesnnersnnessesnnennnnen en 14 22 3 Integration existierender Anwendungen 222022200ssnersnernnensnersne en 15 2 3 Modellierung von Prozessen zn a red 17 2 3 1 Organisationsmodellierung und statische Modelle
262. h der Wiederverwend barkeit der betroffenen Komponenten Das Ziel von Cocoon ist es daher die drei Berei che Inhalt Layout und Logik strikt voneinander zu trennen Als plattformunabh ngige Technologien f r die Umsetzung dieses Ziels werden XML XSL eXtensible Stylesheet Language siehe XSLT99 und Java verwendet In Apa01 werden folgende drei Ebe nen unterschieden Erzeugung von XML Die Erzeugung von XML Dokumenten geschieht durch Auto ren Sie ben tigen kein Wissen ber die sp tere Verarbeitung ihrer Dokumente sondern m ssen lediglich daf r sorgen dass diese g ltig bez glich der geforderten Document Type Definition DTD bzw eines XML Schemas ist Verarbeitung von XML Die erzeugten XML Dokumente werden schrittweise verar beitet indem sie eine Kette von externen Logikkomponenten durchlaufen Diese k nnen sowohl Daten aus dem Dokument lesen als auch nderungen daran vornehmen Darstellung durch XSL Die verarbeiteten XML Dokumente k nnen schlie lich durch Anwendung von XSL Stylesheets in das gew nschte Ausgabeformat transformiert wer den Denkbar sind hier HTML WML XML PDF usw Durch die konzeptionelle und implementierungstechnische Unterscheidung dieser drei Ebenen kann eine bessere Trennung von Kompetenzen sowie Wartbarkeit von Soft waresystemen erreicht werden Cocoon stellt sich dabei als Plug in Erweiterung von beliebigen Java f higen Webservern dar um seine Funktionalit t zur Verf gung zu stellen Die A
263. h direkt ver ndert werden Abbildung 9 3 zeigt beispielhaft die Eingabemaske f r einen Service Alle brigen Masken haben nat rlich ein anderes Aussehen die grund s tzliche Bedienung ist jedoch analog impei Port hy koraha urn erara Tr il Add Trara kr en EI j Tumin Wie a Tran Fib Taipi Fort Trai kin Bgy Pr Wen Trara dar Hih Para ii LEL Ea Abb 9 3 Eingabemaske f r einen Service Links oben in der Maske wird angezeigt dass es sich um die Eingabemaske zu einem Service handelt Darunter ist der Name des Konnektors angegeben zu dem der Service geh rt Diese Information kann vom Benutzer nicht ver ndert werden da der Konnek tor zu dem ein Service geh rt unwiderruflich feststeht Unterhalb davon kann bei Bedarf der Name des Service ge ndert werden Des Weiteren l sst sich ein Bild aus w hlen das in den Prozessdiagrammen zur Darstellung des Service verwendet wird Entweder kann direkt in das entsprechende Feld eine URL eingegeben werden hinter der das gew nschte Bild abgelegt ist oder es l sst sich durch Bet tigen der Schaltfl che Select Image ein Bild ausw hlen Es erscheint dann ein Dateiauswahldialog Das aus 196 Kapitel 9 Modellierungswerkzeug f r Prozessdiagramme gew hlte Bild wird in der Eingabemaske angezeigt Schlie lich enth lt die Maske noch eine Liste in der die Namen der Parameter angegeben werden k nnen die der Service besitzt Auf der rechten Se
264. h wie m glich erkannt werden d h bevor der Interpreter berhaupt mit der Ausf hrung beginnt An dieser Stelle soll der von uns entwickelte Validierungsalgorithmus erl utert werden Er ist vom Konzept her nicht an die konkrete Implementierung aus Ab schnitt 7 4 gebunden und lie e sich daher auch f r andere Datenstrukturen realisieren Da ein Prozessdiagramm einen gerichteten Graph darstellt f hrt der Algorithmus eine Tiefensuche ausgehend vom Startzustand des Prozesses durch Auf diese Weise besucht er Schritt f r Schritt alle Zust nde F r jeden gefundenen Zustand werden abh ngig von seinem Typ alle notwendigen berpr fungen durchgef hrt vgl Abschnitt 7 3 Dazu z hlt beispielsweise die korrekte Anzahl ein und ausgehender Transitionen die Kompatibilit t der Ports usw F r Transitionen wird gepr ft ob Guards korrekt verwen det wurden und die Ports der Transitionstypen kompatibel sind W hrend der Tiefen suche werden auch die im Prozess verwendeten Bestandteile des statischen Modells d h Konnektoren und Transitionstypen validiert Ein wichtiger Gegenstand der Validierung ist die korrekte Schachtelung von parallelen Prozessabschnitten im Zusammenhang mit Fork und Join Zust nden die den Wohlgeformtheitsregeln der UML Spezifikation Omg01 2 157f und 2 183f gen gen muss Dazu z hlt beispielsweise die Bedingung dass alle Pfade die von einem Fork Zustand ausgehen sp ter wieder in einem Join Zustand vereinigt werden Z
265. hanismen nicht vollst ndig aus lassen sich f r ein Profil auch nat rlichsprachliche Semantik informationen und Erkl rungen erg nzen Neben den Constraints f r bestimmte Modellelemente k nnen allgemeine Wohlgeformtheitsregeln die Spracherweiterung abrunden vgl Omg99 S 25 Working Definition of a UML Profile und Omg01 2 198f Im n chsten Abschnitt dieses Kapitels findet sich als Beispiel f r eine UML Erweiterung das von uns aufgestellte Profil zur Modellierung von Prozessdiagrammen 7 3 UML Profil f r Prozessdiagramme In diesem Abschnitt soll nun mit Hilfe der UML Erweiterungsmechanismen die Spra che zur Modellierung von XML Prozessen formal spezifiziert werden Wie in Abschnitt 7 2 4 beschrieben wurde l sst sich eine Menge von Erweiterungen der UML f r ein bestimmtes Anwendungsgebiet zu einem sogenannten Profil zusammenfassen Daher sollen die in den folgenden Abschnitten spezifizierten Sprachkonstrukte ein Profil zur Modellierung von Prozessdiagrammen bilden Folgende Erweiterungen bzw Ein schr nkungen von Aktivit tendiagrammen sind notwendig um damit Prozessdia gramme erstellen zu k nnen e Jedes Prozessdiagramm hat genau einen Start und Endzustand e Es m ssen Ports definiert werden k nnen mit denen sich die Schnittstellen der Zust nde und Transitionen beschreiben lassen Jeder Port repr sentiert eine spezielle Menge von XML Dokumenten die zu diesem Port konform sind e In Aktivit tszust nden i
266. her Modelle Da die Beschreibung von komplexen Prozes sen recht gro werden kann wurde PML so konstruiert dass nicht alle Bestandteile eines Package in ein und demselben Dokument beschrieben werden Vielmehr werden alle statischen Elemente eines Package in einem gemeinsamen PML Dokument defi niert jeder Prozess besitzt jedoch ein eigenes Dokument Daraus ergeben sich zwei globale XML Elemente die als Wurzelelement eines PML Dokuments benutzt werden k nnen lt package gt zur Beschreibung des statischen Modells und lt process gt um einen Prozess zu beschreiben Um die statischen Elemente eines Package zu definieren erh lt ein PML Dokument also als Wurzelelement das Tag lt package gt Als Attribut name wird der Name des Package angegeben Unterhalb davon k nnen sich zwei Elemente lt components gt und lt transitionTypes gt befinden um die Komponenten bzw die Konnektor Klassen und die Transitionstypen zu beschreiben Stereotyp componentConnector Einer Komponente die in Prozessdiagrammen verwendet werden kann ist im UML Modell stets ein Stereotyp componentConnector als erweitertes Interface zugeordnet F r jeden solchen Konnektor befindet sich unterhalb des Elements lt components gt ein Element mit dem Namen lt component gt Als Wert seines Attributs interface gibt man den Namen des zugeh rigen UML Interface an allerdings ohne das Package in dem es enthalten ist Dieses ergibt sich bereits aus dem Packa
267. hieht ist dem Modell hingegen nicht bekannt Diese Annahme ist mit dem f r XML Netze gew hlten Ansatz der XManiLa Ausdr cke nicht vereinbar da mit XManiLa Manipulationen an XML Dokumenten beschrieben werden Schlie lich erlauben XML Prozesse auch Aktionen die unabh ngig von den XML Daten sind Denkbar ist beispielsweise das Versenden von E Mails oder die Ausf hrung von Daten bankoperationen Da XML Netze sich ausschlie lich auf die Verarbeitung von XML Daten konzentrieren ist eine Spezifizierung solcher Aktionen nicht m glich 5 2 Ereignisgesteuerte Prozessketten Das Konzept der Gesch ftsprozessmodellierung mit Ereignisgesteuerten Prozess ketten EPK wurde Anfang der neunziger Jahre entwickelt und geht auf Arbeiten im Umfeld von Scheer zur ck vgl Kel92 Der in Kel92 als EPK vorgestellte proze orientierte Modellierungsansatz bildet die Grundlage zur Ermittlung und Dokumenta tion der betriebswirtschaftlichen Zusammenh nge in einem Unternehmen S 1 Mit ihm sollen Gesch ftsprozesse einfach bersichtlich und trotzdem eindeutig dargestellt werden Kel99 S 158 Der Zweck des Einsatzes der EPK ist also in erster Linie die Dokumentation der betrieblichen Zusammenh nge und Abl ufe eine m gliche automa tisierte Ausf hrung wurde zu Beginn nicht ber cksichtigt Es wird sich im Folgenden auch zeigen dass das Ziel der Eindeutigkeit nur bedingt erreicht werden kann 5 2 1 Basiskonstrukte des EPK Modells
268. hlt werden muss Der Editor legt dann einen neuen Prozess an der sofort im Baum sichtbar wird und bereits selektiert ist Im rechten Bereich des Fensters erscheint die zugeh rige Eingabemaske die aus zwei Karteireitern besteht siehe Abbildung 9 8 Im Reiter Properties kann man die Eigenschaften des Prozesses einstellen Auf der linken Seite l sst sich der Name des Prozesses und bei Bedarf sein Package ver n dern Au erdem kann festgelegt werden ob er transaktional ausgef hrt werden soll oder nicht Auf der rechten Seite befinden sich die Felder f r die Ports wobei sich jedoch nur der Eingangsport editieren l sst Der Ausgangsport wird automatisch vom Editor anhand der Prozessstruktur berechnet vgl Abschnitt 7 6 200 Kapitel 9 Modellierungswerkzeug f r Prozessdiagramme Abb 9 8 Eingabemaske f r einen neuen Prozess Um den Prozess selbst mit seinen Zust nden und Transitionen zu modellieren wechselt man in den Karteireiter Design in dem bereits je ein Start und Endzustand existiert Abb 9 9 Zeichenfl che f r ein Prozessdiagramm 9 2 Bedienung des Prozesseditors 201 Der Karteireiter Design besteht aus einer gro en Zeichenfl che in dem der ausge w hlte Prozess grafisch in Form eines Prozessdiagramms dargestellt ist Alle grafischen Elemente des Diagramms d h seine Zust nde und Transitionen lassen sich mit der rechten Maustaste ausw hlen hnlich zum Projektbaum erscheint dann ein Popup
269. ht durch wirtschaftliche Interessen und Entscheidungen beeinflusst wird F r den Einsatz von Petri Netzen im Bereich der Workflow Modellierung schl gt Aal97 folgende Abbildung von Gesch ftsprozessen auf Petri Netze vor Da jeder Gesch ftsprozess laut Definition eine Folge von Aktionen mit gemeinsamem Gesch ftsziel ist Wmc95 muss zun chst genau eine definierte Startstelle Quelle und genau eine Zielstelle Senke existieren Jede weitere Stelle repr sentiert einen bestimmten Zustand innerhalb der Prozessablaufs Aufgaben die w hrend des Prozes ses durchzuf hren sind werden durch Transitionen ausgedr ckt Jeder Anwendungsfall also beispielsweise jedes Dokument das einen Prozess durchl uft wird durch Marken dargestellt Mit Hilfe der Erweiterung von individuellen Marken ist es m glich die ein zelnen Anwendungsf lle zu unterscheiden und zus tzliche Anwendungsdaten daran zu kn pfen die f r die Ausf hrung des Prozesses relevant sind Abbildung 5 3 zeigt zur Verdeutlichung das Petri Netz eines beispielhaften Gesch ftsprozesses Modelliert wurde die Situation dass ein Bankkunde bei seiner Bank einen Kredit beantragt Je nach H he des Kredits bzw dem Ergebnis einer Schufa Anfrage verzweigt die Ausf hrung in unterschiedliche ste Um einen besseren Vergleich der verschiedenen Modellierungssprachen zu erm glichen findet sich dieses Beispiel auch in den Abschnitten 5 2 und 5 3 wieder 5 1 Petri Netze 55 Kundenda ten
270. i das gemeinsame Meta Metamodell aller objektorientierten Modelle der OMG Sprachhierarchie siehe Jec00 So ist zum Beispiel das UML Metamodell eine Auspr gung des MOF Modells vgl die Vier Schichten Architektur der UML Abschnitt 7 1 1 Konkret definiert XMI mit den sogenannten DTD Production Rules Prinzipien 8 2 Vorhandene XML Formate f r Prozessmodelle 167 zur Abbildung von Klassendiagrammen in DTD Strukturen Auspr gungen des Klas sendiagramms k nnen so in einem zur DTD g ltigen XML Dokument gespeichert werden welches man auch XMI Dokument nennt Wie solche Modell Auspr gungen in das XMI Dokument berf hrt werden k nnen wird ebenfalls in XMI durch sogenannte Document Production Rules festgelegt siehe XMI00 1 1 Da sowohl das MOF Modell als auch das UML Metamodell als Klassendiagramm dargestellt werden konnte die Nutzbarkeit von XMI durch die Erzeugung je einer DTD f r UML und MOF demonstriert werden Wegen ihrer gro en Bedeutung wurden diese zwei DTDs als Anhang in die XMI Spezifikation aufgenommen Eine Auspr gung des UML Meta modells also jedes UML Modell bestehend aus Klassen und sonstigen Diagrammen kann somit nun textuell in einem XMI Dokument gespeichert werden das bez glich der UML DTD g ltig ist vgl Abbildung 8 2 XML XMI MOF DTD XML DTD Production Rules Metamodell z B UML DTD z B UML Metamodell g ltig bzgl Auspr gung von Document Production Rules Mod
271. i Netze ausschlie lich auf die Modellierung der dynamischen Abl ufe beschr nken kann ein statisches Modell der Komponenten eines Prozesses nicht dargestellt werden Ebenso wenig ist es in Petri Netzen m glich Parametereinstellungen f r den Aufruf der Komponente anzugeben der sich hinter dem Schalten einer Transition verbirgt Um diese Anforderungen erf llen zu k nnen m ssten Petri Netze um geeignete Sprach elemente erweitert werden Diese Erweiterung m sste exakt definiert werden damit die formale Semantik der Netze erhalten bliebe und eine automatisierte Ausf hrung m g lich w re Die Forderung nach einem Konstrukt zur Umsetzung eines Transaktions konzepts l sst sich mit Petri Netzen ebenfalls nicht ohne Weiteres realisieren Da dem Datenfluss also der Verarbeitung und Manipulation von Anwendungs daten w hrend der Ausf hrung eines Prozesses in dieser Arbeit eine besondere Rolle zukommt ist diesem Aspekt ein eigener Abschnitt gewidmet 5 1 5 Datenfluss in Petri Netzen In realen Prozessen gibt es fast immer bestimmte Objekte die w hrend der Ausf hrung von Aktionen manipuliert und zwischen verschiedenen Aktionen weitergereicht werden Solche Sachverhalte die man auch Daten oder Objektfluss nennt m ssen in der Modellierung korrekt abgebildet und beschrieben werden In Petri Netzen besteht die einzige Ausdrucksm glichkeit darin Objekte mit Marken zu identifizieren Der Ausf h rungssemantik von Petri Netzen entsprechend
272. iagramme fast alle notwendigen Sprachkonstrukte besitzen vgl DumOl S 1 und ihre Funktionsweise mit der Idee von XML Prozessen harmoniert An einigen Stellen werden Erweiterungen erforderlich sein die sich aber mit Hilfe der UML Erweiterungsmechanismen siehe Abschnitt 7 2 auf standardisierte Weise vornehmen lassen Wir haben uns daher entschieden als Ausgangspunkt f r die Modellierung mit Prozessdiagrammen UML Aktivit tendiagramme zu w hlen Im folgenden Kapitel wird eine Workflow Modellierungssprache auf Basis von UML Aktivit tendiagrammen vor gestellt die die notwendigen Erweiterungen enth lt 74 _ Kapitel 6 XML Prozesse und Prozessdiagramme 6 1 Konzeption von XML Prozessen 75 6 XML Prozesse und Prozessdiagramme Nach der vorausgegangenen Evaluierung ausgew hlter Systeme und Modellierungs sprachen m chten wir nun unseren eigenen Ansatz f r XML basierte Workflows vor stellen Dabei geht es vor allem um das zu Grunde gelegte Konzept f r XML Prozesse und die Vorstellung von Prozessdiagrammen als Sprache mit der sich solche Workflows modellieren lassen Die Umsetzung als Workflow Management System wird in einem Architekturvorschlag nur grob skizziert und in den Kapiteln 9 und 10 n her beschrieben 6 1 Konzeption von XML Prozessen In diesem Abschnitt erl utern wir grundlegende Konzepte zur Umsetzung der Anforde rungen an XML Prozesse aus Kapitel 3 Im Einzelnen befassen sich die folgenden Unterabschnitte mit den Anforde
273. iche L sung aussehen k nnte Dabei geht es neben Optimierungen der beste henden Konzepte auch um denkbare Erweiterungen sowie M glichkeiten zur Verbesse rung oder Effizienzsteigerung der implementierten Systeme Visualisierung von Ports Bei der bisherigen Notation der Ports von verschiedenen Bestandteilen eines Workflow Modells handelt es sich um eine rein textbasierte Dar stellungsform Im Abschnitt 6 3 1 wurde daher vorgeschlagen Ports nicht innerhalb eines Prozessdiagramms darzustellen sondern es einem CASE Tool zu berlassen sie dem Benutzer anzuzeigen Es scheint uns schwierig zu sein eine grafische Repr senta tion f r Ports zu entwickeln da es sich um Mengen von XML Elementen handelt die ihrerseits textuell beschrieben werden Denkbar ist eine gro e Menge verschiedener Ports oder Dokumenttypen so dass sich nicht einfach eine berschaubare Menge von Farben oder Symbolen verwenden l sst um Ports zu veranschaulichen Sollte es den noch gelingen eine M glichkeit zu finden um Ports grafisch darzustellen w re dies ein gro er Vorteil da dem Modellierer die Ports in einer bersichtlichen und leicht ver st ndlichen Weise pr sentiert w rden Ziel f r ein solches Konzept sollte es sein w h rend des Modellierungsvorgangs auf einfache Weise zu erkennen welche Ports verket tet werden k nnen d h kompatibel zueinander sind Ausf hrung transaktionaler Prozesse Im Abschnitt 10 4 wurden Vorschl ge gemacht wie sich Proze
274. ie end verarbeiten kann 10 2 4 Aufruf von Services Im Abschnitt 6 1 3 wurden die Vorteile aufgef hrt die sich aus einer dynamischen Komponentenbindung ergeben Dabei sollen in den statischen Modellen grunds tzlich nur Interfaces angegeben werden die in den Prozessdiagrammen mit den Service Zust nden verkn pft werden Erst zur Laufzeit soll der Prozessinterpreter eine konkrete Implementierung finden die das Interface erf llt und die er f r die Ausf hrung des Service verwendet Um zu diesem Zweck verschiedene Mechanismen zu erlauben exis tiert das Interface ConnectorFactory interface IConnectorFactory createConnector name String IXMLConnector PropertyConnectorFactory createConnector name String IXMLConnector Abb 10 10 Verwaltung von Konnektorinstanzen Der Interpreter ruft die Methode createConnector auf wenn er f r die Ausf h rung eines Service eine Instanz des zugeh rigen Konnektors ben tigt Als einfachste M glichkeit zur Erzeugung einer solchen Instanz wurde von uns die Klasse Property ConnectorFactory realisiert Sie verwendet eine XML Konfigurationsdatei in der jedem Interface eine passende Klasse zugeordnet ist Um die Effizienz der Verwaltung von Konnektorinstanzen zu verbessern k nnte eine Art Pool angelegt werden Wenn der Interpreter einen Konnektor ben tigt w rde dann zun chst im Pool nachgesehen ob sich bereits eine passende Instanz darin befindet
275. ielmehr in einer bestimmten Reihenfolge vorgenommen werden weil der Ausgangsport vieler Zust nde von den Ports der Vorg ngerzust nde abh ngt Aus diesem Grund werden zun chst die Ports des Startzustands berechnet weil dieser keine Vorg nger hat und dann sukzessive durch Breitensuche alle anderen Zust nde abgearbeitet Da in der Modellierungsphase das Diagramm unter Umst nden noch nicht vollst ndig erstellt ist kann es neben dem Start zustand noch andere Zust nde geben die ebenfalls keine eingehenden Transitionen be sitzen und daher bei der Breitensuche so nicht erreicht w rden Darum beginnt die Breitensuche nicht nur beim Startzustand sondern bei allen Zust nden deren Ein gangsgrad gleich null ist siehe Zeile 1 des folgenden Pseudocodes Die folgende Ab bildung zeigt den implementierten Algorithmus in vereinfachter Form als Pseudocode 158 Kapitel 7 Metamodell f r Prozessdiagramme propagatePorts 1 queueOfStates processDiagram getIndegree_0_States 2 setOfVisited 3 while not queueOfStates isEmpty 4 state queueOfStates dequeue state inputPort state calculateInputPort state outputPort state calculateOutputPort setofVisited setOfVisited U state listOfSuccessors state getSuccessors while listOfSuccessors hasMoreElements if state outputPort has been modified or successor not in setofVisited and successor not in queueOfStates then queueOfS
276. ierungswerkzeug erfasst und pr sentiert ag A Symbol wE A InputPort componentConnector pu t Name OutputPort serviceName S Tag image Stereotyp service Typ UML DataTypes Geometry Multiplizit t 0 1 Erl uterung Angabe eines Symbols das f r den Service im Falle eines Aufrufs in einem Prozessdiagramm benutzt werden kann Tag inputPort Stereotyp service Typ ProcessDiagrams Port Multiplizit t 1 Erl uterung Dieser Port spezifiziert die Menge von Dokumenten die der zugeh rige Service verarbeiten kann Tag outputPort Stereotyp service Typ ProcessDiagrams OpenPort Multiplizit t 1 Erl uterung Dieser Port spezifiziert eine Menge von Dokumenten die alle m glichen Ausgabedokumente dieses Service enth lt Tab 7 4 Definition des Stereotyps service Prozessdiagramme Da ein Prozessdiagramm ein spezielles Aktivit tendiagramm darstellt wird hierf r ein eigenes Stereotyp definiert dem jedes Diagramm entsprechen muss Als Basisklasse dient das UML Meta Element ActivityGraph Um die Forderung zu erf llen dass jedes Prozessdiagramm jeweils genau einen Start und Endzustand hat siehe Abschnitt 3 3 Punkt 2 sind dem Stereotyp entsprechende Constraints zugeordnet Bei der Festlegung der notwendigen Sprachkonstrukte wurde gefordert dass Prozesse bzw Teilprozesse als Transaktionen modelliert werden k nnen siehe
277. ietet sondern es die Aufgabe des Prozesseditors ist zur Ausf hrungszeit eine geeignete Klasse zu finden Im Abschnitt 10 2 4 wurde erw hnt dass bislang eine recht einfache Variante zum Einsatz kommt bei der in einer XML Datei jedem Interface das in den Prozessdiagrammen als Konnektor verwendet wird eine implementierende Klasse zugeordnet ist Als Alternative ist es auch denkbar dass statt einer solchen festen Zuordnung der Interpreter dynamisch zur Laufzeit anhand der Schnittstelle die durch das Interface spezifiziert wird eine passende Klasse sucht Seit einiger Zeit existiert die von Sun Microsystems entwickelte Technologie Java Intelligent Network Infrastructure Jini Laut JinO1 ist Jini entwickelt worden um eine Infrastruktur f r dynamische Dienste in Netzwerken zur Verf gung zu stellen Ein Dienst ist dabei als Software oder auch Hardwarekomponente mit einer bestimm ten Funktionalit t zu verstehen Dienste K nnen sich selbstst ndig beim Jini System an und abmelden Bei der Anmeldung werden sie in einem speziellen Verzeichnis regist riert um ihre Funktionen anderen Teilnehmern des Systems anzubieten Wenn ein Teil nehmer einen Dienst in Anspruch nehmen m chte so spezifiziert er diesen in Form eines Interface das der Dienst erf llen soll und bermittelt diesen Wunsch an das Jini System Anhand des Verzeichnisses aller zur Zeit angemeldeten Dienste wird nun ein passender Dienst gesucht Bei erfolgreicher Suche wird eine Ver
278. ignet So erf llt ein Konnektor in der Regel nur die Br ckenfunktion f r eine ganz bestimmte Kompo nente Soll vom WFMS eine andere Komponente eingebunden werden ist es in den meisten F llen n tig eine neue Konnektorklasse zu implementieren Dabei lassen sich 6 1 Konzeption von XML Prozessen 81 spezielle Teile wie die Verarbeitung des WFMS Datenformats durch Generalisierung und Vererbungsstrukturen wiederverwenden so dass der Aufwand zur Erstellung des Konnektors minimiert wird Hervorzuheben ist auch dass ein einmal realisierter Kon nektor an vielen Stellen und auch in mehreren Workflow Modellen zur Integration seiner zugeh rigen Komponente benutzt werden kann Trotzdem ergibt sich ein nicht zu vernachl ssigender Wartungsaufwand Wird n mlich die Schnittstelle der Software komponente ver ndert dann muss auch der zugeh rige Konnektor entsprechend ange passt werden vgl Gru01 S 5 ber das Konzept der Konnektoren l sst sich f r jede Aktivit t des Workflows eine bestimmte Komponente aus den existierenden Softwaresystemen einbinden Neben den vorhandenen einzelnen Softwarekomponenten sollen aber auch bereits definierte Workflow Modelle als Aktivit ten innerhalb eines Prozesses aufgerufen werden k n nen Die so entstehende Hierarchisierung hilft bei der Handhabbarkeit komplexer Pro zesse und unterst tzt bei der Wiederverwendung bestimmter Teilprozesse die dann als Prozess Bausteine in einem bergeordneten Prozess eingesetz
279. im Workflow Management System stattf nde 6 2 3 Transitionen als XML Dokumentfluss Jedes Prozessdiagramm erh lt bei seiner Ausf hrung ein XML Dokument als Eingabe Dieses wird entsprechend dem Prinzip der Dokumentmigration der Reihe nach durch alle Zust nde des Diagramms gereicht Auf diese Weise entsteht ein impliziter Daten fluss des Dokuments durch den Prozess der Datenfluss muss nicht explizit durch die daf r gebr uchlichen Konstrukte der UML Aktivit tendiagramme wie Objektfluss 6 2 Modellierung mit Prozessdiagrammen 89 zust nde modelliert werden Jede Kontrollfluss Transition des Diagramms bedeutet vielmehr neben der Kontrollfluss Abh ngigkeit gleichzeitig einen Objektfluss den man auch mit den Sprachelementen Objektfluss und Objektfluss Zustand h tte modellieren k nnen wobei ein Objekt das XML Dokument von einer Aktivit t geschrieben und von der n chsten gelesen wird Die implizite Abbildung des Datenflusses und der Verzicht auf die Verwendung von Objektfluss Konstrukten stellt zwar eine Modifikation der bisherigen UML Semantik dar f hrt daf r jedoch zu einer beachtenswerten Vereinfachung der Modellie rung und zu einer besseren Verst ndlichkeit der Prozessdiagramme 6 2 4 Guard Bedingungen Damit der Kontrollfluss eines Prozesses dynamisch beeinflusst werden kann muss es m glich sein auf das XML Dokument oder die Prozessumgebung siehe Abschnitt 6 2 2 zuzugreifen um bestimmte Bedingungen zu pr fen Dies
280. immt der Prozessinterpreter die m glicherweise ver nderten XML Daten wieder entgegen bestimmt den Folgezustand und reicht das XML Dokument nach dorthin weiter Es ist denkbar dass eine Komponente und damit auch der zugeh rige Konnektor nicht nur eine sondern mehrere verschiedene Operationen bzw Services anbietet Jeder Service entspricht einer eigenen Methode des Konnektors In einem Aktivit tszustand wird genau einer der m glichen Services ausgef hrt Die Semantik eines solchen Zustandes ist es also dass zun chst eine Objektinstanz der Konnektorklasse f r die gew nschte Softwarekomponente gefunden bzw falls n tig neu erzeugt und dann darauf die passende Methode aufgerufen wird die den Service repr sentiert Dabei werden Werte f r die vom Service geforderten Parameter bergeben F r jeden Service eines Konnektors kann man im statischen Modell eine grafi sche Darstellung festlegen die im Diagramm anstelle des Standardsymbols f r jeden Aktivit tszustand verwendet wird in dem der jeweilige Service genutzt wird 6 2 2 Parametrisierung von Komponenten In vielen F llen werden beim Aufruf eines Service Parameterwerte zu bergeben sein Dies k nnen im Falle einer E Mail Komponente Empf ngeradresse Betreffzeile und Inhalt der Nachricht oder im Falle einer Datenbank Komponente eine SQL Anweisung sein Sie m ssen in den Aktivit tszust nden des Diagramms angegeben werden Im Zusammenhang mit XML Prozessen sind drei M glichkeiten
281. in Da explizite Aussagen ber zeitliche Aspekte in unserem Bereich der Prozessmodellierung jedoch nicht von zentraler Bedeutung sind vgl Abschnitt 3 4 wird an dieser Stelle auf eine detaillierte Einf hrung geeigneter Sprachkonstrukte verzichtet F r eine tiefergehende Darstellung von Zeitmodellierung sei auf Ajm95 ber stochastische Petri Netze verwiesen Bei der pr zisen Spezifikation realer Systeme werden Petri Netze h ufig gro komplex und damit un bersichtlich Daher ist es beraus sinnvoll eine Art Hierarchie bzw Schachtelung von Netzen zu erlauben Hinter einer einzelnen Transition oder auch Stelle kann sich dann ein Subnetz verbergen Dabei handelt es sich um ein eigenst ndi ges Petri Netz das eine Teilaufgabe beschreibt die ausgef hrt wird wenn sich Marken in der Stelle des bergeordneten Netzes befinden bzw die Transition schaltet Diese M glichkeit der Schachtelung hilft nicht nur dabei Netze bersichtlich zu halten son dern erlaubt auch die logische Gliederung eines Prozesses in Teilprozesse 5 1 3 Gesch ftsprozessmodellierung mit Petri Netzen Das Ziel von Workflow Management Systemen ist die Definition Kontrolle und Aus f hrung von Arbeitsabl ufen Da Petri Netze ein bekanntes Mittel zur Beschreibung von Prozessen sind gibt es eine Reihe von Gr nden Petri Netze zur Modellierung von Gesch ftsprozessen einzusetzen vgl Aal97 54 Kapitel 5 Evaluierung vorhandener Workflow Modellierungssprachen
282. in so dass sie auf beliebige XML Dokumenttypen anwendbar sind oder nur bestimmte Unter elemente in der Eingabe erfordern Der Quellport des Transitionstyps m sste in einem solchen Fall wohl mit einem any Platzhalter gekennzeichnet werden Da hnlich wie bei den Services der Ausgangsport m glichst klein sein und ein any dort vermieden werden sollte k nnen auch f r Ausgangsports von Transitionstypen offene Ports mit den Platzhaltern copyRoot und copySubs benutzt werden Diese werden dann im Kontext des Prozessdiagramms an den Ausgangsport des vorausgehenden Zustands gebunden Abbildung 6 23 verdeutlicht diese Zusammenh nge noch einmal Sie zeigt ein einfaches g ltiges Prozessdiagramm mit den Definitionen der benutzten Kom ponenten im statischen Modell und schematisiert alle vorkommenden Ports Die ge strichelten Pfeile zeigen an welchen Port ein offener Port jeweils gebunden wird Die Bindung an den Vorg nger kann sich ber mehrere Zust nde r ckw rts fortsetzen Sp testens der Startzustand des Prozesses hat jedoch einen Ausgangsport der nicht offen ist und bei dem die Bindungen verankert werden k nnen Wie in dem K stchen angegeben bilden die Teilport Beziehungen und die durch das statische Modell per Stylesheet oder Service definierten berg nge zusammen eine konsistente Migrations kette vom Start zum Endzustand 108 Kapitel 6 XML Prozesse und Prozessdiagramme Typt Be Stylesheet e i EN es A Statisches Model a
283. ines Join Zustands alle eingehenden getriggert werden Beginnend beim Startzustand eines Diagramms wird dies nun iterativ durchge f hrt bis der Endzustand erreicht ist In diesem Augenblick gilt die Ausf hrung des Diagramms als beendet Diese von der UML Spezifikation vorgeschlagene Ausf hrungssemantik ist laut WieOl im Zusammenhang mit Workflow Management Systemen problematisch Das liegt daran dass die UML Spezifikation davon ausgeht dass mit einem Aktivit ten diagramm ein Softwaresystem spezifiziert wird das selbst die Aktion der Zust nde aus f hrt Innerhalb eines sogenannten run to completion step werden die Aktionen aller aktiven Zust nde ausgef hrt Erst wenn dies beendet ist beginnt der n chste run to completion step In Workflow Management Systemen liegen jedoch andere Voraus setzungen vor Das WFMS ist lediglich f r die korrekte Abhandlung des Kontrollflusses 212 Kapitel 10 Ausf hrung von XML Prozessen zust ndig die Ausf hrung der Aktionen selbst delegiert es an die daf r zust ndigen Akteure in unserem Fall die Softwarekomponenten Vereinfacht gesagt besteht die Aufgabe des WFMS in der Ausf hrung der Transitionen eines Diagramms die der Akteure in der Ausf hrung der Aktionszust nde Um diesen Sachverhalt zu verdeut lichen wird in WieOl folgendes Beispiel verwendet Aktion 1 Aktion 2 Abb 10 1 Beispiel zur Semantik von Aktivit tendiagrammen Nach der UML Spezifikation werden die beiden Akti
284. ines abgebrochenen Prozesses ohne jeweilige Angabe einer Kompensa tionsprozedur In den einzelnen Aktionen des Workflows werden vorhandene Softwarekompo nenten aufgerufen Die Einbindung von Benutzerinteraktionen ist dabei nicht explizit vorgesehen sie Kann aber sicher dadurch realisiert werden dass eine aufgerufene Kom ponente intern mit einem Benutzer interagiert 4 2 Komponentenkonfiguration mit WARP Der von Brian Blake in Bla00 vorgestellte Ansatz WARP Workflow Automation through Agent based Reflective Processes behandelt ein agentenbasiertes System zur Konfiguration und Integration von verteilten Softwarekomponenten durch die Modellie rung und Ausf hrung von Workflows Blake sieht sein Konzept im Kontext der sich stark fortentwickelnden Komponententechnologie die seiner Meinung nach gro e Auswirkungen auf die zuk nftigen Softwareentwicklungsprozesse haben wird Dem nach wird es in Zukunft m glich sein Software einfach durch Anordnung und Konfigu ration existierender Komponenten ggf als Softwarebausteine von Dritten angeboten in einer bottom up Vorgehensweise zusammenzusetzen vgl Bla00 S 1 Ein zentraler Vorteil ist dabei die vermehrte Wiederverwendbarkeit der einzelnen Java Beans Klassen und Module die jeweils Teilaufgaben bernehmen Eine gute M glichkeit diese Bausteine miteinander zu verbinden ist die Definition eines Workflows der von autonomen Agenten ausgef hrt werden kann Mit WARP hat Blake ein solch
285. ing bindTo DocType DocType Constraints self root size self placeholder size 1 dataType DocType Constraints self root isEmpty implies placeholder ocllsTypeOf AnyPlaceholder lt xsd complexType name DoctypeType gt lt xsd sequence gt lt xsd choice gt lt xsd element name root type ElementType gt lt xsd element name any type AnyType gt lt xsd choice gt lt xsd element name sub type ElementTyp minOccurs 0 maxOccurs unbounded gt lt xsd sequence gt lt xsd complexType gt lt xsd complexType name OpenDoctypeType gt lt xsd sequence gt lt xsd choice gt lt xsd element name root type ElementType gt lt xsd element name any type AnyType gt lt xsd sequence gt lt xsd element name copyRoot type CopyRootType gt lt xsd element name copySubs type CopySubsType minOccurs 0 gt lt xsd sequence gt lt xsd choice gt lt xsd element name sub type ElementTyp minOccurs 0 maxOccurs unbounded gt lt xsd sequence gt lt xsd complexType gt Abb 8 7 PML Schema Fragment f r Dokumenttypen 8 3 Process Markup Language PML 175 Abbildung 8 8 zeigt zur Verdeutlichung beispielhaft die Beschreibung zweier Doku menttypen lt doctype gt lt root element root1l namespace lt sub element child1 namespace lt sub element child2 namespace lt doctype gt lt doctype gt
286. ingabemasken des Editors sind zwei Ereignisse relevant das Bet tigen der Save und der Reset Schaltfl che vgl Abschnitt 9 2 3 Im Falle von Reset kann einfach die Methode updateview aus ServicePanelView aufgerufen werden da sie die Daten des Service neu aus dem Datenmodell liest und 208 Kapitel 9 Modellierungswerkzeug f r Prozessdiagramme etwaige Benutzereingaben in der Maske berschreibt Im Falle von Save hingegen erfolgt ein Aufruf von saveInput um die Eingaben ins Datenmodell zu bernehmen Zuvor findet eine berpr fung aller Benutzereingaben mittels inputIsConsistent statt Nur wenn keine Inkonsistenzen gefunden wurden k nnen die Daten gespeichert werden ansonsten erscheint eine entsprechende Fehlermeldung die den Benutzer auf Eingabefehler hinweist 9 3 3 Die Prozesszeichenfl che Im Abschnitt 9 2 5 wurde die Prozesszeichenfl che beschrieben in der alle Zust nde und Transitionen eines Prozessdiagramms grafisch dargestellt werden Zust nde k nnen zudem mit der Maus beliebig verschoben werden Im Sinne des MVC Konzepts handelt es sich bei der grafischen Darstellung der Modellelemente um eine zus tzliche View Komponente neben der Eingabemaske so dass solche Elemente also zwei verschiedene Repr sentationen in der Benutzungsoberfl che haben Abbildung 9 15 zeigt die not wendigen Klassen am Beispiel eines Service Zustands _ AbstractStateVertexAdapter
287. ion von parallelen Ausf hrungsstr ngen Erm glicht die Synchronisation zwischen verschie denen parallelen Ausf hrungsstr ngen Dient der Beschreibung welche Systemkomponente welche Aktivit ten ausf hrt Darstellung eines Objekts das von einer Aktivit t gelesen oder geschrieben wird Beschreibung des Datenflusses eines Objekts zwischen verschiedenen Aktivit ten Spezielle Aktivit t die zum Senden eines Signals an eine andere Aktivit t dient Spezielle Aktivit t die ein Signal von einer anderen Aktivit t empf ngt Tab 5 2 Elemente eines UML Aktivit tendiagramms Um explizit mehrere Ausf hrungsstr nge zu synchronisieren dienen Synchronisations zust nde Dabei kann eine ganze Zahl als Schranke f r die Differenz zwischen der Anzahl ausgel ster eingehender und ausgehender Transitionen angegeben werden oder ein Stern f r eine unbeschr nkte Differenz f r Details siehe Omg01 2 160 68 Kapitel 5 Evaluierung vorhandener Workflow Modellierungssprachen Abb 5 9 Synchronisation von parallelen Teilprozessen H ufig m chte man zus tzlich zum Kontrollfluss auch den Datenfluss in einem Aktivi t tendiagramm modellieren Dazu k nnen Objekte in das Diagramm eingef gt werden Von derjenigen Aktivit t die das Objekt erzeugt oder ndert wird ein ausgehender Objektfluss Pfeil zum Objekt gezogen Alle Aktivit ten die das Objekt lesen erhalten einen eingehenden Pfeil Es gibt dar ber hinaus einige
288. ird bei der Modellierung ein Gesch ftsprozess durch ein Flussdia gramm dargestellt siehe Moh01 S 27ff dessen Notation an die von UML Aktivit tendiagrammen angelehnt ist Die Modellierungssprache unterst tzt Konstrukte f r Sequenz Verzweigung Nebenl ufigkeit und Synchronisation siehe Mic00 S 8 und erlaubt damit die Definition eines flexiblen Workflow Modells Des Weiteren lassen sich Teilbereiche des Prozessmodells zu einer Transaktion zusammenfassen die atomar ausgef hrt werden soll Beim Entwurf der Workflows wird die Definition des Prozesses explizit von der zu Grunde liegenden Software getrennt In einer Art statischem Modell werden die vorhandenen Softwarekomponenten aufgef hrt und mit den einzelnen Prozessaktivit ten im dynamischen Modell verkn pft siehe Mic00 S 6 Dazu muss angegeben werden welcher Nachrichtenfluss zwischen den Aktionen bzw Komponen ten gew nscht wird Au erdem ist es m glich einen Prozess als Komposition von meh reren Teilprozessen darzustellen siehe Mic00 S 7 um dadurch die Komplexit t zu reduzieren und arbeitsteiligen Entwurf zu unterst tzen 4 1 Microsoft BizTalk Server 2000 39 TITTTT77 ad 3 rte n o tPA AR ar T Abb 4 1 Ansicht des BizTalk Orchestration Designer aus Mic00 S 6 Nach der Fertigstellung eines Workflow Modells wird das Modell in das XML Format XLANG umgewandelt und abgespeichert vgl auch Abschnitt 8 2 1 Damit liegt eine Workflow Beschreibung in XML vor
289. ist zu ber cksichtigen dass diese in der Lage sein m ssen die Arbeit der urspr nglichen Instanzen fortzuf hren oder r ckg ngig zu machen 3 Falls der Ausfall in der sogenannten Commit oder Abort Phase stattgefunden hat d h w hrend der Interpreter damit besch ftigt war alle Services ber Erfolg oder Scheitern des transaktionalen Prozesses zu benachrichtigen kann das Drei Phasen Commit Protokoll zum Einsatz kommen siehe Hei00B 6 47ff Es wurde dazu entwickelt um speziell den Ausfall des Transaktionsverwalters in verteilten Syste men zu behandeln 4 F r den Einsatz des Drei Phasen Commit Protokolls ist es notwendig dass sich alle Teilnehmer einer Transaktion in unserem Fall die Services untereinander kennen und kommunizieren k nnen Diese F higkeit wird dazu verwendet um die Commit oder Abort Entscheidung die einige Services schon erhalten haben k nnten bevor der Systemausfall stattgefunden hat auch den brigen mitzuteilen Bei XML Prozessen existiert bislang jedoch kein Mechanismus mit dem die ein zelnen Services eines Prozesses untereinander Nachrichten austauschen k nnen 5 Falls der Prozessinterpreter ausf llt befinden sich m glicherweise die Back End Systeme die durch Services angesprochen wurden in einer Art Ungewissheits situation da sie auf ein Commit oder Abort warten Dieser Zustand kann je nach Gegebenheit nicht ber l ngere Zeit toleriert werden was vom Drei Phasen Commit Protokoll dur
290. it besch ftigen denn hier soll es gerade ein Hauptzweck der Workflow Modelle sein die Integration der existierenden Softwarekomponenten zu f rdern 2 3 Modellierung von Prozessen 17 2 3 Modellierung von Prozessen Soll die Ausf hrung von Informationsprozessen durch Software unterst tzt oder ganz vorgenommen werden muss zun chst eine Modellierungs und Analysephase voraus gehen siehe Wen00 S 8 In der Modellierungsphase werden die Prozesse in einer semi formalen Darstellung zu einem Modell abstrahiert Ein statisches Organisations modell hilft bei der Findung und Zuweisung geeigneter Aufgabentr ger Bei der Analyse werden die Prozessmodelle auf m gliche kritische Pfade Engp sse Durch laufzeiten und Inkonsistenzen untersucht 2 3 1 Organisationsmodellierung und statische Modelle Im Zusammenhang mit der Modellierung ist neben der Definition der Workflow Modelle auch eine Organisationsmodellierung durchzuf hren mit der strukturelle funktionelle und technische Aspekte siehe B h95 S 4 der Organisation festgehalten werden die die Prozesse ausf hren soll Die Organisationsstruktur muss beschrieben werden damit das WFMS eine Zuordnung der einzelnen Aktivit ten eines Workflows an einen Bearbeiter vornehmen kann F r Mensch orientierte Prozesse werden in den strukturellen Modellen vor allem Akteure Organisationseinheiten Gruppen Stellen und Rollen spezifiziert und miteinander verkn pft Das Konzept der Stellen und
291. ite befinden sich je ein Feld f r den Eingangs und Ausgangsport des Service Zu ihrer Bedienung siehe Abschnitt 9 2 4 Jede Eingabe maske enth lt ganz unten zwei Schaltfl chen Save und Reset Beim Bet tigen von save werden alle Eingaben aus der Maske in das Workflow Modell bernommen Mit Hilfe von Reset lassen sich die vorgenommenen nderungen zur cksetzen und der Ausgangszustand der Maske wieder herstellen Es ist zu beachten dass alle nderungen verloren sind wenn im Projektbaum eine andere Komponente ausgew hlt wird ohne vorher durch Bet tigen von Save die Eingaben zu speichern 9 2 4 Eingabe von Ports Immer wenn eine Komponente einen Port besitzt wird dieser in der Eingabemaske durch folgendes Feld dargestellt Input Port any httpsfexample upb de elementi a http fexample upb de element element3 element4 Details Delete Abb 9 4 Eingabefeld eines Ports In der wei en Fl che sieht man eine Liste aller Dokumenttypen des Ports in der aus Abschnitt 6 3 bekannten Syntax Ein neuer Dokumenttyp l sst sich hinzuf gen indem man die Schaltfl che Add ausw hlt Es erscheint dann der in Abbildung 9 5 darge stellte Eingabedialog Wenn in der Liste ein Dokumenttyp mit der Maus ausgew hlt wurde l sst er sich entweder durch Details bearbeiten es erscheint dann ebenfalls der Dialog aus Abbildung 9 4 oder durch Delete aus dem Port entferne
292. itzen Daraus ergibt sich der folgende Hilfssatz der sp ter beim Beweis des Kompatibilit ts Satzes benutzt wird Lemma 6 6 y doc e XmiIDocs Y type root subs e DocTypes doc e L type amp subs c c doc A root r doc v root eAnyPlaceholder Beweis 1 Fall root e AnyPlaceholder doc e L type amp doce JL x subs xe XmlElements amp 3x e XmilElements doc e L x subs amp r doc x a subs c c doc 2 Fall root amp AnyPlaceholder doc e L type amp r doc root 1 subs c c doc Mit den bisherigen Definitionen von einzelnen XML Elementen bis hin zu Dokument typen steht uns nun das n tige R stzeug zur Verf gung um in der folgenden Definition zu bestimmen was wir unter einem Port bzw der Menge aller Ports verstehen wollen Def 6 7 Die Menge aller Ports Ports types types c DocTypes P DocTypes Ein Port pe Ports ist somit einfach eine Teilmenge der Menge DocTypes also eine Menge von Dokumenttypen Syntax Ein Element aus Ports wird durch Ableitung des Nicht Terminals Port der EBNF Grammatik notiert Das entspricht im Wesentlichen einer durch Kommata getrennten Auflistung der enthaltenen Dokumenttypen Die Menge der zu einem Port konformen XML Dokumente wird wiederum durch eine Funktion L als Vereinigung ber alle enthaltenen Dokumenttypen definiert Def 6 8 Dokumentmenge eines Ports L Ports gt P XmIDocs vpe Ports L p JL tep L p hei t Dokumentmenge vom Port p 6
293. k hoher Wiederverwendbarkeit der Modellierungsaufwand reduziert Die textuell codierte Speicherung der Prozessmodelle gem 3 2 Anforde rung 6 erfolgt durch die Erzeugung einer Prozessbeschreibungsdatei in der XML Spra che PML Process Markup Language die eigens zur textuellen Repr sentation von Prozessdiagrammen in Abschnitt 8 3 definiert wurde Im Gegensatz zu anderen in Ab schnitt 8 2 vorgestellten XML basierten Ans tzen wie XLANG und XMI erlaubt PML das Abspeichern der vollst ndigen Prozessdiagramme in einem f r menschliche Benut zer gut lesbaren Format ist f r spezielle Anwendungen und Werkzeuge flexibel erwei terbar und kann direkt als Grundlage f r die automatische Ausf hrung der Prozesse benutzt werden wie dies bei dem in Abschnitt 10 2 vorgestellten Prozessinterpreter der Fall ist Vorteil der XML basierten Speicherung ist die M glichkeit zur Konvertierung mit Stylesheets in andere Formate wie XMI zur Verarbeitung mit anderen Werkzeugen sowie eine gute Austauschbarkeit ber das Internet Im dritten Teil der Diplomarbeit wurden die Resultate der praktischen Umset zung dokumentiert Entstanden ist dabei ein ganzheitliches System zur Modellierung und Ausf hrung der XML basierten Workflows Zur Erstellung und Verwaltung von Prozessdiagrammen wurde ein grafisches Modellierungswerkzeug siehe Kapitel 9 entwickelt mit dem sich die statischen und dynamischen Teile der Prozessmodelle spe zifizieren lassen Ein Algorithmus zur V
294. kann h tte dies allerdings zur Folge dass unter Umst nden nach jeder Aktivit t im Prozessdiagramm ein XML Dokument mit diesem Fehlerelement vorliegen kann und von den nachfolgenden Aktivit ten weiterverarbeitet werden muss Als Folge enthielten alle Ports des Diagramms dieses Fehlerelement so dass man es aufgrund des strengen Port Konzepts bei allen Transitionstypen Style sheets etc ber cksichtigen m sste auch wenn gerade der Einbau einer speziellen Fehlerbehandlung nicht sinnvoll w re Darum haben wir f r unsere Implementierung kein fixes Fehlerelement vordefi niert das alle Ausnahmen aufnehmen kann sondern berlassen es dem jeweiligen Modellierer und Entwickler der Konnektoren Java Ausnahmen durch spezielle indivi duell definierte XML Elemente im Migrationsdokument zu repr sentieren die im weiteren Prozessverlauf zu einer besonderen Fehlerbehandlung f hren 228 Kapitel 10 Ausf hrung von XML Prozessen 10 4 Transaktionale Prozessausf hrung Nachdem im letzten Abschnitt berlegungen zur Behandlung von Fehlern w hrend der Ausf hrung eines Prozessdiagramms gemacht wurden soll hier speziell auf Transaktio nen eingegangen werden Wie in Abschnitt 7 3 2 erw hnt wurde l sst sich ein Prozess oder Subprozess als transaktional definieren Im Folgenden soll die Semantik dieser Festlegung betrachtet werden Da sich das Thema Transaktionen als sehr umfangreich und komplex darstellt haben wir aus Zeitgr nden darauf verzichtet
295. kapselte Anwei sung dann auszuf hren Den Eingangsport dieses Service k nnte man durch den Platz halter any in Verbindung mit dem Subelement wie folgt spezifizieren any http namespace sqlStatement Konform zu diesem Port sind somit alle XML Dokumente die irgendwo an beliebiger Stelle das lt sqlStatement gt Element enthalten so dass der Service eine entsprechende Aktivit t durchf hren kann 96 Kapitel 6 XML Prozesse und Prozessdiagramme Notation von Ports Zusammenfassend besteht ein Port also aus einer Menge von Dokumenttypen die leere Menge als Q wobei jeder Dokumenttyp durch die Angabe eines Wurzelelements und einer Liste obligatorischer Unterelemente die leere Liste als spezifiziert wird Jedes XML Element wird durch seinen Namen und einen Namensraum bestimmt F r das Wurzelelement kann auch der Platzhalter any verwendet werden Somit ergibt sich unter Verwendung der erweiterten Backus Naur Form EBNF vgl ISO96 die fol gende Grammatik f r die Notation eines Ports Port Doctype f Doctype Doctype Root Element T Root any Element Element Namespace Name Namespace character Name character Abb 6 7 EBNF Grammatik f r Ports Beispiele f r Ports sind somit etwa a http namespace1 elemA http namespace1 elemB http namespace2 elemC http namespace1 elemC b any c any http namespace1 sqlSt
296. kflows macht eine Anwendung des Transaktionskonzepts dagegen m glicherweise Sinn In B h95 wird allerdings in die sem Zusammenhang festgestellt Die in Datenbankanwendungen seit Jahrzehnten etablierten Techniken haben bei WFMS noch bei weitem nicht die Verbreitung wie es notwendig w re um bestimmte Eigenschaften bei der Ausf hrung von Vorg ngen zuzusichern Die Zusicherung von Atomarit t bedarf einer M glichkeit gescheiterte Vor g nge zur ckzusetzen und ihre Wirkung r ckg ngig zu machen Diese Aufgabe gestal tet sich f r ein WFMS sehr schwierig besonders wenn f r die Erf llung von Teil aufgaben vorhandene Softwaresysteme eingesetzt werden F r das R cksetzen eines transaktionalen Workflows w re es n tig dass auch alle angesprochenen Software komponenten eine Undo Operation unterst tzen und ihre jeweilige Teilaufgabe r ck g ngig machen k nnen vgl Geo95 S 138 Noch 1995 kommt man in Geo95 zu der Feststellung No commercial WFMSs we are aware of offers significant support for workflow recovery Dies mag sich inzwischen ge ndert haben es macht jedoch deut lich wie schwierig die Gew hrleistung von Transaktionseigenschaften f r Workflows ist 2 2 3 Integration existierender Anwendungen Das Modell eines systemorientierten Prozesses muss die einzelnen Prozessaktivit ten zwecks automatisierter Ausf hrung existierenden Applikationen sog legacy applica tions oder Softwarekomponenten zuordnen Dami
297. klassifiziert wird erh lt dann alle diese zus tzlichen Eigenschaften Mit einem Stereo typ erweitert man in der Regel die vorhandenen Meta Elemente um ihnen eine neue Bedeutung im Kontext der Spracherweiterung zuzuweisen Im Abschnitt 7 3 2 zum Beispiel wird das Stereotyp serviceState benutzt um in einem Prozessdiagramm einem Zustandselement die Semantik einer komponenten basierten Aktivit t zuzuschreiben Da die Basisklasse dieses Stereotyps das Meta Element CallState ist erh lt eine Instanz des Stereotyps serviceState die Semantik des CallState Elements zus tzlich aber auch die f r das Stereotyp definierten Attribute und Nebenbedingungen Stereotypen kann man in einer Vererbungshierarchie strukturieren Dabei darf ein Stereotyp A nur von einem Stereotyp B erben wenn die Basisklasse von B der Basisklasse von A entspricht oder eine Unterklasse davon ist Das eine Stereotyp erbt dann alle Attribute Tagged Values und Bedingungen Constraints des anderen 128 Kapitel 7 Metamodell f r Prozessdiagramme 7 2 2 Tag Definitions und Tagged Values Um Stereotypen mit Attributen zu versehen wird der Mechanismus der sogenannten Tag Definitions in Verbindung mit den Tagged Values angeboten OmgOl 2 6 2 4 Mit ihnen lassen sich neben den Stereotypen auch andere Elemente des Metamodells um Pseudo Attribute erg nzen Auf den Wert eines Attributs der als Tagged Value gespeichert wird kann man dabei ber ein eindeutiges Schl sselwor
298. kuments siehe Abschnitt 8 3 3 ben tigt werden wie es bei den Koordinaten der Fall ist kann der Observer diese mit Hilfe der Methode getExtensions des Interpreter abfragen 8 4 2 PML Exporter Der PML Exporter dient dazu aus einem Prozessmodell das sich in Form einer Objekt struktur im Speicher befindet PML Beschreibungen zu generieren die dauerhaft gespeichert werden k nnen Es lassen sich sowohl einzelne Prozesse und Packages als auch ein gesamtes Prozessmodell exportieren Die internen Abl ufe des Exporters sind sehr technisch so dass im Folgenden nur grob die Arbeitsweise erl utert wird Abbil dung 8 22 zeigt die Klasse PMLExporter PMLExporter exportState state StateVertex Element exportService service Service Element 1 A observes 1 ExportObserver notifyState state StateVertex Element notifyService service Service Element Abb 8 22 Klassen PMLExporter und ExportObserver Die Klasse PMLExporter besitzt zu jeder Datenklasse aus Abschnitt 7 4 eine Methode die als Parameter eine Instanz der jeweiligen Datenklasse erh lt und als R ckgabewert 8 4 Werkzeuge f r die PML Verarbeitung 189 ein XML Element liefert das eine PML Beschreibung des Modellelements darstellt Beispielsweise konstruiert die Methode exportService aus einem Service Objekt die zugeh rige PML Beschreibung Der Exporter durchl uft in einer Tiefensuche die zu exportierenden Modellteile u
299. l das zusammen mit XML vom W3 Konsortium vorgestellte DTD Konzept Document Type Definition siehe XML00 Punkt 2 8 als auch der verabschiedete Standard XML Schema siehe XSchO1 erlauben die genaue Definition eines XML Dokumenttyps durch Baum grammatiken siehe MakOl Die Produktionsregeln dieser Baumgrammatiken erlau ben die Ableitung hierarchisch aufgebauter XML Dokumente Als Nachfolgestandard des DTD Konzepts haben XML Schemata den Vorteil selbst ein XML Dokument zu sein das mit XML Werkzeugen verarbeitet werden kann Au erdem erlauben sie die Benutzung einer gr eren Menge von Grunddatentypen und sind mit Vererbungs und Spezialisierungskonstrukten an objekt orientierte Konzepte angelehnt Daher wollen wir uns in dieser Arbeit auf die Anwendung von XML Schemata konzentrieren Die Vali dierung konkreter XML Dokumente gegen das Schema f r das sie erstellt wurden stellt eine Standardfunktion zahlreicher XML Werkzeuge und Parser dar Das WFMS kann diese Werkzeuge nutzen um zur Laufzeit eine Validierung der zu verarbeitenden XML Dokumente durchzuf hren In einem XML Schema wird eine Menge von XML Elementen definiert F r unsere Betrachtung sind davon nur die sogenannten globalen Elemente siehe XSchOl Punkt 2 2 2 relevant da nur sie als Wurzelelement eines Dokumentes benutzt werden k nnen Globale XML Elemente sind durch die Angabe einer URL f r ihren Namens raum und ihren Elementnamen eindeutig bestimmt siehe XSch01 Punkt
300. lasse AbstractModelElementAdapter verwendet werden da UML StateAdapter bereits eine Oberklasse besitzt und nicht zus tzlich davon erben k nnte Die Klasse hat daher eine eigene Referenz auf StateVertex Der Prozessinterpreter kann jedoch die Klasse AbstractStateAdapter nicht direkt als Repr sentation eines Prozesszustandes verwenden Es fehlt eine Methode execute die die Aktionen ausf hrt die zu einem bestimmten Prozesszustand geh ren Diese Aktionen sind in hohem Ma e abh ngig vom Typ des Zustandes d h ob es sich um einen Service Fork oder anderen Zustand handelt Aus diesem Grund wird zus tzlich das Entwurfsmuster Bridge verwendet Dieses Muster dient dazu eine Abstraktion hier AbstractState von seiner Implementierung hier AbstractState Adapter zu trennen und beide unabh ngig voneinander vererben zu K nnen vgl Gam96 S 186 Auf diese Weise k nnen sowohl Unterklassen f r die verschiedenen Zustandstypen gebildet werden als auch die M glichkeit beibehalten werden wie oben beschrieben das zu Grunde liegende Datenmodell zu ver ndern Abbildung 10 4 zeigt die notwendigen Klassen AbstractState bietet so die passende Schnittstelle die der Pro zessinterpreter zu einem Zustand ben tigt 10 2 Der Prozessinterpreter 219 AbstractState AbstractStateAdapter getFollowing AbstractState 1 1 getFollowing AbstractState validatelnputPort boolean valida
301. lb des Microsoft BizTalk Systems verwendet um die modellierten Workflows in einer maschinell interpretierbaren Form zu speichern Laut Tha01 handelt es sich bei XLANG um eine XML basierte Sprache zur Spezifikation des Nachrichtenaustausches zwischen interagierenden Webservices Sie ist vor allem als Basis f r die automatisierte Ausf hrung von unternehmens bergreifenden Gesch ftsprozessen gedacht Dabei liegt das Augenmerk auf der Modellierung des nach au en hin sichtbaren Verhaltens durch den Austausch von Nachrichten nicht jedoch die internen Verarbeitungsschritte der beteiligten Komponenten XLANG stellt eine Erweiterung der Web Service Description Language WSDL siehe WSDLO1 dar WSDL wurde vom W3 Konsortium entwi ckelt um die externen Schnittstellen von Netzwerkdiensten d h insbesondere Web services spezifizieren zu k nnen W hrend durch eine WSDL Beschreibung lediglich angegeben wird welche Operationen ein Webservice anbietet bzw welche Nachrich tentypen er verarbeitet kann erg nzt XLANG eine solche Spezifikation um die Beschreibung der Abfolge verschiedener Nachrichten Auf diese Weise wird ein Proto koll festgelegt das die komplette Interaktion mit einem Webservice bestimmt Zwar geht es bei den in dieser Arbeit betrachteten XML Prozessen nicht um die Integration von Webservices die verwendeten Softwarekomponenten k nnten jedoch prinzipiell als Webservices interpretiert werden Bei der folgenden Beschreibung der wichtigsten
302. le Beschreibung der Prozesse in einer formalen Workflow Sprache k me der Programmie rung der Workflows gleich und widerspricht der Intention die Aufgabe der Modellie rung m glichst einfach zu gestalten Laut Aal97 erleichtert eine visuelle Modellie rungssprache nicht nur das Lernen und Verstehen der Modelle sondern verbessert auch die M glichkeit sie unter Umst nden sogar mit Laien zu diskutieren Aus diesem Grund ist es auch w nschenswert dass zur Modellierung eine Sprache benutzt wird die bereits weitl ufig bekannt ist oder sich als Industriestandard etabliert hat so dass mit gr erer Akzeptanz bei den Anwendern gerechnet werden kann Darum wurde in der vorliegenden Arbeit keine vollst ndig neue Sprache entworfen sondern bestehende Modellierungssprachen mit den hier gestellten Anforderungen verglichen und auf ihre Tauglichkeit untersucht In Wmc95 wird ein Gesch ftsprozess als Folge von Aktivit ten definiert Die auszuw hlende Sprache sollte daher ablauforientiert sein damit sie mit dieser Defini tion harmoniert Zur Erf llung dieser Forderung bietet sich die Anwendung von Spra chen an die auf gerichteten Graphen basieren Mit ihnen lassen sich Kontrollfl sse beschreiben Als bekannte Vertreter dieser Gruppe von Modellierungsans tzen werden sp ter Petri Netze Ereignisgesteuerte Prozessketten und UML Aktivit tendiagramme n her vorgestellt siehe Kapitel 5 Des Weiteren sollen folgende Eigenschaften erf llt
303. legt werden Die Methode der EPK erf llt die Anforderungen visuell weitl ufig bekannt ablauforientiert und graphbasiert Als grafische Modellierungssprache mit zahlreichen symbolischen Repr sentanten f r Objekte Funktionen und Ereignisse erzeugt eine EPK ein sehr anschauliches und eing ngiges Bild von dem gew nschten Prozessablauf Da die Methode im Rahmen der stark verbreiteten betriebswirtschaftlichen Standardsoft ware SAP R 3 zur Modellierung von Unternehmensabl ufen benutzt wird ist sie vor allem im Bereich der betriebswirtschaftlichen Anwendung au erordentlich gut bekannt und quasi zu einem Industriestandard geworden vgl Wen00 S 36 Basierend auf dem Prinzip der Vorgangskettendiagramme ist die EPK graphbasiert und ablauforien tiert Ein besonderer Akzent liegt jedoch auf der Steuerung des Ablaufs durch Ereig nisse die jeweils explizit in die Modellierung der Prozesse einflie en m ssen Das Ein treten eines Ereignisses schafft die Voraussetzung f r das Ansto en der n chsten Auf gabe Bei den in dieser Arbeit anzufertigenden Workflow Modellen wird das Auftreten von Ereignissen keine so zentrale Rolle spielen Vielmehr gilt als Ausl se Ereignis f r eine Aktivit t in der Regel implizit die Beendigung der Vorg nger Aktivit t en vgl Abschnitt 10 1 Zur Modellierung der vier geforderten Kontrollflusskonstrukte Sequenz Ver 64 Kapitel 5 Evaluierung vorhandener Workflow Modellierungssprachen zweigung Schleife und P
304. licherweise die Erstellung neuer Services bedingen Die Softwarekomponenten geben nach Ausf hrung ihrer Funktionen die R ckgabewerte an die Services zur ck Die Services erf llen auf diese Weise die Aufgabe von Konnektoren zwischen dem WFMS und den existierenden Softwarekomponenten Der Routingmechanismus des WFMS beruht im Wesentlichen auf der Auswer tung des Prozesszustandes und des Dokumenttyps durch ein Regelwerk F r die Reali sierung dieses Regelwerks kommen verschiedene Ans tze von einer einfachen Liste ber ein XML Dokument bis zur Datenbank in Frage Es besteht aus einer endlichen Menge von Regeln die alle m glichen Kombinationen der Parameter beschreiben und jeweils auf die zugeh rigen Ausgabeparameter abbilden Die Definition der Regeln passiert also auf relativ technischer Ebene und kann bei gr eren Systemen schnell einen un berschaubaren Umfang annehmen vgl Abschnitt 11 1 Da eine Regel im Prinzip wie eine Zustandsmaschine f r einen Prozesszustand seinen nachfolgenden Zustand angibt k nnte man alternativ auch eine ablauforientierte Workflow Modellie rung vornehmen Eine visuelle Modellierungssprache f r Workflows wie sie in Kapitel 6 vorgestellt wird k nnte bei der Spezifikation der Abl ufe helfen Eine so aufgebaute E Business Plattform eignet sich um die Vorg nge zur Verarbeitung von eingehenden Dokumenten automatisiert durchzuf hren Jedes Eingangsdokument stellt dabei eine Anfrage an die vorhandenen Systeme
305. lows f r die bernahme einer Aktivit t eingesetzt werden Dabei muss in dem statischen Modell spezifiziert sein wie die Komponente bezeichnet wird wie sie angesprochen wird welche Funktionen sie zur Verf gung stellt und welche Parameter sie erwartet 18 Kapitel 2 Grundlagen des Workflow Managements 2 3 2 Vorgangsmodellierung und dynamische Modelle Nach der Spezifikation des Strukturmodells k nnen die dort aufgef hrten Aufgaben tr ger bei der Definition der Workflow Modelle benutzt werden Ein Workflow Modell in der Literatur auch als Vorgangstyp bezeichnet beschreibt nach B h95 zum einen die Ablaufreihenfolge der Aufgaben und zum anderen die einzelnen Aktivit tstypen Zu den wichtigsten Kontrollstrukturen f r die Beschreibung der Abl ufe z hlen laut B h95 die Konstrukte Sequenz Parallelit t und Verzweigung vgl Abschnitt 3 3 ber die Anforderungen an eine visuelle Prozessmodellierungssprache Zur Modellierung der Aktivit ten innerhalb der Abl ufe ist die Angabe der zugeh rigen Aufgabenbeschreibung und der zust ndigen Bearbeiter n tig Aktivit ten k nnen mit einer losen Kopplung an Anwendungsprogramme gebunden werden wenn ein Sachbearbeiter das Programm zur Erf llung der Aufgabe aufrufen und benutzen kann Bei einer engen Kopplung von Aktivit t und Programm wird die Applikation automatisch gestartet Sie bernimmt an Stelle eines Sachbearbeiters die Erf llung der Aufgabe etwa die Durchf hrung einer komplexen
306. ls Container f r die ver schiedenen Teildokumente angesehen werden kann die im Datenfluss vorkommen Das verwendete Datenformat z B XML muss diese Schachtelung und Zusammenfassung von Teildokumenten erlauben Das Migrationsdokument flie t im Laufe des Kontroll flusses zu allen Aktivit ten so dass diese die f r sie relevanten Informationen entneh men k nnen Obwohl die explizite Ber cksichtigung von Datenfl ssen bei der Modellierung flexibler ist haben wir uns f r das Dokumentmigrationsmodell entschieden weil ent sprechend der Fallstudie aus Abschnitt 3 1 die Verarbeitung eines XML Dokumentes einen typischen Anwendungsfall einer modernen E Business Plattform darstellt und sich dieser mit dem Dokumentmigrationsmodell besonders gut l sen l sst Wie bei der Vorstellung der Prozessdiagramme siehe Abschnitt 6 2 gezeigt wird l sst sich das Dokumentmigrationsmodell in einer Modellierungssprache sehr einfach ausdr cken da auf eine explizite Angabe der einzelnen Datenfl sse verzichtet werden kann und so die Diagramme wesentlich bersichtlicher und leichter verst ndlich werden Hinzu kommen die Argumente dass das Migrationsdokument Workflow relevante Daten laut Workflow Referenz Modell enth lt die sowieso jeder Aktivit t mitgeteilt werden m ssen und dass durch die Festlegung auf den Austausch eines ein zigen Migrationsdokumentes die Schnittstellen der Komponenten weiter vereinheitlicht werden k nnen da nicht die Ein oder Ausg
307. ls auch Webservices auf XML als Datenfor mat zur ckgreifen sollten sich dabei keine gravierenden Schwierigkeiten ergeben Zum anderen k nnte untersucht werden ob sich nicht jeder XML Prozess selbst als Web service auffassen l sst Ein Prozess bietet demnach einen Dienst im Netz an der in Anspruch genommen werden kann indem ihm ein SOAP Dokument gesendet wird Dieses wird vom Prozess verarbeitet und das resultierende XML Dokument als Ergeb nis wiederum in Form einer SOAP Nachricht an den Aufrufer bermittelt M glicher weise sind aber noch andere Formen vorstellbar beide Techniken miteinander zu ver binden Wie sich zeigt gibt es eine Reihe interessanter weiterf hrender Fragestellungen Zum gro en Teil ergaben sich diese erst w hrend der Erarbeitung und Umsetzung der in die ser Arbeit vorgestellten Konzepte Obwohl sie im Rahmen der Diplomarbeit nicht mehr vertiefend ber cksichtigt werden konnten lohnt es sich sicher in den angesprochenen Bereichen weitergehende berlegungen anzustellen 254 Kapitel 12 Schlussbetrachtungen 255 Literatur und Quellen Aal97 Ajm95 Alh98 Alh99 Apa01 Ark01 Bac98 Bad01 Bau96 Bet01 W M P van der Aalst The Application of Petri Nets to Workflow Management The Journal of Circuits Systems and Computers 8 1 S 21 66 1998 http wwwis win tue nl wsinwa jcesc jesc html M Ajmone Marsan et al Modelling with Generalized Stochastic Petri N
308. lt xsd element name fork type ForkType gt lt xsd element name join type JoinType gt lt xsd element name decision type DecisionType gt lt xsd element name merge type MergeType gt lt xsd element name serviceCall type ServiceCallType gt lt xsd element name subactivity type SubactivityType gt lt xsd element name synchfork type SynchforkType gt lt xsd element name synchjoin type SynchjoinType gt lt xsd element name synch type SynchType gt lt xsd choice gt lt xsd sequence gt lt xsd attribute name id type xsd ID use required gt lt xsd complexType gt lt xsd complexType name ServiceCallType gt lt xsd sequence gt lt xsd element name callservice type CallserviceType gt lt xsd element name next type NextType gt lt xsd sequence gt lt xsd complexType gt lt xsd complexType name SubactivityType gt lt xsd sequence gt lt xsd element name process type SubProcessType gt lt xsd element name next type NextType gt lt xsd sequence gt lt xsd complexType gt lt xsd complexType name CallserviceType gt lt xsd sequence gt lt xsd element name argument type ArgumentType minOccurs 0 maxOccurs unbounded gt lt xsd sequence gt lt xsd attribute name component type xsd string 182 Kapitel 8 Beschreibung von Prozessen in XML use required gt lt xsd attribute name method
309. lw rter jeweils um eine Teilmenge von XmlElements mit der wie bereits bei der Erl uterung offener Ports in Abschnitt 6 3 1 dargelegt die Ausnahmen beim Kopieren der Elemente spezifiziert werden k nnen Syntax Das Element copyRoot aus CopyPlaceholder wird durch Ableitung des Nicht Terminals CopyRoot der EBNF Grammatik notiert das Element copySubs analog durch das Nicht Terminal CopySubs Die Ableitungen f hren jeweils zu den termina len Symbolen copyRoot bzw copyRoot_except falls Ausnahmen aufgelistet wer den sollen rootExceptions analog zu copySubs und copySubs_except 6 3 Modellierung der Dokumenttypen 115 Def 6 12 Offene Dokumenttypen OpenDocTypes root subs root e XmlElements U AnyPlaceholder U CopyPlaceholder subs c XmlElements XmlElements U AnyPlaceholder U CopyPlaceholder x P XmlElements Bei einem offenen Dokumenttyp Kann durch den Gebrauch von Platzhaltern die sp ter an konkrete Werte gebunden werden die Dokumentmenge der konformen XML Dokumente zun chst offen gehalten werden Als Platzhalter sind daf r zus tzlich copyRoot und copySubs aus der Menge CopyPlaceholder vgl Def 6 12 erlaubt Offene Dokumenttypen werden bei der Definition offener Ports ben tigt siehe Def 6 13 Da die Menge der offenen Dokumenttypen eine echte Erweiterung der Menge der gew hnlichen Dokumenttypen ist gilt die Beziehung DocTypes c OpenDocTypes Syntax Ein
310. m als Ganzes und ebenso jeder einzelne Zustand der Angabe eines Ein und eines Ausgangsports vgl Abschnitte 6 3 und 7 3 Um ein voll st ndig konsistentes Workflow Modell aufzustellen m sste der Modellierer also einen nicht unerheblichen Aufwand mit der Angabe aller n tigen Ports treiben Allerdings erlauben die in Abschnitt 7 3 bei der formalen Definition der Sprache f r Prozessdia gramme gemachten Einschr nkungen keinen gro en Spielraum f r die Ausgestaltung von Ports im dynamischen Modell F r viele Zust nde ergeben sich bei Ber cksich tigung der Einschr nkungen und Constraints die Ein und Ausgangsports bereits teil weise oder sogar vollst ndig aus den Vorgaben der Sprachdefinition oder dem Kontext innerhalb des Prozessdiagramms Beispielhaft seien hier die PseudoStates genannt bei denen h ufig der unbeschr nkte Port any als Eingangsport gesetzt werden kann In sehr vielen F llen ist somit eine automatische Berechnung der Ports m glich die zum Ziel hat zum einen den Benutzer zu entlasten und ihm die automatisierbaren Aufgaben abzunehmen zum anderen gleichzeitig inkonsistente und fehlerhafte Einga ben des Benutzers zu verhindern Dabei soll die Angabe eines Ports durch den Benutzer nur noch bei den Elementen des statischen Modells und beim Eingangsport von Pro zessdiagrammen m glich sein Alle anderen Ports ergeben sich im Zusammenhang mit den modellierten Prozessen aus diesen Benutzervorgaben Insbesondere die Angabe von
311. mationen n tig sind wird eine Identit ts Transformation benutzt die keine Ver nderungen vornimmt Somit kommt man schnell zu einem Typ konzept f r Transitionen bei dem die Transformationsvorschriften bzw die gesammel ten Stylesheets im statischen Modell die vorhandenen Typen f r die Transitionen darstellen Jeder Transition muss dann ein Transitionstyp also ein Quellport ein Ziel port und eine passende Transformationsvorschrift zugeordnet werden was automa tisch die Forderung aus der Konsistenzbetrachtung erf llt nach der vor dem Ziehen einer Transition erst ein entsprechender Typ angelegt werden muss wenn es ihn noch nicht gibt Typisierte Transitionen eignen sich somit hervorragend f r die Forderung von Wiederverwendbarkeit und Konsistenz Stylesheet Statisches Modell Typ t A x gt y i mit Transitionstyp e 1 Prozessdiagramm mit typisierter Transition Abb 6 21 Typisierte Transition mit ihrem Typ Zusammenfassend besteht ein Transitionstyp also aus einem eindeutigen Namen einem Quellport einem Zielport und einer Transformationsvorschrift mit der Dokumente des Quellports f r den Zielport angepasst werden k nnen ber den Typnamen kann jeder Transition ein Transitionstyp zugeordnet werden Die formale Definition von typisierten Transitionen folgt im n chsten Abschnitt Selbstverst ndlich muss der Typ einer Transition immer zum jeweiligen Kontext des Kontrollflusses passen das hei t sein Quellport muss
312. me zur Softwareintegration im E Business betrachtet Da im Abschnitt 3 2 die Forderung nach einer visuellen Modellierung von Workflows aufgestellt wurde sollen nun grafische Sprachen unter sucht werden mit denen sich Workflow Modelle entwerfen und beschreiben lassen Als bekannteste Vertreter wurden Petri Netze Ereignisgesteuerte Prozessketten EPK und UMIL Aktivit tendiagramme ausgew hlt 5 1 Petri Netze Petri Netze sind ein bekanntes Mittel zur Beschreibung und Analyse von Prozessabl u fen Daher soll in diesem Abschnitt untersucht werden ob sie sich als Modellierungs sprache f r XML Prozesse eignen Zun chst erfolgt eine allgemeine Einf hrung in die Theorie der Petri Netze und ihre Anwendbarkeit f r allgemeine Gesch ftsprozesse Anschlie end werden die M glichkeiten von Petri Netzen mit den Anforderungen von XML Prozessen verglichen 5 1 1 Klassische Petri Netze Ein klassisches Petri Netz ist ein gerichteter bipartiter Graph mit zwei Knotenmengen Stellen und Transitionen In der grafischen Darstellung von Petri Netzen werden Stellen durch Kreise und Transitionen durch Rechtecke repr sentiert Ein solches Netz l sst sich durch folgende formale Definition beschreiben vgl Bau96 S 50 und Aal97 Definition Ein Petri Netz ist ein 3 Tupel S T F Dabei ist S eine endliche Menge von Stellen und T eine endliche Menge von Transitionen mit S A T sowie F c S x T U T x S die Menge der Kanten zwischen S und T
313. men angeboten werden siehe Abschnitt 6 2 noch einige besondere Eigenschaften erf llen m ssen werden sie als Stereotyp service definiert Neben der blichen Signatur der Operation ben tigt eine Service Definition die Angabe eines Eingabe und eines Ausgabeports zur Spezifikation seiner Schnittstellen Der Eingabe port gibt die Struktur der Eingabedokumente vor die von dem Service verarbeitet werden k nnen Der Ausgabeport beschreibt die Menge der Dokumente die nach Aufruf des Services an das nachfolgende Element weitergegeben werden vgl Ab schnitt 6 3 Au erdem gibt es f r jeden Service ein eigenes Symbol siehe 6 2 das beim Einf gen eines Services in ein Prozessdiagramm benutzt werden kann Stereotyp service Basisklasse UML Core Operation Ober Stereotyp Tag Definitionen image inputPort outputPort Einschr nkungen Constraints Erl uterung Ein Service definiert eine Operation die in einer Aktivit t eine Prozessdiagramms aufgerufen werden kann 134 Kapitel 7 Metamodell f r Prozessdiagramme Darstellung bliche Darstellung einer Operation mit Signatur Zur Unterscheidung von gew hnlichen Operationen wird der Signatur ein hochgestelltes S angef gt Das dem Service zugewiesene Symbol und die Spezifikation der Ein und Ausgabeports kann als UML Kommentar an die Operation angef gt werden F r gew hnlich werden diese Attribute jedoch in spezifischer Weise von einem Modell
314. mit dem UML Profil f r Prozessdiagramme konform mit dem UML Metamodell vorgenommen wurde ist es m glich auch die Erweiterungen und die neuen Attribute abzuspeichern die sich durch die Stereotypen und Tag Definitionen siehe Kapitel 7 ergeben Da sich die Stereotyp Definitionen jedoch wie aus Abbildung 8 3 ersichtlich auf der gleichen Modellhierar chie Ebene wie die Prozessdiagramme selbst befinden werden sie ebenfalls im XMI Dokument als Instanzen der Metaklasse Stereotype abgelegt Die Dokument verkn pfungs und Referenzierungsmechanismen XLink und XPointer erlauben es ein getrenntes XMI Dokument f r diese Definitionen des Erweiterungsprofils anzulegen und mit den XMI Dokumenten f r die konkreten Prozessdiagramme zu verkn pfen siehe XMI00 Kapitel 3 8 Auf diese Art ist es m glich die vorgenommenen Sprach erweiterungen zu integrieren und alle Sprachelemente von Prozessdiagrammen ein schlie lich erg nzender Attribute etwa f r die Angabe von Ports Transitionstypen oder Transaktionen in XMI Dokumenten abzulegen Die UML DTD liefert eine Repr sentation des gesamten UML Metamodells und ist daher sehr umfangreich Entsprechend k nnen auch die XMI Dokumente sehr viele Details bez glich eines UML Modells enthalten was im Zusammenhang mit den schon erw hnten langen Markenbezeichnungen zu schlechter Lesbarkeit der Doku mente f r einen menschlichen Leser f hrt Insofern wird die Anforderung m glichst keine unn tigen Elemente z
315. modell vgl Abschnitt 6 1 1 Rechnung getragen Dabei migriert ein XML Dokument das die Workflow relevanten Daten beinhaltet durch die Aktivit ten des Prozesses Da dieser Datenfluss implizit stattfindet braucht er in den Prozessdiagrammen nicht explizit modelliert zu werden Der Zugriff auf die XML Daten geschieht mit Hilfe von Anfragesprachen wie XPath beispielsweise inner halb von Guards Dabei wird durch die im Abschnitt 6 3 beschriebene Modellierung der Dokumentstrukturen die Konsistenz der Prozessmodelle bez glich der XML Daten sichergestellt Da Prozessdiagramme auf UML Aktivit tendiagrammen basieren bieten sie alle Vorteile von UML Dazu z hlt vor allem die M chtigkeit der Kontrollflusskonstukte wie Parallelit t Als zus tzliche M glichkeit neben den bereits vorhandenen wurde ein Sprachelement eingef hrt um Prozesse als Transaktionen ablaufen zu lassen da dies in der Praxis h ufig sichergestellt werden muss Abschlie end wurde gefordert dass jedes Workflow Modell eine eindeutige Semantik besitzt Dies wurde in Prozessdiagrammen durch bestimmte Einschr nkungen der Aktivit tszust nde erreicht womit die Grund voraussetzung f r ihre vollst ndig maschinelle Ausf hrung gegeben ist Bevor wir berlegungen in dieser Richtung anstellen soll im n chsten Kapitel zun chst die Modellierungssprache f r Prozessdiagramme formal spezifiziert werden 7 1 Das UML Metamodell 121 7 Metamodell f r Prozessdiagramme Die im vorheri
316. n Durch eine solche webbasierte Infrastruktur k nnen Gesch ftsprozesse beispielsweise von einem Mitarbeiter an einem Internetportal des Unternehmens ausgel st werden Der Vorgang wird dann durch das IT System des Unternehmens an die Mitarbeiter oder Softwaresysteme weitergeleitet die die gew nschte Aufgabe erledigen k nnen Ein derart automatisierter Ablauf f hrt zu einer geringeren Durchlaufzeit und gro er Effizienz Die Beobachtung der E Business und E Commerce Wirtschaft zeigt immer deutlicher dass es nicht ausreicht neue Marktpl tze und elektronische Vertriebswege einzurichten Um sich erfolgreich am Markt behaupten zu K nnen ist f r die Unter nehmen dar ber hinaus eine Integration ihrer existierenden Anwendungen sehr wichtig Die neuen netzbasierten Prozesse m ssen mit den bestehenden Softwaresystemen kommunizieren auf die vorhandenen Datenbanken zugreifen und die bereits realisierten Funktionen aufrufen k nnen Ein besonderes Augenmerk erh lt zunehmend die unter nehmens bergreifende Integration von Gesch ftsprozessen etwa zur Kopplung und Integration der an einer Lieferkette beteiligten Unternehmen oder Unternehmensteile Supply Chain Management Die Zukunft des E Business liegt ganz klar in der Integration so zitiert die Computer Zeitung siehe Hen01 die Beraterin eines f hrenden Marktforschungs unternehmens und berichtet ber eine Studie des Fraunhofer Instituts f r Fabrikbetrieb 10 Kapitel 2 Grundlagen
317. n Ein Dop pelklick auf einen Dokumenttyp hat denselben Effekt wie ein Bet tigen von Details Um einen Dokumenttyp zu erzeugen oder zu bearbeiten dient der modale Dia log aus Abbildung 9 5 Ganz links im Dialog l sst sich ausw hlen ob der Dokumenttyp ein konkretes Wurzelelement oder den Platzhalter any enthalten soll Falls es sich um einen offenen Port handelt steht au erdem copyRoot zur Auswahl In der Tabelle rechts kann eine Menge von Unterelementen angegeben werden Genau wie f r das Wurzelelement m ssen dabei sowohl der Namensraum als auch der Name des XML Element eingegeben werden F r copyRoot l sst sich eine Menge von Ausnahmen 9 2 Bedienung des Prozesseditors 197 angeben siehe Abschnitt 6 3 1 Des Weiteren kann durch Markieren des entsprechen den Feldes bestimmt werden dass auch die Unterelemente bernommen werden copySubs wobei sich ebenfalls Ausnahmen spezifizieren lassen Der Dialog kann mit OK oder Cancel beendet werden Im Fall von OK werden die Eingabe in das Feld des zugeh rigen Ports in der Eingabemaske bernommen bei Cancel werden die Eingaben verworfen Zu beachten ist dass die nderungen am Port erst dann in das Workflow Modell bernommen werden wenn in der Eingabemaske der Komponente die Schalfl che Save bet tigt wird Es gen gt nicht den Dialog des Dokumenttyps mit OK zu beenden ERE d Docume Ippe Fhag meri ar P haah ii er Sub Elerrente
318. n homogenen Prozessbeschreibung der M glichkeit f r flexiblere bedingte Verzweigungen und der Definition umfangreicherer paralleler Teilabschnitte in Prozessdiagrammen im Gegen satz zu den bisher benutzen regelbasierten Beschreibungen Auf die Umsetzung des gesamten Regelwerks aus der Fallstudie in Prozessdiagramme soll an dieser Stelle ver zichtet werden sie k nnte analog zu dem gezeigten Beispielen auch f r umfangreichere Prozesse aus der E Business Plattform des Finanzunternehmens vorgenommen werden 11 2 Erf llung der Anforderungen Nach dieser Betrachtung der Anwendbarkeit in einem konkreten Fallbeispiel bleibt ab schlie end noch die berpr fung ob die zu Beginn der Arbeit gesetzten Anforderungen vgl Abschnitt 3 2 und Ziele 3 4 f r ein Workflow System im E Business erreicht wurden Die Forderung nach einem Modellierungswerkzeug das auch bei der Konsis tenzpr fung unterst tzt Kann mit dem entwickelten Prozesseditor erf llt werden Die Anbindung von Back End Systemen bei der Prozessausf hrung erfolgt durch dyna misch zu bindende Konnektoren die gleichzeitig die Zuordnung von Workflow Elementen auf reale Komponenten vornehmen Die Verarbeitung von XML Dokumen ten und der Workflow relevanten Daten kann durch das Migrationsprinzip und die Ausrichtung auf XML erf llt werden Mit PML liegt auch die Workflow Beschreibung in einem XML Format vor Der entwickelte Prozessinterpreter interpretiert diese Beschreibungssprache un
319. n werden die Typen den Transitions Instanzen zugewiesen Von zentraler Bedeutung sowohl bei der Verwaltung der Transitionstypen als auch bei der Nutzung der typisierten Transitionen sind die Funktionalit ten des Modellierungswerkzeugs Es muss den Benutzer mit Hilfe der Transitionstypen bei der Konsistenzwahrung in seinen Modellen unterst tzen Denkbar w re etwa eine sukzessive Entwicklung der Prozessdiagramme ausgehend vom Start 6 3 Modellierung der Dokumenttypen 109 zustand Hat der Modellierer den Port des Anfangszustands angegeben kann das Modellierungswerkzeug aus seinen Bibliotheken des statischen Modells diejenigen Services als Nachfolger vorschlagen f r die ein passender Transitionstyp zur Verket tung mit der zuletzt angelegten Service Aktivit t vorhanden ist So wird der Benutzer bei der Auswahl von Services unterst tzt die nicht zu Konsistenzbr chen f hren Vergleiche in diesem Zusammenhang auch Kapitel 9 ber das im Rahmen dieser Arbeit entwickelte Modellierungswerkzeug f r Prozessdiagramme Schlie lich kann es vorkommen dass der Modellierer zwei Ports miteinander verketten m chte f r die noch kein Transitionstyp definiert worden ist Dann muss er zun chst einen entsprechenden Typ anlegen und ein Stylesheet entwickeln das die n tigen Transformationen durchf hrt Erst danach kann er mit der Modellierung des Workflows fortfahren und den neuen Transitionstyp benutzen Man spricht in diesem Zusammenhang von einem iterati
320. n Aufgabentr gern weiter geleitet wird Dabei hat das WFMS Zugriff auf ben tigte Datenbanken auf die Orga nisationsstruktur also das statische Modell der Unternehmung und es kann mit Auf gabentr gern wie Mitarbeitern oder Softwarekomponenten kommunizieren ihnen 2 4 Unterst tzung durch Software 21 gem der Prozessvorschrift Aufgaben zuweisen und auf deren Erledigung warten Man sagt auch das WFMS erzeuge eine Instanz des Workflow Modells und f hre diese aus Mit einem WFMS sollte es m glich sein gleichzeitig mehrere Auspr gungen bzw Instanzen von Workflow Modellen auszuf hren Modellierung Analyse 2 Simulation P Re Design ggf Konvertierung Ausf hrung und Steuerung durch WFMS LN Software Ea SL de IN Mitarbeiter E f IA Abb 2 3 Werkzeug Einsatz beim Workflow Management Der Einsatz eines WFMS eignet sich vor allem f r gut strukturierte Prozesse die a priori spezifiziert und festgelegt werden k nnen Es sollte aber auch die M glichkeit bestehen Prozessmodelle an neue Gegebenheiten anzupassen und flexibel eventuell bei langlebigen Prozessen sogar zur Laufzeit der Prozessdurchf hrung zu ndern Dies betrifft sowohl die Ablaufstruktur als auch die in der Prozessbeschreibung enthal tene Gesch ftslogik die den Ablauf regelt oder zumindest beeinflusst Um dieses soge nannte Redesign f r den Planer m glichst einfach zu gestalten sollte es m
321. n Fluss der Referenzen durch den Prozess 6 1 2 Komponentenintegration Eine zentrale Anforderung aus der praktischen Anwendung vgl Fallstudie in Ab schnitt 3 1 ist die Anbindung der bestehenden Softwaresysteme und komponenten und ihre Integration in die einzelnen Aktivit ten des Workflows Dies ist besonders unter dem Ziel einer vollst ndig automatisierten Ausf hrung der Workflows wichtig bei der nicht nur die Steuerung des Kontroll und Datenflusses sondern auch die einzelnen Aktivit ten selbst ohne Benutzerinteraktion ausgef hrt werden sollen Dies macht es n tig bestehende Softwarekomponenten f r die Ausf hrung der einzelnen Aktivit ten einzubinden Mit dem Begriff Softwarekomponente sind in dieser Arbeit die verschiedensten Software Einheiten eines Unternehmens gemeint die jeweils ganz unterschiedliche Funktionen wahrnehmen k nnen Es kann sich dabei um Module handeln die reine Datenverwaltung in Verbindung mit Datenbanken oder anderen Speichereinheiten betreiben Daten transformieren Daten aus anderen Systemen anfordern oder Daten auf Basis spezieller Gesch ftslogiken auswerten und entsprechende Berechnungen durch f hren In der Regel findet sich in einem Unternehmen eine ganze Landschaft heteroge ner Systeme von betrieblicher Standardsoftware wie SAP R 3 ber umfangreiche Datenbanksysteme bis hin zu objektorientierten Anwendungssystemen auf Basis von Enterprise Java Beans Strategisches Ziel einer prozessorientierten E B
322. n Guard zum Beispiel nur XML Elemente enthalten die in den zu den Doku menttypen des Ports geh rigen Schemata als Unterelemente definiert sind Ansonsten ist die Semantik des Guards nicht eindeutig definiert Die bei der obigen Definition der Spracherweiterung f r OCL Ausdr cke benutzte Funktion isStereotypedAs berpr ft ob ein Element mit dem angegebenen Stereotyp klassifiziert wurde Die Operation ist folgenderma en definiert context ModelElement def let isStereotypedAs stype Name Boolean self stereotyp gt exists s s name stype 7 4 Implementierung des erweiterten Metamodells 145 7 4 Implementierung des erweiterten Metamodells Damit die in den nachfolgenden Kapiteln vorzustellenden Software Werkzeuge auf Prozessdiagrammen operieren k nnen muss das im letzten Abschnitt eingef hrte Metamodell f r Prozessdiagramme implementiert werden N tig ist eine Datenstruktur in der sich beliebige Prozessdiagramme mit ihren statischen und dynamischen Teilen ablegen lassen Da wegen ihrer Plattformunabh ngigkeit f r alle Implementierungen dieser Arbeit die Programmiersprache Java gew hlt wurde soll auch das Metamodell f r Prozessdiagramme als eine Sammlung von Java Klassen implementiert werden Dazu wird im Folgenden beschrieben wie die Metaklassen des UML Profils im Einzel nen in Java Klassen bertragen wurden Grunds tzlich repr sentiert dabei jede Java Klasse eine entsprechende Metaklasse Dadurch entsteht eine effizi
323. n Kontrollfl ssen und der Integration von Softwarekomponenten in Prozessdiagram men vorgestellt Dabei liegt dem Kontrollfluss immer der implizite Datenfluss des Migrationsdokuments zu Grunde Welche Struktur dieses Dokument hat wurde bisher allerdings aus der Betrachtung weitgehend ausgeklammert Die Modellierung der Dokumentstruktur ist f r die Wohldefiniertheit des Prozessmodells sehr wichtig wenn die Einhaltung von Konsistenzbedingungen berpr ft und so der Modellierer durch Rechnerunterst tzung fr hzeitig auf Fehler in seinem Modell aufmerksam gemacht werden soll In diesem Abschnitt werden daher Konzepte dargestellt mit denen sich Informationen ber den Typ und die damit verbundene Struktur des Migrations dokuments in seinen jeweiligen Zust nden in ein Prozessdiagramm integrieren lassen Die Struktur der Dokumente wird durch einen Dokumenttyp spezifiziert Dabei muss man zwischen der Definition des Typs und seiner Verwendung in den Modellen unterscheiden Die Typdefinition ordnet dem Namen des Typs eine bestimmte Doku mentstruktur zu Dadurch wird definiert wie ein Dokument dieses Typs aufgebaut sein muss Ist ein Dokumenttyp einmal definiert kann er im Workflow Modell durch Angabe seines eindeutigen Namens verwendet werden Zur Definition von Dokumenttypen gibt es in XML bereits etablierte Standard verfahren Da XML das f r die Migrationsdokumente zu Grunde gelegte Datenformat ist K nnen wir diese Techniken hier aufgreifen Sowoh
324. n Prozessen in XML 8 1 Anforderungen an Prozessbeschreibungssprachen 161 8 Beschreibung von Prozessen in XML In den vorausgegangenen Kapiteln haben wir Prozessdiagramme vorgestellt und defi niert Sie bieten eine ad quate M glichkeit Workflows entsprechend den Anforderun gen aus Kapitel 3 zu modellieren Bei der Anforderungsanalyse wurde au erdem von einem Workflow Management System gefordert dass es das grafische Workflow Modell in eine textuell kodierte Form bzw ein XML Format bersetzen kann mit der das Modell ebenfalls vollst ndig beschrieben wird Zweck ist dabei diese Beschreibung als Eingabe f r einen Interpreter zu benutzen der Instanzen des Workflows ausf hren soll Dieses Kapitel stellt zun chst die Ziele und Anforderungen an eine solche Beschreibungssprache dar und evaluiert in einem zweiten Abschnitt vorhandene Ans tze und L sungen gegen diese Anforderungen Nachdem die St rken und Schw chen der betrachteten Formate aufgezeigt wurden stellt der dritte Unterabschnitt die Process Markup Language PML als unsere Antwort auf die Anforderungen vor Dabei wird auch der Zusammenhang zwischen dem grafischen UML Modell der Prozess diagramme und dem XML Format erl utert Diese Abbildung zwischen UML und PML soll bei der Implementierung als Grundlage dienen um ein Diagramm als PML Doku ment abzulegen bzw umgekehrt ein PML Dokument als Prozessdiagramm zu visuali sieren Zur praktischen Arbeit mit PML wurden diese Abbil
325. n Service Operation in einem serviceState f hrt zu nderungen auf dem Migrationsdokument Deshalb m ssen f r einen serviceState bzw die durch ihn definierte Service Aktivit t die erlaubten Eingangs und die m glichen Ausgangsdokumenttypen durch die Angabe von Ports modelliert werden Dies geschieht durch das Erben der entsprechenden Attribute von stateWithPorts Beim Setzen der Ports kann ein Werkzeug als Vorgabe die Werte f r die Portattribute aus dem service bernehmen der diesem serviceState zugeordnet ist vgl Abschnitt 9 2 5 Hinzuf gen von Zust nden Bei manchen Services Kann es allerdings sein dass ihre Portspezifikation die zul ssigen Dokumentmengen nur sehr wage oder bei der Verwendung von Platzhaltern gar nicht einschr nkt weil bei diesen generischen Services die Dokumenttypen von konkreten Parameterwerten abh ngen In solchen F llen k nnen die Portspezifikationen f r den serviceState vom Benutzer angepasst werden nachdem die Werte der Parameter gesetzt sind vgl Abschnitt 6 3 1 Einbindung von Ports in Prozessdiagramme 140 Kapitel 7 Metamodell f r Prozessdiagramme Typisierte Transitionen als XML Dokumentfluss Jedes Prozessdiagramm erh lt bei seiner Ausf hrung ein XML Dokument als Eingabe das durch die einzelnen Aktivit tszust nde migriert Ein solcher Fluss von Daten zwi schen den Aktivit ten l sst sich in Aktivit tendiagrammen durch Objektfl sse und Objektflusszust nde beschrei
326. n der Tran sition t2 l scht die Marke und damit das Signal damit bei der n chsten Ausf hrung die Synchronisation korrekt stattfindet In diesem Beispiel wartet also Prozess 2 auf Pro zess 1 Um eine gegenseitige Synchronisation durchzuf hren muss das Basiskonstrukt zweifach verwendet und gespiegelt in das Netz eingebaut werden Analog l sst sich auch die Synchronisation von mehr als zwei Prozessen beschreiben Bei der bedingten Verzweigung unterscheidet man zwei F lle Beim expliziten OR Split werden an den Kanten zwischen einer Transition und ihren Ausgangsstellen Bedingungen notiert Nur die Ausgangsstelle deren Bedingung erf llt ist wird beim Schalten markiert Auf diese Weise findet die weitere Verarbeitung nicht in parallelen Teilstr ngen statt wie beim AND Split sondern genau ein Strang wird gew hlt in dem der Prozess fortf hrt Demgegen ber besitzen beim impliziten OR Split mehrere Transi tionen dieselbe Eingangsstelle Nur eine Transition kann die Marke die sich in der Stelle befindet konsumieren Welche der Transitionen letztlich schalten darf muss separat modelliert werden Hier k nnten beispielsweise zus tzliche Eingangsstellen f r jede Transition eingef hrt werden die die n tigen Bedingungen repr sentieren Iterative Prozessabl ufe werden durch Verzweigungen realisiert Abh ngig von bestimmten Bedingungen verzweigt der Prozessablauf zur ck zu einer fr heren Stelle Die Forderung dass ein Workflow Modell immer
327. n der textlichen Beschreibung vornehmen kann ohne das Workflow Modell im Entwurfswerkzeug visuell zu bearbeiten 13 Keine Definition von eigentlich nicht ben tigten Elementen Eine Vielzahl von Elementdefinitionen die zur Repr sentation von Prozessdiagrammen eigentlich nicht ben tigt werden erh hen die Komplexit t erschweren die Verst ndlichkeit und sollten deshalb vermieden werden Diese Anforderung kommt besonders bei der Betrachtung vorhandener Sprachen und Standards zum Tragen die unter Umst nden ber die Kon strukte von Prozessdiagrammen weit hinausgehen 164 Kapitel 8 Beschreibung von Prozessen in XML 8 2 Vorhandene XML Formate f r Prozessmodelle Es gibt zahlreiche XML Formate in denen sich Workflow Modelle textuell abspeichern lassen einige von ihnen sind sogar als Industriestandard etabliert Da es gem einer der oben aufgestellten Anforderungen geboten ist solche Standards zu unterst tzen wollen wir in diesem Abschnitt stellvertretend zwei Formate vorstellen und gegen die Anforderungen evaluieren Es handelt sich dabei um XLANG einem Format in dem beim BizTalk Server 2000 die Prozessdefinitionen abgelegt werden und dem XML Metadata Interchange XMI Konzept zur Speicherung objekt orientierter Modelle 8 2 1 Beschreibung von Prozessen mit XLANG An dieser Stelle soll die von Microsoft entwickelte Prozessbeschreibungssprache XLANG vorgestellt werden Wie bereits im Abschnitt 4 1 erw hnt wurde wird sie innerha
328. n einem Schema Repository soll den Austausch vereinfachen F r die Suche nach einem bestimmten Schema k nnen Stichworte angegeben werden nach denen die Schema Eintr ge kategorisiert sind Nachdem ein Unternehmen die von einem Handelspartner benutzten Schemata gefunden hat kann es entscheiden ob es mit den gleichen Schemata arbeiten oder lieber eine Konvertierung der Nachrichten in die eigenen Dokumentformate vornehmen m chte vgl Moh01 S 16f Ein auf BizTalk org ver ffentlichtes Schema ist auf Korrektheit gepr ft und zu dem BizTalk Framework konsistent so dass ein BizTalk Server Nachrichten dieses Formats interpretieren kann Zus tzlich kann sich ein Interessent f r ein bestimmtes Schema registrieren lassen um automatisch Informationen ber neue Versionen und nderungen zu erhalten Neben der Speicherung der XML Formate dient die Internet plattform BizTalk org zum Austausch von Neuigkeiten und Informationen ber den jeweils aktuellen Stand der Biz Talk Initiative 4 1 Microsoft BizTalk Server 2000 37 BizTalk Servers Ein BizTalk Server ist ein Softwaresystem das BizTalk Dokumente verarbeiten kann Insbesondere muss der Server die im BizTalk Framework definierten BizTags interpre tieren und gem der im Framework definierten Semantik verarbeiten k nnen Da es sich bei dem Framework um einen offenen Standard handelt kann er prinzipiell von verschiedenen Anbietern implementiert und in ihre Softwaresysteme integriert werden
329. n han deln muss mit der eine bestimmte Operation zur Ausf hrung ausgew hlt wird siehe Omg01 2 13 3 3 Dieser Sachverhalt wurde im Metamodell f r Prozessdiagramme vereinfacht durch die Assoziation zur Klasse Service abgebildet Somit ist jedem ServiceStateVertex genau ein Service zugeordnet der bei der Ausf hrung dieses Zustands ausgef hrt werden soll Damit die Ausf hrung wohldefiniert ist wird au erdem f r jeden Parame ter des Service ein Objekt der Klasse Argument angelegt und mit dem ServiceStateVertex verbunden in dem der Wert f r den jeweiligen Parameter gesetzt werden kann Diese Klasse bernimmt die Rolle der gleichnamigen UML Metaklasse siehe Omg01 Abb 2 15 mit der f r den Aufruf einer Operation Werte f r deren Parameter angegeben werden Die abstrakte Klasse PseudoStateVertex bernimmt hnlich der UML Metaklasse PseudoState die Funktion einer Abstraktion aller sonstigen Zust nde in denen keine Aktionen ausgef hrt werden m ssen Im Gegensatz zum orginalen UML Metamodell werden die verschiedenen Unterarten jedoch nicht durch ein Attribut kind siehe Omg01 2 12 2 7 unterschieden sondern durch die Bildung weiterer Unterklassen die im Folgenden kurz erl utert werden Diese Klasse repr sentiert den Startzustand eines Prozessdia gramms Zwecks effizienteren Zugriffs gibt es eine unidirektio nale Referenz von ProcessDiagram auf ein Objekt der Klasse Diese Klasse repr sentiert den Endzustand eines
330. n soll so dass es nicht zu einem Abbruch des Prozesses kommt Diese berlegungen lassen sich auch auf transaktionale Prozesse bertragen Statt einen Fehler an den Prozessinterpreter zu melden welcher die Transaktion mit einem Abort beenden w rde k nnte ein Service auch eine entsprechende Fehlermeldung in das Migrationsdokument schreiben Diese wird vom Prozess erkannt so dass beispielsweise ein alternativer Service ausgef hrt und so das Scheitern des Prozesses vermieden wird Trotzdem kann es bei der expliziten Modellierung von Fehlerbehandlungen Situationen geben in denen eine weitere Ausf hrung nicht m glich ist Dies k nnte beispielsweise eintreten falls alle alternativen Prozessstr nge ausprobiert wurden und gescheitert sind Es ist zu berlegen ob f r einen solchen Fall nicht ein neuer Zustandstyp in Prozessdiagrammen eingef hrt werden sollte Es K nnte sich dabei um einen speziellen UML Aktionszustand handeln dessen Semantik so definiert ist dass sofort die Ausf hrung des Prozesses beendet wird Er stellt quasi einen Endzustand dar der sich jedoch vom normalen Endzustand dadurch unterscheidet dass er ein Scheitern des Prozesses signalisiert Ein solcher Zustand w rde nicht nur in transaktionalen Prozessen Sinn machen sondern k nnte auch im Zusammenhang mit Fehlerbehandlun gen gem Abschnitt 10 3 2 zum Einsatz kommen 10 4 4 Ausfall des Prozessinterpreters Neben dem Auftreten von Fehlern innerhalb von Services best
331. n und produzieren als Ausgabe auch nur bestimmte Doku menttypen Bei der Verkettung von Services in den Aktivit ten eines Prozessdiagramms m ssen die Ein und Ausgabetypen aufeinander folgender Services abgestimmt sein und zueinander passen wenn keine Fehler entstehen sollen Aus diesem Grund m ssen Informationen ber die Dokumenttypen bereits im Workflow Modell also im Prozess diagramm ber cksichtigt werden F r Prozessdiagramme haben wir daher das in diesem Abschnitt vorgestellte und im bern chsten Abschnitt formal definierte Konzept der Ports eingef hrt mit dem sich Typkonsistenz bereits im Modell sicherstellen l sst Mit Ports lassen sich die Ein und Ausgabeschnittstellen von Komponenten definieren die ein XML Dokument verarbeiten Ein XML Dokument hat einen bestimmten Typ der durch sein Wurzelelement festgelegt wird Wie die Dokument struktur eines g ltigen XML Elements unterhalb des Wurzelelements aussieht bestim men die Typdefinitionen im zugeh rigen XML Schema das dieses XML Element f r einen bestimmten Zielnamensraum definiert Durch Angabe dieses Namensraums und des f r diesen Namensraum eindeutigen Namens des XML Elements ergibt sich eine eindeutige Bezeichnung f r das Element Im einfachsten Fall besteht ein Port also aus der Angabe eines einzelnen XML Elements und bestimmt damit diejenigen Dokumente die dieses Element als Wurzelelement besitzen als Menge der zum Port konformen XML Dokumente Dieser sehr einfache
332. nd die Wahrnehmung neuer Herausforderungen und Chancen zu erreichen vgl Geo95 S 120 Diese Besch ftigung mit den unternehmenseigenen Prozessen wird zun chst unabh ngig von Informationssystemen durchgef hrt die zur Automatisierung der Prozesse dienen k nnten Das Ergebnis der Betrachtung ist eine Beschreibung der Gesch ftsprozesse die meist in papierbasierter Form vorliegt und sich mit der Frage befasst Was ist zu tun vgl Wen00 S 9 Um die oben genannten Ziele der Prozessanalyse zu erreichen ist es aber auch erforderlich sich mit der Umsetzung der Ergebnisse und der Durchf hrung der opti mierten Prozesse zu befassen Hier ist die Frage Wie ist es zu tun zu beantworten Besonders die wachsenden M glichkeiten der Informationstechnik bieten ein gro es Potenzial f r die effiziente Ausf hrung von Prozessen Dazu ist allerdings eine genau ere Beschreibung der einzelnen Aufgaben innerhalb eines Gesch ftsprozesses n tig die auch aus Sicht der vorhandenen Informationssysteme erfolgen muss mit denen die Aufgaben koordiniert und ausgef hrt werden sollen siehe Wen00 S 9 Diese Beschreibung der Aufgaben und der Abl ufe die diese Aufgaben im Sinne des zu Grunde liegenden Prozesses anordnen kennzeichnet den Begriff des 2 2 Prozesse in einem Unternehmen 13 Workflow Nach Wenski siehe Wen00 S 10 soll unter Workflow Folgendes verstan den werden Ein Workflow ist eine partiell oder vollst ndig geordnete M
333. nd ruft dabei die passenden Methoden auf Auf diese Weise wird schrittweise das PML Dokument generiert Im Abschnitt 8 3 3 wurde die M glichkeit beschrieben mit Hilfe des Extension Abschnitts in einem PML Dokument zus tzliche Informationen abzulegen Der Pro zesseditor speichert dort beispielsweise die Koordinaten aller Prozesszust nde in der grafischen Darstellung Analog zum Importer kommt auch hier das Entwurfsmuster Observer zum Einsatz siehe Gam96 S 287 Die Klasse ExportObserver zu der der Exporter eine Assoziation besitzt wird immer dann benachrichtigt wenn ein Modell element exportiert wurde Dies geschieht durch Aufruf der zugeh rigen Methode des Observers die das Modellelement bergeben bekommt Als R ckgabewert kann die Methode ein XML Element liefern das der Exporter als Kind des Elements lt extensions gt in das PML Dokument einbettet Man muss bei Bedarf eine Unterklasse von ExportObserver implementieren die die Methoden berschreibt und die gew nschten XML Elemente konstruiert Unter Verwendung der hier vorgestellten Prozessbeschreibungssprache PML und den beiden Konvertierungswerkzeugen zwischen PML und der aus Abschnitt 7 4 bekannten Datenstruktur folgt im n chsten Kapitel die Vorstellung des Prozesseditors mit dem sich Prozessdiagramme entwerfen lassen 190 Kapitel 9 Modellierungswerkzeug f r Prozessdiagramme 9 1 Der Prozesseditor 191 9 Modellierungswerkzeug f r Prozessdiagramme Nachdem in den vora
334. nden in dem das Workflow Management System zum Einsatz kommt Unter diesen Gesichtspunkten ergeben sich folgende Anforderungen l Zun chst muss dem Benutzer ein visuelles Modellierungswerkzeug zur Verf gung stehen mit dem er die vorhandenen oder gew nschten Prozessabl ufe vollst ndig modellieren kann siehe Wmc95 S 12 Mit Hilfe dieses Werkzeugs kann er komfortabel auf grafischer Ebene Prozessmodelle entwerfen ohne sie durch eine bestimmte textuelle Sprache hnlich einer Programmiersprache beschreiben zu m ssen 2 Das Modellierungswerkzeug sollte den Benutzer durch geeignete Funktionen bei der Analyse Konsistenzpr fung und Optimierung der Prozessmodelle unterst t zen da dies ein wichtiges Ziel der Workflow Modellierung ist vgl Geo95 S 136 Zu diesem Zweck bietet es sich an eine Simulation von Workflow Modellen durchzuf hren um ihr Verhalten schon vor dem realen Einsatz beo bachten und untersuchen zu k nnen 3 Beim Einsatz eines Workflow Management Systems in einem Unternehmen ist davon auszugehen dass dadurch keine vollst ndig neue Software L sung einge f hrt werden soll Vielmehr dient ein solches System h ufig dazu die heterogenen vorhandenen Komponenten bzw Back End Systeme zu einer Gesamtl sung zu integrieren Eine solche Situation ist auch bei der Fallstudie gegeben Daher muss das Einbinden von bestehenden Softwarekomponenten sowohl bei der Modellie rung als auch bei der Ausf hrung der Workflo
335. ndeutigen Namen bekannt und wird Sessioncontext genannt Zum Zugriff auf solche Daten wird bei Prozessdiagrammen ebenfalls XPath verwendet F r jeden Parameter eines Service kann also ein XPath Ausdruck angegeben werden Der Prozessintepreter liest dann bei der Ausf hrung des Prozesses die Daten aus der entsprechenden Stelle eines XML Baums und bergibt sie an die Komponente Schlie lich stellt sich die Frage nach dem Datentyp eines Parameters Eine Service Methode k nnte prinzipiell jeden beliebigen Datentyp f r ihre Parameter verwenden Die Ermittlung der Werte zur Laufzeit ergibt jedoch zumindest bei den letzten beiden der oben beschriebenen Herkunftsorte zun chst nur Werte vom Typ String Dies liegt daran dass die heute verf gbaren Werkzeuge zur XML Verarbeitung ebenfalls nur mit dem Typ String arbeiten Bevor die so gewonnenen Werte also als Parameter an einen Service bergeben werden k nnen m ssten sie in den gew nschten Zieldatentyp kon vertiert werden Dies ist f r jeden Typ individuell zu realisieren was dazu f hrt dass stets nur eine Auswahl von Typen unterst tzt werden k nnte Wir haben uns aus diesem Grund dazu entschlossen zun chst nur Parameter vom Typ String f r eine Service Methode zuzulassen Jeder Service kann dann intern den Inhalt der Parameter in geeig neter Weise deuten und ggf eine Konvertierung durchf hren Diese L sung schien uns flexibler zu sein als wenn die Typbehandlung bereits
336. ndung in den geforderten Formaten der anderen Systeme kommunizieren kann Die dritte Stufe der Gesch ftsprozessabbildung auf die in dieser Arbeit besonders eingegangen werden soll baut auf den Grundlagen der ersten beiden Stufen auf ber ck sichtigt bei der Integration aber die betrieblichen Abl ufe und verbindet die Einzel anwendungen zu Akteuren bei der automatisierten Durchf hrung von Workflows vgl CZ01 Diese Abgrenzung der Integrationsstufen schl gt sich auch auf die jeweils bei der Umsetzung verwendeten Technologien und Architekturen nieder In Joh00 S 3f wird zwischen drei wesentlichen Vorgehensweisen unterschieden Die einfachste Form der Applikationsintegration ist demnach eine Punkt zu Punkt L sung bei der jede Anwendung unmittelbar mit jeder anderen gekoppelt wird siehe Abbildung 2 1a Diese Methode eignet sich allerdings nur f r eine kleine berschaubare Anzahl zu integrierender Systeme weil die Menge der Verbindungen und Schnittstellen sonst schnell un bersichtlich und unkontrollierbar wird Abhilfe schafft hier die Benutzung eines Message Brokers siehe Abbildung 2 1b der als zentrale Instanz Nachrichten zwischen den einzelnen Anwendungen bermittelt und so jede Anwendung nur noch eine Schnittstelle zu dieser Instanz haben muss Der Message Broker muss eine ein gehende Nachricht entgegennehmen in ein f r den Empf nger verst ndliches Format transformieren und dann an den Empf nger weiterleiten Dieser Ansatz
337. ne Fehler befinden Die Validierung bricht nicht beim ersten Fehler ab sondern versucht so viele Inkonsistenzen wie m glich zu finden Dabei kann es passie ren dass sogenannte Folgefehler auftreten oder in Ausnahmef llen Meldungen produ ziert werden die nur schwer nachvollziehbar sind Sobald die Ursache des Hauptfehlers behoben ist verschwinden beim n chsten Validierungsvorgang auch diese Meldungen Eine Validierung aller im Projekt enthaltenen Prozesse wird automatisch durch gef hrt bevor das Projekt gespeichert wird Das stellt sicher dass niemals Projekte mit inkonsistenten Workflow Modellen dauerhaft abgelegt werden 9 3 Implementierung des Prozesseditors 205 9 3 Implementierung des Prozesseditors In diesem Abschnitt sollen nun wichtige Aspekte der Implementierung des Prozess editors betrachtet werden Der Editor wurde von uns in der Sprache Java realisiert wo bei insbesondere die Java Swing Bibliotheken zum Einsatz kamen die die notwendige Funktionalit t zur Verf gung stellen um grafische Benutzungsoberfl chen zu erstellen 9 3 1 Klasse AppFrame Die wichtigste Klasse des Prozesseditor ist AppFrame Dabei handelt es sich um die Klasse die das Hauptfenster repr sentiert vgl Abschnitt 9 2 Sie ist innerhalb der Implementierung zugleich der Einstiegspunkt des Systems ber den alle wichtigen Bestandteile erreichbar sind Aufgrund dieser Aufgabe haben wir uns entschieden die Klasse gem dem Entwurfsmuster Singlet
338. ner Pr fungsmeldung lt match pattern auditing schreiben xml gt lt generate src auditing auditing xml gt lt Aufruf des allgemeinen sunShine Transformers gt lt transform type sunShine gt lt Archiv Transformers zum Laden des Dokuments gt lt transform type archivTransformer gt lt Transformation mit einem Stylesheet gt lt transform src auditing auditing schreiben xs1l gt lt Transformers zum Schreiben der Pr fungsmeldung gt lt transform type auditingTransformer gt lt Transformation mit einem Stylesheet gt lt transform src auditing auditing ergebnis xs1l gt lt Archiv Transformers zum Sichern des Dokuments gt lt transform type archivTransformer gt lt serialize type xml gt lt match gt Abb 11 2 Pipeline Beispiel nach Bad01 Es sollen hier nicht die Details der Syntax von Pipelines erl utert sondern vielmehr durch den Vergleich mit folgendem kleinem Prozessdiagramm die offensichtlichen Vorz ge der visuellen Modellierung verdeutlicht werden Die gleiche Pipeline k nnte als Prozessdiagramm grafisch modelliert etwa so aussehen 11 1 Vergleich der L sungsans tze 239 Auditing schreiben Auditing Ergebnis SunShine Transformer Archiv Transformer Archiv Transformer Auditing Transformer Abb 11 3 Prozessdiagramm einer Pipeline Je gr er die Pipeline Strukturen werden
339. ng durch Klassendiagramme die ihrerseits UML Bestandteil sind Die Semantik wird durch eine textuelle Beschreibung zu jedem Sprachelement erl utert Schlie lich werden mit Hilfe der Object Constraint Language OCL siehe Ab schnitt 7 1 3 Wohlgeformtheitsregeln aufgestellt die bei der Benutzung der Elemente einzuhalten sind um beispielsweise bestimmte problematische Konstellationen von Sprachelementen zu verbieten 7 1 1 Architektur von UML Das UML Metamodell stellt eine von vier Schichten einer Metamodell Schichtenarchi tektur dar e Das Meta Metamodell legt die grundlegende Infrastruktur fest um berhaupt die Darstellung von Sachverhalten mit grafischen Elementen zu erm glichen Dazu z hlen die Definitionen f r Klasse Assoziation und Operation Omg01 2 5 e Mit Hilfe der Basiskonstrukte des Meta Metamodells erfolgt nun die Beschreibung des Metamodells also der gesamten UML Sprache e Ein Modell ist eine Konkrete Instanz des Metamodells mit der beispielsweise ein reales Softwaresystem durch verschiedene Diagrammtypen spezifiziert wird e Beim Benutzermodell schlie lich handelt es sich um die Auspr gung des Modells also den Objektgraphen des Softwaresystems zu einem bestimmten Zeitpunkt der Ausf hrung 122 Kapitel 7 Metamodell f r Prozessdiagramme Da es sich beim UML Metamodell um eine komplexe Beschreibung vieler verschiede ner Sprachelemente handelt ist es in eine Reihe von Packages gegliedert
340. ng zeigt die obige Regel in einer Darstellung als Prozessdiagramm 11 2 Erf llung der Anforderungen 243 Auditing Antwort Auditing schreiben Auditing Best tigung Abb 11 9 Prozessdiagramm mit paralleler Ausf hrung Die parallele Ausf hrung von Aktionen ist im Regelwerk leider immer nur f r die Ak tionen eines Zustands m glich Der Wechsel in den nachfolgenden Zustand findet erst dann statt wenn alle nebenl ufigen Aktionen beendet worden sind Es ist daher nicht m glich ganze nebenl ufige Prozessstr nge mit mehreren Aktionen zu modellieren die unabh ngig voneinander ablaufen sollen Weil dies in Prozessdiagrammen ohne Weite res der Fall ist bilden sie auch im Bereich Nebenl ufigkeit das m chtigere und flexi blere Konzept Zudem ist es bei Prozessdiagrammen m glich Synchronisationspunkte einzubauen um Abh ngigkeiten zwischen parallelen Prozessteilen zu modellieren Somit bringt der Einsatz von Prozessdiagrammen und des zugeh rigen Prozess interpreters neben den Vorteilen der Veranschaulichung durch visuelle Modellierung weitere Verbesserungen gegen ber der bisherigen L sung der Workflow Management Anforderungen der E Business Infrastruktur Dazu geh ren vor allem die gr ere M chtigkeit und Flexibilit t der Konstrukte der Modellierungssprache die durch den Interpreter f r Prozessdiagramme auch auf die Ausf hrungsebene bertragen werden Vorgestellt wurden in diesem Abschnitt die Vorz ge einer einheitliche
341. ngen f r den Inhalt einer Aktivit t zu fordern Diese Ungenauigkeit f hrt zu einer nicht exakt festgelegten Semantik der Diagramme was ein h ufig genannter Nachteil von Aktivit tendiagrammen ist siehe z B Esh01 S 33 und Dum01 S 1 Da eine eindeutig definierte Semantik aber die Grundvoraussetzung f r die maschinelle Kontrolle und Ausf hrung von Gesch ftsprozessen durch Workflow Management 70 Kapitel 5 Evaluierung vorhandener Workflow Modellierungssprachen Systeme ist wurden unterschiedliche Versuche vorgenommen um Aktivit ten diagramme formal zu definieren In Esh01 beispielsweise werden zun chst Bedingun gen erarbeitet die von Aktivit tendiagrammen zu erf llen sind wenn es sich um die Beschreibung eines Workflows handeln soll Es wird dann eine formale Definition der Syntax entwickelt die ein Aktivit tendiagramm als Hypergraph auffasst Auf der Basis dieser Definition erfolgt eine Formulierung der Bedingungen an ein g ltiges Workflow Diagramm Es wird eine formale Beschreibung von Datenmanipulationen in den Zust nden entwickelt die schlie lich dazu benutzt wird die komplette Ausf hrungs semantik von Diagrammen exakt festzulegen Ein weiterer Nachteil von Aktivit tendiagrammen ist es dass sich im Zusam menhang mit Workflow Modellen die Verkn pfung mit der Organisationssicht schlecht ausdr cken l sst Man kann zwar mit Hilfe von Bahnen grafisch darstellen wer oder was bestimmte Aktivit ten ausf hrt daraus
342. ngs aus dass die Modellierung der Prozesse durch das Aufstellen der gro en Anzahl verschiedener Diagramme relativ aufwendig erscheint und au erdem nur Komponenten eingesetzt werden k nnen deren Schnittstelle durch Introspektion analysiert werden kann Wie schon bei BizTalk ist es mit Hilfe von WARP nicht m glich ein Web Portal zu erstellen ohne auf zus tzliche Produkte zu r ckzugreifen Besonders nachteilig wirkt sich aus dass WARP keinerlei XML Unterst tzung anbietet da dies eine wichtige Anforderung im Bereich E Business ist sunShine stellt ebenfalls einen interessanten Ansatzpunkt f r die Integration von Softwarekomponenten dar Es erlaubt das Einbinden verschiedenster Systeme und Datenquellen in die Verarbeitungsabl ufe eines Web Portals Daher stellt es kein Prob lem dar die Back End Systeme aus der Fallstudie zu integrieren und zudem einen Web Auftritt zu realisieren Die Forderung nach Multi Channel F higkeit d h der M glich keit verschiedene Ein und Ausgabeger te zu unterst tzen kann ebenfalls erf llt werden Alle Werkzeuge die f r die Verarbeitung von XML Daten ben tigt werden stehen bei sunShine implizit zur Verf gung F r die Realisierung von komplexen Workflow Modellen hat sunShine jedoch zwei Schw chen Zum einen ist jede Pipeline d h die Abfolge ihrer Bestandteile wie Transformer Selektoren usw fest in der Cocoon Sitemap durch eine spezielle XML Sprache codiert Dies entspricht einer Programmierung
343. nnnennnnnenn anne 92 6 3 1 Das Port Konzept zur Typisierung von Dokumenten unenen 94 6 3 2 Wiederverwendbarkeit und Konsistenz durch typisierte Transitionen 104 6 3 3 Formale Definition von Ports und typisierten Transitionen 109 6 4 Bewertung augen iin ibn 119 7 Metamodell f r Prozessdiagramme cs00s00000s0000s00000s00000000000000000 0000000000000 121 7 1 Das UML Melamadel uses en 121 7 1 1 Architekt von UME ass 121 7 12 Metamodell f r Aktivit tendiagramme ussssenennsenenennnenn 122 7 1 3 Object Constraint Langu gse unusnisk lsenseshr Babes ke 123 2 UMT Erweiterungsmechanismen 2b 126 712 4 Stereotype SA ee een anime 127 172 2 Tag Definitions und Tagged Values 0u0ssesnsnsenssenenneneeennnenn 128 4 2 3 Constraints u a ana 128 7 2 3 Nao EREE ee T 128 1 3 UML Profil f r Prozessdiasramme ass aa 129 7 3 1 Umsetzung des Port Konzepts in UML Datentypen e 130 732 Definition von Stereotypen f r Prozessdiagramme ee 132 7 3 3 Wohblgeformtheitsrege Mersinin a R a Ea 143 71 4 Implementierung des erweiterten Metamodells 2222200 en 145 7 5 Validierung von Prozessdiagrammen uueesssessssneessnnensnnnnesnnnnennnnnnnn 154 7 6 Automatische Portberechnung a Da 156 8 Beschreibung von Prozessen in XML ssesssocsssecssocesocesoocesoocessecssocesocsssooesoosesse 161 8 1 Anforderungen an Prozessbeschreibungssprachen
344. nterelemente ausgel st copyRoot copySubs a b i A c d a b gebunden an A c d K B a b j B i i Abb 6 11 Beispiel f r die Bindung des Platzhalters copySubs Ein Port der ausnahmslos die Einstellungen des Ports an den er gebunden wird ber nehmen soll schreibt sich demnach copyRoot copySubs Die folgende Abbildung illustriert eine Anwendung dieses Ports f r den erw hnten Archiv Service Der offene Port wird dabei an den Ausgangsport des Vorg ngerzustands gebunden InputPort OutputPort Statisches Modell lt 2 any gt lt copyRoot copySubs D Archiv Service y Offener Port wird an den Ausgangsport des Vorg ngers gebunden Prozessdiagramm Service u fu i Service vix Abb 6 12 Bindung eines offenen Ports mit copyRoot im Diagrammkontext Die beiden Platzhalter lassen sich jeweils um eine Menge von XML Elementen erg n zen die beim Kopieren ausgenommen werden sollen Wenn wir f r das bekannte Bei spiel annehmen dass alle Wurzelelemente au er B und alle Unterelemente au er c kopiert werden sollen ergibt sich folgende Situation 6 3 Modellierung der Dokumenttypen 99 copyRoot_except B copySubs_except c a b E k gebunden an A c d ED dab B St Abb 6 13 Beispiel f r die Bindung der Platzhalter mit Ausnahmen Eine Anwendung der Ausnahmeangaben w re zum Beispiel f r den ebenfalls oben erw hnten SQL Se
345. nts ergeben sich unmittelbar aus den dort festgelegten Restriktionen Stereotyp stateWithPorts Basisklasse UML StateMachines StateVertex Ober Stereotyp Tag Definitionen inputPort ouputPort Einschr nkungen 1 Keine Einschr nkungen sondern lediglich Hilfsfunktionen zum Zugriff auf die Attribute Constraints context stateWithPorts def let inputPort Port self definedTag gt select name inputPort typedValue referencedValue oclAsType Port let outputPort Port self definedTag gt select name outputPort typedValue referencedValue oclAsType Port let state StateVertex self extendedkElement oclAsType StateVertex let predecessors Set Port self state incoming stereotype oc1lAsType typedTransition getBoundTarget 2 Ein InitialState hat als Eingangsport den Eingangsport seines zugeh rigen Prozessdia gramms if state oclIsTypeOf PseudoState and state oclAsType PseudoState kind initial then inputPort state outgoing stateMachine stereotype oclAsType processDiagram definedTag gt select name inputPort typedValue referenceValue oclAsType Port endif 7 3 UML Profil f r Prozessdiagramme 137 3 Ein InitialState hat als Ausgangsport seinen Eingangsport if state oclIsTypeOf PseudoState and state oclAsType PseudoState kind initial then outputPort inputPort endif 4 SynchStates FinalStates ForkStates JoinStates
346. nzepts offen gehalten werden Das prinzipielle Vorgehen in den nachfolgenden Kapitel gestaltet sich derart dass wir durch die Vorstellung einiger exemplarischer Ans tze einen Einblick in den aktuellen Stand der Technik geben m chten Die jeweiligen Verfahren Modelle und Systeme werden anhand der hier gestellten Anforderungen bewertet bevor wir unsere eigenen Ans tze oder Erg nzungen der bisherigen Konzepte vorstellen 4 1 Microsoft BizTalk Server 2000 35 4 Evaluierung vorhandener Workflow Systeme Im Bereich der Workflow Modellierung und Ausf hrung gibt es eine Vielzahl von L sungen und Produkten sowohl aus dem kommerziellen als auch aus dem wissen schaftlichen Bereich Um einen Einblick in den aktuellen Stand der Technik zu gew h ren sollen an dieser Stelle exemplarisch drei Systeme vorgestellt werden die den Zielen dieser Arbeit in besonderer Weise nahe kommen Neben der jeweiligen System architektur wollen wir besonders die Aspekte der Workflow Modellierung Workflow Ausf hrung und der Komponentenintegration betrachten Im letzten Abschnitt dieses Kapitels findet eine zusammenfassende Evaluierung der Systeme anhand der Forderun gen aus Kapitel 3 statt Zum einen handelt es sich um das kommerzielle von Microsoft angebotene System BizTalk Server 2000 das zur Umsetzung der BizTalk Initiative beitragen soll Die Betrachtung von BizTalk ist deswegen so interessant weil es bei der Modellierung und Ausf hrung von Gesch ftsprozes
347. nzwischen wurden zahlrei che verwandte Sprachen im Umfeld von XML standardisiert Sie dienen zur Anwendung und Verarbeitung von XML in bestimmten Branchen zum Beispiel durch Transformationen von XML Dokumenten Mit der wachsenden Verbrei tung sind au erdem eine Menge von Werkzeugen verf gbar mit denen sich XML Dokumente auf einfache Art verarbeiten lassen Da sich XML somit als derzeitiger und auch zuk nftiger Industriestandard etabliert hat wird gerade im Bereich des E Business verst rkt auf den Einsatz von XML Technologien f r die Datenhaltung und den Datenaustausch gesetzt Auch die Anforderungen des Finanzunternehmens aus der in Abschnitt 3 1 vorgestellten Fallstudie schreiben explizit die Verwendung von XML vor Aus diesen Gr nden kann die Verar beitung von KML Dokumenten als eine Anforderung an heutige Workflow Management Systeme im Bereich E Business angesehen werden Das Workflow Management System ben tigt ein Werkzeug mit dem sich aus dem grafischen Modell eines Prozesses eine textuell codierte Beschreibung gene rieren l sst die so pr zise ist dass sie als Grundlage f r die automatisierte Aus f hrung des Workflows dienen kann vgl Geo95 S 136 Diese Workflow Beschreibung muss in einem plattform und anwendungsneutralen Format abge legt werden damit bei einer nderung der Systemumgebung nicht alle bisherigen Modelle unbrauchbar werden Aus diesem Grund sollte hnlich wie bei den Workflow relevanten Daten auch f
348. offenen Fragen bei der Softwareintegration im E Business l Die Anbindung heterogener Systeme an eine E Business Plattform und die Kopp lung der Systeme untereinander 2 Die Einbindung der betrieblichen Gesch ftsprozesse und Workflows Die vor handenen Informationssysteme des Unternehmens sollten in den Aktivit ten der Workflows aufgerufen werden Die bei diesem prozessorientierten Ansatz entste henden elektronischen Gesch ftsprozesse k nnten ber eine E Business Infrastruk tur und das Internet von externen Partnern Mitarbeitern und Kunden ausgel st werden 3 Die vollst ndige Automatisierung der Workflows durch Kontroll und Datenfluss zwischen den benutzten Softwarekomponenten die ohne Benutzerintervention ablaufen k nnen Dazu m ssen Schnittstellen zum automatischen Datenaustausch zwischen den Applikationen geschaffen werden 4 Die Schaffung flexibler Zugriffsm glichkeiten f r die Kunden mit ihren verschie denen Endger ten und damit der Unterst tzung eines Multi Channel Ansatzes 5 Die Unterst tzung der Mitarbeiter eines Unternehmens die sich mit der Software integration befassen bei ihren teilweise komplexen Aufgaben durch entsprechende Werkzeuge Im folgenden R ckblick wollen wir diese Problemstellungen und die einzelnen Ziele der Diplomarbeit rekapitulieren und die dazu im Hauptteil der Arbeit vorgestellten L sungsoptionen und Konzepte reflektieren Neben den in der Einleitung Kapitel 1 aufgef hrten Zielen we
349. on siehe Gam96 S 157 zu entwerfen Es kann damit sichergestellt werden dass von der entsprechenden Klasse maximal eine Instanz existiert und diese zudem von berall her zug nglich ist ohne m glicherweise ber eine Vielzahl von Assoziationen zu navigieren um auf sie zugreifen zu K nnen Abbildung 9 13 zeigt die Klasse und ihre wichtigsten Bestandteile javax swing JFrame A Singleton gt nn AppFrame javax swing JPanel PANEL SERVICE String service PANEL PROJECT String project 1 servicePanel gt 1 thelnstance AppFrame ServicePanelView 1 projectPanel gt 1 get AppFrame 7 ProjectPanelView AppFrame swapWorkingAreaTo panel String Void v projectTree v workingArea 1 1 javax swing JTree javax swing JPanel Abb 9 13 Klasse AppFrame AppFrame erbt von der Swing Klasse JFrame damit sie als Repr sentation des Editor Hauptfensters verwendet werden kann Sie hat entsprechend der Beschreibung aus Abschnitt 9 2 Referenzen zu ihren zwei Bestandteilen dem Projektbaum projectTree und dem Bereich in den die Eingabemasken eingeblendet werden workingArea Das Attribut theInstance und die Methode get die beide Klasseneigen schaften in Java statisch sind realisieren in Kombination mit dem Konstruktor dem die Sichtbarkeit private zugeordnet ist die Eigenschaft der Kl
350. onen 1 und 2 simultan innerhalb desselben run to completion step ausgef hrt d h ihre Ausf hrung ist zur gleichen Zeit beendet Wenn eine solche Konstruktion in einem Workflow modelliert wird ist jedoch meistens eine andere Semantik beabsichtigt n mlich dass die Ausf hrung der Aktionen zur gleichen Zeit beginnen soll Da die Aktionen selbst an Akteure delegiert werden k nnen sich die Zeiten zu denen die Ausf hrungen enden erheblich unterscheiden M glicherweise wurden im oberen Prozessstrang bereits mehrere Folgezust nde bear beitet w hrend sich der untere immer noch in der dargestellten Aktion 2 befindet Auf grund dieser Probleme wird in WieOl eine eigene Ausf hrungssemantik f r Aktivit tendiagramme beschrieben die sich f r den Einsatz im Workflow Management besser eignet sowie ein Algorithmus angegeben der die Diagramme entsprechend dieser Semantik ausf hrt Im Mittelpunkt der Betrachtungen stehen dabei Ereignisse die innerhalb des Systems auftreten und ihre Behandlung innerhalb der Workflow Ausf h rung Wie bereits im Abschnitt 6 2 6 argumentiert haben wir f r Prozessdiagramme auf den Einsatz von Ereignissen verzichtet Die Verwendung des Algorithmus aus WieOl w rde also f r Prozessdiagramme einen gro en Overhead bedeuten Aus diesem Grund bernehmen wir zwar insoweit die dort eingef hrte Semantik wie es f r Prozess diagramme erforderlich ist entwickeln aber einen eigenen Algorithmus der speziell auf die Aus
351. opriet re Formate abzubilden die von lteren Anwendungen genutzt werden 2 2 Prozesse in einem Unternehmen Bei den betrieblichen Abl ufen in einem Unternehmen kann man die auftretenden Prozesse in Materialprozesse Informationsprozesse und Gesch ftsprozesse klassifi zieren vgl Med93 Materialprozesse stellen materielle Transformationen in einem Unternehmen dar Dazu geh rt zum Beispiel die Erzeugung eines Endproduktes aus den Roh materialien Zu einem Materialprozess geh ren immer physische Aktivit ten an realen Objekten Informationsprozesse dagegen behandeln die Verarbeitung von Daten Informa tionen und die damit verbundenen Vorg nge Sie sind oft durch Softwaresysteme automatisiert oder werden teilautomatisiert von Sachbearbeitern mittels Rechnerunter 12 Kapitel 2 Grundlagen des Workflow Managements st tzung erledigt In diesen Bereich fallen zum Beispiel alle Buchungsvorg nge in einem Unternehmen die Rechnungslegung usw Gesch ftsprozesse engl business processes sind markt oder kundenorientierte Prozesse die einen messbaren Nutzwert erzeugen oder einen Beitrag zur Erreichung von Unternehmenszielen bringen sollen Der Begriff des Gesch ftsprozesses ist dabei ein umfassenderer denn Gesch ftsprozesse k nnen sowohl Material als auch Informa tionsprozesse als Teilprozesse enthalten und durch sie realisiert werden In Wen00 S 8 wird ein Gesch ftsprozess daher folgenderma en definiert Unter einem Ge
352. ormat ankommen m ssen nicht mehr transformiert werden F r einen Ansatz zur L sung der Transformationsprobleme im Zusammenhang mit XML und propriet ren Formaten sei auf Dep00 und die Studienarbeit L t00 verwiesen Eine XML f hige Datenbank wird als Dokumentenarchiv eingesetzt In ihr werden zur Protokollierung der Vorg nge Kopien der Dokumente gespeichert Somit wird bei der internen Verarbeitung und Zwischenpufferung der Daten komplett auf XML gesetzt Das Weiterleiten Routing wird vom WFMS mit Hilfe einer Regelmaschine vorgenommen So werden die in XML vorliegenden Dokumente intern an die richtigen Services weitergeleitet Dabei dienen Tags der XML Struktur zur Klassifizierung des Dokumenttyps und zustands Zu diesem Zweck hat das Unternehmen eine spezielle XML Sprache f r die interne Struktur der Dokumente definiert Nach der Klassifizie rung entscheidet das WFMS aufgrund der vorhandenen Regeln welchem Service eine Referenz auf das Dokument gegeben werden soll so dass sich der Service das Exemplar des Dokumentes aus der Dokumentdatenbank holen kann Die Services sollen alle in Java realisiert werden Jeder Service ist ein Stellver treter f r eine Funktion der Back End Systeme und stellt dem WFMS eine solche Funktion zur Verf gung Dazu bildet der Service eine Art Container f r die Parameter die zum Aufruf der entsprechenden Back End Funktion ben tigt werden nderungen an den Funktionalit ten der Back End Systeme k nnen m g
353. ort Diese Funktion wird f r sp tere Wohlgeformtheitsregeln und Constraints ben tigt context Port def let is tany Boolean self types gt size 1 and self types gt one root oclIsTypeOf AnyPlaceholder and subs gt isEmpty 132 Kapitel 7 Metamodell f r Prozessdiagramme 7 3 2 Definition von Stereotypen f r Prozessdiagramme Die f r die Verwendung in Prozessdiagrammen vorgenommenen Erweiterungen an Syntax und Semantik der Standardelemente von UML Aktivit tendiagrammen sollen durch die folgenden Definitionen von Stereotypen exakt definiert werden Dazu zeigt Abbildung 7 5 alle neu eingef hrten Stereotypen mit ihren jeweiligen Tags im Kontext ihrer Basisklassen aus dem UML Metamodell Im Anschluss daran folgt die detaillierte Definition der einzelnen Stereotypen und Attribute durch Tabellen metaclass Metamodell ModelElement meines 1_ source outgoing GeneralizableElement metaclass metaclass A StateVertex T Harget Trap Transition REN 7 i i i es enemaser i meadass emackss a Uaa BE 7 i PseudoState State Hop H StateMachine i A A i A i N i i
354. orts spezifizieren lassen Um dem Modellierer diese Arbeit soweit wie m glich abzunehmen verwendet der Editor intern das Verfahren der automatischen Portberechnung siehe Abschnitt 7 6 Lediglich im statischen Modell m ssen die Ports von Hand eingegeben werden bei der Konstruktion von Prozessdiagrammen findet jedoch wann immer m glich eine sukzessive Berechnung der Ports statt Weiterhin kann der Modellierer vom Prozesseditor aus jederzeit den Validie rungsalgorithmus aus Abschnitt 7 5 starten um zu berpr fen ob sein Diagramm Fehler enth lt bzw an welchen Stellen die Modellierung noch unvollst ndig ist Der Editor selbst verwendet den Algorithmus intern um sicherzustellen dass keine ung lti gen Prozessdiagramme dauerhaft gespeichert werden Gegebenenfalls wird der Model lierer durch Fehlermeldungen auf die Inkonsistenzen aufmerksam gemacht Damit der Prozesseditor in der Lage ist eine solche Verwaltung von Prozessen zu erlauben muss er intern auf einer geeigneten Datenstruktur arbeiten mit der sich Prozessdiagramme repr sentieren lassen Ausgehend von dem in Kapitel 8 erl uterten XML Format PML zur Speicherung von Prozessdiagrammen w re ein erster Ansatz f r ein internes Datenmodell direkt auf den XML Dokumenten und Elementen zu arbei ten die nach dem Parsen eines PML Dokuments beispielsweise als Auspr gung des Document Object Models DOM siehe DOMOI im Speicher vorliegen k nnten und zugreifbar w ren Der Vorteil dies
355. orts werden im Prozessdiagramm nicht dargestellt Ein Modellierungswerkzeug hat daf r zu sorgen dass sie passend repr sentiert werden und visua lisiert werden k nnen Tag isTransactional Stereotyp processDiagram Typ UML DataTypes Boolean Multiplizit t 1 Erl uterung Zeigt an ob das zugeh rige processDiagram einen Prozess modelliert der Transaktions eigenschaften erf llen muss Tag inputPort Stereotyp processDiagram Typ ProcessDiagrams Port Multiplizit t 1 Erl uterung Dieser Port spezifiziert die Menge von Dokumenten die das zugeh rige Prozessmodell verar beiten kann Tag outputPort Stereotyp processDiagram Typ ProcessDiagrams Port Multiplizit t 1 Erl uterung Dieser Port spezifiziert eine Menge von Dokumenten die alle m glichen Ausgabedokumente dieses Prozesses enth lt Tab 7 5 Definition des Stereotyps processDiagram Dieses Stereotyp enth lt au erdem die Tag Definitionen f r Eingangs und Ausgangsport so dass ein Prozessdiagramm auch als ein Element angesehen werden kann das bestimmte Anforderungen an den Typ eines eingehenden Dokuments stellt 136 Kapitel 7 Metamodell f r Prozessdiagramme und nach der Ausf hrung bestimmte Dokumenttypen zur ckliefert Durch die Angabe der Ports l sst sich das Prozessdiagramm leicht als Prozessbaustein in einem anderen Workflow Modell wiederverwenden vgl Abschnitt 6 3 1 Einbind
356. ozessdiagramms der Code neu erzeugt werden muss Im Falle des Interpreters sind nderungen dagegen sofort wirk sam nachdem die neue PML Beschreibung gespeichert ist Wird haben uns daher ent schlossen zun chst Konzepte zur Interpretation von Prozessdiagrammen zu entwickeln In weiterf hrenden Arbeiten k nnte dann untersucht werden wie sich durch den Einsatz eines bersetzers sinnvoll Effizienzsteigerungen erzielen lie en vgl Abschnitt 12 2 Der Interpreter arbeitet gem dem oben diskutierten in WieOl beschriebenen Prinzip wonach das WFMS f r das Management der Prozessausf hrung und die Behandlung der Transitionen zust ndig ist es jedoch alle Aktionen innerhalb von Aktionszust nden an Softwarekomponenten delegiert Zur Erf llung dieser Aufgaben enth lt der Interpreter eine Reihe verschiedener Bestandteile die im Abschnitt 10 2 vorgestellt werden Der folgende Algorithmus f hrt einen Prozess gem der obigen Semantikdefinition aus executeProcess process document 1 executeSection process getInitialState document executeSection state document 2 firstState true 3 6 4 if firstState then 5 firstState false 6 else 7 state getFollowing state 8 transition getUsedTransition state Transition ber die der Folgezustand erreicht wurde 9 stylesheet transition getStylesheet 0 if stylesheet null then 1 transform document stylesheet 2 end if 3 end if
357. ozesse m glichst intuitiv modelliert werden k nnten so dass auch Mitarbeiter die Modelle verstehen und anlegen k nnen die keine technische Spezialausbildung mitbringen Insgesamt kann die Automatisierung bislang manueller T tigkeiten die Produktivit t und damit die Konkurrenzf higkeit des Unter nehmens erh hen Des Weiteren wird ein Schwerpunkt der Untersuchung auf den Vorteilen und M glichkeiten von XML als grundlegendes Datenformat liegen Wir betrachten wie die Verarbeitung von XML Dokumenten in die Workflow Modelle eingebettet werden kann und wie sich mit Hilfe von XML der geforderte Multi Channel Ansatz realisieren l sst der den Unternehmen die unterschiedlichsten elektronischen Kommunikations und Vertriebswege zu ihren Kunden und Partnern er ffnet Im praktischen Teil der Diplomarbeit sollen die entwickelten Konzepte in Soft warewerkzeuge umgesetzt werden die den Anwender umfassend bei der Erstellung Wartung und Ausf hrung der Workflow Modelle zur Softwareintegration unterst tzen 8 Kapitel 1 Einleitung Ziel ist ein ganzheitliches System das eine prozessorientierte Softwareintegration ange fangen von der Modellierung bis hin zur Ausf hrung der Workflows erm glicht Zur praktischen Anwendbarkeit der Werkzeuge sollen sie in die E Business Plattform sunShine eingebettet werden die Basisfunktionalit ten zum Beispiel zum Aufbau eines Internetportals zur Verf gung stellt sunShine ist ein Produkt der Paderborner S
358. p c L p2 Beweis Seien p p2e Ports mit p p2 und doc e L p beliebig Z z doc e L p2 doc e L p amp 3t1 root subs ep mit doc e L t4 6 8 amp subs c c doc A root r doc v root e AnyPlaceholder 6 6 Aus p lt p folgt 3 t3 root subs e pz mit 6 9 root root v rootze AnyPlaceholder A subs gt c subs root r doc v root e AnyPlaceholder A subs c subs c c doc doc e L t2 6 5 doc e L p gt 6 8 UU 114 Kapitel 6 XML Prozesse und Prozessdiagramme Dieser Kompatibilit ts Satz besagt dass wenn ein Port p Teilport von pz ist dann sind alle zu p konformen XML Dokumente auch zu p2 konform Damit haben wir eine einfache Methode gefunden die Kompatibilit t zweier Ports zu berechnen Denn gilt die Bedingung L p lt L p2 dann kann eine Komponente mit p als Ausgangsport mit einer Komponente verkn pft werden deren Eingang durch p2 spezifiziert ist Offene Ports und ihre Bindung Im Folgenden sollen auch die in Abschnitt 6 3 1 vorgestellten offenen Ports formal definiert werden Aufbauend auf den bereits vorgenommenen Definitionen ergibt sich daraus eine formale Semantik f r die Sprache der zweiten EBNF Grammatik aus dem erw hnten Abschnitt vgl Abbildung 6 15 mit der sich offene Ports mit den zus tz lichen Platzhaltern copyRoot und copySubs notieren lassen Neben der Definition der offenen Ports erfolgt auch eine formale Darstellung der Bindung sol
359. pes input c source A binding target input lt output Eine typisierte Transition besteht somit neben den konkreten Ein und Ausgangsports aus einem Typ wobei die Ein und Ausgangsports von Transition und Transitionstyp durch die angegebenen Teilmengenbeziehungen zueinander kompatibel sein m ssen Die Ein und Ausgangsports der Transition sind im Prozessdiagramm de facto durch die Ein und Ausgangsports der Zust nde gegeben die diese Transition miteinander verbin det Das XML Migrationsdokument kann so entlang dieser Transition von einem Zustand zu seinem Nachfolgerzustand wandern Der folgende Migrationssatz beweist dass mit Hilfe der im Transitionstyp festgelegten Transformationsfunktion trans jedes Dokument das zur Dokumentmenge des Eingangsports geh rt auch konform zum Ausgangsport der Transition gemacht werden kann Satz 6 18 Migrations Satz V t input output type e Transitions type source target trans e TTypes YV xe L input trans x e L output Beweis Seixe L input beliebig Z z trans x e L output Es gilt input c source 6 17 Aus xe L input folgt damit gt xe L source 6 10 gt trans x e L binding target input 6 16 Es gilt binding target input lt output 6 17 gt Li binding target input c L output 6 10 gt trans x e L output Damit ist gezeigt dass Transformationsfunktionen auf Transitionen nicht zu Konsis tenzbr chen f hren k nnen wenn sie d
360. ponenten integriert werden sollen Eine Komponente ist dabei f r den Prozessinterpreter eine Black Box Er bergibt ihr als Eingabe die XML Daten und nimmt sie anschlie end wieder entgegen Er kann jedoch keinen Einfluss darauf nehmen wie die Komponente intern mit den Daten umgeht insbesondere kann er nicht den Zugriff auf die Daten verz gern um eine Synchronisa tion zu erreichen Die einzige M glichkeit best nde darin die gesamte Ausf hrung jeder Komponente als kritischen Abschnitt zu betrachten und entsprechend zu sch tzen Dadurch ginge aber jegliche Parallelit t verloren da die Teilstr nge zwar verzahnt ihre Aktivit tszust nde aber streng sequentiell ausgef hrt w rden Die zweite Alternative besteht darin dass jeder parallele Teilprozess eine eigene Kopie des XML Dokuments erh lt auf der seine Komponenten Ver nderungen vor nehmen d rfen Wenn die Prozesse wieder zu einem Ausf hrungsstrang vereinigt 90 Kapitel 6 XML Prozesse und Prozessdiagramme werden m ssen die Kopien in geeigneter Weise zusammengesetzt werden so dass sich wieder ein einzelnes Dokument ergibt siehe Wen 00 S 32 71 Dies kann jedoch problematisch werden falls gravierende nderungen an der Struktur des Dokuments vorgenommen wurden Es ist beispielsweise denkbar dass ein Service in einem Teil prozess die gesamte Struktur sowie XML Element Bezeichnungen des Dokuments ver ndert hat Es ist dann nicht rekonstruierbar an welcher Stelle die nderun
361. preter und f hrt den gew nschten Prozess aus Das XML Ausgabedoku ment wird dem Webserver als Ergebnis des SunflowTransformers bergeben Da f r die Ressource jeder beliebige Generator verwendet werden kann ist als Herkunftsort des Eingabedokuments jede mit sunShine m gliche Datenquelle denkbar Meistens wird es jedoch sinnvoll sein dieses beim Aufruf der Ressource vom Client aus zu bergeben oder aus den bermittelten Daten eines Webformulars ein XML Dokument zu generie ren Beide Varianten sind mit Hilfe von sunShine bereits realisierbar 10 6 2 sunShine Prozessumgebung Im Abschnitt 10 5 wurde angedeutet dass f r jede Systemumgebung in der der Prozessinterpreter eingesetzt werden muss eine Unterklasse von AbstractEnvironment entwickelt werden muss die die speziellen Gegebenheiten ber cksichtigt Zu diesem Zweck wurde zur Integration in sunShine eine Klasse SunshineEnvironment implemen tiert Dies gestaltete sich relativ einfach da mit den sogenannten Sessioncontexts bereits eine Menge von XML Dokumenten zur Verf gung steht die sich jeweils ber einen 236 Kapitel 10 Ausf hrung von XML Prozessen eindeutigen Namen ansprechen lassen vgl Abschnitt 10 5 Eine Anforderung an die Integration des Interpreters in sunShine war es dass sich die bisherigen Transformer als Softwarekomponenten in XML Prozessen wieder verwenden lassen da sie eine Menge von Standardl sungen f r die Verarbeitung von XML Daten darstellen Zu
362. putPort gt lt parameter name parl gt lt service gt lt component gt lt components gt lt package gt Abb 8 12 Beispiel f r die PML Beschreibung eines Konnektors Stereotyp transitionType F r jeden Transitionstyp des Package existiert ein Unterelement lt transitionType gt unterhalb von lt transitionTypes gt Durch sein Attribut name legt man den Namen des Typs fest wobei das Package nicht angegeben wird Dieses ergibt sich bereits aus dem Package Kontext in dem der Transitionstyp beschrieben wird Aus dem Stereotyp transitionType ergibt sich dass ein Transitionstyp aus drei Teilen besteht Durch die Elemente lt sourcePort gt und lt targetPort gt lassen sich Ein und Ausgangsports definie ren Dies geschieht analog zu Abschnitt 8 3 1 Im Anschluss daran gibt das Element lt transformation gt das XSL Stylesheet an mit dem das Migrationsdokument transfor miert werden soll wenn es ber eine Transition des beschriebenen Typs l uft Dazu gibt es zwei M glichkeiten Entweder verweist das Attribut href auf eine URL unter der das gew nschte Stylesheet abgelegt ist oder das Stylesheet wird direkt als Unter element von lt transformation gt in der PML Beschreibung notiert stereotype transitionType Tags sourcePort Port 1 targetPort OpenPort 1 transformation Expression 0 1 lt xsd complexType name TransitionTypeType gt lt xsd sequence gt lt xsd elemen
363. q wert 0 gt lt Entscheidungswerte gt lt SyncAktion gt lt StandardAktion final Ja name Fehlerverarbeitung gt lt Subprozess subprozess Fehlerbehandlung gt lt StandardAktion gt lt Zustand gt lt Prozesstyp gt Abb 11 6 Regeln mit bedingter Verzweigung nach BadO1 In Prozessdiagrammen werden solche bedingten Verzweigungen durch Entscheidungs ausdr cke guards an den Transitionen beschrieben Dieses Verfahren hat den Vorteil dass dort beliebig komplexe boolsche Ausdr cke benutzt werden k nnen Au erdem muss die Ausf hrung einer Aktion nicht explizit einen R ckgabewert produzieren der in den Guards abgefragt wird und so den weiteren Kontrollfluss steuert sondern man kann in den Guards beliebige XPath Ausdr cke angeben um direkt auf die Inhalte des Migrationsdokuments oder Umgebungsvariablen zuzugreifen vgl Abschnitt 6 2 4 Dieses Konzept ist viel m chtiger weil sich komplexere Entscheidungsbedingungen in Abh ngigkeit vom Zustand des Migrationsdokuments formulieren lassen als dies mit R ckgabewerten m glich ist Im brigen l sst sich das Konzept der R ckgabewerte auf das Guard Konzept abbilden indem der R ckgabewert einer Aktion einfach im Migrationsdokument oder einer Umgebungsvariable abgelegt und in nachfolgenden Guards abgefragt werden kann Das folgende Prozessdiagramm greift diese Methode auf und geht davon aus dass der R ckgabewert im XML Element lt return gt un
364. quenzdiagrammen die zeitliche Reihenfolge im Vordergrund steht lassen sich durch Kollaborationsdiagramme besonders gut die Beziehungen der Objekte zueinander ausdr cken Beide Diagrammarten haben den Nachteil dass sie bei komplexen Abl ufen gro und un bersichtlich werden Im Rah men der Gesch ftsprozessmodellierung ist ihre Aufgabe daher eher darin zu sehen ein zelne Ausschnitte eines Prozesses zu verdeutlichen die besonders kompliziert oder schwer verst ndlich sind Aufgrund ihrer netzartigen Struktur und der M glichkeit Aktivit ten durch Transitionen flexibel miteinander zu verketten sind Aktivit tsdiagramme in besonderer Weise daf r geeignet verschiedenste Abl ufe zu modellieren Sie werden in der Regel das bevorzugte Mittel sein um die dynamische Sicht auf einen Gesch ftsprozess zu beschreiben Ihre vielf ltigen Sprachkonstrukte reichen f r die meisten denkbaren Situ ationen aus Eine besondere St rke von Aktivit tendiagrammen liegt im Umgang mit parallelen Abl ufen die h ufig in Gesch ftsprozessen vorkommen Die UML Spezifikation OmgOl erlaubt es in Aktivit tszust nden oder Guard Bedingungen informelle Angaben ber die auszuf hrende Aktion zu machen Aus die sem Grund lassen sich Aktivit tendiagramme sowohl auf einer hohen konzeptionellen Ebene einsetzen als auch sehr implementierungsnah als Darstellung konkreter Programmabl ufe Es ist jedoch zun chst nicht m glich die Einhaltung fester Rahmen bedingu
365. r Transitionen keine expliziten Trigger Ereignisse angegeben werden Dies ist eine Versch rfung der Wohlgeformtheitsregeln 2 12 3 8 5 und 2 13 3 2 3 aus der UML Spezifikation Omg01 in denen der Gebrauch von Triggern bereits f r Aktivi t tendiagramme stark eingeschr nkt wird context Transition inv self trigger gt isEmpty 7 Bedingte Verzweigungen und Zusammenf hrungen Diamant Symbol m ssen in decision und merge unterscheidbar sein context PseudoState inv self kind junction implies self incoming gt size 1 and self outgoing gt size gt 1 or self outgoing gt size 1 and self incoming gt size gt 1 Ein solcher Knoten hat entweder nur eine eingehende und mehrere ausgehende Transi tionen decision oder umgekehrt mehrere eingehende aber nur eine ausgehende Transi tionen merge Eine Verzweigung mit sowohl mehreren eingehenden als auch mehre ren ausgehenden Transitionen kann durch die sequentielle Kombination eines merge und eines decision Knotens nachgebildet werden 8 Enth lt der in einem Guard angegebene Ausdruck Bez ge auf Elemente im Migra tionsdokument so beziehen sich diese auf das vom Ausgangsport des vorausgegange nen Zustands ausgegebene Dokument noch bevor es eventuell auf der Transition trans formiert wird Die verwendeten Elemente im Bedingungsausdruck des Guards m ssen f r die Struktur der durch den Port vorgegebenen Dokumenttypen wohldefiniert sein So darf ei
366. r die Prozessbeschreibung XML verwendet werden Damit ein Workflow Modell maschinell durch das WFMS ausgef hrt werden kann muss es m glich sein eine Zuordnung aller Modellelemente zu entspre chenden realen Komponenten zu definieren bzw Teilsysteme zu identifizieren die noch nicht existieren und daher neu entwickelt oder angeschafft werden m s sen vgl Geo95 S 129 Da diese Zuordnung nicht schon bei der Modellierung des Prozesses stattfinden muss kann man auch von dynamischer Bindung von Komponenten sprechen Das WFMS muss eine Art Interpreter Workflow Enactment Service vgl Wmc95 besitzen der die Kontrolle und Ausf hrung der Prozessinstanzen leis tet Er greift dazu auf die formale Beschreibung des Workflow Modells zur ck und muss f r die Ausf hrung aller anfallenden Aufgaben sorgen Dazu z hlt vor allem die Abarbeitung des Prozesses gem dem korrekten Kontrollfluss und das 30 10 11 12 13 14 Kapitel 3 Anforderungsanalyse Ansprechen der Back End Systeme sowie der Austausch von Daten mit diesen Systemen Im Anwendungsgebiet E Business ist davon auszugehen dass Gesch ftsvorf lle und damit die Ausf hrung von Prozessinstanzen durch Benutzeraktionen an einer internetbasierten Oberfl che ausgel st werden Das WFMS sollte daher die not wendige Funktionalit t besitzen um ein Web Portal als Benutzungsschnittstelle zu integrieren Als besonders flexibel stellt sich ein sogenannter Multi Channel
367. r die speziellen Anwendungs zwecke Dazu m ssen die genauen Strukturen der XML Formate durch Dokumenttyp definitionen und Schemata festgelegt werden Da nach der Verabschiedung des XML Standards nun der Einigung auf solche anwendungsspezifischen XML Formate eine essentielle Bedeutung zukommt werden in dieser Richtung intensive Angleichungs bestrebungen durchgef hrt Standards wie die Electronic Business XML ebXML siehe EbX01 definieren genaue Schemata und Regeln zur Erstellung von XML Dokumen ten mit dem Ziel die beim elektronischen Gesch ftsverkehr benutzten XML Formate zu vereinheitlichen und dadurch die Gesch ftsabwicklung zu vereinfachen Mit der in der Integrations ra zunehmenden Verbreitung von E Business L sungen und der Entstehung von virtuellen Marktpl tzen im Internet wird es f r die in diesem Umfeld t tigen Unternehmen immer wichtiger ihre existierenden Anwendungen und Softwaresysteme an diese neuen E Business Plattformen anzubinden Ein Beispiel Der Online Verkaufsauftritt eines Versandh ndlers im World Wide Web muss mit den internen Buchungssystemen des Unternehmens gekoppelt werden um einen effizienten Ablauf der anfallenden Transaktionen abwickeln zu k nnen In der Zeit vor der allge meinen Nutzung des Internets wurden die Bestellungen an den H ndler in der Regel papierbasiert oder telefonisch vorgenommen w hrend der Kommunikations ra dann zum Beispiel durch den Versand einer E Mail Doch auch nach Erhalt de
368. r elektroni schen Kauforder musste meistens immer noch jemand die Daten manuell in die Buchungssysteme des H ndlers eingeben was einen eigentlich vermeidbaren Ressour cen und Zeitaufwand bedeutet Besser w re es wenn der Kaufauftrag unmittelbar nach Empfang automatisiert verarbeitet und an die Buchungssysteme des Handelsunterneh mens weitergeleitet w rde Dieses Beispiel legt die Problemstellung offen die ein Unternehmen l sen muss um erfolgreich am elektronischen Gesch ftsverkehr teilnehmen und damit zukunfts f hig bleiben zu k nnen die Integration vorhandener Anwendungssysteme untereinan der und mit den E Business Systemen als Schnittstelle zu externen ber das Internet zu erreichenden Partnern Zulieferern und Kunden Dadurch k nnten die Funktionalit ten der einzelnen heterogenen Softwaresysteme geb ndelt und den Gesch ftspartnern ber das Internet verf gbar gemacht werden Zur Erreichung dieses Ziels sind eine Reihe von Fragestellungen zu beantworten 1 Wie bindet man die heterogenen Systeme an Es wird ein Verfahren ben tigt das in der Lage ist ganz beliebige Komponenten anzusprechen und deren Funktionen aufzurufen Dazu braucht man Schnittstellen um den Komponenten Eingabedaten zu schicken und Ausgabedaten von ihnen entgegenzunehmen 2 Wie kann man Gesch ftsprozesse die zwischen dem Unternehmen und seinen Kunden Partnern und Zulieferern ablaufen in das Integrationskonzept einflie en lassen Die Ausrichtung von
369. r gegebenen Quell und Zielport eine passende Trans formation definiert Abbildung 6 6 gibt einen berblick ber die Fragestellungen die durch das Port Konzept und die typisierten Transitionen in den folgenden Abschnitten gel st werden sollen Neben der Unterst tzung des Modellierers bei der Konsistenzwahrung kann eine genaue Modellierung der Dokumentstrukturen auch bei der Ausf hrung der Workflow Modelle n tzlich sein weil so das WFMS jederzeit die aktuelle Struktur des Migra tionsdokuments gegen den im Modell vorgegebenen Typ validieren und Abweichungen feststellen kann die durch Fehler bei der Ausf hrung verursacht worden sind 94 Kapitel 6 XML Prozesse und Prozessdiagramme Benutzt der Guard Ausdruck Welche Transformation der nur Elemente die in Dokumente ist bei dieser den Schemata zu den Typen Transition n tig um Port B von Port B definiert sind auf Port C abzubilden guard condition A Service i Service D S i S Welche Dokumenttypen k nnen vom Service S4 m glicherweise ausge geben werden Port B Welche Dokumenttypen kann der Service S verarbeiten Port C Abb 6 6 Fragestellungen bei der Modellierung der Dokumentstrukturen 6 3 1 Das Port Konzept zur Typisierung von Dokumenten Um ein konsistentes Prozessmodell zu erzeugen d rfen Services nur an f r sie passen den Stellen eingesetzt werden Insbesondere k nnen viele Services nur bestimmte Dokumenttypen verarbeite
370. r kaskadierenden Abbr che siehe Bac98 S 450 Im Bereich von Workflows reichen laut Studien wie beispielsweise Kon96 oder Day91 h ufig schw chere Anforderungen an Transaktionen als die herk mmlichen Es w re daher zu pr fen ob die Verletzung der Isolation m gli cherweise kein Problem darstellt und toleriert werden k nnte 10 4 Transaktionale Prozessausf hrung 231 Wir schlagen f r XML Prozesse vor dass es den Implementierungen der Services berlassen werden sollte welche der beiden Varianten zu bevorzugen ist Je nach Aufgabe des Service kann eine Variante vorteilhafter oder sinnvoller sein als die andere Abschlie end sei bemerkt dass das Zwei Phasen Commit Protokoll von der fehlerfreien Ausf hrung der Operationen Commit und Abort ausgeht d h wenn ein Service bei seinem Aufruf keinen Fehler gemeldet hat so darf sp ter beim Ausf hren von Commit oder Abort auch kein Fehler mehr auftreten siehe Bac98 S 501 Wenn dies nicht sichergestellt werden kann m ssen weitergehende Konzepte entwickelt werden auf die im Rahmen dieser Arbeit jedoch nicht eingegangen werden kann Fehlerbehandlung durch den Prozess Bei den bisherigen berlegungen sind wir davon ausgegangen dass ein transaktionaler Prozess abgebrochen werden muss sobald in einem Service ein Fehler auftritt Wie schon im Abschnitt 10 3 2 dargelegt kann es jedoch Situationen geben in denen die Behandlung von Fehlern explizit im Prozessmodell ber cksichtigt werde
371. r restriktiv als der Gebrauch der vordefinierten Erweiterungsmechanismen und kann leicht zu Inkom patibilit ten mit der standardm igen UML Definition f hren Daher wollen wir diesen Ansatz hier nicht weiter verfolgen sondern im Folgenden die expliziten Erweiterungs konstrukte vorstellen um mit ihnen sp ter eine UML Erweiterung f r den Entwurf von Prozessdiagrammen zu entwickeln vgl Abschnitt 7 3 Die drei Erweiterungsmechanismen Stereotype Tagged Values und Constraint sind fest im Metamodell der UML verankert Sie erlauben es die vorhandenen Meta Elemente der UML flexibel anzupassen und somit f r bestimmte Prozesse oder Imple mentierungssprachen UML Erweiterungen zu definieren Neben dem Erg nzen der semantischen Informationen lassen sich so auch nicht semantische also etwa syntakti sche nderungen vornehmen Die gesamte Menge der f r ein bestimmtes Anwen dungsgebiet definierten Spracherweiterungen werden schlie lich zu einem Profil zusammengefasst siehe OmgOl 2 74 und dem in dem speziellen Anwendungsfeld t tigen Modellierer zur Verf gung gestellt Der folgende Auszug aus dem UML Metamodell verdeutlicht in einem ersten berblick die Zusammenh nge zwischen den einzelnen Erweiterungsmechanismen auf die in den folgenden Abschnitten noch n her eingegangen wird 7 2 UML Erweiterungsmechanismen 127 Modelziement referenceValue from Core extendedElement constrainedElement
372. r vorgestellten Konzepte 3 1 Fallstudie E Business Plattform eines gro en Finanzunternehmens In dieser Fallstudie sollen anhand eines Pilotprojektes bei der Deutschen Bausparkasse Badenia AG einem f hrenden Finanzunternehmen unter den privaten Bausparkassen in Deutschland die Ziele Anforderungen und Architekturvorschl ge vorgestellt werden die dieses Unternehmen f r den Aufbau einer E Business Plattform in einem Anforde rungskatalog aus Bad01 festgehalten hat Da eine zentrale Komponente der neuen Plattform ein Workflow Management System sein soll wollen wir auf diese Weise untersuchen welche Anforderungen sich in der Praxis an solche Systeme ergeben 3 1 1 Projektziele Mit der Durchf hrung des Pilotprojektes strebt die Badenia Bausparkasse den Aufbau einer flexiblen und hochmodernen E Business Plattform an Dabei sollen zunehmend konventionelle Informationsprozesse auf Formular und Papierbasis durch elektronische Prozesse ersetzt werden die ber das Internet oder das firmeneigene Intranet aufgerufen werden Statt der Arbeit mit Formularen und der anschlie enden manuellen Eingabe der Daten zur Verarbeitung mit den existierenden Softwaresystemen sog Back End Systemen will man in Zukunft die Daten ber unterschiedlichste elektronische Schnitt stellen ein und ausgeben und mit den Back End Systemen kommunizieren k nnen Neben der R stung f r den wachsenden Bedarf an E Business Unterst tzung seitens der Kunden und Gesch
373. rationsdatei die sogenannte Sitemap in der alle Ressourcen die dem Webserver bekannt sein sollen in einer speziellen XML Sprache aufgelistet sind Bislang enth lt sunShine kein Werkzeug mit dem sich solche durch Pipelines realisierte Workflow Beschreibungen auf abstrakter Ebene grafisch modellie ren lassen Ebenso wenig ist eine Unterst tzung bei der Analyse und Optimierung von Prozessen vorgesehen Eine Pipeline besteht aus einem Generator beliebig vielen Transformern und endet mit einem Serializer Ein Generator stellt die Verbindung zur Datenquelle dar aus der das XML Dokument stammt Er liefert als Ergebnis die gelesenen XML Daten die dann zur Verarbeitung an den ersten Transformer weitergeleitet werden Wie bereits weiter oben erw hnt kennt sunShine Generatoren f r Datenbanken Dateien HTTP Server usw Die Verarbeitung der XML Daten durch Transformer ist die wichtigste Aufgabe einer Pipeline daher ist diesem Bereich ein eigener Abschnitt gewidmet siehe Abschnitt 4 3 3 Wenn die Verarbeitung der XML Daten abgeschlossen ist werden sie an einen Serializer weitergeleitet Dieser formatiert das XML Dokument indem bei spielsweise berfl ssige Leerzeilen entfernt werden und bergibt es dem Webserver der es als Ergebnis der Anfrage an das Endger t sendet Abbildung 4 5 zeigt beispielhaft die Ausf hrung einer Pipeline 46 Kapitel 4 Evaluierung vorhandener Workflow Systeme Webserver HTML Dokument Tr
374. rchitektur von sunShine bernimmt diese Trennung der drei Ebenen und erg nzt sie um die notwendige Funktionalit t zur Erstellung von Portalen sunShine enth lt dar ber hinaus mehrere Tools die bei der Erstellung und Verwaltung von Por talen unterst tzen wie beispielsweise ein Content Management System zur Verwaltung der Inhalte des Portals 4 3 E Business Plattform sunShine 45 4 3 2 Workflow Ausf hrung mit sunShine Hinter jedem Portal k nnen sich Gesch ftsprozesse verbergen die die anfallenden Daten verarbeiten Einen solchen Gesch ftsprozess stellt beispielsweise die durchzuf h rende Verarbeitung dar wenn ein Kunde eines Online Banking Systems eine Konto transaktion veranlasst sunShine bietet durch das Konzept der sogenannten Pipelines die M glichkeit einfache Prozesse zu beschreiben vgl Lau00 Da sunShine vollst ndig XML basiert ist wird vorausgesetzt dass die zu verarbeitenden Daten in Form von XML Dokumenten vorliegen Als Black Box betrachtet erh lt eine Pipeline ein XML Dokument als Eingabe f hrt abh ngig von seinem Inhalt Verarbeitungsaktionen durch und gibt schlie lich ein manipuliertes XML Dokument aus XML Eingabe EN XML Ausgabe dokument Pipeline dokument re Abb 4 4 Pipeline Konzept Jeder Pipeline ist eine URL zugeordnet durch deren Angabe sie beim Webserver ange sprochen werden kann Man spricht daher im Umfeld von Cocoon auch von einer Ressource Cocoon kennt eine Konfigu
375. rden der Modellierer muss sich jedoch bewusst dar ber sein dass f r sie die Atoma rit t nicht sichergestellt werden kann 230 Kapitel 10 Ausf hrung von XML Prozessen 10 4 3 Fehler bei der Ausf hrung von Services Prinzipiell sind zwei Arten von Fehlern denkbar die dazu f hren k nnen dass ein Prozess abgebrochen werden muss Zum einen kann bei der Ausf hrung eines Service ein Fehler auftreten dieser Fall soll in diesem Abschnitt betrachtet werden Zum ande ren kann ein Fehler oder Ausfall im Interpreter in seiner Rolle als Transaktionsverwalter auftreten siehe Abschnitt 10 4 4 Zur Behandlung von Fehlern die w hrend der Ausf hrung von Services auftre ten kann das Zwei Phasen Commit Protokoll f r verteilte Transaktionen verwendet werden siehe Bac98 S 502ff Dabei sammelt der Prozessinterpreter als zentraler Verwalter die Ergebnisse aller Services Phase 1 Nur wenn alle Services fehlerfrei ausgef hrt wurden kann die Transaktion best tigt werden und die Commit Entschei dung wird allen Services mitgeteilt Phase 2 Falls jedoch Fehler aufgetreten sind lautet die Entscheidung Abort was ebenfalls allen Services mitgeteilt wird Ma nahmen zur Fehlerbehandlung Es stellt sich nun die Frage welche Bedeutung das Senden einer Commit oder Abort Nachricht an einen Service f r sein Verhalten hat Es gibt daf r prinzipiell zwei verschiedene M glichkeiten 1 Wenn der Service innerhalb eines transaktionalen Prozesses a
376. rden auch die Anforderungen aus der Anforderungsanalyse Ka pitel 3 als Ma stab herangezogen Diese fu t auf einer vorab durchgef hrten Fallstudie Abschnitt 3 1 in der Anforderungen einer gro en deutschen Bausparkasse untersucht wurden die in einem Pilotprojekt ihre Gesch ftsprozesse ber eine E Business Infrastruktur f r Kunden und Au endienstmitarbeiter verf gbar machen und dabei ihre vorhandenen Informationssysteme einbinden m chte Eingeflossen sind aber auch Anforderungen die allgemein im Zusammenhang mit Workflow Management im E Business auftreten und im Kapitel2 ber die Grundlagen des Workflow Managements betrachtet wurden Anhand der festgestellten Anforderungen erfolgte zun chst eine Evaluierung der vorhandenen Systeme Microsoft BizTalk WARP und sunShine Kapitel 4 um einen Einblick in den derzeitigen Stand der Technik zu geben Dabei zeigte sich bei BizTalk 246 Kapitel 12 Schlussbetrachtungen und WARP siehe 4 1 und 4 2 ein gro er Mangel bei der Unterst tzung des Modellie rers durch Konsistenzpr fungen zur Fehlervermeidung sowie der Realisierung eines Multi Channel Ansatzes und der M glichkeit zur Integration in ein Unternehmens portal was f r den Einsatz im E Business zum Beispiel f r virtuelle Marktpl tze sehr hilfreich w re Letzteres wird zwar vorbildlich von der E Business Plattform sunShine der S amp N AG gel st siehe 4 3 sie weist aber andere Schw chen auf die sich vor allem aus unzur
377. ren zum Beispiel alle Klassen die mit der Behandlung von Ereignissen zu tun haben z B Event siehe OmgO0l Abb 2 24 oder die Zust nde beschreiben die in Prozessdiagrammen nicht vorkommen k nnen z B ObjectFlowState siehe OmgOl Abb 2 30 Im unteren Teil der Abbildung befinden sich die Stereotypen die zur Erweite rung von Syntax und Semantik der konventionellen Aktivit tendiagramme erg nzt wur den Nach dem UML Metamodell befinden sich diese Stereotypen Konzeptionell auf der Ebene unterhalb des eigentlichen Metamodells sie erf llen jedoch hnliche Funktionen wie die Metaklassen da auch sie zur Klassifizierung von Modellelementen benutzt werden sollen Man spricht in diesem Zusammenhang auch von virtuellen Metaklas sen siehe Omg01 2 78 146 Kapitel 7 Metamodell f r Prozessdiagramme metaclass Metamodell ModelElement metaclass u GeneralizableElement metaclass 2 toutgoing metaclass 0 1 metaclass A StateVertex 1 Mangel Angaming Transition Guard Ab A A l i i i i m mas dod aee
378. rgabe von Parametern an Komponenten Beim Aufruf einer Komponente m ssen Parameter bergeben werden k nnen F r dieses Konstrukt der Prozess diagramme ist eine ad quate Repr sentation in der XML Beschreibung n tig 5 Beschreibung von Nebenl ufigkeit und Synchronisation Eine parallele Ausf h rung mehrerer Kontrollflussstr nge und ihre Synchronisation muss analog zu den Pro zessdiagrammen auch in der XML Beschreibung spezifizierbar sein 8 1 Anforderungen an Prozessbeschreibungssprachen 163 6 Beschreibung von Entscheidungsbedingungen an Verzweigungen Eine Transi tion nach einer Verzweigung kann im Prozessdiagramm eine Bedingung bzw Guard enthalten Entsprechend m ssen Transitionen in der XML Beschreibung mit Entschei dungsbedingungen auszustatten sein 7 Schachtelung von Prozessteilen Analog zur Hierarchisierung von Prozessdia grammen muss ein hnlicher Mechanismus f r die XML Beschreibung der Workflows vorhanden sein Andere Prozesse die ihrerseits als XML Dokument beschrieben sind m ssen zum einen aufgerufen sowie zum anderen mit ihrer Beschreibung direkt in den bergeordneten Prozess eingebettet werden k nnen 8 Angabe von Ports zur Modellierung von Dokumenttypen Entsprechend dem Port Konzept f r die Modellierung der Dokumenttypen in Prozessdiagrammen vgl Abschnitt 6 3 m ssen Portdefinitionen in die Prozessbeschreibung integriert werden Diese Informationen werden sowohl bei der Modellierung als auch bei der
379. rif fen Laut Bac98 S 311ff ist ein Monitor eine Klasse die bestimmte Daten kapselt Alle Operationen auf diesen Daten werden unter gegenseitigem Ausschluss d h als kritischer Abschnitt ausgef hrt Zus tzlich findet eine Bedingungssynchronisation statt damit sich die Daten stets in einem g ltigen Zustand befinden Eine Operation muss ggf solange warten bis die Daten sich in einem Zustand befinden der garantieren kann dass die Daten nach Ausf hrung der Operation ebenfalls konsistent sind Die Klasse SynchMonitor wurde nach diesem Prinzip realisiert SynchMonitor signalSynchState synchState AbstractState document Document Void waitForSynchState synchState AbstractState Document Abb 10 9 Synchronisationsklasse SynchMonitor Durch Aufruf der Methode signalSynchState signalisiert ein Prozess seine Ankunft an einem bestimmten Synchronisationszustand Er muss dabei neben einer 10 2 Der Prozessinterpreter 223 Referenz auf diesen Zustand auch eine Kopie seines aktuellen Migrationsdokuments bergeben da dieses vom Synchronisationspartner ben tigt wird Dieser ruft die Methode waitForSynchState auf wenn er an dem Zustand ankommt Falls der Partner noch nicht signalisiert hat muss der Prozess solange warten Andernfalls bekommt er das Dokument des Partners zur ckgeliefert das dieser im Monitor abgelegt hat Es wird dann gem Abschnitt 6 2 5 ein neues Dokument zusammengesetzt das der Prozess anschl
380. rozessdiagramm m ssen immer mit dem Stereotyp stateWithPorts klassifiziert sein da alle Zust nde mit Ports versehen sein m ssen vgl Ab schnitt 6 3 1 context StateVertex inv self isStereotypedAs stateWithPorts or self isStereotypedAs serviceState 2 F r einfache Zust nde SimpleState d rfen lediglich CallStates in Verbindung mit dem Stereotyp serviceState benutzt werden context SimpleState inv self ocll1sKindOf CallState and self isStereotypedAs serviceState 3 Wenn ein StateVertex kein FinalState oder PseudoState ist muss er genau eine ein gehende und eine ausgehende Transition haben Diese Regel gilt somit f r alle SimpleState SynchState und CompositeState Instanzen PseudoState Instanzen wie Startzustand oder Verzweigung sind ausgenommen context StateVertex inv if not self oclIsKindOf FinalState or self oclIsKindOf PseudoState then self incoming gt size 1 and self outgoing gt size 1 4 F r geschachtelte Aktivit ten in Prozessdiagrammen d rfen lediglich nur wieder Pro zessdiagramme benutzt werden context SubactivityState inv self submachine isStereotypedAs processDiagram 5 Transitionen m ssen immer mit dem Stereotyp typedTransition klassifiziert sein context Transition inv self isStereotypedAs typedTransition 144 Kapitel 7 Metamodell f r Prozessdiagramme 6 Da auf die Behandlung von Ereignissen verzichtet wurde siehe Abschnitt 6 2 6 d rfen f
381. rozessen in XML Objektstruktur noch nicht vollst ndig aufgebaut werden W hrend des Importvorgangs merkt sich der Importer daher zun chst zu jeder Transition die eindeutige Knotenidenti fikation siehe Abschnitt 8 3 3 ihres Zielzustands Erst wenn das gesamte PML Dokument verarbeitet ist also alle Zust nde importiert wurden wird zu jeder Transition der Zielzustand gesetzt Je nachdem zu welchem Zweck ein Prozessmodell importiert werden soll m s sen w hrend des Importvorgangs zus tzliche Berechnungen stattfinden So muss beispielsweise der Prozesseditor zu jedem Modellelement die von ihm ben tigten Adapter erzeugen vgl Abschnitt 7 4 Flexible Zugriffsschicht auf Elemente des Datenmodells und im Falle eines Prozesszustands zus tzlich die Koordinaten f r die grafische Darstellung des Diagramms laden Um den Importer f r solche Anforderun gen flexibel zu gestalten haben wir unter Einsatz des Entwurfsmusters Observer das dazu dient Nachrichtenempf nger ber bestimmte Ereignisse zu informieren siehe Gam96 S 287 die Klasse ImportObserver realisiert zu der der Importer eine Asso ziation besitzt Immer wenn ein Modellelement importiert wurde wird die zugeh rige Methode des Observers aufgerufen und bekommt das Modellelement bergeben Man muss eine Unterklasse von ImportObserver implementieren die die Methoden ber schreiben und die gew nschten Berechungen durchf hrt Falls dazu Daten aus dem Extensions Bereich des PML Do
382. rst ndlich Ablauforientiert Alle Basiskontrollfluss Konstrukte Ein Start und ein Endpunkt XML Dokumentfluss Zugriff auf XML Dokumente Integration von Softwarekomponenten Parametrisierung der Komponenten Geschachtelte Prozesse Hierarchie Statisches Modell der Komponenten Transaktionale Prozesse Pr zise Eindeutige Semantik Tab 6 3 Bewertung von Prozessdiagrammen Die Forderung nach der Einbindung vorhandener Softwarekomponenten wurde f r XML Prozesse durch das im Abschnitt 6 1 2 eingef hrte Konzept der Komponenten integration mittels Konnektoren umgesetzt Dadurch ist das WFMS in der Lage nahezu beliebige Systeme anzusprechen Das Problem der heterogenen Schnittstellen wird f r das WFMS transparent innerhalb der Konnektoren gel st Um solche Komponenten in einem Workflow Modell zu verwenden bietet die Modellierungssprache geeignete Konstrukte Dabei ist es nicht nur m glich bereits vorhandene Systeme als Aktivit ten zu verwenden Zun chst kann ein abstraktes Modell des Workflows entworfen werden um sp ter den einzelnen Aktivit ten konkrete Ausf hrungsinstanzen zuzuordnen Auch die bergabe von Parametern an die eingesetzten Komponenten wird im Ansatz der XML Prozesse ber cksichtigt 120 Kapitel 6 XML Prozesse und Prozessdiagramme Der geforderten Verarbeitung von XML Dokumenten wurde durch die Anleh nung an das Dokumentmigrations
383. rter und PML Exporter vorgestellt die vom Editor zum Speichern und Laden von Prozess modellen verwendet werden Die Implementierung des Editors umfasst ca 15 000 LOC lines of code 9 2 Bedienung des Prozesseditors Wenn der Prozesseditor gestartet wird erscheint das Hauptfenster Es enth lt eine Men leiste mit dem Eintrag File Dort l sst sich das Programm beenden oder eine der beiden Aktionen New Project oder Load Project ausw hlen Durch New Project kann man ein neues Projekt siehe Abschnitt 9 2 1 anlegen Es erscheint ein Eingabe dialog in dem der gew nschte Name eingegeben werden muss Dieses Projekt ist dann ge ffnet und kann bearbeitet werden Alternativ l sst sich mit Load Project ein beste hendes Projekt ffnen Mit Hilfe eines Dateiauswahldialogs kann die gew nschte Pro jektdatei ausgew hlt werden Nach beiden Aktionen pr sentiert sich die Oberfl che des Programms wie in Abbildung 9 1 gezeigt Neben der Men leiste die nach wie vor die beiden oben genannten Aktionen anbietet besteht das Hauptfenster aus zwei Teilen Auf der linken Seite befindet sich der sogenannte Projektbaum siehe Abschnitt 9 2 2 der alle Bestandteile des ge ffne ten Projekts zeigt Im rechten Bereich des Fensters erfolgen die Benutzereingaben Hier werden abh ngig davon welcher Bestandteil des Projekts im Projektbaum angew hlt ist Eingabemasken eingeblendet die Ver nderungen am Workflow Modell erm gli chen
384. rts der f r den Service definiert wurde Der gebundene offene Port des Service muss Teilport sein Subaktivit t Eingangsport des ein gebundenen Prozesses Ausgangsport des einge bundenen Prozesses N Startzustand Eingangsport des Eingangsport des Prozesses Startzustands Endzustand any Ausgangsport des Vorg ngers bernehmen copyRoot copySubs Synchronisation any Ausgangsport des Vorg ngers bernehmen Oder Verzweigung decision any Ausgangsport des Vorg ngers bernehmen Oder Zusammenf hrung merge any Vereinigung der Vorg ngerports aller o e gt eingehenden Transitionen Und Verzweigung fork any Ausgangsport des h gt Vorg ngers bernehmen Und Zusammenf hrung join any lt join gt Kartesisches Produkt ber alle Vorg n gerports f r Unterelemente Tab 6 2 Ports bei verschiedenen Zustandsarten 104 Kapitel 6 XML Prozesse und Prozessdiagramme Die oben dargelegten Festlegungen f r die Ports der einzelnen Zust nde im Prozess diagramm werden in Abschnitt 7 3 2 als Randbedingungen der Sprachelemente von Prozessdiagrammen noch einmal formal definiert F r das Konzept der Ports zusammen mit den typisierten Transitionen die im folgenden Abschnitt vorgestellt werden folgt in Abschnitt 6 3 3 eine theoretische Formalisierung 6 3 2 Wiederverwendbarkeit und Konsistenz durch typisierte Transitionen Bisher haben wir Ports an den Ein
385. rungen an e die Behandlung Workflow relevanter Daten in Form eines Eingabedokumentes die Verarbeitung der Dokumente die flexible Einbindung von bestehenden Softwarekomponenten die dynamische Bindung von Komponenten an Modellelemente und die Rolle eines Interpreters zur Kontrolle und Ausf hrung der Prozessinstanzen 6 1 1 Dokumentmigration Wie in der Fallstudie aus Abschnitt 3 1 aufgezeigt werden elektronische Gesch fts vorg nge in der Regel durch den Eingang eines bestimmten Dokumentes ausgel st Dieses Dokument repr sentiert eine Anfrage an die E Business Plattform und muss von dieser in geeigneter Weise bearbeitet werden um die Anfrage zu beantworten und die gew nschten Informationen zu beschaffen oder zu berechnen Im Referenzmodell der Workflow Management Coalition werden die Daten eines solchen Dokuments die dem WFMS bei der Initialisierung eines Prozesses bergeben werden m ssen als Workflow relevante Daten bezeichnet siehe Wmc95 S 14 26 Die Beantwortung der Anfrage nach der Verarbeitung des Dokumentes erfolgt durch die R ckgabe der Ergebnisdaten zum Beispiel an einen Web Browser oder ein anderes vom Klienten eingesetztes End ger t Diese R ckgabedaten k nnen gleichfalls wie das Paket der Eingabedaten als Dokument aufgefasst werden Die Ausl sung eines Vorgangs durch das Eintreffen eines Dokumentes das gegebenenfalls den n tigen Vorgangstyp selektiert und weitere Parameterwerte f r die Durchf hrung des Vorgang
386. rungen selbst siehe Ab schnitt 7 3 soll auch die Beschreibung der Semantik anhand der definierten UML Stereotypen erfolgen Stereotyp processDiagram Jedem Prozessdiagramm ist das Stereotyp processDiagram zugeordnet so dass es die Attribute inputPort und outputPort besitzt um Ein und Ausgangsport zu spezifizie ren Nur wenn ein XML Dokument konform zum Eingangsport ist kann es entspre chend der definierten Semantik durch den Prozess verarbeitet werden Bei erfolgreicher Ausf hrung des Prozesses entspricht es anschlie end dessen Ausgangsport Wurde zus tzlich das Attribut transactional gesetzt so wird der Prozess entweder vollst ndig oder gar nicht ausgef hrt nicht jedoch teilweise Wenn bei seiner Ausf hrung ein Feh ler auftritt ist daf r zu sorgen dass alle Effekte die sich bis dahin ergeben haben zur ckgef hrt werden so dass sich das System wieder im Ausgangszustand befindet vgl auch Abschnitt 10 4 Stereotyp stateWithPorts Das Konzept der Ports die in Abschnitt 6 3 eingef hrt wurden hat zun chst eine wich tige Bedeutung bei der Modellierung von Prozessdiagrammen um Inkonsistenzen so fr h wie m glich zu erkennen oder zu vermeiden Sie bieten jedoch auch die M glich keit bei der Ausf hrung eines Prozesses Konsistenzpr fungen durchzuf hren Jedem Zustand eines Prozessdiagramms sind ber das Stereotyp stateWithPorts Ports zuge ordnet Bevor die Aktion die mit einem Zu
387. runter Ereignisdiagramme Zustandsdiagramme und Petri Netze In den folgenden Abschnitten sollen Aktivit tendiagramme vorgestellt und ihre Eignung f r die Model lierung von Gesch ftsprozessen untersucht werden 5 3 1 Basiskonstrukte von Aktivit tendiagrammen Ein Aktivit tendiagramm ist laut UML Spezifikation siehe OmgOl 3 161 eine spe zielle Zustandsmaschine in dem Zust nde als Aktivit ten interpretiert werden K nnen Eine Aktivit t wird grafisch durch einen Rahmen dargestellt bei dem obere und untere Kante gerade Linien und linke und rechte Kante konvexe B gen sind vgl Tabelle 5 2 Die Aktivit ten sind verbunden durch Transitionen welche als Pfeile dargestellt wer den Dabei hat jede Aktivit t mindestens je eine Eingangs und Ausgangsaktivit t Die Ausf hrung einer Aktivit t wird ausgel st sobald alle ihre Eingangsaktivit ten beendet sind Zur besseren bersichtlichkeit der Diagramme ist es m glich komplette Teildia gramme in eine Aktivit t des bergeordneten Diagramms einzubetten bzw darauf zu verweisen Das Teildiagramm wird dann ausgef hrt wenn die Ausf hrung des berge ordneten Diagramms bei der entsprechenden Aktivit t ankommt Man spricht dabei auch von Subaktivit tszust nden Zus tzlich zu den beiden grundlegenden Elementen Aktivit t und Transition besitzen Aktivit tendiagramme eine Reihe weiterer Sprachelemente um spezielle Situ ationen im Kontrollfluss zu beschreiben Mit Hilfe von Verzweigung
388. rvice denkbar Es soll davon ausgegangen werden dass dieser Service aus einem beliebigen Dokument mit Unterelement lt sqlStatement gt selbiges herausfiltert und nach Ausf hrung des SQL Befehls durch lt sqlResult gt ersetzt Die folgende Abbildung zeigt die zugeh rigen Ports OutputPort InputPort a 3 3 EcopySubs_except sqlStatement Statisches Modell any sqlStatement 2 sqlResult SQL Service Offener Port wird an den Ausgangsport des Vorg ngers gebunden Prozessdiagramm zu sqlResult x Service Y sqlResult y Abb 6 14 Bindung eines offenen Ports mit ausgenommenen Unterelementen Wie die Bindung eines offenen Ports an einen anderen Port und die dabei vorgenom mene Ersetzung der Platzhalter definiert ist und berechnet wird zeigt die formale Fun dierung im bern chsten Abschnitt Es sei darauf hingewiesen dass jeder Port als offe ner Port betrachtet werden kann denn ein offener Port muss nicht sondern kann die Platzhalter copyRoot und copySubs enthalten Umgekehrt ist jedoch nicht jeder offene Port auch ein Port jedenfalls dann nicht wenn er einen der Platzhalter tats ch lich enth lt erst durch die Bindung wird er zu einem nicht offenen Port Im formalen Modell aus Abschnitt 6 3 3 wird dies durch die Beziehung Ports c OpenPorts ausge dr ckt Zusammenfassend l sst sich sagen dass offene Ports mit ihren zus tzlichen Platzhaltern copyRoot und copyS
389. rw hnen ist dass alle nderungen die am Workflow Modell vorgenommen wurden erst dann dauerhaft bernommen werden wenn das Projekt gespeichert wird 9 2 2 Ansicht des Projektbaums Im linken Teil des Editorfensters befindet sich eine hierarchische Ansicht Baum aller Bestandteile des Projekts Den Wurzelknoten dieses Baums bildet das Projekt selbst Unterhalb davon befinden sich alle Packages die dem Projekt hinzugef gt wurden Jedes Package enth lt wiederum seine Konnektoren Transitionstypen und Prozesse Konnektoren haben als Unterknoten die in ihnen enthaltenen Services Prozesse eine 194 Kapitel 9 Modellierungswerkzeug f r Prozessdiagramme Liste aller ihrer Zust nde und Transitionen Alle Aktionen die im Editor m glich sind werden durch Popup Men s aufgerufen die angezeigt werden wenn der Benutzer mit der rechten Maustaste einen Knoten des Projektbaums ausw hlt Abh ngig von der angew hlten Komponente erscheinen dabei unterschiedliche Men s Ei sunFkom Process Edito ahire swi ange Save Froject Aa Gitse Project Mes Package Load Package Froject Hame festroiekt Abb 9 2 Popup Men s im Projektbaum F r den Projektknoten stehen beispielsweise folgende Aktionen zur Verf gung Save Project Diese Aktion speichert alle nderungen die vorgenommen wurden dauerhaft im Workflow Modell Falls das Projekt zuvor noch nicht mindestens einmal gespeichert wurde erscheint ein Dateiauswahldialog Dort kann ein
390. s Sinnvoll sind in diesem Zusammenhang nur solche Ports die zum Quellport kompatibel sind und damit berhaupt als Vorg nger im Kon trollfluss des Diagramms in Frage kommen Somit ergibt sich folgende Definition f r Transitionstypen Def 6 16 Transitionstypen TTypes source target trans source e Ports target e OpenPorts trans Transformationsfunktion kodiert in XSL trans L source gt JL binding target p pePorts pssource V x e L source V pe Ports mit p lt source xe L p trans x e L binding target p Die obige Randbedingung an die Funktion trans besagt dass alle X lt ML Dokumente aus der Dokumentmenge eines Ports p der zum Quellport source des Transitionstyps kompatibel ist p lt source durch die Funktion trans so abgebildet werden dass sie zur Dokumentmenge des Zielports target gebunden an eben jenen Ausgangsport p geh ren Diese Bedingung ist n tig damit target gebunden an p Ausgangsport einer Tran sition ist wenn p der Eingangsport ist und die Transformationsfunktion dann auch tats chlich zwischen diesen Ein und Ausgangsports abbildet Die folgende Definition von typisierten Transitionen stellt einen solchen Fall dar wobei der Eingangsport input die Rolle des Ports p bernimmt 118 Kapitel 6 XML Prozesse und Prozessdiagramme Def 6 17 Typisierte Transitionen Transitions input output type input e Port output e Port type source target trans e TTy
391. s Datenformat f r Metadaten unterst tzt wird w re eine Konvertie rungsm glichkeit zwischen XMI und PML Dokumenten sinnvoll Dazu k nnte zum Beispiel zus tzlich zur Definition von PML ein XSL Stylesheet zur Konvertierung von und nach XMI angegeben werden womit es unter der Voraussetzung dass ein CASE Tool die Spezifikationen von UML und XMI voll unterst tzt m glich w re auch Pro zessdiagramme mit diesem Werkzeug zu editieren Da mit den Erweiterungsmechanis men und Stereotypen jedoch ein Randbereich der UML betreten wird fehlt bei vielen Werkzeugen noch deren vollst ndige Unterst tzung Diese Tatsache hat die Entwick lung eines eigenen Editors f r Prozessdiagramme n tig gemacht vgl Kapitel 9 172 Kapitel 8 Beschreibung von Prozessen in XML 8 3 Process Markup Language PML In diesem Abschnitt soll nun die von uns entwickelte XML basierte Prozessbeschrei bungssprache PML Process Markup Language vorgestellt werden die speziell zur textuellen Repr sentation von Prozessdiagrammen vorgesehen ist Dazu definieren wir PML als XML Sprache durch Angabe eines XML Schemas siehe XSchO1 Alle Informationen eines Prozessdiagramms sind dabei in der zugeh rigen PML Beschrei bung enthalten Somit ist es m glich aus einem PML Dokument ein Prozessdiagramm zu rekonstruieren Soweit m glich wurden die Einschr nkungen die f r Prozess diagramme in Form von UML Constraints formuliert wurden mit Hilfe von Sprachkon strukte wie V
392. s Metamodell f r Prozessdiagramme implementiert werden soll bietet es sich an bei der Implementie rung die Ebenentrennung aufzuheben und die vorgenommenen Erweiterungen und Stereotypen gleichwertig zu den Original Metaklassen in der Modellimplementierung f r Prozessdiagramme zu integrieren Zur Verschmelzung der beiden Ebenen kommen zwei Techniken zum Einsatz Zum einen kann ein Stereotyp dadurch ersetzt werden dass seine Tag Definitionen die neue Meta Attribute der Basisklasse darstellen sollen direkt als zus tzliche Attribute dieser Basisklasse hinzugef gt werden Zum anderen kann man eine Unterklasse der originalen Basisklasse bilden die dann alle Eigenschaf ten des Stereotyps mit den geerbten Attributen und Methoden der Basisklasse vereinigt Zus tzlich zu der Verschmelzung von Metaklassen und Stereotypen wurden noch einige weitere Metaklassen angepasst und f r unsere Zwecke optimiert auf die wir an den entsprechenden Stellen noch jeweils n her eingehen werden Vielfach wurden zum Bei spiel die Vererbungshierarchien bereinigt und berfl ssige Vererbungsstufen entfernt Im Folgenden werden nun die Klassenstrukturen des implementierten Meta modells f r Prozessdiagramme als Klassendiagramme dargestellt Dabei erfolgt zu n chst die Pr sentation der elementaren Datentypen dann der Metaklassen f r statische Diagrammelemente und schlie lich der Metaklassen f r die dynamischen Modell elemente von Prozessdiagrammen Es wird jeweils da
393. s Weiterverarbeitung oder Spei cherung zu bergeben Zu diesem Zweck m ssen die Komponenten die Ziel dieses Datentransfers sind eine Schnittstelle zum Empfang der Daten bereit stellen Gegebenenfalls ist au erdem noch eine Konvertierung des Datenformats n tig wenn ein spezielles zum internen Format des Workflow Management Systems inkompatibles Datenformat von der Zielkomponente gefordert wird bernahme von Daten aus externen Quellen wie Datenbanken und Appli kationen Ein analoges Problem zur bergabe von Daten beim Benutzen der existierenden Komponenten ist das Entgegennehmen der Ergebnisse nachdem eine Komponente eine gew nschte Funktion ausgef hrt oder eine Datenbank eine bestimmte Anfrage durchgef hrt hat Schwierig wird diese Aufgabe bei einer gro en Anzahl verschiedener Datenbanken wie sie sich in gro en ver teilten Unternehmen finden lassen Spezielle Treiber und Konvertierungs programme m ssen unter Umst nden f r die Ansteuerung der Anwendungen und Datenbanken sowie f r die Konvertierung und Aufbereitung der Daten sorgen Nach B hm siehe B h95 stellt die Integration bestehender Anwendungen ein nicht zu untersch tzendes Problem bei der Einf hrung von Workflow Management Systemen dar weil f r den Daten und Informationsaustausch h ufig Schnittstellen erweiterungen zu den existierenden Anwendungen mit gro em Aufwand realisiert wer den m ssen Mit dieser Problematik werden wir uns auch in dieser Arbe
394. s ben tigten Daten an einer zentralen und von berall erreichbaren Stelle abgelegt und brauchen nicht explizit ber geben zu werden Die beiden Ans tze Dokumentmigration und Verwendung eines zentralen Spei chers entsprechen den Konzepten Kommunikation und Kooperation zum Datenaus tausch im Bereich der verteilten Systeme siehe Wet93 S 110f Direkter Datenaus tausch kann dabei als Kommunikation aufgefasst werden da eine bertragung von Daten stattfindet w hrend indirekter Datenaustausch eine Kooperation mittels gemein samem Speicher darstellt Beide Ans tze sind laut Hei00A zun chst lediglich als konzeptuelle Modelle zu sehen Bei der Realisierung k nnen sie jedoch aufeinander abgebildet werden und sind aus diesem Grund als gleichm chtig anzusehen Auch das Konzept der in dieser Arbeit zu Grunde gelegten Migration eines XML Dokuments ist eher als von der sp teren Implementierung unabh ngige Vorstel lung zu betrachten Es l sst sich bei der konkreten Umsetzung sowohl durch direkten wie indirekten Datenaustausch realisieren Bei der von uns gew hlten objekt orientier ten Realisierung werden bei der Ausf hrung von Workflow Modellen nicht die XML Daten selbst an eine Softwarekomponente bergeben sondern eine Referenz auf die entsprechenden Objektinstanzen im Speicher ber diese Referenz k nnen die Kompo nenten dann intern die Daten lesen oder ver ndern Daher findet kein Dokumentfluss im eigentlichen Sinne statt sondern ei
395. s enth lt sowie die Ausgabe eines Ergebnisdokumentes nach Beendigung des Vorgangs f hrt uns zu einem Dokumentmigrationsmodell f r die Ausf hrung von Workflow Modellen wie es in der folgenden Grafik dargestellt ist 76 Kapitel 6 XML Prozesse und Prozessdiagramme Zustandsinformationen Zwischenergebnisse i Globale Daten f r Kommunikation zwischen den Aktivit ten i Oo Ausgabedokument mit R ckgabewerten SS a Eingabedokument mit Parameterdaten Abb 6 1 Dokumentmigrationsmodell f r die Workflow Ausf hrung Bei dem Dokumentmigrationsmodell wird von der Eingabe eines Dokuments in einem strukturierten Datenformat ausgegangen Dieses Eingabedokument wird vom Workflow Management System entgegengenommen und verarbeitet Dazu klassifiziert das WFMS den Dokumenttyp und erzeugt f r diesen Typ eine Instanz des zu seiner Verarbeitung n tigen Workflow Modells Basierend auf den im Bereich des Workflow Managements bekannten Objekt migrationsmodellen wollen wir bei diesem Dokumentmigrationsmodell davon ausge hen dass das Eingangsdokument wie eine Umlaufmappe in einer Beh rde den gesamten Workflow durchl uft und von Aktivit t zu Aktivit t weitergereicht wird Bei den Objektmigrationsmodellen vgl Wen00 S 32 werden die Dokumente bei ihrer Modellierung bereits mit allen steuerungsrelevanten Informationen ausgestattet so dass sie selbstst ndig die Weiterleitung zum n chsten Sachbearbeiter ver
396. s zugeh rige Klassendiagramm abgebildet und danach werden die einzelnen Klassen des Diagramms beschrieben Klassendiagramm f r die Datentypen Im Abschnitt 6 3 wurde zur Modellierung von Dokumenttypen in das Konzept der Ports eingef hrt und daran ankn pfend in Abschnitt 7 3 1 eine Menge von Datentypen defi 7 4 Implementierung des erweiterten Metamodells 147 niert mit denen sich das Port Konzept in die Prozessdiagramme einbetten l sst Das dort in Abbildung 7 5 gezeigte Klassendiagramm dient gleichzeitig als Grundlage f r die Implementierung dieser Datentypen Es wird hier aufgegriffen und lediglich leicht angepasst Zu den Anpassungen geh rt die Vererbungsbeziehung zwischen den einzel nen Datentypen und der abstrakten Oberklasse ModelElement von der im Weiteren s mtliche Klassen des Metamodells abgeleitet werden ModelElement XmiElement Placeholder OpenDocType OpenPort namespace String root XmlElement 0 1 types OpenDocType elemName String placeholder Placeholder 0 1 ESTER subs XmiElement binding bindTo Port Port binding bindTo DocType DocType AnyPlaceholder s1 ype ye CopyPlaceholder Constraints self root size rootExceptions XmIElements self placeholder size 1 Port Constraints F self types gt forAll LogicSet lt oclisTypeOf DocType
397. sch ftsproze soll der potentielle zeitlich logische Ablauf von Aktivit ten zur Transformation von Material und oder Infor mation verstanden werden die zur Erf llung eines gesch ftlichen Ziels notwendig sind W hrend einige Autoren die Begriffe Gesch ftsprozess und Wertsch pfungskette synonym benutzen sehen andere Gesch ftsprozesse als Teil der Wertsch pfungskette an Ein Gesch ftsprozess kann auch organisatorische Grenzen wie Abteilungen oder ganze Unternehmen berqueren Er beschreibt alle Aktivit ten mit denen f r interne wie externe Kunden eine Leistung von Wert produziert wird Um dieses Ergebnis zu erzeugen ben tigt man zur Durchf hrung des Gesch ftsprozesses Ressourcen wie Material und Informationen nach Kel99 Da in dieser Arbeit der Fokus auf der rech nerunterst tzten Ausf hrung von Prozessen liegt mit denen elektronische Gesch fts vorf lle im Rahmen des E Business bearbeitet und dabei vorhandene Softwaresysteme eingebunden werden sollen wollen wir die Materialprozesse nicht n her untersuchen und uns detaillierter den Informationsprozessen widmen 2 2 1 Der Begriff Workflow Gesch ftsprozesse werden in einem Unternehmen im Rahmen des sogenannten Business Process Engineering untersucht analysiert und optimiert Ziel ist dabei eine prozessorientierte Ausrichtung der Gesch ftsvorf lle im Unternehmen um eine bessere Kundenorientierung h here Effizienz h here Produktqualit t reduzierte Kosten u
398. scheinbare Erg nzung des UML Meta modells Weil somit Prozessdiagramme durch das UML Metamodell und das spezielle Profil f r Prozessdiagramme auf zwei verschiedenen Ebenen definiert sind siehe Ab bildung 8 3 ist es nicht m glich mit Hilfe von XMI eine DTD zu erzeugen die alle Metamodell Elemente f r Prozessdiagramme inklusive der Stereotypen repr sentiert stereotype stereotype extendedElement service service sendMessage UML Profil f r Prozessdiagramme Prozessdiagramm Abb 8 3 Zusammenhang von UML Profil und Metamodell zur Definition von Prozessdiagrammen Da die M glichkeit einer eigenen Prozessdiagramm DTD nach der XMI Spezifikation nicht gegeben ist bleibt alternativ noch die Betrachtung der vorgegebenen UML DTD Nach dieser DTD lassen sich beliebige Auspr gungen des UML Metamodells in einem XMI Dokument abspeichern Die folgende Abbildung zeigt exemplarisch ein gek rztes Dokument f r ein UML Modell mit einem einfachen Aktivit tendiagramm zum besse 8 2 Vorhandene XML Formate f r Prozessmodelle 169 ren Verst ndig der Elementnamen vgl Abbildung 7 1 zum Metamodell f r Aktivit ten diagramme Zwecks besserer Lesbarkeit wurde insbesondere darauf verzichtet die Elemente entsprechend der DTD vollst ndig mit ihren UML Package Pr fixen zu bezeichnen Durch die Pr fixe wird zwar eine eindeutige Benennung sichergestellt doch werden die XML Marken auch sehr lang und f r den Leser schwerer
399. selbst wieder beliebig viele Unterzust nde und erlaubt damit die Schachtelung von Diagrammen d h das Einbetten von Unterdiagrammen in einen Aktivit tszustand Als SimpleState wird in Aktivit tendiagrammen stets das Element ActionState verwendet oder ObjectFlowState zur Beschreibung des Objektflusses zwi schen den Aktionen Die Spezifikation der Aktivit t die in einem Zustand ausgef hrt werden soll geschieht ber die Assoziation vom Zustand zum Element Action Diese Aktion wird ausgef hrt sobald der zugeh rige Zustand betreten wird In Aktivit tendiagrammen wird als Aktion meistens das Element CallAction verwendet durch das die Methode eines Objekts aufgerufen wird Alternativ kann auch UninterpretedAction verwendet werden wenn die Aktivit t durch einen informalen Text beschrieben werden soll Dies erlaubt zwar das Modellieren von Abl ufen auf hohem Niveau verhindert jedoch die M glichkeit einer maschinellen Interpretation des Diagramms 7 1 Das UML Metamodell 123 Neben gew hnlichen Zust nden gibt es in Aktivit tendiagrammen auch soge nannte PseudoStates Dazu z hlen Verzweigungen Fork und Joinzust nde und der Startzustand also Zust nde in denen keine explizite Aktion ausgef hrt wird Jeder Zustandsknoten StateVertex eines Diagramms besitzt beliebig viele Eingangs bzw Ausgangstransitionen zu anderen Zust nden in Form des Elements Transition Dabei k nnen bestimmte Transitionen einen Guard besitzen um eine Beding
400. sen in besonderem Ma e auf den Einsatz von XML Technologien setzt Zum anderen wird die von M Brian Blake unter dem Namen WARP ver ffent lichte agentenbasierte Architektur zur Konfiguration verteilter Komponenten vorge stellt In diesem Ansatz wird zwar nicht mit XML gearbeitet er zeigt aber gut wie man verteilte Softwarekomponenten durch Workflow Systeme integrieren kann Schlie lich folgt eine Erl uterung der grundlegenden Konzepte des Produkts sunShine der Firma S amp N AG Dabei handelt es sich um eine Integrationsplattform f r B2C und B2B Anwendungen wie beispielsweise Online Banking Systeme Mit Hilfe von sunShine als Rahmenwerk l sst sich neben dem Layout auch die Businesslogik solcher Webauftritte realisieren Die Untersuchung von BizTalk Server 2000 und WARP erfolgte anhand von vorliegender Literatur und Dokumentation bei sunShine war es dank der Kooperation mit der S amp N AG m glich Erfahrungen am installierten System selbst zu sammeln 4 1 Microsoft BizTalk Server 2000 Die von Microsoft initiierte BizTalk Initiative besch ftigt sich mit dem Problem dass die Integration von Softwaresystemen verschiedener Unternehmen oder Unterneh mensteile oft durch inkompatible Datenformate gebremst wird F r die zum Austausch von Nachrichten erforderlichen abgestimmten Nachrichtenformate steht als Basistech nologie zwar XML zur Verf gung es mangelt aber h ufig an der Verst ndigung auf ge meinsame Schemata und Definitionen f r
401. sersreererserereses 41 4 2 3 Workflow Modellierung mit WARP u censsensnsensnnennnnnn 42 4 2 4 Workflow Ausf hrung mit WARP ucceensssenssnsssneesnnnnennn ann 42 4 3 E Business Plattform sunshine aus 43 4 3 1 Systemarchitektur von sunShine 22uu022essnersnnesnnennnnennnersnnennennnen en 44 4 3 2 Workflow Ausf hrung mit sunShine uusssssssssssnnennnenennnnnn 45 4 3 3 Komponentenintegration mit sunShine ursersenesnsersnnersnnrsnnesnnennnen en 46 4 4 BEWETTUNG 1 A S E E N S 48 2 5 Inhaltsverzeichnis Evaluierung vorhandener Workflow Modellierungssprachen ss ecsssresee 51 5 1 Peti Netze nn et seen a a a Ea AaS 51 5 1 1 Klassische Petri Nee ain E SaS 51 5 1 2 Hieh Level Petri Netzeu uunsesniinens sanken 52 5 1 3 Gesch ftsprozessmodellierung mit Petri Netzen unns seen 53 5 1 4 Eignung f r Prozessdiagramme eeeseseeeeeesesesesresseserrsressesererressessresres 55 5 1 5 Hatentlussin Petti Netzen sirenita R Asaa Rainis 58 5 2 Ereignisgesteuerte Prozessketten neuen 59 5 2 1 Basiskonstrukte des EPK Modells seseeeeeseeseeeeeseserssressessresrersrrsreses 59 5 22 Formale Beschreibung der Syhlax 2 ae een 61 3 2 3 Gesch ftsprozessmodellierung mit EPK u22s0 sn 62 5 2 4 Eignung f r Prozessdiagramme 2u0022000sssnnensnnneennnnennnnnennnnennnn 63 5 3 UMIL Aktivit tendiagramme 2u022220020200snsnnnensn
402. sich das Angebot des Portals auf den wirtschaftlichen Bereich bezieht spricht man auch von Virtuellen Marktpl tzen sata U Onn uelet mi zur Sad rechi verkagh r Elder E Wi 20 Hare bch sal berera er wihi Eii CINT Ergeb sn hin 1 1 Ba MrabichPucatn PP A Fakin L Aap msan am 1Jabra nAn Au SE A m Eh a Elisa DE So Zugang AAEE sin CEAI AN Hickhlick wakis DR 00 Aimat NET DENA E Daai KU BT Tarkka 05 07 nama ad Fester 10 Lier baian H i I Eainbaner Enihjahr 1 Eau das Haiii BEN Betrag CH 15000 lionan ER 3 T Beiniersesse Zuian amp Ben Elli D7 BLSUR Fe Ar Biti TEIE waha O SION ker ain ESE E ad Pre iriki Karim Partie a BEI F ander Ba en Era BA gyt Mpiri Imskratt 2 LE ETE n 1 LG Dia iraa ii HEA fr Eeay CHEA 7 stm Nez EDER Kimiken TENES iE D n gramm i ran ala Diri inii ETE mike Brai Fahra ara CER meniad Niii Breh rechte II am i EE Mi ITEN Kiam La Eshil I TW t Eoss sl 3 M Eeber EE maas xj Boo T 17 77 Abb 4 3 Ansicht eines Beispielportals Um Informationen die aus unterschiedlichen Quellen in einem Portal zusammengef hrt sind dem Benutzer individuell anzubieten sind drei Aspekte zu ber cksichtigen Zun chst sollte ein E Business Portal Multi Channel f hig sein d h es sollten Daten aus Quellen unterschiedlichen Typs eingebunden werden k nnen sunShine erm glicht beispielsweise Dateien Datenbanken HTTP oder RMI Server usw Um die Daten dem Benutzer zu pr senti
403. sie weiterleitet Eine Besonderheit im Zusammenhang mit parallelen Prozessen stellen Synchro nisationszust nde dar Zun chst findet an einer solchen Prozessstelle eine zeitliche Synchronisation statt d h ein Teilprozess A wartet auf einen anderen Teilprozess B Der Sinn einer Synchronisation ist es jedoch meistens dass A eine Information ben tigt die B erzeugt Daher kann A erst dann weiterarbeiten wenn B an der Synchronisa tionsstelle angekommen ist Aus diesem Grund ist die Semantik von XML Prozessen an solchen Punkten analog zu den zuvor beschriebenen Join Zust nden definiert Prozess B legt am Synchronisationszustand eine Kopie seines XML Dokuments ab Wenn A den Zustand erreicht so wird ein neues XML Wurzelelement erzeugt welches sowohl das aktuelle Dokument von A selbst als auch das von B abgelegte als Unterelemente erh lt Auf diese Weise stehen A nun alle ben tigten Daten zur Verf gung Gegebenenfalls muss durch eine anschlie ende Transformation das zusammengesetzte Dokument in eine Form berf hrt werden die der Rest von Strang A verarbeiten kann 6 2 6 Einschr nkungen gegen ber Aktivit tendiagrammen Neben den Erweiterungen von Aktivit tendiagrammen die in den vorhergehenden Abschnitten beschrieben wurden sind in Prozessdiagrammen folgende Sprach konstrukte nicht vorgesehen 6 2 Modellierung mit Prozessdiagrammen 91 Ereignisse Laut UML Spezifikation ist ein Aktivit tendiagramm eine spezielle Zustandsmaschine
404. sportiert die Ergebnisse des einen Service zur Weiterverarbeitung an den n chsten Service Dabei wird es sukzessive transformiert und mit Zwischenergebnissen angereichert Das resultierende Dokument des letzten Verarbeitungsschrittes ist dann die Ausgabe des Workflows Dieses Vorge hen vereinfacht die Handhabung der sehr umfangreichen Datenfl sse indem alle f r die 12 1 Zusammenfassung 247 nachfolgenden Verarbeitungsschritte relevanten Zwischenergebnisse der Services durch das Migrationsdokument aufgenommen und mit dem fortschreitenden Kontrollfluss weitergeleitet werden siehe oben Punkt 3 Au erdem bietet XML eine hervorragende Grundlage zur Realisierung des geforderten Multi Channel Ansatzes siehe oben Punkt 4 und Abschnitt 3 2 Anforderung 9 weil sich mit Stylesheets die Ausgabedoku mente der Prozesse leicht umstrukturieren und in die gew nschten Zielformate trans formieren lassen Um das Ziel einer m glichst gut verst ndlichen intuitiven Modellierung der Workflows zu erreichen bedarf es einer visuellen Modellierungssprache siehe 3 2 An forderung 1 Wegen der hohen Bedeutung die der Workflow Modellierung als hilfrei ches Abstraktionsmittel zum Entwurf und der Wartung von Workflows zukommt siehe 2 3 enth lt Abschnitt 3 3 eigene Anforderungen an eine solche grafische Workflow Modellierungssprache Die daraufhin in Kapitel 5 untersuchten bekannten Modellierungssprachen wie Petri Netze Ereignisgesteuerte Prozessketten und UML
405. ssSection die die notwendige Funktio nalit t besitzt um einen Prozessabschnitt auszuf hren Davon abgeleitet ist die Klasse ProcessInterpreter die aus der Systemumgebung heraus instanziiert werden kann um ein gesamtes Prozessmodell auszuf hren Abbildung 10 6 zeigt die Zusammenh nge 220 Kapitel 10 Ausf hrung von XML Prozessen java lang Thread AsubSections ProcessSection i run Void 1 operatesOn gt 1 Document AbstractState 1 current gt 1 Processinterpreter ProcessiInterpreter document Document executeProcess Document Abb 10 6 Ausf hrende Klassen Die Klasse ProcessSection besitzt zun chst Assoziationen zu dem Migrationsdokument sowie dem aktuellen Zustand In der Methode run die aus der Oberklasse Thread berschrieben wurde befindet sich der aus Abschnitt 10 1 bekannte Algorithmus der einen Prozessabschnitt ausf hrt Wenn dabei ein Forkzustand erreicht wird erzeugt der Interpreter f r jeden parallelen Strang eine neue Instanz der Klasse ProcessSection die als Kind an die bergeordnete ProcessSection angeh ngt wird subSections Diese wartet nun solange bis alle ihre Unterabschnitte terminiert sind Anschlie end sammelt sie die Ergebnisdokumente der Unterabschnitte ein und erzeugt daraus ein neues Migrationdokument vgl Abschnitt 6 2 5 Danach setzt sie die Ausf hrung ihres Prozessabschnitts fort Au
406. ssdiagramm zwei Services durch eine Transition miteinan der verkn pft werden sollen deren Ein und Ausgabeschnittstellen entsprechend ihrer Ports nicht zueinander kompatibel sind kann die gew nschte Transition mit einem Stylesheet versehen werden Die Anwendung des Stylesheets auf das Migrationsdoku ment transformiert dieses derart dass es doch noch konform zur Zielschnittstelle wird Somit wird einer Transition im Prozessdiagramm neben dem passiven Zustands ber gang zus tzlich ein aktives Verhalten zugeordnet Vorteil dieser Methode ist eine viel gr ere Flexibilit t bei der Verkettung von Services in den Workflows Durch die trans formierenden Transitionen k nnen auch Services hintereinander ausgef hrt werden deren Schnittstellen eigentlich nicht kompatibel zueinander sind Um das Stylesheet bei hnlichen Konstellationen einfach wiederverwenden zu k nnen wurde ein Konzept f r typisierte Transitionen eingef hrt nach dem jeder Tran sition statt des Stylesheets ein wiederverwendbarer Transitionstyp zugeordnet wird der seinerseits auf ein entsprechendes Stylesheet verweist Die typisierten Transitionen und Transitionstypen wurden in das formale Konzept f r die Ports aufgenommen so dass zur Konsistenzpr fung nun eine einheitliche Theorie zu Grunde liegt die auch die Kompatibilit t bei Zustands berg ngen und eventuell vorgenommenen Transformatio nen bei Transitionen ber cksichtigt Durch die Typisierung der Transitionen wird dan
407. sse als Transaktionen ausf hren lassen Diese F higkeit ist bereits in der Modellierungssprache f r Prozessdiagramme enthalten lediglich der von uns implementierte Prozessinterpreter bietet daf r noch keine Unterst tzung Pufferung von Prozessmodellen Die Verarbeitung gro er Mengen von XML Daten beansprucht zur heutigen Zeit noch vergleichsweise viel Rechenzeit Vor allem f r Pro zessbeschreibungen die in Form von PML Dokumenten vorliegen w re es daher sinn voll Pufferungsverfahren einzusetzen damit vom PML Importer geladene Prozesse nicht nur einmal sondern f r mehrere Ausf hrungen oder sogar vom Prozesseditor verwendet werden k nnen vgl Abschnitt 10 2 1 Dabei sind unter anderem berle gungen anzustellen wie lange Prozessmodelle im Puffer gehalten werden sollen und wie mit Aktualisierungen im laufenden Betrieb umgegangen wird d h falls ein Prozess im Editor ver ndert wird w hrend er gerade von einer Instanz des Interpreters ausge f hrt wird Dynamisches Suchen von Konnektorinstanzen Aus Sicht des Prozesseditors handelt es sich bei Konnektoren und Services ausschlie lich um Interfaces und ihre Methoden d h es sind lediglich Schnittstellen und nicht konkrete Implementierungen bekannt Die Vorteile dieses Ansatzes wurden in 6 1 3 dargelegt Allerdings hat dieses Vorgehen zur Folge dass auch in der PML Beschreibung eines Prozesses keine Klasse verankert ist 12 2 Ausblick 251 die die ben tigte Funktionalit t anb
408. st als einzige Aktion die Integration einer bestimmten Softwarekomponente als Service erlaubt e Die Schnittstelle eines Service wird durch die Angabe von Ports definiert e F r den Aufruf eines Service m ssen Parameter angegeben werden k nnen e Jede Transition ist als Objektfluss des XML Dokuments zwischen den Akti vit ten zu interpretieren Transitionen sind typisiert wobei Instanzen eines Typs nur bestimmte Ports miteinander verbinden k nnen e In Guards m ssen auch XPath Ausdr cke erlaubt sein um auf das XML Dokument zugreifen zu k nnen Die Ausdr cke m ssen zu den jeweiligen Dokumenttypen kompatibel sein e Es muss ein Sprachkonstrukt eingef hrt werden um Teil Prozesse als Transaktionen ausf hren zu K nnen e Damit eine Ausf hrung des Prozessmodells durch den Prozessinterpreter m glich ist m ssen zus tzliche Wohlgeformtheitsregeln eingehalten werden Das Profil f r die Modellierung von Prozessdiagrammen besteht im Wesentlichen aus einigen Datentypen zur Realisierung des Port Konzeptes und mehreren Stereotypen die die oben genannten Erweiterungen umsetzen sowie den zugeh rigen Tag Definitionen und Constraints Die Datentypen zur Repr sentation der Ports sind aus der formalen mengentheoretischen Betrachtung aus Abschnitt 6 3 3 abgeleitet Sie werden zuerst vor gestellt Danach schlie t sich die detaillierte Definition der benutzten Stereotypen durch Tabellen an wie sie in OmgOl 3 35 vorgeschlagen werden
409. stand verbunden ist ausgef hrt wird wird berpr ft ob das Migrationsdokument zum Eingangsport des Zustands konform ist Nach Ausf hrung der Aktion wird das Dokument gegen den Ausgangsport validiert Falls bei der Pr fung der Ports Fehler auftreten befindet sich der Prozess in einem inkonsistenten Zustand und muss abgebrochen werden Die meisten in Prozessdiagrammen erlaubten Zustandsarten haben dieselbe Semantik wie in UML Aktivit tendiagrammen siehe Omg01 2 175ff Ausnahmen bilden Service Zust nde siehe n chsten Absatz sowie Join und Synchjoin Zust nde Letztere haben nicht nur die Aufgabe einer zeitlichen Synchronisation sondern sie m ssen auch die Migrationsdokumente aller ihrer eingehenden Transitionen sammeln und daraus gem der Vorschrift aus Abschnitt 6 2 5 ein einzelnes Dokument erzeugen Dieses wird dann an den Rest des Prozesses weitergeleitet 214 Kapitel 10 Ausf hrung von XML Prozessen Stereotyp serviceState Die wichtigste Zustandsart in Prozessdiagrammen sind Service Zust nde Jedem Service Zustand ist ber das Metamodell f r Prozessdiagramme eine Operation mit dem Stereotyp service zugeordnet Wird bei der Ausf hrung des Prozesses ein solcher Zustand erreicht wird das Migrationsdokument an die Softwarekomponente bergeben zu der der Service geh rt Zuvor erfolgt eine Konformit tspr fung anhand des Ein gangsports Es m ssen dann die Argumentwerte berechnet werden sofern der Service Paramet
410. ste zur Verf gung stehen generiert der Global Workflow Manager Agent GWMA f r jeden Service eine grafische Repr sentation Ein Prozessdesigner kann nun mit Hilfe des Design Werkzeugs Workflow Modelle daraus entwerfen 42 Kapitel 4 Evaluierung vorhandener Workflow Systeme 4 2 3 Workflow Modellierung mit WARP Zur Spezifikation eines mit WARP auszuf hrenden Prozesses m ssen verschiedene objektorientierte Modelle erstellt werden Dazu steht in WARP ein Modellierungswerk zeug zur Verf gung das jedoch keine Unterst tzung bei der Analyse und Simulation von Prozessen bietet WARP unterscheidet bei den Modellen zwischen struktureller funktionaler und nicht funktionaler Sicht Im strukturellen Modell das in Form von UML Klassendiagrammen aufgestellt wird werden zun chst die vorhandenen Services erfasst Sie k nnen in einem weiteren Schritt zu Rollen aggregiert werden um sie dann dem zu modellierenden Workflow zuzuordnen Die Aggregation zu Rollen erm glicht es einem Role Manager Agenten auch mehrere Dienste anzubieten In der funktionalen Modellsicht werden die eigentli chen Abl ufe des Workflows beschrieben Dazu werden in zwei verschiedenen UML Aktivit tendiagrammen der Daten und Kontrollfluss des Prozesses getrennt voneinan der modelliert Zu den nicht funktionalen Eigenschaften des Workflows z hlen Beson derheiten wie Fehler und Ausnahmebehandlung Nebenl ufigkeit usw Leider wird in Bla00 nicht n her auf die Modellierung
411. t Tag zugreifen Die Bezeichnung der Schl sselworte eines Modellelements muss daher eindeutig sein In der aktuellen Version 1 4 der UML wird empfohlen die Definition neuer Attribute nur f r Stereotypen zu benutzen und diesen zuzuweisen Aus Kompatibilit tsgr nden zur Vorg ngerversion 1 3 ist es aber auch weiterhin nicht ausgeschlossen die Schl ssel Wert Paare beliebigen Modellelementen zuzuordnen Im Gegensatz zu UML 1 3 ist es jetzt au erdem m glich die zu einem Schl s selwort korrespondierenden Werte genau zu typisieren W hrend fr her nur der einheit liche generische Typ String benutzt werden konnte siehe Omg00 2 73f stehen nun alle Standard Datentypen und sogar Referenzen auf andere Klassen des Meta modells zur Verf gung Der Typ der Werte und die Kardinalit t werden in der Tag Definition festgelegt Diese Tag Definition besitzt dann in der Regel eine Assoziation zu einem bestimmten Stereotyp Tag Definitions und Tagged Values sind somit ein ad quates Mittel um im Zusammenhang mit Stereotypen zus tzliche Eigenschaften und Attribute f r Modell elemente zu definieren die zum Beispiel Informationen f r die Codegenerierung oder f r die spezielle neue Semantik tragen 4 2 3 Constraints Mit Hilfe von Constraints lassen sich durch Regeln formuliert in einer ad quaten Sprache semantische und syntaktische Erg nzungen f r Modellelemente spezifizieren Omg01 2 6 2 1 Diese Regeln definieren Nebenbedin
412. t 7 3 2 das ein UML Interface als Konnektor f r eine Softwarekomponente auszeich net Diese Klasse bernimmt die Rolle der bisherigen Meta klasse Interface Wie Abbildung 7 6 zeigt wird Interface von Classifier abgeleitet und erbt dadurch eine Assoziation zur Klasse Feature die dann durch Vererbung zum Stereotyp service f hrt Diese Vererbungsstufen konnten eingespart werden und stattdessen direkt eine Assoziation zwischen ComponentConnector und der neuen Klasse Service gezogen werden Da zun chst nicht vorgesehen ist Vererbungskonzepte auf Instanzen von ComponentConnector anzuwenden Konnte auch die Ableitung von der Metaklasse GeneralizableElement entfallen Die Klasse Service realisiert das Stereotyp service aus Ab schnitt 7 3 2 mit dem Methoden eines ComponentConnectors ausgezeichnet werden wenn sie innerhalb von Prozessaktivit ten aufrufbar sein sollen Diese Klasse bernimmt die Rolle der Metaklasse Operation Die Vererbungsstufen Feature und BehavioralFeature siehe Abbildung 7 6 konnten eingespart werden Dadurch ergibt sich auch die direkte Assoziation zur Metaklasse Parameter Die Bedeutung der Attribute ergibt sich aus der Stereotyp Definition in Abschnitt 7 3 2 Die Klasse Parameter entspricht der gleichnamigen UML Metaklasse Mit ihr werden die f r einen Service Aufruf n tigen Parameter spezifiziert Die Klasse hat keine Attribute weil die Angabe eines eindeutigen Namens bereits durch die Ableitung von
413. t ist Im rechten Bereich des Fensters sieht man daher die zugeh rige Eingabemaske in der man insbesondere den gew nschten Namen des Konnektors eingeben kann E sunFlow Process Editor Ioj x File Xt Testprojekt u Package de sundn prod sunshine cofon can gt Transition type Cres Close Package gt Transition type Join Delete Package E Component connect EJ Component connect o Process Transfer New Process New Connector New Transitiontype Abb 9 6 Erzeugen eines neuen Konnektors Durch Auswahl des Konnektors im Baum und Auswahl der Aktion New Service im dann erscheinenden Popup Men lassen sich Services zum Konnektor hinzuf gen Jeder Service wird dabei in der unter 9 2 3 beschriebenen Eingabemaske definiert Erzeugen neuer Transitionstypen Analog zum Anlegen eines Konnektors w hlt man mit der rechten Maustaste das Package im Projektbaum aus das den neuen Transitionstyp enthalten soll es erscheint ein Popup Men Nach Auswahl der Aktion New Transitiontype legt der Editor einen neuen Typ an der sofort im Baum sichtbar wird und selektiert ist Im rechten Bereich des Fensters sieht man dann die in Abbildung 9 7 gezeigte Eingabemaske Dort l sst sich oben links der gew nschte Name des Typs angeben Darunter wird das Package angezeigt in dem sich der Transitionstyp befindet dies kann bei Bedarf durch Bet tigen der Schaltfl che Move ge ndert werden
414. t name sourcePort type PortType gt lt xsd element name targetPort type OpenPortType gt lt xsd element name transformation type TransformationType minOccurs 0 gt lt xsd sequence gt lt xsd attribute name name type xsd string use required gt lt xsd complexType gt Abb 8 13 PML Schema Fragment f r Transitionstypen 8 3 Process Markup Language PML 179 Abbildung 8 14 zeigt beispielhaft die Beschreibung eines Transitionstyps lt package name de sundn sunflowexamples gt lt transitionTypes gt lt transitionType name Typel gt lt sourcePort gt lt sourcePort gt lt targetPort gt lt targetPort gt lt transformation href gt lt transitionType gt lt transitionType name Type2 gt lt sourcePort gt lt sourcePort gt lt targetPort gt lt targetPort gt lt transformation xmilns xsl http www w3 org 1999 XSL Transform gt lt xsl stylesheet gt lt xsl stylesheet gt lt transformation gt lt transitionType gt lt transitionTypes gt lt package gt Abb 8 14 Beispiel f r die PML Beschreibung eines Transitionstyps 8 3 3 Beschreibung von Prozessen Stereotyp processDiagram Wenn mit einem PML Dokument ein Workflow beschrieben werden soll hat es das Wurzelelement lt process gt Entsprechend dem zugeh rigen Stereotyp processDiagram gibt das Attribut name den Namen einschlie lich des Package an zu dem das Dia gramm geh rt
415. t werden k nnen 6 1 3 Modell und Ausf hrungsebene Ein Workflow Modell ist eine abstrakte Beschreibung f r eine Menge von gleichartigen Workflows Die einzelnen Workflow Instanzen unterscheiden sich durch verschiedene Werte bei den zu Grunde liegenden Parametern und Daten So kann etwa ein Workflow zur berweisung eines Geldbetrages f r verschiedene Konten oder verschiedene Betr ge aufgerufen werden F r diese verschiedenen Workflows wird aber immer das gleiche Modell instanziiert Neben der Abstraktion von den konkreten Dateninhalten wird in einem Workflow Modell auch von konkreten Aufgabentr gern abstrahiert Im Bereich der Gesch ftsprozessmodellierung etwa wird in einem Gesch ftsprozessmodell f r die Erledigung eines Kreditantrages nicht der konkrete Kreditexperte Herr A eingesetzt sondern die Rolle Kreditexperte die von Herrn A erf llt wird Es k nnte aber auch andere Personen geben die diese Rolle erf llen Vorteil dieser Abstraktion ist die gr Bere Unabh ngigkeit von Ver nderungen im Bereich der konkreten Personen So bliebe das Prozessmodell unber hrt wenn Herr A das Unternehmen verlie e Jemand anderes der die gleiche Rolle erf llt K nnte die Erledigung der Aufgabe bernehmen Ein hn liches Abstraktionskonzept ist das der Stelle zum Beispiel die Stelle des Abteilungs leiters f r die eine konkrete Stellenbesetzung in Form einer realen Person zu jedem Zeitpunkt gegeben sein sollte Beide Konzepte werden in B
416. t wird Jede Aktivit t kann zu ihrer Erledigung n tige Infor mationen aus dem Dokument entnehmen sowie die Ergebnisse der Aktivit t als Zwischenergebnis und als Eingabe f r nachfolgende Aktivit ten in dem Dokument ablegen Die aus dem Dokument entnommenen oder vom WFMS aus dem Workflow Modell abgeleiteten Informationen und Parameter m ssen ausreichen um die Ausf h rung der einzelnen Aktivit t zu spezifizieren Neben diesen Startinformationen kann jede Aktivit t weitere Eingabedaten aus externen Datenquellen beziehen Solche Daten auf die das WFMS selbst keinen Zugriff hat werden im Workflow Referenzmodell Workflow Applikationsdaten genannt siehe Wmc95 S 14 Handelt es sich dabei zum Beispiel um das Ergebnis einer Datenbankanfrage ben tigt die Instanz die die Aktivit t ausf hren soll Schl sselattribute um die richtigen Datens tze aus den Tabellen der Datenbank zu selektieren Solche Schl sselinformationen befinden sich in der Regel in dem Eingabedokument des Workflows Ein typisches Beispiel ist etwa die Kunden nummer eines Klienten der f r seine Konten eine bestimmte Funktion ausf hren lassen m chte Genauso wie das Einlesen aus externen Datenquellen m glich ist k nnen in Aktivit ten auch Daten in externen Datenspeichern abgelegt werden Auf diese Weise k nnen Aktivit ten unabh ngig vom umlaufenden Dokument beliebige Ausgabedaten produzieren Alle f r den Fortgang des Workflows und f r die nachfolgenden Aktivit
417. t wird die Interoperabilit t der vor handenen meist heterogenen Softwaresysteme untereinander aber vor allem mit dem WFMS zu einer zentralen Frage bei der Prozessmodellierung und ausf hrung Das WFMS muss auf die heterogenen autonomen und oft verteilten Komponenten zugreifen sowie den Kontroll und Datenfluss zwischen diesen Einheiten steuern k nnen Im Einzelnen sind drei Formen der Einbindung vorstellbar vgl B h95 S 15 die auch 16 Kapitel 2 Grundlagen des Workflow Managements beliebig miteinander kombiniert werden k nnen Einbindung zur Ausf hrung einer Funktion oder Aktivit t Hierbei geht es um den automatischen Aufruf einer externen Komponente zur Durchf hrung eines Bearbeitungsschritts Denkbar sind hier die Benutzung elementarer Ein heiten wie zum Beispiel JavaBeans oder auch der Aufruf gr erer Module zum Beispiel aus einer betriebswirtschaftlichen Standardsoftware Neben einer M g lichkeit die jeweilige Komponente aufzurufen z B ber CORBA RMI RFC Internet URL m ssen die beiden folgenden Punkte der bergabe von Daten und der R ckgabe von Ergebnissen gel st werden bergabe von Parameterwerten und Ergebnissen an existierende Applika tionen und Datenbanken Beim Aufruf von Funktionen bestehender Software m ssen in der Regel Parameterwerte bergeben werden Au erdem ist es oft n tig Zwischenergebnisse Protokollinformationen oder sonstige Datens tze an externe Anwendungen oder Datenbanken zweck
418. talten bzw bestimmte Teilausdr cke wiederverwenden zu k nnen lassen sich mit Hilfe des Schl sselworts let Variablen und Funktionen definieren Diese erhalten durch die Definition einen eindeutigen Namen unter dem sie in Ausdr cken verwendet wer den k nnen Um beispielsweise die Anzahl der Ausgangstransitionen eines Zustands als Variable zu definieren dient folgende Anweisung Context State inv let outCount Integer self outgoing gt size OCL Typen Neben einigen Basistypen sind auch alle Klassifizierer aus einem UML Modell wie Klassen oder Interfaces Typen die in OCL Ausdr cken benutzt werden k nnen F r den Umgang mit Typen bietet OCL einige sehr hilfreiche Funktionen an die auf jeder Objektinstanz aufgerufen werden k nnen vgl Omg01 6 8 1 2 object oc1IsKindOf type Oc1Type Wahr falls einer der Typen oder Supertypen Boolean transitiv von object gleich type ist object oc1IsTypeOf type Oc1Type Wahr falls type einer der Typen von object ist Boolean object oclAsType type Oc1Type Liefert object aber als Auspr gung des Typs type type Das Ergebnis ist nicht definiert falls object nicht von diesem Typ oder einem seiner Sub typen ist Tab 7 2 OCL Hilfsfunktionen f r das Arbeiten mit Typen 126 Kapitel 7 Metamodell f r Prozessdiagramme Die Object Constraint Language besitzt eine Reihe weiterer M glichkeiten wie beispielsweise das Formulieren von Vor und Nachbeding
419. tates enqueue successor 5 6 7 8 9 10 successor listOfSuccessor nextElement 1 2 3 4 5 end while 6 end while Abb 7 14 Algorithmus f r die automatische Portberechnung In der Schlange queueOfStates werden die noch zu bearbeitenden Zust nde des Pro zessdiagramms gespeichert Solange diese Schlange nicht leer ist werden ihre Elemente sukzessive abgearbeitet siehe Zeilen 3 und 4 Dazu wird f r den jeweils der Schlange entnommenen Zustand der Ein und der Ausgangsport neu berechnet Zeilen 5 und 6 Der besuchte Knoten wird dann durch Einf gen in die Menge setOfVisited markiert siehe Zeile 7 Anschlie end wird die Breitensuche fortgesetzt indem alle Nachfolge zust nde betrachtet werden Zeilen 9 und 10 Wenn bei dem gerade besuchten Zustand der Ausgangsport durch calculateOutputPort ge ndert wurde werden alle Nach folgezust nde in die Schlange zur weiteren Bearbeitung aufgenommen Zeile 11 ansonsten nur diejenigen die noch nicht besucht worden sind Zeile 12 Zust nde die sich jedoch schon in der Schlange befinden brauchen nicht erneut aufgenommen zu werden Zeile 13 Durch die Bedingung in Zeile 11 ist es m glich dass schon besuchte Zust nde erneut in die Warteschlange aufgenommen werden Aus diesem Grund muss an dieser Stelle eine Bemerkung zur Terminierung des Algorithmus gemacht werden denn Zyklen im Prozessdiagramm k nnten ja eventuell zu Endlosschleifen f hren und eine Terminierung
420. tehen die bekannten Verkn pfungsoperatoren durch folgende Schl sselw rter zur Verf gung or logisches ODER and logisches UND implies Folgerung Implikation Zugriff auf Attribute Die Werte von Attributen eines Modellelements k nnen durch einen Punkt gefolgt vom Namen des Attributs abgefragt werden Wenn sich beispiels weise eine OCL Regel auf den Startzustand eines Aktivit tendiagramms beziehen soll l sst sich dies durch folgenden Ausdruck realisieren context PseudoState inv self kind initial implies Dabei ist initial eine vordefinierte Konstante f r das Attribut kind des Elements PseudoState die den Startzustand identifiziert Navigation ber Assoziationen Sehr h ufig muss man innerhalb eines OCL Ausdrucks ber Assoziationen von Elementen navigieren Dies geschieht analog zum Zugriff auf Attribute durch einen Punkt gefolgt von der Rollenbezeichnung der gew nschten Assoziation Bei Assoziationen die nicht die Kardinalit t 1 besitzen ist der R ckgabewert vom vordefinierten OCL Datentyp Collection F r diesen existieren eine Reihe von Operationen wie size oder select die im n chsten Absatz erl utert werden Sie sind durch einen Pfeil Operator aufrufbar Mit ihrer Hilfe wird beispiels weise in der UML Spezifikation festgelegt dass der Startzustand eines Aktivit ten diagramms keine Eingangs und nur genau eine Ausgangstransition besitzt context PseudoState inv self kind initial implies
421. telnputPort boolean execute Void TE UMLStateAdapter ForkState ServiceState getFollowing AbstractState execute Void execute Void validatelnputPort boolean Abb 10 4 Verwendung des Entwurfsmusters Bridge Abbildung 10 5 zeigt zur Verdeutlichung das Zusammenwirken der beiden Muster am Beispiel eines Service Zustandes und die sich daraus ergebende Schichtenstruktur Sicht des Interpreters Kopplungsschicht Datenstruktur ProcessDiagram Adapter gt pii i 1 1 1 ServiceState 5 UMLStateAdapter ServiceStateVertex Abb 10 5 Verwendung der Datenklassen durch den Prozessinterpreter 10 2 2 Ausf hrende Klassen Mit Hilfe der im vorherigen Abschnitt beschriebenen Klasse AbstractState kann der Prozessinterpreter den Prozess schrittweise abarbeiten Wie bereits im Abschnitt 10 1 erl utert ist der zentrale Ausf hrungsalgorithmus in der Lage einen Prozessabschnitt auszuf hren Ein solcher Abschnitt kann dabei entweder der gesamte Prozess ein refe renzierter oder eingebetteter Subprozess oder ein paralleler Teilstrang im Zusammen hang mit einem Fork Zustand sein Bei parallelen Teilstr ngen m ssen mehrere Threads gestartet werden von denen jeder einen Teilprozess abarbeitet Dies l sst sich sehr leicht realisieren indem eine Unterklasse der Java Klasse Thread gebildet wird Die zentrale Klasse des Interpreters ist daher Proce
422. ter Zeit ein Trend zur Speicherung von Prozessmodellen in XML Formaten zu verzeichnen ist einige der bestehenden Ans tze sollen im nachfolgenden Abschnitt n her vorgestellt werden 2 Graphorientierte Beschreibung des Kontrollflusses Prozessdiagramme als spe zielle UML Aktivit tendiagramme beruhen auf den Prinzipien einer Zustandsmaschine bzw eines endlichen Automaten vgl B0099 S 294 Somit handelt es sich bei Pro zessdiagrammen im Wesentlichen um gerichtete Graphen mit den Zust nden und Akti vit ten als Knoten und den Transitionen als Kanten Damit sind flexible Kontrollfl sse mit beinahe beliebigen Transitionen zwischen den einzelnen Zust nden m glich Es k nnen Strukturen entstehen die durch wohlgeformte Schachtelung von Bl cken wie sie aus strukturierten Programmiersprachen bekannt sind nicht mehr abgebildet werden k nnen Verzweigungen etwa k nnen zu einer beliebigen anderen Aktivit t f hren was unter Umst nden ohne eine Graphstruktur nur schwer auszudr cken w re Darum muss die Prozessbeschreibungssprache erm glichen den Kontrollfluss als Graphstruktur ab zuspeichern 3 Aufruf vorhandener Services bzw Komponenten als Aktionen Genau wie in den Aktivit ten des Prozessdiagramms muss es auch in der XML Beschreibung eine M g lichkeit geben auf Softwarekomponenten des statischen Modells zu verweisen so dass bei der Ausf hrung eine Bindung vorgenommen und eine konkrete Instanz aufgerufen werden kann 4 be
423. terhalb der Wurzel des Migrationsdokuments abgespeichert ist Dann stellt sich der obige Prozess mit seiner Verzweigung wie folgt als Prozessdiagramm dar Daten Anzeigen Fehlerbehandlung return 0 Kundeninfo else Abb 11 7 Prozessdiagramm mit Verzweigung Die Standardaktion aus dem Regelwerk wird im Prozessdiagramm durch den vordefi nierten Guard mit der Bezeichnung else siehe Omg01 2 150f modelliert Insge 242 Kapitel 11 Evaluierung anhand einer Fallstudie samt zeigt sich dass Verzweigungen in der bisherigen L sung nur ber den relativ umst ndlichen Weg der R ckgabewerte spezifiziert werden k nnen und somit auch bei diesem Kontrollflusskonstrukt Prozessdiagramme eine elegantere und m chtigere Option anbieten Parallelit t Zur Definition von Nebenl ufigkeit wird im Regelwerk der E Business L sung der Bausparkasse das Konstrukt der asynchronen Aktionen eingef hrt Dahinter verbergen sich Aktionen die gleichzeitig zu der aufgrund der Entscheidungswerte ausgew hlten synchronen Aktion ausgef hrt werden sollen Die Unterscheidung der beiden Aktions arten erfolgt durch die XML Elemente lt SyncAktion gt und lt AsyncAktion gt In jedem Zustand kann also immer nur eine synchrone aber durchaus mehrere asynchrone Aktionen durchgef hrt werden hnlich wie bei den synchronen Aktionen im voraus gegangenen Abschnitt vorgestellt kann man auch den Start asynchroner Aktionen von der Erf llung
424. tion Durability Application Programming Interface Architektur integrierter Informationssysteme Business to Business Business to Consumer Business Process Management Initiative Business Process Modeling Language Computer Aided Software Engineering Component Object Model Common Object Request Broker Architecture Customer Relationship Management Computer Supported Cooperative Work Database Document Object Model Document Type Definition Enterprise Application Integration Electronic Business XML Electronic Data Interchange Ereignisgesteuerte Prozesskette Enterprise Resource Planning Global Workflow Manager Agent Graphical XML Schema Definition Language HyperText Markup Language HyperText Transfer Protocol Meta Object Facility Model Schema Language Object Constraint Language Object Management Group Portable Document Format Process Markup Language Remote Function Call Role Manager Agent Remote Method Invocation Systeme Anwendungen und Produkte in der Datenverarbeitung Simple API for XML Site Manager Agent Simple Mail Transport Protocol Simple Object Access Protocol Structured Query Language Unified Modeling Language Uniform Resource Locator World Wide Web Consortium Wireless Application Protocol Workflow Automation through Agent based Reflective Processes WFMS Workflow Management System WMA Workflow Manager Agent WML Wireless Markup Language WSDL Web Service Description Language XML Extensible Mark
425. ts Die beiden Datentypen Placeholder und CopyPlaceholder sind als abstrakt gekenn zeichnet weil von ihnen keine konkreten Auspr gungen erzeugt werden k nnen Sie dienen lediglich der Generalisierung der anderen drei Platzhalter Datentypen Somit entspricht ein AnyPlaceholder Exemplar dem any Platzhalter aus der in Ab schnitt 6 3 3 definierten Menge AnyPlaceholder Die Elemente der Menge CopyPlaceholder werden durch die Spezialisierung auf die Datentypen CopyRoot und CopySubs noch einmal in die zwei m glichen Gruppen nur mit dem Platzhalter 7 3 UML Profil f r Prozessdiagramme 131 copyRoot auf der einen und zusammen mit dem Platzhalter copySubs auf der anderen Seite aufgeteilt Insgesamt ergibt sich der folgende Zusammenhang zwischen den Auspr gungen der oben definierten Datentypen linke Spalte und den Mengendefinitionen aus Ab schnitt 6 3 3 rechte Spalte Die OCL Funktion alllnstances siehe OmgOl 6 30 liefert dabei jeweils alle zu einem Zeitpunkt verf gbaren Auspr gungen eines Typs Mit der Teilmengen Beziehung soll angedeutet werden dass diese Auspr gungen quasi Elementen aus den jeweils angegebenen Mengen entsprechen XmiElement alllnstances c XmlElements Def 6 1 AnyPlaceholder alllnstances c AnyPlaceholder Def 6 3 DocType alllnstances c DocTypes Def 6 4 Port alllnstances c Ports Def 6 7 CopyPlaceholder alllnstances _ c CopyPlaceholder Def 6 11 OpenDocType alllnstances c Open
426. typedTransition inv 2 Der Ausgangsport des Quellknotens inputPort der Transition ist ein Teilport des Ein gangsports der im Typ der Transition deklariert wurde inputPort isSubsetOf type sourcePort 3 Der Ausgangsport des Transitionstypes gebunden an den vorausgehenden Port boundTarget der Transition ist ein Teilport des Eingangsports des Zielknotens der Transition outputPort der Transition boundTarget isSubsetOf outputPort Erl uterung Transitionen die als typedTransition klassifiziert sind symbolisieren den bergang von einem Zustand bzw einer Aktivit t im Prozessdiagramm zu einer anderen Dabei charakterisie ren sie sowohl den Kontroll als auch den Datenfluss Im Prozessdiagramm ist jedem Kontroll fluss implizit die Migration eines XML Dokumentes als Datenfluss zugeordnet Das XML Doku ment ist Ergebnis der Quellaktivit t und Eingabe f r die Zielaktivit t Eine typedTransition ist somit eine abk rzende Darstellung f r einen Object Flow State mit dem XML Dokument Zu s tzlich ist der Transition ber ihren Typ eine Schnittstellenspezifikation und eine Konvertie rungsvorschrift zwischen Quell und Zielport zugeordnet Darstellung Als Pfeil wie f r gew hnliche Transitionen mit der zus tzlichen Beschriftung typedTransition und dem Namen des zugewiesenen Typs Die Erstellung eines Prozessdiagramms impliziert die Verwendung von typedTransition bei allen Transitionen Die Beschriftung typ
427. u Informationen ben tigt welche Workflow Instanzen zur Zeit aktiv sind in wel chem Zustand sie sich befinden und welcher Aufgabentr ger gerade welche Aktivit t durchf hrt Als Nebeneffekt der berwachung k nnen Statistiken ber die Abl ufe auf gestellt werden die bei der nachtr glichen Untersuchung von Fehlern hilfreich sein und au erdem als Datenquelle f r die n chste Analysephase dienen k nnen 2 4 Unterst tzung durch Software F r die Durchf hrung der Modellierung und Analyse gibt es eine Reihe von Werk zeugen Sie reicht von reinen Zeichenprogrammen mit denen sich lediglich die Prozessmodelle durch Flussdiagramme oder hnliche Techniken visualisieren lassen bis zu hochintegrierten Werkzeugen wie zum Beispiel das ARIS Toolset mit denen sich gesamte Organisationen und Informationssysteme sowohl aus statischer wie dyna mischer Sicht modellieren lassen vgl Wen00 S 9 Die meisten dieser Werkzeuge zur Modellierung der Gesch ftsprozesse bewegen sich auf einer relativ abstrakten Ebene was sich durch den Gebrauch teilweise infor meller Notationen zur Erstellung der Modelle auszeichnet Mit zunehmender Abstrak tion kann die Beschreibung unpr ziser und in ihrer Interpretation mehrdeutig werden Das Auslassen von zun chst weniger wichtigen Details erleichtert zwar das Verst ndnis der Prozessmodelle macht ihre Beschreibung aber unvollst ndig im Sinne einer Ein gabe f r einen ausf hrenden Interpreter Diesen Unterschied
428. u definieren nicht erf llt aber dadurch angen hert dass die meisten Elemente in der DTD als optional deklariert wurden und auch ausgelassen wer den k nnen wenn sie zum Beispiel f r Prozessdiagramme nicht relevant sind 8 2 3 Bewertung Nachdem exemplarisch die zwei Sprachans tze vorgestellt wurden soll nun eine zusammenfassende Bewertung erfolgen Dabei wird berpr ft inwieweit sie den im Abschnitt 8 1 aufgestellten Anforderungen gerecht werden In Tabelle 8 2 sind alle Anforderungen und die Bewertung der einzelnen Ans tze in Kurzform aufgelistet 8 2 Vorhandene XML Formate f r Prozessmodelle 171 Anforderung XLANG XML Format Graphorientierte Beschreibung des Kontrollflusses x Aufruf vorhandener Services bzw Komponenten bergabe von Parametern an Komponenten Beschreibung von Nebenl ufigkeit und Synchronisation Jlo Entscheidungsbedingungen an Verzweigungen Schachtelung von Prozessteilen Angabe von XML Dokumenttypen mit Ports Typisierung von Transitionen Repr sentation sonstiger Sprachelemente Bekanntes Format oder Standard Dokumente verst ndlich und lesbar Keine Definition nicht ben tigter Elemente vorhanden nicht vorhanden o teilweise vorhanden Tab 8 2 Bewertung vorhandener XML Formate f r Prozessmodelle XLANG kommt als XML basierte Sprache zur Beschreibung von Proz
429. u eines neuen Prozessmodells benutzen lassen Da die internen Abl ufe des Importers sehr technisch sind soll im Folgenden nur grob seine Arbeitsweise erl utert werden Abbildung 8 21 zeigt die Klasse PMLiImporter PMLImporter importState elem Element StateVertex importService elem Element Service getExtensions Element 1 A observes 1 ImportObserver notifyState state StateVertex Void notifyService service Service Void Abb 8 21 Klassen PMLImporter und ImportObserver Die Klasse PMLImporter besitzt zu jeder Datenklasse aus Abschnitt 7 4 eine Methode die als Parameter das XML Element erh lt in dem das korrespondierende Modell element beschrieben wird und als R ckgabewert ein Objekt der zugeh rigen Daten klasse liefert Beispielsweise konstruiert die Methode importService aus der PML Beschreibung eines Service eine Objektinstanz der Klasse Service Der Importer durchl uft Schritt f r Schritt das PML Dokument das importiert werden soll und ruft dabei die passenden Methoden auf Auf diese Weise wird sukzes sive die gesamte Objektstruktur aufgebaut Eine Besonderheit ergibt sich beim Import von Transitionen zwischen Prozesszust nden Da es passieren kann dass der Importer im PML Dokument an eine Stelle kommt die eine Transition beschreibt deren Ziel zustand bis zu diesem Zeitpunkt noch gar nicht importiert wurde kann die zugeh rige 188 Kapitel 8 Beschreibung von P
430. uards angegeben werden wobei darauf zu achten ist dass zur Laufzeit stets eine der Guard Bedingungen wahr wird oder eine Transition den vordefinierten Guard else Merge Dies ist ein Zustand vom Typ junction in dem verschiedene Prozessstr nge zusammenlaufen Das Element lt merge gt muss eine Transition zu einem Nachfolge zustand enthalten die keinen Guard besitzen darf Subaktivit t Mit Hilfe des Elements lt subactivity gt l sst sich ein Subprozess aufrufen Dieser wird durch das Unterelement lt process gt ausgew hlt Es kann entweder ein Attri but ref enthalten dessen Wert einen anderen Prozess einschlie lich seines Package referenziert oder es beschreibt einen vollst ndigen Prozess Dieser ist jedoch als loka ler Prozess anzusehen der nicht an anderer Stelle explizit angesprochen werden kann Ein Subaktivit tszustand besitzt eine Transition zu einem Nachfolger ohne Angabe eines Guards 8 3 Process Markup Language PML 183 lt subactivity gt lt process ref de sundn sunflowexamples Process2 gt lt next gt lt next gt lt subactivity gt lt subactivity gt lt process name Subprocess1 transactional false gt lt inputPort gt lt inputPort gt lt outputPort gt lt outputPort gt lt state id id1 gt lt state gt lt process gt lt next gt lt next gt lt subactivity gt Abb 8 17 Zwei M glichkeiten zum Ansprechen eines Subprozesses Service
431. ubs die Definition offener Ausgabeschnittstellen f r Services erm glichen deren Ausgabetypen von den Dokumenttypen abh ngen die sie von ihrem Vorg nger als Eingabe erhalten Im Kontext eines Prozessdiagramms l sst sich der offene Port durch Bindung an den Ausgabeport des Vorg ngers in einen gew hnlichen Port umwandeln der f r die weitere Verkettung zu einem Kontrollfluss mit nachfolgenden Services besser geeignet ist als wenn er den unbeschr nkten Platz halter any tr ge 100 Kapitel 6 XML Prozesse und Prozessdiagramme Notation offener Ports F r offene Ports wird die EBNF Grammatik von oben vgl Abbildung 6 7 wie folgt erg nzt um auch die neuen Platzhalter mit den Ausnahmelisten angeben zu k nnen OpenPort OpenDoctype f OpenDoctype OpenDoctype Doctype CopyRoot OpenSubs CopyRoot copyRoot copyRoot_except Element Element OpenSubs CopySubs CopySubs Element Element CopySubs copySubs copySubs_except Element Element Abb 6 15 EBNF Grammatik f r offene Ports Die nicht terminalen Symbole Doctype und Element werden wie bei nicht offenen Ports abgeleitet vgl oben Notation von Ports Entsprechende Beispiele f r die durch diese Grammatik definierte Sprache w ren hier a copyRoot copySubs http namespace1 elemB http Inamespace2 elemC http
432. ufgerufen wird merkt er sich zun chst nur intern alle nderungen die vorgenommen werden m ssen Falls er sp ter eine Commit Entscheidung vom Interpreter erh lt bertr gt er alle nderungen in den Datenbestand bzw f hrt alle sonstigen notwendigen Aktionen aus Im Falle eines Abort verwirft er einfach die gemerkten nderungen 2 Alternativ dazu k nnte der Service zwar alle Aktionen bereits dann ausf hren wenn er im Prozess aufgerufen wird daf r jedoch eine inverse Operation oder auch Kompensationsoperation anbieten Falls sp ter der Prozess aufgrund eines Abort zur ckgesetzt werden muss k nnen mit Hilfe dieser Operation alle Aktionen r ck g ngig gemacht werden so dass sich das System wieder im Ausgangszustand befindet Als Beispiel ist ein Service denkbar der einen Flug buchen soll Der Buchungsvorgang muss nun nicht unbedingt verz gert werden bis die Transaktion best tigt wird sondern es k nnte stattdessen eine Stornierungsoperation zur Verf gung stehen mit der sich die Wirkungen des Service aufheben lassen Bei dieser Variante besteht das Problem dass die Eigenschaft der Isolation nicht eingehalten werden kann da m glicherweise nderungen einer gescheiterten Transaktion im System sichtbar werden Wenn dies vermieden werden soll kann es vorkommen dass auch andere Prozesse abgebrochen werden m ssen falls sie Daten gelesen haben die von dem gescheiterten Prozess ver ndert wurden Vergleiche hierzu das Problem de
433. ugeh rigen Schema definiert welche Struktur es hat und welche Unterelemente mit welcher Kardinalit t vorhanden sind Da Schemata bewusst flexibel gehalten sind erlauben sie auch die Definition optionaler Unterelemente sowie sogenannten offenen Inhalt siehe XSch01 Punkt 5 5 bei dem ein Teil der Substruktur unbestimmt bleibt Um trotzdem f r den Port einer Schnittstelle spezifizieren zu k nnen dass bestimmte Unterelemente des Wurzel elementes wirklich vorhanden sein m ssen wird die Syntax der Ports so erweitert dass auch solche Unterelemente verlangt werden k nnen Diese Erweiterung geschieht durch die Erg nzung einer Liste mit Unterelemen ten hinter jedem XML Element eines Ports Diese Liste z hlt eingerahmt von eckigen Klammern alle XML Elemente auf die auf jeden Fall in der Baumhierarchie unterhalb des Wurzelelements vorkommen m ssen F r Elemente deren Minimum kardinalit t laut Schema sowieso gr er als Null ist ist eine solche Angabe eigentlich berfl ssig f r optionale Elemente minOccurs 0 macht sie dagegen Sinn Die Auflistung der Unterelemente ist besonders zur Spezifikation von Services wichtig die das XML Dokument nicht als Ganzes verarbeiten sondern unabh ngig von der Dokumentstruktur lediglich bestimmte XML Elemente herausfiltern und manipulie ren Ein SQL Service k nnte zum Beispiel beliebige XML Dokumente nach einem Element mit dem Namen lt sqlStatement gt durchsuchen um die dort ge
434. und transactional ob der Prozess als Transaktion auszuf hren ist oder nicht Erlaubte Werte sind hier true und false Ein und Ausgangsport des Prozesses werden in den Unterelementen lt inputPort gt und lt outputPort gt entsprechend Abschnitt 8 3 1 definiert Dar ber hinaus enth lt das Element lt process gt Unterelemente lt state gt von denen jedes einen Zustand des Prozessdiagramms mit dem Stereotypen stateWithPorts beschreibt Bei Bedarf kann au erdem ein Element lt extensions gt angegeben werden Sein Inhalt ist im PML Schema durch das Konstrukt lt xsd any gt als offener Inhalt siehe XSch01 5 5 spezifiziert d h es k nnen hier beliebige XML Daten eingebettet werden Hierdurch wird PML zu einer erweiterbaren Sprache die die M glichkeit bietet PML Dokumente um zus tzliche Informationen zu erg nzen Dies k nnen bei spielsweise Daten sein die von einem bestimmten Werkzeug ben tigt werden So nutzt das im Kapitel 9 beschriebene Modellierungswerkzeug den Bereich lt extensions gt um Koordinaten f r alle Zust nde zu speichern damit der Benutzer stets die gleiche grafi sche Darstellung der Workflow Modelle vorfindet Es ergibt sich folgende XML Schema Definition f r die PML Beschreibung eines Prozessdiagramms 180 Kapitel 8 Beschreibung von Prozessen in XML stereotype processDiagram Tags isTransactional Boolean 1 inputPort Port 1 outputPort Port 1 lt xsd
435. und Ausg ngen von Zust nden betrachtet und Bedingungen formuliert wie eine g ltige und konsistente Portverkettung zu einem Kontrollfluss aussehen muss Die Verkettung zum Kontrollfluss geschieht in Prozess diagrammen durch Transitionen zwischen den einzelnen Zust nden Daher wollen wir uns in diesem Abschnitt detailliert den Transitionen zuwenden und sie im Zusammen hang mit dem Port Konzept an unsere Anforderungen anpassen Transitionen mit Transformationen Durch die oben formulierte Bedingung p lt p gt f r die erlaubte Verkettung von zwei Ports wird man bei der Wahl aufeinander folgender Services stark eingeschr nkt Als Nachfolger eines Service sind nur solche Services m glich die die Ausgaben des Vor g ngers direkt verarbeiten k nnen Dazu m ssen die Ausgaben nicht nur den n tigen Informationsgehalt sondern auch die passende Dokumentstruktur aufweisen damit der nachfolgende Service wei an welcher Stelle er eine gesuchte Information finden kann Nun kann es sein dass die Ausgabe des Vorg nger Service zwar alle n tigen Informa tionen enth lt diese aber nicht in der gew nschten Struktur zur Verf gung stellt Dies zeigt sich darin dass der Ausgangsport nicht kompatibel zum Eingangsport des Nach folgers ist Um dem Nachfolger aber doch die Verwendung der Daten und die Arbeit mit dem Dokument zu erm glichen m sste das Dokument zun chst strukturell umge ordnet werden damit es zum Eingangsport des Service konform ist
436. unded gt lt xsd sequence gt lt xsd complexType gt lt xsd complexType name CopySubsType gt lt xsd sequence gt lt xsd element name except type ElementType minOccurs 0 maxOccurs unbounded gt lt xsd sequence gt lt xsd complexType gt Abb 8 6 PML Schema Fragment f r Platzhalter Datentypen DocType und OpenDocType Entsprechend des Datentyps OpenDocType hat jeder Dokumenttyp genau ein Wurzel element das in PML im Element lt root gt beschrieben wird und kann ein oder mehrere Unterelemente fordern die durch lt sub gt beschrieben werden Statt des Elements lt root gt das ein konkret benanntes Wurzelelement definiert kann auch der Platzhalter lt any gt eingesetzt werden Es kann jedoch nicht ein Wurzelelement und ein Platzhalter gleichzeitig angegeben werden Diese Bedingung spiegelt sich in der Semantik des 174 Kapitel 8 Beschreibung von Prozessen in XML XML Schema Elements lt xsd choice gt wider Nur falls es sich um einen OpenDocType handelt l sst sich neben lt any gt auch der Platzhalter lt copyRoot gt verwenden Zur Erf llung dieser Anforderung wurde der spezielle XML Typ OpenDoctypeType definiert Durch die Verwendung des optionalen lt copySubs gt Elements wird beschrieben dass neben dem Wurzelelement auch die Unterelemente bernommen werden sollen dataType OpenDocType root XmilElement 0 1 placeholder Placeholder 0 1 subs XmiElement bind
437. ung f r die Ausf hrung des betroffenen Strangs angeben zu k nnen Auf diese Weise entsteht ein gerichteter Graph der den gesamten Kontrollfluss zwischen den Zust nden beschreibt Es ist jedoch zu beachten dass nicht jeder Zustand beliebig viele Transitionen besitzen darf obwohl dies im abstrakten Syntaxgraph erlaubt ist Beispielsweise untersagt die UML Spezifikation dass ein Fork Zustand mehr als eine Eingangstransition hat siehe Omg01 2 162 Um solche zus tzlichen Regeln f r den Aufbau von Diagrammen zu spezifizieren dient die Object Constraint Language Da sie in dieser Arbeit f r die notwendigen Erweiterungen im Bezug auf Prozessdiagramme verwendet werden soll werden ihre Grundkonzepte im folgenden Abschnitt erl utert 7 1 3 Object Constraint Language An vielen Stellen der UML Spezifikation m ssen einschr nkende Aussagen ber den Aufbau von Diagrammen gemacht werden die sich nicht ohne Weiteres im abstrakten Syntaxgraphen beschreiben lassen Damit f r diese Wohlgeformtheitsregeln nicht auf eine informale Spezifikation ohne eindeutige Semantik zur ckgegriffen werden muss wurde von der OMG die Object Constraint Language OCL eingef hrt Sie kann nicht nur dazu verwendet werden um Aussagen innerhalb des UML Metamodells zu formu lieren sondern auch in der Modell oder Benutzerschicht Daher werden beispielsweise Guard Bedingungen h ufig als OCL Ausdr cke angegeben Ein wichtiges Ziel bei der Entwicklung der OCL war es ein
438. ung und die zugeh rigen Klassen sowohl f r das in Kapitel 9 vorgestellte Modellierungswerkzeug als auch f r weitere Werkzeuge wie den Prozessvalidierer siehe Abschnitt 7 4 2 und den Prozess interpreter siehe Abschnitt 10 2 1 zu verwenden Diese Werkzeuge erfordern jedoch teilweise unterschiedliche Sichten auf die jeweiligen Modellelemente oder zus tzliche Attribute f r die einzelnen Klassen Der Editor zum Beispiel muss f r jedes visuelle Modellelement die Koordinaten bez glich der Zeichenfl che speichern bei denen ein Symbol f r das Modellelement platziert worden ist Um die Modellelemente daf r mit einer flexiblen und erweiterbaren Schnittstelle auszustatten wurde das Entwurfsmuster Adapter vgl Gam96 S 171 eingesetzt und jedem Modellelement ber eine Assozia tion eine Adapterklasse zugeordnet Damit f r verschiedene Modellelemente auch verschiedene Adapterarten erm glicht werden k nnen spezialisierte Unterklassen des abstrakten Adapters AbstractModelElementAdapter gebildet werden Auf diese Weise entstehen zwei Vererbungshierarchien die an der Spitze durch eine Assoziation mitei nander verbunden sind Die folgende Abbildung soll den Einsatz dieses Entwurfs musters noch einmal verdeutlichen AbstractModelElementAdapter Sacapier 1 ModelElement Abb 7 11 Entwurfsmuster Adapter f r Modellelemente 154 Kapitel 7 Metamodell f r Prozessdiagramme 7 5 Validierung von Prozessdiagrammen Im vorherigen Abschnitt w
439. ung von Ports in Prozessdiagramme Zust nde mit Schnittstellenspezifikation durch Ports Alle Zust nde in einem Prozessdiagramm werden von dem Migrationsdokument durchlaufen Um ein m glichst hohes Ma an Konsistenz zu erreichen werden zu jedem Zustand Ein und Ausgabeschnittstellen in Form eines Ports angegeben siehe Abschnitt 6 3 Durch den Zustand d rfen dann nur Dokumente flie en die zu dem Eingangsport inputPort konform sind Der Ausgangsport outportPort definiert die Struktur der Dokumente nachdem sie durch diesen Zustand geflossen sind Einige Zust nde wie SynchStates oder ForkStates sind passiv und reichen ein eingehendes Dokument lediglich unver ndert weiter andere vor allem die Aktivit ts und Subakti vit tszust nde k nnen das Dokument aktiv transformieren und nur ganz bestimmte Dokumenttypen verarbeiten Mit Hilfe der Ports an Zust nden ist es m glich solche Dokumenttypen eindeu tig zu modellieren Allerdings gibt es f r verschiedene Zustandsarten auch unterschied liche Spielr ume bei der Ausgestaltung der dort m glichen Ports Daher findet bei den Constraints der folgenden Stereotyp Definition mit denen die Portverwendung einge schr nkt werden soll eine Differenzierung nach dem jeweiligen Typ des Zustands statt Die Bedingungen sollen dabei garantieren dass die in der Tabelle 6 2 aus Abschnitt 6 3 1 festgehaltenen Vorgaben f r die Ports bestimmter Zustandsarten eingehalten wer den Die Constrai
440. ungen von Methoden Da diese jedoch in dieser Arbeit nicht zum Einsatz kommen soll auf eine tiefergehende Darstellung verzichtet werden 7 2 UML Erweiterungsmechanismen Die UML bietet mit ihren verschiedenen Diagrammarten und Sprachkonstrukten umfangreiche M glichkeiten zur Modellierung von Systemen seien es Hardware systeme Softwaresysteme oder zum Beispiel ganze Unternehmen Neben den durch das UML Metamodell definierten Standardkonzepten sieht das Metamodell auch vor dass sich Erweiterungen der Sprache integrieren lassen siehe Omg01 2 6 Dadurch l sst sich die UML flexibel f r besondere Bed rfnisse und Anwendungsfelder anpassen Mit den in diesem Abschnitt vorgestellten Konstrukten Stereotype Tag Definition mit Tagged Values und Constraint hat man Basiskonzepte zur Hand um die UML durch neue Modellelemente oder neue Semantiken zu erg nzen Wenn es sich dabei um addi tive also erg nzende nderungen der Sprache handelt die nicht im Widerspruch zur Standardsemantik stehen spricht man von einer UML Erweiterung UML Extension siehe Omg01 2 74 Im Gegensatz dazu ist es auch m glich eine sogenannte UML Variante zu defi nieren die ber die Verwendung der drei Erweiterungsmechanismen hinausgeht Daf r m sste man jedoch explizit neue Meta Elemente zum UML Metamodell hinzuf gen und die Sprachvariante somit durch ein eigenes Metamodell spezifizieren siehe Alh99 S 6 19f Diese M glichkeit der Sprachmodifikation ist wenige
441. ungsstufe StateMachine siehe Abbildung 7 6 konnte eingespart werden Im UML Metamodell hat die Klasse StateMachine eine 1 n Assoziation zu den Tran sitionen des Zustandsdiagramms siehe Omg01 Abb 2 24 Uns erschien es dagegen zweckm iger eine solche Assoziation zur Klasse StateVertex anzulegen um so die Verbindung zu allen Zust nden des Prozessdiagramms herzustellen Es handelt sich dabei um eine qualifizierte Assoziation wodurch sicher gestellt ist dass jeder Zustand innerhalb eines Prozessdia gramms einen eindeutigen Identifikator als Namen besitzt F r die Bedeutung der Attribute sei wiederum auf die Definition des Stereotypen processDiagram in Abschnitt 7 3 2 verwiesen Die Klasse StateVertex realisiert das Stereotyp stateWithPorts aus Abschnitt 7 3 2 mit dem alle Zust nde eines Prozessdia gramms ausgezeichnet werden m ssen Diese Klasse bernimmt gleichzeitig die Rolle der gleichnamigen UML Metaklasse Damit handelt es sich auch hier um eine Verschmelzung von Metaklasse und Stereotyp Die Bedeutung der Attribute input Port und outputPort wurde in Abschnitt 7 3 2 bei der Stereotyp Definition erl utert Jeder StateVertex kann ber die zugeh ri gen Assoziationen ein und ausgehende Transitionen haben 7 4 Implementierung des erweiterten Metamodells 151 Transition Die Klasse Transition entspricht der gleichnamigen UML Meta klasse aus Abbildung 7 6 Jede Transition verbindet zwei Zust nde source und target
442. unterst tzt damit die oben genannte zweite Integrationsstufe der Transformation Application Application Application Process Broker HON Message Broker a Punkt zu Punkt Integration b Integration durch Message Broker c Integration durch Process Broker Abb 2 1 Architekturen f r EAI aus Joh00 S 4 2 2 Prozesse in einem Unternehmen 11 Als Erweiterung des Message Brokers sieht Joh00 den Process Broker siehe Abbil dung 2 1c der zus tzlich zur Formatkonvertierung auch Prozesslogik zur Verkn pfung der Anwendungen kapselt Damit wird ein Architekturkonzept f r die dritte Stufe des EAI der Gesch ftprozessabbildung vorgeschlagen mit der es m glich wird die Pro zesse mit einer grafischen Benutzungsschnittstelle zu analysieren und zu administrieren Diese Visualisierung reduziert die Komplexit t und erm glicht verschiedenen Benut zergruppen die Teilnahme am Entwurf der Prozesse Die Process Broker Technologie kann als eine Weiterf hrung von Workflow Management Systemen betrachtet werden bersetzt nach Joh00 S 4 Wir wollen bei solchen EAI Ans tzen die die Gesch ftsprozesse des Unterneh mens ber cksichtigen von prozessorientierter Integration sprechen Es liegt auf der Hand dass die umfangreichen existierenden Anwendungen eines Unternehmens zur Realisierung der neuen E Business Gesch ftsprozesse nicht komplett neu geschrieben werden sondern als erprobte und g
443. up Language XPath XML Path Language XQL XML Query Language XSL Extensible Stylesheet Language A 2 Inhalt der CD Der Diplomarbeit ist ein CD ROM Datentr ger beigef gt auf dem sich das sunFlow System einschlie lich einiger Beispieldaten sowie Materialien zur Dokumentation befinden Die Verzeichnisse haben folgenden Inhalt Dokumentation Diplomarbeit doc Diplomarbeit pdf Pr sentation ppt sunFlow lib fujaba runtime jar xerces jar xalan jar source javadoc sunFlow jar sunflow properties PML Spezifikation PMLSchema xsd Beispieldaten Word Version dieser Arbeit PDF Version dieser Arbeit Pr sentation der Ergebnisse Hilfsbibliothek zur Implementierung von Assoziationen zwischen Klassen Der XML Parser Xerces der Apache Organisation Der XSL Prozessor Xalan der Apache Organisation Quellcode des sunFlow Systems Quellcode Dokumentation als JavaDoc Archiv mit den lauff higen Klassendateien Property Datei XML Schema f r die Sprache PML Einige Beispieldaten die mit dem sunFlow System verarbeitet werden k nnen A 3 Autorenzuordnung 10 11 12 Einleitung Th ne Grundlagen des Workflow Managements Th ne Anforderungsanalyse 3 1 Fallstudie E Business Plattform eines gro en Finanzunternehmens Th ne 3 2 Anforderungen an Workflow Systeme im E Business L tkemeier 3 3 Anforderungen an Workflow Modellierungssprachen L tkemeier 3 4 Zielsetzungen dieser Arbeit Th ne
444. ur n chsten weitergeleitet wird Da das Migrationsdokument alle Workflow relevanten Daten enth lt ist ein zus tzlicher Datenfluss zwischen den ein zelnen Aktivit ten eines Workflow Modells nicht vorgesehen Alternativ w re auch der Ansatz eines expliziten Datenflusses denkbar der nicht 78 Kapitel 6 XML Prozesse und Prozessdiagramme von der festen Vorgabe eines einzigen Dokumentes ausgeht sondern die Modellierung und Ausf hrung von beliebigen Datenfl ssen zwischen den Aktivit ten erm glicht die weitgehend unabh ngig vom Kontrollfluss verlaufen K nnten Dadurch w re es m g lich die Datenfl sse flexibler zu modellieren ein Dokument zum Beispiel direkt von einer Aktivit t zu einer anderen nicht unmittelbar nachfolgenden Aktivit t zu senden die Daten in mehrere kleinere Teildokumente aufzuteilen oder f r eine Aktivit t auch mehrere Ein oder Ausgabedokumente zu modellieren Aus unserer Sicht sind beide Ans tze jedoch weitgehend gleich m chtig und las sen sich ineinander berf hren Die Dokumentmigration etwa k nnte durch allgemeinen Datenfluss realisiert werden indem man sich dort auf nur ein Dokument beschr nkt und den Datenfluss synchron zum Kontrollfluss modelliert so dass dieses Dokument ent sprechend dem Kontrollfluss von Aktivit t zu Aktivit t migriert Auf der anderen Seite kann durch das Migrationsdokument ein expliziter Datenfluss simuliert werden weil das Dokument gem der Analogie zu den Umlaufmappen a
445. urde eine Datenstruktur vorgeschlagen mit der sich Prozess diagramme in einem implementierten System repr sentieren lassen Wenn eine Objekt struktur dieser Datenklassen vorliegt stellt sich die Frage ob sie ein g ltiges Prozess diagramm widerspiegelt d h ob alle im Abschnitt 7 3 f r die Stereotypen aufgestellten Bedingungen erf llt sind und zudem alle Wohlgeformtheitsregeln eingehalten werden die bereits in der UML Spezifikation f r Aktivit tendiagramme gefordert sind Um diese Frage zu beantworten haben wir einen Validierungsalgorithmus entwickelt der eine Objektstruktur der obigen Datenklassen als Eingabe erh lt und pr ft ob alle Anforderungen erf llt sind Ein entsprechendes Werkzeug im Folgenden Validierer genannt kann an verschiedenen Stellen zum Einsatz kommen in dem von uns entwi ckelten System wird es an zwei Stellen verwendet Zum einen kann der Validierer vom Prozesseditor aus jederzeit aufgerufen werden um ein beliebiges Prozessdiagramm auf Korrektheit zu pr fen siehe Abschnitt 9 2 5 Validieren von Prozessdiagrammen Dies ist besonders w hrend der Modellierung eines Workflow hilfreich da der Modellierer sofort erkennen kann an welchen Stellen sein Modell noch unvollst ndig oder fehler haft ist Zum anderen kann der Validierer wahlweise aufgerufen werden bevor der Pro zessinterpreter siehe Kapitel 10 einen Prozess ausf hrt Dies bietet den Vorteil dass vorhandene Fehler in einer Prozessbeschreibung so fr
446. us tzlich d rfen keine Transitionen zwischen verschiedenen dieser Pfade verlaufen es sei denn sie f hren zu oder aus einem Synchronisationszustand Im Folgenden soll erl utert werden wie der Validierer die Einhaltung dieser Regeln pr ft Der Algorithmus verwendet dazu Farben mit denen er die Prozesszust nde markiert Alle Zust nde sind zun chst wei Anschlie end wird eine erste Farbe ungleich wei gew hlt mit der die Zust nde gef rbt werden wenn sie von der Tiefensuche zum ersten Mal erreicht werden Falls die Tiefensuche auf einen Fork Zustand trifft w hlt der Algorithmus f r jeden ausgehenden Pfad eine eigene Farbe die ungleich aller bisher gew hlten ist mit der im Folgenden alle Zust nde des Pfades markiert werden Auf diese Weise l sst sich 7 5 Validierung von Prozessdiagrammen 155 f r jeden Zustand ermitteln zu welchem parallelen Pfad er geh rt Alle Transitionen die im weiteren Verlauf der Tiefensuche gefunden werden und die nicht zu einem Syn chronisationszustand f hren d rfen nun ausschlie lich zu wei en Zust nden f hren oder solchen die die gleiche Farbe besitzen wie der Zustand aus dem die Transition herausf hrt Durch diese Bedingung wird gepr ft ob Transitionen zwischen verschie denen Str ngen verlaufen was nicht erlaubt ist Falls dieser Fall eintritt liegt eine ung ltige Schachtelung vor und es wird eine entsprechende Fehlermeldung ausgegeben Abbildung 7 12 verdeutlicht den Einsatz d
447. usgabe des Archiv Service nur Dokumente vom Typ u oder v sein k nnen die als Eingabe vom Vorg nger Service S bernommen werden In einem anderen Kontext kann die Aus gabe vom Archiv Service wieder ganz anders sein so dass wir ohne den Diagramm kontext also im statischen Modell bei der Spezifikation des Service keine Aussage ber die Dokumenttypen treffen k nnen und deshalb eigentlich den unbestimmten Platzhalter any angeben m ssten Um dies zu vermeiden benutzen wir offene Ports Das sind Ports die die Platz halter copyRoot und copySubs enthalten Diese Platzhalter werden erst dann durch konkrete XML Elemente ersetzt wenn der offene Port an einen anderen nicht offenen Port gebunden wird Der Platzhalter copyRoot kann anstelle des Wurzelelements eines Dokumenttyps angegeben werden Bei der Bindung an einen nicht offenen Port wird der Platzhalter durch die Wurzelelemente dieses Ports ersetzt daher die Bezeichnung copyRoot Hinter dem Platzhalter kann wie bei gew hnlichen Wurzelelementen auch eine Liste von Unterelementen angegeben werden die nach der Bindung an die kopier ten Wurzelelemente angeh ngt werden 98 Kapitel 6 XML Prozesse und Prozessdiagramme gebunden an A c d gt eb gt B a b j Abb 6 10 Beispiel f r die Bindung des Platzhalters copyRoot Durch den Platzhalter copySubs den man zus tzlich in der Unterelementliste zu copyRoot angeben kann wird au erdem das Kopieren der jeweiligen U
448. usgegangenen Kapiteln das Konzept der Prozessdiagramme sowie n tzliche Werkzeuge und Verfahren beschrieben wurden stellt dieses Kapitel ein Modellierungwerkzeug vor mit dem sich Workflow Modelle und Prozessdiagramme entwerfen lassen Es wurde von uns in der Sprache Java entwickelt Im ersten Abschnitt folgt zun chst eine allgemeine Erl uterung des Zwecks eines Prozesseditors sowie der zu Grunde gelegten Konzepte Im Anschluss daran wird auf den Aufbau der Benut zungsoberfl che und grundlegende Bedienungstechniken eingegangen bevor in einer Art Tutorial beschrieben wird wie man schrittweise einen Workflow modelliert Der letzte Abschnitt des Kapitels betrachtet die Implementierung des Systems 9 1 Der Prozesseditor Die Aufgabe des Prozesseditor besteht darin dem Modellierer ein Werkzeug zur Verf gung zu stellen mit dem sich komplette Workflow Modelle verwalten lassen Dazu z hlt zun chst die M glichkeit ein statisches Modell anzulegen d h Konnektoren zu erzeugen und Transitionstypen zu definieren die als Grundbausteine f r Prozess diagramme ben tigt werden Weiterhin gibt es die M glichkeit aus diesen Bestand teilen komplexe Prozesse zu konstruieren bzw vorhandene Prozesse zu bearbeiten Zu diesem Zweck stellt der Editor Prozessdiagramme visuell dar und erlaubt direkte nde rungen an dieser Darstellung durch den Modellierer Insbesondere stehen Eingabe dialoge zur Verf gung ber die sich die aus Abschnitt 6 3 bekannten P
449. usiness Plattform ist es m glichst alle diese Softwarekomponenten einzubinden und in die Workflow Modelle zu integrieren 80 Kapitel 6 XML Prozesse und Prozessdiagramme Bei der Vorstellung der Architektur eines Internet Portal Systems schreiben Gruhn und Sch pe in Gru01 dazu The business transactions conducted between two partners in electronic commerce or electronic business are supported entirely or in part by different software systems In this sense an electronic commerce portal is an integration platform for different software systems like legacy web Internet or office systems siehe Gru01 S 2 Bei der L sung dieser Aufgabe stellt sich als zentrale Frage das Problem der Schnittstellen die ben tigt werden um die verschiedenen Komponenten anzusprechen und Daten mit ihnen auszutauschen W nschenswert w re es wenn das WFMS zu allen Komponenten eine passende Schnittstelle vorf nde der es das aktuell vorhandene Migrationsdokument bergibt und dann auf die R ckgabe eines transformierten Doku mentes wartet Da allerdings nicht davon auszugehen ist dass alle Komponenten eine solche Schnittstelle mit Dokument bergabe anbieten ist es n tig kleine Programme zu entwickeln die eine Art Br ckenfunktion zwischen dem WFMS und den einzelnen Komponenten bernehmen Diese sogenannten Konnektoren bieten dem WFMS die gew nschte Schnittstelle zur Daten bertragung m ssen aber auf der Verbindungsseite zur angesprochenen
450. ut getestete Komponenten wiederverwendet werden sollen vgl Moh01 S 4 Diese Komponenten m ssen im Rahmen des prozess orientierten Integration zu einem Workflow zusammengesetzt werden Beim Start eines solchen Prozesses l st die Eingabe der Workflow relevanten Daten an einer Benut zungs oder Systemschnittstelle einen Datenfluss aus Diese Daten werden dann durch eine oder mehrere Anwendungen im Verlauf des Vorgangs entweder direkt verarbeitet oder diese Anwendungen f hren unterst tzende Funktionen quasi bewusste Seiten effekte aus w hrend die Daten durch den Prozess flie en vgl Moh01 S 5 Zu den Herausforderungen der prozessorientierten Integration geh ren laut Moh01 S 5ff die berwindung inkompatibler Protokolle und Datenformate sowie insbesondere Verfahren zum Workflow Entwurf und zur Workflow Kontrolle In WesOl hei t es dazu Diese L sungen m ssen in der Lage sein Gesch ftsprozesse zu modellieren und zu automatisieren Dies hebt die Bedeutung des Workflow Manage ments im Rahmen der prozessorientierten Integration hervor F r die angesprochene berwindung inkompatibler Datenformate eignet sich der derzeitige Standard XML eXtensible Markup Language siehe XMLO0 bei dem sich zus tzliche Kostenreduk tionen ergeben k nnen weil ausreichend Werkzeuge zum Umgang mit XML Daten teilweise sogar frei verf gbar sind vgl MohOl S 11 Insbesondere gibt es die M glichkeit XML Daten auf andere pr
451. uten k nnte man die geforderten Parametereinstellungen f r die Akti vit ten der EPK realisieren 5 2 Ereignisgesteuerte Prozessketten 65 Zur Beherrschung der Komplexit t von Modellen bietet die EPK drei Alternati ven an die hierarchisierten Funktionen Prozessmakros und die Prozesswegweiser W hrend die Prozesswegweiser in erster Linie zur Verkettung einzelner EPKs genutzt werden eignet sich die M glichkeit einer hierarchisierten Funktion zur Realisierung der in der Anforderungsanalyse gew nschten hierarchischen Schachtelung Bei der Hierar chisierung einer EPK wird in einer Funktion auf einen bereits definierten anderen Pro zess verwiesen der beim Erreichen dieser Aufgabe ausgef hrt werden soll vgl Kel99 S 166 168f Prozess 1 Aufgabe 1 Q HH Prozess 1 a Abb 5 8 Hierarchisierung einer EPK nach Ke199 S 169 Das Konzept der Hierarchisierung wird auch in den Referenzmodellen von SAP einge setzt Dabei werden Bibliotheken mit sogenannten Prozessbausteinen gebildet Jeder Prozessbaustein besteht aus einer elementaren Prozess EPK Diese Grundbausteine k nnen auf einer zweiten h heren Stufe zu Szenarien zusammengefasst werden Die entsprechende EPK eines Szenarios wird Szenario EPK genannt In ARIS gibt es neben der EPK weitere Modelle mit denen die Struktur des Systems dargestellt werden kann Diese Sichten k nnte man verwenden um ein stati sches Modell zu einem Workflow aufzubauen in dem die verf g
452. ven Vorgehen weil sich der Zyklus von Typdefinition und Typverwendung st ndig wiederholt 6 3 3 Formale Definition von Ports und typisierten Transitionen W hrend in den vorausgegangenen Abschnitten relativ informell in das Konzept der Ports eingef hrt wurde erfolgt in diesem Abschnitt daran ankn pfend eine formale Definition der einzelnen Konstrukte Dadurch wird ihnen eine pr zise und eindeutige Semantik verliehen die den Einsatz der Ports bei der Modellierung von Dokument strukturen im Prozessdiagramm auf eine gesicherte Fundierung stellt Die formale Theorie hilft nicht nur den Zusammenhang zwischen der vorab eingef hrten Syntax und der nun formalisierten Semantik zu pr zisieren sondern sie dient auch als Grund lage f r eine sp tere Implementierung des Konzepts und begr ndet durch die mathema tische Analyse der Zusammenh nge Berechnungsm glichkeiten und erste Algorithmen Au erdem lassen sich innerhalb der Theorie Zusammenh nge mathematisch korrekt beweisen die die Konsistenz innerhalb des Port Konzeptes sicherstellen Nach Abschnitt 6 3 1 soll ein Port benutzt werden um die Schnittstelle eines Service eines Zustands oder eines ganzen Prozesses zu definieren Dazu ist es n tig dass er eine bestimmte Menge von XML Dokumenten genau spezifiziert Um dieses Ziel auch in der formalen Semantik zu erreichen wird zun chst dargelegt was wir innerhalb dieser Theorie unter einem XML Element und einem XML Dokument verste hen woll
453. verst ndlich exampleAction lt xml version 1 0 encoding UTF 8 gt lt XMI xmi version 1 0 gt lt XMI header gt lt XMI metamodel xmi name UML xmi version 1 3 gt lt XMI header gt lt XMI content gt lt ActivityGraph xmi id xmi 3 gt lt name gt workflowProcessingActivityGraph lt name gt lt StateMachine top gt lt CompositeState xmi id xmi 4 gt lt name gt activities_top lt name gt lt CompositeState subvertex gt lt Pseudostate xmi id xmi 5 gt lt name gt initalState lt name gt lt Pseudostate kind xmi value initial gt lt StateVertex outgoing gt lt Transition xmi idref xmi 6 gt lt StateVertex outgoing gt lt Pseudostate gt lt ActionState xmi id xmi 7 gt lt name gt exampleAction lt name gt lt StateVertex outgoing gt lt Transition xmi idref xmi 8 gt lt StateVertex outgoing gt lt StateVertex incoming gt lt Transition xmi idref xmi 6 gt lt StateVertex incoming gt lt ActionState gt lt FinalState xmi id xmi 11 gt lt FinalState gt lt CompositeState subvertex gt lt CompositeState gt lt StateMachine top gt lt StateMachine transitions gt lt Transition xmi id xmi 6 gt lt Transition stateMachine gt lt StateMachine xmi idref xmi 3 gt lt Transition stateMachine gt lt Transition source gt lt StateVertex xmi idref xmi 5 gt lt Transition source gt lt Transition target gt lt StateVertex xmi idref
454. verteilten Systemen Skriptum zur Vorlesung Verteilte Systeme I 6 Universit t Paderborn 2000 http www uni paderborn de cs ag heiss lehre vs vs_6_4 pdf 258 Literatur und Quellen Hen01 Hans Thomas Hengl E Business Anwendungen bilden nur Inseln in der IT Landschaft Computer Zeitung Nr 36 vom 6 September 2001 S 9 Konradin Verlag Leinfelden HTML99 Dave Raggett et al ISO96 Jec00 Jin01 Joh00 Kel92 Kel99 Kon96 HTML 4 01 Specification W3C World Wide Web Consortium Recommendation 24 Dezember 1999 http www w3 org TR htm1401 ISO Extended BNF ISO IEC 14977 1996 E International Organization for Standardization Genf http www dataip co uk Reference iso 14977 pdf Mario Jeckle Entwurf von XML Sprachen Java Spektrum 6 00 SIGS Conferences GmbH November 2000 http www jeckle de entwurfxml entwurfxml html Sun Microsystems Inc Jini Network Technology An Executive Overview http www sun com jini whitepapers jini execoverview pdf P Johannesson B Wangler und P Jayaweera Application and Process Integration Concepts Issues and Research Directions Information Systems Engineering Symposium 2000 Hrsg Brinkkemper Lindencrona und S lvberg Springer Verlag 2000 http www dsv su se perjons fossilpaul2 pdf G Keller M N ttgens A W Scheer Semantische Proze modellierung auf der Grundlage Ereignisgesteuerter Proze ketten EPK Forschungsberi
455. voll erscheint Dadurch werden die Vorz ge der Fehlertoleranz Idee gewahrt ohne unn tige Performanzverluste dulden zu m ssen 10 3 Fehlerbehandlung 227 10 3 2 Explizite Modellierung von Fehlerbehandlungen Wie die vorausgegangenen Betrachtungen gezeigt haben wird sich ein gro er Teil m glicher Fehler nicht tolerieren lassen sondern muss vom Prozessinterpreter behan delt oder weitergeleitet werden Da die hier ausgef hrten Workflow Modelle auf der Verarbeitung von XML Dokumenten durch Services basieren w re in Analogie zu den Ausnahmen in Java die Definition von eigenen XML Elementen denkbar die Informa tionen und Meldungen ber aufgetretene Fehler speichern k nnen Wenn bei der Aus f hrung eines Service ein Fehler auftritt K nnte der Service dann anstelle des eigentli chen Migrationsdokuments ein XML Dokument mit den Fehlerinformationen ausgeben das dann ohne unkontrollierten Abbruch des Prozesses in einer explizit modellierten Fehlerbehandlung weiterverarbeitet werden k nnte vgl Abbildung 10 11 Service f u v 8 errof local name error ErrorHandler Abb 10 11 Explizite Fehlerbehandlung im Prozessmodell Man k nnte berlegen bei allen Service internen Fehlern diese Methode anzuwenden und automatisiert eine Ausnahme Exception abzufangen um sie in ein XML Element umzuwandeln das zum Beispiel unter dem Namen lt error gt vordefiniert wurde Weil man Fehler nie ganz ausschlie en
456. werden 1 Die Workflow Management Coalititon siehe Wmc99 S 29ff hat vier grundle gende Kontrollflusskonstrukte identifiziert die von der Sprache unterst tzt wer den m ssen a Sequenzen b bedingte Verzweigungen c Schleifen d Nebenl ufigkeit bzw parallele Teilprozesse und deren Synchronisation 2 Aufgrund der Definition eines Gesch ftsprozesses als Folge von Aktivit ten mit einem gemeinsamen Gesch ftsziel wird in Aal97 die Forderung gestellt dass je des Workflow Modell a genau einen definierten Startpunkt und b genau einen definierten Endpunkt besitzen muss 32 Kapitel 3 Anforderungsanalyse Die Aktivit ten w hrend der Ausf hrung des Workflows stellen in der Regel Ope rationen auf den Workflow relevanten Daten in Form eines XML Dokuments oder in Abh ngigkeit von ihnen dar Dazu muss die Modellierungssprache Kon strukte zum gezielten Zugriff auf diese XML Daten bereitstellen Damit wird es erm glicht den Kontrollfluss in Abh ngigkeit von den vorhandenen Daten zu modellieren Zus tzlich muss es m glich sein im Modell Aussagen ber die Struktur der XML Daten an jeder Stelle des Prozesses zu machen Dadurch k n nen sowohl Fehler im Modell selbst als auch Inkonsistenzen bei der sp teren Ausf hrung des Prozesses besser erkannt werden Ein Workflow Modell besteht entsprechend der Definition vgl Wmc95 aus einer Verkettung von Aktivit ten Eine Aktivit t in den hier betrachteten XML basierten
457. werden sie beim Schalten der Transitio nen von Stelle zu Stelle weitergeleitet Um verschiedene Objekte die sich im Netz befinden unterscheiden zu k nnen muss man auf die Technik der individuellen Marken zur ckgreifen Auf diese Weise k nnen sowohl Objekte die zu unterschiedlichen Anwendungsf llen als auch verschiedene Dokumente innerhalb desselben Anwen dungsfalls eindeutig identifiziert werden Weiterhin ist es m glich beliebige Attribute und deren Werte an eine Marke zu binden um so Manipulationen an den Objekten beschreiben zu k nnen Bei den in dieser Arbeit betrachteten XML basierten Workflows erh lt jeder Prozess bei seiner Ausf hrung ein XML Dokument als Eingabe siehe Abschnitt 6 1 Dieses kann w hrend des Durchlaufs manipuliert werden und bildet schlie lich die Ausgabe bzw das Ergebnis des Prozesses Eine geeignete Sprache muss so konstruiert sein dass lesender und schreibender Zugriff auf dieses Dokument beschrieben werden kann Einen interessanten Ansatz in dieser Richtung haben Kirsten Lenz et al in LenOl mit sogenannten XML Netzen vorgestellt Das Ziel bei der Entwicklung von XML Netzen war die Verbindung der Flussmodelle von XML Dokumenten mit Gesch ftsprozessen und deren Ausf hrung Ein zentraler Aspekt in XML Netzen ist die G ltigkeit von XML Dokumenten bez glich DTDs Zur grafischen Beschreibung von DTDs dient dabei die Sprache Graphical XML Schema Definition Language GXSL Ein XML Netz ist laut LenOl ein
458. werden und visualisiert werden k nnen 7 3 UML Profil f r Prozessdiagramme 141 Tag sourcePort Stereotyp transitionType Typ ProcessDiagrams Port Multiplizit t 1 Erl uterung Dieser Port spezifiziert die Menge von Dokumenten die in diese Transition flie en k nnen Tag targetPort Stereotyp transitionType Typ ProcessDiagrams OpenPort Multiplizit t 1 Erl uterung Dieser Port spezifiziert eine Menge von Dokumenten die alle m glichen Ausgabedokumente dieser Transition enth lt Tag transformation Stereotyp transitionType Typ UML DataTypes Expression Multiplizit t 0 1 Erl uterung Dieser Ausdruck spezifiziert eine Transformationsfunktion die in der Regel als Stylesheet der Sprache XSLT kodiert ist Der Definitionsbereich der Funktion entspricht dem Quellport des Transitionstyps der Wertebereich dem Zielport des Transitionstyps Der Ausdruck kann entwe der das Stylesheet selbst enthalten oder auf eine externe Datei verweisen in der das Style sheet abgelegt ist Die Transformationsfunktion entspricht der Funktion trans aus Def 6 16 siehe Abschnitt 6 3 3 Um die Anwendbarkeit des Migrationssatzes sicherzustellen muss die Transformationsfunktion die in Def 6 16 getroffenen Einschr nkungen erf llen Tab 7 8 Definition des Stereotyps transitionType Das folgende Stereotyp typedTransition definiert eine Transition der ein
459. ws m glich sein vgl B h95 S 15 Gerade diese Anforderung stellt laut Geo95 S 139 ein nicht triviales Problem dar 4 Im Zusammenhang mit den Daten die durch einen Prozess verarbeitet werden unterscheidet das Workflow Referenz Modell zwei Arten siehe Wmc95 S 25 Workflow relevante Daten enthalten alle Informationen die f r die Ausf hrung einer bestimmten Prozessinstanz von Bedeutung sind Sie werden beim Aufruf des Prozesses festgelegt bzw bergeben und enthalten insbesondere Steuerungs informationen die den Prozessablauf direkt beeinflussen Das Workflow Management System muss daf r sorgen dass alle Komponenten Zugriff auf die 3 2 Anforderungen an Workflow Systeme im E Business 29 Workflow relevanten Daten haben Bei der Fallstudie k nnen beispielsweise die Eingabedokumente die jeweils einen Vorgang ausl sen als solche Daten inter pretiert werden Demgegen ber sind Workflow Applikations Daten alle sonsti gen Daten die von den aktiven Komponenten des Systems gelesen oder geschrie ben werden Ihre Verarbeitung ist jedoch f r das WFMS transparent Im Verlauf einer Prozessausf hrung m ssen die Workflow relevanten Daten maschinell verarbeitet werden Mit der Integration bestehender Komponenten in einen Prozess entsteht zwangl ufig das Problem des Datenaustausches zwischen heterogenen inkompatiblen Systemen In j ngster Zeit hat sich XML als Daten format f r heterogene Umgebungen stark verbreitet I
460. wurden und ihr Dokument abgelegt haben wird die Ausf h rung fortgesetzt und ein gemeinsames Ergebnisdokument konstruiert Zeile 50 Die Ausf hrung des gesamten Prozesses ist beendet sobald der oberste Aufruf der Methode executeSection terminiert dem der Startzustand des Prozesses als Parameter bergeben wurde Nachdem nun die Semantik von Prozessdiagrammen festgelegt und darauf auf bauend ein Ausf hrungsalgorithmus f r Prozesse entworfen wurde haben wir den Prozessinterpreter entwickelt der im folgenden Abschnitt beschrieben wird 10 2 Der Prozessinterpreter 217 10 2 Der Prozessinterpreter Die Aufgabe des Prozessinterpreters besteht darin die mit dem Modellierungswerkzeug entworfenen und in PML gespeicherten Prozessmodelle entsprechend der im letzten Abschnitt festgelegten Semantik auszuf hren Er besitzt dazu eine Reihe von Klassen f r unterschiedliche Bereiche wie interne Repr sentation der Prozessmodelle Aufruf von Konnektoren Synchronisation und andere Wie schon das Modellierungswerkzeug wurde auch der Interpreter in der Sprache Java realisiert In den folgenden Abschnitten werden die jeweils wichtigsten Bestandteile erl utert Alle Klassen des Interpreters bestehen zusammen aus ungef hr 5 000 LOC lines of code 10 2 1 Interne Datenstruktur zum Zugriff auf Prozessmodelle Es gibt prinzipiell zwei verschiedene M glichkeiten f r die Verwaltung der Prozess modelle durch den Interpreter Zum einen k nnte er geeign
461. www cobase cs ucla edu tech docs dongwon mura0619 pdf R Medina Mora T Winograd P Flores Action Workflow as the Enterprise Integration Technology Bulletin of the Technical Committee on Data Engineering Vol 16 2 1993 IEEE Computer Society Mesginson Technologies SAX 2 0 The Simple API for XML Mai 2000 http www megginson com SAX Microsoft Corporation BizTalk Orchestration A Technology for Orchestrating Business Interactions White Paper Juni 2000 http www microsoft com biztalk techinfo planning 2000 wp_orchestration doc Microsoft Corporation Microsoft BizTalk Server Web Site http www microsoft com biztalk default asp Object Management Group Meta Object Facility MOF Specification Version 1 3 M rz 2000 ftp ftp omg org pub docs formal 00 04 03 pdf Stephen Mohr Scott Woodgate Professional BizTalk Wrox Press Inc ISBN 1861003293 Januar 2001 http www wrox com books samplechapters 3293 content pdf 260 Literatur und Quellen Oes97 Omg99 Omg00 Omg01 Rit99 Rit00 Sch98 SOAPOI SunO1 Tha00 Bernd Oestereich Objektorientierte Gesch ftsprozessmodellierung mit der UML OBJECTspektrum Ausgabe 2 98 Sigs Datacom GmbH Troisdorf http www oose de download oogpm pdf Object Management Group UML Profile for Enterprise Distributed Object Computing Request for Proposal M rz 1999 ftp ftp omg org pub docs ad 99 03 10 pdf Object Management Group
462. xmi 7 gt lt Transition target gt lt Transition gt lt Transition xmi id xmi 8 gt lt Transition gt lt StateMachine transitions gt lt ActivityGraph gt lt XMI content gt lt XMI gt Abb 8 4 Ein kleines UML Aktivit tendiagramm als XMI Dokument 170 Kapitel 8 Beschreibung von Prozessen in XML Wie erwartet korrespondiert das XMI Dokument sehr stark mit der Struktur des UML Metamodells Da ein Aktivit tendiagramm dort als Vernetzung von Zust nden durch Transitionen definiert ist wird die Anforderung einer graphorientierten Strukturierung des XML Formats vgl Abschnitt 8 1 Punkt 2 erf llt Das Beispiel zeigt wie die Ablaufbeschreibung im Gegensatz zu einem durch XLANG beschriebenen Workflow nicht durch Strukturelemente wie lt sequence gt lt while gt oder lt all gt sondern durch wechselseitige Referenzierungen auf nachfolgende und vorausgehende Elemente inner halb des Ablaufgraphen definiert ist Au erdem ist es mit der UML DTD inh rent m glich alle Konstrukte von Prozessdiagrammen abzuspeichern die keine Erweiterung von Aktivit tendiagrammen darstellen Dazu geh ren der Aufruf von Operationen eines Interfaces mit bergabe von Parametern in Aktivit ten die Schachtelung von Abl ufen durch Subaktivit ten sowie Konstrukte f r Nebenl ufigkeit Synchronisation Verzwei gung und die Angabe von Ausdr cken als Entscheidungsbedingungen guards Da die Definition der Erweiterungen im Zusammenhang
463. zwischen dem abstrakten Modell und einer pr zisen ausf hrbaren Formalisierung bezeichnet man als seman tische L cke s WenO0 Erzeugt wird diese Diskrepanz insbesondere dadurch dass die Semantik der zumeist grafischen Notation in der die Prozessmodelle aufgestellt werden nicht pr zise und eindeutig definiert worden ist vgl z B Ereignisgesteuerte Prozessketten Abschnitt 8 2 Einige Modellierungsans tze erlauben sogar die nat r lichsprachliche Beschreibung auszuf hrender Aktivit ten was die semantische L cke weiter vergr ert denn f r eine softwaregest tzte Ausf hrung m ssen diese Aktivit ten genau und in einer vom Rechner verst ndlichen Form spezifiziert sein Doch auch wenn die Werkzeuge nur die abstrakte Modellierung der Prozesse leisten und wegen der semantischen L cke keine Ausf hrung der Modelle anbieten Kommt ihnen eine wich tige Bedeutung zu da die von ihnen geleistete Visualisierung der Abl ufe zumindest Schwachstellen erkennen l sst und besseres Verst ndnis f r die Zusammenh nge erzeugt Um die beschriebene semantische L cke zwischen dem Modell eines Gesch fts prozesses und einer pr zisen Workflowbeschreibung die als Eingabe f r die Aus 20 Kapitel 2 Grundlagen des Workflow Managements f hrung dienen kann zu berbr cken ist eine Verfeinerung der Prozessmodelle n tig Zu den Aufgaben die beim bergang vom Gesch ftsprozess zum Workflow Modell auszuf hren sind z hlen nach Wen00 S 1

Prozessorientierte Integration von Softwarekomponenten durch XML

Contents

Download Pdf Manuals

Related Search

Related Contents