5. díl - UML - Class diagram

Návrhové vzory UML UML - Class diagram

V minulém UML tutoriálu jsme si vytvořili doménový model a tak jsme si vlastně ukázali základní notaci tříd v UML a také základní vztahy, které mezi sebou třídy mohou mít. Doménový model byl zjednodušenou verzí modelu třídního (Class diagramu). Dnes si ukážeme nějaké další vazby a vytvoříme si třídní diagram.

Class diagram

Diagram tříd je diagram implementace. To je rozdíl oproti doménovému modelu, který byl spíše náčrt systému. Class diagram je již naostro, musí být úplný, když ho programátor přepíše do kódu, kód musí fungovat. Budeme zde mít tedy všechny třídy, které program bude obsahovat. Třídy budou mít všechny atributy a také metody. Diagram je platformově závislý, tedy specifický pro určitý programovací jazyk. Mimo jiné to znamená, že se v identifikátorech již nevyskytuje diakritika, atributy mají datové typy specifické pro daný jazyk a podobně.

Význam diagramu

Class diagram je návod pro programátora, ten by již neměl s naším diagramem řešit žádné zásadní otázky ani problémy, jeho práce by měla být (možná bohužel :) ) rutinní. Návrh systému mají na starosti zkušení programátoři a analytici. Díky návrhu se potom samotné programování může předat i méně zkušeným programátorům, kteří jsou mnohdy levnější. Diagram tříd je dobré vytvořit však i v případě, že systém píšeme jen pro sebe, donutí nás to nejprve přemýšlet v kontextu celého systému a až potom programovat. Nestane se nám, že napíšeme půlku systému a potom zjistíme, že to takhle nebude fungovat. Složitější informační systémy již nelze vytvářet bez návrhu a i práce v týmu se bez kvalitního návrhu neobejde. Diagram nám do budoucnosti poslouží i jako dokumentace.

Ukažme si ještě jednou grafickou notaci třídy v UML, tentokrát již kompletní:

Třída v UML diagramu

V první části obdélníku je opět název třídy, tentokrát již bez diakritiky.

V druhé části jsou přítomny atributy s datovými typy. Před každým atributem je uveden modifikátor přístupu. Máme 4 možnosti:

  • - (mínus) - Privátní atribut (private).
  • + (plus) - Veřejný atribut (public).
  • # (hash kříž) - Protected atribut (protected).
  • ~ (tilda) - Atribut viditelný v rámci balíku (package).

Význam prvních 3 určitě známe z objektově orientovaného programování, package atribut je atribut viditelný v rámci celého balíčku tříd (tedy jmenného prostoru).

Mezi název atributu a datový typ píšeme dvojtečku.

Metody v posledním obdélníku jsou zapisovány podobně. Je možné specifikovat ještě několik symbolů, ale to se v praxi příliš nepoužívá a proto se tím nebudeme zabývat.

Vztahy

Oproti doménovému modelu zde můžeme použít ještě další 2 vztahy.

Realizace (Realization)

Vztah realizace je mezi interface a třídou, která tento interface implementuje. Třída reprezentující interace má tzv. stereotyp. Ten se píše mezi 2 a 2 špičaté závorky. Již jsme se s ním setkali u vazby <<include>> v Use Case diagramu. Stereotyp umožňuje změnit význam určitého prvku v diagramu, nyní měníme třídu na interface. Třída implementující interface je k interface připojena vazbou podobnou dědičnosti, pouze je čára vykreslena jako přerušovaná.

Realizace interface v UML diagramu

Asociační třída (Association class)

Asociační třída je třída, která zprostředkovává vztah mezi 2ma entitami. Výhodou je to, že může vztahu dodat nějaké atributy. Často se uvádí příklad tříd Osoba a Zajezd, kdy asociační třída Ucast přiřazuje osobu na zájezd a dodává čas příjezdu a odjezdu. Dalším přikladem je třeba Osoba a Hotel, kdy v hotelu není pevně stanovený čas ubytování a objednává si ho konkrétní osoba. Podobná třída by mohla ještě např. být mezi zaměstnancem a firmou, kde by definovala plat zaměstnance. Dalším využitím může být možnost takto vytvořit vazbu M:N, podobně, jako to funguje u databází. Asociační třída by tedy držela kolekci referencí. Použití asociační třídy může být poněkud zavádějící a pokud si nejste jistí, tak se ji raději vyhněte.

Asociační třída v UML diagramu

Příklad Class diagramu

Přejděme k příkladu a vytvořme si Class diagram devbooku. Budeme samozřejmě vycházet z předešlého doménového modelu.

Předem upozorňuji, že příklad je velmi zjednodušený, návrh není ideální a nectí MVC architekturu, jak je u webových aplikací zvykem.

Příklad class diagramu, diagramu tříd v UML

