Paweł Traczyński - praca dyplomowa

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.


1. Użytkownik wybiera w menu opcję "Wyloguj"

2. Użytkownik zostaje wylogowany.

3. System wyświetla informacje potwierdzającą poprawne wylogowanie.


Brak.

Przypadek użycia: 2.1 Przeglądanie listy wszystkich dokumentacji



Oczekiwane wyniki: Wyświetlona zostanie lista wszystkich dokumentacji.

20


1. Użytkownik wybiera w menu opcję "Lista".

2. System wyświetla stronę z listą wszystkich dokumentacji.


#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


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.


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.


#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



Oczekiwane wyniki: Wyświetlone zostaną dokumentacje spełniające kryteria

wyszukiwania.


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


#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.


braku połączenia.

Przypadek użycia: 2.4 Przechodzenie pomiędzy stronami wyników



jest na stronie Lista wszystkich dokumentacji lub Wyszukiwanie dokumentacji (z

wyświetlonymi wynikami wyszukiwania).

Oczekiwane wyniki: Wyświetlona zostanie wybrana strona wyników.

22


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.


Brak.

Przypadek użycia: 2.5 Sortowanie wyświetlanych danych





Oczekiwane wyniki: Wyświetlane dane zostaną posortowane alfabetycznie według

wartości z wybranej kolumny.


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.


#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





Oczekiwane wyniki: Wyświetlona zostanie strona z danymi szczegółowymi wybranej

dokumentacji.

23


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.


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.


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.


#1. W punkcie 6 użytkownik nie podał wszystkich wymaganych danych. System

wyświetla komunikat informujący użytkownika o brakujących danych.

24



#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.


braku połączenia.

Przypadek użycia: 3.2 Dodawanie nowej miejscowości



zalogowany. Użytkownik jest na stronie Dodawanie dokumentacji lub Edycja dokumentacji.

Oczekiwane wyniki: Do systemu dodana zostanie nowa miejscowość.


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".


5. System zapisuje w bazie danych nazwę nowej miejscowości.


#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.


braku połączenia.

Przypadek użycia: 3.3 Dodawanie nowej ulicy


25



Oczekiwane wyniki: Do systemu dodana zostanie nowa ulica.


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".



6. System zapisuje w bazie danych nazwę nowej ulicy.



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.


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).


braku połączenia.

Przypadek użycia: 3.4 Modyfikacja istniejącej dokumentacji



zalogowany.

Oczekiwane wyniki: Dane na temat wybranej dokumentacji zostaną zmodyfikowane.


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.



10. Zmienione dane zostają zapisane w bazie danych.


#1. W punkcie 7 użytkownik usunął dane z pól wymaganych. System wyświetla

komunikat informujący użytkownika o brakujących danych.



#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.


braku połączenia.

Przypadek użycia: 3.5 Modyfikacja nazwy miejscowości




Oczekiwane wyniki: Nazwa wybranej miejscowości zostanie zmodyfikowana.


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".


7. System zapisuje w bazie danych zmienioną nazwę miejscowości.



obowiązku podania nazwy miejscowości.


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.


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




Oczekiwane wyniki: Nazwa wybranej ulicy zostanie zmodyfikowana.


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".



8. System zapisuje w bazie danych zmienioną nazwę ulicy.

28



obowiązku podania nazwy ulicy.


obowiązku podania poprawionej nazwy miejscowości.


informujący o charakterze błędu.


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.


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.


1. Użytkownik wybiera w menu strony opcję "Pomoc"

2. Wyświetlona zostaje strona pomocy.


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)


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.



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


IDTypu - wpis w tej kolumnie umożliwia skojarzenie danego rekordu z jednym

wpisem w tabeli Typy.

Typ danych: int


46

Data - określa moment złożenia gotowej dokumentacji.

Typ danych: datetime


IDStrefy - wpis w tej kolumnie umożliwia skojarzenie danego rekordu z jednym

wpisem w tabeli Strefy.

Typ danych: int


IDMiejscowosci - każdy wpis w tej tabeli musi być skojarzony z jedną z miejscowości

z tabeli Miejscowosci.

Typ danych: int


IDUlicy - każdy wpis w tej tabeli musi być skojarzony z jedną z ulic z tabeli Ulice.

Typ danych: int


AdresDodatkowe - pole to przechowuje ewentualne dodatkowe dane adresowe, bądź

związane z dojazdem.


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


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)


Geologia - pole to przechowuje dane o geologii gruntów na terenie badań.


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


IDBadaniaSpec - wpis w tej kolumnie umożliwia skojarzenie danego rekordu z

jednym wpisem w tabeli BadaniaSpecjalistyczne.

Typ danych: int


WodaNa1 - wpis w tej kolumnie określa poziom, na którym występuje woda

gruntowa.

Typ danych: nvarchar(50) - potrzebna możliwość wpisywania tekstu


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


Profil1 - wpis w tej kolumnie określa, jaki był profil geotechniczny gruntów na

zbadanej działce.



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.



Rys. 7.5. Projekt tabeli Dokumentacje [P. Traczyński].

49

Uwagi - kolumna ta to miejsce na wszelkie inne informacje o charakterze ogólnym.



Haslo - kolumna ta przechowuje hasło, czyli słowo które może np. łączyć ze sobą

jakąś grupę prac zleconych przez jednego inwestora.



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


Miejscowosc - wpis w tej kolumnie określa nazwę miejscowości. Zawartość tej tabeli

może być modyfikowana z poziomu aplikacji internetowej.



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


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.



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 - wpis w tej kolumnie określa rodzaj typu dokumentacji. Aktualnie są to wartości:

geotechniczna, wstępna, geologiczna, zanieczyszczenia oraz inna.



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.


Ulica - wpis w tej kolumnie określa nazwę ulicy. Zawartość tej tabeli może być

modyfikowana z poziomu aplikacji internetowej.



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ń.


65


● 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.



● 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;



● 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


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


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


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


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


● 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:


● 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"


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:



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"


sprawdza , czy ulica, której nazwę chce zmienić, znajduje się w bazie:


● 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


● 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 Pomocy - Help.aspx


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";


● 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.


● 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


● 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

http://validator.w3.org/

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

http://www.microsoft.com/express

Paweł Traczyński - praca dyplomowa

Documents

Transcript of Paweł Traczyński - praca dyplomowa