Dudas sobre el diseño en 3 capas

[cacu]

Querido delphinarios quisiera solcitar su ayuda en lo siguiente.

A modo de poder aprender la oop es que me he dispuesto un ejemplo practico :
Suponiendo un sitema para una ferreteria he tomado solo lo que se refiere a la codificacion de productos
que la dispongo como SuperFamilia-Familia-Subfamilia-Producto.-

por ejemplo
Ferreteria---------------------------------------->Superfamilia
Electricidad ------------------------------------->Familia
Transformadores------------------------------>subfamilia
transformador electrico--------------->Producto



Desarrollar una aplicacion que maneje codigos usando como fuente de datos access.

la estructura de codigo es : Super Familia Familia SubFamilia Producto

Luego ya con esto creo las tablas correspondientes en access.-
Por su parte en delphi construyo lo siguiente.

3 unidades :
1.- llamada Dato -> (Data Module) contiene las conecciones
2.- llamada registro -> contiene los record de las estructuras de las tablas
3.- llamada clase -> contiene la definicion de clases




UNIDAD DATO :
esta unidad contiene las conceciones a la base de datos y
su coneccion con las tablas

PRIMERA DUDA
Es en esta unidad donde defino los procedimiento y funsiones de
acceso a las tablas
Ejemplo :

> procedure Tdata.abreTabla;
> begin
> AdSpFamilia.Connection:=Coneccion;
> AdSpFamilia.TableName :='SUPERFAMILIA';
> AdSpFamilia.Open;
> end;

> Function Tdata.GetDato(AId: integer):boolean;
> var
> registro:boolean;
> begin
> with adSpFamilia do
> begin
> result:=Locate('sp_idsp',Aid,[]);
> end;
> end;


UNIDAD REGISTRO :
es aqui donde definio los diferente registros de las tablas ejemplo:
Type
_spFamilia = Record
sp_idsp :integer;
sp_desc :string;
end;
Type
_fmFamilia = Record
fm_idfm :integer;
fm_idsp :integer;
fm_desc :string;
end;
Type
_sbFmailia = Record
sbf_idsb :integer;
sbf_idfm :integer;
sbf_desc :string;
end;
Type
_pdtoProducto = Record
pdto_idpdto :integer;
pdto_idsb :integer;
pdto_desc :string;
pdto_marca :string;
pdto_tipo :string;
pdto_um :string;
pdto_stmi :integer;
pdto_stma :integer;
pdto_modelo :string;
pdto_serie :string;
end;

UNIDAD CLASES
Es aqui son donde defino las diferentes clases ejemplo:
type
Tsuperfamilia = class
private
data:Tdata;
Fdt :_spFamilia;
function carga:string;
public
constructor Create;
procedure actualzar;
property spid :integer read Fdt.sp_idsp write Fdt.sp_idsp;
property spesc :string read carga write Fdt.sp_desc;
end;


UNIDAD UNIT1
Unidad de forms

Ejemplo

procedure TForm1.FormCreate(Sender: TObject);
begin
spfamilia:=Tsuperfamilia.Create;
end;

Bueno mi gran duda es que si quisiera heredar si esta bien que en la unidad Dato Especifique los accesos a los datos o bien lo defino en cada clase para luego poder heredar...


Espero se comprenda esto
De antemando agradesco sus comentarios....
Saludos
Marco
Chile

[Faust]

Amigo Cacu...

Intenta nombrar mejor tus post, pues no se entiende que quieres, y utiliza las etiquetas de código Delphi, date una vuelta por la Guía de Estilo.

Saludos...

[cacu]

OOP-> Programacion Orientada a Obejtos
que es lo que intento hacer construyendo mis propias clases
Eso........

[roman]

Al igual que el compañero Faust, te recomiendo que leas la guía de estilo y utilices las etiquetas adecuadas. Supongo que te das cuenta que el código que pones no está indentado.

Además, te recomiendo intentar ser más claro en la exposición:

Empezado por cacu

Desarrollar una aplicacion que menje codigos usando como fuente de datos access.

