Статьи‎ > ‎

UML для программистов

Статья предназначена для разработчиков, которые ранее не сталкивались с UML, но имеют желание изучить данную нотацию. В статье приведено краткое описание, как использовать UML и дополнительно - нотацию Archimate.

Хочу использовать UML

Однажды я решил вырасти из программистов в архитекторы. Списки вакансий на сайтах о работе подсказали мне, что для роста было бы неплохо выучить UML, RUP и еще много страшных слов. Найти спецификацию на UML на просторах интернета сложности не представляет, но глядя на 15+ диаграмм этой нотации у меня возник вопрос: и что с этим делать? Недавно такой же вопрос мне задал знакомый, это и подтолкнуло меня написать статью. Если вас тоже это мучает - здесь вы найдете относительно короткий ответ.

Следующий мой шаг был - найти книгу про UML, где по шагам было бы расписано, какие диаграммы в какой последовательности делать. В руки мне попалась "UML2 и унифицированный процесс. Джим Арлоу, Айла Нейштадт", книга неплохая, на вопросы "зачем и как" ответила, а заодно немного погрузился в UP (из которого потом вырос RUP).

Оставалось только проверить все это на практике, и мне повезло - я попал на крупный проект, причем на самое его начало, когда даже требования с заказчика еще не собрали. Практика показала, что 90% спецификации UML вам никогда не понадобятся, можете даже не тратить время на изучение. Какие 10% оказались полезными - читайте ниже.

Какие диаграммы действительно нужны

Для аналитиков

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

  • перечень функций, которые выполняет система, используется диаграмма "Use case diagram", она же "Диаграмма вариантов использования";
  • описание алгоритмов для выполнения функций, используется диаграмма "Activity diagram", она же "Диаграмма деятельности".

Как разработчик, вы скорее всего эти диаграммы будете только читать, что не представляет большой сложности. Пример Use case diagram:

Диаграмма показывает не только перечень функций, но и их иерархию и зависимости. Большой полезности для разработчика она не несет, эти диаграммы обычно добавляют к текстовому описанию функций в Техническом задании. В специализированных системах UML-моделирования (Enterprise Architect, IBM Rational System Architect и др.) эти диаграммы немного упрощают навигацию (можно кликнуть по функции и провалиться в описание ее алгоритма).

Пример Activity diagram:


На диаграмме приведен алгоритм выполнения функции "Синхронизация", и даже без знания UML вы можете ее понять. Данные диаграммы также включаются в техническое задание и всегда сопровождаются текстовыми пояснениями.

Activity diagram не подходит для проектирования, так как она не показывает:

  • кто кого вызывает (касса обращается к ЦОД, или наоборот);
  • какие вызовы используются: синхронные или асинхронные.
Activity diagram строится по результатам общения аналитика и заказчика, они хорошо понимают бизнес-процесс (алгоритмы), но их не интересуют технические детали.

Для разработчиков

Диаграммы необходимы в двух случаях:

  • спроектировать систему;
  • разобраться в чужой системе.

Нотация UML содержит большое количество диаграмм, которые призваны решить оба вопроса, но по факту почти никто ими не пользуется. Почему? Они избыточны, и у разработчиков стабильно не хватает времени. Разберемся подробнее.

Спроектируем приложение "Касса". Очевидно, что у нас будут пакеты библиотек:

  • для работы с торговым оборудованием;
  • для связи с ЦОД;
  • для работы с базой;
  • common для общих функций;
  • и т.д.

После того, как мы составили этот список на бумажке и создали в проекте соответствующие каталоги, будем ли мы рисовать Component diagram? Нет, т.к. и без нее все очевидно. Мне приходилось анализировать большое количество чужого кода в посторонних проектах, и именно структура каталогов + корректные имена файлов позволяли быстро понять структуру всего проекта.

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

  1. рисуем диаграммы;
  2. генерируем код;
  3. редактируем код (реализуем функции);
  4. на следующий день появляется необходимость изменить поля и методы одного из классов. Редактируем диаграмму
  5. В код мы диаграмму уже не можем преобразовать, так как ни одна существующая система UML-моделирования не может корректно это выполнить. Весь код, который вы написали руками будет затерт. Соответственно вносим правки в код вручную.

На 3 шаге диаграммы классов в UML теряют актуальность, шаг 4 никто не делает из-за нехватки времени, все изменения вносятся сразу в код. Не выполняется даже шаг 1, так как современные средства разработки (та же Visual Studio) очень наглядны, и классы успешно вносятся сразу в исходный код. При анализе чужого кода мне ни разу не пригодились диаграммы классов. Найти нужное место в чужом коде в первую очередь помогают комментарии и корректные имена переменных и методов. При большом желании можно весь исходный код загрузить в систему UML-моделирования, и она автоматически построит все диаграммы классов, но в 99% случаях вы увидите диаграмму с сотней классов и тысячью связей между ними, и в понимании исходного кода вам это никак не поможет.

И так, пишите комментарии и задавайте правильные имена, а не тратьте время на диаграммы классов/пакетов/компонент/объектов и т.д. Модель приложения в первую очередь должна строиться в вашей голове. Но некоторые диаграммы UML все же полезны!

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

Она же Sequence diagram:
Данная диаграмма является развитием Activity diagram, при большом желании на ней можно показать и альтернативные ветки алгоритма (когда что-то пошло НЕ успешно). Диаграмма показывает, кто кого вызывает, синхронные и асинхронные запросы, как правило на диаграмме детализируют компоненты (уже не Касса, а ПО и базы данных). Sequence diagram прекрасно подходит для описания распределенных систем, комментариями в исходном коде вы такой наглядности не добьетесь.

Сколько этих диаграмм надо нарисовать? Опишите все самые сложные взаимодействия, на описание простых ваш работодатель не оставит вам времени.

Диаграмма классов для проектирования баз данных

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


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

Собственно на этом и все, я не встречал ни в одном проекте, чтобы кто-то вручную рисовал еще какие-то диаграммы UML. И помните важную вещь: вы можете досконально изучить спецификацию UML, начнете использовать какой-нибудь дополнительный экзотический язык на своих диаграммах (например OCL), или банальные "стереотипы UML", и спустя некоторое время вы столкнетесь с тем, что ваша команда не понимает эти диаграммы, т.к. далеко не все зазубрили UML. А через пару лет на проект придет новая команда, и ваши "сложные" диаграммы скорее всего пойдут в помойку.

Распределенные приложения и Archimate

На самом деле начинать проектирование надо именно с этих диаграмм, а не с UML.

В нотации Archimate не предусмотрено обязательного перечня диаграмм, вы можете отобразить то, что посчитаете нужным. На рисунке выше для Кассы отмечено ее оборудование, ОС и СУБД, но можно было обойтись и без них.

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

На диаграмме видно, кто является инициатором сетевых подключений (всегда Служба синхронизации), какие потоки данных и в какую сторону передаются, какие базы данных имеются на Кассе и какие данные они содержат. Аналогичные детальные диаграммы можно отрисовать для каждой из компонент в ЦОД.

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

Бывают и такие варианты диаграмм Archimate:


На диаграмме вы видите Функции - это те самые, из UML-диаграмм выше. Нотация Archimate имеет много общих элементов с UML, и данное использование блоков легально. На этой же диаграмме видно, с помощью какого ПО эти функции реализованы, и на каком оборудовании это ПО развернуто. Т.е. в отличие от UML, на диаграммах Archimate можно намешать сразу все "уровни": оборудование, функции, бизнес-процессы, сетевые потоки данных.

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

2015.01.14, Андрей Абрамов

Comments

Не удалось найти URL спецификации гаджета