UNIVERSITY OF SZEGED D epartment of Software Engineering UNIVERSITAS SCIENTIARUM SZEGEDIENSIS 6. Nyelvi paradigmák trendek - logika megvalósítása Dr. Bilicki Vilmos Szegedi Tudományegyetem Informatikai Tanszékcsoport Szoftverfejlesztés Tanszék

UNIVERSITY OF SZEGED D epartment of Software Engineering UNIVERSITAS SCIENTIARUM SZEGEDIENSIS Tartalom  RUP – absztrakciós szintek  Nyelvek generációi  Logika megvalósítása ■Folyamat nyelvek ■Szabály nyelvek ■Tartomány specifikus nyelvek ■Aspektus Orientált nyelvek Programrendszerek fejlesztése

UNIVERSITY OF SZEGED D epartment of Software Engineering UNIVERSITAS SCIENTIARUM SZEGEDIENSIS RUP – absztrakciós szintek  RUP Programrendszerek fejlesztése

UNIVERSITY OF SZEGED D epartment of Software Engineering UNIVERSITAS SCIENTIARUM SZEGEDIENSIS Nyelvek fejlődése Programrendszerek fejlesztése

UNIVERSITY OF SZEGED D epartment of Software Engineering UNIVERSITAS SCIENTIARUM SZEGEDIENSIS Logika megvalósítása  POP (Post Objektum Orientált) ■AOP ■Dinamikus  COP ■CDI,…  Folyamat nyelvek  Szabály nyelvek Programrendszerek fejlesztése

UNIVERSITY OF SZEGED D epartment of Software Engineering UNIVERSITAS SCIENTIARUM SZEGEDIENSIS Folyamat nyelvek  WFMS – Munkafolyamat Kezelő Rendszerek (Workflow Management System)  80-as évek adatközpontú világnézet ■az adatok voltak a fejlesztők fókuszában és nem a folyamatok  Ma már kellő intelligencia található a különböző keretrendszerekben -> a folyamatok álljanak a fejlesztők, sőt az adott tartomány szakértői azaz a nem szoftver fejlesztők figyelmének központjában.  Munkafolyamat leíró nyelvek ■grafikus megjelenítéssel is rendelkeznek ■magát a folyamatot megfelelő fejlesztő eszközök segítségével nem programozó is meg tudja tenni.  Alkalmazási területek ■üzleti folyamatok modellezése ■hagyományos üzleti folyamatok koordinálása ■Komponens keretrendszerek ■Munkafolyamatok közötti interakciók ■B2B interakciók ■felhasználói folyamatok  A logika dinamikusan változtatható akár futásidőben is Programrendszerek fejlesztése

UNIVERSITY OF SZEGED D epartment of Software Engineering UNIVERSITAS SCIENTIARUM SZEGEDIENSIS Munkafolyamat séma - workflow scheme  Segítségével definiálhatóak az aktivitások és a közöttük logikai relációk  Az aktivitás a munka egy atomi eleme  A munkafolyamat definíciókat hasonlóan az OO osztályokhoz példányosítani kell a futtatáshoz  Az egyes aktivitások a munkafolyamaton belül átmenetekkel vannak összekötve.  A konkrét aktivitás sorozatok egymással párhuzamosan is futtathatóak.  Az aktivitásokat különböző szerepkörű humán vagy gépi entitásokhoz rendelhetjük és esetenként magát az aktivitást is ezek az entitások végzik el.  Két adattípust szoktak megkülönböztetni: ■vezérlő információ amelyet a munkafolyamat egyes csomópontjaiban szükséges döntésekhez használjuk és tipikusan a munkafolyamat futása alatt léteznek ■produkciós adat melyben olyan objektumok vannak melyek léte nem függ a munkafolyamattól Programrendszerek fejlesztése7

