Разработка прототипа веб-приложения "Репозиторий электронных ресурсов"

размер файла с презентацией;

дата создания;

автор (-ы);

тематика.

Журнал.

Сведения, которые должны быть указаны:

название журнала;

язык оригинала;

страна;

год публикации;

том;

выпуск (номер);

тип доступа (в открытом доступе; в относительно закрытом доступе (текст будет доступен только сотрудникам НИУ ВШЭ по логину и паролю; в полностью закрытом доступе (доступен только проверяющим отчеты, заявки на гранты и т.п.));

ссылка на электронный вариант;

описание местоположения печатного издания;

классификатор УДК;

классификатор ГРНТИ;

тематика.

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

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

Автор. Данная таблица содержит информация об авторе. Включает два поля: поле с идентификатором и поле с именем автора.

Город. Данная таблица содержит информацию об месте издательства. Включает два поля: поле с идентификатором и поле с названием города.

Составитель. Данная таблица содержит информация о составителе. Включает два поля: поле с идентификатором и поле с именем составителя.

Страна. Данная таблица содержит информацию о стране. Включает два поля: поле с идентификатором и поле с названием страны.

Язык, на котором написан источник. Данная таблица содержит информацию о текущем языке. Включает два поля: поле с идентификатором и названием.

Редактор. Данная таблица содержит информацию о редакторе. Включает два поля: поле с идентификатором и поле с именем редактора.

Редактор перевода. Данная таблица содержит информацию о редакторе. Включает два поля: поле с идентификатором и поле с именем редактора.

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

Грифы. Данная таблица содержит информацию о грифе. Включает два поля: поле с идентификатором и поле с названием грифа.

Язык оригинала источника. Данная таблица содержит информацию об оригинальном языке источника. Включает два поля: поле с идентификатором и названием.

Издательство. Данная таблица содержит информацию об издательстве. Включает два поля: поле с идентификатором и названием издательства.

Тематика. Данная таблица содержит информацию о тематике. Включает два поля: поле с идентификатором и названием.

Переводчик. Данная таблица содержит информацию о переводчике. Включает два поля: поле с идентификатором и именем переводчика.

Тип печатного издания. Данная таблица содержит информацию о типе печатного издания. Включает два поля: поле с идентификатором и названием типа.

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

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

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

Интересы. Данная таблица содержит информацию об интересах преподавателей. Включает два поля: поле с идентификатором и поле с названием.

Факультет. Данная таблица содержит информацию о факультете. Включает два поля: поле с идентификатором и поле с названием.

Департамент. Данная таблица содержит информацию о департаментах. Включает два поля: поле с идентификатором и поле с названием.

Логин. Данная таблица содержит информацию о логине. Включает два поля: поле с идентификатором и поле с логином в символьном формате.

Пароль. Данная таблица содержит информацию о пароле. Включает два поля: поле с идентификатором и поле с паролем в символьном формате.

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

3.1 Описание реализации интеллектуального поиска

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

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

В настоящее время существует большое количество поисковых систем, однако они все имеют общую архитектуру, представленную на рисунке 3.2.

Рисунок 3.2 показывает, что система информационного поиска выполняет следующие три базовые функции:

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

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

3) Сравнение - вычисления оценок релевантности между запросами и документами, на основе которых определяется множество результатов, возвращаемое пользователям.

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

Model = [D, Q, F, R(q, d)],(1)

где

D - множество логических представлений документов;

Q - множество логических представлений информационных потребностей (запросов);

F - платформа для моделирования документов, запросов;

R(d, q) - функции вычисления близости между документами и запросами [13].

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

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

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

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

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

Онтология состоит из 4-х компонентов O = <C, R, I, A>, где C - множество классов, представляющих интересуемые систему понятия в определенной предметной области; R - множество отношений (свойств или предикатов), которые связывают между собой понятия; I - множество экземпляров, в котором каждый экземпляр может быть объектом одного или более классов, и может быть связан с другим экземпляром или литеральным значением (строкой, числом и т.д.) с использованием некоторого отношения; A определяет множество аксиом.

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

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

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

