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.
Kilka dni temu pisałem a statycznej analizie kodu (Dwa słowa o statycznej analizie kodu). W praktyce taka analiza nie jest trudna o czym można się przekonać stosując bardziej zaawansowane narzędzia do projektowania i implementacji. Jednym z lepszszch narzędzi jest Rational Software Architect.
Środowisko Rational Software Architect zapewnia narzędzie od wykonywania statycznej analizy kodu aplikacji. Zwiększa ona jakość finalnego produktu poprzez znajdowanie oraz dokumentowanie wad oprogramowania. Udostępnia ono również ogólną ocenę jakości oprogramowania a co więcej umożliwia ono weryfikację założeń poczynionych na etapie projektowania i specyfikacji wymagań. Code Review Tool udostępnia także możliwość weryfikacji odpowiednich interakcji pomiędzy oprogramowaniem a komponentami systemowymi.
W dzisiejszym świecie podstawowym kryterium oceny tworzonego oprogramowania jest jego niezawodność. To nie jest odkrywczy pogląd. Jedną z techniki wspierającą proces wytwarzania oprogramowania, która istotnie zwiększa jego jakość i niezawodność jest statyczna analiza kodu źródłowego. Poprzez analizę statyczna rozumiem analizę struktury kodu źródłowego lub kodu skompilowanego bez jego uruchomienia. Analiza statyczna może odbywać się na etapie budowania aplikacji, ponieważ jej wyniki są dostępne już podczas kompilacji kodu źródłowego. Istnieje kilka metod analizy statycznej kodu. Są to:
Ponadto warto wspomnieć, że statyczna analiza programu pozwala na:
Na koniec chciałbym przypomnieć, że dobry przypadek testowy to taki, który niesie duże prawdopodobieństwo wykrycia nowego błędu 
Nigdy się nie zastanawiałem nad etyką w procesie wytwórczym oprogramowania aż do dziś kiedy natrafiłem na artykuł, którego autorami są Maria Ganzha i Stanisław Szejko. Tekst jest dość ciekawy gdyż porusza nowe obszary procesu wytwórczego oprogramowania, które wykraczają poza tradycyjnie stosowaną podejście stosowane w inżynierii oprogramowania.
Zainteresowanych odsyłam do artykułu: http://www.e-informatyka.pl/article/show/493
Inżynieria oprogramowania to nie tylko systemy informatyczne ale także agentowe czyli takie, które (najogólniej rzecz ujmująć)bazują na samodzielnych jednostkach, które mogą się przemieszczać i wykonywać usługę na rzecz wysyłającego go klienta. O bezpieczeństwie takich systemów wraz z metodami modelowania za pomocą języka AML (Agent Modeling Language) napisaliśmy z kolegami rozdział do książki pt.: “Inżynieria oprogramowania Metody wytwarzania i wybrane zastosowania” pod red. B. Hnatkowskiej, Z. Huzara. Tytuł naszego rozdz
iału to: Bezpieczeństwo w środowiskach otwartych na przykładzie metryk zaufania mobilnych agentów. Książka ma się ukazać niebawem nakładem wydawnictwa PWN a zainteresowanych tym tekstem odsyłam na strony 296-307.
Zawsze trzymam kciuki za firmę, która w pewnym momencie swojego rozwoju dostrzega fakt, że złożoność systemów bądź procesów biznesowych jest tak wielka, że trzeba sięgnąć po zestaw innych praktyk. Lubię, gdy zgłaszają się do mnie i mogę zaproponować im jako lekarstwo podejście obiektowe. Bardzo często te firmy chcą zobaczyć czy UML jest zgodny z kulturą organizacji lub sprawdzić czy jest w nim coś dla nich. Tak było i tym razem w dwóch miejscach, które łączy jedno – obie firmy działają w sektorze bankowym. Pierwszą z nich jest wytwórca oprogramowania dla banków. Na dwudniowych warsztatach modelowany był fragment systemu bankowego – bardzo mały fragment, na których zaprezentowałem w Enterprise Architect, podstawowe techniki modelowania poczynając od diagramów przypadków użycia po przez diagram klas kończąc na modelach zachowania systemu. Po pierwszych opiniach jakie usłyszałem po zakończeniu warsztatów myślę, że firma ta w perspektywie niezadługiego czasu skorzysta z pewnych modeli.
Drugą firmą był jeden z dużych banków. W banku największy nacisk był położony na dokumentowanie procesów biznesowych za pomocą UML oraz metodykę budowania modeli. W pięciodniowych warsztatach, których celem było sprawdzenie przydatności języka UML do modelowania procesów biznesowych, był wykorzystany IBM Rational Software Modeler oraz IBM RequisitePro oraz autorski proces budowania modeli biznesowych. Nie mam jeszcze oficjalnej opinii z banku na temat mojej i mojego kolegi pracy w czasie tych 5 dni, ale za dobrą monetę biorę słowa jednego z uczestników warsztatów – przedstawiciela działu IT – “Jeszcze nigdy biznes nie dał nam tak dobrze opisanego procesu…”
W obecnych czasach developerzy oprogramowania muszą odznaczać się wysoką produktywnością, aby móc sprostać wciąż wzrastającym wymaganiom na oprogramowanie. Wielu profesjonalistów z branży IT wciąż kontynuuje jednak spędzanie wielu godzin pracy nad rozwijaniem powtarzających się i istniejących od dawna rozwiązań na niskim poziomie abstrakcji. Istnieją jednak nowe metody wspierające proces budowania oprogramowania, dzięki którym to specjaliści IT nie muszą pracować nad powtarzającymi się problemami, ale za to mogą skupić swoją uwagę na poważniejszych koncepcjach znajdujących się na wyższych poziomach abstrakcji. Mowa tutaj oczywiście o wzorcach projektowych.
Wszystkie prawa zastrzeżone 
modesto group All rights reserved