UNIVERSITY OF SZEGED D epartment of Software Engineering UNIVERSITAS SCIENTIARUM SZEGEDIENSIS Munkafolyamat kezelő rendszerek  Munkafolyamatok létrehozása ■Munkafolyamat séma létrehozása  Futtatása ■Munkafolyamat példányosítása ■Résztvevő –Szervezeti struktúra/Szerepkörök –Alkalmazások  Monitorozása ■Vezérlő/Produkciós adat ■Vezérlés szál Programrendszerek fejlesztése8

UNIVERSITY OF SZEGED D epartment of Software Engineering UNIVERSITAS SCIENTIARUM SZEGEDIENSIS Munkafolyamat tervezési minták  Nincs általánosan elfogadott rendezőelv  Tervezési minták: Wil van Der Aalst, Arthur H.M. Hofstede, Bartek Kruszewski, and Alistair P. Barros (2003). "Workflow Patterns„  Lehetséges nézetek ■Vezérlő folyam ■Adat perspektíva ■Erőforrás perspektíva ■Működési perspektíva Programrendszerek fejlesztése9

UNIVERSITY OF SZEGED D epartment of Software Engineering UNIVERSITAS SCIENTIARUM SZEGEDIENSIS Vezérlő folyam nézet  Egyszerű vezérlő minták: azon minták melyek a folyamat vezérlés elemi műveleteit írják le  Összetett elágazás és szinkronizálás minták: a kötegelt kezelés és a szinkronizáció témakörében fellelhető bonyolultabb minták  Strukturális minták: olyan minták amelyek a munkafolyamat modellek struktúráját határozzák meg  Több példányt is érintő minták: egy adott aktivitásnak több egyszerre futó példánya is lehet  Időbeli relációk: két vagy több aktivitás közötti viszonyt kifejező minta család  Állapot alapú minták: a rendszer állapotkezelő képességét leíró minták  Visszavonási minták: az aktivitások futási engedélyének visszavonását leíró minták  Munkafolyamatok közötti szinkronizáció: a csoportba a különböző munkafolyamat példányok vagy a különböző munkafolyamat példányai közötti szinkronizációt leíró minták tartoznak Programrendszerek fejlesztése10

UNIVERSITY OF SZEGED D epartment of Software Engineering UNIVERSITAS SCIENTIARUM SZEGEDIENSIS 1. Szekvenica  egy munkafolyamaton belül egy aktivitás akkor kerül aktív állapotba, ha az előtte lévő aktivitás befejeződött  Pl: ■aru_kuldes ■szamla_kuldes Programrendszerek fejlesztése11

UNIVERSITY OF SZEGED D epartment of Software Engineering UNIVERSITAS SCIENTIARUM SZEGEDIENSIS 2. Párhuzamos elágazás  A munkafolyamat olyan pontja ahol az egy szálú végrehajtás több párhuzamos szálra ágazik  Típusai: ■Explicit (van külön elágazás elem) ■Implicit (nincs külön elágazás elem)  Pl.: ■Áruk kiszállítása ■Felhasználó értesítése Programrendszerek fejlesztése12

UNIVERSITY OF SZEGED D epartment of Software Engineering UNIVERSITAS SCIENTIARUM SZEGEDIENSIS 3. Szinkronizálás  A munkafolyamat olyan pontja ahol több alfolyamat/végrehajtási szál egyesül egy folyamattá/végrehajtási szállá egyesülnek így szinkronizálva a végrehajtásukat  Típusai: ■Explicit ■Implicit  Pl.: ■Archiválás a send_tickets és a receive_payment után hajtódhat végre Programrendszerek fejlesztése13

UNIVERSITY OF SZEGED D epartment of Software Engineering UNIVERSITAS SCIENTIARUM SZEGEDIENSIS 4. Kizárólagos választás  Egy olyan döntési pont ahol valamilyen döntési elv alapján egy végrehajtási ágat választanak ki a több lehetséges közül  Típusai: ■Explicit ■Implicit  Pl: ■A kiszállítás vagy egyik vagy másik módszerrel történik Programrendszerek fejlesztése14

