Již dlouhá léta můžeme slýchat ze všech stran nářky o přetrvávající softwarové krizi. Alarmující statistiky nás stále dokola přesvědčují o problematičnosti tvorby SW, o chybovosti vytvářených programových systémů a nekompetentnosti jejich tvůrců. Problém tohoto druhu nepochybně existuje, stejně tak jako existují teoretické návody jak ho odstranit, nebo alespoň částečně potlačit. S boomem objektových technologií na přelomu osmdesátých a devadesátých let se zdálo, že byl mohl být lék na tyto neduhy nalezen. Vše, co bylo před objekty se náhle zavrhovalo jako nepoužitelné zastaralé technologie nevyhovující dnešním požadavkům. Objekty byly zkrátka všude. Onen přívlastech "object-oriented" si našel cestu do slovníků mnoha vývojářů, uživatelů a především obchodníků, aniž by byla často pochopena alespoň základní filosofie tohoto nového přístupu. I přes snahu o osvětu ze strany zainteresovaných odborníků a inovátorů si po pár letech každý při vyslovení pojmu objekt ihned představil nástroje jako Visual Basic nebo Delphi.
Metoda tvorby RAD (Rapid Application Development) přímo podporovaná těmito nástroji se stala na dlouhá léta zaklínadlem. Bohužel. Návrh SW se tak někdy zůžil na poskládání připravených komponent GUI, často bez přihlédnutí k nutnosti zabývat se věcmi jako analýza apod. Takový přístup samozřejmě funguje pro relativně nenáročné aplikace, jejichž funkčnost stojí většinou nad jednoduchou manipulací databází, ovšem při trochu složitějších problémech může být použití RAD bez dalších adekvátních prostředků docela ošemetnou záležitostí.
Tvorba SW se často podobala a stále ještě někdy podobá všemu možnému jen ne pečlivé inženýrské práci, která by snad dokázala alespoň trochu eliminovat rizika spojená s vytvářením informačních systémů. Inženýrská práce se vyznačuje především dodržováním určitých standardů, respektováním nejrůznějších doporučení a používáním adekvátních nástrojů. O tom všem je tento článek.
Životní cyklus tvorby IS
Tvorba IS je komplexnějším problémem, než se na první pohled může zdát. Stále se můžeme nezřídka setkat s názorem, že se tvorbou IS rozumí především činnosti související přímo s programováním. Samozřejmě i tato etapa má nezastupitelné místo v celém tzv. životním cyklu IS, ovšem její přeceňování na úkor ostatních činností se někdy může výraznou měru podepsat, bohužel většinou negativně, na kvalitě výsledného systému.
Opomineme-li případ, že ne každý IS musí být nutně postaven na počítačových technologiích, je stále více než žádoucí provést před samotnou implementací detailní analýzu a návrh. Především na etapu analýzy se často nahlíží "skrz prsty" jako na víceméně zbytečnou činnost, jejímž hlavním úkolem je nechat se dostatečně zaplatit. Jejím výstupem bývá pouze dokumentace, obvykle ve formě "jakýchsi nesrozumitelných diagramů", která mnohdy u zadavatelů nemusí vzbuzovat moc důvěry. Do jisté míry je tento postoj oprávněný. Zadavatel, budoucí uživatel ještě neexistujícího systému, upíná všechnu svoji pozornost především na samotnou implementaci a vše ostatní chápe často jako nutné zlo. V horším případě je pod tlakem uživatelů analýza provedena co nejrychleji (tzn. často nedůkladně, povrchně a nekvalitně), v "lepším" případě může být zdánlivě zdlouhavá a nicnepřinášející analýza důvodem ke vzniku nežádoucího napětí mezi oběma stranami. Je zřejmé, že ani jedna z možností není zrovna ideální. Úkolem týmu řešitele by tedy měla být i jakási osvěta vysvětlující nutnost a oprávněnost i činností úzce nesouvisejících přímo s programováním.
Chápeme-li etapu analýzy v širším smyslu, je jedním z úkolů i sběr a utřídění uživatelských a systémových požadavků. Může se to zdát možná trochu paradoxní, ale uživatel často ani přesně neví, co chce. S postupem času by se měly představy zadavatelů i řešitelů ohledně funkčnosti a celkovém účelu systému maximálně shodovat. Za často problematický přístup lze označit počínání zadavatele, který se snaží hned od začátku vnutit řešiteli své vlastní představy o technickém provedení a podobě celkového řešení. Je samozřejmě účelné a hlavně nezbytně nutné konzultovat požadavky kladené na systém přímo s uživatelem, ovšem otázky spojené se samotnou realizací je vhodné nechat zprvu otevřené a soustředit všechnu pozornost a úsilí na definování požadované funkčnosti budoucího systému. V ideálním případě je vhodné zaměřit se i na pracovní postupy, které má nový IS podpořit. Celý problém se tak rozšiřuje směrem k BPR (Business Process Reengineering), jehož cílem bývá právě mapování, analýza a přehodnocování firemních pracovních postupů sledující zlepšení vybraných ukazatelů.
Lehce se může stát, že se nasazením IS řešícího pouze dílčí problém zakonzervují nevhodné pracovní postupy, pro jejichž změnu již posléze není vůle ("Máme nový infomační systém za XYZ milionů a vy chcete, abychom ho nechali přepracovat? Zbláznil jste se? Víte co na to řekne vedení?"). V extrémním případě může být postupem času vytvořeno více dílčích systémů, jejichž administrace vyžaduje další personální nároky a tím pádem i zvýšené finanční náklady. Ze začátku levnější řešení se může v konečném důsledku výrazně prodražit. Dříve nebo později bude nejspíš navíc organizace tak jako tak přinucena k (možná i radikálnímu) přehodnocení "business procesů". Je proto dobré zodpovědět následující otázky: "Nebylo by vhodnější namísto pouhého nasazení nového IS provést i reorganizaci podnikových procesů ? Do jaké míry nový IS pouze oddálí objektivní potřebu provést reenginering ? Jaké řešení bude v konečném důsledku levnější?". Samozřejmě klíčovou roli při tomto rozhodování sehrává management, bez jehož souhlasu a nezbytné podpory nepřichází nic podobného v úvahu. Mohou zde proti sobě stát dva těžko slučitelné postoje, které značnou měrou ovlivňují podobu výsledného systému. Zadavatel má pochopitelně co největší snahu na snižování nákladů a časových nároků spojených s realizací IS (což jsou cíle do jisté míry společné oběma stranám), apriori tedy vyžaduje co nejjednodušší (= nejlevnější) řešení. Na druhé straně řešitel, který si může být v důsledku analýzy vědom budoucích rizik, by často rád prosadil důslednější, i když časově (= finančně) náročnější řešení.
Důsledně provedenou analýzou a vytvořením katalogu požadavků se nakonec chrání obě spolupracující strany. Zadavatel má přesnou kontrolu splnění dílčích požadavků, zatímco od řešitele nemůže být požadováno něco, co není v katalogu požadavků obsaženo. Problém tzv. "requirements engineeringu" je samozřejmě daleko širší, ovšem stojí zato se jím zabývat. S větší dávkou nadsázky lze prohlásit, že kvalita výsledného systému se zpravidla přímo odvíjí od množství úsilí věnovaného zpracovávání uživatelských a systémových požadavků. Publikované studie jasně deklarují, že odhalení chyby či nekonzistence ještě v rané fázi analýzy je mnohonásobně (až tisíckrát) levnější než nezbytné pozdější úpravy.
Dnes je obvyklý i přístup, kdy je samotná analýza prováděna v rámci oddělené dodávky objednané zadavatelem. Nic tedy nebrání tomu, aby analýzu prováděla jiná firma než ta, která má na starosti pozdější design a implementaci. Vyvstává zde pak požadavek na používání standardních nástrojů a dokumentačních prostředků pro usnadnění komunikace s třetí stranou. Nutným předpokladem je samozřejmě patřičná erudice zadavatele a serióznost dodavatele.
Etapa analýzy je zpravidla následována fází designu. Zatímco při analýze se úmyslně abstrahuje od konkrétního řešení, design je zaměřen především na rozpracování a transformování právě výsledků analýzy do jednoho partikulárního řešení. Zatímco analýza může být často činnost veskrze mechanická ("analytik nemá co myslet, analytik se má ptát..."), design je již opravdu tvůrčí činností. Výsledky dostatečně detailního návrhu mohou být chápány již jako přímé podklady pro implementaci. Velmi vhodným prostředkem používaným při designu je prototypování, jehož úkolem je tvorba částečně funkčního aplikačního systému, který slouží především pro vyjasňování požadavků týkajících se například interakce systému s uživatelem apod. Právě pro tuto činnost se značně hodí prostředky kategorie RAD, jejichž přínos je v této oblasti nedocenitelný.
Etapa implemetace se věnuje především činnostem souvisejím se samotným programováním. Jsou využívány technologie a nástroje, o jejichž používání bylo rozhodnuto v designu a které též nevyhnutelně respektují systémové požadavky. Zde hrají svoji úlohu SW a HW platformy, programovací jazyky, DBMS apod. Z uživatelského hlediska je implementace nejzajímavější etapou. Z dokumentů vytvořených v analýze a návrhu se v lepším případě "vyloupne" spustitelný systém, v němž je od samého začátku spatřován cíl věškerého úsilí.
Neopominutelnou úlohu při tvorbě IS zaujímá testování, které je bohužel často chápáno jako něco, co se provádí až v případě, kdy "zbyde trochu času". Praxe bohužel, nebo chcete-li bohudík, potvrzuje nutnost testování jako činnosti opravdu nezastupitelné. Je sice pravda, že se jedná o aktivity mnohdy časově náročné, ovšem dnes již lze s výhodou použít poměrně sofistikovaná řešení postavená na automatických testovacích prostředcích, které dokáží vytvářený systém "proklepnout" ze všech stran a úhlů opravdu důkladně. Investice do nástrojů tohoto druhu se zcela určitě vrátí ve snížených nákladech na dodatečné opravy.
V případě použití objektového přístupu nemusí být, vhledem k povaze používaných nástrojů, jasná hranice mezi jednotlivými etapami. Obecné schéma posloupnosti analýza/design/implementace/validace však zůstává zachováno. Právě v souvislosti s používáním objektových technologií se nejvíce osvědčil iterativní přírůstkový životní cyklus, jehož filosofie staví na práci s relativně malými částmi systému, které jsou vždy řešeny a zpracovávány přes všechny etapy zkráceného životního cyklu. Celý vývoj IS je tak vlastně neustálým koloběhem klíčových etap při uvažování stále většího množství dílčích celků. Samozřejmě tento model iterativního životního cyklu víceméně padá v případě, kdy není uvažována tvorba kompletního IS, tj. například v již diskutovaném případě analýzy prováděné samostatně. Zatímco při klasickém tzv. vodopádovém modelu byla snaha uzavírat definitivně jednotlivé etapy, při iterativní metodě jsou jednotlivé etapy průchodné oběma směry. Samozřejmě tento přístup trochu komplikuje možnost stanovit přesné časové hranice dodávek, což zadavatele nijak nepotěší. Je samozřejmě možné a mnohdy účelné sáhnout k nejrůznějším metodám kalkulace časových a finančních nákladů, ovšem výsledky těchto metod je nutné brát s mírnou rezervou a nespoléhat se na ně jako na stoprocentně spolehlivé údaje.
Obr. 1 - Základní schéma iterativní přírůstkové metody
Jak jsme již patřičně zdůraznili na začátku, není příliš vhodné upřednostňovat jakoukoliv z klíčových etap na úkor zbylých. Ošidíme-li analýzu, můžeme nakonec zjistit, že vytvořený systém nesplňuje požadavky zadavatele, snaží se odstraňovat pouze důsledky a ne příčiny problémů. Nedůsledný návrh jen stěží umožní plně využít výhod objektového přístupu, celá architektura systému může postrádat určitou základní koncepci. O dopadech nekvalitní implementace a testování snad není ani potřeba se zmiňovat.
Jedním z největších přínosů nasazení metodiky je zcela určitě ten fakt, že své uživatele vede, nikoliv nutí, k respektování těchto obecných zkušeností a snaží se klást důraz bez rozdílu na všechny nezbytné etapy.
Metodika vs. Metoda
Pod pojmem metodika rozumíme právě onen prostředek, jehož "používáním" můžeme dosáhnout s trochou štěstí usnadnění a zkvalitnění naší práce. Budeme-li konkrétní, popíšeme metodiku jako návod, postup, jak vytvářet informační systém. Ucelená metodika zahrnuje například popis životního cyklu tvorby SW, role a zodpovědnosti jednotlivých účastníků tohoto procesu, posloupnost úkonů k dosažení stanoveného cíle apod. Ke každé z fází definovaných metodikou a na vyřešení jednotlivých klíčových úloh je posléze možné použít nejrůznější metody, které se snaží popsat činnosti a úkony nutné k vyřešení konkrétního problému.
Obr. 2 - Vybrané předměty zájmu metodik pro tvorbu IS
Splnění vytyčeného cíle, v tom nejobecnějším smyslu, vyžaduje vždy určitou posloupnost dílčích kroků, ke každému z nich pak mohou existovat i odpovídající nástroje, s jejichž pomocí lze kýženého efektu dosáhnou. Chceme-li pověsit na zeď obraz, použijeme pravděpodobně kladivo a hřebík. Nicméně můžeme použít i odlišné nástroje. Někdo dá možná přednost vrtačce, hmoždince a šroubu. A někdo, ne že bych takového člověka znal, se rozhodne obraz na zeď přilepit. Volba nástrojů pro splnění konkrétního úkolu záleží většinou pouze na naší zdravé úvaze. Často nás mohou vést obecná doporučení, zkušenosti nebo dokonce intuice. V případě tvorby IS je to právě metoda, která determinuje volbu vhodných nástrojů pro vyřešení dílčího problému.
Na tomto místě by bylo vhodné upozornit čtenáře, že ne vždy je striktní dělení pojmů metodika a metoda akceptováno a používáno. Poměrně často se lze setkat, a to i v zahraniční literatuře, s libovolným zaměňováním těchto dvou termínů, což může občas způsobit nedorozumění v komunikaci.
Modelování systému
Tvorba informačního systému s použitím objektového přístupu (ale i bez něj) stojí především na vytváření nejrůznějších modelů. Modelujeme tak například interakci systému s okolím, komunikaci objektů jako nosný prostředek realizace dynamiky aplikace a jako podrobný model můžeme chápat i zdrojový kód. Samotné modely můžeme ze zřejmých důvodů prezentovat a vytvářet ve formě grafických diagramů, jejichž sémantika (význam) a syntaxe (zápis) je zpravidla jasně vymezena. Souhrnně mluvíme o tzv. notaci.
V souvislosti s používáním objektových metod můžeme často slýchat, že nám tyto prostředky pomáhají lépe modelovat realitu, což ovšem není tak úplně pravda. Modelujeme totiž pouze námi vybranu, poměrně úzkou část reality, zase opět pouze nějaký model (tento problém, stejně jako další aspekty objektových technologií, vede spíše na otázky filozofického rázu, kterými ovšem stojí za to se zabývat). Jako ilustrativní příklad můžeme uvažovat dnes tolik diskutovaný problém Y2K. V šedesátých letech byla pro padesátiletého programátora v COBOLu osobní realita taková, že úvahy o problému s malým počtem číslic vyhrazených datumu byly více méně irelevantní. Programátor přemýšlel v horizontu několika desítek let, které mu byly vyměřeny a co bylo dál již neuvažoval. Celý problém tak vlastně vznikl zvolením špatného modelu, který nebyl sto reflektovat a akceptovat realitu.
Jakýkoliv systém, a nemusí jít pouze o systém informační, nějak vypadá a nějak se chová. Tento fakt je většinou reflektován explicitním odlišením jednotlivých nástrojů pro modelování statické a dynamické stránky systému. Jednotlivé nástroje a jimi podporované metody slouží především ke zmírnění nežádoucích dopadů komplexnosti modelovaných systémů. Prostřednictvím modelů se pracuje s dílčími částmi, na které je navíc nahlíženo pouze z určitého úhlu pohledu. Větší variabilita nástrojů a metod pravděpodobně umožní zmapovat a modelovat systém důkladněji, ovšem za cenu nemalých časových nároků vyžadovaných jak pro k jejich osvojení, tak i k jejich rutinnímu používání. Zcela určitě platí, že je lepší ovládat méně nástrojů bravurně než mnoho prostředků a nástrojů povrchně a nedostatečně.
V průběhu životního cyklu tvorby IS se tedy postupně vypracovávají jednotlivé modely až do podoby SW produktu, který je možné v lepším případě testovat, nasadit, provozovat a dále udržovat.
Objektově a objektově nemusí být nutně totéž
Jak již bylo řečeno, z objektových technologií se záhy stal všudypřítomný "buzzword", čímž došlo nevyhnutelně i k posunu chápání a nahlížení na tyto prostředky, které si postupně začaly osvojovat firmy i jednotlivci. Z nedostatku zkušenosti se však často objektové technologie používají ne zrovna "košér" způsobem. Za dobrým úmyslem využití všech výhod objektového přístupu se často skrývá neúmyslné zneužívání objektových principů, počínaje úrovní programování (používání hybridních jazyků) a konče nesprávným používáním prostředků pro objektovou analýzu a design.. Tento nevyhnutelný proces probíhal a probíhá samozřejmě ne vždy ke škodě věci. Mnohdy se i nepříliš adekvátní nasazení objektového přístupu osvědčí, ovšem jen těžko může být využito všech nebo alespoň většiny výhod, které z vhodného používání objektových technologií vyplývají.
Při přechodu z klasických strukturovaných metodik na objektové metodiky a vůbec objektové principy je vcelku vhodné nenechat nic náhodě a obrátit se na nějaký subjekt, který má s touto problematiku široké zkušenosti a je ochoten formou konzultací nebo poskytnutím odborníků na konkrétní projekt pomoci zavádět objektové technologie do běžné praxe. Ještě před pár lety byla v ČR tato vize spíše utopií, nicméně vývoj jde kupředu a dnes již existují dokonce specializované firmy zabývající se právě touto problematikou. Můžete-li si tyto služby dovolit, využijte jich. Nabývat znalosti školeními či konzultacemi je často levnější a efektivnější cesta než slepé bloudění a pátrání po pravé podstatě problému.
Nástroje CASE
Je-li při tvorbě IS postupováno podle nějaké vybrané metodiky, pak je většinou její používání podpořeno adekvátním CASE (Computer Aided System Engineering) systémem, který je nad metodikou takříkajíc postaven. Právě dostupnost CASE nástrojů byl a je často též rozhodující faktor, zda-li se metodika uchytí či nikoliv. Při výběru vhodné metodiky jsme samozřejmě často omezeni nabídkou CASE nástrojů na trhu. Obvyklý, možná častější, je postup, kdy je nejdříve vybrán CASE podle dílčích kritérií (úroveň generované dokumentace, …) a tím je vlastně implicitně vybrána i použitá metodika. Nutno zdůraznit, že zvlášť u tak rozsáhlých a komplexních systémů, jakými vyspělé CASE bezesporu jsou, se pod pojmem dostupnost skrývá plno dalších věcí. Většinou nejde pouze o to CASE koupit, ale také nasadit, absolvovat školení a mít k dispozici kvalitní technickou podporu.
Problém dostupnosti CASE prostředků pro ty které nástroje vybraných metod se v posledních několika málo letech zdánlivě začínal řešit příchodem CASE systémů, které jsou do jisté míry na nástrojích uvažovaných metod nezávislé. Ty se často pod CASE "podsunou" v již předpřipravené podobě, tj. většinou jako množina zaměnitelných datových souborů. Takový popis vychází často z metamodelu, což je svým způsobem předpis, vytvořený právě pomocí výsledného produktu, který je popisován. V našem případě je popsána notace nástrojů objektových metod opět pomocí této notace. Nutno podotknout, že CASE systémy založené na této filosofii se zdají být velkým příslibem teprve do budoucna, neboť se zatím jejich dnešní zástupci nemohou co do nabízené funkčnosti měřit s vyspělými produkty "klasické" konstrukce.
V minulosti bylo iniciováno několik projektů, které se zabývaly vytvořením metamodelů většiny používaných prostředků objektové analýzy a designu, které měly být poté použity pro vytvoření jakéhosi univerzálního standardu. Za všechny jmenujme alespoň iniciativu COMMA (Common Object Methodology Metamodel Architecture) sloužící jako podklad pro vytvoření univerzální metody objektové analýzy a designu, případně CDIF (CASE Data Interchange Format) sledující vytvoření univerzálního formátu pro přenos dat mezi různými CASE systémy.
Výběr vhodného CASE prostředku ovlivňuje mnoho kritérií. Hlavní úkol CASE spatřujeme v usnadnění týmové spolupráce a samozřejmě v patřičné podpoře metod konkrétní metodiky. Často oslnivé celostránkové výčty prostředí, pro které je možno generovat výsledný kód většinou nejsou primárním rozhodovacím faktorem. Mezi stěžejní vlastnosti dobrého CASE nástroje patří solidní podpora týmového vývoje, pokud možno úplná podpora zvolené metodiky, možnost přizpůsobitelnosti generované dokumentace a možnost celkové přizpůsobitelnosti CASE nástroje (žádný CASE nevyhovuje vždy plně a je výhodné, existuje-li možnost dílčích nebo i zásadnějších úprav produktu). Jedním z nejdůležitějších a bohužel možná nejvíce opomíjených faktorů je existence a dosažitelnost kvalitní technické podpory, která slouží jako vítaný pomocník v případě řešení vzniklých problémů nebo při integraci CASE do celkového vývojového prostředí ve firmě. Ideální je dále kombinace CASE nástrojů s nástroji pro analýzu a sběr uživatelských a systémových požadavků, případně s prostředky pro testování a ladění aplikací.
Závěr
Zavedení a používání konkrétní metodiky, ať objektové či jakékoliv jiné, není samozřejmě všelékem. Jako všechny nástroje, dá se i objektové modelování a celkově metodika používat, lépe řečeno nasadit, vhodným i méně vhodným způsobem. Recept na uspěch samozřejmě nezná nikdo. Jako extrémní, možná kontraproduktivní, se jeví někdy zaujímaný postoj, kdy se naprosto všechno konání bezvýhradně podřizuje nasazené metodice. Pouhá množina doporučení se tak stane pánem a nikoli služebníkem usnadňujícím a zefektivňujícím práci. V takovém případě snad dokonce platí, že lepší žádná než neadekvátně nasazená metodika.