Otevírání černých skříněk

Transkript

1 Vážení čtenáři, držíte v rukou už dvanácté číslo našich novin. Za tu dobu se mnohé změnilo vlády, prostředí, ve kterém žijeme, technologie, naše společnost i my sami. Říká se, že přežijí jen ti, kteří se všem těm změnám dokáží rychle a pružně přizpůsobit. Jsem možná konzervativní, ale jsem přesvědčen, že v tomto světě plném změn, člověk přece jen touží po nějaké stabilitě, po tom aby se pohyboval v prostředí, jehož vývoj dokáže předvídat. Myslím si, že ať jsou módní trendy jakékoliv, stále platí, že profesionálně odvedená práce má svou hodnotu jak pro zákazníka, tak pro toho, kdo ji udělal. Otevírání černých skříněk Patrik Šálek, salek@komix.cz Naše společnost se snaží kousek stability svým zákazníkům poskytnout, být jim partnerem, na kterého se mohou obrátit i s problémy, které třeba přímo nesouvisí s aplikací, kterou jim dodala. Jsem rád, že se nám to daří a celá řada našich zákazníků s námi spolupracuje deset i více let. Profesionalita a týmová spolupráce jsou hodnoty, které jsou vysoko na seznamu hodnot společností vyznávaných. KOMIX se časem změnil z čistě programátorské firmy na společnost, která je schopna pomoci svým zákazníkům i s problematikou procesního řízení, definicí požadavků na potřebná řešení nebo s tvorbou strategie. Na rozdíl od čistě konzultačních firem, služba KOMIXu nekončí sadou doporučení nebo studií, ale jsme připraveni na sebe vzít svůj díl odpovědnosti i za implementaci svých doporučení. V poslední době jsme své aktivity v oblasti konzultačních služeb rozšířili. Získali jsme projekty na tvorbu IT strategií, nasazení IT technologií pro podporu prodeje, propojení spolupracujících partnerů či řízení firmy. Jsme silní v oblasti tvorby metodik a pracovních postupů pro testování softwaru a to jak při jeho vývoji, tak při přejímce. Troufám si říci, že jsme se stali jedničkou českého trhu v zátěžovém testování, které je stále častěji součástí akceptačních testů. V novinách, které čtete, se snažíme ukázat rozsah toho, co umíme. Věřím, že každý z čtenářů najde v našich novinách něco, co ho zaujme. Petr Kučera, ředitel, kucera@komix.cz Představte si to vzrušení techniků, když zkoumají nějaké cizí zařízení, aby zjistili, jak vlastně funguje. Na počátku je pro ně černou skříňkou a postupně odhalují jednotlivá tajemství. Naprosto jiný typ vzrušení naproti tomu zažívají někteří vedoucí oddělení IT, když se jejich šéfové snaží zjistit, jak vlastně funguje ta jejich černá skříňka. Konkurenční ekonomické prostředí nutí firmy ke zvyšování efektivity, a to znamená, že než vydaná koruna zmizí v měšci nějakého dodavatele, je nutné opravdu pečlivě zvážit, jak se v brzké budoucnosti vrátí. IT projekty jsou navíc investičně velmi náročné. Přitom se často zahájily, aniž by existovala přesná a detailní představa o budoucím využití jejich výstupů. To se dnes mění. Penězi se více šetří a nastala doba, kdy jsou IT projekty plánovány daleko pečlivěji než dříve. Jak soukromé firmy, tak státní instituce hospodařící s napjatými rozpočty, velmi hluboce zvažují, které oblasti potřebují pokrýt, s jakou prioritou a jakým typem řešení komfortním a komplexním nebo méně pohodlným a levnějším. Pořizovatelé si uvědomují, že když nesprávně vyjádří, co chtějí, mohou pak těžko trvat na dodávce řešení, které jim bude skutečně k užitku. To, jak organizace kladou stále větší důraz na ekonomickou návratnost prostředků vložených do IT, je zpravidla transformováno do relativně podrobného popisu očekávaných přínosů. Jeden z důsledků je ten, že hlavní část rozhodování o investici do IT se zcela správně přesouvá do místa, kde tato investice přináší užitek, tj. do businessu, který nejlépe dokáže zhodnotit potenciální přínosy řešení svých požadavků. Pracovníci IT poskytují především informace o nákladech a potenciálních rizicích. IT je tak nuceno daleko pečlivěji zkoumat, jaké další náklady si investice vyžádá a zpravidla nemilosrdně škrtá vše, co není pro řešení nezbytně nutné. Striktně se odlišují vlastnosti typu nice to have a must have. Dnešní manažer se více než na krásu a dokonalost řešení soustřeďuje na výkonnost pracovníků a funkčnost podpůrných aplikací. Do vlastností, které sice řešení dělají hezkým, ale vykazují nízký poměr cena/výkon nebo představují nepřípustné riziko, zpravidla neinvestuje. Pro firmy dnes zpravidla není problém zvládnout jednotlivý projekt. Před řadou společností teď však stojí problém daleko větší: jak koordinovat to množství projektů, které v IT odděleních běží, a jak ve firmě globálně řídit poskytování podpory businessu pomocí IT prostředků. Nejsou výjimkou společnosti, které IT podpora stojí až desítky miliónů. Logicky se tedy musí klást důraz na ekonomickou efektivitu celého řešení či dokonce dílčích změn. Stále více se vpřed tlačí kontrola kvality. Přitom nejde o fráze, ale o relativně podrobné ověření stanovených parametrů SLA (Service Level Agreement) na výkon a spolehlivost. Při tom všem je až k podivu, že na rozdíl od výroby nebo účetnictví, si IT jen výjimečně vypomáhají nějakým svým IT ERP systémem, který by specifické procesy IT podpořil. Když bychom to měli shrnout, jde o to, aby mnohdy mlhavé vazby IT procesů na ostatní firemní procesy byly jasně popsány. Pokud by se tak nestalo, nemusela by se IT oddělení dál tvářit jako černé skříňky, ale postupně by upgradovala na skříňky Pandořiny. Proto také v těchto novinách píšeme i o technologiích, postupech či softwarové podpoře, které podle našeho názoru pomáhají tzv. ajtíkům. Jedná se na jedné straně o nástroje na podporu strategického řízení, využití a nasazování IT technologií, na druhé straně jsou to nástroje pro sledování provozu výpočetní techniky a jednotlivých aplikací. Informační technologie jsou dnes klíčem k optimalizaci činností firmy, ke snižování nákladů i ke hledání cest, jak se odlišit od konkurence. 1

2 Systém TARIC pro Generální ředitelství cel Architektura systému a jeho silné stránky Martin Lipš, Jiří Marschal lips@komix.cz; marschal@komix.cz Architektura systému Úkolem české celní správy v rámci vstupu České republiky do EU bylo napojit se na jednotný systém TARIC. Tento systém integruje systémy pro uplatňování celních opatření jednotlivých členských států EU. Česká část systému TARIC, kterou implementovala společnost KOMIX s.r.o., je z jedné strany vymezena rozhraním, přes které jsou přijímána data z administrativy EU, a z druhé strany rozhraním, přes které jsou data distribuována do celně deklaračního systému používaného na celních úřadech ČR. Viz obrázek 1. Administrativa EU TARIC EU databáze tarifních opatření pro EU CCN/CSI EDIFACT Generální ředitelství cel ČR NIT národní integrovaný tarif TARIC ČR databáze tarifních opatření pro ČR Import dat přicházejících denně z administrativy EU je dávková úloha, která je realizována v jazyce C. Tato aplikace dekóduje formát EDI- FACT a přijatá data zaznamenává do databáze taric, která je zrcadlem databáze v Bruselu. Při zápisu do databáze Informix jsou použity dynamické struktury SQLDA (SQL Dynamic Area). Všechny změny v této databázi jsou rovněž zaznamenávány do logovací databáze. Řízení aplikace je zcela automatické a o výsledcích běžného zpracování jsou administrátoři informováni em. UNLOAD FTP Celní úřady CDS celně deklarační systém Obrázek 1 službou session holder (démon komunikující na bázi IPC-fronty zpráv). Připojení k databázi je nativní, přes ESQL/C opět s dynamickými strukturami SQLDA. Obrázek 3 IBM INFORMIX řídící databáze (metadata) Pracovní databáze logovací databáze SQL DBI ESQL/C Aplikační server Aplikační logika libxml2 libxslt šablony xslt dat jsou přetransformovány s pomocí knihoven libxml2.a a libxslt.a na HTML. Díky tomu je elegantně oddělena prezentační logika (je v šablonách) od aplikační logiky (je v C a ESQL/C msg.queue FastCGI CGI IPC www browser HTTP HTML HTTP server APACHE/ mod_fastcgi/ Session holder session1 session2... sessionn Data systému TARIC, která jsou na předcházejícím obrázku označena jako Databáze TARIC ČR, jsou ve skutečnosti rozdělena do několika databází, viz obrázek 2. Všechny tyto databáze jsou uloženy na společném databázovém serveru IBM Informix Dynamic Server 9.30 (32bit) na uzlu IBM RS6000 SP2 (p-series). Databáze podporují vícejazyčné prostředí UTF-8 (database locale) a jsou transakční (buffered log). CCN/CSI EDIFACT taric zrcadlo TARIC EU triggery taric_log logování změn v databázi taric taric_cz kompletní databáze tarifních opatření view UNION view taric_mng řídící a metadatová databáze triggery nit_log logování změn v databázi nit UNLOAD FTP nit národní opatření IBM Informix Dynamic server 9.30 Aplikace NIT (Národní Integrovaný Tarif) je určena k interaktivní aktualizaci národních opatření uložených v databázi nit. Je realizována jako tenký klient s technologií aplikačního serveru FastCGI. Jako HTTP server byl použit WWW server Apache s modulem mod_fastcgi. HTML (přesněji XHTML) stránky jsou generovány knihovnami libxml2 a libxslt z šablon XSLT a XML dat. Kontext uživatelských připojení (tzv. session) je spravován Export tarifních opatření Aplikace NIT národní integrovaný tarif Obrázek 2 Export dat je také realizován v jazyce C. Tato aplikace denně exportuje data z databází taric a nit (respektive taric_cz) a předává je do celně deklaračních systémů (CDS). Rovněž tato aplikace je řízena zcela automaticky. Součástí systému je i synchronizace jednotlivých komponent, která je realizována semafory (IPC). Silné stránky systému Aplikace je řízena metadaty Všechny součásti aplikace jsou řízeny metadaty (metadata driven application), jak se nám již v minulosti mnohokrát osvědčilo. Popisovat výhody aplikací, které jsou řízeny metadaty, je sice nošením dříví do lesa, ale řečeno slovy klasika nepochválíš-li se sám, nikdo jiný to za tebe neudělá. Aplikace je tak díky metadatům otevřená, rozšiřitelná a parametrizovatelná. Metadata popisující všechny prvky systému jsou společně s dalšími provozními a řídícími daty uložena v databázi taric_mng. Aplikační C-moduly přistupují k metadatům prostřednictvím sofistikovaných funkcí nad cache pamětí. Díky metadatům lze třeba snadno přidat novou stránku se vstupním formulářem aniž by se cokoliv programovalo, stačí ji pouze zadat do metadat a restartovat HTTP server. Formát XML/XSLT je použit pro generování HTML Módní hysterie okolo XML sice právě teď vrcholí, ale myslíme si, že v systému NIT je tento formát použit střízlivě, rozumně a prakticky, i když ne ve svém hlavním poslání. Stránky aplikace jsou vytvořeny jako šablony XSLT a z XML modulech). Dalším důležitým plusem je ten fakt, že C-moduly nejsou zamořeny ohromnou a prakticky neudržovatelnou masou HTML tagů. Celá prezentační vrstva je postavena na několika typových šablonách, které vzájemně sdílí opakující se části kódu obsluhujícího transformaci těch prvků prezentace, které se vyskytují ve více druzích stránek. Základ prezentační vrstvy je v podstatě tvořen třemi šablonami, jejichž úkolem je generování HTML stránky pro vstup uživatelských dat tzv. input page, dále stránky pro zobrazení položek odpovídajících zadaným vstupním kritériím tzv. output page a konečně stránky s obecnějším použitím v aplikaci tzv. text page. Vedle těchto tří základních šablon jsou v aplikaci použity jejich modifikované verze pro obsloužení specifických případů stránka pro přihlášení k aplikaci, stránka pro nastavení vyhledávacích kritérií. K transformaci XML dat pomocí XSLT šablon dochází na straně serveru, úkolem prohlížeče je tedy pouze zobrazit zaslaný HTML kód. V aplikaci jsou využity také prvky dynamického HTML, které zajišťují např. kontrolu uživatelských vstupů ještě před odesláním zadávaných dat. Od 1. května 2004 je náš systém nasazen do rutinního provozu jako součást jednotného evropského systému. Odposlechnuto na autobusové zastávce; aneb Mercury už není jen o testování. Dan Petřivalský, dan.petrivalsky@komixbrn.cz Blažková: Už jste, paní, slyšela, že Mercury Interactive to dala dohromady s tím mladým Kintanou od vedle? Vomáčková: Ale to víte, že slyšela, jenže to je stará vesta. Teď už má zas nového. Je to nějaký Appilog. Blažková: No vidíte, předtím ten Performant, teď zase Appilog. Prý se taky přestěhovala ze Slunečného údolí na Horskou vyhlídku?! Vomáčková: No to je všechno pravda a ještě navíc si nechala udělat plastiku, aby vypadala jinak, přestala používat příjmení, takže si teď říká jen Mercury, a loni dokonce v Praze povila dcerku. Takhle bychom mohli dámy čekající na autobus poslouchat ještě dlouho, ale jednak se to nesluší a také by se pro čtenáře nástin novinek v Mercury Interactive docela jistě stal velmi nepřehledným. Co se tedy stalo s Mercury od léta 2003 do léta 2004? A co KOMIX na to? Uveďme na pravou míru odposlechnuté drby: Drb 1 jak to bylo s Kintanou? Kintana byla vedoucí společností na trhu Program a Portfolio managementu. Mercury Interactive, jako leader trhu s řešením pro testování softwaru a BTO Business Technology Optimization, měla ke Kintaně blízko. Nejen proto, že obě společnosti sídlily v kalifornském Sunnyvale, ale především proto, že obě best- -of-breed řešení se skvěle doplňují. V létě 2003 došlo k akvizici Kintany a krátce potom byla představena Mercury IT Governance (ITG). Začlenění podpory testování a řízení dostupnosti a výkonnosti aplikací do celkového workflow pro řízení IT ve firmách se ukazuje jako velmi dobrý tah. Produkty bývalé Kintany se stávají známé i v Evropě a celkové řešení Mercury se stává strategickou investicí pro nejednoho CIO. KOMIX se o problematiku IT Governance zajímá, čehož důkazem je i samostatný článek věnovaný produktu Mercury IT Governance Center na jiném místě tohoto listu. ITG není krabicový software, který stačí nainstalovat a vše je rázem hotovo. ITG znamená digitalizaci procesů a jejich optimalizaci, tomu se věnují konzultanti KOMIXu. Návratnost investice do ITG je až překvapivě krátká. Drb 2 co ten Appilog? Appilog je další z řady úspěšných a zajímavých akvizicí Mercury. Jejím dokončením na jaře 2004 doplnila Mercury chybějící článek do svého Business Availability Centra a tím ho ještě více odlišila od konkurence. Mapování jednotlivých prvků komplexní infrastruktury na chování klíčových aplikací umožňuje snadnější a přesnější odhalení pravé příčiny změny ve výkonnosti sledované aplikace. Tato novinka je natolik čerstvá, že KOMIX ještě neměl příležitost se s novým softwarem seznámit. Věřím, že až se tyto řádky dostanou ke čtenářům, budeme s ním mít vlastní zkušenosti a že budou pozitivní. Drb 3 Performant, stěhování Akvizice společnosti Performant je trochu staršího data. Přínos pro ladění výkonnosti Java aplikací pomocí J2EE Deep Diagnostics, který vznikl spojením sil expertů na LoadRunner 2

3 pokračování ze strany 2 a vývojářů z bývalého Performantu, je neoddiskutovatelný. KOMIX oceňuje nové možnosti sledování J2EE aplikací do nejmenších podrobností a doufá, že je brzy ocení i naši zákazníci. Naopak stěhování americké centrály ze Sunnyvale do Mountain View středoevropské uživatele příliš nezasáhlo. Drb 4 plastika, dcerka, Koncem roku 2003 otevřela Mercury Interactive v Praze pobočku pro Českou republiku a Slovensko, se kterou KOMIX spolupracuje. Plastikou se rozumí změna firemní image. Nové logo, barvy, styl komunikace, už ne Mercury Interactive, ale zkrátka Mercury. Teď, když jsme uvedli na pravou míru všechny drby z autobusové zastávky, je zřejmé, že testování je jen jednou z několika oblastí, na které se Mercury zaměřuje. Na obrázku je schematicky zachyceno rozdělení realizace BTO do 3 oblastí. IT Governance (Center) řeší správu požadavků, plánování zdrojů, finanční a změnové řízení; vše v multiprojektovém režimu. Application Delivery pokrývá oblast testování a ladění výkonnosti softwarových aplikací. Quality Center se zaměřuje na optimalizaci kvality aplikací ve smyslu správné funkčnosti. Převedeno do názvů produktů, jedná se o Test- Director a WinRunner či QuickTest Professional. Této oblasti se KOMIX velmi podrobně věnuje. Kvůli podpoře českého prostředí jsme se společně s jedním naším významným zákazníkem zapojili do beta testování nové verze TestDirectoru. Nová verze je už multiplatformní J2EE aplikace rozšiřující možnosti verze minulé mj. o Business Process Testing. Jedná se o nový modul umožňující uživatelům popsat průběh procesu, jehož funkčnost má být testována. Tento nový modul vyplňuje mezeru mezi chápáním uživatelů nebo analytiků a pohledem testerů na testování aplikace. Performance Center je vlastně LoadRunner se všemi novinkami, z nichž nejzajímavější jsou Tuning module a J2EE Transaction Breakdown. Obě novinky usnadňují lokalizaci klíčového místa pro optimalizaci výkonnosti. Práci s Performance Centrem se KOMIX věnuje nejintenzivněji. Také počet projektů zátěžového testování převažuje nad našimi ostatními Mercury projekty. Application Management se dělí do dvou center Business Availability Center (BAC) a Resolution Center. Věnujme se pouze prvně uvedenému. BAC už není jen Topaz. Právě doplnění o software Appilogu rozvíjí možnosti sledování a řízení infrastruktury a softwarových aplikací o nové funkce umožňující namapovat zhoršení výkonnostních parametrů sledované aplikace na konkrétní část infrastruktury a dokonce doporučit, jak by bylo možné problém odstranit. KOMIX sbírá první zahraniční zkušenosti s implementací BAC. Nasazení BAC ke každodennímu sledování běhu aplikací je dalším logickým krokem po využití Performance Centra pro nastavení výkonnostních parametrů komplexní infrastruktury před uvedením systémů do rutinního provozu. Závěrem lze říci, že přestože novinek a změn je kolem Mercury hodně, KOMIX zůstává svým zákazníkům partnerem pro bezpečnou a úspěšnou optimalizaci podnikové informatiky. Mercury IT Governance Otakar Brabec, brabec@komix.cz Empiricky vedené výzkumy prováděné v posledních letech ukazují na stále se opakující problémy při tvorbě, rozvoji a údržbě informačních systémů. S kterými problémy se řešitelé nejčastěji potýkají? Jsou to především: Nesoulad mezi představou klienta a výsledným řešením Tento problém je způsoben především ve fázi tvorby zadání požadavku na útvar IT nebo dodavatelskou firmu. Riziko nesouladu mezi představami a výsledkem lze minimalizovat nebo dokonce snížit na únosnou mez pomocí nástrojů pro tvorbu a řízení požadavků. Nesprávný odhad lidských, finančních a časových zdrojů Mnoho projektů je zastaveno ještě před dokončením a firma se k nim již nikdy nevrátí. To je důsledek nesprávného plánování a řízení zdrojů. Tento problém se dá řešit pečlivou úvahou ve fázi plánování lidských a finančních zdrojů s přihlédnutím k časovému faktoru. Při přípravě složitých projektů si ani zde nevystačíme s papírem a tužkou. Překročení plánovaných nákladů Podcenění přípravné fáze projektu má zákonitě za následek jeho prodlužování a tím i růst finančních nákladů a dalších ztrát z toho vyplývajících. Jediným řešením je pečlivá předprojektová příprava a stanovení reálného harmonogramu prací včetně kontrolních dnů, kde za účasti zadavatele a řešitele je vyhodnocen reálný stav projektu a na jeho základě jsou přijímána potřebná opatření. Nesprávné stanovení priorit Problém prioritizace požadavků na IT je palčivější ve firmách, kde mají svůj vlastní útvar IT. Z vlastní praxe vím, že každý manažer je přesvědčen o tom, že potřeby jeho útvaru jsou pro firmu nejdůležitější a proto je IT musí okamžitě začít řešit. Zde je potřeba mít vhodný nástroj, který je schopen všechny potřeby zaznamenávat a podle předem daných objektivních kritérií vyhodnotit. Změny v průběhu tvorby informačního systému nebo projektu Neustálé změny v požadavcích na informační systém a neustálé zásahy do zadání projektu zákonitě prodlužují čas potřebný pro konečné řešení, zvyšují náklady a v nejednom případě mají za následek předčasné ukončení projektu. Řada nástrojů na tento problém reflektuje separátním modulem, který řeší Change Management. Podcenění tvorby testovacích skriptů Čím je informační systém nebo projekt složitější, tím větší pozornost musí být věnována přípravě a následnému provádění testovacích prací. Při existenci stále dokonalejších nástrojů, které umožňují provádět systémové, integrační, uživatelské akceptační a zátěžové testy, vystupuje nutnost jejich pečlivé přípravy do popředí analytické činnosti řešitele. Po tomto nepříliš optimistickém úvodu by se zdálo, že vytvořit funkční informační systém nebo alespoň jeho část je nemožné. Není to nemožné, ale snadné to také není. Existuje celá řada softwarových produktů, které řešení této problematiky napomáhají. Jedním z nich je Mercury IT Governance od firmy Mercury Interactive. Mercury IT Governance se skládá z osmi modulů. Moduly jsou integrovány do systému, který využívá jednotnou datovou základnu. Výstupy z jednotlivých modulů jsou určeny pro rozhodovací aktivity managementu firmy. Jedná se o grafické výstupy a statistiky, popisující aktivity jednotlivých útvarů, resp. pracovníků firmy. Mercury ITG není uzavřeným systémem, lze jej integrovat na další softwarové produkty, např. (TestDirector, MS Project, atd.). obr. 1 Moduly Mercury IT Governance Mercury Demand Management (Správa požadavků) Potřeby firem, které jsou nakonec transformovány do požadavků na jejich útvary IT, mají různou povahu, obsah, formu a naléhavost. Největší objem potřeb je rutinního charakteru. Sem patří především údržba a rozvoj stávajícího systému, popř. aplikací a odstraňování provozních chyb. Na druhé straně stojí potřeby koncepčního charakteru. Jedná se o kvalitativní změny provozovaného IS nebo budování nového systému. Demand Management umožňuje konzolidovat a ukládat do centrální databáze všechny firemní požadavky. Provádět prioritizaci a plánovat řešení požadavků na základě uvedených priorit, časových aspektů, přínosů či měření. Podchycuje a kompletuje informace o průběhu řešení pro účely IT auditu. Hlavním přínosem tohoto modulu je podchycení a sledování firemních požadavků v průběhu celého životního cyklu požadavku. Mercury Portfolio Management (Správa portfolia) Portfolio Management nám dává možnost spravovat portfolio IT prostřednictvím vyhodnocování, prioritizace, bilancování a schvalování jak nových činností v rámci IT, tak i stávající portfolio aktivit. Zprostředkovává analýzy různých scénářů a zajišťuje přizpůsobení byznys strategie s omezeními zdrojů umístěných v útvarech IT. Integruje strategická, finanční, funkční a technická měřítka v rámci jednotného procesu řízení. Best practises pomáhají řídit, prosazovat a automatizovat spouštění projektů, minimalizovat rizika a zvyšovat ROI (návratnost investic). Hlavním přínosem tohoto modulu je zachycení stavu IT aktivit v reálném čase a poskytování přesných, průběžně aktualizovaných informací pro rozhodování v oblasti IT portfolia. Mercury Program Management (Správa programu) V úvodu tohoto odstavce je třeba říct, že program v rámci ITG představuje nadřízený celek projektovému řízení. Program je souhrn projektů, které slouží k řešení firemních procesů prostřednictvím IT. Program Management pomáhá v procesu správy a řízení programů počínaje koncepční fází až do fáze kompletace. Umožňuje digitalizaci procesů za účelem řízení rozsahu řešené problematiky, rizika, jakosti a plánování. Výsledkem je komplexní program v nejvyšší kvalitě dodaný v požadovaném čase a v rámci stanoveného rozpočtu. Důležitým prvkem tohoto modulu je PMO (Program Management Office), nástroj pro multiprojektové řízení. Hlavním přínosem tohoto modulu je komplexní monitoring multiprojektových programů a kontrola detailních informací aktuálních projektů v reálném čase. Mercury Project Management (Správa projektu) Řízení projektů je důležitou součástí IT aktivit. Project Management stejně dobře pomáhá při řízení jednorázových projektů, jako např. vývoj komerčních systémů, tak i opakujících se projektů, zejména instalování nových releasů. Umožňuje řešitelům urychlovat dodávky projektových řešení a zároveň snižovat náklady na projekt. V rámci Project Managementu lze sledovat v reálném čase zdroje, procesy, stavy a závislosti jednotlivých procesů. Hlavním přínosem tohoto modulu je, že se uživatel může soustředit na úkoly s nejvyšší prioritou a má jistotu, že sledovaný projekt má k dispozici zdroje, které ke splnění svých cílů potřebuje a to v potřebném čase a místě. Mercury Financial Management (Správa financí) Není třeba zdůrazňovat, že dostatek či nedostatek finančních zdrojů hraje klíčovou roli při schvalování projektových plánů a jejich následné realizaci. Mnoho dobrých projektů se neuskuteční právě proto, že na jejich realizaci není v potřebný čas potřebné množství peněz. Finance Management nabízí automatické propočty finančních nákladů v reálném čase, jejich sledování a porovnávání s plánovanými hodnotami. To velmi pomáhá při stanovení a řízení rozpočtů v rámci IT, počínaje fází projektových nabídek, ověřování, revize, až po fáze prvotního spuštění, nasazení a realizace přínosů. Správa financí umožňuje 3

4 pokračování ze strany 3 kontrolu rozpočtů a nákladů v reálném čase s minimálními výdaji. Hlavním přínosem tohoto modulu je zefektivnění rozhodovacího procesu v rámci IT, kontrola a celkové snižování nákladů. Mercury Resource Management (Správa zdrojů) Tak jako peněžní zdroje hrají při vývoji IS velkou úlohu, tak i lidské zdroje, jejich dosažitelnost a vhodné nasazování mohou být příčinou úspěchu či neúspěchu v rámci IT aktivit. Resource Management se zaměřuje na efektivní řízení lidských zdrojů a jejich alokaci. Je nástrojem, který umožňuje manažerům přijímat správná rozhodnutí při řízení lidských zdrojů. Poskytuje aktuální informace ohledně schopností disponibilních lidských zdrojů, jejich alokaci v čase a využívání, včetně vyčíslení nákladů na tyto zdroje. Hlavním přínosem tohoto modulu je možnost plánování a alokace lidských zdrojů na různém stupni podrobnosti, počínaje globální úrovní v rámci celého IT a konče detailní úrovní konkrétního úkolu v rámci konkrétního projektu. Mercury Change Management (Správa změnového řízení) Častou příčinou neúspěchu při řešení firemních požadavků je nesoulad mezi představami zadavatele a řešitele. K odstranění tohoto rizika je účelné použití softwarového produktu, který nabídne formalizovaný zápis požadovaných změn a sledování jejich řešení. Change Management řeší plánování změn, tvorbu programových balíčků, tvorbu a nasazování releasů v rámci aplikačního portfolia. Snižuje riziko při nasazování robustních systémů a těch systémů, které mají složité vazby na okolní systémy nebo aplikace. Umožňuje automatizaci migrace a nasazování nových verzí softwarových řešení. Hlavním přínosem tohoto modulu je možnost přesného vytýčení problematiky v rámci změnového řízení a možnost návratu k předchozí verzi systému. Mercury Time Management (Správa časové využitelnosti zdrojů) Time Management má za úkol sledovat rozmisťování lidských zdrojů a jejich využití v rámci jednotlivých projektů. Je spojovacím můstkem mezi plánováním jednotlivých úkolů a sledováním jejich skutečné časové náročnosti. Synchronizuje jednotlivé úkoly, jejich časovou náročnost a využití potřebných lidských zdrojů v rámci celého spektra činností v IT oblasti. Hlavním přínosem tohoto modulu je možnost přesného sledování skutečného využívání lidských zdrojů, což vede k jejich hospodárnému obr. 2 Procesy Mercury IT Governance využití a minimalizaci časových ztrát v průběhu prací na projektu. Mercury IT Governance je velmi rozsáhlý systém, který není nutné implementovat jako celek. Možnosti dílčí implementace, které podporují činnosti jednotlivých útvarů a tedy i skupin uživatelů ukazuje následující tabulka. Jednotlivé funkčnosti systému jsou vztaženy k uživatelským rolím. tab. 1 Možnosti nasazení jednotlivých modulů Mercury ITG je robustní systém vhodný zejména pro větší firmy, které jsou odhodlány řešit IT portfolio komplexně. Vzhledem ke své cenové náročnosti se nehodí pro menší firmy, kde je nedostatek financí a lidských zdrojů potřebných pro jeho implementaci a správu. Implementaci Mercury ITG musí provádět firma, která má s tímto software zkušenosti, dovede provést úvodní analýzu před implementací Mercury ITG a doporučit zákazníkovi nasazení vhodných modulů a vytvoření vazeb mezi nimi. Společnost KOMIX dlouhodobě spolupracuje s firmou Mercury a je schopna systém Mercury ITG implementovat. Strategie pro ČSÚ V rámci národních programů Phare pro rok 2004 byl definován projekt IT and Dissemination Strategies Study, který měl přispět ke zlepšení strategického řízení vybraných oblastí v rámci Českého statistického úřadu (dále ČSÚ). Jsme rádi, že vám můžeme oznámit, že v konsorciu s německou společností GOPA jsme se na tomto projektu v tomto roce podíleli i my, společnost KOMIX s.r.o. Vstup ČR do EU byl tedy u nás doprovázen účastí na významném strategickém projektu s mezinárodní účastí. Co bylo předmětem projektu? Jak je z názvu projektu zřejmé, šlo o vytvoření strategie ČSÚ v oblasti IT a šíření (dissemination) statistických informací. Proces produkce statistických informací zahrnuje tři základní fáze sběr, zpracování a právě šíření informací. Při sběru jsou od respondentů získávána vstupní data, která jsou v rámci následující fáze zpracována statistickými procedurami. Výstupní statistické informace jsou pak různými kanály šířeny uživatelům. Informační technologie jsou kritickým nástrojem v rámci celého procesu. Z pohledu IT IT and dissemination strategies Sběr dat tedy předmětem zájmu celý proces produkce statistických informací. Z hlediska věcného obsahu jsme se zaměřili na závěrečnou fázi, tj. jak co nejefektivněji pokrýt potřeby uživatelů statistických informací. Hlavním cílem projektu bylo umožnit ČSÚ plnění jemu přidělených úkolů s podporou IT Zpracování dat moderních informačních technologií. Strategické návrhy, které byly v rámci projektu definovány a které vedou k naplnění tohoto cíle, patří především do těchto oblastí: webová prezentace ČSÚ nová koncepce IS statistické registry metainformační systém veřejná databáze statistických informací moderní technologie sběru dat projektová metodika IT bezpečnost Organizace, spolupráce, komunikace Pro práce na projektu byl sestaven velmi kvalitní tým. Společnost KOMIX do něj obsadila odborníky v oblasti informačních technologií a statistiky. Za společnost GOPA byli vybráni dva nezávislí experti v oblasti statistiky a šíření statistických informací. Nezastupitelnou úlohu v projektu hráli vybraní pracovníci ČSÚ, kteří Šíření statistických informací se projektových prací aktivně účastnili. Tým byl koncipován tak, aby znalosti a zkušenosti jeho členů pokryly celou věcnou oblast. Praxe ukázala, že to byla dobrá volba. Za velmi důležité považujeme správné rozdělení odpovědností jednotlivých členů týmu. Jde o projekt realizovaný v české organizaci v českém prostředí. Zástupci KOMIXu byli v tomto ohledu odpovědni za veškeré činnosti, které vyžadují znalost tuzemských podmínek. Sem patří například analýza právního rámce vytvářené strategie, která znamenala prostudování řady právních norem, směrnic, vyhlášek apod. Patří sem však i řešení organizačních problémů jako je vytváření pracovního zázemí pro zahraniční členy týmu nebo podpora při zdolávání jazykové bariéry. Zahraniční experti naopak přinesli do pracovního týmu znalost prostředí statistických úřadů vyspělých evropských zemí, zkušenosti z práce pro EUROSTAT a řadu dalších poznatků z projektů obdobného zaměření a potřebný odstup. Členové projektového týmu ze strany ČSÚ spolupracovali na všech činnostech vyžadujících dobrou znalost prostředí ČSÚ. Jejich přínos byl pro úspěch projektu kritickým faktorem. Podíleli se na plánování projektu, analýze současného stavu, formulaci a hodnocení strategických návrhů a například i na organizaci workshopů. Projekt začal na začátku února tohoto roku a dle projektového plánu trval pět a půl měsíce. Od začátku projektových prací jsme si uvědomovali, že nás čeká hodně práce v poměrně intenzivním režimu, abychom vše v plánovaných termínech stihli. Bylo nám i jasné, že dobrou strategii nelze definovat pouze v teple analytické kanceláře. V průběhu projektu bylo uspořádáno téměř padesát pracovních schůzek a workshopů, v rámci kterých jsme se setkali s více než třiceti pracovníky ČSÚ a organizací, s nimiž ČSÚ spolupracuje. Nakonec jsme projekt úspěšně zakončili v plánovaných termínech. Významným faktorem úspěchu bylo racionální plánování. Projekt byl odstartován s velmi dobrým projektovým plánem. Díky zkušenostem společnosti GOPA z projektů obdobného typu, bylo vše naplánováno poměrně detailně. Pro dosažení definovaných cílů byla definována množina aktivit, jejich zdroje, vstupy, výstupy, návaznosti, schůzky a workhopy, které se v rámci jednotlivých aktivit měly konat. Kvalitu projektového plánu dokazuje skutečnost, že nemusel být v průběhu projektu významně upravován. Postup aneb praxe blízká teorii Tomáš Hrubý, hruby@komix.cz Práce na tvorbě strategie byla rozdělena do třech hlavních etap. V první etapě byla popsána současná situace v předmětné oblasti. Tento popis byl prováděn z několika pohledů (tzv. multidimenzionální popis). Byl analyzován legislativní rámec do kterého jsou činnosti ČSÚ zasazeny, popsáno organizační uspořádání ČSÚ i státní statistické služby jako celku, analyzovány globální strategické záměry, popsán proces produkce statistických informací, využívané metodologické nástroje, SW a HW architektura atd. V druhé etapě byl proveden návrh budoucího stavu bylo provedeno srovnání ČSÚ se statistickými úřady vyspělých zemí, analyzovány budoucí potřeby uživatelů statistických informací, definovány konkrétní návrhy v oblastech sběru a zpracování dat, šíření statistických informací, bezpečnosti, statistických registrů apod. Všechny výstupy byly průběžně předkládány zástupcům ČSÚ k připomínkování, případně prezentovány a diskutovány na společných workshopech. Na základě společného konsensu byl v třetí etapě sepsán finální produkt strategie v oblasti IT a šíření statistických informací. Pro postup tvorby informační strategie i podobu tohoto dokumentu jako finálního produktu existuje řada obecně přijímaných teoretických principů. Jak byl postup uplatněný při tvorbě informační strategie pro ČSÚ upraven pro použití v podmínkách našeho projektu? Liší se nějak výsledná informační strategie jako produkt uplatněného postupu od ideálního teoretického produktu? Téměř všechna teoretická doporučení jsme dodrželi. V některých oblastech jsme však přistoupili k určitým modifikacím postupu a následně i obsahu vlastního dokumentu. Hlavním důvodem byly specifické podmínky, které tvorbu informační strategie provázely. Za významné specifikum lze považovat samotnou věcnou oblast, ve které se organizace pohybuje tou je statistika jako věda a statistická práce jako její aplikace v praxi. Množství času, které bylo na projekt alokováno, bylo také významným faktorem, který vedl k určitým restriktivním úpravám postupu. Klíčovým vodítkem, které určovalo co a jak se bude dělat, byly samozřejmě potřeby a přání zástupců zákazníka ČSÚ. Výsledná informační strategie se soustřeďuje především na pragmatické oblasti, řešení problémových míst a slabé stránky oblasti IT. Cílem 4

