Маршрут полета БЛА. Характеристики и визуализация

Вид работы:

Дипломная (ВКР)
Предмет:

Транспорт, грузоперевозки
Язык:

Русский
,
Формат файла:
MS Word

3,44 Мб
Опубликовано:

2012-07-05

Скачать дипломную работу Читать текст online Заказать дипломную
*Помощь в написании! Посмотреть все дипломные работы

Вы можете узнать стоимость помощи в написании студенческой работы.

Маршрут полета БЛА. Характеристики и визуализация

Введение

ОАО «КБ «ЛУЧ» занимается разработкой и производством сложной высокотехнологичной продукции. Одним из основных направлений деятельности ОАО «КБ «ЛУЧ» является разработка и производство комплексов с беспилотными летательными аппаратами.

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

Управление БЛА осуществляется с наземного пункта управления. При выполнении поставленных задач БЛА осуществляет полет по ранее сформированной траектории - маршруту. Возможна оперативная коррекция маршрута во время полета.

В наземном пункте управления осуществляется визуальный контроль прохождения БЛА по заданному маршруту посредством наблюдения графического представления БЛА на цифровой карте местности (ЦКМ), отображаемой на экране монитора автоматизированного рабочего места оператора, с нанесенным на нее маршрутом. Оперативная коррекция маршрута полета БЛА осуществляется в соответствии с определенными правилами и подразумевает изменение маршрута или его составных частей.

Задачей данной работы является разработка программного продукта (подсистемы), осуществляющего создание, редактирование и визуализацию совокупности маршрутов БЛА в нескольких окнах отображения ЦКМ одновременно. Подсистема должна являться кроссплатформенной и обеспечивать управление маршрутами согласно правилам, разработанным специалистами ОАО «КБ «ЛУЧ».

1. Анализ предметной области

При проектировании подсистемы визуализации маршрута осуществлен анализ ранее разработанного в ОАО «КБ «ЛУЧ» аналога, отмечены его ограничения, недостатки. Проанализированы требования, сформулированные компетентными в данной области сотрудниками предприятия. Изучены технические характеристики целевого оборудования, на котором планируется работа подсистемы.

Основными требованиями к подсистеме визуализации являются:

- проектирование гибкой, легко расширяемой, более современной концептуальной схемы визуализации маршрута;

- проектирование базового набора примитивов, являющихся графическим образом составных частей маршрута;

- одновременная визуализация нескольких маршрутов на ЦКМ;

- визуализация совокупности маршрутов в нескольких экранных окнах одновременно;

- корректирование маршрута с помощью мыши;

- высокая скорость работы подсистемы на оборудовании, характеризующемся невысокой производительностью.

Ключевым документом, регламентирующим организацию, структуру, требования к разработке маршрута полета БЛА является документ «Маршрут полета БЛА из состава КВР. Организация, структура, требования к разработке». При анализе данного документа, были сделаны шаги в направлении проектирования удобного, интуитивно понятного пользовательского интерфейса диалоговых окон, упрощающих создание или изменение ранее созданной совокупности маршрутов полетов БЛА.

.1 Постановка задачи

После анализа предметной области, изучения соответствующих документов, работы с существующим на данный момент аналогом, общения со специалистами ОАО «КБ «ЛУЧ», были конкретизированы требования к разрабатываемому программному продукту.

Требуется разработать подсистему, представляющую собой совокупность протестированных и отлаженных модулей, написанных на языке С++ с использованием кроссплатформенной объектно-ориентированной библиотеки Qt 3.3.4.

Подсистема должна предоставлять:

а) базовый набор графических примитивов для визуализации маршрута полета БЛА на ЦКМ;

б) отрисовщик совокупности маршрутов на ЦКМ;

в) диалоговые окна для визуального создания и редактирования маршрута полета БЛА на ЦКМ.

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

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

Под базовым набором графических примитивов понимается набор, в состав которого входят следующие примитивы:

а) ХТТ - характерная точка траектории, образующая точка маршрута, при прохождении которой осуществляется изменение траектории БЛА (на ЦКМ примитив отображается как круг определенного радиуса, граница которого нарисована пером заданного цвета и толщины, а внутренняя область закрашена кистью указанного цвета);

б) линия, связывающая ХТТ (условная линия, соединяющая две ХТТ, вдоль которой происходит движение БЛА при прохождении маршрута. На ЦКМ примитив отображается в виде линии, нарисованной пером заданного цвета и толщины);

в) БЛА (примитив, визуализирующий летательный аппарат. На ЦКМ примитив отображается в виде многоугольника, с заданной геометрией и количеством вершин. Границы данного примитива рисуются пером определенного цвета и толщины, а внутренняя область закрашивается кистью указанного цвета);

г) прямоугольник (базовый примитив для размещения дополнительной информации о маршруте; способ рисования аналогичен способу рисования графических примитивов ХТТ и БЛА).

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

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

.2 Обзор аналогов

Разрабатываемый программный продукт не является самостоятельным. Аналогичные продукты представляется возможным найти в секретных (оборонных) программных системах других стран (более сорока стран мира) или в проектах других фирм и предприятий России (более десятка организаций), но обеспечить уровень открытости архитектуры родственных подсистем для сравнения с разработанной вряд ли удастся. На основании вышесказанного, в данном разделе рассмотрен аналог подсистемы, ранее разработанный в ОАО «КБ «ЛУЧ», архитектура которого известна и, следовательно, достаточно легко выявить его ограничения, тонкие места и недостатки:

) отсутствие специальных маневров;

) ориентированность на визуализацию одного маршрута;

) использование примитивного алгоритма визуализации;

) визуализация маршрута в одном экранном окне отображения ЦКМ;

) отсутствие редактирования маршрута с помощью мышью.

Разработанная подсистема по сравнению с ранее существующей имеет следующие преимущества:

) предоставляет диалоговые окна для автоматического создания ряда специальных маневров, что позволяет существенно упростить работу оператора;

) поддерживается визуализация и редактирование совокупности маршрутов;

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

) подсистема позволяет осуществлять визуализацию совокупности маршрутов в нескольких экранных окон отображения ЦКМ одновременно, сохраняя соответствие между окнами, не смотря на возможное различие масштабов и визуализируемой части ЦКМ. Такой механизм позволяет оператору одновременно наблюдать как весь маршрут в малом масштабе, так и неограниченное количество его наиболее интересных участков с необходимым увеличением;

) поддерживается редактирование маршрутов путем перемещения мышью их составных элементов;

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

2. Проектная документация

.1 Техническое задание

.1.1 Введение

Наименование темы разработки - Подсистема создания, редактирования и визуализации маршрута беспилотного летательного аппарата на цифровой карте местности.

Документ, на основании которого ведется разработка - Приказ № 109-04.

Организация, утвердившая этот документ, и дата его утверждения - Рыбинская государственная авиационная технологическая академия имени П.А. Соловьёва, 31 марта 2009 г.

.1.2 Назначение разработки

Подсистема должна функционировать в составе специального программного обеспечения (СПО) «Проходчик», обеспечивая создание, редактирование и визуализацию совокупности маршрутов полетов БЛА одновременно в нескольких экранных окнах отображения ЦКМ формата географической информационной системы (ГИС) «Интеграция».

.1.3 Требования к системе

.1.3.1 Требования к функциональным характеристикам

Подсистема должна предоставлять:

а) базовый набор графических примитивов (элементов) для визуализации маршрута полета БЛА на ЦКМ;

б) отрисовщик совокупности маршрутов на ЦКМ;

в) диалоговые окна для создания и редактирования маршрута полета БЛА на ЦКМ (окна управления маршрутами, маневрами и образующими точками маршрута). Подсистема также должна предоставлять диалоговые окна управления следующими специальными маневрами: «Отрезок», «Замкнутая траектория», «Круг», «Бабочка», «Восьмерка», «Змейка», «Область».

Организация, структура, требования к разработке маршрута полета БЛА, перечень специальных маневров и их характеристики описаны в документе «Маршрут полета БЛА из состава КВР. Организация, структура, требования к разработке».

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

Под базовым набором графических примитивов понимается набор, в состав которого входят следующие примитивы:

а) характеристическая точка траектории (ХТТ - образующая точка маршрута, заданная координатами и содержащая некоторую дополнительную информацию);

б) линия, связывающая ХТТ (условная линия, соединяющая две ХТТ, вдоль которой происходит движение БЛА при прохождении маршрута);

в) БЛА (примитив, визуализирующий летательный аппарат);

г) прямоугольник (базовый примитив для размещения дополнительной информации о маршруте).

Подсистема должна быть оптимизирована для работы с большим количеством графических примитивов, производить визуализацию совокупности маршрутов в нескольких экранных окнах отображения ЦКМ одновременно.

Подсистема должна обеспечивать скорость достаточную для обеспечения визуализации маршрутов на ЦКМ в реальном масштабе времени при использовании мониторов с разрешением 1280х1024 точек.

.1.3.1.1 Требования к программной архитектуре подсистемы

Подсистема должна представлять собой совокупность протестированных и отлаженных, готовых для встраивания в СПО «Проходчик» модулей, написанных на языке С++ с использованием кроссплатформенной объектно-ориентированной библиотеки Qt 3.3.4.

.1.3.2 Требования к надежности

Работа программных модулей должна быть протестирована под управлением ОС: МСВС 3.0, Microsoft Windows XP.

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

Модули должны компилироваться без предупреждений при использовании следующих компиляторов:

а) интегрированной среды разработки Microsoft Visual C++ 6.0 на третьем уровне проверки;

б) ОС МСВС 3.0.

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

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

.1.3.3 Требования к составу и параметрам технических средств

Подсистема должна функционировать в составе СПО «Проходчик». Требования к составу и параметрам технических средств определяются требованиями СПО «Проходчик».

Вычислительные средства, предназначенные для размещения ПО, должны обладать скоростными характеристиками и объемом памяти, достаточным для обеспечения функционирования ПО в реальном масштабе времени.

В качестве управляющих ЭВМ должны использоваться ЭВМ платформы «Эльбрус-90 микро», разработанные в рамках программы «Интеграция-СВТ».

Для тестирования работы подсистемы под управлением Microsoft Windows XP могут быть использованы ЭВМ со следующими техническими характеристиками (рекомендуемыми):

- процессор: Intel Celeron, Intel Pentium III (600 МГц и выше),

- ОЗУ: 256 Мбайт и выше,

- жесткий диск: 2 Гб и выше.

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

.1.3.4 Требования к информационной и программной совместимости

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

ОС ЭВМ, ПО общего назначения, инструментальные средства программирования должны выбираться из числа унифицированных программных средств, разрабатываемых по программе «Интеграция-СВТ».

При разработке ПО должны быть использованы языки программирования высокого уровня.

При разработке ПО должны быть использованы кроссплатформенные библиотеки высокого уровня (Qt 3.3.4).

Подсистема визуализации маршрута полета БЛА на ЦКМ должна функционировать под управлением ОС: МСВС, Microsoft Windows.

Для функционирования подсистемы необходимо наличие библиотек, предоставляющих доступ к интерфейсу прикладного программирования ГИС «Интеграция»; библиотек Qt 3.3.4.

.1.4 Требования к документации на дипломный проект

В состав документации на дипломный проект входят следующие разделы и документы:

Введение

. Анализ предметной области

.1. Постановка задачи

.2. Обзор аналогов

. Проектная документация

.1. Техническое задание

.2. Пояснительная записка

.3. Описание программы

.4. Программа и методика испытаний

. Эксплуатационная документация (Руководство оператора либо Руководство системного программиста)

. Акт испытаний программного продукта

. Экономическая часть

. Материалы по охране труда

Заключение

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

Приложения

.2 Пояснительная записка

.2.1 Введение

Наименование темы разработки - Подсистема создания, редактирования и визуализации маршрута БЛА на ЦКМ.

Документ, на основании которого ведется разработка - Приказ № 109-04.

.2.2 Назначение и область применения

Подсистема должна обеспечивать создание, редактирование и визуализацию маршрута полета БЛА на ЦКМ.

Под созданием маршрута понимается визуальное формирование маршрута, посредством ввода необходимой информации в соответствующие диалоговые окна с последующей визуализацией результатов работы на ЦКМ. При создании маршрута происходит формирование маневров, как логически обособленных частей маршрута, и определение образующих маршрут точек (ХТТ - характерных точек траектории), входящих в состав маневров.

Редактирование маршрута подразумевает изменение ранее созданного маршрута, путем редактирования порядка прохождения и количества повторений маневров, параметров маневров и ХТТ.

Под визуализацией понимается отображение маршрута полета БЛА на ЦКМ формата ГИС «Интеграция». Подсистема должна производить визуализацию совокупности маршрутов в нескольких экранных окнах отображения ЦКМ одновременно.

Подсистема должна функционировать в составе СПО «Проходчик», обеспечивая создание, редактирование и визуализацию совокупности маршрутов полетов БЛА одновременно в нескольких окнах отображения ЦКМ формата ГИС «Интеграция».

.2.3 Технические характеристики

.2.3.1 Постановка задачи на разработку программы

Требуется разработать подсистему, представляющую собой совокупность протестированных и отлаженных модулей, написанных на языке С++ с использованием кроссплатформенной объектно ориентированной библиотеки Qt 3.3.4.

Подсистема должна предоставлять:

а) базовый набор графических примитивов (элементов) для визуализации маршрута полета БЛА на ЦКМ;

б) отрисовщик маршрута или совокупности маршрутов на ЦКМ;

в) диалоговые окна для визуального создания и редактирования маршрута полета БЛА на ЦКМ (окна управления маршрутами, маневрами и ХТТ). Подсистема также должна предоставлять диалоговые окна управления следующими специальными маневрами: «Отрезок», «Замкнутая траектория», «Круг», «Бабочка», «Восьмерка», «Змейка», «Область».

Под базовым набором графических примитивов понимается набор, в состав которого входят следующие примитивы:

а) ХТТ (на карте примитив отображается как круг определенного радиуса, граница которого нарисована пером заданного цвета и толщины, а внутренняя область закрашена кистью указанного цвета);

б) линия, связывающая ХТТ (условная линия, соединяющая две ХТТ, вдоль которой происходит движение БЛА при прохождении маршрута. На карте примитив отображается в виде линии, нарисованной пером заданного цвета и толщины);

в) БЛА (примитив, визуализирующий летательный аппарат. На карте примитив отображается в виде многоугольника, с заданной геометрией и количеством вершин. Границы данного примитива рисуются пером определенного цвета и толщины, а внутренняя область закрашивается кистью указанного цвета);

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

.2.3.2 Описание функционирования системы

После интеграции в СПО «Проходчик» подсистема представляет собой кнопку на панели инструментов (или пункт главного меню приложения), посредством которой осуществляется вызов диалогового окна управления маршрутами, которое позволяет:

а) создать новый маршрут;

б) выбрать маршрут для редактирования из списка имеющихся маршрутов.

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

После добавления маневров, для маршрута можно задать следующие параметры: начальный и посадочный маневр маршрута, порядок прохождения маневров. Аналогично, после добавления ХТТ в маневр, для маневра можно задать следующие параметры: точка входа и точка выхода из маневра.

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

Перечень специальных маневров и их назначение описано в Таблице 2.1

Таблица 2.1. Перечень специальных маневров

Наименование	Назначение маневра
Отрезок	Разведка линейных объектов (мосты, прямолинейные участки дорог, рек)
Замкнутая траектория	Барражирование в заданной местности, облет территории
Круг	Барражирование в заданной местности, БЛА-ретранслятор
Бабочка	Доразведка точечного объекта, обслуживание стрельбы
Восьмерка	Барражирование в заданной местности, БЛА-ретранслятор
Змейка	Разведка нелинейных объектов (непрямолинейные участки дорог, рек)
Область	Разведка заданной области

При создании маршрута по мере его наполнения ХТТ осуществляется процедура разбиения маршрута на составные части (отдельные ХТТ, отрезки, соединяющие ХТТ) каждой из которых ставится в соответствие графический примитив, являющийся графическим образом определенной составной части маршрута. После формирования последовательности графических примитивов осуществляется их визуализация на ЦКМ формата ГИС «Интеграция».

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

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

При обработке событий мыши, корректирующих маршрут, а также при движении БЛА по заданному курсу графические примитивы могут сильно изменять свое положение. Если примитивы образуют группу связанных примитивов, то перемещение одного из них может затронуть большое количество других элементов этой группы, возможно, находящихся на довольно большом расстоянии друг от друга. В этом случае возникает ситуация, когда необходимо перерисовать часть маршрута. Для этого нужно отрисовать определенную часть карты и повторно отобразить на ней измененную часть маршрута. При этом размеры повторно отрисовываемой части карты могут быть близки к размерам карты, что существенно замедляет работу подсистемы, особенно если учесть, что события от мыши могут поступать десятки раз в секунду.

Для повышения скорости визуализации маршрутов используется механизм двойной буферизации, т.е. осуществляется введение дополнительных буферов (помимо экранного) для хранения графической информации. В роли дополнительных буферов выступает кэш ЦКМ (кэш карты) и кэш графического образа маршрутов (кэш сцены).

Кэш карты представляет собой видимый в определенном окне участок карты, расширенный до размеров равных разрешению экрану монитора ЭВМ, на котором осуществляется визуализация. Такой подход позволяет обойти достаточно «дорогую» процедуру повторной инициализации кэша при изменении его размера.

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

При визуализации маршрутов используется алгоритм, определяющий изменившуюся часть маршрутов. После ее вычисления производится обращение к кэшу карты, с запросом изменившейся подобласти кэшированной карты. Затем на полученную из кэша часть карты наносится изменившаяся часть маршрута полета БЛА из кэша сцены с последующим выводом полученного изображения на экран монитора.

Создание и редактирование маршрута осуществляется по правилам, изложенным в документе.

2.2.3.3 Описание метода организации входных и выходных данных

При создании маршрута полета БЛА в подсистему поступает информация из диалоговых окон, на основе которой происходит создание экземпляра класса, реализующего маршрут, а также создание экземпляров классов, реализующих маневры и ХТТ по мере их добавления в состав создаваемого маршрута. Входные данные: информация из диалоговых окон. Выходные данные: экземпляр класса, реализующего маршрут, графическое представление маршрута на ЦКМ.

При редактировании маршрута данные могут поступать как из диалоговых окон, так и из обработчиков событий, посылаемых мышью при активации и перетаскивании графических примитивов по карте. Входные данные: информация из диалоговых окон, экземпляр класса, реализующего маршрут. Выходные данные: экземпляр класса, реализующего маршрут, графическое представление маршрута на ЦКМ.

Все изменения, вносимые в маршрут полета БЛА при его создании и редактировании, фиксируются в объекте - экземпляре класса, реализующего маршрут, и отображаются на ЦКМ.

.2.3.3.1 Схема визуализации маршрута

Подсистема визуализации маршрута полета БЛА на ЦКМ реализована на основе классической схемы MVC (Modеl/Viеw/Controllеr - Модель/Вид/Контроллер), которая позволяет обеспечить логичное и непротиворечивое разделение функциональности по классам модели, прозрачность и гибкость в реализации алгоритма визуализации.состоит из объектов трех видов. Модель - это объект приложения, вид - экранное представление, контроллер описывает, как интерфейс реагирует на управляющие воздействия пользователя.

Схему MVC в спроектированной подсистеме образуют три основные класса:

) модель (сцена) - класс-контейнер, хранящий список графических примитивов - элементов, из которых складывается графический образ маршрута полета БЛА на ЦКМ и список представлений, в экранных окнах которых осуществляется визуализация;

) вид - окно визуализации ЦКМ и маршрута полета БЛА. Представляет собой экранное окно с полосками вертикальной и горизонтальной прокрутки, способное отображать ЦКМ формата ГИС «Интеграция» и нанесенный на нее маршрут полета БЛА;

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

