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.
Dużo się mówi na temat modelowania systemów informatycznych w języku UML. A co z systemami, które nie są informatycznymi? Za nim odpowiem na to pytanie warto przypomnieć sobie czym jest system a pomoże mi w tym zestawienie jakie zrobił Robert Gwiazdowski, którego pozwalam sobie zacytować:
Pod pojęciem systemu nauka rozumie zintegrowaną całość, której własności nie są prostą sumą własności poszczególnych części tej całości, istnienie jednak szereg związków i interakcji pomiędzy nimi. (E. Laszlo, Systemowy obraz świata, Warszawa 1978; L. von Bertalanffy, Ogólna teoria systemów, Warszawa 1984) „Doniosłą cechą systemów jest tkwiący w samej ich istocie charakter dynamiczny. Systemy pod względem formy nie są sztywnymi strukturami; ich forma wyraża zmienne, a jednocześnie trwałe przejawy procesów zachodzących w systemach”. (F. Capra, Punkt zwrotny, Warszawa 1987) Funkcjonowanie systemu stanowi rezultat zachodzących w nich pętli sprzężeń zwrotnych polegających na tym, że element A oddziaływa na element B, B na C, zaś C zwrotnie na A. W systemie nie działa linearny łańcuch przyczyn i skutków, lecz zjawisko nielinearnej współzależności.
Z powyższych definicji wynika, że system składa się ze struktur, które zmieniają swój stan – przejawiają zachowanie. Jest to wspólna cecha systemów informatycznych (np.: struktura: klasa, zachowanie metoda, która zmienia stan klasy) i systemów nieinformatycznych (np.: struktura: siłownik, zachowanie: uruchomienie dźwigni, która zmienia położenie – stan -siłownika).
Reasumując skoro UML nadaje sie do modelowania systemów informatycznych to nadaje się także do modelowania wszystkich innych typów systemów ze szczególnym naciskiem na automatykę i robotykę. Nie można też zapomnieć o innych dziedzinach społecznych nie związanych z informatyką, gdzie są stosowane różnej maści systemy (np.: system wynagrodzeń). W obszarach nietechnicznych UML sprawdza się bardzo dobrze przy modelowaniu procesów biznesowych, gdzie także możemy odnotować, że (cytując R. Gwiazdowskiego) element A oddziaływa na element B, B na C, zaś C zwrotnie na A. Co w konsekwencji pozwala sądzić, że w modelach biznesowych (ponownie cyt.) nie działa linearny łańcuch przyczyn i skutków, lecz zjawisko nielinearnej współzależności.
Planowanie w oparciu o kamienie milowe obejmuje określenie pożądanych wyników projektu i planowania progresji wobec nich poprzez serię kamieni milowych. Można określić dwa typy kamieni milowych:
Każdy kamień milowy jest określony w zakresie celów, które muszą być osiągnięte oraz kryteriów oceny dla obiektywnej oceny, czy zostały osiągnięte. Każdy kamień milowy prezentuje:
Korzystając z techniki kamieni milowych pamiętaj aby zidentyfikować główne produkty kamieni milowych. Pamiętaj także, że granice iteracji zapewniają jasno określone wewnętrzne kamienie milowe dla projektów iteracyjnych.
W trakcie projektowania systemów na poziomie komponentów istotnym jest aby dobrze wyspecyfikować kanały komunikacji pomiędzy komponentami. Poniżej w tekście tym, postaram się przedstawić kilka technik umożliwiających pracę na tym poziomie abstrakcji.
Jak widać uległ zmianie design bloga co zostało podyktowane faktem, że od 2 listopada moje teksty stały się kanałem informacyjnyno-merytorycznym wcielonym w struktury firmy Modesto (www.modesto.pl).
Wraz ze “zmianą designu” znikają wszystkie reklamy – co ja osobiście uważam za plus. Ponadto blog przechodzić będzie na nowy serwer co może spowodować drobne perturbacje.
Przy okazji chciałem się pochwalić, że w ostatnim miesiącu moja strona odnotowała troszkę ponad 3000 odwiedzin. Dziękuję.
Praca grupowa w Enterprise Architect jest wydajniejsza po zastosowaniu centralnego serwera bazodanowego, na którym znajduje się repozytorium z modelami i dokumentacją projektową. Takie repozytorium może być postawione przykładowo na MySQL. Tu jednak rodzi się problem z polskimi znakami. Każdy polski znak zwłaszcza litra “ł“ są zamieniane na znaki zapytania.
Aby temu zapobiec wystarczy zmienić kodowanie tabel w bazie danych z latin1 na utf-8.
Kilka dni października spędziłem na Śląsku, gdzie miałem okazję wspierać Klienta w zakresie modelowania za pomocą języka UML w Enterprise Architect. Zdarzenie to jest o tyle ciekawe, że po za “tradycyjnymi modelami” budowaliśmy modele systemów działających w oparciu o architekturę zorientowaną na usługi (SOA). Poniżej diagram-przykład (nie pochodzi z rzeczywistego projektu Klienta) przedstawiający fragment modelu.
Co więcej okazało się, że wersja Corporate Enterprise Architecta w zakresie modelownia SOA z powodzeniem, po małych zabiegach, dogania wersję Ultimate, której używam.
Na koniec chcę się pochwalić, że w przeprowadzonej anonimowej ankiecie, otrzymałem w zakresie kompetencji i umiejętności przekazania wiedzy dobre i bardzo dobre noty.
Wszystkie prawa zastrzeżone 
modesto
