Odpověď na dotaz

ohledně asociační třídy v

modelu měření
Část 2.
Tento článek navazuje na předešlý článek jako jeho pokračování

autor RNDr. Ilja Kraval, http://www.objects.cz

srpen 2007
firma Object Consulting s.r.o.
 Odpověď na dotaz ohledně asociační třídy v modelu měření 2.část
© Ilja Kraval, 2007, http://www.objects.cz

Úvod
Opravdu mne potěšilo, když autor prvního příspěvku odpověděl velmi brzy mailem na
první část článku. Tímto se totiž z tvorby článku stala „oboustranná konzultace“.
Oddechl jsem si - nemusím si tedy pracně některé věci vymýšlet, „jak by mohly být“,
ale naopak budeme řešit případ konkrétně podle požadavků autora dotazu, tj. „jak
jsou požadovány, že by měly být“.
Zde je tedy další mail autora dotazu:

----------
Dobrý den,
děkuji za rozsáhlou odpověď, která mi ukázala novou perspektivu pohledu na
navrhovaný systém.
Nejdříve bych chtěl reagovat na odstavec, který se zmiňuje o Kompozici a
sdílení instancí. Jako studijní materiál o OOP a UML využívám skvělých
článků , které zveřejňujete na Vašem webu. Dále jsem si zakoupil knihu "UML
a unifikovaný proces vývoje aplikací" (J. Arlow a Ila Neustadt). Tato kniha
rozděluje vývoj aplikace do fází: analýza, návrh a implementace. Pochopil
jsem z ní, že v době analýzy se relace mezi třídami modelují jako prosté
asociace a až v době návrhu se transformují na agregace a kompozice,
popřípadě zůstanou prostou asociací. Můj model jsem zamýšlel jako
analytický, tak jsem tedy použil pouze prosté asociace s vyjádřením
kardinality a někde i rolí. Je mé chápání mylné nebo je jen více možností
použití a výkladů? Je mi jasné, že to co je v knize není dogma, ale zřejmě
ověřená metodika autorů, která implementuje pravidla RUP a UML.

Dále bych chtěl upřesnit popis problémové domény. Jelikož každé Měření
(přejmenováno na Protokol měření) představuje vlastně měřidlo nebo místo,
kde je příslušné měřidlo umístěno či připojeno. Například se jedná o
elektroměr, který je umístěn na přívodním vedení v hale č. 5. Potom by se
tedy jednalo o Měření z haly č. 5. Zpětně musím potvrdit, že název Měření
nebyl zvolen šťastně (i vzhledem k problémům vyjádření množného čísla).
Napadla mě ještě myšlenka, že by třída Protokol měření měla vztah typu
agregace s novou třídou Měřidlo, která by nesla informace o měřidle,
protože zamýšlený systém by měl tyto informace také evidovat. Dále bych
chtěl potvrdit, že opravdu není žádoucí sdílení instancí třídy Záznam
měření mezi instancemi třídy Protokol měření. Potom je tedy vztah kompozice
plně v souladu s mými záměry. Jen jsem ho nevyjádřil z důvodů, které jsem
uvedl výše.

Původní třída SadaHodnot (nyní Záznam měření) měla být kolekcí objektů typu
HodnotaMěření. Počet instancí v kolekci by závisel na typu měření (nyní
Protokolu měření). Tak například, pokud by se jednalo o měření elektrické
energie, pak by kolekce obsahovala objekty s hodnotami těchto veličin
výkonů a s potřeb energie. V případě měření odběru vody, by se jednalo o
jiné veličiny. Tím se chtěl navrhnout flexibilní strukturu, která by nebyla
závislá jen na dědičnosti. Možná je to zbytečná komplikace. Vycházím z
toho, že s daty se pracuje jako se záznamy, které obsahují vždy sadu hodnot

strana 2
 Odpověď na dotaz ohledně asociační třídy v modelu měření 2.část
© Ilja Kraval, 2007, http://www.objects.cz

určitých veličin, opatřených časovou značkou jejich pořízení. I v databázi

