🥇От моделиране на процеси към проектиране на автоматизирана система (Част 2)

„Един ден от живота на белката“ или от моделирането на процесите към проектирането на автоматизирана система за отчитане на материални ценности „Белка-1.0“ (Част 2)

Използвана е илюстрация от „Приказката за цар Салтан“ на А.С. Пушкин, изд. „Детска литература“, Москва, 1949 година, Ленинград, рисунки К. Кузнецов

Кратко резюме на предишната серия

В 1-ва част Ние използвахме „приказна“ предметна област, вдъхновени от примери за изучаване на 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)
…
(А.С. Пушкин „Приказка за цар Салтан, за сина му славния и могъщ богатир княз Гвидон Салтанович и за прекрасната царевна Лебеди“, както се счита, вълна обработка на народна приказка „По колена краката в злато, до лакти ръцете в сребро“, която беше записана от Пушкин в различни варианти)

В този пример използвам средата Enterprise Architect от австралийската компания Sparx Systems [2], а в рамките на учебните занятия прилагам Modelio [3].
Напомням, че процесите могат да бъдат различни, можете да се запознаете, например, тук. [4] и тук. [5].
По-подробно за използваните подходи към моделирането и проектирането вижте [6, 7].
Пълната спецификация на UML вижте. тук. [8].

Сега сме готови да преминем към следващите етапи и да започнем проектирането на функциите на системата и нейната вътрешна организация. Номерирането на рисунките ще бъде продължено.

Етап 3. На автоматизирания етап трябва да поставим в съответствие функция или функции на системата

Разработваната автоматизирана система (АС) е предназначена за водене на строг отчет на ядки, помните? За всяка изолирана стъпка (виж Рисунка 3, Рисунка 4 в 1-ата част), която ще автоматизираме, ще запишем функционално изискване, прилагащи приблизително такава конструкция „В системата трябва да бъде реализирана възможността …“ и ще разработим диаграма Use-case. Сега всъщност допълваме нашето споразумение по моделирането с нови правила. Ще обясня какви елементи ще използваме.

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

Рисунок 5. Използване на връзка от тип «Асоциация»

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

Рисунок 6. Използване на връзка от тип «Реализация»

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

Рисунок 7. Използване на връзка от тип «Зависимост (включване)»

В крайна сметка нашата диаграма ще изглежда по този начин (Рисунок 8).

Рисунок 8. Диаграма на Use-case (функционален модел на АС)

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

Рисунок 9. Диаграма на Use-case (роли на потребителите на АС)

Етап 4. Описваме вътрешната организация на АС с помощта на диаграма на класовете

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

За да покажем отношението «цяло-част» ще използваме връзка от тип «Агрегация» (Рисунок 10): орехът – това е цялото, а черупките и ядрото – това са частите.

Рисунок 10. Отношение «цяло-част»

В крайна сметка фрагментът на нашата диаграма ще изглежда по този начин (Рисунок 11). С цвят са отбелязани класовете, които сме изтъкнали директно в текстовото описание на процеса.

Рисунок 11. Диаграма на класовете

Диаграмата на класовете беше използвана и за моделиране на други артефакти – не само тези, които ще имат отношение към концептуалния модел на автоматизирания процес на отчитане на материални ценности, но и към средата на изпълнение – околната среда (Рисунок 12) и „съседни“ процеси (Рисунок 13), които могат да повлияят на автоматизирания процес, но все още не са в центъра на нашето внимание (предполагаме, че системата ще се развие и тази информация ще се окаже полезна).

Рисунок 12. Диаграмата на класовете (околната среда)

Връзката наследяване показва обобщение на различни конструкции, „дъщерни“ класове под обобщаващия „родителски“ клас „Конструкция“.

Рисунок 13. Диаграмата на класовете (допълнителна информация за артефактите)

„Реакцията на ситуацията“ зависи от „Данни за визуален контрол“. За няколко зависимости се използва стереотип „trace“, за да покаже трасировката на класове, явно не обозначени в описанието на процеса, но които са необходими за автоматизацията му, към класовете, на които има точно указание в нашето описание.

Етап 5. Анализираме забележките на пътеката „Бизнес правила“

Като правила бяха посочени (вижте Рисунок 2 в 1-ата част):

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

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

Заключителни бележки

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

Рисунок 14. Структура на пакетите на проекта

По този начин разработихме съгласувани модели, описващи система за отчитане на материални ценности от различни страни: модел на автоматизируем бизнес процес, функционален модел и модел за вътрешна организация на системата на концептуално ниво.

От моделирането на процесите до проектирането на автоматизирана система (Част 1)

Списък на източниците

Сайт «UML2.ru». Форум на Общността на Аналитиците. Общ раздел. Примери. Примери на приказки, оформени под формата на UML диаграми. [Електронен ресурс] Режим на достъп: Интернет: http://www.uml2.ru/forum/index.php?topic=486.0
Сайт на Sparx Systems. [Електронен ресурс] Достъп: Интернет: https://sparxsystems.com
Сайт Modelio. [Електронен ресурс] Режим на достъп: Интернет: https://www.modelio.org
Голям енциклопедичен речник. Процес (тълкуване). [Електронен ресурс] Режим на достъп: Интернет: https://dic.academic.ru/dic.nsf/enc3p/246322
Сайтът «Организация на ефективното управление». Блог. Рубрика «Управление на бизнес процесите». Определение на бизнес процес. [Електронен ресурс] Режим на достъп: Интернет: https://rzbpm.ru/knowledge/pochemu-processy-stali-s-pristavkoj-biznes.html
Свидетелство № 18249 за регистрация и депониране на произведение на резултат от интелектуална дейност. Алфимов Р.В., Золотухина Е.Б., Красникова С.А. Ръкопис на учебно-методическо пособие с заглавие «Моделиране на предметната област с използване на Enterprise Architect» // 2011 г.
Золотухина Е.Б., Вишня А.С., Красникова С.А. Моделиране на бизнес процеси. — М.: КУРС, НИЦ ИНФРА-М, ЕБС Znanium.com. — 2017.
OMG Unified Modeling Language (OMG UML) Спецификация. Версия 2.5.1. [Електронен ресурс] Достъп: Интернет: https://www.omg.org/spec/UML/2.5.1/PDF