Návrh aplikací v jazyce UML – diagram tříd

16. srpna 2005

•

Po delší prodlevě vychází další článek o návrhu aplikací s využitím jazyka UML. Místo zbytečných omluv za dlouhou a neplánovanou odmlku snad čtenáře potěší informace, že se napříště budu věnovat i konstrukcím jazyka UML nově přidaným ve verzi 2.0. Tématem tohoto článku je vysvětlení elementárních pojmů, jejichž znalost je nezbytná při návrhu diagramu tříd.

Nesnesitelná lehkost pojmu objekt

Slovo „objekt“ je v IT zprofanováno minimálně tak, jako pojmy „systém“ či „komponenta“. Všichni v IT hierarchii (zvláště projektoví a různí jiní IT manažeři) o nich pronášejí velkohubé věty a soudy u zákazníků i vývojářů a ti zvláště otrlí přispěchají i se svým šroubovaným a stylisticky polámaným perem, aby přidali nějaké moudro do novodobého informačního moru, jimiž jsou prostoduché rozjásané marketingové materiály firmy. Není nad to umět být vždy in. Nejsme tady ale proto, abychom vytvořili zajímavou sociologickou studii, v níž by byl osvětlen vznik patologického podhoubí komerčních firem a jeho vliv na zákazníky, ale kvůli významem opětovně naplněné definici pojmu „objekt“.

Z laického hlediska můžeme objektem rozumět libovolný předmět, jenž má většinou svůj korelát v realitě (například faktura nebo objednávka). Tak většinou chápe pojem objekt zákazník, se kterým vytváříte analýzu systému a který vám popisuje, jaké objekty jsou použity v jeho problémové doméně. Objektům z problémové domény budeme říkat business objekty.

Rychlá evoluce objektů

S business objekty je důvěrně obeznámen zákazník, ale pro vývoj informačních systémů s business objekty nevystačíme. Všechny business objekty jsou ve dvou základních fázích transformovány na takzvané softwarové objekty.

V první fázi dochází k přerodu business objektů na konceptuální objekty. Jak uvidíte dále, tento přerod se děje aplikací formálních objektových principů a pravidel, mezi něž patří generalizace, polymorfismus, agregace a asociace.

Všechny tyto i další prozatím tajemné pojmy budou postupně vysvětleny, zde jen naznačím, že například jeden business objekt (zde předbíháme, ale řekněme raději třída) Faktura může být modelován dvěma konceptuálními objekty (třídami), z nichž jeden vyjadřuje fakturu, která přišla od běžného dodavatele, a druhý fakturu od VIP dodavatele, protože se jejich chování a stavy výrazně liší. Zajímavá fáze, ve které případy užití a slovníkem pojmů podložený soulad mezi chápáním pojmů u zadavatele a realizátora informačního systému doznává prvních trhlin.

Přechody mezi business objekty a konceptuálními objekty musíte mít výborně zmapovány, neboť jako již tradičně je i tato fáze rozhoupaným Damoklovým mečem a při jejím podcenění se vám po nasazení aplikace rozbliká obligátní rudá řídící kontrolka NEÚSPĚŠNÝ PROJEKT.

Samotné konceptuální objekty jsou postupným upřesňováním v druhé fázi transformovány na softwarové objekty. Softwarový objekt je plně připraven na implementaci v cílovém vývojovém prostředí a využívá všech unikátních vlastností zvolené platformy (například delegáty, události, meta atributy v prostředí .Net, meta tags v J2EE a podobně).

Kacířská poznámka: Jestliže je firma orientována jen na jednu technologii a platformu (J2EE), fáze modelování konceptuálních a softwarových objektů (tříd) se většinou neoddělují a diagram konceptuálních objektů (tříd) jako samostatný diagram nevzniká. Pokračujme v prohřešcích proti pravověrnosti – když nemáte dostatek času na vytváření diagramu business objektů (tříd) nebo nechcete investovat prostředky na bezcílné grafické kreace intelektuálně retardovaného business analytika, které nepřinášejí projektu žádnou přidanou hodnotu a slouží jen pro formální odškrtnutí úkolu v projektovém plánu, je možné ihned přikročit k modelování softwarových objektů (tříd).

Hlavní charakteristiky softwarových objektů

Softwarový objekt představuje jednotku, v níž je zapouzdřeno chování a stav. Co to přesně znamená?

Stav objektu

Objekt Faktura může mít atributy datum vytvoření, datum zaplacení, částka, poznámka. Příklady hodnot atributů jednoho objektu faktura v určitém čase:

Datum vytvoření = 10.6.2005
Datum zaplacení = 30.6.2005
Částka = 2000 Kč
Poznámka = Větší částce se nebráníme

