Zastosowanie reguł spójności w modelowaniu

Transkrypt

Zastosowanie reguł spójności
w
modelowaniu systemów BPM
na przykładzie zamówienia publicznego
na system e-IRZ dla ARiMR
Stanisław Jerzy Niepostyn
Instytut Informatyki,
Wydział Elektroniki i Technik Informacyjnych,
Politechnika Warszawska
Plan prezentacji
 Cel i motywacja
 Proces biznesowy, architektura oprogramowania
 Spójność i kompletność modeli UML/BPMN
 Reguły spójności modeli UML/BPMN
 Szereg uporządkowanych diagramów opartych
na regułach spójności
 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
Project-Media, Stanisław Niepostyn
 Publikacje naukowe – współpraca z Instytutem




Informatyki oraz Instytutem Telekomunikacji Politechniki
Warszawskiej
Projektowanie, modelowanie, audyt systemów
informatycznych i procesów biznesowych
Wykłady, szkolenia z zakresu modelowania systemów
IT (BPM)
Darmowe narzędzia open-source do modelowania
procesów biznesowych i systemów IT –
Topcased/Eclipse
www.project-media.pl
Project-Media - projekty
 Projekt e-IRZ, ZSIN dla ARiMR
 Audyt systemu SRP dla MSW
 System ECS/ICS dla Ministerstwa Finansów
 Projekt systemu BPM-II dla RWE
 Projekt systemu Dokumentacji Ochrony Danych
Osobowych dla Polkomtel S.A.
 Elektroniczny System Obiegu Dokumentów dla
Najwyższej Izby Kontroli
 Szkolenia, wykłady: Ministerstwo Finansów, ARiMR,
PARP, Wola Info, Asseco, RWE, Instytut Informatyki
oraz Instytut Telekomunikacji Politechniki Warszawskiej
…
Project-Media – publikacje naukowe

Niepostyn Stanisław Jerzy: Consistent Model Driven Architecture, w: Proceedings of SPIE, Photonics
Applications in Astronomy, Communications, Industry, and High-Energy Physics Experiments /
Romaniuk Ryszard ( red. )

Niepostyn Stanisław Jerzy: The Sufficient Criteria for Consistent Modelling of the Use Case Realization
Diagrams with a New Functional-Structure-Behaviour UML Diagram, w: Przegląd Elektrotechniczny,
Sigma NOT, nr 2, 2015

Niepostyn Stanisław Jerzy, Tyrowicz Andrzej: The sufficient criteria for consistent modeling from the
context diagram to the business use case diagrams driven by consistency rules. Chapter 5, w: Software
Engineering from Research and Practice Perspectives / Madeyski Lech, Ochodek Mirosław ( red. ),
2014, Nakom

Niepostyn Stanisław Jerzy: The Sufficient Criteria for Consistent Modelling of the Use Case Realization
Diagrams, w: Information Systems Architecture and Technology: System Analysis Approach to the
Design, Control, and Decision Support / Świątek Jerzy [i in.] ( red. ), 2014, Oficyna Wydawnicza
Politechniki Wrocławskiej

Bluemke Ilona, Niepostyn Stanisław Jerzy: From Three Dimensional Document Circulation Diagram
into UML Diagrams, w: Emerging Trends in Computing, Informatics, Systems Sciences, and
Engineering / Sobh Tarek, Elleithy Khaled ( red. ), Lecture Notes in Electrical Engineering

Niepostyn Stanisław Jerzy, Bluemke Ilona: The Function-Behaviour-Structure Diagram for Modelling
Workflow of Information Systems, w: Advanced Information Systems Engineering Workshops / Bajec
Marko, Eder Johann (red.), Lecture Notes in Business Information Processing

Niepostyn Stanisław Jerzy: BPMN-XPDL Transformation using Three Dimensional DCD Model, w:
Information Systems Architecture and Technology, Information as the Intangible Assets and Company
Value Source / Wilimowska Zofia [i in.] ( red. ), 2011, Wrocław University of Technology
Cel i motywacja
Stan obecny budowy systemów IT

Budowa systemów informatycznych rozpoczynana jest często na
podstawie wstępnej architektury oprogramowania
(np. tylko przypadki użycia, wyłącznie procesy biznesowe, bądź
tylko opis tekstowy)

Właściciele systemów informatycznych, którzy chcą wdrożyć
(zbudować) IT, otrzymują jedynie informacje praktycznie
o przewidywanym koszcie i czasie trwania budowy i wdrożenia IT,
bez opisu metody budowy oprogramowania (architekturze
oprogramowania), stąd przed zawarciem umowy nie mają
możliwości oceny sposobu realizacji SI przez poszczególnych
Wykonawców i muszą polegać wyłącznie na zaufaniu do wiedzy
i doświadczenia Wykonawcy

Systemy Informatyczne opisywane są bardzo często dopiero po
ich zbudowaniu (wdrożeniu), przy czym takie opisy są zazwyczaj
niespójne i niekompletne, a wynikowa jakość i wartość
dokumentacji – niewielkie.
Cel i motywacja
Koncepcja CMDA
 Automatyzacja budowy systemów IT sterowana regułami
spójności diagramów projektowych UML (BPMN) –
Consistent Model Driven Architecture (CMDA)
 Istnieje taki uporządkowany szereg diagramów UML
