От объекта к системе

Часть I. Что такое объект?

Глава 1. Почему компьютер не понимает, что такое автомобиль?

1.1. Очевидность, которая обманчива

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

Попробуйте провести мысленный эксперимент. Закройте глаза и представьте автомобиль. Скорее всего, перед вами возникнет вполне определённый образ — легковой, грузовой, спортивный. Но, почти наверняка вы не представляете одновременно тысячи деталей, из которых он состоит. Наше мышление сначала выделяет объект целиком, а уже затем, если это необходимо, рассматривает его составные части. Именно поэтому ребёнок узнаёт автомобиль задолго до того, как узнаёт слово «двигатель».

Теперь зададим тот же вопрос компьютеру. Ответ будет неожиданным: компьютер не знает, что такое автомобиль. Для него не существует автомобиля. Не существует двигателя. Не существует колес.

До тех пор, пока человек не построит соответствующую модель, компьютер оперирует только данными. Сами по себе эти данные не содержат того смысла, который человек вкладывает в слово «автомобиль».

1.2. Что видит компьютер

Представим, что в базе данных появилась запись:

id = 12345
name = "Автомобиль"
weight = 1450
engine_power = 150

Для человека это очевидно: перед нами автомобиль. Для компьютера — нет.

Для него это набор значений, связанных определёнными правилами хранения. Число 1450 не знает, что это масса. Число 150 не знает, что это мощность двигателя. Строка "Автомобиль" сама по себе не создаёт понятия автомобиля.Смысл появляется только потому, что человек заранее определил:

1450 → масса
150  → мощность двигателя

И определил, что совокупность этих данных относится к некоторому объекту, который называется автомобилем. То есть компьютер не обнаруживает объект. Человек сообщает компьютеру, что считать объектом. Это принципиальное различие.

1.3. Данные не равны объекту

Здесь возникает первая фундаментальная проблема любой информационной системы. Мы привыкли говорить:

«Автомобиль хранится в базе данных».

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

То же самое относится к инженерным системам. В PLM не находится насос. В PLM находится информация о насосе. В CAD не находится самолёт. В CAD находится его цифровая модель. В ERP не находится изделие. В ERP находятся данные о номенклатуре, производстве, закупках, стоимости и других аспектах деятельности.

Это кажется очевидным, но именно здесь возникает большинство проблем моделирования. Если система не различает объект и данные о нём, постепенно данные начинают подменять объект.

Тогда возникает вопрос: что именно представляет запись в системе? Документ? Изделие? Описание изделия? Версию описания? Конкретный экземпляр? Вариант? Или просто набор данных?

Пока этот вопрос не задан, архитектура системы строится практически вслепую.

1.4. Модель как договор между человеком и компьютером

Компьютер не способен самостоятельно определить, какие сущности существуют в предметной области. Поэтому между реальным миром и программой появляется модель.

Реальный мир
     ↓
Человеческое понимание
     ↓
Модель
     ↓
Информационная система

Модель сообщает системе:

• какие объекты существуют;
• какие данные относятся к этим объектам;
• какие отношения между объектами существуют;
• какие изменения допустимы;
• что означает каждое состояние данных.

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

Если в модели существует только Product, система будет видеть мир через понятие Product. Если в модели существует Product и ProductRevision, система сможет различать изделие и изменение его описания. Если существует отдельный ProductInstance, система сможет различать тип изделия и конкретный изготовленный экземпляр. Если существует отдельный Document, система сможет отличать изделие от документа, который его описывает. Каждое такое решение меняет не только структуру базы данных.

Оно меняет саму систему.

1.5. Почему ошибка модели опаснее ошибки кода

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

Система может работать годами. Пользователь создаёт изделие. Выпускает документ. Делает ревизию. Передаёт данные в производство. Формирует отчёт. Технически всё работает. Но если модель неправильно отвечает на вопрос, что именно является объектом, система постепенно начинает хранить неправильную картину мира. Пользователь начинает приспосабливаться. Если системе не хватает понятия, он использует другое поле. Если нельзя выразить нужную связь, он создаёт дополнительную запись. Если нельзя сохранить нужное состояние, он ведёт его в Excel. Если система не различает два разных инженерных понятия, пользователь начинает кодировать различие в названии, статусе или комментарии.

Так система постепенно перестаёт быть моделью предметной области. Она становится моделью собственных ограничений.

1.6. Почему интерфейс не исправляет плохую модель

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

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

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

1.7. Инженерная система делает проблему особенно сложной

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

Но в инженерной системе один и тот же физический мир приходится рассматривать одновременно с разных сторон.

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

Если система ответит неправильно, последствия будут распространяться на всю архитектуру.

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

Она начинается с объекта.

1.8. Первый принцип

Из всего сказанного можно сформулировать первый принцип книги:

Информационная система не обнаруживает объекты реального мира. Она должна получить их формальное представление.

Человек говорит: «Это автомобиль». Система должна иметь возможность представить:

Автомобиль
    ↓
самостоятельный объект

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

1.9. Связь с дальнейшим развитием модели

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

Все эти вопросы появляются из одного исходного решения: что именно мы считаем объектом? Поэтому выбор объекта является не частным решением разработчика базы данных. Это исходное решение всей информационной системы.

1.10. Главный вывод

Человек воспринимает автомобиль как объект. Компьютер видит только данные.

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

Что существует?

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

В следующей главе: существует ли объект до своего описания? И если да, то как система может представить то, что ещё не имеет ни одного документа?

Примечания к главе 1

Источники:

• ANSI/EIA-649-D, Configuration Management Standard, SAE International, 2019.
• ISO 10303-239, Industrial automation systems and integration — Product data representation and exchange — Part 239: Application protocol: Product life cycle support.
• NATO CALS Office, NPDM Version 4.10 — NATO Product Data Model, STANAG 4613 / ALP-14.
• ГОСТ 2.101-2016. Единая система конструкторской документации. Виды изделий.
• ГОСТ Р 2.005-2023. Единая система конструкторской документации. Термины и определения.

Типы доказательств: