Modelowanie procesów biznesowych BPMN cz. I
|
|
- Stanisław Kamiński
- 7 lat temu
- Przeglądów:
Transkrypt
1 Modelowanie procesów biznesowych BPMN cz. I 1
2 Plan wykładu Literatura Wprowadzenie Bramki Zdarzenia Czynności Przepływy Pule i tory Obiekty Przykład 2
3 Literatura* 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 *w prezentacji wykorzystano przykłady z wyżej wymienionych pozycji 3
4 Literatura Wprowadzenie Bramki Zdarzenia Czynności Przepływy Pule i tory Obiekty Przykład 4
5 Pojęcie procesu Proces w językach programowania Procesy w naukach inżynierskich (procesy chemiczne, procesy sterowania w automatyce) Produkcja oprogramowania Procesy biznesowe (zarządzanie, informatyka) 5
6 Definicje procesu biznesowego (1) Proces biznesowy jest to logiczna organizacja ludzi, materiałów, energii, wyposażenia i procedur w działalności zawodowej przeznaczony do uzyskania określonego efektu końcowego (Pall, 1987, Zarządzanie) Proces biznesowy jest zdefiniowany jako łańcuch działań, których ostatecznym celem jest produkcja konkretnej wartości wyjściowej dla konkretnego klienta lub rynku (Davenport, 1993, Ekonomia) Proces biznesowy jest zbiorem czynności, ma jeden lub więcej rodzajów wejść i tworzy wartość wyjściową dla klienta. Proces biznesowy posiada swój cel, a oddziałują na niego zdarzenia zachodzące w świecie zewnętrznym lub w innych procesach (Hammer and Champy, 1993, Nauki inżynierskie) 6
7 Procesy biznesowe Określony zbiór czynności biznesowych, które stanowią niezbędne kroki w celu osiągnięcia celu biznesowego. Obejmuje on przepływ i użycie informacji oraz zasobów (OMG, 2011) Proces biznesowy jest to zbiór powiązanych procedur lub działań, które wspólnie zapewniają osiągnięcie celu biznesowego lub celu polityki, zwykle w ramach struktury organizacyjnej definiującej funkcjonalność ról i zależności pomiędzy nimi (WfMC, 1999) Proces biznesowy to seria powiązanych ze sobą działań lub zadań, które rozwiązują określony problem lub prowadzą do osiągnięcia określonego efektu (Wikipedia, 2012) 7
8 Dlaczego warto modelować procesy biznesowe? Odpowiedzialność za zadania (co kto robi) Alokacja zasobów (jak przypisać zadania) Związki (kto/co z kim/czym się komunikuje) Przepływy informacji (skąd biorą się dokumenty i gdzie trafiają) Ścieżki krytyczne (gdzie mogą pojawić się problemy) Optymalizacja procesów (jak zwiększyć produktywność, obniżyć, koszty przyśpieszyć proces?) Automatyzacja (które czynności można zautomatyzować) 8
9 Reguły wyrazem strategii 1/4
10 Reguły wyrazem strategii 2/4
11 Reguły wyrazem strategii 3/4
12 Reguły wyrazem strategii 4/4
13 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) 13
14 Troszeczkę historii 2001 opracowanie BPML przez organizację BPMI 2004 przedłożenie BPMN do akceptacji przez OMG 2006 akceptacja BPMN przez OMG 2011 wersja
15 BPMN vs. diagramy czynności BPMN Diagramy czynności 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 15
16 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 16
17 Literatura Wprowadzenie Bramki Zdarzenia Czynności Przepływy Pule i tory Obiekty Przykład 17
18 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) 18
19 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) 19
20 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) 20
21 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 21
22 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 22
23 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 23
24 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ą myte, płyn jest uzupełniany 24
25 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 25
26 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 26
27 Literatura Wprowadzenie Bramki Zdarzenia Czynności Przepływy Pule i tory Obiekty Przykład 27
28 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 28
29 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 29
30 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 30
31 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 31
32 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
33 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 33
34 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 34
35 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 35
36 Komunikat vs. Sygnał Komunikat Komunikat jest kierowany do określonego uczestnika Nadawca musi wiedzieć do kogo chce wysłać komunikat Komunikat może uruchomić co najwyżej jeden proces Sygnał Sygnał jest nie jest kierowany do określonego odbiorcy tylko rozgłaszany (publikowany) Każdy może zasubskrybować się by odbierać sygnał 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 36
37 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 37
38 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 38
39 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 39
40 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 40
41 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 41
42 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 42
43 Zdarzenia pośrednie Nieokreślone Komunikat Czas Eskalacja Throw Catch Zdarzenie pośrednie oznacza sytuację w trakcie wykonywania procesu biznesowego, która jest istotna z punktu widzenia tego procesu Sygnał Wielozdarzenie Warunkowe Kompensacja Link Zdarzenia pośrednie służą do modelowania wysyłania i odbierania komunikatów, sygnałów, opóźnień, sytuacji wyjątkowych oraz kompensacji 43
44 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 44
45 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ę 45
46 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 46
47 Literatura Wprowadzenie Bramki Zdarzenia Czynności Przepływy Pule i tory Obiekty Przykład 47
48 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) 48
49 Rodzaje czynności Zadanie Czynność atomowa Podproces Czynności nie atomowe Czynność wywołania Reprezentuje wywołanie innej czynności 49
50 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 50
51 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ł 51
52 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 52
53 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 a, 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) 53
54 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 54
55 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 55
56 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) 56
57 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) 57
58 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) 58
59 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 59
60 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 60
61 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 61
62 Literatura Wprowadzenie Bramki Zdarzenia Czynności Przepływy Pule i tory Obiekty Przykład 62
63 Rodzaje przepływów w procesie Przepływ sekwencji Przepływ komunikatów Przepływ danych 63
64 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 64
65 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. 65
66 Literatura Wprowadzenie Bramki Zdarzenia Czynności Przepływy Pule i tory Obiekty Przykład 66
67 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 67
68 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 68
69 Literatura Wprowadzenie Bramki Zdarzenia Czynności Przepływy Pule i tory Obiekty Przykład 69
70 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 70
71 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 71
72 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 72
73 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 73
74 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 74
75 Obiekt danych przykład 75
76 Literatura Wprowadzenie Bramki Zdarzenia Czynności Przepływy Pule i tory Obiekty Przykład 76
77 77
78 KONIEC 78
Modelowanie procesów biznesowych BPMN cz. 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
Bardziej szczegółowoTerminologia BPMN 2.0 Wersja 2.0 opracowana w AION
Terminologia BPMN 2.0 Wersja 2.0 opracowana w AION Terminy standardu OMG BPMN 2.0 są wytłuszczone i uporządkowane alfabetycznie. Podane ich tłumaczenia, pisane zwykłą czcionką, zostały opracowane przez
Bardziej szczegółowoJęzyk UML w modelowaniu systemów informatycznych
Język UML w modelowaniu systemów informatycznych dr hab. Bożena Woźna-Szcześniak Akademia im. Jan Długosza bwozna@gmail.com Wykład 4 Diagramy aktywności I Diagram aktywności (czynności) (ang. activity
Bardziej szczegółowoModelowanie procesów biznesowych BPMN cz. II
Modelowanie procesów biznesowych BPMN cz. II Plan wykładu Łączenie przepływów Powtarzanie czynności Zdarzenia pośrednie Podprocesy 2 Literatura* http://www.omg.org/spec/bpmn/2.0/ witryna organizacji odpowiedzialnej
Bardziej szczegółowoInżynieria oprogramowania
Inżynieria oprogramowania Wykład 8 Inżynieria wymagań: analiza przypadków użycia a diagram czynności Patrz: Stanisław Wrycza, Bartosz Marcinkowski, Krzysztof Wyrzykowski, Język UML 2.0 w modelowaniu systemów
Bardziej szczegółowoTECHNOLOGIE OBIEKTOWE WYKŁAD 2. Anna Mroczek
TECHNOLOGIE OBIEKTOWE WYKŁAD 2 Anna Mroczek 2 Diagram czynności Czym jest diagram czynności? 3 Diagram czynności (tak jak to definiuje język UML), stanowi graficzną reprezentację przepływu kontroli. 4
Bardziej szczegółowoMapowanie procesów - AS IS (jak jest)
Zarządzanie procesami dr Mariusz Maciejczak www.maciejczak.pl Mapowanie procesów - AS IS (jak jest) Źródło: G. Jokiel, AE Wrocław Podejście funkcjonalne i procesowe Proces Proces to uporządkowany w czasie
Bardziej szczegółowokoniec punkt zatrzymania przepływów sterowania na diagramie czynności
Diagramy czynności opisują dynamikę systemu, graficzne przedstawienie uszeregowania działań obrazuje strumień wykonywanych czynności z ich pomocą modeluje się: - scenariusze przypadków użycia, - procesy
Bardziej szczegółowoModelowanie procesów biznesowych, przepływu pracy i wdrażanie aplikacji w oparciu o Jboss jbpm lub Activiti
Kod szkolenia: Tytuł szkolenia: JBPM Modelowanie procesów biznesowych, przepływu pracy i wdrażanie aplikacji w oparciu o Jboss jbpm lub Activiti Dni: 2 Szkolenie jest zgodne z wersją 6.x, możliwe są również
Bardziej szczegółowoŹródło: S. Wrycza, B. Marcinkowski, K. Wyrzykowski Język UML 2.0 w modelowaniu systemów informatycznych Helion DIAGRAMY INTERAKCJI
DIAGRAMY INTERAKCJI DIAGRAMY STEROWANIA INTERAKCJĄ Diagramy sterowania interakcją dokumentują logiczne związki między fragmentami interakcji. Podstawowe kategorie pojęciowe diagramów sterowania interakcją
Bardziej szczegółowoĆwiczenie 1. Modelowanie prostego procesu
Ćwiczenie 1. Modelowanie prostego procesu Część 1. Definiowanie nowego projektu 1. Uruchom narzędzie TIBCO Business Studio. 2. Z menu wybierz File -> New -> Project... 3. W oknie dialogowym New Project
Bardziej szczegółowoModelowanie procesów biznesowych, przepływu pracy oraz reguł biznesowych na przykładzie Drools i jbpm lub Activiti
Kod szkolenia: Tytuł szkolenia: BPMR Modelowanie procesów biznesowych, przepływu pracy oraz reguł biznesowych na przykładzie Drools i jbpm lub Activiti Dni: 5 Opis: Adresaci Szkolenia: Szkolenie adresowane
Bardziej szczegółowoJak powstaje model biznesowy? Co to jest? Modelowanie biznesowe. Model biznesowy. Jak powstaje model biznesowy? Jak firma generuje przychody?
Modelowanie biznesowe Wprowadzenie (część 1) Co to jest? Każdy model jest błędny. Niektóre modele są użyteczne. George E. P. Box Jak firma generuje przychody? Model biznesowy Sposób generowania przychodów
Bardziej szczegółowoPodstawy programowania III WYKŁAD 4
Podstawy programowania III WYKŁAD 4 Jan Kazimirski 1 Podstawy UML-a 2 UML UML Unified Modeling Language formalny język modelowania systemu informatycznego. Aktualna wersja 2.3 Stosuje paradygmat obiektowy.
Bardziej szczegółowoKomputerowe Systemy Przemysłowe: Modelowanie - UML. Arkadiusz Banasik arkadiusz.banasik@polsl.pl
Komputerowe Systemy Przemysłowe: Modelowanie - UML Arkadiusz Banasik arkadiusz.banasik@polsl.pl Plan prezentacji Wprowadzenie UML Diagram przypadków użycia Diagram klas Podsumowanie Wprowadzenie Języki
Bardziej szczegółowoZagadnienia (1/3) Data-flow diagramy przepływów danych ERD diagramy związków encji Diagramy obiektowe w UML (ang. Unified Modeling Language)
Zagadnienia (1/3) Rola modelu systemu w procesie analizy wymagań (inżynierii wymagań) Prezentacja różnego rodzaju informacji o systemie w zależności od rodzaju modelu. Budowanie pełnego obrazu systemu
Bardziej szczegółowoMapowanie procesów - AS IS (jak jest)
Projektowanie procesów dr Mariusz Maciejczak www.maciejczak.pl Mapowanie procesów - AS IS (jak jest) Źródło: G. Jokiel, AE Wrocław Podejście funkcjonalne i procesowe Proces Proces to uporządkowany w czasie
Bardziej szczegółowoJBPM [JUG] Tomasz Gratkowski [GRATKOWSKI SOFTWARE]
JBPM [JUG] Tomasz Gratkowski [GRATKOWSKI SOFTWARE] Parę słów o mnie 2 Nauczyciel akademicki od 2000 roku Od 2002 współpracuję z firmami jako programista i projektant aplikacji Od 2006 roku właściciel firmy
Bardziej szczegółowoKurs programowania. Wykład 12. Wojciech Macyna. 7 czerwca 2017
Wykład 12 7 czerwca 2017 Czym jest UML? UML składa się z dwóch podstawowych elementów: notacja: elementy graficzne, składnia języka modelowania, metamodel: definicje pojęć języka i powiazania pomiędzy
Bardziej szczegółowoWymiar poziomy: oś na której umieszczono instancje klasyfikatorów biorące udział w interakcji.
Wymiar poziomy: oś na której umieszczono instancje klasyfikatorów biorące udział w interakcji. Wymiar pionowy: oś czasu przedstawiajaca ułożone chronologicznie komunikaty Podstawowe notacje graficzne Konceptualny
Bardziej szczegółowoFaza Określania Wymagań
Faza Określania Wymagań Celem tej fazy jest dokładne określenie wymagań klienta wobec tworzonego systemu. W tej fazie dokonywana jest zamiana celów klienta na konkretne wymagania zapewniające osiągnięcie
Bardziej szczegółowoAPIO. W4 ZDARZENIA BIZNESOWE. ZALEŻNOŚCI MIĘDZY FUNKCJAMI. ELEMENTY DEFINICJI PROCESU. DIAGRAM ZALEŻNOŚCI FUNKCJI.
APIO. W4 ZDARZENIA BIZNESOWE. ZALEŻNOŚCI MIĘDZY FUNKCJAMI. ELEMENTY DEFINICJI PROCESU. DIAGRAM ZALEŻNOŚCI FUNKCJI. dr inż. Grażyna Hołodnik-Janczura W8/K4 ZDARZENIA BIZNESOWE W otoczeniu badanego zakresu
Bardziej szczegółowoProjektowanie oprogramowania cd. Projektowanie oprogramowania cd. 1/34
Projektowanie oprogramowania cd. Projektowanie oprogramowania cd. 1/34 Projektowanie oprogramowania cd. 2/34 Modelowanie CRC Modelowanie CRC (class-responsibility-collaborator) Metoda identyfikowania poszczególnych
Bardziej szczegółowoDiagramy czynności. Widok logiczny. Widok fizyczny
Diagramy czynności System widoków 4+1 Kruchtena Widok logiczny Widok fizyczny Widok procesu Widok przypadków użycia Widok konstrukcji Diagramy czynności są jedynym diagramem w widoku procesu modelowanego
Bardziej szczegółowoModelowanie biznesowe. Na podstawie materiałów: Mirosława Ochodeka
Modelowanie biznesowe Na podstawie materiałów: Mirosława Ochodeka Miroslaw.Ochodek@cs.put.poznan.pl 1 Agenda Modelowanie biznesowe Obiekty biznesowe UML diagram klas Activity modeling 2 Proces Def: ICOM
Bardziej szczegółowoMechanizmy pracy równoległej. Jarosław Kuchta
Mechanizmy pracy równoległej Jarosław Kuchta Zagadnienia Algorytmy wzajemnego wykluczania algorytm Dekkera Mechanizmy niskopoziomowe przerwania mechanizmy ochrony pamięci instrukcje specjalne Mechanizmy
Bardziej szczegółowoBPMN- BUSINESS PROCESS MODELING NOTATION Narzędzie tworzenia metamodeli procesów biznesowych. Diagram moŝe e być zmieniany na kaŝdym etapie Ŝycia procesu: od stworzenia, poprzez rozwój, wykonanie, monitorowanie
Bardziej szczegółowoUML cz. I. UML cz. I 1/1
UML cz. I UML cz. I 1/1 UML cz. I 2/1 UML - Unified Modeling Language ujednolicony można go współdzielić z wieloma pracownikami modelowania służy do opisu projektowanego modelu język posiada opisaną strukturę
Bardziej szczegółowoGraficzna notacja procesów biznesowych BPMN. Porównanie z notacja UML. Jakub Morkis, Piotr Chmielewski
Graficzna notacja procesów biznesowych BPMN. Porównanie z notacja UML Jakub Morkis, Piotr Chmielewski BPMN - Historia Formowanie grumy tworzącej notację Sierpień 2001, 58 członków reprezentujących 35 firm,
Bardziej szczegółowoZARZĄDZANIU. Wykład VI. dr Jan Kazimirski
INFORMATYKA W ZARZĄDZANIU Wykład VI dr Jan Kazimirski jankazim@mac.edu.pl http://www.mac.edu.pl/jankazim MODELOWANIE SYSTEMÓW UML Literatura Joseph Schmuller UML dla każdego, Helion 2001 Perdita Stevens
Bardziej szczegółowoOdwzorowanie BPMN w sieć Petriego
Odwzorowanie BPMN w sieć Petriego Proces odwzorowania Scenariusz procesu odwzorowania BPMN2PN BPMN Modeler plik XML BPMN Preprocesor plik XMI BPMN Narzędzie transformacji plik PNML Narzędzia analizy: ProM,
Bardziej szczegółowoDiagramy czynności Na podstawie UML 2.0 Tutorial
Diagramy czynności Na podstawie UML 2.0 Tutorial http://sparxsystems.com.au/resources/uml2_tutorial/ Zofia Kruczkiewicz 1 Diagramy czynności 1. Diagramy czyności UML http://sparxsystems.com.au/resources/uml2_tutorial/
Bardziej szczegółowo5. Model komunikujących się procesów, komunikaty
Jędrzej Ułasiewicz str. 1 5. Model komunikujących się procesów, komunikaty Obecnie stosuje się następujące modele przetwarzania: Model procesów i komunikatów Model procesów komunikujących się poprzez pamięć
Bardziej szczegółowoProcesowa specyfikacja systemów IT
Procesowa specyfikacja systemów IT BOC Group BOC Information Technologies Consulting Sp. z o.o. e-mail: boc@boc-pl.com Tel.: (+48 22) 628 00 15, 696 69 26 Fax: (+48 22) 621 66 88 BOC Management Office
Bardziej szczegółowoJęzyk UML w modelowaniu systemów informatycznych
Język UML w modelowaniu systemów informatycznych dr hab. Bożena Woźna-Szcześniak Akademia im. Jan Długosza bwozna@gmail.com Wykład 5 Diagram sekwencji - wprowadzenie I Diagram sekwencji (ang. sequence
Bardziej szczegółowoZ-LOG-1073 Projektowanie procesów Process design. Logistyka I stopień Ogólnoakademicki. Stacjonarne
KARTA MODUŁU / KARTA PRZEDMIOTU Kod modułu Nazwa modułu Nazwa modułu w języku angielskim Obowiązuje od roku akademickiego 2012/2013 Z-LOG-1073 Projektowanie procesów Process design A. USYTUOWANIE MODUŁU
Bardziej szczegółowoAutomatyczne decyzje kredytowe, siła szybkiego reagowania i optymalizacji kosztów. Roman Tyszkowski ING Bank Śląski S.A. roman.tyszkowski@ingbank.
Automatyczne decyzje kredytowe, siła szybkiego reagowania i optymalizacji kosztów. Roman Tyszkowski ING Bank Śląski S.A. roman.tyszkowski@ingbank.pl Obsługa wniosków kredytowych Potrzeba elastyczności
Bardziej szczegółowoAnaliza i programowanie obiektowe 2016/2017. Wykład 6: Projektowanie obiektowe: diagramy interakcji
Analiza i programowanie obiektowe 2016/2017 Wykład 6: Projektowanie obiektowe: diagramy interakcji Jacek Marciniak Wydział Matematyki i Informatyki Uniwersytet im. Adama Mickiewicza 1 Plan wykładu 1. Przejście
Bardziej szczegółowoCel wykładu. Literatura. Wyższa Szkoła Menedżerska w Legnicy. Modelowanie wymagań Wykład 2
Wyższa Szkoła Menedżerska w Legnicy Systemy informatyczne w przedsiębiorstwach Zarządzanie, ZIP, sem. 6 (JG) Modelowanie wymagań Wykład 2 Grzegorz Bazydło Cel wykładu Celem wykładu jest przekazanie wiedzy
Bardziej szczegółowoPROLOG WSTĘP DO INFORMATYKI. Akademia Górniczo-Hutnicza. Wydział Elektrotechniki, Automatyki, Informatyki i Inżynierii Biomedycznej.
Akademia Górniczo-Hutnicza Wydział Elektrotechniki, Automatyki, Informatyki i Inżynierii Biomedycznej WSTĘP DO INFORMATYKI Adrian Horzyk PROLOG www.agh.edu.pl Pewnego dnia przyszedł na świat komputer Komputery
Bardziej szczegółowoZ-LOGN Projektowanie procesów Process design
KARTA MODUŁU / KARTA PRZEDMIOTU Kod modułu Nazwa modułu Nazwa modułu w języku angielskim Obowiązuje od roku akademickiego 2012/2013 Z-LOGN1-1073 Projektowanie procesów Process design A. USYTUOWANIE MODUŁU
Bardziej szczegółowoInformatyzacja przedsiębiorstw WYKŁAD
Informatyzacja przedsiębiorstw WYKŁAD dr inż. Piotr Zabawa IBM/Rational Certified Consultant pzabawa@pk.edu.pl wersja 0.1.0 07.10.2010 Wykład 1 Modelowanie procesów biznesowych Przypomnienie rodzajów narzędzi
Bardziej szczegółowoJęzyk UML w modelowaniu systemów informatycznych
Język UML w modelowaniu systemów informatycznych dr hab. Bożena Woźna-Szcześniak Akademia im. Jan Długosza bwozna@gmail.com Wykład 3 Diagramy przypadków użycia Diagramy przypadków użycia (ang. use case)
Bardziej szczegółowoWymiana opisu procesów biznesowych pomiędzy środowiskiem Eclipse i EMC Documentum
Wymiana opisu procesów biznesowych pomiędzy środowiskiem Eclipse i EMC Documentum Stanisław Jerzy Niepostyn, Ilona Bluemke Instytut Informatyki, Politechnika Warszawska Wprowadzenie Systemy CMS (Content
Bardziej szczegółowoKATEDRA INFORMATYKI STOSOWANEJ PŁ INŻYNIERIA OPROGRAMOWANIA
KATEDRA INFORMATYKI STOSOWANEJ PŁ INŻYNIERIA OPROGRAMOWANIA Przygotował: mgr inż. Radosław Adamus Wprowadzenie Podstawą każdego projektu, którego celem jest budowa oprogramowania są wymagania, czyli warunki,
Bardziej szczegółowoMINISTERSTWO FINANSÓW PLAN INTEGRACJI SYSTEMU ZAŁĄCZNIK NR 6 SEAP SPECYFIKACJA KANAŁ EMAIL DLA PODMIOTÓW ZEWNĘTRZNYCH PL PROJEKT ECIP/SEAP
MINISTERSTWO FINANSÓW PLAN INTEGRACJI SYSTEMU ZAŁĄCZNIK NR 6 SEAP SPECYFIKACJA KANAŁ EMAIL DLA PODMIOTÓW ZEWNĘTRZNYCH PL PROJEKT ECIP/SEAP WERSJA 1 z 15 Spis treści 1. Kanał email dla podmiotów zewnętrznych...
Bardziej szczegółowoJęzyk BPEL. Bussiness Process Execution Language
Język BPEL Bussiness Process Execution Language Język BPEL BPEL jest (Web Services) Business Process Execution Language, standaryzowany przez OASIS BPEL jest językiem bazującym na XML służącym do definiowania
Bardziej szczegółowoWykład 1 Inżynieria Oprogramowania
Wykład 1 Inżynieria Oprogramowania Wstęp do inżynierii oprogramowania. Cykle rozwoju oprogramowaniaiteracyjno-rozwojowy cykl oprogramowania Autor: Zofia Kruczkiewicz System Informacyjny =Techniczny SI
Bardziej szczegółowoUML cz. III. UML cz. III 1/36
UML cz. III UML cz. III 1/36 UML cz. III 2/36 Diagram współpracy Diagramy współpracy: prezentują obiekty współdziałające ze sobą opisują rolę obiektów w scenariuszu mogą prezentować wzorce projektowe UML
Bardziej szczegółowoOpis. Liczba godzin zajęć dydaktycznych z
Załącznik nr 5 do Uchwały nr 1202 Senatu UwB z dnia 29 lutego 2012 r. Elementy składowe sylabusu Nazwa jednostki prowadzącej kierunek Nazwa kierunku studiów Poziom kształcenia Profil studiów Forma studiów
Bardziej szczegółowoInżynieria oprogramowania Jarosław Kuchta. Modelowanie interakcji
Inżynieria oprogramowania Jarosław Kuchta Modelowanie interakcji Podstawowe pojęcia Interakcja (interaction) Przepływ komunikatów pomiędzy obiektami konieczny dla wykonania określonego zadania. Interakcja
Bardziej szczegółowoAnaliza i projektowanie obiektowe 2016/2017. Wykład 10: Tworzenie projektowego diagramu klas
Analiza i projektowanie obiektowe 2016/2017 Wykład 10: Tworzenie projektowego diagramu klas Jacek Marciniak Wydział Matematyki i Informatyki Uniwersytet im. Adama Mickiewicza 1 Plan wykładu 1. Projektowy
Bardziej szczegółowoMODELOWANIE PRZEPŁYWU DANYCH
MODELOWANIE PRZEPŁYWU DANYCH 1. Diagram przepływu danych (DFD) 2. Weryfikacja modelu strukturalnego za pomocą DFD Modelowanie SI - GHJ 1 Definicja i struktura DFD Model części organizacji rozważany z punktu
Bardziej szczegółowoProcesy biznesowe w praktyce. Projektowanie, testowanie i optymalizacja
Procesy biznesowe w praktyce. Projektowanie, testowanie i optymalizacja Autor: Marek Piotrowski Notacje Zasady projektowania i najczęściej popełniane błędy Optymalizacja i testowanie procesów Procesy biznesowe
Bardziej szczegółowoDotacje na innowacje - Inwestujemy w Waszą przyszłość ZAPYTANIE OFERTOWE
Warszawa, 16.07.2013r. Nabywca: Rezerweo Sp. z o.o. Ul. Tamka38 00-355 Warszawa Tel./fax 22 556 23 42 e-mail: dariusz.urbanski@rezerweo.com Dane oferenta: ZAPYTANIE OFERTOWE W zawiązku z realizacją projektu
Bardziej szczegółowoUML w Visual Studio. Michał Ciećwierz
UML w Visual Studio Michał Ciećwierz UNIFIED MODELING LANGUAGE (Zunifikowany język modelowania) Pozwala tworzyć wiele systemów (np. informatycznych) Pozwala obrazować, specyfikować, tworzyć i dokumentować
Bardziej szczegółowoPrzesyłania danych przez protokół TCP/IP
Przesyłania danych przez protokół TCP/IP PAKIETY Protokół TCP/IP transmituje dane przez sieć, dzieląc je na mniejsze porcje, zwane pakietami. Pakiety są często określane różnymi terminami, w zależności
Bardziej szczegółowoReferencyjny model OSI. 3 listopada 2014 Mirosław Juszczak 37
Referencyjny model OSI 3 listopada 2014 Mirosław Juszczak 37 Referencyjny model OSI Międzynarodowa Organizacja Normalizacyjna ISO (International Organization for Standarization) opracowała model referencyjny
Bardziej szczegółowoAutomatyzacja procesu i zarządzanie zespołem
Nowoczesne BOK Automatyzacja procesu i zarządzanie zespołem Wstęp: Automatyzacja w procesach obsługi klienta jest obecnie koniecznym elementem samej obsługi. Myślenie procesowe, związane z Business Process
Bardziej szczegółowoTechniki i rozwiązania IT w optymalizacji procesów
Techniki i rozwiązania IT w optymalizacji procesów dr inż. amber.zarz.agh.edu.pl/amaciol Cel przedmiotu Zapoznać się z problemami informacyjnodecyzyjnymi zarządzania organizacjami Nauczyć się wykorzystywać
Bardziej szczegółowoBazy danych 2. dr inż. Tadeusz Jeleniewski
Wykład 4 Projektowanie bazy danych i procesów aplikacji Modelowanie reguł przetwarzania Środowisko przykładowego programu do modelowania reguł przetwarzania Reguły poprawności 2018-02-23 Bazy danych 2
Bardziej szczegółowoKierunki rozwoju systemów obiegu dokumentów: Enterprise Content Management. Jarosław Żeliński analityk biznesowy, projektant systemów
Kierunki rozwoju systemów obiegu dokumentów: Enterprise Content Management Jarosław Żeliński analityk biznesowy, projektant systemów Cel prezentacji Coraz częściej można się spotkać w firmach z potrzebą
Bardziej szczegółowo1 Projektowanie systemu informatycznego
Plan wykładu Spis treści 1 Projektowanie systemu informatycznego 1 2 Modelowanie pojęciowe 4 2.1 Encja....................................... 5 2.2 Własności.................................... 6 2.3 Związki.....................................
Bardziej szczegółowoZarządzanie działem serwisu przy wykorzystaniu aplikacji Vario
Zarządzanie działem serwisu przy wykorzystaniu aplikacji Vario rejestracja i obsługa zleceń montażowych rejestracja i obsługa zleceń serwisowych rejestracja i planowanie przeglądów serwisowych rejestracja
Bardziej szczegółowoJęzyk UML w modelowaniu systemów informatycznych
Język UML w modelowaniu systemów informatycznych dr hab. Bożena Woźna-Szcześniak Akademia im. Jan Długosza bwozna@gmail.com Wykład 7 Przeglądowe diagramy interakcji Przeglądowe diagramy interakcji wiążą
Bardziej szczegółowoDeduplikacja danych. Zarządzanie jakością danych podstawowych
Deduplikacja danych Zarządzanie jakością danych podstawowych normalizacja i standaryzacja adresów standaryzacja i walidacja identyfikatorów podstawowa standaryzacja nazw firm deduplikacja danych Deduplication
Bardziej szczegółowoDiagram przypadków użycia
Diagram przypadków użycia Diagram przypadków użycia opisuje system z punktu widzenia użytkownika, pokazuje, co robi system, a nie jak to robi. Diagram ten sam w sobie zazwyczaj nie daje nam zbyt wielu
Bardziej szczegółowoDiagramy maszyn stanowych, wzorce projektowe Wykład 5 część 1
Diagramy maszyn stanowych, wzorce projektowe Wykład 5 część 1 Zofia Kruczkiewicz Zofia Kruczkiewicz Inżynieria oprogramowania INEK011 1 Diagramy maszyn stanowych, wzorce projektowe 1. Modelowanie zachowania
Bardziej szczegółowoLaboratorium modelowania oprogramowania w języku UML. Ćwiczenie 4 Ćwiczenia w narzędziu CASE diagram czynności. Materiały dla studenta
Zakład Elektrotechniki Teoretycznej i Informatyki Stosowanej Wydział Elektryczny, Politechnika Warszawska Laboratorium modelowania oprogramowania w języku UML Ćwiczenie 4 Ćwiczenia w narzędziu CASE diagram
Bardziej szczegółowoWarstwa integracji. wg. D.Alur, J.Crupi, D. Malks, Core J2EE. Wzorce projektowe.
Warstwa integracji wg. D.Alur, J.Crupi, D. Malks, Core J2EE. Wzorce projektowe. 1. Ukrycie logiki dostępu do danych w osobnej warstwie 2. Oddzielenie mechanizmów trwałości od modelu obiektowego Pięciowarstwowy
Bardziej szczegółowoBazy danych 2. Wykład 1
Bazy danych 2 Wykład 1 Sprawy organizacyjne Materiały i listy zadań zamieszczane będą na stronie www.math.uni.opole.pl/~ajasi E-mail: standardowy ajasi@math.uni.opole.pl Sprawy organizacyjne Program wykładu
Bardziej szczegółowomiejsca przejścia, łuki i żetony
Sieci Petriego Sieć Petriego Formalny model procesów umożliwiający ich weryfikację Główne konstruktory: miejsca, przejścia, łuki i żetony Opis graficzny i matematyczny Formalna semantyka umożliwia pogłębioną
Bardziej szczegółowoModelowanie procesów biznesowych
Modelowanie procesów biznesowych Standard BPMN Specyfikacja BPMN 1.2 3 01 2009 (OMG, BPMI) Specyfikacja BPMN 2.0 3 01 2011 (OMG) Notacja modelowania procesów biznesowych podstawy, Marek Piotrowski, Wydawnictwo
Bardziej szczegółowoDiagramy interakcji. Jarosław Kuchta Dokumentacja i Jakość Oprogramowania
Diagramy interakcji Jarosław Kuchta Dokumentacja i Jakość Oprogramowania Podstawowe pojęcia Interakcja (interaction) Przepływ komunikatów pomiędzy obiektami konieczny dla wykonania określonego zadania.
Bardziej szczegółowoZalety projektowania obiektowego
Zalety projektowania obiektowego Łatwe zarządzanie Możliwość powtórnego użycia klas obiektów projektowanie/programowanie komponentowe W wielu przypadkach występuje stosunkowo proste mapowanie pomiędzy
Bardziej szczegółowoDiagramy stanów tworzenie modeli analizy i projektowania Na podstawie UML 2.0 Tutorial
Diagramy stanów tworzenie modeli analizy i projektowania Na podstawie UML 2.0 Tutorial http://sparxsystems.com.au/resources/uml2_tutorial/ Zofia Kruczkiewicz Zofia Kruczkiewicz Projektowanie oprogramowania
Bardziej szczegółowoModelowanie przypadków użycia. Jarosław Kuchta Projektowanie Aplikacji Internetowych
Modelowanie przypadków użycia Jarosław Kuchta Podstawowe pojęcia Przypadek użycia jest formalnym środkiem dla przedstawienia funkcjonalności systemu informatycznego z punktu widzenia jego użytkowników.
Bardziej szczegółowoModelowanie procesów (1) Oracle Designer: Modelowanie procesów. Modelowania procesów (2) Modelowanie procesów (3)
Modelowanie procesów (1) Oracle Designer: Modelowanie procesów Identyfikuje kluczowe aktywności w działalności organizacji. Modeluje wybrane lub wszystkie aktywności w ramach organizacji. Określa kolejność
Bardziej szczegółowoPobieranie komunikatów GIF
Spis treści Wstęp... 2 1. Ustawienia harmonogramu zadań... 3 1.1. Tryby pracy AswPlan... 3 2. System KS-EWD... 4 2.1. Instalacja KS-EWD... 5 3. Inauguracja OSOZ... 6 3.1. Zdefiniowanie zadania pobierania
Bardziej szczegółowoJava Developers Day. Implementacja ESB przy użyciu Mule. ESB Mule Obsługa zamówień DEMO
Java Developers Day Implementacja ESB przy użyciu Mule Michał Majcher michal.majcher@altkom.pl Łukasz Krawczyk lukasz.krawczyk@altkom.pl slide 1 Tematy ESB Mule Obsługa zamówień DEMO Opis problemu Przepływ
Bardziej szczegółowoR o g e r A c c e s s C o n t r o l S y s t e m 5
R o g e r A c c e s s C o n t r o l S y s t e m 5 Nota aplikacyjna nr 003 Wersja dokumentu: Rev. B Uprawnienia Uwaga: Niniejszy dokument dotyczy RACS v5.2 (VISO 1.2.2 lub nowszy) Wprowadzenie W systemie
Bardziej szczegółowoDiagramy maszyn stanowych, wzorce projektowe Wykład 5 część 1
Diagramy maszyn stanowych, wzorce projektowe Wykład 5 część 1 Zofia Kruczkiewicz Zofia Kruczkiewicz Inżynieria oprogramowania INEK011 1 Składnia elementów na diagramach UML 1. W prezentacji składni diagramów
Bardziej szczegółowoSieci Petriego. Sieć Petriego
Sieci Petriego Sieć Petriego Formalny model procesów umożliwiający ich weryfikację Główne konstruktory: miejsca, przejścia, łuki i żetony Opis graficzny i matematyczny Formalna semantyka umożliwia pogłębioną
Bardziej szczegółowoProjektowanie Zorientowane na Dziedzinę. ang. Domain Driven Design
Projektowanie Zorientowane na Dziedzinę ang. Domain Driven Design 2 Projektowanie Stan posiadania Przypadki użycia Model dziedziny Operacje systemowe Kontrakty dla operacji systemowych Problemy do rozwiązania
Bardziej szczegółowoProjektowanie systemów informatycznych. Roman Simiński siminskionline.pl. Modelowanie danych Diagramy ERD
Projektowanie systemów informatycznych Roman Simiński roman.siminski@us.edu.pl siminskionline.pl Modelowanie danych Diagramy ERD Modelowanie danych dlaczego? Od biznesowego gadania do magazynu na biznesowe
Bardziej szczegółowoWykorzystanie standardów serii ISO 19100 oraz OGC dla potrzeb budowy infrastruktury danych przestrzennych
Wykorzystanie standardów serii ISO 19100 oraz OGC dla potrzeb budowy infrastruktury danych przestrzennych dr inż. Adam Iwaniak Infrastruktura Danych Przestrzennych w Polsce i Europie Seminarium, AR Wrocław
Bardziej szczegółowoINTERNETOWE BAZY DANYCH materiały pomocnicze - wykład X
Wrocław 2006 INTERNETOWE BAZY DANYCH materiały pomocnicze - wykład X Paweł Skrobanek C-3, pok. 323 e-mail: pawel.skrobanek@pwr.wroc.pl INTERNETOWE BAZY DANYCH PLAN NA DZIŚ zajęcia 1: 2. Procedury składowane
Bardziej szczegółowoLogika Temporalna i Automaty Czasowe
Modelowanie i Analiza Systemów Informatycznych Logika Temporalna i Automaty Czasowe (7) Automaty czasowe NuSMV Paweł Głuchowski, Politechnika Wrocławska wersja 2.3 Treść wykładu NuSMV NuSMV symboliczny
Bardziej szczegółowoNowoczesne aplikacje mobilne i ich rola w podnoszeniu jakości danych
Nowoczesne aplikacje mobilne i ich rola w podnoszeniu jakości danych www.ascen.pl 1 Agenda O firmie Zarządzanie jakością danych Aplikacje mobilne i ich rola w zarządzaniu jakością danych 2 O firmie Data
Bardziej szczegółowoDiagramy czynności tworzenie modelu przypadków użycia Wykład 2
Diagramy czynności tworzenie modelu przypadków użycia Wykład 2 Zofia Kruczkiewicz Zofia Kruczkiewicz - Projektowanie oprogramowania 2.2 1 Diagramy czynności- tworzenie modelu przypadków 1. Diagramy czynności
Bardziej szczegółowoNowości oraz trendy w obszarze BPM nurty i kierunki rozwoju. Jarosław Żeliński analityk biznesowy, projektant systemów
Nowości oraz trendy w obszarze BPM nurty i kierunki rozwoju Jarosław Żeliński analityk biznesowy, projektant systemów O mnie qod 1991 roku w branży IT i zarządzania jako analityk projektant rozwiązań qod
Bardziej szczegółowoPodstawy programowania. Wykład Funkcje. Krzysztof Banaś Podstawy programowania 1
Podstawy programowania. Wykład Funkcje Krzysztof Banaś Podstawy programowania 1 Programowanie proceduralne Pojęcie procedury (funkcji) programowanie proceduralne realizacja określonego zadania specyfikacja
Bardziej szczegółowoUML. dr inż. Marcin Pietroo
dr inż. Marcin Pietroo Pojęcia obiektowości obiekt klasa komunikat hermetyzacja polimorfizm dziedziczenie graficzny język wizualizacji, specyfikowania, tworzenia i dokumentowania systemów informatycznych
Bardziej szczegółowoZasady budowy i przekazywania komunikatów wykorzystywanych w Systemie IT KDPW_CCP
Załącznik Nr 3 KDPW_CCP Zasady budowy i przekazywania komunikatów wykorzystywanych w Systemie IT KDPW_CCP Wersja 1.0 Warszawa, czerwiec 2012 Spis treści Wstęp... 3 Budowa komunikatów XML... 3 Przestrzenie
Bardziej szczegółowoSystemy przepływu pracy (workflow)
Systemy przepływu pracy (workflow) Definicja Workflow (w języku polskim określany jako przepływ pracy) jest to zautomatyzowany w całości lub części proces biznesowy, w trakcie którego dokumenty, informacje
Bardziej szczegółowoECDL/ICDL Zarządzanie projektami Moduł S5 Sylabus - wersja 1.0
ECDL/ICDL Zarządzanie projektami Moduł S5 Sylabus - wersja 1.0 Przeznaczenie Sylabusa Dokument ten zawiera szczegółowy Sylabus dla modułu ECDL/ICDL Zarządzanie projektami. Sylabus opisuje zakres wiedzy
Bardziej szczegółowoDiagramy przypadków użycia
Instytut Informatyki Uniwersytetu Śląskiego 10 października 2010 Spis treści 1 Wprowadzenie do UML 2 3 4 5 6 Diagramy UML Język UML definiuje następujący zestaw diagramów: diagram przypadków użycia - służy
Bardziej szczegółowoInżynieria wymagań. Wykład 2 Proces pisania przypadków użycia. Część 6 Wskazówki i sugestie
Inżynieria wymagań Wykład 2 Proces pisania przypadków użycia Część 6 Wskazówki i sugestie Opracowane w oparciu o materiały IBM (kurs REQ570: Writing Good Use Cases) Wyzwania podczas pisania przypadków
Bardziej szczegółowo