"ថ្ងៃមួយក្នុងជីវិតរបស់សត្វកំប្រុក" ឬពីដំណើរការគំរូដល់ការរចនាប្រព័ន្ធគណនេយ្យទ្រព្យសម្បត្តិស្វ័យប្រវត្តិ "Belka-1.0" (ផ្នែកទី 2)
Краткое содержание предыдущей серии
В мы использовали «сказочную» предметную область, вдохновленные примерами изучения диаграмм UML с опорой на сюжеты сказок (см., например, [1]). До начала моделирования мы договорились относительно использования некоторых элементов диаграммы Activity и начали формировать соглашение по моделированию. С учетом этих договоренностей мы на 1-ом этапе описали процесс в виде диаграмм Activity, а на 2-ом этапе выделили шаги процесса, для которых требуется (и возможна) автоматизация.
Напомню, что автоматизировать мы собираемся деятельность по учёту материальных ценностей, которая возникает вот в этих процессах.
...
កោះមួយស្ថិតនៅលើសមុទ្រ (E1, E2)
មានព្រឹលនៅលើកោះ (E3, E1)
ជាមួយនឹងព្រះវិហារពណ៌មាស (E4)
ជាមួយនឹងប៉មនិងសួនច្បារ; (E5, E6)
ដើមព្រីងដុះនៅមុខវាំង (E7, E8)
ហើយខាងក្រោមវាគឺជាផ្ទះគ្រីស្តាល់។ (E9)
សត្វកំប្រុករស់នៅទីនោះ (A1)
មែនហើយ ដំណើរផ្សងព្រេង! (A1)
កំប្រុកច្រៀងចម្រៀង, (P1, A1)
បាទ គាត់បន្តញញួរគ្រាប់ (P2)
ប៉ុន្តែគ្រាប់មិនសាមញ្ញទេ (C1)
សំបកទាំងអស់មានពណ៌មាស (C2)
ស្នូលគឺត្បូងមរកតសុទ្ធ; (C3)
អ្នកបម្រើការពារកំប្រុក (P3, A2)
ពួកគេបម្រើនាងជាអ្នកបម្រើផ្សេងៗ (P4)
ហើយស្មៀនម្នាក់ត្រូវបានចាត់តាំង (A3)
គណនីដ៏តឹងរឹងនៃគ្រាប់គឺជាព័ត៌មាន; (P5, C1)
កងទ័ពសរសើរនាង; (P6, A4)
កាក់មួយត្រូវបានចាក់ចេញពីសំបក (P7, C2, C4)
អនុញ្ញាតឱ្យពួកគេទៅជុំវិញពិភពលោក; (P8)
ក្មេងស្រីចាក់ត្បូងមរកត (P9, A5, C3)
ចូលទៅក្នុងឃ្លាំងនិងនៅក្រោមគម្រប; (E10, E11)
...
(А.С.Пушкина «Сказка о царе Салтане, о сыне его славном и могучем богатыре князе Гвидоне Салтановиче и о прекрасной царевне Лебеди», )
ក្នុងឧទាហរណ៍នេះ ខ្ញុំកំពុងប្រើក្របខ័ណ្ឌស្ថាបត្យករសហគ្រាសពីក្រុមហ៊ុនអូស្ត្រាលី [2], а в рамках учебных занятий применяю [3] ។
Напомню, что процессы бывают разные, ознакомится можно, например, [4] និង [5] ។
Подробнее о применяемых подходах к моделированию и проектированию см. [6, 7].
សម្រាប់ការបញ្ជាក់ពេញលេញរបស់ UML សូមមើល [8] ។
Теперь мы готовы перейти к следующим этапам и начать проектирование функций системы и ее внутренней организации. Нумерация рисунков будет продолжена.
ដំណាក់កាលទី 3. ជំហានស្វ័យប្រវត្តិត្រូវតែភ្ជាប់ជាមួយមុខងារ ឬមុខងារនៃប្រព័ន្ធ
Разрабатываемая автоматизированная система (АС) предназначена для ведения строгого учета орехов, помните? Для каждого выделенного шага (см. Рисунок 3, Рисунок 4 ), который будем автоматизировать, запишем функциональное требование, применяя примерно такую конструкцию «В системе должна быть реализована возможность …» и разработаем диаграмму Use-case. Сейчас мы фактически дополняем наше соглашение по моделированию новыми правилами. Поясню какие элементы будем использовать.
Между «Ролью пользователя» и «Функцией» будем использовать связь «Ассоциация» (Рисунок 5), это означает, что для пользователя с данной ролью доступно выполнение данной функции.
Рисунок 5. Использование связи типа «Ассоциация»
От «Функции» к «Требованию» проведем связь «Реализация» (Рисунок 6), чтобы показать, что данное требование будет реализовано вот этими функциями, отношение может быть и «многие-ко многим», т.е. одна функция может участвовать в реализации нескольких требований, а для реализации требования может понадобиться более одной функции.
Рисунок 6. Использование связи типа «Реализация»
Если одна функция требует для своего выполнения, чтобы была выполнена еще какая-то функция, причем обязательно, будем использовать связь «Зависимость» со стереотипом «Include» — включение (Рисунок 7). Если же выполнение дополнительной функции требуется при определенных условиях, то будем использовать связь «Зависимость» со стереотипом «Extend» — расширение. Все очень легко запомнить: «Include» — ВСЕГДА, а «Extend» – ИНОГДА.
Рисунок 7. Использование связи типа «Зависимость (включение)»
В итоге наша диаграмма будет выглядеть примерно так (Рисунок 8).
Рисунок 8. Диаграмма Use-case (функциональная модель АС)
Кроме того, диаграмма Use-case используется для моделирования ролей пользователей (Рисунок 9).
Рисунок 9. Диаграмма Use-case (роли пользователей АС)
ដំណាក់កាលទី 4. ចូរពិពណ៌នាអំពីការរៀបចំផ្ទៃក្នុងរបស់ AS ដោយប្រើដ្យាក្រាមថ្នាក់
Используя информацию о входных и выходных артефактах нашего процесса (см. диаграммы Activity — Рисунок 2, Рисунок 3, Рисунок 4), разработаем диаграмму классов. Будем использовать моделирующий элементы «Класс» и различные виды связей между ними.
Чтобы показать отношение «целое-часть» будем использовать связь типа «Агрегация» (Рисунок 10): орех – это целое, а скорлупки и ядро – это части.
Рисунок 10. Отношение «целое-часть»
В итоге фрагмент нашей диаграммы будет выглядеть примерно так (Рисунок 11). Цветом отмечены классы, которые мы выделили непосредственно в текстовом описании процесса.
Рисунок 11. Диаграмма классов
Диаграмма классов использовалась также для моделирования прочих артефактов – не только тех, которые будут иметь отношение к концептуальной модели автоматизируемого процесса учета материальных ценностей, но имеют отношение к среде выполнения – окружению (Рисунок 12) и «соседним» процессам (Рисунок 13), которые могут оказывать влияние на автоматизируемый процесс, но пока не находятся в фокусе нашего внимания (предполагаем, что система будет развиваться, и эта информация окажется полезной).
Рисунок 12. Диаграмма классов (окружение)
Связь наследование показывает обобщение различных построек, «дочерние» классы, под обобщающим «родительским» классом «Строение».
Рисунок 13. Диаграмма классов (дополнительная информация об артефактах)
«Реакция на ситуацию» зависит от «Данных визуального контроля». Для нескольких связей зависимости используется стереотип «trace», чтобы показать трассировку классов, явно не обозначенных в описании процесса, но которые необходимы для его автоматизации, к классам, на экземпляры которых есть точное указание в нашем описании.
ដំណាក់កាលទី 5. ចូរយើងវិភាគកំណត់ចំណាំនៅលើបទ "ច្បាប់អាជីវកម្ម"
В качестве правил были указаны (см. Рисунок 2 ):
- необходимость разбиения одного из шагов на 2 части, вторая часть начинает выполняться только при определенных условиях;
- назначение для выполнения учета орехов определенного должностного лица;
- технический прием (белый цвет элементов), который указывает, что элемент явно не был указан в описании процесса.
Следует отметить, что все эти правила мы уже использовали при разработке диаграмм.
សុន្ទរកថាចុងក្រោយ
Итак, мы прошли 5 этапов и построили 3 вида диаграмм. Добавлю еще небольшой комментарий об организации наших моделей в среде моделирования. Существует большое количество фреймворков, которые помогают структурировать разрабатываемые модели, но это не предмет данной статьи, поэтому мы ограничимся следующим простым набором пакетов для упорядоченного ведения нашего проекта: Бизнес-процесс, Функциональная модель, Артефакты, Участники и Окружение (Рисунок 14).
Рисунок 14. Структура пакетов проекта
Таким образом, мы разработали согласованные модели, описывающие систему учета материальных ценностей с различных сторон: модель автоматизируемого бизнес-процесса, функциональную модель и модель внутренней организации системы на концептуальном уровне.
បញ្ជីប្រភព
- គេហទំព័រ "UML2.ru" ។ វេទិកាសហគមន៍អ្នកវិភាគ។ ផ្នែកទូទៅ។ ឧទាហរណ៍។ ឧទាហរណ៍នៃរឿងនិទានដែលបានធ្វើទ្រង់ទ្រាយជាដ្យាក្រាម UML ។ [ធនធានអេឡិចត្រូនិក] របៀបចូលប្រើ៖ អ៊ីនធឺណិត៖
- គេហទំព័រ Sparx Systems ។ [ធនធានអេឡិចត្រូនិក] របៀបចូលប្រើ៖ អ៊ីនធឺណិត៖
- គេហទំព័រគំរូ។ [ធនធានអេឡិចត្រូនិក] របៀបចូលប្រើ៖ អ៊ីនធឺណិត៖
- វចនានុក្រមសព្វវចនាធិប្បាយធំ។ ដំណើរការ (ការបកស្រាយ) ។ [ធនធានអេឡិចត្រូនិក] របៀបចូលប្រើ៖ អ៊ីនធឺណិត៖
- គេហទំព័រ "ការគ្រប់គ្រងប្រកបដោយប្រសិទ្ធភាព" ។ ប្លុក។ ប្រភេទ "ការគ្រប់គ្រងដំណើរការអាជីវកម្ម" ។ និយមន័យនៃដំណើរការអាជីវកម្ម។ [ធនធានអេឡិចត្រូនិក] របៀបចូលប្រើ៖ អ៊ីនធឺណិត៖
- វិញ្ញាបនបត្រលេខ 18249 ស្តីពីការចុះឈ្មោះនិងការដាក់ប្រាក់នៃការងារនៃសកម្មភាពបញ្ញា។ Alfimov R.V., Zolotukhina E.B., Krasnikova S.A. សាត្រាស្លឹករឹតនៃជំនួយការបង្រៀនដែលមានចំណងជើងថា "ការធ្វើគំរូតំបន់ប្រធានបទដោយប្រើស្ថាបត្យករសហគ្រាស" // ឆ្នាំ 2011 ។
- Zolotukhina E.B., Vishnya A.S., Krasnikova S.A. គំរូនៃដំណើរការអាជីវកម្ម។ - M.: វគ្គសិក្សា, SIC INFRA-M, EBS Znanium.com ។ – ឆ្នាំ ២០១៧។
- ការបញ្ជាក់ភាសាគំរូបង្រួបបង្រួម OMG (OMG UML) ។ កំណែ 2.5.1 ។ [ធនធានអេឡិចត្រូនិក] របៀបចូលប្រើ៖ អ៊ីនធឺណិត៖
ប្រភព: www.habr.com