Главная / Программы / Основные диаграммы языка UML. Моделирование на UML

Основные диаграммы языка UML. Моделирование на UML

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 разработчики программного обеспечения могут обеспечить полное соглашение в используемых графических обозначениях, чтобы представить общие понятия, такие как: компонент, обобщение, класс, поведение и агрегация. За счет этого достигается большая степень концентрации на архитектуре и проектировании.

Также стоит отметить, что есть несколько видов таких диаграмм.

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

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

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

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

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

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

Диаграмма композитной/составной структуры

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

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

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

Диаграмма развертывания

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

Между артефактом и тем компонентом, который он реализует, формируется зависимость манифестации.

Диаграмма объектов

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

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

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

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

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

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

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

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

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

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

В качестве аналогов таких диаграмм могут использоваться так называемые дракон-схемы.

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

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

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

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

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

Коммуникации

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

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

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

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

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

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

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

Диаграмма сотрудничества

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

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

Диаграммы обзора взаимодействия

Это диаграммы языка UML, которые относятся к разновидности диаграмм деятельности и включают в себя одновременно элементы Sequence и конструкции потока управления.

Стоит отметить тот факт, что данный формат объединяет в себе Collaboration и Sequence diagram, которые предоставляют возможность с разных точек зрения рассматривать взаимодействие между несколькими объектами в формируемой системе.

Диаграмма синхронизации

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

В чем преимущества?

Стоит отметить несколько преимуществ, которыми отличается UML диаграмма пользования и другие:

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

Недостатки

Несмотря на то что построение UML-диаграмм отличается массой своих плюсов, довольно часто их и критикуют за следующие недостатки:

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

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

Модель UML (UML model) ‒ это совокупность конечного множества конструкций языка, главные из которых ‒ это сущности и отношения между ними.

Сами сущности и отношения модели являются экземплярами метаклассов метамодели.

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

1.4.1. Сущности

Для удобства обзора сущности в UML можно подразделить на четыре группы:

структурные;
поведенческие;
группирующие;
аннотационные.

Структурные сущности, как нетрудно догадаться, предназначены для описания структуры. Обычно к структурным сущностям относят следующие.

Объект (object) 1 ‒ сущность, обладающая уникальностью и инкапсулирующая в себе состояние и поведение.

Класс (class) 2 ‒ описание множества объектов с общими атрибутами, определяющими состояние, и операциями, определяющими поведение.

Интерфейс (interface) 3 ‒ именованное множество операций, определяющее набор услуг, которые могут быть запрошены потребителем и предоставлены поставщиком услуг.

Кооперация (collaboration) 4 ‒ совокупность объектов, которые взаимодействуют для достижения некоторой цели.

Действующее лицо (actor) 5 ‒ сущность, находящаяся вне моделируемой системы и непосредственно взаимодействующая с ней.

∇ Подобная взаимосвязь безусловно существует, что выражается на рис. Иерархия типов диаграмм для UML 1 в виде отношения зависимости со стереотипом «refine» .

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

∇∇∇ В UML 2 синтаксическая и смысловая нагрузка диаграммы состояний настолько изменилась, что название уже не отражало содержания.

Список новых диаграмм и их названий, принятых в этой книге, приведен ниже.

Диаграмма внутренней структуры (Composite Structure diagram)
Диаграмма пакетов (Package diagram)
Диаграмма автомата (State machine diagram)
Диаграмма коммуникации (Communication diagram)
Обзорная диаграмма взаимодействия (Interaction Overview diagram)
Диаграмма синхронизации (Timing diagram)

На рис. Иерархия типов диаграмм для UML 2 (часть 1 и 2) приведена диаграмма классов, отражающая взаимосвязь диаграмм в UML 2.

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

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

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

Указанная сложная форма ярлычка поддерживается не всеми инструментами. Впрочем, это не обязательно, поскольку семантика первична, а нотация вторична. Далее мы везде используем в качестве ярлычка диаграммы прямоугольник, и это не должно вызывать недоразумений.

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

Табл. Типы и теги диаграмм

