„Един ден от живота на белката“ или как от моделиране на процеси да преминем към проектиране на автоматизирана система за управление на материални ценности „Белка-1.0“ (Част 1)
Каква е връзката с „белката“?
Нека веднага поясня каква е връзката с „белката“. Натъквайки се в интернет на забавни проекти за изучаване на UML, свързани с предметната област, заимствана от сюжетите на приказките (например, [1]), реших да подготвя такъв пример и за моите студенти, с цел за начало да изучат само три вида диаграми: Диаграма на дейности, Диаграма на случаи на употреба и Класова диаграма. Умишлено не превеждам имената на диаграмите на български, за да избегна спорове относно „превода“. Какво, за какво е – ще поясня малко по-късно. В този пример използвам средата Enterprise Architect от австралийската компания [2] – добър инструмент на разумна цена. А в рамките на учебните часове използвам [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)
…
(На А.С. Пушкин "Приказка за цар Салтан, за сина му славния и могъщ богатир княз Гвидон Салтанович и за прекрасната царевна Лебед", — 10 години от замисъла до публикуването, между другото!)
Някои кодове, написани вдясно на редовете. „A“ (от „Actor“) означава, че редът съдържа информация за участник в процеса. „C“ (от „Class“) – информация за обекти на класове, които се обработват по време на изпълнение на процесите. „E“ (от „Environment“) – информация за обекти на класове, които характеризират средата на изпълнение на процесите. „P“ (от „Process“) – информация за самите процеси.
Между другото, точното определение на процеса също претендира да стане причина за методологически спорове, понеже процесите са различни: бизнес, производствени, технологични и т.н. (може да се запознаете, например, [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).
Всички те се изпълняват от един участник в процеса – Дьяк приказный:
- Внася информация за теглото на ореха в ведомостта;
- Внася информация за предаване на ореха в ведомостта;
- Фиксира факта на преобразуването на ореха в черупки и ядро;
- Внася информация за ядрата на ореха в ведомостта;
- Внася информация за черупките на ореха в ведомостта.
Анализ на свършената работа. Какво следва?
Така, ние извършихме значителна подготовка: събрахме информация за процеса, който планираме да автоматизираме; започнахме да съставяме споразумение за моделиране (поне до момента само в частта на използването на диаграмата на дейността); извършихме моделиране на процеса и дори проведохме декомпозиция на няколко от неговите стъпки; выделихме стъпките на процеса, които ще автоматизираме. Сега сме готови да преминем към следващите етапи и да започнем проектиране на функции на системата и нейната вътрешна организация.
Както е известно, теорията без практика е нищо. Необходимо е задължително да опитате "моделирането" със собствените си ръце, това е полезно и за осъзнаване на предложеното подход. Например, може да работите в среда за моделиране [3]. Ние декомпозирахме само част от стъпките на диаграмата на общия вид на процеса (вж. Рис. 2). Като практическо задание може да бъде предложено да се повторят всички диаграми в средата на Modelio и да се извърши декомпозиция на стъпката „Предаване/прием на съхранение и преработка“.
Работата в конкретни среди за моделиране в момента не разглеждаме, но това може да стане предмет на самостоятелни статии и отзиви.
Във втората част на статията ще разгледаме техники за моделиране и проектиране, необходими на 3-5 етапа, ще използваме UML диаграми на Use-case и Class. Продължение следва.
Списък на източниците
- Сайт «UML2.ru». Форум на Общността на Аналитиците. Общ раздел. Примери. Примери на приказки, оформени под формата на UML диаграми. [Електронен ресурс] Режим на достъп: Интернет:
- Сайт на Sparx Systems. [Електронен ресурс] Достъп: Интернет:
- Сайт Modelio. [Електронен ресурс] Режим на достъп: Интернет:
- Голям енциклопедичен речник. Процес (тълкуване). [Електронен ресурс] Режим на достъп: Интернет:
- Сайтът «Организация на ефективното управление». Блог. Рубрика «Управление на бизнес процесите». Определение на бизнес процес. [Електронен ресурс] Режим на достъп: Интернет:
- Свидетелство № 18249 за регистрация и депониране на произведение на резултат от интелектуална дейност. Алфимов Р.В., Золотухина Е.Б., Красникова С.А. Ръкопис на учебно-методическо пособие с заглавие «Моделиране на предметната област с използване на Enterprise Architect» // 2011 г.
- Золотухина Е.Б., Вишня А.С., Красникова С.А. Моделиране на бизнес процеси. — М.: КУРС, НИЦ ИНФРА-М, ЕБС Znanium.com. — 2017.
Източник: habr.com
