|
Doporučené Postupy při nalézání tříd v návrhu IS
autor: RNDr. Ilja Kraval, leden 2012
část 2.
Object Consulting s.r.o.
Server objektových technologií
Úvod
V první části tohoto článku bylo poukázáno na nutnost použití jednoho ze základních principů, kterým je náhled na IS pomocí vzoru dichotomie třída -instance“ (pozn.: o tomto vzoru viz například kniha Analytické modelování volně ke stažení zdarma). Podle tohoto vzoru je informační systém rozdělen na dva prostory: Na prostor tříd jako prostor předpisů neboli šablon, které definují vlastnosti prvků - instancí, a na straně druhé na prostor instancí, které na základě těchto předpisů vznikají v průběhu evidence. Důležité je si uvědomit, že pokud sledujeme systém již v činnosti (anebo si jej tak představujeme), potom vidíme projevy instancí, a proto je nalézání třídy jako předpisů pro tyto třídy obtížnější a nevyhneme se při hledání vzorců (zobecnění) metodě pokus omyl. Je však třeba upozornit, že zobecnění od instancí ke třídám metodou pokus omyl proběhne pouze v hlavě vývojáře a ve většině případů tomu se tomu tak stane velmi rychle řádově v sekundách.
V tomto článku se zmíníme o dalších následných doporučeních týkajících se vyhledávání tříd.
Jako první ze vztahů hledejte asociace
V modelovacím jazyce UML jsou v modelu tříd zavedeny dva typy interakcí, které se od sebe diametrálně liší (detailně viz zmíněná kniha):
1. Asociace 2. Generalizace
Vztah Asociace vyjadřuje v modelu tříd budoucí vztah mezi instancemi, tj. v jaké vztahu budou instance, až vzniknou, „jak budou evidované informace sešněrovány“. Oproti tomu vztah Generalizace vyjadřuje vztah přímo mezi předpisy (třídami) jako takovými, kdy jedna třída použije druhou třídu ještě před zrodem instance.
Protože při návrhu tříd si umíme nejprve představit instance ze tříd, tak je zřejmé, že jako první hledáme asociace, které se v prostoru instancí projeví jako vztahy mezi instancemi (např. faktura má řádky, klient má služby, osoba má adresu atd.). Nalézání vztahu Generalizace hledáme až poté specifickým postupem, protože se jedná o další abstrakci již v rámci vztahů mezi třídami resp. pojmy. Odhalení Generalizace je složitější proto, že musíme učinit dva kroky zobecnění po sobě: Nejprve zobecňujeme pohled na IS od instancí ke třídám a poté mezi těmito nalezenými třídami ještě hledáme zobecnění pojmů mezi sebou neboli Generalizaci.
Omezený výčet použitelných analytických vztahů u asociace
Pokud hledáme nějaké řešení úkolu,pak je vždy výhodou, máme-li k dispozici pouze omezený počet možných výsledků. Podobně je tomu také u analytických vztahů Asociace při návrhu IS v jazyce UML.
Jazyk UML zná sice pouze jeden vztah Asociace (tj. vztah mezi třídami jako vztah mezi budoucími instancemi), avšak pomocí označování vlastností konců asociace se vyjadřuje velmi přesně analytická povaha tohoto vztahu.
Poznámka: Někteří vývojáři se označování konců asociace a tedy nalezení analytické povahy vztahu asociace vyhýbají. Není to sice fatální chyba, ale připravují se tak o velmi dobrou možnost zjednodušit si práci při psaní scénářů. Pokud totiž nalezneme analytickou povahu vztahu Asociace, pak tato povaha má charakter vzorce, který musí dodržet všechny scénáře v případech užití, kde se pracuje s instancemi z daných tříd. Jinak řečeno, jestliže v jednom scénáři je popsán děj programu odpovídající jednomu analytickému významu (například Odkaz do seznamu), nemůže být v jiném scénáři, kde se pracuje s instancemi ze stejných tříd, zvolen scénář odpovídající jiné povaze vztahu (například Kompozice ku jedné). Tato skutečnost výrazně zjednodušuje psaní scénářů u již nalezených vztahů Asociace.
Díky tomu, že pro návrh IS lze použít pouze omezený výčet vztahů Asociace různé analytické povahy, můžeme si jeden po druhém odzkoušet a doslova vylučovat v seznamu vztahy nevhodné a tak najít ten správný. Rozborem evidence instancí a jejich vztahů tak jednodušeji nalézáme odpovídající vztahy mezi třídami typu Asociace.
Uvedený výčet je velmi podrobně popsán v uvedené knize analytického modelování a je detailně probrán na našich pobytových školeních nebo internetových školeních včetně cvičení a příkladů z praxe.
Zde si uveďme výčet a stručně význam:
1. Kompozice ku N (Faktura má řádky faktury) resp. Kompozice ku jedné (Osoba má adresu jako v eshopu) jedna instance obsahuje a má podřízeno N nebo jednu instanci jako svoje součástky. Podřízené instance mohou vznikat, žít a zanikat pouze ve „scope“ nadřízené instance jako její součástka.
2. Odkaz do seznamu (Auto má barvu) jedna instance používá druhou instanci, ale ta není jejím majetkem, jedná se o odkaz na instanci. Slangově se nazývá také číselníkovou vazbou.
3. Sdílená instance (GSM telefon má SIM kartu) výjimečný vztah, kdy jedna instance má sice v majitelství jednu nebo vícero instancí podobně jako v kompozici, ale je dovolen výjimečný scénář, který narušuje povahu kompozice (chování jako u kompozice, až na to že…)
4. Asociační třída (dvojná nebo vícenásobná) posláním a smyslem instancí pocházejících z asociační třídy je propojit do vztahu jiné instance. Klasickým příkladem může být evidence sňatků mezi mužem a ženou (každá instance sňatku obsahuje odkaz na muže a odkaz na ženu a další údaje, například datum sňatku apod.)
Pomocí tohoto jednoduchého výčtu se snažíme identifikovat vztahy mezi evidovanými instancemi.
Rekapitulace
Spolu se závěrem předešlého článku můžeme shrnout současné závěry pro postupy vyhledávání tříd takto:
1. Musíme si vytvořit (byť jen v duchu) představu několika příkladů instancí a jejich vztahů (tzv. linky v UML).
2. Metodou „pokus omyl“ se snažíme z těchto příkladů nalézt obecnější meta-vzorec v modelu tříd, který bude platný jak pro naše instance, tak i pro libovolné další instance v budoucnu se narodivší.
3. Mezi instancemi hledáme vztahy asociace a to pouze vyjmenované podle předešlého seznamu: a. kompozice ku N resp. kompozice ku 1 b. odkaz do seznamu c. sdílená agregace d. asociační třída
V dalším článku přidáme ještě doporučené postupy pro vyhledávání Generalizace.
Pokračování příště
|
|
|
|