Witaj na Zine.net online Zaloguj się | Rejestracja | Pomoc

UMLowy profesjonalizm

Niedawno zostałam poproszona o przeszkolenie zespołu programistów w temacie notacji UML.
Niestety przed szkoleniem nie byłam w stanie zdobyć wielu informacji dotyczących oczekiwań poza generalnym stwierdzeniem, iż stan wiedzy słuchaczy na temat UMLa jest zróżnicowany - niektórzy nie wiedzą kiedy stosować jakie diagramy, inni nie znają nawet podstaw notacji. Wiedzę należało usystematyzować tak, by po szkoleniu można było wdrażać UMLa do codziennej pracy zespołu.

Postanowiłam więc bazować na swojej prezentacji dotyczącej podejścia MDD. Jest to szkolenie zawierające w swojej treści opis faz modelowania, właśnie z użyciem języka UML. Opiera się na case study ukazującym, od opisu środowiska, przez model wymagań, architektury aż do kodu, jakie diagramy UMLowe należy kiedy stosować.
W wersji rozszerzonej skupiłam się dodatkowo na wszelakich elementach języka występujących w przestawianych diagramach - wszystko po to, by jak najdokładniej przekazać wiedzę o notacji.

Nie wiem jakie były końcowe postanowienia jeśli chodzi o zastosowanie UMLa w pracy zespołu, byłam natomiast świadkiem dyskusji poszkoleniowej i pierwsze wnioski jakie wyciągnięto nieco mnie zaskoczyły.

Okazało się, że od tej pory zespól posiada wiedzę pozwalającą na dokumentowanie tworzonego przez niego produktu. OUMLowane miało być teraz wszystko - od projektowanych funkcjonalności, poprzez istniejący kod, po instrukcje użycia produktu czy też zewnętrzne API. Co więcej, przez użycie tej konkretnej notacji praca zespołu miała się jawić jako bardziej profesjonalna, odtąd wszystko zyskać miało lepszą jakość. Zaznaczam dodatkowo, że nie chodziło o nowe podejście do produkcji dokumentacji projektowej (która do tej pory jawiła się bardziej mgliście niż statki kosmiczne w powieściach s-f), nie chodziło również o lepsze podejście do projektowania. Mówiono o rozwiązaniu wszelakich problemów komunikacyjnych i PRowych przez modelowanie wszystkiego za pomocą UMLa.

Czułam się tak, jakby nic co chciałam przekazać w szkoleniu nie zostało usłyszane, chociaż zawsze zaczynając jakąkolwiek dyskusję na temat notacji podkreślam jasno i wyraźnie kilka spraw:
- UML to jedynie język, służący temu by wszystkie osoby rozmawiające o projekcie posługiwały się tymi samymi pojęciami.
- Jakakolwiek notacja (niekoniecznie UML) jest sposobem komunikacji dotyczącym jedynie tych elementów systemu które są sporne, skomplikowane (np. często lepiej jest zastosować diagram czynności niż beletrystycznie opisywać skomplikowany algorytm) lub dotyczą wysokopoziomowej architektury systemu (w tym wypadku głownie ze względu na fakt iż takich diagramów jest niewiele, a błąd architektoniczny wiele kosztuje).
- Diagramy UML nie są wystarczające same w sobie, wymagają innych form dokumentacji i komentarzy. Jest w nich wiele miejsca na beletrystykę, nieścisłości i nie można dzięki nim pozbyć się tekstu (choćby prostego słownika pojęć).
- Diagramy służą do modelowania najczęściej w fazie projektowania. Istniejące funkcjonalności najlepiej dokumentuje kod, a jeśli tak nie jest należy zastanowić się nad refaktoryzacją, a nie nad dopieszczaniem opisu. UML niewiele tu pomoże.
- Nie należy nadużywać UMLa opisując wszystko za jego pomocą. Często lepiej nadaje się do tego język naturalny lub wiele mówiący obrazek (w szkoleniu podkreślone są obszary, które uważam za godne użycia UMLa), nie należy opisywać każdego algorytmu, każdego procesu, każdej linii kodu. W końcu UML opisuje jak działa oprogramowanie lub jakie funkcje ma spełniać, służy do komunikacji między biznesem a technologią. W instrukcjach użytkownika lepiej spisują się print screeny.
- UML nie pomoże w poprawie jakości zarówno jeśli chodzi o opis procesów biznesowych, projektu czy też kodu. Pozwoli jedynie na opisanie tego co wymyśliliśmy, lub to co w danym momencie istnieje (Co się stanie gdy zinformatyzujemy burdel? Będziemy mieć zinformatyzowany burdel.). Jeśli rozważane procesy są błędne, to właśnie takie zostaną zapisane, jeśli wymyślimy zły projekt - UML (jak papier) wszystko przyjmie. Trzeba jednak przyznać że błędy te mogą zostać zauważone dzięki diagramom prędzej niż w wielostronnicowej dokumentacji.

