ГОСТ Р 55346—2012
Формальные выражения:
UR1:
4.3.267 Прикладной компонент requirement_class_relationship
Прикладной компонент requirement_class_relationship определяет взаимосвязь между двумя при
кладными компонентами requirement_c!ass.
Примечание — Семантика этой взаимосвязи определяется с помощьюатрибута relationshipJype.
EXPRESS-описание:
*)
ENTITY requirement_class_relationships;
description : OPTIONAL text_select:
related_class:requirement_class;
relating_dass: requirement_dass;
relationship_type : label:
END_ENTITY;
(’
Определения атрибутов.
Атрибут description: Этот атрибут определяет дополнительную текстовую информацию, относящу
юся к специализации.
Атрибут related_class: Этот атрибут определяет второй прикладной компонент requirement_dass в
указанной взаимосвязи.
Атрибут relatir»g_class: Этот атрибут определяет первый прикладной компонент requirement_class
в указанной взаимосвязи.
Атрибут relationshipjype: Этот атрибут определяет характер указанной взаимосвязи. Там. где это
применимо, должны использоваться следующие состояния (значения) в этом компоненте:
- состояние spedalization: Атрибут related_class для прикладного компонента requirement_class
является экземпляром атрибута relating_class для прикладного компонента requirement_class;
- состояние equivalence: Атрибут related_class для прикладного компонента requirement_dass яв
ляется синонимом атрибута relating_class для прикладного компонента requirement_dass.
4.3.268 Прикладной компонент requirement_composition_relationship
Прикладной компонент requirement_composition_re!ationship определяет связь при разбиении при
кладных компонентов requirement_definition и requirement_occurence.
Примечание 1 — Прикладной компонент requirement_definition может быть разделен на любое число
прикладных компонентов requirement_occurence.
Примечание 2 — Одноважное предположениесостоитвтом. чтомодельбудет применятьсядля пред
ставления множества вариантов системной спецификации. Соответственно, существует значительный выигрыш
от совместного или повторного использования в этих вариантах общих проектных элементов. Указанные предпо
ложения приводят кмодели, в которой четыреобъекта входят впредставление единственного требования, каким
он видится с точки зрения пользователя. Структура модели будет описана ниже.
Прикладной компонент requrrement_de(inition содержит описание всего того, что требуется. В модели со
держатся три субтипа компонента, которые поддерживают различные представления требования. При этом ни
каких предположений не делается в отношении контекста, в котором используется требование и которое озна чает
отсутствие связей между требованиями, определяемыми прикладным компонентом requirement_definition.
Прикладной компонент requirement_definit»on может давать определение любому числу прикладных компонентов
requirement_occurence.
Прикладной компонент requirenrentjnstance является контекстно-зависимым представлением требования и
может присваиваться прикладномукомпонентуsystem_view (вархитектуре системныхфункциональных модулей).
Все взаимосвязимежду требованиями определены вприкладном компоненте requirementjnstance.
Прикладной компонент requirement_composition_relationship является средством разделения требова
ний. Для каждого вводимого в состав требования должен быть конкретизирован новый прикладной компонент
requirement_composition_relationship.
Прикладной компонент requirement_occurence является промежуточным представлением требования,
которое включается в модель для обеспечения максимальной отслеживаемости и усиления поддержки по
вторного использования этого требования в нескольких различных контекстах (в различных вариантах си
стемы или системах). Прикладной компонент requirement_occurence. использующий только один прикладной
компонент requirement_definition в качестве его определения, может служить в качестве определения любого
числа прикладных компонентов requirementjnstance.
139