- •Цели создания языка uml. Средства языка uml.
- •Диаграммы вариантов использования.
- •Действующее лицо (actor)
- •Описание
- •Предусловия
- •Основной и альтернативный потоки событий
- •Постусловия
- •Диаграммы взаимодействия
- •Диаграммы последовательности
- •Кооперативные диаграммы
- •Сравнение диаграмм последовательности и кооперативных диаграмм
- •Двухэтапный подход к разработке диаграмм взаимодействия
- •Диаграммы классов.
- •Общие сведения.
- •Атрибуты
- •Операции
- •Операции реализации
- •Операции управления
- •Операции доступа
- •Вспомогательные операции
- •Ассоциации
- •Зависимости
- •Агрегации
- •Обобщения
- •Множественность
- •Имена связей
- •Классы ассоциаций
- •Выявление связей
- •Диаграммы состояний
- •Деятельность
- •Входное действие
- •Выходное действие
- •События
- •Ограждающие условия
- •Действие
- •Диаграммы деятельностей
- •Диаграммы компонентов
- •Диаграммы размещения
Имена связей
Связи можно еще уточнить с помощью имен связей или ролевых имен. Имя связи - это обычно глагол или глагольная фраза, описывающая, зачем она нужна. Например, между классом Person (человек) и классом Company (компания) может существовать ассоциация. Можно задать в связи с этим вопрос, а зачем она нужна. Является ли объект класса Person клиентом компании, ее сотрудником или владельцем? Чтобы определить это, ассоциацию можно назвать "employs" (нанимает):
Company
|
Employs
|
Person
|
|
|
|
|
||
|
|
Имена у связей определять не обязательно. Обычно это делают, если причина создания связи не очевидна. Имя показывают около линии соответствующей связи.
Роли
Ролевые имена применяют в связях ассоциации или агрегации вместо имен для описания того, зачем эти связи нужны, Возвращаясь к примеру с классами Person и Company, можно сказать, что класс Person играет роль сотрудника класса Company Ролевые имена - это обычно имена существительные или основанные на них фразы, их показывают на диаграмме рядом с классом, играющим соответствующую роль. Как правило, пользуются или ролевым именем, или именем связи, но не обоими сразу. Как и имена связей, ролевые имена не обязательны, их дают, только если цель связи не очевидна. Пример ролей приводится ниже:
Company
|
•+Employer +Employee
|
Person
|
|
|
|
|
||
|
|
Классы ассоциаций
Классом ассоциаций (Association class), называется место, где хранятся относящиеся к ассоциации атрибуты. Допустим, например, что у нас имеется два класса, Student и Course, и возникла необходимость добавить на диаграмму атрибут Grade (Год обучения). В таком случае законный вопрос — в какой класс надо его добавить. Если мы помещаем его внутри класса Student, то нам придется вводить его для каждого посещаемого студентом курса, что слишком сильно увеличит размер этого класса. Если же мы помещаем его внутри класса Course, то нам придется задавать его для каждого посещающего этот курс студента.
Чтобы решить проблему, можно создать класс Ассоциаций. В этот класс следует поместить атрибут Grade, относящийся в большей степени к связи между курсом и студентом, чем к какому-то классу конкретно. Нотация UML для класса ассоциаций представлена ниже:
Выявление связей
Чтобы найти связи, изучите созданные к этому моменту элементы модели. Почти вся информация о связях уже была описана на диаграммах последовательности и кооперативных диаграммах. Чтобы обнаружить связи, сделайте следующее:
1. Начните с изучения диаграмм последовательности и Кооперативных диаграмм. Если на них класс А посылает сообщение классу Б, между этими классами должна быть установлена связь. Как правило, обнаруживаемые таким способом связи - это ассоциации и зависимости.
Исследуйте ваши классы на предмет наличия связей целое-часть. Любой класс, состоящий из других классов, может принимать участие в связях агрегации.
Исследуйте классы на предмет связей обобщения. Постарайтесь найти все классы, у которых может быть несколько типов или вариантов. Например, у вас может быть класс Employee (Сотрудник). В вашей компании имеется два типа сотрудников - получающих почасовую оплату и оклад. Это значит, что вам надо создать классы HourlyEmp и SalariedEmp, наследующие от класса Employee. Общие для всех сотрудников атрибуты, операции и связи следует поместить в класс Employee. Атрибуты, операции и связи, уникальные для сотрудников какого-то типа, надо поместить в классы HourlyEmp и SalariedEmp.
Изучите ваши классы еще раз, старайтесь найти все остальные связи обобщения. Постарайтесь обнаружить такие классы, которые имеют много общего. В частности, у вас могут быть классы CheckingAccount (Счет до востребования) и SavingAccount (Сберегательный счет). Данные и поведение обоих похожи друг на друга. Для этих общих элементов двух классов можно создать третий класс Account (Счет).
Будьте осторожны, работая с классами, у которых слишком много связей. Одной из особенностей хорошо спроектированного приложения является сравнительно небольшое количество связей в системе. Класс, у которого слишком много связей, должен знать о слишком большом количестве других классов системы. В результате его трудно будет использовать во второй раз, а также вносить изменения в готовое приложение. Если изменится любой из других классов, это может повлиять на данный класс.
