Разработка и реализация программных средств для работы с веб-контентом в рамках проекта INTERIN PROMIS

Размещено на http://www.allbest.ru/

СОДЕРЖАНИЕ

ВВЕДЕНИЕ

1. АНАЛИТИЧЕСКИЙ ОБЗОР

1.1 Расширение возможностей браузера плагинами

1.2 Проксирование вызовов через теневую службу

1.3 Создание собственного веб-клиента

1.4 Анализ требований и выбор варианта решений

2. ПРОЕКТИРОВАНИЕ СТРУКТУРЫ СИСТЕМЫ

2.1 Основная идея модульного деления

2.2 Межмодульное взаимодействие

2.3 Проектирование ядра системы

2.4 Проектирование главного окна системы

2.5 Проектирования модуля печати

2.6 Допущения и ограничения

2.7 Структурная схема системы

2.8 Функциональная схема системы

3. РАЗРАБОТКА ОСНОВНЫХ УЗЛОВ СИСТЕМЫ

3.1 Среда разработки Qt Creator

3.2 Разработка ядра системы

3.3 Разработка модуля главного окна системы и модуля печати

4. ТЕСТИРОВАНИЕ СИСТЕМЫ

4.1 Инсталяция программы

4.2 Тестирование функциональной части программы

4.3 Тестирование модульной расширяемости

5. ВНЕДРЕНИЕ

ЗАКЛЮЧЕНИЕ

ПРИЛОЖЕНИЕ

ВВЕДЕНИЕ

Актуальность темы.

В эпоху бурного развития информационных технологий начался тот этап, который подразумевает не только информатизацию процессов производств, но и организацию защищенного доступа к ним из глобальной сети. Основным средством организации такого доступа являются веб-технологии. Самым популярным их воплощением является web-браузер. Такой подход позволяет создать не только интерактивный интерфейс пользователя, но и реализовать красивое оформление.

На рынке информационных технологий появилось много решений прикладных задач, таких как редакторы графических и текстовых файлов, web-браузеры, IP-телефония и другие. Для создания конкурентно способного приложения необходимо использовать эти технологии, иначе оно будет проигрывать как в функциональном плане, так и в интерфейсном. В данный момент на рынке нет подобных современных решений, где собраны различные части таких технологий.

Цель данной работы:

Целью данной работы является разработка идеи объединения сторонних решений и реализация многофункционального, легко масштабируемого приложения, в рамках проекта «Interin Promis».

Задачи работы:

1. Аналитический обзор предметной области и выбор средств разработки.

2. Разработка функциональной и структурной схемы программного средства.

3. Реализация основного модуля программы (Модуля отображения веб-страниц).

4. Реализация модуля печати и модуля обновлений. Создание инсталлятора приложения.

5. Изучение взаимодействия информационных технологий, методов их интеграции и обмена данными.

Научная новизна работы:

Новизна работы заключается в разработке технологии интеграции различных информационных решений. Данная идея заключается в объединении готовых сторонних разработок для получения многофункциональной системы, позволяющей динамически наращивать функционал.

Практическая значимость работы:

Практическая значимость работы заключается в универсальности предложенного решения.

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

Апробация работы.

Результаты работы используются в тестовом режиме в медицинском центре ООО «Клиника Говорово».

Публикации. Основные результаты диссертационного исследования изложены в статье «Кроссплатформенный клиент корпоративной информационной системы», опубликованной в выпуске №67 научного журнала «NovaInfo».

Выпускная квалификационная работа состоит из пяти разделов.

В первом разделе представлен аналитический обзор существующих методов реализации клиента информационной веб-системы и выбран способ его разработки.

Во втором разделе автором производится проектирование системы, предлагается модульный способ ее реализации, а так же представлены функциональная и структурная схемы программной системы.

В третьем разделе представлена реализация основных модулей системы, а так же дано описание среды разработки QtCreator.

В четвертом разделе представлены материалы функционального тестирования системы с представлением материала их выполнения.

В пятом разделе описывается процесс внедрения программной системы в рамках проекта «InterinPromis».

1. АНАЛИТИЧЕСКИЙ ОБЗОР

В эпоху бурного развития информационных технологий начался тот этап, который подразумевает не только информатизацию процессов производств, но и организацию защищенного доступа к ним из глобальной сети. Основным средством организации такого доступа являются веб-технологии. Самым популярным их воплощением является веб-браузер. Такой подход позволяет создать не только интерактивный интерфейс пользователя, но и красивое оформление.

Корпоративная веб-система - это совокупность технических и программных средств, позволяющая автоматизировать рабочие процессы предприятий, в основе которой лежит веб-архитектура.

Для организации работы МИС Интерин PROMIS одним из ключевых моментов является взаимодействие клиента (веб-браузера) с периферийными устройствами и операционной системы. Такое двухстороннее взаимодействие невозможно, используя стандартный браузер. Далее будут представлены возможные варианты организации двухстороннего взаимодействия веб-клиента и операционной системы, а так же подставлены достоинства и недостатки таких подходов.

1.1 Расширение возможностей браузера плагинами

Неоспоримым достоинством данного подхода является наличие уже отлаженного, хорошо работающего, обновляемого, поддерживающего все современные веб-технологии интернет-браузера, который разрабатывает и поддерживает команда профессиональных разработчиков. Однако нет никакого единообразия в написании плагинов, а количества интернет-браузеров достаточно велико, следовательно, поддержка такого решения будет очень трудоемка и дорога. Однако можно ограничить клиента в выборе браузера, что не является приемлемым решением для большой корпоративной системы. Используя данный подход, появляется прямая зависимость от разработчиков браузера, так как после его обновления могут отказать разработанные плагины.

