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

Transkript

V
Á
Š
S
P
O
L
E
H
L
I
V
Ý
P
A
R
T
N
E
R
V
E
S
V
Ě
T
Ě
I
T
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, [email protected]
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, [email protected]
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
V
Á
Š
S
P
O
L
E
H
L
I
V
Ý
P
A
R
T
N
E
R
V
E
S
V
Ě
T
Ě
I
T
Systém TARIC pro Generální ředitelství cel
Architektura
systému
a
jeho
Ú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.
Martin Lipš, Jiří Marschal
[email protected]; [email protected]
stránky
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.
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
www
browser
HTTP
HTML
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 EDIFACT 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 e-mailem.
Architektura systému
silné
Generální
ředitelství cel ČR
NIT
SQL
národní integrovaný tarif
Administrativa EU
TARIC EU
databáze tarifních
opatření pro EU
Celní úřady
TARIC ČR
CCN/CSI
EDIFACT
UNLOAD
FTP
databáze tarifních
opatření pro ČR
libxml2
libxslt
CDS
celně deklarační
systém
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
taric_cz
kompletní databáze
tarifních opatření
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
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.
Export
tarifních
opatření
view
view
CCN/CSI
EDIFACT
UNION
Aplikace
NIT
taric
nit
zrcadlo TARIC EU
národní opatření
národní
integrovaný
tarif
triggery
triggery
taric_log
nit_log
logování změn
v databázi taric
logování změn
v databázi nit
Session
holder
session1
session2
...
sessionN
taric_mng
řídící a metadatová
databáze
Obrázek 2
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.
Formát XML/XSLT je použit
pro generování HTML
I B M In f o r m ix D y n a m ic se r v e r 9 .3 0
IPC
APACHE/
1.3.27
mod_fastcgi/
2.4.0
Obrázek 3
Aplikace je řízena metadaty
UNLOAD
FTP
HTTP server
CGI
šablony
xslt
Obrázek 1
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).
Aplikační
logika
msg.queue
řídící databáze
(metadata)
Pracovní databáze
logovací databáze
DBI – ESQL/C
IBM INFORMIX
FastCGI
Aplikační server
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
Odposlechnuto na autobusové zastávce;
aneb Mercury už není jen o testování.
Dan Petřivalský, [email protected]
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
2
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
V
Á
Š
S
P
O
L
E
H
L
I
V
Ý
P
A
R
T
N
E
R
V
E
S
V
Ě
T
Ě
I
T
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 TestDirector 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
Mercury IT Governance
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í.
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.).
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
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.
Otakar Brabec, [email protected]
Největší objem potřeb je rutinního charakteru. přesných, průběžně aktualizovaných informací
Sem patří především údržba a rozvoj stáva- pro rozhodování v oblasti IT portfolia.
jícího systému, popř. aplikací a odstraňování
provozních chyb. Na druhé straně stojí potřeby
Mercury Program Management
koncepčního charakteru. Jedná se o kvalitativní (Správa programu)
změny provozovaného IS nebo budování novéV úvodu tohoto odstavce je třeba říct, že
ho systému. Demand Management umožňuje
„program“ v rámci ITG představuje nadřízený
konzolidovat a ukládat do centrální databáze
celek projektovému řízení. Program je souhrn
všechny firemní požadavky. Provádět prioritiprojektů, které slouží k řešení firemních prozaci a plánovat řešení požadavků na základě
cesů prostřednictvím IT. Program Management
uvedených priorit, časových aspektů, přínosů
pomáhá v procesu správy a řízení programů
či měření. Podchycuje a kompletuje informace
počínaje koncepční fází až do fáze kompletace.
o průběhu řešení pro účely IT auditu.
Umožňuje digitalizaci procesů za účelem řízeHlavním přínosem tohoto modulu je podchyní rozsahu řešené problematiky, rizika, jakosti
cení a sledování firemních požadavků v průběa plánování. Výsledkem je komplexní program
hu celého životního cyklu požadavku.
v nejvyšší kvalitě dodaný v požadovaném čase
a v rámci stanoveného rozpočtu. Důležitým
Mercury Portfolio Management prvkem tohoto modulu je PMO (Program
(Správa portfolia)
Management Office), nástroj pro multiproPortfolio Management nám dává možnost jektové řízení.
spravovat portfolio IT prostřednictvím vyhodHlavním přínosem tohoto modulu je komnocování, prioritizace, bilancování a schvalování
plexní monitoring multiprojektových prograjak nových činností v rámci IT, tak i stávající
mů a kontrola detailních informací aktuálních
portfolio aktivit. Zprostředkovává analýzy růz- projektů v reálném čase.
ných scénářů a zajišťuje přizpůsobení „byznys
strategie“ s omezeními zdrojů umístěných Mercury Project Management
v útvarech IT. Integruje strategická, finanční, (Správa projektu)
funkční a technická měřítka v rámci jednotného
Ří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í)
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.
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í
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
V
Á
Š
S
P
O
L
E
H
L
I
V
Ý
P
A
R
T
N
E
R
V
E
S
V
Ě
T
Ě
I
T
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.
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
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.
Æ¹Ã¸ÊË ÌYÀÍ¸Ë¼Ã

