Математическое и программное обеспечение для формализации приоритетов пользователя с целью повышения эффективности использования сетевых сервисов

Число пользователей, которые используют в повседневной жизни мобильные устройства, такие как КПК, смартфоны или коммуникаторы, постоянно растет. В свою очередь функциональность таких устройств претерпела в последнее время значительные изменения и их возможности сопоставимы уже с возможностями обычных персональных компьютеров. Это позволяет пользователям решать при помощи этих устройств «оффлайновые» и «онлайновые» задачи типичные для настольных компьютеров. Вот только небольшой круг таких задач: органайзер, менеджмент файлов, использование мультимедийных возможностей (просмотр видео и прослушивание аудио), работа с документами (текстовые документы, электронные таблицы и презентации), работа с электронной почтой и использование интернета. Т. е. потребности мобильных пользователей можно сравнить с потребностями пользователей стационарных компьютеров. Но, тем не менее, мобильные устройства все еще имеют ограниченные ресурсы, например энергетические или связанные с объемами хранимых данных, а так же ограниченные возможности ввода-вывода информации. Подходящим решением для преодоления данных ограничений является возможность использования пользователями мобильных устройств сетевых сервисов. Сетевые сервисы представляют собой некоторую инкапсулированную функциональность, которую пользователь может однозначно идентифицировать и удаленно использовать. В качестве функциональности сервисов могут выступать не только услуги, исконно ориентированные на решение проблем в сфере вычислительной техники (как-то конвертирование файлов или распечатка документов), но и чисто бытовые услуги, например бронирование авиабилетов или номера в гостинице. Одно из препятствий для использования «онлайновой» функциональности — это высокая стоимость связи и относительная не распространенность необходимой инфраструктуры. Данная отрасль рынка информационных технологий находится сейчас на стадии своего развития, но является очень перспективной. Этому свидетельствуют большой интерес и инвестиции в данную область со стороны таких крупных компаний как Уос1а/опе[85], Т-МоЫ1е[86], ЫоИа[87] и Мсгауо//[88]. Другим препятствием на пути повсеместного внедрения сетевых сервисов является отсутствие стандартных технологий, направленных на автоматизацию процесса использования сервисов. Повсеместно разрабатываемые в данный момент технологии для семантического описания и поиска сервисов, позволяющие автоматизировать процесс использования сервисов, достаточно нетривиальны. Это очень сильно усложняет их применение в условиях реальной жизни даже для квалифицированных специалистов. Следовательно, целесообразна разработка средств, направленных на облегчение применения и использования подобных технологий.

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

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

На рисунке 1 изображена схема взаимодействия разнообразных устройств. Можно выделить три составляющих данной структуры: стационарная сеть (на рисунке обозначена как Интернет[89]), беспроводная сеть и шлюз, который их связывает. Основными факторами, определяющими работу стационарных сетей, является стабильность подключения пользователя к сети, его относительно постоянное физическое местонахождение и возможность наличия в подобных сетях централизованных управляющих узлов. Эти факторы позволяют использовать достаточно дешевые и быстрые способы подключения к сети, например, такие как DSL[3] или локальная сеть (LAN)[4], а так же использовать стандартные и достаточно простые механизмы использования сетевых ресурсов. Беспроводные сети, в свою очередь, характеризуются противоположными факторами: зачастую отсутствие централизованных узлов управления, динамическое, нестабильное подключение к сети и изменяющееся пространственное положение пользователя, которое в большой степени влияет на качество соединения с сетью. Естественно, это определяет стоимость и скорость использования сети. Наиболее распространенные подключения в данном случае — это точки доступа WLAN[5], беспроводные Ad-hoc сети [6], GPRS[7] или EDGE[8] сети и в меньшей степени, развивающиеся UMTS[9] сети.

Еще одним характерным отличием между использованием беспроводных и стационарных сетей является тип устройства, применяемого для подключения к сети. В стационарных сетях это в основном настольные ПК, а в беспроводных сетях мобильные устройства типа КПК[10] или смартфоны[11]. Смартфоны мы не будем брать в расчет в силу еще больших технических ограничений, чем у КПК. Существует еще возможность использования ноутбуков в обоих типах сетей, но пользователь зачастую теряет мобильность передвижения. Многообещающей перспективой на будущее выглядят, так называемые, UMPC{Ultra-Mobile PC)[12] - ультра компактные персональные компьютеры, обладающие сенсорным экраном и полноценной операционной системой (в случае UMPC — это Windows ХР). UMPC представляет собой не какое-то конкретное устройство, а концепцию создания мобильных ПК. В силу того, что на рынке только появилось первое поколение подобных устройств, они не избавлены от «детских болезней», например, таких как довольно малое время автономной работы. Исходя из всего этого, этого мы будем рассматривать только два типа устройств — ПК и КПК. Процессорная мощность и объем памяти современных КПК удовлетворяют практически всем требованиям, необходимым для нормального функционирования сетевых сервисов. Главной проблемой, мешающей полноценному использованию КПК в качестве мобильного терминала для сетевых сервисов, остаются ограниченные возможности ввода-вывода информации (в силу малых размеров экрана и отсутствия клавиатуры) и высокая стоимость использования мобильных сетей (имеется в виду коммерческих сетей). Из этого следует, что наиболее проблематично использование сетевых сервисов в условиях беспроводных сетей.

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

Беспроводная сеть N.

Интернет *.

Рисунок 1. Использование мобильных и стационарных сетей.

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

