212 meneos
2191 clics
UML será eliminado de Microsoft Visual Studio [ENG]
La compañía elimina el soporte de UML en Visual Studio 15 debido a su poco uso. Object Management Group, la cual gestiona UML, declinó comentar las acciones de Microsoft.
|
comentarios cerrados
UML es la especificación formal del dibujo que muchos desarrolladores ya hacíamos en papel con bolitas cuadraditos y flechas antes de que existiese. Que eran dibujos para dar soporte rápido a ideas y formas de explicar diagramas y/o flujos de informacion. Pero eso no era ni es UML. Eran diagramas y bolitas.
Las cosas no son útiles de por sí. Solo son útiles si su empleo es productivo y útil.
25 años de profesión. Ingeniero informática. No he visto nunca un documento UML actualizado respecto a la versión actual del software.
UML lo usan los malllamados consultores - la mayoría ni puta idea de informática a nivel útil porque apenas han desarrollado uno o 3 años antes de ponerse la corbata.
UML sirve para que dichos consultores y algún jefe de proyecto que piensa que sabe mucho hagan un montón de diagramas para hacer ver que su trabajo es útil. Trabajo que nunca se actualiza y queda guardado en el cajón como la reliquia de la &qu…...
Al rato volvió cabreado con la semicarpeta. "¡¿Pero qué es esto?! Sólo son folios en blanco", me espetó. "Es la documentación existente del módulo. ¿No es lo que buscabas?". Y toda la sala explotó en carcajadas.
Porque que reir esa tontería tiene delito.
www.google.com.ar/#q=uml+software+open+source
PD: como anécdota, hace relativamente poco nos obligaron a sacar la documentación que habíamos tenido que meter en el repo, así que esperemos que llegue con los comentarios en el código
Lo dudo
Sólo el hecho de tener que ir a otra herramienta externa al ide es ya una pérdida de tiempo.
Te estoy hablando de mi caso, a lo mejor crees que estás respondiendo a otro usuario
Pegate una vuelta por estos links:
stackoverflow.com/questions/15376/whats-the-best-uml-diagramming-tool
en.wikipedia.org/wiki/List_of_Unified_Modeling_Language_tools
Te doy la razón que aquellas cosas con cambios constantes cualquier diagrama se pudre rapidísimamente, pero cuando algo se estabiliza, sería deseable un diagrama.
Otra cosa es que nunca se haga. Pero cuando eso mismo tengas que mirarlo un año después, agradecerás tu propio diagrama.
Asi funcionan proyectos de software libre con millones de líneas de código y miles de desarrolladores, no hay diagramas pero todos pueden saber fácilmente que hace cada cosa, si algo no se adapta dicho framework y estilo no se acepta y punto.
Ahora sí, a nivel medio amateur, cuando cada uno programa como le da la gana, se hace una cagada encima de otra y el diseño se complica cada vez más, pues en ese caso hay dos opciones: hacerlo todo nuevo o hacer unos diagramas de la ostia para seguir tirando.
No deberías asumir que todos tienen una memoria increíble y una comprensión apabullante como la tuya (lo digo porque considero que para no hacer nada en papel hay que tener memoria increíble y comprensión apabullante). A mi edad la memoria no es tan eficiente.
Pues eso: no todos son como tú, y no significa que seamos inservibles. ¿Tú no necesitas diagramas? Guay por ti. Otros sí que los necesitamos.
Y mis compañeros de trabajo, jóvenes ellos recién saliditos de FP, todavía tiernos, se acuerdan de las issues en las que han estado y qué líneas de código han escrito. Otros no tenemos ya energía de tantos años acordándonos de basura que al final más vale olvidar porque es absurdo acordarse de esas cosas.
Por supuesto que agradezco los patrones y consistencia en el estilo de código: el día que tengo que leerlo es mucho más fácil. Pero el primer día que me enfrento con algo, prefiero ver de un vistazo qué cosas hay, qué relaciones hay entre ellos.
Y de software libre dices que no se complica porque se hace todo de nuevo (ya que hablas de no hacer diagramas)? Pues no has visto el código de Nutch
Uml es demasiado formal, demasiado verboso y demasiado lento, no es mejor que un párrafo y un mini diagrama informal hecho en 5 min, por eso ya no se usa.
¿Métricas y cosas de esas? No, yo no hablo de eso. Pero puedo asegurarte que un buen diagrama ahorra muchos dolores de cabeza.
Por definición UML no es "demasiado formal", puesto que está creado para ser personalizable. Tampoco tiene que ser "demasiado verboso", y si lo es, seguramente está mal porque debería descomponerse en diferentes vistas en función de la necesidad y lo que se quiera explicar. Y ¿lento? eso no sé ni lo que significa, aunque si te refieres a que hay que invertir tiempo, es tiempo que luego redunda positivamente en tener menos errores y tardar menos.
Cualquier "mini diagrama informal hecho en 5 minutos" seguro que es inservible. A mí hacer un diagrama me puede llevar fácilmente 30 minutos, y después lo uso un montón de veces.
O compañeros de trabajo que se tiran 4 horas (contadas) haciendo cerdadas, y cuando ya no pueden más porque las cosas no funcionan, me llaman, hago mi diagrama con el que se detectan todas las cerdadas mal hechas, y se ven cómo han de estar bien, y se soluciona en 45 minutos (y porque no reutilizan el diagrama porque no le hacen ni puto caso, que si no...).
No digo que tú tengas que usarlo, pero de ahí a borrarlo de la faz de la tierra hay un largo trecho.
El UML es una basura, los patrones de diseño son una cosa fantástica y yo me cago en los profesores de la ingeniería superior que me obligaron a perder tiempo haciendo dibujitos de mierda pero que en programación orientada a objetos se quedaron en chorradas básicas tipo "la clase triángulo hereda la clase figura..."
UML tiene demasiada morralla. Con herramientas de diseño genéricas ya va bien. Si de todas maneras el 90% de la documentación usable son tablas, texto, ejemplos, comentarios y demás. De todas maneras el uso real de UML no justifica la integración con Visual Studio.
De hecho la herramienta con la herramienta de #7 sobra y todo.
Yo creo que no he hecho más que los que están aquí yuml.me, y la verdad la mayoría de los que he usado los podía haber hecho con Paint y power point en poco tiemp
Y de hecho hay herramientas donde la realización del diagrama se hace automática, como graphviz.
El libro de Gang of Four hay gente que lo clasifica como "veneno para el cerebro" (Mario Fusco por ejemplo), y el problema es que se sigue explicando en las facultades sin razonar por qué son realmente necesarios los patrones de diseño (de OO).
#3, como documentación está bien en proyectos pequeños/medianos/grandes/supergrandes/ultragrandes/megagrandes/teragrandes ... pero sobre todo está muy bien que cuando cambian las personas del equipo de trabajo que mantiene un software exista un documento o varios donde que se expliquen como funciona ese software y si quieres meter UML en el documento, pues fale vale y para mi el word/writer/page/notepad/notepad++/sublime ... cumplen muy bien este cometido.
Tu comentario es irónico ¿verdad?
Object composition es el futuro.
Por eso el software libre tiene tan buena calidad en comparación. Porque se hace sin presiones y con la intención de hacer algo bien hecho, no algo para vender el mes que viene.
Ahora mismo con la tendencia a microtareas no se prima un tiempo dedicado a documentación por 2 motivos:
i. El cliente no quiere asumir un coste de que el programador se dedique a documentar correctamente lo que hace.
ii. Tu jefe solo te exigirá el tiempo aprobado por el cliente. Ya a veces se va justo con el tema de pruebas pues ya no te digo cosas como hacer documentos.
Ojala fuera tan fácil, y si lo has conseguido te doy mi enhorabuena.
Ese es el momento de atacar!
Donde trabajo se ha pasado de proyectos de una duración X a proyectos compuestos de microtareas y donde tienes que justificar el tiempo empleado. Todo a petición del cliente.
Antes era asumible dedicar tiempo a documentación o seguimiento propio de bugs u otras tareas menores, ya que había huecos libres para ello. Ahora parece esto un trabajo de fontaneros, te pago X por un tiempo y si te pasas de ahí que salga gratis.
UML es un lenguaje que entendemos todos y para explicar un desarrollo compartido es la mejor idea.
Con metodología ágil lo que no puedes es tirarte 7 días haciendo un UML.
Y los test igual. Si no hay tiempo para hacerlos y luego hay bugs que con ellos serían más fácil de identificar y arreglar no es mi problema y cobro por horas. No voy a trabajar gratis por hacer las cosas mejor básicamente porque no tengo tiempo infinito tampoco
UML es la especificación formal del dibujo que muchos desarrolladores ya hacíamos en papel con bolitas cuadraditos y flechas antes de que existiese. Que eran dibujos para dar soporte rápido a ideas y formas de explicar diagramas y/o flujos de informacion. Pero eso no era ni es UML. Eran diagramas y bolitas.
Las cosas no son útiles de por sí. Solo son útiles si su empleo es productivo y útil.
25 años de profesión. Ingeniero informática. No he visto nunca un documento UML actualizado respecto a la versión actual del software.
UML lo usan los malllamados consultores - la mayoría ni puta idea de informática a nivel útil porque apenas han desarrollado uno o 3 años antes de ponerse la corbata.
UML sirve para que dichos consultores y algún jefe de proyecto que piensa que sabe mucho hagan un montón de diagramas para hacer ver que su trabajo es útil. Trabajo que nunca se actualiza y queda guardado en el cajón como la reliquia de la "documentación de la primera versión", a veces ni eso, "prediseño de la primera version".
Útil és documentar el código y hacer una wiki del proyecto si es grande.
Útil es hacer un pequeño diagrama del flujo principal a nivel muy alto. Y eso no es UML. Son diagramas y bolitas.
No conozco a nadie que lleve trabajando varios años que se conozca todas las reglas inútiles de UML que sólo sirven en el mundo académico para aprovar.
UML repito, no son los diagramas y bolitas que muchos hacemos y seguimos haciendo. Son un conjunto de normas que no se conoce ni su madre sobre como dibujar. Y por eso no se usa.
- "yo no documento porque prefiero una ñapa a tiempo que algo bien hecho tarde"
- "el que venga detrás que arree, aunque tenga que ser yo mismo en 3 meses"
- "no te quejes, los de sistemas son peores"