Requality

h1. Вступление

Разработка систем, в том числе программных, должна сопровождаться процессом тестирования. Используемые при разработке систем стандарты, в том числе DO-178С для разработки программного обеспечения в сфере авионики, рассматривают необходимость тестирования системы с использованием требований, в том числе представленных в форме документов.

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

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

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

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

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

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

Процесс тестирования может быть произведен над разными формами представления требований. Будет рассматриваться использование текстового представления.

Рассмотренный подход к тестированию позволяет выделить жизненный цикл требования в ситуации отсутствия изменений (Рис. 1). Вопрос о влиянии изменений на процесс будет рассмотрен подробней в пункте 1.1.2.

!re-image1.png!

_Рисунок 1. Жизненный цикл тестов_

h2. Проблемы, связанные с проектированием тестов

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

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

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

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

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

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

h1. 1. Особенности проектирования тестов

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

h2. 1.1. Выделение каталога требований

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

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

!re-image2.png!

Рисунок 2. Получение каталога требований из документа

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

h2. 1.2. Управление изменениями

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

!re-image3.png!

Рисунок 3. Изменение исходного документа

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

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

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

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

h2. 1.3. Схожие артефакты и фрагменты каталога требований

Рассматривая вопрос описания схожих артефактов в каталоге требований, приведем набор тестовых ситуаций для проверки требования к надежности прибора к высоким температурам:

* Req 1. Требования к надежности прибора

** Req 1. 1. Обеспечение устойчивости корпуса прибора к высоким температурам

*** Req 1. 1. _ TestPurpose 1. При помещении корпуса  прибора в область с температурой 200 градусов Цельсия температура внутренней стороны корпуса не должна превышать 	50 градусов	

*** Req 1. 1. _ TestPurpose 2. При помещении корпуса прибора в область с температурой 300 градусов Цельсия температура внутренней стороны корпуса не должна превышать 75 градусов

*** Req 1. 1. _ TestPurpose 3. При помещении корпуса прибора в область с температурой 400 градусов Цельсия температура внутренней стороны корпуса не должна превышать 	100 градусов

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

* Req 1. 1. _ TestPurpose N. При помещении корпуса прибора в область с температурой K1 	градусов Цельсия температура внутренней стороны корпуса не должна превышать K2 градусов

В примере символами N, K2, K3 обозначены места описания параметров. Можно определить взаимозависимость значений. Так, для K1 можно определить через множество допустимых значений,  а K2 имеется возможность определить по формуле K1 / 4.

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

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

h1. 2. Варианты использования

Для решения проблем с рассмотренными в п. 1 особенностями процесса проектирования тестов были реализованы механизмы параметризации и повторного использования. При этом было выделено два основных варианта использования указанных механизмов.

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

Например, может быть использован набор сообщений [OK, ERROR, ABORT] для которого OK и ERROR используются во всех случаях, а ABORT доступен не всегда. В первом случае будет доступен набор [OK, ERROR], во втором - [OK, ERROR, ABORT].

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

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

h1. 3. Список изменений

Рассмотренные варианты использования потребовали введения новых элементов:

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

новый элемент каталога требований, Virtual Node, позволяющий указать место в котором будет производится повторное использование согласно одному из вариантов использования

механизм определения параметров с возможностью описания генераторов их значений

механизм определения количества и состава переиспользованных элементов — для ВИ 1 данный пункт включает в себя возможность указания количества копий, для ВИ 2 — возможность скрытия некоторых элементов

h2. 3.1. Особенности Virtual Node.

Виртуальные вершины представляют собой новый элемент каталога требований используемый для повторного использования фрагментов каталога требований. Процесс повторного использования в общем случае осуществляется путем выбора подхода к повторному использованию с последующим указанием целевого элемента для которого будет проводиться переиспользование. На данный момент имеется два возможных подхода к повторному использованию: «Reuse» — использование обобщенного описания, копии которого будут добавлены к VNode или определение "базового" элемента «Base element», при котором копии прямых потомков целевого элемента будут добавлены к VNode. Для обобщенного описания также доступны настройки связанные с определением количества копий.

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

Также имеется возможность скрытия VNode в декларативном дереве с возможностью отмены скрытого режима. В скрытном режиме вместо VNode отображаются его потомки, то есть повторно использованные элементы.

