ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 16.03.2024
Просмотров: 104
Скачиваний: 0
ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.
– главным образом, типы значений, обозначаются при помощи атрибутов, а ассоциации обозначают более значимые классы, такие как клиенты или заказы. Предпочтительно также использовать прямоугольники классов для наиболее значимых классов диаграммы, а ассоциации и атрибуты для менее важных элементов.
Двунаправленные ассоциации
Двунаправленная ассоциация, показанная на рис. 6, – это пара свойств, связанных в противоположных направлениях. Класс Car (Автомобиль) имеет свойство owner:Person[1], а класс Person (Личность) имеет свойство cars:Car[*]. (Обратите внимание, что использована множественная форма имени свойства cars по причине того, что у свойства кратность больше 1.)
Рис.6.Двунаправленнаяассоциация
Агрегация и композиция
Простая ассоциация между двумя классами отражает структурное отношение между равноправными сущностями, когда оба класса находятся на одном концептуальном уровне и ни один не является более важным, чем другой. Но иногда приходится моделировать отношение типа "часть/целое", в котором один из классов имеет более высокий ранг (целое) и состоит из нескольких меньших по рангу (частей). К примеру, можно сказать, что двигатель и колеса представляют собой части автомобиля.
Отношение
такого типа называют агрегированием (aggregation); оно причислено к отношениям типа "имеет" (с учетом того, что объектцелое имеет несколько объектовчастей). Агрегирование является частным случаем ассоциации и изображается в виде простой ассоциации с незакрашенным ромбом со стороны "целого" (рис. 7).
Наряду с агрегацией в языке UML есть более определенное свойство – композиция (composition).
Композиция — более строгий вариант агрегации. Композиция имеет жёсткую зависимость времени существования экземпляров классаконтейнера и экземпляров содержащихся классов. Если контейнер будет уничтожен, то всё его содержимое будет также уничтожено. Графически представляется так же, как и агрегация, но с закрашенным ромбиком.
На рис. 8 экземпляр класса Point (Точка) может быть частью многоугольника, а может представлять центр окружности, но он не может быть и тем и другим одновременно. Главное правило состоит в том, что хотя класс может быть частью нескольких других классов, но любой экземпляр может принадлежать только одному владельцу. На диаграмме классов можно показать несколько классов потенциальных владельцев, но у любого экземпляра класса есть только один объектвладелец.
Можно заметить, что на рис. 8 не показаны обратные кратности. В большинстве случаев, как
и здесь, они равны 0..1. Единственной альтернативой является значение 1, когда класскомпонент разработан таким образом, что у него только один классвладелец.
Правило «нет совместного владения» является ключевым в композиции. Другое допущение состоит в том, что если удаляется многоугольник (Polygon), то автоматически должны удалиться все точки (Points), которыми он владеет.
Рис.7.Агрегация
Рис.8.Композиция
Обобщение
Обобщение (generalization) — это отношение между двумя сущностями, одна их которых является частным (специализированным) случаем другой. Графически обобщение изображается в виде линии с треугольной незакрашенной стрелкой на конце, направленной от частного (подкласса) к общему (суперклассу).
На рис. 9 показан пример обобщения, где классы Rectangle (Прямоугольник) и Square (Квадрат) являются подклассами класса Shape (Фигура).
Еще один пример обобщения включает индивидуального и корпоративного клиентов некоторой бизнессистемы (см. рис. 2). Несмотря на определенные различия, у них много общего. Одинаковые свойства можно поместить в базовый класс Customer (Клиент, супертип), при этом класс Personal Customer (Индивидуальный
клиент) и класс Corporate Customer (Корпоративный клиент) будут выступать как подтипы.
Этот факт служит объектом разнообразных интерпретаций в моделях различных уровней. На концептуальном уровне мы можем утверждать, что Корпоративный клиент представляет собой подтип Клиента, если все экземпляры класса Корпоративный клиент по определению являются также экземплярами класса Клиент. Таким образом, класс Корпоративный клиент представляет собой частную разновидность класса Клиент. Основная идея заключается в следующем: все, что нам известно о классе Клиент (ассоциации, атрибуты, операции), справедливо также и для класса Корпоративный клиент.
Рис.9.Примеробобщения
С точки зрения программного обеспечения очевидная интерпретация наследования выглядит следующим образом: Корпоративный клиент является подклассомкласса Клиент. В основных объектноориентированных языках подкласс наследует всю функциональность суперкласса и может переопределять любые методы суперкласса.
Важным принципом эффективного использования наследования является замещаемость.
Необходимо иметь возможность подставить Корпоративного клиента в любом месте программы, где требуется Клиент, и при этом все должно прекрасно работать. По существу это означает, что когда вы пишете программу в предположении,
что у вас есть Клиент, то вы можете свободно использовать любой подтип Клиента.
Вследствие полиморфизма Корпоративный клиент может реагировать на определенные команды не так, как другой Клиент, но вызывающий не должен беспокоиться об этом отличии. Наследование представляет собой мощный механизм, но оно несет с собой много такого, что не всегда является необходимым для достижения замещаемости.
Замещаемые классы можно создавать при помощи массы других механизмов. Поэтому многие разработчики предпочитают различать создание подтипа, то есть наследование интерфейса, и создание подкласса, или наследование реализации. Класс – это подтип, если он может замещать свой супертип, в независимости от того, использует он наследование или нет. Создание подкласса используется как синоним обычного наследования.
Существует достаточное количество других механизмов, позволяющих создавать подтипы без создания подклассов. Примером может служить реализация интерфейса и множество стандартных шаблонов разработки.
Реализация
Рис.10.Примеротношенияреализации
Отношение реализации указывает, что одна сущность является реализацией другой. Например, класс является реализацией интерфейса. Графически реализация изображается в виде пунктирной л
Двунаправленные ассоциации
Двунаправленная ассоциация, показанная на рис. 6, – это пара свойств, связанных в противоположных направлениях. Класс Car (Автомобиль) имеет свойство owner:Person[1], а класс Person (Личность) имеет свойство cars:Car[*]. (Обратите внимание, что использована множественная форма имени свойства cars по причине того, что у свойства кратность больше 1.)
Рис.6.Двунаправленнаяассоциация
Агрегация и композиция
Простая ассоциация между двумя классами отражает структурное отношение между равноправными сущностями, когда оба класса находятся на одном концептуальном уровне и ни один не является более важным, чем другой. Но иногда приходится моделировать отношение типа "часть/целое", в котором один из классов имеет более высокий ранг (целое) и состоит из нескольких меньших по рангу (частей). К примеру, можно сказать, что двигатель и колеса представляют собой части автомобиля.
Отношение
такого типа называют агрегированием (aggregation); оно причислено к отношениям типа "имеет" (с учетом того, что объектцелое имеет несколько объектовчастей). Агрегирование является частным случаем ассоциации и изображается в виде простой ассоциации с незакрашенным ромбом со стороны "целого" (рис. 7).
Наряду с агрегацией в языке UML есть более определенное свойство – композиция (composition).
Композиция — более строгий вариант агрегации. Композиция имеет жёсткую зависимость времени существования экземпляров классаконтейнера и экземпляров содержащихся классов. Если контейнер будет уничтожен, то всё его содержимое будет также уничтожено. Графически представляется так же, как и агрегация, но с закрашенным ромбиком.
На рис. 8 экземпляр класса Point (Точка) может быть частью многоугольника, а может представлять центр окружности, но он не может быть и тем и другим одновременно. Главное правило состоит в том, что хотя класс может быть частью нескольких других классов, но любой экземпляр может принадлежать только одному владельцу. На диаграмме классов можно показать несколько классов потенциальных владельцев, но у любого экземпляра класса есть только один объектвладелец.
Можно заметить, что на рис. 8 не показаны обратные кратности. В большинстве случаев, как
и здесь, они равны 0..1. Единственной альтернативой является значение 1, когда класскомпонент разработан таким образом, что у него только один классвладелец.
Правило «нет совместного владения» является ключевым в композиции. Другое допущение состоит в том, что если удаляется многоугольник (Polygon), то автоматически должны удалиться все точки (Points), которыми он владеет.
Рис.7.Агрегация
Рис.8.Композиция
Обобщение
Обобщение (generalization) — это отношение между двумя сущностями, одна их которых является частным (специализированным) случаем другой. Графически обобщение изображается в виде линии с треугольной незакрашенной стрелкой на конце, направленной от частного (подкласса) к общему (суперклассу).
На рис. 9 показан пример обобщения, где классы Rectangle (Прямоугольник) и Square (Квадрат) являются подклассами класса Shape (Фигура).
Еще один пример обобщения включает индивидуального и корпоративного клиентов некоторой бизнессистемы (см. рис. 2). Несмотря на определенные различия, у них много общего. Одинаковые свойства можно поместить в базовый класс Customer (Клиент, супертип), при этом класс Personal Customer (Индивидуальный
клиент) и класс Corporate Customer (Корпоративный клиент) будут выступать как подтипы.
Этот факт служит объектом разнообразных интерпретаций в моделях различных уровней. На концептуальном уровне мы можем утверждать, что Корпоративный клиент представляет собой подтип Клиента, если все экземпляры класса Корпоративный клиент по определению являются также экземплярами класса Клиент. Таким образом, класс Корпоративный клиент представляет собой частную разновидность класса Клиент. Основная идея заключается в следующем: все, что нам известно о классе Клиент (ассоциации, атрибуты, операции), справедливо также и для класса Корпоративный клиент.
Рис.9.Примеробобщения
С точки зрения программного обеспечения очевидная интерпретация наследования выглядит следующим образом: Корпоративный клиент является подклассомкласса Клиент. В основных объектноориентированных языках подкласс наследует всю функциональность суперкласса и может переопределять любые методы суперкласса.
Важным принципом эффективного использования наследования является замещаемость.
Необходимо иметь возможность подставить Корпоративного клиента в любом месте программы, где требуется Клиент, и при этом все должно прекрасно работать. По существу это означает, что когда вы пишете программу в предположении,
что у вас есть Клиент, то вы можете свободно использовать любой подтип Клиента.
Вследствие полиморфизма Корпоративный клиент может реагировать на определенные команды не так, как другой Клиент, но вызывающий не должен беспокоиться об этом отличии. Наследование представляет собой мощный механизм, но оно несет с собой много такого, что не всегда является необходимым для достижения замещаемости.
Замещаемые классы можно создавать при помощи массы других механизмов. Поэтому многие разработчики предпочитают различать создание подтипа, то есть наследование интерфейса, и создание подкласса, или наследование реализации. Класс – это подтип, если он может замещать свой супертип, в независимости от того, использует он наследование или нет. Создание подкласса используется как синоним обычного наследования.
Существует достаточное количество других механизмов, позволяющих создавать подтипы без создания подклассов. Примером может служить реализация интерфейса и множество стандартных шаблонов разработки.
Реализация
Рис.10.Примеротношенияреализации
Отношение реализации указывает, что одна сущность является реализацией другой. Например, класс является реализацией интерфейса. Графически реализация изображается в виде пунктирной л