Sklep internetowy z grami

Sklep internetowy z grami Dokumentacja projektowa Choina Sebastian, Cisek Daniel, Dudziński Piotr, Gątnicki Łukasz, Ignatowicz Mariusz Koszalin, 2012

Spis treści 1. Protokół założycielski... 4 1.1. Grupa założycielska... 4 1.2. Statut grupy projektowej... 4 1.2.1. Postanowienia ogólne... 4 1.2.2. Cele... 4 1.2.3. Członkowie... 4 1.2.4. Funkcje członków grupy projektowej... 5 1.3. Cele projektu... 5 2. Narzędzia projektowe... 6 3. Założenia projektowe... 6 3.1. Wymagania klienta... 6 3.2. Proces biznesowy... 8 3.3. Mapa myśli... 11 3.4. Wymagania funkcjonalne... 12 3.5. Wymagania niefunkcjonalne... 13 3.6. Harmonogram projektu... 14 4. Raport dla klienta... 15 4.1. Kompletna lista funkcjonalności systemu... 15 4.2. Narzędzia projektowe... 16 4.3. Rozliczenie... 16 5. Baza danych... 17 5.1. Słownik danych... 17 5.2. Kategorie i funkcje użytkowników... 20 5.2.1. Administrator... 20 5.2.2. Klient... 20 5.3. Model konceptualny... 21 5.3.1. Schemat modelu... 21 5.3.2. Opis modelu... 22 Spis treści 1

5.3.2.1. Wykaz encji... 22 5.3.2.2. Wykaz asocjacji... 23 5.3.2.3. Relacje i połączenia asocjacyjne... 23 5.4. Model fizyczny... 25 5.4.1. Schemat modelu... 25 5.4.2. Opis modelu... 26 5.4.2.1. Wykaz tabel... 26 5.4.2.2. Relacje... 28 5.5. Implementacja bazy danych... 29 6. GUI graficzny interfejs użytkownika... 34 6.1. Przeznaczenie... 34 6.2. Kolorystyka... 34 6.3. Koncepcje... 35 6.3.1. Szkic strony głównej... 35 7. Projekt systemu... 36 7.1. Diagram przypadków użycia... 37 7.1.1. Dla użytkownika gość... 37 7.1.2. Dla pracownika, klienta i administratora... 38 7.2. Diagram klas... 39 7.2.1. Konceptualny model diagramu klas... 39 7.2.2. Opis diagramu klas... 40 7.2.2.1. Basket... 40 7.2.2.2. BasketItem... 41 7.2.2.3. Comment... 41 7.2.2.4. Order... 41 7.2.2.5. PEGI... 42 7.2.2.6. PersonalData... 42 7.2.2.7. Product... 43 7.2.2.8. User... 43 Spis treści 2

7.2.2.9. UserRights... 44 7.2.3. Fizyczny model diagramu klas... 45 7.2.4. Opis fizycznego diagramu klas... 46 7.2.4.1. Controller... 46 7.2.4.2. AdminController... 46 7.2.4.3. IndexController... 46 7.2.4.4. ProductController... 47 7.2.4.5. View... 47 7.2.4.6. DatabaseConnection... 47 7.2.4.7. Form... 48 7.2.4.8. FormInput... 49 7.2.4.9. FormRegexInput... 49 7.2.4.10. FormCheckboxInput... 50 7.2.4.11. FormSelectInput... 50 7.2.4.12. FormNumberRangeInput... 51 7.2.4.13. FormRadioInput... 51 3

1. Protokół założycielski 1.1. Grupa założycielska [SKLEP INTERNETOWY Z GRAMI] W dniu 29 lutego 2012 r. w Koszalinie odbyło się spotkanie osób mających na celu utworzenie grupy projektowej CASE. W skład zespołu wchodzą: a) Sebastian Choina b) Daniel Cisek c) Piotr Dudziński d) Łukasz Gątnicki e) Mariusz Ignatowicz Po stwierdzeniu obecności wszystkich członków zespołu przystąpiono do opracowania Statutu Grupy Projektowej. 1.2. Statut grupy projektowej 1.2.1. Postanowienia ogólne Grupa Projektowa jest organizacją twórczą Grupa ma charakter projektowo-techniczny Grupa działa dla klienta zlecającego wykonanie projektu Siedzibą Zarządu projektu CASE jest miasto Koszalin 1.2.2. Cele Stworzenie projektu i wykonanie aplikacji sklepu internetowego Przetestowanie i wykonanie potrzebnej dokumentacji Wykonanie aplikacji zgodnie z wymaganiami stawianymi przez klienta 1.2.3. Członkowie Członkiem grupy projektowej może być każda osoba pełnoletnia będąca studentem trzeciego roku Informatyki specjalności PKISI Członkostwo jest formą dobrowolną Członkowie grupy projektowej CASE na jego podstawie będą czerpali wymierne korzyści w postaci zaliczenia przedmiotu z oceną bdb. Protokół założycielski 4

