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

Эпилог

Мы начали с простого вопроса: что такое объект? И пришли к модели, которая позволяет системе сохранять смысл данных на протяжении десятилетий.

Э.1. От вопроса к модели

Мы начали с простого вопроса: Что такое объект?

На него оказалось недостаточно ответить одним классом или одной таблицей.

Объект должен быть зарегистрирован.

У него должно быть описание.

Описание может изменяться.

Его свойства имеют время и историю.

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

Он связан с другими объектами.

Он может иметь разные представления и участвовать в разных процессах.

И однажды его активное существование заканчивается.

Но ни одно из этих изменений само по себе не должно стирать историю объекта. Из этого постепенно сложилась модель.

KObject
   │
   ├── Definition
   │       └── Revision
   │
   ├── Attribute
   │
   ├── KContext
   │
   └── KRelation

Это не набор таблиц. Каждая сущность отвечает на свой вопрос.

KObject — какой объект существует.

Definition — как этот объект описан.

Revision — какая версия этого описания действовала.

KAttribute — какое утверждение об объекте было справедливо и когда.

KContext — в каких административных условиях объект существовал.

KRelation — с какими другими объектами он связан и каким образом.

А инварианты определяют, какие сочетания этих сущностей вообще имеют смысл.

Э.2. Разделение, которое сохраняет смысл

В результате модель позволяет отделить то, что в традиционных системах часто оказывается смешано:

• объект
• описание
• свойство
• контекст
• связь
• история
• права

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

Изделие меняется. Его описание меняется. Меняются люди и организации. Закрываются проекты. Появляются новые Revision. Меняются свойства. Меняются связи.

Но прошлое не должно исчезать только потому, что настоящее стало другим. Именно поэтому главный вопрос такой системы — не только:

Что существует сейчас?

но и:

Что существовало тогда?

Какой объект? С каким описанием? С какой Revision? С какими свойствами? В каком административном состоянии? С какими связями?

И на каком основании мы сегодня утверждаем, что всё было именно так?

Э.3. Модель как фундамент

Если модель способна ответить на эти вопросы, она становится основой не только для одной прикладной системы.

На такой модели можно строить разные классы инженерных информационных систем: PLM, системы управления конфигурацией, ERP и другие системы, которым необходимо сохранять сложные взаимосвязанные данные на протяжении длительного жизненного цикла.

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

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

Именно поэтому разработка модели данных — это не вспомогательная работа перед программированием. Это проектирование самого фундамента будущей системы.

Э.4. Объект 12345

Теперь вернёмся к первоначальному вопросу.

Что такое объект?

Пусть в системе действительно существует объект 12345.

KObject: 12345

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

Важно другое. Система должна суметь ответить:

Что это за объект?

Как он был описан?

Какие Revision существовали?

Какие свойства были у него тогда?

В каком контексте он находился?

С какими объектами был связан?

Что с ним произошло?

И почему система знает, что это именно тот объект?

Если модель отвечает на эти вопросы — она выполняет свою задачу. Потому что в конечном счёте вся сложная архитектура нужна для одной простой вещи:

не потерять смысл данных со временем.

Э.5. Откуда появилась эта книга

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

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

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

За каждым таким решением стоит вопрос: что произойдёт с моделью через пять, десять или двадцать лет?

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

Э.6. Возвращение к началу

Поэтому книга заканчивается там же, где всё начиналось.

С объектом.

Например, с объектом 12345.

Он просто существует.

А всё остальное — описание, свойства, связи, контекст, изменения и история — должно помочь системе точно рассказать, что это за объект, каким он был и что с ним происходило.

В этом и состоит смысл модели.

Конец книги.

Для тех, кто хочет заглянуть под капот — KContext Service.

использовать:

Термины