Projekt i implementacja systemu do obsługi wypożyczalni przyczep

i samochodów kempingowych

Cel mojej Pracy

Celem mojej pracy był projekt oraz implementacja systemu dla wypożyczalni przyczep i samochodów kempingowych.

Ogólny koncept projektowy

Założyłem, iż projektowany przeze mnie system składać się będzie z trzech niezależnych od siebie modułów, oraz bazy danych.

Moduł dla pracowników wypożyczalni

Moduł Rescue

Moduł WEB dla klientów

Baza danych

Określenie cyklu życia oprogramowania

W swoim projekcie zdecydowałem się na zastosowanie modelu kaskadowego jako procesu tworzenia oprogramowania. Do takiej decyzji skłoniły mnie dobrze zdefiniowane wymagania już na samym początku tworzenia oprogramowania, świadomość, iż nie będą one zmieniane, a także prostota w stosowaniu tego procesu.

Postawione zadania

Analiza wymagań stawianych na system

Projekt systemu

Projekt bazy danych

Projekt składowych systemu współpracujących z bazą danych

Implementacja systemu

Testowanie

Analiza wymagań

Ustaliłem dziedzinę problemu, w której szczegółowo opisałem otoczenie w którym system będzie funkcjonować, jak i zakres działania systemu.

Dokonałem dokładnego opisu specyfikacji funkcjonalnej systemu, z podziałem na każdy moduł.

Projekt systemu

Podczas pracy nad projektem systemu wykorzystałem język UML (ang. Unified Modeling Language – zunifikowany język modelowania), w którym stworzyłem diagramy wspomagające mnie podczas badania systemu pod kątem poprawności działania, a także ułatwiające proces implementacji.

•Język modelowania wizualnego

•Łatwy do zrozumienia

•Pozwala na efektywną wymianę informacji

•Pozwala na standaryzację

Najważniejsze cechy języka UML, które stały się nieocenione podczas mojej pracy:

Projekt systemuW pierwszym kroku projektowania systemu postanowiłem określić listę aktorów wchodzących w interakcję z nim.

Ze względu na swoją specyfikę – modułowość – uznałem, że należy wyszczególnić aktorów dla każdego modułu, bowiem każdy z nich jest unikalny, niezależny i mogący być użytkowany przez wyszczególnioną grupę docelową.

Na poniższym rysunku przedstawiłem diagram aktorów modułu dla pracowników, stanowiącego najważniejszą część z punktu widzenia zarządzania systemem.

Projekt systemu

W kolejnym kroku, dzięki określeniu wstępnie wymagań funkcjonalnych, byłem w stanie określić przypadki użycia dla każdego modułu składającego się na system.

Przypadki użycia są to konstrukcje, które pomogły mi w określeniu jak system ma być używany

Przypadki użycia określiłem oddzielnie dla każdego modułu systemu.

Ilość przypadków użycia skłoniła mnie również do podziału ich na poszczególne grupy, w celu lepszego zobrazowania diagramów.

Każdy przypadek użycia dokładnie opisałem i ze względu na obszerność dokumentu, umieściłem w załączniku do pracy.

Ilość diagramów: 11

Ilość opisanych przypadków użycia: 42

Projekt systemuPrzykład diagramu przypadków użycia, oraz opisu dla jednego z nich.

UC 1.4 Dodanie miejscowości do systemu

Warunki wstępne : 1. Użytkownik uzyskał dostęp do systemu

Oczekiwane wyniki : Miejscowość zostaje dodana do bazy danych systemu

Przebieg podstawowy : 1. Użytkownik w oknie głównym aplikacji z menu górnego wybiera „Klienci”, a następnie „ Dodaj” (tą samą operację można wykonać z okna służącego do modyfikowania klienta - UC 3.2 Modyfikuj dane klienta w systemie). 2. W oknie służącym do dodawania klienta znajduje się wydzielony sektor o nazwie „Dodawanie miasta” w którym należy podać Nazwę miejscowości. 3. Użytkownik potwierdza chęć dodania nowej miejscowości za pomocą przycisku „Dodaj” znajdującym się w tym samym sektorze – „Dodawanie miasta”.

