Aspekt-orienterad mjukvaruutveckling - Aspect-oriented software development

I computing , aspektorienterad programvaruutveckling (AOSD) är en mjukvaruutveckling teknik som söker nya modularizations av mjukvarusystem för att isolera sekundära eller stödfunktioner från huvudprogrammet är affärslogik . AOSD gör att flera problem kan uttryckas separat och automatiskt förenas i arbetssystem.

Traditionell mjukvaruutveckling fokuserar på nedbrytning av system till enheter med primär funktionalitet, samtidigt som man inser att det finns andra problem som inte passar bra in i den primära nedbrytningen. Den traditionella utvecklingsprocessen överlåter det till programmerarna att koda moduler som motsvarar den primära funktionaliteten och att se till att alla andra problem som berörs behandlas i koden där det är lämpligt. Programmerare måste komma ihåg alla saker som måste göras, hur man hanterar varje problem, problemen i samband med möjliga interaktioner och genomförandet av rätt beteende vid rätt tidpunkt. Dessa bekymmer spänner över flera primära funktionella enheter inom applikationen och resulterar ofta i allvarliga problem vid applikationsutveckling och underhåll. Distributionen av koden för att förverkliga ett problem blir särskilt kritisk eftersom kraven för det problemet utvecklas - en systemansvarig måste hitta och korrekt uppdatera en mängd olika situationer.

Aspektorienterad mjukvaruutveckling fokuserar på identifiering, specifikation och representation av tvärgående problem och deras modulering i separata funktionella enheter samt deras automatiserade sammansättning i ett fungerande system.

Historia

Aspekt-orienterad mjukvaruutveckling beskriver ett antal tillvägagångssätt för mjukvarumodularisering och komposition inklusive, i ordning för publicering, reflektion och metaobjektprotokoll , kompositionsfilter , utvecklade vid universitetet i Twente i Nederländerna, ämnesorienterad programmering (senare utökad som flerdimensionell separering of Concerns ) på IBM, Feature Oriented Programming vid University of Texas i Austin, Adaptive Programming vid Northeastern University , USA och Aspect-Oriented Programming (AOP) vid Palo Alto Research Center . Uttrycket "aspektorienterat" introducerades av Gregor Kiczales och hans team vid Palo Alto Research Center som också först utvecklade det uttryckliga konceptet AOP och AOP-språket som heter AspectJ, som har fått betydande acceptans och popularitet inom Java-utvecklargemenskapen.

För närvarande finns flera aspektorienterade programmeringsspråk tillgängliga för en mängd olika språk och plattformar.

Precis som objektorienterad programmering ledde till utvecklingen av en stor klass av objektorienterad utvecklingsmetodik , har AOP uppmuntrat en ny uppsättning programvaruteknik, inklusive metoder för att hantera aspekter, modelleringstekniker (ofta baserade på idéerna från Unified Modelleringsspråk , UML) och testteknik för att bedöma effektiviteten hos aspektmetoder. AOSD hänvisar nu till ett brett utbud av programvaruutvecklingstekniker som stöder modulering av tvärgående problem i ett mjukvarusystem, från kravteknik till affärsprocesshantering , analys och design , arkitektur , programmering och implementeringstekniker, testning och programvaruunderhållstekniker .

Aspektorienterad mjukvaruutveckling har ständigt blivit populärare och är föremål för en årlig konferens, den internationella konferensen om aspektorienterad mjukvaruutveckling, som hölls för första gången 2002 i Enschede, Nederländerna. AOSD är ett område i snabb utveckling. Det är ett populärt ämne inom Software Engineering- forskning, särskilt i Europa, där forskningsaktiviteter på AOSD samordnas av European Network of Excellence on Aspect-Oriented Software Development (AOSD-Europe), finansierat av EU-kommissionen.

Motivering

Övergripande oro

Figur 3 - Ett UML-arkitekturdiagram för en telekomkomponent

Den motivationen för aspektorienterad programmering närmar härrör från de problem som orsakas av koden spridning och trassel. Syftet med Aspect-Oriented Software Development är att tillhandahålla systematiska medel för att modulera tvärgående problem.

Implementeringen av ett problem sprids om dess kod sprids över flera moduler. Oron påverkar implementeringen av flera moduler. Dess genomförande är inte modulärt.

