Haladó .NET Programozás
Tömegközlekedés-követő rendszer
Követelményleírás
A csapat tagjai és elérhetőségeik
• Kalapos Gergely (gergo@kalapos.net)
• Quintz Gábor (quintz.gabor@hotmail.com)
Tovabbi dokumentumok:
-A Rendszerterv tervezesi resze itt talalhato:
Rendszerterv_Tervezesi-A Rendszerterv implementacios resze itt talalhato:
Rendszerterv_Implementacios
Feladat rövid ismertetése:
A Project során egy tömegközlekedés követő rendszert fogunk megvalósítani. Az alkalmazás célja az, hogy a felhasználók Windows Phone készülékeik segítségével gyorsabban, és pontosabban kapjanak információkat arról a járatról, amire felszállnak, mintha a menetrendet néznék. A rendszer nemcsak egy adott városon belüli járatokat, hanem akár vonatokat is tud követni. Minden felhasználó az utazás megkezdésekor jelzi, hogy melyik járattal utazik, így a többi felhasználó ezt az adatot felhasználva informálódhat arról, hogy az adott járat éppen hol tart, és várhatóan mennyi idő múlva ér a megállóba. Az alkalmazás lényege az, hogy csakis a felhasználók okostelefonjai által szolgáltatott adatokra támaszkodnak, így nincs szükség a közlekedési vállalatnak egyéb infrastruktúra kiépítésére. Ebből természetesen az a hátrány is adódik, hogy ha nincs egy aktív felhasználó sem az adott járaton, akkor arról nem tudunk információt szolgáltatni a felhasználóknak.
Feladat leírása, elemzése
Az alkalmazás több rétegű lesz, a felhasználók Windows Phone-os alkalmazáson, és weben keresztül tudják használni azt.
Mobil eszközön a felhasználónak két lehetősége lesz:
• Tracking üzemmód. Ekkor a felhasználó kiválasztja, hogy melyik járaton utazik, és az alkalmazás folyamatosan küldi a GPS koordinátáit a szerver felé. A szerver ezeket az adatokat a többi felhasználó tájékoztatására, és a becslések pontosítására használja.
• Lekérdező üzemmód. A felhasználó kiválasztja, hogy melyik járatra szeretne felszállni, és a rendszer megmondja, hogy várhatóan az mikor fog a megállóba érni.
Lehetőség lesz új járatok felvételére weben keresztül. Ezt viszont csak külön regisztráció után tehetik meg a felhasználók. Erre azért van szükség, hogy ne lehessen össze-vissza új járatokat felvenni.
Mivel a mobil képernyője viszonylag kicsi, ezért a webes felületet használhatjuk arra is, hogy itt nagyobb adatsorokat jelenítsünk meg (pl. az általunk mért átlag menetidőket egy adott járat összes állomásai között, vagy Bing Maps-en megjeleníthetjük a járatok helyét, stb).
Fontos követelmények:
• Könnyen előfordulhat, hogy egy járatra több felhasználó is felszáll, és mindketten elkezdik küldeni a saját koordinátáikat. A rendszernek ekkor le kell kezelnie, hogy az adatbázisban egy járat aktuális pozíciójáról egyszerre csak egy adat legyen.
• Előfordulhat, hogy egy felhasználó csak úgy viccből rányom arra, hogy egy adott járattal utazik, vagy éppen valóban az adott járaton utazott, de már leszállt róla, és elfelejtette kikapcsolni a tracking funkciót. Ekkor helytelen adatok jutnának az adatbázisra. Ezt nem engedhetjük meg. (Itt felhasználhatjuk az adott járatok útvonalának koordinátáit…)
• Előfordulhat, hogy egy felhasználónak nincs internethozzáférése, de GPS van a telefonjában. Ekkor lehetőséget kell biztosítani, hogy az adott menetidőt koordinátákkal a telefonra mentse, majd amikor wifi közelébe ér fel tudja ezeket az adatokat tölteni a Back-end-be. Habár ezzel a járat pontos helyéről nem nyerünk információt, de az átlagos menetidők számítására felhasználhatjuk.
• Ahhoz, hogy a bemutatáshoz ne kelljen sok GPS-es telefon, és városnézés, teszteket kell írnunk, ami pl adott időközönként adatokat küld a Back-endbe megfelelő GPS koordinátákkal, mintha az egy telefon lenne, amivel egy járművön utazunk.
Use Case Diagram
Időbeosztás, költségek, mérföldkövek
A project során alapvetően az „Iterative and incremental development” módszertan szerint fogunk haladni. A kezdeti követelményleírás és a rendszerterv elkészítése után 2 hetes iterációkra osztjuk a munkát. Minden iteráció csütörtökön kezdődik, és csütörtökön fejeződik be. Az első 4 napban fogalmazzuk meg az adott iterációra vonatkozó követelményeket. Ezeket röviden le is írjuk. Ezzel párhuzamosan, nekilátunk a részfeladatok implementálásának. Erre 12 nap áll rendelkezésre. Az iteráció utolsó két napjában csak tesztelünk, és az esetleges hibákat javítjuk. Minden egyes iteráció vége egy mérföldkő, amikorra egy működő rendszert szeretnénk kapni. (Természetesen az első iteráció után ez még messze nem lesz funkcionálisan teljes). Azok a feladatok, amiket esetleg nem sikerül implementálni automatikusan átkerülnek a következő iterációba.
Erre a módszerre azért van szükségünk, mert még kevés projeckttapasztalattal rendelkezünk, és egészen biztos az, hogy első nekifutásra nem fogunk tudni mindenre tökéletesen felkészülni. Az iterációk lehetőséget adnak arra, hogy a hibáinkból tanuljunk, és adott esetben még időben módosítani tudjuk a rendszerünk egyes elemeit.
Időpontok:
• November 24: Eddigre egy működő WCF Service-t szeretnénk, amihez egy ASP.net oldal kapcsolódik.
• December 4: Ha kész vagyunk a WCF Service-el, akkor az ASP.net oldal és a Windows Phone alkalmazás fejlesztése párhuzamosan folyhat. December 4-ére szeretnénk egy olyan oldalt, ami egy térképen mutatja az olyan villamosok állapotát, amin felhasználóink éppen utaznak. Emellett a honlapon lehetőségnek kell lenni arra, hgy új állomásokat és járatokat vagyünk fel útvonallal együtt. A Windows Phone alkalmazásnak fel kell tudnia küldeni az aktuális koordinátáit, és lekérdezni azt, hogy a legközelebb lévő járat előreláthatólag mennyi idő múlva érkezik meg.
• December 11: Minden nem implementált, vagy hibás funkciót szeretnénk eddigre kijavítani.
ProjectManagement
A Project Kezeléséhez CodePlexet, verziókövetéshez pedig Mercurialt használunk. Az UML Diagrammok a Visual Studio Modeling Project Template –tel készülnek, a project menetét, időbeosztását és mérföldköveit pedig a Microsoft Project –tel tartjuk számon.
Feladatkiosztás:
• Adatbázis elkészítése – Közös munka
• WCF Service elkészítése - Gergő
• ASP.NET oldal elkészítése -Gergő
• WP7 alkalmazás elkészítése Gábor
• Tesztek elkészítése (pl egy olyan konzolos alkalmazás megírása, ami egy utazást szimulál olyan módon, hogy megfelelő koordinátákat továbbít a WCF Service-nek) – Közös munka, aki éppen ráér, itt a munka nagy része inkább a megfelelő koordináták megszerzése, ami villamosonként egymástól függetlenül is megoldható.
(A részfeladatokról részletesebb leírás a rendszertervben lesz)