Członkostwo może ustać na podstawie o Pisemnej deklaracji zrzeczenia się członkostwa o Skreślenia członka przez organ nadzorczy grupy projektowej o Inne sytuacje powstałe poprzez zaniedbania członka zespołu 1.2.4. Funkcje członków grupy projektowej Sebastian Choina kierownik projektu Daniel Cisek główny programista Piotr Dudziński analityk, projektant systemu Łukasz Gątnicki projektant baz danych Mariusz Ignatowicz projektant interfejsu, grafik, projektant systemu Głównym organem nadzorczym, który posiada najwyższą władzę sprawczą jest Kierownik Projektu. Członkowie projektu wykonują przydzieloną im pracę przez Kierownika Projektu. Członkowie projektu mogą odwołać Kierownika Projektu. Członkowie projektu mogą powołać nowego Kierownika Projektu, rozpatrując złożone kandydatury. Wybranym przez członków projektu Kierownikiem Projektu jest Sebastian Choina 1.3. Cele projektu a) Stworzenie aplikacji trafiającej w zapotrzebowanie rynku b) Dostarczenie klientowi platformy umożliwiającej elektroniczny handel grami komputerowymi c) Zapewnienie klientowi systemu zarządzania sklepem internetowym (asortyment, użytkownicy) Protokół założycielski 5

2. Narzędzia projektowe [SKLEP INTERNETOWY Z GRAMI] Kierownik zespołu projektowego CCDGI po konsultacji z zespołem, ustala listę narzędzi które będą wykorzystywane do ukończenia projektu CCDGI. SVN: code.google.com, freeware Zarządzanie projektem: code.google.com, freeware Projektowanie baz danych: Sybase PowerDesigner v15.0, RAD: Eclipse for PHP v Helios sp2, Netbeans 7.11 Technologia PHP 5 Design: Adobe Photoshop CS4, commercial licence Testy: Internet Explorer >6, Firefox>5, Chrome, freeware Wspomaganie projektowania: FreeMind, Gliffy, freeware OS: Microsoft Windows 7 SP2, licencja komercyjna na 5 stanowisk 3. Założenia projektowe 3.1. Wymagania klienta Po przeprowadzeniu w dniu 12-02-29 wstępnego wywiadu z klientem utworzona została lista wymagań wyspecyfikowanych przez klienta. Posiadają one najwyższy priorytet oraz są obowiązkowymi punktami realizacji projektu. Wszelkie zmiany co do wymagań, które wprowadzi klient, muszą być dołączone w formie pisemnej po akceptacji kierownika projektu, pod rygorem nieważności. Narzędzia projektowe 6

Tabela 3.1. Wymagania klienta na oprogramowanie Pytanie Możliwość rejestracji użytkownika Możliwość logowania Możliwość zamówienia bez rejestracji Zmiana wersji językowej Liczba kategorii gier Przewidywana ilość klientów Możliwość oceny produktu Możliwość komentowania produktu (zatwierdzanie opinii przez administratora) Możliwość edycji profilu użytkownika Możliwość dodawania kategorii Możliwość dodawania/usuwania produktu Odpowiedź TAK TAK TAK NIE Standardowo Ok 30 klientów dziennie TAK TAK TAK TAK TAK Nadawanie uprawnień do witryny użytkownikom przez administratora Zarządzanie bazą danych za pośrednictwem witryny Koszyk (zarządzanie: dodawania / usuwanie) Rezerwacja (tylko na 24h) Informowanie klientów o bieżących nowościach (newsletter) Informowanie klientów o zmianie statusu zamówienia(w trakcie realizacji/zrealizowane/zakończone) Automatyczna aktualizacja bazy danych Płatność elektroniczna( integracja z systemem przelewów) Styl graficzny witryny Reklamy (promowanie nowych produktów) TAK TAK TAK TAK TAK TAK TAK Zgodnie z zainteresowaniem użytkowników TAK Założenia projektowe 7

Możliwość filtrowania produktów przez klienta wg kategorii Wyświetlanie bestsellerów w lewym panelu witryny Prowadzenie statystyk Dodawanie słów kluczowych do produktów Proponowanie produktów(na podstawie słów kluczowych) Wysłanie potwierdzenie zamówienia klientowi na pocztę elektroniczną Kontakt z administratorem sklepu za pośrednictwem strony TAK TAK TAK TAK TAK TAK TAK 3.2. Proces biznesowy Proces funkcjonowania przedsiębiorstwa handlowego został szczegółowo przeanalizowany. W wyniku prac analitycznych, uzyskano ścieżkę transakcyjną będącą częścią modelu biznesowego odpowiedzialną za sprzedaż końcową. Przedstawiony poniżej model biznesowy prezentuje zachowanie oraz relacje klienta końcowego (kupującego) oraz pracowników. Wydzielona została również część ścieżki transakcji, za której kompletną obsługę odpowiadał będzie system informatyczny. Jak jasno widać na poniższym diagramie, ścieżka biznesowa, za którą będzie odpowiadał system sięga od prezentacji produktów, po przez szczegóły dotyczące dostawy, informacji o całkowitym koszcie dla klienta sklepu, aż po realizacje transakcji finansowej oraz przekazanie gotowego zamówienia do działu odpowiadającego za dostawę. Sklep internetowy jest jedną z najpopularniejszych z form e-biznesu. Celem przedsięwzięcia jest sprzedaż towarów za pośrednictwem witryny internetowej. Głównymi zaletami tego modelu są: Niskie koszty utrzymania Dodatkowy zysk płynący z reklam Globalny zasięg zbytu Założenia projektowe 8

