Návrh informačních systémů pomocí UML, OOP a vzorů

Návrh informačních systémů pomocí UML, OOP a vzorů © RNDr. Ilja Kraval mailto:[email protected], OBJECT CONSULTING s.r.o. http://www.objects.cz

Obsah (postupně se rozšiřuje): Návrh informačních systémů pomocí UML, OOP a vzorů ...........................................1 1. Proč UML, OOP a vzory?..................................................................................1 2. Pád do pasti BYROKRATICKÉ METODY .........................................................6 3. Čtyři základní pilíře návrhu IS ...........................................................................9 4. Trojice základních vzorů návrhu IS .................................................................12 4.1 Vzor Pattern for interaction .....................................................................12

1. Proč UML, OOP a vzory? Na tuto otázku existuje jednoduchá odpověď: Protože existuje způsob tvorby informačních systémů, který se příznačně nazývá TUNEL. Jedná se spíše o „antimetodu“, tj. o postup tvorby informačního systému, který není v žádném případě doporučován.

Návrh informačních systémů pomocí UML, OOP a vzorů © RNDr. Ilja Kraval, 2006, http://www.objects.cz

Jeho podstata je následující (viz následující obrázek):

TUDY NE

ÚSPĚCH

TUDY NE

obrázek 1 Metoda tvorby IS zvaná TUNEL Na počátku projektu se vstupuje do černého tunelu (viz zelená šipka), kterým se prochází poslepu od stěny ke stěně. Cestou se díky nárazům do stěn tunelu zjišťuje, kudy cesta nevede (viz červené šipky s nápisy „TUDY NE“), tj. co se nemá dělat resp. nemělo udělat. Operativními zásahy se vedoucí projektu snaží projekt uřídit a najít světýlko na konci tunelu (žluté světélko s nápisem ÚSPĚCH). Mnohdy se projekt „s odřenýma ušima“ dokončí a „jakýs takýs“ informační systém se zákazníkovi nakonec odevzdá. Bohužel velmi často nastane případ, kdy se nadějné světélko na konci tunelu promění ve světla protijedoucího vlaku a celý projekt skončí katastrofickým scénářem. Použití metody TUNEL vede z hlediska softwarové firmy ke třem hlavním a podstatným negativním důsledkům: •

Zvýšené náklady strana 2


•

Pozdní dodávka systému

•

Absolutní nesoulad mezi naprogramovanými funkcionalitami IS a původními požadavky zákazníka

To jsou nejzávažnější důsledky použití metody TUNEL, většinou také uváděné v literatuře, avšak existují i další nepříjemné důsledky, které jsou neméně důležité. Při použití metody TUNEL nastávají zákonitě tyto nepříznivé jevy: •

Chybí jakákoliv koncepce vývoje a není možná opakovatelnost výsledků. V metodě TUNEL nejsou použity žádné opakovatelné postupy a projekt se řídí pouze momentální intuicí a zkušenostmi vedoucího projektu. Každý projekt a jeho výstupy vypadají jinak, a to dokonce i v případě, že projekty řídí jeden a tentýž vedoucí. Výsledky z různých projektů jsou různé, jsou nesourodé, navzájem si odporují, apod.

•

Není možná jakákoliv predikce v projektu. Ani na začátku, ani v průběhu projektu, a to dokonce ani v jeho závěrečných fázích nelze odhadovat další pracnost, tj. jaké všechny práce bude třeba ještě udělat. Účastníci projektu nevědí, co je čeká na jejich cestě „za příštím rohem“. Každý projekt se tak stává sázkou do loterie a připomíná spíše dobrodružnou výpravu za pokladem pirátů než výrobu softwaru.

•

Platí obecná neznalost kdy má co kdo dělat. Vše je pouze v kompetenci vedoucího projektu, který řídí projekt spíše ze zkušeností a pouze pomocí vlastní intuice. Vedoucí nemá žádnou příručku, ani žádné rady a pokyny, jak v dané chvíli postupovat, co vyžadovat. Proto volí své vlastní ať už lepší nebo horší řešení přímo v dané chvíli a na daném místě. Řízení se pro něj stává velmi náročnou prací plnou lokálních operativních zásahů bez možnosti jakékoliv kontroly správnosti rozhodnutí, přičemž z hlediska metod řízení chybí jakékoliv kvalitativní porovnání čehokoliv s čímkoliv.

