Kiedy jest warto modelować w UML?

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.

Podobne wpisy
Modelowanie infrastruktury w języku UML – diagram wdrożenia w praktyce

Modele mają za zadanie pokazać rzeczywistość w sposób uproszczony, w którym uwypuklamy interesującą nasz cechę. Projektując nowe lub zmieniając istniejące więcej

NATO Architecture Framework

Technik i obszarów, które możemy modelować jest bardzo wiele. Ponadto powstało wiele szablonów, ram, frameworków, które mówią co i jak więcej

Modelio – open source

Modelowanie, poza metodykami i notacjami, które im towarzyszą, to także narzędzia. Wiele z nich to narzędzia płatne. Dla mnie narzędzia więcej

Dokumentacja przypadków użycia w administracji publicznej

Myślę, że czasem warto się pochwalić drobnymi osiągnięciami. W 2013 roku miałem okazję współpracować z Ministerstwem Sprawiedliwości. Brałem udział w więcej

Reklama
MODESTO - licencje Enterprise Architect

Zostaw komentarz

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *

Przewiń do góry