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

Question

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

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

Примечание:

• ClassA-ClassC находится в генерализации связи, стрелка означает, что твердый
• ClassA-ClassB находится в одном из [зависимость, ассоциация, агрегация, композиция]
• Unicode это круто, но выглядел намного лучше с редактором шрифта :)

Мой вопрос в том, как эти отношения наследуют? Например, когда ClassA зависит от ClassB, будет ли ClassC зависеть от ClassB? и т.д.

спасибо.

Answer 1

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

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

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

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

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

Answer 2

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

Например, когда ClassA зависит от ClassB, зависит ли ClassC от ClassB?

- Да :)

Answer 3

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

Но дело сложнее, чем кажется; Цитируя Unified Modeling Language Reference Manual, Second Edition:

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

Я помню довольно длинную лекцию еще в 2003 году о различии между обобщением и наследованием. Короче говоря, эти два понятия принадлежат к различным уровням разработки программного обеспечения, или процитировать Мартина Фаулера в УМЛ, третье издание «различных точек зрения моделирования»:

Концептуально, мы можем сказать, что корпоративных клиентов является подтип Клиент, если все экземпляры Корпоративного Клиент также по определению экземпляров Заказчика. A Corporate Заказчик - это особый вид клиента .

Концепция обобщения относится к концептуальному уровню проектирования.

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

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

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

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

• прямоугольник представляет собой четырехугольник с четырьмя прямыми углами
• квадрат представляет собой многоугольник с четырьмя равными сторонами и углами

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

Но на уровне реализации, то прошу отличаться:

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

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

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

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