Как наследуются отношения в UML-диаграмме классов?

Мне было интересно, как Ассоциации, зависимости и такие отношения наследуются в UML (или, скажем, в целом). Итак, в подобной ситуации: 

  ┌──────────┐                                        ┌──────────┐
  │  ClassA  │                                        │  ClassB  │
  ├──────────┤                                        ├──────────┤
  │          │─────────"One kind of relation"────────>│          │
  ├──────────┤                                        ├──────────┤
  │          │                                        │          │
  └──────────┘                                        └──────────┘
        ^
       /┬
        │
        │
        │
        │
  ┌─────┴────┐
  │  ClassC  │
  ├──────────┤
  │          │
  ├──────────┤
  │          │
  └──────────┘

Примечание:

  • ClassA-ClassC находится в обобщающем отношении, стрелка должна быть сплошной
  • класса-classb является одним из [зависимость, ассоциация, агрегация, композиция]
  • Unicode классный, но с редактором шрифта смотрится намного лучше:)
Мой вопрос в том, как эти отношения наследуются? Для например, когда класс classa зависит то, будет ClassC зависят от ТО? и т.д.

Спасибо.

3 3
oop inheritance uml class-diagram

3 ответа:

Вы задаете не UML-вопрос, а более общий вопрос.

Что означает наследование?

ClassC-это подкласс ClassA. В каждом языке программирования, реализующем наследование, ClassC будет иметь все возможности ClassA.

В языке, который не поддерживает наследование, необходимо создать иллюзию правильного наследования, убедившись, что все функции ClassA также являются частью ClassC.

Таково определение наследования. Всегда и навсегда. Даже в UML-диаграммах.

1

Простой ответ-да (и вам не нужно смотреть дальше этого для большей практической цели).

Но дело обстоит сложнее, чем кажется; цитируя справочное руководство по унифицированному языку моделирования, второе издание:

Слова обобщение и наследование часто используются взаимозаменяемо, но есть на самом деле два родственных но разных концепция. Обобщение-это таксономическая связь между моделированием элементы. Оно описывает, что такое элемент - это . Наследование-это механизм объединения общих инкрементных данных. описания, чтобы сформировать полный описание элемента. В большинстве объектно-ориентированные системы, наследование основан на обобщении, но наследование может основываться на другом концепции, такие как делегирование указатель собственного языка. Базирующийся механизм наследования на отношение обобщения позволяет факторинг и обмен описаниями и полиморфное поведение. Этот это подход, принятый большинством объектно-ориентированных языки и по UML. Но имейте в виду что есть и другие подходы, которые могли быть взяты и такие используется некоторыми языками программирования.

Я помню довольно длинную лекцию, еще в 2003 году, о разнице между обобщением и наследованием. Короче говоря, эти две концепции принадлежат к разным уровням проектирования программного обеспечения, или цитируя Мартина Фаулера в UML Distilled, третье издание, " различные перспективы моделирование":
Концептуально мы можем сказать, что a Корпоративный клиент - это подтип Клиент, если все экземпляры корпоративного Клиент также, по определению, примеры клиента. Корпоративный Клиент - это тогда особый вид Покупатель.
Понятие обобщения относится к концептуальному, проектному уровню.

Но наследование-это понятие, которое относится к перспективе реализации:

С точки зрения программного обеспечения, очевидная интерпретация-это наследование: Корпоративный клиент - это подкласс клиента. В мейнстриме ОО языки, подкласс наследует все особенности суперкласса и мая переопределять методы суперкласса.

Я помню пример, где различие между обобщением и наследованием действительно имело смысл:

Квадрат-это прямоугольник. Это следует из их определений в математике:

  • прямоугольник-это четырехугольник с четырьмя правыми сторонами. углы
    • Квадрат-это многоугольник с четырьмя равными сторонами и углами

На уровне проектирования существует обобщающее отношение между квадратом и прямоугольником.

Но на уровне реализации все выглядит иначе:

  • прямоугольник можно определить двумя мерами: его шириной и высотой
    • Квадрат может быть определен одной мерой, так как все стороны равны

Было бы контрпродуктивно наследовать ширину и высоту класса прямоугольника в классе квадрата, что потребует дополнительных ограничений для обеспечения того, чтобы одно и то же значение предоставлялось сеттеру для ширины и сеттеру для высоты.

Это случай (несколько резкий, я признаю), когда вы не переводите отношение обобщения на использование наследования на уровне реализации.

Ну, это были те дни.

2

Поскольку наследование является отношением" is-a "(без каламбура), вы можете прочитать его как "ClassC-это ClassA, который знает ClassB", поэтому:

Например, если ClassA зависит от ClassB, будет ли ClassC зависеть от ClassB?

-- Yes:)

1