AskAnything - SAD by the Hackin9 crew

Transkrypt

1 AskAnything - SAD by the Hackin9 crew Jan Urbański (ju219721) Jakub Rauch (jr219554) Sebastian Tomaszewski (st219712) Maciej Stefański (ms219668) 5 czerwca (strona projektu) 1

2 Spis treści 1 Wprowadzenie Cel Zakres Definicje Omówienie reszty dokumentu Prezentacja architektury systemu 3 3 Załozenia i zależności 4 4 Przeglad przypadków użycia Zdefiniowanie ankiety Korzystanie z konsultacji Odebranie wyników Wypełnienie ankiety Sklepik Realizacje przypadków użycia Dekompozycja logiczna systemu Omówienie Interfejs użytkownika Interfejs bazy danych Baza danych Dekompozycja na procesy 11 7 Instalacja systemu 12 8 Implementacja systemu Omówienie Warstwy Aplikacja Interfejs bazy danych Baza danych Wydajność systemu Jakość Rozszerzalność Niezawodność Historia zmian 17 2

3 1 Wprowadzenie 1.1 Cel Ten dokument ma na celu przedstawienie architektury systemu AskAnything. Jego charakterystyka została tu szczegółowo zaprezentowana, w oparciu o rozmaite techniki projektowe. Celem jest przedstawienie najistotniejszych rozwiązań strukturalnych, zgodnych z założeniami i wymaganiami, wykorzystanych do tworzenia systemu AskAnything. Przy tworzeniu oprogramowania wszystkie, zawarte w tym dokumencie wymagania, muszą być przestrzegane. 1.2 Zakres Software Architecture Document opisuje: 1. pakiety 2. strukturę systemu 3. interfejsy 4. klasy 1.3 Definicje ACID: Atomicity, Consistency, Isolation, Durability HTML: HyperText Markup Language HTTP: Hypertext Transfer Protocol HTTPS: HTTP z wykorzystaniem dodatkowego protokołu zabezpieczeń PG: PostgreSQL PHP: PHP: Hypertext Preprocessor SQL: Structured Query Language WWW: World Wide Web 1.4 Omówienie reszty dokumentu W kolejnych działach znajduje się omówienie następujących tematów: 2. Prezentacja architektury systemu 3. Założenia i zależności 3

4 4. Przegląd przypadków użycia 5. Dekompozycja logiczna systemu - pakiety 6. Dekompozycja na procesy - komunikacja procesów 7. Instalacja systemu 8. Implementacja systemu 9. Przechowywane dane 10. Wydajność systemu 11. Jakość 2 Prezentacja architektury systemu Architektura systemu bazuje na zależności klient-serwer. Ze strony użytkownika dostęp wymaga jednynie posiadania przeglądarki internetowej oraz dostępu do sieci WWW. Cała struktura systemu znajduje się na serwerze. Całość przedstawiona jest w następujących perspektywach: Przypadki użycia Dekompozycja logiczna sytemu Dekompozycja procesów Implementacja Instalacja 3 Załozenia i zależności Wymagania zostały zawarte w Dokumentacji Uzupełniającej - rozdziały 2.2, 2.3 Sprostanie tym wymaganiom wiąże się z koniecznością istnienia co najmniej dwóch równolegle działających serwerów zapewniających nieprzerwaną pracę systemu. Konieczne jest, aby serwery te były fizycznie od siebie oddalone. W razie awarii jednego z nich drugi musi zapewniać pełną sprawność systemu na czas przywrócenia pierwszego do prawidłowego funkcjonowania. Każdy z serwerów powinien mieć szerokopasmowe łącze - co najmniej 10Mb/s. Preferowana architektura to AMD Opteron, która znakomicie sprawdza się w roli serwera. Dla swobodnej pracy systemu wymagane jest 100GB pamięci dyskowej na bazę danych i aplikację AskAnything. W celu ochrony danych konieczne jest wykonanie co najmniej jednej dodatkowej kopii bazy danych aktualizowanej przynajmniej raz na trzy dni. Kopia danych musi znajdować się na komputerze fizycznie oddalonym od aktywnie działającego w ramach systemu. 4

