Преподаватель который помогает студентам и школьникам в учёбе.

Моделирование предметной области «Формирование производственных заказов» с помощью UML

Содержание:

Введение

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

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

Темой данной работы является «Моделирование предметной области «Формирование производственных заказов» с помощью UML».

Объектом работы является процесс формирования производственных заказов.

Предметом является язык UML и связанные с ним средства моделирования.

Целью работы является объектное моделирование процесса формирования производственных заказов.

Для достижения поставленной цели необходимо решить следующие задачи:

Дать общее описание предметной области и постановку задачи;
Предложить мероприятия по улучшению процесса;
Выбрать нотацию и средства моделирования;
Провести моделирование предметной области в выбранной нотации.

1. Аналитическая часть

1.1. Описание предметной области. Постановка задачи

Производственный заказ определяет, какой материал должен быть обработан, в каком месте, в какое время и какое количество материалов или деталей требуется. Он также определяет, какие компоненты и последовательность операций должны использоваться и как должны быть сопоставлены затраты по заказу.

Запланированные заказы являются результатом выполнения ресурсного планирования. Нехватка материалов, настроенных на внутреннюю закупку, приведет к созданию запланированных заказов, которые можно преобразовать в производственные заказы. Производственные заказы являются "печатными копиями", они больше не могут быть скорректированы путем запуска системы ресурсного планирования.

Спецификации и маршрутные данные материалов копируются в производственный заказ, который определяет список компонентов и эксплуатационные данные в заказе.

Запланированные затраты также обновляются в производственном заказе через цену компонента и цену маршрутной операции.

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

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

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

Можно автоматически выполнить обратную подачу (потребление) компонентов во время подтверждения заказа в соответствии со спецификацией.

Также можно разнести получение товара из материала автоматически во время подтверждения заказа.

После подтверждения заказа все затраты, такие как стоимость компонентов и стоимость работ, будут дебетованы в заказе, и после разноски поступления товаров затраты будут зачислены в заказ.

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

1.2. Предлагаемые мероприятия по улучшению технологии решения задачи

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

Ниже приведены подзадачи планирования требований к материалам:

Планирование требований
Управление запасами
Разделение требований

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

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

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

Такая идентификация является обязательной в производстве, ориентированном на заказчика.

2. Проектная часть

2.1. Выбор средства для моделирования предметной области решаемой задачи

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

Основные способы моделирования на настоящий момент:

IDEF – метод функционального моделирования;
UML – унифицированный язык моделирования;
BPMN - нотация моделирования бизнес-процессов.

Проведем более подробное описание семейства основных методов и нотаций моделирования.

В течение многих лет проводились мероприятия, направленные на стандартизацию методов описания процессов и методов получения информации, необходимой для построения моделей. В 1970-х годах Министерство обороны США разработало стандарт моделирования процессов IDEF0. Он использовался в качестве инструмента для создания компьютерных программ, поддерживающих производственные процессы, а позже он был принят в качестве инструмента, позволяющего составлять модели процессов в сервисных и производственных компаниях.

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

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

Стандарт IDEF0 подробно и точно описывает способ размещения блоков, стрелок и их описания. Каждый процесс, стрелка и модель описываются идентификатором, назначенным в соответствии со стандартом. Согласно стандарту IDEF0 – основная модель помечена символом A-0, и в ней есть один основной процесс A0. Он может быть описан моделью A0, и процессы в нем будут помечены A1, A2, A3 и т. Д. Подчиненная модель, описывающая процесс A1, также будет помечена A1, и процессы в ней расположены последовательно – символы A11, A12, A13, и т.д. Этот структурированный способ описания позволяет быстрее создавать список отдельных моделей и процессов. Связь между родительской и вышестоящей моделями также может быть показана графически с помощью дерева иерархии функций. Стандарт IDEF0 ограничивает число функций, которые можно разместить в подчиненной модели.

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

Разработка и дополнение стандарта IDEF0 привели к появлению других стандартов IDEF. Стандарт IDEF1 позволяет построить модель, отображающую структуру информационных потоков в системе. Стандарт IDEF2 указывает, как построить динамическую модель, показывающую временные зависимости между функциями. Стандарт IDEF1 дополнен стандартом IDEF1X, который используется для проектирования реляционных баз данных.

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

Язык UML фактически был изобретен как язык, который помогает визуализировать, определять, конструировать и документировать функции программного обеспечения. Создатели языка посчитали возможным расширить язык таким образом, чтобы он применялся ко многим другим областям. Эта функция позволила UML стать языком для традиционного бизнес-моделирования, а также для системного анализа и проектирования.

UML успешно применяется для моделирования различных систем, то есть:

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

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

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

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

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

Хорошо построенная визуальная бизнес-модель, использующая UML, ответит на все основные вопросы:

Кто ваши внутренние и внешние клиенты? (кто выиграет от этой бизнес-системы).
Как разрабатываемая система может повысить ценность вашего бизнеса?
Какие события в/или вне организации инициируются каким-либо бизнес-процессом?
Какие конечные продукты производятся бизнес-процессами?
Какие внутренние элементы связаны с бизнес-процессами?
Какая организационная структура поддерживает бизнес?
Какие роли и обязанности в рамках этих организационных структур должны быть частью системы?

