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

"Един ден от живота на една катерица" или от процесите на моделиране до проектирането на автоматизирана система за отчитане на материални активи "Белка-1.0" (част 2)

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

Резюме на предишната серия

В 1-ва част използвахме "приказна" тематична област, вдъхновена от примери за изучаване на UML диаграми, базирани на сюжети от приказки (вижте, например, тук [1]). Преди моделирането се договорихме за използването на някои елементи от диаграмата на дейността и започнахме да формираме споразумение за моделиране. Като взехме предвид тези споразумения, на 1-ви етап описахме процеса под формата на диаграми на дейностите, а на 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)
...
(A.S. Пушкин „Приказката за цар Салтан, за неговия славен и могъщ син княз Гвидон Салтанович и красивата принцеса лебед“, както се смята, свободна адаптация на народната приказка "До колене в злато, до лакът в сребро", която е записана от Пушкин в различни версии)

В този пример използвам среда Enterprise Architect от австралийска компания. Sparx Systems [2] и в рамките на тренировките, които използвам Моделио [3].
Нека ви напомня, че процесите са различни, можете да се запознаете напр. тук [4] ​​и тук [5].
Вижте [6, 7] за подробности относно приложените подходи за моделиране и проектиране.
За пълната UML спецификация вижте тук [8].

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

Етап 3. На автоматизираната стъпка трябва да бъде присвоена функция или функции на системата

Автоматизираната система (AS), която се разработва, е предназначена да поддържа строг регистър на ядките, помните ли? За всяка маркирана стъпка (вижте Фигура 3, Фигура 4 в част 1), който ще автоматизираме, ще запишем функционалното изискване, като използваме нещо като тази конструкция „Системата трябва да може да ...“ и ще разработим диаграма на случая на използване. Сега всъщност допълваме нашето споразумение за моделиране с нови правила. Нека обясня какви елементи ще използваме.

Между „Потребителска роля“ и „Функция“ ще използваме връзката „Асоциация“ (Фигура 5), което означава, че потребителят с тази роля може да изпълнява тази функция.

Фигура 5. Използване на връзка тип асоциация

От „Функция“ към „Изискване“ ще начертаем връзката „Изпълнение“ (Фигура 6), за да покажем, че това изискване ще бъде изпълнено от тези функции, връзката може да бъде „много към много“, т.е. една функция може да участва в изпълнението на няколко изисквания и може да е необходима повече от една функция за изпълнение на изискването.

Фигура 6. Използване на връзка за изпълнение

Ако една функция изисква за изпълнението си друга функция да бъде изпълнена и е необходимо, ще използваме връзката „Зависимост“ със стереотипа „Включване“ - включване (Фигура 7). Ако при определени условия е необходимо изпълнението на допълнителна функция, тогава ще използваме връзката "Зависимост" със стереотипа "Разширяване" - разширение. Всичко се запомня много лесно: „Включи“ – ВИНАГИ, а „Разшири“ – ПОНЯКОГА.

Фигура 7. Използване на типа връзка "Зависимост (включване)"

В резултат нашата диаграма ще изглежда така (Фигура 8).

Фигура 8. Диаграма на случаи на използване (функционален модел на AS)

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

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