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

Глава 4. Когда изменение создаёт новый объект?

4.1. Разговор, который происходит без слов

Представим простую ситуацию. Владелец автомобиля отправляет его в ремонт. Меняют тормозные колодки, масляный фильтр, свечи зажигания. Автомобиль возвращается. Владелец говорит: «Мой автомобиль из ремонта». Никто не удивляется. Никто не спрашивает: «А это всё ещё тот же автомобиль?»

Теперь представим другую ситуацию. Тот же владелец приходит в автосалон. Ему предлагают новую модель той же марки. Название похоже. Логотип тот же. Но владелец говорит: «Это другой автомобиль». И снова никто не удивляется.

Человек проводит эту границу мгновенно и безошибочно. Замена колодок — ремонт. Новая модель — другой объект. При этом никто не формулирует явного правила. Никто не составляет перечень критериев. Граница существует в инженерной интуиции, которая формировалась десятилетиями практики.

Но попробуйте объяснить это компьютеру.

4.2. Почему компьютер не видит границы

Для информационной системы любое изменение выглядит одинаково. Заменён материал покрытия — новая запись. Изменён диаметр вала — новая запись. Добавлено новое крепёжное отверстие — новая запись. Система не знает, какое из этих событий сохраняет объект, а какое создаёт новый.

Если модель данных не содержит явного критерия, пользователь вынужден принимать решение самостоятельно. И здесь начинается проблема. Один инженер считает, что замена материала — это новое изделие. Другой считает, что это лишь уточнение документации. Третий полагает, что изменение цвета корпуса требует нового обозначения. Все трое могут быть по-своему правы в рамках своего опыта. Но система получает три разных ответа на один и тот же вопрос.

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

4.3. Как человек на самом деле проводит границу

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

Возьмём конкретный пример. Насос. Конструктор изменил материал корпуса: вместо чугуна использована сталь. Размеры остались прежними. Присоединительные отверстия на тех же местах. Расход и напор не изменились. Можно ли снять старый насос и поставить новый? Да. Инженер говорит: «Это тот же насос. Изменилось описание».

Теперь другой случай. Конструктор изменил диаметр выходного патрубка. Присоединительные размеры другие. Старый трубопровод не подходит. Снять старый насос и поставить новый без переделки системы невозможно. Инженер говорит: «Это другой насос».

Что изменилось между двумя случаями? Не материал. Не сложность доработки. Не объём конструкторской работы. Изменилось одно: возможность заменить один объект другим без переделки окружения.

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

4.4. Form, Fit, Function: три слова, которые определяют границу

Принцип взаимозаменяемости формализован через три критерия, известных как FFF:

Form (форма) — геометрические характеристики объекта: размеры, контуры, масса, внешний вид.

Fit (посадка) — способность объекта занимать предназначенное ему место в системе: присоединительные размеры, допуски, интерфейсы.

Function (функция) — способность объекта выполнять предназначенную ему работу: производительность, мощность, точность, надёжность.

Если изменение сохраняет все три критерия, объект остаётся тем же. Изменяется его описание. Нарушение взаимозаменяемости является основанием для оценки необходимости новой идентификации объекта. В модели Constructum это оформляется как граница между изменением существующего описания и созданием нового объекта.

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

4.5. Что говорят стандарты управления конфигурацией

Стандарт ANSI/EIA-649-D «Configuration Management Standard» (2019) определяет:

A change that affects form, fit, or function of a configuration item shall be evaluated to determine whether a new configuration item identification is required.

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

Это ключевое положение. Стандарт не говорит: «любое изменение создаёт новый объект». Он говорит: изменение должно быть оценено. И критерий оценки — FFF. Если взаимозаменяемость сохранена, новая идентификация не требуется. Если нарушена — требуется.

NASA Systems Engineering Handbook (NASA/SP-2016-610 Rev. 2) рассматривает управление конфигурацией как сквозную дисциплину и развивает эту мысль через понятие функциональной и физической идентичности. Изменение конфигурации оценивается по его влиянию на характеристики, требования и взаимозаменяемость (interchangeability) элемента в составе общей системы. Если для замены необходимо переделать сопрягаемые элементы или модифицировать систему, взаимозаменяемость нарушена. Объект не может считаться тем же.

MIL-HDBK-61A «Configuration Management Guidance» (2001) формулирует ещё более строго:

A change is classified as affecting interchangeability when it alters the physical or functional characteristics that determine whether one item can be used in place of another.

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

CMII Institute в стандарте CMII Release 3.0 (§4.2) вводит дополнительное понятие:

A configuration item is identified by its ability to perform a required function. Changes that do not affect this ability are managed as revisions of the existing CI. Changes that do affect this ability require establishment of a new CI.

(Конфигурационная единица идентифицируется по её способности выполнять требуемую функцию. Изменения, не затрагивающие эту способность, управляются как ревизии существующей конфигурационной единицы. Изменения, затрагивающие эту способность, требуют создания новой конфигурационной единицы.)

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

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

Отечественная инженерная практика решает тот же вопрос через систему обозначений и правила внесения изменений.

ГОСТ Р 2.101-2023 «Единая система конструкторской документации. Виды изделий» устанавливает, что изделие имеет обозначение. Обозначение является идентификатором объекта. Если изделие сохраняет обозначение, оно считается тем же изделием. Если получает новое обозначение, оно считается новым.

