**STRONA PROJEKTU Z_IMPETEM_PRZEZ_SWIAT**

Kisielewski Marcin, Kokosza Łukasz, Jop Mateusz

Projekt ten jest częścią bazodanową projektu gry internetowej, który realizujemy na przedmiocie Technologie i Programowanie WWW.

Przedstawienie zadania projektowego

Celem pracy jest zaprojektowanie oraz zaimplementowanie gry internetowej wraz z wszystkimi potrzebnymi systemami oraz jego prezentacja. W rzeczywistości oznacza to zaprogramowanie wszystkich systemów gry internetowej w oparciu o wybrane technologie.

Wybór technologii dokonany został na podstawie:

  • Wymagań postawionych przed systemem
  • Popularności
  • Prostocie interfejsu
  • Możliwości rozwoju

Poprzez cały system gry internetowej rozumiane jest:

  • baza danych (SQL)
  • interfejs do bazy danych
  • silnik gry (Java)
  • szata graficzna
  • aplety interaktywne

Każdy z podsystemów będzie stworzony do formy, w której umożliwi podstawowe operacje na systemie. Wynikiem nie będzie pełna gra internetowa, a jedynie przykład możliwości pisanego silnika i systemów pomocniczych.

Analiza stanu wyjściowego

Współczesny rynek gier internetowych jest prężnie rozwijającą się gałęzią przemysły internetowego. Z tego powodu powstało dużo nowych portali związanych z grami internetowymi. Mimo istnienia dużej ilości tego typu stron, rynek nie został w pełni nasycony co daje dużą szansę na sukces nowo powstałego portalu. Odpowiednia reklama oraz ciekawa fabuła gry wraz z innowacyjnością produktu powinna zagwarentować zdobycie odpowiedniej ilości użytkowników co jest bezpośrednio związane z osiągnięciem sukcesu na tym rynku.

Analiza wymagań użytkownika

Główne funkcjonalności (Must have):

  • rejestracja oraz logowanie do serwisu
  • niezalogowany użytkownik będzie miał dostępne informacje o grze oraz możliwościach rejestracji
  • zalogowany użytkownik będzie miał możliwość zagrania w grze
  • wybór bota oraz jego parametrów
  • możliwość zmiany ustawień strony
  • możliwość zarobienia pieniędzy przez klikanie na reklamy
  • gracz bedzie mógł zbierać punkty oraz tracić życia
  • archiwizacja gry
  • ranking graczy

Dodatkowe funkcjonalności (Could have):

  • stworzenie więcej niż jednego świata gry
  • stworzenie systemu płatności

Określenie scenariuszy użycia

  1. Scenariusze dla Użytkownika niezalogowanego:
    1. Dostęp do serwisu:
      • Rejestracja w systemie
    2. Przeglądanie treści serwisu:
      • Zapoznanie się z zasadami serwisu
      • Zapoznanie się z zasadami gry
      • Możliwość oglądnięcia screenów z gry
      • Mozliwość nawiązania kontakru z serwisu
    3. Główne funkcjonalności:
      • Jeszcze się określi
  2. Scenariusze dla Użytkownika zarejestrowanego:
    1. Dostęp do serwisu:
      • Zalogowanie do systemu
      • Przypomnienie hasła użytkownika
    2. Zarządzanie kontem:
      • Zmiana danych użytkownika
      • Zmiana ustawień strony
      • Usuwanie konta
    3. Główne funkcjonalności:
      • Możliwość gry
      • Mozliwość zarobienia pieniędzy
  3. Scenariusze dla Administratora:
    1. Zarządzanie użytkownikami:
      • Zmiana danych użytkownika
      • Usuwanie użytkownika
      • Zmiana uprawnień użytkownika
    2. Zarządzanie treścią serwisu:
      • Moderacja serwisu

Studium wykonalności

Studium wykonalności składa się z szeregu analiz, mianowicie: analizy rynku, analizy ekonomicznej, analizy technicznej i analizy strategicznej. Pozwala ono na oszacowanie kosztów i prawdopodobieństwa powodzenia projektu. Analiza rynku polega na zbadaniu zapotrzebowania, osiągnięć konkurencji i prognozy sprzedaży (analiza marketingowa). Poniżej zamieszczony został opis konkurencyjnych portali.

Ogame:

OGame jest kosmiczną grą strategiczną. Tysiące graczy zbiera się jednocześnie, by grać ze sobą lub przeciw sobie. Aby zagrać użytkownik potrzebuje tylko zwykłej przeglądarki internetowej. Międzygalaktyczny podbój polega na zbudowaniu własnej potężnej kolonii, która później umożliwi najazd i zagrabienie klonii innych graczy. Użytkownicy również muszą się bronić przed najazdami innych graczy oraz gromadzić materiały do dalszej rozbudowy. Dochody gry pochodzą głownie z reklam oraz płatnych opcji, które pozwalają zautomatyzować niektóre fragmenty gry co znacznie ułatwia graczom zarządzanie wirtualnym światem. Na obecną chwilę polska wersja OGame skupia ponad 1 milion graczy co przekłada się na kolosalne zyski.

Plemiona:

Plemiona to przeglądarko wa gra online, której akcja osadzona została w średniowieczu. Każdy gracz posiada małą wioskę, którą ma doprowadzić do władzy i chwały. Na dzień pisania dokumentu na portalu jest zarejestrowanych ponad 500 tys. graczy, którzy codziennie odwiedzają stronę by móc bardziej rozwinąć swoje „posiadłości”, co da im większy prestiż wśród innych użytkowników. Podobnie jak OGame zyski pochodzą z reklam i dodatkowych opcji ułatwiających grę, które można wykupić płacąc kartą kredytową lub wysyłając SMS.

