Como podria modelar esto

[[Chris]]

Empezado por roman

Oye, Chris, por menos que esto, en cualquier bar de OOP purists ya te habrían apuñalado ¿Cómo que empezar por la interfaz gráfica? Se supone que tu interfaz no debe guiar tu modelado y, de hecho, la interfaz tiene su propio modelado.

Por otra parte, muchas veces hago como tú

// Saludos

Creo que david_uh, no se refería precisamente a la "TClass"... sino a la estructura de las tablas y la DB.

A los usuarios lo único que les importa es la interfaz. Les vale madre que su implementación sea un desastre o sea impecable. Por eso es que los usuarios prefieren Windows, a pesar de ser un desastre de S.O.

Un desarrollador o equipo experimentado puede crear una muy buena estructura interna usando la GUI como inspiración.

Cuando hacía aplicaciones para Delphi, lo primero que desarrollaba era el diseño de las ventanas. De hecho, esos diseños me sugerían una buena estructura para empezar. Por ejemplo, si la gran mayoría de ventanas requierían de un TDBGrid, entonces cuando hacía la implementación desarrollaba una clase, por ejemplo TDBModuleWnd. TDBModuleWnd ya incluía un TDBGrid y un TDataset con código centralizado para las operaciones CRUD y control de errores. Los herederos sólo cambiaban detalles.

Empezar con la GUI es trabajar de afuera hacía adentro. Empezar con los modelos es trabajar de dentro hacia afuera.

Si fueras a construir un edificio, primero vas con arquitecto para que te diseñe cómo se verá y esas cosas. Luego vas a un ingeniero civil para que haga los cálculos que soportarán ése diseño. Empezar con los cálculos primero es ir dando palmadas de ciego en el futuro. No sabes cuántos pisos tendrás, no sabes dónde habrán escaleras o no, dónde estarán las puertas, etc.

Saludos!

[Casimiro Notevi]

Empezado por Chris

A los usuarios lo único que les importa es la interfaz. Les vale madre que su implementación sea un desastre o sea impecable.
Por eso es que los usuarios prefieren Windows, a pesar de ser un desastre de S.O.

Eso te va a traer cola


Aunque yo estoy de acuerdo