Второй вариант организации беспроводной сети это, так называемые, ас1-кос-сети [90]. Основной характеристикой данного подхода является отсутствие центрального элемента в сети. Вся функциональность и управление сетью распределяются между узлами, составляющими эту сеть. Узлы, в свою очередь, присоединяются к сети и покидают ее динамически. Отдельные устройства (узлы) взаимодействуют напрямую с другими устройствами. Они так же могут взаимодействовать с более удаленными устройствами, находящимися вне пределов прямой досягаемости, в несколько этапов (английский термин «кор «- прыжок), используя в качестве посредников соседние устройства. Сервисы, в таких сетях, предоставляются любыми узлами и зачастую носят не коммерческий характер. Данные обстоятельства накладывают определенные ограничения на функциональность сети и сервисов. В частности, отсутствие центральных узлов, влечет за собой необходимость применения распределенных механизмов управления сервисами. Другими словами, в подобных сетях не возможно применение технологий для предоставления сервисов, которые используются в стационарных сетях, а требуется разработка оригинальных механизмов.

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

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

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

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

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

Основной тенденцией последних лет в области предоставления сервисов является исследование возможностей автоматизации процесса использования сервисов[91]. Повсеместно разрабатываемые в данный момент технологии для семантического описания[92] и поиска сервисов, позволяющие автоматизировать процесс использования сервисов, достаточно нетривиальны. Это очень сильно усложняет их применение в условиях реальной жизни даже для квалифицированных специалистов. Следовательно, целесообразна разработка средств, направленных на облегчение применения и увеличение эффективности использования подобных технологий[93]. Целью данного диссертационного исследования является разработка математического и программного обеспечения для механизмов предоставления пользователям поддержки, с целью повышения эффективности использования сервисов. В качестве языка описания сетевых сервисов применяется технология семантического описания сервисов DSD (DIANE Service Descriptions). Данная технология представляет собой многообещающий инструмент для семантического описания сетевых сервисов, а так же для автоматизации поиска и управления сервисами [94].

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

Во второй главе рассматривается концептуальная сторона предлагаемого подхода к предоставлению поддержки при использовании сервисов. Разрабатывается архитектура системы поддержки использования сервиса (СПИС) и ее компонент с применением методов объектно-ориентированного и функционального анализа.

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

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

Исследования проводились в рамках федеральной целевой программы «Интеграция науки и высшего образования Российской Федерации на 20 022 006 гг.» по проекту «Фундаментальные исследования и новые технологии проектирования сложных технических систем» и частично поддержаны грантом РФФИ 03−07−90 242 «Интернет-комплекс поддержки выполнения проектов фундаментальных исследований сложных систем с применением интеллектуальных технологий на базе экспертных систем» (2003;2005 гг.).

Практические и теоретические исследования диссертационной работы выполнялись в ходе научно-исследовательского проекта DIANE (Dienste In Ad-hoc Netzen).

3.4 Основные выводы по третьей главы.

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

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

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

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

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

4. Разработка прототипа СПИС и оценка эффективности его работы.

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

4.1 Разработка требований к архитектуре прототипа СПИС.

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

Прототип СПИС должен представлять собой программный продукт, предназначенный для инструментальной поддержки проведения комплекса исследований, направленных на решение проблем в области предоставления сетевых сервисов. В качестве подобных задач, выступают не только задачи поддержки использования сервисов, решаемые в данном диссертационном исследовании, но и задачи комбинированного[60] и контекстно-зависимого[61] использования сервисов. Данное обстоятельство накладывает отпечаток, как на характеристики всей системы, так и на предоставляемую ей функциональность. Но в первую очередь, прототип СПИС предназначен для проверки и тестирования концептуальных, объектных и формальных моделей, разработанных в ходе данного диссертационного исследования. Таким образом, прототип СПИС должен предоставлять набор средств необходимых для полнофункциональной работы всех элементов концептуальной и формальной моделей СПИС.

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

1. Прототип должен быть реализован на платформо-независимой технологии Java[ 38]. Данное требование продиктовано необходимостью гибкой интеграции и совместного использования прототипа с существующей системой СУС DSD, которая выполнена на технологии Java. Применение этой технологии вызвано тем, что исследовательские работы в проекте ведутся на разных системных платформах, и при совместном использовании прототипов не должно возникнуть проблем несовместимости.

2. Второе требование вытекает из первого — это наличие СУБД, которая предоставляет возможность использования реляционных таблиц в контексте программного кода Java. СУБД должна поддерживать стандарт языка SQL.

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

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

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

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

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

4.2 Анализ компонентов прототипа СПИС и их программная реализация.

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

Рассмотрим более подробно каждый программный класс прототипа СПИС. На рисунке 21 изображены основные классы программной реализации СПИС, а так же указаны их наиболее важные функции. Взаимодействие между классами представлено в виде стрелок, связывающие классы, с обозначением протокола или способа взаимодействия. Как уже упоминалось выше, каждому элементу концептуальной модели СПИС соответствует программный класс. СУС DSD и клиентское приложение так же изображены в виде программных классов, но на самом деле представляют собой комплексные структуры, более чем из одного класса. Для СУС DSD указаны основные функции, при помощи которых осуществляется внешнее использование данной системы. Проектирование функций и атрибутов классов выполнялось на основе разработанных во второй главе объектных диаграмм. На стрелках, связывающих классы, обозначены соответствующие методы взаимодействия объектов друг с другом. Метка TCP обозначает взаимодействие объектов через сетевые сокеты {Network Socket[67]) при помощи протокола ТСР[ 68]. Метка Java function call обозначает вызов одним объектом функции другого объекта. Прямоугольник с надписью Java Intrface в объектном классе обозначает наличие обобщенного программного интерфейса[69], на основании которого был разработан данный класс.

Теперь разберем отдельные классы программного прототипа СПИС более детально. Как видно из рисунка 21, АГИ является частью реализации клиентского приложения.

Рисунок 21. Разработанная структура программных классов СПИС.

Заключение

.

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

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

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