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

WprowadzenieTezy 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 implementowalnych umoż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

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

Architektura składa się z wielu powiązanych modeli opisujących wybrane zagadnienia (ang. separation of concern – Hursh, Lopes 1995 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)

Architektura oprogramowaniaPerspektywy i kompletność

Spójność modeli UMLDefinicje 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, 2008Spó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, 2007Zwią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 UMLSzereg uporządkowanych diagramów UML

Author, Year Sequence of diagrams

Number of consistency rules

Egyed 2000 P(CQ|CO|CS) 50Sapna 2007 C(S|U(A|Q)) 18Ibrahim 2012 UQC 8Ha 2008 O(Q|A|I) 7Shinkawa 2008 UAQS 4Chanda 2009 UAC 4Hausmann 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 UMLOznaczenia 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}[a1-aN] albo Bu{1}[a1-aN] Przykład ogólnej reguły dla BA: BaApHUa

Reguły spójności modeli UMLNajczę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 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 UMLAnaliza dotychczasowych rozwiązań

Reguły spójności modeli UMLAutorska 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.

Szereg uporządkowanych diagramówKompletny i spójny opis architektury oprogramowania

custom Diagrams Sequence

Business view

System view

Component view

{X} Context Diagram: Activ ity Diagram

{R} Decomposition Process Diagram: Activ ity Diagram{B} Business Use Case Diagram: Use Case Diagram

{A} FSB UML Business Diagram: Activ ity Diagram

{C} Business Object Diagram: Class Diagram {S} Business Object Behav iour Diagram: State Machine Diagram{U} System Use Case Diagram: Use Case Diagram

{Z} FSB UML System Diagram: Activ ity Diagram

{T} System Object Behav iour Diagram: State Machine Diagram{J] System Object Diagram: Class Diagram

{Q} FSB UML Component Diagram: Sequence Diagram

{M} Component Diagram: Component Diagram

{D} Deployment Diagram: Deployment Diagram

XFSB(RSB|BF)AFSB(CS|SB|UF)

UFZFSB(JS|TB|YF)

{Y} Internal Use Case Diagram: Use Case Diagram

YFQFSBMFSBDFSB

XFSB(RSB|BF)AFSB(CS|SB|UF)ZFSB(JS|TB|YF)QFSBMFSBDFSB

«derive» 1..*

«derive»

«derive»

«generated»«generated»«generated»

«derive» 1..*

«generated»«generated» «generated»

«derive» 1..*

«derive»«derive»

«derive»1..*

«InformationDependency»«InformationDependency»

«InformationDependency» «InformationDependency»

Transformacje perspektywy biznesowejSzereg XR: XFSB(RFSB|BF)AFSB(CS|SB|UF)

analysis Context2Decomposition

Decomposition DiagramContext Diagram

Main Process

Event 1

Event 2

Event n

Repository

Product 1

Product 2

Business rules

Subprocess 1

Subprocess 2

Subprocess nEvent n

Event 1.1

Event 1.2

Product 2

Product 1.1

Product 1.2

decomposition into Event n

decomposition into Subprocess 1


decomposition into Subprocess n

decomposition into Event 1.1

decomposition into Event 1.2



decomposition into Subprocess n

decomposition into Product 1.1

decomposition into Product 1.2

decomposition into Product 2

Reguły kompletności diagramu kontekstowego:{B} Xv<<process>>{1}; Xi<<rule>>+; {F} Xe+; {S} Xi<<product>>+; Xi<<datastore>>+

Reguły kompletności diagramu dekompozycji procesów: {B} Rv<<subprocess>>+; {F} Re<<subevent>>+; {S} Ri<<subproduct>>+;

XeRe<<subevent>>

Xev<<process>>{1}R[v1<<subprocess>>-v2<<subprocess>>]

Xi<<rules>>v<<process>>{1}i<<product>>Ri<<subproduct>

Transformacje perspektywy biznesowejPseudo-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