¿Menje? ¿No será maneje? Y, ¿qué codigos? ¿Qué significa manejar códigos?

Luego pones una imagen que puede verse muy bien en tu disco duro, pero hay que subirla a algún lugar (como imageshack.us) para que los demás nos enteremos.

Mencionas tres unidades y pones cuatro. ¿Qué significa conceciones (sic) a la base de datos?

En fin, si tomas más tiempo y dedicación a la formulación de tu pregunta, seguro alguien podrá responderte.

// Saludos

[cacu]

Bien roman agradesco tu observacion....el tema planteado no se trata de un error ni nada que se paresca solo de experiencia en esta tecnica.......que yo no domino bien......y que no se necista mayor esfuerso por cuanto solo quien tenga esa experiencia podra darme un consejo....


Gracias

[cacu]

Primero que todo el nombre de este post tubo que haber sido "Dudas sobre el diseño en 3 capas".

Este modelo yo particularmete lo he visto de la siguiente manera de la forma de poder encapsular la progamacion y de paso aprender ha trabajar con clases

[[Al González]]

Hola Marco.

Hace catorce horas y tres mensajes más tuyos que publicaste el código del primer mensaje y todavía no lo has sangrado. ¿Alguna razón en particular para no haber modificado (sí, otra vez) ese mensaje?

[cacu]

Empezado por Al González

Hola Marco.

Hace catorce horas y tres mensajes más tuyos que publicaste el código del primer mensaje y todavía no lo has sangrado. ¿Alguna razón en particular para no haber modificado (sí, otra vez) ese mensaje?

Intentare hacerlo

[[Al González]]

Debes usar la etiqueta "Delphi" (la del Partenón de tres columnas).

[rgstuamigo]

Empezado por cacu

PRIMERA DUDA
Es en esta unidad donde defino los procedimiento y funsiones de
acceso a las tablas....

Pero cual es tu duda?

[cacu]

He pensado que le mejor titulo para este post es el de Aislar el Codigo.

Con el fin de poder aprender acerca del desarrollo de clases ..es que me propuse un ejemplo.

Este consistio en crear una simple aplicacion que pudiese manejar informacion relativa a una ferreteria que en este caso seria los codigos de producto.

Es asi como separe este codigo en 4 categorias..
Superfamilia-Familia-Subfamilia-Producto.

Con este enfoque creo mi base de datos conteniendo 4 tablas relacionas entre si.

Bien ahora es el turno de la aplicacion :

Dispongo de un DataModule en el cual agrego un componente de coneccion a la base de datos.

Habitualmente lo que hago es :
1.- poner el codigo necesario para verificar que exista la base de datos en el lugar que se supone de bede estar, una ves hecho esto(verdad) , pongo el codigo necesario para descubrir la ruta y abrir la coneccion, todo esto en el datamodule.

2.-en el form de la aplicacion pongo el codigo nesesario para trabajar con los datos ingresados y almacenarlos en las tablas que correspondan.

El tema esta en que estoy tratando de hacer que todo el codigo sea aislado del datamodule como de la aplicacion, de la siguiente manera

DataModule --->unidad de clase---->aplicacion

Donde en el
- DataModule : solo estan los componetes
- Unidad de Clase : pongo el codigo nesesario para la verificacion de la existencia de la base de datos , abrirla y ademas pongo el codigo necesario para almacenar los datos.
Todo esto creando clases .-
- Unidad del form : pongo el codigo de validacion de los datos...


Bueno de acuerdo a esto la duda seria :

En este sentido las clase ...deebrian solo servir para la validacion de las validacion de los datos.-

Deebria poner en el data modulo el codigo del manejo de los datos y solo usar las clases para el manejo de estas?????

Espero quese me pueda entender lo que intento hacer...si alguien a trabajado de esta menera le solicito que pudiesen orientarme...

Agradesco sus comentarios
Saludos

[rgstuamigo]

Bueno de acuerdo a esto la duda seria :

En este sentido las clase ...deebrian solo servir para la validacion de las validacion de los datos.-

Deebria poner en el data modulo el codigo del manejo de los datos y solo usar las clases para el manejo de estas?????

