Что описывают при помощи uml диаграмм

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

Изображение с www.uml.org

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Объектно-ориентированный подход, я думаю, всем понятен и прост. Чтобы не тратить время, не будем рассматривать бизнес-уровень. Думаю, все могут представить в голове советующий 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, вы найдете сотни примеров для каждого вида диаграмм, и без проблем создадите свои, нотация не сложная. Но так ли уж необходимо тратить на это время? Наш богатый опыт говорит «Да». Если у вас в команде более 2 человек и проект от 3 месяцев, то уже имеет смысл отрисовать 2-3 вида диаграмм. В одной нашей команде более 30 человек, проект длительностью более 3 лет, и мы используем. 2-3 вида диаграмм.

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

В чем будем рисовать?

Если ваша цель «быстро и красиво» (например, для презентации или для этой статьи), то Visio подходит более чем: его редактор удобен и прощает любые отступления от нотации.

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

Техническое задание

Мы будем проектировать гипотетическое мобильное приложение для изучения иностранных языков. Техническое задание обычно готовят аналитики, которые и подготовят первую партию диаграмм. От разработчиков, в данном случае, требуется только правильно их читать.

Самая простая диаграмма — Use Case (Варианты использования):

На диаграмме указаны виды пользователей и перечислены функции или группы функций, которые с ними связаны. Синим цветом выделен элемент, которого в UML нет, но его часто не хватает: Requirement — Требование (из нотации Archimate), уточнение функций.

Вы спросите — и какой в этом смысл? Ведь перечень функций можно указать просто текстом, одним компактным списком! И будете правы, но есть нюансы.

Почему для связи элементов мы использовали линии, а не стрелки? Потому что никто не помнит, как выглядят стрелки «Обобщение» и «Расширение», и что они вообще такое. Чем проще вы нарисуете, тем больше людей поймет диаграмму без вашего участия.

Второй вид диаграмм, который вы можете встретить в техническом задании, это Activity diagram:

Здесь для разработчика все очевидно, кроме одного: почему AI делает вызовы Студента? Не делает. Эту диаграмму рисуют аналитики, а не программисты, они не знают где клиент, а где сервер, и их не интересуют потоки данных. На Activity diagram вы видите последовательность действий и не более того. Как же из этого сделать код? Переходим к этапу проектирования.

Проектирование архитектуры

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

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

Для каждой подсистемы потребуется Архитектурная схема, как ее правильно нарисовать? В UML для этого нет подходящих диаграмм, давайте посмотрим на Archimate:

Даже без знания нотации схема, в целом, читаема. Помните, что 90% участников вашей команды не знают ни UML, ни тем более Archimate, и никогда не выучат эти нотации, поэтому делайте упор на надписи. Тем не менее, пара слов о кубиках и стрелочках:

Полную спецификацию Archimate вы найдете без труда.

Цвет — на ваш вкус, нотация никак их не регламентирует. Раскрасьте одним цветом текущую подсистему, вторым — смежные подсистемы, третьим — внешние системы, это сильно повышает читаемость схемы.

На схеме используется всего два вида стрелок: Flow (Поток) и Access (Вызов, Доступ). Поток показывает направление передачи данных, а Вызов — кто к кому обращается. Следует правильно понимать стрелку Поток:

На схеме не отображен поток от мобильного приложения к серверу, хотя на самом деле он есть (первым идет поток «Запрос данных»). Делается это для того, чтобы схема проще читалась: показываем только самое важное. То, что есть еще и исходный Запрос данных и так очевидно из кубика с надписью API.

Детализация

Последние две диаграммы, которые очень полезны (внимательный читатель конечно заметил, что всего видов диаграмм уже не 2-3): Sequence diagram (Диаграмма последовательности) и Class Diagram (Диаграмма классов, но вовсе не для классов).

Иногда взаимодействие клиента и сервера многоступенчатое, с использованием третьих ресурсов. Например, авторизация с Oauth2: текстовое описание этого процесса весьма затруднительно для понимания. Здесь нам поможет Sequence diagram:

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

Когда вы углубитесь в изучение Sequence diagram вы обнаружите, что она позволяет отобразить циклы и ветвления, но не злоупотребляйте ими: не нужно на одной диаграмме рисовать ветки «Если пользователь выбрал локальную авторизацию, то» и «Если выбрал авторизацию FB, то», вместо этого нарисуйте две схемы под каждый вариант. Условия, особенно вложенные, на Sequence diagram очень сильно снижают читаемость схемы.