Implementeringen av ett problem är trassligt om dess kod blandas med kod som implementerar andra problem. Modulen där trassel inträffar är inte sammanhängande.

Spridning och trassel går ofta ihop, även om de är olika begrepp.

Aspekt-orienterad mjukvaruutveckling anser att kodspridning och trassling är symtomen på tvärgående problem. Övergripande problem kan inte moduleras med hjälp av språkens nedbrytningsmekanismer (objekt eller förfaranden) eftersom de i sig följer olika nedbrytningsregler. Implementeringen och integreringen av dessa problem med den primära funktionella nedbrytningen av systemet orsakar kodtrassel och spridning.

Exempel 1: Logga in i Apache Tomcat

Klasslastning i Tomcat är ett modulärt problem med avseende på systemnedbrytning. Dess genomförande ingår i ett litet antal klasser och är inte sammanflätat med genomförandet av andra problem.

Att logga in Tomcat är en tvärgående fråga. Dess implementering sprider sig över många klasser och paket och blandas med implementeringen av många andra problem.

Exempel 2: Koordinering av komponenter

Figur 3 representerar UML-arkitekturdiagrammet för en telekomkomponent. Varje ruta motsvarar en process som kommunicerar med andra processer via kontakter.

Exempel på tvärgående överväganden

Se tvärgående intresse # exempel .

Problem orsakade av spridning och trassel

Spridning och trasslande beteende är symptomen på att implementeringen av en oro inte är väl modulerad. En oro som inte är modulerad uppvisar inte ett väldefinierat gränssnitt. Samspelet mellan implementeringen av problemet och modulerna i systemet förklaras inte uttryckligen. De kodas implicit genom beroenden och interaktioner mellan kodfragment som implementerar oro och implementering av andra moduler.

Bristen på gränssnitt mellan implementeringen av tvärgående problem och implementeringen av systemets moduler hindrar utvecklingen, utvecklingen och underhållet av systemet.

Systemutveckling

En modul är främst en enhet för oberoende utveckling. Den kan implementeras till stor del oberoende av andra moduler. Modularitet uppnås genom definitionen av väldefinierade gränssnitt mellan systemets delar.

Bristen på uttryckliga gränssnitt mellan tvärgående problem och modulerna som erhålls genom funktionell sönderdelning av systemet innebär att implementeringen av dessa frågor, liksom ansvaret för korrekt implementering av dessa frågor, inte kan tilldelas oberoende utvecklingsteam. Detta ansvar måste delas mellan olika utvecklare som arbetar med att implementera olika moduler i systemet och måste integrera den övergripande frågan med modulbeteendet.

Dessutom är det svårt att återanvända moduler vars implementering är inblandad i tvärgående problem i olika sammanhang. Genomskärning hindrar återanvändning av komponenter. Bristen på gränssnitt mellan övergripande problem och andra moduler gör det svårt att representera och resonera om systemets övergripande arkitektur. Eftersom problemet inte är modulerat är det svårt att uttrycka interaktionen mellan systemet och de högsta komponenterna i systemet. Därför blir dessa problem svåra att resonera över eftersom beroendet mellan tvärgående problem och komponenter inte specificeras.

Slutligen är problem som inte är modulerade svåra att testa isolerat. Beroendeförhållandena för andra modulers beteende deklareras inte uttryckligen. Därför kräver implementeringen av enhetstest för sådana problem kunskap om implementeringen av många moduler i systemet.

Systemunderhåll och utveckling

Bristen på stöd för det modulära genomförandet av tvärgående problem är särskilt problematiskt när genomförandet av denna fråga behöver modifieras. Förståelsen av implementeringen av en tvärgående fråga kräver inspektion av implementeringen av alla moduler som den interagerar med. Därför kräver modifieringar av systemet som påverkar implementeringen av skärningsprocessen en manuell inspektion av alla platser i koden som är relevanta för skärningsprocessen. Systemunderhållet måste hitta och korrekt uppdatera en mängd olika dåligt identifierade situationer.

Översikt

Aspektorienteringens natur