Перечисленных выше недостатков достаточно, что бы говорить о невозможности использования браузера, расширенного плагинами, в качестве клиента большой корпоративной системы.

1.2 Проксирование вызовов через теневую службу

Прокси-сервер представляет собой «промежуточный» сервер, который выступает в роле своеобразного посредника между сайтом и браузером. Название этого сервера произошло от английского слова «proxy» - «уполномоченный, представитель» [1].

Прокси-серверы различаются в зависимости от конфигурации. Бывают открытые и закрытые прокси-серверы.

Открытым прокси-сервером может воспользоваться любой желающий. Такие промежуточные серверы помогают оказаться на сайтах, доступ к которым с конкретного IP-адреса может быть запрещенным по той или иной причине. Чтобы начать использовать данный сервер, пользователь должен сначала подключиться к нему (либо же зайти на определенный сайт), а после этого послать запрос, содержащий адрес необходимого ресурса. Получив необходимую команду от пользователя, прокси-сервер начинает подключаться к необходимому серверу, а затем он выдает результат запроса.

Закрытые прокси-серверы могут использоваться отдельными организациями. Они предназначены для того, чтобы обслуживать работников конкретного офиса и, например, запрещать доступ для этого офиса к каким-либо ресурсам.

Обрабатывая запросы пользователей, прокси-сервер или подключается к серверу, где находится искомый ресурс, или же ищет сайт в своем кеше, если такой имеется.

Добавление прокси-сервера позволит системе абсолютно не зависеть от вида интернет-браузера, а так же от его обновлений. Однако браузер должен поддерживать работу в веб-соккетом, что накладывает на него некоторые ограничения. Проксирование клиентских запросов позволит из java-скрипта выполнить любой метод любого класса, который объявлен внутри этого прокси-сервера. Для реализации такой цепочки нужно будет во все веб-страницы, в которых будет необходимо взаимодействие с операционной системой, добавлять специальный java-скрипт. Это ограничение не очень серьезное, поэтому особых проблем не вызывает, но написание этих скриптов становится более трудоемким, так-как разработчик должен расписывать то, что классическому java-скрипту не свойственно.

Поддержка оптимальная, только одно приложение. Однако стоит отметить недостаток - прокси-сервер должен работать как служба. В таком случае он будет не визуален, а следовательно будет невозможно взаимодействовать с пользователем напрямую, а только через скрипты на веб-странице.

Из недостатков, так же стоит отметить сложность изменения содержания веб-страниц, так как для этого придется делать дополнительный запрос к прокси-серверу и ждать его ответа.

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

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

1.3 Создание собственного веб-клиента

Web-браузер - это прикладное программное обеспечение для просмотра веб-страниц; содержания веб-документов, компьютерных файлов и их каталогов; управления веб-приложениями; а также для решения других задач [2].

В глобальной сети браузеры используют для запроса, обработки, манипулирования и отображения содержания веб-сайтов. Многие современные браузеры также могут использоваться для обмена файлами с серверами ftp, а также для непосредственного просмотра содержания файлов многих графических форматов, аудио-видео форматов, текстовых форматов и других файлов.

Функциональные возможности браузеров постоянно расширяются и улучшаются благодаря конкуренции между их разработчиками и высоким темпом развития и внедрения информационных технологий. Несмотря на то, что браузеры разных изготовителей базируются на разных технологических решениях, большинство современных браузеров придерживается международных стандартов и рекомендаций в области обработки и отображения данных. Стандартизация позволяет добиться предсказуемости в визуальном представлении информации конечному пользователю независимо от технологии, которая использована для её отображения в браузере.

При создании собственного веб-клиента (браузера) приходится работать с активно развивающимися мультимедийными технологиями, и, если получившийся браузер должен поддерживать все современные веб-технологии, то необходимо отслеживать все изменения в них. Такая поддержка значительно удорожит разработку, ведь даже создание простого клиента, который будет что-то отображать - это большая предварительная работа. Стоит отметить то, что поддержка приложения - это не цель, а всего лишь средство, на которое придется тратить много средств. Получается настолько дорогой инструмент, что он даже сопоставим с ценой самого продукта.

1.4 Анализ требований и выбор варианта решений

Разрабатываемая система предназначена для реализации клиентской части МИС (медицинской информационной системы) и обеспечивать взаимодействие МИС с операционной системой АРМа.

Целью разработки системы является обеспечение взаимодействия веб-приложений с операционной системой АРМ, сторонними программными продуктами и оборудованием.

Требования к структуре и функционированию системы:

1. Система должна функционировать под управлением ОС Windows, Linux, MacOS.

2. Система должна обрабатывать запросы пользователя и визуализировать результат (диалоговый режим).

3. Система должна обеспечивать защиту передаваемых по сети данных.

4. Система должны обеспечивать API для отображаемых веб-страниц по взаимодействию с клиенской ОС.

5. Система должна иметь модульную структуру состоящую из ядра системы (исполняемого файла) и библиотеки модулей. Каждый модуль отвечает за реализацию определенной группы функций и подключается к ядру системы динамически.

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

Самым подходящим вариантом в качестве клиента большой корпоративной системы является создание собственного клиента, однако это очень трудоемкий и дорогостоящий процесс. Его упрощает универсальная кроссплатформенная библиотека QT, которая позволит значительно это упростить.

