Odpověď na dotaz ohledně asociační třídy v modelu měření

Transkript

1 Odpověď na dotaz ohledně asociační třídy v modelu měření Část 3. Tento článek navazuje na předešlé články jako jejich pokračování autor RNDr. Ilja Kraval, srpen 2007 firma Object Consulting s.r.o.

2 Úvod Je potěšitelné, že autor příspěvku odpověděl opět velmi brzy mailem i na druhou část článku. Zde je další mail autora dotazu jako odpověď na předešlé dotazy: ---- Dobrý den, zrovna dnes jsem chtěl reagovat na druhý díl článku, za který opět děkuji. Tímto bych chtěl odpovědět na otázky, uvedené v závěru druhé části. 1. Stačí pro protokol jedna měrná jednotka? Nestačí, protože v rámci jednoho protokolu se měří několik veličin, které mají odlišné jednotky. Například u již zmíněného elektroměru se v jeden okamžik zaznamenává hodnota spotřeby činné energie (Wh), jalové energie (Varh), činného výkonu (W) a jalového výkonu (Var). Stejně tak to může být i u vodoměrů, pro který se zaznamená hodnota kumulovaného proteklého množství a okamžitý průtok v okamžiku záznamu. Proto je každý záznam opatřen časovou značkou. 2. Jaký význam má Sada měření v rámci Protokolu? Pokusím se popsat celý proces záznamu hodnot měření protokolu. Pro každý protokol se periodicky zaznamenávají hodnoty sledovaných veličin (podle typu protokolu). Vždy jsou zaznamenány aktuální hodnoty veličin a časová značka, která určuje kdy byly hodnoty pořízeny, tedy zaznamenány. Každý protokol by měl tedy obsahovat sadu záznamů pořízených v určitém období. Každý záznam by měl obsahovat časovou značku a hodnoty všech sledovaných veličin, zaznamenané v tomtéž okamžiku. Systém potom provádí operace nad těmito záznamy, které umožňují například bilanční výstupy (např.: spotřeby elektrické energie za určité období apod..). Současný systém pracuje jen s hodnotami elektrických veličin, získaných z elektroměrů, ale v budoucnu by měl být schopen pracovat se záznamy i jiných veličin z jiných měřidel. Třídu Sada záznamů měření bych tedy doplnil o vlastnost, která strana 2

3 by obsahovala časovou značku, která by určovala čas pořízení hodnot objektů Záznam měření. Připouštím, že název třídy Sada záznamů měření není příliš vhodný, ale v uvedeném kontextu se mi nezamlouvá ani pojmenování třídy Záznam měření. Ten by se mi potom více hodil jako název třídy Sada záznamů měření, protože to je opravdu jeden záznam měření v určitém okamžiku. Třída obsahující hodnotu by se mohla jmenovat třeba Veličina, protože nese hodnotu jedné z veličin. Je to pouze má úvaha. Snad se mi podařilo odpovědět na Vaše konzultační dotazy. Pokud by se mi to nepodařilo srozumitelně, tak mě neváhejte kontaktovat. Velice si vážím Vaší spolupráce a námětů. S pozdravem K. M Děkuji za poslední slova a musím i ze své strany říci, že i já s vážím hodnotných příspěvků autora. Jako autor článku rád konstatuji, že máme dobrého konzultanta, který nám předává přesné odpovědi. Mimochodem jedna poznámka: Pokud chceme jako analytici dostávat od konzultantů přesné odpovědi, musíme znát postupy a naučit se, jak pokládat přesné otázky. Na to existuje několik praktických doporučení, což je samozřejmě velmi dobrý námět pro některý z dalších článků. Nyní si však musíme probrat odpovědi autora příspěvku a pokusit se je tzv. analyticky uzavřít nějakým návrhem. Možná to není poslední pokus, ale možná už cítíme, že jsme velmi blízko. Sada měření a vzor TEMPLATES Z předešlé odpovědi mailem se mnohé vyjasnilo. Je již zřejmé, jaký má pojem Sada měření analytický význam. Důležitou skutečností je ta okolnost, že v daném časovém okamžiku dojde k měření několika hodnot několika veličin. Tak vznikne jedna sada měření. V daném protokolu se pak vyskytují sady měření jako množina současně naměřených hodnot (doufám, že jsem to pochopil správně!). Učiňme nyní jeden předpoklad a poté pokus o uzavření pojmu sady měření. strana 3

