Aplikacje Rozproszone i Biznesowe (ARB), semestr letni 2010/2011

Proponowane tematy projektów zaliczeniowych

Można zaproponować własny temat projektu. Poniższe projekty są trochę bardziej niestandardowe i jest to zbiór projektów, które kiedyś sam chciałem gdzieś zrealizować, ale nigdy nie miałem czasu…

Tematyka projektów jest dowolna ważne tylko, aby wykorzystywały wszystko co jest wymagane od projektu zaliczeniowego (jest to opisane na mojej stronie i na stronie wykładowcy). Dopuszczalne tematy projektów obejmują wszelkie Sklepy internetowe, Aukcje, Serwisy wymiany plików, itp. Nie powinny jednak tematy projektów za bardzo się pokrywać ze sobą, więc jeśli jakaś para osób zgłosi, że chce robić wspólnie projekt sklepu internetowego, to dodam ten projekt do listy i w ten sposób będzie już zajęty dla kolejnych par (będą musiały wymyśleć coś innego).

Lista projektów

Projekt A – MathCaptcha

reCAPTCHA – rozwiązanie informatyczne, dzięki któremu rozproszona aktywność użytkowników Internetu jest wykorzystywana do pomocy przy rozpoznawaniu fragmentów zeskanowanego tekstu, z których odczytaniem nie poradziło sobie oprogramowanie OCR. Łączy ochronę stron internetowych przez CAPTCHA z pożyteczną pracą użytkowników sieci na rzecz digitalizacji tekstów. Wdrożone i rozwijane w ramach projektu reCAPTCHA na Uniwersytecie Carnegie - Mellona w Pittsburghu.

Żródło: wikipedia

Projekt serwisu i web-usługi. Usługa polega na udostępnieniu użytkownikom mechanizmu na zasadzie reCAPTCHA, tylko w naszym przypadku prezentowane mają być dwa wzory matematyczne, z prostym obliczeniem, tzn. takim, którego wartość może być łatwo zapisana liczbą – np. 2+2*2 albo \integral_0^1 x^2 dx (zapisane w bazie najlepiej LaTeXem a prezentowane w formie wyrenderowanej). Jeden ze wzorów matematycznych będzie miał znany wynik, drugi ze wzorów będzie pobrany z puli wzorów nierozwiązanych. Wzory nierozwiązane będą mogły być dodawane przez zarejestrowanych użytkowników na specjalnej stronie internetowej (przygotowanej w ramach projektu). Projekt powinien umożliwiać tworzenie kont użytkowników, dodawanie wzorów do bazy, przeglądanie zaproponowanych przez użytkowników captcha wyników obliczeń. Powinien mieć także panel administratora pozwalający na banowanie (albo usuwanie) wzorów użytkowników, banowanie (usuwanie) wyników zaproponowanych przez użytkowników podczas korzystania z captcha, oraz możliwość definiowania pewnych wzorów i ich wyników (używanych do weryfikacji).

(nieprzydzielony)

Projekt B – Platforma e-learningowa

Projekt prostej platformy e-learningowej. Platforma powinna obsługiwać lekcje, na które zapisać się może użytkownik, do każdej lekcji powinny być zadania. Zadania mają prawo umieszczać prowadzący daną lekcję. Prowadzących do lekcji przypisuje administrator. Zadania do systemu można wysyłać np. w formacie XML (można np. zaimplementować któreś ze standardu SCORM – będzie to mile widziane). Użytkownik powinien mieć możliwość przeglądania wyników swoich zadań, anulowania zadań niepoprawnych, aby możliwe było ponowne rozwiązanie. Powinien też mieć dostęp do raportu podsumowującego jego dokonania na platformie. Tworzący zadania powinien móc ograniczyć liczbę możliwych ponownych wysłani dla danego zadania np. do 3 itp. Administrator powinien móc tworzyć nowe lekcje i przydzielać prawa użytkownikom do tworzenia zadań w tych lekcjach.

Katarzyna Soboń, Bartosz Kolasa

Projekt C – Sieciowa gra browserowa

