De UML a Delphi...

[JorgeBec]

Antes que nada gracias por sus respuestas, crei que el hilo iba a provocar varias respuestas, creo que si el paso del diseño a la programacion es mas claro y transparente mas eficientes seremos en el desarrollo, de hecho hay Software como el de Rarional que ya te crea codigo en JAVA a partir de un diagrama de clases, y por lo que leí en un articulo el próximo paso de UML es generar ejecutables a partir de un trabajo de Analisis y diseño, !imaginense! sería sensacional, y no suena disparado ya que tenemos mucho material en UML, diagramas de clase, diagramas de secuencia etc. para poder generar codigo. Pero desgraciadamente sigue existiendo una brecha enorme entre Analistas y desarrolladores.

No hagamos un mundo aparte el de desarrollo ni el de Ingenieria de Software complementemos una labora con la otra para que nuestros desarrollos sean mas eficientes y nuestros costos puedan baja para que haya mas empresas
que se interesen en los desarrollos.

PD. les dejo esta liga de UML que se me hace interesantisima...


Taller de UML

[orfeo]

Como te respondieron lo mejor es hacer el soft en capas,
Algo sencillo, prolijo y que no lleva mucha progracion es crear un objeto Factura, que tenga todas las propiedades de alta,baja,modificacion y otras que debe tener una factura (pero solo datos, y sin interaccion del user).

Luego con un procediminto (fuera del objeto Factura) que se llame por ejemplo mostrarFactura(Factura), que si lo hacer prolijo deberia ser un metodo de otro objeo (pero alcansa con que sea en procediminto del formulario)
Por ultimo un conjunto de procediminto que tome el contenido nesesario de los componentes visuales y los actualice dentro del objeto Factura.

Por la parte de la DB podes poner el codigo en el objeto factura, como por ejemplo factura.commit; y este se encargaria de ver si tieen que insertar,eliminar o actualizar. Otra forma es tener un objeto DBFactura y le mandas DBFactura.commit(unaFactura).

Con todo esto estarias implementado algo parecido a MVC (model view control) que es una arquitectura para diseno de interfaces.

En conclucion, lo mejor es tener los datos en un Objeto, y luego hacer que se muestre o que se guarde en la DB.

[JorgeBec]

De nuevo gracias agradezco sus respuestas, las cuales me han parecido muy interesantes. Pero pretendo ser los mas practico y congruente con mi modelo UML.
Imaginemos lo siguiente Una clase factura que entre sus metodos esta el dar de alta una factura. y la funcionalidad de un sistema es la siguiente imaginemos una cotizacion que se hace efectiva y necesitamos facturar esa cotizacion entonces estando en la pantalla de cotizacion invocamos a factura viendolo analiticamente yo crearia una instancia de factura por que se que ese objeto tiene un metodo dar de alta, pero no, partiendo nuestro codigo en las capas que me menciona el colega marto, primero seria llamar a la interfaz frmAltaFactura(por ejemplo) la cual a su vez invoca al objeto factura, desde mi punto de vista se pierde la interpretacion de UML. No creen???, es decir seria mas facil encapsular la Interfaz de usuario en la clase factura, o bien planear tu codigo a manera que tu interfaz tenga una total correspondencia con un metodo de una clase que necesite de una interfaz no creen???


agradecere sus respuestas...

[roman]

¿Por qué ha de perderse la interpretación de UML? A fin de cuantas UML te servirá para diseñar no sólo los objetos del modelo (cliente, factura, pedido, etc.) sino también los de la interfaz de usuario (VistaCliente, EditarFactura, etc.)

En otros términos, la interfaz de usuario no tiene que ni debe reflejar el modelo. Esta independencia es la que te permitirá hacer las adecuaciones necesarias en uno u otro lado sin afectarse mutuamente.

Al capturar la interfaz de usuario en la clase factura haces a tu aplicación dependiente totalmente de la interfaz de usuario y cuando requieras cambiar la interfaz te verás envuelto en cambios al código estructural (el modelo).

En principio la interfaz de usuario debe conocer al modelo ya que hace uso de él para presentar datos al usuario y tomar datos de él pero el modelo no debe conocer la interfaz.

En cuanto a lo de ser más fácil, sí que lo es, y por esto la programación RAD tiene tanto éxito. De ahí a ser lo óptimo...

// Saludos

Ya siento las pedradas

[orfeo]

Empezado por JorgeBec

