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ł biznesowych 2 : 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 kategorii 3 : 1 S. W. Ambler. Business Rules. http://www.agilemodeling.com/artifacts/businessrule.htm, 2003. 2 D. Hay, A. Kolber, K. Anderson Healy. Defining business rules ~ what they really are. Final report. Technical report, Business Rules Group, July 2000. 3 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 modelowania 4 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 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. 5 Object Management Group, Unified Modeling Language version 2.2. Superstructure. Technical Report formal/2009-02-02, OMG, February 2009.
Dotychczas stosowane podejścia 6,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 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. 7 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. 8 Object Management Group, Object Constraint Language version 2.0. Technical report, OMG, May 2006. 9 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 LNI 10 ) 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 I1 12 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 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. 12 http://rewerse.net/i1/oxygen.informatik.tu-cottbus.de/rewerse-i1/default.htm, 10-12-2010. 13 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 1 15 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 Object Management Group, Production Rule Representation version beta 1. Specification. Technical Report dtc/07-11-04.pdf, Object Management Group, November 2007. 15 Ibidem. 16 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=item- Type.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łasny 19 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 Object Management Group, Business Process Modeling Notation. Specification. Technical Report dtc/06-02-01, OMG, February 2006. 18 T. Allweyer, BPMN 2.0. Introduction to the Standard for Business Process Modeling. BoD, Norderstedt, 2010. 19 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 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. 21 G.J. Nalepa, A. Ligęza, A Graphical Tabular Model for Rule-based Logic Programming and Verification, Systems Science, 31(2):89 95, 2005. 22 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. 23 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 Drools 24 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 decyzyjnych 25. 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 Nalepy 26,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ługi 29. 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 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. 27 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. 28 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 (KESE- 2009) at the 32nd German conference on Artificial Intelligence: September 21, 2010, Karlsruhe, Germany, s. 6 17, Karlsruhe, Germany, 2010. 29 M. Piotrowski. Notacja modelowania procesów biznesowych podstawy, BTC, Legionowo, 2007. 30 Business Process Management Initiative. BPMN Implementors and Quotes. http://www.bpmn.org/bpmn_supporters.htm
Specyfikacja BPMN 31 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ętrzny 32 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 stawianych 33. W zależności od udostępnianych funkcji, narzędzia te można zakwalifikować do następujących kategorii 34 : 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 jak 35 : 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 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. 34 Ibidem. 35 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. 36 P. Sarang, M. Juric, B. Mathew, Business Process Execution Language for Web Services BPEL and BPEL4WS. Packt Publishing, 2006. 37 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 Process 38, 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 intuicyjny 39. 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 modelowania 40, 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 M. Lasek, B. Otmianowski, BPMN standard opisywania procesów biznesowych. Budowa modeli procesów BPMN w igrafx. WSISiZ, Warszawa, 2007. 39 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. 40 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 aplikacji 41. 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ły 42 : 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 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. 42 A. Ligęza, Logical Foundations for Rule-Based Systems. Springer-Verlag, Berlin, Heidelberg, 2006.