Historia zmian. Data wersja Opis Autor. 05/05/ Paweł Maćkowski. 31/05/ Paweł Maćkowski

Transkrypt

1 System obsługi konferencji Software Architecture Document Wersja 0.4 Historia zmian Data wersja Opis Autor 05/05/ Paweł Maćkowski 31/05/ Paweł Maćkowski 04/06/ Uzupełnienie o przegląd przypadków użycia Marcin Potkański 04/06/ Dodanie modelu bazy danych Paweł Maćkowski

2 1. Wprowadzenie 1.1 Cel 1.2 Zakres 1.3 Definicje 1.4 Załączniki 1.5 Omówienie reszty dokumentu 2. Prezentacja architektury systemu 3. Założenia i zależności 4. Przegląd przypadków użycia 4.1 Opis przypadków użycia 4.2 Realizacje przypadków użycia 5. Dekompozycja logiczna systemu 5.1 Omówienie 5.2 Omówienie klas analitycznych 5.3 Najważniejsze komponenty 6. Dekompozycja na procesy 6.1 Proces aplikacji Java 6.2 Proces przeglądarki WWW 6.3 Proces serwera aplikacji JBoss 6.4 Proces bazy danych Oracle 7. Instalacja systemu 7.1 Omówienie 7.2 Wymagania sprzętowe 8. Implementacja systemu 9. Przechowywane dane 10. Wydajność systemu 10.1 Wymagania 10.2 Bezawaryjność 10.3 Rozwiązania sprzętowe 10.4 Rozwiązania programowe 11. Jakość 11.1 Bezpieczeństwo 11.2 Przeglądarki internetowe Spis treści

3 Software Architecture Document 1. Wprowadzenie Dokument ten zawiera szczegółową specyfikację przyjętej architektury programu. Na wiele odmiennych sposobów ukazana jest zarówno struktura implementacyjna, jak też logiczna całego prezentowanego systemu. 1.1 Cel Dokument ma na celu przedstawienie pełnego przeglądu systemu SOK. Dokument ten odpowiada na pytanie JAK zostanie zrealizowany system. Wszystkie wymienione w dokumencie założenia i wymagania powinny być bezwzględnie przestrzegane. 1.2 Zakres Niniejszy dokument zawiera opis sposobu implementacji, rodzaje przechowywanych danych, docelowe środowisko działania oraz przyjęte założenia dotyczące jakości systemu. 1.3 Definicje System Obsługi Konferencji - niniejszy projekt, aplikacja usprawniająca przeprowadzenie koferencji naukowej Spring framework - szkielet aplikacji, abstrakcja nad J2EE JBoss - serwer aplikacji J2EE komponenty EJB - elementy osadzane na serwerze J2EE i wołane zdalnie poprzez protokół RMI Subversion (svn) - system kontroli wersji 1.4 Załączniki Vision Technical Use Cases 1.5 Omówienie reszty dokumentu Reszta dokumentu zawiera szczegółową prezentację Systemu Obsługi Konferencji z pięciu perspektyw. Przedstawia zachowanie systemu z perspektywy przypadków użycia. Opisuje logiczną dekompozycję systemu oraz podział na procesy. Przedstawia sposób instalacji oraz oczekiwań wydajnościowych. Opisuje również dokładnie rodzaje przechowywanych danych.

4 2. Prezentacja architektury systemu Złożoność systemu wymaga zastosowania architektury wielowarstowej, z rozdzieleniem warstwy biznesowej od warstwy prezentacji. Jednym z wiodących standardów wspierających pisanie takich aplikacji jest J2EE (Java 2 Platform, Enterprise Edition). Uznaliśmy, że wybór tego standardu będzie najlepszym rozwiązaniem. Oczywiście za skrótem J2EE kryje się wiele alternatywnych rozwiązań. Nasze będzie wykorzystywało technologię EJB. Dodatkowo niektóre usługi zostaną udostępnione w postaci Web Services. Spośród wielu dostępnych na rynku serwerów aplikacji wybraliśmy serwer JBoss. Przy implementacji warstwy biznesowej wykorzystamy Springa, szkielet aplikacji stanowiący abstrakcję nad klasami umieszczanymi w kontenetrze. Dostęp do bazy danych będzie realizowany przez Jdbc Spring API oraz przez metody mapowania obiektowo-relacyjnego. Podczas implementacji zostanie ustalona jedna z metod: Hibernate lub ibatis SQL Maps. Dostęp do aplikacji będzie możliwy poprzez przeglądarkę internetową (dla uczestników i prelegentów) oraz poprzez aplikację kliencką (dla organizatorów). Warstwa prezentacji dla przeglądarki będzie napisana jako Java Server Pages (JSP). JSP będzie odpowiedzialne za wygląd aplikacji na stronie internetowej i komunikację z serwerem (wysyłanie i odbieranie komunikatów SOAP w przypadku Web Services lub wykonywanie metod w przypadku EJB). Standardowo razem z JSP będzie wykorzystany HTML i CSS. Natomiast aplikacja kliencka będzie napisana w Javie.

5 Poniższy rysunek przedstawia (uproszczoną) architekturę systemu: Przyjęcie powyższych rozwiązań pozwoli nam w znaczynym stopniu abstrahować od konkretnego wyboru bazy danych, którego jednak w końcu nie można uniknąć. W porozumieniu ze zleceniodawcą została wybrana baza danych Oracle. Część logiki biznesowej zostanie zaimplementowana w postaci procedur składowanych napisanych w języku PL/SQL. Aplikacja stworzona zostanie z wykorzystaniem szerokiej gamy narzędzi. Ich poznanie wymaga sporego wysiłku od programisty ale w zamian otrzymujemy możliwość napisania przejrzystego, funkcjonalnego i łatwo modyfikowalnego kodu. Będziemy postępować zgodnie z zasadą nie wyważania otwartych drzwi, czyli tam gdzie to możliwe będziemy korzystać z wcześniej sprawdzonych i przetestowanych metod czyli tzw. wzorców projektowych. Ponieważ projekt będzie tworzony przez grupę programistów,więc konieczne będzie zastosowanie systemu kontroli wersji ( nasz wybór - Subversion). Nasz produkt będzie korzystał z wielu darmowych bibliotek. Zarządzanie nimi ale także i samym projektem ułatwi nam kompleksowy system Maven2. Maven2 wymusza przyjęcie określonej struktury projektu, czyniąc go bardziej przejrzystym ale także uławia testowanie i bezbolesne przeniesienie aplikacji ze środowiska testowego na środowisko produkcyjne.

6 Szerzej architektura systemu została opisana w kolejnych rozdziałach: Perspektywa przypadków użycia Ta część dokumentu krótko opisuje przypadki użycia, które szczegółowo omówione zostaną w dokumencie Technical Use Case. Oprócz krótkiego opisu przedstawiona została realizacja tychże przypadków użycia w oparciu o klasy implementacyjne zdefiniowane w części omawiającej logiczną dekompozycję systemu. Dekompozycja logiczna systemu Opisuje podział systemu na pakiety/podsystemy wraz z przypisaniem ich do różnych warstw systemu. Podzielone pakiety są następnie podzielone na klasy analityczne. Perspektywa procesów Dzieli system na procesy (niezależne przebiegi sterowania). Implementacja W tym miejscu dokumentu znajduje się szczegółowy opis podziału systemu na klasy implementacyjne wraz z zaprojektowanymi metodami. Diagramy sekwencji przedstawione w tym punkcie prezentują realizację przypadków użycia w oparciu o opisane klasy. Instalacja Sugeruje poprawny sposób rozmieszczenia każdego z komponentów systemu, zawiera również opis wzorcowego przebiegu procesu instalacji. 3. Założenia i zależności dostęp do aplikacji będzie się odbywał poprzez stronę internetową i aplikację Java aplikacja będzie wykonana w języku Java wykorzystując do tego środowisko programistyczne Eclipse i framework Spring warstwa prezentacji testowana będzie w przeglądarkach Firefox oraz Internet Eplorer funkcjonalność systemu będzie testowana z wykorzystaniem narządzi junit

7 4. Przegląd przypadków użycia 4.1 Diagramy przypadków użycia Rejestracja Przeglądanie informacji o konferencji Wyświetlenie listy aplikacji

