Лекция № 4 Отношения – способы, с

Лекция №

Отношения – способы, с помощью которых можно связать сущности. UML – это стандартный язык разработки моделей программных систем, но ни один замкнутый язык не в состоянии охватить нюансы всех возможных моделей в различных предметных областях. Поэтому UML является открытым языком, то есть допускает контролируемые расширения. Механизмы расширения UML включают: стереотипы (stereotype) ; тегированные значения (tagged value) ; ограничения (constraints). Разбираемся что это такое, и как это применяется?

Основные структурные сущности : Стереотипы (stereotype) — расширяют словарь UML, позволяя на основе существующих блоков языка создавать новые, специфичные для решения конкретной проблемы. Стереотип определяется следующим образом: 1. Выбирается базовый элемент UML. 2. В рамки базового элемента вносятся изменения, которые либо производят некоторую смысловую настройку элемента, либо вносят некоторые ограничения по смыслу его использования, либо фиксируют определенный вид элемента, либо. . . 3. Если возникает необходимость, для стереотипа разрабатывается специальное графическое изображение. 4. Можно использовать на здоровье.

Отношения – способы, с помощью которых можно связать сущности. Примеры стереотипов (или мы с вами уже встречались ): Наш старый знакомый интерфейс – это на самом деле стереотип такого элемента как класс. А это всего на всего, его персональная пиктограмма. Это некоторая абстрактная зависимость. А это вполне определенная зависимость.

В модели анализа используется три различных стереотипных класса: 1. Граничный класс – для моделирования взаимодействия между системой и ее актерами. 2. Управляющий класс – для представления координации, последовательности, взаимодействия и управления другими объектами. Часто применяются для инкапсуляции бизнес-логики, которая относится к конкретному варианту использования. 3. Класс сущности – моделируют информацию длительного хранения. Каждый из стереотипов предназначен для моделирования различных типов поведения, что позволяет проверить реализуемость варианта использования в рамках трехслойной архитектуры.

Основные структурные сущности : Тэгированные значения (tagged value) расширяют свойства основных конструкций UML , позволяя включать новую информацию в формальную спецификацию элемента. Пример:

Основные структурные сущности : Ограничения (constraints) расширяют семантику конструкций UML , позволяя создавать новые и отменять существующие правила. Пример:

Основные структурные сущности : Принятые деления ( common divisions) или дихотомия в ООП, UML , да и во всем объектно-ориентированном подходе. Деление «класс-объект» : Класс – это абстракция; Объект — конкретная материализация этой абстракции. Примеры:

Основные структурные сущности : Деление «интерфейс-реализация» : интерфейс декларирует некоторый контракт; Реализация представляет конкретное воплощение контракта и обязуется точно следовать объявленной семантике интерфеса. Примеры:

Отношения – способы, с помощью которых можно связать сущности. Основные представления (модель 4+1) Словарь, функциональность Производительность, масштабируемость, Пропускная способность Сборка системы, управление конфигурацией Топология системы, Распределение, поставка, установка. Поведение.

Отношения – способы, с помощью которых можно связать сущности. Виды (Кто есть что): Вид с точки зрения вариантов использования ( use case view) – охватывает варианты использования, которые описывают поведение системы, наблюдаемое конечными пользователями. Чаще всего используется аналитиками и тестерами. Описывает, не физику разработанной системы, а те силы, которые двигали ее разработкой – т. е. В UML статические аспекты моделируются с помощью диаграмм вариантов использования, а для динамических аспектов предлагается использовать диаграммы взаимодействия, состояния и действий. На практике динамика, чаще всего, просто фиксируется в виде текста в некотором специальном формате.

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

Виды (Кто есть что): Вид с точки зрения реализации ( implementation view) – охватывает компоненты и файлы, используемые для сборки системы и выпуска очередного программного продукта. Этот вид предназначен в первую очередь для управления конфигурацией версий системы, составляемых из независимых (до некоторой степени) компонентов и файлов, которые могут по-разному объединяться между собой. В UML статические аспекты этого вида представляются диаграммами компонентов, а динамические – диаграммами взаимодействия, состояний и действий. Вид с точки зрения развертывания ( deployment view) – охватывает узлы, формирующие топологию аппаратных средств системы, на которой она выполняется. В первую очередь он связан с распределением, поставкой и установкой частей, составляющих физическую систему. В UML его статические представляются диаграммами развертывания, а динамические – диаграммами взаимодействия, состояний и действий.