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

22
Рисунок 5 – Диаграмма развертывания «EventPlatform»
Стоит отметить, что физическое расположение элементов платформы никак не влияет на их работу.
2.2 Функциональные требования
Для проектирования приложения необходимо использовать диаграммы нотации UML.

23
Язык графического описания UML (англ. Unified Modelling Language, язык унифицированного моделирования) представляет собой общецелевой язык графического описания моделей, который разработан для спецификации, визуализации, проектирования и документирования компонентов программного обеспечения, бизнес-процессов, взаимодействий объектов системы и других систем. UML призван поддерживать процесс моделирования программных средств на основе объектно-ориентированного подхода, организовывать взаимосвязь концептуальных и программных понятий и отражать проблемы масштабирования сложных систем. Модели языка UML используются на всех этапах жизненного цикла ПС, начиная с бизнес-анализа и заканчивая сопровождением системы. Различные организации могут применять UML по своему усмотрению в зависимости от своих проблемных областей и используемых технологий.
С точки зрения методологии объектно-ориентированного анализа и проектирования достаточно полная модель сложной системы представляет собой определенное число взаимосвязанных представлений (views), каждое из которых адекватно отражает аспект поведения или структуры системы.
Принцип иерархического построения моделей сложных систем предписывает рассматривать процесс построения моделей на разных уровнях абстрагирования или детализации в рамках фиксированных представлений
[7]. Любой язык состоит из словаря и правил комбинирования слов для получения осмысленных конструкций. Отличительной его особенностью является то, что словарь языка образуют графические элементы. Каждому графическому символу соответствует конкретная семантика, поэтому модель, созданная одним разработчиком, может однозначно быть понята другим, а также программным средством, интерпретирующим UML. Словарь языка
UML включает три вида блоков:
ー сущности – это абстракции, являющиеся основными элементами модели;

24
ー отношения – части, связывающие различные сущности;
ー диаграммы – блоки, группирующие представляющие интерес совокупности сущностей.
Диаграммы UML повышают сопровождаемость проекта и облегчают разработку документации к программной системе. UML может быть применен на всех этапах жизненного цикла анализа бизнес-систем и разработки приложений.
Для дальнейшего проектирования и разработки программного средства необходимо определить функциональные требования программных средств.
Для этого была составлена диаграмма вариантов использования в нотации
UML. Составление вариантов использования производится на основе анализа требований к ПС.
Главными актерами (англ. Actors) в контексте программного средства являются администратор сервера обработки сообщений и прикладная система.
Для запуска платформы необходима ее первоначальная настройка, которую производит администратор непосредственно перед запуском. При удачном запуске платформы к ней могут подключаться прикладные системы и отправлять сообщения. Однако для однозначной идентификации системы нужен какой-либо уникальный код, который система будет предъявлять платформе после подключения – что является еще одним вариантом использования (идентификация).
На рисунке 6 изображена готовая диаграмма вариантов использования сервера обработки сообщений при режиме обмена pull. На рисунке 7 изображена диаграмма вариантов использования ПС при режиме обмена push. Диаграммы представлены в нотации языка UML.

25
Рисунок 6 – Варианты использования «Режим pull»
Рисунок 7 – Варианты использования «Режим push»

26
Выделение вариантов использования облегчит процесс дальнейшего проектирования.
2.3 Выбор технологий и средств разработки
Для разработки ПО необходимо выбрать язык и среду разработки, как можно более подходящие для разработки данного типа программного обеспечения. После анализа ТЗ и предметной области язык C# был выбран как наиболее подходящий требованиям. В качестве среды разработки было решено использовать IDE Visual Studio 2013 Community как наиболее функциональную и надежную среду разработки, поддерживающую выбранный язык; среда MonoDevelop будет использоваться для отладки приложения при работе на базе ОС Linux и среды выполнения Mono.
Платформа .NET Framework — это технология, которая поддерживает создание и выполнение нового поколения приложений и веб-служб XML.
При разработке платформы .NET Framework учитывались следующие цели:
ー обеспечение согласованной объектно-ориентированной среды программирования для локального сохранения и выполнения объектного кода, для локального выполнения кода, распределенного в Интернете, либо для удаленного выполнения;
ー обеспечение среды выполнения кода, минимизирующей конфликты при развертывании программного обеспечения и управлении версиями;
ー обеспечение среды выполнения кода, гарантирующей безопасное выполнение кода, включая код, созданный неизвестным или не полностью доверенным сторонним изготовителем;
ー обеспечение среды выполнения кода, исключающей проблемы с производительностью сред выполнения сценариев или интерпретируемого кода;

27
ー обеспечение единых принципов работы разработчиков для разных типов приложений, таких как приложения Windows и веб- приложения;
ー разработка взаимодействия на основе промышленных стандартов, которое обеспечит интеграцию кода платформы .NET Framework с любым другим кодом [8].
В качестве платформы юнит-тестирования вместо стандартного фреймворка ( англ. framework — каркас) тестирования платформы Microsoft
VisualStudio используется фреймворк NUnit для обеспечения работы модульных тестов как под IDE Visual Studio, так и при использовании IDE
MonoDevelop.
2.4 Взаимодействие сервера обработки сообщений с
прикладными системами
2.4.1 Стратегия получения сообщений от прикладной системы
В процессе анализа аналогов было выявлено деление обозреваемых систем по стратегии отправки/получения сообщений. Перед дальнейшим проектированием системы необходимо оценить преимущества и недостатки каждой из них и выбрать наиболее подходящую.
Существуют две технологии (стиля) сетевой коммуникации – client pull
(англ. «вытягивание клиентом») и server push (англ. «проталкивание сервером»). Данные технологии определяют определяют стратегию распространения данных. В упрощенном виде можно сказать, что они определяют, по чьей инициативе происходит обмен данными между клиентом и сервером [9].
На данный момент pull-технология является более распространенной в сети Интернет. При ее использовании клиент инициирует передачу информации с помощью запроса, содержащего какие-либо параметры.