•

Každá porada v projektu začíná „jobovými zvěstmi“, co vše nechodí, co chybí, co je třeba ještě udělat. Vedoucí projektu, který používá metodu TUNEL, většinou mívá žaludeční vředy.

•

Ve výstupech z projektů, které se průběžně tvoří metodou TUNEL, neexistuje požadavek na opětovnou použitelnost neboli re-use, anebo přesněji řečeno, při metodě TUNEL se tento požadavek nedá efektivně zavést. Některé části agend se vyvíjejí několikrát, což vede k dalším nečekaným problémům díky existenci několikanásobných řešení. Nejenže se bez zavedení opětovné použitelnosti jedná při opakování vývoje o zbytečnou práci, ale software začíná vykazovat velmi silnou nepřehlednost. Jednotlivé prvky softwaru v projektech se díky své násobnosti velmi těžko identifikují. Neví se, kde

strana 3


všude se opakující chyba resp. požadavek na změnu vlastně vyskytuje. To se projevuje jako závažný nedostatek zejména při opravách a případných změnách. Opravdu velmi obtížně (někdy dokonce až za hranicí možného) se vyhledávají všechna místa, kde se všude chyba nebo požadavek na změnu nachází. V některých případech se při opravě chyby u hodně složitých a rozsáhlých systémů dokonce ani nenajdou všechna místa, kde se chyba vyskytuje, protože se o všech místech prostě neví. Systém vykazuje velmi nízkou transparenci, jeví se jako zbytečně složitý, vypadá jako slepenec plný těžko identifikovatelných a tedy těžko opravitelných chyb. Navíc informační systém nevykazuje žádné nosné analytické myšlenky a jeho architektura je zbytečně složitá a nepřehledná. Odhalení chyb (například v testování) ještě není zárukou, že se tato chyba skutečně odstraní ve všech místech svého výskytu. •

V některých případech se předchozí bod pojednávající o velmi nízké opětovné použitelnosti v TUNELU rozvine do nejhrůznější podoby: Nejenom, že se začnou opakovat funkcionality v jednotlivých agendách, ale díky opakovaným pracím začne docházet k redundanci samotných evidovaných informací. Například v metodě TUNEL se běžně stane, že některé osoby jsou v systému evidovány několikrát, v každé agendě znovu. Vzniká tak další nečekaný problém: Musí se zadat k řešení úplně „nová agenda“, jakýsi „program pro program“ - zbytečná integrace, která má za úkol dávat dohromady opakující se evidované informace, které se vůbec opakovat nemusely.

•

Při metodě TUNEL je každý i malý a jednoduchý analytický požadavek na změnu v konečném důsledku raději odmítán i za cenu obchodních ztrát. Systém vykazuje vysokou „synergetickou nestabilitu“: I malé změny v systému vedou k jeho nečekaným kolapsům paradoxně v odlehlých částech systému. Díky nízké transparenci, nestabilitě a chybovosti systém vykazuje vysokou pracnost i v případě jednoduché údržby, a to i po drobném zásahu. Po malé změně v systému se vyžaduje obrovský díl práce na opětovném bezchybném stabilním zprovoznění systému (nestabilita jako malá změna vyvolává obrovské nepříjemné důsledky).

•

V softwaru se objevují příliš časté chyby i po odevzdávce odběrateli, systém jako produkt vykazuje velmi nízkou kvalitu. Díky chaotickému vývoji a neustálému řešení dalších nových a nečekaných problémů vznikají zákonitě softwarové slepence plné chyb. Důsledkem chybovosti je velmi nízká kvalita produktů. Enormně vzrůstá nutnost neustálých oprav i po implementaci systému. Co je však nejhorší, u zákazníka se začne projevovat nespokojenost s kvalitou dodávky, zejména pokud zjišťuje fatální chyby ve funkcionalitách systému („…ten systém dělá neuvěřitelné hlouposti, takhle jsme to tedy ale vůbec nechtěli…“)

•

Chaotický vývoj vede i k zvláštní atmosféře ve firmě, která je charakterizována vysokou hektičností prací, shonem a všeobecnou nervozitou. Vyrobený strana 4