XR1: XeRe<<subevent>> - dekompozycja zdarzeńXR2: Xev<<process>>{1}R[v1<<subprocess>>-v2<<subprocess>>] - dekompozycja procesu głównegoXR3: Xi<<rules>>v<<process>>{1}i<<product>>Ri<<subproduct> - dekompozycja produktów.

Inne:XR4: Xi<<product>>Ri<<subproduct>> - dekompozycja produktówXR5: Xvi<<product>>Rvi<<subproduct>> - mapowanie związków czynność-instancjaXR6: Xvi<<datastore>>Rv<<data>> - mapowanie czynności w aspekcie danych

analysis Context2BuseCases

UseCase DiagramContext Diagram

Main Process

Event 1

Event 2

Event n

Repository

Product 1

Product 2

Business rules

UC1. Subprocess 1

UC2. Subprocess 2

UCn. Subprocess n

«business actor»Actor1


«business actor»Actorn

Reguły kompletności diagramu biznesowych przypadków użycia: {F} Bu+; Ba+

XeBu

XeBa

Xi<<product>>Ba

Xi<<rules>>v<<process>>Bu

Reguły kompletności diagramu kontekstowego:{B} Xv<<process>>{1}; Xi<<rule>>+; {F} Xe+; {S} Xi<<product>>+; Xi<<datastore>>+

Transformacje perspektywy biznesowejInne reguły szeregu XB: XFSB(RFSB|BF)AFSB(CS|SB|UF)

XB1: XeBu - mapowanie zdarzenia na przypadek użyciaXB2: XeBa - mapowanie zdarzenia na aktoraXB3: Xi<<product>>Ba - mapowanie produktu na aktoraXB4: Xi<<rules>>v<<process>>Bu - dekompozycja procesu na uc

Inne:XB5: Xei<<rules>>v<<process>>Bu<<scenarios>> - dekompozycja procesu na czynności w scenariuszuXB6: Xei<<rules>>i<<product>>Ba – mapowanie zdarzeń i produktów według reguł na aktorówXB7: Xev<<process>>Bn - mapowanie związków zdarzenie-proces na ziązki aktor-przypadek użyciaXB8: Xv<<data>>Bu<<data>> - mapowanie czynności na przypadki użycia w aspekcie danych

analysis Decomposition2FSBModel

Decomposition Diagram Business FSB UML Diagram - UC1. Subprocess 1

Pa

rtition

1.3

Pa

rtition

1.2

Pa

rtition

1.1

Product 1Request 1

1.4. Activ ity

Start1

1.1. Activ ity

1.2. Activ ity :Product 1

[Created]

:Product 1

[Verified]

:Product 1

[Approved]

Final1

:Request 1

[Received]

:Request 1

[Approved]

1.3. Activ ity

Subprocess 1

Subprocess 2

Subprocess nEvent n

Event 1.1

Event 1.2 Product 2

Product 1.1

Product 1.2

Transformacje perspektywy biznesowejSzereg RA: XFSB(RFSB|BF)AFSB(CS|SB|UF)

Re<<subevent>>Ap<<vertical>>

Re<<subevent>>Ap<<horizontal>>+ Rv<<subprocess>A

Ri<<subproduct>>Ap<<vertical>>

Transformacje perspektywy biznesowejReguł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 poziomeRA3: Rv<<subprocess>A<<scenarios>> - mapowanie podprocesu na diagram realizacji przypadku użyciaRA4: Ri<<subproduct>>ApV - mapowanie produktu na partycje pionowe

Inne:RA5: Rvi<<subproduct>>AnO – mapowanie związków obiektówRA6: Rv<<subprocess>>Av – mapowanie czynnościRA7: Rv<<data>>Av<<data>> - mapowanie danychRA8: Rei<<subproduct>>AiSTATE – mapowanie produktu na stan instancjiRA9: Rvi<<subproduct>>AnI – mapowanie związków pomiędzy instancjami tej samej klasy

