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

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

Национальный исследовательский университет

«Высшая школа экономики»

Факультет экономики, менеджмента и бизнес-информатики

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

Разработка портала «Распознавание пыльцевых зерен»

Щуркин Михаил Дмитриевич

Пермь, 2018 год



Аннотация

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

Работа состоит из 47 страниц основного текста, 6 таблиц, 45 иллюстраций, 4 приложений.

интернет портал палинология



Оглавление

• Введение
• Глава 1. Анализ предметной области и разработка требований к системе
• 1.1 Описание функциональных процессов работы интернет портала
• 1.2 Постановка требований к разрабатываемой системе
• 1.3 Анализ существующих способов получения информации
• Глава 2. Анализ методов решения задачи разработки порталов
• 2.1 Сервис-ориентированная архитектура
• 2.2 Достоинства и недостатки сервис-ориентированной архитектуры
• 2.3 Веб-сервисы
• 2.4 Сравнение SOAP и REST
• 2.5 WSDL
• 2.6 Обоснование выбора технологии разработки
• 2.6.1 Критерии выбора технологии
• 2.6.2 Java (REST API)
• 2.6.3 .NET(WCF)
• 2.6.4 Вывод
• 2.7 Онтологический подход к генерации кода сервисов
• Глава 3. Проектирование портала и инструмента генерации кода
• 3.1 Описание прецедентов
• 3.2 Архитектура системы
• 3.2. Проектирование базы данных
• 3.3. Диаграммы классов
• 3.4. Проектирование пользовательского интерфейса
• Глава 4. Реализация портала и инструмента генерации кода
• 4.1 Реализация сервисов
• 4.2. Композитное приложение
• 4.3 Генератор кода
• 4.4. Тестирование
• Заключение
• Библиографический список
• Приложение
• 

Введение

Окружающий мир человека наполнен различными растениями. Некоторых из них выбрасывают в воздух пыльцу и споры, которые, в свою очередь, влияют на различные сферы нашей жизни. Начиная от процесса определения качества продаваемого меда, и нахождения контрафактной продукции, заканчивая предупреждением аллергических реакций на частицы, витающие в воздухе, стоит проблема определения принадлежности пыльцевого зерна к определенному виду растений. Этими проблемами занимаются сотрудники биологического факультета Пермского национального исследовательского университета (ПГНИУ). Наряду с ними, эти проблемы являются объектом исследования и других ученых как в России, так и за рубежом. Ученые должны иметь возможность оперативно получать информацию об исследованиях в этой же области исследований как можно более оперативно, возможно проводить совместные исследования с учеными других вузов, делиться опытом обучения студентов и обучать студентов. По этой причине целесообразно разработать Интернет-ресурс и Веб-приложение, которые бы позволяли проводить исследования, обеспечивать ученых актуальной информацией об исследованиях в области распознавания пыльцевых зерен.

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

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

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

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

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

Для достижения поставленной цели необходимо решить следующие задачи:

1. провести анализ задачи разработки интернет-портала:

1.1. формализовать описание процесса работы интернет-портала;

1.2. конкретизировать требования к разрабатываемому интернет-порталу;

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

2. провести анализ методов решения задачи разработки интернет-портала:

2.1. разработать алгоритмы решения поставленной задачи;

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

3. рассчитать стоимость и сроки разработки информационной системы;

4. спроектировать разрабатываемую систему:

4.1. выполнить проектирование пользовательского интерфейса;

4.2. построить архитектуру разрабатываемого продукта;

4.3. разработать схемы необходимых баз данных.

5. разработать портал для проведения тестирования распознавания пыльцевых зерен и получения соответствующей обучающей информации;

6. выполнить тестирование и отладить компоненты разрабатываемой системы.

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

В процессе работы буду применены следующие методы исследования:

1. методы анализа аналогичных решений и технологий разработки;

2. методы моделирования информационных систем;

3. методы проектирования систем;

4. методы программирования с использованием объектно-ориентированной парадигмы.

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



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

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