Fokus för aspektorienterad mjukvaruutveckling ligger i utredningen och implementeringen av nya strukturer för mjukvarumodularitet som ger stöd för uttryckliga abstraktioner för att modulera problem. Aspektorienterade programmeringsmetoder ger uttryckliga abstraktioner för modulär implementering av problem i design, kod, dokumentation eller andra artefakter som utvecklats under programvarans livscykel. Dessa modulära problem kallas aspekter , och aspektorienterade tillvägagångssätt ger metoder för att komponera dem. Vissa tillvägagångssätt betecknar en grundläggande oro som bas. Olika tillvägagångssätt ger olika flexibilitet med avseende på sammansättningen av aspekter.

Kvantifiering och glömska

Den mest kända definitionen av AOSD: s natur beror på Filman och Friedman, som karaktäriserade AOSD med hjälp av ekvationen aspektorientering = kvantifiering + glömska .

AOP kan förstås som en önskan att göra kvantifierade uttalanden om programmens beteende, och att dessa kvantifieringar håller över program skrivna av ovetande programmerare.

AOP är önskan att göra uttalanden av formuläret: I program P, när villkor C uppstår, utför åtgärd A över ett konventionellt kodat program P.

Obliviousness innebär att ett program inte har någon kunskap om vilka aspekter som modifierar det var eller när, medan kvantifiering hänvisar till aspekternas förmåga att påverka flera punkter i programmet.

Begreppet icke-invasivitet föredras ofta framför begreppet glömska. Icke-invasivitet uttrycker att aspekter kan ge beteende till ett program utan att behöva utföra ändringar i det programmet, men det antar inte att program inte är medvetna om aspekterna.

Filmans definition av aspektorientering anses ofta vara alltför restriktiv. Många aspektorienterade tillvägagångssätt använder anteckningar för att uttryckligen förklara platserna i systemet där aspekter introducerar beteende. Dessa tillvägagångssätt kräver manuell inspektion och modifiering av andra moduler i systemet och är därför invasiva. Vidare kräver aspektorientering inte nödvändigtvis kvantifiering. Aspekter kan användas för att isolera funktioner vars implementering annars skulle trassla i andra funktioner. Sådana aspekter använder inte nödvändigtvis kvantifiering över flera platser i systemet.

Huvuddragen i Aspect-Oriented Software Development därför bättre kännetecknas i termer av modularitet genomförandet av kapnings oro, de abstraktioner som tillhandahålls av Aspect orienterade språk möjliggör modularisering och uttrycksfullhet av aspektorienterad sammansättning operatörer .

Begrepp och terminologi

Aspektorienterade tillvägagångssätt ger uttryckligt stöd för lokalisering av problem i separata moduler, så kallade aspekter. En aspekt är en modul som inkapslar ett problem. De flesta aspektorienterade språk stöder icke-invasiv införande av beteende i en kodbas och kvantifiering över punkter i programmet där detta beteende bör införas. Dessa poäng kallas kopplingspunkter .

Gå med i poängmodell

Kopplingspunkter är punkter i körningen av systemet, till exempel metodanrop, där beteende från aspekter kombineras. En kopplingspunkt är en punkt i genomförandet av programmet, som används för att definiera den dynamiska strukturen för ett tvärgående företag.

Kopplingspunktmodellen för ett aspektorienterat språk definierar de typer av kopplingspunkter som stöds av det aspektorienterade språket och möjliga interaktionspunkter mellan aspekter och basmoduler.

Den dynamiska tolkningen av kopplingspunkter gör det möjligt att exponera information om runtime, såsom den som ringer eller kallar en metod från en kopplingspunkt till en matchande genväg . Numera finns det olika kopplingspunktmodeller runt och ännu mer under utveckling. De är starkt beroende av det underliggande programmeringsspråket och AO-språket.

Exempel på kopplingspunkter är:

• metodkörning
• metodsamtal
• läs- och skrivåtkomst
• exekvering av undantagshanterare
• statisk och dynamisk initialisering

En kopplingspunkt för metodtäckning täcker åtgärderna för ett objekt som tar emot ett metodsamtal. Den innehåller alla åtgärder som komponerar ett metodanrop och börjar efter att alla argument utvärderats för att återvända.

Många AOP-tillvägagångssätt implementerar aspektbeteende genom att väva krokar i skuggor för anslutningspunkter, vilket är den statiska projiceringen av en kopplingspunkt på programkoden.

Figur 6 illustrerar möjliga kopplingspunkter i utförandet av ett litet objektorienterat program. De markerade kopplingspunkterna inkluderar körningen av metod moveBy (int, int) på ett Line- objekt, samtalen till metoder moveBy (int, int) på Point- objekten i kontext för Line- objektet, körningen av dessa metoder i sammanhanget av Point föremål och de samtal och exekvering av sattX (int) och setY (INT) metoder.

Pointcut-beteckningar

Kvantifieringen över kopplingspunkter uttrycks på språknivå. Denna kvantifiering kan vara implicit i språkstrukturen eller kan uttryckas med hjälp av en frågeliknande konstruktion som kallas en genväg. Punktskärningar definieras som ett predikat över programmets syntaxträd och definierar ett gränssnitt som begränsar vilka element i basprogrammet som exponeras av pekskärmen. En punktskärning plockar ut vissa kopplingspunkter och värden vid dessa punkter. Den syntaktiska formuleringen av en pekskärm varierar från tillvägagångssätt till tillvägagångssätt, men en pekskärm kan ofta komponeras av andra genvägar med de booleska operatorerna AND, OR och NOT. Punktuttryck kan kortfattat fånga ett brett spektrum av intressanta händelser med jokertecken. Till exempel, i AspectJ- syntax, flytta genväg

pointcut move: call(public * Figure.* (..))

väljer ut varje samtal till Figurs offentliga metoder.

cflow poincuts identifierar kopplingspunkter baserat på om de förekommer i det dynamiska sammanhanget för andra kopplingspunkter. Till exempel i AspectJ cflow(move()) plockar syntax ut varje kopplingspunkt som uppstår i det dynamiska sammanhanget för de kopplingspunkter som plockats ut genom flyttpunktsgenvägen.

Pointcuts kan klassificeras i två kategorier:

• Sorterade genvägar, till exempel anropsgenvägen, matchar en typ av kopplingspunkt med hjälp av en signatur.
• Icke-slagna genvägar, som cflow-genvägen, matchar alla typer av kopplingspunkter med en mängd olika egenskaper.

Rådgivningsorgan

En rådgivare är kod som körs när en kopplingspunkt uppnås. Råd modulerar de funktionella detaljerna i ett problem. Den ordning i vilken rådgivningsorganen som bidragits av aspekter (och av basen) kan kontrolleras på olika sätt, inklusive:

• när en kopplingspunkt uppnås innan körningen fortsätter med basen
• efter bassemantiken för kopplingspunkten. När kopplingspunkten motsvarar exekveringen av en metod kan en efterråd utföras efter att metoden har returnerats eller efter att ett undantag har höjts
• när kopplingspunkten uppnås, med uttrycklig kontroll över om bassemantiken körs. Runt råd kan ändra kontrollflödet för programmet.

Mer generella sätt att beskriva beställning av rådgivningsorgan i form av delordningsdiagram har också tillhandahållits.

När körningen av en kopplingspunkt uppfyller ett punktuttryck, körs basen och rådkoden som är associerad med kopplingspunkten. Rådgivningen kan interagera med viloprogrammet genom en kopplingspunktinstans som innehåller reflekterande information om sammanhanget för händelsen som utlöste rådet, såsom argumenten för ett metodanrop eller målinstansen för ett samtal.

Inter-typdeklarationer

Inter-typdeklarationer tillåter programmeraren att ändra ett programs statiska struktur, till exempel klassmedlemmar och klasshierarki. Nya medlemmar kan infogas och klasser kan tryckas ner i klasshierarkin.

Aspekter

En aspekt är en modul som inkapslar ett problem. En aspekt består av punkter, rådgivningsorgan och inter-typdeklarationer. I vissa tillvägagångssätt kan en aspekt också innehålla klasser och metoder.

Aspekt vävning

Aspektvävning är en kompositionsmekanism som koordinerar aspekter med de andra modulerna i systemet. Det utförs av en specialiserad kompilator, kallad aspektvävare .

Exempel

Figur 6 - Figurredigerare i UML

Figur 7 - Bildorienterad bildredigerare i UML

Figur 6 illustrerar ett klassiskt exempel på ett tvärsnittsproblem i ett figurredigerareexempel hämtat från AOSD-litteraturen. Exemplet beskriver en abstrakt formklass som kan flyttas i redigeraren. När en form flyttas måste skärmen uppdateras. Figur 6 visar också två Shape-underklasser, Line och Point som implementerar Shape-funktionaliteten. Skärmens uppdateringsproblem är spridda över implementeringen av båda underklasserna. Figur 7 representerar en aspektorienterad implementering av samma system, där en aspekt inkapslar skärmuppdateringsfunktionaliteten.

