Diagrama UML abstraido o real

#3 no sé si entiendo la pregunta. Se hace exactamente como harías las clases programando, pero en UML.

Una vez tengas el UML puedes generar el esqueleto EXACTO del programa a partir de este, así que imagina el nivel de detalle al que debes llegar.

Yo es que no soy muy fan del UML porque considero que el desarrollo de software es una actividad tan compleja que modelar vale sólo para documentar, no para diseñar (a no ser que lo tomes como una guía inicial MUY burda... pero para eso ni me molesto en usar UML.) UML está bien para cuando conoces el dominio del problema al 100%, pero el caso no se suele dar (porque entonces tendrías el problema resuelto y no te haría falta )

Desarrollo incremental wins.

#1 Si la variable es privada, cuando hagas el diagrama de clases y reflejes esa variable la marcas con el - de privada y fiesta.

#7 no estoy de acuerdo y me voy a explicar xD. Para empezar odio más que nadie uml, creo que entra demasiado en detalle y es demasiado rígido en "sintaxis" o como lo se quiera llamar. Pero yo sin un diagrama de clases, donde obviamente voy a aplicar modelos de diseño no soy nadie, y soy incapaz de hacer una aplicación medio decente.

Sin casos de uso lo mismo. Y obviamente tienes que aclarar antes el dominio y el alcance, porque me parece clave para un proyecto serio. Si no sabes qué, como y hasta donde quieres llegar dime tú cómo te pones a programar algo xD

Y no, no me vale extreme programming XD

Edit: por cierto los diagramas de comunicación, secuencia y mierdas del estilo me los paso por donde yo te diga, menuda basura por dios xD

#1

Depende del uso del diagrama.

• Para generar código. Hay herramientas que te generan el esqueleto de la clase en el lenguaje que quieras a partir del diagrama. En ese caso tendrás que hacer lo que te diga la herramienta.

• Para diseñar. A veces si no tienes muy claro como hacer una cosa, verlo en dibujo te lo puede aclarar. No es necesario que hagas el diagrama como si estuvieses haciendo código... pon solo aquello que sea relevante para que te ayude a encontrar una solución.

• Para explicar. La gente es muy visual, y muchas veces si tienes que explicar un diseño a otra persona, es más fácil ponerle un dibujo, que 500 líneas de código o un tocho de texto de 50 páginas. Al igual que cuando vas a diseñar, no es necesario que lo detalles todo como si lo fueses a compilar... pon solo aquello que pueda resultar útil para lo que quieres explicar y omite el resto.

-Para documentar. Nunca lo hagas, es la mayor estupidez del mundo.

En resumen, mostrar una variable privada en el diagrama, es independiente de que exista o no en la clase real, solo la pones si es relevante para lo que quieres mostrar en el diagrama. En el caso de que la pongas, es como te ha dicho #6. Las variables privadas llevan un - y las públicas un +, casi todas las herramientas de modelado uml te ponen el + o el - automáticamente, en lugar de ponerlo tú tienes que indicar en las propiedades si es público o privado.

#11

Son filosofías de desarrollo, no hay una verdad absoluta, solo opiniones.

En Agile Modeling nunca se documenta con diagramas (no es por que sí, tiene su explicación, con la que puedes estar de acuerdo o no), y como experiencia personal, he trabajado durante 5 años en una empresa que exigía montones de documentación con una exactitud casi calcada a la del código, y no he visto los supuestos buenos resultados que te daría tener una documentación casi perfecta.

"Ver las relaciones entre clases, es decir, "the big picture of the project", facilita el poder meterte con documentación sin sentirte perdido"

Es que eso yo no lo considero documentación, entraría en el apartado que he puesto de "explicar algo". Parece lo mismo, pero el matiz es que solo muestras aquello que es relevante, no haces un calco del código.

#8 y si los casos de uso, el modelo y todo cambia constantemente? xD

Yo estoy con cabron, los uml, sus mierdas y su metrica3 se lo pueden meter por el ojal.

