UML. Взгляд со стороны
•Download as PPTX, PDF•
0 likes•637 views
Доклад Ильдара Гиматдинова на конференции Analyst Days-6 www.analystdays.com
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (7)
Similar to UML. Взгляд со стороны
Similar to UML. Взгляд со стороны (20)
More from SQALab
More from SQALab (20)
UML. Взгляд со стороны
- 1. UML. Взгляд со стороны или «Как UML удерживает аналитиков в прошлом» Гиматдинов Ильдар ООО «НПО ВС» ildar.gimatdinov@gmail.com
- 2. О себе 11летвIT: • 4годакакразработчик, • 3каканалитик, • 4какархитектор. Специализация: • Управлениетребованиями; • Планированиеиорганизацияработ; • Госсектор. 2
- 3. Чем занимаются аналитики • Изучаютпредметнуюобласть,описываютеев видемодели • Выявляютиформализуюттребования • Формируютмодельпрограммнойсистемы • Пишутразличнуюдокументацию 3
- 4. История создания и развития UML Ada/Booch State Charts 2017 2015 2010 2005 2000 1997 1995 1990 Booch 91 Booch 93 OMT OMT 94 OOSE OOSE 94 Fusion RDD OBA OOA OODA OOSA Fusion Team SOMA OPEN/OML MOSES RD UML 0.8 UML 0.9 UML 1.1 UML 1.4 UML 2.0 UML 1.5 UML 2.1 UML 2.2 SysML 1.1 xUML UML 2.5 UML 2.3 UML 2.4 UML 1.3 SysML 1.2 SysML 1.3 SysML 1.4 SoaML 1.0 FUML 1.0 FUML 1.1 FUML 1.2 Unified Process История UML 4
- 5. Взгляд со стороны • ВсеметодикииспользованияUML«ходятвокруг» UseCaseDrivenDevelopment. • МоделямнаUMLнехватаетцелостности. • Объектно-ориентированныйподходUML ограничиваетвозможностианалитика. 5
- 6. Аспекты представления SeqDUCD Системный вариант использования 2 Системный вариант использования 1 Актер 2 Актер 3 Актер 1 Группа 1 Системный вариант использования 4 Системный вариант использования 5 Системный вариант использования 3 «include» «include» «include» Актер 4 Актер 5 Объект 1 Объект 2 Объект 3 Объект 4 yyy StateDClassD Статус 1 Статус 2 Статус 3 Статус 4 Статус 5 Статус 7Статус 6 поле 1 поле 2 поле 3 поле 4 Класс 1 поле 1 поле 2 поле 3 поле 4 Класс 2 поле 1 поле 2 поле 3 поле 4 Класс 3 поле 1 поле 2 поле 3 поле 4 Класс 4 поле 1 поле 2 поле 3 поле 4 Класс 6 «used» поле 1 поле 2 поле 3 поле 4 «enumeration» Класс 5 «used» 6
- 7. Гибридная диаграмма SeqDUCD Системный вариант использования 2 Системный вариант использования 1 Актер 2 Актер 3 Актер 1 Группа 1 Системный вариант использования 4 Системный вариант использования 5 Системный вариант использования 3 «include» «include» «include» Актер 4 Актер 5 Объект 1 Объект 2 Объект 3 Объект 4 yyy StateDClassD Статус 1 Статус 2 Статус 3 Статус 4 Статус 5 Статус 7Статус 6 поле 1 поле 2 поле 3 поле 4 Класс 1 поле 1 поле 2 поле 3 поле 4 Класс 2 поле 1 поле 2 поле 3 поле 4 Класс 3 поле 1 поле 2 поле 3 поле 4 Класс 4 поле 1 поле 2 поле 3 поле 4 Класс 6 «used» поле 1 поле 2 поле 3 поле 4 «enumeration» Класс 5 «used» Требование 1 Требование 2 Требование 3 Системный вариант использования «trace» «trace» «trace» Web форма 1 «realize» Компонент 1 «realize» 7
- 8. Уровни представления Уровень бизнеса Уровень приложений UCD Бизнес вариант использования 2 Бизнес вариант использования 1 Актер 2 Актер 3 Актер 4 Актер 1 Группа 1 Бизнес вариант использования 4 Бизнес вариант использования 5 Бизнес вариант использования 3 «include» «include» «include» AD Action 1 Action 2 [yyy] [xxx] Action 3 [zzz] [www] Action 4 [rrr] [qqq] Action 5 Action 6 Action 7 Action 8 SeqDUCD Системный вариант использования 2 Системный вариант использования 1 Актер 2 Актер 3 Актер 1 Группа 1 Системный вариант использования 4 Системный вариант использования 5 Системный вариант использования 3 «include» «include» «include» Актер 4 Актер 5 Объект 1 Объект 2 Объект 3 Объект 4 yyy 8
- 9. Связь между уровнями Уровень бизнеса Уровень приложений UCD Бизнес вариант использования 2 Бизнес вариант использования 1 Актер 2 Актер 3 Актер 4 Актер 1 Группа 1 Бизнес вариант использования 4 Бизнес вариант использования 5 Бизнес вариант использования 3 «include» «include» «include» AD Action 1 Action 2 [yyy] [xxx] Action 3 [zzz] [www] Action 4 [rrr] [qqq] Action 5 Action 6 Action 7 Action 8 SeqDUCD Системный вариант использования 2 Системный вариант использования 1 Актер 2 Актер 3 Актер 1 Группа 1 Системный вариант использования 4 Системный вариант использования 5 Системный вариант использования 3 «include» «include» «include» Актер 4 Актер 5 Объект 1 Объект 2 Объект 3 Объект 4 yyy 9 Требование 1 Требование 2 Требование 3 Системный вариант использования «trace» «trace» «trace» Web форма 1 «realize» Компонент 1 «realize»
- 10. Archimate. Уровни и аспекты 10 Сотрудник туроператора «Бизнес-процесс» Продажа тура «Бизнес-сервис» Оформление договора «Бизнес-функция» Подготовка договора «Программная функция» Поверка удостоверения личности Исполняет Используется в Используется в Используется в Интернет «Программный сервис» Банковское обслуживание Используется для «Бизнес-функция» Прием оплаты Используется для безналичных платежей Сервер «Компонент» Система ведения договоров «Бизнес-функция» Поверка личности Используется в «Технологический сервис» Хостинг приложений Используется для Реализует Терминал Сервер приложений «Программный сервис» Взаимодействие с МВДРеализует Договор
- 11. Сервис-ориентированная архитектура Бизнес-процесс 1 Бизнес-процесс 2 Сервис 1 Сервис 2 Сервис 3 Операция 1 Операция 2 Операция 3 Операция 4 Операция 5 11
- 12. ОО моделирование (Уровень приложений) 12 + продать(:Название товара, :Деньги) :Товар «interface» Умеющий продавать type МагазинЧеловек
- 13. СО моделирование на SoaML Бизнес-архитектура 13 «ServiceArchitecture» Архитектура розничной сети :Продажа товара покупатель продавец :Магазин:Человек
- 14. СО моделирование на SoaML Бизнес-процесс 14 продавец :Продавецпокупатель :Покупатель Продажа товара
- 15. СО моделирование на SoaML Бизнес-сервис 15 «ServiceContract» Договор купли-продажи продавец :Продавецпокупатель :Покупатель продать ( ) «Provider» Продавец «Consumer» Покупатель
- 16. СО моделирование на SoaML Бизнес-процесс (Уровень приложений) 16 продавец :Продавецпокупатель :Покупатель продать(:Название товара, :Деньги) :Товар
- 17. СО моделирование на SoaML Сервисы (Уровень приложений) 17 «Participant» Магазин «Participant» Человек Умеющий продавать :Желание продавать :Потребность покупать + продать(:Название товара, :Деньги) :Товар «interface» Умеющий продавать «ServiceInterface» Желание продавать «ServiceInterface» Потребность покупать «use»
- 18. Сравнение ОО и СО моделирования на SoaML 18 МагазинЧеловекООМ СОМ Умеющий продавать «Participant» Магазин «Participant» Человек Умеющий продавать :Желание продавать :Потребность покупать
- 19. СО моделирование на SoaML Общий вид Уровень бизнеса Уровень приложений SoaML «ServiceArchitecture» Dealer Network Architecture ps :Purchasing Service dealer :Dealer ship :Shipstatus :Ship Status shipper :Shipper mfg :Manufacturer buyer enquire ship info agent from seller SoaML «Participant» Manufacturer «Service» :Purchasing orderProcessor :OrderProcessor «Service» :Purchasing :Invoicer :Productions :Shipper «Service» :Purchasing «Service» :InvoisingService «Service» :ShippingService «Request» :InvoisingService «Request» :ShippingService «Request» :Purchasing 19
- 23. Сравнение ОО и СО моделирования 23 гулять(:Собака) ЧеловекСобака ЧеловекСобака Сервис «Гулять» «Реализует»«Кто использует» ООМ СОМ
- 24. ОО + СО моделирование 24 спать() танцевать() Человек лаять() Собака Сервис «Гулять» «Реализует»«Кто использует»
- 25. Archimate. СО моделирование 25 Сотрудник туроператора «Бизнес-процесс» Продажа тура «Бизнес-сервис» Оформление договора «Бизнес-функция» Подготовка договора «Программная функция» Поверка удостоверения личности Исполняет Используется в Используется в Используется в Интернет «Программный сервис» Банковское обслуживание Используется для «Бизнес-функция» Прием оплаты Используется для безналичных платежей Сервер «Компонент» Система ведения договоров «Бизнес-функция» Поверка личности Используется в «Технологический сервис» Хостинг приложений Используется для Реализует Терминал Сервер приложений «Программный сервис» Взаимодействие с МВДРеализует Договор
- 26. Вместо заключения • Осмысленновыбирайтеподходакописанию предметнойобласти. • Изучайтеновыетехнологии,онипредоставляют возможностьвзглянутьнапривычныезадачис новойточкизрения. • Нефиксируйтесвоюточкузренияв «железобетонныеконструкции». 26
- 27. Спасибо за внимание Гиматдинов Ильдар ООО «НПО ВС» ildar.gimatdinov@gmail.com
Editor's Notes
- Здравствуйте, уважаемые коллеги. Меня зовут Гиматдинов Ильдар, я представляю компанию «НПО ВС», город Казань. Мой доклад посвящен UML и особенностям его применения в настоящее время.
- Мой общий опыт в IT 11 лет, из них 4 года как разработчик, 3 как аналитик, 4 как архитектор.
- И так как я работал аналитиком, то хорошо представлю чем занимаются аналитики. Думаю, наиболее распространен следующий типовой список задач: В общем: изучают, анализирую, формализуют, моделируют, описывают. Обращение к залу: Какой язык моделирования наиболее популярен у аналитиков? Что должен знать каждый уважающий себя аналитик? Конечно, это UML. Его можно использовать в каждом пункте этого списка. И для описании бизнес, и для моделирования программных систем.
- Немного исторических сведений. Совсем немного, только основные моменты: UML зародился в 90-х годах как результат работы по создания языка объектно-ориентированного моделирования. Спецификация 1.0 вышла в 1997 году. Спецификация 2.0 вышла в 2005 году. На сегодняшний день версия UML 2.5, развитее получили несколько профилей, такие как SysML и SoaML. Обращение к залу: Если посмотреть, как применял тогда и сейчас и это обдумать, то можно сделать следующий вывод: Пусть версия UML сейчас 2.5, но с первой версии принципы использования языка не изменились. И как следствие, аналитики используют концепцию описания программных систем, которая была заложена более 20 лет назад.
- Если дальше продолжить этот анализ а также соотнести UML с требований текущего времени, то выводы такие: Язык сам навязывает методику Use Case Driven Development. Про нее я ничего говорить не буду, полное воплощение ее это Rational Unified Process. Выбранный подход раздельного описания аспектов структуры и поведения, уровней бизнеса и приложений усложняет восприятие моделей в целом. UML является объектно-ориентированным языком, это затрудняет с помощью него выражать другие концепции. Далее я продемонстрирую последние два пункта.
- UML состоит из множества диаграмм. Каждая из которых подчиняется своим правилам, использует элементы и стрелки в своем понимании. И со стороны выглядит это не как унифицированный язык, а как набор из различных представлений, который часто преподносится как возможность посмотреть на предметную область с различных точек зрений. С тем же успехом можно назвать швейцарский нож унифицированным инструментом, который по сути является набором состоящем из лезвий, отверток, открывашек, ложки, вилки с одной ручкой. Обращение к залу: Что делает аналитик, когда пытается увязать все диаграммы в одну модель?
- Он начинает строить гибридные диаграммы и таблицы связей. В результате получается не единая модель, а множество диаграмм к которому добавились еще диаграммы и таблиц.
- Допустим бизнес-аналитик описал предметную область с помощью диаграмм UML. И теперь системному аналитику или тому же самому аналитику требуется сформировать модель программной системы. Если аналитик ориентирован на UML, то начнет создавать представления соответствующие сделанным ранее, но уже в рамках системы. Это будет выглядеть опять в виде аналогичных диаграмм. Обращение к залу: А что будет делать аналитик, когда захочет сопоставить описание предметной области и модели системы?
- Он опять начинает строить гибридные диаграммы, таблицы связей и трассировки. В результате опять получается множество диаграмм и таблиц. Тут еще нужно заметить, UML старый язык и для него имеется огромное количество книг и старых примеров. В которых в основном описываются случаи перехода от неавтоматизированного бизнеса к автоматизированному. И аналитики учатся на этих примерах. Но ведь на сегодняшний день информационные технологии проникли повсюду. Подход «Бизнес отдельно, ИТ отдельно» уже неприемлем.
- Теперь давайте посмотрим на пример с более современным подходом. Archimate – язык моделирования архитектуры предприятия. Итак в чем же особенность данной модели. Во-первых: Отображены три уровня представления: Бизнес уровень – желтый цвет, Уровень приложений – голубой цвет, Технологический уровень – зеленый цвет. Во-вторых: Отображены три аспекта моделирования: Активные структуры – это те кто выполняет работу: Люди, Роли, Компоненты. Поведение – это элементы которые описывают работу: Функции, Сервисы, Бизнес-процессы. Пассивные структуры – это то над чем производится работа: Бизнес-объекты, Объекты данных, Материалы. И в-третьих: Всё это на одной диаграмме. Использую стандартный набор диаграмм, элементов и соблюдая правила UML вы не сможете просто описать данную схему. Вам потребуется несколько диаграмм и дополнительное пояснение, как они связаны.
- UML является объектно-ориентированным языком, это затрудняет с помощью него выражать другие концепции. Например сервис-ориентированные. В стандартном профиле UML нет понятия «Сервис», но есть профиль SoaML, который преподносится как язык моделирования сервис-ориентированной архитектуры. Давайте я очень коротко расскажу про сервис-ориентированную архитектуру, чтобы далее было понятно почему SoaML не подходит для сервис-ориентированного моделирования. Существует три основных уровня абстракции в сервис-ориентированной архитектуре: Бизнес-процессы, сервисы, операции. Бизнес-процесс - это длительный набор действий или мероприятий, проводимых с конкретными бизнес-целями. На системном уровне процесс обычно представляется как ряд операций, которые выполняются в порядке следования в соответствии с определенным набором бизнес-правил. Операция представляет собой логическую единицу работы. Сервис - это логическая группа операций. Бизнес-процессы, как правило, охватывают вызовов нескольких сервисов. Посмотрим как всё это моделируется на 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. Тут нужно быть аккуратным, не стоит этим сильно увлекаться, так как такого рода расширения относятся к метамоделированию. Может так получиться, что создаваемые модели окажутся противоречивыми и малопонятными.
- Посмотрим еще раз на пример с моделью на Archimate. Тут: Отображены три уровня абстракции сервис-ориентированной архитектуры: Процессы, Сервисы, Операции. Отображены три уровня представления: Бизнес уровень – желтый цвет, это бизнес-процесс, бизнес-сервисы и бизнес функции. Уровень приложений – голубой цвет, это программные сервисы и функции. Технологический уровень – зеленый цвет, это сервисы инфраструктуры. Всё это на одной диаграмме. Использую стандартный набор диаграмм, элементов и соблюдая правила UML вы не сможете выразить смысл данной модели.
- UML ограничивает возможности аналитика в выборе подхода к моделированию. Если загнать всё в одну парадигму или выразить предметную область несвойственным для нее подходом, то ваше представление может оказаться искажением. Поэтому выбирайте подходящие языки моделирования. Не отрывайтесь далеко от разработчиков в знании современных технологий и направлений их развития. Лучше иметь знания глубже, чем просто в общих чертах. Иначе вы не сможете построить модели соответствующие новым подходам в информационных технологиях. Проблемы подобные имеющимся в UML можно найти в любом языке моделирования. Любая парадигма, любая модель ущербна относительно реального мира. Учитесь мыслить с различными подходами, в отличии от текущей версии UML, человек способен это делать.