Структура информации для управления — КиберПедия 

Эмиссия газов от очистных сооружений канализации: В последние годы внимание мирового сообщества сосредоточено на экологических проблемах...

Двойное оплодотворение у цветковых растений: Оплодотворение - это процесс слияния мужской и женской половых клеток с образованием зиготы...

Структура информации для управления

2017-10-08 331
Структура информации для управления 0.00 из 5.00 0 оценок
Заказать работу

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

Ø Имя (идентификатор объекта (OID-Object Identifier), уникально определяет управляемый объект. Имена бывают двух видов – цифровые и «удобочитаемые».

Ø Тип и синтаксис (тип данных управляемого объекта определяется при помощи части языка ASN.1(Abstract Syntax Notation One)). ASN.1 – это способ указать, как данные представляются и передаются между менеджерами и агентами в контексте SNMP.

Ø Кодировка (Конкретный управляемый объект кодируется в строчку октетов с использованием правил “Basic Encoding Rules” (BER стандарта ASN.1). Правила BER определяют, как объекты кодируется и декодируются, чтобы их можно было транспортировать по среде передачи).

Стандарт на структуру MIB, стандарт «The Structure of Management Information» (SMI) требует, чтобы все MIB-переменные были описаны и имели имена в соответствии с ANS.1 (Abstract syntax notation 1). В SMI не используется полный набор типов объектов, предусмотренных в ANS.1, разрешены только следующие типы примитивов:

Ø Integer (некоторые переменные объявляются целыми с указанием начального значения, примером может служить номер UDP- или TCP-портов);

Ø Octet string (последовательность байтов). В соответствии с BER последовательность октетов должна начинаться с числа байт в этой последовательности;

Ø Object identifier (идентификатор объекта).Имя объекта, представляющее собой последовательность целых чисел, разделенных точками. (192.148.167.129 или 1.2.3.1.2.5);

Ø Null указывает, что переменная не имеет значения;

Ø Counter (счетчик).

Задание имен 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

 


Поделиться с друзьями:

Особенности сооружения опор в сложных условиях: Сооружение ВЛ в районах с суровыми климатическими и тяжелыми геологическими условиями...

Двойное оплодотворение у цветковых растений: Оплодотворение - это процесс слияния мужской и женской половых клеток с образованием зиготы...

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

Индивидуальные и групповые автопоилки: для животных. Схемы и конструкции...



© cyberpedia.su 2017-2024 - Не является автором материалов. Исключительное право сохранено за автором текста.
Если вы не хотите, чтобы данный материал был у нас на сайте, перейдите по ссылке: Нарушение авторских прав. Мы поможем в написании вашей работы!

0.041 с.