(BPMN), który umożliwia automatyzację budowy
systemu informatycznego
 Taki uporządkowany szereg diagramów UML oparty jest
na regułach spójności i kompletności modeli UML w ten
sposób, że można pokazać reguły odwzorowujące
nawzajem elementy pomiędzy sąsiednimi diagramami
Cel i motywacja
Przeznaczenie CMDA
 Zaprezentowanie metodyki budowy oprogramowania
 Ocena wiarygodności utworzonej architektury
oprogramowania
 Brak przedstawienia architektury systemu IT za
pomocą szeregu uporządkowanych diagramów UML
znacznie zwiększa ryzyko niepowodzenia wdrożenia
Proces biznesowy
Podejścia: ekonomiczne, zarządzanie organizacją, inżynierskie
Proces biznesowy
Definicje









1987 r. - Pall
1993 r. - Davenport
1993 r. - Hammer and Champy
1995 r. - Jacobson
1995 r. - Ould
1999 r. - Workflow Management Coalition
2001 r. - Fan
2005 r. - Wang and Wang
2011 r. – Object Management Group (standard
BPMN)
Proces biznesowy
Definicje: Davenport, Hammer and Champy
 1993 r. – Davenport
Proces biznesowy jest zdefiniowany jako łańcuch
działań, których ostatecznym celem jest produkcja
konkretnej wartości wyjściowej dla konkretnego klienta
lub rynku
 1993 r. - Hammer and Champy
Proces biznesowy jest zbiorem czynności, ma jeden lub
więcej rodzajów wejść i tworzy wartość wyjściową dla
klienta. Proces biznesowy posiada swój cel, a oddziałują
na niego zdarzenia zachodzące w świecie zewnętrznym
lub w innych procesach
Proces biznesowy
BPM: Business Process Management
 2003 r. – Wili van der Aalst
Business Process Management (BPM) to wiedza o
metodach, technikach, narzędziach do projektowania,
uruchamiania, kontroli i analizy procesów biznesowych
 2003 r. – cykl życia BPM – Wili van der Aalst

Projektowanie (process design)
analiza aktualnego stanu organizacji i utworzenie modelu w oparciu o stan
systemu informacyjnego „AS-IS”

Konfiguracja (system configuration)
implementacja modeli w systemie BPMS

Uruchomienie (process enactment)
wdrożenie i uruchomienie procesów biznesowych

Optymalizacja (diagnosis)
upraszczanie przepływów i usuwanie „wąskich gardeł”
Proces biznesowy
Business Process Management vs. Workflow Management
Architektura oprogramowania
Rational Unified Process – business process
Architektura oprogramowania
Model 4 + 1
Koncepcja CMDA
Perspektywy i wymiary architektury oprogramowania
 Architektura składa się z wielu modeli
opisujących wybrane zagadnienia (ang.
separation of concern – Hursh, Lopes 1995 r.)
 Uproszczony model perspektyw architektonicznych „4 + 1” (podstawa metodyki RUP-1998 r.):

Perspektywa biznesowa (scenariuszy), systemowa
(projektowa), implementacyjna, wdrożeniowa
 Każda perspektywa powinna opisywać trzy
wymiary (FSB framework, John Gero – 1990 r.):



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, subpackage - functionality)
Koncepcja CMDA
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.
Reguły spójności modeli UML
Szereg uporządkowanych diagramów UML
Author, Year
Egyed 2000
Sapna 2007
Ibrahim 2012
Ha 2008
Shinkawa 2008
Chanda 2009
Hausmann 2002
Sequence of
diagrams
P(CQ|CO|CS)
C(S|U(A|Q))
UQC
O(Q|A|I)
UAQS
UAC
UAO
Number of
consistency rules
50
18
8
7
4
4
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
Oznaczenia elementów, wyrażenia regularne jako reguły
 a-aktor
 q-komponent
 c-klasa
 y-interface
 e-zdarzenie
 w-urządzenie/węzeł
 f-atrybut
 x-klasyfikator
 h-metoda
 n-związek
 i-instancja
Niektóre stereotypy:
 v<<start>>
 v<<data>>
 v<<process>>
 l-lifeline
 m-komunikat
 o-occurence
 p-partycja
 s-stan
 t-przejście stanów
 u-przypadek użycia
 v-czynność
Przykład reguły dla B:
 u{1}[a1-aN] albo Bu{1}[a1-aN]
Przykład ogólnej reguły dla BA:
 BaApHUa
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)
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
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 (John Gero – 1990 r.)
 Warunek wystarczającej spójności
 transformacje (mapowanie) od diagramu na najwyższym poziomie
abstrakcji (diagram kontekstowy - Sanford Friedenthal, Howard
Lykins, Abe Meilich - 2001) , aż do wynikowego kodu aplikacji,
powinny spełniać definicje spójności:
 między diagramami – według definicji Spanoudakis’a i Zisman’a
(interpretacje) oraz Fryza i Kotulskiego (powiązania),
 dla diagramu strukturalnego – według definicji Berarrdi’ego,
 dla diagramu behawioralnego – według definicji Jurack’a,
 dla diagramu funkcjonalności – według definicji Hausmann’a.
