Проектирование автоматизированных систем обработки информации и управления

 

Содержание

1. Постановка задачи

. Разработка системы с помощью BPwin и ERwin средств

.1 BPwin

.2 Erwin

. Разработка при помощи Rational Rose

Вывод

1. Постановка задачи

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

2. Разработка системы с помощью BPwin и ERwin средств

.1 Начинаем разрабатывать модель в BPwin

Первая диаграмма, которую следует построить IDEFO.

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

Любые схемы, реализуемые в BPwin должны придерживаться одного стандарта, а именно:

Слева стрелки - это вход, который требует выполнение некоторой процесса

Стрелка сверху - выполняет функцию управленческого процесса

Стрелка снизу - Исполнительный механизм нечто, что используется для выполнения процесса

Стрелка справа - выход нечто, что является результатом выполнение процесса

Это самая главная диаграмма нашей системы дальнейшая работа сводиться к декомпозиции данной модели.

Производим декомпозицию "Деятельность Компании"

Делаем декомпозицию работы Перевод

Так же BPwin позволяет нам сделать Диаграмму Узлов, что помогает наглядно посмотреть иерархию работ

Следующая диаграмма в нашем списке это IDEF3

IDEF3 - методология моделирования и стандарт документирования процессов, происходящих в системе. Метод документирования технологических процессов предоставляет собой механизм документирования и сбора информации о процессах. IDEF3 показывает причинно-следственные связи между ситуациями и событиями в понятной эксперту форме, используя структурный метод выражения знаний о том, как функционирует система, процесс или предприятий

Делаем декомпозицию работы Подготовка комикса

И заключительная диаграмма в продукте BPwin это DFD

DFD - диаграммы потоков данных. Так называется методология графического структурного анализа, описывающая внешние по отношению к системе источники и адресаты данных, логические функции, потоки данных и хранилища данных, к которым осуществляется доступ.

Декомпозируем Прием Заказа и Маркетинг

2.2 Теперь ознакомимся с Case - средством под названием Erwin

ERwin Data Modeler (ранее ERwin) - CASE-средство для проектирования и документирования баз данных, которое позволяет создавать, документировать и сопровождать базы данных, хранилища и витрины данных. Модели данных помогают визуализировать структуру данных, обеспечивая эффективный процесс организации, управления и администрирования таких аспектов деятельности предприятия, как уровень сложности данных, технологий баз данных и среды развертывания.

Создание хранимого отображения

Хранимым отображением называется отображение конкретного аспекта модели с удобным для презентации расположением, масштабом и цветовыми эффектами

Создаем сущности, и связи между ними заметим, что на диаграмме присутствует, как и связи 1 ко Многим, так и многие ко многим.

Теперь создаем атрибутивную модель, т.е. модель, содержащую все сущности в 3-ей нормальной форме со всеми атрибутами и связями.

Здесь мы задали все первичные ключи в наших сущностях.

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

Что бы перевести данные в базу данных Access надо сделать преобразование многие ко многим при помощи встроенного мастера преобразование и диаграмма примет вид.

запросы для создания базы

CREATE TABLE Доставка

(Приоритет smallint NULL ,

Местоположение varchar(20) NULL ,

Место_Выдачи varchar(20) NULL ,

Идентификатор_Заказов smallint NULL ,

id_Продукции smallint NULL ,

НомЗаказ smallint NOT NULL

)TABLE ДоставкаCONSTRAINT XPKДоставка PRIMARY KEY CLUSTERED (НомЗаказ ASC)NONCLUSTERED INDEX XIE1Доставка ON Доставка

(

Место_Выдачи ASC,

Местоположение ASC,

Приоритет ASC

)TABLE Заказы

(

СпосОплат varchar(20) NULL ,

ТДостав varchar(20) NOT NULL ,

Идентификатор_Заказов smallint NULL

)TABLE ЗаказыCONSTRAINT XPKЗаказы PRIMARY KEY CLUSTERED (ТДостав ASC)TABLE Кленты

