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 (http://www.vico.org/pages/TRAD_cards/TRAD_cards_menu.html)

[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 :rolleyes:

:D

[orfeo]

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]

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]

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!

[JorgeBec]

Gracias, mil gracias por sus mensajes. Ni hablar, me hace mucha falta saber de programacion orientada a objetos, como lo comente anteriormente me muevo mejor en Ingeniería de Software. Propongo algo, alguien podria compartir algun ejemplo de un diagrama de clases y la implementacion de las mismas en codigo...??? y si alguien vio la liga del taller de UML que puse quisiera saber sus comentarios, sino aqui va de nuevo...

Taller de UML (http://www.vico.org/pages/TRAD_cards/TRAD_cards_menu.html)

[marto]

alguien podria compartir algun ejemplo de un diagrama de clases y la implementacion de las mismas en codigo...???

Yo no puedo hacer eso que me pides ya que mis diagramas y su código no son propiedad mía (una cosa es poner un ejemplito, y otra ponerlo todo).
De todas maneras, es un tema un poco complicado ya que este tipo de diagramas, cuando pertencen a sistemas reales acostumbran a ser grandes y complejos, así que no es tan sencillo como "compartirlos" para que los demas los sigan.

[JorgeBec]

Tienes razon Marto, y a veces tambien la confidencialidad de los mismos influye entonces, cambio la pregunta, alguien sabe de alguna liga Ingles o español de un ejercicio que vaya de UML a Delphi???, ah y si alguien me puede pasar la liga del MVC, se los agradecere...

[JorgeBec]

Chequense el mensaje que puse en noticias "La solucion de UML a Delphi", creo que esto es lo que estaba buscando, y espero que les sirva a toda la comunidad...

[marto]

Lo que comentas de Delphi 8 es interesante, pero tiene tres problemas:

1.- Es delphi 8, o sea que te obliga a tener esa versión de Delphi y a trabajar con .NET

2.- Si no me equivoco están disponibles solo en las versiones más caras y, créeme, son muy caras.

3.- Existen bastantes voces que ponen en duda la estabilidad, hoy por hoy de este sistema.

Si lo que quieres es aplicar OOP a Delphi como metodología de desarrollo lo puedes hacer a pelo. Tal y como te he dicho en este mismo hilo, en la revista sintesis en http://www,grupoalbor.com encontrarás una serie de artículos sobre el tema de mucho nível, con ejemplos y código fuente.

[marisara]

Hola,

Estoy haciendo mi proyecto final de carrera y tengo una duda:
¿Se puede hacer un programa en Delphi que no sea orientado a objetos?; ya que según lo que he leido Delphi es híbrido, permitiendo también la programación estructurada.
El problema es que a la hora de hacer el estudio de ingenieria de software (aunque ya sé que este se debe realizar antes de codificar; pero en cada empresa se trabaja de una forma diferente), no veo que mi programa tenga clases, por lo que me resulta imposible realizar diagramas UML.
Entonces no sé si al realizar el estudio de ingeniería de un modo estructurado estaré haciendolo mal.

Gracias de antemano por la respuestas. :D

[JorgeBec]

Gracias al compañero marto que nos paso el tip de la revista Sintesis, y alli viene una gran explicacion de toda esta problematica, me agrado que partan de que pueden desarrollar en Delphi de 2 maneras:

1) Aprovechando los beneficios del RAD
2) Programando en capas, lo cual nos daria mejor mantenibilidad y mejor entendimiento, sacrificamos la rapidez, pero los beneficios son mucho mayores


Puedo comentar que especificamente los numeros 16, 17, 18 de la revista traen un articulo de UML con Delphi, esta sensacional, se los recomiendo y abrira mucho la mente para desarrollar de una manera mas organizada y aprovechando todo tu trabajo de análisis...