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.

Technorati Tagi: Enterprise Architect,inżynieria oprogramowania,narzędzia CASE,modelowanie systemów informatycznych,agile modeling

1 Comment

  1. 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ą.

Zostaw odpowiedź

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *

Możesz użyć tych HTML tagów i atrybutów: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

Close