Другое на тему Модели UML Use Case– область использования, правила построения, основные элементы.

Содержание:

Введение.......................................................................................................... 3

1. Особенности модели UML Use Case............................................................ 4

1.1. Специфика построения.......................................................................... 4

1.2. Область применения.............................................................................. 9

2. Разработка модели UML Use Case для предприятия
общественного питания 11

2.1. Характеристика организации............................................................... 11

2.2. Модель UML Use Case в работе
ресторана.......................................... 16

Список использованной литературы.............................................................. 22

Введение:

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

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

Объект исследования: модель UML
Use Case

Предмет исследования: инжиниринг
бизнес-процессов

Цель исследования: изучить
особенности модели UML Use Case, ее структуру и область применения

Основные задачи:

- охарактеризовать специфику
специфика построения UML Use Case;

- рассмотреть область применения
модели UML Use Case;

- охарактеризовать деятельность
организации;

- разработать модель; UML Use
Case для предприятия общественного питания;

Заключение:

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

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

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

Фрагмент текста работы:

1. Особенности модели UML
Use Case

1.1. Специфика
построения Большинство современных методов
объектно-ориентированного анализа и проектирования (ООАП), включая языковую
модель и описание модели процесса. Язык шаблонов — это нотация (в основном
графическая), которая используется методом для описания проекта.

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

Процесс — это описание шагов,
которые необходимо выполнить при разработке проекта.

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

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

- основные строительные блоки
языка;

- правила их комбинирования;

- какой-то общий механизм для
всего языка.

Словарь процесса включает в себя
три типа строительных блоков:

- сущность;

- отношение;

- таблица ранжирования.

Единицы измерения являются
абстрактными, которые являются основными элементами модели. Различные отношения
связывают подразделение; диаграмма групповых интересов персонала.

Сущность — это
объектно-ориентированные блоки языка. Вы можете использовать их, чтобы создать
правильный шаблон.

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

Класс — это описание набора
объектов с общими атрибутами, операциями, отношениями и семантикой. Классы
реализуют один или несколько интерфейсов. Графически класс показан в виде
прямоугольника, который обычно имеет свое имя, атрибуты и операции[1].

Интерфейс — это набор действий,
идентифицирующих услуги (сервис), предоставляемые классом или разделом. Таким
образом, интерфейс описывает внешнее видимое поведение элементов. Представитель
может представлять поведение класса или секции в целом или в части, определяемой
им, только спецификациями операций (сигнатурами), но никогда их реальностью. На
графике интерфейс представлен в виде круга с написанным под ним названием, как
показано на чертеже. Интерфейс редко существует сам по себе - он часто связан с
классом или компонентом, который его реализует[2].

Сотрудничество определяет
взаимодействие, это совокупность ролей и других элементов, которые, работая
вместе, создают социальный эффект, который не сводится к простой сумме
терминов. Сотрудничество, таким образом, имеет как структурный, так и
поведенческий аспекты. Один и тот же класс может участвовать в нескольких
кооперациях, поэтому они составляют модель поведения модели системы. Графика,
коллаборация представлена в виде эллипса, окруженного пунктирной линией,
которая часто содержит только название[3].

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

А этот компонент является
заменяющей частью системы, соответствует набору интерфейсов и обеспечивает его
реализацию. Вы можете найти множество различных типов компонентов,
установленных в системе, таких как COM или Java Beans, а также компоненты,
являющиеся артефактами процесса разработки, такие как файлы исходного кода.
Компонент обычно представляет собой физическую упаковку логических элементов,
таких как классы, интерфейсы и совместная работа. Графическая композиция,
представленная в виде карточного Прямоугольника, обычно содержит только
название. Компонент подобен классу: он описывает набор объектов с общими
атрибутами, операциями, отношениями и семантикой[5].

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

Поведенческие вещи являются
динамическими компонентами модели процесса. Это слово языка: они описывают
поведение модели во времени и пространстве. Существует только два основных типа
организационного поведения.[6]

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

Элемент — это алгоритм
поведения, который определяет последовательность состояний, через которые
объект или взаимодействие проходит в течение своего жизненного цикла в ответ на
различные события, а также реакцию на эти события. Можно использовать элементы
для описания поведения класса или взаимодействия классов. Некоторые другие
элементы связаны с человеческой машиной: состояния, переход (из одного
состояния в другое), события (единицы, которые начинают движение) и тип
действия (ответ с передачей). Графически представлено в виде прямоугольника со
скругленными углами, имеет название, а может, и название страны[8]. [1]
Шуваев А.В. Моделирование бизнес-процессов на региональном рынке// Управление
бизнес-процессами в условиях формирования цифровой экономики. Сборник научных
статей по материалам Всероссийской научно-практической конференции. Московский
финансово-юридический университет Санкт-Петербургский государственный
экономический университет, Донской государственный технический университет,
Кубанский государственный университет, Кубанский государственный
технологический университет, Ставропольский государственный педагогический институт,
Северо-Кавказский федеральный университет, Ставропольский государственный
аграрный университет. 2019. С. 464 [2] [3]
Гаджиева М.М. Моделирование бизнес-процессов предприятия// Научный альманах.
2019. № 4-1 (54). С. 19 [4]
Маданбекова А. Нотации моделирования бизнес-процессов// Аллея науки. 2018. Т.
4. № 11 (27). С. 529 [5]
Тихомирова М.Л. Моделирование бизнес-процессов средствами проектирования UML//
Устойчивое развитие науки и образования. 2018. № 5. С. 86 [6]
Караченкова К.В. Проблемы методологии моделирования бизнес-процессов в
современных организациях// Перспективы социально-экономического развития в XXI
столетии: инновационные, финансовые, информационные и правовые аспекты. Сборник
научных трудов Международной научно-практической конференции. Под редакцией
В.Н. Немцева, А.Г. Васильевой. 2019. С. 229 [7]
Михеев Г.М. Моделирование бизнес-процессов мониторинга средствами
проектирования UML// Устойчивое развитие науки и образования. 2018. № 5. С. 208 [8]
Дадаева Б.Ш. Особенности моделирования бизнес-процессов на предприятии// Азимут
научных исследований: экономика и управление. 2019. Т. 8. № 2 (27). С. 233