Igor20264
225 lines
11 KiB
Markdown
225 lines
11 KiB
Markdown
# *СОДЕРЖАНИЕ
|
|
|
|
[TOC]
|
|
|
|
# Практическая работа №1. Описание предметной области и границ системы
|
|
|
|
## Цель работы
|
|
|
|
Описать предметную область складского учёта, выделить участников процесса и зафиксировать границы автоматизируемой системы.
|
|
|
|
## Ход работы
|
|
|
|
Рассматривается склад готовой продукции среднего предприятия: три зоны комплектации, один участок приёмки, две смены по четыре кладовщика. Через склад проходит около 400 отгрузок в сутки, приёмка занимает от 20 до 90 минут на партию.
|
|
|
|
Участники процесса и их задачи приведены в @Таблица:pr1_roles.
|
|
|
|
%pr1_roles Участники процесса складского учёта
|
|
|
|
| Участник | Задача | Что получает на выходе |
|
|
|----------|--------|------------------------|
|
|
| Кладовщик приёмки | сверяет поступившую партию с накладной | акт приёмки |
|
|
| Комплектовщик | собирает заказ по заданию | укомплектованный заказ |
|
|
| Кладовщик отгрузки | оформляет передачу заказа перевозчику | подписанная накладная |
|
|
| Начальник склада | контролирует остатки и сроки | сводка по остаткам |
|
|
|
|
Границы системы и её внешнее окружение показаны на @Рисунок:pr1_ctx.
|
|
|
|
%pr1_ctx Контекстная диаграмма потоков данных
|
|
|
|
```dfd
|
|
style context
|
|
|
|
entity Supplier Поставщик
|
|
entity Carrier Перевозчик
|
|
entity Sales Отдел продаж
|
|
process System Система складского учёта
|
|
|
|
Supplier --> System товарная накладная
|
|
Sales --> System заказ на отгрузку
|
|
System --> Carrier накладная на отгрузку
|
|
System --> Sales сведения об остатках
|
|
```
|
|
|
|
Границы приняты по участку от приёмки партии до передачи заказа перевозчику. Бухгалтерский учёт и закупки остаются за пределами системы: они ведутся в учётной системе предприятия и получают из системы только сводки.
|
|
|
|
## Выводы
|
|
|
|
Основным ограничением процесса является ручной ввод накладных при приёмке: он даёт до 6 % расхождений в учёте остатков и удлиняет приёмку партии в среднем на 25 минут. Именно этот участок определяет требования к системе.
|
|
|
|
# Практическая работа №2. Модель бизнес-процессов склада
|
|
|
|
## Цель работы
|
|
|
|
Построить функциональную модель процесса складского учёта в нотации IDEF0 и определить состав функций верхнего уровня.
|
|
|
|
## Ход работы
|
|
|
|
Контекстная диаграмма процесса приведена на @Рисунок:pr2_a0.
|
|
|
|
%pr2_a0 Контекстная диаграмма A-0
|
|
|
|
```idef0
|
|
title Обеспечить движение товара на складе
|
|
node A-0
|
|
number 1
|
|
project Система складского учёта
|
|
context TOP
|
|
|
|
[A0] Обеспечить движение товара на складе
|
|
<- Товарная накладная
|
|
<- Заказ на отгрузку
|
|
^ Регламент складских операций
|
|
-> Подписанная накладная на отгрузку
|
|
-> Сводка по остаткам
|
|
v Персонал склада
|
|
```
|
|
|
|
Декомпозиция функции верхнего уровня выделила три функции, приведённые на @Рисунок:pr2_a0d.
|
|
|
|
%pr2_a0d Декомпозиция A0
|
|
|
|
```idef0
|
|
title Обеспечить движение товара на складе
|
|
node A0
|
|
number 2
|
|
project Система складского учёта
|
|
context A-0
|
|
purpose Сократить расхождения учёта при приёмке и отгрузке
|
|
viewpoint Начальник склада
|
|
|
|
[A1] Принять партию
|
|
[A2] Разместить и хранить
|
|
[A3] Скомплектовать и отгрузить
|
|
|
|
A1 <- Товарная накладная [I1]
|
|
A3 <- Заказ на отгрузку [I2]
|
|
A1, A2, A3 ^ Регламент складских операций [C1]
|
|
A2 ^ Схема зонирования склада [C2]
|
|
A1 -> A2 : принятая партия
|
|
A2 -> A3 : товар к комплектации
|
|
A3 -> Подписанная накладная на отгрузку [O1]
|
|
A2 -> Сводка по остаткам [O2]
|
|
A1, A2, A3 v Персонал склада [M1]
|
|
A2 v Складское оборудование [M2]
|
|
```
|
|
|
|
Схема зонирования вынесена в управление, а не во вход: она задаёт правила размещения и не расходуется в процессе.
|
|
|
|
## Выводы
|
|
|
|
Функция размещения оказалась единственной, которая одновременно получает управление от схемы зонирования и формирует сводку по остаткам. Расхождения учёта возникают именно на переходе от приёмки к размещению, когда партия физически принята, но ещё не отражена в остатках.
|
|
|
|
# Практическая работа №3. Модель данных системы
|
|
|
|
## Цель работы
|
|
|
|
Спроектировать логическую модель данных системы складского учёта и обосновать состав сущностей.
|
|
|
|
## Ход работы
|
|
|
|
Модель данных приведена на @Рисунок:pr3_erd.
|
|
|
|
%pr3_erd Логическая модель данных системы
|
|
|
|
```uml
|
|
@startuml
|
|
hide circle
|
|
skinparam linetype ortho
|
|
|
|
entity "Партия" as batch {
|
|
* id : bigint <<PK>>
|
|
--
|
|
* supplier : varchar(255)
|
|
* accepted_at : timestamp
|
|
* invoice_no : varchar(32)
|
|
}
|
|
|
|
entity "Товарная позиция" as item {
|
|
* id : bigint <<PK>>
|
|
--
|
|
* batch_id : bigint <<FK>>
|
|
* sku : varchar(32)
|
|
* qty : numeric(12,3)
|
|
zone : varchar(16)
|
|
}
|
|
|
|
entity "Заказ на отгрузку" as order_ {
|
|
* id : bigint <<PK>>
|
|
--
|
|
* created_at : timestamp
|
|
* status : varchar(16)
|
|
}
|
|
|
|
entity "Строка заказа" as line {
|
|
* id : bigint <<PK>>
|
|
--
|
|
* order_id : bigint <<FK>>
|
|
* sku : varchar(32)
|
|
* qty : numeric(12,3)
|
|
}
|
|
|
|
batch ||--o{ item
|
|
order_ ||--o{ line
|
|
@enduml
|
|
```
|
|
|
|
Остаток по артикулу не хранится отдельным полем, а вычисляется как разность принятого и отгруженного количества. Такое решение исключает расхождение между остатком и первичными документами, но требует индекса по артикулу для приемлемой скорости выборки.
|
|
|
|
Соответствие сущностей модели функциям процесса приведено в @Таблица:pr3_map.
|
|
|
|
%pr3_map Соответствие сущностей функциям процесса
|
|
|
|
| Функция | Сущности | Что изменяется |
|
|
|---------|----------|----------------|
|
|
| Принять партию | Партия, Товарная позиция | добавляются позиции с нулевой зоной |
|
|
| Разместить и хранить | Товарная позиция | заполняется зона размещения |
|
|
| Скомплектовать и отгрузить | Заказ на отгрузку, Строка заказа | создаются строки и уменьшается доступное количество |
|
|
|
|
## Выводы
|
|
|
|
Модель обходится четырьмя сущностями за счёт вычисляемого остатка. Слабое место решения — скорость расчёта остатка при росте числа позиций: при объёме свыше миллиона строк потребуется материализованное представление.
|
|
|
|
# Практическая работа №4. Расчёт нагрузки на систему
|
|
|
|
## Цель работы
|
|
|
|
Оценить пиковую нагрузку на систему складского учёта и объём хранилища на три года эксплуатации.
|
|
|
|
## Ход работы
|
|
|
|
Пиковая интенсивность запросов оценивается по числу операций в смену с учётом коэффициента неравномерности.
|
|
|
|
%pr4_eq_load
|
|
$$
|
|
\lambda_{\max} = \frac{Q \cdot m}{T} \cdot k
|
|
$$
|
|
|
|
где $Q$ — число отгрузок в смену; $m$ — среднее число запросов на одну отгрузку; $T$ — длительность смены в секундах; $k$ — коэффициент неравномерности нагрузки.
|
|
|
|
Расчёт по (@Формула:pr4_eq_load) при 200 отгрузках в смену, 14 запросах на отгрузку, смене 12 часов и коэффициенте 2,5 даёт пиковую интенсивность около 0,16 запроса в секунду.
|
|
|
|
Реализация расчёта приведена в @Листинг:pr4_code.
|
|
|
|
%pr4_code Расчёт пиковой интенсивности запросов
|
|
|
|
```python
|
|
def peak_rate(shipments: int, requests_per_shipment: int,
|
|
shift_seconds: int, unevenness: float) -> float:
|
|
return shipments * requests_per_shipment / shift_seconds * unevenness
|
|
```
|
|
|
|
Результаты расчёта для трёх сценариев роста приведены в @Таблица:pr4_load.
|
|
|
|
%pr4_load Оценка нагрузки для сценариев роста
|
|
|
|
| Сценарий | Отгрузок в смену | Пиковая интенсивность, запр./с | Объём за три года, ГБ |
|
|
|----------|------------------|-------------------------------|-----------------------|
|
|
| Текущий | 200 | 0,16 | 1,4 |
|
|
| Рост на 50 % | 300 | 0,24 | 2,1 |
|
|
| Двукратный рост | 400 | 0,32 | 2,8 |
|
|
|
|
## Выводы
|
|
|
|
Даже при двукратном росте отгрузок пиковая интенсивность остаётся ниже одного запроса в секунду, поэтому одного экземпляра сервиса достаточно. Ограничивающим фактором становится не нагрузка, а расчёт остатков по накопленным первичным документам.
|