Унифицированный язык моделирования UML

сложных систем
Знание основных изобразительных средств языка UML в версиях 1.х

… 2.0
Приобретение практических навыков моделирования в UML
Знакомство с инструментами поддерживающими UML (по выбору Rational Rose, PowerDesigner, Poseidon, ArgoUML, …)
Знание особенностей моделирования баз данных в UML
Получение представления о возможных направлениях развития UML

 Бессарабов Н.В.2008

языками.
Это расширяемый язык.
Это язык моделирования (но не имитации процессов).

Три автора

и три источника UML:
Грэди Буч (Grady Booch), метод Booch’91
Джеймс Рамбо (James Rumbaugh), метод OMT (Object Modelling Technique)
Айвар Якобсон (Ivar Jacobson), метод OOSE (Object Oriented Software Engineering)

Замечание: Термин “унифицированный” не означает
претензий на универсальность. Просто UML был создан
путем объединения как минимум трех перечисленных
выше языков.

 Бессарабов Н.В.2008

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

но это дорого, повышает требования к квалификации разработчика и обычно не понятно заказчику
Автоматический синтез программ алгоритмически неразрешим, хотя известны разрешимые подклассы
Частичная генерация кода осуществима
Визуализация позволяет подключить образное (правополушарное для правшей) мышление человека и потому облегчает создание целостного образа задачи
По визуальному представлению генерируется код
В инструментах обязательно использование механизма reverse engineering для создания визуальной модели по коду

 Бессарабов Н.В.2008

актуальном состоянии
Все элементы моделей UML позволяют вводить текстовые описания
Как

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

 Бессарабов Н.В.2008

UML 1.0
1999 г. UML 1.3
2001 г. UML 1.4
2003 г. UML

1.5
2005 г. UML 2.0

 Бессарабов Н.В.2008

смотрится лучше)

Документооборот
Бизнес – процессы
Потоки данных
Данные
 Бессарабов Н.В.2008

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

реализации на объектно-ориентированных языках.

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

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

Компромисс между понятностью и точностью.

 Бессарабов Н.В.2008

системы,
имеющие непосредственное отношение к решаемой
задаче).
2. Многомодельность (можно понимать

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

 Бессарабов Н.В.2008

Например, описание класса
без методов имеет вид:
имя_класса(А1, А2,

… ),
где Аi – атрибуты.
Тогда множество {А1, А2, … } определяет экстенсионал,
а набор всех потомков класса есть интенсионал.
Термины синтаксис, семантика и прагматика.
Синтаксис – формальная структура
Семантика – смысл и содержание понятий, моделируемых объектов
Прагматика это по сути дела ответ на вопрос “Зачем это нужно?”

 Бессарабов Н.В.2008

метамодели (понятия метакласс, метаатрибут, метаоперации). КС грамматика. Может специфицировать несколько

метамоделей, что обеспечивает возможность расширения UML.
Метамодель
Это конкретизация мета-метамодели. На этом уровне определены все основные понятия UML (такие как класс, атрибут, операция, …).
Модель
Это экземпляр метамодели. Описывает конкретную предметную область.
Объекты пользователя
На первом уровне определяются основные используемые понятия,
определяется язык спецификации метамодели. Семантика мета-мета-
модели в описание UML не входит.

 Бессарабов Н.В.2008

некоторое пространство имен. Каждый элемент
может принадлежать одному пакету. Пакет

может
вкладываться в другой пакет, образуя отношение “быть
подмножеством”. Все виды элементов модели UML
могут быть сгруппированы в пакеты.
Изображение пакета:

 Бессарабов Н.В.2008

включая агрегацию композицию и наследование;
описания структур классов, основанные на отношениях

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

 Бессарабов Н.В.2008

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

модель имеется (The Unified Software Development Process)
Не спецификация CASE-средства, но инструменты подразумеваются, имеются и многочисленны (Rose, Sun Java Studio Enterprise, Together, Sybase PowerBuilder, Enterprise Architect, Visio, ArgoUML, и т.д.)

 Бессарабов Н.В.2008

CORBA
UML XMI DTD
OCL
Всего в спецификации более 1000 страниц.
Число диаграмм –

8.

 Бессарабов Н.В.2008

Diagram Interchange
UML Extensions
UML MOF Metamodel
UML CORBA
UML XMI DTD
OCL
Объем документации резко

возрос.
Число диаграмм увеличилось до 13.

 Бессарабов Н.В.2008

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

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

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

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

Диаграмм объектов, составной структуры,
временной и обзора взаимодействий в UML-1 нет.

произвольных текстов)
Пакеты (рассматриваются в другом разделе)
2. Отношения
Ассоциации между акторами и

вариантами
Обобщения на акторах
Обобщения и зависимости между вариантами

 Бессарабов Н.В.2008

задачи взаимодействие пользователя и
информационной системы (ИС), или двух ИС,

