Диссертация (1148251), страница 21
Текст из файла (страница 21)
КЛАСС ДЛЯ ВЫВОДА КОЛИЧЕСТВА ЗАПУЩЕННЫХ ЭКЗЕМПЛЯРОВ ВЕБ-РОЛИ115После АОП-рефакторинга:public partial class _Default : System.Web.UI.Page{//…//Свойство-представитель аспекта ElasticAzureAspectprivate string CurrentInstances{get{ return ""; }set{}}protected void btnRefresh_Click(object sender, EventArgs e) {lblCurrentInstanceCount.Text = CurrentInstances;}protected void btnUpdateConfig_Click(object sender, EventArgs e) {CurrentInstances = lblCurrentInstanceCount.Text.Trim();}}// class _Defaultpublic class ElasticAzureAspect : Aspect {//…[AspectAction("%instead %call *_Default.get_CurrentInstances()")]public static string get_CurrentInstances() {//…string InstanceCount = AzureRESTMgmtHelper.GetInstanceCount(svcconfig,"WebRole1");return InstanceCount;}[AspectAction("%instead %call *_Default.set_CurrentInstances(string)")]public static void set_CurrentInstances(string value) {//…string UpdatedSvcConfig = AzureRESTMgmtHelper.ChangeInstanceCount(svcconfig, "WebRole1", value);AzureRESTMgmtHelper.ChangeConfigFile(UpdatedSvcConfig);}} // class ElasticAzureAspectЛИСТИНГ 51.
КЛАСС ДЛЯ ВЫВОДА КОЛИЧЕСТВА ЗАПУЩЕННЫХ ЭКЗЕМПЛЯРОВ ВЕБ-РОЛИ ПОСЛЕ АОПРЕФАКТОРИНГАДля оценки полученных результатов использовалась интегральная метрикаMaintainability Index, которая встроена в Microsoft Visual Studio и определяетудобство сопровождения исходного кода отдельных классов и проекта в целом.Так, например, выделение из целевых классов учебного примера [106] функциикэширования в отдельный аспект позволило увеличить для них эту метрикукачества на 33%. Для целевых классов другого примера [33] аспектное управлениеконфигурацией дало прирост этого индекса на 24%. Следует отметить, что такойвыигрыш наблюдается только у конкретных классов, но экономия в масштабахцелого приложения будет не столь существенна.1165.7 Демонстрация АОП-рефакторинга в приложениях N2CMS иOrchardАналогично проекту по демонстрации преимуществ АОП-рефакторингасистемы JHotDraw [52] на основе AspectJ [101], получить информацию оприменимости АОП-рефакторинга на базе Aspect.NET для реальных приложенийможно из студенческих проектов Н.
Волкова и А. Михайловой, которыерассматривали N2CMS [85, 110] и Orchard CMS [122, 86]. Данные приложения соткрытым кодом по созданию и управлению сайтами работают на платформеASP.NET и, следовательно, могут быть перенесены в облако Microsoft Azure. Впервом проекте проведен рефакторинг 3 классов, их метрики приведены ниже, нарис. 7 и рис. 8.Самой существенной из них можно считать метрику «Коэффициентсопровождаемости» (Maintainability Index). На рис. 7 и 8 его значения находятся впервой колонке.Данный коэффициент имеет значение от 0 до 100, которое обозначаетотносительную легкость сопровождения кода.
Чем больше значение, тем легче кодсопровождать (вносить в него изменения, добавлять новую функциональность,удалять устаревшие блоки, искать ошибки и т.д.). Чтобы ускорить обнаружениепроблемных фрагментов кода, могут использоваться цветовые индикаторы.Зеленый рейтинг указывает на значение индекса в диапазоне от 20 до 100, чтоозначает, что код удобно поддерживать. Желтый рейтинг указывает на значениеиндекса в диапазоне от 10 до 19, что означает, что код можно поддерживать.Красный рейтинг указывает на значение индекса в диапазоне от 0 до 9, чтоозначает, что код сложно поддерживать [118]. Значения указанных коэффициентовдо и после преобразования приведены ниже (Таблица 2 и Таблица 3соответственно).117ТАБЛИЦА 2. ИНДЕКСЫ СОПРОВОЖДАЕМОСТИ ДО АОП-РЕФАКТОРИНГАИндексЦикломатическая Глубинасопровождаемости сложностьКол-воКол-вонаследования связейстрокVirtualPathFileSystem 7080127196SecurityEnforcer713912366ChildXmlReader671721324ТАБЛИЦА 3.
ИНДЕКСЫ СОПРОВОЖДАЕМОСТИ ПОСЛЕ АОП-РЕФАКТОРИНГАИндексЦикломатичесГлубинаКол-воКол-восопровождаемости кая сложностьнаследованиясвязейстрокVirtualPathFileSystem7278127188SecurityEnforcer763212249ChildXmlReader801321010Как можно видеть, коэффициент сопровождаемости кода целевых классов,подвергнутых АОП-рефакторингу улучшился на 3-25%. В проекте с Orchard CMSАОП-рефакторингспомощью6аспектовповысилкоэффициентсопровождаемости целевых классов на 5-12%. В результате реализовано:1)2)3)4)5)извлечение в аспект методов, отвечающих за протоколирование;извлечение в аспект методов, отвечающих за запись в журнал событий;извлечение в аспект методов, отвечающих за форматирование объектов;обработка исключений;извлечение в аспект методов, отвечающих за работу с контейнерами.Результаты изменения Maintainability Index целевых классов приведенына рисунке 7.118РИСУНОК 7.
УЛУЧШЕНИЕ МЕТРИКИ MAINTAINABILITY INDEX ПОСЛЕ АОП-РЕФАКТОРИНГА ORCHARD CMS5.8 Выводы по главеПроведение ООП-рефакторинга становится обязательной процедурой приразработке ПО. Его отсутствие приводит к повышению косности системы,усилению её вязкости, потере гибкости и снижению общего качества исходногокода [121]. В том случае, если на класс возложено сразу несколько обязанностей(нарушен принцип SRP), или при добавлении нового поведения приходитсяредактировать его код (нарушение принципа OCP), то следует произвести егорефакторинг, в частности перенести “лишние” обязанности на новые классы изаменить прямые зависимости от конкретных классов на использованиеабстракций. После ООП-рефакторинга один “толстый” класс распадается насистему из меньших, суммарный размер исходного кода которых может бытьбольше прежнего, но качество сопровождаемости каждого в отдельности будетлучше (известный принцип “разделяй и властвуй”).При АОП-рефакторинге предлагается пойти ещё дальше и вынестисквозную функциональность в класс из внешнего проекта (аспект), чтобыповысить степень её повторного применения.
Особенно это актуально для веб-119приложений на базе платформы Microsoft Azure, так как её сервисы и компонентыне зависят от окружающего контекста, зачастую вызываются через статическиеметоды и пригодны для выделения в статический класс аспекта.В данной главе сформулированы приемы для выделения из целевых классоввеб-приложений зависимостей от служб Microsoft Azure в аспекты. На примереслужбы кэширования демонстрируется “очищение” целевого бизнес-класса отвторичной функции кэширования и выделения её в %instead-действие аспекта,пригодного для повторного использования.
В том случае, когда требуетсяподвергнуть АОП-рефакторингу метод (callback), вызываемый инфраструктуройMicrosoft Azure, рекомендуется создать для него аспектный производный классчерез атрибут [ReplaceBaseClass]. Однако это не поможет в случае, когдатребуется переопределить целевой метод рабочей или веб-роли, так как MicrosoftAzure требует для роли только прямого наследования от класса RoleEntryPoint. Вэтом случае целиком заменить его не получится, но можно расширить егоповедение, привязав %before или %after-действие аспекта к вызову методовRoleEntryPoint.В ряде случаев сквозная функциональность требует отдельной панелинастройки от пользователя в .aspx-разметке ASP.NET MVC приложения.
Тогда врамках АОП-рефакторинга она выделяется в отдельный аспект, содержащий .ascxкомпонент представления указанной панели, связанную с моделью данных длясквознойфункциональностииклассцелевогоконтроллерарасширяетсяаспектным замещающим наследником для поддержки нового .ascx-компонента.Такой прием повышает повторную используемость сквозной функциональности,однако бывают случаи, когда в представлении есть лишь несколько разнородныхполей, управляющих службой, которые не имеет смысла или затруднительнообъединять в одну панель.
В этом случае оптимальным будет решение выделитьв классе страницы для них пустые private-свойства, а реализацию определитьв аспекте с помощью %instead-действий.Все приведенные приемы АОП-рефакторинга позволяют переложитьобязанность работать со службами Microsoft Azure с целевого класса на аспект,120чтофокусируетегонареализацииисключительнобизнес-требований.Конкретные преимущества демонстрируются повышением у целевых классовкомбинированной метрики качества кода Maintainability Index. В заключениеприведеныи OrchardпримерыCMSи,АОП-рефакторинговтакжеспомощьюпромышленныхметрикисистемMaintainabilityN2CMSIndex,продемонстрировано улучшение качества их исходного кода.Таким образом, применение АОП и Aspect.NET в разработке облачногоприложения позволяет повысить легкость его сопровождения, увеличить скоростьразработки и снизить затраты за счет повторного использования универсальныхаспектов.121Глава 6. Бесшовное расширение облачных вебприложений с помощью Microsoft Enterprise LibraryIntegration Pack6.1Применимость MicrosoftфункциональностиELдляреализациисквознойВ данном разделе представлена методика по бесшовному расширениюфункциональности веб-приложений с помощью Aspect.NET и Microsoft EnterpriseLibrary Integration Pack for Microsoft Azure.
Объектом исследования быливыбраны Autoscaling Application Block и Transient Fault Handling Block, какнаиболее полезные для разработки облачных приложений на платформе MicrosoftAzure. Содержание данного раздела в значительной степени основывается наранее опубликованной автором работе [114].Библиотека Microsoft Enterprise Library [63] представляет собой наборнаиболееудачныхобразцоврешениястандартныхпроблемитакжепредназначена для реализации “сквозной функциональности”.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
