Aspektno-orijentisano programiranje

U računarstvu, aspektno-orijentisano programiranje (AOP) je patentirana paradigma programiranja koja ima za cilj da poveća modularnost dozvoljavajući izdvajanje mehanizmom kros-sečenje problema. To čini dodavanjem dodatnog ponašanja na postojećem kodu bez menjanja samog koda, umesto odvojeno navodeći koji kod je modifikovan preko "pointkat" specifikacije, kao što su "log sve funkcije poziva kada ime funkcija počinje sa 'set' ". Ovo omogućava ponašanja koja nisu u središtu poslovne logike (kao što ulogovanje) da se doda u programu bez prenatrpavanja jezgra koda na funkcionalnosti. AOP formira osnovu za aspektno orijentisan razvoj softvera.

AOP obuhvata metode i alate koji podržavaju modularizaciju zabrinutosti na nivou izvornog koda za programiranje, dok se  "aspekt orijentisan razvoj softvera" odnosi na čitave inženjerske discipline.

Aspekt-orijentisano programiranje podrazumeva razbijanje programske logike u različitim delovima (tzv. brige, ujedinjene oblasti funkcionalnosti). Skoro sve programske paradigme podržavaju određeni nivo grupisanja i enkapsulacije zabrinutosti u posebne, nezavisne entitete pružajući apstrakcije (npr. funkcije, procedure, moduli, klase, metode) koje mogu da se koriste za sprovođenje, apstrakcija i komponovanja ovih problema. Neki problemi "presecaju" više apstrakcije u programu, i prkosi ovom obliku implementacije. Ovi problemi se nazivaju ukrštena zabrinutost ili horizontalna zabrinutost.

Prijavljivanje ilustruje poprečno sečenje zabrinutosti zato što strategija prijavljivanja nužno utiče na svaki prijavljeni deo sistema. Prijavljivanje na taj način preseca sve prijavljene klase i metode.

Sve AOP implementacije imaju neke prožimajuće izraze koji enkapsuliraju svaku zabrinutost na jednom mestu. Razlika između implementacije leži u moći, sigurnosti i upotrebljivosti konstrukcije predviđenih. Na primer, presretači koji uređuju način da presretnu izraze ograničenog oblika prožimajućeg, bez mnogo podrške tipa bezbednosti ili otklanjanja grešaka. AspektJ ima veliki broj takvih izraza i sažima ih u specijalno odeljenje, jedan aspekt. Na primer, jedan aspekt može promeniti ponašanje osnovnog koda (non-aspekt deo programa) primenom saveta (dodatna ponašanja) na različitim pridruženjem poena (tačaka u programu) navedenim u kvantifikaciji ili upitima koji se zovu "pointkat" (da detektuje da li je dati pridružiti tačka matches). Jedan aspekt takođe može da napravi binarne-kompatibilne strukturne promene na drugim klasama, kao dodavanje članova ili roditelja.

Istorija

AOP ima nekoliko direktnih prethodnice A1 i A2: refleksija i metaobjektni protokoli,  subjektno-orijentisano programiranje, sastav filtera i adaptivno programiranje.

Gregor Kiczales i njegove kolege u Xerox PARC su razvili eksplicitni koncept AOP, a zatim ovo sa AspektJ AOP proširenje na Javi. Istraživački tim IBM vodi pristup alata preko pristupa dizajna jezika i 2001. godine predložio je Hiper / J i zabrinutost manipulacije okruženja, koji nisu videli široku primenu. Primeri u ovom članku koriste aspektJ jer je najpoznatiji AOP jezik.

Microsoft Transaction Server se smatra da je prva velika primena AOP zatim Enterprise JavaBeans

Motivacija i osnovni pojmovi

