результаты проверки на антиплагиат (1206298), страница 4
Текст из файла (страница 4)
22 Если любая часть транзакции выполнится неудачно, то будетпроизведен откат всей транзакции в исходное состояние. А если все шаги будутвыполнены успешно, то транзакция будет зафиксирована. Каждая транзакциядолжна проверяться на непротиворечивость в соответствии с настраиваемыми в 22системе правилами.3.6 Требования по сохранности информации при аварияхВ системе должно быть обеспечено резервное копирование данных. 1 Этонеобходимо будет обеспечивать с помощью инструментов управлениярезервного копирования.3.7 Требования по стандартизации и унификацииРазработка системы должна осуществляться с использованием стандартныхметодологий функционального моделирования: IDEF0, DFD иинформационного моделирования IE и IDEF1Х в рамках рекомендаций постандартизации Р50.1.028-2001 «Информационные технологии поддержкижизненного цикла продукции. Методология функционального моделирования».Моделирование должно выполняться в рамках стандартов, поддерживаемыхпрограммными средствами моделирования ERWin 4.х и BPWin 4.х 9 или Astah.Для работы с БД должен использоваться язык запросов SQL в рамках стандарта 220ANSI SQL-92 ( 2 третья версия языка запросов к базам данных SQL).4 Требования к функциям (задачам), выполняемым системой4.1 Блок администратора4.1.1 Подсистема контроля действий менеджеровПодсистема контроля действий менеджеров должна осуществлятьдобавление, обновление и хранение личных данных менеджеров такжевозможность изменения прав доступа (роли).
Должна быть предусмотренавозможность просмотра заявок, с которыми работал менеджер, а так жепросмотр туров, которые менеджер загрузил в систему. Это необходимоадминистратору для контроля действий менеджеров.4.2 Блок менеджера4.2.1 Подсистема обработки заявокПодсистема обработки заявок должна состоять из следующих модулей:4.2.1.1 Модуль новых заявокМодуль новых заявок должен реализовывать следующие функции: просмотринформации о поступивших заявках, как в кратком, так и в подробном виде;возможность перемещения заявки в модуль заявок менеджера, находящегося всистеме.4.2.1.2 Модуль заявок менеджера, находящегося в системеМодуль заявок менеджера, находящегося в системе должен реализовыватьследующие функции: просмотр информации о заявках, как в кратком, так и вподробном виде; возможность редактирования и подтверждения заявки;перемещение заявки в архив с указанием соответствующей причины.4.2.1.3 Модуль архива заявок21Модуль архива заявок должен реализовывать функцию просмотраинформации о заявках, как в кратком, так и в подробном виде.4.2.2 Ведение базы отзывов клиентов3.2.3 Подсистема управления справочной информациейПодсистема управления справочной информацией должна обеспечиватьведение следующих справочников:‒ 47 реестр «Категории туров»;‒ реестр «Способы передвижения»;‒ реестр «Страны»;‒ реестр «Курорты»;‒ реестр «Регионы»;‒ реестр «Населенные пункты».4.2.4.
Подсистема управления разделом вопросовПодсистема управления разделом вопросов должна осуществлятьдобавление, обновление, хранение и удаление вопросов, которые могутвозникнуть у клиента, которые будет использовать информационную Web –систему.4.3 Блок клиента4.3.1 Подсистема управления личными даннымиПодсистема управления личными данными включает в себя:‒ добавление личных данных пользователя;‒ редактирование существующих данных.4.3.2 Подсистема управления закладкамиДанная подсистема обеспечивает хранение истории изменений туров,22которые клиент добавляет в закладки;4.3.3 Модуль истории личных заявок4.3.4 Модуль истории личных отзывов5.
Требования к видам обеспечения5.1 Требования к информационному обеспечению5.1.1 Требования к составу, структуре и способам организации данных всистеме. 12Модель данных системы физически должна быть реализована вреляционной СУБД.5.1.2 20 Требования по применению систем управления базами данных.Для реализации хранения данных должна использоваться СУБД 1 MicrosoftSQL Server.5.2 Требования к лингвистическому обеспечению системыВсе прикладное программное обеспечение системы для организациивзаимодействия с пользователем должно использовать русский язык.5.3 Требования к программному обеспечению 42Для 2 описания объекта автоматизации должен использоваться Erwin 2 илиAstah. Для реализации алгоритмов манипулирования данными в системенеобходимо использовать стандартный язык запроса к данным SQL и егопроцедурное расширение.
Для организации диалога системы с пользователемдолжен применяться графический оконный пользовательский интерфейс. 1 Дляуправления Web – приложением должны использоваться следующие браузеры:IE 11, Edge 15, Firefox 53, Chrome 58, Safari 10.1, Opera 44 и выше с поддержкойJavaScript.235.4 Требования к техническому обеспечениюМинимальные требования к хостингу: процессор – 2 ядра с частотой 2ГГц,объем диска – 30 Гб, скорость подключения – 10 Мбит/с, размер оперативнойпамяти – 1500 Мб.
Персональные компьютеры пользователей должныудовлетворять требованиям, предъявляемым к типовым рабочим станциям.6 Требования к 20 методическому обеспечениюКомплексы нормативных документов на разработку информационнойсистемы:‒ ГОСТ 34.601– 90.
Автоматизированные системы. Стадии создания;‒ ГОСТ 34.602– 89. Техническое задание на создание автоматизированнойсистемы;‒ 20 РД 50– 34.126– 92 Рекомендации. Правила проведения работ при созданииавтоматизированных систем.2.2 55 Проектирование бизнес-процессов и структуры системыРазработка модели информационной системы осуществляется с помощьюобъектно-ориентированного подхода для автоматизации работы турагентства.Туроператор заключает с турагентом агентский договор, согласно которомуагенту поручается реализовывать туры, сформированные туроператором, завознаграждение.Работа информационной системы турагентства осуществляетструктурирование туров и представление их в удобном для пользователя виде,позволяет забронировать тур, кроме того, клиент может оставить отзыв о туре ипоставить оценку.Предметом автоматизации являются процессы работы с клиентами,систематизация, хранение, накопление данных, необходимых для24функционирования турагентства, бронирование туров, поисковое продвижениекоммерческих предложений (туров).При ведении личного кабинета, хранятся следующие данные: ФИО, датарождения, почта, номер телефона, туры в закладках, ближайшие туры,пройденные туры, отзывы.
Для того чтобы пользоваться услугамиинформационной системы (бронирование тура) пользователю необходимопройти регистрацию. При подтверждении бронирования менеджером наопределенный тур количество мест уменьшается.Проектирование информационной системы выполняется на основеобъектно-ориентированного подхода и языка UML.2.2.1 Разработка функциональной моделиДиаграмма вариантов использования описывает 16 функциональноеназначение системы или, другими словами, то, что бизнес-система должнаделать в процессе своего функционирования.
38Суть данной диаграммы: 15 проектируемая система представляется в видемножества актеров, взаимодействующих с системой с помощью, такназываемых вариантов использования. При этом актером 15 может быть любойобъект, субъект или система, взаимодействующая с моделируемой системойизвне. В 51 свою очередь вариант использования – это спецификация сервисов(функций), которые система предоставляет актеру. Другими словами, каждыйвариант использования определяет некоторый набор действий, совершаемыхсистемой при взаимодействии с актером. 15 Также два варианта использования,определенные в рамках одной моделируемой системы, 16 могут взаимодействоватьдруг с другом, 16 но характер этой связи будет отличаться от связи с актерами.При этом в модели никак не отражается то, каким образом будет реализованэтот набор действий.
В 11информационной системе турагентства можно выделить следующие вариантыиспользования:‒ подбор тура по заданным критериям;25‒ регистрация пользователя;‒ бронирование тура;‒ оставление отзыва;‒ формирование и модерация коммерческих предложений (туров);‒ модерация прав и аккаунтов.Так же выделим актеров, взаимодействующих в информационной системе:‒ администратор (главный менеджер) – сотрудник предприятия,отвечающий за добавление и контроль деятельности менеджеров;‒ менеджер – сотрудник предприятия, осуществляющий организациюпродаж и работу с клиентами;‒ авторизованный клиент – человек, который имеет возможностьдобавление туров в закладки, бронирование туров и оставление отзывов;‒ не авторизованный клиент – человек, который имеет возможностьпросмотра предложений.На рисунке 2.1 изображена контекстная диаграмма вариантов использованияинформационной системы турагентсва.26Рисунок 2.1 – Контекстная диаграмма вариантов использованияНа рисунке 2.2 показана декомпозиция варианта использования «Подбортура».
Для того чтобы клиент смог подобрать тур, ему желательно определитьдату поездки и какие-нибудь другие параметры (например, сезон,продолжительность, название) или же просто выбрать категорию тура(например, пляжный отдых или горные путешествия). После чего клиентвыбирает дату поездки.27Рисунок 2.2 – Диаграмма декомпозиции варианта использования«Подбор тура»Далее рассмотрим декомпозицию варианта использования «Бронированиетура», представленную на рисунке 2.3. На ней взаимодействуют два актера:пользователь и менеджер.Для того чтобы забронировать тур, клиенту необходимо после выбора тура,нажать кнопку «Забронировать».
После чего будет проверяться статус клиента,авторизован он или нет, а также проверка наличия свободных мест в туре. Есликлиент не авторизован, то он перенаправляется на страницу «Регистрация».После того, как клиент совершил все необходимые операции, в интерфейсеменеджера появляется заявка, и в зависимости от того подтвердит он ее или нет,клиенту должно прийти письмо с ответом. Если менеджер подтвердил заявку, тоданный тур будет добавлен в личный кабинет клиента в графу «Ближайшиетуры».28Рисунок 2.3 – Диаграмма декомпозиции варианта использования«Бронирование тура»Диаграмма автоматов показывает все возможные состояния, в которыхможет находиться объект, а также процесс смены состояний в 65 результатевнешнего влияния.Под состоянием понимается ситуация в ходе жизни экземпляра сущности,когда эта ситуация удовлетворяет некоторому условию, экземпляр выполняетнекоторые операции или ждет наступления 11 события.Например, для объекта его состояние может быть задано в виде набораконкретных значений атрибутов, при этом изменение этих значений будет 41приводить к изменению состояния моделируемого объекта.
41На рисунке 2.4 расположена контекстная диаграмма, которая моделируетреакцию системы при выборе клиентом пунктов меню. В системе существуеттри модуля: администратор, менеджер, клиент. Вход в любую из нихосуществляется после ввода логина и пароля.29Рисунок 2.4 – Контекстная диаграмма автоматовПримечание: closeApp() – закрытие программы.После инициализации программа переходит в стартовое состояние – работане авторизованного пользователя. Далее может быть осуществлен переход всостояние авторизация, где необходимо ввести логин и пароль, после чегопроизойдет провека подлинности пользователя и определение его прав доступа,на основе которых осуществляется переход в одно из трех состояний, каждое изкоторых представляет собой особый режим работы системы.В соответствии с разграничением полномочий, в зависимости от типазарегистрированного пользователя возможны три режима работы:‒ работа клиента в системе;‒ работа администратора в системе;‒ работа менеджера в системе.На рисунке 2.5 изображена диаграмма декомпозиции варианта30использования – инициализация модуля для менеджера, которая отображаетработу менеджера в системе.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
