Что такое нотация 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. Дайте определение понятию «сторожевое условие».
Простое руководство по UML-диаграммам и моделированию баз данных
Унифицированный язык моделирования (UML) играет важную роль в разработке программного обеспечения, а также в системах, не связанных с ИТ, во многих отраслях, поскольку он дает возможность визуально показать поведение и структуру системы или процесса. UML помогает продемонстрировать возможные ошибки в структурах приложений, поведении системы и других бизнес-процессах.
Почему UML?
Впервые UML появился еще в 1990-х годах благодаря трем инженерам-программистам — Грэди Бучу, Ивару Джекобсону и Джеймсу — поскольку они хотели разработать менее хаотичный способ представления разработки все более сложного программного обеспечения, в то же время отделяя методологию от самого процесса. Сегодня UML по-прежнему является стандартной практической нотацией для разработчиков, а также для руководителей проектов, владельцев бизнеса, технических предпринимателей и специалистов из разных отраслей.
Каковы преимущества UML?
Типы диаграмм UML
Существует два основных типа диаграмм UML: структурные диаграммы и поведенческие диаграммы (а внутри этих категорий имеется много других). Эти варианты существуют для представления многочисленных типов сценариев и диаграмм, которые используют разные типы людей.
От заказчиков и руководителей проектов до технических писателей, конструкторов, аналитиков, программистов и тестеров — представители каждой роли будут использовать конкретную диаграмму в соответствии со своими потребностями. Это означает, что каждый шаблон требует различного фокуса и уровня детализации. Цель UML — визуально представить диаграммы, которые легко понять каждому.
Пример базовой диаграммы последовательности UML. Шаблон доступен длязагрузки
Давайте посмотрим внимательнее:
Структурные диаграммы
Структурные диаграммы представляют статическую структуру программного обеспечения или системы, они также показывают различные уровни абстракции и реализации. Они используются, чтобы помочь визуализировать различные структуры, составляющие систему, например, базу данных или приложение. Они показывают иерархию компонентов или модулей и то, как они связаны и взаимодействуют между собой. Эти инструменты обеспечивают руководство работы и гарантируют, что все части системы функционируют так, как задумано по отношению ко всем остальным частям.
Поведенческие диаграммы
Основное внимание здесь уделяется динамическим аспектам системы программного обеспечения или процесса. Эти диаграммы показывают функциональные возможности системы и демонстрируют, что должно происходить в моделируемой системе.
Давайте подробнее рассмотрим различные типы диаграмм UML, которые относятся к каждой категории:
1. Структурные диаграммы UML
2. Поведенческие диаграммы UML
Модели базы данных
UML также завоевывает популярность как нотация для моделирования баз данных. Эти модели являются отличным визуальным инструментом для проведения мозгового штурма, создания диаграмм в свободной форме и совместной работы над идеями.
Хотя UML не имеет спецификаций для моделирования данных, он может быть полезным инструментом для построения диаграмм, тем более что данные из баз данных могут использоваться в объектно-ориентированном программировании.
Давайте рассмотрим различные типы моделей баз данных, которые вы можете создать:
Упрощение с помощью программного обеспечения
Создаете ли вы модели баз данных или диаграммы UML, использование программных инструментов упрощает и улучшает этот процесс. Обязательно выберите инструменты, которые позволят вам:
При разработке программного обеспечения и непрограммируемых систем во многих отраслях использование визуальных UML-диаграмм может играть важную роль в построении поведенческих процессов и структур. Узнайте больше о создании диаграмм UML с помощью программного обеспечения при помощи пошаговой инструкции: руководства.
Сведения об авторе
Основы бизнес-моделирования: 5 популярных нотаций с примерами
В этой статье мы поговорим про основы бизнес-анализа и рассмотрим наиболее популярные на сегодня нотации моделирования UML, BPMN и EPC, а также покажем, почему структурные методы IDEF0, IDEF1 и DFD до сих пор актуальны. Читайте в этом материале, где и как использовать различные нотации бизнес-моделирования и что рекомендует руководство BABOK.
Что такое бизнес-моделирование: взгляд BABOK на многообразие нотаций
Прежде всего отметим, что цель этой статьи – не научить читателя рисовать диаграммы в той или иной нотации моделирования, а показать возможности этих инструментов для практикующего бизнес-аналитика. Начнем с определения: нотация бизнес-моделирования – это система графических элементов, символов и условных обозначений, для описания процессов или систем, позволяющая описать ключевые понятия предметной области и их взаимоотношения. Используемые при этом символы, условные и графические обозначения составляют алфавит нотации, с которым можно работать по специальным правилам применения его элементов [1]. Существует множество нотаций, используемых при описании бизнес-процессов и проектировании информационных систем, например, один только стандарт UML (Unified Modeling Language) включает 12 видов диаграмм для объектного моделирования при разработке программного обеспечения [2].
Семейство стандартов IDEF (ICAM или Integrated DEFinition) насчитывает целых 14 методологий, каждая из которых предназначена для моделирования процессов или систем с определенной точки зрения. Например, IDEF0 наглядно показывает структуру процессов и систем за счет функциональной декомпозиции, IDEF1x используется при проектировании реляционных баз данных, позволяя создавать ERD-диаграммы (Entity Relationship Diagram), с помощью IDEF3 можно документировать логику выполнения процесса и пр. [3]. Наконец, среди наиболее часто используемых на практике нотаций стоит упомянуть DFD (Data Flow Diagram, диаграммы потоков данных), EPC (Event-driven Process Chain, событийная цепочка процессов) и BPMN (Business Process Management Notation, нотация моделирования бизнес-процессов).
Некоторые из перечисленных нотаций частично дублируют назначение друг друга и даже похожи визуально. К примеру, у BPMN очень много общего с EPC и UML-диаграммой деятельности (Activity Diagram), а также процессным методом IDEF3 [4]. В свою очередь, объектный метод IDEF3 пересекается с UML-диаграммой состояний (State Diagram) [5], а IDEF4 вообще включает целый набор методов, аналогичных UML, позволяя проектировать систему «сверху вниз» через моделирование классов, объектов и взаимоотношений между ними [6].
Чтобы не запутаться в многообразии различных нотаций моделирования, бизнес-аналитику стоит помнить, что все эти диаграммы – всего лишь инструмент для описания процесса или системы с определенного ракурса. В частности, профессиональное руководство BABOK (Business Analysis Body of Knowledge) по бизнес-анализу [7], о котором мы рассказывали здесь, поясняет, что для комплексного описания системы следует использовать несколько нотаций моделирования, т.к. ни одна точка зрения не может автономно определить всю архитектуру сложного объекта. Более того, BABOK подчеркивает, что попытки вложить слишком много информации в одну точку зрения и представить все аспекты сложной системы, таких как набор требований к программному обеспечению, архитектура предприятия, корпоративные бизнес-процессы и пр., только усложнят видение и не позволят получить модели приемлемого качества.
Таким образом, на практике бизнес-аналитик работает с несколькими нотациями, чтоб описать бизнес-процессы предприятия или специфицировать требования к программному продукту. Разумеется, в реальности при этом используются не все вышеуказанные нотации бизнес-моделирования. Далее мы рассмотрим, какие диаграммы и для чего чаще всего применяются в практическом бизнес-анализе.
Методы описания бизнес-процессов (IDEF, DFD, BPMN, EPC, UML)
Код курса
Ближайшая дата курса
Длительность обучения
8 ак.часов
Стоимость обучения
15 000 руб.
Структура и динамика: как описать системы и бизнес-процессы
Все многообразие нотаций бизнес-моделирования можно разделить на 2 категории:
На практике все перечисленные нотации моделирования используются довольно часто, однако тут стоит отметить некоторые особенности применения в зависимости от контекста:
В заключение отметим, что все рассмотренные и другие нотации бизнес-моделирования, в первую очередь, предназначены для аналитика и могут показаться сложными для руководителя или специалиста другой предметной области. В частности, руководство BABOK отмечает, что UML и BPMN-диаграммы в большинстве случаев кажутся стейкхолдерам слишком «техническими», что затрудняет восприятие информации. Поэтому при выборе нотации как инструмента моделирования следует помнить не только о цели (что хотим описать), но и о целевой аудитории (кому будем показывать). К примеру, схемы EPC, ярко и понятно описывающие алгоритм выполнения отдельных процессов, достаточно легко воспринимаются бизнес-пользователями. Что общего между EPC и BPMN нотациями, я рассказываю в этом материале.
Пример простой EPC-диаграммы без логических ветвлений в системе Business Studio
Разумеется, эти нотации процессного моделирования не охватывают весь спектр задач по формализованному описанию бизнеса. Поэтому появляются новые методы. Например, нотации DMN и CMMN — для описания моделей принятия решений и ситуаций (бизнес-кейсов) соответственно. Подробнее об этом мы рассказываем здесь. О том, в каких случаях допустимо нарушать строгие правила формальных нотаций читайте в нашей новой статье. А про то, в каких случаях бизнес-моделирование приносит пользу бизнесу вы узнаете в этом материале.
Освоить все рассмотренные нотации моделирования и их применение с точки зрения руководства BABOK вы сможете на курсах Школы прикладного бизнес-анализа в нашем лицензированном учебном центре обучения и повышения квалификации системных и бизнес-аналитиков в Москве: