Logo GenDocs.ru

Поиск по сайту:  


Загрузка...

Проектирование автоматизированной системы управления Магазин электроники - файл Отчет по курсовой работе.doc


Проектирование автоматизированной системы управления Магазин электроники
скачать (229.9 kb.)

Доступные файлы (2):

НОВОЕ.rsf
Отчет по курсовой работе.doc401kb.15.01.2009 13:49скачать

содержание
Загрузка...

Отчет по курсовой работе.doc

Реклама MarketGid:
Загрузка...
Содержание

1 Введение 3

2 Анализ предметной части 5

2.1 Описание предметной части 5

2.2 Разработка функциональной модели процесса управления магазином в соответствии с методом IDF0 5

2.2.1 Подпроцесс «Поставлять товар» 6

2.2.2 Подпроцесс «Складировать» 6

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 12

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 Вывод главы 21

4 Заключение 22

5 Список литературы 23

Приложение А 24

1 Введение



Информация в современном мире превратилась в один из наиболее важных ресурсов, а информационные системы (ИС) стали необходимым инструментом практически во всех сферах деятельности.

Информационная система – это программный комплекс, функции которого состоят в поддержке надежного хранения информации в памяти компьютера, выполнении специфических для данного приложения преобразований информации и вычислений, предоставления для пользователя удобного и легко осваиваемого интерфейса. Практически в любой области деятельности люди используют тот или иной вид моделей (математических, физических или компьютерных), чтобы иметь более ясное представление о том, что они делают. Разнообразие задач, решаемых с помощью ИС, привело к появлению множества разнотипных систем, отличающихся принципами построения и заложенными в них правилами обработки информации [1].

В городе Набережные Челны существует торгово-закупочная фирма «Оптовый магазин электроники». Она предоставляет клиентам максимально широкий ассортимент самой современной техники. «Оптовый магазин электроники» напрямую работает с производителями. Отчетность склада в магазине ведется в бумажном виде. Формирование заявок на поставку товара осуществляется вручную на основе запасов и занимает 2-3 часа.

Проведя анализ данного процесса, было выделено несколько проблем:

  1. Использование бумажной документации замедляет время формирования заявки на поставку товаров.

  2. Уточнение количества и наличие товара на складе замедляет процесс продажи товара.

Целью проекта является повышение эффективности работы отдела закупок и складирования, уменьшение экономических затрат на расходные материалы и уменьшение длительности времени выполнения процесса с 2-3 часов до 1-15 минут.

Для достижения этих целей требуется решить следующие задачи:

 провести анализ предметной части;

 разработать модель процесса управления магазином;

 разработать модель функциональных требований к системе;

 разработать информационную модель процесса в соответствии с методом ERD;

 разработать UML-модель прецедентов системы в соответствии с методом UP;

 разработать техническое задание на создание системы.

^

2 Анализ предметной части



2.1 Описание предметной части

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

Далее приводится разработка функциональной модели процесса в соответствии с методом IDF0.
^ 2.2 Разработка функциональной модели процесса управления магазином в соответствии с методом IDF0

Главная задача и функция процесса выражена в виде процесс «Управлять магазином». Процесс выражен в функциональной модели блоком под номером А0, который изображен на рисунке 1 приложения А.

Основными элементами управления данного блока являются «Законодательство» и «Документация».

Механизмами данного функционального блока являются «Персонал». В результате, то есть на выходе данного блока, должны быть сформированы:

  • проданный товар;

  • накладная;

Структура вход/выходных, управляющих характеристик и механизмов, представлена в таблице 1.

Далее приводится декомпозиция данного процесса на три подпроцесса, выраженные в модели функциональными блоками. Таким образом, управление магазином – это результаты взаимосвязи блоков:

  • блок А1 «Поставлять товар»;

  • блок А2 «Складировать»;

  • блок А3 «Продать».

Графическое представление взаимосвязи функциональных блоков А1, А2, А3 изображена на рисунке 2 приложения А.

^ Таблица 1 — Вход/выходные, управляющие характеристики и механизмы блока А0

Виды характеристик

Наименования характеристик

Вход

Товар

Сопровождающие документы

Информация о покупателе

Управление

