UML абстрактные классы?

Question

Так что в настоящее время я самообучаюсь UML , и я взял онлайн-тест, чтобы помочь мне лучше понять его.

Один из заданных вопросов:

Как моделировать следующую ситуацию с диаграммой классов UML2:

"Существует несколько разных видов птиц, например, дрозд, дрозд, и скворец. "

И два доступных варианта:

Диаграмма вверху правильная (и я понимаю почему), однако диаграмма внизу неверная . Почему это? Поскольку эти три птицы наследуются от птицы абстрактного класса и соответствуют любым абстрактным методам, не все ли они птицы?

Answer 1

Есть два возможных ответа на этот вопрос:

1. Вершина неверна логически, поскольку вы не можете создать экземпляр Bird самостоятельно. Птица - это абстрактная классификация всех видов птиц. Вы можете создавать только дроздов, скворцов и черных дроздов. Я не уверен, как будет выглядеть экземпляр Bird, но он будет сверхъестественным.

2. Нижняя часть синтаксически неверна, потому что абстрактное ограничение должно применяться после имени и типа класса.

Лично я думаю, что отпустил бы номер 2 (это ошибка, кого это волнует?) И сосредоточился на №1, что, если бы я занимался птицами, более важно.

Answer 2

Требование в викторине гласит: Существует несколько разных видов птиц, например, черный дрозд, дрозд и скворец

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

Диаграмма UML:

является допустимымРешение для этого требования.Оба варианта в вашей викторине также являются действительными решениями в зависимости от того, как вы смотрите на требование.Требование дало три примера, которые явно смоделированы в обоих решениях.«например» означает, что могут быть другие птицы, и этот факт лучше описать в первом решении.Во втором решении у вас не может быть экземпляров «Bird», которых нет в списке примеров.

Но это решение будет иметь смысл, только если у вас могут быть некоторые атрибуты и операции, которые не показаны - ИМХОминимум должен был бы отслеживать тип птицы - очень неудобно извлекать его из имени класса в большинстве сред реализации.

Лично я не думаю, что это хороший способ объяснить наследование такими примерами, какв вашей викторине.Наследование является дорогостоящим в реализации (например, в большинстве языков программирования вы получаете отдельные файлы исходного кода для унаследованного класса), и эта стоимость должна дать вам определенную выгоду.Это в основном тот случай, когда изображаемые предметы различаются по своим атрибутам и поведению, и вам нужны разные реализации.«Черный дрозд» и «Синий дрозд» могут отличаться только цветом (атрибут цвета является дискриминатором).ИМХО в этом случае лучше иметь: , чем

Answer 3

В спецификации UML 2.5 говорится о с. 98

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

То есть, если Bird украшено ключевым словом abstract, это приводит к ограничению возможности его / не создавать. Если вам нужен экземпляр Bird, оставьте его в покое. Если вы хотите создать индекс животных, у вас, вероятно, будет abstract Bird, который говорит, что вам нужно в основном включить в описание птицы. Но ты не описываешь это сам по себе.

В вашем случае обе диаграммы в целом "правильные". Это зависит от контекста, который вы не объяснили должным образом. Вы можете выполнить требование с обоими, поскольку нет требования, что вы не можете создавать экземпляр Bird.