Aspektorienteret softwareudvikling - Aspect-oriented software development

I computing er aspektorienteret softwareudvikling (AOSD) en softwareudviklingsteknologi, der søger nye modulariseringer af softwaresystemer for at isolere sekundære eller understøttende funktioner fra hovedprogrammets forretningslogik . AOSD tillader, at flere bekymringer udtrykkes separat og automatisk forenes i arbejdssystemer.

Traditionel softwareudvikling fokuserer på nedbrydning af systemer til enheder med primær funktionalitet, samtidig med at man erkender, at der er andre problemer, der bekymrer sig, der ikke passer godt ind i den primære nedbrydning. Den traditionelle udviklingsproces overlader det til programmørerne at kode moduler, der svarer til den primære funktionalitet, og at sikre, at alle andre problemer, der bekymrer sig, behandles i koden, hvor det er relevant. Programmører skal huske på alle de ting, der skal gøres, hvordan man håndterer hvert problem, de problemer, der er forbundet med de mulige interaktioner, og udførelsen af ​​den rigtige adfærd på det rigtige tidspunkt. Disse bekymringer spænder over flere primære funktionelle enheder i applikationen og resulterer ofte i alvorlige problemer under applikationsudvikling og vedligeholdelse. Distributionen af ​​koden til at realisere en bekymring bliver især kritisk, da kravene til den pågældende sag udvikler sig - en systemholder skal finde og korrekt opdatere en række forskellige situationer.

Aspektorienteret softwareudvikling fokuserer på identifikation, specifikation og repræsentation af tværgående bekymringer og deres modularisering i separate funktionelle enheder såvel som deres automatiserede sammensætning i et fungerende system.

Historie

Aspektorienteret softwareudvikling beskriver en række tilgange til softwaremodularisering og -sammensætning, herunder i rækkefølge efter offentliggørelse, refleksion og metaobjektprotokoller , Composition Filters , udviklet ved University of Twente i Holland, Emneorienteret programmering (senere udvidet som flerdimensionel separering of Concerns ) hos IBM, Feature Oriented Programming ved University of Texas i Austin, Adaptive Programming ved Northeastern University , USA og Aspect-Oriented Programming (AOP) ved Palo Alto Research Center . Udtrykket "aspektorienteret" blev introduceret af Gregor Kiczales og hans team på Palo Alto Research Center, som også først udviklede det eksplicitte koncept AOP og AOP-sproget kaldet AspectJ, som har fået betydelig accept og popularitet inden for Java-udviklerfællesskabet.

I øjeblikket er flere aspektorienterede programmeringssprog tilgængelige for en række sprog og platforme.

Ligesom objektorienteret programmering førte til udviklingen af ​​en stor klasse af objektorienterede udviklingsmetoder , har AOP tilskyndet et spirende sæt software engineering-teknologier, herunder metoder til at håndtere aspekter, modelleringsteknikker (ofte baseret på ideerne fra det samlede Modelleringssprog , UML) og testteknologi til vurdering af effektiviteten af ​​aspekttilgange. AOSD henviser nu til en bred vifte af softwareudviklingsteknikker, der understøtter modularisering af tværgående bekymringer i et softwaresystem, fra kravsteknologi til styring af forretningsprocesser , analyse og design , arkitektur , programmering og implementeringsteknikker, test og vedligeholdelsesteknikker til software .

Aspektorienteret softwareudvikling er konstant blevet mere populær og er genstand for en årlig konference, den internationale konference om aspektorienteret softwareudvikling, der blev afholdt for første gang i 2002 i Enschede, Holland. AOSD er et område i hurtig udvikling. Det er et populært emne inden for softwareingeniørforskning , især i Europa, hvor forskningsaktiviteter på AOSD koordineres af det europæiske netværk af ekspertise inden for aspektorienteret softwareudvikling (AOSD-Europe), finansieret af Europa-Kommissionen.

Motivering