Espero quese me pueda entender lo que intento hacer...si alguien a trabajado de esta menera le solicito que pudiesen orientarme...

Agradesco sus comentarios
Saludos

Bueno actualmente estoy desarrollando un Sistema de Informacion que trabaja de acuerdo a las especificaciones de UML,el cual todavia estoy en desarrollo;Al empezar dicho sistema tuve muchas dudas de como implementarlo,ya que habia elegido a delphi para el desarrollo,aunque pude hacerlo en java,pero ya habia comenzado con delphi y tuve que seguir,al pasar algunos dias me di cuenta que la forma de trabajar en delphi no es muy adecuada a UML,como lo son otros lenguajes de programacion, y a veces en este foro tuve que postear muchas veces algunas dudas que tenia e incluso llegue hasta pelearme con algunos por aqui(mentira solo algunos debates)para poder entender algunas cosas.
Sobre tus dudas te diria que sigas lo que dice UML acerca de un sistema; pero para resumirte un poco UML nos dice que un sistema debe tener 3 capas ;al hacer un digrama de colaboracion de algun caso de uso te daras cuenta que la primera capa es la capa de datos,la segunda capa de negocio, la tercera capa de presentacion. Acontinuacionte explico algo de cada una:
*La capa de datos son clases encargadas de gestionar la conexion,insercion,actualizacion,etc de los datos con la base de datos.
Generalmente por cada tabla de tu base de dato tendras al menos una clase que se encargue de gestionar lo anteriomente dicho.generalmente estas clases se llaman "clase entidad".
*La capa de Negocio son clases tambien que utilizan objetos de las clases entidades para ejecutar cualquier accion hacia la base de datos,en mi caso es aqui lo que hago las validaciones antes de hacer alguna accion que pueda cambiar mi base de datos.En esta capa esta el negocio de la aplicacion y es como una intermediaria.Generalmente se llaman en UML "Clase Control".
*La capa de presentacion son clases interfas ,es decir son tus clases de tu formulario, donde el usuario se comunica con el sistema, estas clases utilizan a las clases controles.Ten en cuenta que la capa anterior es decir capa de negocio debe ser independiente de esta capa de presentacion en otras palabras por ejemplo no tienes que tener un metodo por ejemplo que llame o utilize digamos a un Edit especifico de algun formulario,pero tu diras ¿Por que?,pues por que que pasaria si por alguna razon en algun tiempo cambias de interfaz,tendrias problemas,en otras palabras es como construir un auto ,la capa de datos seria el motor del auto,la capa de negocio seria las piezas externas al motor como cables,enchufes,etc y la capa de presentacion seria la carcaza del auto, es decir la lata que cubre el auto de tal forma que si se quiere cambiar de caparazon por asi decirlo,tranquilamente se hace ya que el negocio no dependeria de la capa de presentacion.
Para profundizar mas podrias leer algun libro de UML 2.0.el tema es amplio.
Saludos...

[cacu]

Que puedo decir....Gracias....muy interesante tema..megustaria debatir mas estos temas........

Nuebamente Gracias...
Saludos

[rgstuamigo]

Empezado por cacu

Que puedo decir....Gracias....muy interesante tema..megustaria debatir mas estos temas........

Nuebamente Gracias...
Saludos

Asi es amigo cacu, a mi tambien me llamo mucho la atencion esta forma de trabajo ,en realidad lo aprendi en la Universidad con una docente mujer muy buena,la materia se llamaba "Sistema de Informacion" donde en el semestre debes presentar para poder aprobar,un Sistema de Informacion completo,ten en cuenta que un sistema de informacion no solo es el SoftWare sino la documentacion, hacer los diferentes diagramas de UML por cada Caso de Uso.Es muy cansador pero se aprende..
Lo que pasa que en delphi puedes hacerlo todo desde el formulario,comunicarte ala base de dato con algun componente directo desde el formulario,en realidad esta orientado a esta forma de trabajo,es decir no se sigue el consejo de UML, y aveces nos acostumbramos a trabajar asi;pero cuando haces un sistema grande te das cuenta que debes trabajar de una forma ordenada.Por cuestiones de mantenimiento y estandarizacion.

