Teleradiologia. Rzeczy godne uwagi w projekcie. Historia zmian. Version <1.0>

Transkrypt

1 Teleradiologia Rzeczy godne uwagi w projekcie Version <1.0> Historia zmian Data Wersja Opis Autor Stworzenie dokumentu Wojciech Marks

2 Spis treści 1. Wprowadzenie Cel Zakres Wybrane stosowane wtyczki do środowiska Eclipse Hibernate Tools JAutodoc Jindent Wybrane stosowane rozwiązania w projekcie Mechanizm masterpage Message.properties Formularze XML Bezpieczeństwo Automatyczna inicjalizacja Rozwiązania dotyczące testowania projektu Testy wydajnościowe Testy funkcjonalne Testy jednostkowe oraz integracyjne Testy wydajnościowe bazy danych Inne narzędzia stosowane w projekcie Repozytorium SVN Grupa dyskusyjna Wiki projektu oraz bugtracker Zaawansowane narzędzia do korzystania z SVN Środowisko ciągłej integracji Konfiguracja serwera projektu Fizyczny serwer Serwer bazy danych Build-proces Automatycznie przeprowadzane testy Raporty i wykresy Historia integracji Lista stosowanych narzędzi...7

3 Rzeczy godne uwagi w projekcie 1. Wprowadzenie 1.1 Cel Dokument ma na celu przedstawienie rzeczy godnych uwagi w projekcie: stosowane technologie, narzędzia, rozwiązania oraz konfigurację projektu. 1.2 Zakres Dokument obejmuje opis wykorzystywanych wtyczek do środowiska Eclipse, stosowanych technologii, opis ciekawych rozwiązań wykorzystanych w projekcie oraz opis konfiguracji projektu. 2. Wybrane stosowane wtyczki do środowiska Eclipse 2.1 Hibernate Tools Wtyczka do automatycznego tworzenia klas DAO do Hibernate na podstawie schematu bazy danych pobieranego z samej bazy. Stosujemy zmodyfikowane przez siebie szablony do wytwarzania kodu tych klas, aby dostosować je do naszych wymagań. 2.2 JAutodoc Automatyczne tworzenia zalążków komentarzy do dokumentu Javadoc na bazie kodu źródłowego. Zaoszczędza wiele pracy przy uzupełnianiu komentarzy. 2.3 Jindent Wtyczka do formatowania kodu źródłowego w celu dostosowania do standardu kodowania, działająca lepiej niż wbudowane w Eclipse formatowania kodu, a także bardziej konfigurowalna. Wtyczka płatna, korzystaliśmy z darmowej 30-dniowej wersji testowej. 3. Wybrane stosowane rozwiązania w projekcie 3.1 Mechanizm masterpage Framework Spring nie posiada wbudowanego mechanizmu masterpage, dlatego stosujemy taki mechanizm wspierany na poziomie samego Apache'a.

