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

ЧАСТЬ IV. Что находится внутри модели?

Глава 19. Всё является объектом

Предыдущие главы устанавливали смысл понятий. Теперь мы переводим эти понятия в минимальную структуру модели Constructum. Поэтому следующие главы не вводят новые философские основания, а формализуют уже полученные выводы.

19.1. Разные вещи — один фундамент

До этого момента мы рассматривали объекты с разных сторон.

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

На уровне содержания всё это совершенно разные вещи. Но возникает простой вопрос:

как система представляет сам факт их существования?

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

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

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

19.2. KObject — базовый класс

В объектно-ориентированной модели есть простой принцип.

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

              KObject
             /   |   \
            /    |    \
           ↓     ↓     ↓
      KProduct KDocument KUser

KProduct — конкретный тип объекта.

KDocument — другой тип объекта.

KUser — ещё один тип объекта.

Но каждый из них является KObject.

Именно это означает утверждение:

все объекты являются объектами.

Речь не о философии. Речь о структуре модели.

KObject задаёт общий фундамент. Конкретный наследник задаёт то, чем является объект.

19.3. Что общего у всех объектов

Представим изделие.

KProduct
    id = 12345

Теперь документ:

KDocument
    id = 67890

И пользователя:

KUser
    id = 24680

Их содержание совершенно различно.

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

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

Это и есть роль KObject.

19.4. Наследование не делает объекты одинаковыми

Важно не перепутать общий фундамент с одинаковым содержанием.

                         KObject
                            │
          ┌─────────────────┼─────────────────┐
          │                 │                 │
       KProduct          KDocument          KUser
      

Все эти классы имеют общий базовый механизм.

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

У KProduct будет свой набор допустимых сущностей и связей.

У KDocument — свой.

У KUser — свой.

Наследование отвечает только за общее основание.

Общий фундамент не отменяет различий между типами. Он позволяет этим различиям существовать внутри одной модели.

Здесь важно зафиксировать это различие явно:

общий механизм существования
        ≠
общая семантика

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

19.5. Почему нельзя делать отдельный фундамент для каждого типа

Можно было бы построить систему иначе. Например:

ProductBase
DocumentBase
UserBase
ProjectBase
...

У каждого типа была бы собственная схема существования.

Но тогда вместе с каждым новым типом пришлось бы создавать новый механизм:

• идентификации;
• ссылок;
• связей;
• жизненного цикла;
• истории;
• интеграции с остальной системой.

Получилась бы система отдельных миров.

Вместо этого модель говорит:

KObject
   │
   ├── KProduct
   ├── KDocument
   ├── KUser
   ├── KProject
   └── ...

Новый тип получает общий фундамент автоматически.

Нужно определить его собственное содержание и правила — но не изобретать заново сам способ существования объекта.

19.6. Один объект может участвовать в разных отношениях

Единый фундамент нужен ещё по одной причине.

Система не существует ради хранения объектов по отдельности.

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

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

KObject ←── KRelation ──→ KObject

Связь знает, какие объекты она соединяет. Каждый из них имеет общий фундамент.

Это делает модель единой, не делая её однообразной.

19.7. Что означает «тип объекта»

Здесь важно провести границу.

Тип не является заменой KObject. KObject отвечает за общий механизм существования объекта. Конкретный тип отвечает за его смысл в модели.

Поэтому:

KProduct is-a KObject
KDocument is-a KObject
KUser is-a KObject

Но:

KProduct ≠ KDocument
KDocument ≠ KUser

Они разные типы одного общего класса.

Это ровно тот же принцип, который используется в объектно-ориентированном программировании: базовый класс задаёт общее, наследник — специальное.

19.8. Почему это важно для модели данных

Теперь становится понятнее, что именно означает единый механизм существования.

Он не означает:

все данные должны храниться одинаково.

Не означает:

все объекты должны иметь одинаковые свойства.

Не означает:

все объекты должны обслуживаться одним сервисом.

Он означает только одно:

все самостоятельные объекты модели имеют общий базовый фундамент.

Поэтому система может знать:

KProduct 12345
KDocument 67890
KUser 24680

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

19.9. Откуда берётся содержимое объекта

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

Если KObject содержит общий фундамент, где находятся остальные данные?

Ответ уже подготовлен предыдущими главами.

Описание находится в KDefinition.

Изменения описания — в Revision.

Свойства — в KAttribute.

Связи — в KRelation.

Административное состояние — в KContext.

То есть объект не превращается в одну большую запись.

Вокруг него существует модель:

                         KObject
                            │
          ┌─────────────────┼──────────────────┐
          │                 │                  │
    KDefinition         KAttribute         KContext
          │
       Revision
          │
       KRelation

Здесь важно видеть не дерево владения, а общий объектный фундамент.

KObject — начало.

Остальные сущности добавляют сведения о конкретном объекте.

19.10. Почему единый фундамент устойчив

PLM-система живёт десятилетиями.

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

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

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

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

Устойчивым должен быть общий объектный фундамент модели.

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

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

Глава 12 установила: связи являются самостоятельными объектами.

Глава 19 добавляет: все самостоятельные объекты модели имеют общий базовый класс KObject. Конкретные типы объектов являются его наследниками.

Эта глава не утверждает, что все объекты одинаковы.

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

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

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

Все самостоятельные объекты системы имеют общий базовый класс — KObject.

KObject определяет общую часть объекта.

KProduct, KDocument, KUser, KProject и другие типы наследуют этот фундамент и добавляют собственную семантику.

Поэтому:

единый фундамент не делает объекты одинаковыми.

Он позволяет разным объектам существовать внутри одной модели.

И это уже не абстракция. Это конкретная структура:

                         KObject
                            │
          ┌─────────────────┼─────────────────┐
          │                 │                 │
       KProduct          KDocument          KUser
          │
      KInstance

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

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

Источники:

• 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-2023. Единая система конструкторской документации. Виды изделий.
• ГОСТ 2.102-68. Единая система конструкторской документации. Виды и комплектность конструкторских документов.
• ГОСТ Р 2.052-2024. Единая система конструкторской документации. Электронная модель изделия. Общие положения.
• ГОСТ Р 2.053-2023. Единая система конструкторской документации. Электронная структура изделия. Общие положения.
• ГОСТ Р 2.051-2023. Единая система конструкторской документации. Электронная конструкторская документация. Основные положения.
• ГОСТ Р 2.005-2023. Единая система конструкторской документации. Термины и определения.

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