Wsparcie technologiczne Wygoda kupujących i sprzedających Swoboda funkcjonowania, niezależnie od miejsca Proces biznesowy użytkownika podzielony jest na dwie strefy: klienta i pracownika. Klient od momentu wejścia na witrynę sekwencyjnie porusza się po kolejnych stanach które rozpoczynają się od wyboru zbioru produktów i dodania ich do koszyka. W kolejnym etapie system weryfikuje dostępność towaru znajdującego się w koszyku i ewentualnie zgłasza brak danego produktu. Następnie klient w przypadku wcześniejszego logowania przechodzi do wyboru metody dostawy paczki w przeciwnym wypadku poprzedzone jest to wymogiem podania danych klienta. Kolejnym krokiem jest wybór sposobu płatności i potwierdzenie zamówienia wysłanego na adres e-mail. Rola pracownika w tym modelu ogranicza się do nadzorowania przychodzących zamówień w systemie administracji i nadania paczki do klienta. Założenia projektowe 9

Rysunek 3.2.1 Model biznesowy Założenia projektowe 10

3.3. Mapa myśli Poniższy diagram przedstawia wszelakie pomysły grupy projektowej odnośnie funkcjonalności systemu. Wszystkie funkcjonalności zostaną zaimplementowane przyrostowo, a więc po częściowej implementacji wybranych funkcjonalności, odbywały się będą ich testy oraz konsultacja z klientem. Rysunek 3.3.1 Mapa myśli Założenia projektowe 11

3.4. Wymagania funkcjonalne Przeglądanie asortymentu sklepu Modyfikowanie asortymentu sklepu Komunikowanie (w formie reklamy/banneru) klienta o Topselerach Kontrolowanie dostępności towaru (powiadomienie o wyczerpywaniu się zapasów) Wystawienie przez konsumenta opinii o sklepie/ transakcji Sugerowanie konsumentowi produktów zbliżonych do wybranego, jeżeli nie jest obecnie dostępny. Rezerwowanie produktu na 24h Zakupy bez konieczności rejestracji Informacja dla konsumenta o stanie realizacji zamówienia Dla właściciela statystyka sprzedaży Funkcja "koszyka" na zakupy Dodawanie produktów do koszyka Usuwanie produktów z koszyka Podział produktów na kategorie Ocena produktu przez konsumenta (zawyżona) Prowadzenie historii zamówień Przeglądanie historii zamówień Filtrowanie produktów wg wybranych kategorii Wyświetlanie na głównej stronie promocji i nowości (zachęcenie konsumenta) Formularz kontaktu z personelem po przez witrynę Obsługa transakcji bezgotówkowych (system "Płacę z...") Wysłanie potwierdzenia zamówienia na e-mail konsumenta Rejestracja w systemie użytkownika Logowanie do systemu użytkownika Edycja profilu użytkownika Założenia projektowe 12

3.5. Wymagania niefunkcjonalne Tabela 3.5.1. Wymagania niefunkcjonalne Wymaganie Miara Szybki Liczba przetworzonych transakcji na sekundę 20 Czas oczekiwania na zdarzenie wywołane przez użytkownika maksymalnie 5s Ładny Procent ankietowanych użytkowników reagująca pozytywnie na wygląd serwisu 80% Wygodny Niezawodny Liczba maksymalnych kroków potrzebnych do wykonania podstawowych czynności 4 Czas pomiędzy poważnymi awariami wynoszący 60 dni Przenośny Wykonanie w języku programowania w powszechnym użyciu na serwerach Bezpieczny Częstotliwość robienia backupów 1 dziennie Założenia projektowe 13

3.6. Harmonogram projektu Po przeprowadzonej analizie wymagań projektowych oraz mapy myśli, utworzony został wstępny harmonogram realizacji projektu. Projekt oszacowany jest na realizacje do 31.05.2012 r. Dopuszczalne jest przekroczenie o 14 dni terminu podanego powyżej, bez ponoszenia kary umownej ze strony grupy projektowej. Rysunek 3.6.1. Diagram Gantta Założenia projektowe 14

4. Raport dla klienta Po przeprowadzonej analizie została wyznaczona lista funkcjonalności systemu będąca podstawą rozliczenia. Wyznaczony został również kosztorys projektu oraz termin jego realizacji. Uprzejmie uprasza się klienta o dogłębne zapoznanie się z niniejszym raportem, oraz podjęcie decyzji o przystąpieniu do implementacji projektu. 4.1. Kompletna lista funkcjonalności systemu Przeglądanie asortymentu sklepu Modyfikowanie asortymentu sklepu Komunikowanie (w formie reklamy/banneru) klienta o Topselerach Kontrolowanie dostępności towaru (powiadomienie o wyczerpywaniu się zapasów) Wystawienie przez konsumenta opinii o sklepie/ transakcji Sugerowanie konsumentowi produktów zbliżonych do wybranego, jeżeli nie jest obecnie dostępny. Rezerwowanie produktu na 24h Zakupy bez konieczności rejestracji Informacja dla konsumenta o stanie realizacji zamówienia Dla właściciela statystyka sprzedaży Funkcja "koszyka" na zakupy Dodawanie produktów do koszyka Usuwanie produktów z koszyka Podział produktów na kategorie Ocena produktu przez konsumenta (zawyżona) Prowadzenie historii zamówień Przeglądanie historii zamówień Filtrowanie produktów wg wybranych kategorii Wyświetlanie na głównej stronie promocji i nowości (zachęcenie konsumenta) Formularz kontaktu z personelem po przez witrynę Obsługa transakcji bezgotówkowych (system "Płacę z...") Wysłanie potwierdzenia zamówienia na e-mail konsumenta Rejestracja w systemie użytkownika Logowanie do systemu użytkownika Raport dla klienta 15

