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 Automatyzacja budowy systemów informatycznych z zastosowaniem UML • sformułowanie warunków koniecznych do automatycznego wytwarzania modeli oprogramowania w postaci: • definicji koniecznej spójności architektury oprogramowania • definicji koniecznej kompletności architektury oprogramowania • uszeregowanie i skatalogowanie diagramów projektowych UML umożliwiających automatyzację budowy systemu informatycznego • opracowanie transformacji kolejnych, powiązanych diagramów UML sterowanych regułami spójności i kompletności architektury oprogramowania • zdefiniowanie zbioru reguł transformacji (mapowania) elementów powiązanych modeli • zdefiniowanie zbioru reguł zachowania spójności elementów poszczególnych modeli • zdefiniowanie zbioru reguł zachowania kompletności powiązanych modeli z określonych warstw abstrakcji poszczególnych perspektyw Przedstawiona będzie metoda automatycznego projektowania systemów informatycznych w środowisku BPM z zastosowaniem autorskiego modelu FSB UML

3. 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 biznesowego do modelu wdrożeniowego • Transformacje perspektywy biznesowej • Transformacje perspektywy systemowej • Transformacje perspektywy komponentowej • Podsumowanie

4. 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, systemowa, implementacyjna • Każdą perspektywę powinno się przedstawić za pomocą modelu opisującego trzy wymiary: • Struktura – np. diagram klas UML (structure) • Zachowanie – np. diagram stanów UML (behaviour) • Funkcjonalność – np. diagram przypadków użycia UML (OMG – behaviour)

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

6. Reguły spójności modeli UML • Szereg uporządkowanych diagramów UML • P-package diagram, C-class diagram, O-object diagram, • U-use case diagram, A-activity diagram, S-state machine diagram, • Q-sequence diagram, I-communication diagram

7. Reguły spójności modeli UML • Oznaczenia • u-przypadek użycia • v-czynność • x-klasyfikator (1-brak, 2-typ, 3-niedostępny) • n-związek (1-brak, 2-typ, 3-niedostępny, 4-krotność, 5-skierowanie,!-zły poziom modelu) • b-widoczność • d-ograniczenia • g-warunek • r-odpalacz • 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

8. Reguły spójności modeli UML • Najczęstsze reguły (wyrażenia regularne) • hm: Metoda - komunikat (4) • 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)

9. Reguły spójności modeli UML • Przykłady z pokazaniem diagramów (duże litery) hm: Metoda - komunikat (4) • ChQm – Ibrahim 2012, Szereg: UQC Każdemu komunikatowi z diagramu sekwencji odpowiada metoda klasy z diagramu klas • ChQm – Sapna 2007, Szereg: C(S|U(A|Q)) Każdemu komunikatowi obiektu diagramu sekwencji odpowiada metoda klasy z diagramu klas. • QmOh – Ha 2008, Szereg: O(Q|A|I) Komunikat z diagramu sekwencji odpowiada operacji obiektu z diagramu obiektów. • OhIm – Ha 2008, Szereg: O(Q|A|I) Komunikat z diagramu współpracy odpowiada metodzie obiektu z diagramu obiektów.

10. Reguły spójności modeli UML • Obserwacje • 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) • Reguły spójności nie mają powiązania z jakąkolwiek 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 • Diagramy projektowe • Diagram realizacji przypadku użycia: A • diagram aktywności UML (brak wymiaru struktury) • diagram sekwencji UML (brak wymiaru funkcjonalności) • diagram kolaboracji UML (brak wym. behawioryzmu. i funkcjon.) • Diagram kontekstowy: X • diagram aktywności, komponentów UML • Diagram dekompozycji procesów: R • diagram aktywności UML • Diagram biznesowych przypadków użycia: B • Diagram przypadków użycia UML (stereotyp: business) • Diagram systemowych przypadków użycia: U • Diagram przypadków użycia UML • Diagram obiektów biznesowych: O • Diagram obiektów UML

12. Reguły spójności modeli UML • Autorska definicja spójności • Warunek wystarczającej kompletności • modele systemu informatycznego powinny opisywać funkcjonalność, behawioryzm i strukturę projektowanego systemu • 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, przy czym wybrane diagramy z danej warstwy perspektywy architektury oprogramowania powinny być ze sobą zintegrowane

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

14. Tezy rozprawy • Wykazanie • Opracowanie uporządkowanego szeregu powiązanych diagramów UML opisujących architekturę oprogramowania od kontekstu działania systemu, aż do modeli implementowalnych w środowisku BPM; • Opracowanie semantyki modelu FSB UML, obejmującą formalny opis dziedziny syntaktycznej, semantycznej oraz odwzorowania pomiędzy modelem FSB UML, a sąsiednimi diagramami UML w uporządkowanym szeregu powiązanych diagramów UML w postaci reguł spójności zapisanych w formie algorytmów. • Opracowanie — w oparciu o formalnie wyrażoną semantykę — pojęć wystarczającej spójności i wystarczającej kompletności wybranych modeli wraz z analizą ich własności i przykładów zastosowania. • Weryfikację praktyczną zaproponowanej metody projektowania na przykładach realizacji rzeczywistych projektów informatycznych.