8 4.1.4 Wyświetlenie listy tutoriali Rejestracja na tutorial Recenzowanie Przeglądanie planu konferencji

9 4.1.8 Generowanie zapotrzebowania na noclegi i wyżywienie Stworzenie nowej konferencji Modyfikacja informacji o konferencji Odwołanie konferencji

10 4.2 Opis przypadków użycia Rejestracja Przypadek użycia opisuje proces rejestracji Użytkownika na konferencję Przeglądanie informacji o konferencji Przypadek użycia opisuje proces prezentacji informacji o konferencji naukowej Przeglądanie listy prelegentów Przypadek użycia opisuje proces prezentacji listy prelegentów Przeglądanie aplikacji prelegenta Przypadek użycia opisuje proces prezentacji aplikacji zgłoszonych przez Prelegenta Przeglądanie harmonogramu Przypadek użycia opisuje proces prezentacji harmonogramu Wyświetlenie listy aplikacji Przypadek użycia opisuje proces prezentacji listy aplikacji Wyświetlenie listy tutoriali Przypadek użycia opisuje proces prezentacji listy tutoriali Zgłoszenie aplikacji Przypadek użycia opisuje proces zgłaszania aplikacji przez Prelegenta Usunięcie aplikacji Przypadek użycia opisuje proces usuwania aplikacji przez Prelegenta Rejestracja na tutorial Przypadek użycia opisuje proces rejestrowania się na tutorial przez Prelegenta.

11 Recenzowanie Przypadek użycia opisuje proces recenzowania aplikacji Przeglądanie planu konferencji Przypadek użycia opisuje proces prezentacji planu konferencji z punktu widzenia Organizatora Generowanie planu konferencji Przypadek użycia opisuje proces generowania planu konferencji Ręczne tworzenie planu konferencji Przypadek użycia opisuje proces ręcznego tworzenia planu konferencji Wskazanie kolizji Przypadek użycia opisuje proces wskazania kolizji w ręcznie tworzonym planie Wyświetlenie wskazówek Przypadek użycia opisuje proces prezentacji wskazówek dotyczących ręcznego tworzenia planu konferencji Automatyczne uzupełnienie Przypadek użycia opisuje proces automatycznego uzupełniania ręcznie tworzonego planu Generowanie zapotrzebowania na noclegi i wyżywienie Przypadek użycia opisuje proces generowania zapotrzebowania na noclegi i wyżywienie Stworzenie nowej konferencji Przypadek użycia opisuje proces tworzenia nowej konferencji Modyfikacja informacji o konferencji Przypadek użycia opisuje proces modyfikacji informacji o konferencji.

12 Odwołanie konferencji Przypadek użycia opisuje proces odwoływania konferencji. 5. Dekompozycja logiczna systemu 5.1 Omówienie Diagram 'Dekompozycja systemu' przedstawia podział na podsystemy i zależności między nimi. Stereotyp << subsystem >> znajdujący się na komponencie oznacza, iż komponent ten będzie poddany dekompozycji w dalszej części dokumentu. Komponent warstwy bazy danych (DataBase) zostanie omówiony w rozdziale 9. Komponent ejb.model udostępnia logikę biznesową. AppClient oznacza aplikację kliencką. Pakiety WebPresentation i WebBeanManager umożliwiają dostęp do systemu poprzez przeglądarkę internetową. Dodatkowo na rysunku umieszczono framework Spring w celu pokazania jego miejsca w aplikacji. Pakiety HarmonogramRD i ReferatRD mają na celu zautomatyzowanie procesu tworzenia harmonogramu i konwersji dokumentów: systemu Diagram. Dekompozycja

13 5.2 Omówienie klas analitycznych Diagram 'Model klas' przedstawia podział systemu na klasy. Diagram. Model klas

