7.6 Значение текстового атрибута компонента не должно заканчиваться точкой.
8 Функциональные требования к компонентам
8.1 Компонент должен «вести себя» таким образом, чтобы отражались его функциональное назначение и взаимосвязи с другими компонентами.
8.2 В среде программного обеспечения, как правило, существует возможность разработать компонент с тем или иным числом предварительно заданных фиксированных параметров, которыми располагает реальный физический строительный элемент. При наличии предварительно настроенных вариантов компонента снижение его производительности либо затруднение в его использовании должны быть минимальными.
8.3 Компонент следует моделировать таким образом, чтобы он мог быть подсоединен к другим компонентам и функционировать совместно с ними, если совместное функционирование поддерживается и соответствует задачам разрабатываемой модели.
9 Правила именования компонентов и их атрибутов
9.1 Правила именования компонентов, приведенные в настоящем разделе, предназначены для программного обеспечения, работающего на основе файловой системы хранения данных.
9.2 Система именования должна состоять из:
- общих правил именований;
- схем именований.
П р и м е ч а н и е – Пример системы именования файлов компонентов приведен в А.15–А.16 (приложение А).
9.3 У компонента должно быть уникальное имя и описание.
9.4 Правила именования атрибутов
9.4.1 Единицы измерения в названии атрибута не указываются.
9.4.2 Атрибуты со значениями, предполагающими логические типы данных (Да/Нет), должны именоваться так, чтобы значение обязательно было присвоено (например, «Наличие Подоконника» – Да/Нет).
- р и м е ч а н и е – Пример правил именования атрибутов приведен в А.17 (приложение А).
9.5 Правила именования материалов
9.5.1 Имя материала должно начинаться с заглавной буквы, за которой следуют строчные. Если название состоит из двух и более слов, то каждое слово начинается с заглавной буквы и все слова пишутся слитно.
9.5.2 Файлу с изображением материала имя присваивается таким же образом, как и материалу, с расширением, соответствующим формату применяемого графического файла.
- р и м е ч а н и е – Пример правил именования материалов приведен в А.18 (приложение А).
10 Требования к форматам компонентов
10.1 По форматам файлов компоненты могут быть представлены:
- в открытом формате IFC (версии 2x3 и выше);
- в исходных форматах (форматы файлов компонентов и файлов проекта применяемого программного обеспечения).
11 Требования к метаданным компонентов
11.1 При организации баз/каталогов/библиотек компонентов, например, в виде интернет-хранилищ, необходимо обеспечивать удобный поиск необходимого контента. Как правило, такой поиск осуществляется по метаданным. Поиск по метаданным – поиск по атрибутам компонента, поддерживаемым конкретной поисковой системой.
11.2 Для организации поиска рекомендуется применять идентификационные атрибуты, имя файла, формат файла, код по применяемой системе классификации, дату создания и другие возможные метаданные.
Приложение А Рекомендации по разработке компонентов
А.1 Компоненты могут объединяться в сборки (например, «сантехкабина», «тепловой узел», «трансформаторная подстанция»), которые рекомендуется применять для формирования тематических каталогов/баз/библиотек повторного применения.
А.2 Компонент должен быть однозначно идентифицирован. Для этого рекомендуется использовать:
- уникальное имя;
- глобальный уникальный идентификатор, который применяется для идентификации ресурсов;
- код по классификатору (при его наличии).
А.3 Для минимизации числа разрабатываемых компонентов и их унификации рекомендуется создавать параметрические компоненты.
А.4 Рекомендации к отображению графических обозначений:
для соответствия требованиям стандартов ЕСКД и СПДС (например, ГОСТ 2.303 и ГОСТ 2.306), предъявляемым к оформлению проектной и рабочей документации, при разработке компонента рекомендуется включать в его состав условные графические обозначения.
А.5 Для разработки компонентов рекомендуется применять три уровня геометрической проработки:
- LOD 200;
- LOD 300;
- LOD 400.
П р и м е ч а н и е – Компоненты на уровне проработки LOD 100 представляют собой концептуальные формообразующие элементы и как таковые не нуждаются в предварительной подготовке соответствующих компонентов, а на уровне LOD 500 – полностью определенные компоненты, которые отличаются от уровня LOD 400 только размерами, которые соответствуют фактическому исполнению проектных решений . По этим причинам для разработки баз/библиотек/каталогов компонентов рекомендуются уровни проработки LOD 200, 300 и 400.
А.6 Компоненты типа «обобщенный» рекомендуется представлять на уровнях проработки LOD 200 и LOD 300.
А.7 Компоненты типа «продукт» рекомендуется представлять на уровне проработки LOD 400.
П р и м е ч а н и е – При отсутствии соответствующих компонентов низкого уровня проработки допускается применять компоненты более высокого уровня.
А.8 Компоненты инженерного/технологического оборудования рекомендуется разрабатывать с учетом резервирования пространства для обслуживания, которое рекомендуется включать как часть компонента.
А.9 При необходимости разработки компонента с определенным материалом рекомендуется включать в него цвета, образцы штриховок/заливок и файлы с изображением текстуры в соответствующем масштабе.
А.10 В компонентах типа «продукт» рекомендуется применять материалы с определенными свойствами.
А.11 Значение текстового атрибута рекомендуется указывать последовательно с первой заглавной буквы и без форматирования текста (т.е. без выделения жирным шрифтом и курсивом).
А.12 Значение атрибута компонента может быть выражено в виде формулы – в случае, если его значение зависит от других атрибутов.