Библиотека QT предназначена для разработки GUI, разработанная компанией Trolltech AS. Qt была представлена в 1996 году, с тех пор, с помощью этой библиотеки было создано большое количество разнообразных приложений с графическим пользовательским интерфейсом [3].

Qt является кроссплатформенной, есть реализации библиотеки для MS/Windows, Unix/X11 (Linux, Sun Solaris, HP-UX, Digital Unix, IBM AIX, SGI IRIX и пр.), Macintosh ( Mac OS X ) и Embedded платформ. Библиотека является объектно-ориентированной, базирующейся на компонентах и имеет богатое разнообразие различных визуальных элементов - виджетов (widgets), предоставляемых в распоряжение программиста.

Эта библиотека является безусловным лидером среди имеющихся средств разработки межплатформенных программ на языке C++. Широко известная и часто используемая в мире Linux, она, благодаря распространению графической оболочки KDE, стала де-факто стандартом проектирования программного обеспечения на этой платформе.

Достоинства библиотеки QT:

1. Кроссплатформенная разработка приложений.

2. Удобная работа со строками.

3. Поддержка оконного интерфейса.

4. Возможность работы с сетевыми протоколами.

5. Поддержка разработки сложных графических объектов.

6. Модульность библиотеки.

7. Обновляемость.

Таким образом, данная библиотека в своем составе уже имеет модуль

для работы с веб-контентом, который в свою очередь построен на базе chromium. Это позволит иметь современный и обновляемый инструмент, а модульная структура поспособствует легкому обновлению приложения.

2. ПРОЕКТИРОВАНИЕ СТРУКТУРЫ СИСТЕМЫ

Приступая к разработке сложной программной системы, следует принять меры для ее упрощения. Для этого такую программу разрабатывают по частям, которые называются программными модулями. А сам такой метод разработки программ называют модульным программированием.

Программный модуль - это любой фрагмент описания процесса, оформляемый как самостоятельный программный продукт, пригодный для использования в описаниях процесса [4]. Это означает, что каждый программный модуль программируется, компилируется и отлаживается отдельно от других модулей программы, и тем самым, физически разделен с другими модулями программы. Более того, каждый разработанный программный модуль может включаться в состав разных программ, если выполнены условия его использования, декларированные в документации по этому модулю. Таким образом, программный модуль может рассматриваться и как средство борьбы со сложностью программ, и как средство борьбы с дублированием в программировании.

В случае разработки большой корпоративной системы, модульный подход позволит не только упростить ее разработку, но и обеспечить легкость обновления. Таким образом, вся система будет состоять из набора отдельных программных модулей, подключая которые можно изменять функционал всех системы.

2.1 Основная идея модульного деления

Разрабатываемый клиент большой корпоративный системы использует множество технологии для реализации различных автоматизированных рабочих мест (АРМ). Он вынужден собирать различные информационные технологии для организации таких возможностей как:

1. Организация звонков с рабочих мест.

2. Просмотр файлов.

3. Мониторинг работы оборудования.

4. Работа с текстовыми документами.

Таким образом, получается, что для реализации всех возможностей

системы необходимо объединить все технологии и организовать их корректную работу. Если реализовать все модули в одном исполняемом файле, то при изменении одной из них придется пересобрать весь файл целиком, что значительно усложняет поддержку, разработку и обновление системы. Такой подход относительно прост в реализации, однако совершенно не подходит для большой корпоративной системы. Поэтому целесообразно разбить исполняемый модуль по технологиям и объектам. Это позволит разрабатывать компоненты отдельно друг от друга, что положительно скажется на поддержке и обновлении всей системы в целом.

2.2 Межмодульное взаимодействие

Для обеспечения работоспособности всех компонентов системы необходимо организовать связь модулей друг другом. Для этого применяют такие технологии как AciveX, элементы NativeAPI, подключение динамических библиотек (DLL) и другие.

Одним из требований к системе является ее кроссплатформенность, однако элементы AciveX и NativeAPI предназначены для работы только в операционных системах семейства Windows. Однако разработка с использование DLL библиотек позволяет получить платфомонезависимое приложение [5].

Динамически подключаемые библиотеки (DLL)

Библиотека DLL представляет собой коллекцию подпрограмм, которые могут быть вызваны на выполнение приложениями или подпрограммами из других библиотек. Подобно модулям, библиотеки DLL содержат разделяемый (sharable) код или ресурсы. Однако, в отличие от модулей, библиотеки содержат отдельно откомпилированный исполняемый код, который подключается к приложению динамически на этапе его выполнения, а не компиляции.

Для того чтобы библиотеки можно было отличить от самостоятельно выполняемых приложений, они имеют расширение .dll.

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

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

Использование динамических библиотек предлагает следующие преимущества:

Экономия памяти и уменьшение объема выгрузки. В случае использования динамических библиотек, несколько приложений одновременно получают доступ к одной библиотеке. При этом для использования библиотеки требуется хранение только одного экземпляра библиотеки в памяти системы. В случае же использования статичных библиотек операционная система должна для каждой программы, которой необходима данная библиотека, загрузить код библиотеки в память.

Экономия места на диске. В случае параллельного использования одной dll-библиотеки многими программами, на диске хранится только одна копия данной библиотеки. При использовании статических библиотек наоборот, для каждой программы создается отдельная копия данной библиотеки.

Удобство и простота изменения и обновления dll-библиотек. Если требуется провести изменение или корректировку dll-библиотеки, то после внесения изменений в библиотеку не придется проводить компиляцию или компоновку приложения, которое использует данную библиотеку, заново. Однако при использовании объектного кода статических библиотек придется проводить перекомпиляцию программы или снова проводить компоновку в случае даже небольших изменений.