5 Dodatkowe zabezpieczenie na poziomie software owym zakłada pracę na bazie danych opartej na konwencji ACID. Preferowana baza - ORACLE (w ostateczności PG). Nie mniej istotna jest stabilność, którą zapewni system UNIX i serwer Apache (wersja lub nowsza). 4 Przeglad przypadków użycia 4.1 Zdefiniowanie ankiety Stale rosnące zapotrzebowanie na badanie rynku jest najważniejszym powodem istnienia AskAnything. Do badania niezbędne jest utworzenie szeregu pytań. Ten przypadek użycia pokazuje w jaki sposób powstaje ankieta w AskAnything. 5

6 4.2 Korzystanie z konsultacji Tworzenie ankiety nie jest łatwe, a jej prawidłowe skonstruowanie może znacznie poprawić skuteczność ankiety, a co za tym idzie, również jakość wyników. Skorzystanie z konsultacji pozwala na zoptymalizowanie ankiety tak, by dostarczała ona jak najwięcej cennych informacji. W konsultacjach uczestniczą zatrudnieni do tego celu specjaliści. 4.3 Odebranie wyników Po zakończeniu przeprowadania ankiety konieczne jest umożliwienie jej analizy. Oczywiście dostęp do takich danych musi być odpowiednio ograniczony i zabezpieczony. Ten przypadek prezentuje odbiór wyników ankiety przez zleceniodawcę (jedyny prawowity właściciel danych poza AskAnything). 4.4 Wypełnienie ankiety Konieczne jest zgromadzenie znacznej liczby osób, chętnych do uczestniczenia w badaniu. Ten przypadek użycia ukazuje, w jaki sposób zbierane są informacje od poszczególnych badanych. 4.5 Sklepik Aby zachęcić ludzi do uczestniczenia w ankiecie konieczne jest zorganizowanie nagród. Dostęp do sklepiku pozwala uczestnikom ankiety zrekompensować sobie czas poświęcony na wypełnianie ankiety. Tutaj widać, jak został zorganizowany system nagród w AskAnything. 4.6 Realizacje przypadków użycia 5 Dekompozycja logiczna systemu 5.1 Omówienie System dzieli się na trzy podstawowe warstwy: Interfejs użytkownika (ankietowany lub zleceniodawca) Interfejs bazy danych Baza danych 6

7 7

8 5.2 Interfejs użytkownika Użytkownik poprzez swoją przeglądarkę internetową, może za pomocą protokołu http (w przypadku logowania https) połączyć się z systemem i poruszać się w środowisku za pośrednictwem przygotowanego interfejsu użytkownika. Tak zinterpretowana strona WWW będąca wygenerowanym w PHP kodem HTML pozwoli użytkownikowi na interakcję z systemem. Sposób poruszania się użytkownika po sytemie zawarty jest w przypadkach użycia - Wypełnienie Ankiety (rozdział 2.), Sklepik (rozdział 2.). Jak widać na diagramie istnieją trzy podklasy Strony. Jako że wyniki ankiety, treść ankiety czy sklepik będzie oparty na schematycznej budowie, więc najłatwiej będzie skorzystać z klas, które na podstawie pobranych z bazy informacji wygenerują odpowiedni kod HTML. Pozostałe, mniej charakterystyczne strony będą korzystały ze zwykłej klasy Strona, która wyświetlać będzie informacje zawarte w treści. Strona, jako składnik okna, wyświetlana będzie razem z menu i nagłówkiem. Menu pozwoli poruszać się po systemie i różnorodnych jego podstronach. Nagłówek widoczny na każdej otwartej witrynie (podobnie jak menu) jest jedynie informacją na jakiej stronie internauta się znalazł. Jego kliknięcie spowoduje powrót do strony głównej. Menu 8

