UML – Modelado de la relación de herencia entre clases
He cursado la asignatura Sistema y Diseño Orientado a Objetos en la Universidad de Estocolmo. Tuve que entregar una tarea extra en la que tenía que crear un Diagrama de Clases UML que reflejara una web de venta de coches (este no es un hilo en el que os pida que hagáis mis deberes). Esto es lo que entregué:
El profesor dijo que «así no se usan los atributos» y parece reacio a explicar lo que debería haber hecho de otra manera. Está todo en sueco pero creo que los puntos principales están claros independientemente del idioma.
Me parece que tienes tus Enumeraciones modeladas como Clases. Aunque visualmente una Enumeración se parece a una Clase con un estereotipo <>, en realidad es una cosa totalmente diferente y tiene EnumerationLiterals en el compartimento cuando los Atributos serían para una Clase.
En ArgoUML puedes crear una Enumeración usando el cuarto botón de la derecha en la barra de herramientas. Es un menú desplegable que por defecto crea un nuevo Tipo de Dato, pero si lo bajas y seleccionas el rectángulo verde, creará una Enumeración. Crea primero tus Enumeraciones y estarán disponibles para que las selecciones como tipo para tus Atributos.
Ejemplo de diagrama de clases
Coloque automáticamente todos los elementos de un diagrama en un formato de salida mediante Graphviz (Software de visualización de gráficos). Todos los diagramas UML que se almacenan en formato XMI pueden ser procesados y exportados a PDF, SVG, PNG, etcétera.
Las transformaciones XSL para cada tipo de diagrama pueden utilizarse independientemente de ArgoUML y ejecutarse directamente sobre el archivo XMI. El diagrama de flujo siguiente ilustra los diferentes procesos que se aplican en ambos casos.
Del XMI se ha extraído el siguiente diagrama de clases con la transformación XSL (versión de desarrollo). Tenga en cuenta que aún no está completo. Sin embargo, muestra valores etiquetados que normalmente están ocultos. Su visualización es especialmente útil para los diagramas que van a ser procesados, por ejemplo, por AchGenXML.
Descarga de Argouml
La multiplicidad puede establecerse para atributos, operaciones y asociaciones en un diagrama de clases UML, y para asociaciones en un diagrama de casos de uso. La multiplicidad es una indicación de cuántos objetos pueden participar en la relación dada o el número permitido de instancias del elemento.En un diagrama de casos de uso, la multiplicidad indica cuántos actores pueden participar en cuántas ocurrencias de un caso de uso. La multiplicidad en un caso de uso podría significar que un actor interactúa con múltiples casos de uso, la multiplicidad en un actor podría significar que uno o más actores interactúan con un caso de uso particular.
La relación entre un jugador y el caso de uso de juego. Un juego puede ser jugado por muchos (dos o más) jugadores, pero un jugador no siempre puede participar en el juego.Para mostrar esta relación, se establece la siguiente multiplicidad: en el lado del actor 2.., en el lado del caso de uso *0..1. Esto se muestra en el diagrama de la siguiente manera:Para un registro completo de los detalles de una persona, la persona debe tener al menos una dirección, pero puede tener dos direcciones. Además, la persona debe tener al menos un número de teléfono, pero puede tener muchos. Para mostrar esto, se establece la siguiente multiplicidad: para el atributo de dirección la multiplicidad es 1..2, para el atributo de número de teléfono la multiplicidad se establece en 1..{*}. Esto se muestra en el diagrama como sigue:
ArgoUml Exportar su diagrama de clases y generar java
Los siguientes diagramas describen, sin una atención paranoica a la precisión, los detalles de la implementación de la versión 0.7.5 de RoboTracker. Algún día, crearé diagramas de secuencia y casos de uso y todo tipo de otros encantadores diagramas uml. Estos diagramas fueron producidos «post-facto» – por lo tanto, no se utilizaron en la generación del diseño. La metodología de diseño intenta seguir las ideas del «Test-Driven Development» aunque no he hecho esto antes así que los resultados pueden ser curiosos …
Gracias a los creadores de ArgoUML por permitir la creación de estos diagramas, y a los creadores de The GIMP para que pudiera capturarlos (sería genial si pudiera guardar imágenes de ArgoUML, pero entonces no tendría una razón para usar The GIMP, así que tal vez no sería tan genial …)
El objeto «Aplicación» es un contenedor para cada uno de los principales objetos del sistema: Factory, Persister, objetos Reporter, y el BeanShell Interpreter. Factory define todos los métodos relevantes para crear o encontrar objetos; Persister simplemente proporciona ganchos para que otras partes del sistema escuchen eventos de creación o actualización; los objetos Reporter crean informes, evidentemente; y el BeanShell se utiliza para ejecutar scripts de pruebas funcionales. Si alguna vez es necesario crear scripts de demostración o utilizar complejos scripts de inicio de usuario, el BeanShell será útil también en esos contextos. El uso de BeanShell para las pruebas funcionales parece ser más simple y más flexible que el uso de otras bibliotecas diseñadas para las pruebas de Swing GUI. En la mayoría de los casos, estas bibliotecas también se basan en scripts, excepto que sus lenguajes de script son más restrictivos.
Los comentarios están cerrados, pero los trackbacks y pingbacks están abiertos.