Методические указания по выполнению лабораторных занятий

жүктеу/скачать 3,94 Mb.

бет	52/102
Дата	01.09.2022
өлшемі	3,94 Mb.
	#38357
түрі	Методические указания

1 ... 48 49 50 51 52 53 54 55 ... 102

Байланысты:
Технология проектирования программных систем

Лекция № 10. Унифицированный язык визуального моделирования Unified Modeling Language ( UML )
10.2. Семантика и синтаксис UML
10.3. Нотация UML

Вопросы для самопроверки
1. Дайте краткую характеристику основных составляющих Унифицированного процесса: технологических процессов, исполнителей, артефактов, утилит.
2. Перечислите основные технологические процессы.
3. Назовите модели, разрабатываемые в рамках создания информационной системы, и их связь с основными технологическими процессами.
4. Перечислите основные возможности объектно-ориентированных Case-средств.
5. Перечислите базовые концепции Унифицированного процесса.
Лекция № 10. Унифицированный язык визуального моделирования Unified Modeling Language (UML)
10.1. Структура Унифицированного языка моделирования
10.2. Семантика и синтаксис UML
10.3. Нотация UML
10.1. Структура Унифицированного языка моделирования
Унифицированный язык моделирования (UML) в настоящий момент является стандартом де-факто при описании (документирования) результатов проектирования и разработки объектно-ориентированных систем. Последнюю официальную спецификацию языка можно найти на сайте www.omg.org.
Общая структура UML показана на рис. 10.1 [23–25].

Рис. 10.1. Структура UML
10.2. Семантика и синтаксис UML
Семантика – раздел языкознания, изучающий значение единиц языка, прежде всего его слов и словосочетаний [35].
Синтаксис – способы соединения слов и их форм в словосочетания и предложения, соединения предложений в сложные предложения, способы создания высказываний как части текста [35].
Таким образом, применительно к UML, семантика и синтаксис определяют стиль изложения (построения моделей), который объединяет естественный и формальный языки для представления базовых понятий (элементов модели) и механизмов их расширения.
10.3. Нотация UML
Нотация представляет собой графическую интерпретацию семантики для ее визуального представления.
В UML определено три типа сущностей:
 структурная – абстракция, являющаяся отражением концептуального или физического объекта;
 группирующая – элемент, используемый для некоторого смыслового объединения элементов диаграммы;
 поясняющая (аннотационная) – комментарий к элементу диаграммы.
В табл. 10.1 приведено краткое описание сущностей, используемых в графической нотации.
Таблица 10.1. Сущности

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

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

Наименование	Обозначение	Определение (семантика)
Ассоциация (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.
В табл. 10.3 приведено описание механизмов расширения, применяемых для уточнения семантики сущностей и отношений. В общем случае, механизм расширения представляет собой строку текста, заключенную в скобки или кавычки.
Таблица 10.3. Механизмы расширения

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

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

Рис. 12. Примеры стандартного и стереотипного отображения класса:
a – стандартное обозначение; б – стандартное обозначение с текстовым стереотипом; в – графический стереотип
Диаграмма представляет собой группировку элементов нотации для отображения некоторого аспекта разрабатываемой информационной системы. Диаграммы представляют собой, как правило, связный граф, в котором сущности являются вершинами, а отношения – дугами. В следующей таблице дана краткая характеристика диаграмм UML [23–26].
Таблица 10.4. Диаграммы

Диаграмма

Назначение

Тип диаграммы (модели ИС)

по степени физической реализации

по отображению динамики

по отображаемому аспекту

Вариантов использования
(use case)

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

Логическая

Статическая

Функциональная

Классов
(class)

Отображает набор классов, интерфейсов и отношений между ними

Логическая или
физическая

Статическая

Функционально-информационная

Поведения
(behavior)

Состояний
(statechart)

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

Логическая

Динамическая

Поведенческая

Деятельности
(activity)

Отображает бизнес-процессы в системе (описание алгоритмов поведения)

Взаимодействия
(interaction)

Последова-тельности
(sequence)

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

Кооперации
(collaboration)

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

Реализации
(implementation)

Компонентов
(component)

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

Физическая

Статическая

Компонентная
(структурная)

Развертывания
(deployment)

Отображает размещение компонентов по узлам сети, а также ее конфигурацию

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

Модель	Диаграмма
Модель	Вариантов использования	Состояний	Классов	Кооперации	Последовательности	Деятельности	Компонентов	Развертывания
Вариантов использования	+	+	+	+	+
Анализа	+	+	+	+	+
Проектирования		+	+	+	+	+
Реализации			+				+	+

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

¹Класс анализа – укрупненный класс, который требует дальнейшей детализации и декомпозиции на несколько более мелких классов.

жүктеу/скачать 3,94 Mb.

Достарыңызбен бөлісу:

1 ... 48 49 50 51 52 53 54 55 ... 102