Обеспечение длительной поддержки выпущенных в использование библиотек. Обеспечивается легкостью обновления и дополнения функционала библиотеки для расширения возможностей или для поддержки новых устройств.

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

Упрощение создания международных версий приложений. Легкость использования dll-библиотек позволяет облегчить процесс интернационализации программы, если, например, загрузить все строковые ресурсы, используемые программой, в dll-библиотеку. Соответственно версию для каждого языка размещаем в отдельной библиотеке, и подгружаем ресурсы той, язык которой необходим в данный момент.

Единственным крупным недостатком можно считать тот факт, что программа, использующая dll-библиотеку, не может иметь полный функционал в ее отсутствии.

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

1) соответствующая библиотека обновилась до новой версии;

2) внесены изменения в зависимую dll-библиотеку;

3) соответствующий dll-файл перезаписывался с более ранней версией;

4) соответствующий dll-файл не найден системой или удален с компьютера.

Обычно эти действия называются конфликтами dll-библиотек. Если не обеспечивается обратная совместимость, программа не может быть успешно запущена. Такие действия называют конфликтом dll-библиотек. Программа может быть успешно запушена и нормально использоваться только в случае обеспечения обратной совместимости [6].

Преимущества использования динамических библиотек (по сравнению со статическим подключением подпрограмм на этапе сборки приложения) следующие:

Процессы, которые загрузили библиотеку по одному и тому же базовому адресу, пользуются одной копией их кода, но имеют свои собственные копии данных. Благодаря этому снижаются требования к объему памяти и снижается своппинг.

Модификация подпрограмм библиотек не требует повторной компиляции приложений до тех пор, пока остается неизменным формат их вызова.

Библиотеки обеспечивают также послепродажную поддержку (after-market support). Например, дисплейный драйвер, предоставляемый библиотекой, может быть обновлен для того, чтобы поддерживать дисплей, который не существовал в момент продажи приложения.

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

Недостатком использования библиотек является то обстоятельство, что приложение не является самодостаточным и зависит от наличия отдельного файла(ов) библиотеки. В случае отсутствия статически загружаемой библиотеки система прерывает приложение и выводит сообщение об ошибке. В случае отсутствия динамически загружаемой библиотеки приложение не прерывается, но функции библиотеки являются, разумеется, недоступными для приложения.

Реализация межмодульного взаимодействия

При использовании собственных библиотек или библиотек независимых разработчиков придется обратить внимание на согласование вызова функции с ее прототипом. Для этого, еще на этапе проектирования модулей, стоит определить наличие обязательных для всех модулей функций. Они могут быть по-разному реализованы или вообще быть пустыми, но их наличие обязательно.

Такими функциями являются:

1. Init.

2. Start.

3. Stop.

4. About.

После загрузки каждого конкретного модуля в память, в функции Init размещается код для инициализации и создания используемых объектов, которые объявлены внутри DLL библиотеки. Функция About позволяет получить строку с описанием модуля и его функционала. Интерфейсная функция Start используется в тех случаях, когда загруженный модуль содержит исполняемый код, которому нужно передавать управление. Stop - это функция останавливает выполнение исполняемого кода. Если загруженная библиотека только предоставляет набор функций, то интерфейсные функции Start и Stop должны быть пустыми.

Поскольку разрабатываемая система отображает веб-страницы, то в подключаемых библиотеках могут быть как элементы управления (окна, виджеты, кнопки, и прочее), так и элементы меню, которые имеют собственные обработчики команд. Для этого в каждой библиотеке предусмотрено две структуры, которые инициализируются в методе Init, такие как: Get_actions и Get_widgets. Эти структуры возвращают список визуальных элементов управления и список обработчиков команд, которые присутствуют в библиотеке.

Для однозначного определения соответствия команды обработчика с функцией, которая его выполняет, нужно создать отдельную структуру. Эта структура содержит название всех команд и указатель на исполняемую функцию. Поскольку планируется, что систему будет расширяться, то и количество модулей будет только возрастать. Для их синхронизации необходимо создать отдельный модуль - ModuleManager, который будет хранить информацию по каждому модулю и указатели на исполняемые функции. Таким образом, когда к системе подключили модуль, затем дали ему команду Init, которая может, например, открыть вкладки или создать новое окно, то ModuleManager будет знать, как работать с обработчиками на новых компонентах.

Организация доступа к функциям

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

Абстрактный класс в объектно-ориентированном программировании - это базовый класс, который не предполагает создания экземпляров. Абстрактные классы реализуют на практике один из принципов ООП -- полиморфизм. Абстрактный класс может содержать абстрактные методы и свойства. Абстрактный метод не реализуется для класса, в котором описан, однако должен быть реализован для его неабстрактных потомков. Абстрактные классы представляют собой наиболее общие абстракции, то есть имеющие наибольший объём и наименьшее содержание [7].

Проблема доступа к функциям в различных библиотеках решена путем создания абстрактного класса AbstractInterface. В нем нет реализации ни одной функции, а только объявлены их прототипы. Этот класс является одним из предков для класса - модуля ядра системы (InterinClient). Таким образом, любой модуль может использовать функции в абстрактном классе для обращения к модулю ядра системы, а затем, используя менеджер модулей, обратится к функциям или визуальным компонентам, объявленным в другой библиотеке.

Основной причиной использования именно абстрактного класса является возможность объявления функций, реализация которых может находиться в а различных библиотеках. Если не использовать абстрактный функций, то, например, для реализации общесистемной возможности записи в лог, то придется добавить реализацию класса ЛОГ во все модули.

