UML je užitečný nástroj pro vývoj SW. Jen je potřeba znát jeho omezení, je potřeba vědět, kdy a k čemu se hodí a jak ho používat. Bohužel většina materiálů o UML se zabývá syntaxí tohoto grafického jazyka, ale málokdy je ukázáno použití na reálné, například webové aplikaci. Sepsal jsem tedy pár praktických poznámek na téma UML.

Míra podrobnosti

Snad největším bariérou při kreslení UML je to, že s vyjímkou školních úloh (a úloh v knihách o UML) je problém složitý a obsáhlý (kdyby takový nebyl, tak nebudeme používat UML, že…). A o to jde: po počátečním nadšení nad „kreslítkem“ zanedlouho zjistíte, že nadpoloviční většina problématiky zůstává stále nepodchycená. S přibližujícím se termínem hotové analýzy pak začnete pronášet něco takového jako „ve Wordu už bych to měl dávno“. Přesně v ten okamžik víte, že jste nezvládli míru detailu.

Problém není v UML. Při psaní textové analýzy každý intuitivně tuší, že text je nepřesný a abstrahující, naopak UML má prostředky, kdy je možné zajít až do implementačních detailů, které jsou zpravidla v zadání nedůležité.

Duplicitní textové zadání

Výhodou i nevýhodou UML je to, že jde o grafický nástroj. Grafické vyjádření má tu výhodu, že je názorné a přehledné. Nevýhodou je to, že každá grafická značka je jen symbolem, něčím, co je v případě UML zástupné, kontextově závislé a často nepřesné. Výsledek je ten, že i ke čtení UML diagramu je potřeba určitá zkušenost a často i dovysvětlení od tvůrce.

Tím se dostávám k tomu, na co je vlastně UML dobré použít. Teoreticky (podle metodiky vodopádového vývoje) by UML analýza měla sloužit k porozumění mezi zákazníkem a programátorem. Bohužel fungovalo by to jen v případě, kdy zákazník má vzdělání či zkušenost v oboru SW vývoje, což se nestává tak často. Takže výsledek je ten, pokud opravdu chcete, aby vám zákazník porozuměl, vytvořte dvojí zadání – textové pro zákazníka a UML pro programátory.

Pravidlo 80:20

Jedno z pravidel SW vývoje říká, že na 80% funkcionalit potřebujeme 20% času a na zbylých 20% funkcionalit potřebujeme zbylých 80% času. Neberu toto pravidlo doslova, ale o principech SW vývoje říká hodně – některé zákaznické požadavky (a spoustu funkcí, na které se neodvážil zákazník ani pomyslet) je snadné implemetovat. Některé jiné zákaznické požadavky jsou naopak velmi pracné, snad až nesplnitelné.

Ale zpět k analýzám. Je v zájmu imlementátorů těch „nepříjemných 20%“ omezit. Jenže pokud již jednou dostal podrobnou analýzu do ruky zákazník ke schválení, budute s ním jen těžko vyjednávat o tom, že nějakou funkci nepotřebuje…

Analýza vs. návrh

UML pokrývá téměř celý vývojový cyklus – od soupisu zákaznických požadavků až k deploymentu. Pokud ale necháme analytika kreslit vše, máme problém – analytik (zpravidla) není programátorem, takže když ho necháme navrhovat diagram tříd či nějaké API, nemusí to dopadnout dobře. Úkolem analytika by mělo být porozumět zákazníkovi a ne předepisovat práci vývojáři. Proto je dobré odlišovat dvě role – roli analytika (definuje, co zákazník chce = analýza) a roli architekta (určuje, jak to realizovat = návrh). (Tyto dvě role by měly být obsazeny dvěma odlišnými lidmi.)

Zadání vs. dokumentace

Častým problémem SW projektů je nedostatečná dokumentace. Řešení se nabízí – proč nepoužít UML diagramy, podle kterých SW vznikal? Je to možné, ale vyžaduje to důkladnou revizi. Vývoj SW je činnost „dobrodružná“, nelze ji direktivně řídit podle detailního plánu – proto se často implementace odchýlí od původního zadání. Proto i UML dokumentace k již hotovému SW může vzniknout jen po revizi UML zadání.

Model Driven Development

Model driven architecture je přístup k vývoji SW, kdy kreslíte UML a z něj pak necháte vygenerovat kód v nějakém programovacím jazyce. Možná, že některý ze čtenářů bude mít lepší zkušenosti, ale mé jsou velmi špatné – UML modelář, který jsou zkušel, neuměl vygenerovat rozumný javový kód (rozumný = čitelný a přeložitelný).

Použití MDA vidím jen velmi omezené. Jednou z možností je vytvoření prvotního prototypu, ale stojí ta námaha s dotažením vygenerovaných kódů vůbec za to? Možná, že budoucnost bude lepší – až budou existovat UML nástroje, které budou obousměrné. Pak bude možné udržovat UML v konzistentním stavu s kódem – vidím to ale skepticky, neboť automatická analýza kódu, to je spíš úloha pro umělou inteligenci. Možná by pomohly programátorem do kódu doplněné metainformace, například ve formě anotací…

Závěr

UML je užitečný nástroj, který na začátku vypadá jako snadný a jednoduchý, ale jeho zavedení a smysluplné používání vyžaduje spoustu přemýšlení… Jak používáte UML u vás?