Dokumentacja projektu CCDGI

Transkrypt

1 Dokumentacja projektu CCDGI Strona 1 z 33

2 Spis treści 1.Narzędzia projektowe Założenia projektowe Wymagania klienta Proces biznesowy Mapa myśli Wymagania funkcjonalne Wymagania niefunkcjonalne Harmonogram projektu Raport dla klienta Baza danych Model konceptualny...14 a)słownik danych Kategorie i funkcję użytkowników:...19 a)opis modelu konceptualnego Model fizyczny...23 a)opis modelu fizycznego Implementacja bazy danych GUI graficzny interfejs użytkownika Przeznaczenie grupa docelowa Kolorystyka Koncepcje...34 a)szkic głównej stony...34 Strona 2 z 33

3 1. Narzędzia projektowe. Kierownik zespołu projektowego CCDGI po konsultacji z zespołem, ustala listę narzędzi z 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 Framework ZEND version 1.11 v Framework Symhony ver. 2.0 Design: Adobe Photoshop CS4, commercial licence Testy: Internet Explorer >6, Firefox>5, Chrome, freeware Wspomaganie projektowania: Mindfre, Gliffy, freeware OS: Microsoft Windows 7 SP2, licencja komercyjna na 5 stanowisk 2. Założenia projektowe 2.1. Wymagania klienta. Po przeprowadzeniu w dniu 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. 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 Strona 3 z 33 NIE standardowo Ok 30 klientów dziennie

4 Możliwość dodawania/usuwania produktu 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) 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 Strona 4 z 33 Zgodnie z zainteresowaniem użytkowników

5 2.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 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 . Rola pracownika w tym modelu ogranicza się do nadzorowania przychodzących zamówień w systemie administracji i nadania paczki do klienta. Strona 5 z 33

6 Ilustracja 2.1: Model biznesowy Strona 6 z 33

7 2.3. Mapa myśli Strona 7 z 33

8 Poniższy diagram przedstawia wszelakie pomysły grupy projektowej odnośnie funkcjonalności systemu. Wszystkie funkcjonalności zostaną zaimplementowane przyrosowo, a więc po częściowej implementacji wybranych funkcjonalności, odbywały się będą ich testy oraz konsultacja z klientem. Ilustracja 2.2: Mapa myśli 2.4. Wymagania funkcjonalne Strona 8 z 33

9 Przeglądanie asortymentu sklepu Modyfikowanie asortymentu sklepu Komunikowanie (w formie reklamy/baneru) 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 konsumenta Rejestracja w systemie użytkownika Logowanie do systemu użytkownika Edycja profilu użytkownika 2.5. 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 Strona 9 z 33

10 Wymaganie Miara 80% Wygodny Liczba maksymalnych kroków potrzebnych do wykonania podstawowych czynności 4 Niezawodny 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 back-upów 1 dziennie Strona 10 z 33

11 2.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 r. Dopuszczalne jest przekroczenie o 14 dni terminu podanego powyżej, bez ponoszenia kary umownej ze strony grupy projektowej. Ilustracja 2.3: Tekst 1: Diagram Gaant'a Strona 11 z 33

12 3. 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. Kompletna lista funkcjonalności systemu: Przeglądanie asortymentu sklepu Modyfikowanie asortymentu sklepu Komunikowanie (w formie reklamy/baneru) 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 konsumenta Rejestracja w systemie użytkownika Logowanie do systemu użytkownika Strona 12 z 33

13 Edycja profilu użytkownika 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 Framefork ZEND version 1.11 v Framework Symhony ver. 2.0 Design: Adobe Photoshop CS4 Testy: Intertnet Exploler >6, Firefox>5, Chrome Wspomaganie projektowania: Mindfre, Gliffy Szacowany termin ukończenia r. Koszt projektu ,00 zł Szczegółowe rozliczenie: Programista Analityk Projektant Grafik Kerownik projektu Media Licencje Miesiące Strona 13 z 33

14 4. Baza danych Niniejszy rozdział dokumentuje pełny model relacyjnej bazy danych która będzie wykorzystana do pracy systemu CCDGI 4.1. Model konceptualny Ilustracja 4.1: Model konceptualny Strona 14 z 33

15 a) 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. 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. Strona 15 z 33