Szereg uporządkowanych diagramów
Kompletny i spójny opis architektury oprogramowania
stom Diagrams Sequence
Business view
{X} Context Diagram: Activ ity Diagram
«derive»
«derive»
{R} Decomposition Process Diagram: Activ ity Diagram
{B} Business Use Case Diagram: Use Case Diagram
«derive»
XFSB(RSB|BF )AFSB(CS|SB|UF )
1..*
«generated»
«derive»
«generated»
«generated»
{C} Business Obj ect Diagram: Class Diagram
{U} System Use Case Diagram: Use Case Diagram
«derive»
System view
UF ZFSB(JS|TB|YF )
1..*
{A} FSB UML Business Diagram: Activ ity Diagram
«InformationDependency»
1..*
{Z} FSB UML System Diagram: Activ ity Diagram
«generated»
{Y} Internal Use Case Diagram: Use Case Diagram
«derive»
Component view
YF QFSBMFSBDFSB
«generated»
«generated»
{J] System Obj ect Diagram: Class Diagram
{S} Business Obj ect Behav iour Diagram: State Machine Diagram
{T} System Obj ect Behav iour Diagram: State Machine Diagram
1..*
{Q} FSB UML Component Diagram: Sequence Diagram
«derive»
{M} Component Diagram: Component Diagram
«derive»
{D} Deployment Diagram: Deployment Diagram
XFSB(RSB|BF )AFSB(CS|SB|UF )ZFSB(JS|TB|YF )QFSBMFSBDFSB
Transformacje perspektywy biznesowej
Szereg XR: XFSB(RFSB|BF)AFSB(CS|SB|UF)
Reguły kompletności diagramu kontekstowego: Reguły kompletności diagramu dekompozycji
procesów: {B} Rv<<subprocess>>+; {F}
{B} Xv<<process>>{1}; Xi<<rule>>+; {F} Xe+;
Re<<subevent>>+; {S} Ri<<subproduct>>+;
{S} Xi<<product>>+; Xi<<datastore>>+
analysis Context2Decomposition
Context Diagram
Decomposition Diagram
XeRe<<subevent>>
decomposition into Product 1.2
decomposition into Product 1.1
decomposition into Subprocess 1
decomposition into Event 1.1
decomposition into Event 1.2
Business
rules
Event 1.1
Subprocess 1
Product 1.1
Xev<<process>>{1}R[v1<<subprocess>>-v2<<subprocess>>]
Event 1
Event 1.2
Product 1
Event 2
Main
Process
Subprocess 2
Product 2
Product 2
Event n
decomposition into Product 2
Repository
decomposition into Subprocess n
Event n
Subprocess n
decomposition into Event n
decomposition into Subprocess n
Xi<<rules>>v<<process>>{1}i<<product>>Ri<<subproduct>
Product 1.2
Szereg XR dla systemu e-IRZ
act Szereg XR
Xi(Informacje o kontrolach na miejscu)Ri(Raport z kontroli)
XeRe<<subevent>>
ha rmogra m kontrol i
ma s owe typowa ni e
ra port z kontrol i
Di a gra m dekompozycji proces ów
Raport z kontroli na
miejscu
:Raport z kontroli
[Za twi erdzony]
wymóg wza jemnej
zgodnoś ci
:WzSE
[Za twi erdzony]
Zgłos zeni e s i edzi by s tada
decyzja PLW
pi s mo PLW
Di a gra m konteks towy
Ra port z kontrol i
Regulacje UE,
krajowe
oś wi a dczeni e Producenta
IRZ
Xe(Zgłoszenie siedziby stada)v(IRZ){1}Rv(Zgłoszenie siedziby stada)
Tra ns fer zwi erząt
Informacje o zwierzętach
Zgłos zeni e
przemi es zczeni a
Zgłos zeni e utyl i za cji
Zgłos zeni e rejes tra cji
Informacje o identyfikatorach
Xe(Zgłoszenie zwierzęce)v(IRZ){1}Rv(Zgłoszenie zwierzęce)
«za s ób»
Repozytorium
«za s ób»
Zasoby
a ktua l i za cja
s tanu
dzi a ła l noś ci
pi s mo Producenta
Informacje o kontrolach na miejscu
Informacje o posiadaczach i siedzibach stad
Za potrzebowa ni a
IRZ
Za pytani e o da ne
:ZaswRSS
[Wyda ny]
Xev<<process>>{1}R[v1<<subprocess>>-v5<<subprocess>>]
Zgłos zeni e
s i edzi by s tada
Zgłos zeni e
zwi erzęce
Zgłoszenie siedziby
stada
Zgłos zeni e
wyrejes trowa ni a
:Pass
[Wyda ny]
Zgłoszenie
zwierzęce
wydruk
dupl i ka tu zda rzeni a
pa s zportu a ktua l i zujące
ś l edzeni e
wykorzys tani a
pul i
i dentyfi ka torów
pul a kol czyków
dupl i ka t pa s zportu
pul a dupl i ka tów kol czyków
:WzSD
[Za twi erdzony]
Zapotrzebowania
IRZ
numer dl a drugi ego
kol czyka
:Prz
[Wyda ny]
:Wyr
[Wyda ny]
:Pula
[Wyda ny]
:Kol
[Wyda ny]
Xe(Zapytanie o dane)v(IRZ){1}Rv(Udostępnianie danych)
Za pytani e o da ne
Udostępnianie
danych
Informacje IRZ
Xi(Informacje o identyfikatorach)Ri(Kolczyk)
Xi(Informacje o identyfikatorach)Ri(Pula)
Xi<<rules>>v<<process>>{1}i<<product>>Ri<<subproduct>
Szereg XB: XFSB(RFSB|BF)AFSB(CS|SB|UF)
Reguły kompletności diagramu kontekstowego:
{B} Xv<<process>>{1}; Xi<<rule>>+; {F} Xe+;
{S} Xi<<product>>+; Xi<<datastore>>+
Reguły kompletności diagramu biznesowych
przypadków użycia: {F} Bu+; Ba+
analysis Context2BuseCases
Context Diagram
UseCase Diagram
XeBu
XeBa
UC1. Subprocess 1
Business
rules
«business actor»
Actor1
Event 1
Product 1
Event 2
Main
Process
UC2. Subprocess 2
Product 2
«business actor»
Actor2
Xi<<product>>Ba
Event n
Xi<<rules>>v<<process>>Bu
Repository
UCn. Subprocess n
«business actor»
Actorn
Szereg XB dla systemu e-IRZ
act Szereg XB
XeBa
Di a gra m bi znes owych przypa dków użyci a
Ra port z kontrol i
Di a gra m konteks towy
Xe(Zapotrzebowania IRZ)v(IRZ){1}Bu(Zapotrzebowania IRZ)
Regulacje UE,
krajowe
Informacje o kontrolach na miejscu
Zgłos zeni e
s i edzi by s ta da
IRZ
Zgłos zeni e
zwi erzęce
Informacje o zwierzętach
UC3. Zapotrzebowania za potrzebowa ni a
IRZ
Dostawca
kolczyków
a kcepta cja ,
decyzje
Informacje o posiadaczach i siedzibach stad
Za potrzebowa ni a
IRZ
Za pyta ni e o da ne
Sys tem IRZ TO-BE
rea l i za cja
za mówi eni a
UC2. Zgłoszenie
zwierzęce
UC4. Raport z
kontroli
Informacje o identyfikatorach
«za s ób»
Repozytorium
«za s ób»
Zasoby
Posiadacz
zgła s za
zwierząt
zda rzeni a i
zmi a ny
generuje, drukuje, wprowa dza , za twi erdza
Pracownik IW
Pracownik ARiMR
Xev<<process>>Bu
UC1. Zgłoszenie
siedziby stada
UC5. Udostępnianie
danych
rejes truje s i edzi by s ta d
Xe(Zapytanie o dane)v(IRZ){1}Bu(Udostępnianie danych)
Producent
Szereg RA: XFSB(RFSB|BF)AFSB(CS|SB|UF)
analysis Decomposition2FSBModel
Re<<subevent>>Ap<<vertical>>
{A} BPMN Process Diagram - UC1. Subprocess 1
«Lane» Request 1
Decomposition Diagram
Event 1.1
Subprocess 1
Start
«Lane» Partition1.1
Re<<subevent>>Ap<<horizontal>>+
Rv<<subprocess>A
«Lane» Product 1
1.1. Task1
Request 1
[Received]
Product 1.1
Ri<<subproduct>>Ap<<vertical>>
Event n
Subprocess 2
Subprocess n
Product 2
Product1
[Created]
1.3. Task 3
Request 1
[Approved]
Product1
[Verified]
Product 1.2
Event 1.2
1.2. Task2
1.4. Task4
End
Product1
[Approved]
act System IRZ - dekompozycja procesu głównego
ha rmogra m kontrol i
Szereg RA dla systemu e-IRZ
ma s owe typowa ni e
Raport z kontroli na
miejscu
ra port z kontrol i
:Raport z kontroli
[Za twi erdzony]
wymóg wza jemnej
zgodnoś ci
Re(decyzjaPLW)
Ai(PLW)
:WzSE
[Za twi erdzony]
Zgłos zeni e s i edzi by s ta da
act Szereg RA
decyzja PLW
Zgłoszenie siedziby
stada
Business Process Rejestracja siedziby stada
Producent
pi s mo PLW
:ZaswRSS
[Wyda ny]
oś wi a dczeni e Producenta
zgłos zeni e
dokumentu
pa pi erowego
wypełni eni e
os ku
przez
a wni
ktua
l i za
cja
Internet
pi s mo Producenta
powi a domi eni e
System
Kancelaryjny
Producenta
:WzSD
[Za twi erdzony]
Informa cje o
wprowa dza ni u
s ta nu
dzi a ła l noś ci
Tra ns fer zwi erząt
Ri(ZaswRSS)
Ai(ZaswRSS)
Informa cje o
za twi erdzeni u
:Pass
[Wyda ny]
Rv(Zgłoszenie siedziby stada)A(BPMN)
Zgłos zeni e
Zgłoszenie
pobra ni e
przemi
es zczeni a
:Prz
rejes tra cja
rejes tra cja
utworzeni e
numeru
zgłos zeni e
Wezwa ni e
zwierzęce
pi s ma ze
pi s ma z wyja ś ni eni a
dokumentu
dokumentu
powi
a
domi
eni
e
dokument
[Wyda
ny]
dokumentu
producenta
do
s tanowi s ki em
Zgłos
zeni
e
utyl
i
za
cji
pytani em
ka ncel a ryjnego
el es ktroni czny
pa pi erowego pa pi erowego
wyja ś ni eniProducenta
a
PLW
do PLW
rejes tra cja
dokumentu
Zgłos zeni e rejes tra cji
:Wyr
Start
zdaA3.1,
rzeni aA4.2, A10.2,
ka ncel a ryjnego
A1.2,
[Wyda
ny]
Zgłos
zni
e
:ZS12
A5.2,
A12.1,
a ktua
l i zujące
A11.2, A12.2, :WzSD
:WzSE
KnM zwi erzęce
[Za rejes trowa ny] Zgłos zeni e
A13.1, A.14.2, A13.2, A14.3, [Za twi erdzony]
:WzSE
[Za twi erdzony]
wydruk
A15.2, A16.1, A15.3, A16.2,
wyrejes
trowa
[Za rejes
trowani
ny]a
ś l edzeni
e
Anul owa ni e
A17.1
A17.2
dupl i ka tu
Pracownik BP ds. IRZ
1. Powi ąza ni e
ze s pra wą
ARiMR
pa s zportu
pul
a kol czyków
:WzSD
[Za rejes trowa ny]
i dentyfi ka torów
dupl i ka t pa s zportu
A1.1,
A5.1,
A14.1,
A15.1
:PLW
[Za rejes trowa ny]
Zapotrzebowania
IRZ
pul a dupl i ka tów kol czyków
numer:ZS12
dl a drugi ego
[Wyja
ś ni ony]
kol
czyka
wykorzys ta ni a
pul i
2. Wprowa dzeni e da nych
A2.2,
A6.2
A1.3.
Pos tępowa ni e
wyja ś ni a jące
Za pytadecyzja
ni e o da ne
nowy
Ki erowni ka
wni os ek
Błędy
oczywi s te
:ZS12
[Wyja ś ni a ny]
:ZS12
[Wprowa dzony]
Udostępnianie
danych
:WzSD
[Wprowa dzony]
Koni ec
:OPr
[Za rejes trowa ny]
A7.2,
:ZS12
[Za pi s a ny]
A2.3.
Powi a domi eni e
Producenta
:WzSE
[Wprowa dzony]
A4.3.
Anul owa ni e
:ZS12
[Anul owa ny]
utworzeni e
dokumenty
ka ncel a ryjnego
A4.4,
A5.4,
A10.3,
A18.4
Koni ec
3. Za:Pula
twi erdzeni e
[Wyda ny]
bra k
a kceptacji
Błędy
za s a dni cze
a nul owa ni e
dokumentu
ka ncel a ryjnego
:Kol
zmi a nany]
s tatus u
[Wyda
epi zootycznego
l ub s tanu
dzi a ła l noś ci
kol ejna
sInformacje
i edzi ba
IRZ
pod
jednym
a dres em Koni ec
4. Wyda ni e
dokumentów
:ZS12
[Za twi erdzony]
:Za s wRSS
[Za twi erdzony]
:ZS12
:ZS12
[Za a kceptowa ny]
[Akceptowa ny]
:Odmowa RSS
[Wyda na ]
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>>
analysis BUseCase2FSBDiagram
UseCase Diagram
Business FSB UML Diagram - UC1. Subprocess 1
Request 1
BaApH
Product 1
UC1. Subprocess 1
BuA
Partition 1.1
Start1
«business actor»
Actor1
1.1. Activ ity
:Request 1
[Received]
Annotation
1.2. Activ ity
:Product 1
Partition 1.2
[Created]
:Request 1
1.3. Activ ity
[Approved]
:Product 1
[Verified]
1.4. Activ ity
Partition 1.3
tags
Actor =
Description =
Event =
Postcondition =
Precondition =
Scenario =
State =
UObject =
:Product 1
[Approved]
Final1
Szereg BA systemu e-IRZ
act Szereg BA
Ba(Producent)ApH(Producent)
Producent
zgłos zeni e
dokumentu
pa pi erowego
Sys tem IRZ TO-BE
UC3. Zapotrzebowania za potrzebowa ni a
IRZ
UC2. Zgłoszenie
zwierzęce
UC4. Raport z
kontroli
Posiadacz
zgła s za
zwierząt
zda rzeni a i
zmi a ny
generuje, drukuje, wprowa dza , za twi erdza
Pracownik IW
Pracownik ARiMR
UC1. Zgłoszenie
siedziby stada
Informa cje o
wprowa dza ni u
pobra ni e
rejes tra cja
rejes tra cja
numeru
zgłos zeni e
Wezwa ni e
pi s ma ze
pi s ma z wyja ś ni eni a
powi a domi eni edokument
dokumentu dokumentu
do
s tanowi s ki em pytani emproducenta
el es ktroni czny
pa pi erowego pa pi erowego
wyja ś ni eniProducenta
a
PLW
do PLW
rejes tra cja
dokumentu
Start
ka ncel a ryjnego
Zgłos zni e
:ZS12
KnM zwi erzęce
[Za rejes trowa ny]
:WzSE
[Za rejes trowa ny]
utworzeni e
dokumentu
ka ncel a ryjnego
A1.2, A3.1,
A5.2, A12.1,
A13.1, A.14.2,
A15.2, A16.1,
A17.1
UC5. Udostępnianie
danych
rejes truje s i edzi by s ta d
Ba(Pracownik ARiMR)ApH(ARiMR)
:WzSD
[Za rejes trowa ny]
1. Powi ąza ni e
ze s pra wą
Producent
Dostawca
kolczyków a kcepta cja ,
decyzje
ARiMR
rea l i za cja
za mówi eni a
wypełni eni e
wni os ku przez
Internet
powi a domi eni e
Producenta
System
Kancelaryjny
Di a gra m bi znes owych przypa dków użyci a
A2.2,
A6.2
:ZS12
[Wyja ś ni ony]
A1.3.
Pos tępowa ni e
wyja ś ni a jące
decyzja
nowy
Ki erowni ka
wni os ek
:PLW
[Za rejes trowa ny]
:ZS12
[Za pi s a ny]
do
rejes tra cji
Kierownik BP
A6.3. Weryfi ka cja
decyzji o rejes tra cji
s i edzi by s tada
Koni ec
s tanowi s ko
PLW
PLW/Organy
Ba(Pracownik IW)ApH(PLW)
Błędy
oczywi s te
Błędy
za s a dni cze
:ZS12
[Wprowa dzony]
:ZS12
[Wyja ś ni a ny]
:WzSD
[Wprowa dzony]
Koni ec
A7.2,
A8.2,
A9.2
:ZS12
[Za konczony]
3. Za twi erdzeni e
bra k
a kceptacji
A1.1,
A5.1,
A14.1,
A15.1
:OPr
[Za rejes trowa ny]
Bu(Zgłoszenie siedziby stada)A(BPMN)
A4.2, A10.2,
A11.2, A12.2, :WzSD
:WzSE
A13.2, A14.3, [Za twi erdzony]
[Za twi e
A15.3, A16.2,
An
A17.2
za pytani e o
s tanowi s ko
A2.3.
Powi a domi eni e
Producenta
A7.3
nowy
wni os ek
zmi a na s tatu
epi zootyczneg
l ub s tanu
dzi a ła l noś ci
kol ejna
s i edzi ba
pod
jednym
a dres em Koni ec
:WzSE
[Wprowa dzony]
ZS12
[Za mkni ety]
:ZS12
[Błedny]
:ZS12
[Zweryfi kowa ny]
Zmi a na s tatus u
epi zootycznego
:Odmowa RSS
[Za twi erdzony]
A5.3. Odmowa
Zmi a na
s tanu
dzi a ła l noś ci
Potwi erdzeni e
zmi a ny s tanu
dzi a ła l noś ci
Szereg A(C|S|U)
act FSB Diagram
Class Diagram
Class A (Opinion)
Class C (Reply)
Class B (Request)
«trace»
«trace»
«trace»
FSB UML Diagram
Customer
Partition A (Opinion)
Partition B (Request)
ApVCc
AnCn
AvCh
Av<<data>>Cf
Partition 2 (Clerk)
3. Creating
Opinion
Partition C (Reply)
1. Creating
Request
Receiv ing
Reply
Start
Fi nal
:Class B
(Request)
[Creati ng]
:Class B
(Request)
[Checki ng]
:Class C
(Reply)
[Sendi ng]
UseCase Diagram
2. Checking
Request
UC2. Creatng
opinion
AvUu
:Class A
(Opinion)
[Creati ng]
UC1. Checking
request
«trace»
Clerk
5. Archiv ing
Opinion
7. Archiv ing
Request
8. Creating
Reply
10. Sending
Reply
:Class A
(Opinion)
[Approvi ng]
:Class B
(Request)
[Approvi ng]
:Class C
(Reply)
[Creati ng]
:Class C
(Reply)
[Approvi ng]
UC6. Sending
reply
Partition 1 (Supervisor)
UC4. Creating
reply
4. Approv ing Opinion
Ini ti al
StateMachine Diagram
Ini ti al
AnISt
Ini ti al
C.SM1
(Creating)
B.SM1
(Checking)
A.SM1
(Creating)
C.SM2
(Approv ing)
A.SM2
(Approv ing)
Fi nal
UC5. Approv ing
reply
9. Approv ing Reply
ApHUa
AiSs
6. Approv ing
Request
ApHvUn
B.SM2
(Approv ing)
C.SM3
(Sending)
Fi nal
Fi nal
«trace»
Superv isor
UC3. Approv ing
case
Szereg A(C|S|U) systemu e-IRZ
uc Zgłoszenie siedziby stada
e-IRZ
«i nterna l »
«i ncl ude» UC1.15. Kontrola
zgłoszenia SS
«i ncl ude»
«i nterna l »
UC1.12. Rejestracja
wchodzącego
dokumentu
kancelaryjnego
«i nterna l »
UC1.11. Pobranie
danych z Rejestru
Kancelaryjnego
«i ncl ude»
«i nterna l »
UC1.13. Aktualizacja
danych sprawy
UC1.3. Wprowadzanie
danych
«i ncl ude»
«i ncl ude»
«i ncl ude»
«i ncl ude»
«i ncl ude»
Sta rt
KnM
«common»
UC1.1. Określenie
sprawy
Zgłos zni e
zwi erzęce
UC1.4. Zatwierdzenie
«i nterna l »
UC1.19. Rejestracja
wychodzącego
dokumentu
kancelaryjnego
«i nterna l »
rejestru zgłoszeo siedzib
stad
UC1.5. Wydanie
dokumentów
«i ncl ude»
«i ncl ude»
«i nterna l »
rejestrów zaświadczeo
siedzib stad
«i nterna l »
«i ncl ude»
UC1.24. Wprowadzanie
danych - dokumenty
elektroniczne
A4.3.
Anul owa ni e
UC1.2 Powiązanie ze
sprawą
Anul owa ni e
Błędy
Błędy
oczywi s te
za s a dni cze
«i nterna l »
UC1.23. Odmowa
rejestracji zgłoszenia
A1.3.
Pos tępowa ni e
wyja ś ni a jące
«i nterna l »
UC1.21. Zamknięcie
zgłoszenia siedziby
stada
decyzja
Ki erowni ka
nowy
wni os ek
UC1.6. Postępowanie
wyjaśniające
«i ncl ude»
«i ncl ude»
Koni ec
A2.3.
Powi a domi eni e
Producenta
UC1.8. Weryfikacja
decyzji o rejestracji
siedziby stada
UC1.10. Odmowa
do
rejes tra cji
A6.3. Weryfi ka cja
decyzji o rejes tra cji
s i edzi by s ta da
Koni ec
«i ncl ude»
«i n
UC1.16.
rejes
«i ncl ude»
«i nterna l »
UC1.18. Anulowanie
zgłoszenia
«common»
UC1.1. Określenie
sprawy
«i ncl ude»
«i nterna l »
UC1.11. Pobranie
danych z Rejestru
Kancelaryjnego
«i ncl ude»
UC1.6. Postępowanie
wyjaśniające
«i ncl ude»
4. Wyda ni e
dokumentów
bra k
a kcepta
ude»
«i nclcji
«i ncl ude»
Kierownik BP
ARiMR
3. Za twi erdzeni e
«i ncl ude»
«i nterna l »
ude» Rejestracja
«i nclUC1.12.
wchodzącego
dokumentu
kancelaryjnego
«i ncl ude»
«i nterna l »
danych sprawy
«i ncl ude»
UC1.7.
Koni ec
Powiadomienie
Producenta
«i ncl ude»
1. Powi ąza ni e
ze s pra wą
UC1.2 Powiązanie ze
sprawą
«i nterna l » «i ncl ude»
UC1.17. Anulowanie
dokumentu
kancelaryjnego
«i ncl ude»
UC1.5. Wydanie
dokumentów
«i nterna l »
Pracownik BP ds.
rejestrów IRZ
IRZ
«i nterna l »
UC1.19. Rejestracja
wychodzącego
dokumentu
kancelaryjnego
«i ncl ude»
zmi a na s ta tus u
epi zootycznego
UC1.3. Wprowadzanie
l ub s ta nu
danych
dzi a ła l noś ci
kol ejna
«i nterna l »
«i ncl ude»
s i edzi ba pod
«i nterna l »
UC1.4. Zatwierdzenie
jednym
ude»
ncl
«i
zaświadczeo
rejestrów
UC1.22. Akceptacja
a dres em
Posiadacz
siedzib stad
zgłoszenia
«i nterna l »
zwierząt/Producent
Koni ec
«i ncl ude»
«i ncl ude»
rejestru zgłoszeo siedzib
«i ncl ude»
«i ncl ude»
stad
«i nterna l »
«i nterna l »
«i nterna l »
Kontrola
UC1.15.
Akceptacja
UC1.9.
UC1.18. Anulowanie
UC1.17. Anulowanie
«i ncl ude»
zgłoszenia SS
zgłoszenia
dokumentu
«externa l »
kancelaryjnego
«i ncl ude»
Kancelaria
dokumenty
«i ncl ude»
«i ncl ude»
«i ncl ude»
«i nterna l »
UC1.24. Wprowadzanie
danych - dokumenty
elektroniczne
«i ncl u
el ektroni czne
UC1.7.
Powiadomienie
Producenta
A18.3. Akcepta cja
nowy
wni os ek
«i nterna l »
UC1.22. Akceptacja
UC1.9. Akceptacja «i ncl ude»
zgłoszenia
«i ncl ude»
A5.3. Odmowa
«i ncl ude»
UC1.10. Odmowa
Kierownik BP
ApHUa
«i nterna l »
UC1.23. Odmowa
rejestracji zgłoszenia
«i nterna l »
UC1.21. Zamknięcie
zgłoszenia siedziby
stada
«i ncl u
UC1.8. Weryf
decyzji o reje
siedziby st
act Szereg AC
«externa l »
Model Dziedziny::DokumentKancelaryjny
Model Dziedziny::SiedzibaStada
Rejes tr Dzi a łekRejes tr
Rejes tr
ków
Ewi dencyjnych Pełnomocni
Producentów
EP
LPIS
EP
-
Rejes tr
Za ka zów
Sądowych
Rejes tr Rejes tr
Rejes tr
Si edzi bSta dZwi erząt Pos tępowa o
s ta tus
epi zootyczny
Rejes tr
Decyzji
:PLW
PLW
[Za rejes trowa ny] da ne
:ZS12
[Wprowa dzony]
:ZS12
[Za rejes trowa ny]
2. Wprowa dzeni e
da nych
:WzSD
[Za rejes trowa ny]
:ZS12
[Wyja ś ni ony]
błędy
Rejes tr
Błędów
:ZS12
[Zweryfi kowa ny]
da ne
nowy
dokument
nrDokumentu :cha r
da ta Wpl ywu :Da ta
typDokumentu :typDokumentu
s pos ob :i nt
da ta Stempl a :Da ta
a dnota cja :cha r
da ta Rejes tra cji :Da ta
da ta Sys temu :Da ta
RWA :cha r
Model Dziedziny::
ZgloszenieSiedzibyStada
Rejes tr
Zgłos zeo
Si edzi b
Sta d
ma tka ,
da wczyni ,
da wca
:ZS12
[Błedny]
:OPr
[Za rejes trowa ny]
-
:WzSD
da ne[Wprowa dzony]
:WzSE
[Wprowa dzony]
:WzSE
[Za rejes trowa ny]
CzyWyna jem :bool ea n
nrGIW :Stri ng
NumerRzezni :Stri ng
numerSi edzi bySta da :Stri ng
opi s Loka l i za cji :Stri ng
Upra wni eni a Bydl o :Bool ea n
Upra wni eni a Kozy :Stri ng
Upra wni eni a Owce :Stri ng
Upra wni eni a Swi ni e :Bool ea n
typDzi a l a nos ci :i nt
s ta tus Epi zootyczny :i nt
s ta nDzi a l a l nos ci :i nt
da ta Rejes tra cji :i nt
Model Dziedziny::Zwierze
:ZS12
[Wyja ś ni a ny]
Rejes tr
Rejes tr
Oś wi a dczeo Dokumentów
Wchodzących
AiCc
-
numerIdentyfi ka cyjny :Stri ng
da ta Urodzeni a :Da te
l i czba Zwi erza t :i nt
ga tunek :Stri ng
pl ec :Stri ng
da ta Opus zczeni a Sta da :ja va .uti l .Da te
da ta Przybyci a DoSta da :ja va .uti l .Da te
cza s Przebywa ni a WSta dzi e :i nt
s ta tus :i nt
s ta tus Epi zootyczny :i nt
l oka l i za cja :Loka l i za cja zwi erzęci a
-
cel :cha r
numerIdentyfi ka cyjny :cha r
typDzi a l a l nos ci :cha r
Zgl a s za ja cy :i nt
Si edzi ba :cha r
Adres :cha r
Dzi a l ka :cha r
da ta Zgl os zeni a :i nt
podpi s :bool ea n
typWni os kuEpi :cha r
da ta OdBl oka dy :Da ta
da ta DoBl oka dy :Da ta
przyczyna Epi :cha r
przyczyna Dzi :cha r
da ta Dzi Od :Da ta
da ta Dzi Do :Da ta
s ta nDzi :cha r
act Szereg AS
Rejes tr Dzi a łekRejes tr
Rejes tr
ków
Ewi dencyjnych Pełnomocni
Producentów
EP
LPIS
EP
Rejes tr
Za ka zów
Sądowych
Ini ti a l
Rejes tr Rejes tr
Rejes tr
Si edzi bSta dZwi erząt Pos tępowa o
s ta tus
epi zootyczny
Rejes tr
Decyzji
:PLW
PLW
[Za rejes trowa ny] da ne
:ZS12
[Wprowa dzony]
:ZS12
[Za rejes trowa ny]
2. Wprowa dzeni e
da nych
Wprowadzony
Wyjaśniony
Zapisany
Błędny
da ne[Wprowa dzony]
:WzSE
[Wprowa dzony]
:WzSE
[Za rejes trowa ny]
Zweryfikowany
Rejes tr
Zgłos zeo
Si edzi b
Sta d
błędy
Rejes tr
Błędów
da ne
nowy
dokument
:ZS12
[Wyja ś ni a ny]
Rejes tr
Rejes tr
Oś wi a dczeo Dokumentów
Wchodzących
Akceptowany
Anulowany
Zatwierdzony
Zaakceptowany
:ZS12
[Błedny]
:OPr
[Za rejes trowa ny]
:ZS12
[Zweryfi kowa ny]
Wyjaśniany
:WzSD
:WzSD
[Za rejes trowa ny]
:ZS12
[Wyja ś ni ony]
Zarejestrowany
Zamkniety
Zakonczony
AiSs
Fi na l
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
Podsumowanie 1
 Automatyczna budowa systemów informatycznych
możliwa jest przy spełnieniu warunków:

istnieje uporządkowany szereg spójnych diagramów
pogrupowanych w perspektywy

każdy model danej perspektywy posiada kompletny opis w
zakresie funkcjonalności, zachowania i struktury

każdy diagram w szeregu jest wewnętrznie spójny

wszystkie diagramy spełniają reguły spójności w postaci
transformacji elementów pomiędzy diagramami
Podsumowanie 2

Zaprezentowanie metodyki budowy systemu informatycznego, za
pomocą uporządkowanego szeregu spójnych diagramów
projektowych UML, pozwoli na określenie możliwości jej wdrożenia,
bezpieczeństwa wytwarzania oprogramowania, automatyzacji,
uzasadnienie i predykcję czasu wytworzenia systemu.

Przedstawienie systemu informatycznego za pomocą
uporządkowanego szeregu spójnych diagramów projektowych UML
od diagramu kontekstowego do modelu implementowalnego
umożliwi automatyczne wytwarzanie oprogramowania z modeli
budowanych w sposób niewymagający wiedzy programistycznej –
obecnie brak takich rozwiązań

Brak przedstawienia architektury systemu IT za pomocą
szeregu uporządkowanych diagramów UML znacznie zwiększa
ryzyko niepowodzenia wdrożenia systemu IT
Pytania ?
Dziękuję za uwagę
www.project-media.pl

Zastosowanie reguł spójności w modelowaniu

Transkrypt

Podobne dokumenty

Case study

Wersja PDF