Про UML я писал много, и периодически получаю вопросы из ряда “А нужен ли современному гибкому и динамичному аналитику этот ваш юэмэль?“ И тут подумалось, что полезным будет пояснить, зачем вообще мне в работе бывают нужны диаграммы и какие именно. Плюс так, чтобы просто и с акцентом на практику.
И начнем с того, зачем IT бизнес-аналитику диаграммы. Я рекомендую вначале читануть вот эти небольшие заметки: https://t.me/itmineba/65, https://t.me/itmineba/66. Они — про силу визуализации в коммуникациях с живыми примерами. Но помимо того, что аналитику полезно визуализировать информацию для наглядной подачи другим людям, есть и иные плюсы:
- Рисовать полезно и для себя. Например, окинув взглядом данные системы в виде одной модели (где еще и связи между данными путно отрисованы), вы а) легче воспримете полную картину с высоты полета орла, б) вероятнее заметите пробелы и ошибки. Сравните с вариантом, когда вы пытаетесь “окинуть взглядом” полотно текста, пусть и структурированного.
- Диаграммы как чеклисты. Многие диаграммы за счет своих внутренних правил дают нам полезные подсказки. Например, нарисовав диаграмму какого-либо процесса и точки ветвления в ней, вы поймете, что любое ветвление подразумевает как минимум два исхода. И если у вас только один, то что-то пошло не так.
Теперь о том, нужны ли аналитику нотации моделирования. Да, действительно, в большинстве случаев польза от них туманна. Если вам по долгу службы не нужно жечь ортодоксальным юэмелем, моменты выше можно закрыть грамотными рисунками по наитию. И да, все мы кучу раз слышали, что с нотацией вероятность правильного понимания наших шедевров выше, но немногие осознают ещё пару нюансов:
а) Путь освоения нотаций нужно пройти, чтобы отсебятина стала качественной. У человека, качественно погрузившегося в изучение известных подходов к моделям, любые модели нагляднее, полнее и безошибочнее. А требования, как мы знаем, — это такая штука, небольшая ошибка или мискоммуникация в которой может привести к печали. То бишь в процессе изучения UML, BPMN, IDEF, DFD и пр. мы не столько изучаем внутренние правила этих нотаций, сколько учимся качественно и системно моделировать в принципе.
б) Багаж придуманных умными людьми техник сократит необходимость повторно изобретать корявые велосипеды. Например, я знаю, что на IT-решение можно визуально смотреть с позиции юз кейсов, архитектуры, алгоритмов, операционной среды, структуры данных, их потоков, состояний и т. п. И в нужные точки я буду изучать именно то, что считаю наиболее полезным. То есть мы получаем багаж из десятков взглядов на решение и его контекст, до которых додуматься самому порой непросто. Ну и конечно мы получаем набор готовых инструментов, которые не нужно переизобретать, чтобы заткнуть большинство рабочих ситуаций. Постигнув этот дзен, мы можем забить на UML compliancy, но диаграммы при этом будут нести теперь больше пользы, так как мы научились их правильно готовить перед тем, как экспериментировать с ингредиентами.
Теперь о том, что лично у меня прижилось в практике и почему. Я пользовал много разных нотаций и подходов (думается, что абсолютное большинство из популярных), и далеко не все завоевали место в сердечке. Далее я вкратце расскажу про ряд популярных нотаций и поясню, когда и зачем люблю их применять.
UML (Unified Modeling Language)
UML — язык для того, чтобы нарисовать что-то, относящееся к ПО (чуть более умные слова есть тут: https://shesterov.by/tpost/f5j0k327v1-uml-i-it-analitik). В UML много диаграмм, и большинство из них — для разработчиков. Но некоторые полезны и для бойцов на фронте требований.
Use Case Diagram (диаграмма вариантов использования) — это база. Самая аналитичная из всех аналитичных диаграмм. Раньше слова Use и Case (в комбинации и именно в таком порядке) ассоциировались с IT-аналитиком и только с ним. Теперь их заменяют User Stories. Тем не менее, между Use Cases и User Stories много общего, и диаграмма вполне себе огонь работает, когда:
- Для себя самого надо визуально налепить все те полезняшки, которые система несёт для юзеров и прочих внешних агентов.
- То же самое надо показать заказчику.
- Вы пользуете Use Cases как технику документирования требований, и вам нужно показать их big picture (какая fabric, какие details).
Рисуется диаграмма просто, быстро, а бенефиты выше остаются. User Story Map как основной подход к визуализации User Stories не настолько наглядна: User Stories как куски скоупа обычно детальнее и показывают более мелкие шаги пользователя, плюс карта больше акцентирует приоритеты разработки. Варианты использования же показывают все те крупные пользы, которая система будет наносить юзерам. Может, я слишком олдскулен, но эта диаграмма мне до сих пор нравится, и я вижу ценность иметь такой взгляд на требования.
О диаграмме подробно тут: https://shesterov.by/tpost/g9mg3zhpi1-uml-use-case-diagram
Class Diagram (диаграмма классов) — эта штука полезна для любого структурного моделирования. Структура отдела в плане должностей или ролей? Пожалуйста. Глоссарий терминов? Аналогично. Конечно, не всегда это лучший вариант, и диаграмма не настолько универсальна — зачастую отсебятина работает лучше, плюс в контексте структур я больше люблю mind maps.
Один из популярных вариантов применения Class Diagram — структура предметной области (бизнес-домена), чтобы аналитик прояснил и закрепил ключевые термины автоматизируемой области и отношения между ними (об этом — в первой половине этой статьи: https://shesterov.by/tpost/j9acle3jd1-model-predmetnoi-oblasti-i-logicheskaya).
Я долго и вполне успешно пользовал это, но признаюсь, что карты памяти/ментальные карты/интеллект-карты (mind maps) со временем вытеснили диаграмму классов в таком применении. Как древовидная структура, особенно клепающаяся в инструменте, где диаграммы рисуются горячими клавишами, mind maps жгут не по-детски.
Но где не уберёшь полезность Class Diagrams — это моделирование данных. Это не единственная нотация, подходящая для этой цели, но мне лично нравится больше всего. При этом, раз мы ведем речь про требования, это не схемы баз данных, а логические модели данных (или иные вариации абстракции, не доходящие до физической реализации). Детальнее об этой диаграмме и применимости к моделям данных тут: https://shesterov.by/tpost/pgu0yucas1-uml-class-diagram.
Activity Diagram (диаграмма активностей, если по-плебейски, или диаграмма деятельности, если по-научному). Там, где ранее жгли блок-схемы и flowcharts, теперь отжигает Activity Diagram как более мощная и гибкая штука. Это типовая диаграмма, которую я пользую для визуализации сложных процессов (их шагов, ветвлений, циклов и прочих алгоритмических специфик). Детальнее про эту диаграмму тут: https://shesterov.by/tpost/s30fpt0j11-uml-activity-diagram.
State Machine Diagram (диаграмма состояний или, если на высоком валирийском, диаграмма конечных автоматов) — показывает, как что-то меняет свои состояния в процессе жизни. По факту это нечто весьма похожее на Activity Diagram, но акцент не на шаги процесса, а на жизнь объекта и его состояния в процессе жизни.
Признаюсь честно: пользую нечасто, но не потому что это бесполезная фигня, а из-за весьма узкой специфики — ситуации, когда нужно показать смену состояний чего-либо (например, объекта из картины данных), возникают не так уж и часто. Тем не менее, когда они таки возникают, считаю диаграмму очень полезным инструментом, который позволяет именно с данной стороны взглянуть на моделируемый объект и зачастую найти лютое количество пробелов в требованиях и знаниях. Детальнее про эту милую модельку здесь: https://shesterov.by/tpost/n26iurdac1-uml-state-machine-diagram.
Sequence Diagram (диаграмма последовательности) — лично я не фанат пользовать сие по поводу и без, как многие аналитики, но инструмент осел в багаже. По факту этот та же процессная диаграмма, что и Activity Diagram, но с акцентом на участниках и их общении между собой, а не на алгоритме. Не то, чтобы она мне не нравится, но как-то так получается, что в моей картине бизнес-анализа моделирование с таким акцентом требуется существенно реже, чем показать алгоритмы. Но для упомянутой цели она, несомненно, наглядна. Детальнее про нее тут: https://shesterov.by/tpost/g4n39inn91-uml-sequence-diagram.
Honorable mention: Deployment Diagram (диаграмма развертывания) — редко, но пригождается, дабы показать, как софтваре располагается на хардваре.
DFD (Data Flow Diagrams)
Контекстная диаграмма в нотации DFD (DFD level 0) — это опять-таки база. Начинаю продумывать целевое решение с неё практически всегда. Для тех, кто не воспитан на Вигерсе, контекстная диаграмма показывает границы решения (но не его наполнение — в этом плане у нас остается черный ящик) и внешних субъектов (люди, аппаратные и программные системы), которые с решением напрямую взаимодействуют. Плюс, суть взаимодействий: информацию, которой эти субъекты обмениваются с решением. Очень помогает в следующем:
- Правильно очертить границы решения, а это, как ни странно, то, в чем путаются начинающие аналитики.
- Понять всех внешних агентов, которые “прилегают” к решению.
- Как стартовая точка для дальнейшей детализации картины данных: потоки данных в/из решения — это та информация, которая затем будет дорабатываться моделью данных.
DFD-диаграммы следующих уровней пользую существенно реже, но опять-таки — это инструмент в багаже. Если нужно показать потоки данных внутри системы (детализировав наш черный ящик), то порой полезно.
BPMN (Business Process Model and Notation)
BPMN, как многие знают, это нотация моделирования процессов, причем процессов из реальной жизни (ну или бизнес-процессов, если быть точным). Ну то есть это не язык, чтобы ПО как-то отрисовать — как минимум по задумке авторов. В BPMN есть 4 вида диаграмм, и в народ ушли Process Diagram и Collaboration Diagram — штуки весьма популярные и мало чем друг от друга отличающиеся (поэтому обычно говорят “рисуем BPMN-диаграмму”, не заморачиваясь с подвидами). Остальные две, кажись, вообще никому не сдались, поэтому и упоминать тут не имеет смысла.
Мне не особо по душе эта нотация в контексте типовых задач, с которыми я как IT-аналитик сталкивался. Не отрицаю, что для аналитика, активно работающего с бизнес-процессами, сие полезно, но как-то так складывается, что у IT-аналитика активное моделирование бизнес-процессов — это скорее исключение, чем правило. Плюс да, в плане рисования хода процесса (шаги, события, ветвления, участники и пр.) эта диаграмма мощнее, чем UML Activity, так как дает больше средств, но по моему опыту это оверкилл для большинства задач: аналитик скорее будет рисовать простое (flowcharts, UML Activity), а не мощное. А за счет того, что BPMN не особо прост и рисуется дольше, для многих читателей результат воспринимается хуже. Если честно, то пользую, когда нужно понтануться перед стейкхолдерами, что мы тут не зря хлебушек кушаем, или если по специфике проекта оно навязано извне. Но в целом знать, что есть диаграммы, позволяющие показать ход процесса мощнее и детальнее, чем UML Activity или блок-схемы, полезно.
IDEF (Integration Definition)
Также нотация для моделирования ПО. В целом, это устаревшая штука, успешно заменяемая UML. В университетах ее периодически усердно изучают, да и вроде как заявлено, что министерство обороны США ее любит, но практически не вижу никакого смысла становиться адептом этой секты. Там так же, как в UML, много разных видов диаграмм, но хочу отметить одну из них как уникальную и потенциально полезную в некоторых ситуациях.
IDEF0 — это моделирование функций, процессов, действий, задач — в общем того, что имеет входные данные и преобразует их в полезные выходные. И IDEF0 предлагает интересный взгляд на это, который порой полезно и на доске зарисовать. Контекстная диаграмма из IDEF0 (не путать с описанной выше контекстной диаграммой из DFD) смотрит на функцию как на черный ящик, у которого есть 4 параметра: входная информация, выходная информация, управление (то, что регулирует то, как функция работает) и механизмы (то, что выполняет функцию). И в таком преломлении это вполне себе любопытный и полезный взгляд, который быстро рисуется и подсказывает важные моменты.
Mind maps
Вот это огонь огненный — один из любимых инструментов для визуализации. Настолько любимый, что именно для таких карт у меня стоит отдельный софт, ибо диаграммы — это, как правило, вялое елозание мышкой, а майндмэпы в специализированной софтине — это куча горячих клавиш и лютая скорость.
Для чего я пользую эти карты: проектные планы (рабочие и личные), чеклисты разного плана, конспекты, базы знаний — в общем все, что удобно представляется в виде древовидной, а главное быстро и наглядно рисуемой структуры.
Кстати, один из вариантов применения mind maps для аналитиков вычленился в собственную технику: impact mapping (подробнее тут: https://shesterov.by/tpost/fzh1lezxp1-impact-map-i-user-story-map-kak-bistro-i).
По итогу, если прикинуть такой сценарий (который лично для меня показывает силу визуализации), когда под рукой есть доска и человек, которому нужно влить в мозг нечто не особо тривиальное (а значит нужно еще и порисовать вкупе со словами, дабы вливать быстрее), то что я буду рисовать:
- Если это какой-то процесс, то либо UML Activity (фокус на алгоритме), либо UML Sequence (фокус на участниках и последовательности обмена сообщениями между ними).
- Если это структура, то либо mind maps (когда дерево вполне себе работает), либо UML Class (когда лучше квадратики и связи между ними наколбасить).
- Если это что-то выходящее за рамки этих кейсов, то либо остальные упомянутые в заметке модели, либо уже пойду проявлять чудеса креативности.
Конечно, именно в таком сценарии все эти диаграммы будут сильно нарушать красоту по UML, т. к. в подобных обстоятельствах всем плевать на то, какой конец у стрелочки.
Ну а для аналитика все диаграммы, описанные выше, покроют большинство ситуаций при работе с требованиями и донесении их команде и заказчику. Главное — задуматься хоть немного над тем, поймут ли их получатели, и либо обучить оных, либо упростить сами диаграммы во имя благой цели.
