close

Вход

Забыли?

вход по аккаунту

?

курсач03

код для вставкиСкачать
Министерство образования и науки Российской Федерации
Федеральное государственное бюджетное образовательное учреждение
высшего профессионального образования
"ТОМСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ СИСТЕМ
УПРАВЛЕНИЯ И РАДИОЭЛЕКТРОНИКИ" (ТУСУР)
Кафедра автоматизации обработки информации (АОИ)
УТВЕРЖДАЮ
Заведующий кафедрой АОИ
д-р техн. наук, проф.
___________Ю.П. Ехлаков
"___"_____________2012 г.
ИНТЕРНЕТ-МАГАЗИН ЖЕНСКОЙ ОДЕЖДЫ "КРАСОТКА"
Курсовая работа
по дисциплине "Проектирование АСОИУ"
Студентка гр. 428-1
_____________ М. Ю. Перминова
______________
Руководитель
Ст. преп. каф. АОИ, к.т.н.
_________ _____________ Д. А. Соловьев
_____________
2012
Министерство образования и науки Российской Федерации
Федеральное государственное бюджетное образовательное учреждение
высшего профессионального образования
"ТОМСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ СИСТЕМ
УПРАВЛЕНИЯ И РАДИОЭЛЕКТРОНИКИ" (ТУСУР)
Кафедра автоматизации обработки информации (АОИ)
УТВЕРЖДАЮ
Заведующий кафедрой АОИ
д-р техн. наук, проф.
___________Ю.П. Ехлаков
"___"_____________2012 г.
ЗАДАНИЕ
на курсовую работу
студентке Перминовой М. Ю. группы 428-1 факультета систем управления
1.Тема работы:
Проектирование интернет-магазина женской одежды "Красотка".
2. Срок сдачи работы на кафедру: "30" ноября 2012 г.
3. Содержание:
В работе созданы артефакты, определенные Rational Unified Process: модель системы и ее элементов в нотации Unified Modeling Language, пирамида требований к системе в виде проекта RequisitePro, документа Видения в формате Microsoft Word и других документов.
4. Дата выдачи задания: "3" сентября 2012 г.
Руководитель: старший преподаватель кафедры АОИ Соловьев Д.А. "___"___________________2012 г. _____________________________
(подпись руководителя)
Задание принял к исполнению:
"___"___________________2012 г. ______________________________
(подпись студента)
Содержание
Введение4
1 Моделирование производства5
1.1 Диаграмма последовательности5
1.2 Диаграмма классов7
1.3 Диаграмма прецедентов8
1.4 Диаграмма состояний12
1.5 Модель предметной области13
2 Требования к системе14
2.1 Бизнес-правила14
2.2 Функциональные требования14
2.3 Запросы заинтересованных сторон14
2.4 Матрицы трассировки15
Заключение17
Список использованных источников18
Приложение А. Диаграмма прецедентов19
Приложение Б. Модель предметной области20
Приложение В. Матрица атрибутов бизнес-правил21
Приложение Г. Матрица атрибутов функциональных возможностей22
Приложение Д. Документ Видения24
Приложение Е. Матрица атрибутов запросов заинтересованных сторон29
Введение
Целью курсовой работы является анализ организационных систем, рассматриваемых в качестве объекта автоматизации и объектно-ориентированный анализ и проекти-рование информационных систем, выполняемый согласно рекомендациям Rational Unified Process (RUP). Курсовая работа по дисциплине "Проектирование АСОИУ" направлена на применение теоретических знаний и навыков практической работы с инструмен-тальными средами, полученных в процессе изучения курса. Работа призвана способствовать формированию инженерных навыков.
Выполнение курсового проекта сопровождается созданием артефактов, определенных Rational Unified Process: моделей системы и их элементов в нотации Unified Modeling Language, пирамиды требований к системе в виде проекта RequisitePro, документа Видения в формате Microsoft Word и других документов [1].
1 Моделирование производства
В качестве проектируемой системы выбран интернет-магазин женской одежды "Красотка".
Интернет-магазин (далее ИМ) - это система (веб-сайт и сопутствующие службы) по приему заявок на покупку определенных товаров. Основная часть ИМ - веб-сайт, который служит витриной для представления товаров. Пользователь просматривает каталог, подбирая товары. Сбор товаров для покупки происходит с помощью корзины - это индивидуальный раздел сайта со списком товаров и предварительным расчетом общей стоимости заказа. После сбора всех необходимых товаров, пользователь переходит к оформ-лению заказа. Для оформления заказа от пользователя необходимо узнать адрес доставки и контактную информацию для подтверждения заказа. На сайте ИМ осуществляется выбор оплаты покупки - безналичный (банковской картой) или наличный расчет. После отправки оформления заказа, данные о составе заказа и покупателе поступают менеджеру ИМ для проверки и подтверждения. Если заказ подтвержден и товар в наличии, то заказ переходит в службу доставки, которая его собственно и доставляет заказчику. Оплата заказа происходит при получении. После успешной доставки заказ считается выполненным.
1.1 Диаграмма последовательности
Для начала рассмотрим работу магазина "Красотка" до автоматизации. Покупатель приходит в магазин, знакомится с ассортиментом магазина, рассматривая витрину магазина. Затем выбирает нужную модель одежды, выбирает нужный размер (при необходимости обращается к продавцу-консультанту) и идет на примерку. Если одежда подошла по размеру и удовлетворяет всем требованиям покупателя, то покупатель проходит на кассу. Клиент оплачивает товар банковской картой или наличными и покидает магазин с покупками.
Мы автоматизировали работу магазина. На рисунке 1.1 изображена диаграмма последовательности, иллюстрирующая схему протекания бизнес-процесса после его автоматизации. Покупатель заходит на сайт ИМ, знакомится с ассортиментом магазина, рассматривая каталог товаров. Затем выбирает нужную модель одежды, выбирает нужный размер (при необходимости обращается к продавцу-консультанту) и добавляет товар в корзину. Далее клиент оформляет заказ и ждет его подтверждения. На рисунке 1.2 показана диаграмма последовательности, отображающая работу с сайтом ИМ.
Рисунок 1.1 - Диаграмма последовательности работы ИМ в Rational Rose
Рисунок 1.2 - Диаграмма последовательности работы сайта ИМ в Rational Rose
1.2 Диаграмма классов
Диаграмма классов (class diagram) служит для представления статической структуры модели системы в терминологии классов объектно-ориентированного программирования. Диаграмма классов отражает различные взаимосвязи между отдельными сущностями предметной области, а также описывает их внутреннюю структуру и типы отношений. На диаграмме классов не указывается информация о временных аспектах функционирования системы.
Диаграмма классов состоит из множества элементов, которые в совокупности отражают декларативные знания о предметной области. Она содержит основные сущности предметной области, их атрибуты и отношения [2].
Диаграмма классов изображена на рисунке 1.3.
Рисунок 1.3 - Диаграмма классов в Rational Rose
1.3 Диаграмма прецедентов
Диаграмма прецедентов (use case diagram) относится к концептуальному представлению системы, описывая назначение системы. Она разрабатывается для достижения следующих целей:
* определить границы и контекст моделируемой системы;
* сформулировать требования к поведению системы;
* создать и зафиксировать исходное концептуальное представление системы с целью его последующей детализации в форме логических и физических моделей;
* подготовить набор артефактов, используемых разработчиками системы для общения с ее заказчиками и будущими пользователями.
Основная идея состоит в представлении системы посредством совокупности прецедентов (use cases) - сервисов, адресованных конкретным потребителям. Любую сущность, взаимодействующую с системой извне, и являющуюся потребителем адресованного ей сервиса называют актером (actor). В роли актера может выступать человек, техническое устройство, программа, или другая система, служащая источником воздействия на моделируемую систему. С внутренней точки зрения прецедент представляет собой совокупность действий, выполняемых системой в ответ на запрос актера и приводящих к значимому для актера результату. При этом соблюдается принцип "черного ящика" - никакой информации о том, каким именно образом реализуется взаимодействие актера и системы, на диаграмме не приводится.
Говоря формально, диаграмма прецедентов представляет собой граф специального вида, основными элементами которого являются прецеденты, актеры и отношения между ними. С целью упрощения восприятия диаграммы и структурирования информации могут применяться пакеты, содержащие как диаграммы, так их элементы [2].
Диаграмма прецедентов для ИМ представлена в Приложении А.
Краткое описание прецедентов:
* Авторизация. Клиент заходит на сайт ИМ. Вводит свой логин и пароль в окне авторизации. Клиент авторизирован.
* Регистрация. Клиент заходит на сайт ИМ. Вводит свои контактные данные в окне регистрации. Клиент зарегистрирован.
* Поиск товара. Клиент заходит на сайт ИМ. Вводит в окно поиска требуемый товар или его артикул. Клиент находит искомый товар.
* Управление списком товаров в корзине. Клиент заходит на сайт ИМ. Выбирает нужный товар, добавляет его в корзину. Если клиент захотел изменить параметры товара, то он может их изменить. Если пользователь не хочет покупать данный товар, то он удаляет его из корзины.
* Подписаться на новости. Клиент заходит на сайт ИМ. Вводит свой email в окно подписки на новости, подтверждает свой электронный адрес нажатием на кнопку "Подписаться". Клиент подписался на рассылку новостей.
* Получить помощь. Клиент заходит на сайт ИМ. Если при выполнении любой операции у него возникли вопросы, то клиент может написать сообщение онлайн-консультанту или позвонить в справочную службу ИМ. Клиент получил помощь.
* Просмотр спец. предложений. Клиент заходит на сайт ИМ. На главной странице он выбирает нужный раздел (акции, скидки) и просматривает информацию.
* Просмотр каталога одежды. Клиент заходит на сайт ИМ. При необходимости выбирает нужный раздел каталога одежды и просматривает весь каталог или выбранный раздел каталога одежды.
* Оформить заказ. Клиент должен быть авторизирован. Клиент заходит на сайт ИМ. Выбирает нужный товар. Добавляет его в корзину. Клиент оформляет заказ, нажав кнопку "Оформить заказ".
* Оставить отзыв о товаре. Клиент должен быть авторизирован. Клиент заходит на сайт ИМ. Выбирает ранее заказанный товар. Клиент оставляет отзыв о данном товаре.
* Редактирование профиля. Клиент должен быть авторизирован. Клиент заходит на сайт ИМ. Заходит в личный кабинет. Редактирует личные данные.
* Проверка заказа. Менеджер получил уведомление о новом заказе клиента. Менеджер проверяет наличие товара в заказе на наличие.
* Подтверждение заказа. Менеджер получил уведомление о новом заказе клиента. Менеджер проверяет наличие товара в заказе на наличие. Если товар есть в наличии, то менеджер уведомляет пользователя о подтверждении его заказа. Если нет, то менеджер уведомляет пользователя о причине, по которой его заказ не принят.
* Управление списком пользователей. Новый клиент зарегистрировался на сайте ИМ. Модератор добавил нового пользователя в базу данных. Модератор обнаружил нарушение правил ИМ одним из клиентов. Модератор выслал предупреждение пользователю. Если клиент продолжил нарушения, модератор удалил клиента.
* Управление списком товаров в каталоге. Менеджер сообщил о поступлении нового товара. Модератор добавил в каталог новый товар. Менеджер сообщил о том, что товар больше не будет продаваться. Модератор удалил товар. Менеджер сообщил об изменении параметров товара. Модератор изменил необходимую информацию.
Прецедент "Оформить заказ" (расширенное описание)
Краткое описание
Клиент заходит на сайт ИМ. Клиент выбирает товар. Клиент добавляет товар в корзину. Клиент заходит в корзину и оформляет заказ.
Основной актер
Авторизированный пользователь (клиент).
Предусловия
Клиент авторизован на сайте.
Постусловия
Клиент предоставил сведения о месте и времени доставки, о способе оплаты. Клиент оформил заказ. Менеджер проверил наличие товара. Менеджер выслал клиенту сообщение, что его заказ принят. Основной успешный сценарий (или основной процесс)
1. Клиент заходит на сайт ИМ
2. Клиент выбирает товар
3. Клиент добавляет товар в корзину.
2. Клиент заходит в корзину с товарами.
3. Клиент нажимает кнопку "Оформить заказ".
4. Клиент авторизуется.
5. Клиент вводит адрес доставки.
6. Клиент вводит время доставки.
7. Клиент выбирает способ оплаты.
8. Клиент подтверждает введенные ранее данные.
9. Клиент видит сообщение "Ваш заказ проверяется. Дождитесь оповещения от нашего представителя.".
10. Клиенту приходит подтверждение заказа.
11. Статус заказа меняется на "Подтвержден".
12. Клиенту приходит оповещение "Ожидайте доставки".
Расширения (или альтернативные потоки)
3а. Клиент не выбрал товар.
1. Система не дает возможности оформить заказ, пока отсутствует товар в корзине.
4а. Клиент уже авторизован.
4а1. Клиент сразу переходит к шагу 5.
4а2. Клиент вводит логин и пароль.
4а2а. Клиент ввел неверный логин.
1. Система уведомляет о неверно введенном логине.
2. Пользователь повторно вводит логин.
4а2б. Клиент ввел неверный пароль.
1. Система уведомляет о неверно введенном пароле.
2. Пользователь повторно вводит пароль.
4а2в. Клиент забыл логин/пароль.
1. Клиент нажимает кнопку "Забыл логин/пароль".
2. Клиент вводит свой email.
3. Клиенту на email отправляются данные для авторизации.
4б. Клиент не зарегистрирован на сайте.
1. Клиент ставит метку "Новый клиент".
2. Система предоставляет форму для регистрации.
6а. В заданное время Курьер не сможет доставить заказ.
1. Система предлагает ввести клиенту другое время доставки.
7а. Клиент выбрал оплату наличными.
1. Клиент вводит информацию о том, какими купюрами будет происходить оплата.
7б. Клиент выбрал оплату банковской картой.
1. Система уведомляет о скидке на заказ.
8а. Не все введенные клиентом данные верны.
1. Клиент возвращается на нужную форму введения данных и исправляет некорректно введенную информацию.
10а. Клиенту пришло оповещение "Заказ не подтвержден".
10а1а. Товара нет в наличии.
1. Менеджер приносит извинения Клиенту и предлагает заказать другой товар.
10а1б. Технические неполадки.
1. Менеджер предлагает повторить оформление заказа через несколько минут.
12а. Клиенту не приходит оповещение "Ожидайте доставки".
12а1. Технические неполадки.
1. Оповещение приходит позже или Менеджер позвонит Клиенту.
1.4 Диаграмма состояний
Главное предназначение диаграммы состояний - описать возможные последовательности состояний и переходов, которые в совокупности характеризуют поведение элемента модели в течение его жизненного цикла. Диаграмма состояний представляет динамическое поведение сущностей, на основе спецификации их реакции на восприятие некоторых конкретных событий. Системы, которые реагируют на внешние действия от других систем или от пользователей, иногда называют реактивными. Если такие действия инициируются в произвольные случайные моменты времени, то говорят об асинхронном поведении системы.
Диаграмма состояний по существу является графом специального вида, который представляет некоторый автомат. Вершинами этого графа являются состояния. Дуги графа служат для обозначения переходов из состояния в состояние [2].
Диаграмма состояний для заказа ИМ "Красотка" изображена на рисунке 1.4.
Рисунок 1.4 - Диаграмма состояний в Rational Rose
1.5 Модель предметной области
Модель предметной области широко используется в качестве основы для разработки программных объектов и обеспечивает важную входную информацию для создания последующих артефактов. Она отображает основные (с точки зрения моделирующего) классы понятий (концептуальные классы) предметной области и является наиболее важным артефактом, создаваемым на этапе объектно-ориентированного анализа. Модель предметной области представляет классы понятий реального мира, а не программные компоненты. Это не набор диаграмм, описывающих программные классы или программные объекты с их обязанностями [3].
В приложении Б представлена диаграмма предметной области.
2 Требования к системе
На этом этапе выполнения курсовой работы ставится задача сбора и определения требования к информационной системе, их классификации согласно рекомендациям Rational Unified Process, создание графика (плана) реализации системы [3].
2.1 Бизнес-правила
Бизнес-правило - это положение, определяющее или ограничивающее какие-либо стороны бизнеса. Его назначение - защитить структуру бизнеса, контролировать или влиять на его операции.
Существует множество различных схем классификации бизнес-правил на виды. Одна из них, предложенная Карлом Вигерсом включает в себя факты и ограничения.
Факты (facts) - это верные утверждения о бизнесе. Они описывают связи и отношения между важными бизнес-терминами. Факты также называют инвариантами - неизменными истинами о сущности данных и их атрибутах. Обычно факты напрямую не преобразуются в функциональные требования к системе. Сведения о сущности данных, важных для системы, применяют в моделях данных, создаваемых аналитиком или архитектором базы данных.
Ограничения (Constraints) определяют, какие операции могут выполняться в рамках системы. Как правило, при формулировании ограничений используются слова и фразы вида: должен/не должен, может/не может, только [3].
В приложении В представлена матрица атрибутов бизнес-правил.
2.2 Функциональные требования
Функция - это предоставляемое системой обслуживание для удовлетворения одной или нескольких потребностей заинтересованных сторон.
Функции представляют собой описания, которые команда будет использовать в качестве ярлыков, чтобы пояснить заказчику, как создаваемая система решает его задачу. Они представляют собой очень полезные конструкции для управления масштабом продукта на ранних этапах взаимных согласований и поиска компромиссов. Формулировка функций не требует значительных инвестиций; их легко описать и перечислить [3].
В приложении Г представлена матрица атрибутов функциональных требований. Также в приложении Д представлен документ Видения, который содержит данный тип требований.
2.3 Запросы заинтересованных сторон
Заинтересованные стороны (stakeholders) - это все, на кого реализация новой системы или приложения может оказать материальное воздействие. Запрос заинтересованной стороны (stakeholders request) - отражение некой личной, рабочей или бизнес-проблемы (или возможности), решение которой оправдывает замысел, покупку или использование новой системы [3].
В приложении Е представлена матрица атрибутов запросов заинтересованных сторон.
2.4 Матрицы трассировки
Трассировочная матрица представляет собой довольно удобный инструмент для отслеживания изменений в функциональных требованиях, которые появляются при внесении изменений в модель прецедентов. Трассировочная матрица (Traceability Matrix) показывает отношения между требованиями одинаковых или разных типов. Данная матрица используется для создания, модификации и удаления отношений трассируемости и для отображения отношений трассируемости с подозрительными состояниями. Кроме того, она применима для фильтрации и сортировки строк и столбцов отдельных требований [3].
Трассировка бизнес-правил на функциональные требования
На рисунке 2.1 представлена трассировочная матрица бизнес-правил на функциональные требования.
Рисунок 2.1 - Матрица трассировки бизнес-правил на функциональные требования
в Rational RequisitePro
Трассировка запросов заинтересованных сторон на функциональные требования
На рисунке 2.2 представлена трассировочная матрица запросов заинтересованных сторон на функциональные требования.
Рисунок 2.2 - Матрица трассировки запросов заинтересованных сторон на функциональные требования в Rational RequisitePro
Заключение
В ходе курсовой работы были созданы артефакты, определенных Rational Unified Process: моделей системы и их элементов в нотации Unified Modeling Language, пирамиды требований к системе в виде проекта RequisitePro, документа Видения в формате Microsoft Word и других документов. Для выполнения работы были применены теоретические знания и навыки практической работы с инструментальными средами, полученные в процес-се изучения курса дисциплины "Проектирование АСОИУ".
Список использованных источников
1 Соловьев Д.А. Методические указания по выполнению курсовой работы по дисциплине "Проектирование АСОИУ". - Томск : Томский государственный университет систем управления и радиоэлектроники, 2007 - 10 с.
2 Соловьев Д. А. Проектирование автоматизированных систем обработки информации и управления : Учебное пособие. В 2-х частях. - Томск : Томский межвузовский центр дистанционного образования, 2007. - Ч. 1: Унифицированный язык моделирования. - 170 с.
3 Соловьев Д.А. Курс лекций по дисциплине "Проектирование АСОИУ".
Приложение А
(рекомендуемое)
Диаграмма прецедентов
Рисунок А.1 - Диаграмма прецедентов в Rational Rose
Приложение Б
(рекомендуемое)
Модель предметной области
Рисунок Б.1 - Модель предметной области в Rational Rose
Приложение В
(рекомендуемое)
Матрица атрибутов бизнес-правил
Рисунок В.1 - Матрица атрибутов бизнес правил в Rational RequisitePro
Приложение Г
(рекомендуемое)
Матрица атрибутов функциональных возможностей
Рисунок Г.1 - Матрица атрибутов функциональных требований в Rational RequisitePro (часть 1)
Рисунок Г.2 - Матрица атрибутов функциональных требований в Rational RequisitePro (часть 2)
2
20
Документ
Категория
Рефераты
Просмотров
295
Размер файла
562 Кб
Теги
курсач03
1/--страниц
Пожаловаться на содержимое документа