14 5.3 Najważniejsze komponenty WebPresentation Pakiet należy do warstwy prezentacji. W jego skład wchodzą pliki JSP i HTML. Każdej podstawowej funkcjonalności udostępnianej poprzez stronę internetową odpowiada jeden plik JSP. Wewnątrz plików JSP znajdują się wywołania metod pakietu WebBeanManager. Ważniejsze pliki JSP: konfplan.jsp - wyświetlenie aktualnego planu konferencji rejestrsluchacz.jsp - rejestracja słuchacza zglosref.jsp - zgłoszenie referatu listaprel.jsp - wyświetlenie listy prelegentów ankieta.jsp - oddanie głosu przez słuchacza na referat/prelegenta WebBeanManager Pakiet ten ma na celu pośredniczenie między stronami JSP a komponentami EJB. Dodatkowo pozwala wydzielić większość kodu Javy ze stron JSP. Każdemu plikowi JSP z pakietu WebPresentation odpowiada jedna klasa Java z pakietu WebBeanManager, która wykonuje metody odpowiadającego jej komponentu z kontenera EJB. Ważniejsze klasy: konfplanbean - korzysta z komponentu Harmonogram rejestrsluchacz - korzysta z komponentu Sluchacz zglosrefbean - korzysta z komponentu Referat listaprelbean - korzysta z komponentu Prelegent ankietabean - korzysta z komponentu Ankieta Na przykład plikowi zglosref.jsp odpowiada klasa ZglosRefBean, która z kolei wykonuje metody komponentu Referat z kontenera EJB: ejb.model Komponent warstwy biznesowej ejb.model jest uszczegółowiony na diagramie 'Pakiety podsystemu ejb.model'. Diagram ten przedstawia pakiety znajdujące się w kontenerze EJB i zależności między nimi. Każdy z poniższych pakietów zostanie omówiony w tym rozdziale. Pakiety oznaczone szarym kolorem oznaczają komponenty EJB. Na diagramie tym dodatkowo umieszczono także dwa pakiety analityczne HarmonogramRD i ReferatRD (które nie należą do podsystemu ejb.model):

15 podsystemu ejb.model Diagram. Pakiety ejb.model.sluchacz Pakiet ejb.model.sluchacz umożliwia rejestrację użytkownika na konferencję naukową. Rejestrowany użytkownik dodawany jest do bazy danych. Połączenie z bazą danych realizowane jest przez Spring Jdbc API, mapowanie obietków na tabele realizowane jest przez Hibernate. Klasy pakietu: SluchaczBean - komponent encyjny rejestrujący słuchacza w bazie danych (fizyczny zapis do bazy danych) SluchaczController - klasa implementująca interfejs EJBObject, do niej kierowane są komunikaty od aplikacji klienckich SluchaczControllerBean - komponent sesyjny, przetworzone i zweryfikowane dane kieruje do komponentu SluchaczBean SluchaczControllerHome - fabryka do tworzenia obiektów klasy SluchaczController Sluchacz - interfejs dla klienta komponentu SluchaczHome - fabryka do tworzenia obiektów implementujących interfejs Sluchacz

16 ejb.model.prelegent Pakiet ejb.model.prelegent umożliwia dodanie prelegenta (przez aplikacje Java) oraz zgłoszenie chęci prelekcji (przez stronę internetową). Każda z powyższych akcji jest rejestrowana w bazie danych. Połączenie z bazą danych realizowane jest przez Spring Jdbc API, mapowanie obietków na tabele realizowane jest przez Hibernate. Dodatkowo przy pomocy tego pakietu można poprzez aplikacje Java sprawdzić nowe zgłoszenia. Klasy pakietu: PrelegentBean - komponent encyjny rejestrujący (potencjalnego) prelegenta w bazie danych (fizyczny zapis do bazy danych) PrelegentController - klasa implementująca interfejs EJBObject, do niej kierowane są komunikaty od aplikacji klienckich PrelegentControllerBean - komponent sesyjny, przetworzone i zweryfikowane dane kieruje do komponentu PrelegentBean PrelegentControllerHome - fabryka do tworzenia obiektów klasy SluchaczController Prelegent - interfejs dla klienta komponentu PrelegentHome - fabryka do tworzenia obiektów implementujących interfejs Prelegent ejb.model.rejestracja Pakiet ejb.model.rejestracja umożliwia rejestrację uczestnika. Przekazuje i odbiera dane od interfejsu użytkownika. Nie komunikuje się bezpośrednio z bazą danych, lecz przekazuje żądanie zapisu uczestnika do pakietu ejb.model.sluchacz lub ejb.model.prelegent. Klasy pakietu: RejestracjaController - klasa implementująca interfejs EJBObject, do niej kierowane są komunikaty od aplikacji klienckich RejestracjaControllerBean - komponent sesyjny, przetworzone i zweryfikowane dane kieruje do komponentu PrelegentBean lub SluchaczBean RejestracjaControllerHome - fabryka do tworzenia obiektów klasy RejestracjaController Rejestracja - interfejs dla klienta komponentu RejestracjaHome - fabryka do tworzenia obiektów implementujących interfejs Rejestracja ejb.model.referat Pakiet ejb.model.referat ułatwia zapis i gromadzenie w bazie danych referatów potencjalnych prelegentów. Korzysta z pakietu 'badawczego' referatrd, który zajmuje się konwertowaniem i poprawianiem referatów ejb.model.harmonogram Pakiet ejb.model.harmonogram ułatwia sporządzenie harmonogramu konferecji właściwej jak i tutoriala. Harmonogram będzie tworzony automatycznie przy pomocy dodatkowego pakietu 'badawczego' harmonogramrd. Pakiet podstawowy pozwoli wprowadzić modyfikacje do harmonogramu sporządzonego przez pakiet harmonogramrd.

