Добавил:
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Методичка по лабам по ООПиП.pdf
Скачиваний:
219
Добавлен:
15.09.2014
Размер:
1.77 Mб
Скачать

10

Лабораторная работа №2

«Создание логического представления проектируемой системы. Диаграммы взаимодействия»

Цели работы:

6.Научиться работать с логическим представлением системы при помощи CASE-

средства Rational Rose.

7.Изучить основные сведения о диаграммах взаимодействия UML.

8.Выполнить следующий этап учебного проекта.

Ответьте на следующие вопросы:

1.Какие представления поддерживаются в модели Rational Rose?

2.Какие диаграммы UML описывают поведение проектируемой системы «в динамике»? Какие описывают её статическую архитектуру?

Краткие теоретические сведения:

4. Логическое представление проектируемой системы в Rational Rose

Логическое представление (Logical View) проектируемой системы в Rational Rose концентрируется на том, как система будет реализовывать поведение, описанное в вариантах использования. Оно даёт подробную картину составных частей системы и описывает их взаимодействие. С помощью логического представления конструируется детальный проект системы.

Логическое представление содержит:

классы;

диаграммы классов – как правило, несколько диаграмм, каждая из которых отображает некоторое подмножество всех классов системы;

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

диаграммы состояний;

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

5. Диаграммы взаимодействия UML

Для описания поведения взаимодействующих групп объектов в UML применяются диаграммы взаимодействия (Interaction Diagrams). Как правило, диаграмма взаимодействия охватывает поведение объектов в рамках только одного варианта использования. На диаграммах взаимодействия отображается ряд объектов и те сообщения, которыми они обмениваются между собой.

Сообщение (message) – средство, с помощью которого объект-отправитель запрашивает у объекта получателя выполнение одной из его операций. Можно выделить следующие типы сообщений:

– Информационное (Informative) – сообщение, снабжающее объект-получатель ка- кой-либо информацией для обновления его состояния.

11

Запрос (Interrogative) – сообщение, запрашивающее выдачу некоторой информации об объекте получателе.

Императивное (Imperative) – сообщение, запрашивающее у объекта получателя выполнение некоторых действий.

В так называемой нотации Буча (см. список литературы [1]) сообщением называется спецификация обмена данными между объектами, при котором передается некая информация в расчете на то, что в ответ последует определенное действие, и выделяется 5 видов простых действий:

call (вызов) – вызов операции, применяемой к объекту, возможен, в том числе, и локальный вызов операции, когда объект посылает сообщение самому себе;

return (возврат) – возвращение значения вызывающему объекту;

send (послать) – посылает объекту сигнал;

create (создать) – создаёт новый объект;

destroy (уничтожить) – уничтожает объект.

Нотация UML предоставляет несколько видов диаграмм взаимодействия, наиболее распространёнными среди которых являются диаграммы последовательности (Sequence Diagrams) и диаграммы взаимодействий (Collaboration Diagrams).

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

На диаграмме последовательности основное внимание уделяется временнόй упорядоченности сообщений. На ней изображаются объекты, непосредственно участвующие во взаимодействии, и сообщения, которыми эти объекты обмениваются (см. рис. 1).

Рис. 1. Графические элементы диаграммы последовательности

Графически каждый объект изображается в виде прямоугольника, от которого начинается его линия жизни. Линия жизни отражает существование объекта во времени. Большинство объектов существует на протяжении всего времени взаимодействия, как показано на рисунке, другие могут создаваться во время взаимодействия, и тогда их линии жизни начинаются с получения сообщения со стереотипом create. Также объекты могут уничтожаться во время взаимодействия (стереотип destroy), и конец его жизни обозначается специальным символом.

12

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

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

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

Сообщения, которыми обмениваются объекты, обозначаются в виде стрелок различного вида и упорядочиваются по времени (поэтому, их порядковые номера указывать необязательно). Основные виды стрелок:

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

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

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

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

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

Для изображения ветвления используются две или более стрелки, выходящие из одной точки фокуса управления объекта. Перед порядковым номером сообщения ставится выражение-условие, например [х>0]. У всех альтернативных ветвей будет один и тот же порядковый номер, но условия на каждой ветви должны быть заданы так, чтобы два из них не выполнялись одновременно.

