32
кодах для тех платформ, в которых реализована поддержка Windows, Windows
CE, Windows Mobile, Windows Phone .NET Compact Framework, .NET
Framework, Xbox и Silverlight. Также данная среда поддерживает интеграцию с
СУБД Microsoft Access посредством общей платформы .NET.
Выбор данных средств разработки также обоснован тем, что вся сетевая
инфраструктура компании, которая будет использоваться для мониторинга
сетевого оборудования, расположена именно на серверах под управлением
Windows Server и других решениях Microsoft.
Немаловажным является и тот факт, что в организации имеются другие
решения на платформе .NET, которые впоследствии можно будет
интегрировать в единый комплекс программно-аппаратных решений компании,
либо существенно упростить взаимодействие между различными
программными продуктами.
Основным языком для разработки программного решения был выбран
такой язык программирования, как C# (C Sharp). Данный язык родом из семьи
языков, имеющих C-подобный синтаксис, из всего семейства его синтаксис
максимально приближен к C++ и Java. В языке имеется поддержка
полиморфизма, перегрузки операторов (причём как операторов явного, так и
неявного типа), статическая типизация, делегаты, свойства, атрибуты, события,
обобщённые методы и типы, множество анонимных функций,
поддерживающих замыкания, итераторы, исключения и XML-комментарии.
Предшественники C#, такие как Smalltalk, C++, Pascal, и, особенно, Java,
передали своему преемнику множество функций и особенностей. Для того,
чтобы исключить некоторые модели, которые при разработке программных
продуктов зарекомендовали себя главным образом как проблематичные, язык
опирается как раз на практику использования своих языков-предшественников.
Программный код на C# компилируется в приложения или сборки с
расширениями *.exe или *.dll на языке CIL. Далее при запуске на выполнение
подобного приложения происходит JIT-компиляция (Just-In-Time) в машинный
код, после чего выполняется уже этот скомпилированный код. Так как наше
33
приложение может быть достаточно объёмным и содержать большое
количество инструкций, в текущий момент времени будет компилироваться
только та часть приложения, к которой непосредственно идет обращение. Если
же обратиться к другой части кода, то она будет скомпилирована из CIL в
машинный код. При этом та часть приложения, которая уже скомпилирована,
сохраняется в памяти до самого завершения работы программы. В итоге это
существенно повышает производительность подобных решений и позволяет
затрачивать в разы меньшее количество вычислительных ресурсов.[14]
2.3. Проектирование базы данных
2.3.1. Внешний уровень архитектуры БД
2.3.1.1. Формирование описания предметной области
Для описания внешнего уровня архитектуры использованы результаты
анализа предметной области: описание иерархии функций АС,
формализованное описание предметной области, состав пользователей АИС и
их уровни доступа; выделены классы объектов и их свойства.
Таблица 5
Классы объектов
Класс
объектов/
Свойство
Ключ
(уникальный,
первичный)
Физическая
характеристика
(тип, длина)
Обязательность
значения
(м.б.,д.б.)
Процессы
(генерация,
ввод значений,
обновление,
просмотр)
HOSTS
HostIpAddress
УИ1, ПК
Короткий текст, 255
д.б.
в,п,о
HostName
Короткий текст, 255
м.б.
в,п,о
HostMACAddress
Короткий текст, 255
м.б.
в,п,о
CheckMethod
Короткий текст, 255
д.б.
в,п,о
EVENTS
EventId
УИ1, ПК
Счётчик
д.б.
г.п.
HostIpAddress
Короткий текст, 255
д.б.
в,п.
CheckTime
Дата/время
д.б.
в,п.
Result
Короткий текст, 255
д.б.
в,п,о
IsAccessible
Логический, 1
д.б.
в,п,о
34
Связи между классами объектов приведены в таблице 6.
Таблица 6
Связи между классами объектов
Классы объектов
Опционально
сть связи
Имя связи со
стороны
Тип связи со
стороны
Главный
КО
Подч.КО
Главн
ый КО
Под
ч.КО
Главн
ый КО
Подч.
КО
Главн
ый КО
Подч.
КО
HostIpAddre
ss
HostName
Д.б.
М.б.
Относи
тся
Имеет
1
1
HostIpAddre
ss
HostMACAdd
ress
Д.б.
М.б.
Относи
тся
Имеет
1
1
EventId
CheckTime
Д.б.
Д.б.
Относи
тся
Соответ
ствует
1
1
HostIpAddre
ss
Result
Д.б.
Д.б.
Относи
тся
Имеет
1
1
HostIpAddre
ss
IsAccessible
Д.б.
Д.б.
Имеет
Имеет
1
1
В таблицах использованы сокращения: м.б. – может быть; д.б. – должно
быть; КО – класс объектов; подч. – подчиненный.
Выявив связи между классами объектов, необходимо проверить связь,
путем чтения с обеих сторон, используя правило чтения:
1. Каждый HostIpAddress может иметь один HostName. Каждому
HostName должен относиться только один HostIpAddress.
2. Каждый HostIpAddress может иметь один HostMACAddress. Каждому
HostMACAddress должен относиться только один HostIpAddress.
3. Каждому EventId должен соответствовать один CheckTime. Каждому
CheckTime должен относиться только к одному EventId.
4. Каждый HostIpAddress должен иметь один Result. Каждый Result
должен относиться только к одному HostIpAddress.
5. Каждый HostIpAddress должен иметь один IsAccessible. Каждый
IsAccessible должен иметь только один HostIpAddress.
Таким образом, выявленные в предметной области связи между
классами объектов являются бинарными.
35
2.3.1.2. Пользователи АС
В ходе анализа предметной области, которая обозначена в рамках
разработки данного проекта, необходимо выделить определённый состав
пользователей системы и их уровень доступа к данным:
– прикладной программист, обладает правами на выполнение всех
операций;
– конечный пользователь – оператор, выполняющий операции чтения,
добавления и обновления данных.
Состав пользователей АС, их уровни доступа и описание оформляются в
виде таблицы 7.
Таблица 7
Уровни доступа пользователей АС
Класс объектов/
Свойство
Прикладной
программист
Оператор
HOSTS
HostIpAddress
RIUD
RIU
HostName
RIUD
R
HostMACAddress
RIUD
RU
CheckMethod
RIUD
R
EVENTS
EventId
RIUD
R
HostIpAddress
RIUD
RIU
CheckTime
RIUD
R
Result
RIUD
RU
IsAccessible
RIUD
RU
В таблице 7 использованы следующие сокращения для операций,
которые проводятся с данными: R – чтение; I – добавление; U – обновление ; D
– удаление.
Как правило, конечные пользователи, не выполняют никаких операций с
автоматически сгенерированными значениями, сохраняемыми в базе данных.
36
2.3.2. Концептуальный уровень архитектуры БД
2.3.2.1. ре Инфологическая модель ре предметной области
Результаты ре анализа предметной ре области, представленные ре в виде
ре описания классов ре объектов и ре связей между ре ними, являются ре исходными
данными ре для построения ре инфологической модели ре предметной области.
Инфологическая ре модель в ре данной работе ре построена на ре основании
методологий ре Ричарда Баркера, ре представленной в ре ввиде ER-диаграммы. ре Далее
приводится ре краткое описание ре этой методологии.
Элементы ре методологии: класс ре объектов (сущность), ре свойство класса
ре объектов, опциональность ре свойств, мощность ре или тип, ре уникальный
идентификатор, ре опциональность и ре переносимость связей, ре супертип, подтип,
ре уникальность объектов ре из связей, ре арк.
Сущность ре изображается в ре виде блока ре с закругленными ре концами, внутри
ре которого строчными ре буквами записываются ре атрибуты, а ре заглавными – ре имя
сущности. ре Две сущности ре могут быть ре связаны между ре собой. Графическое
ре представление объектов ре и связей ре изображено на ре рисунке 10.
Рисунок ре 10 – ре Графическое представление ре классов объектов ре и
связей
Связи ре представляют информационные ре потребности и ре правила бизнеса:
ре
Значения ре определённых атрибутов ре в какие-то ре моменты могут ре быть
недоступными ре или же ре вовсе отсутствовать. ре В таких ре случаях на ре схеме ставится
- ре обязательная связь ре – должна ре быть;
- ре необязательная связь ре – может ре быть;
- ре один или ре более – ре «воронья ре лапа»;
- ре один и ре только один.
КО ре 1
КО ре 2
37
ре латинская «o» ре перед именем ре атрибута, что ре говорит о ре необязательности атрибута
ре (optional).
Те ре атрибуты, которые ре имеют перед ре своим именем ре значок «*» ре всегда
имеют ре известные значения.
Каждая ре сущность может ре иметь несколько ре различных способов ре особой,
уникальной ре идентификации. Один ре из способов ре состоит в ре том, чтобы ре обозначить
те ре атрибуты, которые ре бы составляли ре уникальный идентификатор ре в виде
ре символа решётки ре («#»), а ре также в ре том, чтобы ре перечеркнуть все ре входящие связей
ре в этот ре уникальный идентификатор.
Те ре элементарные правила, ре применяемые для ре построения схем,
ре направлены на ре облегчение их ре чтения и ре доступности к ре восприятию
пользователями, ре а также ре повышение их ре качества и ре точности. Необходимо
ре стремиться к ре тому, чтобы ре блоки на ре схемах были ре выстроены в ре ряд, а ре линии
связей ре были по ре возможности прямые, ре вертикальные или ре горизонтальные.
Пересечения ре линий должны ре быть сведены ре к минимуму. ре Если же ре пересечений
избежать ре не удается, ре то необходимо, ре чтобы линии ре пересекались под ре углом 30-
60 ре градусов, тем ре самым облегчая ре зрительное восприятие. ре Также необходимо
ре следить за ре тем, чтобы ре в одной ре схеме не ре было нагромождения ре большого
количества ре элементов с ре расположенными близко ре друг к ре другу параллельными
ре линиями, ведь ре за такими ре связями крайне ре трудно следить. ре В таком ре случае
необходимо ре между блоками ре оставлять больше ре свободного места, ре чтобы у
ре пользователя не ре возникало ощущения ре тесноты. Чтобы ре придать схеме ре изящный
вид, ре можно изредка ре пользоваться диагональными ре линиями. Нужно ре постараться
сделать ре так, чтобы ре разветвляющийся конец ре («воронья лапа») ре связи находился
ре сверху или ре в левой ре части линии ре связи. Как ре выяснилось, это ре существенно
повысит ре точность модели, ре так как ре модель при ре этом читалась ре бы от ре тех
сущностей, ре что встречаются ре наиболее часто ре в сторону ре более редких. ре Каждый из
ре нас при ре просмотре схемы ре проводит глазами ре слева направо ре и сверху ре вниз, так
ре что такой ре вариант расположения ре информации совпадает ре с естественным ре путём
её ре восприятия. Также ре этому способствует ре тот факт, ре что те ре сущности, которые
38
ре встречаются наиболее ре редко, находятся ре в нижнем ре правом углу ре схемы и
ре являются особо ре важными, так ре как их ре используют другие ре объекты для ре своего
описания. ре При прочтении ре схемы по ре направлению к ре таким сущностям ре можно
определять ре остальные сущности ре через связи, ре которые существуют ре между ними.
Не ре имеют особого ре значения как ре размеры, так ре и форма ре блоков. Если ре это
необходимо ре с целью ре обеспечить большую ре наглядность представления, ре блоки
могут ре быть вытянуты, ре увеличенны или ре сжаты.[10]
Полученная ре инфологическая модель ре предметной области ре представлена
на ре рисунке в ре приложении А.
2.3.2.1. ре Даталогическая модель ре БД
На ре основании ER-диаграммы ре нотации Ричарда ре Баркера, представленной
ре на рисунке ре 10, была ре получена логическая ре структура. Даталогическая ре модель
базы ре данных приведена ре на рисунке ре 11.
Приведенная ре схема соответствует, ре как минимум, ре ЗНФ, поскольку
ре атрибуты во ре всех отношениях ре атомарные, первичные ре ключи не ре составные и
ре отсутствуют транзитивные ре зависимости между ре не ключевыми ре атрибутами и
ре первичными ключами, ре следовательно, может ре в достаточной ре мере обеспечить
ре целостность данных.
Рисунок ре 11 – ре Даталогическая модель ре базы данных
39
2.3.3. ре Внутренний уровень ре базы данных
Программные ре коды (SQL-скрипты) ре проектируемых объектов ре базы
данных ре разрабатываемой автоматизированной ре информационной системы
ре приведены в ре Приложении Б.
Реляционные ре таблицы БД ре приведены в ре таблицах 8 ре и 9.
Таблица 8
Реляционная таблица «Hosts»
Имя поля
HostIpAddr
ess
HostNam
e
HostMACAddres
s
CheckMetho
d
Ключ
ПК
Тип, длина
char(255)
char(255)
char(255)
char(255)
Обязательность
знач
NotNull
NotNull
Логическое
ограничение на
поле
Пример данных
192.168.0.1
laptop
FF:FF:FF:FF:FF:FF
Ping
Таблица 9
Реляционная таблица «Events»
Имя поля
EventId
HostIpAddr
ess
CheckTime
Result
IsAccessib
le
Ключ
ПК
Тип, длина
counter
char(255)
datetime
char(255)
bool
Обязательност
ь значения
NotNull
NotNull
NotNull
NotNull
0/1
Логическое
ограничение
на поле
Check
(>0)
Check
(0/1)
Пример
данных
666
192.168.0.1
01.01.18
00:00
Success
True
2.3.4. Реализация мероприятий по защите данных
2.3.4.1. Технология создания объектов БД. Поддержка целостности данных
В первую очередь необходимо разработать структуры хранения сетевых
узлов. В автоматизированной информационной системе контроля доступности
сетевого оборудования такой структурой будет являться таблица «Hosts». Далее
разрабатывается таблица «Events», в которую будут записываться все
происходящие события.
40
СУБД поддерживает стратегию поддержки ссылочной целостности
(запрещение удаления строк главной таблицы, замена значения внешнего
ключа подчиненной таблицы на определенное ранее значение и др.).
Реляционной базе данных присущи два вида ограничений: ограничения,
накладываемые самой реляционной моделью данных, и ограничения
предметной области.
Ограничения реляционной модели – это:
– целостность реляционного отношения. Реляционное отношение
должно иметь первичный ключ и его значение должно быть определено.
Первичный ключ – это поле или совокупность полей, значения которых
являются уникальными в пределах одной таблицы. Эти ограничения
реализуются в командах создания и модификации таблиц. В СУБД для
описания первичных ключей используется конструкция Primary Key, для
описания уникальных полей – конструкция Unique, обязательность значений
полей задаётся конструкцией Not Null;
– ссылочная целостность. Значение внешнего ключа должно быть равно
значению соответствующего первичного ключа по связи, либо может быть не
определено. Ссылочная целостность, например, может нарушаться при
удалении строк в родительской таблице. Существуют различные стратегии
поддержки ссылочной целостности: связи между таблицами могут быть заданы
как путем явного описания внешних ключей в структурах таблиц, либо
ссылочная целостность может поддерживаться с помощью триггеров. В СУБД
связь между двумя таблицами задается при помощи конструкции Foreign Key.
2.3.4.3. Резервное копирование и восстановление БД
При эксплуатации программного средства предполагается логическое
резервное копирование БД. Данный вид резервного копирования позволяет
экспортировать всю базу, заданные схемы или таблицы. При экспорте всей
базы выполняется так называемый полный экспорт (при этом экспортируются
41
все таблицы базы данных) или инкрементный (выгружаются таблицы,
изменившиеся с момента последнего экспорта).
При создании резервной копии БД и восстановлении БД необходимо
учитывать тот факт, что все эти операции требуют немалое количество
свободного места на жестком диске. Предполагаемый объем ежедневной
инкрементальной резервной копии: до 1 Гб.
2.4. Разработка алгоритмов
На рисунке 12 представлена укрупненная схема алгоритмов
автоматизированной системы.
Рисунок 12 – Укрупнённая схема алгоритма АС