Обговорення використання роз’єму живлення є багато, фактично, користувач може додати роз’єм живлення до існуючої моделі програмного забезпечення, що використовується для підключення бізнес-проблем і наскрізних проблем, через семантику AOP частина роз’єму залежить від бізнес-проблем, поперечна частина залежить від роз’єму живлення.
Потім, навколо з’єднувача, користувач може створити серію вибраних, без необхідності вручну вводити будь-який вміст, це можуть бути бізнес-проблеми, режим з’єднання частин і наскрізні проблеми, визначені (цей крок полягає у визначенні спільної інформації AOP, і інформація, що зберігається в конекторі для досягнення, ця частина експорту інформації, звичайно, можлива).
Також стверджується, що для забезпечення плавного переходу між проектуванням і реалізацією та підтримки низькорівневого архітектурного проектування інструменти аспектно-орієнтованого моделювання на основі зв’язків повинні підтримувати структуру коду, яка автоматично генерує різні методи реалізації АОП із моделі проектування. Це дозволяє розробнику зосередитися на побудові моделі, тоді як інструмент моделювання автоматично генерує код. Генерація коду покращує продуктивність розробника та зменшує кількість помилок. Метод аспектно-орієнтованого моделювання на основі зв’язків покращує повторне використання технології AOP та підвищує ефективність розробки програмного забезпечення за допомогою уникаючи неузгодженості між дизайном і реалізацією. Дизайнер може спроектувати AO з об’єктно-орієнтованою ідеєю, а розробник може продовжити подальше програмування відповідно до створеного коду.
Також було припущено, що з’єднувачі були введені для підтримки аспектно-орієнтованого моделювання, зберігаючи поділ проблем на ранніх етапах життєвого циклу програмного забезпечення для вирішення специфікації наскрізних проблем на архітектурному рівні. Однією з головних причин, чому були введені з’єднувачі, було забезпечення стандарту підтримка інструментів розробки. Більш прийнятними є рішення на основі Uml для додавання з’єднувачів. З’єднувачі є простим і потужним ідентифікатором для аспектно-орієнтованого моделювання. Але щоб зменшити кількість помилок у відображенні моделей у коді та забезпечити підтримку базового дизайну архітектури, також потрібна автоматична генерація фреймворків коду AOP.
Таким чином, загалом підходи до аспектно-орієнтованого моделювання на основі зв’язків можуть бути впроваджені прозорим чином на аналітичній стадії проектування програмного забезпечення та можуть керувати подальшим написанням коду AOP для досягнення безперебійного зв’язку між дизайном і кодом.
Час публікації: 01.10.2019