Dudas sobre el diseño en 3 capas

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

[rgstuamigo]

Empezado por Delphius

Hola,

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

Saludos,

Ya respondi en ese hilo.
Y creo que doy por finalizado este Hilo.