2.3 Проектирование ядра системы

Основным компонентов всей системы является ее ядро. Именно с этого модуля начинается логика работы программы. В реализации данной системы, ядро является не визуальным компонентом, поэтому его основные задачи:

1. Запуск ядра системы.

2. Проверка обновлений.

3. Получение обновлений.

4. Установка обновлений.

5. Инициализация библиотек.

6. Передача управления модулю главного окна.

Структурная схема ядра системы представлена на рисунке 2.1.

Основная идея ядра системы заключается в его окончательности. Оно реализовано таким образом, что для изменения логики работы всей системы не нужно будет вносить изменения в ядро. Такой подход позволят сразу прилучить готовое, отлаженное решение, для модификации которого нужно лишь изменить набор используемых библиотек.



Рисунок 2.1 - Структурная схема ядра системы.

Менеджер модулей

Менеджер модулей - это подсистема, которая реализована в виде класса. Она осуществляет загрузку модулей, их выгрузку, проверку необходимости обновления модулей, их загрузку и непосредственно обновление. Так же, менеджер модулей осуществляет получение информации о визуальных компонентах и обработчиках подключаемых библиотек.

Гланый цикл программы (Main Loop)

Главный цикл программы - это подсистема, реализуемая средствами библиотеки QT, а именно классом QAplication, но над ней выполнена надстройка для интеграции с подсистемой работы с параметрами. Ее основной задачей является обработка сообщений от операционной системы.

Подсистема работы с параметрами

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

Модуль логирования

Модуль логирования - это составная часть ядра системы, которая может работать с модулями и имеет в своем составе функционал для работы с лог файлами. Благодаря абстрактному классу, любая подключенная библиотека может вести лог независимо от её внутренней функциональности.

2.4 Проектирование главного окна системы

В разрабатываемой системе модуль главного окна является основным визуальным модулем, он обеспечивает работу с веб-контентом. Разработка с нуля такого модуля большая и трудная задача, но кроссплатформеннная библиотека Qt в своем составе уже имеет похожее решение. Оно называется «Demo Browser», Снимок экрана работы которого представлен на рисунке 2.2.

Рисунок 2.2 - Снимок экрана работы проекта «Demo Browser»

Данное решение является как кроссплатформенным, так и многофункциональным, а за работу с веб-контентом отвечает ядро CEF (Chrome Embedded Framework). Оно работает со всеми актуальными веб-протоколами, взаимодействует с java-скриптами, а так же имеет в своем составе инструментарий для организации канала связи «Webchannel». Поддерживает как оконную, так и вкладочную модель навигации по веб-страницам. Таким образом «Demo Browser» является отличным модульным решением, которое можно использовать в качестве основы для реализации модуля главного окна системы [8].

Chrome Embedded Framework

Chromium Embedded Framework (CEF) -- это проект с открытыми исходными кодами, созданный в 2008 году как элемент управления Web browser, работающий на базе Chromium от Google [9].

Основные возможности фреймворка:

1. CEF позволяет создать свои обработчики протоколов, таким образом, реализовать свой «закрытый» алгоритм шифрования. Этим же можно воспользоваться, чтобы подгружать данные из статических ресурсов программы.

2. CEF позволяет делать обертку над нативными функциями в пространстве объектов виртуальной машины Javascript. Ресурсоемкие операции по обработке больших массивов данных можно переложить на более строгие и быстрые языки программирования.

3. CEF позволяет обрабатывать события навигации, скачивания файлов и так далее.

2.5 Проектирования модуля печати

Модуль печати основан на стандартном классе QPrinter, позволяющем организовать обмен данными с принтером, и сторонней библиотеке Debenu PDF Library для работы с PDF файлами [10]. Над ней сделана надстройка, где все вызовы функции приведены к стандартному виду Qt.

Основные возможности Debenu PDF Library:

1. Обширный список функций.

2. Безопасность, подпись и защита PDF-файлов.

3. Создание, заполнение и редактирование PDF-формы.

4. Разделение, слияние, добавление и объединение PDF-файлов.

5. Преобразование EMF в PDF.

6. Извлечение текста и изображений из PDF-файлов.

7. Редактирование начального вида и свойств документов формате PDF.

8. Расширенная поддержка JavaScript, закладок.

10.Функция прямого доступа (загружает файлы с диска, а не из памяти).

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

2.6 Допущения и ограничения

Ни при каких условиях несовместимость продукта и модуля не должна приводить к падению того или другого. Проверка версий и совместимости должна проводиться своевременно и безопасно. Разработчиком должны строго выполняться правила ведения версии модуля и обеспечения механизма проверки версии и совместимости.

Модуль должен поддерживать программный механизм определения версии как минимум по соглашению мажорная/минорная версия. Мажорная версия библиотеки меняется (увеличивается) при изменениях интерфейсов или принципов работы, делающих библиотеку несовместимой со старыми версиями продукта. Минорная версия библиотеки меняется при инкрементальных изменениях, позволяющих старым версиям продукта использовать новую библиотеку абсолютно прозрачно и без каких-либо последствий для функциональности. Таким образом, существует правило бинарной обратной совместимости модуля в рамках одной мажорной версии: Старые версии продукта должны гарантированно работать с новыми минорными версиями модуля, и при этом вся функциональность должна полностью сохраняться. Вся работа с библиотекой должна быть построена на интерфейсах. браузер плагин инсталлятор программный

Все методы, функциональность которых подразумевает возможность ошибок или отказа в выполнении запроса, должны возвращать численный результат операции типа CHAR.

При наличии в проекте логической части (функционального кода) и графической оболочки (GUI), они должны быть полностью разделены и должны физически находиться в разных DLL библиотеках. Взаимодействие между GUI и алгоритмической частью должно осуществляться по интерфейсам согласно общим правилам взаимодействия библиотек.
За исключением специально оговоренных случаев, алгоритмическая часть должна быть способна функционировать при отсутствии своего GUI-модуля. При этом она может иметь функциональность для предупреждения пользователя или продукта об отсутствии GUI компоненты, но также, при необходимости, должна уметь работать без каких-либо лишних сообщений об этом.

2.7 Структурная схема системы

На рисунке 2.3 представлена структурная схема системы.

Рисунок 2.3 - Структурная схема системы

2.8 Функциональная схема системы

На рисунке 2.4 представлена функциональная схема системы.

Рисунок 2.4 - Функциональная схема системы

3. РАЗРАБОТКА ОСНОВНЫХ УЗЛОВ СИСТЕМЫ

3.1 Среда разработки Qt Creator

Введение

Qt Creator это полностью интегрированная среда разработки (IDE), которая предоставляет вам инструменты проектирования и разработки сложных приложений для множества настольных и мобильных платформ. На рисунке 3.1 представлен логотип среды разработки Qt Creator с указанием ее основных компонентов [11].

Рисунок 3.1 - Логотип Qt Creator с указанием основных компонентов

На рисунке 3.2 представлен снимок экрана главного окна среды разработки Qt Creator.

Проекты

Одним из главнейших достижений Qt Creator является то, что он позволяет команде разработчиков работать над проектом на различных платформах с использованием общих инструментов для разработки и отладки.



Рисунок 3.2 - Снимок экрана главного окна среды разработки Qt Creator

Но зачем вам нужны проекты? Чтобы быть в состоянии собирать и запускать приложения, Qt Creator нуждается в той же информации, которая потребуется компилятору. Эта информация указана в настройках сборки и запуска проекта.

Создание проекта позволяет:

1. Группировать файлы вместе.

2. Добавить собственные шаги сборки.

3. Включить формы и файлы ресурсов.

4. Указать настройки для запускаемых приложений.

Можно или создать проект с нуля, или импортировать существующий проект. Qt Creator генерирует все необходимые файлы в зависимости от типа создаваемого проекта. Например, если выбрать создание приложения с графическим интерфейсом пользователя (GUI), Qt Creator создаст пустой .ui файл, который вы можете изменить в интегрированном Qt Designer.

QtCreator интегрирован с кроссплатформенными системами автоматизации сборки: qmake и CMake. Также вы можно импортировать существующие проекты, которые не используют qmake или CMake, и указать Qt Creator просто проигнорировать систему сборки [12].

Редакторы

Qt Creator поставляется с редактором кода и Qt Designer для проектирования и сборки графических интерфейсов пользователя (GUI) из виджетов Qt.

Так как он является IDE, Qt Creator отличается от текстового редактора тем, что знает как собирать и запускать приложения. Он понимает языки C++ и QML как код, а не как простой текст. Это позволяет ему:

1. Дать возможность писать хорошо форматированный код.

2. Угадывать что разработчик хочет написать и дополнять код.

3. Отображать сообщения об ошибках и предупреждения.

4. Дать возможность перемещаться между классами, функциями и символами.

5. Предоставлять контекстно-зависимую справку по классам, функциям и символам.

6. Осмысленно переименовывать символы так, что другие символы с таким же именем но принадлежащие другим областям действия не будут переименованы.

7. Показывать место в коде где функция была описана или вызвана.

Так же можете использовать Qt Designer чтобы располагать и настраивать ваши виджеты или диалоги и тестировать их используя разные стили и разрешения экрана. Созданные с помощью Qt Designer виджеты и формы легко интегрируются в программный код с использованием механизма сигналов и слотов Qt, которые позволят легко определить поведение графических элементов. Все свойства, установленные в Qt Designer, могут быть динамически изменены в коде. Более того, такие особенности как продвижение виджетов и собственные модули позволят использовать собственные виджеты с Qt Designer.

Языки

Можно использовать редактор для написания кода на Qt C++ или на языке декларативного программирования QML.

Язык QML позволяет создавать очень гибкий интерфейс пользователя из обширного набора элементов QML. Он помогает разработчикам и дизайнерам работать вместе над созданием гибких пользовательских интерфейсов, которые получат распространение на портативных устройствах, таких как сотовые телефоны, медиаплееры, неттопы и нетбуки.

QML это расширение JavaScript, которое предоставляет механизм декларативной сборки дерева объектов из элементов QML. QML улучшает интеграцию между JavaScript и существующей системой Qt, основанной на QObject, добавляет поддержку автоматического связывания свойств и обеспечивает сетевую прозрачность на уровне языка [13].

Цели

Qt Creator предоставляет поддержку для сборки и запуска приложений на Qt для настольных компьютеров (Windows, Linux и Mac OS) и мобильных устройств (Symbian, Maemo и MeeGo). Настройки сборки позволяют быстро переключаться между целями сборки.

Когда разработчиквы собирает приложение для мобильного устройства, подключённого к компьютеру, Qt Creator генерирует пакет установки, устанавливает его на устройстве и запускает его.

3.2 Разработка ядра системы

Разработка главной функции ядра системы

