CC BY
57
УДК 004.41
А. Ю. Подъячев, А. Ю. Атисков, С. В. Перминов
ТЕСТИРОВАНИЕ ПРОЦЕССА ТРАНСФОРМАЦИИ ФУНКЦИОНАЛЬНЫХ МОДЕЛЕЙ НА ОСНОВЕ ГИБРИДНЫХ МЕТОДОВ
Обсуждается задача трансформации формальных моделей IDEF0 в диаграммы классов UML с использованием гибридных методов, включающих онтологическое проектирование правил трансляции. Рассматривается механизм создания правил трансформации и тестирования на соответствие полученной и исходной моделей.
Ключевые слова: оценка качества, модельное тестирование, трансляция моделей, онтологические правила.
Введение. С развитием стандартизации и интенсификацией процессов глобализации методов и средств разработки программных систем средства для кроссметодологических трансформаций моделей становятся все более востребованными. Этим обусловлено создание автоматизированной системы, предназначенной для решения задачи трансформации модели из нотации IDEF0 в диаграмму классов UML [1].
Разработка систем такого типа связана с проблемой корректности описания функционального поведения при трансляции моделей. Несмотря на то что модели представляют собой ориентированные взвешенные графы, использование последних для решения данной задачи осложнено неоднородностью методов их оценки. Предлагаемый в настоящей статье подход связан с использованием существующих средств тестирования и оценки качества моделей в новом контексте для определения полноты трансляции, а также сложности полученного графа и вычисления его метрических оценок.
Задачи трансформации моделей. При решении задачи построения автоматизированного средства трансформации моделей использовались три основанные на системе правил подхода — от самого простого до гибридного — с возможностью их адаптации к исходным данным [1—3]. Свойства этих подходов в соответствии с классификацией, предложенной в работе [4], приведены в таблице.
Подход на основе прямой манипуляции обеспечивает полный контроль над описанием правил трансформации и позволяет строить правила любой сложности, но при этом требуется изменять программный код приложения и выполнять его перекомпиляцию. Кроме того, данный подход не предполагает использование механизмов формального описания правил и элементов моделей, что в долгосрочной перспективе делает его непрактичным.
Применение структурного подхода позволяет дифференцировать правила трансформации и основную программу. Такой подход предоставляет большую свободу пользователю при проведении трансформации, однако требует знания языка программирования Java для определения даже простых правил.
Использование гибридного подхода приводит к построению метода трансформации, который позволяет реализовать модульную программную систему. В качестве основных ее свойств можно выделить следующие: независимость от синтаксиса входной и выходной нотаций модели; использование формализованной семантики для определения нотаций проектирования и правил трансформации, реализуемой посредством языков RDF, OWL [3] и SPARQL [5]; контроль за стратегией выполнения правил со стороны пользователя; адаптивность системы к входным и выходным данным при использовании независимых семантических анализаторов данных.
Форма представления правил Подход
прямая манипуляция структурный гибридный
Переменные правил Синтаксически типизированы Синтаксически типизированы Семантически типизированы
Представление правил Строковое Строковое Графовое
Синтаксис правил Текстовый Текстовый Абстрактный
Типизация правил Нетипизированные
Логика правил Императивная Императивная Декларативная
Ограничение области применения Есть Есть Нет
Редактирование модели В выходной целевой модели (отсутствие правки в процессе применения правил)
Параметризация правил Есть
Стратегия правил Детерминистическая Детерминистическая Недетерминистическая
Схема планирования Неявная Явная Явная
Планирование применения правил Внутреннее Внешнее Внешнее
Планирование итераций Рекурсии, циклы Рекурсии, циклы Одноэлементное
Планирование фаз трансформации Есть
Модули правил
Синтаксическое разделение
Повторное использование правил
Организационная структура правил По исходным данным По исходным данным Независима
Направленность правил Однонаправленные Однонаправленные Возможна двунаправленность
Связи между исходными и целевыми элементами Нет Нет Есть
Формализация правил трансформации. Рассмотрим формализацию семантики на примере правила, состоящего из двух утверждений, в первом из которых говорится о том, что определенные дуги исходного графа являются объектами класса, а во втором — о том, что блок исходного графа — это метод (структура) класса полученной модели.
Сначала формализуем преобразование для первого утверждения. Так как задача преобразования сводится к трансформации одного RDF-формата данных (описывающего IDEF0-диаграмму) в другой (описывающий UML-диаграмму), используем стандартизованный язык запросов SPARQL [5] для извлечения данных из ГОEF0-диаграммы. RDF-идентификаторы при преобразовании будут сохраняться. Предварительно определим XML-префикс, который будет использоваться во всех последующих формализмах: PREFIX tf: <spiiras.transform>.
Часть SPARQL-запроса, описывающего объект класса, выделим в отдельную константу, содержащую текст для использования и в других запросах: %class =
?class a tf:Mechanism . :class a tf:Arrow . :class tf:hasArrowEnd ?class
Запрос:
SELECT ?class ?name WHERE { %class . :class tf:name ?name }
Для приведения запроса к окончательному (стандартизованному) виду достаточно произвести в нем предварительную обработку с заменой константы %class ее значением и добавлением информации об используемом префиксе.
Другая часть преобразования состоит в генерации выходных RDF-данных для UML-диаграммы. Для простоты редактирования и восприятия правил построения выходных данных используем нестандартную нотацию (основанную на примитивах языка SPARQL), которая описывает логические тройки, создаваемые для каждого элемента массива, получаемого как результат работы SPARQL-процессора: ?class a tf:Class . ?class tf:name ?name
Таким же образом формализуем преобразование для второго утверждения.
Выделяем константу
%method =%class . ?method a tf:Block . ?class tf:atBlock ?method,
тогда запрос будет сформирован в следующем виде:
SELECT ?class ?method ?name WHERE {%method . ?method tf:name ?name }.
Результирующие данные в этом случае будут соответствовать следующему выражению:
?class a tf:Class . ?method a tf:Method . ?class tf:method ?method . ?method tf:name ?name.
Получаемые независимые друг от друга декларативные правила преобразования с формализованной семантикой могут выполняться в любом порядке. Как одно из следствий использования декларативного подхода при построении правил в выходных данных возможно появление копий логических троек, которые необходимо удалить на любом из этапов преобразования. Подобным образом можно формализовать и другие правила преобразования диаграмм, состоящие из утверждений. Таким образом, можно говорить, что задача формализации правил, т. е. формального описания их семантики, решена.
Оценка формальной модели. Существует достаточное количество метрик, которые в той или иной степени могут характеризовать IDEFO-модели. Часть этих метрических оценок применима также и к диаграммам классов UML [6, 7]. Взаимосвязь метрических показателей может быть использована для проверки соответствия результата гибридной трансформации модели IDEF0 в диаграмму классов UML. Рассмотрим такую взаимосвязь на примере примитивной метрики покрытия элементов исходной спецификации системы. Тестовый набор элементов модели удовлетворяет критерию полного покрытия, если при его проверке каждому элементу находится соответствие в исходной спецификации программы, по крайне мере, один раз.
Для отображения результатов проверки модели достаточно хорошо подходят методы проверки пустого и ложного покрытий. Пусть F — диаграмма классов UML; ф — спецификация IDEF0, удовлетворяющая F; F' — измененная диаграмма UML. Если F' не удовлетворяет ф, то можно однозначно утверждать, что спецификация ф покрыта ошибочно. При F', удовлетворяющем ф, можно также говорить о бессодержательном покрытии спецификации ф. Таким образом, проверяем, удовлетворяет ли спецификации измененная схема полученной модели, в случае если спецификация также подвергалась изменению.
Для точного определения результатов тестирования моделей необходимо, помимо использования метода оценки формальной модели, применить метод оценки ошибочного по-
крытия элементов спецификации. Алгоритм этого метода позволяет произвести вычисления, осуществляемые путем подмены значений переменных. Подмена значений происходит в наборах выходных параметров методов классов UML-диаграммы. Подробное описание этого алгоритма изложено в работе [8]. Для символьных проверок соответствия и оценки метрических показателей подходит предложенное выше представление элементов диаграмм обеих нотаций в стандарте RDF [3].
Заключение. Для решения задачи формализации правил трансформации был задействован пакет технологий, предложенных в рамках пирамиды стандартов „Semantic Web" [9]. Это является экспериментальным подтверждением предположения о том, что методика семантического поиска пригодна для анализа и трансформации не только данных, представленных в сети Интернет, но и для любых других данных, если последние можно формализовать для представления в стандарте RDF. Суть предложенной в настоящей статье методики сводится к извлечению данных и их контекста из исходного документа, формализации представления извлеченной информации в виде семантической сети и последующему анализу полученных данных.
С другой стороны, говоря о технологии тестирования, необходимо отметить, что она может применяться не только как прикладной инструмент для автоматизации тестирования, но и как инструмент для исследования методов построения моделей программного обеспечения в различных нотациях и их дальнейшего использования в качестве спецификаций для создания тестовых сценариев [10]. Перспективное развитие методов метрической оценки данных моделей предоставит возможность контролировать сложность, надежность и качество как исходной спецификации программы, так и последующих реализаций программных комплексов. По оценкам схемы построения тестового сценария можно сделать выводы и дать рекомендации относительно улучшения кода либо пересмотра спецификации при наличии проблем с надежностью системы. Предложенный алгоритм тестирования дает возможность абстрагироваться от конкретных описаний метамоделей и, в частности, позволяет использовать IDEFO-описание в качестве тестовой спецификации.
Данная технология использована при выполнении проекта 1.3 целевой программы Президиума РАН „Информатизация", а также комплексного междисциплинарного проекта „Разработка портала и баз данных Президиума Санкт-Петербургского научного центра РАН".
список литературы
1. Атисков А. Ю., Воробьев В. И. Автоматизированная система трансформации диаграмм бизнес-процессов в диаграммы классов // Тр. СПИИРАН. СПб.: Наука, 2006. Вып. 3, т. 2. С. 146—155.
2. Атисков А. Ю., Воробьев В. И. Адаптивная система трансформации диаграмм бизнес-процессов в диаграмм -мы классов // Вестн. гражданских инженеров. СПб.: СПбГАСУ, 2007. № 1(10). С. 83—88.
3. Атисков А. Ю., Перминов С. В. Гибридная адаптивная технология проектирования бизнес-процессов // Тр. СПИИРАН. СПб.: Наука, 2007. Вып. 4. С. 184—192.
4. The Open Group. ADL 2.0 Translation System [Электронный ресурс]: <http://adl.opengroup.org/> (по состоянию на 10.03.2007).
5. SPARQL Query Language for RDF. W3C Recommendation 15 January 2008 [Электронный ресурс]: <http://www.w3.org/TR/rdf-sparql-query/> (по состоянию на 14.04.2008).
6. Подъячев А., Афанасьев С. Тестирование трансляции формальных моделей // Тр. СПИИРАН. СПб.: Наука, 2006. Вып. 3, т. 2. С. 156—161.
7. Подъячев А. Построение TTCN тестов на основе UML диаграмм // Там же. 2007. Вып. 4. С. 155—162.
8. Подъячев А. Использование метода покрытий при верификации моделей IDEF-0 // Там же. 2007. Вып. 5. С. 275—283.
9. Berners-Lee T., Hendler J, Lassila O. The Semantic Web. A new form of Web content that is meaningful to computers will unleash a revolution of new possibilities // Scientific Amer. 2001. N. 5. P. 34—43.
10. Adel K., Helsen S. Classification of model transformation approaches // OOPSLA'03 Workshop on Generative Techniques in the Context of Model-Driven Architecture. Univ. of Waterloo, Canada, 2003.
Алексей Юрьевич Подъячев Алексей Юрьевич Атисков Сергей Владимирович Перминов
Сведения об авторах СПИИРАН, лаборатория вычислительных систем и проблем защиты информации; E-mail: Alexey.Podjachev@quest.com СПИИРАН, лаборатория вычислительных систем и проблем защиты информации; E-mail: atiskov@gmail.ru
СПИИРАН, лаборатория вычислительных систем и проблем защиты информации; E-mail: sv.perminov@gmail.com
Поступила в редакцию 06.05.08 г.