4 Předpokládejme, že v daném protokolu se vyskytují sady téhož typu ve smyslu vždy stejné veličiny se stejnými jednotkami, ale různými hodnotami v různém časovém bodě (myslím, že to lze logicky usoudit z mailu). Znamená to, že instance sad měření se od sebe v protokolu neliší veličinami, ale hodnotami naměřených veličin a časem. Tímto je samozřejmě dáno co se má měřit hned na začátku, a to už při založení protokolu (autor se zmiňuje o typu protokolu). Existuje i druhá složitější varianta, kdy protokol může obsahovat sady různých typů s různými veličinami pro měření (tj. například u elektroměru se v jednom protokolu jednou měří to a jednou něco jiného), ale nepředpokládáme nyní, že by tomu tak bylo. Poznámka: Je zřejmé, že v případě, kdy by nastala situace různé veličiny měření v sadách v protokolu, potom lze tento problém vyřešit tak trochu nečistou fintou a obezličkou pomocí maximální sady měření, která obsahuje všechny veličiny všech možných měření v protokolu. Někdy se něco měří a někdy ne. Nečistota se projeví zbytečně velkou sadou měření někdy s mnoha nic hodnotami a označením tady se vůbec neměřilo (aby nedošlo k záměně k chybě měření, tj. kdy se chtělo měřit a nic nenaměřilo). Tuto variantu zde však nebudeme rozebírat. Pro nás se Sady měření v protokolu podobají jako vejce vejci a liší se pouze hodnotami měření a časem. Pokud tedy předpokládáme, že v protokolu se vyskytují typově stejné sady měření lišící se pouze obsahem naměřených hodnot, lze zde použít analytický vzor TEMPLATES. Tento vzor se aplikuje poměrně dost často, paradoxně mnohdy i bez znalosti jeho existence, tj. bez vědomí, že nějaký takový vzor vůbec existuje. Myšlenka vzoru TEMPLATES je poměrně dosti jednoduchá. Mnohokrát jako analytici narazíme na situace, kdy lze evidentně v analytickém modelu IS vidět něco jako evidované instance šablon, neboli předpisů, následně evidentně vidíme v systému evidované instance těchto vyplněných předpisů, tj. vidíme evidované instance vyplněných šablon. Jako klasický příklad na vzor TEMPLATES bych uvedl aplikaci flexibilní dotazník, která má za úkol evidovat dotazníky a následně vyplnění dotazníků respondenty. V takové aplikaci existují evidované dotazníky jako šablony, které se časem vyplňují, a to tak, že vznikají nové instance již vyplněných dotazníků daného dotazníku - šablony. Na jedné straně vidíme instance dotazníků jako šablon, na straně druhé spatřujeme instance vyplněných dotazníků. strana 4

5 Jednu věc však musíme u tohoto vzoru zdůraznit: Evidované šablony (například dotazníky k vyplnění) podléhají základnímu pravidlu evidence, tj. jedná se o živou evidenci, jakou je každá jiná evidence. Má tedy tuto axiomatickou vlastnost: Evidence se odehrává v instancích a vlastnosti evidovaných instancí se definují ve třídách. Jinak řečeno, také evidované šablony podléhají evidenci a nejsou v aplikaci takříkajíc natvrdo (nejsou umístěny staticky na úrovni tříd, ale dynamicky na úrovni instancí). Pokud jsme tuto vlastnost vzoru nepochopili do důsledků, tak pro její objasnění stačí jediná věta: Určitě se v systému aplikace flexibilní dotazník bude nacházet případ užití (tj. USE CASE) vytvoření nového dotazníku, něco jako Vytvoř nový dotazník resp. jiné případy užití správy dotazníků jako šablon. Uživatel si tak může postavit fungl nový dotazník a nabídnout jej k vyplnění. Jinak řečeno i evidence šablon je normální živá evidence ovládaná uživatelem. Teoretická poznámka: Všimněme si, že tento vzor lze také chápat jako imitaci vztahu třída - instance. Na jedné straně jsou instance šablony jakoby třídami (tj. evidence souhrnu vlastností) a na straně druhé instance vyplněných šablon vystupují jako instance imitující instance těchto šablon (vyplněné vlastnosti). Vrátíme se teď k naší agendě a pokusíme se o nějaké závěry, tj. nejprve si slovy řekněme, jakou máme představu: Založí se protokol, který nějak určí, co se bude měřit. Tím je dána množina veličin a měrných jednotek budoucích sad měření. Při vzniku nové instance sady měření se odněkud přeberou hodnoty veličin a časový okamžik měření, veličiny a jednotky jsou již dány, takže tím se vyplní daný dotazník dané sady měření. Co se týče časového okamžiku sady měření, dá se volit mezi dvěma variantami: Buď bude časová značka dána do sady natvrdo jako její atribut anebo využijeme již existující konstrukci podle vzoru QUANTITY a zařadíme časovou značku jako jednu z měřených hodnot, samozřejmě výjimečnou tím, že je povinná. K této složitější variantě bychom se přiklonili v případě, že by v různých měřeních u různých přístrojů docházelo k udání času pro danou sadu měření různým způsobem a např. v jiných jednotkách. Pokud nám však nehrozí měření času v různých jednotkách, přikloníme se k variantě čas je měřen stále stejně a bude to atribut. Samozřejmě tato otázka souvisí i s problémem, jak moc máme pod kontrolou všechna měření a zda nám nebudou někdy v budoucnu přicházet i externí data s různými jednotkami času při určení časového okamžiku sady měření. strana 5

6 Dále rozšíříme předešlý model z minulých článků o pojem Veličina. Jedná se o opravdu jednoduchý číselník veličin, obsahující kód, text, zkratku, instančně například s hodnotami textů výkon, napětí, proud atd. Jako další provážeme tento číselník s číselníkem měrných jednotek pomocí tzv. asociační třídy a vytvoříme tak Povolené kombinace Veličina versus Měrná jednotka. Tady se samozřejmě musíme pozastavit, protože součástí úplně prvního dotazu byla otázka týkající se fungování asociační třídy. Jak funguje asociační třída Asociační třída je v UML definována poměrně dost jednoduše, avšak jak jsem zjistil, bývají s ní mezi analytiky tak trochu problémy. Osobně se domnívám, že určitá nedorozumění vznikla díky poměrně složitému (podle mne dokonce chybnému) výkladu převzatému z jedné knihy (anglická v překladu). V UML je asociační třída definována velmi jednoduše: Je to třída, jejíž instance (resp. instance jejích dědiců, pokud je abstraktní) zprostředkovávají asociaci, tedy vztah mezi instancemi. Jinak řečeno, je to třída a současně asociace. Definice jak vidět sice krátká, ale nepříliš srozumitelná. Co tedy vlastnost asociační třídy umět zprostředkovat vztah mezi instancemi, neboli asociaci, vlastně znamená? Podstata je velmi jednoduchá a vysvětlíme si ji na dvojné asociační třídě. Nejprve se však vrátíme na začátek výkladu těchto článků a znovu si připomene úvodní doporučení: Chceme-li dobře pochopit poslání tříd v nějakém modelu tříd, musíme velmi dobře pochopit fungování instancí z těchto tříd. Proto asociační třídu musíme vysvětlit pomocí instančního modelu. Představme si nějakou konkrétní třídu A, a několik jejích instancí, označme je A1, A2, A3 atd. Podobně si představme nějakou konkrétní třídu B a několik jejích instancí B1, B2, B3 a B4. Zavedeme třetí konkrétní třídu, označme ji v tomto příkladu jako C a několik jejích instancí jako C1, C2, C3 atd. Nechť tyto instance ze třídy C mají takovou strukturu, že každá instance ze třídy C v sobě obsahuje (mimo jiné) jeden ukazatel (tj. má odkaz) na jednu instanci ze třídy A, a má (mimo jiné) jeden odkaz na instanci ze třídy B. Příklad takovéto situace může vypadat takto: strana 6

7 A1 B1 C1 A2 B2 C2 A3 B3 C3 B4 C4 obrázek 1 Struktura instancí ze třídy C Pokud je třída asociační (v příkladu nyní jako dvojná), její instance (resp. instance dědiců u abstraktní třídy) mají povinně tuto strukturu zobrazenou na předešlém obrázku jako strukturu instancí ze třídy C. Je-li tedy třída asociační, její instance (resp. instance dědiců) mají každá po jednom odkazu do seznamu instancí, které třída propojuje jako asociace. Pozor však na jednu záludnost: Obrácené tvrzení neplatí! Pokud mají instance ze třídy C strukturu jako na předešlém obrázku, nemusí (ale mohou) reprezentovat asociační třídu. Naopak však platí na sto procent, že je-li třída C asociační, její strana 7

8 instance (nebo instance potomků u abstraktní třídy) mají strukturu zobrazenou na předešlém obrázku. Navíc nechť instance ze třídy C mají jako seznam tu vlastnost, že podporují funkcionalitu podobnou filtru: Je možné díky této funkcionalitě nad seznamem instancí ze třídy C vybrat pouze ty instance ze třídy C, které si ukazují na jednu vybranou instanci ze třídy A, a naopak, u druhého filtru z druhé strany, dovedeme pomocí druhého filtru vybrat ty instance ze třídy C, které si ukazují na jednu vybranou instanci ze třídy B. A těmito filtry nad odkazy do seznamů se zprostředkovává daný vztah mezi instancemi ze třídy A a instancemi ze třídy B, tedy asociace. Podívejme se na předešlý obrázek a zkusme zodpovědět: Jaký bude výstup filtru (zleva) pro vstup instance A1 do filtru? Odpověd: Instance C1. (Pozor, nikoliv B1! Filtry pracují nad seznamem instancí ze třídy C, tedy nad zelenou oblastí a nikde jinde!) Jaký bude výstup filtru pro vstup instance A2? Odpověd: C2. Zajímavá je situace u vstupu instance A3. Výstup filtru je v tom případě C3, C4. (poznámka: Výstupem filtrů je tedy obecně seznam instancí ze třídy C a nikoliv jedna instance!) Všimněme si, co nám tyto filtry zleva a zprava vlastně poskytují ve svém důsledku! Pokud držíme v ruce instanci ze třídy A (například A3 jako v posledním příkladu) a hodíme ji jako vstupní parametr do filtru zleva, dostaneme ty instance ze třídy C, které si na tuto instanci ukazují (pro A3 dostaneme C3, C4). Uvnitř těchto instancí jsou nějaké vlastní atributy, ale je tam vždy i ukazatel do seznamu ze třídy B. Takže díky tomu dostaneme z C3 instanci B3 a z instance C4 dostaneme B2. Takže když to shrneme: Máme na vstupu A3, dostaneme C3 a B3 plus C4 a B2. Všimněme si, že díky vlastnostem instancí ze třídy C zavedené takto: Držím ukazatele do seznamů a umím nad nimi filtrovat, nám instance ze třídy C zprostředkovávají vztah mezi instancemi ze třídy A a instancemi ze třídy B (pozn.: Navíc instance ze třídy C nám ještě mohou dodat své vlastní informace ze své vlastní struktury). A takto jednoduše funguje asociační třída! Velmi se mi líbí výstižné přirovnání, že každá instance ze třídy C reprezentuje jednu evidenci - registraci jedné spřažené dvojice instancí ze tříd A a B. Asi nemá smysl uvádět funkcionalitu filtru i z druhé strany, stačí jen uvést, že pro instanci B2 dostaneme filtrem zprava instance C2 a z ní A2 plus C4 a z ní A3. Závěr vysvětlení asociační třídy tedy zní: Pokud požadujeme, aby instance ze třídy C měly tyto popsané vlastnosti zprostředkující vztah mezi instancemi ze tříd A a B (průchod přes filtrace nad odkazy), navrhneme ji jako asociační třídu a graficky znázorníme takto: strana 8

9 A B C obrázek 2 Třída C jako asociační třída Tím jsme zavedli všechny uvedené vlastnosti evidence spřažených dvojic. Povolené měrné jednotky veličin, převody mezi jednotkami V analytických modelech se velmi často používá vzor POVOLENÉ KOMBINACE, který využívá asociační třídu pro vyjádření povolených kombinací ze dvou seznamů. Zrovna tento vzor se nám hodí do našeho příkladu. Chceme totiž vyjádřit tu skutečnost, že daná jedna veličina může být měřena pouze v několika povolených jednotkách. Zavedeme povolené kombinace mezi třídou Veličina a třídou Měrná jednotka takto: Veličina * * Měrná jednotka Povolené MJ veličin obrázek 3 Povolené měrné jednotky veličin strana 9

10 Podobně, pokud se podíváme do knihy Analysis Patterns, zjistíme, že autoři zavádějí také vztah mezi měrnými jednotkami, který nazveme Převod (v knize zvolil název Conversion Ratio), což je další pěkný příklad na použití asociační třídy. Chceme vyjádřit tu skutečnost, že mezi jednotkami mohou být převody jednotek (gram kilogram apod.), současně vyjadřujeme i hodnotu poměru tohoto převodu (tisíc apod.). Protože se poměry neustále opakují, bude asi vhodnější tyto poměry zavést jako číselník poměrů. Převod mezi jednotkami zavedeme tedy takto: Měrná jednotka +převod od * +převod do * Převod 1 Poměr obrázek 4 Převod mezi jednotkami Jedna poznámka ke směru: Zde je důležité upozornit na názvy odkazů (budou reprezentovány například cizími klíči v DB) jako převod od a převod do. To reprezentuje nad nimi zavedené filtry buď zleva nebo zprava a udává, zda hodnotu poměru brát v původní hodnotě (filtr ve směru převod od k převod do ) anebo v hodnotě reciproční (obrácený směr průchodu) ve směru převod do k převod do ). Při pohledu na předešlý obrázek je třeba podotknout, že Poměr lze zavést i jako prostý atribut Převodu. Například převod od gramu do kilogramů má hodnotu 1000, což zde je odkaz do číselníku (například kód 2, hodnota 1000) a to proto, abychom nemuseli tuto velmi častou hodnotu poměru neustále zavádět. Navíc můžeme spatřovat výhodu i v tom, že při založení nového převodu si můžeme vybrat z číselníku poměrů (např. combobox apod.). Druhá možnost je zavést prostý atribut ve třídě Převod a do něj jednoduše zadat hodnotu Hodnota tohoto atributu se strana 10

11 tak bude vyskytovat ve všech převodech s hodnotou tisíc. Obě možnosti přicházejí v úvahu a každá má své výhody a nevýhody. V knize Analysis Patterns je ještě zaveden pojem Složená jednotka (například Wh, ms -1 apod.). Nebudeme otevírat tuto Pandořinu skřínku, odkážeme zájemce na tuto kapitolu v knize. Jenom upozorním, že pokud jsme zavedli pojem Veličina, měli bychom narozdíl od autorů knihy skládat nejprve veličiny a z toho teprve odvozovat skládání jednotek. Nyní bychom se měli pustit do sady měření a použití vzoru TEMPLATES. Ale o tom zase příště. * * * pokračování příště * * strana 11