CC BY
42
УДК 004.05
А. В. Самонов
Методика реализации программно-управляемого процесса разработки и верификации программных средств автоматизированных систем специального назначения
Определены наиболее проблемные вопросы использования технологий и средств разработки программного обеспечения автоматизированных систем специального назначения, основанных на модельно-ориентированном подходе. При реализации данного подхода предполагается, что все артефакты жизненного цикла системы (требования, проект, реализация) представлены в виде формальных моделей. Предложены пути решения этих проблем посредством реализации программно-управляемого процесса разработки и верификации формальных исполняемых FUML-моделей требований и архитектуры программного обеспечения.
Ключевые слова: автоматизированные системы управления, диаграммы активности, диаграммы классов, модели анализа, модели архитектуры, проектирование и верификация, генерация тестовых сценариев.
Введение
Высокая динамичность подготовки и ведения современных боевых действий обусловливают необходимость всеобъемлющего и согло-сованного использования в системе управления силами и средствами специального назначения комплексов средств автоматизации (КСА), систем связи и передачи данных (ССПД), построенных на основе современных информационных и телекоммуникационных технологий. Предприятия оборонно-промышленного комплекса (ОПК) Российской ® Федерации, осуществляющие разработку та-
0
™ ких сложных программно-технических сис-
^ тем (СПТС), должны учитывать следующие
— существенные особенности систем и процес-
| са их создания:
< • отсутствие прямых аналогов, что ограД ничивает возможность использования типовых
<3
5 проектных решений и готовых прикладных систем;
§ • высокие требования к надежности, про-
я изводительности и защищенности СПТС, что обусловлено необходимостью обеспечения не-х прерывности автоматизированного управления ^ войсками, силами и средствами;
1 • необходимость интеграции вновь раз-
си рабатываемых систем с уже существующими со
и унаследованными; ™ • функционирование СПТС в неодно-
9 родной среде на нескольких аппаратных платформах.
см
2 _
(П
© Самонов А. В., 2018
Разработка СПТС представляет собой сложную и ресурсоемкую задачу, результат решения которой, к сожалению, не всегда удовлетворяет заданным требованиям и соответствует объему выделенных временных и финансовых ресурсов. При этом стоит отметить тенденцию возрастания роли и значения в обеспечении корректного и надежного функционирования СПТС их программной составляющей - программных средств систем вооружения (ПССВ). В ходе применения СПТС подтверждено, что до 85...90 % отказных ситуаций обусловлены ошибками в их программной составляющей.
О наличии серьезных проблем при создании и внедрении СПТС красноречиво свидетельствуют результаты анализа успешности выполнения как отечественных, так и зарубежных проектов по их созданию. В качестве примера приведем данные из отчета компании The Standish Group [1] о качестве реализации проектов по созданию информационных систем (ИС), выполненных в США за последние 15 лет. Согласно этим данным, только 16,2 % проектов были завершены вовремя и в рамках первоначального бюджета. При этом 31,1 % проектов по созданию ИС провалились, в 52,7 % случаев возникли проблемы, из-за которых итоговый бюджет превысил первоначальный в среднем в 2 раза, а сроки - в 3,3 раза, при этом было реализовано менее 75 % требуемого функционала. Основные причины этого - низкое качество исходного комплекса требований к разрабатываемой системе,
отсутствие автоматизированных средств их валидации, сопровождения и коррекции. Актуальность данной проблемы подтверждают приведенные в работе [2] данные: бюджет проекта в случае внесения изменений в требования возрастает более чем в 3 раза, а сроки исполнения - более чем в 2 раза.
Для решения указанных проблем в рамках системной и программной инженерии создаются новые более эффективные технологии, модели и средства автоматизированного проектирования, разработки и верификации СПТС. Процесс разработки СПТС состоит из трех основных этапов: обоснование требований, проектирование и реализация. Каждый из них в соответствии с методологией модельно-ори-ентированного подхода включает процедуру верификации соответствующего артефакта. По результатам проведенного анализа можно заключить, что в настоящее время достаточно успешно решены вопросы, связанные с автоматизацией процессов генерации и верификации программного кода, создаваемого на этапе реализации. В то же время на начальных этапах создания СПТС, в частности, на этапах формирования комплекса требований и проектирования архитектуры системы, по-прежнему требуется существенное участие специалистов в области системной инженерии и информационных технологий.
Подтверждением актуальности автоматизированной поддержки процессов обоснова-
ния требований и проектирования архитектуры служат данные о распределении стоимости устранения ошибок, внесенных и обнаруженных на различных этапах жизненного цикла (ЖЦ) СПТС. Например, в монографии известного американского эксперта Б. Боэма [3] отмечено, что удельная стоимость исправления дефектов возрастает по экспоненциальному закону распределения по мере продвижения продукта к стадии эксплуатации. При этом затраты на исправление дефекта, внесенного на этапе обоснования требований, при его обнаружении на этапе проектирования возрастают в 5 раз, на этапе реализации в 10 раз, на этапе тестирования в 20 раз, а в ходе эксплуатации - в 100 и более раз (рис. 1).
В связи с этим, главной целью исследований и работ, основные результаты выполнения которых представлены в данной статье, являлась разработка алгоритмического, программного и методического обеспечения процессов построения и верификации формальных моделей комплекса требований и архитектуры программных средств (ПС), предназначенных для использования в КСА и ССПД автоматизированных систем специального назначения (АССН). Их использование позволит снизить затраты на поиск и устранение дефектов, вносимых на этапах формирования требований и проектирования архитектуры, и существенно повысить качество (функциональную корректность, надежность, производительность,
ю о
>150х
1х
5х
10х
■ I I.
20х
Требования Проектирование Программирование Тестирование Приемка Эксплуатация
Этап жизненного цикла
Рис. 1. Относительная стоимость исправления ошибки
та
та
s
о. о ■fr
о cv
cv
OI
<
I
о та
0 ü CQ та
1 о.
<D
£
и
<D CQ
cv
■Clio 9 cv ■clin cv
w
W
защищенность, совместимость) разрабатываемых систем благодаря реализации программно-управляемого процесса их разработки и верификации.
Обзор современной нормативно-методической базы и научных публикаций в области разработки и верификации СПТС
Наиболее важными нормативно-методическими документами в этой области, по мнению автора данной статьи, являются спецификации и модели, разработанные под эгидой международной организации Object Management Group (OMG), с которой сотрудничают более 800 научно-исследовательских и государственных организаций (INCOSE, EURESCOM, DISA, NIST, NASA и др.) и промышленных компаний (AT&T, IBM, Oracle, Microsoft, Cisco Systems и др.). В настоящее время на сайте организации [4] опубликовано более 230 методических документов и спецификаций. В контексте рассматриваемых в настоящей статье вопросов наиболее важными из них являются следующие: Meta Object Facility (MOF), Unified Modeling Language (UML), XML Metadata Interchange (XMI), System Modeling Language (SysML), Object Constraint Language (OCL), UML Testing Profile (UTP), Action Language for Foundational UML (ALF), Semantics of a Foundational Subset for Executable UML Models (FUML), Requirements Interchange Format (ReqIF).
Приведенные выше документы составляют научно-методическую базу системной и программной инженерии, они активно используются на практике, постоянно дополняются и совершенствуются. В России активные исследования в этой области ведутся в Институте систем программирования им. В. П. Иванни-кова, на факультете вычислительной математики и кибернетики МГУ им. М. В. Ломоносова, в Санкт-Петербургском государственном университете, Новосибирском государственном техническом университете, Военно-космической академии имени А. Ф. Можайского и др. Ниже приведен краткий анализ наиболее интересных, с точки зрения автора, научно-технических публикаций и работ.
В первую очередь следует представить монографии и практические руководства.
В фундаментальном труде известного сербского ученого и эксперта в области MBSE, профессора Белградского университета Д. Милисева (Dragan Milicev) [5] изложены принципы и методы применения для промышленной разработки СПТС современных информационных технологий, основанных на объектной парадигме и мо-дельно-ориентированном подходе, и, что особенно ценно в контексте исследуемых в настоящей статье проблем, даны рекомендации и примеры использования для этих целей фундаментальной части языка моделирования UML - Foundational UML (FUML). На его основе создаются и верифицируются исполняемые формальные UML-модели. Также отметим монографию [6], разработанную С. Фриденталем, А. Муром, Р. Штайнером, которые являются активными участниками разработки целого ряда методических документов и спецификаций OMG и применяют свои знания на практике в Lockheed Martin и Raytheon Company. В ней в сжатой форме с примерами изложены не только приемы и способы применения конструкций и механизмов языка SysML, но и дано объяснение его философии и принципов.
Следующую группу образуют публикации, посвященные решению частных задач разработки и верификации СПТС. Диссертационная работа сотрудника НГТУ А. В. Маркова посвящена вопросам автоматизации процессов проектирования и анализа программного обеспечения с использованием языка UML и сетей Петри [7]. В работе дано описание методики проектирования программного обеспечения с использованием UML-диаграмм последовательности в формате .xmi и представлен способ их автоматической трансляции в формат .cpn, используемый для описания сетей Петри. Результатом применения этой методики являются иерархические сети Петри, в ходе анализа которых осуществляется верификации проекта программного обеспечения (ПО), представленного в виде UML-диаграмм. Наиболее ценными для практики представляются следующие изложенные в данной работе решения:
• алгоритм преобразования UML-диаграмм в сети Петри;
• алгоритм и правила реализации инверсии в сетях Петри для проверки достижимости выбранного состояния сети;
• алгоритмическое и программное обеспечение для построения и анализа сетей Петри с целью выявить и устранить дефекты создаваемого ПО.
Полезная и ценная информация содержится в обзоре современных методов автоматической генерации тестов [8]. В работе дано описание следующих методов:
• структурного тестирования с помощью символического выполнения (structural testing using symbolic execution);
• тестирования на основе моделей (model-based testing);
• комбинаторного тестирования (combinatorial testing);
• выборочного тестирования (random testing);
• поиска на основе тестирования (search-based testing).
В статье [9] описан способ проектирования и моделирования бизнес-процессов, реализуемых в парадигме сервисно-ориентированной архитектуры (Service Oriented Architecture, SOA), с помощью диаграмм активности, для верификации которых предложено использовать аппарат цветных сетей Петри (Colour Petri Net, CPN).
В работе [10], подготовленной специалистами Шанхайского университета, описан подход к верификации крупномасштабных веб-проектов посредством разработки и анализа исполняемой модели соответствующего программного обеспечения. Для построения исполняемой модели разработан метод, в котором в качестве исходных данных используются динамические диаграммы последовательностей (Live Sequence Charts, LSCs). UML-мо-дель, представленная с помощью LSCs-диа-грамм, преобразуется в символьный конечный автомат. Сценарии тестирования создаются путем обхода автомата методом «поиск в глубину» (Depth-first search, DFS).
В статье [11] описаны два метода реализации автоматической проверки нагруженных систем реального времени с использованием сценариев. В первом случае система модели-
руется как сеть временных автоматов (ВА). Во втором - с помощью набора диаграмм динамических последовательностей (LSCs) и требований в виде отдельной анализируемой LSC-диаграммы. Автором статьи разработаны временные (темпоральные) расширения для подмножества ядра языка LSC и определена его семантика на основе трассировки. Анализируемая LSC-диаграмма транслируется в ее поведенческий эквивалент в нотации диаграммы ВА. Верификация корректности модели осуществляется посредством моделирования диаграммы ВА в режиме реального времени с использованием аппарата темпоральной логики (Computational Tree Logic, CTL) с последующим сравнением полученного результата с эталоном. Оба метода реализованы с помощью средств инструмента UPPAAL.
В работе [12] описан способ генерирования модульных тестов (unit case) на основе модели архитектуры, представленной в форме UML-диаграмм активностей. Построение тестов осуществляется с помощью решателей SMT/SAT, которые анализируют управляющий граф программы, записанной на математическом языке программирования AMPL. Особое внимание уделено смешанному целочисленному нелинейному программированию и построению логических формул (Object Constraint Language, OCL) для ограничений.
В статье [13] для установления и синхронизации связей системных требований с элементами дизайна предложено применять поведенческие SysML-диаграммы. Для реализации автоматической верификации проекта в виде комплекса SysML-диаграмм приведены следующие операции:
• преобразование SysML-диаграмм активностей в сети Петри, представленные на языке Petri Net Markup Language (PNML);
• математический аппарат и инструментальные средства анализа сетей Петри CPN Tools и SPIN; _
• алгоритм верификации присутствую- " щих в SysML-диаграммах деятельности вре- Й менных требований, представленных в виде g. формул линейной темпоральной логики (Linear Temporal Logic, LTL), с помощью разработан-
ного автором данной работы языка (Active Temporal Requirement Language, AcTRL).
В статье [14] для создания средств динамической верификации и валидации проектных поведенческих моделей предложено использовать исполняемые предметно-ориентированные языки моделирования (executable Domain-Specific Modeling Languages, XDSML). С помощью созданных на их основе средств можно осуществлять мониторинг состояния анализируемых моделей посредством построения и управления трассами их исполнения в среде виртуальной машины XDSML. Данный метод имеет более высокую производительность по сравнению со стандартной UML-метамоделью благодаря возможности исключать из обработки избыточные данные [14].
По результатам анализа публикаций и представленных в них решений можно заключить, что основные усилия исследователей направлены на разработку методов и средств автоматизированной генерации и верификации программных реализаций СПТС, в меньшей степени - на автоматизацию разработки и верификации проектных решений. Практически отсутствуют решения для автоматизированного формирования и верификации комплекса
со
о требований. В качестве основных математи-
«N
pj ческих моделей и построенных на их основе
z средств для автоматической верификации ис-
,« пользуются математический аппарат и алго-
ь ритмы анализа сетей Петри, решатели задач
** SMT/SAT, различные вариации исполняемых
8 языков моделирования xUML, а также пред-
ц метно-ориентированные языки моделирова-
» ния XDSML.
о5 Обоснование проблемных вопросов
х и способов их решения
В настоящее время наиболее эффективным J для создания СПТС является подход, основан-g ный на методологии модельно-ориентирован-ь ной системной инженерии (МОСИ) (Modeled based systems engineering, MBSE) [15], включающий три базовые технологии: разработку на основе моделей (Model driven development, ™ MDD); архитектуру на основе моделей (Model 8 driven architecture, MDA); тестирование на ос-
w нове моделей (Model based testing, MBT). В хо-tn
— де реализации данного подхода предполага-
ется, что создаваемые и используемые на всех этапах ЖЦ системы артефакты (комплекс требований, технический проект, программные и технические реализации, средства верификации и тестирования) представляются в виде формальных моделей. Благодаря этому может быть реализован программно-управляемый процесс создания ПССВ.
Процесс создания ПССВ по методологии МОСИ схематично представлен на рис. 2. Он включает три этапа, на которых создаются модели трех типов:
• модель анализа (формальное представление комплекса требований к системе);
• модель архитектуры (формальное представление технического проекта);
• модель реализации (формальное представление программной реализации).
Следует подчеркнуть, что существенной особенностью МОСИ является то, что каждый этап завершается процедурой верификации полученного на этом этапе артефакта и принятием решения о его пригодности для дальнейшего использования или направлениях его доработки при обнаружении дефектов.
Для синхронизации и обеспечения прямых и обратных связей между всеми моделями (артефактами жизненного цикла разрабатываемых систем) должны быть разработаны методы и алгоритмы автоматической трансформации и синхронизации моделей разных уровней. Формально-математической основой MBSE являются языки визуального проектирования и моделирования: MOF, UML, SysML, FUML, AFL, ArchiMate, AADL, SDL, Modelica и др. Технологическую базу составляют такие инструментальные средства, как IBM Rhapsody, Magic Draw, Sparx Enterprize Architect, Eclipse Papyrus, MASIW и др.
В настоящее время технологии и средства МОСИ применяются при создании систем и комплексов, используемых в авиационно-космической, автомобильной, кораблестроительной, микроэлектронной, энергетической, военной и других отраслях. Благодаря их использованию были достигнуты определенные успехи в части повышения производительности труда разработчиков СПТС, улучшения их качества и сокращения сроков создания.
С
с
i| Требования ТТЗ ] i
I
Требования ТТЗ на АСУ и ПССВ
Разработка ДВИ
Ос= (ak,fi, bß
-г~
)
Разработка ОДВ Л
djo (ак, Ы, bjj )
(Разработка ДКл ^ d_class(class, interface, feature, relations) л
(Разработка ДТр Л d_regs = (n,n,ft,rl,...))
Анализ и структурирование требований ТТЗ ^
(1 Разработка модели анализа: rh d_uc, oL/o, djtess, d_regs
£
Т
3 3 Разработка тестов для
верификации модели анализа *
)
^ Верификация модели анализа на полноту, неизбыточность, системность j
С
с с с с
1
Модель архитектуры, требования ТТЗ
Построение графа TCi (TTCN-3)
2. Преобразование ТСц в ALF
3. Генерация ТСц модели анализа
4. Генерация ТСц архитектуры
5. Генерация ТСц реализации
I
(Разработка ДА Л
d_act = (P,T,F,w,mO) J
Доработка ДКл d_class*=(class, interface, ), relations)
(Уточнение ДТр Л d_regs = fn, ъ, Гэ, и,..))
Рис. 2. Общая схема методологии МОСИ
В то же время кардинальным образом улучшить ситуацию пока не удалось. Основными сдерживающими факторами достижения качественных улучшений в решении данных задач являются:
• объективная сложность задачи построения формального представления требований к системе на основе исходной неформальной формы их представления;
• наличие широкого спектра языков и средств, предлагаемых для построения моделей анализа, архитектуры и реализации системы, при отсутствии четких и конкретных правил и рекомендаций их применения;
• отсутствие средств автоматизированного построения и выполнения тестовых сценариев верификации моделей анализа и архитектуры.
Таким образом, для преодоления представленных выше проблем и реализации программно-управляемого последовательно-итерационного процесса разработки и верификации моделей анализа и архитектуры
ПССВ в соответствии со схемой (см. рис. 2), необходимо разработать алгоритмическое и программное обеспечение:
• построения формального описания требований к системе (модели анализа) на основе исходной неформальной формы их представления;
• поддержки процесса проектирования ПССВ в виде связанного набора исполняемых FUML диаграмм - модели архитектуры;
• автоматизированного построения и выполнения тестовых сценариев верификации моделей анализа и архитектуры.
В качестве единой концептуальной, языковой и инструментальной среды разработки и верификации моделей анализа и архитектуры ПССВ предлагается использовать языки моделирования UML, FUML и ALF, абстрактный язык описания метамоделей MOF (MetaObject Facility) и протокол обмена метаданными XMI (XML Metadata Interchange).
В следующих разделах представлено описание разработанных автором статьи способов и алгоритмов решения данных задач.
та
та
s
о.
о fr
Алгоритм построения формальной модели требований на языке FUML
Схема алгоритма построения формальной модели требований (модели анализа), предназначенного для реализации процедуры № 1 (см. рис. 2), представлена на рис. 3. Алгоритм заключается в построении набора связанных между собой FUML-диаграмм вариантов использования (ДВИ) - d _ uc, обзорных диаграмм взаимодействия (ОДВ) - d _ io, диаграмм классов (ДКл) - d _ class, диаграмм требований (ДТр) - d _ reqs, диаграмм параметров (ДПар) - d _ pars.
Опишем диаграмму /-го варианта использования, представляющего собой функциональное требование:
d _ uci =(ак, fi, bj), где ak - пользователь или внешняя система, инициирующие исполнение функции (варианта использования) f;
fi - функция системы, реализующая вариант использования uci ;
bj - компонент (модуль, блок, класс) системы, реализующий функцию:
f (input, operation, result),
где input - входные данные;
operation - алгоритм или программа, реализующие выполнение функции f ;
result - результат выполнения функцииf.
Для каждого варианта использования разрабатывается обзорная диаграмма взаимодействия d_io:
d _ iot =(ак, iof , bj ).
• fi / • fim • fia \
Здесь loi = (loi , loi ) описывает алгоритм реализации функции j-м блоком (классом) проектируемого программного средства, который включает описание основного ioflm и альтернативных потоков iofa.
о см
см
OI
<
I
to те S
0 ^
CÛ
<я
1
о.
ф
£
и
V CÛ
СМ ■clin 9 см ■clin см
(П (П
Î
«- — -
Требования ТТЗ
Разработка ДВИ d'_ифь Ь, bj)
I
У
I Разработка ОДВ efjo (аь ioi, bj)
---
( Запрос из БД очередного djjgj^-НЕТ
Диаграммы вариантов использования
^ L
-| Class аГ\ | Interface fi~~\-> Class Ai —
1С
^(Подготовка Решетя)
3
—I classat 1 I Interface fi
^^Обзорные диаграммы взаимодействия^^
---->
I Class a\ L
¡Interface fi\
ДО40ИАЦ
ColecSon&Anafyse Decisin
ф t
I Interfaced
Class Ы
ИГ
Разработка ДКп d_class(class, interface, feature, relations)
while read (class Ы){create (interface) featurerelations*), write bk(nterfacei< featurek, relations))};
return 0;
ъ
с
Разработка ДТр d_reqs
ReqIFstructure (mainXML tag): ReqIFheader (comment, creationTime, identifier... Title) ReqIFContent ( DataTypeDefinition, SpecType, SpecObject, SpecRelation...) ReqIFToolExtension,
Ж
Диаграммы классов djclass (class, Interface, feature, relations¡^
ргЫе datajnfo: 7jps1 ptÉicreœive_data(soŒce, format, data_irrfo) ptÉicanafyse_datafda!a_rÉ), datajmc)} piÈSc reœùe_data(scŒce, tonnai data_irfo)
ptÈic zna!yse_data(data_info, datajmc)}
dassdedsion{ /mate decision: Type2 putfcreceive_inb(riput store) ^ putfcanàysejntyskxe, doc)}
Рис. 3. Разработка модели требований
Альтернативные потоки описывают работу программ при возникновении нештатных ситуаций, например, ошибочных действий пользователя, непредусмотренных воздействий со стороны внешней среды и др. Основные и альтернативные потоки могут иметь подчиненные потоки, которые в ОДВ представляются с помощью фреймов с приставкой ref_. Подчиненные потоки ОДВ отражают функционирование программы с точки зрения пользователя и могут быть формализованы с помощью диаграмм активностей, диаграмм последовательностей, машин состояний или коммуникаций. Для задания порядка и возможности реализации тех или иных потоков применяются пред- и постусловия. Для построения обзорных диаграмм взаимодействия используются:
• узлы управления nodecontrol типа decision node, merge node, fork node, join node, interaction, interaction use;
• узлы данных node object;
• ссылки на диаграммы активности ref_act;
• ссылки на диаграммы последовательности refseq;
• ссылки на диаграммы машин состояний refsm;
• ссылки на диаграммы коммуникаций refcomm.
Детальные описания алгоритмов реализации функции с системной точки зрения как основного, так и альтернативных потоков разрабатываются на этапе проектирования ПССВ. На обзорной диаграмме взаимодействия могут также применяться псевдоузлы, соответствующие началу алгоритма initial node, завершению потока управления flow final node и алгоритма activity final node, а также временные ограничения duration constraint, time constraint.
Следующим шагом построения модели анализа является разработка диаграммы нефункциональных требований, определенных в техническом задании для каждой функции:
dreqs = (г/, r{, r{, r{...),
где r/ - требования к оперативности исполнения функции f;
г
г2 - требования к производительности (например, объемы хранимых, обрабатываемых и передаваемых данных, количество поль-
зователей, количество и размеры запросов в единицу времени и др.);
r3 - требования к надежности (коэффициент готовности, время безотказной работы, время восстановления и др.);
r4 - требования к защищенности.
Для каждого функционального блока и информационного объекта программы разрабатывается конструкция class, в которой задаются атрибуты, операции (методы), ограничения и семантика. Наборы взаимодействующих классов объединяются в диаграммы классов dclass. Формально диаграмма классов может быть описана так:
d class = ( class, interface, features, relations),
где class - имена классов;
interface - интерфейсы, описывающие сигнатуры операций (входные и выходные параметры), за реализацию которых отвечают соответствующие классы. Связь класса с соответствующим интерфейсом описывается посредством отношения realization или dependency;
features - атрибуты класса, которые могут включать ограничения на значения атрибутов constraint;
relations - отношения ассоциации (association), обобщения (generalization) и зависимости (dependency) между классами. Класс владеет (ownedAttribute) атрибутами (StructuralFeature) и может находиться в определенных отношениях (association, generalisation, ...) с другими классами. Атрибуты имеют определенный тип (DataType) и характеристику множественности (MultiplicityElevent).
Фрагмент модели анализа программного обеспечения информационно-аналитического центра (ИАЦ), разработанной в соответствии с описанным выше алгоритмом, представлен на рис. 4. Данный фрагмент содержит основные элементы формальной модели требований к программному обеспечению ИАЦ, обеспечивающего реализацию функций сбора, анализа
данных и подготовки решения. Основными g
s
элементами данной модели являются: диаграм- ^ мы вариантов использования (d uc), обзорная о. диаграмма взаимодействия (d_io), диаграмма ■©■ требований (dreqs), диаграмма активностей ^
dLcísssAOHAL|
dassooleclk>n_data{ private óeia:Type1 pubic receive_data() pubicanalysejIataOl
ргШв decision: Type2 pubScrecewjMaO public analyse_data(l}
Zb
rec&ve data
X Xüass recetejfetel JL
Гт <■■■) Tt
cfass/Eoeive date dassanalyse dsh
{...} {■■■}
ÍH
d_pars decision ^J
rs
Sizeoi(decisiail< 2K6
Type2=hM
Обозначение > отношение"
отношение Include"
Рис. 4. Модель архитектуры
о сч
CV
OI
<1
I
м та
s
0 ^
CQ та
1
о.
ф
£
и
V CQ
сч ■clin 9 сч ■clin сч
(П (П
(d act), диаграммы классов (dclass), диаграмма параметров (d_pars). Они связаны между собой посредством отношений «удовлетворять требованию» (satisfy) и «включения» (include), а также через общие атрибуты.
Построенная таким образом модель анализа требований подвергается процедурам ва-лидации и верификации. Процедура валидации заключается в оценивании комплекса требований на предмет его полноты и корректности и выполняется как программными средствами, так и неформальной экспертизой специалистов в данной предметной области. При верификации проверяются такие свойства модели, как непротиворечивость, системность, неизбыточность, безопасность, живость, отсутствие взаимоблокировок, невыполнимых операций и зацикливаний. Процедура верификации модели требований осуществляется посредством ее исполнения и тестирования в среде виртуальной машины FUML и анализа с помощью решателей SAT/SMT. Описание этих методов и средств представлено в следующих разделах. Алгоритм проектирования ПССВ Проектирование архитектуры ПССВ реализуется в соответствии с алгоритмом (рис. 5). В качестве исходных данных используется модель анализа, представленная обзорными диаграммами взаимодействия d_io, диа-
граммами требований к качеству реализации функций dreqs, диаграммами классов dclass, диаграммами параметров d_pars, а также требованиями к технологиям разработки и среде функционирования. На основе каждой d ie, разрабатываются и детализируются входящие в нее диаграммы активностей d act, последовательностей dseq, состояний d_sm и коммуникаций dcomm. Для реализации процедуры верификации три последних типа диаграмм транслируются в диаграммы активностей и представляются на языке ALF (Action Language for Foundational UML). Каждая диаграмма активностей описывается с помощью узлов управления (nodecontrol) типа decision node, merge node, fork node, join node, interaction, interaction use; узлов данных (nodeobject); пре- (pre) и пост- (post) условий.
На следующем шаге алгоритма на основе каждой d_ioi разрабатываются и детализируются входящие в нее диаграммы активностей (d act), последовательностей (d seq), состояний (d_sm) и коммуникаций (dcomm). Затем для реализации процедуры верификации три последних типа диаграмм транслируются в диаграммы активностей и представляются на языке ALF (Action Language for Foundational UML). На завершающем шаге алгоритма вы-
/ Ч
N = /
Разработка архитектуры ПССВ: диаграммы djact, djclass, d_reqs
Запрос из БД диаграмм модели анализа djo, ^
( djxA ) ( d_seq —>d_acf ) Qdjsm ->cL_acQ ( d_comm —>d_act) ■ * * + * —
Q Выбор d_act¡ из d_iOi
НЕТ
( {conM_nodek} )
^ i '
( [objedjoden} )
" ^ "
( {pre-condition*} )
( {post-conditionk} ) i
( Запись d_act¡ в БД j
^Доработка d_class и d_reqs
(§К
Рис. 5. Разработка модели архитектуры
полняются доработка и корректировка диаграммы классов (d_class) и диаграммы требований (d regs) для их согласования с разработанными диаграммами активностей.
На рис. 6 приведена схема, иллюстрирующая процедуру верификации формальной FUML-модели архитектуры ПССВ посредством ее исполнения в среде виртуальной FUML-машины, включающей три компонента: ExecutionFactory, Executor и Locus. ExecutionFactory (фабрика выполнения моделей) используется для создания экземпляров семантических классов visitor, соответствующих исполняемым элементам FUML-модели.
Класс Executor, представляющий собой абстракцию виртуальной машины для исполнения FUML-модели, обеспечивает выполнение операций:
• расчет значения спецификации исполняемого элемента модели evaluate;
• синхронное выполнение поведения, получающего определенные входные данные и выдающее на выходе результат их обработки execute;
• асинхронное выполнение определенного поведения, возвращающее ссылку на экземпляр выполняемого действия start.
Выполнение FUML-модели осуществляется в конкретной виртуальной машине (Locus), являющейся абстракцией физического или виртуального компьютера. Верифицируемая в среде виртуальной FUML-машины модель архитектуры (см. рис. 6) построена из FUML-диаграмм классов и активностей и представлена на языке ALF. Модель архитектуры ПССВ верифицируется на предмет удовлетворения основным требованиям:
• полноты реализации функциональных требований, определенных в обзорных диаграммах взаимодействия dio;
те
те
s
о.
о ■fr
Стандартные пакеты FUML
FUML
Classes
IL
IL
CommonBehaviors
Activities
л Actions
Формальная модель архитектуры на FUML i -
Использует
e1
init
activity •---.
CreateObject
action
sresult: classiflier
FUML
Class
- attributed : Type
+ operation! (Type) : void - operational) : Type
Виртуальная машина для исполнения FUML (ALF) моделей
Executor
Locus
FUML (ALF)
public class Executor { public ParameterValueList
execute (Behavior behavior Execution execution = this, locus, false
execution execute ();
ExecutionFactory
Формальная модель архитектуры на ALF
class Class {
private attributed : Type; public operation1 (in param1\ Type) {
paraml .op();
}
private operation2()\ Type { return type-,
}
}
ALF
Рис. 6. Схема выполнения FUML-модели в верифицированной модели
о см
см
Ol
<
I
to та
0 ü CÛ та
1 О.
<D
â
О <D CQ
CM ■clin
9
CM ■ci-
10
CM
(П (П
• полноты и корректности реализации нефункциональных требований, определенных в диаграммах требований d_reqs и диаграммах параметров d_pars;
• согласованности и непротиворечивости всех диаграмм модели;
• отсутствия избыточности.
Кроме того, необходимо проверить, удовлетворяет ли модель архитектуры таким требованиям, как безопасность, живость, отсутствие взаимоблокировок, невыполнимых операций и зацикливаний. Описание алгоритма, обеспечивающего решение данной задачи, представлено в следующем разделе. Алгоритм разработки тестовых сценариев для верификации моделей анализа, архитектуры и реализации ПССВ Схема алгоритма разработки тестовых сценариев для верификации моделей анализа, архитектуры и реализации ПССВ представлена на рис. 7. Основными этапами реализации данного алгоритма являются:
• построение по управляющим графам диаграмм активности графов тестовых сценариев (ТСц);
• описание ТСц на языке ALF;
• генерация ТСц для верификации модели анализа;
• генерация ТСц для верификации модели архитектуры;
• генерация ТСц для верификации модели реализации.
На вход данного алгоритма может подаваться либо модель анализа, представленная в виде FUML обзорных диаграмм взаимодействия, либо модель архитектуры, представленная в виде FUML-диаграмм активностей. На их основе строится соответствующий верифицируемой модели граф ТСц, в котором учтены функциональные и нефункциональные требования к разрабатываемому ПССВ. Последние должны быть записаны на языке ограничений OCL (Object Constraint Language). Представленный на языке ALF ТСц передается на вход решателям SMT/SAT CVC-4 [16] и Z3 [17]. Эти решатели посредством символьного исполнения программ и процедур автоматического доказательства теорем осуществляют обнаружение таких дефектов, как нарушение безопасности и живости, возможности взаимоблокировок и зацикливаний, наличие тупиков, нарушение граничных
3. Генерация тестевых сценариев моделей анализа, архитектуры и реализации ПССВ
input: FUML diagram
input: FUML
^Sf Проверка корректности исходных данных^ input_._/
1
1. Построение трафа тестовых сценариев ТСц на основе f£Mfi-диаграмм
( Разбор ¿^¿-ограничений )
( Трансформация ЯЖ-диаграмм ^ ^_в граф ТСц (afeg)_)
( Добавление ограничений целостности )— Ш atcg
Т.
atcg (abstract test case graph) - фаф абстрактного тестового набора atcaif (abstract test case onALF) - абстрактный тестовый набор на языке ALF
2. Описание ТСц на языке ALF
Трансформация переменных PCL в ALF- переменные J >1/
( Трансформация локальных ЛюЛусповий в /ЦЯ-ограничения)
( Трансформация сторожевых (Guards) условий в ALF- ограничения^-1йГШ
«centra/Butter» atcg: Test Cass Graph (хранилище графов ТСц)
I
«сепЫВиПег » atcattALF model
5. Генерация ТСц для верификации модели реализации
--[ Создание unit-тестов Ig
-Щ-
ш/г-тесг
Тесты
ч
ч
ч
4. Генерация тестовых сценариев для верификации модели архитектуры
( Разработка модели ТСц-МА F^I
Ч__Лепты
Разработка модели ш/7-теста
Пути
I
Тесты
гН[ Вызов решателя SMT/SAt) itnälf^-s
«centra/Buffer» unit_tests: Unit Tests (хранилище unit-тестов)
1
3. Генерация тестовых сценариев для верификации модели анализа
С
Метод поиска в глубину
Ж
^ Исключение первого неисполнимого пути )
С* ^ —
Построение контрпримера решателем ЭМТ/ВАТ^З
( Метод поиска в ширину
I NU I Пути
«centralBuffer» tests: Unit Test Model (хранилище ТСц модели архитектуры)
«сепШВиЯег » paths: Abstract Test Case (хранилище ТСц модели анализа)
Рис. 7. Схема алгоритма разработки тестовых сценариев
значений переменных, и других ошибок проектирования и реализации. Для обнаруженных дефектов решатели 8МТ/8ЛТ генерируют тесты (контрпримеры), с помощью которых разработчики могут установить и устранить причины этих дефектов и ошибок. Заключение
В настоящее время для разработки сложных программно-технических систем активно применяются модельно-ориентированные технологии, методы и средства. При их использовании все артефакты жизненного цикла системы (требования, архитектура и реализация) должны быть представлены в виде формальных моделей. На основе проведенного анализа можно заключить, что наибольшую трудность представляют задачи формализации и верификации требований и архитектуры. Это обусловлено, во-первых, объективной сложностью задачи формализации изначально неформального представления требований, во-вторых, -отсутствием четких и конкретных правил и алгоритмов построения формальных моделей
требований и архитектуры с помощью предлагаемых для этого разнообразных языков и инструментальных средств.
Для преодоления указанных выше трудностей были разработаны следующие модели, алгоритмы и методики:
• графово-текстовая метамодель формализованного представления комплекса требований к ПС АССН в виде фиксированного набора взаимосвязанных FUML-диаграмм;
• графово-текстовая метамодель формализованного описания архитектуры ПС АССН в виде рационального набора взаимосвязанных FUML-диаграмм;
• алгоритмы разработки формальных моделей требований и архитектуры ПС АССН на основе разработанных для них метамоделей;
• алгоритмы верификации моделей требований и архитектуры ПС АССН посредством g их моделирования и анализа в среде виртуаль- |
ной FUML-машины и выполнения тестовых о.
о
сценариев, построенных с помощью решате- ■©■ лей SMT/SAT; Ё
о
CM
CM
Ol
<
I
to та
0 ü CÛ та
1
.
<D
â
о
<D CQ
CM ■clin
с?
CM ■ci-io
CM
(П (П
• методические рекомендации реализации программно-управляемого процесса разработки и верификации ПС АССН с помощью разработанных моделей и алгоритмов.
В настоящее время сотрудники Военно-космической академии им. А. Ф. Можайского проводят работы по реализации описанных в статье моделей и алгоритмов в виде комплекса программных средств. В качестве среды и прототипов используются инструментальные средства, библиотеки и приложения, реализованные в рамках проекта Eclipse (EFM, GMP, Papyrus, Moka, ReqCycl, Titan) [18]. Применение данного комплекса позволит реализовать программно-управляемый процесс разработки и верификации ПС АССН. Основными его достоинствами являются:
• использование единой модельно-язы-ковой и информационно-программной среды разработки и верификации формальных моделей требований, архитектуры и программной реализации ПС АССН, построенной на основе технологий объектно-ориентированного анализа и проектирования, методов и средств дедуктивной верификации, языков и средств визуального моделирования FUML, XMI, ALF, VMFUML;
• реализация автоматизированных процедур верификации, валидации и коррекции комплекса требований и проектных решений как в случае обнаружения каких-либо дефектов, так и при изменении самих требований или условий эксплуатации АССН, что позволит улучшить экономические показатели в части снижения финансовых и временных затрат, связанных с выполнением дополнительных работ.
Список литературы
1. The Standish Group report. URL: https://www. projectsmart.co.uk/white-papers/chaos-report.pdf (date access 14.05.2018).
2. Defense acquisitions. Assessments of selected weapon programs. Report to Congressional Committees. GAO-17-333SP. March 2017. https:// www.gao.gov/assets/690/683838.pdf (date access 14.07.2018).
3. Selby R. W., ed. Software engineering. Barry W. Boehm's lifetime contributions to software development, management, and research. Los
Alamitos: Wiley- IEEE Computer Society Press, 2007. 832 p.
4. OMG. Object management group. URL: https:// www.omg.org (date access 14.05.2018).
5. Milicev D. Model-driven development with executable UML. USA: Wrox, 2009. 816 p.
6. Friedenthal S., Moore A., Steiner R. A practical guide to SysML. The systems modeling language. Elsevier Inc., 2012. 630 p.
7. Марков А. В. Автоматизация проектирования и анализа программного обеспечения с использованием языка UML и сетей Петри. Дис. ... канд. Новосибирск, 2015.
8. Anand S., Burke E. K., Chen T. Y., Mcminn P. An orchestrated survey on automated software test case generation // Journal of Systems and Software. August 2013. Vol. 86. Iss. 8. Pp. 1978-2001.
9. Andr'e E., Choppy C., Reggio G. Activity diagrams patterns for modeling business processes. URL: http://citeseerx.ist.psu.edu/viewdoc/downl oad?doi=10.1.1.650.6505&rep=rep1&type=pdf (date access 25.07.2018).
10. LiL., GaoH., Shan T. An executable model and testing for web software based on live sequence charts // IEEE ICIS 2016, June 26-29, 2016, Okayama, Japan. URL: https://zapdf.com/an-executable-model-and-testing-for-web-software-based-on-li.html (date access 25.07.2018).
11. Li Sh., Balaguer S., David A., Kim G., Nielsen B., Pusinskas S. Scenario-based verification of real-time systems using // Formal Methods in System Design. 2010. Vol. Iss. 2-3. https://doi. org/10.1007/s10703-010-0103-z (date access 20.07.2018).
12. Kurth F. Automated Generation of Unit Tests from UML activity diagrams using the AMPL interface for constraint solvers. Hamburg: Hamburg University of Technology (TUHH), Technische Universität, Hamburg-Harburg Institute for Software Systems, 2014. 77 p.
13. RahimM., Boukala-IoualalenM., Hammad Ah. Petri nets based approach for modular verification of SysML Requirements on Activity Diagrams. URL: http:// citeseerx.ist.psu.edu/viewdoc/ (date access 20.07.2018).
14. Bousse E., Mayerhofer T., Combemale B., Baudry B. Advanced and efficient execution trace management for executable domain-specific modeling languages // Software and Systems Modeling. URL: https://link.springer.com/ article/10.1007/s10270-017-0598-5 (date access 20.07.2018).
15. HartL. E. Introduction to model-based system engineering (MBSE) and SysML. Presented at the Delaware Valley INCOSE Chapter Meeting. July 30, 2015. URL: https://www.incose.org/docs/ default-source/delaware-valley/mbse-overview-incose-30-july-2015.pdf (date access 21.06.2018).
16. CVC-4. URL: https://github.com/CVC4/ CVC4 (date access 22.05 2018).
17. Z3. URL: https://github.com/Z3Prover/z3 (date access 22.05 2018).
18. Eclipse. URL: https://www.eclipse.org/ modeling/emf/ (date access 22.05.2018).
Поступила 27.07.18
Самонов Александр Валерьянович - кандидат технических наук, доцент, старший научный сотрудник Военно-космической академии им. А. Ф. Можайского, г. Санкт-Петербург.
Область научных интересов: системный анализ, информатика, системная и программная инженерия, методы и средства обеспечения информационной безопасности.
Methodology of implementing a programmable process of software design and validation for specialised automated systems
The paper defines the most problematic issues of using model-based technologies and tools for developing specialised automated system software. Implementation of this approach assumes that all the application development life-cycle artifacts (requirements, project, implementation) are presented as formal models. We propose ways of solving these problems by means of implementing a programmable development and validation process for executable FUML models of software requirements and architecture.
Keywords: automated control systems, activity diagrams, class diagram, analysis models, architecture models, design and validation, test case generation.
Samonov Aleksandr Valeryanovich - Candidate of Engineering Sciences, Associate Professor, Senior Research Fellow, Mozhaisky Military Space Academy, Saint Petersburg.
Science research interests: systems analysis, information technology, system and software engineering, information security methods and tools.