Edycja profilu użytkownika 4.2. Narzędzia projektowe SVN: code.google.com Zarządzanie projektem: code.google.com Projektowanie baz danych: Sybase PowerDesigner RAD: Eclipse for PHP, Netbeans 7.11 Technologia PHP Design: Adobe Photoshop CS4 Testy: Internet Explorer >6, Firefox>5, Chrome Wspomaganie projektowania: FreeMind, Gliffy 4.3. Rozliczenie Szacowany termin ukończenia 7.07.2012 r. Koszt projektu 87 600,00 zł Szczegółowe rozliczenie: Tabela 4.3.1. Szczegółowe rozliczenie wydatków Wydatek Koszt Koszt całkowity (2 miesiące) Programista Analityk Projektant Grafik Kierownik projektu Media Licencje na oprogramowanie Razem: 78000 Raport dla klienta 16

5. Baza danych Niniejszy rozdział dokumentuje pełny model relacyjnej bazy danych, która będzie wykorzystana do pracy systemu CCDGI. 5.1. Słownik danych a) Administratorzy użytkownicy systemu będący pracownikami sklepu. Posiadają pełne uprawnienia do zarządzania systemem. Mają dostęp do pełnej funkcjonalności systemu. Ich zadaniem jest wstawianie gier znajdujących się w sprzedaży, ustawianie i edytowanie ich cen, opisów, itp. b) Klienci użytkownik systemu będący klientami sklepu. Mogą oni kupować gry ustawiać i edytować swoje dane adresowe, przeglądać historię swoich zamówień oraz oceniać i komentować gry. c) Gra program komputerowy służący do celów edukacyjnych lub rozrywkowych, będący asortymentem sklepu. Gry należą do odpowiednich kategorii, posiadają oceny i tagi zewnętrznej organizacji oraz mogą być oceniane i komentowane przez użytkowników. d) PEGI, Pan European Game Information (pol. Ogólnoeuropejski System Klasyfikacji Gier, OSKG) europejski system oceniania gier komputerowych, założony przez Interactive Software Federation of Europe (ISFE) w kwietniu 2003 roku, używany w 32 krajach. We wrześniu 2009 oznaczenia PEGI zostały uznane za jedyne oficjalnie obowiązujące w Polsce. e) Oceny wiekowe PEGI minimalny wiek, oznaczający, dla kogo, pod względem wieku, powinna być dostępna gra. Obecny system ikon obowiązuje od 1 września 2009 roku: Ograniczenie Informacje Treść gier oznaczonych w ten sposób uznaje się za odpowiednią dla wszystkich grup wiekowych. Dopuszczalna jest pewna ilość przemocy w komicznym kontekście. Dziecko nie powinno utożsamiać postaci pojawiających się na ekranie z postaciami rzeczywistymi. Powinny one być w całości wytworem fantazji. Gra nie powinna zawierać dźwięków ani obrazów, które mogą przestraszyć dziecko. Nie powinny w niej występować wulgaryzmy, sceny zawierające nagość ani odwołania do życia seksualnego. Baza danych 17

Gry, które w innym przypadku zostałyby zakwalifikowane do grupy 3, lecz zawierają dźwięki lub sceny potencjalnie przerażające najmłodszych odbiorców, mogą być uznane za odpowiednie dla tej grupy wiekowej. Dopuszczalne są sceny obejmujące częściową nagość, ale nigdy w kontekście seksualnym. Gry wideo pokazujące przemoc o nieco bardziej realistycznym charakterze, skierowaną przeciw postaciom fantastycznym i/lub nierealistyczną przemoc wobec postaci o ludzkim lub rozpoznawalnych zwierząt, ponadto w tej kategorii wiekowej dopuszczalna jest nieco bardziej dosłowna nagość. Ewentualne wulgaryzmy muszą mieć łagodny charakter i nie mogą zawierać odwołań do seksu. Ten symbol jest nadawany, jeżeli przemoc lub aktywność seksualna wyglądają tak jak w rzeczywistości. Młodzież w tym wieku powinna również być odporna na brutalniejsze wulgaryzmy, sceny pokazujące używanie tytoniu lub narkotyków oraz sceny popełniania przestępstw. Za gry dla dorosłych uznaje się gry przedstawiające daleko posuniętą przemoc i/lub specyficzne rodzaje przemocy. Daleko posunięta przemoc jest najtrudniejsza do zdefiniowania, ponieważ w wielu przypadkach jest to pojęcie bardzo subiektywne, ale ogólnie można ją określić, jako sceny przemocy powodujące u widza uczucie odrazy. f) PEGI tagi (opisy zwartości) produkt oznaczany jest maksymalnie ośmioma opisami: Obrazek Treść Informacje Dopuszczalne oznaczenia Przemoc Gra zawiera elementy przemocy. Seks Dyskryminacja W grze pojawiają się nagość i/lub zachowania seksualne lub nawiązania do zachowań o charakterze seksualnym. Gra pokazuje przypadki dyskryminacji lub zawiera materiały, które mogą do niej zachęcać osoby nieletnie. Baza danych 18

W grze pojawiają się nawiązania do Używki Strach używek lub przedstawiono ich zażywanie. Gra może przestraszyć młodsze dzieci. Wulgarny język W grze jest używany wulgarny język. Hazard Gry, które zachęcają do uprawiania hazardu lub go uczą. Gra online Gry, w które można grać przez Internet. g) Metascore ocena gry wydana przez serwis Metacritic na podstawie przeliczenia ocen branżowych portali i magazynów. Ocena ta zawiera się w skali 0 100 punktów. h) Wydawca osoba bądź instytucja (ta druga zwana również wydawnictwem), za której pieniądze przygotowywane, opracowywane, a następnie dystrybuowana jest gra. i) Kategoria (gatunek) Gry, tak jak większość innych mediów, mogą być kategoryzowane według gatunków bazujących na mechanice gry, atmosferze i wielu innych czynnikach. Najczęściej spotykane gatunki gier: Platformówki Przygodowe Gra fabularna (RPG) MMORPG Sportowe Wyścigowe Gry akcji Bijatyki Strzelanki First-person shootery (FPS) Third-person perspective (TPP) Skradanki Baza danych 19

Logiczne Symulacyjne Strategiczne Turowe Czasu rzeczywistego (RTS) Przeglądarkowe 5.2. Kategorie i funkcje użytkowników 5.2.1. Administrator a) Wykorzystanie pełnej funkcjonalności systemu b) Dodawanie i usuwanie użytkowników c) Przeglądanie wszystkich i modyfikacja wszystkich listy wraz z opisami, komentarzami, ocenami itp. d) Przeglądanie historii zamówień, listy użytkowników, listy ocen i kategorii 5.2.2. Klient a) Przeglądanie gier i kupowanie gier b) Przeglądanie historii zamówień c) Przeglądanie i edytowanie danych osobowych d) Przeglądanie i edytowanie listy obserwowanych gier e) Ocenianie i komentowanie gier Baza danych 20

5.3. Model konceptualny 5.3.1. Schemat modelu Rysunek 5.3.1 Schemat modelu konceptualny Baza danych 21

5.3.2. Opis modelu 5.3.2.1. Wykaz encji 5.3.2.1.1. Users użytkownicy a) email unikatowy identyfikator użytkownika będący jego adresem poczty e-mail, klucz pierwotny, typ danych: Variable characters(50) b) password hasło użytkownika, typ danych: Variable characters(30) c) firstname imię użytkownika, typ danych: Variable characters(30) d) lastname nazwisko użytkownika, typ danych: Variable characters(30) e) address adres użytkownika, typ danych: Variable characters(50) f) post_code kod pocztowy użytkownika, typ danych: Variable characters(6) g) city miasto użytkownika, typ danych: Variable characters(30) h) phone telefon użytkownika, typ danych: Variable characters(12) i) newsletter wskazuje czy użytkownik chce otrzymywać newsletter, typ danych: Boolean 5.3.2.1.2. Groups grupy a) name unikatowa nazwa grupy użytkowników, klucz pierwotny, typ danych: Variable characters(30) b) rights liczba określająca prawa użytkownika należącego do danej grupy, typ danych: Byte 5.3.2.1.3. Games gry a) id unikatowy identyfikator gry, klucz pierwotny, typ danych: Serial b) title tytuł gry, typ danych: Variable characters(100) c) description opis gry, typ danych: Text d) releasedate data wydania gry, typ danych: Date e) pegiurl adres url do ikony oceny wiekowej PEGI, typ danych: Text f) metascore ocena gry, typ danych: Byte g) coverurl adres url do okładki gry, typ danych: Text h) youtubeurl adres url do gameplayu gry, typ danych: Text i) price cena gry, typ danych: Number(5,2) j) count ilość kopii gry w magazynie, typ danych: Integer Baza danych 22

5.3.2.1.4. Categories kategorie gry a) catname unikatowa nazwa kategorii gry, klucz pierwotny, typ danych: Variable characters(30) b) description opis kategorii gry, typ danych: Text c) Publishers wydawcy gier d) publishername unikatowa nazwa wydawcy gry, klucz pierwotny, typ danych: Variable characters(80) 5.3.2.1.5. PEGI Tags opisy zawartości gier PEGI a) tagid unikatowy identyfikator tagu, klucz pierwotny, typ danych: Serial b) tagname nazwa tagu, typ danych: Variable characters(80) c) tagurl adres url do ikony opisującej tag, typ danych: Text 5.3.2.1.6. Orders zamówienia a) orderid unikatowy identyfikator zamówienia, klucz pierwotny, typ danych: Serial b) orderdate data zamówienia, typ danych: Date 5.3.2.2. Wykaz asocjacji Grades oceny gier wydane przez użytkowników grade ocena gry, typ danych: Byte comment komentarz gry, typ danych: Text adddate data wystawienia oceny, typ danych: Date Observed gry obserwowane przez użytkownika date data dodania gry do obserwowanych, typ danych: Date 5.3.2.3. Relacje i połączenia asocjacyjne W modelu semantycznym encje zostały połączone następującymi relacjami: Users, Groups relacja jeden do wielu wymagająca przynależności każdego użytkownika do tylko jednej grupy. Users, Orders relacja jeden do wielu wymagająca powiązania każdego zamówienia z tylko jednym użytkownikiem. Games, Categories relacja jeden do wielu wymagająca przynależności każdej gry do tylko jednej kategorii. Baza danych 23

Games, Publishers relacja jeden do wielu wymagająca przynależności każdej gry do tylko jednego wydawcy. Games, Orders relacja wielu do wielu wymagająca co najmniej jednej gry powiązanej z zamówieniem. Games, PEGITags relacja wielu do wielu pozwalającej każdej grze przypisać wiele tagów PEGI. Users, Games, Grades każdy gra może posiadać oceny od wielu użytkowników i każdy użytkownik może wydać oceny dla wielu gier Users, Games, Observed każdy gra może być obserwowana przez wielu użytkowników i każdy użytkownik może obserwować wiele gier. Baza danych 24

5.4. Model fizyczny 5.4.1. Schemat modelu Rysunek 5.4.1. Schemat modelu fizycznego Baza danych 25

5.4.2. Opis modelu 5.4.2.1. Wykaz tabel 5.4.2.1.1. Users email unikatowy identyfikator użytkownika będący jego adresem poczty e-mail, klucz pierwotny, typ danych: varchar(50) password hasło użytkownika, typ danych: varchar (30) firstname imię użytkownika, typ danych: varchar (30) lastname nazwisko użytkownika, typ danych: varchar (30) address adres użytkownika, typ danych: varchar (30) post_code kod pocztowy użytkownika, typ danych: varchar (6) city miasto użytkownika, typ danych: varchar (30) phone telefon użytkownika, typ danych: varchar (12) newsletter wskazuje czy użytkownik chce otrzymywać newsletter, typ danych: bool 5.4.2.1.2. Groups grupy name unikatowa nazwa grupy użytkowników, klucz pierwotny, typ danych: varchar (30) rights liczba określająca prawa użytkownika należącego do danej grupy, typ danych: tinyint 5.4.2.1.3. Games gry id unikatowy identyfikator gry, klucz pierwotny, typ danych: int catname identyfikator kategorii gry, klucz obcy, typ danych: varchar(30) publishername identyfikator wydawcy, klucz obcy, typ danych: varchar(80) title tytuł gry, typ danych: varchar(100) description opis gry, typ danych: text releasedate data wydania gry, typ danych: date pegiurl adres url do ikony oceny wiekowej PEGI, typ danych: text metascore ocena gry, typ danych: tinyint coverurl adres url do okładki gry, typ danych: text youtubeurl adres url do gameplaya gry, typ danych: text Baza danych 26

price cena gry, typ danych: numeric(5,2) count ilość kopii gry w magazynie, typ danych: int 5.4.2.1.4. Categories kategorie gier catname unikatowa nazwa kategorii gry, klucz pierwotny, typ danych: varchar(30) description opis kategorii gry, typ danych: text Publishers wydawcy gier publishername unikatowa nazwa wydawcy gry, klucz pierwotny, typ danych: varchar(80) 5.4.2.1.5. PEGI Tags opisy zawartości gier PEGI tagid unikatowy identyfikator tagu, klucz pierwotny, typ danych: int tagname nazwa tagu, typ danych: varchar(80) tagurl adres url do ikony opisującej tag, typ danych: text GamesPegiTags tagi PEGI przypisane do gier id unikatowy identyfikator gry, klucz obcy, typ danych: int tagid unikatowy identyfikator tagu, klucz obcy, typ danych: int klucz pierwotny złożony z obu kluczy obcych 5.4.2.1.6. Orders zamówienia orderid unikatowy identyfikator zamówienia, typ danych: int email unikatowy identyfikator użytkownika będący jego adresem poczty e-mail, klucz obcy, typ danych: varchar(50) orderdate data zamówienia, typ danych: date GamesInOrders gry które w jednym zamówieniu kupił klient orderid unikatowy identyfikator zamówienia, klucz obcy, typ danych: int id unikatowy identyfikator gry, klucz obcy, typ danych: int klucz pierwotny złożony z obu kluczy obcych Baza danych 27

