CC BY
13
Хританков А.С.
МФТИ, доцент, anton.khritankoc@acm . org
Сценарная оценка возможных архитектурных изменений на примере одного класса программ анализа
данных
КЛЮЧЕВЫЕ СЛОВА:
Программа анализа данных, оценка архитектурных изменений, метод анализа модифицируемости, реестр технических рисков.
АННОТАЦИЯ:
В статье исследуется применимость сценарного метода анализа модифицируемости ALMA к программам анализа данных и машинного обучения. Составлен и изучен перечень возможных сценариев изменения для программ, реализованных по определенному архитектурному шаблону. Рассматривая сценарии изменений как технические риски, продемонстрирована возможность построения единого реестра технических рисков сразу для множества приложений в составе реальной системы интеллектуального анализа данных.
Введение
Оценка модифицируемости программной системы является важным инструментом для определения ее сопровождаемости в будущем. Модифицируемость является важной характеристикой для систем, создаваемых в проектах с существенной исследовательской частью, неточно определенными или непредсказуемо изменяющимися требованиями. Рассматриваемая в этой статье задача оценки модифицируемости архитектурного шаблона возникла в проекте по разработке интеллектуальной подсистемы для электронных библиотек. Анализируемый архитектурный шаблон использован для разработки приложений анализа данных, входящих в состав подсистемы. Результаты анализа позволяют понять, к каким изменениям подсистема не является гибкой и какие риски возникают вследствие применения данного архитектурного шаблона.
Для проведения анализа был выбран сценарный подход [4, 6], который, в отличие от анализа модульности структуры (например, [3]) и анализа на основе метрик (см. [2]), позволяет оценить модифицируемость системы по ее архитектурному описанию до начала разработки в соответствии с ожиданиями заинтересованных сторон.
Под сценарием изменения подразумевается цепочка событий, влияющих на приложение или среду его выполнения. Воздействием
сценария будем называть изменения, которые необходимо внести в приложение при реализации сценария. Сценарный подход оценки модифицируемости заключается в формулировании сценариев изменений, анализе изменений, вносимых этими цепочками, и оценивании воздействия этих изменений.
Среди сценарных методов был выбран метод анализа модифицируемости на архитектурном уровне (ALMA) [1], так как известны подтверждения применимости этого метода для анализа рисков [1]. Метод ALMA состоит в следующем. Для проведения анализа формируется группа из аналитика, посредника (facilitator), экспертов и заинтересованных лиц системы. Определяется цель исследования, ограничения и объект анализа. На предварительном этапе формируется описание архитектурного шаблона, в которое вносятся пояснения, дополнения по результатам предварительных обсуждений в группе.
Аналитик составляет схему классификации сценариев, специфичную для предметной области - анализа данных и машинное обучение в данном случае.
Сценарная оценка выполняется по следующей процедуре:
1. Аналитик рассылает краткое описание архитектуры приложения, назначает встречу эксперту.
2. На встрече аналитик отвечает на вопросы по архитектуре и интервьюирует эксперта по сценариям, используя классификационные схемы. Проводится несколько раундов, критерием останова является отсутствие новых категорий в схеме.
3. Аналитик совместно с архитектором оценивает сценарии и готовит интерпретацию.
4. Аналитик формирует сводный отчет о поддержке архитектурным шаблоном типов изменений.
Анализ архитектурного шаблона Цель анализа
Целью анализа является выявление и оценка типов изменений, относительно которых программные системы, построенные по рассматриваемому шаблону, не будут гибкими.
Анализируются приложения анализа данных в отдельности, каждое приложение решает определенную задачу из предметной области анализа данных. При этом в ходе анализа рассматриваются изменения, предполагаемые в любых приложениях анализа данных, но не затрагивающие изменение решаемой приложением задачи. Описание архитектурного шаблона
Исследуемый архитектурный шаблон используется в проекте по разработке интеллектуальных средств для электронных библиотек. По замыслу разработчиков шаблон должен обеспечить модифицируемость и переносимость приложений анализа данных, а также систематизировать и облегчить процесс их проектирования и реализации.
Согласно шаблону, каждое приложение реализует одну или несколько операций обработки данных, результаты которых могут использовать другие приложения. В архитектурном шаблоне, приложение состоит из драйвера и нескольких связанных модулей, использующих данные из одной предметной области.
Драйвер создает и настраивает модули, получает постановку задачи и организует ее обработку модулями. Алгоритмический модуль реализует определенный алгоритм анализа данных и решает одну точно сформулированную задачу. Модуль доступа к данным обеспечивает доступ к внешним данным и перевод их во внутренний формат приложения. Процессный модуль использует алгоритмические модули, модули доступа к данным и другие процессные модули для реализации операции, выполняемой приложением. Алгоритмический модуль получает доступ к справочникам и вспомогательным данным (side data) также через модули доступа к данным. Модули могут использовать внешние библиотеки, при этом подразумевается, что они не имеют непредвиденных эффектов на другие модули.
Логическая схема шаблона приведена на рис. 1.
вызывает подпроцесс ►
Рис. 1. Диаграмма классов архитектурного шаблона
При старте приложения драйвер создает экземпляры модулей, связывает их между собой и передает процессному модулю постановку задачи. Процессный модуль загружает из внешних источников
необходимые для решения задачи данные, вызывает в определенном порядке алгоритмические модули и сохраняет результаты и возвращает управление драйверу.
Извлечение сценариев
Для первоначального выделения сценариев была использована общая схема с категориями по источникам изменений:
• Изменения в функциональной спецификации.
• Изменения в нефункциональных требованиях.
• Изменения в среде работы.
• Другие источники.
Экспертами выступили разработчики системы, исследователи алгоритмов и представители продуктового менеджмента.
Опросы экспертов проводились независимо по отдельным приложениям с целью извлечения релевантных сценариев изменений. Всего было исследовано четыре приложения и получено 89 сценариев. Три из них были исключены как нерелевантные.
Сценарии были сгруппированы в пять категорий по изменению функциональности, и в четырнадцать категорий по восьми характеристикам качества ISO 25010 [5]. При этом большинство категорий отнесены к переносимости, к безопасности не было отнесено ни одной категории.
В качестве критерия для группировки сценариев была использована общность описания изменений в терминах архитектурного шаблона: какие модули должны быть изменены, как распространяются изменения между модулями. Как следствие, построенные категории сценариев изменений можно принять как типовые сценарии изменений для архитектурного шаблона. Названия типовых сценариев были скорректированы для исключения специфичных для предметной области понятий. Полученные типовые сценарии приведены в таблице 1.
Оценка сценариев
Воздействие сценария оценивалось отдельно для внутренней структуры приложения (SI) и для взаимодействия с внешней средой (EI).
Табл. 1. Типовые сценарии изменения с оценками влияния (EI, SI), сложности согласований (AC),уровня затрат на реализацию (EL), вероятности возникновения (P) и предполагаемая реакция (Resp.)
№ Типовой сценарий изменений EI SI AC EL P Resp.
1. Расширение задачи обработки данных, области применения 2 2 2 Iter Med Ctrl
2. Изменение математической модели задачи обработки данных 2 3 2 Phs Low Ctrl
3. Изменение реализации и алгоритмов обработки данных 1 1 1 Task Med Acc
4. Изменение состава справочников, сторонних (side) данных 1 1 1 Task Med Acc
5. Изменение состава обрабатываемых данных и результатов 2 2 2 Iter High Ctrl
6. Изменение интерфейса управления приложением 1 1 2 Iter Med Acc
7. Существенные изменения в объеме обрабатываемых данных 1 1 1 Task High Acc
8. Оптимизация сценариев обработки, комбинирование алгоритмов 1 1 1 Task Med Acc
9. Поддержка тестирования отдельных модулей 0 1 None Low Acc
10. Изменение границ, объединение и перекомпоновка приложений 1 1 1 Task Med Acc
11. Рефакторинг и унификация интерфейсов модулей 1 2 1 Iter Low Acc
12. Изменение механизмов обеспечения надежности 1 1 2 Iter Med Acc
13. Изменение средств мониторинга работы приложения 1 1 2 Iter Med Acc
14. Миграция или замена внешних библиотек алгоритмов 1 1 2 Iter Med Acc
15. Изменение технологии хранения и доступа к данным 1 1 2 Iter Med Acc
16. Изменение языка программирования 1 3 1 Phs Med Ctrl
17. Изменение каркаса (framework), промежуточного ПО (middleware) 1 1 1 Task Low Acc
18. Перенос в облачные среды (IaaS, PaaS) 2 2 2 Iter Med Ctrl
19. Смена модели вычислений (Sequential batch, M/R, Message Passing) 1 2 2 Iter High Ctrl
Оценка воздействия выполнена качественно, использована шкала воздействия изменений, представленная в описании метода [1]:
(0) изменение затрагивает конфигурацию компонента;
(1) изменение затрагивает реализацию компонента;
(2) изменение затрагивает несколько компонентов;
(3) изменение затрагивает архитектуру системы или приложения.
С учетом специфики объекта анализа, шкала сложности согласования (AC) была доработана:
(1) согласование с владельцем приложения;
(2) согласование с владельцами приложения и системы или с владельцами внешних систем;
(3) согласование с владельцами приложения, системы и внешних систем.
Мы не рассматривали воздействие сценариев, связанные с возникновением конфликта версий компонентов, так как ни для одного сценария такой конфликт не возникал.
Интерпретация сценариев как рисков
Для анализа рисков модифицируемости, связанных с негибкостью архитектуры приложений относительно выделенных сценариев изменений каждому типовому сценарию была приписана вероятность возникновения (P). Вероятность оценивалась экспертно и, частично, с учетом исторических данных по проекту по шкале:
(Low) изменение маловероятно и, скорее всего, не случиться в жизненном цикле приложения;
(Med) изменение возможно, имеются примеры в сходных проектах; (High) скорее всего, изменение произойдет, изменение планируется и требуется для развития приложения.
Для классификации изменений по уровню затрат на реализацию (EL) были построены таблицы принятия решений в координатах SI-AC и EI-AC (пример в таблице 2), из которых выбиралось максимальное значение по шкале:
(Nvr) комбинация параметров невозможна;
(None) дополнительные к решению поставленной задачи затраты отсутствуют;
(Task) возможны дополнительные затраты на уровне одной задачи; (Iter) возможно потребуется перепланирование работ в рамках недели или месяца;
(Ph) возможные затраты могут привести к изменениям на уровне фазы или этапа проекта;
(Prj) изменения могут привести к неудаче проекта по разработке приложения в целом.
Табл. 2. Пример таблиц принятия решений по оценке затрат (EL).
Взаимодействие со средой Внутренняя структура_
AC AC
1 2 3 1 2 3
0 None Task Iter 0 None Task Iter
1 None Iter Iter 1 Task Task Iter
2 Never Iter Ph 2 Iter Iter Iter
3 Never Ph Prj on 3 Phase Phase Prj
Анализ полученного реестра рисков
Анализ полученных для архитектурного шаблона типовых сценариев показывает, что основные риски связаны с расширением постановки задачи, решаемой приложением, изменением модели данных, изменением математической постановки задачи и переносом приложения в другую среду исполнения или изменение модели вычислений.
Первые два риска связаны с тем, что модули приложения имеют общую зависимость от модели данных приложения. Изменение математической постановки - это изменение на уровне предметной области, оно влечет смену используемых алгоритмов, порядка обработки и модели данных. Существенное воздействие риска переноса в другую среду объясняется тем, что реализация и интерфейсы модулей, взаимодействующих со средой, не унифицированы, может потребоваться их адаптация.
Отметим, что не были выделены сценарии, связанные с изменением требований к безопасности, что, может объясняться, с одной стороны, решением данного вопроса на уровне архитектуры системы, а с другой недостаточным вниманием к безопасности со стороны экспертов.
Полученные сценарии по построению не являются независимыми,
например, реализация сценария расширения задачи обработки данных может привести к необходимости изменения состава обрабатываемых данных и реализации соответствующего сценария.
Оценивая процесс анализа модифицируемости, можно сказать, что применение метода ALMA не вызвало существенных трудностей, обучение аналитика применению метода состояло в изучении материалов по методу, предварительном обсуждении и пробном интервью по извлечению сценариев. Суммарные затраты времени всей группы составили около пяти человеко-дней.
Заключение
В данной статье представлены результаты анализа модифицируемости и составлен реестр рисков для приложений анализа данных, построенных по определенному архитектурному шаблону.
Сценарный метод оценки позволил выявить труднореализуемые изменения и качественно оценить их влияние на процесс разработки. При необходимости, архитектурный шаблон может быть доработан для обеспечения гибкости по выявленным сценариям, что снизит общий риск проектов разработки приложений с использованием данного шаблона.
Предложенная в данной работе модификация метода ALMA для оценки технических рисков, связанных с внесением изменений в программную систему, и разработанный реестр рисков могут быть применены для повышения качества сложных программных систем анализа данных, управления техническими рисками проектов их разработки и сопровождения.
Литература
1. PerOlof Bengtsson, Nico Lassing, Jan Bosch, and Hans van Vliet. 2004. Architecture-level modifiability analysis (ALMA). J. Syst. Softw. 69, 1-2 (January 2004), 129-147.
2. Heiko Koziolek. 2011. Sustainability evaluation of software architectures: a systematic review. In Proceedings of the joint ACM SIGSOFT conference -- QoSA and ACM SIGSOFT symposium --ISARCS on Quality of software architectures -- QoSA and architecting critical systems -- ISARCS (QoSA-ISARCS '11). ACM, New York, NY, USA, 3-12.
3. Yuanfang Cai and Kevin J. Sullivan. 2006. Modularity Analysis of Logical Design Models. In Proceedings of the 21st IEEE/ACM International Conference on Automated Software Engineering (ASE '06). IEEE Computer Society, Washington, DC, USA, 91-102.
4. Rick Kazman, Len Bass, Mike Webb, and Gregory Abowd. 1994. SAAM: a method for analyzing the properties of software architectures. In Proceedings of the 16th international conference on Software engineering (ICSE '94). IEEE Computer Society Press, Los Alamitos, CA, USA, 81-90.
5. ISO/IEC 25010:2011. Systems and software engineering -- Systems and software Quality Requirements and Evaluation (SQuaRE) -- System and software quality models.
6. Ville Reijonen, Johannes Koskinen, and Ilkka Haikala. 2010. Experiences from scenario-based architecture evaluations with ATAM. In Proceedings of the 4th European conference on Software architecture (ECSA'10), Muhammad Ali Babar and Ian Gorton (Eds.). Springer-Verlag, Berlin, Heidelberg, 214-229.
