Содержание к диссертации
Введение
Глава 1. Бизнес-логика программ 10
1.1. Основные понятия и определения 10
1.1.1. История бизнес-правил в экономике и в программировании 10
1.1.2. Определения бизнес-правила и бизнес-логики 12
1.1.3. Сравнение моделей бизнес-правил 13
1.2. Основные подходы к автоматизации работы с бизнес-правилами 16
1.2.1. Использование бизнес-правил для проектирования приложения... 17
1.2.2. Извлечение бизнес-логики из кода приложения 18
1.2.3. Программные средства для проектирования приложений с использованием бизнес-правил 19
1.2.4. Программные средства для извлечения бизнес-логики 24
Глава 2. Методы извлечения бизнес-логики 29
2.1. Постановка задачи 29
2.2. Варианты решений 30
2.2.1. Слабая автоматизация 31
2.2.2. Сильная автоматизация 32
Глава 3. Автоматическое создание бизнес-правил на основе семантических свойств программ 35
3.1. Восстановление вычислений 35
3.1.1. Специальный информационный граф как входные данные метода 36
3.1.2. Построение и преобразование операторного графа 38
3.1.3. Анализ условий 44
3.1.4. Создание последовательности бизнес-правил 45
3.1.5. Группировка бизнес-правил в бизнес-процедуры 50
3.2. Валидация экранных портов 55
3.2.1. Построение и анализ операторного графа 55
3.2.2. Создание бизнес-правил 59
3.3. Поиск использований заданной переменной 60
Глава 4. Business Rule Manager - средство анализа бизнес-логики старых приложений 63
4.1. Общее знакомство с инструментом 63
4.1.1. Представление бизнес-правил 63
4.1.2. Пользовательский интерфейс 64
4.2. Возможности инструмента Business Rule Manager 68
4.2.1. Жизненный цикл бизнес-правил 69
4.2.2. Проверки бизнес-правил 73
4.2.3. Поиск по атрибутам и групповое редактирование 76
4.2.4. Обнаружение входных и выходных данных и подстановка терминов предметной области 78
4.3. Особенности реализации методов автоматического создания бизнес-правил 78
4.3.1. Интерфейсные решения, или особенности с точки зрения пользователя 79
4.3.2. Программные решения 89
4.4. Применение на реальных приложениях 93
4.5. Сравнение с другими программными средствами 103
Заключение 107
Список литературы 109
Приложение
- Основные подходы к автоматизации работы с бизнес-правилами
- Поиск использований заданной переменной
- Возможности инструмента Business Rule Manager
- Интерфейсные решения, или особенности с точки зрения пользователя
Введение к работе
Актуальность проблемы
В современном обществе компьютеры используются практически во всех областях человеческой деятельности, и компьютерные программы составляют важную часть бизнес-процессов предприятий и организаций. Подобные программы создавались в течение не одного десятка лет и на сегодняшнем этапе требуют постоянной поддержки, модернизации и адаптации к меняющимся условиям их применения. Ситуация осложняется тем, что существенная часть этих приложений разработана с использованием устаревших языков программирования COBOL, PL/1, Natural и других, мало употребляемых современными программистами. Часто такие программы не имеют документации вообще или документация не соответствует коду, поскольку она уже не отражает многочисленных изменений, произведенных за годы эксплуатации. Кроме того, исходный код рассматриваемых приложений может оказаться частично утраченным, что затрудняет компиляцию и отладку.
Также нельзя не отметить, что для любого изменения существующих бизнес-приложений необходимо понимание предметной области их применения, которым программисты в большинстве случаев не владеют. Поэтому важно предоставить системным аналитикам средство работы с бизнес-логикой приложений, требующее от пользователя лишь минимальных навыков программирования. Полученные с помощью такого средства бизнес-правила имеют самостоятельную ценность и являются универсальным методом коммуникации между программистами и аналитиками. В дальнейшем бизнес-правила могут использоваться для корректировки работы имеющейся программы, создания спецификаций новых приложений или документирования кода.
Как показывает практика, многие бизнес-приложения не соответствуют современному уровню развития информационных технологий, поскольку большинство из них было создано до появления персональных компьютеров, сети Интернет и графического интерфейса пользователя. Эти приложения функционируют на устаревшей технике, под управлением архаичных операционных систем и не используют
современные средства хранения и передачи данных. Подобные бизнес-приложения считаются устаревшими или унаследованными (legacy) и, безусловно, нуждаются в модернизации. Возможны различные методы их модернизации, в том числе и с применением таких элементов реинжиниринга (или «обратного проектирования»), как автоматическое извлечение бизнес-логики и автоматический перевод кода приложения на другие языки программирования. Рассмотрим кратко некоторые из этих методов и отметим необходимость использования бизнес-правил для успешного их применения.
Метод разработки нового приложения для полной замены существующего является одним из самых дорогостоящих методов модернизации, требующим значительного времени на проектирование, разработку, тестирование и внедрение нового приложения. Предварительное извлечение бизнес-логики исходного приложения в виде бизнес-правил может быть полезно на всех этапах модернизации: в качестве спецификаций при проектировании и разработке и в качестве тестовых сценариев (use cases) при тестировании. Важно, что соответствие новой системы бизнес-правилам, извлеченным из старой системы, обеспечивает корректность модернизации.
Метод автоматического перевода устаревшего бизнес-приложения на новые языки программирования и новые платформы является более привлекательным. К преимуществам использования этого метода относится быстрота и относительно низкая стоимость проведения модернизации. Однако необходимо отметить, что полная автоматизация для реально используемых бизнес-приложений не всегда возможна и структура автоматически созданного кода не всегда является оптимальной. Данный метод может обеспечить синтаксически корректный перевод с одного языка на другой, но это, как правило, не приводит к улучшению структуры программы и не позволяет выделить действительно интересные фрагменты (бизнес-правила) из устаревшего кода.
Метод извлечения знаний предполагает использование средств извлечения (в том числе и автоматического) и анализа бизнес-правил с последующей реализацией (в том числе и автоматической) полученных правил в новом приложении на новых языках и новых платформах. Этот
метод обеспечивает высокое качество модернизации при высокой скорости проведения работы и относительно низкой ее стоимости.
При использовании любого метода модернизации детали технической реализации устаревших приложений обычно не представляют особой ценности при попытке создания современных аналогов этих приложений. В самом деле, для современных графических приложений, работающих в сети Интернет, совершенно неважно, как именно были реализованы детали пользовательского интерфейса на алфавитно-цифровом дисплее в оригинальной программе или какие средства использовались для обеспечения совместной работы пользователей. Наибольшую ценность представляют используемые в существующих приложениях бизнес-правила и алгоритмы, поскольку именно они определяют, что и как делает приложение.
На сегодняшний день объем существующих бизнес-приложений, нуждающихся в полной замене или дальнейшей модернизации, настолько велик, что актуальность автоматического извлечения бизнес-логики программ не вызывает сомнений.
Цель работы
Цель работы заключается в исследовании методов автоматического построения бизнес-правил на основе семантических свойств программ. Основные задачи в рамках достижения этой цели включают:
Разработку метода восстановления вычислений заданной программной переменной на основе графа информационных зависимостей программы.
Разработку метода валидации экранных портов для построения бизнес-правил из всех проверок корректности значений, вводимых пользователем и попадающих в программу через операторы обработки экранных форм -экранные порты.
Построение вспомогательного алгоритма для валидации сегментов бизнес-правил, позволяющего проверять актуальность правил после редактирования программного кода.
Реализацию всех разработанных алгоритмов в рамках программного средства анализа бизнес-логики старых приложений Business Rule Manager.
Методы исследования
Для решения поставленной задачи нами использовались различные алгоритмы анализа графов, алгоритмы поиска по шаблону. Для обеспечения многопользовательского режима работы применялась оптимистическая стратегия. Кроме того, использовались результаты работы синтаксических анализаторов языков COBOL, PL/1 и др. Входными данными для автоматического извлечения бизнес-правил служили результаты анализа влияния (impact analysis), а именно специальный информационный граф, построенный путем анализа потоков данных. В процессе реализации разработанных алгоритмов использовались методы объектно-ориентированного программирования.
Научная новизна
Исследования в области бизнес-логики занимают важное место в современной информатике. В данной работе исследована возможность автоматического восстановления бизнес-логики на основании анализа семантических свойств программ, выявляемых по исходному коду. В работе определена оригинальная модель представления бизнес-правил, сформулированы основные задачи восстановления бизнес-логики, представлены алгоритмы, которые могут быть не только использованы для старых приложений на языках COBOL, PL/1 и др., но и преобразованы для анализа более современных приложений.
Автоматически построенные бизнес-правила могут быть использованы, в частности, для анализа, документирования, сопровождения и реинжиниринга существующих приложений, а также для проектирования на их основе новых приложений.
Практическая ценность
Практическим результатом работы явилось создание средства Business Rule Manager как одной из важнейших подсистем системы Modernization Workbench анализа старых приложений, которая в настоящее время успешно применяется многими компаниями Европы,
Азии и Америки для выполнения работ в области реинжиниринга. Описанные в работе методы извлечения бизнес-логики широко используются при анализе и модернизации приложений в области банковской деятельности, страхования, снабжения и управления.
Апробация работы
Результаты работы были представлены на конференциях-конкурсах «Технологии Microsoft в теории и практике программирования», проходивших в Новосибирске в 2006 и 2007 годах, на XLV Международной научной студенческой конференции «Студент и научно-технический прогресс» в 2007 году, на VIII Всероссийской конференции молодых ученых по математическому моделированию и информационным технологиям, проходившей в Институте вычислительных технологий СО РАН в 2007 году, на рабочем семинаре «Наукоемкое программное обеспесение» в рамках седьмой международной конференция памяти академика А. П. Ершова «Перспективы систем информатики» (PSF09) в 2009 году, а также обсуждались в ряде встреч с российскими и зарубежными специалистами в области реинжиниринга.
Автором опубликовано 9 печатных работ, из них по теме диссертации - 7 работ.
Структура и объем работы
Диссертационная работа состоит из введения, четырёх глав, заключения и списка литературы. Объем диссертации - 123 стр. Список литературы содержит 40 наименований. Работа включает 4 таблицы и 56 иллюстраций, в том числе полученных с использованием разработанного программного обеспечения.
Основные подходы к автоматизации работы с бизнес-правилами
Бизнес-правила образуют бизнес-логику программного продукта, которую необходимо знать разработчикам как для создания, так и для сопровождения приложения. Существует две в некотором смысле противоположные задачи: 1) построение аналитиком набора бизнес-правил и их дальнейшее использование в разработке приложения и 2) извлечение бизнес-логики программы из ее кода. Первая задача близка к синтезу программ на основе спецификации. Вторая задача может возникать в разных контекстах: для документирования и сопровождения существующего приложения, либо для полной переработки приложения, в частности, переноса на другую платформу.
Соответственно решаемой задаче, можно выделить два основных подхода к автоматизации работы с бизнес-правилами, которые мы подробно рассмотрим в данном разделе вместе с программными продуктами, реализующими эти подходы.
В процессе проектирования приложения бизнес-правила могут выполнять роль спецификаций высокого уровня, так как они наиболее общим образом определяют: что и как должно делать приложение. Такой способ проектирования, включающий построение бизнес-правил и их дальнейшее использование в разработке приложения, привлек широкое внимание исследователей около двадцати лет назад и был хорошо методологически проработан [17, 27]. Использование языков типа UML и специальных програмных продуктов, например, Rational Rose, позволяет проводить даже генерацию исходных текстов проектируемого приложения, по крайней мере, на уровне определения интерфейсов.
Кроме того, с помощью специальных программ моделирования (например, RuleMap компании Bizrules) можно создавать модель бизнес-логики приложения на основе собранных бизнес-правил и проводить тестирование этой логики в различных ситуациях еще на стадии проектирования нового приложения.
Совершенствование технологий делает заманчивым перевод бизнес-приложений, используемых в работе предприятий на протяжении длительного периода (десятки лет) [30], на современные языки. Такой перевод подразумевает понимание их бизнес-логики, информация о которой часто оказывается фрагментарной. Процесс извлечения (восстановления) бизнес-логики, повторная разработка системы и последующее ее внедрение являются довольно трудоемкими и затратными. Поэтому широко применяется и другой вариант — сопровождение бизнес-приложений на старых языках программирования. Стоит заметить, что сопровождение также требует понимания бизнес-логики, с той лишь разницей, что приложение продолжает использоваться и процесс его изменений не такой кардинальный [23].
Процесс восстановления бизнес-логики программных систем, с учетом размера этих систем, непосилен для человека и нуждается в автоматизации. Опыт показывает, что полная автоматизация невозможна как ввиду возникающих алгоритмических проблем, так и потому что требуется непосредственное участие бизнес-аналитика, владеющего знанием предметной области. Тем не менее, инструментальная поддержка процесса анализа чрезвычайно важна.
Имеющиеся программные решения для восстановления бизнес-логики отличаются разными степенями автоматизации процесса и могут быть ориентированы как на сопровождение старых приложений, так и на их трансформацию на основе восстановленной бизнес-логики [29]. Выделяются и программы, предназначенные для узкого класса исследуемых приложений. Например, существует разработка, ориентированная на извлечение бизнес-логики из приложений с трехуровневой архитектурой: пользовательский интерфейс - бизнес-логика - взаимодействие с базами данных [19]. В некоторых системах, например, SoftwareMining BRE Toolkit, бизнес-правила по сути выполняют роль промежуточного представления или промежуточного языка программирования высокого уровня в процессе переноса бизнес-приложения с одной платформы на другую. При такой трансляции удается выделить и сохранить наиболее существенную логику оригинального бизнес-приложения, не заботясь о переносе второстепенных деталей, специфичных для конкретной платформы, таких как интерфейс пользователя, взаимодействие с базой данных или передача данных в сети.
В данной работе (см. Главу 4) подробно рассматривается компонент Business Rule Manager системы перепроектирования программного обеспечения Relativity Modernization Workbench [1, З, 4, 14, 32], предназначенный для восстановления (в том числе и автоматического) бизнес-логики существующих приложений и проводится сравнение данного средства с аналогичными программными продуктами.
В настоящее время существует множество средств работы с бизнес-правилами. Среди программ, предназначенных для проектирования приложений с использованием бизнес-правил, можно отметить:
1. Rational Rose - объектно-ориентированное CASE-средство фирмы Rational IBM - предназначено для автоматизации этапов анализа и проектирования программного обеспечения, а также для генерации кодов на различных языках и выпуска проектной документации.
Поиск использований заданной переменной
Задача поиска использований заданной переменной актуальна, например, для получения информации о том, как в программе использовались данные, введенные пользователем или считанные из базы данных. Отметим, что под использованием здесь мы понимаем не только явное использование исходного значения, но и любых его вычислительных модификаций. Таким образом, эта задача является в некотором смысле противоположной задаче восстановления вычислений, поэтому для ее решения предлагается использовать аналогичные алгоритмы, но со сменой ориентации графа. Однако чтобы результирующие бизнес-правила соответствовали ожиданиям бизнес-аналитика, требуется их дополнительная обработка, исследование которой является нашей дальнейшей целью. В данном разделе мы рассмотрим требования, которым должны удовлетворять результирующие бизнес-правила, и отличия данного метода от простого обращения метода восстановления вычислений.
Главным предъявляемым требованием, выполнение которого не может быть достигнуто простым обращением метода, является генерация условий выполнения бизнес-правил. Прямой анализ влияния, результаты которого предполагается использовать в качестве входных данных метода, не возвращает условные зависимости в том случае, если переменная из условия не была ранее использована в вычислениях. Для демонстрации рассмотрим два простых примера.
В первом примере переменная из условия используется в дальнейших вычислениях: Операторный граф для данного примера, который можно получить на основе прямого анализа влияния, приведен на Рис. 14.
В первом примере условная зависимость получена в некотором смысле случайно, поскольку в общем случае переменные в условиях не обязаны вычисляться с использованием исходной переменной.
Очевидно, что во втором примере условная зависимость может быть получена с помощью обратного анализа влияния. Однако запуск данного метода отдельно для каждой переменной (поскольку потенциально практически каждая может контролироваться условием) является дорогостоящим по времени. Можно ограничиться лишь выходными переменными, то есть вычисляемыми оператором, но и это не решает проблему.
Другой проблемой является необходимость пересмотра алгоритма упорядочения бизнес-правил. Если в задаче восстановления вычислений нам лишь было важно, чтобы значение не пересчиталось раньше, чем было использовано, то в данной задаче имеет смысл разграничивать параллельные использования, которые с некоторого присваивания становятся совершенно независимыми. При этом возникает вопрос наиболее удобной демонстрации результирующих бизнес-правил. Одно из возможных решений -использование более ранней группировки. Соответственно, алгоритмы группировки также требуют пересмотра.
Business Rule Manager — это компонент системы Relativity Modernization Workbench, предназначенный для создания и изменения бизнес-правил [34, 40]. Подобные инструменты называют системами управления бизнес-правилами (Business Rules Management Systems). Они должны удовлетворять следующим требованиям: предоставлять сервисы для хранения, просмотра, изменения, защиты и восстановления данных, называемые сервисами репозитория; управлять жизненным циклом бизнес-правила: создание, активация, замена, удаление и т.п.; проверять бизнес-правила на соответствие стандартам (логическая корректность) и проверять их действенность в бизнесе.
В разделе 4.2 мы рассмотрим, как эти и другие функциональности реализованы в компоненте Business Rule Manager.
В первой главе мы определили BRM-модель. Рассмотрим ее подробнее как часть модели репозитория, используемой в системе Relativity Modernization Workbench.
Репозиторий служит для хранения информации о рассматриваемой программной системе. Модель репозитория определяет его структуру. Объекты и отношения представлены записями в различных таблицах, соответствующих различным типам объектов и отношений. Таким образом, модель нужна для создания базы данных.
Кроме того, модель используется средствами доступа к базе данных репозитория, поскольку запросы к этой базе сформулированы в терминах модели, что обеспечивает дополнительный уровень абстракции. Такие запросы транслируются в SQL специальным программным интерфейсом приложения (API) и затем исполняются соответствующей СУБД (Oracle, DB2 или Access). При этом достигается независимость как от особенностей конкретной СУБД, так и от структуры базы данных. Например, отношения различных типов могут храниться в одной или нескольких таблицах, но это не влияет на запросы пользователя, поскольку они сформулированы в терминах модели.
Модель репозитория определяет сотни различных типов объектов и отношений между ними. Концептуально эта модель делится на два уровня. Модель первого уровня определяет общую структуру приложения. Второй уровень модели репозитория представлен набором подмоделей, специфичных для конкретного языка программирования, и определяет структуру программы на уровне отдельных операторов.
Возможности инструмента Business Rule Manager
Помимо функциональностей, стандартно предоставляемых системами управления бизнес-правилами (и упомянутых в разделе 4.1), Business Rule Manager позволяет осуществлять: поиск по различным атрибутам бизнес-правил; групповое редактирование бизнес-правил; копирование и перемещение бизнес-правил; валидацию сегментов - проверку на соответствие сегмента бизнес-правила и редактированного кода; автоматический поиск входных и выходных данных бизнес-правила; подстановку терминов предметной области вместо имен переменных (с использование специального бизнес-словаря); автоматическое построение бизнес-правил; экспорт и импорт бизнес-правил с использованием формата XML. Более подробно эти возможности будут рассмотрены далее в соответствующих разделах. Автоматическое построение бизнес-правил работает согласно методам, описанным в главе 3, поэтому мы отдельно остановимся лишь на некоторых особенностях реализации (см. 4.3). Согласно модели, используемой в компоненте Business Rule Manager и описанной в первой главе, бизнес-правило содержится в бизнес-процедуре, которая реализует бизнес-функцию. Таким образом, для создания бизнес-правила в компоненте необходимо сначала создать бизнес-функцию и бизнес-процедуру либо указать уже существующие. Бизнес-функция имеет следующие атрибуты: имя, описание и предметная область (business area). При создании бизнес-функции необходимо задать имя. Бизнес-процедура и бизнес-правило имеют имя и описание, при их создании также необходимо задать имя. Остальные атрибуты могут быть заполнены позже, имя также может быть отредактировано. Интерфейс для создания бизнес-функции, бизнес- процедуры и бизнес-правила показан на Рис. 19, Рис. 20, Рис. 21 соответственно.
Помимо перечисленных основных атрибутов, все элементы имеют статусные атрибуты, которые заполняются бизнес-аналитиком, и при создании элементов имеют значения по умолчанию. Множество этих атрибутов может быть изменено пользователем. К предлагаемым по умолчанию статусным атрибутам относятся: тип (classification), проверка (audit), состояние (status) и актуальность (transition). Данные атрибуты, как следует из названия, определяют текущий статус элемента и демонстрируются в правой части панели Rules (Рис. 22). Например, бизнес-правило может быть вычислительное (тип), подтвержденное (проверка), действующее (статус), устаревшее (актуальность). Для любого элемента можно задать входные и выходные данные и условия выполнения, которые отображаются на соответствующих закладках (Рис. 23, Рис. 24).
Бизнес-правило может быть задано без указания соответствующего сегмента кода, но обычно это подразумевает, что сегмент будет указан позже. Также бизнес-правило может не иметь привязки к коду, если оно предназначено только для вызова исполнения некоторой бизнес-процедуры, т.е. является триггером без параметров. Если сегмент кода был определен неверно, он может быть заменен. Замена сегмента может быть необходима в случае, если код был модифицирован после создания бизнес-правила.
В любой момент бизнес-функция, бизнес-процедура и бизнес-правило могут быть удалены. При этом бизнес-процедура удаляется вместе с содержащимися в ней бизнес-правилами, а бизнес-функция вместе с реализующими ее бизнес-процедурами.
Если пользователь хочет сохранить только часть бизнес-правил данной бизнес-процедуры, он может как удалить нежелательные правила, так и применить к сохраняемым правилам операцию копирования или перемещения в другую бизнес-процедуру с последующим удалением исходной бизнес-процедуры. Операции копирования и перемещения также могут применяться и к процедурам. Интерфейс операции копирования показан на Рис. 25.
Интерфейсные решения, или особенности с точки зрения пользователя
Методы автоматического построения бизнес-правил реализованы в отдельной библиотеке и программно могут быть использованы любым приложением. Однако у пользователя системы Relativity Modernization Workbench существует лишь два способа работы с этими методами. Во-первых, можно их запустить с панели Business Rule Manager (Рис. 29).
Во-вторых, можно автоматически создавать бизнес-правила по списку поиска, создаваемому компонентом Clipper (Рис. 30, Рис. 31). В этом случае метод восстановления вычислений будет запущен для каждого порта, оператора ввода-вывода или переменной из текущего списка. Все полученные таким образом бизнес-правила будут помещены в одну бизнес-функцию.
Процес создания бизнес-правил методом восстановления вычислений контролируется специальными опциями, или параметрами настройки, которые можно установить в проектных параметрах системы (Project Options) на соответствующей закладке. Метод валидации экранных портов не имеет собственных опций, он использует некоторые специальные установки анализа влияния (Impact analysis), но ни одна из них не может быть изменена пользователем. Поэтому далее мы рассмотрим именно управление методом восстановления вычислений с помощью соответствующих опций.
На упомянутой выше закладке проектных параметров слева находится список опций (Settings). Справа расположены элементы управления для установки конкретных значений для каждой опции из списка. Кроме того, имеется общая опция ручной установки значений условий «Set values of conditions manually» (Рис. 33). Включение этой опции позволяет пользователю в процессе работы метода задавать значения условий, для которых оба значения (True и False) возможны в контексте исполнения. При этом метод будет ожидать выбора пользователя и только после его совершения сможет продолжить работу. В случае отключения опции «Set values of conditions manually» метод восстановления вычислений будет анализировать все возможные значения условий. Тогда метод не требует участия пользователя и работает без остановок. По умолчанию эта опция включена. Но если метод восстановления вычислений вызывается для списка объектов и включена опция «Set values of conditions manually», показывается специальное сообщение с предупреждением. В такой ситуации необходимо подтверждение пользователя на установку значений условий в режиме диалога.
Взаимодействие с пользователем осуществляется посредством специальной диалоговой формы, отображающей иерархию условий (Рис. 32). Если для переменной определен соответствующий ей термин предметной области, то именно он будет использован в диалоге для обозначения переменной.
Знак «+» около условия «DISCOUNTS» означает, что для достижения точки интереса это условие должно быть истинно (True). Это условие может иметь (и имеет в данном случае) только истинное поддерево, где показаны условия зависящие от данного условия, если таковые имеются.
Другие условия помечены знаком «?». Это означает, что для различных бизнес-правил они могут принимать различные значения. С помощью всплывающего меню пользователь может выбрать конкретное значение. Например, если значение будет установлено как ложное (False), то знак «?» будет заменен на знак «—» и все бизнес-правила, исполняемые при истинном условии, не будут созданы.
В общем случае каждое условие на форме может иметь не более двух поддеревьев. Одно поддерево содержит условия, зависящие от значения «True» данного условия, другое соответствует значению «False» данного условия. Любая из ветвей может отсутствовать, если нет соответствующих зависимых условий. Для просмотра больших деревьев с условиями пользователь имеет возможность изменять размер окна.
Всплывающее меню доступно только для вершин дерева, значение которых может быть изменено. При этом выбраное условие подсвечивается в коде (на панели Source), что облегчает навигацию по программе.
Параметры «Data Impacts» (Рис. 33) являются одними из основных для метода восстановления вычислений, потому что этот метод использует данные, полученные в процессе выполнения анализа влияния (Impact Analysis). Установка опций «Data Impacts» определяет набор параметров, с которыми будет исполняться анализ влияния. Ниже объясняется соответствие параметров метода восстановления вычислений и анализа влияния.