software se neustále předělává a to stále dokola „jako za trest“. Provádí se zbytečná a tedy úmorně nepříjemná práce. Výsledkem jsou extrémně náročné vztahy na pracovišti. Firma si v konečném důsledku díky neustálým úpravám a opravám uzurpuje velmi vysoké nároky na volný čas pracovníků. Problém nespočívá ani tak v tom, že by se pracovníci bránili příliš vysokému vypjetí sil a přesčasům (pokud mají slušný výdělek), ale jako vysoce inteligentním pracovníkům a expertům jim velmi vadí zbytečnost vykonané práce. Nakonec to mohou pociťovat i jako určitou křivdu, že díky neuvěřitelnému chaosu ve vývoji musejí zůstat přesčas a dané chyby stále dokola opravovat s povzdechem: „Po kolikáté už v této agendě, to už opravdu nikdo neřekne, jak to má být správně?!“ Ve firmě, která pracuje metodou TUNEL, je úplnou samozřejmostí pracovat hodně přesčas, dokonce až tak, že se to považuje za obvyklý standard chování. Někdy se tím vedoucí pracovníci u zákazníků chlubí: „Sledujte, jak usilovně pracujeme, žádné dovolené, zůstáváme tu až do večera, někdy do rána, samé pracovní soboty a dokonce i neděle!“. Ve skutečnosti však firma paradoxně staví na odiv svůj neefektivní způsob práce, který je pro metodu TUNEL příznačný. Správnější než tyto chlubné věty by byla formulace: „Pracujeme sice hodně, ale neefektivně.“ Navíc metoda TUNEL v žádném případě neprospívá dobrým vztahům na pracovišti. •

Souhrnem všech negativních projevů jsou, jak bylo již zdůrazněno, zvýšené náklady a následně finanční ztráty.

Proto se způsob tvorby informačních systémů TUNEL zásadně nedoporučuje, i když mohu z dlouholeté praxe konzultanta potvrdit, že bývá ve velmi mnoha firmách až příliš často používán.

strana 5


2. Pád do pasti BYROKRATICKÉ METODY V předešlé kapitole byla popsána „anti-metoda“ TUNEL. Existuje však ještě další dokonce ještě více nebezpečná „anti-metoda“ - BYROKRATICKÁ METODA. Tato opět nedoporučovaná metoda následuje většinou jako další krok po metodě TUNEL. Pád softwarové firmy do pasti BYROKRATICKÉ METODY mívá většinou stejný scénář: Ve firmě neexistují žádné postupy prací, firma vyrábí software chaoticky, tj. tak., jak bylo popsáno v předešlé kapitole. Vedení SW firmy se tato situace přestane zamlouvat, tj. důsledky intenzivně působící metody TUNEL. Rozhodne se tedy s tímto postupem ve firmě rázně skoncovat. Vedení firmy vcelku správně pochopí, že základním nedostatkem metody TUNEL jsou chybějící postupy prací, tj. metodiky, a že je proto žádoucí nějaké metodiky ve firmě zavést. Zadá se proto „jakýsi úkol“, aby se vytvořily postupy pro tvorbu softwaru, neboli metodiky. Většinou spolu s tímto krokem se současně založí oddělení kvality. Na první pohled dobře míněná snaha však může skončit katastrofou. Pokud pracovníci, kteří zavádějí tyto postupy a metodiky, neznají základní principy tvorby softwaru, začnou vznikat velmi podivné dokumenty. Podle nich se sice vyžaduje pracovat, ale pro programátory se tyto dokumenty stávají spíše přítěží než pomůckou. Vznikají tak předpisy podle hesla: „Hlavně ať jsou předpisy!“, avšak jejich správnost, efektivita apod. není posuzována. Doslova začnou vznikat „dokumenty pro dokumenty“, avšak podle nich se nedá pracovat. Tento „extrémně opačný byrokratický přístup“ je charakterizován následujícími body: •

Zavádějí se postupy a metodiky bez zkušeností s nimi, nedodržují se základní pravidla metodik platné pro tvorbu softwaru (o těchto principech bude dále v této knize pojednáno)

•

Na počátku zavádění metodik se zahajují práce s přehnaným optimismem. Jsou patrná přílišná očekávání ze zavedených postupů, a to s očekáváním výsledků ihned a okamžitě. To samozřejmě vede k zavádění neověřených postupek za každou cenu s následnými krachy.

•

