Программные продукты и системы

Тенденция к проникновению информационных технологий (ИТ) в подавляющее большинство областей деятельности человека, особенно в промышленность, развитие средств массовой ком- муникации и масштабность бизнеса находят свое отражение в сложности принимаемых решений и неопределенности представления предметной области при разработке ПО.

Общепризнано, что предметная область является инвариантной составляющей в современном рекуррентном подходе к проектированию промышленного ПО, который характеризуется компоновкой различных взглядов в отношении реализации функциональности бизнес-процессов будущей информационной системы (ИС).

Таким образом, необходим механизм, позволяющий абстрагировать каждый бизнес-процесс предприятия на всех итерациях стадий проектирования и реализации ПО от несущественных (вспомогательных) аспектов системы.

Методологии программирования

Среди основных методологий программиро- вания (императивного, функционального, логи- ческого программирования и объектно-ориентированного программирования (ООП)) наиболее востребованным подходом при проектировании и разработке ПО является ООП (Object-Oriented Programming) [1].

ООП – методология программирования, основанная на представлении программного продукта в виде совокупности объектов, каждый из которых является экземпляром конкретного класса. ООП использует в качестве базовых элементов взаимодействие объектов – именованных моделей реальной сущности, обладающих конкретными значениями свойств и проявляющих свое поведение [2].

ООП можно описать четырьмя главными характерными свойствами: абстрагирование, инкапсуляция, модульность, иерархия (рис. 1).

Абстрагирование позволяет выделить наиболее значимые свойства объекта и тем самым моделировать объект, отличающийся от других объектов. С помощью абстракции разработчики промышленных ИС могут решать разнообразные сложные проблемы, последовательно дифференцируя их на более простые [3].

Инкапсуляция предназначена для сокрытия реализации элементов, описывающих поведение объекта.

Под модульностью подразумевается свойство разделения программы на независимые составные части – модули.

Иерархия позволяет упорядочить абстракции и модули, формируя из них уровни взаимодействия.

Рассматривая ООП в контексте проектирования крупных промышленных ИС, можно отметить, что исходный код данных ИС характеризуется необоснованной сложностью, излишним дублированием, шаблонными ошибками, неопределенностью, наличием сильной взаимосвязи между модулями. Как следствие, оценка бюджета разрабатываемого проекта, классификация расходов, планирование сроков разработки и анализ затрат сопровождаются неточностями и искажениями.

В связи с этим особую актуальность приобретает применение инновационного подхода к проектированию ПО, который с точки зрения разработки ПО позволит

-     значительно повысить уровень програм- мной абстракции;

-     разрабатывать ПО как независимую совокупность различных надежных компонентов функциональности и предметной области;

-     повысить качество исходного кода: уменьшить дублирование и, как следствие, объем, повысить прозрачность (улучшить структуру) и читаемость, упростить тестирование;

-     не зависеть от возможного изменения конфигурации ИС (масштабирование);

-     систематически добавлять и модифицировать функциональность (адаптивность);

-     упростить разработку документации и сопровождение ИС.

С точки зрения экономических показателей позволит

-     повысить точность оценки предполагаемого бюджета разрабатываемой ИС;

-     улучшить качество решений при планировании сроков разработки ИС;

-     рациональнее распределять расходы по аспектам разработки ИС;

-     корректно отражать величину трудозатрат при разработке ИС на каждом из этапов жизненного цикла ПО.

Парадигмой программирования, нацеленной на решение указанных проблем, является аспектно-ориентированное программирование (АОП).

Описание АОП

АОП является современным развитием ООП и предназначено для отделения бизнес-логики  ИС от сквозных функций.

Сквозная функциональность (Cross-cutting concern) – это функциональность, рассеянная по всему исходному коду ПО, систематически независимая от предметной области. АОП предоставляет возможность вызывать код сквозных функций без изменения исходного кода программы в определенный момент работы программы [4]:

-     перед вызовом метода;

-     после вызова метода независимо от результата;

-     после успешного вызова (выполнение метода завершилось успешно);

-     после исключения (вызванный метод возбудил исключение);

-     вокруг (до и после вызова метода).

К общесистемным требованиям обычно относятся сквозные функции (рис. 2).

К сокращению количества вариантов сквозной функциональности приводит реализация главной цели АОП, которая состоит в том, что типовой код (не связанный с решением прикладных задач предметной области и повторяющийся от компонента к компоненту) не должен смешиваться с прикладной бизнес-логикой [4].

Описание предлагаемой модели ПО

Наиболее общую модель архитектуры промышленной ИС без использования АОП можно представить множеством , где  – обозначение модели промышленной ИС;  – сведения о предметной области;  – набор реализаций функций бизнес-логики ИС;  – сквозная функциональность.

Сведения о предметной области представляют собой формализованную структуру, отображающую взаимодействие бизнес-процессов предприятия.

Под бизнес-логикой понимается набор функций, необходимый для корректного и полного описания алгоритма взаимодействия бизнес-процессов предприятия на каком-либо языке программирования.

Общая модель архитектуры промышленной ИС без использования АОП в соответствии с представленным множеством отражена на рисунке 3.

В данном подходе целевой код будущей ИС зависит от общесистемных требований (сквозной функциональности). Это приводит к увеличению сложности модификации кода и невозможности повторного использования кода, реализующего конкретную, специфичную для данной предметной области поведенческую особенность ИС.

Модель ПО с использованием АОП можно транслитерировать в следующее представление: , где  – обозначение модели промышленной ИС с использованием АОП; СПО – сведения о предметной области; SБ – набор реализаций функций бизнес-логики ИС; СФ – сквозная функциональность.

Общая модель архитектуры промышленной ИС с использованием АОП представлена на рисунке 4.

Очевидно, что данный подход позволяет изолировать целевой код сквозной функциональности от предметной области и бизнес-логики, следовательно, вынести реализацию функций сквозной функциональности в отдельный, независимый процесс разработки.

Иллюстрация использования АОП

В качестве иллюстрации использования АОП рассмотрим следующий фрагмент программы на языке Java:

public class UserFileService { ... public void getCustomInfo(File file) { if (file == null) { throw new FileNotFoundException( file.getPath() + " not found..."); } if (this.id == file.id) { System.out.println(file.getInfo()); } else { throw new SecurityException( "Not allowed"); } } ... } ...

Данный модуль (метод getCustomInfo объекта класса UserFileService) реализует алгоритмы двух аспектов:

-     вывод на экран титульных сведений о содержимом объекта класса File – главный аспект;

-     обеспечение безопасности (в данном случае проверка совпадения значений идентификаторов файлов, доступных для чтения текущему пользователю) – сквозная функциональность.

Поскольку к одному модулю программы предъявляются требования сразу двух аспектов, один из которых реализует сквозную функциональность, средствами АОП необходимо изолировать данные аспекты в независимые модули (для примера был выбран язык AspectJ, который является расширением языка Java):

public class UserFileService { ... public void getCustomInfo(File file) { System.out.println(file.getInfo()); } ... } ... public aspect Security { ... void around(UserFileService service, File file): call(void UserFileService.getCustomInfo(File)) && args(file) && target(service) { if (file == null) { throw new FileNotFoundException( file.getPath() + " not found..."); } if (file.id == service.id) { proceed(service, file); } else { throw new SecurityException( "Not allowed"); } } ... } ...

Как видно, реализация чтения титульных све- дений о содержимом объекта класса File теперь изолирована от сквозной функциональности (проверки совпадения значений идентификаторов файлов, доступных для чтения текущему пользователю).

Параметр aspect предназначен для инициализации нового аспекта – Security.

