Szolgáltatásintegráció házi feladat
Értékelés:
A házi feladatokra a konzulensek értékelése és a közös bemutatók alapján egyhangúlag 5-öst javaslunk minden csapatnak (amelyik leadta a feladat mindhárom fázisát). A jegy 30%-os súllyal beszámít a vizsga értékelésekor.
Az 1,2,3,4,5,6,7 csapatok vizsgakönnyítést kapnak, erről a Vizsga oldalon írunk bővebben. A felmerült esetleges tecnhológiai kihívások mellett minden csapat igényes feladatot adott be, amihez ezúton gratulálunk.
Csapatok
A házi feladat megoldása 3 fős csapatokban történik, az értékelés a csapat munkája és az egyes csappattagok időráfordítása/teljesítménye alapján egyéni.
A feladat megoldása során használandó infrastruktúra: (x = csapat száma)
- Trac: https://modeling.inf.mit.bme.hu/trac/modeling_x_2014
-
Szolgint Git:
- web: https://git.inf.mit.bme.hu/w?p=edu/szolgint/szolgint_2014_x.git
- clone URI: https://git.inf.mit.bme.hu/r/edu/szolgint/szolgint_2014_x.git
- Leírás. A tárgyban a HTTPS-en keresztül történő elérést használjuk.
Aki nem rendelkezik még LDAP-os felhasználóval, az IB414-es teremben átveheti a felhasználónév-jelszót párosát.
Megjegyzés: a házi feladat megoldása során felmerülő (a segédletek alapján nem megoldható) technikai hibák megvitatására szolgál az FTSRG Q&A oldal.
A csapatbeosztás alapvetően megegyezik az MDSD tárggyal:
- 1. csapat: MOHOKA (konzulens: Szárnyas Gábor)
- 2. csapat: Eclipse apocalypse (konzulens: Szárnyas Gábor)
- 3. csapat: Pineapple (konzulens: Gönczy László)
- 4. csapat: Raptor (konzulens: Szárnyas Gábor)
- 5. csapat: Pagmomolde (konzulens: Bergmann Gábor)
- 6. csapat: Adrenalin (konzulens: Bergmann Gábor)
- 7. csapat: NameNotFound, csak Szolgint: Zoltánka Mátyás (konzulens: Gönczy László)
- 8. csapat: Enthusiasm-Driven Software Developers, csak MDSD (konzulens: –)
- 9. csapat: Pozitron (konzulens: Bergmann Gábor)
Feladatkiírás
A házi feladat egy olyan, intelligens számítógép (desktop/laptop/alkatrész) kereskedés elkészítése, mely egyéni eladóknak árajánlatot ad eladni kívánt gépeikre. A rendszer használata során a felhasználó először feltölti az eladni kívánt gép konfigurációját
(CPU, memória, kijelző, stb.). A rendszer a feltöltés során a gép típusa alapján a típushoz tartozó, már ismert konfigurációkat felkínálja, az újonnan feltöltött konfigurációkat pedig eltárolja. Ezután a rendelkezésre álló benchmark adatok (PassMark) alapján, a műszaki avulás figyelembevételével megállapítja a gépért adható árat. A kalkuláció során figyelembe veszi az egyes (használt) konfigurációkból már rendelkezésre álló állományt és a tárolható mennyiséget, valamint a rendszer üzemeltetője által az egyes alkatrészekre megadott preferenciákat.
Ez alapján elképzelhető olyan eset is, amikor egy gépre nem ad árat, vagy alkatrészként kívánja megvásárolni.
Amennyiben egy konfiguráció olyan elemet tartalmaz, melyre nincs elérhető ár (pl. a benchmark adatbázis nem teljes), akkor az adott alkatrész teljesítménye/kora alapján határoz meg egy árat, és ezt el is tárolja további felhasználásra. A rendszer eltárolja az egyes konfigurációkra adott ajánlatokat is.
A rendszer az árakat a felhasználó által megadott pénznemben adja meg, ehhez (és a kalkuláció során szükséges esetleges egyéb átváltásokhoz) a Magyar Nemzeti Bank online valutaváltó szolgáltatását használja.
A rendszerben az üzemeltetőnek (kereskedőnek) lehetősége van a kalkulációt meghatározó preferenciáin változtatni, pl. döntési táblák megadásával.
A rendszer vezérlési logikáját folyamat alapon kell megvalósítani a Bonita szoftverben. Elvárás, hogy ne csak az egyes omponensek legyenek teszteltek, hanem maga a vezérlési folyamat is. Ehhez a Bonita API-t használva saját alkalmazást kel készíteni. A rendszer felhasználói felülete tetszőleges lehet (akár a Bonita saját webes konzolja, akár a teszteléshez is használt API-t meghajtó desktop alkalmazás). A rendszer az adatokat Cassandra alapon tárolja. A felhasználókezelés nem része a feladatnak, használható a Bonita beépített mechanizmusa. Elvárás ugyanakkor, hogy a rendszer a későbbiekben több adatforrást is kezelni tudjon, erre a 3. fázis során lesz szükség, amikor a szabályok teszteléséhez alternatív adatforrásokat fogunk biztosítani. Az árképzési logikát szabály alapon, JBoss Drools segítségével kell megvalósítani.
A házi feladat megoldása során használandó adatforrások:
- Árfolyam
-
Hardver
- PassMark: http://www.cpubenchmark.net/
- Konfigurációk:
A házi feladat beadásának ütemezése
1. fázis: Adatmodell, külső adatforrások integrációja
- Leadandó: Bonita folyamatok rövid dokumentációval, a külső adatokkal feltöltött Cassandra adatbázis
- Elvárás, hogy a Bonita folyamatok működjenek (a konzolon végig lehessen ezeket futtatni, amennyire lehetséges, a későbbiekben használni kívánt adatszerkezetekre hivatkozzanak), de nem elvárás a valós üzleti logika implementálása.
- Határidő: 2014. március 12. szerda éjfél (5. hét)
2. fázis: Integrált rendszer, külső szolgáltatások megvalósítása
- Leadandó: Bonita folyamatok rövid dokumentációval, a külső adatokkal feltöltött Cassandra adatbázis
- Elvárás: Az összes folyamat működik, a szükséges szolgáltatások integrálva vannak, a szükséges saját csatolók (Connectorok) kész vannak, a hibakezelés implementálva van Bonita szinten. A szabály alapú kalkuláció (Drools) és értelemszerűen a kereskedői preferenciák felhasználása még nincs implementálva, a rendszer mindenre a benchmark adatokból legegyszerűbben kiszámolható árat adja.
- Határidő: 2014. április 16. szerda éjfél (10. hét)
3.. fázis: Teljes rendszer, szabályalapú döntésekkel, kitesztelve.
- Leadandó: Bonita folyamatok rövid dokumentációval, a külső adatokkal feltöltött Cassandra adatbázis
- A teljes feladat kész, dokumentált, tesztelt.
- Határidő: 2014. május 7. szerda éjfél (13. hét)
Értékelés, általános követelmények
- A végső leadott feladatnak hibamentesen futni kell az általunk előre megadott, ill. a bemutatás során megadott inputokra.
- A rendszert minden fázisban dokumentálni kell, a 3. fázisban elvárt a tesztelési jegyzőkönyv is.
- A rendszert fel kell készíteni a működés során potenciálisan fellépő hibákra (rossz felhasználói adat, elérhetetlen szolgáltatás/adatbázis, hibás válasz szolgáltatástól, a kereskedő által rosszul megadott kalkulációs táblázat, stb.)
- A csapatok a leadás utáni csütörtöki gyakorlat után bemutatják az elvégzett munkát rövid ppt prezentáció + opcionálisan rövid (1-2 perces) demó keretében. Az előadás és a demó együttes hossza nem haladhatja meg a 10 percet (sokszor a való életben sincs több lehetőség munkánkat bemutatni...).
- Emellett a konzulensekkel egyeztetett időpontban minden csapat bemutatja konzulensének a feladatot, aki részletesen megnézi/kipróbálja azt.
- Mind a közös, mind a konzulensnek tartott bemutatón egyértelművé kell tenni az egyes csapattagok munkáját és időráfordítását.
Opcionális feladatok
- felhasználói adatok (nem formai) validációja
- fejlett kommunikációs/adattranszfer technológiák használata (pl. Apache Thrift)
- historikus árfolyamok kezelése
- ECB valutaváltó használata
- további adatforrások integrálása
- LDAP integráció
- egyéb, egyeztetett feladat
Pontosítások
Az alábbiakban a házi feladat témájával/értékelésével kapcsolatos kérdésekre adott válaszokat gyűjtöttük össze pontosításként
(utolsó frissítés: 2014.03.17.):
Értékelés
-
Hogy történik a feladatok "beadása"?
- A git-en egyértelműen azonosítható verzióra kell mutatnia egy linknek a csapat trac oldalán, röviden összefoglalva, hogy mi készült el (felsorolásként), ill. mi volt az egyes csapattagok munkája (időráfordítással). A trac oldalra be kell linkelni a közös bemutatóra készített fóliasort is.
-
A közös bemutatón minden csapattagnak részt kell vennie a bemutatón?
- Igen, de nem szükséges mindenkinek minden alkalommal részt vennie magában az előadás megtartásában. Ugyanakkor a három beadási alkalom alatt lehetőleg mindhárom csapattag vegyen részt legalább egy előadás megtartásában.
Feladat értelmezés
-
Milyen formában kell megadni a döntési táblát?
- Tetszőleges, a későbbiekben eldönthető. (Értelmezéshez: döntési fa != döntési tábla.)
-
Új gépek felvétele hogyan történjen?
- Tetszőleges (form, opcionálisan CSV alapú mass upload)
-
Hogyan fogadja el a felhasználó a rendszer ajánlatát?
- A felhasználó dönthet a gépre vagy alkatrészeire adott ajánlat elfogadásáról. A továbbiakat nem kell modellezni, de a raktárkészletet ennek megfelelően módosítani kell.
-
Mit jelent, hogy "a későbbiekben használni kívánt adatszerkezetekre hivatkozzanak"? (1. fázis)
- Akár kitöltetlen szerkezetű folyamatváltozóként jelenjen meg minden adat, amit a későbbiekben használni fognak.
-
Hogy történik a Cassandra adatbázis "beadása"? (1. fázis)
- Létrehozó szkriptek, rövid konfiguráció leírás legyen meg (reprodukálható legyen).
-
Mit kell szabály alapon megvalósítani, milyen technológiával? Hova kapcsolódnak a döntési táblák? (3. fázis)
- Az árképzést, JBoss Drools felhasználásával. A Drools közvetlenül is képes döntési táblákban megadott szabályokkal dolgozni.
-
Hogyan történjen a szabály alapú árképzés, milyen paramétereket befolyásolhasson az üzleti döntéshozó? (3. fázis)
-
Az árképzés vegye figyelembe minimálisan a következő főbb szempontokat:
- Ha az alkatrészekre bontás és az egész konfiguráció továbbértékesítése is szóba jön, a magasabb továbbértékesítési haszonnal kecsegtető lehetőség alapján képzünk árajánlatot.
- Megadható egy (ártartománytól függő?) haszonkulcs, tehát a továbbértékesítésből származó tényleges várható haszonhoz képest ennyivel olcsóbb árajánlatot teszünk.
- A haszon számításánál a várható továbbértékesítési árat csökkenteni kell a költségekkel. A költségek egy része az áru átvételével, szállításával, könyvelésével képződik (ez akár az áru típusától független is lehet). Ezen felül alkatrészekre bontás esetén a gép szétszerelésének és végső hulladékkezelésének is költsége van. Végül minden egyes kiszerelt alkatrészhez tartozik egy költség (kiszerelés, adminisztráció, stb.) - értelemszerűen csak az azokat az alkatrészeket szereljük ki, amelyeknél a várható továbbértékesítési bevétel meghaladja ezt az alkatrészköltséget. Az egyes költségtételeket természetesen üzleti döntéshozók határozzák meg (az alkatrésztípus stb. függvényében).
- A korlátos raktárkapacitást lehetőleg minél többféle áru között kell megosztani, és kockázatos egy típusból túl sokat felhalmozni. Így a döntéshozók minden alkatrész- és konfigurációtípusra előírhatnak egy maximálisan raktározható mennyiséget - ennél többet semmiképp se veszünk át továbbértékesítésre. Ahogy a raktáron álló mennyiség közelíti a limitet, esetleg az árajánlat is fokozatosan csökkentendő valamilyen mértékben, hiszen egyre kevésbé számít ritkaságnak az adott típus.
- Negatív árajánlatot nem teszünk, és ez az alsó határ praktikussági szempontokból akár magasabbra is szabható (pl. $2) az üzleti döntéshozók által.
-
Az árképzés vegye figyelembe minimálisan a következő főbb szempontokat:
