¿Está implícito el estereotipo de clase en un diagrama de clase UML? ¿Se debe especificar?
Comúnmente veo diagramas de clase donde no hay <<class>>
estereotipo. Otros donde está lo común <<interface>>
y otros con algunos interesantes como <<shape>>
o <<computer>>
y tal que para un diagrama de clases yo personalmente no veo la necesidad pero Ok.
Estoy haciendo un diagrama UML para un proyecto de álgebra moderna en C++, pero como sabemos, el lenguaje no debería ser tan influyente cuando se trabaja con UML. Para este proyecto, he reconocido los estereotipos <<interface>>
y <<abstract>>
todo bien hasta este punto, pero hay estructuras y clases, quiero hacer las cosas de la mejor manera posible, así que llegué a preguntarme: ¿son <<class>>
los <<struct>>
estereotipos válidos?
Agradezco sus respuestas o comentarios.
Nota: creo que struct
debería ser válido porque especifica el tipo para una determinada implementación.
Respuestas
No necesita indicar para indicar clases explícitamente en un diagrama de clases: se asume por defecto, según UML:
Una Clase se muestra usando el símbolo Clasificador. Como Class es el clasificador más utilizado, no se necesita ninguna palabra clave para indicar que la metaclase es Class.
Eres libre de definir tus propios estereotipos en UML. Se documentan mejor en un diagrama de perfil que muestra cómo se relacionan con los elementos UML estándar.
UML es lenguaje de implementación neutral. Es muy típico definir tipos de datos específicos del idioma (p. ej float
., double
que no pertenecen al UML estándar) y estereotipos (p. ej . class
y struct
). Vea, por ejemplo, aquí un perfil de C# , para un lenguaje en el que las clases y las estructuras tienen una semántica diferente.
Tenga en cuenta que no todo lo « »
que parece un estereotipo es un estereotipo. También puede ser una palabra clave bien definida:
- interfacees una palabra clave que hace referencia a algo con un significado claro en el metamodelo UML, que se comparte entre los diagramas de clases y los diagramas de componentes.
- enumerationes una palabra clave que se refiere a un tipo especial de tipo, que debe describirse de manera diferente a otros tipos y clases de datos básicos.
Dos comentarios muy importantes además:
- La introducción de estereotipos específicos del idioma hace que su modelo de diseño sea menos general y corre el riesgo de obtener modelos de implementación detallados en lugar de centrarse en el diseño abstracto. Por lo tanto, debe pensar en los pros y los contras. Si su modelo es neutral en términos de lenguaje, puede centrarse en OOD y dejar que se reutilice para un puerto Java o C#, por ejemplo. Si su intención principal es hacer un modelo de implementación, por supuesto que no es un problema.
- En C++ a
struct
es unclass
con todos los miembros públicos por defecto. Este es un principio básico del lenguaje. La diferencia es solo sobre el control de acceso. Dado que en UML documenta el control de acceso a nivel de miembro, tener un estereotipo« struct »
que requiere que todos los miembros sean públicos parece simplemente redundante. Aconsejaría usar clases no estereotipadas en UML y decidir en la implementación usar una estructura o una clase dependiendo de la visibilidad de los miembros.