Tipično, aspekt je rasut ili zamršen kao kod, što otežava da se razume i održi. Rasut je na osnovu funkcije (kao što je prijavljivanje) koja se prostire na velikom broju nepovezanih funkcija koje mogu da koriste svoju funkciju, verovatno u potpunosti nepovezanih sistema, različitim jezicima izvora, itd To znači da promenjeno prijavljivanje može zahtevati menjanje svih modula. Aspekti postaju zamršeni ne samo sa umerenim funkcijama sistema u kojima su izraženi nego i međusobno. To znači promena jedne brige podrazumeva razumevanje svih zamršenih zabrinutosti ili ima neka sredstva kojima se efekat promena može zaključiti.

Na primer, razmotrimo bankarsku aplikaciju sa konceptualno veoma jednostavnim načinom za prebacivanje u visini od jednog računa na drugi:

void transfer(Account fromAcc, Account toAcc, int amount) throws Exception {
  if (fromAcc.getBalance() < amount)
      throw new InsufficientFundsException();

  fromAcc.withdraw(amount);
  toAcc.deposit(amount);
}

Međutim, ovaj metod prenosa previđa određena razmatranja koje bi rasporedilo primenu zahteva: nedostaju bezbednosne provere da proverite da li sadašnji korisnik ima ovlašćenje za obavljanje ove operacije; transakcija (baze podataka) bi trebalo da obuhvati operaciju kako bi se sprečio slučajni gubitak podataka; za dijagnostiku, operacija treba biti prijavljena na evidenciju sistema, itd Verzija sa svim tim novim problemima, zbog primera, moga da donekle izgleda ovako:

void transfer(Account fromAcc, Account toAcc, int amount, User user,
    Logger logger, Database database) throws Exception {
  logger.info("Transferring money...");
  
  if (!isUserAuthorised(user, fromAcc)) {
    logger.info("User has no permission.");
    throw new UnauthorisedUserException();
  }
  
  if (fromAcc.getBalance() < amount) {
    logger.info("Insufficient funds.");
    throw new InsufficientFundsException();
  }

  fromAcc.withdraw(amount);
  toAcc.deposit(amount);

  database.commitChanges();  // Atomic operation.

  logger.info("Transaction successful.");
}

U ovom primeru drugi interesi su postali zamršeni sa osnovnim funkcijama (ponekad nazvana poslovna logika zabrinutosti). Transakcije, sigurnost, i prijavljivanje svih primerom ukrštene zabrinutosti.

Sada razmotrimo šta se dešava ako se iznenada treba promeniti (na primer) i sigurnosni aspekti za primenu. U trenutnoj verziji programa, operacije vezane za bezbednost izgledaju razbacano preko brojnih metoda, a takva promena će zahtevati velike napore.

AOP pokušava da reši ovaj problem tako što programer da izraze ukrštenih zabrinutosti u samostalnom modulu pod nazivom aspekti. Aspekti mogu sadržati savete (kod se pridružio određenoj tački u programu) i intertipove deklaracije (strukturni članovi se dodaju drugim klasama). Na primer, bezbednosni modul može uključivati savete koji obavljaju bezbednosnu proveru pre nego što pristupite bankovnom  računu."Pointkat" definiše vreme (pridruže poena) kada se može pristupiti bankovnom računu, a kod u uputstvu tela definiše kako se sprovodi provera bezbednosti. Dalje, dobar "pointkat" može da predvidi kasnije promene programa, tako da ako drugi programer kreira novi metod za pristup bankovnom računu, savet će se primenjivati na novom načinu kada izvršava.

Tako, na gornjem primeru sprovodi se prijavljivanje u pogledu:

aspect Logger {
  void Bank.transfer(Account fromAcc, Account toAcc, int amount, User user, Logger logger)  {
    logger.info("Transferring money...");
  }

  void Bank.getMoneyBack(User user, int transactionId, Logger logger)  {
    logger.info("User requested money back.");
  }

  // Other crosscutting code.
}

Jedino mogu da zamislim AOP kao alat za debagovanje ili kao korisnik oruđa na nivou. Saveti treba da budu rezervisani za slučajeve gde ne mogu da se funkcije menjaju (nivo korisnika) ili ne želite da promenite funkciju u proizvodnji koda (debagovanje).

Modeli pridružene tačke

