Объектная модель помогает удержать целостность продукта, когда один и тот же предмет появляется в разных процессах и экранах. Команда сначала описывает сущности, свойства и отношения, а затем проектирует представления и действия. основание Для темы «как проектировать объектную модель интерфейса» артефакт «объектная карта интерфейса» связывает компонент «Сущность» с этапом «Назвать основные сущности»; неподтверждённые рекомендации остаются редакционными гипотезами темы «как проектировать объектную модель интерфейса».
Задача и проверяемые основания
Обзор NN/g связывает информационную архитектуру с организацией, навигацией и поиском, которые опираются на устойчивую структуру содержания. основание
W3C рекомендует использовать логические регионы и заголовки, отражающие отношения частей страницы. основание
USWDS описывает компоненты как повторно используемые единицы интерфейса с определённым назначением и поведением. основание
GOV.UK рассматривает структурирование сервиса и применение паттернов как часть проектирования цифрового продукта. основание
В артефакте «объектная карта интерфейса» вопрос «Остаётся ли сущность узнаваемой в разных контекстах?» хранится отдельно от решения «Определить идентичность» и ограничения «объектная модель не заменяет сценарии».
Рабочая модель
Сущность. В теме «как проектировать объектную модель интерфейса» этот элемент означает предмет, узнаваемый независимо от конкретного экрана или шага процесса. В артефакте «объектная карта интерфейса» связь с компонентом «Идентичность» проверяют сценарием темы «как проектировать объектную модель интерфейса».
Идентичность. В теме «как проектировать объектную модель интерфейса» этот элемент означает признаки, позволяющие отличить объект и открыть стабильную ссылку. В артефакте «объектная карта интерфейса» связь с компонентом «Свойства» проверяют сценарием темы «как проектировать объектную модель интерфейса».
Свойства. В теме «как проектировать объектную модель интерфейса» этот элемент означает данные объекта, разделённые на обязательные, вычисляемые, исторические и ролевые. В артефакте «объектная карта интерфейса» связь с компонентом «Отношения» проверяют сценарием темы «как проектировать объектную модель интерфейса».
Отношения. В теме «как проектировать объектную модель интерфейса» этот элемент означает связи с владельцами, участниками, дочерними элементами и источниками данных. В артефакте «объектная карта интерфейса» связь с компонентом «Состояния» проверяют сценарием темы «как проектировать объектную модель интерфейса».
Состояния. В теме «как проектировать объектную модель интерфейса» этот элемент означает этапы жизненного цикла с правилами перехода и видимыми последствиями. В артефакте «объектная карта интерфейса» связь с компонентом «Действия» проверяют сценарием темы «как проектировать объектную модель интерфейса».
Действия. В теме «как проектировать объектную модель интерфейса» этот элемент означает операции над объектом, доступные при подходящей роли, состоянии и данных. В артефакте «объектная карта интерфейса» связь с компонентом «Сущность» проверяют сценарием темы «как проектировать объектную модель интерфейса».
Порядок проектирования
1. Назвать основные сущности. Команда применяет шаг к теме «как проектировать объектную модель интерфейса»: выписать существительные из пользовательских задач и убрать технические контейнеры. Результат уточняет компонент «Сущность», а спорные варианты темы «как проектировать объектную модель интерфейса» остаются в артефакте «объектная карта интерфейса».
2. Определить идентичность. Команда применяет шаг к теме «как проектировать объектную модель интерфейса»: зафиксировать идентификатор, краткое имя и признаки различения похожих объектов. Результат уточняет компонент «Идентичность», а спорные варианты темы «как проектировать объектную модель интерфейса» остаются в артефакте «объектная карта интерфейса».
3. Развести свойства и отношения. Команда применяет шаг к теме «как проектировать объектную модель интерфейса»: не копировать данные связанной сущности туда, где достаточно ссылки. Результат уточняет компонент «Свойства», а спорные варианты темы «как проектировать объектную модель интерфейса» остаются в артефакте «объектная карта интерфейса».
4. Описать жизненный цикл. Команда применяет шаг к теме «как проектировать объектную модель интерфейса»: сопоставить состояния с событиями, действиями и историей изменений. Результат уточняет компонент «Отношения», а спорные варианты темы «как проектировать объектную модель интерфейса» остаются в артефакте «объектная карта интерфейса».
5. Собрать карточки объектов. Команда применяет шаг к теме «как проектировать объектную модель интерфейса»: создать базовое представление, узнаваемое в разных разделах. Результат уточняет компонент «Состояния», а спорные варианты темы «как проектировать объектную модель интерфейса» остаются в артефакте «объектная карта интерфейса».
6. Проверить сквозные задачи. Команда применяет шаг к теме «как проектировать объектную модель интерфейса»: пройти сценарии перехода между сущностями и возврата назад. Результат уточняет компонент «Действия», а спорные варианты темы «как проектировать объектную модель интерфейса» остаются в артефакте «объектная карта интерфейса».
Практический пример
Редакционный пример: в системе найма кандидат отображался как строка в вакансии, участник интервью и запись в отчёте. Каждое представление хранило собственный статус, поэтому данные расходились. Команда выделила объект «Кандидат», отношения с вакансиями и отдельные объекты интервью. Статус отбора стал вычисляться из этапов конкретной заявки, а история осталась на карточке кандидата. Интерфейс сохранил специализированные списки, но они начали ссылаться на одну модель.
Пример показывает, как «объектная карта интерфейса» помогает раньше обнаружить ошибку «принимать страницу за предметную сущность» и проверить критерий «каждая сущность имеет устойчивую идентичность» для темы «как проектировать объектную модель интерфейса».
Контрольные вопросы
- Остаётся ли сущность узнаваемой в разных контекстах? Ответ фиксируют в артефакте «объектная карта интерфейса» и связывают с компонентом «Сущность»; мнение отмечают как допущение темы «как проектировать объектную модель интерфейса».
- Какие свойства принадлежат отношению, а не объекту? Ответ фиксируют в артефакте «объектная карта интерфейса» и связывают с компонентом «Идентичность»; мнение отмечают как допущение темы «как проектировать объектную модель интерфейса».
- Может ли объект участвовать в нескольких процессах? Ответ фиксируют в артефакте «объектная карта интерфейса» и связывают с компонентом «Свойства»; мнение отмечают как допущение темы «как проектировать объектную модель интерфейса».
- Где пользователь увидит историю изменения состояния? Ответ фиксируют в артефакте «объектная карта интерфейса» и связывают с компонентом «Отношения»; мнение отмечают как допущение темы «как проектировать объектную модель интерфейса».
Типовые ошибки
- Принимать страницу за предметную сущность. В артефакте «объектная карта интерфейса» для темы «как проектировать объектную модель интерфейса» ошибка искажает компонент «Идентичность»; рядом записывают последствие, обнаружение и исправление.
- Дублировать свойства в каждом рабочем представлении. В артефакте «объектная карта интерфейса» для темы «как проектировать объектную модель интерфейса» ошибка искажает компонент «Свойства»; рядом записывают последствие, обнаружение и исправление.
- Создавать статус без правил перехода. В артефакте «объектная карта интерфейса» для темы «как проектировать объектную модель интерфейса» ошибка искажает компонент «Отношения»; рядом записывают последствие, обнаружение и исправление.
- Смешивать глобальные и контекстные действия. В артефакте «объектная карта интерфейса» для темы «как проектировать объектную модель интерфейса» ошибка искажает компонент «Состояния»; рядом записывают последствие, обнаружение и исправление.
- Скрывать отношения за текстовыми полями. В артефакте «объектная карта интерфейса» для темы «как проектировать объектную модель интерфейса» ошибка искажает компонент «Действия»; рядом записывают последствие, обнаружение и исправление.
Критерии качества
- Каждая сущность имеет устойчивую идентичность. В артефакте «объектная карта интерфейса» критерий темы «как проектировать объектную модель интерфейса» проверяют после шага «Назвать основные сущности»; рядом сохраняют результат и ответственного.
- Отношения моделируются явно. В артефакте «объектная карта интерфейса» критерий темы «как проектировать объектную модель интерфейса» проверяют после шага «Определить идентичность»; рядом сохраняют результат и ответственного.
- Состояния не противоречат друг другу. В артефакте «объектная карта интерфейса» критерий темы «как проектировать объектную модель интерфейса» проверяют после шага «Развести свойства и отношения»; рядом сохраняют результат и ответственного.
- Действия зависят от роли и контекста. В артефакте «объектная карта интерфейса» критерий темы «как проектировать объектную модель интерфейса» проверяют после шага «Описать жизненный цикл»; рядом сохраняют результат и ответственного.
- Карточки используют общие правила. В артефакте «объектная карта интерфейса» критерий темы «как проектировать объектную модель интерфейса» проверяют после шага «Собрать карточки объектов»; рядом сохраняют результат и ответственного.
- История изменений доступна для проверки. В артефакте «объектная карта интерфейса» критерий темы «как проектировать объектную модель интерфейса» проверяют после шага «Проверить сквозные задачи»; рядом сохраняют результат и ответственного.
Ограничения применимости
- Объектная модель не заменяет сценарии. Ограничение сужает вывод по теме «как проектировать объектную модель интерфейса» и требует повторно задать вопрос «Остаётся ли сущность узнаваемой в разных контекстах?»; границу решения сохраняют в артефакте «объектная карта интерфейса».
- Некоторые процессы удобнее показывать как последовательность. Ограничение сужает вывод по теме «как проектировать объектную модель интерфейса» и требует повторно задать вопрос «Какие свойства принадлежат отношению, а не объекту?»; границу решения сохраняют в артефакте «объектная карта интерфейса».
- Наследуемая база может ограничивать связи. Ограничение сужает вывод по теме «как проектировать объектную модель интерфейса» и требует повторно задать вопрос «Может ли объект участвовать в нескольких процессах?»; границу решения сохраняют в артефакте «объектная карта интерфейса».
- Унификация не должна стирать профессиональный контекст. Ограничение сужает вывод по теме «как проектировать объектную модель интерфейса» и требует повторно задать вопрос «Где пользователь увидит историю изменения состояния?»; границу решения сохраняют в артефакте «объектная карта интерфейса».
- Слишком абстрактные сущности ухудшают язык продукта. Ограничение сужает вывод по теме «как проектировать объектную модель интерфейса» и требует повторно задать вопрос «Остаётся ли сущность узнаваемой в разных контекстах?»; границу решения сохраняют в артефакте «объектная карта интерфейса».
Вывод
Для темы «как проектировать объектную модель интерфейса» команда связывает компонент «Сущность» с этапом «Назвать основные сущности», проверяет критерий «каждая сущность имеет устойчивую идентичность» и учитывает ограничение «объектная модель не заменяет сценарии». Артефакт «объектная карта интерфейса» сохраняет основания выбора и позволяет пересмотреть решение после новых наблюдений.