Функция main вызывается при старте программы после инициализации нелокальных объектов со статической длительностью хранения. Это точка входа в программу, которая исполняется в гостевом окружении (то есть с операционной системой). Точки входа в автономные программы (boot loaders, OS kernels, и т.п.) зависят от реализации.

Параметры функции main в варианте с двумя параметрами позволяют передать произвольные многобайтовые строки из окружения выполнения (обычно это аргументы командной строки), указатели (argv[1] и. argv[argc-1]) ссылаются на первые символы этих строк. argv[0] -- указатель на первый символ многобабайтовой строки с завершающим нулём, которая содержит имя, используемое при вызове программы. Эти строки изменяемые, хотя их изменения не распространяются назад в окружение выполнения: они могут использоваться, например, в std::strtok. Размер массива, на который указывает argv, равен по меньшей мере argc+1, и последний элемент массива argv[argc] гарантированно является null-указателем.

Функция main обладает следующими специальными свойствами:

1. Она нигде не может быть использована в программе.

2. Её нельзя объявлять и нельзя перегружать: фактически имя main зарезервировано в глобальном пространстве имён.

3. Её нельзя объявить как удалённую или определить со связыванием для C (начиная с C++17), inline, static или constexpr.

4. В теле функции main не обязателен оператор return: при завершении функции main без оператора return эффект будет тот же самый, как при выполнении return 0.

5. Выполнение return (или неявного return при достижении конца функции main) эквивалентно нормальному выходу из функции (которое уничтожает объекты с автоматическим временем жизни) с последующим вызовом std::exit с тем же самым аргументом, который был передан в return. (std::exit уничтожает статические объекты и завершает программу).

6. Если функция main определена как function-try-block, исключения, брошенные деструкторами статических объектов (которые уничтожаются при вызове std::exit), не отлавливаются функцией.

7. Тип возвращаемого значения функцией main не может быть выведен (auto main() {...} не разрешён) [14].

В разрабатываемой системе точкой входа в программу является функция main, именно она отвечает за логику работу с библиотеками, параметрам и подсистемой логирования.



Рисунок 3.3 - Блок-схема алгоритма функции main ядра системы

Рисунок 3.4 - Блок-схема алгоритма функции main ядра системы



Рисунок 3.5 - Блок-схема алгоритма функции main ядра системы

На рисунке 3.6 изображен снимок экрана разработанной функции main, вынесенной в одноименный файл main.cpp.

Рисунок 3.6 - Снимок экрана разработанной функции main

Исходный код функции main представлен в приложении А.

Разработка менеджера модулей

Менеджер модулей реализован в виде двух классов GSModulesManager и GSModule. Далее перечислены открытые интерфейсы класса GSModulesManager:

1. GSModulesManager(const QString &objectName, QObject *parent = Q_NULLPTR).

2. Virtual ~GSModulesManager().

3. GSModule *loadModule(const QString &moduleName="").

4. virtual void loadAllModules(void *abstractInterface=Q_NULLPTR, bool doInit=false).

5. Void unloadModule(GSModule* module).

6. Void unloadAllModules().

7. Void setLog(GSLog *log=Q_NULLPTR).

8. Virtual void init().

9. Virtual void onEvent(const QString &event, char param).

10. Void *getWidget(const QString &widgetID).

11. Char checkUpdates(const QString &listFileName, bool forceUpdate=false).

12. QString& getNewExeName().

13. QString& getInstName().

14. Void exeUpdated(const QString fileName).

15. Void instReceived(const QString fileName).

Открытые интерфейсы класса GSModule:

1. GSModule(const QString &moduleName, const QString &modulesSection,

2. QObject *parent = Q_NULLPTR).

3. Virtual ~GSModule().

4. Char init(void *abstractInterface).

5. Char start().

6. Char stop().

7. QString about(char content).

8. Bool isLoaded().

9. Bool load().

10. Bool unload().

11. Char onEvent(const QString &event, char param).

12. Void *getWidget(const QString &widgetId).

13. Vvoid setLog(GSLog *log=Q_NULLPTR).

На рисунке 3.7 изображен снимок экрана реализованного менеджера модулей, вынесенного в файл gsModule.cpp.

Рисунок 3.7 - Снимок экрана реализованного менеджера модулей

Исходный код менеджера модулей представлен в приложении Б.

Разработка подсистемы работы с параметрами

Подсистема работы с параметрами реализована в виде класса GSApplication. Далее перечислены его открытые интерфейсы:

1. GSApplication(int &argc, char **argv).

2. Virtual ~GSApplication().

3. Static GSApplication *theApplication().

4. Virtual void saveParams().

5. Virtual void readParams().

6. GSLog *createAppLog(const QString &objectName="").

7. GSLog* getAppLog().

8. GSModulesManager *createModulesManager(const QString &objectName="").

9. QUuid getAppUID().

10. Void isWow64(QString *appDigits).

На рисунке 3.8 изображен снимок экрана реализованной подсистемы работы с параметрами, вынесенной в файл gsApplication.cpp.

Рисунок 3.8 - Снимок экрана реализованной подсистемы работы с параметрами

Исходный код подсистемы работы с параметрами представлен в приложении В.

Разработка подсистемы логирования

Подсистема логирования реализована в виде класса GSLog. Далее перечислены его открытые интерфейсы:

1) GSLog(QObject *pobj=Q_NULLPTR,const QString &objectName="").

2) Virtual ~GSLog().

3) Bool init(const QString &paramsSection="").

4) Bool setLogFileName(QString &value=QString()).

5) QString getLogFileName().

6) Void setLogLevel(int value).

