| Projektowanie i kodowanie aplikacji w zintegrowanym środowisku programistycznym |
|---|
| Napisane przez Mon 27 Mar 2006 przez Artur (8832 cztane) |
|
Autor: Michał Wolski Kontakt: [email protected] Streszczenie Artykuł ten ma na celu przedstawienie zintegrowanego środowiska programistycznego, które umożliwia projektowanie i kodowanie aplikacji bez potrzeby przełączania się pomiędzy dwoma różnymi narzędziami. Zaprezentowane rozwiązanie pokazuje proces wytwarzania na przykładzie prostej aplikacji ASP.NET, którą zbudowano za pomocą Microsoft Visual Studio .NET oraz IBM Rational XDE. Przedstawiono strukturę projektu, sposoby synchronizacji kodu programu z modelem oraz sposób uzyskania zgodności pomiędzy elementami modelu a bazą danych. 1. Wprowadzenie Tworzenie nowoczesnych i złożonych rozwiązań informatycznych wymaga wsparcia coraz to bardziej zaawansowanych narzędzi CASE. W trakcie budowy oprogramowania, powstaje wiele artefaktów takich jak kod źródłowy, dokumentacja czy modele i diagramy. Obecnie jednym z najbardziej palących problemów inżynierii oprogramowania jest utrzymywanie spójności między artefaktami projektu [HAPK2003]. Główną przyczyna tego stanu rzeczy jest brak integracji pomiędzy narzędziami wspomagającymi wytwarzanie aplikacji. Projekt systemu, wraz z dokumentacją i modelami UML, powstaje w zupełnie innym środowisku niż implementacja systemu. W takiej sytuacji utrzymywanie spójności pomiędzy kodem programu a opisującymi go diagramami UML sprawia dużo trudności. Każda ręczna synchronizacja, po każdej zmianie czy to w projekcie, czy to w programie, zabiera dwie cenne rzeczy: czas i pieniądze. Celem artykułu jest prezentacja możliwości uniknięcia wspomnianych trudności, poprzez zastosowanie zintegrowanych narzędzi programistycznych, które umożliwiają jednoczesne projektowanie i kodowanie aplikacji wraz z utrzymywaniem pełnej synchronizacji pomiędzy wytworzonym kodem programu a diagramami UML. Przykładem środowiska programistycznego, umożliwiającego jednoczesne tworzenie modeli UML i kodowanie aplikacji z zachowaniem pełnej synchronizacji pomiędzy tymi dwoma elementami, jest użycie Microsoft Visual Studio .NET w połączeniu z IBM Rational XDE (eXtended Development Environment). Narzędzia te, dzięki całkowitej integracji, pozwalają zespołowi projektowemu na wydajne tworzenie oprogramowania. Umożliwiają na zachowanie najlepszych praktyk projektowych oferowanych przez Rational Unified Process oraz na korzystanie z zasobu doświadczeń w dziedzinie narzędzi developerskich firmy Microsoft. Artykuł opisuje sposób wytwarzania oprogramowania przy wykorzystaniu zintegrowanego środowiska oferowanego przez Microsoft Visual Studio .NET (VS.NET) i IBM Rational XDE (XDE). W kolejnych częściach zaprezentowano architekturę modelu UML stworzonego w XDE, sposób synchronizacji pomiędzy modelem opisującym implementację a kodem źródłowym programu oraz metodę uzyskania zgodności pomiędzy bazą danych a projektem. Wskazano również technikę umożliwiającą zaimportowanie projektów z programu IBM Rational Rose oraz sposób tworzenia modeli biznesowych. Dodatkowo przedstawiono możliwości opisywanego środowiska do przeprowadzenia inżynierii do przodu (ang. forward engineering) oraz inżynierii wstecz (ang. reverse engineering). Do prezentacji potencjału użytych narzędzi posłużono się procesem wytwórczym, prostej aplikacji ASP.NET wspomagającej ewidencję studentów. Przykład ten, ze względów oczywistych, został zaprezentowany w dużym uproszczeniu i nieco fragmentarycznie. 2. Projektowanie aplikacji Projektowanie aplikacji, czy to za pomocą flamastra na tablicy, czy to przy użyciu zaawansowanych narzędzi CASE, zazwyczaj wspomaga zespół projektowy w czasie budowy aplikacji. Rozpoczęcie tego procesu przy użyciu połączonych sił Visual Studio i Rational XDE oznacza, w pierwszej kolejności stworzenie nowego lub uruchomienie już z istniejącego projektu w VS.NET, co umożliwia budowę architektury projektowej. 2.1. Architektura projektowa Architektura projektowa w Rational XDE odbiega od znanej z Rational Rose struktury projektu. Różnice nie polegają na artefaktach a na sposobie ich wytworzenia. W Rose istnieje w jednym pliku struktura pozwalająca na zgromadzenie w nim całego repozytorium bez podziału na pakiety kontrolowane. Natomiast w XDE nie mamy widoków a jedynie w oddzielnych plikach modele [RUP2003a]. Metodyka Rational Unified Process [RUP2003], którą wspiera XDE, dopuszcza zastosowanie kilkunastu różnych modeli. W zależności od potrzeb projektowych można zastosować: • 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ą: • logiczny model bazy danych (ang. Logical Data Model) - opcjonalny, • fizyczny model danych (ang. Physical Data Model), • model dziedziny (ang. Domain Model) - opcjonalny. Metodyka RUP pozwala na wybranie elementów potrzebnych do wykonania projektu aplikacji. W przedstawianym przykładzie struktura projektu składa się z modelu przypadków użycia, modelu projektu, fizycznego modelu bazy danych oraz modelu wdrożenia. Ostatnim elementem, jest model kodu, który powstaje automatycznie poprzez synchronizację z kodem programu. Pliki reprezentujące model znajdują się w oknie Solution Explorer. Klikniecie w dowolnie wybrany plik z rozszerzeniem .mdx powoduje uruchomienie się okna Model Explorer, w którym znajdują się modele, pakiety, diagramy i elementy UML. Rysunek 1 pokazuje strukturę projektu w Visual Studio wraz z plikami XDE oraz architekturę projektową UML. Rys. 1. Widok struktury plików projektu (Solution Explorer) i modeli UML (Model Explorer) 2.2. Modelowanie Modelowanie w XDE może przebiegać na dwa sposoby. Pierwsza metoda opiera się na tradycyjnym tworzeniu kolejnych diagramów. Ta metoda jest efektywna, gdy zespół projektowy od samego początku decyduje się na modelowanie w XDE. Ale co zrobić gdy najpierw, z różnych względów, modele są tworzone w Rational Rose? W takim przypadku należy zastosować drugą technikę i dokonać importu modelu Rose do XDE. 2.2.1 Importowanie projektu wykonanego w Rose do XDE Przy importowaniu projektów Rose do projektów XDE należy pamiętać o dwóch sprawach. Po pierwsze XDE nie zawiera diagramów współdziałania (ang. Collaboration Diagram), tak więc one nie zostaną przeniesione. A po drugie importowanie plików odbywa się tylko w jedna stronę tzn. z Rose do XDE. Po dokonaniu przeniesienia projektów, nie można po jakimś czasie pracy w XDE wrócić z nowymi elementami na platformę Rose. Poniższy opis migracji z Rose do XDE pokazuje jak łatwo jest zintegrować projekty w jedną całość: W pierwszej kolejności w pasku narzędziowym należy wybrać File następnie opcję Open a potem znowu File. Kolejną czynnością jest wybranie i wczytanie odpowiedniego pliku Rose (z rozszerzeniem mdl). Ostatnim krokiem jest zapamiętanie projektu Rose jako projekt XDE. W tym celu należy przejść do okna Model Explorer i tam trzeba zaznaczyć poprzez kliknięcie nazwę otwartego projektu Rose a potem w pasku narzędziowym wybrać File potem Save nazwapliku.mdl.mdx. Następnie należy już tylko zatwierdzać wybrane przez program opcje. W oknie Model Explorer powinien pokazać się importowany projekt. 2.2.2. Inżynieria do przodu Zgodnie z tym co wspomniano wcześniej poza importem pliku istnieje tradycyjna metoda wytwarzania projektu aplikacji. Tą właśnie drogą posłużono się tworząc prezentowaną przykładową aplikację. Rys. 2. Struktura modelu przypadków użycia Proces tworzenia modeli, w opisywanym przykładzie, rozpoczęto od wytworzenia modelu przypadków użycia (ang. Use Case Model) a w nim przypadków użycia (ang. Use Cases) i aktorów (ang. Actors). Struktura modelu przypadków użycia w XDE jest dowolna i zależy tylko od zespołu projektującego, gdyż do stworzenia tego modelu używa się wzorca pustego modelu (ang. Blank Model). Przykładową strukturę modelu przypadków użycia pokazano na rysunku 2. Rys. 3. Diagram przypadków użycia Końcowym i najważniejszym artefaktem modelu przypadków użycia jest przedstawiony na rysunku 3 diagram przypadków użycia. Następnym etapem jest tworzenie modelu projektowego. Model projektowy stanowi uszczegółowienie modelu przypadków użycia. Wzorzec projektowy co widać na rysunku 4, umożliwia tworzenie wielowarstwowej struktury aplikacji. Rys. 4. Struktura modelu projektowego z przykładowymi klasami w warstwie Business Stosowanie wielowarstwowej architektury aplikacji jest najlepszym rozwiązaniem umożliwiającym efektywne tworzenie aplikacji webâowych, w tym ASP.NET. Każda z czterech warstw charakteryzuje następującymi właściwościami: • Warstwa prezentacji (ang. Presentation Layer) jest odpowiedzialna za komunikację użytkownika z systemem. Znajdują się tu klasy specyfikujące strony aspx. • Warstwa usług (ang. Business Layer) zawiera klasy, które sterują aplikacją i odpowiadają za jej działanie. Poziom ten stanowi most pomiędzy warstwami danych i prezentacji. • Warstwa danych (ang. Integration Layer) reprezentuje bazę danych. • Warstwa wspólna (ang. Common Elements Layer) zawiera elementy, z których korzystają klasy zawarte w poprzednich trzech warstwach Zastosowanie powyższej techniki podczas modelowania aplikacji webâowych z powodzeniem zastępuje występujący Rational Rose Diagram Trójwarstwowy (ang. Three-Tier Diagram). Szczegółowe informacje na temat budowy wielowarstwowych aplikacji znajdują się w [RUP2003] oraz w [EELE2001]. Na rysunku 4, poza pakietami tworzącymi warstwy, znajduje się pakiet zawierający uszczegółowienie przypadków użycia - Use-Case Realization. Pakiet ten zawiera realizacje przypadków użycia (ang. Use-Case Realizations), które za pomocą diagramów klas i sekwencji oraz aktywności opisują przypadki użycia. Rys. 5. Przykładowy diagram sekwencji Rysunki 5 i 6 prezentują przykładowe diagramy znajdujące się w opisywanym pakiecie. Przedstawione diagramy są częścią realizacji przypadku użycia o nazwie Zarządzaj danymi o studentach. Zaprezentowany na rysunku 5 diagram sekwencji realizuje scenariusz dodania do bazy danych informacji o studencie. Rys. 6. Przykładowy diagram klas Ostatnim elementem, jaki zostanie przedstawiony w tym punkcie, jest model wdrożenia. Model ten, zawiera węzły i połączenia między nimi, które reprezentują konfigurację sieciową wdrażanego środowiska. Zazwyczaj model wdrożenia pokazuje także elementy, które będą wdrożone w węzłach. Dodatkowo w XDE stereotypami opisującymi węzły nie muszą być standardowe elementy, gdyż mogą je zastąpić albo zdefiniowane w środowisku rysunki, albo piktogramy, które doda projektant. Przykładowy diagram wdrożenia, wraz z indywidualnie dodanymi piktogramami, został przedstawiony na rysunku 7. Rys. 7. Przykładowy diagram wdrożenia Opis modelu wdrożenia kończy prezentacje modeli, w których nie ma synchronizacji pomiędzy diagramami a fizycznie zaimplementowanymi komponentami. Uzupełnieniu podlega jeszcze informacja dotycząca modelowania biznesowego (ang. Business Modeling), które stanowi integralną część Rational Unified Process. 2.2.3. Modelowanie biznesowe w XDE Modelowanie biznesowe nie jest wspierane przez XDE. W przypadku gdy istnieje potrzeba przeprowadzenia analizy biznesowej za pomocą XDE trzeba wytworzyć w Rational Rose po jednym elemencie z zachowaniem notacji modelowania biznesowego. Przede wszystkim należy stworzyć takie elementy jak biznesowe przypadki użycia (ang. Business Use-Case), aktorzy biznesowi (ang. Business Actors), cele biznesowe (ang. Business Goals), realizacje biznesowych przypadków użycia (ang. Business Use-Case Realizations) oraz systemy biznesowe (ang. Business System). Po kreacji wymienionych elementów należy dokonać importu pliku Rose do XDE. Dzięki temu projekt wykonywany w XDE zostanie wzbogacony o notację i stereotypy wspomagające analizę biznesową. 2.3. Modelowanie bazy danych Rational XDE wspiera takie bazy danych jak: • IBM DB2 UDB 5.x, 6.x, and 7.0 and OS390 (MVS) 5.x and 6.x • Oracle 7.x, 8.x, and 9i • Microsoft SQL Server 6.5, 7.0, and 2000 • Sybase Adaptive Server 12.x Do modelowania bazy danych w XDE można zastosować model logiczny, fizyczny i dziedziny. W prezentowanej, przykładowej aplikacji wykorzystano tylko fizyczny model danych, gdyż w opisywanym banalnym systemie użycie większej ilości modeli, opisujących bazę danych, nie znajduje uzasadnienia. 2.3.1 Modelowanie danych w inżynierii do przodu XDE oferuje dwa rodzaje sposobów tworzenia modelu bazy danych. Pierwszy stanowi inżynierię do przodu a drugi inżynierię wstecz. Stosowanie obu metod wraz z synchronizacją pomiędzy modelem a fizycznie istniejąca bazą danych jest ułatwione poprzez odpowiedni kreator. Wsparcie narzędzi w dziedzinie pełnej integracji jest tak daleko posunięte, że już kilka, kilkanaście kliknięć myszką umożliwia tworzenie w pełni zsynchronizowanych projektów. Przykładem realizacji, w kilku krokach, synchronizowanego modelu z bazą danych jest poniższy opis. Pierwszym krokiem jest stworzenie na serwerze bazodanowym bazy danych o nazwie ES_BazaDanych. Kolejnym krokiem, jaki powinno się wykonać chcąc stworzyć bazę danych na podstawie klas UML, jest stworzenie klas w wybranym katalogu. Potem należy ustawić stereotyp klas na table oraz utwardzić klasy poprzez zmianę parametru Persistence z Transient na Persistent. Następnie do projektu trzeba dodać komponent o nazwie Database. Potem należy w nim zmienić typ bazy danych na SQL Server 2000 oraz nazwę na ES_BazaDanych. Następnym krokiem jest dołączenie zależności Database Realization, w ten sposób, że komponent Database realizuje każdą z tabel. Przedostatnim krokiem jest zdefiniowanie w każdej z tabel kolumny primary key. Następnie należy uruchomić kreatora poprzez klikniecie prawym klawiszem na dodany przed chwilą komponent Database i wybranie z menu podręcznego Data Modeler a potem Forward Engineer. Kolejnym etapem jest wybranie parametrów zgodnie z rysunkiem 8. Rys.8. Tworzenie fizycznej bazy danych Na rysunku 9 przedstawiono widok fizycznego modelu danych oraz widok serwera, na którym znajduje się, stworzona w procesie inżynierii do przodu, baza danych. Rys. 9. Baza danych (Server Explorer) i fizyczny model bazy danych (Model Explorer) 2.3.2. Pozostałe metody synchronizacji modelu z bazą danych W opisywanym zintegrowanym środowisku programistycznym modelowanie danych w inżynierii wstecz polega na tym, że z gotowej bazy danych za pomocą kreatora tworzy się fizyczny model danych odpowiadający faktycznie istniejącej bazie danych. Uzyskany w ten sposób model UML znajduje się repozytorium projektowanej aplikacji. Synchronizacja również polega na użyciu kreatora, który w kilku krokach doprowadza do pełnej synchronizacji pomiędzy bazą danych znajdującą się na serwerze a fizycznym modelem bazy danych. Bliższe informacje na temat synchronizacji i modelowania baz danych przy wykorzystaniu XDE i Visual Studio można znaleźć w [FRAN2003] i [KUSL2003]. 3. Kodowanie aplikacji Kodowanie aplikacji w zintegrowanym środowisku programistycznym, jakie stanowi połączenie Visual Studio .NET i Rational XDE opiera się głównie na wykorzystywaniu platformy .NET. VS.NET oferuje deweloperom możliwość programowania w kilku językach takich, jak: Visual Basic, Visual C++, C# czy J#. Do wyboru jest także kilkanaście różnych szablonów, które pozwalają budować wydajne aplikacje przeznaczone na standardowe komputery oraz urządzenia przenośne typu PocketPC. Wzorce pomagają tworzyć rozwiązania oparte m.in. na technologiach ASP.NET, XML i Web Services. Prezentowana przykładowa aplikacja „Ewidencja Studentów” wykonana w technologii ASP.NET została zbudowana na podstawie modeli wykonanych w XDE. Językiem w jakim zaimplementowano ten system jest C#. Rys. 10. Fizyczna struktura plików w projekcie Zastosowanie wielowarstwowej struktury aplikacji umożliwiło rozgraniczenie kompetencji zbudowanych klas. Na rysunku 10 widać to, w ten sposób, że wszystkie klasy odpowiedzialne za obsługę interfejsu użytkownika znajdują się w plikach posiadających rozszerzenie .aspx. Klasy te zostały zbudowane na podstawie klas zamieszczonych w warstwie prezentacji modelu projektowego. Klasy z zaprojektowanej warstwy usług (model projektu) zostały zaimplementowane w plików z rozszerzeniem .cs, które znajdują się w katalogu Usługi. Natomiast, implementacja klas znajdujących się w warstwie danych, polega na stworzeniu na serwerze bazodanowym odpowiednich tabel, co zostało opisane w wcześniejszych częściach niniejszego artykułu. 4. Synchronizacja kodu aplikacji z modelem UML Wzajemna współpraca XDE z VS.NET zaowocowała możliwością pełnej synchronizacji kodu źródłowego aplikacji z modelem UML. Jest to chyba jedna z najważniejszych cech, jakie posiada opisywane środowisko programistyczne. Rys. 11. Synchronizacja kodu aplikacji z modelem UML Synchronizację można przeprowadzić w każdym momencie budowania kodu aplikacji, nawet tuż zaraz po stworzeniu projektu. Jest to czynność bardzo prosta, gdyż jak to zostało pokazane na rysunku 11, wymaga tylko jednego kliknięcia. Wynikiem synchronizacji jest model kodu, który został przedstawiony na rysunku 13. Model kodu zawiera trzy foldery. W katalogu Artifacts znajdują się pliki i katalogi, które są artefaktami wytworzonymi w procesie implementacji aplikacji. 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 Student, która została określona poprzez pakiet Student. Ostatnim folderem występującym modelu kodu jest pakiet References, który zawiera powiązania z innymi przestrzeniami nazw. Rys.13. Fragment struktury modelu kodu Z racji tego, że przykładowym programem jest aplikacja 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. Rysunek 14 szczegółowo pokazuje fragment zawartości pakietu Student. Rys. 14. Szczegółowa zawartość fragmentu przestrzeni nazw Student wraz z opisem elementów Zastosowanie wielu stereotypów do określenia budowanych komponentów pozwala na tworzenie przejrzystych diagramów kodu. Przykładowy diagram kodu pokazano na rysunku 15. Rys. 15. Diagram kodu 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. W opisywanym środowisku programistycznym w celu uzyskania zgodności pomiędzy kodem źródłowym aplikacji a modelem kodu możemy zastosować również inżynierię wstecz oraz posiadając model kodu, inżynierię do przodu. Te sposoby synchronizacji zostały szczegółowo przedstawione w [RATI2003]. 5. Podsumowanie W artykule zostało przedstawione, oparte na Visual Studio .NET i Rational XDE, zintegrowane środowisko programistyczne, które umożliwia jednoczesne projektowanie i kodowanie aplikacji bez potrzeby przełączania się pomiędzy dwoma niepowiązanymi ze sobą narzędziami. Na zaprezentowanym przykładzie aplikacji ASP.NET pokazano możliwości tworzenia modeli UML oraz kodu programu. Wskazano także techniki budowania architektury projektu. Omawiając model fizyczny danych pokazano, w jaki sposób, korzystając z inżynierii do przodu, zbudować tabele w istniejącej fizycznie bazie danych. Ponadto przedstawiono sposoby synchronizacji kodu aplikacji z modelem UML. Zaprezentowane środowisko pozwala na korzystanie z dobrych praktyk oferowanych przez Rational Unified Process. Ponadto projektanci mogą używać kilku języków programowania oraz kilkunastu szablonów projektowych. Do dyspozycji są też cztery rodzaje relacyjnych baz danych. Umożliwienie projektowania a potem implementacji wielowarstwowych aplikacji pozwala na przejrzyste i wydajne tworzenie komponentów systemu. Do głównych zalet, prezentowanego środowiska, należy inżynieria dwustronna, która umożliwiająca zarówno generację kodu z modelu (inżynieria do przodu), jak również generację modelu w oparciu o kod systemu (inżynieria wstecz). Umożliwienie pełnej synchronizacji nie tylko pomiędzy aplikacją a modelem kodu, ale także pomiędzy modelem danych a bazą danych stanowi siłę przedstawianego rozwiązania. Wydaje się, że stosowanie zintegrowanego środowiska programistycznego, w którym możemy projektować i kodować aplikacje, stanowi technologię przyszłości. Bibliografia [EELE2001] Eeles P., Layering Strategies, Rational Software, 2001. [FRAN2003] Franklin S., Data Modeling in Rational XDE Release 2, www.rational.net, 2003. [HAPK2003] Hapke M., Jaszkiewicz A., Kowalczykiewicz K., Weiss D., Zielniewicz P. OPHELIA - zintegrowane środowisko wytwarzania oprogramowania. V Krajowa Konferencja Inżynierii Oprogramowania, Szklarska Poręba, 2003. [KUSL2003] Kuslich J., Data Modeling in Rational XDE Release 2: A Guide for Visual Studio .NET Developers, www.rational.net, 2003. [RATI2003] IBM Rational XDE Developer v2003 — .NET Edition - Evaluators Guide, Rational Software, www.rational.net, 2003. [RUP2003] Rational Unified Process, wersja 2003.06.00 [RUP2003a] Model Structure Guidelines for Rational XDE Developer - .NET Edition, Rational Unified Process, wersja 2003.06.00 |
| Indeks :: Drukuj :: E-mail |
Komentarze są własnością ich autorów. Nie ponosimy odpowiedzialności za ich treść.