Saludos, feliz navidad.
Santiago.

Se necesita un lenguaje de modelo especifico, yo creo que tendria que ser algo recursivo para que funcione bien, desde el entendimiento de los procesos, hasta llegar al codigo.

Creo que un diagrama de clases en UML (sin querer detallar mucho) es útil, pero de nuevo, solo para dar una idea muy básica del diseño. Para detallar es mejor dejar el diagrama básico y usar algún otro método para hacerlo.

Los demás diagramas pueden ser útiles pero creo que hay que usarlos con cuidado por que después pueden terminar causando mas problemas que soluciones.

Usar cursiva para definir un método o clase abstracta me parece algo totalmente incomprensible, no entiendo como no se dieron cuenta que NO SE NOTA!, el único que sabe que un método es abstracto es el que hizo el diseño o alguien con una agudeza visual realmente envidiable.

Querer especificar “genericidad” (clases templates en c++ si no me equivoco) no está muy bien hecho.

La carta del alumno me parece genial!, gracias por la traducción.

Saludos.

Conseguí un libro excelente, que explica los diagramas de clases, se llama: PROGRAMACIÓN ORIENTADA A OBJETOS PARA PHP5 por Enrique Place
Este libro está también que me dió esperanzas de nuevo para entender UML.

Pero los demás libros y ejemplos son puro texto y texto, que termina mareando y en definitiva: Si es complicado, no es bueno, así de fácil, así de simple.

Un cordial saludo.

P.D.: Si alguien tiene información sobre un ejercicio completo se lo agradecería mucho.

Un saludo

Desde mi punto de vista el problema radica en que no es fácil encontrar libros, profesores o colegas que expliquen de manera sencilla y práctica cómo usar UML de manera efectiva dentro de un proceso de desarrollo dado.

Empecemos por entender lo básico. UML es simplemente una forma estandarizada de documentar un sistema. Es una herramienta que puedes usar o no. Y que la uses o no, no implica que tu sistema será mejor o peor, como no puede ser mejor o peor tu programa si colocas comentarios en el código. Por ello, no tiene sentido pedirle a UML que ofrezca mayor robustez, flexibilidad y demás características deseables de un sistema moderno. ¿Esperaríamos que por el hecho de crear un buen archivo de ayuda para el usuario final, nuestro sistema fuera más flexible, robusto, etc?

UML se creó con la idea básica de poder contar con una forma estándar de comunicar ideas. Punto. Cuando hablamos con nuestros colegas sobre el programa que estamos haciendo solemos hacer dibujos en una hoja para hacernos entender. UML es una forma más formal de hacer estos dibujos. Si tú dibujas las clases como triángulos y yo las dibujo como rectángulos no nos vamos a entender fácilmente. Pongámonos de acuerdo. Eso es UML.

El problema de UML empieza con el gran número de artefactos que a cualquier principiante puede abrumar. Pero como bien lo dicen los mismos creadores, la gran mayoría de proyectos se pueden documentar fácilmente sólo con el 20% de todos los artefactos de UML. (Lo malo fue que nunca nos dijeron cuál era ese 20%).

Y aquí es donde empieza el problema del uso efectivo del UML. Como todo lenguaje, UML tiene una gramática (una estructura del lenguaje) y un vocabulario (cómo se nombran las cosas). Por lo general los libros, profesores, seminarios y cursos, explican con detalle estos dos aspectos. Y nos abruman con diagramas, símbolos, flechas, etc. Pero muy raramente encuentra uno quien explique cómo usar toda esa gramática y ese vocabulario en un proyecto real y de manera efectiva. Ese es otro cuento.

Para mi ha sido un proceso doloroso, no lo niego, pero no es por culpa de UML, sino por el mal enfoque de quiénes lo explican. Una vez que entiendes cómo usarlo se te hace difícil crear un sistema complejo sin apoyarte en UML.

UML es una herramienta de apoyo en el proceso de desarrollo, pero como toda herramienta, si es mal usada puede terminar siendo un verdadero lastre. Lo ideal, es poder usar UML junto con una metodología de desarrollo que se adapte a la forma de trabajo del equipo de desarrollo.

Ahora bien, no existe una única metodología que funcione bien con UML. Cada equipo termina adaptando la que le parece más adecuada a su forma de trabajar.

Es importante tener en cuenta que la ingeniería del software es una disciplina muy joven, si la comparamos con la ingeniería civil, química o eléctrica por ejemplo. Estas últimas llevan cientos de años, incluso miles de años de evolución. Nuestra profesión ni siquiera ha alcanzado sus primeros cien años. Por ello, todavía hay mucho en qué mejorar. UML sólo ha sido el primer intento por estandarizar la documentación de un sistema, y sigue evolucionando. Se crean herramientas software que día a día facilitan más su uso efectivo. Y es de esperar que un futuro no lejano, gracias a estas herramientas, UML pueda mostrarse en toda su potencia y utilidad práctica.

Gracias,

Nadie dijo que era para software, de hecho, se puede modelar todo lo modelable con el, hasta el cuerpo humano, un coche, la evolucion humana, una casa, etc….

Solo ese detalle queria dejar expresado,

Muy buen articulo, se nota el esmero al escribir y compartir con todos tu punto de vista!

Saludos

la naturaleza del proyecto es un planteamiento que da el cliente,él cliente no la sabe, pero el señor ingeniero de sistemas sí al momento de entrevistar o hablar con el cliente ..etc.

en mi opinion UML sirve y de mucho, de hecho alguna logica de software se ve nesesaria para el planteamiento y desarrollo de sistemas pequeños o complejos.
el uso de UML se ve nesesario para entender la logica del negocio, de sistemas junto con los diagramas de casos de uso…..

por mi experiencia es necesario crear diagrama UML para el desarrollo de sistemas no importando su naturaleza ni que tan complejo pueda ser.

Este tipo de discusión ayuda sobretodo al principiante (como yo). Los viejos zorros en esto ya saben como es el cuento, pero nosotros no y necesitamos este tipo de información para saber la realidad de esto EN LA PRACTICA.

a mi particularmente me fue muy útil leer esto.

aún así no es bueno aceptar algo sólo porque lo escuchamos (o leemos) de otro. Hay que investigar por uno mismo.

Saludos.

Pd. Leeré acerca de Diseño por contratos, me parece interesante.

Gracias por compartir sus comentarios