Eurobarre:

Eurobarre jest aplikacją internetową francuskiej firmy o takiej samej nazwie. Program służy do zarabiania poprzez internet bez wychodzenia z domu. Program działa na zasadzie wypożyczania naszego ekranu komputera w celu reklam. Użytkownikowi programu otwiera się malutkie okno, które zawsze jest na wierzchu i są na nim wyświetlane różne reklamy. Użytkownik dostaje odpowiednią kwotę w euro za odpowiedni czas wyświetlania.

System umożliwia jeszcze dwa sposoby zwiększenia swoich zarobków. Pierwszy z nich polega na klikaniu w wyświetlane reklamy, za co dostajemy dodatkowe eurocenty. Drugi system wymaga głębszego zapoznania się z wyświetloną stroną ponieważ po przeczytaniu reklamy jesteśmy zobligowani do uzupełniania krótkiej ankiety internetowej w której zadane zostały pytania odnośnie reklamowanego produktu. Jeżeli odpowiedzi są poprawne, to na nasze konto zostanie przelana odpowiednia kwota euro.

Wnioski:

Zważając na fakt istnienia wielu książek opisujących problemy wchodzące w zakres tematu niniejszej pracy, wiedzę uzyskaną poprzez studia oraz własne zainteresowania możemy stwierdzić, iż temat pracy jest możliwy do realizacji i w pełni wykonywalny. Ostatnio nastąpił bardzo dynamiczny rozwój gier on-line przez przeglądarkę internetową, które skupiają coraz więcej graczy. Duża ilość graczy pozwala twórcom czerpać adekwatne korzyści majątkowe z reklam oraz udostępniania płatnych usług. Biorąc pod uwagę powyższe dane i argumenty, zasadnym jest stwierdzenie, że temat niniejszej pracy jest w pełni wykonywalny i prawdopodobnie opłacalny. Jedynym pytaniem o studium wykonalności jest pytanie: „Jak bardzo posuną się prace nad rozwojem tematu, którego opracowanie ogranicza czas?” Odpowiedź na nie zostanie zamieszczone w końcowej części niniejszego studium. W celu ograniczenia ryzyka przyjęte zostaje założenie, że na początku każdy z podsystemów będzie swoją podstawową wersją. Kolejnym etapem pracy będzie rozbudowany opis odpowiednich systemów. Ostatnim etapem konstruowania treści studium będzie poddanie projektowanego systemu szacowaniu dwoma najpopularniejszymi metodami. Zatem początkowe ryzyko zostanie obniżone do minimum, a pewność ukończenia pracy w zadanym terminie osiągnie swój maksymalny poziom.

Innowacyjność produktu:

Jak zostało stwierdzone w wcześniejszych punktach, na obecnym rynku istnieje dość obszerna konkurencja. W celu wejścia na planowany rynek, potrzebujemy więc jakieś nowości, oraz dobrego systemu zarobkowego aby się na nim utrzymać.

System zarabiania poprzez banery:

Wraz z popularyzacją naszego portalu oraz wzrostem ruchu na naszej stronie uważamy, iż będziemy mogli zacząć zarabiać również na reklamach. W tym celu będziemy chcieli nawiązać współpracę z portalami, które zajmują się tego typu reklamami i czerpaniem z tego profitów.

System zarabiania poprzez sms, ing itp:

W grze przewidujemy zaimplementowanie dodatkowych opcji ułatwiających zarządzanie wirtualnym światem. Uproszczenie gry polegało będzie głównie na automatyzacji niektórych opcji lub możliwości wykupienia dodatkowych wirtualnych surowców (wirtualne pieniądze, paliwo itp.). Owe dodatkowe opcje oraz surowce będzie można wykupić poprzez płatność sms lub przelew bankowy (płatność kartą).

System zarabiania poprzez reklamy użytkownika:

W systemie planujemy wprowadzenie euro Pumeksów które będzie można nabyć za pośrednictwem systemu płatności lub systemu zarobkowego. Pumeksoporyt służyć będą do wykupienia odpowiednich dodatkowych usług udostępnianiach przez portal. Użytkownik będzie mógł zakupić za euro Pumeksy jednie usługi świadczone przez nasz system. Każdy zalogowany uczestnik portalu będzie mógł zdobyć euro Pumeksy poprzez klikanie w wyświetlane reklamy. Za każde kliknięcie będzie otrzymywał odpowiednią ilość punktów, za które będzie mógł wykupić określoną usługę. Taki system zarabiania jest bardzo popularny w internecie i działa na zasadzie Google.

System zarabiania poprzez ankiety internetowe:

Euro Pumeksy będzie można zdobyć też w sposób troszkę trudniejszy aczkolwiek bardziej dochodowy z względu na punkty. Na specjalnej stronie będą umieszczone ankiety internetowe, z podanymi źródłami wiedzy jaką należy zdobyć aby otrzymać odpowiednią wiedzę. Jeżeli użytkownik wypełni poprawnie ankietę, to na jego konto zostanie przelana odpowiednia ilość punktów. Portal będzie otrzymywał zyski od odpowiednich reklamodawców którzy będą płacić od wypełnionej ankiety.

Wymagania

Wymagania po stronie serwera:

  • Co najmniej 100MB wolnej przestrzeni dyskowej
  • Co najmniej 64MB dostępnej pamięci RAM
  • serwer Tomcat lub glassfish
  • obsługa baz danych – Postgress, MySQL
  • atrakcyjna domena internetowa w formie domena
  • transfer 6Gb/ miesiąc
  • 5 kont Ftp
  • 5 kont email
  • bez limitów jednoczesnych połączeń na serwer

