список использованных источников 3 страница

2.3 Описание архитектуры системы

В п.п. 2.3.1 - 2.3.3 будет приведено описание основных компонентов системы. В данном разделе не рассматривается вопрос об аппаратном обеспечении системы, так как в соответствии с ТЗ (приложение А, раздел 3, п.п. 3.2), выбор аппаратного обеспечания системы остается на усмотрение заказчика.

2.3.1 База данных

База данных представляет собой реляционную БД, спроектированную исходя из функционального описания системы, представленного в разделе 2. Краткое описание основных таблиц спроектированной БД предствлено в таблице 2.1:

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

2.3.2 Сервер

С архитектурой отладочного сервера Django можно ознакомится в официальной документации Django [ссылка на документ]. Здесь отметим, что отладночный сервер не требует каких-либо специального настроек.

2.3.3 Web-приложение

Основу системы EBIS составляет web-приложение, разработанное с использованием web-фреймоврка Django.

Архитектура web-приложения ПО построена на основе модифицированного шаблона MVC (Model-View-Controller) - MTV (Model-Template-View). Выбор шаблона MTV для построения архитектуры системы был выбран исходя из того, что данный шаблон является основой фреймворка Django. Контроллер классической модели MVC примерно соответствует уровню, который в Django называется Представление (англ. View), а презентационная логика Представления реализуется в Django уровнем Шаблонов (англ. Template).

Бизнес-логика системы EBIS заключена в двух Django-приложениях: Accounts и Forum.

Обобщенная структурная схема web-приложения представлена на рисунке 2.3:

Рисунок 2.3 - Обобщенная структурная схема разработанного web-приложения

Приложение Accounts отвечает за регистрацию и аутентификацию пользователей. В приложении Accounts используется единственная, встроенная в Django, модель User.

Приложение Forum является ключевым приложением сервиса, и отвечает за создание вопросов, создание ответов на вопросы, а так же осуществляет управление рейтингами вопросов. В приложении Forum используются модели Question, Answer, User, Post, Tag, Attachment, Vote.

Кроме того, в разработанной системе используется ряд встроенных в фреймворк Django приложений, а именно: admin, auth, contenttypes, sessions, messages, staticfiles. Данные встроенные приложения содержатся в модуле django.contrib.

2.4 Принятие основных решений по видам обеспечений системы

2.5 Принятие основных решений по безопасности и отказоустойчивости системы

Безопасность системы основывается на средствах, имеющихся во фреймоврке Django. В п.п. 2.5.1 - 2.5.5 будут рассмотрены основные моменты по обеспечению безопасности разработанного web-приложения.

Защиту базы данных от несанкционированного локального доступа предполагается осуществлять с использванием средств серверной ОС (БД хранится в одном файле, права доступа к которому можно контролировать стандартными средствами ОС).

Так же отметим решения, принятые по другим вопросам безопасности, а именно:

13. Код web-приложения находится вне корня web-сервера. Это не позволит злоумышленнику отобразить его в виде текста, или запустить его на выполнение.

14. Ограничение попыток аутентификации пользователя в единицу времени. Таким образом, система будет защищена от brute-force атак по подбору пароля.

15. Ограничение на размер принимаемых файлов. Таким образом, система будет защищена от некоторых атака класса DOS.

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

2.5.1 Защита от межсайтового скриптинга (XSS)

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

Шаблоны Django экранируют специальные символы, которые обычно создают проблемы для HTML. В частности, экранирование специальных символов осуществляются следующие автоматические замены:

11) < заменяется на &lt;

21) > заменяется на &gt;

22) ' (одинарная кавычка) заменяется на &#39;

23) " (двойная кавычка) заменяется на &quot;

24) & заменяется на &amp.

2.5.2 Защита от подделки межсайтового запроса (CSRF)

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

CSRF защита работает, проверяя метку с текущим временем в каждом POST запросе. Она не позволяет злоумышленнику просто сформировать POST запрос и создать возможность другому авторизованному пользователю неумешленно отправить эту форму. Злоумышленнику потребуется знать содержимое метки, которое сильно зависит от пользователя (используются cookie).