Законодательство

Документация

Механизм

Персонал

Выход

Проданный товар

Накладная



^

2.2.1 Подпроцесс «Поставлять товар»


Данный подпроцесс представлен на схеме функциональным блоком с номером А1 и представляет собой все трудовые операции по обеспечению работоспособного состояния подвижного состава предприятия. Дальнейшая декомпозиция данного блока представляет все требуемые трудовые операции. Декомпозиция блока А1 представлена на рисунке 3 приложения А.

Структура вход/выходных, управляющих характеристик и механизмов, представлена в таблице 2.

^ Таблица 2 — Вход/выходные, управляющие характеристики и механизмы блока А1

Виды характеристик

Наименования характеристик

Вход

Товар

Сопровождающие документы

Информация о состоянии склада

Управление

Документация

Механизм

Персонал (экспедитор)

Выход

Товар на складирование

^

2.2.2 Подпроцесс «Складировать»


Данный подпроцесс представлен на схеме функциональным блоком с номером А2 и представляет собой все трудовые операции по обеспечению работоспособного состояния подвижного состава предприятия. Дальнейшая декомпозиция данного блока представляет все требуемые трудовые операции. Декомпозиция блока А2 представлена на рисунке 4 приложения А.

Структура вход/выходных, управляющих характеристик и механизмов, представлена в таблице 2.

^ Таблица 2 — Вход/выходные, управляющие характеристики и механизмы блока А2

Виды характеристик

Наименования характеристик

Вход

Товар на складирование

Управление

Документация

Механизм

Персонал (кладовщик)

Выход

Товар на продажу

Информация о состоянии склада


^

2.3 Разработка информационной модели процесса управления магазином в соответствии с методом ERD


В ходе анализа проектируемой системы были определены следующие сущности.

^

2.3.1 Сущность «Товар»


Данная сущность содержит в себе информацию о товарах. Атрибутами сущности являются:

– ID товара;

– наименование;

– цена;

– описание.

Ключом сущности является атрибут «ID товара». Он является уникальным для всех товаров. Диаграмма рассматриваемой сущности показана на рисунке 1



Рисунок 1 Сущность «Товар»
^

2.3.2 Сущность «Клиент»


Данная сущность содержит в себе информацию о клиентах. Атрибутами сущности являются:

– ID клиента;

– фамилия;

– имя;

– отчество;

– адрес;

– телефон.

Ключом сущности является атрибут «ID клиента». Он является уникальным для всех клиентов. Диаграмма рассматриваемой сущности показана на рисунке 2.



Рисунок 2 Сущность «Клиенты»

^

2.3.3 Сущность «Покупки»


Данная сущность содержит в себе информацию о покупках. Атрибутами сущности являются:

– ID покупки;

– дата покупки;

– цена;

– количество;

– сумма;

– НДС;

– сумма с НДС.

Ключом сущности является атрибут «ID покупки». Он является уникальным для всех покупок. Диаграмма рассматриваемой сущности показана на рисунке 3.



Рисунок 3 Сущность «Покупки»

^

2.3.4 Сущность «Заказы»


Данная сущность содержит в себе информацию о заказах. Атрибутами сущности являются:

– ID заказа;

– дата заказа;

– количество ;

– сумма заказа;

Ключом сущности является атрибут «ID заказа». Он является уникальным для всех заказов. Диаграмма рассматриваемой сущности показана на рисунке 4.



Рисунок 4 Сущность «Заказы»
^

2.3.5 Сущность «Сотрудники»


Данная сущность содержит в себе информацию о сотрудниках. Атрибутами сущности являются:

– ID сотрудника;

– фамилия;

– имя ;

– отчество ;

– пол ;

– дата рождения ;

– отдел;

– должность;

– зарплата ;

– дата приема на работу;

Ключом сущности является атрибут «ID сотрудника». Он является уникальным для всех сотрудников. Диаграмма рассматриваемой сущности показана на рисунке 5.



Рисунок 5 Сущность «Сотрудники»
^

2.3.6 Сущность «Производитель»


Данная сущность содержит в себе информацию о производителях. Атрибутами сущности являются:

– ID производителя;

– название;

– адрес ;