Процесс создания онтологии включает в себя несколько этапов:

Спецификация. На этом этапе определяются цели создания онтологии, предполагаемое использование и потенциальные пользователи.

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

Формализация. На этом этапе трансформируется концептуальная модель в формальную или вычислительную.

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

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

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

определение классов в онтологии (понятий в рассматриваемой предметной области);

определение слотов (свойств и атрибутов каждого понятия);

описание допускаемых значений этих слотов и ограничений, наложенных на слоты;

отображение иерархии классов (подкласс - надкласс);

определение других отношений между классами.

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

Графическое представление созданной онтологии показано в приложении F.

Семантический поиск основывается на основании запросов к онтологии. Алгоритм включает в себя следующие шаги:

1.Разбиение запроса на триплеты. Компоненты триплетов определяются в результате сопоставления терминов запроса и понятий онтологии предметной области.

2.Определение триплетов метаданных документов, семантически близких к запросу. Этот шаг включает несколько этапов:

1)Если существует свободный триплет из множества триплетов описания документа, который соответствует триплету поискового запроса, то переходим на этап 2, иначе - на этап 4.

2)Формируется SPARQL-запрос на основании данного триплета и ему присваивается метка занятости.

3)Если результат выполнения запроса над множеством триплетов документов положительный, то запоминаем найденные результаты, иначе возвращаемся на этап 1.

4)Рассчитывается семантическая близость триплетов документов триплетам запроса.

3.Производится ранжирование и сортировка результатов поиска.

На псевдокоде алгоритм может быть описан следующим образом:

FUNCTION Семантический_поиск (исходный_запрос)

//Разбиение запроса на триплеты

Триплеты = Разбиение_на_триплеты (запрос)

L0: WHILE (количество_свободных_триплетов > 0)

Результат = Sparql_запрос (свободный_триплет)

Свободный_триплет = занятый

IF (Результат!= 0)

Запомнить_результат (результат)

ELSE Переход на L0

Расчет_семантической_близости (триплеты, результат).

Результат = Ранжирование (результат)

RETURN Результат.

Пример реализации запроса к онтологии разрабатываемой системы:

1 шаг - выделяем определения объектов и отношений с их атрибутами:

Article_in_book [article_in_book_name =>> STRING;

year=>> STRING;...

Author_name =>> Author].

Book [book_name =>> STRING;...]. …

2 шаг - описываем правила:

FORALL Book1, Article1

Book1: Article_in_book [cooperatesWith ->> Article1] <-

Article1: Article_in_book [cooperatesWith ->> Book1].

FORALL Book1, Author1

Author1: Author [author_name ->> Book1] <->

Author1:Book [book_name ->> Book1].

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

Технический проект

Процесс проектирования систем включает в себя пять стадий, а также связи между ними с детальным описанием действий, моделей и результатов каждой стадии. Ниже представлены названия и краткое содержание работ на каждой стадии в соответствии с ГОСТ 19.102 - 77 [5]:

Техническое задание:

постановка задачи;

обоснование проведения научно-исследовательских работ;

разработка технического задания.

Эскизный проект:

описание структуры входных и выходных данных;

уточнение методов решения;

описание общий алгоритм;

разработка документации эскизного проекта.

Технический проект:

уточнение структуры входных и выходных данных;

разработка алгоритмов;

представление форм данных;

описание структуры программы;

описание конфигурации технических средств разработки;

представление плана работ.

Рабочий проект.

выбор технологий для реализации решения;

программирование и отладка;

разработка документов;

подготовка и проведение испытаний;

корректировка программы и документов по итогам испытаний.

Внедрение.

передача программы и документов для сопровождения;

оформление акта приемки и передачи;

передача в ФОНД алгоритмов и программ.

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

Разработка требований к системе

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

Возможность внесения данных о пользователе.

Возможность настройки системы.

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

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

