Modelowanie aplikacji - czy aby na pewno to zło konieczne?

Ostatnio spotkałem się z twierdzeniem,że tworzenie i utrzymywanie modelu aplikacji jest niepotrzebnym zbytkiem i zwykłą stratą czasu.
Ze względu na fakt, że zagadnienia dotyczące samego modelowania, oraz późniejszego przetwarzania modelu jest mi bardzo bliskie, doszedłem do wniosku że odniesienie się do tej tezy będzie dobrą okazją do odświeżenia swojego bloga.

Nie ulega wątpliwości że przygotowanie kompleksowego projektu wymaga dużego wysiłku, który przekłada się na realny koszt. Czy warto podejmować ten wysiłek i inwestować w niego cenny czas? Zapewne to zależy i to od wielu czynników. W moim odczuciu jest to wręcz konieczność - szczególnie w przypadku dużych projektów, w których realizację zaangażowana jest duża liczba osób. Bez solidnego modelu nie sposób koordynować prac i dbać o "spójność wizji". Jednym tchem mógłbym wymienić jeszcze wiele innych, bezdyskusyjnych zalet wynikających z posiadania modelu aplikacji, ale mimo tego przygotowywanie diagramów umlowych często traktowane jest jako zło konieczne i męczący obowiązek, dlaczego ?

Myślę że składa się na to wiele czynników z których najważniejsze to:

1. Niewłaściwy cel i przeznaczenie modelu - jeśli jedyną motywacją skłaniającą do tworzenia modelu jest przygotowanie wkładu do dokumentacji projektowej to nasz wysiłek nie ma szans się zwrócić. Taki model bardzo szybko straci aktualność. Zespół deweloperski nie będzie posiadał odpowiedniej motywacji do stałego utrzymania spójności pomiędzy diagramami i kodem. Dobry model żyje i zmienia się wraz z aplikacją. Iteracje i przejścia pomiędzy modelem i kodem muszą być wpisane w realizowany cykl wytwórczy, a sam model musi stanowić dla programistów źródło pierwotnej wiedzy o rozwijanej aplikacji.

2. Niewłaściwe narzędzia - ich mnogość potrafi zakręcić w głowie, ale dokonanie niewłaściwego wyboru może skutecznie zniechęcić do tworzenia modelu. Przy wyborze narzędzia ważne jest nie tylko to, jakie diagramy można tworzyć przy jego pomocy ale również to, jak wspiera pracę grupową, oraz czy pozwala na łatwe i bezbłędne przekształcanie modelu w kod aplikacji(i z powrotem). Aspekt łatwego przechodzenia pomiędzy kodem i modelem ma decydujący wpływ na utrzymanie aktulności modelu - a przecież tylko taki model stanowi rzeczywistą wartość.

Jeśli chodzi o wybór narzędzia do modelowania to warto zwrócić uwagę na możliwości jakie dostarcza nam ono w zakresie przekształcania modelu, walidacji i kontroli jego spójności oraz automatyzacji wykonywania różnego rodzaju generat.

Przykładem narzędzia, na które w moim przekonaniu warto zwrócić uwagę, jest Enterprise Architect - komercyjny produkt firmy Sparx Systems. Do celów testowych można skorzystać z darmowego 30 dniowego triala. Niestety nie jest to dużo ale wystarczy by solidnie się pobawić.
Nie chcę tu rozwodzić się na temat tego, co to narzędzie ma, a czego mu brakuje. Chciałbym się natomiast skupić na czymś, co według mnie wyraźnie go wyróżnia.

Mianowicie Sparx Systems, wraz ze swoim narzędziem dostarcza API pozwalające na swobodną manipulację obiektami rozwijanego modelu. Daje to niesamowite możliwości, które właściwie wykorzystane pozwalają na znaczne zwiększenie potencjału narzędzia. Dzięki dostarczanym bibliotekom otrzymujemy pełną obiektową reprezentację naszego modelu. Biblioteki pozwalają nam na przetwarzanie istniejących oraz tworzenie zupełnie nowych elementów. Otrzymujemy możliwość programowego wykonania większości funkcjonalności dostępnej przez GUI EA. Daje to dużą swobodę w zakresie twórczego wykorzystania modelu aplikacji.

Możliwość programowego dostępu do modelu jest to luksus, którego na próżno szukam w świecie Open Source. Duże nadzieję pokładam w Eclipsowym frameworku Eclipse EMF, oaraz porojektach Papyrus i MOSKitt. Niestety nie udało mi się jeszcze przeprowadzić ich rozpoznania.

Mam nadzieję że wkrótce uda mi się przygotować materiał do pokazania praktycznego zastosowania programowego dostępu do repozytorium obiektów modelu, a wtedy na pewno o tym napiszę.