1. описание функциональных процессов работы интернет-порталов, необходимое для определения концепции разработки;

2. постановка требований к разрабатываемой системе;

3. анализ существующих аналогов разрабатываемого продукта.

1.1 Описание функциональных процессов работы интернет портала

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

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

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

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

По направленности на пользователей интернет-порталы также делят на две категории:

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

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

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

1.2 Постановка требований к разрабатываемой системе

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

Основные возможности, которые должен предоставлять разрабатываемый интернет-портал:

1. работа с тезаурусом:

1.1. добавление новых понятий в тезаурус;

1.2. обновление существующих понятий;

1.3. удаление записей;

1.4. предоставление тезауруса пользователям.

2. работа с блоком ученых:

2.1. добавление новых ученых;

2.2. обновление информации о добавленных ученых;

2.3. удаление информации об ученых;

2.4. предоставление информации пользователям.

3. работа с блоком новостей:

3.1. добавление новых новостей;

3.2. обновление существующих записей;

3.3. удаление записей;

3.4. предоставление новостного блока пользователям.

4. работа с блоком методов исследования:

4.1. добавление новых методов;

4.2. обновление существующих записей;

4.3. удаление записей;

4.4. предоставление информации из блока пользователям.

5. работа с блоком информации о зернах:

5.1. добавление новых зерен;

5.2. обновление существующих записей;

5.3. удаление записей;

5.4. предоставление информации из блока пользователям.

6. работа с сервисом определения принадлежности зерна:

6.1. загрузка обучающей выборки;

6.2. загрузка тестируемой выборки;

6.3. предоставление результатов работы сервиса.

7. поиск доступных на портале материалов в категориях «Тезаурус», «Последние новости», «Ученые-палинлоги», «Зерна», «Методы исследования» по запросу пользователя;

8. поддержка языка разметки Markdown для редактирования материалов в категориях «Тезаурус», «Последние новости», «Ученые-палинлоги», «Зерна», «Методы исследования».

Результатом постановки требований является Техническое задание (приложение A).

1.3 Анализ существующих способов получения информации

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

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

· возможность получения информации на централизованном ресурсе, без необходимости посещения сторонних ресурсов;

· возможность поиска конкретной информации;

· возможность использования дополнительных сервисов, таких как модуль определения принадлежности зерна.

Так как разрабатываемый продукт используется не только посетителями, но и администраторами, которые дополняют и обновляют наполнение портала, в процессе его сравнения с существующим решением Биологического факультета ПГНИУ необходимо выделить еще один критерий - поддержка языка разметки Markdown. Markdown упрощает редактирование веб-страницы путем предоставления синаксиса для удобного ввода формул, форматирования текста, добавления нумерованных и маркированных списков. Markdown простой в преобразовании в язык разметки HTML, что дает возможность его использования в процессе редактирования контента на интернет-ресурсе. Результатом использования данного языка является более удобный к прочтению текст. Для администратора преимуществом использования Markdown является то, что нет необходимости изучения сложных языков разметки, в случае если необходимо оформить текст с использованием различных шрифтов цветов и разделением абзацев.

Для сравнения способов решения проблемы получения информации построим таблицу с перечислением критериев (табл. 1.1).

Таблица 1.1. Сравнение способов решения проблемы получения информации

Критерии	Портал ПГНИУ	Самостоятельный поиск
Возможность получения информации на централизованном ресурсе, без необходимости посещения сторонних ресурсов	+	-
Возможность поиска конкретной информации	-	+
Возможность использования дополнительных сервисов, таких как модуль определения принадлежности зерна	-	-
Возможность использования языка Markdown	-	-



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

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



Глава 2. Анализ методов решения задачи разработки порталов

Данная глава описывает такие этапы анализа методов решения, как:

1. выбор методов решения задач и обоснование данного выбора;

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

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

2.1 Сервис-ориентированная архитектура

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

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

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

При разработке сервиса, необходимо предъявлять ему такие требования, как:

· возможность многократного использования;

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

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

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

Существуют несколько преимуществ использования сервис-ориентированного подхода при построении архитектуры приложения, таких как:

· многократное ускорение разработки приложений и снижение трудозатрат;

· возможность построения коммуникации между компонентами системы используя различные протоколы и стандарты форматирования сообщений;

· возможность обеспечить безопасность передачи сообщений;

· возможность размещения компонентов системы на различных узлах сети.

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

При построении сервис-ориентированной архитектуры необходимо придерживаться следующих принципов:

· независимость системы от вычислительных платформ, на которых она размещена;

· независимость системы от языков программирования, используемых при разработке;

· независимость информационных услуг от прикладных приложений;

· единообразный интерфейс доступа к каждой информационной услуге;

· независимость информационных услуг друг от друга.

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

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

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



2.2 Достоинства и недостатки сервис-ориентированной архитектуры

К достоинствам сервис-ориентированной архитектуры можно отнести:

· сокращение продолжительности разработки и тестирования за счет:

1. унаследования программных продуктов;

2. фокуса на требованиях и бизнес-правилах заказчика, производство продукта, удовлетворяющих уникальные потребности клиента;

3. сокращения времени на написание кода;

4. упрощения архитектуры программного комплекса;

5. унификации способов взаимодействия компонентов;

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

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

Однако сервис-ориентированный подход к построению архитектуры программного продукта имеет несколько недостатков. Среди недостатков можно выделить следующие:

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

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

· отсутствие общей модели безопасности в системах, построенных на базе сервис-ориентированной архитектуры;

· отсутствие стандартизированных средств для описания распределенных информационных услуг;

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

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

2.3 Веб-сервисы

Веб-сервисом является компонент программного комплекса, который предоставляет информационную услугу посредством удаленного вызова. Удаленный вызов строится на основе группы стандартов WSI (Web Services Interopertability).

При разработке веб-сервиса используют следующие стандарты:

· SOAP (Simple Objects Access Protocol) - протокол обмена произвольными сообщениями, использующий формат XML для кодирования передаваемых данных;

· UDDI (Universal Description Discovery and Integration) - каталог информационных услуг и о организациях, предоставляющих веб-сервисы для общего пользования, либо конкретным компаниям;

· WSDL (Web Services Description Language) - язык описания интерфейса информационной услуги;

· XML (Extensible Markup Language) - расширяемый язык разметки, предназначенный для хранения и передачи структурированных данных.

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

Основываясь на перечисленной ранее информации, дадим определение веб-сервису. Информационная услуга (веб-сервис) - это программный компонент, идентификатором которого является строка URI, переход по которой вызывает работу компонента. Функции, которые доступны для неограниченного круга пользователей перечислены в интерфейсе и описаны с помощью языка XML. Каждый веб-сервис является отельным модульным компонентом в составе приложения построенного с учетом сервис-ориентированной архитектуры (рис. 2.1.).

Рисунок 2.1. Общая схема взаимодействия веб-сервисов и клиентов веб-сервисов

На данный момент наиболее популярными протоколами реализации веб-сервисов являются:

· REST (Representational State Transfer);

· SOAP (Simple Object Access Protocol).

Произведем сравнение данных протоколов



2.4 Сравнение SOAP и REST

REST является более удобным, простым и понятным способом передачи данных, а также более производительным по сравнению с SOAP, так как не требует ресурсов на обработку входных команд на языке XML, а оперирует со стандартными HTTP запросами: GET, POST, PUT, DELETE). Однако REST ограничен лишь CRUD операциями («Создать», «Прочесть», «Обновить», «Удалить») [4]. В большинстве случаев данных операций достаточно. В случае, если необходима передача команды на выполнение особенных операций, связанных с конкретной предметной областью, целесообразнее использование SOAP. Стоит также отметить, что протокол SOAP является более надежным и безопасным.

2.5 WSDL