Возможность поиска по ключевым словам.

Возможность расширенного поиска по названию документа, по названию ресурса, по типу документа, по автору, по периоду публикации, а также по тематике в соответствии с классификатором УДК.

Возможность полнотекстового поиска.

Возможность работы в авторизованном режиме (для сотрудников кафедры).

Возможность работы без авторизации (для студентов).

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

Возможность работы с документами следующих форматов: ".doc", ".docx", ".xls", ".xlsx", ".pdf", ".txt", ".ppt", ".pptx".

Возможность работы с ресурсами на русском и английском языках.

Поиск только по документам файловой системы.

Организация мониторинга изменений файловой системы.

Условия эксплуатации системы являются предпосылками для описания нефункциональных требований:

Платформа Windows 7 и выше.

Параметры технических средств совпадают с параметрами технических средств для операционной системы Microsoft Windows 7.

Отсутствие затрат, связанных с разработкой системы.

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

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

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

Все полученные требования представлены в документе "Техническое задание", которое представлено в приложении E. Техническое задание, которое разработано в соответствии с ГОСТ 34.602-89 [6].

Выбор инструментальных средств разработки

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

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

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

Таблица 3.1. Функциональные требования и возможность их реализации

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

3.2 Разработка архитектуры репозитория

Архитектура системы (в данном случае) - это описание (модель) основной компоновки и взаимодействия частей системы. В разделе показана структура взаимодействия основных компонентов системы.

Определение позиции хранилища данных в архитектуре системы

Система предназначена для поиска электронных ресурсов в уже существующей файловой системе, которая и является хранилищем документов. Для хранения метаданных документа и данных о работе системы необходимо использовать базы данных. Совокупность баз данных и файловой системы представляет собой хранилище данных. Пользовать взаимодействует с базой данных при помощи интерфейса, поэтому общая архитектура системы ни что иное, как интерфейс взаимодействия пользователя с базой данных (рис. 3.5) [14].

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

Общая архитектура информационно-поисковой системы

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

В служебной базе данных хранится:

служебная информация о системе и о ее модулях;

данные о пользователях (рис. 3.6).

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

Архитектура служебной базы данных информационно-поисковой системы

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

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

по названию документа;

по типу документа;

по автору;

по названию издания/учебно-методического материала/контрольно-измерительного материала в содержании документа;

по периоду публикации (диапазон дат, а именно годов);

по тематике (в соответствии с классификатором УДК).

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

На основе приведенных результатов предлагается следующая архитектурная модель хранилища данных в информационно-поисковой системе (рис. 3.7).

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

Рисунок 3.7. Архитектурная модель хранилища данных информационно-поисковой системы

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

В настоящее время процесс работы с документами организован с использованием классической архитектуры "Файл-сервер" (рис. 3.8).

Рисунок 3.8. Классическое представление архитектуры "Файл-сервер"

Таким образом, сервер осуществляет хранение данных и кода программы, а клиент производит обработку данных. У такого типа архитектуры имеются как достоинства, так и недостатки, которые представлены в таблице 3.2.

Таблица 3.2. Достоинства и недостатки архитектуры "Файл-сервер"

Достоинства архитектуры	Недостатки архитектуры
Многопользовательский режим работы с данными.	Проблемы многопользовательской работы с данными: последовательный доступ, отсутствие гарантии целостности.
Удобство централизованного управления доступом.	Низкая производительность (зависит от производительности сети, сервера, клиента).
Низкая стоимость разработки.	Плохая возможность подключения новых клиентов.
Высокая скорость разработки.	Ненадежность системы.
Невысокая стоимость обновления и изменения ПО.

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

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

Рисунок 3.9. Представление многоуровневой архитектуры "Клиент-сервер"

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

Консоль администратора (позволяет конфигурировать систему и вводить данных о пользователях).

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

модуль "искателя" документов;

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

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

после выбора источника, компонент искателя собирает из него данные для анализа и индексации.

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

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

модуль извлечения текста;

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

