Quelle est la différence entre un stéréotype et d'un héritage de classe en UML?
Je suis confus au sujet de la différence entre quelque chose de "stéréotype" et être un "super-classe" en UML.
Disons que je veux créer un diagramme comportant un "WidgetMaker." WidgetMaker est clairement un Actor de sorte que le standard UML est de stéréotype c'acteur:
<<Actor>> WidgetMaker
Mais j'ai grandi programmation en Java/Ruby/C++ monde. Dans ce monde, la relation est:
class Actor
end
class WidgetMaker < Actor
end
Qui ressemble à ceci dans UML:
Actor
^
|
WidgetMaker
Donc ma question est: pourquoi a-t d'UML ont stéréotypes à tout moment, vous pouvez facilement le modèle de ces concepts à l'aide de l'héritage de classe, qu'il aussi a.
Une fois que nous avons plusieurs "sortes" d'acteurs, la question devient encore plus trouble:
Actor
^
|
------------------------
| | |
Person Robot Group
^
|
WidgetMaker
contre
<<Actor>> <<Person>> WidgetMaker
- ce lien pourrait aider sites.google.com/site/assignmentssolved/mca/semester2/mc0069/10
Vous devez vous connecter pour publier un commentaire.
Comme je le comprends, le but principal de stéréotypes est de permettre l'extension d'UML lui-même (en tant que langage de modélisation), et de ne pas le modèle de quoi que ce soit.
Cela dit, je pense aussi que votre question implique une réponse valable: certaines personnes préfèrent utiliser les stéréotypes de 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èles.
Par exemple, de nombreux systèmes logiciels ont des classes qui représentent donc appelé domaine des entités (des choses comme les entreprises, les clients, les commandes, les produits, etc.). Finalement, vous pourrait voulez avoir une classe commune, comme
Entityde dériverCompany,Customeretc. partir de. Mais d'abord, il est susceptible d'être suffisant pour utiliser les classes stéréotypées comme ces<<Entity>> Company,<<Entity>> Customeretc. Essentiellement, c'est juste une question de commodité (et le coût/avantage!) de vos efforts de modélisation.Dans votre exemple, l'Acteur n'a probablement pas besoin d'être mis en œuvre en tant que classe, mais cela peut ou ne pas être toujours le cas. Stéréotype sont des abstractions qui peuvent être appliqués à la plupart des éléments UML et pas seulement les classes.
Ils encapsulent sémantique sans que cela implique la façon dont ces sémantique sera fourni. Un autre exemple pourrait être un canal de communication stéréotypée comme HTTP ou RPC. Ils sont en communication avec le lecteur que quelque chose va être fournis, sans pour autant compliquer le modèle avec des détails inutiles.
La spécification UML fournit un nombre prédéfini de stéréotype, mais leur pouvoir réel vient d'être capable de définir votre propre grâce à des profils. Vous pouvez également associer un objet de domaine comme un EJB pour vous sauver la spécification de toutes les chaudières de la plaque de code.
Un Stéréotype est là et utilisé pour présenter plus d'informations à propos de l'artefact qui, à la documentation ou à la Classification de la même dans un bloc d'artefacts ne peuvent 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 comme <>, il spécifie des informations complètes; Jusqu'alors il continue comme toute autre classe pour un 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 offre la possibilité de créer un nouveau type d'éléments de modélisation. Les stéréotypes doivent être fondées sur des éléments qui font partie du métamodèle UML. Certains des stéréotypes courants pour une classe d'entité, de frontière, de contrôle, d'utilité et d'exception. Le stéréotype de la classe est illustré ci-dessous le nom de la classe enfermés dans des guillemets (c'est à dire
«et», prononcé 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 peuvent être vu dans la façon dont l'OMG a appliquées dans le SysML ou BPMN profils. Plus précisément, les stéréotypes de décrire une nouvelle série de constructions de modélisation comme faisant partie du langage pour la spécification de votre domaine. Par exemple, un Bloc de SysML est stéréotype appliqué à la 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 met en place de nouvelles relations avec d'autres éléments et types de diagrammes, par exemple, le Bloc << satisfait >> Exigence (permis relation) ou un Bloc peut être modélisé à l'aide d'un Diagramme de blocs Internes (permis de comportement).
Un stéréotype n'est pas utilisé pour le modèle de votre sujet de l'espace. Il classe l'utilisation de la modélisation des constructions pour une verticale ou horizontale de l'aspect de la définition des systèmes.
J'ai l'impression que parler de stéréotypes, sans introduire de MOF METALEVELS dans cette discussion fait qu'il est impossible de réellement expliquer les points clés.
Le stéréotype de "vie" dans M2 (voir la section "OMG Unified Modeling Language (OMG UML), les Infrastructures, la Verison 2.4.1"), qui est spécifiquement pour la définition de la modélisation des langues. Stéréotype de la vie de ce niveau et de ne pas en M1 ou M0. en d'autres termes, les stéréotypes est une construction spécifiquement pour la définition de NOUVEAUX MODÉLISATION des LANGUES, non pas pour définir de nouveaux modèles de domaine.
Donc, en remplaçant les stéréotypes avec la généralisation de niveau M1 peut être sémantiquement ok dans le champ d'application du domaine de la modélisation, mais depuis qu'il est dans le mauvais méta-niveau, il n'est PAS entièrement sémantiquement équivalentes.
Un autre point est que les stéréotypes peuvent être facultative ou obligatoire. L'héritage, cependant, ne peut pas être facultatif.
Un stéréotype s'étend de la structure du méta-modèle UML en spécifiant par exemple du domaine des attributs spécifiques sur les éléments dans un modèle UML et ne modifie pas le moment de l'exécution de la sémantique du système modélisé - ils seulement d'enrichir le langage de modélisation.
Bon exemple de ce est de donner un "rôle" à une classe dans le modèle de conception de schéma. La fonctionnalité de la classe est donnée au sein de la classe, pas encore ajouté par le stéréotype - ce qui appuie la déclaration ci-dessus.
Maintenant, la partie la plus délicate est l'héritage ou de stéréotypes classes; ainsi, selon UML 1.3 ils ne sont pas héritables; cependant les contraintes donné par la classe "A" par le biais de certains stéréotypes ne s'appliquent à des services spécialisés de catégorie. À mon avis, ce n'est toujours pas s'appliquer à l'environnement d'exécution, de nouveau ambiguïté demeure sur le plan sémantique. De plus en ce thread messagerie.
selon
https://sites.google.com/site/assignmentssolved/mca/semester2/mc0069/10
si vous voulez avoir balisé les valeurs que vous auriez besoin de les définir comme des attributs sur un stéréotype (depuis UML 2.0, il est nécessaire)
Une lecture intéressante sur les stéréotypes de retour à partir de 2003 est probablement
https://www.semanticscholar.org/paper/Systematic-stereotype-usage-Atkinson-K%C3%BChne/3253db03c11f4f99be580277716d3b78d750618a
C'est le résumé: