Применение интегрированной технологии тестирования и верификации к модели телефонной сети

устранения, знания о которых также должны быть введены в БЗ агентов.

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

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

Список литературы

1. Швецов А.Н., Яковлев С.А. Распределенные интеллектуальные информационные системы. - СПб.: Изд-во СПбГЭТУ «ЛЭТИ», 2003. - 318 с.

2. Искусственный интеллект. - В 3-х кн. Кн. 2. Модели и методы: Справочник/ Под ред. Д.А. Поспелова - М.: Радио и связь, 1990. - 304 с.: ил.

3. Садыков С.С., Симаков Р.А. Автоматизированный способ идентификации объектов карты// Геоинформатика. - 2004. - №2. - С.46-51.

ПРИМЕНЕНИЕ ИНТЕГРИРОВАННОЙ ТЕХНОЛОГИИ ТЕСТИРОВАНИЯ И ВЕРИФИКАЦИИ К МОДЕЛИ ТЕЛЕФОННОЙ СЕТИ

М.Ш. Даишев, П.Д. Дробинцев, В.П. Котляров, Д.В. Песков, Ю.В. Юсупов

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

Современные технологии автоматизации тестирования и разработки кода ПО основаны на процессе генерации кода тестов или приложения. Непременным условием генерации является применение формальных спецификаций в описании системы или ее части, которая должна быть сгенерирована. Использование формальных методов спецификации сразу решает две проблемы: 1) наглядное и интуитивно понятное представление требований к системе; 2) точное соответствие спецификаций (требований) генерируемому коду системы и тестов.

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

UML, SDL, MSC [1-3]. Одной из распространенных задач производства ПО является разработка модифицированного продукта на основе старых версий путем добавления новых свойств в существующий код. В этом случае возникает необходимость изучения старого кода до его модификации.

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

В последнее время все чаще возникает проблема перевода старых формальных спецификаций (SDL, MSC) на новые (UML). Эта задача решается в CASE-системах, оснащенных средствами трансформации спецификаций с одного языка на другой [4], например, с SDL на UML.

Любая из рассмотренных задач решается по следующей методике (рис. 1).

• Перевод существующего кода на формальный язык с целью его последующего использования (в данной работе был выполнен переход с языка SDL на UML).

• Разбиение полученной спецификации на элементарные единицы (базовые протоколы) на языке MSC и их последующая верификация.

• Тестирование системы с использованием трасс, полученных в результате верификации.

Неформальные. специфика ции на естественном. языке

Формализация

SDL, MSC модифицируемой версии

UML -

специфи кация

Коррекция исходных спецификаций

Построение базовых

Верификация требований и спецификаций

Вердикт верификации

верифи катор

Генерация поведенческих сценариев или трасс

Вердикт тестирования

Автоматическое тестирование

Рис. 1. Технологическая цепочка верификации тестирования

• Использование протоколов тестирования, представленных в виде MSC трасс, в верификаторе для определения места ошибок в случае их обнаружения.

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

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

Рассматриваемая интегрированная технология (рис. 2) опирается на верификатор, инструмент

Верификатор

Требования на естественном языке

В процессе формализации разработчик находит несоответствия в спецификации

/ Формальные спецификации поступают на вход генератора для генерации трасс обеспечивающих полное покрытие

В процессе верификации с использованием верификатора автоматицески выявляются несоответствия в спецификациях

для автоматической генерации и исполнения тестов и CASE-систему Telelogic Tau G2 [4]. К сожалению, тотальное использование технологии генерации кода по спецификациям в современных CASE-системах сдерживается сложностью получения приемлемого по эффективности, реактивности и другим характеристикам кода. Именно поэтому в рамках описываемой технологии основное внимание направлено на тестирование, на которое влияние перечисленных ограничений ослабевает.

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

Требование на естественном языке

за-

Если трубке слышен сигнал нято", то, после того как ее кладут на базу, система переходит в состояние "idle"

Требование в виде MSC-диаграммы

Состояние телефона, до сигнала "занят

Переход системы в состояние "idle

Рис. 3. Пример базового протокола

Тестер

Сгенерирова нные тесты

