CC BY
20
Использование экспертной системы для обеспечения качества исходного кода начинающих разработчиков программного обеспечения
В.П. Поляков, Южно-Уральский Государственный Университет, инженер, [email protected];
Одно из важнейших направлений в подготовке специалистов, занимающихся разработкой программного обеспечения является анализ требований заказчика и выбор стратегии разработки, максимально подходящей для удовлетворения набора критериев качества реализации программного продукта. На сегодняшний день производство программного обеспечения, а особенно крупных программных систем в промышленных масштабах, выдвигает требования, которые, как правило, включают [1]:
1. функциональные критерии - корректность выполняемых программным продуктом функций;
2. нефункциональные критерии. Нефункциональные критерии включают в себя [2]:
• надежность - свойство программы выполнять необходимые функции без отказов в заданных условиях в течение определенного периода времени с учетом стоимости каждого отказа для пользователей;
• корректность - свойство программы удовлетворять спецификациям;
• устойчивость - свойство программы успешно продолжать выполнение необходимых функций при наличии отклонений в исходных спецификациях;
• эффективность - свойство программы выполнять необходимые функции без излишних затрат ресурсов;
• оптимизированность - свойство программы экономно использовать ресурсы ЭВМ.
Функциональные и нефункциональные требования влияют на оценку качества продукта заказчиком и обычно устанавливаются в техническом задании и другой документации. Но кроме них существуют критерии, которые являются показателем качества не получаемого программного продукта, а качества процесса разработки:
1. скорость реализации функций программного продукта;
2. точное следование плану разработки.
При формализации технического задания заказчик выставляет зачастую очень сжатые сроки на выполнения требований. При изменении функциональных требований в процессе разработки проекта также вы-
ставляются сроки, в которые разработчик опять же должен уложиться. Следовательно, кроме функциональных и нефункциональных требований появляется важное для хода проекта требование к качеству исходного кода, которое оказываются важно как для разработчиков проекта, так и для его заказчика. Качество исходного кода включает в себя следующие критерии [2]:
1. понимаемость, которая включает в себя такие критерии, как информативность, осмысленность, структурированность, сложность, модульность;
2. сопровождаемость - изменяемость, тестируемость, переносимость, распараллеливаемость.
Перечисленные критерии влияют на то, насколько разработчику просто понять исходный код программного обеспечения и сделать в нем необходимые изменения. Соответственно, чем выше показатели сопро-вождаемости и понимаемости, тем выше скорость разработки продукта, меньше времени уходит на изменение функций вслед за изменяющимися требованиями [3].
Изменения требований связаны с уточнением и изменением бизнес -процессов заказчика в ходе реализации проекта, исправлением обнаруженных ошибок, наращиванием выполняемых программным продуктом функций и пр. К тому же во многих методологиях разработки, таких как Agile SCRUM и XP, выделяются этапы, в течение которых заказчик имеет возможность пересмотреть свои требования и приоритеты в зависимости от текущего состояния проекта [4].
К сожалению, по мере усложнения, усовершенствования или исправления ошибок, работа системы ухудшается. Код имеет тенденцию к ухудшению качества при внесении многочисленных изменений [5]. Количество модулей растет линейно с номером версии, но число модулей, затронутых изменениями, растет экспоненциально в зависимости от номера версии. Все исправления имеют тенденцию к разрушению структуры, увеличению энтропии и дезорганизации системы. Все меньше сил тратится на исправление ошибок исходного проекта и все больше - на ликвидацию последствий предыдущих исправлений [6].
Это побуждает многие компании использовать практики контроля качества исходного кода. Наиболее популярные из них:
1. эффективная и зарекомендовавшая себя ревизия кода ("Code review") [7];
2. рефакторинг чужого или собственного кода [5, 8] (процесс изменения внутренней структуры программы, не затрагивающий её внешнего поведения и имеющий целью облегчить понимание её работы). В условиях очных занятий с будущими специалистами по разработке
ПО чаще всего применяется первая из вышеуказанных практик: для
разъяснения ошибочных решений и некачественных участков кода отводятся практические занятия, на которых преподаватель может провести ревизию кода каждого отдельного студента. Кроме того, существует техническая литература, в которой описываются применения ручного рефакторинга для улучшения программного кода.
Однако, в условиях самообразования, нехватки времени практических занятий, либо недостатка знаний ревью кода и рефакторинг могут быть не применимы.
Решением этой проблемы может стать методика автоматизированного улучшения качества программного кода на этапе кодирования (непосредственно во время написания текстов программ). Технически такая система будет реализована в виде экспертной системы, анализирующей программный код и дающей подсказки, либо предлагающей автоматическое улучшение кода с объяснением причин и хода работы.
В настоящее время уже существуют исследования, призванные автоматизировать улучшение качества кода программных систем. Большинство таких исследований используют в качестве средства предварительного анализа программного кода метрическую оценку качества.
Метрики программного кода - система измерений качества программ. Эти измерения могут проводиться на уровне критериев качества программ или на уровне отдельных характеристик качества. В первом случае система измерений позволяет непосредственно сравнивать программы по качеству. При этом сами измерения не могут быть проведены без субъективных оценок свойств программ. Во втором случае измерения характеристик можно выполнить объективно и достоверно, но оценка качества ПО в целом будет связана с субъективной интерпретацией получаемых оценок.
В качестве примеров метрической оценки качества программного кода можно привести метрики, описанные в исследовании Р.Чидамбера и Ф.Кемерера [9], такие как вес методов класса (WMC), глубина дерева наследования (DIT), количество потомков класса (NOC) и др.
Метрическая оценка качества может обеспечить анализ исходного кода и выявление некачественных или сомнительных участков, которые требуют улучшения или хотя бы внимания со стороны разработчика. Но для комплексного подхода к поддержке качества исходного кода на этапе кодирования проекта необходимо непосредственное воздействие либо на разработчика, либо, что более эффективно, на сам исходный код. Если для воздействия на разработчика необходимо только определение некачественных участков кода и оповещение о них, то в качестве воздействия на исходный код можно принять метод автоматизированного улучшения кода, которое позволит приводить реальные примеры улучшения кода начинающему специалисту, а также сэкономить время раз-
работчиков, затрачиваемое на ручной анализ, переосмысление и реорганизацию кода.
Для автоматизированного улучшения проблемных участков кода, выявленных при помощи метрической оценки может использоваться автоматизированный рефакторинг. Современные интегрированные среды разработки программного обеспечения уже имеют функции для упрощения процедуры рефакторинга кода. Пользователь лишь задает целевой участок кода и параметры производимого изменения, и система автоматически редактирует исходный код в соответствии с заданными параметрами. Но для произведения сложных изменений кода всегда необходимо осмысленное вмешательство программиста, поскольку этот процесс слабоформализуем и алгоритма автоматизированного определения параметров рефакторинга не существует.
Для решения этой проблемы возможно использование теории искусственного интеллекта, а в частности - модели экспертных систем с наполняемой базой знаний, которая подходит для плохоформализуемых областей, а также наиболее широко распространена среди моделей ис-куственного интеллекта, что позволит использовать уже существующие наработки.
Чтобы представить знания в области улучшения программного обеспечения необходим язык записи преобразований программного кода для описания действий над кодом, независимо от предметной области и конкретных особенностей языка, а также метод «обезличивания» программного кода для проведения преобразований без учета стиля кодирования и идентификаторов (имен переменных, методов, классов). Одной из технологий, поддерживающих такое «обезличивание» является Eclipse AST (Abstract Syntax Tree). Она входит в интегрированную среду разработки Eclipse и рассматривается как наиболее подходящая для построения инструмента обеспечения качества исходного кода. Кроме того база знаний экспертной системы:
1. должна быть представляема в виде документа, который может прочитать человек;
2. должна иметь возможность пополняться в режиме редактирования;
3. должна иметь возможность пополняться автоматически, отслеживая действия эксперта.
Таким образом база знаний должна включать типичные шаблоны для поиска некачественного кода, в том числе с указанием значений метрик (антипаттерны), преобразования исходного кода для этих шаблонов (рефакторинги) и целевые шаблоны качественного кода (паттерны).
В качестве дополнительного метода контроля эффективности работы такой экспертной системы и получаемыми в этом случае результатами может, опять же, использоваться метрическая оценка качества.
Методология автоматизированного улучшения качества программного кода, полученная из перечисленных выше методов, может служить следующим целям в обучении и практике разработки программного обеспечения:
1. сопровождение процесса обучения программированию и повышение квалификации программистов;
2. обеспечение максимальной независимости качества программ от личностных факторов разработчиков;
3. повышение производительности труда программистов и сокращение сроков разработки программ на производстве.
Поскольку на уровне метрической оценки и преобразований исходного кода возможно использование абстрактного представления обрабатываемых операторов и конструкций языков программирования, и поскольку языки программирования, классифицируемые одной парадигмой имеют похожие конструкции и применяют одинаковые модели работы с потоками управления и данных, то возможно построение унифицированных баз знаний для отдельных парадигм, которые можно будет использовать для обеспечения системой поддержки качества исходного кода новых языков программирования, еще не обеспеченных специализированными средами разработки.
Литература
1. Abran, A. Guide to the Software Engineering Body of Knowledge [Text] / Alain Abran, James W. Moore, Pierre Bourque, Robert Dupuis. - IEEE Computer Society, 2001. - 205 p.
2. Саркисян, А. А. Повышение качества программ на основе автоматизированных методов [Текст] / А. А. Саркисян. - М. i Радио и связь, 1991. - 156 с.
3. Что такое качество программного обеспечения? [Электронный ресурс] // СМ-Консалт. 2008. Режим доступа! http://cmcons.com/articles/standarty__kachestvo/chto_takoe_kachestvo_program mnogo_obespechenija/ (дата обращения: 04.02.2011).
4. Бек, К. Экстремальное программирование [Текст] / Кент Бек. - СПб i Питер, 2002. - 224 с.
5. Мартин, Р. Чистый код i создание, анализ и рефакторинг [Текст] / Роберт Мартин. - М. i Питер, 2010. - 464 с.
6. Брукс, Ф. Мифический человеко-месяц или как создаются программные системы [Текст] / Фредерик Брукс. - Пер. с англ. - СПб. i Символ-Плюс, 2001. - 304 с.
7. Brian, P. Twenty Reasons To Do Code Reviews [Electronic resource] / Brian St. Pierre // The Daily Build. 2008. URL: http://blog.bstpierre.org/twenty-reasons-to-do-code-reviews (access date: 04.02.2011)
8. Фаулер, М. Рефакторинг : улучшение существующего кода [Текст] / Мартин Фаулер. - СПб. : Символ-Плюс, 2003. - 430 с.
9. Chidamber, R. A Metrics Suite for Object Oriented Design [Text] / Shyam R. Chidamber and Chris F. Kemerer. - IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, 1994.