h2. 3.2. Особенности определения параметров

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

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

Также для ВИ-2 количество копий исходного элемента определяется на основе значений выбранных параметров.  На данный момент предполагается два основных варианта — использование одной копии(независимой от параметров) или сопоставления копии одному из значений параметра или сочетания значений параметров. 

Для пояснения последнего варианта приведем пример двух параметров с наборами значений T = [200, 300, 400] и M = [steel, iron]. Для данного набора можно построить декартово произведение содержащее 6 вариантов пар значений. При этом каждой паре ставится в соответствие одна копия исходного элемента. В полученных копиях определяются свойства соответствующие значениям параметров в соответствующей паре. Так, для первой копии будут определены свойства T = 200 и M = steel.

Для ВИ-1 дополнительно требуется определить возможность скрытия некоторых элементов дерева требований. Для этого в декларативном дереве для соответствующих элементов имеется возможность описания условий видимости соответствующих элементов. При использовании элемента в виртуальном дереве производится проверка условия с последующим отображением или сокрытием элемента. 

Примером может послужить введение некоторого параметра $has_abort влияющего на видимость элемента ABORT. При этом условием можно обозначить предикат «$has_abort==true». В виртуальном дереве при определении соответствующего параметра, доступного для элемента ABORT с именем $has_abort, он будет заменен на соответствующее значение.

h1. 4. Примеры реализации в GUI

h2. 4.1. Пример "reuse" переиспользования

Рассмотрим пример с проверкой устойчивости прибора к высоким температурам. Для организации повторного использования согласно ВИ 2 требуется определить обобщенное описание. Для этого в Requality explorer создадим объект Test Purpose (Рисунок 4). 

!re-image4.png!

Рисунок 4. Обобщенное описание тестовой ситуации — объект Test Purpose

Для созданного объекта в поле Description укажем обобщенное описание с параметрами $K1 и $K2 (Рисунок 5).

!re-image5.png!

Рисунок 5. Обобщенное описание тестовой ситуации — полe Description

После этого создадим требование с именем "Обеспечение устойчивости корпуса прибора к высоким температурам" которое будет содержать итоговые тестовые ситуации. Для требования создадим элемент Virtual Node через который будет осуществляться повторное использование (Рисунок 6).

!re-image6.png!

Рисунок 6. Новый элемент Virtual Node

Для созданного элемента определим генерируемые параметры $K1 и $K2. Для этого во вкладке Generators свойств элемента добавим два генератора при помощи кнопки "Add new generator". После указания имен генераторов список генераторов приобретет вид соответствующий Рисунку 7. 

!re-image7.png!

Рисунок 7. Список генерируемых параметров

Опишем свойства каждого из генераторов. Для $K1(Рисунок 8), значение которого будет обозначать проверяемую температуру, определим вид генерации — цикличный перебор значений в указанном диапазоне и укажем видимость параметра — Local, данный параметр будет использоваться только в механизме переиспользования в данном элементе. 

!re-image8.png!

Рисунок 8. Настройки генерации $K1

$K2 можно определить как зависимый от $K1 по определенной формуле. Для этого выберем вид генератора — по формуле ("BY_FORMULA") и укажем область видимости генератора — в рамках прямых потомков(DIRECT_CHILDREN), что соответствует прямым потомкам текущего элемента, то есть — для определяемых тестовых ситуаций. Значение определим как  " ($K1/4)+"" ", что соответствует значению $K1 поделенному на 4 в целочисленном формате. 

Предварительный просмотр отображает NaN, так как генерация данного параметра для Virtual Node некорректна, в рамках его потомков значение параметра будет определяться относительно конкретных значений $K1, в то время как в текущем элементе данный параметр представляет собой набор значений. Возможным решением могло быть описание данного параметра в рамках описания тестовой ситуации(01/T01_01) с областью видимости "Local".

!re-image9.png!

Рисунок 9. Настройки генерации $K2

