1. Ogólny opis systemu

Niniejszy projekt dotyczy opracowania systemu do obsługi wypożyczalnią DVD Platforma zostanie wdrożona w wypożyczalni „FajneFilmy”, która znajduje się w centrum Warszawy. Wypożyczalnia cieszy się dużą popularnością wśród klientów, ponieważ oferuje najnowsze filmy i stara się na bieżąco zakupywać nowości. Niemniej jednak ideą wypożyczalni jest niezapominanie o kultowych filmach. Zatem każdy widz odwiedzający wypożyczalnie powinien znaleźć coś dla siebie.

Właściciele wypożyczalni zgłosili się z potrzebą zaprojektowania takiego systemu. Idea powstania takiego oprogramowania wynikła z błędów i pomyłek personelu. Dotychczas pracujący w sieci wypożyczalni zapisywali wszystkie dane w arkuszach Excel. Niestety ich jakość oraz struktura nie ułatwiały pracy i zdarzało się, że personel wprowadzał niepoprawnie dane lub zapomniał aktualizować informacji tam zawartych.

Dzięki nowo wdrożonemu oprogramowaniu właściciele sieci wypożyczalni mają nadzieję, iż uda się naprawić te problemy i znacznie usprawnić działanie wypożyczalni. Dlatego też celem niniejszego projektu jest opracowanie systemu, który usprawni działanie wypożyczalni video oraz będzie czuwał nad poprawnością transakcji przeprowadzanych w wypożyczalni filmów DVD.

Oprogramowanie powinno cechować się kilkoma funkcjami takimi jak:

• możliwość przechowywania informacji o klientach wypożyczających filmy DVD,

• możliwość rejestrowania wypożyczeni,

• możliwość przechowywania informacji o stanie magazynowym filmów,

• dokonanie klasyfikacji filmów wg odpowiednich kategorii tematycznych,

• zorientowanie na przyszłą rozbudowę,

• możliwość wystawiania rachunków dla klientów wypożyczających filmy,

• tworzenie statystyk związanych z analizą, które filmy są najpopularniejsze,

• tworzenie raportów odnoszące się do wypożyczeni w danym okresie czasu,

• możliwość wysyłania smsów/e-maili do klientów wypożyczalni,

• możliwość tworzenia i przywracania kopii zapasowych danych.

2. Analiza dziedziny

W tab. 1 zaprezentowano wyodrębnione klasy systemu. Zaprezentowano spis atrybutów oraz dokonano opisu.

Tabela . Wyodrębnione klasy systemu.

Klasa	Atrybuty	Opis
Osoba (abstrakcyjna)*	Adres zamieszkania, adres e-mail, imię, nazwisko, pesel, telefon	Niniejsza klasa reprezentuje osoby w systemie. Jest klasą abstrakcyjną – nie przewiduje się tworzenia obiektu klasy Osoba. Innymi słowy inne klasy (np. klient będą dziedziczyć po klasie Osoba).
Klient	Adres zamieszkania, adres e-mail, imię, nazwisko, pesel, telefon	Klient wypożyczalni DVD. Klasa dziedzicząca po klasie abstrakcyjnej Osoba.
Pracownik	Adres zamieszkania, adres e-mail, imię, nazwisko, pesel, telefon, hasło, login	Pracownik wypożyczalni dziedziczący po klasie Osoba. Zawiera również oprócz danych osobowych oraz teleadresowych informacje o loginie oraz haśle do systemu informatycznego.
Rachunek	Kwota, data wystawienia, wypożyczone filmy, pracownik wystawiający, data rachunku	Rachunek wystawiony przez danego pracownika dla danego klienta i jego listy zamówień. Rachunek musi zawierać również takie informacje jak kwota jaką zapłacił klient oraz datę wystawienia.
Filmy	Tytuł, opis, kategoria, rok produkcji, opis	Filmy dostępne w wypożyczalni DVD. Posiadają określoną kategorię, tytuł, rok produkcji oraz opis.
Kategoria	Nazwa kategorii filmu	Kategoria filmu
Wypożyczenie	Klient, film, data wypożyczenia, data zwrotu	Klasa przechowująca informacja o danym wypożyczeniu. Wypożyczenie przechowuje informacje o kliencie, nazwie filmu oraz dacie wypożyczenia i zwrocie filmu.
Stan magazynu	Film, ilość egzemplarzy w magazynie	Encja przechowująca informacje o stanach magazynowych wypożyczalni DVD.

Diagram klas*¹ został zaprezentowany na rys.1.

Rysunek . Diagram klas.

3. Specyfikacja wymagań

Specyfikacja wymagań stanowi opis założeń jaki powinien realizować projektowany system informatyczny do obsługi wypożyczalni DVD. Początkowo wyszczególniono założenia funkcjonalne oraz niefunkcjonalne systemu. Odpowiednio – założenia funkcjonalne zostały zaprezentowane w tabeli 2, natomiast założenia niefunkcjonalne przedstawiono w tabeli 3.

Tabela . Założenia funkcjonalne systemu.

Założenia funkcjonalne	Opis
Oprogramowanie powinno uwzględniać konta pracowników	Innymi słowy każdy pracownik powinien posiadać osobne konto do systemu tak by na przykład możliwym było zweryfikowanie, który pracownik wystawił dany rachunek.
System musi mieć możliwość rejestrowania wypożyczeni oraz zwrotów egzemplarzy filmów	Jest to jedna z podstawowych funkcjonalności projektowanego systemu informatycznego wynikająca z działalności wypożyczalni. Pracownicy muszą mieć możliwość zarejestrowania wypożyczenia filmu w systemie oraz dodania informacji o zwrocie danego elementu.
Oprogramowanie powinno umożliwiać wystawianie rachunków/faktur	Za pomocą systemu informatycznego pracownicy muszą mieć możliwość wystawienia rachunków(faktur).
System musi mieć możliwość przeglądania raportów związanych z przychodami, terminami zwrotów, ilości wypożyczeni danego filmu	Oprogramowanie powinno generować raporty, z których będzie można jednoznacznie stwierdzić, który miesiąc był najbardziej dochodowy w przeciągu roku lub jakie filmy wypożyczane są najczęściej.
System powinien mieć możliwość dodawania oraz usuwania filmów	Inaczej ujmując oprogramowanie musi mieć możliwość przechowywania danych o filmach znajdujących się w wypożyczalni.
Oprogramowanie powinno mieć możliwość dodawania oraz usuwania danych klientów wypożyczalni DVD	System musi przechowywać informacje o klientach wypożyczalni.
Oprogramowanie powinno umożliwiać aktualizacje stanów magazynowych	Inaczej ujmując oprogramowanie powinno w sposób jednoznaczny wskazywać pracownikom ile danych egzemplarzy danego filmu znajduje się obecnie w wypożyczalni.

Tabela . Założenia niefunkcjonalne.

Założenia niefunkcjonalne	Opis
Oprogramowanie powinno mieć intuicyjny interfejs użytkownika	Innymi słowy każdy przeciętny użytkownik komputera powinien poradzić sobie z obsługą systemu. Jego obsługa nie powinna być skomplikowana, a interfejs nie powinien się różnić od przyjętych standardów stosowanych w tego typu systemach. Ważnym jest również stonowana grafika w interfejsie. Należy unikać jaskrawej kolorystyki.
Oprogramowanie powinno zostać opracowane w taki sposób aby w przyszłości można było aktualizować system.	Innymi słowy jedną z myśli podczas wytwarzania oprogramowania musi być idea tego, że system będzie w przyszłości rozwijany. Nie jest określone w jakim kierunku podąży rozwój. Niemniej jednak wytworzone oprogramowanie musi być napisane tak by w łatwy i przyjazny sposób można było dalej je rozwijać. Wytworzony system musi zatem zawierać kod wysokiej jakości o odpowiedniej czytelności, powinny zostać zastosowane wszystkie dobre praktyki stosowane w procesie wytwarzania oprogramowania.