Django обладает встроенной защитой против большинства типов CSRF атак.

Для реализации данного метода защити, в каждом POST запросе используется CSRF-token.

2.5.3 Защита от внедрения SQL (SQL-injection)

Внедрение SQL — это тип атаки, когда недобросовестный пользователь имеет возможность выполнить в базе данных определённый SQL запрос. Результатом выполнения такого запроса может быть удаление или даже утечка данных.

При использовании Django ORM созданный SQL запрос будет правильно экранирован соответствующим драйвером базы данных.

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

2.5.4 SSL/HTTPS

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

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

1. Настроено перенаправление HTTP запросов на HTTPS. Перенаправление осуществляется с помощью функционального слоя Django.

2. Использованы "безопасные" cookie. Если браузер изначально подключается через HTTP, что характерно для большинства браузеров, то существует возможность утечки пользовательских cookie. По этой причине в настройках проекта использованы параметры SESSION_COOKIE_SECURE и CSRF_COOKIE_SECURE. Таким оразом, браузер будет отправлять данные cookie только через HTTPS соединения.

3 Разработка структур данных и основных решений

3.1 Разработка основных компонентов системы

Основными компонентами разработанной системы являются приложения (applications) и шаблоны (templates). В свою очередь, приложения состоят из моделей (models) и представлений (views).

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

25) django.contrib.auth – система аутентификации;

26) django.contrib.contenttypes - управление объектами "contenttypes";

27) django.contrib.sessions – управление сессиями.

28) django.contrib.staticfiles – приложение для работы со статическими файлами;

29) django.contrib.admin - приложение для администрирования системы;

30) accounts - менеджер учетных записей;

31) forum - приложение для управления сервисом вопросов и ответов.

Приложение 1-5 входят в состав фреймоворка Django. Подробное описание данных приложений доступон в официальной документации фреймворка Django [ссылка на документацию]. Приложения 6-7 разработанны специально для системы EBIS. Описание данных приложений приведено в разделах 3.1.2 – 3.1.3.

Модель - отображение информации о данных, с которыми работает приложение. Каждая модель представлена классом, унаследованным от django.db.models.Model. Каждая модель содержит несколько атрибутов, каждый из которых отображает поле в таблице базы данных. Каждое поле представлено экземпляром класса Field – например, CharField для текстовых полей и DateTimeField для полей даты и времени. Это указывает Django какие типы данных хранят эти поля.

Представление – это “тип” страниц приложения, которое является функцией для обработки запроса и использует шаблон для генерации страницы. Django выбирается представление анализируя запрошенный URL (часть URL-а после домена). Чтобы из URL-а получить представление, Django используется так называемый ‘URLconf’. URLconf определяет соответствие URL-шаблонов(являются регулярными выражениями) и представлений. Чтобы из URL-а получить представление, Django используется так называемый ‘URLconf’. URLconf определяет соответствие URL-шаблонов(являются регулярными выражениями) и представлений.

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

3.1.1 Описание приложения менеджера учетных записей (apps.accounts)

Приложение accounts отвечает за регистрацию и аутентификацию пользователей. Приложение accounts оперирует объектами класса User.

Объекты User - основа системы аутентификации. Они представляют пользователей сайта и используятся для проверки прав доступа, регистрации пользователей, ассоциации данных с пользователями. Для представления пользователей используется только один класс, ‘superusers’ или ‘staff’ пользователи - это объект пользователей с определенными атрибутами, а не другие классы пользователей.

Основные атрибуты пользователя представлены в таблице 3.1:

№ п/п	Атрибут	Описание
	username	Имя пользователя. Видно всем.
	password	Пароль
	email	Адрес электронной почты
	first_name	Реальное имя. Видно только администраторам.
	last_name	Реальная фамалия. Видна только администраторам.

Описание модели User, используемой в приложнии accounts доступно в официальной документации фреймворка Django [ссылка на документацию].

Описание представлений приложения accounts приведено в таблице 3.1:

№ п/п	Наименование	Входные параметры	Описание
	sign_in	-	Регистрация пользователя.
	log_in	-	Вход в систему (аутентификация)
	log_out	-	Выход из системы.

Сопоставление представлений с URL-шаблонами приведено в таблице 3.2:

№ п/п	URL-шаблон	Сопоставленное представление (view)
	sign-in/	sign_in
	log-in/	log_in
	log-out/	log_out

3.1.2 Описание приложения для управления сервисом вопросов и ответов (apps.forum)

Приложение Forum является ключевым приложением сервиса, и отвечает за создание вопросов, создание ответов на вопросы, а так же осуществляет управление рейтингами вопросов. В приложении Forum используются модели Question, Answer, User, Post, Tag, Attachment, Vote.

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

№ п/п	Наименование	Тип	Описание
	timestamp	DateTimeField	Дата создания сообщения
	rating	IntegerField	Рейтинг сообщения
	text	TextField	Текст сообщения
	user	ForeignKey	Автор сообщеия

В таблице 3.2 представлено описание свойств модели Question. Модель Question содержит информацию о вопросах, которые задали пользователи на сервисе. По данной модели была автоматически сгенерирована таблица forum_question.

№ п/п	Наименование	Тип	Описание
	subject	TextField	Тема обсуждения
	views	IntegerField	Количество просмотров
	post	ForeignKey	Сообщение
	user	ForeignKey	Автор вопроса

В таблице 3.3 представлено описание свойств модели Answer. Модель Answer содержит информацию об ответах, которые дали пользователи на разилчные вопросы. По данной модели была автоматически сгенерирована таблица forum_answer.

№ п/п	Наименование	Тип	Описание
	question	ForeignKey	Вопрос
	post	ForeignKey	Сообщение
	user	ForeignKey	Автор ответа

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

№ п/п	Наименование	Тип	Описание
	file_path	FilePathField	Путь к файлу вложения
	post	ForeignKey	Сообщение
	user	ForeignKey	Автор вопроса

В таблице 3.5 представлено описание свойств модели Tag. Модель Tag содержит информацию о ключевых словах, которыми обозначены различные вопросы. По данной модели была автоматически сгенерирована таблица forum_tag.

№ п/п	Наименование	Тип	Описание
	name	TextField	Ключевое слово
	question	ForeignKey	Вопрос

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

№ п/п	Наименование	Тип	Описание
	post	ForeignKey	Сообщение
	user	ForeignKey	Пользвотель

Структуры данных в БД проекта были автоматически сгенерированы средствами фреймворка Django на основе ORM моделей для каждого из разработанных приложений. Генерация моделей осуществляется при помощи команды syncdb модуля manage.py

Подробное описание таблиц БД приведено в приложении Х "Описание структур данных в БД".

Описание представлений приложения accounts приведено в таблице 3.1:

№ п/п	Наименование	Входные параметры	Описание
	questions	tag_name	Отображение списка вопросов, отфильтрованных по ключевому слову tag_name
	question	question_id, action	Выполнение действия action над вопросом с идентификатором question_id и отображение результата. Список возможных действий: view, like, dislike.
	answer	answer_id, action	Выполнение действия action над ответом с идентификатором answer_id и отображение результата. Список возможных действий: view, like, dislike.
	ask_question	-	Отображение формы для создания нового вопроса
	search_by_tag	-	Отображение формы для поиска вопросов по ключеовому слову

Сопоставление представлений с URL-шаблонами приведено в таблице 3.2:

№ п/п	URL-паттерн	Сопоставленное представление (view)
	questions/(?P<tag_name>[0-9\w]*)	questions
	question/(?P<question_id>[0-9]+)/(?P<action>[a-z\-]*)	question
	answer/(?P<answer_id>[0-9]+)/(?P<action>[a-z\-]*)	answer
	search/	search_by_tag
	ask/	ask_question

