курсовая приближенно по серверам. Удаленные программные средства первичной
 Скачать 2.16 Mb.
|
|
Название системы Способ передачи данных Вид передаваемых данных StatsD Push JSON Prometheus Push/Pull JSON Ganglia Push CSV/JSON Таблица 2 – Функциональный аспект сравнительного анализа Название системы Поддержка анализа данных Поддерживаемые типы событий Возможность создавать типы событий StatsD - 5: «Gauge», «Counter», «Timer», «Histogram», «Meter» - Prometheus + 4: «Counter», «Gauge», «Histogram», «Summary» - Ganglia + 3: «Counter», «Timer», «Gauge» - 15 В ходе проведения сравнительного анализа было выявлено, что все рассмотренные аналоги имеют поддержку Push-метода обмена сообщениями вида JSON. Prometheus также имеет поддержку Pull-метода обмена сообщениями. Ganglia поддерживает обмен сообщениями вида CSV. Prometheus и Ganglia имеют модули анализа данных. Однако все три сервиса поддерживают только ограниченную коллекцию типов событий, что накладывает ограничение на область их применения. 1.3 Постановка задачи на разработку Целью выпускной квалификационной работы является разработка удаленных программных средств (ПС) первичной обработки и передачи сообщений в составе платформы журнализации. Система доставки сообщений должна быть спроектирована с использованием клиент-серверной архитектуры. Для ПС необходимо разработать API для взаимодействия с сервером. Разработку системы осуществить с применением объектно- ориентированного языка программирования высокого уровня с кроссплатформенной реализацией. Данную систему предполагается использовать в качестве сервера доставки сообщений в составе платформы журнализации EventPlatform. Основной целью разрабатываемого программного комплекса является обеспечение надежного канала связи между удаленными подсистемами и журналом сообщений, используемым при дальнейшем анализе поступающей информации. Компоненты данной платформы включают в себя сервер приема и обработки сообщений и API для прикладных систем. Требуется спроектировать сетевой протокол для обмена данными между API и сервером приема сообщений. Так как система, над которой производится наблюдение, не определена – то формат сообщения должен быть максимально прост, гибок и 16 его формирование не должно требовать большого количества вычислительных ресурсов. Предпочтительно использовать общедоступный формат сериализации сообщения для как можно большего охвата операционных систем и устройств для наблюдения. В связи с сетевой направленностью разрабатываемого комплекса программных средств необходимо уделить должное внимание сохранности передаваемых данных для исключения компрометации и изменения информации в процессе пересылки. Защита может быть обеспечена протоколом SSL (англ. Secure Sockets Layer — уровень защищенных cокетов) или TLS (англ. Transport Layer Security — безопасность транспортного уровня). В целях обеспечения приемлемой скорости приема и обработки сообщений требуется использовать асинхронную модель обработки данных. Сообщения необходимо выгружать в журнал сообщений EventPlatform на основе СУБД InterSystems Cache. Программное средство должно работать под управлением операционных систем (ОС) Windows 7/8/8.1/10 и ОС Linux. Требуется уделить особое внимание отказоустойчивости платформы. Платформа должна сохранять работоспособность и обеспечивать восстановление функций в случае отказа или временной недоступности сервера журнализации. Отказ или ошибка в обработке сообщений от одной прикладной системы не должны влиять на работу других цепочек обработки сообщений. Так как к серверу журнализации EventPlatform может подключаться неограниченное количество экземпляров платформы, то необходимо позаботиться о снижении нагрузки с сервера. Одним из возможных вариантов снижения нагрузки может являться агрегация входящих сообщений по каким-либо признакам. 17 Готовый продукт должен иметь документацию пользователя. Правильность работы программного средства должна проверяться как с помощью юнит-тестов, так и с помощью ручного тестирования. Разработка программного средства должна происходить с использованием модульных тестов, проверяющих работу системы с различными тестовыми наборами данных. Необходимо обеспечить как можно большее покрытие кода юнит-тестами. Для проверки корректного выполнения задач в режиме ручного тестирования должен быть разработан пример прикладной системы, отправляющей различные типы сообщений. Ручное тестирование программного средства должно осуществляться путем выполнения тестовых примеров и сравнения выходных данных с ожидаемыми результатами. 1.4 Планирование разработки и оценки бюджета 1.4.1 Планирование разработки проекта Для планирования разработки проектов отлично подходит диаграмма Ганта. Диаграмма Ганта до сих пор остается важным инструментом управления. Она обеспечивает графическое отображение плана работ, удобное для контроля и отслеживания прогресса выполненных задач [6]. Диаграмма Гантта (англ. Gantt chart, также ленточная диаграмма, график Гантта, календарный график) — это популярный тип столбчатых диаграмм (гистограмм), который используется для иллюстрации плана, графика работ по какому-либо проекту. Является одним из методов планирования проектов. Используется в приложениях по управлению проектами [6]. На данном этапе была построена диаграмма Ганта, отображенная на рисунке 2. 18 Рисунок 2 – Диаграмма Ганта Из построенной диаграммы видно, что основную часть разработки проекта составляют кодирование и тестирование. 1.4.2 Функционально-стоимостной анализ разработки проекта Функционально-стоимостной анализ предназначен для описания существующих процессов в некоторой области, взаимодействий объектов, участвующих в таких процессах и расчета стоимости процессов. Методология и графическая нотация IDEF0 описывает один из способов формализации и описания бизнес-процессов. Существует множество специальных программных пакетов для анализа и построения диаграмм; в данной работе использовалась программная среда для построения диаграмм AllFusion Process Modeler r7 (также известная как BPWin). На рисунке 3 представлена контекстная диаграмма бизнес-процесса «Выполнение дипломного проектирования» и определена его стоимость. Для дальнейшей формализации процесса «Дипломное проектирование» необходимо провести его декомпозицию. Результаты декомпозиции изображены на рисунке 4. В процессе проектирования было выделено шесть составляющих бизнес-процессов: «Анализ существующих систем», «Анализ технического задания», «Проектирование», «Разработка и написание ПЗ», «Тестирование» и «Защита». Для каждого процесса были определены статьи затрат и стоимость проведения процесса. 19 Рисунок 3 – Контекстная диаграмма «Дипломное проектирование» Рисунок 4 – Диаграмма декомпозиции процесса «Дипломное проектирование» 20 Был проведен анализ затрат времени на каждый этап для одного работника. Работник выступает в качестве системного аналитика, разработчика и тестировщика программного обеспечения. Основные средства были затрачены на этапах анализа и разработки, т.к. на данных этапах использовалось платное программное обеспечение. Результаты вычислений представлены в таблице 3. Таблица 3 – Результаты функционально-стоимостного анализа Этапы Израсходовано средств Анализ предметной области и постановка задачи 6150 руб Анализ требований на разработку 4700 руб Разработка ПО 7850 руб Тестирование 2800 руб Предзащита 0 руб Итого: 21500 руб В итоге на разработку удаленных программных средств сервера первичной обработки и передачи сообщений для платформы журнализации EventPlatform было затрачено 21500 руб. 21 2 Анализ требований к программным средствам 2.1 Архитектура программных средств платформы журнализации Платформа журнализации включает в себя следующие элементы: ー прикладная система; ー сервер обработки сообщений; ー сервер журнализации; ー портал управления. Сервер обработки сообщений, соединившись с прикладными системами, принимает от них сообщения согласно протоколу по сокету. Инициатором данного соединения может быть как прикладная система, так и сам сервер обработки сообщений. Далее после первичной обработки сообщений данным сервером и установления соединения с БД журнала событий сообщение через интерфейс БД записывается в БД. Параллельно с вышеописанным процессом клиенты портала управления могут отправлять запросы серверу CSP согласно протоколу прикладного уровня HTTP и получать обработанные данные из БД в формате HTML. На рисунке 5 изображена диаграмма развертывания программного средства в нотации UML. Данная диаграмма учитывает взаимосвязи между объектами программного средства и внешними системами. Также данная диаграмма отображает размещение компонентов программного средства относительно физических ЭВМ. Диаграмма развертывания отражает наиболее типичный сценарий развертывания платфомры, однако возможен вариант, когда любая комбинация систем (в том числе все системы сразу) работает на одной физической ЭВМ. 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 простых устройствах, таких, как микроконтроллеры – при этом не лишая систему возможности описывать сложные структуры данных благодаря выразительности формата и наличию возможности описания всех основных структур данных. Также благодаря свободной структуре сообщений нет необходимости заново конфигурировать сервер при добавлении нового типа сообщения – прием сообщений нового типа будет работать сразу после добавления типа сообщения на сервер журнализации сообщений. В разрабатываемых программных средствах представление сообщения будет использовать только структуры данных «хэш-массив» и «строка» в связи с ограничениями сервера журнализации. Количество пар ключ:значение в сообщении не ограничено. |