Od pewnego czasu widoczna jest dyskusja dotycząca wartości modelowania. Zwolennicy podejścia zwinnego niezbyt chętnie widzą modele. Konserwatyści preferujący klasyczne podejście do procesu wytwórczego oprogramowania chętniej modelują.
Modelowanie kosztuje. Narzędzia zazwyczaj niewiele, natomiast ludzie (analitycy, projektanci, architekci) już sporo. Nie da się ukryć, że korzystanie z UML wydłuża proces budowy oprogramowania. Czy to czas stracony? Przy nadmiarowym modelowaniu zapewne tak. Przy rozsądnym dobraniu technik i odpowiedniej metodyce pracy zespołu wytwórczego uzyskujemy zysk w trakcie rozwoju systemu, jego rozbudowy i bieżących zmian.
Jestem zwolennikiem ostrożnego dobierania modeli. W moim odczuciu ich nadmiar powoduje spore obciążenie zespołu. Nie mniej jednak budowanie modeli ma ogromną wartość. Dokumentacja projektu przypomina trochę projekt domu. Budynku większego niż garaż raczej nie buduje się bez projektu. (Pomijam fakt, że budując dom wymagana jest dokumentacja projektowa a do budowy systemu informatycznego, wielokrotnie droższego od niejednego domu, to sprawa opcjonalna.)
Dokumentacja opisująca działanie systemu, architekturę oraz dane to moim zdaniem takie minimum. Dokumentacja w UML pozwala na świadome i mniej ryzykowną rozbudowę systemu.
Budowa modeli:
- pozwala na odkrycie nowych wymagań
- zwiększa efektywność opisu systemu
- pomaga nadać odpowiednie priorytety wymaganiom
Innymi słowy niezależnie od tego czy budujemy nowy system czy też rozbudowujemy stary, mając model jesteśmy w stanie lepiej zarządzać wymaganiami a tym samym całym przedsięwzięciem, gdyż unikamy większej ilości przypadkowych czynności, które mogłyby doprowadzić do porażki.
Z drugiej strony, przy małej zmianie w systemie, rysowanie wielkich diagramów jest mało sensowne. Odnotowanie zmiany na już istniejących modelach UML to dobra droga.
Kiedy wiec warto jest modelować w UML?
Moim zdaniem modele w UML powinny powstać:
- dla dużych systemów (dla mniejszych też, ale tutaj czasem agile wystarczy)
- dla systemów, które przetwarzają dane osobowe, wrażliwe lub wspomagają ratowanie życia (niezależnie od wielkości)
- gdy chcemy zapanować nad złożonością systemu
- gdy chcemy opisać jak systemy informatyczne wspierają poszczególne kroki procesów biznesowych
- gdy planujemy integrację systemów (szczególnie nacisk należy położyć na modele opisujące architekturę i przetwarzane, w integrowanych systemach dane)
- gdy chcemy precyzyjnie opisać problem (wymagania), rozwiązanie (projekt) oraz kontekst (architektura) działania systemu.
I na koniec. Gdy planujemy budowę domu, kompletujemy dokumenty w tym jego projekt. W trakcie budowy domu bazujemy na jego projekcie. Oczywiście są pewne zmiany (przestawiamy ścianki, zmieniamy wysokość okna itd. itp.), ale nikt nie burzy wszystkiego i nie zaczyna od nowa. Przy implementacji aplikacji bez dokumentacji, często bywa tak, że albo oddajemy źle napisany komponent (o ile w miarę działa), albo piszemy od nowa (by w miarę działał). Budowanie modeli w UML, zwiększa prawdopodobieństwo, że zminimalizujemy straty czasu związane z poprawianiem (lub pisaniem od nowa) źle funkcjonujących komponentów.
