В этом цикле (5-6 заметок) мы поговорим о диаграммах и UML-диаграммах в частности. Просто, нескучно и без лишней воды. Начнем с общего обзора — популярные “языки” моделирования, UML как один из них и на кой он вообще нужен — после чего разберем UML-диаграммы, популярные у аналитиков и в преломлении для аналитиков. Для выпускников нашего курса по бизнес-анализу материал будет, в основном, не нов, но я постараюсь добавить сюда всякого, чтобы каждый нашел для себя новое и интересное.
Итак, большинство аналитиков рисуют диаграммы (”строят модели”). Не хочется душнить о том, зачем мы это делаем (или ”цели визуального моделирования”, если по-академичному), но вот и вот, почему не стоит игнорировать визуальную составляющую. Плюс для многих рисование диаграммок — отдушина, позволяющая не закиснуть в клепании однотипных требований.
Есть разные нотации моделирования. Нотация — это язык. Придуманный когда-то кем-то и в котором заложены правила вида “эти штуки показывай прямоугольником/ромбом/слоненком”, “слоненки могут быть соединены между собой только штрихпунктирной стрелочкой, и означает это то-то”, “такую стрелку рисовать нельзя, дабы не попасть, ибо не кошерно” и пр. Многие аналитики плюют на нотации и рисуют ad hoc: фантазируют на лету, подстраиваясь под задачу в моменте. И это отличный рабочий вариант. Но попробую все же защитить смысл инвестироваться хотя бы в наиболее популярные нотации:
- Нотация повышает вероятность того, что вас верно поймут (команда, заказчик и его люди, другие аналитики). Да, для этого нужно довольно редкое комбо: чтобы получатели в этом ориентировались, а вы умели правильно и понятно рисовать. Но такие ситуации бывают, пусть и нечасто.
- Нотации, скорее всего, уже изобрели тот велосипед, который вы пытаетесь собрать. Стоит ли тратить время и силы, если уже есть рабочие и не раз доработанные умными людьми инструменты? От нотации всегда можно отойти, если есть нужда. То есть я все же призываю осмыслить вариант “сначала я вспомню/поищу, есть ли уже что-то подходящее под мою задачу, и только потом буду это кастомизировать, если сочту, что оно нечитаемо для получателей или мне не хватает средств показать нужное”.
- Нотации сильно повысят вашу “начитанность” в области визуализации. Если вы, например, изучите хоть немного упомянутые ниже нотации, то в сравнении с человеком, который ни разу в жизни не сталкивался с ними, вы будете а) рисовать больше (зная, чем и как разные диаграммы могут помочь, и активно пользуя это на практике), б) визуализировать и по итогу прорабатывать требования правильнее (не перегружая читателей лишним, допуская меньше ошибок, упуская меньше пробелов и т. п.). Например, вы не будете делать вот так:
- Блеснуть пониманием нотации вполне может результироваться в то, что получатели респектнут вам за знания и скиллы. На фоне тренда упрощения рабочих техник заказчик из серьезной индустрии может неслабо так оценить ваше погружение в профессиональные инструменты. А еще они частенько фигурируют в вакансиях, и оценить кругозор в этом также любят и интервьюеры.
Нотации, которые на слуху, плюс мои общие рекомендации по ним (не считая случаев, когда вам по долгу службы показано иное):
Есть и более точечные узкопрофильные “нотации” (позволяющие рисовать, например, один вид диаграмм), хотя тут уже сложно сказать, называть ли их этим серьезным словом: Flowcharts, Crow’s Foot, DFD (Data Flow Diagrams) и пр. — в них могу выделить только DFD, под грифом “у нее нет прямой замены в популярных нотациях, а потому читаните статейку-две и посмотрите, отзывается ли”.
- UML (Unified Modeling Language) — наиболее популярная нотация графического моделирования, когда дело касается IT-систем. Много видов диаграмм на разные случаи жизни. Полезно знать и уметь — из-за распространенности и широкой применимости, ради чего, собственно, и затеялся этот цикл.
- BPMN (Business Process Model and Notation) — популярная нотация, когда дело касается описания бизнес-процессов. Не IT-систем и их аспектов, как с UML выше, а именно процессов в организациях. Именно для этой цели стоит в ней хотя бы ориентироваться, а лучше освоить и пользовать, когда с бизнес-процессами нужно активно работать. Нотация гораздо более узка, чем UML, и фактически там только один вид диаграмм (хоть и формально их 4). Да, есть и в UML диаграммы, подходящие, чтобы описать процесс любого вида, плюс BPMN также никто не мешает применять вместо некоторых диаграмм UML. Но как минимум применяя правильный инструмент в нужной ситуации вы будете выглядеть чуточку профессиональнее. Тем более, для уровня “нарисовать и обсудить” ничего сложного там нет.
- IDEF (Integration Definition) — как и UML, это набор диаграмм на множество разных ситуаций. Весьма узкоприменимая нотация (aka непопулярная среди популярных), плюс морально устаревшая. Вам она не нужна.
Есть и более точечные узкопрофильные “нотации” (позволяющие рисовать, например, один вид диаграмм), хотя тут уже сложно сказать, называть ли их этим серьезным словом: Flowcharts, Crow’s Foot, DFD (Data Flow Diagrams) и пр. — в них могу выделить только DFD, под грифом “у нее нет прямой замены в популярных нотациях, а потому читаните статейку-две и посмотрите, отзывается ли”.
Теперь ближе к теме. Самая популярная нотация в IT-мире — UML (Unified Modeling Language). Что о ней полезно знать:
- Развивается (хотя для нынешнего ее состояния это слишком сильное слово) аж с 94-95 годов. Текущая версия на момент написания заметки — 2.5.1.
- Позиционируется как язык графического моделирования объектно-ориентированных программных систем. Т. е. 1) основной фокус — IT и программные системы в частности; 2) системы, построенные с применением объектно-ориентированного подхода (если не знакомы с тем, что это такое, shame on you не заморачивайтесь — большинство современных средств разработки основываются на этом подходе, да и не то, чтобы диаграммы от этого будут сильно зависеть в плане применимости).
- Как UML, так и BPMN (упоминаю их вместе, т. к. они поддерживаются одной организацией — Object Management Group) описаны большими, сложными и скучными спецификациями. Единственные кейсы, когда в них стоит лезть, это если корректность диаграмм в плане соответствия нотации сильно влияет на вашу работу (например, в вашей команде “скармливают” диаграммы каким-то тулам, которые строят на их базе структуру кода, базы данных и т. п.), или же если вы планируете профессионально и умно преподавать эти вещи кому-то. Для остальных случаев есть более человечные, пусть и с риском неверной интерпретации в не особо значимых моментах, гайды и обучалки. Как, например, этот цикл, ага.
- UML создавался не для аналитиков. Это инструмент для всей команды разработки, причем многое там как раз таки для разработчиков. Поэтому большинство диаграмм а) аналитику не нужны, т. к. этих аспектов разработки он не касается, б) могут оказаться сложны для понимания с наскоку, т. к. ориентированы на багаж знаний разработчика. То есть лезете вы в какой-нибудь источник, чтобы понять, как же ж там правильно рисовать, а он общается с вами, будто вы фуллстек-девелопер с 15 годами опыта — именно поэтому я пометил в начале, что мы будем рассматривать диаграммы в преломлении для аналитиков (гайдов, объясняющих их языком изначальной целевой аудитории, в Интернете и так полно).
Чтобы ориентироваться в том, какие вообще инструменты есть в тулбоксе под названием UML, давайте вкратце обо всех его диаграммах.
Во-первых, UML-диаграммы делятся на структурные (показывают какой-то статичный структурный аспект) и поведенческие (показывают динамику/поведение, т .е. изменение чего-то с течением времени).
Во-первых, UML-диаграммы делятся на структурные (показывают какой-то статичный структурный аспект) и поведенческие (показывают динамику/поведение, т .е. изменение чего-то с течением времени).
Пару слов про каждую диаграмму, дабы понимать, о чем это вообще и нужно ли это нам как аналитикам (естественно, с оттенком субъектива и определенным обобщением):
Class Diagram (Диаграмма классов) — изначально предназначалась для отображения структуры кода и базы данных ПО. По факту можно применять для отображения структуры всего, чего угодно. Аналитику нужна и полезна, т. к. с ее помощью можно строить не одну полезную модель.
Object Diagram (Диаграмма объектов) — показывает структуру объектов как экземпляров классов в какой-либо момент времени. Чтобы это осмыслить, нужно понимать основы объектно-ориентированной разработки. Или не нужно — вам эта диаграмма не пригодится.
Package Diagram (Диаграмма пакетов) — позволяет объединить элементы ваших диаграмм в пакеты и показать, как они между собой связаны. Например, объединить юз кейсы из Use Case Diagram в схожие по тематике группы, назвать их пакетами и сделать некий укрупненный взгляд на элементы ваших моделей. Вряд ли это был возбуждающий пассаж, а потому не нужна.
Component Diagram (Диаграмма компонентов) — показывает крупные компоненты ПО и то, как они между собой связаны. Если не брать в расчет системный анализ, который отчасти = разработка, то едва ли пригодится.
Composite Structure Diagram (Диаграмма композитной структуры) — показывает внутреннюю структуру классов. Не нужна.
Deployment Diagram (Диаграмма развертывания) — показывает, как компоненты системы физически будут располагаться — на серверах, устройствах, в рамках какого ПО и т. д. Аналитику изредка может пригодиться, если нужно подобное для кого-то визуализировать. Не особо это его работа, конечно, но почему бы не помочь разработчикам в этом нелегком деле.
Profile Diagram (Диаграмма профилей) — показывает профили и стереотипы в рамках вашего набора моделей. Звучит, понимаю, как что-то инопланетное, поэтому проще сразу забыть о ее существовании.
Use Case Diagram (Диаграмма вариантов использования) — визуализирует набор юз кейсов, добавляя отношения между ними и их актерами. Если вы пользуете технику юз кейсов, то диаграмма нужна и полезна.
Activity Diagram (Диаграмма деятельности, диаграмма активностей) — основная поведенческая диаграмма и показывает она базовые параметры любого процесса – шаги, участников и ветвления. Полезна, причем можно применять не только для процессов, связанных с ПО (именно она является “конкурентом” BPMN и заменителем flowcharts/блок-схем).
State Machine Diagram (Диаграмма состояний) — показывает смену состояний какого-либо объекта в течение его жизни. Весьма клевая и нужная штука в ряде ситуаций.
Есть еще ряд диаграмм, объединенных в подкатегорию “Диаграммы взаимодействия” — упор в них сделан на взаимодействие между объектами.
Sequence Diagram (Диаграмма последовательности) — показывает, по сути, то же самое, что и Activity Diagram, но с акцентом на взаимодействие между участниками. Иногда полезный взгляд, а потому скорее нужна.
Communication Diagram (Диаграмма коммуникации) — показывает, как, в общем и целом (в отличие от предыдущей диаграммы, где все детально и подробно), между собой коммуницируют некие объекты. Не нужна.
Timing Diagram (в душе не ведаю, как это будет по-русски — не видел в источниках с оттенком официальности) — показывает взаимодействия между объектами с упором на их распределение во времени. Не нужна.
Interaction Overview Diagram (Диаграмма обзора взаимодействия) — комбинация activity и sequence: шаги процесса и обмены сообщениями между участниками. Не нужна.
Class Diagram (Диаграмма классов) — изначально предназначалась для отображения структуры кода и базы данных ПО. По факту можно применять для отображения структуры всего, чего угодно. Аналитику нужна и полезна, т. к. с ее помощью можно строить не одну полезную модель.
Object Diagram (Диаграмма объектов) — показывает структуру объектов как экземпляров классов в какой-либо момент времени. Чтобы это осмыслить, нужно понимать основы объектно-ориентированной разработки. Или не нужно — вам эта диаграмма не пригодится.
Package Diagram (Диаграмма пакетов) — позволяет объединить элементы ваших диаграмм в пакеты и показать, как они между собой связаны. Например, объединить юз кейсы из Use Case Diagram в схожие по тематике группы, назвать их пакетами и сделать некий укрупненный взгляд на элементы ваших моделей. Вряд ли это был возбуждающий пассаж, а потому не нужна.
Component Diagram (Диаграмма компонентов) — показывает крупные компоненты ПО и то, как они между собой связаны. Если не брать в расчет системный анализ, который отчасти = разработка, то едва ли пригодится.
Composite Structure Diagram (Диаграмма композитной структуры) — показывает внутреннюю структуру классов. Не нужна.
Deployment Diagram (Диаграмма развертывания) — показывает, как компоненты системы физически будут располагаться — на серверах, устройствах, в рамках какого ПО и т. д. Аналитику изредка может пригодиться, если нужно подобное для кого-то визуализировать. Не особо это его работа, конечно, но почему бы не помочь разработчикам в этом нелегком деле.
Profile Diagram (Диаграмма профилей) — показывает профили и стереотипы в рамках вашего набора моделей. Звучит, понимаю, как что-то инопланетное, поэтому проще сразу забыть о ее существовании.
Use Case Diagram (Диаграмма вариантов использования) — визуализирует набор юз кейсов, добавляя отношения между ними и их актерами. Если вы пользуете технику юз кейсов, то диаграмма нужна и полезна.
Activity Diagram (Диаграмма деятельности, диаграмма активностей) — основная поведенческая диаграмма и показывает она базовые параметры любого процесса – шаги, участников и ветвления. Полезна, причем можно применять не только для процессов, связанных с ПО (именно она является “конкурентом” BPMN и заменителем flowcharts/блок-схем).
State Machine Diagram (Диаграмма состояний) — показывает смену состояний какого-либо объекта в течение его жизни. Весьма клевая и нужная штука в ряде ситуаций.
Есть еще ряд диаграмм, объединенных в подкатегорию “Диаграммы взаимодействия” — упор в них сделан на взаимодействие между объектами.
Sequence Diagram (Диаграмма последовательности) — показывает, по сути, то же самое, что и Activity Diagram, но с акцентом на взаимодействие между участниками. Иногда полезный взгляд, а потому скорее нужна.
Communication Diagram (Диаграмма коммуникации) — показывает, как, в общем и целом (в отличие от предыдущей диаграммы, где все детально и подробно), между собой коммуницируют некие объекты. Не нужна.
Timing Diagram (в душе не ведаю, как это будет по-русски — не видел в источниках с оттенком официальности) — показывает взаимодействия между объектами с упором на их распределение во времени. Не нужна.
Interaction Overview Diagram (Диаграмма обзора взаимодействия) — комбинация activity и sequence: шаги процесса и обмены сообщениями между участниками. Не нужна.
Теперь о строительных блоках UML. UML – по определению язык, и у него есть алфавит, который является общим для всех диаграмм (при этом некоторые “буквы” этого алфавита специфичны для отдельных диаграмм):
- Элементы — ключевые строительные блоки любой диаграммы. Например, диаграмма структуры UML-диаграмм выше — это UML Class Diagram (сломал мозх, да?). И все элементы на ней — это Классы (Class). Кстати, чуть позже узнаете, почему некоторые из них написаны курсивом.
- Связи — то, что связывает элементы между собой и показывает отношения между ними. Кстати, чуть позже узнаете, почему на диаграмме все они заканчиваются полым треугольником, а также почему одни сливаются, а другие — нет.
- Стереотипы. Знать о них не обязательно, но будете выглядеть очень умными. Стереотипы — это способ расширения языка UML. Т. е. помимо стандартных элементов и связей, которые есть в UML, вы можете добавить свои, какие угодно. Это не особо рекомендуется, т. к. суть нотации в том, чтобы все шарили единое видение (а как только вы добавляете свою семантику, смысловое наполнение, вы отходите от единых правил и по умолчанию понимаемых вещей). Но если сильно хочется, то вот механизм. Стереотип — это надпись в двойных угловых скобках около элемента или связи, которая придает им новое значение:
Что у нас будет дальше? В следующих заметках мы рассмотрим полезные для аналитика UML-диаграммы (те, который желтеньким на схеме и в тексте, если еще не догадались), и для каждой я опишу следующие вещи (напоминаю, что каждый пункт будет идти в значении "для IT бизнес-аналитика"):
- В каких ситуациях диаграмму удобно/полезно использовать
- Элементы (как те, которые вы будете пользовать часто, так и более редкие, для "продвинутого" моделирования)
- Связи (частые и редкие)
- Логику построения на примере
- Советы из личной практики
- Типовые ошибки и как их избежать
