Házi feladat (SzolgInt-MDSD 2012)

Kerettörténet - App Store

A feladat egy alkalmazásbolt - angol nevén app store - üzleti logikájának megtervezése és megvalósítása. A boltból a felhasználók alkalmazásokat vásárolhatnak, a fejlesztők feltölthetik saját munkájukat, a bolt üzemeltetője pedig az alkalmazások minőségellenőrzésével, illetve a pénzügyi tranzakciók lebonyolításával foglalkozik.

Az alkalmazásboltban mindenkinek (felhasználóknak, fejlesztőknek) egyéni kontója van, mely kreditekben számol el (pénzügyi szempontból 1 kredit 1 EUR-nak felel meg) és minden korábbi tranzakciót, vásárolt alkalmazást eltárol. A felhasználók (hitelkártyával) krediteket vásárolhatnak (melyeket aztán alkalmazásokra költhetnek el), a fejlesztők pedig kreditekben kapják meg a vásárlások ellenértékét, melyet aztán EUR-ban utalhatnak át bankszámlájukra. Az alkalmazások árát (kreditben) a fejlesztők határozzák meg, az egyes vásárlások alapján a bolt üzemeltetőjét 30%-os részesedés illeti.

Az alkalmazásbolt a végfelhasználók számára a következő szolgáltatásokat kívánja nyújtjani:

• Böngészés: a bolt alkalmazásainak listázása, különféle keresési feltételek, tematikus listák alapján.
• Alkalmazás megtekintése: egy kiválasztott alkalmazás adatainak megjelenítése.
• Vásárlás: az alkalmazás kiválasztása után a boltban fenntartott egyéni kontó terhére történő vásárlás.
• Kontó menedzsment: az egyéni kontóba krediteket lehet feltölteni, amelyeket a felhasználó banki átutalással vásárolhat meg. A felhasználó megtekintheti már megvásárolt alkalmazásait is.

Az alkalmazásbolt a fejlesztők számára a következő szolgáltatásokat kívánja nyújtjani:

• Alkalmazás feltöltése, verziókezelés, metaadatok: a fejlesztő kezdeményezheti egy-egy új alkalmazás feltöltését, már elfogadott alkalmazásaihoz új verzió feltöltését, illetve a meglévő alkalmazások és verzióik metaadatainak módosítását. Minden változtatást a bolt üzemeltetője saját belső szempontjai szerint bírál el és hagyhat jóvá.
• Kontó menedzsment: a fejlesztő megtekintheti saját kontóját, illetve a bevételeit átutalhatja saját bankszámlájára. A fejlesztő áttekintheti saját alkalmazásait.

A bolt üzemeltetője számára először egyetlen fő funkciót szeretnénk megvalósítani:

• Minőségbiztosítási folyamat: a bolt üzemeltetője számára fontos, hogy a felhasználók kizárólag jó minőségű, biztonságos szoftvereket tölthessenek le a boltból. Ezért minden, a boltba feltöltött alkalmazás szigorú minőségbiztosítási folyamaton megy át (melynek részét képezik az emberi ellenőrzés, tesztelés, valamint automatikus verifikációs és bytekód audit technikák is). A minőségbiztosítási folyamat végzi a már korábban jóváhagyott alkalmazások új verzióinak, ill. metaadat-módosításainak ellenőrzését is (speciális szempontok alapján).

Általános megjegyzések

• A házi feladat üzleti folyamatait a jBPM5-ben futó BPMN2 folyamatokként, az egyes elemi üzleti logikai funkciókat pedig RESTful webszolgáltatásként kell megvalósítani. Az elemi funkciók közötti vezérlés- és adatáramlás biztosítása a BPMN2 folyamat feladata.
• A webszolgáltatások megvalósításához szabadon választott technológia felhasználható. Követelmény, hogy legalább két különböző technológiát kell felhasználni, valamint a szolgáltatásoknak a perzisztens adatokat objektumrelációs leképezésen keresztül relációs adatbáziskezelőben tárolják. A gyakorlatokon a Java/JPA és .NET/Entity Framework technológiákat mutatjuk majd be.
• A házi feladathoz NEM elvárás a felhasználói felület kialakítása.
• A fenti kiírás szándékosan tartalmaz nem pontosan, esetleg ellentmondásosan specifikált részleteket. A csapatok feladata lesz a követelményanalízis során ezek feloldása, pontosítása.

