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

Текст из файла

МОСКОВСКИЙ ГОСУДАРСТВЕННЫЙ ТЕХНИЧЕСКИЙ УНИВЕРСИТЕТ

им. Н.Э. Баумана

Кафедра «Системы обработки информации и управления»

Курсовая работа

Москва – 2016

__________________________________________________________

Оглавление

Описание предметной области 3

Постановка задачи проектирования 3

Функциональные требований к проектируемой системе 3

Описание взаимодействия пользователя с системой 4

Диаграмма прецедентов 4

Диаграмма последовательностей 5

Архитектура системы 7

Диаграмма классов 8

Диаграмма пакетов 8

Структура базы данных 11

Пользовательский интерфейс 11

Диаграмма развертывания 15

Выводы 16

Описание предметной области

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

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

Постановка задачи проектирования

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

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

• Необходимо создать систему для общения пользователей

• Необходимо организовать оплату услуг через эту систему.

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

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

Функциональные требований к проектируемой системе

Анонимный пользователь должен иметь возможность зарегистрироваться/авторизоваться

Авторизованный пользователь должен иметь возможность:

• Писать сообщения в техподдержку и получать на них ответ

• Писать сообщения ремонтнику и получать на них ответ

• Оплачивать услуги онлайн

• Просматривать историю заказов и платежей

Описание взаимодействия пользователя с системой

Диаграмма прецедентов

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

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

Рис.1. Диаграмма прецедентов

Диаграмма последовательностей

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

Рис.2. Диаграмма последовательностей прецедента

«Написать сообщение ремонтнику»

Рис.3 Диаграмма последовательностей прецедента

«Зарегистрироваться»

Рис.4. Диаграмма последовательностей прецедента «Оплатить»

Архитектура системы

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

Диаграмма классов

На диаграмме классов отражена структура классов моделей. Все классы моделей наследуются от абстрактного класса Model. Модели в Django framework’е обладают гораздо большим функционалом, чем обычные объекты базы данных. Этот факт так же был отражен на диаграмме.

Рис.5. Диаграмма классов моделей

Диаграмма пакетов

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

1. Необходимо обеспечить максимально возможную независимость компонентов, а также удобство подключения и отключения компонентов.

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

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

1. Connections – модуль, отвечающий за настройки приложения (например, IP-адрес, адрес базы данных, язык, используемый в приложении) и за правильное соединения серверов.

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

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

4. Static – модуль, отвечающий за отдаваемую сервером статику: изображения, скрипты, стили и шрифты.

5. Templates – модуль, отвечающий за шаблоны веб-страниц.

Рис.6. Диаграмма пакетов

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

Рис.7. Диаграмма компонентов приложения

Структура базы данных

Рис.8. Структура базы данных

Пользовательский интерфейс

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

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

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

Со страницы истории заказов можно перейти на страницу истории платежей.

Рис.9. Диаграмма состояний

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

Рис.10. Диаграмма деятельности «Процесс просмотра истории платежей»

На временных диаграмме представлено поведение системы в прецедента «Отправка сообщения ремонтнику» и «Оплатить», как пользовательских действий. Линии жизни первой диаграммы:

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

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

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

DataBase – база данных, которая хранит данные: сообщения, заявки и т.д.

Ко второй диаграмме к вышеперечисленному добавляется новая линия жизни:

BankServer – сервер банка, с которым соединяется сервер работающего приложения, чтобы провести оплату услуг.

Рис.11. Временная диаграмма поведения системы в прецеденте

«Отправка сообщения ремонтнику»

Рис.12. Временная диаграмма поведения системы в прецеденте

«Оплатить»

Диаграмма развертывания

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

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

Рис.13. Диаграмма развертывания

Выводы

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

Характеристики

Тип файла документ

Документы такого типа открываются такими программами, как Microsoft Office Word на компьютерах Windows, Apple Pages на компьютерах Mac, Open Office - бесплатная альтернатива на различных платформах, в том числе Linux. Наиболее простым и современным решением будут Google документы, так как открываются онлайн без скачивания прямо в браузере на любой платформе. Существуют российские качественные аналоги, например от Яндекса.

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

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

Список файлов домашнего задания