5 pokračování ze strany 4 bylo vytvořit použitelný dokument, nikoliv rozsáhlý román, který by pak skončil na dně nějakého šuplíku. Ve výsledném textu proto nenajdete budoucí komplexní popis struktury IS/IT architektury ze všech teoreticky možných pohledů, ale najdete v něm například to, jaký projekt je nutné realizovat pro řešení problematické situace v oblasti metainformačního systému. Využité analytické metody, nástroje a techniky Vytvoření strategie není snadný úkol. Naopak jde o značně komplexní náročnou práci vyžadující projektovou formu. Je nutné myšlenkově pojmout celou předmětnou oblast, stále mít na paměti hlavní cíle, vize a jejich priority, zohlednit řadu externích faktorů jako jsou nové trendy a technologie, zapojit kreativitu a při tom se vyhnout rizikům projektu. Tyto úkoly nám pomáhala zvládat řada analytických nástrojů a technik. Velmi se nám osvědčila např. metoda logického rámce, která slouží pro strukturovanou definici zadání úkolů, činností či celých projektů. Z dalších nástrojů, které nám významně usnadnily práci a zvýšily kvalitu výstupu, lze jmenovat procesní diagramy, SWOT analýzu nebo problémové stromy. Co významně ovlivnilo průběh projektu? Tak jako u jiných projektů i v rámci našeho projektu jsme se potýkali s řadou problémů a okolností, z nichž některé měly na průběh projektu významný vliv. Zmínit je třeba především legislativní prostředí, ve kterém byla strategie vytvářena. Všechna doporučení a strategické návrhy samozřejmě musí být v souladu s právními normami, a to jak České republiky tak EU, které jsme se stali členem. Problémů zde bylo několik. Za prvé bylo třeba se vypořádat s poměrně nestabilním právním prostředím. V souvislosti se vstupem do EU i z jiných důvodů byly mnohé, pro náš projekt významné zákony v procesu novelizace, případně byly a stále jsou připravovány zákony nové (v průběhu projektu byla schválena i novela klíčového statistického zákona 89/1995 Sb.). Problémem byl i samotný obsah některých právních norem, který ne vždy odpovídal naším představám a řešit jsme museli i otázku souladu našich zákonů se zákony EU. Dalším významným faktorem byla určitá komunikační jazyková bariéra daná účastí zahraničních expertů. Projektovým jazykem byla samozřejmě angličtina. Začátek projektu nebyl snadný i pro členy projektového týmu. Společné workshopy s větším počtem pracovníků ČSÚ probíhaly za účasti překladatele. Kdo chtěl promluvit česky, mohl. Tento přístup jsme shledali jako velmi přínosný, ačkoliv se zdánlivě ve stanoveném čase stihlo prodiskutovat méně. S porozuměním anglicky mluvenému projevu nebyl problém, avšak povinnost aktivního vyjadřování mnohdy složitých myšlenek v angličtině by pro některé pracovníky mohla být brzdou komunikace. Závažnou otázkou, se kterou jsme se museli vypořádat, byla návaznost našeho výstupu jako jedné z dílčích podnikových strategií na globální strategické cíle ČSÚ. Projekt, v rámci kterého měly být tyto cíle definovány, byl shodou okolností načasován tak, že běžel s naším projektem paralelně. Přitom je zřejmé, že naše výstupy musely být podřizovány tomuto projektu, nikoliv naopak. Znamenalo to průběžné monitorování definice globálních strategických cílů a vizí a korigování našich aktivit a výsledků. Velmi pozitivně hodnotíme spolupráci zástupců ČSÚ, z nichž někteří věnovali práci na projektu významnou část svého času, ačkoliv je jinak plně vytěžovaly jejich běžné pracovní úkoly. Toto platí dvakrát o závěrečné fázi projektu, kdy vrcholily přípravy na volby do Evropského parlamentu, za jejichž zpracování je ČSÚ ze zákona odpovědný. Projekt vytvoření strategie v oblasti IT a šíření statistických informací v ČSÚ není prvním významným projektem v oblasti IT strategií a návrhu architektury informačního systému, na kterém se naše společnost podílela. Představuje pro nás další nárůst zkušeností z mezinárodních projektů, kde bychom v budoucnu i nadále rádi působili. Úspěch spolupráce s německou společností GOPA byl impulsem, který odstartoval přípravu dalšího projektu ve společném konsorciu. Věříme, že výsledky projektu budou představovat dobrý podklad strategického řízení. Podpořte své pojišťovací agenty a obchodní kanály Jana Hamadová, Jan Rádl hamadova@komix.cz; radl@fss.cz Na počátku byly dlouholeté zkušenosti s pojišťovnictvím, znalost problémů ke kterým dochází v každodenním životě v pojišťovně a zkušenosti s různými tuzemskými i zahraničními informačními systémy pro danou oblast. To všechno vedlo k vytvoření systému eims (e-insurance Management System) a k vyvinutí metodiky jeho nasazení. V článku se zabýváme významnými vlastnostmi software a způsobu jeho implementace ve vztahu k řešení řady problémů v pojišťovnách a makléřských firmách. Problém jménem provoz pojišťovny Prvním podnětem pro vznik systému byla nutnost řešit samotný počátek vzniku pojistných smluv resp. návrhů pojistných smluv. Každý, kdo si v pojišťovně odseděl jen několik měsíců, musel alespoň jednou denně zaslechnout nářky obchodníků nebo makléřů, kteří si stěžovali na opožděné provize, nevyplacené škody, ztracené smlouvy atd. Je nesmírně složité probírat se stovkami smluv v papírové podobě a dohledávat chyby nebo nesrovnalosti, které se tam v průběhu sjednání nebo typování zanesly. Systém eims umožňuje dotáhnout nabídku pojistné smlouvy až do finální pojistné smlouvy resp. návrhopojistky a přenést ji až do samotného provozního systému. Tímto krokem se podaří eliminovat hned několik příčin chybovosti: chyby ve výpočtu, chyby plynoucí z povinnosti údajů ve smluvním vztahu mezi pojistníkem a pojistitelem, chyby způsobené při ručním přetypování smluv resp. návrhů, chyby způsobené pozdním natypováním či ztrátou smluv resp. jejich návrhů. Bez informací nelze řídit Dalším podnětem byla potřeba vedení obchodu a pojišťovny jako takové mít dostatek informací o produktivitě práce jednotlivých prodejních kanálů resp. agentů vlastní prodejní sítě a hlavně o prodejnosti a rentabilitě pojistných produktů. Neflexibilní systémy vedou často k mylné představě o tom, které že to produkty si žádá trh. Má-li vedení pojišťovny dostatek informací (počty, pojistné částky atd.) o nabídkách, smlouvách, návrhopojistkách, které jsou agenty resp. makléři sjednány, potažmo nabídnuty a pokud tyto informace jsou včasné a úplné, může pružně reagovat na potřeby trhu na základě faktů a ne na základě informací typu jedna paní povídala. Bez spolehlivých dat a bez adekvátních kontrolních procedur, které zabezpečí přesnost dat, se jeví oddělení controllingu jako ztracená jehla v kupce sena. Systém eims umožňuje shromažďovat kompletní informace o celém průběhu životního cyklu pojistné smlouvy nebo nabídky a součástí komplexního řešení systému je vlastní OLAP modul. Různost prodejních kanálů Třetím podnětem byla problematika odlišných požadavků na funkčnost SW pro podporu prodeje pro různé prodejní kanály. Odlišné požadavky distribučních kanálů na funkčnost systému vycházejí z několika základních skutečností: 1. Úroveň znalostí prodávaných produktů má vliv na vzhled a funkčnost uživatelského rozhraní. To musí být tím intuitivnější a obsahovat co možná nejméně možností voleb (přednastavené default hodnoty, zjednodušené produkty atd.), čím je obsluha méně znalá problematiky prodeje pojištění. 2. Odlišné prostředí ve kterém se produkty nabízejí souvisí s použitou technologií, která zpřístupňuje aplikaci. Pro obchodní kanály například typu bankovní přepážky, kde předem neznáme bezpečnostní politiku a kde nebudou užívány všechny moduly aplikace, je vhodné použít HTML rozhraní přístupné přes libovolný web prohlížeč. Naopak v případech, kdy obchodník bude používat i sofistikované funkce jednotlivých modulů, je dobré použít některou z možností tzv. rich clients realizovaných v Java Swing, C++ nebo jiných komponentách. Takovým kanálem je typicky vlastní obchodní síť nebo vlastní pobočková síť. 3. Různost produktových řad je důležité brát na zřetel v případě, že pro některé prodejní kanály (např. prodejní kanál Autosalony ) je vhodné vybrat jen určitou škálu pojistných produktů, které mohou být navíc přesně upraveny na podmínky jednotlivých typů prodejců (nová auta, ojetiny, Renault, Škoda atd.). 4. Rozdílná motivace prodeje pojištění souvisí rovněž s uživatelským rozhraním. Agent vlastní prodejní sítě má odlišnou motivaci uzavřít pojistnou smlouvu správně a hlavně s tou pojišťovnou pro kterou pracuje než autoprodejce, který prodává pojištění pro dalších pět pojišťoven. To vyžaduje, aby uživatelské rozhraní pro méně motivované prodejní kanály bylo co možná nejjednodušší a vedlo prodejce k uzavření pojistné smlouvy s co nejmenším počtem kliků a s co možná největším počtem SW kontrol omezujících podmínek pojistného produktu. Systém eims je proto konstruován tak, aby umožňoval definovat odlišné prodejní podmínky pro jednotlivé prodejní kanály resp. sítě. Specifika makléřského obchodu Makléř zabývající se prodejem finančních produktů je vždy vystaven problému jak nabídnout klientovi rychle a spolehlivě optimální variantu produktu. Není efektivní, aby makléř pracoval s pěti různými aplikacemi od pěti různých pojišťoven. Ideálním řešením je jeden systém, který umožní nabídky vytvářet pod jedním uživatelským rozhraním bez nutnosti přetypovávání stejných údajů pro různé pojistitele. Systém eims umožňuje implementaci rozdílných finančních produktů a tvorbu nabídek stejných produktů od různých poskytovatelů. Jak vypadá systém eims? Systém eims se skládá z licencovaného jádra eims Engine, aplikace vyvinuté nad tímto jádrem a databáze. Celé řešení je postaveno jako modulární systém, kde každý jednotlivý modul může pracovat samostatně, přičemž je zachována těsná spolupráce mezi jednotlivými moduly. Tyto moduly v souhrnu řeší celou problematiku nabídky, sjednání a správy pojistných smluv včetně všech vazeb do finančního účetnictví, zajištění, provizního systému, inkasa, exkasa a jiných systémů. 5

6 pokračování ze strany 5 Funkčnost eims Engine umožňuje implementovat libovolný pojistný produkt nebo vytvářet modifikace z produktů již implementovaných. Tuto vlastnost využijí především produktoví a obchodní manažeři. Oddělená prezentační vrstva umožňuje ušít na míru uživatelské rozhraní modulů pro konkrétní pojišťovnu či jednotlivé prodejní kanály pojišťovny. Systém eims je vytvořen jako vícejazyčný, takže není velký problém přejít na jiný jazyk. Volba jazykové mutace pro konkrétního uživatele se provádí v nástrojích určených pro správu systému eims, tj. bez zásahu do aplikace nebo Engine eims (za předpokladu, že je v systému implementován příslušný slovník). Všechna data jsou uložena v jedné databázi, což umožňuje veškerý možný komfort z toho plynoucí. Řešení eims je připraveno na integraci s již existujícími centrálními informačními systémy. Co dostanu, když si pořídím systém eims? Velmi stručně řečeno komplexní řešení přizpůsobené na míru včetně nezbytných služeb a následné technické podpory provozu systému eims. Protože je systém již vytvořen, je nutné realizovat jen takové postupy, kterými se eims v průběhu projektu implementace upraví na míru podle specifických požadavků konkrétní pojišťovny. Samotná existence softwarového řešení však ještě nezaručuje, že bude systém efektivně využit. Kvalita a efektivnost implementace eims je klíčovým faktorem dlouhodobého přínosu systému. Implementaci eims provádí specializovaný projektový tým KOMIXu, který používá specifické metody a postupy. Specifické projektové řízení Zaměřujeme se na faktory, které mají zásadní vliv na implementaci a na využití eims v konkrétní pojišťovně. Z pohledu týmu KOMIXu není nutné, aby zadavatel vytvářel rozsáhlé detailní zadání, které je náročné na čas a kapacity specialistů pojišťovny. Ideální je realizovat informační schůzku před zahájením tvorby poptávkového dokumentu následovanou například předvedením eims. Výsledkem by mělo být objasnění cílů zadavatele a jeho představy, jak by eims měl tyto cíle podpořit. Konkrétní návrh řešení zpracuje tým KOMIXu do nabídkového dokumentu. Při tvorbě plánu projektu preferujeme přírůstkovou implementaci a rozvoj systému eims dle rozvoje potřeb zadavatele. V případě velkého počtu pojistných produktů nebo při požadavcích na rozsáhlou funkcionalitu či větší počet prodejních kanálů je proto projekt rozdělen na dílčí projekty, které zajistí realizaci samostatně provozuschopných částí systému eims. Zadavatel tak rychleji získá výstupy na jejichž základě může korigovat další implementaci nebo rozvoj systému dle své aktuální situace. Jsme si vědomi skutečnosti, že členové projektového týmu na straně pojišťovny budou v průběhu projektu současně plnit své běžné pracovní úkoly. Organizační struktura projektu je vždy navržena s ohledem na tuto skutečnost. Pravidla a formy komunikace členů projektového týmu jsou stanovena tak, aby se minimalizovaly časové prodlevy a zároveň se zabezpečila odpovídající dostupnost sdílených informací a možnost průběžné kontroly stavu a postupu projektu. Specifický projektový postup Využíváme vlastností systému eims k efektivnímu získání informací nezbytných pro cílové řešení. Prvním krokem je analýza jednoho pojistného produktu a jeho implementace do systému eims. Tím je realizován prototyp na jehož základě se provádějí další úpravy eims. Zadavatel tedy pracuje již při zadávání požadavků s reálným systémem. Funkční prototyp umožní zapojit do zadávání požadavků i koncové uživatele. Implementace jednotlivých pojistných produktů a úpravy funkčnosti systému eims dle potřeb zadavatele se provádí postupně. Po dokončení implementace každé dílčí části je v pojišťovně proveden upgrade prototypu. Zadavatel tak může velmi rychle ověřit a korigovat své zadání. Zároveň lze prototyp využít při postupném zaškolování administrátorů či uživatelů. Specializovaný projektový tým Tým KOMIXu je tvořen specialisty, kteří mají dlouholeté praktické zkušenosti jak z hlediska problematiky pojišťoven (provoz, informatika, obchod, pojistná matematika atd.), tak z hlediska informačních technologií či projektového řízení. Naši specialisté se velmi rychle orientují v prostředí zadavatele, nejsou problémy s odbornou terminologií, minimalizují se komunikační problémy. Řada detailních požadavků nemusí být složitě analyticky popisována, protože komunikace probíhá často na úrovni jednotlivých specialistů, kteří jsou požadavky schopni bezprostředně realizovat v prototypu systému eims a výsledek následně ověřit se zadavatelem. Pro koho je systém eims vhodný? Systém eims není zaměřen pouze na podporu prodeje pojistných produktů, ale na komplexní finační retail, do kterého můžeme zahrnout i stavební spoření, penzijní produkty, drobné úvěry atd. Má své místo nejen v pojišťovnách, ale lze jej využít i v oblasti makléřských obchodů. Závěrem Naše zkušenosti z minulých let strávených v pojišťovnách a nepřetržité sledování rozvoje této oblasti umožnily našemu týmu realizovat řadu vlastností, které činí systém eims rozdílným od podobných systémů nejen na našem, ale i zahraničním trhu. Systém eims je efektivní flexibilní systém, který umožňuje řešit stále náročnější požadavky na úplnost a spolehlivost dat. Podporuje prodej a správu pojistných či obdobných finančních produktů. Odhadujete pracnost projektu? Tomáš Vahalík, vahalik@komix.cz V počátečních fázích vývoje IS, kdy o požadovaném systému máme málo informací, je problém správného odhadu nejpalčivější. Ale právě tyto předběžné odhady jsou požadovány pro vypracování nabídky a uzavření smlouvy nebo při rozhodování o výhodnosti realizace projektu vlastními silami. V poslední době je stále rozšířenější use case driven přístup k vývoji softwaru, do češtiny překládaný jako přístup řízený případy použití. Nejznámějším představitelem use case driven metodik je metodika RUP (Rational Unified Process). Use case model je jeden z modelů podporovaných UML. Popisuje chování systému z pohledu interakcí uživatele se systémem při dosahování určitého cíle. Use case model je jednotícím pohledem na systém od fáze popisu funkčních požadavků, přes design až po testování a uživatelskou dokumentaci. Use case model obsahuje textovou specifikaci uživatelských požadavků v pojmech, kterým uživatel rozumí. Proto je vhodné v počátečních fázích vývoje pro odhad pracnosti projektu použít metodiku založenou právě na use case. Protože use case model je často používaná technika pro popis funkčních požadavků, dalo by se předpokládat, že často používána a rozšířená bude i metoda pro odhad pracnosti založená na use case. Podle [1],[2] tomu tak však není. Příčiny jsou pravděpodobně následující: existuje mnoho variant specifikace use case use case mohou reprezentovat pohled uživatele na systém na různých úrovních abstrakce use case stejné úrovně abstrakce se mohou lišit v komplikovanosti popisu a realizace V tomto článku se podrobněji seznámíte s jednoduchou metodu založenou na use case points (UCP), která je obzvlášť vhodná na těch projektech, kde use case vznikají jako přirozený artefakt procesu vývoje softwaru. V kapitole Postup odhadu metodou UCP, kde je tato metoda podrobněji popsána, naleznete odkaz na jednoduchý tabulkový kalkulační program a plug-in do CASE nástroje, který si můžete stáhnout a odhad touto metodou vyzkoušet. Nejprve ale několik základních informací o odhadování velikosti softwaru: Techniky odhadu pracnosti Dominantní a klíčovou složkou nákladů na pořízení informačního systému jsou náklady vyplývající z pracnosti vývoje (náklady na mzdy vývojového týmu, na jejich kanceláře, sítě a komunikace, pojištění, daně). Ze všech ostatních složek nákladů (jako např. cena hardware, licenční poplatky za software, školení atd.) se právě pracnost nejhůře odhaduje. Existují 3 kategorie technik přístupu k odhadu velikosti a ceny softwaru: Expertní odhady Analogie Odhady založené na modelu V každé z těchto kategorií může být odhad proveden postupem shora-dolů nebo zdola- -nahoru, tj. celek je součtem odhadů pro jednotlivé komponenty nebo naopak, pracnost komponenty je odhadnuta jako podíl z celku. Při odhadu by se měly kombinovat různé techniky. Pokud se odhady získané různými technikami výrazně liší, je nutné pokusit se získat více informací a odhad zopakovat. Podle studií citovaných v [7] je expertní odhad nejčastějším způsobem odhadu, bývá používán v % případů. Důvodem upřednostnění expertního odhadu může být složitost formálních metod založených na modelu. Dalším důvodem je neexistence přesvědčivých důkazů, že formální metody vedou k lepším výsledkům než expertní odhady (viz [8]) i když např. podle studie [5] dal odhad metodou UCP výsledky bližší skutečnosti, než odhad provedený 37 experty. Expertní odhady Tato technika vychází z odhadu provedeného expertem, podloženém předchozími zkušenostmi. Expertní odhad je užitečný především tam, kde nemáme měřitelná data, ze kterých by bylo možné vycházet. Nevýhodou je, že tato metoda je jen tak dobrá, jak dobrý je expert. Čím více expertů provádí odhad, tím jsou výsledky odhadu objektivnější. Podle [6] je důležitou podmínkou expertního odhadu, aby odhadce neznal očekávání zákazníka, protože tento fakt výrazně ovlivňuje expertův odhad (i podvědomě). Při expertním odhadu lze vyjít například ze znalosti, že fáze Analýza je 20% celkové pracnosti. Na základě znalosti požadavků a problémové oblasti může expert odhadnout pracnost analýzy. Vynásobením 5 (5x20% = 100%) potom získá odhad celkové pracnosti. V tomto příkladu jsou zanedbány faktory konkrétních podmínek projektu. Rozdělení pracnosti na jednotlivé činnosti se může lišit pro různé organizace, může být závislé na technologii a na použitých nástrojích, na charakteru projektu. Pro představu uvádím data podle [9]. 18 % Rozdělení pracnosti 8 % 7 % 34% 16 % obrázek 1: Rozdělení pracnosti Analogie 17 % Při této technice jde o odhalení rozdílů a podobností s podobnými projekty a o odhad vlivu těchto rozdílů na pracnost. Nevýhodou je, že musíme mít data o obdobných projektech (to, že jsme dělali analogický projekt, ještě neznamená, že o něm máme data). Odhady založené na modelu Na základě velkého množství dat o skutečných projektech a jejich charakteristikách byly vyvinuty modely závislosti velikosti projektu na pracnosti. Jedná se o algoritmy, které na základě nějaké měřitelné vstupní hodnoty (velikosti projektu) vypočítají výstupní hodnoty (pracnost, trvání projektu). Výpočet ovlivňuje mnoho faktorů (tzv. cost drivers ), které jsou zadávány subjektivně v definované škále (např. zkušenosti programátorů velmi dobré, dobré, průměrné atd.). Nejznámějšími algoritmy jsou COCOMO a Function Point Analysis (FPA). Žádný z těchto přístupů není vhodný k odhadu prováděném ve fázi požadavků, nejsou ani příliš vhodné pro systémy vyvíjené objektově orientovaným přístupem. COCOMO vyžaduje odhad počtu zdrojových řádků vyvíjeného systému. FPA má výhodu v tom, že jako měřítko složitosti používá funkční body, nikoli počet řádků kódu. Získat ale spolehlivě počet FP není triviální, je to možné ve fázi detailního návrhu, ale to je už pozdě, to už je smlouva zpravidla uzavřena a cena stanovena. Existují i další techniky odhadu ceny a pracnosti, které jsou v praxi často používány, nejsou však objektivní. Jedná se o tyto techniky : Analýza Detailní návrh Kódování a jednotkové testy Integrační a sytémové testy Dokumentace Instalace a nasazení Pricing to win Cena softwaru je stejná částka, jakou může zákazník utratit za projekt. Cena je závislá nikoli na funkcionalitě dodávaného softwaru a z ní odvozené pracnosti, ale pouze na zákazníkově rozpočtu. Skutečnou pracnost potom často zákazník doplatí například při zapracování dalších požadavků (náklady na údržbu a rozvoj systému dosahují i více než polovinu z celkových nákladů na celý životní cyklus IS). Parkinsonův zákon Podle tohoto zákona bude pracnost taková, že spotřebuje všechny dostupné zdroje a čas. Pokud má být projekt dokončen nejpozději do jednoho roku a k dispozici jsou 4 pracovníci, celková pracnost bude 48 člověko-měsíců. Přesnost odhadu Přesnost odhadu bývá problematická. Například Standish Group ve svém CHAOS Report uvádí, že průměrné náklady na projekt představují 189 % původního odhadu, pouze 17 % projektů je ukončeno v plánovaném čase a s plánovanými náklady (u menších projektů pro menší společnosti jsou výsledky lepší). Podle Gartner Group až 75% J2EE projektů na rozsáhlé podnikové systémy končí neúspěchem kvůli nerealistickým odhadům časových a finančních nároků. Otázkou je, nakolik jsou čísla z podobných studií odrazem přesnosti odhadů nebo faktu, že původní odhady jsou prováděny technikou Pricing to win. Další příčinou možného zkreslení je skutečnost, že nejčastěji je citováno z těch studií, ve kterých je nepřesnost 6

7 pokračování ze strany 6 odhadů největší. Tyto údaje jsou potom používány jako marketingový materiál pro výrobce softwarových nástrojů na odhad pracnosti nebo pro výrobce nástrojů na generování kódu a zvyšování produktivity vývoje (nebo jsou citovány v článcích, jako je tento). Často citovaný zdroj se potom stává autoritou. Bez ohledu na možná zkreslení faktem zůstává, že odhad pracnosti zvláště v počátečních fázích vývoje je obtížný. Proto by odhad pracnosti měl být průběžný proces, měl by sloužit průběžné kontrole, že práce na projektu odpovídá plánovaným zdrojům. Ke zpřesnění odhadu dochází v průběhu projektu nejen proto, že víme více detailů o požadovaném chování vyvíjeného systému, ale i z toho důvodu, že na základě předchozích přírůstků víme více i o produktivitě konkrétního vývojového týmu a o produktivitě zvolených technologických postupů. 4x 2x 1x 0,5x 0,25x Úvodní studie Návrh Požadavky Programování obrázek 2: Zpřesňování odhadu Nelineární závislost problémy vyplývající z nereálného plánu Podhodnocení < 100 % x = skutečná pracnost V průběhu práce na projektu je k dispozici stále více informací a odhady jsou přesnější Čas Nesprávný odhad se projeví ve zvýšené pracnosti projektu oproti situaci, kdy projekt byl naplánován realisticky. V případě nadhodnocení pracnosti jsou podle Parkinsonova zákona spotřebovány všechny dostupné zdroje, v případě podhodnocení prudce rostou náklady způsobené nerealistickým plánem a zvýšeným výskytem chyb (práce kvapná, málo platná). obrázek 3: Dopad správnosti odhadu Předání Karnerova metoda Use Case Points Cena Pracnost Termíny 100 % V roce 1993 Gustav Karner vyvinul metodu odhadu založenou na use case points. Jednalo se o diplomovou práci na švédské University of Linköping. Copyright na tuto práci nyní vlastní Rational Software. Karnerova metoda vychází z teze, že funkcionalita systému z pohledu uživatele je základem pro odhad Lineární závislost viz. Parkinsonův zákon Odhad jako procento skutečné pracnosti Nadhodnocení > 100 % velikosti informačního systému. Karnerova metoda je často citována a rozvíjena, existují práce kombinující function points (FP) a use case points (UCP), konverze UCP na FP nebo práce o konverzi UCP na řádky zdrojového kódu (LOC) viz [3]. Postup odhadu metodou UCP Nejprve musíte zjistit počet aktorů a počet use case. Use case zařadíte do kategorie složitosti (jednoduchý, střední, složitý) podle počtu transakcí (počet transakcí může být odvozen z počtu kroků popsaných ve scénáři). Někteří autoři doporučují vynechat use case typu extends a includes. Podle kategorie složitosti přiřadíte jednotlivým use case váhu. Metoda UCP používá obdobné modifikační faktory jako metoda analýzy funkčních bodů. Dále tedy musíte ohodnotit dílčí technické faktory a faktory prostředí stupněm 0 (nemá vliv) až 5 (silný vliv). Tyto faktory se týkají konkrétního projektu. Dosazením do Karnerových vzorců získáte počet use case points (UCP). Nakonec počet UCP vynásobte pracností člověko-hodin na jeden UCP. Karner doporučuje hodnotu 20, jiní autoři rozmezí 15 až 30 hodin na jeden UCP. Doporučuje se kalibrovat tuto hodnotu podle dat z minulých projektů. Odhad si můžete vyzkoušet pomocí jednoduchého kalkulačního programu a plug-inu do CASE nástroje, který si můžete stáhnout z (sekce Ke stažení). Tam naleznete i podrobnější návod k jednotlivým krokům odhadu. Existují i softwarové nástroje podporující tuto metodu, od jednoduchých až po složité, které počet transakcí získávají automaticky analýzou use case modelu a textu scénáře. Pro odhady v počátečních fázích vývoje je ale i tabulka v MS Excelu zcela vyhovující. Výhody a nevýhody metody UCP Metoda Use Case Points stále není standardizována (narozdíl od standardizace výpočtu functional points). Neexistují formální standardy pro psaní use case, problematická je především úroveň abstrakce a úroveň podrobnosti popisu UC, která přímo ovlivňuje počet transakcí popisovaných v UC, což má potom vliv na odhad pracnosti. Metoda UCP není nová, vznikla před více než deseti lety. Mohou zde být pochybnosti, zda odpovídá současným způsobům vývoje softwaru. Existují sice studie prokazující vhodnost této metody, ale studie [4] se týkaly malých projektů (okolo 2500 člověko-hodin) a projektů jedné firmy. Je málo zkušeností s aplikací na různé projekty v různých firmách. Na druhou stranu, podle e-zinu The Rational Edge je metoda UCP používána s dobrými výsledky v Sun a v IBM. K výhodám patří jednoduchost metody, lze se ji snadno naučit a může tak být překonán psychologický odpor k provádění odhadů komplikovanými metodami. Podle studie [5] byl dokonce odhad metodou UCP blíže skutečné pracnosti než odhad provedený skupinou expertů. K další výhodě patří možnost provádět odhady v počátečních fázích vývoje informačního systému, při sjednávání smlouvy. Součástí žádosti o nabídku bývají specifikace funkčních požadavků v úrovni podrobnosti Úvodní studie (pokud její vypracování není součástí poptávky). V této fázi zpravidla ještě neexistuje podrobná textová specifikace jednotlivých kroků scénáře, ze které by se dal jednoznačně vyčíst počet transakcí. I když se nelze spolehnout na to, že jeden funkční požadavek odpovídá jednomu use case a pro klasifikaci složitosti use case je nutno počet transakcí pouze odhadnout, je pro takovéto situace metoda UCP vhodná a dává dobré výsledky. Přesto by měla být vždy kombinována s jinou metodou, expertním odhadem nebo analogií s obdobným projektem. Reference [1] M. Damodaran, A. Washington: Estimation Using Use Case Points [2] K. Ribu: Estimating Object-Oriented Software Projects with Use Cases [3] J. Smith: The Estimation of Effort Based on Use Cases Rational Software White Paper [4] B. Anda et al.: Estimating Software Development Effort based on Use Cases Experiences from Industry. [5] B. Anda: Comparing Effort Estimates Based on Use Case Points with Expert Estimates [6] M. JØrgensen, D. SjØberg: The Impact of Customer Expectation on Software Development Effort Estimates [7] M. JØrgensen: A Review of Studies on Expert Estimation of Software Development Effort [8] K. MolØkken, M. JØrgensen: A Review of Surveys on Software Effort Estimation [9] H. Rubin: Worldwide benchmark project report Webové služby Martin Janček, jancek@komix.cz K myšlence, na kolik jsou známy informace o webových službách, mě přivedl nedávný zážitek z městské hromadné dopravy, kde jsem nechtěně vyslechl rozhovor dvou studentů. Jejich zájem o daný problém byl značný, i když některé odborné výrazy pokulhávaly. A právě proto jsem se rozhodl o tomto novém fenoménu něco napsat. V tomto článku se budu snažit přiblížit standardy, na kterých jsou webové služby vystavěny a k čemu všemu vlastně slouží. Ale začněme od Adama. Základem webových služeb je XML. Tento otevřený standard je už hodně používaný i jinde, takže byl jenom logický krok ho využít. No ale proč ten humbuk, jak jsou webové služby úžasné? Pokud řeknu, že jsou mířeny k integraci aplikací bez ohledu na to, na jaké platformě a v jakém jazyce jsou napsány, tak nejeden nadšenec zajásá. Standardů, které aspirovaly na podobné proklamace asi bylo více (CORBA, DCOM), ale jejich implementace a nasazení nebylo tak jednoduché, jak se to jeví s pomocí webových služeb. Webové služby jsou naproti těmto standardům postavené na relativně jednoduchých, přístupných a široce rozšířených standardech. Vyjmenujme jenom pár výhod, které webové služby poskytují. Obsahují způsob, jak popsat své rozhraní. Tento obsah je popsán pomocí XML dokumentu, celé je to nazváno WSDL (Web Services Description Language). Komunikace probíhá pomocí standardního transportního HTTP protokolu, kterého výhodou je průchodnost přes směrovací prvky v síti. Umožňuje vzdálené volání procedur. Celá komunikace probíhá za pomoci protokolu SOAP (Simple Object Access Protocol). Služby je možno registrovat a následně vystavit pro použití širší veřejnosti. Výhodou je, že potenciální uživatelé je mohou snadno nalézt. Toto se děje pomocí specifikace UDDI (Universal Discovery Description and Integration). Dále si pohovoříme o výše uvedených standardech, s kterými webové služby pracují. Řekli jsme si, že pro komunikaci je možné použít transportního HTTP protokolu. Takže komunikovat po čem máme a potřebujeme protokol, kterým se budeme mezi sebou dorozumívat. Pro tento účel byl zvolen SOAP. SOAP je primárním protokolem webových služeb. Jeho výhoda tkví v jeho jednoduchosti. Protokol se skládá ze tří částí: Obálka (tato slouží k identifikaci zprávy SOAP protokolu). Hlavička (nepovinné, slouží k nastavení atributů protokolu). Tělo (parametry, návratové hodnoty). Zprávy protokolu je možné posílat prostřednictvím HTTP protokolu, ale i pomocí SMTP, TCP/IP anebo Microsoft Message Queue. Všechno záleží na implementaci. Posílání SOAP zprávy pomocí HTTP protokolu se bere jako základ. Je výhodný proto, že je implementován na všech platformách a v organizacích si na něj lidé už zvykli. Další jeho výhodou je možnost zabezpečení a monitorování. Právě spojení HTTP a SOAP je ideální k implementaci webových služeb, které mohou být volány téměř všude. Jak taková SOAP zpráva vypadá, si ukážeme na následujícím příkladu: <SOAP-ENV:Envelope xmlns:soap-env= schemas.xmlsopa.org/soap/envelope/> <SOAP-ENV:Header> </SOAP-ENV:Header> <SOAP-ENV:Body> </SOAP-ENV:Body> </SOAP-ENV:Envelope> Existují ještě další části specifikace, které popisují jak je možné SOAP použít při vzdáleném volání procedur. Tyto části specifikace se využívají při implementaci aplikací ve stylu RPC. Protokol SOAP je však možné využít i pro aplikace, které komunikují mezi sebou pomocí XML ve formě dokumentů. V tomto případě se stává SOAP obálkou XML dokumentu. Jak tedy funguje komunikace s webovou službou, je ukázáno na následujících obrázcích. Aplikace/klient Aplikační kód SOAP Platformově a jazykově specifická komunikace Síť HTTP Webová služba SOAP Platformově a jazykově nezávislá komunikace Webová služba Obrázek č.1 Základní princip komunikace pomocí SOAP Aplikační klient Obrázek č.2 Webové služby a komunikace pomocí SOAP 7