13

И, наконец, для моделирования итерации перед номером сообщения в последовательности ставится выражение итерации, например * [ i : = 1. . n] (или просто *, если надо обозначить итерацию без дальнейшей детализации).

b. Диаграммы коопераций

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

Восновном, описанная нотация для диаграмм последовательностей действительна

идля диаграмм коопераций, однако существуют некоторые отличия:

1.Путь – для описания связи одного объекта с другим к дальней концевой точке этой связи можно присоединить стереотип пути:

– association – соответствующий объект виден на ассоциации;

– self – объект является диспетчером операции;

– global – объект находится в глобальной области действия;

– local – объект находится в локальной области действия;

– parameter – объект является параметром.

2.Порядковый номер сообщения – для обозначения временнόй последовательности перед сообщением ставиться номер (нумерация начинается с единицы), который должен постепенно возрастать для каждого нового сообщения (2, 3 и т.д.). Для обозначения вложенности используется десятичная нотация Дьюи (1 - первое сообщение; 1.1 - первое сообщение, вложенное в сообщение 1; 1.2- второе сообщение, вложенное в сообщение 1 и т.д.). Уровень вложенности не ограничен. Для каждой связи можно показать несколько сообщений (вероятно, посылаемых разными отправителями), и каждое из них должно иметь уникальный порядковый номер.

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

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

Практическая часть:

1. Архитектурный анализ системы

Следующий этап разработки проекта – анализ системы. Примем следующие соглашения по моделированию:

1.Имена вариантов использования должны быть короткими глагольными фразами.

2.Для каждого варианта использования должен быть создан пакет Use Case Realization, включающий:

по крайней мере, одну реализацию варианта использования;

диаграмму VOPC (View of Participating Classes).

14

3.Имена классов должны быть существительными, соответствующими понятиям предметной области, и начинаться с прописной буквы. Имена атрибутов и опе-

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

Реализация варианта использования описывает конкретный вариант использования в терминах взаимодействующих объектов и представляется с помощью набора диаграмм – классов и взаимодействия (логического представления).

Сначала создайте структуру модели, аналогично рис.2.

Рис. 2. Структура модели проектируемой системы

Как видно на рис. 2, для реализации каждого варианта использования в Logical View создан отдельный пакет (Use Case Realization), а также добавлена диаграмма вариантов использования, отображающая связи между вариантами использования и их реализациями.

Затем, для построения логической модели, необходимо определить предварительные ключевые абстракции – классы анализа, добавить их в пакет Design Model, и помес-

тить на диаграмму Key Abstractions (см. рис.3).

15

Рис. 3. Диаграмма классов ключевых абстракций

В потоках событий вариантов использования классы могут быть трёх типов:

1.Граничные классы (стереотип boundary) – служат посредниками при взаимодействии внешних объектов с системой. Как правило, для каждой пары «актёр – вариант использования» определяется один такой класс. Типы граничных классов:

пользовательский интерфейс (без деталей – кнопок, окон и т.п.);

системный интерфейс (протоколы без деталей реализации);

аппаратный интерфейс (протоколы без деталей реализации).

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

3.Управляющие классы (стереотип control) – обеспечивают координацию поведения объектов в системе. В вариантах использования, где производятся только простейшие манипуляции с данными, такие классы могут отсутствовать. Как

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

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

2. Построение диаграммы последовательности

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

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

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

6. Построение диаграммы коопераций

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

Представляемые в отчёте результаты: диаграммы взаимодействий и VOPC для каждого варианта использования с необходимыми пояснениями. Также в отчёте необходимо обосновать применение той или иной диаграммы взаимодействия.

Знать ответы на контрольные вопросы.

16

Контрольные вопросы:

1.Что собой представляет логическое представление системы в Rational Rose?

2.Что общего и чем отличаются диаграммы последовательности и коопераций? Какие ещё виды диаграмм взаимодействия Вы знаете?

3.Что такое сообщение, и какие типы сообщений можно выделить?

4.Поясните понятия «линия жизни» и «фокус управления».

5.Какие разновидности сообщений доступны в Rational Rose? Поясните их смысл?