Komponenta savet u vezi jednog aspekta orijentisanih jezika definiše se pridruživanjem tački modela (JPM). JPM definiše tri stvari:

1. Kada se savet može pokrenuti. To su pridruženi poeni jer su poenei u programu rada, gde dodatno ponašanje može biti korisno pridruženo. A pridružena tačka treba da bude adresibilna i shvatljiva običnom programeru da bude korisno. Takođe bi trebalo da bude stabilno preko nevažnih promena programa, kako bi jedan aspekt trebalo da bude stabilan  preko takvih promena. Mnoge AOP implementacije podržavaju metod pogubljenja i reference na terenu kao pridružena tačka.
2. Jedan od načina da odredite (ili količina) pridruživanje bodova, zove se "pointkat". Pointkat utvrđuje da li je dato pridruže tačke utakmice. Najkorisniji pointkat jezici koriste sintaksu kao osnovni jezik (na primer, AspektJ koristi Java potpisa) i omogućava ponovnu upotrebu kroz imenovanje i kombinacije. 
3. Sredstvo za navođenje koda da pokrene pridruživanje tačke. AspectJ zove ovaj savet, a mogu ga pokrenuti pre, posle i oko pridruživanja poena. Neke implementacije takođe podržavaju takve stvari koje definišu metod u pogledu na druge klase.

Tačka pridruživanja modela može se uporediti na osnovu pridružene izložene tačkež, kako se pridruže tačke su navedene, operacije dozvoljeno na pridruži poena, a strukturnih poboljšanja koja se može izraziti.

AspectJ pridružena tačka model

• Pridružene tačke  u aspektJ uključuju metod ili konstruktora poziva ili izvršenja, inicijalizacija klase ili objekta, polje čitaju i pišu pristup izuzetaka sirovina, itd Oni ne uključuju petlje, super pozive, klauzule, višestruke izjave, itd
• Tačke preseka su navedene kombinacijom primitivnih "pointkat" oznaka (PCD).

PCDS odgovara posebnoj vrsti pridruženih tačaka (npr izvršenja metoda) i ima tendenciju da se uđe u Javu kao potpis. Jedan takav "pointkat" izgleda ovako:

 execution(* set*(*))

Ako naziv metode počinje saсетi upravo tu je jedan argument bilo koje vrste.

"Dinamika" PCD  proverava runtime vrste i vezuje varijable. Na primer,

  this(Point)

Ovo sečenje odgovara kada trenutno izvršavanje objekta je  instanca klase Poen. Imajte na umu da nekvalifikovano ime klase može da se koristi preko Jave normalnog tipa pronalaženja.

Obim" PCDS ograničavaju leksički obim pridružene tačke. Na primer:

 within(com.company.*)

Ovo sečenje bilo kom pridruživanju u bilo kojoj vrsti u com.companypaketu.   * je jedan oblik džokerske oznake koje se mogu koristiti da odgovaraju mnogim stvarima sa jednim potpisom.

Tačka sečenja može biti sastavljena i imenovana za ponovnu upotrebu. Na primer:

pointcut set() : execution(* set*(*) ) && this(Point) && within(com.company.*);

Ovaj metod-izvršenja pridružeje tačku, ako  naziv metoda počinje sa "set" i this je instanca tipa Point u com.company paketu. Može se odnosi na upotrebu imena "set()".

• Savet navodi da radi na (pre, posle, ili oko) A Član tačke (određenog ) sigurnog koda (navedeno kao kod u metod). AOP Runtime poziva savet automatski kada pointkat odgovara tački da  se pridruži. Na primer:

after() : set() {
   Display.update();
}

To praktično određuje: "ako set() pointkat odgovara pridruženju tačke, pokrenite kodDisplay.update() nakon što je pridruže tački završenja."

Drugi potencijalni model pridruživanja tačke 

Postoje i druge vrste JPMs. Sve instrukcije jezika se mogu definisati u smislu njihovog JPM. Na primer, hipotetički jezik aspekt UML mogu imati sledeću JPM:

• Join tačke su svi elementi modela.
• Tačke sečenja su neki izrazi kombinujući elemente modela.
• Sredstva koja utiču na ove tačke su vizualizacija svih poklapanja da se pridruži tački.

Među-tipovi deklaracije

Među-tipovi deklaracije obezbeđuju način da se izrazi zabrinutost prožimajućeg uticanja na strukturu modula. Poznat i kao otvorena klasa i proširenja metoda, ovo omogućava programerima da se izjasne na jednom mestu ili članovima roditelja druge klase, obično u cilju kombinuju sve šifre koje su povezane sa brigom u jednom aspektu. Na primer, ako programer realizuje prožimajući ekran ažuriranja zabrinutosti koristeći posetilaca umesto toga, među-tipovi deklaracije koristeći obrazac posetilaca mogu izgledati ovako u aspektj:

  aspect DisplayUpdate {
    void Point.acceptVisitor(Visitor v) {
      v.visit(this);
    }
    // other crosscutting code...
  }

Ovaj fragment koda dodaje acceptVisitor metod Point klase.

To je uslov da svaka strukturna slika mora biti kompatibilna  sa originalnim klasama, tako da klijenti postojeće klase nastave da rade, osim ako primena za AOP može očekivati da kontroliše sve klijente u svakom trenutku.

Implementacija

AOP programi mogu uticati na druge programe na dva načina, u zavisnosti od osnovnih jezika i okruženja:

1. kombinovani program proizvoda, važi u originalnom jeziku i ne razlikuje se od običnog programa do krajnjeg prevodioca
2. krajnji tumač ili okruženje je ažurirano da razume i implementira AOP karakteristike.

Problem promene okruženja znači većina implementacija proizvesti kompatibilne kombinovane programe kroz proces poznat kao tkanje - poseban slučaj transformacije programa. Akpektni pregledač čita aspektno-orijentisane kodove i generiše odgovarajuće objektno-orijentisane kodove sa aspekta integrisanih. Isto AOP jezik može biti implementiran kroz razne metode tkanja, tako da semantiku jezika nikada ne treba shvatiti u smislu implementacije tkanja. Samo brzina načina sprovođenja i njegova lakoća razmeštanja su pogođeni koje metode kombinaciji se koriste.

Sistemi mogu implementirati izvor nivoa tkanja koristeći preprocesore (kao C ++ je prvobitno implementiran u frontu) koji zahtevaju pristup programu izvornih fajlova. Međutim, Java je dobro definisana binarnim oblikom koji omogućava bajtkod tkalje da radi sa bilo kojim Java programom u .class-file formi. Bajtkod tkanje može biti raspoređeno tokom procesa izrade ili, ako je tkanje model po-klasi, tokom utovara klase. AspektJ počeo sa izvora na nivou tkanja u 2001. godini, održao je po svojoj klasi bajtkod pregledač  2002. godine, i ponudio napredna opterećenja vremenu podršku nakon integracije AspectWerkz u 2005. godini.

Svako rešenje koje kombinuje programe na runtime mora da obezbedi stavove koji ih razdvajaju pravilno održavanjem programer je segregirani model. Bajtkod Javina podrška za više izvornih fajlova omogućava bilo koje otklanjanje grešaka na korak kroz pravilno pletene .klas u izvornom uredniku. Međutim, neki nezavisni kompajleri ne mogu da obrade tkani kod jer očekuju prukovanje koda od strane Javac. (vidi "problemi" ispod).

Primena vremena tkanja nudi drugačiji pristup. To u osnovi znači post-procesiranje, ali umesto krpljenja generisanih kodova, ovo tkanje pristupa podklasi postojeće klase tako da se  modifikacije uvode prema postupku-prevashodni. Postojeće klase ostaju netaknute, čak i na runtime, i svi postojeći alati (Debuggers, Profilers, itd) mogu da se koriste tokom razvoja. Sličan pristup već se dokazao u realizaciji mnogih Java EE aplikacija servera, kao što su IBM's WebSphere. 

