Правило 7. Постройте концептуальную модель

В этом посте я хочу поговорить об очень хорошо известной и в то же время мало понятной теме — концептуальной модели данных (далее КМД).

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

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

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

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

Эти характеристики могут интересовать инженера-испытателя или пожарного инспектора, но поскольку ни тот, ни другой не являются целевой аудиторией, модель упрощается и эти характеристики игнорируются.

Концептуальная модель данных (КМД) поднимается ещё выше в уровне абстракции и исключает ещё больше характеристик, а порой игнорирует множество объектов.

Такое «варварство» по отношению к объектной модели часто встречает агрессивную реакцию в ИТ: «Зачем делать менее понятную абстракцию, если можно посмотреть в базу объектов?»

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

Откройте SID для телекома, BIAN для финтеха или FHIR для медицины, и вы поймёте, о чём я.

Однако потребность в концептуальной модели данных (КМД) возникает даже у программистов, тех самых людей, кто «час назад» говорил: «Зачем нам КМД, когда можно открыть базу и посмотреть?»

КМД — это один из важных инструментов в ИТ, который, как и любой другой инструмент, при правильном его использовании приносит пользу и облегчает жизнь, а при неправильном создаёт лишнюю работу и раздражает.

В этом посте я постараюсь рассказать, зачем нужна КМД и каким критериям она должна отвечать, чтобы приносить пользу, а не вред.

Дон Норман описывает КМД следующим образом: «Это объяснение (как правило, сильно упрощённое) того, как что-то работает».

Хорошая КМД даёт следующие преимущества:

Проблема многих теоретически выверенных КМД заключается в том, что они могут быть сложными для понимания и использования. Некоторые КМД включают в себя элементы, назначение которых не сразу понятно, и неясно, как их применять.

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

Но что делать с дверью на нижней картинке? Более естественным кажется, что нужно нажать на углубление, чтобы получить результат. Однако непонятно, куда именно нужно нажать: то ли в районе небольшого прямоугольника, то ли с противоположной стороны. Ручки двери появятся из кузова сами, когда автомобиль будет разблокирован.

Этот пример показывает, как важно сделать КМД понятной и удобной для использования. Если пользователи не могут понять, как работает система, или если им приходится тратить много времени на изучение документации, это может привести к снижению эффективности работы и увеличению затрат.

Теперь ручки дверей автомобиля явно демонстрируют свои возможности: их можно потянуть, чтобы открыть дверь. Возникает вопрос: почему нельзя было сделать так, чтобы дверь открывалась автоматически при нажатии на ручку?

Подобные вопросы возникают и при работе с моделями ИТ-систем. Например, когда мы видим объект с названием «Задание», у нас сразу возникают ассоциации с определённым процессом: у каждого задания есть исполнитель, срок выполнения и ожидаемый результат. Задания выдаются ради достижения полезного результата.

Таким образом, название «Задание» сразу вызывает определённые ожидания относительно его содержания и целей. Это помогает нам лучше понимать структуру и логику работы системы, а также упрощает взаимодействие с ней.

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

Если срок на задании истечёт, то выполненные действия не будут засчитаны. Чтобы продлить срок действия задания, необходимо выполнять целевые действия.

В такой ситуации я столкнулся с тем, что задание, используемое таким образом, не укладывается в мою концептуальную модель. Такое задание предоставляет совсем другие возможности, которые должны быть у него. Этот объект правильно было бы назвать «Продуктом».

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

Ценность КМД не ограничивается только хорошим описанием входящих в неё объектов. КМД должна давать чёткое представление о том, как работает система в целом, исключая при этом лишние детали.

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

Однако реализован газ по-разному. В машине функция газа реализована в педали на полу, на мотоцикле функция газа реализована в подвижной ручке на руле.

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

Автомобиль находится в стабильном состоянии как в движении, так и стоя без движения. Водитель не занят стабилизацией положения автомобиля, поэтому может спокойно сидеть в кресле и нажимать на педаль газа.

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

Эта унификация позволяет быстрее осваивать оба вида техники, без дополнительных усилий по адаптации модели.

Перенос управления газом в ручку на руле мотоцикла потребовал адаптации модели. Фразы «поддай газа» или «убери газ» хорошо ложатся в концептуальную модель данных (КМД) автомобиля. Слово «поддай» ассоциируется с пинком, что, в свою очередь, стимулирует посильнее топнуть по педали газа, а фраза «убери ногу с педали газа» напрямую соотносится с КМД и действием в реальном мире. Однако такая КМД плохо подходит к управлению мотоциклом с его крутящейся ручкой газа.

Поэтому в управлении мотоциклом используется другая КМД: «открыть газ» / «закрыть газ». Поворот ручки на себя открывает заслонку, и мотоцикл начинает ускоряться, в то время как поворот её в другую сторону возвращает ручку в исходное положение — закрытой заслонки.

Такая КМД гораздо лучше отвечает сути происходящего и не вызывает усилий по интерпретации, то есть КМД даёт понимание о работе системы.

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

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

Детали работы двигателя для водителя должны скрываться на нижних уровнях — в сервисных мануалах. Говоря ИТ-шным языком, в описаниях таблиц и кодовой базе.

Крайне важно освобождать концептуальную модель данных (КМД) от лишних деталей, оставляя только значимые объекты для понимания работы системы.

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

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

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

Однако попытка применить такой подход к автомобилю сразу же покажет значение выражения «ведро с болтами». В реальном мире создание подобной системы было бы крайне сложным и неэффективным процессом.

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

Всё это справедливо для физической реализации. При проектировании структуры компонентов системы, структур таблиц и API-контрактов нужно руководствоваться техническими соображениями и нефункциональными требованиями.

Однако на уровне концептуальной модели данных (КМД) мы можем находиться на более высоком уровне абстракции и повторять с её помощью реальный мир, то есть строить «Проекции» реальных объектов на объекты системы.

Когда мы заходим в интернет-магазин и выбираем товары, которые хотим купить, мы, как правило, складываем их в корзину. Корзина повторяет объект реального мира в настоящем магазине, куда мы складываем товары, пока перемещаемся по магазину, а затем совершаем покупку.

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

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

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

Проекция концептуальной модели данных (КМД) является критически важной при проектировании пользовательского интерфейса (UI). Если модель реализована неправильно или элементы UI не соотносятся с КМД, то и заложенная бизнес-логика будет работать неправильно ввиду непонимания этой логики конечным потребителем.

Если пользователь хотел посмотреть несколько товаров, сравнить их между собой и затем приобрести понравившийся, сообщение «создан Заказ №ХХХХХХХ» может сбить с толку или вообще привести к бегству покупателя с сайта.