9 składa się z przycisków - te zaś posiadają swoją nazwę i odpowiednie odnośniki. Menu z przyciskami, podobnie jak wszystkie elementy strony, potrafi wygenerować swój kod (Menu jedynie wybiera gdzie kod przycisku ma zostać umieszczony). Każdemu Elementowi można nadać szerokość i wysokość. Ponadto istnieje możliwość zmiana image strony za pomocą popularnych obecnie stylów. 5.3 Interfejs bazy danych W pakiecie AskAnything znajduje się implementacja wielu pomocniczych funkcji do bazy danych. Głównymi tam dostępnymi są: dodajużytkownika(info: Uzytkownik) - dodaje do bazy użytkownika o charakterystyce zdefiniowanej w info (typ został uogólniony dla większej czytelności) skasujużytkownika(login: String) - usuwa użytkownika o podanym loginie (dostępne tylko dla administratora) dodajankietę(struktura: Ankieta) - dodaje do bazy Ankietę na podstawie podanego parametru Ankieta (typ został uogólniony dla większej czytelności), za pośrednictwem interfejsu opartego na InterfejsUżytkownika::Ankieta wynikiankiety(id: int) - zwraca wyniki ankiety o identyfikatorze id (dla zleceniodawców - używane w klasie InterfejsUżytkownika::Ankieta) podajankiete(id: int) - zwraca zestaw pytan ankiety (dla ankietowanych - używane w klasie InterfejsUżytkownika::Ankieta) zapiszankiete(struktura: Ankieta) - zapisuje wyniki ankiety (za pośrednictwem interfejsu opartego na InterfejsUżytkownika::Ankieta) zawartośćsklepiku() - zwraca zawartość sklepiku (wykorzystywane np: w klasie InterfejsUżytkownika::Sklep do generowania interfejsu) kup(id) - zwraca kupiony przedmiot jeśli możliwe (wystarczająca liczba zebranych punktów) Poza najważniejszymi istnieje jeszcze wiele innych ułatwiających pracę na bazie danych (tj. dodajpunkty(i: int), zabierzpunkty(i: int), itp). 9

10 5.4 Baza danych Na powyższym diagramie zawarte są encje dotyczące osób, ankiet, pytań i odpowiedzi. Pominięty został sklepik dla większej przejrzystości. Diagram charakteryzuje strukturę bazy danych, istniejące tabele i zależności oraz rodzaje zmiennych. Część dotycząca sklepiku to dodatkowe encje: Kategorie Artykuły Zamówienia Kategorie będą wyświetlane na stronie głównej sklepiku. Mają wprowadzać porządek wśród dostępnych artykułów. Atrybuty: # id: INTEGER - unikalny identyfikator kategori (klucz główny) * nazwa: VARCHAR(30) - nazwa kategorii o opis: VARCHAR(250) - krótki opis, czego dotyczy kategoria 10

11 o ikona: VARCHAR(100) - ikona wyświetlana na stronie, która ma charakteryzować daną kategorię Kategorie są połączone związkiem jeden do wielu z encją Artykuły. Każdy artykuł musi należeć do jakiejś kategorii, a każda kategoria może mieć wiele artykułów. Artykuły będą widoczne po otwarciu którejś z kategorii (oczywiście tylko te artykuły, które do owej kategorii należą). Atrybuty: # id: INTEGER - unikalny identyfikator artykułu (klucz główny) * kategoria: INTEGER - klucz zewnętrzny, na którym opiera się związek z Kategoriami * nazwa: VARCHAR(30) - nazwa artykułu * cena: INTEGER - cena artykułu w punktach o cenapln: FLOAT - cena artykułu w złotówkach o opis: VARCHAR(250) - opis artykułu o zdjęcie: VARCHAR(100) - zdjęcie artykułu (ewentualnie adres folderu ze zdjeciami) Artykuły są połączone związkiem z Kategoriami (wspomniane wyżej) oraz związkiem jeden do wielu z Zamówieniami. Każdy artykuł może być zamówiony wielokrotnie, ale każde osobne zamówienie może dotyczyć tylko jednego artykułu. Zamówienia jest encją powstałą w miejsce związku wiele do wielu pomiędzy Osobami, a Artykułami. # id: INTEGER - unikalny identyfikator zamówienia (klucz główny) * osoba: INTEGER - klucz zewnętrzny, na którym opiera się związek z Osobami * artykuł: INTEGER - klucz zewnętrzny, na którym opiera się związek z Artykułami Zamówienia są połączone związkiem z Artykułami (wspomniane wyżej) oraz związkiem wielu do jednego z Osobami. Jedna osoba może złożyć wiele zamówień, ale każde osobne zamówienie może być złożone tylko przez jedną osobę. 6 Dekompozycja na procesy Ponieważ baza danych Oracle pozwala na współbieżny dostęp do zawartych w niej danych, system pozwala więc na równoległą pracę wielu użytkowników jednocześnie, generując dla każdego z nich odpowiedni interfejs. Za jego pośrednictwem każdy z użytkowników będzie mógł, niezależnie od pozostałych, łączyć się z serwerem SQL. Jako, że połączenie będzie osobne dla każdego użytkownika, a serwer umożliwia znaczny przepływ danych w takich okolicznościach, więc każda instancja Okna z wygenerowanym kodem będzie działała równolegle do innych, wywołanych przez resztę aktywnych użytkowników. 11

12 7 Instalacja systemu Perspektywa instalacji pokazuje fizyczne połączenia między najistotniejszymi węzłami w systemie. System AskAnything wyznacza w tej dziedzinie konkretne cele, aby sprostać postawionym wymaganiom (przede wszystkim bezpieczeństwu i bezawaryjności). Poniższy diagram systemu pokazuje w jaki sposób następuje przekaz danych między użytkownikami z różnymi uprawnieniami, a systemem AskAnything. System może działać zarówno na jednym jak i wielu równolegle współpracujących serwerach. Podobnie jest w przypadku baz danych. Wymagania wydajnościowe i jakościowe powodują, że w przypadku AskAnything, ze względu na skalę na jaką ma on być rozpowszechniony, musi on pracować na co najmniej dwóch serwerach obsługujących użytkowników i dwóch serwerach baz danych. Szczegóły tego rozwiązania są zawarte w Założeniach i zależnościach tego dokumentu. Poniższy diagram stanowi graficzną interpretację planowanej struktury systemu. Oczywiście zakładamy, że zależności z diagramu powyżej zawarte są i w budowie systemu przedstawianego poniżej. 12

13 Widać wyraźnie, że system można łatwo rozbudowywać i dodawać kolejne serwery lub bazy danych. Dzięki takiemu uniwersalnemu rozwiązaniu możliwe jest uruchomienie systemu AskAnything przykładowo na zwiększonej liczbie serwerów, o mniejszej wydajności niż jest to założone. Istotne jest, aby obciążenie serwerów było możliwie wyrównane. W tym celu serwer DNS będzie przydzielał losowy numer komputera pod adres strony AskAnything. 8 Implementacja systemu 8.1 Omówienie Ze strony implementacyjnej system AskAnything dzieli się na następujące warstwy: aplikacja w PHP - interfejs użytkownika, struktura generowania stron 13

14 interfejs bazy danych baza danych 8.2 Warstwy Aplikacja Aplikacja ma za zadanie stworzyć stronę WWW dla użytkownika, adekwatnie do jego uprawnień. W tym celu należy zaimplementować interfejsy z różnymi prawami dostępu. Interfejsy mają być oparte na strukturze klas przedstawionej w rozdziale 5.2 tego dokumentu. Naturalnie konieczna jest implementacja przedstawionych tam klas Interfejs bazy danych Interfejs bazy danych stanowi implementacja funkcji wymienionych w rozdziale 5.3. Istnieje podział na dwie główne grupy: funkcje administracyjne + funkcje użytkownika wspólne funkcje ankietowanego funkcje zleceniodawcy 14

