W artykule przedstawiono opis pakietu narzędziowego VS.NET (Microsoft) z Rational XDE (IBM) do wytwarzania aplikacji webowych pracujących w środowisku urządzeń mobilnych na platformie .NET (firmy Microsoft) z wraz z metodyką jego użycia bazującą na procesie wytwórczym Rational Unified Process. Przedstawiono w nim strukturę i opis metodyki tworzenia projektów w XDE. Szczególną uwagę poświęcono nowym funkcjom środowiska XDE pozwalającym na badanie własności behawioralnych aplikacji. Opis procesu wytwórczego zilustrowano na przykładzie aplikacji czasu rzeczywistego zaimplementowanej w ASP.NET a przeznaczonej na PocketPC.
1 Wprowadzenie
Zintegrowane środowiska wytwórcze łączą w sobie cechy narzędzi Upper i Lower CASE, które umożliwiają zarówno analizę, projektowanie jak i kodowanie aplikacji (na przykład webowych itp.) bez potrzeby przełączania się między nimi. Jednym z takich rozwiązań jest połączenie Microsoft Visual Studio .NET z IBM Rational XDE. Zintegrowanie tych dwóch narzędzi umożliwia zbudowanie jednego repozytorium systemu zawierającego jego projekt wraz z implementacją.
Do zaprezentowania możliwości opisywanego środowiska w tworzeniu aplikacji webowych dla reaktywnych systemów mobilnych posłużono się przykładem Systemu Wspomagania Obsługi Rozliczeń za Parkowanie – „Parkingowy”.
W systemie „Parkingowy” istotne są trzy zdarzenia zachodzące w czasie parkowania. Są nimi: wjazd na parking, opłata za parkowanie i wyjazd. Czas każdego z wymienionych zdarzeń może być odnotowany przez system po przesłaniu danych pojazdu lub numeru biletu przez bramkę, automat czy człowieka.
Rys.1.1 Zdarzenia w systemie „Parkingowy”
W prezentowanym przykładzie techniczną realizację systemu zaimplementowano na platformie mobilnej PocketPC z wbudowanym systemem łączności radiowej (ang. wireless)[1].
Aplikacja została tak zaprojektowana by opłata za parkowanie (wzór1.1) była uiszczana przy pojeździe w chwili odjazdu lub przy wejściu kierowcy na teren parkingu. Takie rozwiązanie ułatwia rozliczanie oraz zapobiega kolejkom, które mogą się tworzyć przy bramce wyjazdowej.
Opłata = stawkaZaJednostkęCzasu*(tozp – twnp) (1.1)
Przedstawiony problem projektowy wymusza rozwiązanie przez system zadania uwarunkowanego czasowo, jakim jest określenie sprawdzenie nierówności Dt-Dtmax>0; gdzieDtmax=twyj-tozp; aDt – czas potrzebny na wyjechanie z parkingu po dokonaniu zapłaty. Czas ten, w zależności od wielkości parkingu, może być różny, wahając się od kilku do kilkunastu minut.
Dodatkowo aplikacja umożliwia rejestrowanie w czasie utargu z dowolnej bramki.
2 Struktura projektu
Istotną cechą struktury projektu w opisywanym środowisku, jest podział modeli na pakiety kontrolowane – minimalne współużytkowane przez udziałowców elementy systemu stanowiące jego zasoby. W odróżnieniu od Rational Rose, w którym istnieje również możliwość tworzenia pakietów kontrolowanych, w XDE nie mamy widoków a jedynie w oddzielnych plikach modele [6]. Każdy z modeli stanowi samodzielny pakiet, który jest powiązany z innym modelem tylko w sposób koncepcyjny.
Do budowy architektury projektu zgodnej z metodyka Rational Unified Process [7], którą wspiera XDE, można zastosować następujące modele:
– model przypadków użycia (ang.Use Case Model),
– model analizy (ang.Analysis Model) – opcjonalny,
– model projektu (ang.Design Model),
– model implementacji (ang.Implementation Model),
– model wdrożenia (ang.Deployment Model),
– model kodu (ang.Code Model).
Natomiast do modelowania bazy danych zastosowanie znajdują:
– model dziedziny (ang.Domain Model) – opcjonalny,
– logiczny model bazy danych (ang.Logical Data Model) – opcjonalny,
– fizyczny model danych (ang. Physical Data Model).
Rys.1.2 Architektura projektu „Parkingowy”
Metodyka RUP pozwala na wybranie tych modeli, które w najlepszy sposób przedstawiają system. W przykładowej aplikacji webowej budowanej na urządzenie przenośne strukturę projektu tworzą: model przypadków użycia, model projektowy, fizyczny model bazy danych, model wdrożenia oraz model kodu.
2.1 Model przypadków użycia
Rys.1.3 Diagram przypadków użycia dla systemu „Parkingowy”
Model przypadków użycia określa wymagania funkcjonalne stawiane systemowi oraz definiuje jego otoczenie [1]. W czasie jego budowania korzystając z takich elementów jak aktorzy (ang.Actors) oraz przypadki użycia (ang.Use Cases) powstaje diagram przypadków użycia (ang. Use Case Diagram). Metodyka tworzenia, w opisywanym zintegrowanym środowisku programistycznym, modeli przypadków użycia przebiega tak samo dla każdego typu aplikacji, w tym i aplikacji webowych na systemy mobilne.
W podanym przykładzie aplikacji, wspomagającej rozliczanie opłat za parkowanie w interakcję z systemem wchodzi trzech aktorów a funkcjonalność systemu została opisana poprzez cztery przypadki użycia.
2.2 Model projektu
Model projektu stanowi uszczegółowienie modelu przypadku użycia. Zastosowanie wielowarstwowej architektury modelu projektu, jest istotnym czynnikiem wspomagającym efektywne tworzenie aplikacji webowych.
Na diagramie (rys. 1.4) przedstawiono wielowarstwowy model architektury systemu „Parkowanie” którą tworzą cztery warstwy:
A~?€Ë~ Warstwa prezentacji (ang.Presentation Layer) jest odpowiedzialna za komunikację użytkownika z systemem. Znajdują się tu klasy interfejsu (ang.Boundary Class), które specyfikują strony aspx,
A~?€Ë~ Warstwa usług (ang.Business Layer) zawiera klasy sterujące (ang.Control Class), które sterują aplikacją i odpowiadają za jej działanie. Poziom ten stanowi most pomiędzy warstwami danych i prezentacji,
A~?€Ë~ Warstwa danych (ang.Integration Layer) reprezentuje bazę danych i zawiera klasy danych (ang.Entity Class),
A~?€Ë~Warstwa wspólna (ang.Common Elements Layer) zawiera elementy, z których korzystają klasy zawarte w poprzednich trzech warstwach.
Rys.1.4Dekompozycja horyzontalna – podział na warstwy w XDE
Istotną cechą tak zdefiniowanej architektury jest to, że komponenty z jednej warstwy mogą współpracować tylko z komponentami z warstwy sąsiedniej [2]. Własność ta pozwala na wykorzystanie logiki biznesowej i warstw danych jako podstawy do zbudowania aplikacji webowych działających nie tylko na urządzeniach przenośnych, ale także w innych środowiskach. Z powyższych faktów wynika, że przy budowie aplikacji przeznaczonych na systemy mobilne, kluczowym elementem jest odpowiednia implementacja warstwy prezentacji, która pozwoli na odpowiednie wykorzystanie charakterystycznych cech systemów mobilnych.
Model projektowy poza podzielonymi na warstwy klasami zawiera uszczegółowienie przypadków użycia w postaci realizacji przypadków użycia (ang.Use Case Realizations). Uściślenie przypadków użycia jest przedstawione w postaci diagramów klas, aktywności i sekwencji. Poniższe rysunki (rys. 1.5i rys. 1.6) przedstawiają uszczegółowienie przypadku „Rozlicz parkowanie”.
Rys.1.5 Diagram klas wchodzący w skład realizacji przypadku „Rozlicz parkowanie”
Rys.1.6 Diagram sekwencji „Wjazd pojazdu na parking”
Na diagramie rys. 1.5zaprezentowano powiązania pomiędzy klasami: interfejsu – IParkingowy, sterowania – ParkingCTR i danych – Parkowanie. Natomiast diagram sekwencji (rys. 1.6) przedstawia scenariusz „Wjazd pojazdu na parking”
3 Możliwości zintegrowanego środowiska
Zintegrowanie Visual Studio .NET z Rational XDE w jedno środowisko programistyczne umożliwiło, w każdym momencie, synchronizacji modelu z jego implementacją oraz możliwość śledzenia rozwiązania na „poziomie obiektów projektowych”.
3.1 Synchronizacja modelu z baza danych
Zastosowanie zintegrowanego narzędzia wytwórczego opartego na VS.NET i XDE pozwala na posiadanie repozytorium projektu modelu bazy danych, który jest w pełni zsynchronizowany z fizycznie istniejącą bazą danych. Jest to pierwsza własność opisywanego środowiska, która pozwala na posiadanie pełnej i kompletnej dokumentacji bez potrzeby ponoszenia dodatkowych kosztów czasowych i finansowych.
Rys.1.7 Baza danych (Server Explorer) i fizyczny model bazy danych (Model Explorer)
W prezentowanym przykładzie, zastosowanie metod inżynierii w przód (ang. forward engineering) pozwoliło na wygenerowanie, na podstawie modelu fizycznej bazy danych, odpowiedniej struktury tabel na serwerze bazodanowym (rys. 1.7). Dodatkowo, przy użyciu odpowiednich kreatorów, opisywane środowisko umożliwia uzyskanie zgodności pomiędzy modelem bazy danych z jego implementacja za pomocą inżynierii wstecz (ang.reverse engineering) i synchronizacji [3] i [4].
3.2 Sychronizacja modelu z jego implementacją
Wzajemna współpraca XDE z VS.NET zaowocowała możliwością pełnej synchronizacji kodu źródłowego aplikacji z modelem UML.
Wynikiem synchronizacji jest model kodu (rys. 1.8). Model kodu zawiera trzy foldery. W katalogu Artifacts znajdują się pliki i katalogi, które są artefaktami wytworzonymi w procesie implementacji aplikacji. W plikach tych znajdują się klasy odpowiedzialne za interfejsy i usługi aplikacji. Wszystkie klasy składające się na budowaną aplikację znajdują się w przestrzeni nazw Parking, która została określona poprzez pakiet Parking. Ostatnim folderem występującym modelu kodu jest pakiet References, który zawiera powiązania z innymi przestrzeniami nazw. Jak już wspomniano, synchronizacji kodu z modelem można dokonać w dowolnym momencie. Dodatkowo można tak dostosować narzędzie by samo dokonywało automatycznej synchronizacji, która może mieć miejsce po każdej zmianie czy to w kodzie programu, czy to w modelu.
Rys.1.8 Fragment modelu kodu
Rys.1.9 Przykładowy diagram kodu systemu „Parkingowy”
Z racji tego, że przykładowym programem jest aplikacja webowa korzystająca z ASP.NET, w zdefiniowanej przestrzeni nazw znajdują się nie tylko klasy, ale dzięki stereotypom wyszczególnione są także inne elementy wchodzące w skład budowanego systemu. Diagram kodu (rys. 1.9) prezentuje zależności pomiędzy elementami wchodzącymi w skład modelu kodu.
3.3 Automatyczne tworzenie diagramów sekwencji
Opisywane zintegrowane środowisko wytwórcze posiada bardzo interesującą cechę a mianowicie jest w stanie wygenerować w czasie rzeczywistym diagram sekwencji. Diagram ten powstaje na podstawie kodu źródłowego w trakcie działania aplikacji. Możliwości te są dostępne dzięki zastosowaniu Visual Trace, które jest integralnym składnikiem IBM Rational Developer Plus. Diagramy sekwencji wygenerowane za pomocą tego narzędzia w odróżnieniu od tradycyjnie zbudowanych diagramów noszą nazwę śladowego diagramu sekwencji (ang. trace sequence diagram) [5]. Visual Trace pozwala na wygenerowanie diagramu zarówno z aplikacji Windows jak i web
owych. Zbudowany w czasie rzeczywistym śladowy diagram sekwencji zawiera typowe elementy znane z UML takie jak obiekty, linie życia i komunikaty.
Rys.1.10 Śladowy diagram sekwencji – „Wjazd pojazdu na parking”
Na przedstawionym przykładzie (rys. 1.10) można zobaczyć, że czas każdej czynności został zmierzony z dokładnością do tysięcznych części sekundy. Jest to cecha bardzo istotna przy testowaniu i tworzeniu dokumentacji systemów czasu rzeczywistego. Porównując diagram sekwencji (rys. 1.6) z śladowym diagramem sekwencji (rys. 1.10), można stwierdzić, że choć oba diagramy opisują ten sam scenariusz (Wjazd pojazdu na parking) to uwypuklają aspekt behawioralny na różnych poziomach abstrakcji. Diagram sekwencji (rys. 1.6) przedstawia model konceptualny scenariusza głównego usługi „Wjazd pojazdu na parking”. Natomiast śladowy diagram sekwencji ilustruje w jaki sposób działa projektowany system.
Budowanie diagramów sekwencji za pomocą Visual Trace jest doskonałą metodą na uzupełnienie kodu i jego modelu o automatycznie uzyskiwane dynamiczne aspekty budowanego systemu w postaci śladowego diagramu sekwencji wykorzystującego standardową notację języka UML.
Teraz możesz zobaczyć jak budowane są te diagramy. Zobacz artykuł o budowie diagramów sekwencji w czasie rzeczywistym
4 Zakończenie
Przedstawione zintegrowane środowisko programistyczne pozwala na utrzymanie spójności między artefaktami projektu w całym procesie wytwórczym aplikacji. Łączne zastosowanie XDE i VS.NET umożliwia utrzymywanie w jednym repozytorium systemu modeli o różnym poziomie abstrakcji – od modelu koncepcyjnego (model przypadków użycia) po model prezentujący kod aplikacji (model implementacyjny). Dodatkowo synchronizacja kodu programu z jego modelem ułatwia zarządzanie zmianami w projekcie tworząc trwałą relację między nimi (tzw. „żywy kod”). Natomiast zastosowanie Visual Trace pozwala na uzyskanie wizualnej reprezentacji działania kodu źródłowego systemu. Cecha ta daje możliwość śledzenia rozwiązania na „poziomie obiektów projektowych”, co sprawia, że jest pożądanym rozwiązaniem do dokumentowania aspektów dynamicznych projektu po jego implementacji.
Powyższe cechy, łącznie z możliwością tworzenia repozytoriów wielokrotnego użycia, skłaniają do stwierdzenia, że skutecznym sposobem budowania aplikacji mobilnych może być wykorzystanie zintegrowanego środowiska XDE z VS.NET. Obecnie rozwiązanie to stanowić może alternatywę dla coraz bardziej popularnegoModel Driven Architecture(MDA).
Literatura
[1] Booch G., Rumbaugh J., Jacobson I.: UML przewodnik użytkownika, WNT, Warszawa 2003
[2] Eeles P., Layering Strategies, Rational Software, 2001
[3] Franklin S., Data Modeling in Rational XDE Release 2, www.rational.net, 2003
[4] Kuslich J., Data Modeling in Rational XDE Release 2: A Guide for Visual Studio .NET Developers, www.rational.net, 2003
[5] Kuslish J., Visual Trace and Asset Repositories in Rational XDE Developer v2003: A Guide for Visual Studio .NET Developers, www.rational.net, 2003
[6] Model Structure Guidelines for Rational XDE Developer – .NET Edition, Rational Unified Process, wersja 2003.06.00
[7] Rational Unified Process, wersja 2003.06.00
Dodawanie komentarzy zostało zablokowane.