A feladat
Nyomtatóbarát változatTartalom
1. Üzleti probléma
A varázsital termelő vállalkozások kiszolgáltatott piaci helyzetben vannak. Termékük romlandó, csak korlátozott ideig tárolható, így azt a termelőknek gyorsan el kell juttatniuk a vevőkhöz. A termék romlandóságának tudatában a kereskedők jellemzően kihasználják a termelőket, egymás ellen kijátszva őket, hogy a lehető legalacsonyabb áron vásárolják fel a készleteket. A termelők azonban megelégelték a kiszolgáltatott helyzetüket és összefogva elhatározták, hogy egy elektronikus varázsitaltőzsdét hoznak létre, ahol bárki önmaga kereskedhet a termékével.
A tőzsde működése:
A varázsital tradicionális elszámolási egysége a csöbör (cibrio v. Zuber), ami pontosan 113,28 litert tesz ki. A tőzsdén kötésegységekben lehet kereskedni (KE). Egy kötésegység nyolc csöbörnek felel meg. A regisztrált tőzsdei tagok (felhasználók) anonim ajánlatokat tehetnek mind az eladási, mind vételi oldalon. Az ajánlatokat a rendszer ár alapján ajánlati könyvben rendezve jeleníti meg. Az ajánlati könyvet minden felhasználó láthatja.
Az eladási és vételi ajánlatokat a rendszer – bizonyos szabályok alapján – automatikusan párosítja és ezáltal létrehozza a kötéseket is. A kötések adatai a rendszerből listázhatók.
2. Funkcionalitás
2.1. Regisztráció
Biztosítja a felhasználók regisztrációját, melyhez alapvetően felhasználónevet, jelszót és szerepkört lehet rögzíteni. A rendszer két szerepkört kezel:
- Kereskedő: ajánlatokat adhat be mind az eladási, mind a vételi oldalon. Az adatok (pl. ajánlatok és kötések) listázásánál csak a saját magára vonatkozó adatokat éri el. Kötéseinek listázásánál azonban nem láthatja, hogy ki volt az egyes kötésekben a partnere.
- Rendszergazda: kereskedésre (ajánlatadásra) nem jogosult, de a rendszer minden egyéb funkcióját eléri. Az adatok (pl. ajánlatok és kötések) listázásánál minden adatot elér, láthatja az ajánlatot adó, illetve kötésben résztvevő partnerek azonosítóját.
2.2. Ajánlatadás
A kereskedők (ajánlattevők) ajánlatokat adhatnak be, melyhez az alábbi adatokat kell megadni:
- Ajánlati mennyiség: egész kötésegységben megadva, legkisebb mértéke 1 KE.
- Az ajánlati ár: forintban egy csöbörre értelmezve.
2.3. Ajánlati könyv
Az ajánlati könyv ár szerint rendezve jeleníti meg a rendszerbe beadott ajánlatokat, egymástól elkülönítve a vételi és eladási oldalt. Az ajánlatok rendezési szempontjai:
- Eladás: a legalacsonyabb árú ajánlatok vannak legfelül, ha két ajánlatnak megegyezik az ára, akkor az időben korábban beadott jelenik meg feljebb.
- Vétel: a legmagasabb árú ajánlatok vannak legfelül, ha két ajánlatnak megegyezik az ára, akkor az időben korábban beadott jelenik meg feljebb.
Az ajánlati mennyiség az ajánlati könyvben alapértelmezetten KE-ben jelenik meg, de a rendszer tájékoztató jelleggel képes a mennyiséget csöbörben és literben is, illetve az ajánlati árat 1 KE-re, illetve 1 literre értelmezve is megjeleníteni.
Anonimitás: a kereskedők az ajánlati könyvből nem ismerhetik meg az ajánlattevő személyét.
2.4. Párosítás
Az ellentétes irányú ajánlatokat a rendszer képes automatikusan párosítani az alábbi szabályok betartásával (akkor ellentétes irányú két ajánlat, ha az egyik vételi, a másik eladási ajánlat):
- A párosítandó ajánlatok egymásnak árban megfelelőek, azaz az eladó eladási árajánlata nem lehet magasabb, mint a vevő vételi árajánlata (vételi ár >= eladási ár).
- Mindig az ajánlati könyv tetején lévő ajánlatok párosítását kell legelőször megkísérelni.
- Az ajánlati könyvben nem lehetnek egymással párosítható ajánlatok.
- Egyazon kereskedő által benyújtott vételi és eladási ajánlatok egymással nem párosíthatóak. (A kereskedők önmagukkal nem kereskednek.)
- Ha két ajánlat párosítása során az egyik ajánlat nem teljes kötésegységével kerül felhasználásra, akkor az ajánlatból megmaradt kötésegységek alapján ún. maradékajánlattal kell helyettesíteni az eredeti ajánlatot. (Azaz részteljesítés megengedett.) Ld. példa
Két – megfelelő – ajánlat párosítása egy kötést hoz létre a rendszerben. A kötés jellemzői:
- vételi ajánlat azonosítója (rendszer által generált azonosító szám),
- vételi ajánlat kereskedője,
- vételi ajánlat beadásának időpontja,
- eladási ajánlat (rendszer által generált azonosító),
- eladási ajánlat kereskedője,
- eladási ajánlat beadásának időpontja,
- kötés mennyisége,
- kötésár: annak az ajánlatnak az ára lesz a kötésár, amelyet előbb rögzítettek a rendszerben.
A rendszer a párosított ajánlatok alapján tárolja a kötéseket, illetve képes azok jogosultság alapján történő megjelenítésére (lásd 2.1 pont).
2.5. Jéghegy típusú ajánlatok kezelése
A jéghegy ajánlat lényege, hogy az ajánlattevő egy nagyobb mennyiségű ajánlatot kisebb darabokra oszt fel, melyben az egyes ajánlati elemeknek eltérő mennyiségei, eltérő árai is lehetnek. A jéghegy ajánlatot az ajánlattevő egyben adja meg, de az ajánlati könyvben csak a jéghegyajánlat legelső eleme jelenik meg. Amennyiben az ajánlati könyvben szereplő elem lekötésre kerül, akkor a sorban következő lép be a helyére. A jéghegy ajánlat újabb elemének ajánlati könyvbe történő belépése automatikusan elindítja a párosítási folyamatot ugyanúgy, mint egy teljesen új ajánlat bekerülése.
2.6. Árfolyammozgás riport
A rendszer a kötések alapján képes az árfolyammozgás adatait megjeleníteni táblázatos formában. A táblázatnak tartalmaznia kell a kötés időpontját, mennyiségét és az árat.
3. Példa a párosító algoritmus működéséhez
Kezdetben az ajánlati könyv üres. A rendszerbe korábban három kereskedő lett regisztrálva (X, Y és Z).
Lépés | Esemény | Következmény |
|---|---|---|
1. | X vételi ajánlatot nyújt be 10KE-gel, 500 Ft-os áron. | Az ajánlat bekerül az ajánlati könyvbe (mivel még nem párosítható). |
2. | Y eladási ajánlatot nyújt be 8KE-gel, 300 Ft-os áron. | X kereskedő korábbi ajánlatával párosít a rendszer, és új kötés jön létre 8KE-gel, 500 Ft-os áron. Az ajánlati könyvből kikerül az Y kereskedő ajánlata, és bekerül – X eredeti ajánlata alapján – a maradékajánlat ugyanazzal az árral (500 Ft) és X ajánlattevővel 2KE-gel (10KE-8KE). |
3. | X eladási ajánlatot nyújt be 5KE-gel, 300 Ft-os áron. | Az ajánlat bekerül az ajánlati könyvbe (saját ajánlatok nem párosíthatóak). |
4. | Y vételi ajánlatot nyújt be 10KE-gel, 200 Ft-os áron. | Az ajánlat bekerül az ajánlati könyvbe, mert az eladási oldalon szereplő ajánlatok (1db) ár szerint nem párosíthatóak (vételi árnak legalább annyinak kell lennie, mint az eladási árnak). Az ajánlat a vételi oldal aljára kerül, mert az ajánlati könyvet vételi oldalon ár szerint csökkenő sorrendben kell vezetni. |
5. | Z eladási ajánlatot nyújt be 8 KE-gel, 100 Ft-os áron. | A beadott ajánlat párosítható, és egyből két kötés jön létre. Először X kereskedő ajánlatával (2KE) párosít a rendszer (500 Ft-os áron) – mivel ez szerepel az ajánlati könyv tetején –, majd Y kereskedő ajánlatával (6KE-ig 200 Ft-os áron). Y kereskedőnek maradékajánlata keletkezik a könyvben 4KE-gel, 200 forintos áron. |
6. | Z eladási ajánlatot nyújt be 7 KE-gel, 100 Ft-os áron. | A beadott ajánlat párosítható az ajánlati könyv vételi oldalán lévő ajánlattal. Maradékajánlat keletkezik, amelyet az eladási oldal tetején kell elhelyezni (az eladási oldal ár szerint növekvő sorrendbe rendezett). |
Az ajánlati könyv az egyes lépések után a következőképpen alakul:
1. lépés – új ajánlat: X 10KE 500HUF vétel
| Vétel | Eladás |
|---|---|
| X 10KE 500HUF | |
2. lépés – új ajánlat: Y 8KE 300HUF eladás, 1db új kötés
| Vétel | Eladás |
|---|---|
| X 2KE 500HUF | |
3. lépés – új ajánlat: X 5KE 300HUF eladás
| Vétel | Eladás |
|---|---|
| X 2KE 500HUF | X 5KE 300HUF |
4. lépés – új ajánlat: Y 10KE 200HUF vétel
| Vétel | Eladás |
|---|---|
| X 2KE 500HUF | X 5KE 300HUF |
| Y 10KE 200HUF | |
5. lépés – új ajánlat: Z 8KE 100HUF eladás, 2db új kötés
| Vétel | Eladás |
|---|---|
| Y 4KE 200HUF | X 5KE 300HUF |
6. lépés – új ajánlat: Z 7KE 100HUF eladás, 1db új kötés
| Vétel | Eladás |
|---|---|
| Z 3KE 100HUF | |
| X 5KE 300HUF | |
4. Technológiai elvárások
A kész alkalmazáshoz tartozó projektet egy zip állományban kell átadni (a feltöltés pontos módja a későbbiekben kerül meghatározásra). A zip állomány egy könyvtárat tartalmazhat, mely a teljes projektet tartalmazza a forráskóddal, librarykkal (jar), erőforrás állományokkal (xml, jsp, css, js, stb.). Ez alatt a projekt dokumentációját a doc könyvtárban PDF formátumban kell tartalmaznia. A zip állomány nem tartalmazhatja a lefordított class állományokat. A projektnek egy parancssorból kiadott paranccsal fordulnia, buildelődnie kell. Ez lehet bármilyen bat-script, Ant- vagy mvn-parancs, a parancs pontos formátumát a dokumentációban le kell írni.
Az elbírálási platformja: Windows7 32 bites operációs rendszer, JDK 6 Update 21, Maven 2.2.1, Apache Ant 1.8.1. Más szoftver (az adatbázisszervereket leszámítva, ld. később) az elbírálás során előre telepítve nem áll rendelkezésre. A Mavenhez a central repositoryn (http://repo1.maven.org/maven2/) kívül más repository nincs beállítva. (Internetelérés ebből a célból biztosított.)
A build folyamat eredménye a következők egyikének kell lennie: jar, war, ear. A jar állomány esetében az alkalmazásnak parancssorból indíthatónak kell lennie. A parancssoron belül kell megadni az adatbázis JDBC címét, felhasználónevet és jelszót. A parancsnak a dokumentációban szerepelnie kell. WAR és EAR esetén szabványos állományokat kell átadni. Web konténer Apache Tomcat 6.0.29, alkalmazásszerver GlassFish Server Open Source Edition 3.0.1, mely mindkettő a megfelelő szabványok referencia implementációja. A fejlesztés bármilyen környezetben történhet, a futtatás a megadott környezetben történik. A WAR esetén a dokumentációnak rendelkeznie kell, hogy az alkalmazás Apache Tomcatre, vagy GlassFishre telepítendő-e. Az EAR esetén a telepítés mindenképp a GlassFish Server Open Source Edition 3.0.1-re történik.
Az alkalmazásnak nem kötelező adatbáziskezelőt használnia. Ha mégis szükség van rá, megengedettek a beágyazott adatbázis szerverek (pl. Apache Derby, HSQLDB, stb.), de ebben az esetben az adatbáziskezelőt az alkalmazásnak kell indítania. A környezetre a következő adatbázisszerverek lesznek telepítve: MySQL Community Server 5.1.51, PostgreSQL Version 9.0.0-1, Oracle Database 10g Express Edition. Garantált, hogy az alkalmazás futtatása üres adatbázissal történik. Az adatbázison semmilyen beállítást ne kelljen végezni, beleértve scriptek futtatását is, azaz az adatbázis sémát, és annak kezdeti feltöltését az alkalmazásnak kell elvégeznie.
Az adatbázishoz a Tomcaten vagy Glassfishen belül csak a DataSource-on keresztül lehet hozzáférni. Ezek nevei adatbázisonként rendre: mysqlDS, postgresqlDS és oracleDS. A Tomcat és a Glassfish alá mindhárom adatbázis drivere telepítésre kerül, ezeket nem kell az alkalmazásnak tartalmaznia.
Webes alkalmazás esetén a dokumentációban meg kell adni azt a címet (url-t), melyen az alkalmazás kezdőlapja elérhető.
5. Dokumentáció
Nem várunk el részletes dokumentációt az alkalmazással kapcsolatban, csak annyit, hogy a benne leírt információk alapján buildelni és indítani lehessen az alkalmazást (a technológiai elvárások fejezetben említett elvek alapján).
6. Értékelési szempontok
Az értékelési szempontrendszer három fő részből áll:
Felhasználói felület, üzleti funkciók kidolgozottsága | 40 pont |
Technológia | 20 pont |
Forráskód | 40 pont |
Összesen | 100 pont |
6.1. Felhasználói felület, üzleti funkciók kidolgozottsága
A felhasználói felület értékelési szempontjai a következők:
- mennyire logikus a funkciók képernyőkre való tagolása;
- hány műveleti lépéssel végezhető el egy-egy funkció;
- a felhasználói felületi kontrollok műveleti hatókörének világos ábrázolása;
- hány féle módon lehet elérni egy funkciót (menü, nyomógombok, gyorsbillentyűk használata);
- egyértelmű és következetes megnevezések használata;
- a felhasználói felület egységes képe, megjelenése;
- gazdag felhasználói élmény.
6.2. Technológia
A technológiai értékelési szempontok a következők:
- a versenyző mennyire ismeri jól a Java SE API-ját, milyen interfészeket, osztályokat választ, és azokat hogyan használja;
- mennyire ismeri, és használja jól a szabványokat;
- milyen 3rd party keretrendszereket, könyvtárakat használ fel, mi alapján választotta ki ezeket, és mennyire jól használja őket;
- milyen az alkalmazás belső felépítése, mennyire válnak el a rétegek;
- milyen a hibakezelés;
- tartalmaz-e az alkalmazás szűk keresztmetszeteket, lassú kódot;
- mennyire lehet információkat megtudni az alkalmazás futásáról, mennyire támogatja a hibakeresést;
- milyen a projekt felépítése, könyvtárstruktúrája, mennyire alkalmazkodik a konvenciókhoz.
6.3. Forráskód
A forráskód elbírálásában fő szempontként az agilis szoftverfejlesztésben elterjedt mérnöki gyakorlatok játszanak szerepet. Ezek nem alkalmazása nem számít kizáró oknak.
- KISS-elv és YAGNI-elv alkalmazása (Simple Design),
- automatizált tesztesetek (unit-tesztek, integrációs tesztek),
- Domain Driven Design: az üzleti fogalmi rendszer következetes használata a forráskódban, objektum-orientált modellezés és domain modell,
- POJO-k használata,
- tiszta (könnyen áttekinthető, karbantartható) kód.
7. Jótanácsok versenyzők számára
Úgy hisszük, hogy a feladatleírás alapján elkészíthető egy lehetséges megoldás. Nem szerettünk volna olyan specifikációt adni, amely teljesen megköti a kezeteket, ezért a funkciók kidolgozását teljesen Rátok bízzuk.
A felhasználói felületnek, üzleti funkciók kidolgozottságának pontozásánál azon versenyművek kapnak nagyobb pontszámot, amelyek a funkciók használhatóságában közelebb állnak az üzleti felhasználók valós igényeihez. Ezért arra biztatunk Titeket, hogy bátran kérdezzetek, így jobban megérthetitek, hogy valójában hogyan is használnák a rendszert az üzleti felhasználók.
Jó munkát kíván,
a zsűri