В свойствах переиспользования(вкладка Iteration) укажем целевой элемент — тестовую ситуацию "01/01_T1"(Рисунок 10, область 1), вид переиспользования - "Reuse iteration"(Рисунок 10, область 2). Определим настройки переиспользования — имя укажем как ""Test purpose"+_I"(Рисунок 10, область 3), что соответствует обозначению тестовой ситуации с добавлением номера копии(_I соответствует нумерации от 1, _i нумерации от 0). Определим итерируемую переменную нажав "Add var." и выбрав $K1, определенный выше(Рисунок 10, область 4).

!re-image10.png!

Рисунок 10. Настройки переиспользования

В результате выполнения перечисленных операций дерево требований примет вид соответствующий Рисунку 11. Для элемента Virtual Node было определено три потомка с именами "Test Purpose 1", "Test Purpose 2" и "Test Purpose 3" определенными по формуле, указанной в свойствах.

!re-image11.png!

Рисунок 11. Дерево требований

Рассмотрим свойства одной из тестовых ситуаций под именем "Test Purpose 1". На Рисунке 12 представлена основная панель свойств данного элемента. Определены два свойства элемента - $K1, значение которого соответствует первому из значений определенного в Virtual Node генератора и $K2, значение которого определилось согласно формуле.

!re-image12.png!

Рисунок 12. Основное окно свойств Test Purpose 1

При этом во вкладке Description данного элемента текст описания соответствует приведенному Рисунку 13. Имена параметров, отображаемые на Рисунке 5 были заменены на соответствующие значения.

!re-image13.png!

Рисунок 13. Окно свойств описания Test Purpose 1

h2. 4.2. Пример "base element" переиспользования

Рассмотрим пример с повторным использованием набора требований к функции на двух потоках Streem1 и Streem2. Для этого создадим требование для повторного использование с именем «Codes» содержащее три тестовые ситуации соответствующие определенным кодам с идентификаторами «OK», «ABORT» и «ERROR»(Рисунок 14).

!re-image14.png!

Рисунок 14. Тестовые ситуации для кодов

Для тестовой ситуации определим условия при которых она должна отображаться. Для этого в панели свойств в разделе «Advanced» (Рисунок 15) укажем значение поле Predicate равным «$has_abort==true». При вычислении подобного выражения при отсутствии $has_abort или при значении параметра равном false тестовая ситуация отображаться не будет.

!re-image15.png!

Рисунок 15. Условие видимости тестовой ситуации ABORT

После описания тестовых ситуаций становится возможным повторно использовать полученный фрагмент каталога требований. Для этого создадим два требования «Streem1» и «Streem2». Для каждого из требований создадим по элементу Virtual Node. Определим свойства каждой виртуальной вершины в панели Itaration (Рисунок 16) — укажем требование «Codes» как целевое требование и выберем вид переиспользования - «Base  iteration»

!re-image16.png!

Рисунок 16. Свойства виртуальной вершины

Для использования в требовании «Streem2» тестовой ситуации «ABORT» определим для соответствующего требования в свойствах генераторов параметров (Рисунок 17) параметр «$has_abort» как генерируемое по формуле «true» значение с видимостью для всех потомков. 

!re-image17.png!

Рисунок 17. Свойства генераторов параметров для требования «Streem2»

В результате выполнения всех вышеперечисленных операций дерево требований примет вид соответствующий Рисунку 18.

!re-image18.png!

Рисунок 18. Дерево требований после выполнения операций

При выполнении операции сокрытия виртуальных вершин (путем вызова в контекстном меню RequalityCNF для соответствующего элемента пункта меню «Hide Virtual Node») дерево требования примет вид соответствующий Рисунку 19. Стоит отметить, что в левом-нижнем углу повторно использованных тестовых ситуаций отображается символ обозначающий что они являются виртуальными.

!re-image19.png!

Рисунок 19. Дерево требований после сокрытия Virtual Node

h1. 5. Особенности реализации — техническая сторона

h2. 5.1. Представление генераторов свойств

Генераторы параметров хранятся в виде скрытого свойства _generators. Свойство содержит описания всех генераторов в виде списка строк, в каждой из которых хранятся данные для описания генератора разделенные знаком «|». При этом хранимые данные можно разделить на общие для всех данные (тип итератора, имя генерируемого свойства, значение доступности) и данные уникальные для определенного вида генераторов(например, формула для генератора свойства по формуле).

h2. 5.2. Хранение и редактирование информации о переиспользовании

