Описание объекта автоматизации

Имени Гагарина Ю.А.»

Факультет Международный факультет прикладных информационных технологий

Специальность Информационные системы и технологии

Кафедра Прикладные информационные технологии

ДИПЛОМНАЯ РАБОТА

«РАЗРАБОТКА ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ ДЛЯ УЧЕТА И КОНТРОЛЯ СЕТЕВЫХ УСТРОЙСТВ ПО ПРОТОКОЛУ SNMP»

Выполнил студент группы ИСТ-51

Бескровнов Ю.Ю.

Руководитель работы к т.н., доцент

каф. ПИТ Большаков А.А.

Допущен к защите

Протокол № 25 от 09 июня 2014 г.

Зав. кафедрой _______________________ Долинина О.Н.

Саратов 2014

РЕФЕРАТ

Пояснительная записка 92 страниц, 59 рисунков, 23 таблицы, 30 источников.

Объектом автоматизации в данном дипломном проекте является процесс управления и контроля сетевого оборудования, находящегося в обслуживании компании ООО «РН-Информ».

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

Для разработки информационной системы были проанализированы существующие технологии разработки веб - приложений. На основе анализа был сделан выбор наиболее подходящих технологий (ASP.NET MVC4, SQL, JavaScript, ADO.NET).

СОДЕРЖАНИЕ

ВВЕДЕНИЕ. 6

1 ОПИСАНИЕ ОБЪЕКТА АВТОМАТИЗАЦИИ.. 7

1.1 Краткая характеристика объекта автоматизации. 7

1.2 Организационная структура ООО «РН-Информ». 8

1.3 Функциональные особенности ООО «РН-Информ». 10

1.4 Описание решаемой проблемы.. 11

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

1.6 Структурно-функциональная схема приложения. 13

2 ОБЗОР СУЩЕСТВУЮЩЕГО ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ.. 18

2.1 Система мониторинга «The Dube». 18

2.2 Система мониторинга «Zabbix». 19

2.3 Система мониторинга «Nagios». 20

2.4 Система мониторинга PRTG (Paessler Router Traffic Grapher) 23

2.5 Система мониторинга AggreGate Network Manager 25

2.6 Система мониторинга «RN_Monitoring». 26

2.7 Сравнительный анализ возможностей различных систем. 27

3 ОПИСАНИЕ РАЗРАБОТАННОГО ПРОГРАММНОГО.. 29

ОБЕСПЕЧЕНИЯ.. 29

3.1 Описание протокола SNMP. 29

3.1.1 Компоненты. 30

3.1.2 Соединители. 30

3.1.3 Данные. 32

3.2 Архитектура приложения. 35

3.2.1 Модуль DomainModel 35

3.2.2 Модуль Dal 39

3.2.3 Ядро системы.. 42

3.2.4 Модуль «Пользовательский интерфейс». 42

3.2.4.1 Модели. 44

3.2.4.2 Контроллеры.. 44

3.2.4.3 Конфигураторы пользовательского интерфейса. 46

3.2.4.4 Вспомогательные классы пользовательского. 46

интерфейса. 46

3.3 Выбор технологий для разработки. 47

3.3.1 Выбор платформы разработки. 47

3.3.2 Выбор языка программирования. 48

3.3.3 Выбор технологии разработки веб - приложения. 49

3.3.4 Выбор системы управления базой данных. 52

3.3.5 Выбор технологии разработки пользовательского. 54

интерфейса. 54

3.3.5.1 JavaScript 55

3.3.5.2 JQuery. 56

3.3.5.3 Технология Ajax. 56

3.4 Проектирование базы данных программного обеспечения. 59

3.4.1 Перечень таблиц. 62

3.5 Входные и выходные данные. 68

3.6 Описание функционала разработанного веб-приложения. 68

3.7 Общий алгоритм работы системы.. 69

3.8 Описание графического интерфейса системы.. 70

3.8.1 Авторизация. 70

3.8.2 Описание роли «Пользователь». 71

3.8.2.1 Вкладка «Мониторинг». 71

3.8.2.2 Вкладка «Отчет». 72

3.8.3 Описание интерфейса роли «Администратор». 73

3.8.3.1 Вкладка «Параметры». 73

3.8.3.1.1 Раздел «Пользователи». 74

3.8.3.1.2 Раздел «Заказчики». 75

3.8.3.1.3 Раздел «Типы устройств». 77

3.8.3.1.4 Раздел «Производители устройств». 79

3.8.3.1.5 Раздел «Модели устройств». 79

3.8.3.1.6 Раздел «Устройства». 82

3.8.3.1.7 Раздел «Оповещения». 84

3.8.3.1.8 Раздел «отчеты». 86

ЗАКЛЮЧЕНИЕ. 89

СПИСОК ЛИТЕРАТУРЫ.. 90

ВВЕДЕНИЕ[s1]

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

Основной целью дипломной работы является разработка для ООО ООО [s3] «РН-Информ» автоматизированной системы мониторинга сетевого оборудования по протоколу SNMP (RN-Monitoring). Система будет включать механизмы опроса устройств, хранить полученные данные, отображать графическую информацию работы оборудования за настраиваемый промежуток времени, уведомлять при пиковых нагрузках и некорректной работе служб, а также заблаговременно оповещать об окончании расходных материалов.

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

Описание решаемой проблемы

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

В организации отсутствует система по комплексной оценке всей сетевой инфраструктуры. Некоторые устройства имеют собственные средства мониторинга, но индивидуальное отслеживание не позволит оценить ситуацию комплексно, а держать одновременно несколько запущенных программ попросту неудобно. Гораздо лучше использовать централизованные системы мониторинга. Они включают в себя постоянное 24/7 наблюдения в реальном времени за ИТ – инфраструктурой в поисках неисправных систем, пиковых нагрузках, о приближении окончания расходных материалов. Также использование системы мониторинга сетевой инфраструктуры позволит значительно повысить доступность сети, предупредить возникновение аварийных ситуаций и снизить временные затраты на восстановление после сбоев.

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

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

Ø Уменьшение времени простоя бизнес – процессов из-за проблем в ИТ;

Ø Сокращение расходов по поддержке ИТ - инфраструктуры в целом;

Ø Оптимизация работы обслуживающего персонала для поддержки ИТ;

Ø Создание отчетности по использованию ресурсов и планирования на будущее;

Ø Использование средств и механизмов оповещения специалистов о возникшей проблеме.

Заказчиком были выдвинуты следующие требования к информационной системе:

Ø Надежность;

Ø Масштабируемость;

Ø Разграничение прав;

Ø Эргономический интерфейс (язык интерфейса - русский);

Ø Изменяемый набор отслеживаемых параметров;

Ø Возможность создания отчетов;

Ø Выбор механизмов оповещения.

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

Ø Снижение отказоустойчивости сети, оборудования, служб;

Ø Проактивное выявление неполадок в работе оборудования;

Ø Анализ загрузки сетевых каналов;

Ø Повышение эффективности работы ИТ - служб.

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

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

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

Ø Изучить предметную область;

Ø Провести анализ существующих приложений;

Ø Определить функционально-технические требования;

Ø Произвести выбор технологий для реализации задачи;

Ø Спроектировать и разработать БД;

Ø Разработать дизайн веб-приложения;

Ø Разработать и реализовать ролевой доступ администратора и пользователя;

Ø Протестировать разработанное приложение.

1.6 Структурно[s6] -функциональная схема приложения

В компании ОАО «НК «Роснефть» вся связь с пользователями осуществляется через корпоративную сеть. На поддержке у компании находится более 30 тысяч пользователей ПК. В состав сетевой инфраструктуры входят различные сетевые устройства, такие как принтеры, многофункциональные устройства, серверы, маршрутизаторы, рабочие станции, ip - телефония, источники бесперебойного питания. Для улучшения качества обслуживания сетевых устройств в сети была разработана система мониторинга. Система запущена на веб - сервере, опрашивает последовательно все необходимые устройства с точным набором параметров и сохраняет полученные значения в базу данных. Назначение параметров производится в бизнес-логике приложения. Если значение параметра выходит за диапазон допустимых значений, ранее настроенного администратором, то осуществляется оповещение службы поддержки. После чего, ответственный из службы поддержки обязан предпринять действия по устранению инцидента. Ниже в структурно-функциональной схеме отображена работа приложения и функции пользователей приложения (см. рисунок 1.3).

На рисунке 1.3 отображены информационные потоки в «RN-Monitoring».

Электропитание

ЛВС

МФУ

ИБП

Коммутатор

Сервер

Принтер

Server БД

Web-приложение

Администратор

Служба поддержки

Получение уведомления о некорректной работе

Устройства

Отчетов

Личный кабинет

Добавление

Изменение

Удаление

Редактирование

Формирование

Редактирование

Просмотр

Мониторинг

Опрос

Опрос

Опрос

Оргтехника

Сетевое оборудование

ИБП

Опрос

Рис.1.3.Структурно-функциональная схема ПО

В организации ООО «РН-Информ» (Поволжье) находится в обслуживании более 500 сетевых устройств.

В таблице 1.1 приведены подробные количественные характеристики объекта автоматизации.

Таблица 1.1. Количественные характеристики

Устройства /кол-во	Серверы	МФУ	Принтеры	Коммутаторы

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

· устройство (имя устройства, физический адрес, уникальный адрес, версия прошивки),

· процессор (имя устройства, загруженность, скорость работы, время работы, температура и т.д.),

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

· ошибка (причина и многое другое).

[s7]

В качестве примера приведен приблизительный список параметров мониторинга, разделенный по типам устройств (таблиц 1.2).

Таблица 1.2. Параметры мониторинга

Тип устройства	Параметр мониторинга
Принтер и МФУ	Запас чернил/тонера
Текущий статус принтера
Текущий статус печати
Время работы с момента последней перезагрузки
Количество портов у принтера
Статус каждого порта
Количество подключенных принтеров
Общее количество заданий в принтере
Список IP – адресов или пользователей, создавших задания
Замятие, отсутствие бумаги в латке
Всего распечатано страниц
Просмотр последних документов
Коммутатор	Количество, размер, вид пакета, прошедший через каждый интерфейс
Ведение списка подключенных интерфейсов
Отслеживание скорости передачи
Информация о состоянии портов
Отслеживания сетевых протоколов
Ведение списка MAC – адресов
Сервер	Просмотр запущенных служб
Просмотр состояния жестких дисков
Просмотр информации о процессорах
ИБП	Уровень заряда батареи
Температура батареи
Информация о напряжении в сети
Уровень нагрузки
Количество подключенных устройств

ОБЕСПЕЧЕНИЯ

Описание протокола SNMP

Протокол SNMP (Simple Network Management Protocol) - предназначен для проверки функционирования сетевых маршрутизаторов и мостов. Со временем сфера действия протокола стала распространяться и на другие сетевые устройства, такие как: хабы, шлюзы, терминальные сервера, многофункциональные устройства, принтеры и т.д. Существуют различные версии протокола, основным направлением развития которых было совершенствование вопросов безопасности. Существуют следующие версии SNMP: SNMPv1, SNMPv2, SNMPv2c, SNMPv2u, SNMPv3.

Протокол был создан для решения следующих задач:

Ø Обработка ошибок (выявление, определение и устранение после сбоев и отказов в работе сети);

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

При разработке стандартов SNMP основной идеей было сделать управление протоколом простым, пренебрегая при этом такими характеристиками как мощность, масштабируемость и защищенность [9].

