1. Представления модели.

2. Характеристика представлений и относящиеся к ним диаграммы.

Разделение системы на представления позволяет уменьшить сложность ее моделирования. Представление — это кон­струкции, представляющие один из аспектов моделируемой сис­темы.

Различают три основных пред­ставления:

1. Описание структуры

2. Описание динамики взаимодействия объектов

3. Управление моделями

Структурная классификация описывает системные сущности и их отношения между собой.

Динамическое поведение описывает поведение системы во време­ни.

Представление управления моделью — это описание разбиения мо­дели на иерархические блоки.

В табл. 1 приведены представления модели, используемые в языке UML и относящиеся к ним диаграммы.

Таблица 1 Представления модели и диаграммы в языке UML

Область	Представления	Диаграммы
Структурная	Статистическое	классов
	Использования	использования
	Программной реализации	компонентов
	Развертывания	развертывания
Динамическая	В виде конечного автомата	состояний
	Деятельности	деятельности
	Взаимодействия	последовательности
		кооперации
Управление моделью	Управления моделью	классов

1. СТРУКТУРНАЯ КЛАССИФИКАЦИЯ

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

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

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

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

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

Пример: В качестве примера рассмотрим компьютеризирован­ную театральную кассу.

На рис.1 приведена диаграмма классовдля системы продажи теат­ральных билетов.

Рис. 1 Диаграмма классов

Эта диаграмма частично отражает предметную область деятельно­сти театральной кассы: в ней есть такие важные классы, как Customer (Клиент), Reservation (Заказ), Ticket (Билет) и Performance (Представ­ление). Клиенты могут делать по несколько заказов, при этом один заказ принадлежит только одному клиенту. Существует два вида за­казов: Subscription Series (Абонемент) и Individual Reservation (Единич­ный заказ). В обоих случаях происходит заказ билетов — в первом случае одного, во втором — одного или нескольких. Каждый из имею­щихся в кассе билетов может быть продан как Абонемент или как Единичный заказ, но не как и то и другое одновременно. На каждое представление имеется некоторое количество билетов, снабженных уникальным номером места. Театральное представление может иден­тифицироваться постановкой, датой и временем ее исполнения.

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

В представлении использования описывается функционирование системы с точки зрения ее пользователей, которые называются в моделировании актантами (actors). Назначение представления вариантов использования — вы­явить всех актантов системы и все варианты ее использования, а также указать, какие актанты в каких вариантах использования фигурируют.

На рис. 2 изображена диаграмма использования для нашего при­мера с театральной кассой. Актантами здесь будут Kiosk (Киоск), Clerk (Кассир) и Supervisor (Начальник). Киоск представляет собой еще од­ну систему, которая принимает заказы клиента. Клиент не будет счи­таться актантом в программном приложении для театральной кассы, так как он не связан с ним напрямую. Варианты использования в на­шем примере включают в себя покупку билетов в Киоске или у Кас­сира в театре, покупку абонемента (только у Кассира) и подсчет об­щего числа продаж билетов (по требованию Начальника). Покупка билетов или абонемента имеют одну общую черту — процедуру снятия денег Клиента с его кредитной карты. В полном описании систе­мы продажи театральных билетов должны присутствовать еще не­сколько вариантов использования (например, обмен или проверка наличия свободных билетов).

Рис. 2 Диаграмма использования

2. ДИНАМИЧЕСКОЕ ПОВЕДЕНИЕ

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

На диаграммах последовательности отображаются сообщения в том же порядке, в котором они передаются во времени. Каждая роль-классификатор изображается в виде «линии жизни» (lifeline) — вер­тикальной линии, представляющей роль на протяжении взаимодей­ствия. Сообщения изображаются в виде стрелок, идущих от одной линии жизни к другой.

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

Рис. 3 Диаграмма последовательности

На рис. 3 изображена диаграмма последовательности для варианта использования Buy tickets (Купить билеты), который начинается с обращения киоска к театральной кассе. В эту же диаграмму включены шаги обращения к варианту использования charge (Снять деньги с кредитной карты), куда, в свою очередь, уже входят как общение с Киоском, так и со Службой работы с кредитными картами (credit card service).

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

Рис. 4 Диаграмма кооперации

