Software Architecture Document czyli jak i dlaczego w 14 minut ;-) Łukasz Bieniasz-Krzywiec Dariusz Leniowski Jakub Łącki 23 maja 2007 1
Spis treści 1 Wprowadzenie 3 1.1 Cel............................................. 3 1.2 Zakres........................................... 3 1.3 Definicje.......................................... 3 1.4 Załączniki......................................... 3 2 Prezentacja architektury systemu 3 3 Założenia i zależności 4 4 Dekompozycja logiczna systemu 4 4.1 Omówienie........................................ 4 4.2 Najważniejsze komponenty................................ 6 4.2.1 Obsługa użytkownika............................... 6 4.2.2 Obsługa formularza................................ 6 4.2.3 Kontrola Praw Dostępu.............................. 6 4.2.4 Wiadomości systemowe............................. 6 4.2.5 Wyszukiwanie.................................. 6 4.2.6 Obsługa błędów................................. 7 5 Przeglad przypadków użycia 7 5.1 Realizacja tworzenia formularza............................. 8 5.2 Diagram Zależności.................................... 9 5.3 Diagramy przebiegu.................................... 10 6 Dekompozycja na procesy 11 7 Instalacja systemu 12 8 Implementacja systemu 12 9 Przechowywane dane 13 10 Wydajność systemu 13 11 Jakość 13 11.1 Przenośność........................................ 13 11.2 Elastyczność....................................... 14 11.3 Łatwość obsługi...................................... 14 11.4 Niezawodność....................................... 14 11.5 Bezpieczeństwo...................................... 14 12 Historia zmian 14 2
1 Wprowadzenie 1.1 Cel Dokument ten ma na celu zaprezentowanie architektury systemu oraz przedstawienie najważniejszych założeń, które stworzą fundamenty YapS. Dodatkowo opisane zostaną najistotniejsze rozwiązania techniczne, a także jakościowe cele projektu. 1.2 Zakres Na dokument składają się: opis architektury systemu, opis założeń i zależności, przegląd najważniejszych podsystemów, przegląd przypadków użycia, opis wdrożenia i implementacji, schemat przechowywania danych oraz przepływu informacji, opis założeń wydajnościowych i jakościowych projektu. 1.3 Definicje Definicje używanych terminów i skrótów znajdują się w załączonym słowniku. 1.4 Załaczniki 1. Słownik 2 Prezentacja architektury systemu YapS jest zaprojektowany jako architektura klient-serwer, za cały system jest odpowiedzialny serwer, który samodzielnie przetwarza wszelkie zapytania od klienta. Klient odpowiada tylko za wizualizację i zgłaszanie zapytań do serwera. Oddzielona, relacyjna baza danych YapS korzysta z relacyjnej bazy danych, która nie musi być zainstalowana na tym samym komputerze co sam system. Serwer składa się z czterech warstw, które są rozszerzeniem schematu MVC. Widok odpowiada View w MVC Prezenter odpowiada Controller Asystent jest to warstwa pośrednia, która upraszcza komunikację między Aplikacją a Modelem Model odpowiada Model w MVC 3
Szczegółowy opis z perspektywy podziału logicznego znajduje się w rozdziale 4. Szczegółowy opis z perspektywy przypadków użycia znajduje się w rozdziałach 5. Szczegółowy opis z perspektywy wdrożenia i implementacji znajduje się w rozdziałach 7 i 8. 3 Założenia i zależności Bezpieczeństwo System musi być wystarczająco zabezpieczony, by możliwe było umieszczenie w formularzach informacji poufnych. Dostęp do YapS będzie wymagał autoryzacji, z wykorzystaniem nazwy użytkownika i hasła. YapS będzie umożliwiał szyfrowanie danych przesyłanych między systemem a użytkownikiem. Zostanie to zrealizowane poprzez wykorzystanie możliwości serwera WWW - protokołu TLS. Niezawodność Wykorzystywany framework nie pozwala na zapisywanie danych w bazie danych w transakcjach, dlatego, aby zachować spójność danych, należy użyć mechanizmu triggerów. Wielojęzyczność YapS napisany zostanie w polskiej wersji językowej, jednak jego budowa musi pozwolić na wybór języka interfejsu. Dodanie nowego języka musi sprowadzać się do przetłumaczenia informacji wyświetlanych przez system (oraz niewielkich zmian konfiguracji). Wydajność System napisany będzie w języku skryptowym. Poza tym dostęp do bazy danych realizowany będzie z wykorzystaniem wzorca projektowego Active Record, który zwalnia programistę z konieczności pisania zapytań SQL. Niestety, czasem prowadzi to do powstania nieoptymalnych zapytań. Z tego względu, należy zwrócić uwagę, by podczas implementacji nie stworzyć kodu posiadającego niepotrzebne narzuty czasowe. 4 Dekompozycja logiczna systemu 4.1 Omówienie YapS został podzielony na cztery warstwy: Widok, Prezentera, Asystenta (Fasadę) i Model. Jest to podział dość standardowy, który pozwala w łatwy sposób utrzymywać i rozszerzać budowany system. Wybrano to podejście, gdyż jest powszechnie stosowane i sprawdziło się ono w wielu podobnych projektach. Jego podstawowe zalety to: odseparowywanie niepowiązanych części systemu od siebie, duża elastyczność tworzonego kodu. 4
5
Wyjaśnienie funkcji poszczególnych warstw: Widok jest odpowiedzialny za wizualizację działania systemu, działa w połączeniu z przeglądarką internetową zainstalowaną na komputerze użytkownika, Prezenter jest to logika, która odpowiada za obsługiwanie poleceń użytkownika, Asystent (Fasada) pełni funkcję pomocniczą, stanowi swoiste spoiwo pomiędzy abstrakcyjnymi częściami systemu jakimi są Widok i Prezenter, a Modelem, realizuje większość poleceń użytkownika. Jego użyteczność jest widoczna na diagramach przebiegu w rozdziale 5. Zastosowanie asystenta do niskopoziomowych operacji na obiektach modelu znacząco upraszcza protokół komunikacji użytkownika z systemem i ułatwia pracę nad wysokopoziomowymi warstwami YapS. Model jest odpowiedzialny za logiczne modelowanie danych w systemie. 4.2 Najważniejsze komponenty 4.2.1 Obsługa użytkownika Klasy z tego pakietu modelują użytkownika YapS oraz pamiętają jego dane, preferencje. Klasa Sesja reprezentuje pojedyncze logowanie użytkownika w systemie. 4.2.2 Obsługa formularza Formularze są modelowane w systemie za pomocą obiektów klasy Formularz. Każdy formularz jest przydzielony do konkretnej kategorii (klasa Kategoria). Na pojedynczy formularz składa się zbiór odpowiednio zestawionych komponentów. Klasa Komponent jest klasą abstrakcyjną, formularze mogą zawierać jedynie instancje jej konkretnych podklas. Każdy formularz może zostać wypełniony raz lub wiele razy. Takie zdarzenie modeluje klasa Wypełnienie. Na jej podstawie możliwe jest generowanie statystyk odpowiedzi na konkretne pytania z formularza. 4.2.3 Kontrola Praw Dostępu Użytkownicy są zrzeszeni w grupy (klasa Grupa). Każda grupa ma swojego właściciela i pamięta swoich członków. Grupom można nadawać zasady dostępu do formularzy (klasa ZasadaDostępu), które określają prawa dostępu członków danej grupy do konkretnego formularza. 4.2.4 Wiadomości systemowe Użytkownicy mogą przesyłać między sobą wiadomości (modelowane przez obiekty klasy Wiadomość). Służą one m.in. do zgłaszania chęci zapisu do grupy, zadawania pytań administratorowi, rozgłaszania informacji członkom swojej grupy. 4.2.5 Wyszukiwanie Ten pakiet zawiera logikę i metody pozwalające wyszukiwać w systemie interesujące formularze i grupy. 6
4.2.6 Obsługa błędów Klasa Błąd reprezentuje błędy w systemie. Każdy błąd ma swój kod i jest powiązany z konkretnym komunikatem, który jest w razie konieczności prezentowany użytkownikowi. 5 Przeglad przypadków użycia Najważniejsze przypadki użycia YapS to: tworzenie formularza, wypełnianie formularza, usuwanie formularza, przeglądanie statystyk, dodawanie praw dostępu, usuwanie praw dostępu, wysyłanie wiadomości systemowych. Przedstawimy teraz sposób realizacji tworzenia formularza. Pozostałe przypadki użycia są wykonywane analogicznie. 7
5.1 Realizacja tworzenia formularza Użytkownik loguje się w systemie i wchodzi na stronę z edytorem formularzy. Wybiera opcję: Nowy Formularz. System wyświetla pusty formularz gotowy do edycji. Użytkownik cyklicznie wybiera komponent do wstawienia, ustawia jego parametry i dodaje do formularza. Na koniec użytkownik nadaje stworzonemu w ten sposób dokumentowi nazwę, przydziela go do wybranej kategorii oraz określa dla niego prawa dostępu. Potem formularz jest zapisywany w bazie danych i udostępniany wypełniającym. 8
5.2 Diagram Zależności 9
5.3 Diagramy przebiegu Poniższy diagram przedstawia szczegółowo interakcje użytkownika z systemem podczas tworzenia formularza. Koncentrujemy się tu tylko na wysokopoziomowych warstwach systemu. Komunikacja z obiektami modelu odbywa się poprzez wygodny interfejs Asystenta - Fasady: 10
Rysunek 1: realizacja metody stworzformularz Rysunek 2: realizacja metody zapiszformularz Dwa powyższe diagramy to przykłady niskopoziomowych realizacji metod modułu FasadaObsługiFormularza. Demonstrują one jak prosta staje się obsługa formularzy dzięki zastosowaniu fasad i technologii Ruby On Rails. 6 Dekompozycja na procesy Wykorzystywane przez nas technologie Apache, Ruby On Rails, PostgreSQL zapewniają dekompozycje systemu YapS na procesy. 11
7 Instalacja systemu Na rysunku powyżej przedstawiono schemat instalacji systemu. Możliwe jest uruchomienie zarówno serwera WWW i Aplikacji oraz serwera bazy danych na jednym komputerze i tej właśnie konfiguracji uruchomimy YapS. W przypadku samodzielnej instalacji, ważne by połączenie pomiędzy serwerem WWW a serwerem bazy danych odbywało się po sieci o przepustowości nie mniejszej niż 100Mbit (prędkość typowej sieci LAN). Przy zakładanym obciążeniu (por. rozdz. 10) połączenie serwera z internetem powinno mieć prędkość co najmniej 1Mbit (zarówno download jak i upload). Serwer WWW będzie obsługiwany przez Apache w wersji 2 z obsługą HTTPS. Na tym samym komputerze zainstalowane będzie interpreter języka Ruby (wersja co najmniej 1.8.5) z biblioteką Ruby Gems, a także pakiet ImageMagick. Serwer bazy danych będzie działać w oparciu o PostgreSQL. Na komputerze zainstalowany będzie system Linux. Przy samodzielnej instalacji możliwe jest użycie innego serwera WWW (o ile wspiera HTTPS, CGI, FCGI), a także dowolnego systemu operacyjnego zgodnego z POSIX. Do uruchomienia systemu (w przypadku instalacji Aplikacji jak i bazy danych na jednym komputerze) potrzebny będzie komputer wyposażony w procesor o zegarze 2Ghz, 1GB pamięci RAM oraz dysk o pojemności 100GB. 8 Implementacja systemu Implementację systemu można podzielić na kilka zadań o stosunkowo niewielkim sprzężeniu, zgodnie z podziałem systemu na warstwy (por. rozdz. 4). Zadania te można rozdzielić pomiędzy członków zespołu. Implementacja każdej z warstw polegać będzie głównie na stworzeniu plików źródłowych w języku Ruby. Poza tym, koniecznie będzie napisanie skryptu w języku SQL, który stworzy tabele w bazie danych, a także skryptu w języku YAML, pozwalającego skryptom języka Ruby na korzystanie z bazy danych zgodne ze wzorcem projektowym Active Record. Przy tworzeniu warstwy Widoku, trzeba będzie napisać szablony stron WWW oraz narysować obrazki na nich wyświetlane. 12
9 Przechowywane dane Zawartość bazy danych będzie uporządkowana według poniższego modelu. 10 Wydajność systemu Zakładamy następujące obciążenie systemu: ilość zarejestrowanych użytkowników: do 50000, ilość jednocześnie zalogowanych użytkowników: do 100. Takie obciążenie pozwoli na odpowiedź systemu w ciągu 2 sekund, w przypadku gdy interakcja z użytkownikiem nie wymaga przesłania dużej ilości danych (na przykład pliku o dużym rozmiarze). W przeciwnym razie, do czasu odpowiedzi należy dodać czas potrzebny na transmisję danych, w głównej mierze zależny od szybkości łącza internetowego. 11 Jakość 11.1 Przenośność YapS powinien być systemem przenośnym tak, aby do korzystania z pełnej funkcjonalności była potrzebna jedynie przeglądarka z dostępem do internetu i wbudowaną obsługą potrzebnej nam technologii AJAX. Przy projektowaniu nie ograniczyliśmy się tylko do upraszczania strony użytkownika. YapS nie powinien potrzebować egzotycznej konfiguracji dedykowanego systemu, ważne jest aby z łatwością można go było zainstalować na tradycyjnym serwerze. 13
11.2 Elastyczność YapS został zaprojektowany z myślą o dalszym rozwoju, nie jest zamknięty na innowację. Połączenia między komponentami są ograniczone do minimum, co powinno ułatwić modyfikacje i rozszerzenia systemu. Warto zwrócić uwagę na elastyczność stosowanych technologii, aby nie ograniczać potencjału YapS. 11.3 Łatwość obsługi Obsługa YapSpowinna być intuicyjna tak, aby niezaawansowany użytkownik posiadający podstawową wiedzę dotyczącą obsługi komputera i standardowej przeglądarki internetowej, był w stanie nie tylko wypełnić test lub ankietę, ale także stworzyć swoje własne egzaminy. Nie jest to podstawowa kwestia, jednak trzeba wspomnieć, że podjęte decyzje projektowe uwzględniały potrzebę bycia łatwym do instalacji i obsługi dla administratorów. Osiągnięte to będzie przez przygotowanie gotowych schematów, dzięki którym instalacja systemu nie będzie przysparzała problemów. 11.4 Niezawodność Ze względu na specyfikację projektu, ważne jest aby w trakcie działania system był stabilny i odporny na przeciążenia, przewidujemy jednak możliwość niedługich przerw technicznych w celu administracji systemu. 11.5 Bezpieczeństwo Ze względu na poufność danych przechowywanych w YapS system musi oferować wysoki poziom bezpieczeństwa. Będzie to osiągnięte dzięki zastosowaniu sprawdzonych schematów dotyczących szyfrowania i autoryzacji. 12 Historia zmian 0.1 - wersja z szablonu 0.2 - napisane rozdziały 7-9 0.3 - dodałem rozdziały 2 i 10 0.4 - dodano wprowadzenie 0.5 - dodano jakość 0.6 - dodano prezentacje architektury 0.7 - strona tytułowa i spis treści 0.8 - edycja tresci wszystkich rozdzia\l\,ow 0.9 - edycja grafiki 0.10 - spellchecking 0.11 - dostrojenie rozmiarów grafiki 14