Архитектура

Составные элементы системы управления SNMP:

o Компоненты:

· Агент;

· Менеджер;

o Соединители:

· Транспортный протокол;

o Данные:

· Управляющая информация MIB (Management Information Base).

Компоненты.

Архитектура системы SNMP построена по схеме «клиент-сервер». Система SNMP содержит множество управляемых узлов, на каждом из которых размещается достаточной простой сервер - агент SNMP, а также, по крайней мере, один узел, содержащий сложного клиента-менеджера SNMP.

Связь между агентом и менеджером осуществляется при помощи протокола SNMP с целью обмена управляющей информацией. Менеджер периодически опрашивает множество агентов. Агенты, работающие на хостах, собирают информацию об устройствах и записывают собранные счетчики в значения переменных в базу управляемой информации MIB. Тем самым делая ее доступной для менеджеров. Данная реализация системы теряет в масштабируемости, поскольку есть выделенный клиент, занимающийся опросом всех серверов. Такая схема построения обеспечивает простоту реализации систем под управлением SNMP [10].

Соединители

SNMP работает на 7 уровне модели OSI, являясь службой прикладного уровня. Взаимодействие агента и менеджера на уровне протокола SNMP организуется посредством объектов PDU (Protocol Data Unit), которые инкапсулируются в транспортный протокол. Структура объекта PDU отображена на рисунке 3.1.

Рис.3.1. Структура PDU

Поля и значения:

Ø Версия (содержит версию SNMP);

Ø Пароль (содержит последовательность символов, описывающую принадлежность к группе);

Ø Тип PDU (цифровой идентификатор запроса);

Ø Идентификатор запроса, это тот самый набор символов, который связывает в единое целое запрос\ответ.

Ø Статус ошибки – это число, характеризующее характер ошибки:

Ø 0(NoError) – нет ошибки;

Ø 1(TooBig) - объект не вмещается в одно Response сообщение,

Ø 2(NoSuchName) – несуществующая переменная;

Ø 3(BadValue) – недопустимое значение или совершена синтаксическая ошибка,

Ø 4(ReadOnly)- при Set запросе была попытка изменить read-only переменную;

Ø 5(GenErr) – другие ошибки.

Ø Индекс ошибки;

Ø Связанные переменные может содержать одну и более переменную (для запросов Get – только имя переменной, Set – имя и устанавливаемое значение, для Response – имя и запрошенное значение).

SNMP PDU (или сообщения SNMP протокола)

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

Ø Trap-одностороннее уведомление от SNMP агента менеджеру о каком-либо событии;

Ø GetReponse – ответ от агента к менеджеру, возвращающий запрошенные значения переменных;

Ø GetRequest – запрос к агенту от менеджера, используемый для получения значения одной или нескольких переменных;

Ø GetNextRequest – запрос к агенту от менеджера, используемый для получения следующего в иерархии значения переменной;

Ø SetRequest – запрос к агенту на установку значения одной или нескольких переменных ;

Ø GetBulkRequest – запрос к агенту на получения массива данных;

Ø InformRequest – односторонее уведомление между менеджерами. Может использоваться для обмена информацией о MIB [11].

Данные

Вся управляющая информация для контроля сетевых устройств и маршрутами Интернет находится в базе данных MIB (Management Information Base).

Согласно нормативам MIB, управляющая информация делится на восемь категорий. MIB категории включают в себя информацию представленную в таблице 3.1.

Таблица 3.1 Описание категорий MIB

MIB-категория	Описание
System	Операционная система ЭВМ или маршрутизатора
Interfaces	Сетевой интерфейс
Addr.trans	Преобразование адреса
IP	Программная поддержка протокола Интернет
ICMP	Программное обеспечение ICMP - протокола
TCP	Программное обеспечение TCP - протокола
UDP	Программное обеспечение UDP – протокола
EGP	Программное обеспечение EGP – протокола
SNMP	Программное обеспечение SNMP – протокола