(_Продукции smallint NOT NULL ,

ФИО varchar(20) NULL ,

ДатаРож datetime NULL ,

Адрес varchar(20) NULL ,

НомерКарты smallint NULL )TABLE КлентыCONSTRAINT XPKКленты PRIMARY KEY NONCLUSTERED (id_Продукции ASC)NONCLUSTERED INDEX XIE1Кленты ON Кленты

(

ФИО ASC,

ДатаРож ASC,

Адрес ASC

)TABLE Кленты_Заказы

(_Продукции smallint NOT NULL ,

ТДостав varchar(20) NOT NULL ,

НомКлиеЗак smallint NOT NULL

)TABLE Кленты_ЗаказыCONSTRAINT XPKКленты_Заказы PRIMARY KEY NONCLUSTERED (НомКлиеЗак ASC)TABLE Продукция

(

Идентификатор_Продукции smallint NOT NULL ,

Вселенная varchar(20) NULL ,

Название varchar(20) NULL ,

НомСерии smallint NULL ,

ЧислоСтраниц smallint NULL

)TABLE ПродукцияCONSTRAINT XPKПродукция PRIMARY KEY NONCLUSTERED (Идентификатор_Продукции ASC)NONCLUSTERED INDEX XIE1Продукция ON Продукция

(

Вселенная ASC,

НомСерии ASC,

ЧислоСтраниц ASC

)TABLE Продукция_Заказы

(

Идентификатор_Продукции smallint NOT NULL ,

ТДостав varchar(20) NOT NULL ,

НомПродукЗак smallint NOT NULL

)TABLE Продукция_ЗаказыCONSTRAINT XPKПродукция_Заказы PRIMARY KEY NONCLUSTERED (НомПродукЗак ASC)TABLE Склад

(

Идентификатор_Заказов smallint NOT NULL ,

ВремПост datetime NULL ,

ВремОжид datetime NULL

)TABLE СкладCONSTRAINT XPKСклад PRIMARY KEY NONCLUSTERED (Идентификатор_Заказов ASC)TABLE ДоставкаCONSTRAINT R_16 FOREIGN KEY (Идентификатор_Заказов) REFERENCES Склад (Идентификатор_Заказов)DELETE NO ACTIONUPDATE NO ACTIONTABLE ДоставкаCONSTRAINT R_17 FOREIGN KEY (id_Продукции) REFERENCES Кленты (id_Продукции)DELETE NO ACTIONUPDATE NO ACTIONTABLE ЗаказыCONSTRAINT R_14 FOREIGN KEY (Идентификатор_Заказов) REFERENCES Склад (Идентификатор_Заказов)DELETE NO ACTIONUPDATE NO ACTIONTABLE Кленты_ЗаказыCONSTRAINT Заказывает FOREIGN KEY (id_Продукции) REFERENCES Кленты(id_Продукции)DELETE NO ACTIONUPDATE NO ACTIONTABLE Кленты_ЗаказыCONSTRAINT Ожидает FOREIGN KEY (ТДостав) REFERENCES Заказы(ТДостав)DELETE NO ACTIONUPDATE NO ACTION

ALTER TABLE Продукция_ЗаказыCONSTRAINT Оформляют FOREIGN KEY (Идентификатор_Продукции) REFERENCES Продукция(Идентификатор_Продукции)

ON DELETE NO ACTIONUPDATE NO ACTIONTABLE Продукция_ЗаказыCONSTRAINT Запрашивают FOREIGN KEY (ТДостав) REFERENCES Заказы(ТДостав)DELETE NO ACTIONUPDATE NO ACTION

go

3. Разработка системы с помощью Rational Rose

информационный база данный запрос

Подразумеваем, что продажа продукции и заказы происходит при помощи сайта компании.

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

Поток событий для прецедента

Вариант использования «Изменить параметры учетной записи» позволяет клиенту который зарегистрировался на сайте изменять параметры учетной записи а так же изменять номера кредитных карт которые привязаны к кошельку

