Файл: Проектирование реализации операций бизнес-процесса (Аналитический раздел).pdf

• Регистрация в системе;
• Аутентификация в системе;
• Отображение, ввод и коррекция информации о товарах, имеющихся на складе;
• Отображение, ввод и коррекция информации о поставщиках;
• Ввод и коррекцию информации о запросах;
• Обработка запросов и ведение финансового журнала исполнения запросов;
• Предоставление статистики.

Исходные данные:

• Список продукции;
• Цены на продукцию;
• Информация о поставщике;
• Информация о запросе.

Результаты:

• Финансовый отчёт руководителю;
• Список продукции;
• Цены (стоимость) на продукцию;
• Информация о поставщике;
• Электронные и напечатанные экземпляры запросов.

Требования к надёжности.

• Контроль вводимой (входной) информации.
• Блокировку ошибочных действий пользователя при работе с системой.
• Гарантировать целостность хранимой информации.
• Обеспечить защиту от несанкционированного доступа к информации в системе.

2.2. Разработка модели As-Is основного бизнес-процесса выбранного подразделения предприятия

Для проектирования АИС управления складом ООО «Электропульт-Система» применяется программное средство BPwin 4.1. BPwin представляется мощным инструментом для формирования моделей, позволяющих подвергать анализу, документировать и составлять план изменения сложных бизнес-процессов. BPwin предлагает средство для сбора всей нужной информации о работе компании и графического изображения данной информации в варианте целостной и непротиворечивой модели.

BPwin поддерживает 3 методологии: IDEF0, DFD и IDEF3, позволяющие анализировать бизнес с 3 основополагающих точек зрения:

С точки зрения функциональности системы. В рамках методологии IDEF0 (Integration Definitionfor Function Modeling) бизнес-процесс представляется в виде комплекта элементов-работ, что взаимодействуют между собой, а кроме того показывается информационные, людские и производственные ресурсы, потребляемые каждой работой.

С точки зрения потоков данных (документооборота) в системе. Диаграммы DFD (Data Flow Diagramming) могут расширить то, что уже отображено в модели IDEF3, потому как они описывают потоки данных.

Позволяя отследить, каким способом совершается обмен информацией между бизнес-функциями внутри системы. В тоже время диаграммы DFD оставляют без внимания связь между бизнес-функциями.

С точки зрения очередности выполняемых работ. И еще более точную картину можно получить, дополнив модель диаграммами IDEF3. Данный способ привлекает внимание к последовательности выполнения событий. В IDEF3 интегрированы компоненты логики, что дает возможность моделировать и подвергать анализу альтернативные сценарии развития бизнес-процесса.

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

Из контекстной диаграммы видно что, управляющая информация поступает в блок сверху (Нормы и требования), при этом входная информация (Списки товаров продукции, Цена на продукцию, Сведения о поставщике, Информация о запросе), которая подвергается обработке, отображена с левой стороны блока, а итоги (выход) изображены с правой стороны блока (Финансовый отчёт руководителю, Списки продукции, Цена на товары (продукцию), Информация о поставщике). Механизм (Работники склада, Работники), который выполняет операцию, представляется дугой, входящий в блок снизу.

Рисунок 3 – Контекстная диаграмма

Далее блок АИС управления складом ООО «Электропульт-Система» разделяется на три процесса, которые изображены на диаграмме декомпозиции процесса:

• Оформление заявки на поставку продукции;
• Формирование запроса;
• Оформление поставку продукции (поставщику)

Рисунок 4 – Диаграмма декомпозиции

2.3. Разработка модели потоков данных между участниками выбранного подразделения предприятия

По сути DFD близка к IDEF, так как также использует принцип иерархии и декомпиляции, но в отличие от IDEF является основным средством моделирования функциональных требований проектируемой системы. Целью создания такой диаграммы является демонстрация того, как каждый процесс преобразует свои входные данные в выходные, а также выявить отношения между этими процессами. Эта диаграмма изображает систему в состоянии «как будет».

Рисунок 5 – DFD0 диаграмма

Рисунок 6 – DFD диаграмма 1 уровня

2.4. Обоснование выбора СУБД

Для реализации проектирования базы данных (БД) выбор пал на систему управления базой данных - Microsoft SQL Server.

MS SQL Server система управления базами данных, в данном случае реляционными, создателем данной СУБД является компания Microsoft. Базовый применяемый язык для запросов это Transact-SQL (T-SQL), язык как и собственно СУБД создан Microsoft совместно с Sybase. Transact-SQL есть реализация такого стандарта как ANSI/ISO специально под структурированный язык запросов (SQL) с расширениями. Такие системы активно используется при оперировании, как с большими базами данных (БД), так и с персональными.

По сравнению со всеми другими наиболее известными СУБД MS SQL Server располагает рядом преимуществ. SQL это мощный и отличный инструмент, он позволяет программам, пользователям и вычислительным системам получить доступ к информации, хранящейся в реляционных и прочих базах данных.

Ключевые плюсы языка Structured Query Language (SQL) состоят в следующем:

• возможность переноса с одной вычислительной системы (рабочей станции) на другую. СУБД может быть направлена на разнообразные вычислительные системы, при всем этом приложения, разработанные с помощью Structured Query Language (SQL), допускают применение, как для локальных баз данных (БД), так и для масштабных многопользовательских систем;
• реляционная основа языка - Structured Query Language (SQL) - язык реляционных баз данных (РБД), вследствие чего он стал популярным вместе с тем, как широкое распространение получила реляционная модель представления (отображения) данных. Табличная структура данного типа баз проста в понимании, а потому и язык Structured Query Language (SQL) прост в изучении;
• возможность создания (использование) интерактивных запросов - Structured Query Language (SQL) дает возможность пользователям (клиентам) мгновенный доступ к данным, при этой возможности в интерактивном режиме, имеется возможность получить результат (итог) запроса за кротчайшее время без необходимости написания (разработки) сложной программы;
• обеспечение разнообразного представления данных - при помощи Structured Query Language (SQL) можно представить таковую структуру данных, что каждый пользователь (клиент) будет видеть разные их представления. Кроме этого, данные из разных частей базы данных (БД), могут быть представлены и скомбинированы в виде одной (единой) простой таблицы, что означает, представления применимы для повышения защиты базы данных (БД) и ее настройки под определенные требования отдельных пользователей (клиентов);
• возможность динамического изменения (модифицирования) и расширения структуры баз данных (БД) - язык Structured Query Language дает возможность манипулировать структурой базы данных (БД), обеспечивая, тем самым гибкость с точки зрения (позиции) приспособленности базы данных (БД) к трансформирующимся условиям предметной области;
• поддержка архитектуры клиент-сервер - Structured Query Language - представляется одним из наилучших средств (решений) для реализации (разработки) приложений (ПО) на платформе клиент-сервер. Structured Query Language выступает объединяющим звеном между взаимодействующей (работающий) с пользователем (клиентом) клиентской (пользовательской) системой и серверной системой, которая управляет базой данных (БД), разрешая каждой из них сконцентрироваться на исполнении своих функций.

Язык Structured Query Language - первый и сейчас один-единственный стандартный язык запросов для работы (обработки) с базами данных (БД), получивший достаточно значительное распространение.

2.5. База данных автоматизированной информационной системы управления складом ООО «Электропульт-Система»

Модель позволяет структурировать и добавлять новые данные. Именно на этапе моделирования возникает больше всего ошибок и сложностей, поэтому этот этап является самым ответственным при разработке информационной системы управления складом ООО «Электропульт-Система». Порой ошибки, допущенные на этом этапе, можно обнаружить только после непосредственного составления документов (отчетов), получив неожиданный результат.

Процесс моделирования можно представить в виде следующих этапов:

1. Выбор источника данных, на основе которого будет создаваться модель

2. Выбор таблиц, которые должны войти в модель

3. Создание и редактирование связей на основе имеющейся структуры Источника данных.

4. Добавление и редактирование данных в модель. Чаще всего этот этап связан с написанием SQL-запросов

Важно понимать, что каждый отчет может содержать данные только из одного пакета.