WSDL (WEB Services Description Language) -- язык описания веб-сервисов. Данный язык используется для описания информационной услуги, а именно адреса сервера, протокола передачи данных, номера порта, формата входных запросов и результатов. Помимо перечисленного, язык используется для описания интерфейса информационной услуги.

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



2.6 Обоснование выбора технологии разработки

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

· Java(REST API сервисы);

· .NET(WCF сервисы).

2.6.1 Критерии выбора технологии

Для выбора технологии составим вариантный сектор, а в качестве критериев выберем нижеследующие:

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

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

· возможность повторного использования - Большим плюсом технологии является возможность повторного использования ранее написанного кода, не только на других web-сайтах, но и для локальной работы, для работы в локальной сети, для работы через Интернет, но без браузера и т.д. Вес равен 8;

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

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

2.6.2 Java (REST API)

Java представляет собой самостоятельный язык программирования и спецификацию на виртуальный процессор - Java Virtual Machine.

Для создания Java артефактов существуют различные среды разработки, но наиболее популярным и удобным решением является IntelliJ IDEA, которая предлагает удобные инструменты отладчика и автозаполнения кода. Минусами технологии являются необходимость наличия на машине пользователя виртуальной Java машины и более низкая производительность. В случае использования REST API необходимо самостоятельное описание вызовов методов сервиса путем вызова соответствующих запросов. При таком подходе присутствует высокая возможность ошибки, а также отсутствует автоматическая проверка кода в процессе разработки.

2.6.3 .NET(WCF)

О WCF сервисах было сказано выше. Отметим лишь, что для работы .NET приложений так же необходимы дополнительные компоненты, поставляющиеся вместе с .NET Framework, что так же снижает производительность, однако не так критично, как при использовании виртуальных машин. Что касается удобства работы с технологией, при использовании WCF сервисов и клиентского приложения, так же разрабатываемого на платформе .Net появляется возможность простого подключения новых информационных услуг в решение, а также использования автоматической генерации классов, необходимых для работы с сервисом [7].

2.6.4 Вывод

В результате анализа в качестве технологии для разработки сервисов и композитного приложения была выбрана технология .NET Framework. Такой выбор сделан, прежде всего, из-за удобства разработки (обеспечиваемой средой для разработки Visual Studio 2017 и языком C#), возможностью повторного использования компонентов и удобством обеспечения взаимной работы веб-сервисов и композитного приложения. Подсчет результатов представлен в таблице 2.1.

Таблица 2.1. Вариантный сектор выбора технологии разработки

Название технологии	K1	K2	K3	K4	Результат
Вес критерия	10	4	8	2
Java	7	3	5	2	126
.NET	9	6	5	9	173

2.7 Онтологический подход к генерации кода сервисов

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

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

Онтологии состоят из следующих элементов:

· объекты - компоненты онтологии, описывающие объекты предметной области;

· классы - коллекции объектов;

· атрибуты - свойства объекта. Атрибут имеет имя и значение;

· отношения - связи между объектами.

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



Глава 3. Проектирование портала и инструмента генерации кода

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

3.1 Описание прецедентов

Основываясь на требованиях к программному продукту, построим диаграмму прецедентов (рис 3.1).

Рисунок 3.1. Диаграмма прецедентов портала

Как представлено на диаграмме, система содержит двух акторов и трех основных прецедентов, таких как «Распознавание зерна», «Просмотр содержимого портала» и «Редактирование содержимого портала».

Прецеденты просмотра содержимого категории портала содержит прецедент просмотра элемента категории, а прецедент редактирования содержимого включает в себя прецеденты: «Добавление новых категорий», «Добавление новых записей к категориям портала», «Удаление записей» и «Редактирование записей».

Каждый из прецедентов опишем с помощью диаграмм деятельности (см. рис 3.2 _ 3.7).

Рисунок 3.2. Просмотр содержимого категории портала

Рисунок 3.3. Добавление новой записи



Рисунок 3.4. Удаление записи

Рисунок 3.5. Редактирование записи



Рисунок 3.6 Просмотр элемента категории портала



Рисунок 3.7. Распознавание зерна

Администратор так же имеет возможность добавления новой категории. Для создания новой категории портала необходимо сгенерировать код сервиса. Построим диаграмму деятельности для данного прецедента (рис 3.8).



Рисунок 3.8. Генерация кода на основе онтологии

3.2 Архитектура системы

Каждый из сервисов имеет свою базу данных (далее БД), в которой хранит информацию, связанную с его предметной областью. WCF сервисы работают с БД и выполняют CRUD операции, а также преобразуют данные из БД для дальнейшей отправки клиенту, в данном случае композитному приложению. Коммуникация сервисов с приложением осуществляется по протоколу SOAP, который был описан в предыдущей главе. В качестве клиентского продукта выступает веб-приложения, доступ к которому осуществляется через веб-браузер.

Построим архитектуру системы (см. рис. 3.9.).



Рисунок 3.9. Архитектура системы

3.2 Проектирование базы данных

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

Опишем проектирование БД для хранения информации о зернах (рис 3.10). БД содержит 2 сущности. Сущность Grain хранит информацию о зерне. Поле Name хранит название зерна, а поле Description содержит описание. Поле Id используется в качестве ключа.

Рисунок 3.10. База данных для хранения информации о зернах



Сущность Photo предназначено для хранения информации о изображениях зерна. Оно содержит ссылку на конкретный экземпляр сущности «Зерно» и обеспечивает связь «один ко многим». Поле Name хранит название изображения, а поле Path содержит ссылку на конкретный файл изображения на сервере.

Опишем проектирование БД для хранения информации о методах исследования (рис 3.11).

Рисунок 3.11. База данных для хранения информации о методах исследования

БД содержит 2 сущности. Сущность Method хранит информацию о методе. Поле Name хранит название метода, а поле Description содержит описание. Поле Id используется в качестве ключа.

Сущность Photo предназначено для хранения информации о изображениях, связанных с методом исследования. Оно содержит ссылку на конкретный экземпляр сущности «Метод» и обеспечивает связь «один ко многим». Поле Name хранит название изображения, а поле Path содержит ссылку на конкретный файл изображения на сервере.

Опишем проектирование БД для хранения информации о новостях (рис 3.12).



Рисунок 3.12 База данных для хранения информации о новостях

БД содержит 2 сущности. Сущность Post хранит информацию о новости. Поле Name хранит название метода, а поле Body содержит полную новость. Поле Id используется в качестве ключа.

Сущность Photo предназначено для хранения информации о изображениях, включенных в новость. Оно содержит ссылку на конкретный экземпляр сущности «Новость» и обеспечивает связь «один ко многим». Поле Name хранит название изображения, а поле Path содержит ссылку на конкретный файл изображения на сервере.

Опишем проектирование БД для хранения информации об ученых (рис 3.13).

Рисунок 3.13 База данных для хранения информации об ученых

БД содержит 1 сущность. Сущность Scientist хранит информацию об ученом. Поле Name хранит имя, а поле Description содержит информацию о его деятельности. Поле Id используется в качестве ключа. Поля BirthDate и DeathDate хранят информацию о датах жизни и смерти ученого. Поле DeathDate имеет параметр Nullable=true, так как ученый может находиться при жизни. Стоит отметить, что для хранения фотографии ученого не добавлена отдельная сущность, так как в данном случае необходимо хранить лишь одну фотографию. Поле ImagePath хранит ссылку на файл изображения на сервере.

Опишем проектирование БД для хранения информации тезауруса (рис 3.14).

Рисунок 3.14 База данных для хранения информации тезауруса

БД содержит 1 сущность. Сущность Thesaurus хранит информацию тезауруса. Поле Name хранит термин, а поле Description содержит описание термина. Поле Id используется в качестве ключа.

3.3 Диаграммы классов

Опишем диаграммы классов каждого сервиса и композитного приложения.

IGrainService является интерфейсом, содержащим в себе информацию о методах сервиса, GrainService в свою очередь является имплементацией интерфейса. Классы Grain и Photo являются обертками над соответствующими сущностями. Класс PhotoType является оберткой над классами Grain и Photo и упрощает передачу данных клиентам сервиса, храня в себе информацию об объекте, к которому относятся фотографии, а также сериализованное изображение.

Опишем диаграмму классов сервиса предоставления информации о зернах (рис. 3.15).

Рисунок 3.15 Диаграмма классов сервиса «Зерна»

Опишем диаграмму классов сервиса предоставления информации о методах исследования (рис. 3.16).

Рисунок 3.16 Диаграмма классов сервиса «Методы исследования»



IMethodService является интерфейсом, содержащим в себе информацию о методах исследования, MethodService в свою очередь является имплементацией интерфейса. Классы Method и Photo являются обертками над соответствующими сущностями. Класс PhotoType является оберткой над классами Method и Photo и упрощает передачу данных клиентам сервиса, храня в себе информацию об объекте, к которому относятся фотографии, а также сериализованное изображение.

Опишем диаграмму классов сервиса предоставления информации о новостях (рис. 3.17).

Рисунок 3.17 Диаграмма классов сервиса «Новости»

INewsService является интерфейсом, содержащим в себе информацию о новостях, NewsService в свою очередь является имплементацией интерфейса. Классы Post и Photo являются обертками над соответствующими сущностями. Класс PhotoType является оберткой над классами Post и Photo и упрощает передачу данных клиентам сервиса, храня в себе информацию об объекте, к которому относятся фотографии, а также сериализованное изображение.

IScientistsService является интерфейсом, содержащим в себе информацию о новостях, ScientistsService в свою очередь является имплементацией интерфейса. Класс Scientist является оберткой над соответствующей сущностью.

Опишем диаграмму классов сервиса предоставления информации об ученых (рис. 3.18).

Рисунок 3.18 Диаграмма классов сервиса «Ученые»

Опишем диаграмму классов сервиса предоставления информации тезауруса (рис. 3.19).



Рисунок 3.19. Диаграмма классов сервиса «Тезаурус»

IThesaurusService является интерфейсом, содержащим в себе информацию о новостях, ThesaurusService в свою очередь является имплементацией интерфейса. Класс Thesaurusявляется оберткой над соответствующей сущностью.

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

3.4 Проектирование пользовательского интерфейса

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

Пользовательский интерфейс портала будет представлять набор веб-страниц. На каждой из страниц вверху будет располагаться панель с набором вкладок для использования любого из доступных сервисов [3,9]. По переходу по таким вкладкам как «Тезаурус», «Новости», «Ученые», «Зерна» и «Методы исследования» пользователь перейдет на страницы с набором всех записей данного блока. При нажатии на ссылку «Подробнее», он перейдет на вкладку с полной информацией о конкретной записи. Вкладка «Контакты» будет содержать контактные данные владельца и администратора портала, а вкладка «Распознавание» будет отправлять к сервису распознавания пыльцевых зерен [11,13].

Интерфейсом системы генерации кода будет являться Windows приложение. При запуске приложения откроется главная форма, содержащая списки с составляющими онтологии, а именно классами, атрибутами классов и связями между классами (рис. 3.20).

Рисунок 3.20 Форма приложения генерации кода

Для добавления классов необходима для реализации соответствующая форма, содержащее поле для ввода наименования класса (рис 3.21).

Рисунок 3.21 Форма создания класса

Для добавления атрибутов к классам была спроектирована форма добавления атрибутов. Для создания нового атрибута необходимо указать его наименование, а также его тип. Наименование вводится в текстовое поле, а тип необходимо выбрать из предложенных вариантов списка (рис. 3.22).

Рисунок 3.22 Форма создания атрибута

Для реализации связей между классами спроектирована форма добавления связей. Для создания связи необходимо выбрать из списков два созданных класса, а также тип связи: «Один ко многим», «Многие ко многим», «Один к одному» (рис. 3.23).

Рисунок 3.23 Форма создания связи

По окончании заполнения онтологии пользователь нажимает кнопку «Сгененерировать код». Система должна открыть окно выбора папки для сохранения файлов с созданным кодом на основе онтологии (рис. 3.24).



Рисунок 3.23 Форма создания связи

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



Глава 4. Реализация портала и инструмента генерации кода

Данная глава описывает результат процесса разработки приложения, а именно: реализацию сервисов; реализацию композитного приложения; реализацию генератора кода сервисов; тестирование.

4.1 Реализация сервисов

Рассмотрим реализованные информационные услуги на примере сервиса поставщика новостей по предметной области. Методы сервиса и их описание предоставлено в таблице (табл. 4.1).

Таблица 4.1. Описание методов сервиса

Название метода	Входные параметры	Выходные данные	Описание
Post GetPost(int ID)	ID новости	Новость	Метод для получения конкретной новости
List<Post> GetAllPosts()	-	Список новостей	Получение всех новостей
bool AddPost(Post p)	Новость	Ответ об успешности добавления	Добавление новости
bool EditPost(Post p)	Новость	Ответ об успешности редактирования	Редактирование новости
bool RemovePost(Post p)	Новость	Ответ об успешности удаления	Удаление новости
bool UploadImages(List<PhotoType l, Post p)	Список изображений, новость	Ответ об успешности добавления	Добавление изображений к новости
bool RemoveImage(String ID, Post p)	ID изображения, новость	Ответ об успешности удаления	Удаление изображений у новости
List<PhotoType> GetImages(Post p)	Новость	Список изображений	Получение изображений по новости

Метод GetPost принимает на вход идентификатор новости, сервис обращается к подключенной базе данных и находит соответствующий объект класса «новость». В случае успешного поиска сервис возвращает найденный объект класса. Метод GetAllPosts вернет список всех новостей. Методы AddPost, EditPost и RemovePost реализуют редактирование блока новостей. Они принимают на вход экземпляр класса «новость» и возвращают ответ об успешности манипуляций с хранилищем данных. Сервис вернет True если редактирование прошло успешно и False в случае ошибки. Метод GetImages возвращает все изображения, связанные с новостью. Ответом сервиса является коллекция объектов PhotoType, включающих в себя наименования изображений и сами изображения, сериализованные с помощью класса BinaryFormatter.

Методы UploadImages и RemoveImage используются для загрузки и удаления изображений соответсвенно.

4.2 Композитное приложение

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

Рисунок 4.1. Главный экран приложения

Рассмотрим работу сервисов на примере вкладки «Ученые». При нажатии на соответствующую вкладку композитное приложение отправляет SOAP запрос сервису ScientistsService, вызывая метод GetAllScientists(). При получении соответствующего сообщения, сервис обращается к БД и формирует список объектов класса Scientist. Сформированный список сервис возвращает композитному приложению. После получения списка метод ScientistsPage адаптирует объекты списка для корректного отображения, при завершении, он передает список на представление (см. рис 4.2).

Рисунок 4.2. Список, возвращенный сервером

При нажатии на ссылку «Подробнее» композитное приложение отправит сервису запрос на получение информации о конкретном ученом. Метод GetScientist получает на вход ID ученого. Сервис получает информацию из БД и передает композитному приложению. После получения списка метод CurrentScientist адаптирует объект класса Scientist для корректного отображения, при завершении, он передает его на представление.

Рассмотрим обращение к сервису распознавание зерна. При нажатии на вкладку «Распознавание зерна» приложение открывает соответствующую страницу (рис 4.3).



Рисунок 4.3. Страница распознавания зерна

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

4.3 Генератор кода

Работа с инструментом генерации кода описана в Главе 3, подглаве «Проектирование пользовательского интерфейса». Опишем результат работы приложения. После заполнения онтологии и указания места сохранения файлов, система создает код сервиса и SQL скрипт для создания таблиц, используемых сервисом (см. рис. 4.4, 4.5).



Рисунок 4.4. SQL скрипт

Рисунок 4.5 Созданный код сервиса

4.4 Тестирование

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

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

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

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

Системное тестирование используется для проверки работы программ как единого набора компонентов. Тестирование проходило по стратегии черного ящика (см табл. 4.2). Так же была выполнена проверка достаточности тестов (см. табл. 4.3).

Таблица 4.2. Набор тестов

Тест	Функция	Входные данные	Результат
T1	Добавление записи в блоках «Тезаурус», «Новости», «Ученые», «Зерна» и «Методы исследования»	Пустые или некорректные поля	Ошибка
T2	Добавление записи в блоках «Тезаурус», «Новости», «Ученые», «Зерна» и «Методы исследования»	Корректно заполненные поля	Добавлена запись
T3	Изменение записи в блоках «Тезаурус», «Новости», «Ученые», «Зерна» и «Методы исследования»	Пустые или некорректные поля	Ошибка
T4	Изменение записи в блоках «Тезаурус», «Новости», «Ученые», «Зерна» и «Методы исследования»	Корректно заполненные поля	Изменена запись
T5	Чтение записей в блоках «Тезаурус», «Новости», «Ученые», «Зерна» и «Методы исследования»	Выбран один из блоков	Список записей
T6	Чтение записи в блоках «Тезаурус», «Новости», «Ученые», «Зерна» и «Методы исследования»	Выбрана запись	Запись
Т7	Удаление записи в блоках «Тезаурус», «Новости», «Ученые», «Зерна» и «Методы исследования»	Нажата кнопка удаления	Запись удалена

Таблица 4.3. Достаточность критериев

Функция	Входные данные	Т1	Т2	Т3	Т4	Т5	Т6	Т7
Добавление записи в блоках «Тезаурус», «Новости», «Ученые», «Зерна» и «Методы исследования»	Пустые или некорректные поля	+
Добавление записи в блоках «Тезаурус», «Новости», «Ученые», «Зерна» и «Методы исследования»	Корректно заполненные поля		+
Изменение записи в блоках «Тезаурус», «Новости», «Ученые», «Зерна» и «Методы исследования»	Пустые или некорректные поля			+
Изменение записи в блоках «Тезаурус», «Новости», «Ученые», «Зерна» и «Методы исследования»	Корректно заполненные поля				+
Чтение записей в блоках «Тезаурус», «Новости», «Ученые», «Зерна» и «Методы исследования»	Выбран один из блоков					+
Чтение записи в блоках «Тезаурус», «Новости», «Ученые», «Зерна» и «Методы исследования»	Выбрана запись						+
Удаление записи в блоках «Тезаурус», «Новости», «Ученые», «Зерна» и «Методы исследования»	Нажата кнопка удаления							+
Добавление записи в блоках «Тезаурус», «Новости», «Ученые», «Зерна» и «Методы исследования»	Пустые или некорректные поля
Добавление записи в блоках «Тезаурус», «Новости», «Ученые», «Зерна» и «Методы исследования»	Корректно заполненные поля
Изменение записи в блоках «Тезаурус», «Новости», «Ученые», «Зерна» и «Методы исследования»	Пустые или некорректные поля
Изменение записи в блоках «Тезаурус», «Новости», «Ученые», «Зерна» и «Методы исследования»	Корректно заполненные поля
Чтение записей в блоках «Тезаурус», «Новости», «Ученые», «Зерна» и «Методы исследования»	Выбран один из блоков
	Выходные данные
	Ошибка		+		+		+
	Корректный результат	+		+		+		+

Тестирование так же было проведено для системы генерации кода сервисов. Проведено тестирование по стратегии черного ящика и выполнена проверка достаточности тестов (см. табл. 4.4 и 4.5).

...