De UML a Delphi...

[JorgeBec]

Hola a todos! este será un hilo de discusión que espero recibir varias respuestas. La mayor parte de mi experiencia ha sido con programación pero a ultimos años he estado interesado en todo lo que es Ingeniería de Software por que he visto la necesidad a la hora de programar, ya que constantemente me regreso a los requerimientos. Ultimamente me he metido a lo que es UML y es muy interesante, pero ahorita que estoy intentando llevar un proyecto completo. Hice mis diagramas de clase y segun yo esas clase hay que implementarlas en delphi pero me han surgido varias dudas. Por ejemplo imaginemos una clase factura que puede tener como operacion el alta de factura, hasta aqui todo suena bonito, pero como llevarlo a la programación es decir esa operación alta de factura debe incluir tambien los componentes visuales necesarios (edits, dbgrids etc) para dar de alta la factura???, cual es su experiencia, que recomiendadn los mas experimentados???, la OOP no tiene que ver nada con la OOA???

[JorgeBec]

A la fecha no he recibido respuesta de la pregunta que lance, será que la mayoria de los que participamos en este foro no usamos alguna metodología de desarrollo??? los que desarrollamos identificamos requerimientos muy al vapor y el análisis y diseño lo hacemos al momento??? o varios trabajan con equipos de análisis y diseño que hacen esa chamba y solo nos dedicamos a desarrollar???

Considero que hay que darle mas importancia a la Ingeniería de Software, para que el área de sistemas tenga una mejor reputación, que entrguemos a tiempo, que nuestros costos no se eleven, en especial las areas que desarrollan software...

agradeceré sus respuestas...

[marto]

Hola Jorge,

Normalmente, cuando quieres encapsular tu logica de aplicación en clases lo que se hace es diseñar varias capas, como mínimo 3: La base de datos, la interfaz y la "capa intermedia" que es donde van tus clases.
En el ejemplo que pones, la clase TFactura tendria que "ver" la base de datos o, aun mejor, un modulo de datos que le diese acceso a la BD. Por otra parte, la clase debe ofrecer una interfaz "suficiente" para que la interfaz de usuario (sea un form o una pagina web) pueda manipular esa factura.
Te pongo un ejemplo tonto de como podria quedar el código del boton guardar de un supuesto formulario que crease una factura nueva:

 
procedure TForm1.BtGuardarOnClick(Sender: TObject);
begin
  with TFactura.Create(Self) do
  begin
	try
	  Cliente := EdNumero.Text;
	  Descripcion := EdDescrip.Text;
	  //aqui guardariamos todas las propiedades y al final...
	 GuardateEnLaBd;
	finally
	  Free;
	end;
  end;
end;

Esto es solo un ejemplo, evidentemente se podria hacer de mil maneras, pero lo importante es separar la presentación grafica de el "meollo" del programa.

Si quieres más información, en el foro se ha discutido varias veces de temas parecidos y en http://www.grupoalbor.com , en algun numero de la revista Sintesi (que te puedes descargar gratuitamente) hay una serie de buenos articulos sobre como programar OO con Delphi.

[haron]

me parece muy interesante el UML, aunque tampoco estoy muy puesto al dia.

en pricipio se que es un lenguaje de modelado grafico que se utiliza para especificar, visualizar, documentar y desarrollar.

realmente no le veo mucho sentido llevar el UML a los extremos. es decir, me parece mas interesante el UML como un medio para documentar, trabajar con las especificacioes y poder visualizar distintas perspectivas del sistema, sin entrar en detalles, que para eso esta el codigo del propio programa documentado.

hablando de metodologias de desarrollo, hace un tiempo estuve leyendo algo de Programacion XP (programacion extrema) y parece muy interesante. al principio pensaba que era programacion para Windows XP o algo asi como programar con riesgo (extrema). no tiene nada que ver.

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