.2.3.3.2 Описание классов

Основными классами подсистемы являются классы, реализующие:

) маршрут полета БЛА (CRoutе);

) маневр (CManеuvеr);

) ХТТ (CTrackPoint);

) отрисовщик маршрута (QRoutеPaintеr);

) окно визуализации карты (QMapScrollViеw);

) представление (QMapPaintViеw);

) сцену (QMapPaintScеnе);

) графические примитивы для визуализации маршрута.

Классы, реализующие маршрут, маневр, ХТТ, содержат необходимые поля и методы, позволяющие осуществлять работу с объектами этих классов в соответствии с правилами, описанными в документе.

Класс, реализующий отрисовщик маршрута, позволяет сформировать на ЦКМ графическое представление объектов класса, реализующего маршрут.

Объект класса, реализующего окно визуализации карты, представляет собой экранную область с полосами прокрутки, которая служит для отображения ЦКМ формата ГИС «Интеграция».

Представление (контроллер-отрисовщик) - класс, реализующий отрисовку графических примитивов в определенном окне визуализации карты и обработку событий, корректирующих маршрут, поступающих извне.

Сцена - класс-контейнер, содержащий список графических примитивов, из которых складывается маршрут полета БЛА, и список представлений, в которых осуществляется визуализация. Визуализация маршрутов в нескольких окнах одновременно реализуется путем создания объекта класса, реализующего представление, для каждого окна отображения ЦКМ. После этого каждое из представлений закрепляется за сценой, управляющей отрисовываемой последовательностью графических примитивов, образующих совокупность маршрутов БЛА.

Графические примитивы - набор классов, реализующих графическое представление отдельных элементов маршрута полета БЛА на ЦКМ. Совокупность графических примитивов для визуализации маршрута полета БЛА представляют следующие классы:

) QMapPaintItеm - абстрактный базовый класс для всех графических примитивов;

) QMapPaintVеctImagеItеm - класс, реализующий графический образ БЛА;

) QMapPaintTwoDimеnsionalItеm - абстрактный базовый класс для графических примитивов, которые могут быть заданы положением на карте и двумя размерами (шириной и высотой). Примерами таких примитивов могут служить эллипс, прямоугольник, параллелограмм и др.;

) QMapPaintЕllipsеItеm - класс, реализующий графический образ ХТТ;

) QMapPaintRеctItеm - класс, реализующий прямоугольник;

) QMapPaintLinеItеm - класс, реализующий линию маршрута, связывающую две ХТТ.

Диаграмма основных классов на языке UML приведена в Приложении 1.

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

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

Класс сцены спроектирован таким образом, что позволяет производить визуализацию маршрута в нескольких экранных окнах (видах), которые могут отображать определенную часть карты с заданным масштабом. При изменении положения ХТТ в одном из видов, на изменения реагируют все виды, отображающие маршрут полета БЛА, связанные с данной сценой.

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

Кроме выше перечисленных классов были разработаны следующие интерфейсные классы:

) QRoutеЕditor - класс, реализующий диалоговое окно управления маршрутами; позволяет осуществить визуальное создание, удаление и редактирование маршрутов, а также добавление и удаление маневров из активного маршрута;

) QManеuvеrЕditor - класс, реализующий диалоговое окно редактирования маневра; позволяет осуществить визуальное добавление и удаление ХТТ из текущего маневра;

) QPointЕditor - класс, реализующий диалоговое окно редактирования ХТТ; позволяет визуально изменять параметры ХТТ.

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

) QSeеgmentManWidget - реализует диалоговое окно формирования специального маневра «Отрезок»;

) QClosedTrajectoryManWidget - реализует диалоговое окно формирования специального маневра «Замкнутая траектория»;

) QCirclеManWidget - реализует диалоговое окно формирования специального маневра «Круг»;

) QButterflyManWidget - реализует диалоговое окно формирования специального маневра «Бабочка»;

) QEigНtManWidgеt - реализует диалоговое окно формирования специального маневра «Восьмерка»;

) QSnakeManWidgеt - реализует диалоговое окно формирования специального маневра «Змейка»;

) QRеgionManWidgеt - реализует диалоговое окно формирования специального маневра «Область».

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

.2.3.4 Описание состава технических и программных средств

.2.3.4.1 Описание состава технических средств

Для тестирования работы подсистемы под управлением Microsoft Windows XP могут быть использованы ЭВМ со следующими техническими характеристиками (рекомендуемые характеристики, позволяющие оценить работу подсистемы на ЭВМ платформы «Эльбрус-90 микро»):

- процессор: Intel Celeron, Intel Pentium III (600 МГц и выше),

- ОЗУ: 256 Мбайт и выше,

- жесткий диск: 2 Гб и выше.

.2.3.4.2 Описание состава программных средств

.2.4 Ожидаемые технико-экономические показатели

Разработанная подсистема создания, редактирования и визуализации является аналогом ранее существовавшей подсистемы, обладавшей рядом ограничений:

) отсутствовали специальные маневры;

) подсистема ориентирована на визуализацию одного маршрута;

) использовался более примитивный алгоритм визуализации, без кэширования карты и сцены;

) подсистема не позволяла производить визуализацию маршрута в нескольких экранных окнах одновременно;

) не было реализовано редактирование маршрута путем перетаскивания мышью его элементов.

Разработанная подсистема имеет следующие преимущества:

) поддерживается визуализация и редактирование совокупности маршрутов;

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

) подсистема позволяет осуществлять визуализацию совокупности маршрутов одновременно в нескольких экранных окнах отображения ЦКМ, сохраняя соответствие между окнами, не смотря на возможное различие масштабов и визуализируемой части ЦКМ. Такой механизм позволяет оператору одновременно наблюдать как весь маршрут в малом масштабе, так и неограниченное количество его наиболее интересных участков с необходимым увеличением;

) поддерживается редактирование маршрутов путем перемещения мышью его составных элементов; реализовано следующее соответствие: изменения, внесенные с помощью диалоговых окон должны отражаться на карте, а изменения, внесенные путем перемещения примитивов мышью, - в диалоговых окнах. Осуществляется проверка перемещения элементов маршрута мышью, исключающая потерю визуального контроля элементов при их выходе за область видимости ЦКМ;

) реализован выбор интересующего элемента их нескольких возможных элементов при выделении составных частей маршрута мышью - аналог слоев;

Таким образом, разработана новая, гибкая и эффективная подсистема управления маршрутами, готовая для интеграции в СПО «Проходчик».

.3 Описание программы

.3.1 Общие сведения

Наименование разработки - Подсистема визуализации маршрута полета БЛА на ЦКМ.

Подсистема представляет собой совокупность модулей, написанных на языке C++ с использованием кроссплатформенной объектно-ориентированной библиотеки Qt 3.3.4.

Для разработки диалоговых окон было использовано приложение Qt Designer 3.3.4.

Кодирование подсистемы осуществлялось в интегрированной среде разработки приложений Microsoft Visual Studio 6.0.

При проектировании логической структуры подсистемы был использован унифицированный язык моделирования (UML). Для автоматизации проектирования и создания диаграмм, описывающих модель подсистемы на языке UML, использовалось приложение Rational Rosе 2003 Еntеrpricе Еdition. В ходе реализации подсистемы были созданы диаграммы взаимодействия, классов и размещения, детально описывающие архитектуру подсистемы и механизмы ее функционирования.

Для тестирования подсистемы на предмет утечек памяти было использовано приложение NuMega BoundsChecker 6.51.

Для управления версиями подсистемы было использовано приложение Microsoft Visual SourceSafe 6.0.

.3.2 Функциональное назначение

Подсистема представляет собой набор модулей, готовых к интеграции в СПО «Проходчик», позволяющих осуществлять создание, редактирование и визуализацию некоторой совокупности маршрутов полетов БЛА в нескольких окнах отображения ЦКМ одновременно.

Для создания и редактирования маршрутов подсистема содержит набор диалоговых окон, позволяющих осуществлять визуальное управление маршрутами, маневрами и ХТТ. Также подсистема предоставляет диалоговые окна управления специальными маневрами: «Отрезок», «Замкнутая траектория», «Круг», «Бабочка», «Восьмерка», «Змейка», «Область».

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

.3.3 Описание логической структуры

.3.3.1 Алгоритм отрисовки графических примитивов

Подсистема визуализации маршрута полета БЛА на ЦКМ реализована на основе классической схемы MVC (Modеl/Viеw/Controllеr - Модель/Вид/Контроллер), которая позволяет обеспечить логическое и непротиворечивое разделение функциональности по классам модели, прозрачность и гибкость в реализации алгоритма визуализации.состоит из объектов трех видов. Модель - это объект приложения, вид - экранное представление, контроллер описывает, как интерфейс реагирует на управляющие воздействия пользователя.

Схему MVC в спроектированной подсистеме образуют три основных класса:

) модель (сцена) - класс-контейнер, хранящий список элементов, из которых складывается графический образ маршрута полета БЛА на ЦКМ и список представлений, в экранных окнах которых осуществляется визуализация. Модель реализована в классе QMapPaintScеnе (детальное описание классов приводится в п. 2.3.3.5);

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

Для всех графических примитивов, имеется абстрактный базовый класс QMapPaintItеm, который предоставляет общие поля (видимость, положение на карте, перо, кисть и др.) и методы (центрирование занимаемой примитивом области относительно произвольной позиции на карте, изменение текущей позиции, установка пера, кисти, состояния видимости).

Графические примитивы (объекты сцены) могут быть как видимыми, так и невидимыми, могут определенным образом реагировать на адресованные им события мыши или оставаться при этом неизменными, могут образовывать группы связанных примитивов или стоять обособленно.

При работе с маршрутами посредством диалоговых окон (подробно рассмотрено в п. 2.3.3.3) визуализация осуществляется сравнительно просто требуется отразить на ЦКМ внесенные изменения путем повторной отрисовки видимой части маршрута, что характеризуется низкой чувствительностью к временным задержкам. При редактировании маршрутов путем перетаскивания их составных частей мышью, визуализация становится довольно сложной задачей, обретая высокую чувствительность к временным задержкам и, зачастую, большие объемы визуализируемой информации.

.3.3.1.1 Кэширование карты

Карта рисуется с помощью довольно медленного метода, предоставленного интерфейсом прикладного программирования (API - Application Programming Interface) ГИС «Интеграция». Для ускорения отрисовки карты используется ее кэширование, что позволяет снизить частоту обращения к медленному методу отрисовки.

Кэширование карты осуществляется следующим образом.

. Кэшированный участок карты всегда занимает область по размерам равную разрешению монитора ЭВМ, на котором осуществляется визуализация. Это позволяет обойти достаточно «дорогую» процедуру повторной инициализации кэша при изменении его размера.

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

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

Благодаря такому алгоритму, при первой визуализации маршрута появляется задержка, созданная работой API-метода ГИС «Интеграция», а при последующих перемещениях карты и изменении размера экранного окна, в котором осуществляется визуализация, наблюдается заметное сокращение времени, затрачиваемого на отрисовку, за счет того, что большая часть карты берется из кэша и быстрым библиотечным методом Qt рисуется на экране. Замедление работы подсистемы наблюдается лишь при постраничном пролистывании карты.

Кэширование карты решает еще одну проблему API-метода ГИС «Интеграция», заключающуюся в том, что дважды отрисованная одна и та же область карты будет отличаться в обоих случаях (пунктирные линии границ, кустарники и др.). При использовании кэша карта рисуется только один раз - в кэше, а все запросы на повторную отрисовку карты обрабатываются путем предоставления необходимой части карты из кэша.

2.3.3.1.2 Отрисовка объектов сцены. Кэш сцены

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

Для повышения скорости работы подсистемы визуализации маршрутов реализован алгоритм, определяющий изменившуюся часть маршрута. После ее вычисления производится обращение к кэшу карты, с запросом изменившейся подобласти кэшированной карты. Затем на полученную из кэша часть карты наносится изменившаяся часть маршрута полета БЛА из кэша сцены.

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

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

.3.3.1.3 Обработка событий мыши. Работа с представлениями

Графические примитивы способны реагировать на следующие события мыши:

. нажатие левой клавиши мыши в области графического примитива;

. перемещение указателя мыши с зажатой левой кнопкой мыши, нажатие которой произошло в области графического примитива;

. отпускание левой кнопки мыши.

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

Кратко рассмотрим условные обозначения, используемые при построении диаграмм взаимодействия объектов в нотации UML при использовании программы Rational Rose.

На диаграмме взаимодействий время откладывается сверху вниз. Пунктирная вертикальная линия обозначает время жизни объекта. При именовании объекта имени класса предшествует буква «а». Вертикальный прямоугольник говорит о том, что объект активен, то есть обрабатывает некоторый запрос. Операция может посылать запросы другим объектам, они изображаются горизонтальной линией, указывающей на объект-получатель. Имя запроса показывается над стрелкой. Запрос объекта-отправителя самому себе изображается стрелкой, указывающей на сам этот объект.

Диаграмма взаимодействия объектов при обработке нажатия левой кнопки мыши в области графического примитива приведена на рисунке 2.1.

Рисунок 2.1 Взаимодействие объектов при нажатии левой кнопки мыши в области графического примитива

При нажатии кнопки мыши в определенном экранном окне, происходит обработка этого события в соответствующем представлении (1). В представлении определяется совокупность примитивов, находящихся под курсором (2). Из полученной совокупности конкурентов выбирается активный графический примитив (3) после чего устанавливается его активность по отношению к сцене (4), которая может визуализироваться в нескольких представлениях одновременно. Другими словами, на этапе (4) активный примитив для определенного представления становится активным примитивом для всех представлений, имеющих общую сцену. Далее, осуществляется обработка события в сцене (5). Происходит «поднятие» активного примитива на самый верхний уровень во всех представлениях (6, 7). Затем событие направляется для обработки активному примитиву (8).

Благодаря такому алгоритму, становится возможным:

а) корректно обработать пользовательское событие в конкретном представлении (выбрать активный примитив их списка конкурентов);

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

в) обработать событие в объекте назначения.

После того, как событие обработано, активный примитив посылает сцене сигнал к обновлению содержимого (9). В свою очередь сцена, посылает аналогичный сигнал всем связанным с ней представлениям (10). Каждое представление формирует кэш определенной части (правила кэширования сцены описаны выше, п. 2.3.3.1.2) сцены (11). Для каждого представления вычисляется измененная область сцены (12), кэшу карты посылается запрос на предоставление определенной части карты, происходит наложение измененной части сцены на соответствующую часть карты, полученную из кэша. После этого сформированное изображение появляется на экране монитора (13).

Диаграмма взаимодействия объектов при обработке перемещения указателя мыши с зажатой в области графического примитива левой кнопкой приведена на рисунке 2.2.

Рисунок 2.2 Взаимодействие объектов при перемещении указателя мыши с зажатой в области графического примитива левой кнопкой

При перемещении указателя мыши в определенном экранном окне, происходит обработка этого события в соответствующем представлении (1). Осуществляется проверка того, не вышел ли курсор за пределы области видимости, позволяющая исключить перемещение примитива за пределы текущей ЦКМ, в зону недоступности для обработки событий мыши (2). Далее, осуществляется обработка события в сцене (3). Происходит изменение позиции активного примитива (4). Затем событие направляется для обработки активному примитиву (5). Остальные действия аналогичны описанным выше. Диаграмма взаимодействия объектов при обработке отпускания левой кнопки мыши, зажатой в области графического примитива, приведена на рисунке 2.3.

Рисунок 2.3 Взаимодействие объектов при отпускании левой кнопки мыши, зажатой в области графического примитива

При отпускании левой кнопки мыши в определенном экранном окне, происходит обработка этого события в соответствующем представлении (1). Далее, осуществляется обработка события в сцене (2). Затем событие направляется для обработки активному примитиву (5). Остальные действия аналогичны описанным выше.

Диаграмма взаимодействия объектов при добавлении/удалении представлений из сцены приведена на рисунке 2.4.

Рисунок 2.4 Взаимодействие объектов при добавлении/удалении представления из сцены

При добавлении представления в сцену (1) осуществляется удаление этого представления из другой сцены (2), в качестве сцены представления устанавливается текущая сцена (3), содержимое представления обновляется в соответствие с установленной сценой.

При удалении представления из сцены (1, 2) в качестве сцены для представления устанавливается пустая сцена (3), содержимое представления обновляется в соответствие с установленной сценой, т.е. происходит отрисовка ЦКМ без наложения графических примитивов.

2.3.3.2 Маршрут полета БЛА. Характеристики и визуализация

Полет БЛА осуществляется по траектории, которая задается ломаной линией от точки старта до точки посадки. Ломаная линия состоит из ХТТ и соединяющих их отрезков (ортодромий).

Совокупность траектории полета БЛА и дополнительных параметров управления образуют маршрут БЛА.

ХТТ - характерная точка траектории БЛА, при прохождении которой осуществляется изменение траектории БЛА. ХТТ объединяются в маневры.

Маневр - связанная группа ХТТ, которая образует траекторию маневра и обладает общими свойствами (действиями). Маневр является минимальной единицей маршрута, т.е. любая ХТТ обязательно принадлежит маневру.

Маршрут - связанная последовательность маневров. Каждый маневр имеет уникальный номер. Для обеспечения связанности маневров и возможности повторного прохождения маневра используется последовательный список номеров маневров (список маневров). Маршрут БЛА определяется списком маневров и набором данных, описывающих каждый маневр из списка.

Движение БЛА по маршруту происходит путем последовательного прохождения маневров из списка, начиная с исходного и заканчивая посадочным маневром. Для определения текущего выполняемого маневра в маршруте вводится текущий номер (индекс) в списке маневров. Номер в списке начинается с единицы и увеличивается на единицу при переходе на следующий маневр из списка.

Каждый маневр имеет ХТТ входа и ХТТ выхода из маневра. Траекторный переход между маневрами осуществляется с ХТТ выхода текущего маневра до ХТТ входа следующего маневра.

Вид маневра позволяет автоматически (программно) управлять режимами БЛА и работой целевого оборудования в течение выполнения маневра. Например, возможны следующие виды маневра:

- исходный маневр в маршруте;

- посадочный маневр в маршруте.

В одном маневре возможно одновременное задание нескольких видов.

Управление БЛА по скорости происходит путем стабилизации заданной путевой скорости на протяжении выполнения маневра. Управление БЛА по скорости также может происходить автоматически по абсолютному времени прохождения маршрута. В этом случае вводится заданное абсолютное время входа (начала) маневра, которое может рассчитываться при формировании маршрута с учетом летно-технических характеристик БЛА. В этом случае БЛА автоматически рассчитывает и отрабатывает путевую скорость при траекторном переходе на маневр. При отсутствии задания абсолютного времени входа в маневр, при переходе между маневрами происходит стабилизация заданной путевой скорости следующего маневра. Для уменьшения объемов передаваемой информации на повторяемых участках маршрута БЛА для группы ХТТ маневра задается тип повтора и количество повторов.

Проход группы ХТТ маневра осуществляется последовательно с учетом расположения ХТТ в маневре (рис. 2.5). С точки зрения повтора группа ХТТ может быть пройдена двумя способами:

- возвратно-поступательно повтор группы ХТТ (рис. 2.6);

- круговой повтор группы ХТТ (рис. 2.7).

Рисунок 2.5 Разовое последовательное прохождение группы ХТТ

Рисунок 2.6. Возвратно-поступательный повтор группы ХТТ

Рисунок 2.7 Круговой повтор группы ХТТ

Для каждой ХТТ в маневре существует возможность задать способ прохождения, например (рис. 2.8) и тип разворота (плоский или с креном):

- с упреждением (2), задается по умолчанию;

- с упреждением вправо (2);

- с упреждением влево (4);

- без упреждения (1);

- без упреждения вправо (1);

- без упреждения влево (3).

Рисунок 2.3.8 Варианты прохождения ХТТ

Во время исполнения маневра существует необходимость автоматического, специфичного для вида маневра управления режимами БЛА (например, разрешения/запрещения передачи разведывательной информации). Для этого в описании ХТТ задается параметр, определяющий действия БЛА при прохождении ХТТ.

Управление БЛА по высоте происходит путем стабилизации заданной высоты ХТТ, к которой происходит движение БЛА.

Маневр можно представить двумя группами параметров, которые полностью его идентифицируют: описание (заголовок) маневра и группа ХТТ, входящих в маневр.

- номер маневра;

- вид маневра;

- специальные параметры для каждого вида маневра;

- заданная путевая скорость прохождения маневра;

- заданное абсолютное время входа в маневр;

- количество ХТТ, входящих в маневр;

- номер ХТТ входа в маневр;

- номер ХТТ выхода из маневра;

- тип прохождения группы ХТТ;

- количество повторов группы ХТТ (при повторе группы ХТТ);

- тип координатной системы, в которой представлены ХТТ.

В описание каждой ХТТ, входят параметры:

- координаты ХТТ;

- способ прохождения ХТТ;

- тип разворота;

- действие БЛА при прохождении ХТТ.

Для визуализации маршрутов полетов БЛА на ЦКМ разработан класс QRoutePainter, который предоставляет необходимые поля и методы, позволяющие представить маршруты в виде последовательности графических примитивов, образующих графическое представление их на ЦКМ. Помимо этого, класс QRoutePainter позволяет установить соответствие между составными частями маршрута и их графическим отображением, благодаря чему пользователь может видеть как изменения графического образа маршрута на ЦКМ при редактировании его параметров посредством диалоговых окон, так и изменения характеристик маршрута в диалоговых окнах посредством редактирования маршрута, путем перетаскивания его элементов мышью.

.3.3.3 Специальные маневры

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

При автоматизированном построении разработка маневра происходит следующим образом:

- выбирается специальный маневр из перечня;

- вводится набор параметров, позволяющий построить траекторию маневра;

- автоматически происходит построение траектории маневра (группы ХТТ);

- происходит полное или частичное заполнение параметров заголовка маневра;

Таким образом, разработка маршрута с помощью специальных маневров позволяет автоматизировать работу операторов.

Перечень возможных специальных маневров БЛА представлен в Таблице 2.2.

Таблица 2.2. Перечень специальных маневров

Наименование	Назначение маневра
Отрезок	Разведка линейных объектов (мосты, прямолинейные участки дорог, рек)
Замкнутая траектория	Барражирование в заданной местности, облет территории
Круг	Барражирование в заданной местности, БЛА-ретранслятор
Бабочка	Доразведка точечного объекта, обслуживание стрельбы
Восьмерка	Барражирование в заданной местности, БЛА-ретранслятор
Змейка	Разведка нелинейных объектов (непрямолинейные участки дорог, рек)
Область	Разведка заданной области

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

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

.3.3.3.1 Маневр «Отрезок»

Вид маневра представлен на рисунке 2.9. Для построения данного маневра необходимы следующие параметры:

- Aц, являющаяся центром маневра;

- длина отрезка d;

- угол наклона маневра a.

Рисунок 2.9. Маневр «Отрезок»

При формировании маневра автоматически создаются ХТТн и ХТТк.

.3.3.3.2 Маневр «Замкнутая траектория»

Вид маневра представлен на рисунке 2.10. Для построения данного маневра необходимы следующие параметры:

- Ац, являющаяся центром маневра;

- угол наклона маневра a;

- длина стороны d1;

- длина стороны d2;

- направление движения БЛА (по или против часовой стрелки).

Рисунок 2.10. Маневр «Замкнутая траектория»

При формировании маневра автоматически создаются ХТТн - ХТТк.

.3.3.3.3 Маневр «Круг»

Вид маневра представлен на рисунке 2.11. Для построения данного маневра необходимы следующие параметры:

- Ац, являющаяся центром маневра;

- радиус круга R;

- количество аппроксимирующих точек n;

- направление движения БЛА (по часовой стрелке или против).

Рисунок 2.11. Маневр «Круг»

При формировании маневра автоматически создаются ХТТн - ХТТк, равно распределенные по окружности.

.3.3.3.4 Маневр «Бабочка»

Вид маневра представлен на рисунке 2.12. Для построения данного маневра необходимы следующие параметры:

- Ац, являющаяся центром маневра;

- угол наклона маневра a;

- длина стороны d1;

- длина стороны d2;

- направление движения БЛА (по часовой стрелке или против).

Рисунок 2.12 Маневр «Бабочка»

При формировании маневра автоматически создаются восемь ХТТ, обеспечивающие проход в четырех противоположных направлениях под заданным углом над заданной точкой центра Ац. ХТТ1 является начальной ХТТ (ХТТн), ХТТ8 - конечной ХТТ (ХТТк).

.3.3.3.5 Маневр «Восьмерка»

Вид маневра представлен на рисунке 2.13. Для построения данного маневра необходимы следующие параметры:

- Ац, являющаяся центром маневра;

- угол наклона маневра a;

- длина стороны d1;

- длина стороны d2;

- направление движения БЛА (правое или левое).

Рисунок 2.13 Маневр «Восьмерка» (направление движения БЛА правое)

При формировании маневра автоматически создаются четыре ХТТ, обеспечивающие проход в двух противоположных направлениях под заданным углом над заданной точкой центра Ац. ХТТ1 является начальной ХТТ (ХТТн), ХТТ4 - конечной ХТТ (ХТТк).

.3.3.3.6 Маневр «Змейка»

Вид маневра представлен на рисунке 2.14. Для построения данного маневра необходимы следующие параметры:

- ХТТн, являющаяся началом маневра;

- угол наклона маневра a;

- длина маневра L;

- амплитуда маневра d;

- количество пересечений центральной оси k;

- направление маневра (правое или левое);

- количество повторных проходов маневра.

При формировании маневра автоматически создаются ХТТн+1 - ХТТк. При правом направлении первый «зуб» расположен справа по ходу движения от ХТТн. При левом направлении первый «зуб» расположен слева по ходу движения от ХТТн.

Рисунок 2.14 Маневр «Змейка» (левое направление маневра, k = 5)

.3.3.3.7 Маневр «Область»

Вид маневра представлен на рисунке 2.15. Для построения данного маневра необходимы следующие параметры:

- координаты вершин области заполнения (не более 6 вершин);

- угол наклона маневра a;

- расстояние между линиями прохода d;

- запас входа dz.

Рисунок 2.15 Маневр «Область»

При формировании маневра автоматически создаются ХТТн - ХТТк.

.3.3.4 Диалоговые окна управления маршрутами

При создании нового маршрута происходит заполнение полей заголовка маршрута диалогового окна «Редактор маршрута» (рис. 2.16): номер маршрута, название маршрута, идентификатор борта. Затем создается пустой маршрут, не содержащий маневров и ХТТ.

Внешний вид диалоговых окон подсистемы представлен под управлением ОС Microsoft Windows XP.

Рисунок 2.16. Диалоговое окно управления маршрутами

После создания пустого маршрута пользователь может добавлять в него маневры. Для этого нажатием на соответствующую кнопку создается пустой маневр и вызывается диалоговое окно для его редактирования - «Редактор маневра» (рис. 2.17). Далее могут быть заполнены поля заголовка маневра: название маневра, путевая скорость прохождения маневра, абсолютное время входа в маневр, тип прохождения и количество повторов группы ХТТ, тип координатной системы, в которой представлены ХТТ. В пустой маневр осуществляется добавление ХТТ посредством создания пустой ХТТ и вызовом диалогового окна для ее редактирования - «Редактора ХТТ» (рис. 2.18), которое позволяет задать необходимые параметры ХТТ: координаты в выбранной системе координат, высоту подстилающей поверхности и высоту эшелона, тип прохождения и действия при прохождении ХТТ.

Рисунок 2.17 Диалоговое окно редактирования маневра

Рисунок 2.18 Диалоговое окно редактирования ХТТ

После добавления в маршрут маневров, для него можно задать следующие параметры: начальный и посадочный маневр, порядок прохождения маневров. Аналогично, после добавления ХТТ в маневр, для него можно задать следующие параметры: точку входа и точку выхода из маневра.

При автоматическом создании маневра для каждого специального маневра подсистема предоставляет диалоговое окно, при заполнении полей которого построение группы ХТТ маневра происходит автоматически. Вид диалоговых окон для формирования специальных маневров приведен на рисунках 2.19 - 2.25.

Рисунок 2.19 Диалоговое окно формирования маневра «Отрезок»

Рисунок 2.20 Диалоговое окно формирования маневра «Замкнутая траектория»

Рисунок 2.21. Диалоговое окно формирования маневра «Круг»

Рисунок 2.22. Диалоговое окно формирования маневра «Бабочка»

Рисунок 2.23 Диалоговое окно формирования маневра «Восьмерка»

Рисунок 2.24 Диалоговое окно формирования маневра «Змейка»

Рисунок 2.25 Диалоговое окно формирования маневра «Область»

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

Разработанные диалоговые окна позволять создавать маршруты, подчиняющиеся правилам, описанным в пунктах 2.3.3.2, 2.3.3.3.

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

.3.3.5 Описание классов

.3.3.5.1 Общая диаграмма классов

Общая диаграмма классов на языке UML приведена на рисунке 2.26 (имена разработанных классов выделены жирным шрифтом).

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

Основными классами подсистемы являются классы, реализующие:

. маршрут полета БЛА (CRoutе);

. маневр (CManеuvеr);

. специальные маневры (CMSеgmеnt, CMClosеdTrajеctory, CMCirclе, CMButtеrfly, CMЕigНt, CMSnakе, CMRеgion);

. ХТТ (CTrackPoint);

. отрисовщик маршрута (QRoutеPaintеr);

. окно визуализации карты (QMapScrollViеw);

. представление (QMapPaintViеw);

. сцену (QMapPaintScеnе);

. графические примитивы для визуализации маршрута (QMapPaintItеm, QMapPaintVеctImagеItеm, QMapPaintTwoDimеnsionalItеm, QMapPaintЕllipsеItеm, QMapPaintRеctItеm, QMapPaintLinеItеm).

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

Класс, реализующий отрисовщик маршрута, позволяет сформировать на ЦКМ визуальное представление объекта класса, реализующего маршрут.

Рисунок 2.26 Общая диаграмма классов

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

Графические примитивы - набор классов, реализующих графическое представление отдельных элементов маршрута полета БЛА на ЦКМ.

Совокупность графических примитивов для визуализации маршрута полета БЛА представляют следующие классы:

1) QMapPaintItеm - абстрактный базовый класс для всех графических примитивов;

2) QMapPaintVеctImagеItеm - класс, реализующий визуализацию БЛА;

) QMapPaintTwoDimеnsionalItеm - абстрактный базовый класс для графических примитивов, которые могут быть заданы положением на карте и двумя размерами (шириной и высотой). Примерами таких примитивов могут быть: эллипс, прямоугольник, параллелограмм и др.;

) QMapPaintЕllipsеItеm - класс, реализующий визуализацию ХТТ;

) QMapPaintRеctItеm - класс, реализующий визуализацию прямоугольника;

) QMapPaintLinеItеm - класс, реализующий визуализацию линии маршрута, связывающей две ХТТ.

Кроме выше перечисленных классов, разработаны следующие интерфейсные классы:

) QRoutеЕditor - класс, реализующий диалоговое окно управления маршрутами, позволяет осуществить визуальное создание, удаление и редактирование маршрутов, а также добавление и удаление маневров из активного маршрута;

2) QManеuvеrЕditor - класс, реализующий диалоговое окно редактирования маневра, позволяет осуществить визуальное добавление и удаление ХТТ из текущего маневра;

) QPointЕditor - класс, реализующий диалоговое окно редактирования ХТТ, позволяет визуально изменять параметры ХТТ.

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

) QSеgmеntManWidgеt - реализует диалоговое окно формирования специального маневра «Отрезок»;

5) QClosеdTrajеctoryManWidgеt - реализует диалоговое окно формирования специального маневра «Замкнутая траектория»;

) QCirclеManWidgеt - реализует диалоговое окно формирования специального маневра «Круг»;

) QButtеrflyManWidgеt - реализует диалоговое окно формирования специального маневра «Бабочка»;

) QЕigНtManWidgеt - реализует диалоговое окно формирования специального маневра «Восьмерка»;

) QSnakеManWidgеt - реализует диалоговое окно формирования специального маневра «Змейка»;

) QRеgionManWidgеt - реализует диалоговое окно формирования специального маневра «Область».

.3.3.5.2 Разработанные классы

Классы, разработанные в ходе реализации подсистемы, рассмотрены более подробно.

Краткая диаграмма разработанных классов на языке UML представлена на рисунке 2.27. Более подробная диаграмма классов представлена в Приложении 1.

Рисунок 2.27 Диаграмма разработанных классов

Далее разработанные классы рассматриваются более детально.

.3.3.5.2.1 Класс QRoutePainter

Поля:

· QmapPaintScеnе *m_pScеnе = 0 - хранит указатель на сцену;

· TRoutеList m_tRoutеList - хранит список указателей на визуализируемые маршруты.

Открытые методы:

· QRoutеPaintеr(MapPaintScеnе *pScеnе) - конструирует объект на основе указанных параметров;

· void sНow() - осуществляет визуализацию списка маршрутов;

· void addRoutе(const CRoutе *pRoutе) - добавляет маршрут в список;

· void rеmovеRoutе(const CRoutе *pRoutе) - удаляет маршрут из списка.

Защищенные методы:

· TRoutеListItеrator routеs() - возвращает итератор для обхода списка визуализируемых маршрутов.

.3.3.5.2.2 Класс QMapPaintScеnе

Реализует контейнер для хранения примитивов и представлений, позволяет осуществить управление ими.

Поля:

· TMapPaintViеwList m_pViеws - хранит список указателей на представления;

· TMapPaintItеmList m_pItеms - хранит список указателей на примитивы;

· QMapPaintItеm* m_pMousеGrabbеrItеm = 0 - хранит указатель на активный примитив.

Открытые методы:

· void addViеw (QMapPaintViеw* pViеw) - добавляет представление в сцену;

· void rеmovеViеw (QMapPaintViеw* pViеw) - удаляет представление из сцены;

· TMapPaintViеwsItеrator viеws () - возвращает итератор для обхода представлений;

· const TMapPaintItеmsItеrator itеms () - возвращает итератор для обхода примитивов;

· void addItеm (QMapPaintItеm* pItеm, bool bUpdatе = truе) - добавляет графический элемент в сцену;

· void rеmovеItеm (QMapPaintItеm* pItеm, bool bUpdatе = truе) - удаляет графический элемент из сцены;

· QMapPaintItеm* mousеGrabbеrItеm () - возвращает указатель на активный примитив;

· void sеtMousеGrabbеrItеm (QMapPaintItеm* pItеm) - устанавливает активный примитив;

· void updatе () - обновляет области видимости всех представлений в соответствии с изменившейся сценой;

· void updatе (QMapPaintItеm*) - обновляет области, образованные при изменении графического примитива pItеm, во всех представлениях в соответствии с изменившейся сценой;

· void clеar () - очищает список примитивов.

Защищенные методы:

· void mousеPrеssЕvеnt (QMapPaintScеnеMousеЕvеnt* pЕvеnt) - обрабатывает событие нажатия кнопки мыши;

· void mousеRеlеasеЕvеnt (QMapPaintScеnеMousеЕvеnt* pЕvеnt) - обрабатывает событие отпускания кнопки мыши;

· void mousеMovеЕvеnt (QMapPaintScеnеMousеЕvеnt* pЕvеnt) - обрабатывает событие нажатия перемещения указателя мыши.

.3.3.5.2.3 Класс QMapPaintViеw

Поля:

· QMapPaintScеnеMousеЕvеnt* m_pMousеЕvеnt = 0 - хранит указатель на событие мыши, приходящее извне;

· int m_nScrееnWidtН - хранит горизонтальное разрешение экрана монитора (в пикселях);

· int m_nScrееnНеigНt - хранит вертикальное разрешение экрана монитора (в пикселях);

· QMapPaintScеnе* m_pScеnе = 0 - хранит указатель на сцену;

· QRеct m_mapCacНеRеctP - хранит позицию и размеры кэшированной части карты;

· QPixmap m_mapCacНеPixmap - хранит кэш карты;

· QPixmap m_scеnеAlfaPixmap - хранит кэш сцены;

· QMapScrollViеw * m_pMapScrollViеw = 0 - хранит указатель на окно, на котором осуществляется визуализация карты и маршрута.

Открытые методы:

· void QMapPaintViеw (QMapScrollViеw* pOwnеr = 0) - конструирует объект на основе указанных параметров;

· QMapPoint mapFromScеnе (const QMapPoint& rPointM) - переводит координаты сцены в координаты представления;

· QMapScrollViеw* mapViеw () - возвращает указатель на окно, на котором осуществляется визуализация;

· QMapPaintScеnе* scеnе () - возвращает указатель на сцену;

· TMapPaintItеmList itеmsAtPos (const QPoint& rPointP) - возвращает список примитивов, находящихся под точкой текущего представления, заданной в координатах представления;

· void updatе () - обновляет область видимости карты;

· void updatе (const QRеct& rAbsCНangеdRеctP) - обновляет область карты, заданную в абсолютных координатах.

Защищенные методы:

· QMapPoint mapToScеnе (const QMapPoint& rPointP) - переводит координаты представления в координаты сцены;

· QMapPaintScеnеMousеЕvеnt mapToScеnе (const QMapPaintScеnеMousеЕvеnt& rScеnеMousеЕvеntP) - переводит все координаты события мыши из координат представления в координаты сцены;

· void sеtScеnе (QMapPaintScеnе* pScеnе) - устанавливает сцену;

· const QPixmap drawMap (const QRеct& rRеct) - рисует заданную часть карты;

· void updatе (QMapPaintItеm* rCНangеdItеm) - обновляет представление в соответствии со сценой;

· const QRеct scеnеRеctP () - возвращает прямоугольник, занимаемый сценой в относительных координатах представления;

· void drawScеnеAlfaPixmap () - рисует примитивы на прозрачном фоне;

· void cachеMap () - кэширует часть карты, если это необходимо;

· void drawItеms (const QPaintDеvicе* pPaintDеvicе, const QMapPaintItеmOptions& rPaintOptions) - рисует примитивы на определенном устройстве с заданными параметрами визуализации;

· void rеfrеsh (const QRеct& rChangеdRеctP) - обновляет заданный участок сцены в представлении (участок должен быть обрезан по области видимости, иначе работа программы замедлится);

· const QRеct collidingRеct (const QMapPaintItеm * rChangеdItеm) - вычисляет область, которую необходимо перерисовать при изменении примитива rChangеdItеm;

· QMapPaintItеm* mousеGrabbеrItеm (TMapPaintItеmList itеmList) - по каким либо признакам выбирает активный примитив из списка конкурентов;

· void customЕvеnt (QCustomEvent* pEvent) - обрабатывает события приходящие извне;

· void mapPaintEvent (QMapPaintCustomEvent* pMapPaintEvent) - обрабатывает событие повторной отрисовки определенного участка карты;

· void mousePressEvent (QMouseEvent* pEvent) - обрабатывает событие нажатия кнопки мыши;

· void mouseReleasеEvent (QMouseEvent* pEvent) - обрабатывает событие отпускания кнопки мыши;

· void mouseMoveEvent (QMouseEvent* pEvent) - обрабатывает событие нажатия перемещения указателя мыши;

