Файл: Моделирование предметной области «Управление снабжением» с помощью UML.pdf
Добавлен: 06.04.2023
Просмотров: 115
Скачиваний: 1
- условия или возможности, необходимые пользователю для решения проблем или достижения целей;
- условия или возможности, которыми должна обладать система или системные компоненты.
К системе в общем случае предъявляется множество требований. Методология RUP (Rational Unified Process) [25] предлагает разделить требования на две основные группы: функциональные и нефункциональные. При этом методология ссылается на [11], где предлагается дополнительная классификация требований по схеме FURPS:
- Functional - функциональные требования;
- Usability - требования к удобству использования;
- Reliability - требования к надежности;
- Performance - требования к производительности;
- Supportability - требования к сопровождению.
На рисунке 4 приведена модель функциональных требований в виде соответствующей диаграммы (эта и последующие диаграммы требований и UML–диаграммы, а также информационные модели построены с помощью CASE–системы Visual Paradigm 13).
Рисунок 4. Модель функциональных требований к АИС «УКИ»
Модель требований к удобству использования АИС «УКИ» приведена на рисунке 5. В основу этих требований были положены фундаментальные принципы Нильсена–Молиха, обеспечивающие построения эффективного интерфейса:
Рисунок 5. Модель требований к удобству использования АИС «УКИ»
На рисунке 6 представлена модель требований к надежности АИС «УКИ».
Рисунок 6. Модель требований к надежности АИС «УКИ»
Модель требований к удобству сопровождения АИС «УКИ» приведена на рисунке 7.
Рисунок 7. Модель требований к сопровождению АИС «УКИ»
1.2. Предлагаемые мероприятия по улучшению бизнес-процессов
Новая схема ведения описанных бизнес–процессов не изменяется в количественном составе (то есть все основные подпроцессы и задачи остаются теми же), но меняется в качественном – применяется новый механизм или способ обработки данных и обмена информацией – новая АИС «УКИ» (рисунок 8). На диаграмме на рисунке 8 отражена новая стрелка механизма, роль которого выполняет АИС «УКИ».
Рисунок 8. Контекстная диаграмма IDEF0производства изделий
На рисунке 8 приведена модифицированная диаграмма декомпозиции, на которой также указана роль АИС «УКИ» при выполнении основных работ рассмотренного процесса. Из диаграммы на рисунке 8 видно, что АИС «УКИ» будет являться дополнительным средством, с помощью которого планируется управлять учетом и закупкой комплектующих и регистрировать в справочнике новые изделия (в соответствии с их компонентным составом).
Рисунок 9. IDEF0–диаграмма декомпозиции процессов производства изделий
В рамках процесса управления закупкой комплектующих формирование заказов на комплектующие автоматизируется с помощью АИС «УКИ». При этом процесс получения списка компонентов для изготовления заказа будет также автоматизирован. На рисунке 10 приведена соответствующая диаграмма в нотации BPMN.
Рисунок 10. BPMN–схема процесса составления списка компонентов
Из диаграммы видно, что добавление комплектующих в заказ будет выполняться как поодиночке (по одному типу из номенклатурного справочника), так и комплексно по конкретному виду изделия. При этом система автоматически проведет декомпозицию выбранного изделия на комплектующие, добавив их в запрос в необходимом количестве.
2 глава. Проектная часть
2.1. Выбор средства для моделирования предметной области решаемой задачи
Одним из способов формального описания функциональных требований является диаграмма вариантов использования для более удобной передачи информации между моделью системы и моделью разрабатываемого программного обеспечения [3]. Диаграмма вариантов использования позволяет наглядно описать пользовательские требования к АИС, идентифицировать пользователей АИС и соотнести с ними функции системы. Для детализации диаграмма вариантов использования может дополняться набором диаграмм из нотации UML - деятельности, сценариев, и т.д. [15].
Само понятие варианта использования предполагает описание действий, которые производит АИС в ответ на действия, инициируемые пользователями. Пользователи на диаграммах вариантов использования являются основными действующими лицами системы, одновременно выполняющими функции источника и приемника информации.
Диаграмма вариантов использования является одной из первых, которые разрабатываются при комплексном проектировании программного обеспечения в UML, поскольку именно эта диаграмма является основой, определяющей функциональность продукта, круг его пользователей и функций, которые они будут выполнять с помощью разработанной системы.
Диаграмма вариантов использования АИС «УКИ» выполнена в соответствии с разработанной моделью функциональных требований и приведена на рисунке 11. На диаграмме показаны основные пользовательские роли (администратор АИС, сотрудник склада, сборщик), которые будут выполнять соответствующие функции, описанные в модели функциональных требований.
Рисунок 11. Диаграмма вариантов использования АИС «УКИ»
Помимо диаграмм вариантов использования логическая модель системы в UML может быть описана рядом других диаграмм как статических, так и динамических моделей.
2.2. Моделирование предметной области решаемой задачи с использованием объектно-ориентированного подхода к проектированию
В соответствии с выполненным анализом и разработанными моделями требований и вариантов использования можно составить концептуальную модель классов. Основными концептуальными классами предметной области АИС «УКИ» являются:
- компонент (комплектующие) - компоненты, из которых составляются конечные изделия в цехе сборки, поставляемые заказчикам;
- категория - категория функционального назначения или классификации комплектующих по какому-либо признаку;
- производитель - производитель комплектующих;
- изделие - единица продукции, состоящая из комплектующих;
- операция - транзакция, которая относится к учету изменения количества комплектующих на складе и может включать в себя несколько позиций различных комплектующих;
- запрос - вид операции, характеризующий поступление набора комплектующих на склад;
- выдача - вид операции, характеризующий расход комплектующих, то есть их выдачу в цех сборки для изготовления изделий.
В таблице 1 приведен перечень атрибутов концептуальных классов с их кратким описанием.
Таблица 1
Идентифицированные атрибуты концептуальных классов
Класс |
Атрибут |
Описание |
Деталь (Компонент) |
Наименование |
Наименование комплектующего |
Характеристики |
Описание технических и (или) любых других характеристик и параметров |
|
Кол-во на складе |
Количество комплектующих данного вида, находящихся в данный момент на складе |
|
Категория |
Наименование |
Наименование категории комплектующего, соотнесенное с его классом |
Производитель |
Наименование |
Наименование производителя |
Описание |
Краткое описание производителя |
|
Изделие |
Наименование |
Наименование типового изделия |
Описание |
Краткое описание изделия |
|
Операция |
Описание |
Краткое описание операции |
Дата Время |
Дата и время регистрации операции в системе |
|
Ответственный |
Данные ответственного лица, совершившего регистрацию операции |
|
Тип |
Тип операции - запрос, выдача |
|
Запрос, Выдача |
Наследуются |
Подклассы класса «операции», которые будут отличаться функциональным назначением и реализацией операций |
Выявленные концептуальные классы, их атрибуты и взаимосвязи составляют в совокупности диаграмму концептуальных классов, которая представлена на рисунке 12.
Рисунок 12. Диаграмма концептуальных классов АИС «УКИ»
Для идентификации связей концептуальных классов необходимо понимание взаимосвязей сущностей предметной области (эти принципы также могут использоваться при построении информационной модели):
1. С каждым комплектующим обязательно должна быть ассоциирована категория и производитель. И категория, и производитель, в свою очередь, могут иметь экземпляры, которым не соответствует ни один экземпляр комплектующего.
2. Комплектующие составляют конечные варианты изделий, причем изделие не может быть составлено менее, чем из одного комплектующего.
- Операции учета изменения количества комплектующих на складе могут быть двух видов: операции поступления на склад (запросы) и операции расхода со склада в сборочный цех (выдачи).
- Каждая операция может включать в себя как несколько отдельных комплектующих, так и несколько изделий, а также их комбинации (впоследствии будет проведена декомпозиция изделия на составляющие комплектующие).
Таким образом, были идентифицированы основные концептуальные классы рассматриваемой предметной области, выявлены их основные атрибуты и взаимосвязи.
Диаграммы деятельности (или активности) в нотации UML 2.0 [26] относятся к классу динамических моделей и предназначены для описания формальной последовательности действий и поведения системы при выполнении пользователем определенных действий. В рамках диаграмм деятельности могут быть описаны как общий алгоритм работы с системой, так и частные алгоритмы, соответствующие выполнению конкретных пользовательских или системных задач.
На рисунке 13 приведена диаграмма деятельности, характеризующая общую модель поведения при функционировании АИС «УКИ».
Рисунок 13. Общий алгоритм работы АИС «УКИ»
Диаграмма на рисунке 13 показывает общую последовательность операций, которые типично выполняются при поступлении нового заказа на изготовление изделий. При этом формируется задание на сборку заказанных изделий, по которому определяется комплект требуемых компонентов (комплектующих). Определенный комплект в виде списка передается на склад для выдачи комплектующих на сборку. Если все необходимые комплектующие в нужном количестве имеются на складе, то на них сразу оформляется накладная выдачи в сборочный цех. Если же комплектующих для сборки и выполнения заказа не хватает на складе, то сотрудник склада составляет соответствующий запрос на закупку необходимого количества комплектующих у поставщиков.
На рисунке 14 приведена диаграмма деятельности, которая иллюстрирует процесс оформления запроса на закупку комплектующих у поставщиков с помощью АИС «УКИ».
Рисунок 14. Действия при создании запроса на закупку комплектующих
Из диаграммы, приведенной на рисунке 14, видно, что операция оформления запроса на закупку комплектующих является итерационным процессом - на каждой итерации для закупки добавляется очередное комплектующее или изделие. При этом АИС «УКИ» сама определит компонентный состав добавленных в закупку изделий, осуществит их декомпозицию и добавит их в закупку в необходимом количестве.
Операции, выполняемые при оформлении выдачи комплектующих в сборочный цех, аналогичны и также соответствуют диаграмме деятельности, приведенной на рисунке 14.
Поскольку АИС «УКИ» будет оперировать справочными данными (комплектующие, производители и т.д.), то необходимо организовать процессы ведения справочников. Ведение справочника комплектующих (деталей), их категорий и производителей представляет собой типовой набор операций по учету данных, позволяющий выполнять операции создания, редактирования и удаления данных. При этом все изменения сохраняются в соответствующих таблицах базы данных. Типовой алгоритм ведения справочников в АИС «УКИ» приведен на рисунке 15.