Stanisław Jerzy Niepostyn Instytut Informatyki, Wydział Elektroniki i Technik Informacyjnych,

1. Automatyzacja projektowania systemów informatycznych w środowisku BPM z zastosowaniem modelu FSB UML • Stanisław Jerzy Niepostyn • Instytut Informatyki, • Wydział Elektroniki i Technik Informacyjnych, • Politechnika Warszawska

2. Wprowadzenie • Tezy rozprawy • Możliwe jest formalne zdefiniowanie takiego uporządkowanego szeregu powiązanych diagramów UML, który umożliwiłby w sposób wystarczająco spójny i kompletny opisanie architektury oprogramowania systemu informatycznego od modelu opisującego kontekst biznesowy systemu, aż do modelu implementowalnego w środowisku BPM • Formalna semantyka zależności pomiędzy poszczególnymi elementami uporządkowanego szeregu powiązanych diagramów UML umożliwia wnioskowanie w zakresie zachowania spójności i kompletności opisu architektury oprogramowania

3. WprowadzenieWykazanie tez rozprawy Automatyzacja budowy systemów informatycznych z wykorzytaniem UML • sformułowanie warunków wystarczających do automatycznego wytwarzania modeli oprogramowania w postaci: • definicji wystarczającej spójności modeli architektury oprogramowania • definicji wystarczającej kompletności modeli architektury oprogramowania • definicji uporządkowanego szeregu modeli od najbardziej abstrakcyjnego do implementowalnego w konkretnym środowisku uruchomieniowym (np. BPM) • opracowanie uporządkowanego szeregu powiązanych diagramów UML opisujących architekturę oprogramowania od kontekstu działania systemu, do modeli implementowalnychumożliwiających automatyzację budowy systemu informatycznego w środowisku BPM • opracowanie transformacji kolejnych, powiązanych diagramów UML sterowanych regułami spójności i kompletności architektury oprogramowania • zdefiniowanie zbioru reguł zachowania spójności elementów między powiązanymi modelami (reguły transformacji, mapowania) • zdefiniowanie zbioru reguł zachowania spójności elementów wewnątrz modeli • zdefiniowanie zbioru reguł zachowania kompletności modeli Przedstawiona będzie metoda automatycznego projektowania systemów informatycznych w środowisku BPM z zastosowaniem autorskiego modelu FSB UML

4. Plan prezentacji • Architektura oprogramowania • Spójność i kompletność modeli UML • Reguły spójności modeli UML • Szereg uporządkowanych diagramów opartych na modelu FSB UML • 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

5. Architektura oprogramowania • Perspektywy i kompletność • Architektura składa się z wielu powiązanych modeli opisujących wybrane zagadnienia (ang. separation of concern – Hursh, Lopes1995 r.) • Uproszczony model perspektyw architektonicz-nych „4 + 1” (podstawa metodyki RUP-1998 r.): • Perspektywa biznesowa (scenariuszy), systemowa (projektowa), implementacyjna, wdrożeniowa • Każda perspektywa powinna opisywać trzy wymiary: • 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, subpakage - functionality)

6. Spójność modeli UML • 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.

7. Reguły spójności modeli UML • Szereg uporządkowanych diagramów UML • 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

8. Reguły spójności modeli UML • Oznaczenia elementów, wyrażenia regularne jako reguły • 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}[a1-aN] albo Bu{1}[a1-aN] Przykład ogólnej reguły dla BA: • BaApHUa • 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ść

9. 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)

10. 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

11. 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 (standard OMG UML wyznacza ogólną przynależność elementów UML do określonej grupy) • Warunek wystarczającej spójności • transformacje (mapowanie) pomiędzy poszczególnymi diagramami, od diagramu na najwyższym poziomie abstrakcji, aż do wynikowego kodu aplikacji, powinny spełniać reguły spójności według definicji Spanoudakis’a i Zisman’a, natomiast każdy diagram opisujący strukturę powinien być spójny zgodnie z definicją Berarrdi’ego, diagram opisujący behawioryzm powinien być spójny zgodnie z definicją Jurack’a, diagram opisujący funkcjonalność powinien być spójny zgodnie z definicją Hausmann’a.

12. Szereg uporządkowanych diagramów • Kompletny i spójny opis architektury oprogramowania

13. Transformacje perspektywy biznesowej • Szereg XR: XFSB(RFSB|BF)AFSB(CS|SB|UF) • Reguły kompletności diagramu dekompozycji procesów: {B} Rv<<subprocess>>+; {F} Re<<subevent>>+; {S} Ri<<subproduct>>+; • Reguły kompletności diagramu kontekstowego: • {B} Xv<<process>>{1}; Xi<<rule>>+; {F} Xe+; {S} Xi<<product>>+; Xi<<datastore>>+ • XeRe<<subevent>> • Xev<<process>>{1}R[v1<<subprocess>>-v2<<subprocess>>] • Xi<<rules>>v<<process>>{1}i<<product>>Ri<<subproduct>

14. Transformacje perspektywy biznesowej • Pseudo-kod reguł spójności szeregu diagramów XR • XeRe<<subevent>> : dekompozycja zdarzeń • METHOD createProcessDecomposition(contextDiagram, event) • FOR each event FROM contextDiagram TIMES event.Decomposition • CREATE subEvent WITH Name of Event(next free number) • END FOR • Xev<<process>>{1}R[v1<<subprocess>>-v2<<subprocess>>] : dekompozycja procesu gł. • METHOD createProcessDecomposition(contextDiagram, process) • FOR each event FROM contextDiagram TIMES event.Decomposition • CREATE subProcess WITH Name of Event(next free number) • CREATE objectFlow WITH subProcess&subEvent • END FOR • Xi<<rules>>v<<process>>{1}i<<product>>Ri<<subproduct>: dekompozycja produktów. • METHOD createProcessDecomposition(contextDiagram, product) • FOR each product FROM contextDiagram TIMES product.Decomposition • CREATE subProduct WITH Name of Product(next free number) • CREATE objectFlow WITH subProcess&subProduct&rules • END FOR

15. Transformacje perspektywy biznesowej • Inne reguły szeregu XR: XFSB(RFSB|BF)AFSB(CS|SB|UF) • XR1: XeRe<<subevent>> - dekompozycja zdarzeń • XR2: Xev<<process>>{1}R[v1<<subprocess>>-v2<<subprocess>>] - dekompozycja procesu głównego • XR3: Xi<<rules>>v<<process>>{1}i<<product>>Ri<<subproduct> - dekompozycja produktów. • Inne: • XR4: Xi<<product>>Ri<<subproduct>> - dekompozycja produktów • XR5: Xvi<<product>>Rvi<<subproduct>> - mapowanie związków czynność-instancja • XR6: Xvi<<datastore>>Rv<<data>> - mapowanie czynności w aspekcie danych

16. Transformacje perspektywy biznesowej • Szereg XB: XFSB(RFSB|BF)AFSB(CS|SB|UF) • Reguły kompletności diagramu biznesowych przypadków użycia: {F}Bu+; Ba+ • Reguły kompletności diagramu kontekstowego: • {B} Xv<<process>>{1}; Xi<<rule>>+; {F} Xe+; {S} Xi<<product>>+; Xi<<datastore>>+ • XeBu • XeBa • Xi<<product>>Ba • Xi<<rules>>v<<process>>Bu

17. Transformacje perspektywy biznesowej • Inne reguły szeregu XB: XFSB(RFSB|BF)AFSB(CS|SB|UF) • XB1: XeBu - mapowanie zdarzenia na przypadek użycia • XB2: XeBa - mapowanie zdarzenia na aktora • XB3: Xi<<product>>Ba - mapowanie produktu na aktora • XB4: Xi<<rules>>v<<process>>Bu - dekompozycja procesu na uc • Inne: • XB5: Xei<<rules>>v<<process>>Bu<<scenarios>> - dekompozycja procesu na czynności w scenariuszu • XB6: Xei<<rules>>i<<product>>Ba – mapowanie zdarzeń i produktów według reguł na aktorów • XB7: Xev<<process>>Bn - mapowanie związków zdarzenie-proces na ziązki aktor-przypadek użycia • XB8: Xv<<data>>Bu<<data>> - mapowanie czynności na przypadki użycia w aspekcie danych

18. Transformacje perspektywy biznesowej • Szereg RA: XFSB(RFSB|BF)AFSB(CS|SB|UF) • Re<<subevent>>Ap<<vertical>> • Re<<subevent>>Ap<<horizontal>>+ • Rv<<subprocess>A • Ri<<subproduct>>Ap<<vertical>>

19. Transformacje perspektywy biznesowej • Reguły szeregu RA: XFSB(RFSB|BF)AFSB(CS|SB|UF) • RA1: Re<<subevent>>ApV?- mapowanie zdarzenie wejściowego na partycję pionową • RA2: Re<<subevent>>ApH -mapowanie zdarzenia wejściowego na partycje poziome • RA3: Rv<<subprocess>A<<scenarios>> - mapowanie podprocesu na diagram realizacji przypadku użycia • RA4: Ri<<subproduct>>ApV - mapowanie produktu na partycje pionowe • Inne: • RA5: Rvi<<subproduct>>AnO– mapowanie związków obiektów • RA6: Rv<<subprocess>>Av –mapowanie czynności • RA7: Rv<<data>>Av<<data>> - mapowanie danych • RA8: Rei<<subproduct>>AiSTATE – mapowanie produktu na stan instancji • RA9: Rvi<<subproduct>>AnI – mapowanie związków pomiędzy instancjami tej samej klasy

20. 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>> • BaApH • BuA

21. Transformacje perspektywy biznesowej • Reguły szeregu BA: XFSB(RFSB|BF)AFSB(CS|SB|UF) • BA1: BaApH - aktor mapowany jest na partycję poziomą • BA2: BuA<<scenarios>> -przypadek użycia mapowany jest na diagram realizacji biznesowego przypadku użycia • Inne: • BA3: BnApHv - mapowanie związku aktora z uc • BA4: Bu<<data>>Av<<data>> - mapowanie danych

22. Transformacje perspektywy biznesowej • Trzy wymiary diagramu FSB UML • Diagram FSB UML jest diagramem realizacji biznesowego przypadku opartym o diagram aktywności UML i rozszerzonym o elementy opisujące strukturę (instancje) i behawioryzm systemu (stany instancji) • Diagram FSB UML umożliwia za pomocą jednego diagramu zaprezentować trzy wymiary: • Funkcjonalność – wybrane czynności do implementacji w systemie informatycznym • Strukturę – obiekty, • Behawioryzm – stany obiektów. • Z diagramu FSB UML można wygenerować trzy „ortogonalne” diagramy UML - szereg A(C|S|U): • Diagram klas - struktura • Diagram maszyny stanów - behawioryzm • Diagram przypadków użycia - funkcjonalność. • 22

23. Transformacje perspektywy biznesowej • Model FSB UML - Szereg AC • FOR founded Instance • //Rule AiCc (Chanda 2009) • Create UML Class WITH Name of Instance • Relate UML Class WITH founded Instance • //Rule AnCn (brak odpow.) • FOR founded Flow • Relate UML Classes WITH • Association • END FOR • END FOR

24. Transformacje perspektywy biznesowej • Model FSB UML - Szereg AS • FOR founded Instance • //Rule AiSs (brak odpow.) • Create UML State WITH Name of Instance state • Relate UML State WITH founded Instance • //Rule AnSt (brak odpow.) • FOR founded Flow • Relate UML States WITH • Transition • END FOR • END FOR

