Tegoroczny kwiecień to moje małe święto. Dziesiąta rocznica blogowania. Pomyślałem, że może warto jest wrócić do tego co było przed blogiem. Przed blogiem już trochę pisałem. Potem moją twórczość przelałem na bloga. Wtedy to były materiały uzupełniające dla moich studentów. Nie miałem planu być w sieci tak długo – 10 lat temu nie było blogosfery :-). Ot strona pracownika uczelni. Okazało się, że lubię pisać. Znaleźli się ludzie, którzy czytają niszowego bloga o inżynierii oprogramowania. Dziś postanowiłem przypomnieć tekst, który powstał przed blogiem. Było ich wiele. Ten wybrałem ze względu na fakt, że o MDD mówi się teraz raczej niewiele. 
W 2006 roku ukazał się SDJ Extra nr 18 – „IBM Software Development Platforma, Projektowanie w SI”. Byłem współautorem kilku tekstów. Znalazłem się wśród znakomitych osób. Jedną z nich był sam Philippe Kruchten. To historia :-). A oto tekst Model – Driven Development udoskonalona metoda wytwarzania aplikacji (str. 72 – wydawnictwo Software-Wydawnictwo Sp. z o.o. ). Tekst napisałem wraz z Andrzejem Stasiakiem. Tekst jest długi więc podzieliłem go na dwa wpisy. Kolejna część tekstu już za dwa tygodnie.
Model – Driven Development udoskonalona metoda wytwarzania aplikacji cz. 1
1. Wprowadzenie
Projektowanie i implementacja oprogramowania to niewątpliwie procesy o dużej złożoności. Fakt ten został zauważony już w połowie lat sześćdziesiątych poprzedniego stulecia, gdy wraz z rozwojem technologii, budowano złożone systemy informatyczne, których realizacja wymagała współpracy wielu osób. Głównie z powodu ich złożoności wiele z tych przedsięwzięć zakończyło się fiaskiem lub znacznie przekroczono w nich założony czas realizacji albo planowany budżet. Okazało się również, że techniki budowy oprogramowania nie nadążały za rozwojem sprzętu i potrzebami użytkowników. Zjawiska te określono jako „kryzys oprogramowania” [4].
Obecnie, w walce z niezmiennie trwającym kryzysem oprogramowania, udziałowcy projektu są wspierani przez wiele metodyk i narządzi CASE. Mimo dużego zaangażowania w usprawnienie wszystkich procesów wytwórczych systemów informatycznych (od wymagań na system, po implementację i testowanie) okazało się, że nadal kluczowym etapem świadczącym o jakości budowanych systemów jest tworzenie kodu aplikacji [2]. Jedną z istotnych przyczyn takiej sytuacji są często błędy spowodowane brakiem jawnych specyfikacji zależności (mapowań) między modelami projektowymi a odpowiadającym im kodom źródłowym aplikacji. Brak poprawnego mapowania prowadzić może do niepożądanej sytuacji, w której analityk systemu musi wspólnie z kodystą dokonywać przeglądów zaimplementowanych już fragmentów systemu (w celu usunięcia defektów w oprogramowaniu). Dlatego, też celowym jest znalezienie takiego rozwiązania, które doprowadzi do możliwości kontroli kodu przez architekta systemu (bądź analityka), bez konieczności znajomości przez niego języka w jakim jest zaimplementowane rozwiązanie. Czy jest to możliwe? Aby udzielić odpowiedzi twierdzącej na to pytanie niezbędne jest spełnienie następującej zależności:
model implementacji <-> implementacja projektu (1)
Podana zależność (1) oznacza, że model implementacyjny wyrażony np.: w języku UML, jest równoważny zbudowanemu na jego podstawie kodowi aplikacji systemu. W tej sytuacji, każda część kodu systemu (wyrażona w języku implementacji) ma jednoznacznie odpowiadający jej model implementacji systemu (opisany w języku modelowania). Czyli spełnienie zależności (1) umożliwi pełniejszą kontrolę nad kodem aplikacji dzięki modelom UML.
Zaprezentowane rozwiązanie przenosi uwagę projektantów z kodu aplikacji na odpowiadające mu modele, z których ten kod powstaje oraz jego testy. Skutkiem tej zmiany jest przejście z podejścia ukierunkowanego na kod systemu (ang. code-centric) do podejścia ukierunkowanego na modele (ang. model-centric), które podnosi znaczenie ról, jakie pełnią architekci i analitycy systemu [6]. Wytwarzanie oprogramowania zgodnie z tym podejściem zwane Model-Driven Development (MDD), kładzie szczególny nacisk na architekturę projektu.
Z tego też powodu celowe wydaje się wykonanie próby mapowania, wcześniej znanej architektury projektu wyrażonej w metodyce RUP, na nowe bardziej ukierunkowane na architekturę projektu i modele, podejście MDD.
W niniejszym artykule, na przykładzie systemu wspomagania pracy hurtowni, zaprezentowana zostanie nowa metoda projektowania oprogramowania ukierunkowana na modele (model-centric). W opisie metody, z pewnym uproszczeniem założono, że przedstawiona zostanie ona jako sekwencja kolejnych działań (kroków) wytyczonych przez proces wytwórczy RUP. Projekt wykonany będzie w IBM Rational Software Architect (RSA), który jest jednym z narzędzi IBM Software Development Platform – środowiska wytwórczego oprogramowania dedykowanego dla podejścia MDD.
2. Perspektywy RUP
Rational Unified Proces jest jedną z bardziej kompleksowych metodyk, wspierających procesy wytwórcze oprogramowania.
W RUP stosuje się pięć powiązanych ze sobą perspektyw, z których każda opisuje system z innego punktu widzenia. Poniżej (rys. 1), na podstawie [1] i [12], zobrazowano perspektywy modelowania architektury systemu.
Przedstawiony model (rys. 1) zwany „The 4 + 1 View Model” [5] odnosi się do potrzeb różnych uczestników budowy oprogramowania, umożliwiając położenie nacisku na autonomiczne i wybrane aspekty systemu, które zostaną przedstawione poniżej.
Perspektywa przypadków użycia (ang. Use Case View), zwana także perspektywą użytkownika, prezentuje system oczami użytkownika i analityka. Głównym celem tego widoku jest specyfikacja obiektów systemu i przedstawienie zależności między nimi, w prezentowanych modelach. Do zobrazowania aspektu statycznego stosuje się diagramy przypadków użycia i obiektów. Uszczegółowienie tych modeli stanowi następuje poprzez przedstawienie cech dynamicznych, projektowanego systemu – postrzeganych przez byty (aktorów) będące poza systemem, w postaci diagramów aktywności, interakcji i stanów.
rys. 1. Modelowanie architektury systemu
W perspektywie projektowej (ang. Logical View, Design View) opisuje się funkcjonowanie systemu z punktu widzenia analityka systemu. W widoku tym kładzie się nacisk na uszczegółowienie specyfikacji wymagań funkcjonalnych i dodatkowych (niefunkcjonalnych, tj. opisujących użyteczność, niezawodność, wydajność, pielęgnowalność i ograniczenia projektowe) projektowanego systemu. Aspekt statyczny perspektywy projektowej jest wyrażony za pomocą diagramów klas i obiektów a aspekt dynamiczny za pomocą diagramów interakcji, aktywności i stanów.
Perspektywa procesowa (ang. Process View) opisuje funkcjonowanie systemu z punktu widzenia komunikacji oraz synchronizacji wątków i procesów systemu. Zasadniczo, pozwala ona na doprecyzowanie wymagań dodatkowych, takich jak: wydajność, przepustowość i skalowalność. Prezentując klasy aktywne, na tych samych diagramach, co w widoku projektowym, perspektywa procesowa stanowi uszczegółowienie modelu.
Perspektywa implementacyjna (ang. Development View, Implementation View) znana także pod nazwą perspektywy komponentów jest ukierunkowana na opisanie systemu z punktu widzenia jego komponentów składowych. W widoku tym znaczenie mają komponenty i pliki, które zostały użyte do scalenia i udostępnienia systemu (jego kodu). Zasadniczo sprowadza się to do zarządzania konfiguracją poszczególnych wersji systemu. Opis aspektu statycznego tej perspektywy jest realizowany poprzez diagramy komponentów a aspekt dynamiczny poprzez diagramy interakcji, aktywności i stanów.
Ostatnim widokiem jest perspektywa wdrożenia (ang. Deployment View, Physical View) zwana także perspektywą rozmieszczenia. Istotą tej perspektywy jest nacisk na węzły (elementy struktury technicznej) i umieszczone w nich komponenty (elementy struktury oprogramowania), które stanowią o konfiguracji systemu (określając strukturę techniczno-programową). Perspektywa wdrożenia opisuje zagadnienia związane z rozmieszczeniem, dostarczeniem i instalacją systemu. Aspekt statyczny tej perspektywy jest opisywany na diagramach wdrożenia a aspekt dynamiczny na diagramach interakcji, aktywności i stanów.
Przedstawione widoki są na tyle niezależne, że pozwalają wielu różnym twórcom systemu na skupieniu się na tych aspektach systemu, które ich najbardziej interesują. Jednocześnie są na tyle zintegrowane ze sobą, że pozwalają na spojrzenie na system z różnych poziomów abstrakcji. W konsekwencji przedstawionych pięć perspektyw tworzy obraz architektury oprogramowania, która przedstawia nie tylko aspekt dynamiczny i statyczny modelowanego systemu, ale także określa jego funkcjonalność, efektywność oraz ograniczenia ekonomiczno-technologiczne.
3. Perspektywy RUP a modele w RSA
IBM, proponując nowy produkt – Rational Software Architekt (RSA), nie odcina się od procesu RUP, a wręcz przeciwnie wiele z niego czerpie, stąd zaprezentowane (w punkcie 2) perspektywy RUP mają swoje odzwierciedlenie w nowych modelach (RSA – rys. 2). Istotna różnica polega na tym, że perspektywy RUP wyrażone w szablonach repozytoriów projektów Rational Rose są dla nich odpowiednio dedykowane, zgodnie z nazwą do rozwiązania konkretnego problemu – wsparcia konkretnej perspektywy. W RSA nazwy perspektyw są mniej istotne a kluczowa jest zawartość modelu. Mimo tego odmiennego podejścia można mapować modele RUP na modele oferowane w RSA (rys. 2).
rys. 2 Szablony projektowe Rational Software Architect
Na rys. 2, zamieszczono przykład mapowania modeli RUP na szablony projektowe oferowane przez RSA. Należy zauważyć, że Model projektu (ang. Desing Model) jest mapowany dwukrotnie. Pierwsze mapowanie jest skierowane na pusty szablon (ang. Blank Model) a drugie mapowanie dotyczy aplikacji wielowarstwowych (np. aplikacje webowe), dla których dedykowany jest szablon Enterprise IT Design Model. Zgodnie z zaleceniami zawartymi w [11] model analityczny może być w repozytorium projektu jako oddzielny model (ang. Analysis Model) lub może być umieszczony w modelu projektu jako pakiet ze stereotypem <<analysis>>.
4. Architektura projektu w RSA
4.1 Model przypadków użycia
Proces projektowania rozwiązania informatycznego rozpoczyna się od działań w perspektywie przypadków użycia, od utworzenia modelu przypadków użycia. Jego zadaniem jest wizualne zobrazowanie wymagań funkcjonalnych systemu oraz interakcji ze światem zewnętrznym. W Rational Software Architect model ten wybierany jest z szablonu Use Case Model [2].
rys. 3 Struktura modelu przypadków użycia
Po utworzeniu nowego modelu przypadków użycia automatycznie zostaną zbudowane trzy pakiety:
- <perspective> Overviews – który jest stosowany do umieszczenia w nim schematów organizacyjnych. Nie należy w nim przechowywać elementów semantycznych takich jak klasy pakiety, asocjacje, gdyż służy on do składowania diagramów opisujących organizację lub widok aplikacji. Pakiet ze stereotypem perspective jest ekwiwalentem RUP dla inżynierów systemowych lub zgodnie z IEEE 1417 – „Viewpoint”. Pakiet ten przechowuje diagramy
- Actors Overview – prezentuje aktorów stosowanych w modelu przypadków użycia i zależności zachodzące między nimi.
- Context Diagram – zawiera najważniejsze przypadki użycia wraz z aktorami.
- Versatile Actors – jest stosowany do przechowywania aktorów, do których następują odwołania z różnych pakietów modelu.
- <<model Library>> Use-Case Building Blocks – zawiera elementy modelu, które są stosowane w modelu przypadków użycia.
3.1 ${functional.area} – kontener funkcjonalnie powiązanych ze sobą aktorów i przypadków użycia.
3.2 ${use.case} – prototypowe przypadki użycia, które są doprecyzowane podstawowymi i alternatywnymi scenariuszami (diagramy sekwencji i aktywności).
Jak z przedstawionego opisu wynika, struktura modelu przypadków użycia w Rational Software Architect jest więc, w porównaniu do Rational Rose, dużo bardziej rozbudowana. Dodatkowo model ten zawiera także diagram pakietów specyfikujących obszary wymagań funkcjonalnych ${project} Requirements Overview.
Pierwszym etapem modelowania przypadków użycia jest określenie pakietów grupujących wymagania funkcjonalne systemu. Dla omawianego przykładu wspomagania sprzedaży hurtowej „Hurtownia” zdefiniowano cztery pakiety. Powinny być one umieszczone w specjalnie do tego celu dedykowanym diagramie Requirements Overview (rys. 4)
rys. 4 Diagram pakietów obszarów funkcjonalnych (Requirements Overview).
Kolejnym krokiem, jaki jest zalecany przez metodykę RUP, jest znalezienie przypadków użycia jak i otoczenia systemu w jakim funkcjonują. Zbudowane w ten sposób diagramy przypadków użycia stanowią uszczegółowienie pakietów diagramu Requirements Overview.
Po określeniu przypadków użycia należy zdefiniować aktorów systemu. MDD zakłada podział aktorów na dwie grupy. W pierwszej umieszczani są aktorzy wchodzący w interakcję z przypadkami użycia w wielu obszarach działania systemu (na wielu diagramach przypadków użycia). W drugiej grupie znajdują się aktorzy, których zakres interakcji z systemem nie przekracza jednego pakietu.
W prezentowanym przykładzie, w modelu przypadków użycia zdefiniowanym przy pomocy RSA, aktorzy zostali zdefiniowani w dwóch pakietach: „Versatile Actors” i „Sprzedaż” (rys. 5). W pierwszym pakiecie zostali umieszczeni aktorzy, którzy biorą udział w różnych obszarach funkcjonalnych systemu. Natomiast aktor „Lokalny dystrybutor„ został umieszczony w pakiecie „Sprzedaż”, gdyż rola jaką prezentuje odnosi się jedynie do funkcjonalności systemu dotyczącej sprzedaży.
Wszyscy aktorzy zostali umieszczeni w specjalnie dla nich dedykowanym diagramie Actors Overview (rys. 6), który znajduje się w katalogu Overviews. Diagram ten wskazuje na zależności pomiędzy aktorami.
Zawartość agregatu funkcjonalności systemu dotycząca sprzedaży została zrealizowana poprzez sześć przypadków użycia, które zostały umieszczone w pakiecie Sprzedaż a ich interakcja z otoczeniem systemu (aktorami) została zaprezentowana na diagramie „Sprzedaż diagram przypadków użycia” (rys. 7).
rys. 5 Struktura projektu z zdekomponowanym pakietem funkcjonalnym „Sprzedaż”
Na diagramie tym umieszczono trzech aktorów, którzy wchodzą w interakcję z system Hurtownia. Ich role to:
rys. 6 Diagram Actor Overview
Lokalny dystrybutor – zbiera zlecenia i dostarcza towar; Odbiorca – jest kupującym towar. Z przedstawionego diagramu wynika, że Odbiorca potwierdza dostawę co w konsekwencji (patrz związek zawierania <include>) umożliwia odebranie faktury. Z największego zakresu funkcji systemu, zgodnie z rys. 7, korzysta Przedstawiciel Handlowy, który Pobiera zamówienia. Z przypadkiem użycia „Pobierz zamówienie jest połączony związkiem zawierania przypadek użycia „Wykonaj specyfikację”. Taka sytuacja oznacza, że Pobranie zamówienia jest związane z wykonaniem przez system specyfikacji. Natomiast związek rozszerzenia <extend>, który łączy przypadki użycia „Pobierz zamówienie” i „Zaktualizuj zamówienie” oznacza, że aktor (Przedstawiciel handlowy), będzie mógł skorzystać z możliwości aktualizacji zamówienia na swoje wyraźne żądanie, przy spełnieniu określonego warunku. Jeśli ten warunek nie zostanie spełniony to funkcja systemu reprezentowana przez „Zaktualizuj zamówienie” nie zostanie uruchomiona.
rys. 7 Sprzedaż – diagram przypadków użycia
W tym miejscu należy wspomnieć, że bardzo istotne jest dobre udokumentowanie przypadku użycia. W praktyce oznacza to, zamieszczenie w dokumentacji diagramu takich elementów jak opis funkcjonalności, jaką reprezentuje przypadek użycia, aktorów, którzy korzystają (otrzymują kwant funkcjonalności) z danego przypadku użycia. Ważne jest także werbalne przedstawienie scenariuszy: głównego i alternatywnych, jakie są realizowane przez przypadek użycia. Dodatkowo w dokumentacji przypadku użycia należy zamieścić opis warunków początkowych dla przypadku użycia oraz podać nazwy związków rozszerzenie i zawierania. Zgromadzenie w jednym miejscu tych informacji ma na celu lepsze i dokładniejsze zrozumienie funkcji, jakie pełni w systemie dany przypadek użycia oraz ukierunkowuje projektanta systemu na jego dalsze postępowanie w kolejnych fazach projektu.
4.2 Model analityczny
W środowisku Rational Software Architect model analityczny jest oddzielnym plikiem bazującym na wzorcu Analysis Model Template lub na Enterprise IT Design Model Template. Pierwszy wzorzec wymaga ręcznego przeniesienia zdefiniowanych artefaktów do dalszego uszczegóławiania w modelu projektu. Korzystając ze wzorca Enterprise IT Design Model Template po zdefiniowaniu elementów kandydujących do projektowania następuje ich uszczegóławianie aż w konsekwencji otrzymywany jest model projektu. Innym rozwiązaniem jest połączenie przedstawionych dwóch rozwiązań i utrzymywanie w jednym pliku takiej samej struktury modelu zarówno w modelu analitycznym jak i w modelu projektu (w wybranym katalogu z zaznaczonym stereotypem <<analysis>>).
Model analityczny jest pierwszym krokiem na drodze od wymagań do projektu. Zawiera w sobie informacje analityczne dotyczące procesów biznesowych a także pozwala na uszczegółowienie istotnych przypadków użycia. Model analityczny jest agregatem abstrakcji wysokiego poziomu, które są kandydatami na elementy projektowe. Zasadniczym celem budowy modelu analitycznego jest uszczegółowienie środowiska, w którym system będzie pracował.
W modelu analitycznym powinny znaleźć się pakiety obszarów funkcjonalnych, które nazwami odpowiadają nazwom zdefiniowanym w modelu przypadków użycia. Wspomniane pakiety są agregatami klas oraz realizacji przypadków użycia, które są używane w projekcie systemu.
W prezentowanym przykładzie wybrano budowę oddzielnego repozytorium dla modelu analitycznego i następnie doprecyzowanie tych elementów w modelu projektu.
Zbudowany nowy model analityczny oparto o Analysis Model Template (rys. 8), który zawiera dwa pakiety.
rys. 8 Struktura modelu analitycznego
Należy zauważyć, że istnieje szereg różnych wariantów struktury modelu analitycznego, które szerzej zostały opisane [11]. W niniejszej publikacji opisano tylko wybrany wariant.
rys. 9 Elementy składowe modelu analitycznego
W pakiecie Analysis Building Blocks tworzone są pakiety, których nazw powinny odpowiadać pakietom utworzonym w modelu przypadków użycia. W każdym tak utworzonym pakiecie należy umieścić realizacje odpowiednio stereotypowane klasy, które biorą udział w realizacji odpowiedniego przypadku użycia. Wspominane klasy powinny posiadać stereotypy Entity gdy klasa reprezentuje dane, Control gdy jest to klasa sterująca i Boundary w przypadku klasy reprezentującej interfejs.
Natomiast realizacje przypadków użycia powinny znaleźć się w oddzielnym pakiecie także pogrupowane w odpowiednie pakiety. W Rational Software Architect pakiety funkcjonalne są reprezentowane przez elementy współpracy (ang. Collaborations), które mają stereotyp << use-case realizations>> (rys. 9). Nazwy realizacji przypadków użycia powinny odpowiadać nazwom przypadków użycia, których realizacje reprezentują.
Kolejnym działaniem jest odpowiednie wypełnienie modelu analitycznego. W przypadku opisywanego środowiska zasadą jest, że:
- każdemu przypadkowi użycia powinna odpowiadać jedna klasa sterująca;
- każdej relacji pomiędzy przypadkiem użycia a aktorem powinna towarzyszyć klasa graniczna, która reprezentuje interfejs;
- należy zdefiniować klasy danych i sterujące, odpowiadające wymaganej funkcjonalności systemu.
Kolejnym krokiem jest zdefiniowanie relacji pomiędzy przypadkiem użycia a jego realizacją. Zależność tę można przedstawić na diagramie umieszczonym w realizacji przypadku użycia (rys. 10).
rys. 10 Realizacja przypadków użycia
Ostatnim i najważniejszym krokiem tworzonego modelu analitycznego jest zdefiniowanie diagramów uszczegóławiających realizacje przypadków użycia. W Rational Software Architect można użyć do tego celu diagramu sekwencji, komunikacji, aktywności, stanów maszyny, struktury oraz diagramów klas. W omawianym przykładzie zbudowano diagram klas, aktywności i sekwencji.
rys. 11 Diagram klas VOPC przypadku użycia „Potwierdź dostawę”
Przykładowy diagram sekwencji prezentuje scenariusz potwierdzenia zapłaty (rys. 12). Należy zauważyć, że w odróżnieniu od diagramów sekwencji tworzonych przy użyciu języka UML 1.x na tym diagramie jest zawarty więcej niż jeden scenariusz [7]. Uwzględniono także równoległy przepływ komunikatów.
rys. 12 Przykładowy diagram sekwencji
Ciąg dalszy tego tekstu już za około 2 tygodnie…..
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
