Автор: Пользователь скрыл имя, 10 Марта 2012 в 12:03, курсовая работа
Целью проекта является повышение эффективности работы отдела закупок и складирования, уменьшение экономических затрат на расходные материалы и уменьшение длительности времени выполнения процесса с 2-3 часов до 1-15 минут.
Для достижения этих целей требуется решить следующие задачи:
провести анализ предметной части;
разработать модель процесса управления магазином;
1 Введение 3
2 Анализ предметной части 5
2.1 Описание предметной части 5
2.2 Разработка функциональной модели процесса управления магазином в соответствии с методом IDF0 5
2.2.1 Подпроцесс «Поставлять товар» 6
2.2.2 Подпроцесс «Складировать» 7
2.3 Разработка информационной модели процесса управления магазином в соответствии с методом ERD 7
2.3.1 Сущность «Товар» 7
2.3.2 Сущность «Клиент» 8
2.3.3 Сущность «Покупки» 8
2.3.4 Сущность «Заказы» 9
2.3.5 Сущность «Сотрудники» 9
2.3.6 Сущность «Производитель» 10
2.3.7 Сущность «Поставщик» 11
2.3.8 Сущность «Склад» 11
2.4 Разработка модели требований к системе 12
2.5 Разработка UML-модели прецедентов системы в соответствии с методом UP 13
2.6 Составление спецификаций 13
2.7 Вывод по главе 17
3 Разработка технического задания 18
3.1 Общие сведения 18
3.1.1 Наименование системы 18
3.2 Назначение и цели создания системы 18
3.2.1 Назначение системы 18
3.2.2 Цели создания системы 18
3.3 Характеристика объектов автоматизации 18
3.4 Требования к системе 19
3.4.1 Требования к системе в целом 19
3.5 Вывод главы 20
4 Заключение 22
5 Список литературы 23
– ID производителя;
– название;
– адрес ;
– телефон ;
Ключом сущности является атрибут «ID производителя». Он является уникальным для всех производителе. Диаграмма рассматриваемой сущности показана на рисунке 6.
Рисунок 6 — Сущность «Производитель»
Данная сущность содержит в себе информацию о поставщиках. Атрибутами сущности являются:
– ID поставщика;
– ФИО;
– наименование поставщика ;
– ИНН ;
– юридический адрес ;
– телефон ;
Ключом сущности является атрибут «ID поставщика». Он является уникальным для всех поставщиков. Диаграмма рассматриваемой сущности показана на рисунке 7.
Рисунок 7 — Сущность «Поставщик»
Данная сущность содержит в себе информацию о складе. Атрибутами сущности являются:
– ID поставки;
– № товарной накладно;
– дата поставки ;
– цена ;
– количество ;
– доступно ;
– выписано ;
– остаток ;
Ключом сущности является атрибут «ID поставки». Он является уникальным для всего склада. Диаграмма рассматриваемой сущности показана на рисунке 8.
Рисунок 8 — Сущность «Склад»
В ходе разработки ERD модели была получена следующая информация о предметной области: список сущностей и список атрибутов сущностей. На основе этих данных на рисунке 9 представлены отношения рассмотренных сущностей.
Разработка требований к автоматизированной системе управление «Оптовым магазином электроники» (АСУ «ОМЭ») проводилась на основании того, что должна делать система в конечном результате.
Функциональные требования к системе:
1. АСУ «ОМЭ» должна формировать информацию о состоянии склада .
2. АСУ «ОМЭ» должна редактировать информацию о потребителях.
3. АСУ «ОМЭ» должна редактировать информацию о товаре.
4. АСУ «ОМЭ» должна редактировать информацию о поставщике.
5. АСУ «ОМЭ» должна редактировать информацию о потребителях
6. АСУ «ОМЭ» должна добавлять информацию о потребителях.
7. АСУ «ОМЭ» должна добавлять информацию о товаре.
8. АСУ «ОМЭ» должна добавлять информацию о поставщике.
9. АСУ «ОМЭ» должна информировать о продаже товара.
На основании функциональных требований, мы определили актеров и прецедентов.
Актеры — роли, выполняемые людьми или сущностями, использующими систему. Прецеденты — то, что актеры могут сделать с системой.
В нашем случае Актерами являются «Сотрудник» и «Покупатель». А в роли прецедентов выступают элементы модули требований.
После того, как определили составляющие диаграммы прецедентов, мы смоделировали модель прецедентов. Графическое представление данной диаграммы представлено на рисунке 10.
Далее к каждому прецеденту должна быть предоставлена спецификация прецедента. Спецификацию всех прецедентов было принято выполнить в виде таблиц. Спецификации прецедентов приведены в таблицах 1−8.
Рисунок 10 — диаграмма прецедентов
Таблица 1 – Спецификация прецедента «Формировать информацию о состоянии склада»
Прецедент: ФормироватьИнформациюОСостояни |
ID: 1 |
Краткое описание: Регистрация количества на складе |
Главные актеры: Сотрудник |
Второстепенные актеры: Нет |
Предусловия: Поступление товара. Запрос остатка. |
Основной поток: Прецедент начинается когда сотрудник формирует состояние склада. Система регистрирует все записи. Система формирует запись в базе данных о всех товарах. |
Постусловия: В базе данных имеется вся информация о состоянии склада. |
Альтернативные потоки: Нет. |
Таблица 2 – Спецификация прецедента «Редактировать информацию о потребителях»
Прецедент: РедактироватьИнформациюОПотреб |
ID: 1 |
Краткое описание: Редактирование информацию о потребителях |
Главные актеры: Сотрудник |
Второстепенные актеры: Нет |
Предусловия: Изменение персональных данных покупателя. |
Основной поток: Прецедент начинается, когда потребитель изменяет личные данные. Система регистрирует все записи. Система формирует запись в базе данных о всех товарах. |
Постусловия: В базе данных имеется вся информация о клиенте. |
Альтернативные потоки: Нет. |
Таблица 3 – Спецификация прецедента «Редактировать информацию о товаре»
Прецедент: РедактироватьИнформациюОТоваре |
ID: 1 |
Краткое описание: Изменение данных о товаре |
Главные актеры: Сотрудник |
Второстепенные актеры: Нет |
Предусловия: Изменение характеристик товара. |
Основной поток: Прецедент начинается, когда товар изменяет свои свойства. Система регистрирует все записи. Система формирует запись в базе данных о всех товарах. |
Постусловия: В базе данных имеется вся информация о товаре. |
Альтернативные потоки: Нет. |
Таблица 4 – Спецификация прецедента «Редактировать информацию о поставщике»
Прецедент: РедактироватьИнформациюОПостав |
ID: 1 |
Краткое описание: Изменение данных о поставщике |
Главные актеры: Сотрудник |
Второстепенные актеры: Нет |
Предусловия: Изменение данных поставщика. |
Основной поток: Прецедент начинается, когда данные о поставщике изменяются. Система регистрирует все записи. Система формирует запись в базе данных о поставщиках. |
Постусловия: В базе данных имеется вся информация о поставщиках. |
Альтернативные потоки: Нет. |
Таблица 5 – Спецификация прецедента «Добавлять информацию о потребителях»
Прецедент: ДобавлятьИнформациюОПотребител |
ID: 1 |
Краткое описание: Регистировать данных о потребителе |
Главные актеры: Сотрудник |
Второстепенные актеры: Нет |
Предусловия: Покупка товара. |
Основной поток: Прецедент начинается, когда клиент приобретает товар. Система регистрирует все записи. Система формирует запись в базе данных о клиенте. |
Постусловия: В базе данных имеется вся информация о клиенте. |
Альтернативные потоки: Нет. |
Таблица 6 – Спецификация прецедента «Добавлять информацию о поставщиках»
Информация о работе Разработка функциональной модели процесса управления магазином