Flyttpunktsbeskrivaren i figur 7 fångar alla körningar av flyttningen Med hjälp av metoder för en underklass av form och åberopar funktionen för uppdatering av skärmen efter körningen. Bekymringen är modulerad, vilket gör det lättare att utvecklas och underhålla.

Aspektorienterad kravteknik

Aspektorienterad kravet engineering (även hänvisad till som "Tidiga Aspects") fokuserar på identifiering, specifikation och representation av kapning egenskaper vid kravet nivå. Exempel på sådana egenskaper inkluderar säkerhet , rörlighet, tillgänglighet och begränsningar i realtid . Korsningsegenskaper är krav, användningsfall eller funktioner som har en omfattande effekt på andra krav eller arkitekturkomponenter .

Aspektorienterade kravtekniska tillvägagångssätt är tekniker som uttryckligen erkänner vikten av att tydligt ta itu med både funktionella och icke-funktionella tvärgående förutom för icke-tvärgående. Därför fokuserar dessa tillvägagångssätt på att systematiskt och modulärt behandla, resonera om, komponera och därefter spåra tvärsnittsfunktionella och icke-funktionella problem via lämpliga abstraktions- , representations- och kompositionsmekanismer anpassade till kravteknikområdet.

Specifika kompetensområden under nämnaren för AO-kravanalys är:

• den aspektorienterade kravprocessen,
• aspektinriktade kravnoteringar,
• aspekt-orienterade krav verktygsstöd,
• antagande och integration av aspektering av kravteknik, och
• bedömning / utvärdering av aspektinriktade krav.

Aspektorienterad affärsprocesshantering (AOBPM)

Att minska komplexiteten är en viktig fråga inom BPM-området (Business Process Management). En källa till komplexitet är rotad i de många olika problem som en affärsprocess tar upp, såsom säkerhet och integritet. Helst bör dessa problem definieras separat från affärsprocesserna, eftersom de vanligtvis spänner över flera processer, och de kan komma att ändras på en allmän organisationsnivå istället för en specifik processnivå. Nuvarande affärsprocesshanteringssystem stöder dock inte denna typ av modellering.

Aspektorienterad affärsprocesshantering (AOBPM) försöker stödja separering av tvärgående problem från kärnverksamheten. Den definierar en uppsättning krav och en formell modell. Denna modell är designad med Colored Petri Nets (CPN).

Metoden implementeras som en tjänst i YAWL baserat på Service Oriented Architecture .

Bedömningsresultatet av nuvarande aspektorienterade affärsprocesshanteringsmetoder definieras utifrån fem dimensioner, såsom Signaturexposure, Rule Composition, Advice Relations, Transformation Patterns, and Phases Support. Resultatet kan ses i följande bild.

Aspektorienterad systemarkitektur

Aspektorienterad systemarkitektur fokuserar på lokalisering och specifikation av tvärgående problem i arkitektoniska mönster. Övergripande oro som visas på arkitektonisk nivå kan inte moduleras genom att omdefiniera programvaruarkitekturen med konventionella arkitektoniska abstraktioner. Aspektorienterade systemarkitekturspråk föreslår uttryckliga mekanismer för att identifiera, specificera och utvärdera aspekter på arkitekturdesignnivå.

Aspektorienterad arkitektur börjar med observationen att vi behöver identifiera, specificera och utvärdera aspekter uttryckligen på arkitekturdesignnivå. Aspektuella arkitekturmetoder beskriver steg för att identifiera arkitektoniska aspekter. Denna information används för att omforma en viss arkitektur där de arkitektoniska aspekterna uttryckas. I detta avseende är specifika kompetensområden:

• själva den aspektorienterade arkitekturprocessen,
• de aspektorienterade arkitekturnotationerna,
• aspektorienterat stöd för arkitekturverktyg,
• antagande och integration av aspektorienterad arkitektur, och
• bedömning / utvärdering av aspektorienterad arkitektur.

Aspektorienterad modellering och design