Wymagania po stronie użytkownika:

  • Zainstalowana paczka Java Run time environment 1.4.2
  • Procesor Pentium 166Mhz lub odpowiednik AMD
  • co najmniej 125MB wolnego miejsca na dysku twardym
  • co najmniej 32MB pamięci RAM
  • Co najmniej 32MB pamięci RAM
  • Co najmniej 100MB wolnej pamięci na dysku twardym
  • Przeglądarka internetowa(IE 5.0, Mozilla 2.0 lub nowsze
  • Aktywna obsługa cookies
  • Aktywna obsługa Javascript

Szacowanie systemu

Dzięki zastosowaniu szacowania systemu w początkowej fazie uzyskujemy wstępne rozmiary pracy, jaką będziemy musieli włożyć w celu zakończenia projektu. Szacowanie w projektach informatycznych posiada bardzo duży współczynnik błędu, który wynosi w granicy 30%. Każdy projekt informatyczny powinien być więc szacowany. Projekty szacuje się w celu uzyskania w miarę możliwości względnego czasu potrzebnego na jego ukończenie, przy żądanej ilości pracowników. W przypadku niniejszej pracy szacowanie odbyło się kilkakrotnie, z rożnymi współczynnikami. Przedstawione wyniki są odpowiednie do uzyskanych rezultatów projektu. Dodatkowym atutem, jaki został uzyskany przy szacowaniu pracy, jest stwierdzenie, co tak naprawdę uda się wykonać w czasie, jaki pozostał do ukończenia pracy. Przez oszacowanie, projekt uzyskał wymagania, które mogą zostać ukończone w terminie.

Metodyka delficka

Metodyka delficka szacowania polega na wykonaniu przez fachowców ekspertyz, które zostają porównane. Jeżeli wyniki są znacząco rożne wykonuje się konfrontację ekspertów w celu uzyskania zgodnych wyników (według wszystkich ekspertów). Konfrontacje wykonuje się często w anonimowy sposób. Oznacza to, że eksperci nie są świadomi, który z nich wykonał daną ekspertyzę, co daje im możliwość zachowania większej pewności siebie. W końcowym etapie często za zgodą ekspertów, ujawnia się ich dane i przeprowadza jawną rozmowę w celu udoskonalenia szacowania. W przypadku tej pracy szacowanie metodą delficką zostało zmodyfikowane do przeprowadzenia wyłącznie kilku wywiadów z osobami, które miały styczność z technologią obejmującą implementowany system. Wywiady zostały przeprowadzone słownie. Ekspertami byli więc:

  • dr Sebastian Ernst
  • dr Konrad Kułakowski
  • Inni prowadzący zajęcia, od których wiedza została uzyskana w trakcie wywiadu oraz na zajęciach przez nich prowadzonych.
  • Studenci informatyki (koledzy z roku) – okazało się, że kilka osób miało styczność z wybranymi dziedzinami, przez co mogli udzielić porad o typowych problemach oraz czasie potrzebnym do realizacji określonych klas.
  • Uczestnicy odpowiednich forów internetowych, którym zostały zadane pytania. Ich odpowiedzi były traktowane jednak jako mało znaczące ze względu na fakt, iż Internet nie stanowi żadnego, pewnego źródła informacji.
  • Dodatkowym kryterium były dane statystyczne uzyskane za pośrednictwem grupy IFPUG (www.ifpug.org), w których omówione zostały wybrane problemy i czasy ich rozwiązań.

W wyniku przeprowadzonych badań, zostało wysunięte następujące stwierdzenie: zaprojektowanie systemu (silnika gry) wraz z jego implementacją oraz odpowiednie udokumentowanie kodu jest możliwe do przeprowadzenia w czasie nie większym niż 5 miesięcy przez trzy osoby jedynie w przypadku spełnienia minimalnych wymagań jakie zostały postawione przed systemem. Określenie większych wymagań może spowodować przekroczenie ram czasowych projektu, co w wypadku projektu uczelnianego jest niedopuszczalne. Eksperci zwrócili też uwagę na fakt, że określone 5 miesięcy nie jest w pełni tego słowa znaczeniu, ponieważ projekt jest tworzony w trakcie trwania studiów, co za tym idzie autorzy będą potrzebowali jeszcze wygospodarować czas na zajęcia oraz praktyki, które będą się odbywać semestrze studiów. Według metodyki delfickiej projekt jest więc wykonalny z postawionymi wymaganiami.

Zastosowane technologie i narzędzia

  • Hibernate - framework do realizacji warstwy dostępu do danych (ang. persistance layer).
  • PostgreSQL, MySQL, HSql– systemy zarządzania relacyjnymi bazami danych.
  • Tomcat, Glass Fish - serwer
  • Java – obiektowy język programowania.
  • Javascript – obiektowy skryptowy język programowania.
  • Ajax - technologia tworzenia aplikacji internetowych, w której interakcja użytkownika z serwerem odbywa się bez przeładowywania całego dokumentu, w sposób * asynchroniczny.
  • CSS - (ang. Cascading Style Sheets, CSS) to język służący do opisu formy prezentacji (wyświetlania) stron WWW.
  • UML 2.0 - (ang. Unified Modeling Language, czyli Zunifikowany Język Modelowania) – język formalny służący do opisu świata obiektów w analizie obiektowej (ang. * Object-oriented analysis) oraz programowaniu obiektowym (ang. Object-oriented programming).
  • Eclipse - platforma (framework) napisana w Javie do tworzenia aplikacji typu Rich Client
  • spring - jest szkieletem tworzenia aplikacji (ang. application framework) w języku Java dla platformy Java EE/J2EE
  • Visio – program modelowania grafiki
  • OpenOffice – edytor tekstowy
  • dbcreator – program modelowania baz danych
  • mozilla 3, IE6 – przeglądarki internetowe
  • JSP - (ang. JavaServer Pages) to technologia umożliwiająca tworzenie dynamicznych dokumentów WWW w formatach HTML, XHTML, DHTML oraz XML z wykorzystaniem języka Java, wplecionego w kod HTML danej strony.

Diagram Przypadków użycia

Diagram struktury statycznej

Diagram struktury bazodanowej

Scenariusze użcia

Nazwa Reklama portalu
Numer 1.01.2010
Twórca Marcin Kisielewski
Poziom ważności Wysoki
Typ przypadku użycia Ogólny / niezbędny
Aktorzy Internautaq
Krótki opis Określa sposób zachowania systemu dla otwarcia portalu przez zwykłego internautę nie zalogowanego w systemie
Warunki wstępne Wysłanie zapytania na portal przez internautę
Warunki końcowe Brak aktywności internauty przez 30min
Główny przepływ zdarzeń wejście internauty na główną stronę portalu –> wyświetlenie reklamy portalu –> otwarcie animacji nakłaniających do zarejestrowania się użytkownika
Alternatywny przepływ zdarzeń wejście internauty na główną stronę portalu –> kliknięcie w baner reklamowy zewnętrzny –> otworzenie się nowej karty z banera reklamowego –> powrót do strony portalu – główny przepływ zdarzeń
Specjalne wymagania Wysoka niezawodność
Notatki i uwagi Strona główna musi być dobrana w odpowiednią szatę graficzną tak aby ładowanie strony internetowej odbywało się płynnie, sama zaś szata musibyć piękna.:)
Nazwa Rejestracja użytkownika
Numer 1.01.2010
Twórca Łukasz Kokosza
Poziom ważności Wysoki
Typ przypadku użycia Szczegółowy / istotny
Aktorzy Internauta, system, administrator
Krótki opis Rejestrowanie nowych użytkowników wraz z walidacją podanego adresu email
Warunki wstępne wolne konta na serwisie, niezalogowany użytkownik
Warunki końcowe poprawna walidacja adresu email
Główny przepływ zdarzeń wejście internauty na główną stronę portalu –> kliknięcie przez internautę odsyłacza rejestracji –> poprawne wpisanie danychużytkownika –> założenie konta na portalu –> wysłanie wiadomości email z linkiem aktywującym konto –> kliknięcie przez internautę linku aktywującego konto –> uaktywnienie konta
Alternatywny przepływ zdarzeń wejście internauty na główną stronę portalu –> kliknięcie przez internautę odsyłacza rejestracji –> brak możliwości rejestracji z powodu braku wolnych kont na portalu –> wyświetlenie informacji o terminie utworzenia nowych kont
Specjalne wymagania Szyfrowanie hasła do zalogowania
Notatki i uwagi Brak reklam na formularzu rejestracyjnym
Nazwa Zalogowanie i gra
Numer 1.01.2010
Twórca Mateusz Jop
Poziom ważności Wysoki
Typ przypadku użycia Ogólny / niezbędny
Aktorzy Internauta, użytkownik, system
Krótki opis Logowanie do systemu wraz z rozpoczęciem sesji gry
Warunki wstępne Niezalogowany użytkownik
Warunki końcowe Wylogowanie
Główny przepływ zdarzeń wejście internauty na główną stronę portalu –> kliknięcie internauty na link logowania –> wpisanie poprawnego loginu oraz hasła –> zalogowanie do systemu –> przekierowanie do panelu gry –> akcje użytkownika związane z grą –> wylogowanie lub utracenie sesji po określonym czasie nieaktywności 30min
Alternatywny przepływ zdarzeń wejście internauty na główną stronę portalu –> kliknięcie internauty na link logowania –> kliknięcie internauty w link przypominający hasło –> wpisanie loginu oraz adresu email –> walidacja przez system oraz przesłanie nowego hasła na adres email –> utracenie ważności sesji, restart sesji
Specjalne wymagania Szyfrowanie haseł
Notatki i uwagi Formularz przypominający hasła należy wykonać w ostatnim etapie, gdy znane już będą sposoby szyfrowania
Nazwa Kasowanie konta
Numer 1.01.2010
Twórca Marcin Kisielewski
Poziom ważności Niski
Typ przypadku użycia Ogólny / przeciętnie istotny
Aktorzy Użytkownik, administrator
Krótki opis Kasowanie konta na serwisie
Warunki wstępne Zalogowany użytkownik
Warunki końcowe Kasacja konta
Główny przepływ zdarzeń wybranie linka kasującego konto –> potwierdzenie kasacji konta poprzez wpisanie powtórne adresu email podanego przy rejestracji –> wylogowanie automatyczne z systemu
Alternatywny przepływ zdarzeń Wybranie linku kasowania konta –> brak potwierdzenia kasacji konta
Specjalne wymagania Brak
Notatki i uwagi Brak reklam, małe linki kasacji
Nazwa System płatności SMS
Numer 1.01.2010
Twórca Łukasz Kokosza
Poziom ważności Wysoki
Typ przypadku użycia Ogólny / istotny
Aktorzy Użytkownik, administrator, system płatności
Krótki opis Sposób zapłaty za dodatkowe funkcje i brak reklam poprzez wiadomość sms
Warunki wstępne Zalogowany użytkownik
Warunki końcowe Doładowanie konta
Główny przepływ zdarzeń wybranie odpowiedniego odsyłacza przez użytkownika –> wyświetlenie informacji z numerem telefonu oraz tekstem wiadomości jaki należy wysłać w celu doładowania konta –> wysłanie sms przez użytkownika –> informacja z zewnętrznego systemu o dokonaniu płatności –> wysłanie wiadomości email do użytkownika o dokonaniu przez niego płatności
Alternatywny przepływ zdarzeń brak informacji z zewnętrznego systemu, informacja dla użytkownika o możliwości skontaktowania się z administratorem systemu
Specjalne wymagania Wykorzystanie zewnętrznego systemu płatności sms(Pay)
Notatki i uwagi Szyfrowanie połączenia pomiędzy zewnętrznym systemem a portalem
Nazwa System płatności bankowej internetowej
Numer 1.01.2010
Twórca Mateusz Jop
Poziom ważności Średni
Typ przypadku użycia Ogólny / istotny
Aktorzy Użytkownik, administrator, system
Krótki opis Sposób zapłaty za dodatkowe funkcje i brak reklam poprzez bankowość internetową
Warunki wstępne Zalogowany użytkownik
Warunki końcowe Doładowanie konta
Główny przepływ zdarzeń wybranie odpowiedniego odsyłacza przez użytkownika –> wyświetlenie informacji z numerem konta oraz tytułem przelewu jaki należy wysłać w celu doładowania konta –> wykonanie przelewu przez użytkownika –> informacja z zewnętrznego systemu o dokonaniu płatności –> wysłanie wiadomości email o dokonaniu płatności
Alternatywny przepływ zdarzeń brak informacji z zewnętrznego systemu, informacja dla użytkownika o możliwości skontaktowania się z administratorem systemu
Specjalne wymagania Wykorzystanie zewnętrznego systemu płatności sms(Pay)
Notatki i uwagi Szyfrowanie połączenia pomiędzy zewnętrznym systemem a portalem
Nazwa System zarobkowy reklam klienta
Numer 1.01.2010
Twórca Marcin Kisielewski
Poziom ważności Średni
Typ przypadku użycia Ogólny / istotny
Aktorzy Użytkownik, administrator, system
Krótki opis Doładowanie konta użytkownika poprzez klikanie w banery reklamowe portalu
Warunki wstępne Zalogowany użytkownik
Warunki końcowe Doładowanie konta
Główny przepływ zdarzeń wybranie przez użytkownika odsyłacza do systemu zarobkowego użytkownika –> wybranie opcji klikasz –> klikanie użytkownika w banery reklamowe, nie częściej jak określony interwał przez klienta reklamodawcę –> otwarcie nowej karty z reklamą portalu z banera –> doładowanie odpowiedniej ilości punktów na konto użytkownika –> wysłanie wiadomości email o doładowaniu konta
Alternatywny przepływ zdarzeń Brak reklam, lub wykorzystany dzienny limit klikacza –> wyświetlenie odpowiedniej informacji z zaproszeniem w późniejszym terminie
Specjalne wymagania Wysoka niezawodność oraz dobrze zabezpieczony system naliczania punktów z reklam banerowych
Notatki i uwagi Należy zwrócić szczególną uwagę na system zabezpieczeń doładowania punktów. Nie należy dopuścić do sytuacji w której użytkownik posiadał by możliwość nabycia punktów poprzez wpisanie odpowiedniego adresu http lub przez skorzystanie z odpowiedniego programu wysyłającego zapytania do portalu, czy też próbie zmiany bazy danych SQL.
Nazwa System zarobkowy ankiet
Numer 1.01.2010
Twórca Łukasz Kokosza
Poziom ważności Średni
Typ przypadku użycia Ogólny / istotny
Aktorzy Użytkownik, administrator, system
Krótki opis Doładowanie konta użytkownika poprzez oglądanie stron reklamodawców i następne wypełnienie ankiety sprawdzającej uzyskaną wiedzę z ankiet
Warunki wstępne Zalogowany użytkownik
Warunki końcowe Doładowanie konta
Główny przepływ zdarzeń wybranie przez użytkownika odpowiedniego odsyłacza do systemu zarobkowego poprzez ankiety → wyświetlenie listy stron wraz z krótkim opisem kategorii przynależności strony –> wyświetlenie wybranej strony internetowej w postaci nowej karty –> ukazanie się w panelu zarobkowym ankiety internetowej –> wypełnienie ankiety przez użytkownika –> weryfikacja poprawności odpowiedzi, dokonywana według wytycznych dostarczonych przez reklamodawców –> w przypadku pozytywnej weryfikacji, dodanie odpowiedniej ilości punktów do stanu konta użytkownika –> wysłanie wiadomości email potwierdzającej dodanie odpowiedniej ilości punktów
Alternatywny przepływ zdarzeń Brak dostępnych ankiet –> Wyświetlenie informacji z podane przybliżonego terminu nowych ankiet
Specjalne wymagania Jeden użytkownik może tylko jeden raz wypełnić jedną ankietę
Notatki i uwagi Uwaga na poprawne odpowiedzi. System powinien w możliwie łatwy sposób sprawdzać poprawność ankiet bez udziału administratorów

