Файл: Удаленные программные средства первичной.pdf

44
Таблица 8 – Свойства класса SettingsStorage
Название свойства
Тип свойства
Описание свойства
ConnectionString string
Хранит строку подключения к БД журнала событий
AppSocketPort uint
Хранит номер порта TCP сокета
Instanse
SettingsStorage
Содержит конфигурацию сервера обработки сообщений, извлеченную из XML-файла
PassiveComponents string
Хранит информацию о компонентах
ПС, работающих в режиме push
Таблица 9 – Методы класса SettingsStorage
Название метода
Параметры
Описание метода
SettingsStorage отсутствуют
Конструктор класса SettingsStorage
Load отсутствуют
Производит загрузку конфигурации сервера обработки сообщений из
XML-файла
Save отсутствуют
Сохраняет конфигурацию сервера обработки сообщений в XML-файл
Таблица 10 – Свойства класса ServerSocket
Название свойства
Тип свойства
Описание свойства
_actor
IActorRef
Хранит актор сервера
_listener
TcpListener
Хранит слушателя TCP сокета
_cancelsrc
CancellationTokenSOurce Хранит объект, отвечающий за разрыв соединения

45
Таблица 11 – Методы класса ServerSocket
Название метода
Параметры
Описание метода
ServerSocket actor:IActorRef
Хранит строку подключения к БД журнала событий ep: IPEndPoint
Start uint
Хранит номер порта TCP сокета
Stop
SettingsStorage
Содержит конфигурацию сервера обработки сообщений, извлеченную из XML-файла
AcceptConnections string
Хранит информацию о компонентах
ПС, работающих в режиме push
Таблица 12 – Свойства класса ServerSocketActor
Название свойства
Тип свойства
Описание свойства
_ep
IPEndPoint
Хранит IP-адрес и номер TCP- порта сервера обработки сообщений
_ssock
ServerSocket
Хранит сокет сервера обработки сообщений
Таблица 13 – Методы класса ServerSocketActor
Название метода
Параметры
Описание метода
ServerSocketActor ep: IPEndPoint
Конструктор класса
ServerSocketActor
Handle message:TcpClient
Обработчик события установления соединения по TCP сокету
Handle message:bool
Обработчик события получения сообщения об успешном подключении

46
Диаграмма классов наглядно показывает отношения наследования, однако вследствие минимальной связанности акторов не видны взаимодействия между классами. Для отслеживания взаимодействий между акторами и вспомогательными классами требуется построить диаграмму последовательности (Sequence Diagram в нотации UML).
На диаграмме 12 изображена последовательность действий при запуске системы акторов. Видно, как корневой актор Server обращается к хранилищу настроек, и в случае успешной их загрузки инициализирует актор сокета
ServerSocketActor, принимающего входящие соединения и соединение с БД.
Актор сокета в свою очередь инициализирует класс сокета ServerSocket, который служит прокси-объектом между низкоуровневыми соединениями и системой акторов. В случае успешного соединения выводится сообщение, уведомляющее о готовности сервера к приему входящих соединений.
Рисунок 12 – Диаграмма последовательности «Запуск сервера»

47
После процесса инициализации сервер входит в свое основное состояние ожидания соединений. Следующей активностью является подключение компонента системы к серверу. Данная активность имеет две разновидности в зависимости от режима обмена сообщениями между компонентом системы и сервером сообщений. Данная активность описана
UML-диаграммами на рисунках 13-14. На рисунке 13 описана активность для режима pull. На рисунке 14 – для режима push.
Рисунок 13 – Диаграмма последовательности «Соединение в режиме pull»
Рисунок 14 – Диаграмма последовательности «Соединение в режиме push»
Данная диаграмма отображает последовательность действий при приеме подключения к серверу. Цепочка акторов создает новый актор

