Файл: Проектирование реализации операций бизнес-процесса "Складской учет" (Предметная область).pdf
Добавлен: 22.04.2023
Просмотров: 315
Скачиваний: 2
СОДЕРЖАНИЕ
1.3 Анализ информационных потребностей пользователей
2.1 Моделирование бизнес-процессов
2.1.1 Взгляд на предприятие с точки зрения функциональности системы (IDEF0)
2.1.2 Взгляд на предприятие с точки зрение потоков информации (DFD)
2.1.3 Взгляд на предприятие с точки зрения алгоритма выполнения работы (IDEF3)
2.2 Разработка информационной модели данных
2.3 Схемы и описание программных модулей
2.4 Характеристика базы данных
2.6 Разработка форм и отчетов складского учета предприятия
2.7 Контрольный пример реализации проекта
Любой блок модели имеет «стрелки». Данные «стрелки» обозначают события, места, людей и т.д. Они связывают диаграммы и блоки, а так же блоки между собой. Любой блок должен иметь хотя бы одну стрелку управления.
Входными параметрами для блока является данные или материалы. Так как эти параметры преобразовываются самим блоком для получения какого то результата. Стрелка входа может быть необязательна.
Так же блок обязательно должен иметь стрелки управления. В данном случае для бизнес-процесса складского учета, стрелкой управления будут инструкции.
Выходными параметрами будет переработанная информация, которая была подана на вход.
Механизмом исполнения является информационная система склада предприятия.
На рисунке 2 показана диаграмма IDEF0 для бизнес-процесса складского учета предприятия ООО «Партнер».
Для более подробного описания блоков используется декомпозиция. На рисунке 3 показана декомпозиция диаграммы IDEF0.
Рисунок 2 – IDEF0
Рисунок 3 – Декомпозиция IDEF0
2.1.2 Взгляд на предприятие с точки зрение потоков информации (DFD)
Для наглядной демонстрации передачи и обработки данных в системе складского учета предприятия, используются диаграммы потоков данных (DFD).
Данные диаграммы разрабатываются для наглядной демонстрации документооборота. DFD используют в основном как дополнение к IDEF0.
Диаграммы потоков данных показывают систему связанных между собой работ как она есть на самом деле.
Основной задачей построения данной диаграммы является продемонстрировать происходящие в данный момент операции документооборота.
Основной целью построения диаграммы является продемонстрировать преобразование входных данных в выходные.
Диаграмма потока данных складского учета предприятия ООО «Партнер» содержит внешние сущности, работы, потоки данных и хранилища.
Последующее моделирование целесообразнее проводить использую диаграммы DFD.
На рисунке 4 представлена декомпозиция блока «Приемка товара на склад». Данный блок делится на следующие действия:
- Проверка накладной;
- Проверка продукции;
- Добавление данных;
- Передача на хранение.
Так же на рисунках 5 и 6 представлена декомпозиция блоков «Хранение и переучет продукции» и отгрузка.
Рисунок 4 – Приемка товара на склад
Рисунок 5 – Хранение и переучет продукции
Рисунок 6 – отгрузк
2.1.3 Взгляд на предприятие с точки зрения алгоритма выполнения работы (IDEF3)
Для демонстрации описания рабочих процессов используется нотация IDEF3. На данном этапе важно корректно отобразить последовательность выполнения процедур.
Для полного описания принципа взаимодействия потоков данных, модель дополняется диаграммами IDEF3.
Данный метод описывает процессы, акцентируя внимание на протекании этих самых процессов и их отношениям с объектами.
Нотация IDEF3 описывает два типа моделей. Либо модель позволяет отображать процессы в их определенной последовательности, позволяя тем самым увидеть функционирование предприятия, либо демонстрирует переходные состояния объектов, предполагая визуализацию последовательности состояний объекта по прохождению какого либо процесса.
На рисунке 7 представлена декомпозиция блока «проверка товарно-транспортной накладной». Данный блок делится на следующие действия:
- Принятие накладной;
- Проверка поставщиков;
- Проверка реквизитов документов;
- Проверка на соответствие количества поставляемых продуктов.
Так же на рисунке 8 представлена декомпозиция блока «проверка поставленной продукции».
Рисунок 7 – Проверка товарно-транспортной накладной
Рисунок 8 – Проверка поставленной продукции
2.2 Разработка информационной модели данных
Графическое представление информационных моделей предметной области значительно упрощает восприятие структуры базы данных. В ходе построения таких моделей выделяют сущности, идентификацию связей между ними, а так же атрибуты сущностей и их первичных ключей. Так ER-диаграммы наиболее распространенный вид графического изображения реляционной модели данных (к примеру ERWin). Преимущества графических представлений с помощью ER-моделей наглядность, возможность проектирования баз данных с огромным охватом объектов и атрибутов.
Основные элементы ER-моделей:
- Объекты (сущности);
- Атрибуты объектов;
- Связи между объектами.
Рассмотрим основные понятия. Под связью понимается функциональная зависимость между сущностями, каждая из которых в свою очередь обладают атрибутами или характеристиками. Сущность - это то множество индивидуальных различных объектов (концепция, идея, человек, место и т. д.) информацию о которых необходимо хранить.
Линия связывающая два индивидуальных объекта (две сущности) или замкнутая на себе показывает графическую связь. В зависимости от количества экземпляров для сущности, вход в прямоугольник сущности может быть либо трехточечным при условии использования нескольких экземпляров сущности, либо одноточечным так как в связи участвует только один экземпляр сущности.
Прерывистая линия обозначает необязательный конец связи, в свою очередь обязательный конец изображается сплошной линией.
В данной курсовой работе модель имеет тип связи один ко многим.
Существует два уровня моделирования и представления системы. Они делятся на логические и физические. На рисунке 9 изображена диаграмма IDEF1X логического уровня процесса складского учета предприятия.
Физический уровень в свою очередь подразделяется на:
- СУБД;
- Тип и имя объекта;
- Индекс.
На рисунке 10 изображена диаграмма физического уровня IDEF1X процесса складского учета предприятия.
Рисунок 9 – Сущности логического уровня
Рисунок 10 – Сущности физического уровня
2.3 Схемы и описание программных модулей
Структура базы данных Access состоит из:
- Таблиц;
- Запросов;
- Форм;
- Отчетов;
- Модулей;
- Макросов;
- Страниц.
В таблицах вводятся данные, а формы соответственно работают с данными из таблицы. Формы позволяют вносить данные в таблицы, редактировать и удалять данные и ограничить доступ к информации посредством отображения только для просмотра.
Запросы в свою очередь позволяют извлекать и фильтровать информацию в соответствии с заданными критериями, производить расчеты Для вывода необходимых данных на экран, а так же печати используются отчеты.
Страницы позволяют соединятся с интернетом.
Макросы позволяют выполнять однотипные операции с данными БД.
Access так же позволяет писать программы (модули) на языке Basic.
2.4 Характеристика базы данных
На основе созданной информационной модели складского учета создаются таблицы в Access. Каждой сущности модели создается отдельная таблица, а ключевые поля соответственно приравниваются к первичным ключам.
На рисунке 11 и 12 показана структура таблицы «продукция» и пример самой таблицы соответственно.
Рисунок 11 – Структура таблицы «Продукция»
Рисунок 12 – Таблица «Продукция»
Последующие таблицы создаются аналогично. Созданные таблицы описаны в Приложении А.
Схема данных используется в виде графического образа базы данных. Всевозможные объекты БД Access используют схему для определения связей между таблицами. Следовательно при создании формы с данными из разных взаимосвязанных таблиц, схема данных позволит автоматически согласовать допуск к полям данных таблиц, при этом обеспечивая целостную структуру при корректировки таблиц.
В базе данных складского учета предприятия ООО «Партнер» используется такой тип связи как один ко многим. Тип связи один ко многим подразумевает что, каждой записи одной таблицы могут соответствовать несколько записей другой, при этом записи в другой таблице может содержать лишь одну запись в одной.
База данных складского учета реализована в виде восьми взаимосвязанных таблиц. На рисунке 13 изображена схема данных складского учета предприятия
Рис. 13. “Схема данных”
2.5 Разработка запросов
Запросы позволяют выполнить разные виды обработки данных.
Ниже представлена реализация запросов в системе складского учета предприятия ООО «Партнер».
На рисунке 14 показано окно создания запросов.
Рисунок 14 – Параметрический запрос в режиме конструктора
Так как запрос параметрический, то при выполнении выводится форма задачи параметров. Данная форма представлена на рисунках 15 и 16. Далее результаты выводятся в виде таблицы. Вывод результатов показан на рисунке 17.
Рисунок 15 – Параметр «ввод поставщика»
Рисунок 16 – Параметр «наименование продукции»
Рисунок 17 – Результаты запроса
Далее на рисунке 18 представлен запрос на создание таблицы. Таблица создается автоматически на основе данных из других таблиц.
Рисунок 18 – Запрос на создание таблицы
Результат выполнения запроса представлен в Приложении А.
2.6 Разработка форм и отчетов складского учета предприятия
Данные можно вносить несколькими способами, как напрямую в таблицу, так и с помощью форм. Формы дают возможность выполнения заданий, которые в режиме таблицы недоступны. Используя форму можно вычислять значения и выводить на экран результаты. Входными данными для форму являются записи таблицы или запроса.
На рисунке 19 изображена форма «Приход».
Аналогичным образом были созданы и другие формы. Все имеющиеся формы изображены в Приложении А. Формы в основном используются для удобства ввода данных.
Для вывода итоговой информации используются отчеты. Отчет позволяет вывести результаты расчетов, изобразить диаграммы, графики и т.д.
На рисунках 20, 21 показаны конструктор отчетов и пример отчета соответственно. Все имеющиеся отчеты изображены в Приложении А.
Рисунок 19 – Форма «Приход»
Рисунок 20 – Конструктор отчетов
Рисунок 21 – Отчет «Ведомость прихода»
2.7 Контрольный пример реализации проекта
Для разработки программной части системы складского учета предприятия ООО «Партнер» был использован Microsoft Access и встроенные в него модули на языке Basic.
Основная экранная форма представлена на рисунке 22.