Файл: Складской учет (Выбор комплекса задач автоматизации).pdf
Добавлен: 23.05.2023
Просмотров: 116
Скачиваний: 2
СОДЕРЖАНИЕ
1.1 Выбор комплекса задач автоматизации
1.2 Характеристика существующих бизнес-процессов
1.3 Характеристика документооборота, возникающего при решении задачи
1.4 Обоснование проектных решений
2.1 Информационная модель и её описание
2.2 Характеристика нормативно-справочной, входной и оперативной информации
2.4 Характеристика базы данных
2.5 Контрольный пример реализации проекта и его описание
Связь типа один-к-одному означает, что один экземпляр первой сущности (левой) связан с одним экземпляром второй сущности (правой).
Связь типа один-ко-многим означает, что один экземпляр первой сущности (левой) связан с несколькими экземплярами второй сущности (правой).
Связь типа много-ко-многим означает, что каждый экземпляр первой сущности может быть связан с несколькими экземплярами второй сущности, и каждый экземпляр второй сущности может быть связан с несколькими экземплярами первой сущности.
В нашей курсовой работе ER-модель имеет связь типа один-ко-многим.
В ERwin существуют два уровня представления и моделирования - логический и физический. Логический уровень означает прямое отображение фактов из реальной жизни. Например, люди, столы, отделы, компьютеры являются реальными объектами. Они именуются на естественном языке, с любыми разделителями слов (пробелы, запятые и т.д.). На логическом уровне не рассматривается использование конкретной СУБД, не определяются типы данных (например, целое или вещественное число) и не определяются индексы для таблиц.
2.2 Характеристика нормативно-справочной, входной и оперативной информации
На этапе проектирования информационной системы формируется модель данных. Проектировщики в качестве исходной информации получают результаты анализа. Конечным продуктом этапа проектирования являются:
- схема базы данных (на основании ER-модели, разработанной на этапе анализа);
- набор спецификаций модулей системы (они строятся на базе моделей функций).
Моделирование бизнес-процессов
BPwin поддерживает три методологии: IDEF0, DFD и IDEF3, позволяющие анализировать деятельность предприятия с трех ключевых точек зрения:
- С точки зрения функциональности системы. В рамках методологии IDEF0 бизнес-процесс представляется в виде набора элементов-работ, которые взаимодействуют между собой, а также показывается информационные, людские и производственные ресурсы, потребляемые каждой работой.
- С точки зрения потоков информации (документооборота) в системе. Диаграммы DFD могут дополнить то, что уже отражено в модели IDEF3, поскольку они описывают потоки данных, позволяя проследить, каким образом происходит обмен информацией между бизнес-функциями внутри системы. В тоже время диаграммы DFD оставляют без внимания взаимодействие между бизнес-функциями.
- С точки зрения последовательности выполняемых работ. Более точную картину можно получить, дополнив модель диаграммами IDEF3. Этот метод привлекает внимание к очередности выполнения событий. В IDEF3 включены элементы логики, что позволяет моделировать и анализировать альтернативные сценарии развития бизнес-процесса.
2.2.1 Нотация IDEF0
Нотация IDEF0 (Integration Definition for Function Modeling) была разработана на основе методологии структурного анализа и проектирования SADT, утверждена в качестве стандарта США и успешно эксплуатируется во многих проектах, связанных с описанием деятельности предприятий.
IDEF0 может быть использована для моделирования широкого класса систем.
Для новых систем применение IDEF0 имеет своей целью определение требований и указание функций для последующей разработки системы, отвечающей поставленным требованиям и реализующей выделенные функции.
Для существующих систем IDEF0 может быть использована для анализа функций, выполняемых системой и отображения механизмов, посредством которых эти функции выполняются.
Результатом применения IDEF0 к некоторой системе является модель этой системы, состоящая из иерархически упорядоченного набора диаграмм, текста документации и словарей, связанных друг с другом с помощью перекрестных ссылок.
Контекстная диаграмма — это модель, представляющая систему как набор иерархических действий, в которой каждое действие преобразует некоторый объект или набор объектов. Высшее действие иерархии называется действием контекста — это самый высокий уровень, который непосредственно описывает систему. Уровни ниже называются порожденными декомпозициями и представляют подпроцессы родительского действия.
При создании модели сначала необходимо изобразить самый высокий уровень — действие контекста. Наименование действия описывает систему непосредственно и, как правило, состоит из одного активного глагола в сочетании с обобщающим существительным, которое разъясняет цель деятельности с точки зрения самого общего взгляда на систему.
Каждый блок может иметь различные типы связанных с ним стрелок. Стрелки обозначают людей, место, вещи, понятия или события. Стрелки связывают границы диаграммы с блоками, а также действия (блоки) на диаграмме между собой. В диаграммах IDEF0 имеется четыре основных типа стрелок.
Вход блока представляет материал или информацию, которая должна быть использована или преобразована блоком, чтобы произвести продукцию (выпуск). Стрелки входа всегда направляются в левую сторону блока. Стрелки входа необязательны, так как не все действия могут преобразовать или изменять (заменять) что-либо.
Каждый блок должен иметь по крайней мере одну стрелку контроля (управления). Управление всегда входит в вершину блока. Управление, как правило, представляется в виде правил, инструкций, политики компании, процедур или стандартов. Оно влияет на деятельность без фактического преобразования чего-либо. Управление может также использоваться для описания процедуры начала или окончания выполнения действия.
Стрелки выхода (выпуска) — это материал или информация, произведенная блоком. Каждый блок должен иметь по крайней мере одну стрелку выхода (выпуска). Процессы, которые не производят продукции (выпуска), лучше не моделировать вообще.
Механизмы исполнения — это те ресурсы, которые обеспечивают выполнение действия. В качестве механизма исполнения могут быть рассмотрены персонал компании, машины или оборудование, которые обеспечивают выполнение деятельности. Стрелка механизма может отсутствовать, если определено, что это не важно для работы блока.
Для проанализированной предметной области построим контекстную диаграмму при помощи BPWin 4.0.
Рис.1. Контекстная диаграмма
Декомпозиционное разложение модели используется в моделировании бизнес-процессов, для того чтобы дать более подробное описание блоков. Каждое из этих действий может в свою очередь быть декомпозировано. При каждой декомпозиции блока создается новая диаграмма. Число декомпозиций не ограничено и полностью зависит от уровня сложности, который необходимо показать в модели.
Декомпозируем контекстную диаграмму на 3 функциональных блока (Рис.2):
- Приемка товара на склад;
- Хранение и переучет продукции;
- Отгрузка продукции.
Рис. 2. Диаграмма IDEF0
2.2.2 Нотация DFD
Для того чтобы документировать механизмы передачи и обработки информации в моделируемой системе, используются диаграммы потоков данных (Data Flow Diagrams). Диаграммы DFD обычно строятся для наглядного изображения текущей работы системы документооборота организации. Чаще всего диаграммы DFD используют в качестве дополнения модели бизнес-процессов, выполненной в IDEF0.
Диаграммы потоков данных используются для описания документооборота и обработки информации. Подобно IDEF0, DFD представляет моделируемую систему как сеть связанных между собой работ. Их можно использовать как дополнение к модели IDEF0 для более наглядного отображения текущих операций документооборота в корпоративных системах обработки информации. Главная цель DFD - показать, как каждая работа преобразует свои входные данные в выходные, а также выявить отношения между этими работами.
Любая DFD-диаграмма может содержать работы, внешние сущности, стрелки (потоки данных) и хранилища данных.
Далее моделировать систему будем, используя диаграммы потоков данных (DFD).
Декомпозируем функциональный блок «Приемка товара на склад» еще на четыре действия (Рис.3):
- Проверка товарно-транспортной накладной;
- Проверка поставленной продукции;
- Занесение данных о продукции в БД;
- Передача продукции на хранение.
Рис.3. Диаграмма DFD «Приемка товара на склад»
Далее декомпозируем функциональный блок «Хранение и переучет продукции» на два действия (Рис.4):
- Размещение товара на складе;
- Анализ наличия необходимого количества на складе (на этом этапе лицу, принимающему решение, передается оперативная информация).
Рис.4. Диаграмма DFD «Хранение и переучет продукции»
Декомпозируем функциональный блок «Отгрузка» на три действия (Рис.5):
- Проверка наличия товара на складе;
- Занесение информации об отгружаемой продукции в БД;
- Отгрузка продукции по требованию.
Рис.5. Диаграмма DFD «Отгрузка»
2.2.3 Нотация IDEF3
Нотация IDEF3 была разработана с целью более удобного описания рабочих процессов (workflow), для которых важно отразить логическую последовательность выполнения процедур.
Наличие в диаграммах DFD элементов для описания источников, приемников и хранилищ данных позволяет точно описать процесс документооборота. Однако для описания логики взаимодействия информационных потоков модель дополняют диаграммами еще одной методологии – IDEF3, также называемой workflow diagramming. Методология моделирования IDEF3 позволяет графически описать и задокументировать процессы, фокусируя внимание на течении этих процессов и на отношениях процессов и важных объектов, являющихся частями этих процессов.
IDEF3 предполагает построение двух типов моделей: модель может отражать некоторые процессы в их логической последовательности, позволяя увидеть, как функционирует организация, или же модель может показывать “сеть переходных состояний объекта”, предлагая вниманию аналитика последовательность состояний, в которых может оказаться объект при прохождении через определенный процесс.
Декомпозируем функциональный блок «Проверка товарно-транспортной накладной» который, в свою очередь, является элементом декомпозиции блока «Приемка товара на склад» на четыре действия:
- Принятие товарно-транспортной накладной;
- Проверка поставщика;
- Проверка реквизитов документа;
- Проверка количества продукции.
Рис.6. Диаграмма IDEF3 проверки товарно-транспортной накладной.
Декомпозируем функциональный блок «Проверка поставленной продукции» который, в свою очередь, является элементом декомпозиции блока «Приемка товара на склад» на три действия:
- Проверка продукции на годность;
- Принять продукцию;
- Вернуть поставщику.
Рис.7. Диаграмма IDEF3 проверки поставленной продукции
2.3 Общие положения
Основными структурными единицами базы данных Access являются таблицы, запросы, формы, отчеты, страницы, макросы и модули.
Таблицы – это объекты, в которые вводятся данные.
Формы – это объекты предназначенные для работы с индивидуальными данными из таблиц баз данных. С помощью форм можно вводить информацию в таблицы, редактировать и удалять ее, а также ограничить доступ к данным и отображать их только в режиме просмотра.
Запросы – это объекты, позволяющие производить расчеты, извлекать нужные данные по определенным критериям, фильтровать данные входящие в БД.
Отчеты – это объекты позволяющие выводить результатные данные на экран и печать в нужном виде.
Страницы – это объекты, позволяющие связываться с Internet или Intranet.
Макросы – это макрокоманды БД, позволяющие просто и быстро выполнять однотипные операции с данными базы.
Модули – это специальные программы, написанные в Access на языке Visual Basic для обработки данных базы, если средств, заложенных в Access для их обработки не хватает или пользоваться ими менее удобно.
2.4 Характеристика базы данных
Все таблицы создаются на основе информационной модели, причем каждой сущности будет соответствовать отдельная таблица. Ключевые поля будут соответствовать первичным ключам сущностей.
Рис. 8. Струкрура полей таблицы “Продукция”
Рис. 9. Пример таблицы “ Продукция ”
Аналогично создаются и остальные таблицы (см. Приложения).
Схема данных является графическим образом БД. Она используется различными объектами Access для определения связей между несколькими таблицами. Например, при создании формы, содержащей данные из нескольких взаимосвязанных таблиц, схема данных обеспечивает автоматический согласованный доступ к полям этих таблиц. Она же обеспечивает целостность взаимосвязанных данных при корректировке таблиц.