5.4.2.1.7. Grades oceny gier wydane przez użytkowników id unikatowy identyfikator gry, klucz obcy, typ danych: int email unikatowy identyfikator użytkownika będący jego adresem poczty e-mail, klucz obcy, typ danych: varchar(50) grade ocena gry, typ danych: tinyint comment komentarz gry, typ danych: text adddate data wystawienia oceny, typ danych: date klucz pierwotny złożony z obu kluczy obcych 5.4.2.1.8. Observed gry obserwowane przez użytkownika id unikatowy identyfikator gry, klucz obcy, typ danych: int email unikatowy identyfikator użytkownika będący jego adresem poczty e-mail, klucz obcy, typ danych: varchar(50) date data dodania gry do obserwowanych, typ danych: date klucz pierwotny złożony z obu kluczy obcych 5.4.2.2. Relacje W wygenerowanym modelu fizycznym bazy danych tabele zostały połączone relacjami odzwierciadlającymi połączenia z modelu konceptualnego. Różnice są widoczne przez rozbici relacji wiele do wielu na dwie relacje jeden do wielu i wiele do jednego za pomocą tabeli pośredniej. Tak połączono relacją tabelę Games z tabelą Orders za pomocą tabeli pośredniej GamesInOrders oraz tabelę Games z tabelą PEGITags za pomocą tabeli pośredniej GamesPegiTags. Pozostałe relacje zostały wygenerowane przez ustawienie kluczy obcych, co jest widoczne w wykazie tabel. Baza danych 28

5.5. Implementacja bazy danych Poniżej znajduje się pełna implementacja bazy danych. Listing 1. Kod SQL służący do utworzenia wygenerowanej bazy danych. 1. 2. /*==============================================================*/ 3. /* DBMS name: MySQL 5.0 */ 4. /* Created on: 2012-03-28 11:27:29 */ 5. /*==============================================================*/ 6. 7. drop table if exists Categories; 8. drop table if exists Games; 9. drop table if exists GamesInOrders; 10. drop table if exists GamesPegiTags; 11. drop table if exists Grades; 12. drop table if exists Groups; 13. drop table if exists Observed; 14. drop table if exists Orders; 15. drop table if exists PEGITags; 16. drop table if exists Publishers; 17. drop table if exists Users; 18. 19. /*==============================================================*/ 20. /* Table: Categories */ 21. /*==============================================================*/ 22. create table Categories 23. ( 24. catname varchar(30) not null, 25. description text, 26. primary key (catname) 27. ); 28. 29. alter table Categories comment 'Games categories'; 30. 31. /*==============================================================*/ 32. /* Table: Games */ 33. /*==============================================================*/ 34. create table Games 35. ( 36. id int not null auto_increment, 37. catname varchar(30) not null, 38. publishername varchar(80) not null, Baza danych 29

Listing 1. Ciąg dalszy listingu 1. 39. title varchar(100), 40. description text, 41. releasedate date, 42. pegiurl text, 43. metascore tinyint, 44. coverurl text, 45. youtubueurl text, 46. price numeric(5,2), 47. count int, 48. primary key (id) 49. ); 50. 51. alter table Games comment 'All games in shop'; 52. 53. /*==============================================================*/ 54. /* Table: GamesInOrders */ 55. /*==============================================================*/ 56. create table GamesInOrders 57. ( 58. orderid int not null, 59. id int not null, 60. primary key (orderid, id) 61. ); 62. 63. /*==============================================================*/ 64. /* Table: GamesPegiTags */ 65. /*==============================================================*/ 66. create table GamesPegiTags 67. ( 68. id int not null, 69. tagid int not null, 70. primary key (id, tagid) 71. ); 72. 73. /*==============================================================*/ 74. /* Table: Grades */ 75. /*==============================================================*/ 76. create table Grades 77. ( 78. id int not null, 79. email varchar(50) not null, Baza danych 30

Listing 1. Ciąg dalszy listingu 1. 80. Grade tinyint, 81. comment text, 82. adddate date, 83. primary key (id, email) 84. ); 85. 86. alter table Grades comment 'Grades and comments of game written by users'; 87. 88. /*==============================================================*/ 89. /* Table: Groups */ 90. /*==============================================================*/ 91. create table Groups 92. ( 93. name varchar(30) not null, 94. rights tinyint, 95. primary key (name) 96. ); 97. 98. alter table Groups comment 'Users groups of CCDGI shop. Entity contains rights assingned'; 99. 100. /*==============================================================*/ 101. /* Table: Observed */ 102. /*==============================================================*/ 103. create table Observed 104. ( 105. email varchar(50) not null, 106. id int not null, 107. date date, 108. primary key (email, id) 109. ); 110. 111. alter table Observed comment 'All games observed by users'; 112. 113. /*==============================================================*/ 114. /* Table: Orders */ 115. /*==============================================================*/ 116. create table Orders 117. ( 118. orderid int not null auto_increment, 119. email varchar(50) not null, 120. orderdate date, Baza danych 31

Listing 1. Ciąg dalszy listingu 1. 121. primary key (orderid) 122. ); 123. alter table Orders comment 'All orders of all users ; 124. 125. /*==============================================================*/ 126. /* Table: PEGITags */ 127. /*==============================================================*/ 128. create table PEGITags 129. ( 130. tagid int not null auto_increment, 131. tagname varchar(80), 132. tagurl text, 133. primary key (tagid) 134. ); 135. 136. /*==============================================================*/ 137. /* Table: Publishers */ 138. /*==============================================================*/ 139. create table Publishers 140. ( 141. publishername varchar(80) not null, 142. primary key (publishername) 143. ); 144. 145. /*==============================================================*/ 146. /* Table: Users */ 147. /*==============================================================*/ 148. create table Users 149. ( 150. email varchar(50) not null, 151. name varchar(30) not null, 152. password varchar(30), 153. firstname varchar(30), 154. lastname varchar(30), 155. address varchar(50), 156. postcode varchar(6), 157. city varchar(30), 158. phone varchar(12), 159. newsletter bool, 160. primary key (email) 161. ); Baza danych 32

