Dwa tygodnie temu sięgnąłem do wykopalisk. W 2006 roku ukazał się SDJ Extra nr 18 – „IBM Software Development Platforma, Projektowanie w SI”. Byłem współautorem kilku tekstów. 
Zapraszam do drugiej części tekstu „Model – Driven Development udoskonalona metoda wytwarzania aplikacji” (str. 72 – wydawnictwo Software-Wydawnictwo Sp. z o.o. ).
Model – Driven Development udoskonalona metoda wytwarzania aplikacji cz.2
4.3 Model projektu
Budowanie modelu projektowego jest kolejnym działaniem procesu tworzenia oprogramowania. W Rational Software Architect model projektowy jest tworzony w oparciu o szablon Enterprise IT Design Model, który zawiera w sobie szereg zdefiniowanych pakietów (rys. 13)
rys. 13 Architektura modelu projektu
Każdy z pakietów jest agregatem elementów o inny przeznaczeniu. Pakiet Design Contracts zawiera elementy projektu, które są kandydatami do implementacji. Pakiet ten może być repozytorium wielokrotnego użycia – Reuseable Asset Specification (RAS), gdyż zawiera dwa ważne pakiety. Pierwszy z nich – Component Specifications jest repozytorium pakietów obrazujących podsystemy. W pakietach obrazujących podsystemy umieszczone są komponenty, które w następnej fazie zostaną zaimplementowane. Drugim pakietem znajdującym się w Design Contracts jest pakiet Design-Level Use Case Realizations, który jest odpowiedzialny za przechowywanie uszczegółowionych w porównaniu z modelem analitycznym realizacji przypadków użycia. Zasadnicza różnica pomiędzy tymi widokami polega na tym, że w modelu analitycznym zaprezentowane jest zachowanie klas analitycznych natomiast w modelu projektu prezentowana jest współpraca elementów projektowych takich jak np.: komponenty.
Kolejnym ważnym pakietem w modelu projektu jest Implementation Design, który jest agregatem elementów wysokiego poziomu abstrakcji. Pakiet ten wskazuje na zachowanie komponentów, użycie portów oraz pozwala na prezentację jak komponenty współpracują z klasami oraz innymi elementami składowymi projektowanego systemu.
Przeznaczenie pozostałych pakietów modelu projektu jest takie samo jak w wcześniej opisywanych modelach.
Na (rys. 14) zaprezentowano przykład model projektu dla systemu wspomagania hurtowni. Należy zauważyć, zgodnie z tym co zaleca MDD, że nazwy pakietów odpowiedzialnych za podsystemy mają nazwy zgodne z nazewnictwem stron WWW. Taki wymóg niewątpliwie ułatwia zarządzanie zaimplementowanym kodem aplikacji, gdyż pozwala łatwo umiejscowić gotowy artefakt.
rys. 14 Model projektu dla Hurtowni
Zaprezentowana architektura modelu projektu nie jest jedyną z możliwych. W zależności od projektu jego struktura może być różna, a najlepiej taka, która pełniej odda charakter projektowanego przedsięwzięcia.
W modelu projektu, systemu wspomagania pracy hurtowni w specyfikacji komponentów umieszczono diagramy komponentów (przykładowy diagram rys. 15).
rys. 15 Przykładowy diagram komponentów
Na zaprezentowanym przykładowym diagramie zaprezentowano statyczny aspekt komunikacji pomiędzy dwoma komponentami „Sprzedaż” i „Dostawa”. Na diagramie tym można zauważyć także, że klasa Dostawa jest składnikiem komponentu o tej samej nazwie. Wymienione oba komponenty komunikują się ze sobą za pomocą interfejsu o nazwie „IOdbiorcy”.
W Design-Level Use Case Realizations umieszczono diagramy sekwencji i aktywności, które wskazują na zachowanie uszczegółowionych w tym modelu elementów.
rys. 16 Struktura realizacji przypadku użycia (model projektu)
4.4 Model implementacyjny
Model implementacyjny w Rational Software Architect zawiera artefakty odpowiadające plikom i pakietom występującym w tworzonym kodzie programu.
rys. 17 Model implementacji = Implementacja projektu
Należy jednak pamiętać, że w Rational Software Architect dopuszczalne jest pominięcie modelu implementacyjnego, gdyż po utworzeniu modelu projektu, jawnie specyfikującego architekturę rozwiązania, większość elementów implementacyjnych została już uszczegółowiona [11] (w modelu projektu). Można, więc generować projekt aplikacji zarówno z modelu projektu, jaki i za pośrednictwem modelu implementacji.
Istotny jest jednak fakt, iż model implementacji pozwala na pełne zsynchronizowanie implementacji z odpowiadającym mu modelem. Sytuację taką zaprezentowano na rys. 17, na którym wskazano model projektu, model implementacji oraz automatycznie wygenerowany wynik w postaci implementacji projektu. Implementację tę przedstawiono w postaci specyfikacji plików źródłowych w języku Java, tworzonego systemu wspomagania pracy hurtowni. Z rysunku tego wynika, że zastosowanie Rational Software Architect pozwala na to by model implementacyjny, wyrażony w języku UML, był równoważny zbudowanemu kodowi aplikacji. Oznacza to na przykład, że każda zaprojektowana klasa ma swój odpowiednik w kodzie programu.
rys. 18 Artefakt modelu implementacji i klasy implementacji projektu z wygenerowanym kodem.
Omawianą sytuację zaprezentowano na diagramie (rys. 18), który zawiera klasę Dostawa_tow. Klasa Dostawa_tow pochodzi z modelu projektu i jest implementacją artefaktu Dostawa_tow pochodzącego z modelu implementacja. Klasa ta dzięki zależności <<derive>> jest także powiązana z istniejącą klasą wyrażoną w języku implementacji (tutaj Java).
5. Podsumowanie zmian
5.1 Zmiany w architekturze projektu
Przedstawiony w artykule opis architektury jest ukierunkowany na modele i jest zgodny z MDD, które kładzie szczególny nacisk na modele. Z tego też powodu istnieje szereg różnic pomiędzy strukturą projektu w RSA, a projektami „ukierunkowanymi na kod”, które znane są z Rational XDE i Rational Rose. Zasadnicze różnice te zostały umieszczone w tabeli 1.
Tabela 1. Różnice w architekturze RSA a Rose/XDE
| Rational Software Architect | Rational Rose/XDE |
| Architektura projektu zawiera elementy logiczne jak i niektóre elementy fizyczne systemu. | Architektura projektu zawiera tylko modele logiczne. |
| Modele nie mają określonej roli – bardzo często stosowany jest czysty szablon) | Modele pełnią określoną rolę zawartą w nazwie. |
| Szczegółowy, obligatoryjny podział aktorów na wiele pakietów w zależności od roli jaką pełni w systemie | Szczegółowy podział aktorów na przypadki użycia jest opcją. |
| Szablon modelu przypadków użycia zawiera pakiety uszczegóławiające model. | Brak w szablonie dodatkowych pakietów |
| Realizacja przypadku użycia jest elementem współpracy | Realizacja przypadku użycia jest pakietem |
| Model analizy wymaga dodatkowych pakietów agregujących model na funkcjonalnie sobie odpowiadające elementy. | Opcjonalne jest dzielenie modelu analizy na pakiety. |
| Model implementacji jest równoznaczny z implementacją systemu | Model implementacji nie jest tożsamy z implementacja systemu |
5.2 Zmiany w etapach procesu wytwórczego
Podejście MDD jest, jak już to wspomniano, ukierunkowane na modele, stąd też należy spodziewać się zmian nie tylko w strukturze projektu, ale także w czasie trwania kolejnych etapów cyklu życiowego oprogramowania. Wydaje się również, że czas przeznaczony na etap konstrukcji ulegnie zmniejszeniu na rzecz czasu przeznaczonego na budowanie modeli w etapie rozwinięcia.
rys. 19 Czas i zasoby poświecone na fazy wytwórcze oprogramowania RUP.
Przedstawiony wykres (rys. 19) jest więc prognozą zmian, jakie mogą zajść w czasie trwania poszczególnych etapów cyklu wytwórczego i odpowiadającego im przydziału zasobów do poszczególnych etapów procesu RUP (pionowe linie powierzchni etapów wskazują dotychczasowy podział zasobów i etapów, natomiast kreskowanym polem zaznaczono przypuszczane obciążenia).
5.3 Celowość stosowania RSA
Położenie przez udziałowców projektu większego nacisku na architekturę systemu oraz co za tym idzie na zwiększenie szczegółowości modeli sprawia, że Rational Software Architect jest narzędziem dedykowanym dla (za [2]):
- architektów oprogramowania, którzy także tworzą kod aplikacji,
- kodystów, którzy potrzebują pracować zarówno z modelem jak i kodem aplikacji,
- twórców oprogramowania, którzy chcą korzystać ze wszystkich możliwości oferowanych przez MDD,
- udziałowców projektu, którzy przeglądają i sprawdzają istniejącą architekturę w celu sprawdzenia przeniesienia modeli analitycznego i projektowego na model implementacji;
Ponadto RSA pozwala na osiągnięcie korzyści, nie oferowanych przez inne środowiska CASE, do których należą:
- integracja z Eclipse,
- zaawansowane modelowanie oraz możliwość łatwego rozszerzania środowiska narzędziowego przez platformę EMF (Eclipse Modeling Framework),
- poprawiona łatwość stosowania personalizowanych ustawień,
- możliwość modelowania w UML 2.0,
- udoskonalona możliwość przeglądu i kontroli struktury,
- zdolność wizualizacji działania kodu poprzez diagramy sekwencji,
- łatwa możliwość przeglądu kodu,
- zintegrowanie dwóch narzędzi Java IDE i środowiska projektowego MDD.
6. Zakończenie
Pojawienie się Model-Driven Development jest wynikiem naturalnego rozwoju metod wytwarzania oprogramowania. Wynika ona z potrzeby zwiększenia poziomu jakości budowanego oprogramowania i przeciwdziałania uzależnieniu tejże jakości od implementacji. Z tego też powodu kluczowe staje się zwiększenie roli, jaką w projekcie informatycznym pełni architekt oprogramowania i analityk. Zmiany te implikują uszczegółowieniem architektury projektów o nowe artefakty, które pozwalają na silne oddziaływanie na jakości tworzonego oprogramowania już w podczas jego projektowania.
LITERATURA
[1] Booch G., Rumbaugh J., Jacobson I.: UML przewodnik użytkownika, WNT, Warszawa 2003
[2] Cernosek G.: Next-generation model-driven development , IBM Rational Software, White Paper
[3] Fowler M.: UML w kropelce, Wydawnictwo LTP 2002
[4] Jaszkiewicz A.: Inżynieria oprogramowania, Helion, Gliwice 1997
[5] Kruchten P.: The 4+1 View Model of Architecture, IEEE Software. 12(6), 1995 r.
[6] Lloyd A.: How to migrate from code-centric to model-centric development using Rational Software Architect, IBM Rational Software, White Paper
[7] Object Management Group : Unified Modeling Language Specification, Version 2.0
[8] Rational Unified Process for Systems Engineering, Rational Software White Paper, TP165A, 5/02
[9] Rational Unified Process ver. 2003.06.13.
[10] Schmuller J.: UML dla każdego. Helion, Gliwice 2003
[11] Smith B. :Model Structure Guidedelines for Rational Software Modeler and Rational Software Architect, IBM Ratioanl Software, White Paper
[12] „Rational Unified Process for Systems Engineering” Rational Software White Paper, TP165A, 5/02
To koniec drugiej części. Tekst ten opublikowany został ponad 10 lat temu. Powrót do przeszłości uważam za zakończony 🙂
