Upload
lysander-theron
View
42
Download
5
Embed Size (px)
DESCRIPTION
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. - PowerPoint PPT Presentation
Citation preview
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 2
decomposition into Subprocess n
decomposition into Event 1.1
decomposition into Event 1.2
decomposition into Subprocess 1
decomposition into Subprocess 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»Actor2
«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
«business actor»Actor1
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
FOR founded InstanceCreate UML Class WITH Name of InstanceRelate UML Class WITH founded InstanceFOR founded ControlFlow
Relate UML Classes WITH AssociationEND FOR
END FOR
FOR founded InstanceCreate UML Class WITH Name of InstanceRelate UML Class WITH founded InstanceFOR founded ControlFlow
Relate UML Classes WITH AssociationEND 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
Partition A (Opinion) Partition B (Request) Partition C (Reply)
FSB UML Diagram
1. Creating Request
2. Checking Request
3. Creating Opinion
:Class B (Request)
[Creating]
:Class B (Request)
[Checking]
:Class A (Opinion)
[Creating]
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
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
Partition A (Opinion) Partition B (Request) Partition C (Reply)
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]
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
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)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
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
UC2. Creatng opinion
UC1. Checking request
UC3. Approv ing case
UC5. Approv ing reply
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
Partition A (Opinion) Partition B (Request) Partition C (Reply)
FSB UML Diagram
Class Diagram
UseCase Diagram
StateMachine 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
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
UC2. Creatng opinion
UC1. Checking request
UC3. Approv ing case
UC5. Approv ing reply
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ę