Terminologija

Standardna terminologija koja se koristi u aspektu orijentisanog programiranja može uključivati:

Zabrinutost poprečnog izvršenja

Iako će većina časova u toku OO modela obavljati jednu, specifičnu funkciju, oni često dele zajedničke, sekundarne zahteve sa drugim klasama. Na primer, možemo želeti da dodamo evidentiranje na nastavu u okviru podataka pristupa sloja i da nastave u UI sloj kad god nit ulazi ili izlazi. Dalja zabrinutost može da se odnose na sigurnost, kao što su kontrola pristupa i kontrole protoka informacija. Iako svaka klasa ima veoma različitu osnovnu funkcionalnost, kod potreban za obavljanje sekundarne funkcionalnost je često identičan.

Saveti

Ovo je dodatni kod koji želite da primenite na vaš postojeći model. U našem primeru, to je kod izvršenja koji želimo da primenjujemo kad god nit ulazi ili izlazi. 

Tačka izvršenja

To je termin koji daje do tačke izvršenja u aplikaciji u kojoj poprečno sečenje briga treba da se primeni. U našem primeru, tačka izvršenja je dostignuta onda kada  nit ulazi u postupak, a drugi tačka izvršenja je dostignuta onda kada nit izlazi  . 

Aspekt

Kombinacija tačke izvršenja i savet je nazvao jedan aspekt. U gornjem primeru, dodamo evidentiranje aspekta našoj aplikaciji kroz definisanje tačke izvršenja i daje ispravan savet.

Poređenje sa drugim programskim paradigmama

Aspekti izašli iz objektno orijentisanog programiranja i računarskog razmišljanja. AOP jezici imaju funkcionalnost sličnu, ali više ograničenu nego metaobjekt protokola. Aspekti se odnose blisko sa programskim konceptima kao što su predmeti, mikins, i delegacija. Drugi načini da se koriste paradigme aspekt-orijentisanog programiranja  uključuje Filtere sastava i pristup hiper delovima. Od najmanje 1970, programeri su korišćenjem oblika presretanja i otpreme-šarom koje liče na neke od metoda implementacije za AOP, ali to nikada nije imalo semantiku da je krst specifikacije za sečenje pismene na jednom mestu.

Dizajneri su smatrali alternativne načine za postizanje odvajanja koda, kao što su delimične vrste u jeziku C#, ali takvi pristupi nemaju kvantitativni mehanizam koji omogućava dostizanje nekoliko pridruženih tačaka koda sa jednom deklarativnom izjavom.

Iako može izgledati nepovezano, u testiranju, upotreba ruga ili stuba zahteva upotrebu AOP tehnike, kao i oko saveta, i tako dalje. Ovde sarađuju objekti za potrebe testa, a poprečno sečenje zabrinutost. Tako su različiti Mok Objekti okviri pružanja ove funkcije. Na primer, proces se poziva na uslugu da se bilans iznosi. U testu procesa, gde iznos dolazi je nebitno, samo da proces koristi ravnotežu u skladu sa zahtevima. 

Usvajanje pitanja

Programeri treba da budu u stanju da pročitauj kod i razumeju šta se dešava u cilju sprečavanja greške. Čak i sa pravilnim obrazovanjem, razumevanje poprečne brige za sečenje može biti teško bez odgovarajuće podrške za vizuelizaciju kako statičke strukture tako i dinamičnog toka programa. Počevši od 2002. godine, AspektJ počeo je da obezbedđuje IDE dodatke za podršku vizuelizacije poprečnih zabrinutosti za sečenje.

S obzirom na moć AOP, ako programer čini logičnu grešku u izražavanju poprečnog sečenja, to može dovesti do široko rasprostranjenog programa neuspeha. Nasuprot tome, drugi programer može promeniti pridružene tačke u programu - na primer, preimenovanjem ili se kreće metode - na način koji aspekt pisac nije predvideo, sa nesagledivim posledicama. Jedna od prednosti modularizacije prožimajuće zabrinutosti omogućuje jedan programer da  lako utiče na ceo sistem; Kao rezultat toga, takvih problema sadašnjeg kao sukoba oko nadležnosti između dva ili više programera za dat neuspeh. Međutim, rešenje za ove probleme može biti mnogo lakše u prisustvu AOP, jer samo aspekt treba da se promeni, dok odgovarajući  problemi bez AOP mogu biti mnogo širi.

