Автоматизированная система управления воздушным движением

МИНИСТЕРСТВО ОБРАЗОВАНИЯ  И НАУКИ УКРАИНЫ

НАЦИОНАЛЬНЫЙ АВИАЦИОННЫЙ  УНИВЕРСИТЕТ

Факультет компьютерных наук

Кафедра инженерии программного обеспечения

 

 

 

 

 

 

 

 

 

 

 

 

 

Курсовой проект

 

По дисциплине «Методология разработки программных продуктов  и больших программных систем»

Тема: «Автоматизированная  система управления воздушным движением»

 

5 вариант

 

 

 

 

 

 

 

Выполнил: студент 404 гр. ФКН

спец. 8.080403 «Программное обеспечение  автоматизированных систем» 

Суриков П. Г.

Богданов О. А.

 

Принял: Марченко О. И.

 

 

 

 

Киев 2008

Содержание

 

1. Задание

 

Автоматизированная  система управления воздушным движением

(5 вариант)

 

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

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

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

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

В системе обеспечивается автоматизированное взаимодействие между рабочими местами диспетчерского центра, а также возможность обмена со смежными системами УВД.

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

2. Краткое описание методов и средств, которые используются при проектировании.

 

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

для календарного планирования – Microsoft Project 2003, обеспечивающий быстрое и  качественное планирование сроков и  этапов разработки, а также распределение  ресурсов.

Для графического представления спецификаций требований в виде UML-диаграмм  используется  CASE-средство Rational Rose 2003.

 

Описание методов  и средств  проектирования.

Визуальное моделирование (visual modeling) — это способ восприятия проблем с помощью зримых абстракций, воспроизводящих понятия и объекты реального мира. Моделирование способствует более полному усвоению требований, улучшению качества дизайна системы и повышению степени ее управляемости. Процесс моделирования включает в себя создание ряда диаграмм.

Диаграмма вариантов использования (use case diagram) - описывает функциональное назначение системы или, другими словами, то, что система будет делать в процессе своего функционирования.

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

Диаграмма классов (class diagram) служит для представления статической структуры модели системы в терминологии классов объектно-ориентированного программирования. Диаграмма классов состоит из множества элементов, которые в совокупности отражают декларативные знания о предметной области. Эти знания интерпретируются в базовых понятиях языка UML, таких как классы, интерфейсы и отношения между ними и их составляющими компонентами. При этом отдельные компоненты этой диаграммы могут образовывать пакеты для представления более общей модели системы. Если диаграмма классов является частью некоторого пакета, то ее компоненты должны соответствовать элементам этого пакета, включая возможные ссылки на элементы из других пакетов.

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

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

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

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

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

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

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

Архитектурный уровень  выполнения (process view) представляет структуру системы в период времени выполнения и описывает параметры, касающиеся производительности, надежности, целостности, управляемости и способности системы к масштабированию и синхронизации. Архитектор и в этом случае имеет дело с компонентами. С этой целью создаются диаграммы компонентов, воспроизводящие библиотечные и исполняемые компоненты (модули) системы и необходимые связи зависимости. Библиотечный компонент устанавливает соответствие между классом и определенным файлом аплета Java, компонента Active-X или динамической библиотеки формата DLL. Исполняемые компоненты отображают интерфейсы и зависимости уровня вызовов между отдельными исполняемыми модулями. Для облегчения восприятия диаграмм каждый компонент может быть отнесен к тому или иному стереотипу.

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

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

 

3. Спецификация проекта

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

 

1.  Определение  требований   

    

Рис. 1. Диаграмма прецедентов.

 

2.  Вербальные спецификации прецедентов

 

Прецедент 1

 

1.Краткое описание

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

2.Субьект  - диспетчер

3.Предусловие

Диспетчер открывает  форму запроса расписания взлета \посадки.

4.Основной поток

4.1.Диспетчер выполняет  запрос расписания взлета \посадки.

4.1.1 Диспетчер открывает  форму запроса расписания.

4.1.2 Диспетчер заполняет  форму основной информации о  судне.

4.1.3 Диспетчер заполняет  форму дополнительной (уточняющей) информации о судне.

4.1.4 Диспетчер отправляет  запрос на сервер системы.

4.2 Диспетчер ожидает  обработки запроса системой.

4.3 Если введенная информация  верна и система смогла сформировать  расписание, диспетчер получает  его представление.

4.3.1 Если введенная  информация неверна, выполняется  А1.

4.3.2 Если введенная  информация верна, но система  не смогла сформировать расписание на текущий момент, выполняется А2.

5.Альтернативные потоки

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

А2. Невозможность сформировать расписание. Если система не может  сформировать расписание по заданному  запросу диспетчера в текущий  момент времени, система возвращает развернутый отчет о причинах отказа или переносе момента обработки запроса. Прецедент продолжается.

6.Послеусловия

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

 

Прецедент 2

 

1.Краткое описание

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

2.Субьект  - система интерактивного взаимодействия.

3.Предусловие

Срабатывает таймер обновления представлений информации.

4.Основной поток

4.1 Система получает  сигнал о необходимости обновить  представление полетной информации  и информации о взлетах \посадках.

4.2. Система запускает  цикл ожидания информации от  подсистем.

4.3. Если за время  ожидания приходят данные от  радиолокационной системы выполняется  А1.

4.4. Если за время  ожидания приходят данные от  обработчика плановой информации то выполняется А2

4.5 Если за время  ожидания приходят данные от  системы УВД и безопасности  то выполняется А3.

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

4.6.1 Формирует отображение  координатных отметок и трасс

4.6.2 Формирует отображение  списков планов полета