Rysunek . Diagram przypadków użycia.

PU : Dodaj film

Aktorzy: Pracownik

Zdarzenie wyzwalające: zakup całkowicie nowego egzemplarzu filmu

Warunki wstępne: pracownik musi być zalogowany w systemie

Warunki końcowe dla sukcesu: dodane dane filmu nie mogą być nieunikalne, film nie może być dostępny w wypożyczalni

Warunki końcowe dla niepowodzenia: dany film jest już w wypożyczalni.

Scenariusz główny:

1. Zostaje zakupiony nowy egzemplarz filmu, który nie był dostępny w wypożyczalni.

2. Pracownik wprowadza podstawowe dane – tytuł, rok produkcji oraz opis.

3. Dane zostają wprowadzone do bazy.

4. Użytkownik otrzymuje potwierdzenie pozytywnego zakończenia transakcji.

PU : Usuń film

Aktorzy: Pracownik

Zdarzenie wyzwalające: usunięcie wszystkich egzemplarzy danego filmu z wypożyczalni

Warunki wstępne: pracownik musi być zalogowany w systemie

Warunki końcowe dla sukcesu: film musi istnieć już w bazie danych

Warunki końcowe dla niepowodzenia: dany film nie jest wprowadzony do bazy

Scenariusz główny:

1. Zdecydowano się na usunięcie danego filmu z oferty wypożyczalni.

2. Pracownik wyszukuje dany film w bazie danych

3. Pracownik usuwa film.

4. Użytkownik otrzymuje potwierdzenie pozytywnego zakończenia transakcji.

PU : Generuj raporty

Aktorzy: Pracownik

Zdarzenie wyzwalające: usunięcie wszystkich egzemplarzy danego filmu z wypożyczalni

Warunki wstępne: baza danych powinna zawierać dane, pracownik musi być zalogowany w systemie

Warunki końcowe dla sukcesu: film musi istnieć już w bazie danych

Warunki końcowe dla niepowodzenia: dane w bazie są niespójne (informacje nie odzwierciedlają stanu rzeczywistego, błędy w trakcie wprowadzania danych)

Scenariusz główny:

1. Użytkownik wybiera jeden z rodzajów raportów – sprzedażowy w danym okresie, popularności danego filmu etc.

2. Użytkownik wybiera wygenerowanie raportu do pliku xls lub pdf.

3. Plik jest zapisywany na lokalnym dysku użytkownika.

PU : Dodaj klienta

Aktorzy: Pracownik

Zdarzenie wyzwalające: pojawienie się nowego klienta w wypożyczalni

Warunki wstępne: pracownik musi być zalogowany w systemie

Warunki końcowe dla sukcesu: klient nie może być zarejestrowany w systemie wypożyczalni

Warunki końcowe dla niepowodzenia: dany klient został już zarejestrowany w systemie.

Scenariusz główny:

1. Nowy klient dokonuje swojego pierwszego wypożyczenia.

2. Pracownik podczas wprowadzania wypożyczenia wyszukuje klienta wg jego danych.

3. W systemie nie ma rekordu o danym kliencie, zatem pracownik wprowadza jego dane.

PU : Usuń klienta

Aktorzy: Pracownik

Zdarzenie wyzwalające: pojawienie się nowego klienta w wypożyczalni

Warunki wstępne: pracownik musi być zalogowany w systemie

Warunki końcowe dla sukcesu: klient musi być zarejestrowany w systemie

Warunki końcowe dla niepowodzenia: rekord o danych klienta nie istnieje w systemie

Scenariusz główny:

1. Wypożyczalnia decyduje się na usunięcie danych klienta na jego prośbę lub z innych powodów.

2. Pracownik przeglądając dane z tabeli o klientach wyszukuje przy wykorzystaniu filtrów odpowiedni rekord.

3. Pracownik usuwa danego klienta.

PU : Aktualizuj stany magazynowe

Aktorzy: Pracownik

Zdarzenie wyzwalające: pojawienie się nowego egzemplarza/zagubienie egzemplarzu/kradzież

