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

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

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

Какво общо има „катерицата“?

Веднага ще поясня какво общо има „катерицата“. Някак си, натъквайки се в мрежата на забавни проекти за изучаване на UML, базирани на предметни области, заимствани от сюжети на приказки (например, тук [1]), реших да подготвя подобен пример и за моите студенти, за да могат да изучат в началото само три вида диаграми: Діаграма на дейността, Діаграма на случая на приложение и Класова диagrama. Умишлено не превеждам на български имената на диаграмите, за да избегна спорове относно „трудностите на превода“. Какво за какво – ще обясня малко по-късно. В този пример използвам среда Enterprise Architect от австралийската компания Sparx Systems [2] – добър инструмент на разумна цена. А в рамките на учебните занятия използвам Modelio [3], приличен безплатен инструмент за обектно-ориентирано проектиране, който поддържа стандартите UML2.0 и BPMN, без излишни функции в частта на графичните възможности, но напълно достатъчен за изучаване на основите на езика.

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

…
Остров на морето се намира, (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)
…
(А.С. Пушкин „Приказка за цар Салтан, за сина му славен и могъщ богатир княз Гвидон Салтанович и за прекрасната царевна Лебеди“, работата по приказката е започната предположително през 1822 г., за първи път приказката е публикувана от Пушкин в сборника „Стихотворения на А. Пушкин“ (ч. III, 1832, стр. 130—181) — 10 години от замисъла до публикуването, между другото!)

Няколко думи за кодовете, написани вдясно от редовете. „A“ (от „Актьор“) означава, че в реда има информация за участника в процеса. „C“ (от „Клас“) – информация за обектите на класовете, които се обработват по време на изпълнението на процесите. „E“ (от „Околна среда“) – информация за обектите на класовете, които характеризира околната среда на изпълнението на процесите. „P“ (от „Процес“) – информация за самите процеси.

Между другото, точното определение на процеса също предизвиква методологични спорове, понеже съществуват различни видове процеси: бизнес, производствени, технологични и т.н. (можете да се запознаете, например, тук [4] и тук [5]). За да избегнем спорове, да се договорим, че процесът ни интересува от гледна точка на неговата повторяемост във времето и необходимостта от автоматизация, т.е. прехвърляне на изпълнението на някоя част от операциите на процеса на автоматизирана система.

Бележки относно приложението на диаграмата Activity

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

…
Белката пее песнички, (P1, A1)
Да, все орехи гризе, (P2)
А орехите не са обикновени, (C1)
Всички черупки са златни, (C2)
Ядките са чисти изумруди; (C3)
…

Имаме две стъпки на процеса P1 и P2, участник A1 и обекти от три различни класа: обект от клас C1 постъпва на входа на стъпката, а обектите от класове C2 и C3 се получават на изхода, като резултат от дейността на тази стъпка P2 от нашия процес. За диаграмата ще използваме следните моделиращи елементи.

Фрагментът на нашия процес може да бъде представен приблизително така (Фигура 1).

Фигура 1. Фрагмент на диаграмата Activity

За организиране на пространството и структуриране на диаграмата Activity ще приложим не съвсем стандартен подход, от гледна точка на класическото използване на нотацията UML. Но за това има няколко причини. Първо, просто преди началото на моделирането ще съставим т.нар. съгласие за моделиране, в което ще фиксираме всички особености на използването на нотацията. Второ, този подход многократно е бил успешно приложен на етапа на бизнес моделиране в реални проекти за създаване на софтуерни системи, резултатите са били фиксирани от нашия малък авторски колектив в съответния обект на авторско право [6] и също така използвани в учебно пособие [7]. За диаграмата Activity ще определим, че полето на диаграмата структурирано с помощта на "плавателни" ленти – Swim lanes. Името на лентата ще съответства на тип елементите на диаграмата, които ще бъдат разположени на тази лента.

"Входни и изходни артефакти": На тази пътека ще се разположат елементите Objects – обекти, които се използват или са резултат от изпълнението на определена стъпка от процеса.
«Стъпки на процеса»: Тук ще поставим елементите Activity – действия на участниците в процеса.
«Участници»: Пътека за елементи, които ще обозначават ролите на изпълнителите на действия в нашия процес. За тях ще използваме същия моделирующий елемент Object – обект, но ще добавим стереотипа «Actor».
Следващата пътека се нарича «Бизнес правила» и на тази пътека ще разположим в текстов вид правилата за изпълнение на стъпките на процеса. За целта ще използваме моделирующий елемент Note – бележка.
Тук ще спрем, въпреки че допълнително можеше да се използва и пътека «Инструменти» за събиране на информация за нивото на автоматизация на процеса. Може да е полезна и пътека «Длъжности и подразделения на участниците», която може да се използва за свързване на ролите с длъжностите и подразделенията на участниците в процеса.

Всичко, което току-що описах, е фрагмент от споразумението за моделиране, тази част от споразумението се отнася до правилата за организация на една диаграма и съответно до правилата за нейното писане и четене.

«Рецепта»

Сега ще разгледаме варианта за моделиране на системата именно от диаграмата Activity. Това е само един от вариантите, отбелязвам, че той, разбира се, не е единствен. Диаграмата Activity ще ни интересува от гледна точка на нейната роля за прехода от моделиране на процеса към проектиране на автоматизирана система. За тази цел ще се придържаме към методическите препоръки – своеобразна рецепта, състояща се само от пет етапа и предвиждаща разработката на три вида диаграми. Прилагането на тази рецепта ще помогне да се получи формализирано описание на процеса, който искаме да автоматизираме, и да се съберат данни за проектиране на системата. А за студентите в началото на изучаването на UML това е своеобразен спасителен кръг, който не позволява да се потопят в многообразието от графични средства и техники, които има в UML и съвременните средства за моделиране.