Encje podstawowe

Użytkownik – każdy gracz będzie posiadał swój unikalny identyfikator będący kluczem głównym określonym jako id_uzytkownika oraz takie pola jak login, hasło, adres e mail, data urodzenia, zdobyte punkty oraz zestaw kluczy obcych, które są kluczami głównymi innych encji takich jak reklama, ankieta, świat, bagaż, adres.

Swat – obecnie przyjęliśmy ze będą w naszej grze dwa światy, dlatego encja ta posiada identyfikator będący kluczem głównym. W tym obiekcie będziemy pamiętać aktualne położenie na mapie gry, Obiekt ten będzie pamiętał identyfikatory aktualnie toczonych bitew. Bitwy będą mogły odbywać się pomiędzy dwoma graczami, albo graczem i komputerem. Pamiętane są również klucze obce encji pogoda, artefakt oraz bitwy.

BitwaUzytkownikow oraz BitwaPrzeciwnik są to dwie encje, które zapamiętują aktualne położenie na mapie świata, oraz posiadają identyfikatory dwóch toczących walkę ze sobą użytkowników, lub walkę użytkownika z komputerowym stworem. Przyjęliśmy założenie, że klucze główne tych dwóch encji mają wartości unikalne.

Adres – encja przechowująca informacje dotyczące adresu zamieszkania użytkownika. Zawiera takie pola jak: ulica, numer domu, miejscowość oraz klucz obcy do encji KodPocztowy.