Při tvorbě metodik se dopředu předjímají a vymýšlejí nesmyslné postupy neověřené praxí. Metodiky se vydávají jako jednou konečné pravdy, o kterých není již radno diskutovat.

strana 6


•

Přílišné očekávání vede ke snaze o revoluční skoky („čínská revoluce“) ve změnách způsobů práce ve firmě. Zanedbává se ten prostý fakt, že každý fungující mechanismus má svou setrvačnost. Navíc při zavádění metodik je třeba vytvořit rychlou zpětnou vazbu. Každý nový postup vyžaduje „přejít postupně do krve“. Každou postupku je třeba ověřit, odzkoušet, zrevidovat praxí. Při zanedbání těchto faktů následují při zavádění metodik v SW firmách krachy. Správně uvažujícímu člověku by měl přeběhnout mráz po zádech, když někdo přijde s myšlenkou: „Máme tři čtvrtě roku na zavedení postupek a návodek, času máme dost. Zavedeme je a od 1.1. příštího roku je spustíme, to bude potom bomba!“ Bomba to bude, ale jinak, než původně autor zamýšlel. Necelý rok uplyne a vydají se takové postupky, které všichni zavrhnou jako nesmysly. S příchodem nového roku hora porodí myš.

•

Při zavádění byrokratické mašinérie následuje zpomalení vývoje a poté se zvyšuje netrpělivost u zákazníka. Zde mohou nastat dva možné scénáře: Buď pracovníci začnou nesmyslné metodiky ignorovat a tím se dostanou zpět do metody TUNEL (metodiky se ignorují a každý bojuje jak umí), anebo nastane horší varianta: V některých případech dokonce pracovníci začnou „švejkovat“ v tom smyslu, že pracují „přesně podle nesmyslných postupek“, což pochopitelně vede ke katastrofálním výsledkům.

Přístup k tvorbě softwaru pomocí BYROKRATICKÉ metody se také nedoporučuje. Z vlastní zkušenosti mohu potvrdit, že pád firmy do pasti BYROKRATICKÉ METODY je mnohem nebezpečnější než použití klasické metody TUNEL. Pokud totiž nastane scénář striktního dodržování nesmyslných postupů, může to nakonec vést až k totálnímu kolapsu týmové práce. Zatímco v metodě TUNEL se mnohdy „jakýs takýs“ informační systém odevzdá, BYROKRATICKÁ METODA může vést ke katastrofě, kdy se rozpadnou týmy a dokonce se zruší dosud zažité „dobré zvyklosti vývoje“ vedoucí alespoň k nějakým výsledkům. Uvedený přechod firmy od TUNELU přes BYROKRATICKOU METODU zpátky do TUNELU ukazuje následující obrázek:

strana 7


Zavedení metody TUNEL

Ignorace předpisů (jedeme podle svého)

Zavedení BYROKRATICKÉ METODY

Dodržování nesmyslů BYROKRATICKÉ METODY

KRACH

obrázek 2 : Metoda TUNEL a návrat do ní po neúspěšném zavedení metodik Paradoxně jsem se setkal s firmami, ve kterých byla zavedena BYROKRATICKÁ METODA, naštěstí byla ignorována (viz šipka zpět na předešlém obrázku), firma tedy „jela vesele TUNELEM“ a honosila se certifikáty ISO. Formálně totiž vše vypadalo tak, jako by firma předpisy pro postupy prací měla, ale stejně se v realitě pracovalo pouze „ad hoc“, jak je v metodě TUNEL zvykem.

strana 8


3. Čtyři základní pilíře návrhu IS V předešlých kapitolách byly popsány dvě často používané „anti-metody“ : TUNEL a druhá ještě více nebezpečná „anti-metoda“ - BYROKRATICKÁ METODA. Samozřejmě naskýtá se otázka, jak má vypadat správná metodika. Ukazuje se, že efektivnost metodiky návrhu a tvorby IS je postavena základních čtyřech pilířích. Pokud je jeden z těchto pilířů narušen, metodu TUNEL nelze korektně opustit. Tyto čtyři pilíře zobrazuje následující obrázek:

4 PILÍŘE VÝVOJE IS

OBJEKTOVÝ PŘÍSTUP

ÚROVNĚ ABSTRAKCE

Analýza Design Kód atd...

POUŽITÍ VZORŮ

MODELOVÁNÍ V JAZYCE UML

Třídy Instance Zapouzdření atd...