модуль обработки текста на ЕЯ;

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

Нормализует символы текста, а именно приводит все символы к нижнему регистру.

Обрабатывает с использованием методов лингвистического анализа, которые включают в себя:

графематический; на выходе - отдельно выделенные элементы структуры текста;

морфологический; на выходе - определенные морфологические характеристики слова и его словоформы;

синтаксический; на выходе - синтаксическая зависимость слов в предложении

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

Этапы обработки текста на ЕЯ

Все результаты обработки в результате сохраняются в служебной БД.

модуль индексации;

Существует два варианта построения индекса:

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

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

модуль поиска;

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

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

модуль ввода данных.

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

Пользовательский интерфейс(позволяет пользователю взаимодействовать с базой данных, используя доступ к модулю управления).

Сервер с СУБД.

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

Схема потоков данных информационно-поисковой системы

Для выбора подходящей системы управления базами данных требуется произвести анализ существующих СУБД с точки зрения следующих критериев:

бесплатная лицензия;

производительность (скорость обработки запросов влияет на скорость выдачи результата поиска);

надежность (обеспечивает целостность данных);

масштабируемость (система должна иметь возможность расширения, в связи с увеличением числа пользователей, объема хранимых данных и количества обрабатываемой информации);

поддержка операционной системы MS Windows 7 и более поздних версий.

3.3 Проектирование функциональной схемы репозитория

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

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

Функциональная схема информационно-поисковой системы

Работа системы основана на подключении к трем серверам:

сервер с СУБД;

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

сервер с компонентой поиска.

Определение дискового пространства для репозитория

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

Поисковый индекс будет строиться по двум сетевым дискам локальной файловой системы: общий диск "S" (содержит 15 985 документов) и диск сотрудников кафедры "H" (содержит 55 248 документов) (см. рис. 3.13).

Свойства диска "S" и диска "H"

Получили примерные параметры рабочей нагрузки небольшой системы:

общее число документов - 100 000;

максимальный размер страницы документа: 1 Мб;

память (на один сервер): 2 Гбайта RAM;

число процессоров (на один сервер): 1 или 2;

построений индексов: 1 в каждый момент времени;

обработка запроса: 1 запрос в секунду.

Определение прецедентов

Выделим прецеденты, ориентируясь на функциональные требования:

Внести информацию о пользователе.

Настроить систему поиска.

Добавить информацию в базу данных сведений о документе.

Изменить информацию в базе данных сведений о документе.

Выполнить поиск по ключевым словам.

Выполнить расширенный поиск.

Выполнить полнотекстовой поиск.

Авторизоваться в системе (для сотрудников кафедры).

Поддержка работы без авторизации (для студентов).

Поддержка работы с документами определенных форматов.

Поддержка работы с документами на русском и английском языках.

Выполнить поиск только по документам файловой системы.

Организовать мониторинг изменений файловой системы.

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

Таблица 3.3. Распределение требований по субъектам и прецедентам

№	Функциональное требование	Субъект	Прецедент
1	Возможность внесения информации о пользователе.	Администратор, СУБД	Внести информацию о пользователе.
2	Возможность настройки системы.	Администратор, СУБД	Настроить систему поиска.
3	Возможность редактирования и добавления информации в базу данных сведений о документе (база данных метаданных).	Работник кафедры, СУБД	Добавить информацию в базу данных сведений о документе.
4	Возможность изменения информации в базе данных сведений о документе (база данных метаданных).	Работник кафедры, СУБД	Изменить информацию в базе данных сведений о документе.
5	Возможность поиска по ключевым словам.	Работник кафедры, СУБД, ФС	Выполнить поиск по ключевым словам.

Построение алгоритма работы системы с помощью UML диаграмм

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

Прецедент "Внести данные о пользователе"