17 ejb.model.ankieta Pakiet ejb.model.ankieta zarządza całym cyklem życia ankiety, od jej utworzenia do zapisu do bazy danych AppClient Podsystem AppClient, czyli aplikacja kliencka dostarcza interfejs dla wszystkich funkcji udostępnianych przez podsystem ejb.model (w przeciwieństwie do strony internetowej). 6. Dekompozycja na procesy W skład systemu wchodzą dwa niezależne procesy działające po stronie użytkownika (aplikacja Java i przeglądarka WWW), proces udostępniający logikę bieznesową (serwer aplikacji JBoss) oraz proces bazy danych. 6.1 Proces aplikacji Java Jest to proces działający po stronie użytkownika, będącego organizatorem konferencji. Obsługuje on zdarzenia użytkownika - od jego przyjęcia do zwrócenia wyniku. Komunikuje się z procesem serwera aplikacji JBoss. 6.2 Proces przeglądarki WWW Jest to proces działający po stronie użytkownika, którym może być uczestnik konferencji lub organizator. Obsługuje on zdarzenia użytkownika - od jego przyjęcia do zwrócenia wyniku. Komunikuje się z procesem serwera aplikacji JBoss. 6.3 Proces serwera aplikacji JBoss Proces ten realizuje logikę systemu, poprzez przyjmowanie i wykonywanie zleceń użytkowników. Dane uzgodnione do trwałego zapisu kieruje do procesu bazy danych. Mechanizmy serwera aplikacji zapewniają obsługę niskopoziomowych aspektów funkcjonowania aplikacji takich jak wielowątkowość czy transakcyjność. Zatem twórca aplikacji może skupić się przede wszystkim na tworzeniu logiki biznesowej. 6.4 Proces bazy danych Oracle Proces pozwala przechowywać dane w bazie danych. Odbiera zlecenia od procesu serwera aplikacji.

18 7. Instalacja systemu 7.1 Omówienie Finalny produkt będzie składał się z trzech części: modułu J2EE (plik sok.ear) aplikacji Java skryptów instalacyjnych bazy danych Pierwszy krok instalacji obejmuje instalację i konfigurację oprogramowania na którym będzie działał system SOK: instalacja maszyny wirtualnej Java instalacja serwera JBoss instalacja bazy danych Oracle W celu instalacji systemu należy osadzić plik sok.ear na serwerze aplikacji JBoss, oraz uruchomić skrypty instalacyjne na serwerze bazy danych Oracle. Dla organizatorów przeznaczona jest dodatkowo aplikacja Java, która udostępnia większą funkcjonalność niż dostęp poprzez przeglądarkę. Przed uruchomieniem aplikacji na komputerze użytkownika należy prawidłowo zainstalować maszynę wirtualną Javy. W przypadku zwykłych użytkowników wystarczy dostęp do Internetu. 7.2 Wymagania sprzętowe Wymagania sprzętowe po stronie użytkownika WWW: podłączenie do Internetu przeglądarka Internetowa Firefox lub Internet Explorer Wymagania sprzętowe po stronie użytkownika aplikacji Java: zainstalowana maszyna wirtualna Javy komputer z 128 MB pamięci i procesorem min. 400MHz karta graficzna min. 16 MB Wymagania sprzętowe dla serwera: zainstalowana maszyna wirtualna Javy procesor min. 2 GHz pamięć operacyjna min. 2 GB 8. Implementacja systemu Implementacji systemu została omówiona w punkcie piątym.