15. Model FSB UML • Diagram FSB UML - przykład

16. Model FSB UML • 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ść. • 16

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

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

19. Model FSB UML • Szereg AU (AB - projektowe) • 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

20. Szereg uporządkowanych diagramów • Perspektywa biznesowa

21. Szereg uporządkowanych diagramów • Perspektywa biznesowa, szereg XR (kontekst-podprocesy)

22. Transformacje perspektywy biznesowej • Definicje diagramu kontekstowego i dekompozycji procesów • CLASS contextDiagram • ATTRIBUTES: • events: EList<Event> • products: EList<Product> • processes: EList<Process> • dependencies: EList<Dependency> • objectflows: EList<ObjectFlow> • CLASS processesDecompositionDiagram • ATTRIBUTES: • events: EList<Event> • products: EList<Product> • processes: EList<Process> • dependencies: EList<Dependency> • objectflows: EList<ObjectFlow>

23. Transformacje perspektywy biznesowej • Reguły kompletności dla szeregu diagramów XR • Reguły kompletności diagramu kontekstowego: • Xv<<process>>{1} : istnieje tylko jeden proces (behawioryzm) • Xe+ : istnieje co najmniej jedno zdarzenie (funkcje) • Xi<<product>>+ : istnieje co najmniej jeden produkt (struktura) • Xi<<datastore>>+ : istnieje co najmniej jedna struktura danych (struktura) • Xi<<rule>>+: istnieje co najmniej jedna reguła (behawioryzm) • Reguły kompletności diagramu dekompozycji procesów: • Rv+i<<product>>{1}: każdy produkt jest wynikiem realizacji procesu • Re{1}v<<process>{1}: każde zdarzenie musi wpływać na proces • Re+v{1}i<<product>>+ : każdy proces posiada co najmniej jedno zdarzenie na wejściu i co najmniej jeden produkt na wyjściu

24. Transformacje perspektywy biznesowej • Pseudo-kod reguł kompletności diagramu kontekstowego • Xv<<process>>{1} : istnieje tylko jeden proces (behawioryzm) • METHOD verifyProcessInDiagramContext(contextDiagram) • countofProcess=0 • FOR each process FROM contextDiagram • countofProcess++ • END FOR • IF countofProcess <>1 THEN RETURNfalse • RETURN true • Xe+ : istnieje co najmniej jedno zdarzenie (funkcje) • METHOD verifyEventInDiagramContext(contextDiagram) • countofEvent=0 • FOR each event FROM contextDiagram • countofEvent++ • IF event not connected to contextDiagram.getProcess() THEN • RETURN false • END IF • END FOR • IF countofEvent < 1 THEN RETURN false • RETURN true

25. Transformacje perspektywy biznesowej • Reguły spójności dla szeregu diagramów XR • XeRe+ : • dekompozycja zdarzeń wejściowych na podzdarzenia • Xev<<process>>{1}Re+v<<process>>+ : • dekompozycja procesu głównego na podprocesy według zdarzeń wejściowych • Xv<<process>>{1}i<<product>>Rv<<process>>+i<<product>+: • dekompozycja produktów wyjściowych na podprodukty wyjściowe

26. Transformacje perspektywy biznesowej • Pseudo-kod reguł spójności szeregu diagramów XR • XeRe+ : 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}Re+v<<process>>+: dekompozycja procesu głównego • 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 • Xv<<process>>{1}i<<product>>Rv<<process>>+i<<product>+: 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 • END FOR

27. Szereg uporządkowanych diagramów • Perspektywa biznesowa, szereg RB (podprocesy-b. use case)

28. Transformacje perspektywy biznesowej • Reguły kompletności i spójności dla szeregu diagramów RB • Reguły kompletności diagramu dekompozycji procesów: • Rv+i<<product>>{1}: każdy produkt jest wynikiem realizacji procesu • Re{1}v<<process>{1}: każde zdarzenie musi wpływać na proces • Re+v{1}i<<product>>+ : każdy proces posiada co najmniej jedno zdarzenie na wejściu i co najmniej jeden produkt na wyjściu • Reguły kompletności diagramu biznesowych przypadków użycia: • Bu{1}a+: weryfikacja kompletności przypadków użycia • Ba{1}u+: weryfikacja kompletności aktorów • Reguły spójności szeregu diagramów RB: • Rv<<process>Bu: mapowanie podprocesów na biznesowe przypadki użycia • ReBa: mapowanie podzdarzeń na aktorów • Ri<<product>>Ba: mapowanie podproduktow na aktorów

29. Szereg uporządkowanych diagramów • Perspektywa biznesowa, szereg BA (b. use case-fsb uml)

