}w !"#$%&'()+,-./012345
M ASARYKOVA UNIVERZITA FAKULTA INFORMATIKY
Funkˇcní testování CEP aplikací D IPLOMOVÁ PRÁCE
Bc. David Ševˇcík
Brno, podzim 2011
Prohlášení Prohlašuji, že tato diplomová práce je mým puvodním ˚ autorským dílem, které jsem vypracoval samostatnˇe. Všechny zdroje, prameny a literaturu, které jsem pˇri vypracování používal nebo z nich cˇ erpal, v práci rˇ ádnˇe cituji s uvedením úplného odkazu na pˇríslušný zdroj.
Bc. David Ševˇcík
Vedoucí práce: Mgr. Michal Oškera ii
Podˇekování Dˇekuji vedoucímu diplomové práce Mgr. Michalu Oškerovi za cenné rady, pˇripomínky a metodické vedení práce. Dále dˇekuji všem spolupracovníkum ˚ z Mycroft Mind, a.s., bez jejichž praktických zkušeností s vývojem CEP aplikací by tato diplomová práce nemohla vzniknout. V neposlední rˇ adˇe dˇekuji svým rodiˇcum ˚ a pˇrátelum ˚ za morální i finanˇcní podporu pˇri studiu.
iii
Shrnutí Diplomová práce poskytuje v úvodních kapitolách pˇrehled o problematice zpracování komplexních událostí (angl. Complex Event Processing – zkrácenˇe CEP). Popsány jsou základní principy CEP, jeho historický vývoj, obecná architektura a životním cyklus CEP aplikace. Následnˇe je analyzována problematika funkˇcního testování CEP aplikace a popsány úrovnˇe funkˇcního testování v kontextu jejího životního cyklu. Diplomová práce se pˇritom zamˇerˇ uje na specifika testování CEP aplikací, které jej odlišují od testování obecných aplikací. Na základˇe analýzy je vybudována metodika integraˇcního testování sítˇe pro zpracování událostí (angl. Event Processing Network – zkrácenˇe EPN), která je systematickým návodem pro testování business logiky CEP aplikace. Vzhledem k rychlému vývoji CEP platforem ruzných ˚ dodavatelu˚ není vázána na konkrétní nástroje nebo jazyky pro definici EPN a implementaci testu. ˚ Doplnuje ˇ ji tedy kapitola zabývající se pˇrípravou testu˚ v nástroji CloverETL. Použitelnost metodiky i nastroje CloverETL pˇri integraˇcním testování EPN je demonstrována na pˇríkladu testování reálné aplikace Adjustment Monitor.
iv
Klíˇcová slova zpracování komplexních událostí, complex event processing, CEP, event processing network, EPN, EP agent, testování softwaru, software testing, jednotkové testování, integraˇcní testování, unit testing, integration testing, data driven testing, CloverETL
v
Obsah 1
2
3
4
Úvod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.1 Co je to CEP . . . . . . . . . . . . . . . . . . . . . . . . . 1.2 Pˇríklady použití CEP . . . . . . . . . . . . . . . . . . . . 1.2.1 Dohledování rozsáhlých sítí . . . . . . . . . . . . Dohledování poˇcítaˇcové sítˇe . . . . . . . . . . . Dohledování distribuˇcní sítˇe elektrické energie 1.2.2 Dohledování složitých business procesu˚ . . . . . Dohledování sítˇe cˇ erpacích stanic . . . . . . . . Odhalování pojistných podvodu˚ . . . . . . . . . 1.2.3 Algoritmické obchodování . . . . . . . . . . . . 1.3 Verifikace a validace CEP aplikací . . . . . . . . . . . . . 1.3.1 Souˇcasná praxe . . . . . . . . . . . . . . . . . . . 1.4 Cíle diplomové práce . . . . . . . . . . . . . . . . . . . . 1.5 Logická struktura diplomové práce . . . . . . . . . . . . 1.6 Použité konvence . . . . . . . . . . . . . . . . . . . . . . 1.6.1 Názvosloví . . . . . . . . . . . . . . . . . . . . . 1.6.2 Grafiké notace . . . . . . . . . . . . . . . . . . . . CEP a jeho okolí . . . . . . . . . . . . . . . . . . . . . . . . . 2.1 Historický vývoj . . . . . . . . . . . . . . . . . . . . . . . 2.2 CEP, SEP, EDA a SOA . . . . . . . . . . . . . . . . . . . . Architektura CEP . . . . . . . . . . . . . . . . . . . . . . . . . 3.1 Struktura EPN . . . . . . . . . . . . . . . . . . . . . . . . 3.2 Rozdˇelení událostí . . . . . . . . . . . . . . . . . . . . . 3.3 Implementace CEP . . . . . . . . . . . . . . . . . . . . . Životní cyklus CEP aplikace . . . . . . . . . . . . . . . . . . 4.1 Cyklické paradigma . . . . . . . . . . . . . . . . . . . . 4.2 Definice strategie CEP aplikace . . . . . . . . . . . . . . 4.2.1 Vstupní analýza problémové domény . . . . . . Analýza workflow . . . . . . . . . . . . . . . . . Analýza aplikaˇcní vrstvy . . . . . . . . . . . . . Analýza datové vrstvy . . . . . . . . . . . . . . Formulace hypotézy . . . . . . . . . . . . . . . . 4.2.2 Formulace pˇrínosu˚ a cílu˚ . . . . . . . . . . . . . 4.3 Vývoj CEP aplikace . . . . . . . . . . . . . . . . . . . . . 4.4 Provoz CEP aplikace . . . . . . . . . . . . . . . . . . . .
4 4 6 6 6 6 7 7 7 7 8 9 10 10 11 11 12 13 13 14 16 16 18 19 20 20 21 22 23 23 23 23 24 24 24 1
5
6
4.5 Ladˇení CEP aplikace . . . . . . . . . . . . . . . . . . . 4.6 Redefinice strategie CEP aplikace . . . . . . . . . . . . Úrovnˇe funkˇcního testování CEP aplikace . . . . . . . . . 5.1 Testování proveditelnosti CEP aplikace . . . . . . . . 5.2 Vývojové testování CEP aplikace . . . . . . . . . . . . 5.2.1 Testování EP agenta . . . . . . . . . . . . . . . 5.2.2 Integraˇcního testování EPN . . . . . . . . . . . 5.2.3 Systémové testování CEP aplikace . . . . . . . 5.2.4 Akceptaˇcní testování CEP aplikace . . . . . . . 5.2.5 Pˇríprava vstupu˚ . . . . . . . . . . . . . . . . . . Úmˇelé vstupní události . . . . . . . . . . . . . Vstupní události založené na reálných datech 5.2.6 Kontrola výstupu˚ . . . . . . . . . . . . . . . . . Manuální kontrola . . . . . . . . . . . . . . . . Automatická kontrola . . . . . . . . . . . . . . Adaptabilní kontrola . . . . . . . . . . . . . . 5.3 Pilotní testování CEP aplikace . . . . . . . . . . . . . . 5.4 Regresní testování CEP aplikace . . . . . . . . . . . . 5.5 Shrnutí kapitoly . . . . . . . . . . . . . . . . . . . . . . Metodika integraˇcního testování EPN . . . . . . . . . . . . 6.1 Principy . . . . . . . . . . . . . . . . . . . . . . . . . . 6.2 Role . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.2.1 Tester . . . . . . . . . . . . . . . . . . . . . . . . 6.2.2 Doménový expert . . . . . . . . . . . . . . . . . 6.2.3 Vývojáˇr . . . . . . . . . . . . . . . . . . . . . . 6.3 Vstupy . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.3.1 Dokumentovaná a spustitelná EPN . . . . . . 6.3.2 Podklady pro tvorbu testovacích událostí . . . 6.4 Výstupy . . . . . . . . . . . . . . . . . . . . . . . . . . 6.4.1 Spustitelný test . . . . . . . . . . . . . . . . . . 6.5 Aktivity . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.5.1 Pˇríprava testovacího prostˇredí . . . . . . . . . 6.5.2 Pˇríprava testovacích vstupních událostí . . . . 6.5.3 Testování konkrétního typu události . . . . . . Výbˇer testovaného typu události . . . . . . . . Pˇríprava oˇcekávaných výstupních událostí . . Implementace testu . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
25 25 26 26 28 29 29 29 30 30 30 31 31 32 32 32 33 33 34 35 35 36 36 37 37 37 37 37 38 38 38 38 39 40 40 42 42 2
Provedení a vyhodnocení testu . . . . . . . . . . Známá omezení metodiky . . . . . . . . . . . . . . . . . Kombinace integraˇcního testování EPN s testováním EP agentu˚ . . . . . . . . . . . . . . . . . . . . . . . . . . 7 Testování EPN pomocí CloverETL . . . . . . . . . . . . . . . 7.1 Testovací webová služba . . . . . . . . . . . . . . . . . . 7.2 Testovací grafy . . . . . . . . . . . . . . . . . . . . . . . . 7.2.1 Graf TestSuite . . . . . . . . . . . . . . . . . . . . 7.2.2 Graf GeneralEventTest . . . . . . . . . . . . . . . 7.3 Jiné nástroje pro implemetaci testu˚ . . . . . . . . . . . . 8 Pˇredstavení aplikace Adjustment Monitor . . . . . . . . . . 8.1 Charakter aplikace . . . . . . . . . . . . . . . . . . . . . 8.2 Struktura EPN . . . . . . . . . . . . . . . . . . . . . . . . 8.3 Použité technologie . . . . . . . . . . . . . . . . . . . . . 9 Integraˇcní testování aplikace Adjustment Monitor . . . . . 9.1 Pˇríprava testovacího prostˇredí . . . . . . . . . . . . . . . 9.2 Pˇríprava testovacích dat . . . . . . . . . . . . . . . . . . 9.3 Testování konkrétní události . . . . . . . . . . . . . . . . 9.3.1 Výbˇer události PreparationStartEvent . . . . . . 9.3.2 Pˇriprava testu PreparationStartEvent . . . . . . 9.3.3 Provedení a vyhodnocení testu PreparationStartEvent . . . . . . . . . . . . . . . . . . . . . . . . 9.3.4 Výbˇer události AlertEvent . . . . . . . . . . . . . 9.3.5 Pˇriprava testu AlertEvent . . . . . . . . . . . . . 9.3.6 Provedení a vyhodnocení testu AlertEvent . . . 9.4 Využití sady testu˚ pro regresní testování . . . . . . . . . 10 Závˇer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.1 Další rozvoj . . . . . . . . . . . . . . . . . . . . . . . . . 6.6 6.7
42 44 44 46 46 49 49 52 53 54 54 54 57 58 58 58 59 59 60 60 60 61 61 62 63 63
3
1 Úvod V dnešním rozvinutém svˇetˇe již dávno není problém nedostatek informací, právˇe naopak. Informací je produkováno takové množství, že je tˇežké rozlišit ty duležité ˚ od bezcenných. Informace se navíc staly nejvˇetším aktivem pro státy, organizace i jednotlivce. Správné informace na správném místˇe ve správný cˇ as mohou zahranovat ˇ lidské životy, pˇrispívat k rozvoji spoleˇcnosti a vytváˇret skvˇelé obchodní pˇríležitosti. Aplikaˇcní rˇ ešení, postavené na principech zpracování komplexních událostí (CEP), se snaží toto smˇerˇ ování podpoˇrit. To je také duvod ˚ vzniku souboru diplomových prací, které mají za úkol zpopularizovat tento inovativní pˇrístup a obohatit již existující nástroje o metodiky vývoje a nasazení CEP aplikací. Tato diplomová práce se zamˇerˇ uje na problematiku ovˇerˇ ování správné funkˇcnosti CEP aplikací a staví na praktických zkušenostech z vývoje a testování CEP aplikací ve spoleˇcnosti Mycroft Mind, a.s.
1.1
Co je to CEP
CEP je zkratkou pro complex event processing, do cˇ eštiny pˇrekládané jako zpracování komplexních událostí. Oznaˇcuje pˇrístup ke zpracování proudu˚ událostí v reálném cˇ ase s využitím operací jako filtrování, korelace, detekce vzoru˚ a závislostí. Úˇcelem tohoto zpracování je poskytnutí kontinuálního vhledu do problémové domény, rozpoznávání hrozeb a pˇríležitostí. Primární využití nachází tedy v ruz˚ ných formách operativního rˇ ízení. Pro snadnˇejší vysvˇetlení pˇrínosu CEP aplikací bylo vyvinuto schéma tzv. CEPyramidy. [20], zobrazené na obrázku 1.1. Zespodu vstupují do CEPyramidy události pocházející z prostˇredí, ve kterém je CEP aplikace nasazena a následnˇe protékají systémy zpracování událostí znázornˇenými modrou podstavou pyramidy. Tyto systémy pracují bud’ na úrovni zpracování proudu˚ událostí (angl. Stream Event Processing), nebo na úrovni zpracování komplexních událostí (CEP)1 . Systémy zpracování proudu˚ událostí se svou funkˇcností omezují na filtrování událostí a stojí na nejnižších patrech modré podstavy CE1. Více o úrovních zpracování událostí naleznete v sekci 2.2.
4
1. Ú VOD
Actions
Events and Context information
Obrázek 1.1: CEPyramid - pˇrínos CEP rˇ ešení (pˇrevzato z [20])
Pyramidy. Nad nimy se nacházejí systémy CEP, které umožnují ˇ korelaci událostí a detekci vzoru, ˚ na základˇe kterých jsou generovány nové události s vyšší informaˇcní hodnotou neboli událost komplexní. Nad tˇemito systémy stojí cˇ lovˇek, který na základˇe jejich výstupu˚ provede vlastní úsudek (zelený vrchol pyramidy) a vykoná pˇríslušnou akci. Obecným cílem CEP rˇ ešení, je posouvat cˇ lovˇeka v této pyramidˇe smˇerem nahoru. To se dˇeje pomocí kodifikování myšlenkových pochodu˚ cˇ lovˇeka pˇri rˇ ešení situace (tzv. mentální CEP) do podoby komponent systému zpracování událostí. Tento proces je na schématu znázornˇen pomocí šipky pˇresouvající patra nad hlavou cˇ lovˇeka pod nˇej. 5
1. Ú VOD
1.2
Pˇríklady použití CEP
Pro získání lepší pˇredstavy o možnostech nasazení CEP technologií v ruzných ˚ doménách následuje nˇekolik pˇríkladu˚ konkrétních CEP aplikací. Obor rˇ ešených problému mužeme ˚ obecnˇe rozdˇelit na dohledování rozsáhlých sítí a dohledování složitých business procesu. ˚ Samostatnou kapitolu poté tvoˇrí použití CEP pˇri algoritmickém obchodování.
1.2.1 Dohledování rozsáhlých sítí Dohledování poˇcítaˇcové sítˇe Bezpeˇcnost poˇcítaˇcových sítích je se zvyšujícím se objemem a duvˇ ˚ erností dat stále narustajícím ˚ problémem. Na možné hrozby je nutno reagovat okamžitˇe. CEP aplikace na základˇe nauˇcených charakteristik bˇežného sít’ového provozu vyhledává odchylky a možná ohrožení v aktuálním provozu na síti. Tyto odchylky jsou kontinuálnˇe vyhodnocovány a v pˇrípadˇe pˇrekroˇcení limitních hodnot je zasláno upozornˇení správcum ˚ sítˇe prostˇrednictvím emailu nebo SMS.
Dohledování distribuˇcní sítˇe elektrické energie Provozovatel lokální distribuˇcní sítˇe elektrické energie zabezpeˇcuje dodávku energie svým zákazníkum ˚ na základˇe smluv obsahující objem energie, které se zákazníci zavazují odebrat. Pokud jsou reálné odbˇery odlišné od nasmlouvaných, je zákazník nucen zaplatit sankci. CEP aplikace v reálném cˇ ase vyhodnocuje aktuální odbˇery zákazníku˚ a porovnává je s nasmlouvanými objemy odbˇeru. ˚ Pˇred zavedením CEP se tuto informaci zákazník dozvˇedˇel až na konci mˇesíce. Nyní muže ˚ prubˇ ˚ eh odbˇeru sledovat v reálném cˇ ase a pˇrizpuso˚ bit se této situaci. V delším cˇ asovém horizontu získáváme charakteristiky odbˇeru˚ jednotlivých zákazníku, ˚ které mohou posloužit jako podklady k novým smlouvám. 6
1. Ú VOD 1.2.2 Dohledování složitých business procesu˚ Z oblasti dohledování business procesu uvedeme jako první pˇríklad reálnou aplikaci vyvíjenou v Mycroft Mind, a.s. Druhý pˇríklad je modelový a s menšími obmˇenami se objevuje v literatuˇre zabývající se CEP ([17] a [11]). Dohledování sítˇe cˇ erpacích stanic Distributor pohonných hmot má uzavˇreny smlouvy s majiteli jednotlivých cˇ erpacích stanic, které je zavazují k dodržování licenˇcních podmínek. CEP aplikace hlídá dodržování tˇechto podmínek. Vzájemnˇe pˇrirˇ azuje dodací listy se zmˇenami hladiny paliva v nádrži pˇri nákupu pohonných hmot a vztahy mezi úbytkem paliva v nádrži, stavem registru˚ na obslužných stojanech a vystavenými úˇctenkami pˇri prodeji pohonných hmot. V tomto rˇ etˇezci událostí hledá možné úniky paliva a penˇez nebo naopak doplnování ˇ jiného druhu paliva v rozporu se smlouvou. Odhalování pojistných podvodu˚ Pojišt’ovny se stávají cˇ asto cílem pokusu˚ o neoprávnˇené nároky na náhradu škody. CEP zde slouží k odhalování a reportování podezˇrelých událostí, napˇríklad výskytu pojistné události krátce poté co došlo k uzavˇrení nebo navýšení pojistky. V sofistikovanˇejších pˇrípadech mohou být integrovány i události z jiných zdroju, ˚ jako napˇr. zmˇeny v obchodním rejstˇríku nebo zápis do databáze dlužníku. ˚ 1.2.3 Algoritmické obchodování Specifickým pˇríkladem využití CEP je algoritmické obchodování, které je souˇcasnˇe jedním s prvních oblastí kde se CEP zaˇcal prosazovat. Na základˇe signálu˚ o aktuální cenˇe nabídky a poptávky a objemu obchodu, ˚ které proudí ve velmi krátkých intervalech z burzy, jsou vypoˇcítávány hodnoty ukazatelu˚ pravdˇepodobné výnosnosti obchodu a obchody následnˇe automaticky exekuovány. Reálné výsledky obchodu˚ poté slouží k prubˇ ˚ ežnému zdokonalování výpoˇcetních modelu. ˚ 7
1. Ú VOD
1.3
Verifikace a validace CEP aplikací
Aby mohly být výstupy CEP aplikací použity v praxi, musí mít uživatelé duvˇ ˚ eru v jejich správnost. Ovˇerˇ ování správnosti je provádˇeno verifikací a validací [22]. Verifikace je proces, jehož cílem je ovˇerˇ it, že software vyhovuje zadané specifikaci. Oproti tomu validace zahrnuje také reálné uživatele a ovˇerˇ uje, jestli software vyhovuje jejich požadavkum, ˚ které mohou být mnohem širší a nˇekdy i v protikladu se specifikací. Jinými slovy mužeme ˚ rˇ íci, že verifikace ovˇerˇ uje funkˇcnost aplikace a validace její užiteˇcnost pro koncového uživatele. CEP aplikace mají svá specifika, která ovlivnují ˇ možnosti jejich validace i verifikace. Je to zejména vysoká závislost na prostˇredí, ve kterém jsou nasazeny a na událostech, které toto prostˇredí generuje. CEP aplikace jsou navrhovány na základˇe našich znalostí o chování tohoto prostˇredí v minulosti. Je tedy obtížné zaruˇcit, že bude aplikace podávat korektní výsledky, pokud se v budoucnu charakter prostˇredí výraznˇe zmˇení. Druhým specifikem je velký poˇcet interních stavu, ˚ ve kterých se systém muže ˚ nacházet, a které ovlivnují ˇ výstupy. Pˇríˇcinou je použití speciálních konstruktu˚ jako jsou cˇ asová okna a vzory pro zachycení souslednosti událostí. V dusledku ˚ toho je obtížné identifikovat vstupní hraniˇcní hodnoty (viz definice 1) komponent, ze kterých je software sestaven. Definice 1 Hraniˇcní hodnota (angl. boundary value) je každá vstupní nebo výstupní hodnota, která leží na okraji tˇrídy ekvivalence (viz definice 2) nebo v nejmenší inkrementální vzdálenosti na obˇe strany od tohoto okraje. [3] Pˇri použití takových hodnot je nejvˇetší pravdˇepodobnost nalezení defektu v kódu programu. [22]
Definice 2 Tˇrída ekvivalence (angl. equivalence class nebo equivalence partition) je každá cˇ ást oboru vstupních nebo výstupních hodnot, která by mˇely, na základˇe specifikace, zpusobit ˚ shodné chování komponenty nebo systému. [3]
8
1. Ú VOD 1.3.1 Souˇcasná praxe
Na základˇe dostupných zdroju˚ a autorovy zkušenosti z praxe v Mycroft Mind, a.s. byly identifikovány tˇri pˇrístupy k funkcionálnímu testování CEP aplikací: manuální testování, automatické testování a formální verifikace. Pˇri manuálním testování CEP aplikace je nejprve vybrán vhodný vzorek historických dat. Ty jsou poté použity jako vstupní data pro CEP aplikaci, která je spuštˇena a její výstupy zaznamenány v nˇejaké formˇe logu. Tester musí následnˇe tyto záznamy projít a ovˇerˇ it, zda jsou výstupní události správné. Efektivita tohoto pˇrístupu se oproti automatizovaným metodám snižuje s každým opakováním testu, které stojí vždy stejný cˇ as testera. Automatické testování CEP aplikace tak, jak je doporuˇceno v dokumentaci CEP enginu Esper [10] a také v [26], využívá klasických nástroju˚ pro jednotkové nebo integraˇcní testování jako JUnit a TestNG. Jako vstup se používá malý vzorek umˇele vytvoˇrených dat. Kvuli ˚ obecnosti tˇechto nástroju˚ je nutné napsat pro každý test množství obslužného kódu, který rˇ eší inicializaci CEP aplikace, nahrávání vstupních dat a zachycování dat výstupních. Problémem jak manuálního, tak automatického testování je neexistence metodiky, která by použití tˇechto nástroju˚ dokázala uchopit a nasmˇerovat tak, aby byla systematicky ovˇerˇ ena správnost CEP aplikace jako celku a ne pouze náhodnˇe vybraných cˇ ástí. Zcela odlišným pˇrístupem je formální verifikace [33]. Pokud je tento pˇrístup vhodnˇe použit, poskytuje vysokou duvˇ ˚ eru ve správnost fungování aplikace za všech okolností, nejenom funkˇcnost vybraných cˇ ástí aplikace na omezeném množství vstupních dat. Formální verifikace CEP aplikací je stále ve fázi výzkumu. V dostupných zdrojích ([9] a [8]) je navíc její použíti omezeno na CEP aplikace konstruované pomocí pravidel (angl. rule-based). Nevýhodou je vysoká cˇ asová nároˇcnost, a to nejenom na pˇrípravu verifikaˇcního modelu systému. Vˇetšina vývojáˇru˚ nemá teoretické znalosti nezbytné pro její aplikaci, musíme tedy poˇcítat také s netriviálním cˇ asem nutným na jejich zaškolení. Proto se formální verifikace ekonomicky vyplatí pouze u kritických aplikací, kde by chyba znamenala ohrožení života nebo vysokou finanˇcní ztrátu. 9
1. Ú VOD
1.4
Cíle diplomové práce
Na základˇe zadání diplomové práce a diskuze problému˚ pˇri testování CEP aplikací v sekci 1.3 byly stanoveny následující cíle: 1.
Analyzovat úrovnˇe testování CEP aplikací.
2.
Vyvinout metodiku systematického funkˇcního testování CEP aplikací.
3.
Nalézt nástroje, které vybudovanou metodiku podpoˇrí.
4.
Aplikovat metodiku v praxi s použitím vybraných nástroju. ˚
1.5
Logická struktura diplomové práce
Pˇrehled o logické struktuˇre této diplomové práce podává obrázek 1.5. Kapitoly 1 až 3 poskytnou cˇ tenáˇri nezbytné informace o problematice zpracování komplexních událostí vˇcetnˇe základních principu, ˚ historii a obecné architektuˇre CEP aplikací. Kapitola 4 pˇredstavuje rámec životního cyklu CEP aplikace, ve kterém se všechny úrovnˇe funkˇcního testování odehrávají. Samotné úrovnˇe funkˇcního testování jsou poté analyzovány v kapitole 5, která pokládá základ pro hlubší zkoumání specifických aspektu˚ testování CEP aplikací. Kapitola 6 zužitkovává námˇety pˇredložené v kapitole 5 a buduje metodiku integraˇcního testování EPN (Event Processing Network), která obsahuje business logiku CEP aplikace a je tedy primárním cílem funkˇcního testování. Principiálnˇe je testování provádˇené na základˇe této metodiky integraˇcní, zasahuje ale i do dalších úrovní. Úrovenˇ testování EP agentu˚ je v rámci metodiky využívána pro získání podrobnˇejších informací o chybˇe a automatizované testy EPN, které jsou jejím výstupem, hrají klíˇcovou roli v systémovém a regresním testování CEP aplikace. Metodika integraˇcního testování EPN je nezávislá na technologii použité pro implementaci EPN i na nástroji pro implementaci spustitelných testu. ˚ Kapitola 7 tedy pˇredstavuje vhodný nástroj pro vývoj automatizovaných testu˚ – CloverETL. Kapitola 9 poté demonstruje použití metodiky integraˇcního testování EPN v kombinaci s 10
1. Ú VOD Úvod do CEP (principy, historie, architektura)
Kap. 1, 2, 3
Životní cyklus CEP aplikace
Kap. 4 Testování proveditelnosti
Kap. 5
Testování EP agentů
Integrační testování EPN
Systémové testování CEP apl.
Regresní testování CEP apl.
Akceptační testování CEP apl.
Pilotní testování CEP apl.
Metodika integračního testování EPN
Kap. 6
Nástroj pro testování EPN - CloverETL
Kap. 7
Modelové použití metodiky integračního testování EPN a CloverETL
Kap. 8, 9
Obrázek 1.2: Logická struktura diplomové práce
nástrojem CloverETL na testování reálné aplikace Adjustment Monitor. Nezbytné informace o této aplikaci jsou poskytnuty v rámci kapitoly 8.
1.6
Použité konvence
1.6.1 Názvosloví Použitým referenˇcním zdrojem definujícím pojmy z oblasti CEP je [5]. Kapitoly 6 a 7 rozšiˇrují tento slovník o terminologii používanou pˇri vývoji CEP aplikací v Mycroft Mind, a.s. Pˇrí prvním výskytu tˇechto specifických termínu˚ je vždy uveden jejich význam. Referenˇcním zdrojem pro pojmy z oblasti testování softwaru je [3]. Protože jedinou literaturu na téma CEP v cˇ eštinˇe nebo slovenštinˇe pˇredstavují bakaláˇrské a diplomové práce ([14], [6] a [13]), nejsou cˇ eské pˇreklady termínu˚ ustáleny. Pro zachování srozumitelnosti této diplomové práce široké veˇrejnosti jsou proto používány puvodní ˚ anglické termíny nebo je pˇri prvním výskytu cˇ eského pojmu uvedena anglická alternativa. Kromˇe anglických pojmu˚ z oblasti CEP jsou v textu také použity 11
1. Ú VOD kombinace anglických a cˇ eských termínu, ˚ které jsou v odborné literatuˇre ustálené a jejich pˇreklady by ubraly na srozumitelnosti, napˇr. business logika, nebo enterprise aplikace. 1.6.2 Grafiké notace Pro popis procesu˚ v kapitolách 5 a 6 byla zvolena notace BPMN 2.0 [2]. Duvodem ˚ je jednoznaˇcnost, kterou tato standardizovaná notace pˇrináší.
12
2 CEP a jeho okolí 2.1
Historický vývoj
Koncept událostí a jejich zpracování se v aplikované informatice používá již od 50. let 20. stol.[16] První využití našel v diskrétních simulacích, které umožnují ˇ modelovat chování složitých dynamických systému, ˚ jejichž matematické vyˇcíslení by bylo cˇ asovˇe velmi nároˇcné [31]. V pozdˇejších letech mužeme ˚ rozpoznat událostmi rˇ ízenou komunikaci v principech fungování sít’ových protokolu, ˚ a zárovenˇ v aplikacích pro monitoring a optimalizaci tˇechto sítí. Dalším krokem k pokroˇcilejšímu využití událostí byly aktivní databáze [21]. Jedná se o nadstavbu nad klasickými relaˇcními databázemi, která umožnuje ˇ definici pravidel nad daty a akcí, které budou spuštˇeny pˇri splnˇení tˇechto pravidel. Osmdesátá léta 20. století pˇrinesla potˇrebu integrace již zavedených a cˇ asto složitých firemních aplikací a informaˇcních systému. ˚ Odpovˇedí bylo rˇ ešení zvané middleware [28], které zjednodušuje komunikaci mezi aplikacemi postavených na rozdílných technologiích a odstinuje ˇ je od technických aspektu˚ sít’ové komunikace. Dnešní trend v systémové integraci – koncept Enterprise Service Bus [27] lze pokládat za middleware, který klade nejvyšší nároky na univerzálnost. Tyto historické milníky pˇrispˇely podle [16] k formování konceptu CEP. Pokud se podíváme na souˇcasné CEP aplikace, mužeme ˚ v nich najít aspekty dˇríve zmínˇených rˇ ešení. Stejnˇe jako diskrétní simulace používají architekturu transformaˇcních uzlu˚ 1 propojených kanály, kterými proudí události. Ze sít’ových protokolu˚ CEP rˇ ešení pˇrevzaly koncept abstrakce událostí, kdy se události ve formˇe jednotlivých packetu˚ na transportní vrstvˇe skládají do jedné události pˇrijatého emailu na vyšší – aplikaˇcní vrstvˇe. Spoleˇcným jmenovatelem s aktivními databázemi je univerzální použitelnost nevázaná na konkrétní problémovou doménu, a také prvky jazyka – rozšíˇreného SQL – které se podobají jazykum ˚ používaných v mnohých nynˇejších CEP enginech. A koneˇcnˇe stejnˇe jako middleware jsou CEP platformy pˇrizpu˚ sobeny pro integraci událostí s mnoha ruzných ˚ zdroju. ˚ 1. V kontextu CEP nazývaných event processor, event processing agent nebo také detekˇcní metoda
13
2. CEP
2.2
A JEHO OKOLÍ
CEP, SEP, EDA a SOA
Pozice CEP v kontextu obecných pˇrístupu˚ k návrhu a konstrukce enterprise aplikací je zachyceno na obrázku 2.2. Zámˇernˇe zvolená podoba mráˇcku, ˚ naznaˇcuje jejich neostré hranice, protože definice pocházející od ruzných ˚ autorit se mohou lišit. Tato hierarchie i následující popis vychází z [18] a [19]. Zjednodušenˇe mužeme ˚ rˇ íci, že Service Oriented Architecture (SOA) a Event Driven Architecture (EDA) jsou architektonické styly návrhu a konstrukce IT systému. ˚ Filosofií SOA je konstrukce IT systému ze znovupoužitelných komponent, které jsou sdíleny a využívány napˇríˇc tímto systémem. To vede ke snadnˇejší udržovatelnosti rozsáhlých aplikací a adaptaci na zmˇeny v problémové doménˇe. Puvodní ˚ verze SOA, oznaˇcovaná nyní také jako SOA 1.0, navrhuje jako prostˇredek k dosažení vytyˇceného cíle komunikaˇcní schéma request – response [30]. Pomocí tohoto schématu je rˇ ízena kooperace jednotlivých komponent, které hrají bud’ roli poskytovatele služby nebo konzumenta služby. Komunikace na tomto základˇe je synchronní. Filosofií EDA je konstrukce IT systému z nezávislých komponent, které se svým okolím komunikují prostˇrednictvím pˇrijímání a zasílání zpráv. Používají pˇritom komunikaˇcní schéma publish – subscribe [29], pˇri kterém hrají komponenty roli producenta událostí nebo konzumenta událostí. Konkrétní komponentu pˇritom nezajímá kdo je tímto producentem nebo konzumentem. Jediné, co s ostatními komponentami potˇrebuje sdílet je formát událostí. V rámci EDA mužeme ˚ rozlišit tˇri úrovnˇe zpracování událostí: zpracování jednoduchých událostí (angl. Simple Event Processing – SEP), zpracování proudu˚ událostí (angl. Stream Event Processing) a zpracování komplexních událostí (angl. Complex Event Processing – CEP. V rámci Simple Event Processing dochází pouze k distribuci událostí mezi jednotlivé komponenty EDA. Úrovenˇ Stream Event Processing oznaˇcuje zpracování, pˇri kterém k dochází filtrování událostí, modifikaci atributu˚ událostí a vytváˇrení nových událostí komponentami EDA. Události jsou ale zpracovávány oddˇelenˇe bez vazby na ostatní události v systému. Úrovenˇ CEP obohacuje repertoár funkcí o korelaci událostí na základˇe posloupnosti, cˇ asu a umístˇení. Pomocí tˇechto nástroju˚ mohou být detekovány vzory, na základˇe kterých jsou generovány nové události s vyšší informaˇcní 14
2. CEP
A JEHO OKOLÍ
SOA 2.0 SOA 1.0 (request response)
EDA (publish - subscribe) Complex EP Stream EP Simple EP
Obrázek 2.1: Hierarchie pojmu˚ z oblasti enterprise IT rˇ ešení
hodnotou neboli událost komplexní. Koneˇcnˇe SOA 2.0 je architektonický styl návrhu a konstrukce enterprise aplikací, který kombinuje jak pˇrístupy SOA 1.0, tak EDA.
15
3 Architektura CEP Obecnou architekturu CEP aplikace popisuje obrázek 3. Skládá se ze sítˇe pro zpracování události (angl. event processing network – EPN), rˇ ídíci komponenty a obslužných komponent. EPN je klíˇcovou komponentou, která zachycuje business logiku CEP aplikace. Podrobnˇe je rozebrána v následující sekci 3.1. ˇ Rídící komponenta zajišt’uje chod EPN. Stará se o inicializaci, pˇridˇelování prostˇredku, ˚ rˇ ízení cˇ asu atd. Obvykle zapouzdˇruje CEP engine, který se stará o interpretaci pravidel, zapsaných v nˇekterém ze specializovaných jazyku˚ pomocí kterých je EPN definována (viz sekce 3.3). Obslužné komponenty zajišt’ují podporu pro chod EPN. Poskytují pˇripojení k externím zdrojum, ˚ monitorují výkon EPN atd.
3.1
Struktura EPN
Jak již bylo rˇ eˇceno, jádrem CEP aplikace je EPN, která obsahuje business logiku aplikace. EPN staví na principech EDA popsaných v sekci 2.2. Mužeme ˚ si ji pˇredstavit jako sít’ komponent, které si mezi sebou posílají události. Jejich komunikace funguje na principu publish – subscribe (viz sekce 2.2). Sdílí komunikaˇcní protokol a formáty pˇredávaných zpráv, ale nemusí vˇedˇet nic o struktuˇre EPN, do které jsou zapojeny. Obrázek 3.2 vycházející z [11], znázornuje ˇ zapojení jednotlivých komponent v rámci EPN. Jejich popis naleznete v následujících odstavcích. Producent událostí (angl. event producer), jak už název napovídá, produkuje události dovnitˇr EPN. Muže ˚ se jednat o hardwarový senzor spolu s rˇ ídícím softwarem nebo proxy, která vytváˇrí události v pravidelných intervalech na základˇe aktualizovaných záznamu˚ v databázi. Pro zbytek sítˇe ale skuteˇcný puvod ˚ událostí není duležitý. ˚ Konzument událostí (angl. event consumer) naopak události pˇrijímá a na jejich základˇe iniciuje nˇejakou akci. V jednodušším 16
3. A RCHITEKTURA CEP
CEP aplikace
Řídící komponenta (CEP engine) Síť pro zpracování událostí (EPN) Obslužné Obslužné Obslužné komponenty komponenty komponenty
Obrázek 3.1: Schéma CEP aplikace
Producent událostí
Konzument událostí Producent událostí
EP agenti EPN na nižším stupni hierarchie
Konzument událostí
Obrázek 3.2: Schéma sítˇe pro zpracování událostí (EPN)
17
3. A RCHITEKTURA CEP pˇrípadˇe se muže ˚ jednat o zaslání emailu nebo pˇrekreslení grafu v rámci dohledové obrazovky rˇ ídícího procesu. V plnˇe autonomních systémech, jako napˇríklad algoritmické obchodování, muže ˚ jít o požadavek na prodej nebo koupi akcií, který je zaslán do externího systému bez pˇriˇcinˇení lidské obsluhy. Agent zpracovávající události (angl. event processing agent, dále jen EP agent) zapouzdˇruje business logiku CEP aplikace. Jednodušší EP agenti provádˇejí filtrování a transformace událostí, složitˇejší detekují existenci vzoru˚ v proudu událostí a na tomto základˇe emitují události vyšší úrovnˇe (angl. high-level event). Takovéto události se nazývají komplexní a jsou nositeli informace derivované z informací nesenými událostmi na nižší úrovni, které vytvoˇrili seskupení podle daného vzoru (viz porovnání s CEPyramidou v sekci 1.1). Kanály transportují události produkované jedním EP agentem na vstup jiného EP agenta (na obrázku 3.1 jsou to linky spojující EP agenty). Duležitým ˚ aspektem EPN je její hierarchické struktura. EP agenti ale i producenti a konzumenti mohou zapouzdˇrovat celou EPN na nižší úrovni hierarchie (viz obrázek 3.1)1 .
3.2
Rozdˇelení událostí
Událostí probíhající EPN mužeme ˚ rozdˇelit na jednoduché události a komplexní události. Jednoduché události jsou produkovány producenty událostí a nesou neinterpretované informace o aktuálním dˇení v prostˇredí ve kterém je CEP aplikace nasazena. Mužeme ˚ je pojmenovat také jako vstupní události. Komplexní události jsou derivované z jednoduchých prostˇrednictvím EP agentu. ˚ Jinými slovy jde o interpretaci jednoduchých událostí v závislosti na kontextu. Tento kontext je utváˇren pˇredchozími událostmi, které EPN prošli, pˇrípadnˇe informacemi z dalších datových zdroju, ˚ do kterých mohou mít EP agenti pˇrístup. 1. S ruznými ˚ úrovnˇemi abstrakce v rámci EPN pracuje i metodika integraˇcního testování EPN popsaná v kapitole 6.
18
3. A RCHITEKTURA CEP Ilustrováno pomocí CEPyramidy (viz obrázek 1.1) jsou jednoduché události ty, které vstupují do CEPyramidy zespodu, komplexní události jsou potom ty, které se nacházejí v cˇ ásti pod siluetou cˇ lovˇeka. Komplexní události mužeme ˚ z pohledu jejich toku pˇres EPN dále rozdˇelit na interní události a výstupní události. Výstupní události jsou ty, které jsou konzumovány konzumenty událostí. Interní události jsou všechny zbývající, tj. ty které proudí kanály mezi EP agenty. Události výstupní se nazývají také situace [11].
3.3
Implementace CEP
ˇ Rídící a obslužné komponenty (viz obrázek 3) jsou obvykle implementovány pomocí standardních programovacích jazyku˚ (Java, C#) a frameworku˚ pro vývoj enterprise aplikací. EPN muže ˚ být také implementována pomocí tˇechto programovacích jazyku˚ a frameworku. ˚ V souˇcasnosti ale na trhu existuje mnoho CEP enginu˚ [12], které umožnují ˇ zpracování událostí rˇ ídit pomocí specializovaných jazyku. ˚ V takových jazycích je možno naprogramovat pravidla pro zpracování událostí v rámci EPN jednodušeji a pˇrímoˇcaˇreji. Šetˇrí tím pádem cˇ as nutný na implementaci a snižují potenciál vzniku chyb. Jsou ve vˇetšinˇe enginu˚ interpretovány za bˇehu, takže umožnují ˇ snadnou úpravu pravidel v nasazené aplikaci bez nutnosti jejího kompilování. Tím odpovídají na dynamickou povahu rˇ ešených problému˚ s cˇ asto se mˇenícími požadavky na zpracování. Pojem CEP platforma oznaˇcuje rozšíˇrení samotného enginu o další komponenty a vývojové nástroje usnadnující ˇ vývoj, testování a integraci do existující IT infrastruktury.
19
4 Životní cyklus CEP aplikace Tato kapitola vznikla z potˇreby zasadit funkcionální testování CEP aplikací do kontextu jejich životního cyklu. Podrobnˇe se životním cyklem CEP aplikací zabývá [13]. Pro tuto diplomovou práci byl ale zvolen obecnˇejší pˇrístup. Uvedený popis životního cyklu vychází z cyklického paradigmatu [23], které poskytuje vysokoúrovnový ˇ pohled na životní fáze IT systému. Principy v nˇem kodifikované lze promítnout na konkrétní metodiky inkrementálního vývoje softwaru jako RUP, SCRUM atd. Aplikaci cyklického paradigmatu na životní cyklus CEP aplikace zachycuje obrázek 4.1.
4.1
Cyklické paradigma
Cyklické paradigma adresuje problém tvorby a kontinuálního zdokonalování informaˇcního systému v komplexním prostˇredí, které se navíc v prubˇ ˚ ehu cˇ asu mˇení. Tento popis plnˇe vystihuje vývoj CEP aplikace. Po jejím nasazení jsou cˇ asto rozkryty nové úrovnˇe problému, které ale zatím CEP aplikace neˇreší, a proto je nutné ji modifikovat. Tento proces zdokonalování nemá jasnˇe daný konec, protože i kdyby byla CEP aplikace dokonale odladˇená pro danou problémovou doménu, nikdy nejsme schopni zaruˇcit, že nedojde ke zmˇenám v doménˇe samotné, at’ už z organizaˇcních, legislativních nebo jiných du˚ vodu. ˚ Pˇri pohledu na obrázek 4.1 mužeme ˚ rozlišit dva okruhy. Pˇri zahájení životního cyklu je definována strategie CEP aplikace, podle které je následnˇe CEP aplikace vyvinuta a nasazena do provozu. V rámci vnitˇrního cyklu dochází k ladˇení CEP aplikace tak, aby se pˇrizpusobila ˚ drobným zmˇenám prostˇredí, se kterými bylo poˇcítáno pˇri tvorbˇe strategie. Pokud ale dojde k výraznému posunu celé problémové domény, je nutné vystoupit do vnˇejšího okruhu, redefinovat zvolenou strategii a na základˇe ní provést zmˇenu CEP aplikace. Cyklické paradigma je spjato s principem MENTION – USE [23]. Tento princip nám pomáhá vyjasnit vztah, který v dané fázi k CEP aplikace zaujímáme. Jak je ukázáno na obrázku 4.1, fáze Definice strategie CEP aplikace, Vývoj CEP aplikace, Ladˇení CEP aplikace a 20
APLIKACE
Provoz CEP aplikace
USE
Ladění CEP aplikace
Vývoj CEP aplikace
MENTION
Definice strategie CEP aplikace
Redefinice strategie CEP aplikace
MENTION
MENTION
MENTION
4. Ž IVOTNÍ CYKLUS CEP
Obrázek 4.1: Životní cyklus EPN
Redefinice strategie CEP aplikace, jsou typu MENTION, protože bˇehem nich EPN zminujeme ˇ (analyzujeme, modelujeme, diskutujeme o ní, atd.). Fáze Provoz CEP aplikace je typu USE, protože je bˇehem ní CEP aplikace používána a v ideálním pˇrípadˇe pˇrináší pˇrínos zákazníkovi. Stˇrídání fází MENTION a USE je nutností pro kontinuální zlepšování aplikace.
Následuje podrobnˇejší popis jednotlivých fází. Pro zachování pˇrehlednosti jsou zámˇernˇe vynechány úrovnˇe testování, které jsou s jednotlivými fázemi spjaty. Tím se podrobnˇe zabývá kapitola 5.
4.2
Definice strategie CEP aplikace
Strategie udává smˇer pro následný vývoj CEP aplikace. Definice strategie se skládá ze dvou souboru˚ cˇ inností, které se navzájem podporují: vstupní analýza problémové domény a formulace pˇrínosu˚ 21
4. Ž IVOTNÍ CYKLUS CEP
APLIKACE
Obrázek 4.2: Analýza problémové domény pro nasazení CEP
a cílu. ˚ Analýza problémové domény nám poskytne nezbytné znalosti pro formulaci pˇrínosu˚ a cílu. ˚ Naopak jasnˇeji definované pˇrínosy a cíle smˇerˇ ují analýzu a vedou nás k dukladnˇ ˚ ejšímu rozkrytí konkrétních oblastí v problémové doménˇe. Bˇehem fáze definice strategie EPN tedy mezi tˇemito dvˇema kroky opakovanˇe pˇrepínáme. 4.2.1 Vstupní analýza problémové domény Cílem tohoto kroku je vymezit a poté pochopit problémovou doménu, ve které má být CEP aplikace nasazena. K tomu je nutné porozumˇet procesum ˚ ve firmˇe zákazníka, IT infrastruktuˇre, která je podporuje a datum ˚ produkovaných touto infrastrukturou. Produkovaná data pˇritom závisí na událostech, které nastaly bˇehem vykonávání procesu. Rozdˇelení na tyto tˇri vrstvy nám usnadní orientaci v problému a vede nás v postupném budování hypotézy o neexplicitních vazbách (viz obrázek 4.2.1). Protože závˇery analýzy mají podstatný dopad na návrh testu, ˚ rozebereme jednotlivé vrstvy v následujících odstavcích podrobnˇeji. 22
4. Ž IVOTNÍ CYKLUS CEP
APLIKACE
Analýza workflow Cílem analýzy workflow je získání znalosti o pracovních postupech, rolích, které je vykonávají a produktech, které jsou prostˇrednictvím nich vytváˇreny. Vykonáváme ji, abychom zjistili možné fyzické pˇrícˇ iny pro vznik elektronických reprezentací událostí v aplikaˇcní vrstvˇe. Ale také naopak – jak události produkované aplikaˇcní vrstvou ovlivnují ˇ vykonávání procesu. Analýza aplikaˇcní vrstvy Analýza aplikaˇcní vrstvy má za cíl zmapovat architekturu hardwarových a softwarových prvku, ˚ které jsou zapojeny do firemního procesu. Pˇredmˇetem analýzy jsou také zpusoby ˚ mapování událostí v reálném svˇetˇe na reprezentaci událostí v aplikaˇcní vrstvˇe a dále mapování na reprezentaci událostí v datové vrstvˇe. Analýza datové vrstvy Úˇcelem analýzy datové vrstvy je pochopit strukturu a obsah dat produkovaných a konzumovaných v rámci problémové domény. Nutnou podmínku jsou dostupná historická data napˇr. v databázi, která jsou evidencí výskytu událostí v minulosti. V rámci analýzy se k rˇ ešení problému snažíme pˇriblížit pomocí statistických výpoˇctu˚ a ruˇcˇ ního vyhledávání souvislostí v omezeném výseku dat. Cím je analyzovaný úsek kratší, tím se snižuje pravdˇepodobnost platnosti výsledku˚ analýzy v cˇ asovˇe delším úseku a v dusledku ˚ toho i dosažení cílu˚ CEP aplikace. Formulace hypotézy Hypotézou je zde myšleno tvrzení o neexplicitních závislostech mezi jednotlivými prvky domény vybudované na základˇe pˇredchozích analýz. Hypotézou je nazýváno proto, že již z podstaty problému˚ na jejichž rˇ ešení se CEP nasazuje vyplývá, že obvykle nejdou rˇ ešit právˇe bez aplikace CEP technoligií. Proto mužeme ˚ v této fázi pouze pˇredpokládat že definovaná strategie je proveditelná. Hypotéza musí být formulována tak, že její platnost podminuje ˇ naplnitelnost cílu˚ CEP aplikace definovaných v následujícím kroku. 23
4. Ž IVOTNÍ CYKLUS CEP
APLIKACE
Míra formálnosti hypotézy a dukladnost ˚ jejího ovˇerˇ ování (viz oddíl 5.1) záleží na složitosti problémové domény a kritiˇcnosti výstupu˚ plánované CEP aplikace pro danou problémovou doménu. 4.2.2 Formulace pˇrínosu˚ a cílu˚ Na základˇe požadavku˚ zákazníka a znalosti domény získané bˇehem fáze analýzy formulujeme pˇrínosy a cíle CEP aplikace. V praxi se ukazuje, že zákazníci mají obvykle pouze mlhavou pˇredstavu o pˇrínosech, kterých by chtˇeli díky nasazení CEP aplikace dosáhnout. Na tvurcích ˚ samotných tedy leží úkol dovést zákazníka k pˇresné formulaci pˇrínosu˚ a z nich odvozených cílu˚ projektu. Pro ilustraci souˇcasného a požadovaného cílového stavu je vhodné využít CEPyramidu (viz sekce 1.1).
4.3
Vývoj CEP aplikace
Na základˇe zvolené strategie je navržena, implementována a otestována samotna CEP aplikace. Obecný proces vývoje je zachycen na obrázku 5.2. Pˇrístupem k návrhu EPN se zabývá diplomová práce [6]. Konkrétní zpusob ˚ implementace je ovlivnˇen možnostmi CEP enginu a jeho programovacím jazykem. Pˇríklady vývoje EPN v jazyce EPL za použití CEP enginu Esper mužete ˚ nalézt v diplomové práci [14].
4.4
Provoz CEP aplikace
Provozem je myšlena fáze, kdy je CEP aplikace nasazena v rámci IT infrastruktury zákazníka a napojena na zdroje reálných událostí. Mužeme ˚ jej rozdˇelit na pilotní provoz a produkˇcní provoz. V rámci pilotního provozu je provádˇeno pilotní testování (viz sekce 5.3). Pilotní provoz se od produkˇcního provozu liší také dopadem výstupu˚ na rozhodování zákazníka. Pokud jsou na výsledky zpracování EPN navázány automatické akce jiných systému, je obvykle v pilotním provozu vyžadován dohled experta nad takovým procesem. Souˇcástí provozu je v praxi obvyklý monitoring CEP aplikace a vyhodnocování její výkonnosti. Ty tvoˇrí podklady pro následnou 24
4. Ž IVOTNÍ CYKLUS CEP
APLIKACE
fázi ladˇení CEP aplikace (viz sekce 4.5).
4.5
Ladˇení CEP aplikace
Možnosti ladˇení CEP aplikace jsou výraznˇe ovlivnˇeny pˇrístupem k jejímu návrhu a implementace. V jednodušší formˇe je ladˇením CEP aplikace myšlena úprava parametru˚ EPN. Tyto parametry mohly být nastaveny na výchozí hodnoty bˇehem vývoje s tím, že budou upraveny uživateli CEP aplikace na základˇe reálných výstupu˚ v provozu. Druhou variantou je, že se zmˇenily parametry business procesu, jehož je CEP aplikace souˇcástí, a tyto zmˇeny je tˇreba promítnout i do ní. Pˇri návrhu CEP aplikace je nutné s možnými úpravami parametru˚ poˇcítat a poskytnout uživatelské rozhraní, které to umožní. Silnˇejší formou ladˇení CEP aplikace je uživatelský zásah pˇrímo do pravidel definovaných v programovacím jazyce CEP enginu. Tento pˇristup umožní vytváˇret CEP aplikace, které je možno pružnˇe pˇrizpusobit ˚ zmˇenám prostˇredí. Spoleˇcnˇe s tím ale pˇrináší otázku rozsahu funkˇcnosti, kterou poskytovatel CEP rˇ ešení garantuje zákazníkovi. Pˇrí rˇ ešení tohoto problému muže ˚ hrát podstatnou roli regresní testování (viz ??).
4.6
Redefinice strategie CEP aplikace
K nutnosti redefinice strategie dochází v momentˇe, kdy se zmˇení pravidla problémové domény, ve které je CEP aplikace nasazena a na základˇe kterých byla puvodní ˚ strategie vytvoˇrena. Jinými slovy mužeme ˚ rˇ íci, že se zmˇení základy, na kterých byla postavena analýza problémové domény. Konkrétnˇe muže ˚ jít o zmˇeny v organizaci práce, nasazení nové informaˇcního systému a obecnˇe zmˇeny, které vedou k zneplatnˇení hypotézy, jejíž platností jsme správnou funkˇcnost CEP aplikace podmínili (viz sekce 4.2.1). Postup pˇri redefinici strategie CEP aplikace je stejný jako u definice prvotní strategie (viz 4.2). Její dukladnost ˚ je však závislá na rozsahu zmˇen problémové domény.
25
5 Úrovnˇe funkˇcního testování CEP aplikace Tato kapitola navazuje na kapitolu 4 a rozebírá jednotlivé úrovnˇe testování spjaté s fázemi životního cyklu CEP aplikace. Pˇriˇrazení úrovní testu˚ k fázím životního cyklu CEP aplikace je zachyceno na obrázku 5.1. Následuje podrobnˇejší popis jednotlivých úrovní.
5.1
Testování proveditelnosti CEP aplikace
Cílem testování proveditelnosti je ovˇerˇ it, zda je definovaná strategie aplikovatelná v praxi, tj. zda jsou naplnitelné formulované cíle CEP aplikace. Provádí se tedy na konci fáze Definice strategie CEP aplikace. Pokud jsme postupovali podle doporuˇceného sledu kroku˚ v sekci 4.2.1, je dosažitelnost cílu˚ podmínˇena správností formulované hypotézy. Proto je testování proveditelnosti ve své podstatˇe ovˇerˇ ováním správnosti této hypotézy. Pro ovˇerˇ ení hypotézy mužeme ˚ použít metody data miningu nebo metody CEP. Použití metod data miningu jako sumarizace, klasifikace a analýza shluku˚ (angl. clustering) [24] je omezeno na cˇ ásti CEP aplikace, které jsou používají pouze pˇrístupu Stream Event Processing (viz 1.1). Duvodem ˚ je, že zmínˇené metody nepracují explicitnˇe s aspekty cˇ asu a kauzality. Možným pˇrístupem k ovˇerˇ ení proveditelnosti ostatních cˇ ástí CEP aplikace je vytvoˇrení prototypu, který pˇrímo aplikuje konstrukty CEP. Strategie tvorby prototypu se mohou ruznit. ˚ Mužeme ˚ se napˇríklad zamˇerˇ it pouze na kritickou cˇ ást EPN, která je klíˇcová pro funkˇcnost ostatních cˇ ástí a tu v rámci prototypu plnˇe implementujeme. Nebo bude prototyp pokrývat celou EPN, ale zpracování jednotlivých EP agentu˚ bude omezeno pouze na podmnožinu vstupních událostí. Možnosti využití data miningu a prototypování pˇrí vývoji CEP aplikací by si zasloužily hlubší výzkum, který je ale mimo rámec této diplomové práce. Vhodným zdrojem pro úvod do problematiky data minigu je kniha [24]. Pˇrístupem k prototypování systému pracujících v reálném cˇ ase se zabývá cˇ lánek [15]. 26
ˇ 5. Ú ROVN Eˇ FUNK CNÍHO TESTOVÁNÍ CEP
APLIKACE
Definice strat. CEP apl.
Testování provediteslnosti
Redefinice strat. CEP apl.
Vývoj CEP aplikace
Testování provediteslnosti
Vývojové testování
Ladění CEP aplikace
Provoz CEP aplikace
Regresní testování
Pilotní testování
Obrázek 5.1: Pˇriˇrazení úrovní testu˚ k fázím životního cyklu CEP aplikace
27
ˇ 5. Ú ROVN Eˇ FUNK CNÍHO TESTOVÁNÍ CEP
APLIKACE
Vývoj EP agenta
Návrh a implementace EP agenta
Vývoj rámce EPN
Testování EP agenta (Jednotkové testování)
Integrace EP agenta do EPN
Systémové testování CEP aplikace
Akceptační testování CEP aplikace
Integrační testování EPN
Vývoj obslužných komponent
Obrázek 5.2: Proces vývoje CEP aplikace se zamˇerˇ ením na specifické úrovnˇe testování
5.2
Vývojové testování CEP aplikace
Vývojové testování je souhrnné pojmenování pro všechny úrovnˇe testu, ˚ které jsou provádˇeny bˇehem fáze vývoje CEP aplikace. Zaˇrazení jednotlivých úrovní v rámci procesu vývoje CEP aplikace zachycuje obrázek ??. Jejich podrobnˇejší popis je uveden v následujících sekcích. Zámˇernˇe jsou vynechány popisy testování rˇ ídících a obslužných komponent. Ty jsou implementovány ve standardních programovacích jazycích jako Java nebo C# a problematikou testování takovýchto prvku˚ se již zabývá široká škála literatury. Možné pˇrístupy k pˇrípravˇe vstupu˚ a kontrole výstupu˚ jsou popsány v samostatných sekcích, protože mohou být využity napˇríˇc úrovnˇemi vývojového testování. 28
ˇ 5. Ú ROVN Eˇ FUNK CNÍHO TESTOVÁNÍ CEP
APLIKACE
5.2.1 Testování EP agenta Testování EP agenta mužeme ˚ nazvat také obecným pojmem jednotkové testování nebo testování komponent. Pˇredmˇetem ovˇerˇ ování funkˇcnosti je izolovaná komponenta, napˇr. tˇrída v deklarativním programovacím jazyce nebo v pˇrípadˇe EPN jeden EP agent. Implementace a vykonání testu by mˇelo následovat ihned po implementaci funkcionality EP agenta, pˇrípadnˇe mužeme ˚ implementaci testu pˇredrˇ adit implementaci EP agenta podle zásad test-driven development [1]. Zodpovˇednost za otestování EP agenta nese jeho autor, který také udržuje test aktuální v pˇrípadˇe zmˇen EP agenta. Alternativou k tomuto pˇrístupu zdola nahoru je použití jednotkových testu˚ pˇri testování EPN smˇerem shora dolu, ˚ jako je tomu v rámci metodiky integraˇcního testování EPN pˇredstavené v kapitole 6. V tomto pˇrípadˇe je k jednotkovému testování pˇristoupeno až v momentˇe, kdy bylo bˇehem integraˇcního testování naraženo na problém, jehož rozkrytí si žádá vˇetší granularitu testu. ˚ 5.2.2 Integraˇcního testování EPN Integraˇcní testování je provádˇeno za úˇcelem odhalení defektu˚ na rozhraní mezi integrovanými komponentami nebo v procesu komunikace mezi nimi. [3] V pˇrípadˇe integraˇcního testování EPN je objektem testování komunikace mezi jednotlivými EP agenty. Implementace a vykonání integraˇcního testu následuje po implementaci funkˇcnˇe ohraniˇcené cˇ ásti EPN. Zodpovˇednou osobou je v tomto pˇrípadˇe tester, který má rovnˇež na starosti udržování testu aktuálního v pˇrípadˇe zmˇeny EPN. Podrobnˇeji je integraˇcní testování popsáno v rámci metodiky integraˇcního testování EPN v kapitole 6. 5.2.3 Systémové testování CEP aplikace Úˇcelem systémového testování je ovˇerˇ it jestli integrovaný systém naplnuje ˇ specifikované požadavky. [3] Jinými slovy mužeme ˚ rˇ íci, že systémové testování je integraˇcní testování zahrnující celý systém obohacené o testy interakce systému s okolím. Vzhledem k této charakteristice je možné. Systémové testování CEP aplikace zahrnuje jak EPN tak ostatní 29
ˇ 5. Ú ROVN Eˇ FUNK CNÍHO TESTOVÁNÍ CEP
APLIKACE
komponenty (viz kapitola 3). Pro pˇrípravu systémových testu˚ tak mužeme ˚ využit artefaktu˚ vytvoˇrených pˇri aplikaci metodiky integraˇcního testování EPN (viz kapitola 6) jako testovací prostˇredí a sada integraˇcních testu˚ EPN. 5.2.4 Akceptaˇcní testování CEP aplikace Úˇcelem akceptaˇcního testování je zjistit, jestli systém splnuje ˇ akceptaˇcní kriteria. [3]. Tato akceptaˇcní kriteria reflektují požadavky zainteresovaných stran na vyvíjený systém. Jsou definována bud’ pˇrímo entitou, která pˇrebírá hotový systém, nebo dodavatelem CEP aplikace. V druhém pˇrípadˇe ale odpovˇedná entita musí formálnˇe potvrdit jejich správnost. Akceptaˇcní testování CEP aplikací s sebou nepˇrináší žádné specifické aspekty, které by ho odlišovali od úrovnˇe akceptaˇcního testování obecných aplikací. Muže ˚ být provádˇeno manuálnˇe (uživatel interaguje s CEP aplikací prostˇrednictvím uživatelského rozhraní), automaticky nebo kombinací obou pˇrístupu. ˚ Pˇri automatickém akceptaˇcním testování lze rovnˇež využít artefaktu˚ pˇripravených prostˇrednictvím metodiky integraˇcního testování EPN (viz kapitola 6) jako testovací prostˇredí a sada integraˇcních testu. ˚ 5.2.5 Pˇríprava vstupu˚ V rámci jednotlivých fází vývojového testování mužeme ˚ použít dvou ruzných ˚ pˇrístupu˚ k pˇrípravˇe vstupních testovacích událostí. Bud’ vytváˇríme umˇelé vstupní události, nebo vybíráme vhodné testovací události ze souboru historických dat které máme k dispozici. Úmˇelé vstupní události Umˇele vstupní události pˇripravujeme na základˇe identifikovaných hraniˇcních hodnot komponent EPN (viz definice 1). Výsledkem je soubor vstupních událostí s ruznými ˚ kombinacemi hodnot atributu, ˚ které jsou bud’ na okraji definiˇcního oboru pro daný typ atributu, nebo jsou blízko hodnoty, na které je závislá zmˇena nˇejakého vnitˇrního stavu EP agenta, nebo pˇrímo jeho výstup. 30
ˇ 5. Ú ROVN Eˇ FUNK CNÍHO TESTOVÁNÍ CEP
APLIKACE
Úˇcinnost testu˚ pomocí umˇele pˇripravených vstupních událostí ale velmi záleží na schopnosti testera hraniˇcní hodnoty správnˇe identifikovat. Tento pˇrístup k pˇrípravˇe vstupu˚ je proto vhodný u jednotkového testování, kdy testujeme izolovaného EP agenta na nízké úrovni abstrakce (viz sekce 3.1) u kterého je zˇrejmý mechanismus závislosti atributu˚ výstupních událostí na atributech událostí vstupních.
Vstupní události založené na reálných datech Pˇri použití testovacích vstupních událostí vycházejících s reálných historických dat nezáleží pˇríliš na schopnosti testera odhalit správnˇe hraniˇcní hodnoty. Pragmaticky spoléháme na to, že pˇri použití dostateˇcnˇe velkého a rozmanitého vzorku dat, je statisticky pravdˇepodobné, že v nˇem jsou mezní hodnoty zahrnuty. Výhodný je tento pˇrístup v pˇrípadech, kdy nejsou závislosti mezi vstupními a výstupními daty na první pohled zˇrejmé a identifikace všech mezních hodnot by byla cˇ asovˇe nároˇcná. To nastává zejména pˇri integraˇcním a systémovém testování kdy testujeme EP agenta na vyšší úrovní abstrakce (viz sekce 3.1), který v sobˇe zapouzdˇruje EPN složenou opˇet z propojených EP agentu. ˚ Místo hledání mezních pˇrípadu˚ ale musíme pˇri použití historických dat rˇ ešit jiný problém: jak poznat, že jejich vzorek je dostateˇcnˇe velký a rozmanitý. Pˇrístupy k rˇ ešení tohoto problému jsou diskutovány v sekci 6.5.2. Další otevˇrenou otázkou je, jaký pˇrístup zvolit, když chceme systematicky otestovat celou EPN. Na tuto otázku odpovídá metodika integraˇcního testování EPN popsaná v kapitole 6.
5.2.6 Kontrola výstupu˚ Jakmile probˇehne zpracování vybraných vstupních událostí, dostaneme na výstupu události u kterých musíme ovˇerˇ it jejich správnost. Mužeme ˚ rozlišit tˇri pˇrístupy: manuální, automatická a adaptabilní kontrola. 31
ˇ 5. Ú ROVN Eˇ FUNK CNÍHO TESTOVÁNÍ CEP
APLIKACE
Manuální kontrola Manuální kontrola znamená, že s každým spuštˇením testu musí povˇerˇ ená osoba projít události na výstupu a ovˇerˇ it jejich platnost. Tento zpusob ˚ je vhodný pˇri vývojovém testování, kdy si potˇrebujeme pouze rychle ovˇerˇ it provedené zmˇeny v kódu a test neplánujeme v nezmˇenˇené podobˇe znovu opakovat. Pokud bychom tímto zpusobem ˚ testovali stejnou cˇ ást EPN opakovanˇe, bylo by vynaložené úsilí na každé opakování testu pˇribližnˇe stejné.
Automatická kontrola Automatická kontrola je pˇrístup, kdy na základˇe vybraných vstupu˚ odvodíme oˇcekávané výstupy a ty kodifikujeme takovým zpusobem, ˚ abychom porovnávání oˇcekávaných výstupu˚ vuˇ ˚ ci reálným výstupum ˚ mohli opakovanˇe provádˇet automaticky pomocí nástroju˚ jako JUnit nebo TestNG. Pro testování EPN je možné využít i jiných nástroju, ˚ které sníží potˇrebu psaní obslužného kódu. V kapitole 7 je pˇredvedeno použití nástroje CloverETL. Oproti manuálnímu testování je zde nejvˇetší úsilí vynaloženo na zaˇcátku v rámci kodifikace oˇcekávaných výstupu, ˚ pˇri opakovaném spouštˇení je už lidské úsilí minimální. Nevýhodou tohoto pˇrístupu je pevné svázání testu˚ se testovacími vstupními daty. Pokud se rozhodneme vstupní data zmˇenit, jsme nuceni celý test pˇrepsat.
Adaptabilní kontrola Adaptabilní kontrola znamená, že kontrolní mechanismus naprogramujeme takovým zpusobem, ˚ aby nebyl závislý na konkrétních hodnotách vstupních dat. Nekodifikujeme tedy pˇrímo oˇcekávané výstupy, ale tvoˇríme model EPN, který popisuje závislosti vstupních dat na výstupních a následnˇe tento model verifikujeme [33]. Formální verifikace je ale cˇ asovˇe nároˇcná a její použití se ekonomicky vyplatí zejména u kritických CEP aplikace, jejichž testování je specifická úloha pˇresahující rámec této práce. Zdroji diskutujícími použití formální verifikace pro EPN jsou [9] a [8]. 32
ˇ 5. Ú ROVN Eˇ FUNK CNÍHO TESTOVÁNÍ CEP
5.3
APLIKACE
Pilotní testování CEP aplikace
S pilotním testováním se mužeme ˚ setkat rovnˇež pod názvem operativní testování. Je provádˇeno v reálném bˇehovém prostˇredí aplikace za úˇcasti vybrané skupiny uživatelu. ˚ [3] Je to poslední volitelný krok pˇred oficiálním spuštˇením nebo distribucí aplikace. Jeho úˇcelem je odhalit chyby na rozhraní mezi aplikací a reálným bˇehovým prostˇredím, které nebylo možné odhalit v prostˇredí testovacím. Riziko vzniku takových chyb se zvˇetšuje úmˇernˇe s nárustem ˚ komplexnosti bˇehového prostˇredí. Tento problém mužeme ˚ vztáhnout na vˇetšinu CEP aplikací, které musí obvykle komunikovat s nˇekolika informaˇcními systémy od ruzných ˚ dodavatelu˚ používajícími rozdílné komunikaˇcní protokoly. Problémem pilotního testování je obtížnost rˇ ízení bˇehového prostˇredí. Nemužeme ˚ nasimulovat nˇekteré situace, protože nad prostˇredím nemáme plnou kontrolu. Oblast pilotního testování je dosud málo prozkoumaná i co se týˇce obecného softwaru. O tom svˇedˇcí i nedostatek literatury na toto téma.
5.4
Regresní testování CEP aplikace
Pojmem regresní testování se oznaˇcuje opakované provádˇení již vykonaných testu˚ (zpravidla jednotkových, integraˇcních nebo systémových, viz sekce 5.2) za úˇcelem ovˇerˇ ení, že funkcionalita systému nebo jeho cˇ ásti byla nezmˇenˇena. [3] To je potˇrebné pokud provádíme refaktoring za úˇcelem zefektivnˇení a zpˇrehlednˇení kódu, nebo mˇeníme izolovanou cˇ ást systému a chceme ovˇerˇ it, že ostatní cˇ ásti touto zmˇenou nebyly zasaženy. V rámci životního cyklu CEP aplikace najde regresní testování své uplatnˇení zejména ve fázi ladˇení CEP aplikace (viz sekce 4.5). Provádí se po zmˇenˇe parametru˚ nebo pravidel EP agenta za úˇcelem ovˇerˇ ení, že do zbytku EPN nebyla tímto zásahem vnesena chyba. Pro tyto pˇrípady je možné použít sadu integraˇcních testu, ˚ vytvoˇrených na základˇe metodiky integraˇcního testování EPN, popsané v kapitole 6. Testy jsou spuštˇeny v rámci testovacího prostˇredí vytvorˇ eného rovnˇež na základˇe zmínˇené metodiky. Zodpovˇednou za tuto úrovenˇ testování je osoba, která zmˇeny EPN provedla. 33
ˇ 5. Ú ROVN Eˇ FUNK CNÍHO TESTOVÁNÍ CEP
APLIKACE
Kromˇe fáze ladˇení CEP aplikace, muže ˚ být regresní testování využito rovnˇež pˇri rozsáhlejších úpravách CEP aplikace v rámci opakované fáze vývoje (viz sekce 4.3) následující po fázi redefinice stategie (viz sekce 4.6). Pokud se v rámci zmˇen EPN rozhodneme nˇekteré cˇ ásti zachovat, mˇeli bychom použít regresního testování pro ovˇerˇ ení, že funkˇcnost dané cˇ ásti zustala ˚ zachována. V tomto pˇrípadˇe použijeme opakovanˇe již hotové jednotkové testy, neboli testy EP agentu˚ (viz sekce 5.2).
5.5
Shrnutí kapitoly
Tato kapitola poskytla pˇrehled všech identifikovaných úrovní funkˇcního testování CEP aplikací. V rámci rozsahu této práce je nemožné vybudovat metodiku testování funkcionálního testování CEP aplikací, která by zahrnovala všechny zmínˇené úrovnˇe funkcionálního testování. Zárovenˇ by taková metodika byla pˇríliš komplikovaná pro užití v praxi. V dusledku ˚ toho se autor rozhodl zamˇerˇ it na úroven, ˇ kterou nejvíce ovlivnují ˇ specifické vlastnosti CEP a jejíž pˇrístupy lze aplikovat i v dalších úrovních testování. Touto úrovní je integraˇcní testování EPN. EPN je držitelem business logiky CEP aplikace a její správná funkˇcnost je pro funkˇcnost celé CEP aplikace naprosto klícˇ ová.
34
6 Metodika integraˇcního testování EPN Tato kapitola popisuje metodiku pro systematické integraˇcní testování EPN. Byla vyvinuta a otestována v praxi v rámci autorova puso˚ bení ve firmˇe Mycroft Mind, a.s. Uvedený popis je nezávislý na konkrétních technologiích jak pro implementaci CEP aplikace tak pro implementaci testu. ˚ Vhodný nástroj pro implementaci testu˚ – CloverEPL a postup jeho užití je popsán v kapitole 7. Modelovému nasazení metodiky v rámci reálného projektu se vˇenuje kapitola 9. Tato metodika rˇ eší cˇ istˇe testování business logiky CEP aplikace ve formˇe EPN, ostatní komponenty CEP aplikace jako napˇr. databázové konektory a kontrolery detekˇcního procesu jsou obvykle implementovány ve standardních programovacích jazycích jako Java nebo C#, a proto je pro jejich testování vhodnˇejší použít standardní nástroje (JUnit, TestNG atd.) a postupy.
6.1
Principy
Proces integraˇcního testování EPN pomocí této metodiky spoˇcívá v pragmatickém iterativním ovˇerˇ ování správnosti výstupních událostí EP agentu. ˚ Pˇredmˇetem testování jsou výstupní události EP agentu. ˚ V každé iteraci je testovaná sada událostí rozšíˇrena právˇe o jeden typ výstupní události. Pravidla výbˇeru tohoto typu jsou podrobnˇe popsána v rámci sekce 6.5.3. Oˇcekávané výstupní události jsou testerem definovány na základˇe znalosti vstupních událostí celé EPN a výstupních událostí, jejichž správnost byla ovˇerˇ ena v pˇredchozích iteracích. Pragmatický pˇrístup k testování znamená, že metodika nevynucuje pokrytí všech událostí testy, ale snaží se maximalizovat pomˇer cena/výkon (viz sekce 6.5.3). Cenou je v tomto kontextu myšleno množství spotˇrebovaného cˇ asu, výkon vyjadˇruje množství odhalených chyb. Jelikož metodika není vybudována na paradigmatech formální verifikace, neklade si za cíl prokázat správnost aplikace. Jejím cílem je systematizovat a urychlit testování EPN. Proces testování muže ˚ bˇežet paralelnˇe s iterativním vývojovým procesem respektujícím pravidla popsaná v sekci 4.3 nebo samostatnˇe 35
ˇ 6. M ETODIKA INTEGRA CNÍHO TESTOVÁNÍ EPN
po ukonˇcení procesu vývoje. S testováním mužeme ˚ zaˇcít již po první dodávce cˇ ásteˇcnˇe implementované EPN, která ale musí být spustitelná1 . Stavíme na pˇredpokladu, že pˇri iterativním vývoji EPN je tato sít’ budována „po proudu“, smˇerem od vstupních událostí k výstupním událostem EPN, neboli smˇerem z dolních do horních pater CEPyramidy, která je popsaná v sekci 1.1. Metodika byla od zaˇcátku koncipována pro použití s nástroji pro automatizovanou kontrolu výstupních událostí (viz sekce 5.2.6). V dusledku ˚ její obecnosti, ale nic nebrání jejímu použití pro rˇ ízení manuálních testu. ˚ V takovém pˇrípadˇe nebudeme vykonávat aktivitu Implementace testu a ovˇerˇ ování reálných výstupních událostí oproti oˇcekávaných bude tester provádˇet ruˇcnˇe v rámci aktivity Provedení a vyhodnocení testu (viz sekce 6.5.3).
6.2
Role
Do integraˇcního testování EPN jsou zapojeny následují tˇri role. V závislosti na rozsahu aplikace muže ˚ jedna osoba hrát více rolí a naopak jedna role muže ˚ být zastávána více osobami.
6.2.1 Tester Pˇripravuje množinu testovacích vstupních událostí a na jejich základˇe odvozenou množinu oˇcekávaných výstupních událostí. Následnˇe implementuje automaticky proveditelný test, spouští jej a vyhodnocuje jeho výsledky. Musí mít dostateˇcnou znalost problémové domény2 a nástroje, který je pro implementaci testu˚ použit.
1. V rámci procesu vývoje EPN (na obrázku 5.2) zabezbeˇcuje tuto spustitelnost úkol Vývoj rámce EPN, bˇehem kterého je implementován základ rˇ ídící komponenty EPN. Mužeme ˚ ale také v rámci pˇrípravy testovacího prostˇredí pˇripravit testovací driver, který bude funkci rˇ ídící komponenty pro úˇcely testu˚ simulovat (angl. test driver). 2. Ideální je, pokud se pˇrímo podílí na analýze problémové domény tak, jak je popsaná v sekci 4.2.1.
36
ˇ 6. M ETODIKA INTEGRA CNÍHO TESTOVÁNÍ EPN
6.2.2 Doménový expert Má pˇrehled o fungování problémové domény. Je k dispozici testerovi jako poradce pˇri výbˇeru vhodné množiny testovacích dat a pˇri ovˇerˇ ování faktické správnosti oˇcekávaných výstupu. ˚ Ideální je, pokud se jedná o externího nebo interního zákazníka, který bude výslednou aplikaci sám používat. 6.2.3 Vývojáˇr ˇ Primárním úkolem vývojáˇre je pˇríprava testovacího prostˇredí. Casto je v rámci pˇrípravy testovacího prostˇredí nutné zasáhnout do samotné CEP aplikace a implementovat rozhraní, které by umožnoˇ valo kontrolu nad interními událostmi. Musí tedy mít adekvátní znalosti technologií, pomocí kterých je CEP aplikace implementována. Sekundárnˇe muže ˚ být nápomocný testerovi pˇri implementaci automatických testu. ˚
6.3
Vstupy
6.3.1 Dokumentovaná a spustitelná EPN Protože metodika poˇcítá s dynamickým testováním [22] EPN je nutné, aby cˇ ást EPN pˇredaná k integraˇcnímu testování byla spustitelná, tj. aby bylo možné do ní posílat vstupní události a získávat události výstupní. Duležitou ˚ souˇcástí je také dokumentace, která nám umožní porozumˇet fungování EPN a identifikovat kritická místa, na která se pˇri testování zamˇerˇ íme. 6.3.2 Podklady pro tvorbu testovacích událostí V sekci 6.5.2 byly diskutovány možnosti použití testovacích událostí založených na zaznamenaných výstupech reálného informaˇcního systému nebo testovacích událostí umˇele vytvoˇrených. Pro integraˇcní testování je u komplexních EPN (viz definice 4) výhodnˇejší vytvoˇrení testovacích událostí na základˇe zaznamenaných výstupu˚ IS, ze kterého bude EPN získávat vstupní události i v reálném provozu. V pˇrípadech, kdy EPN není komplexní, mužeme ˚ vytvoˇrit umˇelé 37
ˇ 6. M ETODIKA INTEGRA CNÍHO TESTOVÁNÍ EPN
vstupní události (viz sekce 6.5.2).
6.4
Výstupy
6.4.1 Spustitelný test Výstupem každé iterace testování konkrétního typu události (viz obrázek 6.5) je automatizovaný integraˇcní test cˇ ásti EPN. Tento test mu˚ žeme opakovanˇe využít v rámci jiných úrovních testování, zejména pˇri systémovém a regresním testování (viz sekce 5.2).
6.5
Aktivity
Proces testování se skládá ze šesti aktivit: 1.
Pˇríprava testovacího prostˇredí
2.
Pˇríprava testovacích vstupních událostí
3.
Výbˇer testovaného typu události
4.
Pˇríprava oˇcekávaných výstupních událostí
5.
Implementace testu
6.
Provedení a vyhodnocení testu
Za vykonání aktivity Pˇríprava testovacího prostˇredí je zodpovˇedná osoba v roli vývojáˇr. Za všechny ostatní aktivity zodpovídá osoba v roli tester. Pˇrechody mezi aktivitami zachycuje obrázek 6.5. Popis jednotlivých aktivit je uveden v následujících sekcích.
6.5.1 Pˇríprava testovacího prostˇredí V rámci této aktivity je tˇreba pˇripravit prostˇredí, ve kterém bude EPN testována. Zámˇerem je, aby se testovací prostˇredí co nejvíce blížilo prostˇredí, ve kterém bude EPN produkˇcnˇe nasazena, ale zárovenˇ bylo plnˇe kontrolovatelné. V rámci pˇrípravy je obvykle nutné 38
ˇ 6. M ETODIKA INTEGRA CNÍHO TESTOVÁNÍ EPN Testování konkrétního typu události
Spustilená a zdokumentovaná EPN Příprava testovacího prostředí
Výběr testovaného typu události
Příprava očekávaných výstupních událostí
Implementace testu
Příprava testovacích vstupních událostí
Provedení a vyhodnocení testu
Podklady pro tvorbu testovacích událostí
Spustitelný test
Obrázek 6.1: Proces integraˇcního testování EPN
implementovat testovací náhražky (angl. stubs) zatím neexistujících komponent CEP aplikace i externích systému, na které má být EPN napojena. Dále je potˇreba pˇripravit rozhraní, pomocí kterého bude testovací nástroj rˇ ídit proces zpracování událostí, pˇredávat vstupní události a získávat události výstupní. Prubˇ ˚ eh a nároˇcnost této aktivity je výraznˇe ovlivnˇena použitými technologiemi. 6.5.2 Pˇríprava testovacích vstupních událostí Testovací vstupní události vytváˇríme na základˇe vstupních podkladu˚ (viz sekce 6.3.2). Metodika vzhledem k velké ruznorodosti ˚ CEP aplikací nepˇredkládá pˇresný návod, jak testovací události vybrat. Principiálnˇe bychom se mˇeli snažit pokrýt širší spektrum událostí rozˇ prostˇrených jak v cˇ ase, tak prostoru. Casová dimenze vyjadˇruje momenty výskytu událostí. Pod prostorovou dimenzí si mužeme ˚ pˇredstavit jak umístˇení v rámci reálného svˇeta (napˇr. mˇesto ve kterém je umístˇena poboˇcka firmy) tak umístˇení v rámci kyberprostoru (napˇr. kategorie produktu). Vˇetším rozprostˇrením událostí se snažíme bojo39
ˇ 6. M ETODIKA INTEGRA CNÍHO TESTOVÁNÍ EPN
vat proti tzv. paradoxu pesticidu˚ [7]. Tak je popisována situace, kdy nám testy procházejí, ale systém je stále plný „imunních“ defektu, ˚ které nejsou odhaleny kvuli ˚ úzkému zábˇeru testu. ˚ Proti snaze o vytvoˇrení dokonale vyváženého souboru vstupních testovacích událostí jde cˇ as, který máme na testování vyhrazen. Pˇri pˇrípravˇe testovacích událostí tedy musíme volit urˇcitý kompromis. Z duvodu ˚ úspory cˇ asu se také snažíme maximálnˇe využít už pˇripravené sady testovacích vstupních událostí z pˇredchozích bˇehu˚ procesu a modifikovat je podle potˇreby. Na této pˇrípravˇe vstupních testovacích událostí se podílí osoba v roli autora testu a konzultuje výbˇer s osobou v roli doménového experta. 6.5.3 Testování konkrétního typu události Testování konkrétního typu události je cyklický podproces. Jak již bylo rˇ eˇceno v sekci 6.1, pˇredmˇetem testování jsou výstupní události EP agentu. ˚ Události jsou vždy nˇejakého typu, pˇriˇcemž jeden EP agent muže ˚ produkovat události více typu. ˚ V rámci jedné iterace tohoto podprocesu testujeme právˇe jeden typ události produkovaný právˇe jedním EP agentem. Pokud více EP agentu˚ produkuje shodný typ událostí, jsou jejich výstupy testovány v oddˇelených iteracích. Výbˇer testovaného typu události Pˇri výbˇeru testovaného typu události dodržujeme jednoduché pravidlo: vybíráme typ výstupní události EP agenta, do nˇehož vstupují pouze vstupní události EPN nebo interní události, jejichž správnost již byla ovˇerˇ ena pˇredchozími testy. Pˇritom se snažíme testovat vždy výstupní události EP agentu˚ na tak vysoké úrovni abstrakce, kterou dokážeme pomocí jednoho testu uchopit. Pokud to z duvodu ˚ komplexnosti EP agenta (viz definice 4) není možné, zamˇerˇ íme se na vnitˇrní strukturu EP agenta (EPN na nižší úrovni abstrakce viz sekce 3.1). Tento sestup opakujeme, dokud nejsme ve struktuˇre EPN zanoˇreni dostateˇcnˇe hluboko, tj. komplexita testu je logicky uchopitelná a implementovatelná technologií použitou pro testování. Poˇradí typu˚ testovaných událostí ilustruje obrázek 6.5.3. Koleˇcka 40
ˇ 6. M ETODIKA INTEGRA CNÍHO TESTOVÁNÍ EPN v 1 6
2 v
1 5 2
1
3
4
3
4
2 3
Obrázek 6.2: Ukázkové poˇradí testování události EPN
oznaˇcují EP agenty, šipky mezi nimi poté kanály, kterými proudí právˇe jeden typ událostí. Písmeno v oznaˇcuje vstupní události EPN, cˇ ísla poté poˇradí, v jakém budeme testovat typy událostí v rámci jednotlivých iterací podprocesu Testování konkrétního typu události. Na obrázku je zachycena situace, kdy jednu výstupní událost nebylo možné kvuli ˚ komplexnosti EP agenta testovat rovnou na nejvyšší úrovni abstrakce, proto došlo k zanoˇrení se do struktur daného EP agenta a do integraˇcních testu˚ byly zahrnuty jeho interní události. Pokud vhodných kandidátu˚ pro testování v aktuální iteraci existuje více, je urˇcení poˇradí jejich testování na testerovi. Mˇel by pˇri tom zvážit externí souvislosti jako dopad výsledku˚ testování na další vývoj EPN atd. Definice 3 Komplexní EP agent je každý EP agent, pro kterého není možné jednoduše identifikovat hraniˇcní hodnoty atributu˚ vstupních událostí (viz definice 1) a jejich vzájemné závislosti.
Definice 4 Komplexní EPN je každá EPN, pro kterou není možné jednoduše identifikovat hraniˇcní hodnoty atributu˚ vstupních událostí (viz definice 1) a jejich vzájemné závislosti. 41
ˇ 6. M ETODIKA INTEGRA CNÍHO TESTOVÁNÍ EPN
Pˇríprava oˇcekávaných výstupních událostí V rámci této aktivity tester pˇripraví soubor oˇcekávaných výstupních událostí. Odvození tˇechto událostí probíhá na základˇe znalosti technického návrhu EPN, znalosti vstupních událostí EPN a výstupních událostí EP agentu˚ ovˇerˇ ených v rámci pˇredchozích iterací podprocesu Testování konkrétního typu události. Implementace testu Poté, co je pˇripraven soubor oˇcekávaných výstupních událostí, je nutné vytvoˇrit mechanismus porovnání tˇechto událostí s událostmi získanými z EPN. Tento mechanismus je kodifikován do automaticky vykonatelné podoby (viz sekce 5.2.6). Zpusob ˚ implementace testu je závislý na nástrojích, které pro testování použijeme. Metodika samotná proto nepˇredkládá žádné zásady, které bychom mˇeli bˇehem implementace dodržovat. Implementace testu˚ pomocí nástroje CloverETL je zachycena v rámci kapitoly 7. Provedení a vyhodnocení testu Vzhledem k vˇetšímu poˇctu rozhodovacích kroku, ˚ je proces vykonávání této aktivity zachycen na obrázku 6.5.3. Nejprve je implementovaný test spuštˇen v rámci testovacího prostˇredí. Pˇri správném nastavení testovacího prostˇredí by samotné provedení testu mˇelo probˇehnou automaticky bez nutností zásahu zvenˇcí. Pokud je výsledek testu pozitivní, je test archivován pro pˇrípadné pozdˇejší použití a proces ukonˇcen. Pokud je výsledek testu negativní je nutné získat dostatek informací o chybˇe, abychom ji mohli lokalizovat a podniknout pˇríslušné kroky. Pokud dostatek informací nemáme, pustíme se do hlubší investigace chyby. V rámci investigace chyby máme dvˇe možnosti, jak postupovat: 1.
Pokud EP agent, který produkuje výstupní událost testovanou v rámci iterace integraˇcního testu, zapouzdˇruje EPN na nižší úrovni hierarchie (viz sekce 3.1), zahrneme interní události této EPN do integraˇcního testování, jak je popsáno v sekci 6.5.3. To nám umožní lépe izolovat chybu. 42
ˇ 6. M ETODIKA INTEGRA CNÍHO TESTOVÁNÍ EPN
Ano Vykonání testu
Negativní
Ne Výsledek testu Pozitivní
Chyba v očekávaných událostech
Archivace implementovaného testu
Návrat k aktivitě Příprava očekávaných výstupních událostí
Zahodit test a zahájit novou iteraci
Investigace chyby
Chyba opravena
Ano Lokalizace chyby
Ne
Test stále validní?
Dostatek informací o chybě?
Chyba v EP agentovi
Požadavek na opravu chyby
Chyba v implementace testu
Návrat k aktivitě Implementace testu
Obrázek 6.3: Proces vykonání a vyhodnocení testu
2.
Pokud jsme již na nejnižší úrovni hierarchie, tj. EP agenta nelze dále rozložit, vytvoˇríme a provedeme jednotkový test daného EP agenta. Jednotkový test nám umožní lépe manipulovat se vstupními událostmi a dukladnˇ ˚ eji tak provˇerˇ it funkˇcnost EP agenta. Více o testování EP agentu˚ naleznete v sekci 5.2.
Jakmile máme dostatek informací o chybˇe, mužeme ˚ ji lokalizovat. Bud’ se jedná o chybu testu (v chybnˇe definovaných oˇcekávaných událostech nebo v implementaci testu), nebo o chybu v EP agentovi, který testovaný typ události produkuje. Pokud se jedná o chybu v testu, vrátíme se k aktivitˇe bˇehem které vznikla a opravíme ji. V pˇrípadˇe, že se jedná o chybu v EP agentovi, reportujeme ji vývojáˇrum ˚ spolu se všemi duležitými ˚ informacemi k identifikaci její pˇríˇciny. Jakmile je chyba opravena, zkontrolujeme, jestli nedošlo v výrazným zmˇenám EPN, které by test uˇcinili nevalidním. Pokud k takovým zmˇenám došlo, test zahodíme a zapoˇcneme s novou iterací procesu Testování konkrétního typu události. V opaˇcném pˇrípadˇe test opˇetovnˇe spustíme a opakujeme všechny kroky v rámci aktivity Pro43
ˇ 6. M ETODIKA INTEGRA CNÍHO TESTOVÁNÍ EPN
vedení a vyhodnocení testu. Bˇehem cˇ ekání na opravu chyby lze zahájit novou iteraci Testování konkrétního typu události, pokud je možné testovat jinou událost nezávislou na výstupu tohoto testu.
6.6
Známá omezení metodiky
Vzhledem k postupnému testování událostí „po proudu“, není možné metodiku užít pro testování EPN obsahujících zpˇetnou vazbu. Zpˇetná vazba znamená že nˇekterý EP agent produkuje události „smˇerované“ na EP agenta umístˇeného v sítí pˇred ním proti toku událostí. Tento problém by si zasloužil hlubší samostatný výzkum pˇrekraˇcující rozsah této práce. Druhé omezení metodiky se vztahuje k situaci, kdy proces integraˇcního testování bˇeží paralelnˇe s procesem vývoje. V tomto pˇrípadˇe je nutné vyvíjet EPN „po proudu“ od událostí vstupních po událostí výstupní (blíže specifikováno v sekci 6.1). Metodiku integraˇcního testování EPN tedy nelze použít pˇri integraci vˇetších celku˚ EPN, které byly vyvíjeny oddˇelenˇe.
6.7
Kombinace integraˇcního testování EPN s testováním EP agentu˚
Metodika integraˇcního testování EPN byla od poˇcátku plánována tak, aby mohlo být integraˇcní testování použito jako základní úrovenˇ testování EPN, tj. integraˇcnímu testováni nepˇredchází jednotkové testování EP agentu. ˚ Tím je porušena standardní posloupnost úrovní testování popsaná v sekci 5.2. Duvodem ˚ k tomu je cˇ asovˇe nároˇcné udržování jednotkových testu˚ bˇehem vývoje EPN, které bylo vypozorováno bˇehem autorova pusobení ˚ na CEP projektech v Mycroft Mind, a.s. Vypuštˇení jednotkového testování je kompenzováno systematickým pˇrístupem k výbˇeru testovaných událostí (viz sekce 6.5.3). Tím je zajištˇeno otestování všech EP agentu˚ na nejvyšší úrovni hierarchie (viz sekce 3.1). Jednotkové testování lze využit v rámce metodiky integraˇcního 44
ˇ 6. M ETODIKA INTEGRA CNÍHO TESTOVÁNÍ EPN
testování EPN jako doplnkový ˇ nástroj pro zjištˇení podrobností o chybˇe a její lokalizaci, pokud nejsou tyto informace zˇrejmé z výsledku˚ integraˇcního testu (viz sekce 6.5.3).
45
7 Testování EPN pomocí CloverETL V rámci této kapitoly je pˇredstaven nástroj CloverETL1 a zpusob ˚ jeho využití pro testování EPN. CloverETL je engine sloužící k extrakci, transformaci a nahrávání2 dat z a do ruzných ˚ datových zdroju. ˚ Celý proces zpracování proudu˚ dat je zapsán pomocí sítˇe komponent, nazývané transformaˇcní graf, doplnˇené o konfiguraˇcními soubory a skripty v jazyce CTL. Výrobce poskytuje nástroj CloverETL Designer, kterým lze transformaˇcní grafy editovat v grafickém režimu s využitím základních znalostí programování. Z pohledu testování se dá použití CloverETL charakterizovat jako testování rˇ ízené daty (angl. data driven testing). Pˇri použití této techniky jsou vstupní a oˇcekávaná testovací data uložena v podobˇe tabulek. Pˇri testování je spuštˇen kontrolní skript, který nahraje vstupní data a porovná reálné výstupy s oˇcekávanými, tak jak jsou uvedeny v tabulkách. [3] V našem pˇrípadˇe hrají roli kontrolního skriptu transformaˇcní grafy CloverETL popsané v sekci 7.2. Následující text pˇredstavuje obecné nastavení testovacího prostˇredí a nástroj pro implementaci testu, ˚ které jsou kapitole 9 použity spoleˇcnˇe s metodikou integraˇcního testování EPN. Díky pružnosti, kterou využití CloverETL pˇrináší, mohou být transformaˇcní grafy (nazývané pro úˇcely testování EPN grafy testovacími) snadno upraveny pro specifické potˇreby testování konkrétní EPN.
7.1
Testovací webová služba
Aby bylo možné z testovacích grafu˚ ovládat proces zpracování dat a pˇristupovat k interním stavum ˚ EPN je nutné, aby CEP aplikace poskytla rozhraní, které tyto funkce zpˇrístupní. V rámci popisovaného obecného nastavení testovacího prostˇredí je tímto rozhraním webová služba typu REST [25]. CloverETL ale umožnuje ˇ používat i jiné komunikaˇcní prostˇredky jako SOAP nebo JMS. Rozhraní webové služby CloverTestService zachycuje výpis kódu 7.1 v jazyce Java. 1. http://www.cloveretl.com/ 2. Angl. extract, transform, load – zkracováno na ETL.
46
7. T ESTOVÁNÍ EPN POMOCÍ C LOVER ETL Následuje popis významu jednotlivých metod. Metoda listen nastaví zachycování událostí proudících EPN. Pomocí parametru eventType jí pˇredáme typ události, kterou chceme zachycovat. Metoda loadEvents nahraje do CEP aplikace vstupní události, které ale nejsou zpracovány, dokud není zavolána metoda processEvents. Parametr eventType specifikuje typ událostí, obsahem parametru jsou poté samotné události zapsané v podobˇe definované parametrem format. Metodu lze volat opakovanˇe pro ruzné ˚ typy událostí. Povinným atributem událostí je cˇ asová známka, podle které budou pˇred zpracováním seˇrazeny. Metoda processEvents spustí proces zpracování událostí a pošle do EPN vstupní události nahrané pomocí metody loadEvents. Parametry dataFrom a dateTo definují cˇ asový rozsah vstupních událostí, které budou do EPN poslány. Boolean parametr simulation zapíná a vypíná simulaˇcní mód. V tomto módu se nezapisuje nic do testovací databáze a muže ˚ ovlivnovat ˇ i další chování v závislosti na konkrétní aplikaci. Metoda getListened vrací události zachycené bˇehem zpracování. Pomocí parametru eventType je pˇredán typ událostí, které chceme vrátit. Aby tato metoda pracovala korektnˇe, je nutné zavolat pro daný typ události metodu listen ještˇe pˇred zapoˇcetím zpracování pomocí metody processEvents. Parametrem format mužeme ˚ ovlivnit formát v jakém bude výpis vrácen, standardnˇe je to formát CSV. Následující dvˇe metody slouží pro zjednodušení práce z CloverETL. Ten umožnuje ˇ naˇcítat metadata a transformaˇcní skripty dynamicky z externích zdroju. ˚ Díky tomu je možné vytvoˇrit univerzální grafy, které umožní testovat ruzné ˚ typy událostí. V opaˇcném pˇrípadˇe by bylo nutné pro každý typ události vytvoˇrit separátní graf. Metoda getMetadata vrací metadata popisující datové typy jednotlivých atributu˚ události na základˇe typu události pˇreda47
7. T ESTOVÁNÍ EPN POMOCÍ C LOVER ETL ného pomocí parametru eventType. Boolean parametr resultField urˇcuje, jestli se má být k atributum ˚ události pˇridán atribut, který obsahuje vyhodnocení testu pro danou událost. Metoda getTransformFunction slouží k získání kódu transformaˇcní funkce, která je nutná pro vzájemnou komunikaci nˇekterých komponent CloverETL. Tato funkce je závislá na typu události pˇredaného pomocí parametru eventType. Parametr resultValue nese vyhodnocení testu pro danou událost, které je pomocí transformaˇcní funkce k atributum ˚ událost pˇridáno. Pokud je tento parametr prázdný, nepˇridává se žádný atribut. Výpis kódu 7.1: Rozhraní webové služby CloverTestService @Produces("text/plain;charset=utf-8") public interface CloverTestService { @POST @Path("listen/{eventType}") public String listen( @PathParam("eventType") String eventType); @POST @Path("loadEvents") public String loadEvents( @FormParam("eventType") String eventType, @FormParam("data") String data, @DefaultValue("csv") @QueryParam("format") String format); @POST @Path("processEvents") public String processEvents( @FormParam("dateFrom") String dateFromStr, @FormParam("dateTo") String dateToStr, @DefaultValue("true") @FormParam("simulation") boolean simulationMode); @GET @Path("getListened/{eventType}") public String getListened( @PathParam("eventType") String eventType, @DefaultValue("csv") @QueryParam("format") String format);
48
7. T ESTOVÁNÍ EPN POMOCÍ C LOVER ETL @GET @Path("getMetadata/{eventType}") @Produces("application/xml;charset=utf-8") public String getMetadata( @PathParam("eventType") String eventType, @DefaultValue("false") @QueryParam("resultField") boolean resultField); @GET @Path("getTransformFunction/{eventType}") public String getTransformFunction( @PathParam("eventType") String eventType, @DefaultValue("") @QueryParam("resultValue") String resultField); }
7.2
Testovací grafy
Pro úˇcely automatizovaného vykonání testu˚ byly v nástroji CloverETL Designer vytvoˇreny dva testovací grafy. Graf s názvem TestSuite (na obrázku 7.2) rˇ ídí provádˇení celého testovacího procesu. Volá metody testovací webové služby 7.1, spouští testy jednotlivých typu˚ událostí a vytváˇrí soubor s agregovanými výsledky testu. ˚ Graf s názvem GeneralEventTest (na obrázku 7.2) vykonává samotné testy jednotlivých typu˚ událostí a zapisuje jejich podrobné výsledky. Obecnˇe probíhá zpracování dat v CloverETL dávkovˇe. Pˇri spuštˇení protékají jednotlivé záznamy pˇres komponenty grafu po smˇeru šipek spojovacích cˇ ar, které nesou informace o metadatech, tj. forˇ mátu, ve kterém si komponenty pˇredávají data. Císlo v levém horním rohu každé komponenty oznaˇcuje fázi, v rámci které bude zpracování provedeno. Následuje podrobnˇejší popis prubˇ ˚ ehu zpracování testovacích grafu. ˚ 7.2.1 Graf TestSuite V nulté fázi zpracování grafu jsou komponentou Read input event types naˇcteny rˇ ádky souboru input_events.txt, které obsahují vždy dvojici typ události a název souboru se vstupními testovacími 49
7. T ESTOVÁNÍ EPN POMOCÍ C LOVER ETL
Obrázek 7.1: Graf TestSuite vytvoˇrený v CloverETL
50
7. T ESTOVÁNÍ EPN POMOCÍ C LOVER ETL
Obrázek 7.2: Graf GeneralEventTest vytvoˇrený v CloverETL
událostmi daného typu. Tyto soubory jsou postupnˇe naˇcteny komponentou Read input events a prostˇrednictvím komponenty Load input events pˇredány metodˇe loadEvents testovací webové služby (viz sekce 7.1). V rámci první fáze je pomocí komponenty Read specification nacˇ tena specifikace sady testu˚ ze souboru test_suite.txt (pˇríklad obsahu souboru je uveden v tabulce 9.1). Naˇctené rˇ ádky souboru jsou jednoduše zkopírovány na dva výstupy pomocí komponenty Copy. Na základˇe typu události komponenta Format listen call pˇripraví URL, kterou se metoda testovací služby zavolá. Samotné volání se provede prostˇrednictvím komponenty Set listener. Volanou metodou webové služby je v tomto pˇrípadˇe listen popsaná v sekci 7.1. Komponenta Trash je zapojena z cˇ istˇe provozních duvod ˚ u, ˚ protože CloverETL u pˇredchozí komponenty vyžaduje zapojení výstupního portu. Komponenta Trash veškeré svoje vstupy zahazuje. V druhé fázi je spuštˇen samotný detekˇcní proces prostˇrednictvím komponenty Run detection process, která volá metodu processEvent testovací webové služby. Soubˇežnˇe s tím je vytvoˇren soubor pro souhrnnými výsledky celé sady testu˚ (na obrázku 7.2 žlutý rámeˇcek s nadpisem Reporting). Komponenta Triger se stará pouze o vygenerování právˇe jednoho záznamu, který spustí vykonání kom51
7. T ESTOVÁNÍ EPN POMOCÍ C LOVER ETL ponenty Format header. Ta definuje formát hlaviˇcky výstupního souboru a také samotný název souboru, který se skládá z data a cˇ asu zahájení testu. Samotný soubor i s hlaviˇckou je vytvoˇren komponentou Write header. V rámci tˇretí fáze dojde nejprve k naplnˇení vstupních parametru˚ grafu GeneralEventTest podle specifikace jednotlivých testu˚ komponentou Format graph params. Poté je graf komponentou Run event test spuštˇen. S každým rˇ ádkem v souboru test_suite.txt je spuštˇena jedna instance grafu GeneralEventTest popsaného níže. 7.2.2 Graf GeneralEventTest Tento graf se spouští s ruznými ˚ parametry pro každou testovanou událost definovanou v souboru test_suite.txt Vˇetšina komponent grafu je zpracována v nulté fázi. Nejprve jsou prostˇrednictvím komponenty Read actual events, která volá metodu webové služby getListened, získány události zachycené bˇehem detekˇcního procesu. Soubˇežnˇe s tím jsou ze souboru CSV naˇcteny oˇcekávané události prostˇrednictvím komponenty Read expected events. Poté jsou aktuální i oˇcekávané události serˇ azeny pomocí komponent Sort. Atributy, podle kterých je seˇrazení provedeno jsou definovány ve sloupci Seˇrazení událostí souboru test_suite.txt (pˇríklad obsahu viz tabulka 9.1). Komponenta Intersection provádí prunik ˚ dvou proudu˚ událostí a rozdílné výstupní porty rozdˇeluje ty, které jsou jenom v prvním proudu, jenom v druhém proudu a v obojích. Komponenty Format unexpected events, Format OK events a Format expected events jednoduše pˇridávají k atributum ˚ události atribut z výsledkem testu – OK, expected nebo unexpected. Tyto události jsou sjednoceny zpˇet do jednoho proudu pomocí komponenty Gather, seˇrazeny sestupnˇe podle povinného atributu engineTime a zapsány do výstupního souboru ve formátu CSV. Fáze jedna zaˇcíná vygenerováním jednoho spouštˇecího záznamu komponentou Trigger, který iniciuje sumarizaci výsledku˚ testu pomocí komponenty Gather log info. Tyto výsledky obsahují poˇcet událostí, které byly nalezeny v obou zdrojích, tˇech, které byly oˇcekávány, ale v aktuálním proudu událostí nebyly nalezeny, a tˇech, které byly mezi aktuálními událostmi, ale nebyly oˇcekávány. 52
7. T ESTOVÁNÍ EPN POMOCÍ C LOVER ETL
7.3
Jiné nástroje pro implemetaci testu˚
Pˇri cestˇe k hledání vhodného nástroje pro implementaci automatických testu˚ EPN byl kromˇe CloverETL vyzkoušen také standardní nástroj pro psaní jednotkových testu˚ JUnit3 a nástroj JBehave4 sloužící primárnˇe pro podporu Behavior Driven Development [4]. Oba tyto nástroje byly vyhodnoceny jako nevhodné pro testování EPN kvuli ˚ nutnosti psát velké množství obslužného kódu a nepˇrehlednosti pˇri testování vˇetších objemu˚ událostí. Lze ale pˇredpokládat, že pro implementaci testu˚ budou kromˇe CloverETL použitelné i další nástroje postavené na principech ETL [32], i když nebyly v rámci této práce testovány.
3. http://www.junit.org/ 4. http://jbehave.org/
53
8 Pˇredstavení aplikace Adjustment Monitor Kapitola 9 pojednává o modelovém nasazení metodiky testování EPN s konkrétními nástroji na reálném vývojovém projektu, jehož výstupem je zakázková aplikace Adjustment Monitor pro monitoring serˇ izování stroju˚ v kovovýrobˇe. Úˇcelem této kapitoly je aplikaci Adjustment Monitor pˇredstavit. Jsou zde uvedeny pouze informace nezbytnˇe nutné pro pochopení procesu testování. Projekt byl realizován v Mycroft Mind, a.s. Kvuli ˚ zachování firemního tajemství není v následujícím textu uvedeno jméno zákazníka ani informaˇcního systému, který pro rˇ ízení výroby používá.
8.1
Charakter aplikace
CEP aplikace byla vyvinuta jako rozšiˇrující modul IS rˇ ízení výroby nasazeného ve firmˇe zákazníka. Vstupem jsou aktuální informace o pˇrihlašování a odhlašování operátoru˚ výroby a seˇrizovaˇcu˚ k pˇríslušným operacím na výrobních strojích. Tyto informace jsou v pravidelných intervalech naˇcítány z databáze IS rˇ ízení výroby. Výstupem jsou generované reporty seˇrizování a okamžitá upozornˇení na podezˇrelá seˇrizování. Reporty poskytují agregované informace o typickém prubˇ ˚ ehu seˇrizování vztaženému k umístˇení stroje, typu stroje a souslednosti operací. Slouží jako podklad pro optimalizaci procesu˚ ve výrobˇe v dlouhodobˇejším horizontu. Oproti tomu funkce upozornˇení na podezˇrelá seˇrizování má okamžitý efekt na zkrácení cˇ asu˚ seˇrizování. Upozornˇení je odesláno zodpovˇednému výrobnímu mistrovi v momentˇe, kdy se aktuálnˇe probíhající seˇrizování svým prubˇ ˚ ehem odkloní od jemu podobným seˇrizováním, která probˇehla v minulosti. Mistr tak muže ˚ na danou situaci okamžitˇe reagovat a sjednat nápravu.
8.2
Struktura EPN
Následující text používá slovník a notace z [6], které jsou využívány pˇri návrhu CEP aplikací v Mycroft Mind, a.s. EP agent na nejvyšší úrovni je zde nazýván detekˇcní scénáˇr, EP agenti na nižších úrovních 54
ˇ 8. P REDSTAVENÍ APLIKACE A DJUSTMENT M ONITOR
se nazývají detekˇcní metody. Proces zpracování komplexních událostí byl adekvátnˇe pˇrejmenován na detekˇcní proces. Tato aplikace má jeden detekˇcní scénáˇr s názvem Dohledování seˇrizování, který je zobrazen na 8.2. Následuje popis jednotlivých detekˇcních metod. SelectAlertingRelavantAdjustment vytváˇrí na základˇe drženého stavu a pˇríchozí události o zapoˇcetí seˇrizování (AdjustmentStartEvent) událost o zahájení prvotního seˇrizování (PreparationStartEvent) relevantní pro systém upozornˇení. Aktuální stav výrobního procesu je konstruován na základˇe pˇríchozích událostí o ukonˇcení obecné operace, která muže ˚ být jak seˇrizováním tak výrobou (OperationStopEvent). SelectProfileRelevantAdjustment vytváˇrí na základˇe drženého stavu a pˇríchozí události o ukonˇcení obecné operace (OperationStopEvent) událost o ukonˇcení prvotního seˇrizování (PreparationStopEvent) nebo korekˇcního seˇrizování (TuningStopEvent). Na základˇe tˇechto vytvoˇrených událostí jsou kontinuálnˇe budovány profily, které popisují obvyklé prubˇ ˚ ehy seˇrizování. Aktuální stav výrobního procesu je konstruován na základˇe pˇríchozích událostí o ukonˇcení obecné operace, která muže ˚ být jak seˇrizováním tak výrobou (OperationStopEvent). CompareWithNormAndProfile zachytí událost o zaˇcátku prvotního seˇrizování (PreparationStartEvent) a v pravidelných cˇ asových intervalech ji porovnává s definovanou normou a vybudovaným profilem. Pokud dojde k pˇrekroˇcení normy, je generována událost OverNormPreparationEvent. Pokud dojde k pˇrekroˇcení obvyklého cˇ asu seˇrizování podle profilu, je generována událost OverProfilePreparationEvent. Pravidelné porovnávání je ukonˇceno v momentˇe pˇríchodu události o ukonˇcení operace seˇrizování (OperationStopEvent). AlertMaking zachycuje událost o bˇežícím seˇrizování, které pˇrekrocˇ ilo normu nebo profil (OverNormPreparationEvent nebo OverProfilePreparationEvent). Na základˇe stavu jejich atributu˚ vypoˇcítává úrovenˇ duležitosti ˚ upozornˇení a odesílá jej jako událost AlertEvent. 55
ˇ 8. P REDSTAVENÍ APLIKACE A DJUSTMENT M ONITOR
<
> OperationStopEvent
<> AdjustmentStartEvent
<> SelectAlertingRelevantAdjustment
<> SelectProfileRelevantAdjustment PreparationStopEvent TuningStopEvent
PreparationStartEvent <> PreparationNorm
<> AdjustmentProfiles
<> CompareWithNormAndProfile OverNormPreparationEvent OverProfilePreparationEvent <> AlertMaking
<<Situation>> AlertEvent
Obrázek 8.1: Detekˇcní scénáˇr Dohledování seˇrizování
56
ˇ 8. P REDSTAVENÍ APLIKACE A DJUSTMENT M ONITOR
8.3
Použité technologie
Logika zpracování událostí je implementována pomocí EPL (Event Processing Language) CEP enginu Esper1 . Obslužné komponenty jsou implementovány v jazyce Java s použití EJB 3.1. Celá aplikace bˇeží na aplikaˇcním serveru GlassFish2 .
1. http://esper.codehaus.org/ 2. http://glassfish.java.net/
57
9 Integraˇcní testování aplikace Adjustment Monitor Následující text popisuje modelové použití metodiky integraˇcního testování EPN, spolu s CloverETL jako nástrojem pro implementaci testu. ˚ Struktura této kapitoly respektuje posloupnost aktivit definovanou v sekci 6.5. Objektem testování je CEP aplikace Adjustment Monitor popsaná v kapitole 8.
9.1
Pˇríprava testovacího prostˇredí
Pˇríprava testovacího prostˇredí spoˇcívá v implementaci testovací služby podle rozhraní uvedeného v sekci 7.1. Tato služba umožní ovládání detekˇcního procesu a získávání událostí výstupních. Metoda pro nahrávání vstupních událostí loadEvents nebude použita, testovací vstupní události se budou nahrávat z pˇripravené testovací databáze (viz sekce 9.2). V rámci simulaˇcního módu nebudou aktualizovány profily serˇ izování a události AdjustmentStartEvent budou generovány i pro záznamy o seˇrizování, které již byly ukonˇceny (viz sekce 7.1). Testovací grafy v CloverETL, TestSuite a GeneralEventTest, byly pˇripraveny v totožné podobˇe, jako jsou uvedeny v sekci 7.2. Jedinou zmˇenou je vyˇrazení fáze 0 z grafu TestSuite vzhledem k naˇcítání vstupních událostí z testovací databáze.
9.2
Pˇríprava testovacích dat
Vstupní události AdjustmentStartEvent a OperationStartEvent jsou pˇri provozu CEP aplikace generovány v pravidelných intervalech na základˇe aktuálního obsahu databáze IS rˇ ízení výroby. V rámci minimalizace nutných zásahu˚ do aplikace jsme tedy pro naˇcítání testovacích události zvolili stejný pˇrístup. Pˇripravili jsme nemˇennou testovací databázi, která byla vytvoˇrena zkopírováním vybraných tabulek produkˇcní databáze IS rˇ ízení výroby. Tyto tabulky byly naplnˇeny historickými záznamy z vybraného dne výroby, pro který byly odvozeny všechny oˇcekávané události generované CEP aplikací. 58
ˇ 9. I NTEGRA CNÍ TESTOVÁNÍ APLIKACE A DJUSTMENT M ONITOR
Kromˇe testovací databáze je do procesu testování zapojena také databáze, ve které jsou uchovávány vybudované profily seˇrizování a normy prvotních seˇrizování (viz kapitola 8). Pro naplnˇení tabulek uchovávajících profily byla spuštˇena metoda processEvents testovací webové služby s parametrem simulation nastaveným na hodnotu false, nad záznamy z vybraných tˇrech souvislých mˇesícu. ˚ Norma seˇrizování byla pro úˇcely testu nastavena jednotnˇe pro všechny prvotní seˇrizování na 60 minut, korekˇcní seˇrizování normovány nejsou.
9.3
Testování konkrétní události
Tato cˇ ást pˇredstavuje dva modelové pruchody ˚ podprocesem Testování konkrétní události (viz sekce 6.5) pˇri testování události PreparationStartEvent a AlertEvent.
9.3.1 Výbˇer události PreparationStartEvent Pˇredstavme si, že tento výbˇer provádíme na zaˇcátku testování, není tedy zatím otestována žádná událost. Podle pravidel popsaných v sekci 6.5.3 vybereme tedy takovou událost, která je závislá pouze na vstupních událostech EPN. Pˇri pohledu na schéma EPN na obrázku 8.2 tomuto kritériu odpovídají tˇri události: PreparationStartEvent, PreparationStopEvent a TuningStopEvent. Urˇcení poˇradí jejich testování je cˇ istˇe na uvážení testera. Zvolíme tedy jako první PreparationStartEvent. Nyní ovˇerˇ íme, jestli je mechanismus závislosti mezi PreparationStartEvent a vstupními událostmi AdjustmentStartEvent a PreparationStopEvent dostateˇcnˇe zˇrejmý a zachytitelný testem. Toto uvážení provádí tester, který by mˇel vzít v potaz kritiˇcnost dané CEP aplikace. Pokud by shledal mechanismus závislosti pˇríliš složitý na to, aby byl pokryt jedním testem, rozkryl by detekˇcní metodu SelectAlertingRealevantAdjustment a zvolil pro testování nˇekterou z jejich interních událostí. V našem pˇrípadˇe je ale závislost mezi vstupními událostmi a testovací událostí pˇrímoˇcará, takže hlubší rozpad detekˇcní metody není nutný. 59
ˇ 9. I NTEGRA CNÍ TESTOVÁNÍ APLIKACE A DJUSTMENT M ONITOR
9.3.2 Pˇriprava testu PreparationStartEvent Pˇríprava testu pˇri použití testovacích grafu˚ v CloverETL spoˇcívá ve vytvoˇrení CSV souboru s oˇcekávanými událostmi PreparationStartEvent a specifikaci parametru˚ daného testu v souboru test_suite.txt. Oˇcekávané události jsou ruˇcnˇe odvozeny na základˇe znalosti záznamu˚ z databáze IS rˇ ízení za zvolený testovaný den a obsahu tabulek s napoˇcítanými profily a normou. Parametry tohoto testu jsou uvedeny v prvním rˇ ádku tabulky 9.1. Hodnota parametru Typ události je PreparationStartEvent. Druhý parametr Seˇrazení událostí je nastaven na loginIt(a), což znamená, že záznamy ze souboru oˇcekávaných událostí i ty aktuální vrácené metodou getListened testovací webové služby budou serˇ azeny podle atributu loginId sestupnˇe. Parametr Porovnávané atributy nastavený na hodnotu $loginId = $loginId rˇ íká, že shodnost události v obou proudech se bude posuzovat pouze podle atributu loginId. To znamená, že v souboru s oˇcekávanými událostmi mohou být hodnoty ostatních atributu˚ nevyplnˇené. 9.3.3 Provedení a vyhodnocení testu PreparationStartEvent Provedení testu je už velmi jednoduché, staˇcí v prostˇredí CloverETL Designer spustit pˇripravený graf TestSuite. Pˇrí každém spuštˇení sady testovacích grafu˚ je vytvoˇren soubor v adresáˇri test_suite_results, který obsahuje v názvu datum a cˇ as spuštˇení sady testu. ˚ Soubor samotný obsahuje pro každý typ testovaných událostí poˇcet tˇech, které byly nalezenu v proudu aktuálních i oˇcekávaných událostí; oˇcekávaných ale neobsažených mezi aktuálními a obsažených mezi aktuálními ale neoˇcekávaných. Pˇríklad obsahu tohoto souboru je uveden v tabulce 9.3.6 (zde obsahuje už všechny testované události). Pro tuto chvíli se spokojíme s tím, že kumulované výsledky neukazují žádnou chybu. Hledání potenciální chyby v podrobných výsledcích si ukážeme u následujícího testu. 9.3.4 Výbˇer události AlertEvent Nyní se pˇreneseme do fáze, kdy už jsou všechny ostatní události otestované a poslední zbývající událostí k otestování je AlertEvent. 60
ˇ 9. I NTEGRA CNÍ TESTOVÁNÍ APLIKACE A DJUSTMENT M ONITOR
Typ události PreparationStartEvent PreparationStopEvent TuningStopEvent OverNormPreparationEvent OverProfilePreparationEvent AlertEvent
Seˇrazení událostí loginId(a)
Porovnávané atributy $loginId = $loginId
loginId(a)
$loginId = $loginId
loginId(a) loginId(a); currentTS(a)
$loginId = $loginId $loginId = $loginId; $currentTS = $currentTS $loginId = $loginId; $currentTS = $currentTS $loginId=$loginId; $actualSeverityInterval = $actualSeverityInterval; $prevSeverityInterval = $prevSeverityInterval
loginId(a); currentTS(a) loginId(a); actualSeverityInterval(a); prevSeverityInterval(a)
Tabulka 9.1: Obsah test_suite.txt pro kompletní sadu testu˚ Adjustment Monitor (v souboru jsou jednotlivé sloupce oddˇeleny znakem svislé cˇ áry) 9.3.5 Pˇriprava testu AlertEvent Stejnˇe jako u testu PreparationStartEvent je tˇreba pˇripravit CSV soubor s oˇcekávanými událostmi a vyplnit parametry testu v souboru test_suite.txt. Plnˇe vyplnˇený soubor se specifikací zobrazuje tabulka 9.1. 9.3.6 Provedení a vyhodnocení testu AlertEvent Protože je test AlertEvent souˇcástí sady testu˚ Adjustment Monitor je pro jeho provedení nutné spustit celou sadu testu˚ pomocí grafu TestSuite. Pˇri pohledu do tabulky agregovaných výsledku˚ 9.3.6 zjistíme, že pˇri testu AlertEvent vrátila testovací webová služba dvˇe události, které nebyly oˇcekávány. Pro nalezení detailu˚ o chybˇe je nutné podívat se do souboru AlertEvent _results.csv, který obsahuje cˇ asovˇe seˇrazený výpis všech událostí daného typu i se všemi jejich atributy doplnˇenými o atribut test_result obsahují výsledek testu na dané událostí (viz sekce 7.2.2). Nalezneme tedy dva rˇ ádky, u kterých 61
ˇ 9. I NTEGRA CNÍ TESTOVÁNÍ APLIKACE A DJUSTMENT M ONITOR
Typ události
Poˇcet událostí OK
PreparationStartEvent PreparationStopEvent TuningStopEvent OverNormPreparationEvent OverProfilePreparationEvent AlertEvent
67 50 71 12 9 7
Poˇcet pouze oˇcekávaných událostí 0 0 0 0 0 0
Poˇcet neoˇcekávaných událostí 0 0 0 0 0 2
Tabulka 9.2: Možný obsah souboru s agregovanými výsledky sady testu˚ (v souboru jsou jednotlivé sloupce oddˇeleny znakem svislé cˇ áry) nabývá atribut test_result hodnoty unexpected. Postup reportování nalezené chyby pˇresnˇe odpovídá procesu, který byl popsán v sekci 6.5.3.
9.4
Využití sady testu˚ pro regresní testování
Po opravení chyb nalezených pomocí testu˚ ve fázi vývoje jsou testovací grafy i data uchována v archivu, aby mohly být znovu použity pro regresní testování ve fázi ladˇení EPN (viz sekce 5.4).
62
10 Závˇer Diplomová práce Funkˇcní testování CEP aplikací je jedním z prvních zdroju˚ dedikovaných problematice testování CEP aplikací. Toto téma bylo dosud v literatuˇre o CEP zminováno ˇ pouze okrajovˇe. Práce reviduje pˇrístupy k funkˇcnímu testování obecných aplikací, snaží se z nich vytˇežit použitelné techniky a redefinovat ty aspekty, které se pro testování CEP aplikací jeví jako tˇežkopádné. Hlavním pˇrínosem práce je metodika integraˇcního testování EPN, která je systematickým návodem pro testování business logiky CEP aplikací. Vzhledem k rychlému vývoji CEP platforem ruzných ˚ dodavatelu˚ není vázána na konkrétní nástroje nebo jazyky pro definici EPN a implementaci testu. ˚ Doplnuje ˇ ji tedy kapitola zabývající se implementací testu˚ v nástroji CloverETL. Použitelnost metodiky i nastroje CloverETL pˇri integraˇcním testování CEP aplikací byla demonstrována na pˇríkladu testování reálné aplikace Adjustment Monitor.
10.1 Další rozvoj Problematika testování softwaru a tedy i CEP aplikací je široká. Vzhledem k omezenému rozsahu diplomové práce je po pˇrehledovém rozboru úrovní testování v rámci životního cyklu CEP aplikace, hlavní pozornost vˇenována integraˇcnímu testování. U vˇetšiny úrovní testování zcela chybí literatura, která by se danou problematikou v kontextu CEP aplikací zabývala. Proto muže ˚ tato práce posloužit zárovenˇ jako „odrazový mustek“ ˚ k hlubšímu výzkumu v oblasti testování CEP aplikací. Mezi otevˇrené otázky patˇrí: •
Jak efektivnˇe rˇ ídit testování proveditelnosti CEP aplikace?
•
Jak zkombinovat metodiku integraˇcního testování EPN s postupy testování obslužných komponent CEP aplikace?
•
Lze zformulovat univerzální strategie pro pˇrípravu sady testovacích vstupních událostí?
•
Jak pracovat se zákazníkem pˇri tvorbˇe akceptaˇcních testu? ˚ 63
Literatura [1] K. Beck. Test-driven development: by example. The AddisonWesley signature series. Addison-Wesley, 2003. [2] Mariano Benitez. Bpmn 2.0 by example, June 2010. [3] International Software Testing Qualifications Board. Standard glossary of terms used in software testing, April 2010. [4] D. Chelimsky, D. Astels, B. Helmkamp, Z. Dennis, D. North, and A. Hellesoy. The RSpec Book: Behaviour Driven Development with RSpec, Cucumber, and Friends. Pragmatic Bookshelf Series. Pragmatic Programmers, LLC, The, 2010. [5] Roy Schulte David Luckham. Event processing glossary - version 1.1, July 2008. [6] Ján Demo. Metody analýzy a návrhu cep aplikací. Diplomová práce, Masarykova univerzita - Fakulta informatiky, 2011. [7] S. Desikan and G. Ramesh. Software Testing: Principles and Practice. Prentice Hall, 2007. [8] AnnMarie Ericsson and Mikael Berndtsson. Rex, the rule and event explorer. In Proceedings of the 2007 inaugural international conference on Distributed event-based systems, DEBS ’07, pages 71–74, New York, NY, USA, 2007. ACM. [9] AnnMarie Ericsson, Paul Pettersson, Mikael Berndtsson, and Marco Seiriö. Seamless formal verification of complex event processing applications. In Proceedings of the 2007 inaugural international conference on Distributed event-based systems, DEBS ’07, pages 50–61, New York, NY, USA, 2007. ACM. [10] EsperTech. Faq - how do i test epl? [Online; navštíveno 8. 9. 2011]. [11] O. Etzion, P. Niblett, and D. Luckham. Event Processing in Action. Manning Pubs Co Series. Manning Publications, 2010. 64
ˇ 10. Z ÁV ER
[12] Mike Gualtieri and John Rymer. The forrester wavetm: Complex event processing (cep) platforms, the forrester wave: Complex event processing (cep) platforms, q3 2009, August 2009. [13] Miroslav Guriˇcan. Cep aplikácie z hl’adiska životného cyklu a význaˇcných problémov pri ich riešení. Diplomová práce, Masarykova univerzita - Fakulta informatiky, 2011. [14] Jiˇrí Karpíšek. Praktický úvod do complex event processing [online]. Diplomová práce, Masarykova univerzita, Fakulta informatiky, 2011 [cit. 2011-12-22]. [15] K. Kulakowski and M. Kostrzewa. Rapid prototyping of realtime reactive systems. In Signals and Electronic Systems, 2008. ICSES ’08. International Conference on, pages 381 –384, sept. 2008. [16] David Luckham. A short history of complex event processing part 1: Beginnings, 2007. [17] D.C. Luckham. The Power of Events: An Introduction to Complex Event Processing in Distributed Enterprise Systems. Addison-Wesley, 2002. [18] Brenda M. Michelson. Event-driven architecture overview, February 2006. [19] Michal Oškera. O vztahu soa a eda, srpen 2011. [20] Michal Oškera, Tomáš Pitner, Filip Procházka, and Zdenko Staníˇcek. Cepyramid: Tool for clarification of cep-based solution delivery principles and benefits. Experience report for DEBS 2011. [21] Norman W. Paton and Oscar Díaz. Active database systems. ACM Comput. Surv., 31:63–103, March 1999. [22] Ron Patton. Testování softwaru. Computer Press, 2002. [23] Zdenko Staníˇcek. Univerzální modelování a konstrukce IS. PhD thesis, Masarykova univerzita, Brno, 2003. 65
ˇ 10. Z ÁV ER
[24] P.N. Tan, M. Steinbach, and V. Kumar. Introduction to data mining. Pearson Addison Wesley, 2006. [25] Sameer Tyagi. Restful web services, August 2006. [26] J. Weiss, P. Mandl, and A. Schill. Functional testing of complex event processing applications. In Intelligent Computer Communication and Processing (ICCP), 2011 IEEE International Conference on, pages 407 –413, August 2011. [27] Wikipedia. Enterprise service bus — wikipedia, the free encyclopedia, 2011. [Online; navštíveno 2. 1. 2012]. [28] Wikipedia. Middleware — wikipedia, the free encyclopedia, 2011. [Online; navštíveno 2. 1. 2012]. [29] Wikipedia. Publish–subscribe pattern — wikipedia, the free encyclopedia, 2011. [Online; navštíveno 3-10-2011]. [30] Wikipedia. Request-response — wikipedia, the free encyclopedia, 2011. [Online; navštíveno 9. 11. 2011]. [31] Wikipedia. Discrete event simulation — wikipedia, the free encyclopedia, 2012. [Online; navštíveno 2. 1. 2012]. [32] Wikipedia. Extract, transform, load — wikipedia, the free encyclopedia, 2012. [Online; navštíveno 2. 1. 2012]. [33] Wikipedie. Formální verifikace — wikipedie: Otevˇrená encyklopedie, 2010. [Online; navštíveno 8. 9. 2011].
66
