Từ mô hình hóa quy trình đến thiết kế hệ thống tự động (Phần 2)

“Một ngày trong cuộc đời của một con sóc” hay từ mô hình hóa quy trình đến thiết kế hệ thống kế toán tài sản tự động “Belka-1.0” (Phần 2)

Từ mô hình hóa quy trình đến thiết kế hệ thống tự động (Phần 2)
Использована иллюстрация к «Сказке о царе Салтане» А.С.Пушкина, изд.»Детская литература», Москва, 1949 год, Ленинград, рисунки К.Кузнецова

Tóm tắt tập trước

В phần 1 мы использовали «сказочную» предметную область, вдохновленные примерами изучения диаграмм UML с опорой на сюжеты сказок (см., например, đây [1]). До начала моделирования мы договорились относительно использования некоторых элементов диаграммы Activity и начали формировать соглашение по моделированию. С учетом этих договоренностей мы на 1-ом этапе описали процесс в виде диаграмм Activity, а на 2-ом этапе выделили шаги процесса, для которых требуется (и возможна) автоматизация.

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

...
Một hòn đảo nằm trên biển, (E1, E2)
Có mưa đá trên đảo (E3, E1)
Với những nhà thờ mái vòm dát vàng (E4)
Với tháp và vườn; (E5, E6)
Một cây vân sam mọc trước dinh, (E7, E8)
Và bên dưới là một ngôi nhà pha lê; (E9)
Một con sóc thuần hóa sống ở đó, (A1)
Vâng, thật là một cuộc phiêu lưu! (A1)
Con sóc hát những bài hát, (P1, A1)
Vâng, anh ấy cứ gặm hạt, (P2)
Nhưng quả hạch không hề đơn giản, (C1)
Tất cả vỏ đều bằng vàng, (C2)
Lõi là ngọc lục bảo nguyên chất; (C3)
Người hầu canh sóc, (P3, A2)
Họ phục vụ cô như nhiều người hầu khác nhau (P4)
Và một thư ký đã được phân công (A3)
Một tài khoản nghiêm ngặt về các loại hạt là tin tức; (P5, C1)
Quân đội chào cô; (P6, A4)
Một đồng xu được đổ ra từ vỏ sò, (P7, C2, C4)
Hãy để họ đi khắp thế giới; (P8)
Cô gái đổ ngọc lục bảo (P9, A5, C3)
Vào nhà kho và có mái che; (E10, E11)
...
(А.С.Пушкина «Сказка о царе Салтане, о сыне его славном и могучем богатыре князе Гвидоне Салтановиче и о прекрасной царевне Лебеди», как считается, вольная обработка народной сказки «По колена ноги в золоте, по локоть руки в серебре», которая, была записана Пушкиным в различных вариантах)