16 f. PEGI tagi (opisy zwartości) produkt oznaczany jest maksymalnie siedmioma opisami: Obrazek Treść Przemoc Informacje Dopuszczalne oznaczenia Gra zawiera elementy przemocy. Seks W grze pojawiają się nagość i/lub zachowania seksualne lub nawiązania do zachowań o charakterze seksualnym. Dyskryminacja Gra pokazuje przypadki dyskryminacji lub zawiera materiały, które mogą do niej zachęcać osoby nieletnie. Używki W grze pojawiają się nawiązania do używek lub przedstawiono ich zażywanie. Strach Gra może przestraszyć młodsze dzieci. Wulgarny język W grze jest używany wulgarny język. Hazard Gra online Gry, które zachęcają do uprawiania hazardu lub go uczą. 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 punktów. Przedział punktów Opis oceny Opinia zdecydowanie niechętna Opinia generalnie niekorzystna Opinia mieszana lub średnia Opinia generalnie przychylna Powszechne uznanie Strona 16 z 33

17 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: 4.2. Platformówki Przygodowe Gra fabularna (RPG) MMORPG Sportowe Wyścigowe Gry akcji Bijatyki Strzelanki First-person shootery (FPS) Third-person perspective (TPP) Skradanki Logiczne Symulacyjne Strategiczne Turowe Czasu rzeczywistego (RTS) Przeglądarkowe Kategorie i funkcję użytkowników: 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 2. Klient Strona 17 z 33

18 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) Wybieranie przedmiotów które będzie prowadził f) Ocenianie i komentowanie gier a) Opis modelu konceptualnego 1. Wykaz encji 1.1. Users użytkownicy a) unikatowy identyfikator użytkownika będący jego adresem poczty , 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 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 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 Strona 18 z 33

19 h) youtubeurl adres url do gameplaya gry, typ danych: Text i) price cena gry, typ danych: Number(5,2) j) count ilość kopii gry w magazynie, typ danych: Integer 1.4. Categories kategorie gier 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) 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 1.6. Orders zamówienia a) orderid unikatowy identyfikator zamówienia, klucz pierwotny, typ danych: Serial b) orderdate data zamówienia, typ danych: Date 2. Wykaz asocjacji 2.1. Grades oceny gier wydane przez użytkowników 2.2. grade ocena gry, typ danych: Byte 2.3. comment komentarz gry, typ danych: Text 2.4. adddate data wystawienia oceny, typ danych: Date 2.5. Observed gry obserwowane przez użytkownika 2.6. date data dodania gry do obserwowanych, typ danych: Date 3. Relacje i połączenia asocjacyjne W modelu semantycznym encje zostały połączone następującymi relacjami: 3.1. 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 Games, Publishers relacja jeden do wielu wymagająca przynależności każdej gry do tylko jednego wydawcy. Strona 19 z 33

20 3.5. 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 3.8. 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 Model fizyczny Ilustracja 4.2: Model fizyczny Strona 20 z 33

21 a) Opis modelu fizycznego Na podstawie modelu konceptualnego został wygenerowany następujący model fizyczny bazy danych dla środowiska MYSQL 5.0: 1. Wykaz tabel a) Users użytkownicy unikatowy identyfikator użytkownika będący jego adresem poczty , 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 b) 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 c) 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 Strona 21 z 33

22 price cena gry, typ danych: numeric(5,2) count ilość kopii gry w magazynie, typ danych: int d) 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) e) 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 f) Orders zamówienia orderid unikatowy identyfikator zamówienia, typ danych: int unikatowy identyfikator użytkownika będący jego adresem poczty , 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 g) Grades oceny gier wydane przez użytkowników id unikatowy identyfikator gry, klucz obcy, typ danych: int unikatowy identyfikator użytkownika będący jego adresem poczty , klucz obcy, typ danych: varchar(50) grade ocena gry, typ danych: tinyint Strona 22 z 33

23 comment komentarz gry, typ danych: text adddate data wystawienia oceny, typ danych: date klucz pierwotny złożony z obu kluczy obcych h) Observed gry obserwowane przez użytkownika id unikatowy identyfikator gry, klucz obcy, typ danych: int unikatowy identyfikator użytkownika będący jego adresem poczty , klucz obcy, typ danych: varchar(50) date data dodania gry do obserwowanych, typ danych: date klucz pierwotny złożony z obu kluczy obcych 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 Implementacja bazy danych Poniżej znajduje się pełna implementacja bazy danych. /* DBMS name: /* Created on: MySQL 5.0 */ :27:29 */ drop table if exists Categories; drop table if exists Games; drop table if exists GamesInOrders; drop table if exists GamesPegiTags; Strona 23 z 33

