C.A.R. Hoare escribió:Hay dos maneras de construir un diseño de software: una es hacerlo tan
simple que obviamente no tenga deficiencias, y la otra es hacerlo tan complicado
que no tenga deficiencias obvias.

Muy interesante para todos los que estudian Sistemas. Más que el blog, lo importante es la traducción de un artículo al final.

http://blog.smaldone.com.ar/2006/11/17/ ... -no-sirve/

Saludos

PD: Hay varios comentarios interesantes abajo del artículo, recomiendo que los lean también si tienen tiempo.

Buenisimo el articulo!. Estoy de acuerdo con muchas de las cosas que estan ahi, pero me quedo con esto:

Si UML se ocupara de la implementación, debería ocuparse de cuestiones relacionadas con el software; lo bueno de las burbujas y flechas, en oposición a los programas, es que nunca se cuelgan.

Entiendo la postura pero no la comparto para nada...

Si vas a prenderle velas a un diagrama de clases y te vas a hacer fundamentalista del UML, logicamente no sirve... ahora, si lo usas como una HERRAMIENTA mas y que te sirve para cosas puntuales y para modelar una cierta cantidad de cosas esta bastante bueno... en mi laburo hemos hecho reuniones usando "diagramas de clases con secuencia" donde mezclamos todo, pero nos sirvio para analizar un problema complejo y que todo el equipo lo entienda.

Cada uno sabra si sirve o no cuando lo use lo suficiente... el problema es que mucha gente confunde UML con "tengo que hacer 100 hojas de documentacion y no tengo ganas"

Escucho mas opiniones!

Cita:Si vas a prenderle velas a un diagrama de clases y te vas a hacer fundamentalista del UML, logicamente no sirve... ahora, si lo usas como una HERRAMIENTA mas y que te sirve para cosas puntuales y para modelar una cierta cantidad de cosas esta bastante bueno... en mi laburo hemos hecho reuniones usando "diagramas de clases con secuencia" donde mezclamos todo, pero nos sirvio para analizar un problema complejo y que todo el equipo lo entienda.

Cada uno sabra si sirve o no cuando lo use lo suficiente... el problema es que mucha gente confunde UML con "tengo que hacer 100 hojas de documentacion y no tengo ganas" :P

En los comentarios del blog se discute precisamente eso.

En mi opinión el problema está en la integración de todo el UML como una herramienta monolítica, tratando de crear un equivalente a "planos de un edificio". No por eso hay que dejar de usar los diagramas de clases o los diagramas de casos de uso, que son bastante útiles.

Dem0 escribió:

Cita:Si vas a prenderle velas a un diagrama de clases y te vas a hacer fundamentalista del UML, logicamente no sirve... ahora, si lo usas como una HERRAMIENTA mas y que te sirve para cosas puntuales y para modelar una cierta cantidad de cosas esta bastante bueno... en mi laburo hemos hecho reuniones usando "diagramas de clases con secuencia" donde mezclamos todo, pero nos sirvio para analizar un problema complejo y que todo el equipo lo entienda.

Cada uno sabra si sirve o no cuando lo use lo suficiente... el problema es que mucha gente confunde UML con "tengo que hacer 100 hojas de documentacion y no tengo ganas" :P

En los comentarios del blog se discute precisamente eso.

En mi opinión el problema está en la integración de todo el UML como una herramienta monolítica, tratando de crear un equivalente a "planos de un edificio". No por eso hay que dejar de usar los diagramas de clases o los diagramas de casos de uso, que son bastante útiles.

Sisisi lei el articulo completo, pero los titulos de Javier Smaldone suelen ser un poco amarillistas...

Ej: "Ajax no es Ajax", donde arranca diciendo

Cita:AJAX es simplemente una técnica, o mejor dicho, la combinación de varias técnicas. Si bien su nombre significa “JavaScript y XML asincrónicos“, no tiene necesariamente que ver con Javascript ni con XML. De ahí el título de este artículo.

y finaliza con:

Cita:Esto que hemos visto es AJAX. Si bien hemos utilizado JavaScript para realizar el requerimiento “asincrónico”, podríamos haber usado cualquier tecnología “client-side” (VBScript, JScript, etc.).

Que se yo... a mi personalmente no me gusta como escribe el tipo, y creo que el mundo blog da para todo, y se sobredimensiona lo que dice un tipo que escribio una opinion suya... y para leer alguien escribiendo con soberbia prefiero que sea Fowler :P (http://martinfowler.com/)

Saludos gente!!!

Por ahí es complicado aplicar UML en su todo, justamente porque requiere mucha documentación, mucho papel, y para eso se requieren dos factores importantes: ganas, y tiempo. Y sabemos que actualmente no contamos con el último en el ámbito de los sistemas.

No obstante, las ideas están buenas, y se utilizan partes. No se olviden que UML es un lenguaje, que debe estar acompañado de un proceso de desarrollo. Y no tiene por qué se el único lenguaje que se utiliza.

En mi poca experiencia me da la sensación de que la mayoría utilizan los diagramas básicos, como clases o casos de uso. Y deben ser muy pocos los que usan, por ejemplo, un diagrama de despliegue.
Y también hay muchos que utilizan muchas cosas de UML sin saber que lo hacen, como definir los roles y las tareas, por ejemplo.

Los diagramas de despliegue son útiles, pero lógicamente son mucho menos utilizados que los más básicos.

UML rocks, aunque haya gente a la que no le guste. Si no le gusta a alguien, que no lo use, a mí y a mucha gente más le sirve, y no porque me lo hayan vendido.

Desde el vamos, se entiende que "algo" tiene servir porque si no ya se hubiera ganado mucha mala fama hace tiempo.
Capaz lo que se puede cuestionar es "¿podría ser mejor?", "¿podría ser más simple?".
Supongo que sí, como todo. Además, sistemas es un área que todavía está dando su primeros pasos, así que seguramente los modos de documentar los sistemas mejoren.
De todas formas, nunca lo usé formalmente en lo laboral para tener una posición madura al respecto.

Lo que mas rescato de UML, son algunos diagramas, como el de clases y el de casos de uso. Este ultimo, es buenisimo para interactuar con el cliente.

No sirve, por que hace parte de la teoría de sistemas, que nunca se provó que haya funcionado alguna vez. UML, teoría de sistemas, teoría de organizaciones y demás, fueron "metodologías" y cosas hechas por empresas, que en un momento dado, facturaron con la idea. Toooodo eso que se enseña y vemos en la facultad, carece de transfondo científico... La parte científica de la solución de los problemas se encuentra en la "computer science". La única cosa que es ciencia. Todo lo relacionado a las organizaciones y la teoría de sistemas, son "teorías" que nunca se pudieron demostrar que funcionaran. Se enseñan y utilizan sus marcos teóricos, pero nunca nadie provó que el UML (por ejemplo) sirviera para algo. Uno puede hacer el mismo software con o sin el UML... En definitiva no es "nada"... Bah... Ni siquiera se provó que sirva como herramienta...

ciomar escribió:Ni siquiera se provó que sirva como herramienta...

Mentira, ya en este thread tenés varios contra-ejemplos en los cuales UML sirvío como herramienta. :P

Que sirva solamente para comunicar y documentar es otra cosa.

Justo hablando de este tema, en Habilitación encontramos un documento modelo para especificación, basado en UML.
El modelo está hecho por la cátedra para la cursada del 2004. O sea que te obligaban a utilizar UML al parecer.
Al parecer en la facu le dan mucha atención.
Peguen una mirada en http://materias.frba.utn.edu.ar/habilitacion/