Файл: ВКР проектирование информационной системы учета заказов на ООО Мамонт.pdf
ВУЗ: Московский государственный машиностроительный университет (МАМИ)
Категория: Дипломная работа
Дисциплина: Проектирование информационных систем
Добавлен: 21.10.2018
Просмотров: 5647
Скачиваний: 29
46
Обработать заказы
Счета
Контроль оплаты
Клиенты
Данные счетов
Данные счетов
Информация о клиенте
Информация о клиенте
Клиенты
Доставить продукцию
Заказы
Данные заказа
Информация о доставке
Склад
Информация о продукции
Клиенты
Информация о продукции
Данные счетов
Информация о клиенте
Пункты
самовывоза
Информация о продукции
Информация о продукции
Рисунок 3.2 - Декомпозированная DFD-диаграмма А0. Модель TO-BE
В модели TO-BE уже существует по сравнению с моделью AS-IS
хранилища с данными о клиенте и заказе. Менеджер при поступлении заказа
от клиента проверяет в начале, находится ли клиент в базе, и при отсутствии
добавляет все его необходимые данные. Требования и пожелания клиента
менеджер учитывает в заказе, оформляет его и добавляет в систему новый
заказ. После этого клиент может заходить в систему по своим
идентификационным данным и отслеживать статус своего заказа.
3.3 Объектно-ориентированное проектирование информационной
системы учета заказов
1. Диаграмма вариантов использования
На рис. 3.3 изображена диаграмма вариантов использования, на
которой показаны сотрудники организации, которые непосредственно
участвуют в процессе учета заказов.
47
Менеджер
Бух система
Клиент
Зарегистрировать клиента
Ввести новый заказ
Создать заказ
Изменить существующий заказ
Печать документов
Выгрузка отчетов
«includes»
Выбор типа товара
Бухгалтер
Поиск
Удалить существующий заказ
Мониторинг статуса заказа
Запрос на изменение или удаление заказа
Рисунок 3.3 - Диаграмма вариантов использования
Некоторые варианты использования, представленные на диаграмме:
Со стороны менеджера:
Ввести новый заказ – менеджер по продажам заносит в базу данных
всю информацию по заказу.
Зарегистрировать клиента – менеджер по продажам заносит в базу
данных всю необходимую информацию о клиенте, с помощью которой будет
происходить его дальнейшая идентификация в системе.
Изменить и удалить существующий заказ – менеджер по продажам
по требованию клиента изменяет или удалят существующий заказ.
Со стороны бухгалтера:
Поиск – найти интересующую информацию по клиенту, заказу или
товару.
Печать документов – распечатать нужный документ.
48
Выгрузка отчета – выгрузить из системы базовые отчеты по работе
сотрудников.
Со стороны клиента:
Создать заказ – клиент без помощи менеджера создает заказ.
Мониторинг статуса заказа – клиент отслеживает статус заказа.
Запрос на изменение или удаление заказа – клиент может отправить
запрос менеджеру на изменение или удаление статуса заказа.
2. Диаграмма классов
Диаграмма
классов
–
статическая
структурная
диаграмма,
описывающая структуру системы. Например, менеджер принимает заказ от
клиента и они выбирают тип товара. Вносят все необходимые данные в заказ,
после этого проверяется на правильность оформления, заполнены ли все поля
корректно, после этого заказ сохраняется, помещается в базу. Далее
составляется договор и подписывается клиентом и директором (рис.3.4).
49
Create()
«Boundary»
ВыборЗаказа
Open()
SubmitInfo()
Save()
«Boundary»
ДеталиЗаказа
SaveOrder()
Commit()
«Control»
МенеджерТранзакций
SaveOrder()
«Control»
МенеджерЗаказа
Create()
SetInfo()
GetInfo()
Cancel()
OrderNumber : Integer
CustumerName : String
OrderDate : Date
OrderFillDate : Date
Price : Double
Status : Char
«Entity»
Заказ
Create()
SetInfo()
GetInfo()
ItemID : Integer
ItemDescription : String
«Entity»
ПозицияЗаказа
1
1..*
0..1
0..1
1
0..*
0..1
0..1
0..1
0..*
1
1..*
0..1
0..*
Print()
Open()
«Boundary»
Печать документов
Submit()
Exit()
«Control»
Менеджер печати
Create()
Save()
Edit()
GetInfo()
id : Integer
login : Char
pass : Char
name : Char
phone : Long
adress : Char
email : Char
money : Double
spam : Integer
RegistrDate : Date
RegistrIP : Char
«Entity»
Клиенты
Save()
Open()
«Boundary»
Создание клиента
Edit()
Delete()
Save()
Open()
«Boundary»
Редактирование данных
Save()
Open()
«Control»
Менеджер клиентов
0..1
0..1
0..1
0..1
0..1
0..1
0..1
0..1
0..1
0..1
0..1
0..1
Find()
Open()
«Boundary»
Поиск
0..1
0..1
Рисунок 3.4 - Диаграмма классов
Рассмотрим подробнее:
Boundary
(граница):
Выбор
Заказа,
Создание
клиента,
Редактирование данных, Печать документов, Детали Заказа, Поиск.
Control (управление): Менеджер Заказа, Менеджер печати,
Менеджер клиентов, Менеджер транзакций.
Entity (сущность): Заказ, Клиенты, Позиция Заказа.
3. Диаграмма последовательности
Диаграмма
последовательности
отражает
поток
событий,
происходящих в рамках варианта использования. На ней изображаются
участвующие во взаимодействии объекты и последовательность сообщений,
которыми они обмениваются.
50
Менеджер принимает заказ от клиента и они выбирают тип товара.
Вносят все необходимые данные в заказ, после этого проверяется на
правильность оформления, заполнены ли все поля корректно, после этого
заказ сохраняется, помещается в базу. Далее составляется договор и
подписывается клиентом и директором (рис.3.5).
: Продавец
«Boundary»
ФормаДеталиЗаказа : ДеталиЗаказа
«Entity»
Заказ1234 : Заказ
«Boundary»
ВыборВариантаЗаказа : ВыборЗаказа
«Control»
МенеджерЗаказа : МенеджерЗаказа
«Control»
МенеджерТранзакций : МенеджерТранзакций
Create()
Open
SubmitInfo()
Save()
SaveOrder()
Create
SetInfo()
SaveOrder()
GetInfo()
Commit()
Рисунок 3.5 - Диаграмма последовательностей для вариант использования
«Создать Заказ»
4. Диаграмма кооперации
Диаграмма кооперации позволяет графически представить структурные
отношения между объектами, участвующими во взаимодействии.
На рис. 3.5. представлена диаграмма кооперации для варианта
использования «Редактирование данных».
Сотруднику приходит заявка, он открывает его, проверяет на наличие
недочетов и др. При наличии ошибок, менеджер связывается с клиентом и