ЛекUML
.pdf
«utility» |
|
«utility» |
Headquarters |
|
Filial |
|
|
|
Staff Manager
|
open() |
|
Staff Form |
Задержанная |
|
|||||||||
|
|
|
|
|
|
|
|
|
|
|
|
|||
create_deparment () |
|
|
|
|
|
|
|
|||||||
|
|
|
|
|
|
доставка |
|
|||||||
|
|
|
||||||||||||
|
|
|
|
|
|
|
|
|
|
|
|
|
||
|
|
|
|
|
|
|
|
CreateDpt() |
|
сообщения |
|
|||
|
|
|
|
|
|
|
|
|||||||
|
|
|
|
|
|
|
|
|||||||
|
|
|
|
|
|
|
|
|
t1 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
||
|
|
|
|
|
|
|
|
|
|
|
|
|
||
|
|
|
|
|
|
|
|
|
|
|
|
|
||
|
|
|
|
|
|
|
|
|
|
|
|
|
||
|
|
|
|
|
|
|
|
|
|
|
|
|
||
|
|
|
|
|
|
|
|
|
|
Notification() |
|
Метка времени |
||
|
|
|
|
|
|
|
|
|
|
|
|
|
||
|
|
|
|
|
|
|
|
|
|
|
||||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
close() |
|
|
|
|
|
|
|
|
|
|
||
|
|
|
|
|
|
|
|
|
Асинхронный |
t2 |
||||
|
|
|
|
|
|
|
||||||||
|
|
|
|
|
|
|
|
|
|
|
||||
|
|
|
|
|
|
|
|
|
|
|
||||
|
|
|
|
|
|
|
|
|
|
|
|
|||
|
|
|
|
|
|
|
|
|
|
|
|
сигнал |
{t2 - t1 < 24 h} |
|
Ограничение
Чтобы показать, что некоторый объект в определенный период взаимодействия имеет фокус управления, на диаграмме последовательности соответствующую часть линии жизни объекта изображают в виде узкой полоски. Фактически такая полоска означает выполнение операции объекта и называется активацией объекта. Начало активации соответствует приему сообщения вызова операции, а конец активации — завершению выполнения операции и возврату управления. При этом, если во время выполнения данной операции будет вызвана еще раз вызвана операция этого же объекта (та же самая операция, или другая), то это отмечается с помощью еще одной полоски активации, которая накладывается сбоку на первую. И так далее, глубина стека вызовов и, соответственно, количество наложенных полосок активации для одного объекта в UML, естественно, не ограничиваются.
Для наглядности на диаграмме последовательности можно показать в явном виде возврат, хотя это не обязательно: возврат управления подразумевается при использовании сообщения типа вызов операции.
Следующее средство, которое необходимо обсудить — ветвления. Сообщение может иметь сторожевое условие. Если сторожевое условие ложно, то сообщение просто не будет отправлено. Таким образом, сторожевые условия на сообщениях позволяют отобразить на одной диаграмме взаимодействия несколько альтернативных сценариев. Но UML позволяет больше: можно из одной точки активации отправить несколько различных сообщений (в том числе адресованным разным объектам), снабженных альтернативными сторожевыми условиями. Не более чем одно из этих условий должно оказаться истинным — в противном случае это будет означать одновременный вызов двух операций в одном потоке управления, что неправильно. Последний элемент диаграмм последовательности - отображения на диаграмме последовательностей состояний пассивных объектов. Приведем пример. Допустим для простоты, что менеджер персонала выполняет свою часть работы с помощью
информационной системы отдела кадров, а собственно принятие решения о найме выполняется "вручную" где-то вне отдела кадров и менеджер персонала становится известным данное решение помимо нашей системы. Тогда деятельность менеджера сводится к тому, чтобы провести интервью и полученную информацию сохранить во вновь созданном объекте класса Person, а получив решение, либо выполнить дальнейшие действия (заполнить документы и т. д., подробности мы опускаем), либо сообщить кандидату об отказе. В первом случае созданный объект переходит в состояние Accepted, а во втором — Rejected. Сам созданный объект участвует в этом взаимодействии пассивным образом: он хранит данные и меняет свое состояние по командам извне. Сообщений данный объект никаких не посылает. В таком случае можно на диаграмме последовательности на линии жизни данного объекта вместо активации показать состояния, в которые он переходит получая сообщения
Personnel Manager
open() |
Hire Form |
introduce() |
|
|
new() |
Person |
|
||
|
|
|
|
|
|
[accepted]: hire()
[rejected]: refuse() |
hire |
Accepted
refuse
Rejected
close()
5.4.3. Диаграммы кооперации
Данный тип диаграмм графически очень лаконичен и чрезвычайно выразителен.
Диаграмма кооперации (равно как и диаграммы последовательности) описывает поведение как взаимодействие, т. е. как протокол обмена сообщений между объектами. Один и тот же объект может участвовать в различных взаимодействиях, играя в них различные роли.
Номер сообщения определяется в соответствии с положением сообщения в последовательности сообщений данного взаимодействия. Если во взаимодействии используются только простые или асинхронные сообщения, то сообщения просто нумеруются, обычно подряд: 1, 2, 3 и т. д. Сообщения с меньшими номерами предшествуют сообщениям с большими номерами. Если же используются вложенные потоки управления, т. е. сообщения типа вызова операции, то сообщения нумеруются более сложным образом. Допустим сообщение вызова операции имеет номер x. Тогда сообщения, отправляемые при выполнении этой операции будут иметь номера x.1, x.2 x.3 и т. д. Первое сообщение, отправляемое при выполнении вызова x.1 будет иметь номер x.1.1 и т. д. Количество точек в номер соответствует уровню вложенности потока управления, т. е. глубине стека вызовов (см. разд. 5.4.2). Таким образом, например, сообщение с номером 1.2 предшествует сообщению с номером 1.2.3, а сообщение 2.1, напротив, следует за сообщением 1.2.3. Если первым во взаимодействии является сообщение вызова, то его номер часто не указывают (такое сообщение как бы имеет неявный номер 0), чтобы не загромождать диаграмму повторяющимся всюду номером первого сообщения и ненужной точкой.
На диаграмме последовательности время жизни объекта относительно данного взаимодействия показывается графически, с помощью смещения вниз символа объекта, создаваемого в процессе взаимодействия и с помощью символа уничтожения объекта (косой крест) на линии жизни уничтожаемого объекта. На диаграмме кооперации для этой цели используются специальные ключевые слова, которые указываются для ролей классификаторов в форме стандартных стереотипов и/или в форме стандартных ограничений для сообщений.
Ключевые слова для описания времени жизни объектов во взаимодействии на диаграмме кооперации
Ключевое |
Способ |
|
|
|
Описание |
|
||
слово |
использования |
|
|
|
|
|
||
create |
стереотип |
операции |
в |
Операция создает объект, т. е. данное |
||||
|
сообщении |
|
|
|
сообщение является вызовом конструктора |
|||
destroy |
стереотип |
операции |
в |
Операция уничтожает объект, т. е. данное |
||||
|
сообщении |
|
|
|
сообщение является вызовом деструктора |
|||
destroyed |
ограничение |
роли |
Объект |
уничтожается |
|
в процессе |
||
|
классификатора |
|
|
описываемого взаимодействия |
||||
new |
ограничение |
роли |
Объект |
создается |
в |
процессе |
||
|
классификатора |
|
|
описываемого взаимодействия |
||||
transient |
ограничение |
роли |
Объект создается и уничтожается в |
|||||
|
классификатора |
|
|
процессе |
описываемого |
взаимодействия. |
||
|
|
|
|
|
Такой объект называется временным. |
|||
|
|
|
|
|
Данное |
ограничение |
|
эквивалентно |
|
|
|
|
|
одновременному указанию |
ограничений |
||
new и destroyed
«create» 1: open() |
Роль |
|
2: create_deparment () |
классификатора |
|
«destroy» 3: close() |
|
|
|
|
|
|
Staff Form{transient} |
|
|
|
|
|
|
|
Staff Manager
Связь
2.1: CreateDpt()
Сообщение
|
|
«utility» |
Department{new} |
|
|
|
Company |
|
|
|
|
|
|
|
«create» 2.1.1: new()
Стереотип,номеритело сообщения
Роли классификаторов и ассоциаций могут применяться на диаграмме кооперации по разному. Некоторые связи (роли ассоциаций) могут быть экземплярами реальных (хранимых) ассоциаций, а другие могут быть сугубо временными, нужными только для однократной передачи сообщения. Аналогично и объекты (роли классификаторов) могут быть глобально существующими в системе, а могут быть локальными объектами, временно используемыми для организации взаимодействия. Чтобы отобразить все эти особенности, на диаграмме кооперации используются стандартные стереотипы для полюсов ролей ассоциации.
Стереотипы полюса роли ассоциации на диаграмме кооперации
Стереотип |
Описание |
«association» |
Объект на полюсе роли ассоциации связан с объектом на |
|
противоположном полюсе фактической связью, реализующей |
|
ассоциацию |
«global» |
Объект на полюсе роли ассоциации имеет глобальную область |
|
определения относительно объекта на противоположном |
|
полюсе |
«local» |
Объект на полюсе роли ассоциации имеет локальную область |
|
определения относительно объекта на противоположном |
|
полюсе, т. е. является временным объектом для выполнения |
|
операции |
«parameter» |
Объект на полюсе роли ассоциации является параметром |
|
операции объекта на противоположном полюсе |
«self» |
Роль ассоциации является фиктивной связью, введенной для |
|
моделирования вызова операции данного объекта |
Нужно описать еще один дополнительный элемент нотации, применяемый на диаграмме кооперации — мультиобъект. Мультиобъект — это множество объектов, к которому сообщение можно отправить, как к единому целому.
Например, допустим, что в информационной системе отдела кадров имеется множестве объектов класса Person, представляющих информацию о людях. Разумно предположить, что имеется функция findPerson, позволяющая найти конкретный объект по значению некоторого атрибута, скажем, по имени. В таких условиях предыдущий сценарий создания подразделения с немедленным заполнением вакансии руководителя можно более детально и точно описать с помощью следующей диаграммы кооперации
Первоесообщение
CreateDpt(dptName:String,bossName:String) 
|
«create» 1: new(dptName:String) |
|
|
2: boss:=createPos() |
|
|
4: occupy(boss:Position,aBoss:Person) |
|
«utility» |
|
Department{new} |
Company |
|
|
|
|
|
|
|
|
Сообщение, адресованное
мультиобъекту
3 |
: |
|
Мультиобъект : Person
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
i |
n |
g |
) |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
: |
S |
tr |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
am |
e |
|
|
|
|
||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
s |
s |
N |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
o |
|
|
|
|
|
|
|
|
|||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
b |
|
|
|
|
|
|
|
|
|
|||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
( |
|
|
|
|
|
|
|
|
|
|
|||
|
|
|
|
|
|
|
|
|
|
|
|
|
n |
|
|
|
|
|
|
|
|
|
|
|
|||
|
|
|
|
|
|
|
|
|
|
|
|
so |
|
|
|
|
|
|
|
|
|
|
|
|
|||
|
|
|
|
|
|
|
|
|
|
|
r |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
||
|
|
|
|
|
|
|
|
|
P |
e |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
||
|
|
|
|
|
|
|
|
d |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
||
|
|
|
|
|
|
fi |
n |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|||
|
|
|
s |
: |
= |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
||
|
|
s |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|||
|
Bo |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
||
a |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
) |
|
|
|
) |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
( |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
w |
|
|
|
n |
|
|
|||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
e |
|
|
o |
|
|
|
|||
|
|
|
|
|
|
|
|
|
|
|
|
: |
n |
|
|
rs |
|
|
|
|
||||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
e |
|
|
|
|
|
|
|||
|
|
|
|
|
|
|
|
|
|
|
.1 |
|
|
|
:P |
|
|
|
|
|
|
|
||
|
|
|
|
|
|
|
|
|
|
|
2 |
|
|
s |
|
|
|
|
|
|
|
|
||
|
|
|
|
|
|
|
|
|
|
» |
|
|
|
s |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
o |
|
|
|
|
|
|
|
|
|
|
||
|
|
|
|
|
|
|
|
te |
|
B |
|
|
|
|
|
|
|
|
|
|
|
|||
|
|
|
|
|
|
|
a |
|
a |
|
|
|
|
|
|
|
|
|
|
|
|
|||
|
|
|
|
|
|
e |
|
|
|
( |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
r |
|
|
|
y |
|
|
|
|
|
|
|
|
|
|
|
|
|
||
|
|
|
|
c |
|
|
|
p |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
||
|
|
|
|
« |
|
|
|
u |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
||
|
|
|
|
|
|
|
c |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
||
|
|
|
|
|
|
|
c |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
.1 |
o |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|||
boss {new} |
|
|
4 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
4 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
. |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
1 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
. |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
1 |
: |
a |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|||
|
|
|
|
|
|
s |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
si |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
||
|
|
|
|
|
|
|
|
g |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
||
|
|
|
|
|
|
|
|
|
|
n |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
P |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
o |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
s( |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
b |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
o |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
s |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
s |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
: |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
P |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
o |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
s |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
iti |
|
|
|
||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
o |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
n |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
) |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
« |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
p |
|
|
|
|
|
|
|
Композиция |
|
|
|
|
|
|
|
|
|
|
|
a |
|
m |
|
|
||||||||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
r |
|
|
|
||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
a |
et |
|
||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
e |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
r |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
» |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
aBoss : Person |
||
Выводы
Конечные автоматы — базовая алгоритмическая техника моделирования поведения
Диаграмма состояний — вариант конечного автомата с различными дополнениями
Диаграмма деятельности — частный случай диаграммы состояний с различными дополнениями
Диаграммы кооперации и последовательности (диаграммы взаимодействия) семантически эквиваленты и являются протоколами выполнения (примерами)
Параллелизм на уровне программы моделируется с помощью взаимодействующих машин состояний
Лекция 6. Пакеты
Как следует структурировать модель?
6.1. Пакетная структура
Проблема управления моделями реально возникает в том случае, когда модель достаточно велика. Что значит "достаточно велика"? Однозначно на этот вопрос ответить сложно – каждый принимает решение, исходя из собственного опыта. Итак, что делать, если модель достаточно велика? Видимо, ее нужно разделить на части обозримого размера и рассматривать их по отдельности. Для этой цели в UML используется одно универсальное средство — пакет. Пакет— это группирующая сущность в UML. Хотя в UML предусмотрена только одна сущность для структурирования модели, этого оказывается достаточно. Рассмотрим свойства пакета в UML.
Отношение владения. Говорят, что пакет владеет объявленными в нем элементами модели, а элементы принадлежат владеющему ими пакету. Пакет может владеть любыми элементами модели, в частности, пакетами. Отношение владения является строгой композицией, т. е. каждый элемент модели принадлежит ровно одному пакету. Всегда имеется корневой пакет (с именем по умолчанию). Таким образом, структура пакетов по отношению владения (или вложенности) образует в модели строгую иерархию, подобную иерархии папок и файлов в файловой системе.
Пространство имен. Каждый пакет в модели образует пространство имен, т. е. область определения и использования имен. Имена однотипных элементов в одном пространстве имен уникальны — элемент данного типа однозначно определяется по имени в данном пространстве имен — в этом и состоит основное назначение пространства имен. В другом пространстве имен это имя может быть использовано для именования любого другого элемента. Например, все классы в данном пакете должны иметь различные имена, в то же время ассоциация (будучи сущностью иного типа) может иметь имя, совпадающее с именем класса. Пакет — не единственное средство образования пространства имен в UML. Все сущности, имеющие составляющие, которые не существуют отдельно от этих сущностей, образуют собственное пространство имен. Таковыми сущностями являются, в частности, классификаторы, ассоциации, машины состояний и кооперации. Например, атрибуты в разных классах могут иметь совпадающие имена, поскольку эти атрибуты принадлежат различным пространствам имен. Пространства имен вложены друг в друга. Пространства имен пакетов вложены в соответствии с иерархией отношения владения, пространства имен прочих элементов вложены в соответствии со специфической иерархией элементов. В частности, каждое составное состояние машины состояний образует вложенное пространство имен. Таким образом, пространства имен также образуют строгую иерархию. Для указания точного положения любого элемента в этой иерархии используются составные имена — последовательность имен вложенных
пространств имен, разделенных двойным двоеточием (::), которая заканчивается именем элемента.
Видимость элементов. Все элементы, которыми владеет пакет, обладают определенной видимостью. Закрытые (ключевое слово private, символ –) элементы видимы только в том пакете, где определены. Защищенные (ключевое слово protected, символ #) элементы видимы в том пакете, где определены, и во всех пакетах, которые обобщает данный (см. ниже про отношение обобщения для пакетов). Только открытые (ключевое слово public, символ +) элементы данного пакета могут быть видимы в иных пакетах.
На диаграммах пакет изображается в виде фигуры — прямоугольник с закладкой. Если внутри пакета ничего не изображено, то имя пакета пишется в основном прямоугольнике, в противном случае — в закладке. Внутри основного прямоугольника фигуры пакета можно помещать любые элементы модели — тем самым моделируется отношение владения: пакет владеет элементом, помещенным внутрь его фигуры. Отношение владения редко изображают графически — обычно его задают другими средствами. Большинство инструментов в явном виде предусматривает специальный интерфейс для задания, отображения и манипулирования отношением владения. Обычно это древовидная структура, изображающая дерево вложенности пакетов и элементов. Как правило, этот интерфейс позволяет создавать, перемещать из в пакета в пакет и удалять любые элементы модели, в том числе и пакеты.
Рассмотрим теперь, для чего же нужно строить иерархию пакетов и пространств имен при моделировании? В жизни модели большие или очень большие. Такие модели нуждаются в структуре, в противном случае они не отвечают своему основному назначению — служить средством визуализации, спецификации, проектирования и документирования. Если диаграмма в модели не помещается на экран так, чтобы тексты и значки оставались читаемыми, от модели мало проку. Если имена элементов модели состоят из десятков непонятных слов, модель трудно использовать. Если для понимания какой-то характеристики приложения нужно одновременно рассматривать десяток диаграмм, модель не отвечает своему назначению. Если для поиска ответа на конкретный вопрос нужно просмотреть всю модель подряд, она никуда не годится.
Считается (Буч, Якобсон, Рамбо), что модель имеет хорошую, удобную для работы структуру, если выполняются следующие три количественных критерия.
Количество сущностей, изображенных на всех диаграммах, примерно одинаково и равно 7±3. Если сущностей на диаграмме три или меньше, то диаграмма
недостаточно информативна, чтобы включать ее в модель отдельно. Такую диаграмму либо не стоит включать в модель, либо можно объединить с другой однородной диаграммой. Если на диаграмме больше десяти сущностей, то она, как правило, слишком трудна для понимания с одного взгляда. Такую диаграмму целесообразно разбить на несколько диаграмм.
Ширина ветвления в дереве вложенности пакетов с учетом диаграмм примерно постоянна и равна 7±3. Другими словами, пакету должны принадлежать от трех до десяти пакетов или диаграмм. Если их меньше, то не понятно, нужен ли такой малосодержательный пакет как отдельная сущность. Если больше, то в деталях пакета можно "утонуть".
Число использующих вхождений элементов модели должно быть ограничено сверху значением 7±3, при этом больше половины элементов модели должно присутствовать на диаграммах. Любой данный элемент модели может присутствовать на некотором количестве диаграмм: 0, 1 или больше..
Приведенные критерии характеризуют форму модели, но никак не затрагивают ее содержание. Структурировать модель по содержанию можно самими разными способами, перечислим три наиболее характерных.
По структуре приложения. В основу структуры пакетов кладется одна из реальных структур приложения, например, компонентная структура. Вся система разбивается на пакеты, соответствующие компонентам (или подсистемам), они, если нужно, разбиваются на более мелкие части и т. д.
По фазам процесса разработки. Модель делится на пакеты в соответствии с фазами ее создания (набор которых зависит от принятой дисциплины моделирования). Например, пакет для диаграмм концептуального уровня, пакет диаграмм детального проектирования, пакет диаграмм реализации и развертывания и т. д.
По представлениям. Модель делится на пакеты по представлениям Например, представление использования, логическое представление, представление реализации и т. д.
Авторы языка рекомендуют структурировать модель по представлениям. В более сложных моделях приходится определять достаточно много пакетов (особенно если придерживаться наших критериев локального ограничения сложности). Поэтому исходить нужно из потребностей модели, руководствуясь опытом и здравым смыслом — указанные принципы структуризации полезны, но все равно требуют размышлений при применении.
6.1.2. Отношения между пакетами
Итак, допустим, что выбрана принципиальная структура пакетов в модели (и фигуры пакетов отображены на диаграмме, описывающей
общую структуру модели). Рассмотрим отношения между пакетами в следующей последовательности:
отношения владения (вложенности); индуцированные отношения; стереотипные зависимости; обобщение.
Вложенность пакетов влечет вложенность пространств имен. Всякий элемент модели, определенный в данном пространстве имен, видит все элементы, определенные в этом же пространстве имен и во всех объемлющих пространствах имен. Имена в "параллельных" и вложенных пространствах имен не видимы для данного элемента. Если в цепочке вложенных пространств имен определены несколько разных элементов с одним именем, то для данного элемента видимым является ближайший при просмотре изнутри наружу. Значение свойства видимости самих элементов (public, protected, private), в том числе пакетов, не имеет значения для данного правила.
Например, классы A и B принадлежат пакету X, класс D принадлежит пакету Y, а класс C и пакеты X и Y принадлежат некоторому объемлющему пакету (т. к. они определены на одной диаграмме). В этом случае класс A видит классы B и C, но не видит класс D; класс B видит классы A и C, но не видит класс D; класс C не видит классы A, B и D; класс D видит класс C, но не видит классы A и B.
Класс, принадлежащий объемлющему
C пакету
Пакет
владеющий
двумя
классами
X |
|
|
|
Y |
|
|
|
||
|
|
|
|
|
|
|
|
|
Пакет |
|
|
|
|
|
|
|
|
|
|
|
|
A |
|
|
|
|
|
|
владеющий |
|
|
|
|
|
|
|
D |
|
одним |
|
|
B |
|
|
|
|
|
|
классом |
|
|
|
|
|
|
|
|
|
|
Рис. 6.2. Вложенность пакетов
Индуцированное отношение — это отношение между пакетами, которое просто отражает наличие такого же отношения между некоторыми элементами данных пакетов. Например, если указано, что пакет X зависит от пакета Y, то это означает, что один или несколько элементов модели, которыми владеет пакет X, зависят от одного или
нескольких элементов модели, которыми владеет пакет Y. При этом вовсе не подразумевается, что все элементы пакетов находятся в данном отношении — достаточно наличия одной пары.
Зависимые пакеты
|
|
|
|
|
|
|
|
|
|
|
|
|
Personell Managment |
|
|
|
|
Staff Management |
|
||||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
||||||
|
|
|
«call» |
|
«call» |
|
|||||
|
|
|
|
|
|
|
|
|
|
Отношение |
|
|
|
|
|
|
|
|
|
|
|
зависимости |
|
Независимый |
|
|
|
|
|
|
|
|
|
||
|
|
|
|
|
|
|
|
|
|||
|
Common Components |
|
|
|
|
|
|||||
|
пакет |
|
|
|
|
|
|
|
|
|
|
Существуют два специальных стандартных стереотипа отношения зависимости — «access» и «import», которые имеют сходное назначение, но различаются в некоторых деталях. В обоих случаях это отношение зависимости между пакетами, которое указывает на то, что зависимый пакет имеет доступ к открытым элементам независимого пакета (т. е. зависимый пакет "видит" открытое содержимое независимого пакета).
В приведенном случае класс A видит классы B и C, но не видит класс D; класс B видит классы A и C, но не видит класс D; класс C видит класс A, но не видит классы B и D; класс D видит классы A и C, но не видит класс
B.