Общая характеристика языка UML. UML: от теории к практике Uml диаграммы с подробным обоснованием и описанием

26.06.2022

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

UML был создан в результате хаоса вокруг разработки ПО и документации. В 1990-х годах было несколько различных способов представления программных систем. Появилась потребность в более унифицированном способе visual UML представления этих систем, и в результате в 1994-1996 годах он был разработан тремя инженерами-программистами, работающими в Rational Software. Позднее он был принят в виде стандарта в 1997 году и до сих пор остается им, получив всего лишь несколько обновлений.

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

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

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

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

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

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

Для упрощения моделирования доступны самые разнообразные инструменты моделирования UML, включая IBM Rose, Rhapsody, MagicDraw, StarUML, ArgoUML, Umbrello, BOUML, PowerDesigner и Dia.

Использование UML имеет различные виды и в документации по разработке программного обеспечения, и в бизнес-процессах:

Эскиз. В этом случае UML-диаграммы используются для передачи различных аспектов и характеристик системы. Однако это только представление верхнего уровня системы и, скорее всего, не будет включать все необходимые детали для выполнения проекта до самого конца.
Forward Design - дизайн эскиза выполняется до кодирования приложения. Это делается для лучшего обзора системы или рабочего процесса, который пользователь пытается создать. Многие проблемы дизайна или недостатки могут быть выявлены, что улучшит общее состояние здоровья и благополучия проекта.
Обратный дизайн. После написания кода диаграммы UML отображаются как форма документации для разных действий, ролей, участников и рабочих процессов.
Светокопия. В этом случае диаграмма служит полной конструкцией, которая требует исключительно фактической реализации системы или программного обеспечения. Часто это делается с помощью инструментов CASE (Computer Aided Software Engineering Tools). Основным недостатком использования инструментов CASE является то, что они требуют определенного уровня знаний, обучения пользователей, а также управления и персонала.

UML не является автономным языком программирования, как Java, C ++ или Python, однако с правильными инструментами он может превратиться в язык UML псевдопрограмм. Для достижения этой цели вся система должна быть документирована в разных диаграммах, и, используя правильное программное обеспечение, диаграммы могут быть непосредственно переведены в код. Этот метод может быть полезен только в том случае, если время, затрачиваемое на рисование диаграмм, займет меньше времени, чем написание фактического кода. Несмотря на то, что UML был создан для моделирования систем, он нашел несколько применений в бизнес-областях.

Ниже приводится пример UML-диаграммы для моделирования бизнеса.

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

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

Разные типы разбиваются следующим образом:

Не все из 14 различных типов UML-диаграмм используются на регулярной основе при документировании систем и архитектур.
Принцип Парето, применяется и в отношении использования диаграмм UML.
20 % диаграмм используются разработчиками в 80 % случаев.

Наиболее часто используемые элементы в разработке программного обеспечения:

диаграммы использования;
диаграммы классов;
последовательности.

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

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

Диаграмма использования

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

Функциональные - представлены в качестве вариантов использования.
Глагол, описывающий действие.
Актеры - для взаимодействия с системой. В роли актера могут быть пользователи, организации или внешней заявкой. Отношения между участниками представляются прямыми стрелками.

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

Этот тип диаграмм хорошо подходит для отображения динамического поведения между участниками в системе, упрощая ее представление не отражая детали реализации.

Временная

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

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

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

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

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

Очень простая диаграмма состояния машины была бы в шахматной игре. Типичная шахматная игра состоит из ходов, сделанных Белыми, и движений, сделанных Черными. У Белых есть первый ход, что таким образом инициирует игру. Завершение игры может происходить независимо от того, побеждают ли Белые или Черные. Игра может закончиться матчем, отставкой или ничьей (разные состояния машины). Statecharts находят применение в основном в прямом и обратном UML проектировании различных систем.

Последовательные

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

Чтобы получить более полную информацию, можно рассмотреть пример диаграммы последовательности UML ниже.

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

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

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

Объектов

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

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

Развертывания

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

Типичная упрощенная схема развертывания для веб-приложения будет включать:

Узлы (сервер приложений и сервер баз данных).
Артефакты схема клиентского приложения и базы данных.