Kritika

Prvo, aspekt orijentisano programiranje je patentirano, i na taj način ne slobodno sprovodivo.

Najosnovnija kritika efekta AOP je da kontrola protoka je zaklopljena, i ne samo gorom nego mnogo osporavanom GOTO, ali je u stvari tesno analogno na šalu COME FROM izjave. Očiglednosti primene, koja je osnova za mnoge definicije AOP (kod u pitanju nema indikacija da će savet biti primenjen, koji je naveden), znači da savet nije vidljiv, za razliku od izričite metode poziva.  Na primer, uporedite dolaze iz programa:

 5 input x
10 print 'result is :'
15 print x

20 come from 10
25 x = x * x
30 return

sa AOP fragmentima sa analognom semantikom:

main() {
    input x
    print(result(x))
}
input result(int x) { return x }
around(int x): call(result(int)) && args(x) {
    int temp = proceed(x)
    return temp * temp
}

Zaista, razmak može zavisiti od runtime stanja i stoga ne bude statično deterministička. Ovo se može ublažiti, ali ne rešava statičke analize i IDE podršku projekcije koja savete potencijalno podudara.

Opšta kritika jeste da za AOP tvrdi da poboljša "kako modularnost i strukturu koda", ali neki brojač da potkopava ove ciljeve i onemogućava "nezavisan razvoj i razumljivost programa". Konkretno, kvantifikacija od pauze modularnosti: "mora, generalno, imati čitav-program znanja da rezonuju o dinamičnom izvršenju aspektno orijentisanog programa." Dalje, dok njeni ciljevi (modularnost ukrštenih zabrinutosti) su dobro razumeli, njegova stvarna definicija je nejasana i nije jasno kako se razlikuje od drugih dobro uspostavljenih tehnika. Zaista, aspekti mogu se prijaviti na sebi, što dovodi do problema kao što je paradoks lažov.

Tehnička kritika uključuje da je kvantitativni "pointkat" (definišu gde se izvršavaju saveti) je "izuzetno osetljiv na promene u programu", koji je poznat kao krhki problem. Problemi se smatraju tvrdoglavim: ako se zamenjuje kvantifikacija sa eksplicitnim napomenama, umesto jednog dobija atribut-orijentisano programiranje, što je jednostavno eksplicitan potprogram poziv i trpi identičan problem rasejanja koji za AOP je dizajniran da reši.

Implementacija

Sledeći programski jezici su sprovedeni za AOP, u jeziku, ili kao spoljna biblioteka:

• .NET Framework jezici (C# / VB.NET)
  • Unity, ona pruža API da omogući proverene prakse u ključnim oblastima programiranja, uključujući pristup podacima, bezbednosti, logovanju, izuzecima i drugima..
• ActionScript
• Ada
• AutoHotkey
• C / C++
• COBOL
•  Cocoa Objective-C frameworks
• ColdFusion
• Common Lisp
• Delphi
• Delphi Prism
• e (IEEE 1647)
• Emacs Lisp
• Groovy
• Haskell
• Java
  • AspectJ
• JavaScript
• Logtalk
• Lua
• make
• Matlab
• ML
• Perl
• PHP
• Prolog
• Python
• Racket
• Ruby
• Squeak Smalltalk
• UML 2.0
• XML

Vidi još

• Aspektno orijentisani softverski razvoj
• Funkcionalno programiranje
• Paradigme programiranja
• Uloga-orijentisano programiranje, alternativa Aspekt-orijentisanog programiranja
• Izvršni UML

Literatura

• Kiczales, G.; Lamping, J.; Mendhekar, A.; Maeda, C.; Lopes, C.; Loingtier, J. M.; Irwin, J. (1997). Aspect-oriented programming (PDF). ECOOP'97: Proceedings of the 11th European Conference on Object-Oriented Programming. LNCS. str. 220—242. ISBN 978-3-540-63089-0. doi:10.1007/BFb0053381. 
• Andreas Holzinger, M. Brugger, W. Slany (2011). Applying Aspect Oriented Programming (AOP) in Usability Engineering processes: On the example of Tracking Usage Information for Remote Usability Testing. Proceedings of the 8th International Conference on electronic Business and Telecommunications. Sevilla. D. A. Marca, B. Shishkov and M. v. Sinderen (editors). str. 53–56.
• Robert E. Filman, Tzilla Elrad, Siobhán Clarke and Mehmet Aksit . . Filman, Robert E. (2004). Aspect-Oriented Software Development. Addison-Wesley. ISBN 978-0-321-21976-3. 
• Renaud Pawlak, Lionel Seinturier and Jean-Philippe Retaillé . . Seinturier, Lionel; Pawlak, Renaud (2005). Foundations of AOP for J2EE Development. Apress. ISBN 978-1-59059-507-7. 
• Laddad, Ramnivas (2003). AspectJ in Action: Practical Aspect-Oriented Programming. Manning. ISBN 978-1-930110-93-9. 
• Jacobson, Ivar; Pan-Wei Ng . . Jacobson, Ivar; Ng, Pan-Wei (2005). Aspect-Oriented Software Development with Use Cases. Addison-Wesley. ISBN 978-0-321-26888-4. 
• Aspect-oriented Software Development and PHP, Dmitry Sheiko, 2006
• Siobhán Clarke and Elisa Baniassad . . Clarke, Siobhán; Baniassad, Elisa (2005). Aspect-Oriented Analysis and Design: The Theme Approach. Addison-Wesley. ISBN 978-0-321-24674-5. 
• Raghu Yedduladoddi (2009). Aspect Oriented Software Development: An Approach to Composing UML Design Models. ISBN 978-3-639-12084-4. 
• "Adaptive Object-Oriented Programming Using Graph-Based Customization" – Lieberherr, Silva-Lepe, et al. - 1994
• Zambrano Polo y La Borda, Arturo Federico (2013). Addressing aspect interactions in an industrial setting: Experiences, problems and solutions (Tesis). Universidad Nacional de La Plata. doi:10.35537/10915/35861. 

Spoljašnje veze

• Eric Bodden's list of AOP tools u .net framework
• Programming Styles: Procedural, OOP, and AOP
• Programming Forum: Procedural, OOP, and AOP Arhivirano na sajtu Wayback Machine (24. oktobar 2011)
• AOSD Wiki, Viki na razvoju softvera aspekto orijentisano
• AspectJ Programming Guide
• The AspectBench Compiler for AspectJ, druga realizacija Jave
• Series of IBM developerWorks articles on AOP
• A detailed series of articles on basics of aspect-oriented programming and AspectJ Arhivirano na sajtu Wayback Machine (26. jul 2013)
• What is Aspect-Oriented Programming?, upoznavanje sa RemObjects Taco
• Constraint-Specification Aspect Weaver
• Aspect- vs. Arhivirano na sajtu Wayback Machine (15. april 2021) Object-Oriented Programming: Which Technique, When? Arhivirano na sajtu Wayback Machine (15. april 2021)
• Aspect Oriented Programming in COBOL Arhivirano na sajtu Wayback Machine (17. decembar 2008)
• Aspect-Oriented Programming in Java with Spring Framework
• Wiki dedicated to AOP methods on.NET
• Early Aspects for Business Process Modeling (An Aspect Oriented Language for BPMN)
• Spring AOP and AspectJ Introduction
• AOSD Graduate Course at Bilkent University
• Aspect-Oriented programming for iOS and OS X by Manuel Gebele
• Java Method Logging with AOP and Annotations by Yegor Bugayenko
• DevExpress MVVM Framework. Introduction to POCO ViewModels