viendolo analiticamente yo crearia una instancia de factura por que se que ese objeto tiene un metodo dar de alta, pero no, partiendo nuestro codigo en las capas que me menciona el colega marto, primero seria llamar a la interfaz frmAltaFactura(por ejemplo) la cual a su vez invoca al objeto factura, desde mi punto de vista se pierde la interpretacion de UML. No creen???, es decir seria mas facil encapsular la Interfaz de usuario en la clase factura, o bien planear tu codigo a manera que tu interfaz tenga una total correspondencia con un metodo de una clase que necesite de una interfaz no creen???

Y que arias cuando deceas Cambiar un componete grafico, tendrias que cambair todo el objeto factura y la idea es poder cambiar una capa sin tener que cambair mucho la otra.


Talves no me esplique bien en el otro mensaje, frmAltaAfactura no llama a unaFactura (obj), se la madas como parameto (o una coleccion de ellas). para formar la capa View que te contaba de MVC., osea la capa view seria el from.

Dependiendo de la interaccion del formulario (cambios) el objeto se actualizaria, supogamos que definis un evento onChange de un label llamado lblPrecio.
Cuando el label cambia se produce un evento e invoca un metodo unaFacura.setPrecio(value);
Esta interracion entre los componentes visuales y el obj unaFactura seria mas o menos la capa Control.
Para lograr una separacion 'perfacta" deberias definir eventos en el objeto unaFactura para que informe a los componentes graficos que se actualicen solos al cambio de unaFactura.
Estos eventos informarian de un cambio en un valor, y el conponete que le interese dicho cambio pediria el nuevo valor.

con esto estas separando la capa de UI de la informacion, podrias cambiar la estructura/implementacion del Objeto sin cambair la UI, o cambiar la UI (tipos de componentes) sin tener que tocar el objeto factura. Dado que este ultimo no conoce los componetes visuales. Adentro de el nunca tendrias un lblPrecio.text:=value;

y ahora solo te falta separar la DB, que en realidad ya lo esta. al tener un objeto.., el objeto es la DB, el es el responsable de mantenerce consistente con la DB al momento que el cambia.
Pero en realidad a mi gusta mas la idea de tener un obteto que le mandes la factura, ej. DB.commit(uanFactura);


De culquier forma no se puede logra una separacion absoluta entre la entre los datos y la UI, termina jugando la complejidad para programarla y la performance. (pensa cuando usamos un DBGRID para listar y hacemos que el user defina los tipos de busqueda, es muy dificer tener una buena performance sin usar un DBgrid, si las tablas son muy grandes)


Para que te convensas podrias buscar algun libro que explique diferentes arquitecturas de UI, las vas a poder relacionar y te vas a dar cuenta que ninguna es milagrosa. Yo te decia la MVC porque la estoy empresando a aplicar (muy rudimentariamente) y es vastante buena viendola con respecto al costo de programarla.

Por tus dudas de UML, es un lenguage de Modelado, que te sirve para modelar cualquir cosas, desde requeriminto, diseno, arquitecturas, cualquier cosa O.O.
No se que tan abansado tenes tu proyecto, pero si ya definiste el Diagrama de clases, tendrias que descrivir con algun diagrama de iteracion los casos de uso y te vas a empezar a dar cuenta las relaciones entre las clases.

Luego de eso deberias empesar a definir las interfaces de las clases y como interactuan (quien llama a quien y como lo hace) , luego de esto vas a empesar a ver el codigo dibujado (dependindo de la experiancia de uno, es lo que dicen), es mucho mejor darte cuenta que tenes un error o que te falta algo que no tubiste en cuenta, talves algun caso mas... en un dibujo que en el codigo ya programado.
Y esto realmente te lo da la experincia, porque te lo tenes imaginar, de la misma forma que cuando uno codifica la idea que uno tiene en la cabesa de un programa, la ventaja que al dibujarlo podes encontar errores antes de codificar.

Bueno, cualquier cosa segimos debatindo, me biene justo porque el 11 rindo desarrolo de sofware.
Ha por casualidad nadie esta interesado en debatir antes del 11 el tema FrameWorks?

[marto]

Empezado por orfeo

De culquier forma no se puede logra una separacion absoluta entre la entre los datos y la UI, termina jugando la complejidad para programarla y la performance. (pensa cuando usamos un DBGRID para listar y hacemos que el user defina los tipos de busqueda, es muy dificer tener una buena performance sin usar un DBgrid, si las tablas son muy grandes)

Es algo muy largo de explicar en un foro, pero te aseguro que se puede separar asolutamente y sin un perjuicio excesivamente alto sobre el rendimiento.

