¿Todavía se considera que UML es una forma viable de documentar un diseño de software?¿Sigue siendo visto UML como una forma viable de documentar un diseño de software?
puntos extra para las referencias que respaldan cualquier reclamación :)
Estoy respondiendo a la nueva versión de la pregunta que habla a UML como una herramienta de documentación. Trataré de desempeñar un papel en UML como una herramienta de comunicación también, porque son uno en lo mismo.
Contexto: Este punto de vista es impulsado de mi trabajo diario como Arquitecto tener que diseñar a través de cientos de sistemas/software, 10.000 horas + esfuerzos, y el mantenimiento de la documentación y prácticas coherentes para una cartera de sistemas. Esto significa que tuve que lidiar con la calidad, consistencia y definición de la documentación muchas veces.
Resumen: ¿Qué más hay? Claro que puedes discutir los niveles de documentación, ¿es UML realmente mejor que leer el código para la lógica condicional? Probablemente no, pero en general no hay una alternativa real si el espacio problemático es lo suficientemente grande.
Si UML es nada más, es para documentación y comunicación."UML Distilled" escrito por Martin Fowler, que es casi el estándar de facto para los libros UML, conlleva esta opinión. Fowler, si leo correctamente, cree que el uso principal de UML es para la comunicación, qué documentación es, simplemente, del tipo estático. No tanto especificaciones de bajo nivel y generación de código.
IBM, Borland, Microsoft y Eclipse son compatibles con UML con grandes herramientas complejas. Muchos otros proveedores más pequeños o específicos también proporcionan herramientas UML. No estoy al tanto de un estándar de diagrama/modelado más aceptado/implementado.
Además, tenga en cuenta las alternativas, ¿qué diagrafía es más común? Por qué no usar lo que la mayoría de la gente sabe La mayoría de los colegios/universidades si enseñan cualquier diagramación o modelado usan UML. Aparte de algunos estilos de flujo o diagramas de lógica condicional, no hay mucho más por ahí, bien documentado y estandarizado.
La notación estándar es aún más crítica que lo que la mayoría de la gente sabe. En proyectos grandes, no siempre se puede leer el código, hablar con la persona que lo escribió o preguntar al socio comercial qué es lo que querían de nuevo. Aquí es donde los estándares son la clave. El uso inconsistente causará confusión, y realmente lo hará si las personas pueden inventar o agregar símbolos de una manera informal. Además, no desea crear un documento y siempre debe explicar lo que quiere decir.
Nunca inventes a menos que también lo hagas, que es la alternativa más probable a UML. Piense cada vez que una nueva persona se una al equipo o compañía. ¿Qué significa una caja, flecha? ¿Puede esta flecha conectarse a este triángulo en esta dirección, y qué significa? Básicamente, debes inventar un lenguaje/modelo específico de dominio. Por lo tanto, necesita una presentación de capacitación, tutoriales, ejemplos, trabajos de revisión, programar sesiones de capacitación, mantener el método de documentación inventado, etc. Luego, por supuesto, cambia de socios externos o contrata a una nueva persona y debe hacerlo todo de nuevo. Permita que las personas se concentren en aprender los sistemas, no en su método de documentación, o si tienen que hacer que sea un conocimiento o habilidad transferible como UML. Permita que los expertos se centren en la codificación y el diseño, sin inventar un estándar de documentación/diagrama.
Para todos los críticos UML no vivo en una torre de marfil o burbuja de cristal, tengo que vivir con cientos de diferentes métodos de documentación cotidiana como las personas inventen ellos o yo estoy mirando a la próxima tecnología vendedor. UML es no perfecto, pero es el más común, es lo suficientemente bueno y no es trivialmente reemplazable.
válidos preguntas adicionales:
Gran respuesta/post - gracias por tomarse el tiempo para componerlo. – Jamo
El UML es sólo una notación estándar para la representación de un diseño, no es un proceso o un método.
Para añadir a esto, UML está ahí para ayudarle a expresar su diseño, por no cumplir. –
¡Expuesto por un hombre que no ha usado Enterprise Architect (http://www.sparxsystems.com.au)! Pruébalo ... Son los awesomes. – Kieveli
Buen punto. He editado la pregunta para reflejar esto :) –
Pensar es la única forma viable de diseñar software.
UML a veces se ve como una forma viable de describir parcialmente el diseño que se le ocurrió.
Estoy de acuerdo con el punto de pensar, pero encuentro que algunos de los diagramas de UML (diagramas de secuencia, por ejemplo) son muy útiles para pensar problemas que involucran interacciones razonablemente complejas. No estoy de acuerdo con la idea de usarlo puramente como un sistema de documentación posterior al diseño. –
Una vez trabajé con un tipo que no podía pensar sin tener anotaciones UML. Le confundió tener dos cajas en una pizarra con una línea que las conecta sin indicar su relación a través de un icono específico de UML. – Kieveli
Como herramienta para la visualización, personalmente encontré UML * dramáticamente * útil en una etapa de diseño. – annakata
UML es una manera de presentar visualmente un diseño, no el método de diseño en sí. Es solo una herramienta que usas a lo largo de tus viajes. Hasta donde yo sé, todavía es bastante frecuente en el mundo de la ingeniería de software porque es un estándar y se puede utilizar para transmitir ideas entre dos personas de manera efectiva (razón por la cual se conoce como lenguaje).
UML, como lo señaló @John Topley, es solo una notación estándar para describir aspectos de un diseño orientado a objetos, por lo que su pregunta no tiene mucho sentido.
Personalmente, creo que los diagramas de clases a ser el aspecto más útil de UML; Casi nunca me molesto con la mayoría de las otras cosas, ya que me resulta más fácil escribir documentación breve y descriptiva que explique las interacciones y los comportamientos. Los diagramas de clases, sin embargo, proporcionan una visión general razonable de la arquitectura.
Una cosa a tener en cuenta es que no se debe necesariamente preocuparse demasiado acerca de cómo escribir UML "perfecta" (es decir normativo); lo más importante es asegurarse de que las personas entiendan su diseño. Dicho esto, tenga cuidado con el abuso accidental de la notación, porque eso puede confundir a las personas que esperan que las cosas tengan un significado específico. En caso de duda, haga una anotación con el texto para tener claro lo que está sucediendo.
UML es más bien una forma de visualizar el diseño de un sistema, no es realmente un proceso de hacer que el diseño. Aunque ser capaz de visualizar ayuda al proceso de diseño.
Dicho esto me gusta y el uso de UML en el diseño de más de una arquitectura básica.
Es muy útil cuando se diseña para ser capaz de ver cómo todas las piezas encajan entre sí. Muchas veces un diseño mostrará deficiencias de arquitectura al hacer el UML, antes de que haya comenzado cualquier codificación.
Sirve como una buena referencia para hacer que la gente se familiarice con el funcionamiento de un sistema, y es útil cuando vuelvas a ese código más tarde y dices: "¿Cómo lo diseñé de nuevo?"
Básicamente para responder a su pregunta editada, sí, es útil documentar un diseño de sistema porque muchas personas ya lo saben y, como ya se señaló, hay muchas herramientas que lo soportan.
UML se debe utilizar como una herramienta de comunicación. Definitivamente es un medio válido para comunicar diseños y ofrece a los desarrolladores un lenguaje común para discutir esos diseños antes de la implementación.
La mejor manera de documentar su diseño es escribiendo código de limpieza. UML, como toda otra documentación, tiende hacia la entropía.
Estoy de acuerdo. He usado UML para 'discutir' (por ejemplo, pizarra) opciones de diseño, pero usarlo para 'documentar' un diseño se convierte rápidamente en un problema de mantenimiento. "Ningún plan de batalla sobrevive al contacto con el enemigo". - Colin Powell –
La pregunta suena un poco hacia atrás para adelante para mí ... No creo UML pretende ser una herramienta para el diseño de software, por lo tanto como una herramienta para documentar un diseño (en curso)
En mi opinión, UML puede ser una herramienta valiosa para dicha documentación, ya que estandariza una serie de vistas en un diseño ... pero de ninguna manera el único válido. Cualquier documento de diseño que sea lo suficientemente claro y bien escrito hará el trabajo, incluso si no tiene UML en él.
IMO, UML perdió gran parte de su imagen como la única y siempre la mejor solución para el desarrollo de software. Mientras que los entusiastas al principio son (y algunos todavía lo son) en la opinión de que UML resolverá los problemas de diseño y todo debería idealmente dibujarse con UML. La realidad demostró que no es mucho mejor que cualquier otro tipo de diagrama.
IMO, UML ahora se ve ampliamente como lo que realmente es: un estándar para muchos diagramas necesarios en el análisis y diseño de oo. De hecho, es el estándar de diagrama más popular en uso. Hay más herramientas y más personas conocen UML que cualquier otro estilo de diagrama.
UML puede convertirse en parte del proceso de diseño e implementación. Enterprise Architect tiene algunas excelentes herramientas para el diseño inicial. UML falla cuando no está respaldado por sus herramientas adicionales de reimportación después de la personalización para actualizar el diseño. Realmente hace un buen trabajo al mostrar su estructura actual y le permite agregar detalles en términos de otros diagramas UML (casos de uso, diagramas de estado, maquetas de interfaz de usuario y más).
Lamentablemente, UML realmente no está acostumbrado a su potencial en la práctica.
Prefiero usar UML autogenerado (código fuente -> UML) para visualizar la implementación de un sistema. Encuentro que la documentación estática a menudo es inútil y a veces engañosa.
La charla How to Represent the Architecture of Your Enterprise Application Using UML 2.0 and More de Paulo Merson en JavaOne 2006 describe varios enfoques para documentar una arquitectura, con y sin UML. Hay más información en Architecture Documentation, Views and Beyond (V&B) Approach, que describe un enfoque defendido por el Software Engineering Institute (SEI).
UML es solo un método para visualizar algunos aspectos de un diseño de software. No se puede usar solo para documentar un diseño.
Editar: Se ha cambiado la pregunta para preguntar sobre la viabilidad de UML para la documentación en lugar de diseño, basado en sugerencias de respuestas –