Diskuto pri la uzo de la potenco-konektilo havas multajn, fakte, la uzanto povas aldoni la potenco-konektilon al ekzistanta programaro-modelo, uzata por konekti la komercajn zorgojn kaj transversajn zorgojn, pro AOP-semantiko, la konektilo-parto dependas de komercaj zorgoj, la transkruciĝo koncernas parto dependas de la potenca konektilo.
Tiam, ĉirkaŭ la konektilo, la uzanto povas fari serion de elektitaj, sen devi permane enigi ajnan enhavon, ĝi povas esti la komercaj zorgoj, la maniero de konektopartoj kaj transversaj zorgoj identigitaj (ĉi tiu paŝo estas determini la reciprokan informon de AOP, kaj la informoj stokitaj en la konektilo atingi, ĉi tiu parto eksporta informo estas farebla, kompreneble).
Estas ankaŭ argumentite ke por permesi glatan transiron inter dezajno kaj efektivigo kaj subteni malaltnivelan arkitekturan dezajnon, lig-bazitaj aspekto-orientitaj modeligaj iloj devas subteni kodkadron kiu aŭtomate generas malsamajn AOP-efektivigteknikojn de la dezajnomodelo. permesas al la programisto koncentriĝi pri konstruado de la modelo dum la modelila ilo generas la kodon aŭtomate.Kodgenerado plibonigas la produktivecon de la programisto kaj reduktas erarojn.La lig-bazita aspekto-orientita modeliga metodo plibonigas la reuzeblon de AOP-teknologio kaj plibonigas la efikecon de programaro-disvolviĝo per evitante nekongruecon inter dezajno kaj efektivigo. La dezajnisto povas desegni AO kun la objekto-orientita ideo, kaj la programisto povas daŭrigi la pli postan programadon laŭ la generita kodkadro.
Estis ankaŭ sugestite ke konektiloj estis lanĉitaj por apogi aspekto-orientitan modeligadon, konservante apartigon de zorgoj frue en la programara vivociklo por trakti la specifon de transkrucitaj konzernoj sur la arkitektura nivelo. Unu el la ĉefaj kialoj, kial konektiloj estis lanĉitaj, estis disponigi normon. subteno de evoluiloj.Uml-bazitaj solvoj por aldoni konektilojn estas pli akcepteblaj.Konektiloj estas simpla kaj potenca identigilo por aspekto-orientita modeligado.Sed por redukti erarojn en mapado de modeloj al kodo, kaj provizi subtenon por la subesta arkitekturo-dezajno, aŭtomata generacio de AOP-kodkadroj ankaŭ estas postulata.
Tiel, ĝenerale, lig-bazitaj aspekto-orientitaj modeligaj aliroj povas esti lanĉitaj en travidebla maniero en la analiza dezajnostadio de softvaro, kaj povas gvidi la pli postan skribon de AOP-kodo por atingi senjuntan ligon inter dezajno kaj kodo.
Afiŝtempo: Oct-01-2019