Lokalna kopia bioinformatycznego serwera obliczeniowego jako wysokowydajne środowisko obliczeniowe Dokument wizji Autorzy: Łukasz Kempny, Tomasz Sikora, Tomasz Rokita, Robert Ostrowski, Zbigniew Polek, Utworzono: 23 listopada 2010 Zmodyfikowano: 23 listopada 2010 Odbiorcy: Aleksandra Gruca Wersja dokumentu: 1.0.6
Spis treści 1. Historia dokumentu... 3 1 Wprowadzenie... 4 1.1 Opis dokumentu... 4 1.2 Opis produktu... 4 1.3 Odniesienia... 4 2 Analiza wykonalności... 4 2.1 Definicja problemu... 4 2.2 Zespół... 4 2.3 Zagrożenia... 5 3 Użytkownicy... 5 3.1 Opis użytkowników... 5 3.2 Środowisko użytkowników... 5 3.3 Podstawowe potrzeby użytkowników... 5 4 Opis produktu... 6 4.1 Schemat produktu... 6 4.2 Założenia i zależności... 6 4.3 Słownik... 6 4.4 Wymagania funkcjonalne... 6 5 Model systemu... 7 5.1 Diagram przypadków użycia... 7 5.2 Diagramy sekwencji... 8 5.1.1. Rejestracja... 8 5.1.2. Logowanie... 8 5.1.3. Wysłanie zadania... 9 5.1.4. Węzeł obliczeniowy... 10 5.1.5. Węzeł zapasowy... 11 5.3 Diagramy aktywności... 12 5.3.1. Wyślij zadanie... 12 5.3.2. Zrealizuj zadanie... 12 5.3.3. Wyznacz węzeł... 13 5.3.4. Węzeł zapasowy... 13 5.4 Diagram wdrożenia... 14 6 Udziałowcy... 14 Wydrukowana wersja tego dokumentu jest nienadzorowana Strona 2 z 14
1. Historia dokumentu Wersja dokumentu Data Autor Zatwierdzono przez Dodatkowe informacje 1.0.0 2010-11-20 Tomasz Sikora Utworzenie dokumentu wizji 1.0.1 2010-11-21 Robert Ostrowski Dodanie analizy wykonalności 1.0.2 2010-11-22 Tomasz Sikora Dodanie wymagao produktu 1.0.3 2010-12-07 Łukasz Kempny Dodanie przypadków użycia 1.0.4 2010-12-22 Tomasz Sikora Dodanie diagramów aktywności, sekwencji 1.0.5 2011-01-05 Tomasz Rokita Dodanie diagramów wdrożenia 1.0.6 2011-01-19 Łukasz Kempny Ostatnie poprawki. Wydrukowana wersja tego dokumentu jest nienadzorowana Strona 3 z 14
1 Wprowadzenie 1.1 Opis dokumentu Celem dokumentu jest zebranie, analiza i definicja cech bioinformatycznego serwera obliczeniowego. 1.2 Opis produktu W dokumencie opisano wizję systemu, który umożliwia przechowanie lokalnej kopii serwera bioinformatycznego. System ten będzie umożliwiał użytkownikom wykorzystanie serwera jako wysokowydajne. 1.3 Odniesienia Następujące pliki są bezpośrednio związane z realizacją projektu: Nazwa PSK-Skrypty-bd.sql PSK-polecenia.txt kolejka.php wezel.php Opis Skrypty bazy danych. Polecenia i skrypty do backup u, pobierania plików i testów węzłów. Skrypty kolejkowania. Skrypty węzła. 2 Analiza wykonalności 2.1 Definicja problemu Projektowany system wysokowydajnego środowiska obliczeniowego, z założenia ma byd budowany w oparciu o narzędzia Open Source. W ten sposób do kosztorysu projektu nie wchodzą opłaty związane z licencjami. Wadą tego rozwiązania jest ograniczony wsparcie do narządzi Open Source oraz ich mniejsza funkcjonalnośd w porównaniu z płatnymi produktami. System ma byd tworzony w języku PHP i wykorzystywad środowisko bazodanowe PostgreSQL. Dokumentacja UML projektu ma byd tworzona w środowisku Star UML. Projekty tworzone w PHP cechują się dużą podatnością na luki w systemie zabezpieczeo, dlatego ważne jest, by twórcy systemu zwrócili szczególną uwagę na jego bezpieczeostwo. 2.2 Zespół Zespół realizujący projekt składa się z 7 osób. Osoby te są pracownikami różnych firm informatycznych i realizują projekt w ramach czasu wolnego. Członkowie zespołu dysponują wiedzą z różnych dziedzin informatyki, dlatego podział zadao powinien uwzględniad wiedzę i doświadczenie poszczególnych członków. Członkowie zespołu powinni co najmniej raz w tygodniu spotykad się na spotkaniach projektowych. Czas realizacji całości projektu (budowa systemu, testy i poprawa błędów) to 10 tygodni. Szacowany czas potrzebny na uruchomienie systemu to dwa miesiące, przy założeniu że każdy członek zespołu poświęci średnio 10 godzin, w ciągu tygodnia, na jego realizacje. Po jego uruchomieniu, planuje się przeprowadzenie testów systemu trwających 1 tydzieo, a Wydrukowana wersja tego dokumentu jest nienadzorowana Strona 4 z 14
znalezione błędy powinny byd poprawione w ciągu kolejnych tygodni. Po tym czasie system będzie można oficjalnie udostępnid użytkownikom. Zespół powinien na bieżąco monitorowad pracę gotowego systemu, poprawiad wykryte błędy, wprowadzad modyfikacje ułatwiające prace z systemem oraz rozbudowywad go zgodnie z oczekiwaniami użytkowników. 2.3 Zagrożenia Głównym zagrożeniem realizacji projektu może byd niewystarczająca ilośd czasu poświęcanego przez członków zespołu na jego realizacje oraz problem ze znalezieniem terminu na cotygodniowe spotkania projektowe. Po zrealizowaniu projektu może zabraknąd osób dbających o jego rozwój, dlatego ważne jest by pozyskad nowe osoby rozwijające projekt. Osoby te powinny byd w stanie rozwiązywad problemy związane np. ze zmianą parametrów i lokalizacji serwera GenBank oraz jego likwidacją. 3 Użytkownicy 3.1 Opis użytkowników Gośd - użytkownik nie posiadającym konta w systemie. Ma możliwośd rejestracji w systemie. Naukowiec - użytkownik posiadającego konto w systemie. Wykorzystanie systemu obliczeniowego. Administrator systemu - użytkownik opiekujący się systemem od strony informatycznej 3.2 Środowisko użytkowników Użytkownicy posiadają do dyspozycji interfejs graficzny. Jest to strona internetowa z możliwością autoryzacji. Po rejestracji i logowaniu użytkownik może w pełni korzystad z systemu obliczeniowego. Wszystkie opcje dostępne są z poziomu panelu administracyjnego. 3.3 Podstawowe potrzeby użytkowników Użytkownicy powinni mied możliwośd: pobrania najnowszych danych z GenBank wykonania obliczeo podglądu przetwarzanych danych pobrania wyników możliwośd ustawiania priorytetów dostęp do historii Wydrukowana wersja tego dokumentu jest nienadzorowana Strona 5 z 14
4 Opis produktu 4.1 Schemat produktu Użytkownik Wysyłanie żądania System obliczeniowy Przetwarzanie żądao w węzłach Wyniki Prezentacja wyników 4.2 Założenia i zależności Zakładamy, że implementacją algorytmu BLAST zajmuje się inny zespół projektowy. Dane genów pobieramy ze serwera FTP : ftp://ftp.ncbi.nih.gov/genbank/daily-nc/* 4.3 Słownik Gośd - niezarejestrowany użytkownik Naukowiec zarejestrowany użytkownik BLAST algorytm porównywania sekwencji zoptymalizowany do szybkiego używania do przeszukiwania biologicznych baz danych zawierających sekwencje Zadanie - zapytanie wysłane przez użytkownika (poszukiwanie sekwencji) Węzeł obliczeniowy realizuje zadanie Load Balancer (zarządca) serwer odpowiedzialny za przekierowywanie zadao do węzłów obliczeniowych Konto płatne daje użytkownikowi odpowiednio wyższy priorytet 4.4 Wymagania funkcjonalne Wymagania dodatkowo podzielone są na dwie grupy: ID REQ.C01 REQ.C01.1 REQ.C03 REQ.C04 REQ.C04.1 REQ.C05 REQ.C wymagania dot. obsługi systemu obliczeniowego REQ.S wymagania części serwerowej, baza danych, etc. Opis wymagania Rejestracja użytkownika: system umożliwia rejestrację użytkownika. Konta płatne: możliwośd wykupienia specjalnych kont płatnych. Logowanie: zarejestrowany użytkownik może zalogowad się na swoje konto. Wysłanie zadania: Zalogowany użytkownik powinien mied możliwośd wysłania zadania. Zabezpieczenia: System powinien byd odporny na próby wielokrotnego wysyłania zadao w krótkim czasie. Blokowanie wysyłania zadao po wysłaniu 3 zadao w ciągu 1 minuty. Wartości powinny byd konfigurowalne. Podgląd zadao: Zalogowany użytkownik powinien mied możliwośd podglądu postępu Wydrukowana wersja tego dokumentu jest nienadzorowana Strona 6 z 14
REQ.C06 REQ.S01 REQ.S01.1 REQ.S02 REQ.S02.1 REQ.S02.2 REQ.S02.3 wykonania oraz wyników zadao. Konfiguracja systemu: system powinien zapewniad panel konfiguracyjny dostęny po uwieżytelnieniu. Aktualizacja BD: automatyczny update lokalnej kopii bazy danych Obsługa błędów aktualizacji: System powinien precowad bez przerw w przypadku niepowodzenia / błędów aktualizacji Obsługa zadao: system powinien obsługiwad zapytania wysłane przez zalogowanych użytkowników. Load Balancing: zarządca powinien rozproszyd obciążenie pomiędzy węzły obliczeniowe. Wykonanie zadania: węzeł obliczeniowy powinien wykonad zadania dostępne w kolejce. Obsługa błędów: w przypadku awarii wezłów obliczeniowych, system powinien wykorzystad zapasowe węzły obliczeniowe. 5 Model systemu 5.1 Diagram przypadków użycia Wydrukowana wersja tego dokumentu jest nienadzorowana Strona 7 z 14
5.2 Diagramy sekwencji 5.1.1. Rejestracja 5.1.2. Logowanie Wydrukowana wersja tego dokumentu jest nienadzorowana Strona 8 z 14
5.1.3. Wysłanie zadania Wydrukowana wersja tego dokumentu jest nienadzorowana Strona 9 z 14
5.1.4. Węzeł obliczeniowy Wydrukowana wersja tego dokumentu jest nienadzorowana Strona 10 z 14
5.1.5. Węzeł zapasowy Wydrukowana wersja tego dokumentu jest nienadzorowana Strona 11 z 14
5.3 Diagramy aktywności 5.3.1. Wyślij zadanie 5.3.2. Zrealizuj zadanie Wydrukowana wersja tego dokumentu jest nienadzorowana Strona 12 z 14
5.3.3. Wyznacz węzeł 5.3.4. Węzeł zapasowy Wydrukowana wersja tego dokumentu jest nienadzorowana Strona 13 z 14
5.4 Diagram wdrożenia 6 Udziałowcy Imię i Nazwisko Dr inż. Aleksandra Gruca Łukasz Kempny Tomasz Sikora Tomasz Rokita Robert Ostrowski Piotr Rebajn Zbigniew Polek Tomasz Szypowski Szpitale, lekarze, badacze Rola Prowadząca projekt Nadzorujący projekt, wykonawca Wykonawca Wykonawca Wykonawca Wykonawca Wykonawca Wykonawca Perspektywiczni klienci Wydrukowana wersja tego dokumentu jest nienadzorowana Strona 14 z 14