3.2 Описание решений по организации тестирования системы

Тестирование системы организованы с использование встроенных средств фреймворка Django. Есть два основных способа создания тестов для Django: unit-тесты, унаследованные от unittest.TestCase и doc-тесты — тесты, написанные в стиле интерактивного интерпретатора Python. В разработанной системе применяется способ создания doc-тестов.

Юнит тесты Django используют модуль unittest2. Этот модуль определяет тесты в виде классов. Test runner при запуске юнит тестов проверяет models.py и tests.py в поиске наследников класса unittest.TestCase в каталоге приложения.

Запуск тестов для приложения осуществляется командой python manage.py test. Есть возможность запустить единственный метод из теста, к примеру: python manage.py test my_tests.MyTestCase.test_something

Тесты, которым необходима база данных, не используют основную базу данных, для них база создается отдельно и при окончании тестов автоматически удаляется. По умолчанию тестовые базы данных создаются с помощью добавления префикса test_ к значению параметра NAME в DATABASES. Чтобы использовать свое название нужно просто определить его в TEST_NAME в DATABASES. Для контроля кодировки информации в базе следует использовать TEST_CHARSET.

3.3 Разработка средств автоматизированного развертывания системы и основных решений по автоматизации рутинных задач

Система поставляется в виде архива, в котором расположены файлы проекта. В архиве также расположен файл «readme», который содержит описание развертывания системы.

Содержимое файла «readme»:

3. Скачать и установить Python 3.4: https://www.python.org/downloads/release/python-340/.

4. Скачать ez_setup.py: https://bootstrap.pypa.io/ez_setup.py.

5. Запустить ez_setup.py командой ez_setup.py.

6. Скачать Django web-framework: https://github.com/django/django/zipball/master.

7. Распаковать Django, перейти в распакованный каталог и установить Django командой setup.py install.

8. Запустить отладночный сервер командой manage.py runserver.

После чего система готова к эксплуатации пользователями.

Для автоматизации рутинных задач в системе предусмотрена панель администратора. Панель администратора позволяет вручную редактировать содержиоме БД и управлять учетными записями пользователей.

4 описание выбора окончательного решения

4.1 Оптимизация проекта

4.1.1 Анализ и оптимизация плана проекта

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

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

Чтобы определить неравномерность загрузки ресурсов, открываем «Лист ресурсов». Ресурсы, загрузка которых превышает их доступность, выделены красным цветом, и в поле «Индикаторы» стоит пометка о перегрузке.

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

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

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

Рисунок 4.1 - Выравнивание ресурсов

Автоматизированное выравнивание загрузки ресурсов производится с помощью диалогового окна «Выравнивание загрузки ресурсов».

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

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

Раздел «Диапазон выравнивания для проекта...» позволяет задать временной период выравнивания или производить выравнивание во всем проекте.

Раздел «Устранение превышений доступности» определяет, как программа будет устранять найденные перегрузки ресурсов.

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

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

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

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

Часть ресурсов все же пришлось выравнивать вручную. Ручное выравнивание осуществляется в два этапа: сначала надо найти те задачи, назначение на которые перегружает ресурсы. Затем надо определить методы выравнивания перегрузки. Методов довольно много: перенести задачу, прервать задачу, изменить длительность задачи, выделить на задачу другой ресурс, уменьшить объем работы, сохранить перегрузку, перенеся избыточные трудозатраты в сверхурочные и т.д. Произвели выравнивание ресурсов (рисунок 4.2).

Рисунок 4.2 - Выравнивание перегрузки ресурсов

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

Рисунок 4.3 - Диаграмма Ганта с выравниванием

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

4.1.2 Анализ и оптимизация плана работ

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

Метод PERT (Program, EvaluationandReviewTechnique) использует три сценария: пессимистичный (максимальные длительности задач), оптимистичный (минимальные длительности задач) и ожидаемый. В соответствии с удельным весом каждого варианта программа рассчитывает средневзвешенную длительность каждой задачи.

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

Дата добавления: 2015-11-14