8 pokračování ze strany 7 Z předchozího obrázku je patrné, že webová služba je objektem, který je přístupný přes síťové rozhraní. A jako každý objekt i tento může mít nějaké metody s parametry, které klient může zavolat. Klientem v tomto případě může být webová, nebo i desktop aplikace. (Na vyzkoušení funkčnosti webové služby je možné použít i nějaký dostupný toolkit, například curl ). Aby tedy bylo možné zavolat webovou službu, je nutné ji vystavit a popsat. K tomu slouží WSDL. Je to de facto XML soubor popisující správy SOAP a způsob jejich volání. WSDL můžeme tedy směle přirovnat k IDL (CORBA, COM). Výhoda popisu je v čitelnosti XML formátu. Co WSDL obsahuje je patrné v následujícím popisu. <definitions> vystupuje jako root element <types> tady jsou datové typy definované službou <message> popisuje vstupní a výstupní parametry služby pomocí datových typů v části types <porttype> specifikace operací na základě message <bindtype> protokoly přístupu k metodě a kódování zprávy <service> vše spojuje dohromady Podle vystaveného WSDL se musíte řídit při volání webové služby. Většina vývojových prostředí obsahuje nástroj, který vytvoří z WSDL zástupní objekt, tzv. proxy, a pomocí něho lze s danou službou komunikovat. Programátor tedy nemusí ručně procházet WSDL a vyhledávat metody a parametry. (Tady to však ještě není tak růžové, ne všechny toolkity podporují všechny implementace). Další normou, která je navržena, avšak její využití není takové, je UDDI. Tato specifikace je něco jako zlaté stránky webových služeb. Stejně jako ve zlatých stránkách je možné nalézt firmy a činnosti, které poskytují, tak pomocí UDDI jsou k nalezení potřebné služby, jejich popisy, kontakty a mnoho jiného o dané službě. Vstupem do adresáře UDDI je zase jenom XML soubor popisující autora a služby, které poskytuje. Tento adresář však poskytuje i sofistikovanější způsob hledání vám vyhovující služby. Potom je možné nalezenou službu zaimplementovat do vaší aplikace. (V tomto bodě bych byl však navýsost opatrný. Implementovat takto vystavené služby do aplikace a spoléhat se na jejich dostupnost může být ošidné). Zabezpečení Webových služeb se stává dalším problémem, který je potřeba řešit. Jednou z možností je zabezpečení na straně transportního protokolu. Protokol HTTP poskytuje možnost zabezpečení svým rozšířením na HTTPS. Toto je možné využít při aplikacích typu point to point. Co však dělat, pokud váš protokol je SMTP, nebo do zpracování dat vstupuje ještě někdo jiný? Specifikace, která si dala za úkol toto vyřešit se jmenuje WS-Security. Tato norma popisuje zabezpečení celistvosti, integrity a utajení obsahu posílaných dat. Řekněme si něco málo o základních pojmech, s kterými se u bezpečnosti setkáte. Autentizace Subjekt je opravdu tím za koho se vydává. Autorizace Subjekty smí jednat pouze v rámci svých oprávnění. Důvěrnost Data nejsou dostupná neautorizované třetí straně. Integrita Data nemohou být změněna po cestě. Neodmítnutelnost odpovědnosti subjekt nemůže popřít své akce. WS-Security tedy nabízí možnost logické ochrany našich dat. Nebudu se rozepisovat o způsobech šifrování, ale je vhodné ukázat, co znamená data podepsat a šifrovat. Na dalších obrázcích je tedy názorně ukázáno, jak se data podepisují a jak šifrují. Podepisování Privátní klíč odesílatele + = + Veřejný klíč odesílatele Obrázek č. 3 Podepisování Šifrování Veřejný klíč adresáta = + = + Obrázek č. 4 Šifrování Privátní klíč adresáta = Rozšíření SOAP zprávy pak vypadá následovně: <SOAP-ENV:Envelope xmlns:soap-env= xmlns:wsse= > <SOAP-ENV:Header> <WSSE:Security> </WSSE:Security> </SOAP-ENV:Header> <SOAP-ENV:Body> </SOAP-ENV:Body> </SOAP-ENV:Envelope> Norma WS-Security, je již v některých vývojových nástrojích integrována. Zatím jsem však nikde nenašel reálný projekt, který by využíval tuto normu pro přenos svých dat. Je to však jenom otázka času, kdy dojde k většímu nasazení. Tato rozšiřující norma není osamocena. Vznikají další, které pokryjí jiné oblasti komunikace pomocí webových služeb. Jenom namátkou bych uvedl WS-Routing (definuje mechanizmus pro směřování SOAP zpráv), WS-Referral (protokol pro konfigurování instrukcí o cestě zpráv), WS-Trust (rozšíření, které poskytuje vydávání důvěryhodných bezpečnostních známek), WS-Transaction (umožňuje dosáhnout v distribuovaném prostředí webových služeb konzistentnost dat pomocí transakcí), WS-Attachments (posílá přílohy přímo osmibitově, bez konverze), WS-Secure- Conversation (poskytuje bezpečnou komunikaci přes jednu nebo mnoho zpráv), WS-SecurityPolicy (je stavebným blokem, který se používá k spolupráci mezi webovými službami a protokoly aplikací při řešení bezpečnostních modelů), a WS-Addressing (poskytuje transportně neutrální mechanizmus k adresování webových služeb a zpráv). Jeví se tedy, že webové služby se stávají silným hráčem na poli integrace aplikací. Tato technologie již není v plenkách a prvotní mouchy má vychytány. Není proto potřeba mít strach z jejího nasazení do svého řešení. Správa identit s využitím adresářových služeb Jan Krejčí, krejci@komix.cz Proč adresářové služby? V posledních letech jsme svědky značného rozšiřování počítačových systémů do mnoha sfér podnikání a obchodu. Tím logicky dochází k rychlému zvyšování jak počtu klientů, tak serverů připojených do veřejných datových / počítačových sítí. Tato skutečnost klade nové nároky na bezpečnost a IT infrastrukturu organizací. Zahraniční zdroje uvádějí, že ztráty související se zabezpečením informačních zdrojů, které utrpěli spotřebitelé, firmy, obchodníci, poskytovatelé úvěrů a finanční odvětví v roce 2003, jsou podle odhadů téměř trojnásobné oproti roku předešlému (Aberdeen Group, miliard USD, ,75 miliardám USD). V následujícím článku se pokusíme srozumitelně podívat na problematiku správy uživatelů a řízení jejich přístupu k aplikacím. Během rozšiřování množiny systémů a uživatelů se postupně objevily následující problémy: pro koncové uživatele je poměrně dost komplikované nalézt požadované služby a zdroje a dozvědět se o nových, které v dané síti existují, pro aplikace je naopak obtížné sdílet informace o službách, zdrojích a uživatelích, protože jsou často uloženy v aplikačně závislých databázích, se vzrůstajícím počtem služeb narůstá i náročnost administrace, kterou navíc komplikuje propojování systémů na různých platformách, a jedním z neposledních bodů je otázka bezpečnosti, tj. řízení přístupu v jednotlivých částech sítě, za použití odlišných nástrojů a aplikací. Tyto nedostatky se snaží odstraňovat tzv. adresářové služby, které se stávají nedílnou součástí moderních podnikových softwarových řešení. Adresářové služby Adresářovou službou (Directory Service DS) se rozumí aplikace, která umožňuje uchovávat informace o daných objektech informačního systému, dále pak tyto data organizovat, přistupovat k nim a provádět s nimi různé operace. Pod názvem adresářové objekty (Entry) jsou myšleny entity, reprezentující konkrétní komponenty počítačové sítě. Jsou to například objekty reprezentující tiskárny, počítače, uživatelé, uživatelské skupiny, servery, aplikace, atd. Každý z těchto objektů má spoustu vlastností (Attribute), které popisují jeho chování. Objekty a jejich atributy spolu s konkrétními hodnotami jsou uloženy v globální systémové databázi, označované jako databáze služeb nebo adresář služeb. V uvedené databázi jsou uloženy všechny informace, které daný systém služeb potřebuje ke své činnosti. Entity v adresářových službách jsou členěny do hierarchických stromových struktur (Tree). Je to základní vlastnost DS, která umožňuje definovat mezi jednotlivými objekty jednoznačné logické vztahy. Na této myšlence je založena jmenná konvence entit v DS. Celá struktura je tedy vyjádřitelná pomocí grafu stromu, přičemž jednotlivé uzly určují hierarchické úrovně stromu a listy koncové objekty. Jednotlivé uzly jsou také objekty mající většinou funkci kontejneru, který může být i listem v případě, že momentálně neobsahuje žádnou další entitu. Kontejnerové objekty zpravidla nepředstavují fyzické součásti sítě, ale jejich typickou úlohou je sdružovat koncové objekty s podobným významem do skupin. Koncové objekty většinou již představují konkrétní prvky sítě. Každý objekt má své jméno (Object Name), které je jedinečné v rámci větve stromu, do které spadá. Bývá zvykem volit tato jména tak, aby co nejlépe popisovala daný objekt. Objekt má kromě tohoto jména přiřazeno i úplné jméno (Complete Name), vyjadřující jeho polohu v rámci stromu. Toto jméno již není unikátní pouze ve své větvi, ale v celém stromu. Pro úplné jméno objektu se v anglicky psané literatuře ustálil název Distinguished Name (DN). Pro tvorbu DN se zavedla konvence určující cestu stromem od objektu až ke kořeni stromu. V názvech objektů mohou být uvedeny zkratky, které popisují, o jaký druh objektu se jedná. V tabulce jsou pro představu uvedeny zkratky některých objektů. O organizace Organization C stát Country OU pobočka organizace Organization Unit CN koncový objekt Common Name Příklady symbolů určujících typ objektu Zápis DN objektu za použití symbolických zkratek může tedy vypadat například takto: DN = cn=krejci, ou=od-is, o=komix Základní vlastnosti adresářových služeb Jednou ze základních vlastností DS je již zmíněná hierarchičnost. Tato vlastnost dává DS velmi rozsáhlé a flexibilní možnosti pro správu všech objektů. S využitím pojmů jako jsou dědičnost a kontejnerový objekt se velice zjednodušují operace nad jednotlivými objekty. Kontejnerový objekt nám přináší možnost řídit hromadně vlastnosti celé skupiny objektů. Bez této podpory by bylo nutné nastavit množinu vlastností každého z objektů zvlášť. Za pomoci tohoto nástroje se zmíněná operace provede pouze jednou, a to na kontejneru. A potom stačí vytvořit pouze logickou návaznost objektů s kontejnerem. Dědičnost znamená, že se jednotlivé vlastnosti kontejnerů dědí směrem k listům v jednotlivých větvích adresářového stromu. Díky hierarchičnosti se potom dají mezi objekty jednoduše vytvářet vzájemné vztahy. Tyto vztahy určují, jaké operace může objekt provádět vzhledem k jinému objektu nebo skupině objektů obsažených v daném kontejneru. Pod pojmem operace se rozumí čtení nebo modifikace vlastností jiných objektů, nebo využívaní jejich služeb. Jako příklad uveďme vztah uživatele a síťové tiskárny. Uživatel má přiřazena určitá práva k tiskárně a podle toho ji například může nebo nesmí využívat k tisku. Naopak se dá říci, že tiskárna povoluje nebo neumožňuje tisk danému uživateli. Protokol LDAP LDAP Lightweight Directory Access Protocol byl původně navržen jako zjednodušení protokolu DAP, který zase vycházel ze standardu X.500, což je plnohodnotná realizace DS. Zjednodušení spočívalo jednak ve využití protokolové sady TCP/IP a dále byly vypuštěny složitější vlastnosti a některé operace. LDAP definuje dva typy autentizace: jednoduchou autentizaci a SASL (Simple Authentication and Security Layer specification). Autentizační proces zpracovává informace, které udávají, jestli jsme ti, za něž se vydáváme. První z uvedených jednoduše ověřuje správnost hesla k danému DN, pod kterým se uživatel přihlašuje do systému. Druhý typ SASL zajišťuje bezpečné připojení a je mnohem složitější. Zjednodušeně lze říci, že v rámci operace bind (navázání spojení) je k dispozici identita uživatele, jméno autentizačního mechanismu a credentials, neboli vlastní důkaz uživatelské identity ve formě dat. Jednoduchá autentizace: při tomto druhu autentizace se serveru předává heslo v nezašifrované podobě. Ten pak provádí ověření, zda-li odpovídá přihlašovanému objektu. Tento princip má jako svou podskupinu anonymní přhlašování. Anonymní spojení: existuje mnoho situací, kdy chceme využít pouze minimální množství služeb nabízených LDAP serverem bez toho, aniž bychom poskytli DN a heslo pro autentizaci. LDAP protokol umožňuje se serverem vytvořit anonymní spojení. Aby nastala zmíněná situace, stačí poslat požadavek typu bind na server a uvést prázdný řetězec s heslem. Server tento požadavek zpracuje jako anonymní přihlášení a přidělí uživateli úroveň služeb, kterou administrátor povolil pro anonymní uživatele. Obvykle se přiděluje takovýmto uživatelům možnost pouze vidět stromovou hierarchii se jmény objektů, které jim přísluší (Browse Rights). Anonymní spojení je tedy vhodné použít tehdy, když server obsahuje informace, které nevyžadují ochranu a my se nechceme zabývat otázkou přihlašování. Vrstva SSL (Secure Sockets Layer) řeší zabezpečení přenášených dat mezi klientem a serverem a je vložena mezi aplikační protokol a protokol TCP/IP. Přenášená data se pak tedy např. mezi WWW serverem a browserem přenášejí šifrovaně pomocí šifrování veřejným a tajným klíčem. Klíče navíc obvykle obsahují autentifikační informaci od certifikační autority (CA). 8

9 pokračování ze strany 8 Správa identit Identity Management Využití adresářových služeb (LDAP) je však pouze jedním z kroků k centrálnímu uložení a efektivní správě uživatelských oprávnění k síťovým zdrojům a aplikacím. Je třeba hledat řešení pro správu identit, které poskytne soubor procesů a technologií pro řízení bezpečného přístupu k informacím a informačním zdrojům v organizaci. Hledané řešení umožní provádět správu identit centrálně, rychle, efektivně, a to při dodržení všech zásad definovaných bezpečnostní politikou organizace. Všechny tyto předpoklady splňují systémy, které se shodně označují pojmem Identity Management (IM). Správa identit (IM) je spojení adresářových služeb, zabezpečení sítě a autentizace, zaopatření a správy uživatelů, technologií pro jediné přihlášení se do systému (single sign-on) a webových služeb (web services). Jednou větou lze tedy Identity Management systémy charakterizovat jako efektivní řízení životního cyklu uživatelských identit s centralizovaným řízením pravidel a zdrojů, decentralizovanou administrací a samoobslužným přístupem uživatelů. Téměř každý systém či aplikace má definovanou svou vlastní politiku pro přístup uživatelů, což s sebou přináší množství různých správců, nástrojů administrace a různá bezpečností pravidla. Cílem IM je sjednotit správu přístupů do jedné aplikace s jednotným rozhraním, která eliminuje rozdíly ve správě jednotlivých systémů. To umožní podstatné zjednodušení celého procesu přidávání, modifikace a mazání přístupových oprávnění, při naplnění bezpečnostních pravidel v organizaci. IM systémy jsou aplikace, které definují vztah mezi osobou reprezentovanou dostupnými údaji získanými z personálních systémů nebo jiných zdrojů dat a účtem poskytujícím přístup k požadovaným informacím, aplikacím a systémům. Na základě vstupních informací jsou, buď automaticky nebo na žádost, spouštěny procesy, které podle přesně stanovených pravidel vedou k vytvoření nebo modifikaci účtů a dalších nastavení, tak, aby příslušná osoba mohla provádět všechny požadované činnosti zajišťované IT. Dalším pojmem, se kterým se setkáváme, jsou role. Rolí budeme rozumět množinu určitých přístupových práv. V IM systému jsou vytvářeny jednotlivé role podle typu přístupu nebo typu uživatele. Pro každou roli je pak možné stanovit pravidla (policy), která příslušné roli přiřazují odpovídající účty nebo oprávnění na spravovaných systémech. Role jsou pak přiřazovány uživatelům nebo skupinám uživatelů. Změní-li se definice role, automaticky se tato změna projeví u všech uživatelů, kteří mají tuto roli přidělenou. Podobné je to se zrušením role, kdy jsou přístupová oprávnění automaticky odebrána. Řízení přístupu prostřednictvím rolí umožňuje, aby nastavování přístupových práv uživatelům prováděly i ty osoby (např. odpovědní pracovníci), které nemusí znát administrátorské nástroje spravovaných oblastí. Pro maximální využití možností, které IM poskytuje, je nutné provést analýzu, jejímž výsledkem je přesná definice rolí včetně jejich výstižného popisu. Jedním ze základních prostředků IM je workflow. Slouží pro modelování procesů vedoucích k vytvoření požadovaného účtu, či nastavení atributu při zachování všech formálních požadavků na takovýto proces v organizaci. Primárním cílem je umožnit schvalování požadavků definovaných uživateli IM při respektování organizační struktury a dalších pravidel. Tato pravidla mohou být stanovena i vně workflow. Příkladem workflow může být schválení přístupu do aplikace, kdy uživatel sám modifikuje nastavení svého účtu podle předem připravených voleb a po odeslání požadavku je tento požadavek směrován na osobu definovanou ve workflow. Ta požadavek buď schválí, nebo s odůvodněním zamítne. Tato nejjednodušší forma workflow může být rozšiřována o další schvalující osoby, doplňující informace, podmíněné větvení, cykly apod. Delegace administrace je důležitá oblast, která umožňuje přenesení odpovědnosti za určité operace v IM na osoby, kterým dané oprávnění přísluší. Není již nutné, aby změny prováděli správci systémů nebo jiné specializované útvary. Odpovědnost je přenesena na přímého řídícího, nebo pověřeného pracovníka, který spravuje danou oblast, nebo útvar. Speciální formou delegace jsou tzv. samoobslužné služby (SelfServices). Ty umožňují uživatelům, kteří mají přístup do IM aplikace, samostatně provádět změny atributů spojených se svou osobou. Žádat o přidělení dalších zdrojů, případně modifikaci, či žádat o jejich zrušení. Veškeré tyto operace je možné individuálně povolovat či zakazovat prostřednictvím přístupových oprávnění k atributům či operacím IM. Pro většinu uživatelů však zůstává hlavní volbou SelfServices změna hesla. Známé úskalí pro uživatele spočívá ve velkém množství účtů, které musí používat. Pamatovat si mnoho hesel je náročné a přináší to s sebou riziko zapomenutí hesla. Různí uživatelé to řeší různě heslo přilepené na klávesnici nebo na monitoru je asi ten nejméně vhodný způsob, jak se proti zapomenutí hesla bránit. Nejčastější dotazy na Helpdesk bývají právě v souvislosti s reinicializací hesla. IM systémy nabízejí možnost centrální správy hesel pro všechny definované účty. Na hesla je aplikována politika, která splní bezpečnostní požadavky všech systémů. Má-li uživatel přístup do IM a zná jej, může si změnit hesla na kterémkoliv systému či aplikaci, které mu náleží, a to pro všechny najednou, či jednotlivě. Stejnou volbu může realizovat správce systému nebo jiná pověřená osoba. Pro ověření uživatele při přihlášení do IM systému lze také využít ověření systémem otázek a odpovědí. Závěr Stále více podniků a organizací si uvědomuje důležitost efektivní a bezpečné správy uživatelských účtů a řada dodavatelů z oblasti IT na tuto poptávku reaguje různými specializovanými produkty, ale na trhu jsou i řešení, která se snaží o ucelený přístup k této problematice. Je zřejmé, že IM systémy významně zvyšují efektivitu správy identit v organizaci, úroveň bezpečnosti a v neposlední řadě i komfort uživatelů. I přes jejich nesporné výhody však přináší také potencionální rizika spojená s koncentrací citlivých informací do jednoho místa. Je tedy nutné v maximální možné míře IM systémy, a obzvláště jejich úložiště dat, chránit před zneužitím. Informační podpora technologických procesů Jan Vrána, vrana@komix.cz Úvod Řízení složitého technologického procesu je nelehký úkol, který vyžaduje spoustu znalostí o řízeném procesu, zejména o hodnotách parametrů a veličin, které celý proces ovlivňují přímo, ale také spoustu informací o vzájemných vazbách jednotlivých částí technologického procesu a dílčích veličinách, které výsledný proces ovlivňují nepřímo. Se vzrůstající složitostí technologického procesu velice prudce narůstá množství informací, které jsou nezbytné pro jeho řízení. Prudce se zvětšuje množství informací o veličinách, které proces ovlivňují přímo, ale ještě mnohem rychleji roste množství informací o veličinách, které proces ovlivňují nepřímo a o vzájemných netriviálních kombinacích a vazbách těchto veličin. Manuální zvládnutí a využití všech těchto informací se pro obsluhu stává stále větším problémem. Další oblastí, která zatím není příliš uspokojivě řešena, je následné zpracování dat o technologickém procesu, která produkují jednotlivá měřící čidla. V současné době se tato data používají většinou pouze pro okamžité rozhodování a řízení, a i to v nezbytně nutné míře. Z těchto dat je ale možné dalším zpracováním získávat další velice užitečné informace. Z dat, na jejichž získání jsme zdroje již vynaložili pro potřeby řízení a sledování výrobního procesu, takže další informace z nich získané jsou v podstatě bonusem. Výsledkem pak mohou být netriviální závislosti kvality výsledného produktu na kvalitě nebo kolísání kvality některých vstupních nebo interních veličin, nebo podobné netriviální závislosti jiných veličin, např. efektivity výroby. Z dat o technologickém procesu lze popřípadě modelovat různé předpovědi sledovaných kritérii na základě historických záznamů. Pomocí takto získaných informací je potom možné optimalizovat vlastnosti celého technologického procesu, což může mít významné pozitivní ekonomické a tržně-konkurenční důsledky. Uvedené možnosti vyžadují informační podporu řízení složitého technologického procesu, neboli podporu pro následné zpracování základních provozních informací o technologickém procesu. Tento článek má za cíl naznačit některé typy následného zpracování technologických dat a možnosti a výhody, které popsané prostředky poskytují. Budeme zde mluvit o dvou typech systémů pro následné zpracování technologických dat: o primárních technologických informačních systémech (PTIS) a o datových skladech (DS) jako zástupcích nadstavbových informačních systémů (IS), o jejich hlavních vlastnostech, o některých úskalích jejich zavádění a o metodě DRD, která umožňuje tyto systémy efektivně vytvořit. Primární informační systém Úkolem PIS je podporovat každodenní provoz a základní informační potřeby provozovatele. Obvykle se jedná o provozní, výrobní a ERP systémy, např. informační podpora personální a mzdové agendy, fakturace, účetnictví, skladového hospodářství atd. Za PIS lze považovat i automatizační systém pro řízení technologického procesu, ale zde se používá spíše termín řídící systém. Odhlédneme-li od čistě ekonomicky nebo administrativně orientovaných PIS, může nám jako příklad technologického PIS posloužit např. aplikace pro podporu správy konfiguračních parametrů a nastavení jednotlivých elementů rozsáhlé technologické sítě. Tento charakter mají i další oblasti: modelování a správa rozsáhlé a složité technologické sítě (např. mobilní nebo jiné telekomunikační sítě), modelování a správa distribuovaného řídícího systému, modelování a správa distribuční a produktovodné sítě, modelování a správa obchodní a logistické sítě, modelování, správa a odhalování závislostí v ekonomických, technologických a jiných procesech, další. Na rozdíl od různých administrativních a ekonomických PIS, které jsou v současné době dobře zvládnuté, představují technologické PIS mnohem větší problém. Jednak proto, že se doposud věnovala mnohem menší pozornost následnému zpracování získaných údajů, ale také proto, že jsou mnohem náročnější na dobrou, ale hlavně po všech stránkách efektivní implementaci. Standardní postupy známé z budování ekonomických IS zde často selhávají. Zjednodušeně řečeno, většina problémů pramení z toho, že spravovaná data mají mnohem složitější vnitřní strukturu a vazby a tato struktura se navíc může dynamicky měnit. To je koncept, se kterým klasické návrhové metody nepočítají. Zavádění IS Při vývoji, nasazování a provozu jakéhokoliv systému, ať už je to chladnička, auto, technologická linka nebo počítačová aplikace např. informační systém, je možné a potřebné daný systém posuzovat z několika hledisek. Je třeba sledovat: náklady na prvotní pořízení, náklady na standardní provoz, údržbu a možný rozvoj a provozní vlastnosti, tj. výstupní kvalitu, spolehlivost, efektivitu, rychlost, atd. Tato tři hlediska mají zásadní vliv na úspěch zaváděného systému. První dvě reprezentují přímé ekonomické faktory pořízení a provozu a třetí má principiální vliv na praktickou použitelnost nebo naopak nepoužitelnost zaváděného systému. Existuje mnoho různých možností, jak řešit problém uložení a správy dat v rozsáhlých datových systémech. Většina známých postupů se však soustřeďuje na co nejlepší vyřešení jednoho dílčího hlediska, např. na minimalizování pořizovacích nákladů nebo na co největší univerzálnost a flexibilitu a tím na minimalizování nákladů na provoz, údržbu a rozvoj. Hlavní pozornost se také často zaměřuje na provozní vlastnosti, tj. na rychlost a efektivitu. Následkem velkého objemu ukládaných dat s obrovskou vnitřní složitostí a s měnící se strukturou je v praxi obvykle velmi obtížné optimalizovat současně všechna tři uvedená hlediska. Většina známých metod a postupů řešení má velmi dobré nebo vynikající vlastnosti v některém z hledisek, ale zároveň výrazně horší vlastnosti v jiném hledisku. Kvalita řešení se projeví právě na kombinaci nákladů na vývoj a údržbu příslušné aplikace a v neposlední řadě pak na jejích provozních vlastnostech. Postupy a metody, které jednotliví výrobci používají, jsou jejich výrobním tajemstvím a není tudíž ani na základě znalosti použité metody dopředu odhadnutelné, jak se bude budoucí IS chovat ve standardních, ale hlavně v nějakých nestandardních situacích. Pro efektivní uložení a správu rozsáhlých datových systémů se složitou vnitřní strukturou existuje publikovaná metoda DRD (Dynamické Relační uložení Dat), která byla od počátku vyvíjena s cílem optimalizovat všechny tři zmíněné aspekty, tj.: minimalizovat náklady na prvotní zavedení, minimalizovat náklady na údržbu a rozvoj a také maximalizovat provozní efektivitu, tj. minimalizovat dobu odezvy aplikace a minimalizovat nároky na uložení spravovaných dat. Minimalizace nákladů na prvotní zavedení, ale hlavně nákladů na údržbu a rozvoj aplikací je 9

