Czy warto stosować mechanizmy inżynierii wprzód i wstecz w zwinnym modelowaniu?

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
Podobne wpisy
Enterprise Architect 14 – pierwsze wrażenia

Enterprise Architect, jak już wspominałem w kilku poprzednich wpisach, doczekał się wersji 14. Tradycyjnie firma Sparx System dokonała zmiany menu więcej

Enterprise Architect 13 został opublikowany

Zgodnie z zapowiedziami Enterprise Architect doczekał się 13 wersji. Sparx Systems dziś opublikował finalną wersję tego popularnego narzędzia. Publiczna kompilacja więcej

Wersjonowanie w Enterprise Architect 13

Wersjonowanie w Enterprise Architect 13 zwane Time Aware Modeling (TAM) to jedna z najbardziej znaczących zmian w nowej wersji Enterprise więcej

Kanban w Enterprise Architect 13 część 2

W poprzednim tygodniu pisałem o kanban w Enterprise Architect (Kanban w Enterprise Architect 13 część 1). Dziś postaram się przedstawić więcej

Reklama
MODESTO - licencje Enterprise Architect

1 komentarz dla “Czy warto stosować mechanizmy inżynierii wprzód i wstecz w zwinnym modelowaniu?”

  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 komentarz

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

Przewiń do góry