I NNOVATÍV MEGOLDÁSOK AZ E F ILTER 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 Informatika a felsőoktatásban 2011, Debrecen 1

Tartalom  Az EgerFood projekt  Az eFilter projekt bemutatása  Innovációk  Innovatív modellezés  Összefoglalás 2

3

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. 4

EgerFood cikkek:  T. Radványi, G. Kusper: Requirement Analysis and a Database Model for the Project EgerFood Food Safety Knowledge Center, ICAI-2007, p ,  K. Liptai, G. Kusper, T. Radványi: Cryptographycal protocols in the Egerfood Information System, Annales Mathematicae et Informaticae 34., p ,  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,

Az eFilter projekt  KMOP / 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 6

Az eFilter projekt Bő élelmiszer listaEgészségügyi profilSzűk élelmiszer lista Menük listája Boltban kapható élelmiszerek listája Étel rendelésnél étlap Boltok listája kapható élelmiszerekkel SZŰRÉS Fogyasztható menük listája Boltban kapható fogyasztható élelmiszerek listája Fogyasztható ételek listája Fogyasztható terméket áruló boltok listája KérdésEgészségügyi profilVálasz Megvásárolt élelmiszer fogyasztható-e? Vásárlásnál megerősítés, hogy az adott termék fogyasztható-e? ELLENŐRZÉS Igen / Nem + Megvásárolt élelmiszerről bő információ 7

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 8

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. 9

Többdimenziós megszorítás mátrix fehérje zsír só 0 g < fehérje tartalom <= 2 g 0 g < zsír tartalom <= 1.5 g 0 g < só tartalom <= 2.2 g CSÁSZÁRSZALONNA MÜZLI TÜKÖRTOJÁS GULYÁSLEVES 10

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. 11

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. 12

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. 13

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 14

 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. Innovatív modellezés 15

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. 16

Ü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ú. 17

18

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 19

20

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. 21

22

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. 23

24

25

26

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 27

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. 28

A tesztesetek alapját az absztrakt használati esetekre kötött absztrakt tesztesetek képezik 29

Master entitás bejegyzés aktivitási diagramja 30

Csak az elő- és utófeltételt kell megadni 31  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. 32

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. 33

34

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. 35

36

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. 37

38

Ö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. 39

KÖSZÖNÖM A FIGYELMET! 40