Ето, всъщност, самата рецепта, а следват диаграмите, построени за нашата «приказна» предметна област.

Етап 1. Описваме процеса под формата на диаграма Activity. За процеси, в които са определени повече от 10 стъпки, има смисъл да приложим принципа на декомпозиция на стъпките, за да повишим четимостта на диаграмата.

Етап 2. Определяме какво може да бъде автоматизирано. (стъпките могат да бъдат, например, подчертавани на диаграмата).

Етап 3. На автоматизируемата стъпка трябва да се съпостави функция или функции на системата (отношението може да бъде много-към-много), рисуваме диаграма на Use-case. Това са функциите на нашата система.

Етап 4. Ще опишем вътрешната организация на АС с помощта на диаграма класове – Class. Плувната лента "Входни и изходни обекти (документи)" на диаграмата Activity е основата за изграждане на обектна модел и модел на сущност-свързване.

Етап 5. Ще анализираме записките на модула "Бизнес-правила", те дават различни ограничения и условия, като постепенно се трансформират в нефункционални изисквания.
Получената група диаграми (Activity, Use-case, Class) предоставя формализирано описание в достатъчно строга нотация, т.е. има еднозначно прочитане. Сега можем да разработим техническо задание, уточнявайки спецификацията на изискванията и т.н.

Да преминем към моделиране.

Етап 1. Описваме процеса под формата на диаграма Activity.

Напомням, че полето на диаграмата структурирахме с помощта на "плувни" ленти, на всяка лента са разположени елементи от един и същи вид (Фигура 2). Освен описаните по-горе елементи на диаграмата ще използваме допълнителни елементи, нека да ги опишем.

Решение (Decision) обозначава на диаграмата точка на разклонение на нашия процес, а сливането на потоките (Merge) – точка на тяхното възстановяване. В квадратни скоби на преходите са записани условията на преходите.

Между двата синхронизатора (Fork) ще показваме паралелни клонове на процеса.
Нашият процес може да има само едно начало – една точка на вход (Initial). А завършвания (Final) може да има няколко, но не за нашата конкретна диаграма.

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

Фигура 2. Диаграма Activity – общ вид на процеса

Тъй като в стихотворните редове някои детайли от процеса са пропуснати, се наложи да ги възстановим, като те са показани с елементи на бял фон. Тези детайли включват стъпка „Предаване/приемане на съхранение и преработка“ и няколко входящи и изходящи артефакти. Струва си да се отбележи, че и тази стъпка не разкрива напълно процеса, тъй като трябваше отделно да обозначим стъпката на предаване и стъпката на приемане, а за черупките дори да добавим отделна стъпка, а също така да предположим, че първоначално всичките тези материални ценности трябва да се съхраняват някъде временно и т.н.
Още веднъж, ще обърнем внимание, че остава без отговор въпросът за произхода на орехите – откъде идват и как попадат при белките? И този въпрос (той е подчертан с червен шрифт в бележката – елемент Note) изисква отделна разработка! Така работи аналитикът – събирайки информация по малко, правейки предположения и получавайки „окей“ или „не-окей“ от експертите в предметната област – много важни и просто незаменими хора на етапа на бизнес моделиране при създаването на системи.

Обърнете внимание също, че стъпката на процеса P5 се състои от две части.

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

Рисунка 3. Диаграма на дейността – детайлизиране (част 1)

Рисунка 4. Диаграма на дейността – детайлизиране (част 2)

Етап 2. Определяме какво може да бъде автоматизирано.

Стъпките, подлежащи на автоматизация, са подчертане с цвят в диаграмите (вж. Рисунка 3, Рисунка 4).

Всичко това се извършва от един участник в процеса – Дьяк приказный:

• Внася информация за теглото на ореха в ведомостта;
• Внася информация за предаването на ореха в ведомостта;
• Фиксира факта на превръщането на ореха в черупки и ядро;
• Внася информация за ядрата на ореха в ведомостта;
• Внася информация за черупките на ореха в ведомостта.

Анализ на извършената работа. Какво следва?

И така, извършихме много подготвителна работа: събрахме информация за процеса, който възнамеряваме да автоматизираме; започнахме да оформяме споразумение за моделиране (засега само в частта за използване на диаграмата Activity); извършихме моделиране на процеса и дори проведохме декомпозиция на няколко от неговите стъпки; отделихме стъпките на процеса, които ще автоматизираме. Сега сме готови да преминем към следващите етапи и да започнем проектирането на функционалностите на системата и нейната вътрешна структура.

Както е известно, теорията без практика е нищо. Необходимо е задължително да опитате "моделирането" с вашите ръце, това е полезно и за осъзнаване на предложените подходи. Например, можете да работите в среда за моделиране. Modelio [3]. Ние декомпозирахме само част от стъпките на диаграмата на общия вид процес (вижте Рисунок 2). Като практическо задание може да бъде предложено да повторите всички диаграми в средата Modelio и да извършите декомпозиция на стъпката „Предаване/прием на съхранение и преработка”.
Работата в конкретни среди за моделиране не я разглеждаме за момента, но това може да стане обект на самостоятелни статии и прегледи.

Във втората част на статията ще разгледаме техники за моделиране и проектиране, необходими на 3-5 етапа, ще използваме UML диаграми Use-case и Class. Продължението следва.

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

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

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