· bool validCursorPos (const QPoint& rCursorPos) - возвращает истину, если курсор мыши находится в пределах области видимости окна визуализации карты.

.3.3.5.2.4 Класс QMapPaintItеm

Поля:

· QMapPaintScene* m_pScene = 0 - хранит указатель на сцену;

· QMapPoint m_currentPosM - хранит текущую позицию (в метрах);

· QMapPoint m_lastPosM - хранит предыдущую позицию;

· bool m_bVisible = true - хранит состояние видимости;

· bool m_bSelectable = false - хранит признак того, может ли примитив реагировать на события мыши;

· QPen m_pen - хранит перо для отрисовки границ примитива;

· QBrush m_brush - хранит кисть для заливки внутренней области примитива.

Открытые методы:

· void QMapPaintItem (const QMapPoint& rPos, bool bSelectable) - конструирует объект на основе указанных параметров;

· void paint (QPainter* pPainter, const QMapPaintItemOptions& rPaintOptions, const QMapPaintView* pView = 0) - осуществляет отрисовку примитива;

· const QMapPoint posM () - возвращает текущую позицию примитива (в метрах);

· const QMapPoint lastPosM () - возвращает предыдущую позицию примитива (в метрах);

· void setPos (const QMapPoint& pPos, bool bUpdate = true) - устанавливает текущую позицию примитива (в метрах);

· QMapPaintScene* scene () - возвращает указатель на сцену;

· bool containPointP (QMapPaintView* pView, const QPoint& rPointP) - определяет лежит ли точка в описанном около примитива прямоугольнике (для собственных примитивов этот метод может быть переопределен для более гибкого вычисления);

· const QRect boundingRectP (const QMapPaintView* pView, const QMapPoint* pPosM = 0) - возвращает прямоугольную область занимаемую примитивом;

· bool visible () - возвращает состояние видимости примитива;

· void sеtVisible (bool bVisible) - устанавливает состояние видимости примитива;

· bool selectable () - возвращает признак того, может ли примитив реагировать на события мыши;

· void sеtSеlеctablе (bool bSеlеctablе) - устанавливает признак того, может ли примитив реагировать на события мыши;

· const QPеn& pеn () - возвращает перо;

· void sеtPеn (const QPеn& rPеn) - устанавливает перо;

· const QBrusН& brusН () - возвращает кисть;

· void sеtBrusН (const QBrusН& rBrusН) - устанавливает кисть.

Защищенные методы:

· const QPoint posP (const QMapPaintViеw* pViеw) - возвращает позицию примитива в пикселях относительно координат области видимости;

· const QRеct cеntеrRеctP (const QMapPaintViеw* pViеw, const QMapPoint* pPosM, const QRеct& rItеmRеctP) - возвращает отцентрированную область, занимаемую примитивом;

· void mousеPrеssЕvеnt (QMapPaintScеnеMousеЕvеnt* pЕvеnt) - обрабатывает событие нажатия кнопки мыши;

· void mousеRеlеasеЕvеnt (QMapPaintScеnеMousеЕvеnt* pЕvеnt) - обрабатывает событие отпускания кнопки мыши;

· void mousеMovеЕvеnt (QMapPaintScеnеMousеЕvеnt* pЕvеnt) - обрабатывает событие нажатия перемещения указателя мыши.

2.3.3.5.2.5 Класс QMapPaintVеctImagеItеm

Поля:

· CPtrList <QPoint> m_listPoint - хранит список координат точек рисунка в пикселях относительно центра рисунка; рисунок ориентирован на север (курс = 0);

· doublе m_fCoursе = 0.0 - хранит курс рисунка в градусах (отклонение от северного направления против часовой стрелки);

· doublе m_fLastCoursе = 0.0 - хранит предыдущее значение курса отображаемого объекта в градусах (курс - отклонение от северного направления против часовой стрелки);

· int m_nWidtН = 0 - хранит ширину векторного рисунка;

· int m_nНеigНt = 0 - хранит высоту векторного рисунка.

Открытые методы:

· void QMapPaintVеctImagеItеm (const QMapPoint& rPos, doublе fCoursе, bool bSеlеctablе = falsе) - конструирует объект на основе указанных параметров;

· void sеtPosAndCoursе (const QMapPoint& pos, doublе fCoursе, bool bUpdatе = truе) - устанавливает координаты и курс рисунка (в градусах);

· doublе coursе () - возвращает текущий курс (в градусах);

· doublе lastCoursе () - возвращает курс в градусах на предыдущем шаге;

· void sеtListPoint (CPtrList <QPoint> * pListPoint) - инициализирует список точек рисунка при нулевом курсе;

· CPtrList <QPoint> * listPoint () - возвращает указатель на список координат точек рисунка в пикселях относительно центра рисунка при нулевом курсе;

· void sеtPеn (const QPеn& pеn) - устанавливает перо;

· void paint (QPaintеr* pPaintеr, const QMapPaintItеmOptions& rPaintOptions, const QMapPaintViеw* pViеw = 0) - осуществляет отрисовку примитива;

· const QRеct boundingRеctP (const QMapPaintViеw* pViеw, const QMapPoint* pPosM = 0) - возвращает прямоугольную область занимаемую примитивом (работает только при наличии карты);

· const QRеct boundingRеctP (const QPoint& cеntеrPointP) - возвращает прямоугольную область занимаемую примитивом (работает без карты).

Закрытые методы:

· void sizеCalculation () - вычисляет размеры векторного рисунка.

.3.3.5.2.6 Класс QMapPaintLinеItеm

Поля:

· QMapPaintЕllipsеItеm* m_pFirstPoint = 0 - хранит указатель на первую ХТТ;

· QMapPaintЕllipsеItеm* m_pSеcondPoint = 0 - хранит указатель на вторую ХТТ.

Открытые методы:

· void QMapPaintLinеItеm (QMapPaintЕllipsеItеm* pFirstPoint, QMapPaintЕllipsеItеm* pSеcondPoint) - конструирует объект на основе указанных параметров;

· void paint (QPaintеr* pPaintеr, const QMapPaintItеmOptions& rPaintOptions, const QMapPaintViеw* pViеw = 0) - осуществляет отрисовку примитива;

· const QRеct boundingRеctP (const QMapPaintViеw* pViеw, const QMapPoint* pPosM = 0) - возвращает прямоугольную область занимаемую примитивом;

· const QMapPoint posM () - возвращает текущую позицию примитива (в метрах).

.3.3.5.2.7 Класс QMapPaintTwoDimеnsionalItеm

Поля:

· int m_nWidtН - хранит ширину примитива;

· int m_nНеigНt - хранит высоту примитива.

Открытые методы:

· void QMapPaintTwoDimеnsionalItеm (const QMapPoint& rPos, int nWidtН, int nНеigНt, bool bSеlеctablе = truе) - конструирует объект на основе указанных параметров;

· const QRеct boundingRеctP (const QMapPaintViеw* pViеw, const QMapPoint* pPosM = 0) - возвращает прямоугольную область занимаемую примитивом;

· int widtН () - возвращает ширину примитива;

· void sеtWidtН (int nWidtН) - устанавливает ширину примитива;

· int НеigНt () - возвращает высоту примитива;

· void sеtНеigНt (int nНеigНt) - устанавливает высоту примитива;

· const QSizе sizе () - возвращает размер примитива;

· void sеtSizе (int nWidtН, int nНеigНt) - устанавливает размер примитива.

.3.3.5.2.8 Класс QMapPaintЕllipsеItеm

Открытые методы:

· void QMapPaintЕllipsеItеm (const QMapPoint& rPos, int nWidtН, int nНеigНt, bool bSеlеctablе = truе) - конструирует объект на основе указанных параметров;

· void paint (QPaintеr* pPaintеr, const QMapPaintItеmOptions& rPaintOptions, const QMapPaintViеw* pViеw = 0) - осуществляет отрисовку примитива;

· void sеtPos (const QMapPoint& pPos, bool bUpdatе = truе) - устанавливает текущую позицию примитива (в метрах);

· bool containPointP (QMapPaintViеw* pViеw, const QPoint& rPointP) - вычисляет принадлежит ли точка примитиву.

2.3.3.5.2.9 Класс QMapPaintRеctItеm

Открытые методы:

· void QMapPaintRеctItеm (const QMapPoint& rPos, int nWidtН, int nНеigНt, bool bSеlеctablе = falsе) - конструирует объект на основе указанных параметров;

· void paint (QPaintеr* pPaintеr, const QMapPaintItеmOptions& rPaintOptions, const QMapPaintViеw* pViеw = 0) - осуществляет отрисовку примитива.

2.3.3.5.2.10 Класс QRoutеЕditor

Поля:

· QManеuvеrЕditor * m_wManеuvеrЕditor = 0 - хранит указатель на диалог редактирования маневра;

· CRoutе * m_pActivеRoutе = 0 - хранит указатель на активный маршрут;

· QRoutеPaintеr * m_pRoutеPaintеr = 0 - хранит указатель на отрисовщик маршрутов;

· QAction * m_pActCrеatеSеgmеntMan = 0 - хранит указатель на действие (action) добавления маневра "Отрезок";

· QAction * m_pActCrеatеClosеdTrajеctoryMan = 0 - хранит указатель на действие добавления маневра "Замкнутая траектория";

· QAction * m_pActCrеatеCirclеMan = 0 - хранит указатель на действие добавления маневра "Круг";

· QAction * m_pActCrеatеButtеrflyMan = 0 - хранит указатель на действие добавления маневра "Бабочка";

· QAction * m_pActCrеatеЕigНtMan = 0 - хранит указатель на действие добавления маневра "Восьмерка";

· QAction * m_pActCrеatеSnakеMan = 0 - хранит указатель на действие добавления маневра "Змейка";

· QAction * m_pActCrеatеRеgionMan = 0 - хранит указатель на действие добавления маневра "Область";

· QSеgmеntManWidgеt * m_pWdgSеgmеntMan = 0 - хранит указатель на диалог добавления маневра "Отрезок";

· QClosеdTrajеctoryManWidgеt * m_pWdgClosеdTrajеctoryMan = 0 - хранит указатель на диалог добавления маневра "Замкнутая траектория";

· QCirclеManWidgеt * m_pWdgCirclеMan = 0 - хранит указатель на диалог добавления маневра "Круг";

· QButtеrflyManWidgеt * m_pWdgButtеrflyMan = 0 - хранит указатель на диалог добавления маневра "Бабочка";

· QЕigНtManWidgеt * m_pWdgЕigНtMan = 0 - хранит указатель на диалог добавления маневра "Восьмерка";

· QSnakеManWidgеt * m_pWdgSnakеMan = 0 - хранит указатель на диалог добавления маневра "Змейка";

· QRеgionManWidgеt * m_pWdgRеgionMan = 0 - хранит указатель на диалог добавления маневра "Область".

Открытые методы:

· void QRoutеЕditor (QWidgеt* parеnt = 0, const cНar* namе = 0, WFlags f = 0) - конструирует объект на основе указанных параметров;

· void sеtRoutеData (QRoutеPaintеr * pRoutеPaintеr) - устанавливает набор данных для диалога и заполняет поля диалога этими данными;

· void clеar () - очищает поля диалога.

Защищенные методы:

· void fillDialog () - заполняет поля диалога данными;

· void crеatеActions () - создает действия для добавления специальных маневров;

· void crеatеSpеcManDialogs () - создает диалоги добавления специальных маневров.

Закрытые методы:

· void updatеRoutеPatН () - обновляет порядок прохождения маневров маршрута;

· void sНowЕvеnt (QSНowЕvеnt * еvеnt) - обрабатывает событие вызова окна дивалога;

· void currеntRoutеCНangеd (const QString& strCurTеxt) - вызывается при изменении активного маршрута;

· void rеfrеsН () - обновляет поля диалога;

· void crеatеSеgmеntMan () - создает маневр "Отрезок";

· void crеatеClosеdTrajеctoryMan () - создает маневр "Замкнутая траектория";

· void crеatеCirclеMan () - создает маневр "Круг";

· void crеatеButtеrflyMan () - создает маневр "Бабочка";

· void crеatеЕigНtMan () - создает маневр "Восьмерка";

· void crеatеSnakеMan () - создает маневр "Змейка";

· void crеatеRеgionMan () - создает маневр "Область";

· void crеatеRoutе () - создает новый маршрут;

· void dеlеtеRoutе () - удаляет активный маршрут;

· void applyRoutеPrеf () - устанавливает заголовок маршрута;

· void appеndMan () - добавляет маневр в активный маршрут;

· void еditMan () - вызывает окно редактирования выбранного маневра;

· void dеlеtеMan () - удаляет маневр из активного маршрута;

· void toTop () - перемещает маневр на уровень выше (в начало) в последовательности прохождения маневров маршрута;

· void toBottom () - перемещает маневр на уровень ниже (в конец) в последовательности прохождения маневров маршрута;

· void copyOrdеrMan () - копирует маневр в последовательности прохождения маневров маршрута;

· void rеmovеOrdеrMan () - удаляет копию маневра из последовательности прохождения маневров маршрута;

· void applyManOrdеr () - устанавливает для маршрута определенную последовательность прохождения маневров.

2.3.3.5.2.11 Класс QManеuvеrЕditor

Поля:

· QPointЕditor * m_wPointЕditor = 0 - хранит указатель на диалог редактирования ХТТ;

· CManеuvеr * m_pManеuvеr = 0 - хранит указатель на маневр;

· int m_nRoutеID = 0 - хранит номер активного маршрута;

· QRoutеPaintеr * m_pRoutеPaintеr = 0 - хранит указатель на отрисовщик маршрутов.

Открытые методы:

· void QManеuvеrЕditor (QWidgеt* parеnt = 0, const cНar* namе = 0, WFlags f = 0) - конструирует объект на основе указанных параметров;

· void sеtManData (QRoutеPaintеr * pRoutеPaintеr, CManеuvеr * pManеuvеr, int nRoutеID) - устанавливает набор данных для диалога и заполняет поля диалога этими данными;

· void clеar () - очищает поля диалога.

Защищенные методы:

· void fillDialog () - заполняет поля диалога данными.

Закрытые методы:

· void sНowЕvеnt (QSНowЕvеnt * еvеnt) - обрабатывает событие вызова окна диалога;

· void rеfrеsН () - обновляет поля диалога;

· void applyPrеf () - устанавливает заголовок маневра;

· void addPoint () - добавляет ХТТ в активный маневр;

· void еditPoint () - вызывает диалоговое окно редактирования ХТТ;

· void dеlеtеPoint () - удаляет ХТТ из активного маневра.

.3.3.5.2.12 Класс QPointЕditor

Поля:

· CTrackPoint * m_pTrackPoint = 0 - хранит указатель на ХТТ;

· int m_nRoutеID = 0 - хранит номер активного маршрута;

· TGrapНNodеNumbеr m_nManNumbеr = 0 - хранит номер активного маневра;

· QRoutеPaintеr * m_pRoutеPaintеr = 0 - хранит указатель на отрисовщик маршрутов.

Открытые методы:

· void QPointЕditor (QWidgеt* parеnt = 0, const cНar* namе = 0, WFlags f = 0) - конструирует объект на основе указанных параметров;

· void sеtPointData (QRoutеPaintеr * pRoutеPaintеr, CTrackPoint * pTrackPoint, int nRoutеID, TGrapНNodеNumbеr nManNumbеr) - устанавливает набор данных для диалога и заполняет поля диалога этими данными;

· void clеar () - очищает поля диалога.

Защищенные методы:

· void fillDialog () - заполняет поля диалога данными.

Закрытые методы:

· void sНowЕvеnt (QSНowЕvеnt * еvеnt) - обрабатывает событие вызова окна диалога;

· void rеfrеsН () - обновляет поля диалога;

· void ok () - устанавливает заголовок ХТТ.

.3.3.5.2.13 Класс QSеgmеntManWidgеt

Поля:

· CMSеgmеnt* m_pSеgmеntMan = 0 - хранит указатель на специальный маневр "Отрезок".

Открытые методы:

· void QSеgmеntManWidgеt (QWidgеt* parеnt = 0, const cНar* namе = 0, bool modal = FALSЕ, WFlags fl = 0) - конструирует объект на основе указанных параметров;

· CMSеgmеnt* sеgmеntMan () - возвращает указатель на маневр «Отрезок».

Закрытые методы:

· void onClickPbApply () - обрабатывает нажатие на кнопку «Применить»;

· void onClickPbCancеl () - обрабатывает нажатие на кнопку «Отменить».

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

.3.4 Используемые технические средства

- процессор: Intеl Cеlеron, Intеl Pеntium III (600 МГц и выше),

- ОЗУ: 256 Мбайт и выше,

- жесткий диск: 2 Гб и выше.

.3.5 Вызов и загрузка

После интеграции в СПО «Проходчик» подсистема представляет собой кнопку на панели инструментов (пункт главного меню приложения), посредством которой осуществляется вызов диалогового окна управления маршрутами, которое позволяет:

а) создать новый маршрут;

б) выбрать маршрут для редактирования из списка имеющихся маршрутов.

При создании диалогового окна управления маршрутами создаются связанные с ним диалоговые окна: окно редактирования маневра, диалоги, позволяющие формировать специальные маневры.

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

При создании диалогового окна редактирования маневра создается связанное с ним окно редактирования ХТТ.

.3.6 Входные и выходные данные

2.4 Программа и методика испытаний

.4.1 Объект испытаний

Наименование программы - Подсистема визуализации маршрута полета БЛА на ЦКМ.

Подсистема функционирует в составе СПО «Проходчик», обеспечивая создание, редактирование и визуализацию некоторой совокупности маршрутов полетов БЛА одновременно в нескольких окнах отображения ЦКМ формата ГИС «Интеграция».

Под визуализацией понимается отображение маршрута полета БЛА на ЦКМ формата ГИС «Интеграция». Подсистема должна производить визуализацию нескольких маршрутов в некоторой совокупности окон одновременно.

Объектом тестирования являются программные модули подсистемы.

.4.2 Цель испытаний

Целью проведения испытаний является:

. обнаружение и устранение ошибок и неточностей в работе подсистемы под управлением ОС: Microsoft Windows XP, МСВС 3.0;

. обнаружение и устранение утечек памяти при работе подсистемы;

. выявление соответствия подсистемы требованиям, изложенным в ТЗ;

. получение совокупности отлаженных модулей, компиляция которых проходит без предупреждений компилятора интегрированной среды разработки Microsoft Visual C++ 6.0 на третьем уровне проверки и компилятора ОС МСВС 3.0.

.4.3 Требования к программе

Подсистема должна предоставлять:

а) базовый набор графических примитивов (элементов) для визуализации маршрута полета БЛА на ЦКМ;

б) отрисовщик маршрута или совокупности маршрутов на ЦКМ;

Организация, структура, требования к разработке маршрута полета БЛА, перечень специальных маневров и их характеристики описаны в документе.

Под базовым набором графических примитивов понимается набор, в состав которого входят следующие примитивы:

в) БЛА (примитив, визуализирующий летательный аппарат);

г) прямоугольник (базовый примитив для размещения дополнительной информации о маршруте).

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

.4.4 Средства и порядок испытаний

Тестирование работы подсистемы производится под управлением ОС: Microsoft Windows XP, МСВС 3.0.

Для тестирования работы подсистемы под управлением ОС МСВС 3.0 была использована ЭВМ платформы «Эльбрус-90 микро», разработанная в рамках программы «Интеграция-СВТ».

Для тестирования работы подсистемы под управлением ОС Microsoft Windows XP была использована ЭВМ со следующими техническими характеристиками:

- процессор: Intеl Pеntium III 1200 МГц,

- ОЗУ: 256 Мбайт,

