Как UML мешает визуализации структуры кода Java

Человеческий мозг очень хорошо воспринимает изображения, именно поэтому графики и диаграммы позволяют быстро понять структуру. Java код обладает структурой, в которой нам, программистам, нужно разобраться. Но главный язык визуального программирования, который у нас есть - это UML, который был создан для диаграмм, создаваемых вручную.

Зачастую он приводит к беспорядочным и неразборчивым результатам, особенно в случае обратного процесса - создании диаграмм по существующему исходному коду. Что бы вы изменили в UML, чтобы изображения позволяли лучше понять код?

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

Нейтральность языка

Во время задумки UML между новыми объектно-ориентированными языками было много общего. Но наличие разных языков программирования вместо одного стандартного объясняется изменениями представления о том, что делает язык эффективным и выразительным.

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

Построение диаграмм вручную

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

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

Символы

В языке UML символ видимости "+" обозначает атрибут с областью видимости типа общедоступный, символ "-" обозначает атрибут с областью видимости типа закрытый и, наконец,  символ "#" обозначает атрибут с областью видимости типа защищенный.

Если бы такая система обозначений была интуитивно-понятной, создатели IDE позаимствовали бы ее. Однако, причина выбора подобных символов в UML заключается, опять-таки, в простоте рисования вручную. И с точки зрения эстетики они проигрывают, особенно, если просмотреть список членов класса, выделенных тем же шрифтом что и имена членов класса. Кроме того, IDE используют богатый набор символов, обозначающих не только доступность.

Ассоциации между классами

Чтобы разобраться в понятиях "композиция", "агрегирование" и "ассоциация", программистам Java, которые привыкли организовывать ссылки между классами с помощью одного механизма (полей класса), нужно больше времени. Большинство способно быстро уловить разницу между ними тремя, как только поймут роль владения и жизненного цикла объекта в определении типа ассоциации.

С другой стороны, композиция представляет проблему лишь при отсутствии автоматизированной сборки мусора: разрушение владельца влечет за собой разрушение его частей. Агрегирование и композиция в Java связаны с соглашениями по именованию, внутренними классами, структурой пакетов и шаблонами проектирования.

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

Мощность множества

С точки зрения статического анализа структуры важную роль играет то, является ли ссылка в коде ссылкой на один объект или на множество. Java представляет это как поле, которое ссылается на именованное поле, указывающее на единственный экземпляр заданного типа, или на массив экземпляров заданного типа. Иными словами, возможны два типа отношений: один-к-одному или один-ко-многим. И никаких других.

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

Соглашения Java

Java разработчики уделяют огромное внимание соглашениям, которые упрощают чтение кода и понимание структуры. В диаграммах UML этого нет.

• Соглашения по именованию свойств bean-компонентов - наличие get/set методов соответствует ассоциации с установленным или полученным типом.
• Проверяемые исключения - как бы вы к ним не относились, они - составляющий элемент языка. Не помешает принимать их во внимание, поскольку они входят в сигнатуру метода
• Сериализация - спросите любого, кто выполнял сериализацию графы Java-объектов и услышите, как важно контролировать границы процесса сериализации.
• Коллекции - основа моделирования объектов, представляющая преимущественно тип отношений "один-ко-многим", но по сути не рассматривается как таковая языком UML.

Визуальное представление кода не имеет существенной ценности для Java разработчиков, когда диаграммы не учитывают конструкции и соглашения языка программирования.

Присваивание имен и меток ассоциациям

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

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

Набор функций, как у бумажного варианта

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

Диаграммы UML, являющиеся результатом обратного анализа, обладают ограниченными функциями, как будто они строятся на бумаге.

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

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

источник