Tværgående bekymringer

Figur 3 - Et UML-arkitekturdiagram for en telekomponent

Den motivation for aspektorienteret programmering tilgange stammer fra de problemer, som kode spredning og sammenfiltring. Formålet med Aspect-Oriented Software Development er at tilvejebringe systematiske midler til at modulere tværgående bekymringer.

Implementeringen af ​​en bekymring er spredt, hvis dens kode er spredt over flere moduler. Bekymringen påvirker implementeringen af ​​flere moduler. Dens implementering er ikke modulopbygget.

Implementeringen af ​​en bekymring er sammenfiltret, hvis dens kode blandes med kode, der implementerer andre bekymringer. Modulet, hvor sammenfiltring forekommer, er ikke sammenhængende.

Spredning og sammenfiltring går ofte sammen, selvom de er forskellige begreber.

Aspektorienteret softwareudvikling mener, at kodespredning og sammenfiltring er symptomerne på tværgående bekymringer. Tværgående bekymringer kan ikke moduleres ved hjælp af sprogets spaltningsmekanismer (objekt eller procedurer), fordi de iboende følger forskellige nedbrydningsregler. Implementeringen og integrationen af ​​disse bekymringer med den primære funktionelle nedbrydning af systemet forårsager kodefilter og spredning.

Eksempel 1: Logning på Apache Tomcat

Classloading i Tomcat er et modulopbygget problem med hensyn til systemnedbrydning. Dens gennemførelse er indeholdt i et lille antal klasser og er ikke sammenflettet med implementeringen af ​​andre bekymringer.

Logning på Tomcat er en tværgående bekymring. Dens implementering spredes over mange klasser og pakker og blandes med implementeringen af ​​mange andre bekymringer.

Eksempel 2: Koordinering af komponenter

Figur 3 repræsenterer UML-arkitekturdiagrammet for en telekomponent. Hver boks svarer til en proces, der kommunikerer med andre processer gennem stik.

Eksempler på tværgående bekymringer

Se tværgående bekymring # eksempler .

Problemer forårsaget af spredning og sammenfiltring

Spredning og sammenfiltring af adfærd er symptomerne på, at implementeringen af ​​en bekymring ikke er godt moduleret. En bekymring, der ikke er moduleret, udviser ikke en veldefineret grænseflade. Samspillet mellem implementeringen af ​​bekymringen og modulerne i systemet erklæres ikke eksplicit. De er kodet implicit gennem afhængigheder og interaktioner mellem fragmenter af kode, der implementerer bekymring og implementering af andre moduler.

Manglen på grænseflader mellem implementeringen af ​​tværgående bekymringer og implementeringen af ​​systemets moduler hindrer udviklingen, udviklingen og vedligeholdelsen af ​​systemet.

Systemudvikling

Et modul er primært en enhed for uafhængig udvikling. Det kan implementeres i høj grad uafhængigt af andre moduler. Modularitet opnås gennem definitionen af ​​veldefinerede grænseflader mellem systemets segmenter.

Manglen på eksplicitte grænseflader mellem tværgående bekymringer og modulerne opnået ved funktionel nedbrydning af systemet indebærer, at implementeringen af ​​disse bekymringer såvel som ansvaret for den korrekte implementering af disse problemer ikke kan tildeles uafhængige udviklingsteams. Dette ansvar skal deles mellem forskellige udviklere, der arbejder på implementeringen af ​​forskellige moduler i systemet og er nødt til at integrere den tværgående bekymring med modulets adfærd.

Desuden er moduler, hvis implementering er sammenflettet med tværgående bekymringer, vanskelige at genbruge i forskellige sammenhænge. Krydsning hindrer genbrug af komponenter. Manglen på grænseflader mellem tværgående bekymringer og andre moduler gør det svært at repræsentere og argumentere for et systems overordnede arkitektur. Da bekymringen ikke er moduleret, er interaktionerne mellem bekymringen og systemets topkomponenter vanskelige at repræsentere eksplicit. Derfor bliver disse bekymringer svære at begrunde, fordi afhængigheden mellem tværgående bekymringer og komponenter ikke er specificeret.

