Uml нотации что это
Зачем нам UML? Или как сохранить себе нервы и время
Многие программисты, столкнувшись со сложной задачей, пренебрегают этапом проектирования, ссылаясь на то, что проектирование — это потеря времени, и в данном случае оно будет мне только мешать.
Зачастую это утверждение оказывается верным, если задача и правда небольшая и квалификации программиста достаточно для определения наиболее оптимального решения.
Программисты, не использующие UML, делятся на несколько групп:
Можно провести аналогию с постройкой дома. Когда кто-то хочет построить дом, он не просто бьет молотком и приступает к работе. Ему нужно иметь план — план проектирования, чтобы он мог анализировать и модифицировать свою систему.
Если вы уже начали описывать на бумаге вашу задачу, это уже огромный плюс.
Что такое UML
UML – унифицированный язык моделирования (Unified Modeling Language) – это система обозначений, которую можно применять для объектно-ориентированного анализа и проектирования. Его можно использовать для визуализации, спецификации, конструирования и документирования программных систем.
Проще говоря, если посмотреть картинки в поисковых системах, то станет понятно, что UML – это что-то про схемы, стрелочки и квадратики.
Важно, что UML переводится как Unified Modeling Language. Главное здесь слово Unified. То есть наши картинки поймём не только мы, но и остальные, знающие UML. Получается, это такой международный язык рисования схем.
Плюсы и минусы UML проектирования
Все представленные ниже диаграммы связаны между собой. Комбинируя их, мы можем добиться необходимого уровня декомпозиции отдельно взятых задач.
Предлагаю познакомиться с одними из самых полезных и часто используемых диаграмм.
Речь пойдет о диаграммах последовательности, состояний, деятельности и самой сложной из них — диаграмме классов.
Представьте, что вам нужно описать последовательность действий для заказа товара в интернет-магазине. Кто должен участвовать в процессе? Какие фазы проходит заказ прежде, чем он будет оформлен?
Обычно, мы пишем длинный список этапов, которые должна пройти заявка, чтобы получить гордый статус «Оформлена». Затем описываем, кто именно будет выполнять конкретное действие. И только после этого начинаем программировать.
В чем недостаток данного подхода? Он не нагляден.
Представьте, перед вами лежит длинный список описанных ранее этапов и комментариев к ним. Насколько просто вам будет разобраться в нем? Сколько времени может на это потребоваться? Предполагаю, что достаточно.
Альтернативой данному подходу является использование диаграммы последовательностей, представленной на рисунке ниже.
Сверху отображены действующие лица, а каждая стрелка это конкретное действие, связанное с ними. Подробнее о данной диаграмме можно узнать здесь
Диаграмма состояний. Настраиваем старые электронные часы
Диаграмма состояний позволяет описать поведение отдельно взятого объекта при определенных условиях. Также она покажет нам все возможные состояния, в которых может находиться объект, а также процесс смены состояний в результате внешнего влияния.
Предположим, мы программируем советские электронные часы.
Для настройки нам дано всего несколько кнопок. Довольно негусто. При этом мы знаем, что одна из кнопок переключает режим настройки часов. Другая кнопка в первом режиме меняет минуты, а во втором часы.
Инструкция по настройке и так достаточно небольшая, но благодаря диаграмме состояний она визуально воспринимается гораздо проще.
Подробнее о диаграмме состояний можно прочитать здесь.
Диаграмма классов, или как рассказать о своем коде без кода
Диаграммы классов используются при моделировании ПС наиболее часто. Они являются одной из форм статического описания системы с точки зрения ее проектирования. Диаграмма классов не отображает динамическое поведение объектов изображенных на ней классов. На диаграммах классов показываются классы, интерфейсы и отношения между ними.
В различных документациях, описании паттернов проектирования, а также, читая хабр, все мы часто встречаем диаграмму классов. Почему же ее так часто используют?
Предположим, вам нужно спроектировать систему. Прежде чем приступить к реализации нескольких классов, вы захотите иметь концептуальное понимание системы, — какие классы мне нужны? Какая функциональность и информация будет у этих классов? Как они взаимодействуют друг с другом? Кто может видеть эти классы? И так далее.
Вот где появляются диаграммы классов. Диаграммы классов — это отличный способ визуализировать классы в вашей системе, прежде чем вы начнете их кодировать. Они представляют собой статическое представление структуры вашей системы.
Именно диаграмма классов дает нам наиболее полное и развернутое представление о структуре и связях в программном коде. Понимание принципов построения данной диаграммы позволяет кратко и прозрачно выражать свои мысли и идеи.
Рассмотрим, как с помощью диаграммы классов описать известный паттерн проектирования «Посетитель».
«Посетитель» — это поведенческий паттерн проектирования, который позволяет добавлять в программу новые операции, не изменяя классы объектов, над которыми эти операции могут выполняться.
Самыми значимыми достоинствами этой диаграммы являются:
Подробнее о диаграмме классов можно прочитать здесь, а о паттерне «Посетитель» здесь.
Диаграмма деятельности
Диаграмма деятельности – это технология, позволяющая описывать логику процедур, бизнес-процессы и потоки работ. Во многих случаях они напоминают блок-схемы, но принципиальная разница между диаграммами деятельности и нотацией блок-схем заключается в том, что первые поддерживают параллельные процессы.
Если говорить кратко, то диаграмма деятельности помогает нам описать логику поведения системы. Можно построить несколько диаграмм деятельности для одной и той же системы, причем каждая из них будет фокусироваться на разных аспектах системы, показывать различные действия, выполняющиеся внутри нее.
Именно на диаграмме деятельности представлены переходы от одной деятельности к другой. Это, по сути, разновидность диаграммы состояний, где все или большая часть состояний являются некоторыми активностями, а все или большая часть переходов срабатывают при завершении определенной деятельности и позволяют перейти к выполнению следующей.
Смысл диаграммы вполне понятен. На ней показана работа с веб-приложением, которое решает некую задачу в удаленной базе данных. Обратите внимание на расположение активностей на этой диаграмме: они как бы разбросаны по трем колонкам, каждая из которых соответствует поведению одного из трех объектов — клиента, веб-сервера и сервера баз данных. Благодаря этому легко определить, каким из объектов выполняется каждая из деятельностей.
Подробнее о диаграмме деятельности можно прочитать здесь.
Заключение
Надеюсь, что после этой статьи вы по-другому посмотрите на UML. Теперь при прочтении литературы или сайтов, посвященных данной теме, вам будет проще понять, какую цель преследует UML, и найти возможности для его применения. Попробуйте начать применять его и вы почувствуете всю силу и мощь, скрываемую за набором стрелок и квадратиков.
Оставьте комментарий, если вы думаете (или знаете), что что-то не так или могло быть описано лучше.
Uml нотации что это
11. ОСНОВЫ УНИФИЦИРОВАННОГО ЯЗЫКА МОДЕЛИРОВАНИЯ
11.1. Структура Унифицированного языка моделирования
Унифицированный язык моделирования (UML) в настоящий момент является стандартом де-факто при описании (документирования) результатов проектирования и разработки объектно-ориентированных систем. Начало разработки UML было положено в 1994 г. Гради Бучем и Джеймсом Рамбо, работавшим в компании Rational Software. Осенью 1995 г. к ним присоединился Ивар Якобсон и в октябре того же года была выпущена предварительная версия 0.8 унифицированного метода (англ. Unified Method). С этого времени было выпущено несколько версий спецификации UML, две из которых носят статус международного стандарта:
— UML 1.4.2 – ISO/IEC 19501:2005. «Информационные технологии. Открытая распределительная обработка. Унифицированный язык моделирования (UML). Версия 1.4.2» (англ. «Information technology. Open distributed processing. Unified modeling language (UML). Version 1.4.2»);
Последнюю официальную спецификацию языка можно найти на сайте www.omg.org.
Общая структура UML показана на следующем рисунке [25].
Рис. 11.1. Структура UML
11.2. Семантика и синтаксис UML
Семантика – раздел языкознания, изучающий значение единиц языка, прежде всего его слов и словосочетаний [35].
Синтаксис – способы соединения слов и их форм в словосочетания и предложения, соединения предложений в сложные предложения, способы создания высказываний как части текста [35].
Таким образом, применительно к UML, семантика и синтаксис определяют стиль изложения (построения моделей), который объединяет естественный и формальный языки для представления базовых понятий (элементов модели) и механизмов их расширения.
Нотация представляет собой графическую интерпретацию семантики для ее визуального представления.
В UML определено три типа сущностей:
— структурная – абстракция, являющаяся отражением концептуального или физического объекта;
— группирующая – элемент, используемый для некоторого смыслового объединения элементов диаграммы;
— поясняющая (аннотационная) – комментарий к элементу диаграммы.
В следующей таблице приведено краткое описание основных сущностей, используемых в графической нотации, и основные способы их отображения.
Таблица 11.1. Сущности
| Тип | Наименование | Обозначение | Определение (семантика) |
| Структурная | Класс (class) | Множество объектов, имеющих общую структуру и поведение | |
| Объект (object) | Абстракция реальной или воображаемой сущности с четко выраженными концептуальными границами, индивидуальностью (идентичностью), состоянием и поведением. С точки зрения UML объекты являются экземплярами класса (экземплярами сущности) | ||
| Актер (actor) | Инженер службы пути | Внешняя по отношению к системе сущность, которая взаимодействует с системой и использует ее функциональные возможности для достижения определенных целей или решения частных задач. Таким образом актер – это внешний источник или приемник информации | |
| Вариант использования (use case) | Описание выполняемых системой действий, которая приводит к значимому для актера результату | ||
| Состояние (state) | Описание момента в ходе жизни сущности, когда она удовлетворяет некоторому условию, выполняет некоторую деятельность или ждет наступления некоторого события | ||
| Кооперация (collaboration) | Описание совокупности экземпляров актеров, объектов и их взаимодействия в процессе решения некоторой задачи | ||
| Компонент (component) | Физическая часть системы (файл), в том числе модули системы, обеспечивающие реализацию согласованного набора интерфейсов | ||
| Интерфейс (interface) | iРасчет | Совокупность операций, определяющая сервис (набор услуг), предоставляемый классом или компонентом | |
| Узел (node) | Физическая часть системы (компьютер, принтер и т. д.), предоставляющая ресурсы для решения задачи | ||
| Группирующая | Пакет (package) | Общий механизм группировки элементов. В отличие от компонента, пакет – чисто концептуальное (абстрактное) понятие. Частными случаями пакета являются система и модель | |
| Фрагмент (fragment) | Область специфического взаимодействия экземпляров актеров и объектов. Любая диаграмма в UML также является фрагментом – фрагментом (частью) проекта. | ||
| Раздел деятельности (activity partition) | Группа операций (зона ответственности), выполняемых одной сущностью (актером, объектом, компонентом, узлом и т.д.) | ||
| Прерываемый регион (interruptible activity region) | Группа операций, обычная последовательность выполнения которых может прервана в результате наступления нестандартной ситуации | ||
| Поясняющая | Примечание (comment) | Комментарий к элементу. Присоединяется к комментируемому элементу штриховой линией |
В некоторых источниках, в частности [24, 29], выделяют также поведенческие сущности взаимодействия и конечные автоматы, но с логической точки зрения их следует отнести к диаграммам.
Некоторые из приведенных выше сущностей в соответствии с приципами иерархического упорядочивания и декомпозиции подразумевают их подробное описание на диаграммах декомпозиции. На диаграмме верхнего уровня они помечаются особым значком или меткой.
Таблица 11.2. Декомпозируемые сущности
В следующей таблице приведено описание всех видов отношений UML, используемых на диаграммах для указания связей между сущностями.
Таблица 11.3. Отношения
| Наименование | Обозначение | Определение (семантика) |
| Ассоциация (association) | Отношение, описывающее значимую связь между двумя и более сущностями. Наиболее общий вид отношения | |
| Агрегация (aggregation) | Подвид ассоциации, описывающей связь «часть»–»целое», в котором «часть» может существовать отдельно от «целого». Ромб указывается со стороны «целого». Отношение указывается только между сущностями одного типа | |
| Композиция (composition) | Подвид агрегации, в которой «части» не могут существовать отдельно от «целого». Как правило, «части» создаются и уничтожаются одновременно с «целым» | |
| Зависимость (dependency) | Отношение между двумя сущностями, в котором изменение в одной сущности (независимой) может влиять на состояние или поведение другой сущности (зависимой). Со стороны стрелки указывается независимая сущность | |
| Обобщение (generalization) | Отношение между обобщенной сущностью (предком, родителем) и специализированной сущностью (потомком, дочкой). Треугольник указывается со стороны родителя. Отношение указывается только между сущностями одного типа | |
| Реализация (realization) | Отношение между сущностями, где одна сущность определяет действие, которое другая сущность обязуется выполнить. Отношения используются в двух случаях: между интерфейсами и классами (или компонентами), между вариантами использования и кооперациями. Со стороны стрелки указывается сущность, определяющее действие (интерфейс или вариант использования) |
Для ассоциации, агрегации и композиции может указываться кратность (англ. multiplicity), характеризующая общее количество экземпляров сущностей, участвующих в отношении. Она, как правило, указывается с каждой стороны отношения около соответствующей сущности. Кратность может указываться следующими способами:
— * – любое количество экземпляров, в том числе и ни одного;
— целое неотрицательное число – кратность строго фиксирована и равна указанному числу (например: 1, 2 или 5);
— перечисление целых неотрицательных чисел и диапазонов через запятую (например: 1, 3..5, 10, 15..*).
Если кратность не указана, то принимается ее значение, равное 1. Кратность экземпляров сущностей, участвующих в зависимости, обобщении и реализации, всегда принимается равной 1.
В следующей таблице приведено описание механизмов расширения, применяемых для уточнения семантики сущностей и отношений. В общем случае, механизм расширения представляет собой строку текста, заключенную в скобки или кавычки.
Таблица 11.4. Механизмы расширения
| Наименование | Обозначение | Определение (семантика) |
| Стереотип (stereotype) | « » | Обозначение, уточняющее семантику элемента нотации (например: зависимость со стереотипом «include» рассматривается, как отношение включения, а класс со стереотипом «boundary» – граничный класс) |
| Сторожевое условие (guard condition) | [ ] | Логическое условие (например: [A > B] или [идентификация выполнена]) |
| Ограничение (constraint) | Правило, ограничивающее семантику элемента модели (например, <время выполнения менее 10 мс>) | |
| Помеченное значение (tagged value) | Новое или уточняющее свойство элемента нотации (например: |
Помимо стереотипов, указываемых в виде строки текста в кавычках, на диаграммах могут использоваться графические стереотипы. На следующем рисунке приведены примеры стандартного и стереотипного отображения класса-сущности.
| a) стандартное обозначение | б) стандартное обозначение с текстовым стереотипом | в) графический стереотип |
Рис. 11.2. Примеры стандартного и стереотипного отображения класса
Диаграмма представляет собой группировку элементов нотации для отображения некоторого аспекта разрабатываемой информационной системы. Диаграммы представляют собой, как правило, связный граф, в котором сущности являются вершинами, а отношения – дугами. В следующей таблице дана краткая характеристика диаграмм UML [26].
Таблица 11.5. Диаграммы
| Диаграмма | Назначение | Тип диаграммы (модели ИС) | ||||
| по учету специфики средств итоговой реализации моделируемой сущности | по учету фактора времени | по семантике (сущности) содержания | ||||
| Вариантов использования (use case) | Отображает функции системы, взаимодействие между актерами и функциями | Логическая | Статическая | Функциональная | ||
| Классов (class) | Отображает набор классов, интерфейсов и отношений между ними | Логическая или физическая | Статическая | Функционально-информационная | ||
| Пакетов (package) | Отображает набор пакетов и отношений между ними | Логическая или физическая | Статическая | Компонентная | ||
| Поведения (behavior) | Автоматов (state machine) | Отображает состояния сущности и переходы между ними в процессе ее жизненного цикла | Логическая | Динамическая | Поведенческая | |
| Деятельности (activity) | Отображает бизнес-процессы в системе (описание алгоритмов поведения) | |||||
| Взаимодействия (interaction) | Последовательности (sequence) | Отображает последовательность передачи сообщений между объектами и актерами | ||||
| Коммуникации (communication) | Аналогична диаграмме последовательности, но основной акцент делается на структуру взаимодействия между объектами | |||||
| Реализации (implementation) | Компонентов (component) | Отображает компоненты системы (программы, библиотеки, таблицы и т.д.) и связи между ними | Физическая | Статическая | Компонентная | |
| Развертывания (deployment) | Отображает размещение компонентов по узлам сети, а также ее конфигурацию | |||||
Стандарт UML 2.x определяет также дополнительные, узкоспециализированные диаграммы:
При разработке отдельной модели системы в Унифицированном процессе строят несколько видов диаграмм. Более того, при разработке модели сложной системы, как правило, строят несколько диаграмм одного и того же вида. В то же время можно не создавать отдельные виды диаграмм, если в этом нет необходимости. Например, диаграммы последовательности и коммуникации являются взаимозаменяемыми, диаграммы автоматов строятся только для объектов, обладающих сложным поведением. В следующей таблице приведены рекомендации о необходимости разработки (уточнении) диаграмм по моделям системы.
Таблица 11.6. Связь моделей и диаграмм
В приведенной таблице не приведена модель тестирования, так как в рамках ее построения диаграммы не разрабатываются, а проверяются (тестируются) на полноту и непротиворечивость.
Часть диаграмм после их построения требует развития и уточнения в рамках разработки следующей модели (технологического процесса). Так, например, диаграммы вариантов использования должны быть уточнены при разработке модели анализа. В моделях вариантов использования и анализа разрабатывается и уточняется диаграмма классов анализа, а в модели проектирования – итоговая детализированная диаграмма классов. Как правило, диаграмма классов анализа и диаграмма классов существуют независимо.
1 Класс анализа – укрупненный класс, который требует дальнейшей детализации и декомпозиции на несколько более мелких классов.
Вопросы для самопроверки
4. Дайте определение понятию «сторожевое условие».