PRZEPRASZAMY ZA USTERKI 1 1.

PRZEPRASZAMY ZA USTERKI 1 1

Analiza silników reguł biznesowych
Autor: Jan Waloch nr indeksu: 4374 Promotor: dr hab. prof. WWSI Michał Grabowski WARSZAWA 2012

Osiągnięcie celu pracy wymagało rozwiązania następującego głównego problemu badawczego: Jakimi atrybutami cechują się wybrane silniki reguł biznesowych?

Pozytywne rozwiązanie problemu badawczego wymagało sformułowania i odpowiedzi następujących problemów szczegółowych: Jakimi atrybutami cechuje się powstający system informatyczny? Jaki poziom wiedzy cechuje środowisko, w jakim powstaje system informatyczny? Jakie można prognozować tendencje rozwoju silników reguł biznesowych w tworzeniu systemów informatycznych?

Proces badań wymaga zweryfikowania hipotezy roboczej: Użycie środowiska reguł biznesowych do implementacji logiki biznesowej ułatwia konserwację i modyfikację w systemach informatycznych.

Osiągnięcie założonego celu pracy oraz rozwiązanie szczegółowych problemów badawczych wymagało zastosowania następujących metod badawczych: Metoda analizy, którą zastosowano do analizy literatury przedmiotu i wyników uzyskanych podczas częściowej implementacji logiki biznesowej systemu informatycznego. Metoda syntezy, którą zastosowano do zebrania wniosków uzyskanych z analizy literatury przedmiotu badanego zjawiska i wyników uzyskanych podczas częściowej implementacji logiki biznesowej systemu informatycznego.

Osiągnięcie założonego celu pracy oraz rozwiązanie szczegółowych problemów badawczych wymagało zastosowania następujących metod badawczych: Metoda analogii, która posłużyła do przeniesienia ogólnych trendów w rozwoju oprogramowania, na implementację logiki biznesowej. Taksonomia numeryczna, która posłużyła do oceny atrybutów silników reguł biznesowych.

Otoczenie systemu informatycznego.
Analiza silników reguł biznesowych Otoczenie systemu informatycznego. Analiza systemu informatycznego. Wymagania. Modelowanie. Architektury projektowe systemów informatycznych. Analiza systemu informatycznego. Analiza systemu informatycznego jest procesem, którego celem jest dostarczanie jak najprecyzyjniejszego opisu tego, co ma być wykonane dla tego, który ma wykonywać. Nawet pierwsze, proste aplikacje wymagały spisania założeń tak, aby użytkownik, który później będzie korzystał z powstałego oprogramowania mógł uprościć przy jego pomocy wykonywane i czynności – innymi słowy – program będzie go wspierał a nie stanowił wyzwania sam w sobie. Ian Graham w swojej książce „Metody obiektowe w praktyce i teorii” definiuje obiekt jako naturalną metaforę dla połączenia danych ze sterowaniem. Z tej perspektywy podejście obiektowe umożliwia analityczny opis modelowanej rzeczywistości biznesowej w postaci zbioru elementów i ich relacji. Antropomorficznych charakter obiektu, przejawiający się w hermetyzacji i kapsułkowaniu, wzbogaca proces analizy o skalowalność. Wymagania. Wymagania stawiane wobec systemu informatycznego są próbą wyartykułowania potrzeb oraz oczekiwań wobec powstającego oprogramowania. Allistar Cockburn w swojej książce „Writing Effective Use Cases” zawarł stanowisko, w myśl którego nie ma przewodników jak pisać lub oceniać przypadki użycia. Pomimo kilkudziesięciu lat, odkąd przypadki użycia stały się normą dla opisu wymagań funkcjonalnych oraz zdobywaniem coraz szerszej akceptacji w kręgach ekspertów związanych z analizą – określenie jakości przypadku użycia nadal nie jest oczywiste. Powodem takiego stanu rzeczy w dużej mierze jest pochodzenie treści przypadku użycia. Modelowanie Model jest abstrakcją rzeczywistości biznesowej. Aby był zrozumiały dla szerokiego grona ekspertów, związanych z wytworzeniem systemu informatycznego, model musi być zaimplementowany w przynajmniej jednym z wielu istniejących rozwiązań. Istnieje bogate portfolio narzędzi do wspomagania tego procesu, których część jest uwzględniona w pakietach typu CASE (Computer Aided Software Enginering), służących do wspomagania procesu projektowania. Przykłady narzędzi do modelowania: UML, Sieci Petriego, BPMN, Prototypowanie Architektury projektowe systemów informatycznych. Architektura systemu informatycznego jest odzwierciedleniem wizji, umiejętności oraz wpływów środowisk wytwórczych. Określeniem jakości architektury jest ilość zasobów, jaka jest wymagana do zaimplementowania, modyfikacji i utrzymania systemu informatycznego. Proces wdrażania zmian jest obrazem jakości architektury systemu informatycznego. Uniwersalizm ma negatywny wpływ na wydajność, jednak dostarcza najbardziej elastycznych rozwiązań. Według publikacji Len’a Bass’a, Paul’a Clements’a i Rick’a Kazmana pt. „Architektura oprogramowania w praktyce” na wybór architektury systemu informatycznego mają wpływ następujące czynniki: Cele firmy, Wykształcenie i doświadczenie architektów, Środowisko techniczne. Wybór architektury powinien powodować efekt synergii w procesie wytworzenia systemu informatycznego. Spodziewanymi efektami są: Ujednolicona komunikacja między udziałowcami procesu wytwórczego, Wczesne decyzje projektowe, Możliwa do przenoszenia abstrakcja systemu

Rodzaje metod implementacji systemu informatycznego
Analiza silników reguł biznesowych Rodzaje metod implementacji systemu informatycznego Sekwencyjne. Strukturalne. Proceduralne. Modułowe. Obiektowe. Sekwencyjne Poszczególne funkcje postrzegane są w postaci punktu startu, sekwencji czynności i punktu końca. Podczas implementacji przekazanie sterowania do pożądanego, a nie będącego następnikiem aktualnie wykonywanego elementu algorytmu było wykonywane poprzez użycie polecenia skoku. Charakterystycznym przykładem elementu sekwencyjnego środowiska projektowego jest schemat blokowy. Publikacja Edsger’a Dijkstra’a: „Szkodliwe GOTO”, zwieraja postulat zastąpienia instrukcji skoku innymi konstrukcjami programistycznymi umożliwiającymi stosowanie paradygmatu niezmienników w uzasadnianiu poprawności zaprojektowanych algorytmów. Strukturalne Podejście strukturalne różni się od sekwencyjnego wprowadzeniem struktur sterujących. W tym podejściu zalecany jest podział poszczególnych algorytmów na hierarchiczne bloki czynności z jednym punktem wejścia i jednym lub wieloma punktami wyjścia. Podstawą budowy systemu informatycznego jest rozkład funkcji systemu. Proceduralne Proceduralne środowisko projektowe jest rozszerzeniem środowiska strukturalnego, które cechuje funkcjonalne wydzielenie bloków czynności w postaci procedur, traktowanych jako osobne byty, inicjowane parametrami wejściowymi. Zaleca się odejście w warstwie implementacyjnej od globalnie zarządzanych danych. Modułowe Korzyści, uzyskane podczas eliminowania zależności między poszczególnymi blokami czynności, rozszerzono środowisko proceduralne, nakładając obowiązek zawierania procedur, typów i konstrukcji specyficznych dla wybranej domeny zagadnień w odseparowanych od siebie modułach. Kluczowego znaczenia nabiera proces przekazywania danych. Podejście to jest efektem postulatu, aby eliminować relacje między poszczególnymi procedurami. Dla przykładu: relacje tego typu były tworzone w warstwie implementacyjnej, poprzez zastosowanie zmiennych globalnych do przekazywania danych, co powodowało utrudnienia podczas separowania bloków czynności. Obiektowe Użycie podejścia obiektowego do wytworzenia systemu informatycznego wymaga definicji za pomocą obiektów – elementów łączących stan (czyli dane, nazywane najczęściej polami) i komunikaty (czyli procedury, tu: metody). Środowisko obiektowe używa obiektów do zobrazowania rzeczywistych elementów i ich zachowań, w celu stworzenia modelu systemu informatycznego. Wyodrębniając poszczególne obiekty z rzeczywistości, definiuje się cechy i zachowania, które są istotne z punktu widzenia modelowanego systemu. Obiekty o wspólnych definicjach są instancjami tej samej klasy. Klasa nie jest samodzielnym bytem, jest metadanymi obiektów. Ian Graham w publikacji „Metody obiektowe w praktyce i teorii” zaznacza, że pojęcie obiektu stanowi naturalną metaforę dla połączenia danych ze sterowaniem. Ukryta w ten sposób współbieżność pozwala zwiększyć wydajność.

Narzędzia i środowiska wspierające proces wytwarzania systemu informatycznego. Metodyki. Wzorce projektowe. Metodyki Świadomość zakresu prac, jakie wymusza wytworzenie systemu informatycznego oraz pracochłonność, której pochodną jest późniejsza wycena takiego systemu, wymusiły na architektach systemów informatycznych zastosowanie metodyk projektowych, dostarczających zunifikowany zestaw etapów wytwórczych, o precyzyjnie określonym zakresie dostarczanych elementów. Wzorce projektowe „Każdy wzorzec składa się z trzech części, które wyrażają związek między konkretnym kontekstem, problemem i rozwiązaniem” – Christopher Alexander. Wzorzec projektowy określa problem, rozwiązanie oraz uwarunkowania typowego zadania implementacyjnego. Jest efektem zebrania i syntezy doświadczeń ekspertów, uzyskanych podczas budowy systemów informatycznych. Przedstawione we wzorcu projektowym rozwiązanie jest abstrakcją. Nie odnosi się do konkretnego środowiska, takiego jak język programowania czy konfiguracja serwera. Jest algorytmem, metodą postępowania dla typowych problemów implementacyjnych. Ciekawym rozwinięciem tezy Alexandra była propozycja Martina Fowlera, który w publikacji „Analysis Patterns” napisał: „Wzorzec to pomysł, który okazał się użyteczny w jednym rzeczywistym kontekście i prawdopodobnie będzie także użyteczny w innym”. Unaocznia to charakter wzorca, jakim jest przedstawienie rozwiązania realnego problemu. Abstrakcja, jaką cechuje się opis wzorca jest przy tym zapewnieniem uniwersalizmu, wymaganego przy dynamicznie zmieniającym się środowisku wytwarzania systemów informatycznych.

