Orchestrace a choreografie procesů v BORM

Transkript

1 Orchestrace a choreografe procesů v BORM Dsertační práce z oboru Informační Management Ing. Josef Moravec Školtel: doc. Ing. Prokop Toman, CSc.

2 Chtěl bych na tomto místě poděkovat svému vedoucímu doc. Ing. Prokopov Tomanov, CSc. za veškeré rady, přpomínky a odborné vedení př psaní této práce. Dále bych rád poděkoval mým kolegům z Katedry nformačního nženýrství, kteří m byly vždy ochotn pomoc a poradt a v nchž jsem našel nejen odborníky ve svém oboru, ale také přátele. V neposlední řadě bych na tomto místě rád poděkoval mým rodčům a všem mým blízkým, kteří m vždy byl velkou oporou. Josef Moravec

3 Orchestrace a choreografe procesů v BORM Klíčová slova Orchestrace, choreografe, BORM, modelování procesů, konečné automaty Abstrakt Práce se zabývá problematkou řízení komunkace mez nterním a externím účastníky obchodních procesů s využtím metody BORM. Cílem práce je jednoznačně formálně popsat procesní dagramy v BORM pomocí teore konečných automatů, tak aby bylo možné tímto způsobem zaznamenat nejen řídící toky, ale také datové toky. Dílčím cílem práce je rozšířt metodu BORM případně její část tak, aby bylo možné lépe a efektvněj modelovat choreograf v rámc procesů. Busness process orchestraton and choreography usng BORM method Keyword Orchestraton, choreography, BORM, process modelng, fnte state machnes Abstract The thess deals wth the communcaton between nternal and external users of busness processes usng BORM method. The am of ths work s to formally and clearly descrbe the process dagrams n BORM usng the theory of fnte state machnes, n order to descrbe not just control flows but also the data flows. Furthermore the work suggests extenson of the BORM method so that t can be used for better and more effcent modelng of the choreography nsde busness processes.

4 Obsah 1 Úvod Cíle Metodka Vybrané nástroje pro modelování procesů, orchestrace a choreografe Technky modelování obchodních procesů Busness Process Modelng Notaton Tokové objekty Data Spojovací objekty Dráhy Artefakty Busness Object Relaton Modelng Rozšíření BORM Analýza procesního modelu pomocí OBA Procesní dagramy v BORM Konečné automaty Mooreův sekvenční stroj Meallyho sekvenční stroj Komunkující konečné automaty Webové služby Web Servce Modellng Framework Web Servce Modelng Ontology Orchestrace a choreografe ve WSMO Vybrané jazyky pro pops choreografe a orchestrace Busness Process Executon Language for Web Servces BPEL4People XML Process Defnton Language Web Servces Conversaton Language...55

5 7.5 Web Servce Choreography Interface Web Servces Descrpton Language Web Servces Choreography Descrpton Language IZMAN CASE Komparace vybraných jazyků pro pops choreografe a orchestrace Orchestrace a choreografe Choreografe Orchestrace Výchozí předpoklady dsertační práce Motvace Formální pops ORD Pops ORD pomocí konečného automatu Pops chování partcpanta Proces s více nekomunkujícím partcpanty Proces s více vzájemně komunkujícím partcpanty Orchestrace a choreografe v BORM Choreografe a orchestrace z pohledu BORM Procesy z pohledu partcpantů Srovnání BPMN a BORM Defnce problémové domény Zobrazení procesu v BPMN a BORM Model choreografe v BPMN a BORM Návrh rozšíření metody OBA pro BORM Identfkace klíčových stavů objektů Záznam komunkací pomocí OCMC Rozšířená metoda OBA...104

6 12 Dskuse Závěr Ctovaná lteratura Seznam obrázků a tabulek...122

7 Úvod 1 Úvod Busness Process Management (BPM) je komplexní manažerský přístup zahrnující metody, technky a nástroje pro podporu analýzy, návrhu, zavádění a správy provozních obchodních procesů (van der Aalst, a další, 2003). Během posledních dvacet let došlo k výraznému zvýšení zájmu o oblast řízení podnkových procesů. Díky velké poptávce po BPM exstuje pro řízení podnkových procesů mnoho metod, technk a nástrojů. Stále více společností nvestuje za účelem zvyšování efektvty práce a snžování provozních nákladů nemalé prostředky do analýzy, rengeneerngu nebo audtu procesů probíhajících ve frmě. Důležtým předpokladem pro efektvní fungování podnku jsou dobře zdokumentované procesy, které se snadno udržují a jednoduše provádějí. Dobře navržené a spravované procesy snžují jak časovou, tak fnanční náročnost na provoz (Brocke a Rosemann, 2010). Jednodušší procesy jsou lépe provedtelné a často spolehlvější. Rozmach dstrbuovaných technologí a potažmo servsně orentovaných archtektur umožnl snadnější nterakce napříč společnostm. Internet jž dávno není pouze prostorem pro sběr a prezentac nformací. Rozvoj webových služeb znamenal posun nternetu od úložště nformací k nástroj pro dstrbuované výpočty. Podle zkušeností autora práce může využtí webových služeb jako účastníků procesu zjednodušt návrh procesu tím, že se elmnuje nutnost realzovat úkol, který služba zabezpečuje, pomocí do nedávné doby běžných konstrukcí. Běžnou konstrukcí je myšleno například objednávání zboží zaměstnancem jedné společnost prostřednctvím sytému společnost jné. Objednatel může pověřt zaměstnance, který bude prostřednctvím systému poskytovaným dodavatelem zboží objednávat. Takový koncept má svá úskalí př plánování procesu. Nahradíme-l pověřeného zaměstnance a systém dodavatele webovým službam, lze jednak mnohdy zjednodušt návrh procesu a také je možné do logky rozhodování procesů začlent parametry jejch vzájemné komunkace. Využtí webových služeb může vést ke zjednodušení procesů a snížení provozních nákladů na proces alokovaných. Na druhé straně je př návrhu procesů obsahujících jak reálné užvatele (ld), tak webové služby, nutné ošetřt různá chování webových služeb na konkrétní vstupy a pochoptelně také výjmky, aby nedocházelo k zacyklení nebo uváznutí procesu. Součástí Busness Procees Managementu je řízení průběhu procesů, ať jž jsou jejch účastníc reální užvatelé nebo webové služby. Problematkou užtí webových služeb jako účastníků procesů se zabývá orchestrace a choreografe. 7

