Нотация и семантика языка UML

1. Современные технологии объектно-ориентированного анализа и проектирования
2. Диаграммы "сущность-связь" (Entity-Relationship Diagrams, ERD)
3. IDEF
4. Диаграммы потоков данных (Data Flow Diagrams, DFD)
5. Основные этапы развития языка UML
6. Общая характеристика моделей объектно-ориентированного анализа и проектирования
7. Пакеты в языке UML
8. Канонические диаграммы языка UML
9. Особенности графического изображения диаграмм языка UML
10. Рекомендации по графическому изображению диаграмм языка UML
11. Диаграмма вариантов использования:
• Диаграмма вариантов использования как концептуальное представление бизнес-системы в процессе ее разработки
• Отношение ассоциации
• Отношение включения
• Отношение расширения
• Отношение обобщения
• Дополнительные обозначения языка UML для бизнес-моделирования
• Диаграмма вариантов использования для системы продажи товаров по каталогу в общих обозначениях языка UML
• Формализация функциональных требований к системе с помощью диаграммы вариантов использования
• Особенности спецификации функциональных требований на диаграмме вариантов использования
• Рекомендации по разработке диаграмм вариантов использования
12. Диаграмма классов:
• Класс. Имя класса
• Атрибуты класса
• Операции класса
• Расширение языка UML для построения моделей программного обеспечения и бизнес-систем
• Отношения и их графическое изображение на диаграмме классов:
• Отношение ассоциации
• Отношение обобщения
• Отношение агрегации
• Отношение композиции (разновидность отношения агрегации, при которой составные части целого имеют такое же время жизни, что и само целое)
• Рекомендации по построению диаграмм классов
13. Диаграмма кооперации:
• Кооперация (collaboration)
• Объекты и их графическое изображение
• Пассивные и активные объекты
• Мультиобъекты
• Диаграмма кооперации для ситуации отправки почтового сообщения клиенту из редактора электронной почты
• Составной объект
• Связи на диаграмме кооперации
• Сообщения и их графическое изображение
• Рекомендации по построению диаграмм кооперации
14. Диаграмма последовательности:
• Объекты и их изображение на диаграмме последовательности
• Сообщения на диаграмме последовательности
• Ветвление потока управления
• Рекомендации по построению диаграмм последовательности
15. Диаграмма состояний:
• Диаграмма состояний в контексте конечного автомата
• Состояние и его графическое изображение
• Переход и событие
16. Моделирование параллельного поведения с помощью диаграмм состояний:
• Составное состояние и подсостояние
• Исторические состояния
• Сложные переходы и псевдосостояния
• Рекомендации по построению диаграмм состояний
17. Диаграммы деятельности:
• Диаграмма деятельности и особенности ее построения
• Состояния деятельности и действия
• Переходы на диаграмме деятельности
• Дорожки
• Объекты на диаграмме деятельности
18. Диаграмма компонентов:
• Диаграмма компонентов и особенности ее построения
• Компоненты
• Интерфейсы
• Зависимости между компонентами
• Рекомендации по построению диаграммы компонентов
19. Диаграмма развертывания:
• Узел
• Соединения и зависимости на диаграмме развертывания
• Рекомендации по построению диаграммы развертывания
20. Паттерны проектирования и их представление в нотации UML:
• Паттерны, их классификация
• Паттерны проектирования в нотации языка UML
• Паттерн Фасад и его обозначение в нотации языка UML
• Паттерн Наблюдатель и его обозначение в нотации языка UML
21. Тест на знание нотации и семантики языка UML

Тест на знание нотации и семантики языка UML

Какое из приведенных ниже определений модели наиболее полно?

(Отметьте один правильный вариант ответа.)

Вариант 1 модель — абстракция физической системы, рассматриваемая с определённой точки зрения и представленная на некотором языке, или в графической форме

Вариант 2 модель — логическое представление физической системы в форме математического уравнения

Вариант 3 модель — визуальное представление физической системы в форме изображения

Паттерн Наблюдатель и его обозначение в нотации языка UML

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

Общее представление паттерна проектирования Наблюдатель

Паттерн Фасад и его обозначение в нотации языка UML

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

Общее представление паттерна проектирования Фасад

Изображенная параметризованная кооперация содержит 4 параметра: класс Facade (Фасад), интерфейс IFacade, интерфейсы IConcreteClass и конкретные классы ConcreteClass, в которых реализованы интерфейсы IConcreteClass. Пунктирная линия со стрелкой в форме треугольника служит для обозначения отношения реализации (не путать с отношением обобщения классов).

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

Паттерны проектирования в нотации языка UML

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

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

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

Изображение паттерна в форме параметризованной кооперации

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

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

Паттерны, их классификация

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

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

• Архитектурные паттерны
• Паттерны проектирования
• Паттерны анализа
• Паттерны тестирования
• Паттерны реализации

Рекомендации по построению диаграммы развертывания

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

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

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

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

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

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

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

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

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

Соединения и зависимости на диаграмме развертывания

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

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

Фрагмент диаграммы развертывания с соединениями между узлами

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

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

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

Графически узел на диаграмме развертывания изображается в форме трехмерного куба. Узел имеет имя, которое указывается внутри этого графического символа. Сами узлы могут представляться как на уровне типа (а), так и на уровне экземпляра (б).

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

Диаграмма развертывания, особенности ее построения

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

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

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

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

Первой из диаграмм физического представления является диаграмма компонентов. Вторая форма физического представления программной системы - это диаграмма развертывания (размещения).

Рекомендации по построению диаграммы компонентов

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

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

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

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

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

Если же проект содержит физические элементы, описание которых отсутствует в языке UML, то следует воспользоваться механизмом расширения. В частности, можно применить дополнительные стереотипы для отдельных нетиповых компонентов или помеченные значения для уточнения отдельных характеристик компонентов.

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

Зависимости между компонентами

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

Интерфейсы на диаграмме компонентов

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

Графическое изображение интерфейсов на диаграмме компонентов

Кроме того, интерфейс на диаграмме компонентов может быть изображен в виде прямоугольника класса со стереотипом << interface>> и секцией поддерживаемых операций (б). Как правило, этот вариант обозначения используется для представления внутренней структуры интерфейса.

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

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

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

Компоненты

Для представления физических сущностей в языке UML применяется специальный термин – компонент.

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

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

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

Графическое изображение компонента

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

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

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

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

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

Объекты на диаграмме деятельности

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

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

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

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

Переходы на диаграмме деятельности

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

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

Состояния деятельности и действия

Состояние деятельности (activity state) - состояние в графе деятельности, которое служит для представления процедурной последовательности действий, требующих определенного времени.

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

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

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

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