Хабр, привет!
Меня зовут Витя, я работаю системным аналитиком, а также пишу про системный анализ у себя в Telegram канале, сегодня хочу рассказать про такой обязательный навык аналитиков, как проектирование процессов. Думаю, что каждый, кто будет работать на позиции системного/бизнес аналитика, рано или поздно столкнется с такой задачей.

Существует много различных языков моделирования процессов, но сегодня мы остановимся на UML. Прочитав первую статью из серии статей про моделирование процессов вы узнаете:

• Что такое UML и зачем его нужно использовать

• Какие типы диаграмм существуют в UML

• Подробно узнаете как моделировать процессы с помощью диаграммы классов

Что такое UML ?

UML (Unified Modeling Language — унифицированный язык моделирования) - язык графического описания для объектного моделирования в области разработки программного обеспечения, его также используют для моделирования бизнес-процессов, системного моделирования и отображения организационных структур.

А зачем нам UML ? Может придумаем свой язык моделирования ?

Представьте себе такую ситуацию: аналитик Вася занялся разработкой технической документации по новому проекту, он использует для описания процессов свои собственно-придуманные диаграммы.

После составления документации Вася презентует результаты разработчику Коле, но Коля ничего не понимают в написанном. Васе приходится объяснять то, что он нарисовал в своей документации и тратить на это много времени.

А что, если у нас не один разработчик, а 10 ? Или 100 ?

В таком случае нам нужен универсальный язык моделирования, который будут понимать все участники процесса разработки программного обеспечения. Таким универсальным языком выступает UML, то есть UML - это некий стандарт для описания различных процессов. Его используют разработчики, аналитики, архитектор, с его помощью можно понятно доносить мысли и общаться между собой. Такой подход с использованием универсального языка значительно сократит время коммуникаций между сотрудниками и уменьшит время для поставки конечного продукта пользователю.

Плюсы UML:

• Упрощает сложности при разработке ПО

• Автоматизирует производство программного обеспечения и процессов  

• Помогает решить постоянные проблемы с архитектурой 

• Улучшает качество работы 

• Сокращает затраты и время выхода на рынок 

Минусы UML:

• трата времени на составление диаграмм :)

• необходимо знать различные диаграммы и их нотации

Виды диаграмм в UML

Итак, приступим к изучению и обзору диаграмм UML. Все UML диаграммы по своей сущности делятся на два вида:

1. Структурные диаграммы - описывают структуру сложных объектов и систем, показывают статическую структуру системы и ее частей на разных уровнях абстракции и реализации, а также их взаимосвязь

2. Диаграммы поведения - иллюстрируют взаимодействие с системой и процесс её работы, основное внимание здесь уделяется динамическим аспектам системы программного обеспечения или процесса

К структурным диаграммам относят следующие 7 типов диаграмм:

• Диаграмма составной структуры

• Диаграмма развертывания

• Диаграмма пакетов

• Диаграмма профилей

• Диаграмма классов

• Диаграмма объектов

• Диаграмма компонентов

А к диаграммам поведения относят следующие типы диаграмм:

• Диаграмма деятельности

• Диаграмма прецедентов

• Диаграмма состояний

• Диаграмма последовательности

• Диаграмма коммуникаций

• Диаграмма обзора взаимодействия

• Временная диаграмма

Ниже на рисунке приведена иллюстрация структуры языка UML:

Предлагаю сегодня остановиться на диаграмме классов и подробно рассмотреть данный тип диаграмм. Остальные типы диаграмм будут рассмотрены в последующих сериях статей.

Диаграмма классов

Диаграмма классов описывает типы объектов системы и различного рода статические отношения, которые существуют между ними. На диаграммах классов отображаются свойства классов, операции классов и ограничения, которые накладываются на связи между объектами.

На рисунке ниже изображена модель класса обработки заказов клиентов. Прямоугольники на диаграмме представляют классы и разделены на три части: имя класса (жирный шрифт), его атрибуты и его операции. На рисунке также показаны два вида связей между классами: ассоциации и обобщения.

Свойства

Свойства представляют структурную функциональность класса. Можно рассматривать свойства как поля класса. Свойства представляют единое понятие, воплощающееся в двух совершенно различных сущностях: в атрибутах и в ассоциациях. Хотя на диаграмме они выглядят совершенно по разному, в действительности это одно и то же.

Атрибуты

Атрибут описывает свойство в виде строки текста внутри прямоугольника класса.
Полная форма атрибута:
видимость имя: тип кратность = значение по умолчанию {строка свойств}

Например:
имя: String [1] = "Без имени" {readOnly}

Обязательно указывать только имя.

Рассмотрим основные сущности атрибута :

• Метка видимость обозначает, относится ли атрибут к открытым (+) (public) или к закрытым ( ) (private).

• Имя атрибута – способ ссылки класса на атрибут – приблизительно соответствует имени поля в языке программирования.

• Тип атрибута накладывает ограничение на вид объекта, который может быть размещен в атрибуте. Можно считать его аналогом типа поля в языке программирования.

• Кратность - данное понятие будет рассмотрено ниже.

• Значение по умолчанию представляет собой значение для вновь создаваемых объектов, если атрибут не определен в процессе создания.

