ГОСТ Р 58908.1-2020/МЭК 81346-1:2009 Промышленные системы, установки, оборудование и промышленная продукция. Принципы структурирования и коды. Часть 1. Основные правила

Приложение C
(справочное)

Обращение с объектами

C.1 Общие положения

Принципы структурирования настоящего стандарта не предназначены для наложения каких-либо предписаний или ограничений на то, как должен выполняться процесс разработки и проектирования.

Принципы сфокусированы на том, как управлять и решать текущие задачи с точки зрения объектов по мере развития процесса проектирования и разработки. Аспекты используются как средство, помогающее организовать объекты независимо от того, как они появляются или исчезают.

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

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

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

C.2 Создание и срок службы объекта

C.2.1 Общие положения

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

Таким образом, объект может быть создан с достаточно неполным пониманием того, чем он должен стать. В самом простом случае он является просто "заполнителем" для информации, которому присваивается имя и, возможно, он идентифицируется посредством кодового обозначения в контексте разрабатываемой системы. Данный заполнитель используется для сбора информации в процессе проектирования и разработки системы. Подобная "пустая" структура может быть расширена, например, для использования в качестве шаблона.

Как следствие этого, и особенно, если в работе участвуют несколько проектировщиков, вполне вероятно, что в системе объекты, которые очень тесно связаны или даже "одинаковы", определяются с точки зрения разных аспектов. Необходимо находить подобные близкие связи и устранять возможные повторы. См. C.2.3.

Подобные явления происходят, например, когда объект, определенный посредством требований с точки зрения аспекта функции, должен быть реализован существующим продуктом. Разница по сравнению с предыдущим случаем заключается в том, что в этом случае один объект внутри рассматриваемой системы связан с объектом, изначально внешним по отношению к нему. См. C.2.2.

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

C.2.2 Реализация объекта

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

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

Примечание 1 - Ничто не мешает такому объекту быть идентифицированным из нескольких аспектов и адресованным системой кодовых обозначений. Для упрощения принимают, что участвует только один объект.

- Разработчик считает, что эти требования могут быть удовлетворены с помощью продукта, доступного на рынке, то есть объекта, изначально внешнего для рассматриваемой системы. Информация, связанная с этим объектом, организована в соответствии с решением поставщика.

Необходимо интегрировать этот продукт как компонент рассматриваемой системы. Существует только два способа интегрировать эту информацию:

- Путем копирования. Информация, связанная с продуктом, копируется (частично или полностью по мере необходимости) в информацию, связанную с существующим объектом в системе (см. рисунок C.1).

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

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

Рисунок C.1 - Интеграция внешней информации путем копирования