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.

Moduł dla pracowników wypożyczalni 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ł WEB dla klientów Moduł dla pracowników wypożyczalni Baza danych Moduł Rescue

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. Najważniejsze cechy języka UML, które stały się nieocenione podczas mojej pracy: Język modelowania wizualnego Łatwy do zrozumienia Pozwala na efektywną wymianę informacji Pozwala na standaryzację

Projekt systemu W 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 systemu Przykł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. Budowę diagramów poprzedziło określenie przeze mnie występujących w systemie klas analitycznych. 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 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 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. Ilość diagramów: 42

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. 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. Ilość diagramów: 61

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

Implementacja W 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. Opisałem czym jest środowisko CLR oferowane przez firmę Microsoft. Przedstawiłem łatwość łączenia technologii .NET z bazą danych MS-SQL za pomocą grupy klas – ADO.NET, udostępniającą architekturę bezpołączeniową. 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 Opis przykładowego okna 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. 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”.

Instalacja i Testowanie Systemu Zaimplementowałem i opisałem instalator modułu głównego 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. 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ę.