Логическая структура БД (рисунок 7), физическая (рисунок 8). Основные таблицы: Поставщики, Приходный ордер, Материально ответственные лица, Карточка складского учёта, Товарно-транспортная накладная, Справочник продукции, Запрос.

Рисунок 7 – Логическая структура БД

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

• Поставщики,
• Приходный ордер,
• Материально ответственные лица,
• Карточка складского учёта,
• Товарно-транспортная накладная,
• Справочник продукции,
• Запрос.

1) Для сущности «Поставщики» можно выделить следующие атрибуты:

• id_post Код поставщика
• name_org Наименование организации
• ur_adres Юридический адрес
• tel Телефон
• raschet_schet Расчетный счет

2) Для сущности «Приходный ордер» можно выделить следующие атрибуты:

• N_ordera Номер ордера
• Date_order Дата
• id_post Код поставщика
• id_material_otvetstv_lica Код материально ответственные лица
• id_producta Код продукта
• kolvo_o Количество
• sum_o Сумма

3) Для сущности «Материально ответственные лица» можно выделить следующие атрибуты:

• id_material_otvetstv_lica Код материально ответственные лица
• fio_mol Ф.И.О.

4) Для сущности «Карточка складского учёта» можно выделить следующие атрибуты:

• id_producta Код продукта
• Date_k Дата
• N_ordera Номер ордера
• N_zaprosa Номер запроса
• kolvo_prix Количество прихода
• kolvo_ras Количество расхода
• ost Остаток

5) Для сущности «Товарно-транспортная накладная» можно выделить следующие атрибуты:

• id_nakl Номер накладной
• N_zaprosa Номер запроса
• id_material_otvetstv_lica Код материально ответственные лица
• id_producta Код продукта
• Date_nakl Дата
• kolvo_t Количество
• sum_t Сумма

6) Для сущности «Справочник продукции» можно выделить следующие атрибуты:

• id_producta Код продукта
• name_pdt Наименование
• ed_izm Единица измерения
• Cena_ed Цена за единицу

7) Для сущности «Запрос» можно выделить следующие атрибуты:

• id_producta Код продукта
• N_zaprosa Номер запроса
• Date_zp Дата запроса
• Date_pl Дата получения
• kolvo_z Количество

Рисунок 8 – Физическая структура БД

1) Для сущности «Поставщики» можно выделить следующие атрибуты:

• id_post type: bigint, (Primary key), Identity
• name_org type: nchar(100) (Required)
• ur_adres type: nchar(100) (Required)
• tel type: nchar(30) (Required)
• raschet_schet type: int (Required)

2) Для сущности «Приходный ордер» можно выделить следующие атрибуты:

• N_ordera type: bigint, (Primary key), Identity
• Date_order type: date (Required)
• id_post type: bigint (Foreign key)
• id_material_otvetstv_lica type: bigint (Foreign key)
• id_producta type: bigint (Foreign key)
• kolvo_o type: int (Required)
• sum_o type: int (Required)

3) Для сущности «Материально ответственные лица» можно выделить следующие атрибуты:

• id_material_otvetstv_lica type: bigint, (Primary key),
• fio_mol type: nchar(50) (Required)

4) Для сущности «Карточка складского учёта» можно выделить следующие атрибуты:

• id_producta type: bigint (Foreign key)
• Date_k type: date (Required)
• N_ordera type: bigint, (Primary key),
• N_zaprosa type: bigint (Foreign key)
• kolvo_prix type: int (Required)
• kolvo_ras type: int (Required)
• ost type: int (Required)

5) Для сущности «Товарно-транспортная накладная» можно выделить следующие атрибуты:

• id_nakl type: bigint, (Primary key),
• N_zaprosa type: bigint (Foreign key)
• id_material_otvetstv_lica type: bigint (Foreign key)
• id_producta type: bigint (Foreign key)
• Date_nakl type: date (Required)
• kolvo_t type: int (Required)
• sum_t type: int (Required)

6) Для сущности «Справочник продукции» можно выделить следующие атрибуты:

• id_producta type: bigint, (Primary key),
• name_pdt type: nchar(50) (Required)
• ed_izm type: nchar(30) (Required)
• Cena_ed type: int (Required)