диплом целиком (1218792), страница 5

Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 5)

Условия эксплуатации АИС совпадают с условиями эксплуатации ПЭВМ IBM PC и совместимых с ними ПК. Для запуска АИС требуется наличие IBM PC или совместимого с ним ПК.

Данная АИС должна представлять собой самостоятельный исполняемый модуль, который должен работать под управлением ОС Windows 7 и выше. База данных должна устанавливаться на ПК пользователя и не должна требовать наличие серверной СУБД.

В ходе разработки АИС должно быть разработано описание базы данных (схема БД) и подготовлена следующая документация:

– текст программы;

– диаграмма БД.

2 ПРОЕКТИРОВАНИЕ

2.1 Структура данных

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

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

В решении WeatherAnalysis ядро приложения представлено в проекте WeatherAnalysis.Core. Классы и интерфейсы представленные в этом проекте функционально разделены на пять категорий:

1. модель данных приложения (Model);

2. управление данными приложения (Data);

3. исключения (Exceptions);

4. бизнес-логика приложения (Logic);

5. сервисы (Service).

К моделям данных, позволяющим моделировать структуру данных, относятся классы (пространство имен WeatherAnalysis.Core.Model):

– Location;

– WeatherRecord;

– FireHazardReport.

Location – класс, представляющий информацию о населенном пункте.

WeatherRecord – класс, представляющий погодную запись.

FireHazardReport – класс, представляющий отчет о пожарной опасности.

Рисунок 12 – Диаграмма классов модели приложения

К управлению данными приложения относятся (WeatherAnalysis.Core.Data):

– IDbManager;

– IFireHazardReportManager;

– ILocationManager;

– IWeatherRecordManager.

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

IFireHazardReportManager, ILocationManager, IWeatherRecordManager – интерфейсы предоставляющие методы по чтению, сохранению, поиску, удалению соответствующих данных из БД.

Рисунок 13 – Диаграмма классов управления базой данных

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

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

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

– WeatherAnalysisException;

– WeatherRecordNotFoundException;

– WeatherServiceException.

WeatherAnalysisException – базовое исключение для ядра приложения.

WeatherRecordNotFoundException – исключение, означающее, что погодная запись не найдена.

WeatherServiceException – исключение, означающее, что в сервисе погоды произошла ошибка.

Рисунок 14 – Диаграмма классов исключений

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

2.2 Связь программных компонентов

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

– зацепление по общей области;

– зацепление по содержимому;

– зацепление по управлению;

– зацепление по данным;

– смешанное зацепление;

– патологическое зацепление.

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

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

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

Рисунок 15 – Диаграмма компонентов приложения

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

2.3 Математическая модель

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

, (17)

где n – число дней после последнего дождя; T – температура воздуха на 12-14 часов по местному времени; – точка росы на 12-14 часов по местному времени; K – коэффициент пожароопасности [13].

Точка росы может быть определена по формуле (18) как зависимость от температуры воздуха и влажности в момент времени.

, (18)

где определена как

, (19)

где T – температура воздуха, RH – относительная влажность, a=17,27, b=237,7 °C.

В таблице 5 представлены классы пожарной опасности.

Таблица 5 – Классы пожарной опасности

Класс пожарной опасности	Комплексный показатель, К	Опасность
I	до 300	Отсутствие опасности
II	от 301 до 1000	Малая пожарная опасность
III	от 1001 до 4000	Средняя пожарная опасность
IV	от 4001 до 10000-12000	Высокая пожарная опасность
V	больше 10000-12000	Чрезвычайная пожарная опасность

2.4 Связь с сайтами

В качестве поставщика погодных данных используется сервис Open Weather Map. Данный сервис имеет удобное, хорошо документированное REST api, которое позволяет легко выгружать данные в популярных для веб-приложений форматах JSON и XML. Сервис предусматривает как бесплатный доступ к данным, так и платный. В платной версии становится доступной возможность выгрузки истории погодных данных. Разработанное приложение на текущий момент использует только бесплатные функции Open Weather Map; в будущем, по желанию заказчика, возможен легкий переход на платную версию сервиса.

Для вызова методов веб-сервиса используется библиотека с открытым исходным кодом RestSharp. Данная библиотека позволяет формировать и отправлять http запросы, и принимать http ответы от веб-службы в различных режимах и формах представления. При необходимости, существует возможность тонкой настройки данной программной библиотеки [14].

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

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

Рисунок 16 – Диаграмма последовательности получения данных с веб-сервиса

На представленной диаграмме веб-сервис не имеет линии «жизни», так как является независимым от программы компонентом.

2.5 Связь с базой данных

Для хранения данных используется реляционная микро СУБД SQLite. Данная СУБД позволяет хранить данные на локальном ПК, без установки дополнительного программного обеспечения. Данные хранятся в одном файле, к которому можно обращаться как к базе данных и выполнять запросы, составленные на языке SQL. SQLite реализует функции выборки, группировки, агрегирования, фильтрации, проекции, записи, удаления данных подмножество SQL [15].

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

Связь с базой данных осуществляется при помощи библиотеки linq2db. Данная библиотека позволяет делать запросы к базе данных как к некоторому объекту внутри самого приложения посредством вызова цепочки методов, либо составлении запроса на встроенном в C# языке linq (language integrated query). Такой подход позволяет абстрагироваться от низкоуровневых задач, таких как установка соединения с базой данных, обработка “сырых” данных ответа и т.д.

Чтобы обеспечить еще большую абстракцию от способа хранения данных были реализованы классы DbManager, LocationManager, WeatherRecordManager и FireHazardReportManager, которые соответственно реализуют интерфейсы IDbManager, ILocationManager, IWeatherRecordManager и IFireHazardReportManager, и находятся в пространстве имен WeatherAnalysis.Core.Data.Sql. Полученный уровень абстракции позволяет заменить реализацию хранения данных при минимуме трудовых затрат. Например, если заказчик в будущем захочет использовать для хранения данных серверную СУБД, то реализовать заново нужно будет всего лишь 4 программных интерфейса. Следующая диаграмма иллюстрирует последовательность выполнения запроса пользователя на отображение данных.

Характеристики

Список файлов ВКР