Новиков Ф.А. Учебно-методическое пособие по дисциплине Анализ и проектирование на UML
Подождите немного. Документ загружается.
экземпляры ассоциации, т. е. связи. Но если связь связывает роли классификаторов,
т. е. слоты объектов, то она сама является слотом — слотом связи, который
называется ролью ассоциации. На диаграмме роль ассоциации синтаксически
неотличима от связи (разве что имя ассоциации не подчеркнуто, если оно
отображается).
125
ЗАМЕЧАНИЕ
У связи, в отличии от объекта, нет личного имени. Ее индивидуальность
определяется набором объектов, которые она связывает.
Диаграмма кооперации (равно как и диаграммы последовательности) описывает
поведение как взаимодействие, т. е. как протокол обмена сообщений между
объектами. Один и тот же объект может участвовать в различных взаимодействиях,
играя в них различные роли. Таким образом, взаимодействие всегда происходит в
определенном контексте, который определяется множеством участвующих во
взаимодействии объектов и связей. Несколько утрируя, можно сказать, что
диаграмма кооперации, в которой не указаны сообщения (и которая, тем самым,
синтаксически неотличима от диаграммы объектов) является контекстом
взаимодействия.
Обычно контекст выбирается с расчетом на то, чтобы описать взаимодействие,
имеющее определенную цель, скажем, выполнить сценарий варианта
использования или операцию (это наиболее типичные примеры применения
диаграмм кооперации). Варьируя контекстом (добавляя и убирая роли
классификаторов и ассоциаций), можно скрывать или показывать детали
взаимодействия, описывая поведение на разных уровнях абстракции. Чтобы
пояснить данный тезис, нужно вернуться к понятию номера сообщения,
упомянутому в разд. 4.4.1 и объяснить его детально.
Номер сообщения определяется в соответствии с положением сообщения в
последовательности сообщений данного взаимодействия. Если во взаимодействии
используются только простые или асинхронные сообщения (см. табл. 4.5), то
сообщения просто нумеруются, обычно подряд: 1, 2, 3 и т. д. Сообщения с
меньшими номерами предшествуют сообщениям с большими номерами. Если же
используются вложенные потоки управления, т. е. сообщения типа вызова
операции (см. табл. 4.5), то сообщения нумеруются более сложным образом.
Допустим сообщение вызова операции имеет номер x. Тогда сообщения,
отправляемые при выполнении этой операции будут иметь номера x.1, x.2 x.3 и т. д.
Первое сообщение, отправляемое при выполнении вызова x.1 будет иметь номер
x.1.1 и т. д. Количество точек в номер соответствует уровню вложенности потока
управления, т. е. глубине стека вызовов
(см. разд. 4.4.2). Таким образом, например,
сообщение с номером 1.2 предшествует сообщению с номером 1.2.3, а сообщение
2.1, напротив, следует за сообщением 1.2.3. Если первым во взаимодействии
является сообщение вызова, то его номер часто не указывают (такое сообщение как
бы имеет неявный номер 0), чтобы не загромождать диаграмму повторяющимся
всюду номером первого сообщения и ненужной точкой.
Такая иерархическая десятичная нумерация удобна, поскольку задает
относительный порядок сообщений на данном уровне вложенности вызовов и
125
Беда в том, что инструменты забывают подчеркивать имя связи.
позволяет описывать взаимодействие с нужной степенью детальности. Например,
если требуется раскрыть детали выполнения операции, вызванной сообщением с
номером x, т. е. показать, какие сообщения отправляются в процессе выполнения
данной операции, то достаточно добавить на диаграмму сообщения с номерами x.1,
x.2 и т. д. (а также соответствующие целевые объекты — роли классификаторов).
Если же детали не нужны на данной диаграмме, то сообщения можно удалить, при
этом номера других сообщений не меняются. Другими словами, в
последовательности сообщений, образующей взаимодействие, можно показывать
больше или меньше элементов, и при этом перенумерации элементов не требуется.
На диаграмме последовательности время жизни объекта относительно данного
взаимодействия показывается графически, с помощью смещения вниз символа
объекта, создаваемого в процессе взаимодействия и с помощью символа
уничтожения объекта (косой крест) на линии жизни уничтожаемого объекта. На
диаграмме кооперации для этой цели используются специальные ключевые слова,
которые указываются для ролей классификаторов в форме стандартных
стереотипов и/или в форме стандартных ограничений для сообщений (табл. 4.6).
Таблица 4.6. Ключевые слова для описания времени жизни объектов во взаимодействии на
диаграмме кооперации
Ключевое
слово
Способ
использования
Описание
create
стереотип операции в
сообщении
Операция создает объект, т. е. данное сообщение
является вызовом конструктора
destroy
стереотип операции в
сообщении
Операция уничтожает объект, т. е. данное сообщение
является вызовом деструктора
destroyed
ограничение роли
классификатора
Объект уничтожается в процессе описываемого
взаимодействия
New
ограничение роли
классификатора
Объект создается в процессе
описываемого
взаимодействия
transient
ограничение роли
классификатора
Объект создается и уничтожается в процессе
описываемого взаимодействия. Такой объект называется
временным. Данное ограничение эквивалентно
одновременному указанию ограничений new и
destroyed
Рассмотрим пример из информационной системы отдела кадров, уже разобранный
нами на рис. 4.49. Рис. 4.55 семантически эквивалентен рис. 4.49 — эти диаграммы
описывают одно и то же взаимодействие и поведение. Мы рекомендуем читателю
просто сравнить эти две диаграммы.
sd Create Department
form:Staff Form
c:Company
<<actor>>
somebody:Staff Manager
d:Department
3: createDpt
1: <<creation>> Open
2: Create_Department
5: <<destruction>> Close
4: <<creation>> new
Рис. 4.55. Диаграмма кооперации
На диаграмме последовательности невозможно отобразить связи, имеющие место,
но не используемые для посылки сообщений, а на диаграмме кооперации это
вполне возможно, а иногда бывает очень полезно. Большую часть деталей
статической структуры контекста, которые можно показать на диаграмме классов,
можно показать и на диаграмме кооперации. Сюда относятся имена ролей на
полюсах связей (ролей ассоциаций), направление навигации, символы агрегации и
композиции, квалификаторы и т. д. (см. разд. 4.2.6).
Роли классификаторов и ассоциаций могут применяться на диаграмме кооперации
по разному. Некоторые связи (роли ассоциаций) могут быть экземплярами
реальных (хранимых) ассоциаций, а другие могут быть сугубо временными,
нужными только для однократной передачи сообщения. Аналогично и объекты
(роли классификаторов) могут быть глобально существующими в системе, а могут
быть локальными объектами, временно используемыми для организации
взаимодействия. Чтобы отобразить все эти особенности, на диаграмме кооперации
используются стандартные стереотипы для полюсов ролей ассоциации. Список
этих стереотипов приведен в табл. 4.7.
Таблица 4.7. Стереотипы полюса роли ассоциации на диаграмме кооперации
Стереотип Описание
«association»
Объект на полюсе роли ассоциации связан с объектом на противоположном
полюсе фактической связью, реализующей ассоциацию
«global»
Объект на полюсе роли ассоциации имеет глобальную область определения
относительно объекта на противоположном полюсе
«local»
Объект на полюсе роли ассоциации имеет локальную область определения
относительно объекта на противоположном полюсе, т. е. является
временным объектом для выполнения операции
«parameter»
Объект на полюсе роли ассоциации является параметром операции объекта
на противоположном полюсе
«self»
Роль ассоциации является фиктивной связью, введенной для моделирования
вызова операции данного объекта
Рассмотрим в качестве примера реализацию операции рисования многоугольника
(см. предварительно, рис. 4.19). Мы подробно прокомментируем обозначения на
рис. 4.56, чтобы объяснить все детали нотации на диаграмме сообщений.
Взаимодействие, описывающее поведение операции, инициируется сообщением
draw. Для этого сообщения номер не задан (обычная для UML практика опускания
очевидных вещей), а посылающий сообщение объект изображен в виде анонимного
действующего лица, символизирующего источник вызова операции. Для
выполнения операции draw вызывает операция drawSegment (n–1 раз, где n —
количество вершин многоугольника). Соответствующее сообщение (оно имеет
номер 1) нагружено на связь со стереотипом «self», которая не является реальным
экземпляром ассоциации, а введена в модель только для того, чтобы послать
сообщение объекту из операции этого же объекта. При каждом вызове операции
drawSegment определяются две вершины, которые являются началом и концом
стороны многоугольника. При этом в модели не показаны никакие сообщения:
подразумевается, что нужную информацию можно получить, указывая значение
квалификатора (i и i+1, соответственно).
126
После этого с помощью сообщения с
номером 1.1 создается временный объект line и затем вызывается его операция
draw (сообщение с номером 1.2). То обстоятельство, что объект line временный
(существует только на время выполнения операции drawSegment), указывать с
помощью стандартного ограничения transient не обязательно: достаточно
стереотипа «local», указанного для имени полюса роли ассоциации segment.
126
Мы просим читателя извинить кривоватые квадратики квалификаторов и неудачно
расположенные значения i и i+1. Мы не чувствуем себя виноватыми — так сделан использованный
трафарет Visio. Но согласитесь, что UML выдерживает испытание небрежностью разработчиков
инструмента — диаграмма все равно читается.
poly : Polygon line : Line
from : Point to : Point
«
a
s
s
o
c
i
a
t
i
o
n
»
i
«
a
s
s
o
c
i
a
t
i
o
n
»
i
+
1
1 *[i:=1..n-1] : drawSegment(i:Integer)
«self »
«create» 1.1: new(from:Point, to:Point)
1.2: drawLine()
«local »
segment
d
r
a
w
(
)
Значение
квалификат ора
Внешний
агент,
вызывающий
операцию
Первое
сообщение
Сообщение с пов т орителем
Локальный
объект
операции
Стереотип
полюса
Рис. 4.56. Структурные связи и стереотипы полюса роли ассоциации на диаграмме
кооперации
Обычно объект, участвующий во взаимодействии, отображается на диаграмме
кооперации один раз, даже если он получает и отправляет несколько сообщений.
Однако иногда нужно показать, что в процессе взаимодействия объект меняет свое
состояние. Для этого используется зависимость с соответствующим стереотипом.
• «become» — зависимость с данным стереотипом проводится от объекта в
исходном состоянии к тому же самому объекту, но в измененном состоянии.
Имя состояния, как обычно, указывают в квадратных скобках.
• «copy» — данный стереотип означает, что создается новый объект — копия
исходного. После создания копия объекта существует как новый независимый
объект.
Рассмотрим еще раз пример из информационной системы отдела кадров,
относящийся к созданию подразделения. Допустим, что кадровая политика
организации требует немедленного назначения начальника при создании
подразделения (что вполне разумно, по нашему мнению). В
терминах нашей
модели это означает, что при создании новый объект boss класса Position
находится в состоянии vacant, но ему сразу же посылается сообщение occupy, в
результате чего объект boss переходит в состоянии occupied. Описание данного
взаимодействия может быть представлено диаграммой на рис. 4.57 (полезно
сопоставить эту диаграмму с диаграммой на рис. 4.53). Иногда для зависимости
указывают номер (как у сообщения), чтобы показать, при выполнении какой
именно операции происходит изменение состояния объекта.
127
127
На нашей диаграмме это не указано, т. к. использованный инструмент не поддерживает данную
возможность. В данном случае перед стереотипом «become» можно было бы указать номер 2.2.1.
Department{new}
«create» 1: new()
2: createPos()
«utility»
Company
boss [vacant]
boss [occupied]
2.1: new()
2.2: occupy()
«become»
Объект в
измененном
состоянии
Зависимость
Объект в
исходном
состоянии
Рис. 4.57. Использование зависимости на диаграмме кооперации
Нам осталось описать один дополнительный элемент нотации, применяемый на
диаграмме кооперации — мультиобъект.
Мультиобъект — это множество объектов, к которому сообщение можно
отправить, как к единому целому.
Например, допустим, что в информационной системе отдела кадров имеется
множестве объектов класса Person, представляющих информацию о людях.
Разумно предположить, что имеется функция findPerson, позволяющая найти
конкретный объект по значению некоторого атрибута, скажем, по имени. В таких
условиях предыдущий сценарий создания подразделения с немедленным
заполнением вакансии руководителя можно более детально и точно описать с
помощью диаграммы кооперации, приведенной на рис. 4.53. Фактически, данная
диаграмма кооперации является детальной реализацией операции createDpt
(полезно сравнить рис. 4.53 и 4.58).
Department{new}
«
c
r
e
a
t
e
»
1
:
n
e
w
(
d
p
t
N
a
m
e
:
S
t
r
i
n
g
)
2
:
b
o
s
s
:
=
c
r
e
a
t
e
P
o
s
(
)
4
:
o
c
c
u
p
y
(
b
o
s
s
:
P
o
s
i
t
i
o
n
,
a
B
o
s
s
:
P
e
r
s
o
n
)
«utility»
Company
boss {new}
4
.
1
o
c
c
u
p
y
(
a
B
o
s
s
:
P
e
r
s
o
n
)
«
c
r
e
a
t
e
»
2
.
1
:
n
e
w
(
)
CreateDpt(dptName:String, bossName:String)
: Person
3
:
a
B
o
s
s
:
=
f
i
n
d
P
e
r
s
o
n
(
b
o
s
s
N
a
m
e
:
S
t
r
i
n
g
)
aBoss : Person
Му льт иобъ е к т
Сообщение,
адресованное
мультиобъекту
Первое сообщение
Композиция
4
.
1
.
1
:
a
s
s
i
g
n
P
o
s
(
b
o
s
s
:
P
o
s
i
t
i
o
n
)
«
p
a
r
a
m
e
t
e
r
»
Рис. 4.58. Применение мультиобъекта на диаграмме кооперации
4.5. Моделирование параллелизма
Термин параллельность в программировании, вообще говоря, означает
"одновременное" выполнение нескольких активностей. Слово "одновременное" в
данном контексте означает, что невозможно (или не нужно) указать, какая из
активностей происходит раньше другой во времени. Другими словами,
параллельные процессы не упорядочены во времени. Тем самым термин
"параллельный" противопоставляется термину "последовательный":
последовательные активности упорядочены во времени, причем строго.
В UML с каждой параллельно выполняемой активностью связывается поток
управления. Таким образом, моделирование параллельного (равно как и
квазипараллельного) поведения средствами UML сводится к описанию
параллельных потоков управления и способов взаимодействия между ними.
Средства описания параллелизма в UML отнюдь не противопоставлены средствам
описания последовательного поведения, напротив, они образуют единое целое,
поскольку
параллельное программирование скорее общее правило, нежели
экзотическое исключение. Мы отдели обсуждение средств описания параллельного
поведения от средств описания последовательного только с целью упростить
изложение основных идей каждого из типов канонических диаграмм,
используемых для описания поведения. В последующих разделах поочередно
рассматриваются отдельные опущенные выше детали и конструкции диаграмм
описания поведения, относящиеся к моделированию параллелизма, причем эти
средства начинаются с простых и часто используемых и описываются в той же
последовательности, которая выбрана для канонических диаграмм.
4.5.1. Взаимодействие последовательных процессов
Начнем с обсуждения самого распространенного случая параллелизма. Допустим,
что имеются
128
несколько параллельно выполняющих процессов, каждый из
которых имеет свой собственный поток управления. Если эти процессы никак не
взаимодействуют друг с другом (самый распространенный случай), то нам ничего
и не нужно моделировать. Поведение каждого из процессов может быть описано
любым из рассмотренных выше способов (конечным автоматом, блок-схемой или
диаграммой взаимодействия). Если процессы не взаимодействуют, то они
независимы и с точки зрения конечного результата поведения (состояния системы
в целом) неважно, как именно реализованы параллельные процессы: как физически
параллельные выполняемые на многопроцессорном компьютере,
квазипараллельные или последовательно выполняемые в произвольном порядке.
Но с точки зрения других аспектов поведения, таких как, например,
производительность, время реакции, пропускная способность способ реализации
параллелизма является очень существенным. Мы вернемся к этому вопросу в
разд. 4.5.5, а здесь сосредоточимся на моделировании поведения
взаимодействующих процессов, которое должно обеспечивать определенную
функциональность, т. е. изменения состояния системы.
Взаимодействие в UML моделируется с помощью сообщений: синхронных (вызовы
операций) и асинхронных (посылка сигналов), см. разд. 4.4.1. Типичный вариант:
взаимодействие машин состояний разных классов с помощью действий,
выполняемых на переходах.
Рассмотрим несколько примеров на эту тему из информационной системы отдела
кадров. Пусть у нас определены два класса: Position (должность) и Person
(сотрудник), представленные на рис. 4.59. У объектов этих классов имеются по два
состояния: должность может быть вакантна (Vacant) или занята определенным
сотрудником (Occupied) и сотрудник может быть не занят (Free) ли назначен на
определенную должность (Assigned). Соответственно, у каждого из классов есть
конструктор (new) и деструктор (destroy) и по паре операций, которые
ответственны за изменение состояния объекта: у класса Position операции
называются occupy (занять должность) и free (освободить должность), а у класса
Person — assign (назначить на должность) demote (освободить от должности). У
каждого класса есть скрытый атрибут, предназначенный для хранения ссылки на
объект другого класса (т. е. между этими классами существует ассоциация) и
предусмотрена операция без побочного эффекта, возвращающая значение данного
(getPerson и getPosition, соответственно).
128
Вопрос о том, как возникают (и исчезают) параллельные потоки управления чуть более сложен и
мы вернемся к нему несколько раз в следующих четырех разделах.
Рис. 4.59. Классы Position и Person
Рассмотрим теперь, как должна выполнятся операция назначения сотрудника на
должность. Мы оставим в стороне вопрос о том, в каком классе разумно
определить данную операцию (на самом деле это совершенно не важно), и
положим, что операция назначения сотрудника на должность имеет два
параметра — сотрудника и должность:
assignP2P(person:Person,position:Position)
Допустим, что требуется обеспечить элементарный порядок в учете кадров (на
программистском языке — целостность данных): если сотрудник А назначен на
должность Б, то и в должности Б должно быть записано, что ее занимает сотрудник
А и наоборот. Другими словами, занятые должности и сотрудники должны взаимно
однозначно соответствовать друг другу, а свободные должности и сотрудники
должны быть действительно свободны и не должны содержать неадекватных
ссылок друг на друга.
129
Требуемое поведение операции assignP2P можно описать
с помощью диаграммы объектов (фактически, это контекст взаимодействия, см.
разд. 4.4.3), на которой показано, как должны измениться связи между объектами в
результате выполнения операции (рис. 4.60). В данном описании контекста
рассматривается типичный сценарий, в котором до выполнения операции
сотрудник занимает некоторую должность, а целевая должность вакантна.
129
Мы не утверждаем, что наше решение с хранением взаимных ссылок является единственно
возможным, и даже не утверждаем, что это решение является хорошим — мы рассматриваем
пример на взаимодействие конечных автоматов.
oldPosition : Position
[Occupied]
position : Position
[Vacant]
person : Person
[Assigned]
thePosition
thePerson
oldPosition : Position
[Vacant]
position : Position
[Occupied]
person : Person
[Assigned]
thePosition
thePerson
«become»
«become»
«become»
Рис. 4.60. Изменение связей и состояний объектов при выполнении операции перевода
сотрудника
Мы видим, что при назначении сотрудника на должность задействованы три
объекта: Требуемое поведения может быть обеспечено за счет взаимодействия
автоматов, реализующих поведение каждого из этих объектов. На рис. 4.61 и 4.62
приведены диаграммы машин состояний для классов Position и Person,
соответственно. Обратите внимание на изоморфизм графов переходов этих машин
состояний — это не случайное обстоятельство. Классы Position и Person в нашей
модели совершенно равноправны и их поведение по отношению друг к другу
совершенно симметрично.
Рис. 4.61. Машина состояний класса Position
Рис. 4.62. Машина состояний класса Person