Hola!
Estoy terminando mi diagrama de clases hecho con StarUML, pero por una de las especificaciones requeridas por las pruebas que nos dieron me queda una caja ancha, gigante con un nombre de método largo y un montón de parámetros. Esta bien que quede así o hay que hacer algo para que se achique?
Saludos!
Hola Rodrigo:
Recordá que la idea es que el diagrama muestre un modelo esquelético (como lo llama Martin Fowler) de tu solución, es decir, mostrando detalles interesantes y ocultando aquellos que no. Un mensaje así de grande probablemente no sea relevante, dependiendo de qué es lo que quieras mostrar. Por otro lado, si considerás que es importante mostrarlo pero te ocupa demasiado espacio, podés optar por partir el diagrama en dos o más partes. Es decir, podrías hacer un diagrama con algunas clases principales mostrando gran parte de sus detalles y luego otro diagrama con menos detalles de esas clases pero incluyendo otras clases que antes habías ocultado para hacer énfasis en las relaciones.
Saludos,
Tomás
El problema que tengo es que, justamente, el mensaje largo es de una clase principal. El nombre del metodo esta dado por las pruebas descargadas. Tambien se me ocurrio no poner el nombre exacto, y asi comprimir un poco el nombre. No se su puedo dar detalles de lo que querria hacer por aca. Voy a dar un ejemplo:
AutoSeAlquilaHastaAnioMesDiaHoraMinuto( unAnio, unMes, unDia, unaHora, unMinuto) AutoSeAlquilaHastaFecha(fecha) Es una buena simplificación aunque depende mucho de lo que quieras mostrar. Si lo que querés mostrar con tu diagrama no está relacionado con la fecha entonces no habría problema.
Por eso, como mencionaba antes y como está en las recomendaciones, te conviene hacer varios diagramas. Quizás en uno puedas poner algunas pocas clases principales en donde sí pondrías el nombre completo de los principales métodos de cada una y luego, en un segundo diagrama en donde mostrarías más clases podrías poner el nombre simplificado de ese método (o directamente no incluirlo).
UML es un estándar y conviene respetarlo para que no haya dudas en la comunicación del modelo pero, si tantos detalles ensucian el dibujo entonces podés omitir algunos de manera criteriosa. Siempre es preferible que ocultes atributos antes que métodos (para mostrar las responsabilidades de las clases) y por supuesto no todos los métodos son relevantes para todos los diagramas. Si es más importante respetar la notación UML para las asociaciones y que sea coherente con el código.
Saludos,
Tomás
Buenos días, también se incluyen las clases que son excepciones en UML? No lo encontré explícito que se incluyan o no (Si bien son excepciones, son subclases de Error, pero como no hacen nada por sí mismas o no se instancian...). Gracias.
Las clases de excepciones sí se instancian y técnicamente podrían estar en un diagrama UML de clases. Si conviene o no dependerá de lo que quieras mostrar en cada diagrama. Probablemente al incluirlas harías que tu diagrama quede demasiado grande y se "ensucie" y no te convenga. Quizás podrías hacer varios diagramas y en uno solo de ellos mostrar las excepciones y en él ocultar otras clases de tu modelo. Aunque en el caso del TP no es tan necesario ya que hay una sección en la que las enumerás, así que el diagrama con excepciones quedaría como algo opcional (o sea, no se espera que lo incluyan pero si lo hacen y no ensucia el diagrama no va a estar mal).