28
Самыми известными протоколами, работающими по этому принципу, являются протоколы HTTP (1 и 2 версии), FTP, DNS, POP3, SMTP и другие.
Данная технология наиболее подходит в случаях, когда адрес клиента неизвестен/нестабилен, когда клиент может находиться за межсетевым экраном (firewall) или когда клиенту требуется получить незначительную часть информации, содержащейся на сервере.
При использовании push-подхода инициатива исходит от сервера. Как правило, клиент соединяется с сервером и подписывается на определенные события. В некоторых реализациях сервер сам устанавливает соединение с клиентом (например, по такой стратегии действует система мониторинга
Prometheus). Однако минусы такого подхода перевешивают плюсы, т.к. не всегда изначально известны адреса и количество компонентов системы.
Также клиент может быть доступен непостоянно. В данном случае применение push-подхода приведет к возникновению очереди на стороне сервера, что замедлит его работу.
В контексте мониторинга pull-технология выглядит более привлекательной: для такой платформы отсутствие подключения к подсистеме само по себе является отдельным событием, которое легко отследить. Однако, в случае экстренного отключения подсистемы платформа мониторинга не зарегистрирует сообщения, сформированные между моментом последнего запроса и отключением системы.
В целом, для мониторинга больших, но стабильных систем (как с точки зрения доступности, так и топологии ее подсистем) лучше подходит pull- технология; во всех остальных случаях выигрывает push-подход.
После анализа было принято решение использовать pull-технологию, как основной механизм доставки сообщений. Однако push-технология также будет доступна в качестве альтернативы.

29
2.4.2 Выбор формата передаваемого сообщения
При проектировании программных средств было проанализировано несколько форматов сериализации и хранения данных, таких, как XML,
YAML, GOB, JSON, JSONB и других. После анализа в качестве формата передачи сообщений был выбран формат JSON.
JSON (англ. JavaScript Object Notation) – текстовый формат описания данных, изначально описанный в языке JavaScript. Данный формат предназначен для машинной обработки, однако может легко читаться людьми. JSON более лаконичен по сравнению с языком XML, поэтому он более подходит для описания сложных структур. Чаще всего этот формат используется в обмене данными между браузером и сервером в подходе
AJAX (англ. Asynchronous Javascript and XML), но не ограничен данной областью.
JSON-текст представляет собой одну из двух структур: набор пар ключ-значение (аналог объекта или хэш-таблицы) или упорядоченный набор значений (аналог массива/вектора). В качетсве значений могут выступать:
ー объект – неупорядоченное множество пар ключ:значение, заключенное в фигурные скобки;
ー одномерный массив – упорядоченное множество значений, заключенное в квадратные скобки;
ー значение – строка, число, объект, массив или один из литералов
(true, false, null).
Ключами объекта могут выступать только строковые значения, заключенные в двойные кавычки. Числа, в отличие от строковых значений, кавычками не закрываются; как правило, в дробных числах используется разделитель «точка».
Данный формат сообщения был выбран из-за его простоты и гибкости, которые позволят реализовать протокол отправки сообщений даже на самых

30 простых устройствах, таких, как микроконтроллеры – при этом не лишая систему возможности описывать сложные структуры данных благодаря выразительности формата и наличию возможности описания всех основных структур данных. Также благодаря свободной структуре сообщений нет необходимости заново конфигурировать сервер при добавлении нового типа сообщения – прием сообщений нового типа будет работать сразу после добавления типа сообщения на сервер журнализации сообщений.
В разрабатываемых программных средствах представление сообщения будет использовать только структуры данных «хэш-массив» и «строка» в связи с ограничениями сервера журнализации. Количество пар ключ:значение в сообщении не ограничено.

31 зашифрованного соединения. Фаза переговоров является первой фазой установления соединения, во время которой клиент и сервер договариваются о используемой версии протокола, обмениваются своими публичными ключами (цифровыми сертификатами) и генерируют общий секретный ключ для текущей сессии. Далее клиент посылает пакет ChangeCipherSpec, который обозначает вторую фазу установки соединения, начиная с которой обмен информацией производится по зашифрованному каналу. Клиент посылает сообщение, содержащее свой MAC-адрес и хэш, сгенерированный на основе предыдущих сообщений. Если серверу не удается расшифровать сообщение, то соединение прерывается. В ином случае сервер отвечает пакетом ChangeCipherSpec и пакетом Finished, после которого начинается обмен данными с помощью протоколов более высокого уровня.
В разрабатываемом проекте используется протокол TLS 1.2 как наиболее современный и безопасный на момент написания.
Так как не все наблюдаемые прикладные системы имеют достаточно вычислительных мощностей для поддержки шифрованного соединения, то передача данных открытым текстом поддерживается наряду с безопасным каналом. Такая поддержка возможна благодаря особенностям алгоритма
TLS, который позволяет не только создавать защищенные соединения, но и шифровать уже существующие. Для этого клиент должен отправить команду, обозначающую запрос на начало шифрования серверу. Команда определяется протоколом прикладной программы, в данном случае – протоколом сообщения между API и сервером обработки сообщений. Так как команда на начало шифрования может быть перехвачена и подавлена между прикладной системой и сервером, то на сервере должна быть настраиваемая опция, определяющая, разрешено ли принимать и обрабатывать незащищенные соединения. В случае установленного запрета первое входящее сообщение отбрасывается, а соединение закрывается.