или ИС и
устройства. Он определяет некоторый набор сценариев,
приводящих к значимому с точки зрения актора результату.
Для достижения ясности можно пробовать переписывать
варианты использования в схеме
“субъект – предикат – объект”.
Акторы – действующие субъекты.
Примеры: Менеджер по продажам, Принтер,
Бухгалтерская система
Акторы находятся вне проектируемой системы.
Актор это множество взаимосвязанных ролей.
Актор это стереотипный класс.
Важная особенность: При создании модели необходимо
выписать все существенные варианты использования.

 Бессарабов Н.В.2008

Принтер

 Бессарабов Н.В.2008

в рамках UML:
С помощью диаграмм деятельности
С помощью диаграмм взаимодействия (последовательности

и коммуникации)
Вне UML можно использовать:
Текстовые описания
Программы на псевдокоде

 Бессарабов Н.В.2008

диаграмм
Не менялись от версии UML 1.0 до версии 2.0
Могут применяться

самостоятельно
Позволяют построить предварительную модель интерфейсов пользователя и решать задачи качества (usability)
Позволяют выделить основные компоненты системы
Позволяют разработать план тестирования, может быть предварительный

 Бессарабов Н.В.2008

первым
шагом моделирования системы
Диаграммы вариантов использования дают декларативное, но не

императивное описание
Основное их назначение – показать связи с внешним миром
Диаграммы Use case не обязательно соответствуют диаграммам классов, модулей и компонентов, но позволяют определить:
1. Основные интерфейсы, в том числе пользовательские
и межпрограммные
2. Предварительные оценки производительности
каналов связи
3. Некоторые возможности повторного использования
модулей

 Бессарабов Н.В.2008

(в естественном языке)

OCL – объектно ориентированный язык предикатов
первого порядка

с равенством и ограниченными
кванторами.

 Бессарабов Н.В.2008

архитектуру, поведение и отношения с другими объектами.
 Бессарабов Н.В.2008

{строка_свойство}.
Обозначения областей видимости атрибутов знаками:
+ общедоступный (public)
#

защищенный (protected)
- закрытый (private)
Кратность атрибута характеризует наличие ни одного(0)
или нескольких атрибутов данного типа,
[0..1] - иногда есть, иногда нет
[0..1,5,7..11] - любое из перечисленных чисел
* - любая кратность
Примеры:
+ПолучитьАдрес : Address
#Цена : {$200}

 Бессарабов Н.В.2008

Не все операции должны выполняться
последовательно и не все

могут выполняться
параллельно.
Квантор видимости принимает
значения + , - , #
Список параметров:
<вид_параметра><имя_параметра><тип_параметра> =<значение_по_умолчанию>
Вид_параметра: {in, out, inout}.

операции
исполняемыми параллельно. Для указания на степень
параллельности используется строка-свойство

вида:
{concurrency = тип_параллельности}.
Типы параллельности:
Sequential -- последовательная;
Concurrent -- параллельная;
Guarded -- защищенная.
Обращения к защищенной операции должны быть
регламентированы по времени, только в этом случае
можно гарантировать правильную обработку
исключительных ситуаций.

(association relationship).
Отношения обобщения (generation relationship), это взгляд на наследование снизу

вверх.
Отношения реализации (realization relationship).
Отношения агрегации (aggregation relationship).
Отношения композиции (composition relationship).

других компонентов.
Обозначается:

класс клиент класс источник









независимый класс

зависимостей.
Применяют следующие стереотипы:
“access” - означает, что открытые атрибуты и операции

класса-источника доступны классу-клиенту.
“bind” - класс-клиент может использовать класс-источник как шаблон для своей параметризации.
“derive” - атрибуты клиента вычисляются по атрибутам источника.
“import”-открытые атрибуты и операции источника становятся частью клиента, как будто они в нем были объявлены.
“refine” - клиент уточняет источник (может быть отражая временную зависимость свойств). В UML считается, что это наиболее общий вид зависимости.

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

одним классом, входят сущности
описываемые другими классами. При этом все

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

что части не могут в каком-то смысле существовать
независимо от

целого.




Сравните с отношением обобщения

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

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

некоторые преподаватели могут быть студентами. Класс СтудентПреподаватель определен путем множественного

наследования от суперклассов Студент и Преподаватель
Проблема: предположим, что в обоих подклассах Студент и Преподаватель был создан атрибут с именем "номерКомнаты”, но с разной семантикой. Очень вероятно, что для объектов класса Студент значениями этого атрибута будут номера комнат в студенческом общежитии, а для объектов класса Преподаватель - номера служебных кабинетов. Как определить этот атрибут в классе СтудентПреподаватель?

в одном из суперклассов не будет произведено переименование атрибута "номерКомнаты";

наследовать это свойство только от одного из суперклассов, так что, например, значением атрибута "номерКомнаты" у объектов класса СтудентПреподаватель всегда будут номера служебных кабинетов;
унаследовать в подклассе оба свойства, но автоматически переименовать оба атрибута, чтобы прояснить их смысл; назвать их, например, "номерКомнатыСтудента" и "номерКомнатыПреподавателя".

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