1 / 37

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

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. Wprowadzenie Tezy rozprawy.

hue
Download Presentation

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

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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ę

More Related