Название диаграммы	Тег (стандартный)	Тег (предлагаемый)
Диаграмма использования	use case или uc	use case
Диаграмма классов	class	class
Диаграмма автомата	state machine или stm	state machine
Диаграмма деятельности	activity или act	activity
Диаграмма последовательности	interaction или sd	sd
Диаграмма коммуникации	interaction или sd	comm
Диаграмма компонентов	component или cmp	component
Диаграмма размещения	не определен	deployment
Диаграмма объектов	не определен	object
Диаграмма внутренней структуры	class	class или component
Обзорная диаграмма взаимодействия	interaction или sd	interaction
Диаграмма синхронизации	interaction или sd	timing
Диаграмма пакетов	package или pkg	package

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");

UML 2.4.1 – "ISO/IEC 19505-1:2012. Информационные технологии. Унифицированный язык моделирования группы по управлению объектами (OMG UML). Часть 1. Инфраструктура" (англ. "Information technology -- Object Management Group Unified Modeling Language (OMG UML) - Part 1: Infrastructure") и "ISO/IEC 19505-2:2012. Информационные технологии. Унифицированный язык моделирования группы по управлению объектами (OMG UML). Часть 2. Сверхструктура" (англ. "Information technology -- Object Management Group Unified Modeling Language (OMG UML) - Part 2: Superstructure").

Последнюю официальную спецификацию языка можно найти на сайте www.omg.org .

Общая структура UML показана на следующем рисунке .

Рис. 11.1. Структура UML

11.2. Семантика и синтаксис UML

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

Синтаксис – способы соединения слов и их форм в словосочетания и предложения, соединения предложений в сложные предложения, способы создания высказываний как части текста .

Таким образом, применительно к UML, семантика и синтаксис определяют стиль изложения (построения моделей), который объединяет естественный и формальный языки для представления базовых понятий (элементов модели) и механизмов их расширения.

11.3. Нотация UML

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

В UML определено три типа сущностей :

Структурная – абстракция, являющаяся отражением концептуального или физического объекта;

Группирующая – элемент, используемый для некоторого смыслового объединения элементов диаграммы;

Поясняющая (аннотационная) – комментарий к элементу диаграммы.

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

Таблица 11.1. Сущности

Тип	Наименование	Обозначение	Определение (семантика)
Структурная	(class)		Множество объектов, имеющих общую структуру и поведение
	(object)		Абстракция реальной или воображаемой сущности с четко выраженными концептуальными границами, индивидуальностью (идентичностью), состоянием и поведением. С точки зрения UML объекты являются экземплярами класса (экземплярами сущности)
	(actor)	Инженер службы пути	Внешняя по отношению к системе сущность, которая взаимодействует с системой и использует ее функциональные возможности для достижения определенных целей или решения частных задач. Таким образом актер – это внешний источник или приемник информации
	(use case)		Описание выполняемых системой действий, которая приводит к значимому для актера результату
	(state)		Описание момента в ходе жизни сущности, когда она удовлетворяет некоторому условию, выполняет некоторую деятельность или ждет наступления некоторого события
	Кооперация (collaboration)		Описание совокупности экземпляров актеров, объектов и их взаимодействия в процессе решения некоторой задачи
	(component)		Физическая часть системы (файл), в том числе модули системы, обеспечивающие реализацию согласованного набора интерфейсов
	(interface)	iРасчет	Совокупность операций, определяющая сервис (набор услуг), предоставляемый классом или компонентом
	(node)		Физическая часть системы (компьютер, принтер и т. д.), предоставляющая ресурсы для решения задачи
Группирующая	(package)		Общий механизм группировки элементов. В отличие от компонента, пакет – чисто концептуальное (абстрактное) понятие. Частными случаями пакета являются система и модель
	(fragment)		Область специфического взаимодействия экземпляров актеров и объектов
	(activity partition)		Группа операций (зона ответственности), выполняемых одной сущностью (актером, объектом, компонентом, узлом и т.д.)
	(interruptible activity region)		Группа операций, обычная последовательность выполнения которых может прервана в результате наступления нестандартной ситуации
Поясняющая	Примечание (comment)		Комментарий к элементу. Присоединяется к комментируемому элементу штриховой линией

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

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

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

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