Тестовый вердикт

Рис. 2. Основные этапы технологии верификации и тестирования

На первом этапе требования к системе на естественном языке преобразуются в формальные требования (спецификации). Каждое требование переписывается в виде базового протокола - отдельной МБС-диаграммы, представляющей минимальный набор событий, переводящих систему из одного состояния в другое (рис. 3).

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

Трассы поступают на вход тестового Генератора входящего в состав тестера

В результате тестирования генерируется тестовый журнал

Fcrall m

Следующий этап связан с доказательством корректности базовых протоколов. Подобное доказательство позволяет обнаружить недетерминированное поведение системы, а также провести проверку полноты описания. Этот процесс полностью реализуется с помощью верификатора, после работы которого (если возникли ошибки) есть возможность пересмотреть или исправить требования к системе. На рисунке 4 можно увидеть пример верификационного вердикта, в котором показано недетерминированное поведение системы. При одном и том же входном воздействии off_hook система может перейти в два различных состояния dial и connected.

а

Checking transition consistency msc diagrams: Off_hook and Off_hook_ringing INCONSISTENCY:

Matching formula: (# m0 = # ml) & (m0 = ml) Precondition 1: Phone (m0 , idle);

Precondition 2: Phone (nl , ringing ml) & Phone (ml , ringing); Post condition l: Phone (m0 , dial); Post condition 2: Phone (ml , connected) & Phone (nl , connected);

Рис. 4. Пример верификационного вердикта с выявленной ошибкой

W

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

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

Параллельно с процессом разработки тестов происходит перевод системы с языка SDL на UML с последующей генерацией кода. Задача решалась с использованием инструментария Telelogic.

Для обеспечения "связывания" модели и тестового окружения используется обертка - программный модуль на целевом языке. Обертка описывает все аспекты взаимодействия между тестом и окружением. Тестовое окружение, сгенерированное на основе MSC диаграмм, посылает воздействия в тестируемую систему и получает ответную реакцию системы посредством данного программного модуля (в случае тестируемой телекоммуникационной системы мы имеем 2 сущно-

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

Тестер .

Xkt potstest_Recv_BÜSY(int Parami, int

from, int to) {

model_sigBÜSY.Param1 = Parami; instances_evBÜSY[0] = from; instances_evBÜSY[1] = to; TAT ReceiveMessage(TI ID,

-Q

Рис. 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&CFT0KEN=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).

МЕТОДИКА ОЦЕНКИ ПРОЕКТОВ СОЗДАНИЯ ИНФОРМАЦИОННЫХ СИСТЕМ

Л.Н. Иванов, О.В. Милёхина

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

Предлагаемая авторами методика оценки проектов создания ИС состоит из трех этапов:

• разработка бизнес-плана, позволяющая оценить эффективность вложения финансовых средств в создание современной ИС;

• проведение функционально-стоимостного анализа затрат в процессе создания, направленного на оптимизацию новых систем;

• выбор вариантов реализации технологических процессов при создании ИС на базе классического метода приведенных затрат.

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

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

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

длительность и стоимость выполнения данного этапа. Методы решения возникающих задач при этом рассматриваются с позиции и исследовательского, и нормативного планирования.

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

Бизнес-планирование помогает менеджерам решать следующие важные проблемы:

• определить степень жизнеспособности идеи, лежащей в основе проекта создания новой ИС;

• минимизировать риск, связанный с возможной неконкурентоспособностью произведенной ИС;

• конкретизировать проект по созданию ИС в виде системы количественных и качественных показателей развития;

• оценить затраты и время, необходимые для выполнения определенных этапов проекта;

• привлечь внимание и интерес, обеспечить поддержку со стороны потенциальных инвесторов проекта.

С этой целью необходимо осуществить сбор информации: о спросе (при разработке принципиально новой ИС); производственной информации, включающей определение производственных потребностей на базе реально существующих технологических процессов и оборудования, конкретного предприятия либо сегмента предприятий и организаций, на которые ориентировано создание ИС, а также описать финансовые аспекты проекта, на основании которых оценить рентабельность проекта, объем финансовых вложений и способов их получения.