Transformacje perspektywy biznesowejSzereg BA: XFSB(RFSB|BF)AFSB(CS|SB|UF)

analysis BUseCase2FSBDiagram

Business FSB UML Diagram - UC1. Subprocess 1

Pa

rtition

1.3

Pa

rtition

1.2

Pa

rtition

1.1

Product 1Request 1

UseCase Diagram

UC1. Subprocess 1


1.4. Activ ity

Start1

1.1. Activ ity

1.2. Activ ity :Product 1

[Created]

:Product 1

[Verified]

:Product 1

[Approved]

Final1

:Request 1

[Received]

:Request 1

[Approved]

1.3. Activ ity

Annotation

tagsActor = Description = Event = Postcondition = Precondition = Scenario = State = UObject =

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

Transformacje perspektywy biznesowejReguł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 ucBA4: Bu<<data>>Av<<data>> - mapowanie danych

22

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ść.

Transformacje perspektywy biznesowejTrzy wymiary diagramu FSB UML

Transformacje perspektywy biznesowejModel FSB UML - Szereg AC

act FSB Diagram - structure mapping

FOR founded InstanceCreate UML Class WITH Name of InstanceRelate UML Class WITH founded InstanceFOR founded ControlFlow

Relate UML Classes WITH AssociationEND FOR

END FOR

Pa

rtition

1 (S

up

erv

iso

r)P

artitio

n 2

(Cle

rk)

Cu

sto

me

r

Partition A (Opinion) Partition B (Request) Partition C (Reply)

FSB UML Diagram

Class Diagram

1. Creating Request

2. Checking Request

3. Creating Opinion

Class B (Request)Class A (Opinion)

:Class B (Request)

[Creating]

:Class B (Request)

[Checking]

:Class A (Opinion)

[Creating]

Class C (Reply)

6. Approv ing Request

4. Approv ing Opinion

5. Archiv ing Opinion

7. Archiv ing Request

:Class A (Opinion)

[Approving]

:Class B (Request)

[Approving]

8. Creating Reply

9. Approv ing Reply

10. Sending Reply

:Class C (Reply)

[Creating]

Receiv ing Reply

:Class C (Reply)

[Approving]

:Class C (Reply)

[Sending]

Start Final



END FOR



END FOR

«trace»«trace» «trace»

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

Transformacje perspektywy biznesowejModel 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

act FSB Diagram - behav iour mapping

FOR founded InstanceCreate UML State WITH Name of Instance stateRelate UML State WITH ClassFOR founded Flow Relate UML States WITH TransitionEND FOR

END FOR

StateMachine DiagramStateMachine Diagram StateMachine Diagram

Pa

rtition

1 (S

up

erv

iso

r)P

artitio

n 2

(Cle

rk)

Cu

sto

me

r


FSB UML Diagram

1. Creating Request

2. Checking Request

3. Creating Opinion

:Class B (Request)

[Creating]

:Class B (Request)

[Checking]

:Class A (Opinion)

[Creating]





:Class A (Opinion)

[Approving]

:Class B (Request)

[Approving]

8. Creating Reply

9. Approv ing Reply

10. Sending Reply

:Class C (Reply)

[Creating]

Receiv ing Reply

:Class C (Reply)

[Approving]

:Class C (Reply)

[Sending]

Start Final

Initial

C.SM1 (Creating)

C.SM2 (Approv ing)

C.SM3 (Sending)

Final

Initial

B.SM1 (Checking)

B.SM2 (Approv ing)

Final

Initial

A.SM1 (Creating)

A.SM2 (Approv ing)

Final

Transformacje perspektywy biznesowejModel 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

act FSB Diagram - function mapping

Pa

rtition

1 (S

up

erv

iso

r)P

artitio

n 2

(Cle

rk)

Cu

sto

me

r


FSB UML Diagram

UseCase Diagram

1. Creating Request

2. Checking Request

3. Creating Opinion

