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
Zintegrowane środowisko wytwarzania aplikacji web’owych na platformie .NET

W artykule przedstawiono opis pakietu narzędziowego VS.NET (Microsoft) z Rational XDE (IBM) do wytwarzania aplikacji webowych pracujących w środowisku urządzeń więcej

Rational Software Architect Pierwszy Krok

Technorati Tagi: Rational Software Architect,inżynieria oprogramowania W artykule zaprezentowano jak rozpocząć pracę z i opis elementów tego narzędzia CASE. Środowisko więcej

Wstęp do projektowania aplikacji w Rational Software Architect

Rational Software Architect jest kolejną po Rational Rose i Rational XDE generacją narzędzi wspierających twórców oprogramowania w czasie projektowania. RSA więcej

Rational Unified Process – Wstęp

Rational Unified Process jest zunifikowanym procesem wytwórczym oprogramowania dostarczającym praktycznych wskazówek, wzorców dokumentów i narzędzi, szablonów dokumentów oraz przykładów postępowania 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 *

Scroll to Top