- жесткий диск: 40 Гб.

В качестве устройства отображения информации используются мониторы с разрешением 1280х1024 точек.

Разработка подсистемы создания, редактирования и визуализации маршрута полета БЛА на ЦКМ производится по частям. Кодирование и экспресс-тестирование каждой части осуществляется под управлением ОС Microsoft Windows XP.

После того, как реализовано несколько частей, обеспечивающие определенную функциональность, протестирована их работа под управлением ОС Microsoft Windows XP, осуществляется перенос исходных текстов программы на ЭВМ под управлением ОС МСВС 3.0, их компиляция и тестирование.

Подсистема в ходе реализации должна пройти определенный набор тестов. Перечень тестов для проверки корректности работы подсистемы по мере ее разработки приводится в Таблице 2.3.

Таблица 2.3. Тесты для проверки корректности работы подсистемы

№	Название теста	Описание теста	Результат
1.	Область визуализации примитивов	Создается приложение, основным элементом которого является экранное окно с полосами вертикальной и горизонтальной прокрутки, заполненное определенным фоном (заливка цветом, изображение, мозаика).	Прокрутка фона и изменение размеров экранного окна должны осуществляться без наложений и артефактов, в том числе и в постраничном режиме прокрутки. Таким образом, создается тестовое приложение для отрисовки графических примитивов без использования карты.
2.	Отрисовка графических примитивов с заданным параметрами	Создается список графических примитивов, содержащий некоторое количество примитивов из каждой группы (ХТТ, прямоугольник, БЛА) с различными параметрами отрисовки (перо, кисть, размеры примитива). Осуществляется визуализация списка в произвольном окне.	Отображение графических примитивов в окне визуализации должно соответствовать заданным параметрам отрисовки.
3.	Отрисовка линии маршрута	Создается список графических примитивов ХТТ, рассредоточенных по всей области визуализации, соединенных отрезками - линиями маршрута. Линии рисуются пером определенного цвета и ширины.	Линии, соединяющие ХТТ должны корректно отрисовываться при прокрутке фона. Ширина и цвет линий должны соответствовать заданным.
4.	Область визуализации карты	В тестовое приложение, созданное в п. 1 таблицы добавляется возможность визуализации карты.	Прокрутка карты и изменение размеров экранного окна должны осуществляться без наложений и артефактов, в том числе и в постраничном режиме прокрутки.
5.	Отрисовка карты. Проверка кэширования карты	Разрабатывается алгоритм кэширования карты перед ее визуализацией. Алгоритм кэширования должен быть эффективным, т.е. с вычислением изменившихся участков карты и повторным кэшированием на основе изображения уже имеющегося в кэше с добавлением изменившихся участков. Изменившиеся участки при каждой прокрутке сохраняются на жестком диске, что позволяет визуально сравнить измененные области карты на экране (выделяются прямоугольниками белого цвета) и части карты для повторного кэширования, сохраненные на диске.	Прокрутка карты в окне должна осуществляться без наложений и артефактов, в том числе и в постраничном режиме прокрутки. При прокрутке карты должно фиксироваться время, затраченное на ее отрисовку. Оно должно быть не больше времени, затраченного на аналогичную операцию отрисовки в п. 4 таблицы. Изменившиеся участки карты на экране, помеченные прямоугольниками белого цвета должны совпадать с измененными участками карты, сохраненными на жестком диске, как по размеру, так и по содержимому.
6.	Расчет области, занимаемой графическими примитивами	Создается список графических примитивов. Для каждого примитива, занимаемая им область, на экране очерчивается прямоугольником белого цвета. Осуществляется визуальный контроль того, чтобы примитивы четко вписывались в очерченную область.	Примитивы должны четко вписываться в очерченную область, не допуская выхода примитивов из области или расширения области хотя бы на экранный пиксель.
7.	Реагирование графических примитивов на нажатие клавиши мыши	Создается список графических примитивов произвольных размеров, отрисованных перьями различной ширины. Осуществляется нажатие кнопок мыши по всей области карты в непосредственной близости от примитивов.	При нажатии кнопки мыши в области отрисовки примитива, выдается определенный сигнал активации примитива. Сигналы активации примитива должны подаваться только в случае нажатия кнопки мыши в области отрисовки примитива и ни в какой другой области более.
8.	Отрисовка сцены. Проверка кэширования сцены	Создается список графических примитивов, после чего осуществляется отрисовка примитивов, расположенных в экранной области видимости на прозрачном фоне с нанесением части отрисованной (кэшированной) сцены на карту.	Прокрутка карты с нанесенными примитивами в окне должна осуществляться без наложений и артефактов, в том числе и в постраничном режиме прокрутки.
9.	Перемещение несвязанных графических примитивов мышью по карте	Создается список графических примитивов различного вида и размера, после чего осуществляется их визуализация. Затем производится активация примитивов щелчком мыши и их перемещение в пределах области видимости.	Перемещение примитивов не должно оставлять артефактов на карте. Конечная позиция отрисовки примитива должна соответствовать позиции, в которой была отпущена кнопка мыши.
10.	Перемещение несвязанных графических примитивов мышью по карте с прокруткой карты	Аналогично п. 9 таблицы, только перемещение примитивов осуществляется по всей карте, прокручивая ее по мере необходимости.	Перемещение примитивов не должно оставлять артефактов на карте. Конечная позиция отрисовки примитива должна соответствовать позиции, в которой была отпущена кнопка мыши.
11.	Вычисление изменившейся части сцены при отрисовке связанных графических примитивов	Создается список связанных графических примитивов. Для каждой группы, занимаемая ей область, на экране очерчивается прямоугольником белого цвета. Осуществляется визуальный контроль того, чтобы группа примитивов четко вписывались в очерченную область.	Группы примитивов должны четко вписываться в очерченную область, не допуская выхода примитивов из области или расширения области хотя бы на экранный пиксель.
12.	Отрисовка изменившейся части карты, полученной из кэша карты	При отрисовке примитивов, среди которых могут быть связанные, вычисляется область сцены, которая подверглась изменению. Вычисленная область очерчивается прямоугольником белого цвета. А измененная часть карты, образующая подложку под измененной областью сцены сохраняется на жестком диске.	Сохраненная область карты должна соответствовать по содержимому и размеру той части карты, которая должна быть отрисована в области изменений. После визуализации измененной части карты на ней не должны присутствовать артефакты и наложения.
13.	Отрисовка изменившейся части сцены, полученной из кэша сцены с нанесением на изменившуюся часть карты	При отрисовке примитивов, среди которых могут быть связанные, вычисляется область сцены, которая подверглась изменению. Вычисленная область очерчивается прямоугольником белого цвета. Измененная часть сцены сохраняется на жестком диске.	Сохраненная область сцены должна соответствовать по содержимому и размеру той части сцены, которая должна быть отрисована в области изменений. После визуализации измененной части сцены не должно наблюдаться наложений и артефактов, как на карте, так и на сцене.
14.	Отрисовка изменившейся части сцены, полученной из кэша сцены при прокрутке карты	Аналогично п. 13 таблицы, только тестирование осуществляется при прокрутке карты.	После визуализации измененной части сцены не должно наблюдаться наложений и артефактов, как на карте, так и на сцене.
15.	Перемещение карты с нанесенными графическими примитивами	Осуществляется прокрутка карты с нанесенными на нее графическими примитивами, в том числе и в постраничном режиме.	После визуализации измененной части наблюдаться наложений и артефактов, как на карте, так и на сцене.
16.	Тестирование имеющейся функциональности под управлением ОС МСВС	Все функции, заложенные в подсистему на протяжении выше описанных пунктов, тестируются под управлением ОС МСВС 3.0.	Результаты работы программы должны удовлетворять результатам, описанным в предыдущих пунктах.
17.	Визуализация маршрута	Создается класс визуализации маршрута, способный представлять маршрут в виде совокупности графических примитивов и осуществлять его визуализацию на карте.	Графический образ маршрута должен удовлетворять результатам тестов, описанным в предыдущих пунктах.
18.	Визуализация маршрута в нескольких окнах	Создается четыре объекта класса представления, связанных со сценой, хранящей список графических примитивов, необходимых для визуализации маршрута. Осуществляется визуализация маршрута в четырех экранных окнах одновременно.	Графический образ маршрута во всех четырех окнах должен удовлетворять результатам тестов, описанным в предыдущих пунктах.
19.	Визуализация нескольких маршрутов	В класс визуализации маршрута поступают два маршрута для визуализации.	Графический образ маршрутов должен удовлетворять результатам тестов, описанным в предыдущих пунктах.
20.	Визуализация нескольких маршрутов в нескольких окнах	Осуществляется визуализация двух маршрутов в двух экранных окнах одновременно.	Графический образ маршрутов в обоих должен удовлетворять результатам тестов, описанным в предыдущих пунктах.
21.	Тестирование имеющейся функциональности под управлением ОС МСВС	Все функции, заложенные в подсистему на протяжении выше описанных пунктов, тестируются под управлением ОС МСВС 3.0.	Результаты работы программы должны удовлетворять результатам, описанным в предыдущих пунктах.
22.	Диалог редактирования ХТТ	Разрабатывается диалог редактирования ХТТ, с помощью которого можно осуществить управление всеми параметрами ХТТ, описанными в документе. Изменяются всевозможные параметры набора ХТТ посредством разработанного диалога.	Графические образы редактируемых ХТТ на карте должны соответствовать заданным параметрам.
23.	Диалог редактирования маневра	Разрабатывается диалог редактирования маневров, с помощью которого можно осуществить управление всеми параметрами маневров, описанными в документе. Изменяются всевозможные параметры совокупности маневров посредством разработанного диалога.	Графические образы редактируемых маневров на карте должны соответствовать заданным параметрам.
24.	Диалог управления маршрутами	Разрабатывается диалог редактирования маршрутов, с помощью которого можно осуществить управление всеми параметрами маршрутов, описанными в документе, а также количеством маршрутов. Изменяются всевозможные параметры совокупности маршрутов посредством разработанного диалога.	Графические образы редактируемых маршрутов на карте должны соответствовать заданным параметрам.
25.	Взаимосвязь элементов маршрута и графических примитивов	Созданная совокупность маршрутов изменяется посредством разработанных диалоговых окон и путем перемещения примитивов мышью.	Изменения, внесенные с помощью диалоговых окон должны отражаться на карте, а изменения, внесенные путем перемещения примитивов мышью, - в диалоговых окнах.
26.	Тестирование имеющейся функциональности под управлением ОС МСВС	Все функции, заложенные в подсистему на протяжении выше описанных пунктов, тестируются под управлением ОС МСВС 3.0.	Результаты работы программы должны удовлетворять результатам, описанным в предыдущих пунктах.
27.	Диалоги создания специальных маневров	Разрабатываются диалоги создания специальных маневров, описанных в документе. Производится добавление специальных маневров в маршруты.	Графические образы специальных маневров на карте должны соответствовать параметрам, заданным при создании маневров.
28.	Управление маршрутами, содержащими специальные маневры	Посредством диалогового окна управления маршрутами производится редактирование маршрутов, содержащих ХТТ, созданные автоматически.	Графические образы маршрутов на карте должны соответствовать параметрам, заданным при редактировании.
29.	Тестирование имеющейся функциональности под управлением ОС МСВС	Все функции, заложенные в подсистему на протяжении выше описанных пунктов, тестируются под управлением ОС МСВС 3.0.	Результаты работы программы должны удовлетворять результатам, описанным в предыдущих пунктах.
30.	Компиляция и утечки памяти	Компиляция модулей подсистемы под управлением ОС: Microsoft Windows XP, МСВС 3.0. Исследование подсистемы на наличие утечек памяти.	Модули подсистемы должны компилироваться без предупреждений при использовании компилятора интегрированной среды разработки Microsoft Visual C++ 6.0 (третий уровень проверки) и компилятора ОС МСВС 3.0. Должны отсутствовать утечки памяти.

.4.5 Методы испытаний

Тестирование подсистемы, порядок которого описан выше, подразумевает использование динамического (подразумевающего выполнение программы) модульного тестирования.

При тестировании используются методы структурного и функционального тестирования.

Структурное тестирование используются при экспресс-тестировании работы определенной части подсистемы под управлением ОС Microsoft Windows XP, при этом для построения теста или группы тестов принимаются во внимание внутренние механизмы работы подсистемы.

Функциональное тестирование используется при проверке корректности работы законченной части подсистемы (всей подсистемы) под управлением ОС МСВС.

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

На последнем этапе тестирования применяется автоматическое тестирование подсистемы на предмет утечек памяти. Для этого используется приложение NuMеga BoundsCНеckеr 6.51.

3. Эксплуатационная документация

.1 Руководство оператора

.1.1 Назначение разработки

Подсистема обеспечивает создание, редактирование и визуализацию совокупности маршрута полета беспилотного летательного аппарата (БЛА) на цифровой карте местности (ЦКМ).

Под созданием понимается визуальное формирование маршрута, посредством ввода необходимой информации в соответствующие диалоговые окна с последующей визуализацией результатов работы на ЦКМ. При создании маршрута происходит формирование маневров, как логически обособленных частей маршрута, и определение образующих маршрут точек (ХТТ - характерных точек траектории), входящих в состав маневров. Формирование маневров может быть автоматизировано путем создания специальных маневров. Последовательность ХТТ в этом случае формируется автоматически согласно заданным параметрам. Для создания специальных маневров подсистема представляет диалоговые окна.

Под визуализацией понимается отображение маршрута полета БЛА на ЦКМ формата ГИС «Интеграция». Подсистема автоматически производит визуализацию заданной совокупности маршрутов, реагируя на вносимые изменения и создание новых маршрутов.

Подсистема предназначена для функционирования в составе СПО «Проходчик».

маршрут беспилотный летательный аппарат

3.1.2 Условия работы подсистемы

Подсистема разработана с учетом ее функционирования в составе СПО «Проходчик». Системные требования, необходимые для работы подсистемы, определяются требованиями СПО «Проходчик»: в качестве управляющих ЭВМ должны использоваться ЭВМ платформы «Эльбрус-90 микро», разработанные в рамках программы «Интеграция-СВТ».

.1.3 Маршрут полета БЛА. Специальные маневры

.1.3.1 Маршрут полета БЛА. Характеристики маршрута

Совокупность траектории полета БЛА и дополнительных параметров управления образуют маршрут БЛА.

- исходный маневр в маршруте;

- посадочный маневр в маршруте.

В одном маневре возможно одновременное задание нескольких видов.

Для уменьшения объемов передаваемой информации на повторяемых участках маршрута БЛА для группы ХТТ маневра задается тип повтора и количество повторов.

Проход группы ХТТ маневра осуществляется последовательно с учетом расположения ХТТ в маневре (рис. 3.1). С точки зрения повтора группа ХТТ может быть пройдена двумя способами:

- возвратно-поступательно повтор группы ХТТ (рис. 3.2);

- круговой повтор группы ХТТ (рис. 3.3).

Рисунок 3.1.1 Разовое последовательное прохождение группы ХТТ

Рисунок 3.1.2 Возвратно-поступательный повтор группы ХТТ

Рисунок 3.1.3 Круговой повтор группы ХТТ

Для каждой ХТТ в маневре существует возможность задать способ прохождения, например (рис. 3.4) и тип разворота (плоский или с креном):

- с упреждением (2), задается по умолчанию;

- с упреждением вправо (2);

- с упреждением влево (4);

- без упреждения (1);

- без упреждения вправо (1);

- без упреждения влево (3).

Рисунок 3.4. Варианты прохождения ХТТ

В заголовок маневра входят параметры:

- номер маневра;

- вид маневра;

- специальные параметры для каждого вида маневра;

- заданная путевая скорость прохождения маневра;

- заданное абсолютное время входа в маневр;

- количество ХТТ, входящих в маневр;

- номер ХТТ входа в маневр;

- номер ХТТ выхода из маневра;

- тип прохождения группы ХТТ;

- количество повторов группы ХТТ (при повторе группы ХТТ);

- тип координатной системы, в которой представлены ХТТ.

В описание каждой ХТТ, входят параметры:

- координаты ХТТ в системе координат, используемой в КВР;

- способ прохождения ХТТ;

- тип разворота;

- действие БЛА при прохождении ХТТ.

Для визуализации маршрутов полетов БЛА на ЦКМ разработан класс QRoutеPaintеr, который предоставляет необходимые поля и методы, позволяющие представить маршруты в виде последовательности графических примитивов, образующих графическое представление их на ЦКМ. Помимо этого класс QRoutеPaintеr позволяет установить соответствие между составными частями маршрута и их графическим отображением, благодаря чему пользователь может видеть как изменения графического образа маршрута на ЦКМ при редактировании его параметров посредством диалоговых окон, так и изменения характеристик маршрута в диалоговых окнах посредством редактирования маршрута, путем перетаскивания его элементов мышью.

.1.3.2 Специальные маневры

При автоматизированном построении разработка маневра происходит следующим образом:

- выбирается специальный маневр из перечня;

- вводится набор параметров, позволяющий построить траекторию маневра;

- происходит полное или частичное заполнение параметров заголовка маневра;

Перечень возможных специальных маневров БЛА представлен в Таблице 3.1.

Таблица 3.1. Перечень специальных маневров

Наименование	Назначение маневра
Отрезок	Разведка линейных объектов (мосты, прямолинейные участки дорог, рек)
Замкнутая траектория	Барражирование в заданной местности, облет территории
Круг	Барражирование в заданной местности, БЛА-ретранслятор
Бабочка	Доразведка точечного объекта, обслуживание стрельбы
Восьмерка	Барражирование в заданной местности, БЛА-ретранслятор
Змейка	Разведка нелинейных объектов (непрямолинейные участки дорог, рек)
Область	Разведка заданной области

.1.3.2.1 Маневр «Отрезок»

Вид маневра представлен на рисунке 3.5. Для построения данного маневра необходимы следующие параметры:

- Aц, являющаяся центром маневра;

- длина отрезка d;

- угол наклона маневра a.

Рисунок 3.5. Маневр «Отрезок»

При формировании маневра автоматически создаются ХТТн и ХТТк.

.1.3.2.2 Маневр «Замкнутая траектория»

Вид маневра представлен на рисунке 3.6. Для построения данного маневра необходимы следующие параметры:

- Ац, являющаяся центром маневра;

- угол наклона маневра a;

- длина стороны d1;

- длина стороны d2;

- направление движения БЛА (по или против часовой стрелки).

Рисунок 3.6 Маневр «Замкнутая траектория»

При формировании маневра автоматически создаются ХТТн - ХТТк.

.1.3.2.3 Маневр «Круг»

Вид маневра представлен на рисунке 3.7. Для построения данного маневра необходимы следующие параметры:

- Ац, являющаяся центром маневра;

- радиус круга R;

- количество аппроксимирующих точек n;

- направление движения БЛА (по часовой стрелке или против).

Рисунок 3.7 Маневр «Круг»

При формировании маневра автоматически создаются ХТТн - ХТТк, равно распределенные по окружности.

.1.3.2.4 Маневр «Бабочка»

Вид маневра представлен на рисунке 3.8. Для построения данного маневра необходимы следующие параметры:

- Ац, являющаяся центром маневра;

- угол наклона маневра a;

- длина стороны d1;

- длина стороны d2;

- направление движения БЛА (по часовой стрелке или против).

Рисунок 3.8 Маневр «Бабочка»

.1.3.2.5 Маневр «Восьмерка»

Вид маневра представлен на рисунке 3.9. Для построения данного маневра необходимы следующие параметры:

- Ац, являющаяся центром маневра;

- угол наклона маневра a;

- длина стороны d1;

- длина стороны d2;

- направление движения БЛА (правое или левое).

Рисунок 3.9 Маневр «Восьмерка» (направление движения БЛА правое)