#15 te vas a cagar en muchos clientes a lo largo de tu vida xDD

Eso o simplemente cambias de metodología de trabajo a otra que se adapte mejor a los cambios.

#13

A lo que me refiero es que hay gente que su idea de documentar es crear una copia del código fuente con todo detalle pero en formato doc explicado con palabras o con diagramas, y eso es el demonio a punto de llevarse tu alma.

Es un tema que da mucho de sí, donde también influye como estén diseñadas las interfaces, buscando una especie de nirvana donde la propia interfaz sea la documentación del método (algo que no se va a conseguir 100% pero se puede conseguir mucho)

#4 Vale vale, es que no te habia entendido bien. Pensaba que te referias a modelarlo todo tanto para api externa como el esqueleto.

#6 Si, es de ambito privado. Pero se puede obtener su valor. Entonces tambien se consideraría publica.

Para aclarar dudas, que no lo he dicho. Sí, es un diagrama de clases. En realidad es un diagrama para documentar, porque no son muchisimas clases y no tiene complejidad, es decir que no es para aclarar su entendimiento.

Y sí. Yo tambien estoy de acuerdo en que diseñar una APP grande y compleja es un fail. Vas a tener que reacerlo casi seguro, a menos que tengas una mente privilegiada y seas capaz de preveer todo lo que vas a necesitar.

Al final optaré por una documentacion tipo API.

Ya podemos cerrar el thread como dice kaod. Estamos todos de acuerdo xD

Yo nunca entenderé utilizar UML más allá de los casos de uso o para explicar subsistemas concretos. Una api se documenta cojonudamente con un xxxdoc (javadoc por ejemplo).

Tengo pendiente mejorar toda mi forma de trabajar (desde el análisis hasta la implementación), quizás me mire algo del tema de agilismo. Aunque muchas cosas creo que están orientadas a equipos.

PD: No veas que puto coñazo documentar el PFC con las putas clases, y eso que las generaba desde el código (lo suyo es que hubiera diseñado y generado el código desde el UML, pero muchas cosas cambiaron).

#22 Una api se documenta cojonudamente con un xxxdoc
Depende de lo compleja que sea la API. Un framework por ejemplo queda mucho más claro y conciso con diagramas de clases (por lo "ligado" de sus clases.) Un xxxdoc no dice NADA de la relación entre clases (más allá de la herencia... e incluso ahí es muy poco descriptivo porque un árbol de clases tampoco me dice mucho...)

Por ejemplo, yo ahora estoy lidiando con overtone. Es un framework de generación de sonido sobre Clojure que usa Supercollider como backend de sonido. La documentación es penosa, mientras que un diagrama jerárquico de generadores/filtros me vendría de perlas!+

Agile ni te lo mires si no vas a estar en equipo, no tiene sentido. Como lone-developer el sentido común sobra.

#23 Entonces, si se puede acceder a la propiedad por que representarla como privada? No confundiria un poco?
Piensa que estás modelando/diseñando. Si lo que planeas es documentar, mejor hazlo AL ACABAR cuando tengas la API fijada.

Cada vez que veo algo de codigo en clojure me quedo loco xD
Me pasaba lo mismo y sin embargo ahora yo ya no puedo ver otra cosa, el resto de lenguajes me dan como grimilla xD

Pues yo no se si será cosa de costumbre o que, pero creo que llevar un buen diseño UML agiliza bastante luego a la hora de programar, organizar el código y hacer uso de patrones de diseño.

Las veces que he programado a capón luego he tardado más haciendo reingeniería porque tenia una mierda de código.

Normalmente hacer un análisis de requisitos, casos de uso y distintos diagramas (clase, etc..) suele hacerte comprender mejor el dominio del problema, y poder hacer un diseño mucho mas limpio para tu proyecto.

Por cierto me ha parecido leer por arriba, que usar agile implica no usar UML? Pregunto de verdad, porque yo pensé que una cosa no influía a la otra.