Házi feladat (SzolgInt-MDSD 2011)

Házi feladat

Fejlesztőeszközök

A házi feladatok elkészítéséhez ajánlott eszközöket tartalmazó virtuális gépek (BME-s IP tartományból) a https://modeling.inf.mit.bme.hu/images/ URL-en érhetőek el. A gépek futtatásához az ingyenesen letölthető VMware Player programra van szükség.

SzolgInt_JBoss.7z JBoss Tools és AppServer környezet, Eclipse, integrált Papyrus UML szerkesztővel 3.0G
UML2009-RSA-7.5.7z Rational Software Architect v.7.5 UML szerkesztő 2.9G
WindowsXP.Prof.Eng.SP3-BASE.7z Az RSA image futtatásához szükséges Windows XP alaprendszer 3.6G
Riftsaw_WinXP.7z JBoss Tools,  Server, Riftsaw végrehajtó, Eclipse, integrált BPEL szerkesztővel és telepítővel 3.0G

Kerettörténet - Online sportfogadási portál

A feladat egy olyan portál (üzleti logikájának) megtervezése, amely sportfogadási szolgáltatásokat nyújt regisztrált felhasználók számára. A portál a 2010-es foci-VB alatt üzemel, és a foci-VB aktuális statisztikái alapján fogadási lehetőséget kínál a következő meccsekre.

A portál szolgáltatásai a http://footballpool.dataaccess.eu/ oldal statisztikáira építenek. Feltételezzük, hogy a játék a foci VB ideje alatt tetszőleges időpontban játszható, vagyis minden fogadáskor megadható a ("szimulált") időpont, melyben a játékos fogadni kíván. Bármilyen, az adott időpont utáni esemény kimenetelére lehet fogadni, és az oddsok meghatározására felhasználható bármilyen, az adott időpont előtti esemény.

A portál aggregátorként működve több fogadási iroda ajánlatait egyesíti. Az ezekben szereplő események halmaza nem feltétlen egyezik (esemény pl:  X játékos kap-e sárga lapot, legalább Y gól esik a meccsen, stb). A feladat megoldása során legalább 2 ilyen irodát integrálni kell a portál rendszerébe. A felhasználók kezelésétől (regisztáció, stb.) el lehet tekinteni, előre feltöltött adatbázis használható e célra. Követelmény viszont, hogy adott eseményre történő fogadás esetén mind a portál, mind az irodák lekérjék az esemény oddsainak meghatározásához szükséges adatokat a dataaccess.eu oldalról.

Figyelem: NEM követelmény a realisztikus oddsok meghatározása (ehhez több háttérismeret kellene), de követelmény, hogy az oddsok megadása során az egyes irodák támaszkodjanak a statisztikákra (is). Az egyes fogadási irodák regisztrációjától szintén eltekintünk, azt adottnak feltételezzük. A portál nem a valós események alapján működik, vagyis minden fogadás alkalmával egy, véletlenszerű sorsolás dönti el a fogadás végkimenetelét. A rendszer a házi feladat szempontjából "emlékezet nélküli", vagyis az egyes fogadások eseményei egymástól függetlenek, valószerűséget nem feltételezünk (példa: A csapat játszik B csapattal, X és Y játékos is fogadnak a meccs eredményére. A rendszer egymástól függetlenül sorsol a két eseményhez, tehát akár különböző eredmény is adódhat a két játékosnak. A meccs utáni dátum megadásakor ezzel szemben a meccs a ténylegesen lejátszottaknak megfelelő statisztikával számít be a következő oddsok meghatározásába).

A portál funkcionalitása:

  • Statisztika lekérése a foci VB megelőző mérkőzései alapján.
  • Következő esemény kiválasztása, fogadás az eseménnyel kapcsolatosan egy adott fogadási iroda ajánlatai alapján. A fogadás vonatkozhat tetszőleges eseménye, vagyis az eredményen kívül gólszerzőkre, sárgalapos figyelmeztetések számára, stb. Praktikusan bármilyen, a footballpool.dataaccess.eu statisztikái alapján elérhető adatra fogadni lehet, de nem garantálható, hogy minden, a portál kínálatában szereplő iroda ugyanazokat az eseményeket kezeli.
  • A felhasználó számára a fogadási egyenleg feltöltése tetszőleges pénznemben. A portál működésének alapja EUR, de tetszőleges pénznemben történő egyenleg feltöltést támogatni kell. A feltöltés során publikusan elérhető XML webszolgáltatásra építve kell meghatározni az EUR összeget, az adott dátumon érvényes konverziós ráták alapján.
  • Egyenleg lekérdezése (az előző fogadások eredményei alapján).
  • Top10 fogadó játékos (felhasználó) listájának lekérdezése (sikeresség: pl. találati arány vagy hasonló).

