Software Architecture Document dla systemu USOSweb 2.0 Adam Radziwończyk-Syta Karol Sobczak Marcin Koziński Grzegorz Paszt 17 maja 2007
Spis treści 1 Wprowadzenie 4 1.1 Cel.......................................... 4 1.2 Zakres........................................ 4 1.3 Definicje....................................... 4 1.4 Omówienie reszty dokumentu........................... 4 2 Prezentacja architektury systemu 5 2.1 Widok przypadków użycia............................. 5 2.2 Widok logiczny................................... 5 2.3 Widok procesów.................................. 5 2.4 Widok instalacji................................... 5 2.5 Widok implementacji................................ 5 3 Założenia i zależności 6 3.1 Platforma...................................... 6 3.2 Bezpieczeństwo................................... 6 3.3 Przechowywanie danych.............................. 6 3.4 Dostępność i niezawodność, wydajność, inne................... 6 4 Przeglad przypadków użycia 7 4.1 Sprawdzenie terminu kolokwiów i egzaminów................... 7 4.2 Sprawdzanie planu Znajomego........................... 7 4.3 Wgrywanie plików................................. 8 4.4 Dodanie ogłoszenia................................. 8 4.5 Odpowiadanie na ogłoszenie............................ 8 4.6 Sprawdzanie wyniku kolokwium znajomego.................... 8 5 Dekompozycja logiczna systemu 8 5.1 Omówienie..................................... 8 5.2 Realizacje najważniejszych przypadków użycia.................. 10 5.2.1 Realizacja przypadku użycia Wgrywanie pliku.............. 10 5.2.2 Realizacja przypadku użycia Wyszukiwanie kolokwiów......... 11 6 Dekompozycja na procesy 11 7 Instalacja systemu 12 7.1 Ogólny opis..................................... 12 8 Implementacja systemu 12 8.1 Omówienie..................................... 12 8.2 Warstwy....................................... 12 8.2.1 Interfejs................................... 12 2
8.2.2 Aplikacja.................................. 13 8.2.3 Model dziedziny.............................. 14 8.2.4 Usługi.................................... 15 8.2.5 Podstawy.................................. 15 9 Wydajność systemu 15 10 Historia zmian 16 3
1 Wprowadzenie 1.1 Cel Ten dokument zawiera opis architektury systemu USOSweb 2.0. Składają się na niego różne widoki, które mają uwypuklić poszczególne aspekty budowy systemu. W tym dokumencie mamy przede wszystkim na celu uchwycić i pokazać ważne decyzje dotyczące architektury systemu, które zostały podjęte w trakcie prac nad nim. 1.2 Zakres Ten dokument dotyczy architektury systemu USOSweb 2.0 projektowanego w ramach zajęć z Inżynierii Oprogramowania w roku 2006/2007 przez zespół złożony z autorów tego dokumentu. 1.3 Definicje USOS Uniwersytecki System Obsługi Studiów, http://usos.mimuw.edu.pl/ USOSweb webowy interfejs do USOSa, dający dostęp do zasobów studentom i pracownikom naukowym wydziału System system, którego ten dokument dotyczy USOSweb 2.0 gateway program odpowiadający za umożliwienie komunikacji pomiędzy dwoma systemami zaintastalowanymi na różnych platformach, używających niespójnych formatów danych, etc. MIM skrót od: Matematyka, Informatyka i Mechanika; jeden z wydziałów UW. 1.4 Omówienie reszty dokumentu Kolejne sekcje dokumentu dotyczą następujących aspektów: Sekcja 2 przedstawienie i opis poszczególnych widoków prezentowanych w dalszej części dokumentu Sekcja 3 opis założeń i zależności systemu Sekcja 4 przypadki użycia mające znaczący wpływ na architekturę Sekcja 5 dekompozycja systemu na logiczne składowe Sekcja 6 zagadnienia wielowątkowości Sekcja 7 plan wdrożenia (instalacji) systemu Sekcja 8 podział systemu na warstwy i ewentualne podsystemy Sekcja 9 wymagania wydajnościowe 4
2 Prezentacja architektury systemu Architektura systemu zostanie zaprezentowana przy pomocy następujących widoków: 2.1 Widok przypadków użycia Zawiera opis przykładowego, podstawowego przypadku użycia, który obrazuje typowe użycie systemu i standardowe akcje, które użytkownik będzie wykonywał na systemie. 2.2 Widok logiczny Zawiera opis logicznej realizacji funkcjonalnych wymagań wobec systemu, w szczególności realizację zaprezentowanego przypadku użycia. Pokazuje logiczne składowe systemu i wyjaśnia powody takiego właśnie podziału. 2.3 Widok procesów Zawiera opis zagadnień wielowątkowości w przypadku rywalizacji współbieżnie działających procesów. 2.4 Widok instalacji Zawiera opis sprzętu potrzebnego do wdrożenia systemu, nakreśla powiązania pomiędzy poszczególnymi elementami sprzętowymi. 2.5 Widok implementacji Zawiera opis podstawowych warstw na jakie będzie podzielony system oraz co za tym idzie plan implementacji. 5
3 Założenia i zależności W tej sekcji zostaną opisane wymagania wobec budowy systemu, wynikające z narzuconych ograniczeń i założonych celów. 3.1 Platforma System jest aplikacją w pełni webową, zatem konieczne jest umieszczenie go serwerze odpowiednim dla takich zastosowań, np. serwer aplikacji J2EE. W przypadku pełnej integracji z USOSem wgodne będzie dostoswanie się do platformy wybranej pod USOSweb (PHP, MySQL), aby uniknąć konieczności tworzenia gateway ów. 3.2 Bezpieczeństwo System musi być bezpieczny, ponieważ będzie obsługiwał poufne dane dotyczące studiów i studentów. Także zawartość wprowadzana przez użytkownikach musi być zabezpieczona, ponieważ chcemy umożliwić jej moderację, a więc także pozwolić na wyciąganie odpowiedzialności w pewnych przypadkach. Zapewnione będą przede wszystkim podstawowe fukncje zabezpieczające: logowanie się uzytkowników, jak dotychczas w USOSweb (pesel i hasło); autoryzacja użytkowników: udostępnienie funkcji odpowiednich dla studenta, pracownika naukowego, administratora, etc. Podstawowe mechanizmy zapewniania bezpieczeństwa w internecie zostaną wykorzystane: szyfrowanie poufnych danych, logowanie ważnych aktywności, etc. 3.3 Przechowywanie danych Do przechowywania wszelkich danych, w tym prywatnych danych z profilów użytkowników, zawartości dostarczanej przez użytkowników, itd. zostanie użyta relacyjna baza danych. 3.4 Dostępność i niezawodność, wydajność, inne System musi spełniać w tych kwestiach (oraz w ogóle w każdych) wymagania postawione oryginalnemu USOSowi i jego interfejsom. 6
4 Przeglad przypadków użycia 4.1 Sprawdzenie terminu kolokwiów i egzaminów Zalogowany Student wyraża chęć sprawdzenia, kiedy w najbliższym czasie ma kolokwia. System wyświetla jego terminarz. Student wybiera odpowiedni aspekt. System wyszukuje zdarzenia odpowiadające temu aspektowi. System przekazuje Studentowi wyniki wyszukiwania. System umożliwia Studentowi ponowne wyszukiwanie. 4.2 Sprawdzanie planu Znajomego Zalogowany Student wyraża chęć sprawdzenia planu Znajomego. System wyświetla listę Znajomych Studenta. Student wybiera Znajomego. System łączy się z USOSem i pobiera plan Znajomego. Jeśli pobranie udaje się, System prezentuje plan Studentowi. 7
4.3 Wgrywanie plików Zalogowany Student wyraża chęć wgrania pliku do systemu. System pobiera plik i w zależności od ograniczeń narzuconych na studenta wgrywa go. Nastepnie umożliwia Studentowi dodanie odpowiednich etykiet do pliku. 4.4 Dodanie ogłoszenia Firma wyraża chęć dodania ogłoszenia. System umożliwia podanie treści ogłoszenia. Firma podaje treść ogłoszenia. System pyta o adres kontaktowy Firmy. Firma podaje adres. System przekazuje ogłoszenia do weryfikacji Administratorowi. Po zaakceptowaniu ogłoszenia przez Administratora System zapisuje ogłoszenie wraz z innymi ogłoszeniami, tak aby było ono wyświetlane, gdy pojawi się żądanie obejrzenia ogłoszeń. 4.5 Odpowiadanie na ogłoszenie Student wyraża chęć obejrzenia ogłoszeń. System wyswietla ogłoszenia. Student wybiera interesujące go ogłoszenie i wyraża chęć odpowiedzenia na nie. System prosi o podanie treści odpowiedzi. Student wpisuje treść. System umożliwia dodanie CV na podstawie szablonu CV, o ile Student posiada taki szablon. Student wybiera szablon, modyfikuje go odpowiednio i zatwierdza. System wysyła odpowiedź na adres Firmy. 4.6 Sprawdzanie wyniku kolokwium znajomego Zalogowany Student wyraża chęć sprawdzenia wyniku kolokwium Znajomego. System wyświetla listę Znajomych Studenta. Student wybiera Znajomego. System łączy się z USOSem i pobiera listę kolokwiów, których wyniki są dostępne dla Znajomego. Jeśli pobranie powodzi się, System prezentuje listę Studentowi. Student wybiera interesujące go kolokwium. System łaczy się z USOSem i pobiera wynik kolokwium Znajomego. Jeśli pobranie udaje się System prezentuje wynik Studentowi. Student może powrócić do listy kolokwiów i wyrazić chęć obejrzenia innego wyniku. 5 Dekompozycja logiczna systemu 5.1 Omówienie System Usosweb 2.0 jest podzielony na warstwy. Podział ten został dokonany tak, by odpowiadał on podziałowi zadań systemu, a każda z warstw była logicznie niezależna od pozostałych. Dzięki uzyskaniu małych zależności między warstwami ułatwione są rozbudowa, testowanie i konserwacja systemu. 8
W systemie Usosweb 2.0 komunikacja następuję tylko z jednym zewnętrznym system USO- Sem. Komunikacja ta jest realizowana poprzez moduł Komunikacja z USOSem 9
5.2 Realizacje najważniejszych przypadków użycia 5.2.1 Realizacja przypadku użycia Wgrywanie pliku 10
5.2.2 Realizacja przypadku użycia Wyszukiwanie kolokwiów 6 Dekompozycja na procesy W systemie działa w rzeczywistości tylko jeden proces, a jego podziałem na wątki zajmuje się model J2EE. 11
7 Instalacja systemu 7.1 Ogólny opis Serwery WWW, aplikacji, baza danych oraz łączność z Serwerem USOS działać będa przy użyciu serweru JBoss. Zdecydowaliśmy się na ten serwer ponieważ oparty na licencji GNU LGPL i integruje wszystkie potrzebne funkcje. 8 Implementacja systemu 8.1 Omówienie Implementacja systemu USOSWeb 2.0 dzieli się na następujące, logicznie oddzielone od siebie warstwy, których szczegółowy opis zostanie podany w następnych podrozdziałach. 8.2 Warstwy 8.2.1 Interfejs Interfejs ma za zadanie udostępniać użytkownikowi dostęp do całej funkcjonalności systemu. Opiera się on na stronach WWW (ze względu na analogiczny aktualnie zaimplementowany interfejs USOSa), a także na komponentach Javy. Dzięki wydzieleniu warstwy interfejsu można 12
łatwo modyfikować wygląd systemu bez ingerencji w bardziej podstawowe jego elementy. Istotnym podsystemem interfejsu jest oparta na Javie Graficzna Reprezentacja Terminarza, która odzwierciedla jedną z najbardziej wyraźnych idei systemu USOSWeb 2.0. Komponent ten daje użytkownikowi kontrolę nad terminarzami oraz umożliwia modyfikację ich właściwości poprzez wygodny interfejs zbudowany na bazie Javy. 8.2.2 Aplikacja Warstwa Aplikacji zawiera funkcjonalność, z której bezpośrednio korzysta interfejs. Warstwa ta składa się z szeregu modułów, każdy zarządzający wybraną logiczną funkcjonalnością udostępniając warstwie interfejsu procedury i struktury danych. Jednakże odwołania do tej warstwy z interfejsu są wykonywane z poziomu użytkowników, co dodatnio wpływa na bezpieczeństwo, gdyż ewentualna luka w systemie nie powoduje naruszenia jego spójności. Niektóre podsystemy tej warstwy komunikują się bezpośrednio z podstawami USOSWeb 2.0 w celu archiwizacji danych w Bazie Danych i obsługi konta. 13
8.2.3 Model dziedziny 14
8.2.4 Usługi Warstwa ta definiuje usługi niewidoczne dla zwykłego użytkownika USOSWeb 2.0, natomiast być może konfigurowalne przez Administratora systemu. Najważniejszą z punktu widzenia tej warstwy usługą jest Obsługa Logowania Użytkowników. Jest to usługa o tyle ważna, że zapewnia przestrzeganie praw dostępu użytkowników dla warstw systemu znajdujących się wyżej. Stąd umieszczenie jej tak nisko w hierarchii systemu powoduje jej małą zależność od komponentów niżej i większą niezawodność. Ponadto jest to komponent uniwersalny, możliwy do wykorzystania w innych projektach programistycznych. 8.2.5 Podstawy Do warstwy podstaw systemu należą komponenty, na których wydajności i niezawodności nam zależy oraz których zależność od platformy jest większa. Dlatego też tutaj znajduje się moduł komunikacji z USOS-em. Jako, że USOS jest ciągle rozwijany, to sposób komunikacji z nim może się zmieniać w przeciągu czasu. Dzięki umieszczeniu komponentu Komunikacja z USOSem w podstawach liczba zmian wynikająca z modyfikacji USOS-a jest minimalna. Moduły warstwy podstawowej zostaną zaimplementowane częściowo jako Adaptery z wykorzystaniem procedur niskiego poziomu, co umożliwi w przyszłości obsługę różnych baz danych (np: MySQL, Oracle...) lub różnych systemów (Linux, Windows). 9 Wydajność systemu Wielkości dotyczące systemu: Liczba użytkowników na MIMie około 300 osób na pierwszym roku, odliczając tych, którzy nie zdają to jakieś 1100 studentów; na niektórych wydziałach nawet po 1000 osób na roku; liczba pracowników MIMu - niecałe 300; na większych wydziałach prawdopodobnie proporcjonalnie więcej. Rozmiar plików średnich rozmiarów plik z notatkami/zadaniami - ok. 100 kb; duży plik z treścią wykładu, slajdami - ok. 1 MB; rozsądna ilość miejsca dla studenta - np. 10 MB; rozsądna ilość miejsca dla pracownika - np. 30 MB; 15
Liczba dziennych wgrań plików średnio maksymalnie 30 (z lekkim nasieleniem przed/na początku sesji i w miesiącach obfitych w kolokwia - ostatnich miesiącach semestru). Liczba dziennych pobrań plików w ostatnim miesiącu semestru i na początku/w trakcie sesji: ok. 80; w pozostałych miesiącach ok. kilkanaście Oczekiwana wydajność: Wgranie 100 kb-ego pliku: poniżej 5 sek. Wgranie 1 MB-ego pliku: poniżej 45 sek. 10 Historia zmian $Log: 12 V 2007: Pierwsze rozdziały: wprowadzenie, omówienie, założenia i zależności. 13 V 2007: Dodano dekompozycję i implementację. 14 V 2007: Dodano wydajność. 16 V 2007: Dodano przegląd przypadków oraz instalację. 17 V 2007: Poprawki w instalacji. 16