»¼Ä¸Å» ÇÆÉË½ÆÃÀÆ ÇÉÆ¾É¸Ä ÇÉÆÁ¼ºË ËÀÄ¼ º¿¸Å¾¼
Ä¾ÄË
Ä¾ÄË
Ä¾ÄË
Ä¾ÄË Ä¾ÄË Ä¾ÄË
·êèÞãÚèè
ÀäãØäëêÞëÖéÚá
·êèÞãÚèè
ÅçäßÚàéäëâÖãÖÚç
Í
Í
Í
Í
·êèÞãÚèè
¶ãÖáîéÞà
Í
Í
Í
Í
·êèÞãÚèè
ÂÖãÖÚç
Í
Í
Í
Í

¾É
¾ÉâÖãÖÚç
Í
Í
Í
Í
Í
¾É
¾ÉÖãÖáîéÞà
Í
Í
¾É
ËëäßäëåçÖØäëãmà
Í
Í
Í
¾É
ÅäçéÛäáÞäâÖãÖÚç
Í
Í
¾É
ÅçäßÚàéäëâÖãÖÚç
Í

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ří
IT
Zpracování
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
4
Í
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.
IT and dissemination strategies
Sběr dat
Í
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.
Strategie pro ČSÚ
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
Í
Í
tab. 1 Možnosti nasazení jednotlivých modulů
Č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
Co bylo předmětem projektu?
Í
obr. 2 Procesy Mercury IT Governance
Mercury Change Management
(Správa změnového řízení)
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í.
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.
Šíř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
Tomáš Hrubý, [email protected]
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
Práce na tvorbě strategie byla rozdělena do
třech hlavních etap. V první etapě byla po-
psá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
V
Á
Š
S
P
O
L
E
H
L
I
V
Ý
P
A
R
T
N
E
R
V
E
S
V
Ě
T
Ě
I
T
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 mu-
Podpořte své pojišťovací agenty
a obchodní kanály
sely 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í.
Jana Hamadová, Jan Rádl
[email protected]; [email protected]
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
V
Á
Š
S
P
O
L
E
H
L
I
V
Ý
P
A
R
T
N
E
R
V
E
S
V
Ě
T
Ě
I
T
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.
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é řízení
Specifický projektový postup
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é
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
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ů.
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
Odhadujete pracnost projektu?
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 ko-
6
munikace, 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 70-80 % 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].
Rozdělení pracnosti
7%
8%
Tomáš Vahalík, [email protected]
Analýza
Detailní návrh
16 %
Kódování a jednotkové
testy
18 %
17 %
Integrační a sytémové
testy
Dokumentace
34%
Instalace a nasazení
obrázek 1: Rozdělení pracnosti
Analogie
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 :
„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
V
Á
Š
S
P
O
L
E
H
L
I
V
Ý
P
A
R
T
N
E
R
V
E
S
V
Ě
T
Ě
I
T
Nelineární závislost
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.
Cena
Pracnost
Termíny
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
nete 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í.
problémy vyplývající
z nereálného plánu
Podhodnocení
< 100 %
viz. Parkinsonův zákon
Nadhodnocení
100 %
> 100 %
Odhad jako procento skutečné pracnosti
obrázek 3: Dopad správnosti odhadu
x = skutečná pracnost
2x
1x
Lineární závislost
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
Úvodní studie
Návrh
Programování
Požadavky
Předání
0,5x
0,25x
V průběhu práce na projektu
je k dispozici stále více informací
a odhady jsou přesnější
Čas
obrázek 2: Zpřesňování odhadu
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á).
Karnerova metoda
Use Case Points
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
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.
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 www.komix.cz (sekce Ke stažení). Tam nalez-
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í:
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.
[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
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“.
Výhody a nevýhody
metody UCP
Martin Janček, [email protected]
• 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= http://
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.
Síť
Aplikace/klient
SOAP
SOAP
Webová služba
HTTP
Obrázek č.1
Základní princip komunikace pomocí SOAP
Webová služba
Aplikační kód
Aplikační klient
Platformově
a jazykově
specifická
komunikace
Platformově
a jazykově
nezávislá
komunikace
Obrázek č.2
Webové služby a komunikace pomocí SOAP
7
V
Á
Š
S
P
O
L
E
H
L
I
V
Ý
P
A
R
T
N
E
R
V
E
S
V
Ě
T
Ě
I
T
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, kon-
takty 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
+
=
Privátní klíč
adresáta
+
=
Obrázek č. 4 – Šifrování
Rozšíření SOAP zprávy pak vypadá následovně:
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-SecureConversation (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í.
<SOAP-ENV:Envelope
xmlns:SOAP-ENV=http://schemas.xmlsopap.org/soap/envelope/
xmlns:WSSE=”http://schemas.xmlsoap.orgws/2002/12/secext”>
<SOAP-ENV:Header>
<WSSE:Security>
…
</WSSE:Security>
</SOAP-ENV:Header>
<SOAP-ENV:Body>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
Správa identit s využitím adresářových služeb
Jan Krejčí, [email protected]
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, 2003 – 24
miliard USD, 2002 – 8,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.
8
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).
V
Á
Š
S
P
O
L
E
H
L
I
V
Ý
P
A
R
T
N
E
R
V
E
S
V
Ě
T
Ě
I
T
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
Informační podpora
technologických procesů
Ú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ý
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.
Jan Vrána, [email protected]
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
V
Á
Š
S
P
O
L
E
H
L
I
V
Ý
P
A
R
T
N
E
R
V
E
S
V
Ě
T
Ě
I
T
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 speci-
fické 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
10
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
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
Ω3 – celek
Ω3 – entita
Logická
Ω3 – vazba
Ω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
Ošetření chyb v aplikacích – jaké údaje
zaznamenávat při vzniku chyby
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í.
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.
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.
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.
Petr Sobotka, [email protected]
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í.
V
Á
Š
S
P
O
L
E
H
L
I
V
Ý
P
A
R
T
N
E
R
V
E
S
V
Ě
T
Ě
I
T
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: 2004-06-30 15:37:01.560
Misto: module2.c:func_B (158)
ID procesu: 25031
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 = 48.23
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
[email protected]; [email protected]; [email protected]
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ů.
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
Workstation
Introscope
Enterprise
Manager
User Defined
Scripts
(stdout)
Introscope J2EE Application
Agent
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.
Introscope J2EE Application
Agent
Application Server
JVM
Historical
Data
Obr. 1.1.: Introscope Architecture
11
V
Á
Š
S
P
O
L
E
H
L
I
V
Ý
P
A
R
T
N
E
R
V
E
S
V
Ě
T
Ě
I
T
J2SE 5.0 – revize poklidného života java programátora
Jan Peremský, [email protected]
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
12
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 = 123456; Integer I2 = 123456;
out.println(I1==I2); // vysledek je false
I1 = 127; I2 = 127;
out.println(I1==I2); //vysledek je true
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í za běhu.
@Retention(RetentionPolicy.RUNTIME) @Target({ElementType.METHOD})
public @interface Developer {
int id();
//identifikator developera
String name();
//jmeno developera
String version() default „1.0“; //verze (major.minor)
}
/* zadani anotace */
@Developer(id = 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í
Obrázek 4 – Problémy související s autoboxingem
Další změny
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!).
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.
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í
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 5.0
http://java.sun.com/j2se/1.5.0/index.jsp
Odkaz 2 – J2SE 5.0 hlavní prvky
http://www.jcp.org/en/jsr/detail?id=176
Odkaz 3 – Popis změn jazyka
http://java.sun.com/developer/technicalArticles/releases/j2se15/
Odkaz 4 – Rozhovor s jedním z tvůrců změn
http://java.sun.com/features/2003/05/bloch_qa.html
Odkaz 5 – Tutorial java generics
http://java.sun.com/j2se/1.5/pdf/generics-tutorial.pdf
V
Á
Š
S
P
O
L
E
H
L
I
V
Ý
P
A
R
T
N
E
R
V
E
S
V
Ě
XML a databáze Oracle
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 URIType, včetně nástrojů schopných interpretovat takové odkazy
na webových stránkách.
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 znakem @
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
(“@nmattr“ 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 */
M e t o d i c k o u p o d p o r u p ro c e s u t e s t o v á 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í
s a l e s @ k o m i x . c z ,
T
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.
Vys oc e kva
Vysoce
kvallii f ikov
i kovaný
aný t est ov
o v a cí
c í tý
tým n
na
a bí
b íz
z í:
nejcennější, co máte!
I
Další prostředky Oracle pro XML
Poskytujeme testování softwarových aplikací
Informace jsou to
Ě
Jan Rada, [email protected]
SQL funkce a programátorská
rozhraní pro práci s XML
•
•
•
•
•
T
w w w . k o m i x . c z
13
V
Á
Š
S
P
O
L
E
H
L
I
V
Ý
P
A
R
T
N
E
R
V
E
S
V
Ě
T
Ě
I
T
Test znalostí IT
sebral a sestavil Tomáš Vahalík, [email protected]
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
6. Kosmetické úpravy jsou
a)
literární postava, přítel slavného detektiva, který nebyl bezdomovcem ač je
a)
za něj někdy pokládán
b) nastrčení vnadných spolupracovnic na předávání kvapné práce (málo platné)
b) náš spolupracovník, autor produktu KMX WAT (Web Administration Tool
– Informix, Unix – ke stažení na http://www.komix.cz/produkty.php?go=pro_
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
isn#kmxwat)
c)
krycí název pro zásadní změny v projektu těsně před termínem předání
poslední chvíli
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ě
e)
pokus, jak upoutat pozornost k vlastnímu zevnějšku místo na pracovní
výsledky.
před tím, než jste si uložili svoji práci.
7. Hot Key slouží k
2. Servlet je
a)
a)
b) rychlému vyvolání často používané operace
server leteckého navigačního systému automatického pilota
rozmražení zamrznutého počítače (známé také jako „defrost“)
b) malý javovský program běžící na web serveru
c)
c)
d) zahřátí procesoru na provozní teplotu v případě pomalého běhu aplikace.
eskymácký výraz pro mobilní WC.
ovládání klimatizace (v kombinaci s klávesou windows)
3. CORBA je
8. 4GL je
a)
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)
byt 3 + 1 s garáží a lodžií
b) časopis For Gays and Lesbiens
c)
jazyk čtvrté generace.
vymakaný svalovec z posilovny (jinak také slangově Korbič)
d) architektura pro podporu tvorby distribuovaných objektově orientovaných
aplikací.
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
4. TestDirector je
a)
diagram plný panáčků a bublin
ředitel, který cílenými otázkami a úkoly testuje své podřízené
c)
veselý přítel Asterixe a Obelixe
b) software pro správu a řízení procesu testování
d) devátý komunikační port
c)
ředitel, který byl do své funkce dosazen na zkoušku a je testován svými
e)
Klub Obdivovatelů MIchaela foXe
podřízenými co vydrží.
f)
integrace textu a obrazu specifickými prostředky
g) český systémový integrátor zaměřený na dodávky vlastních řešení.
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.
Ř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, 150 00 Praha 5, tel.: +420 225 989 811, fax: +420 225 989 803, [email protected], www.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. 2004
14