Článek 73 - Objects.cz

JAK ZAVÁDĚT VZORY U STANDARDNÍCH
PŘÍPADŮ UŽITÍ
1. část
RNDr. Ilja Kraval, listopad 2009
http://www.objects.cz
ÚVOD – DOTAZ MAILEM
Obdržel jsem mail od jednoho bývalého účastníka našeho školení. Následuje ta část textu,
která směřuje k zajímavému dotazu:
„...
Mám teoretický dotaz, kdy si chci ověřit, že nejdeme do slepé uličky. Při analýze nového systému
jsem narazil na to, že analytik mi definuje (a popisuje) vždy znovu administrativní část reálných
objektů, tzv. manažery. Manažer osob, firem, uživatelských účtů, oprávnění, jablek, hrušek,... Jde
vždy o to samé (možnost založení, vyhledání, zobrazení, editace, kopírování, smazání,...), kdy se
reálné objekty liší pouze poli, která mají být použita.
Zadal jsem tedy vytvořit již na úrovni UC „rádobyvzor“ (možná "prapředek" per partes) - UC
model, který popíše vše, co je všem manažerům společné. V něm bude i (aktuálně) 6 UC (založení,
vyhledání, zobrazení, editace, kopírování, smazání), ze kterých se bude na úrovni konkrétního
manažeru dědit a v dědici se popíší specifika (pole a jejich vlastnosti). Něco se mi ale na tom nezdá a
nevím co. Vede mne to k úvaze, zda nebude jednodušší použití obecného UC modelu vždy jako vzoru
a jeho přepsání vždy do konkrétního manažeru. Tam se nám ale zase ztratí reuse. Můžete, prosím,
vyjádřit Váš názor, případně připojit doporučení?
Děkuji a s pozdravem,
M. K.
V tomto článku se budeme věnovat odpovědi na tento dotaz.
http://www.objects.cz
strana 2
JAK FUNGUJE VZOR V UML
Představme si, že jsme při vývoji informačního systému narazili na nějaký problém k
řešení. Označme si tento problém jako P1. (Pozn.: Podtržením nyní zdůrazňujeme, že tento
problém je konkrétní výskyt problému na který se dá přímo ukázat, tj. doslova tehdy a tehdy
jsme měli tento problém k řešení). Nechť jsme daný problém vyřešili konkrétním řešením R1.
Poté jsme někdy jindy narazili na další problém P2 a vyřešili jsme jej pomocí řešení R2, a poté
později nechť se objevil další problém a ten jsme také vyřešili, a tak dále...
Vznikla tak řada konkrétních problémů P1, P2, P3, ...PN, které jsme vyřešili konkrétními
řešeními R1, R2, R3, ...RN. Situaci bychom mohli znázornit tímto obrázkem:
P1
R1
P2
R2
P3
R3
Pn
Rn
Obrázek 1 Problémy a jejich řešení
strana 2
http://www.objects.cz
strana 3
Samotný vzor vznikne takto:
Představme si, že nastala situace, že při pohledu na tuto řadu dvojic "problém - řešení" jsme
nalezli mezi nimi opravdu výraznou shodu, která spočívá v tom, že v těchto problémech
řešíme stále totéž. Jinak řečeno problém je stejný a jeho řešení také, jenom situace se
opakuje s jinými prvky.
Podle principu opětovné použitelnosti se tedy nabízí zobecnění: Zavedeme proto „obecný
problém“, který vyřešíme „obecným řešením“ a tak vznikne tzv. vzor. Jednotlivé dvojice na
předešlém obrázku jsou pouze výskyty tohoto „obecného problému“ s „obecným řešením“.
V této chvíli sice ještě nevíme, jak lze technicky v modelování pomocí UML toto zobecnění
provést, ale je zřejmé, že tuto abstrakci opakujících se řešení můžeme provést. Lze tedy
zavést definici vzoru takto:
Vzor je opětovně použitelné řešení opakujícího se problému.
Následující obrázek ukazuje toto zobecnění pomocí dichotomie třída instance (viz předešlé
články).
strana 3
http://www.objects.cz
strana 4
P1
R1
P2
R2
P3
R3
Pn
Rn
P
R
Obrázek 2 Zobecnění do vzoru
Z tohoto závěru je samozřejmě jasné, že vzory jsou pro vývojáře velice užitečné. Platí totiž
pravidlo zdravé lenosti dobrého vývojáře: "Nač řešit vyřešené, když mám řešení k dispozici?"
(Poznámka: existují masochisté, kteří odmítají používat jiná řešení, než svoje. Jejich vývoj je
prodchnut radostnými výkřiky nad objevenými žárovkami. Jako "hra na vývoj" pěkné, ale z
hlediska ekonomiky firmy jsou tito pracovníci obtížně použitelní...)
Vzniká však otázka, jak se dá pracovat se vzorem jako s opětovně použitelným řešením a to
konkrétně technicky. Mimochodem vzato z hlediska modelování řešíme nyní otázku, jak
vypadá tzv. "metamodel vzoru", tj. meta-pravidlo pro všechny vzory.
strana 4
http://www.objects.cz
strana 5
Řešení, jak obecně pracovat se vzory, se skrývá v pojmu "účastníci vzoru" neboli tzv.
"Participants".
Vzor namodelujeme pomocí tzv. účastníků vzoru, což jsou pro vzor vlastně volné parametry.
V modelování UML se jedná obecně o libovolné prvky libovolného typu prvku z UML (třídy,
metody, zprávy apod.). Tito účastníci však nejsou prvky našeho konkrétního řešení, ale
chovají se podobně jako parametry v šabloně. Vzor použijeme tak, že do těchto parametrů
dosadíme naše konkrétní prvky.
Například nechť vzor X má účastníky A, B a C a jako příklad řeší spolupráci mezi prvkem
formuláře A, prvkem střední vrstvy B a prvkem z datové vrstvy C. Vidíme tedy obecné řešení
s parametry A, B, C. Když se nám tento vzor bude jako řešení hodit a chceme jej použít,
potom zavedeme naše řešení s prvky S, T, U a řekneme doslova: Použili jsme vzor X, kde S
je A, T je B, a U je C. Je zřejmé, že po tomto přiřazení "našich prvků k účastníkům" je v
dokumentaci úplně jasné, jak jsme problém vyřešili, stačí si místo A, B, C představit S, T, U.
Mezi vzorem a jeho použitím je tedy podobný vztah, jako mezi třídou a instancí (viz například
předešlé články o dichotomii třída instance). Proto také hovoříme o použití vzoru jako o
instanci vzoru.
Nyní je otázkou, jak tedy konkrétně vzory zavádět a jak je konkrétně používat a to zejména
s ohledem na předešlý dotaz.
Při definici modelu vzoru pomocí účastníků musíme být opatrní na jednu velkou záludnost.
Účastníci vzoru jsou „volné parametry vzoru“ a proto nejsou přímo našimi prvky našeho
řešení - ty se teprve přiřazují k těmto parametrům. Při tomto přiřazení může nastat situace (a
většinou také nastává), že k jednomu účastníkovi vzoru, tedy parametru vzoru, může být
přiřazeno několik našich prvků řešení (vztah 1 ku N).
Pro vysvětlení si uveďme příklad:
Ve vzoru je zavedena dědičnost a proto zavedeme jako účastníka (parametr vzoru) třídu
předka, nazvěme ji ve vzoru například jako třída CA. Následně zavedeme druhého účastníka
(tj. druhý parametr vzoru), třídu potomka, nazvěme jej například třída CB. Při použití tohoto
vzoru můžeme zavést vlastní prvky řešení, tedy třídu předka a několik (kolik chceme) tříd
potomků. Znamená to, že například v jednom konkrétním řešení podle tohoto vzoru
zavedeme jednoho předka CX (naše třída v řešení) a přiřadíme jej k prvku CA (předek ve
vzoru) a poté například tři třídy CY1, CY2 a CY2 jako potomky a ti odpovídají jednomu
parametru CB ve vzoru. Správný zápis vzoru je tedy jeden účastník třída předka CA
s multiplicitou použití 1 (můžete v řešení zavést pouze jednoho předka) a druh účastník
potomek třída CB s multiplicitou použití * (můžeme zavést kolik chceme prvků řešení
k tomuto účastníkovi vzoru).
strana 5
http://www.objects.cz
strana 6
Je třeba být opatrný na častý zápis v literatuře (například v GOF), kdy se mnohdy vzor
popisuje pomocí výčtu několika prvků a nikoliv pomocí multiplicit možných použití účastníků.
Důvodem tohoto postupu je vyšší přehlednost a snazší pochopení pro čtenáře. Předešlý
příklad zapsaný tímto ne úplně korektním přístupem vypadá takto:
CA
CB1
CB2
CB3
Obrázek 3 Nepříliš korektní zápis vzoru pomocí účastníků
Když se podíváme na tento obrázek, je zřejmé, že se nejedná o zápis vzoru, ale o jeho
aplikaci s třemi potomky. Čtenář si má „domyslet“, že potomků by mělo být vlastně N.
Správný zápis by tedy mohl vypadat například takto:
{1}
CA
{*}
CB
Obrázek 4 Korektnější zápis vzoru
strana 6
http://www.objects.cz
strana 7
Pro konstrukci vzoru je tedy důležité vědět, že:
Vzor je opakující se řešení vyjádřené pomocí účastníků vzoru, kteří se chovají jako
parametry vzoru. Přiřazením našich prvků řešení k parametrům „instanciujeme“ vzor
jako konkrétní řešení.
K účastníku vzoru je možné přiřadit buď jeden anebo vícero prvků, proto je třeba u
účastníků, tj. parametrů vzoru, udávat multiplicity povoleného přiřazení.
Mimochodem naše školení je postaveno zejména na použití vzorů. Použití vzorů je totiž také
velmi silným prostředkem, jak seznámit účastníky školení s doporučenými postupy při
návrhu IS.
V dalším pokračování článku budeme aplikovat tyto poznatky na již položenou otázku, jak
zavádět vzory ve standardních případech užití.
Nepřehlédněte:
Pobytový kurz Návrh IS pomocí OOP a UML v Bílých Karpatech jaro 2010
Pobytový kurz Návrh IS pomocí OOP a UML v Praze jaro 2010
Prezenční kurz Návrh IS pomocí OOP a UML v Praze jaro 2010 (pro účastníky z Prahy
a okolí)
Pokračování článku příště
strana 7