Reklama – obiekt zawierający pola takie jak identyfikator użytkownika, nazwa reklamy, opis oraz czy jest ona widoczna czy nie. Zdefiniowany tez jest klucz główny id_reklamy.

Bagaz – użytkownik będzie mógł zbierać różne artefakty i ta encja służy do ich przechowywania. Zawarte tu będą informacje dotyczące doświadczenia, zbroi, broni.

Szata graficzna

W naszym projekcie, aby w łatwy sposób kontrolować i formatować wygląd stron WWW zastosujemy kaskadowe arkusze stylów. CSS jest sposobem na oddzielenie strukturalnych elementów witryny od jej prezentacji. Pozwala na zmianę architektury dokumentów i ograniczenie ich rozmiarów do minimum, zachowując jednocześnie pełną kontrolę nad wyglądem witryny. Użytkownik może zmieniać rozmiar i kolor czcionki oraz inne elementy wyglądu z jednego pliku CSS. Wygląd witryny która nie została zaprojektowane w CSS może się różnić między przeglądarkami. CSS ułatwia normalizację witryny i zbliżenie jej wyglądu do zamierzonego. Zaletą tej techniki jest również to, że jest tylko jeden arkusz, który zarządza wszystkimi stronami witryny. CSS zapewnia jednorodność w wyglądzie strony. Arkusze tworzą efekt kaskadowy, tzn. komunikują się z przeglądarką w celu stworzenia jednolitego formatu dla użytkownika. Absolutnie nie trzeba się obawiać stosowania CSS, ponieważ nie powodują one błędów w przeglądarkach, które ich nie obsługują. Nigdy nie zdarzy się tak, aby strona w ogóle nie została wyświetlona, ponieważ korzysta z CSS. Jeżeli przeglądarka nie obsługuje stylów, po prostu je pominie.