jsou tyto skupiny hodnot uloženy vždy v jednom řádku tabulky. Existují tedy
sady hodnoty, které odrážejí řádky tabulek a existují i sady, které jsou
výsledky agregačních funkcí nad daty z více záznamů. A také bych chtěl
poznamenat, že pro jeden Protokol měření může být vytvořeno více druhů Sad
hodnot tedy Záznamů měření.
Jak jsem pochopil z článku, tak jde teprve o první díl. Velice se tedy
těším na další, kde snad dojde i na zmiňované asociační třídy. Doufám, že
tímto jsem pomohl k doplnění Vaší představy o mém záměru. Snad jsem to jen
více nezamotal.

Předem děkuji za jakoukoliv konstruktivní a poučnou reakci.

K. M.

Metodiky a postupy
V první části mailu se autor zmiňuje o tom , jak a kdy nalézat povahu vztahů
v modelu tříd. Tady bych chtěl upozornit na jednu důležitou okolnost.
Poslaní metodik spočívá ve dvou bodech:
1. Metodika umožňuje unifikaci postupů ve firmě, což znamená pro firmu výhodu
zavedení vývoje jako opravdové „výroby SW“
2. Metodika umožňuje urychlit proces seznámení se pracovníků s požadovaným
know-how pro tvorbu SW a zlepšení jejich dovednosti při tvorbě SW (jednoduše
řečeno zvyšuje kvalitu pracovníků).

V každém případě však každou metodiku je třeba chápat pouze jako doporučení jak
používat techniku modelování v UML. Jakoukoliv vámi zavedenou metodiku proto
podrobte neustálé kritice s rychlou zpětnou vazbou s ohledem na výsledky vaší
práce ve firmě. Velmi rychle zavádějte změny, které vyplynou poučením z chyb,
špatných výsledků apod., ale na druhé je třeba vytěžit plus i z dobrých postupů,
osvědčených procesů atd. Současně doporučuji studovat materiály i z jiných
metodik, jiných škol modelování apod. a porovnávat je s vlastními zkušenostmi a s již
zavedenou metodikou ve firmě.
Z tohoto hlediska berte nejenom RUP, ale i moje další slova také jako doporučení:
Měl jsem možnost pracovat v několika desítkách firem jako externí konzultant a
školitel, a za mnoho let mé praxe se mi neosvědčilo vyhledávat povahu vztahu, tj.
zda je to kompozice apod., později. Moje doporučení zní: Vyhledávejte vztahy
kompozice a prosté asociace co nejdříve! Jsou to totiž velmi významné skutečnosti,
až tak významné, že určují samu logiku evidence! Ano, může se stát, že
přehodnotíte vztah na základě přesnějších informací, ale tím také přehodnotíte logiku

strana 3
 Odpověď na dotaz ohledně asociační třídy v modelu měření 2.část
© Ilja Kraval, 2007, http://www.objects.cz

vztahů. Avšak platí, že díky znalosti povahy vztahu jste stále uvnitř logiky věci a máte
o ní dobrou představu. Asociace bez udání kompozice, bez udání běžné asociace
atd. (viz výčet vzorů v předešlém článku), nemá totiž v sobě úplnou logiku a tedy
nemusíme mít dobrou a správnou představu o logice evidence bez udání těchto
vlastností! Proto doporučuji povahu těchto vztahů nalézat co nejdříve i za cenu toho,
že budou možná časem přehodnoceny.

Třída Objekt měření a možná chyba