Listing 1. Ciąg dalszy listingu 1. 162. alter table Users comment 'All users of this system. Clients and shop employees'; 163. 164. alter table Games add constraint FK_Relationship_2 foreign key (catname) 165. references Categories (catname) on delete restrict on update restrict; 166. alter table Games add constraint FK_Relationship_3 foreign key (publishername) 167. references Publishers (publishername) on delete restrict on update restrict; 168. alter table GamesInOrders add constraint FK_GamesInOrders foreign key (orderid) 169. references Orders (orderid) on delete restrict on update restrict; 170. alter table GamesInOrders add constraint FK_GamesInOrders2 foreign key (id) 171. references Games (id) on delete restrict on update restrict; 172. alter table GamesPegiTags add constraint FK_GamesPegiTags foreign key (id) 173. references Games (id) on delete restrict on update restrict; 174. alter table GamesPegiTags add constraint FK_GamesPegiTags2 foreign key (tagid) 175. references PEGITags (tagid) on delete restrict on update restrict; 176. alter table Grades add constraint FK_Grades foreign key (id) 177. references Games (id) on delete restrict on update restrict; 178. alter table Grades add constraint FK_Grades2 foreign key (email) 179. references Users (email) on delete restrict on update restrict; 180. alter table Observed add constraint FK_Observed foreign key (email) 181. references Users (email) on delete restrict on update restrict; 182. alter table Observed add constraint FK_Observed2 foreign key (id) 183. references Games (id) on delete restrict on update restrict; 184. alter table Orders add constraint FK_Relationship_4 foreign key (email) 185. references Users (email) on delete restrict on update restrict; 186. alter table Users add constraint FK_Relationship_1 foreign key (name) 187. references Groups (name) on delete restrict on update restrict; 188. Baza danych 33

6. GUI graficzny interfejs użytkownika Zgodnie z planem prac, sporządzony został szkic graficznego interfejsu użytkownika serwisu w oparciu o dokumentację projektową. Na jego podstawie, tworzone będą kolejne wersje wyglądu aplikacji. 6.1. Przeznaczenie Serwis kierowany jest do szerokiej grupy odbiorców od nastolatków do 30-40-latków z przewagą płci męskiej. 6.2. Kolorystyka Kolorystyka strony ma na celu budować pozytywne skojarzenia, stąd wykorzystanie pastelowych odcieni kolorów zielonego i pomarańczowego. Kolorem czerwonym zaznaczono elementy najbardziej ważne strategicznie dla właściciela sklepu, a więc grupę produktów z działu Promocje. W odróżnieniu od innych sklepów internetowych sprzedających gry komputerowe, tu nacisk położony został na minimalizm, tak by potencjalny klient po wejściu na stronę nie został przytłoczony ogromem informacji, obrazków i działów. Dla porównania: www.gram.pl natłok nagłówków, napisów, mały rozmiar fontów, jedyny czytelny element to kategorie sprzętowe gier i Super oferty www.grymel.pl za dużo informacji na stronie głównej, zbyt małe odstępy pomiędzy prezentowanymi treściami, mały kontrast pomiędzy działami, małe obrazki nie przyciągną uwagi www.bestgame.pl małe obrazki nieprzyciągające uwagi, nieco przygnębiająca kolorystyka www.3kropki.pl uboga szata graficzna, małe odstępy pomiędzy napisami, brak odpowiednich marginesów, zbyt mały rozmiar fontów, kumulowanie pustej przestrzeni w niewłaściwych proporcjach do treści Założyliśmy z góry, że interfejs użytkownika w naszym projekcie ma nie powielać ww. błędów. GUI graficzny interfejs użytkownika 34

6.3. Koncepcje 6.3.1. Szkic strony głównej Rysunek 1. Szkic strony głównej GUI graficzny interfejs użytkownika 35

7. Projekt systemu Projekt systemu jest o model obiektowy. Wybór takiego sposobu projektowania pozwala zorientować architekturę systemu na niezależne od siebie moduły wielokrotnego. Język UML jest najlepiej znanym językiem modelowania projektowego przez wszystkich członków, ze spośród innych języków do tego celu przeznaczonych. Narzędzia którymi posługiwać się będzie zespół to Umlet i StarUML. Projekt systemu 36

7.1. Diagram przypadków użycia 7.1.1. Dla użytkownika gość Diagram 7.1.1. Diagram przypadków użycia dla użytkownika gość Projekt systemu 37

7.1.2. Dla pracownika, klienta i administratora Diagram 7.1.2. Diagram przypadków użycia dla administratora i klienta Projekt systemu 38