BPMN I
Transkrypt
BPMN I
Modelowanie procesów biznesowych – BPMN cz. I 1 Literatura* • http://www.omg.org/spec/BPMN/2.0/ – witryna organizacji odpowiedzialnej m.in. za aktualną wersję BPMN • Bruce Silver: BPMN Method and Style • Thomas Allwayer: BPMN 2.0 • Marek Piotrowski: Notacja modelowania procesów biznesowych • Szymon Drejewicz: Zrozumieć BPMN • http://www.mgx.com.pl/pdf/BPMN2_0_Poster_PL.pdf *w prezentacji wykorzystano przykłady z wyżej wymienionych pozycji 2 • • • • • • • • • Literatura Wprowadzenie Bramki Zdarzenia Czynności Przepływy Pule i tory Obiekty Przykład 3 Reguły wyrazem strategii 1/4 Reguły wyrazem strategii 2/4 Reguły wyrazem strategii 3/4 Reguły wyrazem strategii 4/4 Standardy i organizacje standaryzujące • Workflow Management Coalision (WfMC) – model referencyjny – standardy składowania, wymiany definicji procesów oparte o XML (XPDL, WAPI, Wf-XML), – interoperacyjność • Business Process Management Initiative (BPMI) – Business Process Modeling Language (BPML) • Object Management Group (OMG) – Business Process Model and Notation (BPMN) 8 Troszeczkę historii… • 2001 – opracowanie BPML przez organizację BPMI • 2004 – przedłożenie BPMN do akceptacji przez OMG • 2006 – akceptacja BPMN przez OMG • 2011 – wersja 2.0 9 BPMN vs. diagramy czynności Diagramy czynności BPMN – projektowany dla „ludzi biznesu” – czytelny i zrozumiały dla czytelnika – duża liczba elementów – łatwość modelowania – projektowane dla informatyków – uniwersalność konstrukcji – minimalna liczba elementów – trudniejszy w modelowaniu 10 Poziomy modelowania w BPMN Model poglądowy ogólny zarys procesu biznesowego, bez szczegółów takich jak typy zadań, parametry bramek, obiektów danych, rozwiniętych podprocesów; służy po to, by szybko zorientować się z czym mamy do czynienia? Model analityczny Dodane szczegóły zadań, parametry bramek, wyspecyfikowane obiekty, uszczegółowiona komunikacja miedzy uczestnikami; służy m.in. do oceny rozmiaru prac koniecznych do wdrożenia Model wykonywalny precyzyjnie opisuje proces, zadania, wszystkie używane dane i konstrukcje oraz metody komunikacji; służy do wdrożenia na silniku procesów 11 • • • • • • • • • Literatura Wprowadzenie Bramki Zdarzenia Czynności Przepływy Pule i tory Obiekty Przykład 12 Bramki Służą do sterowania przebiegiem procesu Sterownie przepływem polega rozgałęzieniu procesu na ścieżki alternatywne, równoległe lub funkcjonujące według praktycznie dowolnej reguły oraz na łączeniu tych ścieżek Z każdej bramki może dochodzić wychodzić wiele przepływów sekwencji BPMN dopuszcza tzw. bramki zdarzeniowe (sterowane zdarzeniami) 13 Bramka XOR (decyzyjna, wykluczająca) Bramka XOR (decyzyjna) służy do wybrania tylko jednej z wielu ścieżek Wybór dokonywany jest na podstawie warunku Wybierana jest ścieżka dla której warunek jest prawdziwy Na projektancie leży obowiązek zadbania, żeby warunki nie zachodziły na siebie i pokrywały całą przestrzeń wartości Jest to najczęściej stosowana bramka Jej działanie odpowiada konstrukcji programistycznej if-then-else Bramka może posiadać ścieżki warunkowe i ścieżkę domyślną (wykonywaną wtedy, gdy żadna z alternatyw nie jest prawdziwa) 14 Bramka XOR - przykład Przepływ domyślny Bramka XOR • Jeśli zlecenie jest poprawne i kwota > 1000 zlecenie zostanie przekazane od BOK • Jeśli zlecenie zawiera błędy, zostanie odrzucone • W pozostałych przypadkach zlecenie będzie przetwarzane (przepływ domyślny) 15 Bramka równoległa • Bramka równoległa rozdziela proces na dwie lub więcej ścieżek wykonywanych równolegle • Każde z zadań na ścieżkach równoległych zostanie uruchomione • Równoległość w BPMN oznacza, że zadania mogą być wykonywane w tym samym czasie, głównie jednak chodzi o to, że zadania są wykonywane niezależnie od siebie • Bramka równoległa służy również do synchronizacji niezależnych przebiegów 16 Bramka Równoległa – przykład Podróż jest możliwa tylko wtedy, kiedy dokonamy rezerwacji samolotu i rezerwacji hotelu Obydwie czynności musza być wykonane, ich kolejność nie ma jednak znaczenia • Obydwa zadania będą wykonane (niezależnie) • Proces zakończy się tylko wtedy, gdy skończą się obydwa zadania 17 Bramka OR • Jako bramka rozdzielająca sprawdza warunki na każdej z wychodzących ścieżek i uruchamia te z nich na których warunek jest prawdziwy • Jeśli występuje ścieżka domyślna, wówczas jest ona uruchamiana tylko wtedy, gdy żadna z pozostałych nie została uruchomiona • Może funkcjonować jako bramka XOR lub równoległa (zależy od wyrażenia na ścieżkach wyjściowych) • Jako bramka scalająca działa „inteligentnie” i synchronizuje tylko te przebiegi, które zostały odpalone na odpowiadającej jej bramce rozdzielającej 18 Bramka Or – przykład Klient podjeżdża na stację benzynową celem zatankowania samochodu (obowiązkowe) W trakcie tankowanie może uzupełnić płyn do spryskiwacza, może też umyć szyby • Możliwe jest realizacja następujących zbiorów zadań: – Samochód jest tankowany – Samochód jest tankowany, szyby są myte – Samochód jest tankowany, płyn jest uzupełniany – Samochód jest tankowany, szyby są 19 myte, płyn jest uzupełniany Bramka złożona • Bramka złożona jako jedyna posiada własne wyrażenie określające zachowanie • Pozostałe bramki wykorzystują wyrażenia zdefiniowane na przebiegach • Bramka złożona przy rozwidleniu przepływu zachowuje się podobnie jak bramka OR • Bramka złożona przy scalaniu przebiegów posiada możliwość weryfikacji warunku na bramce 20 Bramka złożona – przykład Pracownicy dostali polecenie wyszukania pewnych informacji Informacje mogą być wyszukiwane w Internecie lub bibliotece Należy rozpocząć poszukiwania w obydwu źródłach i zakończyć, kiedy zostanie znaleziona potrzebna informacja • • Rozpoczęte zostaną dwa zadania: wyszukiwanie w Internecie i wyszukiwanie w bibliotece Proces zakończy się jeśli przynajmniej jedno z równoległych zadań zostanie zakończone 21 • • • • • • • • • Literatura Wprowadzenie Bramki Zdarzenia Czynności Przepływy Pule i tory Obiekty Przykład 22 Zdarzenia • Zdarzenie oznacza wystąpienie pewnej sytuacji w przebiegu procesu biznesowego, istotnej z punktu widzenia tego procesu • Zdarzenie może oznaczać odebranie lub wysłanie komunikatu, sygnału, nadejście pewnego czasu • Zdarzenia mogą rozpoczynać, kończyć, przerywać proces • Zdarzenia umożliwiają modelowanie takich elementów jak: – – – – Komunikacja Transakcje Wyjątki Kompensacje 23 Rodzaje zdarzeń • Początkowe – oznacza rozpoczęcie procesu lub podprocesu • Pośrednie – może pojawić się jako krok w procesie • Końcowe – oznacza zakończenie ścieżki procesu 24 Zdarzenia początkowe • Istnieje 7 rodzajów zdarzeń początkowych • Każde z tych zdarzeń reprezentuje inny sposób i okoliczności w jakich uruchamiany jest proces • Zdarzenia początkowe mogą posiadać tylko przepływy wychodzące • Zdarzenia początkowe są opcjonalne • Proces może posiadać wiele zdarzeń początkowych 25 Nieokreślone zdarzenie początkowe • Nieokreślonego zdarzenia początkowego używa się w sytuacji, gdy proces ma rozpocząć wewnętrzny uczestnik • Każdy proces który w pewnych warunkach będzie funkcjonował jako podproces powinien mieć jedno nieokreślone zdarzenie początkowe • Jeśli proces nie posiada nieokreślonego zdarzenia początkowego, to nie może funkcjonować jako podproces • Procesy rozpoczynające się od niekreślonego zdarzenia mogą być uruchamiane przez tzw. czynność wywołania, czyli mogą być uruchamiane przez inne procesy 26 Zdarzenie początkowe czasowe (Timer) • Proces rozpocznie się, kiedy określony warunek związany z czasem zostanie spełniony • Warunek może oznaczać konkretną datę i czas, np. 1 styczeń 2013 lub też powtarzającą się datę i/lub czas, np. każdy wtorek o 16.30 27 Zdarzenie początkowe warunkowe (Conditional) • Pozwala na uruchomienie procesu w sytuacji, gdy pewien warunek stanie się prawdziwy • Implementacja zdarzenia wymaga ciągłego monitorowania warunku • Zasada działania zdarzenia warunkowego podobna jest do zasady działania wyzwalacza w bazach danych 28 Zdarzenie początkowe Komunikat (Message) • Proces jest uruchamiany, gdy dotrze odpowiedni komunikat • Komunikaty są formą porozumiewania się pomiędzy uczestnikami biznesowymi (pulami) • BPMN nie dopuszcza przesyłania komunikatów w obrębie tej samej puli • Komunikaty są kierowane do określonego adresata • Na diagramie zaznacza się przepływ komunikatu 29 Zdarzenie początkowe Sygnał (Signal) • Proces jest uruchamiany, gdy dotrze odpowiedni sygnał • Sygnały są rozgłaszane (broadcasting) i nie mają określonego adresata • Nadawca sygnału nie ma świadomości istnienia odbiorcy (nie ma potrzeby rejestracji odbiorców) • Na diagramie nie zaznacza się powiązania pomiędzy nadawcą sygnału a odbiorcą, bo sygnał nie ma adresata 30 Komunikat vs. Sygnał Komunikat Sygnał Komunikat jest kierowany do określonego uczestnika Nadawca musi wiedzieć do kogo chce wysłać komunikat Sygnał jest nie jest kierowany do określonego odbiorcy tylko rozgłaszany (publikowany) Każdy może zasubskrybować się by odbierać sygnał Komunikat może uruchomić co najwyżej jeden proces Sygnał może uruchomić wiele procesów Komunikaty mogą być wysyłane tylko pomiędzy pulami (uczestnikami) Sygnały mogą być przesyłane pomiędzy pulami i ramach tej samej puli 31 Wielozdarzenie początkowe zwykłe i równoległe (Multiple i Parallel) • Wielozdarzenie zwykłe jest zbiorem zdarzeń początkowych funkcjonujących według następującej reguły – Wystąpienie jednego z tych zdarzeń powoduje uruchomienie procesu • Wielozdarzenie równoległe jest zbiorem zdarzeń początkowych funkcjonujących według następującej reguły: – Proces jest uruchamiany tylko wtedy, gdy wystąpią wszystkie zdarzenia 32 Zdarzenia końcowe • Zdarzenie końcowe reprezentuje koniec przepływu w procesie lub w jednej z jego ścieżek • Proces może zawierać dowolną skończona liczbę zdarzeń końcowych (również zero) • Zakończenie procesu może oznaczać wytworzenie jakiegoś rezultatu (komunikat, sygnał, itp.) • Jeśli nie ma zdarzenia początkowego, wówczas można pominąć zdarzenie końcowe, gdy proces nie wytwarza żadnego rezultatu • Jeśli model zawiera zdarzenie początkowe to wymagane jest również zdarzenie końcowe 33 Zalecenia projektowe • O ile nie zaleca się dużej liczby zdarzeń początkowych, o tyle w przypadku zdarzeń końcowych jest dokładnie odwrotnie • Powinno się tworzyć zdarzenia końcowe dla każdej innej wartości zwracanej przez proces • Jeśli proces posiada rozgałęzienie równoległe i po złączeniu przebiegów występuje tylko zdarzenie końcowe, wówczas zaleca się nie łączyć przebiegów, tylko zakończyć dwoma lub większą liczbą zdarzeń końcowych 34 Zdarzenie końcowe Przerwanie (Terminate) • Zdarzenie oznacza zakończenie procesu niezależnie od liczby aktywnych ścieżek • Zdarzenie powoduje zakończenie procesu na bieżącym poziomie i wszystkich jego podprocesów • Zdarzenie nie przerywa procesów nadrzędnych • Po wystąpieniu zdarzenia w podprocesie proces nadrzędny jest kontynuowany tak jakby ukończył się w normalnym trybie 35 Zdarzenie końcowe nieokreślone • Zdarzenie końcowe Nieokreślone oznacza zakończenie bieżącej ścieżki procesu bez wytwarzania określonego rezultatu lub też zakończenie bieżącej ścieżki procesu z wytworzeniem rezultatu innego niż w pozostałych zdarzeniach końcowych • Zdarzenie końcowe Komunikat oznacza zakończenie bieżącej ścieżki procesu i przekazanie określonego komunikatu do innego uczestnika procesu • Zdarzenie końcowe Sygnał oznacza zakończenie bieżącej procesu i rozgłoszenie określonego sygnału, który może być odebrany przez dowolnego (w tym tego samego) uczestnika procesu 36 Throwing vs. Catching • Zdarzenia dzielą się na dwie główne kategorie: – Zdarzenia typu catch – oczekuje na nadejście określonego komunikatu sygnału, itp., po jego nadejściu proces przechodzi dalej – Zdarzenia typu throw – wytwarza (generuje, wyrzuca) pewien komunikat sygnał, itp., po „wyrzuceniu” proces przechodzi dalej • Zdarzenia początkowe występują w wersji catch • Zdarzenia końcowe występują w wersji throw • Zdarzenia pośrednie mogą występować w wersji throw lub catch 37 Zdarzenia pośrednie Throw • Zdarzenie pośrednie oznacza sytuację w trakcie wykonywania procesu biznesowego, która jest istotna z punktu widzenia tego procesu Catch Nieokreślone Komunikat Czas Eskalacja Sygnał • Zdarzenia pośrednie służą do modelowania wysyłania i odbierania komunikatów, sygnałów, opóźnień, sytuacji wyjątkowych oraz kompensacji Wielozdarzenie Warunkowe Kompensacja Link 38 Bramka zdarzeniowa (1) • Bramka zdarzeniowa reprezentuje rozgałęzienie typu alternatywa, przy czym wybór konkretnej ścieżki zależy od wystąpienia określonego zdarzenia • Zdarzenia występujące w bramce muszą być typu catch • Bramka zdarzeniowa po aktywacji oczekuje na zajście jednego ze zdefiniowanych zdarzeń • Wystąpienie takiego zdarzenia powoduje, że przebieg przechodzi dalej, a pozostałe ścieżki są dezaktywowane 39 Bramka zdarzeniowa (2) • Autoryzacja przy pomocy kodu np. SMS przebiega zwykle według następującego schematu: – System wysyła SMS z kodem autoryzującym i prosi o wprowadzenie kodu do formularza – Użytkownik wprowadza kod do formularza wówczas podejmowana jest próba autoryzacji – Jeśli w ciągu np. 60 sekund kod nie zostanie wprowadzony proces autoryzacji kończy się 40 Bramka zdarzeniowa (3) • Działanie bramki przypomina tzw. race condition (wygrywa ta ścieżka, która pierwsza odbierze komunikat • Wykorzystuje się często do obsługi przekroczeń czasowych (timeout) oraz do obsługi wyjątków • W odróżnieniu od pozostałych bramek nie opiera się na danych tylko na zdarzeniach 41 • • • • • • • • • Literatura Wprowadzenie Bramki Zdarzenia Czynności Przepływy Pule i tory Obiekty Przykład 42 Czynność • Czynność to praca wykonana w ramach procesu biznesowego • Wykonanie czynności zajmuje określony czas oraz wymaga zaangażowania określonych zasobów • Zwykle konieczne jest wprowadzenie pewnych danych wejściowych • W efekcie realizacji powstaje też często pewien wynik (produkt, usługa, dokument) 43 Rodzaje czynności • Zadanie Czynność atomowa • Podproces Czynności nie atomowe • Czynność wywołania Reprezentuje wywołanie innej czynności 44 Zadanie Zadanie jest przykładem czynności, która nie jest dekomponowana na prostsze czynności (czynność atomowa) W modelowanej rzeczywistości dekompozycja zadania na prostsze czynności zwykle istnieje Przyjmuje się jednak, że taka dekompozycja nie jest istotna z punktu widzenia modelowanego procesu Zadanie nie jest funkcją systemu ani nie jest stanem systemu – zadanie to praca wykonana w ramach procesu Przykład: Wprowadzenie danych do formularza rejestracyjnego serwisu pocztowego 45 Rodzaje zadań • Niezdefiniowane (none) • Użytkownika (user) wykonuje użytkownik pod kontrolą systemu informatycznego • Manualne (manual) wykonuje użytkownik bez kontroli systemu informatycznego • Usługowe (service) wywołuje usługę sieciową lub określoną aplikację • Wysłania (send) wysyła wiadomość do zewnętrznego uczestnika • Odebrania (receive) Oczekuje i odbiera wiadomość od zewnętrznego uczestnika • Skryptowe (script) wykonuje dostarczony skrypt • Reguły biznesowej (business rules) wykonuje reguły biznesowe na silniku reguł 46 Zadanie niezdefiniowane (None lub Abstract) Nie posiada wyspecyfikowanego rodzaju pracy do wykonania Na diagramie może oznaczać każdy rodzaj zadań Jest używane w początkowej fazie odkrywania procesu, kiedy nie znamy jeszcze szczegółów realizacji poszczególnych zadań Jeśli nie jest planowana implementacja procesu zadanie niezdefiniowane może istnieć również w końcowej wersji modelu procesu 47 Zadania wykonywane przez człowieka Zadanie użytkownika reprezentuje dowolną pracę w procesie biznesowym, która jest wykonywana przez człowieka z wykorzystaniem systemów komputerowych (np. wysłanie e-maila, opracowanie danych w arkuszu, wprowadzenie danych do CRM) Zadanie manualne reprezentuje dowolną pracę w procesie biznesowym, która jest wykonywana przez człowieka bez używania systemów komputerowych (np. sortowanie listów, dostarczenie przesyłki) 48 Zadanie użytkownika • Zadanie wykonywane przez użytkownika wiąże się z następującymi operacjami • Utworzenie tzw. workitem i dodanie do listy zadań do wykonania przez użytkownika • Powiadomienie użytkownika, że pojawiło się nowe zadanie do wykonania • Dostarczenie danych procesowych i dokumentów niezbędnych do realizacji zadania 49 Zadanie usługowe (Service) Zadanie wykonywane automatycznie przez zewnętrzny system na żądanie silnika procesów Domyślne zachowanie polega na wywołaniu usługi sieciowej (web service) Możliwe są inne implementacje niż usługa sieciowa (zależy od dostawcy systemu) Usługi sieciowe mogą być wywoływane synchronicznie lub asynchronicznie Wywołanie synchronicznie wstrzymuje proces do momentu powrotu z usługi Wywołanie asynchronicznie nie wstrzymuje procesu Zadanie usługowe służy do modelowania usług wywoływanych w sposób synchroniczny Wywołania asynchroniczne modelowane są przy pomocy zdarzeń wysyłania i odbierania komunikatów 50 Zadanie wysłania (Send) Zadanie wysłania polega na wysłaniu komunikatu do innego uczestnika (puli) Zadanie jest realizowane automatycznie przez silnik procesów biznesowych wspierany przez inny system /komponent Człowiek nie uczestniczy w realizacji tego zadania Wysłanie komunikatu może być alternatywnie modelowane przez zdarzenie typu komunikat (throw) 51 Zadanie odebrania (Receive) Zadanie polega na odebraniu komunikatu od innego uczestnika Zadanie jest realizowane automatycznie przez silnik procesów biznesowych wspierany przez inny system /komponent Człowiek nie uczestniczy w realizacji tego zadania Odebranie komunikatu może być alternatywnie modelowane przez zdarzenie Komunikat (catch) 52 Zadania wysyłania i odbierania • Jeśli w przepływ komunikatów zaangażowany jest człowiek (np. wysłanie maila, faksu, rozmowa telefoniczna), wówczas należy używać zadania użytkownika • Jeśli przepływ komunikatów odbywa się na linii maszynado-maszyna (np. SOAP, JMS), wówczas należy stosować zadanie wysyłania i odbierania lub zdarzenia typu komunikat (catch + throw) 53 Zadanie skryptowe (script) Polega na wykonaniu pewnego skryptu Zadanie jest realizowane automatycznie przez silnik procesów biznesowych Silniki procesów potrafią uruchomić skrypty w JavaScript, Xpath i wiele innych BPMN nie definiuje języka skryptowego Silniki procesów potrafią przekazać dane z procesu do skryptu i odebrać wyniki działania skryptu Skrypty reprezentują zazwyczaj proste zadania przetwarzania danych; stosuje się je tam, gdzie nie opłaca się używać usług 54 Reguły biznesowe Przez regułę biznesową należy rozumieć zbiór powiązanych konstrukcji warunkowych typu „jeżeli A i B to C” Reguły biznesowe są niezależne od procesu: proces reprezentuje przepływ zadań, reguły biznesowe służą wyznaczenia wartości pewnych danych/obiektów Reguły biznesowe mogą reprezentować polityki biznesowe możliwe do wykorzystania w różnych procesach (np. sprawdzanie czy klient może być zaliczony do grupy „Premium” lub czy klient jest wypłacalny?) Procesy biznesowe się uruchamia; na regułach biznesowych prowadzi się wnioskowanie Reguły biznesowe zwykle są składowane w oddzielnym repozytorium i zarządzane przez System Zarządzania Regułami Biznesowymi Systemy Zarządzania Regułami Biznesowymi są często zintegrowane z Systemami Zarządzania Procesami Biznesowymi Systemy Zarządzania Regułami Biznesowymi oprócz zbiorów reguł udostępniają takie elementy jak siatki, czy tabele decyzyjne 55 Zadanie reguły biznesowej (business Rule) Zadanie polega na przeprowadzeniu wnioskowania na bazie reguł biznesowych W zadaniu bierze udział silnik procesu i silnik reguł biznesowych Silnik procesu odpowiada za przygotowanie danych do wnioskowania i odebranie wyniku Silnik reguł odpowiada za przeprowadzenie wnioskowania 56 • • • • • • • • • Literatura Wprowadzenie Bramki Zdarzenia Czynności Przepływy Pule i tory Obiekty Przykład 57 Rodzaje przepływów w procesie • Przepływ sekwencji • Przepływ komunikatów • Przepływ danych 58 Przepływ sekwencji • Przepływ sekwencji pomiędzy dwoma elementami A i B (od A do B) oznacza, że jeśli element A zakończył działanie, wówczas element B staje się aktywny • Przepływ sekwencji może zachodzić pomiędzy czynnościami, zdarzeniami, bramkami, • Przepływ sekwencji nie może jednak zachodzić miedzy pulami 59 Przepływ komunikatów • Przepływ komunikatów reprezentuje wiadomość wysyłaną pomiędzy dwoma pulami (uczestnikami) • Komunikaty są wysyłane i odbierane przez dedykowane zadania lub zdarzenia, ale nie jest możliwe by wysyłający i odbiorca znajdowali się w tej samej puli. 60 • • • • • • • • • Literatura Wprowadzenie Bramki Zdarzenia Czynności Przepływy Pule i tory Obiekty Przykład 61 Pule (Baseny) i tory Pula reprezentuje uczestnika, który bierze udział w procesie Pula białej skrzynki zawiera model procesu Pula czarnej skrzynki nie zawiera modelu procesu Pule białej skrzynki zaleca nazywać się nazwą procesu Pule czarnej skrzynki zaleca nazywać się nazwą uczestnika Tory mogą reprezentować rolę uczestnika w organizacji lub dowolny inny aspekt (np. odpowiedzialność) Tory mogą być zagnieżdżane 62 Pule i tory • Ograniczenia nałożone na pule – Pula może zawierać tylko jeden proces – Przepływ sekwencji jest ograniczony do jednej puli, nie może przekraczać granic puli – Przepływ komunikatów może odbywać się tylko pomiędzy pulami • BPMN nie określa dodatkowych ograniczeń na tory niż te wynikające z faktu, że tory znajdują się w puli 63 • • • • • • • • • Literatura Wprowadzenie Bramki Zdarzenia Czynności Przepływy Pule i tory Obiekty Przykład 64 Modelowanie danych w procesie • BPMN umożliwia modelowanie obiektów przetwarzanych w procesie biznesowym • Pojęcie obiektu w BPMN odnosi się do informacji, danych, dokumentów, obiektów materialnych • Do modelowanie obiektów służą następujące konstrukcje: – Obiekt danych – Magazyn danych – Dane wejściowe i wyjściowe 65 Obiekt danych • Obiekty danych posiadają stan, który służy do oznaczenia jak obiekt zmienia się trakcie procesu, np. obiekt zamówienie może posiadać następujące stany: złożone, zaakceptowane, opłacone, zrealizowane • Ten sam obiekt danych może pojawić się w wielu miejscach w procesie, w każdym z tych miejsc może znajdować się w innym stanie • Obiekt danych może być powiązany z – przepływem sekwencji, komunikatów (zwykła asocjacja), – czynnościami i zdarzeniami (asocjacja kierunkowa) • Przepływ obiektów w procesie nie ma wpływu na przepływ sekwencji 66 Magazyn danych • Magazyn danych służy do przechowywania danych procesu niezależnie od tego czy proces trwa, czy też został zakończony • Proces może czytać i zapisywać dane do magazynu • Magazyn danych może również być przydatny w interakcji procesu z zewnętrznymi systemami 67 dane wejściowe i wyjściowe • Wejściowe i wyjściowe obiekty są obiektami zewnętrznymi, istniejącymi przed i/lub po zakończeniu procesu • Obiekt wejściowy to obiekt wymagany do uruchomienia / działania procesu • Obiekt wyjściowy to obiekt powstały lub przetworzony w procesie przekazany do otoczenia • Obiekt może jednocześnie występować w roli wejściowego i wyjściowego, np. legitymacja studencka w trakcie procesu prolongaty legitymacji 68 Czas życia obiektów • Czas życia obiektu danych zależy od jego rodzaju obiektu • Obiekty wejściowe i wyjściowe żyją niezależnie od procesu • Obiekty wewnętrzne żyją tylko tyle, ile instancja procesu • Jeśli obiekt wewnętrzny ma żyć dłużej musi być składowany w magazynie danych 69 Obiekt danych – przykład 70 • • • • • • • • • Literatura Wprowadzenie Bramki Zdarzenia Czynności Przepływy Pule i tory Obiekty Przykład 71 72 KONIEC 73