¿Cuál es la diferencia entre un estereotipo y una herencia de clase en UML?

Question

Estoy confundido acerca de la diferencia entre algo que es un "estereotipo" y ser una "superclase" en UML.

Digamos que quiero crear un diagrama que implique un "WidgetMaker". WidgetMaker es claramente un Actor por lo que el estándar UML es un estereotipo que el actor:

<<Actor>> WidgetMaker 

pero crecí programación en el mundo Java/Ruby/C++. En ese mundo, la relación es:

class Actor 
end 

class WidgetMaker < Actor 
end 

que tiene este aspecto en UML:

Actor 
    ^
    | 
WidgetMaker 

Así que mi pregunta es: ¿por qué UML tienen estereotipos en absoluto cuando se puede modelar con la misma facilidad esos conceptos utilizando herencia de clase, que es también tiene.

Una vez que tenemos más "tipos" de los actores, la cuestión se vuelve aún más turbia:

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

frente

<<Actor>> <<Person>> WidgetMaker 

Answer 1

un estereotipo está ahí y se utiliza para presentar más información sobre el artefacto el cual el la documentación o la clasificación de la misma 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 estetipo como <>, especifica información completa; Hasta entonces, continúa como cualquier otra clase para un desarrollador.

"Los estereotipos se utilizan para extender los elementos de notación UML, para clasificar y ampliar las asociaciones, las relaciones de herencia, clases y componentes"

un estereotipo proporciona la capacidad de crear nuevo tipo de elementos de modelado. Los estereotipos se deben basar en elementos que forman parte del metamodelo de 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 clase incluido en guillemets (es decir, « y », pronunciado gee-may). Si lo desea, un icono gráfico o un color específico pueden asociarse con un estereotipo.

Answer 2

Por lo que yo entiendo, el propósito principal de los estereotipos es permitir la extensión de UML en sí (como un lenguaje de modelado) y no modelar nada.

Habiendo dicho eso, también creo que su pregunta implica otra posible respuesta válida: algunas personas prefieren usar estereotipos para designar (informalmente) ciertas similitudes entre las clases. Podrían hacer eso solo porque es más fácil que subclasificar 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, usted podría querer tener una clase común como Entity para derivar Company, Customer etc. de. Pero inicialmente es probable que sea suficiente 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.

Answer 3

En su ejemplo, el actor probablemente no necesita implementarse como una clase, pero esto puede o no ser siempre el caso. Estereotipo son abstracciones que se pueden aplicar a la mayoría de los elementos UML, no solo a las clases.

Encapsulan la semántica sin implicar cómo se proporcionará esa semántica. Otro ejemplo podría ser un canal de comunicación 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 capacidad de definir sus propios perfiles pasantes. Puede etiquetar un objeto de dominio como un EJB para salvarse especificando todo el código de la placa de la caldera.

Answer 4

Una buena indicación de la intención detrás de los estereotipos se puede ver 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 estereotipo aplicado a Clase. Trae consigo personalizaciones de una clase para su uso en ingeniería de sistemas. En este caso, reemplaza el uso de Class y establece nuevas relaciones con otros elementos y tipos de diagramas, p. El bloque < < satisface >> El requisito (relación permitida) o un bloque se puede modelar utilizando un diagrama de bloque interno (comportamiento permitido). Un estereotipo no se utiliza para modelar el espacio de la asignatura. Clasifica el uso de construcciones de modelado para un aspecto vertical u horizontal de la definición de sistemas.

Answer 5

Un estereotipo amplía la estructura del metamodelo UML especificando p. Ej. los atributos específicos del dominio en los elementos en un modelo UML y no alteran la semántica en tiempo de ejecución del sistema que se modela; solo enriquecen el lenguaje de modelado.

Un buen ejemplo de esto es darle un "papel" a una clase en el diagrama del patrón de diseño. La funcionalidad de la clase se da dentro de la clase, no se agrega por el estereotipo, esto apoya la declaración anterior.

Ahora, la parte difícil es la herencia o clases estereotipadas; bien 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 se aplican también a la clase especializada. En mi opinión, esto todavía no se aplica al tiempo de ejecución, por lo que nuevamente la ambigüedad permanece en el nivel semántico. Más en this mail thread.