Последняя диаграмма (не на сегодня, а вообще) — Диаграмма классов. Название у нее говорящее, предполагалось, что с помощью нее будут проектировать классы. В давние времена текстовых редакторов под DOS это может и было оправдано, но современные среды разработки позволяют проектировать и анализировать классы не покидая их темных и светлых тем.

Но практическое применение у Class Diagram все же осталось — проектирование баз данных:

Если вы знаете, что такое Реляционные базы данных, то это более чем наглядно. Полностью атрибуты на схеме не расписываются, указываются только связи, типы данных, иногда ограничения.

Не пытайтесь рисовать это в Visio, Enterprise Architect или аналогах. Для проектирования баз данных есть много специализированных инструментов, которые заточены под конкретные СУБД, пользуйтесь ими.

На этом все. Из всех диаграмм в UML и Archimate на практике более чем достаточно перечисленных. Сколько диаграмм каждого вида нужно для проекта? Рисовать ли их под каждый процесс и подсистему? Главное правило — диаграмма сопровождает текстовое описание, она нужна только там, где текста недостаточно, т.е. там, где команда вас не понимает.

Спасибо за внимание, с вами была компания «Программный продукт».

Источник

UML-диаграммы классов

UML – унифицированный язык моделирования (Unified Modeling Language) – это система обозначений, которую можно применять для объектно-ориентированного анализа и проектирования.
Его можно использовать для визуализации, спецификации, конструирования и документирования программных систем.
Словарь UML включает три вида строительных блоков:

Сущности – это абстракции, которые являются основными элементами модели, связи соединяют их между собой, а диаграммы группируют представляющие интерес наборы сущностей.

Диаграмма – это графическое представление набора элементов, чаще всего изображенного в виде связного графа вершин (сущностей) и путей (связей). Язык UML включает 13 видов диаграмм, среди которых на первом месте в списке — диаграмма классов, о которой и пойдет речь.
Диаграммы классов показывают набор классов, интерфейсов, а также их связи. Диаграммы этого вида чаще всего используются для моделирования объектно-ориентированных систем. Они предназначены для статического представления системы.
Большинство элементов UML имеют уникальную и прямую графическую нотацию, которая дает визуальное представление наиболее важных аспектов элемента.

Сущности

Диаграммы классов оперируют тремя видами сущностей UML:

Поведенческие сущности – динамические части моделей UML. Это «глаголы» моделей, представляющие поведение модели во времени и пространстве. Основной из них является взаимодействие – поведение, которое заключается в обмене сообщениями между наборами объектов или ролей в определенном контексте для достижения некоторой цели. Сообщение изображается в виде линии со стрелкой, почти всегда сопровождаемой именем операции.

Структурные сущности — классы

Класс – это описание набора объектов с одинаковыми атрибутами, операциями, связями и семантикой.

Графически класс изображается в виде прямоугольника, разделенного на 3 блока горизонтальными линиями:

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

Видимость для полей и методов указывается в виде левого символа в строке с именем соответствующего элемента.

Каждый класс должен обладать именем, отличающим его от других классов. Имя – это текстовая строка. Имя класса может состоять из любого числа букв, цифр и знаков препинания (за исключением двоеточия и точки) и может записываться в несколько строк.
На практике обычно используются краткие имена классов, взятые из словаря моделируемой системы. Каждое слово в имени класса традиционно пишут с заглавной буквы (верблюжья конвенция), например Sensor (Датчик) или TemperatureSensor (ДатчикТемпературы).

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

Атрибут (свойство) – это именованное свойство класса, описывающее диапазон значений, которые может принимать экземпляр атрибута. Класс может иметь любое число атрибутов или не иметь ни одного. В последнем случае блок атрибутов оставляют пустым.
Атрибут представляет некоторое свойство моделируемой сущности, которым обладают все объекты данного класса. Имя атрибута, как и имя класса, может представлять собой текст. На практике для именования атрибута используются одно или несколько коротких существительных, выражающих некое свойство класса, к которому относится атрибут.

Можно уточнить спецификацию атрибута, указав его тип, кратность (если атрибут представляет собой массив некоторых значений) и начальное значение по умолчанию.

Статические атрибуты класса обозначаются подчеркиванием.