8 Úvod Orchestrace nebo také někdy nstrumentace, je název odvozený z hudební teore, který vyjadřuje technku hudební skladby mající za cíl optmální využtí rozlčného počtu hudebních nástrojů za účelem dosažení požadovaného efektu př reprodukc hudební skladby. Orchestr je řízen drgentem. Přeneseno na problematku procesů je možné orchestrac chápat jako koordnac procesů a jejch účastníků, kteří jsou reprezentován pomocí webových služeb. Orchestrace popsuje pořadí vykonávání nterakcí webových služeb a může zahrnovat jak nterní, tak externí webové služby. Př orchestrac je proces vždy řízen jednou stranou, kterou označujeme jako orchestrátora. Orchestrace je podrobně popsána v kaptole 8.2. Obdobnou analogí lze popsat choreograf, jejíž defnc a podrobnému popsu je věnována kaptola 8.1. Choreografe je čnnost spočívající ve vytvoření koncepce, kompozce a řízení tanečního díla. Jednotlví tanečníc tančí podle předem daného scénáře, anž by byl řízen. Přeneseme-l opět koncept taneční choreografe na procesy, lze říc, že choreografe popsuje spoluprác a vzájemnou nterakc účastníků procesu nebo webových služeb za účelem dosažení společného cíle. Účastníc procesu popsují svoj rol v rámc choreografe. Na rozdíl od orchestrace zde není určen řídcí element a nterakce se popsují z globálního pohledu. 8

9 Cíle 2 Cíle Práce se zabývá problematkou řízení komunkace mez nterním a externím účastníky obchodních procesů s využtím metody BORM. Jednotlví partcpant mohou být reprezentován jak webovým službam, tak reálným užvatel. Obecně je pro takový způsob řízení komunkace nazýván orchestrací, respektve choreografí procesů. Hlavním cílem této práce je jednoznačně formálně popsat procesní dagramy v BORM pomocí teore konečných automatů, tak aby bylo možné tímto způsobem zaznamenat nejen řídící toky, ale také datové toky. Aby mohlo být tohoto cíle dosaženo, je nutné splnt následující dílčí cíle: Analyzovat lterární zdroje zabývající se problematkou procesního modelování, teore konečných automatů a webových služeb. Formálně popsat procesní dgram v BORM jako konečný automat a nalézt analogcký koncept v oblast konečných automatů, tak aby tento koncept bylo možné využít pro záznam komplexního chování procesu. Dílčím cílem práce je rozšířt metodu BORM případně její část tak, aby bylo možné lépe a efektvněj modelovat choreograf v rámc procesů. Dalším dílčím cílem práce je na základě komparace vybraných jazyků pro pops webových služeb a jazyku, který je použt pro defncí procesů v nástroj IZMAN Case navrhnout změny v jazyce, který je aktuálně pro záznam procesů používán s ohledem na možnost defnovat orchestrac a choreograf. 9

10 Metodka 3 Metodka První část práce bude obsahovat analýzu lterárních pramenů z oblast webových služeb, mapování obchodních procesů a teore konečných automatů. Se zvláštním zaměřením na metodu BORM budou popsány vybrané metody pro modelování obchodních procesů, na kterých budou demonstrovány možnost modelování orchestrace a choreografe. Jelkož se autor práce nejčastěj setkal s pojmy orchestrace a choreografe v souvslost s webovým službam, budou představeny základní přístupy pro pops webových služeb, včetně jejch klíčových parametrů umožňující záps choreografe a orchestrace. Na základě získaných poznatků a přehledu přístupů k dané problematce bude sestaven formální pops procesního dagramu. Dále budou aplkovány přístupy z teore konečných automatů tak, aby tento pops plně reflektoval potřeby vyplývající z grafcké podoby procesních dagramu v BORM. Dále budou popsány možnost zachycení choreografe procesů v BORM a bude navrženo rozšíření této metody tak, aby bylo možné choreograf lépe a efektvněj modelovat. Na základě komparace vybraných jazyků pro pops webových služeb s jazykem používaným pro pops procesů v nástroj IZMAN Case budou defnována jeho slabá místa tohoto jazyka s ohledem na záps orchestrace a choreografe. Bude-l to nezbytné, bude navrženo jeho rozšíření, tak aby tento byl srovnatelný s jazyky běžně k obdobnému účelu používaným. 10

11 Vybrané nástroje pro modelování procesů, orchestrace a choreografe 4 Vybrané nástroje pro modelování procesů, orchestrace a choreografe Podíváme-l se hluboko do hstore, setkáme se s procesy v každé etapě ldského vývoje. Od jeskyních ldí, stavtelů pyramd přes období renesance, jehož výrazným představtelem je Leonardo da Vnc, až do dnešní moderní doby se ldé vždy potýkal s nutností vykonávat určté čnnost(procesy) přčemž s uvědomoval, že v rámc konkrétního procesu zosobňují určtou rol. Velké osobnost často předběhl svoj dobu a jelkož mez jejch současníky nebyl nkdo, kdo by byl schopen uvažovaní na stejné úrovn jako on, zastával často dvojjedné role. Vezměme například jž zmňovaného Leonarda da Vnc, který byl nejen vynálezcem, ale také konstruktérem. Ačkol bychom našl mnoho zástupců výjmečných osobností, které byly schopny zastávat více rolí, většna ldí není schopna takové komplexnost. V ldských slách, ať už mentálních nebo fyzckých, není možné pojmout veškeré potřebné vědění č um pro řešení komplexního problému a je proto nezbytná specalzace. Velká složtost problému je často těžko uchoptelná a nad možnost naší mentální kapacty. Jak se tedy vypořádat s problémem, který je jako celek nad možnost chápání jedné osoby? Jako logcké se jeví rozdělt složtý problém na více méně složtých problémů. Komplexním problémem je z našeho pohledu návrh a mplementace nformačního systému. Archtektura budov je dobrou paralelou k budování nformačních systémů. Obdobně jako archtekt přenese svoj vz stavby do podoby plánů a výkresů, přenáší archtekt nformačních systémů požadavky užvatelů do podoby procesních dagramů a datových modelů. Stejně jako v případě stavtelů, kdy jeden člověk dokázal stavbu nejen navrhnout, ale také postavt nebylo v mnulost výjmkou, že jeden člověk nejen navrhoval ale také mplementoval nformační systém. Jak se postupně prohlubovaly znalost ldí v oblast statky a nauky o matrálech, oddělla se role archtekta a stavtele. Archtekt navrhuje stavbu tak, aby co nejlépe vyhovovala potřebám užvatele. Naprot tomu stavtel realzuje záměry archtekta přčemž musí zajstt, aby výsledek splňoval kvaltatvní požadavky, ale také cenu, kterou s stanovl užvatel a ze které př návrhu vycházel archtekt. Podobně jako v případě stavby budov se také v případě budování nformačních systémů vyhranl dvě profese. Návrhář archtektury nformačního sytému a ten, kdo bude tento návrh mplantovat by měl vzájemně spolupracovat stejně jako archtekt a stavtel. Jak uvádí (Polák, a další, 2003) dochází v případě realzace nformačních systémů mnohem 11

