CC BY
35УДК 004.4
МОДЕЛИРОВАНИЕ ЖИЗНЕННОГО ЦИКЛА ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ ОТ СБОРА ТРЕБОВАНИЙ ДО ВНЕДРЕНИЯ НА ОСНОВЕ ПРИМЕНЕНИЯ
UML-ДИАГРАММЫ
К. И. Бушмелева, Л. Р. Зарипова
Сургутский государственный университет bkiya@yandex.ru, zlr23.07@gmail.com
В данной работе представлена модель сети Петри жизненного цикла программного обеспечения от сбора требований до внедрения посредством языка UML. Была дана характеристика бизнес-процессов жизненного цикла программного обеспечения, построены Case-модель и маркированная модель сети Петри с подробным описанием, после чего было реализовано дерево достижимости. Авторами проведен анализ сети Перти на безопасность и ограниченность, в результате которого было выявлено, что программное обеспечение является надежным.
Ключевые слова: сети Петри, программное обеспечение, UML-диаграммы, жизненный цикл.
SOFTWARE LIFE CYCLE MODELING FROM REQUIREMENTS GATHERING TO IMPLEMENTATION BASED ON THE USE OF UML DIAGRAMS
K. I. Bushmeleva, L. R. Zaripova
Surgut State University bkiya@yandex.ru, zlr23.07@gmail.com
The paper presents a Petri net model of the software life cycle from requirements gathering to implementation via UML. The characteristic of the business processes of the software life cycle is given. The Case-model and the marked Petri net model with detailed description are constructed. Afterwards, the reachability tree is implemented. The authors analyzed the Petri net for security and limitations resulting in the reliability of software.
Keywords: Petri nets, software, UML diagrams, life cycle.
На сегодняшний день проекты по разработке программного обеспечения (далее - ПО) нуждаются в грамотном управлении требованиями, потому что с помощью четко сформулированных требований от заказчика можно получить наглядное представление о выпускаемом продукте, т. е. от полноценного сбора требований зависит качественное описание предметной области и предложенные технические решения.
Управление требованиями к ПО - это процесс, который включает идентификацию, выявление потребностей, документирование концепции, анализ требований, отслеживание ошибок, изменение требований [1].
Основными этапами выработки требований являются:
- подготовка требований - это документирование жизненного цикла (далее - ЖЦ) требований при разработке ПО;
- управление требованиями - это базовая версия управления требованиями, которая подразумевает собой набор функциональных требований, которые разработчики выполнят в определенной итерации программы.
Основная причина, по которой проваливаются проекты, связана с управлением требований от заказчика, прежде всего это неполнота требований, которая в свою очередь влияет на результат работы, на тестирование программы и, как результат, приводит к дополнительным затратам со стороны заказчика [2]. Этапы управления требованиями включают в себя:
- документирование проекта: описание концепции проекта, цели, способов решения, функциональных требований заказчика, составление технического задания;
- контроль над статусом требований;
- изменение требований по результатам тестирования ПО на стороне заказчика. Шаблон состава требований содержит информацию о дате создания, номере версии ПО, авторе требований (аналитик), заказчике требований, техническом задании (далее - ТЗ).
Требования от заказчика собираются с помощью интервью посредством задавания вопросов по требованиям. Также необходимо детальное изучение цепочки бизнес-процессов и понимание того, в чем заключается ожидаемый заказчиком результат. Следует провести мозговой штурм с разработчиками ПО и получить информацию о возможности реализации нескольких вариантов, сроках выполнения разработки. Далее производится окончательное согласование требований с заказчиком. От данного этапа зависит рентабельность проекта в целом, и тогда можно сделать вывод, будет ли он успешным [3].
Таким образом, для решения указанной проблемы в данной работе вначале было произведено описание бизнес-процессов ЖЦ программного обеспечения от сбора требований до внедрения ПО. Далее была проанализирована надежность ЖЦ ПО с использованием дерева достижимости. Ниже приведена более детальная характеристика происходящих бизнес-процессов (табл. 1) и рассмотрена СаБе-модель (рис. 1) жизненного цикла программного обеспечения от сбора требований до внедрения на стороне заказчика.
Таблица 1
Характеристика бизнес-процессов ЖЦ ПО
№ Входные значения Функция Выходные значения
1 Требования заказчика Анализ. Аналитик собирает данные у заказчика Сбор требований
2 Сбор требований Проектирование ПО. На основе полученного сбора требований аналитик формирует техническое задание Техническое задание
3 Техническое задание Кодирование. Аналитик передает ТЗ на разработку ПО программисту Готовая программа
4 Готовая программа Тестирование. Программист пишет программный код и производит первоначальную внутреннюю проверку выходных данных ПО, далее отдает ПО на тестирование тестировщику Результат тестирования
5 Результат тестирования Внедрение. Сотрудники отдела внедрения получают ПО для внедрения на стороне заказчика Отчет о внедрении программы
6 Отчет внедрении программы Тестирование на стороне заказчика. После этапа внедрения ПО у заказчика пользователи также тестируют полученную программу Отчет о тестировании на стороне заказчика
Рис. 1. Сазе-модель ЖЦ ПО
На следующем этапе была построена маркированная модель сети Петри ЖЦ ПО (рис. 2) и дано ее подробное описание (табл. 2) от сбора требований до внедрения на стороне заказчика. Модель включает возможные варианты перехода событий назад [4].
и
Рис. 2. Маркированная модель сети Петри ЖЦ ПО
Таблица 2
Описание маркированной модели сети Петри ЖЦ ПО
№ Предусловия переходов Позиция (Pan) Постусловия переходов
1 Идентификация пользователя (11) Пользователь распознан (логин, пароль) (Pi) Формирование заявки (12)
2 Формирование заявки (12) Заявка составлена и передана в службу технической поддержки (P2) Обработка заявки (1з)
3 Обработка заявки (1з) Анализ заявки, статус «В разработку» (P3) Сбор требований от заказчика. Анализ предметной области (14)
4 Сбор требований от заказчика. Анализ предметной области (14) Формирование ТЗ (P4) Начало разработки (15)
5 Начало разработки (15) Состояние разработки (P5) Начало внутреннего тестирования (1б)
6 Начало внутреннего тестирования (1б) Позиция P6 используется для отображения состояний разработки ПО, если в P6 имеется метка, то разработчик свободен и пришедшая заявка вызывает срабатывание перехода t5. Пока программа не будет корректно работать, метки в P6 не будет, следовательно, пришедшие в позицию P5 запросы вынуждены ожидать срабатывания перехода P6 Доработка программы (112)
Окончание табл. 2
№ Предусловия переходов (Tn) Позиция (Pan) Постусловия переходов (Ти)
7 Начало внутреннего тестирования (te) Состояние тестирования (P7) Тестирование выполнено. (17)
8 Тестирование выполнено (t7) Позиция (P8) используется для отображения состояний фиксирования багов тестировщиком, если в P8 имеется метка, то те-стировщик свободен и пришедшая заявка вызывает срабатывание перехода ts. Пока баг не будет исправлен, метки P8 не будет, следовательно, пришедшие в позицию Р5 запросы вынуждены ожидать срабатывания перехода Доработка программы (112)
9 Тестирование выполнено (t7) Состояние внедрения (P9) Внедрение выполнено 0«)
10 Внедрение выполнено (ts) Передача программы заказчику (P10) Начало тестирования на стороне заказчика (19)
11 Начало тестирования на стороне заказчика (t9) Пользователи тестируют программу (P11) Тестирование на стороне заказчика выполнено. (1ю)
12 Тестирование на стороне заказчика выполнено (tío) Новые требования к программному продукту (P12) Сбор требований от заказчика. Анализ предметной области (1ц)
13 Сбор требований от заказчика. Анализ предметной области (tíí) Формирование ТЗ (P4) Начало разработки (15)
14 Исправление ошибок в разработке программы (tí2) Состояние разработки (P5) Начало внутреннего тестирования (1б)
Далее в работе был произведен анализ маркированной модели сети Петри ЖЦ программного обеспечения от сбора требований до внедрения на стороне заказчика за счет разработанного дерева достижимости (рис. 3). Деревом достижимости называется ориентированный граф, вершинами которого являются разметки сети, а дуги взвешены переходами и связывают непосредственно достижимые маркировки [5].
Рис. 3. Дерево достижимости
Для анализа дерева достижимости была использована прикладная теория сетей Петри. Известно, что сеть Петри - это математический аппарат, используемый для моделирования динамических дискретных систем [6].
Структура сети Петри описывается ее позициям и переходами, соединенными между собой дугами (при этом множество позиций и переходов не пересекаются), а также входной и выходной функциями [7]. Событием в данной сети называют срабатывание перехода, при котором метки из входных позиций этого перехода перемещаются в выходные позиции. События происходят мгновенно либо разновременно при выполнении некоторых условий. Сеть Петри (С) может быть представлена четверкой параметров (1):
С = (Р, Т, I, О), (1)
где Р = {р 1, р2, рз, ... , рп} - конечное множество позиций, п > 0; Т = {11, 12, 1з, ... ,1т} - конечное множество переходов, т > 0;
I: Т^-Р - входная функция, представленная отображением переходов в комплекты позиций; О: Р^Т - выходная функция, представленная отображением из комплектов позиций в переходы.
Состав сети Петри определяется по укрепленной входной функции I и выходной функции О (рис. 4).
С = (Р, Т, I, О)
Р = {р1, р2, р3, р4, р5, р6, р7, р8, р9, р10, р11, р12} Т = {и, Й, t3, t4, t5, 16, 17, 18, 19, 110, 111, 112}
1(р1)= {11}, О(р1) = {12}, 1(11) = {}, О(11) = {р1},
1(р2) = {12}, О(р2) = {1з}, 1(12) = {р1}, О(12) = {р2},
1(р3) = {13}, О(р3) = {14}, 1(13) = {р2}, О(13) = {13},
1(р4) = {14, 111}, О(р4) = {15}, 1(14) = {рз}, О(14) = {р4},
1(р5) = {15, 112}, О(р5) = {16}, 1(15) = {р4}, О(15) = {р5},
1(р6) = {16}, О(р6) = {112}, 1(16) = {р5}, О(16) = {р6},
1(р7) = {16}, О(р7) = {17}, 1(17) = {р7}, О(17) = {р8, р9},
1(р8) = {17}, О(р8) = {112}, 1(18) = {р9}, О(18) = {р10},
1(р9) = {17}, О(р9) = {18}, 1(19) = {р10}, О(19) = {р11},
1(р10) : = {18}, О(р10) = = {19}, 1(110) ^ = {р11}, О(110) = {112,
1(р11) : = {19}, О(р11) : = {110}, 1(111) : = {р12}, О(111) = = {р4},
1(р12) : = {110}. О(р12) = = {111}. 1(112) = = {р8}. О(112) = = {р5}.
Рис. 4. Структура сети Петри системы управления требованиями
Основные задачи исследования сетей Петри можно разделить на две группы: задачи анализа активности переходов и задачи анализа достижимости, при этом задача достижимости является основной и может быть представлена деревом достижимости. Дерево представляет все возможные последовательности запусков переходов. Всякий путь в дереве, начинающийся в корне, соответствует допустимой последовательности переходов. Для получения дерева достижимости, которое можно считать полезным инструментом анализа, необходимо найти средства ограничения его до конечного размера.
В данной работе анализ дерева достижимости произведен по свойствам: ограниченности и безопасности. Рассмотрим эти свойства сети Петри:
1. Безопасность - единичный риск ограниченности при К = 1. Это означает надежность сети Петри, когда ни при каких условиях не может появиться более одной метки в любой позиции [8, 9]. Очевидно, что безопасные сети могут быть реализованы логическими схемами с двоичными элементами памяти, представляющими отдельные позиции этой сети.
2. Ограниченность - величина меток в каждой позиции сети не может превышать некоторого значения К, т. е. не допускается превышения количества меток в данной позиции некоторого фиксированного числа [8, 9].
Подводя итог, можно отметить, что в работе была построена Case-модель жизненного цикла программного обеспечения от сбора требований до внедрения на стороне заказчика. На основе реализованной структуры данной модели была смоделирована маркированная сеть Петри, что позволило реализовать дерево достижимости. В результате получили выводы о том, что анализ безопасной и ограниченной модели ЖЦ ПО с помощью сети Петри доказывает надежность проектирования ПО.
Литература
1. Атисков А. Ю. Разработка технологии и программной системы автоматизированной трансформации диаграмм функционального проектирования в диаграммах UML. URL: http://www.dissercat.com/content/ (дата обращения: 02.07.2018).
2. Буч Г., Максимчук Р., Энгл М., Янг Б., Коналлен Дж., Хьюстон К. Объектно-ориентированный анализ и проектирование с примерами приложений. 3-е изд. / пер с англ. М. : ООО «И. Д. Вильямс», 2010. 720 с.
3. Мараховский В. Б., Розенблюм Л. Я., Яковлев А. В. Моделирование параллельных процессов. Сети Петри. Курс для системных архитекторов, программистов, системных аналитиков, проектировщиков сложных систем управления. СПб. : Профессиональная литература ; АйТи-Подготовка, 2014. 400 с.
4. Воевода А. А. Разработка программного обеспечения с применением UML диаграмм и сетей Петри для систем управления локальным оборудованием : автореф. дис. ... канд. техн. наук. 2012. URL: http://www.dissercat.com/content/razrabotka-programmnogo-obespecheniya-s-primeneniem-uml-diagramm-i-setei-petri-dlya-sistem-u (дата обращения: 20.01.2019).
5. Зарипова Л. Р., Бушмелева К. И. Модель мультиверсионной информационной системы управления изменениями программного обеспечения в информационных проектах // Вестник кибернетики. 2018. № 3 (31). С. 212-216.
6. Питерсон Дж. Теория сетей Петри и моделирования. М. : Мир, 1984. 264 с.
7. Мальков М. В., Малыгина С. Н. Сети Петри и моделирование // Сборник научных трудов 2010. URL: https://cyberleninka.rU/article/v/seti-petri-i-modelirovanie (дата обращения: 20.01.2019).
8. Марков А. В. Автоматизация проектирования анализа программного обеспечения с использованием языка UML и сетей Петри : автореф. дис. ... канд. техн. наук. 2015. 24 с. URL: https://www.nstu.ru/files/dissertations/markov_abstract_142926270737.pdf (дата обращения: 20.01.2019).
9. Пашковская Е. С. Математическое и программное обеспечение мультиверсионной информационной системы с универсальной структурой интерфейсов на основе маркированной сети Петри : автореф. дис. . канд. техн. наук. Воронеж, 2016. 18 с.
