vistas vista sistema procesos modelo lógica kruchten imagen física exportar diagrama como architect architecture uml

architecture - sistema - vista de procesos



¿Sigue siendo UML una forma viable de documentar un diseño de software? (13)

¿Se considera que UML es una forma viable de documentar un diseño de software?

Puntos extra por referencias que respaldan cualquier reclamo :)

El UML es solo una notación estándar para representar un diseño, no es un proceso o un enfoque.

En mi opinión, 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 en el principio están (y algunos todavía lo están) 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.

OMI, UML ahora es ampliamente visto 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 alrededor y más personas conocen UML que cualquier otro estilo de diagrama.

Estoy respondiendo a la nueva versión de la pregunta que habla de UML como herramienta de documentación. Intentaré desempeñar un papel en UML como herramienta de comunicación también, porque son lo mismo.

Contexto: esta perspectiva se basa en mi trabajo diario como Arquitecto que tiene que diseñar en cientos de sistemas / software, esfuerzos de más de 10.000 horas y mantener documentación y prácticas coherentes para una cartera de sistemas. Esto significa que he tenido que lidiar con la calidad, consistencia y definición de la documentación muchas veces.

Resumen: ¿Qué más hay? Seguro que puedes discutir los niveles de documentación, ¿es UML realmente mejor que leer código para lógica condicional? Probablemente no, pero en general no hay una alternativa real si el espacio del problema es lo suficientemente grande.

Si UML no es otra cosa, es para documentación y comunicación. "UML Distilled", escrito por Martin Fowler, que es casi el estándar de facto para los libros de UML, tiene esta opinión. Fowler, si leo correctamente, cree que el uso principal de UML es para la comunicación, cuya documentación es, simplemente, estática. No tanto las especificaciones de bajo nivel y la generación de código.

IBM, Borland, Microsoft y Eclipse admiten UML con grandes herramientas complejas. Muchos otros proveedores más pequeños o dirigidos también proporcionan herramientas UML. No estoy al tanto de un estándar de diagrama / modelado más aceptado / implementado.

Además, considere las alternativas, ¿qué notación de diagrama es más común? ¿Por qué no usar lo que la mayoría de la gente sabe? La mayoría de los colegios universitarios / universidades, si enseñan diagramas o modelos, usan UML. Aparte de algunos estilos de diagramas de flujo o de lógica condicional, no hay mucho más allá, bien documentados y estandarizados.

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 puede leer el código, hablar con la persona que lo escribió o preguntarle al socio comercial qué deseaba nuevamente. Aquí es donde las normas son clave. El uso inconsistente causará confusión, y realmente lo hará si las personas pueden inventar o agregar a los símbolos de una manera informal. Además, no desea crear un documento y siempre tiene que explicar lo que quiso decir.

Nunca inventes a menos que tú también lo tengas, que es la alternativa más probable a UML. Piense en cada vez que una nueva persona se une 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 tienes que inventar un lenguaje / modelo específico de dominio. Por lo tanto, necesita una presentación de capacitación, tutoriales, ejemplos, trabajo de revisión, programar sesiones de capacitación, mantener el método de documentación inventado, etc. Luego, por supuesto, cambia de pareja o contrata a una nueva persona y tiene que repetir todo nuevamente. Deje que las personas se centren en aprender los sistemas, no su método de documentación, o si tienen que convertirlos en conocimientos o habilidades transferibles como UML. Deje que los expertos se centren en la codificación y el diseño, no en inventar un estándar de documentación / diagrama.

A todos los críticos de UML no vivo en una torre de marfil ni en una burbuja de vidrio, tengo que vivir con cientos de métodos de documentación diferentes cada día, ya que la gente los inventa o estoy mirando la tecnología del próximo proveedor. UML no es perfecto, pero es el más común, es lo suficientemente bueno y no es reemplazable trivialmente.

Preguntas adicionales válidas:

  • ¿Qué debo documentar visualmente con UML, donde pueden hacerse cargo los comentarios de código?
  • ¿Qué lapso o aspectos son más importantes?
  • ¿Cuál podría ser un conjunto consistente de artefactos que funcionen para mi tipo de sistemas o aplicaciones? (Esta es una pregunta crítica si trabaja en una empresa con cientos de aplicaciones / sistemas)
  • ¿Dónde almacenamos la documentación y hacemos que se pueda buscar y descubrir?

La pregunta me suena un poco al revés ... No creo que UML esté pensado como una herramienta para diseñar software, sino como una herramienta para documentar un diseño (en progreso).

En mi opinión, UML puede ser una herramienta valiosa para dicha documentación, ya que estandariza varias vistas en un diseño ... pero de ninguna manera es la única válida. Cualquier documento de diseño suficientemente claro y bien escrito hará el trabajo, incluso si no tiene un UML.

Prefiero usar UML generado automáticamente (código fuente -> UML) para visualizar la implementación de un sistema. Encuentro que la documentación estática es a menudo inútil y, a veces, engañosa.

UML debe ser utilizado como una herramienta de comunicación. Definitivamente, es un medio válido para comunicar diseños y brinda 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 escribir código limpio . UML, como toda otra documentación, tiende hacia la entropía.

Aquí está la mejor referencia que pude encontrar

UML es más una forma de visualizar el diseño de un sistema, no un proceso para hacer ese diseño. Aunque ser capaz de visualizar ayuda al proceso de diseño.

Dicho esto, me gusta y uso UML cuando se diseña más que una arquitectura básica.

Es muy útil cuando se diseña para poder ver cómo encajan todas las partes. Muchas veces, un diseño mostrará deficiencias en la arquitectura al realizar el UML, antes de que comience la codificación.

Sirve como una buena referencia para que las personas estén al tanto de cómo funciona un sistema, y ​​es útil cuando vuelve a ese código más tarde y dice: "¿Cómo lo diseñé de nuevo?"

Básicamente, para responder a su pregunta editada, sí, es útil documentar el diseño de un sistema porque muchas personas ya lo saben y, como ya se señaló, existen muchas herramientas que lo respaldan.

UML es solo un método para visualizar algunos aspectos de un diseño de software. No se puede utilizar solo para documentar un diseño.

UML es una forma 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. Por lo que 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 (por lo que se lo denomina lenguaje).

UML puede convertirse en parte del proceso de diseño e implementación. Enterprise Architect tiene algunas herramientas geniales para el diseño inicial. UML no tiene sentido cuando esto 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, sin embargo, UML realmente no está acostumbrado a su potencial en la práctica.

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 sentido.

Personalmente, encuentro que los diagramas de clase son el aspecto más útil de UML; Rara vez 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 clase, sin embargo, proporcionan una visión general razonable de la arquitectura.

Una cosa a tener en cuenta es que no necesariamente debe preocuparse demasiado por escribir UML "perfecto" (es decir, normativo); Lo más importante es asegurarse de que la gente entienda su diseño. Dicho esto, tenga cuidado de abusar accidentalmente de la notación, ya que puede confundir a las personas que esperan que las cosas tengan un significado específico. En caso de duda, haga anotaciones con el texto para aclarar lo que está sucediendo.

Pensar es la única forma viable de diseñar software.
A veces, se considera que UML es una forma viable de describir parcialmente el diseño que se le ocurrió.