12 Vybrané nástroje pro modelování procesů, orchestrace a choreografe častěj k zásadním změnám projektu než u výstavby budov. Důvodem bývá špatná archtektura nebo lépe řečeno návrh nformačního systému, který neodpovídá požadavkům užvatele. Počítače jž dávno nejsou nástrojem několka vyvolených, kteří byl nucen naplno a velm pečlvě využívat jejch velm omezené prostředky. Rozvoj nformačních technologí znamenal také rozvoj nástrojů a technk pro tvorbu nformačních systémů. Přestože exstuje mnoho CASE nástrojů, které usnadňují návrh nformačních systémů, jde pouze o nástroje. Bez potřebných znalostí není možné an se sebelepším CASE nástrojem vybudovat systém, který by odpovídal požadavkům užvatele (Shlaer a Mellor, 1992). Ncméně an dokonalé znalost a zvládnutí práce s CASE nástrojem nezaručují dobrý výsledek. Klíčovým problémem je pochopení, jaký má výsledný systém být a co je pro jeho užvatele důležté. Je zapotřebí pochopt problém užvatele, pochopt jeho procesy a vytvořt most mez užvatelem a realzátorem nformačního sytému (Polák, a další, 2003). Úkolem archtektů nformačních systémů je překlenout mezeru mez světem užvatelů a světem těch, kteří budou systém realzovat. Archtekt nformačních systémů využívají pro převedení užvatelského pohledu na problém do podoby pochoptelné pro realzátory metody a pracovní postupy, jejchž vybraným zástupc se v této prác budeme zabývat. Na pomezí archtekta a realzátora nformačního systému stojí systémový ntegrátor. Je zde celá řada defnc pojmu systémový ntegrátor. Podle šetření, které provedla Česká společnost pro systémovou ntegrac (Habáň a Sodomka, 2004) je systémový ntegrátor společnost, která má přímý vztah k zákazníkům a je vždy spoluřeštelem IS/IT projektů u zákaznckých organzací. Podle Poláka (Polák, a další, 2003) je systémový ntegrátor osoba nebo frma, která umí účelně vyhledat, provázat a propojt jednotlvé komponenty nformačního systému do jednoho celku tak, aby uspokojl potřeby užvatele a podpořl jeho procesy. Systémový ntegrátor by tedy měl zastat rol archtekta a navrhnout podobu budoucího nformačního systému. Dále by měl být schopen tento svůj návrh realzovat buď za použtí jž hotových komponent a stávajících částí nformačního systému, a nebo vytvořením komponent nových. V osmdesátých letech dvacátého století byl kladen značný důraz na TQM (Total Qualty Management), což je flozofe řízení pro trvalé zvyšování kvalty produktů a procesů. Začátkem devadesátých let byla tato flozofe následována BPR (Busness Process Rengeneerng), který měl bohatou hstor s mnoha velkým úspěchy a pochoptelně neúspěchy. BPR se zabývá analýzou, návrhem a přepracováním pracovních postupů a procesů v rámc organzace za účelem zvýšení jejch efektvty (Jeston a Nels, 2008). 12

13 Vybrané nástroje pro modelování procesů, orchestrace a choreografe Počátkem jednadvacátého století se objevl nový směr, který vychází z myšlenky BPR. Busness Process Management (BPM) zahrnuje metody, technky a nástroje pro podporu návrhu, řízení a analýzu obchodních procesů (van der Aalst, a další, 2003). Někteří autoř jako (Jeston a Nels, 2008), nepředkládají konkrétní defnc BPM, ale popsují ho jako nterdscplnární přístup zahrnující nformační technologe a management, jehož předmětem zájmu jsou organzace, ldé a nformační technologe tvořící obchodní procesy. Podobně jako v případě BPR je cílem nejen procesy řídt, ale měřt a případně zvyšovat jejch efektvtu. Obchodní proces 1, nebo též podnkový proces, někdy také označovaný jako obchodní případ, vymezuje (Ould, 2005) jako ucelenou množnu aktvt, které jsou vykonávány vzájemně spolupracujícím účastníky za účelem dosažení určtého cíle. Obdobným způsobem vymezují pojem obchodního procesu (Smth a Fngar, 2007), kteří uvádějí, že obchodní proces je ucelená a dynamcky koordnovaná množna spolupracujících a transakčně provázaných aktvt, které přnášejí hodnotu pro zákazníky. Obecně lze tedy říc, že obchodní proces je posloupnost vzájemně propojených aktvt a stavů mající výchozí a konečný stav. Výsledkem procesu je přdaná hodnota pro zákazníka procesu. Během vykonávání procesu dochází k transformac vstupní nformace na nformac výstupní. Modely obchodních procesů by měly mít formální základ, protože formální modely umožňují problém jednoznačně popsat a lépe analyzovat. Procesní model by měl být pochoptelný pro všechny zúčastněné strany, což by mělo být dosaženo přehlednou grafckou reprezentací procesu. Vlastníc, účastníc, vývojář analytc by měl být schopn procesnímu modelu přřadt stejný, jednoznačný význam, který neumožňuje alternatvní výklad (Jeston a Nels, 2008). 4.1 Technky modelování obchodních procesů Ačkol exstuje celá řada rozšířených méně používaných přístupů a technk pro modelování obchodních procesů, budeme se zabývat pouze vybraným zástupc. Následující přehled nejpoužívanějších technk a přístupů pro modelování obchodních procesů předkládá (Gagls, 2001). Flowchartng. Flowchartng, nebo též vývojové dagramy, jsou jednou z prvních modelovacích technk, která vznkla v šedesátých letech dvacátého století. Výhody vývojových dagramů spočívají ve schopnost ukázat celkovou strukturu procesu, sledovat toky nformací, popsovat méda, na kterých jsou nformace 1 Označení obchodní proces je překladem anglckého názvu Busness Process, lze se také setkat s označením podnkový proces nebo obchodní případ 13

14 Vybrané nástroje pro modelování procesů, orchestrace a choreografe předávány, a ve schopnost zobrazt klíčová místa a rozhodovací body procesu. Původně byly vývojové dagramy používány pro zobrazení algortmů a logky počítačových programů, ale vzhledem k jejch obecné povaze je lze aplkovat na další oblast včetně modelování obchodních procesů. Jedná se spíše o doplňkovou technku pro pops procesu. Petrho sítě. Petrho sítě se nejčastěj používají pro modelování a synchronzac paralelních výpočtů nebo modelování výrobních procesů (montážní lnky, apod.). Jejch použtí se neomezuje pouze na aplkace v techncké oblast. V posledních letech se také používají k popsu, analýze, smulac a modelování obchodních procesů (Grault a Valk, 2003). Petrho síť je orentovaný, ohodnocený, bparttní graf, který se skládá z míst, přechodů a hran. Základní Petrho sítě jsou matematcko-grafcké reprezentace procesů, zaměřené na podporu analýzy struktury a dynamky chování zejména paralelních systémů. Teore automatů. Základy teore automatů položl McCuloch a Pttsov, kteří roku 1943 navrhl model abstraktního zařízení s konečným počtem dosažtelných stavů. Jedním z nejstarších a nejznámějších způsobů modelování chování systémů uvádějí (Gll, 1962) a (Wrght, 2005) stavové automaty. Konečné automaty dovolují zachytt a popsat stav systému nebo procesu v konkrétním místě a čase. Chování celého systému je možné odvodt na základě jeho stavů. Použtí této technky není omezeno volbou konkrétního modelovacího nástroje a je nezávslé na mplementac. Jelkož je hlavním cílem této práce popsat procesní dagramy v BORM pomocí teore konečných automatů, bude této problematce věnována samostatná kaptola. Data flow dagramy (DFD). DFD jsou technkou pro grafcký záznam datových toků mez externím enttam, nterním kroky zpracování a data-store elementy v rámc obchodního procesu. DFD se používají pro pops systému se zaměřením na toky dat do systému, v rámc systému a vně systému. V tomto ohledu jsou DFD srovnatelné s vývojovým dagramy. Lší se od nch v podstatě pouze v zaměření. DFD se zaměřují na data, zatímco vývojové dagramy na aktvty a kontrolu řízení. DFD byly šroce používány pro datové modelování a staly se standardní notací pro analýzu a návrh systémů, ncméně mají řadu omezení. DFD se převážně zaměřují na data a neposkytují žádné konstrukty pro pops work flow, ldí, událostí a dalších prvků, z nch se podnkové procesy skládají. Nedefnují počáteční an koncové body procesu. Jedná se o statckou reprezentac funkconalt systému, která zahrnuje manpulac s daty. Z toho důvodu je obtížné jejch použtí pro analýzu nebo rozhodování o řízení. 14

