АВТОМАТИЗАЦИЯ ОБУЧЕНИЯ ТЕХНОЛОГИИMSF: РАЗРАБОТКА ВИРТУАЛЬНОГО СОБЕСЕДНИКА ДЛЯ СБОРА ИНФОРМАЦИИ ДЛЯ РАЗВЕРТЫВАНИЯ ПРОГРАММНЫХ ПРОДУКТОВ



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

Репин Дмитрий Юрьевич

АВТОМАТИЗАЦИЯ ОБУЧЕНИЯ ТЕХНОЛОГИИMSF: РАЗРАБОТКА ВИРТУАЛЬНОГО СОБЕСЕДНИКА ДЛЯ СБОРА ИНФОРМАЦИИ ДЛЯ РАЗВЕРТЫВАНИЯ ПРОГРАММНЫХ ПРОДУКТОВ

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

студента образовательной программы «Программная инженерия»

по направлению подготовки09.03.04 Программная инженерия

Рецензент

Директор ООО «Белая логика»

М.А. Андронов

Руководитель

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

____________________

А.В. Бузмаков

Пермь, 2018год

Аннотация

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

Оглавление

Введение

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

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

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

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

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

Объект работы: процесс проведения. деловой игры по развертыванию программного обеспечения по технологии MSF.

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

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

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

Задачи:

  1. Анализ накопленного опыта
  2. Разработка виртуального собеседования
  3. Разработка системы администрирования
  4. Опытная эксплуатация системы

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

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

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

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