10 pokračování ze strany 9 dosažena vysokou flexibilitou metody, založené na metapopisu spravované oblasti. Díky tomu je možné relativně velmi snadno a rychle implementovat i poměrně rozsáhlé změny struktury spravovaného systému (technologického procesu) nebo funkčnosti. Maximalizace provozní rychlosti při minimalizování nároků na uložení dat je dosaženo tím, že metoda ukládá a zpracovává spravovaná data v relační podobě přirozeným způsobem, takže je možné plně využít osvědčených vlastností výkonných relačních databázových systémů. Jinými slovy, metoda DRD umožňuje, s nízkými pořizovacími a provozními náklady, vytvořit aplikaci schopnou minimalizovat náklady na následné zpracování dat z technologických prvků. Samostatný odstavec dále v textu uvádí stručný popis principu DRD, jeho uplatnění a přínos pro informační systémy. Nasazení datového skladu nebo PIS je složitý proces, který se nesmí v žádném případě podcenit. Dobrý návrh datového skladu vychází z pečlivé analýzy charakteru vstupních dat a uživatelských požadavků. Jen poměrně malou součástí procesu nasazování je výběr a zakoupení vhodného softwaru. Naprostou většinu času a úsilí zabere analytická a přípravná fáze. Při dodržení správného postupu při nasazování poskytnou datový sklad i PIS nový druh informací, které jsou jinými prostředky nedostupné. Při nevhodném nasazení nebo nedodržení správného postupu při zavádění se může nový systém naopak stát velmi drahou nepoužitelnou hračkou, či dokonce brzdou rozvoje. V současné době je na trhu celá řada softwarových produktů pro tvorbu a správu datového skladu a prakticky žádné produkty pro tvorbu technologických PIS (PTIS). Jednotlivá řešení se odlišují jak cenou, tak i robustností a funkcionalitou. Jejich společná orientace je na hlavní tržní segment, tj. na finanční, marketingové a logistické údaje. Volba vhodného softwarového produktu/řešení pro zpracování technologických údajů je obtížnější, protože tento směr využití datových skladů není dosud tolik rozšířen. Každopádně je výběr vhodného produktu náročným úkolem, kde hraje roli mnoho různých aspektů včetně ceny, která je u tohoto typu softwaru tradičně poměrně vysoká. Rozhodujícími kritérii pro aplikaci datových skladů nebo PIS v prostředí technologických dat by se měla stát především schopnost dodavatele provést dobře prvotní návrh řešení a podle něj teprve vybrat softwarový produkt s takovými vlastnostmi a výkonem, který splní celkový záměr. Jako příklad reálného PTIS využívajícího metodu DRD může sloužit aplikace s názvem SDMT (System Database Management Tool) pro podporu správy mobilní telefonní sítě mobilního operátora Eurotel. Systém SDMT významným dílem přispěl k zefektivnění správy sítě, jejímu lepšímu využití a v neposlední řadě k její vyšší spolehlivosti, což má jednoznačně pozitivní ekonomické dopady. Uplatnění metody DRD pro IS Z technického hlediska jsou si uložení a správa dat v datovém skladu a uložení a správa dat v PTIS částečně podobné. V datovém skladu je potřeba efektivně zpracovat veliké objemy dat (zpravidla větší než v případě PTIS), vnitřní složitost dat je však většinou nižší. V obou případech ale není struktura dat pevná, může se za provozu měnit. Na rozdíl od PTIS je problematika datových skladů a hlavně OLAP systémů technicky mnohem více propracovaná. Většina významných OLAP systémů je založena na relační technologii a významní výrobci relačních databází nabízejí ke svým DB serverům i OLAP rozšíření. Je ale možné použít i řešení třetí strany a nevázat se tak na jedinou databázovou platformu a jediného dodavatele. Například je možné pro vytvoření datového skladu s výhodou použít metodu DRD. Při použití metody DRD pro PTIS i pro datový sklad je možné ještě využít další vlastnosti této metody její integrační schopnosti. Lze například výstupy z PTIS či datového skladu a nalezené závislosti přímo zapojit do provozního systému, takže tento systém může potom automaticky rozpoznávat neobvyklé stavy a signály přicházející z čidel a na tyto stavy včas upozornit obsluhu. Může tak vzniknout de-facto expertní systém, který je schopen do značné míry autonomně dozírat nad technologickým procesem na mnohem vyšší úrovni, než většina základních automatizačních systémů. Ekonomické dopady takového systému jsou nasnadě: odstranění nebo snížení rutinní dozorové činnosti, snížení nároků na zaškolení dozoru (dozor nemusí držet v hlavě všechna specifika daného provozu), snížení závislosti na lidských specialistech, snížení rizika selhání lidského faktoru (zvláště u rutinních činností), zvýšení spolehlivosti provozu, zvýšení efektivity provozu. Metoda DRD Hlavní princip metody DRD nejjasněji popisuje následující scénář: 1. Aplikační doména, tj. všechny objekty a jejich vazby, se popíše obecně a tento popis se v podobě metadat uloží do zvláštní části DB. 2. Na základě metapopisu se v DB dynamicky vygenerují příslušné datové struktury specifické pro danou aplikační doménu, do nichž se budou ukládat spravovaná data. 3. Požadavky na operaci s daty (vložení, výběry, modifikace) se realizují následujícím způsobem: a. Vstupní data se podle metapopisu transformují z objektové do relační podoby. b. Na základě požadavku a metapopisu aplikační domény se dynamicky vygeneruje specifický SQL dotaz do databáze, který provede požadovanou operaci s daty v dynamicky vygenerované struktuře, přičemž může plně využít všech výhodných a výkonných vlastností relační DB, což se projeví hlavně při hromadných operacích. c. Vygenerovaný SQL dotaz se spustí a výsledky se po zpětné transformaci do objektové podoby vrací zpět žadateli. Popsaný postup se může na první pohled jevit jako zbytečně složitý, ale ve skutečnosti ověřené praxí je režie vstupně-výstupní transformace a sestavování dynamických SQL příkazů velmi malá a je bohatě vyvážena efektivitou provádění vytvořených dotazů. Agregační Ω 3 vazba Logická Ω 3 vazba Ω 3 celek Ω 3 entita Ω 3 atribut Na obrázku je vidět struktura DB při použití metody DRD. V levé části je pevná struktura tabulek obsahujících metapopis a v pravé části je dynamická struktura tabulek vygenerovaných podle metapopisu. Aplikace založená na metodě DRD je obecná a její chování se řídí metapopisem, takže při malé nebo i poměrně velké změně aplikační domény nebo požadované funkcionality většinou stačí pouze změnit příslušnou část metapopisu bez nutnosti upravovat nebo předělávat programy. Pozdější změny datové struktury nebo funkčnosti vyvinuté aplikace, včetně jejího nasazení v jiné aplikační doméně, jsou tedy poměrně velmi snadné a levné. To je obrovská výhoda oproti aplikacím, které jsou vytvořené klasickým způsobem budování ekonomických IS. Flexibilita metody DRD je podobná jako u obecného objektového řešení. Druhou vlastností, kterou se metoda DRD vyznačuje, je mimořádně vysoká provozní efektivita. Té je dosaženo díky tomu, že data jsou uložena v přirozeně relační podobě a stejným způsobem jsou i dotazována a zpracovávána, takže je možné plně využít síly relačních operací. V tom se metoda DRD výrazně odlišuje od obecného objektového řešení a přiklání se naopak k výsledkům klasického přístupu. Závěr Informační podpora technologického procesu může poskytnout mnohé výhody a nové informace, které je možné využít např. k výraznému zlepšení a zefektivnění výrobního procesu a tím získat významné ekonomické nebo tržně-konkurenční výhody. To samo o sobě je neocenitelnou službou. Navíc, tyto důležité informace jsou jakýmsi bonusem vytěženým malými náklady z dat, na jejichž získání již byly prostředky vynaloženy a která v současné době představují pouze nepotřebný odpad. Výhodnější situace snad ani nemůže nastat a nevyužít ji by byla veliká škoda. Je to jako dávný sen alchymistů, udělat z bezcenného kovu zlato. Článek ukazuje možné cesty, jak lze pomocí DRD metody tyto výhody získat efektivním způsobem. Ošetření chyb v aplikacích jaké údaje zaznamenávat při vzniku chyby Petr Sobotka, sobotka@komix.cz Problematika ošetřování chyb v aplikacích je téma, kterým se musí zabývat každý tvůrce softwaru. Přesto není k dispozici mnoho literatury, která by tuto oblast návrhu a tvorby aplikací podrobně rozebírala a hodnotila v praxi používané metody. Tento článek se zabývá jedním z aspektů ošetřování chyb a klade si za cíl odpovědět na následující otázku: Jaké údaje je vhodné zaznamenat v okamžiku vzniku nestandardní chyby v aplikaci? Pod pojmem nestandardní chyba rozumíme takový chybový stav, který sice v aplikaci zachytíme prostředky daného programovacího jazyka, ale nemáme pro ně připravené žádné speciální chování aplikace. Můžeme říci, že taková chybová situace nezapadá do námi navrženého algoritmu. Např. zadá-li uživatel chybné heslo při přihlášení do aplikace, jedná se o chybu, ovšem aplikace je na ni připravena, vypíše chybovou zprávu a nabídne uživateli nové přihlášení. Pokud se však při zápisu do souboru náhle objeví chyba příslušné systémové funkce, aplikace pravděpodobně nebude vědět, co s tím, a bude reagovat tak, že zcela ukončí právě prováděnou aktivitu. Zaznamenání údajů potřebných pro analýzu chyb (do textového protokolu, databáze apod.) je důležité především v situacích, kdy v místě nasazení aplikace nemáme k dispozici vývojové prostředí s možností běhu aplikace v ladícím režimu. Nebo pokud potřebujeme dohledávat náhodně vznikající chyby, resp. takové chyby, které se vůbec neprojeví při spuštění aplikace v ladícím režimu typicky úlohy využívající paralelní zpracování je velmi obtížné spouštět v režimu ladění. V následujících odstavcích postupně vyjmenujeme a vysvětlíme jednotlivé typy údajů, které je užitečné zaznamenávat. Budeme rovněž srovnávat, jak lze daný typ údaje získat v jazycích Java a C. Začneme od základních informací, které se běžně objevují v záznamech o chybách ve všech aplikacích, a dostaneme se rovněž k nadstandardním položkám, z nichž některé lze získávat pouze za cenu zvýšeného úsilí při tvorbě programového kódu. Prvním údajem, který musí být součástí záznamu o chybě, je identifikace chyby, která vznikla. Zde je možné použít dvojí přístup. Buď zapíšeme přímo do programového kódu textový řetězec určující, k jaké chybě došlo, nebo máme vytvořenu tabulku chyb, která každému typu chyby přiřazuje unikátní identifikátor (číselný nebo znakový kód) a odpovídající text. V programovém kódu pak používáme pouze identifikátory chyb a teprve při zápisu chyby do logu aplikace je záznam doplněn o příslušný text. Výhodou prvního přístupu je, že nepotřebujeme žádné podpůrné prostředky pro transformaci chybového kódu na text. Vzhledem k tomu, že text chyby sestavujeme v programovém kódu přímo v místě vzniku chyby, můžeme snadno dynamicky doplňovat parametry (např. jméno souboru, který se nepodařilo otevřít). Pro druhou metodu hovoří následující přednosti: stejný typ chyby ošetřovaný na různých místech programu má jediný text, texty chyb jsou uloženy na jediném místě, čímž se usnadňuje jejich správa, úpravy textu apod., snadno lze provést převod chybových textů do jiných jazyků, což usnadňuje lokalizaci aplikace. Uvedené výhody se výrazně uplatňují v rozsáhlejších aplikacích. Tato metoda je komplikovanější v případě, že potřebujeme používat parametrizovatelné chybové texty. Parametry se do textu chyby doplňují až v okamžiku výstupu k uživateli, je proto nutné je někde dočasně zaznamenávat. Rovněž je nutné myslet na to, že různé typy chyb vyžadují různý počet parametrů, což může komplikovat způsob založení chybového záznamu (např. pokud nemáme k dispozici funkce s proměnným počtem parametrů). Důležitým údajem pro analýzu příčiny vzniku chyby může být datum a čas, kdy chyba vznikla. Význam to má např. v případě, kdy vedeme podrobnější log o činnosti programů a můžeme okamžik vzniku chyb vztáhnout k ostatním záznamům v logu. Nebo pokud různá denní doba, den v týdnu atd. podmiňuje pravděpodobnost vzniku chyby, pomáhá odhalit její příčinu, popř. určuje její závažnost a důsledky. Další informací, bez které se ve většině případů neobejdeme, je určení místa vzniku chyby, tj. kde v programovém kódu se chyba objevila. Minimální a zároveň dostatečnou dvojicí údajů je název zdrojového souboru a číslo řádky. Užitečný je i název funkce, ve které chyba vznikla, což může v některých případech pomoci vyhodnotit příčinu vzniku chyby, aniž by bylo nutné nahlížet do zdrojových souborů. Občas se lze setkat s přístupem, který vychází z předpokladu, že daný typ chyby vzniká pouze na jediném místě programu a není proto potřeba explicitně zaznamenávat místo vzniku. To se určí vyhledání textu či kódu chyby v množině zdrojových souborů. Dalším často používaným způsobem identifikace místa vzniku chyby je použití unikátního návěští, které se vyskytuje na jediném místě v celé množině zdrojových souborů. Tento přístup je obdobný předchozí metodě. Návěští je zapsáno do protokolu jako parametr záznamu o chybě a pomocí něj lze dohledat, kde došlo k chybě. Obě metody jsou použitelné u nepříliš rozsáhlých programů a jsou potenciálním zdrojem problémů při dalším rozvoji aplikací. 10