Vidíme, že oproti doménovému modelu zde máme úplně novou třídu System. Ta drží instance aktuálního článku a aktuálního uživatele. Dále drží kolekce článků, členů a sekcí. Doménový model pouze mapoval důležité entity z hlediska business zadání a tedy ani nepřemýšlel nad tím, jak systém bude fungovat. Počet tříd se tedy prakticky vždy s přechodem od doménového modelu k Class diagramu zvýší.

Instance systému se vytváří s každým HTTP požadavkem, jak nám říká poznámka ke třídě nalevo. Za povšimnutí stojí také výčtový typ StavClanku, který je zde zakreslen jako třída a výčtový typ je z něj vytvořen pomocí stereotypu <<enumerable>>. Zbytek jsme si již popsali, takže si diagram prohlédněte. Jako je to u všech diagramů, je to jeden možný způsob, jak systém navrhnout, možností je nespočetně a i těch správných je mnoho.

Příště se zaměříme na popis tříd a ukážeme si ještě komplexnější praktický příklad Class Diagramu.


 

  Aktivity (1)

Článek pro vás napsal David Čápka
Avatar
Autor pracuje jako softwarový architekt a pedagog na projektu ITnetwork.cz (a jeho zahraničních verzích). Velmi si váží svobody podnikání v naší zemi a věří, že když se člověk neštítí práce, tak dokáže úplně cokoli.
Unicorn College Autor se informační technologie naučil na Unicorn College - prestižní soukromé vysoké škole IT a ekonomie.

Jak se ti líbí článek?
Celkem (7 hlasů) :
4.714294.714294.714294.714294.71429


 


Miniatura
Předchozí článek
UML - Doménový model
Miniatura
Všechny články v sekci
UML
Miniatura
Následující článek
UML - State Machine diagram

 

 

Komentáře
Zobrazit starší komentáře (11)

Avatar
Juraj Mlich
Redaktor
Avatar
Juraj Mlich:

Ako zapíšem preťaženú metodu?

Odpovědět 1.7.2013 10:31
Vždy je lepšie učiť sa z cudzích chýb, než z vlastných chýb.
Avatar
Milan Gallas
Redaktor
Avatar
Milan Gallas:

Napsal jsi statiku nepoužívej, ale jak chceš zajistit například jedinečnou instanci nějaké třídy. Při práci v týmu budeš muset nějak zajistit, aby si každý programátor v týmu nemohl vytvořit instancí třídy (která zajišťuje připojení k databázi, nebo nějaké ladící nástroje)? Jednu jedinečnou instanci bez návrhového vzoru Singleton(který využívá principy statiky) neuděláš a pokud znáš způsob jak v tomhle případě statiku obejít, tak mi ho prosím zděl :)

 
Odpovědět 3.12.2013 19:05
Avatar
Drahomír Hanák
Tým ITnetwork
Avatar
Odpovídá na Milan Gallas
Drahomír Hanák:

O to, aby byla instance jedinečná, se mi stará DI kontejner

 
Odpovědět  +2 3.12.2013 20:10
Avatar
Milan Gallas
Redaktor
Avatar
Odpovídá na Drahomír Hanák
Milan Gallas:

i to má svůj problém.
pro konkrétní případ si dovolím půjčit tvojí továrnu, kterou máš popsanou v článku http://www.itnetwork.cz/…avrhovy-vzor

Ber v úvahu, že tvoji kolegové ve firmě nebudou vědět, že pro získání objektu můžou zvolit metodu getConnection(), ale vytvoří si novou instanci třídy Container a zavolají znovu metodu createConnecti­on(); Pokud již budeš mít takto vytvořený objekt a některý z tvých kolegů si vytvoří další instanci tak Vytvořené objekty nebudou stejné a bude docházet k plýtvání pamětí.

Kdybych použil Singleton tak použiji privátní konstruktor a přinutím je používat metody getConnection, ale ty je nijak nepřinutíš a oni si můžou vytvořit tolit instancí, kolik budou chtít.

 
Odpovědět 3.12.2013 23:12
Avatar
Milan Gallas
Redaktor
Avatar
Odpovídá na Drahomír Hanák
Milan Gallas:

a navíc třídu Container si může kdokoli naklonovat a to tvoje třída také vůbec neřeší:

$container = new Container('Localhost', 'test', 'aaabbb', 'myTable');
$db = $container->createConnection();
$db2 = clone $db;

Pokud mi tyhle 2 věci vyvrátíš, tak uznám svou chybu a uznám že jsem se spletl, ale zatím si myslím, že Ten kontejner má své nedostatky a že nedokáže zajistit na 100ˇ%, aby existovala pouze **1 **instance dané třídy.

 
Odpovědět 3.12.2013 23:21
Avatar
Drahomír Hanák
Tým ITnetwork
Avatar
Odpovídá na Milan Gallas
Drahomír Hanák:

Já mám v práci chytré kolegy, kteří znají ten návrhový vzor a ještě chytřejší DIC, který nikomu nedovolí tohle udělat (dokonce umí sám ty závislosti třídám předávat) ;) Paradoxně hlavní problém singletonu je nepřehlednost. Třída si někde magicky z globálního prostoru vezme instanci. Přitom má signaturu třeba class UserDao(); Kde z toho poznám, že potřebuje databázi? A když si podle názvu odvodím, že asi nějakou databázi potřebuje, odkud si ji vezme? A jak ji v testech budu mockovat? Z praxe vím, že Singleton ve větších aplikacích nenahradí DI. Dokonce jsem se setkal s případem, kdy firma měla v jedné aplikaci tohle řešení singletony. Jak na aplikaci dělalo stále víc lidí, muselo se to prostě přepsat.

Nechci to nikomu nutit, mluvím na základě svých zkušeností z pár firem a vlastních projektů. Určitě jsou tu zkušenější uživatelé, kteří ti poradí mnohem lépe.

Mimochodem, tomu zneužití co píšeš, se dá dost jednoduše zamezit.

Editováno 3.12.2013 23:29
 
Odpovědět  +1 3.12.2013 23:25
Avatar
Milan Gallas
Redaktor
Avatar
Odpovídá na Drahomír Hanák
Milan Gallas:

a jak si to teda v tom svém DIC vyřešil, Aby výše zmíněné věci nebyly možné a DIC to nikomu nedovolilo?
Mě jde o konkrétní postup zamezení těchto 2 "ohavností", které ti můžou tvoji kolegové způsobit.

 
Odpovědět 3.12.2013 23:31
Avatar
Drahomír Hanák
Tým ITnetwork
Avatar
Odpovídá na Milan Gallas
Drahomír Hanák:

K instanci DIC vůbec nemají přístup nebo jen velmi omezený.
V DIC si definuji službu buďto jako service (vytváření instancí je plně pod kontrolou kontejneru tj. createConnection je privátní) nebo jako factory (očekávám, že bude instancí víc, tady předávám tovární funkci) Klonování si např. v PHP ošetříš pomocí vlastní definice __clone().

O tom, že by uživatel vytvořil kontejner nemá cenu diskutovat. Třídy uvnitř systému nikdy nebudou vědět, že nějaký kontejner existuje. Kdyby ho někdo přece jen vytvořil ručně sám (což je velice nepravděpodobné), musel by do něj definovat všechny služby a továrny z celého systému znovu, aby mu to fungovalo.

Ty mi zase řekni, jak mám mockovat singleton v testech? Co když budu chtít přepínat mezi uložišti (databáze/cache)? Co když tam přidám v průběhu vývoje další možnosti? Abys udělal tohle, musel bych nejspíš narušit základní návrhové principy (jako třeba single responsibility, open-closed princip dokonce princip převrácaného předávání závislostí je základním principem). Nebo jak tedy jasně zjistit závislosti třídy? To, že je globální taky není moc ok. Nevýhody singletonu tedy alespoň pro mě jasně převyšují nevýhody DI (můžeme se dál bavit o tom, že si někdo ručně vytvoří tu službu nebo použije reflexi, ale nemá to cenu, protože to se v praxi nestane)

 
Odpovědět  +1 3.12.2013 23:56
Avatar
Drahomír Hanák
Tým ITnetwork
Avatar
Odpovídá na Milan Gallas
Drahomír Hanák:

Abych to ještě uvedl na pravou míru. To, o čem tu diskutujeme, není Dependency Injection, ale Dependency Injection Container (DIC). DI je v zásadě i toto: new UserDao(new Database('local­host')) i když takhle zapsané to není v praxi použitelné.

Ještě bych chtěl možná zmínit, že DI a singleton se navzájem nevylučují.

Editováno 4.12.2013 0:10
 
Odpovědět 4.12.2013 0:08
Avatar
Milan Gallas
Redaktor
Avatar
Odpovídá na Drahomír Hanák
Milan Gallas:

Tak uznávám, že po menší úpravě kódu by mohla být ochrana dostačující(nikoli 100%). Jednoduchá verze třídy by mohla vypadat třeba takto:
http://www.itnetwork.cz/dev-lighter/253

Editováno 4.12.2013 18:02
 
Odpovědět  -1 4.12.2013 18:02
Děláme co je v našich silách, aby byly zdejší diskuze co nejkvalitnější. Proto do nich také mohou přispívat pouze registrovaní členové. Pro zapojení do diskuze se přihlas. Pokud ještě nemáš účet, zaregistruj se, je to zdarma.

Zobrazeno 10 zpráv z 21. Zobrazit vše