Zastosowanie reguł spójności w modelowaniu
Transkrypt
Zastosowanie reguł spójności w modelowaniu
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 Egyed 2000 Sapna 2007 Ibrahim 2012 Ha 2008 Shinkawa 2008 Chanda 2009 Hausmann 2002 Sequence of diagrams P(CQ|CO|CS) C(S|U(A|Q)) UQC O(Q|A|I) UAQS UAC UAO Number of consistency rules 50 18 8 7 4 4 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 q-komponent c-klasa y-interface e-zdarzenie w-urządzenie/węzeł f-atrybut x-klasyfikator h-metoda n-związek i-instancja Niektóre stereotypy: v<<start>> v<<data>> v<<process>> l-lifeline m-komunikat o-occurence p-partycja s-stan t-przejście stanów u-przypadek użycia v-czynność Przykład reguły dla B: u{1}[a1-aN] albo Bu{1}[a1-aN] Przykład ogólnej reguły dla BA: BaApHUa 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. Szereg uporządkowanych diagramów Kompletny i spójny opis architektury oprogramowania stom Diagrams Sequence Business view {X} Context Diagram: Activ ity Diagram «derive» «derive» {R} Decomposition Process Diagram: Activ ity Diagram {B} Business Use Case Diagram: Use Case Diagram «derive» XFSB(RSB|BF )AFSB(CS|SB|UF ) 1..* «generated» «derive» «generated» «generated» {C} Business Obj ect Diagram: Class Diagram {U} System Use Case Diagram: Use Case Diagram «derive» System view UF ZFSB(JS|TB|YF ) 1..* {A} FSB UML Business Diagram: Activ ity Diagram «InformationDependency» 1..* {Z} FSB UML System Diagram: Activ ity Diagram «generated» {Y} Internal Use Case Diagram: Use Case Diagram «derive» Component view «InformationDependency» YF QFSBMFSBDFSB «InformationDependency» «generated» «generated» {J] System Obj ect Diagram: Class Diagram {S} Business Obj ect Behav iour Diagram: State Machine Diagram {T} System Obj ect Behav iour Diagram: State Machine Diagram 1..* {Q} FSB UML Component Diagram: Sequence Diagram «derive» {M} Component Diagram: Component Diagram «derive» {D} Deployment Diagram: Deployment Diagram XFSB(RSB|BF )AFSB(CS|SB|UF )ZFSB(JS|TB|YF )QFSBMFSBDFSB «InformationDependency» Transformacje perspektywy biznesowej Szereg XR: XFSB(RFSB|BF)AFSB(CS|SB|UF) Reguły kompletności diagramu kontekstowego: Reguły kompletności diagramu dekompozycji procesów: {B} Rv<<subprocess>>+; {F} {B} Xv<<process>>{1}; Xi<<rule>>+; {F} Xe+; Re<<subevent>>+; {S} Ri<<subproduct>>+; {S} Xi<<product>>+; Xi<<datastore>>+ analysis Context2Decomposition Context Diagram Decomposition Diagram XeRe<<subevent>> decomposition into Product 1.2 decomposition into Product 1.1 decomposition into Subprocess 1 decomposition into Event 1.1 decomposition into Subprocess 2 decomposition into Event 1.2 Business rules Event 1.1 Subprocess 1 Product 1.1 Xev<<process>>{1}R[v1<<subprocess>>-v2<<subprocess>>] decomposition into Subprocess 1 Event 1 Event 1.2 Product 1 Event 2 Main Process Subprocess 2 Product 2 decomposition into Subprocess 2 Product 2 Event n decomposition into Product 2 Repository decomposition into Subprocess n Event n Subprocess n decomposition into Event n decomposition into Subprocess n Xi<<rules>>v<<process>>{1}i<<product>>Ri<<subproduct> Product 1.2 Transformacje perspektywy biznesowej Szereg XR dla systemu e-IRZ act Szereg XR Xi(Informacje o kontrolach na miejscu)Ri(Raport z kontroli) XeRe<<subevent>> ha rmogra m kontrol i ma s owe typowa ni e ra port z kontrol i Di a gra m dekompozycji proces ów Raport z kontroli na miejscu :Raport z kontroli [Za twi erdzony] wymóg wza jemnej zgodnoś ci :WzSE [Za twi erdzony] Zgłos zeni e s i edzi by s tada decyzja PLW pi s mo PLW Di a gra m konteks towy Ra port z kontrol i Regulacje UE, krajowe oś wi a dczeni e Producenta IRZ Xe(Zgłoszenie siedziby stada)v(IRZ){1}Rv(Zgłoszenie siedziby stada) Tra ns fer zwi erząt Informacje o zwierzętach Zgłos zeni e przemi es zczeni a Zgłos zeni e utyl i za cji Zgłos zeni e rejes tra cji Informacje o identyfikatorach Xe(Zgłoszenie zwierzęce)v(IRZ){1}Rv(Zgłoszenie zwierzęce) «za s ób» Repozytorium «za s ób» Zasoby a ktua l i za cja s tanu dzi a ła l noś ci pi s mo Producenta Informacje o kontrolach na miejscu Informacje o posiadaczach i siedzibach stad Za potrzebowa ni a IRZ Za pytani e o da ne :ZaswRSS [Wyda ny] Xev<<process>>{1}R[v1<<subprocess>>-v5<<subprocess>>] Zgłos zeni e s i edzi by s tada Zgłos zeni e zwi erzęce Zgłoszenie siedziby stada Zgłos zeni e wyrejes trowa ni a :Pass [Wyda ny] Zgłoszenie zwierzęce wydruk dupl i ka tu zda rzeni a pa s zportu a ktua l i zujące ś l edzeni e wykorzys tani a pul i i dentyfi ka torów pul a kol czyków dupl i ka t pa s zportu pul a dupl i ka tów kol czyków :WzSD [Za twi erdzony] Zapotrzebowania IRZ numer dl a drugi ego kol czyka :Prz [Wyda ny] :Wyr [Wyda ny] :Pula [Wyda ny] :Kol [Wyda ny] Xe(Zapytanie o dane)v(IRZ){1}Rv(Udostępnianie danych) Za pytani e o da ne Udostępnianie danych 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: XFSB(RFSB|BF)AFSB(CS|SB|UF) Reguły kompletności diagramu kontekstowego: {B} Xv<<process>>{1}; Xi<<rule>>+; {F} Xe+; {S} Xi<<product>>+; Xi<<datastore>>+ Reguły kompletności diagramu biznesowych przypadków użycia: {F} Bu+; Ba+ analysis Context2BuseCases Context Diagram UseCase Diagram XeBu XeBa UC1. Subprocess 1 Business rules «business actor» Actor1 Event 1 Product 1 Event 2 Main Process UC2. Subprocess 2 Product 2 «business actor» Actor2 Xi<<product>>Ba Event n Xi<<rules>>v<<process>>Bu Repository UCn. Subprocess n «business actor» Actorn Transformacje perspektywy biznesowej Szereg XB dla systemu e-IRZ act Szereg XB XeBa Di a gra m bi znes owych przypa dków użyci a Ra port z kontrol i Di a gra m konteks towy Xe(Zapotrzebowania IRZ)v(IRZ){1}Bu(Zapotrzebowania IRZ) Regulacje UE, krajowe Informacje o kontrolach na miejscu Zgłos zeni e s i edzi by s ta da IRZ Zgłos zeni e zwi erzęce Informacje o zwierzętach UC3. Zapotrzebowania za potrzebowa ni a IRZ Dostawca kolczyków a kcepta cja , decyzje Informacje o posiadaczach i siedzibach stad Za potrzebowa ni a IRZ Za pyta ni e o da ne Sys tem IRZ TO-BE rea l i za cja za mówi eni a UC2. Zgłoszenie zwierzęce UC4. Raport z kontroli Informacje o identyfikatorach «za s ób» Repozytorium «za s ób» Zasoby Posiadacz zgła s za zwierząt zda rzeni a i zmi a ny generuje, drukuje, wprowa dza , za twi erdza Pracownik IW Pracownik ARiMR Xev<<process>>Bu UC1. Zgłoszenie siedziby stada UC5. Udostępnianie danych rejes truje s i edzi by s ta d Xe(Zapytanie o dane)v(IRZ){1}Bu(Udostępnianie danych) Producent Transformacje perspektywy biznesowej Szereg RA: XFSB(RFSB|BF)AFSB(CS|SB|UF) analysis Decomposition2FSBModel Re<<subevent>>Ap<<vertical>> {A} BPMN Process Diagram - UC1. Subprocess 1 «Lane» Request 1 Decomposition Diagram Event 1.1 Subprocess 1 Start «Lane» Partition1.1 Re<<subevent>>Ap<<horizontal>>+ Rv<<subprocess>A «Lane» Product 1 1.1. Task1 Request 1 [Received] Product 1.1 Ri<<subproduct>>Ap<<vertical>> Event n Subprocess 2 Subprocess n Product 2 Product1 [Created] 1.3. Task 3 Request 1 [Approved] Product1 [Verified] Product 1.2 «Lane» Partition1.3 Event 1.2 «Lane» Partition1.2 1.2. Task2 1.4. Task4 End Product1 [Approved] Transformacje perspektywy biznesowej act System IRZ - dekompozycja procesu głównego ha rmogra m kontrol i Szereg RA dla systemu e-IRZ ma s owe typowa ni e Raport z kontroli na miejscu ra port z kontrol i :Raport z kontroli [Za twi erdzony] wymóg wza jemnej zgodnoś ci Re(decyzjaPLW) Ai(PLW) :WzSE [Za twi erdzony] Zgłos zeni e s i edzi by s ta da act Szereg RA decyzja PLW Zgłoszenie siedziby stada Business Process Rejestracja siedziby stada Producent pi s mo PLW :ZaswRSS [Wyda ny] oś wi a dczeni e Producenta zgłos zeni e dokumentu pa pi erowego wypełni eni e os ku przez a wni ktua l i za cja Internet pi s mo Producenta powi a domi eni e System Kancelaryjny Producenta :WzSD [Za twi erdzony] Informa cje o wprowa dza ni u s ta nu dzi a ła l noś ci Tra ns fer zwi erząt Ri(ZaswRSS) Ai(ZaswRSS) Informa cje o za twi erdzeni u :Pass [Wyda ny] Rv(Zgłoszenie siedziby stada)A(BPMN) Zgłos zeni e Zgłoszenie pobra ni e przemi es zczeni a :Prz rejes tra cja rejes tra cja utworzeni e numeru zgłos zeni e Wezwa ni e zwierzęce pi s ma ze pi s ma z wyja ś ni eni a dokumentu dokumentu powi a domi eni e dokument [Wyda ny] dokumentu producenta do s tanowi s ki em Zgłos zeni e utyl i za cji pytani em ka ncel a ryjnego el es ktroni czny pa pi erowego pa pi erowego wyja ś ni eniProducenta a PLW do PLW rejes tra cja dokumentu Zgłos zeni e rejes tra cji :Wyr Start zdaA3.1, rzeni aA4.2, A10.2, ka ncel a ryjnego A1.2, [Wyda ny] Zgłos zni e :ZS12 A5.2, A12.1, a ktua l i zujące A11.2, A12.2, :WzSD :WzSE KnM zwi erzęce [Za rejes trowa ny] Zgłos zeni e A13.1, A.14.2, A13.2, A14.3, [Za twi erdzony] :WzSE [Za twi erdzony] wydruk A15.2, A16.1, A15.3, A16.2, wyrejes trowa [Za rejes trowani ny]a ś l edzeni e Anul owa ni e A17.1 A17.2 dupl i ka tu Pracownik BP ds. IRZ 1. Powi ąza ni e ze s pra wą ARiMR pa s zportu pul a kol czyków :WzSD [Za rejes trowa ny] i dentyfi ka torów dupl i ka t pa s zportu A1.1, A5.1, A14.1, A15.1 :PLW [Za rejes trowa ny] Zapotrzebowania IRZ pul a dupl i ka tów kol czyków numer:ZS12 dl a drugi ego [Wyja ś ni ony] kol czyka wykorzys ta ni a pul i 2. Wprowa dzeni e da nych A2.2, A6.2 A1.3. Pos tępowa ni e wyja ś ni a jące Za pytadecyzja ni e o da ne nowy Ki erowni ka wni os ek Błędy oczywi s te :ZS12 [Wyja ś ni a ny] :ZS12 [Wprowa dzony] Udostępnianie danych :WzSD [Wprowa dzony] Koni ec :OPr [Za rejes trowa ny] A7.2, :ZS12 [Za pi s a ny] A2.3. Powi a domi eni e Producenta :WzSE [Wprowa dzony] A4.3. Anul owa ni e :ZS12 [Anul owa ny] utworzeni e dokumenty ka ncel a ryjnego A4.4, A5.4, A10.3, A18.4 Koni ec 3. Za:Pula twi erdzeni e [Wyda ny] bra k a kceptacji Błędy za s a dni cze a nul owa ni e dokumentu ka ncel a ryjnego :Kol zmi a nany] s tatus u [Wyda epi zootycznego l ub s tanu dzi a ła l noś ci kol ejna sInformacje i edzi ba IRZ pod jednym a dres em Koni ec 4. Wyda ni e dokumentów :ZS12 [Za twi erdzony] :Za s wRSS [Za twi erdzony] :ZS12 :ZS12 [Za a kceptowa ny] [Akceptowa ny] :Odmowa RSS [Wyda na ] Transformacje perspektywy biznesowej Szereg BA: XFSB(RFSB|BF)AFSB(CS|SB|UF) Reguły kompletności diagramu biznesowych przypadków użycia: Bu{1}a+; Ba{1}u+ Reguły spójności diagramu A: Av<<start>>[v+|i+]v<<stop>> analysis BUseCase2FSBDiagram UseCase Diagram Business FSB UML Diagram - UC1. Subprocess 1 Request 1 BaApH Product 1 UC1. Subprocess 1 BuA Partition 1.1 Start1 «business actor» Actor1 1.1. Activ ity :Request 1 [Received] Annotation 1.2. Activ ity :Product 1 Partition 1.2 [Created] :Request 1 1.3. Activ ity [Approved] :Product 1 [Verified] 1.4. Activ ity Partition 1.3 tags Actor = Description = Event = Postcondition = Precondition = Scenario = State = UObject = :Product 1 [Approved] Final1 Transformacje perspektywy biznesowej Szereg BA systemu e-IRZ act Szereg BA Ba(Producent)ApH(Producent) Producent Business Process Rejestracja siedziby stada zgłos zeni e dokumentu pa pi erowego Sys tem IRZ TO-BE UC3. Zapotrzebowania za potrzebowa ni a IRZ UC2. Zgłoszenie zwierzęce UC4. Raport z kontroli Posiadacz zgła s za zwierząt zda rzeni a i zmi a ny generuje, drukuje, wprowa dza , za twi erdza Pracownik IW Pracownik ARiMR UC1. Zgłoszenie siedziby stada Informa cje o wprowa dza ni u pobra ni e rejes tra cja rejes tra cja numeru zgłos zeni e Wezwa ni e pi s ma ze pi s ma z wyja ś ni eni a powi a domi eni edokument dokumentu dokumentu do s tanowi s ki em pytani emproducenta el es ktroni czny pa pi erowego pa pi erowego wyja ś ni eniProducenta a PLW do PLW rejes tra cja dokumentu Start ka ncel a ryjnego Zgłos zni e :ZS12 KnM zwi erzęce [Za rejes trowa ny] :WzSE [Za rejes trowa ny] utworzeni e dokumentu ka ncel a ryjnego A1.2, A3.1, A5.2, A12.1, A13.1, A.14.2, A15.2, A16.1, A17.1 UC5. Udostępnianie danych rejes truje s i edzi by s ta d Ba(Pracownik ARiMR)ApH(ARiMR) :WzSD [Za rejes trowa ny] 1. Powi ąza ni e ze s pra wą Producent Pracownik BP ds. IRZ Dostawca kolczyków a kcepta cja , decyzje ARiMR rea l i za cja za mówi eni a wypełni eni e wni os ku przez Internet powi a domi eni e Producenta System Kancelaryjny Di a gra m bi znes owych przypa dków użyci a 2. Wprowa dzeni e da nych A2.2, A6.2 :ZS12 [Wyja ś ni ony] A1.3. Pos tępowa ni e wyja ś ni a jące decyzja nowy Ki erowni ka wni os ek :PLW [Za rejes trowa ny] :ZS12 [Za pi s a ny] do rejes tra cji Kierownik BP A6.3. Weryfi ka cja decyzji o rejes tra cji s i edzi by s tada Koni ec s tanowi s ko PLW PLW/Organy Ba(Pracownik IW)ApH(PLW) Błędy oczywi s te Błędy za s a dni cze :ZS12 [Wprowa dzony] :ZS12 [Wyja ś ni a ny] :WzSD [Wprowa dzony] Koni ec A7.2, A8.2, A9.2 :ZS12 [Za konczony] 3. Za twi erdzeni e bra k a kceptacji A1.1, A5.1, A14.1, A15.1 :OPr [Za rejes trowa ny] Bu(Zgłoszenie siedziby stada)A(BPMN) A4.2, A10.2, A11.2, A12.2, :WzSD :WzSE A13.2, A14.3, [Za twi erdzony] [Za twi e A15.3, A16.2, An A17.2 za pytani e o s tanowi s ko A2.3. Powi a domi eni e Producenta A7.3 nowy wni os ek zmi a na s tatu epi zootyczneg l ub s tanu dzi a ła l noś ci kol ejna s i edzi ba pod jednym a dres em Koni ec :WzSE [Wprowa dzony] ZS12 [Za mkni ety] :ZS12 [Błedny] :ZS12 [Zweryfi kowa ny] Zmi a na s tatus u epi zootycznego :Odmowa RSS [Za twi erdzony] A5.3. Odmowa Zmi a na s tanu dzi a ła l noś ci Potwi erdzeni e zmi a ny s tanu dzi a ła l noś ci Transformacje perspektywy biznesowej Szereg A(C|S|U) act FSB Diagram Class Diagram Class A (Opinion) Class C (Reply) Class B (Request) «trace» «trace» «trace» FSB UML Diagram Customer Partition A (Opinion) Partition B (Request) ApVCc AnCn AvCh Av<<data>>Cf Partition 2 (Clerk) 3. Creating Opinion Partition C (Reply) 1. Creating Request Receiv ing Reply Start Fi nal :Class B (Request) [Creati ng] :Class B (Request) [Checki ng] :Class C (Reply) [Sendi ng] UseCase Diagram 2. Checking Request UC2. Creatng opinion AvUu :Class A (Opinion) [Creati ng] UC1. Checking request «trace» Clerk 5. Archiv ing Opinion 7. Archiv ing Request 8. Creating Reply 10. Sending Reply :Class A (Opinion) [Approvi ng] :Class B (Request) [Approvi ng] :Class C (Reply) [Creati ng] :Class C (Reply) [Approvi ng] UC6. Sending reply Partition 1 (Supervisor) UC4. Creating reply 4. Approv ing Opinion Ini ti al StateMachine Diagram Ini ti al AnISt StateMachine Diagram Ini ti al C.SM1 (Creating) B.SM1 (Checking) A.SM1 (Creating) C.SM2 (Approv ing) A.SM2 (Approv ing) Fi nal UC5. Approv ing reply 9. Approv ing Reply ApHUa StateMachine Diagram AiSs 6. Approv ing Request ApHvUn B.SM2 (Approv ing) C.SM3 (Sending) Fi nal Fi nal «trace» Superv isor UC3. Approv ing case Transformacje perspektywy biznesowej Szereg A(C|S|U) systemu e-IRZ uc Zgłoszenie siedziby stada e-IRZ Business Process Rejestracja siedziby stada «i nterna l » «i ncl ude» UC1.15. Kontrola zgłoszenia SS «i ncl ude» «i nterna l » UC1.12. Rejestracja wchodzącego dokumentu kancelaryjnego «i nterna l » UC1.11. Pobranie danych z Rejestru Kancelaryjnego «i ncl ude» «i nterna l » UC1.13. Aktualizacja danych sprawy UC1.3. Wprowadzanie danych «i ncl ude» «i ncl ude» «i ncl ude» «i ncl ude» «i ncl ude» Sta rt KnM «common» UC1.1. Określenie sprawy Zgłos zni e zwi erzęce UC1.4. Zatwierdzenie «i nterna l » UC1.19. Rejestracja wychodzącego dokumentu kancelaryjnego «i nterna l » UC1.14. Aktualizacja rejestru zgłoszeo siedzib stad UC1.5. Wydanie dokumentów «i ncl ude» «i ncl ude» «i nterna l » UC1.20. Aktualizacja rejestrów zaświadczeo siedzib stad «i nterna l » «i ncl ude» UC1.24. Wprowadzanie danych - dokumenty elektroniczne A4.3. Anul owa ni e UC1.2 Powiązanie ze sprawą Anul owa ni e Pracownik BP ds. IRZ Błędy Błędy oczywi s te za s a dni cze «i nterna l » UC1.23. Odmowa rejestracji zgłoszenia A1.3. Pos tępowa ni e wyja ś ni a jące «i nterna l » UC1.21. Zamknięcie zgłoszenia siedziby stada decyzja Ki erowni ka nowy wni os ek UC1.6. Postępowanie wyjaśniające «i ncl ude» «i ncl ude» Koni ec A2.3. Powi a domi eni e Producenta UC1.8. Weryfikacja decyzji o rejestracji siedziby stada UC1.10. Odmowa do rejes tra cji A6.3. Weryfi ka cja decyzji o rejes tra cji s i edzi by s ta da Koni ec «i ncl ude» «i n UC1.16. rejes «i ncl ude» «i nterna l » UC1.18. Anulowanie zgłoszenia «common» UC1.1. Określenie sprawy «i ncl ude» «i nterna l » UC1.11. Pobranie danych z Rejestru Kancelaryjnego «i ncl ude» UC1.6. Postępowanie wyjaśniające «i ncl ude» 4. Wyda ni e dokumentów bra k a kcepta ude» «i nclcji «i ncl ude» Kierownik BP ARiMR 3. Za twi erdzeni e «i ncl ude» «i nterna l » ude» Rejestracja «i nclUC1.12. wchodzącego dokumentu kancelaryjnego «i ncl ude» «i nterna l » UC1.13. Aktualizacja danych sprawy «i ncl ude» UC1.7. Koni ec Powiadomienie Producenta «i ncl ude» 2. Wprowa dzeni e da nych 1. Powi ąza ni e ze s pra wą UC1.2 Powiązanie ze sprawą «i nterna l » «i ncl ude» UC1.17. Anulowanie dokumentu kancelaryjnego «i ncl ude» UC1.5. Wydanie dokumentów «i nterna l » UC1.16. Aktualizacja Pracownik BP ds. rejestrów IRZ IRZ «i nterna l » UC1.19. Rejestracja wychodzącego dokumentu kancelaryjnego «i ncl ude» zmi a na s ta tus u epi zootycznego UC1.3. Wprowadzanie l ub s ta nu danych dzi a ła l noś ci kol ejna «i nterna l » «i ncl ude» s i edzi ba pod UC1.20. Aktualizacja «i nterna l » UC1.4. Zatwierdzenie jednym ude» ncl «i zaświadczeo rejestrów UC1.22. Akceptacja a dres em Posiadacz siedzib stad zgłoszenia «i nterna l » zwierząt/Producent Koni ec UC1.14. Aktualizacja «i ncl ude» «i ncl ude» rejestru zgłoszeo siedzib «i ncl ude» «i ncl ude» stad «i nterna l » «i nterna l » «i nterna l » Kontrola UC1.15. Akceptacja UC1.9. UC1.18. Anulowanie UC1.17. Anulowanie «i ncl ude» zgłoszenia SS zgłoszenia dokumentu «externa l » kancelaryjnego «i ncl ude» Kancelaria dokumenty «i ncl ude» «i ncl ude» «i ncl ude» «i nterna l » UC1.24. Wprowadzanie danych - dokumenty elektroniczne «i ncl u el ektroni czne UC1.7. Powiadomienie Producenta A18.3. Akcepta cja nowy wni os ek «i nterna l » UC1.22. Akceptacja UC1.9. Akceptacja «i ncl ude» zgłoszenia «i ncl ude» A5.3. Odmowa «i ncl ude» UC1.10. Odmowa Kierownik BP ApHUa «i nterna l » UC1.23. Odmowa rejestracji zgłoszenia «i nterna l » UC1.21. Zamknięcie zgłoszenia siedziby stada «i ncl u UC1.8. Weryf decyzji o reje siedziby st Transformacje perspektywy biznesowej Szereg A(C|S|U) systemu e-IRZ act Szereg AC «externa l » Model Dziedziny::DokumentKancelaryjny Model Dziedziny::SiedzibaStada Rejes tr Dzi a łekRejes tr Rejes tr ków Ewi dencyjnych Pełnomocni Producentów EP LPIS EP - Rejes tr Za ka zów Sądowych Rejes tr Rejes tr Rejes tr Si edzi bSta dZwi erząt Pos tępowa o s ta tus epi zootyczny Rejes tr Decyzji :PLW PLW [Za rejes trowa ny] da ne :ZS12 [Wprowa dzony] :ZS12 [Za rejes trowa ny] 2. Wprowa dzeni e da nych :WzSD [Za rejes trowa ny] :ZS12 [Wyja ś ni ony] błędy Rejes tr Błędów :ZS12 [Zweryfi kowa ny] da ne nowy dokument nrDokumentu :cha r da ta Wpl ywu :Da ta typDokumentu :typDokumentu s pos ob :i nt da ta Stempl a :Da ta a dnota cja :cha r da ta Rejes tra cji :Da ta da ta Sys temu :Da ta RWA :cha r Model Dziedziny:: ZgloszenieSiedzibyStada Rejes tr Zgłos zeo Si edzi b Sta d ma tka , da wczyni , da wca :ZS12 [Błedny] :OPr [Za rejes trowa ny] - :WzSD da ne[Wprowa dzony] :WzSE [Wprowa dzony] :WzSE [Za rejes trowa ny] CzyWyna jem :bool ea n nrGIW :Stri ng NumerRzezni :Stri ng numerSi edzi bySta da :Stri ng opi s Loka l i za cji :Stri ng Upra wni eni a Bydl o :Bool ea n Upra wni eni a Kozy :Stri ng Upra wni eni a Owce :Stri ng Upra wni eni a Swi ni e :Bool ea n typDzi a l a nos ci :i nt s ta tus Epi zootyczny :i nt s ta nDzi a l a l nos ci :i nt da ta Rejes tra cji :i nt Model Dziedziny::Zwierze :ZS12 [Wyja ś ni a ny] Rejes tr Rejes tr Oś wi a dczeo Dokumentów Wchodzących AiCc - numerIdentyfi ka cyjny :Stri ng da ta Urodzeni a :Da te l i czba Zwi erza t :i nt ga tunek :Stri ng pl ec :Stri ng da ta Opus zczeni a Sta da :ja va .uti l .Da te da ta Przybyci a DoSta da :ja va .uti l .Da te cza s Przebywa ni a WSta dzi e :i nt s ta tus :i nt s ta tus Epi zootyczny :i nt l oka l i za cja :Loka l i za cja zwi erzęci a - cel :cha r numerIdentyfi ka cyjny :cha r typDzi a l a l nos ci :cha r Zgl a s za ja cy :i nt Si edzi ba :cha r Adres :cha r Dzi a l ka :cha r da ta Zgl os zeni a :i nt podpi s :bool ea n typWni os kuEpi :cha r da ta OdBl oka dy :Da ta da ta DoBl oka dy :Da ta przyczyna Epi :cha r przyczyna Dzi :cha r da ta Dzi Od :Da ta da ta Dzi Do :Da ta s ta nDzi :cha r Transformacje perspektywy biznesowej Szereg A(C|S|U) systemu e-IRZ act Szereg AS Rejes tr Dzi a łekRejes tr Rejes tr ków Ewi dencyjnych Pełnomocni Producentów EP LPIS EP Rejes tr Za ka zów Sądowych Ini ti a l Rejes tr Rejes tr Rejes tr Si edzi bSta dZwi erząt Pos tępowa o s ta tus epi zootyczny Rejes tr Decyzji :PLW PLW [Za rejes trowa ny] da ne :ZS12 [Wprowa dzony] :ZS12 [Za rejes trowa ny] 2. Wprowa dzeni e da nych Wprowadzony Wyjaśniony Zapisany Błędny da ne[Wprowa dzony] :WzSE [Wprowa dzony] :WzSE [Za rejes trowa ny] Zweryfikowany Rejes tr Zgłos zeo Si edzi b Sta d błędy Rejes tr Błędów da ne nowy dokument :ZS12 [Wyja ś ni a ny] Rejes tr Rejes tr Oś wi a dczeo Dokumentów Wchodzących Akceptowany Anulowany Zatwierdzony Zaakceptowany :ZS12 [Błedny] :OPr [Za rejes trowa ny] :ZS12 [Zweryfi kowa ny] Wyjaśniany :WzSD :WzSD [Za rejes trowa ny] :ZS12 [Wyja ś ni ony] Zarejestrowany Zamkniety Zakonczony AiSs Fi na l Transformacje perspektywy biznesowej Szereg X(B|R)A(C|S|U) - Z(J|T|Y) - QMD Struktura {S} perspektywa: systemowa komponentowa XeRe<<subevent>>ApV?Cc ZiJc QlMqDw Xi<<product>>Ri<<subproduct>>ApVCc ZiJc QlMqDw Xvi<<product>>Rvi<<subproduct>>AnOCn ZnOJn QmMyDn Xev<<process>>Rv<<subprocess>>AvCh ZvJh QmMyDn Xev<<process>>BnApHvCh 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>>BaApHUa ZpVYa Ql1MyDn Xev<<process>>BnApHvUn ZpVvYn Ql1MyDn Behawioryzn {B} Xei<<product>>Rei<<subproduct>>AiSTATESs ZiTs QoMyDn Xvi<<product>>Rvi<<subproduct>>AnISt ZnTt QmMyDn XeReApV1St ZnTt QmMyDn Xi<<product>>Ri<<subproduct>>ApVSt 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