Задание имен OID

Управляемые объекты организованы в древовидную иерархию. Эта структура является основной схемы присвоения имен в SNMP. Идентификатор объекта состоит из ряда целых чисел, определяемых узлами дерева и разделенных точками. Несмотря на то, что есть удобочитаемая форма, более дружественная, чем строка чисел, эта форма представляет собой не что иное, как ряд имен, разделенных точками, каждое из которых представляет узел дерева. На рисунке 3.2 изображено несколько верхних уровней дерева. В дереве объектов самый верхний узел называется корнем; все, из чего исходят дочерние узлы называются субдеревом; а все узлы, которые не имеют дочерних, называются концевыми узлами (листьями).

На субдереве iso(1).org(3).dod(6).internet(1), которое в форме OID представляется как 1.3.6.1. или iso.org.dod.internet. У каждого управляемого объекта есть цифровой идентификатор OID и соответствующее текстовое имя.

Рис.3.2. Дерево объектов

Ветвь directory в настоящее время не используется. Ветвь management, или mgmt определяет стандартный набор управляемых объектов Интернета. Ветвь experimental зарезервирована для целей тестирования и исследования. Объекты ветви private определяются в одностороннем порядке, то есть за определение объектов этой ветви люди и организации отвечают сами [12].

Архитектура приложения

Архитектуру приложения можно разделить на 4 основных модуля:

1. DomainModel – модуль, содержащий в себе объекты предметной области;

2. DAL – Модуль доступа к БД. Инкапсулирует в себе репозитории для работы с базой данных. Работает с объектами предметной области, описанными в модуле DomainModel;

3. Core – ядро системы. Инкапсулирует в себе базовые алгоритмы работы системы;

4. UI – модуль отображения. Содержит в себе Web формы, отражающие интерфейс пользователя.

На рисунке 3.3 изображена схема взаимодействия модулей архитектуры

.

Доступ к данным

Интерфейс пользователя

Компоненты сущностей системы

Ядро системы

Рис 3.3.Общая схема взаимодействия модулей архитектуры

Модуль DomainModel

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

1. Cache – базовый класс алгоритма работы системы. Инкапсулирует в себе основные потоки обновления значений, уведомления клиентов об изменении значений;

2. ItemHelper – вспомогательный класс;

3. Models – содержит в себе модель для работы ядра системы:

3.1. Device – устройство. Инкапсулирует в себе данные SNMP устройства;

3.2. DeviceItem – параметр устройства. Инкапсулирует в себе параметр;

3.3. SubscriptionItem – элемент подписки. Инкапсулирует в себе настройки подписки на уведомление об обновлении параметра устройства;

3.4. Notification – информация о уведомлении. DTO объект для передачи информации о обновленном параметре.

4. Interfaces – содержит в себе описание интерфейсов по работе с моделью предметной области:

4.1. IConfigRepo – интерфейс репозитория для чтения начальной конфигурации системы;

4.2. IHistoryRepo – интерфейс репозитория для записи исторических значений;

4.3. INotificationExecutor – интерфейс класса для выполнения уведомлений.

5. EfModels – cодержит в себе модель, которая используются в модуле UI для бизнес логики, а так же в модуле DAL для записи в БД:

5.1. Maker – производитель устройства;

5.2. DeviceType – тип устройства;

5.3. DeviceModel – модель устройства;

5.4. DeviceItemEntity – параметр модели устройства;

5.5. Customer – клиент, которому принадлежит конкретное устройство;

5.6. DeviceEntity – конкретное устройство;

5.7. DeviceItemHistory – история изменения параметра конкретного устройства;

5.8. Notification – уведомление пользователя об изменении параметра конкретного устройства;

5.9. EmailNotification – уведомление электронной почтой;

5.10. PhoneNotification – уведомление СМС сообщением;

