Ozadje

1. Aspektno usmerjen razvoj programske opremeAspect-Oriented Software Development (AOSD)Aspektno usmerjeno programiranjeAspect Oriented Programming (AOP)

2. Ozadje Razvoj na področju računalništva • Internet: porazdeljenost, komunikacije • Širitev tehnologij: EJB, CCM, itd. • Različni uporabniki: različno znanje, naprave, področja aktivnosti • Ostro tekmovanje med podjetji Kako hitro prilagajati programsko opremo potrebam uporabnikov in tehnološkim spremembam?

3. Dilema načrtovalca Dobro načrtovana arhitektura upošteva trenutne in bodoče zahtevke s ciljem zmanjšati “krpe” v implementaciji. Težava pa je v tem, da je napovedovanje bodočnosti težavno opravilo. Če zgrešimo bodoče prerezne zahtevke, bomo morali kasneje spremeniti ali celo zamenjati precej delov sistema. Po drugi strani pa bi usmerjanje pozornosti na malo verjetne zahtevke vodilo k predimenzioniranem, lahko tudi zmedenem sistemu. Zato dilema sistemskih načrtovalcev: Koliko načrtovanja je že pretirano? Ali je bolje poddimenzionirati ali predimenzionirati?

4. Primeri dilem Primer: ali naj načrtovalec vključi v sistem mehanizem beleženja dogodkov (log), čeprav ga sistem v začetku ne potrebuje? In če, kje naj bodo točke beleženja in katere podatke želimo beležiti? Podobne dileme se pojavijo pri zahtevkih o optimizaciji. Vnaprej ne vemo, kje bodo ozka grla. Običajen pristop je, da sistem najprej naredimo, ga preverimo in nato uvedemo optimizacijo. To bo morda terjalo spreminjanje delov sistema. Posledično se bodo morda pojavljala nova ozka grla. Še težje je načrtovalcu ponovno uporabljive knjižnice, saj ne more predvideti scenarijev uporabe knjižnice.

5. Programske paradigme • Proceduralno programiranje • Izvajanje skupine ukazov v danem zaporedju • Fortran, C, Cobol • Funkcionalno programiranje • Ocenjevanje funkcije, definirane s pomočjo drugih funkcij • Lisp, ML, OCaml • Logično programiranje • Dokazovanje teoremov z iskanjem vrednosti prostih spremenljivk • Prolog • Objektno usmerjeno programiranje (OOP) • Organiziranje skupine objektov, od katerih ima vsak svojo skupino odgovornosti • Smalltalk, Java, C++ (deloma), C# • Aspektno usmerjeno programiranje (AOP) • Izvajanje kode, kadarkoli program izkazuje določeno obnašanje • AspectJ (razširitev Jave) • Ne nadomesti OO programiranja, pač pa je njegov komplement

6. OOP -> AOP OOP se izkaže, ko modeliramo skupno obnašanje. Ta pristop pa ni najbolj primeren, ko se srečamo z obnašanji, ki se razpenjajo preko mnogih, pogosto tudi nepovezanih modulov. Metodologija AOP skuša zapolniti prav to vrzel. Prav verjetno bo zato AOP predstavljalo naslednji korak v razvoju programskih metodologij.

7. Razlog za AOP • Tipični programi se pogosto obnašajo tako, da tega ne moremo zložiti v en sam modul. • Zmešana koda (“Code Tangling”) Accounting XML Parsing Logging Database

8. Problemi zaradi zmešanega načrtovanja oziroma kode • Koda za dani zahtevek je razpršena preko več modulov. V vsakem modulu je skupaj zmešana koda za različne zahtevke. • Na primer: • Sinhronizacijska koda je zmešana s sekvenčno kodo. • Nekatere programske naloge ne moremo čisto enkapsulirati v objekte, temveč jih moramo razpršiti po kodi • Primeri: • Log(zapis sledenja obnašanja programa v datoteko) • Profiliranje (ugotavljanje, kje program porabi največ časa) • Sledenje (ugotavljanje, katere metode so klicane in kdaj) • Sledenje in iztek seje • Upravljanje z varnostjo • Rezultat je prerezna (crosscuting) koda – to je koda, ki “zareže” preko več različnih razredov in metod

9. class Fraction { int numerator; int denominator; ... public Fraction multiply(Fraction that) {traceEnter("multiply", new Object[] {that}); Fraction result = new Fraction( this.numerator * that.numerator, this.denominator * that.denominator); result = result.reduceToLowestTerms();traceExit("multiply", result); returnresult;} ...} Sedaj pa pomislimo, da bi imeli podobno kodo v vsaki metodi, ki bi ji želeli slediti Primer

10. Še en preprost primer public class SomeBusinessClass extends OtherBusinessClass {    // Core data members    // Other data members: Log stream, data-consistency flag    // Override methods in the base class    public void performSomeOperation(OperationInformation info) {        // Ensure authentication        // Ensure info satisfies contracts        // Lock the object to ensure data-consistency in case other         // threads access it        // Ensure the cache is up to date        // Log the start of operation// ==== Perform the core operation ====        // Log the completion of operation        // Unlock the object    }    // More operations similar to above    public void save(PersitanceStorage ps) {    }    public void load(PersitanceStorage ps) {    }} Preprost, a bolj konkreten primer. Obravnavamo grobo implementacijo razreda, ki enkapsulira nekaj poslovne logike.

11. Pojasnilo primera • V tej kodi moramo upoštevati najmanj tri stvari. • Drugi podatkovni člani ne spadajo v zadevo tega razreda. • Izgleda, da implementacija performSomeOperation() dela več kot le osnovne stvari. Izgleda, da obravnava (se zaveda) tudi log, avtentikacijo, večnitno varnost, legaliziranje pogodbe in upravljanje z “cache”. Poleg tega lahko več od teh postranskih zadev pride v poštev tudi v drugih razredih. • Ni jasno, ali save() in load() sodita v bistveni del (core part) razreda.

12. Posledice prerezne kode • Redundantna koda • Isti delčki kode na več mestih • Težavno razumevanje • Struktura ni eksplicitna • Slika pomešanosti ni jasna • Težko kaj spreminjamo • Poiskati moramo vso kodo, ki je vključena.. • ...in verjeti, da smo vse konsistentno spremenili • ...in da nismo kaj pomotoma pokvarili • Neučinkovitost, ko prerezne kode pravzaprav ne bi rabili

13. Slabosti odpravimo z aspektno usmerjenim programiranjem (AOP) • Rešitev: Programsko opremo razdelimo v sodelujoče, šibko povezane komponente in opise aspektov. • Tako uredimo načrt oziroma programe in odstranimo redundanco. • Primeri opisa aspektov: razporejanje (marshalling), sinhronizacija, podatkovne strukture itd..

14. Pogled na sistem kot skupino zadev (concerns) Kompleksen sistem lahko gledamo kot združeno implementacijo več zadev (concerns). Tipični sistem je lahko sestavljen iz več zadev, vključno s poslovno logiko, učinkovitostjo, vztrajnostjo podatkov, zapisovanjem sledenja, razhroščevanjem, avtentikacijo, zaščito, večnitno varnostjo, preverjanjem napak itd. Srečamo tudi zadeve razvoja, kot so vsebovanost, vzdrževalnost, sledljivost in enostavnost razvoja. Slika kaže sistem kot množico zadev (concerns), implementiranih na raznih modulih.

15. Analogija z optiko Slika predstavlja skupino zahtevkov (requirements) kot svetlobni žarek, ki prehaja skozi prizmo. Tako posredujemo zahtevke skozi prizmo, ki identificira zadeve in jih razloči. Isti pogled lahko razširimo na zadeve, vezane na razvojni proces.

16. Prerezi zadev v sistemu Razvijalec tvori sistem kot odziv na večkratne zahtevke. Te zahtevke grobo razdelimo v zahtevke na nivoju modulov (core module-level requirements) in zahtevke na sistemskem nivoju (system-level requirements). Veliko sistemskih zahtevkov je medsebojno neodvisnih in tudi neodvisnih od zahtevkov na nivoju modulov. Sistemski zahtevki imajo tendenco prereza čez več modulov. Tako na primer tipična poslovna aplikacija vsebuje prerezne zadeve, kot so avtentikacija, log, administracija, učinkovitost, upravljanje s pomnilnikom. Vsaka od teh zadev ima prerez preko več podsistemov

17. Simptomi Simptome, ki kažejo na problematično implementacijo prereznih zadev, delimo v dve kategoriji: Zmešana koda (code tangling): Moduli v programskem sistemu lahko sočasno interaktirajo z različnimi zahtevki. Tako pogosto razvijalci sočasno razmišljajo o poslovni logiki, učinkovitosti, sinhronizaciji, beleženju dogodkov in varnosti. Taka mnogoterost zahtev se odraža v sočasni prisotnosti elementov za implementacije posameznih zadev, koda postane zmešana. Razmetanost kode (code scattering): Po definiciji so prerezne zadeve razpršene preko več modulov, isto velja tudi za njim ustrezne implementacije. Tako lahko v sistemu, ki uporablja podatkovno bazo, opbravnava učinkovitosti vpliva na vse module, ki dostopajo do podatkovne baze..

18. Posledice Zmešana koda in razpršenost kode vplivata na načrtovanje in razvoj programov na več načinov: Slaba sledljivost: Sočasna implementacija več zadev zakriva skladnost med neko zadevo in njeno implementacijo. Nižja produktivnost: Sočasna implementacija več zadev prestavi pozornost razvijalca od glavne zadeve na postranske, kar zniža produktivnost. Manj kode je ponovno uporabne: Ker pod temi pogoji modul en modul implementira več zadev, se lahko zgodi, da drugi sistemi, ki zahtevajo podobno funkcionalnost, niso sposobni takoj uporabiti tak modul. To pa spet zniža produktivnost. Slaba kvaliteta kode: Zmešanost poraja kodo s skritimi problemi. Poleg tega sočasno mešanje več zadev lahko pomeni, da eni ali več zadevam posvetimo premalo. Težji razvoj: Omejen pogled in omejeni viri pogosto vodijo do načrta, v katerem so obdelane le nekatere zadeve. Obdelava bodočih zadev zahteva pogosto predelavo implementacije. Ker implementacija ni modularizirana, pomeni to delo na več modulih. Sprememba vsakega podsistema lahko vodi v nekonsistence. Nujno je podrobno testiranje, ki naj zagotovi, da take spremembe ne povzročijo novih hroščev

19. Prerezne zadeve (Crosscutting Concerns) Bistvene zadeve (core concerns): • Primarna funkcionalnost. • Centralna funkcionalnost modula. • Prerezne zadeve (Crosscutting Concerns): • Sistemske zadeve, ki so razpredene preko več modulov. • Prerez preko tipične razdelitve odgovornosti. • OOP tvori povezavo med bistvenimi in prereznimi zadevami. • AOP modularizira prerezne zadeve.

20. O reševanju prereznih zadev Veliko sistemov vsebuje prerezne zadeve. Zato ni čudno, da se pojavljajo tehnike, ki modularizirajo njihovo uporabo. Te tehnike vključujejo vmešane (mix in) razrede, načrtovalske vzorce in rešitve, ki so specifične za neko področje.

21. Terminologija • Izrazconcern (zadeva) naj pomenivsako “pojmovno stvar, ki nas zanima”. • Izraz aspect(aspekt) uporabljamo za modul, ki bi lahko enkapsuliral programsko kodo za obravnavo sicer prerezne zadeve. • Zadeve (concerns) lahko obravnava eden ali več aspektov.

22. Prerez komponent in aspektov Boljši program Ga lažje razumemo! Navaden program Struktura skriva funkcionalnost Komponente struktura Aspekt 1 sinhronizacija Aspekt 2

23. Aspekti • V AOP so prerezne zadeve (crosscutting concerns) implementirane v aspektih, namesto da jih vgrajujemo v osnovne (core) module. • Aspekti so dodatne enote modularnosti. • Aspekte lahko ponovno uporabimo. • Z zmanjšanjem zmešanosti kode (code tangling) bomo bolj razumeli, kaj je osnovna funkcionalnost modula. • Tkalec aspektov (“aspect weaver”) vzame aspekte in sestavi končni sistem.

24. Aspekti • V arhitekturi z zadevami so aspekti osnovni gradniki (kot LEGO kocke). • Če eni zadevi ustreza več kot en aspekt, jim pravimo podaspekti (sub-aspects). • Podaspekte običajno souporablja več zadev, lahko pa jih sestavimo v sestavljeni aspekt, ki naslavlja eno zadevo.

25. Aspekti • Relacije med aspekti sistema morajo biti eksplicitne. • Vendar so lahko tudi sami aspekti kompleksni. Morda jih moramo sčasoma glede na spremembe zahtevkov prilagajati in jih moramo zato načrtovati inkrementalno. • Idealno predstavlja vsak aspekt le majhen inkrement. To omogoča tvorbo po potrebi in remodulacijo aspektov s sestavljanjem različnih zbirk aspektov. • Ne moremo predpostaviti, da so aspekti vedno ortogonalni (med seboj neodvisni).

26. Trije razvojni koraki pri AOP Aspektna dekompozicija: Zahtevke (requirements) dekomponiramo in ugotovimo prereze in skupne zadeve. Ločimo zadeve na nivoju modulov od prereznih zadev od prereznih- sistemskih zadev. Implementacija zadev: Vsako zadevo ločeno implementiramo. Aspektna rekompozicija: V tem koraku specificira integrator aspektov pravila rekompozicije tako, da tvori modularizacijske enote - aspekte. Procesu rekompozicije pravimo tudi tkanje (weaving) ali integracija. Tkalec uporablja te podatke (aspekte) in sestavi končni sistem. Vzemimo primer: V jeziku, ki ga nudi AOP implementacija, lahko zahtevamo, da se mora pred poslovno logiko izvesti avtentikacija, na koncu pa se mora izvesti še log (zapis dogodka).

27. Razvojni koraki AOP Tkalec (weaver), sestavlja posamezne zadeve (concerns) v procesu, ki mu pravimo tkanje (weaving). Tkalec torej preplete različne delčke izvedljive logike v skladu s kriteriji, ki mu jih podamo

28. Tkanje (weaving) • Pravila tkanja specificirajo, kako sestaviti končni sistem. • Tkanje lahko izvedemo na več načinov: • Preslikava “Source to source”. • Izboljšanje “Bytecode”: najprej prevedemo izvorno kodo z originalnim prevajalnikom, nato vtkemo aspekte v datoteke “class”. • Tkanje “Just-in-time”, ki ga izvede nalagalnik (classloader). • S prevajalnikom. • Jezik JAsCo podpira tkanje in razpredanje v času izvajanja (runtime).

29. Aspektno usmerjen razvoj programov (AOSD, AOP) monitoring sinhronizacija Vmešani razredi, prerezne zadeve Ločitev zadev (monitoring, synchronisation, debugging, security, etc.) Tkalec MyAspect In MyProgram Before process { prikaz podatkov print “pred obdelavo” } MyProgram zbiranje podatkov prikaz podatkov print “pred obdelavo” obdelava podatkov prikaz rezultatov Where MyProgram zbiranje podatkov obdelava podatkov prikaz rezultatov What

30. Primer tkanja Tkalec (weaver) je proces, ki združuje posamezne zadeve. Z drugimi besedami tkalec preplete različne delčke kode v skladu s kriteriji, ki mu jih podamo. Ponazorimo tkanje kode na primeru obdelave kreditne kartice. Vzemimo poenostavljen primer z le dvema operacijama (credit in debit). Predpostavimo še, da imamo na voljo primeren sistem beleženja dogodkov.

31. Modul za obdelavo kreditne kartice public class CreditCardProcessor {     public void debit(CreditCard card, Currency amount)        throws InvalidCardException, NotEnoughAmountException,              CardExpiredException {// Debiting logic    }    public void credit(CreditCard card, Currency amount)         throws InvalidCardException {// Crediting logic    }}

32. ... in še vmesnik beleženja Imejmo še naslednji vmesnik beleženja: public interface Logger {    public void log(String message);} Želena kompozicija zahteva naslednja pravila tkanja, izražena v naravnem jeziku: • Beleženje (log) začetka vsake javne operacije • Beleženje zaključka vsake javne operacije • Beleženje vsake izjeme, ki bi se zgodila v javni operaciji

33. Sestavljena koda, ki jo tvori tkalec public class CreditCardProcessorWithLogging {    Logger _logger;    public void debit(CreditCard card, Money amount)         throws InvalidCardException, NotEnoughAmountException, CardExpiredException { _logger.log("Starting CreditCardProcessor.credit(CreditCard, Money) "                    + "Card: " + card + " Amount: " + amount); // Debiting logic _logger.log("Completing CreditCardProcessor.credit(CreditCard, Money) "                    + "Card: " + card + " Amount: " + amount);    }    public void credit(CreditCard card, Money amount)         throws InvalidCardException {        System.out.println("Debiting");_logger.log("Starting CreditCardProcessor.debit(CreditCard, Money) "                    + "Card: " + card + " Amount: " + amount); // Crediting logic_logger.log("Completing CreditCardProcessor.credit(CreditCard, Money) "                    + "Card: " + card + " Amount: " + amount);    }}

34. Prednosti AOP AOP helps overcome the aforementioned problems caused by code tangling and code scattering. Here are other specific benefits AOP offers: Modularized implementation of crosscutting concerns: AOP addresses each concern separately with minimal coupling, resulting in modularized implementations even in the presence of crosscutting concerns. Such an implementation produces a system with less duplicated code. Since each concern's implementation is separate, it also helps reduce code clutter. Further, modularized implementation also results in a system that is easier to understand and maintain. Easier-to-evolve systems: Since the aspected modules can be unaware of crosscutting concerns, it's easy to add newer functionality by creating new aspects. Further, when you add new modules to a system, the existing aspects crosscut them, helping create a coherent evolution. Late binding of design decisions: Recall the architect's under/overdesign dilemma. With AOP, an architect can delay making design decisions for future requirements, since she can implement those as separate aspects. More code reuse: Because AOP implements each aspect as a separate module, each individual module is more loosely coupled. For example, you can use a module interacting with a database in a separate logger aspect with a different logging requirement. In general, a loosely coupled implementation represents the key to higher code reuse. AOP enables more loosely coupled implementations than OOP.

35. Benefits of AOSD • To non-invasively Adapt/Configure Application Business Code • Better Modularity, Reusability, and Maintenance • Quicker reaction to Customer needs • To be able to check the Compliance of Applications with requirements e.g. Design by Contracts, Goal-oriented Requirements

36. AOP in OOP Osnovna zamisel je modularizacija implementacije prereznih zadev in s tem njihovo ločitev. Bistvo AOP je v posamezni implementaciji zadev in njihovo ponovno sestavljanje v končni sistem kot prerezne zadeve. V razliko od tega klasičen OOP tvori sisteme z uporabo mehko sklopljenih modulariziranih implementacij skupnih zadev. Modularizacijski enoti pri AOP pravimo aspekt, enako, kot pri OOP imamo za implementacijo skupne zadeve pojem razred (class).

37. AOP in OOP AOP se razlikuje od OOP v načinu, kako naslavlja prerezne zadeve (crosscutting concerns). Pri AOP se vsaka implementacija prerezne zadeve ne zaveda, da jo “gledajo” tudi druge zadeve (aspect = gledišče, vidik). Vzemimo primer kreditne kartice: Modul za njeno obdelavo se ne zaveda da druge zadeve beležijo ali avtenticirajo njegove operacije. To je učinkovit premik paradigme od OOP. Opomba: Implementacija AOP lahko za svojo osnovo vzame tudi kakšno drugo metodologijo in s tem ohranja prednosti te, osnovne metodologije. Tako lahko vzame za osnovo OOP. Stvar je analogna temu, da je lahko nek proceduralen jezik temelj za več OOP jezikov.

38. Anatomija jezikov AOP Kot pri vseh programskih metodologijah tudi AOP vsebuje dva dela: Specifikacije jezika in implementacije. Specifikacija jezika opisuje jezikovne konstrukte in sintakso. Implementacija jezika preverja pravilnost kode glede na specifikacijo in jo pretvarja v obliko, izvedljivo na ciljnem računalniku.

39. Specifikacija jezika AOP Na višjem nivoju specificira jezik AOP dve komponenti: Implementacija zadev (concerns): Preslikava posameznih zahtevkov v kodo tako, da jih lahko prevajalnik prevede v izvršljivo kodo. Ker ima implementacija zadev obliko procedur, lahko uporabimo tradicionalne jezike, kot so C, C++ ali Java z AOP. Specifikacija pravil tkanja: Kako sestaviti neodvisno implementirane zadeve v končni sistem. Za to moramo imeti jezik za specifikacijo pravil, kako sestavljati različne kose v končni sistem. Ta jezik je lahko razširitev obstoječega jezika, lahko pa si izmislimo nekaj povsem novega.

40. Implementacija jezika AOP • AOP prevajalniki opravljajo dva logična koraka: • Sestavijo posamezne zadeve • Pretvorijo rezultat v izvedljivo kodo AOP ima lahko implementiran tkalec na več načinov, vključno s preslikavo ene izvorne kode v drugo (source-to-source translation). V tem primeru obdelamo izvorno kodo za posamezne aspekte in tako dobimo stkano izvorno kodo. AOP prevajalnik nato porine to pretvorjeno kodo osnovnemu prevajalniku jezika, ta pa tvori končno, izvedljivo kodo.

41. AspectJ AspectJ je hkrati specifikacija AOP jezika in njegova implementacija. Definira različne konstrukte in njihov pomen za podporo aspektno usmerjenih pojmov. Implementacija jezika nudi orodja za prevajanje, razhroščevanje in dokumentiranje kode. Jezik AspectJ razširja jezik Javo. Tako je vsak javanski program tudi veljaven AspectJ program. Prevajalnik AspectJ tvori datoteke “class”, ki so kompatibilne s specifikacijo “bytecode” in jih lahko interpretira vsak kompatibilni javanski navidezni stroj (JVM). AspectJ tako ohranja vse prednosti Jave in je javanskim programerjem lahek. . AspectJ nudi tkalca aspektov v obliki prevajalnika, vsebuje pa tudi razhroščevalnik, ki se zaveda aspektov, generator dokumentacije in samostojen brkljalnik aspektov za prikaz prerezov v sistermu. AspectJ nudi tudi dobro integracijo s popularnimi razvojnimi orodji, kot so: Sun Microsystems' Forte, Borland's JBuilder in Emacs.

42. Pregled jezika AspectJ Za podporo AOP dodaja AspectJ jeziku Java nekaj novih pojmov: • Aspekt (Aspect) – modularna enota, ki implementira neko prerezno nalogo. Aspekti so podobni razredom. • Stičišče (Join point) – določljiva točka v strukturi ali izvajalnem toku programa, v katero je umeščena aspektna logika • Stičiščni prerez (Pointcut) – določa množico stičnih točk, opremlja jezik AOP s kvantifikacijskim mehanizmom • Navodilo (Advice) – vedenje, ki se izvaja v neki stični točki (pred, po, namesto ali okoli). Navodila so podobna metodam. • Uvod (introduction) – spreminja člane razreda in relacije med razredi Pointcut in advice skupaj specificirata pravila tkanja. Aspect je pojem, podoben razredu in s pointcuts in advices oblikuje prerezno enoto. Pointcuts specificirajo točke izvajanja in kontekst pravil tkanja. Advices specificirajo akcije, operacije ali odločitve, ki naj se v teh točkah izvedejo. Na stičišča (joinpoints) lahko gledamo tudi kot na množico dogodkov, na katere se odzovemo z določenimi navodili (advices)

43. Navodilo “after” a Line Akcija, ki se izvedepo računanju v stični točki (joint point) Navodilo “after” se izvede“na povratku” Aspekt definira poseben razred, ki prerezuje druge razrede pointcut move(): call(void Line.setP1(Point)) || call(void Line.setP2(Point)); after() returning: move() { <code here runs after each move> } aspect History Updating {}

44. Približna sintaksa • Aspekt je: aspect nameOfAspect { body } • Aspekt vsebuje uvode (introductions), stičiščne prereze (pointcuts) in navodilo (advice) • Stičiščni prerez (pointcut) je: when(signature) • Podpis vsebuje tip return • “when” jecall, handler, execution, itd. • Imenovani označevalec “pointcut” je:name(parameters): pointcutDesignator • Navodilo (advice) je:adviceType(parameters): pointcutDesignator { body } • Uvodi (introductions) so v bistvu kot navadna javanska koda.

45. Stičišče (join point) • Stičišče (join point) je dobro definirana točka v poteku programa • Želimo izvesti neko kodo (navodilo or advice) kadarkoli dosežemo stičišče • Nočemo vnašati nove zmede v kodo z eksplicitnimi indikatorji tipa “To je stičišče” • AspectJ nudi sintakso za nakazovanje teh stičišč “z zunanje strani” prave kode • Stičišče je točka v programu, kjer “se nekaj zgodi” • Primeri: • Ko kličemo neko metodo • Ko pride do neke izjeme • Ko dostopamo do neke spremenljivke

46. AspectJ Pozdravljen svet Ohranimo tradicijo uvoda v nek programski jezik s programom “Pozdravljen svet”, to pot zapisanim v AspectJ. Najprej imejmo preprost razred, ki vsebuje metode za izpis besedila: // HelloWorld.javapublic class HelloWorld {     public static void say(String message) {        System.out.println(message);    }    public static void sayToPerson(String message, String name) {        System.out.println(name + ", " + message);    }}

47. Dodajanje aspektov Sestavimo primer z dodajanjem pozdravov in zahval. Preden program izpiše obvestilo, naj napiše “Dober dan!“. Za obvestilom pa naj še “Hvala lepa!": // MannersAspect.javapublic aspect MannersAspect { pointcut callSayMessage() : call(public static void HelloWorld.say*(..)); before() : callSayMessage() {        System.out.println(“Dober dan!");    }after() : callSayMessage() {        System.out.println(“Hvala lepa!");    }} Ime prereza prerez (pointcut)

48. Razlaga Datoteka “MannersAspect.java” je podobna deklaraciji razreda v javi., deklarira pa aspekt “MannersAspect”. Aspekt definira stičiščni prerez (pointcut) “callSayMessage()”, ki lovi klice vseh javnih statičnih metod z imeni, ki se začno s “say”. V našem primeru bo ujel say() in sayToPerson() v razredu HelloWorldne glede na število argumentov. Definiramo tudi dve navodili za izvedbo pred nastopom stičiščnega prereza callSayMessage() in po njem. Ti navodili predvidevata izpis “Dober dan!" in “Hvala lepa!" Če prevedemo tak program s prevajalnikom AspectJ in ga poženemo, dobimo pred in po izpisu vsakega obvestila še izpisa “Dober dan!" oziroma “Hvala lepa!". Res smo olikani!

49. Drug primer: FigureElement

50. Stičiščni prerezi (pointcuts) • Definicije stičiščnih prerezov imajo levo in desno stran, ločeni z dvopičjem • Na levi imamo ime prereza in njegove parametre (torej podatke, ko je prišlo do dogodka) • Na desni strani je sam stičiščni prerez (pointcut) • Primer:pointcut setter(): call(void setX(int)); • Ime prereza jesetter • Prerez nima parametrov • Prerez kot tak jecall(void setX(int)) • Prerez se nanaša na katerikoli čas, ko kličemo metodo void setX(int)