Как уже было упомянуто выше — для организации процесса переиспользования используется дополнительный элемент каталога требований под названием Virtual Node.  Для него определена ссылка на целевой объект _target. Кроме этого возможно указание специфичных для определенного вида переиспользования параметров, например, указание на способ итерирования по параметрам. Дополнительно может храниться параметр скрывающий VNode в дереве требований и UniEditor.

Как уже было упомянуто в п.1, механизмы переиспользования вводят понятие виртуального каталога(или дерева) требований. Кроме изначального каталога требований, т. н. декларативного дерева, при введении переиспользования появляется т. н. виртуальное дерево, содержащее в себя копию исходного дерева с добавлением «виртуальных» элементов, а именно — копий элементов появившиеся в результате работы VNode.

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

Примером может послужить рассмотренное выше переиспользование требований к функции для sin и cos. Для указанного примера в декларативном дереве хранится обобщенное описание требований к функции и два указание на места переиспользования в виде Virtual Node. При этом копии в виртуальном дереве могут быть отредактированы, в таком случае, при редактирования свойств сохраняются только отличные от исходного элемента свойства. 

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

Доступны операции над отдельными элементами и фрагментами каталога требований. Для удаления элемента можно удалить его через пользовательский интерфейс или указать в рамках ВИ-1 такие условия при которых элемент не будет повторно использован.

Также доступно добавление новых элементов в виртуальный фрагмент каталога требований. В подобной ситуации элементы будут добавлены к некоторой скрытой папке в декларативное дерево.

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

h2. 5.3. Построение «виртуального» дерева

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

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

При загрузке декларативного дерева при загрузке Virtual Node производится инициация объекта виртуального дерева если подобное не было проведено ранее

При инициации элементов-копий для конкретного Virtual Node производится привязка к полученным в п. 1 данными — если для полученного элемента хранились изменения параметров — загружается список изменений, если копия была отмечена как удаленная — то соответствующий элемент дерева требований не вносится как потомок Virtual Node. При этом если информация по изменениям относится к потомку непосредственной копии, то они будут загружены при загрузке параметров потомка или его children.

Результат выполнения п. 3 — набор элементов — потомков VNode после применения набора изменений. UUID этих элементов записываются как children элементы VNode. При этом при вызове метода getChild(i) для соответствующих потомков возвращаются элементы из виртуального дерева, в то время как первичные VNode находятся в декларативном(под первичностью понимается возможность вложенности VNode при котором в фрагменте каталога требований являющимся копией также содержится VNode, который уже будет определен в виртуальном дереве)

При закрытии проекта и связанного с ним каталога требований все изменения относительно декларативных переиспользованных фрагментов сохраняются в виде параметра _root элемента в форме строки\массива строк.

h2. 5.4. Реагирование на изменения

Отдельно стоит отметить вопрос реагирования на изменения. Под изменениями могут пониматься как изменения виртуального фрагмента каталога требований, так и изменение исходного фрагмента каталога требования.

Изменения виртуального дерева:

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

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

Для операции копирования копия также добавляется к скрытой части декларативного каталога требований.

При удалении или переносе элемента в виртуальном фрагменте оно обозначается как удаленное в хранилище. Во втором случае перед этим создается полная копия с потерей привязки.

Изменения исходного по отношению к виртуального фрагмента (изменения игнорируются для отмеченных как удаленные копий и фрагментов каталога)

При изменении свойств элемента (не сгенерированных) — происходит определение реакции виртуальных копий — если в месте изменения находится виртуальный элемент или определенный вручную элемент, то он замещается новым. Если измененный элемент виртуальный то изменения игнорируются

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

Изменения в генераторах свойств — отдельно стоит отметить возможность изменения генераторов свойств и\или генерируемых ими значений. В таком случае происходит замещение свойств текущего элемента и элементов потомков по правилам определенным согласно доступности генератора. 

При этом в случае возникновения различных потенциальных источников свойства происходит переопределение значений по правилам отображенным на Рисунке 20. Под «свойством артефакта» понимается определенное пользователем свойство, под параметрами — полученные с помощью генераторов свойства.

!re-image20.png!

Рисунок 20. Приоритет значений свойств согласно уровню доступности