Aspektorienterad design har samma mål som alla programvaru-designaktiviteter, dvs att karakterisera och specificera programvarusystemets beteende och struktur. Dess unika bidrag till programvarudesign ligger i det faktum att problem som nödvändigtvis är spridda och trassliga i mer traditionella metoder kan moduleras. Vanligtvis inkluderar en sådan metod både en process och ett språk. Processen tar som inputkrav och producerar en designmodell. Den producerade designmodellen representerar separata problem och deras relationer. Språket tillhandahåller konstruktioner som kan beskriva de element som ska representeras i designen och relationerna som kan finnas mellan dessa element. I synnerhet tillhandahålls konstruktioner för att stödja orosmodularisering och specifikationen av orossammansättning, med hänsyn till konflikter. Utöver detta jämförs designen för varje enskild modulerad verksamhet med standardprogramvarudesign.

Här är specifika områden för spetskompetens:

• själva den aspektorienterade designprocessen,
• de aspektorienterade designnotationerna,
• aspektorienterat designverktygsstöd,
• antagande och integration av aspektorienterad design, och
• bedömning / utvärdering av aspektorienterad design.

Aspektorienterad programmering (AOP)

AOP inkluderar programmeringstekniker och verktyg som stöder modularisering av problem på nivå med källkoden.

Precis som alla andra programmeringsspråk består ett aspektorienterat språk vanligtvis av två delar: en språkspecifikation och en implementering. Därför finns det två motsvarande problemområden: stöd för språkutvecklare och stöd för applikationsutvecklare.

Stöd för applikationsutvecklare

Ett aspektorienterat tillvägagångssätt stöder implementeringen av problem och hur man komponerar dessa oberoende implementerade problem. Medan specifikationen av ett sådant språk är den primära manualen för applikationsutvecklare, ger det uppenbarligen ingen garanti för att applikationsutvecklaren kommer att producera högkvalitativa aspektinriktade program. Specifika kompetensområden:

• de avgörande begreppen aspektorienterad programmering,
• programmering på aspektorienterade språk,
• komponera programvarukomponenter skrivna på vilket språk som helst med hjälp av aspektorienterade kompositionsmekanismer, eller
• aspektorienterade programmeringsmiljöer.

Stöd för språkutvecklare

Kompetens inom konstruktion av aspektorienterade språk inkluderar följande områden:

• konstruera språk eller DSL: er för specifika domäner och / eller plattformar, och
• överföra implementeringsprinciper från andra aspektorienterade exekveringsmiljöer, inklusive:
  • tolkar,
  • kompilatorer och
  • virtuella maskiner.

Formellt metodstöd för aspektorientering

Formella metoder kan användas både för att definiera aspekter semantiskt och för att analysera och verifiera aspektorienterade system. Aspektorienterad programmering utökar programmeringsnoteringar med aspektmoduler som isolerar deklarationen om när aspekten ska tillämpas (kopplingspunkter) och vilka åtgärder som ska vidtas när den nås (råd). Expertis i formella semantiska definitioner av aspektkonstruktioner är användbar för språkdesigners för att ge en djup förståelse för skillnaderna mellan konstruktioner. Aspekter kan potentiellt skada tillförlitligheten hos ett system som de är vävda till och kan ogiltigförklara väsentliga egenskaper som redan var sanna för systemet utan aspekten. Det är också nödvändigt att visa att de faktiskt lägger till avsedda korsningsegenskaper i systemet. Därför tas många frågor om korrekthet och verifiering upp med aspekt-språk. Bland de sakkunniga är:

• specialdesignade testtekniker för att ge täckning för aspekter,
• programskärning och kodanalysmetoder för att identifiera interaktioner mellan aspekter och mellan aspekter och underliggande system,
• modelleringstekniker specialiserade för aspekter, och
• induktiva tekniker för att verifiera aspektorienterade system.

Var och en av ovanstående tillvägagångssätt kan användas för att:

• specificera och analysera enskilda aspekter i förhållande till ett befintligt system,
• definiera villkor för att komponera flera aspekter korrekt, och
• upptäcka och lösa potentiella störningar mellan aspekter.

Även om vissa tillvägagångssätt redan används i olika språk är andra fortfarande föremål för forskning och är inte redo för rutinmässig industriell tillämpning. Ändå är medvetenhet om dessa frågor avgörande för språkdesigners och för effektiv användning av aspekter, särskilt i säkerhetskritiska sammanhang.

