Проектирование книжного портала

Федеральное агентство  по образованию

 

ТОМСКИЙ ГОСУДАРСТВЕННЫЙ  УНИВЕРСИТЕТ СИСТЕМ УПРАВЛЕНИЯ И  РАДИОЭЛЕКТРОНИКИ (ТУСУР)

 

 

 

Кафедра автоматизации  и обработки информации (АОИ)

 

 

 

 

 

Пояснительная записка  к курсовому проекту 

по дисциплине

«Проектирование АСОИУ»

 

 

 

«Проектирование книжного портала»

 

 

 

 

 

 

Выполнил:

Студент гр. 421-2

____________Гегия С.Т.

«_____»_________2005 г.

 

Принял:

Преподаватель каф. АОИ

_________Соловьев Д.А.

«_____»_________2005 г.

 

 

 

 

 

2005

 

 

 

Содержание

 

 

 

 

 

 

1 Введение

Целью курсового проекта является анализ организационных систем, рассматриваемых в качестве объекта автоматизации и объектно-ориентированный анализ и проектирование информационных систем, выполняемый согласно рекомендациям Rational Unified Process (RUP).

Rational Unified Process сосредотачивает внимание на первоначальной разработке и компоновке устойчивой архитектуры программы, которая облегчает параллельную разработку, минимизирует модификации, увеличивает возможность многократного использования и надежность эксплуатации. Эта архитектура используется для планирования использования и управления развитием программных компонентов.

Rational Unified Process поддерживает объектно-ориентированную технологию. Некоторые из моделей являются объектно-ориентированными моделями, которые базируются на понятиях объектов, классов и зависимостей между ними. Эти модели, подобно многим другим техническим искусственным объектам (артефактам), используют Унифицированный язык моделирования (UML) как общую систему обозначений.

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

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

Описание предметной области и  определение целей моделирования  представлено в документе видения организационной системы (Business Vision) и приведено в Приложении А.

 

3 Моделирование системы

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

Характеристики поведения разрабатываемой  системы фиксируются и документируются  средствами модели, которая отображает функции (прецеденты - use cases) продукта, представляет окружение системы (множество активных субъектов – actors) и определяет связи между прецедентами и актерами (диаграммы прецедентов – use case diagrams).

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

Создание диаграммы прецедентов  преследует следующие цели:

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

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

Как было сказано ранее, система  будет состоять из следующих частей:

• Система предоставления информации и взаимодействие с пользователями
• Система ведения опросов и их статистической обработки
• Система электронной рассылки
• Система электронной торговли "Книжный магазин"

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

 

Актер «Администратор»:

• изменить информацию размещённую на сайте;
• редактировать учетные записи зарегистрированных пользователей;
• исправить последствия нарушения работоспособности системы.

Актер «Аналитик опросов»:

• создать анкету для опроса пользователей;
• обработать полученную информацию;
• разослать электронные сообщения.

Актер «Посетитель»:

• просмотреть информацию размещённую на сайте;
• скачать электронную литературу;
• воспользоваться услугами системы электронной торговли “Книжный магазин”.

Актер «Зарегистрированный пользователь»:

• просмотреть информацию размещённую на сайте;
• скачать электронную литературу;
• воспользоваться услугами системы электронной торговли “Книжный магазин”;
• закачать в БД портала литературные новинки;
• получить электронную рассылку;
• ответить на вопросы опроса;
• настроить интерфейс.

Так как Актер “Зарегистрированный пользователь” имеет все сервисы, что и актер “Обычный пользователь”, то этих двух актеров нужно объединить отношением Generalization. Тогда диаграмма прецедентов будет иметь вид представленный на рис.1.

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

 

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

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

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

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

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

Диаграмма классов системы реализована  для системы электронной торговли "Книжный магазин":

 

Рис. 3.2.2. Диаграмма классов

3.3 Сбор требований

Сбор требований начинается с изучения области проблемы. Эта область — сфера интересов всех заинтересованных лиц, которые будут использовать систему. Для построения системы разработчики должны удовлетворить все потребности пользователей.

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

Далее необходимо выполнить классификацию  требований согласно рекомендациям RUP, сгруппировав их по категориям FURPS:

• Функциональные возможности (functionality);
• Практичность (usability);
• Надежность (reliability);
• Производительность (performance);
• Возможность поддержки (supportability).

3.4 Функциональные возможности

Перечислим функциональные требования, предъявляемые к проектируемой системе:

Таблица 3.4.1

№	Требования:	Полезность	Сложность
FEAT1:	Регистрации нового пользователя	Критическая	Низкая
FEAT2:	Редактирование данных уже существующего пользователя	Важная	Низкая
FEAT3:	Предоставление зарегистрированному пользователю электронной рассылки	Полезная	Средняя
FEAT5:	Просмотр электронных версий книг и брошюр	Критическая	Низкая
FEAT6:	Хранения  электронных книг и брошюр	Критическая	Низкая
FEAT7:	Добавление не использующихся электронных книг и брошюр (сроком больше года) в архив	Важная	Низкая
FEAT8:	Быстрое добавление в систему новых книг и брошюр	Критическая	Средняя
FEAT9:	Скачивание электронных книг и брошюр в формате PDF	Полезная	Низкая
FEAT10:	Прием заказа от пользователя на различные книги и брошюры	Критическая	Средняя
FEAT12:	Обеспечение рассылки прайс-листов	Критическая	Низкая
FEAT13:	Поиск ценного или раритетного вида книги	Критическая	Низкая
FEAT14:	Пополнения системы электронной торговли "Книжный магазин" за счет продукции компании BooksInfo	Критическая	Средняя
FEAT16:	Предоставление возможности настройки интерфейса зарегистрированному пользователю	Важная	Средняя
FEAT17:	Ведение статистики по продаже книжных изданий	Важная	Средняя

 

Перечислим требования прецедентов:

UC1:	Просматривать электронные версии книг
UC2:	Редактировать учетную запись зарегистрированного  пользователя
UC4:	Скачивать электронные версии книг
UC5:	Воспользоваться услугами системы  электронной торговли
UC6:	Получать электронную рассылку прайс-листов и рекламных акций
UC7:	Получать при входе в систему  последние новости
UC8:	Получать возможность пользователю настроить интерфейс по своему усмотрению

Рис. 3.4.1. Трассировочная матрица «Прецеденты – Функциональные требования».

3.5 Нефункциональные программные требования

Рассмотрим нефункциональные требования

• требования практичности (Usability) - требования этого типа описывают, как пользователи будут приспосабливаться к системе;
• требования надежности (Reliability) – показывает насколько приемлемым с точки зрения пользователя образом должна вести себя система;
• требования к производительности (Performance) – показывают параметры производительности системы;
• требования к возможности обслуживания (Supportability) – заключаются в способности легко модифицировать программное обеспечение с целью внесения изменений и исправлений.

3.5.1 Практичность

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

3.5.2 Надежность

• Система должна быть доступна для использования круглосуточно
• Пользователь должен получать корректный ответ на свой вопрос в 100% случаев.
• Зарегистрированный пользователь должен автоматически получать рассылку в 99% случаев. В случае неполучения нужной рассылки, она должна быть отправлена пользователю в течении 3 часов.
• В случае сбоя системы нормальное функционирование должно возобновиться в течении  30 минут
• Система должна нормально функционировать  при 10000 пользователей