19 9. Przechowywane dane Przechowywane dane z punktu widzenia przyjętego rozwiązania można podzielić na dwie kategorie. Do pierwszej należą wszelkie podstawowe informacje o prelegentach, słuchaczach, tutorialu,dostępnych miejscach noclegowych czy harmonogramie. Takie dane przechowywane będą w standardowych strukturach bazy danych Oracle jakimi są tabele z kolumnami prostych typów (VARCHAR2, NUMBER itp). Druga kategoria to obiekty dużych rozmiarów, takie jak np. referaty przesyłane przez prelegentów (w postaci plików różnych formatów). Dane te będą przechowywane w specjalnie utworzonej przestrzeni tabel. Na przestrzeń tą będą składały się trzy pliki danych, które rozmieszczone zostaną na różnych dyskach twardych. Rozwiązanie to jest wygodne z punktu widzenia planowania i strojenia sposobu, w jaki baza danych obsługuje operacje wejścia-wyjścia. Ponadto takie rozwiązanie będzie skalowalne, system będzie odporny na ewentualną potrzebę gromadzenia dużej liczby referatów. Niewykluczone jest bowiem, iż niektórzy prelegenci prześlą referaty w postaci plików AVI.

20 danych Diagram. Model bazy 10. Wydajność systemu Podstawowym miernikiem wydajności systemu będą testy symulujące duże natężenie ruchu w sieci WWW, mimo że przewidywana liczba odwiedzin strony WWW konferencji jest nieznaczna. Należy jednak zwrócić uwagę iż wydajność systemu jest kwestią drugorzędną w porównaniu do bezpieczeństwa i integralności danych.

21 10.1 Wymagania Wymagania wydajnościowe stawiane przez systemem są stosunkowo niewielkie, aczkolwiek ich sprawdzenie jest bezwzlędnie wymagane. Wymagania te dotyczą zapewnienia równoległego wykonywania 50 akcji w systemie przez prelegentów lub słuchaczy. Przez akcję rozumiana jest jedna z poniższych czynnośći: rejestracja użytkownika dodanie prezentacji w którymś z formatów danych przeglądanie harmonogramu oglądanie materiałów konferencyjnych wypełnianie ankiety 10.2 Bezawaryjność System powinien działać 24 godziny na dobę. Dopuszczalne są krótkie przerwy w działaniu w czasie godzin nocnych, jednak niezbyt częste i nie dłuższe niż 15 minut. Dla celów bezpieczeństwa przechowywana jest kopia systemu, więc oczekuje się, że ewntualna awaria zostanie naprawiona w ciągu kilku godzin Rozwiązania sprzętowe Wymagania sprzętowe są następujące: dwurdzeniowy procesor taktowany zegrem minimum 2.8 GHz na potrzeby serwera aplikacji pamięć operacyjna minimum 1 Gb szybkie łącze, przynjamniej 1Mb/s 10.4 Rozwiązania programowe wykorzystanie procedur składowanych po stronie bazy danych (programów pl/sql) tworzenie indeksów na kolumnach o dużej częstosći zapytań gromadzenie danych na 3 niezależnych dyskach ewentualnie zastosowanie klastrów wydajnościowych 11. Jakość 11.1 Bezpieczeństwo Zapewnienie bezpieczeństwa ułatwione jest przez zaawansowane mechanizmy serwera aplikacji i serwera bazy danych Oracle oraz podział systemu na warstwy (w tym rozdzielenie warstwy prezentacji od warstwy logiki) Przeglądarki internetowe System będzie poprawnie działał we wszystich popularnych przeglądarkach internetowych.