48
AppSocketActor, который в свою очередь создает прокси-класс AppSocket и передает ему принятое соединение. AppSocket производит идентификацию подключенного компонента и проверяет версию протокола, при прошествии всех проверок начинается обработка запросов от компонента ПС. Для каждого подключения создается своя пара AppSocket и AppSocketActor. В случае провала проверок соединение закрывается, а актор AppSocketActor и принадлежащий ему прокси-класс уничтожаются.
В текущем состоянии компонент может отправлять сообщения или отправить запрос на защиту соединения. В запросе на защиту соединения участвует лишь компонент системы и класс AppSocket; при этом процессе не производится никаких сложных действий. Процесс приема сообщения более сложен; его диаграмма последовательности представлена на рисунке 15.
Рисунок 15 – Диаграмма последовательности «Прием сообщения»
При приеме сообщения оно проходит через два фильтра: прием сообщений только при защищенных соединениях (зависит от настройки) и упомянутый ранее фильтр алгоритма «текущего ведра». Далее сообщение отправляется актору-родителю класса AppSocket, где сообщение проходит

49 десериализацию (т.е. разбор принятой строки и формирование объекта). Для объекта создается новый прокси-класс Event, который заполняется данными принятого сообщения и отправляется в базу данных сервера журнализации с помощью метода Commit прокси-класса. Дальнейшая обработка сообщения проходит на сервере журнализации, а прокси-объект уничтожается из памяти при срабатывании сборщика мусора. В случае разрыва соединения или отсутствия доступа к объекту класса ActualEvent обрабатывается исключение, и запись последующих сообщений производится в лог файл.

3.2.2 Разработка API для прикладных систем
Вторым этапом разработки данного программного средства является разработка программного интерфейса (API) для подключения компонентов прикладных систем. Данный интерфейс разрабатывается в виде легковесной библиотеки на языке C#, которую можно подключать из внешних приложений. Важно, что все публичные методы этого API должны быть задокументированы для удобства интеграции.
В задачи разрабатываемого интерфейса входит обеспечение обмена информацией между компонентом и сервером обработки сообщений. Все методы должны быть синхронными для лучшего встраивания в уже существующую структуру приложения компонента – обеспечение асинхронности действий ложится на плечи разработчиков самого компонента. Разрабатываемый интерфейс должен быть достаточно низкоуровневым для гибкой работы с ним– но не должен перегружать программиста компонента внутренней логикой работы. Интерфейс был разработан в соответствии с требованиями.
Программный интерфейс состоит из одного подключаемого класса
EvCommunication, который управляет соединением с сервером. Настройка соединения происходит в конструкторе класса с помощью параметров, переданных конструктору. При режиме pull конструктору класса передаются

50 адрес сервера обработки сообщений и кодовое имя компонента системы. При режиме push – номер TCP-порта компонента прикладной системы и кодовое имя компонента системы. Соединение производится методом Open, который вызывается конструктором класса. Метод EncryptConnection отвечает за инициализацию шифрования соединения. Данный метод в качестве аргумента принимает IP-адрес и TCP-порт сервера обработки сообщения в формате строки. Отправка сообщения реализуется в методе SendMessage.
Аргументом данного метода является строка сообщения. Все свойства класса
EvCommunication описаны в таблице 14.
Таблица 14 – Свойства класса EvCommunication
Название свойства
Тип свойства
Описание свойства
_sr
StreamReader
Читает символы из потока
_sw
StreamWriter
Записывает символы в поток
_stream
Stream
Хранит поток символов
_client
TcpClient
Служит для установления соединения в режиме pull
_listener
TcpListener
Служит для установления соединения в режиме push
_client_mode bool
Определяет режим обмена сообщениями (true - режим pull, false - режим push)
Для описания взаимодействия API с другими программными средствами была построена диаграмма последовательности в нотации UML.
Диаграмма последовательности работы с API изображена на рисунке
16. Данная диаграмма покрывает все варианты использования API: от создания и опционального шифрования соединения до закрытия соединения.
Закрытие соединения также опционально и не должно проводиться после отправки каждого сообщения; при завершении родительского процесса соединение завершится автоматически.

51
Рисунок 16 – Диаграмма последовательности API
Принимаемое сообщение сериализуется самим компонентом, так как встроенная библиотека сериализации в формат JSON может не поддерживать всех опций, необходимых для конкретного объекта – и в таком случае разработчик компонента будет вынужден отказаться от использования системы.
3.2.3 Реализация проекта программных средств
После разработки архитектуры программное средство сервера приема и обработки сообщений было закодировано с использованием языка C# в среде разработки MonoDevelop 5.9. Программное средство было реализовано в виде подключаемой библиотеки для разделения реализации пользовательского интерфейса и самого сервера. На рисунке 17 приведена диаграмма компонентов программного средства.