Endelig er bekymringer, der ikke moduleres, vanskelige at teste isoleret. Afhængigheden af ​​bekymringen med hensyn til andre modulers opførsel erklæres ikke eksplicit. Derfor kræver implementeringen af ​​enhedstest for sådanne bekymringer viden om implementeringen af ​​mange moduler i systemet.

Systemvedligeholdelse og udvikling

Manglen på støtte til den modulære implementering af tværgående bekymringer er især problematisk, når implementeringen af ​​denne bekymring skal ændres. Forståelsen af ​​implementeringen af ​​et tværgående problem kræver inspektion af implementeringen af ​​alle de moduler, som det interagerer med. Derfor kræver ændringer af systemet, der påvirker implementeringen af ​​krydsoverskæringsproblemet, en manuel inspektion af alle de placeringer i koden, der er relevante for krydsoverskæringsproblemet. Systemholderen skal finde og korrekt opdatere en række dårligt identificerede situationer.

Oversigt

Aspektorienteringens art

Fokus for aspektorienteret softwareudvikling er i efterforskningen og implementeringen af ​​nye strukturer til softwaremodularitet, der yder støtte til eksplicit abstraktion for at modulere bekymringer. Aspektorienterede programmeringsmetoder giver eksplicitte abstraktioner til den modulære implementering af bekymringer i design, kode, dokumentation eller andre artefakter, der er udviklet under softwarelevecyklussen. Disse modulariserede bekymringer kaldes aspekter , og aspektorienterede tilgange giver metoder til at komponere dem. Nogle tilgange betegner en grundlæggende bekymring som basen. Forskellige tilgange giver forskellig fleksibilitet med hensyn til sammensætningen af ​​aspekter.

Kvantificering og glemsomhed

Den bedst kendte definition af AOSD's natur skyldes Filman og Friedman, som karakteriserede AOSD ved hjælp af ligningens aspektorientering = kvantificering + glemsomhed .

AOP kan forstås som ønsket om at afgive kvantificerede udsagn om programmernes adfærd og at få disse kvantificeringer til at holdes over programmer skrevet af uvidende programmerere.

AOP er ønsket om at fremsætte erklæringer af formularen: I program P, når betingelse C opstår, skal du udføre handling A over et konventionelt kodet program P.

Glemsomhed indebærer, at et program ikke har nogen viden om, hvilke aspekter der ændrer det hvor eller hvornår, mens kvantificering henviser til aspekternes evne til at påvirke flere punkter i programmet.

Begrebet ikke-invasivitet foretrækkes ofte frem for udtrykket glemsomhed. Ikke-invasivitet udtrykker, at aspekter kan tilføje adfærd til et program uden at skulle udføre ændringer i dette program, men alligevel antager det ikke, at programmer ikke er opmærksomme på aspekterne.

Filmans definition af aspektorientering betragtes ofte som for restriktiv. Mange aspektorienterede tilgange bruger annoteringer til eksplicit at erklære de placeringer i systemet, hvor aspekter introducerer adfærd. Disse fremgangsmåder kræver manuel inspektion og ændring af andre moduler i systemet og er derfor invasive. Desuden kræver aspektorientering ikke nødvendigvis kvantificering. Aspekter kan bruges til at isolere funktioner, hvis implementering ellers ville være sammenflettet med andre funktioner. Sådanne aspekter bruger ikke nødvendigvis kvantificering over flere placeringer i systemet.

De væsentlige elementer i Aspect-Oriented Software Development er derfor bedre karakteriseret med hensyn til modularitet af gennemførelsen af tværgående bekymringer, at de abstraktioner, som aspekt-orienterede sprog muliggøre modularisering og udtryksfuldhed af det aspekt-orienterede sammensætning operatører .