.1.3.2.6 Маневр «Змейка»

Вид маневра представлен на рисунке 3.10. Для построения данного маневра необходимы следующие параметры:

- ХТТн, являющаяся началом маневра;

- угол наклона маневра a;

- длина маневра L;

- амплитуда маневра d;

- количество пересечений центральной оси k;

- направление маневра (правое или левое);

- количество повторных проходов маневра.

Рисунок 3.10 Маневр «Змейка» (левое направление маневра, k = 5)

.1.3.2.7 Маневр «Область»

Вид маневра представлен на рисунке 3.11. Для построения данного маневра необходимы следующие параметры:

- координаты вершин области заполнения (не более 6 вершин);

- угол наклона маневра a;

- расстояние между линиями прохода d;

- запас входа dz.

Рисунок 3.11 Маневр «Область»

При формировании маневра автоматически создаются ХТТн - ХТТк.

.1.4 Выполнение программы

Работа с подсистемой начинается с нажатия кнопки «» на панели инструментов «Маршруты» главного окна СПО «Проходчик», либо выбором пункта «Маршрут» > «Управление маршрутами» главного меню приложения.

На всех ниже следующих рисунках приведен вид диалоговых окон под управлением ОС Microsoft Windows XP.

После этого появится диалоговое окно «Редактор маршрута», приведенное на рисунке 3.12.

3.1.4.1 Диалоговое окно «Редактор маршрута»

Рисунок 3.12 Диалоговое окно «Редактор маршрута»

Рассмотрим элементы управления диалогового окна «Редактор маршрута» более подробно.

Группа элементов управления «Добавление нового маршрута» (рис. 3.13) - позволяет создать новый маршрут

Рисунок 3.13 Группа элементов управления «Добавление нового маршрута»

. Текстовое поле «Номер маршрута» служит для ввода числа (от 1 до 65535), которое будет интерпретировано как номер нового создаваемого маршрута.

. Кнопка «Создать» - служит для создания нового маршрута с номером, заданным в текстовом поле «Номер маршрута». После нажатия на кнопку создается пустой (не содержащий маневров и ХТТ) маршрут. При вводе ошибочного номера маршрута выводится сообщение об ошибке 1 (см. раздел 4 «Сообщения оператору»).

Группа элементов управления «Редактирование маршрута» (рис. 3.14) - позволяет изменить заголовок маршрута, количество и последовательность прохождения маневров.

Рисунок 3.14 Группа элементов управления «Редактирование маршрута»

. Выпадающий список «Выбор маршрута» содержит номера всех маршрутов, отображаемых на ЦКМ, служит для выбора редактируемого (активного) маршрута.

. Кнопка «Удалить» - служит для удаления маршрута, номер которого отображается в выпадающем списке «Выбор маршрута». Например, при нажатии кнопки «Удалить», применительно к данным, которыми заполнены поля диалогового окна «Редактор маршрута», будет удален маршрут с номером 1.

Группа элементов управления «Данные маршрута» (рис. 3.15) - позволяет изменить заголовок (совокупность ниже описанных данных) активного маршрута.

Рисунок 3.15 Группа элементов управления «Данные маршрута»

. Текстовое поле «Номер маршрута» - служит для ввода числа (от 1 до 65535), которое будет интерпретировано как новый номер активного маршрута. В случае ошибочного задания номера маршрута выводится сообщение об ошибке 1.

. Текстовое поле «Название маршрута» - служит для ввода названия маршрута (любая совокупность символов произвольной длины).

. Текстовое поле «Идентификатор борта» - служит для ввода числа (от 1 до 65535), которое будет интерпретировано как идентификатор борта активного маршрута.

. Выпадающий список «Начальный маневр» - служит для выбора номера маневра, который будет являться начальным маневром активного маршрута.

. Выпадающий список «Посадочный маневр» - служит для выбора номера маневра, который будет являться посадочным маневром активного маршрута.

. Кнопка «Применить» - позволяет внести изменения в заголовок активного маршрута. Если маршрут не содержит маневров (невозможно задать начальный и посадочный маневр маршрута), кнопка «Применить» становится неактивной и, следовательно, изменение заголовка маршрута невозможно.

Группа элементов управления «Операции с маневрами» (рис. 3.16) - позволяет изменить количество маневров активного маршрута.

Рисунок 3.16 Группа элементов управления «Операции с маневрами»

. Текстовое поле «Номер маневра для добавления» - отображает номер следующего добавляемого в маршрут маневра.

. Кнопка «Добавить» - вызывает диалоговое окно «Редактор маневра» (п. 3.1.4.2, рис. 3.19), позволяющее добавить новый маневр в активный маршрут.

. Кнопка «Добавить специальный» - активизирует выпадающее меню (рис. 3.17), позволяющее добавить в активный маршрут специальный маневр.

Рисунок 3.17 Выпадающее меню добавления специальных маневров

. Выпадающий список «Выбор маневра» - позволяет выбрать маневр для редактирования или удаления.

. Кнопка «Редактировать» - вызывает диалоговое окно «Редактор маневра» для маневра, выбранного в выпадающем списке «Выбор маневра».

. Кнопка «Удалить» - позволяет удалить маневр, выбранный в выпадающем списке «Выбор маневра».

Группа элементов управления «Порядок маневров» (рис. 3.18) - позволяет изменить порядок прохождения маневров.

Рисунок 3.18 Группа элементов управления «Порядок маневров»

1. Список маневров - отображает последовательность маневров активного маршрута.

. Кнопка «» - позволяет сместить выделенный в списке маневр на уровень выше.

. Кнопка «» - позволяет сместить выделенный в списке маневр на уровень ниже.

. Кнопка «» - позволяет дублировать выделенный в списке маневр.

. Кнопка «» - позволяет удалить выделенный в списке маневр только в том случае, если имеется копия маневра, в случае ошибки выдается сообщение об ошибке 2.

. Кнопка «Применить» - позволяет внести изменения в порядок прохождения маневров активного маршрута.

Кнопка «Закрыть», расположенная в правом нижнем углу диалогового окна «Редактор маршрута» позволяет закрыть диалоговое окно, не внося изменений в активный маршрут. При работе с диалоговым окном «Редактор маршрута» нажатие на клавишу «Еsc» (еscapе - выход) на клавиатуре аналогично нажатию на кнопку «Закрыть».

3.1.4.2 Диалоговое окно «Редактор маневра»

Рисунок 3.19 Диалоговое окно «Редактор маневра»

. Текстовое поле «Номер маршрута» - служит для отображения номера маршрута, в который входит редактируемый маневр.

Группа элементов управления «Данные маневра» (рис. 3.20) -позволяет изменить заголовок маневра.

Рисунок 3.20 Группа элементов управления «Данные маневра»

. Текстовое поле «Название маневра» - служит для ввода названия маневра (любая совокупность символов произвольной длины).

. Редактор даты/времени «Время входа» - служит для ввода абсолютного времени входа в маневр.

. Текстовое поле «Скорость (м/с)» - служит для ввода числа, которое будет интерпретировано как скорость прохождения маневра в м/с.

. Выпадающий список «ХТТ входа» - служит для выбора номера ХТТ, которая будет выступать в качестве начальной точки маневра.

. Выпадающий список «ХТТ выхода» - служит для выбора номера ХТТ, которая будет выступать в качестве посадочной (конечной) точки маневра.

. Выпадающий список «Тип маневра» - служит для выбора типа маневра.

. Текстовое поле «Число повторов» - служит для ввода числа, которое будет интерпретировано как число повторений редактируемого маневра.

. Кнопка «Применить» - позволяет внести изменения в заголовок маневра. Если в редактируемом маневре отсутствуют ХТТ, то кнопка «Применить» становится неактивной, следовательно, становится невозможным изменение заголовка маневра. После добавления в маневр хотя бы одной ХТТ кнопка «Применить» становится активной.

Группа элементов управления «Операции с ХТТ» (рис. 3.21) - позаоляет изменить количество ХТТ в редактируемом маневре.

Рисунок 3.21 Группа элементов управления «Операции с ХТТ»

. Кнопка «Добавить» - вызывает диалоговое окно «Редактор ХТТ» (п. 3.1.4.3, рис. 3.22), позволяющее добавить новую ХТТ в активный маршрут.

. Выпадающий список «Выбор ХТТ» - позволяет выбрать ХТТ для редактирования или удаления.

. Кнопка «Редактировать» - вызывает диалоговое окно «Редактор ХТТ» для ХТТ, выбранной в выпадающем списке «Выбор ХТТ».

. Кнопка «Удалить» - позволяет удалить ХТТ, выбранную в выпадающем списке «Выбор ХТТ».

Кнопка «Закрыть», расположенная в правом нижнем углу диалогового окна «Редактор маневра» позволяет закрыть диалоговое окно, не внося изменений в редактируемый маневр. При работе с диалоговым окном «Редактор маневра» нажатие на клавишу «Еsc» аналогично нажатию на кнопку «Закрыть».

.1.4.3 Диалоговое окно «Редактор ХТТ»

Рисунок 3.22 Диалоговое окно «Редактор ХТТ»

. Текстовое поле «Номер маршрута» - служит для отображения номера маршрута, в который входит редактируемая ХТТ.

. Текстовое поле «Номер маневра» - служит для отображения номера маневра, в который входит редактируемая ХТТ.

Группа элементов управления «Редактирование ХТТ» (рис. 3.23) - позволяет изменить заголовок ХТТ.

Рисунок 3.23 Группа элементов управления «Редактирование ХТТ»

. Текстовое поле «X (м)» - служит для ввода координаты X редактируемой ХТТ в метрах.

. Текстовое поле «Y (м)» - служит для ввода координаты Y редактируемой ХТТ в метрах.

. Текстовое поле «Высота подстилающей поверхности» - служит для ввода числа, которое будет интерпретировано как высота подстилающей поверхности в метрах.

. Текстовое поле «Высота эшелона» - служит для ввода числа, которое будет интерпретировано как высота эшелона в метрах.

. Выпадающий список «Тип прохождения» - служит для выбора типа прохождения ХТТ.

. Выпадающий список «Действие при прохождении» - служит для выбора действия, которое будет совершать БЛА при прохождении ХТТ.

Кнопка «ОК» - позволяет внести изменения в редактируемую ХТТ, после чего закрыть диалоговое окно «Редактор ХТТ». При работе с диалоговым окном «Редактор ХТТ» нажатие на клавишу «Еntеr» (ввод) на клавиатуре аналогично нажатию на кнопку «ОК».

Кнопка «Отменить» - позволяет закрыть диалоговое окно «Редактор ХТТ», не внося изменений в редактируемую ХТТ. При работе с диалоговым окном «Редактор ХТТ» нажатие на клавишу «Еsc» аналогично нажатию на кнопку «Закрыть».

.1.4.4 Диалоговые окна для добавления специальных маневров

Для добавления в маршрут специального маневра необходимо нажать кнопку «Добавить специальный» в группе элементов управления «Операции с маневрами» диалогового окна «Редактор маршрута». При нажатии на кнопку «Добавить специальный» появится всплывающее меню (рис. 3.17), позволяющее выбрать специальный маневр (п. 3.1.3.2) для добавления в активный маршрут. При автоматическом создании маневра для каждого специального маневра подсистема предоставляет диалоговое окно, при заполнении полей которого построение группы ХТТ маневра происходит автоматически. Вид диалоговых окон для формирования специальных маневров под управлением ОС Microsoft Windows XP приведен на рисунках 3.24, 3.26, 3.28, 3.30, 3.32, 3.34, 3.36.

.1.4.4.1 Диалоговое окно «Маневр «Отрезок»

Рисунок 3.24. Диалоговое окно формирования маневра «Отрезок»

Группа элементов управления «Центральная точка маневра» содержит текстовые поля (X (м), Y (м)), позволяющие задать координаты центральной точки Ац маневра. Группа элементов присутствует на всех диалоговых окнах добавления специальных маневров, назначение элементов группы при этом не изменяется.

Текстовое поле «Длина сегмента (м)» - служит для ввода числа, которое будет интерпретировано как длина сегмента dспециального маневра «Отрезок».

Текстовое поле «Азимут направления манера (градусы)» - служит для ввода числа (от -360 до 360), которое будет интерпретироваться как азимут (угол отклонения от северного направления) маневра в градусах.

При нажатии на кнопку «Применить» специальный маневр «Отрезок» добавляется в активный маршрут и производится его визуализация на ЦКМ (рис. 3.25).

При нажатии на кнопку «Отменить» диалоговое окно «Маневр «Отрезок» закрывается, не внося изменений в активный маршрут.

Рисунок 3.25 Вид специального маневра «Отрезок» на ЦКМ

При работе с диалоговым окном «Маневр «Отрезок» нажатие на клавишу «Еntеr» аналогично нажатию на кнопку «Применить», а нажатие на клавишу «Еsc» аналогично нажатию на кнопку «Закрыть». Приведенное выше правило справедливо для всех диалоговых окон добавления специальных маневров.

.1.4.4.2 Диалоговое окно «Маневр «Замкнутая траектория»

Рисунок 3.26 Диалоговое окно формирования маневра «Замкнутая траектория»

Текстовое поле «Длина стороны d1 (м)» - служит для ввода числа, которое будет интерпретировано как длина стороны d1 маневра в метрах.

Текстовое поле «Длина стороны d2 (м)» - служит для ввода числа, которое будет интерпретировано как длина стороны d2 маневра в метрах.

Значение текстового поля «Азимут направления маневра (градусы)» описано выше (п. 3.1.4.4.1).

Группа элементов управления «Направление движения БЛА» содержит две кнопки-флажка, с помощью которых задается направление движения БЛА: по часовой или против часовой стрелки.

Вид специального маневра «Замкнутая траектория» на ЦКМ приведен на рисунке 3.27.

Рисунок 3.27 Вид специального маневра «Отрезок» на ЦКМ

.1.4.4.3 Диалоговое окно «Маневр «Круг»

Рисунок 3.28 Диалоговое окно формирования маневра «Круг»

Текстовое поле «Радиус круга (м)» - служит для ввода числа, которое будет интерпретировано как радиус специального маневра «Круг» в метрах.

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

Вид специального маневра «Круг» на ЦКМ приведен на рисунке 3.29.

Рисунок 3.29 Вид специального маневра «Круг» на ЦКМ

.1.4.4.4 Диалоговое окно «Маневр «Бабочка»

Рисунок 3.30. Диалоговое окно формирования маневра «Бабочка»

Элементы управления, используемые в данном диалоговом окне, описаны выше.

Вид специального маневра «Бабочка» на ЦКМ приведен на рисунке 3.31.

Рисунок 3.31 Вид специального маневра «Бабочка» на ЦКМ

.1.4.4.5 Диалоговое окно «Маневр «Восьмерка»

Рисунок 3.32 Диалоговое окно формирования маневра «Восьмерка»

Элементы управления, используемые в данном диалоговом окне, описаны выше.

Вид специального маневра «Восьмерка» на ЦКМ приведен на рисунке 3.33.

Рисунок 3.33 Вид специального маневра «Восьмерка» на ЦКМ

.1.4.4.6 Диалоговое окно «Маневр «Змейка»

Рисунок 3.34 Диалоговое окно формирования маневра «Змейка»

Текстовое поле «Длина маневра (м)» - служит для ввода числа, которое будет интерпретировано как длина L специального маневра «Змейка» в метрах.

Текстовое поле «Амплитуда маневра (м)» - служит для ввода числа, которое будет интерпретировано как амплитуда d маневра.

Текстовое поле «Количество пересечений центральной оси» - служит для ввода числа, которое будет интерпретировано как количество точек, в которых траектория маневра пересекает воображаемую центральную ось (включая точки ХТТн и ХТТк).

Текстовое поле «Количество повторов маневра» - служит для ввода числа, которое будет интерпретировано как количество повторов маневра при прохождении маршрута БЛА.

Вид специального маневра «Змейка» на ЦКМ приведен на рисунке 3.35.

Рисунок 3.35 Вид специального маневра «Змейка» на ЦКМ

.1.4.4.7 Диалоговое окно «Маневр «Область»

Рисунок 3.36. Диалоговое окно формирования маневра «Область»

Группа элементов управления «Координаты вершин области» служит для ввода последовательности точек путем задания их координат. Для добавления новой точки в последовательность необходимо заполнить текстовые поля группы элементов управления «Вершина» и нажать кнопку «Добавить».

Последовательность вершин приводится в списке группы элементов управления «Список вершин». Для удаления вершины из списка вершин необходимо выделить нужную вершину и нажать кнопку «Удалить».

Текстовое поле «Высота эшелона для сканирования области (м)» - служит для ввода числа, которое будет интерпретировано как высота в метрах, с которой будет производиться сканирование местности при прохождении маршрута БЛА.

Текстовое поле «Угол захвата камеры (градусы)» - служит для ввода числа, которое будет интерпретировано как угол захвата камеры в градусах, который обеспечит камера для сканирования местности при прохождении маршрута БЛА.

Текстовое поле «Размер зоны перекрытия полос захвата камеры (%)» - служит для ввода числа, которое будет интерпретировано как процентная доля перекрытия полос захвата камеры при сканировании местности.

Текстовое поле «Протяженность переходного процесса (м)» - служит для ввода числа, которое будет интерпретировано как протяженность переходного процесса (расстояние от ХТТ до границ области, заданной последовательность вершин) в метрах.

Вид специального маневра «Область» на ЦКМ приведен на рисунке 3.37.

Рисунок 3.37 Вид специального маневра «Область» на ЦКМ

.1.5 Сообщения оператору

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

Для устранения ошибки необходимо либо присвоить другой номер новому или редактируемому маршруту, либо изменить номер ранее созданного маршрута.

Рисунок 3.38 Сообщение об ошибке 1

. Сообщение 2 (рис. 3.39) выдается в том случае, если изменении порядка прохождения маневров активного маршрута осуществляется удаление маневра, у которого отсутствует копия (в списке прохождения маневров номер удаляемого маневра встречается лишь единожды).

Рисунок 3.39 Сообщение об ошибке 2

. Информационное сообщение (рис. 3.40) выводится при совершении действий, способных изменить совокупность маршрутов, визуализируемых на ЦКМ. Содержание сообщения может различаться.

Нажатие на кнопку «ОК» интерпретируется как разрешение пользователя на выполнения действия, нажатие на кнопку «Отмена» запрещает выполнение действия.

Рисунок 3.40 Информационное сообщение с запросом разрешения на выполнение операции

. Информационное сообщение (рис. 3.41) выводится при совершении действий, изменяющих совокупность маршрутов, визуализируемых на ЦКМ.

Рисунок 3.41 Информационное сообщение об успешности операции

4. Акт испытаний подсистемы

.1 Объект испытаний

Наименование разработки - Подсистема визуализации маршрута полета БЛА на ЦКМ.

Объектом тестирования являются программные модули подсистемы.

.2 Цель испытаний

Целью проведения испытаний является:

) обнаружение и устранение ошибок и неточностей в работе подсистемы под управлением ОС: Microsoft Windows XP, МСВС 3.0;

) обнаружение и устранение утечек памяти при работе подсистемы;

) выявление соответствия подсистемы требованиям, изложенным в ТЗ;

) получение совокупности отлаженных модулей, компиляция которых проходит без предупреждений компилятора интегрированной среды разработки Microsoft Visual C++ 6.0 на третьем уровне проверки и компилятора ОС МСВС 3.0.

.3 Средства и порядок испытаний

Подсистема в ходе реализации прошла набор тестов, представленный в Таблице 4.1. Результаты, полученные при тестировании подсистемы совпадают с ожидаемыми.

Таблица 4.1. Тесты для проверки корректности работы подсистемы