1. feladat (MDSD-HF1): A sportfogadási portál részletes UML modellezése

Használt technológia: UML 2.0 (pl. IBM Rational Software Architect vagy a Papyrus eszközben, de tetszőleges, a bemutatáskor általatok működésre bírható UML eszköz használható)

Beadás időpontja: 2011. február 28. hétfő

Az első MDSD házi feladatban a fogadási rendszer részletes UML modellezése a feladat (beleértve az összes szükséges külső szolgáltatás igénybevételét), amely a következő diagramok elkészítését foglalja magába:

  • Követelményanalízis: UML Use Case Diagram
  • Üzleti entitások és vezérlés analízis modellje: UML Class Diagram
  • Üzleti entitások és műveletek kényszerei: OCL Constraints
  • Üzleti entitások állapot alapú viselkedései: UML Statechart Diagram

Külön mennyiségi megkötés nincsen (azaz, nem értelmezhető, hogy melyik diagramból hányat kell csinálni). Fontos azonban, hogy a kritikus (azaz bonyolult) esetek (forgatókönyv, üzleti entitás, stb.) UML diagramjai készüljenek el először. Tehát inkább minőségi és ne mennyiségi legyen a modellezés. Az OCL kényszerek esetén elfogadható, ha csak szöveges dokumentációként kerülnek be a modellbe, az előadás fóliákon szereplő szintaxissal.

Követelmények

A házi feladat csapatmunka, és ezt ellenőrizni is fogjuk. A bemutatóra az alábbiakat kérjük:

  •    az UML modell projektje (ezt töltsétek fel az SVN-be 2011. február 28. hétfő éjfélig)
  •    max. 10 fóliából álló előadás, amelyből kiderülnek a következők:
    •    melyek a főbb használati esetek és aktorok
    •    hogyan néznek ki az analízis osztályok
      •    fő üzleti entitások struktúrája és életciklusa (entitás osztályok)
      •    hogyan kapcsolódnak a funkcionalitást irányító elemekhez (control osztályok)
      •    kommunikációs felületek (boundary osztályok)
    •    a legfőbb forgatókönyvek
    •    az egyes csapattagok munkája (munkanapló)
  • a munkanaplót, az SVN-ben tárolt UML projektre mutató linket, valamint az előadást kérjük, hogy tegyétek közzé a csapat honlapján (trac) is!

Végül egy fontos tanács: a feladat specifikációja szándékosan nem tér ki minden részletre (de még így is részletesebb, mint amivel sokszor a gyakorlatban találkozhatunk). A szöveg és probléma pontos értelmezése, és ennek megfelelő tervezői döntések dokumentált meghozása a ti feladatotok lesz, és ezeket a beadások során külön ellenőrizni is fogjuk!

Értékelés

Csapatnév Értékelés Megjegyzések
1-es csapat (FTSRG_1) OK rendben volt
2-es csapat (2. modeling csoport) pótlás entitás modellezési problémák; pótlási határidő: márc. 11.
3-as csapat OK finomítsatok a Bet entitás állapotain, a kaszkád törlés veszélyes

2. feladat (SzolgInt-HF1): A sportfogadási portál üzleti logikájának implementációja

Használt technológia: JBoss Seam 2 (a kiadott VMware image alapján)

Beadás időpontja: 2011. március 18. péntek

Az első SzolgInt házi feladatban a fogadási rendszer a sportfogadási portál és a fogadóirodák legfontosabb üzleti logikájának implementációja a feladat (beleértve az összes szükséges külső szolgáltatás igénybevételét). A megvalósítandó funkciók közül nem tekintjük lényegesnek a felhasználói és egyéb adminisztrációt (felhasználó/fogadóiroda regisztrációja/létrehozása/adatainak megváltoztatása/törlése).

A feladat megoldása során az alábbiakat kérjük:

  • a lényegi üzleti logika és adatmodell teljes és működőképes implementációja;
  • legalább fejenként 1-1 EJB-QL lekérdezés;
  • legalább csapatonként 1-1 validációval kiegészített UI űrlap;
  • minden üzleti funkció legyen távolról elérhető WebService és/vagy REST interfészeken keresztül is, a fejlesztés és a bemutató során a funkciók teszteléséhez használhattok WS alapú eszközöket és/vagy tetszőleges UI technológiával elkészített, prototipikus felhasználói interfészeket.
  • átgondolt hibakezelés és loggolás, kezeletlen exception mentes működés (üres catch blokk halálfejes hiba!)

Extra feladatok (melyeket kizárólag akkor értékelünk, ha a megoldás minden alapkövetelményt teljesít -- viszont minden extra közelebb viszi a csapatot a megajánlott jegyhez):

  • teljesértékű UI implementáció (szabadon választott technológiával), teljesértékű validációval
  • heterogén technológiák integrációja (pl. a fogadóirodát megvalósíthatjátok szabadon válaszott technológiával is)
  • extra, az alap üzleti logikán túlmutató funkciók megvalósítása
  • egyéb, egyénileg emailben egyeztetett feladat

Követelmények

A házi feladat csapatmunka, és ezt ellenőrizni is fogjuk. A bemutatóra az alábbiakat kérjük:

  • az összes forráskód projekt (ezeket töltsétek fel az SVN-be 2011. március 17. csütörtök éjfélig)
  • max. 15 perces live demó, melynek során bemutatjátok a kész rendszer működését;
  • max. 5 fóliából álló előadás, amely tartalmazza az összesített munkanaplót, és részletesen bemutatja az egyes csapattagok munkáját, a feladat megoldása során tapasztalt nehézségeket és a rájuk adott megoldásaitokat;
  • a munkanaplót, az SVN-ben tárolt projektekre mutató linket, valamint az előadást kérjük, hogy tegyétek közzé a csapat honlapján (trac) is!

A korábbi tervezési feladatban meghozott tervezői döntések szinte biztos, hogy az implementáció során kisebb-nagyobb változtatásra szorulnak. Ezeket a változtatásokat szövegesen dokumentáljátok a trac-on, és vezessétek vissza az UML modellbe is! Előfordulhat, hogy a határidő tartása érdekében további (egyszerűsítő) döntésekre lesz szükség. Ezeket is dokumentáljátok és tartsátok karban az UML modellt!

Értékelés

Csapatnév Értékelés Megjegyzések
1-es csapat (FTSRG_1) OK kimagasló színvonalú megoldás
2-es csapat (2. modeling csoport) feltételesen elfogadtuk
  • nagyon egyenetlen munkamegosztás
  • Virág Dánielnek a következő feladat során pótolnia kell
  • a WS-ek implementációját mindenképp pótoljátok be a következő SzolgInt házi feladat beadásakor!
3-as csapat OK egyenetlen munkamegosztás, a következőkben ügyeljetek erre!
 

Összességében elmondható, hogy a 2-es és 3-as csapatok esetében (főleg a 2-esnél) nagyon egyenlőtlen munkamegosztást tapasztaltunk. Természetesen ez arra nézve, aki rendesen dolgozott, semmilyen hátrányos  következménnyel nem jár, viszont a következő HF-ek során javasoljuk, hogy:

  • törekedjetek a feladatok kiegyensúlyozottabb elosztására,
  • előre beszéljétek meg, hogy ki mit csinál,
  • mindenki törekedjen arra, hogy a saját munkája a többiek kiesése esetén is bemutatható és működőképes legyen!

Néhány további tanács:

  • időben kezdjétek el a munkát!
  • Próbáljátok meg hatékonyan beosztani az egyes csapattagok munkáját!
  • Nem érdemes szenvedni a VMware image problémáival, az csak segédlet, de nem kötelező használni. Nyugodtan telepítsetek a saját gépetekre fejlesztőkörnyezetet, ehhez igyekszünk minden segítséget megadni a kiadott segédanyagokkal és a gyakorlaton.
  • Bátran kérdezzetek egymástól és az oktatóktól! A csapatok közötti kommunikáció egyáltalán nem tilos, sőt!

3. feladat (MDSD-HF2): Kódvázlat generálása DSM-ből

A második MDSD házi feladatban a fogadási rendszer implementációjának részben generatív elkészítése a cél. Modellből kell generálni JBoss Seam keretrendszer felett működő komponensek forráskódját (pontosabban annak vázát), amelyek a modellben megadott szolgáltatásokat kínálnak fel a megadott felületeken keresztül.

Használt technológiák:

  • kódgeneráláshoz ajánlott: XPand (megbeszélés alapján más technológia is elfogadható)
  • DSM definiáláshoz: EMF
  • célplatform: JBoss Seam

Első lépésként egy alkalmas domain-specifikus modellezési nyelv (DSML) elkészítése szükséges, amelyben a szükséges információk kellően tömören megadhatóak. A nyelvvel legyen leírható:

  • a készítendő komponensek szimbolikus neve és életciklusa (scope),
  • a komponensek egymásra történő hivatkozásai,
  • az egyes komponensek által biztosított szolgáltatások,
  • az egyes szolgáltatások elérhetőségi paramétereinek megadása (SOAP / ReSTful WS annotációk),
  • az egyes szolgáltatások hívási paraméterei (elemi adattípusok, adatmodell elemei).

A kódgenerátor állítsa elő a rendszerkomponensek teljes Java nyelvű vázát, a szolgáltatásokat megvalósító metódusok konkrét implementációja kivételével (a megvalósító metódus maradjon absztakt, üres implementációjú vagy helyőrzővel implementált). A generált kódban ne legyen fordítási hiba, viszont egyéb technikai megkötés nincs, egyszerű esetben a kimenet lehet pusztán szövegfájlok összessége is.

Mivel a szolgáltatások (metódusok) célszerűen hivatkoz(hat)nak az adatmodell elemeire is, ezt kétféleképp lehet kezelni:

  • mindenképpen meg kell oldani, hogy az adatmodell szerepeltethető legyen a DSML-ben. Ez megoldható úgy, hogy a DSML-t kiegészítjük az adatmodellezéshez szükséges elemekkel (entitás, reláció, attribútumok), és aztán a nyelvvel újramodellezük azt, amit már UML-ben megcsináltatok. Egyszerűsítésként az is elfogadható, ha csak az entitásokat modellezzük, mivel a szolgáltatásoknak várhatóan csak erre lesz szüksége.
  • Illetve, a szabványos UML metamodell "behúzható" a saját DSML-ünk metamodellje mellé (jobbklikk, load resource, browse registered packages), így felvehetünk a DSML-be olyan EReference-eket, amelyek az UML-ben definiált típusokra hivatkoznak (pl. UML Class). Ekkor a generált editorban, példányszinten betölthető és hivatkozható lesz az UML-ben megtervezett adatmodell, ugyanúgy, ahogy a metamodellt is kiegészítettük (de ebben az esetben a példány UML modellt kell már load resource technikával betölteni) --  tehát a korábbi munkát újra lehet hasznosítani.

A fenti két megoldás közül bármelyik tetszőlegesen választható, viszont vigyázzatok arra, hogy a generálás során fontos, hogy a generált kód ne tartalmazzon fordítási hibát, azaz:

  • vagy le kell generálni az adatmodellből a JPA annotált kódot (ez mindenképpen extra feladat),
  • vagypedig a DSML szintjén meg kell oldani, hogy hivatkozható legyen a már létező, kézzel írt kódotok (Java fully qualified név szerűen, pl. hu.bme.mit.akarmi.domain.Bet), és akkor ezek a hivatkozások átkerülhetnek a generált kódba (import deklarációkként) -- ezt az egyszerűbb megoldást várjuk el kötelező jelleggel. (Természetesen, ha JPA kódot is generáltok, akkor nem kell az UML-lel és egyebekkel bajlódni.)

A kapcsolódó gyakorlaton mindkét technikát be fogjuk mutatni.