Диаграмма пакетов похожа на макросбор для диаграмм UML развертывания, которые мы объясняли выше. Различные пакеты содержат узлы и артефакты. Они группируют диаграммы и компоненты модели в группы, подобно тому, как пространство имен инкапсулирует разные имена, которые несколько взаимосвязаны. В конечном итоге пакет также может быть создан несколькими другими пакетами, чтобы отображать более сложные системы и поведение.

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

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

Они обычно делятся на следующие основные категории:

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

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

Я думаю, каждый слышал в детстве такую поговорку как "Семь раз отмерь, один раз отрежь ". В программировании так же. Лучше всегда обдумать реализацию до того, как вы потратите время на её исполнение. Часто приходится при реализации создавать классы, придумывать их взаимодействие. И часто визуальное представление этого может помочь решить задачу наиболее правильным образом. В этом нам и помогает UML .

Что такое UML?

Если посмотреть картинки в поисковых системах, то станет понятно, что UML – это что-то про схемы, стрелочки и квадратики. Что важно, что UML переводится как Unified Modeling Language . Важно тут слово Unified. То есть наши картинки поймём не только мы, но и остальные, кто знает UML. Получается это такой международный язык рисования схем.

Как гласит Википедия

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

Самое интересное, о чём не все задумываются или догадываются, UML имеет спецификации. Причём даже есть спецификация UML2. Подробнее со спецификацией можно ознакомиться на сайте Object Management Group . Собственно, эта группа и занимается разработкой спецификаций UML. Интересно и то, что UML не ограничивается описанием структуры классов. Существует множество типов UML диаграмм. Краткое описание типов UML диаграмм можно увидеть в той же Википедии: UML - диаграммы или в видео Тимура Батыршинова Обзор UML диаграмм . UML так же широко применяется при описании различных процессов, например здесь: Единый вход с использованием JWT . Возвращаясь к использованию UML диаграмм классов, стоит отметить книгу Head First: Паттерны проектирования , в которой паттерны иллюстрируются теми самыми UML диаграммами. Выходит, что UML действительно используется. И выходит, что знание и понимание его применения довольно полезный навык.

Применение

Разберём, как с этим самым UML можно работать из IDE. В качестве IDE возьмём IntelliJ Idea . Если использовать IntelliJ Idea Ultimate , то у нас "из коробки" будет установлен плагин "UML Support ". Он позволяет автоматически генерировать красивые диаграммы классов. Например, через Ctrl+N или пункт меню "Navigate" -> "Class" перейдём в класс ArrayList . Теперь, через контекстное меню по имени класса выберем "Diagram" -> "Show diagram popup". В результате мы получим красивую диаграмму:

Но что, если хочется самому нарисовать, да ещё и нет Ultimate версии Idea? Если мы используем IntelliJ Idea Community Edition, то у нас нет другого выбора. Для этого нужно понять, как такая UML схема устроена. Для начала нам понадобится установить Graphviz . Это набор утилит для визуализации графов. Его использует плагин, который мы будем применять. После установки необходимо добавить каталог bin из каталога установленного Graphviz в переменную среды окружения PATH . После этого в IntelliJ Idea в меню выбрать File -> Settings. В окне "Settings" выбрать категорию "Plugins", нажать кнопку "Browse repositories" и установить плагин PlantUML integration . Чем так хорош этот PlantUML ? Он использует для описания UML язык описания графов под названием "dot " и это позволяет ему быть более универсальным, т.к. данный язык используется не только PlantUML. Более того, всё что мы ниже сделаем мы можем выполнить не только в IDE, но и в онлайн сервисе planttext.com . После установки плагина PlantUML у нас появится возможность через "File" -> "New" создавать UML диаграммы. Давайте выполним создание диаграммы типа "UML class". В ходе этого автоматически генерируется шаблон с примером. Удалим его содержимое и создадим своё, вооружившись статьёй с Хабра: Отношения классов - от UML к коду . А чтобы понять, как это изобразить в тексте, возьмём мануал по PlantUML: plantuml class-diagram . В нём в самом начале представлена табличка с тем, как нужно описывать связи:

Про сами же связи можем ещё подсматривать сюда: "Отношения между классами в UML. Примеры ". На основе этих материалов приступим к созданию нашей UML диаграммы. Добавим следующее содержимое, описывающее два класса: @startuml class ArrayList { } class LinkedList { } @enduml Чтобы увидеть результат в Idea, выберем "View" -> "Tool Windows" -> "PlantUML". Мы получим просто два квадрата, обозначающие классы. Как мы знаем, оба эти класса реализуют интерфейс List. Данное отношение классов так и называют - реализация (realization). Для изображения такой связи используют стрелку с пунктирной линией. Изобразим её: interface List List < | . . ArrayList List < | . . LinkedList List - один из дочерних классов Collection . То есть он наследуется от Collection. Эта связь называется обобщением (generalization). Выглядит как стрелка с обычной непрерывной линией. Изобразим её: interface Collection Collection < | -- List Для следующего типа связи добавим в описание класса ArrayList запись о package private массиве элементов: ~ Object elementData Теперь мы хотим показать, что ArrayList содержит какие-то объекты. В данном случае будет тип связи - агрегация (aggregation). Агрегатом в данном случае является ArrayList , т.к. он содержит другие объекты. Агрегацию мы выбираем потому, что объекты в списке могут жить и без списка: они не являются его неотъемлемыми частями. Их время жизни не привязано к времени жизни списка. Агрегат с латинского переводится как "собранный", то есть что-то, составленное из чего-то. Например, в жизни, есть насосный агрегат, который состоит из насоса и двигателя. Сам агрегат можно разобрать, оставив что-то из его составных частей. Например, чтоб продать или поставить в другой агрегат. Так и в списке. И выражается это в виде пустого ромбика у агрегата и непрерывной линии. Изобразим это следующим образом: class Object { } ArrayList o- Object Теперь мы хотим показать, что в отличие от ArrayList , класс LinkedList содержит в себе Node - контейнеры, ссылающиеся на хранимые данные. В данном случае Node являются частью самого LinkedList и не могут жить отдельно. Node не является непосредственнохранимым содержимым, а только содержит ссылку на него. Например, когда мы добавляем в LinkedList какую-нибудь строку, мы добавляем новый Node , который содержит ссылку на эту строку, а также ссылку на предыдущий и следующий Node . Такой тип связи называется композицией (Composition). Для отображения у композита (того, кто состоит из частей) рисуется закрашенный робмик, к нему ведёт непрерывная линия. Запишем теперь это в виде текстового отображения связи: class Node { } LinkedList * -- Node И теперь необходимо научиться отображать ещё один важный тип связи - зависимость (dependency relationship). Он используется тогда, когда один класс использует другой, при этом класс не содержит в себе используемый класс и не является его наследником. Например, LinkedList и ArrayList умеют создавать ListIterator . Отобразим это в виде стрелок с пунктирной линией: class ListIterator ListIterator < . . . ArrayList : create ListIterator < . . . LinkedList : create Выглядеть после всего это будет следующим образом:

Детализировать можно настолько, насколько это необходимо. Все обозначения указаны тут: "PlantUML - Диаграмма классов ". Кроме того, в рисовании такой схемы нет ничего сверхъестественного, и при работе над своими задачами её можно быстро рисовать от руки. Это позволит развить навыки продумывания архитектуры приложения и поможет выявить недостатки структуры классов на раннем этапе, а не когда вы уже потратите день на реализацию неправильной модели. Мне кажется, это неплохая причина для того, чтобы попробовать?)

Автоматизация

Есть различные способы автоматической генерации PlantUML диаграмм. Например, в Idea есть плагин SketchIT , но рисует он их не совсем правильно. Скажем, неправильно рисуется имплементация интерфейсов (отображается как наследование). Также в интернете есть примеры того, как это встроить в жизненный цикл сборки вашего проекта. Допустим, для Maven есть пример использования uml-java-docklet . Для того, чтобы показать как это, воспользуемся Maven Archetype для быстрого создания Maven проекта. Выполним команду: mvn archetype:generate На вопросе выбора фильтра (Choose a number or apply filter ) оставляем default, просто нажав Enter. Это всегда будет "maven-archetype-quickstart ". Выбираем самую последнюю версию. Далее отвечаем на вопросы и завершаем создание проекта:

Так как Maven не является целью данной статьи, ответы на свои вопросы по Maven можно найти в Maven Users Centre . В сгенерированном проекте откроем на редактирование файл описания проекта, pom.xml . В него скопируем содержимое из описания uml-java-docklet installing . Используемый в описании артефакт не удалось найти в репозитории Maven Central. Но у меня заработало с этим: https://mvnrepository.com/artifact/com.chfourie/uml-java-doclet/1.0.0 . То есть надо в том описании просто заменить groupId с "info.leadinglight " на "com.chfourie " и поставить версию "1.0.0 ". После этого можем выполнить в каталоге, где находится файл pom.xml эти комманды: mvn clean install и mvn javadoc:javadoc . Теперь, если открыть сгенерированную документацию (explorer target\site\apidocs\index.html), мы увидим UML схемы. Кстати, имплементация тут уже отображается верно)

Заключение

Как видно, UML позволяет визуализировать структуру вашего приложения. Кроме того, UML не ограничивается только этим. При помощи UML можно описывать различные процессы внутри вашей компании или описывать бизнес-процесс, в рамках которого работает функция, которую вы пишите. На сколько UML полезен лично для вас - решать вам, но найти время и ознакомиться более подробным будет в любом случае полезно. #Viacheslav English version of this post: UML diagram Java on CodeGym

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

1.5.1. Диаграмма использования

Диаграмма использования (use case diagram) ‒ это наиболее общее представление функционального назначения системы.

Диаграмма использования призвана ответить на главный вопрос моделирования: что делает система во внешнем мире?

На диаграмме использования применяются два типа основных сущностей: варианты использования 1 и действующие лица 2 , между которыми устанавливаются следующие основные типы отношений:

ассоциация между действующим лицом и вариантом использования 3 ;
обобщение между действующими лицами 4 ;
обобщение между вариантами использования 5 ;
зависимости (различных типов) между вариантами использования 6 .

На диаграмме использования, как и на любой другой, могут присутствовать комментарии 7 . Более того, это настоятельно рекомендуется делать для улучшения читаемости диаграмм.

Основные элементы нотации, применяемые на диаграмме использования, показаны ниже. Детальное описание приведено в разделе 2.2 .

1.5.2. Диаграмма классов

Диаграмма классов (class diagram) ‒ основной способ описания структуры системы.

Это не удивительно, поскольку UML в первую очередь объектно-ориентированный язык, и классы являются основным (если не единственным) "строительным материалом".

На диаграмме классов применяется один основной тип сущностей: классы 1 (включая многочисленные частные случаи классов: интерфейсы, примитивные типы, классы-ассоциации и многие другие), между которыми устанавливаются следующие основные типы отношений:

ассоциация между классами 2 (с множеством дополнительных подробностей);
обобщение между классами 3 ;
зависимости (различных типов) между классами 4 и между классами и интерфейсами.

Некоторые элементы нотации, применяемые на диаграмме классов, показаны ниже. Детальное описание приведено в главе 3 .

1.5.3. Диаграмма автомата

Диаграмма автомата (state machine diagram) ‒ это один из способов детального описания поведения в UML на основе явного выделения состояний и описания переходов между состояниями.

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

На диаграмме автомата применяют один основной тип сущностей ‒ состояния 1 , и один тип отношений ‒ переходы 2 , но и для тех и для других определено множество разновидностей, специальных случаев и дополнительных обозначений. Перечислять их все во вступительном обзоре не имеет смысла.

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

1.5.4. Диаграмма деятельности

Диаграмма деятельности (activity diagram) ‒ способ описания поведения на основе указания потоков управления и потоков данных.

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

На диаграмме деятельности применяют один основной тип сущностей ‒ действие 1 , и один тип отношений ‒ переходы 2 (передачи управления и данных). Также используются такие конструкции как развилки, слияния, соединения, ветвления 3 , которые похожи на сущности, но таковыми на самом деле не являются, а представляют собой графический способ изображения некоторых частных случаев многоместных отношений. Семантика элементов диаграмм деятельности подробно разобрана в главе 4 . Основные элементы нотации, применяемые на диаграмме деятельности, показаны ниже.

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

Диаграмма последовательности (sequence diagram) ‒ это способ описания поведения системы на основе указания последовательности передаваемых сообщений.

Фактически, диаграмма последовательности ‒ это запись протокола конкретного сеанса работы системы (или фрагмента такого протокола). В объектно-ориентированном программировании самым существенным во время выполнения является пересылка сообщений между взаимодействующими объектами. Именно последовательность посылок сообщений отображается на данной диаграмме, отсюда и название.

На диаграмме последовательности применяют один основной тип сущностей ‒ экземпляры взаимодействующих классификаторов 1 (в основном классов, компонентов и действующих лиц), и один тип отношений ‒ связи 2 , по которым происходит обмен сообщениями 3 . Предусмотрено несколько способов посылки сообщений, которые в графической нотации различаются видом стрелки, соответствующей отношению.

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

Ось времени может быть направлена горизонтально, в этом случае считается, что время течет слева направо.

На следующем рисунке показаны основные элементы нотации, применяемые на диаграмме последовательности. Для обозначения самих взаимодействующих объектов применяется стандартная нотация ‒ прямоугольник с именем экземпляра классификатора. Пунктирная линия, выходящая из него, называется линией жизни (lifeline) 4 . Это не обозначение отношения в модели, а графический комментарий, призванный направить взгляд читателя диаграммы в правильном направлении. Фигуры в виде узких полосок, наложенных на линию жизни, также не являются изображениями моделируемых сущностей. Это графический комментарий, показывающий отрезки времени, в течении которых объект владеет потоком управления (execution occurrence) 5 или другими словами имеет место активация (activation) объекта. Составные шаги взаимодействия(combined fragment) 6 позволяют на диаграмме последовательности, отражать и алгоритмические аспекты протокола взаимодействия. Прочие детали нотации диаграммы последовательностей см. в главе 4 .

1.5.6. Диаграмма коммуникации

Диаграмма коммуникации (communication diagram) ‒ способ описания поведения, семантически эквивалентный диаграмме последовательности.

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

Таким образом, на диаграмме коммуникации также как и на диаграмме последовательности применяют один основной тип сущностей ‒ экземпляры взаимодействующих классификаторов 1 и один тип отношений ‒ связи 2 . Однако здесь акцент делается не на времени, а на структуре связей между конкретными экземплярами.

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

1.5.7. Диаграмма компонентов

Диаграмма компонентов (component diagram) ‒ показывает взаимосвязи между модулями (логическими или физическими), из которых состоит моделируемая система.

Основной тип сущностей на диаграмме компонентов ‒ это сами компоненты 1 , а также интерфейсы 2 , посредством которых указывается взаимосвязь между компонентами. На диаграмме компонентов применяются следующие отношения:

реализации между компонентами и интерфейсами (компонент реализует интерфейс);
зависимости между компонентами и интерфейсами (компонент использует интерфейс) 3 .

На рисунке показаны основные элементы нотации, применяемые на диаграмме компонентов. Детальное описание приведено в главе 3 .

1.5.8. Диаграмма размещения

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

Таким образом, на диаграмме размещения, по сравнению с диаграммой компонентов, добавляется два типа сущностей: артефакт 1 , который является реализацией компонента 2 и узел 3 (может быть как классификатор, описывающий тип узла, так и конкретный экземпляр), а также отношение ассоциации между узлами 4 , показывающее, что узлы физически связаны во время выполнения.

На рисунке показаны основные элементы нотации, применяемые на диаграмме размещения. Для того чтобы показать, что одна сущность является частью другой, применяется либо отношение зависимости «deploy» 5 , либо фигура одной сущности помещается внутрь фигуры другой сущности 6 . Детальное описание диаграммы приведено в главе 3 .

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

Преимущества UML

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

Типы диаграмм UML

В UML 14 типов диаграмм. Их можно разделить на 2 категории:

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

Иерархия типов диаграмм UML,
представленная диаграммой классов

Структурные диаграммы