[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"

[[Delphius]]

Empezado por Chris

Creo que david_uh, no se refería precisamente a la "TClass"... sino a la estructura de las tablas y la DB.

Entonces tenemos que darle un buen tirón de orejas para que llame a las cosas por su nombre.

Empezado por Chris

A los usuarios lo único que les importa es la interfaz. Les vale madre que su implementación sea un desastre o sea impecable. Por eso es que los usuarios prefieren Windows, a pesar de ser un desastre de S.O.

Que la interfaz sea lo que en última ve el cliente/usuario no le da el mérito para rechazar los otros aspectos.
¿De que carajo sirve tener una hermosa fachada si por dentro las bases no son sólidas?
Ubuntu es según muchos de los GNU puristas y de lo más entendidos es la peor distro que hay (con el debido perdón Casimiro) ¡Y Oye, es Linux! Pero que bonito se ve.

Empezado por Chris

Un desarrollador o equipo experimentado puede crear una muy buena estructura interna usando la GUI como inspiración.

Patrañas. Una estructura interna o para decirlo como debe: la lógica, o más técnico: las capa de aplicación y/o dominio (si nos vamos al OO) se analiza y se piensa para actuar independiente de cualquier ventanita. Y es lo deseable.
Si tomas como base las ventanas estás añadiendo dependencia, en mayor o menor grado, con la lógica. Lo cual no es bueno frente a procesos de mejoras y/o de reingeniería.

Empezado por Chris

Cuando hacía aplicaciones para Delphi, lo primero que desarrollaba era el diseño de las ventanas.

Curioso, yo dejo la interfaz para lo último.

Empezado por Chris

De hecho, esos diseños me sugerían una buena estructura para empezar.

Y creo que ya he señalado los peligros de seguir a rajatabla eso...

Empezado por Chris

Por ejemplo, si la gran mayoría de ventanas requierían de un TDBGrid, entonces cuando hacía la implementación desarrollaba una clase, por ejemplo TDBModuleWnd. TDBModuleWnd ya incluía un TDBGrid y un TDataset con código centralizado para las operaciones CRUD y control de errores. Los herederos sólo cambiaban detalles.

¡Y aquí señoras y señores el mejor ejemplo! Una ventana acoplada no sólo a la lógica sino a las operaciones delgadas y abstractas de la capa de datos.

Empezado por Chris

Empezar con la GUI es trabajar de afuera hacía adentro. Empezar con los modelos es trabajar de dentro hacia afuera.

Eso es precisamente lo que hace diferencia a un programador de un ingeniero.

Empezado por Chris

Si fueras a construir un edificio, primero vas con arquitecto para que te diseñe cómo se verá y esas cosas. Luego vas a un ingeniero civil para que haga los cálculos que soportarán ése diseño. Empezar con los cálculos primero es ir dando palmadas de ciego en el futuro. No sabes cuántos pisos tendrás, no sabes dónde habrán escaleras o no, dónde estarán las puertas, etc.
Saludos!

¿Curioso no? Al que elabora los planos de los sistemas se los suele denominar arquitectos de software, o más formalmente analistas. Lo más curioso es que este análisis y los planos que elabora el analista es la primera etapa del trabajo que luego es enviada al programador para construya sobre él.

Saludos,

[Casimiro Notevi]

Empezado por Delphius

Ubuntu es según muchos de los GNU puristas y de lo más entendidos es la peor distro que hay (con el debido perdón Casimiro) ¡Y Oye, es Linux! Pero que bonito se ve.

Sólo son envidias

[roman]

A decir verdad, salvo las críticas de fundamentalistas como noubuntu.org, que además van en otra dirección, nunca había escuchado eso de que es la peor distro.

// Saludos

[Casimiro Notevi]

Yo sí lo he oído/leído antes, pero lo decían porque permite instalar (si quieres) software no libre, principalmente los controladores gráficos.

[[Delphius]]

Empezado por Casimiro Notevi

Sólo son envidias

Empezado por Casimiro Notevi

Yo sí lo he oído/leído antes, pero lo decían porque permite instalar (si quieres) software no libre, principalmente los controladores gráficos.

Pues ese es uno de los puntos que yo también he leído. Y dicen que no sólo permite instalar software "no libre" sino que además, ¡ya viene con software no libre! Aunque eso no si es totalmente cierto.

He visto algo de esa web que comenta Roman, no se para que dirección apunta esa web pero no son los únicos que indican que Ubuntu es como la oveja negra de la familia GNU/Linux. Precisamente el principal defensor y creador del CopyLeft y el Software Libre (que no necesariamente el Open Source) NO APOYA A UBUNTU. De hecho según ÉL y la FSF, las siguientes distros no son válidas. Las distros que si promueve son éstas. Que nos las conoce ni el.
Y la verdad es que no me explico esto cuando hace unos cuantos años reconoció que utiliza Debian. ¿Que no era que no apoya a esta distro? ¿Que no era que utiliza Ututo?

Para ser un tipo que odia fanáticamente a lo no-libre...

Saludos,

[david_uh]

Creo yo que lo mas saludable informáticamente hablando es empezar por el modelado del sistema, el modelado es lo que a una arquitectura de un edificio se refiere teniendo un modelo claro coherente con clases bien definidas con atributos y metodos bien pensados es la columna vertebral de cada sistema informático, estoy en desacuerdo de empezar creando interfaces(aunque funciona bien para pequeños sistemas), aunque es algo que esta ya en tu cabeza, estas ya pensando como sería tal o cual pantalla, eso es innegable es como un instinto natural pero lo racional es que primero lo modelemos, es por ello que postee mis clases para saber cuales irian o cuales estan demás, ahora yo estoy seguro que el modelado y la definición de las clases no tien mucho que ver con la estructura de talas aunque claro los modelos son parecidos y es por ello que aparece JPA por la similitud que existe pero no quiere decir que las tablas sean el reflejo de nuestras clases. corríjanme si me equivoco.

Ahora volviendo a mis clases que cree, en el modelo de clases Estudiante, EstudianteNuevo, y EstudianteAntiguo tienen diferente trato pues el nuevo tiene primero que inscribirse ser evaluado, mientras que el antiguo pues ya tiene una pre-matricula y solo se apersona a la institución a matricularse con la seguridad de que su vacante esta separada y solo pagara y llenara algunos datos ya que el grueso de su información ya figura en los registros.mi problema era con lo de apoderado ya que siendo una persona que es familiar del alumno o no, podría ser una persona que haya sido autorizada por los padres, tal ve3z la clase Familiares no debería tener ese nombre sino mas bien Encargados o habria que crear una clase adicional llmada Parentezco como lo muestra el diagrama sin embargo que atributos o como seria alguna sugerencia, gracias por sus aportes.

saludos

David