С помощью конструкции around объявляется, что вместо метода UserFileService.getCustom­Info(File) будет выполнен метод (алгоритм), указанный в фигурных скобках [5]. Алгоритм реализует сквозную функциональность (простую проверку совпадения идентификаторов файлов).

Служебное слово proceed выполняет метод getCustomInfo объекта service класса UserFileSer­vice с аргументом file класса File в случае успеха выполнения алгоритма сквозной функциональности [6].

Преимущества и недостатки методологии АОП с точки зрения наибольшей практической ценности приведены в таблице.

В целом можно отметить, что основная польза АОП заключается в повышении прозрачности кода бизнес-логики и в упрощении прикладных моду- лей, поскольку они будут содержать только базо- вую функциональность, а вторичные проблемы будут вынесены в аспекты.

Преимущества и недостатки АОП

AOP advantages and disadvantages

Недостатки в контексте использования методологии АОП при разработке крупных промышленных ИС не являются существенными.

В заключение сделаем следующие выводы. Реализация сквозной функциональности в отдельные автономные модули, называемые аспектами, является существенным отличием АОП от иных парадигм разработки ПО.

Аспектно-ориентированный сценарий жизненного цикла программного продукта, с одной стороны, предполагает упрощение адаптации к каждому конкретному IT-проекту, с другой, поднимает качество оценки эффективности экономических показателей на новый уровень.

Обобщая сказанное, можно констатировать, что реализация большей части будущей функциональности в виде аспектов – потенциальный шаг к повышению качества принимаемых экономических решений, вследствие чего возможны

-     оценка предполагаемого бюджета разрабатываемой ИС без фактического проектирования;

-     варьирование численностью команды разработчиков при наличии эквивалентной работы;

-     гибкое распределение сроков разработки и соблюдение требуемого качества программного продукта независимо от количества функциональ- ных точек [8];

-     уменьшение трудности поиска разумного компромисса между функционалом и затратами ресурсов на создание ИС;

-     прозрачность понимания в каждый конкретный момент времени реальной продуктивности разработчиков.

Абстрагирование и модуляризация совокупности задач в аспекты позволяет получить корректное отображение связей между бизнес-процессами и требованиями к реализации объектов предметной области проектируемой ИС.

Независимость целевого кода и аспектов способствует реализации более гибкого процесса разработки ПО, тем самым предполагается улучшение качества принимаемых экономических решений на всех итерациях жизненного цикла программного продукта.

Литература

1.     Programming Community Index – TIOBE Index. URL: http://www.tiobe.com/tiobe_index?page=index (дата обращения: 28.02.2016).

2.     Блинов И.Н., Романчик В.С. Java. Методы программирования. Минск: Четыре четверти, 2013. 896 с.

3.     Стелтинг С., Маасен О. Применение шаблонов Java. Библиотека профессионала. М.: Вильямс, 2002. 576 с.

4.     Йенер М., Фидом А. Java EE. Паттерны проектирования для профессионалов. СПб: Питер, 2016. С. 122–123.

5.     Laddad R., Johnson R. AspectJ in Action: Enterprise AOP with Spring Applications, Manning Publ., 2009. 568 p.

6.     Gradecki J.D., Lesiecki N. Mastering AspectJ: Aspect-Oriented Programming in Java, Wiley Publ., 2003. 456 p.

7.     The Don’t Repeat Yourself Principle and the Wormhole Anti-Pattern. URL: http://codebetter.com/jeremymiller/2007/03/22/ the-dont-repeat-yourself-principle-and-the-wormhole-anti-pattern/ (дата обращения: 28.02.2016).

8.     Уоллс К. Spring в действии. М.: ДМК Пресс, 2013. С. 202–203.

9.     Буч Г. Объектно-ориентированный анализ и проектирование. М.: Вильямс, 2010. С. 506–509.

10.   Репин В.В., Елиферов В.Г. Процессный подход к управлению. Моделирование бизнес-процессов. М.: Манн, Иванов и Фербер, 2013. 544 с.