„exploze subtříd“
Jako další bod se autor zmiňuje o měřidle, ke kterému je vztaženo každé měření
(přesněji protokol měření). Pokud se nahlédnem do již zmíněné knihy Analysis
Patterns, také autor této knihy zavádí takovouto třídu, nazývá ji Object of Care (str.
59 uvedené knihy). My tuto třídu nazveme podobně Objekt měření.
Nyní musíme spolu s autorem uvedené knihy zohlednit maximální flexibilitu aplikace.
Určitě by bylo dobré a prospěšné dopředu počítat s několika možnými typy objektů
měření. Podobně i v knize je zaveden tento mechanismus, kdy objektem měření
může být například pacient, populace anebo například divize podniku.
Při znalosti vztahu generalizace a jak ho prakticky hledat se pokusíme navrhnout
model pro Objekt měření. Důležité nyní je, zda chceme anebo nechceme oddělit od
sebe a znovu provázat pojmy se samotným měřením.
Poznámka: Vztah generalizace je probírán velmi podrobně jak teoreticky, tak
v příkladech na našem pobytovém školení včetně postupů jeho vyhledávání.
Jinak řečeno, je zřejmé, že se tu dědičnost objeví, protože zřetelně slyšíme „několik
možných typů objektu měření“, ale v jaké podobě tento vztah zavedeme?
Aby bylo jasno, co tím myslím, uvedu jako příklad obě situace, spojené a oddělené
pojmy s měřením:
Máme v evidenci pojem elektroměr. Můžeme jej chápat jako evidovaný kus bez
evidence měření. Má svoje vlastnosti, jako je např. evidenční číslo, datum instalace
apod. Jakmile však začneme hovořit o měření, tak nemluvíme přímo o instanci
tohoto evidovaného elektroměru, ale hovoříme o instanci objektu měření tohoto
elektroměru. Tato instance objektu měření elektroměru si ukazuje „koho vlastně
měří“ pomocí běžné asociace na tento elektroměr. Tato varianta řešení potom
vypadá takto:

strana 4
 Odpověď na dotaz ohledně asociační třídy v modelu měření 2.část
© Ilja Kraval, 2007, http://www.objects.cz

Objekt měření Protokol měření

0..*

Objekt měření Pacient

elektroměr

1 1

Elektroměr Osoba

obrázek 1 Objekt měření elektroměr není přímo elektroměr, ale ukazuje si na něj
běžnou asociací vztahem do seznamu

Druhá možnost je udělat elektroměr rovnou objektem měření a dát jej jako dědice
objektu měření přímo přes dědičnost do stromu takto:

Objekt měření Protokol měření

0..*

Elektroměr Pacient

obrázek 2 Objekt měření elektroměr je přímo elektroměrem

strana 5
 Odpověď na dotaz ohledně asociační třídy v modelu měření 2.část
© Ilja Kraval, 2007, http://www.objects.cz

Tady však vznikl kříženec: Elektroměr vystupuje jako prvek v evidenci přístrojů a
současně jako prvek ve stromu dědičnosti objektů měření!
Při znalosti velkého nebezpečí anti-vzoru kombinace v dědičnosti a následného
efektu „exploze subtříd“ a souběžně při znalosti použití vhodného vzoru BRIDGE se
přikloníme k sice složitější, ale předpokládám, že správnější první variantě.
Poznámka: O vzorech a anti-vzorech viz například cenově dostupné a levné
semináře s názvem Semináře objektových technologií.
Důvod našeho rozhodnutí je následující: Určitě budou existovat také stromy
dědičnosti u jednotlivých měřených prvků, anebo přinejmenším hrozí, že budou
existovat. Například bude existovat celý strom dědičnosti u přístrojů. Lze oprávněně
očekávat, že přístroje jako elektroměr, plynoměr atd. budou mít společného předka
(například abstraktní třídu Přístroj anebo podobně). Svou vlastní dědičností působící
mimo naši agendu měření se budou tyto pojmy samy o sobě „větvit“ ve stromu
dědičnosti. Mimochodem, pokud to nenastane zrovna zde u přístrojů (o čemž silně
pochybuji), hrozí to u libovolné jiné skupiny entit, která strom dědičnosti může
potřebovat.
Jakmile tato situace nastane, musíme bohužel „prokřížit stromy“ s třídou Objekt
měření (vzniknou Objekt měření elektroměr, Objekt měření plynoměr atd.). Pokud
použijeme variantu „objekt měření si ukazuje, koho měří přes běžnou asociaci“,
máme tak problémy spojené s vlastnostmi přístrojů versus jiných prvků odděleny
elegantně od samotného měření („nekříží se“) a nemusíme každou variantu prokřížit!
Navíc v kombinaci se vzorem BRIDGE (jeden ze vzorů, který řeší tyto problémy
„kříženců“) se lze přímo provázat na vrchol stromu dědičnosti u přístrojů bez nutnosti
tvorby jednotlivých kombinací. Proto se přikláníme k tomuto řešení!
Uzavřeme tento krok ještě doporučovaným použitím vzoru DISKRIMINÁTOR, tj.
číselníkem Typ objektu měření. Námi zvolený diagram tříd tedy můžeme vyjádřit
pomocí následujícího obrázku:

strana 6
 Odpověď na dotaz ohledně asociační třídy v modelu měření 2.část
© Ilja Kraval, 2007, http://www.objects.cz

Typ objektu
měření

Objekt měření Protokol měření

0..*

Objekt měření přístroj Objekt měření Pacient

Agenda přístrojů Agenda osob

1 1

Přístroj Osoba

obrázek 3 Objekty měření různého typu

Jednosměrná asociace z prvku Objektu měření přístroj do agendy přístrojů na

Přístroj udává, na čem (na kterém přístroji) se vlastně měří. Všimněte si, že i vrstvy
jsou dobře zachovány a nejsou promíchány, tj. agenda přístrojů zůstala opravdu
jednoduchou agendou evidence přístrojů.

strana 7
 Odpověď na dotaz ohledně asociační třídy v modelu měření 2.část
© Ilja Kraval, 2007, http://www.objects.cz

Vzor QUANTITY
Jako další krok použijeme vzor QUANTITY, který je uveden ve zmíněné knize (str.
36). Tento vzor je velmi jednoduchý, avšak velmi účinný ☺.
Pokud provádíme evidenci nějaké hodnoty něčeho, doporučuje se zavést
jednoduchý číselník měrných jednotek (nebo prostě jen jednotek, aby tento pojem
nemusel znít fyzikálně). Požadovaná evidence množství něčeho se zavede jako
kombinace „hodnota“ umístěná někde v nějakém prvku Quantity s hodnotou plus
odkaz do tohoto číselníku, který uvádí jednotku množství:

Unit
- kod: int
Quantity 1 - text: string
- zkratka: string
- value: number

obrázek 4 Vzor QUANTITY ve své jednoduché podobě

V číselníku jednotek (v předešlém obrázku jej reprezentuje třída Unit) nehledejme nic
složitého, je to jednoduchý prostý číselník se strukturou (kód, text, zkratka),
který instančně obsahuje potřebné jednotky. Příklad instančního obsahu číselníku
jednotek v textovém tvaru může vypadat například takto:

Kód text zkratka

1 litr l
2 metr m
3 kus ks
4 volt V
5 ampér A
6 kilowatt kW
7 hodina h

strana 8
 Odpověď na dotaz ohledně asociační třídy v modelu měření 2.část
© Ilja Kraval, 2007, http://www.objects.cz

Pomocí konstrukce tohoto vzoru můžeme začít řešit třídu Záznam měření (viz
předešlá část článku), díky čemuž se získá flexibilita záznamů měření. Zde se opět
projevuje nevýhoda češtiny u slova měření. Pokud hovořím o prvku Záznam měření,
mám tím na mysli jedno jediné měření s jednou jedinou hodnotou. K otázce Sady
záznamů měření se ještě vrátíme na konci tohoto článku!
Navrhněme tedy Záznam měření (jedna instance = jedna naměřená hodnota !)
například takto:

Měrná jednotka

Záznam měření 1
- hodnota: number

obrázek 5 Použití vzoru QUANTITY pro náš příklad

