Ostatnie kilka wpisów:
dotyczyło metod integracji kodu z jej modelem. Przedstawiłem to zagadnienie w różnych wariantach z pluginem (MDG Integration for Eclipse) i bez. Teraz czas na podsumowanie i pytanie czy jest sens synchronizować model z jego implementacją w trakcie kodowania. Moim skromnym zdaniem NIE. Dlaczego?
Jestem zwolennikiem takiego podziału pracy, ze analityk wyznacza ramy aplikacji (klasy, tabele w bazie danych) oraz specyfikuje w opisach ich zawartość a programista wypełnia je kodem tak dobrym jaki potrafi tylko napisać. Nie chcę wchodzić w jego buty więc w trakcie implementacji posiadanie modelu implementacji, który ciągle się zmienia (poprawki, nowa funkcjonalność i inne) nie ma dla mnie sensu. Szczegółowa specyfikacja atrybutów i metod na poziomie analizy też mija się z celem, bo ja nie znam najnowszych nowinek technologicznych ze ?świata kodu źródłowego? na tyle na ile znają je programiści. Tak więc moja dokładna specyfikacja i tak może ulec ?zamianie? na rozwiązanie, które zaproponuje programista lub bez niczyjej zgody zaimplementuje. Dla mnie ważniejsze jest to by programista nie zmieniał klas, nie dodawał nowych bez konsultacji i najważniejsze by opisywał kod źródłowy aplikacji na poziomie klas, metod i atrybutów. Dzięki temu łatwiej mu będzie się odnaleźć w kodzie a wykonany na koniec model implementacji będzie pełny gdyż będzie zawierał kompletną specyfikację projektu ? klasy, atrybuty i metody z ich zawartością.
Podsumowując: Warto stosować forward engineering gdy zaczynamy kodowanie a reverse engineering gdy projekt jest już gotowy. Kluczem jest opisany przez programistę kod źródłowy, z którego można zbudować za pomocą mechanizmów inżynierii wstecz kompletną specyfikację kodu źródłowego wyrażoną w języku UML.
Według mnie analityk powinien zatrzymać się na projekcie modelu logicznego danych i projekcie interfejsów pomiędzy programami + oczywiście zestaw wymagań funkcjonalnych i niefunkcjonalnych połączonych z powyższymi.
Taki wsad otrzymuje architekt rozwiązania, który projektuje bazę dancych i szkielet klas.
To z kolei dostaje programista i wypełnia klasy ciałem.
Zamiast sztywnego opisu każdej metody sugerowałbym napisanie wewnątrz klas czegoś na kształt CRC + informacje jakie wymagania realizują dane klasy.
Wtedy przy reverse engineringu można by to wszystko zaimportować z powrotem do Enterprise Architecta. Oczywiście nie obejdzie się bez napisania odpowiedniego skryptu, ale to od wersji 7.5 jest sprawą relatywnie łatwą.