5.11. EmailEntity – информация об адресе почты;

5.12. PhoneNumber – информация о номере телефона для смс оповещения;

5.13. User – пользователь уведомлений системы

6. DalInterfaces - содержит интерфейсы репозиториев, модели. Для каждой модели есть соответствующий интерфейс.

Декомпозиция модуля DomailModel отображена на рисунке 3.4.

DomainModel.Models

DomainModel.Interfaces

DomainModel

DomainModel.DalInterfaces

DomainModel.EfModels

Рис.3.4.Декомпозиция модуля DomainModel

Компоненты системы изображены на рисунке 3.5.

Рис.3.5.Компоненты DomainModel

На рисунке 3.6 отображены взаимодействие системы модели

Рис.3.6.Code First модели Entity Framework

Основные интерфейсы модуля DomainModel продемонстрированы на рисунке 3.7.

Рис.3.7.Интерфейсы модуля DomainModel

Модуль Dal

DAL – модуль содержащий в себе реализацию интерфейсов репозиториев описанных в DomainModel.DalInterfaces. Репозиторий – это класс, обеспечивающий операции с таблицей БД. Данный модуль можно разделить на совокупность следующих классов:

Ø SnmpDbContext – EntityFramework (EF) контекс для работы с базой данных;

Ø DatabaseInitializer – класс для создания базы данных;

Ø DalInit – класс для инициализации DAL. Связывает интерфейсы репозиториев с конкретными классами (используется IOC контейнер StructureMap), настраивает маппинг EF сущностей с POCO объектами (используется AutoMapper);

Ø Repos – содержит в себе реализации конкретных репозиториев и вспомогательные классы. Для каждого интерфейса, описанного в DomainModel.DalInterfaces есть собственная реализация.

Декомпозиция модуля Dal приведена на рисунке 3.8.

Рис.3.8.Декомпозиция модуля DAL

Компоненты инициализации базы данных отображены на рисунке 3.9.

Рис.3.9.Компоненты инициализации базы данных

Взаимодействие классов-репозиториев отображены на рисунке 3.10.

Рис.3.10.Взаимодействие классов - репозиториев

Описание репозиториев:

Ø BaseRepository – базовый репозиторий для всех других;

Ø ConfigRepo – репозиторий для загрузки устройств в кэш;

Ø CustomersRepository – репозиторий для манипулирования объектами заказчиков;

Ø DeviceItemsHistoryRepository – репозиторий для манипулирования объектами истории изменения параметров;

Ø DeviceItemsRepository – репозиторий параметров устройства;

Ø DeviceModelsRepository – репозиторий моделей устройств;

Ø DevicesItemsRepository – репозиторий конкретных параметров устройств;

Ø DeviceRepository – репозиторий устройств;

Ø DeviceTypesRepository – репозиторий типов устройств;

Ø EmailNotificationsRepository – репозиторий оповещений по email;

Ø EmailsRepository – репозиторий адресов электронной почты;

Ø MakersRepository – репозиторий производителей;

Ø NotificationsRepository – репозиторий конкретных оповещений;

Ø PhoneNotifications – репозиторий оповещений по телефону;

Ø PhoneNumbersRepository – репозиторий номеров телефонов;

Ø ReportParametersDataTypesRepository – репозиторий типов данных параметров отчетов;

Ø ReportParametersRepository – репозиторий параметров отчетов;

Ø ReportsRepository – репозиторий отчетов.

Ядро системы

Основные классы системы:

Ø SnmpScanServer – класс, инкапсулирующий в себе алгоритм опроса устройств, уведомления пользователя об изменении величины параметров согласно заданной конфигурации;

Ø NotificationExecutor – класс, инкапсулирующий в себе логику уведомления пользователей;

Ø EmailEntityComparer – вспомогательный класс;

Ø PhoneNumberComparer – вспомогательный класс.