Modely, Diagramy Elementy, Interakce MDA atd...

Design Patterns Analysis Patterns Enterprise Patterns Integration Patterns atd.

obrázek 3: 4 pilíře vývoje IS

strana 9


Následuje stručná charakteristika těchto bodů, v dalších kapitolách je probereme samozřejmě detailně a také prakticky: 1. Pilíř: Úrovně abstrakce ve zkratce znamená, že na informační systém je třeba nahlížet z různých úrovní abstrakce, přičemž každá úroveň je charakterizována mírou detailu implementace. Tomuto principu musí odpovídat rozvržení dokumentace projektu. Rozeznávají se (minimálně) tři úrovně abstrakce informačního systému a. analytické modelování (ve zkratce také analýza) b. design c. kód. Na nejnižší úrovni abstrakce (tj. kód) se dokumenty vyznačují nejvyšší mírou detailu implementace a to až na úrovni samotného kódu, na nejvyšší úrovni abstrakce, tj. na úrovni analytického modelování, je systém popsán pouze pomocí analytických entit (evidované pojmy a jejich struktura) a chování výskytů z nich (algoritmy, scénáře, dynamika). Tímto principem se povinně řídí tvorba dokumentů ve vývoji. Zohlednění tohoto bodu vede ke správnému fázování vývoje a k přehledné a úplné dokumentaci informačního systému. Nezohlednění tohoto bodu vede k cestě TUNELEM už díky neznalosti „který dokument je třeba kdy udělat“, což není nic jiného, než zanedbání fázování vývoje. Důsledkem této chyby je také následná velmi chabá dokumentace projektu. Většinou se projekt dokumentuje pouze na jedné úrovni abstrakce a to kódování, protože se u SW jedná o „povinnou“ část dokumentace (ono totiž logicky bez napsání kódu nelze „chodící“ systém odevzdat). Ostatní dokumenty, tj. analytické modely a modely designu, zůstávají v hlavách tvůrců a šíří se pouze ústním podáním. 2. Pilíř: Objektově orientovaný přístup (ve zkratce OOAP - Object Oriented Approach) zavádí při návrhu IS velmi důležitou filosofii náhledu na to, co jsou to vlastně prvky IS. Zavádí pojem „obecný objekt“ (tj. „general object“) ve smyslu prvku IS a definuje jeho vlastnosti. Tyto prvky jsou základními stavebními kameny vývoje systému na všech úrovních abstrakce (analýza, design, kód). Bez tohoto principu není vývojář schopen správně a logicky sestavit IS, protože mu chybí „základní stavební kameny“ - obecné objekty. Problematika OOAP bude dále vysvětlena podrobně a rozvedena v dalších kapitolách, nyní uveďme pouze to, že jeden ze základních důsledků OOAP spočívá v rozdělení informačního systému na dvě prakticky oddělené části: IS je oddělen nikoliv pouze pomyslně, ale „fyzicky“ (tj. až do kódu) na část „uvnitř prvku“ (tj. to, co patří do prvku, implementace) a část „vně prvku“ (okolí prvku, klient). Neznalost tohoto přístupu OOAP vede k fatálním chybám v návrhu, k nesprávnému použití prvků modelu, k nesmyslným návrhům jak v analýze, strana 10