Выполняется администратором после авторизации в системе. В главной форме Администратор нажимает на кнопку "Добавить пользователя". После чего открывается окно для ввода информации о пользователе. Администратор заполняет поля формы. Затем "Модуль ввода данных" корректность введенной информации. Если формат данных корректен, то добавляет соответствующую запись в служебную БД (таблица информации о пользователе), и Администратору выдается сообщение об успешном добавлении пользователя. Если формат введенных данных некорректный, то Администратору выводится сообщение об ошибке, и предлагается повторить попытку, для чего отображается форма ввода информации о пользователе. Диаграммы представлены в приложении H (рисунок H.1. и H.2).

Прецедент "Настроить систему"

Прецедент выполняется администратором после авторизации в системе. В главной форме Администратор нажимает на кнопку "Настройка системы". Затем открывается окно для ввода конфигураций модулей системы. Администратор задает свойства модуля "поисковика" системы, модуля индексации и модуля поиска. Свойства могут быть заданы как для одного модуля, так и сразу для всех. Затем "Модуль ввода данных" корректность введенной информации. Если формат данных корректен, то добавляет соответствующую запись в служебную БД (таблица информации о пользователе), и Администратору выдается сообщение об успешном добавлении пользователя. Если формат введенных данных некорректный, то Администратору выводится сообщение об ошибке, и предлагается повторить попытку, для чего отображается форма ввода информации о пользователе. Диаграммы представлены в приложении H (рисунок H.3. и H.4).

Прецедент "Добавить информацию в базу данных сведений о документе"

Метаданные документа вводятся сотрудником кафедры после авторизации, если документ был найден и информация о нем выдана в поисковом результате. Тогда напротив каждого выданного документа отображается кнопка "Добавить информацию о документе". Затем сотрудник кафедры нажимает на кнопку "Добавить информацию о документе". Открывается и отображается форма с полями сведений о документе. Сотрудник заполняет поля. Затем "Модуль ввода данных" корректность введенной информации. Если формат данных корректен, то добавляет соответствующую запись в служебную БД (таблица информации о пользователе), и Администратору выдается сообщение об успешном добавлении пользователя. Если формат введенных данных некорректный, то Администратору выводится сообщение об ошибке, и предлагается повторить попытку, для чего отображается форма ввода информации о пользователе. Диаграммы представлены в приложении H (рисунок H.5. и H.6).

Прецедента "Изменить информацию в базе данных сведений о документе"

Информацию о документе может изменить сотрудник кафедры после авторизации, если документ был найден и информация о нем выдана в поисковом результате, а также, если информация о документе присутствует. Тогда напротив каждого выданного документа отображается кнопка "Изменить информацию о документе". Далее работник кафедры нажимает на кнопку "Изменить информацию о документе". Открывается и отображается форма с полями сведений о документе с данными, введенными ранее. Сотрудник изменяет поля. Затем "Модуль ввода данных" корректность введенной информации. Если формат данных корректен, то добавляет соответствующую запись в служебную БД (таблица информации о пользователе), и Администратору выдается сообщение об успешном добавлении пользователя. Если формат введенных данных некорректный, то Администратору выводится сообщение об ошибке, и предлагается повторить попытку, для чего отображается форма ввода информации о пользователе. Диаграммы представлены в приложении H (рисунок H.7. и H.8).

Прецедент "Выполнить поиск по ключевым словам"

Реализуется сотрудником кафедры после авторизации. На главной странице отображается строка для поиска. Пользователь вводит поисковый запрос на естественном языке. Далее нажимает на кнопку "Найти". Модуль поиска принимает поисковый запрос, затем осуществляет поиск документов по заранее построенному индексу и производит ранжирование. В результате выдаются все найденные документы. Диаграммы представлены в приложении H (рисунок H.9. и H.10).

Прецедент "Выполнить расширенный поиск"

Прецедент производится сотрудником кафедры после авторизации в системе. На главной странице отображается кнопка "Расширенный поиск", после нажатия на которую открывается новая веб-форма с полями для расширенного поиска. Сотрудник заполняет необходимые поля. Затем требуется нажать на кнопку "Найти". Модуль поиска выполняет поиск по БД метаданных и по заранее созданному индексу, а также производит ранжирование. В поисковом результате выдаются все найденные документы. Диаграммы представлены в приложении H (рисунок H.11. и H.12).