24 drop table if exists Grades; drop table if exists Groups; drop table if exists Observed; drop table if exists Orders; drop table if exists PEGITags; drop table if exists Publishers; drop table if exists Users; /* Table: Categories */ create table Categories ( catname varchar(30) not null, description text, primary key (catname) ); alter table Categories comment 'Games categories'; /* Table: Games */ create table Games ( id int not null auto_increment, Strona 24 z 33

25 catname varchar(30) not null, publishername title varchar(80) not null, varchar(100), description text, releasedate date, pegiurl text, metascore tinyint, coverurl text, youtubueurl text, price numeric(5,2), count int, primary key (id) ); alter table Games comment 'All games in shop'; /* Table: GamesInOrders */ create table GamesInOrders ( orderid id int not null, int not null, primary key (orderid, id) ); /* Table: GamesPegiTags */ create table GamesPegiTags ( id tagid int not null, int not null, Strona 25 z 33

26 primary key (id, tagid) ); /* Table: Grades */ create table Grades ( id int not null, varchar(50) not null, grade tinyint, comment text, adddate date, primary key (id, ) ); alter table Grades comment 'Grades and comments of game written by users'; /* Table: Groups */ create table Groups ( name rights varchar(30) not null, tinyint, primary key (name) ); alter table Groups comment 'Users groups of CCDGI shop. Entity contains rights assingned'; /* Table: Observed */ Strona 26 z 33

27 create table Observed ( id varchar(50) not null, int not null, date date, primary key ( , id) ); alter table Observed comment 'All games observed by users'; /* Table: Orders */ create table Orders ( orderid int not null auto_increment, varchar(50) not null, orderdate date, primary key (orderid) ); alter table Orders comment 'All orders of all users '; /* Table: PEGITags */ create table PEGITags ( tagid tagname tagurl int not null auto_increment, varchar(80), text, primary key (tagid) Strona 27 z 33

28 ); /* Table: Publishers */ create table Publishers ( publishername varchar(80) not null, primary key (publishername) ); /* Table: Users */ create table Users ( varchar(50) not null, name varchar(30) not null, password varchar(30), firstname varchar(30), lastname varchar(30), address postcode city phone newsletter varchar(50), varchar(6), varchar(30), varchar(12), bool, primary key ( ) ); alter table Users comment 'All users of this system. Clients and shop employees '; Strona 28 z 33

29 alter table Games add constraint FK_Relationship_2 foreign key (catname) references Categories (catname) on delete restrict on update restrict; alter table Games add constraint FK_Relationship_3 foreign key (publishername) references Publishers (publishername) on delete restrict on update restrict; alter table GamesInOrders add constraint FK_GamesInOrders foreign key (orderid) references Orders (orderid) on delete restrict on update restrict; alter table GamesInOrders add constraint FK_GamesInOrders2 foreign key (id) references Games (id) on delete restrict on update restrict; alter table GamesPegiTags add constraint FK_GamesPegiTags foreign key (id) references Games (id) on delete restrict on update restrict; alter table GamesPegiTags add constraint FK_GamesPegiTags2 foreign key (tagid) references PEGITags (tagid) on delete restrict on update restrict; alter table Grades add constraint FK_Grades foreign key (id) references Games (id) on delete restrict on update restrict; alter table Grades add constraint FK_Grades2 foreign key ( ) references Users ( ) on delete restrict on update restrict; alter table Observed add constraint FK_Observed foreign key ( ) references Users ( ) on delete restrict on update restrict; alter table Observed add constraint FK_Observed2 foreign key (id) references Games (id) on delete restrict on update restrict; alter table Orders add constraint FK_Relationship_4 foreign key ( ) references Users ( ) on delete restrict on update restrict; Strona 29 z 33

30 alter table Users add constraint FK_Relationship_1 foreign key (name) references Groups (name) on delete restrict on update restrict; Strona 30 z 33

31 5. 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 Przeznaczenie grupa docelowa Serwis kierowany jest do szerokiej grupy odbiorców od nastolatków do latków z przewagą płci męskiej 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: natłok nagłówków, napisów, mały rozmiar fontów, jedyny czytelny element to kategorie sprzętowe gier i Super oferty 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 małe obrazki nieprzyciągające uwagi, nieco przygnębiająca kolorystyka 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. Strona 31 z 33

32 5.3. Koncepcje a) Szkic głównej stony Ilustracja 5.1: Szkic strony głównej Strona 32 z 33

33 6. Projekt systemu 6.1. Diagram przypadków użycia 6.2. Diagram klas a) Diagram Ilustracja 6.1: Diagram klas b) 6.3. Opis diagramu klas Diagram sekwencji 6.4. Strona 33 z 33