Quelle est la différence entre un stéréotype et un héritage de classe dans UML?

pour autant que je sache, le but premier des stéréotypes est de permettre l'extension du langage UML lui-même (en tant que langage de modélisation), et non de modéliser quoi que ce soit.

cela dit, je pense aussi que votre question implique une autre réponse valable possible: certaines personnes préfèrent utiliser des stéréotypes pour désigner (de manière informelle! certains points communs entre les classes. Ils pourraient le faire juste parce que c'est plus facile que de sous-classement et assez "bon" pour les besoins de leurs modèle.

par exemple, De nombreux systèmes logiciels ont des classes qui représentent donc appelé domaine des entités (entreprises, clients, commandes, produits, etc.). Eventuellement, vous voulez avoir une classe commune, comme Entity tirer Company,Customer etc. de. Mais au départ, il est probable qu'il suffise d'utiliser des classes stéréotypées comme celles-ci <<Entity>> Company,<<Entity>> Customer etc. Essentiellement, ce n'est qu'une question de commodité (et de coûts/avantages!) de votre efforts de modélisation.

dans votre exemple, L'acteur n'a probablement pas besoin d'être implémenté en tant que classe, mais cela peut être ou pas toujours le cas. Les stéréotypes sont des abstractions qui peuvent être appliquées à la plupart des éléments UML et pas seulement aux classes.

ils encapsulent la sémantique sans impliquer comment cette sémantique fournira. Un autre exemple pourrait être un canal de communication stéréotypé comme HTTP ou RPC. Ils communiquent avec le lecteur comment quelque chose sera fourni sans compliquer le modèle avec les détails inutiles.

la spécification UML fournit un certain nombre de stéréotype prédéfini, mais leur véritable puissance vient de pouvoir définir votre propre à travers des profils. Vous pouvez étiqueter un objet de domaine comme EJB pour vous sauver en spécifiant tout le code de la plaque de chaudière.

un stéréotype est là et utilisé pour présenter plus d'informations sur l'artefact que la documentation ou la Classification de celui-ci dans un bloc spécifique d'artefacts peut ne pas donner. Par exemple, vous avez identifié une Classe de Données, vous pouvez lui donner le nom, expliquer les attributs et les opérations, mais que lui-même ne peut pas donner l'information complète.Le moment où vous Stéréotype <>, il spécifie des informations complètes; Jusqu'alors il continue comme toute autre classe pour une développeur.

"les Stéréotypes sont utilisés pour étendre UML éléments de notation, de classer et d'étendre les associations, les relations d'héritage, les classes et les composants"

un stéréotype permet de créer de nouveaux types d'éléments de modélisation. Les stéréotypes doivent être fondés sur des éléments qui font partie du méta-modèle UML. Certains stéréotypes courants pour une classe sont l'entité, la limite, le contrôle, l'utilité et l'exception. Le stéréotype d'une classe est affiché sous le nom de la classe inclus dans guillemets (i.e. « et », prononcée gee-mai). Si désiré une icône graphique ou une couleur spécifique peut être associée à un stéréotype.

une bonne indication de l'intention derrière les stéréotypes peut être vue dans la façon dont L'OMG les a appliqués dans les profils SysML ou BPMN. Plus précisément, les stéréotypes décrivent un nouvel ensemble de constructions de modélisation comme faisant partie du langage pour vous spécifier un domaine. Par exemple, un bloc dans SysML est un stéréotype appliqué à une classe. Il apporte avec lui les personnalisations d'une classe pour une utilisation dans des systèmes d'ingénierie. Dans ce cas, il remplace L'utilisation de la classe et établit de nouvelles relations avec d'autres éléments et le diagramme types, par exemple bloc << satisfait >> exigence (relation autorisée) ou un bloc peut être modélisé en utilisant un schéma de bloc interne (comportement autorisé). Un stéréotype n'est pas utilisé pour modéliser votre espace sujet. Il classifie l'utilisation des constructions de modélisation pour un aspect vertical ou horizontal de la définition des systèmes.

je pense qu'il est impossible d'expliquer réellement les points clés en parlant de stéréotypage sans faire entrer dans la discussion les niveaux de métal MOF.

stéréotypage "vit" en M2 (voir "OMG Unified Modeling Language (OMG UML), Infrastructure, Verison 2.4.1"), qui est spécifiquement pour définir les langages de modélisation. Le stéréotype est présent à ce niveau et non dans M1 ou M0. en d'autres termes, le stéréotype est une construction spécifique pour définir de nouveaux langages de modélisation, et non pour la définition de nouveaux modèles de domaine.

ainsi, remplacer le stéréotype par une généralisation au niveau M1 peut être sémantiquement correct dans le cadre de la modélisation de domaine, mais comme il est dans le mauvais métalevel, il n'est pas entièrement équivalent sémantiquement.

un autre point est que les stéréotypes peuvent être facultatifs ou obligatoires. L'héritage, cependant, ne peut pas être facultatif.

un stéréotype étend la structure du métamodèle UML en spécifiant par exemple des attributs spécifiques à un domaine sur des éléments D'un modèle UML et n'altère pas la sémantique du temps d'exécution du système modélisé-ils ne font qu'enrichir le langage de modélisation.

un bon exemple de cela est de donner un" rôle " à une classe dans le diagramme de conception. La fonctionnalité de classe est donnée à l'intérieur de la classe, non ajoutée par le stéréotype - ceci supporte l'énoncé ci-dessus.

maintenant, le délicat une partie est héritée ou des classes stéréotypées; bien selon UML 1.3 ils ne sont pas héritables; cependant les contraintes données à la classe par" A " via un certain stéréotype s'appliquent aussi à la classe spécialisée. À mon avis, cela ne s'applique toujours pas au runtime, donc encore une fois l'ambiguïté reste au niveau sémantique. Plus dans cet e-mail, thread.

selon https://sites.google.com/site/assignmentssolved/mca/semester2/mc0069/10 si vous voulez avoir des valeurs marquées, vous devez les Définir comme des attributs sur un stéréotype (puisque UML 2.0 est requis)

dans UML 1.3 les valeurs marquées peuvent étendre un élément de modèle sans exiger la présence d'un stéréotype. Dans UML 1.4, cette capacité, bien que toujours supportée, a été dépréciée, pour être utilisée seulement pour des raisons de rétrocompatibilité.

depuis UML 2.0, une valeur marquée ne peut être représentée que comme un attribut défini sur un stéréotype. Par conséquent, un élément de modèle doit être étendu par un stéréotype afin d'être étendu par des valeurs marquées. Pour prendre en charge la compatibilité avec UML 1.3, certains outils UML peuvent définir automatiquement un stéréotype auquel seront attachés des attributs "non attachés" (valeurs marquées).

les valeurs des balises peuvent être affichées dans le compartiment de classe sous le nom du stéréotype. Un compartiment supplémentaire est nécessaire pour chaque stéréotype dont les valeurs doivent être affichées. Chaque compartiment est dirigé par le nom du stéréotype dans les guillemets.

une lecture intéressante sur les stéréotypes de 2003 est probablement https://www.semanticscholar.org/paper/Systematic-stereotype-usage-Atkinson-K%C3%BChne/3253db03c11f4f99be580277716d3b78d750618a

C'est le résumé:

comme l'un des principaux mécanismes d'extension de L'UML, les stéréotypes jouent un rôle crucial dans la capacité de L'UML à servir une base d'utilisateurs large et croissante. Toutefois, la signification précise des stéréotypes et leur mode d'utilisation n'ont jamais été tout à fait clairs et ont même suscité un débat important parmi les experts. Deux façons fondamentales d'utiliser les stéréotypes UML ont été observées dans la pratique: l'une pour soutenir la classification des classes comme un moyen d'émuler les extensions metamodel, l'autre pour soutenir la classification des objets comme un moyen d'assigner leur certaines propriétés. Dans cet article, nous analysons ces deux scénarios d'utilisation stéréotypée reconnus et nous expliquons la raison d'être de l'identification explicite d'une troisième forme de scénario d'utilisation. Nous proposons quelques concepts de notation qui pourraient être utilisés pour distinguer explicitement les trois scénarios d'utilisation et fournir des heuristiques quant au moment où chacun devrait être utilisé. Enfin, nous concluons en proposant des améliorations à L'UML qui pourraient prendre en charge les trois formes de manière claire et concise.