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

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

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

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

2.3 Проектирование интерфейса

туристский предложение информационный проект

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

Интерфейс пользователя должен быть:

·        дружелюбным;

·        графический;

·        простой в использовании;

·        удобство в работе для пользователя;

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

·        надежность для использования базы данных;

·        поддерживать платформу Windows.

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

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

·        система должна позволять вводить, редактировать дерево классификации признаков (названия критериев);

·        система должна отображать путь, по которому проходит турист (названия критериев);

·        система должна предлагать пользователю список признаков и соответствующим им критериям в сортированном виде от максимальной конверсии до минимальной конверсии (конверсия);

·        система должна позволять связывать критерии между собой в измеряемую смысловую связь (степень связанности критериев);

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

·        протокол беседы должен содержать в себе группу, признаки и критерии с которыми согласился собеседник, т.е. цепочку вопросов и не принятые группы, признаки и критерии (названия критериев);

·        система должна записывать предпочтения туристов (фамилия, имя, телефон, e-mail, названия точки проведения отдыха, способ передвижения);

·        журнализация беседы (журнал беседы);

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

·        внесение изменений в классификацию («воронка продаж»);

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

·        выгрузка данных в формате excel и word.

Цепочку вопросов в дальнейшем можно предлагать, как скрипты. Особенностью данных скриптов будет то, что они выстроены по согласованию с туристом, т. е. это «скрипт да». Элемент управления «Не согласен» позволяет выстроить «скрипт да нет», т.е. он содержит логику построения диалога для тех, кто данной системой не пользуется.

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

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

Для начала беседы в системе записывается ID клиента и ID менеджера, выбирается группа и записывается, выбирается признак и записывается. В случае если турист не согласился с признаком у нас IDK не записался, тогда снимается флажок. Как только нажимается кнопка «согласие», появляется запись. Также добавим параметры дата и время для измерения, за какое время турист пришел к положительному или отрицательному решению.

В соответствии сданными функциями представим интерфейс на рисунке 2.13.

Рисунок 2.13 Проектирование интерфейса

Если турист пришел в первый раз то в поле «ввод нового туриста» открывается форма для ввода контактных данных туриста, таких как фамилия, имя отчество, e-mail, телефон, количество человек и сроки поездки, см. рис. 2.14. После того, как мы ввели данные о туристе, турист выбирается в поле «Турист», см. рис. 2.15, а в поле «Менеджер» выбирается менеджер осуществляющий поиск предложения, см. рис. 2.16. Турист и менеджер выбираются из выпадающего списка и у туриста для быстрого поиска фамилия имя отчество вводиться в поле для поиска. После чего система выделяет необходимую фамилию и менеджер, нажимая на нее начинает вести структурированный диалог.

Рисунок 2.14 Поле для ввода нового туриста

Рисунок 2.15 Выбор туриста

Рисунок 2.16 Выбор менеджера

После того как были выбраны турист и менеджер, выбирается «Группа признаков». Из группы признаков выбирается «Классификационный признак» и если признак не совсем понятен туристу, то нажимается кнопка «Информация о выбранном классификационном признаке», см. рис. 2.17 и турист может ознакомиться с данным признаком, понять его сущность.

Рисунок 2.17 Кнопка «Информация о выбранном классификационном признаке»

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

Выбор осуществляется кнопками «да», «нет». Кнопка «да» означает, что турист согласен с выбором, а кнопка «нет», что не согласен, см. рис. 2.18.

Рисунок 2.18 Кнопки управления для выбора

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

Рисунок 2.19 Слабосвязанные критерии

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

Рисунок 2.20 Результат выбора

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

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

Вывод

В данной главе рассмотрены методология разработки Feature Driven Development (функционально-ориентированная разработка).

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

Глава 3. Частичное прототипирование информационной системы

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

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

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

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

·        «Стадии»;

·        «ASP.NET»;

·        «SQL Microsoft SQL Server»;

·        «Настройка БД».

Рисунок 3.2 Генерация типов данных

В строке соединения меняем server на .\SQLEXPRESS и создаем в database любую несуществующую базу данных, в нашем случае это будет KRITERII, при генерации она сама создается. И отмечаем галочкой «БД полномочий и БД приложений», см. рис. 3.3. Для реализации нашей базы данных, см. рис. 3.4., воспользуемся стандартной «Картой типов» представленной в программном продукте Flexberry.

Рисунок 3.3 Генерация типов данных и редактирование стадии

Рисунок 3.4 Карта типов

После того, как мы изменили настройки, нажимаем кнопку «Сохранить и закрыть». Далее необходимо повторить процедуру для будущих C# приложений, представленную на рисунке 3.5. Для этого мы правой кнопкой нажимаем на:

·        «Стадия»;

·        «ASP.NET»;

·        «C#»;

·        «Свойства модели».

Рисунок 3.5 Настройка для C# приложений

В строке «Название компании», «Название продукта», «Каталог для исходящего кода» вводим свои названия латиницей, см. рисунок. 3.6.

Рисунок 3.6 генерация типов данных для C# приложений

Для реализации C# приложений воспользуемся стандартной «Картой типов», см. рис. 3.7.

Рисунок 3.7 Карта типов для C# приложений

После того, как мы изменили настройки, нажимаем кнопку «Сохранить и закрыть».

На диаграмме, представленной, на рисунке 3.1. на классе нажимаем «Редактировать свойства» и в раскрывшемся окне нажимаем кнопку «Атрибуты», см. рисунок. 3.8. Кнопка «NotNull» позволяет показать атрибут, как обязательный или необязательный, поэтому как будет отмечено, так данный параметр будет генерироваться на уровне кода. Если мы указываем «NotNull», то данная функция не позволит закрыть приложение, пока не будет введено значение в данную строку, поэтому важно определиться на уровне модели какие параметры важны для введения. После того, как мы определились какие параметры для нас важны, нажимаем кнопку «Сохранить и закрыть».

Рисунок 3.8 Редактирование свойств

После того, как мы выбрали важные для нас атрибуты диаграмма классов, представленная на рисунке 3.1. измениться. Важные значения атрибутов будут выделены знаком «+».

На основе построенной модели предметной области построим модель прототипа приложения. Для этого, см. рис. 3.9. правой кнопкой мыши встаем на «Систему» далее «ASP.NET», «Утилиты», «Создать представления, формы и приложения».

Рисунок 3.9 Построение модели прототипа приложения

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

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

На рисунки 3.11. представлено автоматическое создание дополнительной модели.

Рисунок 3.11 Автоматическое создание дополнительной модели

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

Рисунок 3.12 Форма представление

Рисунок 3.13 Форма представления Е и L

Далее мы редактируем атрибуты, для этого нажимаем на кнопку рис. 3.14. и 3.15.

Рисунок 3.14 Кнопка для редактирования атрибутов

Рисунок 3.15 Редактирование атрибутов

И кнопками «стрелочка влево» и «стрелочка вправо» редактируем нужные нам атрибуты, которые будут представлены на форме.

После этого закрываем и сохраняем и Flexberry создает автоматически диаграмму с тремя стереотипами, представленную на рисунке 3.16. Стереотип «application» представляет собой приложение в нем создаются настройки. И стереотипы «editform» и «listform» для списковой формы и формы представления.