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