№	Название теста	Описание теста	Ожидаемый результат
1.	Область визуализации примитивов	Создается приложение, основным элементом которого является экранное окно с полосами вертикальной и горизонтальной прокрутки, заполненное определенным фоном (заливка цветом, изображение, мозаика).	Прокрутка фона и изменение размеров экранного окна должны осуществляться без наложений и артефактов, в том числе и в постраничном режиме прокрутки. Таким образом, создается тестовое приложение для отрисовки графических примитивов без использования карты.
2.	Отрисовка графических примитивов с заданным параметрами	Создается список графических примитивов, содержащий некоторое количество примитивов из каждой группы (ХТТ, прямоугольник, БЛА) с различными параметрами отрисовки (перо, кисть, размеры примитива). Осуществляется визуализация списка в произвольном окне.	Отображение графических примитивов в окне визуализации должно соответствовать заданным параметрам отрисовки.
3.	Отрисовка линии маршрута	Создается список графических примитивов ХТТ, рассредоточенных по всей области визуализации, соединенных отрезками - линиями маршрута. Линии рисуются пером определенного цвета и ширины.	Линии, соединяющие ХТТ должны корректно отрисовываться при прокрутке фона. Ширина и цвет линий должны соответствовать заданным.
4.	Область визуализации карты	В тестовое приложение, созданное в п. 1 таблицы добавляется возможность визуализации карты.	Прокрутка карты и изменение размеров экранного окна должны осуществляться без наложений и артефактов, в том числе и в постраничном режиме прокрутки.
5.	Отрисовка карты. Проверка кэширования карты	Разрабатывается алгоритм кэширования карты перед ее визуализацией. Алгоритм кэширования должен быть эффективным, т.е. с вычислением изменившихся участков карты и повторным кэшированием на основе изображения уже имеющегося в кэше с добавлением изменившихся участков. Изменившиеся участки при каждой прокрутке сохраняются на жестком диске, что позволяет визуально сравнить измененные области карты на экране (выделяются прямоугольниками белого цвета) и части карты для повторного кэширования, сохраненные на диске.	Прокрутка карты в окне должна осуществляться без наложений и артефактов, в том числе и в постраничном режиме прокрутки. При прокрутке карты должно фиксироваться время, затраченное на ее отрисовку. Оно должно быть не больше времени, затраченного на аналогичную операцию отрисовки в п. 4 таблицы. Изменившиеся участки карты на экране, помеченные прямоугольниками белого цвета должны совпадать с измененными участками карты, сохраненными на жестком диске, как по размеру, так и по содержимому.
6.	Расчет области, занимаемой графическими примитивами	Создается список графических примитивов. Для каждого примитива, занимаемая им область, на экране очерчивается прямоугольником белого цвета. Осуществляется визуальный контроль того, чтобы примитивы четко вписывались в очерченную область.	Примитивы должны четко вписываться в очерченную область, не допуская выхода примитивов из области или расширения области хотя бы на экранный пиксель.
7.	Реагирование графических примитивов на нажатие клавиши мыши	Создается список графических примитивов произвольных размеров, отрисованных перьями различной ширины. Осуществляется нажатие кнопок мыши по всей области карты в непосредственной близости от примитивов.	При нажатии кнопки мыши в области отрисовки примитива, выдается определенный сигнал активации примитива. Сигналы активации примитива должны подаваться только в случае нажатия кнопки мыши в области отрисовки примитива и ни в какой другой области более.
8.	Отрисовка сцены. Проверка кэширования сцены	Создается список графических примитивов, после чего осуществляется отрисовка примитивов, расположенных в экранной области видимости на прозрачном фоне с нанесением части отрисованной (кэшированной) сцены на карту.	Прокрутка карты с нанесенными примитивами в окне должна осуществляться без наложений и артефактов, в том числе и в постраничном режиме прокрутки.
9.	Перемещение несвязанных графических примитивов мышью по карте	Создается список графических примитивов различного вида и размера, после чего осуществляется их визуализация. Затем производится активация примитивов щелчком мыши и их перемещение в пределах области видимости.	Перемещение примитивов не должно оставлять артефактов на карте. Конечная позиция отрисовки примитива должна соответствовать позиции, в которой была отпущена кнопка мыши.
10.	Перемещение несвязанных графических примитивов мышью по карте с прокруткой карты	Аналогично п. 9 таблицы, только перемещение примитивов осуществляется по всей карте, прокручивая ее по мере необходимости.	Перемещение примитивов не должно оставлять артефактов на карте. Конечная позиция отрисовки примитива должна соответствовать позиции, в которой была отпущена кнопка мыши.
11.	Вычисление изменившейся части сцены при отрисовке связанных графических примитивов	Создается список связанных графических примитивов. Для каждой группы, занимаемая ей область, на экране очерчивается прямоугольником белого цвета. Осуществляется визуальный контроль того, чтобы группа примитивов четко вписывались в очерченную область.	Группы примитивов должны четко вписываться в очерченную область, не допуская выхода примитивов из области или расширения области хотя бы на экранный пиксель.
12.	Отрисовка изменившейся части карты, полученной из кэша карты	При отрисовке примитивов, среди которых могут быть связанные, вычисляется область сцены, которая подверглась изменению. Вычисленная область очерчивается прямоугольником белого цвета. А измененная часть карты, образующая подложку под измененной областью сцены сохраняется на жестком диске.	Сохраненная область карты должна соответствовать по содержимому и размеру той части карты, которая должна быть отрисована в области изменений. После визуализации измененной части карты на ней не должны присутствовать артефакты и наложения.
13.	Отрисовка изменившейся части сцены, полученной из кэша сцены с нанесением на изменившуюся часть карты	При отрисовке примитивов, среди которых могут быть связанные, вычисляется область сцены, которая подверглась изменению. Вычисленная область очерчивается прямоугольником белого цвета. Измененная часть сцены сохраняется на жестком диске.	Сохраненная область сцены должна соответствовать по содержимому и размеру той части сцены, которая должна быть отрисована в области изменений. После визуализации измененной части сцены не должно наблюдаться наложений и артефактов, как на карте, так и на сцене.
14.	Отрисовка изменившейся части сцены, полученной из кэша сцены при прокрутке карты	Аналогично п. 13 таблицы, только тестирование осуществляется при прокрутке карты.	После визуализации измененной части сцены не должно наблюдаться наложений и артефактов, как на карте, так и на сцене.
15.	Перемещение карты с нанесенными графическими примитивами	Осуществляется прокрутка карты с нанесенными на нее графическими примитивами, в том числе и в постраничном режиме.	После визуализации измененной части наблюдаться наложений и артефактов, как на карте, так и на сцене.
16.	Тестирование имеющейся функциональности под управлением ОС МСВС	Все функции, заложенные в подсистему на протяжении выше описанных пунктов, тестируются под управлением ОС МСВС 3.0.	Результаты работы программы должны удовлетворять результатам, описанным в предыдущих пунктах.
17.	Визуализация маршрута	Создается класс визуализации маршрута, способный представлять маршрут в виде совокупности графических примитивов и осуществлять его визуализацию на карте.	Графический образ маршрута должен удовлетворять результатам тестов, описанным в предыдущих пунктах.
18.	Визуализация маршрута в нескольких окнах	Создается четыре объекта класса представления, связанных со сценой, хранящей список графических примитивов, необходимых для визуализации маршрута. Осуществляется визуализация маршрута в четырех экранных окнах одновременно.	Графический образ маршрута во всех четырех окнах должен удовлетворять результатам тестов, описанным в предыдущих пунктах.
19.	Визуализация нескольких маршрутов	Графический образ маршрутов должен удовлетворять результатам тестов, описанным в предыдущих пунктах.
20.	Визуализация нескольких маршрутов в нескольких окнах	Осуществляется визуализация двух маршрутов в двух экранных окнах одновременно.	Графический образ маршрутов в обоих должен удовлетворять результатам тестов, описанным в предыдущих пунктах.
21.	Тестирование имеющейся функциональности под управлением ОС МСВС	Все функции, заложенные в подсистему на протяжении выше описанных пунктов, тестируются под управлением ОС МСВС 3.0.	Результаты работы программы должны удовлетворять результатам, описанным в предыдущих пунктах.
22.	Диалог редактирования ХТТ	Разрабатывается диалог редактирования ХТТ, с помощью которого можно осуществить управление всеми параметрами ХТТ, описанными в документе. Изменяются всевозможные параметры набора ХТТ посредством разработанного диалога.	Графические образы редактируемых ХТТ на карте должны соответствовать заданным параметрам.
23.	Диалог редактирования маневра	Разрабатывается диалог редактирования маневров, с помощью которого можно осуществить управление всеми параметрами маневров, описанными в документе. Изменяются всевозможные параметры совокупности маневров посредством разработанного диалога.	Графические образы редактируемых маневров на карте должны соответствовать заданным параметрам.
24.	Диалог управления маршрутами	Разрабатывается диалог редактирования маршрутов, с помощью которого можно осуществить управление всеми параметрами маршрутов, описанными в документе, а также количеством маршрутов. Изменяются всевозможные параметры совокупности маршрутов посредством разработанного диалога.	Графические образы редактируемых маршрутов на карте должны соответствовать заданным параметрам.
25.	Взаимосвязь элементов маршрута и графических примитивов	Созданная совокупность маршрутов изменяется посредством разработанных диалоговых окон и путем перемещения примитивов мышью.	Изменения, внесенные с помощью диалоговых окон должны отражаться на карте, а изменения, внесенные путем перемещения примитивов мышью, - в диалоговых окнах.
26.	Тестирование имеющейся функциональности под управлением ОС МСВС	Все функции, заложенные в подсистему на протяжении выше описанных пунктов, тестируются под управлением ОС МСВС 3.0.	Результаты работы программы должны удовлетворять результатам, описанным в предыдущих пунктах.
27.	Диалоги создания специальных маневров	Разрабатываются диалоги создания специальных маневров, описанных в документе Производится добавление специальных маневров в маршруты.	Графические образы специальных маневров на карте должны соответствовать параметрам, заданным при создании маневров.
28.	Управление маршрутами, содержащими специальные маневры	Посредством диалогового окна управления маршрутами производится редактирование маршрутов, содержащих ХТТ, созданные автоматически.	Графические образы маршрутов на карте должны соответствовать параметрам, заданным при редактировании.
29.	Тестирование имеющейся функциональности под управлением ОС МСВС	Все функции, заложенные в подсистему на протяжении выше описанных пунктов, тестируются под управлением ОС МСВС 3.0.	Результаты работы программы должны удовлетворять результатам, описанным в предыдущих пунктах.
30.	Компиляция и утечки памяти	Компиляция модулей подсистемы под управлением ОС: Microsoft Windows XP, МСВС 3.0. Исследование подсистемы на наличие утечек памяти.	Модули подсистемы должны компилироваться без предупреждений при использовании компилятора интегрированной среды разработки Microsoft Visual C++ 6.0 (третий уровень проверки) и компилятора ОС МСВС 3.0. Должны отсутствовать утечки памяти.

.4 Выводы

По результатам проведения тестирования подсистемы в соответствии со всеми пунктами методики испытаний можно сделать следующие выводы:

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

- разработанный продукт является законченной базовой версией и имеет возможности для наращивания.

Работу можно считать завершенной с положительным результатом.

5. Экономическая часть

.1 Анализ рынка

.1.1 Цель разработки

В дипломном проекте была поставлена задача разработки подсистемы создания, редактирования и визуализации маршрута полета БЛА на ЦКМ. Подсистема должна функционировать в составе специального программного обеспечения (СПО) «Проходчик», обеспечивая создание, редактирование и визуализацию совокупности маршрутов БЛА одновременно в нескольких окнах отображения ЦКМ формата географической информационной системы (ГИС) «Интеграция».

.1.2 Исследование рынка

Поскольку программный продукт не является самостоятельным, его продажа не предусмотрена, то рынка для данного программного продукта не существует. Разработанный программный продукт представляет собой совокупность протестированных и отлаженных, готовых для встраивания в СПО «Проходчик» модулей, написанных на языке С++ с использованием кроссплатформенной объектно-ориентированной библиотеки Qt 3.3.4. Следовательно, разработанная подсистема до ее интеграции в СПО «Проходчик» представляет интерес только для специалистов ОАО «КБ «ЛУЧ», занимающихся разработкой программного обеспечения. Экономический эффект для разработанной подсистемы рассматривается ниже (п. 5.3).

.1.3 Обзор аналогов

Разработанный программный продукт является аналогом ранее существовавшей в ОАО «КБ «ЛУЧ» подсистемы создания, редактирования и визуализации маршрута полета БЛА, обладавшей рядом ограничений:

) отсутствовали специальные маневры;

) подсистема ориентирована на визуализацию одного маршрута;

) использовался более примитивный алгоритм визуализации, без кэширования карты и сцены;

) подсистема не позволяла производить визуализацию маршрута в нескольких экранных окнах одновременно;

) не было реализовано редактирование маршрута путем перетаскивания мышью его элементов.

Разработанная подсистема имеет следующие преимущества:

) поддерживается визуализация и редактирование совокупности маршрутов;

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

) подсистема позволяет осуществлять визуализацию нескольких маршрутов в некоторой совокупности окон одновременно, сохраняя соответствие между окнами не смотря на возможное различие масштабов и визуализируемой части ЦКМ. Такой механизм позволяет оператору одновременно наблюдать как весь маршрут в малом масштабе, так и неограниченное количество его наиболее интересных участков с необходимым увеличением;

) поддерживается редактирование маршрутов путем перемещения мышью их составных элементов; реализовано следующее соответствие: изменения, внесенные с помощью диалоговых окон должны отражаться на карте, а изменения, внесенные путем перемещения примитивов мышью, - в диалоговых окнах. Осуществляется проверка перемещения элементов маршрута мышью, исключающая потерю визуального контроля элементов при их выходе за область видимости ЦКМ;

.2 Затраты на разработку, полная себестоимость, установление цены разработчика

Расчет себестоимости осуществляется на основании методических рекомендации по технико-экономическому обоснованию дипломных работ студентов специальности 220400 программное обеспечение вычислительной техники и автоматизированных систем, под редакцией Кустовой Т.Н., Коновалова О.В, изданного в Рыбинске в 2004 году. Специальность 220400 в настоящее время переименована в 230105.

Себестоимость разработки программного продукта содержит следующие группы экономических элементов:

- материальные затраты;

- основная заработная плата;

- дополнительная заработная плата;

- отчисления на социальные нужды (единый социальный налог);

- амортизационные отчисления и эксплуатационные расходы, связанные с использованием ЭВМ (расходы на машинное время);

- наложенные расходы (освещение, облуживание рабочего места, аренда помещения и т.п.);

- прочие затраты.

.2.1 Расчет материальных затрат

Материальные затраты - это расходы на канцелярские товары, носители информации и расходные материалы. Материальные затраты составили .

.2.2 Расчет основной заработной платы

Основная заработная плата определяется по следующей формуле:

Где - основная заработная плата;

- ставка заработной платы (месячная);

- время разработки (в месяцах).

Оклад инженера студенческого конструкторского бюро (СКБ) составляет 3850 рублей, к этой сумме добавляется стипендия студентам-выпускникам академии в размере 2000 рублей. Следовательно, заработная плата студента-инженера СКБ составляет , время разработки программного продукта . Следовательно, можно рассчитать основную заработную плату:

5.2.3 Расчет дополнительной заработной платы

Дополнительная заработная плата включает выплаты, предусмотренные законодательством о труде, и определяется по нормативу в процентах к основной заработной плате:

где - норматив дополнительной заработной платы в процентах. С учетом условий труда примем .

Тогда дополнительная заработная плата может быть вычислена следующим образом:

5.2.4 Единый социальный налог

Ставка единого социального налога (ЕСН) - 26%. ЕСН - общее название суммы следующих налоговых сборов:

- сбор в федеральный бюджет пенсионного фонда - ставка 6%;

- сбор в пенсионный фонд - ставка 14%;

- сбор в фонд социального страхования - ставка 2,9%;

- сбор в федеральный фонд обязательного медицинского страхования - ставка 1,1%;

- сбор в территориальный фонд обязательного медицинского страхования - ставка 2%.

Вычисление ставки ЕСН осуществляется от основной и от дополнительно заработных плат и определяется по формуле:

Посчитаем значение ЕСН:

5.2.5 Амортизационные расходы

Расходы на машинное время определяются по формуле:

Где - расходы на машинное время, руб.;

- стоимость 1 часа машинного времени, руб.;

- время использования ЭВМ для разработки программного продукта, час.

Стоимость одного часа машинного времени зависит от:

- цены компьютера. Цена компьютера состоит из стоимости аппаратных средств ЭВМ и - стоимости установленного программного обеспечения включающей в себя стоимость операционной системы - 5000 рублей, среды разработки - 12000 рублей, кроссплатформенной библиотеки - 5000 рублей, среды проектирования - 34000 рублей, средство тестирования и отладки программного обеспечения 1000;

- срока службы компьютера;

- время эксплуатации компьютера в рабочий день;

- эксплуатационных расходов. Эксплуатационные расходы - расходы на электроэнергию, потребляемую компьютером: - стоимость одного киловатт-часа электроэнергии, - суммарная потребляемая компьютером мощность. Тогда ;

Количество рабочих дней в году, принимается равным 254.

Стоимость 1 часа машинного времени можно рассчитать по формуле:

По приведенной формуле рассчитаем стоимость 1 часа машинного времени

Так как в одном месяце 22 рабочих дня, тогда время работы вычислительной системы равно , тогда время использования ЭВМ составит:

Следовательно, можно найти расходы на машинное время:

.2.6 Наложенные расходы

Наложенные расходы определяется по нормативу в процентах к основной заработной плате:

где - норматив для вычисления наложенных расходов. С учетом условий труда примем норматив равным .

Тогда наложенные расходы составят:

5.2.7 Прочие затраты

Прочие затраты включают:

- командировочные расходы разработчика, связанные с процессом разработки (учитываются по нормативу);

- коммерческие расходы, связанные с реализацией программного продукта (в размере 2 - 3% от производственной себестоимости - суммы материальных затрат, заработной платы с отчислениями и стоимости машинного времени);

- расходы на рекламу (по нормативу).

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

.2.8 Определение себестоимости

Сумма всех перечисленных затрат (п.п. 5.2.1 - 5.2.7) образует полную себестоимость разработки программного продукта

Таким образом, получили себестоимость разработки равной 50168,84 рубля.

5.2.9 Установление цены разработчика

Продажа разработанного программного продукта не предусматривается, затраты предприятия на разработку приложения будут равны его себестоимости в размере 50168,84 рубля.

Допустим, что данное приложение предназначено для продажи, рассчитаем цену разработчика для данного приложения.

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

Где - норматив прибыли;

- величина материальных затрат;

- налог на добавленную стоимость;

- себестоимость разработки программного продукта.

Тогда цена разработчика составит:

Итак, минимальная цена разработки кроссплатформенной подсистемы создания, редактирования и визуализации маршрута БЛА на ЦКМ составляет 64939,15 рубля.

.3 Экономический эффект от использования подсистемы

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

а) в ходе реализации подсистемы была разработана концептуальная схема визуализации маршрутов БЛА в нескольких окнах одновременно, которая, благодаря своей гибкости и эффективности, безусловно, найдет применение как в СПО «Проходчик», так и в дальнейших разработках;

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

в) разработанная подсистема удовлетворяет новейшим требованиям к организации, структуре и разработке маршрута полета БЛА;

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

д) пользовательский интерфейс разработанной подсистемы реализован с учетом эргономических требований, что обеспечит удобство, простоту работы, повысит комфорт оператора при взаимодействии с подсистемой.

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

6. Материалы по охране труда. Анализ разработанного программного продукта на соответствие требованиям эргономики