15 Vybrané nástroje pro modelování procesů, orchestrace a choreografe State-transton transton dagramy (STD). State-transton dagramy vycházejí z analýzy a návrhu systémů zpracovávajících úlohy v reálném čase. ST dagramy se pokoušejí překonat omezení vyplývající ze statckého charakteru DFD tím, že poskytují explctní nformace o časovém sledu událostí. Notace state-transton dagramů je velm jednoduchá. Skládá se pouze z obdélníků, které představují stavy, a špek, které představují změny stavů (přechody). Ačkol se podařlo ST dagramům překonat některá omezení data flow dagramů, stále se soustřeďují prmárně na data a opomíjí work flow, řízení, rozhodování a další. Unfed Modellng Language (UML). V roce 1997 přjala OMG (Object management Group) jazyk UML jako standard pro specfkac, konstrukc, vzualzac a dokumentac softwarových systémů. UML využívá šrokou škálu dagramů zahrnujících: Use Case dagramy pro zobrazení struktury systému z pohledu užvatele. Class dagramy pro zachycení statckého pohledu na systém, znázornění objektů v systému a jejch vztahů. Dagramy po pops chování, což jsou jž zmňovaný Use Case dagram, dále statechart, actvty, state machne a nteracton dagramy. Dagramy po pops struktury, mez něž patří například Class dagramy, Component dagramy a další. Navzdory velkému množství dlouho exstujících jazyků a prostředků pro pops softwaru, většna z nch je spjata s konkrétním způsoby analýzy a návrhu. Tato zdánlvá rozmantost může být zdrojem problémů nteroperablty mez jazyky. UML se snaží tuto mezeru zaplnt svou unverzálností, tedy tím, že pokrývá celý proces návrhu od modelů obchodních procesů až po databázové schéma a softwarové komponenty. V rámc této práce se budeme nadále věnovat pouze notac BPMN a metodě BORM. 4.2 Busness Process Modelng Notaton Během několka posledních let došlo ke značnému rozvoj vykonávacích jazyků založených na XML pro řízení podnkových procesů. Jazyky jako BPEL4WS poskytují formální nástroj pro defnc obchodních procesů. Klíčovým prvkem těchto jazyků je to, že jsou optmalzovány pro zajštění provozu a spolupráce BPM systémů, následkem čehož jsou tyto jazyky méně vhodné pro přímé použtí návrhář procesů. Vzhledem k povaze jazyků, jako je BPEL4WS, je možné zaznamenat proces sce potencálně komplexní, ale v nesouvslém a nentutvním formátu. Pro programátory a nformační systémy je srozumtelný, ale je těžko pochoptelný pro procesní analytky a manažery, kteří mají za úkol proces 15

16 Vybrané nástroje pro modelování procesů, orchestrace a choreografe modelovat, sledovat a řídt. Pro manažery a analytky je pohodlné a jednodušší zaznamenat proces grafcky, pomocí vývojových č flow-chart dagramů. Rozdíl mez způsobem počátečního návrhu podnkových procesů a jazyky, jako BPEL4WS, používaných pro vykonávání procesů, tvoří mezeru, kterou je třeba překlenout. Mezera musí být odstraněna pomocí formálního mechanzmu, který umožní mapovat grafcký záps procesu na odpovídající BPM vykonávací jazyk. BPMN dovoluje také mapovat dagramy na vykonávací jazyky, jako BPEL4WS, čímž poskytuje standardní mechanzmus pro vzualzac procesů defnovaných ve vykonávacím jazyce. Rozšřuje možnost tradčních notací pro záps obchodních procesů o možnost modelovat komplexní B2B procesy, tedy veřejné a soukromé procesy a choreografe. Dále dovoluje defnovat způsoby zpracování výjmek, transakce a kompenzace výpadků komunkace. Jedním z důvodů pro vývoj BPMN bylo vytvoření mechanzmu pro tvorbu modelů podnkových procesů, který bude na jedné straně jednoduchý a srozumtelný a na straně druhé bude schopen zachytt velm složté procesy. Splnění těchto, do značné míry protchůdných, požadavků bylo dosaženo rozčleněním grafckých prvků, z nchž se proces skládá, do pět základních kategorí. Malá množna základních grafckých prvků dovoluje vlastníkům a účastníkům procesu proces snadno pochopt a dobře se v něm orentovat. Základní kategore obsahují další, jž specfcké grafcké prvky daného druhu, které dovolují vytvářet detalnější modely procesů. Jelkož grafcké prvky v dané kategor vycházejí ze stejného základu, nedochází př jejch použtí k výrazné změně grafcké podoby procesu a tedy an čtelnost a pochoptelnost ze strany vlastníků, účastníků a koncových užvatelů procesu není omezena. Specfkace BPMN (OMG BPMN, 2011) uvádí těchto pět základních kategorí grafckých prvků procesu: Tokové objekty Data Spojovací objekty Dráhy (Swmlanes) Artefakty 16

17 Vybrané nástroje pro modelování procesů, orchestrace a choreografe Obr Základní grafcké elementy notace BPMN vlastní zpracování autora podle (OMG BPMN, 2011) Tokové objekty Základní grafcké prvky, které defnují chování obchodního procesu, jsou tokové objekty. Jednotlvé tokové objekty lze navzájem propojt pomocí spojovacích objektů. Rozlšujeme tř druhy tokových objektů událost, aktvty a gateways, nebol brány. Událost. Událost, jak j defnuje například (Chandy, 2006), je významná změna stavu. Čstě ntutvně lze za událost považovat cokol, co se stane v průběhu procesu nebo choreografe. Událost mají vlv na tok uvntř modelu procesu. Obvykle označují nějakou příčnu nebo důsledek. Zakreslujeme je symbolem kružnce. Pomocí doplnění značek uvntř symbolu rozlšujeme rozdílné příčny (spouštěče) a výsledky událostí. Exstují tř základní typy událostí start, průběžná událost a konec. Rozlšujeme je podle toho, ve kterém okamžku průběhu procesu ovlvňují jeho tok. Událost typu start defnuje místo, kde má proces nebo choreografe počátek. V případě sekvence toků tímto elementem začíná tok procesu, 17

