Wymagania edytoskie TWZ
Transkrypt
Wymagania edytoskie TWZ
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. 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 . 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 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 . 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. 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 . 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. 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 . 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