UML. Взгляд со стороны или Как UML удерживает аналитиков в прошлом

Данная статья является переработанным материалом моего доклада на конференции Analyst Days 6 (2017).

Статья посвящена UML и особенностям его применения в настоящее время. Немного исторических сведений, совсем немного, только основные моменты:

• UML зародился в 90-х годах как результат работы по создания языка объектно-ориентированного моделирования.
• Спецификация 1.0 вышла в 1997 году.
• Спецификация 2.0 вышла в 2005 году.
• На сегодняшний день версия UML 2.5, развитие получили несколько профилей, такие как SysML и SoaML.

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

И как следствие: Аналитики используют концепцию описания программных систем, которая была заложена более 20 лет назад. Сама концепция хорошая, но нужно соотносить ее с местом и контекстом применения.

Если дальше продолжить этот анализ применения UML, а также соотнести его с требований текущего времени, то выводы такие:

• Все методики использования UML ходят вокруг Use Case Driven Development.
• Моделям на UML не хватает целостности. Выбранный подход раздельного описания аспектов структуры и поведения, уровней бизнеса и приложений усложняет восприятие моделей в целом.
• UML является объектно-ориентированным языком, это затрудняет с помощью него выражать другие концепции.

Про подход Use Case Driven Development я ничего говорить не буду, одно из воплощений его это Rational Unified Process. Далее я расскажу про последние два пункта.

Аспекты представления

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



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

Уровни представления

Допустим бизнес-аналитик описал предметную область с помощью диаграмм UML. И теперь системному аналитику или тому же самому аналитику требуется сформировать модель программной системы. Если аналитик ориентирован на UML, то начнет создавать представления соответствующие сделанным ранее, но уже в рамках системы. Это будет выглядеть опять в виде аналогичных диаграмм.



А что будет делать аналитик, когда захочет сопоставить описание предметной области и модели системы?

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

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



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

Сервис-ориентированная подход

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

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

Для простой формализации сервис-ориентированном подхода нам потребуются 2 абстракции:

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

Посмотрим, как это моделируется на SoaML. Заодно сравним, как будет отличаться объектно-ориентированное моделирование на UML и сервис-ориентированное моделирование на SoaML.

Человек и Магазин

Задача простая, описать модель покупки товара в магазине.

Объектно-ориентированный подход, я думаю, всем понятен и прост. Чтобы не тратить время, не будем рассматривать бизнес-уровень. Думаю, все могут представить в голове советующий Use Case и его детализацию в виде диаграммы деятельности или диаграммы последовательности.



Человек выступает не как пользователь, а как одна из сторон взаимодействия.
Теперь решим данную задачу с помощью SoaML, строго в соответствии со спецификацией.



На этой диаграмме определяем сообщество взаимодействующих, это Магазин и Человек.
Определяем действующий между ними бизнес-процесс Продажа товара, в котором Магазин выступает как продавец, а Человек как покупатель.



На основе бизнес-процесса мы теперь можем идентифицировать следующий бизнес-сервис, в SoaML для этого используется классификатор ServiceContract.



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

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



Из обновленного бизнес-процесса можно выделить одну операцию продать, оформим ее в базовый интерфейс Умеющий продавать.

Далее нам нужно описать сервисные интерфейсы, которые будут использованы для реализации сервиса.

Получаем следующие сервисные интерфейсы:

• Желание продавать, который наследуется от интерфейса Умеющий продавать;
• Потребность покупать, который зависит от интерфейса Умеющий продавать.

Теперь можно представить модель целевого сервиса в виде диаграммы композитной структуры.



Сравним результаты объектно-ориентированного моделирования на UML и сервис-ориентированного моделирования на SoaML.



Визуально вся разница вот в этих маленьких квадратиках на границе компонентов. Я отметил их красным цветом.Неужели это вся разницы?

Разница между объектно-ориентированным и сервис-ориентированным моделирование на самом деле есть, просто SoaML свел всё к объектам. Но об этом позже.

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



Что же не так, по моему мнению, с SoaML.

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

Во-вторых: Сервис описывается как объект структуры, это нехорошо. В русской речи распространена фраза Поставщик представляет сервис, вот это компонент-ориентированный подход, который реализован в SoaML.

Но в случае с сервис-ориентированной парадигмой правильнее говорить Поставщик оказывает сервис. А если по другому перевести Сервис на русский язык, то всё сразу встает на свои места: Поставщик оказывает услугу.

С этой точки зрения Сервис это не Объект, это Поведение.

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

Парадигмы

Вернемся к UML. UML посредством своей парадигмы пытается описать другие парадигмы.



И если с компонентно-ориентированной парадигмой всё получается, она может быть представлена как логическое продолжение объектно-ориентированной. То с сервис-ориентированной получилось нехорошо.
В данном случае выражать одну парадигму через другую неудачная идея.
Использование такой концепции я продемонстрировал с SoaML на примере задачи Человек и Магазин.

Относится к парадигмам лучше как обозначено ниже.



Продемонстрирую, чем отличается сервис-ориентированное моделирование, от объектно-ориентированного.

Человек и Собака

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



А как будет выглядеть модель с сервис-ориентированным подходом? Не знаю, ответит ли такой вопрос студент.



Можно вспомнить историю объектно-ориентированного программирования.
Как к нему скептически относились в начале его появления даже очень авторитетные люди, такие как Эдсгер Дейкстра и Никлаус Вирт.
И до сих пор некоторые люди считают ООП недостойным внимания.

Ну так вот, данная модель тоже может вызвать усмешки. Дело в том что сервис-ориентированная парадигма не имеет достаточной поддержки на начальном уровне программирования и проектирования.
Для программистов поддержка осуществляется только фреймворками, например, Java Enterprise Edition или Spring. Думаю, что программисты добираются до них с головой, уже отформатированной под объектно-ориентированный подход.
Аналитики строят свое представление о сервис-ориентированной архитектуре и проектирование по статьям в интернете, которые по-разному понимают, что это такое, а некоторые статьи без глубокого погружения в специфику и технические детали вообще малопонятны. В результате аналитики возвращаются к общепринятым Use Case между системой и пользователями. Распространено также, что архитектура системы и ее компонентный состав уже зафиксированы архитектором или обусловлены выбранной платформой. И тогда аналитики опять просто описывают Use Case между системой и пользователями.

Сравните объектно-ориентированный подход и эту, казалось бы, смешную, где Человек оказывает Собаке услугу Гулять.
Когда она перестанет быть для вас смешной, а будет смешным казаться объектно-ориентированный подход, где Человек реализует метод гулять, на вход которому подается Собака!!! Вот тогда к вам пришло понимание сервис-ориентированной парадигмы.

Еще нужно заметить, что эти парадигмы вполне совместимы. Человек по-прежнему может выполнять свойственные ему действия: спать и танцевать, а Собака лаять.

Еще один момент: В этом примере я ввел новое понятие Сервис.
При этом я пока четко не определил правила его использования, но оно отличается от того что в SoaML. Тут нужно быть аккуратным, не стоит этим сильно увлекаться, так как такого рода расширения относятся к метамоделированию. Может так получиться, что создаваемые модели окажутся противоречивыми и малопонятными.

Вместо заключения

• UML ограничивает возможности аналитика в выборе подхода к моделированию. Если загнать всё в одну парадигму или выразить предметную область несвойственным для нее подходом, то ваше представление может оказаться искажением. Поэтому выбирайте подходящие языки моделирования.
• Не отрывайтесь далеко от разработчиков в знании современных технологий и направлений их развития. Лучше иметь знания глубже, чем просто в общих чертах. Иначе вы не сможете построить модели соответствующие новым подходам в информационных технологиях.
• Проблемы подобные имеющимся в UML можно найти в любом языке моделирования. Любая парадигма, любая модель ущербна относительно реального мира. Учитесь мыслить с различными подходами, в отличии от UML, человек способен это делать.