tak v designu, tj. k hrubým chybám v modelování. Musíme zdůraznit, že porušením tohoto principu hrozí zejména zavlečení jedné z nejvážnějších chyb, kterých se může tvůrce IS dopustit, a tou je chyba uvedená v anti-vzoru „SPLITTING OF OBJECT“. Tato chyba spočívá v tom, že se evidované informace v IS umísťují do nesprávných pozic, tj. tam, kam nepatří. Tím dochází k tříštění objektů neboli evidovaných informací (o tomto „anti-vzoru“ viz dále v knize). Musíme ještě upozornit na to, že pojem „general object“ zavedený pomocí OOAP je obecnějším pojmem než objekt zavedený v OOP. Jedná se o jeho zobecnění pro všechny úrovně abstrakce, nejenom pro kód. 3. Pilíř: Modelování v jazyce UML – (Unified Modeling Language) umožňuje vývojáři vyjádřit svoje myšlenky (a tedy celý návrh) ve velmi sofistikovaném jazyce. Tento jazyk navíc velmi dobře zohledňuje předešlý bod, tj. přístup pomocí OOAP. Jinak řečeno UML je „jazykem určeným pro objektově orientovaná prostředí“. Tvůrci UML poskytují vývojářům unifikovaný, standardní a velmi „chytře promyšlený“ jazyk pro vyjádření návrhu na úrovních abstrakce analytického modelování a designu. 4. Pilíř: Použití vzorů při návrhu IS (návrhové vzory, analytické vzory, vzory integrace aj.) umožňuje vývojáři při návrhu IS použít princip vzorů jako „opakovaných řešení“. Pro firmu to znamená, že může takto zavádět velmi efektivně opakované postupy pro vývoj. Význam použití vzorů se dá vyjádřit trefně pomocí slovní hříčky: Zavádění opakovaných postupů a řešení (vzory) je nejlepším postupem, jak zavést opakované postupy ve firmě. Jinak řečeno, jedná se o nejefektivnější způsob zavádění metodik, navíc je tento postup na rozdíl od byrokratických metod pracovníky vítán a není jimi odmítán (vzory jsou odborné „know-how“, které si vývojáři rádi přečtou na rozdíl od byrokratických příkazů). Je třeba hned úvodem poznamenat, že tyto čtyři oblasti se navzájem prolínají a kombinují. Například pro vyjádření struktury a fungování vzoru se použijí diagramy v jazyce UML (kombinace bodu 3 a 4), nebo například různé modely IS spadají do různých úrovní abstrakce (kombinace bodu 1 a 3), nebo například přechod od dokumentů jedné úrovně abstrakce k druhé je popsán pomocí vzorů modelem v jazyce UML a také pomocí vzoru, což vede k moderní technologii MDA – Model Driven Architecture atd. V dalších kapitolách tohoto seriálu se budeme podrobně zabývat těmito čtyřmi pilíři návrhu IS.

strana 11


4. Trojice základních vzorů návrhu IS Při návrhu IS jsou patrné vzory, které jsou velmi důležité, protože se velmi často používají. Na druhou stranu vidíme jiné vzory, které jsou speciálnější a používají se méně často. Praxe ukazuje, že existuje trojice vzorů, které mají výsadní postavení. Tyto tři vzory se chovají podobně jako axiomy (tj. nejzákladnější tvrzení) v matematice. Jsou to vzory natolik zásadní, že na jejich konstrukci jsou postaveny všechny další vzory pro návrh IS. Proto je dobré si tuto trojici vzorů uvést hned na úvod a řádně vysvětlit. Zde je však jeden drobný háček - tato trojice vzorů je spolu provázána tak, že vysvětlení jednoho vzoru není možné bez druhého a jejich pochopení je možné až jako celé trojice, tedy celku. Vysvětlení však musí proběhnout postupně, což nyní uděláme, a na konec shrneme působnost těchto tří vzorů jako jeden celek.

4.1 Vzor Pattern for interaction Jedná se o první základní vzor z trojice „axiomatických vzorů“. Vzor ukazuje, jak vlastně funguje tzv. opětovná použitelnost (dále také re-use) a také ukazuje, jak funguje interakce mezi prvky. Mohl by se však také jmenovat „Vzor pro objektový přístup“, protože i tato vlastnost je v něm také skryta, jak si ukážeme dále. Jedná se o jednoduchý základní axiom, jehož důsledky se linou teorií tvorby SW a tedy i návrhem IS. Představme si, že existuje nějaký prvek A a existuje nějaký prvek B, přičemž zjistíme, že v prvku A se vyskytuje určitá část „něčeho“, co se opakuje také v prvku B, označme tuto opakující se část klikyhákem:

strana 12


A

B

obrázek 4 Situace 1 ve vzoru pro re-use Příklady takovýchto situací: Opakující se kód ve funkci, opakující se struktury ve analytických třídách, opakující se sloupce v tabulkách aj. Vzor zavádí kromě této situace také situaci 2, která nastane tak, že se zavede interakce použití mezi prvky, daný opakující se klikyhák se „vytkne“ do prvku C a vznikne tak situace 2:

A

B

interakce 2

interakce 1 C