– телефон ;

Ключом сущности является атрибут «ID производителя». Он является уникальным для всех производителе. Диаграмма рассматриваемой сущности показана на рисунке 6.



Рисунок 6 Сущность «Производитель»
^

2.3.7 Сущность «Поставщик»


Данная сущность содержит в себе информацию о поставщиках. Атрибутами сущности являются:

– ID поставщика;

– ФИО;

– наименование поставщика ;

– ИНН ;

– юридический адрес ;

– телефон ;

Ключом сущности является атрибут «ID поставщика». Он является уникальным для всех поставщиков. Диаграмма рассматриваемой сущности показана на рисунке 7.



Рисунок 7 Сущность «Поставщик»
^

2.3.8 Сущность «Склад»


Данная сущность содержит в себе информацию о складе. Атрибутами сущности являются:

– ID поставки;

– № товарной накладно;

– дата поставки ;

– цена ;

– количество ;

– доступно ;

– выписано ;

– остаток ;

Ключом сущности является атрибут «ID поставки». Он является уникальным для всего склада. Диаграмма рассматриваемой сущности показана на рисунке 8.



Рисунок 8 Сущность «Склад»

В ходе разработки ERD модели была получена следующая информация о предметной области: список сущностей и список атрибутов сущностей. На основе этих данных на рисунке 9 представлены отношения рассмотренных сущностей.
^

2.4 Разработка модели требований к системе


Разработка требований к автоматизированной системе управление «Оптовым магазином электроники» (АСУ «ОМЭ») проводилась на основании того, что должна делать система в конечном результате.

Функциональные требования к системе:

1. АСУ «ОМЭ» должна формировать информацию о состоянии склада .

2. АСУ «ОМЭ» должна редактировать информацию о потребителях.

3. АСУ «ОМЭ» должна редактировать информацию о товаре.

4. АСУ «ОМЭ» должна редактировать информацию о поставщике.

5. АСУ «ОМЭ» должна редактировать информацию о потребителях

6. АСУ «ОМЭ» должна добавлять информацию о потребителях.

7. АСУ «ОМЭ» должна добавлять информацию о товаре.

8. АСУ «ОМЭ» должна добавлять информацию о поставщике.

9. АСУ «ОМЭ» должна информировать о продаже товара.
^

2.5 Разработка UML-модели прецедентов системы в соответствии с методом UP


На основании функциональных требований, мы определили актеров и прецедентов.

Актеры — роли, выполняемые людьми или сущностями, использующими систему. Прецеденты — то, что актеры могут сделать с системой.

В нашем случае Актерами являются «Сотрудник» и «Покупатель». А в роли прецедентов выступают элементы модули требований.

После того, как определили составляющие диаграммы прецедентов, мы смоделировали модель прецедентов. Графическое представление данной диаграммы представлено на рисунке 10.
^

2.6 Составление спецификаций


Далее к каждому прецеденту должна быть предоставлена спецификация прецедента. Спецификацию всех прецедентов было принято выполнить в виде таблиц. Спецификации прецедентов приведены в таблицах 1−8.



Рисунок 10 — диаграмма прецедентов
^ Таблица 1 – Спецификация прецедента «Формировать информацию о состоянии склада»

Прецедент: ФормироватьИнформациюОСостоянииСклада

ID: 1

Краткое описание:

Регистрация количества на складе

Главные актеры:

Сотрудник

Второстепенные актеры:

Нет

Предусловия:

Поступление товара. Запрос остатка.

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

Прецедент начинается когда сотрудник формирует состояние склада.

Система регистрирует все записи.

Система формирует запись в базе данных о всех товарах.

Постусловия:

В базе данных имеется вся информация о состоянии склада.

Альтернативные потоки:

Нет.


^ Таблица 2 – Спецификация прецедента «Редактировать информацию о потребителях»

Прецедент: РедактироватьИнформациюОПотребителях

ID: 1

Краткое описание:

Редактирование информацию о потребителях

Главные актеры:

Сотрудник

Второстепенные актеры:

Нет

Предусловия:

Изменение персональных данных покупателя.

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

Прецедент начинается, когда потребитель изменяет личные данные.