Fejlesztőeszközök, segédletek, telepítési útmutatók

Itt olvasható.

1. feladat: az alkalmazásbolt részletes UML alapú követelményanalízise, DSM alapú architektúrális modellezése, valamint BPMN2 alapú folyamatmodellezése

Beadás időpontja: 2012. március 6.

A házi feladat első részében 2+2 részfeladatot kell megoldani:

• Modellvezérelt szoftvertervezés
  • Az alkalmazásbolt részletes UML követelményanalízise (beleértve az összes szükséges külső szolgáltatás igénybevételét), amely a következők elkészítését foglalja magába:
    • Magasszintű követelmények: UML Use Case Diagram
    • Forgatókönyvek részletesebb kifejtése szövegesen, vagy opcionálisan UML Activity Diagramként
  • Domain-specifikus modellezési nyelv és példánymodellek a szolgáltatás-orientált rendszerarchitektúra modellezéséhez. A nyelvvel legyenek leírhatóak az alábbiak:
    • a rendszer üzleti komponensei és adatmodellje (entitások):
      • az egyes komponensek által biztosított szolgáltatások, valamint ezek hívási paraméterei,
      • az entitások adattagjai és ezek típusai,
      • az entitások adattagjaira vonatkozó, egyszerű jólformáltsági kényszerek (OCL nyelven),
    • a komponensek, szolgáltatások és entitások egymásra történő hivatkozásai.
    • A nyelv alapján elkészítendő a konkrét rendszerterv.
• Szolgáltatásintegráció
  • az üzleti folyamatok magasszintű modellezése BPMN2-ben (minőségbiztosítás és opcionálisan az alkalmazásvásárlás)
  • részletes implementációs terv, mely kifejti, hogy a folyamat(ok)ban szereplő egyes szolgáltatások milyen technológiával és műszaki tartalommal lesznek megvalósítva. 

A modellekre 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, szolgáltatás, üzleti entitás, üzleti folyamat stb.) modelljei 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.

Technológiák

• 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ó)
• Eclipse Modeling Framework (Indigo Release)
• jBoss jBPM5 (mintafolyamat)

3. feladat: szabályalapú rendszerek

Beadás időpontja: 2012. május 8.

A házi feladat utolsó, harmadik részében egy-egy feladatot kell megoldani:

• Szolgáltatásintegráció: a HF2-ben elkészült rendszer kiegészítése a "Géniusz" szolgáltatással, amely az adatbázis tartalma alapján, a felhasználói szokások elemzésével szabályalapú, intelligens alkalmazásajánló funkciót valósít meg.
• Modellvezérelt szoftvertervezés: A HF1-ben kialakított, és a HF2-ben finomított domain-specifikus modellezési nyelvhez jólformáltsági kényszerek szerkesztés közbeni ellenőrzését támogató kiegészítő modulok implementációja. 

Az intelligens ajánló irányelvei:

• A "Géniusz" személyre szabva, a felhasználó kezdeményezésére válogasson ki kis számú (5-10) alkalmazást üzleti szabályrendszer segítségével, az alábbi szempontok alapján:
  • Ne ajánljon olyan appot, amelyet a felhasználó már megvásárolt.
  • Opcionálisan: a vásárló életkorát figyelembe véve értelemszerűen rejtse el a magasabb korhatárú appokat.
  • Az ajánlás elsősorban szolgálja az alkalmazásbolt üzleti érdekeit, tehát részesítse előnyben a közelmúltban népszerű (sokat vásárolt) és egyúttal drága (tehát nagy bevételt generáló) appokat.
  • Emellett részesítse előnyben az olyan app készítők műveit, akiktől a felhasználó sokat vásárolt.
  • Továbbá a felhasználóhoz hasonló vásárlási szokású felhasználók által vásárolt appok halmazát is vegye figyelembe.
  • Ezen felül részesítse előnyben az olyan appokat, amelyeknek a kategóriájából sokat appot vásárolt a felhasználó.
