Здравствуйте, BB, Вы писали:

BB>Собственно, вопрос: можно ли по этому представлению достаточно надежно оценить качество библиотеки с точки зрения легкости поддержки и расширения?

К сожалению, никакого волшебства в UML представлении нет. А в особенности в reverse engineered UML модели. Проблема в том, что из кода вытаскивается только статическая диаграмма классов. Информация о поведении системы (жизненном цикле объектов, потоках данных, возможных состояниях системы, типовых сценариях взаимодействия объектов) в ней не содержится. Так что первая проблема состоит в том, что этой информации часто просто _недостаточно_ чтобы понять как работает система. Хотя если вам все-таки это удалось, значит дизайн действительно скорее всего неплох (но это еще не значит, что библиотеку будет легко расширять в контексте _Ваших_ задач).

Также, по формальным признакам (степень "ромбовидности" иерархии наследования, процент "виртуальности" функций, и т. д.) _вообще_говоря_ нельзя выдать заключение о легкости поддержки продукта в будущем и качестве дизайна, а то было-бы все слишком просто: сокращаем глубину наследования, запрещаем множественное наследование, и, — вуаля! — получаем замечательную библиотеку! К сожалению, придется думать или полагаться на экспертные заключения. Наличие reverse engineered диаграммы классов чуть упрощает дело (не придется строить ее руками), хотя на больших и сложных системах автоматически построенные диаграммы совершенно бесполезны — на них слишком много ненужных деталей.

Резюме и ответ на Ваш вопрос: Наличие reverse engineering UML модели _само_по_себе_ не помогает (но и не мешает) оценить качество дизайна. Но одного этого представления во многих случаях не достаточно, чтобы выдать интересуещее Вас заключение (придется работать с исходным кодом/читать документацию и думать).