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

3. Требования к программе или программному изделию.

Требования к функциональным параметрам.

Система должна предоставлять возможность выполнения следующих функций:

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

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

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

Результаты:

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

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

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

Требования к составу и параметрам технических средств.

Система должна работать на IBM совместимых компьютерах.

Минимальная конфигурация:

Тип процессора……............................Pentium II или Athlon и выше;

Частота процессора …………………..333Mhz и выше;

Объём оперативного запоминающего устройства…64 Мб и более;

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

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

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

С точки зрения (стороны) функциональности системы. В рамках 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)