Domena i serwer

Do umieszczenia strony w internecie będzie potrzebny dobry serwer, który zapewni odpowiedni hosting portalu. Aby uzyskać odpowiedni „prestiż” w sieci będzie również potrzebna reprezentatywna domena. Jako domenę wybraliśmy „.pl”, a hosting zamierzamy rozpocząć na portalu „nazwa.pl”. Roczny koszt utrzymania będzie wynosił ok. 300zł. Na początek jest możliwość wykupienia w promocji serwera za 100zł na pół roku i w razie powodzenia projektu możliwość przedłużenia współpracy

Koszta utrzymania

Roczny koszt utrzymania hostingu i domeny będzie wynosił ok. 300zł. Na początek jest możliwość wykupienia w promocji serwera za 100zł na pół roku i w razie powodzenia projektu możliwość przedłużenia współpracy.

Postacie normalne

Pierwsza postać normalna Baza danych spełniająca pierwszą postać normalną musi składać się z tabel, które zawierają dane wzajemnie powiązane, musi zawierać unikalne powiązanie pewnych grup danych oraz muszą byc wskazane klucze główne poszczególnych tabel. Nasza baza danych spełnia pierwszą postać normalną ponieważ wszystkie tabele posiadają ściśle ze sobą powiązane dane np. tabela user_table posiada informacje na temat użytkownika takie jak jego imie, nazwisko, adres, adres e-mail. Wszystkie dane w tej tabeli są ze sobą ścisle powiązanie, nie ma niepotrzebnych lub powielających się elementów. Po rozdzieleniu danych pomiędzy tabele należało je powiązać ze sobą za pomocą unikalnych wartości zwanych identyfikatorami, dlatego każda tabela w naszej bazie posiada klucz główny, np. tabela abstractuser_table posiada identyfikator o nazwie id. Należy pamiętać, że stosowanie dodatkowych identyfikatorów jest korzystne ze względu na wyższą efektywność przeszukiwania danych.

Druga postać normalna Pierwsza postać normalna wymagała wskazania klucza głównego w każdej z tabel bazy danych. Klucz główny może się składać z jednej lub wielu kolumn. Pełni on funkcję unikalnego identyfikatora rekordu. Zgodnie z drugą postacią normalną nie mogą istnieć żadne nawet częściowe zależności pomiędzy jakimikolwiek kolumnami wchodzącymi w skład klucza głównego. Nasza baza danych spełnia drugą postać normalną ponieważ w żadnej tabeli nie wystepuje pola, które by zależały od innego pola tej tabeli. Przykładowo druga postać normalna by nie była spełniona jeżeli np. posiadalibyśmy tabelę w której mielibyśmy dwa klucze główne idUser oraz idWorld. Najlepszym sposobem na rozwiązanie tego problemu byloby rozdzielenie danych na dwie tabele oraz utworzenie trzeciej, która będzie zawierała identyfikatory użytkownika oraz świata.

