400 likes | 495 Views
Innovatív megoldások az eFilter projektben. Kusper Gábor 1 , Kovács Emőd 1 , Márien Szabolcs 2 , Kusper Krisztián 2 , Scheffer Imre 2 , Kiss Balázs 2 , Kovács Péter 2 és Winkler Ernő 2 1: Eszterházy Károly Főiskola, 2: Wit-Sys Zrt. Előadja: Kusper Gábor gkusper @ aries.ektf.hu
E N D
Innovatív megoldások az eFilter projektben Kusper Gábor1,Kovács Emőd1, Márien Szabolcs2, Kusper Krisztián2, Scheffer Imre2, Kiss Balázs2, Kovács Péter2és Winkler Ernő2 1: Eszterházy Károly Főiskola, 2: Wit-Sys Zrt. Előadja: Kusper Gábor gkusper@aries.ektf.hu Informatika a felsőoktatásban 2011, Debrecen
Tartalom • Az EgerFood projekt • Az eFilter projekt bemutatása • Innovációk • Innovatív modellezés • Összefoglalás
Az EgerFood információs rendszere Munkafolyamat gráf Az egyedülálló képességek kulcsa a munkafolyamat-gráf. A gráf segítségével minden cég egyedi módon modellezheti a gyártási folyamatait. Ez a modell vezérli a kliens program és az adatbázis mőködését. A modell szinte végtelen lehetőségeket nyújt és nem mellékesen összetett képet ad a cég működéséről is. Megtervezéséhez ezért a cég képviselőjének és a beüzemelést végző szakemberek közös munkájára van szükség.
EgerFood cikkek: • T. Radványi, G. Kusper: RequirementAnalysis and a Database Model for the Project EgerFood Food Safety Knowledge Center, ICAI-2007, p. 15-23, 2007. • K. Liptai, G. Kusper, T. Radványi: Cryptographycalprotocols in the Egerfood Information System, Annales Mathematicae et Informaticae 34., p. 61-70, 2007. • Kusper Gábor, Radványi Tibor: Az EgerFood élelmiszerbiztonsági nyomkövető rendszer – Hogyan modellezzük a cégek munkafolyamatait, Networkshop 2008, Dunaújváros, 8 oldal, 2008.
Az eFilter projekt • KMOP-1.1.1-09/1-2009-0053 számú pályázat • Egészségügyi profil alapján szűrt fogyasztói adatbázisokból nyert információkat kezelő rendszer - eFilter • WIT-SYS Consulting ZRt. • Eszterházy Károly Főiskola
Egészségügyi profil • Ételallergiák • Ételérzékenységek • Diéták • Egyéb étkezésnél figyelembe veendő betegségek, pl.: cukorbetegség
Megszorítások • eFilter szabályok típusai: • 0 – Tiltás • 1 – Nem javasolt • 2 – Erősen javasolt • 3 – Javasolt • Étel 100 grammjára vonatkozik. • Példa: • Tiltások: dió > 0g. • Nem javasolt: energiatartalom > 500 kcal, zsír > 20g.
Többdimenziós megszorítás mátrix fehérje TÜKÖRTOJÁS MÜZLI zsír CSÁSZÁRSZALONNA GULYÁSLEVES só 0 g < fehérje tartalom <= 2 g 0 g < zsír tartalom <= 1.5 g 0 g < só tartalom <= 2.2 g
Funkcionális szintű innovációk • Személyre szabott egészségügyi profil kezelés. • Fogyasztási szokások követése. • Megkönnyíti a dietetikussal való kapcsolatfelvételt és kapcsolattartást: • Nem mi keressük meg a dietetikust, hanem a dietetikus névtelenül látja, hogy ki fogyaszt túl sok kalóriát, és ő tud minket figyelmeztetni. • Erre nevünk vállalásával válaszolhatunk.
Innovatív modellezés • A modell rétegei realizációs kapcsolatban állnak. • A modell használati eset alapú. • Minden eset őse egy általános használati eset. • pl. létrehozás, módosítás, … • Általános használati esetekhez általános teszt esetek. • Fejlesztői szerepkörök felvétele a modellbe.
Innovatív projektvezetés • Változások követése mini projektként. • Wiki alapú tudástár használata. • Feladat kezelő használata. • Maven, SVN és egyéb eszközök használata.
Innovatív megvalósítás • GUI: JBoss Rich Faces, AJAX, XHTML • Üzleti logika: JavaEE, JBoss Seam • Perzisztencia: Hibernate • Adatbázis: Oracle 11g • Tesztelés: Selenium, TestNG, Jenkins
Innovatív modellezés A modell rétegei realizációs kapcsolatban állnak. A modell használati eset alapú. Minden eset őse egy általános használati eset. Általános használati esetekhez általános teszt esetek. Fejlesztői szerepkörök felvétele a modellbe.
A modell rétegi • A modell rétegi a RUP módszertan szerint: • Üzleti modell, • Követelmény modell, • Rendszer modell, • Implementációs modell, • Tesztelési modell. • Az egyes rétegek egymásra épülnek. • Pl.: minden specifikáció valamily követelményből származik.
Üzleti modell • A rendszer felülnézete, tartalmazza: • az üzleti folyamat modellt, • az üzleti használati eset modellt, • az üzleti entitás modellt, • az üzleti szerepköröket. • A modell üzleti használati eset központú.
Követelmény modell • A üzleti szereplőkkel folytatott interjúk során keletkezett információkat gyűjti össze. • Az üzleti modell megszorításait pontosítja. • Általános, absztrakt funkcionális használati eseteket definiál. • Ezekből származnak a konkrét esetek. • Általános funkcionális használati esetek: • Létrehozás, Módosítás, Törlés, Keresés, listázás, Megtekintés
A modell használati eset alapú • A terv fő integráló elemei a használati esetek. • A használati esetek működését szekvencia és aktivitás diagramokkal részletezzük.
Rendszer modell • A rendszer modell a funkcionális modellben meghatározott funkcionális használati esetek • adat tartalmát (entitás modell), • viselkedését (kontroller modell), • felhasználói felületét (felület terv) adja meg. • Leírja, hogy a felhasználók hogyan használják a használati eseteket.
Implementációs modell • A rendszer modell adaptációja a kiválasztott fejlesztő környezethez: • GUI: JBoss Rich Faces, AJAX, XHTML • Üzleti logika: JavaEE, JBoss Seam • Perzisztencia: Hibernate • Adatbázis: Oracle 11g • Tesztelés: Selenium, TestNG, Jenkins
Tesztelési modell • A funkcionális használati esetek szerint határozzuk meg a lehetséges teszteseteket. • A tesztesetek alapját az absztrakt használati esetekre kötött absztrakt tesztesetek képezik, amelyek a tesztesetek jelentős részének a vázát specifikálják. • Az absztrakt teszteseteket a leszármazott konkrét tesztesetekkel csak a kezdő és végállapot deklarálásával kell specializálnunk.
A tesztesetek alapját az absztrakt használati esetekre kötött absztrakt tesztesetek képezik
Csak az elő- és utófeltételt kell megadni • Egy létrehozás alapú tesztnél elég csak megadnunk a létrehozandó bejegyzés adatait • Módosítás alapú tesztnél meg kell adnunk a bejegyzés módosítás előtti és utáni állapotát. Ez egyértelműen megadja az összes adatot amire szükségünk lehet.
Modell rétegek kapcsolatai • A rétegek közötti realizációs kapcsolatokkal követhető, hogy • egy követelményből miként következik egy üzleti használati eset, • egy üzleti használati eset hogyan kerül kibontásra egy funkcionális használati eset csomaggal, • egy funkcionális használati eset adattartalmát és viselkedését mely rendszermodell entitások és kontrollerek adják.
Modell rétegek kapcsolatai • Minden réteg tartalmaz egy olyan modell csomagot, amely az adott réteg absztraktabb modell szintekkel való kapcsolatát specifikálják és mutatják meg. • A modell rétegek közötti realizációs kapcsolatokkal követhetők, hogy a modellen az egyes módosításoknak milyen következményei vannak, melyeket végig kell követni.
Projektvezetés támogatása modellezéssel • A modellben a projekt résztvevőit rögzítettük. • Így tervben is rögzítésre kerülnek a fejlesztési szerepkörök és felelősségek. • A modellben rögzítjük, hogy az egyes alrendszereket, modulokat mely tervező modellezte, a fejlesztést illetve tesztelést ki végezte. • Ha van egy módosítás, akkor a fejlesztés teljes életciklusa végigfut, amely a modellben szintén visszakereshetően rögzítve van.
A projektből leszűrt eredmény • Néhány tervezési minta már a használati eset diagramon felismerhető. • Pl. a Sablonfüggvény (Template Method) tervezési minta használatára utal, ha egy felhasználó több olyan használati esetet is használhat, amelyeknek közös az őse.
Összefoglalás • A projekt során alkalmazott projektvezetési és tervezési módszerek és megoldások teljesítettek a tervezési integritással, fejlesztési minőséggel kapcsolatos célokat. • A bevezetett UML 2.x-n alapuló modellezési módszer lehetőséget ad arra, hogy a • tervezés – fejlesztés – tesztelés • integritása megmaradjon a későbbi módosítások kezelése során is. Így a megvalósítás és a tervezés során előállt elképzelés nem fog eltérni egymástól.