Диаграмма классов является ключевым элементом в объектно-ориентированном моделировании. С помощью этой диаграммы (собственно, через классы , их атрибуты , методы и зависимости между классами) описывается модель предметной области и структура моделируемой системы.
Диаграмма компонентов отображает разбиение программного кода на крупные блоки (структурные компоненты) и показывает зависимости между ними. Компонентами могут быть пакеты, модули, библиотеки, файлы и т.д.
Объектная диаграмма показывает полный или частичный срез моделируемой системы в заданный момент времени. Она представляет экземплеры классов (объекты), их состояние (текущие значения аттрибутов) и отношения между ними.
Диаграмма композитной структуры демонстрирует внутреннюю структуру классов и, по возможности, взаимодействия между элементами этой структуры.
Диаграмма пакетов показывает пакеты и отношения между ними. Этот вид диаграмм служит для упрощения структуры модели (и, соответственно, работы с ней) через объединение элементов модели в группы по некоторым критериям.
Диаграмма развертывания моделирует развертывание программных компонентов (артефактов ) на вычислительных ресурсах/аппаратных компонентах (узлах ).
Диаграмма профилей описывает механизм расширения, позволяющий приспособить UML к разнообразным предметным областям и сферам деятельности.

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

Диаграммы поведения

Диаграмма деятельности показывает действия (actions ) из которых состоит некоторая деятельность (activity ). Диаграммы деятельности используются для моделирования бизнесс-процессов, технологических процессов, последовательных и параллельных вычислений.
Диаграмма вариантов использования (или диаграмма прецедентов ) описывает отношения между актёрами (действующими лицами) и вариантами использования моделируемой системы (ее возможностями). Основное назначение диаграммы - быть универсальным средством для заказчиков, разработчиков и конечных пользователей, с помощью которого можно было бы совместно обсуждать систему - ее возможности и поведение.
Диаграмма состояний изображает динамическое поведение сущности, показывая как эта сущность в зависимости от своего текущего состояния реагирует на различные события. По сути это диаграмма состояний из теории атоматов.
Диаграмма коммуникации (в ранних версиях диаграмма кооперации ) показывает взаимодействия между частями композитной структуры и ролями кооперации. На диаграмме явно указываются отношения между элементами (объектами).
Диаграмма последовательности используется для визуализации последовательности взаимодействий объектов. Показывает жизненный цикл заданного объекта и взаимодействие актеров (действующих лиц) в рамках некоторого варианта использования, последовательность сообщений которыми они обмениваются.
Диаграмма обзора взаимодействия включает часть диаграммы последовательности и конструкции потока управления. Помогает рассмотреть взаимодействие объектов с различных точек зрения.
Диаграмма синхронизации - отдельный подвид диаграмм взаимодействия, специализируйющийся на тайминге. Диаграммы этого вида используются для исследования поведения объектов в течение определенного периода времени.

UML – это унифицированный графический язык моделирования для описания, визуализации, проектирования и документирования ОО систем. UML призван поддерживать процесс моделирования ПС на основе ОО подхода, организовывать взаимосвязь концептуальных и программных понятий, отражать проблемы масштабирования сложных систем. Модели на UML используются на всех этапах жизненного цикла ПС, начиная с бизнес-анализа и заканчивая сопровождением системы. Разные организации могут применять UML по своему усмотрению в зависимости от своих проблемных областей и используемых технологий.

Краткая история UML

К середине 90-х годов различными авторами было предложено несколько десятков методов ОО моделирования, каждый из которых использовал свою графическую нотацию. При этом любой их этих методов имел свои сильные стороны, но не позволял построить достаточно полную модель ПС, показать ее «со всех сторон», то есть, все необходимые проекции (См. статью 1). К тому же отсутствие стандарта ОО моделирования затрудняло для разработчиков выбор наиболее подходящего метода, что препятствовало широкому распространению ОО подхода к разработке ПС.

По запросу Object Management Group (OMG) – организации, ответственной за принятие стандартов в области объектных технологий и баз данных назревшая проблема унификации и стандартизации была решена авторами трех наиболее популярных ОО методов – Г.Бучем, Д.Рамбо и А.Джекобсоном, которые объединенными усилиями создали версию UML 1.1, утвержденную OMG в 1997 году в качестве стандарта.

