diploman-1 – internetowy system zarządzania pracami dyplomowymi

Transkrypt

Politechnika Poznańska
Wydział Informatyki i Zarządzania
Instytut Informatyki
Praca dyplomowa inżynierska
DIPLOMAN-1 – INTERNETOWY SYSTEM
ZARZĄDZANIA PRACAMI DYPLOMOWYMI
Krzysztof Kaszkowiak, 71310
Robert Przybylski, 71356
Paweł Walczuk, 71381
Promotor
dr hab. inż. Jerzy Nawrocki, prof. PP
Poznań, 2008 r.
Tutaj przychodzi karta pracy dyplomowej;
oryginał wstawiamy do wersji dla archiwum PP, w pozostałych kopiach wstawiamy ksero.
’
Podziękowania
Autorzy pragnęliby serdecznie podziękować
Panu dr. hab. inż. Jerzemu Nawrockiemu oraz
Panu mgr inż. Bartoszowi Michalikowi
za zaangażowanie i pomoc udzieloną w trakcie realizacji niniejszej pracy.
Autorzy kierują podziękowania również do firmy Talex S.A.
za udostępnione pomieszczenia i sprzęt.
I
Spis treści
1 Wprowadzenie
1
1.1
Opis problemu i koncepcja jego rozwiązania . . . . . . . . . . . . . . . . . . . . . .
1
1.2
Omówienie pracy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2
2 Opis procesów biznesowych
3
2.1
Aktorzy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
2.2
Obiekty biznesowe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
2.3
Scenariusze operacyjne . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
2.3.1
Wprowadzenia niezbędnych danych do systemu . . . . . . . . . . . . . . . .
7
2.3.2
Wyznaczenie promotorów i przygotowanie propozycji tematów . . . . . . .
7
2.3.3
Zatwierdzenie propozycji tematów . . . . . . . . . . . . . . . . . . . . . . .
7
2.3.4
Prodziekan akceptuje listę tematów . . . . . . . . . . . . . . . . . . . . . . .
8
2.3.5
Tworzenie zespołów i zgłaszanie ich do tematów . . . . . . . . . . . . . . .
8
2.3.6
Wybranie zespołu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8
3 Wymagania funkcjonalne
9
3.1
Administrator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
3.2
Kierownik zakładu / katedry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11
3.3
Promotor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12
3.4
Prodziekan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13
3.5
Student . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13
4 Wymagania pozafunkcjonalne
15
4.1
Modyfikowalność . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15
4.2
Użyteczność . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15
4.3
Bezpieczeństwo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15
4.4
Wydajność . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15
5 Architektura systemu
17
5.1
Fizyczne rozmieszczenie modułów . . . . . . . . . . . . . . . . . . . . . . . . . . . .
17
5.2
Wzorzec projektowy MVC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
17
5.3
Opis wykorzystanych techonologii . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18
5.3.1
Apache Tomcat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18
5.3.2
Apache Struts 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18
5.3.3
Apache Velocity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
19
5.3.4
Java Servlets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
19
5.3.5
Hibernate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
20
5.3.6
System składu tekstu
LAT
EX . . . . . . . . . . . . . . . . . . . . . . . . . . .
III
20
IV
Spis treści
6 Opis implementacji
6.1
6.2
6.3
21
Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
21
6.1.1
Schemat bazy danych . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
21
6.1.2
Klasy wykorzystywane do modyfikacji danych . . . . . . . . . . . . . . . . .
21
6.1.3
Klasy wyjątków . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
24
6.1.4
Klasy pomocnicze . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
25
Kontroler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
25
6.2.1
6.2.2
Interceptory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Filtry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
25
26
6.2.3 Akcje . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Widok . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
26
26
7 Zapewnianie jakości
29
7.1
Przeglądy kodu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
29
7.2
7.3
Testy jednostkowe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Testy systemowe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
29
29
7.4
Testy akceptacyjne . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
30
8 Zarządzanie wersjami
31
9 Weryfikacja osiągnięcia celów biznesowych
33
10 Zebrane doświadczenia
35
A Wkład poszczególnych osób do przedsięwzięcia
37
B Opinia klienta
39
C Słownik pojęć i skrótów
41
D Kod źródłowy systemu (CD)
43
Literatura
45
Rozdział 1
Wprowadzenie
1.1
Opis problemu i koncepcja jego rozwiązania
Na Wydziale Informatyki i Zarządzania Politechniki Poznańskiej studia są prowadzone w ramach makrokierunku „Automatyka i zarządzanie” (w skrócie AiZ) oraz dwóch kierunków: „Informatyka” (INF) i „Zarządzanie”. Studia na AiZ i INF są realizowane jako 2-stopniowe. Pierwszy
stopień trwa 7 semestrów i kończy się pracą dyplomową inżynierską. Studia II stopnia trwają
3 semestry i kończą się pracą dyplomową magisterską. Wydawanie i przydzielanie tematów prac
dyplomowych rodzi pewne trudności. Co roku pracownicy zaangażowani w proces spotykają się
z następującymi problemami:
• wybór promotorów, którzy w danym roku będą prowadzili prace oraz rozdzielenie liczby
tematów
• modyfikacje i propagacja zmian w dokumentach kart prac dyplomowych
• sprawdzanie terminowości wydawania kart prac dyplomowych
• nadzorowanie postępu procesu wydawania tematów prac (łącznie z oceną merytoryczną ich
zawartości)
Również studenci, których głównym celem jest wybranie jak najciekawszego i rozwijającego tematu
pracy, spotykają się z kilkoma problemami:
• dostęp do listy tematów (brak centralnego repozytorium dostępnego elektronicznie, które
mogłoby ułatwić wyszukiwanie interesujących tematów)
• brak dostępu do informacji o zakresie prac (dane takie bardzo często można wydostać jedynie
kontaktując się bezpośrednio z promotorem pracy) utrudniający proces wyboru tematu pracy
• brak informacji o wolnych tematach (studenci często dowiadują się, że interesująca ich praca
jest już zajęta, dopiero w momencie wizyty u promotora)
Potrzebna jest więc kontrola procesu wydawania i przydzielania tematów prac inżynierskich, by
ułatwić komunikacje między osobami zaangażowanymi w proces, a także skoordynować i wspomóc
prace. Dotychczas ta kontrola była realizowana żęcznie”. Niestety, ze względu na dużą ilość danych
(w roku 2006 na AiZ i na INF było łącznie ponad 70 prac inżynierskich, w których uczestniczyło
ponad 200 studentów) kontrola ta nie była efektywna. Z jednej strony zabierała dużo czasu pracownikom dziekanatu i (w mniejszym stopniu) prodziekanowi, z drugiej strony zebrane dane były
prezentowane z dość dużym opóźnieniem. Wskutek tego panował chaos informacyjny.
Aby rozwiązać opisany problem należałoby zbudować internetowy system zarządzania pracami
dyplomowymi, który umożliwiłby wybór promotorów, zbieranie propozycji tematów prac oraz ich
wydawanie studentom.
1
2
Wprowadzenie
1.2
Omówienie pracy
Niniejszy dokument zawiera opis systemu DiploMan-1, mającego służyć jako internetowy system zarządzania pracami dyplomowymi. Dokument ten jest adresowany przede wszystkim do
osób, które będą miały zajmować się utrzymaniem sprawności opisywanego systemu. Jest to jednocześnie praca dyplomowa inżynierska i z tego względu adresatami są również członkowie komisji
egzaminacyjnej.
Poszerzony opis koncepcji rozwiązania problemu widzianej od strony operacyjnej przedstawiono
w rozdziale 2. Przedstawiono tam opis najważniejszych ról, czyli głównych aktorów procesów biznesowych, obiekty biznesowe przekazywane między aktorami (są to odpowiedniki tradycyjnych
dokumentów) oraz scenariusze operacyjne opisujące jak przepływa informacja między aktorami.
Szczegółowa specyfikacja wymagań jest przedstawiona w rozdziałach 3. i 4. Pierwszy z nich opisuje
wymagania funkcjonalne, które zostały uporządkowane według aktorów, a w drugim zawarto wymagania pozafunkcjonalne. W rozdziale 5. czytelnik znajdzie opis architektury systemu, który na
wysokim poziomie abstrakcji opisuje przyjęte rozwiązanie. Bardziej szczegółowy opis implementacji jest przedstawiony w rozdziale 6, w którym opisano charakterystykę poszczególnych części
systemu i relacji zachodzącymi między nimi. Proces zapewniania jakości produktu przedstawiono
w rozdziale 7. Opisano w nim metody testowania oprogramowania oraz uzyskane wyniki na poszczególnych etapach pracy. Sposób zarządzania kolejnymi wersjami systemu przedstawiono w rozdziale 8. Opisano w nim użyte oprogramowanie i serwery. W rozdziale 9. opisano przyjęte metody
weryfikacji osiągnięcia celów biznesowych. W rozdziale 10. przedstawiono problemy na jakie napotkano w trakcie tworzenia systemu, sposoby ich rozwiązania oraz inne spostrzeżenia dotyczące
rozwiązywanego problemu.
Na końcu pracy załączono dodatki poindeksowane literami A-D. W dodatku A przedstawiono
udział w pracy poszczególnych członków zespołu. Opinia klienta na temat stworzonego systemu
znajduje się w dodatku B. W części C przedstawiono słownik pojęć i skrótów użytych w niniejszej
pracy. Do pracy dołączono również opisaną płytę CD z kodem źródłowym systemu, która stanowi
dodatek D pracy.
Rozdział 2
Opis procesów biznesowych
2.1
Aktorzy
Budowany system ma za zadanie w jak największym stopniu odwzorować procesy zachodzące
w świecie rzeczywistym i przenieść je do świata wirtualnego. Użytkownicy korzystający z systemu
(aktorzy) są to osoby, które podczas standardowej procedury uczestniczą w procesie zbierania
propozycji tematów prac inżynierskich oraz wydawania ich studentom. Osobami tymi są kierownicy poszczególnych zakładów bądź katedr, prodziekan, promotorzy oraz studenci. Dodatkowo na
potrzeby systemu stworzony został dodatkowy użytkownik – administrator, pełniący rolę nadzorczą nad systemem. Jako aktorów pełniących rolę pomocniczą w procesie, ale nie występujących
w systemie jako jednostki funkcjonalne, należy wymienić pracowników dziekanatu, którzy określają
ilu studentów jest na ostatnim semestrze studiów inżynierskich i od których administrator otrzymuje listę studentów danego roku w celu wprowadzenia ich do systemu. Podobnie administrator
może zgłosić się z prośbą do dziekanatu w celu otrzymania listy pracowników wraz z ich danymi
potrzebnymi w systemie. Schemat zależności pomiędzy aktorami przedstawia rysunek 2.1
Rysunek 2.1: Diagram zależności pomiędzy aktorami i systemem
Kierownicy jednostek (zakładów/katedr) zarządzają listą promotorów w swoim zakładzie.
Mogą wskazywać osoby ze swojego zakładu/katedry, które widzieliby w roli promotorów prac.
Mają również możliwość dodawania do bazy danych nowych pracowników w swoim zakładzie,
w przypadku jeśli administrator tego nie zrobił. Decydują również o losie zgłoszonych przez promotorów propozycji tematów prac – mogą je zaakceptować, odrzucić jak również komentować.
3
4
System komentarzy pozwala w łatwy sposób przesyłać informacje między kierownikiem a promotorem dotyczące konkretnego tematu.
Prodziekan jako osoba wyżej w hierarchii nadzoruje prace kierowników poszczególnych jednostek. Ma wgląd do wszystkich prac zaakceptowanych przez kierowników oraz prac oczekujących
na akceptacje. Tematy odrzucone nie są wyświetlane prodziekanowi. Lista wszystkich zweryfikowanych i przyjętych przez kierowników tematów jest zatwierdzana przez prodziekana, aby mogła
zostać przedstawiona studentom. Prodziekan ma do wglądu również listę studentów.
Promotor to osoba, którą wskazuje kierownik zakładu bądź katedry. Do jego zadań należy
przygotowanie propozycji tematów prac według obowiązującego szablonu oraz wskazanie informacji
dodatkowych jakie chciałby uzyskać od studentów zgłaszających się do danej pracy. Po zgłoszeniu
się studentów promotor wybiera odpowiadający mu zespół i generuje kartę pracy.
Studenci to osoby, których obowiązkiem jest połączyć się w zespoły maksymalnie 4-osobowe.
Każdy zespół posiada tymczasowego lidera – jest nim osoba, która założyła zespół w systemie.
Lider zarządza składem zespołu, przyjmując i odrzucając zgłoszone kandydatury (każdy student
ma możliwość zgłoszenia chęci zapisania się do istniejącej już grupy bądź stworzenia własnej).
Kompletny zespół zgłasza swoje zainteresowanie konkretną pracą poprzez zgłoszenie się dno niej
(informacja o zgłaszającej się grupie studentów jest od razu widoczna dla promotora).
Administrator jak już wspomniano pełni w systemie funkcje nadzorczą. Do jego zadań
należy wprowadzanie do systemu listy studentów danego kierunku (otrzymanej z dziekanatu) oraz
dodawanie pracowników wraz z ich danymi osobowymi. Do obowiązków administratora należy
również zarządzanie wydziałami, instytutami oraz zakładami (dodawanie, usuwanie i modyfikacja),
a także wprowadzanie do systemu informacji o kierownikach na wydziale. Pełni on kluczową rolę
w systemie, gdyż wprowadza dane niezbędne do pracy pozostałych użytkowników.
2.2
Obiekty biznesowe
Obiektami biznesowymi w opisywanym systemie są zarówno obiekty mające bezpośrednie odpowiedniki w realnym świecie, jak również takie, które nie występują w odwzorowywanej rzeczywistości, ale pełnią rolę pomocniczą podczas procedury wydawania tematów prac, w tym pełniące
funkcję informacyjną dla użytkowników. Obiektami tymi są propozycje tematów prac zgłaszane
przez promotorów, lista prac zaakceptowanych przez kierowników widoczna dla prodziekana, lista
prac dla studentów, zestawienie prac zaakceptowanych z listą zgłoszonych studentów, zestawienie
pracowników zakładu, a także zestawienie promotorów danego zakładu. Bardzo ważnym obiektem
biznesowym jest karta pracy generowana przez każdego z promotorów.
Propozycje tematów prac jest to zbiór tematów jakie zgłosił promotor. Zostają one przedstawione kierownikowi zakładu, w którym pracuje dany promotor. Kierownik akceptuje, bądź
odrzuca poszczególne propozycje, jak również może zgłosić komentarz do tematu, celem zasugerowania promotorowi zmian. Po zaakceptowaniu propozycji staje się ona obowiązującym tematem
pracy dyplomowej i nie może być już modyfikowana przez promotora. Rysunek 2.2 przedstawia
przykładową listę propozycji tematów prac.
Lista prac zaakceptowanych przez kierowników zakładów jest zbiorem wszystkich prac,
które przeszły weryfikacje i zostały zaaprobowane przez kierowników poszczególnych jednostek.
Lista wszystkich takich prac na wydziale (z możliwością filtrowania względem instytutu, zakładu
i kierunku) zostaje przedstawiona prodziekanowi. Po zaakceptowaniu całej listy przez prodziekana jest ona przedstawiana studentom, którzy mają do wglądu tylko prace przeznaczone dla ich
kierunku. Rysunek 2.3 przedstawia taką przykładową listę.
5
2.2. Obiekty biznesowe
Rysunek 2.2: Propozycje tematów prac
Rysunek 2.3: Lista zaakceptowanych prac
6
Do zaakceptowanych prac zgłaszają się studenci. Powstaje lista prac z wyszczególnionymi
nazwiskami studentów, którzy zgłosili chęć pisania danej pracy. Zestawienie takie jest widoczne
dla każdego promotora, który może następnie zarządzać zgłoszeniami do prac.
Zestawienie pracowników zakładu jest listą do której dostęp ma kierownik danego zakładu. Oprócz przeglądania spisu pracowników, daje ona możliwość dodawania nowych osób,
a także usuwania bądź modyfikowania danych już wprowadzonych. Rysunek 2.4 przedstawia takie
przykładowe zestawienie.
Rysunek 2.4: Zestawienie pracowników zakładu
Zestawienie promotorów jest listą osób które dany kierownik wskazał jako promotorów
w swoim zakładzie. Listę tą można modyfikować – dodawać, usuwać promotorów oraz zmieniać
przypisaną im maksymalną liczbę proponowanych tematów i realizowanych prac. Rysunek 2.5
przedstawia takie przykładowe zestawienie.
Rysunek 2.5: Zestawienie promotorów
Karta tematu pracy dyplomowej opisuje dokładnie każdą pracę. Jest ona generowana
przez każdego z promotorów po przypisaniu studentów do pracy. Karta jest jednym z dokumentów
wymaganych przez dziekanat, decydującym o dopuszczeniu studentów do egzaminu dyplomowego.
2.3. Scenariusze operacyjne
2.3
7
Scenariusze operacyjne
Scenariusz główny:
1. Administrator wprowadza do systemu dane niezbędne dla pozostałych użytkowników.
2. Kierownik wyznacza promotorów, którzy przygotowują propozycje tematów prac dyplomowych.
3. Kierownik akceptuje, odrzuca lub zleca modyfikacje tematu.
4. Prodziekan zatwierdza listę tematów zaakceptowanych prze kierowników.
5. Studenci łącza się w zespoły i zgłaszają się do tematów prac.
6. Promotor wybiera zespół i generuje kartę pracy.
2.3.1
Wprowadzenia niezbędnych danych do systemu
1. Administrator pobiera z dziekanatu listę studentów, którzy prawdopodobnie przystąpią do
wyboru tematu pracy dyplomowej oraz listę pracowników i wprowadza ich do systemu.
2. System zapisuje wprowadzone dane w bazie danych.
3. Administrator wprowadza do systemu dokładną strukturę wydziału czyli instytuty i zakłady (ewentualnie wprowadza tylko zmiany).
5. Administrator przypisuje kierowników do zakładów (jeśli nie ma ich w systemie).
7. Administrator wprowadza do systemu kierunki studiów (jeśli nie ma ich w systemie).
9. Administrator modyfikuje (w razie potrzeby) szablon karty tematu pracy.
2.3.2
Wyznaczenie promotorów i przygotowanie propozycji tematów
Warunek: Do systemu są wprowadzeni pracownicy (przynajmniej kierownicy zakładów/katedr).
1. Kierownik dodaje do systemu pracownika, którego chciałby wskazać jako promotora (w
przypadku jego braku w systemie).
2. Kierownik wskazuje osoby ze swojego zakładu/katedry, które widziałby w roli promotorów
prac (są to tzw. potencjalni promotorzy).
3. Kierownik dla każdej wskazanej osoby określa maksymalną liczbę propozycji tematów prac
jaką może zgłosić.
4. Kierownik dla każdej wskazanej osoby określa maksymalną liczbę faktycznych prac, jakie
może prowadzić.
5. System powiadamia potencjalnego promotora za pomocą poczty elektronicznej o propozycji
kierownika.
6. Potencjalny promotor przygotowuje propozycje tematów prac według obowiązującego
szablonu oraz wskazuje jakie informacje dodatkowe chciałby mieć o ewentualnych członkach
zespołu (na przykład ich średnią ocen).
2.3.3
Zatwierdzenie propozycji tematów
Warunek: Promotor przygotował propozycje tematu pracy dyplomowej.
1. Kierownik zatwierdza poszczególne propozycje, odrzuca je lub też zaleca modyfikacje.
2. Potencjalny promotor w modyfikuje w razie konieczności propozycje tematów prac.
8
3. System udostępnia zatwierdzone propozycje tematów, które zostały zgłoszone przez adiunktów, do wglądu prodziekanowi.
2.3.4
Prodziekan akceptuje listę tematów
Warunek: Kierownicy dokonali akceptacji wybranych tematów prac.
1. Prodziekan akceptuje całą listę tematów prac.
2. System udostępnia studentom listę prac.
2.3.5
Tworzenie zespołów i zgłaszanie ich do tematów
Warunek: Do systemu są wprowadzone dane studentów i mają oni założone konta.
1. Studenci łączą się w zespoły (tworzą własne zespoły lub zgłaszają się do już istniejących).
Każdy zespół ma tymczasowego lidera (założyciel grupy).
2. Lider zarządza składem zespołu (przyjmuje do zespołu osoby, które zgłosiły chęć przystąpienia do grupy; ewentualnie usuwa osoby z zespołu).
3. Lider zaznacza te tematy, którymi zespół jest zainteresowany. Jest możliwość zmiany zainteresowań.
4. System informuje odpowiedniego promotora o zainteresowaniu jego tematem pracy.
5. Lider umawia zespół na spotkanie z promotorem.
2.3.6
Wybranie zespołu
Warunek: Studenci zgłosili się do tematu.
1. Promotor biorąc pod uwagę terminy spotkań, które pasują zespołowi oraz inne informacje
(na przykład średnią ocen) zaprasza zespoły na spotkanie.
2. Promotor wybiera zespół.
3. System blokuje możliwość zgłaszania się pozostałych zespołów do danego tematu.
4. Promotor generuje kompletną kartę tematu pracy dyplomowej.
Rozdział 3
Wymagania funkcjonalne
W tym rozdziale opisano wymagania jakie powinien spełniać zbudowany system. Wymagania
dotyczą funkcjonowania systemu, możliwości jakie daje on użytkownikowi oraz sposobu interakcji
systemu z użytkownikiem. Opis wymagań zostanie przedstawiony w formie przypadków użycia.
3.1
Administrator
UC1: Wprowadzenie pracownika do systemu
Główny scenariusz:
1. Administrator wprowadza do formularza dane pracownika (imię, nazwisko, email, adres).
2. Administrator wybiera z listy (kontrolka checkbox) tytuł naukowy oraz stanowisko pracownika.
3. Administrator wybiera z list (kontrolka checkbox) wydział, do którego zamierza dodać pracownika.
4. System generuje listę instytutów jakie istnieją na wybranym wydziale.
5. Administrator wybiera z listy (kontrolka checkbox) instytut, do którego zamierza dodać
pracownika.
6. System generuje listę zakładów dostępnych w wybranym instytucie.
7. Administrator wybiera z listy (kontrolka checkbox) zakład, do którego zamierza dodać pracownika.
8. Administrator wysyła formularz z danymi naciskając przycisk Dodaj.
9. System sprawdza wprowadzone dane i zapisuje je w bazie danych.
Rozszerzenia:
9a. Nie wprowadzono wszystkich wymaganych danych
9a1. System wyświetla w formularzu, które dane nie zostały wprowadzone i prosi administratora o ich podanie
UC2: Wprowadzenie studentów do systemu
1. Administrator wybiera z listy (kontrolka checkbox) wydział, do którego zamierza dodać
studentów.
2. System generuje listę kierunków jakie istnieją na wybranym wydziale.
3. Administrator wybiera z listy (kontrolka checkbox) kierunek, do którego zamierza dodać
studentów.
9
10
4. Administrator podaje plik w formacie csv z listą studentów i wysyła wprowadzone dane.
5. System sprawdza format pliku i zapisuje studentów w bazie danych.
Rozszerzenia:
5a. Podano plik w złym formacie.
5a1. System wyświetla komunikat o błędnym formacie i prosi po podanie pliku we właściwym
formacie.
UC3: Wprowadzenie instytutu do systemu
instytut.
2. Administrator podaje nazwę wprowadzanego instytutu i wysyła wprowadzone dane.
Rozszerzenia:
3a1. System wyświetla, które dane nie zostały wprowadzone i prosi administratora o ich
podanie
UC4: Wprowadzenie zakładu do systemu
zakład.
2. System generuje listę instytutów, jakie istnieją na wybranym wydziale.
3. Administrator wybiera z listy (kontrolka checkbox) instytut, do którego zamierza dodać
zakład.
4. Administrator podaje nazwę wprowadzanego zakładu i wysyła wprowadzone dane.
Rozszerzenia:
podanie
UC5: Wprowadzenie wydziału do systemu
1. Administrator podaje nazwę wprowadzanego wydziału.
2. System sprawdza czy wprowadzono nazwę i zapisuje wydział w bazie danych.
Rozszerzenia:
2a. Nie wprowadzono nazwy wydziału
2a1. System prosi administratora o podanie nazwy wydziału.
UC6: Wprowadzenie kierunku do systemu
kierunek.
3.2. Kierownik zakładu / katedry
11
2. Administrator podaje nazwę wprowadzanego kierunku i wysyła wprowadzone dane.
Rozszerzenia:
podanie
UC7: Przypisanie kierownika do zakładu
1. Administrator wybiera zakład do którego chce przypisać kierownika.
2. System generuje listę pracowników w wybranym zakładzie.
3. Administrator wybiera z listy (kontrolka checkbox) pracownika, któremu chce przypisać role
kierownika zakładu.
4. System zapisuje zmiany w bazie danych.
UC8: Modyfikowanie szablonu karty tematu pracy
1. Administrator pobiera z systemu szablon karty tematu pracy.
2. Administrator modyfikuje szablon lokalnie na swoim komputerze.
3. Administrator wprowadza zmodyfikowany szablon do systemu (pliki spakowane w formacie
ZIP).
4. System sprawdza format wprowadzonych danych.
Rozszerzenia:
4a. Wprowadzono błędny format pliku
4a1. System wyświetla komunikat o błędnym formacie pliku.
3.2
Kierownik zakładu / katedry
UC1: Wprowadzenie pracownika do systemu
1. Kierownik wprowadza do formularza dane pracownika (imię, nazwisko, email, adres).
2. Kierownik wybiera z listy (kontrolka checkbox) tytuł naukowy oraz stanowisko pracownika.
3. Kierownik wysyła formularz z danymi naciskając przycisk „Dodaj”.
4. System sprawdza wprowadzone dane i zapisuje pracownika w bazie danych (w zakładzie
kierownika).
Rozszerzenia:
4a1. System wyświetla w formularzu, które dane nie zostały wprowadzone i prosi kierownika
o ich podanie.
UC2: Przypisanie pracownikowi roli promotora
1. Kierownik wybiera pracownika z lisy pracowników swojego zakładu (kontrolka checkbox).
12
2. Kierownik wprowadza maksymalną liczbę tematów, jakie promotor będzie mógł zaproponować oraz maksymalną liczbę prac, jakie promotor będzie mógł realizować.
3. Kierownik wysyła formularz z danymi naciskając przycisk „Dodaj”.
5. System powiadamia promotora pocztą elektroniczną
Rozszerzenia:
4a1. System wyświetla w formularzu, które dane nie zostały wprowadzone i prosi kierownika
o ich podanie.
4b. Maksymalna liczba proponowanych tematów jest mniejsza od maksymalnej liczby realizowanych prac.
4b1. System wyświetla w formularzu informacje o błędnych wartościach liczb.
UC3: Dodanie komentarza do propozycji tematu
1. Kierownik wybiera propozycje tematu pracy, do której chce dodać komentarz i naciska przycisk „Komentuj”.
2. System wyświetla formularz komentowania tematu.
3. Kierownik dodaje komentarze do wybranych cech tematu pracy.
4. System zapisuje w bazie komentarze i wyświetla je na liście tematów przy danej pracy.
UC4: Zaakceptowanie lub odrzucenie propozycji tematu
1. Kierownik wybiera propozycje tematu pracy którą chce zaakceptować bądź odrzucić i naciska
przycisk odpowiednio „Akceptuj” lub „Odrzuć”.
2. System wprowadza do bazy danych informację o zaakceptowaniu lub odrzuceniu propozycji
tematu.
3.3
Promotor
UC1: Dodanie propozycji tematu pracy
1. Promotor wypełnia formularz dodawania propozycji tematu pracy.
2. Promotor określa dla jakiego kierunku jest przeznaczony temat pracy.
3. System sprawdza czy promotor może dodać kolejny temat pracy (nie przekroczył maksymalnej liczby propozycji tematów).
4. System dodaje propozycje tematu pracy do bazy danych, która jest od razu widoczna na
liście tematów promotora jak również kierownika.
Rozszerzenia:
3a. Promotor wprowadził już dozwoloną maksymalną ilość propozycji tematów prac.
3a1. System wyświetla komunikat o przekroczeniu limitu propozycji tematów prac. Propozycja tematu nie zostaje dodana.
3.4. Prodziekan
13
UC2: Modyfikacja propozycji tematu pracy
1. Promotor wprowadza zmiany do propozycji tematu pracy w formularzu modyfikacji.
2. System zapisuje zmiany, które są od razu widoczne przy danej pracy.
UC3: Wybranie zespołu
1. Promotor wybiera zespół z listy zgłaszających się do danego tematu.
2. System przypisuje wybrany zespół do danego tematu pracy.
3. Promotor blokuje możliwość zmian w składzie zespołu.
4. System uniemożliwia studentom zmiany w składzie zespołu.
5. Promotor generuje za pomocą systemu kompletną kartę tematu pracy dyplomowej
Rozszerzenia:
1a. Promotor rezygnuje z wybranego już zespołu
1a1. System usuwa przypisanie zespołu do pracy i umożliwia promotorowi wybranie innego
zespołu.
3a. Promotor odblokowuje możliwość zmian w składzie zespołu.
3a1. System umożliwia studentom zmiany w składzie zespołu.
3.4
Prodziekan
UC1: Akceptacja listy tematów prac
1. Prodziekan weryfikuje listę tematów prac i akceptuje całą listę.
2. System udostępnia zaakceptowaną listę tematów prac studentom.
3.5
Student
UC1: Stworzenie i zarządzanie zespołem
1. Student wybiera w menu opcję „Stwórz własny zespół”.
2. System tworzy nowy zespół, którego liderem staje się jego twórca.
3. System udostępnia innym studentom możliwość zgłoszenia się do stworzonego zespołu.
4. Lider zaprasza do zespołu interesującą go osobę wpisując jej numer indeksu.
5. System wysyła zaproszenie do wskazanej osoby.
6. Lider wybiera z listy osób zgłaszających się do zespołu te, które chce przyjąć do zespołu.
7. System wpisuje wybrane osoby na listę członków zespołu.
Rozszerzenia:
1a. Lider zespołu usuwa założony przez siebie zespół.
1a1. System usuwa zespół z systemu.
6a. Lider zespołu usuwa osobę z zespołu.
6a1. System usuwa wybraną osobę z listy członków zespołu.
14
UC2: Zgłoszenie się do zespołu
1. Student wybiera z listy istniejących już zespołów ten, do którego chciałby się zapisać.
2. Student zgłasza się do wybranego zespołu.
3. System wysyła zgłoszenie do lidera zespołu.
UC3: Przyjęcie zaproszenia do zespołu
1. Student wybiera z listy zaproszeń do zespołów jedno, które go interesuje.
2. System zapisuje studenta na listę członków wybranego zespołu.
UC4: Zgłoszenie zespołu do tematu pracy
1. Student (lider zespołu) wybiera z listy dostępnych tematów prac, te które interesują zespół.
2. Student (lider zespołu) zgłasza zespół do wybranych tematów.
3. System wysyła zgłoszenia do odpowiednich promotorów.
Rozszerzenia:
2a. Zespół rezygnuje z tematu pracy.
2a1. System usuwa zespół z listy kandydujących do danego tematu.
Rozdział 4
Wymagania pozafunkcjonalne
4.1
Modyfikowalność
Ze względu na planowaną późniejszą rozbudowę systemu aplikacja powinna umożliwiać prostą
modyfikację:
• kodu źródłowego aplikacji
• bazy danych
Kod źródłowy aplikacji powinien zostać podzielony (jako struktura katalogów) na logiczne części.
Implementacja musi być przejrzysta aby wprowadzenie nowej funkcjonalności nie pociągało za sobą
refaktoryzacji całego kodu źródłowego. Przez modyfikowalność bazy danych autorzy rozumieją
łatwość zmiany typu bazy danych oraz umożliwienie przyszłej modyfikacji schematu bazy danych.
Administrator systemu powienien mieć również możliwość modyfikacji wzorca karty dyplomowej.
Modyfikowalność systemu jest najważniejszym wymaganiem pozafunkcjonalnym.
4.2
Użyteczność
Użyteczność systemu czyli łatwość jego obsługi znacząco wpływa na wrażenie, jakie system
wywiera na użytkowniku. Prosty w obsłudze system jest rozumiany jako intuicyjny w obsłudze
oraz szybki do przyswojenia.
4.3
Bezpieczeństwo
Aplikacja powinna chronić dane użytkowników – szczególnie dane osobowe oraz hasła. Ważne
jest aby użytkownik widział jedynie funkcje przeznaczone dla niego. System musi chronić dane
przed nieautoryzowanym dostępem.
4.4
Wydajność
Autorzy zakładają, że system będzie obsługiwał cały Wydział Informatyki i Zarządzania czyli
około 600 osób. Jeżeli w okresie wzmożonej aktywności 2% użytkowników będzie jednocześnie
żądało odpowiedzi aplikacji, oznacza to, że system będzie musiał w rozsądnym czasie (najwyżej
kilku sekund) odpowiadać na żądania dwunastu osób. System nie może zawiesić się w przypadku
większego obciążenia. Dane, które wymagają czasochłonnych obliczeń, powinny być przechowywane – o ile jest to możliwe – w wersji gotowej do pobrania. Należy mieć również na uwadze ilość
informacji gromadzoną przez system.
15
Rozdział 5
Architektura systemu
5.1
Fizyczne rozmieszczenie modułów
Rysunek 5.1 przedstawia fizyczne rozmieszczenie komponentów systemu. System DiploMan
zostanie wdrożony na serwerze, który poprzez sieć lokalną łączy się z serwerem bazy danych.
Użytkownicy – za pośrednictwem Internetu – posiadają dostęp do systemu poprzez przeglądarkę
WWW.
Rysunek 5.1: Fizyczne rozmieszczenie modułów
5.2
Wzorzec projektowy MVC
Głównym założeniem systemu jest zapewnienie odpowiedniego stopnia modyfikowalności. Taką
modyfikowalność, systematyzację i uporządkowanie kodu źródłowego wyznacza właśnie wzorzec
projektowy MVC (ang. Model View Controller ). Wydziela on trzy komponenty (warstwy): modelu, widoku oraz kontrolera. Ten pierwszy odpowiedzialny jest za przechowywanie danych biznesowych aplikacji. W przypadku tworzonego systemu są to wszelkie informacje o pracach dyplomowych, pracownikach zakładów, studentach, itd. Model nie wie nic o istnieniu kontrolera czy
widoku. Komponent widoku odpowiedzialny jest jedynie za prezentację przygotowanych danych.
Również nie wie nic o kontrolerze, czasami (w rzadkich przypadkach) może odwoływać się bezpośrednio do modelu (w tworzonym systemie taka sytuacja nie występuje). Kontroler przyjmuje
żądania od użytkownika, przetwarza dane i zwraca wyniki do warstwy widoku.
17
18
Wzorzec pozwala na dość znaczne zrównoleglenie pracy. Do wad opisywanego zastosowania
można zaliczyć dużą liczbę plików potrzebnych do realizacji zadania oraz większe trudności w samej
implementacji.
Rysunek 5.2: Schemat wzorca MVC
5.3
Opis wykorzystanych techonologii
Ogólną architekturę całego systemu przedstawia rysunek 5.3. Dokładniejsze omówienie każdego
komponentu znajduje się w dalszych podrozdziałach.
Rysunek 5.3: Ogólny schemat architektury systemu
5.3.1
Apache Tomcat
Apache Tomcat jest popularnym, darmowym kontenerem aplikacji webowych. Obsługuje serwlety Java (ang. Java Servlets) oraz strony JSP (ang. Java Server Pages). Aplikacja sprawdza się
w wielu zastosowaniach, włączając bardzo duże projekty. Tworzony system jest oparty o wersję
serwera 6.0.
5.3.2
Apache Struts 2
Struts 2 to framework przeznaczony do tworzenia rozbudowanych aplikacji internetowych Java.
Środowisko jest efektem połączenia sił wieloletniego projektu WebWork oraz Apache Struts. Technologia obsługuje żądania przeglądarki wysyłane przez użytkownika, przekierowując go do konkretnych akcji. Mapowanie akcji w Struts 2 na konkretne działanie (wywołanie funkcji Java) to bardzo
ważny etap. Framework pozwala przypisać do akcji – oprócz wymaganej nazwy – takie komponenty jak: zbiór interceptorów (patrz: rozdział poświęcony implementacji), zbiór typów wyniku
5.3. Opis wykorzystanych techonologii
19
działania akcji czy obsługę wyjątków. Same akcje mogą być grupowane w pakiety oraz przestrzenie nazw. Modularna budowa plików konfiguracyjnych umożliwia hierarchiczne tworzenie bardzo
rozbudowanych mapowań. Zastosowanie technologii pozwala na:
• automatyczną walidację danych wprowadzanych przez użytkownika i automatyczne wyświetlanie komunikatów o błędach
• tworzenie formularzy WWW o rozszerzonych możliwościach,
• automatyczną konwersję typów, która transparentnie mapuje zmienne HTTP na obiekty
Java,
• dostosowanie odpowiedzi aplikacji do każdej akcji,
• zwiększenie poziomu bezpieczeństwa dzięki zastosowaniu własnych interceptorów
Schemat przetwarzania akcji Struts 2 w tworzonym systemie wygląda następująco:
1. Użytkownik wysyła żądanie o zasób.
2. Aplikacja na podstawie wcześniej zdefiniowanego pliku konfiguracyjnego wybiera określoną
akcję.
3. Następuje wywołanie akcji – wygenerowanie danych wyjściowych.
4. Wynik jest przekazywany do Velocity w postaci specjalnych obiektów (w ogólności użycie
Velocity nie jest konieczne).
5. Velocity renderuje ostateczny wynik.
Rysunek 5.4: Uproszczony schemat działania środowiska Struts 2
5.3.3
Apache Velocity
Velocity jest prostym i jednocześnie bardzo efektywnym językiem znaczników. Umożliwia szybkie tworzenie dynamicznych stron dowolnego typu. Oprócz generowania wszystkich stron html,
opisywana technologia jest wykorzystywana również przy tworzeniu plików PDF (generując dynamicznie pliki źródłowe systemu LATEX). Velocity odpowiada warstwie widoku w tworzonym
projekcie.
5.3.4
Java Servlets
Serwlety Java to aplikacje Java, które w ogólności pozwalają na rozszerzenie możliwości serwera
WWW. Technologia pozwala programistom na dynamiczne tworzenie zawartości stron WWW
używając platfomy Java. Serwlety mogą utrzymywać stan aplikacji przez korzystanie na przykład
ze zmiennych sesyjnych czy ciasteczek (ang. cookies).
Serwlety są obiektami, które otrzymują żądanie i na jego podstawie generują odpowiedź. Mogą
korzystać z całego API Javy, o ile zostanie ono dostarczone.
20
5.3.5
Hibernate
Hibernate jest potężnym i bardzo wydajnym narzędziem służącym do mapowania relacyjnej
bazy danych na odpowiadający model obiektowy (i odwrotnie). Technologia umożliwia zarządzanie
bazą w bardzo prosty sposób. Narzędzie pozwala odseperować konkretną implementację bazy
danych od tworzonej aplikacji. Programista może posługiwać się językiem HQL (ang. Hibernate
Query Language), wzorowanym na SQL. Język pozwala na proste i eleganckie wydawanie nawet
skomplikowanych zapytań (składnią podobnych trochę do SQL). Jedną z zalet języka HQL jest
jego mobilność – zapytanie HQL tłumaczone jest na natywny dialekt języka SQL (zależny od
aktualnie używanej bazy danych). Dzięki zastosowaniu specjalnych annotacji w kodzie źródłowym
(technologia Hibernate Annotations) baza danych została automatycznie wygenerowana. System
DiploMan-1 – ze względu na wykorzystanie Hibernate Annotations – wymaga środowiska Java
w wersji minimum 1.5.
5.3.6
System składu tekstu LATEX
Aby system mógł genenerować pliki PDF, autorzy wykorzystali system składu tekstu LATEXw połączeniu z możliwościami Velocity. Administrator systemu dokonuje zmian w pliku .tex o ustalonej
nazwie, po czym wysyła przygotowane archiwum do serwera. System w momencie generowania
karty pracy zastępuje znaczniki Velocity z pliku .tex informacjami pobranymi z bazy danych. Po
przygotowaniu pliku .tex aplikacja uruchamia system LATEX w celu wygenerowania pliku PDF.
Stworzona karta pracy przechowywana jest na serwerze, aby przy kolejnym pobraniu pliku system
nie musiał dokonywać czasochłonnej kompilacji.
Autorzy zdecydowali się na zastosowanie systemu LATEX (a nie na przykład Jasper Reports) ze
względu na łatwość modyfikacji opisywanych szablonów.
Rozdział 6
Opis implementacji
Implementacja systemu Diploman wynika bezpośrednio z jego architektury, a więc wyboru
kolejno:
• frameworku Struts 2 opierającego się o koncepcję MVC,
• frameworku Hibernate realizującego warstwę dostępu do danych,
• procesora szablonów Apache Velocity realizującego warstwę widoku
Z tego też powodu opis implementacji można podzielić na podrozdziały odpowiadające poszczególnym warstwom aplikacji.
6.1
Model
Jak już wcześniej wspomniano, do realizacji warstwy dostępu do danych użyto open source’owego
projektu Hibernate. Jest to framework zapewniający mapowanie obiektów Java na tabele i krotki
relacyjnej bazy danych (ang. O/R mapping). Jego konfigurację zawiera plik hibernate.cfg.xml.
Wszystkie klasy odpowiedzialne za realizację warstwy modelu znajdują się w pakietach
diploman.database.*.
6.1.1
Schemat bazy danych
Odzwierciedleniu przedstawionego na rysunku 6.1 i 6.2 schematu relacyjnej bazy danych w świecie obiektowym służą klasy zawarte w pakiecie diploman.database.schema. Definiują one obiekty,
które system wykorzystuje przy dostępie do bazy danych zamiast wykonywania klasycznych zapytań SQL. I tak na przykład tabeli pracownicy odpowiadają obiekty klasy Pracownik, tabeli
prace obiekty klasy Praca, a tabeli wydzialy, obiekty klasy Wydzial. Ułatwia to znacząco dostęp
do bazy danych i wykonywanie w niej wszelkich zmian. Nie zaimplementowano klas tabel połączeniowych, gdyż realizacją związków między encjami zajmuje się Hibernate. Dostęp do danych
pozyskiwanych przez połączenie tabel realizuje się poprzez listy (zbiory) obiektów, na przykład
obiekt klasy Wydzial posiada listę (zbiór) obiektów klasy Kierunek. Można dzięki temu odwoływać się do nich w bardzo prosty sposób, na przykład
kierunki_na_wydziale = wydzial.getKierunki();
6.1.2
Klasy wykorzystywane do dodawania, pozyskiwania, modyfikacji
i usuwania danych z bazy
Wszystkie klasy wykorzystywane przy dostępie do bazy danych do pozyskiwania, modyfikacji
i usuwania danych znajdują się w pakiecie diploman.database. Grupują one metody według
21
22
Opis implementacji
Rysunek 6.1: Schemat bazy danych – część 1
23
6.1. Model
Rysunek 6.2: Schemat bazy danych – część 2
24
Opis implementacji
obiektów, na których działają:
• klasa Workers – metody służące dodawaniu, pobieraniu, modyfikacji i usuwaniu pracowników
z bazy danych
• klasa Students – dodawanie, pobieranie, modyfikacja i usuwanie studentów. Znajdują się tu
metody pozyskujące wszelkie potrzebne informacje o studentach, na przykład interesujące ich
zespoły, w ramach których chcieliby realizować pracę dyplomową. Klasa umożliwia również
wyszukiwanie studentów według różnych kryteriów, na przykład wydziału, kierunku na jakim
studiują oraz promotora, u którego realizują swoją pracę (metoda searchStudents()).
• klasa Directors – metody służące pobieraniu oraz usuwaniu z bazy danych kierowników
zakładów. Również tutaj możliwe jest wyszukiwanie kierowników według różnych kryteriów, na przykład metoda viewDirectors() – pobiera wszystkich kierowników, metoda
viewDirectorsInInstitute() – pobiera kierowników z danego instytutu etc.
• klasa Promoters – metody służące dodawaniu, pobieraniu, modyfikacji i usuwaniu promotorów z bazy danych
• klasa Thesises – metody służące dodawaniu propozycji tematów prac dyplomowych, ich
usuwaniu i modyfikacji, a także pobieraniu z bazy danych. Znajdują się tutaj wszelkie
metody realizujące operacje wykonywane na pracy dyplomowej, takie jak dodawanie zespołów
kandydujących do pisania danej pracy, akceptowanie zespołu, czy też jego odrzucanie, a także
komentowanie propozycji pracy dyplomowej przez kierownika zakładu.
• klasa Faculties – dodawanie, pobieranie, modyfikacja, usuwanie wydziałów
• klasa Subjects – dodawanie, pobieranie, modyfikacja, usuwanie kierunków studiów
• klasa Institutes – dodawanie, pobieranie, modyfikacja, usuwanie instytutów
• klasa Laboratories – dodawanie, pobieranie, modyfikacja, usuwanie zakładów
• klasa Groups – dodawanie, pobieranie, modyfikacja, usuwanie oraz wszelkie metody służące
operacjom na zespołach realizujących prace dyplomowe. Znajdują się tu między innymi
metody umożliwiające wysłanie przez zespół zaproszenia do innego studenta, przeglądanie
wysłanych zaproszeń, przeglądanie kandydujących do zespołu studentów, ich akceptację,
opuszczenie zespołu przez studenta etc.
• klasa Passwords – wykorzystywana do logowania i zmiany hasła użytkownika
Wszelkie operacje zmieniające obiekty bazy danych wykonywane są w tranzakcjach umożliwiających w razie niepowodzenia odtworzenie jej spójnego stanu.
6.1.3
Klasy wyjątków
W przypadku niepowodzenia przy wprowadzaniu zmiany w bazie danych, bądś też pobieraniu
z niej informacji zwracane są odpowiednie wyjątki. Głównym wyjątkiem jest DatabaseException
– wszystkie inne użyte wyjątki dziedziczą po tej klasie:
• NoSuchUserException – zwracany, gdy podany przy logowaniu użytkownik nie istnieje
• InvalidPasswordException – zwracany, gdy podane przy logowaniu hasło jest błędne
• PasswordException – zwracany, gdy nie uda się ustawić nowego hasła
• NoSuchFacultyException – zwracany, gdy nie znaleziono danego wydziału
• NoSuchSubjectException – zwracany, gdy nie znaleziono danego kierunku studiów
• NoSuchInstituteException – zwracany, gdy nie znaleziono danego instytutu
• NoSuchLaboratoryException – zwracany, gdy nie znaleziono danego zakładu
• NoSuchWorkerException – zwracany, gdy nie znaleziono danego pracownika
• NoSuchStudentException – zwracany, gdy nie znaleziono danego studenta
6.2. Kontroler
25
• NoSuchGroupException – zwracany, gdy nie znaleziono danego zespołu studentów
• NoSuchThesisException – zwracany, gdy nie znaleziono danej pracy
• StudentAlreadyHasGroupException – zwracany, gdy student próbuje przyłączyć się do zespołu, podczas gdy ma już przypisany inny
• StudentAlreadyHasThesisException – zwracany, gdy zespołowi (studentowi) próbuje się
przypisać pracę, podczas gdy ma on już przypisaną inną
• ThesisIsLockedException – zwracany, gdy praca zespołu jest zablokowana, a ktoś próbuje
wprowadzić do niego zmiany
• ThesisLimitException – zwracany, gdy promotor próbuje zaproponować więcej tematów
prac, niż mu przydzielono
6.1.4
Klasy pomocnicze
Klasy używane jako pomocnicze dla innych, realizujących dostęp do bazy danych, umieszczono
w pakiecie diploman.database.utils. Znajduje się tam klasa HibernateUtil, w której znajdują
się metody odpowiedzialne za:
• dostarczenie sesji Hibernate innym metodom,
• dodawanie kont użytkowników,
• generowanie przykładowych danych na użytek testów
6.2
Kontroler
Rolę kontrolera pełni open source’owy framework Struts 2. Najważniejszym jego elementem
jest plik struts.xml, w którym to przechowywana jest konfiguracja kontrolera, w ramach której
opisane są możliwe do wykonania przez użytkownika akcje. Akcje pogrupowane są w pakiety
(ang. package). Każdy pakiet odpowiada roli, jaką użytkownik może pełnić – podział taki ułatwia
zabezpieczenie przed nieautoryzowanym dostępem do funkcji systemu.
6.2.1
Interceptory
Zabezpieczenie przed niauprawnionym wykonaniem akcji wiąże się ze specjalnymi obiektami
pośredniczącymi – interceptorami. Są to obiekty wywoływane jeden za drugim w ustalonej kolejności za każdym razem, gdy wykonywana jest dana akcja. Interceptory pozwalają na przykład
sprawdzić, czy dane dostarczane do akcji są poprawne i w przypadku stwierdzenia błędów przerwać jej wykonywanie. Interceptory mogą być wywoływane zarówno przed, jak i po wykonaniu
danej akcji. W systemie Diploman użyto tego mechanizmu w celu ochrony przed nieuprawnionym dostępem. Informacje o użytych interceptorach i ich konfiguracje przechowywane są w pliku
struts.xml, natomiast odpowiednie klasy definiujące działanie samych interceptorów umieszczone
są w pakiecie diploman.interceptors. Interceptor SecureInterceptor sprawdza, czy użytkownik wykonujący daną akcję jest zalogowany i czy ma on przypisaną rolę uprawniającą go do jej
wykonania. I tak na przykład użytkownik niezalogowany (pakiet public) może jedynie zalogować
się do systemu. W przypadku próby wykonania jakiejkolwiek innej akcji, zostanie on przekierowany
do strony logowania.
Role, jakie użytkownik może pełnić w systemie to: administrator, prodziekan, kierownik zakładu, promotor oraz student, przy czym użytkownik nie będący studentem lub administratorem
może posiadać więcej niż jedną rolę (to znaczy prodziekan może być jednocześnie na przykład
promotorem i kierownikiem zakładu).
26
Opis implementacji
6.2.2
Filtry
Kwestią mniej ważną, ale również istotną jest zabezpieczenie systemu przed możliwością bezpośredniego podglądu zawartości plików *.vm poprzez wpisanie w przeglądarce odpowiednio spreparowanego URLa (ang. Uniform Resource Locator ). Nie stanowiłoby to bezpośredniego zagrożenia
dla systemu, jednak umożliwiłoby zdobycie potencjalnie niebezpiecznej wiedzy o sposobie pobierania danych przez warstwę widoku.
Zabezpieczeniem przed tym procederem może być odpowiednie użycie filtrów. Filtr to obiekt
tworzony w odpowiedzi na żądanie zasobu w aplikacji webowej. Zasób może być dynamiczny, na
przykład serwlet Java lub strony JSP (ang. JavaServer Pages), bądź też statyczny, jak na przykład
strona HTML lub obrazek. Filtr przechwytuje żądanie, dzięki czemu może je sprawdzić i w razie
potrzeby zmodyfikować odpowiedź serwera. Używane w systemie filtry zdefiniowane są w pliku
web.xml. Klasy filtrów przechowywane są w pakiecie diploman.filters. Znajduje się tam klasa
VelocityFilter odpowiedzialna za przekierowanie użytkownika do strony błędu w przypadku
próby odczytania pliku *.vm.
6.2.3
Akcje
Każdej akcji, jaką może wykonać użytkownik przypisana jest klasa ją obsługująca. Klasa
taka dostarcza do widoku wszelkie dane pobrane z bazy przez warstwę modelu, a także, w przypadku gdy klasa ta obsługuje formularz, odpowiada za walidację wprowadzanych przez użytkownika danych oraz wywołanie odpowiednich metod modyfikujących bazę danych. Klasy obsługujące akcje pogrupowane są w analogiczny sposób, w jaki pogrupowane są akcje w pliku
struts.xml. Umieszczone są one w pakiecie diploman.actions, a w poszczególnych pakietach:
diploman.actions.administrator, diploman.actions.kierownik,
diploman.actions.prodziekan, diploman.actions.promotor, diploman.actions.student
przechowywane są klasy obsługujące akcje przypisane konkretnym rolom. Każda taka klasa dziedziczy po klasie ActionSupport, choć nie jest to obowiązkowe. Daje to jednak możliwość nie
tylko dostarczenia warstwie widoku danych do wyświetlenia, ale również, poprzez przedefiniowywanie funkcji execute() oraz validate() wykonywanie dowolnych innych metod, na przykład
modyfikujących bazę danych, oraz sprawdzanie poprawności wprowadzonych przez użytkownika
danych.
Klasy obsługujące akcje korzystają z kilku klas znajdujących się w pakiecie diploman.utils.
Znajdują się tam klasy pomocnicze, grupujące metody służące na przykład do operacji na plikach,
czy też wysyłające e-maile do użytkowników. W klasie DiplomanConstants zdefiniowane są stałe
ILLEGAL INT oraz EMPTY STRING używane w całym projekcie do obsługi formularzy.
6.3
Widok
Warstwa widoku realizowana jest przy pomocy open source’owego procesora szablonów Velocity
rozwijanego pod patronatem fundacji Apache. Umożliwia on budowanie szablonów stron, które
uzupełnia się treścią na podstawie danych dostarczanych przez inne warstwy. Pomocne okazały się
również oferowane przez Struts 2 w ramach szablonów Velocity tagi upraszczające m.in. budowanie
formularzy. Przykładem takiego szablonu jest plik login.vm zawierający formularz służący do
logowania się do systemu:
#parse("/diploman/common/headers/header.vm")
6.3. Widok
27
#sactionerror()
#sform ()
#stextfield ("label=Login" "name=login" "maxlength=100")
#spassword ("label=Hasło" "name=password" "maxlength=100")
#ssubmit ("name=submit" "value=Zaloguj")
#end
#include("/diploman/common/footers/footer.vm")
Znak specjalny „#” oznacza początek dyrektywy Velocity. Dyrektywy zaczynające się od „#s”
oznaczają dyrektywy Struts 2.
Po przetworzeniu takiego szablonu wygenerowany zostaje plik zawierający klasyczne tagi html,
takie jak <form></form>, <input ...> </input> itd. Automatycznie zostaną także wyświetlone
błędy walidacji przy odpowiednich polach formularza oraz błędy akcji, na przykład w przypadku
niepowodzenia jej wykonania.
Poszczególne pliki z szablonami znajdują się w katalogu WebContent/diploman pogrupowane
według ról użytkowników, dla jakich są przygotowane, na przykład
WebContent/diploman/administrator zawiera szablony używane do wyświetlania stron przeznaczonych dla administratora systemu.
Rozdział 7
Zapewnianie jakości
Jakość tworzonego systemu musi być stale pod kontrolą. Nie można zakładać, że tworzone
oprogramowanie jest wolne od błędów. Autorzy przeprowadzali systematycznie przeglądy kodu
źródłowego oraz wykonali szereg testów. Metody te pozwoliły skutecznie zmniejszyć liczbę błędów.
7.1
Przeglądy kodu
Przegląd kodu jest metodą systematycznego analizowania kodu źródłowego (pojedynczych
funkcji programu) w celu znalezienia błędów. Przegląd musi być dokonywany przez osobę trzecią,
która nie implementowała danej części systemu. Zmiana osób jest istotna ponieważ często osoba
implementująca jakąś funkcję sama nie widzi swoich błędów – jej myślenie jest już „ukierunkowane”
na wybrany przez siebie sposób realizacji danej funkcjonalności.
Autorzy wzajemnie sprawdzali i analizowali kod źródłowy. Najczęstszą praktyką było przejrzenie kodu źródłowego przez dwóch programistów na prośbę trzeciej osoby. Inspekcje kodu źródłowego były dokonywane również przez jedną osobę podczas zapoznawania się z zaimplementowaną
funkcją przed jej pierwszym użyciem. Przy znalezieniu wątpliwego miejsca w kodzie źródłowym
(czy też niezrozumiałej logiki działania programu) wszyscy programiści analizowali potencjalny
błąd. Przeglądy kodu okazały się bardzo owocną metodą wyszkiwania usterek.
7.2
Testy jednostkowe
Testy jednostkowe to walidacja poprawności działania pojedynczych funkcji. Testowanie musi
odbywać się równolegle z implementacją systemu. Szybciej znaleziony błąd jest prostszy (mniej
czasochłonny) do wyeliminowania. Autorzy dokonywali testów metodą „białej skrzynki“. Oznacza
to, że testując daną funkcję mieli dostęp do jej implementacji. Podczas testowania przydatnym
narzędziem okazał się framework JUnit, pozwalający na profesjonalne przygotowanie testów.
7.3
Testy systemowe
Testy miały na celu porównanie rzeczywistej funkcjonalności systemu z zadanymi wymaganiami. Autorzy testowali całe moduły pod kątem funkcjonalności, odpowiedniego przechwytywania
błędów przez aplikację. Jako przykład poniżej został pokazany przykładowy scenariusz testowania
funkcji zmiany hasła.
1. Zaloguj się do systemu, na przykład na konto administratora.
2. Nie uzupełnij wszystkich pól (lub zostaw wszystkie pola puste) i naciśnij przycisk Zmień
hasło. Czy aplikacja pokazała informację o wymaganych polach?
29
30
Zapewnianie jakości
3. Wpisz stare hasło i nowe hasło (w polach Nowe hasło oraz Powtórz nowe hasło wpisz różne
hasła). Czy po zatwierdzeniu system wyświetlił komunikat o niezgodnych hasłach?
4. Podaj nieprawidłowe stare hasło oraz wpisz dwukrotnie nowe hasło. Kliknij przycisk Zmień
hasło. Czy aplikacja pokazała informację o nieprawidłowym starym haśle?
5. Wpisz poprawnie nowe oraz stare hasło. Czy system wyświetlił komunikat o pomyślnej
zmianie hasła?
6. Wyloguj się z systemu.
7. Spróbuj zalogować się używając starego hasła. Czy udało się zalogować?
8. Zaloguj się używając nowego hasła. Czy udało się zalogować?
7.4
Testy akceptacyjne
Testy akceptacyjne zostały przeprowadzone w obecności promotora. Miały na celu ukazanie
i zaakceptowanie danej funkcjonalności.
Rozdział 8
Zarządzanie wersjami
Podczas prac implementacyjnych do zarządzania kolejnymi wersjami systemu wykorzystano
system kontroli wersji Subversion, znany również jako SVN. System kontroli wersji służy do śledzenia zmian w kodzie źródłowym i pomocy przy łączeniu oraz wprowadzaniu zmian, dokonywanych
przez wiele osób w różnych momentach. Można wyróżnić systemy kontroli wersji scentralizowane, oparte o architekturę klient-serwer oraz rozproszone, oparte o architekturę P2P. Podczas
implementacji wykorzystano pierwszy z wymienionych rodzajów systemu, w którym istnieje jedno
centralne repozytorium, z którym użytkownicy synchronizują swoje zmiany. Z różnych narzędzi
do zarządzania wersjami można wymienić RCS, CVS oraz SVN, który jest najbardziej rozbudowany ze wszystkich wymienionych. Subversion oferuje szereg udogodnień, takich jak atomowe
transakcje, wersjonowanie zmian nazwy pliku, położenia w katalogach oraz jego kopii. Bardzo
przydatną funkcją jest możliwość przesyłania różnic w plikach od klienta do serwera i odwrotnie.
SVN rozprowadzany jest na zasadzie open source.
Do łatwego korzystania z SVN wykorzystano okienkowego klienta TortoiseSVN w wersji 1.4.3,
pobranego ze strony http://tortoisesvn.tigris.org/. Jest on rozprowadzany na licencji GNU
i przeznaczony dla systemu operacyjnego Windows. Z jego zalet należy wymienić natychmiastowe
informowanie użytkownika, które pliki lub foldery zostały zmienione i w związku z tym należy je
wysłać do repozytorium w celu aktualizacji wersji. Ponadto TortoiseSVN wspiera znajdowanie
różnic w plikach i ich łączenie.
Projekt umieszczono w repozytorium na serwerze https://opensvn.csie.org/. Dla każdego
programisty zostało stworzone osobne konto. Dostęp do projektu był chroniony hasłem.
31
Rozdział 9
Weryfikacja osiągnięcia
celów biznesowych
Przyczyną decyzji o budowie systemu były trudności, jakie towarzyszyły każdego roku podczas
wydawania i przydzielania tematów prac dyplomowych. Za główny cel postawiono zbudowanie
systemu, który ułatwiłby pracownikom wybór promotorów, zbieranie propozycji tematów prac
i ich wydawanie studentom oraz komunikacje pomiędzy osobami uczestniczącymi w tym procesie.
Studenci mieliby łatwiejszy dostęp do listy tematów, informacji o zakresie prac oraz aktualnych
informacji o dostępności poszczególnych tematów.
O sukcesie przedsięwzięcia zdecyduje fakt, czy zbudowany system rozwiąże problemy, które dotychczas napotykano. Głównym wyznacznikiem osiągnięcia wytyczonych celów będzie powszechne
używanie systemu przez pracowników i studentów, o czym zadecyduje jego rzeczywista użyteczność,
na którą składają się zarówno jego możliwości jak również przyjazny interfejs dla użytkownika.
Weryfikacja osiągnięcia celów zostanie dokonana za pomocą anonimowych ankiet. Badanie to
zostanie przeprowadzone zarówno wśród pracowników, jak również studentów studiów II stopnia,
którzy korzystali z systemu podczas wyboru prac inżynierskich oraz magisterskich. Wszystkie
osoby zostaną zapytane o wygodę korzystania z systemu – czy interfejs jest przejrzysty, czy łatwo
można odnaleźć interesujące nas dane, czy są one czytelne i zrozumiałe, czy szybkość działania
systemu jest wystarczająca oraz czy funkcje systemu spełniają swoją rolę (jeśli nie to które funkcje
i dlaczego). Zostanie również zadane pytanie o ogólne wrażenie o systemie oraz czy spełnił on
oczekiwania użytkowników. Odpowiedzi na postawione pytania będą miały formę zamkniętą (odpowiedzi będą typu „Tak, bardzo”, „Tak, wystarczająco”, „Nie, niewystarczająco”, „Nie, zupełnie
nie spełnia swoich funkcji”).
33
Rozdział 10
Zebrane doświadczenia
Realizacja projektu DiploMan-1 wymagała od ich twórców dobrego zaznajomienia się z procesami biznesowymi zachodzącymi w świecie rzeczywistym na uczelni. Wymagało to między innymi przeanalizowania regulaminu studiów pod kątem interesujących procedur i wyekstraktowania
z niego najważniejszych dla systemu informacji.
Po zapoznaniu się z naturą problemu bardzo ważną decyzją jaką należało podjąć był wybór
architektury systemu. Zorganizowano w tym celu spotkanie z grupą ekspertów doświadczonych
w projektowaniu, implementowaniu i wdrażaniu podobnych systemów, podczas którego podjęto
decyzję co do architektury. Rozwiązania dobrane zostały tak, by spełnić wymagania funkcjonalne
oraz pozafunkcjonalne. Należy tutaj zauważyć, iż autorzy pracy nie mieli wcześniej dużego doświadczenia w budowaniu aplikacji internetowych wykorzystujących koncepcję MVC. W związku
z tym ważnym kryterium była szacowana pracochłonność poznania nowych technologii. Mimo
uwzględnienia tego faktu czas poświęcony na nauczenie się wykorzystywanych narzędzi w stopniu
pozwalającym na rozpoczęcie prac nad system przekroczył przewidywaną długość i wyniósł około
15% całego czasu poświęconego projektowi. Pokazało to, jak ważny i często niedoszacowany bywa
początkowy wkład pracy.
Szczegółowe dane na temat pracochłonności przedstawia tabela 10.1.
programowanie warstwy modelu
programowanie warstwy kontrolera
programowanie warstwy widoku
projektowanie systemu
nauka technologii
30%
20%
18%
17%
15%
Tablica 10.1: Pracochłonność poszczególnych etapów tworzenia systemu
Jak widać najbardziej pracochłonne okazało się zaimplementowanie warstwy modelu i to pomimo ułatwienia jakim było użycie frameworku Hibernate.
Napisano 12480 linii kodu zawartych w 160 plikach. Są to, jak na skalę projektu, liczby dość
duże. Przyjęta organizacja plików źródłowych i konfiguracyjnych pozwoliła jednak na zachowanie
porządku, umożliwiając łatwą orientację w kodzie i zapewniając lepszą modyfikowalność.
Bardzo dobrym rozwiązaniem był wybór MVC jako wzorca projektowego. Umożliwiło to
w miarę sprawną równoległą pracę trzem programistom, gdzie zmiany wprowadzane przez jedną
osobę, pracującą nad konkretną warstwą aplikacji wpływały minimalnie na pracę pozostałych.
Pomimo swoich zalet połączenie Struts 2 z Velocity nie okazało się szczególnie popularnym
rozwiązaniem w Internecie, co wiązało się z pewnymi problemami ze znalezieniem odpowiednich
35
36
Zebrane doświadczenia
tutoriali i przykładów. Na szczęście dokumentacja tych projektów jest na tyle dobra, że pozwala
na rozwiązanie większości pojawiających się problemów bez dodatkowej pomocy.
Choć poznanie nowych technologii zajęło stosunkowo dużo czasu, ich wybór okazał się bardzo
trafiony. Hibernate, dzięki obiektowości jaką zapewnił w warstwie modelu, znacząco przyśpieszył
i ułatwił prace nad projektem. Struts 2 ponad standardowe akcje zaoferował prosty, ale nader
funkcjonalny mechanizm interceptorów. Natomiast procesor szablonów Velocity sprawia wrażenie
o wiele bardziej przejrzystego i szybszego w użyciu niż konkurencyjne JSP.
Praca w zespole wymagała przygotowania nie tylko z dziedziny zarządzania projektem informatycznym, ale także komunikacji interpersonalnej i zarządzania jako takiego. Projekt DiploMan-1
wzbogacił autorów w wiedzę i doświadczenie potrzebne przy projektowaniu, implementowaniu
i wdrażaniu systemów informatycznych.
Dodatek A
Wkład poszczególnych osób
do przedsięwzięcia
Robert Przybylski zajmował się przede wszystkim projektowaniem warstwy widoku i implementowaniem metod pobierających potrzebne informacje z bazy danych, a także planowaniem
akcji użytkownika, zabezpieczeniem systemu oraz przekrojową kontrolą spójności systemu.
Paweł Walczuk w ramach prac zajmował się głównie warstwą modelu i kontrolera, a także
w niektórych przypadkach warstwą widoku. Zajmował się funkcjami dla administratora systemu,
prodziekana, jak również dla kierowników zakładów i promotorów.
Krzysztof Kaszkowiak zajął się głównie implementacją dostępu do bazy danych i funkcjami operującymi na niej. Zrealizował również logowanie użytkowników oraz generowanie i przechowywanie
plików PDF.
Bardziej szczegółowe informacje na temat zakresu realizowanych prac zostały przedstawione
w tabeli A.1.
37
38
Wkład poszczególnych osób do przedsięwzięcia
Czynność
K. Kaszkowiak R. Przybylski
Analiza wymagań
X
X
Stworzenie przypadków użycia
X
Projekt schematu bazy danych
X
X
Stworzenie schematu strony
Przeniesienie bazy danych
X
(Hibernate Annotations)
Konfiguracja Hibernate
X
Skład pracy dyplomowej– LATEX
X
Zaplanowanie podziału akcji
X
na pakiety w pliku struts.xml
X
Użycie interceptorów
Generowanie przykładowych
X
danych
Użycie filtra dla zwiększenia
X
bezpieczeństwa aplikacji
Implementacja poszczególnych funkcjonalności
Logowanie się użytkowników
MK
WK
do systemu
Modyfikacja szablonu pracy
MWK
przez administratora
Generowanie plików PDF
MWK
Wydziały i kierunki
MWK
Jednostki i kierownicy
MWK
Zestawienie pracowników
MWK
administratora
Dodawanie studentów
MWK
z pliku .csv
Zestawienie studentów
MWK
administratora
Zestawienie pracowników
M
kierownika
Dodawanie i usuwanie
W
promotorów przez kierownika
Modyfikowanie danych
promotora przez kierownika
Zestawienie promotorów
MWK
kierownika
Akceptowanie i odrzucanie
propozycji tematów
W
przez kierownika
Komentowanie propozycji
W
tematów przez kierownika
Zestawienie propozycji
MWK
tematów prac kierownika
Zestawienie prac prodziekana
Zestawienie studentów
MWK
prodziekana
Dodawanie propozycji
MWK
tematu pracy promotora
Modyfikowanie propozycji
tematu pracy promotora
Zestawienie propozycji
MWK
tematów prac promotora
Zestawienie prac promotora
MWK
Zmiana hasła
MK
WK
P. Walczuk
X
X
X
X
MWK
MWK
WK
MK
MWK
MWK
MK
MK
MK
MWK
MWK
MWK
MK
Tablica A.1: Wkład poszczególnych osób do przedsięwzięcia. Legenda: M – model,
W – widok, K – kontroler
Dodatek B
Opinia klienta
dr hab. inż. Jerzy Nawrocki, prof. nadzw.
Poznań, 2. lutego 2008 r.
Prodziekan ds. kształcenia
Wydział Informatyki i Zarządzania
Opinia klienta
o systemie DiploMan-1
System DiploMan-1 w obecnej wersji oferuje funkcjonalność wystarczającą do osiągnięcia
podstawowego celu, jakim było uporządkowanie procesu zbierania ofert tematów prac
dyplomowych od pracowników naukowo-dydaktycznych i wspomaganie „zapisywania” się
studentów na poszczególne prace. System umożliwia autoryzowaną współpracę reprezentantów
dziekanatu, kierowników katedr/zakładów, potencjalnych promotorów prac oraz studentów.
W wyniku działania zaprezentowanej w pracy wersji systemu DiploMan powstaje strona
internetowa zawierająca dla danego kierunku studiów wykaz wszystkich tematów prac
dyplomowych na dany rok wraz z podpiętymi pod te tematy kartami prac. Jest to – z punktu
widzenia dziekanatu – ogromne usprawnienie.
Niestety, system DiploMan-1 nie został jeszcze wdrożony więc trudno jest go ostatecznie
ocenić. Jego wdrożenie (czyli pierwsze praktyczne wykorzystanie) jest przewidziane na semestr
letni 2007/08, kiedy to uruchomiony zostanie proces zbierania tematów prac inżynierskich na rok
2008/09. Autorzy systemu DiloMan zadeklarowali już swój udział we wdrożeniu. Zrealizowana
funkcjonalność, którą miałem okazję obejrzeć w działaniu, oraz złożona deklaracja współpracy
przy wdrożeniu stanowią dla mnie wystarczającą gwarancję osiągnięcia zamierzonego celu
biznesowego, o którym wspomniałem na początku.
Z dotychczasowej współpracy ze studentami jestem bardzo zadowolony.
39
Dodatek C
Słownik pojęć i skrótów
AiZ – makrokierunek „Automatyka i zarządzanie” na Politechnice Poznańskiej
Aktor – użytkownik systemu, który odpowiada rzeczywistej osobie w realnym świecie
Architektura Klient/serwer – asymetryczna architektura oprogramowania umożliwiająca rozdzielenie funkcjonalności pomiędzy stronę klienta i serwera
CVS (ang. Concurrent Versions System) – popularny system kontroli wersji
Framework – zbiór narzędzi, programów i bibliotek kodu źródłowego wspomagających tworzenie,
rozwój i testowanie aplikacji
GNU – licencja wolnego oprogramowania
Implementacja – przekształcenie abstrakcyjnego opisu systemu informatycznego w konkretny,
działający program komputerowy
INF – kierunek „Informatyka” na Politechnice Poznańskiej
Interfejs – oprogramowanie pozwalające na interakcję między aplikacją i użytkownikiem
Obiekt biznesowy – odpowiednik tradycyjnego dokumentu
Open Source – otwarte oprogramowanie
Proces biznesowy – powiązane ze sobą czynności , które wykonywane są przez określone osoby
Przypadek użycia – sposób funkcjonowania systemu; wydzielona spośród innych funkcja, dostępna dla użytkownika, pozwalająca osiągnąć jakiś ważny z jego punktu widzenia cel
P2P (ang. peer-to-peer ) – model komunikacji w sieci komputerowej, który gwarantuje obydwu
stronom równorzędne prawa (w przeciwieństwie do modelu klient-serwer)
RCS (ang. Revision Control System) – system kontroli wersji plików tekstowych
Repozytorium – miejsce uporządkowanego przechowywania dokumentów
Scenariusz operacyjny – opis sposobu przepływu informacji pomiędzy aktorami
SVN (Subversion) – popularny system kontroli wersji
System kontroli wersji – system służący do śledzenia zmian głównie w kodzie źródłowym oraz
pomocy programistom w łączeniu i modyfikacji zmian dokonanych przez wiele osób w różnych
momentach
Warstwa aplikacji – wydzielona część kodu programu odpowiedzialna za realizację zadań określonego typu
Wymagania funkcjonalne – usługi jakie ma oferować system, jak ma reagować na określone
dane wejściowe oraz jak ma się zachowywać w określonych sytuacjach
Wymagania pozafunkcjonalne – kryteria jakości systemu
41
Dodatek D
Kod źródłowy systemu (CD)
Na dołączonej płycie CD znajduje się kompletny kod źródłowy systemu.
43
Literatura
[1]
Wikipedia. [on-line] http://en.wikipedia.org.
[2]
Apache Software Foundation. Apache Struts 2 Documentation. [on-line]
http://struts.apache.org/2.x/docs/home.html.
[3]
Apache Software Foundation. Strona projektu Velocity. [on-line] http://velocity.apache.org/.
[4]
Apache Software Foundation. Struts 2 Core 2.0.11 API. [on-line]
http://struts.apache.org/2.x/struts2-core/apidocs/index.html.
[5]
Apache Software Foundation. The Velocity User Guide. [on-line]
http://velocity.apache.org/engine/releases/velocity-1.5/user-guide.html.
[6]
Apache Software Foundation. Introduction to Velocity. [on-line]
http://portals.apache.org/jetspeed-1/tutorial/7/velocity.html, 2005.
[7]
JavaWorld.com Geir Magnusson Jr. Start up the Velocity Template Engine. [on-line]
http://www.javaworld.com/javaworld/jw-12-2001/jw-1228-velocity.html, 2001.
[8]
Red Hat Middleware. Introduction to Hibernate. [on-line]
http://www.hibernate.org/hib_docs/v3/reference/en/html/tutorial.html.
[9]
RoseIndia. Struts 2 Tutorial. [on-line] http://www.roseindia.net/struts/struts2/.
[10] Marcin Staniszczak. Struts – aplikacje internetowe w Javie. [on-line] http://serwis.
magazynyinternetowe.pl/artykul/679,1,580,struts_-_aplikacje_internetowe_w_javie.html,
2007.
45
c 2008 Krzysztof Kaszkowiak, Robert Przybylski, Paweł Walczuk
Instytut Informatyki, Wydział Informatyki i Zarządzania
Skład przy użyciu systemu LATEX.
BibTEX:
@mastersthesis{ key,
author = "Krzysztof Kaszkowiak \and Robert Przybylski \and Paweł Walczuk ",
title = "{DiploMan-1 -- Internetowy system zarządzania pracami dyplomowymi}",
school = "Poznan University of Technology",
address = "Pozna{\’n}, Poland",
year = "2008",
}

diploman-1 – internetowy system zarządzania pracami dyplomowymi

Transkrypt

Podobne dokumenty

Lista tematów prezentacji studenckich: 1. Rodzina i narodziny

Tematy prac kontrolnych – Kurs R6 Rok szkolny: 2014/2015 semestr I

PROCES DYPLOMOWANIA 1. Do końca października każdy Prom

ZESPOŁOWY PROJEKT EDUKACYJNY W GIMNAZJUM

Zasady wyboru promotorów, tematów prac i ustalania oceny

Konto pocztowe dla nauczycieli

Propozycja tematyki godzin wychowawczych