11 pokračování ze strany 10 Nejlepším řešením je zajistit automatické zaznamenání místa vzniku chyby, což většina programovacích jazyků více či méně podporuje. V jazyce C se pro tento účel nabízí k použití symboly preprocesoru FILE a LINE. Java ukládá informace o jméně třídy (odpovídá názvu souboru) a řádce (je-li použit příslušný parametr při překladu), na které vznikla chyba, automaticky do zásobníku volání metod, jehož obraz je součástí vzniklé výjimky. Určení místa vzniku chyby často není dostatečné pro analýzu její příčiny. To platí např. tehdy, vzniká-li chyba uvnitř knihovních funkcí, které jsou volané z různých míst aplikace. V takovém případě je dobré znát kontext volání funkce v okamžiku vzniku chyby; jinými slovy, je dobré mít k dispozici zásobník volání funkcí, který nám přesně pomáhá určit v jakém okamžiku (z hlediska sekvence volání funkcí) chyba vznikla. Toto lze chápat jako dynamické určení místa vzniku chyby. Na vrcholu zásobníku je funkce, ve které došlo k chybě. Na každém dalším řádku je pak název funkce, která volala funkci uvedenou o řádek výše. Aby informace byla úplná, je vhodné mít u každé funkce zaznamenán rovněž název zdrojového souboru s číslem řádky. To proto, že v jediné funkci může být volání jiné funkce použito vícekrát. Zásobník volání funkcí (metod) včetně názvů tříd a čísel řádků je v jazyce Java automaticky k dispozici u každé vytvořené výjimky. V jazyce C je třeba příslušný zásobník vytvářet ručně. Zásobník lze generovat dvojím způsobem: s předstihem, tj. neustále (při vstupu do funkcí a při návratu z nich) aktualizujeme zásobník volání funkcí a v okamžiku vzniku chyby obsah zásobníku zaznamenáme, zpětně, tj. když vznikne chyba, založíme úroveň odpovídající vrcholu zásobníku a s každým návratem z funkce přidáme další záznam; zásobník zaznamenáme do logu až po návratu do hlavní funkce. První metoda je výpočetně náročnější, ovšem vytvářený zásobník lze využít i pro jiné účely (např. ladící výpisy). Pro generování zásobníku (libovolnou z uvedených metod) není v C žádná standardní podpora, je proto nutné vytvořit vlastní knihovnu příslušných funkcí a maker, popř. získat již hotovou implementaci. Nyní se již dostáváme k typům informací, jejichž získání není standardně k dispozici v běžně používaných programovacích jazycích. Významným pomocníkem pro analýzu chyb může být zaznamenání údajů, které lze označit jako stav výpočtu. Jedná se o hodnoty, které jsou v okamžiku vzniku chyby uloženy v lokálních proměnných právě prováděné funkce (včetně vstupních a výstupních parametrů), v proměnných modulu (resp. instančních atributech) a rovněž v globálních proměnných. Např. pokud dynamicky generujeme název souboru, při jehož čtení následně vznikne chyba, a ukládáme ho do lokální proměnné, zajímalo by nás, jaký název byl ve skutečnosti použit. Nebo provádíme zpracování v cyklu a je důležité, jaká je hodnota iterační proměnné v okamžiku vzniku chyby. Zaznamenání údajů o stavu výpočtu má samozřejmě smysl nejen na úrovni funkce, ve které došlo k chybě, ale rovněž na všech dalších úrovních zásobníku volání funkcí. Údaje o stavu výpočtu jsou dostupné při použití vývojových prostředí v režimu ladění aplikace. Ani Java ani C však standardně nenabízí podporu pro jejich zaznamenání do aplikačního logu. V případě potřeby těchto informací by bylo vhodné mít univerzální funkci pro zápis globálních proměnných, v každém modulu (resp. třídě) funkci pro zaznamenání lokálních proměnných modulu (resp. instančních atributů) a ručně doplnit zaznamenání hodnot relevantních lokálních proměnných funkcí v místě vzniku chyby. Pro Javu existují knihovny podporující tzv. aspektově orientované programování, které by zřejmě mohlo usnadnit automatický záznam části výše uvedených údajů. Rozšiřme nyní celou problematiku záznamu informací o vzniklých chybách o další rozměr paralelní provádění aplikačního kódu. Pokud se pohybujeme v oblasti aplikací, kde jeden kód může být vykonáván ve více současně vykonávaných instancích výpočtu, je vhodné zaznamenat informaci o tom, v jaké z těchto instancí chyba vznikla. Obecně lze tento údaj či skupinu údajů nazvat identifikací instance. Může se jednat např. o následující informace: číslo nebo identifikátor procesu (vlákna) je použitelné např. tehdy, když je jeden serverový proces přiřazen právě jednomu procesu klientskému, identifikátor sezení má smysl např. ve webových aplikacích, kde může sice každý požadavek přihlášeného uživatele být zpracováván jiným procesem (vláknem), ovšem požadavky mají přiřazeny jediný identifikátor sezení. Uvedené typy údajů jsou s výhodou použitelné pro svázání záznamů o chybách s jinými údaji v aplikačním logu. Pokud aplikace vyžaduje přihlášení uživatele, je vhodné u vzniklé chyby přímo zaznamenávat identifikaci uživatele, při jehož činnosti chyba vznikla. Jako identifikaci instance lze chápat rovněž další typ informace logické pojmenování činnosti, kterou program právě vykonává. Jediný programový kód, resp. sekvence volání funkcí, může být spuštěn s různým logickým smyslem a cílem, který je určen např. parametry volání funkcí. Jako příklad uveďme situaci, kdy programový kód spouštíme ve dvou fázích v prvním kole provádíme akce pouze na oko, testujeme dostupnost potřebných zdrojů, prostor na cílovém úložišti apod., ve druhém pak běží tatáž činnost na ostro (a liší se např. jen tím, že provede skutečný zápis do souboru či databáze). V tom případě by mohlo znatelně ulehčit analýzu chybového záznamu, kdyby jeho součástí byl logický název činnosti, kterou aplikace právě provádí. V našem příkladu by se rozlišovala činnost TEST a ZAPIS. Identifikace instance souvisí do jisté míry se stavem výpočtu, který byl popsán výše; lze ji chápat jako podmnožinu údajů, které popisují stav výpočtu (na úrovni globálních proměnných). Množina údajů, které by mohly tvořit identifikaci instance, je značně závislá na typu aplikace. Rovněž způsob generování a zaznamenání příslušných údajů musí každá aplikace řešit sama. Uveďme nyní příklad, jak by mohl vypadat ideální (vzhledem k množině údajů, které jsme zmínili) záznam chyby v textovém protokolu: Kod: EFILEREAD Text: Chyba při cteni ze souboru file.txt. Datum a cas: :37: Misto: module2.c:func_b (158) ID procesu: Kontext volani: module2.c:func_b() (158) Parametry: p_name = file.txt Lokalni promenne: i = 17, j = 0 module1.c:func_a() (591) Lokalni promenne: tmpv = -7 module1.c:main()(814) Globalni promenne: g_num = 1024, g_text = ABC Promenne module1.c: m_val1 = 3, m_val2 = Promenne module2.c: m_name = kokos Co napsat závěrem? Vždy je třeba zvážit, jaké úsilí je při tvorbě aplikace vhodné věnovat ošetření chyb. Čím více údajů bychom chtěli mít k dispozici v okamžiku vzniku chyby, tím větší práci s jejich zaznamenáním budeme mít při programování. Záznam některých údajů lze zautomatizovat vytvořením pomocných tříd, metod, funkcí či maker, které následně usnadňují psaní vlastního aplikačního kódu. V praxi se ověřilo, že čas vynaložený na návrh a implementaci kvalitních podpůrných prostředků pro záznam údajů o chybách se u rozsáhlejších aplikacích mnohonásobně vyplatí. Monitoring a optimalizace J2EE aplikací jako služba pro zákazníka Martin Ptáček, Martin Sláma, Martin Vaněk ptacek@komix.cz; slama@komix.cz; vanek@komix.cz Společnost KOMIX s.r.o. nabízí služby optimalizace a monitoringu výkonnostních problémů J2EE aplikací v průběhu celého procesu vývoje, v průběhu zátěžových testů těchto aplikací a v průběhu jejich provozování v reálném prostředí. Ve výsledku tyto služby přinášejí úsporu času a nákladů na případné odstraňování problémů v pozdějších fázích projektu. Potřeba těchto služeb narůstá s počtem nasazení a velikostí kritických J2EE aplikací a se zvyšujícími se požadavky na garantovanou dostupnost a garantovanou dobu odezvy uživatelů. Dnes již nejsou neobvyklé požadavky typu, že doba odezvy určité uživatelské transakce nesmí přesáhnout 3 sekundy, nebo že 90% všech odezev dané transakce nesmí trvat déle než 1 sekundu. Tyto ukazatele se sledují a vyhodnocují. Současně bývají někdy i maximalistické nároky na dostupnost aplikací, často v režimu 24x7, prakticky je požadována 100% dostupnost. K tomu se bohužel přidává faktor s opačným efektem a to, že řada J2EE aplikací vzniká pod velkým časovým tlakem. Ne vždy jsou splněny požadavky na potřebnou kvalifikaci a zkušenost celého realizačního týmu v technologii J2EE. Určité mouchy mívá i samotný middleware J2EE, kdy je třeba mít určité know-how, rozpočet projektů bývá poddimenzován v důsledku velké konkurence na trhu. Důsledkem zmíněných vlivů je pak zvýšení nákladů na testování J2EE aplikace před zavedením do provozu a potřeba monitorovat aplikace v průběhu jejich provozu a preventivně odhalovat potenciální rizika zpomalení transakcí a zajistit jejich včasnou nápravu, dříve než to bude mít např. vážné obchodní důsledky. Dalším trendem je tlak na zvyšování produktivity IT útvarů, které v organizacích provozují J2EE aplikace. Pracovníci těchto útvarů často dohlíží současně na zvýšený počet systémů a je žádoucí jim tuto dozorčí funkci usnadnit, např. právě přehlednou vizualizací stavu odezev J2EE aplikací formou přehledných panelů s alerty. KOMIX má dlouholeté zkušenosti ve vývoji i testování Java aplikací a posledních několik let svou pozornost soustřeďuje na technologie tvorby aplikací J2EE. Naši specialisté dokáží s pomocí sofistikovaných nástrojů velmi efektivně lokalizovat a ošetřit problémy s výkonem před tím, než je odhalí testování kvality nebo ostré nasazení do provozu. Jedním z nástrojů, který je používán v naší firmě, je i Wily Introscope americké společnosti Wily Technology. Wily Introscope představuje pokročilý systém pro monitorování a identifikaci komponent jednotlivých vrstev aplikace J2EE. Strukturu celého systému monitorování tvoří tři základní komponenty: Introscope Agent, Introscope Enterprise Manager a Introscope Workstation (viz. obrázek 1.1). Introscope Agent je spouštěn v JVM společně s monitorovanou aplikací a sbírá měřená data definovaná operátorem. Introscope Enterprise Manager přijímá a zpracovává data od agentů a umožňuje jejich prezentaci v Introscope Workstation, případně jejich ukládání do databáze nebo souborů pro pozdější analýzu a vytváření reportů. Introscope Workstation Obr. 1.1.: Introscope Architecture Introscope Enterprise Manager Historical Data Ve standardní konfiguraci Introscope Agent umožňuje monitorovat základní typy komponent architektury J2EE, například JSP, Servlet a EJB, a s použitím technologie Blame usnadňuje identifikaci závislostí mezi nimi. SQL Agent rozšiřuje možnosti monitoringu o sledování interakcí s databází až na úroveň jednotlivých SQL příkazů. Pomocí dalších rozšiřujících modulů, tzv. PowerPacks, je možno monitorovat i specifické parametry konkrétních aplikačních serverů (BEA WebLogic, WebSphere, Oracle atd.). V případě, že při monitoringu vznikne potřeba získání platformově závislých dat, která nelze standardními postupy pořídit z JVM, je zde k dispozici speciální agent EPA (Environmental Performance Agent), který umožňuje spouštět skript nebo nativní program pro získání těchto dat. Introscope Workstation slouží k vizualizaci naměřených dat a konfiguraci parametrů monitorování. Mezi základní měřitelné hodnoty patří: doba odezvy, počet volání během intervalu, zátěž procesorů, velikost paměti JVM, Introscope EPA Introscope Agent Introscope Agent User Defined Scripts (stdout) J2EE Application Application Server JVM J2EE Application Application Server JVM počet aktivních vláken, počet metod nedokončených v definovaném časovém intervalu atd. V základní podobě je každá měřená veličina zobrazována ve formě periodicky aktualizovaného grafu. Navíc Introscope Workstation nabízí možnost vytvářet uživatelsky definované kontrolní panely (Dashboards) sdružující různé měřené veličiny. Pro účely dlouhodobého monitorování bez nutnosti interakce s uživatelem je k dispozici systém událostí a akcí (Alerts and Actions) podmíněných překročením prahových hodnot sledovaných veličin. V případě výskytu události je provedena akce v podobě zaslání zprávy elektronickou poštou nebo spuštění libovolného příkazu hostitelského systému. Další důležitou součástí je i Transaction Tracer, který je určen pro zachycování dlouhých transakcí přesahujících definovaný časový interval. Jednotlivé transakce jsou zobrazovány jako posloupnost zúčastněných komponent i s jejich časovými odezvami, kterými se podílejí na celkové době transakce. Služba optimalizace a monitoringu výkonnostních problémů J2EE aplikací naší společností není bezprostředně vázána na produkty Wily, nicméně Wily Introscope se jeví jako vhodný a relativně cenově dostupný nástroj pro monitorování J2EE aplikací. Zvláště je oceňován pro svoji vysokou míru přizpůsobivosti individuálním požadavkům zákazníků. Gartner, Inc. umístila Wily Technology do lídr kvadrantu v oblasti J2EE Application Server Management (Magic Quadrant publikováno 6. května, 2003), jedná se tedy v této kategorii o jeden z předních softwarových produktů na trhu. 11

12 J2SE 5.0 revize poklidného života java programátora Jan Peremský, Zatím na konec září 2004 je plánováno uvolnění release nové verze Javy konkrétně J2SE 5.0. Jedná se o následníka současné verze J2SE 1.4.2, a jak již zvýšení verze z 1.4 rovnou na 5.0 napovídá, nejedná se jen o změny a rozšíření API (k těm samozřejmě také došlo), ale také o změny zásadnější změny v syntaxi a sémantice jazyka Java. Cílem tohoto textu není detailní a zevrubná analýza jednotlivých změn zaměřím se na jednoduchý popis nových prvků jazyka s ohledem především na jejich praktický dopad a možná využití v životě běžného Java programátora. V případě, že vás některé, zde uvedené, informace podnítí k hlubšímu studiu, v závěru uvádím několik užitečných odkazů, kde je možné najít detailnější informace, tutoriály, diskuze a specifikace změn jazyka. Nyní k jednotlivým novinkám: Generics šablony Představují pravděpodobně největší a také nejdiskutovanější změnu jazyka Java. Generic classes či templates či šablony označují, v kontextu programovacího jazyka, datovým typem parametrizovatelné datové typy tedy jakési metatypy (metaclasses). Nejlépe bude, ukážeme-li si to na jednoduchém případu. List<Value1> l = new LinkedList<Value1>(); Value1 v1 = new Value1( AAA ); Value2 v2 = new Value2( BBB,11); //Value2 je potomek Value1 l.add(v1); l.add(v2); for(iterator<value1> it = l.iterator();it.hasnext();){ Value1 v = it.next(); System.out.println(v); Obrázek 1 Jednoduché použití generics Jak je z příkladu patrno, pomocí generics jsme schopni parametrizovat třídu List vytvoříme seznam specifických datových typů (Value1 či potomků). Kompilátor zařídí typovou kontrolu a nutné přetypování. Knihovna standardních kolekcí java.util byla přepsána a obsahuje nyní třídy podporující generics. Pro většinu java programátorů je toto v podstatě dostačující informace o implementaci šablon v Javě. Používání již existujících tříd s podporou generics je jednoduchá a intuitivní záležitost. Detailnější pohled na věc je však podstatně komplikovanější. Zatímco např. v C++ slouží templates mimo jiné k možnosti definovat univerzální (generické) algoritmy například třídění, přičemž kompilátor následně pro každý template vyrobí de facto novou třídu, v Javě, naproti tomu, je možno takovéto univerzální algoritmy definovat i bez pomoci generics. Java je jazyk s dynamickými typy, kde každý element jazyka (mimo primitivních typů) dědí od Objectu případně implementuje nějaký Interface a tyto informace jsou dostupné i za běhu programu tudíž je možno napsat generický algoritmus pracující s jakýmkoliv Objectem resp. Interface, či jeho potomkem. To je také jeden z důvodů, proč jsou generics v Javě realizovány pomocí tzv. Erasure and Translation mechanismu. Jak to funguje? Kompilátor provede nezbytné typové kontroly, které je možno při překladu provést, smaže informace o generics < > a v místech, kde je to třeba, doplní typové konverze. Všechny úpravy probíhají na úrovni zdrojového kódu. V důsledku je tak pro ArrayList<String> i pro ArrayList<Integer> použita ta samá třída. Pozor oba listy samozřejmě sdílejí všechny statické proměnné!!! Dalšími problémy s generics vyvstávají při psaní vlastních tříd a metod podporujících generics a při nutnosti spolupráce kódu napsaného s podporou generics a kódu bez podpory generics. Více o této problematice viz (Odkaz 5). Následující příklad (Obrázek 2) ukazuje, jak definovat třídu s podporou generics. Jedná se o implementaci jednoduchého stromu, kde pomocí generics parametrizujeme obsah jednotlivých uzlů. Prakticky tak můžeme zabránit míchání jablek s hruškama v jednotlivých instancích takovéhoto stromu. import java.util.list; import java.util.linkedlist; public class GenNode<T> { protected T value;//hodnota uzlu protected GenNode<? extends T> supernode; //odkaz na nadrazeny uzel protected List<GenNode<T>> subnodes = new LinkedList<GenNode<T>>(); //podrizene uzly /** Konstruktor **/ public GenNode(T value) { this.value = value; /** Konstruktor, ktery prida novy uzel do zadaneho nadrazeneho**/ public GenNode(T value,gennode<t> supernode) { this.value = value; supernode.addsubnode(this); /** Vraci hodnotu uzlu **/ public T getvalue() { return value; /** Meni hodnotu uzlu **/ public void setvalue(t value) { this.value = value; /** Vraci podrizene uzly **/ public List<GenNode<T>> getsubnodes() { return subnodes; /** Pro pridani podrizeneho uzlu **/ public void addsubnode(gennode<t> subnode) { subnodes.add(subnode); subnode.setsupernode(this); /** Vraci nadrizeny uzel **/ public GenNode<? extends T> getsupernode() { return supernode; /** Pro nastaveni nadrizeneho uzlu **/ public void setsupernode(gennode<t> supernode) { this.supernode = supernode; Obrázek 2 Definice třídy s podporou generics K čemu jsou generics dobré a je výhodné je používat? Určitě ano. Nejlépe se generics osvědčí při práci s různými druhy kolekcí, map a stromů. Většina nejběžněji používaných z nich je již naprogramována a je součástí balíku java.util. Pokud je programátor pouze v pozici uživatele již existujícího kódu s podporou generics, ušetří spoustu času a zbytečných řádků vlastního kódu, který se navíc značně zprůhlední. Kompilátor zajistí silnější typovou konverzi a v důsledku tak zabrání některým potenciálním chybám typu ClassCastException za běhu programu. Je však otázkou, zda se pustit do psaní vlastních tříd podporujících generics. O této problematice bylo napsáno již mnoho článků (viz Odkaz 9) a záleží na posouzení každého, zda najde dobré důvody generics použít. Nutnou podmínkou je pak dobrá orientace v celkové problematice generics. Další výhodu generics (hlavně pak již hotových kolekcí) vidím pro nástroje sloužící k modelování a následnému generování koster kódu například UML nástroje. Vztahy např. 1:N mezi modelovanými třídami pak mohou být více adresné. Zde však vyvstává problém s reflexí generics jsou za běhu pomocí reflexe nevystopovatelné. Autoboxing primitivní datové typy a jejich objektové reprezentace Jednou z vlastností jazyka Java je současná existence tzv. primitivních datových typů (int, short, byte ) a jejich objektových reprezentací (Integer, Short, Byte ). V běžné praxi dochází k častým konverzím (new Integer(int) a Integer.intValue()) a to především z důvodu provádění aritmetických operací na jedné straně a na straně druhé při ukládání primitivních hodnot do různých objektových struktur zejména kolekcí. Cílem autoboxingu je zautomatizování takových konverzí. Následující příklad (Obrázek 3) ukazuje jednoduché použití autoboxingu v kódu. Integer I = 12; int j = I++; List<Integer> list = new ArrayList<Integer>(); list.add(0, new Integer(59)); //stary zpusob int n = (list.get(0)).intvalue(); // --#-- list.add(0, 50); // novy zpusob s pouzitim autoboxingu int m = list.get(0); // a generics (list of Integers) Obrázek 3 Použití autoboxingu Autoboxing je záležitostí kompilátoru. Ten automaticky provádí všechny skryté konverze. Ale pozor!!! autoboxing s sebou nese i následující důsledky: 1. Konverze null na primitivní hodnotu vede k NullPointerException. 2. Porovnávání referencí je nebezpečné a je třeba se mu raději vyhnout (důvodem je přesně nespecifikované cacheování některých instancí objektových reprezentací primitivních typů) 3. Některé aritmetické operace mohou mít jiné důsledky při práci s primitivními typy a jiné při práci s jejich objektovými reprezentacemi. Doporučuji vyzkoušet si následující příklad (Obrázek 4) a zamyslet se nad jeho výstupem. Integer I1 = ; Integer I2 = ; out.println(i1==i2); // vysledek je false I1 = 127; I2 = 127; out.println(i1==i2); //vysledek je true Obrázek 4 Problémy související s autoboxingem K čemu je tedy autoboxing dobrý a je vůbec dobrý? Určitě ano. Programátor ušetří mnoho zbytečných řádků kódu a ten se opět stane čitelnějším. Je však třeba mít neustále na paměti úskalí, která nadužívání autoboxingu může přinést (kompilátor netuší, jaký byl váš dobrý záměr!). Enhanced for loop rozšíření konstrukce for Jde o rozšíření syntaxe jazykové konstrukce for. Účelem je opět zjednodušení kódu v případech, kdy iterujeme prvky pole či např. kolekce po jednom prvku, aniž bychom zároveň měnili obsah pole či kolekce. Pro složitější případy stále funguje stávající konstrukce for. Nový for navíc pracuje i se šablonami. Následující příklad (Obrázek 5) ukazuje použití nové syntaxe for. Jde o iteraci přes všechny poduzly uzlu node1 viz Obrázek 3. for(gennode<value1> node : node1.getsubnodes()) { System.out.println(node.getClass().getName() +.value = + node.getvalue()); Obrázek 5 Použití enhanced for smyčky Enum výčtový typ Javě až doposud chyběl výčtový datový typ. V předchozích verzích se tento nedostatek řešil pomocí jednoduchých konstant či pomocí speciálního paternu (vzoru), na jehož základě vznikla třída představující výčtový typ s typovou a hodnotovou kontrolou. Sun do nové verze přidal implementaci výčtového typu (enum), která vychází z výše uvedeného paternu, navíc je však podporován ve for smyčce (viz enhanced for) a v konstrukci switch, což předchozí řešení postrádalo. Výčtové typy je možno využívat i pro anotace (viz dále). V balíku java.util navíc existují dvě speciální třídy (EnumSet a EnumMap), které slouží pro sofistikovanější využívání výčtových typů. Z následující ukázky by mělo být vše podstatné patrno. //vycet dnu v tydnu s priznakem, zda jsou pracovni public enum DayInWeek { Monday(true),Tuesday(true),Wednesday(true),Thursday(true), Friday(true),Saturday(false),Sunday(false); DayInWeek(boolean workingday) { this.workingday = workingday; private final boolean workingday; public boolean isworkingday() {return workingday; static void testenums(){ for(dayinweek diw : DayInWeek.values()) { System.out.println(diw); DayInWeek streda = DayInWeek.Wednesday; switch(streda) { case Monday : System.out.println( Pondeli + DayInWeek.Monday.isWorkingDay()); break; case Wednesday : System.out.println( Streda + DayInWeek.Monday.isWorkingDay()); break; Obrázek 6 Použití výčtového typu Enum Metadata anotace Metadata či anotace představují další významný doplněk jazyka Java. Anotace nemají žádný přímý vliv na běh programu. Umožňují pouze připojit dodatečné informace k jednotlivým elementům Javy (FIELD, METHOD, CLASS, PACKAGE ). Dále je možno specifikovat dostupnost a životnost anotací (SOURCE, CLASS, RUNTIME). Práce s anotacemi se dělí na dvě části: definice anotace a její struktury a použití anotace kódu. Anotace samy o sobě nemají žádné reálné využití, předpokládá se, že budou využívány především vývojovými nástroji a to především pro automatické generování kódu (např. pro EJB viz draft EJB 3.0 specifikace). Následující příklad (Obrázek 7) ukazuje jednak definici typu anotace včetně tzv. meta-anotací určujících umístění a životnost anotace. V druhé části příkladu je ukázáno použití a možnost využití reflexe k zjišťování hodnot existujících anotací Developer { int id(); //identifikator developera String name(); //jmeno developera String version() default 1.0 ; //verze (major.minor) /* zadani anotace = 12345,name = Johny )//pro verzi se pouzije default hodnota public static void metatest() throws Exception { Method met = Runner.class.getMethod( metatest,new Class[0]); if(met.isannotationpresent(developer.class)) { Developer a = met.getannotation(developer.class); out.println( ID : + a.id() + name : + a.name() + version : + a.version()); Obrázek 7 Definice a použití anotací Další změny Kromě výše uvedených hlavních změn a doplňků jazyka Java byly realizovány ještě následující kosmetické změny : a) Statický import slouží i importu statických fields a metod z dané třídy. Hlavní využití vidím v možnosti používání konstant definovaných v importovaných třídách bez nutnosti použití plného kvalifikátoru (class.field, stačí již jen field). b) Variabilní počet argumentů metod metody mohou být definovány s proměnným počtem parametrů. Jedná se o poslední parametr v definici metody, přičemž všechny takovéto parametry musí být stejného typu. c) Formátovaný vstup a výstup podobně jako v jazyce C. Jde o možnost načítat ze streamu a zapisovat do streamu položky definovaného typu a formátu. Závěrem Nová Java (J2SE 5.0) přináší mnoho zajímavých změn do syntaxe a sémantiky jazyka. Podle vývojářů od Sunu bylo hlavní motivací usnadnění práce java programátora. Nelze jim tedy upírat dobrý záměr. Teprve budoucnost ukáže, nakolik se záměr a především jeho realizace povedla. Má osobní, byť krátká, zkušenost je v podstatě pozitivní. Verze 5.0. je kompatibilní s předchozí verzí a také některá IDE (Netbeans, JBuilder, Eclipse, Idea,...) již mají podporu nových prvků jazyka zabudovánu či na ní usilovně pracují. Odkazy Odkaz 1 Hlavní stránka J2SE Odkaz 2 J2SE 5.0 hlavní prvky Odkaz 3 Popis změn jazyka Odkaz 4 Rozhovor s jedním z tvůrců změn Odkaz 5 Tutorial java generics 12