4 3.2 Message.properties Nasze komunikaty i etykiety są oddzielone od kodu biznesowego. Wykorzystujemy mechanizm Javy do ładowania tych etykiet z plików messages.properties. Daje to możliwość internacjonalizacji naszego systemu. 3.3 Formularze XML Do wykonywania opisów oraz ich wyświetlania stosujemy dynamicznie tworzony kod HTML (formularze oraz wyświetlanie), tworzony na podstawie dokumentów XML z bazy danych. Wyniki też są zapisywane jako pliki XML w bazie konwertuje je automatycznie generowany skrypt Javascript, dzięki czemu wg frameworka Spring nasz dynamiczny formularz składa się z tylko jednego pola ukrytego. 3.4 Bezpieczeństwo Stosujemy nie tylko autentykację użytkowników, ale także ich autoryzację (wykrywanie uprawnień), którą potrafiliśmy zintegrować ze Springiem, mimo że dane o użytkownikach przechowujemy w bazie o ustalonym przez nas schemacie. Hasła są przechowywane w bezpiecznej postaci mieszane z użyciem soli. 3.5 Automatyczna inicjalizacja Stosujemy ciekawe techniki automatycznego inicjalizowania pól naszych beanów za pomocą 4. Rozwiązania dotyczące testowania projektu 4.1 Testy wydajnościowe Testy wydajnościowe wykonujemy za pomocą narzędzia JMeter. Jest ono uruchamiane na serwerze projektu, więc aby zasymulować dostęp do serwisu z Internetu a nie sieci lokalnej wykorzystujemy darmowe proxy w Niemczech. 4.2 Testy funkcjonalne Testy funkcjonalne wykonujemy z użyciem narzędzia Selenium HQ. Również są one uruchamiane na serwerze projektu wykonywane są w trybie graficznym, mimo iż serwer nie używa trybu graficznego (wykonywane są z użyciem Firefoksa na zdalnym pulpicie, do którego nie podłącza się żaden użytkownik dzięki temu mogą wykonać się automatycznie). 4.3 Testy jednostkowe oraz integracyjne Poza testami funkcjonalnymi i wydajnościowymi stosujemy też testy jednostkowe i testy integracyjne wykonywane z użyciem JUnit. Nasze testy integracyjne są uruchamiane w ramach transakcji cofanych po każdym teście. Umożliwia to elastyczną pracę na bazie testowej bez obawy o zmianę jej stanu.

5 4.4 Testy wydajnościowe bazy danych W fazie opracowania zostały wykonane testy wydajnościowe bazy danych. Zostały one wykonane z wykorzystaniem narzędzia TGrk udostępnionego przez dr. Lecha Tuzinkiewicza, natomiast baza danych została wypełniona przez napisane przez nas narzędzie DataFiller (dołączone do projektu). 5. Inne narzędzia stosowane w projekcie 5.1 Repozytorium SVN Najpierw korzystaliśmy z repozytorium na serwisie Assembla, potem z serwisu GoogleCode. Konfiguracja środowiska wytwórczego na serwerze SVN jest przystosowana do środowiska Eclipse, ale potrafi sobie poradzić z systemem operacyjnym Windows XP jak i Windows Vista u developera. Aby ułatwić konfigurację, wszystkie niezbędne biblioteki również są trzymane w strukturze projektu na serwerze SVN. Na SVN trzymana jest również ta dokumentacja projektu, która ma swoją wersję papierową. 5.2 Grupa dyskusyjna Ponieważ GoogleCode po każdej zmianie na SVN potrafi wysłać maila o zmianach tylko na jeden adres. Dlatego założyliśmy grupę dyskusyjną Afrodyta, która rozsyła otrzymane maile od GoogleCode dalej do innych członków zespołu, automatycznie. 5.3 Wiki projektu oraz bugtracker Korzystamy z portalu GoogleCode, gdzie wymieniamy (publikujemy) doświadczenia na stronach wiki oraz wykorzystujemy udostępniony tam bugtracker. Portal daje możliwość zgłaszania uwag o błędach, propozycji nowych opcji itp. 5.4 Zaawansowane narzędzia do korzystania z SVN Korzystaliśmy z linuksowych narzędzi zarządzania repozytorium SVN. Narzędzie svnsync pozwoliło nam sklonować stare, uszkodzone repozytorium (serwis Assembla) i odtworzyć je na innym serwisie (GoogleCode) mimo że nie mieliśmy do niego bezpośredniego, administracyjnego dostępu). Podczas całej operacji nie utraciliśmy ówczesnej historii zmian. 5.5 Środowisko ciągłej integracji Wykorzystujemy serwer Hudson jako środowisko ciągłej integracji. Więcej o tym narzędziu w punkcie 6.

