Zastosowanie reguł spójności w modelowaniu systemów BPM na przykładzie zamówienia publicznego na system e-irz dla ARiMR

Zastosowanie reguł spójności w modelowaniu systemów BPM na przykładzie zamówienia publicznego na system e-irz dla ARiMR Stanisław Jerzy Niepostyn Instytut Informatyki, Wydział Elektroniki i Technik Informacyjnych, Politechnika Warszawska

Plan prezentacji Cel i motywacja Proces biznesowy, architektura oprogramowania Spójność i kompletność modeli UML/BPMN Reguły spójności modeli UML/BPMN Szereg uporządkowanych diagramów opartych na regułach spójności Szereg powiązanych diagramów od modelu kontekstowego do modelu implementowalnego w środowisku BPM Reguły spójności perspektywy biznesowej Reguły spójności perspektywy systemowej Reguły spójności perspektywy komponentowej Podsumowanie

Project-Media, Stanisław Niepostyn Publikacje naukowe współpraca z Instytutem Informatyki oraz Instytutem Telekomunikacji Politechniki Warszawskiej Projektowanie, modelowanie, audyt systemów informatycznych i procesów biznesowych Wykłady, szkolenia z zakresu modelowania systemów IT (BPM) Darmowe narzędzia open-source do modelowania procesów biznesowych i systemów IT Topcased/Eclipse www.project-media.pl

Project-Media - projekty Projekt e-irz, ZSIN dla ARiMR Audyt systemu SRP dla MSW System ECS/ICS dla Ministerstwa Finansów Projekt systemu BPM-II dla RWE Projekt systemu Dokumentacji Ochrony Danych Osobowych dla Polkomtel S.A. Elektroniczny System Obiegu Dokumentów dla Najwyższej Izby Kontroli Szkolenia, wykłady: Ministerstwo Finansów, ARiMR, PARP, Wola Info, Asseco, RWE, Instytut Informatyki oraz Instytut Telekomunikacji Politechniki Warszawskiej

Project-Media publikacje naukowe Niepostyn Stanisław Jerzy: Consistent Model Driven Architecture, w: Proceedings of SPIE, Photonics Applications in Astronomy, Communications, Industry, and High-Energy Physics Experiments / Romaniuk Ryszard ( red. ) Niepostyn Stanisław Jerzy: The Sufficient Criteria for Consistent Modelling of the Use Case Realization Diagrams with a New Functional-Structure-Behaviour UML Diagram, w: Przegląd Elektrotechniczny, Sigma NOT, nr 2, 2015 Niepostyn Stanisław Jerzy, Tyrowicz Andrzej: The sufficient criteria for consistent modeling from the context diagram to the business use case diagrams driven by consistency rules. Chapter 5, w: Software Engineering from Research and Practice Perspectives / Madeyski Lech, Ochodek Mirosław ( red. ), 2014, Nakom Niepostyn Stanisław Jerzy: The Sufficient Criteria for Consistent Modelling of the Use Case Realization Diagrams, w: Information Systems Architecture and Technology: System Analysis Approach to the Design, Control, and Decision Support / Świątek Jerzy [i in.] ( red. ), 2014, Oficyna Wydawnicza Politechniki Wrocławskiej Bluemke Ilona, Niepostyn Stanisław Jerzy: From Three Dimensional Document Circulation Diagram into UML Diagrams, w: Emerging Trends in Computing, Informatics, Systems Sciences, and Engineering / Sobh Tarek, Elleithy Khaled ( red. ), Lecture Notes in Electrical Engineering Niepostyn Stanisław Jerzy, Bluemke Ilona: The Function-Behaviour-Structure Diagram for Modelling Workflow of Information Systems, w: Advanced Information Systems Engineering Workshops / Bajec Marko, Eder Johann (red.), Lecture Notes in Business Information Processing Niepostyn Stanisław Jerzy: BPMN-XPDL Transformation using Three Dimensional DCD Model, w: Information Systems Architecture and Technology, Information as the Intangible Assets and Company Value Source / Wilimowska Zofia [i in.] ( red. ), 2011, Wrocław University of Technology

Cel i motywacja Stan obecny budowy systemów IT Budowa systemów informatycznych rozpoczynana jest często na podstawie wstępnej architektury oprogramowania (np. tylko przypadki użycia, wyłącznie procesy biznesowe, bądź tylko opis tekstowy) Właściciele systemów informatycznych, którzy chcą wdrożyć (zbudować) IT, otrzymują jedynie informacje praktycznie o przewidywanym koszcie i czasie trwania budowy i wdrożenia IT, bez opisu metody budowy oprogramowania (architekturze oprogramowania), stąd przed zawarciem umowy nie mają możliwości oceny sposobu realizacji SI przez poszczególnych Wykonawców i muszą polegać wyłącznie na zaufaniu do wiedzy i doświadczenia Wykonawcy Systemy Informatyczne opisywane są bardzo często dopiero po ich zbudowaniu (wdrożeniu), przy czym takie opisy są zazwyczaj niespójne i niekompletne, a wynikowa jakość i wartość dokumentacji niewielkie.