25. Transformacje perspektywy biznesowej • Model FSB UML - Szereg AU • FOR founded Partition • //Rule ApUa (Ibrahim 2011) • Create UML Actor WITH Name of Partition • END FOR • FOR founded Activity • //Rule AvUu (brak odp.) • Create UML Use Case WITH Name of Activity • //Rule ApvUn (brak odp) • Relate UML Use Case WITH UML Actor • END FOR

26. Transformacje perspektywy biznesowej • Szereg A(C|S|U) – Model FSB UML • ApVCc • AnCn • AvCh • Av<<data>>Cf AvUu • ApHvUn • ApHUa • AiSs • AnISt

27. 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

28. Transformacje perspektywy biznesowej • Spójność diagramu FSB UML • METHOD verifyConnectivity(fsbDiagram) • IF current vertex in scenario is the last vertex THEN • Add the main flow to scenarios list • RETURN 0 • END IF • Add current vertex to the unique vertices list • Search for next vertex connected with current vertex • IF no new next vertex THEN RETURN 0 END IF • FOR founded vertices • Push founded vertex to the scenario • CALL verifyConnectivity METHOD WITH founded vertex • IF result no 0 THEN RETURN result END IF • Pop founded vertex from the scenario • END FOR • RETURN 0

29. Transformacje perspektywy biznesowej • Diagramy implementowalne w środowisku BPM • XPDL

30. Transformacje perspektywy systemowej • Szereg UZ(Y|J|T)Q • Ua ………ZpV ………………Ya ……………….. Ql1 • Un …………………………. ZpVv ………Yn …….…………….Qm • Uu ……………… Zv ……….. Yu …….………..Ql • ZvJfQm • ZvJhQm • ZiTsQo • ZnTtQm

31. Transformacje perspektywy komponentowej • Szereg QMD • Ql1MyDn • QlMqDw • QoMyDn • QlMqDw

32. Integracja ze środowiskiem BPM • Narzędzie do budowy modelu FSB UML FSB UML

33. Integracja ze środowiskiem BPM • Integracja z OceanProcess

34. Podsumowanie - 1 • Przedstawiono automatyzację projektowania systemów informatycznych w środowisku BPM z zastosowaniem modelu FSB UML • Szereg uporządkowanych diagramów pogrupowanych w perspektywy • Szereg uporządkowanych diagramów tworzony jest za pomocą jednego lub więcej diagramów tak, by zapewnić na każdym etapie kompletny opis w zakresie funkcjonalności, zachowania i struktury danego fragmentu modelu • Zestawy reguł spójności w postaci transformacji elementów w szeregu diagramów

35. Podsumowanie - 2 • Istnieją inne szeregi uporządkowanych diagramów projektowych UML (i elementów) - powinny spełniać, podobnie jak dla modelu FSB UML, reguły spójności i kompletności • Uporządkowany szereg diagramów UML (i elementów) umożliwia automatyzację projektowania systemów informatycznych • Elementy z uporządkowanych diagramów i ich właściwości umożliwiają przenoszenie (transformacje) z modeli abstrakcyjnych informacji niezbędnych do odpowiedniej ich implementacji w systemie informatycznym, czyli do modeli implementowalnych

36. Podsumowanie - 3 • Różne platformy (środowiska) budowy systemów informatycznych mogą wymagać odmienne uporządkowane szeregi diagramów UML (i ich elementy): dla środowiska BPM diagramami implementowalne to diagram {A} realizacji przypadków użycia (FSB UML) – elementy workflow; {C} diagram klas biznesowych – pola formularzy oraz struktura repozytorium, {S} diagram stanów maszyny – cykle życia obiektów biznesowych oraz {Y} diagram systemowych przypadków użycia - formularze. • Model FSB UML integrowany był z EMC Documentum (brak implementacji wymiaru struktury w EMC Documentum), obecnie opracowywana integracja z OceanProcesses.

37. Pytania ? • Dziękuję za uwagę