43. Диаграмма языка моделирования uml.

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

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

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

Сущности в UML :

структурные (Класс; Интерфейс ; Кооперация ; Прецедент ; Активный класс - инициатор управляющего воздействия, Компонент (физическая модель логической структуры системы); Узел (элемент реальной физической системы);

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

группирующие: Пакеты (организация элементов модели в группы)

Аннотационные (Пояснительные тексты)

Отношения (зависимость, ассоциация, обобщение, реализация)

Диаграммы

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

классов, моделирующая статическое поведение системы;

объектов, отображающая объекты и отношения между ними;

взаимодействия, отображающие связи между объектами.

состояний, моделирующая поведение системы при переходе из одного состояния в другое;

деятельности, на которой представляются переходы потоков управления от одной деятельности к другой внутри системы;

компонентов, отображающая организацию совокупности компонентов и существующие между ними зависимости;

развертывания, моделирующие физическую архитектуру системы.

Общие механизмы языка UML

• Спецификация - это текстовое представление синтаксиса и семантики соответствующего строительного блока,

• Дополнения - это дополнительные детали спецификации,

• Принятые деления (разделение диаграмм по классам и объектам),

• Механизмы расширения (допускаются контролируемые расширения).

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

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

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

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

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

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

Диаграмма классов - статическая структура модели

Основа – понятие класса ООП

Правила для ДК

• Имя класса должно быть уникальным в пределах пакета.ИК- это имя существительное в именительном падеже. Записывается имя полужирным шрифтом посередине поля и должно начинаться с заглавной буквы.

• Для абстрактного класса (не имеющего экземпляров или объектов) имя - курсив

Атрибуты класса

<квантор видимости><имя атрибута>[кратность]:<тип атрибута>=<исходное значение> {строка-свойство}

Тип атрибута - выражение, семантика которого определяется спецификацией модели.

Примеры: имя[1..2]:string

Исходное значение

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

Примеры: имя[1..2]:string=Дмитрий Александрович;точка:Point=(0,0,15)

Операция представляет собой некоторую услугу, которая предоставляется экземпляром класса по определенному требованию

Совокупность услуг характеризует поведение данного класса.

Правила записи: Запись операции располагается на отдельной строке поля

<квантор видимости><имя операции>(список параметров):<тип возвращаемого значения>{строка-свойство}

• <вид параметра><имя параметра>:<тип параметра>=<значение параметра по умолчанию>

• Вид параметра - in, out, i nout

Примеры:

+показать() +нарисовать(форма: точка = координаты, цвет:int=4) сообщение():{"ERROR"}

Отношения ДК

• Отношение зависимости

изменение одного элемента объекта влечет за собой изменение другого, зависимого объекта

Зависимость одного класса определяется некоторым множеством классов

Возможное поименование стрелки

• "access" - служит для обозначения доступности открытых атрибутов и операций класса источника для зависимого класса;

• "bind' - зависимый класс может использовать шаблон;

• "derive" - атрибуты зависимого класса могут быть вычислены по атрибутам класса источника;

• "import" - открытые атрибуты и операции класса-источника становятся частью зависимого класса;

• "refine" - зависимый класс служит уточнением класса источника на стадии проектирования.

• Отношение ассоциации

определяет некоторое отношение между классами

Отношение ассоциации: отношение агрегации:Если некий класс является составной частью другого класса

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

Отношение обобщения - описывает иерархическую структуру классов на диаграмме

Диаграмма состояний

• описывает процесс изменения состояний только одного класса

• Каждая диаграмма состояний представляет собой автомат

• Автомат описывает поведение объекта, начиная от момента его создания до момента уничтожения, т.е. всего жизненного цикла

Состояние - моделирует некоторую ситуацию, в течении которой выполняется некоторое условие

• Имя состояния – глагол в настоящем времени или причастие.

• Анонимное состояние – состояние, у которого имя отстутствует

• Список внутренних действий - это перечень действий, которые выполняются в процессе нахождения объекта в данном состоянии:

<метка-действия / выражениние-действия>

• Метка действия указывает на обстоятельства или условия, при которых будет выполняться действие. Выражение действия может использовать любые атрибуты и связи, которые принадлежат области имен или контексту моделируемого объекта. Символ "/" может не указываться, если выражение действия отсутствует

Перечень меток

• entry - указывает на действие, определенное выражением действия, которое выполняется в момент входа в данное состояние;

• exit - указывает на действие, которое определено выражением действия и выполняется в момент выхода из данного состояния;

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

• include - используется для обращения к подавтомату, следующее за ней выражение действия содержит имя подавтомата.

Пример: ввод пароля пользователем при входе в систему

Переход

• Простой переход осуществляется при наступлении некоторого события: окончания выполнения деятельности, получением объекта сообщения или приемом сигнала

• На переходе указывается имя события и могут указываться действия, производимые объектом в ответ на внешние события при переходе из одного состояния в другое

• Срабатывание перехода может зависеть от выполнения сторожевого условия.

• Строка текста перехода:

<сигнатура события>[<сторожевое условие>]<выражение действия>

• Сигнатура события описывает некоторое событие с необходимыми аргументами в виде: <имя события>(<список параметров, разделенных запятой>)

• Сторожевое условие представляет собой некоторое логическое выражение.

• Выражение действия выполняется в случае срабатывания перехода

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

отображается логика перехода от одной деятельности к другой

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

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

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

Сообщения - информация, передаваемая от одного объекта другому. Виды:

вызов процедур, выполнения операций или обозначения отдельных вложенных потоков управления

обозначение простого (не вложенного) потока управления

асинхронное сообщение между двумя объектами в некоторой процедурной последовательности

возврат из вызова процедуры

Стереотипы

• "call" - сообщение, требующее вызова операции или процедуры принимающего объекта;

• "return" - сообщение, возвращающее значение выполненной операции или процедуры вызвавшему ее объекту;

• "create" - сообщение, требующее создать другой объект для выполнения определенных действий;

• "destroy" - сообщение с явным требованием уничтожить объект;

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

• Диаграмма кооперации

отражает структурные аспекты взаимодействия объектов.

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

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

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

• Диаграмма кооперации на уровне спецификации показывает роли, которые играют участвующие во взаимодействии элементы. Элементами кооперации на этом уровне являются классы и ассоциации.

• отражает структурные аспекты взаимодействия объектов

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

• относится к отдельному варианту использования и детализирует особенности его последующей реализации

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

• включает графическое изображение объектов

Варианты записей строки текста:

• :С - анонимный объект, образуемый от класса С;

• /R - анонимный объект, играющий роль R;

• /R:C - анонимный объект, образуемый от класса С и играющий роль R;

• О/R - объект с именем О, играющий роль R;

• О:С - объект с именем О, образуемый от класса С;

• О/R:C - объект с именем О, образуемый от класса Си играющий роль R;

• /R - роль с именем R;

• :С - анонимная роль на базе класса С.

Связи между объектами

• Прямые линии

• На каждом из концов линий – имена ролей

• Может иметь стереотипы

Стереотипы:

• "association" - ассоциация;

• "parameter" - параметр метода. Соответствующий объект может быть только параметром метода;

• "local" - локальная переменная метода. Область видимости ограничена соседним объектом;

• "global" - глобальная переменная. Область видимости распространяется на всю диаграмму;

• "self" - рефлексивная связь объекта с самим собой.

Диаграммы реализации

Физическое представление моделей

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

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

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

• отображает особенности физической структуры системы

• позволяет определить архитектуру разрабатываемой системы, установив зависимости между компонентами

Цели диаграммы компонентов:

• визуализации общей структуры исходного кода программной системы;

• спецификации исполнимого варианта программной системы;

• обеспечения многократного использования отдельных фрагментов программного кода;

• представление концептуальной и физической схем баз данных

Компонент реализует некий набор интерфейсов и служит для обозначения элементов физического представления системы

имя компонента - имя исполняемого файла, имя динамической библиотеки, имя web - страницы, имена файлов с текстами программ, имя типа (<имя компонента : имя типа>)

Виды компонентов

• компоненты развертывания, которые обеспечивают выполнение системой своих функций: динамические библиотеки, html страницы, файлы справки;

• компоненты-рабочие продукты: файлы с исходными текстами программ

• компоненты исполнения: файлы с расширением exe

Пример с включением интерфейсов

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

• применяется для представления общей конфигурации и топологии распределенной программной системы и содержит распределение компонентов системы по отдельным ее узлам

• отображаются физические соединения - маршруты передачи информации между аппаратными устройствами

Цели диаграммы

• определить распределение компонентов системы по ее узлам;

• показать физические связи между всеми узлами реализации системы на этапе ее исполнения.

• Соединения означают необходимость физической реализации канала для обмена информацией между узлами

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