Прецедент "Выполнить полнотекстовой поиск"

Прецедент визуализирует алгоритм работы системы поиска, а также взаимодействие между выделенными модулями. Система запускает "поисковик" системы и получает для него свойства из служебной БД, заданные администратором. "Поисковик" системы выполняет поиск источника и имя файловой системы, после чего собирает все документы для анализа и индексации. Затем модуль извлечения текста определяет кодировку текста и при необходимости производит преобразование документа в UTF-8 кодировку. Модуль обработки текста выполняет нормализацию символов и производит обработку текста методами лингвистического анализа. Результаты обработки сохраняются в служебной БД. Модуль индексации использует полученные результаты обработки текста и производит построение по ним индекса, который также сохраняет в служебной БД. Затем этот индекс используется модулем поиска во время выполнения операций поиска. В результате поиска отображаются все найденные документы. Диаграммы представлены в приложении H (рисунок H.13. и H.14).

Прецедент "Авторизоваться в системе"

Авторизация в системе проводится администратором или сотрудниками кафедры. Данные о сотрудниках кафедры также добавляются администратором системы. На главной странице репозитория отображается кнопка "Войти". Пользователь нажимает на кнопку "Войти" и открывается форма для авторизации. Пользователь заполняет поля формы авторизации и нажимает на кнопку "Войти". Данные, которые ввел пользователь, проверяются с соответствующими данными из БД информации о пользователях. Если данные введены верно, то выдается сообщение об успешной авторизации и открывается главная страница репозитория с расширенными функциональными возможностями (помимо поиска по общему диску “S”, после авторизации становится доступным поиск по сетевому диску “H”, в котором хранятся документы преподавателей). В случае некорректности введенных данных выводится сообщение об ошибке. В результате поиска содержатся все найденные документы. Диаграммы представлены в приложении H (рисунок H.15. и H.16).

Выбор инструментальных средств для разработки системы

Выбор языка программирования

Языки программирования, существующие на сегодняшний день, можно разделить на следующие группы [8]:

универсальные языки высокого уровня;

специализированные языки разработчика программного обеспечения;

специализированные языки пользователя;

языки низкого уровня.

К универсальным языкам высокого уровня относятся такие языки, как C++, C#, Java, Modula, Ada, COBOL, FORTRAN и другие. В этой группе лидером является язык C++, достоинствами которого являются:

масштабируемость;

возможность создания обобщенных алгоритмов для разных типов данных;

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

Язык программирования C++ на данный момент не имеет аналогов, однако схожий с ним язык программирования C# считается более простым и надежным языком программирования по сравнению с C++, кроме того он сохраняет лучшие черты языков программирования С/С++, на основе которых он был создан. Также язык C# обладает другими достоинствами[8]:

является объектно-ориентированным языком;

реализует наследование и универсализацию;

учитывает все возможности Framework.Net, ставшему надстройкой над операционной системой.

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

Выбор среды программирования

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

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

Существуют среды разработки, предназначенные только для одного языка программирования, такие как Turbo Pascal, Borland С++, GNU toolchain, DrPhython. Однако существуют среды, предназначенные для нескольких языков, такие как Microsoft Visual Studio и Eclipse.

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

В ходе разработки принято решение использовать технологию.NET Framework и язык программирования C#, поэтому средой в качестве среды для разработки репозитория электронных ресурсов выбрана Microsoft Visual Studio. Microsoft Visual Studio находится в свободном доступе для скачивания, поэтому использование данной среды не повлечет за собой денежные затраты.

3.4 Выбор СУБД

Самыми широкоиспользуемыми на данный момент СУБД являются MySQL, PostgreSQL и MSSQL Server, а также Oracle, SQLite, Firebird и другие СУБД. Выделим критерии для оценки, являющиеся наиболее значимыми при выборе СУБД:

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

