Po zbudowaniu modelu analitycznego (Projekt i implementacja aplikacji JAVA w środowisku IBM Rational Software Architect – model analizy), który powstał na podstawie modelu przypadków użycia (Projekt i implementacja aplikacji JAVA w środowisku IBM Rational Software Architect – model przypadków użycia) można przejść do budowy modelu projektowego, który w naszym przypadku, będzie podstawa do wygenerowania szkieletu kodu aplikacji. Pierwszym krokiem tego etapu będzie dodanie do naszego projektu pustego szablonu projektowego, który będzie podstawą do zbudowania modelu projektu. Model ten dodaje się w sposób analogiczny jak poprzednie modele.
Następnie w nowo utworzonym projekcie dodajemy folder ?Klasy projektowe? i metodą przeciągnij i upuść kopiujemy wszystkie klasy z modelu analitycznego do modelu projektu. Następnym krokiem jest uszczegółowienie wszystkich klas poprzez dodanie wszystkich wymaganych atrybutów i metod (rysunek 12). Dodawane elementy powinny uwzględniać już specyfikę języka implementacji (tutaj JAVA).
Rysunek 12 Uszczegóławianie klas analitycznych
Po wstępnym uszczegółowieniu klasy można przystąpić do generowania szkieletu kodu aplikacji. W tym celu należy na wybranej do transformacji klasie kliknąć prawym klawiszem myszy i w menu kontekstowym należy wybrać Transform -> Run Transformation -> UML to Java.
Rysunek 13 Inżynieria do przodu
Wykonanie powyższych kroków uruchamia kreatora, który krok po kroku pozwala na zdefiniowanie JAVA?owego szkieletu aplikacji. Opisywaną sekwencję kroków można wykonać zarówno do pojedynczej klasy jak również do całego pakietu lub modelu. W tym przypadku uruchomiono kreatora , którego celem będzie wykonanie szkieletu klasy ObslugaPliku, która odpowiedzialna jesz za zapis i odczyt plików.
Pierwszym widokiem kreatora jest ekran umożliwiający wybór projektu aplikacji. W naszym przypadku nie mamy takiego projektu jeszcze zdefiniowanego i dlatego klikami na Create New Target Container. Wzmiankowany przycisk uruchamia ekran, który pozwala na dodanie nowego projektu JAVA (rysunek 14).
Utworzony projekt staje się repozytorium kodu aplikacji.
Rysunek 14 Nowy projekt Java generowany podczas inżynierii wprzód
W naszym przykładzie projekt nazywa się KAX_JAVA. Określenie celu transformacji pozwala na jej zakończenie co skutkuje utworzeniem w projekcie KAX_JAVA pliku zawierającego szkielet implementacji systemu. Na poniższym rysunku (rysunek 15) zaprezentowano klasę ObslugaPliku zarówno w modelu projektu jaki i modelu implementacji (KAX_JAVA). Model implementacji jest jednoznaczny z jego implementacja wyrażoną w języku JAVA. Od tej pory jakakolwiek zmiana w modelu warunkuje zmianę w kodzie aplikacji.
Rysunek 15 Model implementacji wraz ze szkieletem kodu
Kolejnym krokiem jest uzupełnienie pliku ObslugaPliku z kodem źródłowym z odpowiednimi treściami, które pozwolą na funkcjonowanie aplikacji.
Rysunek 16 Kod aplikacji ? fragment
Następne etapy wytwórcze naszej aplikacji to powtórzenie zaprezentowanych kroków od momentu uszczegóławiania klas aż po implementację. W trakcie implementacji należy korzystać ze zdefiniowanych wcześniej diagramów , które w modelu analitycznym stanowią integralną część realizacji przypadków użycia.
Uruchomienie
Po dodaniu kod aplikacji należy przejść do jej debugowania i uruchomienia. W tym celu należy najpierw sprawdzić poprawność kodu przez validator. Należy, więc kliknąć prawym klawiszem myszy na nazwie projektu i wybrać Run Validators. W przypadku poprawnej walidacji można uruchomić aplikacje poprzez kliknięcie w przycisk ze strzałką (rys).
Rysunek 17 Przyciski uruchamiające aplikację
W trakcie pierwszego uruchomienia należy określić typ aplikacji i jego środowisko uruchomienia. Ważne jest też określenie głównej klasy, którą w tym przypadku jest klasa KsiazkaAdresowa.
Rysunek 18 Środowisko uruchomienia
Po zdefiniowaniu zmiennych potrzebnych do uruchomienia naszej aplikacji i kliknięciu w przycisk Run aplikacja zostaje uruchomiona.
Ostatnim etapem wytwórczym systemu jest sprawdzenie czy realizowana jest funkcjonalność aplikacji, która założona była na początku naszego przedsięwzięcia.
Dokumentacja po implementacji
Zakończenie projektu implementacją zgodną z wymaganiami stanowi sukces niezależnie od faktu jak duży był budowany system. Niestety w działającej aplikacji należy robić poprawki. Zmiany w oprogramowaniu wynikać mogą z błędów aplikacji ale również, co ma miejsce najczęściej, przyczyną bywa zmieniające się warunki funkcjonowania odbiorcy oprogramowania. Ostatnim powodem jest chęć zwiększenia funkcjonalności systemu. Bardzo często zmiany te maja miejsce po pewnym czasie od wdrożenia i wtedy kłopotliwe może być zrozumienie własnoręcznie napisanego kodu programu. W celu uniknięcia tych trudności dobrze jest po implementacji zsynchronizować kod aplikacji z modelem w języku UML, co stanowić będzie dodatkowe elementy repozytorium naszego projektu.
W IBM Rational Software Architect synchronizacja kodu aplikacji z modelem UML odbywa się poprzez budowę diagramów klas. Diagram klas dodaje się w Package Explorer w analogiczny sposób jak inne diagramy UML, tzn. należy na nazwie projektu z kodem źródłowym stosując prawy klawisz myszy wybrać w menu kontekstowym New -> Class Diagram. Do tak dodanego diagramu można metodą przeciagnij&upuść przeciągnąć klasy, które są podpięte pliki z kodem źródłowym systemu (Rysunek 19).
Rysunek 19 Fragment diagramu klas zaimplementowanego systemu
Zbudowawany na podstawie kodu źródłowego diagram klas jest w pełni z nim zsynchronizowany. Oznacza to, ze tak sam jak najmniejsza zmiana na diagramie powoduje zmianę w kodzie aplikacji to zmiana w kodzie aplikacji niesie ze sobą natychmiastowy skutek na diagramie.
Podsumowanie
Zakończyliśmy projektowanie aplikacji i jej implementację. Dodatkowo udokumentowaliśmy strukturę systemu w postaci diagramu klas. W czasie pracy projektu okazało się, że IBM Rational Software Architect jest niewątpliwi jednym z najbardziej zaawansowanych narzędzi developerskich ostatnich lat, stanowiącym jednolite środowisko programistyczne, które umożliwia projektowanie aplikacji i jej kodowanie bez potrzeby przełączania się pomiędzy różnymi produktami. Wsparcie dla zarządzania wymaganiami (współpraca z RequisitePro) oraz możliwość utrzymywania odpowiadających implementacji diagramów klas pozwala na skuteczne zarządzanie projektem. Ważny jest fakt, ze narzędzie to umożliwia projektowanie aplikacji (co też uczyniliśmy) w języku UML 2.0. Zostaje tylko siąść i samodzielnie budować coraz to doskonalsze systemy informatyczne.
Dodawanie komentarzy zostało zablokowane.