UNIVERSITY OF SZEGED D epartment of Software Engineering UNIVERSITAS SCIENTIARUM SZEGEDIENSIS 5. Egyszerű egyesítés  Több folyamat/végrehajtási ág egyesül egy végrehajtási ágba szinkronizálás nélkül, azaz bármelyik szál teljesül az indikálja az új közös szál indítását  Pl.: ■Ha így vagy úgy fizettek akkor ki lehet szállítani Programrendszerek fejlesztése15

UNIVERSITY OF SZEGED D epartment of Software Engineering UNIVERSITAS SCIENTIARUM SZEGEDIENSIS 6. Többes választás  A munkafolyamat egy olyan pontja ahol egy vagy több végrehajtási száll indul adott döntés meghozatala után  Pl.: ■Miután kiértékelte a kár típusát lehet, hogy a tűzoltóságot vagy a biztosítót vagy mindkettőt hívja Programrendszerek fejlesztése16

UNIVERSITY OF SZEGED D epartment of Software Engineering UNIVERSITAS SCIENTIARUM SZEGEDIENSIS 7. Szinkronizációs egyesítés  A munkafolyamat egy olyan pontja ahol több végrehajtási szál is egyesül egy végrehajtási szállá. A párhuzamos útvonalaknál szükséges a szinkronizáció míg az alternatív útvonalaknál nem. Ha egy ág már teljesült akkor addig nem aktiválódhat amíg más ága az egyesítő csomópontban nem aktiválódtak.  Pl.: ■Miután értesítettük a tűzoltókat és/vagy a biztosítót, értesítsük a felhasználót is (egyszer) Programrendszerek fejlesztése17

UNIVERSITY OF SZEGED D epartment of Software Engineering UNIVERSITAS SCIENTIARUM SZEGEDIENSIS 8. Többes egyesítés  Egy olyan pont a munkafolyamatban ahol több ág egyesül szinkronizáció nélkül. Az új ág annyiszor indul el ahányszor a beérkező ágak befejeződnek  Pl.: ■Ha a biztosító kiment vagy/és a tűz el van oltva akkor jelezzük ezt a központnak Programrendszerek fejlesztése18

UNIVERSITY OF SZEGED D epartment of Software Engineering UNIVERSITAS SCIENTIARUM SZEGEDIENSIS 9. Megkülönböztető  Egy olyan pont a munkafolyamatban amely egy beérkező ág teljesülése után indítja tovább a szálat. Ezután megvárja amíg minden beérkező szál teljesül és ezeket figyelmen kívül hagyja. Miután mindegyik teljesül újra a számláló állapotba kerül és kezdődik a tevékenysége előröl  Ciklusban nehéz megvalósítani  Pl.: ■Több tűzoltó állomásnak is szólunk, a legelső mehet ki Programrendszerek fejlesztése19

UNIVERSITY OF SZEGED D epartment of Software Engineering UNIVERSITAS SCIENTIARUM SZEGEDIENSIS 10. N-ből M csatlakozás  M párhuzamos ág egyesül egy ágba, hasonlóan az előzőhöz N ág teljesülése után továbbmegy és minden ág teljesülése után újra N ág teljesülése után továbbmegy Programrendszerek fejlesztése20

UNIVERSITY OF SZEGED D epartment of Software Engineering UNIVERSITAS SCIENTIARUM SZEGEDIENSIS 11. Tetszőleges ciklus  A munkafolyamat egy olyan pontja ahol egy vagy több aktivitást többször is végre kell hajtani  Ez több mint a strukturális ciklus amelyek nem átlapolhatóak és csak egy belépő illetve egy kilépő pontjuk van (while vs. goto) Programrendszerek fejlesztése21

UNIVERSITY OF SZEGED D epartment of Software Engineering UNIVERSITAS SCIENTIARUM SZEGEDIENSIS 12. Implicit befejezés  Egy adott végrehajtási ágat akkor kell befejezni amennyiben már nincs végrehajtandó aktivitás, a munkafolyamatot pedig akkor amikor olyan aktivitás amely aktív vagy aktívvá tehető (és a munkafolyamat nincs versenyhelyzetben)  Sok munkafolyamat motor ilyenkor minden még futó aktivitást megszakítanak Programrendszerek fejlesztése22