Begreber og terminologi

Aspektorienterede tilgange giver eksplicit støtte til lokalisering af bekymringer i adskilte moduler, kaldet aspekter. Et aspekt er et modul, der indkapsler en bekymring. De fleste aspektorienterede sprog understøtter den ikke-invasive introduktion af adfærd i en kodebase og kvantificering over punkter i programmet, hvor denne adfærd skal introduceres. Disse punkter kaldes sammenføjningspunkter .

Deltag i punktmodel

Forbindelsespunkter er punkter i udførelsen af ​​systemet, såsom metodekald, hvor adfærd leveret af aspekter kombineres. Et sammenkoblingspunkt er et punkt i udførelsen af ​​programmet, som bruges til at definere den dynamiske struktur for en tværgående virksomhed.

Samlingspunktmodellen for et aspektorienteret sprog definerer de typer tilslutningspunkter, der understøttes af det aspektorienterede sprog, og de mulige interaktionspunkter mellem aspekter og basismoduler.

Den dynamiske fortolkning af sammenføjningspunkter gør det muligt at eksponere kørselsinformation, såsom en opkalds eller opkald af en metode fra et sammenkoblingspunkt til en matchende genvej . I dag er der forskellige sammenkoblingsmodeller rundt og stadig mere under udvikling. De afhænger stærkt af det underliggende programmeringssprog og AO-sprog.

Eksempler på sammenføjningspunkter er:

• metodeudførelse
• metodeopkald
• adgang til feltlæsning og skrivning
• undtagelse handler udførelse
• statisk og dynamisk initialisering

Et metodeopkaldspunkter dækker handlingerne for et objekt, der modtager et metodekald. Det inkluderer alle de handlinger, der sammensætter et metodekald, startende, når alle argumenter er evalueret for at vende tilbage.

Mange AOP-tilgange implementerer aspektadfærd ved at væve kroge ind i sammenføjningsskygger, hvilket er den statiske projektion af et sammenføjningspunkt på programkoden.

Figur 6 illustrerer mulige sammenføjningspunkter i udførelsen af ​​et lille objektorienteret program. De fremhævede slutte punkter omfatter udførelse af metoden moveBy (int, int) på en linje objekt, opkald til metoder moveBy (int, int) på punkt objekter i forbindelse med Linie objekt, udførelsen af disse metoder i forbindelse af punkt genstande og opkaldene og udførelse af -anlæg (int) og setY (INT) metoder.

Pointcut designatorer

Kvantificeringen over sammenføjningspunkter udtrykkes på sprogniveau. Denne kvantificering kan være implicit i sprogstrukturen eller kan udtrykkes ved hjælp af en forespørgselignende konstruktion kaldet en genvejstast. Pointcuts defineres som et predikat over programmets syntaks-træ og definerer en grænseflade, der begrænser hvilke elementer i basisprogrammet, der udsættes for ved genvejstasten. En punkt genvej udvælger bestemte sammenføjningspunkter og værdier på disse punkter. Den syntaktiske formulering af en genvej varierer fra tilgang til tilgang, men en genvej kan ofte sammensættes ud fra andre genveje ved hjælp af de boolske operatorer AND, OR og NOT. Punktudtryk kan kortfattet fange en bred vifte af begivenheder af interesse ved hjælp af jokertegn. For eksempel i AspectJ- syntaks, flytning genvej

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

vælger hvert opkald til Figur's offentlige metoder.

cflow poincuts identificerer sammenkoblingspunkter baseret på, om de forekommer i den dynamiske sammenhæng med andre sammenkoblingspunkter. For eksempel cflow(move()) udvælger syntaks i AspectJ hvert sammenkoblingspunkt, der opstår i den dynamiske kontekst af de sammenkoblingspunkter, der er valgt af flytningstasten.

Pointcuts kan klassificeres i to kategorier:

• Sorterede genveje, såsom opkaldsgenvej, matcher en slags tilslutningspunkt ved hjælp af en signatur.
• Ikke-slags genveje, såsom cflow-genvej, matcher alle slags sammenføjningspunkter ved hjælp af en række egenskaber.

Rådgivningsorganer

Et rådgivningsorgan er kode, der udføres, når et sammenføjningspunkt nås. Rådgivning modulerer de funktionelle detaljer i en bekymring. Rækkefølgen, i hvilken rådgivningsorganerne, der er bidraget fra aspekter (og af basen), kan kontrolleres på en række måder, herunder:

• når et sammenføjningspunkt er nået, før udførelsen fortsætter med basen
• efter basissemantikken for sammenføjningspunktet. Når sammenføjningspunktet svarer til udførelsen af ​​en metode, kan en efter-rådgivning udføres efter den returnerede metode eller efter at have hævet en undtagelse
• når sammenkoblingspunktet er nået, med eksplicit kontrol over, om basissemantikken udføres. Omkring rådgivning kan ændre styringen af ​​programmet.

Der er også givet mere generelle måder til at beskrive bestilling af rådgivningsorganer i form af delordre-grafer.

Når udførelsen af ​​et sammenkoblingspunkt tilfredsstiller et punktudskæringsudtryk, udføres basis- og rådgivningskoden, der er knyttet til sammenkoblingspunktet. Rådgivningen kan interagere med restsystemet gennem en sammenføjningspunktsforekomst, der indeholder reflekterende oplysninger om konteksten af ​​den begivenhed, der udløste rådgivningen, såsom argumenterne for et metodekald eller målforekomsten af ​​et opkald.

Inter-type erklæringer

Inter-typedeklarationer giver programmøren mulighed for at ændre et programs statiske struktur, såsom klassemedlemmer og klasseshierarki. Nye medlemmer kan indsættes, og klasser kan skubbes ned i klassehierarkiet.

Aspekter

Et aspekt er et modul, der indkapsler en bekymring. Et aspekt består af pointcuts, rådgivningsorganer og inter-type erklæringer. I nogle tilgange kan et aspekt også indeholde klasser og metoder.

Aspekt vævning

Aspektvævning er en sammensætningsmekanisme, der koordinerer aspekter med de andre moduler i systemet. Det udføres af en specialiseret kompilator, kaldet en aspektvæver .

Eksempel

Figur 6 - Figur Editor i UML

Figur 7 - Aspektorienteret figureditor i UML

Figur 6 illustrerer et klassisk eksempel på en tværgående bekymring i et figureditoreksempel taget fra AOSD-litteraturen. Eksemplet beskriver en abstrakt formklasse, der kan flyttes i editoren. Hver gang en form flyttes, skal skærmen opdateres. Figur 6 viser også to formunderklasser, linje og punkt, der implementerer formfunktionaliteten. Skærmopdateringsproblemet er spredt over implementeringen af ​​begge underklasser. Figur 7 repræsenterer en aspektorienteret implementering af det samme system, hvor et aspekt indkapsler skærmopdateringsfunktionaliteten.

Flytningsgenvejsbeskrivelsen i figur 7 fanger alle udførelser af flytningen Ved hjælp af metoder i en underklasse af figur og påberåber sig skærmopdateringsfunktionaliteten, når udførelsen fortsætter. Bekymringen er moduleret, hvilket gør det lettere at udvikle og vedligeholde.

Aspektorienteret kravsteknik

Aspekt orienteret krav engineering (også omtalt som "Tidlige aspekter") fokuserer på identifikation, specifikation og repræsentation af tværgående egenskaber på kravet niveau. Eksempler på sådanne egenskaber inkluderer sikkerhed , mobilitet, tilgængelighed og begrænsninger i realtid . Tværgående egenskaber er krav, brugssager eller funktioner, der har en bredt anvendt effekt på andre krav eller arkitekturkomponenter .

