UML: обзор основных типов диаграмм, диаграмма Классов. Часть 1
Хабр, привет!
Меня зовут Витя, я работаю системным аналитиком, а также пишу про системный анализ у себя в Telegram канале, сегодня хочу рассказать про такой обязательный навык аналитиков, как проектирование процессов. Думаю, что каждый, кто будет работать на позиции системного/бизнес аналитика, рано или поздно столкнется с такой задачей.
Существует много различных языков моделирования процессов, но сегодня мы остановимся на UML. Прочитав первую статью из серии статей про моделирование процессов вы узнаете:
Что такое UML и зачем его нужно использовать
Какие типы диаграмм существуют в UML
Подробно узнаете как моделировать процессы с помощью диаграммы классов
Что такое UML?
UML (Unified Modeling Language — унифицированный язык моделирования) — язык графического описания для объектного моделирования в области разработки программного обеспечения, его также используют для моделирования бизнес-процессов, системного моделирования и отображения организационных структур.
А зачем нам UML? Может придумаем свой язык моделирования ?
Представьте себе такую ситуацию: аналитик Вася занялся разработкой технической документации по новому проекту, он использует для описания процессов свои собственно-придуманные диаграммы.
После составления документации Вася презентует результаты разработчику Коле, но Коля ничего не понимают в написанном. Васе приходится объяснять то, что он нарисовал в своей документации и тратить на это много времени.
А что, если у нас не один разработчик, а 10? Или 100?
В таком случае нам нужен универсальный язык моделирования, который будут понимать все участники процесса разработки программного обеспечения. Таким универсальным языком выступает UML, то есть UML — это некий стандарт для описания различных процессов. Его используют разработчики, аналитики, архитектор, с его помощью можно понятно доносить мысли и общаться между собой. Такой подход с использованием универсального языка значительно сократит время коммуникаций между сотрудниками и уменьшит время для поставки конечного продукта пользователю.
Плюсы UML:
Упрощает сложности при разработке ПО
Автоматизирует производство программного обеспечения и процессов
Помогает решить постоянные проблемы с архитектурой
Улучшает качество работы
Сокращает затраты и время выхода на рынок
Минусы UML:
Виды диаграмм в UML
Итак, приступим к изучению и обзору диаграмм UML. Все UML диаграммы по своей сущности делятся на два вида:
Структурные диаграммы — описывают структуру сложных объектов и систем, показывают статическую структуру системы и ее частей на разных уровнях абстракции и реализации, а также их взаимосвязь
Диаграммы поведения — иллюстрируют взаимодействие с системой и процесс её работы, основное внимание здесь уделяется динамическим аспектам системы программного обеспечения или процесса
К структурным диаграммам относят следующие 7 типов диаграмм:
Диаграмма составной структуры
Диаграмма развертывания
Диаграмма пакетов
Диаграмма профилей
Диаграмма классов
Диаграмма объектов
Диаграмма компонентов
А к диаграммам поведения относят следующие типы диаграмм:
Диаграмма деятельности
Диаграмма прецедентов
Диаграмма состояний
Диаграмма последовательности
Диаграмма коммуникаций
Диаграмма обзора взаимодействия
Временная диаграмма
Ниже на рисунке приведена иллюстрация структуры языка UML:
Рисунок 1. Структура языка UML
Предлагаю сегодня остановиться на диаграмме классов и подробно рассмотреть данный тип диаграмм. Остальные типы диаграмм будут рассмотрены в последующих сериях статей.
Диаграмма классов
Диаграмма классов описывает типы объектов системы и различного рода статические отношения, которые существуют между ними. На диаграммах классов отображаются свойства классов, операции классов и ограничения, которые накладываются на связи между объектами.
На рисунке ниже изображена модель класса обработки заказов клиентов. Прямоугольники на диаграмме представляют классы и разделены на три части: имя класса (жирный шрифт), его атрибуты и его операции. На рисунке также показаны два вида связей между классами: ассоциации и обобщения.
Рисунок 2. Пример использования диаграммы классов
Свойства
Свойства представляют структурную функциональность класса. Можно рассматривать свойства как поля класса. Свойства представляют единое понятие, воплощающееся в двух совершенно различных сущностях: в атрибутах и в ассоциациях. Хотя на диаграмме они выглядят совершенно по разному, в действительности это одно и то же.
Атрибуты
Атрибут описывает свойство в виде строки текста внутри прямоугольника класса.
Полная форма атрибута: видимость имя: тип кратность = значение по умолчанию {строка свойств}
Например: имя: String [1] = "Без имени" {readOnly}
Обязательно указывать только имя.
Рассмотрим основные сущности атрибута :
Метка видимость обозначает, относится ли атрибут к открытым (+) (public) или к закрытым () (private).
Имя атрибута — способ ссылки класса на атрибут — приблизительно соответствует имени поля в языке программирования.
Тип атрибута накладывает ограничение на вид объекта, который может быть размещен в атрибуте. Можно считать его аналогом типа поля в языке программирования.
Кратность — данное понятие будет рассмотрено ниже.
Значение по умолчанию представляет собой значение для вновь создаваемых объектов, если атрибут не определен в процессе создания.
Элемент {строка свойств} позволяет указывать дополнительные свойства атрибута. В примере он равен {readOnly}, то есть клиенты не могут изменять атрибут. Если он пропущен, то, как правило, атрибут можно модифицировать.
Ассоциации
Другая сущность свойства — это ассоциация. Значительная часть информации, которую можно указать в атрибуте, появляется в ассоциации. На рисунках 3 и 4 ниже показаны одни и те же свойства, представленные в различных обозначениях.
Рисунок 3. Представление свойств заказа в виде атрибутов
Рисунок 4. Представление свойств заказа в виде ассоциаций
Ассоциация — это непрерывная линия между двумя классами, направленная от исходного класса к целевому классу. Имя свойства (вместес кратностью) располагается на целевом конце ассоциации. Целевой конец ассоциации указывает на класс, который является типом свойства.
Естественно, возникает вопрос: «Когда следует выбирать то или иное представление?». Как правило, при помощи атрибутов обозначают небольшие элементы, такие как даты или логические значения, а ассоциации для более значимых классов, таких как клиенты или заказы.
Двунаправленные ассоциации
Двунаправленная ассоциация — это пара свойств, связанных в противоположных направлениях. Класс Car (Автомобиль) имеет свойство owner: Person[1], а класс Person (Личность) имеет свойство cars: Car[*].
Рисунок 5. Двунаправленная ассоциация
Обратная связь между ними подразумевает, что если вы следуете обоим свойствам, то должны вернуться обратно к множеству, содержащему вашу исходную точку. Например, если мы начинаем с конкретной модели Ford, находим ее владельца, а затем смотрим на множество принадлежащих ему машин, то оно должно включать модель Ford, с которой мы начал.
Кратность
Кратность свойства обозначает количество объектов, которые могут заполнять данное свойство. Чаще всего встречаются следующие кратности:
1 (Заказ может представить только один клиент)
0…1 (Корпоративный клиент может иметь, а может и не иметь единственного торгового представителя.)
* (Клиент не обязан размещать заказ, и количество заказов не ограничено. Он может разместить ноль или более заказов.)
Операции
Операции представляют собой действия, реализуемые некоторым классом. Существует очевидное соответствие между операциями и методами класса. Обычно термины операция и метод употребляются как взаимозаменяемые, однако иногда полезно их различать.
Полный синтаксис операций в языке UML выглядит следующим образом:
видимость имя (список параметров) : возвращаемый тип {строка свойств}
Рассмотрим основные сущности операции:
Метка видимости, как и в атрибутах, обозначает, относится ли операция к открытым (+)(public) или к закрытым () (private)
Имя — это название операции.
Список параметров — список параметров операции.
Возвращаемый тип — тип возвращаемого значения, если таковое есть.
Строка свойств — значения свойств, которые применяются к данной операции.
Например, в счете операция может выглядеть так:
+ balanceOn (date: Date) : Money
Обобщение
Обобщение объединяет несколько подклассов в один класс. Так, в нашем примере обобщение объединяет индивидуального и корпоративного клиентов некоторой бизнес системы. Несмотря на определенные различия, у них много общего. Одинаковые свойства можно поместить в базовый класс Customer (Клиент), при этом класс Personal Customer (Индивидуальный клиент) и класс Corporate Customer (Корпоративный клиент) будут выступать как подтипы.
С точки зрения программного обеспечения очевидная интерпретация наследования выглядит следующим образом: Корпоративный клиент является подклассом класса Клиент. В основных объектно-ориентированных языках подкласс наследует всю функциональность суперкласса и может переопределять любые методы суперкласса.
Примечания и комментарии
Примечания — это комментарии на диаграммах. Примечания могут существовать сами по себе или быть связаны пунктирной линией с элементами, которые они комментируют. Они могут присутствовать на диаграммах любого типа.
Рисунок 6. Пример использования примечаний
Советы применения диаграммы классов
Итак, мы рассмотрели основные диаграммы UML и подробно диаграмму классов. Хочу закончить мою первую статью цитатами из книги Мартина Фаулера «Основы UML». В главе про моделировании процессов с помощью диаграммы классов Мартин даёт следующие советы:
1. Не пытайтесь задействовать сразу все доступные понятия. Начните с самых простых, описанных в этой главе: классов, ассоциаций, атрибутов, обобщений и ограничений.
2. Я пришел к выводу, что концептуальные диаграммы классов очень полезны при изучении делового языка. Чтобы при этом все получалось, необходимо всячески избегать обсуждения программного обеспечения и применять очень простые обозначения.
3. Не надо строить модели для всего на свете, вместо этого следует сконцентрироваться на ключевых аспектах. Лучше создать мало диаграмм, которые постоянно применяются в работе и отражают все внесенные изменения, чем иметь дело с большим количеством забытых и устаревших моделей.
Самая большая опасность, связанная с диаграммами классов, заключается в том, что вы можете сосредоточиться исключительно на структуре и забыть о поведении. Поэтому, рисуя диаграммы классов для того, чтобы разобраться в программном обеспечении, используйте какие либо формы анализа поведения. Если вы применяете эти методы поочередно, значит, вы двигаетесь в верном направлении.
Спасибо всем, кто дочитал эту статью до конца. Делитесь своим мнением в комментариях. В следующей статье я продолжу тему моделирование процессов в UML и расскажу про новые типы диаграмм UML.