Otázkou je, zda měření probíhá tak, že v rámci jednoho protokolu měření jsou
všechny záznamy měření v jedné jediné jednotce měření anebo zda má každý
Záznam měření svou (a tedy jinou) jednotku. Například lze předpokládat, že měření
u daného elektroměru se neustále měří v jednotce kWh pro všechna měření v
protokolu. Dá se sice předpokládat, že tomu tak je, ale teoreticky by mohl existovat
případ, že v jednom protokolu by mohly být záznamy měření s různými jednotkami!
Poznámka: Například na jednom našem školení jeden účastník z Agentury na
ochranu životního prostředí nás seznámil s velmi složitou agendou evidence měření
a pozorování v přírodě. Musím poznamenat, že se jednalo o poměrně pěkné oživení
našich cvičení zaměřených na konkrétní praktické příklady modelování pomocí UML.
Řešili jsme evidenci pro sčítání hnízd, kroužkování ptáků atd. ☺ Dovedu si v této
agendě představit, že by v jednom protokolu existovala měření „různých věcí
v různých jednotkách“. V tomto případě musí existovat odkaz do číselníku Měrná
jednotka u každého prvku Záznam měření, protože se může prvek od prvku lišit.
Pokud by tomu nebylo (a to je asi většina případů), tak by stačilo, aby si do číselníku
Měrná jednotka ukázal pouze protokol měření a všechny prvky Záznam měření mají
tímto tento odkaz společný.
Otázkou je, jak vyřešit situaci, kdy 99% procent všech případů bude spadat pod
algoritmus, kdy existuje protokol měření a ten určuje společnou měrnou jednotku
měření v celém protokolu a výjimečně se bude vyžadovat, aby se v jednom protokolu
objevila měření v různých jednotkách. Můžeme navrhnout „hybrid“ a tím pokrýt obě
varianty, např. takto:

strana 9
 Odpověď na dotaz ohledně asociační třídy v modelu měření 2.část
© Ilja Kraval, 2007, http://www.objects.cz

Protokol měření

+implicitní jednotka
0..* 1
Záznam měření Měrná jednotka
- hodnota: number
0..1

obrázek 6 Hybrid: protokol má jednotku a záznam také

Všimněme si, že oproti předešlému modelu se změnila násobnost vazby mezi prvky
Záznam měření a Měrná jednotka z 1 na 0..1 a současně přibyl odkaz z prvku
Protokol měření do prvku Měrná jednotka. U tohoto modelu je důležité vysvětlit
dynamický průběh měření, což provedeme v popisu scénářů náležitého prvku v USE
CASE modelu.
Algoritmus je následující:
U každého prvku Protokol měření se musí vždy vybrat implicitní prvek Měrná
jednotka, což se provede naplněním vazby - odkazu do číselníku, viz předešlý
obrázek. Při vzniku nové instance Záznamu měření (v evidenci systému
samozřejmě, například importem dat apod.) se nejprve kontroluje, zda příchozí data
obsahují svou specifickou jednotku měření (kód jednotky apod.). Pokud ano, vyplní
se vazba z prvku Záznam měření do prvku Měrná jednotka. Každý prvek Záznam
měření má tak přiřazenu měrnou jednotku: Pokud je vyplněna specifická jednotka pro
Záznam měření, platí tato, pokud ne, platí implicitní pro celý Protokol měření.
Zde bychom se měli rozhodnout mezi třemi možnými variantami (což je vlastně
otázka ke konzultaci!):
1. varianta řešení
Existuje vždy pouze jedna jednotka měření pro jeden protokol. Všechny záznamy
měření z jednoho protokolu mají stejnou jednotku. V tom případě stačí vést odkaz
z protokolu měření na tzv. implicitní jednotku a další odkazy ze záznamů měření na
měrnou jednotku nejsou třeba.
2. varianta řešení

strana 10
 Odpověď na dotaz ohledně asociační třídy v modelu měření 2.část
© Ilja Kraval, 2007, http://www.objects.cz

Každý záznam měření v daném protokolu má svou jednotku měření a neexistuje

implicitní jednotka měření v celém protokolu (pozn.: tuto variantu dopředu považuji
za nepravděpodobnou...)

