Opis architektury systemu „ISOiWUT”

Michał Lewowski Piotr Skowron Michał Matczuk Piotr Wygocki

4 czerwca 2006

1

Spis tresci1 Wprowadzenie 3

1.1 Zakres . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2 Ograniczenia i załozenia 3

3 Warstwy systemu 43.1 Motywacja . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

4 Architektura systemu 5

5 Przypadki uzycia 95.1 Dodawac oferty . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105.2 Wyszukiwac oferty . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135.3 Rezerwowac oferte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165.4 Potwierdzac rezerwacje . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185.5 Motywacje . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

6 Wdrozenie projektu 21

7 Dane 22

8 Historia zmian 23

2

1 WprowadzenieCelem niniejszego dokumentu jest opisanie budowy systemu ISOiWUT oraz omówienie róz-nych aspektów realizacji tego projektu. Dokument ten ma w załozeniu pokrywac i wyjasniacwszystkie kluczowe decyzje architektoniczne podjete podczas projektowania tego systemu.

1.1 ZakresW skład niniejszego dokumentu wchodza:

• omówienie logicznego podziału systemu na warstwy

• omówienie architektury systemu

• opis realizacji głównych przypadków uzycia od strony systemu

• omówienie przechowywanych danych oraz sposobu ich gromadzenia

• opis wdrozenia systemu

2 Ograniczenia i załozeniaW załozeniach projektu zakładamy, ze projekt bedzie tworzony w jezykach :

• PHP 4.2

• JavaScript

Zakładamy prace systemu na serwerze Apache w wersji 2.2 z systemem zarzadzania bazadanych PostgreSQL wersja 8.1.4 z zainstalowanym systemem operacyjnym unix (freeBSD).

3

3 Warstwy systemuPodział na warstwy systemu prezentuje ponizszy diagram:

System jest podzielony na 5 warstw :

• warstwa kliencka - widok

Warstwa odpowiedzialna za wizualizacje działania systemu. Działa w połaczeniu z prze-gladarka zainstalowana po stronie uzytkownika.

• warstwa prezentera

Logika, która odpowiada za poprawne obsługiwanie zadan uzytkownika.

• warstwa integracji

Fasada odpowiedzialna za wykonywanie zadan wartwy prezentera odnoszacych sie do da-nych.

• warstwa modelu

Warstwa odpowiedzialna za logiczne modelowanie danych w systemie.

• warstwa bazy danych

Warstwa odpowiedzialna za fizyczne przechowywanie danych.

3.1 MotywacjaPowyzszy podział na warstwy jest dosc standardowy i sprawdził sie w wielu analogicznych pro-jektach, a ponadto dobrze modeluje logiczna dekompozycje systemu ISOiWUT. Wybrane narze-dzia do tworzenia systemu umozliwiaja odzwierciedlenie warstw w projekcie.

4

4 Architektura systemuSystem ISOiWUT bedzie zaprojektowany zgodnie z ponizszym diagramem klas :

5

Klasa widok ( z intuicyjnym dziedziczeniem odpowiadajacym pakietom Modelu ) odpowiadaza graficzne przedstawienie pracy systemu uzytkownikowi. Klasa Prezenter ( z intuicyjnym dzie-dziczeniem ) reaguje na akcje uzytkownika Klasa Fasada jest odpowiedzialna za komunikowa-nie Prezentera z Modelem. Prezenter wywołuje odpowiednia metode obiektu tej klasy, a Fasadamartwi sie, jak od strony danych ( Modelu ) obsłuzyc te prosbe. Klasy modelu reprezentujakonkretne dane w systemie.

Omówimy krótko główne pakiety modelu :

• Forum

6

Forum składa sie z tematów, a kazdy temat zawiera posty, czyli pojedyncze wypowiedzijednego uzytkownika. Ponizszy diagram prezentuje dokładniej zaleznosci w systemie. Naanalogicznej zasadzie działaja pozostałe moduły.

• System uzytkowników

Klasy z tego pakietu reprezentuja uzytkownika w systemie ISOiWUT oraz pamietaja jegodane, preferencje. Klasa Sesja reprezentuje pojedyncze logowanie uzytkownika w syste-mie.

• System opisów podrózy

Ten pakiet reprezentuje klasy zwiazane z modułem opisów podrózy na stronie. Kazdymopis podrózy moze miec wiele komentarzy.

7

• System prywatnych wiadomosci

Klasa wiadomosc odpowiada jednej wiadomosci przesłanej miedzy dwoma uzytkowni-kami.

• System FAQ

Klasy reprezentuja pojedyncze pytanie i odpowiedz zawarta w module FAQ.

• System zarzadzania ofertami

Oferty w systemie reprezentowane sa jako obiekty klasy Oferta. Kazda oferta moze zo-stac zarezerwowana ( odpowiada temu obiekt Rezerwacja ). Rezerwacja pociaga za sobaobowiazek potwierdzenia ( Potwierdzenie ). W systemie zarzadzania ofertami istnieje tezobiekt Wyszukiwarka, która odpowiada za wyszukiwanie ofert przez Uzytkownika o za-danych kryteriach i przekazanie ich w odpowiedniej formie, do pytajacych obiektów.

• System obsługi błedów

Klasa bład reprezentuje błedy w systemie. Kazdy bład ma swój kod i jest powiazany zkonkretnym komunikatem, który jest w razie koniecznosci prezentowany uzytkownikowi.

8

5 Przypadki uzyciaOpisane ponizej przypadki uzycia sa równiez omówione w dokumencie Use-Case.

9

5.1 Dodawac ofertyPopatrzmy na diagram stanów tego przypadku uzycia :

Diagram przebiegu ułatwia zrozumienie mechanizmu działania całego systemu, który jestpodobny w swojej idei w kazdym kolejnym przypadku. Interakcje z uzytkownikiem obsługujePrezenter ( w tym przypadku jego podklasa - PrezenterOferty ), po otrzymaniu prosby o obsługeformularza. Tworzy on wtedy obiekt Oferta, który przechowuje dane formularza i pomaga Pre-zenterowi zwalidowac poprawnosc danych. Nastepnie Prezenter wyciaga potrzebne mu jeszczeinformacje, czyli sprawdza czy uzytkownik jest rzeczywiscie zalogowany i jesli tak, to pobierajego id. O ile po drodze nie wystapiły zadne błedy, Prezenter zleca teraz Fasadzie dodanie odpo-wiedniej oferty.

10

Dodawanie ofert : interfejs i prezenter

11

Zobaczmy teraz bardziej szczegółowo, co dzieje sie w Modelu w tym przypadku uzycia.Fasada otrzymała zlecenie dodania oferty i wie, ze dane wprowadzone przez uzytkownika sa juzpoprawne. Tworzy wiec obiekt Oferta, który reprezentuje dana oferte i ten obiekt zapisuje siez bazy danych tworzac odpowiednie zapytanie SQL i wywołujac je na obiekcie Baza Danych,który jest typowa, prosta nakładka na baze danych :

Dodawanie ofert : model

12

5.2 Wyszukiwac ofertyDiagram stanów dla przypadku wyszukiwanie oferty :

Ten przypadek uzycia jest realizowany analogicznie od poprzedniego jezeli chodzi o ideeprzesyłania komunikatów miedzy obiektami. Ponownie Prezenter korzysta z Fasady by wycia-gnac interesujace go dane z Modelu.

13

Wyszukiwac oferte : interfejs i prezenter

14

Diagram tego, co dzieje sie w Modelu podczas wyszukiwania ofert :

15

5.3 Rezerwowac oferteRezerwowac oferte : interfejs i prezenter

16

Diagram tego, co dzieje sie w Modelu podczas rezerwowania oferty. Warto zwrócic uwage,ze zarezerwowanie powoduje automatyczne wysłanie powiadomienia do uzytkownika, któregooferte zarezerwowano.

17

Diagram komunikacji dla rezerwowania oferty:

18

5.4 Potwierdzac rezerwacje

Klient po zarezerwowaniu oferty dostaje wiadomosc poczta elektroniczna z prosba o potwie-rzenie rezerwacji. Wiadomosc zawiera dwa hiperlinki. Jeden którego otworzenie powoduje po-twierdzenie rezerwacji, oraz drugi którego otworzenie powoduje usuniecie rezerwacji. Podczasrezerwacji obiekt Sesja sprawdza czy uzytkonik jest zalogowany i czy jest tym uzytkownikiemktóry zarezerwował oferte, nastepnie jesli uzytkonik ma prawo by potwierdzic rezerwacje wyko-nywana jest metoda potwierdzRezerwacje Fasady.

Potwierdzac rezerwacje : interfejs i prezenter

19

20

Diagram tego, co robi model podczas potwierdzania rezerwacji.

5.5 MotywacjeW projekcie jest uzyty typowy dla obiektowych aplikacji podział na model widok oraz prezen-ter. Do generowania widoku bedziemy uzywac systemu wzorców Smarty, pozwala on w łatwe iszybkie dopasowanie wygladu aplikacji do naszych potrzeb, ponadto jego integracja z aplikacjanie sprawia problemów. Prezenter nie odwołuje sie bezposrednio do modelu, kontakt z modelemjest realizowany za pomoca obiektu Fasada co sprawi ze, łatwiejsze stanie sie wprowadzaniezmian w modelu oraz dodawanie nowych funkcjonalnosci. Do komunikacji z baza danych uzy-wamy obiektu BazaDanych jego rola jest łaczenie sie z baza danych i wykonywanie zapytan.Dzieki temu uzyskujemy łatwosc dostosowania aplikacji do innych systemów baz danych, po-nadto poprawiamy bezpieczenstwo oraz zapewniamy wieksza wygode przy pisaniu kodu.

21

6 Wdrozenie projektu

Wdrozenie projektu polega w głównej mierze na odpowiedniej konfiguracji komputerów be-dacych serwerami (działajacych pod freeBSD).

Na jednym serwerze systemu zostanie zainstalowany system zarzadzania baza danych Post-greSQL 8.1.4 oraz serwer WWW Apache 2.2. Serwer zostanie połaczony z internetem łaczemszerokopasmowym. Zostanie wykupiony dla niego stały adres DNS oraz domena. Serwer WWWbedzie odpowiadał na zadania przegladarek internetowych (po HTTP i HTTPS) w komputerachklienckich. Dalsza czesc wdrozenia zajma testy opisane szczegółowiej w oddzielnym dokumen-cie : Plan testów.

22

7 DanePonizszy diagram przedstawia encje w bazie danych:

23

8 Historia zmian

30 maja 2006r. - pierwsza wersja dokumentu31 maja 2006r. - dodano diagramy w przypadkach uzycia

24