• Fontos: Minden felsorolt tényezőnek legyen jelentősége, tehát ne legyen olyan, amelynek a hatása elhanyagolható a többihez képest.
• Információforrás: a kiadott minta adatbázishoz (amely egy EMF modell) egy egyszerű importert kell készíteni. Az importer beolvassa az általunk adott mintaadatokat és a HF2-ben implementált rendszer (szükség esetén kiegészített) adatmodelljére konvertálva eltárolja őket az adatbázisban.

Extraként értékeljük:

• Üzleti döntéshozó által is szerkeszthető döntési tábla alkalmazása, pl. az egyes szempontok alapján számolt metrikák értékét öt-öt tartományra osztva, tartományonként kicsit más hatást előírva.
• Skálázhatósági kérdések figyelembe vétele.
• A szabályok (fél)automatikus származtatása adatbányászati módszerek alapján (pl. Weka segítségével).
• Az adatmodell kiegészítése miatt esetlegesen fellépő modellmigrációs probléma megoldása az Edapt technológia segítségével.
• Egyéb, a konzulenssel előre egyeztetett kiegészítő feladat.

A jólformáltsági ellenőrző irányelvei:

• A szabályok célja, hogy a gyakori modellezési hibákat, hiányos/értelmetlenül kitöltött modell részeket kiszűrjük. Olyan megoldásra célszerű törekedni, amely garantálja, hogy a validátor által elfogadott modelleken a kódgenerátor mindig hibamentesen le tudjon futni, és helyes kódot generáljon.
  • Ennek teljeskörű megvalósítása a feladatban nem elvárás, hiszen ez - a nyelv összetettségétől függően - akár igen nehéz feladat is lehet, de érdemes erre törekedni.
• Minden csapat a saját maga által megtervezett nyelvhez, a HF2-ben szerzett tapasztalatok alapján készítsen minimum 5 szabályt, melyek között legyen összetett szabály is (pl. entitások öröklődési hierarchiájának ellenőrzése, körök keresése).
• A HF3 megoldható Eclipse OCL vagy EMF-IncQuery technológiával is.

Extraként értékeljük:

• A HF3 szabályainak megvalósítása Eclipse OCL és EMF-IncQuery technológiával is,  majd rövid összehasonlítás készítése az egyes technológiák tapasztalt előnyeiről-hátrányairól.
• A minimumkövetelményeken felüli összetett, nemtriviális szabályok készítése:
  • célplatformon foglalt kulcsszavak szűrése,
  • izolált/interfész szolgáltatások keresése: van-e olyan szolgáltatás a rendszermodellben, amelyet semmilyen más szolgáltatás sem használ?
  • izolált entitások keresése: van-e olyan entitás az adatmodellben, amelyet semmilyen más entitás nem hivatkozik, és nem használ egyetlen szolgáltatás sem?
  • stb.
• Egyéb, konzulenssel egyeztetett kiegészítő funkciók megvalósítása. 

Speciális extra:

• minden, az (aktív fejlesztés alatt álló) EMF-IncQuery technológiában felfedezett, és a saját Trac issue trackereteken keresztül bejelentett, és általunk a GitHub felületen visszaigazolt, reprodukálható hibáért külön meglepetés jutalmat ajánlunk fel!
  • Reprodukálható hibajelentés: rendelkezésre áll a tapasztalt hibajelenség leírása, minden olyan szoftverkomponens (EMF Ecore fájl, modell kód, példánymodell, stb), amely a hiba előállításához szükséges, valamint egy részletes, lépésről-lépésre leírás a hiba előállításához.

Ajánlott technológiák

• JBoss Drools
• EMF-IncQuery
• Eclipse OCL

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, valamint a példánymodellek frissített projektjei (ezt töltsétek fel az SVN-be 2012. május 7. éjfélig);
• részletes munkanapló;
• max. 20 perces live demó, melynek során bemutatjátok a validációval kiegészített modellszerkesztő, valamint a Géniuszt is megvalósító, teljes rendszer működését;
• max. 20 fóliából álló összefoglaló előadás, amely tartalmazza az összesített munkanaplót, és részletesen bemutatja az egyes csapattagok munkáját, valamint a feladat megoldása során tapasztalt nehézségeket és a rájuk adott megoldásaitokat.
  • Készüljetek fel rá, hogy az előadást széles közönség előtt adjátok majd elő!