Warunki wstępne: pracownik musi być zalogowany w systemie

Warunki końcowe dla sukcesu: film musi istnieć w bazie

Warunki końcowe dla niepowodzenia: rekord o danych filmu nie istnieje w bazie danych

Scenariusz główny:

1. Pracownik zostaje poinformowany o aktualizacji danego egzemplarzu na stanie wypożyczalnia.

2. Pracownik wprowadza nowy stan (zwiększając bądź też zmniejszając liczbę egzemplarzy danego filmu).

PU : Wypożycz film

Aktorzy: Pracownik, klient

Zdarzenie wyzwalające: wypożyczenie filmu prze klienta

Warunki wstępne: pracownik musi być zalogowany w systemie

Warunki końcowe dla sukcesu: dane o filmie oraz kliencie muszą znajdować się w bazie danych, egzemplarz musi być dostępny w wypożyczalni

Warunki końcowe dla niepowodzenia: brak egzemplarzu filmu na stanie

Scenariusz główny:

1. Klient informuje sprzedawcę o chęci wypożyczenia danego filmu/zestawu filmów.

2. Pracownik sprawdza czy dany egzemplarz jest dostępny w wypożyczalni. Jeżeli jest to sprawdza czy:

2a. Klient istnieje w bazie – jeżeli nie to dodaje go.

3. Pracownik przechodzi do wystawienia rachunku oraz poinformowania klienta o okresie zwrotu.

Scenariusz alternatywny:

1. Klient informuje sprzedawcę o chęci wypożyczenia danego filmu/zestawu filmów.

2. Pracownik sprawdza czy dany egzemplarz jest dostępny w wypożyczalni. Jeżeli go nie ma to informuje o tym klienta oraz informuje kiedy egzemplarz został wypożyczony.

PU : Wystaw rachunek

Aktorzy: Pracownik, klient

Zdarzenie wyzwalające: złożenie zamówienia

Warunki wstępne: pracownik musi być zalogowany w systemie, zamówienie musi zostać złożone przez klienta

Warunki końcowe dla sukcesu: klient dokonuje płatności

Warunki końcowe dla niepowodzenia: klient nie dokonuje płatności

Scenariusz główny:

1. Klient składa zamówienie

2. Pracownik informuje go o kwocie zamówienia oraz sugerowanej dacie zwrotu oraz karze za przekroczenie.

3. Pracownik wystawia rachunek/fakturę klientowi.

4. Klient dokonuje płatności.

PU : Zwróć wypożyczony film

Aktorzy: Pracownik, klient

Zdarzenie wyzwalające: zwrot przez klienta egzemplarzu filmu

Warunki wstępne: pracownik musi być zalogowany w systemie, zamówienie musi istnieć w systemie

Warunki końcowe dla sukcesu: klient zwraca prawidłowy egzemplarz

Warunki końcowe dla niepowodzenia: klient zwraca inny egzemplarz filmu lub/i zamówienie nie zostało zarejestrowane przez pracownika

Scenariusz główny:

1. Klient zwraca wypożyczony film.

2. Pracownik sprawdza w systemie zamówienie.

3. Jeżeli istnieje pracownik wprowadza datę zwrotu.

4. Analiza i projekt

System informatyczny dla wypożyczalni DVD oparty zostanie o technologię ASP.NET MVC 4 przy wykorzystaniu serwera bazodanowego MySQL oraz mapowanie obiektowo – relacyjne przy wykorzystaniu Fluent NHibernate w wersji 2.0.3. Niniejsza technologia narzuca wykorzystanie architektury MVC – model, widok, kontroler do budowy systemu.

Architektura systemu

Architektura systemu oparta zostanie o model architektury MVC (Model View Controller). Idea takiej architektury została zaprezentowana na rys. 3.

Rysunek . Diagram przypadków użycia.

Wzorzec składa się z trzech składowych, mianowicie:

• kontrolera – przyjmującego dane wejściowe od użytkownika oraz realizowania odpowiedniej reakcji na jego żądania – aktualizuje model oraz odświeża widokim