További extra feladatok a megajánlott jegyhez:

  • A generált kód a szolgáltatások kézi implementációja (vagyis a metódustörzsek kitöltése) után azonnal, további beavatkozás nélkül legyen működőképes; tehát a teljes Eclipse projekt(ek) generálandóak minden kellékükkel (XML fájlok, stb) együtt.
  • A modellt megváltoztatva majd a generátort újra futtava az új komponensek / szolgáltatások előállíthatóak legyenek, a meglévő kézi implementációk megtartásával. Tipp: törekedjetek a kézi és generált kód (logikai) szétválasztására!

Követelmények

A házi feladat csapatmunka, és ezt ellenőrizni is fogjuk. Lehetőleg mindenki dolgozzon a feladat minden részével, de legalább az összes érintett technológiával legyen tisztában.

A bemutatóra az alábbiakat kérjük:

  • Feladatmegoldás (ezt töltsétek fel az SVN-be 2011. április. 1. péntek reggel 10:00-ig)
    • a DSM metamodellje és implementációja
    • a kódgenerátor teljes, működőképes állapotban
    • egy példamodell és a belőle generált, működő rendszerimplementáció          
  • max. 5 perces live demo a kódgenerátorról és a generált kód működéséről
  • max. 10 fóliából álló előadás, amelyből kiderülnek a következők:
    • DSM metamodell felépítése
    • a generált kód jellemzői, tervezői döntések
    • a kódgenerátor felépítése, elemei, működése
    • az egyes csapattagok munkája (munkanapló)
  • a munkanaplót, az SVN-ben tárolt projektekre mutató linket, valamint az előadást kérjük, hogy tegyétek közzé a csapat honlapján (trac) is!

A félreértések elkerülése végett: ehhez a feladathoz sem kötelező a segédanyagként kiadott VMWare image használata. A feladat tetszőlegesen összeállított, Eclipse-JBoss Tools környezetben megoldható.

Beadás időpontja: 2011. április. 1. péntek reggel 10:00

Értékelés

Csapatnév Értékelés Megjegyzések
1-es csapat (FTSRG_1) OK kimagasló színvonalú megoldás, extrákkal
2-es csapat (2. modeling csoport) OK a DSML absztrakciós szintje nem volt a legszerencsésebb választás, egyébként rendben.
3-as csapat OK szép munka, némi extrával.

4. feladat (SzolgInt-HF2): BPEL alapú szolgáltatásintegráció 

Használt technológia: WS-BPEL2 (a kiadott VMware image, ill. a fejlesztői környezet segédlet alapján)

A második SzolgInt házi feladatban azt a gyakorlatban sokszor előforduló helyzetet modellezzük, amikor a megrendelő "menet közben" módosítja a követelményeket, vagy újakat talál ki. Ebben az esetben egy új szolgáltatást, egy automatizált brókert kell megvalósítani, amely képes a felhasználó preferenciái alapján automatikusan fogadásokat elhelyezni a rendszerben, és azok eredményét megvárva értesíteni a felhasználót a tevékenység eredményességéről. Technikailag tehát a sportfogadási portálhoz kapcsolódóan kell olyan automatizált munkafolyamatokat létrehozni a BPEL végrehajtható folyamatmodellező nyelv segítségével, amelyek képesek lekérni egy adott időszakhoz tartozó eseményeket, elhelyezni fogadásokat a portálon, továbbá ezt a kettőt felhasználva szimulálni fogadásokat.

