Como podria modelar esto

[mamcx]

Yo diria que ambas direcciones son necesarias. El problema de diseñar basado en la GUI es ampliamente documentado, y genera aplicaciones "acopladas", lo que en general es mala idea.

Por el contrario, sin tener un "destino final" es muy facil empezar a implementar codigo basura/inutil.

Lo que hago, luego de siempre hacer los diseños directamente en el IDE, luego tratar de usar UML, luego tratar de usar OO, luego de intentar usar especificaciones funcionales, luego de usar mockups, luego de usar unit testing, es esto:

- Usando un programa como www.pivotaltracker.com (cualquier cosa que soporte scrum, donde tenga: Estoy haciendo, hecho, por hacer) voy agregando que voy a hacer, que necesito, porque, los bugs, los errores, etc EN LA MEDIDA QUE NATURALMENTE VAN SALIENDO <= esto es lo importante, y en iteraciones de 1-2 semanas

- Hago mockups. Como quiero que salga la app al final

- Hago unit testing, que me va perfilando el API del sistema

-Uso un tablero para rayar, de esos blancos. O el iPad para hacer dibujos

- Cuando los unit test masomenos estan bien, voy montando la GUI. Refactorizo muy liberalmente.

- Repito todo lo anterior hasta que llegue a una version 1, en algun momento, miro los mockups iniciales y veo que algo que se me ocurrio no estaba en el sueño del producto, asi que lo descarto. Cuando me parece que me voy acercando, pongo un "fecha limite" de version 1, y lo que se me va ocurriendo lo pongo en la lista de "despues de version 1".

Es igual si la app es idea mia, o por medio de un cliente.

O sea, en general:

- Si veo que tratar de hacer un diagrama UML no me permite expresar bien lo que se necesita, o me entorpese el llegar a una solucion, desecho esa herramienta y cojo otra

- Si haciendo un unit test, comparado con el mockuo, veo que el unit test no expresa lo que busco, lo hago en la gui

- Si algo no esta en los requerimientos, y deberia, lo agrego

- Si algo no esta en los requerimientos, no lo hago. Y no, no es contradiccion con lo anterior

- Si hago un dibujo de la interfaz y eso no me resulve como hacer la tabla, hago la tabla en el motor de BD

- Si hago un tabla, y no veo como rayos eso tiene que ver con la GUI, pues miro la GUI, me doy cuenta que los datos los guardo de una manera que me va a resultar dificil guardar/leer esos datos despues, cambio la tabla. (intento que los datos expresen de forma natural, simple y directa lo que la APP necesita)

- Si el cambio en la tabla termina siendo un problema de desemepeño, ignoro un rato eso. Igual estoy cambiando todo todo el tiempo, ahora no es el mejor momento de resolverlo. Cuando lo es, se hace el refactoring (como dije, refactorizo de forma MUY liberal).

Le perdi el miedo a hacer cambios drasticos. En un sistema que estoy llegando a su version 1, luego de 3 meses, hemos hecho cambios drasticos como 3 veces, cambiado librerias fundamentales como 2 y si me toca hacerlo en un lenguaje diferente, pues lo hago.

PERO

Solo si esta dentro del alcance del proyecto, requerimientos, etc.

Osea, se usa la mejor herramienta para hacer el diseño de cada parte de la App. Una veces, es mejor directamente en codigo. Otras, directamente en la BD. Otras, es un mockup. Otras, es escribiendo. Otras es sentarse un rato y conversar con alguien sobre el tema.

El diseño lo trato como codigo, no duplico el esfuerzo innecesariamente (es por eso que no hago UML. Si el diagrama de clase sera una clase, la hago como una clase y listo. Para que duplicado en un UML y como codigo?)

"Use the source, Luke"