Обратное проектирование (reverse engineering) – это процесс трансформации кода в модель. Обратное проектирование, как это ни парадоксально, порождает избыток информации, часть которой представлена на более низком уровне детализации, чем нужно для построения удобной модели. В то же время обратное проектирование неполно: при прямом проектировании модели в код происходит потеря информации, поэтому невозможно точно восстановить модель из кода, если только инструмент, который мы будем использовать, не кодирует информацию в виде комментариев к исходному коду, выходящих за пределы семантики языка реализации.

Чтобы осуществить обратное проектирование диаграммы классов, необходимо:

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

Заканчивая обсуждение диаграмм классов UML, подведем некоторые итоги. Создавая диаграммы классов на UML, мы будем помнить, что каждая из них – это лишь графическое изображение статического представления дизайна системы. Ни одна диаграмма классов не обязана включать все, что касается представления дизайна системы. Однако диаграммы классов в совокупности сообщают разработчику или другому читателю полную информацию, необходимую для статического представления системы. Таким образом, хорошо структурированная диаграмма классов:

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

Когда мы разрабатываем диаграмму классов, то:

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