Но когда необходимо менять обозначение? Ответ даёт инженерная практика, закреплённая в стандартах ЕСКД.

ГОСТ Р 2.503-2023 «Единая система конструкторской документации. Правила внесения изменений» прямо связывает допустимость изменения документа с взаимозаменяемостью. Стандарт устанавливает, что изменения в документы вносят, если они не нарушают взаимозаменяемость изделия с изделиями, изготовленными ранее. Если изменение нарушает взаимозаменяемость изделие получает новое обозначение, а изменения в документы ранее изготовленных изделий не вносятся.

Таким образом, ЕСКД и международные стандарты CM говорят об одном и том же, используя разную терминологию. Критерий один: взаимозаменяемость.

4.7. Практические примеры

Рассмотрим несколько ситуаций, чтобы убедиться, что критерий FFF работает не только в теории.

Болт М8×20. Изменено покрытие: оцинковка заменена на фосфатирование. Размеры те же. Резьба та же. Прочность та же. Болт можно вывернуть и ввернуть новый без каких-либо доработок. FFF сохранён. Это изменение описания.

Болт М8×20. Изменён на М10×30. Другой диаметр. Другая длина. Другая резьба. Старое отверстие не подходит. FFF нарушен. Это новый объект.

Редуктор. Изменён материал шестерни: сталь 40Х заменена на сталь 18ХГТ. Размеры те же. Передаточное отношение то же. Присоединительные размеры те же. Редуктор можно снять и поставить новый. FFF сохранён. Изменение описания.

Редуктор. Изменён диаметр выходного вала с 50 мм на 60 мм. Муфта не подходит. Подшипниковый узел другой. FFF нарушен. Новый объект.

Насос. Изменён поставщик уплотнения. Размеры уплотнения те же. Материал другой, но характеристики сохранены. Насос работает так же. FFF сохранён. Изменение описания.

Насос. Изменён расход с 100 м³/ч на 150 м³/ч. Другая производительность. Другая мощность двигателя. Другая характеристика. FFF нарушен. Новый объект.

4.8. Почему этот критерий не является произвольным

Может показаться, что FFF — это условность. Почему именно форма, посадка и функция? Почему не стоимость? Не масса? Не цвет?

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

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

Именно поэтому критерий привязан не к внутренним свойствам объекта, а к его отношению с окружением. Взаимозаменяемость — это свойство не объекта самого по себе, а объекта в контексте системы.

4.9. Что происходит, когда критерий не заложен в модель

Если информационная система не различает изменение описания и изменение идентичности, возникает один из двух антипаттернов.

Первый: всё является версией. Любое изменение фиксируется как новая Revision одного и того же объекта. Через несколько лет под одним идентификатором оказываются объекты, которые не являются взаимозаменяемыми. Инженер видит «Насос Н1, Revision C» и не может понять: можно ли заменить насос Revision A на Revision C без переделки? Система не отвечает на этот вопрос, потому что модель не содержит критерия.

Второй: всё является новым объектом. Любое изменение приводит к созданию нового идентификатора. Через несколько лет система содержит сотни объектов, которые по сути являются одним изделием с уточнённой документацией. Найти историю становится невозможно. Связи теряются. Отчётность усложняется.

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

4.10. Следствие для модели данных

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

Объект (изделие)
    |
    +-- Определение
            +-- Версия A
            +-- Версия B   ← изменение описания

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

Объект A (изделие)
    |
    +-- Определение
            +-- Версия A

Объект B (новое изделие)   ← изменение идентичности
    |
    +-- Определение
            +-- Версия A

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

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

Принцип FFF хорошо работает для материальных объектов: деталей, узлов, механизмов, изделий. Но он не является абсолютным.

Для программного обеспечения понятие взаимозаменяемости размыто. Программа не имеет физической формы. Её нельзя вынуть из системы и поставить другую без переделки интерфейсов. Критерий FFF в классическом смысле здесь не применим.

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

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

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

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

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

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

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

Этот критерий закреплён в международных стандартах управления конфигурацией (ANSI/EIA-649-D, NASA Systems Engineering Handbook, MIL-HDBK-61A, CMII) и в отечественной системе ЕСКД (ГОСТ Р 2.101-2023, ГОСТ Р 2.503-2023). Он не является произвольным. Он отражает фундаментальное свойство инженерной деятельности: объект существует не изолированно, а в системе, и его идентичность определяется отношением с окружением.

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

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

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

Источники:

• ANSI/EIA-649-D, Configuration Management Standard, SAE International, 2019. §5.3.
• NASA/SP-2016-610, Rev. 2, NASA Systems Engineering Handbook, NASA, 2016. (Раздел о Configuration Management и interchangeability).
• MIL-HDBK-61A, Configuration Management Guidance, U.S. Department of Defense, 2001. §3.2.
• CMII Institute, CMII Standard for Configuration Management, Release 3.0. §4.2.
• ГОСТ Р 2.101-2023. Единая система конструкторской документации. Виды изделий.
• ГОСТ Р 2.503-2023. Единая система конструкторской документации. Правила внесения изменений.
• ГОСТ 2.114-2016. Единая система конструкторской документации. Технические условия.
• ГОСТ Р 2.005-2023. Единая система конструкторской документации. Термины и определения.

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