Aspekt-orienterad mellanvara

Middleware och AOSD kompletterar varandra starkt. I allmänhet består kompetensområden av:

• stöd för applikationsutvecklaren, som inkluderar
  • de avgörande begreppen för aspekt som stöder middleware
  • aspektorienterad mjukvaruutveckling med hjälp av en specifik middleware, som involverar aspektprogrammeringsmodellen, aspektdistributionsmodellen, plattformsinfrastruktur och tjänster för middleware
• Produktfamiljteknik (metoder, arkitekturer, tekniker) inom distribuerad och omgivande beräkning och
• stöd för middleware-utvecklaren med avseende på
  • värdinfrastruktur mellanprogram,
  • distribution mellanvara,
  • vanliga mellanvarutjänster och
  • domänspecifika mellanvarutjänster.

Adoption

• IBM WebSphere Application Server (WAS) är en Java-applikationsserver som stöder Java EE och Web Services. Websphere distribueras enligt utgåvor som stöder olika funktioner. Websphere använder AspectJ internt för att isolera funktioner i de olika utgåvorna.
• JBoss Application Server (JBoss AS) är en gratis Java-applikationsserver med öppen källkod som stöder Java EE. Kärnan i JBoss AS är integrerad med JBoss AOP aspektinriktade programmeringsspråk. Applikationsservern använder JBoss AOP för att distribuera tjänster som säkerhet och transaktionshantering.
• Oracle TopLink är ett Java-objekt-till-relation-uthållighetsramverk som är integrerat med Spring Application Server. TopLink uppnår höga nivåer av uthållighetstransparens med Spring AOP.
• SAV
• Sun Microsystems använder AspectJ för att effektivisera utvecklingen av mobilapplikationer för Java ME-plattformen. Aspekter används för att förenkla utvecklingen av mobilapplikationer för distribution till olika operatörsdäck och olika mobila spelgränssnitt.
• Siemens Soarian är ett system för hantering av hälsoinformation som stöder sömlös tillgång till patientjournaler och definitionen av arbetsflöden för vårdorganisationer. Soarian använder AspectJ för att integrera tvärgående funktioner som spårning, granskning och prestandaövervakning i samband med en smidig utvecklingsprocess.
• Motorola wi4 är ett mobilinfrastruktursystem som ger stöd för WiMAX trådlöst bredbandsstandard. Wi4-styrprogramvaran är utvecklad med hjälp av en aspektorienterad förlängning av UML 2.0-standarden som heter WEAVR. WEAVR används under utvecklingen för felsökning och teständamål.
• ASML är en leverantör av litografisystem för halvledarindustrin. ASML använder en aspektorienterad förlängning till C som heter Mirjam för att modulera spårning och profilering.
• Glassbox är ett felsökningsagent för Java-applikationer som automatiskt diagnostiserar vanliga problem. Glassbox-inspektören övervakar aktiviteten på den virtuella Java-maskinen med AspectJ.
• .NET 3.5 stöder Aspect Oriented-koncept genom Unity-behållaren.

Fotnoter

Referenser

• Kiczales, G .; Lamping, J .; Mendhekar, A .; Maeda, C .; Lopes, C .; Loingtier, JM; Irwin, J. (1997). Aspektorienterad programmering (PDF) . ECOOP '97. Proceedings of the 11th European Conference on Object-Oriented Programming . LNCS . 1241 . s. 220–242. CiteSeerX   10.1.1.115.8660 . doi : 10.1007 / BFb0053381 . ISBN   3-540-63089-9 .
• Murphy, GC, RJ Walker, ELA Baniassad, MP Robillard, A. Lai, MA Kersten (2001): Fungerar aspektorienterad programmering ?, i: Kommunikation av ACM, oktober 2001, Vol. 44, nr 10, 75-77
• Tarr, P., H. Ossher, W. Harrison, SM Sutton Jr. (1999): N Degrees of Separation: Multi-Dimensional Separation of Concerns, in: Proceedings of the 21st International Conference on Software Engineering (ICSE 1999), Los Angeles, Kalifornien, USA, IEEE Computer Society Press, 107-119
• Wijesuriya, Viraj Brian (2016-08-30) Aspect Oriented Development, Lecture Notes, University of Colombo School of Computing, Sri Lanka

externa länkar

• Aspect-Oriented Software Development Community and Conference