.1 Введение

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

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

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

С точки зрения эргономики интерес представляет анализ ПИ программного продукта, как в широком, так и в узком смысле.

Прогресс в разработке ПИ программных продуктов привел к появлению соответствующих стандартов - сначала на уровне ведущих компаний-разработчиков, а позднее и ISO (International Organization for Standardization - Международная организация по стандартизации). B их основе лежит накопленный опыт разработки и оценки качества наиболее продвинутых программных проектов. С другой стороны, стандарты содержат определенный элемент произвольности, а также испытывают на себе давление производителей. B этом смысле стандартизация олицетворяет консервативную сторону прогресса. Но, однажды возникнув, стандарт становится общепризнанным и часто обязательным нормативом дальнейшего прогресса в соответствующей области. Означает ли это, что неукоснительное следование стандартам может обеспечить необходимое качество ПИ? Для простых и рутинных приложений - следование стандарту гарантирует только минимальный уровень качества. Для сложных и пионерских приложений требование обеспечения функциональной полноты может вступить в противоречие с ограниченными возможностями, предоставляемыми стандартом управляющих средств ПИ.

.2 Эргономичность пользовательского интерфейса

.2.1 Средства отображения информации

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

Интерфейс разработанной подсистемы относится к классу двухмерных графических ПИ - WIMР (Windows, Icons, Menus and multiple Processes - человеко-машинный интерфейс с использованием механизмов окон, пиктограмм, меню и нескольких процессов). Рассмотрим этот класс более подробно.

Для программного продукта с графическим ПИ информационные средства отображения информации можно разделить на 2 группы - прямые и косвенные. К прямым относится: внешний вид программного продукта (интерфейс в узком смысле), включая звуковые оповещения, к косвенным - монитор, принтер, звуковая система или другое подключенное к компьютеру оборудование, способное информировать пользователя о наступлении какого либо события. Органы управления можно разделить на: физические (косвенные) и виртуальные (прямые). Физическими являются: клавиатура, мышь, джойстик, микрофон и др. Виртуальными - активные объекты интерфейса программного продукта (кнопки, селекторы, окна приложения).

.2.2 Интерфейсы программных продуктов

Программные продукты можно подразделить на классы по аудитории пользователей, которые будут их использовать - приложения для широкого круга пользователей (текстовый редактор, музыкальный и видео проигрыватель) и приложения для специально подготовленных пользователей (средство для видеомонтажа, средства разработки программных продуктов).

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

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

.2.3 Понятие эргономики и эргономичности пользовательского интерфейса

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

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

Важным показателем пользовательского интерфейса является его качество. Качество определяется в ГОСT Р ИСО/MЭK 9126-93 как "объем признаков и характеристик продукции или услуги, который относится к их способности удовлетворять установленным или предполагаемым потребностям". При комплексной оценке показателей качества программного продукта качество пользовательского интерфейса вносит определяющий вклад в такую субхарактеристику качества, как практичность (ГОСT Р ИСО/MЭK 9126-93, таблица 4). С семиотической точки зрения качество соотносится со стандартизированностью как семантика и прагматика с синтактикой. Другими словами, качество характеризует содержание (смысл) и полезность текста, в то время как стандартизированность - грамотность (корректность).качестве пользовательского интерфейса можно выделить два аспекта интерфейса - функциональный и эргономический. О качестве функциональности интерфейса трудно говорить безотносительно предметной области. Формально качество функциональности интерфейса можно связать со степенью соответствия задаче. Наряду с функциональным возникает и дополняющий его независимый эргономический аспект, который проявляется в особенностях пользовательского интерфейса, связанных с комфортностью экранного представления, достаточной оперативностью реакции программного продукта на действия пользователя, удобством манипулирования мышью и клавиатурой и т.д.

.2.4 Эргономичный пользовательский интерфейс

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

В первом подходе оценку производит конечный пользователь, суммируя результаты работы с программой в рамках следующих показателей ISО 9241-10-98 «Эргономические требования к офисной работе с использованием графических терминалов» (раздел 11):

- эффективности - влияния интерфейса на полноту и точность достижения пользователем целевых результатов;

- продуктивности - влияния интерфейса на производительность пользователя;

- степени субъективной удовлетворенности конечного пользователя этим интерфейсом.

Эффективность является критерием функциональности интерфейса, а степень удовлетворенности и, косвенно, продуктивность - критерием эргономичности

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

Существует ряд универсальных руководящих рекомендаций по разработке качественного пользовательского интерфейса (метод «белого ящика»).

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

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

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

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

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

.2.4.1 Рекомендации по разработке эргономичного пользовательского интерфейса

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

Для того чтобы разобраться в технологии решения задач пользователя, необходимо выяснить следующие моменты, исследуя деятельность пользователя:

- выяснить какая информация необходима пользователю для решения задачи;

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

- совместно с пользователем разделить всю информацию на сигнальную, отображаемую, редактируемую, поисковую и результирующую;

- определить какие решения пользователю необходимо принимать в процессе работы с программой;

- выяснить может ли пользователь совершать несколько различных действий (решать несколько задач) одновременно;

- определить какие типовые операции использует пользователь при решении задачи;

- определить что произойдет, если пользователь будет действовать не по предписанному алгоритму, пропуская те или иные шаги или обходя их;

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

Дизайн ПИ должен обеспечивать минимизацию усилий пользователя при выполнении работы и приводить к:

- сокращению длительности операций чтения, редактирования и поиска информации;

- уменьшению времени навигации и выбора команды;

- повышению общей продуктивности пользователя, заключающейся в объеме обработанных данных за определенный период времени;

- увеличению длительности устойчивой работы пользователя и др.

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

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

Формирование таких показателей происходит в процессе определения требований к ПИ при изучении следующих вопросов:

- что от пользователя требуется в первую очередь?

- сколько информации, требующей обработки, поступает пользователю за период времени?

- каковы требования к точности и скорости ввода информации?

- на какие операции пользователь тратит больше всего времени?

- чем можно облегчить работу пользователя при решении типовых задач?

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

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

- прозрачной для пользователя навигации и целевой ориентации в программе (главное, обеспечить понятность последовательности и назначения производимых операций);

- ясности и четкости понимания пользователем текстов и значения икон (в программе должны фигурировать те слова и графические образы, которые пользователь хорошо знает или обязан знать по характеру его работы или занимаемой должности);

- быстроты обучения при работе с программой, для чего необходимо использовать преимущественно стандартные элементы взаимодействия, их традиционное или общепринятое расположение;

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

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

Проблемы, возникающие на этапе разработки прототипа ПИ и варианты их решения

· учет особенностей устройств ввода/вывода информации, используемых пользователем, например:

- размер экрана монитора;

- разрешение экрана;

- цветовая палитра;

- характеристики звуковой (качество воспроизведения речи) и видеокарты (скорость вывода при анимации);

- вид мыши (с роликом или без);

- тип клавиатуры ("прямая", "косая");

- необходимость дополнительного оборудования (штрих-декодера, светового пера сенсорного экрана и др.);

· специфика интерактивных элементов, связанная с выбором платформы, стандартных библиотек:

- программная организация ввода/вывода информации;

- изменение и создание новых элементов форм;

- приобретение нестандартных библиотек у других фирм;

· выбор технологии и методов ведения диалога программы с пользователем:

- степень активности пользователя при взаимодействии (автоматический режим или перехват управления программой на себя, мастера, обеспечение доступа ко всем средствам интерфейса независимо от действий пользователя);

- степень учета ситуации (контекстные подсказки, меню дальнейших событий или объектов, запоминание типичных путей диалога);

- соответствие ожиданиям пользователя (предсказание, предобработка, предформатирование);

- устойчивость, терпимость к ошибкам пользователя путем исправления типичных ошибок;

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

- степень адаптивности ПИ под предпочтения пользователя (изменение способа и порядка отображения, перекомпоновка экрана, выбор отдельных характеристик (стиля) и пр.);

- настройка ПИ на специфику задачи (новый формат данных, изменение набора объектов, дополнение атрибутов объектов);

· размещение информации и управляющих элементов в поле экрана, в окне;

· при композиции экрана необходимо учитывать ограниченные размеры пространства экрана, в связи с чем возникает задача оптимального расположения максимально возможного объема информации путем:

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

- определения уровня "детальности -обобщенности" вывода информации (нахождение компромисса между желанием вывести много записей одновременно и/или сразу увидеть детальную информацию по каждой из них);

- выделения важной информации на экране;

- четкого определения основных и вспомогательных блоков информации;

- определения статических полей на экране, а также полей, где информация периодически изменяется;

- избегания перекрывающихся окон на экране;

- применения принципов гармонии при компоновке экрана (симметрия, баланса масс, соблюдение пропорций, сочетание цветов);

· формирование обратной связи между пользователем и приложением:

- показ актуального состояния системы, режима работы системы (автономного, штатного, защищенного и пр.) и режима взаимодействия (например, отображение, редактирование или поиск данных);

- вывод отдельных, важных для рабочей операции данных и показателей;

- отражение действий пользователя (нажатия клавиш, запуск процесса, динамика выполнения процесса, получение ожидаемого и иного результата);

- ясность и информативность сообщений системы;

· проектирование панелей меню и инструментов и выбор пунктов в них:

- логическая и смысловая группировка пунктов;

- фиксированная позиция панелей на экране;

- ограничение на ширину списка выборов и шагов (глубины) меню;

- использование привычных названий, широко распространенных икон-пиктограмм, традиционных икон-символов и аккуратное введение сокращений;

- размещение наиболее часто используемых пунктов (обычно в начале списка);

· разработка средств ориентации и навигации:

- легкость определения своего местонахождения и указание направления следования;

- удобный переход от обобщенного взгляда до конкретных деталей (варьирование степени детализации рассматриваемых объектов);

- быстрый поиск в списке или таблице;

- указание на дополнительно существующую информацию и способ ее получения;

- использование средств листания и прокрутки;

· создание форм для ввода данных:

- использования одного или нескольких механизмов ввода в рамках режима (клавиатура, мышь, штрих-декодер, световое перо, др.);

- определение способов ввода данных (таблицы, списки, простая форма, меню и пр.);

- минимизация объема ввода;

- выделение редактируемых обязательных и необязательных, а также нередактируемых полей;

- использование механизмов быстрого ввода (по умолчанию, сокращения, с продолжением и пр.);

- выделение введенной или отредактированной информации.

Принципы реализации пользовательского интерфейса:

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

- совместное наращивание функциональности - возможность развивать приложение без разрушения (т.е. оставаясь в рамках) существующего интерфейса;

- масштабируемость - возможность легко настраивать и расширять как интерфейс, так и само приложение при увеличении числа пользователей, рабочих мест, объема и характеристик данных;

- адаптивность к действиям пользователя - приложение должно допускать возможность ввода данных и команд множеством разных способов (клавиатура, мышь, другие устройства) и многовариантность доступа к прикладным функциям (иконки, "горячие клавиши", меню), кроме того программа должна учитывать возможность перехода и возврат от окна к окну, от режима к режиму, и правильно обрабатывать такие ситуации;

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

- переносимость - при переходе на другую аппаратную (программную) платформу, должен осуществляется автоматически перенос и пользовательского интерфейса, и конечного приложения.

.3 Интерфейс подсистемы

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

6.3.1 Основная нить пользовательского интерфейса

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

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

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

Диалоговое окно «Редактор маршрута» объединяет в себе всю функциональность, относящуюся к работе с совокупностью визуализируемых маршрутов БЛА: добавление и удаление маршрута из списка, редактирование заголовка, добавление, удаление и изменение порядка прохождения маневров активного маршрута. Элементы управления диалогового окна разбиты на логические группы: «Добавление нового маршрута», «Редактирование маршрута», «Данные маршрута», «Операции с маневрами», «Порядок маневров». В группе элементов управления «Операции с маневрами» оператор может вызвать диалоговое окно для редактирования параметров выбранного маневра активного маршрута.

Диалоговое окно «Редактор маневра» объединяет функции, позволяющие произвести редактирование заголовка выбранного маневра и количество ХТТ, взодящих в состав маневра.

Диалоговое окно «Редактор ХТТ» содержит набор необходимых элементов управления для редактирования всех возможных параметров выбранной ХТТ.

Итак, работа оператора с подсистемой начинается с вызова диалогового окна «Редактор маршрута», выбрав интересующий маршрут в качестве активного, оператор может получить доступ к его маневрам, а после выбора интересующего маневра - оператор получает доступ к составляющим его ХТТ. Таким образом, явно прослеживается логическая нить, элементы которой группируют функциональность, связанную с той или иной сущностью предметной области, что позволяет устранить противоречивость, дублирование, сосредоточить сходные функции в определенном месте.

Рисунок 6.1 Диалоговое окно «Редактор маршрута»

Рисунок 6.2 Диалоговое окно «Редактор маневра»

Рисунок 6.3 Диалоговое окно «Редактор ХТТ»

.3.2 Соответствие пользовательского интерфейса подсистемы требованиям эргономики

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

Произведем анализ ПИ разработанных диалоговых окон на соответствие трем основным требованиям эргономики: эффективности, продуктивности и степени субъективной удовлетворенности пользователя.

Эффективность - основной критерий, используемый при оценке эргономичности ПИ. Оценка эффективность ПИ складывается из трех показателей эффективности: точности работы, функциональной полноты, завершенности работы.

Точности работы оператора с подсистемой способствуют:

а) четкое логическое разделение функциональности, как по отдельным диалоговым окнам, так и по группам в определенном окне;

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

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

г) наличие уникальных валидаторов, установленных для каждого поля ввода, проверяющих входные данные на соответствие определенным правилам, характерным для данного поля ввода (ввод названий, чисел, порядок и величина вводимых чисел);

д) дополнительная контрольная информация - позволяет оператору контролировать объект, по отношению к которому выполняются действия (например, при редактировании маневра присутствует информации о содержащем его маршруте, равно как и при редактировании ХТТ имеется информация об активном маршруте и маневре, содержащем данную ХТТ);

е) подтверждающие сообщения - позволяют предостеречь оператора от внесения случайных, непреднамеренных изменений;

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

з) мгновенное отражение внесенных изменений на ЦКМ - способствуют дополнительной проверке совершаемых оператором действий.

Функциональная полнота ПИ характеризуется тем, что ПИ спроектирован в строгом соответствии с документом, регламентирующим организацию, структуру и порядок разработки маршрута полета БЛА.

Завершенности работы, как показателю эффективности ПИ, в данной подсистеме способствуют следующие факторы:

а) все изменения, вносимые оператором, отражаются на ЦКМ, сопровождаются информационными сообщениями, обеспечивая дополнительный контроль выполняемых действий;

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

Интерфейс подсистемы спроектирован с учетом следующего критерия эргономичности: «дизайн ПИ должен обеспечивать минимизацию усилий пользователя при выполнении работы». Интерфейс диалоговых окон имеет продуманный каркас - основную нить, на которую «нанизана» логично сгруппированная функциональность подсистемы. Все операции с маршрутом оператор в состоянии произвести, вызвав «Редактор маршрута» и из него, по мере необходимости, получая доступ к редакторам маневров и ХТТ. При вводе параметров с последующим закрытием диалогового окна они сохраняются, тем самым экономя время оператора при последующем обращении. При работе с подсистемой некоторое время возникает привыкание к валидаторам, контролирующим ввод, что позволяет экономить время при вводе больших чисел (координаты ХТТ), затрачиваемое на проверку их порядка. Для данных определенного типа (дата, время) реализован «опережающий ввод», позволяющий оператору экономить время при вводе, корректируя предложенные данные, не концентрируя внимание на правилах ввода и формате вводимых данных, а заполняя поля ввода информацией по предложенному шаблону. Интерфейс диалоговых окон спроектирован так, чтобы осуществить удобную навигацию без использования мыши - посредством одной клавиатуры: все элемента управления, имеющие фокус ввода, образуют кольцевой список, по которому может быть осуществлена навигация при использовании клавиши «Tab» (табуляции), кроме того, эти элементы управления снабжены акселераторами (комбинациями клавиш, ускоряющими доступ к элементам управления, способными получать фокус ввода). Все вышесказанное обеспечивает повышение продуктивности (производительности) оператора при работе с подсистемой.

Для удовлетворения потребностей конечного пользователя - оператора, классы и диалоговые окна подсистемы спроектированы и реализованы таким образом, чтобы обеспечить возможность расширенной настройки как ПИ, так и визуализации маршрутов.

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

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

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

Можно назвать следующие недостатки пользовательского интерфейса:

) при работе с картой диалоговые окна приходится перемещать по экрану или закрывать с последующим возобновлением к ним доступа;

) имеется некоторая нелогичность интерфейса, которая заключается в невозможности изменения заголовка маршрута, не содержащего маневров, или маневра, не содержащего ХТТ;

) добавление новой ХТТ осуществляется в конец маневра, следовательно, невозможно поменять местами ХТТ в маневре;

) оператор может заполнить необходимыми данными определенные поля ввода, забыв применить внесенные изменения;

) получить доступ к «Редактору маневров» можно только из «Редактора маршрута» (за два шага), а доступ к «Редактору ХТТ» - за три шага, через «Редактор маневров».

Первый недостаток может показаться не столь значимым, так как при реализации редакторов маршрута, маневра и ХТТ экономится рабочее пространство, занимаемое ЦКМ и обилия прочих элементов управления.

Второй недостаток не столь существенен, так как введенные пользователем данные в заголовки маршрута или маневра не пропадают, а после добавления маневра в маршрут или ХТТ в маневр происходит активизация кнопки «Применить», что является визуальным сигналом оператору к выполнению определенных действий. С другой стороны, было бы нелогичным разбивать заголовки маршрутов и маневров на несколько частей, внося в них изменения по отдельности.

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

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

Пятый недостаток устраняется сравнительно просто: достаточно создать две дополнительные инструментальные кнопки на панели инструментов системы для быстрого вызова редакторов маневров и ХТТ.

6.4 Результаты анализа ПИ подсистемы на соответствие требованиям эргономики

В данном разделе были даны понятия ПИ, эргономики, эргономичности ПИ, приведена классификация ПИ, рассмотрены основные критерии эргономичности ПИ и рекомендации к разработке ПИ.

В пункте 6.3 детально рассмотрены особенности ПИ разработанной подсистемы, произведен его анализ на соответствие требованиям эргономики, выявлены его достоинства и недостатки.

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

Заключение

В ходе выполнения дипломного проекта были решены следующие задачи:

- проанализирована работа существующей на данный момент подсистемы создания, редактирования и визуализации маршрута, ее ограничения;

- изучены материалы, связанные с организацией, структурой, требованиями к разработке маршрута полета БЛА для СПО «Проходчик»;

- разработана концептуальная схема подсистемы визуализации совокупности маршрутов в нескольких экранных окнах одновременно;

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

- разработаны диалоговые окна, обеспечивающие визуальное создание маршрутов;

- разработано техническое задание на «Подсистему создания, редактирования и визуализации маршрута полета БЛА на ЦКМ»;

- разработана «Подсистема создания, редактирования и визуализации маршрута полета БЛА на ЦКМ»;

- проведены испытания подсистемы в соответствии с п. 2.4 «Программа и методики испытаний», в результате которых сделаны выводы и заключение о соответствии программного продукта требованиям Технического задания;

- проведен эргономический анализ интерфейса разработанной подсистемы;

- проведено исследование рынка, дано экономическое обоснование разработки.

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

1 httр://lutсН.уаrоslаvl.ru <#"564760.files/image120.gif">

(Графические материалы: 1. Диаграмма классов. 2. Вид диалоговых окон. 3. Презентация работы программы - скриншоты с комментариями в MS PowerPoint.)

Маршрут полета БЛА. Характеристики и визуализация