Projekt dowolnej gry typu Ogame (www.ogame.pl, www.reddragon.pl) – nie musi być taka rozbudowana. Mechanika gry dowolna. Użytkownicy powinny móc się rejestrować i zakładać swoje państwa (czy cokolwiek innego) i zarządzać nim. Gra powinna się kończyć po jakimś wydarzeniu (np. jeden z graczy wybuduje Świątynię Apokalipsy, zostanie osiągnięta założona ilość tur, lub coś podobnego. Po tym wydarzeniu wszelkie państwa powinny być resetowane i gra zaczyna się od nowa. Ranking dla gry powinien być zachowywany między grami. Od strony administracyjnej można należy dodać możliwość zmiany zdefiniowanej struktury technologii (która technologia od czego zależy, koszty technologii itp., koszt produkcji danego tupu wojska itp.) dzięki czemu każda z rozgrywek będzie trochę inna i za każdym razem trzeba będzie stosować inną taktykę.

Rafał Zając, Rafał Supronowicz

Projekt D – Gry żetonowe

Celem projektu jest stworzenie serwisu pozwalającego na zdalne granie w gry planszowe-żetonowe (Przykład: Gra o Tron i jeszcze zdjęcie planszy). Oczywiście nie trzeba implementować tylu reguł, aby umożliwić grę w tak skomplikowany przykład. Założeniem projektu jest to, że gracze grający w grę znają zasady i ich przestrzegają. Naszym zadaniem jest dostarczyć im wygodny sposób śledzenia i prowadzenia rozgrywki na odległość. Przebieg przygotowania rozgrywki jest taki:

  1. Administrator przygotowuje grę w ten sposób że z dostępnych grafik wybiera kilka i każdej nadaje specyficzną nazwę (TokenID). To będą tokeny. Dodatkowo tworzy planszę na której zaznacza ileś pól i nadaje im nazwy (FIeldID). Plansza i zbiór możliwych tokenów definiują grę.
  2. Od tej pory gracze mogą grać w grę. Mistrz gry tworzy grę i zaprasza do niej użytkowników (wybiera z listy zarejestrowanej na serwerze).
  3. Gra zaczyna się od przydzielenia tokenów graczom (z puli tokenów) – wykonuje to mistrz gry odpowiednimi komendami. Każdy token przydzielony graczowi dostaje unikalne ID (np. TokenID . tokenCount, aby łatwiej je było zidentyfikować przy wydawaniu komend). To ID może wyświetlać się na tokenie na planszy np.
  4. Mistrz gry określa kolejność w jakiej gracze będą wykonywać ruchy i gra się zaczyna.
  5. W każdej turze gracz może wykonać jakieś operacje na swoich tokenach, Mistrz Gry może w każdej turze wykonywać ruchy na tokenach dowolnych graczy. Dla uproszczenia można przyjąć, że Mistrz Gry nie jest graczem. Po zakończeniu swoich ruchów wydaje komendę „gotowe” i gra przekazuje sterowanie do następnego gracza. Można zrobić jakiś rodzaj powiadamiania o tym, że ktoś zrobił ruch np. na maila.
  6. Mistrz Gry kończy grę jakąś komendą np. „koniec”

Najlepiej aby cały przebieg gry był rejestrowany i możliwy do obejrzenia potem ruch po ruchu, z punktu widzenia każdego z graczy. Proponuję sekwencyjny zapis do pliku jakiegoś rodzaju komend tekstowych. Przykładowa rozgrywka w przykładowym języku opisu rozgrywki z komentarzem jest poniżej.

Plik z opisem planszy (może być np. XML lub JSON lub własny format): link do pliku.

Przykładowa gra:

Game master: give Player1 czarny_pionek 8; //daj graczowi 1 8 czarnych pionków
Game master: give Player1 czarny_pionek 8; //daj graczowi 2 8 białych pionków
Player1: put czarny_pionek_1 on A_1; //rozstawianie pionków
Player1: put czarny_pionek_2 on B_2;
//itd…
Player1: ready; //pozwól wykonać ruchy następnemu graczowi
Player2: put bialy_pionek_1 on ….
//itd…
Player2: ready; 
Player1: put czarny_pionek_1 on C_3; //wykonaj ruch
Player1: ready;
//itd…
W implementacji rozgrywki można nawet założyć, że gracze będą wpisywać komendy z klawiatury. Uwaga: Dobrze by było aby tokeny dało się odwracać (funkcja flip) często w grach planszowych układa się tokeny zakryte, aby potem je odwrócić przed kolejną fazą gry (tak jest np. w Grze o Tron) – po to w XML są pola frontside i backside w tokenach – można uogólnić przykład na n-side’owe tokeny…

Uwaga: ten projekt może być robiony przez dwie grupy – jedna wtedy zajmie się serwisem do tworzenia opisu gier i stworzy API do ich publikowania (np. poprzez SOAP – bardzo dobre ćwiczenie). Druga grupa natomiast będzie miała za zadanie wykorzystać serwis drugiej grupy, np. pobierając WSDL opisujący przekazywane XMLe i wykorzystujący je w swojej implementacji rozgrywki między graczami. Jeśli obie grupy się zgodzą, to nie ma problemu z podziałem zadań.

Marcin Lenart, Marek Siupik

Projekt E – Forum eksperckie

Coś na kształt np. stackoverflow.com – miejsce, gdzie użytkownicy mogą publikować swoje problemy a eksperci (lub po prostu inni użytkownicy) mogą na nie odpowiadać. Powinna być możliwość ocenienia czy dana odpowiedź jest przydatna czy nie. Na tej podstawie powinien być prowadzony ranking ekspertów. System powinien automatycznie zgłaszać do administratora/moderatora nieocenione przez zadającego pytanie odpowiedzi po czasie dłuższym niż ustalona z góry wartość. Moderator powinien mieć możliwość ukarania użytkownika negatywnym współczynnikiem, za nie ocenianie odpowiedzi ekspertów. Powinien mieć też możliwość edycji wszystkich postów (jak na forum). Eksperci powinni mieć także możliwość zgłaszania nieodpowiednich (nieuczciwych) ocen do administratora w celu weryfikacji.

Tomasz Stepanko, Piotr Rybiński.

Projekt F - Sklep

Sklep internetowy, który oferuje możliwość zakupu różnorodnych towarów. Użytkownik ma możliwość wystawienia tego przedmiotu, który następnie może zostać zakupiony przez innego użytkownika. Możliwość podglądania odpowiednich historii zakupów, towarów, itd. Plus jakieś konta administratora, który dbałby o ogólny porządek.

Daniel Klucznik, Dawid Bujak

Projekt G - Rezerwacje hotelowe

System rezerwacji hotelowej przy pomocy JSF i JPA. Można będzie rejestrować, dodawać i usuwać użytkowników, przeglądać oferty pokoi, rezerwować je, przeglądać rezerwacje oraz je dodawać,usuwać itd. Zajmować się będzie tym administrator, użytkownik będzie miał dostęp tylko do swojej rejestracji, przeglądania ofert i rezerwacji terminów.

Jan Krzywanek