Современный уровень требований к качеству программного продукта хотя и обеспечивается в рамках традиционных технологий, но соответствующие издержки неуклонно растут. Поэтому все большее внимание в процессе промышленного производства программного обеспечения (ПО) фокусируется на технологиях, автоматизирующих все фазы жизненного цикла программного изделия. Несмотря на появление технологий, автоматизирующих дизайн и разработку ПО и, как следствие, существенно улучшающих качество ПО, их внедрение идет достаточно сложно и медленно. Это связано не столько с необходимостью дополнительных затрат на внедрение новых технологий, сколько с изменением ментальности программистов, решающих все вопросы проектирования прямо на уровне кода, а не спецификаций. Настоящая работа демонстрирует путь гибкого, безболезненного перехода к новым эффективным технологиям разработки ПО.
Современные технологии автоматизации тестирования и разработки кода ПО основаны на процессе генерации кода тестов или приложения. Непременным условием генерации является применение формальных спецификаций в описании системы или ее части, которая должна быть сгенерирована. Использование формальных методов спецификации сразу решает две проблемы: 1) наглядное и интуитивно понятное представление требований к системе; 2) точное соответствие спецификаций (требований) генерируемому коду системы и тестов.
В рамках формального подхода в качестве языков спецификаций широкое распространение получили языки визуального проектирования UML, SDL, MSC [1-3]. Одной из распространенных задач производства ПО является разработка модифицированного продукта на основе старых версий путем добавления новых свойств в существующий код. В этом случае возникает необходимость изучения старого кода до его модификации.
Подобная задача успешно решается при наличии формальных спецификаций старых версий продукта в базе проекта. При этом представление старого кода в виде множества диаграмм, например на UML, SDL или MSC, используется как база, на основе которой проектируется новая функциональность. Если же проектирование новых свойств осуществляется только на базе неформальных описаний функциональности старых версий, то задача разработки становится неформальной и практически не поддается автоматизации.
В последнее время все чаще возникает проблема перевода старых формальных спецификаций (SDL, MSC) на новые (UML). Эта задача решается в CASE-системах, оснащенных средствами трансформации спецификаций с одного языка на другой [4], например, с SDL на UML.
Любая из рассмотренных задач решается по следующей методике (рис. 1).
- Перевод существующего кода на формальный язык с целью его последующего использования (в данной работе был выполнен переход с языка SDL на UML).
- Разбиение полученной спецификации на элементарные единицы (базовые протоколы) на языке MSC и их последующая верификация.
- Тестирование системы с использованием трасс, полученных в результате верификации.
- Использование протоколов тестирования, представленных в виде MSC трасс, в верификаторе для определения места ошибок в случае их обнаружения.
В рассматриваемой технологии для обоснования правильности программ совместно используются верификация и тестирование. Верификация представляет статический метод доказательства правильности символических спецификаций, то есть описывающих поведение системы графов, дуги которых нагружены символами параметров и атрибутов. Тестирование представляет динамический метод проверки правильности на основе исполнения множеств конкретных сценариев, полученных из символических путем задания конкретных значений параметрам и атрибутам.
Технологически процесс верификации реализуется на основании множества спецификаций на языках UML, MSC и SDL. Спецификации, составленные на MSC, используются преимущественно для описания модели окружения и генерации набора тестов. Спецификации на SDL применяются для описания динамических и статических свойств системы. Спецификации на UML покрывают описание системы и окружения.
Рассматриваемая интегрированная технология (рис. 2) опирается на верификатор, инструмент для автоматической генерации и исполнения тестов и CASE-систему IBM Rational / Telelogic Tau G2 [4]. К сожалению, тотальное использование технологии генерации кода по спецификациям в современных CASE-системах сдерживается сложностью получения приемлемого по эффективности, реактивности и другим характеристикам кода. Именно поэтому в рамках описываемой технологии основное внимание направлено на тестирование, на которое влияние перечисленных ограничений ослабевает.
Данная технология применялась к хорошо известной телекоммуникационной задаче POTS (Plain old telephone system) - своеобразному эталонному тесту для такого рода задач. В рамках POTS рассматривается система, состоящая из телефонной сети и множества телефонов, взаимодействующих друг с другом. При этом сеть предоставляет сервисы для обеспечения всех возможных взаимодействий телефонов, таких как создание соединения, конференц-связь, удержание вызова и других. В качестве требований были использованы 19 неформальных описаний функционирования POTS при вызове различных сервисов.
На первом этапе требования к системе на естественном языке преобразуются в формальные требования (спецификации). Каждое требование переписывается в виде базового протокола - отдельной MSC-диаграммы, представляющей минимальный набор событий, переводящих систему из одного состояния в другое (рис. 3).
Таким образом, все функциональные требования заключаются в наборе простых диаграмм (базовых протоколов). В телекоммуникационной системе эти требования представляют собой следующие действия: поднять трубку, сделать звонок, опустить трубку и так далее.
Следующий этап связан с доказательством корректности базовых протоколов. Подобное доказательство позволяет обнаружить недетерминированное поведение системы, а также провести проверку полноты описания. Этот процесс полностью реализуется с помощью верификатора, после работы которого (если возникли ошибки) есть возможность пересмотреть или исправить требования к системе. На рисунке 4 можно увидеть пример верификационного вердикта, в котором показано недетерминированное поведение системы. При одном и том же входном воздействии off_hook система может перейти в два различных состояния dial и connected.
Этап генерации трасс связан с получением множества трасс для полного покрытия требований системы. Гибкие возможности по заданию ограничений при генерации позволяют отсечь то поведение системы, которое не должно проверяться в тестовом наборе.
В данной технологии генерация тестов производится с использованием инструмента тестера, который обеспечивает трансформацию тестовых сценариев с MSC на целевой язык (в случае тестируемой телекоммуникационной системы - это язык С/С++). Поскольку тестирование работает с целевым кодом, появляется возможность проверить свойства низкоуровневого кода приложения. Процесс тестирования использует гибкую систему генерационных smart-шаблонов, представляющую широкие возможности адаптации генерируемого кода к различным целевым языкам и другим особенностям целевой платформы и ее окружения.
Параллельно с процессом разработки тестов происходит перевод системы с языка SDL на UML с последующей генерацией кода. Задача решалась с использованием инструментария IBM Rational / Telelogic.
Для обеспечения "связывания" модели и тестового окружения используется обертка - программный модуль на целевом языке. Обертка описывает все аспекты взаимодействия между тестом и окружением. Тестовое окружение, сгенерированное на основе MSC диаграмм, посылает воздействия в тестируемую систему и получает ответную реакцию системы посредством данного программного модуля (в случае тестируемой телекоммуникационной системы мы имеем 2 сущности, взаимодействующие друг с другом: любой телефон, подключенный к сети, и непосредственно телефонная сеть). На рисунке 5 представлена технология генерации обертки.
После реализации "обертки" мы обладаем полным набором файлов, необходимых для генерации исполняемого теста (рис. 6).
Вердикт, полученный в результате выполнения теста, представляет собой набор сигналов, отражающих взаимодействие модели и окружения. Он представлен в виде текстового файла и текстовой нотации MSC диаграмм, на которых отображаются ошибки.
Таким образом, имея на входе спецификации на языке SDL, были получены и расширены спецификации на языке UML, нотация которого является наиболее распространенной. Также был получен набор тестов, гарантирующий полное покрытие функциональности, и проведено тестирование системы с использованием этого набора.
На этапе верификации и формализации обнаружено 11 ошибок, на этапе тестирования - 1. Основная масса ошибок (70%), найденная при формализации и верификации, сокращает трудозатраты, необходимые при полном тестировании, более чем в 2 раза, что заметно удешевляет производство качественного программного продукта.
Применение представленной технологии для верификации и тестирования в области телекоммуникационных систем позволяет:
· повысить качество ПО при использовании интегрированной инструментальной системы верификации и тестирования;
· получить возможность расширения функциональности системы на языках высокого уровня;
· уменьшить затраты на исправление обнаруженных ошибок за счет их локализации на фазе дизайна в процессе верификации;
· обеспечить полное тестовое покрытие поведенческих свойств тестируемой системы с помощью набора автоматически сгенерированных символических трасс, используемых в процессе тестирования;
· сократить не менее чем на 50% время тестирования с использованием автоматической генерации тестовых наборов и их прогона.
Список литературы
1. White Paper Using UML 2.0 to Solve Systems Engineering Problems// July 2003, Andy Gurd, Senior Project Manager, Telelogic 25 с. - http://www.telelogic.com/download/paper/UsingUML2forSE_problems.pdf?CFID=7722736&CFTOKEN=64228e57feb8365e-474504FC-3477-99FC-6BA42E64D250E0EC.
2. ITU-T z.100 (08/2002)// Telecommunication standardization sector of UTI, 202 с. - http://www.itu.int/rec/recommendation.asp?type=items& lang=e&parent=T-REC-Z.100-200208-I.
3. Recommendation z.120, 78 с. - http://www.itu.int/rec/re commendation.asp?type=items&lang=e&parent=T-REC-Z.120-200404-P.
4. Telelogic TAU 2.3 UML tutorial// Telelogic, 60 с. -https://support.telelogic.com/en/tau/download/product/product.cfm? vid=97 (документ также включен в комплект документации, поставляемой с TAU 2.3).