6 6. Konfiguracja serwera projektu W tym punkcie omówiona zostanie konfiguracja serwera naszego projektu. 6.1 Fizyczny serwer Mamy własny serwer (Hefajstos) z systemem operacyjnym Debian, serwerem Apache oraz serwerem Tomcat. Fizycznie stoi on w domu administratora, Tomasza Poręby i jest to komputer przeznaczony tylko do tego celu. Serwer posiada publiczne IP oraz dynamicznie przydzielaną darmową domenę, hefajstos.no-ip.org. Serwerem można zarządzać tylko zdalnie: w trybie tekstowym z użyciem SSH (każdy członek zespołu ma konto oraz uprawnienia do sudo) lub przez interfejs WWW udostępniany przez program Webmin. Sam serwer nie posiada on urządzeń wejściowych ani monitora. Dodatkowo, aby umożliwić rozliczenia za koszty energii pobierane przez serwer specjalny serwis co 2 minuty sprawdza, czy serwer jest aktywny. Administrator dostaje informacje pocztą elektroniczną o tym, że serwer się uruchomił oraz że przestał działać, a także raporty na temat tzw. up time serwera. 6.2 Serwer bazy danych Na serwerze jest lokalny serwer bazy danych, PostgreSQL 8.1. Można nim zarządzać zdalnie jak również przez interfejs WWW. 6.3 Build-proces Na początku po każdej zmianie na SVN uruchamiany był build-proces na serwerze GoogleCode wchodził na specjalny link na serwerze, uruchamiając build-proces projektu. Obecnie serwer co 10 minut sprawdza czy nie ma jakichś zmian na SVN i zaczyna budować projekt, jeżeli takie były. Zapobiega to przeciążeniu serwera, kiedy jest dużo zmian na SVN. Build-proces wykorzystuje Anta (napisane zostały specjalne skrypty do tego narzędzia), aby pobrać najnowszą wersję projektu z SVN oraz ją zbudować. Dzięki temu build-proces nie jest zależny ani od systemu operacyjnego, ani od środowiska programistycznego, teoretycznie możliwe jest korzystanie z serwera z użyciem środowiska NetBeans lub innego IDE. Build można uruchomić też zdalnie za pomocą interfejsu WWW Hudson (po zalogowaniu). Po każdym buildzie aplikacja jest automatycznie usuwana z serwera Tomcata oraz automatycznie jest udostępniana nowa wersja aplikacji (zapisano to w skrypcie Anta). Jest ona zawsze dostępna pod adresem Automatycznie przeprowadzane testy Korzystając z serwera Hudson można uruchomić poprzez interfejs WWW (po zalogowaniu) automatyczne przeprowadzenie testów wydajnościowych oraz funkcjonalnych. Specyfikacja przypadków testowych dla JMeter oraz Selenium HQ przechowywana jest na serwerze SVN.

7 6.5 Raporty i wykresy Po każdym buildzie Hudson przez interfejs WWW udostępnia: automatycznie wygenerowany Javadoc na podstawie kodu z SVN, wyniki testów JUnit (wykres i raport szczegółowy), wyniki testów wydajnościowych (raport), wyniki testów funkcjonalnych (wykres i raport), badane za pomocą narzędzia Emma pokrycie kodu testami na poziomie metod, bloków, klas i linii kodu (wykresy i raporty), badana za pomocą narzędzia Checkstyle: liczba naruszeń przyjętego stylu kodowania (wykresy i bardzo szczegółowe raporty), liczba zadań to wykonania zapisanych w kodzie (wykresy i raporty), ilość duplikowanego kodu (wykresy oraz raporty) oraz badane zależności w kodzie za pomocą narzędzia JDepend (raport). Widoczne jest też aktualne zużycie przestrzeni dyskowej na serwerze (wykresy). 6.6 Historia integracji Przez interfejs webowy Hudsona można obejrzeć podsumowania, raporty oraz wykres również dla historycznych buildów. 7. Lista stosowanych narzędzi Hibernate Tools JAutodoc Jindent JMeter Selenium HQ TGrk testy bazy danych DataFiller wypełnianie bazy danych, własne narzędzie SVN własna grupa dyskusyjna GoogleCode wiki GoogleCode bugtracker svnsync Hudson system ciągłej integracji Ant JDepend Emma Checkstyle