Назначение диаграммы кооперации - показать реализацию какой-либо операции. На диаграмме указываются параметры и ло­кальные переменные операций, а также постоянные ассоциации. По­следовательность сообщений на схеме соответствует структуре вло­женных вызовов и прохождению сигналов в программе. На рис.4 изображена диаграмма кооперации для заказа билетов. Из Киоска поступает запрос в базу данных. Указатель db, кото­рый возвращается объекту TicketSeller (Продавец билетов), представ­ляет собой локальную связь с базой данных, которая поддерживается только на время взаимодействия. Продавец билетов запрашивает не­которое количество необходимых мест, находит ряд свободных би­летов по различной цене, временно блокирует их в базе данных и перенаправляет в Киоск, где Клиент выбирает из них подходящие. После того как клиент выбрал билет, со всех прочих билетов блоки­ровка снимается.

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

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

Каждое состояние — это такой период жизненного цикла объекта, когда он удовлетворяет определенным условиям. Некоторое собы­тие может привести к переходу, в результате которого объект ока­жется в новом состоянии. При переходе может выполняться дейст­вие, предписанное данному переходу.

Представление в виде конечного автомата изображается на диаграм­мах состояний.

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

На рис. 5 изображена история билета на определенное представле­ние. Исходное состояние билета (черная точка на рисунке) опреде­ляется как Доступное (Available). Места, предназначенные для абоне­ментов, распределяются перед началом театрального сезона. Первый раз бронирование оставшихся после этого мест происходит, когда клиент выбирает билет. После этого билет либо продается, либо воз­вращается в базу данных и блокировка с него снимается. Если кли­ент задерживается с выбором билета, то но истечении максимального времени транзакции билет также разблокируется. Места в абонемен­те можно обменять на другие билеты. В таком случае билеты, пред­назначенные для абонемента, снова поступают в продажу.

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

Представление деятельности является вариантом конечного автома­та, в котором показаны длительные вычислительные деятельности.

Деятельность представляет собой поток работ или выполнение опе­раций. Представление деятельности отображает как последователь­ные, так и параллельные виды деятельности.

Изображаются такие модели на диаграммах деятельности.

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

На рис. 6 изображена диаграмма деятельности для нашей театральной кассы. На ней показан весь спектр различных видов театральной деятельности по подготовке конкретного представления (если у вас есть опыт работы в театре, не принимайте наш пример слишком буквально!). Стрелками на диаграмме показаны последовательные зависимости. Например, конкретную постановку можно выбрать из ряда других еще до того, как станет известно, когда она состоится. Жирной чертой отмечены места разделения или соединения потоков управления. Уже после того, как составлено расписание постановок, театр может начать рекламировать какую-либо одну из них, покупать для нее сценарии и музыку, нанимать актеров, работать над освеще­нием, костюмами, причем делать все это можно одновременно. Впро­чем, до начала репетиций театр должен будет выбрать сценарий и нанять актеров. Диаграмма деятельности отражает реальные потоки работ в челове­ческой организации. Такое бизнес-моделирование и есть основное ее назначение. С таким же успехом ее можно использовать и при моде­лировании работы программного приложения.

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

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

Существует два физических представления: представление реализа­ции и представление развертывания.

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

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

Рис. 7 Диаграмма компонентов

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

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

Маленький именованный кружок на диаграмме изображает интер­фейс, то есть некий набор связанных друг с другом услуг. Непре­рывная линия, идущая от компонента к кружку-интерфейсу, указы­вает на то, что данный компонент обеспечивает работу интерфейса (иными словами, компонент реализует интерфейс, далее он обозна­чается как Клиент). Если же от компонента к интерфейсу идет пунк­тирная стрелка, это означает, что компонент требует для своей работы наличия доступа к данному интерфейсу. Например, компонент про­дажи билетов обеспечивает как продажи абонементов, так и группо­вые продажи билетов. Однако абонемент можно купить как в Киоске, так и у Кассира в театре, тогда как групповыми продажами занимает­ся только Кассир.

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

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

На рис. 9 вы видите диаграмму развертывания в реальном мире. На ней показаны отдельные узлы и их связи в конкретной версии системы. Информация, которую несет эта модель, полностью со­вместима с информацией описательной модели на рис.8.

Рис. 8 Диаграмма развертывания (описательный уровень)

Рис. 9 Диаграмма развертывания (уровень реального мира)

3. УПРАВЛЕНИЕ МОДЕЛЬЮ

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

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

Модель — это полное описание системы, сделанное с некой точки зрения на определенном уровне абстракции. У одной системы мо­жет одновременно быть несколько моделей, полученных с разных точек зрения, например, аналитическая модель, модель проектиро­вания и т. д. Модели отображаются как особые виды пакетов.

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

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

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

Рис. 10 Пакеты