Przebiegi alternatywne : 1. Podana nazwa miasta istnieje już w systemie, następuje wyświetlenie stosownej informacji o zaistniałej sytuacji.

Punkty rozszerzające : brak

Zawierane przypadki użycia : UC 2.1 Uzyskanie dostępu do systemu

Projekt systemu

Następnie podczas projektowania zająłem się diagramami analitycznymi.

W przypadku mojej aplikacji, która jest typu bazodanowego, postanowiłem potraktować procedury składowane, jako obiekty, do których odwołują się inne obiekty pochodzące z poszczególnych modułów systemu, stworzonych przy pomocy języków wysokiego poziomu

Dzięki tym diagramom mogłem zobrazować sposób, w jaki komunikują się obiekty między sobą, a także kolejność wysyłanych komunikatów dla poszczególnych operacji wykonywanych w systemie

Ilość diagramów: 42

Budowane modele stanowiły dla mnie rozszerzenie opisu przypadków użycia. Za pomocą tych modeli chciałem zaprezentować już nie tylko, co system ma robić, ale jak on to robi.

Budowę diagramów poprzedziło określenie przeze mnie występujących w systemie klas analitycznych.

Projekt systemu

Przykład diagramu analitycznego, wraz z opisem.

1. Moduł główny po uruchomieniu powołuje do życia obiekt OknoUzyskanieDostepu oznaczony jako <<boundary>>. Zadaniem Aktora w celu wejścia do systemu jest podanie w tym oknie hasła dostępowego lub hasła secPasswd znanego administratorowi systemu i zaakceptowanie rozpoczęcia procedury logowania do systemu.

2. W drugim kroku podane hasło trafia do obiektu MenedzerZarzadzaniaHaslami oznaczonego jako <<control>> odpowiedzialnego za operacje związane z hasłami w zarejestrowanymi w systemie.

3. W kroku oznaczonym nr 3 MenedzerZarzadzniaHaslami pobiera hasła z obiektu Hasla oznaczonego, jako <<entity>> który w tym przypadku jest strukturą fizyczną w postaci pliku konfiguracyjnego zapisanego na lokalnym komputerze gdzie zainstalowany został moduł główny, oraz dokonuje weryfikacji poprawności wpisanego hasła przez aktora systemu.

4. W kroku nr 4, po poprawnej weryfikacji hasła, następuje powołanie do życia obiektu oznaczonego jako <<boundary>> - OknoGlowne, które oznacza dla aktora poprawnie zakończoną operację logowania do systemu. MenedzerZarzadzaniaHaslami zamyka połączenie z fizyczną strukturą umiejscowioną na dysku twardym. Aktor uzyskuje możliwość pracy w systemie.

Projekt systemu

W ostatnim kroku projektowania modułów systemu postanowiłem zająć się diagramami sekwencji.

Ilość diagramów: 61

Cel, jaki przyświecał mi podczas projektowania modeli sekwencji było zaprezentowanie, w zależności od czasu, przebiegu komunikowania się jednego obiektu z drugim.

W projektowanym przeze mnie systemie modele sekwencji stanowiły najniższy poziom abstrakcji.

Projektując diagramy postarałem się ukazać już nie tyle obiekty utworzone z abstrakcyjnych klas reprezentujących np. grupę procedur składowanych, czy też tabele bazy danych, ale faktyczne obiekty reprezentujące konkretne procedury składowane, czy też konkretne tabele w bazie danych z zachowaniem nazewnictwa zgodnego w fazie implementacji systemu.

Projekt systemu

Przykład diagramu sekwencji

Projekt systemu

Na podstawie wcześniejszych diagramów zaprojektowałem serce mojego systemu – bazę danych.

Po zaprojektowaniu poszczególnych tabel, stworzyłem opis każdej z nich, oraz wszystkich pól występujących w tabelach.

Opisałem działanie, oraz parametry wejściowe i wyjściowe procedur składowanych systemu.

Technologia ASP.NET w której utworzyłem moduł WEB, stworzyła swoją własną strukturę bazy danych. Dokonałem scalenia mojej bazy, oraz bazy technologii ASP.NET, za pomocą tabeli pośredniczącej, w jedną spójną bazę danych systemu.