Como pista te diré que la clave está en definir muy bien las clases tipo "ListaDatos" para cada tipo de colección de datos que necesites mostrar. El tema es optimizar a tope cómo acceden estas clases a la BD y definirle métodos distintos para posibles ordenaciones.

Mi experiencia me dice que es mejor penalizar un poco el rendimiento (en programación de gestión) siempre que a cambio obtengamos código más claro y mantenible. De hecho, si te preocupa demasiado el rendimiento, lo mejor es que programes RAD ya que los acceso a datos siempre está más optimizado (si lo programas bien, claro!!)

[roman]

Empezado por marto

Es algo muy largo de explicar en un foro

Sí supongo que explicar toda la teoría sería excesivo pero sería fantástico que expusieras algunas ideas (si lo deseas claro). Creo que todos nos beneficiaríamos enormemente.

// Saludos

[marto]

Bueno, en lugar de pegaros un rollo patatero sobre mis divagaciones mentales sobre programación os pondré un ejemplo de cómo lo he hecho yo en un caso concreto.
Veamos, yo necesitaba representar empresas que eran clientes de la mia. La base de datos ya estaba diseñada (en Oracle) y tenía que respetar su estructura.
Evidentemente diseñé mi clase TEmpresa con todas sus propiedades y métodos. Esta clase (como todas las demas) no tiene acceso a la BD, si no que "ve" a un módulo de datos (DmFacturas) que es quien se encarga tanto de servirle los datos como de manipularlos.
Por otro lado cree una clase TListaEmpresas que era la que se encargaba de mostrar los conjuntos de empresas, por ejemplo en una pantalla de búsqueda. Esta clase tiene distintos métodos que son los que se encargan de efectuar las búsquedas:
CargaPorCodigo(Codigo: String), CargaPorNombre(Nombre: String)...
La clase TlistaEmpresas lanza una función en DmEmpresas que devuelve un TList con estructuras con los datos de las empresas. En estas estructuras solo se guardan los datos "propios" de la empresa, no aquellos vinculados (como podrían ser sus centros de trabajo o el nombre de sus empleados). Con cada item de la TLista iremos creando una TEmpresa i la guardaremos en una TObjectlist interna de TListaEmpresas (esta es la lista propiamente dicha).
Para cargar los datos en el grid de búsqueda tansolo tendremos que ir pidiendo los datos de cada posición de TListaEmpresa en un bucle. Además, podemos ir guardando en la propiedad Objects del Grid cada una de las TEmpresa que esté vinculada al registro, así, si el control permite ordenaciones (o si en lugar de un grid es un combo) no perderemos el vinculo al objeto.
Cuando el usuario eliga la empresa que quiere, la pantalla retorna el propio objeto de manera que la pantalla que llamó a la de de búsqueda tenga acceso a él y pueda mostrar el resto de datos o editarlos o lo que haga falta.
Para acabar solo remarcar dos aspectos que considero cruciales en este tipo de arquitecturas para evitar un desperdicio desmesurado de memoria.
En primer lugar, los objetos "grandes" que contienen apuntadores o incluso listas a otros objetos no tienen que instancirlos ni cargarlos en su constructor ya que muchas veces ni se consultarán sus datos ni se modificarán y estaremos cargando mucho la memoria y efectuando consultas a la BD innecesarias. Creo que lo mejor es instanciarlos en el metodo de lectura y destruirlos en el destructor. Por ejemplo, en el caso TEmpresa, supongamos que tenemos una propiedad Centros de tipo TListaCentros que apunta a una lista de TCentro's:

private
  FCentros: TListaCentros;
  ...
public
  property Centros: TListaCentros read GetCentros;
  .....
constructor TEmpresa.Create(AOwner: TComponent); 
begin
  inherited;
  ...
  FCentros := Nil;
end;

destructor Destroy; 
begin
  ...
  FCentros.Free;
  inherited;
end;

function GetCentros: TListaCentros;
begin
  if not Assigned(FListaCentros) then
  begin
	FlistaCentros := TListaCentros.Create(Self);
	FlistaCentros.Carga(//parametros de carga);   
  end;  
  Result := FlistaCentros;
end;

La otra cosa que considero indispensable es asegurarnos que, por ejemplo, por cada instancia de TEmpresa NO se cree una de TDmEmpresa ya que al cargar, por ejemplo, una lista 100 de empresas, ''crearemos 100 modulos de datos!!!

Bueno, me acabo de leer todo lo que escrito y creo que no se entiende nada, pero es que es que sobre este tema se escriben libros enteros. Por otra parte para explicar mejor el funcionamiento del ejemplo os tendría que pegar aquí todo el programa, y tampoco seria plan!