Операция (метод) – это реализация метода класса. Класс может иметь любое число операций либо не иметь ни одной. Часто вызов операции объекта изменяет его атрибуты.
Графически операции представлены в нижнем блоке описания класса.
Допускается указание только имен операций. Имя операции, как и имя класса, должно представлять собой текст. На практике для именования операции используются короткие глагольные конструкции, описывающие некое поведение класса, которому принадлежит операция. Обычно каждое слово в имени операции пишется с заглавной буквы, за исключением первого, например move (переместить) или isEmpty (проверка на пустоту).
Можно специфицировать операцию, устанавливая ее сигнатуру, включающую имя, тип и значение по умолчанию всех параметров, а применительно к функциям – тип возвращаемого значения.

Абстрактные методы класса обозначаются курсивным шрифтом.
Статические методы класса обозначаются подчеркиванием.

Изображая класс, не обязательно показывать сразу все его атрибуты и операции. Для конкретного представления, как правило, существенна только часть атрибутов и операций класса. В силу этих причин допускается упрощенное представление класса, то есть для графического представления выбираются только некоторые из его атрибутов. Если помимо указанных существуют другие атрибуты и операции, вы даете это понять, завершая каждый список многоточием.
Чтобы легче воспринимать длинные списки атрибутов и операций, желательно снабдить префиксом (именем стереотипа) каждую категорию в них. В данном случае стереотип – это слово, заключенное в угловые кавычки, которое указывает то, что за ним следует.

Отношения между классами

Существует четыре типа связей в UML:

Эти связи представляют собой базовые строительные блоки для описания отношений в UML, используемые для разработки хорошо согласованных моделей.

Первая из них – зависимость – семантически представляет собой связь между двумя элементами модели, в которой изменение одного элемента (независимого) может привести к изменению семантики другого элемента (зависимого). Графически представлена пунктирной линией, иногда со стрелкой, направленной к той сущности, от которой зависит еще одна; может быть снабжена меткой.

Ассоциация – это структурная связь между элементами модели, которая описывает набор связей, существующих между объектами.
Ассоциация показывает, что объекты одной сущности (класса) связаны с объектами другой сущности таким образом, что можно перемещаться от объектов одного класса к другому.
Например, класс Человек и класс Школа имеют ассоциацию, так как человек может учиться в школе. Ассоциации можно присвоить имя «учится в». В представлении однонаправленной ассоциации добавляется стрелка, указывающая на направление ассоциации.

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

Пример кода и диаграммы классов для него

Программа получает данные с датчика температуры (вводятся с консоли) — по 5 измерений для каждого из двух объектов класса TemperatureMeasure и усредняет их. Также предусмотрен класс ShowMeasure для вывода измеренных значений.

Источник

1) Что такое диаграммы UML?

Что такое диаграммы UML?

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

В этом уроке вы узнаете,

Зачем использовать UML? Полная история

1990-е годы были эпохой развития объектно-ориентированных языков, таких как C ++. Эти объектно-ориентированные языки использовались для создания сложных, но привлекательных систем.

Поскольку разработанные системы были сложны для понимания, это привело к проблемам проектирования и анализа, с которыми столкнулись после развертывания системы. Было сложно объяснить систему другим.

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

UML — это объектно-ориентированный унифицированный язык моделирования. Он был изобретен блестящими инженерами-программистами Грэди Бучом, Иваром Джекобсоном и Джеймсом Румбо из Rational software в течение 1994 и 1995 годов. Он разрабатывался до 1996 года.

У каждого из изобретателей UML, а именно, Грэди Буча, Ивара Джекобсона и Джеймса Румбо, была фантастическая идея разработать язык, который уменьшит сложность.

Позже в UML были изобретены модели поведения и диаграммы состояний, которые были изобретены Дэвидом Харелом.

UML была признана стандартом группой управления объектами (OMG) в 1997 году. Группа управления объектами отвечает за управление UML с момента его принятия в качестве стандарта.

В 2005 году Международная организация по стандартизации утвердила UML в качестве стандарта ISO. Он используется в различных отраслях промышленности для создания объектно-ориентированных моделей.

Последняя версия UML 2.5.1 выпущена в декабре 2017 года.

Версии UML

Характеристики UML

Концептуальная модель

Прежде чем начать с концепции UML, необходимо понять основы концептуальной модели.

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

Концептуальная модель требуется в UML. Вы должны понимать сущности и отношения между ними, прежде чем фактически моделировать систему.

Источник