13 XML a databáze Oracle Jan Rada, rada@komix.cz Proč XML v databázovém serveru? Může se vyskytnout názor, že jeho místo je až na aplikačním serveru nebo ještě blíže k uživateli, kde jeho rozvláčnost nebude tak drahá. Řada úloh však vyžaduje uložení věrné kopie XML dokumentu a uložení v databázi má řadu výhod. Dalším argumentem je stále rostoucí význam XML jako standardu strukturovaných textových dat. Například součástí standardu SQL 2003 se stalo SQL/XML pro převod výsledků dotazování do dat XML, která lze poměrně snadno zobrazit v nejrůznějších formátech nebo je poslat do rozmanitých aplikací. V tomto příspěvku si přiblížíme, jak Oracle pomocí XML DB realizoval nativní XML databázi v rámci databázového serveru 9i resp. 10g. V závěru se zmíníme též o Oracle XML Developer s Kit (XDK). Způsoby uložení XML dokumentů v XML DB XML DB je sada rysů pro výkonné ukládání a vytahování XML dat. Je kompatibilní se standardy W3C a umožňuje provázaný přístup k týmž datům přes XML i SQL model. Je založena: na objektovém typu XMLType, který lze použít například jako typ sloupce tabulky, řádky objektového pohledu nebo proměnné PL/SQL, na funkcích SQL a jiných API pro práci s XML a na Repository podporující souboro/složkový přístup k datům XML. Co do způsobu uložení XML v databázi rozlišujeme dynamické generování XML z objektově relačních dat, uložení XML v XMLType/CLOB a plné využití možností typu XMLType. Při prvním způsobu se data XML generují v okamžiku potřeby například pomocí SQL funkcí; s výhodou lze přitom využít objektových typů dat nebo i zavést virtuální XML dokument jako objektový pohled typu XMLType. Daný způsob je výhodný, pokud se nepožaduje věrná kopie dat XML, struktura XML se nemění a neobsahuje velký počet úrovní, jsou časté dílčí změny dat a je vysoký stupeň současnosti těchto změn. Daný způsob je obecně vhodný pro úlohy intenzivně pracující s položkami dat, například pro integraci podnikových aplikací nebo e-byznysu. Při druhém způsobu jsou data XML uložena v položce typu CLOB nebo XMLType s volbou fyzického uložení CLOB. Data jsou pak vždy ukládána, vytahována a aktualizována jako celek, což je výhodné pro úlohy pracující s celými dokumenty, například pro prezentaci dokumentů na Webu a pro content management. K vyhledávání v XML dokumentech a ke zjišťování jejich fragmentů jsou k dispozici SQL funkce využívající jazyka XPath. Vyhledávání bude zřejmě pomalejší než pro relační data, ale konkrétní dotazy lze urychlit zavedením funkčních indexů. K vyhledávání lze použít též indexů, SQL funkcí a operátorů poskytovaných komponentou Oracle Text. Pro plné využití možností typu XMLType je charakteristické namapování schématu XML na objektově relační struktury. Namapování vyžaduje registraci schématu, při níž se generují objektové typy a defaultní tabulky, do kterých se bude XML rozkládat. Mapování XML-SQL lze řídit anotací schématu pomocí atributů ze jmenného prostoru xdb. Na straně databáze jej pak lze pozměnit například volbou způsobu fyzického uložení konkrétní položky XMLType, spojenou s určením elementu XML, který v ní má být uložen. V současné době lze volit mezi objektově relačním uložením a uložením v CLOB. Podle toho je zachována buď jen DOM-věrnost (pořadí elementů, komentáře, instrukce pro zpracování) nebo i úplná věrnost XML (včetně bílých znaků). Způsob fyzického uložení XMLType je transparentní pro funkce nad XML; objektově relační uložení je ale úspornější a výhodnější například z hlediska možností indexace, dílčí aktualizace XML a query rewrite výrazů jazyka XPath. Vyššího výkonu se v XML DB dosahuje též pomocí virtuálního DOM a cachování schémat XML. Naznačený způsob uložení XML je vhodný zejména pro úlohy kombinující práci s dokumenty a daty při pevných schématech. Při rozsáhlejších změnách schémat by mohlo být náročné udržovat namapování schémat XML na objektově relační struktury. V řadě úloh, například v content managementu, se uplatňuje též další, poměrně samostatný rys XML DB Repository. Repository umožňuje zařazovat XML data do hierarchie složek a dokumentů, přistupovat k nim (kromě SQL) též pomocí FTP, HTTP a WebDAV, spravovat jejich verze a řídit přístupová práva. Pro reprezentaci odkazů na data v Repository, ale i na běžná databázová data a na HTTP adresy je zaveden datový typ URI- Type, včetně nástrojů schopných interpretovat takové odkazy na webových stránkách. SQL funkce a programátorská rozhraní pro práci s XML Pro práci s XML slouží v databázi Oracle několik skupin zabudovaných SQL funkcí, které se do jisté míry překrývají: metody objektového typu XMLType, funkce SYS_XMLGEN a SYS_XMLAGG a funkce SQLX. Většinu funkcí zde pouze vyjmenujeme; základní funkce si později ukážeme na příkladech. K metodám typu XMLType patří konstruktor XMLType (a jeho statická varianta createxml), funkce extrakt pro zjištění fragmentu XML určeného výrazem jazyka Xpath, funkce getstringval, existsnode, schemavalidate, transform a další. K funkcím SQLX řadí Oracle funkce XMLElement, XMLForrest, XMLAttributes, XMLConcat a XMLAgg ze standardu SQL/XML a navíc funkce ExtractValue, Extract, UpdateXML, XMLTransform, XMLSequence a XMLColAttVal, na jejichž začlenění do standardu spolupracuje. Funkce XMLElement vytváří element zadaného jména ze zadaných SQL výrazů a umožňuje též určit atributy elementu pomocí vnořeného volání funkce XMLAttributes. Funkce XMLAgg slouží pro zřetězení elementů vytvářených v agregovaných řádcích dotazu. Funkce SYS_XMLGEN a SYS_XMLAGG jsou mírně odlišnou obdobou funkcí XMLElement a XMLAgg umožňují například upravit tvar XML parametrem typu XMLFormat a jejich výsledkem je vždy dobře zformované XML. Funkce SQL/XML se ale obecně zdají pro generování XML pohodlnější pokud se nám nehodí defaultní pravidla pro převod mezi SQL a XML daty. Souhrnem defaultních převodních pravidel je dán tzv. kanonický tvar XML. Kanonický dokument XML obsahuje element ROWSET, elementy ROW a elementy pojmenované podle sloupců tabulek a objektových typů či jejich atributů. Kolekce se převádí na seznam opakujících se elementů s atributem num (pořadí). Sloupec se na první pozici jména se mapuje na atribut elementu XML. Do XML DB jsou řazena též programátorská rozhraní pro PL/SQL, Javu, C a C++. Poslední verze rozhraní pro PL/ SQL obsahuje balík DBMS_XMLGEN generující XML z výsledku SQL dotazu, DBMS_XMLSTORE pro ukládání XML do relačních tabulek, DBMS_XMLSCHEMA pro registraci a podporu rozvoje schémat, balíky s rozhraním na Repository a URIType a dále balíky DBMS_XMLParser, DBMS_XSLProcessor a DBMS_ XMLDOM souhrnně označované jako PL/SQL API pro XMLType. Obdobná rozhraní typu DOM pro XMLType jsou k dispozici též pro Javu a C/C++. Příklady na SQL funkce pro práci s XML /* Uložení XML v XMLType/CLOB, funkční index pro jedinečnost eid */ CREATE TABLE ex (e XMLType); CREATE UNIQUE INDEX iex ON ex(e.extract( //eid/text() ).getnumberval()); INSERT INTO ex VALUES (XMLType( <?xml version= 1.0?> <erow nmattr= First > <eid>221</eid> <ename>petr</ename> </erow> ) /* data A */ ); /* Dotazy na XML */ SELECT ex.e.getstringval() AS erows FROM ex ex; /* výsledek data A */ SELECT ex.e.extract( //ename/text() ), ex.e.extract( /erow/@nmattr ) FROM ex ex WHERE ex.e.existsnode( //ename )=1; /* Generování XML z relačních dat pomocí SQL/XML */ CREATE TABLE e (eid NUMBER, ename VARCHAR2(60), deptid NUMBER); INSERT INTO e VALUES (221, Petr,NULL); SELECT XMLElement( erow, XM LAttributes( First AS nmattr ), XMLForest(eid AS eid, ename AS ename )) AS erows FROM e; /* výsledek data A bez úvodní poznámky a bílých znaků */ SELECT XMLElement( dept,deptid, XMLAgg(XMLElement( ename,ename))) AS Depts FROM e group by deptid; /* výsledek-pro každé oddělení jeho id a seznam jmen zaměstnanců */ /* Aktualizace XML */ UPDATE ex SET e=updatexml(e, erow/@nmattr, Last ) WHERE ExtractValue(e, //eid/text() )=221; /* Generování XML z obj.relačních dat pomocí pohledu typu XMLType */ CREATE TYPE etype AS OBJECT VARCHAR2(10), eid NUMBER, ename VARCHAR2(60)); / CREATE VIEW exdyn OF XMLType WITH OBJECT ID (sys_nc_rowinfo$.extract( //eid/text() ).getnumberval()) AS SELECT sys_xmlgen(etype( First, eid, ename), xmlformat.createformat( erow )) FROM e; SELECT e.getclobval() AS erows FROM exdyn e; /* výsledek data A */ Další prostředky Oracle pro XML Databázový server Oracle obsahuje řadu dalších prostředků, které nejsou primárně určeny pro práci s XML, ale pomáhají řešit praktické problémy XML aplikací. Výčet těchto prostředků, nemluvě o prostředcích pro podporu XML obsažených v aplikačním serveru a vývojových nástrojích Oracle, leží mimo možnosti tohoto článku. Zmiňme se pouze o prototypové implementaci jazyka XQuery a o sadě nástrojů a programátorských rozhraní XDK, která je přibalena k databázovému a aplikačnímu serveru, lze ji ale stáhnout též samostatně ze stránek otn.oracle.com/xml a provozovat nezávisle na obou serverech. Oracle XDK podporuje Javu, C, C++ a PL/SQL. XDK se rychle rozvíjí v návaznosti na nové verze standardů, zvyšování výkonu a unifikaci rozhraní fungujících uvnitř XML DB a mimo databázi. Varianta pro PL/SQL je utlumována, naopak nejbohatší je varianta pro Javu z obvyklých rozhraní obsahuje XML Parser (rozhraní typu DOM, SAX a JAXP), XML Schema Processor, XSLT Processor, JAXB Class Generator, XML Pipeline Processor a podporu SOAP. Navíc obsahuje též specifická rozhraní na utility XSU a TransX, XML JavaBeans a podporu XSQL stránek. Přibližme si dva z nástrojů, které jsou za specifickými rozhraními. Utilita XSU slouží pro generování XML z výsledku SQL dotazu. Vytváří kanonický tvar XML, který lze mírně upravit pomocí parametrů nebo transformovat pomocí XSLT. Umí též ukládat, aktualizovat a rušit zadaná data XML v databázi, generovat DOM, DTD a XML schemata ze SQL dotazů apod. S databází komunikuje pomocí JDBC. XSQL Pages umožňují zadat požadavky na generování dynamických stránek s databázovým obsahem. Požadavek má formu XML souboru s SQL příkazy a volitelným předpisem XSLT transformace. Při interpretaci XSQL stránek se využívá též utilita XSU. Stránky lze provozovat na jakémkoli Web serveru s podporou Java servletů, nebo i nezávisle na Webu, například voláním z příkazové řádky. Oracle XDK pro C/C++ zahrnuje oproti variantě pro Javu též komponentu XVM, zajišťující rychlejší a pamětově úspornější transformace XSLT. Komponenta obsahuje XSLT Compiler, který překládá transformační skripty do platformově nezávislého kódu pro XSLT Virtual Machine. Databázový server Oracle spolu s aplikačním serverem a vývojovými nástroji Oracle vytvářejí ucelený a efektivní rámec pro vývoj, zavádění a provozování XML aplikací, od aplikací prezentujících informace na Webu po integraci podnikových aplikací nebo e-byznysu. Poskytujeme testování softwarových aplikací Vysoce kvalifikovaný testovací tým nabízí: Informace jsou to nejcennější, co máte! Metodickou podporu procesu testování Funkční a zátěžové testování aplikací Nezávislé akceptační testování dodávek softwaru Sledování dostupnosti a výkonnosti informačních systémů Konzultace a školení v oblasti testování sales@komix.cz, 13

14 Test znalostí IT sebral a sestavil Tomáš Vahalík, vahalik@komix.cz Vážení čtenáři, v následujícím testu si můžete nejen vyzkoušet své znalosti z oblasti informačních technologií, ale současně máte i jedinečnou příležitost nahlédnout do mentality výrobců softwaru, který už možná používáte nebo o tom zatím alespoň uvažujete. Následující test byl totiž sestaven z příspěvků zaměstnanců společnosti KOMIX. 1. Dr. Watson je a) literární postava, přítel slavného detektiva, který nebyl bezdomovcem ač je za něj někdy pokládán b) náš spolupracovník, autor produktu KMX WAT (Web Administration Tool Informix, Unix ke stažení na isn#kmxwat) c) syn skotského inženýra Jamese Watta d) nejméně oblíbený člen projektového týmu, který přichází obvykle těsně před tím, než jste si uložili svoji práci. 2. Servlet je a) server leteckého navigačního systému automatického pilota b) malý javovský program běžící na web serveru c) eskymácký výraz pro mobilní WC. 6. Kosmetické úpravy jsou a) krycí název pro zásadní změny v projektu těsně před termínem předání b) nastrčení vnadných spolupracovnic na předávání kvapné práce (málo platné) c) v terminologii šéfů rozsáhlé změny prováděné v minimálním čase d) výmluva programátora při zdůvodnění zpoždění zaviněného prací na poslední chvíli e) pokus, jak upoutat pozornost k vlastnímu zevnějšku místo na pracovní výsledky. 7. Hot Key slouží k a) rozmražení zamrznutého počítače (známé také jako defrost ) b) rychlému vyvolání často používané operace c) ovládání klimatizace (v kombinaci s klávesou windows) d) zahřátí procesoru na provozní teplotu v případě pomalého běhu aplikace. 3. CORBA je a) nástavba nákladního automobilu pro přepravu nákladu b) největší jedovatý had s délkou až šest metrů, který je schopen zabít i dospělého člověka c) vymakaný svalovec z posilovny (jinak také slangově Korbič) d) architektura pro podporu tvorby distribuovaných objektově orientovaných aplikací. 4. TestDirector je a) ředitel, který cílenými otázkami a úkoly testuje své podřízené b) software pro správu a řízení procesu testování c) ředitel, který byl do své funkce dosazen na zkoušku a je testován svými podřízenými co vydrží. 5. Mercury je a) jedna z planet sluneční soustavy b) příjmení bývalého frontmana skupiny Queen c) společnost s vedoucím postavením na trhu v oblasti testovacích nástrojů d) stavebnice pro tvořivá dítka. 8. 4GL je a) byt s garáží a lodžií b) časopis For Gays and Lesbiens c) jazyk čtvrté generace. 9. KOMIX je a) obrázkový časopis, kde se mluví v bublinách b) výraz používaný programátory, kterým označují analytika vytvářejícího UML diagram plný panáčků a bublin c) veselý přítel Asterixe a Obelixe d) devátý komunikační port e) Klub Obdivovatelů MIchaela foxe f) integrace textu a obrazu specifickými prostředky g) český systémový integrátor zaměřený na dodávky vlastních řešení. Řešení tajenky z minulého čísla: Nikola Tesla KOMIX s.r.o. je systémový integrátor zaměřený na dodávky vlastních řešení informačních systémů s využitím moderních a ověřených technologií. Svým klientům poskytuje služby ve všech fázích životního cyklu informačního systému od definice požadavků na jeho funkčnost, až po provedení akceptačních testů a podporu jeho provozu. KOMIX se přitom spoléhá především na vlastní vývoj, know-how a tým odborníků, kteří se dokonale orientují v informačních technologiích, znají potřeby svých zákazníků a mají praktické zkušenosti z realizace rozsáhlých systémů. Hlavními kritérii úspěšnosti našich projektů jsou míra spokojenosti zákazníka a trvale dobré vztahy. Předáním systému spolupráce nekončí, ale pokračuje ve formě technické podpory, školení a dalších navazujících služeb. Společnost KOMIX byla založena v září 1992 v Praze. V současné době má 95 zaměstnanců. KOMIX ověřená kvalita produktů a služeb KOMIX s.r.o. Holubova 1, Praha 5, tel.: , fax: , sales@komix.cz, Redakční zpracování: kolektiv pracovníků KOMIX s.r.o., DTP a produkce: ARDEA grafické studio, s.r.o. KOMIX s.r.o