3. varianta
Záznamy měření mají implicitní jednotku danou protokolem, pokud není pro daný
záznam řečeno jinak (možnost specifických jednotek u záznamů). Je možné, aby
záznam měl svou specifickou jednotku měření odlišnou od implicitní danou
protokolem. Pokud ji nemá, platí tedy pro tento záznam implicitní jednotka protokolu.
S největší pravděpodobností se bude rozhodovat mezi variantou 1 a 3. Varianta 1 by
se mi líbila pro svou jednoduchost, varianta 3 je však univerzálnější.
Poznámka: Je možné přijmout řešení, že ve verzi 1.0 bude systém fungovat pomocí
varianty 1 a pokud se v požadavcích narazí na požadavek specifických jednotek u
záznamu měření v rámci jednoho protokolu, zavedeme variantu 3 ve verzi 2.0.
Pouze na okraj podotknu, že pokud se zvolí varianta 3 a bude se řešit pomocí jazyka
silného na OOP, měl by se použít některý ze vzorů Design Patterns GOF (např.
STATE anebo STRATEGY anebo CHAIN OF RESPONSIBILITY podle náhledu na
řešení). V každém případě by se měl využít efekt zapouzdření a polymorfismu. Zvně
by vůbec klient neměl poznat, „kam si záznam měření chodí pro měrnou jednotku a
jak“.

Pojmy Sada hodnot a Protokol

Dalším krokem by mělo být vyřešení otázky pojmu Sada hodnot, o které se autor
zmiňuje v mailu na začátku tohoto článku. Zde je však třeba položit otázky, tedy opět
si připravíme poznámky ke konzultaci:
Máme chápat sadu hodnot jako něco, co dále dělí záznamy měření do skupin
v rámci jednoho protokolu, tj. necháme v protokolu vzniknout 2-úrovňový strom?:

strana 11
 Odpověď na dotaz ohledně asociační třídy v modelu měření 2.část
© Ilja Kraval, 2007, http://www.objects.cz

Protokol měření

0..*
Sada záznamů měření

0..*
Záznam měření
- hodnota: number

obrázek 7 Sada záznamů měření jako mezi-úroveň v Protokolu měření

Potom je však otázkou, co tato Sada záznamů měření jako mezi-úroveň vlastně
znamená. Konkrétně dotaz zní:
Jak se otevře a uzavře jedna sada téhož protokolu, jak se od sebe odlišují
(identifikují), jak přicházející údaje budou zařazovány do jednotlivých sad?
Tady se musí přesně popsat představa o dynamice jak vzniku protokolu, ale také
vzniku sady, a v neposlední řadě i vzniku záznamu měření v rámci sady (myšleno
samozřejmě vznik instancí v evidenci), jinak pojmy nebudeme správně chápat. Jak
se bude vědět, že nově vzniklý záznam měření patří právě do této sady měření?
Je možné, že pojem sada je zbytečný a vystačíme s protokolem měření, možná ne.
Protože nemáme nyní dost informací, počkáme si na další mail týkající se dynamiky
u sady hodnot měření ☺.

Závěr druhé části

Co se týče konzultací, nemáme nyní úplně jasno ohledně těchto bodů a ty je třeba
vyjasnit:
• Stačí pro protokol jedna měrná jednotka?

strana 12
 Odpověď na dotaz ohledně asociační třídy v modelu měření 2.část
© Ilja Kraval, 2007, http://www.objects.cz

• Jaký význam má Sada měření v rámci Protokolu?

Mimochodem, i když jsme odpověděli na některé dotazy a návrhy z mailu, stále jsme
ještě nenarazili na použití asociační třídy. Ale nemusíme mít obavy, vzory v kapitole
„Observations and Measurements“ v knize Analysis Patterns dále řeší následující
přehršli otázek (namátkou vybrány):
• Jak zavést „složené jednotky“ (příklad - složená jednotkou je kWh)
• Jak zavést možný převod mezi jednotkami
• Jak dále rozšířit pozorování i o tzv. kategorizaci, kdy se neměří hodnoty, ale
provádí se namísto toho tzv. kategorizace (pozorování jako „škatulkování“,
nikoliv měření hodnot)
• Jak zavést čas pozorování
• Jak zavést jevy měření
• atd. atd.

... a tam všude se to asociačními třídami jenom hemží.... V některém dalším

pokračování tedy na ně určitě narazíme!

- pokračování příště -

strana 13