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

Transkript

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.
© 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 <<include>> 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ů

Transkript

Podobné dokumenty

letní speciál

Několik teoreticko-metodologických poznámek k

Návrh webového systému řízení malé společnosti

ČÍ JE MŮJ KŮŇ?

Riichi Mahjong

Definice pravděpodobnosti, základní vlastnosti

Čech, R. - Radek Čech