Aspekt-orienterede kravstekniske tilgange er teknikker, der udtrykkeligt anerkender vigtigheden af ​​klart at adressere både funktionelle og ikke-funktionelle tværgående bekymringer ud over ikke-tværgående. Derfor fokuserer disse tilgange på systematisk og modulær behandling, begrundelse for, komponering og efterfølgende sporing af tværgående funktionelle og ikke-funktionelle bekymringer via egnede abstraktions- , repræsentations- og kompositionsmekanismer, der er skræddersyet til kravsteknikområdet.

Specifikke ekspertiseområder under nævneren af ​​AO-kravanalyse er:

• den aspektorienterede kravsproces i sig selv,
• de aspektorienterede kravnotationer,
• aspektorienteret understøttelse af værktøj
• vedtagelse og integration af aspektorienterede kravsteknik, og
• vurdering / evaluering af aspektorienterede krav.

Aspektorienteret styring af forretningsprocesser (AOBPM)

Reduktion af kompleksitet er et vigtigt emne i Business Process Management (BPM) -området. En kilde til kompleksitet er rodfæstet i de mange bekymringer, som en forretningsproces adresserer, såsom sikkerhed og privatliv. Ideelt set bør disse bekymringer defineres adskilt fra forretningsprocesserne, da de typisk spænder over flere processer, og de kan ændres på et generelt organisatorisk niveau i stedet for specifikt procesniveau. Nuværende forretningsprocesstyringssystemer understøtter imidlertid ikke denne form for modellering.

Aspektorienteret styring af forretningsprocesser (AOBPM) forsøger at understøtte adskillelse af tværgående bekymringer fra kerneforretningens bekymringer. Den definerer et sæt krav og en formel model. Denne model er designet ved hjælp af Colored Petri Nets (CPN).

Metoden er implementeret som en service i YAWL baseret på Service Oriented Architecture .

Vurderingsresultatet af nuværende aspektorienterede tilgange til ledelse af forretningsprocesser er defineret ud fra fem dimensioner såsom signatureksponering, regelsammensætning, rådgivningsrelationer, transformationsmønstre og fasesupport. Resultatet kan ses i den følgende figur.

Aspektorienteret systemarkitektur

Aspektorienteret systemarkitektur fokuserer på lokalisering og specifikation af tværgående bekymringer i arkitektoniske design. Tværgående overvejelser, der vises på arkitektonisk niveau, kan ikke moduleres ved at omdefinere softwarearkitekturen ved hjælp af konventionelle arkitektoniske abstraktioner. Aspektorienterede systemarkitektursprog foreslår eksplicitte mekanismer til at identificere, specificere og evaluere aspekter på arkitekturdesignniveau.

Aspektorienteret arkitektur starter med den observation, at vi skal identificere, specificere og evaluere aspekter eksplicit på arkitekturdesignniveau. Aspektuelle arkitekturtilgange beskriver trin til identifikation af arkitektoniske aspekter. Disse oplysninger bruges til at redesigne en given arkitektur, hvor de arkitektoniske aspekter gøres eksplicit. I denne henseende er specifikke ekspertiseområder:

• den aspektorienterede arkitekturproces i sig selv,
• de aspektorienterede arkitekturnotationer,
• aspektorienteret understøttelse af arkitekturværktøj
• vedtagelse og integration af aspektorienteret arkitektur, og
• vurdering / evaluering af aspektorienteret arkitektur.

Aspektorienteret modellering og design

Aspektorienteret design har de samme mål som enhver software-designaktivitet, dvs. karakterisering og specificering af softwaresystemets opførsel og struktur. Dens unikke bidrag til softwaredesign ligger i det faktum, at bekymringer, der nødvendigvis er spredt og indviklet i mere traditionelle tilgange, kan moduleres. En sådan tilgang inkluderer typisk både en proces og et sprog. Processen tager inputkrav og producerer en designmodel. Den producerede designmodel repræsenterer separate bekymringer og deres forhold. Sproget giver konstruktioner, der kan beskrive de elementer, der skal repræsenteres i designet, og de forhold, der kan eksistere mellem disse elementer. Især tilvejebringes konstruktioner, der understøtter bekymringsmodularisering og specifikationen af ​​bekymringssammensætning, under hensyntagen til konflikter. Ud over det sammenligner designet af hvert individuelt moduleret problem med standard softwaredesign.

