inheritance - ejemplos - relaciones entre clases programacion orientada a objetos
¿Cuál es la diferencia entre un estereotipo y una herencia de clase en UML? (7)
Estoy confundido acerca de la diferencia entre ser un "estereotipo" y ser una "superclase" en UML.
Digamos que quiero crear un diagrama que involucre un " WidgetMaker ". WidgetMaker es claramente un Actor por lo que el estándar UML es estereotipar a su actor:
<<Actor>> WidgetMaker
Pero crecí programando en el mundo Java / Ruby / C ++. En ese mundo, la relación es:
class Actor
end
class WidgetMaker < Actor
end
Eso se ve así en UML:
Actor
^
|
WidgetMaker
Así que mi pregunta es: ¿por qué UML tiene estereotipos en absoluto cuando puedes modelar fácilmente esos conceptos usando la herencia de clase, que también tiene?
Una vez que tenemos más "tipos" de actores, la pregunta se vuelve aún más turbia:
Actor
^
|
------------------------
| | |
Person Robot Group
^
|
WidgetMaker
versus
<<Actor>> <<Person>> WidgetMaker
En su ejemplo, Actor probablemente no necesita ser implementado como una clase, pero este puede ser o no siempre el caso. Los estereotipos son abstracciones que se pueden aplicar a la mayoría de los elementos UML, no solo a las clases.
Ellos encapsulan la semántica sin implicar cómo se proporcionarán esas semánticas. Otro ejemplo podría ser un canal de comunicaciones estereotipado como HTTP o RPC. Se están comunicando con el lector cómo se proporcionará algo sin complicar el modelo con detalles innecesarios.
La especificación UML proporciona una serie de estereotipos predefinidos, pero su poder real proviene de la posibilidad de definir su propio perfil a través de los perfiles. Puede etiquetar un objeto de dominio como un EJB para guardarse a sí mismo especificando todo el código de la placa de la caldera.
Se puede ver una buena indicación de la intención detrás de los estereotipos en cómo el OMG los ha aplicado en los perfiles SysML o BPMN. Específicamente, los estereotipos describen un nuevo conjunto de construcciones de modelado como parte del lenguaje para especificar su dominio. Por ejemplo, un Bloque en SysML es un estereotipo aplicado a la Clase. Trae consigo personalizaciones de una clase para uso en ingeniería de sistemas. En este caso, reemplaza el uso de la Clase y establece nuevas relaciones con otros elementos y tipos de diagramas, por ejemplo, el Bloque << satisface >> Requisito (relación permitida) o un Bloque puede modelarse utilizando un Diagrama de Bloques Interno (comportamiento permitido). No se usa un estereotipo para modelar el espacio de su sujeto. Clasifica el uso de construcciones de modelado para un aspecto vertical u horizontal de la definición de sistemas.
Según tengo entendido, el propósito principal de los estereotipos es habilitar la extensión de UML (como lenguaje de modelado), y no modelar nada.
Dicho esto, también creo que su pregunta implica otra posible respuesta válida: algunas personas prefieren usar estereotipos para designar (¡informalmente!) Ciertos puntos en común entre las clases. Podrían hacer eso solo porque es más fácil que crear subclases y "lo suficientemente bueno" para los propósitos de sus modelos.
Por ejemplo, muchos sistemas de software tienen clases que representan las denominadas entidades de dominio (cosas como empresas, clientes, órdenes de compra, productos, etc.). Eventualmente, es posible que desee tener una clase común como Entity para derivar Company , Customer , etc. Pero inicialmente es probable que sea suficiente solo para usar clases estereotipadas como estas <<Entity>> Company , <<Entity>> Customer etc. Esencialmente, es solo una cuestión de conveniencia (y costo / beneficio) de sus esfuerzos de modelado.
Siento que hablar de estereotipos sin incluir MOF METALEVELS en esta discusión hace que sea imposible explicar los puntos clave.
El estereotipo "vive" en M2 (consulte "Lenguaje de modelado unificado OMG (UML OMG), Infraestructura, Verison 2.4.1"), que es específicamente para definir lenguajes de modelado. El estereotipo vive en este nivel y no en M1 o M0. en otras palabras, los estereotipos son una construcción específica para definir NUEVOS LENGUAJES DE MODELADO, no para definir nuevos modelos de dominio.
Por lo tanto, reemplazar el estereotipo con la generalización en el nivel M1 puede ser semánticamente correcto dentro del alcance del modelado de dominios, pero dado que está en el nivel meta incorrecto, NO es completamente semánticamente equivalente.
Otro punto es que los estereotipos pueden ser opcionales u obligatorios. La herencia, sin embargo, no puede ser opcional.
Un estereotipo amplía la estructura del metamodelo UML especificando, por ejemplo, atributos específicos del dominio en los elementos de un modelo UML y no altera la semántica de tiempo de ejecución del sistema que se está modelando; solo enriquecen el lenguaje de modelado.
Un buen ejemplo de esto es darle un "rol" a una clase en el diagrama de patrón de diseño. La funcionalidad de la clase se proporciona dentro de la clase, no agregada por el estereotipo; esto es compatible con la declaración anterior.
Ahora, la parte difícil es la herencia o clases estereotipadas; Bueno, según UML 1.3 no son heredables; sin embargo, las restricciones dadas a la clase por "A" a través de algún estereotipo también se aplican a la clase especializada. En mi opinión, esto todavía no se aplica al tiempo de ejecución, por lo que, de nuevo, la ambigüedad permanece en el nivel semántico. Más en este hilo de correo .
Un estereotipo está ahí y se utiliza para presentar más información sobre el artefacto que la documentación o la Clasificación del mismo en un bloque específico de artefactos no puede dar. Por ejemplo, ha identificado una clase de datos, puede darle el nombre, explicar los atributos y las operaciones, pero es posible que no proporcione la información completa. En el momento en que lo estereotipo como <>, especifica la información completa; Hasta entonces continúa como cualquier otra clase para un desarrollador.
"Los estereotipos se utilizan para extender los elementos notacionales UML, para clasificar y extender asociaciones, relaciones de herencia, clases y componentes"
Un estereotipo proporciona la capacidad de crear nuevos tipos de elementos de modelado. Los estereotipos deben basarse en elementos que forman parte del metamodelo UML. Algunos estereotipos comunes para una clase son entidad, límite, control, utilidad y excepción. El estereotipo de una clase se muestra debajo del nombre de la clase incluido en los guillemets (es decir, « y » , pronunciado gee-may ). Si se desea, un icono gráfico o un color específico puede estar asociado con un estereotipo.
de acuerdo con sites.google.com/site/assignmentssolved/mca/semester2/mc0069/10 si desea tener valores etiquetados, debe definirlos como atributos en un estereotipo (desde UML 2.0 es necesario)
En UML 1.3, los valores etiquetados podrían extender un elemento del modelo sin requerir la presencia de un estereotipo. En UML 1.4, esta capacidad, aunque todavía se admite, estaba en desuso, para ser utilizada solo por razones de compatibilidad con versiones anteriores.
Desde UML 2.0, un valor etiquetado solo puede representarse como un atributo definido en un estereotipo. Por lo tanto, un elemento del modelo debe extenderse por un estereotipo para extenderse por los valores etiquetados. Para admitir la compatibilidad con UML 1.3, algunas herramientas UML pueden definir automáticamente un estereotipo al que se adjuntarán los atributos "sin conexión" (valores etiquetados).
Los valores de las etiquetas se pueden mostrar en el compartimento de la clase bajo el nombre del estereotipo. Se requiere un compartimento adicional para cada estereotipo aplicado cuyos valores se muestren. Cada uno de estos compartimientos está encabezado por el nombre del estereotipo aplicado en los guillemets.
Una lectura interesante sobre los estereotipos de 2003 probablemente sea https://www.semanticscholar.org/paper/Systematic-stereotype-usage-Atkinson-K%C3%BChne/3253db03c11f4f99be580277716d3b78d750618a
Este es el resumen:
Como uno de los principales mecanismos de extensión de UML, los estereotipos desempeñan un papel crucial en la capacidad de UML para servir a una amplia y creciente base de usuarios. Sin embargo, el significado preciso de los estereotipos y su modo de uso previsto nunca ha sido del todo claro e incluso ha generado un debate significativo entre los expertos. En la práctica, se han observado dos formas básicas de utilizar estereotipos UML: una para respaldar la clasificación de clases como un medio para emular extensiones de metamodelos, la otra para respaldar la clasificación de objetos como un medio para asignarles ciertas propiedades. En este artículo analizamos estos dos escenarios de uso de estereotipos reconocidos y explicamos la razón para identificar explícitamente una tercera forma de escenario de uso. Proponemos algunos conceptos de notación que podrían usarse para distinguir explícitamente los tres escenarios de uso y proporcionar heurísticas sobre cuándo se debe usar cada uno. Finalmente, concluimos proponiendo mejoras al UML que podrían soportar las tres formas de manera clara y concisa.