Trzecia postać normalna Trzecia postać normalna ma charakter opcjonalny a jej stosowanie w znacznej mierze jest uzależnione od okoliczności. Tabele znajdują się w trzeciej postaci normalnej tylko wtedy, gdy spełniają następujące warunki: tablele znajdują się w drugiej postaci normalnej oraz wszystkie pola, które nie należa do klucza głównego są od niego zależne. Zależność pól spoza klucza głównego dotyczy oczywiście zawartych w nim danych. Nasza baza danych spełnia trzecia postać normalna ponieważ tabela address_user zawiera pola takie jak ulica, numer domu, miasto, państwo i idPostcode, który jest identyfikatorem tabeli postcode_table zawierającej kody pocztowe miejscowości. Widać tutaj, że dane dotyczące adresu śa ścisle związane z kodem pocztowym. Kiedy wysyła sie list to nazwa ulicy, numer domu, miejscowość i wlaśnie kod pocztowy wystarczą do odnalezienia własciwego adresu. Zaletą trzeciej postaci normalnej jest spójność danych. Wydobywanie odpowiednich danych z bazy danych zgodnej z trzecia postacią normalną trwa dlużej. W przypadku małych baz różnice są minimalne, jednak z punktu widzenia użytkowników baz danych z tysiącami lub milionami rekordów takaie spowolnienie może mieć olbrzymie znaczenie.

Implementacja

pom.xml

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
  <modelVersion>4.0.0</modelVersion>
  <groupId>org</groupId>
  <artifactId>gra</artifactId>
  <packaging>war</packaging>
  <version>0.0.1-SNAPSHOT</version>
  <name>gra Maven Webapp</name>
  <url>http://maven.apache.org</url>
   <dependencies>
    <dependency>
      <groupId>junit</groupId>
      <artifactId>junit</artifactId>
      <version>3.8.1</version>
      <scope>test</scope>
    </dependency>
    <dependency>
    	<groupId>org.hibernate</groupId>
    	<artifactId>hibernate</artifactId>
    	<version>3.2.6.ga</version>
    </dependency>
    <dependency>
    	<groupId>javax.transaction</groupId>
    	<artifactId>jta</artifactId>
    	<version>1.1</version>
    	<type>jar</type>
    	<scope>compile</scope>
    </dependency>
   </dependencies>
  <build>
    <finalName>strona_hibernate_v1</finalName>
  </build>
</project>
 

hibernate.cfg.xml

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE hibernate-configuration PUBLIC
		"-//Hibernate/Hibernate Configuration DTD 3.0//EN"
		"http://hibernate.sourceforge.net/hibernate-configuration-3.0.dtd">
 
<hibernate-configuration>
    <session-factory>
 
        <property name="hibernate.connection.driver_class">org.postgresql.Driver</property>
        <property name="hibernate.connection.url">jdbc:postgresql://localhost/postgres</property>
        <property name="hibernate.connection.username">postgres</property>
        <property name="connection.password">passwd</property>	
 
        <property name="hibernate.dialect">org.hibernate.dialect.PostgreSQLDialect</property>
        <property name="hibernate.connection.pool_size">0</property>
 
        <property name="show_sql">true</property>
        <property name="format_sql">true</property>
        <property name="hibernate.hbm2ddl.auto">update</property>
 
        <!-- mapping resources -->
        <mapping resource="User.hbm.xml"/>
        <mapping resource="Address.hbm.xml"/>
        <mapping resource="World.hbm.xml"/>
        <mapping resource="Weather.hbm.xml"/>
		<mapping resource="Artefact.hbm.xml"/>
		<mapping resource="Account.hbm.xml"/>
		<mapping resource="Luggage.hbm.xml"/>
		<mapping resource="Advert.hbm.xml"/>
		<mapping resource="Battle.hbm.xml"/>
 
    </session-factory>
</hibernate-configuration>

user.hbm.xml

<?xml version="1.0"?>
<!DOCTYPE hibernate-mapping PUBLIC
	"-//Hibernate/Hibernate Mapping DTD 3.0//EN"
	"http://hibernate.sourceforge.net/hibernate-mapping-3.0.dtd">
<hibernate-mapping package="org.lukasz.gra.model">
  <class name="AbstractUser" table="abstractuser_table">
 
 	<id name="id">
  		<generator class="native"/>
  	</id>
 
  	<property name="login" type="string"/>
  	<property name="password" type="string"/>
  	<joined-subclass name="User" table="user_table">
  		<key column="id"/>
  		<property name="name" type="string"/>
  		<property name="surname" type="string"/>
  		<component name="email" class="Email">
  			<property name="addressemail" type="string"/>
  		</component>
  		<many-to-one name="address" class="org.lukasz.gra.model.Address" column="idAddress" cascade="all"/>
 
  		 <many-to-one name="account" class="org.lukasz.gra.model.Account" cascade="all" unique="true"/>
  		 <many-to-one name="luggage" class="org.lukasz.gra.model.Luggage" cascade="all" unique="true"/>
 
  		 <set name="advertSet" table="advert_user" cascade="all">
            <key column="idUser" />
         <many-to-many column="idAdvert" unique="true" class="org.lukasz.gra.model.Advert" />
    </set>
  	</joined-subclass>		
  </class>
</hibernate-mapping>

user.java

package org.lukasz.gra.model;
 
import java.util.HashSet;
import java.util.Set;
 
public class User extends AbstractUser{
	private String name;
	private String surname;
	private Address address;
	private Email email;
	private Account account;
	private Luggage luggage;
 
