Автор работы: Пользователь скрыл имя, 19 Апреля 2012 в 22:29, курсовая работа
Цель этой курсовой работы – проектирование ИС «Электронная Библиотека». Читатель просматривает каталог библиотеки и оформляет заявку на книгу. При этом вносятся изменения непосредственно в статус заявки книги, т.е. (обработка, выполнение и готова). При этом, каждая книга имеет свой артикул, свое название и описание. Соответственно, в одной заявке может быть сразу несколько книг, а значит, соответственно, может быть и несколько артикулов. Также указывается дата оформления и выдачи книг.
1. Описание предметной области
2. Средства программной реализации
3. Разработка реляционной базы данных в среде ER-Win
3.1 Диаграмма сущностей с описанием
3.2 Диаграмма отношений между сущностями
3.3 Диаграмма ключевых атрибутов
3.4 Диаграмма всех атрибутов и сущностей
3.5 Физическое представление
3.6 Набор SQL-запросов, создающих структуру БД
4. Разработка и проектирование БД в среде Rational Rose
4.1 Диаграмма прецедентов
4.2 Описание потока событий
4.3 Диаграмма последовательностей
4.4 Диаграмма состояний
4.5 Диаграмма действий
4.6 Диаграмма классов
4.7 Набор SQL-запросов для создания структуры БД
5. Интерфейс БД
5.1 Форма «в столбец» на основе таблицы «товар»
5.2 Ленточная форма на основе таблицы «клиенты»
5.3 Форма на основе таблицы «заказы»
Заключение
Список литературы
ERwinDatabase.Relations.Append ERwinRelation
ERwinDatabase.Close
ERwinWorkspace.Close
' Terminating Access Basic DAO Session.
Прецедент (вариант использования) – это последовательность действий, выполняемых системой в ответ на событие, инициируемое некоторым внешним воздействием (действующим лицом – актером). Прецедент описывает типичное взаимодействие между пользователем и системой.
Актер (действующее лицо) – это роль, которую пользователь играет по отношению к системе. Актерами могут быть:
- пользователи системы;
- другие системы, взаимодействующие с данной;
- время, если от него зависит запуск каких-либо событий в системе.
В языке UML для прецедентов и актеров поддерживается несколько типов связей. Это - связи коммуникации (communication), включения (include), расширения (extend) и обобщения (generalization).
Связь коммуникации (communication) –однонаправленная обычная связь. Направление стрелки указывает, кто инициирует коммуникацию.
Связь включения (include )– применяется тогда, когда имеется какой-либо фрагмент поведения системы, который повторяется более чем в одном прецеденте. Направление связи указывается от базового прецедента к используемому.
Связь расширения (extend ) – применяется при описании
- изменений в нормальном поведении системы;
- дополнительных режимах;
- режимов, которые запускаются только при определенных условиях, например, сигнал тревоги;
- альтернативных потоков, которые запускаются по выбору актера.
Для того, чтобы фактически разработать систему, одной диаграммы прецедентов недостаточно, поскольку требуется описать более конкретные детали. Они описываются в документе, который называется «поток событий». Этот документ подробно описывает, что будут делать пользователи системы и что – сама система. Обычно поток событий включает:
- краткое описание;
- предусловия (pre-conditions);
- основной поток событий;
- альтернативный поток событий;
- постусловия (post-condition).
Поток событий для прецедента "войти в систему"
1. Прецедент начинается, когда клиент заходит на сайт.
2. Клиенту предлагается ввести пароль
3. Клиент вводит пароль
4. Система подтверждает введенный пароль.
Если пароль неверен, выполняется альтернативный поток событий А1.
5. Клиент попадает на свою личную страницу.
6. Прецедент завершается
Альтернативный поток событий А1. Ввод неправильного пароля.
1. Система сообщает клиенту, что код введен неправильно.
2. Прецедент завершается.
Поток событий для прецедента "сделать заказ"
Предусловия
Должен быть выполнен прецедент "войти в систему"
Основной поток событий
1.Прецедент начинается, когда клиент нажимает кнопку "оформить заказ"
2.Клиент выбирает товар в каталоге
3.Клиент проверяет количество товара на складе.
Если товара нет, выполняется альтернативный поток событий А1.
4.Товар переносится в корзинку
5.Клиент подтверждает заказ.
Если нет, выполняется альтернативный поток событий А2.
6.Заказ отправляется менеджеру
7.Статус заказа меняется на "заказ принят".
Если во время отправки заказа возникли ошибки, выполняется поток ошибок Е1.
8.Прецедент завершается.
Альтернативный поток событий А1
1.Система выводит сообщение о том, что данный товар на складе отсутствует.
2.Клиент попадает в каталог товаров.
Альтернативный поток событий А2
1.Клиент не подтверждает отправку заказа.
2.Прецедент завершается.
Поток ошибок Е1
1.Система сообщает клиенту, что при отправке заказа произошла ошибка. И предлагает попробовать
отправить заказ еще раз позднее.
2.Система заносит сведения об ошибке в журнал ошибок.
3.Прецедент завершается.
Диаграммы последовательности событий отражают поток событий, происходящий в рамках прецедента.
Диаграммы состояний (statechart diagrams) определяют все возможные состояния, в которых может находиться конкретный объект, а также процесс смены состояний объекта в результате наступления некоторых событий.
Диаграммы действий (activity diagrams) – частный случай диаграмм состояний. Диаграммы действий особенно полезны в описании поведения, включающего большое количество параллельных процессов. Они являются мощным средством моделирования потоков работ и, по существу, параллельного программирования.
Диаграмма классов определяет типы классов системы и различного рода статические связи, которые существуют между ними. На диаграмме классов изображаются также атрибуты классов, операции классов и ограничения, которые накладываются на связи между классами. Диаграммы классов используются непосредственно для получения программного кода системы.
CREATE TABLE T_заказы (
код заказа INTEGER NOT NULL,
дата заказа DATE NOT NULL,
статус VARCHAR ( 255 ) NOT NULL,
стоимость DOUBLE PRECISION NOT NULL,
дата выдачи DATE NOT NULL,
T_магазин_ID INTEGER NOT NULL,
CONSTRAINT PK_T_заказы6 PRIMARY KEY (код заказа)
);
CREATE TABLE T_3 (
артикул INTEGER NOT NULL,
код заказа INTEGER NOT NULL,
CONSTRAINT PK_T_310 PRIMARY KEY (артикул, код заказа)
);
CREATE TABLE T_2 (
код заказа INTEGER NOT NULL,
код клиента INTEGER NOT NULL,
CONSTRAINT PK_T_29 PRIMARY KEY (код заказа, код клиента)
);
CREATE TABLE T_база клиентов (
код клиента INTEGER NOT NULL,
имя VARCHAR ( 255 ) NOT NULL,
e-mail VARCHAR ( 255 ) NOT NULL,
телефон INTEGER NOT NULL,
CONSTRAINT PK_T_база клиентов5 PRIMARY KEY (код клиента)
);
CREATE TABLE T_магазин (
код магазина INTEGER NOT NULL,
адрес VARCHAR ( 255 ) NOT NULL,
телефон INTEGER NOT NULL,
T_магазин_ID INTEGER NOT NULL,
CONSTRAINT PK_T_магазин8 PRIMARY KEY (T_магазин_ID)
);
CREATE TABLE T_список товаров (
артикул INTEGER NOT NULL,
название VARCHAR ( 255 ) NOT NULL,
автор VARCHAR ( 255 ) NOT NULL,
описание VARCHAR ( 255 ) NOT NULL,
цена DOUBLE PRECISION NOT NULL,
CONSTRAINT PK_T_список товаров7 PRIMARY KEY (артикул)
);
CREATE INDEX TC_T_заказы9 ON T_заказы (T_магазин_ID);
CREATE INDEX TC_T_36 ON T_3 (артикул);
CREATE INDEX TC_T_37 ON T_3 (код заказа);
CREATE INDEX TC_T_24 ON T_2 (код заказа);
CREATE INDEX TC_T_25 ON T_2 (код клиента);
ALTER TABLE T_заказы ADD CONSTRAINT FK_T_заказы8 FOREIGN KEY (T_магазин_ID) REFERENCES T_магазин (T_магазин_ID) ON DELETE NO ACTION ON UPDATE NO ACTION;
ALTER TABLE T_3 ADD CONSTRAINT FK_T_36 FOREIGN KEY (артикул) REFERENCES T_список товаров (артикул) ON DELETE NO ACTION ON UPDATE NO ACTION;
ALTER TABLE T_3 ADD CONSTRAINT FK_T_37 FOREIGN KEY (код заказа) REFERENCES T_заказы (код заказа) ON DELETE NO ACTION ON UPDATE NO ACTION;
ALTER TABLE T_2 ADD CONSTRAINT FK_T_24 FOREIGN KEY (код заказа) REFERENCES T_заказы (код заказа) ON DELETE NO ACTION ON UPDATE NO ACTION;
ALTER TABLE T_2 ADD CONSTRAINT FK_T_25 FOREIGN KEY (код клиента) REFERENCES T_база клиентов (код клиента) ON DELETE NO ACTION ON UPDATE NO ACTION;
В курсовой работе с помощью двух программных сред (ER-Win и Rational Rose) спроектирована модель информационной системы книжного магазина. Модель импортирована в базу данных Access для дальнейшей разработки и усовершенствования.
1. Н.В. Барклаевская «Использование ER-Win для проектирования реляционных баз данных». Методические указания к выполнению лабораторных работ, ГУАП, 2006г.
2. www.interface.ru/rational/rose
3. www.citforum/database/kbd96/
4. С.А. Трофимов «CASE-технологии: практическая работа в Rational Rose», Изд. 2-е – М.: Бином-Пресс, 2002г.
21