Наименование	Обозначение	Определение (семантика)
Ассоциация (association)		Отношение, описывающее значимую связь между двумя и более сущностями. Наиболее общий вид отношения
Агрегация (aggregation)		Подвид ассоциации, описывающей связь "часть"–"целое", в котором "часть" может существовать отдельно от "целого". Ромб указывается со стороны "целого". Отношение указывается только между сущностями одного типа
Композиция (composition)		Подвид агрегации, в которой "части" не могут существовать отдельно от "целого". Как правило, "части" создаются и уничтожаются одновременно с "целым"
Зависимость (dependency)		Отношение между двумя сущностями, в котором изменение в одной сущности (независимой) может влиять на состояние или поведение другой сущности (зависимой). Со стороны стрелки указывается независимая сущность
Обобщение (generalization)		Отношение между обобщенной сущностью (предком, родителем) и специализированной сущностью (потомком, дочкой). Треугольник указывается со стороны родителя. Отношение указывается только между сущностями одного типа
Реализация (realization)		Отношение между сущностями, где одна сущность определяет действие, которое другая сущность обязуется выполнить. Отношения используются в двух случаях: между интерфейсами и классами (или компонентами), между вариантами использования и кооперациями. Со стороны стрелки указывается сущность, определяющее действие (интерфейс или вариант использования)

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

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

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

Диапазон целых неотрицательных чисел "первое число.. второе число" (например: 1..5, 2..10 или 0..5);

Диапазон чисел от конкретного начального значения до произвольного конечного "первое число.. *" (например: 1..*, 5..* или 0..*);

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

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

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

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

Наименование	Обозначение	Определение (семантика)
Стереотип (stereotype)	« »	Обозначение, уточняющее семантику элемента нотации (например: зависимость со стереотипом «include» рассматривается, как отношение включения, а класс со стереотипом «boundary» – граничный класс)
Сторожевое условие (guard condition)		Логическое условие (например: или [идентификация выполнена])
Ограничение (constraint)	{ }	Правило, ограничивающее семантику элемента модели (например, {время выполнения менее 10 мс})
Помеченное значение (tagged value)	{ }	Новое или уточняющее свойство элемента нотации (например: {version = 3.2})

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


a) стандартное обозначение		б) стандартное обозначение с текстовым стереотипом		в) графический стереотип

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

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

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

Диаграмма			Назначение
				по степени физической реализации	по отображению динамики	по отображаемому аспекту
(use case)			Отображает функции системы, взаимодействие между актерами и функциями	Логическая	Статическая	Функциональная
(class)			Отображает набор классов, интерфейсов и отношений между ними	Логическая или физическая	Статическая	Функционально-информационная
(package)			Отображает набор пакетов и отношений между ними	Логическая или физическая	Статическая	Компонентная
Поведения (behavior)	(state machine)		Отображает состояния сущности и переходы между ними в процессе ее жизненного цикла	Логическая	Динамическая	Поведенческая
	(activity)		Отображает бизнес-процессы в системе (описание алгоритмов поведения)
	Взаимодействия (interaction)	(sequence)	Отображает последовательность передачи сообщений между объектами и актерами
		(communication)	Аналогична диаграмме последовательности, но основной акцент делается на структуру взаимодействия между объектами
Реализации (implementation)	(component)		Отображает компоненты системы (программы, библиотеки, таблицы и т.д.) и связи между ними	Физическая	Статическая	Компонентная
	(deployment)		Отображает размещение компонентов по узлам сети, а также ее конфигурацию

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

Диаграмму объектов (object diagram) - аналогична , но вместо классов отображаются объекты;

Диаграмму синхронизации (timing diagram) - описывает состояния объекта с течением времени;

Композитную структурную диаграмму (composite structure diagram) - описывает порты (включая интерфейсы) класса для взаимодействия с другими классами;

Профильную диаграмму (profile diagram) - аналогична с описанием классов, входящих в них;

Обзорную диаграмму взаимодействия (interaction overview diagram) - аналогична , но со скрытыми фрагментами взаимодействия (фрагментами с меткой ref). Представляет собой контекстную (концептуальную) , элементы которой будут конкретизированы на отдельных диаграммах декомпозиции.

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

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

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

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

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

4. Дайте определение понятию " ".

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