Cita:
Empezado por Chris
El consejo que te daré es en resumen: Olvidá el modelado.
Dibuja la interfaz gráfica que tendrá tu aplicación. Muestra tus dibujos a las personas que usarán tu aplicación. Luego de las pruebas, si la interfaz es lo suficientemente buena para cumplir el propósito que necesitas, es hora de pasar al modelado.
Pero ojo! El modelado de los datos te los debe decir la interfaz gráfica, no al reverso.
El problema de iniciar el desarrollo de una nueva aplicación por el modelado, es que nunca sabrás las necesidades de la interfaz gráfica. Para el usuario la interfaz lo es todo. Les importa un carajo la estructura interna de la DB que soporta a esa interfaz.
Otro problema con iniciar con el modelado, es que trabajas en un espacio muy abstracto. Es por esa razón que te sientes confundido. Aunque lo dibujes, no te ayuda mucho a vislumbrar el resultado final, el punto B a dónde quieres llegar, que es un programa visualmente usable.
Si empiezas a trabajar por la interfaz, esto te dará una visión más amplia y lúcida del problema y cómo resolverlo.
Haz tus bosquejos de la interfaz. Muéstreselas a sus usuarios. Una vez aprobadas, vuelve acá y te podremos ayudar a realizar el modelo que soportará a la interfaz. Tómate tu tiempo.
Saludos!
|
Voy a hacer de cuenta que no dijiste nada
Cita:
Empezado por roman
Oye, Chris, por menos que esto, en cualquier bar de OOP purists ya te habrían apuñalado  |
Puñal, no... es poco. Yo siempre tengo a mano mi AK-47
Cita:
Empezado por roman
¿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 |
Es que el error está en los extremos... Se necesita vislumbrar las cosas desde al menos 4 puntos de vista: lógica, presentación, datos y la más difícil de todas: integral.
Si uno dedica su mayo esfuerzo en la presentación dejando de lado el aspecto lógico y el de datos muy seguramente tendrá una interfaces muy bonitas pero que por dentro será muy RAD, fuertemente basado en el uso data-ware y no tendrá demasiado sustento lógico. Luego cuando el sistema se necesite ampliar tendrá que ir toqueteando algo para que funcione.
Si uno se concentra en el aspecto lógico y deja de lado la presentación y los datos seguramente logrará tener un buen sistema capaz sostenerse a ciertos cambios en el contexto, pero llevarlos a visualizarlos y en cómo obtenerlos y pasarlos a la base de datos tendrá ciertas dificultades que le tocarán su operatoria. Generalmente este esquema conduce a una renuncia de data-ware.
Si uno se concentra en los datos seguramente tendrá una base de datos bien robusta, con muchas de sus operaciones optimizadas. Pero en cuanto a ciertas operatorias que escapan a las posibilidades de un motor debe ir al plano lógico y luchará por estabilizar a la lógica según el modelo de su base de datos.
En síntesis si intentas ir por cualquiera de estos caminos sin detenerte a analizar las repercusiones en los otros, seguro que en algo se cae y tendrás problemas. Lo que debe hacerse es cuando analizar por partes y cuando analizarlas de forma conjunta. Debe haber un equilibrio.
Saludos,