Re: Equema Para Realizar Una Aplicación En Gambas
No se lo que me quieres decir, no se a lo que llamas "reglas de negocio"
... lo que yo quiero indicar es que en los módulos se van a usar objetos instanciados de clases, para realizar las tareas....
Reglas de negocio es un término que se utiliza generalmente en diseño de bases de datos para referir a los requerimientos funcionales del programa. No creo que lo que sigue sea necesario, pero lo escribo de todos modos para evitar dudas: las reglas de negocio (requerimientos funcionales), determinan qué debe hacer el programa, lo que nos permite construir el "modelo" (en realidad modelo de la solución), relacionalo con el patrón MVC (Modelo-Vista-Controlador).
El modelo, entonces, es la parte del programa resultante que se ocupa del comportamiento esencial, de "la lógica" del programa.
Osea, que habria que indicar, que hay clases, que pueden contener a otras clases...no?
Saludos
Yo no lo diría así porque puede prestarse a confusión (puede dar la idea de que una clase es un contenedor, como un array o una colección), más bien que en la definición de una clase se pueden incluir variables de referencia de otras clases.
Hay tres cosas más que me parece deberías corregir.
La primera es que los elementos del gráfico y específicamente las líneas tienen que tener un significado preciso: deberías evitar todo elemento del gráfico que sea redundante o que no esté cumpliendo una función específica (por ejemplo, con dos recuadros para formularios sería suficiente). También deberías evitar que las líneas se crucen, que tengan diferentes formas o color (a menos que ello sea para señalar un significado distinto del de otras líneas).
La segunda, es que tu gráfico muestra el uso de módulos y clases, lo que implica una mezcla entre el paradigma de objetos y el procedimental. A mí me parece que deberías eliminar la palabra módulos del gráfico y sólo referirte a clases.
Creo que el uso que sugieres para los módulos es lo que en POO se conoce como objeto guión (guión como en el cine o el teatro): estos objetos contienen métodos que crean objetos de otras clases y les pasan mensajes (realizan llamadas a sus métodos); algo que, visto con un nivel de abstracción mayor, implica que ese objeto guión les está ordenando a otros qué quiere que haga/n, que vendrían a ser como actores que dicen sus diálogos (hacen lo que están programados para hacer) siguiendo el guión de la obra.
La tercera, es que deberías reemplazar elementos específicos con elementos más generales, por ejemplo, el elemento que está para indicar una base de datos, con el concepto más general de "persistencia" (bases de datos, bases de objetos, archivos o lo que fuere) y "Formularios" por clases de la vista (porque una aplicación no necesariamente usará formularios, tal vez genere su vista en formato html).
En síntesis (para que después no me acuses de que no puedo sintetizar lo que digo :P):
- Simplifica el gráfico eliminando elementos que no cumplan una función.
- Usa elementos diferentes sólo cuando quieras señalar un significado distinto (usar sólo un color, nada de líneas negras, grises y rojas si tienen el mismo significado).
- Haz que el gráfico sea consistente también en cuanto al paradigma de programación al que refiere. En todo caso sería mejor que hicieras dos, uno para objetos y otro para procedimental.
- No incluyas elementos específicos (bases de datos, formularios) si quieres que tu gráfico sea más general.
Saludos.
PD: una cosa más que había olvidado, si quieres señalar que ciertos elementos del gráfico constituyen una posible capa en la aplicación podrías encerrarlos con un recuadro de líneas redondeadas con un cierto color de fondo.
dos hermanas, sevilla
Foro 