Tworzenie diagramów UML produkuje dokumentację, dlatego tak jak języka naturalnego należy go oszczędzać i mieć jasny pogląd na to co powinno się w niej znaleźć a co nie. Do tego potrzebna jest spójna strategia tworzenia dokumentacji, zarówno funkcjonalnej, projektowej jak i integracyjnej, czy też dokumentacji użytkownika. Cel nauki UMLa przez jego użycie w codziennej pracy nie jest sam w sobie celem złym, ale wraz z nauką notacji musi iść myśl związana z właściwym jej użyciem.

Odkąd pamiętam UML był kwestią dość śliską. Koledzy po fachu często nie chcieli go stosować, bo podobnie jak każda inna forma dokumentacji wydawał się wymagać wielkich nakładów czasowych. Kiedyś takie argumenty nie wydawały mi się poważne. Nie mogłam nie doceniać wartości "porządnego" projektu. Byłam pełna ideałów i nie docierały do mnie tak przyziemne kwestie jak terminy, zmiany i ich tempo. Potem nadeszły czasy agile'a (a teraz lean'a), i chyba najczęściej wysuwany wniosek będący parafrazą jednego z postulatów manifestu, że... nie należy pisać dokumentacji skoro jest kod :) (zaraz potem w statystykach rządzi brak projektu). Oczywiście wszyscy dzisiaj wiemy, że nie o to do końca w agile'u chodzi.

Skąd więc ostatnio ta fascynacja UMLem? Skąd wniosek, że zapewni on wyższą jakość projektu, bardziej profesjonalne podejście? No i co z tym up-frontowym projektowaniem? Czy to nie czysty waterfall? A może udawanie waterfalla przez zapisanie w diagramach czy dokumentach tego co zrobiliśmy, a czego zapomnieliśmy zapisać w pierwszej fazie? No i po co w ogóle udawać waterfalla?

Największy problem z dokumentacją to zgodność z rzeczywistością i duplikacja informacji. Właśnie stąd wynika niechęć programistów do opisywania swoich poczynań - po co 2 razy robić to samo, raz w kodzie drugi raz w na papierze? A co jeśli kod się zmieni, które działania należy uzupełniać również w tekście, jakie panują tu procedury? Dzisiejsze czasy przynoszą nam konkluzje będące kompromisem. Myślę, że wielu z nas odetchnęło z ulgą na wniosek Erica Evansa by kod był postrzegany jako dokumentacja projektowa. Ale... do tego potrzebny jest wysokiej jakości kod :) Radzę więc skupić się właśnie na tym a nie na pisaniu memoriałów, czy rysowaniu pięknych diagramów. Dokumentujmy to czego nie da się wyciągnąć z kodu to co w 2 zdaniach, obrazkach czy diagramach rozjaśni sytuację, a co wymagać będzie duuużo mniejszych nakładów niż refaktoring.

Opublikowane 23 listopada 2009 10:12 przez fusion

Komentarze:

23 listopada 2009 12:19 by dotnetomaniak.pl

# UMLowy profesjonalizm

Dziękujemy za publikację - Trackback z dotnetomaniak.pl

Komentarze anonimowe wyłączone