18 Vybrané nástroje pro modelování procesů, orchestrace a choreografe z toho důvodu mu nemůže předcházet jná událost. Událost typu start, podobně jako průběžná událost, může mít defnovány specfcké okolnost (spouštěče), za kterých je proces zahájen. Symbol kružnce bez doplňujících značek uvntř se používá k určení počátku procesu nebo choreografe, kde není příčna zahájení jasně defnována. Průběžné událost se mohou vyskytovat mez začátkem a koncem procesu. Mají vlv na tok procesu nebo choreografe, ale nemohou proces spustt nebo ukončt. Průběžné událost se používají pro sledování a kompenzac chyb a výjmek. Dále pak defnují místa v procesu, kde očekáváme příjem zpráv nebo kde dochází k odesílání zpráv. Mohou též pokrývat případy očekávaných zpoždění v rámc procesu. Událost mohou být součástí běžného toku procesu, ale lze je také přpojt k aktvtě, kde defnují událost, př jejímž výskytu dojde k realzac nebo přerušení aktvty. Událost typu konec defnuje místo kde je proces nebo choreografe ukončena. Podobně jako ostatní typy událostí, mohu zde nastat specfcké okolnost, analogcké k událostem spouštějícím událost typu start, za kterých je proces ukončen. Aktvty. Aktvta je obecný pojem pro prác, která je prováděna v rámc procesu. Aktvty mohou být atomcké úlohy, nebo složené podprocesy. Aktvty reprezentují místa v procesu, kde se provádí práce. Úloha je atomcká aktvta uvntř procesu. Úloha se používá v případě, kdy není nutné nebo možné aktvu modelovat detalněj. Úloha v choreograf je opět atomcká aktvta uvntř choreografe. Reprezentuje množnu jedné nebo více výměn zpráv. Každá úloha se skládá ze dvou účastníků. Podproces je složená aktvta, která je součástí procesu nebo choreografe. Obvykle se v dagramu vyskytuje ve sbalené podobě, která neumožňuje zobrazt podrobnost o dílčím procesu uvntř. Sbalený podproces je možné rozbalt a zobrazt tak detalní pohled na dílčí proces. Veškeré sekvenční toky dílčího procesu musí být umístěny uvntř symbolu pro podproces. Vnořená choreografe (Sub-Choreography) vychází ze stejných prncpů jako podproces, pouze se lší grafckým symbolem. Brány. Brány se používají pro řízení, rozdělování a slučování sekvenčního toku v procesech nebo choreografích. Všechny typy bran mohou tok jak rozdělovat, tak slučovat, a jsou značeny shodně symbolem prázdného kosočtverce. Pomocí vntřních symbolů se specfkuje jejch chování. 18

19 Vybrané nástroje pro modelování procesů, orchestrace a choreografe Vylučovací brány umožňují větvt tok procesu na základě rozhodnutí založeného buď na datech, nebo na událostech. Vylučovací brány jsou křžovatkam uvntř procesu, ze kterých mohou vést dvě více cest, z nchž může být vybrána právě jedna, po které bude tok procesu pokračovat. o Nejčastěj používaným druhem brány je vylučovací brána založená na datech. Rozhodování probíhá na základě splnění podmínky, která je formulována jako "běžná otázka", která má předem taxatvně určenou množnu možných odpovědí, reprezentující jednotlvé větve procesu. o Vylučovací brány založené na událostech představují body v procesu, kde dochází k jeho větvení na základě událostí, které nastanou právě v tomto bodě. Událost, na jejchž základě se rozhodne (obvykle přjetí zprávy), jsou místěny za branou na jednotlvých větvích toku. První událost, která je aktvována, určuje větev, kterou bude proces dále pokračovat. Paralelní brány se používají k vytváření a synchronzac paralelních toků. Symbol paralelní brány se lší od vylučovacích bran a na rozdíl od nch musí vždy symbol kosočtverce obsahovat doplňkovou značku "+", aby byl odlštelný od ostatních druhů bran. Př použtí tohoto typu brány dojde vždy k rozdělení toku na více cest, anž by musely být splněny nějaké předem stanovené podmínky. Př použtí brány pro synchronzac více paralelních toků brána vždy čeká, dokud nepřjme všechny vstupní toky, a až poté spouští toky na svém výstupu Data Pro modelování dat v rámc toku procesu se prmárně používají datové objekty. Datové objekty poskytují nformace o tom, co aktvty vyžadují pro své vykonávání a jaká data produkují. Žvotní cyklus datových objektů je vázán na žvotní cyklus procesu nebo subprocesu, ve kterém je obsažen Spojovací objekty Exstují čtyř základní způsoby jak propojovat tokové objekty navzájem nebo s některým ostatním prvky. Rozlšujeme čtyř druhy spojovacích objektů: sekvenční toky, toky zpráv, asocace a datové asocace. Sekvenční toky. Určují pořadí, v jakém budou jednotlvé tokové objekty v rámc procesu nebo choreografe vykonávány. Každý sekvenční tok má právě jeden zdroj a právě jeden cíl a nemůže překračovat hrance podprocesu nebo bazénu. 19

20 Vybrané nástroje pro modelování procesů, orchestrace a choreografe Muže mít defnovanou podmínku, př jejímž splnění bude proces pokračovat právě touto větví. Podmínky se většnou využívají v případech, kdy je zdrojem sekvenčního toku brána nebo aktvta. Toky zpráv. Používají se k zobrazení toku zpráv mez dvěma účastníky procesu, kteří jsou přpraven zprávy odesílat a přjímat. Každý účastník procesu je zobrazen jako samostatný bazén. Toky zpráv se mohou dotýkat hranc bazénů nebo jsou napojeny na tokové objekty uvntř bazénu. Nemohou však spojovat dva tokové objekty v rámc jednoho bazénu. Asocace. Používá se k propojení nformací a artefaktů s ostatním elementy, nejčastěj textovým popsy. Datové asocace. Datové asocace se využívají pro přesun dat mez datovým objekty a vstupy a výstupy aktvt a procesů. Účelem získávání dat z datových objektů a procesních datových vstupů je naplnt vstupy aktvt a pozděj po provedení aktvty vrátt výsledné výstupní hodnoty zpět do datových objektů nebo procesních datových výstupů Dráhy Bazén. Účastníc procesů jsou v BPMN reprezentován bazény. Na bazén takém můžeme pohlížet také jako na dráhu, která odděluje množnu čnností od ostatních bazénů, což se obvykle vyskytuje v případě modelování B2B procesů. Bazén může obsahovat procesy, ale může také zůstat prázdný a vystupovat jako černá skříňka, u které známe pouze vstupy a výstupy. Účastník procesu může zastávat obecnější rol (výrobce, prodávající, kupující) nebo jím může být konkrétní subjekt č osoba (společnost, účetní, ředtel). Interakce mez bazény zajšťují tokové zprávy, které nelze použít pro nterakce uvntř bazénu. Vntřní nterakce jsou zajšťovány pomocí sekvenčních toků, které ale nelze použít pro vnější nterakce. Dráha. Dráhy rozdělují bazén na menší část, z nchž každá může představovat nějakou dílčí rol v rámc organzace. Uvažujeme-l bazén jako jeden proces, lze pomocí drah kategorzovat a organzovat jednotlvé aktvty. Na rozdíl od bazénu mohou sekvenční toky přecházet přes hrance drah Artefakty Artefakty se používají pro doplnění nformací o procesu, které buď nebylo možné zahrnout do procesu, nebo které slouží k lepšímu pochopení modelované problematky. BPMN defnuje dva standardzované artefakty Group nebol Skupna a Text annotaton, tedy textový pops. Návrhářům procesů a tvůrcům 20

