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.
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.
#1:
Joder, tanto estudiarlo en la carrera para esto. Bueno, siempre nos quedará el mus.
#10:
#9 Sí, con el BBVA, con el Santander,... Se llaman deudas.
#98:
#90 Estas noticias sobre programación son geniales para ir anotando nicks de gente con la que nunca trabajarías. No hablo de no usar UML o patrones, sino de estas joyitas:
- "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"
#73:
Madre mía, la de cuñaos informáticos que salen a la luz en estos comentarios tirando por tierra todos aquellos procesos o herramientas relativos a la ingeniería del software únicamente porque no los utilizan para montar el Wordpress de su empresa.
#17:
#12 Y todos como buenos trabajadores, lo poco que averiguaron no lo documentaron, para que la empresa siga gastando en analisis por duplicado, triplicado y lo que haga falta... muy bien todos... Los siguientes que vengan os agradeceran que seais tan buenos trabajadores y compañeros. Si es que hay siguientes debido al tira de dinero en tareas ya hechas.
#101:
#90 Eso que llamas "diagramas y bolitas" es un uso del UML que fowler catalogaba como "UML as Sketch" (http://martinfowler.com/bliki/UmlMode.html como siempre, leer a a fowler obligatorio :P), dibujos informales que pueden ayudar sobre todo para compartir en un equipo una idea de diseño, a mucha gente le ayuda verlo visualmente y no esta mal tener un lenguaje común de modelado donde sepamos que es una flecha y que es una caja, aunque sin mucho formalismo porque entonces te pierdes en los detalles y precisamente eso juega en contra de tener una visión compartida de algo simple y rápida.
Lo que nunca ha funcionado muy bien es tratar de usar "UML as blueprint" o "UML as programming language", donde UML tiene un rol central en el desarrollo, en general las herramientas visuales de programación visual o mediante diagramas se han demostrado con los años bastante ineficientes y engorrosas y hoy en día poca gente se plantea su uso, los más viejunos podemos recordar como estas herramientas se supone que iban a ser la panacea a finales de los 90 principios de los 2000 y al final como tantas cosas en software la cosa quedo en agua de borrajas.
#26:
#13 Será irrelevante para tí. Para mí es imprescindible. No tiene nada que ver con la metodología que utilices. Es un método de representación. Yo flipo en el trabajo cómo la gente no hace un puto diagrama de nada, y después las cosas salen como salen. Metodología ágil no significa ser un tontaina.
#8:
Una vez vino un chavalín nuevo en la empresa a preguntarme por la documentación de un módulo. "¿No te la han pasado? Espera, que la tengo en esta carpeta", y acto seguido abrí el archivador, saqué una semicarpeta con algunos folios y se la di con mi mejor sonrisa.
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.
#11:
#8 trabajas en un departamento de gente con necesidades especiales, no?
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..."
#33:
#32 Yo estoy en un proyecto de software libre y hago mis diagramas
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
#13:
#4 Eso jamás. UML es irrelevante ahora con las metodologías ágiles, pero los patrones son cada vez más importantes y más usados.
#4:
Hoy UML, mañana caerán los "Patrones de Diseño"
#19:
#18 ¿Tienes una carpeta llena de archivos vacios y dices que no tienes sitio para la documentacion? No me hagas reir, la documentacion es parte del trabajo de desarrollo, si no esta hecha, para mi el trabajo no esta completado. Pero tu ponte excusas, a mi me da igual, no es mi profesionalidad la que esta en duda. En ningun momento digo que la culpa sea tuya por no documentar, ¿donde he dicho eso? ¿de donde sacas semejante tontería? Lo que digo es que de profesionales, los que no documentais, teneis poco, mas que nada porque la documentacion muchas veces va en codigo, como pueda ser un proyecto Java. Y si es un modulo independiente, como pueda ser un sistema satelite de una app para dar acceso desde fuera de la intranet, debería tener tambien su correspondiente manual de usuario. Pero lo dicho, que te pongas las excusas que quieras, a vagos como vosotros que se niegan a hacer por lo que se le paga y corresponde por categoría no los contrataba ni harto a heroina.
#34:
#33 diagramas hay en los grandes proyectos de software libre, pero hacer esos diagramas no supone ni el 1% del trabajo, nada que ver con métrica y esas metodología del siglo pasado, con un buen diseño un diagrama hecho en PowerPoint en un par de diapositivas es suficiente.
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.
Ojalá liberen las herramientas UML como Open Source, y si alguien lo necesita las pueda usar. Es cierto que no son muy usadas, pero en proyectos grandes son casi una necesidad.
No se usa porque algo que nació para ser útil se convirtió en una cosa complicadiiiiísima. Pero siempre va bien tener algo que dibuje cajas y flechas con los símbolos de 1.1 1,n y cuatro cosillas mas del uml
Una vez vino un chavalín nuevo en la empresa a preguntarme por la documentación de un módulo. "¿No te la han pasado? Espera, que la tengo en esta carpeta", y acto seguido abrí el archivador, saqué una semicarpeta con algunos folios y se la di con mi mejor sonrisa.
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.
#12 Y todos como buenos trabajadores, lo poco que averiguaron no lo documentaron, para que la empresa siga gastando en analisis por duplicado, triplicado y lo que haga falta... muy bien todos... Los siguientes que vengan os agradeceran que seais tan buenos trabajadores y compañeros. Si es que hay siguientes debido al tira de dinero en tareas ya hechas.
#17 claro hombre, criticar es bien sencillo. "La culpa es vuestra por no documentar". Claro, lo de que no te dejen sitio donde meter la documentación ya tal (no, los servicios externos a la empresa no son una opción en muchos casos).
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
#18 ¿Tienes una carpeta llena de archivos vacios y dices que no tienes sitio para la documentacion? No me hagas reir, la documentacion es parte del trabajo de desarrollo, si no esta hecha, para mi el trabajo no esta completado. Pero tu ponte excusas, a mi me da igual, no es mi profesionalidad la que esta en duda. En ningun momento digo que la culpa sea tuya por no documentar, ¿donde he dicho eso? ¿de donde sacas semejante tontería? Lo que digo es que de profesionales, los que no documentais, teneis poco, mas que nada porque la documentacion muchas veces va en codigo, como pueda ser un proyecto Java. Y si es un modulo independiente, como pueda ser un sistema satelite de una app para dar acceso desde fuera de la intranet, debería tener tambien su correspondiente manual de usuario. Pero lo dicho, que te pongas las excusas que quieras, a vagos como vosotros que se niegan a hacer por lo que se le paga y corresponde por categoría no los contrataba ni harto a heroina.
#16 Que se integren en Visual Estudio, te dejen realizar validación del modelo sobre el proyecto, generar stubs de código automáticamente, que sean de interacción visual?
Lo dudo
Sólo el hecho de tener que ir a otra herramienta externa al ide es ya una pérdida de tiempo.
#19 a ver, campeón, vuelvo a decirlo porque no has entendido un carajo: no nos dan sitio para documentación. Cuando la metimos en el repo en formato digital nos dijeron que la sacásemos. Sí, que hagamos la documentación y la metamos directa al triturador
Te estoy hablando de mi caso, a lo mejor crees que estás respondiendo a otro usuario
#21 Es que tu caso me da igual, yo estoy hablando del caso de Mister_Lala y tu vienes con un caso que no viene a cuento. Ademas lo que tu dices no implica perdida de documentacion, que no te den un servidor donde centralizarla, no implica que tu no puedas tener en tu maquina otro servidor o carpeta compartida para ello. Intentas defender un caso con otro diferente. A ti si te la piden, aunque no la tienes centralizada, la tienes, ¿o tampoco te dan espacio en tu maquina? No sé a donde quieres llegar, la verdad. Si no estas defiendiendo a Mister Lala, ¿a que viene tu comentario?
#23 viene a que, para documentar tienes que tener donde guardar. Y no, el cajón deMister_Lala o el de Manolo el del bombo es virtualmente inexistente. La documentación tiene que ser localizable o es absolutamente inútil
#13 Será irrelevante para tí. Para mí es imprescindible. No tiene nada que ver con la metodología que utilices. Es un método de representación. Yo flipo en el trabajo cómo la gente no hace un puto diagrama de nada, y después las cosas salen como salen. Metodología ágil no significa ser un tontaina.
#2 Si no te gusta, no lo uses. Además, la tendencia es que todas las aplicaciones adicionales que traiga Windows, lleguen via la tienda. Microsoft siempre ha tenido miedo a las leyes antimonopolio, por eso no han mejorado Paint.
#26 si uno sabe diseñar, usar patrones y frameworks no necesita hacer un diagrama para explicar la arquitectura al resto del grupo, al menos no más que un diagrama simple que se hace en media hora.
#30 Discrepo. El problema es que nunca se hacen diagramas. Otra cosa es el proceso unificado de rational, que sí que es excesívamente engorroso. Pero hay muchas muchas cosas que sí que requieren un diagrama. Incluso aunque sepas diseñas y usar patrones, los diagramas nunca están de más.
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.
#31 los diagramas me parece algo muy ochentero, toda la información que necesitas la tienes de usar patrones, frameworks, convenciones de estilo y la documentación, la evolución la tienes en el propio repositorio y las issues.
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.
#32 Yo estoy en un proyecto de software libre y hago mis diagramas
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
#33 diagramas hay en los grandes proyectos de software libre, pero hacer esos diagramas no supone ni el 1% del trabajo, nada que ver con métrica y esas metodología del siglo pasado, con un buen diseño un diagrama hecho en PowerPoint en un par de diapositivas es suficiente.
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.
#34 Sólo puedo decirte: depende. Yo no hablo de documentar todo extensivamente.
¿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.
#35 lo que decía, a peor código más necesidad de diagramas en sitios con manuales de estilo estrictos y donde todo el mundo sabe diseñar no hacen tanta falta
#8 ¿Dónde está la gracia? La falta de documentación y de rigor a la hora de poner el trabajo es una de las principales causas de que la gente pierda el tiempo programando sobre la marcha.
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í http://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
#32 "toda la información que necesitas la tienes de usar patrones, frameworks, convenciones de estilo y la documentación, la evolución la tienes en el propio repositorio y las issues."
Y de hecho hay herramientas donde la realización del diagrama se hace automática, como graphviz.
#13 si estamos hablando de patrones de OO, cada vez son menos importantes y se usan menos, puesto que sólo sirven para superar las limitaciones de ese paradigma. Con la introducción de funciones de orden superior ya te limpias unos cuantos.
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).
#1, en la carrera también existen los créditos de libre configuración y no hablemos ya de asignaturas que luego no sirven para nada. Podremos estar de acuerdo o no, pero las hay.
#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.
#58 si se asigna un tiempo tan bajo a una tarea que no da tiempo ni a programar en condiciones menos a documentar. Y sí, se que si programas bien lleva menos tiempo que programando mal, solo que a veces no puedes ni programar bien por que el proyecto en el que estas tiene taras.
#62 es importante saber hacer diagramas, aunque a veces sean mentales, otra cosa es que sirva de algo hacer el UML formal para un proyecto que no necesita ni la mitad de detalle.
#66 Si el tiempo que te dan no te llega ni para programar lo que te piden tienes un problema muy gordo y perderéis mucho tiempo en el futuro arreglando mierdas que podríais usar en documentar. Habla con tu jefe. Cambia el sistema.
#61 Bueno, el metamodelado, por ejemplo, ya se hacía mejor y casi en exclusiva en Eclipse por lo que, si Visual Studio no quiere UML, cacsi mejor, algo menos que pueden joder
Madre mía, la de cuñaos informáticos que salen a la luz en estos comentarios tirando por tierra todos aquellos procesos o herramientas relativos a la ingeniería del software únicamente porque no los utilizan para montar el Wordpress de su empresa.
#68 Entiendo perfectamente a #66. El problema viene cuando tu jefe no es desarrollador, sino comercial, y hay que hacer las cosas a su modo. Si además es de esos "supergurú emprendedores que saben más que tú de todo", lo llevas jodido...
#68 Lo que pasa es que en el futuro tal vez espere estar en otro trabajo mejor. Esto es como los directivos de las empresas: se meten en cosas como trucar los motores de los coches para obtener buenas ganancias ese año. Cuando se descubra el truco y venga la multa ya le tocará a otro lidiar con ello.
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.
#81 Todo eso está muy bien como idea hasta que empiezan a salir todos los bugs y problemas, especialmente en proyectos grandes o largos en el tiempo. El tema del tiempo entonces ya toma otro cariz y no parece tan descabellado dedicarle más a revisar y solucionar.
#84 Si el programa no tuviera bugs no se contraría un mantenimiento
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.
#13 UML es irrelevante ahora con las metodologías ágiles -> NO
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.
#69 Si no me la pagan no la hago. Luego si tardo 3 h en entender algo que con documentación hubiesen sido 5 minutos los cobro.
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.
#58 si y no. Comentarios en el código y código legible por si mismo es una cosa y una buena documentación es otra. Si tienes tiempo limitado aunque se supone eso o te paras en esos detalles y no acabas o vas a la chicha y acabas.
#90 Estas noticias sobre programación son geniales para ir anotando nicks de gente con la que nunca trabajarías. No hablo de no usar UML o patrones, sino de estas joyitas:
- "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"
Comentarios
Joder, tanto estudiarlo en la carrera para esto. Bueno, siempre nos quedará el mus.
Y no, no es que eliminen a Paint porque hay muchos software para dibujar, allí sigue ese software sencillo en Windows. ¡Eliminan a UML!
Ojalá liberen las herramientas UML como Open Source, y si alguien lo necesita las pueda usar. Es cierto que no son muy usadas, pero en proyectos grandes son casi una necesidad.
Hoy UML, mañana caerán los "Patrones de Diseño"
No se usa porque algo que nació para ser útil se convirtió en una cosa complicadiiiiísima. Pero siempre va bien tener algo que dibuje cajas y flechas con los símbolos de 1.1 1,n y cuatro cosillas mas del uml
#1 Pues sí, porque el modelo entidad-relación para bases de datos tampoco lo vas a usar nunca profesionalmente.
Joder pues no lo usaran en microsoft pero aquí lo usamos mucho, para ser exactos el plantUML http://plantuml.com/
Una vez vino un chavalín nuevo en la empresa a preguntarme por la documentación de un módulo. "¿No te la han pasado? Espera, que la tengo en esta carpeta", y acto seguido abrí el archivador, saqué una semicarpeta con algunos folios y se la di con mi mejor sonrisa.
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.
#6 No te creas, yo tengo bastantes relaciones con entidades.
#9 Sí, con el BBVA, con el Santander,... Se llaman deudas.
#8 trabajas en un departamento de gente con necesidades especiales, no?
Porque que reir esa tontería tiene delito.
#11 Se reían porque todos se habían visto antes en esa tesitura, la de tener que modificar un módulo y no existir ninguna documentación.
#4 Eso jamás. UML es irrelevante ahora con las metodologías ágiles, pero los patrones son cada vez más importantes y más usados.
Estoy de acuerdo, con Dia se pueden hacer cajitas
#2 Ya salio hace unos meses la nota oficial en la que le daban muerte a Paint para las siguientes versiones de Windows.
Ahora miro si encuentro algo mas.
#3 Hay muchas herramientas de código abierto que puedes utilizar. No es necesario.
https://www.google.com.ar/#q=uml+software+open+source
#12 Y todos como buenos trabajadores, lo poco que averiguaron no lo documentaron, para que la empresa siga gastando en analisis por duplicado, triplicado y lo que haga falta... muy bien todos... Los siguientes que vengan os agradeceran que seais tan buenos trabajadores y compañeros. Si es que hay siguientes debido al tira de dinero en tareas ya hechas.
#17 claro hombre, criticar es bien sencillo. "La culpa es vuestra por no documentar". Claro, lo de que no te dejen sitio donde meter la documentación ya tal (no, los servicios externos a la empresa no son una opción en muchos casos).
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
#18 ¿Tienes una carpeta llena de archivos vacios y dices que no tienes sitio para la documentacion? No me hagas reir, la documentacion es parte del trabajo de desarrollo, si no esta hecha, para mi el trabajo no esta completado. Pero tu ponte excusas, a mi me da igual, no es mi profesionalidad la que esta en duda. En ningun momento digo que la culpa sea tuya por no documentar, ¿donde he dicho eso? ¿de donde sacas semejante tontería? Lo que digo es que de profesionales, los que no documentais, teneis poco, mas que nada porque la documentacion muchas veces va en codigo, como pueda ser un proyecto Java. Y si es un modulo independiente, como pueda ser un sistema satelite de una app para dar acceso desde fuera de la intranet, debería tener tambien su correspondiente manual de usuario. Pero lo dicho, que te pongas las excusas que quieras, a vagos como vosotros que se niegan a hacer por lo que se le paga y corresponde por categoría no los contrataba ni harto a heroina.
#16 Que se integren en Visual Estudio, te dejen realizar validación del modelo sobre el proyecto, generar stubs de código automáticamente, que sean de interacción visual?
Lo dudo
Sólo el hecho de tener que ir a otra herramienta externa al ide es ya una pérdida de tiempo.
#19 a ver, campeón, vuelvo a decirlo porque no has entendido un carajo: no nos dan sitio para documentación. Cuando la metimos en el repo en formato digital nos dijeron que la sacásemos. Sí, que hagamos la documentación y la metamos directa al triturador
Te estoy hablando de mi caso, a lo mejor crees que estás respondiendo a otro usuario
#1 puedes usar papel y lápiz para realizar UML pero corres riesgo de romperte la mano de repartir cartas
#21 Es que tu caso me da igual, yo estoy hablando del caso de Mister_Lala y tu vienes con un caso que no viene a cuento. Ademas lo que tu dices no implica perdida de documentacion, que no te den un servidor donde centralizarla, no implica que tu no puedas tener en tu maquina otro servidor o carpeta compartida para ello. Intentas defender un caso con otro diferente. A ti si te la piden, aunque no la tienes centralizada, la tienes, ¿o tampoco te dan espacio en tu maquina? No sé a donde quieres llegar, la verdad. Si no estas defiendiendo a Mister Lala, ¿a que viene tu comentario?
#20 Que los hay lo hay, no se si específicamente con Visual Studio.
Pegate una vuelta por estos links:
http://stackoverflow.com/questions/15376/whats-the-best-uml-diagramming-tool
https://en.wikipedia.org/wiki/List_of_Unified_Modeling_Language_tools
#23 viene a que, para documentar tienes que tener donde guardar. Y no, el cajón deMister_Lala o el de Manolo el del bombo es virtualmente inexistente. La documentación tiene que ser localizable o es absolutamente inútil
#13 Será irrelevante para tí. Para mí es imprescindible. No tiene nada que ver con la metodología que utilices. Es un método de representación. Yo flipo en el trabajo cómo la gente no hace un puto diagrama de nada, y después las cosas salen como salen. Metodología ágil no significa ser un tontaina.
Pues yo lo utilizo para poner las ideas en orden...
#22 La gracia del UML es que sirva de documentación. Si luego no se mantiene, al final no sirve para nada.
#2 Si no te gusta, no lo uses. Además, la tendencia es que todas las aplicaciones adicionales que traiga Windows, lleguen via la tienda. Microsoft siempre ha tenido miedo a las leyes antimonopolio, por eso no han mejorado Paint.
#26 si uno sabe diseñar, usar patrones y frameworks no necesita hacer un diagrama para explicar la arquitectura al resto del grupo, al menos no más que un diagrama simple que se hace en media hora.
#30 Discrepo. El problema es que nunca se hacen diagramas. Otra cosa es el proceso unificado de rational, que sí que es excesívamente engorroso. Pero hay muchas muchas cosas que sí que requieren un diagrama. Incluso aunque sepas diseñas y usar patrones, los diagramas nunca están de más.
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.
#31 los diagramas me parece algo muy ochentero, toda la información que necesitas la tienes de usar patrones, frameworks, convenciones de estilo y la documentación, la evolución la tienes en el propio repositorio y las issues.
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.
#32 Yo estoy en un proyecto de software libre y hago mis diagramas
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
#33 diagramas hay en los grandes proyectos de software libre, pero hacer esos diagramas no supone ni el 1% del trabajo, nada que ver con métrica y esas metodología del siglo pasado, con un buen diseño un diagrama hecho en PowerPoint en un par de diapositivas es suficiente.
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.
#34 Sólo puedo decirte: depende. Yo no hablo de documentar todo extensivamente.
¿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.
#35 lo que decía, a peor código más necesidad de diagramas en sitios con manuales de estilo estrictos y donde todo el mundo sabe diseñar no hacen tanta falta
#8 ¿Dónde está la gracia? La falta de documentación y de rigor a la hora de poner el trabajo es una de las principales causas de que la gente pierda el tiempo programando sobre la marcha.
#4 Los cojones.
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..."
Doxygen es tu amigo. Te genera también diagramas UML de manera automática. Guay para código ya existente.
#3 en proyectos grandes son casi una necesidad.
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í http://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
#37 ojalá me diesen tiempo para documentar en mi trabajo...
#38 Si "la clase triángulo hereda la clase figura..." es lo que sabes de UML o lo que te enseñaron, mal vas.
#37 Mejor no te cuento como funciona el departamento de sistemas.
#32 "toda la información que necesitas la tienes de usar patrones, frameworks, convenciones de estilo y la documentación, la evolución la tienes en el propio repositorio y las issues."
Y de hecho hay herramientas donde la realización del diagrama se hace automática, como graphviz.
#17 bueno la documentación también te tendrán que mandar hacerla. No vas a echar horas no pagadas en hacerla
#22 paper y lápiz? Estamos locos¡¡???
#42 Hablaba de programación orientada a objetos, y que se enseñaba lo muy básico de conceptos como la herencia.
#35 Sabes que a partir de ahora se te conocera como diagramaman, no?
Para #1. Gnu/Linux. No tienes porque permitir que los caprichos de una sola empresa dirijan tus pasos.
#46 no, lo haces en papel, a lápiz, y después lo pasas ordenador. Así trabajamos los genios de la industria electrónica e formatica
#15 Si esta a punto de llegar el Paint con objetos 3D...
Que risas, yo acabo de empezar a usarlo en la carrera, tope bien oye.
#29 https://www.fayerwayer.com/2016/10/el-nuevo-paint-permite-dibujar-en-3d/
#7 Tranquilo, seguramente lo cambiarán por su propia versión de UML, dirán que es mejor, más chachi y demás, y listos
#3 Una pérdida de tiempo y dinero más bien.
#13 si estamos hablando de patrones de OO, cada vez son menos importantes y se usan menos, puesto que sólo sirven para superar las limitaciones de ese paradigma. Con la introducción de funciones de orden superior ya te limpias unos cuantos.
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).
Una palabra: qeditor-plantuml. El mejor software de modelado UML gratuito. Otros de pago como boUML también están bien.
#41 Se supone que la vas creando a medida que programas. No necesitas que te asignen un tiempo para ello...
#28 ¿documentación? ¿Y eso qué é lo que es? (léase con acento andaluz)
#8 Una semicarpeta dentro de la subcarpeta contenida en otra carpeta con los folios en blanco... Gracia la justa
#54 😂 Seguro, pero aquí somos de usar cosas open source, ya se paga bastante por el winblows y el office
Que bien, justamente estoy estudiando UML ahora. Creéis que me servirá de algo?
#59 ¿Lo del acento es para que quede claro que lo dice un tonto?
#1, en la carrera también existen los créditos de libre configuración y no hablemos ya de asignaturas que luego no sirven para nada. Podremos estar de acuerdo o no, pero las hay.
#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.
#6
Tu comentario es irónico ¿verdad?
#58 si se asigna un tiempo tan bajo a una tarea que no da tiempo ni a programar en condiciones menos a documentar. Y sí, se que si programas bien lleva menos tiempo que programando mal, solo que a veces no puedes ni programar bien por que el proyecto en el que estas tiene taras.
#62 es importante saber hacer diagramas, aunque a veces sean mentales, otra cosa es que sirva de algo hacer el UML formal para un proyecto que no necesita ni la mitad de detalle.
#66 Si el tiempo que te dan no te llega ni para programar lo que te piden tienes un problema muy gordo y perderéis mucho tiempo en el futuro arreglando mierdas que podríais usar en documentar. Habla con tu jefe. Cambia el sistema.
#25 #45 si no quieres documentar para otros, documenta para ti mismo y guárdala localmente
#61 Bueno, el metamodelado, por ejemplo, ya se hacía mejor y casi en exclusiva en Eclipse por lo que, si Visual Studio no quiere UML, cacsi mejor, algo menos que pueden joder
#62 no. Ni toda la mierda sobre herencia e interfaces.
Object composition es el futuro.
#6 ¿Por qué dices eso o en qué te basas para realizar tal afirmación?.
Madre mía, la de cuñaos informáticos que salen a la luz en estos comentarios tirando por tierra todos aquellos procesos o herramientas relativos a la ingeniería del software únicamente porque no los utilizan para montar el Wordpress de su empresa.
#68 ya te digo es tal cual dices.
#68 Entiendo perfectamente a #66. El problema viene cuando tu jefe no es desarrollador, sino comercial, y hay que hacer las cosas a su modo. Si además es de esos "supergurú emprendedores que saben más que tú de todo", lo llevas jodido...
#6 Eso, pasémonos el diseño por el forro de los cojones, bueno es lo que hacen el 99,9% de los desarrolladores... cc #65 #76
#1 al menos el mus valió la pena la pena
#59 hay gente pa to
#64 existían
#73 Amén. He visto gente muy buena, con responsabilidad y teniendo más dudas que la mayoría de los que han comentado. Flipante
#68 Lo que pasa es que en el futuro tal vez espere estar en otro trabajo mejor. Esto es como los directivos de las empresas: se meten en cosas como trucar los motores de los coches para obtener buenas ganancias ese año. Cuando se descubra el truco y venga la multa ya le tocará a otro lidiar con ello.
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.
#68 Habla con tu jefe. Cambia el sistema.
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.
#6 estás de coña?
#8 La de risas que os debeis pegar en tu trabajo cuando surge un bug crítico de un modulo sin documentación de hace años y teneis que solucionarlo....
#81 Todo eso está muy bien como idea hasta que empiezan a salir todos los bugs y problemas, especialmente en proyectos grandes o largos en el tiempo. El tema del tiempo entonces ya toma otro cariz y no parece tan descabellado dedicarle más a revisar y solucionar.
Ese es el momento de atacar!
#84 Si el programa no tuviera bugs no se contraría un mantenimiento
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.
#4 Este patrón de diseño ya cayó
#13 UML es irrelevante ahora con las metodologías ágiles -> NO
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.
#69 Si no me la pagan no la hago. Luego si tardo 3 h en entender algo que con documentación hubiesen sido 5 minutos los cobro.
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
#50 pero que era un lápiz?
#1 UML no sirve PARA NADA. Me explico.
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.
#58 si y no. Comentarios en el código y código legible por si mismo es una cosa y una buena documentación es otra. Si tienes tiempo limitado aunque se supone eso o te paras en esos detalles y no acabas o vas a la chicha y acabas.
#62 si
#75 tu jefe o tu cliente
#8 y en vez de sentiros fatal por no tener documentación, pues os echasteis unas risas. Perfecto.
#90 Ni eso. Los consultores son funcionales que no han programado nunca y las especificaciones son una servilleta de bar
#90 el unico que me han pedido hacer fue para un documento para pedir una subvencion...
#59 Tienes la gracia en el culo, deja el humor en manos de profesionales. Un andaluz.
#90 Estas noticias sobre programación son geniales para ir anotando nicks de gente con la que nunca trabajarías. No hablo de no usar UML o patrones, sino de estas joyitas:
- "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"
#15 Están desarrollando una versión UWP (es un tipo de aplicaciones que solo se pueden instalar en Windows 10) de Paint, así que muerto no está.
#98 Me encanta el verbo arrear aplicado al computer science!! Me pregunto como será algo parecido en inglés!!