Upload
pawe-traczyski
View
207
Download
0
Embed Size (px)
Citation preview
W A R S Z A W S K AW Y Ż S Z A S Z K O Ł A I N F O R M A T Y K I
P R A C A D Y P L O M O W AW Y Ż S Z E S T U D I A Z A W O D O W E
Paweł TRACZYŃSKINumer albumu 3738
Projekt i implementacja systemu informatycznego wspomagającego zarządzanie archiwum firmy geotechnicznej
Promotor:prof. dr hab. inż. Włodzimierz KASPRZAK
Praca spełnia wymagania stawiane pracom inżynierskimna studiach inżynierskich
W A R S Z A W A 2008
Spis treści
1. Wstęp.......................................................................................................................................5
1.1. Wprowadzenie.................................................................................................................5
1.2. Cel...................................................................................................................................5
1.3. Zakres pracy....................................................................................................................5
2. Wybrane modele cyklu życia oprogramowania......................................................................7
2.1. Model kaskadowy............................................................................................................7
2.2. Model spiralny.................................................................................................................9
3. Opis problemu klienta...........................................................................................................12
3.1. Wprowadzenie do geotechniki......................................................................................12
3.2. Charakterystyka działalności ZBG Geotest...................................................................12
3.3. Dokumentowanie badań................................................................................................13
3.4. System tworzony w niniejszej pracy.............................................................................13
4. Analiza..................................................................................................................................15
4.1. Aktorzy..........................................................................................................................15
4.2. Uprawnienia..................................................................................................................15
4.3. Przypadki użycia...........................................................................................................17
4.3.1. Lista przypadków użycia.......................................................................................17
4.3.2. Diagramy przypadków użycia...............................................................................18
4.3.3. Opisy przypadków użycia......................................................................................19
5. Założenia projektowe............................................................................................................30
5.1. Wymagane funkcje systemu..........................................................................................30
5.2. Wymogi pozafunkcyjne................................................................................................31
5.3. Prawa użytkowników....................................................................................................33
5.4. Logowanie.....................................................................................................................33
5.5. Bezpieczeństwo.............................................................................................................34
6. Wybór i prezentacja technologii...........................................................................................35
6.1. Technologie wykorzystane w procesie realizacji..........................................................35
6.1.1. ASP.NET 3.5 i C#.................................................................................................35
6.1.2. Microsoft SQL Server 2005...................................................................................37
6.2. Wywiad z szefem firmy Meant4.pl...............................................................................38
7. Projekt...................................................................................................................................41
7.1. Wybór nazwy................................................................................................................41
2
7.2. Projekt bazy danych......................................................................................................41
7.2.1. Przechowywane dane.............................................................................................41
7.2.2. Wybrana technologia.............................................................................................44
7.2.3. Tabele....................................................................................................................44
7.2.4. Właściwości tabel..................................................................................................45
7.2.5. Relacje...................................................................................................................52
7.3. Projekt aplikacji.............................................................................................................60
7.3.1. Lista stron..............................................................................................................60
7.3.2. Schemat połączeń między stronami.......................................................................60
7.3.3. Główne elementy stron..........................................................................................62
7.3.4. Interakcje...............................................................................................................73
7.3.5. Opis interfejsu użytkownika..................................................................................92
8. Implementacja.......................................................................................................................94
8.1. Fazy procesu implementacji..........................................................................................94
8.2. Implementacja bazy danych..........................................................................................94
8.3. Implementacja bazowej strony www............................................................................94
8.4. Implementacja interfejsów stron ASP.NET..................................................................95
8.5. Implementacja funkcjonalności stron ASP.NET...........................................................95
8.6. Obsługa systemu............................................................................................................96
8.6.1. Logowanie.............................................................................................................96
8.6.2. Strona główna........................................................................................................97
8.6.3. Przeglądanie listy wszystkich dokumentacji.........................................................98
8.6.4. Wyszukiwanie dokumentacji...............................................................................100
8.6.5. Przeglądanie szczegółów wybranej dokumentacji..............................................101
8.6.6. Dodawanie nowej dokumentacji do archiwum....................................................103
8.6.7. Dodawanie nowej miejscowości / Edycja nazwy miejscowości.........................105
8.6.8. Dodawanie nowej ulicy / Edycja nazwy ulicy.....................................................106
8.6.9. Edycja dokumentacji...........................................................................................107
8.6.10. Wylogowanie.....................................................................................................108
9. Testowanie..........................................................................................................................110
9.1. Istota testowania..........................................................................................................110
9.1.1. Proces testowania.................................................................................................110
9.2. Wykonane testy...........................................................................................................112
9.3. Odnalezione typy błędów............................................................................................113
3
9.4. Poprawianie błędów....................................................................................................113
10. Możliwości rozbudowy systemu.......................................................................................117
10.1. Łatwość modyfikacji wyglądu stron internetowych..................................................117
10.2. Centralne zarządzanie................................................................................................117
10.3. Dokładnie opisany kod programu.............................................................................117
11. Podsumowanie..................................................................................................................118
12. Wykaz literatury................................................................................................................119
13. Załączniki..........................................................................................................................120
4
1. Wstęp
1.1. Wprowadzenie
Archiwizacja jest procesem tworzenia zbioru kopii danych w celu zabezpieczenia
przed ich utratą, bądź w celu ich uporządkowania, tak aby szybko i łatwo można było
odnaleźć konkretne dane. Miejsce, w którym się je przetrzymuje nazywane jest archiwum.
Dane w archiwum nie są potrzebne w chwili obecnej, nie związane są z aktualnymi
projektami firmy, jednak mogą okazać się potrzebne w przyszłości. Wiele firm prowadzi
archiwizację danych dotyczących swojej działalności i korzysta z nich w późniejszej pracy. W
związku z czym konieczny jest do nich łatwy i szybki dostęp, a tym samym dobry system do
archiwizacji.
Taką właśnie firmą jest zaprzyjaźniony z autorem pracy Geotest. Firma tworzy
dokumentacje i potrzebuje mieć do nich stały i łatwy wgląd. Przydatny jest do tego dobry
system archiwizacji, którego stworzenia podjął się autor pracy.
1.2. Cel
Celem pracy jest stworzenie projektu i implementacji systemu informatycznego
wspomagającego zarządzanie archiwum firmy geotechnicznej.
1.3. Zakres pracy
Praca obejmuje:
● omówienie wybranych modeli cyklu życia oprogramowania;
● omówienie działalności firmy dla której realizowany jest projekt;
● analityczny opis planowanego systemu;
● opis głównych założeń projektowych i wymogów względem systemu;
● omówienie technologii wybranych do realizacji systemu;
● projekt bazy danych;
● projekt aplikacji;
● opis implementacji systemu;
● opis testowania;
5
● opis możliwości rozbudowy systemy;
● podsumowanie.
6
2. Wybrane modele cyklu życia oprogramowania
Cykl życia oprogramowania, inaczej określany procesem tworzenia oprogramowania,
jest okresem trwającym od powstania pierwszych planów aplikacji, poprzez moment
ukończenia jej tworzenia, aż do nastąpienia ewolucji aplikacji, bądź zaniechania jej używania
(na ogół ze względu na jej przestarzały charakter i zastąpienie jej nowszym, lepszym
odpowiednikiem) [4].
Modele cyklu życia oprogramowania przedstawiają kolejne okresy życia aplikacji, co
pozwala łatwiej i efektowniej zaplanować prace związane z jej tworzeniem. Dziedzina
zajmująca się omawianiem tych modeli nazywa się inżynierią oprogramowania. Zajmuje się
ona wszelkimi aspektami związanymi z wytwarzaniem oprogramowania, od analizy i
określenia wymagań, przez projektowanie, wdrożenie, testowanie, na ewolucji kończąc [4].
Każda aplikacja "żyje" zgodnie z jakimś modelem. Wybranie odpowiedniego modelu
dla planowanej aplikacji i dobre jego zrozumienie pozwala lepiej ją zaplanować i
przygotować. Umożliwia to również uniknąć późniejszych rozczarowań, ponieważ ułatwia
"spojrzenie" w przyszłość związaną z aplikacją [4].
W niniejszym rozdziale omówiono dwa wybrane modele cyklu życia
oprogramowania: model kaskadowy i model spiralny.
2.1. Model kaskadowy
Model kaskadowy jest podstawowym modelem cyklu życia oprogramowania, w
którym kolejne kroki wytwarzania oprogramowania są ukazywane pod poprzednimi, w
związku z czym nazywany jest także modelem wodospadowym (Rys. 2.1). Określa on
następujące kroki:
● Planowanie systemu - np. specyfikacja wymagań;
● Analizę systemu;
● Projekt systemu;
● Implementację;
● Testowanie;
● Wdrożenie i pielęgnację [4].
7
Rys. 2.1. Schemat modelu kaskadowego [5].
W modelu kaskadowym produkt każdego etapu jest oceniany. Jeżeli jest on
satysfakcjonujący to można przejść do następnego kroku. Jeżeli nie jest satysfakcjonujący to
należy powtórzyć jego realizację lub cofnąć się do kroku poprzedniego [4].
Model kaskadowy najlepiej sprawdza się dla prostych aplikacji, z jasno
wyznaczonymi wymaganiami względem projektu. Zaletą tego modelu jest jego wymóg, aby
wynik zakończonej fazy realizacji oprogramowania był co najmniej zadowalający. W
przypadku niedoróbek, błędów itp. wynik nie jest zadowalający i nie można przejść do
następnego kroku. Zmusza to realizatorów projektu do zrobienia wszystkiego, aby był on jak
najdoskonalszy. Teoretycznie zmniejsza to ilość pojawiających się później błędów, ponieważ
wykrywane są one w fazie, w której powstały. Jest to ekonomiczne rozwiązanie, gdyż
późniejsze poprawianie oprogramowania jest dużo bardziej kosztowne i czasochłonne, niż
dokonywanie poprawek w fazie jego wytwarzania [4].
Inną zaletą tego modelu jest to, że wymaga on dokładnego udokumentowania i
zaprojektowania każdej fazy tworzenia oprogramowania. W mniej udokumentowanych i
mniej dokładnie zaprojektowanych metodologiach dużo wiedzy i pomysłów jest tracona (z
powodu zawodności pamięci ludzkiej) [4].
8
Wadami modelu kaskadowego są:
● brak możliwości przejścia do kolejnej fazy przed zakończeniem zadań fazy
poprzedniej (narzucona twórcom oprogramowania ścisła kolejność realizacji prac);
● model ten jest nieelastyczny, ponieważ posiada sztywny podział na określone fazy;
● iteracje mogą być bardzo kosztowne w przypadku powtarzania wielokrotnie różnych
kroków, z powodu niezadowalających wyników kolejnych faz [4].
Wielu projektantów uważa ten model za niewłaściwy, głównie dlatego, że są oni
przekonani, że w przypadku złożonego projektu niemożliwe jest ukończenie jednej fazy
projektu przed przejściem do fazy kolejnej, podczas której można wywnioskować co powinno
być poprawione w fazie poprzedniej. Przykład: klient zamawiający oprogramowanie może nie
być pewien swoich wymagań względem realizowanego systemu, dopóki nie zobaczy
działającej wersji wstępnej, którą może skomentować [4].
2.2. Model spiralny
Podczas wytwarzania złożonego oprogramowania zazwyczaj wielokrotnie okazuje się,
że jakaś jego część powinna być wykonana inaczej, niż została wcześniej zrobiona. Dlatego w
przypadku złożonych systemów informatycznych bardziej sprawdzającym się modelem jest
model spiralny (Rys. 2.2).
Model spiralny przedstawia proces tworzenia oprogramowania w postaci spirali, której
każda pętla reprezentuje jedną fazę całego procesu wytwarzania. Najbardziej wewnętrzna
pętla przedstawia początkowe etapy projektowania np. określanie zapotrzebowania oraz
studiowanie wykonalności poszczególnych elementów systemu. Bardziej zewnętrzne pętle w
bardziej szczegółowy i precyzyjny sposób opisują wytwarzane oprogramowanie. Każda pętla
spirali podzielona jest na cztery sektory, z których każdy określa kolejny etap tworzenia.
Etapami tymi są:
● Określanie celów i wytycznych. Ustalanie planów realizacji;
● Analiza ryzyka. Rozpoznanie i redukcja zagrożeń;
● Wytworzenie części produktu opisanej przez daną pętlę (iterację spirali) oraz
upewnienie się, że część jest wykonana poprawnie. Kroku tego dokonuje się w
oparciu o inny wybrany model (np. kaskadowy);
● Ocena postępu prac i planowanie kolejnej fazy przedsięwzięcia, bądź zakończenie
9
projektu [4].
Rys. 2.2. Schemat modelu spiralnego [P. Traczyński na podstawie 4, 5].
Model spiralny w bardzo dobry sposób pozwala rozpoznać zagrożenia i pomaga
przedsięwziąć odpowiednie kroki w celu ich redukcji. Efektem jest wysoki stopień
możliwości polegania na wytworzonym oprogramowaniu. Projekt utworzony w oparciu o
model spiralny ma większe szanse na dalszą realizację, ponieważ każdą fazę tworzenia
projektu można przechodzić ponownie w kolejnej iteracji (sektorze) spirali [4].
Model spiralny ma następujące zalety:
● Projekty powstałe podczas ostatniego cyklu spirali można często wprowadzić już do
użytku;
● Dokładna faza oceny w każdym cyklu pomaga uniknąć błędów lub wcześniej je
wykryć;
● Cały czas istnieje możliwość kontynuacji tworzenia projektu;
10
● Wszelkie kalkulacje (np. finansowe, czasowe) stają się łatwiejsze do określenia
podczas trwania projektu;
● Programiści mogą wcześniej rozpocząć prace nad kodem aplikacji [4].
Model spiralny najlepiej sprawdza się dla rozbudowanych, złożonych aplikacji.
11
3. Opis problemu klienta
3.1. Wprowadzenie do geotechniki
Każdą inwestycję budowlaną poprzedza faza projektowa. Na etapie projektowania
sporządza się dokumentację geotechniczną, która opisuje warunki wodno-gruntowe panujące
na terenie planowanej inwestycji. Na przekrojach geologiczno-inżynierskich pokazany jest
układ warstw gruntu i zaznaczone są poziomy wód gruntowych. W części opisowej
zestawione są parametry geotechniczne, mówiące o właściwościach fizycznych
i mechanicznych każdej warstwy i umożliwiające wykonanie projektu fundamentów.
Dokumentacje geotechniczne wykonywane są na podstawie badań: terenowych oraz
laboratoryjnych i sporządzane przez firmy geotechniczne. Na terenie projektowanych
inwestycji wykonuje się otwory badawcze, które umożliwiają rozpoznanie budowy
geologicznej oraz pomiar głębokości występowania wód gruntowych. Z otworów pobierane
są próby gruntu do badań laboratoryjnych. W terenie przeprowadza się także różnego typu
sondowania gruntów, które pozwalają określić ich nośność czyli zdolność do przenoszenia
obciążeń.
W Warszawie działa spora grupa firm geotechnicznych. Do tej grupy należy Zakład
Badań Geotechnicznych GEOTEST.
3.2. Charakterystyka działalności ZBG Geotest
Firma Geotest działa nieprzerwanie od 1990 roku. Zakres jej działalności obejmuje
sporządzanie dokumentacji geotechnicznych i geologiczno-inżynierskich. Dokumentacje
geologiczno-inżynierskie są szczególnym typem dokumentacji, które sporządza się dla
dużych projektów budowlanych (budynki wysokie, budynki z wielopoziomowymi garażami
podziemnymi, itp.). W firmie przygotowuje się też projekty prac geologicznych, które są
podstawą do opracowania dokumentacji geologiczno-inżynierskich. Geotest zajmuje się
ponadto badaniami zanieczyszczenia środowiska. W pobranych próbach wody i gruntu
określa się zawartość metali ciężkich i substancji ropopochodnych.
W celu oznaczenia wahań poziomów wód gruntowych firma instaluje na badanym
terenie specjalne studnie, tzw. piezometry, które pozwalają monitorować poziom wody
gruntowej.
12
Firma wykonuje także:
● kontrolę zagęszczenia gruntu;
● badania geotechniczne dla składowisk odpadów;
● projekty drenaży budowlanych;
● projekty zabezpieczeń skarp wykopów;
● obliczenia stateczności skarpy;
● określa przyczyny spękań budynków;
● określa przyczyny zawilgocenia piwnic;
● a także prowadzi wszelkiego rodzaju konsultacje geotechniczne.
3.3. Dokumentowanie badań
Każda wykonywana przez firmę Geotest praca zostaje przedstawiona w dokumentacji
geotechnicznej, geologiczno-inżynierskiej lub projektowej. W pierwszych latach prowadzonej
działalności ilość wykonywanych dokumentacji była stosunkowo niewielka. Wraz z
rozwojem gospodarczym kraju wzrosła liczba opracowań. Najlepiej ilustruje ten fakt to, że w
czasie pierwszych czternastu lat działalności firmy opracowano 2000 dokumentacji, a na
kolejny tysiąc czekać trzeba było niecałe trzy lata. Zbiór opracowań zrobił się tak liczny, że
kłopotliwe i czasochłonne stało się przeszukiwanie danych archiwalnych.
Potrzebny stał się system informatyczny, który zarządzał by bazą danych. Zawierałaby
ona najważniejsze informacje z wykonanych dokumentacji. System umożliwiłby szybkie
odnajdywanie dokumentacji według różnych kryteriów (np. adresu, daty lub numeru
dokumentacji).
3.4. System tworzony w niniejszej pracy
Dokumentacje opracowane na potrzeby już zrealizowanych budów nie pozostają
bezużyteczne. Pracownicy firmy stale korzystają z archiwum, gdyż wyniki wcześniejszych
badań wykorzystuje się przy tworzeniu nowych opracowań.
Sprawnie działający system informatyczny znacznie ułatwiłby prace przynosząc
jednocześnie spore korzyści.
Dokumentacje znajdują się w biurze zarówno w archiwum na dyskach twardych jak i
w formie papierowej w segregatorach. W celu zaczerpnięcia danych należy odszukać
dokumentację w archiwum. Sam system zaś, ma zawierać w bazie tylko najbardziej istotne
13
informacje (takie jak: ilość otworów wykonanych na działce, ich głębokość czy jakie było
zbadane podłoże gruntowe).
14
4. Analiza
4.1. Aktorzy
W systemie wyróżnia się następujących aktorów (Rys. 4.1):
● Użytkownik anonimowy
Każdy użytkownik przed zalogowaniem się jest traktowany przez system jako
użytkownik tej grupy.
● Użytkownik ograniczony
Posiada prawa do przeglądania zawartości. Nie może dokonywać żadnych zmian w
archiwum.
● Administrator
Może zarówno przeglądać zawartość archiwum jak i dokonywać edycji zawartości.
Aktorzy abstrakcyjni to:
● Użytkownik
Aktorem tym jest każdy użytkownik.
● Użytkownik zalogowany
Jest nim każdy użytkownik który jest zalogowany (do grupy tej należą aktorzy:
"Użytkownik ograniczony" oraz "Administrator").
4.2. Uprawnienia
Uprawnienia aktorów są realizowane zgodnie z założeniami projektowymi i zależą od
tego jaki aktor korzysta z systemu.
Użytkownik anonimowy
Zgodnie z wymogami względem projektu użytkownicy niezalogowani mogą wejść
tylko na stronę logowania lub stronę pomocy.
Użytkownik ograniczony
Ma wszystkie prawa posiadane przez grupę użytkowników niezalogowanych oraz
dodatkowo może przeglądać zawartość archiwum, przeszukiwać je itp. Może wykonywać
15
wszystkie operacje związane z odczytem danych. Nie może natomiast dokonywać
jakiejkolwiek edycji. Nie posiada również praw do wchodzenia na strony edycyjne -
odpowiednie linki w menu skierowujące na te strony są nieaktywne (a ich kolor jest
zmieniony).
Administrator
Administrator ma pełne uprawnienia do korzystania z wszystkich funkcji systemu.
Rys. 4.1. Aktorzy systemu [P. Traczyński]
16
4.3. Przypadki użycia
4.3.1. Lista przypadków użycia
Dostęp do systemu
● 1.1 Zalogowanie
● 1.2 Wylogowanie
Przeglądanie zasobów
● 2.1 Przeglądanie listy wszystkich dokumentacji
● 2.2 Filtrowanie listy wszystkich dokumentacji
● 2.3 Wyszukiwanie dokumentacji
● 2.4 Przechodzenie pomiędzy stronami wyników
● 2.5 Sortowanie wyświetlanych danych
● 2.6 Przeglądanie danych szczegółowych
Edycja danych
● 3.1 Dodawanie nowej dokumentacji
● 3.2 Dodawanie nowej miejscowości
● 3.3 Dodawanie nowej ulicy
● 3.4 Modyfikowanie istniejącej dokumentacji
● 3.5 Modyfikowanie nazwy miejscowości
● 3.6 Modyfikowanie nazwy ulicy
Funkcje dodatkowe
● 4.1 Otwarcie strony pomocy
17
4.3.2. Diagramy przypadków użycia
Na diagramach przedstawiono kolejne przypadki użycia czyli możliwe interakcje
pomiędzy aktorem (użytkownikiem systemu) a systemem (Rys. 4.2. – Rys. 4.5.).
Rys. 4.2. Diagram: dostęp do systemu [P. Traczyński].
Rys. 4.3. Diagram: przeglądanie zasobów [P. Traczyński].
18
Rys. 4.4. Diagram: edycja danych [P. Traczyński].
Rys. 4.5. Diagram: funkcje dodatkowe [P. Traczyński].
4.3.3. Opisy przypadków użycia
Przypadek użycia: 1.1 Zalogowanie
Aktorzy: Użytkownik anonimowy
Warunki wstępne: System jest dostępny. Użytkownik nie jest zalogowany.
Oczekiwane wyniki: Użytkownik zostanie zalogowany.
19
Przepływ podstawowy:
1. Wyświetlona zostaje strona logowania.
2. Użytkownik anonimowy podaje login i hasło.
3. Użytkownik naciska przycisk "Zaloguj"
4. System weryfikuje podane dane.
5. Użytkownik zostaje zalogowany do systemu.
Przepływy alternatywne:
#1. W punkcie 3. użytkownik nie podał loginu lub hasła, bądź obydwu. System
informuje użytkownika o niepodaniu wymaganych danych.
#2. W punkcie 3 użytkownik wprowadza błędny login lub błędne hasło. System
informuje użytkownika o podaniu błędnych danych.
Przypadek użycia: 1.2 Wylogowanie
Aktorzy: Użytkownik zalogowany (Użytkownik ograniczony, Administrator)
Warunki wstępne: System jest dostępny. Użytkownik jest zalogowany.
Oczekiwane wyniki: Użytkownik zostanie wylogowany.
Przepływ podstawowy:
1. Użytkownik wybiera w menu opcję "Wyloguj"
2. Użytkownik zostaje wylogowany.
3. System wyświetla informacje potwierdzającą poprawne wylogowanie.
Przepływy alternatywne:
Brak.
Przypadek użycia: 2.1 Przeglądanie listy wszystkich dokumentacji
Aktorzy: Użytkownik zalogowany (Użytkownik ograniczony, Administrator)
Warunki wstępne: System jest dostępny. Użytkownik jest zalogowany.
Oczekiwane wyniki: Wyświetlona zostanie lista wszystkich dokumentacji.
20
Przepływ podstawowy:
1. Użytkownik wybiera w menu opcję "Lista".
2. System wyświetla stronę z listą wszystkich dokumentacji.
Przepływy alternatywne:
#1. System nie może połączyć się z bazą danych. Strona listy dokumentacji nie
zawiera danych o dokumentacjach. Wyświetlony zostaje komunikat o braku połączenia.
Przypadek użycia: 2.2 Filtrowanie listy wszystkich dokumentacji
Aktorzy: Użytkownik zalogowany (Użytkownik ograniczony, Administrator)
Warunki wstępne: System jest dostępny. Użytkownik jest zalogowany. Użytkownik
jest na stronie Lista wszystkich dokumentacji.
Oczekiwane wyniki: Wyświetlone zostaną dokumentacje z wybranego przedziału lat.
Przepływ podstawowy:
1. Użytkownik podaje w "Opcjach" zakres lat.
2. Użytkownik naciska przycisk "Filtruj".
3. System odświeża listę dokumentacji pokazując tylko te wykonane w podanym
przedziale lat.
Przepływy alternatywne:
#1. W punkcie 1. użytkownik podał tylko rok otwierający przedział. Wyświetlone
zostają tylko dokumentacje z danego roku.
#2. W punkcie 1. użytkownik podał tylko rok zamykający przedział. Filtrowanie
zostaje zignorowane. Wyświetlone zostają wszystkie wpisy.
#3. W punkcie 1. użytkownik podał rok otwierający przedział jako późniejszy od roku
zamykającego przedział. System wyświetla komunikat "Wartość w pierwszym polu musi być
mniejsza od wartości w drugim polu."
#4. W punkcie 1. użytkownik podał niepoprawne dane (rok musi mieć formę liczby
czterocyfrowej). System wyświetla komunikat o niepoprawnych danych.
#6. System nie odnalazł dokumentacji z podanych lat. Wyświetlony zostaje komunikat
"Brak danych do wyświetlenia".
#7. System nie może połączyć się z bazą danych. Wyświetlony zostaje komunikat o
21
braku połączenia.
Przypadek użycia: 2.3 Wyszukiwanie dokumentacji
Aktorzy: Użytkownik zalogowany (Użytkownik ograniczony, Administrator)
Warunki wstępne: System jest dostępny. Użytkownik jest zalogowany.
Oczekiwane wyniki: Wyświetlone zostaną dokumentacje spełniające kryteria
wyszukiwania.
Przepływ podstawowy:
1. Użytkownik wybiera w menu opcję "Szukaj"
2. System wyświetla stronę wyszukiwania dokumentacji.
3. Użytkownik podaje w "Opcjach" wybrane kryteria wyszukiwania
4. System wyświetla wyniki wyszukiwań dla zapytania podanego przez użytkownika
Przepływy alternatywne:
#1. W punkcie 1 użytkownik podał niepoprawne dane. System wyświetla komunikat
informujący użytkownika o charakterze błędu.
#2. System nie odnalazł dokumentacji spełniających podane kryteria. Wyświetlony
zostaje komunikat "Brak danych do wyświetlenia".
#3. W punkcie 3. użytkownik nie podał żadnych danych. Po wykonaniu punkty 4.
system wyświetli wszystkie dokumentacje zapisane w bazie danych.
#4. System nie może połączyć się z bazą danych. Wyświetlony zostaje komunikat o
braku połączenia.
Przypadek użycia: 2.4 Przechodzenie pomiędzy stronami wyników
Aktorzy: Użytkownik zalogowany (Użytkownik ograniczony, Administrator)
Warunki wstępne: System jest dostępny. Użytkownik jest zalogowany. Użytkownik
jest na stronie Lista wszystkich dokumentacji lub Wyszukiwanie dokumentacji (z
wyświetlonymi wynikami wyszukiwania).
Oczekiwane wyniki: Wyświetlona zostanie wybrana strona wyników.
22
Przepływ podstawowy:
1. Użytkownik wybiera u dołu listy dokumentacji numer strony którą chce zobaczyć.
2. System zmienia wyświetlaną stronę danych na wybraną przez użytkownika.
Przepływy alternatywne:
Brak.
Przypadek użycia: 2.5 Sortowanie wyświetlanych danych
Aktorzy: Użytkownik zalogowany (Użytkownik ograniczony, Administrator)
Warunki wstępne: System jest dostępny. Użytkownik jest zalogowany. Użytkownik
jest na stronie Lista wszystkich dokumentacji lub Wyszukiwanie dokumentacji (z
wyświetlonymi wynikami wyszukiwania).
Oczekiwane wyniki: Wyświetlane dane zostaną posortowane alfabetycznie według
wartości z wybranej kolumny.
Przepływ podstawowy:
1. Użytkownik klika nazwę kolumny według której chce posortować dane.
2. System zmienia kolejność wyświetlanych danych tak aby układały się rosnąco
według wartości z wybranej przez użytkownika kolumny.
Przepływy alternatywne:
#1. W punkcie pierwszym użytkownik ponownie kliknął tą samą kolumnę. Kolejność
sortowania zostaje odwrócona.
Przypadek użycia: 2.6 Przeglądanie danych szczegółowych
Aktorzy: Użytkownik zalogowany (Użytkownik ograniczony, Administrator)
Warunki wstępne: System jest dostępny. Użytkownik jest zalogowany. Użytkownik
jest na stronie Lista wszystkich dokumentacji lub Wyszukiwanie dokumentacji (z
wyświetlonymi wynikami wyszukiwania).
Oczekiwane wyniki: Wyświetlona zostanie strona z danymi szczegółowymi wybranej
dokumentacji.
23
Przepływ podstawowy:
1. Użytkownik klika na odnośnik w kolumnie "Szczegóły" w wierszu tej dokumentacji
której dane szczegółowe chce zobaczyć.
2. System przenosi użytkownika na stronę danych szczegółowych wybranej
dokumentacji.
Przepływy alternatywne:
Brak.
Przypadek użycia: 3.1 Dodawanie nowej dokumentacji
Aktorzy: Administrator
Warunki wstępne: System jest dostępny. Użytkownik grupy 'Administrator' jest
zalogowany.
Oczekiwane wyniki: Do systemu dodane zostaną informacje o nowej dokumentacji.
Przepływ podstawowy:
1. Użytkownik wybiera w menu opcję "Dodaj".
2. System przenosi użytkownika na stronę "Dodawanie dokumentacji".
3. System sprawdza jakie ID będzie miała dodawana dokumentacja.
4. System sprawdza w bazie danych jakie są możliwe opcje wyboru dla odpowiednich
pól DropDownList (w ASP.NET odpowiednik ComboBox - lista rozwijana).
5. Informacje z dwóch powyższych punktów zostają wyświetlone na stronie.
6. Użytkownik podaje odpowiednie dane w odpowiednich polach tekstowych oraz
wybiera. odpowiednie opcje z odpowiednich list rozwijanych.
7. Użytkownik naciska przycisk "Zapisz".
8. System sprawdza poprawność wprowadzonych danych.
9. Dane nowej dokumentacji zostają zapisane w bazie danych.
10. System wyświetla szczegóły nowo dodanej dokumentacji oraz komunikat o
pomyślnym dodaniu jej do bazy danych.
Przepływy alternatywne:
#1. W punkcie 6 użytkownik nie podał wszystkich wymaganych danych. System
wyświetla komunikat informujący użytkownika o brakujących danych.
24
#2. W punkcie 6 użytkownik podał niepoprawne dane. System wyświetla komunikat
informujący użytkownika o charakterze błędu.
#3. W punkcie 6 użytkownik nie odnajduje w na liście rozwijanej określonej nazwy
miejscowości. Użytkownik przechodzi do wykonania przypadku użycia UC3.2. Po
zamknięciu okna obsługującego przypadek UC3.2, użytkownik wciska przycisk "Odśwież" i
wybiera z listy wymaganą nazwę ulicy.
#4. System nie może połączyć się z bazą danych. Wyświetlony zostaje komunikat o
braku połączenia.
Przypadek użycia: 3.2 Dodawanie nowej miejscowości
Aktorzy: Administrator
Warunki wstępne: System jest dostępny. Użytkownik grupy 'Administrator' jest
zalogowany. Użytkownik jest na stronie Dodawanie dokumentacji lub Edycja dokumentacji.
Oczekiwane wyniki: Do systemu dodana zostanie nowa miejscowość.
Przepływ podstawowy:
1. Użytkownik naciska w Opcjach przycisk "Miejscowości".
2. System wyświetla okno "Dodawanie miejscowości".
3. Użytkownik wpisuje nową miejscowość w polu tekstowym "Nazwa".
4. Użytkownik naciska przycisk "Zapisz".
5. System zapisuje w bazie danych nazwę nowej miejscowości.
Przepływy alternatywne:
#1. W punkcie 3. użytkownik nie podał danych. System wyświetla komunikat o
obowiązku podania nazwy miejscowości.
#2. W punkcie 3. użytkownik podał nazwę miejscowości, która znajduje się już w
bazie. System wyświetla komunikat informujący o charakterze błędu.
#3. System nie może połączyć się z bazą danych. Wyświetlony zostaje komunikat o
braku połączenia.
Przypadek użycia: 3.3 Dodawanie nowej ulicy
Aktorzy: Administrator
25
Warunki wstępne: System jest dostępny. Użytkownik grupy 'Administrator' jest
zalogowany. Użytkownik jest na stronie Dodawanie dokumentacji lub Edycja dokumentacji.
Oczekiwane wyniki: Do systemu dodana zostanie nowa ulica.
Przepływ podstawowy:
1. Użytkownik naciska w Opcjach przycisk "Ulice".
2. System wyświetla okno "Dodawanie ulicy".
3. Użytkownik wpisuje nową ulicę w polu tekstowym "Nazwa".
4. Użytkownik naciska przycisk "Zapisz".
5. System sprawdza poprawność wprowadzonych danych.
6. System zapisuje w bazie danych nazwę nowej ulicy.
Przepływy alternatywne:
#1. W punkcie 3. użytkownik nie podał danych. System wyświetla komunikat o
obowiązku podania nazwy ulicy.
#2. W punkcie 3. użytkownik podał nazwę ulicy, która znajduje się już w bazie.
System wyświetla komunikat informujący o charakterze błędu.
#3. W punkcie 3 użytkownik podał niepoprawne dane. System wyświetla komunikat
informujący o charakterze błędu (każda nazwa ulicy musi być poprzedzona przedrostkiem,
np. "ul. " bądź "Al. "; powodem jest występowanie w obrębie jednej miejscowości ulic i Alei
o identycznych nazwach, np. Wilanowska).
#4. System nie może połączyć się z bazą danych. Wyświetlony zostaje komunikat o
braku połączenia.
Przypadek użycia: 3.4 Modyfikacja istniejącej dokumentacji
Aktorzy: Administrator
Warunki wstępne: System jest dostępny. Użytkownik grupy 'Administrator' jest
zalogowany.
Oczekiwane wyniki: Dane na temat wybranej dokumentacji zostaną zmodyfikowane.
Przepływ podstawowy:
1. Użytkownik wybiera w menu opcję "Edytuj".
2. System przenosi użytkownika na stronę "Edycja dokumentacji".
26
3. Użytkownik podaje w "Opcjach" id dokumentacji którą chce edytować
4. Użytkownik naciska przycisk "Wybierz".
5. System sprawdza w bazie danych jakie są możliwe opcje wyboru dla odpowiednich
pól DropDownList (w ASP.NET odpowiednik ComboBox - lista rozwijana).
6. System wczytuje dane wybranej dokumentacji
7. Użytkownik dokonuje edycji danych.
8. Użytkownik naciska przycisk "Zapisz".
9. System sprawdza poprawność wprowadzonych danych.
10. Zmienione dane zostają zapisane w bazie danych.
Przepływy alternatywne:
#1. W punkcie 7 użytkownik usunął dane z pól wymaganych. System wyświetla
komunikat informujący użytkownika o brakujących danych.
#2. W punkcie 7 użytkownik podał niepoprawne dane. System wyświetla komunikat
informujący użytkownika o charakterze błędu.
#3. W punkcie 7 użytkownik nie odnajduje w na liście rozwijanej określonej nazwy
miejscowości. Użytkownik przechodzi do wykonania przypadku użycia UC3.2. Po
zamknięciu okna obsługującego przypadek UC3.2, użytkownik wciska przycisk "Odśwież" i
wybiera z listy wymaganą nazwę ulicy.
#4. System nie może połączyć się z bazą danych. Wyświetlony zostaje komunikat o
braku połączenia.
Przypadek użycia: 3.5 Modyfikacja nazwy miejscowości
Aktorzy: Administrator
Warunki wstępne: System jest dostępny. Użytkownik grupy 'Administrator' jest
zalogowany. Użytkownik jest na stronie Dodawanie dokumentacji lub Edycja dokumentacji.
Oczekiwane wyniki: Nazwa wybranej miejscowości zostanie zmodyfikowana.
Przepływ podstawowy:
1. Użytkownik naciska w Opcjach przycisk "Miejscowości".
2. System wyświetla okno "Dodawanie miejscowości".
3. Użytkownik wpisuje dotychczasową nazwę miejscowości w polu tekstowym
"Nazwa".
27
4. Użytkownik zaznacza opcję "Aktualizacja"
5. Użytkownik wpisuję poprawioną nazwę miejscowości w polu tekstowym "Popraw".
6. Użytkownik naciska przycisk "Zapisz".
7. System zapisuje w bazie danych zmienioną nazwę miejscowości.
Przepływy alternatywne:
#1. W punkcie 3. użytkownik nie podał danych. System wyświetla komunikat o
obowiązku podania nazwy miejscowości.
#2. W punkcie 5. użytkownik nie podał danych. System wyświetla komunikat o
obowiązku podania poprawionej nazwy miejscowości.
#3. W punkcie 3. użytkownik podał nazwę miejscowości, której nie ma w bazie.
System wyświetla komunikat informujący o charakterze błędu.
#4. System nie może połączyć się z bazą danych. Wyświetlony zostaje komunikat o
braku połączenia.
#5. W przypadku gdy użytkownik nie zaznaczy opcji "Aktualizacja" wykonany
zostanie przypadek użycia UC3.2.
Przypadek użycia: 3.6 Modyfikacja nazwy ulicy
Aktorzy: Administrator
Warunki wstępne: System jest dostępny. Użytkownik grupy 'Administrator' jest
zalogowany. Użytkownik jest na stronie Dodawanie dokumentacji lub Edycja dokumentacji.
Oczekiwane wyniki: Nazwa wybranej ulicy zostanie zmodyfikowana.
Przepływ podstawowy:
1. Użytkownik naciska w Opcjach przycisk "Ulice".
2. System wyświetla okno "Dodawanie ulicy".
3. Użytkownik wpisuje dotychczasową nazwę ulicy w polu tekstowym "Nazwa".
4. Użytkownik zaznacza opcję "Aktualizacja"
5. Użytkownik wpisuję poprawioną nazwę ulicy w polu tekstowym "Popraw".
6. Użytkownik naciska przycisk "Zapisz".
7. System sprawdza poprawność wprowadzonych danych.
8. System zapisuje w bazie danych zmienioną nazwę ulicy.
28
Przepływy alternatywne:
#1. W punkcie 3. użytkownik nie podał danych. System wyświetla komunikat o
obowiązku podania nazwy ulicy.
#2. W punkcie 5. użytkownik nie podał danych. System wyświetla komunikat o
obowiązku podania poprawionej nazwy miejscowości.
#3. W punkcie 3 użytkownik podał niepoprawne dane. System wyświetla komunikat
informujący o charakterze błędu.
#4. W punkcie 5 użytkownik podał niepoprawne dane. System wyświetla komunikat
informujący o charakterze błędu.
#5. W punkcie 3. użytkownik podał nazwę ulicy, której nie ma w bazie. System
wyświetla komunikat informujący o charakterze błędu.
#6. System nie może połączyć się z bazą danych. Wyświetlony zostaje komunikat o
braku połączenia.
#7. W przypadku gdy użytkownik nie zaznaczy opcji "Aktualizacja" wykonany
zostanie przypadek użycia UC3.3.
Przypadek użycia: 4.1 Otwarcie strony pomocy
Aktorzy: Użytkownik
Warunki wstępne: System jest dostępny.
Oczekiwane wyniki: Wyświetlona zostanie strona pomocy.
Przepływ podstawowy:
1. Użytkownik wybiera w menu strony opcję "Pomoc"
2. Wyświetlona zostaje strona pomocy.
Przepływy alternatywne:
Brak.
29
5. Założenia projektowe
5.1. Wymagane funkcje systemu
Projektowany system ma posiadać takie funkcje jak:
Przeglądanie listy wszystkich dokumentacji
Ma to być prezentacja w tabeli wybranych informacji o wszystkich dokumentacjach, z
możliwością sortowania według kolumn i stronicowaniem. Możliwe ma być także wybranie
jednej dokumentacji z listy i przejrzenie strony danych szczegółowych.
Wyświetlanie dokumentacji wykonanych w określonym roku bądź przedziale lat
Jako dodatkowa funkcja strony wyświetlającej listę wszystkich wpisów w archiwum
ma być możliwość wyświetlania dokumentacji z konkretnego roku bądź lat. W przypadku
braku dokumentacji z określonych lat system powinien poinformować o braku danych do
wyświetlenia.
Możliwość przeszukiwania archiwum
Wyszukiwarka ma umożliwiać wyszukiwanie dokumentacji pod kątem numeru id,
daty utworzenia, miasta bądź ulicy. Dodatkowo także możliwe musi być wyszukiwanie na
podstawie dowolnych kombinacji powyższych kryteriów. Wyniki zapytań zwrócone mają być
jako dane w tabeli z możliwością sortowania według kolumn i ze stronicowaniem. W
przypadku braku dokumentacji spełniających określone kryteria system powinien
poinformować o braku danych do wyświetlenia. Możliwe ma być także wybranie jednej
dokumentacji z listy i przejrzenie strony szczegółów.
Wyświetlanie strony danych szczegółowych
System ma posiadać możliwość prezentacji szczegółów dokumentacji na specjalnie do
tego przeznaczonej stronie. Możliwe ma być też bezpośrednie przejście ze strony szczegółów
do strony edycji (patrz dalej).
Dodawanie nowych rekordów do bazy danych
System ma umożliwiać dodawanie nowych danych do archiwum. Podczas tego
30
procesu dane wprowadzane przez użytkownika mają być sprawdzane pod kątem ich
poprawności.
Edycja rekordów wpisanych wcześniej
Użytkownicy mają mieć możliwość edycji wpisanych już danych, w celu nanoszenia
poprawek. Podczas edycji dane wprowadzane przez użytkownika mają być sprawdzane pod
kątem ich poprawności.
Prezentacja danych szczegółowych na stronie przeznaczonej do wydruku
System ma mieć możliwość prezentacji danych szczegółowych wyłącznie nas
interesujących na specjalnej stronie do wydruku (bez grafiki, menu bądź stopki).
5.2. Wymogi pozafunkcyjne
Poza wymogami dotyczącymi funkcjonalności system powinien spełniać takie cechy
jak:
Realizacja wszystkich funkcji wymaganych przez firmę
Projektowany system musi posiadać wszystkie wymagane przez firmę funkcje. Ich
lista oraz dokładny opis znajdują się w podrozdziale 3.2.
Pełna dostępność w godzinach pracy biura
Zalecana jest praktycznie nieprzerwana dostępność systemu w godzinach pracy.
Wszelkie aktualizacje, usługi serwisowe, bądź konserwacyjne serwera, na którym będzie
zainstalowany system (tzn. aplikacja internetowa oraz baza danych), będą przeprowadzane po
zamknięciu biura.
Stabilność pracy
Wymóg stabilności stawiany jest każdemu tworzonemu oprogramowaniu. Oznacza to
między innymi, że aplikacja nie powinna zawierać żadnych błędów w kodzie, w zgodności
zapytań SQL z konstrukcją bazy danych oraz innych.
Odporność na błędy użytkownika
Innym rodzajem błędu w konstrukcji oprogramowania jest brak zabezpieczenia
31
aplikacji, przed pojawieniem się niepoprawnych danych wejściowych (czyli tych
wprowadzanych np. przez użytkownika). Przykład: napisanie aplikacji typu kalkulator,
umożliwiającej wpisanie słowa zamiast liczby, spowoduje błąd podczas próby zapisu
podanego słowa do zmiennej typu liczbowego. Rezultatem będzie błąd aplikacji.
Przejrzystość i jasność obsługi. Jednoznaczność elementów interfejsu
użytkownika
Istotną cechą jest wygląd aplikacji. Przejrzystość stron internetowych ułatwia
korzystanie z nich. Ułatwia pracę użytkownikom i przeglądanie przez nich danych. Jasność
obsługi to kolejna ważna cecha mająca wpływ na korzystanie z systemu. Brak zwrócenia na
etapie projektowym odpowiedniej uwagi na te aspekty powoduje utrudnione użytkowanie.
Aplikacja powinna być tak zaprojektowana aby użytkownicy nie mieli problemów w
korzystaniu z niej.
Zabezpieczenie przed niepowołanym dostępem. Bezpieczeństwo danych
Istotnym punktem jest także bezpieczeństwo przechowywanych danych. Mowa tu
zarówno o ochronie przed niepowołanym dostępem jak i przed utratą danych na skutek
uszkodzeń sprzętu (np. dysku twardego, na którym zainstalowana jest baza danych).
Ochrona przed niepowołanym dostępem będzie zrealizowana poprzez funkcję
logowania. Funkcja ta nie jest krytyczna, ponieważ aplikacja będzie działała wyłącznie w
intranecie i nie będzie dostępna na zewnątrz firmy.
Zabezpieczenie przed utratą danych wskutek awarii będzie możliwe dzięki funkcji
automatycznych kopii zapasowych całej zawartości bazy danych.
Łatwość aktualizacji i konserwacji
Aplikacja ma być łatwa w rozbudowie i konserwacji i ma być zarządzana centralnie.
Aplikacją spełniająca te warunki jest aplikacja internetowa, interaktywna strona www
instalowana na serwerze, dynamicznie zmieniająca się w zależności od działań użytkownika.
Aplikacje tego typu są wyświetlane w oknie przeglądarki. W przeciwieństwie do aplikacji
okienkowych, działają niezależnie od platformy systemowej zainstalowanej na komputerze
użytkownika. Zmiany w aplikacji są dokonywane na serwerze, co ma momentalny wpływ na
wszystkich użytkowników - nie trzeba rozprowadzać nowej wersji programu.
32
5.3. Prawa użytkowników
Prawa dostępu zależeć będą od tego, jaki użytkownik się zaloguje. Poniżej
przedstawiono prawa poszczególnych użytkowników:
Użytkownicy anonimowi (niezalogowani)
Nie mają prawie żadnych uprawnień. Oprócz strony logowania system pozwoli im
wejść tylko na stronę pomocy.
Użytkownicy ograniczeni
Będą mogli jedynie przeglądać zawartość archiwum, przeszukiwać itp. Mogą
wykonywać wszystkie operacje związane z odczytem danych. Nie mogą natomiast
dokonywać jakiejkolwiek edycji. Nie mogą również wejść na żadną stronę edycyjną.
Administratorzy
Mają pełne uprawnienia do korzystania z wszystkich funkcji systemu. Użytkownicy
należący do tej grupy będą pilnowani przed podaniem niepoprawnych danych (podrozdział
3.5).
5.4. Logowanie
Korzystanie z systemu wymaga zalogowania. Niezalogowany użytkownik nie będzie
mógł zrobić w systemie niczego, poza podjęciem próby zalogowania się, bądź przejrzeniem
pliku pomocy (w którym zawarte będą również informacje na temat problemów przy
logowaniu i co należy zrobić jak się takowe pojawią).
Strona logowania będzie wymagała podania nazwy użytkownika i hasła. Po podaniu
tych danych użytkownik zostanie przeniesiony na stronę główną, z której będzie miał dostęp
do wszystkich funkcji, z których mogą korzystać użytkownicy danej grupy. W przypadku
nieudanego zalogowania system wyświetli odpowiedni komunikat.
Zalogowany użytkownik zostanie automatycznie wylogowany po krótkim czasie
braku aktywności.
33
5.5. Bezpieczeństwo
Stopień bezpieczeństwa planowanej aplikacji zależeć będzie od takich kwestii jak:
Odporność systemu na błędy użytkownika
Błędy polegające na podawaniu niepoprawnych danych wejściowych mogą mieć
poważne konsekwencje. Wszystkie pola tekstowe, w które użytkownik może wpisać dowolne
dane, muszą być zabezpieczone. Zawartość pól przeznaczonych do wpisania danych
liczbowych powinna być sprawdzona czy jest typu liczbowego. Jeżeli nie to program będzie
przechodził do odpowiedniego działania (np. wyświetlał odpowiedni komunikat). Pola
przeznaczone do wczytywania danych powinny być zabezpieczone przed podaniem zbyt
długiego ciągu znaków (co spowodowało by błąd aplikacji).
Konsekwencje niezabezpieczenia aplikacji pod tym kątem nie będą jednak takie
poważne, jak brak zabezpieczeń przed wstrzyknieciem kodu SQL (SQL Injection). Metoda ta
polega na wpisaniu procedury SQL do pola tekstowego oczekującego danych, które zostaną
zapisane w bazie. Korzystając z tej techniki można dokonać poważnych zniszczeń w bazie
danych i narazić firmę na poważne koszty.
Zabezpieczenie przed niepowołanym dostępem
Zabezpieczenie systemu hasłem ma większy sens tylko wtedy, gdy serwer jest dobrze
zabezpieczony fizycznie. Aplikacja zainstalowana na wolnostojącym serwerze nigdy nie
będzie bezpieczna (niezależnie od ilości haseł). Serwer trzymany pod kluczem i system
logowania w celu skorzystania z aplikacji to dobre zabezpieczenie przed niepowołanym
dostępem.
Kopie zapasowe danych krytycznych
Nawet najlepiej zabezpieczony system nie będzie zapewniał swoim danym
bezpieczeństwa bez odpowiednio częstych kopii zapasowych. Należy zabezpieczyć się przed
możliwą awaria sprzętu, przez którą wszystkie dane mogą zostać utracone.
Tworzenie kopii bezpieczeństwa jest często pomijane, nie tylko w domu ale i w
małych, bądź średnich firmach (głównie tych nie posiadających administratora, który trzyma
pieczę nad wszystkimi komputerami), co czasem prowadzi do utraty ważnych danych.
Planowany system będzie tworzył kopie zapasowe codziennie.
34
6. Wybór i prezentacja technologii
6.1. Technologie wykorzystane w procesie realizacji
Projekt zrealizowany w ramach omawianej pracy dyplomowej będzie aplikacją
internetową napisaną z wykorzystaniem technologii Microsoftu ASP.NET 3.5. Technologia
ASP.NET działa w oparciu o wiele języków programowania, ale dwoma głównymi są tutaj:
Visual Basic oraz C#. Użyty zostanie język C#.
Baza danych zostanie zrealizowana za pomocą technologii Microsoft SQL Server
2005.
6.1.1. ASP.NET 3.5 i C#
ASP.NET jest technologią Microsoftu używaną do tworzenia wydajnych aplikacji
internetowych. Skrót ASP oznacza Active Server Pages, co można przetłumaczyć jako
Aktywne Strony Serwerowe. Aplikacją internetową nazywamy interaktywną, dynamiczną
stronę www. Strona taka jest obsługiwana przez program komputerowy, który wykonywany
jest na serwerze, na którym ta strona jest przechowywana [1].
Działanie aplikacji internetowej znacząco różni się od działania zwykłej, statycznej
strony www, i w dużej mierze przypomina aplikacje okienkowe - z tą różnicą, że aplikacja
internetowa nie posiada własnego okna ale jest oglądana w przeglądarce www [1].
Zaletą aplikacji internetowych jest ich niezależność od platformy systemowej
zainstalowanej na komputerze klienckim. Dodatkowo pojawia się tu fakt scentralizowanego
zarządzania aplikacją - każda zmiana w aplikacji na serwerze ma momentalny wpływ na
wszystkich użytkowników [1].
Zasada działania aplikacji internetowych ASP.NET jest następująca: każda strona
aplikacji internetowej jest przetwarzana przed wysłaniem do przeglądarki końcowego
użytkownika. Funkcjonuje tu następujący schemat:
● przeglądarka użytkownika wysyła do serwera prośbę o wysłanie strony;
● serwer wczytuje stronę do pamięci i przetwarza ją zgodnie z instrukcjami zawartymi
w kodzie i w specjalnych znacznikach;
● generowany jest plik wyjściowy w XHTML'u, nie posiadający już ani kodu
programistycznego ani specjalnych znaczników (tutaj znaczników ASP);
35
● wygenerowany plik XHTML zostaje wysłany do przeglądarki na komputerze
użytkownika [1].
W przypadku zwykłej strony www cały proces jest dużo prostszy:
● przeglądarka użytkownika wysyła do serwera prośbę o wysłanie strony www;
● serwer wysyła pliki strony do przeglądarki na komputerze klienckim [1].
ASP.NET nie jest jedyną technologią tworzenia aplikacji internetowych. Inne
technologie to między innymi: PHP, ASP, JSP, ColdFusion, ESP, Lasso. Jest ich wiele i
prawdopodobnie każda ma swoje mocne i słabe strony. Użyta jednak zostanie technologia
ASP.NET wraz z językiem programowania C#, ponieważ posiada kilka wyjątkowych,
unikalnych cech:
● Umożliwia wykorzystanie ulubionego języka programowania lub języka, który jest do
niego zbliżony. Technologia .NET Framework, w oparciu o którą działa ASP.NET
obsługuje ponad 40 języków programowania i większość z nich może zostać użyta do
tworzenia aplikacji internetowych ASP.NET.
● Strony ASP.NET są kompilowane a nie interpretowane. W PHP za każdym razem gdy
użytkownik wysyła żądanie strony, serwer wczytuje jej kod do pamięci, rozpoznaje
jak go wykonać (zinterpretować) i następnie wykonuje go. W ASP.NET serwer musi
tylko jednorazowo rozpoznać, jak wykonać kod. Kod jest kompilowany do postaci
wydajnych plików binarnych, które mogą być wielokrotnie bardzo szybko
uruchamiane bez narzutu związanego z każdorazowym wczytywaniem strony.
● ASP.NET posiada pełny dostęp do funkcjonalności .NET Framework co daje dostęp
do wielu gotowych do użycia funkcji.
● Możliwe jest oddzielenie kodu wykonywanego po stronie serwera od XHTML.
Pozwala to między innymi na poprawienie przejrzystości kodu projektu.
● ASP.NET ułatwia ponowne wykorzystanie wspólnych elementów interfejsu
użytkownika w wielu stronach internetowych, co umożliwia zachowanie tych
komponentów jako niezależnych kontrolek użytkownika [1, 2].
Utworzenie planowanego systemu pod postacią aplikacji internetowej zapewni łatwe
(centralne) zarządzanie aplikacją zainstalowaną na serwerze. Wiąże się to ze sporymi
udogodnieniami w przypadku aktualizacji oprogramowania - aplikacje wystarczy
aktualizować na serwerze; nie trzeba rozprowadzać użytkownikom nowszej wersji programu.
36
Dzięki takiemu rozwiązaniu mamy stuprocentową pewność, że po dokonaniu aktualizacji,
zmiany wprowadzone w systemie będą miały wpływ na wszystkich użytkowników.
Ponieważ planowany system ma działać w sieci lokalnej, forma aplikacji internetowej
będzie świetnie dopasowana także ze względu na jej wyłącznie sieciowy charakter.
6.1.2. Microsoft SQL Server 2005
Baza danych projektu zostanie zrealizowana w technologii MS SQL Server 2005.
Technologia ta została wybrana, gdyż jest ona bardzo współczesną i jednocześnie dobrze
znaną autorowi technologią. Równocześnie technologia ta jest wspierana przez biblioteki
innej wybranej przeze autora technologii jaką jest wspomniane wcześniej ASP.NET.
Microsoft SQL Server posiada dużo lepsze niż inne technologie bazodanowe wsparcie ze
strony ASP.NET gdyż obie technologie są tej samej firmy [3].
Aplikacja internetowa korzystająca z zasobów bazy danych działa zgodnie z
następującym schematem (Rys. 6.1.):
● przeglądarka użytkownika wysyła do serwera aplikacji prośbę o wysłanie strony;
● serwer aplikacji wczytuje stronę do pamięci i przetwarza ją zgodnie z instrukcjami
zawartymi w kodzie i w specjalnych znacznikach;
● serwer aplikacji wykonuje zapytanie do serwera bazy danych w celu dokonania zmian
w bazie lub pobrania informacji z bazy;
● serwer bazy danych wykonuje polecenia zawarte w zapytaniu serwera aplikacji
(np. wysyła w odpowiedzi określone informacje pobrane z bazy);
● serwer aplikacji podejmuje akcję zależną od odpowiedzi serwera bazy danych
(np. umieszcza otrzymane dane na generowanej stronie www);
● generowany jest plik wyjściowy w XHTML'u, nie posiadający już ani kodu
programistycznego ani specjalnych znaczników (tutaj znaczników ASP);
● wygenerowany plik XHTML zostaje wysłany do przeglądarki na komputerze
użytkownika [1].
37
Rys. 6.1. Schemat współdziałania serwera aplikacji z serwerem bazy danych 1 – zapytanie klienta o stronę www przechowywaną na serwerze aplikacji; 2 – serwer aplikacji podczas przetwarzania strony, o którą poprosił klient wykonuje zapytanie do serwera bazy danych; 3 – serwer bazy danych w odpowiedzi na zapytanie odsyła serwerowi aplikacji dane, o które poprosił; 4 – serwer aplikacji odsyła wygenerowaną stronę www do klienta [P. Traczyński].
6.2. Wywiad z szefem firmy Meant4.pl
Poniżej zamieszczono wywiad z przedstawicielem firmy zajmującej się tworzeniem
aplikacji internetowych. Wywiad ten został przeprowadzony po określeniu formy
projektowanego systemu jako aplikacji internetowej.
Paweł Traczyński: Ile osób liczy Państwa zespół projektowy?
Szef firmy Meant4: 4 osoby.
38
Czy mieli Państwo kiedykolwiek problem, który spowodował, że nie ukończyli
Państwo projektu, i jeżeli tak, to czy mogą Państwo go przedstawić?
Problemy natury ludzkiej, nigdy technicznej, były to generalnie mówiąc problemy z
harmonogramem i dostarczaniem materiałów czy akceptacją etapów wynikających ze złej
organizacji zespołu firmy zamawiającej.
Który z etapów projektu zajmuje najwięcej czasu?
Jest to zależne od typu projektu, nie ma generalnej odpowiedzi na to generalne
pytanie, należałoby analizować poszczególne projekty.
Ok. Powiedzmy na przykładzie Państwa trzech ulubionych prac?
Pkp.pl - ustalenie architektury informacji.
Yachting.com.pl - łączenie technologii gps->gsm->internet->flash i test urządzeń, jak
również ustalenie optymalnej ilości informacji, które są niezbędne do działania systemu.
Body-philosophy.net - opracowanie długoterminowej strategii rozwoju serwisu.
Jakich technologii używają Państwo przy tworzeniu swoich projektów?
Technologii ogólnie dostępnych na rynku. PHP/MySQL jest dominantą w naszym
przypadku, dalszy dobór technologii jest oparty o specyfikacje danego projektu.
Jak często muszą Państwo uaktualniać (pod względem technologicznym) wykonane
przez siebie strony?
Średnio raz do roku dokonujemy zbiorczej aktualizacji platformy i tu również nie ma
reguły. Biorąc pod uwagę klienta typu PKP S.A. uaktualnienia są dokonywane na bieżąco. W
przypadku kiedy mamy do czynienia z małym klientem, którego strona jest odwiedzana przez
małą ilość użytkowników, te uaktualnienia są dokonywane raz do roku.
Co Państwo sądzą o technologiach ASP.NET i SQL Server?
Nie używamy technologii Microsoft-u z powodu polityki naszej firmy i jej
infrastruktury serwerowej, dlatego nie chciałbym prezentować swojej prywatnej opinii, jak
również zalet i wad danej technologii nie używając jej w życiu codziennym firmy.
Jakie błędy są według Państwa najczęściej popełniane przez webmasterów?
Brak znajomości technologii i nie używanie dostępnych rozwiązań.
39
Czy są jakieś metody / elementy / techniki tworzenia stron www, których według
Państwa należy unikać?
Jest to temat na cykl wykładów.
Może jest mimo wszystko kilka rzeczy, które jako pierwsze przychodzą Państwu do
głowy?
Używanie tagów iframe w serwisie, brak rozgraniczenia między warstwą prezentacji a
warstwą logiki.
Niestety odpowiedzi przedstawiciela firmy Meant4.pl nie były wyczerpujące i nie
przyniosły specjalnych korzyści podczas pisania pracy. Motywowały one jednak do
wykonania systemu w taki sposób aby:
● jak najlepiej wykorzystać dostępne technologie;
● dobrze rozgraniczyć warstwę prezentacji od warstwy logiki.
40
7. Projekt
7.1. Wybór nazwy
Projektowany system będzie służył do zarządzania archiwum. Do archiwum trafiają
jedynie te dokumentacje, nad którymi prace zostały ukończone. Oznacza to, że w archiwum
znajdują się tylko w pełni wykonane, sfinalizowane projekty.
Powyższy tok rozumowania podsunął pomysł na nazwę dla systemu. Ostatecznie
ustalono, że będzie to "WellDone", co można przetłumaczyć jako "Dobrze wykonane (od
początku do końca)". Nazwa kojarzyć się może z myślą, o dobrze zrealizowanych przez firmę
projektach.
-----
Występują dwa podobne zwroty w języku angielskim: "well done" oraz "done well".
Zwrotu well done używa się, kiedy chce się zawiadomić o zakończeniu jakiejś czynności z
sukcesem. Done well określa zaś, że coś jest dobrze wykonane.
Przykład:
- How is it going? (Jak idzie?)
-Well done! (Właśnie pomyślnie zakończyłem!)
- I see you've done well. (Widze, że dobrze ci poszło.)
7.2. Projekt bazy danych
7.2.1. Przechowywane dane
Jak opisano wcześniej, system WellDone służy do przechowywania w bazie danych
wybranych informacji i szczegółów każdej dokumentacji. Są to jedynie wybrane informacje -
te które najczęściej są potrzebne i według których dokonuje się wyszukiwań. Konieczne było
określenie zakresu danych przechowywanych przez system.
41
Rekord dotyczący każdej dokumentacji będzie mieścił następujące dane:
Dane ogólne
ID Dokumentacji - jest to numer dokumentacji nadawany przez firmę, przypisywany
jest rosnąco kolejnym dokumentacjom, które są opracowywane. Numer dokumentacji określa
ją jednoznacznie.
Data wykonania - określa dzień, miesiąc i rok sporządzenia dokumentacji.
Typ dokumentacji - dokumentacje mogą być różnego typu. Najczęstszym typem jest
dokumentacja geotechniczna, opisująca warunki wodno-gruntowe panujące na badanym
terenie. Wstępna dokumentacja geotechniczna opisuje budowę geologiczna z mniejszą
dokładnością, na podstawie jedynie kilku punktów badawczych. Dokumentacja geologiczno-
inżynierska (oznaczona w systemie jako geologiczna) sporządzana jest dla skomplikowanych
inwestycji budowlanych. Dokumentacja ta wykonywana jest na podstawie Projektu Prac
Geologicznych zatwierdzonego przez stosowne urzędy (w przypadku Warszawy Projekt
zatwierdza Wydział Ochrony Środowiska Urzędu Stołecznego Miasta Warszawy). Oddzielne
opracowania opisują stan czystości środowiska. W systemie zostały one oznaczone jako
'zanieczyszczenia'. Pozostałe opracowania występują w grupie 'inne'.
Dane adresowe
Strefa - umowne strefy ułatwiają szybkie odnajdywanie wszystkich dokumentacji z
prac np. wykonanych wyłącznie w okolicach Warszawy ale już nie w samym mieście.
Strefy są następujące:
war - strefa warszawska. Obejmuje wszystkie dokumentacje wykonane na terenie
Warszawy;
oko - okolice Warszawy;
pol - prace na terenie Polski ale nie w Warszawie ani w jej okolicach;
zag - prace zagraniczne.
Ulica - nazwa ulicy, przy której prowadzone były prace.
42
Miejscowość - nazwa miejscowości, w której były wykonywane prace.
Informacje dodatkowe - jakiekolwiek inne informacje związane z położeniem badanej
działki, dojazdem itp.
Dane geotechniczne
Ilość otworów - ilość odwiertów badawczych wykonach podczas prac terenowych
(ewentualnie ilość punktów w których wykonano sondowania).
Maksymalna głębokość badań – głębokość, do której wykonano rozpoznanie podłoża
gruntowego.
Geologia - dane charakteryzujące geologiczne pochodzenie terenu badań (tereny
akumulacji rzecznej, grunty pochodzenia lodowcowego, itp.)
Agresywność - określa agresywność wody gruntowej względem betonu i żelbetu.
Badania specjalistyczne - badania wykonywane w przypadku skomplikowanej
budowy geologicznej.
Poziom występowania wody gruntowej - głębokość zalegania zwierciadeł wody
podziemnej.
Profil - opisuje budowę geologiczną w profilu pionowym z zaznaczeniem wszystkich
warstw geologicznych.
Uwagi
Hasło – słowo, które może np. łączyć ze sobą jakąś grupę prac zleconych przez
jednego inwestora.
43
7.2.2. Wybrana technologia
Baza danych będzie utworzona w technologii Microsoft SQL Server 2005, ponieważ
języki ASP.NET oraz C#, za pomocą których napisana będzie aplikacja internetowa
WellDone najlepiej współdziałają właśnie z tym systemem bazodanowym. Innym atutem
skorzystania z technologii Microsoftu jest możliwość użycia rozbudowanego języka T-SQL,
który jest wygodniejszy w użyciu niż tradycyjny SQL [3].
Baza danych zostanie zainstalowana na serwerze Microsft SQL Server 2005 Express
Edition. Współpracuje on z narzędziem SQL Server Management Studio Express Edition,
które umożliwia szybkie i wygodne zarządzanie bazą danych w tym np. łatwe ustawianie
automatycznych backup'ów. Serwer bazodanowy w wersji Express Edtion posiada
ograniczenie objętościowe bazy danych do 4GB, jednak nie stanowi to problemu, gdyż
informacje umieszczane w bazie systemu WellDone nieprędko będą potrzebowały więcej
miejsca (mowa tu o co najmniej kilkunastu latach) [3].
7.2.3. Tabele
W bazie danych znajdują się wymienione poniżej tabele:
Agresywnosc - tabela przechowująca wartości określające agresywność wody
gruntowej (tak/nie);
BadaniaSpecjalistyczne - tabela przechowuje wartości określające czy badania były
specjalistyczne (tak/nie).
Wpisy w powyższych dwóch tabelach maja charakter binarny (prawda / fałsz) jednak
jako typ danych wybrano NVarChar czyli typ znakowy. Umożliwi to łatwe dodanie w
przyszłości innych możliwych wartości (na przykład: tak/nie/nieokreślono), czego nie można
osiągnąć używając typu Bit. Ponadto taka realizacja nie wymaga wykonywania konwersji
danych przy ich prezentacji na stronie www (nie trzeba zamieniać '0' na 'nie' ani '1' na 'tak').
Dokumentacje - tabela ta przechowuje informacje o dokumentacji;
Miejscowosci – tabela przechowuje nazwy miejscowości, w których chociaż raz były
wykonywane badania;
Strefy – tabela przechowuje nazwy stref;
44
Typy – tabela przechowuje nazwy typów dokumentacji;
Ulice – tabela przechowuje nazwy ulic, przy których były wykonywane badania.
7.2.4. Właściwości tabel
Tabela Agresywnosc posiada następujące kolumny (Rys. 7.1., 7.2.):
IDAgresywnosci - każdy wpis w tej tabeli posiada swój unikalny numer przydzielany
automatycznie.
Typ danych: int
Dane w tej kolumnie są wymagane, niedozwolona jest wartość NULL.
Agresywnosc - wpis w tej kolumnie określa rodzaj agresywności wody gruntowej.
Aktualnie są to wartości: 'tak' - woda agresywna, bądź 'nie' - woda nieagresywna.
Typ danych: nvarchar(50)
Dane w tej kolumnie są wymagane, niedozwolona jest wartość NULL.
Rys. 7.1. Projekt tabeli Agresywnosc [P. Traczyński].
Rys. 7.2. Zawartość tabeli Agresywnosc [P. Traczyński].
Tabela BadaniaSpecjalistyczne posiada następujące kolumny (Rys. 7.3., 7.4):
IDBadanSpec - każdy wpis w tej tabeli posiada swój unikalny numer przydzielany automatycznie.
Typ danych: intDane w tej kolumnie są wymagane, niedozwolona jest wartość NULL.
45
BadaniaSpec - wpis w tej kolumnie określa rodzaj badan specjalistycznych. Aktualnie
są to wartości: 'tak' - badania były specjalistyczne, bądź 'nie' - badania nie były
specjalistyczne.
Typ danych: nvarchar(50)
Dane w tej kolumnie są wymagane, niedozwolona jest wartość NULL.
Rys. 7.3. Projekt tabeli BadaniaSpecjalistyczne [P. Traczyński].
Rys. 7.4. Zawartość tabeli BadaniaSpecjalistyczne [P. Traczyński].
Tabela Dokumentacje posiada następujące kolumny (Rys. 7.5.):
IDDokumentacji - każdy wpis w tej tabeli posiada swój unikalny numer przydzielany
automatycznie. Numer ten jest jednocześnie numerem dokumentacji, dzięki któremu można
zawsze łatwo odszukać dowolną prace (jeżeli zna się jej id) zarówno w komputerze, jak i na
półce w archiwum.
Typ danych: int
Dane w tej kolumnie są wymagane, niedozwolona jest wartość NULL.
IDTypu - wpis w tej kolumnie umożliwia skojarzenie danego rekordu z jednym
wpisem w tabeli Typy.
Typ danych: int
Dane w tej kolumnie są wymagane, niedozwolona jest wartość NULL.
46
Data - określa moment złożenia gotowej dokumentacji.
Typ danych: datetime
Dane w tej kolumnie są wymagane, niedozwolona jest wartość NULL.
IDStrefy - wpis w tej kolumnie umożliwia skojarzenie danego rekordu z jednym
wpisem w tabeli Strefy.
Typ danych: int
Dane w tej kolumnie są wymagane, niedozwolona jest wartość NULL.
IDMiejscowosci - każdy wpis w tej tabeli musi być skojarzony z jedną z miejscowości
z tabeli Miejscowosci.
Typ danych: int
Dane w tej kolumnie są wymagane, niedozwolona jest wartość NULL.
IDUlicy - każdy wpis w tej tabeli musi być skojarzony z jedną z ulic z tabeli Ulice.
Typ danych: int
Dane w tej kolumnie są wymagane, niedozwolona jest wartość NULL.
AdresDodatkowe - pole to przechowuje ewentualne dodatkowe dane adresowe, bądź
związane z dojazdem.
Typ danych: nvarchar(50)
Kolumna może być pusta, dozwolona jest wartość NULL.
IloscOtworow - pole to przechowuje informację o ilości wykonanych otworów
badawczych bądź sondowań.
Typ danych: int
Kolumna może być pusta, dozwolona jest wartość NULL.
47
MaksGlebokosc - pole to przechowuje dane o głębokości, do której wykonano
badania gruntu.
Typ danych: float (ponieważ głębokość podaje się z ułamkiem, np. "2.30" m)
Kolumna może być pusta, dozwolona jest wartość NULL.
Geologia - pole to przechowuje dane o geologii gruntów na terenie badań.
Typ danych: nvarchar(50)
Kolumna może być pusta, dozwolona jest wartość NULL
IDAgresywnoci - wpis w tej kolumnie umożliwia skojarzenie danego rekordu z
jednym wpisem w tabeli Agresywsnosc.
Typ danych: int
Dane w tej kolumnie są wymagane, niedozwolona jest wartość NULL.
IDBadaniaSpec - wpis w tej kolumnie umożliwia skojarzenie danego rekordu z
jednym wpisem w tabeli BadaniaSpecjalistyczne.
Typ danych: int
Dane w tej kolumnie są wymagane, niedozwolona jest wartość NULL.
WodaNa1 - wpis w tej kolumnie określa poziom, na którym występuje woda
gruntowa.
Typ danych: nvarchar(50) - potrzebna możliwość wpisywania tekstu
Dane w tej kolumnie są wymagane, niedozwolona jest wartość NULL.
WodaNa2 - wpis w tej kolumnie określa poziom, na którym występuje woda
gruntowa. Dane należy podać wtedy, gdy na badanej działce woda wystąpiła na rożnych
głębokościach. Jeżeli była wszędzie na podobnej - wynik powinien znaleźć się w kolumnie
WodaNa1.
48
Typ danych: nvarchar(50) - potrzebna możliwość wpisywania tekstu
Kolumna może być pusta, dozwolona jest wartość NULL.
Profil1 - wpis w tej kolumnie określa, jaki był profil geotechniczny gruntów na
zbadanej działce.
Typ danych: nvarchar(200)
Dane w tej kolumnie są wymagane, niedozwolona jest wartość NULL.
Profil2 - wpis w tej kolumnie określa jaki był profil geotechniczny gruntów na
zbadanej działce. Dane należy podać wtedy gdy na badanej działce w różnych punktach
badania dawały różne wyniki. W przeciwnym wypadku kolumna ta powinna pozostać pusta.
Typ danych: nvarchar(200)
Kolumna może być pusta, dozwolona jest wartość NULL.
Rys. 7.5. Projekt tabeli Dokumentacje [P. Traczyński].
49
Uwagi - kolumna ta to miejsce na wszelkie inne informacje o charakterze ogólnym.
Typ danych: nvarchar(100)
Kolumna może być pusta, dozwolona jest wartość NULL.
Haslo - kolumna ta przechowuje hasło, czyli słowo które może np. łączyć ze sobą
jakąś grupę prac zleconych przez jednego inwestora.
Typ danych: nvarchar(100)
Kolumna może być pusta, dozwolona jest wartość NULL.
Tabela Miejscowosci posiada nastepujące kolumny (Rys. 7.6.):
IDMiejscowosci - każdy wpis w tej tabeli posiada swój unikalny numer przydzielany
automatycznie.
Typ danych: int
Dane w tej kolumnie są wymagane, niedozwolona jest wartość NULL.
Miejscowosc - wpis w tej kolumnie określa nazwę miejscowości. Zawartość tej tabeli
może być modyfikowana z poziomu aplikacji internetowej.
Typ danych: nvarchar(50)
Dane w tej kolumnie są wymagane, niedozwolona jest wartość NULL.
Rys. 7.6. Projekt tabeli Miejscowosci [P. Traczyński].
Tabela Strefy posiada następujące kolumny (Rys. 7.7., 7.8.):
IDStrefy - każdy wpis w tej tabeli posiada swój unikalny numer przydzielany
automatycznie.
50
Typ danych: int
Dane w tej kolumnie są wymagane, niedozwolona jest wartość NULL.
Strefa - wpis w tej kolumnie określa nazwę strefy. Aktualnie są to wartości: war, oko,
pol oraz zag. Ich znaczenia zostały opisane w punkcie 4.1.
Typ danych: nvarchar(50)
Dane w tej kolumnie są wymagane, niedozwolona jest wartość NULL.
Rys. 7.7. Projekt tabeli Strefy [P. Traczyński].
Rys. 7.8. Zawartość tabeli Strefy [P. Traczyński].
Tabela Typy posiada następujące kolumny (Rys. 7.9., 7.10.):
IDTypu - każdy wpis w tej tabeli posiada swój unikalny numer przydzielany automatycznie.
Typ danych: intDane w tej kolumnie są wymagane, niedozwolona jest wartość NULL.
Typ - wpis w tej kolumnie określa rodzaj typu dokumentacji. Aktualnie są to wartości:
geotechniczna, wstępna, geologiczna, zanieczyszczenia oraz inna.
Typ danych: nvarchar(50)
Dane w tej kolumnie są wymagane, niedozwolona jest wartość NULL.
51
Rys. 7.9. Projekt tabeli Typy [P. Traczyński].
Rys. 7.10. Zawartość tabeli Typy [P. Traczyński].
Tabela Ulice posiada następujące kolumny (Rys. 7.11.):
IDUlicy - każdy wpis w tej tabeli posiada swój unikalny numer przydzielany automatycznie.
Typ danych: intDane w tej kolumnie są wymagane, niedozwolona jest wartość NULL.
Ulica - wpis w tej kolumnie określa nazwę ulicy. Zawartość tej tabeli może być
modyfikowana z poziomu aplikacji internetowej.
Typ danych: nvarchar(50)
Dane w tej kolumnie są wymagane, niedozwolona jest wartość NULL.
Rys. 7.11. Projekt tabeli Ulice [P. Traczyński].
7.2.5. Relacje
Tabele w bazie są połączone relacjami i tworzą pewną integralną strukturę. Określenie
integralność oznacza, że występuje integralność encji (czyli wartość klucza głównego nie
52
może mieć wartości pustej, tzw. null) oraz integralność odwołań (czyli nie mogą istnieć
niedopasowane wartości klucza obcego). Mianem encji czyli bytu w informatyce określa się
np. elementy składające się na projektowany system. Problematyka ta zostanie wyjaśniona na
przykładzie diagramu relacji określanego również często diagramem encji (Rys. 7.12).
Rys. 7.12. Diagram encji (wszystkie elementy bazy danych) [P. Traczyński].
Integralność encji - wartości kluczy głównych nie mogą być puste (null). Np.
niedopuszczalne jest aby w tabeli Strefy pojawił się rekord bez podanego IDStrefy.
Integralność odwołań - w tabeli głównej (Dokumentacje) znajdują się odwołania do
zawartości innych tabel. Np. tabela ta nie przechowuje nazwy typu dokumentacji - nazwa ta
przechowywana jest w odpowiednim rekordzie tabeli Typy, a w tabeli Dokumentacje
przechowywane jest jedynie odwołanie do tego rekordu. Chcąc zapisać, że dokumentacja jest
typu "Geologiczna" zapiszemy w tabeli Dokumentacje w kolumnie IDTypu wartość '3' - bo
właśnie takie id ma ten typ w tabeli Typów.
53
Szczegółowe omówienie relacji
Rys. 7.13. Diagram relacji pomiędzy tabelami Dokumentacje i Agresywnosc [P. Traczyński].
Tabele Dokumentacje i Agresywnosc są połączone relacją poprzez IDAgresywnosci
(w tabeli Agresywnosc jest to klucz główny, natomiast dla tabeli Dokumentacje jest to klucz
obcy) (Rys. 7.13). Wynika to z faktu, że każdy rekord dokumentacji musi zawierać
informacje o agresywności wody gruntowej. Informacja ta powtarza się wielokrotnie w
identycznej formie dla różnych dokumentacji. Aby zmniejszyć objętość bazy danych i ułatwić
wprowadzanie ewentualnych poprawek informacje o agresywności będą przechowywane w
oddzielnej tabeli. Każdy wpis będzie posiadał własne id, a w tabeli Dokumentacje
umieszczony zostanie jedynie numer IDAgresywnosci będący kluczem obcym (łączącym z
odpowiednim wpisem z tabeli Agresywnosc).
54
Rys. 7.14. Diagram relacji pomiędzy tabelami Dokumentacje i BadaniaSpecjalistyczne [P. Traczyński].
Tabele Dokumentacje i BadaniaSpecjalistyczne są połączone relacją poprzez
IDBadaniaSpec (w tabeli BadaniaSpecjalistyczne jest to klucz główny, natomiast dla tabeli
Dokumentacje jest to klucz obcy) (Rys. 7.14.). Wynika to z faktu, że każdy rekord
dokumentacji musi zawierać informacje związane z badaniami specjalistycznymi. Informacja
ta powtarza się wielokrotnie w identycznej formie dla różnych dokumentacji. Aby zmniejszyć
objętość bazy danych i ułatwić wprowadzanie ewentualnych poprawek informacje o
agresywności będą przechowywane w oddzielnej tabeli. Każdy wpis będzie posiadał własne
id, a w tabeli Dokumentacje umieszczony zostanie jedynie numer IDBadaniaSpec będący
kluczem obcym (łączącym z odpowiednim wpisem z tabeli BadaniaSpecjalistyczne).
55
Rys. 7.15. Diagram relacji pomiędzy tabelami Dokumentacje i Miejscowosci [P. Traczyński].
Tabele Dokumentacje i Miejscowosci są połączone relacją poprzez IDMiejscowosci
(w tabeli Miejscowosci jest to klucz główny, natomiast dla tabeli Dokumentacje jest to klucz
obcy) (Rys. 7.15.). Wynika to z faktu, że każdy rekord dokumentacji musi zawierać
informacje o nazwie miejscowości. Informacja ta powtarza się wielokrotnie w identycznej
formie dla różnych dokumentacji. Aby zmniejszyć objętość bazy danych i ułatwić
wprowadzanie ewentualnych poprawek, nazwy miejscowości będą przechowywane w
oddzielnej tabeli. Każdy wpis będzie posiadał własne id, a w tabeli Dokumentacje
umieszczony zostanie jedynie numer IDMiejscowosci będący kluczem obcym (łączącym z
odpowiednim wpisem z tabeli Miejscowosci).
56
Rys. 7.16. Diagram relacji pomiędzy tabelami Dokumentacje i Strefy [P. Traczyński].
Tabele Dokumentacje i Strefy są połączone relacją poprzez IDStrefy (w tabeli Strefy
jest to klucz główny, natomiast dla tabeli Dokumentacje jest to klucz obcy) (Rys. 7.16.).
Wynika to z faktu, że każdy rekord dokumentacji musi zawierać informacje o strefie.
Informacja ta powtarza się wielokrotnie w identycznej formie dla różnych dokumentacji. Aby
zmniejszyć objętość bazy danych i ułatwić wprowadzanie ewentualnych poprawek informacje
o strefie będą przechowywane w oddzielnej tabeli. Każdy wpis będzie posiadał własne id, a w
tabeli Dokumentacje umieszczony zostanie jedynie numer IDStrefy będący kluczem obcym
(łączącym z odpowiednim wpisem z tabeli Strefy).
57
Rys. 7.17. Diagram relacji pomiędzy tabelami Dokumentacje i Typy
[P. Traczyński].
Tabele Dokumentacje i Typy są połączone relacją poprzez IDTypu (w tabeli Typy jest
to klucz główny, natomiast dla tabeli Dokumentacje jest to klucz obcy) (Rys. 7.17). Wynika
to z faktu, że każdy rekord dokumentacji musi zawierać informacje o typie. Informacja ta
powtarza się wielokrotnie w identycznej formie dla różnych dokumentacji. Aby zmniejszyć
objętość bazy danych i ułatwić wprowadzanie ewentualnych poprawek informacje o typie
będą przechowywane w oddzielnej tabeli. Każdy wpis będzie posiadał własne id, a w tabeli
Dokumentacje umieszczony zostanie jedynie numer IDTypu będący kluczem obcym
(łączącym z odpowiednim wpisem z tabeli Typy).
58
Rys. 7.18. Diagram relacji pomiędzy tabelami Dokumentacje i Ulice
Tabele Dokumentacje i Ulice są połączone relacją poprzez IDUlicy (w tabeli
BadaniaSpecjalistyczne jest to klucz główny, natomiast dla tabeli Dokumentacje jest to klucz
obcy) (Rys. 7.18.). Wynika to z faktu, że każdy rekord dokumentacji musi zawierać
informacje o nazwie ulicy. Informacja ta powtarza się wielokrotnie w identycznej formie dla
różnych dokumentacji. Aby zmniejszyć objętość bazy danych i ułatwić wprowadzanie
ewentualnych poprawek informacje o nazwie ulicy będą przechowywane w oddzielnej tabeli.
Każdy wpis będzie posiadał własne id, a w tabeli Dokumentacje umieszczony zostanie
jedynie numer IDUlicy będący kluczem obcym (łączącym z odpowiednim wpisem z tabeli
Ulice).
59
7.3. Projekt aplikacji
7.3.1. Lista stron
Projektowana aplikacja internetowa będzie składała się z następujących stron www:
● Strona logowania – Login.aspx;
● Strona główna – Default.aspx;
● Strona listy wszystkich dokumentacji – ListAll.aspx;
● Strona wyszukiwania dokumentacji – Search.aspx;
● Strona szczegółów dokumentacji – Details.aspx;
● Strona dodawania dokumentacji – Add.aspx;
● Strona edycji danych dokumentacji – Edit.aspx;
● Strona potwierdzająca poprawne wylogowanie – Logout.aspx;
● Strona Pomocy – Help.aspx.
Ponadto w systemie znajdują dwie strony wyświetlane w wyskakujących okienkach
(pop-up). Są to:
● Strona dodawania/edycji miejscowości – AddLocation.aspx;
● Strona dodawania/edycji ulic – AddStreet.aspx.
Ze względu na ich charakter traktowane są one jako elementy stron edycyjnych
(Strona dodawania dokumentacji, Strona edycji dokumentacji).
7.3.2. Schemat połączeń między stronami
Poniżej przedstawiony jest schemat struktury serwisu (Rys. 7.19.), który ukazuje
drogę narzuconą użytkownikowi przez system podczas wykonywania zadań innych niż
nawigacja. Dokładny opis znajduje się pod schematem.
60
Rys. 7.19. Schemat struktury serwisu [P. Traczyński].
1. Użytkownik w momencie wejścia na stronę serwisu zobaczy stronę logowania
(Login.aspx). Po zalogowaniu się automatycznie wyświetlona zostanie strona główna
(Default.aspx).
2. Ze strony głównej, będącej pewnego rodzaju panelem dostępnych funkcji,
użytkownik może przejść do czterech różnych stron: strony listy wszystkich
dokumentacji (ListAll.aspx), strony wyszukiwania dokumentacji (Search.aspx), strony
dodawania dokumentacji (Add.aspx) bądź strony edycji dokumentacji (Edit.aspx).
3. Strony listy dokumentacji oraz wyszukiwania dokumentacji (ListAll.aspx i
Search.aspx) wyświetlają listy dokumentacji. Można wybrać jedną dokumentację, aby
przenieść się na jej stronę szczegółów (Details.aspx).
Strony dodawania i edycji dokumentacji (Add.aspx i Edit.aspx) umożliwiają
61
wprowadzanie danych w celu zapisania ich w bazie danych. Jako potwierdzenie
poprawnego zapisu, system wyświetla stronę szczegółów (Details.aspx) pokazującą
nowe dane.
4. Ze strony szczegółów dokumentacji można przenieść się bezpośrednio na
stronę edycji dokumentacji (tej samej, której szczegóły były wyświetlone).
5. Zalogowany użytkownik może się wylogować w dowolnej chwili klikając
odpowiedni odnośnik w menu strony. Wylogowaniu towarzysz wyświetlenie strony
"Wylogowano" (Logout.aspx), potwierdzającej operację wylogowania. Ze strony tej
można przejść z powrotem na stronę logowania (Login.aspx).
6. Strona pomocy (Help.aspx) jest dostępna dla wszystkich użytkowników, nie
tylko tych zalogowanych. Wejść na nią można z każdej innej strony serwisu.
Menu wyświetlane na każdej stronie umożliwia szybkie przejście na następujące
strony (przedstawione są nazwy odnośników):
● Strona główna - Strona główna – Default.aspx;
● Lista - Strona listy wszystkich dokumentacji – ListAll.aspx;
● Szukaj - Strona wyszukiwania dokumentacji – Search.aspx;
● Dodaj - Strona dodawania dokumentacji – Add.aspx;
● Edytuj - Strona edycji danych dokumentacji – Edit.aspx;
● Pomoc - Strona Pomocy – Help.aspx;
● Zaloguj/Wyloguj - Strona logowania / Potwierdzająca wylogowanie.
7.3.3. Główne elementy stron
Na każdą stronę aplikacji webowej składają się następujące elementy (Rys. 7.20.):
● Nagłówek (1)
W skład nagłówka wchodzi:
1. Logo i nazwa systemu ("WellDone");
2. Tekst określający do czego służy system ("System zarządzania archiwum
Geotestu");
3. Menu główne.
62
● Ciało strony (2)
Ciało strony jest inne dla każdej podstrony serwisu i zmienia się w zależności od tego,
na jakiej stronie znajduje się użytkownik. W skład ciała strony wchodzi:
1. Nazwa danej strony serwisu;
2. Opis danej strony serwisu;
3. Zawartość indywidualna dla danej strony.
● Stopka (3)
W skład stopki wchodzi:
1. Informacja o wersji systemu;
2. Menu dolne będące kopią Menu górnego.
Rys. 7.20. Układ strony: 1 – nagłówek; 2 - ciało strony; 3 - stopka [P. Traczyński].
63
Strona logowania (Login.aspx) zawiera (Rys. 7.21.):
● Na formularz logowania składają się z następujące elementy:
○ Pole tekstowe "Login";
○ Pole tekstowe "Hasło";
○ Przycisk "Zaloguj".
● Nieoznaczony obszar powiadomień, w którym wyświetlane są ewentualne komunikaty
dla użytkownika.
Rys. 7.21. Strona logowania [P. Traczyński].
Strona główna (Default.aspx) zawiera (Rys. 7.22.):
● Panel z czterema przyciskami (ikonami) umożliwiającymi bezpośrednie przejście do
najczęściej wykorzystywanych stron systemu. Dostępność przycisków panelu zależy
od typu zalogowanego użytkownika.
Strona listy wszystkich dokumentacji (ListAll.aspx) zawiera (Rys. 7.23.):
● Dynamiczną listę wszystkich dokumentacji.
● Panel "Opcji" umożliwiający filtrowanie wyświetlanych dokumentacji. Panel ten
zawiera:
○ Dwa pola tekstowe służące do wpisania przedziału lat;
64
○ Przycisk "Filtruj" umożliwiający włączenie filtrowania według danych podanych
w tych polach.
● Pole "Status" (znajdujące się pod panelem "Opcji"), w którym wyświetlane są
komunikaty dla użytkownika;
● Odnośniki skierowujące na stronę szczegółów dokumentacji znajdujące się przy
każdym rekordzie pokazanym na liście.
Rys. 7.22. Strona główna [P. Traczyński].
Strona wyszukiwania dokumentacji (Search.aspx) zawiera (Rys. 7.24.):
● Panel "Opcji" umożliwiający określenie kryteriów wyszukiwania. Zawiera on:
○ Pole tekstowe "ID Dokumentacji";
○ Pole tekstowe "Miejscowość";
○ Pole tekstowe "Ulica";
○ Dwie listy rozwijane "Data" służące do określenia miesiąca i roku;
○ Pola typu CheckBox umożliwiające zignorowanie wybranych pól kryteriów
wyszukiwań;
○ Przycisk "Szukaj";
○ Przestrzeń w której wyświetlone zostaną wyniki wyszukiwań.
● Pole "Status" (znajdujące się pod panelem "Opcji"), w którym wyświetlane są
65
komunikaty dla użytkownika;
● Odnośniki skierowujące na stronę szczegółów dokumentacji znajdujące się przy
każdym rekordzie pokazanym na liście.
Rys. 7.23. Strona listy wszystkich dokumentacji [P. Traczyński].
Strona szczegółów dokumentacji (Details.aspx) zawiera (Rys. 7.25.):
● Tabelę z dynamicznie tworzoną zawartością, przedstawiającą szczegóły wybranej
dokumentacji;
● Panel "Opcji" umożliwiający wykonanie dodatkowych zadań. Zawiera on elementy:
○ Przycisk "Edytuj", który w przypadku korzystania z systemu przez administratora
umożliwia przejście do strony edycji dokumentacji;
○ Przycisk "Drukuj", który przenosi na stronę szczegółów przygotowaną specjalnie
do wydruku;
○ Pole "Status" wyświetlające ewentualne komunikaty dla użytkownika.
66
Rys. 7.24. Strona wyszukiwania dokumentacji [P. Traczyński].
Strona dodawania dokumentacji (Add.aspx) zawiera (Rys. 7.26.):
● Formularz dodawania dokumentacji składający się z 10 pól tekstowych oraz 9 list
rozwijanych umożliwiających określenie szczegółów dodawanej dokumentacji;
● Panel opcji zawierający następujące elementy:
○ Informację o tym jakie ID będzie miała dodawana dokumentacja;
○ Przycisk "Zapisz" zapisujący nową dokumentację do bazy danych;
○ Przycisk "Miejscowości" otwierający okno edycji nazw miejscowości
przechowywanych w bazie;
○ Przycisk "Ulice" otwierający okna edycji nazw miejscowości przechowywanych w
bazie;
○ Przycisk "Odśwież" służący do przeładowywania zawartości list rozwijanych.
● Pole "Status" (znajdujące się pod panelem "Opcji"), w którym wyświetlane są
komunikaty dla użytkownika;
● Przycisk otwierający okno dodawania / edycji miejscowości (obsługiwany przez plik
AddLocation.aspx);
● Przycisk otwierający okno dodawania / edycji ulic (obsługiwany przez plik
AddStreet.aspx).
67
Rys. 7.25. Strona szczegółów dokumentacji [P. Traczyński].
68
Rys. 7.26. Strona dodawania dokumentacji [P. Traczyński].
69
Strona edycji danych dokumentacji (Edit.aspx) zwiera (Rys. 7.27.):
● Formularz edycji dokumentacji składający się z 10 pól tekstowych oraz 9 list
rozwijanych umożliwiających określenie szczegółów dodawanej dokumentacji;
● Panel opcji zawierający następujące elementy:
○ Pole tekstowe "Podaj ID", w którym należy wpisać ID dokumentacji do
edytowana;
○ Przycisk "Wybierz" uruchamiający wczytywanie danych do formularza;
○ Przycisk "Zapisz" zapisujący zmienioną dokumentację do bazy danych;
○ Przycisk "Miejscowości" otwierający okno edycji nazw miejscowości
przechowywanych w bazie;
○ Przycisk "Ulice" otwierający okna edycji nazw miejscowości przechowywanych w
bazie;
○ Przycisk "Odśwież" służący do przeładowywania zawartości list rozwijanych;
● Pole "Status" (znajdujące się pod panelem "Opcji"), w którym wyświetlane są
komunikaty dla użytkownika;
● Przycisk otwierający okno dodawania / edycji miejscowości (obsługiwany przez plik
AddLocation.aspx);
● Przycisk otwierający okno dodawania / edycji ulic (obsługiwany przez plik
AddStreet.aspx).
Strona Pomocy (Help.aspx) zawiera (Rys. 7.28.):
● Listę tematów pomocy;
● Pomoc dotyczącą każdej strony serwisu.
Strona potwierdzająca poprawne wylogowanie (Logout.aspx) zawiera (Rys. 7.29.):
● Komunikat potwierdzający poprawne wylogowanie;
● Odnośnik do strony logowania.
70
Rys. 7.27. Strona edycji dokumentacji [P. Traczyński].
71
Rys. 7.28. Strona pomocy [P. Traczyński].
Rys. 7.29. Strona potwierdzająca poprawne wylogowanie [P. Traczyński].
72
7.3.4. Interakcje
W projektowanym systemie zachodzą opisane poniżej interakcje pomiędzy akcjami
użytkownika na graficznym interfejsie użytkownika a odwołaniami systemu do bazy danych.
(Interakcje dla każdej strony www wymienione zostały według kolejności ich występowania.)
Strona logowania (Login.aspx)
Naciśnięcie przycisku "Zaloguj" w przypadku wypełnionych pól "Login" i "Hasło"
spowoduje odwołanie się systemu do pliku App_Data\ASPNETDB.MDF w celu sprawdzenia
poprawności loginu i hasła. Plik ten został automatycznie wygenerowany przez środowisko
Visiual Web Developer i przechowuje nazwy użytkowników, nazwy grup i przynależności do
nich.
Strona główna (Default.aspx)
Strona ta nie zawiera odwołań do bazy danych.
Strona listy wszystkich dokumentacji (ListAll.aspx)
Interakcje na tej stronie są następujące:
1. Użytkownik wchodzi na stronę listy wszystkich dokumentacji
● System wykonuje zapytanie do bazy danych mające na celu wyświetlenie
podstawowych informacji o wszystkich dokumentacjach (Rys. 7.30.):
SELECT Dokumentacje.IDDokumentacji, Dokumentacje.Data, Miejscowosci.Miejscowosc, Ulice.Ulica, Dokumentacje.AdresDodatkoweFROM DokumentacjeJOIN Miejscowosci ON Miejscowosci.IDMiejscowosci = Dokumentacje.IDMiejscowosciJOIN Ulice ON Ulice.IDUlicy = Dokumentacje.IDUlicy
73
Rys. 7.30. Użytkownik wszedł na stronę Listy wszystkich dokumentacji. System odczytał z bazy danych informacje o wszystkich dokumentacjach [P. Traczyński].
2. Użytkownik naciska przycisk "Filtruj"
● System wykonuje zapytanie do bazy danych zwracające w wyniku tylko
dokumentacje wykonane w określonym przez użytkownika przedziale lat (Rys. 7.31.):
SELECT Dokumentacje.IDDokumentacji, Dokumentacje.Data, Miejscowosci.Miejscowosc, Ulice.Ulica, Dokumentacje.AdresDodatkoweFROM DokumentacjeJOIN Miejscowosci ON Miejscowosci.IDMiejscowosci = Dokumentacje.IDMiejscowosciJOIN Ulice ON Ulice.IDUlicy = Dokumentacje.IDUlicyWHERE Datepart(year, Dokumentacje.Data) BETWEEN @YearFrom AND @YearTo
74
● Dla wyszukiwań dokumentacji z jednego określonego roku komenda SQL
wygląda następująco (Rys. 7.32.):
SELECT Dokumentacje.IDDokumentacji, Dokumentacje.Data, Miejscowosci.Miejscowosc, Ulice.Ulica, Dokumentacje.AdresDodatkoweFROM DokumentacjeJOIN Miejscowosci ON Miejscowosci.IDMiejscowosci = Dokumentacje.IDMiejscowosciJOIN Ulice ON Ulice.IDUlicy = Dokumentacje.IDUlicyWHERE Datepart(year, Dokumentacje.Data) = @SingleYear
Rys. 7.31. Użytkownik nacisnął przycisk filtruj. System odczytał z bazy danych i wyświetlił dokumentacje z podanego przedziału lat (1995-2004) [P. Traczyński].
75
Rys. 7.32. Użytkownik nacisnął przycisk "Filtruj". System odczytał z bazy danych i wyświetlił dokumentacje z wybranego roku (1990) [P. Traczyński].
Strona wyszukiwania dokumentacji - Search.aspx
Interakcje na tej stronie są następujące:
1. Użytkownik naciska przycisk "Szukaj"
● System wykonuje zapytanie do bazy danych zwracające w wyniku
dokumentacje spełniające kryteria wyszukiwania (Rys. 7.33.):
SELECT Dokumentacje.IDDokumentacji, Dokumentacje.Data, Miejscowosci.Miejscowosc, Ulice.Ulica, Dokumentacje.AdresDodatkoweFROM DokumentacjeJOIN Miejscowosci ON Miejscowosci.IDMiejscowosci = Dokumentacje.IDMiejscowosciJOIN Ulice ON Ulice.IDUlicy = Dokumentacje.IDUlicy WHERE [tutaj warunki zależne od wybranych kryteriów wyszukiwań]
76
Rys. 7.33. Użytkownik nacisnął przycisk "Szukaj". System odczytał z bazy danych i wyświetlił dokumentacje spełniające kryteria wyszukiwania (miejscowość = "warszawa") [P. Traczyński].
● W przypadku, gdy użytkownik nie podał żadnych kryteriów wyszukiwania,
system wykona zapytanie zwracające wszystkie dokumentacje z bazy danych
(Rys. 7.34.):
SELECT Dokumentacje.IDDokumentacji, Dokumentacje.Data, Miejscowosci.Miejscowosc, Ulice.Ulica, Dokumentacje.AdresDodatkoweFROM DokumentacjeJOIN Miejscowosci ON Miejscowosci.IDMiejscowosci = Dokumentacje.IDMiejscowosciJOIN Ulice ON Ulice.IDUlicy = Dokumentacje.IDUlicy
77
Rys. 7.34. Użytkownik nacisnął przycisk "Szukaj". Ponieważ użytkownik nie podał żadnych kryteriów wyszukiwania system odczytał z bazy danych i wyświetlił wszystkie dokumentacje [P. Traczyński].
Strona szczegółów dokumentacji - Details.aspx
Interakcje na tej stronie są następujące:
1. Użytkownik wchodzi na stronę szczegółów dokumentacji
● System wykonuje 19 zapytań do bazy danych. Każde zwraca jeden szczegół
dotyczący wybranej dokumentacji. Wszystkie 19 szczegółów jest następnie
prezentowane na stronie www (Rys. 7.35.):
SELECT Typy.Typ FROM Dokumentacje JOIN TypyON Typy.IDTypu = Dokumentacje.IDTypu WHERE IDDokumentacji = @IDDokumentacji---
78
SELECT Datepart(day, Dokumentacje.Data) FROM DokumentacjeWHERE IDDokumentacji = @IDDokumentacji---SELECT Datepart(month, Dokumentacje.Data) FROM DokumentacjeWHERE IDDokumentacji = @IDDokumentacji---SELECT Datepart(year, Dokumentacje.Data) FROM DokumentacjeWHERE IDDokumentacji = @IDDokumentacji---SELECT Strefy.Strefa FROM Dokumentacje JOIN StrefyON Strefy.IDStrefy = Dokumentacje.IDStrefy WHERE IDDokumentacji = @IDDokumentacji---SELECT Miejscowosci.Miejscowosc FROM Dokumentacje JOIN MiejscowosciON Miejscowosci.IDMiejscowosci = Dokumentacje.IDMiejscowosci WHERE IDDokumentacji = @IDDokumentacji---SELECT Ulice.Ulica FROM Dokumentacje JOIN UliceON Ulice.IDUlicy = Dokumentacje.IDUlicy WHERE IDDokumentacji = @IDDokumentacji---SELECT Dokumentacje.AdresDodatkowe FROM DokumentacjeWHERE IDDokumentacji = @IDDokumentacji---SELECT Dokumentacje.IloscOtworow FROM DokumentacjeWHERE IDDokumentacji = @IDDokumentacji---SELECT Dokumentacje.MaksGlebokosc FROM DokumentacjeWHERE IDDokumentacji = @IDDokumentacji---SELECT Dokumentacje.Geologia FROM DokumentacjeWHERE IDDokumentacji = @IDDokumentacji---SELECT Agresywnosc.Agresywnosc FROM Dokumentacje JOIN AgresywnoscON Agresywnosc.IDAgresywnosci = Dokumentacje.IDAgresywnosci WHERE IDDokumentacji = @IDDokumentacji---SELECT BadaniaSpecjalistyczne.BadaniaSpec FROM Dokumentacje JOIN BadaniaSpecjalistyczneON BadaniaSpecjalistyczne.IDBadaniaSpec = Dokumentacje.IDBadaniaSpec WHERE IDDokumentacji = @IDDokumentacji
79
---SELECT Dokumentacje.WodaNa1 FROM DokumentacjeWHERE IDDokumentacji = @IDDokumentacji---SELECT Dokumentacje.WodaNa2 FROM DokumentacjeWHERE IDDokumentacji = @IDDokumentacji---SELECT Dokumentacje.Profil1 FROM DokumentacjeWHERE IDDokumentacji = @IDDokumentacji---SELECT Dokumentacje.Profil2 FROM DokumentacjeWHERE IDDokumentacji = @IDDokumentacji---SELECT Dokumentacje.Uwagi FROM DokumentacjeWHERE IDDokumentacji = @IDDokumentacji---SELECT Dokumentacje.Haslo FROM DokumentacjeWHERE IDDokumentacji = @IDDokumentacji
Strona dodawania dokumentacji - Add.aspx
Interakcje na tej stronie są następujące:
1. Użytkownik wchodzi na stronę dodawania dokumentacji
● System sprawdza, jakie ID będzie miała nowa dokumentacja. Sprawdzane są
kolejne numery od 1 aż do momentu kiedy system trafi na brak rekordu o podanym ID
(Rys. 7.36.). Używane do tego jest następujące zapytanie SQL:
SELECT IDDokumentacji FROM DokumentacjeWHERE IDDokumentacji = @IDDokumentacji
● System sprawdza jakimi wartościami wypełnić kontrolki list rozwijanych (list
wyboru) (Rys. 7.36.). Wykonywane jest to w 6 zapytaniach SQL:
SELECT IDTypu, Typ FROM Typy---SELECT IDStrefy, Strefa FROM Strefy---SELECT IDUlicy, Ulica FROM Ulice ORDER BY Ulica
80
---SELECT IDMiejscowosci, Miejscowosc FROM Miejscowosci ORDER BY Miejscowosc---SELECT IDAgresywnosci, Agresywnosc FROM Agresywnosc ORDER BY Agresywnosc ASC---SELECT IDBadaniaSpec, BadaniaSpec FROM BadaniaSpecjalistyczne ORDER BY BadaniaSpec ASC
Rys. 7.35. Użytkownik wszedł na stronę szczegółów. System odczytał z bazy danych szczegóły wybranej dokumentacji [P. Traczyński].
81
Rys. 7.36. Użytkownik wszedł na stronę dodawania dokumentacji. System sprawdził w bazie danych jakie ID będzie miała dodawana dokumentacja oraz jakimi danymi ma wypełnić kontrolki DropDownList (listy rozwijane) [P. Traczyński].
2. Użytkownik naciska przycisk "Zapisz"
● Jeżeli użytkownik poprawnie podał wszystkie wymagane dane, system zapisze
nową dokumentację w bazie danych (Rys. 7.37.):
INSERT INTO Dokumentacje (IDTypu, Data, IDStrefy, IDMiejscowosci, IDUlicy, AdresDodatkowe, IloscOtworow, MaksGlebokosc, Geologia, IDAgresywnosci, IDBadaniaSpec, WodaNa1, WodaNa2, Profil1, Profil2,
82
Uwagi, Haslo)VALUES (@IDTypu, @Data, @IDStrefy, @IDMiejscowosci, @IDUlicy, @AdresDodatkowe, @IloscOtworow, @MaksGlebokosc, @Geologia, @IDAgresywnosci, @IDBadaniaSpec, @WodaNa1, @WodaNa2, @Profil1, @Profil2, @Uwagi, @Haslo)
Rys. 7.37. Użytkownik nacisnął przycisk "Zapisz". System zapisał dane nowej dokumentacji w bazie danych, po czym z powrotem odczytał je z bazy aby wyświetlić potwierdzenie udanego dodania nowej dokumentacji [P. Traczyński].
83
Strona edycji danych dokumentacji - Edit.aspx
Interakcje na tej stronie są następujące:
1. Użytkownik naciska przycisk "Wczytaj"
● System wykonuje zapytanie do bazy danych w celu sprawdzenia, czy istnieje
dokumentacja o podanym ID (Rys. 7.38.). Jeżeli zapytanie zwraca wartość null to
znaczy, że nie ma dokumentacji o podanym ID.
SELECT Dokumentacje.IDTypu FROM DokumentacjeWHERE IDDokumentacji = @IDDokumentacji
● Jeżeli dokumentacja o podanym ID istnieje, to system sprawdza jakimi
wartościami wypełnić kontrolki list rozwijanych (list wyboru) (Rys. 7.38.).
Wykonywane jest to w 6 zapytaniach SQL:
SELECT IDTypu, Typ FROM Typy---SELECT IDStrefy, Strefa FROM Strefy---SELECT IDUlicy, Ulica FROM Ulice ORDER BY Ulica---SELECT IDMiejscowosci, Miejscowosc FROM Miejscowosci ORDER BY Miejscowosc---SELECT IDAgresywnosci, Agresywnosc FROM Agresywnosc ORDER BY Agresywnosc ASC---SELECT IDBadaniaSpec, BadaniaSpec FROM BadaniaSpecjalistyczne ORDER BY BadaniaSpec ASC
● Następnie system wykonuje 19 zapytań do bazy danych. Każde zwraca jeden
szczegół dotyczący wybranej dokumentacji. Dane dotyczące szczegółów są następnie
wyświetlane w kontrolkach TextBox i DropDownList (Rys. 7.38.).
SELECT Typy.Typ FROM Dokumentacje JOIN TypyON Typy.IDTypu = Dokumentacje.IDTypu WHERE IDDokumentacji = @IDDokumentacji
84
---SELECT Datepart(day, Dokumentacje.Data) FROM DokumentacjeWHERE IDDokumentacji = @IDDokumentacji---SELECT Datepart(month, Dokumentacje.Data) FROM DokumentacjeWHERE IDDokumentacji = @IDDokumentacji---SELECT Datepart(year, Dokumentacje.Data) FROM DokumentacjeWHERE IDDokumentacji = @IDDokumentacji---SELECT Strefy.Strefa FROM Dokumentacje JOIN StrefyON Strefy.IDStrefy = Dokumentacje.IDStrefy WHERE IDDokumentacji = @IDDokumentacji---SELECT Miejscowosci.Miejscowosc FROM Dokumentacje JOIN MiejscowosciON Miejscowosci.IDMiejscowosci = Dokumentacje.IDMiejscowosci WHERE IDDokumentacji = @IDDokumentacji---SELECT Ulice.Ulica FROM Dokumentacje JOIN UliceON Ulice.IDUlicy = Dokumentacje.IDUlicy WHERE IDDokumentacji = @IDDokumentacji---SELECT Dokumentacje.AdresDodatkowe FROM DokumentacjeWHERE IDDokumentacji = @IDDokumentacji---SELECT Dokumentacje.IloscOtworow FROM DokumentacjeWHERE IDDokumentacji = @IDDokumentacji---SELECT Dokumentacje.MaksGlebokosc FROM DokumentacjeWHERE IDDokumentacji = @IDDokumentacji---SELECT Dokumentacje.Geologia FROM DokumentacjeWHERE IDDokumentacji = @IDDokumentacji---SELECT Agresywnosc.Agresywnosc FROM Dokumentacje JOIN AgresywnoscON Agresywnosc.IDAgresywnosci = Dokumentacje.IDAgresywnosci WHERE IDDokumentacji = @IDDokumentacji---SELECT BadaniaSpecjalistyczne.BadaniaSpec FROM Dokumentacje JOIN BadaniaSpecjalistyczneON BadaniaSpecjalistyczne.IDBadaniaSpec = Dokumentacje.IDBadaniaSpec
85
WHERE IDDokumentacji = @IDDokumentacji---SELECT Dokumentacje.WodaNa1 FROM DokumentacjeWHERE IDDokumentacji = @IDDokumentacji---SELECT Dokumentacje.WodaNa2 FROM DokumentacjeWHERE IDDokumentacji = @IDDokumentacji---SELECT Dokumentacje.Profil1 FROM DokumentacjeWHERE IDDokumentacji = @IDDokumentacji---SELECT Dokumentacje.Profil2 FROM DokumentacjeWHERE IDDokumentacji = @IDDokumentacji---SELECT Dokumentacje.Uwagi FROM DokumentacjeWHERE IDDokumentacji = @IDDokumentacji---SELECT Dokumentacje.Haslo FROM DokumentacjeWHERE IDDokumentacji = @IDDokumentacji
2. Użytkownik naciska przycisk "Zapisz"
● Jeżeli użytkownik poprawnie podał wszystkie wymagane dane, system zapisze
nową dokumentację w bazie danych (Rys. 7.39.):
UPDATE Dokumentacje SET IDTypu = @IDTypu, Data = @Data, IDStrefy = @IDStrefy, IDMiejscowosci = @IDMiejscowosci, IDUlicy = @IDUlicy, AdresDodatkowe = @AdresDodatkowe, IloscOtworow = @IloscOtworow, MaksGlebokosc = @MaksGlebokosc, Geologia = @Geologia, IDAgresywnosci = @IDAgresywnosci, IDBadaniaSpec = @IDBadaniaSpec, WodaNa1 = @WodaNa1, WodaNa2 = @WodaNa2, Profil1 = @Profil1, Profil2 = @Profil2, Uwagi = @Uwagi, Haslo = @HasloWHERE IDDokumentacji = @iDDokumentacji
86
Rys. 7.38. Użytkownik nacisnął przycisk "Wczytaj". System sprawdził, czy istnieje dokumentacja o podanym numerze ID, po czym odczytał z bazy danych szczegóły dokumentacji oraz sprawdził jakimi danymi ma wypełnić kontrolki DropDownList (listy rozwijane) [P. Traczyński].
Okno dodawania miejscowości - AddLocation.aspx
Okno to można otworzyć poprzez wciśnięcie przycisku "Miejscowości" na stronie
Dodawania dokumentacji lub na stronie Edycji dokumentacji. Interakcje są tu następujące:
1. Użytkownik naciska przycisk "Zapisz"
● Jeżeli użytkownik poprawnie podał wszystkie wymagane dane, system
87
sprawdza, czy podanej nazwy miejscowości nie ma już w bazie (w celu uniknięcia
duplikujących się wpisów):SELECT Miejscowosci.Miejscowosc FROM Miejscowosci WHERE Miejscowosc = @Miejscowosc
Rys. 7.39. Użytkownik nacisnął przycisk "Zapisz". System zapisał poprawione dane dokumentacji, po czym z powrotem odczytał je z bazy aby wyświetlić potwierdzenie udanej modyfikacji szczegółów dokumentacji [P. Traczyński].
88
● Następnie, jeżeli w bazie nie ma jeszcze podanej miejscowości, system doda ją
do bazy (Rys. 7.40.):
INSERT INTO Miejscowosci (Miejscowosc) VALUES (@Miejscowosc)
Rys. 7.40. Użytkownik nacisnął przycisk "Zapisz". System zapisał w bazie danych nową miejscowość [P. Traczyński].
2. Użytkownik zaznacza pole "Aktualizacja" i naciska przycisk "Zapisz"
● Jeżeli użytkownik poprawnie podał wszystkie wymagane dane, system
sprawdza czy miejscowość, której nazwę chce zmienić znajduje się w bazie:
SELECT Miejscowosci.Miejscowosc FROM Miejscowosci WHERE Miejscowosc = @Miejscowosc
● Następnie system sprawdza, czy podanej nowej nazwy miejscowości nie ma
już w bazie (w celu uniknięcia duplikujących się wpisów):
SELECT Miejscowosci.Miejscowosc FROM Miejscowosci WHERE Miejscowosc = @Miejscowosc
● Na końcu system dokonuje aktualizacji nazwy miejscowości (Rys. 7.41.):
UPDATE Miejscowosci SET Miejscowosci.Miejscowosc = @newNameMiejscowoscWHERE Miejscowosci.Miejscowosc = @Miejscowosc
89
Rys. 7.41. Użytkownik zaznaczył pole "Aktualizacja" i nacisnął przycisk "Zapisz". System zmienił nazwę miejscowości zapisanej w bazie danych. [P. Traczyński]
Okno dodawania ulic - AddStreet.aspx
Okno to można otworzyć poprzez wciśnięcie przycisku "Ulice" na stronie Dodawania
dokumentacji lub na stronie Edycji dokumentacji. Interakcje są tu następujące:
1. Użytkownik naciska przycisk "Zapisz"
● Jeżeli użytkownik poprawnie podał wszystkie wymagane dane, system
sprawdza czy podanej nazwy ulicy nie ma już w bazie (w celu uniknięcia
duplikujących się wpisów):
SELECT Ulice.Ulica FROM Ulice WHERE Ulica = @Ulica
● Następnie, jeżeli w bazie nie ma jeszcze podanej ulicy, system doda ją do bazy:
INSERT INTO Ulice (Ulica) VALUES (@Ulica)
2. Użytkownik zaznacza pole "Aktualizacja" i naciska przycisk "Zapisz"
● Jeżeli użytkownik poprawnie podał wszystkie wymagane dane, system
sprawdza , czy ulica, której nazwę chce zmienić, znajduje się w bazie:
SELECT Ulice.Ulica FROM Ulice WHERE Ulica = @Ulica
● Następnie system sprawdza, czy podanej nowej nazwy miejscowości nie ma
już w bazie (w celu uniknięcia duplikujących się wpisów):
90
SELECT Ulice.Ulica FROM Ulice WHERE Ulica = @Ulica
● Na końcu system dokonuje aktualizacji nazwy miejscowości (Rys. 7.43.):
UPDATE Ulice SET Ulice.Ulica = @newNameUlicaWHERE Ulice.Ulica = @Ulica
Rys. 7.42. Użytkownik nacisnął przycisk "Zapisz". System zapisał w bazie danych nową ulicę. [P. Traczyński]
Rys. 7.43. Użytkownik zaznaczył pole "Aktualizacja" i nacisnął przycisk "Zapisz". System zmienił nazwę ulicy zapisanej w bazie danych. [P. Traczyński]
Strona potwierdzająca poprawne wylogowanie - Logout.aspx
Strona ta nie zawiera odwołań do bazy danych.
Strona Pomocy - Help.aspx
Strona ta nie zawiera odwołań do bazy danych.
91
7.3.5. Opis interfejsu użytkownika
Interfejs użytkownika jest na ogół pierwszą rzeczą, na którą uwagę zwraca
użytkownik uruchamiając nowy program. W czasach, kiedy programy miały charakter
wyłącznie tekstowy, programiści nie musieli martwić się projektowaniem graficznego
interfejsu użytkownika.
W dzisiejszych czasach coraz większą uwagę zwraca się nie tylko na funkcjonalność,
ale także na estetykę programu. Najważniejsze cechy, które powinien posiadać każdy
graficzny interfejs użytkownika to:
● Przejrzystość
● Intuicyjność
● Logiczna konstrukcja
● Stonowana kolorystyka
Dodatkowo często spotyka się grafiki związane wyłącznie z estetyką, a nie pełniące
innych funkcji.
Podczas tworzenia GIU (Graphical User Interface) dla projektowanego systemu,
uwzględnione zostały wszystkie wymienione powyżej aspekty.
Zaprojektowany interfejs składa się następujących elementów (Rys. 7.44.):
1. Menu główne
● Umożliwia dostęp do wybranych stron serwisu.
2. Tytuł i opis strony
● Informuje użytkownika, na jakiej stronie się znajduje.
3. Panel "Opcji"
● Umożliwia korzystanie z różnych funkcji strony.
4. Pole "Statusu"
● W tym miejscu wyświetlane są komunikaty dla użytkownika.
5. Główna zawartość strony
● Dla każdej strony jest inna.
6. Menu dolne
● Zawiera te same opcje co menu główne. Umożliwia skorzystanie z nich w
momencie, kiedy użytkownik znajduje się na dole strony i nie widzi w danej chwili
menu głównego.
92
Rys. 7.44. Elementy interfejsu: 1 – Menu główne; 2 – Tytuł i opis strony; 3 – Panel "Opcji"; 4 – Pole "Statusu"; 5 – Główna zawartość strony; 6 – Menu dolne [P. Traczyński].
93
8. Implementacja
8.1. Fazy procesu implementacji
Proces implementacji został podzielony na następujące fazy:
1. Utworzenie bazy danych zgodnie ze wszystkimi założeniami projektowymi.
2. Utworzenie statycznej bazowej strony w HTML, zachowującej układ:
nagłówek – zawartość – stopka i zawierającej kaskadowy arkusz stylów, określający
między innymi kolory i obrazy wyświetlane na stronie, definiujący jakie kroje
czcionek będą używane do wyświetlania tekstu itp.
3. Utworzenie wszystkich stron ASP.NET w oparciu o stronę bazową. Proces ten
nie obejmuje oprogramowania stron przy użyciu C#. Wykonane zostały tu
niedziałające jeszcze strony, ale zawierające już wszystkie niezbędne elementy - pola
tekstowe TextBox, listy rozwijane DropDownList, etykiety Label oraz wszelkie inne
elementy charakterystyczne dla technologii ASP.NET.
4. Oprogramowanie wszystkich stron ASP.NET przy pomocy języka
programowania C#.
8.2. Implementacja bazy danych
Baza danych została wykonana przy użyciu narzędzia Microsoft SQL Server
Management Studio, które pozwala w wygodny sposób tworzyć tabele, relacje i inne
elementy w bazie danych. Nie trzeba wpisywać procedur SQL w celu utworzenia tabel i
relacji, korzysta się z graficznego środowiska tworzenia baz danych. Dzięki temu baza
danych została zrealizowana szybko, a zarazem zgodnie z założeniami projektu.
8.3. Implementacja bazowej strony www
Strona bazowa jest pewnego rodzaju szablonem, w oparciu o który tworzy się wybrane
strony serwisu tak, aby zachowywały pewien wspólny układ. W omawianym przypadku
strona ta była statyczną stroną HTML, posiadającą bardzo ograniczoną, w stosunku do całego
projektu, funkcjonalność.
94
Stronę bazową przygotowano przy użyciu narzędzia Microsoft Web Developer. Proces
implementacji uwzględniał:
● przygotowanie grafiki do umieszczenia jej na stronie www;
● zrealizowanie kodu HTML strony bazowej;
● zrealizowanie kaskadowych arkuszy stylów CSS strony bazowej.
8.4. Implementacja interfejsów stron ASP.NET
Po wykonaniu strony bazowej, rozpoczęto realizację poszczególnych stron aplikacji
internetowej. Na podstawie strony bazowej HTML utworzony został plik Masterpage.master,
napisany już w języku ASP.NET. Serwer aplikacji internetowej ASP.NET używa tego pliku
podczas budowania strony, którą wyśle do klienta. Ułatwia to zmiany w tych elementach
serwisu, które pojawiają się na wielu stronach. Element wystarczy edytować wyłącznie w
pliku *.master.
W oparciu o plik Masterpage.master utworzone zostały wszystkie pliki *.aspx, czyli
pliki stron ASP.NET, zawierające wszystkie formularze, wszystkie przyciski, listy rozwijane,
etykiety, pola tekstowe i inne elementy typowe dla tej technologii.
Utworzone w ASP.NET strony aplikacji internetowej otrzymały już ostateczny
wygląd, ale nie były jeszcze oprogramowane. Oznacza to, że użytkownik mógł nawigować po
stronie, ale system nie reagował na żadne działania użytkownika, takie jak np: wciskanie
przycisków. Wszelkie wprowadzane w formularzach dane były ignorowane.
8.5. Implementacja funkcjonalności stron ASP.NET
Implementacja funkcjonalności ASP.NET polegała na utworzeniu kodu
programistycznego C#, który obsługiwałby wszystkie strony umieszczone w plikach *.aspx.
W ASP.NET możliwe jest oddzielenie kodu C# od pliku *.aspx poprzez umieszczenie
go w oddzielnym pliku (*.cs), zwanym plikiem chowającym kod. W takiej sytuacji w pliku
*.aspx zapisywana jest referencja do pliku z kodem C#. Kompilator, podczas wczytywania
danej strony, dzięki zapisanej referencji, odnajduje plik z kodem.
Technika ta została wykorzystana także podczas implementacji systemu. Dzięki temu,
w poprzedniej fazie, można było w całości utworzyć pliki *.aspx, a dopiero później
oprogramować wszystkie strony, edytując jedynie pliki z kodem C#.
Wykonanie kodu C# zapewniającego funkcjonalność stron ASP.NET była
95
najtrudniejszą i najbardziej pracochłonną częścią implementacji. Czasochłonność procesu
tworzenia kodu można uzasadnić, między innymi, ilością kodu, który został napisany. Liczba
wierszy w plikach z kodem wynosi ponad 3000, co prawie dwukrotnie przekracza ilość kodu
napisaną w drugiej i trzeciej fazie implementacji (implementacja bazowej strony www,
implementacja stron ASP.NET).
8.6. Obsługa systemu
Aby skorzystać z systemu WellDone należy w przeglądarce www wejść na adres
przypisany serwerowi obsługującemu system aplikacji internetowej. Adres ten jest ustawiany
przez obsługującego lokalną sieć firmy administratora i może być różny, w zależności od
ustawień.
8.6.1. Logowanie
● Po wpisaniu poprawnego adresu serwera obsługującego aplikację WellDone powinna
pojawić się strona logowania (Rys. 8.1.).
● Aby skorzystać z systemu WellDone trzeba być zalogowanym. Niezalogowany
96
Rys. 8.1. Strona logowania [P. Traczyński].
użytkownik ma dostęp jedynie do strony pomocy (aby skorzystać z pomocy kliknij
"Pomoc" w menu strony).
● W celu zalogowania się należy wpisać w odpowiednich polach poprawny login
i hasło, po czym kliknąć przycisk "Zaloguj".
● W przypadku niepoprawnych danych system wyświetli komunikat "Próba logowania
nie powiodła się!"
● W przypadku udanego logowania użytkownik zostanie przeniesiony na stronę główną.
8.6.2. Strona główna
● Strona główna w przejrzysty sposób prezentuje funkcje, do których użytkownik ma
dostęp (Rys. 8.2.).
Rys. 8.2. Strona główna [P. Traczyński].
● Te same opcje dostępne są zarówno w menu głównym (u góry strony) jak i w menu
dolnym (u dołu strony).
● Dostępność opcji zależy od tego, jakiego typu użytkownik jest zalogowany.
● Użytkownicy dzielą się na dwie grupy:
97
○ użytkownicy z pełnymi prawami (Administratorzy);
○ użytkownicy ograniczeni (nie mają praw dokonywania zmian w bazie danych).
● W przypadku gdy zalogowany jest użytkownik ograniczony, strona główna wygląda
inaczej, niż gdy zalogowany jest użytkownik z pełnymi prawami, ponieważ wszystkie
funkcje, do których użytkownik nie ma dostępu wyświetlone są w kolorze szarym
(Rys. 8.3.).
Rys. 8.3. Wygląd strony głównej w przypadku zalogowanego użytkownika ograniczonego [P. Traczyński].
8.6.3. Przeglądanie listy wszystkich dokumentacji
● Aby skorzystać z tej funkcji należy wybrać w menu strony odnośnik "Lista" lub
kliknąć na stronie głównej ikonę zapisanej kartki. System wyświetli stronę
zatytułowaną "Lista wszystkich dokumentacji" (Rys. 8.4.).
● Strona ta zawiera tabelę z wszystkimi dotychczas wykonanymi dokumentacjami.
Kliknięcie odnośnika w kolumnie "Szczegóły" przenosi użytkownika na stronę
prezentującą dane szczegółowe wybranej dokumentacji (patrz podrozdział 8.6.5.).
● Możliwe jest także sortowanie danych według wybranej kolumny. W tym celu należy
kliknąć nazwę kolumny, według której chcemy sortować. Aby odwrócić kolejność
98
sortowania należy kliknąć ją ponownie. Domyślnie dane sortowane są rosnąco według
ID Dokumentacji.
● Tabela posiada także stronicowanie (dane o dokumentacjach wyświetlane są porcjami
po 10 na jednej stronie). Aby przejść do innej strony należy wybrać jej numer u dołu
tabeli.
Rys. 8.4. Strona wyświetlająca wszystkie dokumentacje [P. Traczyński].
● Omawiana strona posiada także panel opcji umożliwiający filtrowanie wyświetlanych
danych. Możliwe jest wyświetlenie dokumentacji geotechnicznych z wybranego
przedziału lat, bądź z jednego określonego roku. W pierwszym przypadku należy w
"Opcjach" podać rok rozpoczynający przedział oraz rok zamykający przedział. Gdy w
pierwszym polu wartości podany zostanie rok "1995" oraz w drugim polu "2000",
wyświetlone zostaną dokumentacje z lat 1995-2000, o czym poinformuje system
wyświetlając odpowiedni komunikat. W celu wyświetlenia dokumentacji z jednego
99
wybranego roku należy wpisać ten rok w polu pierwszym, a drugie pole pozostawić
puste. Dopuszczalne są wartości z zakresu 1000-9999.
● W przypadku podania niepoprawnych danych system wyświetli odpowiedni
komunikat.
8.6.4. Wyszukiwanie dokumentacji
● Aby wyszukiwać dokumentacje należy wybrać w menu strony odnośnik "Szukaj" lub
kliknąć na stronie głównej ikonę lupy. System wyświetli stronę zatytułowaną
"Wyszukiwanie dokumentacji" (Rys. 8.5.).
Rys. 8.5. Strona wyszukiwania dokumentacji [P. Traczyński].
● Strona ta umożliwia wyszukiwanie dokumentacji według zadanych kryteriów
wyszukiwania. Aby dokonać wyszukania należy w "Opcjach" podać dane w jednym
bądź kilku polach, po czym nacisnąć przycisk "Szukaj".
● System umożliwia wyszukiwanie według:
○ ID dokumentacji
○ Daty wykonania
100
○ Nazwy miejscowości
○ Nazwy ulicy
● Podczas wyszukiwania uwzględnione są tylko te pola danych, przy których
zaznaczone jest pole wyboru (tzw. CheckBox), oraz te które jednocześnie nie są puste.
Pozostałe pola są ignorowane. W przypadku zmiany kryteriów wyszukiwania, na
przykład z miejscowości na nazwę ulicy, nie trzeba usuwać podanej wcześniej nazwy
miejscowości - wystarczy odhaczyć zaznaczenie z odpowiedniego pola wyboru.
● W celu wyszukania dokumentacji wykonanych na terenie Warszawy należy w polu
"Miejscowość" wpisać "Warszawa". Należy mieć na uwadze, że system wyszukuje
również na podstawie fragmentów ciągów. Np. wpisanie w polu "Ulica" treści "Krak"
może zwrócić w wynikach dokumentacji wykonane przy ulicy Krakowskie
Przedmieście.
● System nie rozróżnia wielkości liter.
● Wyniki wyszukiwania zwrócone są w postaci tabeli, identycznej jak ta na stronie
"Lista wszystkich dokumentacji". Tabele te posiadają identyczną funkcjonalność.
● Kliknięcie odnośnika w kolumnie "Szczegóły" tabeli wyników przenosi użytkownika
na stronę prezentującą dane szczegółowe wybranej dokumentacji (patrz podrozdział
8.6.5.).
● Możliwe jest także sortowanie danych według wybranej kolumny. W tym celu należy
kliknąć nazwę kolumny, według której chcemy sortować. Aby odwrócić kolejność
sortowania należy kliknąć ją ponownie. Domyślnie dane są sortowane rosnąco według
ID Dokumentacji.
● Tabela wyników posiada także stronicowanie (dane o dokumentacjach wyświetlane są
porcjami po 10 na jednej stronie). Aby przejść do innej strony należy wybrać jej
numer u dołu tabeli.
8.6.5. Przeglądanie szczegółów wybranej dokumentacji
● Strona szczegółów umożliwia przejrzenie wszystkich danych przechowywanych przez
system, dotyczących określonej dokumentacji (Rys. 8.6.).
● Aby przejrzeć dane szczegółowe należy na stronie "Lista wszystkich dokumentacji"
bądź na stronie "Wyszukiwanie dokumentacji" kliknąć odnośnik znajdujący się w
kolumnie "Szczegóły" w tabeli prezentującej dane.
101
Rys. 8.6. Strona szczegółów dokumentacji [P. Traczyński].
Panel opcji
● Przycisk "Drukuj" przenosi użytkownika na stronę przygotowaną specjalnie w celu
wykonania przejrzystego wydruku danych szczegółowych.
● W przypadku, gdy zalogowany użytkownik ma prawa zapisu (należy do grupy
"Administrator"), wyświetlony zostanie również przycisk "Edytuj". Wciśnięcie tego
przycisku przenosi bezpośrednio na stronę "Edycja dokumentacji" gdzie
automatycznie wczytana zostanie ta sama dokumentacja, której szczegóły były
wyświetlone na stronie szczegółów.
● Strona szczegółów zostanie także wyświetlona automatycznie w momencie dokonania
102
przez użytkownika wpisu nowej dokumentacji lub edycji dokumentacji. Umożliwia to
szybkie przejrzenie, zapisanych w bazie, danych w celu weryfikacji. W sytuacji tej
wyświetlony zostanie również komunikat o udanym zapisie danych do bazy.
8.6.6. Dodawanie nowej dokumentacji do archiwum
● Aby dodać nową dokumentację wybierz w menu strony odnośnik "Dodaj" lub kliknij
na stronie głównej ikonę zielonego plusa. System wyświetli stronę zatytułowaną
"Dodawanie dokumentacji" (Rys. 8.7). Dostęp do strony „Dodawanie dokumentacji”
mają tylko użytkownicy posiadający prawo edycji danych.
● W panelu "Opcji" wyświetlone zostanie ID dodawanej dokumentacji. Należy wypełnić
formularz odpowiednimi danymi. Pola oznaczone gwiazdką są wymagane.
● Opis pól:
Dane ogólne:
○ Typ: określa typ dokumentacji. Domyślnie wybrana jest dokumentacja
"Geotechniczna" ponieważ jest to najczęstszy typ dokumentacji.
○ Data: określa datę realizacji dokumentacji. System automatycznie wybiera
aktualny miesiąc i rok (na podstawie ustawień zegara na serwerze), ponieważ w
przypadku dodawania dokumentacji na bieżąco (tzn. tuż po ich opracowaniu)
będzie to prawdopodobnie właśnie ten miesiąc i rok.
Dane adresowe:
○ Strefa: określa, w jakiej strefie prowadzone były prace udokumentowane w danej
dokumentacji. Domyślną strefą jest war - strefa warszawska, ponieważ dotyczy
ona większości prac.
○ Miejscowość: określa w jakiej miejscowości prowadzone były prace. Domyślną
miejscowością jest Warszawa.
○ Ulica: określa przy jakiej ulicy prowadzone były prace. Domyślną wartością jest
"(nieokreślona)".
○ Adres dodatkowe: jakiekolwiek inne informacje związane z położeniem badanej
działki, dojazdem itp.
Dane geotechniczne:
○ Ilość otworów: określa ilość otworów badawczych wykonanych podczas prac
terenowych (ewentualnie ilość punktów, w których wykonano sondowania). Pole
103
to akceptuje wyłącznie wartości w postaci liczb naturalnych.
○ Maksymalna głębokość: głębokość do której wykonano rozpoznanie podłoża
gruntowego. Pole to akceptuje wyłącznie wartości liczbowe. Dopuszczalne są
ułamki; w celu ich określenia należy używać przecinka.
○ Geologia: przechowuje dane charakteryzujące pochodzenie terenu badań.
○ Agresywność: określa agresywność wody gruntowej. Należy wybrać tak/nie.
○ Badania Specjalistyczne: określa czy były wykonane badania specjalistyczne
(wykonywane w przypadku skomplikowanej budowy geologicznej). Należy
wybrać tak/nie.
○ Woda na (1): określa głębokość zalegania zwierciadeł wody podziemnej. Pole to
zezwala na wpisywanie znaków innych niż cyfry.
○ Woda na (2): określa alternatywną głębokość zalegania zwierciadeł wody
podziemnej. Pole to zezwala na wpisywanie znaków innych niż cyfry.
○ Profil 1: opisuje budowę geologiczną w profilu pionowym (maksymalnie 200
znaków).
○ Profil 2: opisuje alternatywną budowę geologiczną w profilu pionowym
(maksymalnie 200 znaków).
Inne:
○ Uwagi: wszelkie inne informacje (maksymalnie 200 znaków).
○ Hasło: słowo bądź słowa kluczowe które mogą np. łączyć ze sobą jakąś grupę
dokumentacji (maksymalnie 200 znaków).
● Po wypełnieniu formularza należy nacisnąć przycisk "Zapisz" w celu zapisania danych
nowej dokumentacji. System wyświetli stronę szczegółów dokumentacji. U góry
strony widoczny będzie komunikat o poprawnym zapisaniu danych do bazy.
● Aby dodać kolejną dokumentację wybierz w menu strony opcję "Dodaj".
● W przypadku podania w formularzu dodawania dokumentacji niepoprawnych danych
system wyświetli odpowiedni komunikat w polu "Status" (pod panelem "Opcji").
104
Rys. 8.7. Strona dodawania dokumentacji [P. Traczyński].
8.6.7. Dodawanie nowej miejscowości / Edycja nazwy miejscowości
● Okno dodawania nowej miejscowości można otworzyć naciskając przycisk
"Miejscowości" w panelu "Opcji" na stronie Dodawania dokumentacji lub na stronie
Edycji dokumentacji. Alternatywnie można kliknąć na odnośnik "dodaj" widoczny
obok pola tekstowego "Miejscowość" na jednej z powyższych stron. Dostęp do tej
strony mają tylko użytkownicy posiadający prawa edycji danych.
105
● Dodawanie nowej miejscowości wykonuje się następująco:
1. Wpisz nazwę miejscowości w polu tekstowym "Nazwa";
2. Naciśnij przycisk "Zapisz".
● Edycja nazwy miejscowości:
1. W polu "Nazwa" podaj miejscowość której nazwę chcesz poprawić / zmienić
(musi znajdować się w bazie danych);
2. W polu "Popraw" wpisz nazwę na którą chcesz zmienić;
3. Zaznacz pole wyboru "Aktualizacja";
4. Naciśnij przycisk "Zapisz".
● Aby nowo dodane miejscowości zostały wczytane do formularza Dodawania/Edycji
dokumentacji należy wcisnąć przycisk "Odśwież" w panelu "Opcji".
8.6.8. Dodawanie nowej ulicy / Edycja nazwy ulicy
● Okno dodawania nowej ulicy można otworzyć naciskając przycisk "Ulice" w panelu
"Opcji" na stronie Dodawania dokumentacji lub na stronie Edycji dokumentacji.
Alternatywnie można kliknąć na odnośnik "dodaj" widoczny obok pola tekstowego
"Ulica" na jednej z powyższych stron. Dostęp do tej strony mają tylko użytkownicy
posiadający prawa edycji danych.
● Dodawanie nowej ulicy wykonuje się następująco:
1. Wpisz nazwę ulicy w polu tekstowym "Nazwa";
Uwaga: Nazwa ulicy powinna być zgodna z formatem [xx][. ][nazwa]. Xx to
dwuliterowy przedrostek np. "ul" bądź "Al". Następnie wymagana jest kropka ".",
dalej spacja " " i dopiero potem nazwa ulicy.
2. Naciśnij przycisk "Zapisz".
● Edycja nazwy ulicy:
1. W polu "Nazwa" podaj ulicę której nazwę chcesz poprawić / zmienić (musi
znajdować się w bazie danych);
2. W polu "Popraw" wpisz nazwę na którą chcesz zmienić;
3. Zaznacz pole wyboru "Aktualizacja";
106
4. Naciśnij przycisk "Zapisz".
● Aby nowo dodane ulice zostały wczytane do formularza Dodawania/Edycji
dokumentacji należy wcisnąć przycisk "Odśwież" w panelu "Opcji".
8.6.9. Edycja dokumentacji
● W celu edytowania dokumentacji należy przejść na stronę "Edycja
dokumentacji" (Rys. 8.8.). Dostęp do tej strony mają tylko użytkownicy posiadający
prawa edycji danych. Sposób korzystania z niej zależy od tego, w jaki sposób się na
nią weszło.
● Sposób 1
○ Wybierz w menu strony odnośnik "Edytuj" lub kliknij na stronie głównej ikonę
kartki z ołówkiem. System wyświetli stronę zatytułowaną "Edycja dokumentacji" i
pozwoli na wybranie dokumentacji do edycji (na podstawie id dokumentacji).
○ W panelu "Opcji", w sekcji "Podaj ID:" wpisz id dokumentacji której dane chcesz
edytować.
○ Naciśnij przycisk "Wybierz".
○ System wczyta do formularza wszystkie dane. Można dokonać edycji.
● Sposób 2
○ Będąc na stronie szczegółów dokumentacji naciśnij w panelu "Opcji" przycisk
"Edytuj" (widoczny tylko dla użytkowników z prawami edycji). System wyświetli
stronę "Edycja dokumentacji" z załadowanymi już danymi dokumentacji. Można
dokonać edycji.
Edycja danych
● W formularzu edycji dokumentacji panują identyczne zasady jak w formularzu
dodawania nowej dokumentacji. (Zobacz rozdział 12.6 Dodawanie nowej
dokumentacji do archiwum).
● Po skorygowaniu danych formularza należy nacisnąć przycisk "Zapisz" w celu
zapisania zmienionych danych. System wyświetli stronę szczegółów dokumentacji. U
góry strony widoczny będzie komunikat o poprawnym zapisaniu danych do bazy.
107
Rys. 8.8. Strona edycji dokumentacji [P. Traczyński].
8.6.10. Wylogowanie
● Aby wylogować się wybierz w menu strony opcję "Wyloguj".
● System wyświetli stronę informującą o poprawnym zakończeniu sesji użytkownika
(Rys. 8.9.).
108
Rys. 8.9 Informacja o poprawnym zamknięciu sesji użytkownika [P. Traczyński].
109
9. Testowanie
9.1. Istota testowania
Istotnym punktem wytwarzania oprogramowania jest jego testowanie (patrz
rozdział 2.). Każdy złożony program, który nie zostanie przetestowany, nie będzie nic wart,
ponieważ będzie zawierał poważne błędy.
Dlatego po ukończeniu wczesnej wersji końcowej oprogramowania następują jego
testy. Zbierane są liczne informacje na temat błędów w programie, po czym następuje analiza
przyczyn tych błędów, a następnie ich poprawianie. Następnie dokonuje się kolejnego
testowania, ponownie poprawia błędy i tak aż do momentu w którym utworzony program
będzie działał w sposób zadowalający.
Istnieją złożone systemy, które do końca swojego istnienia są regularnie poprawiane,
ponieważ raz na jakiś czas znajdowane są kolejne błędy.
9.1.1. Proces testowania
Profesjonalnie wykonane testowanie wykonanego oprogramowania powinno składać
się z następujących kroków:
● planowanie testowania;
● projekt testów;
● implementacja i wykonanie testów;
● analiza wyników testowania.
Profesjonalnie wykonane testowanie powinno składać się z następujących testów:
● Testy integralności danych
Sprawdzają poprawność danych, czy bazy danych są zaprojektowane prawidłowo, czy
dane przechowywane przez system są prawidłowo powiązane ze sobą.
● Testy funkcjonowania
Celem tych testów jest sprawdzenie czy system akceptuje wyłącznie dane
odpowiedniego typu, czy przetwarzanie i wykorzystywanie tych danych jest poprawne
oraz czy aplikacja jest napisana zgodnie ze wszystkimi zasadami biznesowymi
dotyczącymi realizowanych przez program zagadnień.
110
● Testy upływu czasu
Testy te mają sprawdzić poprawność funkcjonowania oprogramowania po upływie
pewnego czasu (np. roku). Należy wykonać symulację sposobu w jaki system ten
będzie używany w przyszłości, np. kiedy zmieni się data oraz wymagania firmy
względem systemu.
● Testy interfejsu użytkownika
Testy te sprawdzają poprawność interakcji pomiędzy użytkownikiem a systemem.
Celem testów jest upewnienie się, że interfejs użytkownika umożliwia użytkownikowi
poprawny i łatwy dostęp do wszystkich funkcji. Dodatkowo test interfejsu
użytkownika sprawdza czy obiekty umieszczone w interfejsie działają tak jak się
spodziewano.
● Testy wydajności
Sprawdzają czy oprogramowanie spełnia wymogi związane z wydajnością, czyli np.
czy oprogramowanie działa odpowiednio szybko. W przypadku projektowania
aplikacji korzystających z zasobów serwerów, bądź działających po stronie serwera,
testy wydajności powinny sprawdzać również czas reakcji systemu i prędkość
wczytywania danych podczas silnego obciążenia serwerów przez dużą liczbę klientów
obsługiwanych jednocześnie.
● Testy działania systemu przy dużej ilości danych
Polegają na wczytywaniu bardzo dużej ilości danych w celu sprawdzenia czy zostają
osiągnięte limity powodujące błąd aplikacji. Przykładem takiego testu może być np.
wczytanie kilku tysięcy rekordów z bazy danych w celu utworzenia raportu i
sprawdzenie czy aplikacja działa poprawnie.
● Testy bezpieczeństwa i praw dostępu
Testy te sprawdzają dwa obszary działania aplikacji. Pierwszym jest bezpieczeństwo
na poziomie aplikacji, wliczając w to dostęp do danych oraz funkcji biznesowych.
Drugi to bezpieczeństwo na poziomie systemu czyli np. logowanie do systemu oraz
działanie funkcji zdalnego dostępu.
● Testy dysfunkcji
Testy te sprawdzają jak poważne mogą być straty/szkody spowodowane upadkiem
aplikacji, wynikającym z dysfunkcji sprzętu komputerowego, oprogramowania lub
sieci komputerowej, z możliwą utratą danych lub ich dezintegracją.
● Testy konfiguracji
Sprawdzają sposób działania aplikacji w systemach komputerowych z różną
111
konfiguracją software'ową i hardware'ową. Dobrym przykładem aplikacji
przechodzących takie testy są gry komputerowe, które powinny działać niezależnie od
typu karty graficznej oraz zainstalowanej wersji sterownika grafiki.
● Testy instalacji
Testy te mają na celu sprawdzenie poprawności instalacji oprogramowania, między
innymi w panujących, nietypowych warunkach takich jak np. brak wystarczającej
ilości miejsca na dysku, brak uprawnień użytkownika do utworzenia niektórych
katalogów itp. [5].
9.2. Wykonane testy
Podczas tworzenia projektu wykonane były następujące z wymienionych wcześniej
testów:
● Testy integralności danych
Wykonuje się je wpisując w Microsoft SQL Management Studio zapytanie T-SQL
"DBCC CHECKDB" skierowane do testowanej bazy. W wyniku wyświetlony został
tekst:"CHECKDB found 0 allocation errors and 0 consistency errors in database 'Archiwum'.
DBCC execution completed."
- CHECKDB nie znalazł żadnych błędów w bazie danych 'Archiwum'.
● Testy funkcjonowania
Badana była poprawność działania wszystkich funkcji oraz odporność systemu na
podawanie przez użytkownika niepoprawnych danych wejściowych.
● Testy upływu czasu
Podczas testów tych zasymulowano pracę systemu w roku 2010. Nie tylko
przestawiono zegar na serwerze, ale również określono jakie dane będą wprowadzane
przez firmę.
● Testy interfejsu użytkownika
Sprawdzały poprawność interakcji pomiędzy użytkownikiem a systemem, czy
interfejs graficzny wygląda poprawnie i czy użytkownik może w pełni po nim
112
nawigować.
● Testy bezpieczeństwa i praw dostępu
Testy te polegały na wykonywaniu prób wejścia na podstrony serwisu, do których
użytkownik nie ma prawa dostępu.
● Testy konfiguracji
Podczas projektowania systemu korzystano z klienta Firefox 2.0.0.11. Dopiero po
ukończeniu projektu wykonywane były testy funkcjonowania systemu w innych
przeglądarkach.
9.3. Odnalezione typy błędów
Podczas testów odnaleziono następujące typu błędów:
● błędy w konstrukcji strony www, błędy w kodzie HTML oraz w arkuszach stylów
CSS;
● błędy w kodzie ASP.NET;
● błędy w kodzie programistycznym C# (uruchamianym po stronie serwera);
● błędy w działaniu aplikacji;
● błędy polegające na braku zabezpieczenia aplikacji przed podaniem przez
użytkownika niepoprawnych danych wejściowych;
● błędy w zabezpieczeniach systemu;
● błędy w działaniu aplikacji podczas symulacji pracy w roku 2010;
● błędy w działaniu w programach klienckich (przeglądarkach www).
9.4. Poprawianie błędów
Błędy w konstrukcji strony www
Odnalezione błędy w kodzie HTML i w arkuszach stylów CSS nie miały wpływu na
funkcjonalność aplikacji. Powodowały one jedynie pogorszenie wyglądu strony www.
Interfejs użytkownika wyglądał na niedopracowany, a niektóre elementy strony
nieestetycznie. Błędów tego typu było niewiele. W celu poprawy wyglądu graficznego
interfejsu użytkownika usunięto wszelkie błędy z kodu HTML i CSS. Strona poprawnie
przechodzi walidację systemu testującego składnię W3C (http://validator.w3.org).
113
Błędy w kodzie programistycznym C#, błędy w kodzie ASP.NET
Z pomocą kompilatora programu Visual Studio z łatwością na bieżąco usuwane były
błędy w kodzie programistycznym C# oraz ASP.NET. Wykrywane również były błędy w
osadzonym w C# kodzie SQL. Nie było to trudne ze względu na mała złożoność kodu SQL.
Błędy w działaniu aplikacji
W fazie testów największą liczbę niepoprawionych błędów stanowiły błędy w
działaniu aplikacji oraz błędy polegające na braku zabezpieczenia aplikacji przed podaniem
przez użytkownika niepoprawnych danych.
Usuwanie błędów w funkcjonowaniu aplikacji polegało na testowaniu działania
wszystkich funkcji. Wszelkie funkcje wykorzystywane były jednak zgodnie z przeznaczeniem
(tzn. jeżeli system prosił o wpisanie do pola tekstowego wartości liczbowej to podawana była
wartość liczbowa a nie np. słowo).
W procesie wyszukiwania błędów w funkcjonowaniu aplikacji odnaleziono między
innymi następujące błędy:
● niemożność zalogowania się;
● niepoprawnie przydzielone uprawnienia użytkowników do określonych podstron
(czego efektem była niemożność wejścia na niektóre z nich);
● niepoprawne działanie przycisków;
● niemożność otwarcia wyskakujących okien w Internet Explorerze;
● wiele innych poważnych błędów uniemożliwiających skorzystanie z różnych funkcji
systemu.
Błędy niepoprawnych danych wejściowych
Następnie poprawiane były błędy, polegające na braku zabezpieczenia aplikacji przed
podaniem przez użytkownika niepoprawnych danych. Odnajdowanie tych błędów polegało na
wpisywaniu do pól tekstowych różnych danych. Warianty były następujące:
● wpisywanie bardzo długich ciągów znakowych;
● wpisywanie słów do pól oczekujących na wprowadzenie liczby;
● wpisywanie do pól oczekujących na podanie liczby z ułamkiem znaków innych niż
cyfry i przecinek;
● wpisywanie innej liczby znaków niż oczekiwał system;
● wpisywanie nielogicznych treści (np. przy podawaniu przedziału lat, jako rok
rozpoczynający przedział 2000 a jako rok zamykający przedział 1998).
114
W rezultacie odnaleziono wszystkie czułe punkty systemu i zabezpieczono je tak, aby
w przypadku podania niepoprawnych danych system rozpoznawał błąd w działaniach
użytkownika i wyświetlał użytkownikowi odpowiedni komunikat.
Błędy w zabezpieczeniach systemu
Testy dotyczące zabezpieczeń systemu wykazały następujące błędy:
● użytkownik niezalogowany nie może wejść na stronę pomocy;
● zalogowany użytkownik ograniczony może wejść na niektóre strony, do
których nie ma dostępu.
Z powodu niskiej złożoności naprawa błędów nie była trudnym zadaniem.
Innych błędów w zabezpieczeniach nie znaleziono.
Błędy w działaniu aplikacji podczas symulacji pracy w roku 2010
Podczas symulacji pracy systemu w roku 2010 znaleziono następujące błędy:
Strona wyszukiwania dokumentacji:
● Niemożność wyszukiwania dokumentacji z roku 2009 i 2010 z powodu braku
tych dat na liście rozwijanej.
Rozwiązanie: Zmieniono zawartość listy tak aby zawierała także pozycje 2009 i 2010.
Strona dodawania dokumentacji:
● Niemożność otwarcia tej strony w roku 2009 i każdym kolejnym.
Problem polegał na tym, że system automatycznie wybiera na liście rozwijanej
aktualny rok. Pojawiał się błąd aplikacji, ponieważ lista zawierała tylko przedział lat
1986-2008.
Rozwiązanie: Zmieniono zawartość listy tak aby zawierała także wartości "2009" i
"2010".
Strona edycji dokumentacji:
● Podczas otwierania do edycji dokumentacji z 2009 roku lub nowszej, pojawiał
115
się błąd na stronie uniemożliwiający skorygowanie danych dokumentacji.
Problem polegał na tym, że system automatycznie wybiera na liście rozwijanej rok
przypisany edytowanej dokumentacji. Pojawiał się błąd aplikacji, ponieważ lista zawierała
tylko przedział lat 1986-2008.
Rozwiązanie: Zmieniono zawartość listy tak aby zawierała także wartości "2009" i
"2010".
Inne informacje:
Ilość dokumentacji opracowanych przez firmę w roku 2010 na pewno nie przekroczy
maksymalnej liczby dokumentacji obsługiwanej w tej chwili przez formularze systemu
Liczba ta wynosi 99 999.
Błędy w działaniu w innych klientach niż Firefox
Podczas testów otwierania aplikacji internetowej na komputerach klienckich z różną
konfiguracją okazało się że występują problemy podczas korzystania z WellDone przy użyciu
przeglądarki Microsoft Internet Explorer 6.
Wykryte błędy w działaniu były spowodowane źle obsługiwanymi przez przeglądarkę
Internet Explorer 6 elementami kodu HTML, CSS, JavaScript bądź plików graficznych PNG.
Większość tych błędów powodowała niepoprawne wyświetlanie się strony. Tylko
nieliczne błędy uniemożliwiały poprawne korzystanie z systemu. Błędy w interpretacji przez
IE 6 kodu strony uniemożliwiały otwarcie na stronach dodawania i edycji dokumentacji okien
"Dodawanie miejscowości" oraz "Dodawanie ulicy".
W celu poprawienia wszystkich powyższych błędów zastosowano alternatywne
rozwiązania dające jednak takie same efekty.
Działanie aplikacji zostało sprawdzone w następujących przeglądarkach:
● Firefox 2
● Firefox 3
● Internet Explorer 6
● Internet Explorer 7
● Opera 9
● Safari 3
116
10. Możliwości rozbudowy systemu
Opracowany system posiada duże możliwości rozbudowy co jest bardzo cenne z
punktu widzenia firmy, ponieważ bardzo prawdopodobne jest, że w pewnym momencie firma
będzie chciała zainwestować w poprawienie lub poszerzenie funkcjonalności systemu. Już
pojawiły się nowe pomysły na kolejne funkcje systemu.
10.1. Łatwość modyfikacji wyglądu stron internetowych
Strony internetowe (w tym też aplikacje internetowe) cechuje na ogół łatwość
rozbudowy oraz łatwość modyfikacji wyglądu. Zmiany kosmetyczne (typu ustawienie innych
kolorów dla wybranych elementów) zajmuje w dzisiejszych czasach kilka minut. Nie tylko
drobne zmiany są łatwe do wykonania - modyfikacja ogólnego wyglądu strony jest łatwa i
szybka. Co najważniejsze wszystkie wprowadzone zmiany mają momentalny wpływ na cały
wygląd systemu i są od razu postrzegane przez wszystkich użytkowników Dzieje się tak,
ponieważ są one zarządzane centralnie na serwerze. Jest to wartościowa cecha stron
internetowych.
10.2. Centralne zarządzanie
Kolejną wielką zaletą wykorzystanej technologii jest centralne zarządzanie. W
przypadku aplikacji webowych, zmiany wprowadzane są jedynie w jednym miejscu –
bezpośrednio na serwerze. Każdy użytkownik łączący się z serwerem korzysta od razu z
uaktualnionej wersji oprogramowania. Program występuje tylko w jednym egzemplarzu. Jest
nim zainstalowana na serwerze aplikacja, z której korzystają użytkownicy logujący się do
systemu.
10.3. Dokładnie opisany kod programu
Kod w języku C# jest bardzo dokładnie opisany i skomentowany. Nie jest to bez
znaczenia. Nieopisany kod nie będzie zrozumiały nawet dla programisty, który go napisał,
zwłaszcza po upływie kilku miesięcy. W takim momencie praca z nieopisanym kodem może
być niezwykle męcząca dla programisty. Dobrze skomentowany kod programu umożliwi
i ułatwi efektywną rozbudowę aplikacji w przyszłości, dzięki czemu rozbudową mógłby zająć
się nawet programista, który danej aplikacji nie napisał.
117
11. Podsumowanie
Wytworzone oprogramowanie spełnia wszystkie wymagania i założenia etapu
projektowego. Z sukcesem osiągnięty został cel pracy - utworzony został projekt
i implementacja solidnej aplikacji do zarządzania archiwum, która potrzebna była firmie
klienckiej Zakład Badań Geotechnicznych Geotest.
Powstała aplikacja ma następujące cechy:
● spełnia wymogi postawione przez firmę;
● nadaje się do zarządzania archiwum firmy;
● jest łatwa w obsłudze;
● jest stabilna;
● jest szybka.
Firma zamawiająca oprogramowanie uznała je za spełniające wszystkie oczekiwania.
W związku z tym oprogramowanie to zostało zainstalowane na serwerze w siedzibie firmy i
od marca 2008 pracownicy mogą korzystać z opracowanego przez autora systemu
archiwizacji.
Wytworzona aplikacja jest wygodna, ponieważ umożliwia łatwe dodawanie
dokumentacji oraz skuteczne ich odnajdywanie. Autor pracy ma nadzieję na przyszłe
rozwijanie aplikacji i poszerzanie jej funkcjonalności.
118
12. Wykaz literatury
1. C. Darie, Z. Ruvalcaba, ASP.NET 2.0, 2007, Helion
2. J. Liberty, Programowanie C#, 2006, Helion
3. S. Saha Bagui, R. Walsh Earp, SQL dla SQL Server 2005, 2006, Helion
4. P. Stevens, UML. Inżynieria oprogramowania. Wydanie II, 2007, Helion
5. www.wikipedia.org
119
13. Załączniki
● Płyta DVD zawierająca wszelkie pliki projektu oraz instrukcję opisującą jak
uruchomić program. Opis zawartości nośnika znajduje się w pliku ReadMe.txt
położonym w katalogu głównym płyty.
● Licencje zamieszczonego na płycie oprogramowania:
1. Microsoft Windows Server 2003 oraz Microsoft Virtual PC 2004 –
oprogramowanie pochodzi z uczelni i jest przeznaczone wyłącznie dla jej
studentów wyłącznie do użytku niekomercyjnego.
2. Microsoft Visual Web Developer 2008 Express Edition oraz Microsoft SQL
Server 2005 Express Edition – oprogramowanie to pochodzi ze strony
www.microsoft.com/express i jest darmowym oprogramowaniem, które może
być wykorzystywane komercyjnie.
120