• Элемент {строка свойств} позволяет указывать дополнительные свойства атрибута. В примере он равен {readOnly}, то есть клиенты не могут изменять атрибут. Если он пропущен, то, как правило, атрибут можно модифицировать.

Ассоциации

Другая сущность свойства – это ассоциация. Значительная часть информации, которую можно указать в атрибуте, появляется в ассоциации. На рисунках 3 и 4 ниже показаны одни и те же свойства, представленные в различных обозначениях.

Ассоциация – это непрерывная линия между двумя классами, направленная от исходного класса к целевому классу. Имя свойства (вместес кратностью) располагается на целевом конце ассоциации. Целевой конец ассоциации указывает на класс, который является типом свойства.

Естественно, возникает вопрос: «Когда следует выбирать то или иное представление?». Как правило, при помощи атрибутов обозначают небольшие элементы, такие как даты или логические значения, а ассоциации для более значимых классов, таких как клиенты или заказы.

Двунаправленные ассоциации

Двунаправленная ассоциация – это пара свойств, связанных в противоположных направлениях. Класс Car (Автомобиль) имеет свойство owner:Person[1], а класс Person (Личность) имеет свойство cars:Car[*].

Обратная связь между ними подразумевает, что если вы следуете обоим свойствам, то должны вернуться обратно к множеству, содержащему вашу исходную точку. Например, если мы начинаем с конкретной модели Ford, находим ее владельца, а затем смотрим на множество принадлежащих ему машин, то оно должно включать модель Ford,с которой мы начал.

Кратность

Кратность свойства обозначает количество объектов, которые могут заполнять данное свойство. Чаще всего встречаются следующие кратности:

• 1 (Заказ может представить только один клиент)

• 0..1 (Корпоративный клиент может иметь, а может и не иметь единственного торгового представителя.)

• * (Клиент не обязан размещать заказ, и количество заказов не ограничено. Он может разместить ноль или более заказов.)

Операции

Операции представляют собой действия, реализуемые некоторым классом. Существует очевидное соответствие между операциями и методами класса. Обычно термины операция и метод употребляются как взаимозаменяемые, однако иногда полезно их различать.

Полный синтаксис операций в языке UML выглядит следующим образом:

видимость имя (список параметров) : возвращаемый тип {строка свойств}

Рассмотрим основные сущности операции:

• Метка видимости, как и в атрибутах, обозначает, относится ли операция к открытым (+)(public) или к закрытым ( ) (private)

• Имя – это название операции.

• Список параметров – список параметров операции.

• Возвращаемый тип – тип возвращаемого значения, если таковое есть.

• Строка свойств – значения свойств, которые применяются к данной операции.

Например, в счете операция может выглядеть так:

+ balanceOn (date: Date) : Money

Обобщение

Обобщение объединяет несколько подклассов в один класс. Так, в нашем примере обобщение объединяет индивидуального и корпоративного клиентов некоторой бизнес системы. Несмотря на определенные различия, у них много общего. Одинаковые свойства можно поместить в базовый класс Customer (Клиент), при этом класс Personal Customer (Индивидуальный клиент) и класс Corporate Customer (Корпоративный клиент) будут выступать как подтипы.

С точки зрения программного обеспечения очевидная интерпретация наследования выглядит следующим образом: Корпоративный клиент является подклассом класса Клиент. В основных объектно-ориентированных языках подкласс наследует всю функциональность суперкласса и может переопределять любые методы суперкласса.

Примечания и комментарии

Примечания – это комментарии на диаграммах. Примечания могут существовать сами по себе или быть связаны пунктирной линией с элементами, которые они комментируют. Они могут присутствовать на диаграммах любого типа.

Советы применения диаграммы классов

Итак, мы рассмотрели основные диаграммы UML и подробно диаграмму классов. Хочу закончить мою первую статью цитатами из книги Мартина Фаулера "Основы UML". В главе про моделировании процессов с помощью диаграммы классов Мартин даёт следующие советы:

1. Не пытайтесь задействовать сразу все доступные понятия. Начните с самых простых, описанных в этой главе: классов, ассоциаций, атрибутов, обобщений и ограничений.

2. Я пришел к выводу, что концептуальные диаграммы классов очень полезны при изучении делового языка. Чтобы при этом все получалось, необходимо всячески избегать обсуждения программного обеспечения и применять очень простые обозначения.

3. Не надо строить модели для всего на свете, вместо этого следует сконцентрироваться на ключевых аспектах. Лучше создать мало диаграмм, которые постоянно применяются в работе и отражают все внесенные изменения, чем иметь дело с большим количеством забытых и устаревших моделей.

Самая большая опасность, связанная с диаграммами классов, заключается в том, что вы можете сосредоточиться исключительно на структуре и забыть о поведении. Поэтому, рисуя диаграммы классов для того, чтобы разобраться в программном обеспечении, используйте какие либо формы анализа поведения. Если вы применяете эти методы поочередно, значит, вы двигаетесь в верном направлении.

Спасибо всем, кто дочитал эту статью до конца. Делитесь своим мнением в комментариях. В следующей статье я продолжу тему моделирование процессов в UML и расскажу про новые типы диаграмм UML.