[[Delphius]]

Empezado por rgstuamigo

Bueno actualmente estoy desarrollando un Sistema de Informacion que trabaja de acuerdo a las especificaciones de UML,el cual todavia estoy en desarrollo;Al empezar dicho sistema tuve muchas dudas de como implementarlo,ya que habia elegido a delphi para el desarrollo,aunque pude hacerlo en java,pero ya habia comenzado con delphi y tuve que seguir,al pasar algunos dias me di cuenta que la forma de trabajar en delphi no es muy adecuada a UML,como lo son otros lenguajes de programacion, y a veces en este foro tuve que postear muchas veces algunas dudas que tenia e incluso llegue hasta pelearme con algunos por aqui(mentira solo algunos debates)para poder entender algunas cosas.
Sobre tus dudas te diria que sigas lo que dice UML acerca de un sistema; pero para resumirte un poco UML nos dice que un sistema debe tener 3 capas ;al hacer un digrama de colaboracion de algun caso de uso te daras cuenta que la primera capa es la capa de datos,la segunda capa de negocio, la tercera capa de presentacion. Acontinuacionte explico algo de cada una:
*La capa de datos son clases encargadas de gestionar la conexion,insercion,actualizacion,etc de los datos con la base de datos.
Generalmente por cada tabla de tu base de dato tendras al menos una clase que se encargue de gestionar lo anteriomente dicho.generalmente estas clases se llaman "clase entidad".
*La capa de Negocio son clases tambien que utilizan objetos de las clases entidades para ejecutar cualquier accion hacia la base de datos,en mi caso es aqui lo que hago las validaciones antes de hacer alguna accion que pueda cambiar mi base de datos.En esta capa esta el negocio de la aplicacion y es como una intermediaria.Generalmente se llaman en UML "Clase Control".
*La capa de presentacion son clases interfas ,es decir son tus clases de tu formulario, donde el usuario se comunica con el sistema, estas clases utilizan a las clases controles.Ten en cuenta que la capa anterior es decir capa de negocio debe ser independiente de esta capa de presentacion en otras palabras por ejemplo no tienes que tener un metodo por ejemplo que llame o utilize digamos a un Edit especifico de algun formulario,pero tu diras ¿Por que?,pues por que que pasaria si por alguna razon en algun tiempo cambias de interfaz,tendrias problemas,en otras palabras es como construir un auto ,la capa de datos seria el motor del auto,la capa de negocio seria las piezas externas al motor como cables,enchufes,etc y la capa de presentacion seria la carcaza del auto, es decir la lata que cubre el auto de tal forma que si se quiere cambiar de caparazon por asi decirlo,tranquilamente se hace ya que el negocio no dependeria de la capa de presentacion.
Para profundizar mas podrias leer algun libro de UML 2.0.el tema es amplio.
Saludos...

Hola rgstuamigo, fíjate que no sabía que UML propone capas. ¿Seguro que UML propone eso?

Porque que yo sepa el estudio del modelo de 3 capas, o de 3 niveles como le suelen llamar algunos, corresponde más a un apartado de la "teoría" OO y no al estándar del lenguaje unificado.

Cuanto mucho podríamos estar hablando del uso del patrón Capas (Layers), pero aún así el estudio escapa a lo que propone UML.

UML sólo ofrece diagramas. Que los patrones, discusiones y/o cualquier documento que trate sobre OO se apoyen en el uso de UML para exponer sus ideas es una cosa pero de allí a que en UML todo se organiza en tres capas me parece un error conceptual.

No es que pretenda traer problemas ni discutir, pero a mi modo de ver es necesario hacer esa aclaración.

Tal vez estoy equivocado, pero debo decir que en ningún lado he leído que UML propone capas.

Craig Larmman en su libro UML y Patrones expone, no de forma exaustiva, pero si con los suficientes detalles sobre el patrón Layers. Recomiendo su lectura. Aquí y aquí hay otro poco sobre el tema, por si interesa.