UNIVERSITY OF SZEGED D epartment of Software Engineering UNIVERSITAS SCIENTIARUM SZEGEDIENSIS 13. Több példány szinkronizálás nélkül  Adott aktivitásoknak több mint egy futó példánya lehet  Pl: ■Egy könyv megrendelésekor sok másik könyvet is megrendelhetünk mindegyikre le kell futnia a munkafolymatnak Programrendszerek fejlesztése23

UNIVERSITY OF SZEGED D epartment of Software Engineering UNIVERSITAS SCIENTIARUM SZEGEDIENSIS 14. Több példány amelyekről futtatáskor tudtunk  Az adott aktivitás párhuzamosan futó példányainak száma valamilyen futásidőben keletkező adattól függ (még mielőtt az adott aktivitást aktiválnák).  Pl.: ■Cikkek véleményezése Programrendszerek fejlesztése24

UNIVERSITY OF SZEGED D epartment of Software Engineering UNIVERSITAS SCIENTIARUM SZEGEDIENSIS 15. Több példány amelyekről nem tudtunk  Az adott aktivitás párhuzamosan futó példányainak száma valamilyen futásidőben keletkező adattól függ (csak az aktiválás után derül ki).  Pl: ■Adott számú könyv kézbesítésénél nem ismert előre, hogy milyen adagokban lehet kézbesíteni Programrendszerek fejlesztése25

UNIVERSITY OF SZEGED D epartment of Software Engineering UNIVERSITAS SCIENTIARUM SZEGEDIENSIS 16. Elhalasztott XOR elágazás  A lehetséges végrehajtási ágak közül egyet választ de csak akkor amikor azt elkezdi végrehajtani (többet is elindít, de csak a leggyorsabban induló futhat, a többit visszavonja) Programrendszerek fejlesztése26

UNIVERSITY OF SZEGED D epartment of Software Engineering UNIVERSITAS SCIENTIARUM SZEGEDIENSIS 17. Átlapolt párhuzamos forgalom irányítás  A végrehajtási ágak egy csoportja kerül végrehajtásra, de a sorrend futásidőben dől el, és egyszerre csak egy fut (egy példányon belül)  Pl.: ■A katonaságnál a felvételinél van fizikai és elméleti teszt mindkettő kell a sorrend tetszőleges, de nem lehet egyidőben Programrendszerek fejlesztése27

UNIVERSITY OF SZEGED D epartment of Software Engineering UNIVERSITAS SCIENTIARUM SZEGEDIENSIS 18. Mérföldkő  Adott aktivitás csak akkor indul el, ha a rendszer adott állapotban van. Ezt tipikusan egy mérföldkő elérését jelenti és azt, hogy ennek az ideje még nem járt le.  Pl.: ■A könyv rendelője visszavonhatja a könyv rendelést, ha már rendelt és még nem indították el a kiszállítást Programrendszerek fejlesztése28

UNIVERSITY OF SZEGED D epartment of Software Engineering UNIVERSITAS SCIENTIARUM SZEGEDIENSIS 19. Aktivitás visszavonás  Egy futásra váró szál futási engedélyét visszavonjuk  Pl.: ■A vásárló visszavonja az információkérelmet Programrendszerek fejlesztése29

UNIVERSITY OF SZEGED D epartment of Software Engineering UNIVERSITAS SCIENTIARUM SZEGEDIENSIS 20. Teljes munkafolyamat példány visszavonás  Pl.: a vásárló visszavonja a vásárlását  Ez tipikusan API szinten valósul meg a munkafolyamat példány törlésével. Nem jellemző a grafikus támogatás Programrendszerek fejlesztése30

UNIVERSITY OF SZEGED D epartment of Software Engineering UNIVERSITAS SCIENTIARUM SZEGEDIENSIS Folyamat nyelvek  Felhasználói folyamatok -> pageflow (JSF/SEAM)  Üzleti folyamatok -> BPLE4WS Programrendszerek fejlesztése31

