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?
W poprzednich tekstach (Inżynieria wstecz w projektach JAVA za pomocą Enterprise Architect, MDG Integration for Eclipse i generowanie kodu aplikacji z poziomu Enterprise Architect) pisałem o inżynierii wstecz w Enterprise Architect. Teraz czas na mały sekret.
Czy można pisać kod aplikacji w Enterprise Architect? Tak można i zaprezentuje to na przykładzie z którego korzystałem w tekście: Inżynieria wstecz w projektach JAVA za pomocą Enterprise Architect
W tekście Enterprise Architect i MDG Integration for Eclipse w praktyce opisałem wstępnie wtyczkę MDG Integration for Eclipse, która ułatwia integrację Enterprise Architecta ze środowiskiem Eclipse. Teraz postaram się zaprezentować możliwości wtyczki w zakresie synchronizacji kodu z modelem.
Tradycyjną metodę inżynierii wstecz opisałem kilka dni temu w tekście: Inżynieria wstecz w projektach JAVA za pomocą Enterprise Architect. Dziś chciałbym się skupić na płatnej wtyczce jaką można zastosować do Enterprise Architecta celem synchronizacji modeli ze środowiskiem JAVA czyli MDG Integration for Eclipse.
Mechanizm inżynierii wstecz (ang. reverse engineering) wstecz jest użyteczny w tedy, gdy mamy napisany program i chcemy go udokumentować za pomocą modeli UML. Powstała w ten sposób dokumentacja jest modelem implementacji. W Enterprise Architect można dokonać tego poprzez wybór odpowiedniego parametru w menu kontekstowym pakietu do którego będzie importowany kod.
Kolejny raz okazało się, że duży potencjał jest ukryty także poza dużymi ośrodkami takimi jak Warszawa, Kraków czy Gdańsk. O Wrocławiu nie wspominając. Tym razem miałem okazję i przyjemność przekonać się o tym w jednej z podkarpackich miejscowości. W czasie dwóch dni, jakie tam spędziłem wspierając młody i ambitny zespół ludzi, przed którymi stanęło dość ciekawe zadanie (niestety z uwagi na ochronę interesów klienta nie mogę podać więcej szczegółów). Tempo prac było bardzo duże bo i temat nie był banalny. Wydaje się mi, że udało się uzyskać zamierzone cele co potwierdzają ankiety. Moje oceny ze szkolenia były w zakresie przygotowanie konsultanta i ważność poruszanych tematów: otrzymałem same bardzo dobre oceny a w zakresie sposób prezentacji tematu jedna ocena dobry a pozostałe bardzo dobry.
O tym, że modelowanie jest przydatne w projektowani wszelakich aplikacji, nie trzeba przekonywać nikogo. Cieszy mnie bardzo, gdy widzę, że kolejne firmy mają ten sam pogląd i razem
wypracowujemy metodykę działania dla ich potrzeb. Tak też było w ostanie dni maja, w które prowadziłem szkolenie dla kilku osób z firmy produkującej gry. Bardzo dobrze spędziłem ten czas z dwóch powodów. Po pierwsze już dawno nie miałem tak wdzięcznego tematu do pracy. Po drugie uczestnicy – rzeczowi, wymagający, doświadczeni programiści poszukujący rozwiązań szytych na ich miarę, co spowodowało, że szkolenie było bardzo intensywne i myślę, że udane. Świadczą o tym ankiety, w których otrzymałem same bardzo dobre oceny za ważność poruszanych tematów, ćwiczenia i moje przygotowanie. Na koniec cytat z ankiety z punktu Co najbardziej podobało Ci się w niniejszym szkoleniu: “Duża liczba ćwiczeń praktycznych. Szkolenie zostało dostosowane do dziedziny jaką się zajmujemy”. Dziękuję za te słowa.
Mit: Zwinne zespoły nie produkują dokumentacji
Fakt: Dobry zwinny zespół produkuje taką ilość dokumentacji, która jest niezbędna do wspierania, utrzymania i rozwoju oprogramowania. Zwinne zespoły produkują przykładowo dokumentacje wyjaśniającą metafory i pojęcia słownikowe używane w trakcie projektu oraz modele w ograniczonym zakresie.
Mit: Zwinne zespoły nie potrzebują inwestować w wymagania
Fakt: Zwinne zespoły maniakalnie koncentrują się na spotkaniach z klientem związanych z określeniem wymagań. Nie potrzebują zapisywać wszystkiego na przód. Jeśli nie ma na miejscu klienta, zespoły używają bardziej tradycyjnych technik, takich jak przypadki użycia.
Mit: Zwinne zespoły nie tworzą modeli ani architektury systemu
Fakt: Zespoły tworzą wiele modeli (zazwyczaj ręcznie na białych kartach) w celu ułatwienia komunikacji. Badania wykazały, że większość zwinnych zespołów wykonuje modele by pomóc zrozumieć jak oni budują i konstruują system. Brak projektu całości na początku przedsięwzięcia nie oznacza braku projektowania. Najczęściej obok przypadków użycia powstają diagramy klas i aktywności.
Mit: Zwinne zespoły nie maja żadnych planów
Fakt: Zwinne zespołu projektują by nie było jak z Alicją w Kainie Czarów Lewisa Carrolla:
– Czy nie mógłby pan mnie poinformować, którędy powinnam pójść? – mówiła dalej.
– To zależy w dużej mierze od tego, dokąd pragnęłabyś zajść – odparł Kot – Dziwak.
– Właściwie wszystko mi jedno.
– W takim razie również wszystko jedno, którędy pójdziesz.
– Chciałabym tylko dostać się dokądś – dodała Alicja w formie wyjaśnienia.
– Ach, na pewno tam się dostaniesz, jeśli tylko będziesz szła dość długo.
Mit: Zwinne zespoły szybko przestają być kontrolowane, robią cokolwiek jak lubią i kiedy chcą.
Fakt: Zespół jest właściwie bardzo zdyscyplinowany i bardzo skupiony.Zadania zawsze są wykonywane w ustalonym porządku, z priorytetem określonym przez klienta przy pomocy przypadków użycia. Mierzenie osiągnięć celów nakreślonych przez przypadki użycia służy do jasnego oszacowania postępu i wydajności.
Mit: Jeśli jesteś zwinny, to nie potrzebujesz żadnych menadżerów
Fakt: Potrzebny jest menadżer by utworzyć dobre środowisko pracy i zaplanować iteracje w oparciu o przypadki użycia. Zwinny zespół dostarcza mierzalnych celów, określonych przez przypadki użycia. Menadżer za pomocą przypadków użycia szacuje ryzyko co umożliwia mu tym samym bardziej efektywne zarządzanie.
Kilka dni temu, w tekście Model Driven Architecture modele PIM a PSM, napisałem dwa słowa o modelach PSM i PIM w architekturze MDA. Teraz chciałbym pokazać jak taką transformację zrobić w Enterprise Architect.
Zrobię to na przykładzie wzorca projektowego Adapter, którego celem jest którego celem jest umożliwienie współpracy dwóm klasom o niekompatybilnych interfejsach.
Zaprezentowany model jest odseparowany od swojej implementacji. Aby wykonać model PSM należy
Zazwyczaj sporo mówi się na temat tego, że model musi być odseparowany od swojej implementacji. Oznacza to, że w pierwszej fazie modelowania nie należy
zastanawiać się nad tym, jak będzie wyglądała implementacja. Dopiero po zatwierdzeniu projektu można dostosować model już do środowiska implementacji. Sprzyja to reużyciu całych fragmentów projektów. Stosując taka zasadę idealnie działa się zgodnie z MDA czyli Model Driven Architecture. Model-Driven Architecture – to sposób budowania oprogramowania w oparciu o modele i ich transformacje.
W MDA wyróżnia się 4 poziomy (modele):
Patrząc na ten podział modelem odseparowanym od implementacji będzie model PIM, którego ideą jest zaprezentowanie rozwiązania zgodnego z wymaganiami.
PSM natomiast stanowi odwzorowanie abstrakcji zamodelowanych w PIM na konkretne rozwiązania charakterystyczne dla danej platformy lub języka programowania. Mówiąc inaczej PSM jest uszczegółowioną formą PIM lub jego konkretnym wystąpieniem.
Narzędzia CASE w różnym stopniu wspierają takie podejście. Czasem jest to wygenerowanie modelu implementacji jak ma to miejsce w narzędziach z rodziny Rational (nawiasem mówiąc w produktach Rational mówi się o Model Driven Development (MDD), który jest rozszerzoną wersją MDA) lub modelu platformy jak ma to miejsce w Enterprise Architect.
Przykład transformacji w EnterpriseArchitect można znaleźć w poście Transformacja PIM-PSM w Enterprise Architect
Na koniec należy wspomnieć, że dwukierunkowość transformacji PIM –> PSM i PSM –>PIM nie jest zawsze możliwa.
Kilka dni temu ukazał sie Enterprise Architect w wersji 7.5. Nowością są 3 nowe wersje:
Mnie najbardziej interesuje opcja generowania kodu z modeli behavioralnych: diagramów sekwencji, maszyny stanów lub aktywności przeczytaj pozostałą część »
Wszystkie prawa zastrzeżone 
modesto group All rights reserved