30. Transformacje perspektywy biznesowej • Reguły kompletności i spójności dla szeregu diagramów BA • Reguły kompletności diagramu biznesowych przypadków użycia: • Bu{1}a+: weryfikacja kompletności przypadków użycia • Ba{1}u+: weryfikacja kompletności aktorów • Reguły spójności diagramu A: • Av<<start>>[v+|i+]v<<stop>>: wszystkie ścieżki są wykonywalne • Reguły spójności szeregu diagramów BA: • BuA: mapowanie przypadków użycia na diagramy aktywności • Ba{1}Ap+: dekompozycja aktorów na partycje

31. Transformacje perspektywy biznesowej • Opis diagramu FSB UML w pseudo kodzie • CLASS fsbDiagram • ATTRIBUTES: • actors: List<Actor> //functional dimension • objects: List<Object> //structure dimension • starts: List<Initial> • stops: List<FlowFinal> • activities: List<Activity> //behavior & functional dim. • gates: List<Gates> • forks: List<Forks> • instances: List<Instances> // structure dimension • controlflows: List<ControlFlow> // behaviour dimension • objectflows: List<ObjectFlow> // structure dimension • METHODS: • verifyConnectivity(FSBModel) RETURN result • checkConsistency(FSBModel) RETURN result • checkCompleteness(FSBModel) RETURN result • createCLDiagram(FSBModel, CLDiagram) RETURN result • createSMDiagram(FSBModel, SMDiagram) RETURN result • createUCDiagram(FSBModel, UCDiagram) RETURN result

32. Transformacje perspektywy biznesowej • Kompletność diagramu FSB UML • METHOD checkCompleteness(fsbDiagram) • IF fsbDiagram has no start OR fsbDiagram has no stop THEN • RETURN false • END IF • IF fsbDiagram has no activity OR fsbDiagram has no controlflow THEN • RETURN false • END IF • IF fsbDiagram has no instance OR fsbDiagram has no objectflow THEN • RETURN false • END IF • IF fsbDiagram has no object OR fsbDiagram has no actor THEN • RETURN false • END IF • RETURN true

33. Transformacje perspektywy biznesowej • Reguły kompletności i spójności dla szeregu A(C|S|U) • Reguły spójności diagramu A: • Av<<start>>[v+|i+]v<<stop>>: wszystkie ścieżki są wykonywalne • Reguły spójności szeregu diagramów A(C|S|U): • Ap<<vertical>>Cc: mapowanie partycji pionowych na klasy • An<<control>>Cn: mapowanie przepływów sterowania na asocjacje pomiędzy klasami • Ap<<horizontal>>Ua: mapowanie partycji poziomych na aktorów • AvUu: mapowanie czynności na systemowe przypadki użycia • ApvUn: mapowanie przynależności czynności do partycji na asocjacje między aktorami, a systemowymi przypadkami użycia • AvSs: mapowanie czynności na stany instancji klasy • An<<object>>St: mapowanie przepływów obiektów na przejścia pomiędzy stanami

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

35. Transformacje perspektywy biznesowej • Reguły AiSs, AiCc • METHOD createSMDiagram(smDiagram) • //AiSs • FOR founded instance • Create UML State WITH Name of instance state • Relate UML State WITH Class • Relate UML State WITH other UML States Linked by Activities • END FOR • RETURN • METHOD createCLDiagram(clDiagram) • //AiCc • FOR founded instance • Create UML Class WITH Name of instance • Relate UML Class WITH founded instance • END FOR • RETURN

36. Transformacje perspektywy biznesowej • Reguły: ApUa; AaUu • METHOD createUCDiagram(ucDiagram) • //ApUa • FOR founded horizontalPartition • Create UML Actor WITH Name of horizontalPartition • Relate UML Actor WITH horizontalPartition • END FOR • //AaUu • FOR founded activity • Create UML UseCase WITH Name of activity • Relate UML UseCase WITH • horizontalPartition contains founded activity • END FOR • RETURN

37. Szereg uporządkowanych diagramów • Perspektywa systemowa

38. Perspektywa systemowa • Transformacje perspektywy systemowej

39. Szereg uporządkowanych diagramów • Perspektywa komponentowa

40. Perspektywa komponentowa • Transformacje perspektywy komponentowej

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

42. Integracja ze środowiskiem BPM • Integracja z OceanProcess

43. Podsumowanie - 1 • Przedstawiono automatyzację projektowania systemów informatycznych w środowisku BPM z zastosowaniem modelu FSB UML • Szereg uporządkowanych diagramów pogrupowanych w perspektywy • Zestawy reguł spójności i kompletności • Istnieją inne szeregi uporządkowanych diagramów projektowych UML, ale poza modelem FSB UML brak zdefiniowanych zestawów reguł spójności i kompletności • Model FSB UML integrowany był z EMC Documentum (brak wymiaru struktury), obecnie opracowywana integracja z OceanProcesses.

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