Има много дискусии относно използването на захранващия конектор. Всъщност потребителят може да добави захранващия конектор към съществуващ софтуерен модел, използван за свързване на бизнес проблеми и междусекторни проблеми. Поради семантиката на AOP, частта за конектора зависи от бизнес проблемите, а частта за междусекторни проблеми зависи от захранващия конектор.
След това, около конектора, потребителят може да направи серия от избрани, без да е необходимо ръчно да въвежда каквото и да е съдържание, като идентифицира бизнес проблеми, начин на свързване на частите и напречни проблеми (тази стъпка е чрез определяне на взаимната информация в AOP и информацията, съхранена в конектора, за да се постигне, разбира се, че е възможно да се експортира тази информация за частите).
Твърди се също, че за да се осигури плавен преход между проектиране и внедряване и да се поддържа ниско ниво на архитектурно проектиране, инструментите за аспектно-ориентирано моделиране, базирани на връзки, трябва да поддържат кодова рамка, която автоматично генерира различни техники за внедряване на AOP от дизайнерския модел. Това позволява на разработчика да се съсредоточи върху изграждането на модела, докато инструментът за моделиране генерира кода автоматично. Генерирането на код подобрява производителността на разработчика и намалява грешките. Методът за аспектно-ориентирано моделиране, базиран на връзки, подобрява повторната употреба на AOP технологията и подобрява ефективността на разработката на софтуер, като избягва несъответствия между дизайна и внедряването. Дизайнерът може да проектира AO с обектно-ориентираната идея, а разработчикът може да продължи с по-късното програмиране според генерираната кодова рамка.
Също така е предложено, че конекторите са въведени, за да поддържат аспектно-ориентираното моделиране, поддържайки разделяне на проблемите в началото на жизнения цикъл на софтуера, за да се отговори на спецификацията на междусекторните проблеми на архитектурно ниво. Една от основните причини за въвеждането на конекторите е да се осигури стандартна поддръжка на инструменти за разработка. Решенията, базирани на UML, за добавяне на конектори са по-приемливи. Конекторите са прост и мощен идентификатор за аспектно-ориентирано моделиране. Но за да се намалят грешките при картографирането на модели към код и да се осигури поддръжка за основния архитектурен дизайн, е необходимо и автоматично генериране на AOP кодови рамки.
По този начин, като цяло, базираните на връзки подходи за аспектно-ориентирано моделиране могат да бъдат въведени по прозрачен начин на етапа на аналитично проектиране на софтуер и могат да насочват по-късното писане на AOP код, за да се постигне безпроблемна връзка между дизайна и кода.
Време на публикуване: 01 октомври 2019 г.