• widok – reprezentuje graficzny interfejs użytkownika, stanowi prezentację danych użytkownikowi,

• model – reprezentuje logikę biznesową systemu informatycznego.

W tab. 4 przedstawiono wybrane technologie do budowy poszczególnych elementów architektury MVC.

Tabela . Wybrane technologii w stosunku do składowych.

Składowa	Technologia wykonania
Kontroler	C#
Model	C#
Widok	cshtml,css,javasript

Projekt oprogramowania

Klasy dziedziny

Tabela . Klasy dziedziny.

Klasa	Opis
Osoba (abstrakcyjna)*	Niniejsza klasa reprezentuje osoby w systemie. Jest klasą abstrakcyjną – nie przewiduje się tworzenia obiektu klasy Osoba. Innymi słowy inne klasy (np. klient będą dziedziczyć po klasie Osoba).
Klient	Klient wypożyczalni DVD. Klasa dziedzicząca po klasie abstrakcyjnej Osoba.
Pracownik	Pracownik wypożyczalni dziedziczący po klasie Osoba. Zawiera również oprócz danych osobowych oraz teleadresowych informacje o loginie oraz haśle do systemu informatycznego.
Rachunek	Rachunek wystawiony przez danego pracownika dla danego klienta i jego listy zamówień. Rachunek musi zawierać również takie informacje jak kwota jaką zapłacił klient oraz datę wystawienia.
Filmy	Filmy dostępne w wypożyczalni DVD. Posiadają określoną kategorię, tytuł, rok produkcji oraz opis.
Kategoria	Kategoria filmu
Wypożyczenie	Klasa przechowująca informacja o danym wypożyczeniu. Wypożyczenie przechowuje informacje o kliencie, nazwie filmu oraz dacie wypożyczenia i zwrocie filmu.
Stan magazynu	Encja przechowująca informacje o stanach magazynowych wypożyczalni DVD.

Klasy mapujące ORM

Do komunikacji z bazą zostanie wykorzystany framework Fluent NHibernate w wersji 2.0.3. Jest to rozszerzenie ORM (ang. Objected-relational mapping) czyli framework umożliwiające mapowanie obiektowo – relacyjne. Dzięki temu możliwym­­ jest odpowiednie odwzorowanie modelu obiektowego zastosowanego w systemie na model relacyjny.

Fluent NHibernate wykorzystuje specjalne klasy mapujące, przykład takiej klasy został zaprezentowany poniżej (klasa mapująca filmy na model relacyjny).