Система регистрирует все записи.

Система формирует запись в базе данных о всех товарах.

Постусловия:

В базе данных имеется вся информация о клиенте.

Альтернативные потоки:

Нет.


^ Таблица 3 – Спецификация прецедента «Редактировать информацию о товаре»

Прецедент: РедактироватьИнформациюОТоваре

ID: 1

Краткое описание:

Изменение данных о товаре

Главные актеры:

Сотрудник

Второстепенные актеры:

Нет

Предусловия:

Изменение характеристик товара.

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

Прецедент начинается, когда товар изменяет свои свойства.

Система регистрирует все записи.

Система формирует запись в базе данных о всех товарах.

Постусловия:

В базе данных имеется вся информация о товаре.

Альтернативные потоки:

Нет.


^ Таблица 4 – Спецификация прецедента «Редактировать информацию о поставщике»

Прецедент: РедактироватьИнформациюОПоставщике

ID: 1

Краткое описание:

Изменение данных о поставщике

Главные актеры:

Сотрудник

Второстепенные актеры:

Нет

Предусловия:

Изменение данных поставщика.

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

Прецедент начинается, когда данные о поставщике изменяются.

Система регистрирует все записи.

Система формирует запись в базе данных о поставщиках.

Постусловия:

В базе данных имеется вся информация о поставщиках.

Альтернативные потоки:

Нет.


^ Таблица 5 – Спецификация прецедента «Добавлять информацию о потребителях»

Прецедент: ДобавлятьИнформациюОПотребителях

ID: 1

Краткое описание:

Регистировать данных о потребителе

Главные актеры:

Сотрудник

Второстепенные актеры:

Нет

Предусловия:

Покупка товара.

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

Прецедент начинается, когда клиент приобретает товар.

Система регистрирует все записи.

Система формирует запись в базе данных о клиенте.

Постусловия:

В базе данных имеется вся информация о клиенте.

Альтернативные потоки:

Нет.


^ Таблица 6 – Спецификация прецедента «Добавлять информацию о поставщиках»

Прецедент: ДобавлятьИнформациюОПоставщиках

ID: 1

Краткое описание:

Регистрация поставщика

Главные актеры:

Сотрудник

Второстепенные актеры:

Нет

Предусловия:

Поставка товара.

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

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

Система регистрирует все записи.

Система формирует запись в базе данных о поставщике.

Постусловия:

В базе данных имеется вся информация о клиенте.

Альтернативные потоки:

Нет.


^ Таблица 7 – Спецификация прецедента «Формировать информацию о состоянии склада»

Прецедент: ДобавлятьИнформациюОПоставщиках

ID: 1

Краткое описание:

Регистрация поставщика

Главные актеры:

Сотрудник

Второстепенные актеры:

Нет

Предусловия:

Поставка товара.

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

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

Система регистрирует все записи.

Система формирует запись в базе данных о поставщике.

Постусловия:

В базе данных имеется вся информация о клиенте.

Альтернативные потоки:

Нет.


^ Таблица 8 – Спецификация прецедента «Информировать о продаже товара»

Прецедент: Информировать о продаже товара

ID: 1

Краткое описание:

Информирование о состоянии заказа товара

Главные актеры:

Сотрудник

Второстепенные актеры:

Покупатель

Предусловия:

Покупка товара.

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

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

Система регистрирует все записи.

Система формирует запись в базе данных о продажах.

Постусловия:

В базе данных имеется вся информация о состоянии склада.

Альтернативные потоки:

Нет.


^

2.7 Вывод по главе


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

На основании разработанных моделей требований и прецедентов были определены основные аспекты и функции системы.
^

3 Разработка технического задания



3.1 Общие сведения

3.1.1 Наименование системы

3.1.1.1 Полное наименование системы


Автоматизированная система управления «Оптовый магазин электроники»

3.1.1.2 Краткое наименование


^ АСУ «ОМЭ»

3.2 Назначение и цели создания системы

3.2.1 Назначение системы

Система предназначена для повышения эффективности работы отдела логистики предприятия. Основным назначением системы является автоматизация процесса заказа товара и его дальнейшей продажи.
^

3.2.2 Цели создания системы


Система создается с целью:

1. Автоматизации процесса управления магазином.

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

В результате должны быть улучшены значения показателей:

— эффективность работы отдела складирования магазина;

— время обслуживания клиентов;

^

3.3 Характеристика объектов автоматизации


Выделены следующие процессы в деятельности предприятия, в рамках которых производится анализ информации и вынесены выводы о возможности их автоматизации, приведенные в таблице 9.

^ Таблица 9 — Описание организационной структуры

Структурное подразделение

Наименование

процесса

Возможность автоматизации

Решение об автоматизации в ходе проекта

Отдел склада

Составление информационной структуры склада

Возможна

Будет автоматизирована

Отдел закупки

Получение заявки на покупку товара

Возможна

Будет автоматизирована



^

3.4 Требования к системе

3.4.1 Требования к системе в целом

3.4.1.1 Требования к структуре и функционированию системы


Система должна быть централизованной – все данные должны быть располагаться в центральном хранилище.

Предполагается следующие функциональные системы:

— подсистема формирования заявок;

— подсистема обработки заявок.

^

3.4.2 Требования к функциям, выполняемым системой

3.4.2.1 Подсистема Управлять магазином

В таблице 10 приведены функции и задачи, подлежащие автоматизации данной подсистемы.

^ 3.4.2.2 Подсистема поставлять товар

В таблице 11 приведены функции и задачи, подлежащие автоматизации данной подсистемы.

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

Функция

Задача

1. Формировать отчетность магазина

1.1. Добавление, редактирование и удаление информации о потребителях, поставщиках, товарах.

1.2 Сохранить отчетность

2.Выводить информацию на экран


frame1


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

Функция

Задача

1. Поставлять товар

1.1. Регистрация товара на складе.

1.2 Сохранить отчетность

2.Выводить информацию на экран


frame2



^

3.4.3 Требования к видам обеспечения


3.4.3.1 Требования к информационному обеспечению

3.4.3.1.1 Требования к информационной совместимости со смежными системами

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

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

^ 3.4.3.1.2 Требования по использованию классификаторов и унифицированных документов

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

Основные классификаторы и справочники в системе должны быть едиными.

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

3.5 Вывод главы


В результате разработки технического задания были получены ответы на такие вопросы как:

1. Что надо сделать.

2. Для чего и с какой целью.

3. Какие требования будут предъявлены функциям системы.

Так же определены составляющие для системы. Данная информация служит исходной базой для проектирования и разработки требуемой системы.


4 Заключение


Проделанная работа в данном проекте является началом проектирования автоматизированной системы управления магазином.

Мы определили требования и функции будущей системы для решения проблем в организации оптимизации работы магазина.

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

Для повышения эффективности процесса работы магазина, уменьшение времени процесса были определены следующие подсистемы:

— подсистема поставки товара;

— подсистема складирования;

— подсистема продажи товара.

^

5 Список литературы





  1. Грекул, В.И. Проектирование информационных систем: учебное пособие / В.И. Грекул, Г.Н. Денищенко, Н.Л. Коровкина. – М.: Интернет-Ун-т Информ. технологий, 2005. – 304 с.

  2. ГОСТ 34.602-89 «Техническое задание на создание автоматизированной системы»;

  3. Арлоу Д., Нейштадт И. UML 2 и унифицированный процесс. Практический объектно-ориентированный анализ и проектирование. — Спб.: Символ-Плюс, 2007 г.;

  4. Вендров А.М. «Проектирование программного обеспечения экономических информационных систем» — М.: Финансы и статистика, 2002 г.

  5. Мамиконов А.Г. «Проектирование АСУ» — М.: Высшая школа, 1987 г.

^

Приложение А




Рисунок 1 — контекстная диаграмма процесса

Рисунок 2 — декомпозиция блока «Управлять магазином» контекстной диаграммы



Рисунок 3 — декомпозиция блока «Поставлять товар»


Рисунок 4 — декомпозиция блока «Складировать»



Рисунок 9 — ERD модель.





Скачать файл (229.9 kb.)

Поиск по сайту:  

© gendocs.ru
При копировании укажите ссылку.
обратиться к администрации
Рейтинг@Mail.ru