En parte estoy de acuerdo con que Delphi tal vez se no ajuste totalmente a algunos diseños de UML, como ser por ejemplo los paquetes (recuerdo, que en una ocasión preguntabas y comparabas el uso de las unidades con los paquetes den Java).

Pero he aquí que es un error en hacer que el lenguaje se adapte a UML. Se supone que UML debe ser independiente del lenguaje. A mi modo de ver UML ya ofrece bastante diagramas, y creo que una buena cantidad de ellos se pueden usar con bastante comodidad "en Delphi".

La idea de los tantos diagramas de UML es ofrecer vistas parciales, está en uno en saber y aprender elegir cuando, y que diagramas son útiles. Diagramar por diagramar no es la solución.

Saludos,

[rgstuamigo]

Empezado por Delphius

Hola rgstuamigo, fíjate que no sabía que UML propone capas. ¿Seguro que UML propone eso?....

Hola Delphius, lo que trate de explicar al amigo cacu es que UML nos dice todos los pasos que se debe tener en cuenta para el desarollo de software;cuando me referi a que UML propone capas en realidad es que UML no lo dice asi directamente como yo lo dije, pero en realidad lo ilustra es decir por ejemplo cuando haces el diagrama de colaboracion de algun caso de uso,te daras cuenta que existen 3 niveles o capas para desarrollar ese caso de uso especifico(Una clase interfaz enganchada hacia una clase control que a su ves utiliza la clase entidad).Eso me quiere decir que debo organizar mi aplicacion en esas tres partes o capas.A parte de eso te das cuenta cuando haces el analisis de arquitectura del sistema,analisis de paquetes,etc. es lo que nos dice el PUDS."Dirigido por caso de uso","Centrado en la arquitectura"e "Iterativo e incremental".En realidad UML no solamente se usa en desarrollo de sotfware,tambien se utiliza en otras areas de una empresa,como ser atencion al cliente,en la planificacion del trabajo,etc,etc de ahi que es un standar.
Espero haber aclarado....
Saludos...

[[Delphius]]

Empezado por rgstuamigo

Hola Delphius, lo que trate de explicar al amigo cacu es que UML nos dice todos los pasos que se debe tener en cuenta para el desarollo de software;

No es por ser pesado pero tampoco indica los pasos.
Repito y sostengo, el estandar UML sólo se limita a brindar un lenguaje visual de vistas parciales.

Los pasos tampoco responden al paradigma o ciclo de vida de desarrollo optado, inclusive. Es cierto que cada ciclo de vida propone ciertas actividades, más de allí en realidad los pasos que uno aplica en el desarrollo de software provienen de las actividades estructurales (siguiendo los términos que propone Pressman, Capítulo 3 en la 4ta Edición) que uno establece y/o determina siguiendo algunos criterios o factores que considere adecuados para el proyecto. (1)

(1) Si quieres ser bien metódico y seguir lo que propone Pressman, deberías leer lo que habla sobre grado de rigor, cálculo del valor de selector, SCT, conjunto de tareas (Capítulo 7, en la 4ta Edición. Ingeniería de Software. Un enfoque práctico).

En resumen concretamente las actividades y los pasos nacen de la experiencia de uno. Los paradigmas de proyectos de desarrollo, ya sea secuencial, prototipado, espiral, USDP/RUP/UP, etc no dicen los pasos. Proponen un marco de trabajo en los cuales uno puede asentar sus propias actividades... de allí salen los verdaderos pasos. Para hacerlo corto, los paradigmas son simples ideas, filosofías, modelos. Si te fijas bien lo que proponen es un modo de organizar y avanzar con nuestro proyecto. Más en ningún momento te van a decir que pasos seguir puesto que esto surge de la propia naturaleza del proyecto, de tu experiencia, de tu intuición.

Tal vez lo que tu quieres decir es que UML nos ayuda y nos asiste a saber como conducir esos pasos. Eso si es distinto.

Empezado por rgstuamigo

cuando me referi a que UML propone capas en realidad es que UML no lo dice asi directamente como yo lo dije, pero en realidad la ilustra es decir por ejemplo cuando haces el diagrama de colaboracion de algun caso de uso,te daras cuenta que existen 3 niveles o capas para desarrollar ese caso de uso especifico(Una clase interfaz enganchada hacia una clase control que a su ves utiliza la clase entidad).

Ummm yo todavía no estoy bien enchufado con UML 2.0 te agradecería que me brindes más información sobre clase interfaz, clase control y clase entidad.
Tengo entendido que el diagrama de interacción se divide en (UML 1.1) diagrama de secuencia y diagrama de colaboración. Con la llegada de 1.5 si no me equivoco (o 2.0) se añadieron otros más: de comunicación, de tiempos y diagrama global de interacciones o de vista interacción.
Con la bibliografía que yo he estudiado, no se menciona a ninguna de esas clases... o yo estoy confiendo el diagrama de colaboración que conozco con algún otro....
Que yo sepa el diagrama de colaboración a diferencia del DDS o Diagrama De Secuencia se caracteriza por la ausencia de una "linealidad" o secuencia exacta de las interacciones. No se ve visualmente el "orden" de los mensajes entre los objetos ya que se ordenan en forma "grafo" o "red", pero si es válido, para mi muy recomendable, el incluir las etiquetas de numeración de los mensajes.
En este punto por ello para debatir adecuadamente, mi pregunta es ¿qué es clase interfaz, control y entidad?

Empezado por rgstuamigo

Eso me quiere decir que debo organizar mi aplicacion en esas tres partes o capas.A parte de eso te das cuenta cuando haces el analisis de arquitectura del sistema,analisis de paquetes,etc. es lo que nos dice el PUDS."Dirigido por caso de uso","Centrado en la arquitectura"e "Iterativo e incremental".

Ummm, aqui debería incluir lo que dije al principio

Empezado por rgstuamigo

En realidad UML no solamente se usa en desarrollo de sotfware,tambien se utiliza en otras areas de una empresa,como ser atencion al cliente,en la planificacion del trabajo,etc,etc de ahi que es un standar.
Espero haber aclarado....
Saludos...

Coincido contigo en que UML se usa en otras áreas; ofrece una amplia variedad de diagramas y puede ser empleado en muchos lados. Por ejemplo es común encontrarse con pseudo-diagramas de actividades en auditorías para reflejar como se realizan las tareas o actividades de un sector, o departamento, e incluso como se vinculan entre los departamentos.

Es un estándar claro está, pero como estándar espero que comprendas que nunca te va a imponer o decir que hagas esto, y luego esto, o que esto deba ser así y esto asá puesto que va en contra de lo que uno espera. Uno debe hacer lo que debe hacer. Es más, para que te hagas una idea... casi todas las "etiquetas" que propone son opcionales, uno puede ocultar y mostrar detalles a gusto y conveniencia... puede agregarle etiquetas "personalizadas"... Es legal... es lo lindo de UML: que uno puede ajustar, dentro de lo razonable, un diagrama según su necesidad. Asi que en pocas: diseña a tu necesidad, según lo que te ofrece UML, pero recuerda que no estás obligado al pie de la letra todo lo que dice.

El estandar existe no porque sea muy bueno y sea "sinónimo de calidad" y orden... existe porque nos ayuda a comunicar y transmitir ideas de forma transaparente e independiente de tecnologías, de procesos, de modelos a otras personas. Es bueno seguir lo mejor que se pueda el estándar, pero este es dinámico y flexible.

rgstuamigo, esto no lo digo por atacarte, ni por demostrarte quien tiene razón... Yo no creo tenerla, pero creo que me pareció (y me parece) que es mejor ser bien correctos en esto porque vamos a confundir a cualquier persona que se acerque a este hilo.
Yo di mi opinión personal y en como interpreto lo que llevo ya unos años de estar estudiando y de constante lectura. De hecho, estoy releyendo a Pressman, y de vez en cuando releo a Larmman (UML y Patrones). Me encantaría releer a Yourdon pero no tengo su libro.

Y esto no lo hago porque dude, sino porque considero volver a mis bases para saber que puedo mejorar, que se puede reaprender, que se puede debatir...
No sigo totalmente los conceptos de éstos autores pero reconozco que sus libros son una fuente de inagotable y renovado conocimientos. A como interpreto las cosas ellos brindan un norte, en como uno adapte y lleve a cabo el camino hacia ese norte eso ya es cuestión de uno.
Yo considero que ellos ofrecen cierto tinte teórico, la práctica queda en uno. Y considero que el conocimiento se hace de la búsqueda, del debate de las verdades a medias que tengamos cada uno.

Saludos,

[rgstuamigo]

Empezado por Delphius

No es por ser pesado pero tampoco indica los pasos.
Repito y sostengo, el estandar UML sólo se limita a brindar un lenguaje visual de vistas parciales.

Me parece que quisas estamos confundiendo algunos terminos,claro que por supuesto UML nos indica los pasos, estonces ¿para que fue creado?
para leerlo solamente y no aplicarlo.esto seria entonces una perdida de tiempo. desde luego que UML no me va decir cada pasito asi detalladamente de lo que debo hacer en el proceso de creacion de algun software,como tu lo dices nos da todas las pautas,etc,sobre los cuales poder trabajar para hacer un software de calidad.

Empezado por Delphius

En resumen concretamente las actividades y los pasos nacen de la experiencia de uno. Los paradigmas de proyectos de desarrollo, ya sea secuencial, prototipado, espiral, USDP/RUP/UP, etc no dicen los pasos.

Creo que en eso no estoy de acuerdo contigo,desde luego que la experiencia vale,pero no debes confiar todo en lo que as podido aprender,todo apunta a que vivimos en un mundo lleno de cambio y si se ha aprendido algo en el pasado,quisas en la actualidad sea necesario actualizarse, y aparte de eso siempre se sigue alguna norma o regla para fabricar cualquiercosa siguiendo los estandares.Y es exactamente en esto que nos ayuda UML.

Empezado por Delphius

Ummm yo todavía no estoy bien enchufado con UML 2.0 te agradecería que me brindes más información sobre clase interfaz, clase control y clase entidad.

En internet vas a pillar muchas referencias al respecto especialmente si se trabaja siguiendo el Proceso Unificado de Desarrollo(PUDS).

Empezado por Delphius

Que yo sepa el diagrama de colaboración a diferencia del DDS o Diagrama De Secuencia se caracteriza por la ausencia de una "linealidad" o secuencia exacta de las interacciones. No se ve visualmente el "orden" de los mensajes entre los objetos ya que se ordenan en forma "grafo" o "red", pero si es válido, para mi muy recomendable, el incluir las etiquetas de numeración de los mensajes.

Puede ser que talves tú al Diagrama de colaboracion lo has trabajado de una forma standar,pero si lo trabajaras aplicado al desarrollo de software los cuadrito o red que tu lo llamas deben ser mas especificos.
quisas te ilustre esta imagen:
http://www.cuelgalo.com/viewer.php?i...8_Ejemplo1.JPG
Saludos....

[nuk3zito]

Empezado por Delphius

Es un estándar claro está, pero como estándar espero que comprendas que nunca te va a imponer o decir que hagas esto, y luego esto, o que esto deba ser así y esto asá puesto que va en contra de lo que uno espera.

Empezado por Delphius

... diseña a tu necesidad, según lo que te ofrece UML, pero recuerda que no estás obligado al pie de la letra todo lo que dice.

Empezado por Delphius

... No sigo totalmente los conceptos de éstos autores pero reconozco que sus libros son una fuente de inagotable y renovado conocimientos. A como interpreto las cosas ellos brindan un norte, en como uno adapte y lleve a cabo el camino hacia ese norte eso ya es cuestión de uno.
Yo considero que ellos ofrecen cierto tinte teórico, la práctica queda en uno.

Creo que con esto está todo claro a lo que se refiere Delphius y no es necesario hacer debate. Todo aquí depende de como uno aplique la teoría o metodología.

Saludos.

[[Delphius]]

Hola,

Para no desviar más el hilo, he continuado la discusión aquí.

Saludos,