public class FilmyMap : ClassMapping<Filmy> {

public FilmyMap() {

Schema("wypozyczalnia");

Lazy(true);

Id(x => x.Id, map => map.Generator(Generators.Assigned));

Property(x => x.Nazwa);

Property(x => x.Opis);

Property(x => x.RokProdukcji, map => map.Column("rok_produkcji"));

ManyToOne(x => x.Kategoria, map =>

{

map.Column("id_kategorii");

map.NotNullable(true);

map.Cascade(Cascade.None);

});

}

Klasy przetwarzające dane

Tabela . Klasy przetwarzające dane.

Klasa	Opis	Metody
RaportGenerator	Klasa oparta o wzorzec singleton. Odpowiedzialna za generowanie raportów do plików Excela lub pdf	GenerujRaportSprzedazowy(DateTime start, DateTime koniec, boolean czyPDF) – metoda generująca raport sprzedażowy w żądanym czasie GenerujRaportPopularnosci(Film film, DateTime start, DateTime koniec, boolena czyPDF) – metoda generująca raport popularności danego filmu.
BazaDanychManager <T>	Klasa generyczna odpowiedzialna za obsługę bazy danych.	DodajDoBazy(T object) – dodaje obiekt do bazy. UsunZBazy(T object) – usuwa obiekt z bazy. EdytujWBazie(T object) – edytuje obiekt w bazie. PobierzZBazy() – pobiera obiekty z bazy. Zwracany wynik w kontenerze List<T>.
BazaDanychKonfigurator	Klasa odpowiedzialna za ustawienie konfiguracji FluentNHibernate z bazą danych MySQL oparta o wzorzec singleton.	UstawKonfiguracje() – metoda ustawiająca konfigurację ORM.
RachunekGenerator	Klasa generująca rachunki oparta o wzorzec projektowy singleton.	GenerujRachunek(Klient,List<Wypozyczenia>,DateTime data, double kwota) – metoda generująca rachunek (zwraca typ Rachunek). DrukujRachunek(Rachunek rachunek) – metoda drukująca rachunek.
RachunekContainer	Kontener przechowujący rachunki.	Metody dodawania, usuwania, edycji i pobrania rachunków.
FilmyContainer	Kontener przechowujący filmy.	Metody dodawania, usuwania, edycji i pobrania filmów.
KlienciContainer	Kontener przechowujący klientów.	Metody dodawania, usuwania, edycji i pobrania klientów.
WypozyczeniaContainer	Kontener przechowujący wypożyczenia.	Metody dodawania, usuwania, edycji i pobrania wypożyczeń.

W klasach przetwarzających dane zdecydowano się na zastosowanie klas – kontenerów (diagram klas dla kontenera klientów przedstawiono na rys. 4) oraz generatorów. Generatory oparte zostaną o wzorzec projektowy – singleton. Równie dobrze można by zastosować klasę statyczną, jednakże zdecydowano się na wzorzec, ponieważ w przyszłości możliwym będzie zastosowanie dziedziczenia. Oprócz tego zastosowano klasę generyczną tak by ułatwić przetwarzanie danych z bazą przy wykorzystaniu ORM.

Rysunek . Diagram klas dla kontenera.

Routing

Routing odpowiada za nazewnictwo stosowane w adresach URL. W przypadku niniejszego projektu zdecydowano się na tradycyjne (domyślne) nazewnictwo wspierane przez ASP.NET MVC. Przykład mapy routingu przedstawia kod poniżej:

routes.MapRoute(

name: "Default",

url: "{controller}/{action}/{id}",

defaults: new { controller = "Home", action = "Index", id = UrlParameter.Optional }

);

Diagram ERD

Rysunek . Diagram ERD.

Przykładowe interfejsy graficzne

Rysunek . Dodawanie klienta.

Rysunek . Przeglądanie klientów.

Rysunek . Dodaj film.

Metodyka wytwarzania oprogramowania

Do wytworzenia oprogramowania wykorzystana zostanie metodyka oparta o TDD (ang. Test Driven Development). Idea tej metodyki opiera się na wykorzystaniu testów jednostkowych w procesie wytwarzania oprogramowania. Metodyka ta zaliczana jest do metodyk zwinnych i jest wykorzystywana w postulacie Agile. Idea opiera się o cykl Red – Green – Refactor, który to został zaprezentowany poniżej.

Rysunek 9. Idea TDD.

Tabela . Opis faz Red – Green – Refactor.

Faza	Opis
Red	Tworzony jest test jednostkowy, który się nie powiedzie – z uwagi na to, że testowane są klasy oraz metody, które nie mają implementacji.
Green	Tworzony jest kod źródłowy do metod oraz klas testowanych w poprzedniej fazie, wówczas test ma prawo się udać.
Refactor	Refaktoryzacja kodu.

Kolejnym elementem wykorzystywanym w procesie wytworzenia niniejszego projektu będzie tzw. „code review” czyli inspekcja kodu. Innymi słowy po zakończeniu określonego etapu (np. napisaniu modułu) zostanie on poddany przeglądowi kodu dla innego programisty. Dzięki zastosowaniu takiej metodyki możliwym będzie zwiększenie czytelności kodu źródłowego systemu informatycznego. Łatwiej będzie można również wychwycić błędy oraz luki w oprogramowaniu.

---

1. * Diagram klas zawiera dodatkowo atrybuty typu – Id w niektórych klasach, takie podejście wynika z faktu zastosowania mapowania obiektowo-relacyjnego.↩