A megvalósítandó BPEL folyamatok részletesen:
  1. Események feltöltése: a fogadóirodáknak be kell vinniük a rendszerbe, hogy milyen eseményekre lehet fogadni. A bemeneti paraméter a kezdő és a vég dátum, amelyek között lejátszódó eseményeket szeretnénk bevinni a rendszerbe. Megadható egy opcionális, maximális eseményszám is, amelynek alapértéke 30 (ha nincs megadva híváskor). A folyamat több iroda eseményeit vigye be a rendszerbe, majd válaszként adja vissza a bevitt események azonosítóit.
  2. Fogadások megtétele (bróker): a folyamat bemenetként a felhasználó azonosításhoz szükséges adatait, a fogadás idejét, a feltenni kívánt pénzt (mennyiség és pénznem) és a fogadások maximális számát kapja. Ezek alapján a folyamat kérdezze le a rendszerből az aktuális eseményeket és helyezzen el fogadásokat a rendszerben a felhasználó nevében, majd adja vissza a fogadásokhoz tartozó azonosítókat, amelyek alapján később le lehet kérdezni azok állapotát, vagy hiba esetén a hibaokot. Az események érvényességének, a feltett pénz rendelkezésre állásának vizsgálata a folyamat feladata (is).
  3. Bróker szimulált végrehajtása: az előző két folyamat és a rendszer egyéb szolgáltatásai segítségével ez a folyamat szimulált fogadás lejátszást hajt végre. Bemenetként a fogadás dátuma, a felhasználó azonosításhoz szükséges adatai, a fogadásra feltett teljes összeg és a fogadni kívánt események mennyisége adható meg. Ezek alapján a folyamat beviszi a lehetséges eseményeket (az események feltöltése folyamat meghívásával), ezekből kiválaszt néhányat, majd megteszi a fogadást. Ezután a szimulált időt "előretekeri" a legkésőbbi esemény utánra, lekérdezi a portáltól a fogadások állapotát és visszaadja, hogy mennyit nyert vagy vesztett a felhasználó.
A BPEL folyamatok a portállal a korábban megvalósított webservice interfészeken keresztül kommunikálnak. Előfordulhat, hogy az új követelmények miatt változtatni kell a korábban megvalósított rendszeren (pl. új WS-re lesz szükség, vagy ki kell egészíteni az interfészeket). A módosításokhoz használjátok a korábbi MDSD házi feladatban elkészített kódgenerátort, és tartsátok karban a rendszer DSML modelljét (és esetleges adatmodell változás esetén az UML modellt is, ha indokolt)! Fontos továbbá, hogy a fent részletezett követelmények pontos műszaki értelmezése is a házi feladat része, így pl. elképzelhető, hogy a bróker számára egyéb paramétereket is szükségesnek találtok átadni -- minden ilyen kiegészítés teljes szabadsággal megtehető, de a HF bemutatásánál külön térjetek ki a tervezői döntésekre és indokoljátok is meg azokat!
 
A feladat megoldása során az alábbiakat kérjük:
  • Mindhárom folyamat teljes és működőképes implementációja.
  • Prototipikus UI: a fejlesztés és a bemutató során a folyamatok teszteléséhez használhattok WS alapú eszközöket (SoapUI) és/vagy tetszőleges UI technológiával elkészített, prototipikus felhasználói interfészeket.
  • Átgondolt hibakezelés és loggolás, kezeletlen exception mentes működés.
Extra feladatok (melyeket kizárólag akkor értékelünk, ha a megoldás minden alapkövetelményt teljesít -- viszont minden extra közelebb viszi a csapatot a megajánlott jegyhez):
  • teljesértékű UI implementáció (szabadon választott technológiával), teljesértékű validációval
  • extra, az alap üzleti logikán túlmutató funkciók megvalósítása (összetettebb bróker logika)
A házi feladat csapatmunka, és ezt ellenőrizni is fogjuk. A bemutatóra az alábbiakat kérjük:
  • az összes forráskód projekt feltöltése az SVN-be 2011. április 15. péntek 10.00-ig;
  • max. 15 perces live demó, melynek során bemutatjátok a kész rendszer működését;
  • max. 5 fóliából álló előadás, amely tartalmazza az összesített munkanaplót, és részletesen bemutatja az egyes csapattagok munkáját, a feladat megoldása során tapasztalt nehézségeket és a rájuk adott megoldásaitokat;
  • a munkanaplót, az SVN-ben tárolt projektekre mutató linket, valamint az előadást kérjük, hogy tegyétek közzé a csapat honlapján (trac) is!
Beadás időpontja: 2011. április 15. péntek, új határidő: április 19. kedd!

Értékelés

Csapatnév Értékelés Megjegyzések
1-es csapat (FTSRG_1) OK jó megoldás, némi extrával
2-es csapat (2. modeling csoport) pótlás csak részlegesen működőképes, Dávid Istvánnak a SzolgInt HF3 során pótolnia kell
3-as csapat OK egyenetlen terhelésmegosztás, a bemutatott részek elfogadhatóak. Orova Péternek a SzolgInt HF3 során pótolnia kell.
 
