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

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

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

Резиме на претходната епизода

В 1 дел Ние користевме домен „бајка“, инспириран од примери за учење на UML дијаграми засновани на заплети од бајките (види, на пример, тука [1]). Пред да започне моделирањето, се договоривме за употреба на некои елементи од дијаграмот Активност и почнавме да формираме договор за моделирање. Земајќи ги предвид овие договори, во првата фаза го опишавме процесот во форма на дијаграми на активност, а во втората фаза ги идентификувавме чекорите на процесот за кои е потребна (и можна) автоматизација.

Дозволете ми да ве потсетам дека ќе ја автоматизираме активноста на сметководство за материјални средства, што произлегува од овие процеси.

...
Остров лежи на морето, (Е1, Е2)
На островот има град (Е3, Е1)
Со цркви со златна купола, (Е4)
Со кули и градини; (Е5, Е6)
Пред палатата расте смрека, (Е7, Е8)
А под него е кристална куќа; (Е9)
Таму живее питома верверица, (А1)
Да, каква авантура! (А1)
Верверицата пее песни, (П1, А1)
Да, тој продолжува да грицка ореви, (P2)
Но, оревите не се едноставни, (C1)
Сите школки се златни, (C2)
Јадрото е чист смарагд; (C3)
Слугите ја чуваат верверицата, (P3, A2)
Тие ѝ служат како разни слуги (П4)
И беше доделен службеник (А3)
Строга сметка за јаткастите плодови е вест; (P5, C1)
Војската ја поздравува; (P6, A4)
Од лушпите се истура паричка, (P7, C2, C4)
Нека одат низ светот; (P8)
Девојки истураат смарагд (P9, A5, C3)
Во магацините и под капакот; (Е10, Е11)
...
(А. се верува дека е слободна адаптација на народната приказна „Длабоко до колена во злато, до лактите во сребро“, која ја напишал Пушкин во различни верзии)

Во овој пример ја користам рамката Enterprise Architect од една австралиска компанија Спаркс системи [2], а за време на тренинг сесиите користам Модели [3].
Да ве потсетам дека постојат различни процеси, можете да се запознаете, на пример, тука [4] и тука [5].
За повеќе детали за применетите пристапи за моделирање и дизајн, видете [6, 7].
За целосна спецификација на UML, видете тука [8].

Сега сме подготвени да преминеме на следните чекори и да започнеме со дизајнирање на функционалноста и внатрешната организација на системот. Нумерирањето на цртежите ќе продолжи.

Фаза 3. Автоматизираниот чекор мора да биде поврзан со функција или функции на системот

Автоматизираниот систем (AS) што се развива е дизајниран да одржува строга евиденција за јаткастите плодови, се сеќавате? За секој означен чекор (види Слика 3, слика 4 во дел 1), што ќе го автоматизираме, ќе запишеме функционално барање со приближно следнава конструкција: „Системот мора да ја имплементира способноста...“ и да развиеме дијаграм за Use-case. Сега всушност додаваме нови правила на нашиот договор за моделирање. Дозволете ми да објаснам кои елементи ќе ги користиме.

Ќе ја користиме врската „Асоцијација“ помеѓу „Улогата на корисникот“ и „Функцијата“ (слика 5), тоа значи дека корисникот со оваа улога може да ја извршува оваа функција.

Слика 5. Користење на врска од типот на асоцијација

Од „Функција“ до „Барање“ ќе ја нацртаме врската „Имплементација“ (слика 6) за да покажеме дека ова барање ќе биде имплементирано од овие функции; односот може да биде „многу-до-многу“, т.е. Една функција може да биде вклучена во спроведувањето на неколку барања, а може да бидат потребни повеќе од една функција за да се имплементира некое барање.

Слика 6. Користење на односот тип „Имплементација“.

Ако една функција бара за нејзиното извршување да се изврши некоја друга функција, и нужно, ќе ја користиме врската „Зависност“ со стереотипот „Вклучи“ (Слика 7). Доколку е потребно извршување на дополнителна функција под одредени услови, тогаш ќе ја користиме врската „Зависност“ со стереотипот „Прошири“. Сè е многу лесно за паметење: „Вклучи“ е СЕКОГАШ, а „Прошири“ е ПОНЕКОГАШ.

Слика 7. Користење на односот „Зависност (вклучување)“.

Како резултат на тоа, нашиот дијаграм ќе изгледа отприлика вака (Слика 8).

Слика 8. Дијаграм за употреба (функционален модел на наизменична струја)

Дополнително, се користи дијаграм на Use-case за моделирање на улогите на корисниците (Слика 9).

Слика 9. Дијаграм за употреба (улоги на корисници на AS)

Фаза 4. Да ја опишеме внатрешната организација на АС користејќи дијаграм на класи

Користејќи информации за влезните и излезните артефакти на нашиот процес (видете дијаграми на активности - Слика 2, слика 3, слика 4), ќе развиеме дијаграм за класи. Ќе ги користиме елементите за моделирање „Класа“ и разни видови врски меѓу нив.

За да го прикажеме односот „целиот дел“, ќе користиме врска од типот „Агрегација“ (Слика 10): оревот е целина, а лушпите и јадрото се деловите.

Слика 10. Врска со цел дел

Како резултат на тоа, фрагмент од нашиот дијаграм ќе изгледа вака (Слика 11). Класите што ги истакнавме директно во текстуалниот опис на процесот се означени во боја.

Слика 11. Дијаграм на класи

Класниот дијаграм беше искористен и за моделирање на други артефакти - не само оние што ќе бидат поврзани со концептуалниот модел на автоматизираниот процес на сметководство за материјалните средства, туку и поврзани со опкружувањето на извршување - околината (слика 12) и „соседното“ процеси (слика 13) кои можат да влијаат на автоматизираниот процес, но сè уште не се во фокусот на нашето внимание (претпоставуваме дека системот ќе се развие и овие информации ќе бидат корисни).

Слика 12. Дијаграм на класи (средина)

Односот на наследството покажува генерализација на различни згради, класи „дете“, под генерализирачката „родител“ класа „Зграда“.

Слика 13. Дијаграм на класи (дополнителни информации за артефактите)

„Реакција на ситуацијата“ зависи од „Податоците за визуелна контрола“. За неколку врски на зависност, стереотипот „трага“ се користи за да се прикаже следењето на класи кои не се експлицитно идентификувани во описот на процесот, но кои се потребни за негово автоматизирање, до класи чии примери се експлицитно референцирани во нашиот опис.

Фаза 5. Да ги анализираме белешките на патеката „Деловни правила“.

Правилата беа специфицирани (види Слика 2 во дел 1):

1. потребата да се подели еден од чекорите на 2 дела, вториот дел почнува да се извршува само под одредени услови;
2. назначување на одредено службено лице за извршување на сметководството на оревите;
3. техника (бела боја на елементи) која покажува дека елементот не бил експлицитно наведен во описот на процесот.

Треба да се напомене дека веќе ги користевме сите овие правила при развивање дијаграми.

Завршни забелешки

Така, поминавме низ 5 фази и изградивме 3 типа на дијаграми. Ќе додадам мал коментар за организацијата на нашите модели во моделската средина. Има голем број рамки кои помагаат да се структурираат моделите што се развиваат, но ова не е тема на овој напис, па затоа ќе се ограничиме на следниве едноставни пакети за уредно управување со нашиот проект: Деловен процес, Функционален модел , артефакти, учесници и животна средина (Слика 14).

Слика 14. Структура на проектен пакет

Така, развивме конзистентни модели кои го опишуваат системот за сметководство на материјали од различни аспекти: модел на автоматизиран деловен процес, функционален модел и модел на внатрешна организација на системот на концептуално ниво.

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

Список на извори

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. Золотухина Е.Б., Вишња А.С., Красникова С.А. Моделирање на деловни процеси. — М.: КУРС, SIC INFRA-M, EBS Znanium.com. - 2017 година.
8. Спецификација OMG унифициран јазик за моделирање (OMG UML). Верзија 2.5.1. [Електронски ресурс] Режим на пристап: Интернет: https://www.omg.org/spec/UML/2.5.1/PDF

Извор: www.habr.com