В чем разница между стереотипом и наследованием классов в UML?

Question

Меня смущает разница между чем-то, что является "стереотипом" и "суперклассом" в UML.

Допустим, я хочу создать диаграмму, включающую "WidgetMaker". WidgetMaker явно Actor, поэтому стандарт UML должен стереотипировать его как актера:

<<Actor>> WidgetMaker

Но я вырос программированием в мире Java / Ruby / C ++. В этом мире отношения таковы:

class Actor
end

class WidgetMaker < Actor
end

Это выглядит так в UML:

  Actor
    ^
    |
WidgetMaker

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

Как только у нас появляется больше "видов" актеров, вопрос становится еще более мрачным:

              Actor
                ^
                |
    ------------------------
    |           |          |
  Person      Robot      Group
    ^
    |
WidgetMaker

против

<<Actor>> <<Person>> WidgetMaker

Answer 1

Насколько я понимаю, основная цель стереотипов - позволить расширение самого UML (как языка моделирования), а не моделировать что-либо.

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

Например, многие программные системы имеют классы, которые представляют так называемые доменные объекты (такие как компании, клиенты, заказы на покупку, продукты и т. Д.). В конце концов, вы можете захотеть иметь общий класс, такой как Entity, для которого можно получить Company, Customer и т. Д. Но изначально, вероятно, будет достаточно просто использовать классы со стереотипами, подобные этим <<Entity>> Company, <<Entity>> Customer и т. Д. По сути, это просто вопрос удобства (и затрат / выгод!) Ваших усилий по моделированию.

Answer 2

В вашем примере Actor, вероятно, не нужно реализовывать как класс, но это может или не всегда так. Стереотип - это абстракции, которые можно применять к большинству элементов UML, а не только к классам.

Они инкапсулируют семантику, не подразумевая, как эта семантика будет предоставлена. Другим примером может быть канал связи, стереотипированный как HTTP или RPC. Они сообщают читателю, как что-то будет предоставлено, не усложняя модель ненужными деталями.

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

Answer 3

Хорошее указание на намерение, стоящее за стереотипами, можно увидеть в том, как OMG применила их в профилях SysML или BPMN. В частности, стереотипы описывают новый набор конструкций моделирования как часть языка для определения вашего домена. Например, блок в SysML - это стереотип, применяемый к классу. Это приносит с собой настройки класса для использования в системной инженерии. В этом случае он заменяет использование класса и устанавливает новые отношения с другими элементами и типами диаграмм, например, Блок << удовлетворяет >> Требованию (разрешенное отношение) или Блок может быть смоделирован с использованием внутренней блок-диаграммы (разрешенное поведение). Стереотип не используется для моделирования вашего предметного пространства. Он классифицирует использование конструкций моделирования для вертикального или горизонтального аспекта определения систем.

Answer 4

Стереотип существует и используется для представления дополнительной информации об артефакте, которую может не предоставить документация или его классификация в конкретный блок артефактов. Например, вы определили класс данных, вы можете дать ему имя, объяснить атрибуты и операции, но он сам может не дать полной информации. В тот момент, когда вы стереотипируете его как <>, он указывает полную информацию; До тех пор он продолжается как любой другой класс для разработчика.

«Стереотипы используются для расширения элементов обозначений UML, для классификации и расширения ассоциаций, отношений наследования, классов и компонентов»

Стереотип предоставляет возможность создавать новый тип элементов моделирования. Стереотипы должны основываться на элементах, которые являются частью метамодели UML. Некоторые общие стереотипы для класса - сущность, граница, контроль, полезность и исключение. Стереотип для класса показан под именем класса, заключенным в гильемы (то есть « и », произносится gee-may ). При желании графический значок или определенный цвет может быть связан со стереотипом.

Answer 5

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

Стереотипирование "живет" в M2 (см. "Язык унифицированного моделирования OMG (OMG UML), Infrastructure, Verison 2.4.1"), который специально предназначен для определения языков моделирования. Стереотип живет на этом уровне, а не в M1 или M0. другими словами, стереотипирование - это конструкция, специально предназначенная для определения НОВЫХ ЯЗЫКОВ МОДЕЛИРОВАНИЯ, а не для определения новых моделей предметной области.

Таким образом, замена стереотипирования на обобщение на уровне M1 может быть семантически приемлемой в рамках моделирования предметной области, но, поскольку он находится на неправильном метауровне, он НЕ полностью семантически эквивалентен.

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

Answer 6

согласно https://sites.google.com/site/assignmentssolved/mca/semester2/mc0069/10 если вы хотите иметь тегированные значения, вам нужно определить их как атрибуты стереотипа (начиная с UML 2.0 это необходимо)

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

Начиная с UML 2.0, теговое значение может быть представлено только как атрибут, определенный в стереотипе. Следовательно, элемент модели должен быть расширен стереотипом, чтобы быть расширенным теговыми значениями. Для поддержки совместимости с UML 1.3 некоторые инструменты UML могут автоматически определять стереотип, к которому будут прикреплены «неприкрепленные» атрибуты (теговые значения).

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

Интересное чтение стереотипов с 2003 года, вероятно, https://www.semanticscholar.org/paper/Systematic-stereotype-usage-Atkinson-K%C3%BChne/3253db03c11f4f99be580277716d3b78d750618a

Это аннотация:

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

Answer 7

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

Хорошим примером этого является предоставление «роли» классу в диаграмме шаблонов проектирования. Функциональность класса дается внутри класса, а не добавляется стереотипом - это поддерживает приведенное выше утверждение.

Теперь сложная часть - это наследование или стереотипные классы; в соответствии с UML 1.3 они не наследуются; однако ограничения, присвоенные классу буквой «A» через некоторый стереотип, также применимы и к специализированному классу. По моему мнению, это все еще не относится к среде выполнения, поэтому опять двусмысленность остается на семантическом уровне. Подробнее в этой теме .