Az értékelés során figyelembe vettük a feladat relatív nehézségét (a többi HF-hez képest).

5. feladat (MDSD-HF3): Statikus hibakeresés BPEL modellekben

Az előző Szolgáltatásintegráció házi feladatban tapasztaltak alapján látható, hogy a BPEL-hez hasonló modellezési nyelvek összetettsége miatt könnyű tervezési hibákat elkövetni. A hibák sokszor csak futási időben derülnek ki (jó esetben), és ez a gyakorlatban hátráltatja a fejlesztőmunkát és rontja a minőséget. A 3. MDSD házi feladatban megvizsgáljuk, hogy hogyan lehet modelltranszformációs technikák használatával javítani a helyzeten, és szerkesztési időben, automatikusan ellenőrizni a modelleket. A feladat megoldása során a kutatócsoportunk által kifejlesztett EMF-IncQuery technológiát fogjátok kipróbálni, egy mintaillesztésen alapuló egyszerű statikus modellhelyesség-ellenőrző megvalósításán keresztül.

Követelmények

Elkészítendő egy olyan validátor program, amelyik az Eclipse/JBoss BPEL editorban szerkesztés alatt álló BPEL modellen a lent felsorolt statikus ellenőrzéseket végzi el. Általános megoldást kell készíteni, amely tetszőleges BPEL modellen működőképes, és az Eclipse felhasználói felületen jelzi a felfedett hibákat vagy gyanús elemeket.

A házi feladat csapatmunka, és ezt továbbra is ellenőrizni fogjuk. A bemutatóra az alábbiakat kérjük:

  • az összes forráskód projekt feltöltése az SVN-be 2011. április 29. péntek 10.00-ig;
  • max. 15 perces live demó, melynek során bemutatjátok a kész rendszer működését;
  • max. 10 fóliából álló előadás, amely tartalmazza az összesített munkanaplót, és részletesen bemutatja az egyes csapattagok munkáját, a feladat megoldása során tapasztalt nehézségeket és a rájuk adott megoldásaitokat; ebben a feladatban külön kérjük, hogy illusztráljátok a HF technikai tartalmát: a gráfmintákat és jelentésüket is!
  • a munkanaplót, az SVN-ben tárolt projektekre mutató linket, valamint az előadást kérjük, hogy tegyétek közzé a csapat honlapján (trac) is!

Kötelezően megvalósítandó jólformáltsági szabályok

  • Létezik-e változó, amelyiket egy tevékenység se olvas (pl. copy)? (Az XPath kifejezések feldolgozásától tekintsünk el.)
  • Keletkezhet-e olyan kivétel, amelyet a szülő szkóp (vagy a folyamat) nem kezel le?
  • Keletkezhet-e olyan kivétel, amelyet egyik ős-szkóp (és a folyamat) sem kezel le?
  • Létezik-e olyan ciklus, amely (legalább egy lefutási ágon) nem végez sem írási műveletet, sem kommunikációt?

Extra feladatok a megajánlott jegyért

  • Bármilyen értelmes és nem triviális (a fentieken túlmutató) jólformáltsági szabály megvalósítását értékeljük!
  • Próbáljátok meg legalább az egyik (összetett) szabályt megvalósítani MDT-OCL segítségével, és hasonlítsátok össze az IncQuery nyelvével!
  • Extraként kipróbálhatjátok az IncQuery technológiát a 2. MDSD házi feladatban általatok kifejlesztett Seam komponens modellező nyelvre is. Példa szabályok:
    • Létezik-e olyan izolált (más komponens által nem hivatkozott) komponens, melynek nincs WS elérhetősége sem?
    • Létezik-e izolált entitás az adatmodellben?
      • Nem tartalmaz sem ki-, sem bemutató referenciát más entitásokra.
      • Nem hivatkozza egyik üzleti logikai komponens sem.

Segédanyagok

Beadás időpontja: 2011. április 29. péntek

Értékelés

Csapatnév Értékelés Megjegyzések
1-es csapat (FTSRG_1) OK jó megoldás egyetlen kisebb hibával (pontatlan BPEL lekérdezés) és némi extrával
2-es csapat (2. modeling csoport) OK jó megoldás kisebb hibákkal (pontatlan BPEL lekérdezések) és extrák nélkül
3-as csapat OK jó megoldás kisebb hibákkal (pontatlan BPEL lekérdezések) és sok extrával

6. feladat (SzolgInt-HF3): Szabály alapú üzleti logika

Az utolsó feladat az üzleti logika "intelligens részének" szabály alapú megvalósítása. Törekedjünk a megoldást úgy felépíteni, hogy a technikai részleteket Java segédeljárásokban bonyolítjuk le, a szabályokra pedig a tényleges magas szintű döntéshozatal feladata hárul. Előny, ha a szabályok kellően lényegretörőek ahhoz, hogy egy hipotetikus üzleti döntéshozó vagy kockázatelemző megérthesse őket, és finomhangolhassa pl. a numerikus paramétereket. A szabályok alapozzák a döntést "hihető" adatokra, tehát a tényleges statisztikákból értelmes számítással képzett becslésekre, de természetesen továbbra sem elvárás, hogy a becslések és a döntések jók ill. sikeresek legyenek. 

Ajánlott technológia: JBoss Drools

Kötelező feladat

Az előző házi feladatban szereplő bróker program intelligenciájának megvalósítása. A bróker robot a portálra csatlakozva bekéret ajánlatokat. Minden ajánlat oddsa és a múltbeli eredmények statisztikái alapján meghatároz egy indikátormennyiséget, amely azt fejezi ki, hogy az adott ajánlatot mennyire tartja fogadásra érdemesnek. Az indikátorhoz rendelt küszöbérték alapján eldönti, hogy mely ajánlatokra fogad; egy fogadóirodánál egy eseménynek legfeljebb egy kimentelére tesz fel pénzt, de összességében több eseményre és eseményenként (külön irodánál) több kimenetelre is fogadhat. Szintén (az előző vagy attól különböző) indikátormennyiség(ek) alapján meghatározza, hogy a rendelkezésére álló pénz mekkora részét kockáztatja, és hogy ezt az összeget milyen arányban osztja el a kiválasztott fogadások között. 

Extra feladatok megajánlott jegyhez

  • Egymástól valamennyire független statisztikai mennyiségek (pl. győzelmek száma, gólkülönbség, megvert csapatok győzelmeinek száma, stb.) alapján több indikátorra alapozott döntéshozatal. Nyilván ilyenkor egyetlen küszöbérték helyett egy többdimenziós térben kell valamilyen törtvonal / poliéder jellegű küszöbfelülettel dönteni a fogadás ellen / mellett. Ezen küszöbfelület "lapjait" egy-egy szabály rögzíti.
  • Szabályok definíciója spreadsheet formájában megadott döntési táblával, ismételten szem előtt tartva az üzleti döntéshozót.
  • Ötletesen számolt indikátorok alkalmazása (pl. valamilyen egyszerűbb gépi tanulás módszerrel, vagy ismert statisztikai becslőkkel).
  • Az egyik fogadóiroda intelligenciájának megvalósítása, a bróker robothoz hasonló elveken.

Követelmények

A házi feladat csapatmunka, és ezt ellenőrizni is fogjuk. A bemutatóra az alábbiakat kérjük:
  • az összes forráskód projekt (beleértve a szabálydefiníciókat) feltöltése az SVN-be 2011. május 13. péntek 10.00-ig;
  • max. 10 perces live demó, melynek során bemutatjátok a kész rendszer működését;
  • max. 10 fóliából álló előadás, amely tartalmazza az összesített munkanaplót, és részletesen bemutatja az egyes csapattagok munkáját, a feladat megoldása során tapasztalt nehézségeket és a rájuk adott megoldásaitokat;
  • a munkanaplót, az SVN-ben tárolt projektekre mutató linket, valamint az előadást kérjük, hogy tegyétek közzé a csapat honlapján (trac) is!

Beadás időpontja: 2011. május 13. péntek

Értékelés

Csapatnév Értékelés Megjegyzések
1-es csapat (FTSRG_1) OK szép megoldás, több extrával
2-es csapat (2. modeling csoport) OK igényes, alapos háttérmunka, bár (Seam gondok miatt) nem nagyon sikerült végül működőképes megoldást összerakni
3-as csapat OK szép megoldás, több extrával