Предусловия

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

Основной поток

.Прецедент начинается, когда клиент заходит на сайт с продукцией

.Сайты предлагают войти на него под своей учетной записи

.Клиент проходит стадии идентификации и аутентификации

.Сайт подтверждает введенный логин и пароль. Если код не подтвержден, выполняется альтернативный поток событий А1.

.Сайт выводит список доступных действий:

Изменить параметры учетной записи;

Покупка;

Пополнение кошелька.

Заказать

.Клиент выбирает пункт «Изменить параметры учетной записи».

.Сайт выводит данные о клиенте в режиме изменения данных.

.Клиент вводит нужные изменения.

.Сайт определяет, веденые данные, не повторяют ли данные, которые уже задействованы на сайте. Если данные такие уже задействованы, выполняется альтернативный поток А2.

.Сайт сохраняет измененные данные.

.Клиента переводят на начальный этап после прохождение идентификации и аутентификации .

.Прецедент завершается.

Альтернативный поток А1. Ввод неправильного логина и пароля

.Сайт информирует клиента, что логин или пароль введен неправильно.

.Сайт предлагают вести еще раз.

.Прецедент завершается.

Альтернативный поток А2. Повторяемые данные.

.Сайт информирует клиента, что данный логин зарегистрирован на сайте.

.Сайт предлагают вести новый логин.

.Прецедент завершается.

Диаграмма последовательностей

Используем в прецеденте Покупка

Описывают поведение взаимодействующих групп объектов. Каждая диаграмма описывает поведение объектов в рамках только одного прецедента. На диаграмме изображаются объекты и те сообщения, которыми они обмениваются между собой. Определяют три типа сообщений:

информационные (informative) - сообщения, снабжающие объект-получатель информацией для обновления его состояния;

сообщения - запросы (interrogative) - сообщения, запрашивающие выдачу информации об объекте-получателе;

императивные (imperative) - сообщения, запрашивающие у объекта-получателя выполнение действия.

Кооперативная диаграмма

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

Диаграмма состояний

Используем в прецеденте Пополнение Кошелька

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

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

Сделана на прецеденте Покупка

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

Диаграмма пакетов

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

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

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

Так как классов в нашей работе не много мы можем обойтись без группировки

Диаграмма компонентов

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

Компоненты системы для Клиентской части

Компоненты системы для Серверной части

Схема базы данных

запросы для создания таблиц

CREATE TABLE T_Чтение_операции_с_кошелька (

Номер_Карты INT NOT NULL,PK_T_Чтение_операции_с_кошелька1 PRIMARY KEY NONCLUSTERED (Номер_Карты)

)TABLE T_Счет (

Номер_Счета INT NOT NULL,INT NOT NULL,

Баланс BIGINT NOT NULL,

Номер_Карты INT NOT NULL,

T_Чтение_операции_с_кошелька_Номер_Карты INT,

CONSTRAINT PK_T_Счет0 PRIMARY KEY NONCLUSTERED (Номер_Карты)

)INDEX TC_T_Счет1 ON T_Счет (T_Чтение_операции_с_кошелька_Номер_Карты )TABLE T_Счет ADD CONSTRAINT FK_T_Счет0 FOREIGN KEY (T_Чтение_операции_с_кошелька_Номер_Карты) REFERENCES T_Чтение_операции_с_кошелька (Номер_Карты)

Вывод

В данной курсовой работе я ознакомился с такими Сase - средствами как BPwin,Erwin и Ration Rose были спроектированы информационная система компании производства комиксов а так же базы данных к ним, был получен код Sql запросов что помогает, переводит данные модели в sql server а так же есть возможность переводит результаты в access все зависит от поставленной задачи.

Содержание 1. Постановка задачи . Разработка системы с помощью BPwin и ERwin средств .1 BPwin .2 Erwin . Разработка при помощи Rational Rose

Больше работ по теме: