Изображение с www.uml.org
Статья посвящена 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, человек способен это делать.
Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.
Какие языки/диаграммы/аспекты моделирования вы ПРИМЕНЯЕТЕ:
4.17% DFD2
6.25% IDEF03
2.08% IDEF1X1
0% IDEF30
14.58% UML. Use Case Diagram7
29.17% UML. Class Diagram14
18.75% UML. State Machine Diagram9
20.83% UML. Sequence Diagram10
18.75% UML. Activity Diagram9
2.08% VAD1
2.08% EPC1
25% BPMN12
0% CMMN0
0% DMN0
6.25% ArchiMate. Business Layer3
6.25% ArchiMate. Application Layer3
6.25% ArchiMate. Technology Layer3
4.17% ArchiMate. Physical2
6.25% ArchiMate. Motivation3
4.17% ArchiMate. Strategy2
4.17% ArchiMate. Implementation2
29.17% MindMap14
43.75% Блок-схема21
43.75% Прямоугольники, линии и стрелки21
35.42% Простой текст17
33.33% Вожу в воздухе руками16
2.08% Другое1
Проголосовали 48 пользователей. Воздержались 18 пользователей.