7) Int getLogLevel().

8) Void setlogMessagesLevel(int value=0).

9) GSLog& toLog(int level=0, QObject *pobj=Q_NULLPTR).

10) GSLog& operator <<(QString &value).

11) GSLog& operator <<(const QString &value).

12) GSLog& operator <<(char *value).

13) GSLog& operator <<(const char *value).

14) GSLog& operator <<(bool value).

15) GSLog& operator <<(int value).

16) GSLog& operator <<(QTextStream &(__cdecl *)(QTextStream &)).

17) GSLog& operator <<(QEvent::Type value.

На рисунке 3.9 изображен снимок экрана реализованной подсистемы логирования, вынесенной в файл gsLog.cpp.

Рисунок 3.9 - Снимок экрана реализованной подсистемы логирования

Исходный код подсистемы логирования представлен в приложении Г.

Разработка модуля обновлений

Модуль обновлений реализован виде класса gsUpdateFiles. Далее перечислены его открытые интерфейсы:

1) Enum TUpdatePolicy {newOnly,fullUpdate}.

2) GSUpdateFiles(QWidget *parent = 0).

3) Virtual ~GSUpdateFiles().

4) Virtual void getUpdatesList(const QString &listFileName).

5) Virtual void buildUpdatesTree(const QString &listFileName.

6) Const QString &modulesSection.

7) TUpdatePolicy updatePolicy=newOnly).

8) Void setLog(GSLog *log=Q_NULLPTR).

9) Virtual void init(const QString &paramSectionName="").

На рисунке 3.10 изображен снимок экрана реализованного модуля обновления, вынесенного в файл gsUpdateFiles.cpp.

Рисунок 3.10 - Снимок экрана реализованного модуля обновления

Исходный код модуля обновления представлен в приложении Д.

3.3 Разработка модуля главного окна системы и модуля печати

В данной системе модуль главного окна является основным модулем, именно ему предается управление после запуска ядра. На данном этапе модули главного окна и модуль печати объединены в одну библиотеку под названием «InterinClntMainWnd.dll».

Основной задачей главного окна системы является работа с веб-контентом, поэтому оно построено на базе Qt WebEngine. Этот просто класс, он не предоставляет возможность отлавливать события на веб-страницах, поэтому в него необходимо добавить обработчики. В итоге появится возможность отлавливать события на веб-страницах, в том числе событие загрузки и получения файлов. В момент обработки ссылки на получение файла, клиент уже будет знать, что с ним делать и уже на стороне ОС вызовет нужную процедуру.

Стоит обратить внимание на подсистемы загрузки файлов, печати в файл формата pdf, а так же настройки системы.

Разработка подсистемы загрузки файлов

Подсистема загрузки файлов реализована в виде класса DownloadManager. Далее перечислены его открытые интерфейсы:

1) void stop();

2) void open();

3) void print();

4) void downloadProgress(qint64 bytesReceived, qint64 bytesTotal);

5) void finished().

На рисунке 3.11 изображен снимок экрана реализованной подсистемы печати, вынесенной в файл gsUpdateFiles.cpp.

Рисунок 3.11 - Снимок экрана реализованной подсистемы загрузки файлов

Исходный код подсистемы загрузки файлов представлен в приложении Е.

Разработка подсистемы печати

Модуль печати состоит из сторонней библиотеки, над которой сделана надстройка, где прописаны все функции этой библиотеки, а так же вызовы этих функций приведены к стандартному виду qt. Таким образом скрыто низкоуровневое обращение к функциям сторонней библиотеки. Основной функцией модуля печати является получение файла, затем, в зависимости от параметра в адресе страницы, либо сразу отправляется на печать, либо открывается предустановленным в ОС программным обеспечением. Перед отправкой на печать (прозрачной), этот модуль может указать размер бумаги, ее ориентацию, дуплекс и количество копий.

На рисунке 3.12 изображен снимок экрана реализованного диалогового окна печати в файл формата pdf, вынесенного в файл printtopdfdialog.cpp.

Рисунок 3.12 - Снимок экрана реализованного диалогового окна печати в файл формата pdf

Исходный код реализованного диалогового окна печати в файл формата pdf представлен в приложении Ж.

Разработка подсистемы настроек

Настройки всей системы реализованы в реестре операционной системы. Они позволяют не просто настроить систему, но полностью изменить логику ее работы, путем изменения или добавления библиотек.

На рисунке 3.13 изображен снимок экрана реализованной подсистемы настроек вынесенной в файл settings.cpp.

Рисунок 3.13 - Снимок экрана реализованной подсистемы настроек системы

Создание инсталлятора программной системы

Для создания инсталлятора целесообразно воспользоваться готовыми программными средствами, например, Inno Setup. Для работы системы необходим следующий набор компонент:

1. Исполняемый файл ядра системы.

2. Модуль главного окна системы.

3. Функциональные библиотеки.

Скрипт Inno Setup , который содержит свойства дистрибутива и набор производимых действий при установке и удалении представлен в приложении З.

4. ТЕСТИРОВАНИЕ СИСТЕМЫ

4.1 Инсталяция программы

Инстлятор клиента представляет собой исполняемый файл с раширением .exe. Его название имеет следующий вид: InterinClient_XX_setup, где XX - версия инсталятора. В процессе установки пользователю предлагается прочесть лицензионное соглашение, выбрать директурю для установки, а так же у пользователя есть возможность вобора название приложения в меню пуск, и необходимость создания ярлыка на рабочем столе. На рисунке 4.1 представлен снимок экрана процесса установки клиента.