В первой главе будет описана деловая игра по технологииMSF «Развертывание», выявлены недостатки в предыдущей ее версии, будут сформированы требования к новой версии системы.

  1. MSF как метод разработки программного обеспечения
  2. MSF (MicrosoftSolutionFramework) – методология разработки программного обеспечения, предложенная корпорациейMicrosoft.MSF опирается на практический опытMicrosoft и описывает управление людьми и рабочими процессами в процессе разработки решения.

    ПоMSF процесс разработки программного обеспечения имеет спиральную форму. Итерация цикла представлена на рис. 1.1:

    Рисунок .1. МодельMSF [1]

    Каждая итерация состоит из следующих этапов:

    1. Envision (Выработка концепции). На первом этапе создается основной состав проектной группы и готовится описание проекта, оговариваются рамки проекта.
    2. Planning (Планирование). На этом этапе составляются планы проекта, в которые входят функциональные спецификации, дизайн разрабатываемого приложения, подготовку рабочих планов, оценку затрат и сроков.
    3. Developing (Разработка). На этапе разработки пишется код приложения, подготавливается документация.
    4. Stabilizing (Стабилизация). На этом этапе проводится тестирование приложения, устраняются обнаруженные ошибки. Внимание фокусируется на предполагаемых сценариях использования приложения
    5. Deploying (Развертывание). На этапе развертывания происходит внедрение готового приложения в рабочий процесс, происходит налаживание сопровождение приложения, закрывается или продлевается контракт с заказчиком.
      1. Деловая игра «Развертывание»
    6. Для изучения технологии MSF в НИУ ВШЭ-Пермь используется ряд деловых игр:Envision&Planning, «Стабилизация» и «Развертывание». В ходе каждой из игр студенты попадают в сложные ситуации, которые как можно более точно имитируют прецеденты на реальном производстве.

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

      1. Сбор информации о подразделениях фирмы «ОбалдеИТ».
      2. Формирование расписания развертывания.
      3. Подведение итогов.
      4. Корректировка расписания после полученной информации в ходе подведения итогов

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

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

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

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

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

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

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

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

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

          1. Требования к   разрабатываемой системе
          2. Исходя из описания автоматизации системы, были сформированы требования к разрабатываемой системе:

            Использование:

            1. Анализ вопроса: филиал, сотрудник, вопрос.
            1. Выбор филиала.
            2. Выявление наличия в указанном филиале фирмы сотрудника с указанной должностью.
            3. Определение ответа сотрудника на заданный вопрос.

            Администрирование:

            1. Возможность  импортирования сотруднику пары вопрос-ответ из области знаний другого сотрудника.
            2. Редактирование областей знаний сотрудников.
            3. Возможность просмотра заданных вопросов.

            Полный список требований к системе представлен в приложении А.

            Глава 2. Проектирование системы

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

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

              Как уже было сказано, первые два года игра проводилась в ручном режиме. При этом были сохранены все заданные в ходе игры вопросы и данные на них ответы. Пары «вопрос-ответ» были привязаны к конкретным должностям в конкретных филиалах. Таким образом, была получена некоторая база четверок «филиал – должность – вопрос – ответ». Готовый входной файл содержал более 400 записей. Выбор проектных решений был скорректирован, с поправкой на размер составленного файла.

              Были рассмотрены следующие варианты проектных решений:

              1. Поиск по полному совпадению вопроса. Наиболее простой вариант, где введенный запрос пользователя дословно сопоставляется с одним из вопросов, имеющихся в базе. Такой вариант реализации не учитывает возможные вариации вопросов, использование синонимов и требует чрезвычайно большую базу вопросов-ответов. На практике этот вариант даже не пробовали реализовать.
              2. Поиск по набору ключевых слов. Усложненная версия первого варианта, где в запросе пользователя производится поиск наборов ключевых слов, которые могут стоять в произвольном порядке и могут быть перемешаны с «шумовыми словами». На базе этой технологии была разработана версия виртуального собеседника для той же деловой игры. Однако ее работа  имела очень низкую точность и для практического применения оказалась не пригодна.
              3. Искусственные нейронные сети (ИНС). Искусственная нейронная сеть – упрощенная модель человеческого мозга. Сеть обучают на базе имеющихся вопросов, после чего она работает с запросами пользователя и выдается результат на основе ранее пройденного обучения. Разработка виртуального собеседника с использованием нейронных сетей рассматривалась, однако, база из 430 входных записей слишком мала для обучения ИНС, поскольку отношение элементов выборки к количеству признаков очень мало[2]. Исходя из следствия теоремы Арнольда–Колмогорова-Хехт–Нильсена[3], велика вероятность переобучения ИНС.
              4. Онтологии. Онтология – способ формализации некоторой области знаний с помощью концептуальной схемы. Как правило такая схема состоит из структур данных, содержащей все релевантные классы объектов, их связи и правила, принятые в этой области. Этот метод решения рассматривался для решения поставленной задачи, однако был отвергнут в пользу лексико-синтаксических шаблонов в связи с опытом в использовании их.
              5. Лексико-синтаксические шаблоны (ЛСШ). Лексико-синтаксический шаблон - структурный образец языковой конструкции, позволяющий обрабатывать исходный текст, учитывая лексические и синтаксические характеристики естественного языка. Для русского языка это падежи, времена, наклонения, склонения, числа и т.д. В основном шаблоны используются для автоматической обработки текста: выявления языковых конструкций, классификации текстов, поиска словоформ, изменения текстов с учетом заданных параметров (синонимов, выражений). Помимо этого, с помощью лексико-синтаксических шаблонов есть возможность распознавать альтернативы частей исходного текста, что дает возможность задавать синонимы определенным словам. Предельно упрощенной формой ЛСШ являются БНФ.

              Год назад была разработана версия виртуального собеседника с использованием лексико-синтаксических шаблонов. Она имела почти такой же интерфейс, но была куда проще с технической точки зрения. Был взят список вопросов, которые студенты задавали в ходе проведения предыдущих деловых игр. Эти вопросы были несколькими студентами вручную преобразованы в ЛСШ (в расчете на то, что  студенты будут и дальше задавать такие же вопросы). Это позволило в сжатые сроки получить набор из примерно сотни шаблонов. Версия была применена на практике, но точность работы собеседника было на уровне 30%, что не является достаточным показателем для имитации диалога.

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

              1. Количество шаблонов. Было разработано всего около сотни шаблонов, количество альтернатив в которых было крайне ограничено.
              2. Отсутствие концептуальной целостности. Не было установлено никаких правил или соглашений о построении шаблонов. Каждый из студентов составлял шаблоны на свое усмотрение.
              3. Недостаточный учет многообразия словоформ и синонимии русского языка.
              4. Помимо проблемы в самих шаблонах, отсутствовала возможность администрирования приложения. Любые административные действия (просмотр информационной базы и ее корректировка) мог выполнять  только программист- автор системы средствами СУДБ SQL.

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

              Вторая версия виртуального собеседника призвана решить проблемы предыдущей системы, разработанной на основе ЛСШ

              1. LSPL – язык лексико-синтаксических шаблонов
              2. Предполагается, что вопросы, обрабатываемые виртуальным собеседником, будут задаваться на русском языке, поэтому было решено взять за основу утилиту, которая также работает с шаблонами, которые бы сопоставлялись с русским текстом. Было решено использовать языкLSPL (Lexico-SyntaxicPatternLanguage). Этот язык предназначен для описания конструкций русского языка с целью их представления в системах извлечения информации из текстов, однако помимо этого он может сравнивать текст с шаблоном, который представляет набор символов на любом языке. Разработка языка началась в 2007 году, но он продолжает изменяться и дополняться по сей день.

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

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

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

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

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

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

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

                1. Проектирование алгоритма работы системы
                2. Поскольку было решено использовать ЛСШ, то  вопрос системе будет считаться входными данными для обработки ЛСШ. Каждый из вопросов неделим и каждому из них соответствует один ответ, заложенный в систему. Это допущение создано исходя из того, что все вопросы достаточно простые по структуре и содержанию. Исходя из этого, было принято решений на каждый из вопросов создать один неделимый шаблон, который бы описывал вопрос. Исходя из этого, каждый из ответов системы является неделимым и в полной мере разрешает заданный вопрос.

                  Между вопросами отсутствуют сложные контекстные связи, за исключением двух: отделение и сотрудник. Отделение студент для каждого вопроса указывает явно. Список сотрудников, при этом, для каждого отделения свой: в одном ответы могут давать 6 разных сотрудников, а в другом лишь трое, должности могут иметь разные названия (например, директор, начальник, менеджер). При этом считаем, что в каждом отделении каждую должность занимает только один человек.

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

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

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

                  Разработчики языкаLSPL предоставили утилиту для анализа текста на соответствие ЛСШ. А именно, утилита позволяет сопоставить заданный текст с заданным набором шаблонов и выявить тот шаблон (или те шаблоны), которые соответствуют различным частям данного текста.

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

                  Пусть анализируемый текст равен:

                  «Сколько в вашем отделении фирмы установлено компьютеров?»

                  Сопоставляемые шаблоны представлены в табл.2.1.

                  Таблица 2.. Упрощенные лексико-синтаксические шаблоны

                  Наименование ЛСШ

                  Содержание ЛСШ

                  Ответ

                  SKF

                  числительное <Сколько> {шумовые  слова} существительное <Фирма> {шумовые  слова} существительное <Компьютер>

                  32

                  SSF

                  числительное <Сколько> {шумовые  слова} существительное <Фирма> {шумовые  слова} существительное <Сотрудник>

                  32

                  SOF

                  числительное <Сколько> {шумовые  слова} существительное <Отделение> {шумовые  слова} существительное <Фирма >

                  6

                  SO

                  числительное <Сколько> {шумовые  слова} существительное <Отделение>

                  6

                  OF

                  существительное <Отделение> {шумовые  слова} существительное <Фирма >

                  да

                  Результатом работы утилиты представлены в табл. 2.2:

                  Таблица 2.2. Результат работы утилиты

                  Наименование ЛСШ

                  Границы текста

                  Фрагмент текста

                  SKF

                  1-56

                  Сколько в вашем отделении фирмы установлено компьютеров

                  SSF

                  -

                  -

                  SOF

                  1-32

                  Сколько в вашем отделении фирмы

                  SO

                  1-26

                  Сколько в вашем отделении

                  OF

                  17-32

                  отделении фирмы

                  Из табл. 2.2 видно, что различные части анализируемого текста соответствуют различным шаблонам.

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

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

                  Студентам заранее не известны должности сотрудников, работающих в данном филиале.  Поэтому студент может назвать должность не так, как она может быть заложена в системе. Эту проблему решает словарь синонимов. Каждый список синонимов представлен в виде ЛСШ. Утилита получает на вход все списки синонимов (соответствующие шаблоны) всех должностей в выбранном филиале, после чего они вместе с запрашиваемой должностью подаются на вход утилите. Утилита в свою очередь возвращает шаблон, которому соответствует запрашиваемая должность. Если утилита не возвращает ничего, пользователю возвращается сообщение о том, что сотрудник с такой должностью не работает в фирме.

                  Когда определен сотрудник, к которому адресован вопрос, из базы данных выбираются все компетенции, которыми располагает данный сотрудник. Далее названия шаблонов всех компетенций, вместе с заданным студентом вопросом,  подаются на вход утилите. Утилита возвращает шаблон той компетенции, о которая была поставлена в соответствие заданному вопросу. Если такой шаблон найден, студент получат ответ, привязанный к найденному шаблону. Если утилита не вернула ни шаблона, студенту возвращается сообщение о том, что сотрудник не знает ответа на заданный вопрос. Такой алгоритм позволяет определить студенту как факт работы сотрудника в отделении, так и компетенции этого сотрудника. Для более наглядного представления работы алгоритма, были построеныIDEF0 диаграмма (Рис 2.3.) и диаграмма последовательностей (Рис 2.4.)

                  Рисунок 2.3.IDEF0диаграмма алгоритма

                  Рисунок .4. Диаграмма последовательностей алгоритма

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

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

                    1. Название: Постановка вопроса системе

                    Акторы: Студент

                    Описание: Студент заходит в систему под своим именем и паролем, указывает сотрудника и задает вопрос системе.

                    1. Название: Определение существования сотрудника в филиале

                    Акторы: Студент

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

                    1. Название: Редактирование компетенций сотрудников филиала

                    Акторы: Администратор

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

                    1. Название: Просмотр заданных вопросов системе.

                    Акторы: Администратор

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

                    Рисунок 2.1. Диаграмма активностей

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

                    Рисунок 2.2. Диаграмма последовательностей

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

                      1. Филиал.

                      Свойства:

                      А) Имя. Тип - строковый

                      Описание: У каждого филиала свои уникальные характеристики такие как месторасположение, количество и комплектация ЭВМ, количество сотрудников и их квалификация.

                      1. Сотрудник.

                      Свойства:

                      А) Имя.Тип строковый.

                      Б) Название шаблона. Тип строковый.

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

                      1. Компетенция.

                      Свойства:

                      А) Название шаблона. Тип – строковый.

                      Б) Текст ответа. Тип – строковый.

                      В) Должность сотрудника

                      Описание: Небольшая область знаний, которой обладает сотрудник, прикрепленный к филиалу.

                      1. Запись о вопросе.

                      Свойства:

                      А) Время. Тип –DateTime

                      Б) Заданный вопрос. Тип – строковый

                      В) Имя сотрудника. Тип – строковый

                      Г) Ответ на вопрос. Тип – строковый

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

                      ДиаграммаERD представлена на Рис 2.5

                      Рисунок 2.5.ERD диаграмма

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

                      Глава 3. Разработка системы

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

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

                        Определим стек технологий для разработки веб-приложения виртуального собеседника. Было решено разрабатывать приложение на платформе .Net с использованием фреймворкаAsp.Net для разработки сайта. Основным языком разработки являетсяC#, однако помимо этого используются языки:HTML для описания веб-страниц,XML для задания конфигурации приложения иLSPL для задания лексико-синтаксических шаблонов.

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

                        1. Яндекс словарь. Как ранее было сказано, в данной статье описан способ реализации собеседника, который не требует большого объема входной выборки. Однако исходная выборка для более широкой работы системы искусственно увеличивается за счет словаря синонимов. Однако, этот словарь нельзя использовать непосредственно во время использования, поскольку предоставляемоеAPI имеет ежедневное ограничение на количество запросов.
                        2. LSPL.LSPL (Lexico-SyntaxicPatternLanguage) – язык, предназначенный для формального описания конструкций русского языка с целью их представления в системах извлечения информации из текстов. К сожалению разработчики не предоставилиdll файл для использования его в системе, таким образом инструмент используется через утилиту с помощью запускаbat файла. Стоит отметить, что для этого компонента нет актуальной документации, поэтому учиться его использовать придется в процессе разработки.
                        3. LemmaSharp.LSPL шаблоны требуют на вход слова в начальной форме. Для решения этого этапа потребовалась отдельная библиотека.
                        4. MSSQL. Как было написано выше, Яндекс словарь имеет ограничение на количество ежедневных запросов. Для того, чтобы во время работы не обращаться к словарю за синонимами, было решено получить их ранее и хранить их в базе данных.



                        1. Похожие работы, которые могут быть Вам интерестны.

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

                          2. Разработка программы сбора информации на языке Python

                          3. Понятие информации. Общая характеристика процессов сбора, передачи, обработки и накопления информации

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

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

                          6. Разработка графического приложения для программных проектов на Agile

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

                          8. Конструирование банком структурированных финансовых продуктов, оценка эффективности продуктов для банка и инвестора

                          9. Учет модальностей восприятия учебной информации в процессе обучения

                          10. АНАЛИЗ И РАЗРАБОТКА МЕРОПРИЯТИЙ ПО СТАБИЛИЗАЦИИ ФИНАНСОВОГО СОСТОЯНИЯ ПРЕДПРИЯТИЯ ПО ПРОИЗВОДСТВУ МЯСА И МЯСНЫХ ПРОДУКТОВ