52
Рассмотрим диаграмму подробнее. Так как данная часть реализации содержит только логическую часть, то весь код программного средства содержится в файлах исходного кода языка C# с расширением «.cs». Для соблюдения чистоты кода каждый класс программного средства за исключением прокси-классов, сгенерированных утилитой Cache Managed
Provider for .NET был выделен в отдельный файл исходного кода.
Рисунок 17 – Диаграмма компонентов ПС сервера приема и обработки сообщений
Компоненты программного средства включают в себя:
ー
EvServerSystem.dll – подключаемую библиотеку данного ПС;
ー
Base.cs – файл с модулем-интерфейсом к системе акторов;
ー
Server.cs – файл класса корневого актора Server;
ー
SettingsStorage.cs
– файл класса хранилища настроек
SettingsStorage;
ー
ServerSocketActor.cs – файлкласса ServerSocketActor;
ー
ServerSocket.cs – файлкласса ServerSocket;
ー
EventClass.cs – файлпрокси-классов Cache Managed Provider for
.NET, содержащийклассы Event, EventContext икласс KeyValuePair;
ー
DBConnection.cs – файлклассасоединениясБД DBConnection;

53
ー
AppSocketActor.cs – файлкласса AppSocketActor;
ー
AppSocket.cs – файлкласса AppSocket.
3.3 Разработка панели управления для сервера обработки
сообщений
Для удобного управления сервером обработки сообщений требуется разработать панель управления.
Панель управления позволяет пользователю (администратору ПС) управлять состоянием сервера обработки сообщений, просматривать и изменять конфигурацию соединения с БД и компонентами ПС, а также отслеживать статистику работы сервера.
Пользовательский интерфейс панели управления состоит из 4-х вкладок:
ー
«Сервер» – содержит элементы для управления состоянием сервера (рисунок 18);
ー
«Компоненты» – позволяет управлять соединениями с компонентами ПС (рисунок 19);
ー
«Соединение» – включает в себя элементы управления конфигурацией соединения с сервером БД журнала событий (рисунок 20);
ー
«Статистика» – отображает статистику работы сервера обработки сообщений (рисунок 21).

54
Рисунок 18 – Вкладка «Сервер» панели управления сервером обработки сообщений
Рисунок 19 – Вкладка «Компоненты» панели управления сервером обработки сообщений

55
Рисунок 20 – Вкладка «Соединение» панели управления сервером обработки сообщений
Рисунок 21 – Вкладка «Статистика» панели управления сервером обработки сообщений
В нижней части диалогового окна панели управления расположены кнопка для сброса настроек сервера обработки сообщений к заводской конфигурации и кнопка применения внесенных изменений. Обработчики нажатия данных кнопок после успешного исполнения своих инструкций

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

57
4 Тестирование
4.1 Выбор методологии тестирования
Тестирование программного обеспечения – процесс выявления ошибок в программном обеспечении (ПО). Существующие на сегодняшний день методы тестирования ПО не позволяют однозначно и полностью устранить все дефекты и ошибки и установить корректность функционирования анализируемой программы особенно в закрытых частных программах.
Поэтому все существующие методы тестирования действуют в рамках формального процесса проверки исследуемого или разрабатываемого ПО.
Такой процесс формальной проверки или верификации может доказать, что дефекты отсутствуют, с точки зрения используемого метода – то есть нет никакой возможности точно установить или гарантировать отсутствие дефектов в программном продукте с учетом человеческого фактора, присутствующего на всех этапах жизненного цикла ПО.
Существует множество подходов к решению задачи тестирования и верификации ПО, но эффективное тестирование сложных программных продуктов – это процесс в высшей степени творческий, не сводящийся к следованию строгим и четким процедурам или созданию таковых.
Одними из таких подходов к тестированию являются методологии компонентного/модульного тестирования и методология функционального тестирования. Для тестирования разработанных программных средств было принято решение использовать методологии компонентного и функционального тестирования.
Компонентное
(или модульное) тестирование проверяет функциональность и ищет дефекты в частях приложения, которые доступны и могут быть протестированы по-отдельности (модули программ, объекты, классы, функции и т.д.). Обычно компонентное (модульное) тестирование