21 Vybrané nástroje pro modelování procesů, orchestrace a choreografe modelovacích nástrojů je dovoleno defnovat další artefakty podle potřeby. Nesmějí však být v konflktu s prvky, které jsou jž v notac defnovány. Skupna. Skupnu tvoří množna grafckých prvků, které jsou ve stejné kategor. Tento typ seskupování prvků nemá vlv na sekvenční toky uvntř skupny. Kategore, jejchž sémantka je defnované užvatelem, lze využít pro dokumentac nebo k analytckým účelům. Textový pops. Textové popsy slouží návrhářům procesů pro doplnění dagramů o nformace užtečné a podstatné pro jejch užvatele. 4.3 Busness Object Relaton Modelng První práce popsující možnost sloučení objektově orentovaného přístupu a popsu objektů a jejch chování pomocí konečných automatů, byla knha autorů Shlaerové a Mellora (Shlaer a Mellor, 1992). Výhody, možnost a postupy použtí objektově orentovaného přístupu pro modelování obchodních procesů popsuje Taylor (Taylor, 1995), který podrobně rozebírá základní prncpy objektového přístupu v kontextu obchodních procesů. Možnost využít objektově orentovaného přístupu pro pops obchodních procesů, někdy též označovaných jako podnkové procesy, jak j popsuje Taylor (Taylor, 1995) spolu s prací Shlaerové a Mellora (Shlaer a Mellor, 1992), poskytly teoretcký a konceptuální rámec pro vznk metody BORM (Knott, a další, 2006). Metoda BORM byla vyvíjena postupně od roku Původním záměrem bylo vytvořt metodku orentovanou na podporu tvorby objektově orentovaných softwarových systémů založených na čstých objektově orentovaných programovacích jazycích a nerelačních objektových databázích. V průběhu vývoje bylo zjštěno, že je možné využít některé defnované technky pro modelování procesů obecně. BORM pokrývá všechny fáze vývoje softwaru a je ho možné využít nejen př tvorbě softwaru, ale k analýze požadavků na projektovaný systém a na modelování obchodních procesů. Od roku 1996 je další vývoj podporován frmou Delotte&Touche Czech Republc and Central Europe, kde je tato metoda také používána. Pro metodu BORM jsou podle (Merunka, 2008) charakterstcké následující vlastnost: BORM je navržen jako metoda, která pokrývá všechny fáze vývoje softwaru. Velká pozornost je v BORMu věnována úvodním fázím projektu a postupům, jak najít objekty v zadaném problému a zkontrolovat jejch správnost. Technky z těchto fází BORMu lze používat samostatně pro modelování procesů takových systémů, které nemají přímý vztah k tvorbě softwaru. Jným slovy lze BORM použít pro mapování procesů problémové 21

22 Vybrané nástroje pro modelování procesů, orchestrace a choreografe domény, jejch případnou optmalzac a tím rozpoznat a případně zvýšt CMMI (Capablty Maturty Model Integraton) procesu, anž by výsledek vyústl v konkrétní softwarovou mplementac, která bude procesy podporovat. BORM pro každou jednotlvou fází žvotního cyklu využívá v dagramech jen omezenou sadu pojmů. Předpokládá se totž, že během projektování dochází k postupným přeměnám pojmů na jné. Například ve fáz analýzy se nepoužívají pojmy jako agregace, jednoduchá č vícenásobná dědčnost, protože tyto pojmy jsou relevantní až pro mplementac. Naopak pojmy jako stav, přechod č asocace jsou používány během analýzy, ale ve fáz mplementace, kdy se snažíme model přzpůsobt cílovému mplementačnímu prostředí, se s nm jž nepracuje. Nejde jen o postupné zvyšování úrovně detalu ve vytvářeném modelu, ale skutečně o řadu transformací modelu v průběhu žvotního cyklu. V BORMu je každý pojem reprezentován shodným symboly bez ohledu na to, jestl se jedná např. o dagramy datové struktury nebo komunkac mez objekty. BORM používá pro znázorňování konceptuálních a softwarových pojmů většnu symbolů shodně s jazykem UML, ale dovoluje v jednom dagramu znázornt například posílání zpráv mez metodam různých objektů v různých stavech. Tento přístup dovoluje vyjádřt konzstentním způsobem některé žádoucí detaly softwarové konstrukce, které lze výhodně aplkovat především př návrhu pro čstě objektově orentované programovací jazyky. Tento orgnální způsob nahrazuje tvorbu více od sebe oddělených třídních, stavových a kolaboračních dagramů a také dovoluje zobrazt větší množství spolu souvsejících nformací. Samostatné stavové č nterakční dagramy jsou však samozřejmě v BORMu také používány. Př řešení projektu podle zásad metody BORM lze rozlšt dvě hlavní fáze: fáz expanze a fáz konsoldace. Fáze expanze začíná analýzou modelu obchodních objektů. Dochází zde ke hromadění nformací potřebných pro vytvoření aplkace. Stadum expanze končí s dokončením analytckého konceptuálního modelu, který na logcké úrovn reprezentuje požadované zadání a v abstraktní podobě popsuje jeho řešení. Fáze konsoldace, tedy fáze od konceptuálního modelu až k fnálnímu systému složenému ze softwarových objektů, se označují jako stadum konsoldace. Je tomu tak proto, že v těchto etapách se model, který je produktem předchozí expanze, postupně stává fungujícím programem. To znamená, že na nějakou myšlenkovou expanz zadání zde jž není prostor an čas. V tomto stadu se také počítá s tím, že od některých dejí z expanzního stada bude třeba 22

