Какие алгоритмы могут анализировать зависимости вызовов для деления библиотеки? - PullRequest
3 голосов
/ 30 ноября 2011

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

Простой пример, в нем четыре функции: альфа, бета, гамма и дельта.

  • бета и гамма оба вызывают дельту.
  • module1 вызывает альфа и бета.
  • module2 вызывает гамму.
  • module3 вызывает альфа, бета и гамму.

Выходные данныеалгоритм может быть таким:

  • LibA содержит (альфа, бета)
  • LibB содержит (гамма)
  • LibC содержит (дельта)
  • зависит от модуля 1на LibA
  • module2 зависит от LibB
  • module3 зависит от LibA и LibB
  • LibA зависит от LibC
  • LibB зависит от LibC

то есть он находит наиболее мелкозернистый раздел Lib * со следующим свойством

Для всех X, если LibX каким-либо образом разделен на LibY и LibZ, то все модули / библиотеки, которые зависятна LibY также зависят от LibZ и наоборот.

Есть ли стандартное решение для этого

1 Ответ

1 голос
/ 30 ноября 2011

(Это та же проблема, что и у людей с заголовочными файлами в программах на C и C ++.)

Это не просто "вызовы", которые создают зависимости;это любой вид ссылки на переменную-член, статическую переменную или даже определение константы.

По сути, вам нужно обнаружить все мелкие зависимости (для этого обычно требуется инструмент анализа, подобный компилятору, который читает код и обнаруживает такие зависимости между объявленными элементами языка (объявлениями, полями, методами,классы, пакеты, если вы Java-центричный и т. д.) и другие языковые элементы, использующие семантику языка, на котором написаны библиотеки (такой анализ, вероятно, консервативен). Это суть дает вам гигантский графузлы - это элементы языка, а дуги - «использует».

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

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

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

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

Наш набор инструментов для реинжиниринга программного обеспечения DMS с его многочисленными языковыми интерфейсами - этовероятно, хороший фундамент для проведения такой реорганизации библиотеки.Мы рассматривали возможность сделать это для C и C ++ [именно поэтому у меня есть этот ответ], но это большая задача даже для нас.Мы хотели бы получить дополнительную серьезную мотивацию!

...