Como podria modelar esto

[Casimiro Noteví]

Yo no quería decir nada, pero es lo primero que hago, pienso en las pantallas, en los datos que se van a necesitar, cómo van a trabajar luego los usuarios con el programa, etc. y después diseño la base de datos con esa información

[[Delphius]]

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

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

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,

[roman]

Yo de esto no sé. Realmente. Según recuerdo de cuando leí algunas cosas de Scott Ambler, una buena herramienta para iniciar una aplicación OOP son las CRC-Cards. El artículo de la wikipedia está muy chafa pero él lo describía mejor e indicaba que eran un medio muy bueno para hablar con los clientes.

Y es que, a mi me suena raro eso de que

Para el usuario la interfaz lo es todo

Quizá para el usuario final, es decir, el que realmente va a lidiar con la aplicación todos los días, pero no para el cliente que encarga la aplicación. Éste entiende de procesos.

En fin, da para mucho.

// Saludos

[[Delphius]]

Empezado por roman

Yo de esto no sé. Realmente. Según recuerdo de cuando leí algunas cosas de Scott Ambler, una buena herramienta para iniciar una aplicación OOP son las CRC-Cards. El artículo de la wikipedia está muy chafa pero él lo describía mejor e indicaba que eran un medio muy bueno para hablar con los clientes.

Pues si, las tarjetas CRC son una de las opciones. Aunque hay que hacer la advertencia de que sólo son a modo de orientación o guía; aunque hay ciertos requisitos que dificilmente se pueden capturar en una tarjeta CRC. El problema de las tarjetas CRC está en que se condiciona a hablar en POO. Y hay ciertos clientes al que les cuesta entenderlas... El problema muchas veces está en que no se logra apreciar las clases. Es requisito fundamental contar con las clases para encarar las tarjetas.
Por este motivo se las suele complementar empleando los Casos de Usos, que logran capturar los procesos y luego de estas "historias" uno puede detectar las clases conceptuales y allí ya meterse con CRC.
Tanto CRC como los Casos de Usos son algunas de las técnicas empleadas para la recolección de requisitos... y aún así no todo se logra capturar o que sea fácil de asimilar. Por ello es que se adjuntan también los glosarios, tablas de especificaciones complementarias... incluso es hasta bueno o saludable tratar de entender el contexto analizando las visiones (como una lista de actores-objetivos).

Algo que tiene de bueno el enfoque de casos de uso es que ayuda a ordenar las cosas basándose en el contexto y los procesos. Para ello emplea una guía denominada Casos de Usos EBP (Elementary Business Processes). Es decir se resaltan las actividades y procesos más significativos y que aportan valor y significado al negocio, recolectando los datos que se necesita, quien lo hace, en que momento, y en respuesta a que evento.

De este modo ya el propio caso de uso te aporta y filtra el material para ir detectando las potenciales clases.

Tengo que contarte que las tarjetas CRC ya están quedando en desuso.

Hay otros enfoques que fuerzan a detectar si las cosas las estamos pensando bien... el diseño dirigido por contratos ayuda a determinar que operaciones se necesita para ir de un estado consistente a otro. Cuando uno define las condiciones iniciales y finales ya puede darse una idea de como son las interacciones entre las clases, el estado y asignaciones de cada objeto.

En fin que no se trata de una única cosa... hay un enorme arsenal de herramientas que uno puede tomar. Y luego es que algunos dicen que la Ingeniería de Software es una burla

Ya lo dijo Grady Booch:

Las personas son más importantes que cualquier proceso.
Buenas personas con un buen proceso siempre actuarán mejor que buenas personas sin procesos.

Saludos,
PD: No hace falta decir que soy defensor de la ingeniería de software supongo