obrázek 5 Situace 2 ve vzoru pro re-use (po „vytknutí“) Situaci 1 budeme dále také nazývat „situace před vytknutím“ a situaci 2 „situací po vytknutí“. Přechod ze situace 1 před vytknutím do situace 2 po vytknutí. tj. samo vytknutí prvku C“, budeme chápat jako zavedení opětovné použitelnosti a budeme to nazývat také jako zavedení interakce mezi prvky. Existuje i opačný postup, kdy se ze situace 2 po vytknutí přejde úmyslně do situace 1 před vytknutím, tj., opačným směrem. Takovýto postup budeme nazývat optimalizace. Většinou se tak děje za účelem získání nějaké technologické výhody, strana 13


například rychlosti apod. Klasickým příkladem je postup tzv. „de-normalizace“ (3. stupně) v relační databázi, kdy se „rozpouštějí tabulky“. Každá optimalizace vede v konečném důsledku k porušení opětovné použitelnosti, což je třeba mít vždy na paměti. Problému optimalizace se budeme ještě blíže věnovat v kapitolách přechodu od analýzy do designu ve vzorech optimalizace. Všimněme si blíže vlastností situací před vytknutím a situaci po vytknutí tj. obrázek 4 Situace 1 ve vzoru pro re-use a obrázek 5 Situace 2 ve vzoru pro re-use (po „vytknutí“). Interakce použití v situaci po vytknutí je směrová, což je velmi důležitý poznatek. Toho, kdo používá (v našem případě prvky A a B), budeme nazývat klientem a toho, kdo je použit, budeme nazývat prvkem, nebo také „obecným objektem“. Je zřejmé, že pokud A používá C, tak to v žádném případě neznamená, že z toho plyne, že C používá A. Obecný objekt tj. prvek, který je použit, musí být v systému nějak přesně identifikován oproti jiným prvkům, jinak bychom nemohli docílit toho, aby si dvě interakce na předešlém obrázku „ukázaly“ svými konci šipek na tentýž prvek C. Stejně tak jsou identifikovány prvky A, B, ale také C pro kohokoliv do budoucna, kdo se stane jejich klientem. Pro tuto situaci konkrétní identifikace, kdy klient používá konkrétní identifikovaný prvek, budeme také používat terminologii, že „klient si drží ukazatel na používaný prvek“, přičemž pod ukazatelem nemáme na mysli pouze „paměťový“ ukazatel v OOP (kde tato věta platí samozřejmě také), ale máme tím na mysli obecně jakýkoliv ukazatel (třeba i datový, například cizí klíč apod.). Pokud tedy namaluje obrázek odpovídající situaci „po vytknutí“ (tj. obrázek 5 Situace 2 ve vzoru pro re-use (po „vytknutí“)), současně tím máme na mysli to, že vnitřní struktura klienta A resp. B se obsahuje obecný ukazatel na prvek C (obsahují ve své struktuře „kolečka“ jako začátek interakce na obrázku situace po vytknutí). Tento ukazatel je v dané technologii nějak realizován (například funkce nějak identifikuje druhou funkci při volání, cizí klíč v datech, anebo ukazatel na interface objektu, třída nějak identifikuje druhou třídu při dědičnosti, tj. má v sobě nějak jednoznačně zapsaného předka atd.) Další důležitou vlastnost tohoto vzoru si uvědomíme, pokud si představíme nový prvek (dosud neexistoval!), který se stane klientem prvku A, označme tento nový prvek jako X. Tomuto prvku X neboli klientovi prvku A „je jedno“, zda je použita situace 1 bez vytknutí anebo 2 po vytknutí, tj. zda došlo k aplikaci opětovné použitelnosti anebo nikoliv. V obou případech bude systém fungovat (nebýt této pravdy, nemohli bychom zavádět optimalizaci). Otázkou je, proč tomu tak je? Důvod je prostý, pokud si uvědomíme princip přechodu od situace „před vytknutím“ k situaci „po vytknutí“: Prvek C byl vytknut a následně použit. Není tedy úplně přesné hovořit o „interakci mezi prvky“ (to příliš zavání symetrií), ale raději o tom, že jeden prvek používá druhý prvek. Každý prvek nabízí v systému své použití, jinak řečeno nabízí nějakou službu použití. Pod službou

strana 14


použití máme na mysli nabízenou možnost být použit v interakci ve směru od klienta k prvku, a takovou službu nabízí každý prvek. V našem příkladu tedy prvek A jako klient prvku C používá nabízenou službu použití prvku C (stejně tak prvek B používá službu C), navíc prvek X používá nabízenou službu prvku A atd., viz následující obrázek:

služby použití X

X

služby použití B

služby použití A

A

B

služby použití C

C

obrázek 6 Princip použití prvků prvky Důležitý závěr: Každý klient prvku si tedy drží obecný ukazatel na používaný prvek a má přitom zpřístupněnu možnost použití služeb tohoto prvku.

strana 15


Díky těmto dvěma okolnostem (identifikaci prvku a nabízené službě použití prvku) nakonec prvek použije. Všimněme si, že pohled klienta je omezen pouze na tuto službu použití a nikoliv na vnitřní strukturu prvku. Proto je možné zavést vnitřní restrukturalizaci prvku vytknutím („refactoring“). Nyní je jasné, proč je prvku X jako klientovi prvku A na předešlém obrázku úplně, ale úplně „jedno“, zda je prvek C z A „vytknut“ anebo nikoliv. X používá služby A a tím jeho pohled na prvek A končí. Tomuto jevu, kdy klient prvku používá služby tohoto prvku a vnitřek neboli implementace používaného prvku je pro klienta přitom skryt, budeme říkat obecně zapouzdření (encapsulation). Vidíme, že náš vzor o re-use má v sobě uschovány také základní principy objektového přístupu, čemuž bude věnována jedna z dalších důležitých kapitol. Tento princip „objektovosti“ je mnohem obecnější než pouze pro OOP a co je hlavní, line se celým návrhem IS. K vysvětlení důležitosti tohoto faktu se vraťme k obrázku obrázek 6 Princip použití prvků prvky a představme si, že v prvku C je nějaká informace. Umí prvek A tuto informaci nebo ne? Odpověď ano, ale zprostředkovaně. Znamená to, že prvku X jako klientovi A je „jedno“, zda je ta informace v A nebo v C. Musíme upozornit (a dále si to ukážeme konkrétně na příkladech), že právě tady je schována nejčastější chyba při modelování a návrhu IS, která se nazývá tříštění objektů. Chyba se vytvoří tak, že určitý prvek se roztříští a jeho části se počnou objevovat rozprsknuté po systému. Jako příklad si představme., že máme v systému evidované jednak čtenáře knihovny, dále zaměstnance knihovny, studenty a jiné osoby. „Umějí“ tyto evidované výskyty rodné číslo? Odpověď ano, protože to po nich budeme vyžadovat. To však neznamená, že rodná čísla budou přímo „v nich“ jako jejich atributy. To, že z těchto evidovaných prvků tento údaj „nějak dostaneme“, tak to může (a v tomto případě to také znamená), že rodné číslo je v konkrétním prvku osoba a ten je použit těmito prvky nějak takto:

strana 16


služby použití zaměstnance

služby použití čtenáře

čtenář

zaměstnanec

služby použití osoby

osoba - rodné číslo

obrázek 7 Má čtenář a zaměstnanec rodné číslo? Bylo by dobré pochopit, že veškeré modelování IS je v UML postaveno na takovýchto obrázcích, které jsou v podstatě úplně stejné, jako je tento předešlý a jediné, co se na nich mění, je jejich grafická podoba pro různé typy diagramů, pro různé typy prvků a pro různé typy interakcí. Různé typy diagramů zobrazují různé případy „o co se v použití jedná a o jak typy prvků se jedná“. Každý vztah použití v různých typech diagramů vyjadřuje pouze něco jiného, například •

dědičnost je použití třídy třídou,

•

asociace je použití instance třídy instancí třídy,

•

vztah <> je použití instance případu užití druhou instancí případu užití

•

atd.

Je to však stále dokola o tomtéž vztahu použití prvku prvkem. Proto je tento vzor tak silný, dovoluje nám totiž pochopit, jak funguje modelování, jak funguje interakce, jak funguje objektový přístup obecně. Jeho nezohlednění vede k fatálním chybám v návrhu IS. V další kapitole se budeme zabývat druhým základním vzorem, který ukazuje, jak vlastně fungují vzory a jakou mají strukturu.

strana 17


Konec dokumentu – pokračování následuje Jakékoliv připomínky k článku pište prosím na adresu autora: mailto:[email protected]

Slovník Pattern for interaction and re-use

strana 18

Návrh informačních systémů pomocí UML, OOP a vzorů

Recommend Documents