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

Глава 11. Объект сохраняется, описание изменяется

11.1. Насос, который живёт тридцать лет

Представим промышленный насос. Он разработан в 2026 году. Изготовлен. Установлен на нефтеперекачивающей станции. Эксплуатируется. Через пять лет выполнен капитальный ремонт. Через десять лет заменён поставщик уплотнений. Через пятнадцать лет модернизирована система контроля. Через двадцать лет изменены требования экологической безопасности. Через тридцать лет насос снят с эксплуатации.

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

Если информационная система не способна удержать идентичность объекта при изменении его описания, через тридцать лет никто не сможет ответить на простой вопрос: что это за насос и какова его история?

11.2. Как человек удерживает идентичность

Человек не испытывает затруднений с этой задачей. Мы встречаем знакомого через двадцать лет. Он изменился. Другая причёска. Другая фигура. Другая одежда. Другая работа. Другой город. Но мы говорим: «Это тот же человек». Идентичность сохранена. Свойства изменились.

То же самое с инженерным объектом. Инженер говорит: «Это насос Н1». При этом он не перечисляет все текущие свойства. Он указывает на объект. Объект существует независимо от того, какие свойства ему приписаны в данный момент.

Это естественное свойство человеческого мышления: мы разделяем объект и его описание. Объект постоянен. Описание временно. Компьютер не делает этого разделения автоматически. Его необходимо заложить в модель данных явно.

11.3. Классическая модель: объект равен своим полям

Рассмотрим, как эта задача решается в традиционном подходе.

Product
    id          INTEGER
    name        VARCHAR
    material    VARCHAR
    weight      DECIMAL
    status      VARCHAR
    manufacturer VARCHAR

Объект представлен строкой в таблице. Его свойства являются полями. На первый взгляд это выглядит просто и понятно. Но проходит время. Появляется требование: хранить историю изменения материала. Добавляется таблица:

Product_Material_History
    product_id  INTEGER
    material    VARCHAR
    valid_from  DATE
    valid_to    DATE

Появляется требование: хранить разные виды статусов. Добавляется ещё одна таблица. Появляется требование: хранить изменения поставщика. Ещё одна таблица. Появляется требование: хранить экологический класс. Новое поле в основной таблице. Через несколько лет модель выглядит так:

Product
      id
      name
      material
      weight
      status
      manufacturer
      environmental_class
      digital_passport_id
      certification_status
      repair_level
      ...

 Product_Material_History
 Product_Status_History
 Product_Supplier_History
 Product_Certification_History
 ...

Основная таблица отражает уже не столько объект, сколько историю попыток расширения его представления. Каждое новое требование добавляет новое поле или новую таблицу. Структура данных постоянно меняется. А объект, который должен быть стабильным, тонет в нарастающей сложности.

11.4. Проблема фиксированной схемы

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

Когда архитектор проектирует таблицу Product, он должен решить: какие поля будут у изделия? Название. Масса. Материал. Статус. Производитель.

Но через пять лет появляются новые понятия, которые никто не мог предвидеть. Экологический класс. Цифровой паспорт. Уровень ремонтопригодности. Статус сертификации по новому стандарту. Идентификатор в государственной системе учёта.

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

11.5. В этом различии появляется временная ось модели

Если вернуться к выводу предыдущих глав, становится очевидным главное правило: объект постоянен; описание временно.

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

Object
   │
   ├── Definition A
   ├── Definition B
   └── Definition C

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

Object остаётся.

Definitions сменяют друг друга.

Каждая Definition отвечает на свой вопрос: какое знание действовало в этот период? Именно поэтому история описания не является историей самого объекта. Она является историей знания об объекте.

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

11.6. Что происходит, когда меняется описание

Вернёмся к насосу Н1.

В 2026 году его описание выглядит так:

Насос Н1
    материал: Сталь 20
    масса: 850 кг
    производитель: Предприятие А