Схема взаимодействия классов изображена на рисунке 3.11.

Рис.3.11.Декомпозиция модуля Core

Модели

Описание моделей:

Ø CustomerModel – модель заказчика;

Ø DeviceModel – модель устройства;

Ø DeviceModelModel – модель моделей устройства;

Ø DeviceTypeModel – модель типа устройства;

Ø EmailModel – модель адресов электронной почты;

Ø EmailNotificationModel – модель оповещений по email;

Ø ItemModel – модель параметра устройства;

Ø MakerModel – модель производителя;

Ø NotificationModel - модель оповещения;

Ø PhoneNotificationModel – модель оповещения по телефону;

Ø PhoneNumberModel – модель номера телефона;

Ø ReportModel – модель отчета;

Ø ReportParameterModel – модель параметра отчета;

Ø UserModel – модуль пользователя;

Ø WarningModel – модель аварийного устройства.

Контроллеры

Описание контроллеров:

Ø AccountController – контроллер манипулирования учетными данными пользователей;

Ø CustomersController – контроллер манипулирования данными заказчиков;

Ø DeviceModelsController – контроллер манипулирования моделями устройств;

Ø DevicesController – контролер манипулирования данными устройств;

Ø DeviceTypesController – контроллер манипулирования типами устройств;

Ø HomeController – стартовый контроллер;

Ø MainPanelController – контроллер главной панели;

Ø MakersController – контроллер манипулирования данными производителями;

Ø NotificationsController – контроллер манипулирования данными оповещений;

Ø ReportsController – контроллер манипулирования данными отчетов;

Ø SettingsController – контролер параметров приложения;

Ø UsersController – контроллер манипулирования данными пользователей;

Ø WarningsController – контроллер манипулирования данными аварийных устройств.

Схема контроллеров отображена на рисунке 3.14.

Рис.3.14.Взаимодействие контроллеров

Интерфейса

Вспомогательные классы модуля UI приведены ниже (см. рисунок 3.15):

Ø HtmlExtensions – вспомогательный класс, создающий пользовательские html – хелперы;

Ø RequestExtensions – вспомогательный класс обработки http - запроса;

Ø AppSettingsHelper – вспомогательный класс для доступа к секции AppSettings глобального конфигурационного файла приложения.

Рис.3.15.Вспомогательные классы UI

Выбор платформы разработки

.Net Framework- программная платформа для создания приложений под различные операционные системы. Ключевые средства, поддерживаемые .NET:

· Возможность взаимодействия с существующим кодом;

· Поддержка многочисленных языков программирования;

· Общий механизм, разделяемый всеми поддерживающими .Net языками;

· Языковая интеграция;

· Общая библиотека базовых классов;

· Упрощенная модель развертывания, по сравнению с COM.

Компоненты платформы .Net

.Net представляет собой среду исполнения и обширную библиотеку базовых классов. Среда исполнения называется общеязыковая среда выполнения (Common Language Runtime или CLR). CLR обеспечивает автоматическое обнаружение, загрузку и управление объектами .NET, также занимается управлением памятью, размещением приложения, координированием потоков и выполнением проверок.

Другим компонентом платформы считается общая система типов (Common Type System или CTS). В спецификации CTS описаны все возможные типы данных и программные конструкции.

Общеязыковая спецификация (Common Language Specification или CLS), в которой описано подмножество общих типов и программных конструкций, которое должны поддерживать все языки программирования для .Net. Отношения между CLR, CTS, CLS и библиотеками базовых классов (см. рисунок 3.16)

Библиотека базовых классов

Общеязыковая исполняющая среда

Общая система типов (CTS)

Общеязыковая спецификация (CLS)

Доступ к базам данных

API- интерфейсы для построения графических пользовательских интерфейсов настольных приложений

Безопасность

Многопоточная обработка

Файловый ввод-вывод

API- интерфейсы для удаленной работы

