Объектная модель при проектировании интерфейсов

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

Описание методики

UML (англ. Unified Modeling Language — унифицированный язык моделирования) — язык графического описания для объектного моделирования в области разработки программного обеспечения, для моделирования бизнес-процессов, системного проектирования и отображения организационных структур (определение из Википедии).

То есть по сути UML можно использовать для описания любых систем и процессов.

Различают следующие виды UML диаграмм.

Структурные:

• Диаграмма классов
• Диаграмма компонентов
• Диаграмма композитной/составной структуры
• Диаграмма кооперации (UML2.0)
• Диаграмма развёртывания
• Диаграмма объектов
• Диаграмма пакетов
• Диаграмма профилей (UML2.2)

Диаграммы поведения:

• Диаграмма деятельности
• Диаграмма состояний
• Диаграмма вариантов использования

Диаграммы взаимодействия:

• Диаграмма коммуникации (UML2.0) / Диаграмма кооперации (UML1.x)
• Диаграмма обзора взаимодействия (UML2.0)
• Диаграмма последовательности
• Диаграмма синхронизации (UML2.0)

Подробнее о UML диаграммах можно узнать из, например, этого видео и статьи.

Адаптация

Рассмотрев теорию, мы в B2B-Center выработали методику, подходящую для наших целей, а именно взяли диаграмму классов и адаптировали. В классической UML-диаграмме есть описание межклассовых отношений (ассоциация, наследование, реализация, зависимость, агрегация, композиция). Применив это к нашим целям, мы поняли, что для дизайна это не имеет большого значения и мы попробуем составлять схему без описания отношений. Но из-за отказа от части классической методологии мы не можем сказать, что у нас диаграмма классов, поэтому употребляем слово «адаптированная». Далее выбрали перспективу, в которой будем описывать.

Диаграмма классов бывает в трёх перспективах:

• Концептуальная. Обозначает только класс, без наполнения.

• Спецификационная. Описывает модель в предполагаемом виде, а не в том, как это реализовано в коде. Именно этот уровень детализации нам подходит.

• Имплементационная. То, как реализовано в коде. Мы решили, что это избыточно, так как требует постоянной актуализации разработчиками.

Когда применяем

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

Процесс

Внутри команды мы договорились о следующей легенде:

Для составления схемы используем шаблон в Miro, который так и называется «UML диаграмма».

На выходе получаем такой результат:

Списки и вложенности могут быть вынесены отдельно, а в диаграмме мы даем ссылку на них.

Частые вопросы и сложности

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

Результат и дальнейшее использование

В результате мы получили модель, которая отображает взаимосвязь и состав сущностей. Основная сложность при объектном проектировании — поддержка актуальности системы. Даже в случае, когда есть время на детальное проектирование, адекватные сроки разработки, многое зависит от личной увлеченности и ответственности дизайнера. Очень легко спустить «на тормозах» и не актуализировать схему.