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. Сущности

В некоторых источниках, в частности [24, 29], выделяют также поведенческие сущности взаимодействия и конечные автоматы, но с логической точки зрения их следует отнести к диаграммам.

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

Таблица 11.2. Декомпозируемые сущности

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

Таблица 11.3. Отношения

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

— * – любое количество экземпляров, в том числе и ни одного;

— целое неотрицательное число – кратность строго фиксирована и равна указанному числу (например: 1, 2 или 5);

— перечисление целых неотрицательных чисел и диапазонов через запятую (например: 1, 3..5, 10, 15..*).

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

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

Таблица 11.4. Механизмы расширения

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

Рис. 11.2. Примеры стандартного и стереотипного отображения класса

Диаграмма представляет собой группировку элементов нотации для отображения некоторого аспекта разрабатываемой информационной системы. Диаграммы представляют собой, как правило, связный граф, в котором сущности являются вершинами, а отношения – дугами. В следующей таблице дана краткая характеристика диаграмм UML [26].

Таблица 11.5. Диаграммы

Стандарт UML 2.x определяет также дополнительные, узкоспециализированные диаграммы:

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

Таблица 11.6. Связь моделей и диаграмм

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

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

1 Класс анализа – укрупненный класс, который требует дальнейшей детализации и декомпозиции на несколько более мелких классов.

Вопросы для самопроверки

4. Дайте определение понятию «сторожевое условие».

Источник