Nazory na vyuziti UML (Unified Modelling Language) se znacne ruzni. Na jedne strane stoji tabor UML nadsencu, kteri kresli diagramky jak na bezicim pasu. Uplne na opacne strane jsou lide, povazujici UML za naprostou zbytecnost (vetsinou razici cestu CowBoyCoding). A nekde mezi nimi se vidim ja.
UML jako takove odsoudit nelze, je znacne jednoduche a k jeho pouzivani vam staci popisek na vnitrni strane desek UML Distilled od Fowlera. Vim to, protoze jsem UML dlouhou dobu skolil a mucit nekoho den nebo 2 je opravdu trochu drsne. Proto byva casto skoleni UML casto spojeno se zaklady Objektove Orientovane Analyzy a Designu, coz muze nektere lidi znudit.
Muj problem s UML je, ze jeho vyuziti vidim pro vsechno jineho nez pro fazi designu software, pro kteru byva vrele doporucovano. Jeste jsem nepotkal projekt, kde by skutecne necemu pomohlo. Spise zdrzuje, predpoklada roli architekta-poloboha, ktery je schopen pojmout a vyresit s predstihem vsechny nastrahy projektu. A to je presne proti metodikam jako XP (extreme programming) ci TDD (test driven development), ktere se ridi pravidlem, vsichni v projektu jsou stejny paka, zvracejme svuj kod, oni nas uz testy ohlidaj. No i kdyz je to samozrejme nadsazka (jak velka 🙂 ), tak mi taky prijde, ze malovani diagramku spise zdrzuje – designovat a prototypovat muzu uz v cilovem jazyku a riziko pramenici z opomenuti ci zaneseni zavazne chyby odhalim s vyuzitim mock objektu drive a tudiz levneji. Mam v zive pameti jeden opravdu velky projekt, kdy vetsinu casu potrebneho pro implementaci ci fixu dane feature zabrala uprava modelu, aby byl up-to-date. Potizi bylo, ze mi vlastni model stejne prilis nepomohl, zakladem pro me byl zdrojovy kod.
Abych nebyl jen negativni, UML je naopak skvele pro vymenu myslenek mezi developery, osobne se mi v minulosti osvedcily zejmena UC diagramy a pak dynamicke sekvencni diagramy, ukazujici kolaboraci mezi objekty.
UML muze byt dobre pro zjistovani stavu projektu pomoci reverse engineeringu pro ucely reportovani. I kdyz podpora toolu zatim dosti pokulhava a vetsinou pro vetsi projekty clovek zkonci na smetisti car a obdelniku.
Takze zaverem: ztracet zbytecne cas s malovanim diagramku je IMHO luxus, lepsi je se soustredit primo na to, za co ste placeni – dodani software.
Taky se priklanim k tomu, ze opravdu je lepsi kodovat a posleze pouzivat UML jako dobry dokumentacni nastroj pro partie projektu, ktere nejsou uplne zrejme nebo trivialni.
V zásade súhlasím, UML by nemalo byť “diagramy pre diagramy” (umenie pre umenie, heh :-), ale občas sa okrem toho hodí aj ako marketingový argument (a na umlátenie niektorých manažérov u zákazníka, ktorí si myslia, že rozumejú IT, keÄ naprogramovali tri makrá v Exceli a používajú PDA).
Jj, presne. Prezentace myslenek pripadne stavu projektu – na to je UML jako delane. Takovehle IT manazery jsem jeste nepotkal, vetsinou ten Excel zvladala jejich sekretarka a oni si tak max. cetli Zive.cz zhlediska novych trendu v server side programovani.
Ale docela dost jsi opomenul zákazníka. Designer a UML by mělo být prostředníkem mezi zákazníkem. Namalovat si s ním co chce a pak to předat kodérovi, který to také snadno převede do programu. Proto si myslím že to není ztráta času, protože to co zákazník podepíše (UML a jiné diagramy a specifikace) musí přijmout a nemůže se vykrucovat že si to představoval jinak. Z toho plyne otázka – Jak naprogramuješ kád bez diagramů když zákazník ani nevíš co chce?
A ještě jedna poznámka: placení přece nejsme za “dodání software” ale za uspokojení tíživých potřeb a problémů zákazníka 😉
Mas pravdu zakaznika jsem opomenul, protoze jsem se vice zameril na designovou cast. Je fakt ze UC diagramy jsou natolik jednoduchy, ze je pochopi i zakaznik a muzou zprehlednit vytvorene dokumenty. Podepisovani UC diagramu zavani projektem s fixni sazbou. To je proti XP, kdy se zakaznikovi vysvetli jak to chodi, kolik je hruby odhad + cena roli na projektu, tak vetsinou rad pristoupi na model, kdy bude mit pravidelne novou verzi s moznosti reakce na aktualni pozadavky. Mozna si priplati nebo naopak usetri.
“Jak naprogramujes kod bez diagramu kdyz zakaznik ani nevi co chce?” V tomhle ti ani diagramy nepomuzou. A kazdy zakaznik zacne menit pozadavky protoze neni buh. Resenim je postupna konvergence k uspokojivemu stavu via variabilni cena projektu popsana vyse.
Jo to je pravda, uz jsem taky zazil, ze byl zakaznik nakonec rad, kdyz rozjety projekt ukoncil. Ze by tiziva potreba sebemrskacstvi? 😉