Производительность (скорость обработки запросов значительно влияет на скорость загрузки данных).

Надежность - обеспечение целостности данных.

Масштабируемость.

Поддержка языков программирования.

Поддерживаемые операционные системы.

После выделения критериев составим сравнительную таблицу (табл. 3.4).



Таблица 3.4. Сравнение СУБД

Название СУБД	MySQL	PostgreSQL	MSSQL Server
Бесплатность	+/-	+	+/-
Производительность	1	3	2
Надежность	3	2	1
Масштабируемость	2	1	3
Операционные системы	Windows, Unix, Linux, Mac	Windows, Unix, Linux, Mac	Windows
Поддержка языков программирования	Ada, C, C#, C++, D, Eiffel, Erlang, Haskell, Java, Objective-C, OCaml, Perl, PHP, Python, Ruby, Scheme, Tcl.	.Net, C, C++, Java, Perl, Python, Tcl.	.Net, Java, PHP, Python, Ruby,Visual Basic.

Одним из основных критериев оценки качества работы системы является быстрота отображения результата поиска, поэтому наиболее подходящим вариантом в текущих условиях разработки является СУБД MySQL.

Для работы с MySQL с MS Visual Studio принято решение использовать "MySQL Connector / NET". Следовательно, для разработки системы выбраны следующие инструментальные средства разработки (табл. 3.5).

Таблица 3.5. Инструментальные средства разработки системы

Средство разработки	Выбранное средство разработки
Язык программирования	C#
Среда для разработки	Microsoft Visual Studio
СУБД	MySQL
Коннектор среды разработки и СУБД	MySQL Connector / NET

Данные проведенного анализа в рамках технического проектирования задокументированы в соответствии с РД 50-34.698-90 и представлены в документе "Пояснительная записка к техническому проекту"

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

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

Авторизация пользователей.

Поиск электронных ресурсов по ключевым словам, а также по названию и по автору.

Отображение и редактирование информации об электронных ресурсах.

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

Пример выполнения на языке программирования C# выглядит так:

static string connection = @»Data Source=(LocalDB)\MSSQLLocalDB;AttachDbFilename=C:\Users\кепнргошл\Desktop\repository-2016-05-20\repository\repository\App_Data\Repository.mdf;Integrated Security=True»;

SqlConnection conn = new SqlConnection(connection);

SqlDataAdapter da = new SqlDataAdapter()

da = new SqlDataAdapter("SELECT Author.author_name, Article_in_book.article_in_book_name, Themes.theme_name FROM Article_in_book INNER JOIN Article_in_book_Author ON Article_in_book.id_article_in_book = Article_in_book_Author.id_article_in_book INNER JOIN Author ON Article_in_book_Author.id_author = Author.id_author INNER JOIN Theme_Article_in_book ON Article_in_book.id_article_in_book = Theme_Article_in_book.id_article_in_book INNER JOIN Themes ON Theme_Article_in_book.id_theme = Themes.id_theme", conn);

SqlCommandBuilder cb = new SqlCommandBuilder(da);

DataSet ds = new DataSet();

da.Fill(dataTable);

GridView1.DataSource = dataTable;

GridView1.DataBind();

conn.Close();

Кроме того, основной задачей являлась реализация поиска по ключевым словам (для прототипа), его реализация на языке программирования C# выглядит следующим образом:

DataTable dt = new DataTable();

dt.Columns.Add(new DataColumn("author_name", typeof(string)));

dt.Columns.Add(new DataColumn("article_in_book_name", typeof(string)));

for (int i = 0; i < GridView1.Rows.Count; i++)

DataRow dr;

GridViewRow row = GridView1.Rows[i];

dr = dt.NewRow();

for (int j = 0; j < GridView1.Columns.Count; j++)

