Wymagania edytoskie TWZ

Transkrypt

mgr inż. Krzysztof Kluza
mgr inż. Weronika T. Adrian
prof. dr hab. inż. Antoni Ligęza
dr inż. Grzegorz J. Nalepa
dr hab. Marcin Szpyrka
mgr inż. Krzysztof Kaczor
mgr inż. Szymon Bobek
Katedra Automatyki
Akademia Górniczo-Hutnicza w Krakowie
e-mail: {kluza,wta,ligeza,gjn,mszpyrka,kk,sbobek}@agh.edu.pl
Metody modelowania, oceny jakości i weryfikacji
reguł i procesów biznesowych
1. Wprowadzenie
Stosunkowo niedawno dostrzeżono w biznesie potencjał modelowania procesów biznesowych. Projektowanie procesu biznesowego organizacji ma pomóc w odzwierciedleniu sposobu jej działania, przez co zredukować ryzyko stworzenia dla niej systemu, który mógłby nie spełniać stawianych przed nim wymagań. W krótkim czasie powszechnie stosowaną
notacją do modelowania procesów biznesowych stała się notacja BPMN,
a narzędzia ją wspierające stają się coraz bardziej zaawansowane.
Wraz z popularyzacją procesów biznesowych pojawiły się wyzwania dotyczące modelowania logiki systemu wyspecyfikowanego przy pomocy procesów. Jedną z odpowiedzi na te potrzeby jest użycie technologii regułowych, które zyskały szersze uznanie świata biznesu jako reguły
biznesowe. Jednak projektowanie złożonych i zaawansowanych systemów regułowych nadal nastręcza trudności. W ich pokonaniu pomóc
mogą metody wizualnej reprezentacji reguł, a także nowe metody modu-
laryzacji i hierarchizacji bazy wiedzy. W szczególności interesujące może
być wykorzystanie do tego celu procesów biznesowych.
Jednym z istotnych teoretycznych i praktycznych problemów jest
zapewnienie wysokiej jakości systemu. W przypadku systemów regułowych formalizacja reguł pozwala na sformalizowany opis wskaźników jakości i metod weryfikacji. W przypadku procesów biznesowych pojawia
się problem z brakiem jednoznacznie zdefiniowanej semantyki elementów notacji biznesowej.
W artykule poruszono zagadnienia modelowania, oceny jakości
oraz weryfikacji reguł i procesów biznesowych. W podrozdziale 2 dokonano przeglądu wybranych metod modelowania reguł i przedstawiono ich
podstawowe założenia. Opisany został również najpopularniejszy standard do modelowania procesów biznesowych: BPMN (Business Process
Modelling Notation).
W dalszej części w podrozdziale 3 zestawiono czynniki warunkujące jakość reguł i procesów biznesowych. W rozdziale zaproponowano
taksonomię anomalii występujących w systemach regułowych, na podstawie której możliwe jest stworzenie odpowiednich algorytmów weryfikacji. W części tej opisane zostały również podstawowe kategorie, w jakich
rozpatruje się jakość procesu biznesowego oraz przedstawiono szereg wymagań jakości w obrębie tych kategorii.
W podrozdziale 4 zaprezentowano metodę weryfikacji procesów
biznesowych polegającą na odpowiedniej translacji diagramów BPMN do
Sieci Petriego. Wyjaśniona została koncepcja tej metody, jej podstawowe
założenia, algorytm postępowania oraz podstawowe cele weryfikacji.
2. Metody modelowania reguł i procesów biznesowych
Wizualna reprezentacja reguł ma za zadanie pomóc w radzeniu sobie ze złożonością bazy wiedzy. Odpowiednio zmodularyzowana i zhierarchizowana baza wiedzy może stanowić efektywny sposób opisu logiki
systemu, który w sposób całościowy można zamodelować w postaci procesu biznesowego.
2.1.
Wybrane notacje i narzędzia do modelowania reguł biznesowych
Reguły biznesowe (Business Rules)1 definiują lub ograniczają pewne aspekty działań biznesowych. Reguły, które opisują te same aspekty,
zazwyczaj grupuje się w zbiory reguł. Business Rules Group wyróżnia
cztery kategorie reguł biznesowych2:
• definicje terminów biznesowych, które służą uwspólnieniu języka używanego do specyfikacji reguł,
• fakty, które odnoszą się do relacji pomiędzy terminami biznesowymi
(specyfikowane w języku naturalnym lub modelowane graficznie),
• ograniczenia zachowań – służące do ograniczenia aktualizacji danych,
a także do niedopuszczenia do wykonania określonych akcji,
• przekształceniowe – określające w jaki sposób wiedza w jednej formie
może być przekształcona w inną wiedzę, w innej formie.
Istnieje wiele narzędzi związanych z regułami biznesowymi, które
można pogrupować w kilka kategorii3:
1
2
3
S. W. Ambler. Business Rules. http://www.agilemodeling.com/artifacts/businessRule.htm,
2003.
D. Hay, A. Kolber, K. Anderson Healy. Defining business rules ~ what they really are. Final
report. Technical report, Business Rules Group, July 2000.
G.J. Nalepa, Business Rules design and Refinement Using the XTT Approach. W: David C.
Wilson, Geoffrey C. J. Sutcliffe, and FLAIRS [Red.] FLAIRS- 20 : Proceedings of the 20th
International Florida Artificial Intelligence Research Society Conference : Key West, Florida, May 7-9, 2007, s. 536–541, Menlo Park, California, may 2007. Florida Artificial Intelligence Research Society, AAAI Press.
• shelle i silniki wnioskujące (Business Rules Engines), np. Jess,
• języki oparte na XMLu wspierające reprezentację reguł biznesowych
i umożliwiające wymianę pomiędzy różnymi systemami, np. RuleML,
• dedykowane metody reprezentacji – narzędzia do wizualnego modelowania reguł, np. opisany w dalszej części język URML oraz narzędzie
go wspierające – Strelka,
• rozwiązania zintegrowane (Business Rules Management Systems), np.
ILOG JRules, JBoss Drools.
Podstawowym problemem podczas tworzenia systemu regułowego
jest projektowanie złożonej bazy wiedzy. Do radzenia sobie ze złożonością bazy, składającej się z wielu reguł, pomocna może być wizualna notacja do modelowania4
UML i OCL
UML (Unified Modeling Language)5 stanowi jeden z najpowszechniej używanych w inżynierii oprogramowania wizualnych języków do
modelowania. W języku tym wyróżnić można dwie klasy diagramów: statyczne, które ukazują budowę i strukturę systemu (np. diagramy klas)
oraz dynamiczne, które obrazują zachowanie systemu (np. diagramy aktywności). Choć specyfikacja języka definiuje 13 różnego rodzaju diagramów o znacznej złożoności, nie ma w niej dedykowanych rozwiązań do
modelowania reguł. Również wśród innych języków modelowania nie
zdefiniowano jednolitego standardu do wizualnego modelowania reguł.
4
5
K. Kluza, G.J. Nalepa. Metody i narzędzia wizualnego projektowania reguł decyzyjnych. In
Adam Grzech et al. [Red.] Inżynieria Wiedzy i Systemy Ekspertowe, s. 197–208, Warszawa,
2009. Akademicka Oficyna Wydawnicza EXIT.
Object Management Group, Unified Modeling Language version 2.2. Superstructure. Technical Report formal/2009-02-02, OMG, February 2009.
Dotychczas stosowane podejścia6,7 wykorzystują elementy języka
UML lub język OCL (Object Constraint Language)8. Język OCL nie posiada jednak wizualnej notacji, stanowi natomiast dodatkową notację tekstową do języka UML. Przy jego użyciu można specyfikować m.in. warunki, ograniczenia, a także zapytania wybierające określone elementy
modelu. OCL definiuje typy danych oraz operatory, którymi można się
posługiwać w wyrażeniach.
Rysunek 1. Przykładowy diagram z model UML dla wypożyczalni samochodów
Źródło: Raport własny 9
6
7
8
9
G.J. Nalepa, K. Kluza. UML Representation Proposal for XTT Rule Design Method.
W: Grzegorz J. Nalepa and Joachim Baumeister [Red.] 4th Workshop on Knowledge Engineering and Software Engineering (KESE2008) at the 32nd German conference on Artificial
Intelligence: September 23, 2008, Kaiserslautern, Germany, s. 31–42, Kaiserslautern, Germany, 2008.
L. Nemuraite, L. Ceponiene, G. Vedricka, Representation of Business Rules in UML and
OCL Models for Developing Information Systems. The Practice of Enterprise Modeling,
15:182–196, 2008.
Object Management Group, Object Constraint Language version 2.0. Technical report,
OMG, May 2006.
K. Kluza, Opracowanie przeglądu metod wizualnego projektowania reguł i procesów biznesowych . Raport wewnętrzny opracowany w ramach projektu „Prototyp systemu zarządzania
regułami biznesowymi i technologicznymi” nr UDAPOIG.01.03.01-12-163/08-01 realizowanego w ramach Priorytetu 1., Działanie 1.3. PO IG, Poddziałanie 1.3.1. Zadanie 5: Opracowanie projektu systemu zarządzania regułami biznesowymi i technologicznymi , Kraków, 16
września 2010 .
Istnieje możliwość przedstawienia wybranych reguł biznesowych
wprost na diagramie UML. Rysunek 1 (opracowany na podstawie artykułu z LNI10) przedstawia fragment modelu dla systemu wypożyczalni samochodów, na którym na diagramie klas UML przedstawiono klasy Samochód, Wypożyczenie i Osoba oraz asocjacje pomiędzy nimi. Na diagramie zostały wizualnie ujęte następujące reguły biznesowe:
• Każdy samochód posiada identyfikator pojazdu (atrybut idPojazdu
w klasie Samochód).
• Każdy kierowca może dokonać wielu wypożyczeń, a wypożyczenie samochodu przypisane jest do konkretnego kierowcy (asocjacja pomiędzy klasami Osoba i Wypożyczenie, w której osoba pełni rolę kierowcy; krotność przy asocjacji określa liczebność instancji poszczególnych
elementów biorących udział w relacji).
Niektóre reguły wymagają jednak dodatkowych wyrażeń zapisanych w języku formalnym. Najczęściej do zapisu warunków integralności
modelu UML wykorzystuje się język OCL, i tak na przedstawionym diagramie w notce zapisano regułę: Kierowca musi mieć powyżej 25 lat (niezmiennik: kierowca.wiek>25, odnoszący się do instancji klasy Wypożyczenie).
Mimo swojego formalnego charakteru, język OCL nie wspiera bezpośrednio opisu reguł, zatem pewne reguły muszą być zapisane w postaci
złożonego wyrażenia, np. regułę: Samochód jest dostępny do wypożyczenia, jeśli nie jest przypisany do żadnego wypożyczenia oraz nie wymaga
serwisowania. można zdefiniować w postaci implikacji dla atrybutu określającego dostępność samochodu (atrybut dostępny) – co zostało zapisane w notce komentarza dołączonej do klasy Samochód.
10
G. Wagner, How to Design a General Rule Markup Language. W: XML Technology for the
Semantic Web (XSW 2002), Lecture Notes in Informatics, s. 19–37, HU Berlin, 2002.
Wadą języka OCL jest brak notacji graficznej do modelowania wyrażeń. Tymczasem w przypadku złożonych systemów użycie graficznej
notacji może znacznie zwiększyć czytelność zapisu, w szczególności gdy
reguły mają wspólny kontekst, posiadają wspólne warunki lub konkluzje.
URML
URML (UML-Based Rule Modeling Language)11 stanowi przykład
dedykowanego języka do modelowania reguł. Został on stworzony przez
REWERSE Working Group I112 i pozwala na wizualne modelowanie reguł przy użyciu rozszerzonego o symbol reguły diagramu klas UML.
Rysunek 2. Przykładowy diagram reguły w języku URML
Źródło: http://oxygen.informatik.tu-cottbus.de/rewerse-i1/?q=URML
Przykładowy diagram dla reguły: Kawaler to osoba płci męskiej,
która nie jest mężem (A bachelor is a male that is not a husband)13 został
przedstawiony na Rysunku 2. Regułę na diagramie reprezentuje okrąg z
11
12
13
S. Lukichev, G. Wagner, Visual rules modeling. W: Sixth International Andrei Ershov Memorial Conference Perspectives of System Informatics, Novosibirsk, Russia, June 2006,
LNCS. Springer, 2005.
http://rewerse.net/I1/oxygen.informatik.tu-cottbus.de/rewerse-i1/default.htm , 10-12-2010.
REWERSE Working Group I1, A UML-based Rule Modeling Language. http://oxygen.informatik.tu-cottbus.de/rewerse-i1/?q=URML, 2006.
identyfikatorem reguły, a etykieta określa jej rodzaj (do wnioskowania
wstecz, do wnioskowania w przód, reakcji). Strzałki dochodzące do reguły reprezentują zbiór przesłanek (warunki), a wychodzące reprezentują
zestaw konkluzji (akcje). Warunki definiują sytuację, w której konkluzja
jest spełniona albo w której należy podjąć akcję. Ponadto element związany z danym warunkiem może być ograniczony wyrażeniem (tzn. w warunku mogą być brane pod uwagę np. tylko określone instancje danego
elementu). Z kolei przekreślenie strzałki warunku przy jej początku oznacza jego negację (wymagany jest wtedy dodatkowy warunek pozytywny
zawierający elementy mogące być objęte tą negacją).
W przeciwieństwie do języka OCL, język URML umożliwia modelowanie reguł, które mogą wpływać na sam model i zmieniać go. Na diagramie pokazanym na Rysunku 3 zobrazowano regułę: Jeśli od daty rezerwacji do daty wypożyczenia jest mniej niż 5 dni, ustaw zniżkę w wysokości 10 (If the reservation date of a rental is 5 days before the start date
of a rental, then grant the rental a discount of 10).
Rysunek 3. Przykładowy diagram reguły zmieniającej model w języku URML
Źródło: http://oxygen.informatik.tu-cottbus.de/rewerse-i1/?q=URML
Dla instancji obiektu, która spełnia zadane warunki reguły przypisywana jest nowa wartość atrybutu określającego wysokość zniżki. Choć
w języku OCL nie można zmieniać danych w modelu, istnieje możliwość
zapisania reguły w postaci implikacji, która sprawdzi czy w przypadku
określonych warunków zniżka wynosi 10.
PRR
Innym standardem opisywania reguł, zaproponowanym przez grupę
OMG (Object Management Group) jest standard reprezentacji dla reguł
produkcji – PRR (Production Rule Representation)14. Standard ten nie definiuje jednak wizualnej notacji, ani nawet nie precyzuje składni reguł,
dostarcza jedynie metamodel dla reguł produkcji. Metamodel definiuje regułę produkcji postaci: if [warunek] then [lista akcji],
jako instrukcję logiki programowalnej, która określa wykonanie jednej
lub więcej akcji (co zmienia stan systemu), w przypadku gdy zachodzą
określone warunki.
Specyfikacja w wersji Beta 115 wprowadza co prawda PRR OCL,
czyli bazującą na OCL składnię definiowania reguł, nie czyni jej jednak
obligatoryjną, a przykłady podawane są zarówno w PRR OCL, jak i w języku reguł produkcji składnią przypominającym język Java. Przykład reguły biznesowej zgodnej z PRR (przykładowe definicje zgodne z PRR –
przykład ze specyfikacji z 3 różnymi notacjami dla tej samej reguły)16:
• w języku naturalnym (w tym wypadku angielskim), przykładowa reguła: If there is no CD item in the customer shopping cart then add a hyperlink to the CD page in the customer web page. (Jeśli w koszyku nie
14
15
16
Object Management Group, Production Rule Representation version beta 1. Specification.
Technical Report dtc/07-11-04.pdf, Object Management Group, November 2007.
Ibidem.
Ibidem.
ma żadnej płyty CD, dodaj na stronie użytkownika hiperłącze do strony z płytami CD.)
• w języku PRR OCL, który składnią przypomina język OCL:
Rule noCDItem
ruleVariable:
?customer: Customer = Customer->any()
?sCart: ShoppingCart = ShoppingCart->any(c:customer|c=?customer)
?cdItems: Set = ?sCart.items->select(e:items|e.type=ItemType.CD)
Condition:
?cdItems.isEmpty()
Action:
?customer.hyperlinkToCD = true
• w języku Proprietary rule language:
rule noCDItem {
when {
?customer1: Customer();
?shoppingCart1: ShoppingCart(customer == ?customer1);
not Item(type == ItemType.CD ; shoppingCart == ?shoppingCart1);
} then {
modify ?customer1{ hyperlinkToCD = true; }
}
}
BPMN rule event
W notacji BPMN(Business Process Modeling Notation)17,18, stanowiącej najpopularniejszą notację do wizualnego modelowania procesów
biznesowych, również istnieje możliwość umieszczenia na diagramie reguły w postaci zdarzenia regułowego. Zdarzenie takie definiuje pojedynczą regułę, a przykład jego zastosowania został pokazany na Rysunku 4 –
zadanie Grzanie posiada dodatkowe zdarzenie regułowe: Jeśli temperatura jest większa niż nastawy termostatu, to przestań grzać.
Rysunek 4. Przykładowy diagram BPMN z regułą
Źródło: Raport własny19
HeKatE XTT2
Modelowanie pojedynczych reguł w przypadku złożonych systemów jest bardzo nieoptymalne. W takich wypadkach przydatne jest grupowanie reguł, a zatem modularyzacja bazy wiedzy. Istotnym aspektem
projektowania złożonej bazy wiedzy jest m.in. przejrzystość jej struktury.
17
18
19
Object Management Group, Business Process Modeling Notation. Specification. Technical
Report dtc/06-02-01, OMG, February 2006.
T. Allweyer, BPMN 2.0. Introduction to the Standard for Business Process Modeling. BoD,
Norderstedt, 2010.
września 2010 .
Zazwyczaj projektowanie skupia się na pojedynczych regułach, bez szerszego spojrzenia na strukturę reguł i kontekst ich występowania.
XTT2 (EXtended Tabular Trees)20,21 jest formalizmem reprezentacji
wiedzy regułowej, który pozwala na ustrukturyzowanie bazy reguł poprzez wprowadzenie tabel grupujących reguły posiadające te same atrybuty, oraz łączy pomiędzy tabelami, pozwalających na sterowanie wnioskowaniem. XTT2 stanowi element metodologii HeKatE (Hybrid Knowledge
Engineering)22, a do modelowania stworzony zostało dedykowane narzędzie HQEd (Hekate Qt Editor)23. Na Rysunku 5 pokazano przykładowy
diagram XTT2 w postaci drzewa połączonych ze sobą tabel decyzyjnych.
Rysunek 5. Przykładowy diagram XTT2 w edytorze HQEd
Źródło: Opracowanie własne
20
21
22
23
G.J. Nalepa, A. Ligęza, XTT+ Rule Design Using the ALSV(FD). W: Adrian Giurca, Anastasia Analyti, and Gerd Wagner [Red.] ECAI 2008: 18th European Conference on Artificial Intelligence: 2nd East European Workshop on Rule-based applications, RuleApps2008:
Patras, 22 July 2008, s. 11– 15, Patras, 2008. University of Patras.
G.J. Nalepa, A. Ligęza, A Graphical Tabular Model for Rule-based Logic Programming
and Verification, „Systems Science”, 31(2):89–95, 2005.
G.J. Nalepa, A. Ligęza, HeKatE Methodology, Hybrid Engineering of Intelligent Systems.
„International Journal of Applied Mathematics and Computer Science”, 20(1):35–53, March
2010.
K. Kaczor and G.J. Nalepa, HQEd – wizualne narzędzie wspierające projektowanie systemów ekspertowych opartych o reprezentację XTT. W: Adam Grzech et al. [Red.] Inżynieria
Wiedzy i Systemy Ekspertowe, s. 355–364, Warszawa, 2009. Akademicka Oficyna Wydawnicza EXIT.
Drools
Drools24 to silnik reguł biznesowych, wspierany przez JBoss Community, który składa się z 4 projektów: Guvnor, Expert, Flow i Fusion,
z których każdy wspiera inną część zintegrowanego procesu. Baza wiedzy
w Drools składa się z trzech podstawowych elementów: reguł, tablic decyzyjnych oraz przepływu Drools Flow, który umożliwia sterowanie procesem wnioskowania. Reguły o takim samym schemacie mogą być grupowane w postaci tablicy decyzyjnej, jednakże modelowanie tablicy nie
odbywa się bezpośrednio w narzędziu, lecz wymaga dodatkowego arkusza kalkulacyjnego.
Podsumowanie
Reguły biznesowe mogą być wyrażone na różnym poziomie formalizacji, począwszy od języka nieformalnego, poprzez bardziej rygorystyczny (np. w zastosowaniach technicznych), kończąc na zdaniach logicznych. Stosowanie tego samego poziomu formalizacji w różnych narzędziach ułatwiłoby tłumaczenie reguł pomiędzy różnymi notacjami.
Do dziś nie zdefiniowano jednolitego standardu wizualnego zapisu
reguł biznesowych. W języku UML można wyrazić tylko wybrane reguły,
pozostałe muszą być wyrażone przy pomocy OCL, lecz jest to już notacja
tekstowa. Choć URML daje możliwość zapisu różnego rodzaju reguł,
jego wadą jest rozszerzenie składni języka UML, przez co zdecydowana
większość narzędzi do modelowania nie może być użyta do modelowania.
Problemem jest także słaba skalowalność i brak wsparcia dla modelowania grup reguł w różnych kontekstach.
24
P. Browne, JBoss Drools Business Rules, Packt Publishing, 2009.
W notacji BPMN zdarzenie regułowe służy jedynie zobrazowaniu
tego, że dane zdarzenie oparte jest o regułę, natomiast nie ma zdefiniowanej notacji opisu takiej reguły, a także nie uwzględnia się możliwości grupowania reguł, czy występowania reguły w konkretnym kontekście.
Tabele decyzyjne wydają się niezastąpionym rozwiązaniem jeśli
chodzi o wizualizację grup reguł w kontekście ich występowania.
W szczególności, gdy grupa reguł złożona jest z reguł podobnie zbudowanych, posiadających tego samego rodzaju warunki i konkluzje, tabele
znacznie upraszczają model systemu regułowego. XTT2 łączy w sobie zalety tabel i drzew decyzyjnych. Użycie tabel pozwala na grupowanie reguł należących do wspólnego kontekstu, a zatem modularyzację. Z kolei
wykorzystanie drzewa decyzyjnego umożliwia hierarchizowanie wiedzy
zmodularyzowanej w tabelach decyzyjnych25.
2.2.
Wybrane notacje i narzędzia do modelowania procesów biznesowych
Z regułami biznesowymi coraz częściej wiąże się pojęcie procesów
biznesowych, których logikę one specyfikują. Pewne propozycje dotyczące modelowania procesów biznesowych w powiązaniu z regułami bizne-
25
A. Ligęza. Logical Foundations for Rule-Based Systems. Springer-Verlag, Berlin, Heidelberg, 2006.
sowymi zostały poczynione m.in. w pracach Nalepy26,27,28, jednak dotychczas nie ma ustandaryzowanych rozwiązań w tym zakresie.
Celem procesu biznesowego, rozumianego jako zbiór powiązanych
ze sobą zadań, jest wyprodukowanie określonego produktu lub dostarczenie określonej usługi29. Najpopularniejszą notacją do modelowania procesów biznesowych jest notacja BPMN (Business Process Modeling Notation). Pomimo krótkiej historii, zyskuje ona coraz większą popularność,
co przejawia się m.in. w liczbie narzędzi ją implementujących. Według
grupy OMG istnieje ponad 60 implementacji różnego rodzaju narzędzi
wspierających notację30, z czego część zapewnia dodatkowe możliwości
tj. przeprowadzenia symulacji, analizy, czy optymalizacji procesu. Za
sprawą użycia reguł do modelowania logiki biznesowej technologie regułowe zaczynają obecnie zyskiwać na znaczeniu w tym obszarze.
BPMN
26
27
28
29
30
G.J. Nalepa. Proposal of Business Process and Rules Modeling with the XTT Method,
W: Symbolic and numeric algorithms for scientific computing : SYNASC’07 : 9th international symposium : RuleApps’2007 – workshop on Rule- based applications : Timisoara,
Romania, September 26–29, 2007 : IeAT Technical Report 07-11, s. 17–23, Timisoara :
West University, September 2007. West University of Timisoara, Romania. Department of
Computer Science, University Johannes Kepler, Linz, Austria. Research Institute for Symbolic Computation, Research Institute e-Austria, Timisoara, Romania.
G.J. Nalepa, M.A. Mach. Business Rules Design Method for Business Process Management. W: M. Ganzha and M. Paprzycki [Red.] Proceedings of the International Multiconference on Computer Science and Information Technology, s. 165–170. Polish Information
Processing Society, IEEE Computer Society Press, 2009.
K. Kluza, G.J. Nalepa, Ł.Łysik. Visual inference specification methods for modularized rulebases. overview and integration proposal. W: Grzegorz J. Nalepa and Joachim Baumeister [Red.] 6th Workshop on Knowledge Engineering and Software Engineering (KESE2009) at the 32nd German conference on Artificial Intelligence: September 21, 2010,
Karlsruhe, Germany, s. 6–17, Karlsruhe, Germany, 2010.
M. Piotrowski. Notacja modelowania procesów biznesowych – podstawy, BTC, Legionowo, 2007.
Business Process Management Initiative. BPMN Implementors and Quotes.
http://www.bpmn.org/BPMN_Supporters.htm
Specyfikacja BPMN31 definiuje BPD (Business Process Diagram)
oraz elementy notacji występujące na nim. Elementy te można pogrupować w następujące kategorie (parz: Rysunek 5):
• Obiekty przepływu – podstawowe elementy aktywne, które definiują
zachowanie procesu. Wśród tych elementów wyróżniamy:
− Zdarzenia – dzieją się w trakcie procesu i wpływają na przepływ
sterowania. Przeważnie zdarzenia są wyzwalane albo mają jakiś
rezultat. Mogą rozpoczynać, przerywać lub kończyć przepływ.
− Aktywności – określony fragment większego procesu biznesowego, w którym wykonywana jest określona praca. Ze względu na
wielkość aktywność może być albo pojedynczym zadaniem albo
podprocesem.
− Bramki – używane do kontroli przepływu sterowania.
• Obiekty łączące – połączenia na diagramie pomiędzy elementami, takie jak:
− Przepływ sterowania – reprezentuje przebieg procesu, czyli w jakiej kolejności mają być wykonywane określone aktywności w
procesie.
− Przepływ komunikatów – reprezentuje przesyłanie komunikatu
pomiędzy elementami, z których jeden wysyła, a drugi odbiera
wiadomość.
− Powiązanie – ukazuje powiązanie między artefaktem a obiektem
przepływu.
• Obiekty miejsc realizacji procesu – elementy pozwalające na grupowanie elementów, względem miejsc, w których realizowany jest proces:
31
Object Management Group, Business Process Modeling Notation. Specification. Technical
Report dtc/06-02-01, OMG, February 2006.
− Obiekty uczestników procesu – zawierające elementy procesu.
− Tory – elementy struktury organizacyjnej uczestników procesu.
• Artefakty – dodatkowe elementy na diagramie, służące zobrazowaniu
informacji uzupełniających, takie jak:
− Obiekty danych – wskazujące jakie dane są używane, aktualizowane lub produkowane przez określone aktywności.
− Adnotacje tekstowe – wykorzystywane do uszczegóławiania elementów.
− Grupy – służące do wizualnego grupowania elementów.
Rysunek 5. Kategorie elementów w notacji BPMN
Źródło: Raport wewnętrzny32
Narzędzia do modelowania w BPMN
Coraz więcej firm dostrzega potencjał modelowania procesów biznesowych do projektowania i implementacji systemów informatycznych,
które wspierają działania organizacji. Dzieje się tak głównie za sprawą
32
września 2010 .
tego, że zamodelowanie procesu znacznie redukuje ryzyko stworzenia
systemu, który nie byłby w stanie spełnić celów przed nim stawianych33.
W zależności od udostępnianych funkcji, narzędzia te można zakwalifikować do następujących kategorii34:
• narzędzia do rysowania modelu procesu (np. Microsoft Visio),
• narzędzia do mapowania procesów (np. iGrafx FlowCharter),
• narzędzia do modelowania i symulacji procesów (np. iGrafx Process),
• narzędzia CASE do projektowania systemów informatycznych (np.
Rational Rose),
• narzędzia wbudowane w systemy ERP (np. IFS Bussiness Modeler).
Część narzędzi wspierających notację BPMN zapewnia także dodatkowe możliwości, takie jak35:
• możliwość modelowania w innych notacjach wizualnych niż BPMN,
• symulacja (przy uwzględnieniu dodatkowych parametrów i zasobów),
• optymalizacja procesu pod kątem określonego kryterium,
• serializacja danych do postaci wykonywalnej np. BPEL4WS (Business
Process Execution Language for Web Services)36,37,
• możliwość automatycznego generowania dokumentacji,
33
34
35
36
37
P. Schmidt, Modelowanie procesów w ramach systemów SOA - część 1.
http://www.4pm.pl/artykul/modelowanie_procesow_w_ramach_systemow_soa_czesc_1- 451079.html.
Ibidem.
września 2010 .
P. Sarang, M. Juric, B. Mathew, Business Process Execution Language for Web Services
BPEL and BPEL4WS. Packt Publishing, 2006.
K. Pant, M. Juric. Business Process Driven SOA using BPMN and BPEL: From Business
Process Modeling to Orchestration and Service Oriented Architecture. Packt Publishing,
2008.
• kompatybilność z innymi aplikacjami, np. pakietami biurowymi, narzędziami CASE lub systemami klasy ERP.
Niektóre programy do modelowania procesów biznesowych, np.
Corel iGrafx Process38, pozwalają na zaawansowaną symulację przebiegu
procesu, analizę procesu i wykrycie błędów. Symulacja taka daje możliwość manualnej optymalizacji procesu np. ze względu na czas obsługi,
czy koszty. W praktyce jednak nie ma jednego standardu symulacji. Perspektywiczna jest automatyczna optymalizacja przebiegu procesu, jednak
musi ona uwzględnić dodatkowe ograniczenia związane z organizacją firmy, a także z dostępnością zasobów. Niestety po takiej optymalizacji diagram BPMN może nie być czytelny i intuicyjny39.
Podsumowanie
BPMN definiuje jedynie notację do modelowania procesów biznesowych. Choć istnieje wiele narzędzi implementujących obsługę tej notacji i powstają książki, które uczą jak stosować notację do spójnego modelowania40, można zauważyć, że istotnym problemem jest brak spójnej metodologii projektowania całego systemu, w szczególności przejścia z modelu na wykonywalny kod.
Wraz z popularyzacją reguł biznesowych, technologie regułowe zyskują coraz szersze uznanie świata biznesu. Jednak projektowanie złożonych i zaawansowanych systemów regułowych nadal nastręcza trudności.
38
39
40
M. Lasek, B. Otmianowski, BPMN – standard opisywania procesów biznesowych. Budowa
modeli procesów BPMN w iGrafx. WSISiZ, Warszawa, 2007.
września 2010 .
B. Silver. BPMN Method and Style. Cody-Cassidy Press, 2009.
W rozwiązaniu tych problemów pomóc mogą wizualne reprezentacje reguł, a także nowe metody modularyzacji i hierarchizacji bazy wiedzy.
W szczególności interesujące może być wykorzystanie do tego celu procesów biznesowych.
3. Metody oceny jakości reguł i procesów biznesowych
W systemach informatycznych rozpatruje się szereg kryteriów jakości oprogramowania, np. normy ISO. Jakość często wiąże się z zagadnieniem testowania oprogramowania, pozwalającego na identyfikację usterek.
Można stwierdzić, iż jednym z podstawowych zadań postawionym
przed współczesną inżynierią oprogramowania jest zapewnienie wysokiej
jakości tworzonych aplikacji41. Jakość oprogramowania rozumie się zespół cech systemu, wpływających na jego zdolność do spełniania określonych kryteriów. Wymaga się, by system charakteryzowały42:
• Efektywność (ang. efficiency) – zdolność systemu do efektywnego
(często optymalnego) wykorzystania zasobów,
• Niezawodność (ang. reliability) – zdolność systemu do działania zgodnego ze specyfikacją w~danym okresie czasu,
• Funkcjonalność (ang. functional capability) – zdolność systemu do
spełniania wymagań użytkownika,
• Użyteczność (ang. usability) – łatwość obsługi,
• Przenaszalność (ang. portability) – zdolność systemu do pracy w różnych środowiskach bez konieczności modyfikacji,
41
42
A. Ligęza, Metody analizy wiedzy regułowej XTT2 w jezyku P ROLOG. Praca magisterska, AGH – University of Sience and Technology, 2009. Promotor: G. J.
Nalepa.
A. Ligęza, Logical Foundations for Rule-Based Systems. Springer-Verlag, Berlin,
Heidelberg, 2006.
• Pielęgnowalność (ang. maintenability) – łatwość utrzymania systemu,
naprawiania uszkodzonego systemu,
• Bezpieczeństwo (ang. safety) – charakteryzuje system, w którym chwilowe odstępstwo od poprawnego działania nie powoduje żadnych katastrofalnych skutków.
Nadanie priorytetów powyższym cechom jest kwestią indywidualną
dla każdego systemu informatycznego. Nie jest to jednak zadanie proste,
gdyż wymienione atrybuty nie są niezależne. Często uzyskanie odpowiedniego bezpieczeństwa przekłada się na znaczącą redukcję efektywności.
Jednak bez bezpieczeństwa nie może być mowy o niezawodności, itd.
3.1.
Ocena jakości w systemach regułowych, w tym wykorzystujących reguły biznesowe
W systemach regułowych dla uzyskania wysokiej jakości należy
szczególnie zatroszczyć się o: niezawodność, bezpieczeństwo i efektywność43. System regułowy musi działać zawsze zgodnie ze specyfikacją
przy optymalnym wykorzystaniu dostępnych zasobów. Jednocześnie proces tworzenia systemu winien być tak przeprowadzony, by już na etapie
projektowania i implementacji eliminować możliwie wiele przyczyn potencjalnych nieprawidłowości.
Niepoprawne działanie systemu regułowego to wynik wystąpienia
anomalii w bazie wiedzy. Dlatego tak istotnym elementem jest identyfikacja możliwych zagrożeń. Stanowi ona podstawę dla formalnej analizy
wiedzy regułowej. Poprawnie zaprojektowany i zaimplementowany system regułowy powinien spełniać szereg kryteriów poprawności i jakości
bazy reguł.
43
A. Ligęza: Logical Foundations... op.cit
Wybrane kryteria dotyczące języka reprezentacji wiedzy to:
• siła ekspresji,
• łatwość przetwarzania,
• czytelność,
• łatwość weryfikacji,
• rozszerzalność,
• import-eksport.
Istotne kryteria poprawności:
• niesprzeczność wewnętrzna,
• zgodność ze specyfikacją,
• zgodność ze światem zewnętrznym.
Natomiast wybrane kryteria wewnętrznej jakości to:
• minimalność reprezentacji,
• brak redundancji,
• brak niepotrzebnych warunków, nieosiągalnych celów.
3.2.
Propozycja taksonomii anomalii w systemie regułowym
W oparciu o analizę literatury problemu44,45 w opracowaniu Ligęzy46
proponowana jest następująca taksonomia anomalii w systemie.
• Niespójność (sprzeczność):
− niespójność logiczna wewnętrzna reguły
− niespójność materialna wewnętrzna reguły
− niespójność logiczna pary reguł
44
45
46
A.Vermesan, The Handbook of Applied Expert Systems. CRC Press (1997).
A.I.Vermesan, F.Coenen (Red.): Validation and Verification of Knowledge Based
Systems. Theory, Tools and Practice. Boston: Kluwer Academic Publisher (1999).
A. Ligęza, Opracowanie metodyki weryfikacji poprawności modelu wiedzy w systemie. Technical Report, Akademia Górniczo-Hutnicza, 2009. Raport wewnętrzny
projektu Rebit.
− niespójność materialna pary reguł
− niespójność logiczna dedukowana (wywód prowadzący do niespójności logicznej)
− niespójność materialna dedukowana (wywód prowadzący do niespójności materialnej)
• Brak zupełności:
− niezupełność logiczna grupy reguł (brak pokrywania wszystkich
wejść)
− niezupełność materialna grupy reguł
− niezupełność logiczna systemu (brak obsługi wszystkich stanów
wejściowych)
− niezupełność materialna systemu
− brakujące reguły dla dowodzenia celów
− brakujące reguły dla dowodzenia faktów pośrednich
• Redundancja:
− identyczne reguły
− równoważne reguły (np. zamiana kolejności warunków w przesłankach)
− subsumpcja prewarunków w pojedynczej regule
− subsumpcja konkluzji w pojedynczej regule
− subsumpcja prewarunków przez konkluzję w pojedynczej regule
− subsumpcja pary reguł
• Niepoprawne i niepotrzebne reguły lub warunki:
− niewykorzystywany prewarunek (input fact)
− nieudowadnialny prewarunek
− niewykorzystywana konkluzja (dead end)
− nieudowadnialny cel
− niepoprawna składnia
− wolne zmienne w konkluzji (brak możliwości wyznaczenia konkluzji po ustaleniu prewarunków)
• Nieoptymalność (niejednoznaczność) decyzji:
− dla pojedynczej reguły (różne możliwości dopasowania prewarunków)
− dla pary reguł
− dla grupy reguł
− dla systemu
• Nieoptymalność reprezentacji:
− niewykorzystana możliwość redukcji (sklejania) reguł,
− niewykorzystana możliwość redukcji częściowej
W odniesieniu do bazy wiedzy i mechanizmu wnioskowania rozważyć należy:
• Zapętlenie (cyrkularność)
• Niepełny mechanizm wnioskowania
• Brak możliwości odpalenia reguły z powodu braku możliwości sprawdzenia prewarunków (brak specjalizowanych procedur, np. dla ograniczeń, dostępu do bazy danych, braku możliwości realizacji usługi zewnętrznej)
Zagadnienie weryfikacji bazy wiedzy w systemach regułowych stanowiło istotny wątek badawczy projektu HeKatE47. W rezulacie w projekcie zaproponowano konkretne rozwiązania48 bazujące na logice atrybuto47
48
G.J. Nalepa, A. Ligęza, HeKatE Methodology... op.cit.
A. Ligęza, G.J. Nalepa: Visual design and on-line verification of tabular rule-based systems with XTT. Marktplatz Internet: Von e-Learning bis e-Payment : 13.
Leipziger Informatik-Tage, LIT 2005, Bonn.
wej oraz zaimplementowane odpowiednie narzędzia wspierające ten proces.
3.3.
Ocena jakości procesów biznesowych
Jakość procesów biznesowych rozpatrywać można w różnych
aspektach. W pracy „Dimensions of Business Process Quality (QoBP)”
49
przedstawiono cztery podstawowe kategorie dla oceny jakości procesów
biznesowych. Są to:
• Jakość funkcji procesu
• Jakość wejścia/wyjścia procesu
• Jakość zasobów procesu nie związanych z ludźmi
• Jakość zasobów ludzkich procesu
W ramach wyżej wymienionych kategorii zidentyfikowano szereg
wymagań dotyczących jakości. Całość tworzy szkielet (z ang. framework)
do oceny jakości procesów biznesowych, zwany QoBP (Quality of Business Processes) (patrz: Tabela 1).
49
M.Heravizadeh, J.Mendling, M.Rosemann, Dimensions of Business Processes
Quality (QoBP) W:Proceedings of Business Process Management Workshops
2008: Milan, Italy.
Tabela 1. Wymiary jakości procesów biznesowych
Funkcja
Odpowiedniość
Wejście/Wyjście
Dokładność
Zasoby
Odpowiedniość
Zasoby ludzkie
Wiedza dziedzino-
Dokładność
Obiektywność
Dokładność
wa
Ochrona
Wiarygodność
Ochrona
Kwalifikacje
Niezawodność
Reputacja
Niezawodność
Certyfikacje
Zrozumiałość
Dostępność
Efektywność czasowa
Doświadczenie
Wyuczalność
Ochrona
Wykorzystanie
Zarządzanie czasem
Efektywność czasowa
Związek
bów
Wykorzystanie zaso-
Wartość dodana
Zdolność
bów
Czasowość
wania
Efektywność
Kompletność
Dostępność
Produktywność
Ilość danych
zaso-
Zdolności komuniprzystoso-
kacyjne
Bezpieczeństwo
Satysfakcja użytkownika
Zdolność
przystoso-
wania
Źródło: Własne, na podstawie: M.Heravizadeh, J.Mendling, M.Rosemann, Dimensions of Business Processes Quality (QoBP) Business Process Management Workshops 2008: Milan, Italy
W dalszej części opracowania wyjaśniono poszczególne kryteria i
wymagania dotyczące jakości procesów biznesowych z podziałem na kategorie.
Jakość funkcji procesu biznesowego
Funkcja to podstawowy komponent procesu biznesowego odpowiadający aktywności (zadania, etap procesu itp.), która musi być wykonana.
Bazując na badaniach z zakresu inżynierii oprogramowania Autorzy frameworku QoBP zidentyfikowali 13 wymiarów jakości funkcji procesu:
• Odpowiedniość (ang. Suitability) – zdolnośc zapewnienia odpowiedniej funkcji dla konkretnego celu użytkownika
• Dokładność (ang. Accuracy) – odnosi się do zdolności dostarczenia
poprawnego lub uzgodnionego rezultatu lub efektu z wymaganą dokładnością
• Ochrona (ang. Security) – związane ze zdolnością funkcji to ochrony
informacji i danych oraz zabezpieczaniem dostępu do nich przed nieuprawnionymi zasobami
• Niezawodność (ang. Reliability) – zdolność funkcji dop utrzymania
odpowiedniego poziomu wydajności w razie wystąpienia wyjątkowych
warunków
• Zrozumiałość (ang. Understandability) – zdolność funkcji do poinformowania danego zasobu, czy w danych warunkach należy użyć tej
funkcji i jak tego dokonać
• Wyuczalność (an. Learnability) – zdolność funkcji do nauczenia się jej
działania przez użytkownika
• Efektywność czasowa (ang. Time efficiency) – zdolność funkcji do zapewnienia odpowiedniego czasu przetwarzania i odpowiedzi oraz odpowiedniego współczynnika przepływu w określonych warunkach
• Wykorzystanie zasobów (ang. Resource utilisation) – zdolność funkcji
to użycia odpowiedniej ilości i typu zasobów w określonych warunkach
• Efektywność (ang. Effectiveness) – umożliwienie użytkownikom osiągnięcia konkretnych celów z określoną dokładnością i kompletnością
w określonym kontekście
• Produktywność (ang. Productivity) – wymiar związany z możliwością
użycia odpowiedniej ilości zasobów w stosunku to osiągniętej efektywności w określonym kontekście
• Bezpieczeństwo (ang. Safety) – zdolność funkcji do osiągnięcia akceptowanego poziomu ryzyka zaszkodzenia ludziom, procesom lub środowisku
• Satysfakcja użytkownika (ang. User Satifsaction) – zdolność do usatysfakcjonowania użytkownika w określonych warunkach użycia
• Zdolność przystosowania (ang. Robustness) – poziom, do którego
funkcja jest w stanie poprawnie funkcjonować w przypadku niekompletnych, niepoprawnych lub sprzecznych danych.
Powyższe kryteria mogą lecz nie muszą być zastosowane do każdej
funkcji. Jednak świadomość powyższych różnych wymiarów jakości procesu biznesowego pomaga zidentyfikować różne aspekty jakości danego
procesu.
Jakość wejścia i wyjścia procesu biznesowego
Wejście i wyjście procesu biznesowego określają fizyczne i informacyjne obiekty przetwarzane i produkowane przez dany proces. Dane
wejściowe i wyjściowe różnią się między sobą znaczeniem i wpływem na
ogólną jakość procesu. Podstawowe wymiary jakości dla danych wejściowych i wyjściowych podano w kolumnie 2. Tabeli 1. Wybrane z nich to:
• Dokładność (ang. Accuracy) – czy dane dokładnie oddają obiekt czy
zdarzenie biznesowe, które reprezentują
• Obiektywność (ang. Objectivity) – czy dane są bezstronne i oparte na
faktach
• Wiarygodność (ang. Believability) – do jakiego stopnia dane uznawane
są za prawdziwe
• Reputacja (ang. Reputation) – dotyczy wiarygodności źródła danych
• Dostępność (ang. Accessibility) – na ile dane są dostępne w momencie
zapotrzebowania na nie
• Ochrona (ang. Security) – na ile dane chronione są przed nieautoryzowanym dostępem
• Związek (ang. Relevancy) – poziom powiązania danych z procesem
• Wartość dodana (ang. Value-added) – wkład, jaki wnoszą dane
• Czasowość (ang. Timeliness) – jak długo dane są uznane za „bieżące”
• Kompletność (ang. Completeness) – czy dane zawierają wszystkie konieczne wartości
• Ilość danych (ang. Amount of data) – ilość danych w stosunku do ilości
potrzebnej w danym kontekście
Jakość zasobów procesu nie związanych z ludźmi
Sposób, w jaki wykorzystywane są zasoby (maszyny, urządzenia,
programy) wpływa na jakość funkcji oraz ogólną jakość procesów biznesowych. Wymagania jakościowe dotyczące zasobów procesu biznesowego wyszczególniono w kolumnie 3. Tabeli 1. Charakterystyka tej kategorii opiera się na ocenie jakości w inżynierii oprogramowania50. Większość
wymienionych aspektów powiązanych jest z wymiarami jakości funkcji
procesu. Istotnym dodanym aspektem jest Dostępność (ang. Availability)
zasobu, opisująca prawdopodobieństwo, że dany zasób (maszyna, urządzenie, program) będzie prawidłowo funkcjonował.
Jakość zasobów ludzkich procesu
W ostatecznym rozrachunku o jakości procesów biznesowych w dużej mierze decydują przydzielone do nich zasoby ludzkie. Jednakże więk50
ISO/IEC-9126-1: Software engineering – product quality: Quality model 2001.
szość stosowanych obecnie techniki modelowania procesów biznesowych
nie uwzględnia możliwości zdefiniowania potrzebnych kompetencji do
wykonania określonych funkcji w ramach procesu. Poniżej przedstawiono
wybrane atrybuty jakości zasobów ludzkich procesu biznesowego51:
• Wiedza dziedzinowa (ang. Domain knowledge) – wiedza w danej dziedzinie, konieczna do wykonania danej funkcji procesu
• Kwalifikacje (ang. Qualification) – kwalifikacje zasobów ludzkich
przydzielonych do procesu, które muszą być posiadane
• Certyfikacje (ang. Certification) – zaświadczenia niezbędne do wykonania określonej funkcji procesu
• Doświadczenie (ang. Experience) – wymagane doświadczenie
• Zarządzanie czasem (ang. Time management) – wymagane umiejętności zasobów ludzkich w dziedzinie zarządzania czasem
• Zdolności komunikacyjne (ang. Communication skills) – umiejętności
komunikacyjne wymagane do wykonania danej funkcji
Ocena jakości procesów biznesowych według omówionego szkieletu QoBP polega w praktyce na przeanalizowaniu poszczególnych wymagań jakości oraz zestawieniu otrzymanych wartości w tabeli. Tabela taka
w klarowny sposób pokazuje, które elementy danego procesu mają istotny wpływ na jakość całości oraz pomagają zidentyfikować ewentualne
usterki.
4. Podejście do weryfikacji procesów biznesowych
O ile zagadnienie weryfikacji bazy wiedzy w systemach regułowych jest stosunkowo dobrze rozpoznaną dziedziną, o tyle weryfikacja
51
L.M. Spencer Jr., L.M. Spencer: Competence at Work: models for superior performance. John Wiley and Sons, Inc. First ed. (1993)
procesów biznesowych, w szczególności opisanych za pomocą diagramów BPMN52 stanowi obszar intensywnych badań. Wynika to z faktu, że
semantyka diagramów BPMN nie jest ściśle sformalizowana. Weryfikacja
procesów biznesowych opiera się więc niejednokrotnie na translacji diagramów BPMN do wybranego formalizmu z dziedziny tak zwanych metod formalnych.
Powstające metody translacji opierają się na zasadzie, którą można
określić w skrócie jako poszukiwanie najlepszego przybliżenia. Oznacza
to, że oryginalne modele są transformowane do wybranego formalizmu
tak dokładnie jak to jest możliwe. Innymi słowy wskazuje się pewien ściśle określony podzbiór konstrukcji języka BPMN i dla tego podzbioru definiuje się algorytm konwersji. Podejście takie wynika z faktu, że w zależności od wybranego formalizmu nie wszystkie konstrukcje języka BPMN
można łatwo transformować. Naturalne jest więc podejście, w którym
pierwszą wersję algorytmu określa się dla podzbioru najczęściej używanych symboli, a następnie iteracyjnie próbuje się rozszerzać metodę translacji na większy zbiór symboli języka BPMN.
Metody formalne zawierają szereg różnych typów formalizmów,
które można zastosować jako cel konwersji diagramów BPMN. Należą do
nich m.in. sieci Petriego53, algebry procesów54, czy też automaty czasowe55. Sieci Petriego ze względu na dostępność graficznego języka modelowania oraz liczne metody analizy wydają się być szczególnie odpowiednie do tego celu. Podobnie jak diagramy BPMN wykorzystują one
grafy skierowane, co ułatwia opracowanie algorytmu konwersji. W algo52
B. Silver. BPMN Method and Style. Cody-Cassidy Press, 2009.
W. Reisig: Sieci Petriego. WNT, Warszawa, 1988.
54
J.A. Bergstra, A. Ponse, S.A. Smolka [Red.]: Handbook of Process Algebra. Elsevier Science, Upper Saddle River, NJ, USA, 2001.
55
R. Alur and D. Dill. A theory of timed automata. Theoretical Computer Science,
126(2):183–235, 1994.
53
rytmie takim stosuje się lokalną transformację, w której fragmenty diagramu w języku BPMN przekształcane są na fragmenty docelowej sieci Petriego.
Sieci Petriego są narzędziem, stosowanym w wielu różnych dziedzinach naukowych. Charakteryzuje je intuicyjny graficzny język modelowania, który wspierany jest przez zaawansowane metody formalnej
analizy ich własności. Naturalnym zjawiskiem w sieciach Petriego jest
współbieżność wykonywanych akcji, stąd też są one najczęściej postrzegane jako matematyczne narzędzie do modelowania systemów współbieżnych56.
Pełny opis algorytmu translacji diagramów BPMN do wybranej klasy Sieci Petriego wraz z jego formalnym zapisem można znaleźć w pracy
Dijkmana, Dumasa i Ouyanga57. Translacja obejmuje zadania, zdarzenia,
wewnętrzne czynności, podstawową obsługę błędów i przepływ komunikatów między zadaniami.
Po transformacji diagramu BPMN do znakowanej sieci Petriego
można wykorzystać jedno z dostępnych narzędzi do automatycznej weryfikacji sieci i wyznaczyć jej własności. W kontekście weryfikacji diagramów BPMN wartościowym byłaby analiza następujących własności:
• Wyznaczenie martwych przejść – Znalezienie martwych przejść w sieci oznacza, że w diagramie BPMN występują zadania, które nigdy nie
są wykonywane. Pożądaną własnością jest więc brak takich przejść.
Operację wyznaczenia martwych przejść można wykonać poprzez odpowiednie metody analizy Sieci Petriego
56
57
M. Szpyrka: Sieci Petriego w modelowaniu i analizie systemów współbieżnych.
WNT, Warszawa, 2008.
R.Dijkman, M.Dumas, C.Ouyang: Formal semantics and analysis of BPMN process models using Petri Nets. Technical report, Queensland University of Technology, 2007.
• Wyznaczenie martwych znakowań – Zakończenie procesu w diagramie BPMN oznacza, że osiągnięte zostało zdarzenie końcowe i nie ma
żadnych aktywnych zadań. W odniesieniu do sieci Petriego oznacza to
wystąpienie znakowania martwego (znakowania, przy którym nie jest
aktywne żadne przejście), przy którym znakowane są tylko miejsca
wyjściowe.
Powyższe operacje można wykonać poprzez odpowiednie metody
analizy Sieci Petriego. Szczegóły dotyczące wnioskowania można znaleźć
np. w monografii Szpyrki58.
Analiza sieci jest realizowana zazwyczaj z użyciem odpowiedniego
oprogramowania, które pozwala ten proces zautomatyzować. Biorąc pod
uwagę formaty wejściowy (XMI) i wyjściowy (PNML) możliwa jest implementacja własnych narzędzi i algorytmów weryfikacji.
5. Zakończenie
Systemy regułowe znalazły liczne zastosowania praktyczne w obszarach wspomagania decyzji, diagnostyki w dziedzinach informatyki,
ekonomii czy medycyny. Ich projektowanie jest dojrzałą dziedziną rozwijaną w ramach Sztucznej Inteligencji. W podejściu reguł biznesowych, regułowe komponenty wnioskujące odgrywają istotną rolę.
Projektowanie złożonych i systemów regułowych wciąż stanowi
wyzwanie dla inżynierów. W ich pokonaniu pomóc mogą metody wizualnej reprezentacji reguł, a także nowe metody modularyzacji i hierarchizacji bazy wiedzy. W szczególności interesujące może być wykorzystanie
do tego celu procesów biznesowych.
58
M.Szpyrka: Sieci Petriego... op.cit.
Jak wskazano we wprowadzeniu, jednym z najistotniejszych teoretycznych i praktycznych problemów jest zapewnienie wysokiej jakości
systemu regułowego. Formalizacja reguł pozawala na sformalizowany
opis wskaźników jakości i metod weryfikacji. W celu zapewnienia jakości
podaje się taksonomię wykrywanych anomalii w bazie reguł, a następnie
sformalizowane definicje wybranych cech systemu regułowego, a następnie przedstawia algorytmy ich weryfikacji. Istotny jest logiczny, niezależny od implementacji opis tych algorytmów.
Bibliografia
Allweyer T., BPMN 2.0. Introduction to the Standard for Business Process Modeling. BoD, Norderstedt, 2010.
Alur R., Dill D.: A theory of timed automata. Theoretical Computer Science,
126(2):183–235, 1994.
Bergstra J.A., Ponse A., Smolka S.A.[red.]: Handbook of Process Algebra. Elsevier Science, Upper Saddle River, NJ, USA, 2001.
Browne P., JBoss Drools Business Rules, Packt Publishing, 2009.
Dijkman R., Dumas M., Ouyang C.: Formal semantics and analysis of BPMN
process models using Petri Nets. Technical report, Queensland University of
Technology, 2007.
Hay D., Kolber A., Anderson K., Defining business rules ~ what they really are.
Final report. Technical report, Business Rules Group, July 2000.
Heravizadeh M., Mendling J., Rosemann M., Dimensions of Business Processes
Quality (QoBP) W: Proceedings of Business Process Management Workshops
2008: Milan, Italy.
ISO/IEC-9126-1: Software engineering – product quality: Quality model 2001.
Kaczor K., Nalepa G.J., HQEd – wizualne narzędzie wspierające projektowanie
systemów ekspertowych opartych o reprezentację XTT. W: Adam Grzech et al.
[Red.] Inżynieria Wiedzy i Systemy Ekspertowe, s. 355–364, Warszawa, 2009.
Akademicka Oficyna Wydawnicza EXIT.
Kluza K., Nalepa G.J., Łysik Ł., Visual inference specification methods for modularized rulebases. overview and integration proposal. W: Grzegorz J. Nalepa,
Joachim Baumeister [Red.] 6th Workshop on Knowledge Engineering and Software Engineering (KESE2009) at the 32nd German conference on Artificial
Intelligence: September 21, 2010, Karlsruhe, Germany, s. 6–17, Karlsruhe, Germany, 2010.
Kluza K., Nalepa G.J.. Metody i narzędzia wizualnego projektowania reguł decyzyjnych. W: Adam Grzech et al. [Red.], Inżynieria Wiedzy i Systemy Ekspertowe, s. 197–208, Warszawa, 2009. Akademicka Oficyna Wydawnicza EXIT.
Ligęza A.: Opracowanie metodyki weryfikacji poprawności modelu wiedzy w
systemie. Technical Report, Akademia Górniczo-Hutnicza, 2009. Raport wewnetrzny projektu Rebit.
Ligęza A., Nalepa, G.J.: Visual design and on-line verification of tabular rule-based systems with XTT. Marktplatz Internet: Von e-Learning bis e-Payment :
13. Leipziger Informatik-Tage, LIT 2005, Bonn.
Ligęza A., Metody analizy wiedzy regułowej XTT2 w jezyku P ROLOG. Praca
magisterska, AGH – University of Sience and Technology, 2009. Promotor: G.
J. Nalepa.
Ligęza A., Logical Foundations for Rule-Based Systems. Springer-Verlag, Berlin, Heidelberg, 2006.
Lukichev S., Wagner G., Visual rules modeling. W: Sixth International Andrei
Ershov Memorial Conference Perspectives of System Informatics, Novosibirsk,
Russia, June 2006, LNCS. Springer, 2005.
Nalepa G.J., Business Rules Design and Refinement Using the XTT Approach.
W: David C. Wilson, Geoffrey C. J. Sutcliffe, and FLAIRS [Red.] FLAIRS- 20 :
Proceedings of the 20th International Florida Artificial Intelligence Research
Society Conference : Key West, Florida, May 7-9, 2007, s. 536–541, Menlo
Park, California, may 2007. Florida Artificial Intelligence Research Society,
AAAI Press.
Nalepa G.J., Kluza K., UML Representation Proposal for XTT Rule Design Method. W: Grzegorz J. Nalepa, Joachim Baumeister [Red.] 4th Workshop on
Knowledge Engineering and Software Engineering (KESE2008) at the 32nd
German conference on Artificial Intelligence: September 23, 2008, Kaiserslautern, Germany, s. 31–42, Kaiserslautern, Germany, 2008.
Nalepa G.J., Ligęza A., A Graphical Tabular Model for Rule-based Logic Programming and Verification, „Systems Science”, 31(2):89–95, 2005.
Nalepa G.J., Ligęza A., HeKatE Methodology, Hybrid Engineering of Intelligent
Systems, „International Journal of Applied Mathematics and Computer Science”,
20(1):35–53, March 2010.
Nalepa G.J., Proposal of Business Process and Rules Modeling with the XTT
Method, W: Symbolic and numeric algorithms for scientific computing : SYNASC’07 : 9th international symposium : RuleApps’2007 – workshop on Rulebased applications : Timisoara, Romania, September 26–29, 2007 : IeAT Tech-
nical Report 07-11, s. 17–23, Timisoara : West University, September 2007.
West University of Timisoara, Romania. Department of Computer Science, University Johannes Kepler, Linz, Austria. Research Institute for Symbolic Computation, Research Institute e-Austria, Timisoara, Romania.
Nalepa G.J., Mach M.A., Business Rules Design Method for Business Process
Management. W: M. Ganzha, M. Paprzycki [Red.] Proceedings of the International Multiconference on Computer Science and Information Technology, s. 165–
170. Polish Information Processing Society, IEEE Computer Society Press,
2009.
Nalepa G.J., Ligęza A., XTT+ Rule Design Using the ALSV(FD). W: Adrian
Giurca, Anastasia Analyti, and Gerd Wagner [Red.] ECAI 2008: 18th European
Conference on Artificial Intelligence: 2nd East European Workshop on Rule-based applications, RuleApps2008: Patras, 22 July 2008, s. 11– 15, Patras, 2008.
University of Patras.
Nemuraite L., Ceponiene L., Vedricka G., Representation of Business Rules in
UML and OCL Models for Developing Information Systems. „The Practice of
Enterprise Modeling”, 15:182–196, 2008.
Object Management Group, Business Process Modeling Notation. Specification.
Technical Report dtc/06-02-01, OMG, February 2006.
Object Management Group, Object Constraint Language version 2.0. Technical
report, OMG, May 2006.
Object Management Group, Production Rule Representation version beta 1.
Specification. Technical Report dtc/07-11-04.pdf, OMG, November 2007.
Object Management Group, Unified Modeling Language version 2.2. Superstructure. Technical Report formal/2009-02-02, OMG, February 2009.
Piotrowski M.. Notacja modelowania procesów biznesowych – podstawy, BTC,
Legionowo, 2007.
Pant K., Juric M., Business Process Driven SOA using BPMN and BPEL: From
Business Process Modeling to Orchestration and Service Oriented Architecture.
Packt Publishing, 2008.
Reisig W.: Sieci Petriego. WNT, Warszawa, 1988.
Sarang P., Juric M., Mathew B., Business Process Execution Language for Web
Services BPEL and BPEL4WS. Packt Publishing, 2006.
Silver B, BPMN Method and Style. Cody-Cassidy Press, 2009.
Spencer L.M. Jr., Spencer L.M.: Competence at Work: models for superior performance. John Wiley and Sons, Inc. First ed. (1993)
Szpyrka M.: Sieci Petriego w modelowaniu i analizie systemów współbieżnych.
WNT, Warszawa, 2008.
Vermesan, A., The Handbook of Applied Expert Systems. CRC Press, 1997.
Vermesan A.I., F.Coenen [Red.] Validation and Verification of Knowledge Based Systems. Theory, Tools and Practice. Boston: Kluwer Academic Publisher,
1999.
Źródła internetowe
S. W. Ambler. Business Rules. http://www.agilemodeling.com/artifacts/businessRule.htm, 2003.
REWERSE Working Group I1
http://rewerse.net/I1/oxygen.informatik.tu-cottbus.de/rewerse-i1/default.htm
REWERSE Working Group I1, A UML-based Rule Modeling Language.
http://oxygen.informatik.tu-cottbus.de/rewerse-i1/?q=URML, 2006.
Business Process Management Initiative. BPMN Implementors and Quotes.
http://www.bpmn.org/BPMN_Supporters.htm
P. Schmidt, Modelowanie procesów w ramach systemów SOA - część 1.
http://www.4pm.pl/artykul/modelowanie_procesow_w_ramach_systemow_soa_
czesc_1- 45-1079.html

Wymagania edytoskie TWZ

Transkrypt

Podobne dokumenty

8 Wstęp to miejsce w każdym podręczniku, którego nie cierpię

CV w załączeniu

Modelowanie procesów biznesowych w BPMN 2.0

tutaj - LondonSam

ZARZĄDZANIE ZASOBAMI LUDZKIMI – ZAGADNIENIA

Rejestracja i networking przy kawie Część I – Rola sprzedaży w

indywidualna ścieżka rozwoju twojego

pobierz - Tech-Com