UML - объектно-ориентированный язык. Объектно-ориентированные модели более конкретны, лучше описаны и, как правило, более гибкие и интуитивно понятные. Это является одной из основных причин, по которой мы будем использовать этот язык в работе.

В качестве конкретной среды разработки будет использовано CASE-средство Rational Rose.

Rational Rose – это CASE-система для визуального моделирования объектно-ориентированных программных продуктов, а также для генерации кодов на различных языках и выпуска проектной документации.

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

Семейство продуктов IBM Rational Rose предназначено для разработки приложений на основе Unified Modeling Language (UML). Архитекторы, аналитики, проектировщики программного обеспечения и баз данных и разработчики систем могут использовать это семейство продуктов для создания визуальных моделей архитектуры программного обеспечения, баз данных, требований приложения и многоразовых ресурсов, а также определения связи на уровне руководства.

2.2 Моделирование предметной области решаемой задачи с использованием объектно-ориентированного подхода к проектированию

Проведем моделирование предметной области с использованием объектно-ориентированного подхода.

Рисунок 2.1. Диаграмма вариантов использования

Согласно диаграмме вариантов, актер «Сотрудник производственного отдела» выполняет следующие кейсы:

Формирование заказа;
Определение и указание сроков заказа;
Определение потребностей в материалах и работах;
Внесение материалов в заказ;
Внесение работ в заказ.

Актер «Сотрудник отдела контроля» выполняет следующие кейсы:

Проверка доступности материалов и работ.

Актер «Сотрудник предприятия» выполняет следующие кейсы:

Выполнение заказа.

Остальные диаграммы в целом повторяет описанную выше, но в них описаны соответственно последовательность, состояния работ, и процессы деятельности.

Рисунок 2.2. Диаграмма последовательности

Рисунок 2.3. Диаграмма состояний

Рисунок 2.4. Диаграмма состояний

Рисунок 2.5. Диаграмма классов

Диаграмма классов требует отдельного пояснения. Согласно диаграмме – существует класс «Заказ», который включает номер заказ, код заказа, сроки начала и окончания выполнения.

Также существуют классы «Материалы» и «Работы», описывающие соответствующие сущности.

Для связи между заказами, работами и материалами – созданы классы «Материалы в заказах» и «Работы в заказах».

Заключение

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

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

Список литературы

Арчибальд Р.Д. Управление высокотехнологичными программами и проектами / Р.Д. Арчибальд. – М.: ДМК Пресс, 2009.- 463 с
Балдин К.В. Информационные системы в экономике / К.В. Балдин. – М.: Издательско-торговая корпорация «Дашков и К», 2004. – 134 с.
Барановская Т.П., Лойко В.В., Семенов М.И., Трубилин А.И. Информационные системы и технологии в экономике: Учебник / Т.П. Барановская, В.В. Лойко, М.И. Семенов, А.И. Трубилин. – М.: Финансы и статистика, 2003 – 416 с.
Баронов В.В., Калянов Г.Н., Попов Ю.И., Рыбников А.И., Титовский И.Н. Автоматизация управления предприятием / В.В. Баронов, Г.Н. Калянов и др. – М.: ИНФРА-М, 2000, -239с.
Гайдамакин Н.А. Автоматизированные информационные системы, базы и банки данных. Вводный курс: Учебное пособие / Н.А. Гайдамакин. – М.: Гелиос АРВ, 2002. – 368 с., ил.
Желен М. Информационные технологии в бизнесе / М. Желен. – СПб.: Питер, 2009. – 725 с.
Кондратьев В.В., Кузнецов М.Н. Показываем бизнес-процессы / В.В. Кондратьев, М.Н. Кузнецов. – М.: Эксмо,2007.- С.73
Маклаков С.В.. Создание информационных систем с ALLFusion Modelling Suite / С.В. Маклаков. – М.: ДМК-Пресс, 2003. – 315 с.
Менеджмент процессов / под ред. Беккера Й., Вилкова Л., Таратухина В. (перев. с нем.). – М.: Эксмо, 2008. – 217c.
Пастущак Т.Н., Буянова Л.Н. Информационные системы в экономике / Т.Н. Пастущак, Л.Н. Буянова. – СПб.: СПГУВК, 2005. – 75 с.
Репин В. В., Елиферов В. Г. Процессный подход к управлению. Моделирование бизнес-процессов / В.В. Репин, В.Г. Елиферов. – М.: Манн, Иванов и Фербер, 2012. – 511 с.
Самуйлов К.Е Серебренникова Н.В. Основы формальных методов описания бизнес-процессов / К.Е. Самуйлов, Н.В. Серебренникова. – М.: Фолио, 2014. – 511 с.
Титоренко Г.А. Информационные системы в экономике. Учебник для ВУЗов / Г.А. Титоренко. – М.: Юнити-ДАНА, 2008. – 463 с.
Чаадаев В.К. Бизнес-процессы в компаниях связи / В.К. Чаадаев. – М.: Эко-Трендс, 2004. – 432 с.