Trong ví dụ này, tôi đang sử dụng môi trường Enterprise Architect của một công ty Úc. Hệ thống Sparx [2], а в рамках учебных занятий применяю người mẫu [3.
Напомню, что процессы бывают разные, ознакомится можно, например, đây [4] và đây [5.
Подробнее о применяемых подходах к моделированию и проектированию см. [6, 7].
Để có đặc tả UML đầy đủ, xem đây [8.

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

Giai đoạn 3. Bước tự động hóa phải gắn với một chức năng hoặc các chức năng của hệ thống

Разрабатываемая автоматизированная система (АС) предназначена для ведения строгого учета орехов, помните? Для каждого выделенного шага (см. Рисунок 3, Рисунок 4 в 1-ой части), который будем автоматизировать, запишем функциональное требование, применяя примерно такую конструкцию «В системе должна быть реализована возможность …» и разработаем диаграмму Use-case. Сейчас мы фактически дополняем наше соглашение по моделированию новыми правилами. Поясню какие элементы будем использовать.
Từ mô hình hóa quy trình đến thiết kế hệ thống tự động (Phần 2)

Между «Ролью пользователя» и «Функцией» будем использовать связь «Ассоциация» (Рисунок 5), это означает, что для пользователя с данной ролью доступно выполнение данной функции.

Từ mô hình hóa quy trình đến thiết kế hệ thống tự động (Phần 2)
Рисунок 5. Использование связи типа «Ассоциация»

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

Từ mô hình hóa quy trình đến thiết kế hệ thống tự động (Phần 2)
Рисунок 6. Использование связи типа «Реализация»

Если одна функция требует для своего выполнения, чтобы была выполнена еще какая-то функция, причем обязательно, будем использовать связь «Зависимость» со стереотипом «Include» — включение (Рисунок 7). Если же выполнение дополнительной функции требуется при определенных условиях, то будем использовать связь «Зависимость» со стереотипом «Extend» — расширение. Все очень легко запомнить: «Include» — ВСЕГДА, а «Extend» – ИНОГДА.

Từ mô hình hóa quy trình đến thiết kế hệ thống tự động (Phần 2)
Рисунок 7. Использование связи типа «Зависимость (включение)»

В итоге наша диаграмма будет выглядеть примерно так (Рисунок 8).

Từ mô hình hóa quy trình đến thiết kế hệ thống tự động (Phần 2)
Рисунок 8. Диаграмма Use-case (функциональная модель АС)

Кроме того, диаграмма Use-case используется для моделирования ролей пользователей (Рисунок 9).

Từ mô hình hóa quy trình đến thiết kế hệ thống tự động (Phần 2)
Рисунок 9. Диаграмма Use-case (роли пользователей АС)

Giai đoạn 4. Hãy mô tả tổ chức bên trong của AS bằng sơ đồ lớp

Используя информацию о входных и выходных артефактах нашего процесса (см. диаграммы Activity — Рисунок 2, Рисунок 3, Рисунок 4), разработаем диаграмму классов. Будем использовать моделирующий элементы «Класс» и различные виды связей между ними.

Từ mô hình hóa quy trình đến thiết kế hệ thống tự động (Phần 2)

Чтобы показать отношение «целое-часть» будем использовать связь типа «Агрегация» (Рисунок 10): орех – это целое, а скорлупки и ядро – это части.

Từ mô hình hóa quy trình đến thiết kế hệ thống tự động (Phần 2)
Рисунок 10. Отношение «целое-часть»

В итоге фрагмент нашей диаграммы будет выглядеть примерно так (Рисунок 11). Цветом отмечены классы, которые мы выделили непосредственно в текстовом описании процесса.

Từ mô hình hóa quy trình đến thiết kế hệ thống tự động (Phần 2)
Рисунок 11. Диаграмма классов

Диаграмма классов использовалась также для моделирования прочих артефактов – не только тех, которые будут иметь отношение к концептуальной модели автоматизируемого процесса учета материальных ценностей, но имеют отношение к среде выполнения – окружению (Рисунок 12) и «соседним» процессам (Рисунок 13), которые могут оказывать влияние на автоматизируемый процесс, но пока не находятся в фокусе нашего внимания (предполагаем, что система будет развиваться, и эта информация окажется полезной).

Từ mô hình hóa quy trình đến thiết kế hệ thống tự động (Phần 2)
Рисунок 12. Диаграмма классов (окружение)

Связь наследование показывает обобщение различных построек, «дочерние» классы, под обобщающим «родительским» классом «Строение».

Từ mô hình hóa quy trình đến thiết kế hệ thống tự động (Phần 2)
Рисунок 13. Диаграмма классов (дополнительная информация об артефактах)

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

Giai đoạn 5. Cùng phân tích những nốt nhạc trong bài “Quy tắc kinh doanh”

В качестве правил были указаны (см. Рисунок 2 в 1-ой части):

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

Следует отметить, что все эти правила мы уже использовали при разработке диаграмм.

Chú thích cuối

Итак, мы прошли 5 этапов и построили 3 вида диаграмм. Добавлю еще небольшой комментарий об организации наших моделей в среде моделирования. Существует большое количество фреймворков, которые помогают структурировать разрабатываемые модели, но это не предмет данной статьи, поэтому мы ограничимся следующим простым набором пакетов для упорядоченного ведения нашего проекта: Бизнес-процесс, Функциональная модель, Артефакты, Участники и Окружение (Рисунок 14).

Từ mô hình hóa quy trình đến thiết kế hệ thống tự động (Phần 2)
Рисунок 14. Структура пакетов проекта

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

Từ mô hình hóa quy trình đến thiết kế hệ thống tự động (Phần 1)

Danh sách các nguồn

  1. Trang web "UML2.ru". Diễn đàn cộng đồng phân tích. Phần chung. Ví dụ. Ví dụ về truyện cổ tích được định dạng dưới dạng sơ đồ UML. [Tài nguyên điện tử] Chế độ truy cập: Internet: http://www.uml2.ru/forum/index.php?topic=486.0
  2. Trang web Hệ thống Sparx. [Tài nguyên điện tử] Chế độ truy cập: Internet: https://sparxsystems.com
  3. Trang web Modelio. [Tài nguyên điện tử] Chế độ truy cập: Internet: https://www.modelio.org
  4. Từ điển bách khoa lớn. Quá trình (giải thích). [Tài nguyên điện tử] Chế độ truy cập: Internet: https://dic.academic.ru/dic.nsf/enc3p/246322
  5. Website “Tổ chức quản lý hiệu quả”. Blog. Chuyên mục "Quản lý quy trình kinh doanh". Định nghĩa về một quy trình kinh doanh. [Tài nguyên điện tử] Chế độ truy cập: Internet: https://rzbpm.ru/knowledge/pochemu-processy-stali-s-pristavkoj-biznes.html
  6. Giấy chứng nhận số 18249 về đăng ký và lưu chiểu tác phẩm trí tuệ. Alfimov R.V., Zolotukhina E.B., Krasnikova S.A. Bản thảo đồ dùng dạy học có tựa đề “Mô hình hóa một môn học bằng Enterprise Architect” // 2011.
  7. Zolotukhina E.B., Vishnya A.S., Krasnikova S.A. Mô hình hóa quy trình kinh doanh. — M.: KHÓA HỌC, SIC INFRA-M, EBS Znanium.com. - 2017.
  8. Đặc tả ngôn ngữ mô hình hóa thống nhất OMG (OMG UML). Phiên bản 2.5.1. [Tài nguyên điện tử] Chế độ truy cập: Internet: https://www.omg.org/spec/UML/2.5.1/PDF

Nguồn: www.habr.com

Thêm một lời nhận xét