Файл: «Моделирование предметной области «Учет товаров» с помощью UML».pdf

ВУЗ: Не указан

Категория: Курсовая работа

Дисциплина: Не указана

Добавлен: 25.04.2023

Просмотров: 133

Скачиваний: 5

ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.

ВВЕДЕНИЕ

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

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

Актуальность темы работы обусловлена следующими обстоятельствами:

      1. Автоматизация складских операций – путь к сокращению потерь предприятия за счет высвобождения персонала.
      2. Автоматизация складских операций – путь к увеличению прибыли за счет повышения оперативности решения всех важных вопросов, связанных с поставкой и отгрузкой товаров.
      3. Автоматизация складских операций повышает эффективность системы управления предприятием в целом, поскольку автоматизированная складская система, как правило, охватывает не только складской комплекс, но и смежные подразделения.

Целью работы является Моделирование предметной области «Учет товаров» с помощью UML

Объектом исследования является компания ООО «КАСцентр».

Предметом исследования работы является складской логистический процесс компании ООО «КАСцентр».

Задачи работы:

  1. Провести анализ существующего логистического процесса компании ООО «КАСцентр».
  2. Определить круг задач, подлежащих автоматизации.
  3. Выбрать среду для разработки и обосновать выбор.
  4. Построить новую модель логистического процесса.
  5. Составить описание алгоритмов работы системы.

1 ПРЕДПРОЕКТНОЕ ОБСЛЕДОВАНИЕ ООО «КАСЦЕНТР»

1.1. Моделирование бизнес-процессов

В данном параграфе построим функциональную модель системы в нотации IDEF0.

Одним из основных понятий стандарта IDEF0 является декомпозиция (Decomposition). Принцип декомпозиции применяется при разбиении сложного процесса на составляющие его функции. При этом уровень детализации процесса определяется непосредственно разработчиком модели. Декомпозиция позволяет постепенно и структурированно представлять модель системы в виде иерархической структуры отдельных диаграмм.


Модель IDEF0 всегда начинается с представления системы как единого целого - одного функционального блока с интерфейсными дугами,

уходящими за пределы рассматриваемой области. Такая диаграмма с одним функциональным блоком называется контекстной диаграммой.

В процессе декомпозиции функциональный блок, который в контекстной диаграмме отображает систему как единое целое, подвергается детализации на другой диаграмме. Получившаяся диаграмма второго уровня содержит функциональные блоки, отображающие главные подфункции функционального блока контекстной диаграммы, и называется дочерней (ChildDiagram) по отношению к нему, а каждый из функциональных блоков, принадлежащих дочерней диаграмме, соответственно называется дочерним блоком (ChildBox). В свою очередь, функциональный блок-предок называется родительским блоком по отношению к дочерней диаграмме (ParentBox), а диаграмма, к которой он принадлежит, - родительской диаграммой (ParentDiagram). Каждая из подфункций дочерней диаграммы может быть далее детализирована путём аналогичной декомпозиции соответствующего ей функционального блока. В случае декомпозиции функционального блока все интерфейсные дуги, входящие в данный блок или исходящие из него, фиксируются на дочерней диаграмме.

Каждый блок имеет свой уникальный порядковый номер на диаграмме (цифра в правом нижнем углу прямоугольника), а обозначение под правым углом указывает на номер дочерней для этого блока диаграммы. Отсутствие этого обозначения говорит о том, что декомпозиции для данного блока не существует.

Для каждого из элементов IDEF0 (диаграмм, функциональных блоков, интерфейсных дуг) существующий стандарт подразумевает создание и поддержание набора соответствующих определений, ключевых слов, повествовательных изложений и т.д., которые характеризуют объект, отображённый данным элементом. Этот набор называется глоссарием (Glossary) и является описанием сущности данного элемента.

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

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


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

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

Обычно IDEF0-модели несут в себе сложную и концентрированную информацию. Поэтому, чтобы ограничить их перегруженность и сделать удобочитаемыми, в стандарте приняты соответствующие ограничения сложности:

  • ограничение количества функциональных блоков на каждом уровне декомпозиции тремя–шестью (верхний предел (шесть) заставляетразработчика использовать иерархии при описании сложных предметов, а нижний предел (три) гарантирует, что на соответствующей диаграмме достаточно деталей, чтобы оправдать её создание);
  • ограничение количества подходящих к одному функциональному блоку (выходящих из одного функционального блока) интерфейсных дуг четырьмя.

Нотация IDEF0 крайне проста. Она содержит только две сущности - блоки и стрелки.

Функциональные блоки (ActivityBox) задают действия. Функциональный блок графически изображается в виде прямоугольника. Он задаёт некоторую конкретную функцию в рамках рассматриваемой системы. По требованиям стандарта название каждого функционального блока должно быть сформулировано в глагольном наклонении (например, «проверить документацию», а не «проверка документации»).