15 Ma on na celu zwiększenie bezpieczeństwa systemu. Funkcje administracyjne udostępniane są jedynie administratorowi, który będzie się łączył z bazą korzystając z innego loginu i hasła niż użytkownicy. W takiej sytuacji nie zdarzy się, że osoba, która będzie chciała włamać się na stronę z poziomu zwykłego użytkownika, skorzysta z funkcji dostępnych administratorowi. Oczywiście administrator ma dostęp do funkcji użytkownika. W podobny sposób podzielony jest dostęp do funkcji u zleceniodawcy i ankietowanego. Ze względu na niewielkie możliwości wyrządzenia szkód w grupie użytkowników, podział ten nie został aż tak wyraźnie wyszczególniony. Jednak warto zauważyć, że ten krok również jest istotny. Zleceniodawca, który pod kątem możliwości jakie daje mu oprogramowanie, ma większe możliwości manewru w razie próby włamania na stronę. Jednak większe możliwości wiążą się z większym ryzykiem, ponieważ klient jest jest znacznie mniej anonimowy niż ankietowany Baza danych Struktura bazy danych została szczegółowo przedstawiona w rozdziale 5.4 tego dokumentu. 15

16 9 Wydajność systemu Największą trudnością jest sprostanie wymaganiom wydajnościowym pod względem obciążenia łącz (do bazy danych). Aby sprostać wymaganiom system musi sprawnie obsługiwać: zapytania wykonywane na bazie danych (wyniki do kilkudziesięciu kilobajtów, modyfikacja bazy) - najbardziej kosztowne operacje generowanie kodu strony (czas zależny od mocy obliczeniowej serwera) znaczny wzrost ruchu na stronie (zwłaszcza w godzinach popołudniowych - łączy dwa poprzednie punkty) Na powyższe sytuacje składają się przede wszystkim: przeglądanie sklepiku otwieranie ankiet wyświetlanie wyników ankiet wysyłanie rozwiązań ankiet Równoległa współpraca dwóch serwerów klasy AMD Opteron - każde z łączem 10Mb/s pozwala na jednoczesną obsługę do 600 użytkowników (zakładając, że są to użytkownicy wykonujący losowe operacje). 10 Jakość 10.1 Rozszerzalność Obecnie AskAnything przewidziane jest do funkcjonowania w obrębie całego kraju. Wraz ze wzrostem zainteresowania lub w razie wkroczenia na zagraniczne rynki, możliwe jest dostosowanie mocy obliczeniowej i przepływu informacji stosując dodatkowe serwery i bazy danych oraz zaopatrując system w bardziej przepustowe łącza. Charakterystyka budowy systemu (opis w rozdziale 7.) pozwala na swobodny rozwój systemu Niezawodność Jednocześnie współpracujące dwa serwery pozwalają zachować stabilność systemu. W razie awarii jednego serwera, drugi przejmie jego obowiązki. Ewentualne przeciążenie systemu i związane z tym opóźnienia będą trwały jedynie tyle ile wyniesie przywrócenie do pracy pierwszego serwera (do 30 minut). W razie poważnych uszkodzeń, które nie pozwolą na szybki powrót serwera do normalnego trybu pracy podjęte działania zaradcze (wynajęcie/kupno serwera) mogą ewentualnie przedłużyć przeciążenie do jednej doby. Stały nadzór administratora 16

17 nad systemem ma zminimalizować ryzyko zaistnienia takich sytuacji. W razie uszkodzenia bazy danych natychmiastowo zostaje uruchomiona kopia zapasowa (bezpowrotnie przełączona z trybu stand-by na ready), która przejmuje obowiązki dotychczas pracującej bazy danych. 11 Historia zmian Wersja /05/27 11:04:07 Gotowa wersja dokumentu. Wersja /05/25 01:47:40 Dodano diagramy. Brak spisu treści, sekcji "wydajność systemu"i sekcji "Jakość". Pozostałe sekcje gotowe. Wersja /05/22 00:03:46 Sekcje 1-7 gotowe - brak diagramów. 17