:Class B (Request)

[Creating]

:Class B (Request)

[Checking]

:Class A (Opinion)

[Creating]





:Class A (Opinion)

[Approving]

:Class B (Request)

[Approving]

8. Creating Reply

9. Approv ing Reply

10. Sending Reply

:Class C (Reply)

[Creating]

Receiv ing Reply

:Class C (Reply)

[Approving]

:Class C (Reply)

[Sending]

Start Final

Clerk

Superv isor

UC2. Creatng opinion

UC1. Checking request

UC3. Approv ing case

UC5. Approv ing reply

UC4. Creating reply

UC6. Sending reply

FOR founded Activity //Rule AvUu Create UML Use Case WITH Name of Activity //Rule ApvUn Relate UML Use Case WITH UML ActorEND FOR

FOR founded Partition //Rule ApUa Create UML Actor WITH Name of PartitionEND FOR

«trace»

«trace»

act FSB Diagram

StateMachine Diagram

UseCase Diagram

Class Diagram

FSB UML DiagramPartition C (Reply)Partition B (Request)Partition A (Opinion)

Cu

sto

me

rP

artitio

n 2

(Cle

rk

)P

artitio

n 1

(Su

pe

rv

iso

r)

1. Creating Request

2. Checking Request

3. Creating Opinion


:Class B (Request)

[Creating]

:Class B (Request)

[Checking]

:Class A (Opinion)

[Creating]

Class C (Reply)





:Class A (Opinion)

[Approving]

:Class B (Request)

[Approving]

8. Creating Reply

9. Approv ing Reply

10. Sending Reply

:Class C (Reply)

[Creating]

Receiv ing Reply

:Class C (Reply)

[Approving]

:Class C (Reply)

[Sending]

Start Final

Initial

C.SM1 (Creating)

C.SM2 (Approv ing)

C.SM3 (Sending)

Final

Initial

B.SM1 (Checking)

B.SM2 (Approv ing)

Final

Initial

A.SM1 (Creating)

A.SM2 (Approv ing)

Final

Clerk

Superv isor





UC4. Creating reply

UC6. Sending reply

StateMachine DiagramStateMachine Diagram

«trace»

«trace»

«trace» «trace» «trace»

Transformacje perspektywy biznesowejSzereg A(C|S|U) – Model FSB UML

ApVCc AnCn AvCh Av<<data>>Cf AvUu

ApHvUn

ApHUa

AiSs AnISt

Transformacje perspektywy biznesowejSzereg X(B|R)A(C|S|U) - Z(J|T|Y) - QMD

Struktura {S} perspektywa: systemowa komponentowaXeRe<<subevent>>ApV

?Cc ZiJc QlMqDwXi<<product>>Ri<<subproduct>>ApVCc ZiJc QlMqDwXvi<<product>>Rvi<<subproduct>>AnOCn ZnOJn QmMyDnXev<<process>>Rv<<subprocess>>AvCh ZvJh QmMyDnXev<<process>>BnApHvCh ZvJh QmMyDnXvi<<repository>>Rv<<data>>Av<<data>>Cf Zv<<data>>Jf QmMyDnXv<<data>>Bu<<data>>Av<<data>>Cf Zv<<data>>Jf QmMyDn Funkcjonalność {F}Xei<<rules>>v<<process>>BuAvUu ZvYu

QlMqDwXei<<rules>>i<<product>>BaApHUa ZpVYa Ql1MyDnXev<<process>>BnApHvUn ZpVvYn

Ql1MyDn Behawioryzn {B}Xei<<product>>Rei<<subproduct>>AiSTATESs ZiTs

QoMyDnXvi<<product>>Rvi<<subproduct>>AnISt ZnTt

QmMyDnXeReApV

1St ZnTtQmMyDn

Xi<<product>>Ri<<subproduct>>ApVSt ZnTt QmMyDn