Cel i motywacja Koncepcja CMDA Automatyzacja budowy systemów IT sterowana regułami spójności diagramów projektowych UML (BPMN) Consistent Model Driven Architecture (CMDA) Istnieje taki uporządkowany szereg diagramów UML (BPMN), który umożliwia automatyzację budowy systemu informatycznego Taki uporządkowany szereg diagramów UML oparty jest na regułach spójności i kompletności modeli UML w ten sposób, że można pokazać reguły odwzorowujące nawzajem elementy pomiędzy sąsiednimi diagramami

Cel i motywacja Przeznaczenie CMDA Zaprezentowanie metodyki budowy oprogramowania Ocena wiarygodności utworzonej architektury oprogramowania Brak przedstawienia architektury systemu IT za pomocą szeregu uporządkowanych diagramów UML znacznie zwiększa ryzyko niepowodzenia wdrożenia

Proces biznesowy Podejścia: ekonomiczne, zarządzanie organizacją, inżynierskie

Proces biznesowy Definicje 1987 r. - Pall 1993 r. - Davenport 1993 r. - Hammer and Champy 1995 r. - Jacobson 1995 r. - Ould 1999 r. - Workflow Management Coalition 2001 r. - Fan 2005 r. - Wang and Wang 2011 r. Object Management Group (standard BPMN)

Proces biznesowy Definicje: Davenport, Hammer and Champy 1993 r. Davenport 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 1993 r. - Hammer and Champy 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

Proces biznesowy BPM: Business Process Management 2003 r. Wili van der Aalst Business Process Management (BPM) to wiedza o metodach, technikach, narzędziach do projektowania, uruchamiania, kontroli i analizy procesów biznesowych 2003 r. cykl życia BPM Wili van der Aalst Projektowanie (process design) analiza aktualnego stanu organizacji i utworzenie modelu w oparciu o stan systemu informacyjnego AS-IS Konfiguracja (system configuration) implementacja modeli w systemie BPMS Uruchomienie (process enactment) wdrożenie i uruchomienie procesów biznesowych Optymalizacja (diagnosis) upraszczanie przepływów i usuwanie wąskich gardeł

Proces biznesowy Business Process Management vs. Workflow Management

Architektura oprogramowania Rational Unified Process business process

Architektura oprogramowania Model 4 + 1

Koncepcja CMDA Perspektywy i wymiary architektury oprogramowania Architektura składa się z wielu modeli opisujących wybrane zagadnienia (ang. separation of concern Hursh, Lopes 1995 r.) Uproszczony model perspektyw architektonicznych 4 + 1 (podstawa metodyki RUP-1998 r.): Perspektywa biznesowa (scenariuszy), systemowa (projektowa), implementacyjna, wdrożeniowa Każda perspektywa powinna opisywać trzy wymiary (FSB framework, John Gero 1990 r.): Struktura np. diagram klas UML (OMG - structure) Behawioryzm np. diagram stanów UML (OMG - behaviour) Funkcjonalność np. diagram przypadków użycia UML (OMG behaviour, subpackage - functionality)

Koncepcja CMDA Definicje spójności Spanoudakis, Zisman, 2001 r. Niespójności powstają, gdy interpretacje dwóch różnych elementów pokrywają się częściowo, bądź jedna z interpretacji zawarta jest w drugiej formalny opis Hausmann, 2002 r. Niespójność przypadków użycia to nakładaniem się na siebie poszczególnych części przypadków użycia (kroków scenariuszy) Berrardi, 2005 r. Klasa na diagramie klas UML jest spójna, jeśli istnieje możliwość utworzenia jej niepustej instancji formalny opis. Jurack, 2008 Spójność diagramu aktywności polega na tym, iż wszystkie sekwencje przepływu (ang. rule sequences) w takim diagramie muszą być wykonywalne (ang. applicable). Fryz, Kotulski, 2007 Związek i kierunek pomiędzy elementami danego diagramu musi być odzwierciedlony pomiędzy odpowiadającymi elementami w innym diagramie.

Reguły spójności modeli UML Szereg uporządkowanych diagramów UML Author, Year Sequence of Number of diagrams consistency rules Egyed 2000 P(CQ CO CS) 50 Sapna 2007 C(S U(A Q)) 18 Ibrahim 2012 UQC 8 Ha 2008 O(Q A I) 7 Shinkawa 2008 UAQS 4 Chanda 2009 UAC 4 Hausmann 2002 UAO 3 A-activity (business uc realization), B-(business uc), C-(business) class, D-deployment, I-communication, J-(system) class, L-(system) object, M-component, O-(business) object, P-package, Q-sequence, R-process, S-business state machine, T-system state machine, U-(system) use case, X-context, Y-internal use case, Z-system uc realization