UML – это язык

Любой язык состоит из словаря и правил комбинирования слов для получения осмысленных конструкций. Так, в частности, устроены языки программирования, таковым является и UML. Отличительной его особенностью является то, что словарь языка образуют графические элементы. Каждому графическому символу соответствует конкретная семантика, поэтому модель, созданная одним разработчиком, может однозначно быть понята другим, а также программным средством, интерпретирующим UML. Отсюда, в частности, следует, что модель ПС, представленная на UML, может автоматически быть переведена на ОО язык программирования (такой, как Java, C++, VisualBasic), то есть, при наличии хорошего инструментального средства визуального моделирования, поддерживающего UML, построив модель, мы получим и заготовку программного кода, соответствующего этой модели.

Следует подчеркнуть, что UML – это именно язык, а не метод. Он объясняет, из каких элементов создавать модели и как их читать, но ничего не говорит о том, какие модели и в каких случаях следует разрабатывать. Чтобы создать метод на базе UML, надо дополнить его описанием процесса разработки ПС. Примером такого процесса является Rational Unified Process, который будет рассматриваться в последующих статьях.

Словарь UML

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

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

Отношения показывают различные связи между сущностями. В UML определены следующие типы отношений:

Зависимость показывает такую связь между двумя сущностями, когда изменение одной из них – независимой – может повлиять на семантику другой – зависимой. Зависимость изображается пунктирной стрелкой, направленной от зависимой сущности к независимой.
Ассоциация – это структурное отношение, показывающее, что объекты одной сущности связаны с объектами другой. Графически ассоциация показывается в виде линии, соединяющей связываемые сущности. Ассоциации служат для осуществления навигации между объектами. Например, ассоциация между классами «Заказ» и «Товар» может быть использована для нахождения всех товаров, указанных в конкретном заказе – с одной стороны, или для нахождения всех заказов в которых есть данный товар, – с другой. Понятно, что в соответствующих программах должен быть реализован механизм, обеспечивающий такую навигацию. Если требуется навигация только в одном направлении, оно показывается стрелкой на конце ассоциации. Частным случаем ассоциации является агрегирование – отношение вида «целое» – «часть». Графически оно выделяется с помощью ромбика на конце около сущности-целого.
Обобщение – это отношение между сущностью-родителем и сущностью-потомком. По существу, это отношение отражает свойство наследования для классов и объектов. Обобщение показывается в виде линии, заканчивающейся треугольничком направленным к родительской сущности. Потомок наследует структуру (атрибуты) и поведение (методы) родителя, но в то же время он может иметь новые элементы структуры и новые методы. UML допускает множественное наследование, когда сущность связана более чем с одной родительской сущностью.
Реализация – отношение между сущностью, определяющей спецификацию поведения (интерфейс) с сущностью, определяющей реализацию этого поведения (класс, компонент). Это отношение обычно используется при моделировании компонент и будет подробнее описано в последующих статьях.

Диаграммы. В UML предусмотрены следующие диаграммы:

Диаграммы, описывающие поведение системы:

Диаграммы состояний (State diagrams),
Диаграммы деятельностей (Activity diagrams),
Диаграммы объектов (Object diagrams),
Диаграммы последовательностей (Sequence diagrams),
Диаграммы взаимодействия (Collaboration diagrams);

Диаграммы, описывающие физическую реализацию системы:

Диаграммы компонент (Component diagrams);
Диаграммы развертывания (Deployment diagrams).

Представление управления моделью. Пакеты.

Мы уже говорили о том, что для того чтобы модель была хорошо понимаемой человеком необходимо организовать ее иерархически, оставляя на каждом уровне иерархии небольшое число сущностей. UML включает средство организации иерархического представления модели – пакеты. Любая модель состоит из набора пакетов, которые могут содержать классы, варианты использования и прочие сущности и диаграммы. Пакет может включать другие пакеты, что позволяет создавать иерархии. В UML не предусмотрено отдельных диаграмм пакетов, но они могут присутствовать на других диаграммах. Пакет изображается в виде прямоугольника с закладкой.

Что обеспечивает UML.

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

И последнее…

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