Her er specifikke områder for ekspertise:

• selve den aspektorienterede designproces,
• de aspektorienterede designnotationer,
• aspektorienteret support til designværktøj
• vedtagelse og integration af aspektorienteret design og
• vurdering / evaluering af aspektorienteret design.

Aspektorienteret programmering (AOP)

AOP inkluderer programmeringsteknikker og værktøjer, der understøtter modularisering af bekymringer på kildekodeniveauet.

Ligesom ethvert andet programmeringssprog består et aspektorienteret sprog typisk af to dele: en sprogspecifikation og en implementering. Derfor er der to tilsvarende bekymringsområder: support til sprogudviklere og support til applikationsudviklere.

Support til applikationsudviklere

En aspektorienteret tilgang understøtter implementeringen af ​​bekymringer og hvordan man sammensætter disse uafhængigt implementerede bekymringer. Mens specifikationen af ​​et sådant sprog er den primære manual for applikationsudviklere, giver det naturligvis ingen garanti for, at applikationsudvikleren vil producere højkvalitets aspektorienterede programmer. Specifikke ekspertiseområder:

• de afgørende begreber inden for aspektorienteret programmering,
• programmering på aspektorienterede sprog
• komponere softwarekomponenter skrevet på ethvert sprog ved hjælp af aspektorienterede kompositionsmekanismer, eller
• aspektorienterede programmeringsmiljøer.

Støtte til sprogudviklere

Excellence i konstruktion af aspektorienterede sprog inkluderer følgende områder:

• konstruere sprog eller DSL'er til bestemte domæner og / eller platforme, og
• overførelse af implementeringsprincipper fra andre aspektorienterede eksekveringsmiljøer, herunder:
  • tolke,
  • kompilatorer og
  • virtuelle maskiner.

Formel metodestøtte til aspektorientering

Formelle metoder kan bruges både til at definere aspekter semantisk og til at analysere og verificere aspektorienterede systemer. Aspektorienteret programmering udvider programmeringsnotationer med aspektmoduler, der isolerer erklæringen om, hvornår aspektet skal anvendes (sammenføjningspunkter), og hvilke handlinger der skal udføres, når det nås (rådgivning). Ekspertise i formelle semantiske definitioner af aspektkonstruktioner er nyttigt for sprogdesignere til at give en dyb forståelse af forskellene mellem konstruktioner. Aspekter kan potentielt skade pålideligheden af ​​et system, som de er vævet til, og kan ugyldiggøre væsentlige egenskaber, der allerede var sandt for systemet uden aspektet. Det er også nødvendigt at vise, at de faktisk tilføjer tilsigtede tværgående egenskaber til systemet. Derfor rejses adskillige spørgsmål om korrekthed og verifikation af aspekt-sprog. Blandt de slags ekspertise er:

• specielt designet testteknikker til at dække aspekter,
• programudskæring og kodeanalysetilgang til at identificere interaktioner mellem aspekter og mellem aspekter og underliggende systemer
• modelkontrolteknikker specialiseret i aspekter, og
• induktive teknikker til at verificere aspektorienterede systemer.

Hver af de ovennævnte tilgange kan bruges til at:

• specificere og analysere individuelle aspekter i forhold til et eksisterende system
• definere betingelser for at komponere flere aspekter korrekt, og
• opdage og løse potentielle interferenser mellem aspekter.