Reguły spójności modeli UML Oznaczenia elementów, wyrażenia regularne jako reguły a-aktor c-klasa e-zdarzenie f-atrybut h-metoda i-instancja l-lifeline m-komunikat o-occurence p-partycja s-stan t-przejście stanów u-przypadek użycia v-czynność q-komponent y-interface w-urządzenie/węzeł x-klasyfikator n-związek Niektóre stereotypy: v<<start>> v<<data>> v<<process>> Przykład reguły dla B: u{1}[a 1 -a N ] albo Bu{1}[a 1 -a N ] Przykład ogólnej reguły dla BA: BaAp H Ua

Reguły spójności modeli UML Najczęstsze reguły (wyrażenia regularne) hm: Metoda - komunikat (4) ChQm [Ibrahim '12, szereg:uqc], ChQm [Sapna '07, szereg:c(s U(A Q))], QmOh, OhIm [Ha '08, szereg:o(q A I)] ua: przypadek użycia diagram Aktywności (3) la: linia życia - aktor (3) il: instancja - linia życia (3) ah: aktywność metoda (3) uq: przypadek użycia - diagram Sekwencji (2) mn: komunikat - asocjacja (2) cu: klasa - przypadek użycia (2) cs: klasa - stan (2) cl: klasa - linia życia (2) ca: klasa aktor (2) am: aktywność komunikat (2)

Reguły spójności modeli UML Analiza dotychczasowych rozwiązań Reguły spójności nie odnoszą się do diagramów projektowych, a wyłącznie do diagramów UML bez kontekstu ich użycia Reguły spójności służą jedynie weryfikacji, a nie do budowy innych diagramów (wyjątek Shinkawa '07) Reguły spójności nie mają powiązania z metodyką wytwarzania oprogramowania Reguły spójności nie tworzą razem spójnego zbioru reguł do zastosowania w konkretnym uporządkowanym szeregu diagramów UML

Reguły spójności modeli UML Autorska definicja spójności Modele są spójne, gdy spełniają warunek wystarczającej kompletności oraz warunek wystarczającej spójności (możliwość automatyzacji budowy systemu IT) Warunek wystarczającej kompletności modele systemu informatycznego powinny opisywać funkcjonalność, behawioryzm i strukturę projektowanego systemu reguła kompletności (John Gero 1990 r.) Warunek wystarczającej spójności transformacje (mapowanie) od diagramu na najwyższym poziomie abstrakcji (diagram kontekstowy - Sanford Friedenthal, Howard Lykins, Abe Meilich - 2001), aż do wynikowego kodu aplikacji, powinny spełniać definicje spójności: między diagramami według definicji Spanoudakis a i Zisman a (interpretacje) oraz Fryza i Kotulskiego (powiązania), dla diagramu strukturalnego według definicji Berarrdi ego, dla diagramu behawioralnego według definicji Jurack a, dla diagramu funkcjonalności według definicji Hausmann a.

tom Diagrams Sequence Szereg uporządkowanych diagramów Kompletny i spójny opis architektury oprogramowania Business view {X} Context Diagram: Activ ity Diagram «derive» {B} Business Use Case Diagram: Use Case Diagram «derive» {R} Decomposition Process Diagram: Activ ity Diagram XFSB(RSB BF)AFSB(CS SB UF) «derive» 1..* 1..* {A} FSB UML Business Diagram: Activ ity Diagram «derive» «generated» {C} Business Object Diagram: Class Diagram «generated» {U} System Use Case Diagram: Use Case Diagram «generated» {S} Business Object Behav iour Diagram: State Machine Diagram System view «InformationDependency» UFZFSB(JS TB YF) «generated» {J] System Object Diagram: Class Diagram «derive» 1..* {Z} FSB UML System Diagram: Activ ity Diagram «generated» {Y} Internal Use Case Diagram: Use Case Diagram «InformationDependency» «generated» {T} System Object Behav iour Diagram: State Machine Diagram Component view «InformationDependency» «derive» 1..* {Q} FSB UML Component Diagram: Sequence Diagram «InformationDependency» YFQFSBMFSBDFSB «derive» {M} Component Diagram: Component Diagram «derive» {D} Deployment Diagram: Deployment Diagram XFSB(RSB BF)AFSB(CS SB UF)ZFSB(JS TB YF)QFSBMFSBDFSB

Transformacje perspektywy biznesowej Szereg XR: X FSB (R FSB B F )A FSB (C S S B U F ) Reguły kompletności diagramu kontekstowego: {B} Xv<<process>>{1}; Xi<<rule>>+; {F} Xe+; analysis Context2Decomposition {S} Xi<<product>>+; Xi<<datastore>>+ Context Diagram XeRe<<subevent>> decomposition into Subprocess 1 decomposition into Event 1.1 decomposition into Subprocess 2 decomposition into Event 1.2 Business rules Reguły kompletności diagramu dekompozycji procesów: {B} Rv<<subprocess>>+; {F} Re<<subevent>>+; {S} Ri<<subproduct>>+; Event 1.1 Decomposition Diagram decomposition into Product 1.2 decomposition into Product 1.1 Subprocess 1 Product 1.1 Xev<<process>>{1}R[v 1 <<subprocess>>-v 2 <<subprocess>>] decomposition into Subprocess 1 Event 1 Product 1 Event 1.2 Event 2 Main Process Product 2 decomposition into Subprocess 2 Subprocess 2 Product 2 Event n Repository decomposition into Subprocess n decomposition into Product 2 Event n Subprocess n Product 1.2 decomposition into Event n decomposition into Subprocess n Xi<<rules>>v<<process>>{1}i<<product>>Ri<<subproduct>

Transformacje perspektywy biznesowej Szereg XR dla systemu e-irz act Szereg XR XeRe<<subevent>> Xi(Informacje o kontrolach na miejscu)ri(raport z kontroli) harmogram kontroli masowe typowanie raport z kontroli Diagram dekompozycji procesów Raport z kontroli na miejscu :Raport z kontroli [Zatwierdzony] Raport z kontroli Zgłoszenie siedziby stada Zgłoszenie zwierzęce Zapotrzebowania IRZ Zapytanie o dane «zasób» Repozytorium IRZ «zasób» Zasoby Informacje o kontrolach na miejscu Informacje o zwierzętach Informacje o posiadaczach i siedzibach stad Informacje o identyfikatorach Zgłoszenie siedziby stada decyzja PLW pismo PLW pula kolczyków duplikat paszportu pula duplikatów kolczyków numer dla drugiego kolczyka Zgłoszenie siedziby stada Zgłoszenie zwierzęce Zapotrzebowania IRZ :WzSE [Zatwierdzony] :ZaswRSS [Wydany] Diagram kontekstowy oświadczenie Producenta aktualizacja :WzSD Regulacje UE, Xev<<process>>{1}R[v1<<subprocess>>-v5<<subprocess>>] pismo Producenta stanu [Zatwierdzony] krajowe Xe(Zgłoszenie siedziby stada)v(irz){1}rv(zgłoszenie siedziby stada) działalności Xe(Zgłoszenie zwierzęce)v(irz){1}rv(zgłoszenie zwierzęce) Xe(Zapytanie o dane)v(irz){1}rv(udostępnianie danych) wymóg wzajemnej zgodności Transfer zwierząt Zgłoszenie przemieszczenia Zgłoszenie utylizacji Zgłoszenie rejestracji Zgłoszenie wyrejestrowania Zapytanie o dane wydruk duplikatu zdarzenia paszportu aktualizujące śledzenie wykorzystania puli identyfikatorów Udostępnianie danych :Pass [Wydany] :Prz [Wydany] :Wyr [Wydany] :Pula [Wydany] :Kol [Wydany] Informacje IRZ Xi(Informacje o identyfikatorach)ri(kolczyk) Xi(Informacje o identyfikatorach)ri(pula) Xi<<rules>>v<<process>>{1}i<<product>>Ri<<subproduct>

Transformacje perspektywy biznesowej Szereg XB: X FSB (R FSB B F )A FSB (C S S B U F ) Reguły kompletności diagramu kontekstowego: {B} Xv<<process>>{1}; Xi<<rule>>+; {F} Xe+; {S} analysis Xi<<product>>+; Context2BuseCases Xi<<datastore>>+ Reguły kompletności diagramu biznesowych przypadków użycia: {F} Bu+; Ba+ Context Diagram UseCase Diagram XeBu XeBa UC1. Subprocess 1 Business rules «business actor» Actor1 Event 1 Product 1 Event 2 Event n Main Process Product 2 Xi<<product>>Ba «business actor» Actor2 UC2. Subprocess 2 Repository Xi<<rules>>v<<process>>Bu UCn. Subprocess n «business actor» Actorn

Transformacje perspektywy biznesowej Szereg XB dla systemu e-irz act Szereg XB Raport z kontroli Zgłoszenie siedziby stada Zgłoszenie zwierzęce Zapotrzebowania IRZ Diagram kontekstowy Regulacje UE, Xe(Zapotrzebowania IRZ)v(IRZ){1}Bu(Zapotrzebowania IRZ) krajowe IRZ XeBa Informacje o kontrolach na miejscu Informacje o zwierzętach Informacje o posiadaczach i siedzibach stad Informacje o identyfikatorach realizacja zamówienia Dostawca kolczykówakceptacja, decyzje Diagram biznesowych przypadków użycia UC3. Zapotrzebowania IRZ UC4. Raport z kontroli System IRZ TO-BE zapotrzebowania UC2. Zgłoszenie zwierzęce Posiadacz zgłasza zwierząt zdarzenia i zmiany generuje, drukuje, wprowadza, zatwierdza Pracownik IW Zapytanie o dane «zasób» Repozytorium «zasób» Zasoby Xev<<process>>Bu Pracownik ARiMR UC1. Zgłoszenie siedziby stada UC5. Udostępnianie danych rejestruje siedziby stad Producent Xe(Zapytanie o dane)v(irz){1}bu(udostępnianie danych)

Transformacje perspektywy biznesowej Szereg RA: X FSB (R FSB B F )A FSB (C S S B U F ) analysis Decomposition2FSBModel Event 1.1 Decomposition Diagram Subprocess 1 Event 1.2 Subprocess 2 Product 2 Event n Re<<subevent>>Ap<<vertical>> Re<<subevent>>Ap<<horizontal>>+ Rv<<subprocess>A Subprocess n Product 1.1 Ri<<subproduct>>Ap<<vertical>> Product 1.2 «Lane» Partition1.3 «Lane» Partition1.2 «Lane» Partition1.1 {A} BPMN Process Diagram - UC1. Subprocess 1 «Lane» Request 1 Start 1.1. Task1 Request 1 [Received] 1.2. Task2 Request 1 [Approved] End «Lane» Product 1 1.3. Task 3 1.4. Task4 Product1 [Created] Product1 [Verified] Product1 [Approved]

Transformacje perspektywy biznesowej act System IRZ - dekompozycja procesu głównego harmogram kontroli Szereg RA dla systemu e-irz Re(decyzjaPLW) act Szereg RA Ai(PLW) Business Process Rejestracja siedziby stada Producent System Kancelaryjny zgłoszenie dokumentu papierowego ARiMR Pracownik BP ds. IRZ Start zgłoszenie dokumentu papierowego pobranie numeru dokumentu papierowego rejestracja PLW do PLW dokumentu kancelaryjnego [Zarejestrowany] Zgłoszenie :WzSE [Zarejestrowany] 1. Powiązanie ze sprawą :PLW [Zarejestrowany] :OPr [Zarejestrowany] rejestracja pisma ze stanowiskiem :WzSD [Zarejestrowany] Zgłosznie KnM zwierzęce A1.1, A5.1, pula duplikatów kolczyków A14.1, A15.1 A2.2, numer dla drugiego A6.2 [Wyjaśniony] A7.2, masowe typowanie raport z kontroli wymóg wzajemnej zgodności Zgłoszenie siedziby stada decyzja PLW pismo PLW oświadczenie Producenta pismo Producenta Transfer zwierząt Zgłoszenie przemieszczenia rejestracja pisma z wyjaśnienia producenta pytaniem Zgłoszenie utylizacji Zgłoszenie rejestracji wyrejestrowania pula kolczyków duplikat paszportu kolczyka A1.3. Postępowanie wyjaśniające decyzja nowy Kierownika wniosek Zapytanie o dane [Zapisany] powiadomienie Producenta Wezwanie do powiadomieniedokument wyjaśnienia Producenta elesktroniczny A2.3. Powiadomienie Producenta 2. Wprowadzenie danych Błędy oczywiste wypełnienie wniosku przez Internet [Wyjaśniany] Koniec Raport z kontroli na miejscu Zgłoszenie siedziby stada aktualizacja stanu działalności Zgłoszenie zwierzęce Informacje o wprowadzaniu Rv(Zgłoszenie siedziby stada)a(bpmn) wydruk duplikatu paszportu Zapotrzebowania IRZ Błędy zasadnicze Udostępnianie danych utworzenie dokumentu kancelaryjnego zdarzenia aktualizujące A1.2, A3.1, A5.2, A12.1, A13.1, A.14.2, A15.2, A16.1, A17.1 śledzenie wykorzystania puli identyfikatorów brak akceptacji A4.2, A10.2, A11.2, A12.2, :WzSD :WzSE A13.2, A14.3, [Zatwierdzony] [Zatwierdzony] A15.3, A16.2, A17.2 Anulowanie [Wprowadzony] :WzSD [Wprowadzony] :WzSE [Wprowadzony] :Raport z kontroli [Zatwierdzony] :WzSE [Zatwierdzony] :ZaswRSS [Wydany] :WzSD [Zatwierdzony] :Pass [Wydany] :Prz [Wydany] :Wyr [Wydany] :Pula [Wydany] 3. Zatwierdzenie :Kol [Wydany] zmiana statusu epizootycznego lub stanu działalności kolejna siedziba Informacje IRZ pod jednym adresem Koniec anulowanie dokumentu kancelaryjnego A4.3. Anulowanie [Anulowany] [Zatwierdzony] :ZaswRSS [Zatwierdzony] Ri(ZaswRSS) Ai(ZaswRSS) 4. Wydanie dokumentów [Zaakceptowany] [Akceptowany] Informacje o zatwierdzeniu utworzenie dokumenty kancelaryjnego A4.4, A5.4, A10.3, A18.4 Koniec :OdmowaRSS [Wydana]

Transformacje perspektywy biznesowej Szereg BA: X FSB (R FSB B F )A FSB (C S S B U F ) Reguły kompletności diagramu biznesowych przypadków użycia: Bu{1}a+; Ba{1}u+ analysis BUseCase2FSBDiagram Reguły spójności diagramu A: Av<<start>>[v+ i+]v<<stop>> UseCase Diagram Business FSB UML Diagram - UC1. Subprocess 1 BaAp H Request 1 Start1 Product 1 «business actor» Actor1 UC1. Subprocess 1 Annotation tags Actor = Description = Event = Postcondition = Precondition = Scenario = State = UObject = BuA Partition 1.3 Partition 1.2 Partition 1.1 1.1. Activ ity :Request 1 [Received] 1.2. Activ ity :Product 1 [Created] :Request 1 1.3. Activ ity [Approved] :Product 1 [Verified] 1.4. Activ ity :Product 1 [Approved] Final1

Transformacje perspektywy biznesowej Szereg BA systemu e-irz act Szereg BA Pracownik ARiMR Ba(Producent)Ap H (Producent) realizacja zamówienia Dostawca kolczyków akceptacja, decyzje Diagram biznesowych przypadków użycia UC3. Zapotrzebowania IRZ UC4. Raport z kontroli UC1. Zgłoszenie siedziby stada System IRZ TO-BE zapotrzebowania UC2. Zgłoszenie zwierzęce Posiadacz zgłasza zwierząt zdarzenia i zmiany generuje, drukuje, wprowadza, zatwierdza Pracownik IW UC5. Udostępnianie danych rejestruje siedziby stad Producent Ba(Pracownik ARiMR)Ap H (ARiMR) Bu(Zgłoszenie siedziby stada)a(bpmn) Ba(Pracownik IW)Ap H (PLW) Business Process Rejestracja siedziby stada PLW/Organy ARiMR Producent System Kancelaryjny zgłoszenie dokumentu papierowego Kierownik BP Pracownik BP ds. IRZ Start zgłoszenie dokumentu papierowego pobranie numeru dokumentu papierowego 1. Powiązanie ze sprawą kancelaryjnego [Zarejestrowany] :PLW [Zarejestrowany] :OPr [Zarejestrowany] [Zakonczony] rejestracja dokumentu Koniec A6.3. Weryfikacja decyzji o rejestracji siedziby stada :WzSE [Zarejestrowany] :WzSD [Zarejestrowany] A1.3. Postępowanie wyjaśniające [Zapisany] Zgłosznie KnM zwierzęce A1.1, A5.1, A14.1, A15.1 A2.2, A6.2 [Wyjaśniony] A7.2, A8.2, A9.2 stanowisko PLW rejestracja pisma ze stanowiskiem PLW rejestracja pisma z wyjaśnienia producenta pytaniem do PLW do rejestracji zapytanie o stanowisko decyzja Kierownika powiadomienie Producenta Wezwanie do powiadomieniedokument wyjaśnienia Producenta elesktroniczny A7.3 nowy wniosek nowy wniosek A2.3. Powiadomienie Producenta 2. Wprowadzenie danych Błędy oczywiste wypełnienie wniosku przez Internet [Wyjaśniany] Koniec ZS12 [Zamkniety] [Zweryfikowany] Zmiana statusu epizootycznego Informacje o wprowadzaniu Błędy zasadnicze [Błedny] Zmiana stanu działalności utworzenie dokumentu kancelaryjnego A1.2, A3.1, A5.2, A12.1, A13.1, A.14.2, A15.2, A16.1, A17.1 brak akceptacji [Wprowadzony] :WzSD [Wprowadzony] :WzSE [Wprowadzony] A5.3. Odmowa A4.2, A10.2, A11.2, A12.2, A13.2, A14.3, A15.3, A16.2, A17.2 :OdmowaRSS [Zatwierdzony] :WzSD :WzSE [Zatwierdzony] [Zatwie An 3. Zatwierdzenie zmiana statu epizootyczneg lub stanu działalności kolejna siedziba pod jednym adresem Koniec Potwierdzenie zmiany stanu działalności

Transformacje perspektywy biznesowej Szereg A(C S U) act FSB Diagram Class Diagram Class A (Opinion) Class B (Request) Class C (Reply) Customer Partition 2 (Clerk) Partition A (Opinion) AvCh 3. Creating Opinion Av<<data>>Cf :Class A (Opinion) [Creating] 5. Archiv ing Opinion «trace» Ap V Cc AnCn «trace» FSB UML Diagram Partition B (Request) 1. Creating Request Start :Class B (Request) [Creating] :Class B 2. Checking (Request) Request [Checking] 7. Archiv ing Request «trace» Partition C (Reply) Receiv ing Reply Final :Class C (Reply) [Sending] AvUu 8. Creating 10. Sending Reply Reply UseCase Diagram UC2. Creatng opinion UC1. Checking request «trace» UC6. Sending Clerk reply Partition 1 (Supervisor) :Class A (Opinion) [Approving] 4. Approv ing Opinion :Class B (Request) [Approving] 6. Approv ing Request :Class C :Class C Ap (Reply) (Reply) H vun [Creating] [Approving] 9. Approv ing Reply Ap H Ua «trace» Superv isor UC4. Creating reply UC5. Approv ing reply UC3. Approv ing case StateMachine Diagram StateMachine Diagram StateMachine Diagram AiSs Initial A.SM1 An (Creating) I St Initial B.SM1 (Checking) Initial C.SM1 (Creating) C.SM2 (Approv ing) A.SM2 (Approv ing) B.SM2 (Approv ing) C.SM3 (Sending) Final Final Final

Transformacje perspektywy biznesowej Szereg A(C S U) systemu e-irz uc Zgłoszenie siedziby stada Business Process Rejestracja siedziby stada e-irz ARiMR UC1.12. Rejestracja wchodzącego dokumentu kancelaryjnego Kierownik BP Pracownik BP ds. IRZ Start 1. Powiązanie ze sprawą UC1.8. Weryfikacja decyzji o rejestracji siedziby stada Koniec UC1.11. Pobranie danych z Rejestru Kancelaryjnego «common» UC1.1. Określenie sprawy UC1.21. Zamknięcie zgłoszenia siedziby stada A6.3. Weryfikacja decyzji o rejestracji siedziby stada UC1.13. Aktualizacja danych sprawy UC1.2 Powiązanie ze sprawą A1.3. Postępowanie decyzja wyjaśniające Kierownika nowy wniosek do rejestracji nowy wniosek A2.3. Powiadomienie Producenta UC1.3. Wprowadzanie danych KnM Koniec Zgłosznie zwierzęce 2. Wprowadzenie danych Błędy oczywiste Błędy zasadnicze UC1.6. Postępowanie wyjaśniające UC1.7. Powiadomienie Producenta UC1.15. Kontrola zgłoszenia SS UC1.14. Aktualizacja rejestru zgłoszeo siedzib stad brak akceptacji UC1.10. Odmowa A5.3. Odmowa UC1.19. Rejestracja wychodzącego dokumentu kancelaryjnego UC1.23. Odmowa rejestracji zgłoszenia UC1.24. Wprowadzanie danych - dokumenty elektroniczne 3. Zatwierdzenie zmiana statusu epizootycznego lub stanu działalności kolejna siedziba pod jednym adresem Koniec Anulowanie UC1.18. Anulowanie zgłoszenia UC1.20. Aktualizacja rejestrów zaświadczeo siedzib stad A4.3. Anulowanie UC1.4. Zatwierdzenie Ap H Ua A18.3. Akceptacja UC1.5. Wydanie dokumentów 4. Wydanie dokumentów UC1.16. Aktualizacja Pracownik BP ds. rejestrów IRZ IRZ Posiadacz zwierząt/producent UC1.17. Anulowanie dokumentu «external» kancelaryjnego Kancelaria Kierownik BP UC1.2 Powiązanie ze sprawą UC1.12. Rejestracja wchodzącego dokumentu kancelaryjnego UC1.7. Koniec Powiadomienie Producenta UC1.3. Wprowadzanie danych UC1.22. Akceptacja zgłoszenia UC1.9. UC1.15. Akceptacja Kontrola zgłoszenia SS dokumenty elektroniczne UC1.22. Akceptacja UC1.9. Akceptacja zgłoszenia UC1.10. Odmowa UC1.5. Wydanie dokumentów UC1.4. Zatwierdzenie «in UC1.17. Anulowanie UC1.16. dokumentu rejes kancelaryjnego UC1.13. Aktualizacja danych sprawy UC1.18. Anulowanie zgłoszenia «common» UC1.1. Określenie sprawy UC1.20. Aktualizacja rejestrów zaświadczeo siedzib stad UC1.14. Aktualizacja rejestru zgłoszeo siedzib stad UC1.19. Rejestracja wychodzącego dokumentu kancelaryjnego UC1.23. Odmowa rejestracji zgłoszenia UC1.6. Postępowanie wyjaśniające UC1.11. Pobranie danych z Rejestru Kancelaryjnego UC1.24. Wprowadzanie danych - dokumenty elektroniczne «inclu UC1.21. Zamknięcie zgłoszenia siedziby stada «inclu UC1.8. Weryf decyzji o reje siedziby st

Transformacje perspektywy biznesowej Szereg A(C S U) systemu e-irz act Szereg AC Rejestr DziałekRejestr Rejestr Ewidencyjnych Pełnomocników - Producentów - - LPIS EP EP Rejestr Decyzji :PLW PLW [Zarejestrowany] dane Rejestr Rejestr SiedzibStadZwierząt status epizootyczny Rejestr Postępowao [Wprowadzony] Rejestr Zakazów Sądowych Model Dziedziny::SiedzibaStada - CzyWynajem :boolean - nrgiw :String - NumerRzezni :String - numersiedzibystada :String - opislokalizacji :String - UprawnieniaBydlo :Boolean - UprawnieniaKozy :String - UprawnieniaOwce :String - UprawnieniaSwinie :Boolean - typdzialanosci :int - statusepizootyczny :int - standzialalnosci :int - datarejestracji :int «external» Model Dziedziny::DokumentKancelaryjny - nrdokumentu :char - datawplywu :Data - typdokumentu :typdokumentu - sposob :int - datastempla :Data - adnotacja :char - datarejestracji :Data - datasystemu :Data - RWA :char [Zarejestrowany] :WzSD [Zarejestrowany] :WzSE [Zarejestrowany] :OPr [Zarejestrowany] [Wyjaśniony] [Zweryfikowany] błędy Rejestr Błędów 2. Wprowadzenie danych dane nowy dokument Rejestr Rejestr Oświadczeo Dokumentów Wchodzących :WzSD dane[wprowadzony] :WzSE [Wprowadzony] [Błedny] [Wyjaśniany] Rejestr Zgłoszeo Siedzib Stad AiCc Model Dziedziny::Zwierze - numeridentyfikacyjny :String - dataurodzenia :Date - liczbazwierzat :int - gatunek :String - plec :String - dataopuszczeniastada :java.util.date - dataprzybyciadostada :java.util.date - czasprzebywaniawstadzie :int - status :int - statusepizootyczny :int - lokalizacja :Lokalizacja zwierzęcia matka, dawczyni, dawca Model Dziedziny:: ZgloszenieSiedzibyStada - cel :char - numeridentyfikacyjny :char - typdzialalnosci :char - Zglaszajacy :int - Siedziba :char - Adres :char - Dzialka :char - datazgloszenia :int - podpis :boolean - typwnioskuepi :char - dataodblokady :Data - datadoblokady :Data - przyczynaepi :char - przyczynadzi :char - datadziod :Data - datadzido :Data - standzi :char

Transformacje perspektywy biznesowej Szereg A(C S U) systemu e-irz act Szereg AS Rejestr DziałekRejestr Rejestr Ewidencyjnych Pełnomocników - Producentów - - LPIS EP EP Rejestr Zakazów Sądowych Rejestr Decyzji :PLW PLW [Zarejestrowany] [Zarejestrowany] :WzSD [Zarejestrowany] :WzSE [Zarejestrowany] :OPr [Zarejestrowany] dane 2. Wprowadzenie danych Rejestr Rejestr SiedzibStadZwierząt status epizootyczny [Wprowadzony] :WzSD dane[wprowadzony] :WzSE [Wprowadzony] [Błedny] Rejestr Postępowao Rejestr Zgłoszeo Siedzib Stad Błędny Initial Zarejestrowany Wprowadzony Akceptowany Anulowany Zaakceptowany Wyjaśniany Zapisany Wyjaśniony Zweryfikowany Zatwierdzony Zamkniety [Wyjaśniony] [Zweryfikowany] błędy Rejestr Błędów dane nowy dokument Rejestr Rejestr Oświadczeo Dokumentów Wchodzących [Wyjaśniany] AiSs Final Zakonczony

Transformacje perspektywy biznesowej Szereg X(B R)A(C S U) - Z(J T Y) - QMD Struktura {S} perspektywa: systemowa komponentowa XeRe<<subevent>>Ap V?Cc ZiJc QlMqDw Xi<<product>>Ri<<subproduct>>Ap V Cc ZiJc QlMqDw Xvi<<product>>Rvi<<subproduct>>An O Cn Zn O Jn QmMyDn Xev<<process>>Rv<<subprocess>>AvCh ZvJh QmMyDn Xev<<process>>BnAp H vch ZvJh QmMyDn Xvi<<repository>>Rv<<data>>Av<<data>>Cf Zv<<data>>Jf QmMyDn Xv<<data>>Bu<<data>>Av<<data>>Cf Zv<<data>>Jf QmMyDn Funkcjonalność {F} Xei<<rules>>v<<process>>BuAvUu ZvYu QlMqDw Xei<<rules>>i<<product>>BaAp H Ua Zp V Ya Ql 1 MyDn Xev<<process>>BnApHvUn Zp V vyn Ql 1 MyDn Behawioryzn {B} Xei<<product>>Rei<<subproduct>>Ai STATE Ss ZiTs QoMyDn Xvi<<product>>Rvi<<subproduct>>An I St ZnTt QmMyDn XeReAp V 1St ZnTt QmMyDn Xi<<product>>Ri<<subproduct>>Ap V St ZnTt QmMyDn

Podsumowanie 1 Automatyczna budowa systemów informatycznych możliwa jest przy spełnieniu warunków: istnieje uporządkowany szereg spójnych diagramów pogrupowanych w perspektywy każdy model danej perspektywy posiada kompletny opis w zakresie funkcjonalności, zachowania i struktury każdy diagram w szeregu jest wewnętrznie spójny wszystkie diagramy spełniają reguły spójności w postaci transformacji elementów pomiędzy diagramami

Podsumowanie 2 Zaprezentowanie metodyki budowy systemu informatycznego, za pomocą uporządkowanego szeregu spójnych diagramów projektowych UML, pozwoli na określenie możliwości jej wdrożenia, bezpieczeństwa wytwarzania oprogramowania, automatyzacji, uzasadnienie i predykcję czasu wytworzenia systemu. Przedstawienie systemu informatycznego za pomocą uporządkowanego szeregu spójnych diagramów projektowych UML od diagramu kontekstowego do modelu implementowalnego umożliwi automatyczne wytwarzanie oprogramowania z modeli budowanych w sposób niewymagający wiedzy programistycznej obecnie brak takich rozwiązań Brak przedstawienia architektury systemu IT za pomocą szeregu uporządkowanych diagramów UML znacznie zwiększa ryzyko niepowodzenia wdrożenia systemu IT

Pytania? Dziękuję za uwagę www.project-media.pl