"Адзін дзень з жыцця вавёркі" або ад мадэлявання працэсаў да праектавання аўтаматызаванай сістэмы ўліку матэрыяльных каштоўнасцяў "Белка-1.0" (Частка 1)
Пры чым тут "вавёрка"?
Адразу растлумачу, пры чым тут "вавёрка". Натыкнуўшыся ў Сеткі на пацешныя праекты для вывучэння UML з апорай на прадметную вобласць, запазычаную з сюжэтаў казак (напрыклад, [1]), я для сваіх студэнтаў таксама вырашыла падрыхтаваць падобны прыклад, каб можна было вывучыць для пачатку ўсяго тры віды дыяграм: Activity Diagram, Use-case Diagram і Class Diagram. Наўмысна не перакладаю на рускую мову назвы дыяграм, каб пазбегнуць спрэчак аб "цяжкасцях перакладу". Што для чаго - растлумачу крыху пазней. У дадзеным прыкладзе я выкарыстоўваю асяроддзе 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, і аб'екты трох розных класаў: аб'ект класа С1 паступае на ўваход кроку, аб'екты класаў С2 і С3 атрымліваюцца на выхадзе, як вынік дзейнасці гэтага кроку 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. Дыяграма Activity – дэталізацыя (частка1)
Малюнак 4. Дыяграма Activity – дэталізацыя (частка2)
Этап 2. Вылучаем тое, што можна аўтаматызаваць
Крокі, якія падлягаюць аўтаматызацыі на дыяграмах выдзелены колерам (гл. Малюнак 3, Малюнак 4).
Усе іх выконвае адзін удзельнік працэсу – дзяк загадны:
- Уносіць інфармацыю аб вазе арэха ў ведамасць;
- Уносіць інфармацыю аб перадачы арэха ў ведамасць;
- Фіксуе факт ператварэння арэха ў шкарлупіны і ядро;
- Уносіць інфармацыю аб ядры арэха ў ведамасць;
- Уносіць інфармацыю аб шкарлупках арэха ў ведамасць.
Аналіз праведзенай працы. Што далей?
Такім чынам, мы выканалі вялікую падрыхтоўчую працу: сабралі інфармацыю аб працэсе, які збіраемся аўтаматызаваць; пачалі фармаваць дамову па мадэляванні (пакуль толькі ў частцы выкарыстання дыяграмы Activity); выканалі мадэляванне працэсу і нават правялі дэкампазіцыю некалькіх яго крокаў; вылучылі крокі працэсу, якія будзем аўтаматызаваць. Цяпер мы гатовы перайсці да наступных этапаў і пачаць праектаванне функцый сістэмы і яе ўнутранай арганізацыі.
Як вядома, тэорыя без практыкі - нішто. Трэба абавязкова паспрабаваць "мадэляванне" сваімі рукамі, гэта карысна і для ўсведамлення прапанаванага падыходу. Напрыклад, можна папрацаваць у асяроддзі мадэлявання [3]. Мы дэкампазіравалі толькі частку крокаў дыяграмы агульнага віду працэсу (гл. Малюнак 2). У якасці практычнага задання можа быць прапанавана паўтарыць усе дыяграмы ў асяроддзі Modelio і выканаць дэкампазіцыю кроку "Перадача / прыём на захоўванне і перапрацоўку".
Працу ў пэўных асяроддзях мадэлявання мы пакуль не разглядаем, але гэта можа стаць прадметам самастойных артыкулаў і аглядаў.
У другой частцы артыкула мы разбяром прыёмы мадэлявання і праектавання, неабходныя на 3-5 этапах, выкарыстоўваць будзем UML дыяграмы Use-case і Class. Працяг будзе.
Спіс крыніц
- Сайт "UML2.ru". Форум Супольнасці Аналітыкаў. Агульны раздзел. Прыклады. Прыклады казак, аформленых у выглядзе UML дыяграм. [Электронны рэсурс] Рэжым доступу: Інтэрнэт:
- Сайт Sparx Systems. [Электронны рэсурс] Рэжым доступу: Інтэрнэт:
- Сайт Modelio. [Электронны рэсурс] Рэжым доступу: Інтэрнэт:
- Вялікі Энцыклапедычны слоўнік. Працэс (тлумачэнне). [Электронны рэсурс] Рэжым доступу: Інтэрнэт:
- Сайт "Арганізацыя эфектыўнага кіравання". Блог. Рубрыка «Кіраванне бізнес працэсамі». Вызначэнне бізнес працэсу. [Электронны рэсурс] Рэжым доступу: Інтэрнэт:
- Пасведчанне № 18249 аб рэгістрацыі і дэпанаванні твора выніку інтэлектуальнай дзейнасці. Алфімаў Р.В., Залатухіна А.Б., Краснікава С.А. Рукапіс вучэбна-метадычнага дапаможніка пад назвай "Мадэляванне прадметнай вобласці з выкарыстаннем Enterprise Architect" // 2011г.
- Залатухіна А.Б., Вішня А.С., Краснікава С.А. Мадэляванне бізнес-працэсаў. - М .: КУРС, НДЦ ИНФРА-М, ЭБС Znanium.com. - 2017.
Крыніца: habr.com