Selvom nogle tilgange allerede anvendes på aspekt-sprog, er andre stadig genstand for forskning og er ikke klar til rutinemæssig industriel anvendelse. Ikke desto mindre er bevidsthed om disse emner afgørende for sprogdesignere og for effektiv brug af aspekter, især i sikkerhedskritiske sammenhænge.

Aspektorienteret middleware

Middleware og AOSD supplerer hinanden stærkt. Generelt består ekspertiseområder af:

• support til applikationsudvikleren, som inkluderer
  • de afgørende begreber i aspekt, der understøtter middleware,
  • aspektorienteret softwareudvikling ved hjælp af en bestemt middleware, der involverer aspektprogrammeringsmodellen, aspektimplementeringsmodel, platforminfrastruktur og tjenester fra middleware og
• Produktfamilieteknik (metoder, arkitekturer, teknikker) i distribueret og omgivende computing og
• support til middlewareudvikleren med hensyn til
  • værtsinfrastruktur middleware,
  • distribution mellemvare,
  • fælles middleware-tjenester og
  • domænespecifikke middlewaretjenester.

Adoption

• IBM WebSphere Application Server (WAS) er en java-applikationsserver, der understøtter Java EE og Web Services. Websphere distribueres i henhold til udgaver, der understøtter forskellige funktioner. Websphere bruger AspectJ internt til at isolere funktioner i de forskellige udgaver.
• JBoss Application Server (JBoss AS) er en gratis Java-applikationsserver med open source, der understøtter Java EE. Kernen i JBoss AS er integreret med JBoss AOP aspekt-orienteret programmeringssprog. Applikationsserveren bruger JBoss AOP til at implementere tjenester såsom sikkerhed og transaktionsstyring.
• Oracle TopLink er en Java-objekt-til-relationel persistensramme, der er integreret med Spring Application Server. TopLink opnår høje niveauer af persistensgennemsigtighed ved hjælp af Spring AOP.
• SAP
• Sun Microsystems bruger AspectJ til at strømline udviklingen af ​​mobilapplikationer til Java ME-platformen. Aspekter bruges til at forenkle udviklingen af ​​mobilapplikationer til implementering på forskellige operatørdæk og forskellige mobile gaming community-grænseflader.
• Siemens Soarian er et sundhedsinformationsstyringssystem, der understøtter problemfri adgang til patientjournaler og definitionen af ​​arbejdsgange for sundhedsudbydere. Soarian bruger AspectJ til at integrere tværgående funktioner som sporing, auditering og ydeevneovervågning i forbindelse med en agil udviklingsproces.
• Motorola wi4 er et mobilinfrastruktursystem, der understøtter WiMAX trådløs bredbåndsstandard. Wi4-kontrolsoftwaren er udviklet ved hjælp af en aspektorienteret udvidelse til UML 2.0-standarden kaldet WEAVR. WEAVR bruges under udviklingen til debugging og testformål.
• ASML er leverandør af litografisystemer til halvlederindustrien. ASML bruger en aspektorienteret udvidelse til C kaldet Mirjam til at modulere sporing og profilering af bekymringer.
• Glassbox er en fejlfindingsagent til Java-applikationer, der automatisk diagnosticerer almindelige problemer. Glassbox-inspektøren overvåger aktiviteten på den virtuelle Java-maskine ved hjælp af AspectJ.
• .NET 3.5 understøtter aspektorienterede koncepter gennem Unity-containeren.

Fodnoter

Referencer

• Kiczales, G .; Lamping, J .; Mendhekar, A .; Maeda, C .; Lopes, C .; Loingtier, JM; Irwin, J. (1997). Aspektorienteret programmering (PDF) . ECOOP '97. Forhandlingerne med den 11. europæiske konference om objektorienteret programmering . 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): Fungerer aspektorienteret programmering ?, i: Kommunikation af ACM, oktober 2001, bind. 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 21. International Conference on Software Engineering (ICSE 1999), Los Angeles, Californien, 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

eksterne links

• Aspektorienteret softwareudviklingsfællesskab og konference