Sunny Wong, Yuanfang Cai, Miryung Kim, and Michael Dalton. 2011. Detecting software modularity violations. In Proceedings of the 33rd International Conference on Software Engineering (ICSE '11). ACM, New York, NY, USA, 411-420. DOI: https://doi.org/10.1145/1985793.1985850

Изложение в pdf – Detecting Software Modularity Violations

Главная задача модульности – обеспечить независимое взаимодействие между различными частами внутри ПО. Однако, в процессе реальной разработки некторые модули могут содержать нежелательные зависимости из-за небрежной реализации. В данной работе предлагается способ отследить нежелательные зависимости – CLIO (Clio – муза истории из греческой мифологии). CLIO отслеживает как взаимодействуют компоненты с помощью истории правок в репозитории и сравнивает с тем, как они на самом деле должны взаимодействовать. Если два компонента регулярно влекут за собой изменения друг друга, то скорее всего в этом месте есть нарушение модульной структуры. CLIO состоит из трех компонент: первый компонент вычисляет структурное сопряжение (structural coupling) – как компоненты должны менять друг друга, второй компонент извлекает change coupling – как компоненты на самом деле меняют друг друга, третий компонент – сравнивает результат первых двух и находит нарушения модульности.

Предположим, что некоторое количество запросов модификации (MRs) зафиксированы при переходе проекта от версии <latex>{n}</latex> к версии <latex>n+1</latex>. Рисунок 1 показывает как проектный менеджер может использовать CLIO для определения изменений, которые нарушают модульную структуру.

CLIO имеет структуру плагина и разделен на три основных компонента, вместе с сопутствующими инструментами. Первый основной компонент, dr-predict, вычисляет множество файлов, которые наиболее вероятно будут изменены вместе согласно designed modular structure. Второй основной компонент, logic-predict, вычисляет компоненты, которые наиболее вероятно будут изменены вместе согласно change coupling, полученном через плагин extract. Плагин extract записывает множество файлов, измененных вместе в истории изменений, и сохраняет частоту и уровень доверия для каждого change coupling в базу данных. Для решения <latex>{S}</latex> каждого MR, плагин logic-predict выбирает подмножество <latex>{S}</latex> которое разделяет самый высокий change coupling с другими файлами согласно базе данных. Обозначим это множество файлов за <latex>{\sigma}</latex>. logic-predict предсказывает величину изменения <latex>\sigma</latex> следующим образом: если соответствующие значения частоты и уверенности выше некоторых пороговых. Подробнее показано на Рис. 1: FileSet B. Плагин logic-predict разделяет <latex>\sigma</latex> с dr-predict так что оба плагина могут вычислить изменение для одного множества файлов. Изменение <latex>\sigma</latex>, вычисленное через dr-predict, обозначено за FileSet A на Рис. 1. Теперь, когда есть A и B, а также MR-решение <latex>{S}</latex>, detect вычисляет <latex>D=(B \cap S) \setminus A</latex> (множество расхождений). Это множество <latex>{D}</latex> возвращается в качестве искомых нарушений модульности.
Так как результаты сильно зависят от выбранных пороговых значений, предлагается автоматически выбирать пороги для лучшей точности исходя из F1-метрики. Плагин dr-predict варьирует пороговое значение весов <latex>th_d</latex> от <latex>{0}</latex> до <latex>{0.95}</latex> с шагом <latex>0.05</latex> – находится значение, максимизирующее F1-метрику. Аналогично, logic-predict варьирует частотный порог и порог уровня доверия для максимизации F1. После рассчета оптимальных порогов и получения точных предсказаний от dr-predict и logic-predict, плагин detect вычисляет множество расхождений и находит расхождения, которые повторяются во всех версиях ПО через алгоритм frequent-pattern mining. Полученные повторяющиеся расхождения называются модульными нарушениями.

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

Для оценки и тестирования метода были выбраны Hadoop Common и Eclipse Java Development Tools (JDT). Найденные CLIO нарушения проверялись путем проверки будущих версий репозитория. Если в будущих версиях в этом месте в самом деле был рефакторинг или серьезные изменения в структуре, это нарушение помечалось как подтвержденное. Использовались как автоматические, так и ручные проверки для подтверждения найденных нарушений.

Clio было найдено 231 нарушений которые встречаются как минимум дважды за 5 релизов Hadoop, из которых 152 (66%) были подтверждены.

Для Eclipse JDT, Clio нашел 399 нарушений, 161 из которых были подтверждены (40% точность).

Итоговая кривая точность-версия для Hadoop изображена на рисунке ниже

В итоге с помощью Clio удалось найти и подтвердить сотни нарушений. Результаты также показывают, что найденные нарушения проявляют различные признаки плохого дизайна, что показывает превосходство Clio над методами “bad-code smell”, которые находят только предопределенный набор признаков плохого дизайна.

1. G. Antoniol, G. Canfora, G. Casazza, and A. D. Lucia. Identifying the starting impact set of a maintenance request. In Proc. 4th CSMR, pages 227–230, Mar. 2000.
2. C. Y. Baldwin and K. B. Clark. Design Rules, Vol. 1: The Power of Modularity. MIT Press, 2000.
3. C. Bird, A. Bachmann, E. Aune, J. Duffy, A. Bernstein, V. Filkov, and P. Devanbu. Fair and balanced? bias in bug-fix datasets. In Proc. 17th FSE, pages 121–130, Aug. 2009.
4. Y. Cai. Modularity in Design: Formal Modeling and Automated Analysis. PhD thesis, University of Virginia, Aug. 2006.
5. Y. Cai and K. J. Sullivan. Modularity analysis of logical design models. In Proc. 21st ASE, pages 91–102, Sept. 2006.
6. M. Cataldo, A. Mockus, J. A. Roberts, and J. D. Herbsleb. Software dependencies, work dependencies, and their impact on failures. TSE, 35(6):864–878, July 2009.