"איין טאָג אין דעם לעבן פון אַ וועווערקע" אָדער פֿון פּראָצעס מאָדעלינג צו די פּלאַן פון אַן אָטאַמייטיד עשירות אַקאַונטינג סיסטעם "בעלקאַ-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)
א צאַמען וועווערקע וואוינט דאָרט, (אַ 1)
יאָ, וואָס אַ פּאַסירונג! (א1)
די וועווערקע זינגט לידער, (P1, A1)
יאָ, ער האלט ניבבלינג אויף ניסלעך, (פּ2)
אָבער ניסלעך זענען נישט פּשוט, (C1)
אַלע שעלז זענען גילדענע, (C2)
די האַרץ איז ריין שמאַראַגד; (C3)
קנעכט היטן די וועווערקע, (פּ3, אַ2)
זיי דינען איר ווי פאַרשידן קנעכט (פּ4)
און אַ באַאַמטער איז געווען אַסיינד (A3)
א שטרענגע חשבון פון ניסלעך איז די נייעס; (P5, C1)
די אַרמיי באַגריסן איר; (פּ6, אַ4)
א מאַטבייע איז אויסגעגאסן פון די שעלז, (P7, C2, C4)
לאָזן זיי גיין אַרום די וועלט; (פּ8)
גירלס גיסן שמאַראַגד (P9, A5, C3)
אַרײַן אין די לאַגערן, און אונטער דעק; (E10, E11)
...
(А.С.Пушкина "Сказка о царе Салтане, о сыне его славном и могучем богатыре князе Гвидоне Салтановиче и о прекрасной царевне Лебеди", — 10 лет от замысла до публикации, между прочим!)
Немного о кодах, которые написаны справа от строк. “A” (от “Actor”) означает, что в строке содержится информация об участнике процесса. “C” (от “Class”) – информация об объектах классов, которые обрабатываются в ходе выполнения процессов. “E” (от “Environment”) – информация об объектах классов, которые характеризуют окружающую среду выполнения процессов. “P” (от “Process”) – информация о самих процессах.
Кстати, точное определение процесса также претендует на то, чтобы стать причиной методологических споров, хотя бы вследствие того, что процессы бывают разные: бизнес-, производственные, технологические и т.д. и т.п. (ознакомится можно, например, [4] און [5]). Чтобы избежать полемики договоримся, что процесс нас интересует с точки зрения его повторяемости во времени и потребности в автоматизации, т.е. перекладывании выполнения какой-либо части операций процесса на автоматизированную систему.
Заметки по применению диаграммы Activity
Приступим к моделированию нашего процесса и воспользуемся для этого диаграммой Activity. Для начала поясню, как указанные выше коды будут использоваться в модели. Объяснять проще на графическом примере, а заодно разберем некоторые (почти все из необходимых нам) элементы диаграммы Activity.
Проанализируем следующий фрагмент:
...
די וועווערקע זינגט לידער, (P1, A1)
יאָ, ער האלט ניבבלינג אויף ניסלעך, (פּ2)
אָבער ניסלעך זענען נישט פּשוט, (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. אַקטיוויטעט דיאַגראַמע - אַלגעמיין מיינונג פון דעם פּראָצעס
Т.к. в стихотворных строках некоторые детали процесса опущены, пришлось их восстановить, они показаны элементами с белым фоном. Данные детали включают шаг «Передачи/приема на хранение и переработку» и несколько входных и выходных артефактов. Стоит отметить, что этот шаг тоже не полностью раскрывает процесс, т.к. нам нужно было бы отдельно обозначить шаг передачи и шаг приема, да еще и для скорлупок добавить отдельный шаг, а еще домыслить, что сначала все эти материальные ценности должны где-то временно храниться и т.д. и т.п.
Еще обратим внимание, что остался пока без ответа вопрос о происхождении орехов – откуда они берутся и как попадают к белке? И этот вопрос (он выделен красным цветом шрифта в примечании – элемент 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 אויף רעגיסטראַציע און אַוועקלייגן פון אַ ווערק פון אינטעלעקטואַל טעטיקייט. Alfimov R.V., Zolotukhina E.B., Krasnikova S.A. מאַנוסקריפּט פון אַ לערנען הילף ענטייטאַלד "מאָדעלינג אַ ונטערטעניק שטח ניצן ענטערפּרייז אַרטשיטעקט" // 2011.
- זאָלאָטוכינאַ ע.ב., ווישניא א.ס., קראסניקאָוואַ ס.א. געשעפט פּראָצעס מאָדעלינג. — מ.: COURSE, SIC INFRA-M, EBS Znanium.com. — 2017.
מקור: www.habr.com