Usunąłem wszystkie relacje wiele do wielu za pomocą tabel pośrednich.

Projekt systemu

Projekt bazy danych (bez części ASP.NET)

Projekt systemu

Projekt bazy danych (ASP.NET)

Implementacja

Posiadając dokładną dokumentację przystąpiłem do implementacji systemu.

W pierwszym kroku zaimplementowałem bazę danych systemu.

Opisałem w kilku zdaniach środowisko w którym postanowiłem zaimplementować bazę danych – Microsoft SQL Server 2005.

Za pomocą zrzutów ekranowych zaprezentowałem kolejno proces tworzenia, za pomocą SQL Server Management Studio, bazy danych, przykładowej tabeli, pól występujących w tabelach, diagramu bazy danych, relacji, oraz przykładowej procedury składowanej rezydującej w bazie danych.

Implementacja

ImplementacjaW kolejnym kroku zaimplementowałem elementy funkcjonalne systemu.

Zacytowałem czym jest język C#, w którym powstał mój system, słowami pochodzącymi z dokumentacji firmy Microsoft.

Przedstawiłem łatwość łączenia technologii .NET z bazą danych MS-SQL za pomocą grupy klas – ADO.NET, udostępniającą architekturę bezpołączeniową.

Opisałem czym jest środowisko CLR oferowane przez firmę Microsoft.

W kilku zdaniach opisałem technologię ASP.NET, w której powstał moduł WEB mojego systemu, umożliwiającą tworzenie dynamicznych stron internetowych.

Dla każdego modułu oddzielnie opisałem każdą formatkę, jej funkcjonalność, komponenty użyte do jej budowy, oraz obsługę zdarzeń występujących podczas wyświetlania formatki.

Liczba opisanych formatek: 29

Implementacja

W formatce zaimplementowałem również obsługę zdarzenia kliknięcia na przycisku, powodujące sprawdzenie poprawności wpisanego hasła w polu tekstowym i utworzenie obiektu reprezentującego okno główne aplikacji. Operacja związana z uzyskaniem dostępu do systemu została dokładnie zaprezentowana na diagramie analitycznym dostępnym w załączniku nr 2 w sekcji „Uzyskanie dostępu do systemu”, a także diagramie sekwencji dostępnym w załączniku nr 3 w sekcji operacje na oknach dla modułu głównego – „Uzyskanie dostępu do systemu”.

Jest to pierwsze okno widoczne zaraz po uruchomieniu się modułu dla pracowników firmy.

Składa się ono z trzech komponentów typu etykieta, jednego pola tekstowego, i jednego przycisku.

Opis przykładowego okna

Instalacja i Testowanie Systemu

Za pomocą zrzutów ekranowych zaprezentowałem wszystkie zmiany które zachodzą za sprawą instalatora – utworzenie plików aplikacji, plików konfiguracyjnych, zmiany w rejestrze systemowym, skróty w menu start, a także pliku log utworzonego w czasie instalacji.

Przeprowadziłem testy na każdym module z osobna, wyniki przedstawiłem w postaci słownego opisu testu, oraz zrzutów ekranowych.

Zaimplementowałem i opisałem instalator modułu głównego systemu.

Za pomocą zrzutów ekranowych i krótkiego opisu zaprezentowałem sposób usunięcia modułu głównego.

Dodatkowo moduł WEB poddałem testowi walidacji algorytmem SGML. Test został zdany bezbłędnie.

Instalacja i Testowanie Systemu

Przykłady zrzutów ekranowych

Podsumowanie i wnioski …•Wstępne założenia w pełni zrealizowane

•Działający system

•Odporny na błędy użytkownika

•Bezpieczny

•Szybki w działaniu

•Składający się z modułów

… ale system …

•Nieprzenaszalny – system bazodanowy z góry ustalony i nie podlegający zmianie

•Współpracujący jedynie z systemami firmy Microsoft (i też nie ze wszystkimi)

Osiągnięcie celu …

Dziękuję za uwagę.