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

Глава 21. KAttribute — знания об объекте

21.1. Поле, которое лжёт

Откройте любую таблицу базы данных. Найдите строку, которая представляет изделие.

Product
    id: 12345
    name: Насос Н1
    material: 09Г2С
    weight: 45.0
    status: in_production

Что вы видите? Вы видите объект. Его имя. Его материал. Его массу. Его статус. Всё кажется простым и понятным.

Но задайте один вопрос: когда материал стал 09Г2С?

Таблица не отвечает. Она хранит текущее значение. Предыдущее значение потеряно.

Задайте другой вопрос: кто изменил материал?

Таблица снова не отвечает. Она хранит значение, но не хранит событие изменения.

Задайте третий вопрос: на каком основании материал был изменён?

Таблица не знает об извещении об изменении. Не знает о решении конструктора. Не знает о результатах испытаний.

Поле хранит значение. Но не хранит знание. А инженерное знание — это не только значение.

Это значение, существующее в определённый момент времени, полученное из определённого источника и имеющее определённое основание.

При этом важно не перепутать две вещи.

KObject действительно содержит общую основу объекта. Но свойства объекта не являются частью этой основы.

KProduct остаётся KObject, но его материал, масса, обозначение или другие характеристики не становятся полями базового класса.

Они являются знаниями об объекте.

21.2. Почему поле не является знанием

Рассмотрим конкретную ситуацию.

Насос Н1 был разработан в 2026 году. Материал корпуса — Сталь 20. В 2031 году конструктор изменил материал на 09Г2С. В 2040 году возникает вопрос: Из какого материала изготовлен экземпляр №12345?

Если система хранит только текущее поле material = 09Г2С, ответить на этот вопрос невозможно. Текущее значение не говорит, какое значение действовало в момент изготовления конкретного экземпляра.

Чтобы ответить, система должна знать историю:

2026
    material = Сталь 20
2031
    material = 09Г2С

Но одной истории тоже недостаточно. Нужно знать: Кто установил значение? На каком основании? Когда оно вступило в действие? Какое утверждение оно заменило?

Тогда инженерное знание становится восстановимым.

KObject: 12345
    |
    +-- KAttribute: material
    |       value: Сталь 20
    |       valid_from: 01.01.2026
    |       valid_to: 01.06.2031
    |       source: конструктор Иванов
    |       basis: расчёт прочности №12
    |
    +-- KAttribute: material
            value: 09Г2С
            valid_from: 01.06.2031
            valid_to: (действует)
            source: конструктор Петров
            basis: извещение об изменении №45

Теперь система знает не только значение. Она знает, что было известно об объекте, когда это стало известно, кем было установлено и почему это стало известно.

Это принципиально другая модель данных.

21.3. Утверждение вместо значения

Вернёмся к тому, как инженер говорит об объекте.

Он не думает:

Product.material = 09Г2С

Он говорит:

«Материал корпуса этого насоса — 09Г2С».

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

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

KObject
    |
    └── KAttribute
            |
            ├── value
            ├── valid_from
            ├── valid_to
            ├── source
            └── basis

KObject остаётся тем же. Изменяется утверждение о нём.

21.4. Объект постоянен. Утверждения изменяются

Это продолжение принципа, сформулированного ранее.

Объект существует. Знание об объекте появляется позже. Знание изменяется. Объект при этом остаётся тем же.

Представим историю материала корпуса:

KObject: Насос Н1

2026
    KAttribute
        material = Сталь 20

2031
    KAttribute
        material = 09Г2С

2036
    KAttribute
        material = 10ХСНД

Не существует трёх насосов. Существует один насос и три последовательных утверждения о его материале.

Именно поэтому изменение свойства не должно изменять KObject.

Если материал изменился — изменилось знание. Если изменилась масса — изменилось знание. Если изменился статус — изменилось знание. Если изменился источник знания — изменилось знание.

Сам объект остаётся тем же.

21.5. Время является частью утверждения

В обычной модели время часто находится где-то рядом с историей изменений.

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

Утверждение:

material = 09Г2С

неполно. Полное утверждение:

material = 09Г2С
valid_from = 01.06.2031
valid_to = NULL
source = конструктор Петров
basis = извещение №45

Теперь система знает, когда это утверждение действует.

Поэтому можно задать вопрос: Какой материал был установлен для насоса 1 июня 2030 года?

И получить историческое значение.

Можно задать другой вопрос: Кто установил действующее значение? И получить источник.

Можно спросить: На каком основании материал был изменён? И получить основание.

Это уже не обычное хранение свойств. Это хранение инженерного знания.

21.6. Атрибут имеет собственную жизнь

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

Оно становится самостоятельной сущностью модели.

KAttribute имеет:

• собственную идентификацию;
• ссылку на KObject;
• тип утверждения;
• значение;
• время действия;
• источник;
• основание;
• собственную историю версий.

