Odpověď na dotaz ohledně asociační třídy v modelu Část 4. Tento článek navazuje na předešlé články jako jejich pokračování autor RNDr. Ilja Kraval, http://www.objects.cz září 2007 firma Object Consulting s.r.o.
Odpověď na dotaz ohledně asociační třídy v modelu 4.část Úvod V předešlých článcích se díky konzultacím dospělo již k určitým závěrům. Nyní se pokusíme provést jakési první shrnutí myšlenek a vytvoříme tedy o něco jako první nástřel modelu, který by se následně podrobil oponentuře a dále doplnil (resp. celý předělal ). Jinak řečeno pokusme se střípky poznatků z minulých článků shrnout do nějaké jediné konzistentní logické konstrukce, aby se dalo nad ní diskutovat. Možná řešení se šablonami - použití vzoru TEMPLATES - ŠABLONY Nejprve navrhněme varianty se šablonami. Před samotným m musí uživatel systému nejprve definovat šablony protokolů, které jsou povoleny. Následně se pro dané konkrétní zakládá protokol s příslušností k určité šabloně. Díky tomu nemusíme u se stejnými vlastnostmi (například elektroměrů) určovat parametry (např. veličiny a jednotky) znovu a znovu. Znamená to, že například pro skupinu elektroměrů se bude používat tatáž šablona. Existuje několik možných variant, jak využít šablony, například varianta s uspořádáním v sadě hodnot takto: strana 2
Odpověď na dotaz ohledně asociační třídy v modelu 4.část Šablona protokolu měrení {ordered}..* Šablona hodnot současných Sada hodnot současných {ordered} obrázek Použití šablony s uspořádáním prvků v sadě hodnot Princip použití šablony je zde logicky jednoduchý: Šablona definuje veličiny a jednotky (pozor záleží na pořadí, viz CONSTRAINT {ordered}!) a následně protokol používá tyto veličiny a jednotky (neboli šablony hodnot, viz diagram) v daném stejném pořadí. Dohoda je zde tedy v pořadí. Opět si to vysvětlíme na instancích: Konkrétní šablona XY (použitelná například pro elektroměry) má tyto veličiny a jednotky v tomto pořadí:. spotřeba činné energie, Wh, 2. jalová energie, Varh, 3. činný výkon, W a 4. jalový výkon, Var (viz mail z minulého článku). Při jsou v sadě hodnot současného (viz již protokol) zaznamenány hodnoty a ty jsou v pořadí v dané sadě současných odpovídajícím této šabloně, tj. první je činné energie, druhá je jalová energie atd. Předešlý obrázek není nic jiného, než model tříd pro takovýto postup evidence. Poznámka: Uvnitř prvku je atribut value, není znázorněno. Druhou variantou je, že nebude učiněna dohoda ohledně pořadí, ale každá naměřená si ukáže na svou šablonu hodnoty : strana 3
Odpověď na dotaz ohledně asociační třídy v modelu 4.část Šablona protokolu měrení..* Šablona hodnot současných Sada hodnot současných obrázek 2 a měrná je dána odkazem na šablonu hodnoty V tomto případě jsou vlastnosti naměřené hodnoty (s výjimkou samotné naměřené hodnoty neboli value a časové značky) dány odkazem do šablony hodnoty. Třetí možností je použití šablony tak, že prvky hodnoty převezmou ze šablony jako kopii příslušné odkazy na jednotku a veličinu, tedy samy si budou ukazovat na měrnou jednotku a veličinu, protože si tyto odkazy ze šablony zkopírovaly: strana 4
Odpověď na dotaz ohledně asociační třídy v modelu 4.část Šablona protokolu měrení..* Šablona hodnot současných generate from Sada hodnot současných obrázek 3 převezme ze šablony veličinu a měrnou jednotku a sama si na ně drží odkazy Varianta řešení bez šablon Existuje i možné řešení bez šablon. V tom případě by se přicházející hodnoty současného prostě zaznamenaly tak, jak přicházejí s tím, že v těchto přicházejících datech bude udáno co a v čem se měří vždy nějak s každou hodnotou (například měrné jednotky a veličiny kódem v měřených datech). V tomto řešení by to, co se měří a v čem, bylo budováno v samotném vyhledáním veličin a vyhledáním jednotek v číselnících přes přicházející kódy v datech (de facto ad hoc s každým m). Model by se sice zjednodušil takto (nejsou v něm šablony): strana 5
Odpověď na dotaz ohledně asociační třídy v modelu 4.část Sada hodnot současných obrázek 4 Řešení bez šablon ale asi tušíme problém. Hodnoty sice jednoduše udávají svými odkazy co a v čem se měří, ale tyto informace vznikají ad hoc bez kontroly vůči předpokládané šabloně. Navíc informace co vše se má měřit u elektroměrů typu XY není dáno jednou šablonou bokem, ale až naživo naměřenými mi v protokolech těchto elektroměrů. Varianta s šablonou jako kontrolním předpisem Nedostatek předešlé varianty (budování hodnot s veličinami a mi ad hoc bez šablon) spočívá v tom, že neexistuje kontrola co se má měřit a navíc, že nemáme jednu informaci co se má měřit, tj. máme k dispozici jen a pouze informaci co se již měřilo. Tento nedostatek bychom mohli odstranit zvláštní variantou použití šablony nikoliv pro generaci prvků, ale pro kontrolní mechanismy. Už to není šablona v pravém slova smyslu, je to spíše kontrolní předpis. Model bude velice podobný modelu se šablonou s kopírováním (viz obrázek 3), ale dynamika generace hodnot bude jiná. Hodnoty se budou generovat skutečně ad hoc jako v předešlé variantě bez ohledu na šablonu (žádné kopírování) a odkazy na veličinu a jednotku tedy budou v přicházejících datech a ad hoc vyhledávat. Příklad: přišlá data (kod=32, kod=25, 000,2) znamená například spotřebu činné energie (kod 32) ve Wh (kod 25) v hodnotě 000,2. Je jasné,že v datech se může omylem objevit kód neodpovídající danému. Proto následně (resp. kdykoliv) lze spustit kontrolní mechanismus vůči šabloně, tedy strana 6
Odpověď na dotaz ohledně asociační třídy v modelu 4.část přesněji vůči kontrolnímu předpisu a přiřazovat naměřené hodnoty k předpokládaným předpisům (původně šablonám). U některých se to nemusí podařit a to jsou divná nepodléhající předpisu a tedy šabloně. Závěrem - kterou variantu vybrat? Zatím jsme našli tyto varianty analytického návrhu: Použití šablony s uspořádanými prvky (dohoda pořadí šablon hodnot a samotných hodnot) Použití šablony s odkazem hodnoty na šablonu hodnoty Šablona s generováním prvků hodnot (převzetí odkazů) Generování hodnot bez šablon - ad hoc Generování hodnot bez šablon - ad hoc, ale následně verifikace vůči kontrolnímu předpisu Navíc se dá předpokládat, že můžeme najít další možná řešení! Mohlo by se zdát, že otázka nyní zní: Které řešení je to správné? Takto formulovaná otázka je tak trochu zavádějící. Správně by otázka měla znít: Které z těchto řešení je nejvýhodnější pro to, co potřebujeme? Dá se s trochou nadsázky říci, že právě v této otázce jsou skryty opravdu bezesné noci analytika. Každé řešení má totiž svoje pro a proti a z toho důvodu se musíme rozhodovat a vybírat z několika možných řešení. Co je přitom důležité - samozřejmě se rozhodujeme při znalosti všech podrobností detailů a záludností daného problému, což nyní nemáme a ani to není předmětem a smyslem tohoto článku. Chtěl jsem hlavně ukázat sílu jazyka UML pro vyjádření myšlenek, nad kterými se dá následně diskutovat. Modely v UML jsou srozumitelné, jasné, logicky vysvětlené, což neznamená, že jsou vždy nejvýhodnější pro řešení! V každém případě však je možné tyto návrhy velmi přísně oponovat a to ve velmi ve tvrdých diskusích, protože si všichni rozumí. Mimochodem, k tomuto postupu oponentur vždy rád směřuji cvičení ve školeních OOP a UML, která jsou tímto opravdu živá a někdy v diskusi i hodně temperamentní. Můžeme se totiž přít, které řešení bude kdy a pro co výhodnější, můžeme se dokonce i odborně hádat nad řešením, ale pokud nemáme dobrý srozumitelný a jasný logický společný jazyk, diskuse prostě končí, tedy přesněji řečeno, diskuse ani nenastane. Myslím, že v tom je hlavní síla použití jazyka UML při modelování IS. *** konec článku *** strana 7