API – интерфейсы для веб-приложений

и другие

Рис.3.16.Отношения между CLR, CTS, CLS и библиотеками базовых классов

Данная платформа была выбрана по следующему ряду преимуществ:

Ø Можно использовать Reporting Services для построения отчетов;

Ø Удобная модель многопоточного программирования по сравнению с Java;

Ø На сервере хранятся скомпилированные файлы;

Ø Удобный механизм разработки Web-приложений [13].

Архитектура MVC.

Взаимодействие пользователя с приложением MVC осуществляется в соответствии с естественным циклом: пользователь принимает действие, в ответ на которое приложение изменяет свою модель данных и доставляет обновленное представление пользователю. Затем цикл повторяется. Это очень удобно укладывается в схему веб-приложений, предоставляемых в виде последовательностей запросов на ответы HTTP.

Веб-приложение, нуждающееся в объединении нескольких технологий (например, баз данных, HTML разметки и исполняемого кода), обычно разделяются на ряд слоев и уровней. Полученные в результате шаблоны естественным образом вписываются в концепции MVC.Схема взаимодействия показана на рисунке 3.18.

Рис.3.18.Схема взаимодействия компонентов ASP.NET MVC

Инфраструктура ASP.NET MVC Framework реализует шаблон MVC и при этом обеспечивает значительно улучшенное разделение ответственности.

Альтернативным подходом к разработке на ASP.Net является WebForms.Преимущества MVC над WebForms:

· Полный контроль над генерируемым HTML – кодом;

· Генерирует чистый HTML – код;

· Лучше реализовано разделение логики приложения и представления;

· Поддерживает множество различных движков представления;

· Маленький размер загружаемой страницы;

· Удобная интеграция с Фреймворками типа jQuery.

Обоснования выбора:

1. Более гибкие возможности разработки динамического пользовательского интерфейса;

2. Небольшой размер страницы, что увеличивает скорость работы;

3. Более удобная модель построения асинхронных приложений по сравнению с WebForms;

4. Наличие встроенных механизмов взаимодействия с jQuery [16].

Интерфейса

Для создания пользовательского интерфейса были использованы технологии HTML (Hyper Text Markup Language), CSS (Cascading Style Sheets), JavaScript. Сайт состоит из страниц, написанных на HTML, которые понимает веб-браузер. Страница разбита на компоненты, к которым можно применять CSS – стили или управлять скриптами.

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

JavaScript

JavaScript – это язык программирования, который используется как встраиваемый язык программирования в HTML разметку и выполняется на клиентской стороне. Для обеспечения высокого уровня абстракции и достижения приемлемой степени кросс-браузерности при разработке веб-приложений используются библиотеки JavaScript. Они представляют собой набор многократно используемых объектов и функций. Наиболее известные библиотеки: Adobe Life, Dojo Toolkit, jQuery и т.д.

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

Преимущества JavaScript:

1. Используется для создания динамичного пользовательского интерфейса;

2. Снижает нагрузку на веб-сервер;

3. Реализует кросс - браузерную совместимость [18].

JQuery

JQuery – это библиотека JavaScript, упрощающая написание JavaScript кода. Данная библиотека помогает легко получать доступ к любому элементу DOM, обращаться к атрибутам и содержимому элементов DOM, манипулировать ими. Также библиотека jQuery предоставляет удобный инструмент программирования приложений (application programming interface или API) по работе с Ajax.

Возможности:

Ø Обращаться к любому элементу DOM (объектной модели документа) и манипулировать ими;

Ø Работать с событиями;

Ø Легко осуществлять различные визуальные эффекты (частично перекрывает требование по эргономическому интерфейсу);

Ø Работать с Ajax (позволяет общаться с сервером без перезагрузки страницы);

Ø Имеет огромное количество JavaScript плагинов, предназначенных для создания элементов пользовательских интерфейсов;

Ø Воспроизведение анима<