В 2030 году поставщик стали изменился. В 2035 году изменился материал корпуса. В 2040 году добавилось новое требование к экологической безопасности. Сам насос при этом не перестаёт быть насосом Н1. Изменяется информация о нём.

Это принципиальное различие:

Объект
    |
    +-- существует
    |
    +-- сохраняет свою идентичность
    |
    +-- имеет изменяющееся описание

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

Изменяется не объект. Изменяется знание об объекте.

11.7. Почему нельзя просто менять поля

Можно возразить: зачем усложнять модель? Почему бы просто не обновлять значения?

UPDATE Product
SET material = '09Г2С'
WHERE id = 12345;

Для текущего состояния это работает. Но через десять лет возникает вопрос: Какой материал был у насоса в момент изготовления?

Если в таблице осталось только текущее значение, система ответит:

09Г2С

Но это может быть неверно. Экземпляр №12345 был изготовлен в 2026 году, когда действовало значение Сталь 20. В 2035 году материал был изменён в результате модернизации.

Если история не сохранена, система больше не знает, что происходило с объектом. Это не просто потеря старого значения. Теряется инженерный факт.

Без него невозможно провести расследование дефекта. Невозможно определить, какие экземпляры затронуты изменением. Невозможно подтвердить, каким требованиям соответствовал объект в конкретный момент времени.

11.8. Revision изменяет описание, а не объект

Именно здесь появляется Revision.

Если изменение не меняет самого объекта, а меняет его описание, создаётся новая Revision этого описания.

KProduct: Насос Н1
    |
    +-- KDesignDefinition
            |
            +-- Revision A
            +-- Revision B
            +-- Revision C

Revision A не заменяется Revision B. Обе остаются в истории.

Revision B не является новым насосом. Она является новым состоянием описания того же насоса.

Это позволяет системе одновременно хранить два факта:

Объект:
    Насос Н1
    остаётся тем же

Описание:
    Revision A
    Revision B
    Revision C
    изменяется во времени

Если же изменение нарушает критерий, установленный в Главе 4, и объект перестаёт быть взаимозаменяемым с прежним, это уже не изменение описания. Это новый объект.

Следовательно:

Изменилось описание
        ↓
Новая Revision

Изменился сам объект
        ↓
Новый KProduct

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

11.9. Два уровня модели

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

Первый уровень — объект.

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

Второй уровень — описание.

Атрибуты, определения, документы и версии относятся к описанию объекта. Описание изменяется во времени. Каждое изменение может быть зафиксировано. История сохраняется.

Уровень объекта:
    Object
        |
        +-- стабильный идентификатор

Уровень описания:
    Attribute
    Definition
        |
        +-- Revision
    Document
        |
        +-- версии
    Context
        |
        +-- условия существования

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

11.10. Почему это особенно важно для PLM

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

Но PLM работает с другим масштабом времени. Изделие может существовать десятилетиями. За это время:

• меняются конструкторы;
• меняются технологи;
• меняются поставщики;
• меняются стандарты;
• меняются требования безопасности;
• меняются производственные площадки;
• появляются новые виды документации;
• выполняются ремонты и модернизации.

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

И система должна уметь представить это без подмены одного понятия другим.

11.11. Разделение, которое уже существует в инженерной практике

Это не исключительно компьютерная идея.

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

ГОСТ Р 2.503-2023 устанавливает правила внесения изменений в конструкторские документы. Само наличие процедуры изменения документации показывает важное различие: изменяется документированное описание изделия, а не произвольно меняется само изделие.

Аналогичное разделение существует и в международном управлении конфигурацией. Configuration Item является управляемым объектом, а configuration information содержит информацию о нём. Изменение информации не означает автоматически замену самого объекта.

В ISO 10303-239 это различие выражено непосредственно структурой модели: product и product_definition являются разными сущностями.

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

11.12. Где здесь Anchor Modeling

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

В упрощённом виде:

Anchor
    |
    +-- Attribute
    |      value A
    |      value B
    |      value C
    |
    +-- Attribute
           value A
           value B

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

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

Гибкость находится на уровне изменяемых данных. Строгость — на уровне модели предметной области.

11.13. Практическое следствие для архитектуры

Если принять принцип стабильного объекта и изменяемого описания, модель данных должна разделять их архитектурно.

Не организационно. Не через соглашения пользователей. Не через инструкцию «не изменяйте идентификатор».

Через структуру модели.

Object
    |
    +-- Attribute
    |
    +-- Definition
    |      |
    |      +-- Revision
    |
    +-- Document
    |
    +-- Context

Object является стабильной точкой. Все остальные сущности могут развиваться вокруг него.

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

Именно поэтому объект может быть известен системе раньше, чем появится полное описание. Сначала существует сам объект. Затем различные области системы добавляют своё знание о нём.

11.14. Граница применимости

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

Граница проходит там, где появляются три условия одновременно:

• объект живёт значительно дольше, чем версия программного обеспечения;
• описание объекта изменяется на протяжении жизненного цикла;
• история изменений является частью инженерного знания.

Для PLM все три условия выполняются. Изделия живут десятилетиями. Описание меняется постоянно. История критична для трассируемости.

Именно поэтому разделение объекта и его описания является не оптимизацией, а необходимым свойством модели.

11.15. Связь с предыдущими главами

Глава 4 установила: граница между «тем же объектом» и «новым объектом» определяется взаимозаменяемостью.

Глава 5 установила: Revision фиксирует изменение описания, а не изменение объекта.

Глава 10 установила: документ не является объектом. Объект существует независимо от документа.

Глава 11 добавляет: объект должен сохранять стабильную идентичность, а его описание должно изменяться во времени. Модель данных должна разделять эти два аспекта архитектурно.

Вместе эти выводы формируют последовательную картину:

Объект существует
        ↓
Идентичность сохраняется
        ↓
Описание изменяется
        ↓
Изменение описания фиксируется через Revision
        ↓
Изменение самого объекта создаёт новый объект

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

Каждый уровень отвечает на свой вопрос. Смешивание этих уровней приводит к потере смысла.

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

Объект реального мира постоянен. Его описание временно.

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

Международные стандарты CM, ISO 10303-239 и отечественная система ЕСКД используют различение объекта и информации о нём. В разных моделях оно выражено по-разному, но принцип один: изменение данных об объекте не должно автоматически означать замену самого объекта. Для модели данных это означает одно: система должна разделять объект и его изменяемые данные архитектурно.

Не через соглашения пользователей. Не через правила интерфейса. Через структуру модели.

Объект является стабильной точкой. Всё остальное развивается вокруг него. Это разделение не является усложнением ради усложнения. Оно отражает реальный мир. Насос, который живёт тридцать лет, остаётся одним объектом. Меняется знание о нём.

Модель данных должна уметь хранить и то и другое, не смешивая.

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

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

Источники:

• ANSI/EIA-649-D, Configuration Management Standard, SAE International, 2019. §3.2.
• NASA/SP-2016-610, Rev. 2, NASA Systems Engineering Handbook, NASA, 2016. §3.4.
• MIL-HDBK-61A, Configuration Management Guidance, U.S. Department of Defense, 2001. §2.3.
• ISO 10303-239, Industrial automation systems and integration — Product data representation and exchange — Part 239: Application protocol: Product life cycle support.
• ГОСТ Р 2.101-2023. Единая система конструкторской документации. Виды изделий.
• ГОСТ Р 2.503-2023. Единая система конструкторской документации. Правила внесения изменений.
• ГОСТ Р 2.005-2023. Единая система конструкторской документации. Термины и определения.
• ГОСТ Р 2.051-2023. Единая система конструкторской документации. Электронная конструкторская документация. Основные положения.
• Rönnbäck, L. et al. Anchor Modeling: An Agile Modeling Technique Using the Sixth Normal Form. 2010.

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