{

if (GridView1.Rows[i].Cells[j].Text.ToString()!= null)

if (GridView1.Rows[i].Cells[j].Text.ToString().Contains(TextBox1.Text))

{

dr[j] = row.Cells[j-1].Text + row.Cells[j].Text;

dt.Rows.Add(dr);

GridView1.DataSource = dt;

GridView1.DataBind();

На рисунке 3.14 представлено отображение главной страницы прототипа системы "Репозиторий электронных ресурсов". Веб-страница содержит:

строку поиска, в которую пользователь вводит поисковый запрос;

кнопку, при нажатии на которую осуществляется поиск ресурса;

кнопку входа в систему и личный кабинет;

документы, которые были добавлены в систему последними.

При нажатии на кнопку "Найти" осуществляется поиск по ключевым словам в базе данных, пример работы изображен на рисунке 3.15.

При нажатии на кнопку "Войти в личный кабинет" открывается окно авторизации (см. рис. 3.16), где пользователь (преподаватель) должен ввести свои логин и пароль. Веб-страница авторизации содержит:

строку, в которую пользователь вводит логин;

строку с паролем;

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

string instance = login_text.Text;

Отображение главной страницы программы

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

string attr = password.Text;

string connection3 = @"Data Source=(LocalDB)\MSSQLLocalDB;AttachDbFilename=C:\Users\кепнргошл\Desktop\repository-2016-05-20\repository\repository\App_Data\Repository.mdf;Integrated Security=True";

SqlConnection conn3 = new SqlConnection(connection3);

conn3.Open();

SqlCommand cmd5 = new SqlCommand("Select id_login, login, id_password, password from Login, Password Where login = @instance and password = @attribute", conn3);

cmd5.Parameters.AddWithValue("@instance", instance);

cmd5.Parameters.AddWithValue("@attribute", attr);

using (SqlDataReader MyReader = cmd5.ExecuteReader())

Response.Redirect("Personal_page.aspx");

conn3.Close();

При нажатии на кнопку "Войти" открывается новая страница, на которой отображается информация о публикациях и интересах текущего пользователя (см. рис. 3.17). Веб-страница содержит:

кнопку, при нажатии на которую пользователь может изменить информацию о себе (открывается новая форма "Изменить данные пользователя");

Отображение страницы с авторизацией

кнопку, позволяющую добавить публикацию;

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

При нажатии на кнопку "Редактировать" открывается форма "Изменить данные пользователя" (см. рис. 3.18) которая содержит поля для редактирования имени, факультета, департамента и почты, а также кнопку сохранения изменений в базе данных. При нажатии на кнопку "Сохранить" измененные значения перезаписываются в базе данных.

Отображение личного кабинета

кнопку, позволяющую добавить публикацию;

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

При нажатии на кнопку "Редактировать" открывается форма "Изменить данные пользователя" (см. рис. 3.18) которая содержит поля для редактирования имени, факультета, департамента и почты, а также кнопку сохранения изменений в базе данных. При нажатии на кнопку "Сохранить" измененные значения перезаписываются в базе данных.

Также на главной странице, кроме поиска по ключевым словам, имеется переход на расширенный поиск путем нажатия на кнопку "Расширенный поиск" (см. рис. 3.19). Данная веб-страница содержит:

поле для ввода поискового запроса;

выбор параметров поиска (в названии, аннотации или в ключевых словах);

панель с выбранными тематиками, которые можно выбрать при нажатии на кнопку "Добавить" или удалить при нажатии на кнопку "Очистить";

Отображение формы редактирования данных пользователя

панель с выбранными авторами, которые можно выбрать при нажатии на кнопку "Добавить" или удалить при нажатии на кнопку "Очистить";

список с типами публикаций;

поля для ввода промежутка лет, за которые была выпущена публикация.

информационный поисковый автоматизированный электронный

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



При нажатии на кнопку "Найти" выполняется поиск с учетом выбранных параметров.



Заключение

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

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

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

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

Анализ существующих систем по хранению и поиску электронных ресурсов.

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

Проектирование системы "Репозиторий электронных ресурсов".

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

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