Поэтому KAttribute является самостоятельной сущностью модели.

Это не означает, что атрибут становится самостоятельным без связи с KObject.

Наоборот.

KAttribute существует для того, чтобы утверждать что-либо о KObject.

Если KObject отвечает на вопрос: «Что существует?»

то KAttribute отвечает на вопрос: «Что система знает об этом объекте?»

Это разные вопросы. Здесь важно зафиксировать одну границу.

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

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

21.7. Почему изменение создаёт новое утверждение

В обычной объектной модели разработчик может сделать:

product.material = "09Г2С";

Старое значение исчезает.

В модели Constructum такое изменение не означает переписывание существующего знания. Предыдущее утверждение закрывается. Создаётся новое.

Старое утверждение
    valid_from = 2026
    valid_to   = 2031

Новое утверждение
    valid_from = 2031
    valid_to   = NULL

Это важный архитектурный принцип.

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

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

21.8. Источник и основание

Инженерное знание почти всегда имеет происхождение.

Материал изменился потому, что:

• появился новый расчёт;
• были проведены испытания;
• изменилось требование заказчика;
• вышло извещение об изменении;
• конструктор принял новое решение.

Поэтому утверждение должно позволять установить происхождение знания. Например:

KAttribute
    type: material
    value: 09Г2С
    source:
        Конструктор Петров
    basis:
        Извещение об изменении №45
    valid_from:
        01.06.2031

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

Это особенно важно для PLM. Через десять лет вопрос обычно звучит не:

«Какое значение сейчас?»

Он звучит:

«Почему тогда приняли именно это решение?»

Именно здесь обычное поле базы данных оказывается недостаточным.

21.9. Что говорят стандарты

Это не только архитектурная идея Constructum.

ANSI/EIA-649-D рассматривает учёт состояния конфигурации как процесс сохранения информации об изменениях конфигурационных данных. Стандарт требует, чтобы информация о состоянии конфигурационной единицы была восстановима во времени.

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

MIL-HDBK-61A также требует прослеживаемости изменения конфигурационных данных до его источника, включая предложение об изменении, утверждающий орган и дату вступления в действие.

ISO 10303-239 (PLCS) формализует разделение между продуктом и информацией о нём. Характеристики продукта (characteristic) представлены как отдельные сущности, связанные с определениями продукта. Это подтверждает принцип: информация о свойствах изделия является самостоятельной сущностью, а не просто полем записи.

NPDM (NATO Product Data Model, STANAG 4613) использует аналогичный подход. Характеристики продукта отделены от самого продукта и связаны с ним через определения. Информация о продукте имеет собственную структуру и собственную историю.

Эти требования имеют общий смысл: информация о состоянии изделия должна быть восстановима во времени и прослеживаема до источника её изменения.

Constructum переводит это требование из процедурного уровня в модель данных.

21.10. Как это закреплено в ЕСКД

Отечественная инженерная практика выражает тот же принцип через извещение об изменении.

ГОСТ Р 2.503-2023 устанавливает порядок внесения изменений в конструкторскую документацию через извещение об изменении.

Изменение имеет:

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

Следовательно, изменение не является простым присваиванием нового значения полю. Оно имеет основание и историю.

Если система хранит только:

material = 09Г2С

то извещение об изменении невозможно связать с самим фактом изменения.

Если система хранит утверждение как самостоятельную сущность, связь становится естественной:

KObject
    |
    └── KAttribute
            |
            └── изменено на основании
                    |
                    └── KChangeNotice

Модель данных начинает отражать инженерную практику непосредственно.

21.11. Практический пример

Рассмотрим насос Н1. В 2026 году инженер установил:

material = Сталь 20
Источник: Иванов
Основание: Расчёт прочности №12

В 2031 году материал изменился.

Причина: Извещение об изменении №45
Новое значение: 09Г2С
Источник: Петров

Модель хранит:

KObject: Насос Н1
     |
     +-- KAttribute
     |       type: material
     |       value: Сталь 20
     |       valid_from: 2026
     |       valid_to: 2031
     |       source: Иванов
     |       basis: Расчёт №12
     |
     +-- KAttribute
             type: material
             value: 09Г2С
             valid_from: 2031
             valid_to: NULL
             source: Петров
             basis: Извещение №45

Теперь через двадцать лет можно восстановить историю. Не только текущее значение.

Можно восстановить последовательность решений.

21.12. Почему это важно для экземпляров

Здесь появляется особенно важное следствие.

Тип изделия и конкретный экземпляр — разные объекты.

Если насос Н1 имеет несколько ревизий описания, это не означает, что каждый изготовленный насос автоматически имеет последнюю ревизию.

Конкретный экземпляр является самостоятельным объектом. Он имеет собственные утверждения и собственный производственный контекст. Информация о том, какая Revision была применена при его изготовлении, относится к этому экземпляру и фиксируется в соответствующей связи/контексте применения.

Поэтому вопрос: «Какая Revision сейчас актуальна для KProduct?»

и вопрос: «Какая Revision была применена при изготовлении экземпляра №12345?»

— это разные вопросы.

Первый относится к текущему состоянию описания. Второй — к историческому факту конкретного изготовления.

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

21.13. Почему это не просто EAV

На первый взгляд модель может показаться обычным EAV (Entity-Attribute-Value):

object_id
attribute
value

Но это принципиально не так. В EAV основная идея — вынести свойства в универсальную таблицу значений.

Здесь задача другая.

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

Поэтому оно имеет:

KObject
    ↓
KAttribute
    ├── type
    ├── value
    ├── valid_from
    ├── valid_to
    ├── source
    └── basis

Кроме того, типы атрибутов остаются определёнными.

Поэтому гибкость модели не означает отказ от строгости.

21.14. Anchor Modeling: философия, а не реализация

В Главе 11 мы уже рассмотрели три подхода к хранению изменяемых данных: фиксированную схему, EAV и Anchor Modeling. Здесь зафиксируем лишь архитектурный принцип, который следует из этого анализа.

Объект и утверждения об объекте должны быть разделены. Не только на уровне таблиц.

На уровне модели.

KObject: 123
      |
      +-- KAttribute: material
      |       value: Сталь 20
      |       время: 01.01.2026
      |       источник: конструктор
      |
      +-- KAttribute: material
      |       value: 09Г2С
      |       время: 01.06.2031
      |       источник: конструктор
      |       основание: извещение №45
      |
      +-- KAttribute: weight
              value: 45.0 кг
              время: 01.01.2026
              источник: расчёт

Объект является точкой. Утверждения развиваются вокруг него. Каждое утверждение имеет собственную жизнь. Собственное время. Собственный источник. Собственное основание.

Это не технический приём. Объект существует. Знания об объекте появляются, изменяются, устаревают, заменяются.

Объект не меняется. Меняются утверждения.

21.15. Почему это важно для расширяемости

Рассмотрим ситуацию.

Через десять лет появляется новое требование: необходимо хранить экологический класс изделия.

В классической модели необходимо изменить структуру таблицы:

ALTER TABLE product
ADD environmental_class ...

Затем провести миграцию. Обновить код. Обновить интеграции. Изменить отчёты.

В модели утверждений структура фундаментального объекта не меняется. Появляется новый тип утверждения:

KObject: 12345
    |
    +-- KAttribute: material
    |       ...
    |
    +-- KAttribute: weight
    |       ...
    |
    +-- KAttribute: environmental_class
            value: класс II
            valid_from: 01.01.2036
            source: экологическая служба
            basis: стандарт ГОСТ Р ...

Объект не изменился. Структура модели не изменилась. Появилось новое знание.

Механизм тот же. История та же. Источник тот же.

Это важно для PLM-системы, которая должна жить десятилетиями.

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

Модель утверждений позволяет расширять область знаний без изменения механизма существования объектов.

21.16. Почему это не означает отсутствие строгости

Здесь возникает естественный вопрос.

Если любое свойство можно представить как KAttribute, не превращается ли модель в произвольное хранилище?

Нет.

Гибкость находится на уровне утверждений.

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

Система знает:

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

Например, система может разрешить:

KProduct
    └── KAttribute: material

но запретить:

KProduct
    └── KAttribute: document_author

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

Они находятся на разных уровнях модели.

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

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

Свойства объекта не являются его полями.

Они являются утверждениями об объекте.

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

Международные стандарты Configuration Management, ISO 10303-239, NATO Product Data Model и отечественная система ЕСКД сходятся в одном принципе: информация о состоянии изделия должна сохраняться во времени и быть прослеживаема до источника изменения.

Constructum переводит этот принцип в модель данных. KObject представляет то, что существует. KAttribute представляет то, что известно об этом объекте.

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

Именно это позволяет системе через десять, двадцать и тридцать лет ответить не только на вопрос: «Что известно об объекте сейчас?»

но и на гораздо более важный инженерный вопрос: «Что было известно об объекте тогда, кто это установил и на каком основании?»

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

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

Источники:

• ANSI/EIA-649-D, Configuration Management Standard, SAE International, 2019. §4.3.
• NASA/SP-2016-610, Rev. 2, NASA Systems Engineering Handbook, NASA, 2016. §5.3.
• MIL-HDBK-61A, Configuration Management Guidance, U.S. Department of Defense, 2001. §4.2.
• 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.503-2023. Единая система конструкторской документации. Правила внесения изменений.
• ГОСТ Р 2.101-2023. Единая система конструкторской документации. Виды изделий.
• ГОСТ Р 2.005-2023. Единая система конструкторской документации. Термины и определения.
• Rönnbäck, L. et al. Anchor Modeling: An Agile Modeling Technique Using the Sixth Normal Form. 2010.

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