Obszary biznesowe i ich integracja w systemach informatycznych.
Analiza silników reguł biznesowych Obszary biznesowe i ich integracja w systemach informatycznych. Pożądane cechy systemów informatycznych Precyzyjny interfejs danych wejściowych. Elastyczny moduł przetwarzania. Systemy informacyjne to zbiór elementów i ich relacji, osiągających efekt synergii w przetwarzaniu danych. Podstawowym elementem takiego systemu jest sterowanie. Reguły biznesowe, zaimplementowane wewnątrz tego komponentu systemu, pozwalają uzyskać dane wyjściowe z zebranych danych wejściowych. Spośród oczekiwanych cech systemu informatycznego można wymienić: dużą wydajność działania, wysoką jakość uzyskiwanych danych czy też elastyczny model wprowadzania zmian.

Sposoby implementacji logiki biznesowej w systemach informatycznych
Analiza silników reguł biznesowych Sposoby implementacji logiki biznesowej w systemach informatycznych Funkcje i Modularność. Biblioteki funkcji, Biblioteki podłączane dynamicznie (DLL) Klasy Technologia COM i DCOM Logika biznesowa w bazie danych. Deklaratywny język opisu. Oszczędność zasobów. Wielodostępność. Funkcje i Modularność. Podział logiki biznesowej na funkcje był urzeczywistnieniem maksymy „Dziel i zwyciężaj”, w myśl której zarządzanie mniejszymi ale za to wyspecjalizowanymi elementami jest łatwiejsze od jedną, większą całością. Biblioteki funkcji, Biblioteki podłączane dynamicznie (DLL) Rozwinięciem koncepcji modularnego grupowania funkcji było powstanie bibliotek. Dodatkowym atutem jest możliwość dynamicznego wczytywania bibliotek do pamięci. Architektura system informatycznego, wykorzystująca tę koncepcję zawiera deklarację wykorzystywanych i tworzonych bibliotek. Uzyskane w ten sposób korzyści, to przede wszystkim: Oszczędność pamięci operacyjnej, Aktualizacja wersji biblioteki funkcji bez konieczności zatrzymywani systemu informatycznego. Klasy Rozrost logiki biznesowej, jej złożoności oraz różnorakiego spektrum zastosowania wymusił poszukiwania bardziej wyrafinowanego podejścia. Utożsamienie rzeczywistych obiektów domeny biznesowej z ich informatycznymi odpowiednikami w postaci klas obiektów zmieniło perspektywę postrzegania architektury. Rozkład funkcji został zastąpiony hierarchą klas, co dodatnie wpłynęło na czytelność. Architekt systemu informatycznego i analityk zyskali wspólny słownik, gdzie analityk, opisując obiekty i relacje, odwoływał się do ich rzeczywistych odpowiedników w domenie biznesowej. Technologia COM i DCOM Implementacja logiki biznesowej, zwłaszcza dotycząca uniwersalnej funkcjonalności (np. obsługa kontrolek systemowych) wymagała platformy niezależnej od języka programowania. Component Object Model (COM) i jego rozproszona wersja – Distributed Component Object Model (DCOM) są interfejsami do osadzania klas w strukturach niezależnych i dostępnych z heterogenicznych środowisk np. języków programowania. Została wprowadzona w 1993 r. przez Microsoft i do dnia dzisiejszego nadal jest wykorzystywana. Technologia COM łączy w sobie kilka innych technologii takich jak np.: Object Linking and Embedding (OLE), ActiveX Logika biznesowa w bazie danych. Czwarta wersja języka SQL - SQL:1999 dodała do kanonu tego języka możliwość osadzania procedur i funkcji, manipulujących danymi. Iteracyjny charakter przetwarzania ma negatywny wpływ na wydajność podczas aktualizacji dużych obszarów danych. W takiej sytuacji każdy element zbioru jest aktualizowany, zależność czasu i zasobów jest wprost proporcjonalna do liczebności zmienianego obszaru danych. Osadzenie takiej logiki po stronie bazy danych ma wymierne korzyści: Deklaratywny język opisu, Oszczędność zasobów, Wielodostępność. Głównymi wadami implementacji logiki biznesowej po stronie bazy danych są: Dostarczanie implementacji wraz z kodem źródłowym, Brak spójnej specyfikacji – poszczególne składnie modułów składowanych różnią się w zależności od producenta silnika zarządzania bazą danych.

Analiza silników reguł biznesowych Sposoby implementacji logiki biznesowej w systemach informatycznych Silniki reguł biznesowych - Przegląd cech Architektura: Otwarta, Zamknięta, Częściowa, Całkowita Wsparcie edukacyjne: Gotowe scenariusze użycia, Pomoc on-line. Środowisko uruchomieniowe: Zależne od platformy systemu informatycznego, Interfejs użytkownika: Graficzny interfejs użytkownika, Język obsługi reguł biznesowych, Wersjonowanie Głównym elementem koncepcji silnika reguł biznesowych jest zbiór wykonywanych etapów, ich hierarchia oraz sposób w jaki poszczególne etapy są przetwarzane. Punktem wyjścia dla definicji przepływu jest określenie jakie czynności i w jakiej kolejności należy wykonać, aby przetransformować dane, pozyskane na wejściu w dane wyjściowe. Z uwagi na fakt, że silnik reguł biznesowych jest koncepcją, jego implementacja różni się w zależności od producenta. Architektura: Otwarta – kod silnika reguł biznesowych jest dostępny na etapie implementacji. Zamknięta – silnik reguł biznesowych dostarczany jest jako gotowy produkt z wyspecyfikowanymi interfejsami konfiguracyjnymi. Częściowa – zdefiniowany przepływ jest elementem systemu informatycznego. Stanowi autonomiczny obiekt, jednakże do pełnej pracy wymagane jest oprogramowanie klienckie. Dostarczany moduł ma charakter biblioteki np. dll Całkowita – silnik reguł biznesowych dostarcza mechanizmów generujących gotowy system wraz z narzędziem do zaprojektowania i zaimplementowania przepływu. Wsparcie edukacyjne. Gotowe scenariusze użycia – użytkownik może szybko nauczyć się założeń i sposobów implementacji, wykorzystując gotowe scenariusze, gdzie producent prezentuje możliwe implementacje z wykorzystaniem cech swojego produktu. Pomoc on-line. Środowisko uruchomieniowe: Zależne od platformy systemu informatycznego – silnik reguł biznesowych wymaga tego samego środowiska uruchomieniowego, jak system informatyczny, który je wykorzystuje (np. Microsoft Framework .NET w wersji 3.5) Niezależne od platformy systemu informatycznego – silnik reguł biznesowych jest osadzony w autonomicznym lub wirtualnym środowisku. Interfejs użytkownika: Graficzny interfejs użytkownika – umożliwiający definicję przepływu przy pomocy wizualnych kreatorów. Język obsługi reguł biznesowych – umożliwiający definicję przepływu przy pomocy deklaratywnego języka opisu. Interfejs administracyjny - umożliwiający zmiany bez konieczności zatrzymywania i aktualizacji pozostałych modułów systemu informatycznego. Wersjonowanie - cecha określa, czy moduł edycyjny silnika reguł biznesowych posiada możliwość wersjonowania zaprojektowanego przepływu

Analiza silników reguł biznesowych Sposoby implementacji logiki biznesowej w systemach informatycznych Silniki reguł biznesowych - Przegląd cech Koszty drożenia: Oprogramowanie „open source”, Oprogramowanie komercyjne Obsługiwane standardy implementacji reguł: Maszyna stanowa, Model sekwencyjny Skalowalność: Autoryzacja użytkowników, Podział funkcji ze względu na role użytkowników, Rodzaj dystrybucji: Aplikacja, Usługa Koszty drożenia: Oprogramowanie „open source” – umożliwiające wdrożenie bez ponoszenia kosztów oprogramowania. Oprogramowanie komercyjne – kupowane jako gotowy produkt i dostarczane wraz z pakietem szkoleń lub gotowymi narzędziami. Obsługiwane standardy implementacji reguł – obie cechy mogą być spełnione. Maszyna stanowa – implementacja przepływu w postaci maszyny stanowej, definiującej stany oraz przejścia między nimi. Model sekwencyjny - implementacja przepływu w postaci diagramu sekwencyjnego, prezentującego wykonywane akcje oraz warunki, decydujące o rozwidleniach przepływu. Skalowalność Autoryzacja użytkowników Podział funkcji ze względu na role użytkowników Rodzaj dystrybucji: Aplikacja – silnik reguł biznesowych dostarczany jest jako gotowy do użycia produkt Usługa – silnik reguł biznesowych jest osadzony na zewnętrznym serwerze i obsługuje żądania, pochodzące od innych systemów.

Analiza silników reguł biznesowych Sposoby implementacji logiki biznesowej w systemach informatycznych Silniki reguł biznesowych - Przegląd cech Migracja i integracja: Zapewniające narzędzie wspierające migrację danych, Nie zapewniające narzędzia wspierającego migrację danych. Dostosowanie: Biblioteki API, Dynamiczna konfiguracja, Kreatory interfejsu użytkownika, Lokalizacja Modele wykonawcze: Synchroniczny, Asynchroniczny Migracja i integracja Zapewniające narzędzie wspierające migrację danych. Nie zapewniające narzędzia wspierającego migrację danych. Dostosowanie: Biblioteki API - silnik reguł biznesowych zapewnia biblioteki do programowalnego interfejsu, umożliwiającego konfigurację środowiska. Dynamiczna konfiguracja – silnik reguł biznesowych umożliwia dynamiczną konfigurację uruchomieniową poszczególnych modułów np. w postaci możliwości wyłączania modułów nadmiarowych lub zastępowania ich autorskimi implementacjami (dotyczy np. utrwalania danych w trwałym źródle danych). Kreatory interfejsu użytkownika – zapewnienie narzędzi do wizualnego zdefiniowania widoku, jakim użytkownik manipuluje danymi. Lokalizacja - zapewnienie konfiguracji silnika reguł biznesowych, w zależności od położenia geograficznego użytkowników systemu informatycznego. Modele wykonawcze – oba kryteria mogą być równocześnie spełnione, jeśli np. silnik reguł biznesowych pozwala na określenie kryterium na poziomie definicji przepływu. Synchroniczny – zapewnia synchroniczne wykonanie kroków silnika reguł biznesowych. Asynchroniczny – zapewnia asynchroniczne wykonanie kroków silnika reguł biznesowych.

Przykładowe wymagania wobec logiki biznesowej WIG 𝑡 = 𝑖=1 𝑁 𝑤 𝑖𝑡 ∗ 𝑃 𝑖𝑡 / 𝑖=1 5 𝑤 𝑖𝐵 ∗ 𝑃 𝑖𝐵 ∗ 𝐾 𝑡 ∗1000 Sekwencyjne – Algorytm wyliczenia WIG’u N – liczba spółek uwzględnionych w indeksie (wszystkie spółki rynku podstawowego) WIG 𝑡 – wartość WIG w chwili t 𝑤 𝑖𝑡 – liczba akcji i-tej spółki w okresie t 𝑃 𝑖𝑡 – kurs akcji i-tej spółki w okresie t 𝑤 𝑖𝐵 - liczba akcji i-tej spółki w okresie podstawowym 𝑃 𝑖𝐵 – kurs akcji i-tej spółki w okresie podstawowym 𝐾 𝑡 – współczynnik korygujący, którego uwzględnienie pozwala na wyliczenie indeksu

Przykładowe wymagania wobec logiki biznesowej
Analiza silników reguł biznesowych Przykładowe wymagania wobec logiki biznesowej Stanowe – Proces akceptacji faktury

Silniki reguł biznesowych – przykładowe implementacje
Analiza silników reguł biznesowych Silniki reguł biznesowych – przykładowe implementacje Bonita JBoss Drools Microsoft Workflow Fundation Bonita – jest połączeniem trzech rozwiązań. Zawiera narzędzie do modelowania procesów biznesowych, silnik reguł biznesowych oraz środowisko tworzenia graficznego interfejsu użytkownika. Dodatkowym atutem tego środowiska jest rozróżnienie analityki biznesowej, której celem jest właściwa definicja modelu procesu i inżynierii procesu, której celem jest kompletność i wykonanie zaprojektowanego modelu. Firma JBoss rozwija projekt Drools ( którego składnikiem jest silnik reguł biznesowych. Projekt zawiera kilka modułów, umożliwiających skalowanie na poziomie architektonicznym zaangażowania modułów firmy JBoss w strukturę budowanego systemu informatycznego. Silnik reguł biznesowych JBoss Drools Expert jest oparty o wirtualną maszynę Java i jest komponentem, dostarczającym bazę wiedzy i mechanizmy do jej tworzenia. Koncepcją rozwiązania JBoss Drools jest rozbicie obsługi procesu na mniejsze moduły, odpowiedzialne za przepływ pracy, przetwarzanie reguł biznesowych, budowanie interfejsu użytkownika itd. Uzyskany w ten sposób podział na podmoduły umożliwia osadzanie tylko wybranych elementów z rodziny JBoss. Według publikacji „Drools Expert User Guide” – Silnik reguł biznesowych jest odpowiedzią na postulat migracji sztucznej inteligencji i technik informatycznych. Celem jest stworzenie deklaratywnego środowiska reprezentacji i rozumienia wiedzy (ang. „Knowledge Representation and Reasoning”) oraz systemów ekspertowych. Silnik reguł biznesowych Drools powstał w oparciu o PRS („Production Rule System”) i wykorzystuje algorytm Rete. Windows Workflow Fundation, jako element w .NET framework stanowi alternatywę dla implementacji logiki biznesowej. Cechami, które wyróżniają go na tle innych podjeść są przede wszystkim: deklaratywność, graficzny interfejs i jednocześnie duża elastyczność, pozwalająca implementować dowolną funkcję. U podstaw WF leży separacja akcji, czyli wykonywanych czynności od fizycznego ich umiejscowienia. Takie podejście zapewnia możliwość dowolnego przegrupowania akcji, co odpowiada częstej sytuacji biznesowej, kiedy podczas wytwarzania systemu informatycznego zachodzi potrzeba wprowadzania zmian. Składnikami logiki biznesowej jest zbiór dyskretnie wykonywanych, przetestowanych komponentów.

Analiza silników reguł biznesowych Silniki reguł biznesowych – przykładowe implementacje Bonita Główne menu Pasek narzędziowy Diagram przepływu Właściwości zaznaczonego obiektu Środowisko Bonita Studio pozwala wizualnie określić przepływ dla danych. Wymagana jest znajomość notacji biznesowej – BPMN. Kluczowym elementem tego środowiska jest: Pasek narzędziowy, zawierający komponenty składowe przepływu Diagram przepływu, zawierający rozmieszczenie komponentów Okno właściwości zaznaczonego obiektu, umożliwiające dostosowanie poszczególnych atrybutów obiektu w celu osiągnięcia pożądanego rezultatu

Analiza silników reguł biznesowych Silniki reguł biznesowych – przykładowe implementacje Bonita Komponenty aktywności Komponenty sterowania przepływem Komponenty stanów inicjalnych i terminalnych Komponenty zaawansowanego dopasowania Komponenty procesowe

Analiza silników reguł biznesowych Silniki reguł biznesowych – przykładowe implementacje Bonita Bramka OR - Wejście Bramka OR - Wyjście Bramka AND - Wejście Bramka AND - Wyjście

Analiza silników reguł biznesowych Silniki reguł biznesowych – przykładowe implementacje Bonita Bramka inkluzji

Analiza silników reguł biznesowych Silniki reguł biznesowych – przykładowe implementacje Bonita – Łączniki Jednym z elementów, wpierających szybką implementację przepływu danych w systemie Bonita są Łączniki. Stanowią one platformę do migracji danych pomiędzy systemem Bonita a systemami zewnętrznymi. Kontekstem uruchomieniowym dla łącznika jest zadanie (aktualny krok procesu przepływu) lub pula. Podczas definicji takiego zadania, można w dziale łączników zdefiniować odpowiedni łącznik oraz moment jego wykonania. Łączniki mogą wykorzystywać zmienne, zadeklarowane w silniku reguł biznesowych. System Bonita dostarcza predefiniowanego zbioru łączników, możliwa jest również rozbudowa tego zbioru o własne typy. Zasada działania łącznika - konfiguracja zamiast kodu w celu wymiany danych z zewnętrznym systemem Łączniki do innych systemów.

Analiza silników reguł biznesowych Silniki reguł biznesowych – przykładowe implementacje Bonita – Kreatory formularzy Dostarczanym razem z systemem modułem jest narzędzie tworzenia formularzy do wprowadzania danych. Moduł w systemie Bonita nosi nazwę „User XP” i zawiera zbiór kreatorów i kontrolek, umożliwiających szybką implementację widoku dla danych Edytor formularza wprowadzania danych. Formularz tworzenia widoku - wybór zmiennych, prezentowanych dla użytkownika ludzkiego

Analiza silników reguł biznesowych Silniki reguł biznesowych – przykładowe implementacje Bonita – Wprowadzanie reguły biznesowej Miejsce wpisania wyrażenia Użytkownik wpisuje w polu wyrażenie, którego wykonanie zwraca wartość logiczną (prawda albo fałsz) i w odpowiedzi podana ścieżka przepływu jest lub nie jest wykonywana. Innym sposobem wprowadzania reguł biznesowych jest tabela decyzyjna. Każda z metod wprowadzenia wyrażenia powoduje określenie reguły biznesowej, warunkującej wykonanie danego przejścia w silniku reguł biznesowych. Różnorodność sposobu określenia reguły sprzyja uniwersalizmowi funkcjonalnemu. Środowisko Bonita może być używane zarówno przez architektów, skupionych na budowie procesu biznesowego, którzy nie muszą posiadać wiedzy na temat budowania wyrażeń – wtedy pomocne jest narzędzie tabeli decyzyjnej, jak i programistów, dla których szybkie określenie wyrażenia jest bardziej pomocne od rozbudowanych kreatorów. Formularz edycyjny przejścia z miejscem określenia reguły biznesowej Określanie reguły biznesowej przy pomocy edytora.

Analiza silników reguł biznesowych Silniki reguł biznesowych – przykładowe implementacje Bonita – Przykład implementacji ścieżki akceptacji dokumentu faktury.

Analiza silników reguł biznesowych Silniki reguł biznesowych – przykładowe implementacje Bonita – Przykład implementacji ścieżki akceptacji dokumentu faktury. Określenie zmiennych procesu obsługi faktury Przykład wykorzystania zmiennej.

Analiza silników reguł biznesowych Silniki reguł biznesowych – przykładowe implementacje Bonita – Przykład implementacji algorytmu wyliczenia WIG’u

Analiza silników reguł biznesowych Silniki reguł biznesowych – przykładowe implementacje Bonita – Podsumowanie Szybka implementacja systemów, opartych o przepływ stanowy Intuicyjny diagram przepływu (oparty na BPMN) Bogaty zbiór kreatorów. Bogata dokumentacja techniczna Architektura niezależna od Systemu Operacyjnego. Oprogramowanie dostarczane przez BonitaSoft umożliwia szybką implementację systemu informatycznego o strukturze procesowej. Szybki proces wytwórczy jest wspierany przez bogaty zbiór kreatorów, edytorów, dobrą dokumentację techniczną wraz z przykładowymi scenariuszami diagramów, co w znaczący sposób przyspiesza zrozumienie narzędzia i wyprodukowanie przy jego pomocy gotowego rozwiązania. Atutem jest również oparcie rozwiązania na środowisku wirtualnej maszyny Java i serwerze JEE. Będący obecnie standardem korporacyjnym, JEE stanowi podstawę dla dużej ilości obecne budowanych systemów. Bonita jest środowiskiem silnie implementującym założenia BPMN. Fakt ten wpływa na trudności podczas implementacji algorytmów, odbiegających od podejścia procesowego, takich jak np. przepływy sekwencyjne. Dla diagramów o charakterystyce nieprocesowej, środowisko Bonita nie oferuje takich usprawnień, co powoduje, że system informatyczny, budowany w oparciu o środowisko Bonita i wykorzystujący nieprocesowe algorytmy nie będzie cechował się łatwiejszą modyfikacją i konserwacją.

Bonita – przegląd cech Kategoria Cecha silnika reguł biznesowych Odzwierciedlenie w produkcie Architektura Całkowita Bonita zawiera kreatory, pozwalające na całościowe wytworzenie systemu. Wsparcie edukacyjne Gotowe scenariusze użycia Strona zawiera gotowe scenariusze wraz z omówieniem, prezentujące kluczowe moduły. Pomoc on-line Oprócz pomocy w postaci dokumentacji, istnieje bogaty zbiór forów dyskusyjnych i przykładów, umożliwiających podzielenie się lub uzyskanie informacji na tematy związane ze środowiskiem Bonita. Środowisko uruchomieniowe Niezależne od platformy systemu informatycznego Bonita wykorzystuje środowisko Java oraz serwer JEE. Wytworzony system informatyczny może być osadzony na dowolnej platformie, zgodnej z tym standardem. Oprogramowanie dostarczane przez BonitaSoft umożliwia szybką implementację systemu informatycznego o strukturze procesowej. Szybki proces wytwórczy jest wspierany przez bogaty zbiór kreatorów, edytorów, dobrą dokumentację techniczną wraz z przykładowymi scenariuszami diagramów, co w znaczący sposób przyspiesza zrozumienie narzędzia i wyprodukowanie przy jego pomocy gotowego rozwiązania. Atutem jest również oparcie rozwiązania na środowisku wirtualnej maszyny Java i serwerze JEE. Będący obecnie standardem korporacyjnym, JEE stanowi podstawę dla dużej ilości obecne budowanych systemów. Bonita jest środowiskiem silnie implementującym założenia BPMN. Fakt ten wpływa na trudności podczas implementacji algorytmów, odbiegających od podejścia procesowego, takich jak np. przepływy sekwencyjne. Dla diagramów o charakterystyce nieprocesowej, środowisko Bonita nie oferuje takich usprawnień, co powoduje, że system informatyczny, budowany w oparciu o środowisko Bonita i wykorzystujący nieprocesowe algorytmy nie będzie cechował się łatwiejszą modyfikacją i konserwacją.

Bonita – przegląd cech Interfejs użytkownika Graficzny interfejs użytkownika Elementem systemu Bonita jest narzędzie edytora diagramu przepływu, graficznych formularzy. Interfejs administracyjny Bonita User Experience jest narzędziem, prezentującym przebieg przepływu dla zdefiniowanych obiektów. Wersjonowanie Wszystkie diagramy, ustawienia projektu, zmienne w środowisku Bonita są wersjonowane. Koszty drożenia Oprogramowanie „open source” Bonita jest dostępna w kilku pakietach, z których darmowy - Bonita Open Solution pozwala na utworzenie systemu informatycznego bez ponoszenia opłat. Wersje subskrybowane są wzbogacane o dodatkowe mechanizmy do migracji czy też skalowania systemu informatycznego. Oprogramowanie dostarczane przez BonitaSoft umożliwia szybką implementację systemu informatycznego o strukturze procesowej. Szybki proces wytwórczy jest wspierany przez bogaty zbiór kreatorów, edytorów, dobrą dokumentację techniczną wraz z przykładowymi scenariuszami diagramów, co w znaczący sposób przyspiesza zrozumienie narzędzia i wyprodukowanie przy jego pomocy gotowego rozwiązania. Atutem jest również oparcie rozwiązania na środowisku wirtualnej maszyny Java i serwerze JEE. Będący obecnie standardem korporacyjnym, JEE stanowi podstawę dla dużej ilości obecne budowanych systemów. Bonita jest środowiskiem silnie implementującym założenia BPMN. Fakt ten wpływa na trudności podczas implementacji algorytmów, odbiegających od podejścia procesowego, takich jak np. przepływy sekwencyjne. Dla diagramów o charakterystyce nieprocesowej, środowisko Bonita nie oferuje takich usprawnień, co powoduje, że system informatyczny, budowany w oparciu o środowisko Bonita i wykorzystujący nieprocesowe algorytmy nie będzie cechował się łatwiejszą modyfikacją i konserwacją.

Bonita – przegląd cech Obsługiwane standardy implementacji reguł Maszyna stanowa Kluczowym elementem jest diagram przepływu w BPMN. Bonita nie obsługuje innych standardów. Skalowalność Autoryzacja użytkowników Bonita jest środowiskiem wielodostępowym. Wymaganiem wobec diagramu jest określenie minimum jednego aktora, który może uruchomić proces. Podział funkcji ze względu na role użytkowników Bonita pozwala określać dostęp do poszczególnych elementów diagramu, poprzez obiekt linii. Rodzaj dystrybucji Aplikacja System informatyczny jest dystrybuowany w postaci pliku war (web archive) środowiska Java i stanowi kompletną aplikację, do osadzenia na serwerze JEE. Oprogramowanie dostarczane przez BonitaSoft umożliwia szybką implementację systemu informatycznego o strukturze procesowej. Szybki proces wytwórczy jest wspierany przez bogaty zbiór kreatorów, edytorów, dobrą dokumentację techniczną wraz z przykładowymi scenariuszami diagramów, co w znaczący sposób przyspiesza zrozumienie narzędzia i wyprodukowanie przy jego pomocy gotowego rozwiązania. Atutem jest również oparcie rozwiązania na środowisku wirtualnej maszyny Java i serwerze JEE. Będący obecnie standardem korporacyjnym, JEE stanowi podstawę dla dużej ilości obecne budowanych systemów. Bonita jest środowiskiem silnie implementującym założenia BPMN. Fakt ten wpływa na trudności podczas implementacji algorytmów, odbiegających od podejścia procesowego, takich jak np. przepływy sekwencyjne. Dla diagramów o charakterystyce nieprocesowej, środowisko Bonita nie oferuje takich usprawnień, co powoduje, że system informatyczny, budowany w oparciu o środowisko Bonita i wykorzystujący nieprocesowe algorytmy nie będzie cechował się łatwiejszą modyfikacją i konserwacją.

Bonita – przegląd cech Dostosowanie Biblioteki API Bonita zawiera edytor wyrażeń, wspierający implementację logiki w postaci skryptu. Dostarczane są również elementy łącznika (ang. „Connectivity”). Kreatory interfejsu użytkownika Bonita dostarcza kreatory interfejsu użytkownika w postaci edytora formularzy, generującego widoki. Lokalizacja Moduł lokalizacyjny jest dostępny w wersji rozszerzonej (płatnej). Modele wykonawcze Synchroniczny Model jest obsługiwany przez środowisko Bonita np. w postaci przejść pomiędzy aktywnościami. Asynchroniczny Model jest obsługiwany przez środowisko Bonita np. poprzez obsługę zdarzeń, uruchamianie przepływu w odpowiedzi na zdarzenie czasowe. Oprogramowanie dostarczane przez BonitaSoft umożliwia szybką implementację systemu informatycznego o strukturze procesowej. Szybki proces wytwórczy jest wspierany przez bogaty zbiór kreatorów, edytorów, dobrą dokumentację techniczną wraz z przykładowymi scenariuszami diagramów, co w znaczący sposób przyspiesza zrozumienie narzędzia i wyprodukowanie przy jego pomocy gotowego rozwiązania. Atutem jest również oparcie rozwiązania na środowisku wirtualnej maszyny Java i serwerze JEE. Będący obecnie standardem korporacyjnym, JEE stanowi podstawę dla dużej ilości obecne budowanych systemów. Bonita jest środowiskiem silnie implementującym założenia BPMN. Fakt ten wpływa na trudności podczas implementacji algorytmów, odbiegających od podejścia procesowego, takich jak np. przepływy sekwencyjne. Dla diagramów o charakterystyce nieprocesowej, środowisko Bonita nie oferuje takich usprawnień, co powoduje, że system informatyczny, budowany w oparciu o środowisko Bonita i wykorzystujący nieprocesowe algorytmy nie będzie cechował się łatwiejszą modyfikacją i konserwacją.

Analiza silników reguł biznesowych Silniki reguł biznesowych – przykładowe implementacje JBoss Drools - Składniki Guvnor Expert Fusion jBPM Planner Firma JBoss rozwija projekt Drools ( którego składnikiem jest silnik reguł biznesowych. Projekt zawiera kilka modułów, umożliwiających skalowanie na poziomie architektonicznym zaangażowania modułów firmy JBoss w strukturę budowanego systemu informatycznego. Składnikami JBoss Drools są: Guvnor Jest to oparty na interfejsie sieci web, dostępny przez przeglądarkę system administracyjny dla przepływu. Stanowi platformę edycyjną dla metadanych zdefiniowanego przepływu. Expert Silnik reguł biznesowych, sterowanym deklaratywnym językiem opisu. Fusion Moduł obsługi przepływów sterowanych zdarzeniowo. jBPM Moduł umożliwia definicję przepływu. Planner Zawiera logikę umożliwiającą rozwiązywanie problemów alokacji i harmonogramowania. Środowisko reguł biznesowych, obsługujące bazę wiedzy składa się z trzech komponentów: Ontologii. Reguł. Danych.

Analiza silników reguł biznesowych Silniki reguł biznesowych – przykładowe implementacje JBoss Drools – Przykład zapisu reguły biznesowej rule when Ser( $czedar : nazwa == "cheddar" ) $osoba : Osoba( ulubionySer == $czedar ) then System.out.println( $osoba.getImie() + " lubi cheddar" ); end Przykład zakłada, że klasa Osoba ma atrybut ulubionySer oraz klasa Ser ma atrybut nazwa. Jeżeli nazwa sera to „czedar” i wartość atrybutu „ulubionySer” klasy osoba to ser o nazwie cheddar, odpowiedni komunikat zostanie wyświetlony na konsoli.

Analiza silników reguł biznesowych Silniki reguł biznesowych – przykładowe implementacje JBoss Drools – Zastosowanie Nieokreśloność rozwiązania. Brak widocznego algorytmu rozwiązania. Zmienność logiki. Wiedza ekspercka. Autorzy rozwiązania JBoss Drools adresują swój silnik reguł biznesowych do szeregu sytuacji, charakteryzujących się: Nieokreślonością rozwiązania. Sformułowanie rozwiązania może nie być złożone, ale nie jest oczywiste w momencie implementacyjnym. Wskazanym jest posługiwanie się narzędziem, umożliwiającym dynamiczne wprowadzanie zmian bez konieczności dziedziczenia wstępnie przyjętych założeń wobec logiki biznesowej systemu. Brakiem widocznego algorytmu rozwiązania. Rozwiązanie problemu nie leży w zbiorze powszechnie zrozumianych i dostępnych algorytmów. Należy je dopiero opracować. Zmiennością logiki. Wymagania wobec logiki biznesowej nie są w pełni skrystalizowane. Wiedzą ekspercką. Rozwiązanie dotyczy wiedzy, której pozyskanie wymaga czasu oraz dostępności ekspertów. W odpowiedzi na wyżej wymienione postulaty, JBoss Drools zawiera następujące główne elementy: Tekstowy język opisu reguł biznesowych. Reguły biznesowe zapisane są w postaci tekstowej, zrozumiałej dla środowiska Drools. Język opisu reguły jest językiem deklaratywnym o wysokim stopniu zrozumiałości dla człowieka (podobnie jak języki trzeciej i czwartej generacji takie jak C# lub Java). Rozróżnieniem jest ich postać – pliki tekstowe, zawierające reguły biznesowe nie są kompilowane. Stanowe i bezstanowe podejście. Kontekstem JBoss Drools jest natura zmienności danych, jakimi zasilana jest budowana baza wiedzy. Podejście bezstanowe zakłada, że dane nie zmieniają się w czasie. Podejście stanowe zakłada, że dane, jakie są przekazywane do bazy wiedzy mogą zmieniać się w czasie, co implikuje wykonanie reguł biznesowych w odpowiedzi na te zmiany.

Analiza silników reguł biznesowych Silniki reguł biznesowych – przykładowe implementacje JBoss Drools – Wybór cech Tekstowy język opisu reguł biznesowych. Stanowe i bezstanowe podejście. W odpowiedzi na wyżej wymienione postulaty, JBoss Drools zawiera następujące główne elementy: Tekstowy język opisu reguł biznesowych. Reguły biznesowe zapisane są w postaci tekstowej, zrozumiałej dla środowiska Drools. Język opisu reguły jest językiem deklaratywnym o wysokim stopniu zrozumiałości dla człowieka (podobnie jak języki trzeciej i czwartej generacji takie jak C# lub Java). Rozróżnieniem jest ich postać – pliki tekstowe, zawierające reguły biznesowe nie są kompilowane. Stanowe i bezstanowe podejście. Kontekstem JBoss Drools jest natura zmienności danych, jakimi zasilana jest budowana baza wiedzy. Podejście bezstanowe zakłada, że dane nie zmieniają się w czasie. Podejście stanowe zakłada, że dane, jakie są przekazywane do bazy wiedzy mogą zmieniać się w czasie, co implikuje wykonanie reguł biznesowych w odpowiedzi na te zmiany. Powyższe fakty potwierdzają spostrzeżenie, że użycie środowiska reguł biznesowych jest tym efektywniejsze im bardziej system informatyczny cechuje potrzeba słabego sprzęgania (ang. „Loose Coupling”) poszczególnych elementów logiki biznesowej budowanego systemu. Opis reguł biznesowych, jako kodu wykonywanego w odpowiedzi na zaistniałe warunki, przywodzi na myśl wykonanie metody w obiekcie danej klasy. Różnicą jest fakt, nieznajomości czasu, w jakim reguła zostanie wykonana. W przeciwieństwie do metody, wykonywanej w momencie jej wystąpienia w kodzie, reguła biznesowa po zadeklarowaniu i przekazaniu do środowiska JBoss Drools Expert może nigdy nie zostać wykonana, jeśli warunki jej uruchomienia nigdy nie zostaną spełnione.

Analiza silników reguł biznesowych Silniki reguł biznesowych – przykładowe implementacje JBoss Drools – Przykład implementacji ścieżki akceptacji dokumentu faktury package faktura import impl.Faktura; rule "Walidacja daty i kwot faktury" when $f : Faktura (dataFaktury == null || kwotaNetto <0 || kwotaBrutto <0) then $f.setPoprawna(false); $f.setZaakceptowana(false); $f.setKomentarz("Niepoprawne dane faktury, data faktury nie może być pusta, kwoty nie mogą być ujemne."); end

Analiza silników reguł biznesowych Silniki reguł biznesowych – przykładowe implementacje JBoss Drools – Przykład implementacji ścieżki akceptacji dokumentu faktury – c.d. rule "Walidacja numeru przypisanego zamówienia do faktury" when $f : Faktura (nrPrzypisanegoZamowienia == null) then $f.setPoprawna(false); $f.setKomentarz("Faktura musi mieć przypisany numer zamówienia"); end

Analiza silników reguł biznesowych Silniki reguł biznesowych – przykładowe implementacje JBoss Drools – Przykład implementacji ścieżki akceptacji dokumentu faktury – c.d. rule "Automatyczna akceptacja faktury o kwocie niższej niż 200" when $f : Faktura (kwotaBrutto < 200, poprawna) then $f.setZaakceptowana(true); end rule "Jeżeli faktura jest na 200 i więcej złotych musi być zaakceptowana przez kierownika pionu" $f : Faktura (kwotaBrutto >= 200) $f.setWymagaAkceptacjiKierownikaPionu(true);

Analiza silników reguł biznesowych Silniki reguł biznesowych – przykładowe implementacje JBoss Drools – Przykład implementacji algorytmu wyliczenia WIG’u. package wig import wig.WigConstans; import java.util.Date; import wig.WigWyliczenie; global wig.WigWyliczenie wigWyliczenie; rule "Akcja należy do rynku pierwotnego" no-loop dialect "java" when $a : Akcja(dataPublikacji == WigConstans.DATA_RYNKU_PIERWOTNEGO) then wigWyliczenie.setSumaPierwotna(wigWyliczenie.getSumaPierwotna()+((double)$a.getIlosc() * $a.getKurs())); end W odpowiedzi na wyżej wymienione postulaty, JBoss Drools zawiera następujące główne elementy: Tekstowy język opisu reguł biznesowych. Reguły biznesowe zapisane są w postaci tekstowej, zrozumiałej dla środowiska Drools. Język opisu reguły jest językiem deklaratywnym o wysokim stopniu zrozumiałości dla człowieka (podobnie jak języki trzeciej i czwartej generacji takie jak C# lub Java). Rozróżnieniem jest ich postać – pliki tekstowe, zawierające reguły biznesowe nie są kompilowane. Stanowe i bezstanowe podejście. Kontekstem JBoss Drools jest natura zmienności danych, jakimi zasilana jest budowana baza wiedzy. Podejście bezstanowe zakłada, że dane nie zmieniają się w czasie. Podejście stanowe zakłada, że dane, jakie są przekazywane do bazy wiedzy mogą zmieniać się w czasie, co implikuje wykonanie reguł biznesowych w odpowiedzi na te zmiany. Powyższe fakty potwierdzają spostrzeżenie, że użycie środowiska reguł biznesowych jest tym efektywniejsze im bardziej system informatyczny cechuje potrzeba słabego sprzęgania (ang. „Loose Coupling”) poszczególnych elementów logiki biznesowej budowanego systemu. Opis reguł biznesowych, jako kodu wykonywanego w odpowiedzi na zaistniałe warunki, przywodzi na myśl wykonanie metody w obiekcie danej klasy. Różnicą jest fakt, nieznajomości czasu, w jakim reguła zostanie wykonana. W przeciwieństwie do metody, wykonywanej w momencie jej wystąpienia w kodzie, reguła biznesowa po zadeklarowaniu i przekazaniu do środowiska JBoss Drools Expert może nigdy nie zostać wykonana, jeśli warunki jej uruchomienia nigdy nie zostaną spełnione.

Analiza silników reguł biznesowych Silniki reguł biznesowych – przykładowe implementacje JBoss Drools – Przykład implementacji algorytmu wyliczenia WIG’u. rule "Akcja należy do rynku obecnego" no-loop dialect "java" when $a : Akcja(dataPublikacji != WigConstans.DATA_RYNKU_PIERWOTNEGO) then wigWyliczenie.setSumaObecna(wigWyliczenie.getSumaObecna()+((double)$a.getIlosc() * $a.getKurs())); end

Analiza silników reguł biznesowych Silniki reguł biznesowych – przykładowe implementacje JBoss Drools – Podsumowanie Cechy: Elastyczne środowisko Łatwe wprowadzanie reguł Przejrzysta składnia Możliwość określania tabel decyzyjnych w arkuszach MsExcel Nieintuicyjne powiadamianie o błędach. Środowisko JBoss Drools Expert cechuje elastyczność, łatwość wprowadzania oraz przejrzystość składni reguł biznesowych. Dodatkowym atutem jest umożliwienie dostarczania reguł biznesowych w postaci tabel decyzyjnych w formie arkusza kalkulacyjnego, co stanowi ułatwienie implementacji algorytmów, które są niejawne lub pochodzące z wiedzy ekspertów domeny biznesowej budowanego systemu informatycznego. Z uwagi na tekstowy charakter reguł biznesowych, to środowisko wymagało dłuższego czasu poznawczego niż w przypadku rozwiązań opartych na notacji BPMN.

Analiza silników reguł biznesowych Silniki reguł biznesowych – przykładowe implementacje JBoss Drools – przegląd cech Architektura Częściowa JBoss Drools Expert jest komponentem, dołączanym do aplikacji. Nie może być uruchomiony samodzielnie. Wsparcie edukacyjne Pomoc on-line Strona zawiera publikacje, umożliwiające poznanie środowiska. Przykłady zawierają błędy oraz czasami są niekompletne. Środowisko uruchomieniowe Niezależne od platformy systemu informatycznego JBoss Drools wykorzystuje środowisko Java, jako komponent systemu informatycznego środowisko uruchomieniowe jest zależne od środowiska uruchomieniowego systemu informatycznego. Interfejs użytkownika Język obsługi reguł biznesowych Jednostką wykonawczą środowiska jest reguła biznesowa, zapisana w języku opisu. Arkusz w formacie xls Reguły biznesowe mogą pochodzić z tabel decyzyjnych zapisanych w arkuszu xls lub csv.

Analiza silników reguł biznesowych Silniki reguł biznesowych – przykładowe implementacje JBoss Drools – przegląd cech Koszty drożenia Oprogramowanie „open source” JBoss Drools Expert jest dostępny na licencji „open source”. Obsługiwane standardy implementacji reguł Maszyna stanowa, Model sekwencyjny. JBoss Drools zapewnia obsługę obu modeli za pomocą stanowego i bezstanowego obiektu sesji. W przypadku zmian obiektów w czasie, należy wybrać stanową wersję obiektu sesji bazy wiedzy. Rodzaj dystrybucji Usługa Silnik reguł biznesowych jest komponentem, stąd pełni rolę usługową wobec innych elementów systemu informatycznego. Dostosowanie Biblioteki API Silnik reguł biznesowych posiada bogaty zbiór klas, pozwalających wywoływać wybrane funkcje silnika lub reagować na zachodzące zdarzenia.

Analiza silników reguł biznesowych Silniki reguł biznesowych – przykładowe implementacje JBoss Drools – przegląd cech Modele wykonawcze Synchroniczny, Asynchroniczny Jest to zależne od modelu implementacji kontenera, wywołującego środowisko.

Analiza silników reguł biznesowych Silniki reguł biznesowych – przykładowe implementacje Microsoft Workflow Fundation Windows Workflow Fundation jest komponentem, pozwalającym na dodawanie nowych funkcji, poprzez wskazywanie modułów, implementujących akceptowany przez ten komponent interfejs. Przykładem może być warstwa utrwalania danych. Workflow Fundation pozwala na zdefiniowanie przez programistę własnego modułu, odpowiedzialnego za zapis informacji o obiektach podlegających przepływowi. Workflow Fundation zapewnia dwa podejścia do implementacji logiki biznesowej: Sekwencyjne. Diagram przepływu na postać sekwencji wykonywanych czynności, z wyraźnie zaznaczonym początkiem, wykonywanymi krokami i końcem. Podejście to jest cechuje konieczność precyzyjnego określenia poprzednika i następnika podczas wykonywania algorytmu. Workflow Fundation dostarcza całej gamy komponentów do budowy przepływu, oraz daje możliwość tworzenia własnych. Microsoft Visual Studio 2010 z uruchomionym diagramem przepływu w Workflow Fundation

Analiza silników reguł biznesowych Silniki reguł biznesowych – przykładowe implementacje Microsoft Workflow Fundation Aktywność na diagramie przepływu Aktywność – widok na pasku narzędziowym

Analiza silników reguł biznesowych Silniki reguł biznesowych – przykładowe implementacje Microsoft Workflow Fundation Aktywność na diagramie przepływu Aktywność jest komponentem, realizującym zbiór akcji, których wykonanie nie może być przerwane. Aktywność – widok na pasku narzędziowym

Analiza silników reguł biznesowych Silniki reguł biznesowych – przykładowe implementacje Microsoft Workflow Fundation Komponent warunku przetwarza reguły i w zależności od ich spełnienia wybierana jest droga wykonania. Warunek – widok na pasku narzędziowym Warunek na diagramie przepływu

Analiza silników reguł biznesowych Silniki reguł biznesowych – przykładowe implementacje Microsoft Workflow Fundation Okno właściwości komponentu "pętla Pętla zapewnia iteracyjny wymóg przetwarzania diagramu sekwencyjnego. Po zdefiniowaniu warunku, pozwala na osadzenie aktywności, wykonywanych tak długo, aż warunek jest spełniony. Opisane powyżej komponenty sterujące – warunek oraz pętla, wymagają określenia reguł. Realizowane jest to za pomocą właściwości komponentu. Okno z właściwościami komponentu „pętla” obrazuje warunek – w tym przypadku o nazwie „czyPrzetwozonoWszystkieAkcje” oraz wyrażenie, definiujące logiczny rezultat. Wprowadzenie wyrażenie jest realizowane za pomocą kreatora Pętla – widok na pasku narzędziowym Pętla na diagramie przepływu

Analiza silników reguł biznesowych Silniki reguł biznesowych – przykładowe implementacje Microsoft Workflow Fundation Komponent obrazujący stan na diagramie przepływu Dla przepływów, których kolejność kroków wykonania nie jest z góry możliwa do przewidzenia (np. kiedy kolejne kroki przepływu stanowią reakcję na działania użytkownika), Workflow Fundation umożliwia tworzenie przepływu za pomocą maszyny stanowej. Tego typu podejście rozszerza diagram sekwencyjny o możliwość uruchomienia czynności w odpowiedzi na zdarzenia, płynące z systemu informatycznego. Podobnie jak w przypadku diagramu sekwencji, diagram stanowy również posiada bogaty zbiór komponentów, warunkujących zachowanie, rodzaj odpowiedzi, uwrażliwienie na konkretne zdarzenia np. takie, które pochodzą z wywołań usług zdalnych. Głównym z tych komponentów jest Stan. Aktywność zdarzeniowa

Analiza silników reguł biznesowych Silniki reguł biznesowych – przykładowe implementacje Microsoft Workflow Fundation - Przykład implementacji ścieżki akceptacji dokumentu faktury Wnioski z implementacji. Microsoft Workflow Fundation jest środowiskiem komponentowym, umożliwiającym szybkie zaimplementowanie złożonych przepływów. Cechą szczególną jest otwartość i łatwość, z jaką można rozszerzyć działanie o nowej funkcje, np. poprzez dodawanie bloków kodu, wstawianie komponentów warunków, lub zmiany stanów. Przearanżowanie przepływu jest działaniem nie wymagającym wiedzy informatycznej, stąd może być wykonane przez ekspertów dziedziny biznesowej lub analityków. Napotkanymi utrudnieniami były problemy związane z wyłapaniem i usuwaniem błędów. Środowisko deklaratywne nie jest tak rozwinięte jak, cechujące się rozbudowanymi debbugerami środowisko programistyczne. Innym problemem była kwestia spowolnienia w przypadku przepływów o ilości stanów przekraczających 20 sztuk.

Analiza silników reguł biznesowych Silniki reguł biznesowych – przykładowe implementacje Microsoft Workflow Fundation - Przykład implementacji ścieżki akceptacji dokumentu faktury Na rysunku widać, że jest to zdarzenie „WyslijDoZamawiajacego” zadeklarowane w interfejsie IFakturaUslugi. Kolejnym komponentem jest „PowiadomOAkceptacjiZamawiajacego”, zawierającego definicję metody, wywoływanej w momencie przejścia przepływu do miejsca wystąpienia komponentu. Kolejnym elementem jest warunek, gdzie rozpatrywana jest reguła biznesowa. Reguła biznesowa jest zapisana w postaci deklaratywnej, poprzez wyrażenie: this.Faktura.KwotaBrutto <= 200. Wykorzystywany jest fakt, że przepływ podczas zdarzenia rejestracji został zasilony danymi faktury. Jeśli warunek reguły jest spełniony, przepływ skierowany jest do komponentu wywołującego zewnętrzną metodę oraz przejście do statusu „Księgowość”. Okno właściwości kontrolki obsługi zdarzenia. Reguła biznesowa warunkująca wykonanie

Analiza silników reguł biznesowych Silniki reguł biznesowych – przykładowe implementacje Microsoft Workflow Fundation - Przykład implementacji algorytmu wyliczenia WIG’u Powyższy diagram obrazuje idee wyliczenia indeksu. Po uruchomieniu wykonywane są czynności inicjacyjne w postaci aktywności „ustawParametryStartowe” następnie sprawdzany jest warunek, czy przetworzono wszystkie akcje. Jeżeli są jeszcze akcje do przetworzenia, badana jest data publikacji akcji i jeśli akcja jest opublikowana przed 16 kwietnia 1993 roku (datą pierwszej sesji Warszawskiej Giełdy), wtedy taka akcja zaliczana jest do rynku pierwotnego, w przeciwnym razie zaliczana jest do rynku bieżącego. Diagram przepływu jest wywoływany z poziomu aplikacji na zasadzie „czarnej skrzynki”, jako instancja obiektu danej klasy i zasilany danymi w postaci listy akcji. Tutaj również daje się odczuć wizualny charakterze przetwarzania. Analityk giełdowy lub osoba nie posiadająca wiedzy informatycznej, może przestawiać wybrane elementy lub zmieniać reguły biznesowe, regulujące przetwarzanie. Silnik reguł biznesowych firmy Microsoft jest dobrą alternatywą dla przepływów sekwencyjnych lub stanowych o małej ilości stanów. W przypadku, kiedy diagram przepływu nadmiernie się rozrasta należy rozważyć rozdzielenie go na mniejsze tak, aby zapewnić odpowiednią ergonomię pracy oraz czas wykonania. Dużym udogodnieniem jest bogaty zbiór możliwych rozszerzeń oraz komunikacja za pomocą standardu WCF. Inicjowanie przepływu zdarzeniami również należy odnotować jako zaletę.

Microsoft Workflow Fundation – przegląd cech Architektura Częściowa Silnik reguł biznesowych dostępny jest na zasadzie komponentu Wsparcie edukacyjne Pomoc on-line Bogata biblioteka artykułów w systemie msdn firmy Microsoft Publikacje Workflow Fundation jest opisany w kilku książkach, między innymi „Pro WF” wydawnictwa Apress. Środowisko uruchomieniowe Microsoft Framework .NET Nakłada to ograniczenie systemów z rodziny Windows. Interfejs użytkownika Graficzny interfejs użytkownika Elementem systemu jest narzędzie edytora diagramu przepływu, graficznych formularzy. Język reguł biznesowych Oparty na xml’u, deklaratywny język reguł biznesowych. Powyższy diagram obrazuje idee wyliczenia indeksu. Po uruchomieniu wykonywane są czynności inicjacyjne w postaci aktywności „ustawParametryStartowe” następnie sprawdzany jest warunek, czy przetworzono wszystkie akcje. Jeżeli są jeszcze akcje do przetworzenia, badana jest data publikacji akcji i jeśli akcja jest opublikowana przed 16 kwietnia 1993 roku (datą pierwszej sesji Warszawskiej Giełdy), wtedy taka akcja zaliczana jest do rynku pierwotnego, w przeciwnym razie zaliczana jest do rynku bieżącego. Diagram przepływu jest wywoływany z poziomu aplikacji na zasadzie „czarnej skrzynki”, jako instancja obiektu danej klasy i zasilany danymi w postaci listy akcji. Tutaj również daje się odczuć wizualny charakterze przetwarzania. Analityk giełdowy lub osoba nie posiadająca wiedzy informatycznej, może przestawiać wybrane elementy lub zmieniać reguły biznesowe, regulujące przetwarzanie. Silnik reguł biznesowych firmy Microsoft jest dobrą alternatywą dla przepływów sekwencyjnych lub stanowych o małej ilości stanów. W przypadku, kiedy diagram przepływu nadmiernie się rozrasta należy rozważyć rozdzielenie go na mniejsze tak, aby zapewnić odpowiednią ergonomię pracy oraz czas wykonania. Dużym udogodnieniem jest bogaty zbiór możliwych rozszerzeń oraz komunikacja za pomocą standardu WCF. Inicjowanie przepływu zdarzeniami również należy odnotować jako zaletę.

Microsoft Workflow Fundation – przegląd cech Koszty drożenia Oprogramowanie komercyjne Koszt wdrożenia musi zawierać minimum koszt systemu z rodziny Windows, obsługujący Microsoft Framework .NET. Obsługiwane standardy implementacji reguł Maszyna stanowa Diagram maszyny stanowej, edytowany z poziomu graficznego edytora. Model sekwencyjny Diagram sekwencji, edytowany z poziomu graficznego edytora. Rodzaj dystrybucji Usługa Diagram przepływu dostarczany jest jako komponent i musi zostać obudowany formularzami w celu wykorzystania w systemie informatycznym. Dostosowanie Biblioteki API Workflow Fundation pozwala na rozbudowanie funkcji o moduły np. utrwalania danych. Dodatkowym elementem jest bogaty zbiór wystawionych zdarzeń, jakie użytkownik może zaimplementować (np. do powiadamiania o nieprawidłowych akcjach). Modele wykonawcze Synchroniczny Model jest obsługiwany przez środowisko np. w postaci przejść pomiędzy aktywnościami. Asynchroniczny Model jest obsługiwany przez środowisko np. poprzez obsługę zdarzeń, uruchamianie przepływu w odpowiedzi na zdarzenie czasowe. Powyższy diagram obrazuje idee wyliczenia indeksu. Po uruchomieniu wykonywane są czynności inicjacyjne w postaci aktywności „ustawParametryStartowe” następnie sprawdzany jest warunek, czy przetworzono wszystkie akcje. Jeżeli są jeszcze akcje do przetworzenia, badana jest data publikacji akcji i jeśli akcja jest opublikowana przed 16 kwietnia 1993 roku (datą pierwszej sesji Warszawskiej Giełdy), wtedy taka akcja zaliczana jest do rynku pierwotnego, w przeciwnym razie zaliczana jest do rynku bieżącego. Diagram przepływu jest wywoływany z poziomu aplikacji na zasadzie „czarnej skrzynki”, jako instancja obiektu danej klasy i zasilany danymi w postaci listy akcji. Tutaj również daje się odczuć wizualny charakterze przetwarzania. Analityk giełdowy lub osoba nie posiadająca wiedzy informatycznej, może przestawiać wybrane elementy lub zmieniać reguły biznesowe, regulujące przetwarzanie. Silnik reguł biznesowych firmy Microsoft jest dobrą alternatywą dla przepływów sekwencyjnych lub stanowych o małej ilości stanów. W przypadku, kiedy diagram przepływu nadmiernie się rozrasta należy rozważyć rozdzielenie go na mniejsze tak, aby zapewnić odpowiednią ergonomię pracy oraz czas wykonania. Dużym udogodnieniem jest bogaty zbiór możliwych rozszerzeń oraz komunikacja za pomocą standardu WCF. Inicjowanie przepływu zdarzeniami również należy odnotować jako zaletę.

Miary Jakościowe: Przejrzysty / Nieprzejrzysty Udokumentowany: Bardzo dobrze, dobrze, przeciętnie Rozbudowywalny / Zamknięty Ilościowe Ilość czasu, jaka była potrzebna do: Zaimplementowania silnika reguł biznesowych Wykonania pojedynczej reguły biznesowej

Użyteczność. Łatwość nauki Efektywność Intuicyjność. Błędogenność. Satysfakcja. Ocena całkowita = 0,1∗ Ś𝑟𝑒𝑑𝑛𝑖𝑎 ł𝑎𝑡𝑤𝑜ść 𝑛𝑎𝑢𝑘𝑖 Ł𝑎𝑡𝑤𝑜ść 𝑛𝑎𝑢𝑘𝑖 + 0,5∗ Ś𝑟𝑒𝑑𝑛𝑖𝑎 𝑒𝑓𝑒𝑘𝑡𝑦𝑤𝑛𝑜ść 𝐸𝑓𝑒𝑘𝑡𝑦𝑤𝑛𝑜ść + 0,3∗ Ś𝑟𝑒𝑑𝑛𝑖𝑎 𝑖𝑛𝑡𝑢𝑖𝑐𝑦𝑗𝑛𝑜ść 𝐼𝑛𝑡𝑢𝑖𝑐𝑦𝑗𝑛𝑜ść + 0,1 ∗ 𝐵łę𝑑𝑛𝑜ść 3 + 0,1∗ 𝑆𝑎𝑡𝑦𝑓𝑎𝑘𝑐𝑗𝑎 3 Według normy ISO 9241, zdefiniowanej w 1998 roku, użyteczność jest pochodną wydajności, satysfakcji użytkownika i efektywności. Na tej podstawie Jakob Nielsen ur. w 1957 r. w Kopenhadze, specjalista w dziedzinie użyteczności w kontekście informatyki, zdefiniował pięć elementów użyteczności: Łatwość nauki Miara czasu, potrzebna do wykonania prostego zadania bez wcześniejszej wiedzy na temat produktu. Efektywność Szybkość realizacji celów przy użyciu narzędzia, przez użytkowników, którzy znają produkt. Intuicyjność. Miara czasu, określająca jak szybko użytkownik przypomina sobie jak używać dany produkt. Błędogenność. Częstotliwość powielania i łatwość ich naprawy. Dla potrzeb weryfikacji cechy, określiłem następującą skalę: Duża (wartość 3) – produkt często posiada błędne zachowanie, które generuje niepożądaną reakcję użytkownika. Średnia (wartość 2) – niski współczynnik błędnego zachowania. Mała (wartość 1) – produkt jest przejrzysty, użytkownik jest naprowadzany na rozwiązanie. Satysfakcja. Określająca przyjazność produktu dla użytkownika. Dla potrzeb weryfikacji cechy określono następującą skalę: Duża (wartość 3) – produkt posiada dobre wsparcie zarówno pod względem merytorycznym, dostarczając pomoce naukowe, jak i podczas użytkowania, kiedy ułatwia pracę np. poprzez dostarczanie graficznych interfejsów użytkownika. Średnia (wartość 2) – produkt nie jest w pełni zrozumiały, niektóre funkcje są nieintuicyjne. Mała (wartość 1) – produkt wymaga wiedzy eksperckiej, nie jest zrozumiały dla początkującego użytkownika Wartości średnie Średnia łatwość nauki 190 min. Średnia efektywność 21,6 min. Średnia intuicyjność 28,3 min.

Użyteczność. Cecha Bonita JBoss Drools Expert Microsoft Workflow Fundation Łatwość nauki 150 min. 240 min. 180 min. Efektywność 25 min. 10 min. 30 min. Intuicyjność 15 min. 60 min. Błędność Mała Średnia Satysfakcja Duża Ocena 1,25 1,42 1,44 Ocena procentowa 86 % 98 % 100 %

Niezawodność Wysoka (wartość 3) Średnia (wartość 2) Niska (wartość 1) Cecha Bonita JBoss Drools Expert Microsoft Workflow Fundation Niezawodność Niska Wysoka Średnia. Ocena 1 3 2 Ocena procentowa 33 % 100 % 66 % Wysoka (wartość 3) Oznacza jednakową pracę silnika reguł biznesowych, bez względu na ilość obiektów, podlegających przetwarzaniu. Średnia (wartość 2) Oznacza kilu (od 1 do 9) procentowy spadek wydajności przy zastosowaniu zaawansowanego algorytmu, w stosunku do przetwarzania algorytmu o mniejszej złożoności. Niska (wartość 1) Oznacza znaczny (powyżej 10 procent) spadek wydajności przy zastosowaniu zaawansowanego algorytmu.

Ryzyko Utrata wsparcia technicznego. Zakończenie cyklu wytwórczego. Niekompatybilność. Wzrost kosztów utrzymania. Wartość numeryczna Wartość skali Warunki 1 Niskie oznacza niezerowe prawdopodobieństwo, przy założeniu że maksymalna ilość wystąpień jest nie większa niż 15 na 100 2 Prawdopodobne oznacza prawdopodobieństwo między 0,15 a 0,45 3 Wysokie oznacza prawdopodobieństwo między 0,45 a 0,8 4 Bardzo prawdopodobne oznacza prawdopodobieństwo między 0,8 a 0,99 Do analizy ryzyka dla silników reguł biznesowych wykorzystano następujące miary prawdopodobieństwa: Utrata wsparcia technicznego. Producent silnika reguł biznesowych zadecydował o zaprzestaniu wspierania użytkowników. Zakończenie cyklu wytwórczego. Silnik reguł biznesowych nie będzie dalej rozwijany. Niekompatybilność. Określenie stopnia niedopasowania wymagań do możliwości technicznych silnika reguł biznesowych. Wzrost kosztów utrzymania. Określenie prawdopodobieństwa wprowadzenia dodatkowych opłat lub podwyższenia bieżących.

Ryzyko Cecha Bonita JBoss Drools Expert Microsoft Workflow Fundation Utrata wsparcia technicznego Niskie Niskie. Zakończenie cyklu wytwórczego Prawdopodobne Niekompatybilność Wzrost kosztów utrzymania Wysokie Ocena 6 5 Ocena procentowa 100% 100 % 83%

Jakość Wymagania użytkownika. Cechy techniczne wyrobu. Różnorodność technologiczna. Stopień korelacji między cechami technicznymi. Analizując jakość, wykorzystane zostały cechy silników reguł biznesowych w kontekście zbieżności z potencjalnie pożądanymi efektami wdrożenia silnika reguł biznesowych w miejscu tradycyjnie budowanego rozwiązania. Definicji uległy następujące cechy: Wymagania użytkownika. Cecha została zdefiniowana jako miara dostępności i zrozumiałości silnika reguł biznesowych dla ekspertów dziedziny biznesowej budowanego systemu. Określa stopień możliwości implementacji wymagań funkcjonalnych, gdzie: Bardzo dobry Wartość 3 – określa wysoki poziom abstrakcji, umożliwiający łatwą naukę i realizację wymagań bez konieczności konsultacji z ekspertem ds. produkcji oprogramowania. Dobry Wartość 2 – określa wysoki poziom abstrakcji, wymagający jednak konsultacji z ekspertem ds. produkcji oprogramowania. Średni Wartość 1 – określa niski poziom abstrakcji, zadanie implementacyjne wymaga delegowania do konsultanta ds. produkcji oprogramowania. Dla tej miary – silnik reguł biznesowych jest ułatwieniem dla programisty a nie narzędziem dla np. analityka. Cechy techniczne wyrobu. Miara została zdefiniowana jako: Czas, potrzebny do zrealizowana algorytmu wyliczenia WIG Czas, potrzebny do zrealizowania algorytmu akceptacji faktury Różnorodność technologiczna: Jednorodna – wartość 1 - silnik reguł biznesowych jest w całości zrealizowany w jednym środowisku Niejednorodna - wartość 2 - silnik reguł biznesowych jest realizowany w oparciu o zbiór narzędzi – oddzielne serwery, bazy danych, itp. Stopień korelacji między cechami technicznymi. Określa zależność implementacyjną pomiędzy poszczególnymi komponentami i został zdefiniowany następująco: Ścisłe powiązanie – wartość 1 - poszczególne elementy silnika reguł biznesowych nie mają wydzielonych interfejsów Separacja relacji – wartość 2 - poszczególne elementy są komponentami o zdefiniowanych interfejsach. Wymiana elementów przebiega bez inwazyjnie.

Jakość Cecha Bonita JBoss Drools Expert Microsoft Workflow Fundation Wymagania użytkownika Bardzo dobry Średni Dobry Czas, potrzebny do zrealizowana algorytmu wyliczenia WIG 60 min. 30 min. 25 min. Czas, potrzebny do zrealizowania algorytmu akceptacji faktury 45 min. 90 min. Różnorodność technologiczna Niejednorodna Jednorodna Stopień korelacji między cechami technicznymi Separacja relacji Ścisłe powiązanie Ocena 5,98 5,96 4,86 Ocena procentowa 100 % 99 % 82 % Analizując jakość, wykorzystane zostały cechy silników reguł biznesowych w kontekście zbieżności z potencjalnie pożądanymi efektami wdrożenia silnika reguł biznesowych w miejscu tradycyjnie budowanego rozwiązania. Definicji uległy następujące cechy: Wymagania użytkownika. Cecha została zdefiniowana jako miara dostępności i zrozumiałości silnika reguł biznesowych dla ekspertów dziedziny biznesowej budowanego systemu. Określa stopień możliwości implementacji wymagań funkcjonalnych, gdzie: Bardzo dobry Wartość 3 – określa wysoki poziom abstrakcji, umożliwiający łatwą naukę i realizację wymagań bez konieczności konsultacji z ekspertem ds. produkcji oprogramowania. Dobry Wartość 2 – określa wysoki poziom abstrakcji, wymagający jednak konsultacji z ekspertem ds. produkcji oprogramowania. Średni Wartość 1 – określa niski poziom abstrakcji, zadanie implementacyjne wymaga delegowania do konsultanta ds. produkcji oprogramowania. Dla tej miary – silnik reguł biznesowych jest ułatwieniem dla programisty a nie narzędziem dla np. analityka. Cechy techniczne wyrobu. Miara została zdefiniowana jako: Czas, potrzebny do zrealizowana algorytmu wyliczenia WIG Czas, potrzebny do zrealizowania algorytmu akceptacji faktury Różnorodność technologiczna: Jednorodna – wartość 1 - silnik reguł biznesowych jest w całości zrealizowany w jednym środowisku Niejednorodna - wartość 2 - silnik reguł biznesowych jest realizowany w oparciu o zbiór narzędzi – oddzielne serwery, bazy danych, itp. Stopień korelacji między cechami technicznymi. Określa zależność implementacyjną pomiędzy poszczególnymi komponentami i został zdefiniowany następująco: Ścisłe powiązanie – wartość 1 - poszczególne elementy silnika reguł biznesowych nie mają wydzielonych interfejsów Separacja relacji – wartość 2 - poszczególne elementy są komponentami o zdefiniowanych interfejsach. Wymiana elementów przebiega bez inwazyjnie.

Kompletność Cecha Bonita JBoss Drools Expert Microsoft Workflow Fundation Posiadanie wsparcia technicznego tak Posiadanie całościowego rozwiązania nie tak. Posiadanie interfejsów migracji danych Obsługa różnorodnych przepływów Ocena 3 2 4 Ocena procentowa 75 % 50 % 100 % Określenie kompletności silników reguł biznesowych oparta została na spełnieniu następujących warunków:

Rozwojowość Cecha Bonita JBoss Drools Expert Microsoft Workflow Fundation Posiadanie interfejsów, umożliwiających dopasowanie tak Elastyczność architektury nie tak. Ocena 3 2 4 Ocena procentowa 75 % 50 % 100 % Określenie kompletności silników reguł biznesowych oparta została na spełnieniu następujących warunków:

Różnorodność Cecha Bonita JBoss Drools Expert Microsoft Workflow Fundation Dostępny dla wielu platform tak nie Obsługa wielu standardów Komunikacja oparta na różnorodnych protokołach Ocena 2 Ocena procentowa 100 % Określenie kompletności silników reguł biznesowych oparta została na spełnieniu następujących warunków:

Synergia Zastosowanie takiego rozwiązania zapewnia łatwość zrozumienia istniejącego rozwiązania, co stanowi kluczowy element dzisiejszego procesu wytwórczego systemów informatycznych. Budowane systemy informatyczne muszą uwzględniać zachowania istniejących systemów. Narzędzie, które wspiera zrozumienie oraz wizualizuje procesy, stanowi często kluczowy element podczas procesu inżynierii odwrotnej. Analizując użyteczność silników reguł biznesowych nasuwa się wniosek, że stosowanie takiego rozwiązania w dużej mierze zapewnia łatwość zrozumienia istniejącego rozwiązania, co stanowi kluczowy element dzisiejszego procesu wytwórczego systemów informatycznych. Z uwagi na wszechobecność przetwarzania komputerowego w dowolnej domenie biznesowej, budowane systemy informatyczne muszą uwzględniać zachowania istniejących systemów. Narzędzie, które wspiera zrozumienie oraz wizualizuje procesy, stanowi często kluczowy element podczas procesu inżynierii odwrotnej.

Podsumowanie Wnioski na podstawie analizy silników reguł biznesowych pozwalają w pełni dowodzą słuszności hipotezy roboczej: „Użycie środowiska reguł biznesowych do implementacji logiki biznesowej ułatwia konserwację i modyfikację w systemach informatycznych” w tezę. Silniki reguł biznesowych są stosunkowo młodym rozwiązaniem, np. Microsoft Workflow Fundation został zaprezentowany w 2006 roku. Mimo młodego wieku – zdobyły one uznanie w środowisku biznesowym, ze względu na zapewnienie płaszczyzny porozumienia między ekspertami domeny biznesowej, analitykami i osobami zaangażowanymi w proces wytwórczy oraz z wytwórcami oprogramowania, w szczególności programistami. Oddzielenie tego, co ma być zaprogramowane od sposobu oprogramowania oraz komponentowo – antropomorficzne podejście do poszczególnych modułów budowanego systemu nie jest nowym postulatem, jednakże środowisko silników reguł biznesowych, chociażby ze względu na omawiane cechy w pełni potwierdza hipotezę roboczą, że użycie środowiska reguł biznesowych do implementacji logiki biznesowej ułatwia konserwację i modyfikację w systemach informatycznych.

Dziękuję za uwagę! 72

PRZEPRASZAMY ZA USTERKI 1 1.

Podobne prezentacje

Prezentacja na temat: "PRZEPRASZAMY ZA USTERKI 1 1."— Zapis prezentacji:

Podobne prezentacje

О projekcie

Zwrotny adres

Wejść

Zaloguj się poprzez sieć społeczną:

PRZEPRASZAMY ZA USTERKI 1 1.

Podobne prezentacje

Prezentacja na temat: "PRZEPRASZAMY ZA USTERKI 1 1."— Zapis prezentacji:

Podobne prezentacje

О projekcie

Zwrotny adres