Для выполнения действия могут потребоваться входные данные (сырьё, информация и т.д.). В результате мы получаем что-либо на выходе.

Потоки информации обозначаются интерфейсными дугами (называемые также потоками или стрелками) (Arrow). Интерфейсная дуга отображает элемент системы, который обрабатывается функциональным блоком или оказывает иное влияние на функцию, отображённую данным функциональным блоком (рисунок 1).

Графическим отображением интерфейсной дуги является однонаправленная стрелка. Каждая интерфейсная дуга должна иметь своё уникальное наименование (ArrowLabel). По требованию стандарта, наименование должно быть оборотом существительного. Началом и концом каждой функциональной дуги могут быть только функциональные блоки, при этом источником может быть только выходная сторона блока, а приёмником - любая из трёх оставшихся. Каждый функциональный блокдолжен иметь, по крайней мере, одну управляющую интерфейсную дугу и одну исходящую.


Типизацию категорий информации можно описать аббревиатурой

ICOM:

I (Input), вход - то, что потребляется в ходе выполнения процесса;

C (Control), управление - ограничения и инструкции, влияющие на выполнение процесса;

O (Output), выход - то, что является результатом выполнения процесса;

M (Mechanism), исполняющий механизм - то, что используется для выполнения процесса, но остаётся неизменным.

Рисунок 1 - Функциональный блок и интерфейсные дуги

Модель существующего логистического процесса компании ООО

«КАСцентр» в нотации IDEF0 представлена на рисунках 2-5.

Модель будет представлена с точки зрения инженер - программиста, целью модели является автоматизация складской деятельности.

Рисунок 2 - Модель верхнего уровня логистического процесса ООО «КАСцентр»

Из диаграммы рисунка 2 видно, что организацией управляет иностранное руководство и естественно соблюдается законодательство РФ. Внутри организации происходит управление организацией и направление её деятельностью. Входными данными в организацию являются: заказы клиентов, весовое оборудование и грузовые паллеты и люди пришедшие на работу. Выходными данными являются: Информация об оборудование, информация для иностранного руководства и весовое оборудование для клиентов. Естественно имеются и другие входные, выходные данные, но диаграмма ограничена точкой зрения и целью модели. Рассмотрим более детализировано бизнес-модель организации, для этого представлена декомпозиция контекстной диаграммы (рисунок 3).

Рисунок 3 - Модель логистического процесса ООО «КАСцентр».

Первый уровень декомпозиции

На этой диаграмме изображено пять функциональных блоков, рассмотрим их подробнее:

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

«Приемка, хранение и отгрузка оборудования» - этот блок отвечает за хранение доставленного оборудование, отгрузку оборудования клиентам и составление отчетов о хранящемся оборудовании.

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


«Гарантийный ремонт весового оборудования» - функции этого блока: поддержка гарантийного оборудования в рабочем состояние, консультация клиентов по ремонту оборудование и ремонт постгарантийного оборудования.

«Подготовка и формирование отчетности» - этот блок отражает процесс подготовки регламентированной отчетности и отчетности для руководства.

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

В данном проекте будем автоматизировать функциональный блок

«Приемка, хранение и отгрузка оборудования». Диаграмма декомпозиции этого блока приведена на рисунках 4 и 5.

Рисунок 4 - Модель логистического процесса ООО «КАСцентр». Декомпозиция блока

«Приемка, хранение и отгрузка оборудования»

Рисунок 5 - Модель логистического процесса ООО «КАСцентр». Декомпозиция блока

«Принимать и хранить оборудование»

Из диаграммы видно, что вся работа склада сводится к получению оборудованию и расположению его на складе, сбору заказов по документу пришедшему из офиса, и подготовке документов для клиента.

Иногда при сборе заказа операторы склада ошибаются и вместо одного оборудования отгружают другое. Целью автоматизации является проверка правильности сбора заказа. Это возможно так как на документе пришедшем из офиса в штриховом коде закодирована вся информация о заказе, а на каждых весах есть специальный штриховой код, который идентифицирует модель оборудования. Таким образом, если оператор после сбора заказа, или при сборе заказа, будет сканировать штриховой код оборудования, то по окончанию сбора заказа программное обеспечение сможет определить правильность сбора заказа и информировать об этом оператора. Также в штриховом коде оборудования закодирован серийный номер оборудования, эта информация будет использована для составления базы данных отгрузок. В базе данных будет храниться, какое оборудование, какому клиенту и когда было отгружено. База данных поможет вести дополнительный учет на предприятие, которого сейчас очень не хватает. Также после завершения сбора заказа нужно автоматизировать печать гарантийных талонов. Сейчас оператор берет бланк и вносит ручкой модель, серийный номер оборудования и информацию о клиенте для кого это оборудование предназначено. Необходимо автоматизировать этот процесс.