Pro jednoduchost budeme nyní stavem objektu rozumět momentální kombinaci hodnot všech jeho atributů.

Chování objektu

Kromě stavu je objekt určen svým chováním. Tím nemám na mysli jeho dobré nebo špatné chování vůči svému okolí, ale hodnotově neutrální nabídku činností, jež lze s objektem provádět. Objekt Faktura může být například stornován (má operaci-metodu Storno) a může vyvolávat událost informující o změně jeho stavu – například událost informující o zaplacení faktury.

Kacířská poznámka pro rejpaly: Autor si je samozřejmě vědom rozdílů mezi operací a metodou. I když je operace používána hlavně ve fázi modelování business objektů (tříd) a může být v dalších fázích rozpadnuta do více implementačních metod s různou signaturou, nemyslím si, že pro čtenáře je takovéto jemné významové rozlišování něčím přínosné.

Zapouzdření

Řekli jsme, že objekt chování a stav zapouzdřuje. Co je míněno zapouzdřením? Zapouzdření, neboli enkapsulace, je jedním z nejdůležitějších principů OOP, který dbá na to, aby dobře navržený objekt nehrál v systému roli potulného exhibicionisty v parku, vystavujícího své privátní nádobíčko všem na odiv. Stav, změny stavu objektu i jeho chování jsou přístupné jen pomocí veřejného rozhraní. Objekt Faktura sám určuje, kdy je možné měnit atribut Datum vytvoření (dle zadání projektu například jen při vytváření nového objektu) i skrývá algoritmus pro kalkulaci výsledné částky na faktuře. Princip zapouzdření, se kterým se zde ještě několikrát setkáme, omezuje chyby v programu vzniklé náhodným a business pravidla porušujícím přepsáním nějaké proměnné (atributu) a ukrývá způsob implementace dané metody. Okolí objektu (tedy jiné objekty) jen používá nabízené služby a není dotčeno případnou změnou implementace metody.

Malá analogie na enkapsulaci ze života: Na oběd chodíte do své oblíbené restaurace, kde výborně vaří. Objektem je tedy restaurace, která vám nabízí službu (metodu) uvařit jídlo. To, že jídlo vaří nějaký usoplený kuchtík u plotny, je implementační podrobnost restaurace, o níž nemusíte a většinou ani nechcete mít žádné tušení. Jestliže restaurace vymění kuchaře, vy nejste touto změnou nijak dotčeni a ani se o ní nedozvíte. Pro můj žaludek je zajímavé jen to, že zůstal stejný objekt se stejnou službou. Analogie poněkud násilně a bohužel i naivně předpokládá, že kvalita kulinářského umění všech kuchařů v reálném světě je na stejné úrovni, ale pro přiblížení principu zapouzdření snad tento příklad postačí.

Identita

Objekty mají ještě jednu význačnou vlastnost – identitu. Identita objektu znamená, že každý žijící objekt v systému je unikátní nezaměnitelnou jednotkou. Identita objektu je v cílovém prostředí zaručena například jedinečnou adresou v paměti.

Objekty jako instance tříd

V UML je objekt také definován jako diskrétní entita – instance třídy. Kupodivu jsme zatím o třídě skoro nemluvili, i když se v tomto článku máme zabývat diagramem tříd. Již v prvních článcích o UML jsme zmiňovali rozlišování klasifikátoru a instance v UML a právě nyní jsme narazili na první exemplární případ tohoto rozlišení. Objekt je instancí třídy, ale co je třída samotná? Specifikace UML o třídě říká: Třída popisuje množinu objektů, které sdílejí identickou sadu vlastností, omezení a mají stejnou sémantiku.

Upřesněme si vztah mezi objektem a jeho třídou. Třídu si můžeme představit jako šablonu pro vznik objektů, které mají stejné atributy, metody a vztahy. V jiném smyslu můžeme také o třídě hovořit jako o množině objektů, které z ní vznikají. Třídou je tedy například faktura, objektem je konkrétní faktura, která má vyplněn datum vytvoření, částku a další náležitosti.

V nejpoužívanějších jazycích (C#, Java, C++) je třída základní syntaktickou konstrukcí pro vyjádření principů objektového programování, v jiných (Smaltalk) jsou i třídy objekty, což má sice svůj nezaměnitelný půvab, ale my se při implementaci budeme držet jen tříd prvního typu.

Kacířská poznámka pro pokročilé rejpaly: Autor ví, že správně by se v jazycích C#, C++ a JAVA mělo mluvit místo o třídách o abstraktním datovém typu. Pro jednoduchost jsem si ale opět dovolil tyto jemné významové nuance vypustit.