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

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

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

Резюме на предишния епизод

В 1-ва част Използвахме „приказна“ предметна област, вдъхновени от примери за изучаване на UML диаграми с опора на сюжетите на приказките (виж, например, тук [1]). Преди да започнем моделирането, се договорихме относно използването на някои елементи от диаграмата Activity и започнахме да формираме съгласие по моделирането. С оглед на тези договорености, на първия етап описахме процеса под формата на диаграми Activity, а на втория етап извадихме стъпките на процеса, за които е необходимо (и възможно) автоматизиране.

Напомням, че възнамеряваме да автоматизираме дейността по счетоводство на материални ценности, която възниква в тези процеси.

…
Остров на морето се намира, (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) Specification. Version 2.5.1. [Електронен ресурс] Режим на достъп: Интернет: https://www.omg.org/spec/UML/2.5.1/PDF

Източник: habr.com