3. Разработка системы с помощью Rational Rose:
Подразумеваем, что продажа продукции и заказы происходит при помощи сайта компании.
Диаграмма прецедентов
Поток событий для прецедента
Вариант использования «Изменить параметры учетной записи» позволяет клиенту который зарегистривовался на сайте изменять параметры учетной записи а так же изменять номера кредитных карт которые привязаны к кошельку
Предусловия
Перед выполнением данного прецедента должно выполниться два прецедента стоящиее перед ним а именно индтетификация и аутентификация после чего можно будет использовать данный прецендент
Основной поток
1. Прецедент начинается, когда клиент заходит на сайт с продукцией
2. Сайти предлогает войти на него под своей учетной записи
3. Клиент проходит стадии индетификации и аутентификации
4. Сайт подтверждает введенный логин и пароль. Если код не подтвержден, выполняется альтернативный поток событий А1.
5. Сайт выводит список доступных действий:
• Изменить параметры учетной записи;
• Покупка;
• Пополнение кошелька.
• Заказать
6. Клиент выбирает пункт «Изменить параметры учетной записи».
7. Сайт выводит данные о клиенте в режиме измения данных.
8. Клиент вводит нажные изменения.
9. Сайт определяет, веденые данные не повтрояют ли данные которые уже задействованны на сайте. Если данные такие уже задействованны, выполняется альтернативный поток А2.
10. Сайт сохраняет измененные данные.
11. Клиента переводят на начальный этап после прохождение индетификации и аутентификации .
12. Прецедент завершается.
Альтернативный поток А1. Ввод неправильного логина и пароля
1. Сайт информирует клиента, что логин или пароь введен неправильно.
2. Сайт предлогает вести еще раз.
3. Прецедент завершается.
Альтернативный поток А2. Повторяемые данные.
1. Сайт информирует клиента, что данный логин зарегистрирован на сайте.
2. Сайт предлогает вести новый логин.
3. Прецедент завершается.
Диаграмма последовательностей
Используем в прецеденте Покупка
Описывают поведение взаимодействующих групп объектов. Каждая диаграмма описывает поведение объектов в рамках только одного прецедента. На диаграмме изображаются объекты и те сообщения, которыми они обмениваются между собой. Определяют три типа сообщений:
информационные (informative) – сообщения, снабжающие объект-получатель информацией для обновления его состояния;
сообщения – запросы (interrogative) – сообщения, запрашивающие выдачу информации об объекте-получателе;
императивные (imperative) – сообщения, запрашивающие у объекта-получателя выполнение действия.
Кооперативная диаграмма
В большей степени заостряют внимание на связях между объектами, чем диаграммы последовательности событий. В принципе, на кооперативной диаграмме представлена такая же информация, как и на диаграмме последовательности, но по-другому. Из нее легче понять связи между объектами, но труднее – последовательность событий. Временная последовательность указывается путем нумерации сообщений.
Диаграмма состояний
Используем в прецеденте Пополнение Кошелька
Определяют все возможные состояния, в которых может находиться конкретный объект, а также процесс смены состояний объекта в результате наступления некоторых событий.
Диаграмма классов
Сделана на прецеденте Покупка
Диаграмма классов определяет типы классов системы и различного рода статические связи, которые существуют между ними. На диаграмме классов изображаются также атрибуты классов, операции классов и ограничения, которые накладываются на связи между классами. Диаграммы классов используются непосредственно для получения программного кода системы.
Диаграмма пакетов
Пакеты используют, чтобы сгруппировать классы, обладающие некоторой общностью. Существует несколько подходов к группировке
По стереотипу. В этом случае получается один пакет с классами-сущностями, другой – с граничными классами, третий – с управляющими классами и так далее. Этот подход может быть полезен с точки зрения размещения готовой системы, поскольку все находящиеся на клиентских машинах компоненты с граничными классами уже оказываются в одном пакете.
По функциональности. В этом случае в один пакет войдут классы, обеспечивающие одну какую-либо функцию, например безопасность системы или обработку ошибок или подготовку отчетов и пр. Преимущество этого подхода заключается в возможности повторного использования.
Так как классов в нашей работе не много мы можем обойтись без группировки
Диаграмма компонентов
Показывают, как выглядит модель на физическом уровне. На них изображены компоненты программного обеспечения и связи между ними. На диаграмме компонентов выделяют два типа компонентов: исполняемые компоненты и библиотеки кода.
Компоненты системы для Клиентской части
Компоненты системы для Серверной части
Схема базы данных
SLQ-запросы для создания таблиц
CREATE TABLE T_Чтение_операции_с_кошелька (
Номер_Карты INT NOT NULL,
CONSTRAINT PK_T_Чтение_операции_с_кошелька1 PRIMARY KEY NONCLUSTERED (Номер_Карты)
)
GO
CREATE TABLE T_Счет (
Номер_Счета INT NOT NULL,
PIN INT NOT NULL,
Баланс BIGINT NOT NULL,
Номер_Карты INT NOT NULL,
T_Чтение_операции_с_кошелька_Номер_Карты INT,
CONSTRAINT PK_T_Счет0 PRIMARY KEY NONCLUSTERED (Номер_Карты)
)
GO
CREATE INDEX TC_T_Счет1 ON T_Счет (T_Чтение_операции_с_кошелька_Номер_Карты )
GO
ALTER TABLE T_Счет ADD CONSTRAINT FK_T_Счет0 FOREIGN KEY (T_Чтение_операции_с_кошелька_Номер_Карты) REFERENCES T_Чтение_операции_с_кошелька (Номер_Карты)
GO
4)Вывод: В данной курсовой работе я ознакомился с такими Сase – средствами как BPwin,Erwin и Ration Rose были спроектированы информационная система компании производства комиксов а так же базы данных к ним, был получен код Sql запросов что помогает, переводит данные модели в sql server а так же есть возможность переводит результаты в access все зависит от поставленной задачи.