UNIVERSITY OF SZEGED D epartment of Software Engineering UNIVERSITAS SCIENTIARUM SZEGEDIENSIS Szabály nyelvek  A tudás ábrázolásának egy módja a szabályokkal történő ábrázolás.  Az erre épülő rendszereket Produkciós Szabály Alapú rendszereknek nevezik (Production Rule Engine). ■bemeneti adatok (tényeknek nevezik ebben a körben – Facts) ■szabályok (Rule) ■eredmények/események Programrendszerek fejlesztése32

UNIVERSITY OF SZEGED D epartment of Software Engineering UNIVERSITAS SCIENTIARUM SZEGEDIENSIS Szabály alapú megközelítés  Előnyei: ■Deklaratív programozás (Mit és nem hogyan) ■Logika és adat elkülönül ■Skálázható/Gyors ■Központi tudástár ■Eszközök ■Naplózás/Értelmezés ■Érthető szabályok  Hátrányai: ■Szorosan csatolt probléma esetén túl bonyolult Programrendszerek fejlesztése33

UNIVERSITY OF SZEGED D epartment of Software Engineering UNIVERSITAS SCIENTIARUM SZEGEDIENSIS Szabály nyelv megközelítések  Szabály modellezés: Az URML nyelv segítségével a szabályok hasonlóan különböző UML nyelvekhez vizuálisan modellezhető.  Objektum orientált szabály rendszerek: Olyan szabály nyelv implementációk melyek az objektum orientált szemantika, szintaktika segítségével oldják meg az adatok kezelését. A szabály nyelvek is gyakran valamilyen OO nyelvhez hasonló szemantikával vannak megvalósítva.  Szemantikus web szabály nyelvek: Itt az erőforrások (adatok) hozzáférése az URI-n alapuló eszköztár segítségével tipikusan ontológiák bevonásával lehetséges. A gyakorlatban ez azt jelenti, hogy az adatokat gráf formájában ábrázolják melynek szabályrendszerét az ontológia leírás adja meg.  MI szabály rendszerek: Azon megoldásokat szokták ide sorolni melyek erős többnyire erős formalizmussal támogatva valamilyen fokú tanulási képességekkel rendelkeznek Programrendszerek fejlesztése34

UNIVERSITY OF SZEGED D epartment of Software Engineering UNIVERSITAS SCIENTIARUM SZEGEDIENSIS Szabály motor  Egy olyan eszköz ami lehetővé teszi számunkra a: ■Üzleti szabályok kezelését (Tudás Ábrázolás) ■Kiértékeli a szabályokat a tények alapjáb és következtetéseket von le (következtető motor – Inference Engine)  Üzleti Szabály Kezelő Rendszerek - Business Rules Management Systems Programrendszerek fejlesztése

UNIVERSITY OF SZEGED D epartment of Software Engineering UNIVERSITAS SCIENTIARUM SZEGEDIENSIS Következtető Motor – Inference Engine  A szabály motorok központi eleme  A tényeket és a hozzájuk tartozó szabályokat párosítja minta illesztés segítségével  Elemei:  Munka memória (tények)  Produkciós memória (szabályok)  Minta illesztő  Konfliktus feloldás Programrendszerek fejlesztése

UNIVERSITY OF SZEGED D epartment of Software Engineering UNIVERSITAS SCIENTIARUM SZEGEDIENSIS Előre láncolt Szabály Motor  Adat vezérlésű/Reaktív Programrendszerek fejlesztése37

UNIVERSITY OF SZEGED D epartment of Software Engineering UNIVERSITAS SCIENTIARUM SZEGEDIENSIS Hátra Láncolt Szabály Motor  Cél vezérlésű/ Proaktív Programrendszerek fejlesztése38

UNIVERSITY OF SZEGED D epartment of Software Engineering UNIVERSITAS SCIENTIARUM SZEGEDIENSIS Drools - Szabályok  Baloldali (LHS) - Feltételek  Jobb oldali (RHS) – Szabályok  Lehetőségek: ■Globális források használata: segítségével definiált globális változókon keresztül a szabály elérheti az alkalmazás objektumait. ■Függvények deklarálása: segéd kód részek megfelelő strukturálását segíti. Leggyakrabban a következmények megvalósítását segíti. ■Típusok deklarálása: Új típusokat hozhatunk létre futásidőben illetve meta adatokkal egészíthetjük ki a meglévő adatmodellünket. ■Lekérdezések: a LHS-ben leírt kifejezések segítségével lehet meghatározni a szabályt. Itt halmazműveletekkel (pl.: contains) reguláris kifejezéseket használhatunk melyek kiegészíthetőek időbeliségen (pl.: during) alapuló logikával (amennyiben használjuk a CEP modult - Complex Event Processing) ■Szabályok: A RHS segítségével a következményeket írják le Programrendszerek fejlesztése39

UNIVERSITY OF SZEGED D epartment of Software Engineering UNIVERSITAS SCIENTIARUM SZEGEDIENSIS Drools állapotmentes viszony  Nem alkalmaz következtetést  Egy-egy tényre (tény csoportra működik)  Függvényhívás szemantikához hasonlít Programrendszerek fejlesztése40

UNIVERSITY OF SZEGED D epartment of Software Engineering UNIVERSITAS SCIENTIARUM SZEGEDIENSIS Drools állapottartó viszony  Hosszú ideig él, lehetővé teszi az iteratív módosításokat  Adott típusú objektumból több példány is lehet -> kereszt szorzat ■SQL join-hoz hasonló megoldás ■Figyelni kell arra, hogy megfelelő szűrések legyenek  A tények adattagjai módosíthatóak (modify) Programrendszerek fejlesztése41

UNIVERSITY OF SZEGED D epartment of Software Engineering UNIVERSITAS SCIENTIARUM SZEGEDIENSIS Példa tények Programrendszerek fejlesztése42

UNIVERSITY OF SZEGED D epartment of Software Engineering UNIVERSITAS SCIENTIARUM SZEGEDIENSIS Példa szabályok Programrendszerek fejlesztése43

UNIVERSITY OF SZEGED D epartment of Software Engineering UNIVERSITAS SCIENTIARUM SZEGEDIENSIS Rete szabály motor  Dr. Charles Forgy PhD  Részei ■Szabály fordítás –Hogyan vannak a szabályok a munkamemóriába ábrázolva –Megkülönböztető hálózat az adat terjedés közbeni szűrésére –A hálózat tetején lévő csomópontoknál sok az egyezés lejebb haladva egyre kevesebb ■Futtatás Programrendszerek fejlesztése44

UNIVERSITY OF SZEGED D epartment of Software Engineering UNIVERSITAS SCIENTIARUM SZEGEDIENSIS Rete algoritmus Programrendszerek fejlesztése45

UNIVERSITY OF SZEGED D epartment of Software Engineering UNIVERSITAS SCIENTIARUM SZEGEDIENSIS Példa Programrendszerek fejlesztése46

UNIVERSITY OF SZEGED D epartment of Software Engineering UNIVERSITAS SCIENTIARUM SZEGEDIENSIS Tartomány Specifikus nyelvek  SQL  BPEL Programrendszerek fejlesztése

UNIVERSITY OF SZEGED D epartment of Software Engineering UNIVERSITAS SCIENTIARUM SZEGEDIENSIS Tartomány specifikus nyelvek  Saját koncentrált, csökkentett képességú szintaktika, szemantika  Célok: ■A fejlesztők produktivitásának növelése ■Az adott tartomány szakértőinek minél hatékonyabb bevonása a tervezései/fejlesztési és tesztelési folyamatba  Típusai ■Külső DSL ■Belső DSL ■Nyelvi fejlesztő környezet Programrendszerek fejlesztése48

UNIVERSITY OF SZEGED D epartment of Software Engineering UNIVERSITAS SCIENTIARUM SZEGEDIENSIS Drools - DSL  Szabályokat szakértőknek kell ellenőrizni/megalkotni  Testreszabhatjuk a LHS és RHS kifejezéseket Programrendszerek fejlesztése49

UNIVERSITY OF SZEGED D epartment of Software Engineering UNIVERSITAS SCIENTIARUM SZEGEDIENSIS AOP  Kiegészíti az OO programozást  Az alapvető üzleti problémák vs. Az átmetsző vállalati problémák  Az AOP komponensei ■Aspect – a keresztülívelő problémák modulba foglalásának alapja ■Join point – jól definiált pontok a program folyamban ■Pointcut –join point szűrő a betoldás futásánák meghatározására ■Advice – egy küdrész ami a pointcut által meghatározott részen fut ■Weaving – Fordítás, vagy futásidőben a megfelelő helyekre betoldja a megfelelő kódot.  Az EJB-ben található deklaratív megoldások egy alternatívája  Aspektusok a kód változtatása nélkül hozzáadhatóak és elvehetőek Programrendszerek fejlesztése

UNIVERSITY OF SZEGED D epartment of Software Engineering UNIVERSITAS SCIENTIARUM SZEGEDIENSIS Spring AOP  Az aopalliance szövetség által definiált interfészekre építő keretrendszer  Az aspektusok Java nyelvben vannak megvalósítva. Nem kell pointcut lekérdező nyelvet tanulni  A Spring aspektusok az IoC konténerben paraméterezhetőek ■A konténerből kapott objektumok transzparens módon szabhatóak  A Spring AOP sok kész aspektust biztosít (tranzakció kezelés, naplózás, …) Programrendszerek fejlesztése

UNIVERSITY OF SZEGED D epartment of Software Engineering UNIVERSITAS SCIENTIARUM SZEGEDIENSIS Spring AOP  Az alábbi tanácsokat támogatja: ■Metódus előtt ■A metódus visszatérése után ■throws tanács ■Körül tanács  Az interceptorokat és a tanácsokat láncolhatjuk precedencia alapján  Az aspektusok futás időben vannak szőve. Programrendszerek fejlesztése

UNIVERSITY OF SZEGED D epartment of Software Engineering UNIVERSITAS SCIENTIARUM SZEGEDIENSIS Spring AOP körbe tanács példa public class PerformanceMonitorDetailInterceptor implements MethodInterceptor { protected final Log logger = LogFactory.getLog(getClass()); public Object invoke(MethodInvocation invocation) throws Throwable { String name = invocation.getMethod().getDeclaringClass().getName() + "." + invocation.getMethod().getName(); StopWatch sw = new StopWatch(name); sw.start(name); Object rval = invocation.proceed(); sw.stop(); logger.info(sw.prettyPrint()); return rval; } Programrendszerek fejlesztése

UNIVERSITY OF SZEGED D epartment of Software Engineering UNIVERSITAS SCIENTIARUM SZEGEDIENSIS Folytatás <bean id="perfMonInterceptor" class= "com.meagle.service.interceptor.PerformanceMonitorDetailInterceptor"/> <bean id="performanceAdvisor" class="org.springframework.aop.support.RegexpMethodPointcutAdvisor">.*find.*.*save.*.*update.* Programrendszerek fejlesztése

UNIVERSITY OF SZEGED D epartment of Software Engineering UNIVERSITAS SCIENTIARUM SZEGEDIENSIS AOP Szövés

UNIVERSITY OF SZEGED D epartment of Software Engineering UNIVERSITAS SCIENTIARUM SZEGEDIENSIS Összefoglaló  RUP – absztrakciós szintek  Nyelvek generációi  Logika megvalósítása ■Folyamat nyelvek ■Szabály nyelvek ■Tartomány specifikus nyelvek ■Aspektus Orientált nyelvek Programrendszerek fejlesztése

UNIVERSITY OF SZEGED D epartment of Software Engineering UNIVERSITAS SCIENTIARUM SZEGEDIENSIS Következő előadás  Adatábrázolás ■Relációs ■OO ■Ontológia ■Leképezések ■ORM Programrendszerek fejlesztése57