- •Цели создания языка uml. Средства языка uml.
- •Диаграммы вариантов использования.
- •Действующее лицо (actor)
- •Описание
- •Предусловия
- •Основной и альтернативный потоки событий
- •Постусловия
- •Диаграммы взаимодействия
- •Диаграммы последовательности
- •Кооперативные диаграммы
- •Сравнение диаграмм последовательности и кооперативных диаграмм
- •Двухэтапный подход к разработке диаграмм взаимодействия
- •Диаграммы классов.
- •Общие сведения.
- •Атрибуты
- •Операции
- •Операции реализации
- •Операции управления
- •Операции доступа
- •Вспомогательные операции
- •Ассоциации
- •Зависимости
- •Агрегации
- •Обобщения
- •Множественность
- •Имена связей
- •Классы ассоциаций
- •Выявление связей
- •Диаграммы состояний
- •Деятельность
- •Входное действие
- •Выходное действие
- •События
- •Ограждающие условия
- •Действие
- •Диаграммы деятельностей
- •Диаграммы компонентов
- •Диаграммы размещения
Агрегации
Агрегации (aggregations) представляют собой более тесную форму ассоциации. Агрегация - это связь между целым и его частью. Например, у вас может быть класс Автомобиль, а также классы Двигатель, Покрышки и классы для других частей автомобиля. В результате объект класса Автомобиль будет состоять из объекта класса Двигатель, четырех объектов Покрышек и т.д. Агрегации показывают в виде линии с ромбиком у класса, являющегося целым:
В дополнение к простой агрегации UML вводит более сильную разновидность агрегации, называемую композицией. Согласно композиции, объект-часть может принадлежать только единственному целому, и, кроме того, как правило, жизненный цикл частей совпадает с циклом целого: они живут и умирают вместе с ним. Любое удаление целого распространяется на его части.
Такое каскадное удаление нередко рассматривается как часть определения агрегации, однако оно всегда подразумевается в том случае, когда множественность роли составляет 1..1; например, если необходимо удалить Клиента, то это удаление должно распространиться и на Заказы (и, в свою очередь, на Строки заказа).
Один класс может участвовать в нескольких отношениях агрегации с другими классами. Например, класс Машина образует такие связи со всеми ее частями: Дверь, Мотор и Покрышка.
Как и ассоциации, агрегации могут быть рефлексивными. Рефлексивные агрегации предполагают, что один экземпляр класса состоит из одного или нескольких других экземпляров того же класса.
При генерации кода для агрегации автоматически будут созданы поддерживающие ее дополнительные атрибуты. В примере автомобиля класс-целое Машина получит атрибуты, соответствующие классам Дверь, Мотор и Покрышка и всем остальным частям связи агрегации.
Обобщения
С помощью обобщений (generalization) показывают связи наследования между двумя классами. Большинство объектно-ориентированных языков непосредственно поддерживают концепцию наследования. Она позволяет одному классу наследовать все атрибуты, операции и связи другого. На языке UML связи наследования называют обобщениями и изображают в виде стрелок от класса-потомка к классу-предку:
В этом примере описаны два типа сотрудников: с почасовой оплатой и получающих оклад. Оба этих типа наследуют от класса Employee. Класс Employee в таком случае называется суперклассом (superclass), а оба производных от него класса -подклассами (subclass). Стрелка показывает направление от подкласса к суперклассу.
Общие для обоих типов элементы размещаются в классе Employee. Таким образом, классы HourlyEmp и SalariedEmp наследуют от него атрибуты Name, Address, SSN и операции Hire() и Fire().
Помимо наследуемых, каждый подкласс имеет свои собственные уникальные атрибуты, операции и связи. Класс сотрудников с почасовой оплатой имеет уникальный атрибут Rate (оплата в час), а класс сотрудников на окладе имеет уникальный атрибут Salary (Оклад).
Связи обобщения позволяют сэкономить время и усилия как при разработке, так и при дальнейшей поддержке программы. В приведенном примере вам не требуется писать и поддерживать две различные копии операции Hire() - для каждого подкласса. Достаточно разработать только одну копию. Любые сделанные в ней изменения будут автоматически наследоваться классами HourlyEmp, SalariedEmp и всеми остальными подклассами суперкласса Employee.
Определяя обобщение на диаграмме, можно развертывать структуру наследования сверху вниз или снизу вверх. В первом случае необходимо найти классы, у которых имеется несколько различных разновидностей. Например, изучив класс Employee, вы поймете, что существуют различные типы сотрудников. Если вы строите структуру снизу вверх, ищите классы, имеющие между собой что-то общее. В нашем примере, рассмотрев классы HourlyEmp и SalariedEmp, вы поймете, что они похожи друг на друга. После этого можно уже создать новый класс Employee для хранения общих элементов.
Следите за тем, чтобы не создать неуправляемую структуру. Иерархия со слишком большим количеством уровней может стать трудно управляемой. Каждое изменение в верхней части структуры немедленно отразится во всех производных классах. Хотя это может быть преимуществом, это может также затруднить анализ и управление системой. В некоторых языках большое количество уровней, кроме того, затрудняет работу приложения.