23 Vybrané nástroje pro modelování procesů, orchestrace a choreografe upustt vzhledem k časovým, kapactním, mplementačním nebo ntelektuálním schopnostem odtud tedy název tohoto stada. (Takto odstraněná nformace však může být v budoucnu základem analýzy nové verze systému.) Umění rozlšt a vyváženě řídt expanz a konsoldac je klíčovým faktorem úspěchu softwarových projektů. Samotný teratvní model totž nezkušeného manažera může dovést k neúměrnému počtu terací s dlouhým expanzem. Konsoldace se potom odbývá a výsledný produkt nemá potřebnou kvaltu (Merunka, 2008). Metoda BORM má podle (Knott, a další, 2006) následující výhody: BORM je založen na předpokladu, že každému vývoj softwarového systému musí předcházet modelování obchodních procesů, jejchž vykonávání má vyvíjený systém podporovat. Díky tomu poskytuje BORM konzstentní přístup a notac pro analýzu a návrh podnkového prostředí, které zdrojem požadavků na systém a dále poskytuje nástroj pro analýzu a návrh softwaru. BORM navazuje na procesně orentovaný přístup v kombnac s čstě objektově orentovaným paradgmatem, který se ukázal být výhodný pro vývoj softwaru. Procesně orentovaný přístup vede ke komplexnější a rychlejší a analýze př řešení problému. Koncoví užvatelé, nebo obecně účastněné strany problémové domény, jsou schopn velm rychle pochopt přístup a dagramy používané v BORM. Podle zkušeností z Delotte & Touche je analytcká fáze projektu v BORM, v porovnání s ARIS, přblžně třkrát až čtyřkrát rychlejší. Metodka je snadno pochoptelná pro analytky vývojáře, protože je založená postupné transformac modelu, přčemž v každé fáz se pracuje pouze s omezenou podmnožnou pojmů. BORM vychází z čstě objektového konceptu, a proto dovoluje použít více druhů herarche objektů, než ostatní metody vývoje softwaru. BORM pracuje se vztahy mez objekty, které nemají přímou mplementac v běžných programovacích jazycích, ale jsou užtečné pro konceptuální modelování Rozšíření BORM Na prác Shlaerové a Mellora (Shlaer a Mellor, 1992), která byla zmňována v souvslost s původní koncepcí metody BORM, navazuje Merunka (Merunka, 2012), který popsuje objektově orentovaný přístup k modelování procesů, založený na fundamentálních prncpech konečných automatů. Základním 23

24 Vybrané nástroje pro modelování procesů, orchestrace a choreografe kamenem je stále metoda BORM, ale namísto procesních dagramů, využívajících prvky defnované v rámc této metody, byl použt jazyk UML, rozšířený o nový druh vztahu. Autoř obou uváděných prací (Shlaer a Mellor, 1992) a (Taylor, 1995) se shodují, že př tvorbě procesního modelu je důležté nejprve dentfkovat stavy, ve kterých se jednotlví partcpant 1 nacházejí. Následně je možné dentfkovat chování, respektve aktvty, které je nutné vykonat proto, aby partcpant přešel z aktuálního stavu do stavu nového. Procesní dagramy v BORM mohou obsahovat komunkace mez aktvtam. Aby bylo možné použít prvky jazyka UML, bylo nutné defnovat nový druh vztahu (komunkace), což UML umožňuje. Tento nový druh vztahu je analogcký s datovým spojením a je ho možné považovat za obecné předávání zpráv, které se používá v dynamckých modelech UML. Nový přístup k dagramům v BORM využívá pro reprezentac procesních modelů prvky UML, čímž sjednocuje objektové modely UML a technky modelování obchodních procesů, jak je známe z BORM. Nespornou výhodou nového přístupu je relatvně snadná transformace takto získaných modelů do jazyka UML nebo procesních modelů v BPMN (Merunka, 2012). Obr UML podoba procesních dagramů BORM vlastní zpracování autora podle (Merunka, 2012) Možné výhody nového přístupu s využtím prvků UML, jak je uvádí (Merunka, 2012): Oprot dagramům v BORM, reprezentovaných pomocí výše zmňované podoby jazyka UML, pokrývají BPMN a UML pouze část celého 1 Partcpanty jsou v celé prác myšlen jak externí tak nterní účastníc procesů. Defnce pratcpanta z pohledu BORM je uvedena v kaptole

25 Vybrané nástroje pro modelování procesů, orchestrace a choreografe využtelného prostoru, který umožňuje objektově orentovaný přístup modelování. Nejdůležtějším pojmy jsou stavy objektů. Aktvty představují "pouze" způsob, jak přejít z jednoho stavu do stavu jného. Př tvorbě procesních modelů nebo návrhu softwarových komponent by se mělo začínat dentfkací stavů, v nchž se jednotlví partcpant v průběhu času mohou nacházet. Modelování procesů pak může být jednodušší, přesnější a méně závslé na chování partcpantů. Nový způsob reprezentace modelů také naznačuje zajímavé koncepční rozdíly mez skládáním (kompozcí) a asocací. Kompozce představuje podrobnější pohled na stejný objekt, zatímco asocace představuje vztah mez dvěma různým objekty. Toto rozlšení pojmů je velm cenné zejména proto, že jsou tyto dva pojmy často směšovány a zaměňovány. Zavedení nového druhu vztahu - komunkace, který je zobecněním zasílání zpráv, jak jej známe z objektově orentovaného přístupu k modelování. Komunkace je propojení mez aktvtam různých objektů. Stavy jednotlvých objektů mohou být také propojeny. Zavedený termín komunkace je symetrcký k termínu asocace a může mít též defnovanou kardnaltu. Asocace je nformace o vztahu mez dvěma objekty nebo jejch stavy, zatímco komunkace je analogcký vztah mez chováním (aktvtam) těchto objektů. Významný rozdíl mez pojmem asocace a skládání může pomoc vyřešt problém konceptuálního a technckého nesouladu v průběhu mplementace softwaru Analýza procesního modelu pomocí OBA Metoda OBA je teratvní technka sloužící k získávání strukturovaných podkladů ze zadání, nejčastěj na základě řízeného ntervew, pro potřeby konstrukce prvotního objektového modelu. Právě proto je velm vhodná pro nasazení v počáteční fáz tvorby nformačních systémů podle zásad metody BORM. Výstupy z OBA analýzy následně slouží ke konstrukc dagramů obchodních objektů. Metoda vnkla počátkem 90. let na základě zkušeností s aplkacem různých technk JAD (Jont Applcaton Desgn) a CRC (Class-Responsblty-Collaborator) pro potřeby objektové analýzy a návrhu a mplementace v objektově orentovaných programovacích jazycích (Merunka, 2012). Objektově orentovaná analýza se snaží modelovat stuac vyjádřenou jako množnu vzájemně nteragujících entt, kde má každá z entt jasně defnovanou 25

26 Vybrané nástroje pro modelování procesů, orchestrace a choreografe sadu chování a atrbutů (Shlaer a Mellor, 1992). Jak uvádí (Goldber a Rubn, 1995), exstuje mnoho přístupů s podobným konceptem, ale odlšnou termnologí. Jným slovy výsledky různých přístupů jsou velm podobné, ale lší se v postupu, kterým je konečného výsledku dosaženo. Obecně se začíná u slovního popsu modelovaného problému. Dále se dentfkují "hmotné" objekty, tedy v popsu problému se hledají podstatná jména, slovesa a přídavná jména. Na základě nalezených podstatných jmen se defnují objekty, od sloves se odvozují rozhraní pro zprávy a přídavná jména slouží pro odvození logky chování objektů. Následkem takového přístupu je slná preference "hmotných" objektů na úkor konceptuálních objektů, což může mít významný vlv na výsledek analýzy. Pro malé systémy může být tento základní přístup postačující, což ovšem neplatí pro velká řešení (Rubn a Goldberg, 1992). Použtí tohoto základního prncpu je podmíněno úplnou a formálně správnou specfkací problémové domény, která zvláště pro velké systémy není vždy k dspozc. Řešení nabízejí Rubn a Goldbergová (Rubn a Goldberg, 1992) v podobě OBA (Object Behavoral Analyss), která představuje efektvnější způsob, jak dentfkovat objekty ze slovního popsu problému. Na první místo kladou autoř pochopení toho, co se v systému děje, tedy na chování systému. Tato chování je dále nutné přřadt konkrétním částem systému a určt, kdo je ncuje a kdo se na nch podílí. Určení ncátorů a účastníků procesu napomáhá k pochopení různých rolí systému a určuje, které jeho část jsou odpovědné za poskytování služeb a řízení. Incátoř a účastníc, kteří mají významné role v rámc systému, jsou považován za objekty a je jm přřazena odpovědnost za chování odpovídající konkrétní část systému. Metoda OBA se podle (Goldber a Rubn, 1995) snaží určt: Jaké role a odpovědnost jsou nezbytné k vykonání určtého úkolu Proč určtý objekt exstuje Proč jsou jednotlvé objekty propojeny tak, jak jsou Jaké služby daný objekt poskytuje Jak se objekt podílí na plnění funkčních požadavků na systém Cílem OBA je v první řadě pochopt verbální pops problému a problém zapsat jako nterakce objektů. Tyto objekty plní systémové role tím, že s navzájem poskytují služby tak, aby naplnly požadavky na chování systému. Výsledek analýzy by měl být srozumtelný pro koncového užvatele a měl by sloužt jako podklad pro návrh konkrétní mplementace. Musí zde být jasná návaznost na cíle a záměry defnované v prvním kroku analýzy. 26

27 Vybrané nástroje pro modelování procesů, orchestrace a choreografe Autoř OBA (Rubn a Goldberg, 1992) uvádějí následujících pět kroků, ze kterých se metoda skládá: Stanovení kontextu pro analýzu. První krok spočívá v dentfkac cílů a záměrů, nalezení vhodných zdrojů pro analýzu, dentfkac klíčových oblastí a aktvt, a sestavení předběžného plánu průběhu analýzy. Jelkož se jedná o přípravnou fáz, která jde nad rámec analýzy samotné, lze j vynechat. ncméně poskytuje odrazový můstek pro další kroky. V průběhu prvního kroku může dojít k odhalení slabých míst v koncepc případně nekonzstence mez záměry a cíl, což může mít dopad na výsledek analýzy. Pochopení modelovaného problému na základě požadovaného chování. Druhým krokem je určt, jaké klíčové funkce by měl systém vykonávat, pro koho by je měl vykonávat a kdo by měl funkce vykonávat. Základem je vytvoření scénářů, které pokrývají všechny možné funkce systému. Někdy se tyto scénáře označují jako případy užtí (Use Cases). Obvykle se podklady pro sestavení scénářů získávají z ntervew s užvatel a odborníky na danou problémovou doménu. Scénáře popsují modelovaný proces jako posloupnost elementárních čnností, které na sebe navazují. Defnuje podmínky nutné pro realzac daného scénáře (precondton), účastníky (partcpanty) procesu, kteří se podílejí na realzac scénáře. Jako poslední prvek obsahují scénáře výsledky procesu (postcondton). Všechny uvedené prvky jsou zachyceny v textové podobě a uspořádané do tabulky. Výsledkem druhého kroku je pak sada scénářů, kde pro každý proces rozpoznaný v rámc ntervew je defnován vlastní scénář. Defnce objektů. Cílem třetího kroku je defnování objektů vykazujících chování, které přspívá k dokončení určtého úkolu. Každý partcpant nebo externí účastník procesu je potencálním objektem majícím specfcké vlastnost. Takový objekt může obsahovat data, poskytovat služby respektve vykonávat aktvty, které slouží k transformacím dat uvntř objektu a také k jeho komunkac s ostatním objekty. Pro zachycení vlastností objektu slouží upravená varanta CRC karet, které se v OBA nazývají Modelové karty. Výstupem třetího kroku je sada modelových karet, které pro daný objekt defnují jeho atrbuty, služby a spolupracující objekty. Klasfkace objektů a dentfkace vzájemných vazeb. Čtvrtý krok rozšřuje obsah modelových karet z předchozího kroku o blžší specfkac vzájemných vztahů jednotlvých objektů. Vzájemné vztahy jsou rozšířeny o případy, kdy objekt odešle jnému objektu zprávu za účelem získání nebo 27

28 Vybrané nástroje pro modelování procesů, orchestrace a choreografe předání nformací, případně s objekty předávají řízení procesu. Autoř metody OBA zavádějí následující tř reorganzační technky, které slouží k dentfkac služeb a logckých vlastností společných pro dva a více objektů: o Abstrakce Mají-l dva nebo více objektů defnované stejné služby nebo logcké vlastnost, vytvoříme nový objekt, kterému tyto vlastnost nebo služby přřadíme. Zároveň tyto vlastnost nebo služby od původních objektů odebereme. o Specalzace Specalzace se v mnohém podobá abstrakc. Postup je velm podobný. V případech kdy dva nebo více objektů poskytují stejné služby nebo mají stejné logcké vlastnost, tyto od původních objektů odejmeme a vytvoříme objekt nový, kterému tyto služby nebo logcké vlastnost přřadíme. Na rozdíl od abstrakce, v případě specalzace přřadíme původním objektům atrbut obsahující nově vytvořený objekt, kterému byly odejmuté vlastnost nebo služby přřazeny. o Faktorzace Každý účastník procesu, tedy objekt, který se účastní více scénářů a který poskytuje velký počet služeb, lze rozdělt na více objektů. Každému z nově vytvořených objektů pak přřadíme podmnožnu atrbutů nebo služeb původního objektu. Původní objekt pak můžeme vyřadt z množny objektů. Cílem je vytvořt z jednoho "unverzálního" objektu více specalzovaných objektů. Modelování dynamky systému. Předchozí kroky popsovaly strukturu systému statcky, tedy v jednom místě a čase. Poslední krok popsuje aspekty systému, které se v čase mění. Všechny dosud dentfkované a nově vytvořené objekty mohou měnt v čase svůj stav na základě událostí, které vykonávají. Pro každý objekt je defnována konečná množna stavů, ve kterých se v průběhu žvotního cyklu objekt může nacházet. Žvotní cyklus objektu vyjadřuje změny jeho stavu v průběhu času. Stavy jednotlvým objektům přdělujeme na základě scénářů, defnovaných v předchozích krocích. Pokud zjstíme, že je nutné přřadt danému objektu další stav, který nevyplývá ze scénářů, musíme se vrátt zpět ke kroku jedna a upravt konkrétní scénář. Dbáme na to, aby každý objekt byl v jednom okamžku pouze v jednom stavu. 28