Глава 24. Когда объект перестаёт существовать?
24.1. Начало и конец существования
До сих пор мы в основном говорили о том, как объект появляется в системе.
Создаётся KObject. Для него создаётся административный контекст. Появляется описание. Появляются атрибуты, связи, изменения.
Но у любого объекта есть и другая сторона жизненного цикла. Он может быть закрыт. Изделие снято с производства. Документ выведен из действия. Проект завершён. Группа закрыта. Экземпляр больше не существует как действующий объект.
Возникает простой вопрос: Что должна сделать система с объектом, когда его существование заканчивается?
Самый простой ответ — удалить запись. Но для инженерной системы это неправильный ответ.
Удаление означает: такого объекта больше нет в базе.
Закрытие означает другое: объект существовал, но его активное существование завершилось.
Это принципиальная разница.
24.2. Удаление и закрытие — не одно и то же
Представим насос Н1. Он был зарегистрирован в 2026 году. В 2038 году его эксплуатация закончилась. Если удалить запись:
KObject 12345
↓
DELETE
система больше не знает, что такой объект когда-либо существовал.
Но инженерная история не исчезает вместе с окончанием эксплуатации. В 2039 году может возникнуть вопрос:
Какой насос был установлен на этой площадке в 2032 году?
Или:
Какая Revision использовалась при изготовлении этого экземпляра?
Или:
Кто отвечал за объект до его закрытия?
Если объект физически удалён из модели, ответить на эти вопросы невозможно.
Поэтому завершение существования объекта должно быть отдельным состоянием жизненного цикла.
создан
↓
существует
↓
изменяется
↓
закрыт
История при этом сохраняется.
24.3. KObject не исчезает из истории
KObject является фундаментальным фактом существования объекта.
Поэтому завершение жизненного цикла не означает уничтожение этого факта. Упрощённо:
KObject 12345
│
├── существовал
│
├── имел описание
│
├── имел атрибуты
│
├── имел контекст
│
├── имел связи
│
└── был закрыт
После закрытия объект больше не является активным. Но его история остаётся частью системы.
Это позволяет отличить два совершенно разных утверждения:
объект не существует сейчас
и
объект никогда не существовал
Первое является нормальным состоянием жизненного цикла. Второе означает отсутствие самого факта.
Для PLM эти утверждения нельзя смешивать.
24.4. Что происходит с KContext
Закрытие объекта не означает, что его KContext превращается в бессмысленную запись. Контекст также имеет собственный временной интервал. Его активное состояние заканчивается.
KObject 12345
↑
│
KContext
valid_from: 2026
valid_to: 2038
После этого контекст больше не является действующим. Но он остаётся историческим свидетельством того, в каких административных условиях объект существовал.
Это особенно важно для аудита. Система должна иметь возможность восстановить не только:
какой объект существовал?
но и:
в каком административном состоянии он находился в определённый момент?
Поэтому закрытие не уничтожает временную историю. Оно завершает её.
24.5. Что происходит с атрибутами
То же относится к атрибутам.
Если объект закрыт, его прежние значения не должны исчезать только потому, что объект больше не активен. Например:
KAttribute
material = 09Г2С
valid_from = 2027
valid_to = 2038
После закрытия объекта это утверждение не становится ложным. Оно остаётся исторически верным. Вопрос:
Из какого материала был изготовлен насос Н1?
не становится бессмысленным только потому, что насос больше не эксплуатируется.
Исторические данные продолжают иметь значение.
24.6. Закрытие не создаёт новый объект
Здесь возникает ещё одно важное следствие.
Если объект закрывается, система не должна создавать вместо него новый KObject только потому, что его активное существование завершилось.
KObject 12345
↓
closed
а не:
KObject 12345
↓
deleted
KObject 67890
↓
бывший KObject 12345
Если инженерный объект тот же, его закрытие не меняет сам факт того, каким объектом он был. Новое состояние жизненного цикла не является новым объектом.
Это позволяет сохранить непрерывность истории.
24.7. Закрытие и изменение объекта
Необходимо также различать закрытие и изменение.
Если изменилось описание изделия, появляется новая Revision.
Если изменилось административное состояние, изменяется KContext.
Если объект перестал быть действующим, завершается его жизненный цикл.
Это три разных события.
изменение описания
↓
Revision
изменение административного состояния
↓
KContext
завершение существования
↓
закрытие KObject
Именно разделение этих событий позволяет не смешивать историю объекта с историей его описания и административного управления.
24.8. Закрытие и права доступа
Закрытие объекта также должно иметь последствия для административного управления.
После закрытия объект не должен продолжать вести себя как обычный активный объект. Это означает, что механизмы доступа должны учитывать состояние жизненного цикла.
Упрощённо:
активный объект
↓
обычные правила доступа
закрытый объект
↓
исторический объект
↓
ограниченный режим работы
Конкретные правила доступа зависят от политики системы. Но принцип остаётся:
закрытие объекта меняет его участие в текущем административном состоянии, но не уничтожает исторические данные.
24.9. Закрытие и проекции
Здесь снова появляется разделение основной модели и производных представлений.
Если объект закрыт, проекции, построенные для текущего состояния системы, должны перестать считать его активным объектом.
Например, объект больше не должен появляться среди текущих объектов пользователя только потому, что когда-то принадлежал его группе.
При этом исторические данные могут продолжать существовать. Получается два разных вопроса:
текущее состояние
↓
проекции активной модели
историческое состояние
↓
временные данные модели
Проекция не должна уничтожать историю. Она должна отражать актуальное состояние.
24.10. Закрытие и аудит
Для долгоживущей системы закрытие является событием, которое само должно быть прослеживаемым.
Нужно понимать:
- какой объект был закрыт;
- когда это произошло;
- кто инициировал операцию;
- в каком состоянии объект находился до закрытия.
Это особенно важно для конфигурационного управления.
Через несколько лет нельзя ограничиться ответом: «этого объекта сейчас нет».
Необходимо иметь возможность установить: объект существовал, использовался, имел определённое описание и определённый административный контекст, после чего его жизненный цикл был завершён.
24.11. Почему это важно для PLM
PLM работает не только с настоящим. Его задача — сохранять историю продукта на протяжении всего жизненного цикла.
Поэтому система должна одинаково хорошо отвечать на два вопроса:
Что существует сейчас?
и
Что существовало тогда?
Если система умеет только первое, она является текущим реестром. Если она умеет второе, появляется возможность инженерной прослеживаемости.
Например:
2032 год
│
├── объект
├── Definition
├── Revision
├── Attribute
├── Relation
└── Context
Даже если в 2040 году объект уже закрыт, система должна иметь возможность восстановить состояние, которое существовало в 2032 году.
Это одна из причин, почему временность проходит через разные уровни модели.
24.12. Главное различие
Вся глава может быть сведена к одному различию:
Удаление
↓
факт исчезает
Закрытие
↓
активное существование заканчивается
↓
история сохраняется
Для обычного приложения разница может показаться технической. Для инженерной системы она фундаментальна.
Изделия выводятся из эксплуатации. Документы отменяются. Проекты завершаются. Экземпляры перестают существовать.
Но прошлое не исчезает.
24.13. Связь с предыдущими главами
Глава 20 установила: KObject фиксирует факт существования. Он не содержит свойств, описания или контекста.
Глава 22 установила: KContext хранит административное состояние, связанное с объектом, и имеет собственное время действия.
Глава 24 добавляет: завершение жизненного цикла объекта является состоянием модели, а не уничтожением факта существования.
Вместе эти выводы формируют последовательную картину:
KObject
│
├── создан → факт существования зафиксирован
├── активен → участвует в текущем состоянии системы
├── изменяется → Revision, KContext, KAttribute
└── закрыт → исторический факт сохраняется
Закрытие не отменяет ни одного из предыдущих состояний.
Оно добавляет к ним последнее.
24.14. Главный вывод
Объект может перестать существовать как активный объект, но это не означает, что он перестаёт существовать как исторический факт.
Поэтому завершение жизненного цикла не должно быть обычным удалением записи. KObject сохраняет факт существования объекта. Его KContext сохраняет историю административных условий. Атрибуты сохраняют исторические утверждения. Definition и Revision сохраняют историю описания. Relations сохраняют историю связей.
Производные проекции отражают текущее состояние и могут исключать закрытые объекты из активных представлений. В результате система может одновременно хранить два состояния:
что существует сейчас
и
что существовало в прошлом
Это и есть принципиальная разница между системой, которая просто хранит текущие данные, и системой, которая сохраняет историю инженерного мира.
Закрытие завершает активное существование объекта. Оно не отменяет факт того, что объект существовал.
Примечание автора
В этой главе намеренно не вводится отдельная сущность для «истории удаления». История закрытого объекта формируется существующей моделью временных данных и жизненного цикла. Конкретный механизм закрытия и каскадного завершения связанных сущностей является частью реализации, а не отдельным понятием модели данных.