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)

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 modellek, az EMF-es kódok (generáltak is), valamint a folyamatmodell projektjei (ezt töltsétek fel az SVN-be 2012. március 5. éjfélig)
  • implementációs terv és munkanapló a trac wikin
  • 10-15 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, forgatókönyvek
    • hogyan néz ki a domain-specifikus rendszerterv, különös tekintettel:
      • a fő üzleti entitások struktúrája
      • kapcsolódásuk a funkcionalitást irányító elemekhez (komponensek és szolgáltatásaik)
      • a komponensek egymás közötti kapcsolatai (függőségek, hivatkozások)
    • implementációs terv áttekintése
    • az egyes csapattagok munkája (munkanapló)

Végül két 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!
  • A házi feladat megoldását időben el kell kezdeni! Amint egy adott technológia sorra került az előadáson, célszerű belekezdeni az adott részfeladat megoldásába, hogy elég idő legyen a végén a csapat munkáját összehangolni, átnézni.

 

 

2. feladat: az alkalmazásbolt üzleti logikájának generatív implementációja

Beadás időpontja: 2012. április 10. 17.

A házi feladat második részében 2+2 részfeladatot kell megoldani:

  • Szolgáltatásintegráció
    • a rendszer üzleti logikáját megvalósító szolgáltatások és adatmodell teljeskörű implementációja, a HF1-ben beadott implementációs terv alapján.
    • az üzleti folyamatok modelljeinek kiegészítése, javítása, valamint az egyes szolgáltatások és a folyamatmodell integrációja a folyamatvezérelt működés megvalósítása érdekében. 
  • Modellvezérelt szoftvertervezés
    • A HF1-ben kialakított domain-specifikus modellezési nyelv, valamint az UML és DSM példánymodellek finomítása, kiegészítése, a konkrét implementáció során felmerülő igények alapján.
    • Kódgenerátor, mellyel a rendszer üzleti logikáját megvalósító szolgáltatások vázának forráskódja (legalább az egyik platformra) automatikusan előállítható.

A szolgáltatások implementációja kapcsá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 két különbőző, de szabadon választott platform (pl. OSGi és .NET) felhasználásával (azaz legalább egy szolgáltatást a többitől eltérő platformon kell elkészíteni).
    • Célszerű úgy megtervezni a rendszert, hogy az implementáció nagy része egy platformon történjen, és ehhez néhány "külső", perzisztens műveleteket nem végző szolgáltatást integrálunk. Ezzel elkerülhető az elosztott, heterogén rendszereken átívelő tranzakciókezelés problémája.
  • Minden üzleti funkció legyen távolról elérhető HTTP/REST interfészeken keresztül is;
  • Átgondolt hibakezelés és loggolás, kezeletlen exception mentes működés.

Extraként értékeljük:

  • Részleges vagy teljes UI implementáció (szabadon választott technológiával), alap validációval.
  • Szabadon választott harmadik platform használata.
  • Egyéb, egyénileg a konzulenssel emailben egyeztetett feladat.

A kódgenerátor kapcsán az alábbiakat kérjük:

  • A generátor állítsa elő a rendszerkomponensek forrásnyelvű 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. Ügyeljetek a "bemenet", tehát a modell tartalmának ellenőrzésére, automatikus "escape"-elésére (pl. a célnyelven foglalt szavak megfelelő kezelésére)!

Extraként értékeljük:

  • Az objektumorientált adatmodell implementációs osztályainak generálása.
  • 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 / Visual Studio / stb. 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!
  • Több célplatformra történő generálás (részben, vagy teljesen közös forrásmodellből).
  • Egyéb, egyénileg a konzulenssel emailben egyeztetett feladat.

Ajánlott technológiák

  • OSGi Declarative Services, Jersey, EclipseLink
  • .NET WCF
  • Eclipse EMF, Xtend

SzolgIntből tetszőleges platform használható, MDSD-ből személyesen megindokolt igény esetén szabadon el lehet térni az ajánlott Eclipse-es technológiáktól.

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 DSM, UML és folyamatmodell frissített projektjei (ezt töltsétek fel az SVN-be 2012. április 16. éjfélig);
  • munkanapló a trac wikin;
  • max. 20 perces live demó, melynek során bemutatjátok a kész rendszer, valamint a kódgenerátor működését;
  • max. 15 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, összefoglalja a modellek változásait, valamint a feladat megoldása során tapasztalt nehézségeket és a rájuk adott megoldásaitokat.

Tippek, tanácsok

  • A kódgenerálási feladatot azután érdemes elkezdeni, miután az implementáció (egy része) kézi módszerrel elkészült. A kódgenerátor megírásához ugyanis pontosan kell látni, hogy hogyan is fog kinézni a generált kód.
  • A szolgáltatások implementációját érdemes elkezdeni amilyen korán csak lehet! A csapatmunkát hatékonyan szervezzétek meg! 
  • A végső implementáció elkészítéséhez hatékony segítséget nyújthat a(z akár csak részlegesen működő) kódgenerátor.
  • Az implementáció során kiderülhet, hogy a kezdeti terveken (akár a modelleken, akár az implementációs terven) módosítani (csökkenteni) kell. Végezzétek el nyugodtan a módosítást és dokumentáljátok a döntéseket!

 

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ő!