Transformacje perspektywy biznesowejSpó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 scenarioCALL verifyConnectivity METHOD WITH founded vertexIF result no 0 THEN RETURN result END IFPop founded vertex from the scenario

END FOR RETURN 0

Transformacje perspektywy biznesowejDiagramy implementowalne w środowisku BPManalysis BPM env ironment

EMC Documentum

StateMachine Diagram StateMachine Diagram

Pa

rtition

1 (S

up

erv

iso

r)P

artitio

n 2

(Cle

rk)

Cu

sto

me

r


FSB UML Diagram

Class Diagram

UseCase Diagram

StateMachine Diagram

1. Creating Request

2. Checking Request

3. Creating Opinion


:Class B (Request)

[Creating]

:Class B (Request)

[Checking]

:Class A (Opinion)

[Creating]

Class C (Reply)





:Class A (Opinion)

[Approving]

:Class B (Request)

[Approving]

8. Creating Reply

9. Approv ing Reply

10. Sending Reply

:Class C (Reply)

[Creating]

Receiv ing Reply

:Class C (Reply)

[Approving]

:Class C (Reply)

[Sending]

Start Final

Initial

C.SM1 (Creating)

C.SM2 (Approv ing)

C.SM3 (Sending)

Final

Initial

B.SM1 (Checking)

B.SM2 (Approv ing)

Final

Initial

A.SM1 (Creating)

A.SM2 (Approv ing)

Final

Clerk

Superv isor





UC4. Creating reply

UC6. Sending reply

Repository

Lifecycle

«trace»«trace» «trace»

«data»

XPDL

Transformacje perspektywy systemowejSzereg UZ(Y|J|T)Q

analysis System v iew

{U} System Use Case

{Z} System FSB UML Diagram - UC1.1

Actor System

Cla

ss

1.1

{Y} Internal use case

{J} System class

{T} System state machine

{Q} Sequence

Actor1.1

Actor1.2

Actor1.3

UC1.1

UC1.2

UC1.3

UC1.4

Start1

1. Activ ity 1 2. Activ ity 2

3. Activ ity 3

Final1

Actor 1.1

UC1.1.1

Object1.1

[Changed] Class1.1

- attrib1 :int- attrib2 :int

+ method1() :void+ method2() :void

Initial

changed

Final

Object1.1 Object1.2

method()

Ua ………ZpV ………………Ya ……………….. Ql1

Uu ……………… Zv ……….. Yu …….………..Ql

Un …………………………. ZpVv ………Yn …….…………….Qm

ZiTsQoZnTtQm

ZvJfQmZvJhQm

analysis Component v iew

Object1.2

{Q} Sequence

Object1.1

{D} Deployment{M} Component

«device»Klaster OSB

WebLogic

Component2

LoadBalancer

Serv er HTTP Client

IE

«device»Klaster DB

Repository

Component1

Explorer

System1

Component2

System2System1

Repository

WEB

Component1

data

Internet

message

«deploy»

message()

Transformacje perspektywy komponentowejSzereg QMD

QlMqDw

Ql1MyDn

QlMqDw

QoMyDn

Integracja ze środowiskiem BPMNarzędzie do budowy modelu FSB UML

cmp Metoda budowy

«execution environm...Topcased

«execution environment»EMC Documentum

BPM Engine

DOD Model

UML Model

xPDL Process Execut ion

Process Optimizat ion

Work Queue Management

Automated Alerts & Actions

BPA

Content ServerDocumentum

Repository

Process Builder

Forms Builder

Process Analyser

Workflow

Informat ion Management

Start«new»

«old»

«new» «new»

manual configuration

«old»

«integration»

Integracja ze środowiskiem BPMIntegracja z OceanProcess

analysis Ocean Process env ironment

«executionEnvironment»Topcased

FSB UML Modeler

XPDL

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

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

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.

Pytania ?

Dziękuję za uwagę

stanisław jerzy niepostyn instytut informatyki, wydział elektroniki i technik informacyjnych,

Documents