	private Set<Advert>advertSet = new HashSet<Advert>(0);
 
 
	public Set<Advert> getAdvertSet() {
		return advertSet;
	}
	public void setAdvertSet(Set<Advert> advertSet) {
		this.advertSet = advertSet;
	}
	public Account getAccount() {
		return account;
	}
	public void setAccount(Account account) {
		this.account = account;
	}
	public Luggage getLuggage() {
		return luggage;
	}
	public void setLuggage(Luggage luggage) {
		this.luggage = luggage;
	}
	public String getName(){
		return name;
	}
	public void setName(String name){
		this.name = name;
	}
 
	public String getSurname(){
		return surname;
	}
	public void setSurname(String surname){
		this.surname = surname;
	}
 
	public Address getAddress(){
		return address;
	}
	public void setAddress(Address address){
		this.address = address;
	}
 
	public Email getEmail(){
		return email;
	}
	public void setEmail(Email email){
		this.email = email;
	}
 
	public User(){
		super();
	}
	public User(String login, String password, String name, String surname, Address address, Email email, Account account, Luggage luggage, Set<Advert> advertSet){
		super(login,password);
		this.name = name;
		this.surname = surname;
		this.address = address;
		this.email = email;
		this.account = account;
		this.luggage = luggage;
		this.advertSet = advertSet;
	}
}

Dao.java

package org.lukasz.gra.persistence;
import java.util.logging.Level;
import java.util.logging.Logger;
 
import org.hibernate.HibernateException;
import org.hibernate.Session;
import org.hibernate.SessionFactory;
 
import org.hibernate.cfg.Configuration;
 
public class Dao {
 
	private static final Logger log = Logger.getAnonymousLogger();
	@SuppressWarnings("unchecked")
	private static final ThreadLocal session = new ThreadLocal();
	private static final SessionFactory sessionFactory =
		new Configuration().configure().buildSessionFactory();
 
	protected Dao () {
	}
 
	@SuppressWarnings("unchecked")
	public static Session getSession() {
		Session session = (Session) Dao .session.get();
		if (session == null) {
			session = sessionFactory.openSession();
			Dao .session.set(session);
		}
		return session;
	}
	protected void begin() {
		getSession().beginTransaction();
	}
	protected void commit() {
		getSession().getTransaction().commit();
	}
 
	@SuppressWarnings("unchecked")
	protected void rollback() {
		try {
			getSession().getTransaction().rollback();
		} catch( HibernateException e ) {
			log.log(Level.WARNING,"Cannot rollback",e);
		}
		try {
			getSession().close();
		} catch( HibernateException e ) {
			log.log(Level.WARNING,"Cannot close",e);
		}
		Dao .session.set(null);
	}
	@SuppressWarnings("unchecked")
	public static void close() {
		getSession().close();
		Dao .session.set(null);
	}
}

userDao.java

package org.lukasz.gra.persistence;
//import java.util.HashSet;
//import java.util.List;
//import java.util.Set;
import org.hibernate.HibernateException;
import org.hibernate.Query;
import org.lukasz.gra.model.User;
 
public class UserDao extends Dao{
	public void add(User user){
		try {
			begin();
			getSession().save(user);
			commit();
		} catch (HibernateException e) {
			System.err.println("Error while adding user: " + e);
			rollback();
		}
	}
	public void delete(Integer id){
		try {
			begin();
			getSession().delete((User)getSession().get(User.class, id));
		} catch (HibernateException e) {
			System.err.println("Error while getting list of users " + e);
			rollback();
		} finally {
			commit();
		}
	}
 
	public void update(User user){
		try {
			begin();
			getSession().update(user);
		} catch (HibernateException e){
			System.err.println("Error while updating user " + e);
			rollback();
		} finally {
			commit();
		}
	}
	public User get(Integer id){
		try {
			begin();
			User user = (User) getSession().get(User.class, id);
			return user;
		} catch (HibernateException e) {
			System.err.println("Error while getting user " + e);
			rollback();
			return null;
		} finally {
			commit();
		}
	}
 
	public User get(String login){
		try {
			begin();
			Query q = getSession().createQuery("from User where login = :login").setString("login", login);
			User user = (User) q.uniqueResult();
			return user;
		} catch (HibernateException e) {
			System.err.println("Error while getting user " + e);
			rollback();
			return null;
		} finally {
			commit();
		}
	}
	public boolean checkPassword(String login, String password){
 
		User u = new User();
		try {
			begin();
			Query q = getSession().createQuery("from User where login= :login").setString("login", login);
			u = (User) q.uniqueResult();
			commit();
		} catch (HibernateException e) {
			System.err.println("Error while checking password: " + e);
			rollback();
			return false;
		}
		if (u==null) return false;
		if (u.getPassword().equals((password))) 
			return true;
		else return false;		
	}
 
 
}

Literatura

  • „Java - tworzenie aplikacji sieciowych za pomocą Springa, Hibernate i Eclipse”, Anil Hemrajani, Helion 2007
  • „Od podstaw SQL”, P. Wilton, J. Colby Helion 2006
  • „Hibernate od Nowicjusza do Profesjonalisty”, D. Minter, J. Linwood, PowerNet 2007
  • „JSP, servlety i strony WWW”, , Orelly 2006
  • Opracowania własne z poprzednich projektów informatycznych
pl/dydaktyka/ztb/2010/projekty/z_impetem/start.txt · ostatnio zmienione: 2017/07/17 08:08 (edycja zewnętrzna)
www.chimeric.de Valid CSS Driven by DokuWiki do yourself a favour and use a real browser - get firefox!! Recent changes RSS feed Valid XHTML 1.0