software - ¿Qué tipo de diagramas UML usas?
uml programa (20)
UML2 ofrece diferentes tipos de diagramas. Hasta ahora solo he usado diagramas de clase.
¿Qué tipo de diagramas UML usas? ¿Qué tipo de diagramas recomienda para el diseño y la documentación de un proyecto de software?
A menudo utilizo algún tipo de diagrama de implementación al modelar el sistema (aunque, ciertamente, también tiendo a usar cosas que no sean UML en mis diagramas)
Los diagramas de casos de uso no proporcionan ningún detalle, pero no he visto una mejor manera de brindar rápidamente una visión general de todos los casos de uso en el sistema.
Los diagramas de clase son útiles para mostrar las clases que forman parte de cada paquete. Sin embargo, rara vez los veo utilizados para ese propósito por otros desarrolladores. Por lo general, se utilizan para lanzar un montón de clases en una imagen con poca rima y la razón de por qué las clases particulares están en cada imagen. Así, los diagramas terminan por no ser muy útiles.
Los diagramas de secuencia son indispensables. Las herramientas no admiten en absoluto el uso útil de los diagramas de secuencia, por lo que debe ser un tanto inventivo dentro de las limitaciones de las herramientas. Pero utilizo diagramas de secuencia para demostrar que mis casos de uso coinciden con mi arquitectura y mi diseño coincide con las operaciones de mis paquetes, etc. No creo que haya un diagrama más útil. Sin embargo, la mayoría de la gente no los usa, probablemente porque te obliga a pensar en tu diseño.
El concepto del diagrama de componentes es útil. La versión UML es bastante fea, por lo que generalmente termino dibujando mi propio diagrama usando Powerpoint o Visio.
No soy muy fanático de los diagramas de estado o de actividad. Tuve algunas malas experiencias con los diseños de máquinas estatales de otras personas al principio de mi carrera y, por lo tanto, los evité como la plaga.
Cuando se trata de presentar a un cliente / gerente, utilizo la información de estos diagramas pero la pongo en un formato que es más fácil de entender y en un nivel mucho más alto.
Sin embargo, para presentar a otros desarrolladores de software, estos diagramas deberían ser suficientes para transmitir la información requerida a través del diseño. Pero, por lo general, requieren que se escriba un texto narrativo para que tenga valor.
Los diagramas de secuencia me ayudan a realizar un seguimiento de las cosas cuando trato de asimilar el código de otras personas.
Los diagramas de secuencia son el tipo principal para mí, muy poco uso de cualquier otra cosa realmente.
Mi voto personal: Diagramas de casos de uso Diagramas de secuencia Diagramas de clase
con el Diagrama de Actividad suplementario ocasional.
Pero creo que el kilometraje varía. Normalmente trabajo en sistemas con muchos casos de uso, algunos de los cuales se atienden mediante la integración de soluciones comerciales y la escritura de un poco de código. Entonces, para mí, los casos de uso son a menudo la parte más relevante de UML, con un diagrama de componentes ocasional.
La secuencia y la clase han sido los diagramas de facto para el diseño de software, pero he visto que se utilizan muy poco. Es fácil caer en un patrón de diseño de diagramas de cortador de galletas con estos, y realmente no profundizar en un diagrama que muestre los aspectos de diseño realmente críticos del sistema.
Me encanta UML por su capacidad de proporcionar una sintaxis clara y estandarizada para explicar los problemas de diseño de una manera consistente. Pero odio que a veces se considere un "estándar" de desarrollo y no solo una herramienta para el trabajo. Yo digo que utilícelos si ayudan a iluminar a un grupo crítico de personas y omítalos por completo si tienen un propósito útil para tomar una decisión técnica.
No me gustan los diagramas de casos de uso. El diagrama realmente no muestra mucho, me parece que una lista con viñetas con descripciones es mucho más útil, si no es que las descripciones de casos de uso completo con escenarios, condiciones de falla, etc.
Los diagramas de clase son útiles, aunque en realidad nunca puse todos los detalles en ellos. Obtener las conexiones entre los objetos del dominio y cómo todo encaja entre sí parece ser más útil que atravesar y completar los comportamientos y los campos.
Los diagramas de secuencia son excelentes si está tratando de averiguar el flujo de algo que se está complicando un poco y tiene problemas para visualizar lo que está sucediendo.
Los diagramas de clase, los diagramas de secuencia y los diagramas de estado también son excelentes para tratar de averiguar qué está haciendo el código existente.
No me preocupo por las formalidades en mis diagramas; Son bocetos ásperos en una pizarra.
Pregúntese a sí mismo qué entienden mis usuarios, ¿soy realmente capaz y estoy comprometido a mantener mis diagramas actualizados y precisos o se pudrirán y agregarán confusión ...
Pregúntese: ¿.Net o Java entregan UML en cualquier lugar como parte de su paquete de documentación?
Quizás sería mejor preguntar qué beneficio práctico obtengo del uso de UML.
- UML no pudo entregar herramientas que entiendan los diagramas y escupan el código de plantilla.
- Los usuarios no técnicos realmente no entienden UML.
- ¿Los diagramas de secuencia realmente capturan todo el flujo del programa?
- Diagramas de clase: la mayoría de las personas terminan con sphaghetti, ya que intentan poner demasiado.
- Utilice los diagramas de casos: a menudo son demasiado simples, no valen nada.
- RUP - cuanto menos se diga de esto, mejor ..
Se puede utilizar cualquier mecanismo de diagramación junto con una narración clara para transmitir cualquier idea. Solo hazlo legible, claro y lógico, y debería ayudar a ser auto explicativo.
Solo uso el diagrama de caso de uso y el diagrama de despliegue solo porque los encuentro útiles para explicar la funcionalidad y la configuración de despliegue respectivamente.
Todos pueden ser utilizados para el diseño y documentación de un proyecto. Esto es muy abierto a la interpretación.
Dependerá del proyecto y para quién está creando la documentación. En algunos casos, UML es casi inútil, pero puede ayudarlo a construir un diagrama simple no UML que los usuarios finales puedan entender.
En otras ocasiones, cuando solo está documentando para otros desarrolladores de software, los diagramas UML pueden ser útiles. En este caso, los diagramas de transición de estado pueden ser útiles para los desarrolladores de sistemas, mientras que los diagramas de casos de uso pueden ser mejores para los analistas que documentan los requisitos.
En general, el uso de UML no es útil para otros programadores, usuarios o sus clientes. Es solo una herramienta de comunicación. Si se vuelve demasiado religioso con su uso de UML, no está atendiendo las necesidades de ninguno de estos grupos.
Trabajo en un entorno ágil, por lo que la mayoría de los UML que escribo son dibujos de corta duración en una pizarra.
Uso diagramas de clases para ilustrar cómo las clases se relacionan unas con otras. Uso diagramas de actividad en lugar de diagramas de flujo tradicionales para explicar el flujo general del programa. Los diagramas de máquina de estado pueden ser útiles para explicar los cambios de estado en los ciclos de vida de los objetos. Muy ocasionalmente, usaré un diagrama de secuencia para trabajar con alguna lógica de programa enmarañada, aunque a menudo refactorizo el código para obtener esa comprensión.
Un modelo de dominio es indispensable en la mayoría de los proyectos. Proporciona al personal técnico una comprensión coherente, clara e inequívoca del vocabulario del dominio. Un diagrama de clase UML es la mejor notación para esto (sí, incluso mejor que un glosario en inglés).
Un modelo de caso de uso (que es modelo, no diagrama) es mucho más fácil de manipular que una docena de documentos de Word (por supuesto, dependiendo de su elección de herramienta UML), por lo que le recomiendo que siga la ruta UML para documentar sus casos de uso. Su herramienta UML casi le permitirá asignar información adicional a sus casos de uso, como scripts de prueba, métricas, etc. Tener esto en un modelo le permitirá crear informes personalizados sobre esta información adicional.
Más allá de eso, diría que si necesitas un diagrama de estado, usa un diagrama de estado UML; si necesita un diagrama de flujo, use un diagrama de actividad UML; Si necesita un gráfico de llamadas, use un diagrama de secuencia UML. En cada caso, la notación UML se entenderá más ampliamente que cualquier notación ad hoc que invente por su cuenta.
Pero el mensaje general es, para utilizar cualquier herramienta que tenga a mano para facilitar su trabajo.
Uso los siguientes diagramas con más frecuencia:
- Diagramas de clase : para explicar la relación de clase.
- Diagramas de secuencia : para capturar interacciones de objetos
- Diagramas de actividad : Para explicar las actividades (flujo de algoritmos).
EDITAR: Se agregaron enlaces según el comentario de @ Smith325.
Utilizo los diagramas de clase con bastante frecuencia para documentar el diseño de alto nivel y las relaciones entre las clases más importantes. A menudo utilizo diagramas de transición de estado, pero no lo hago en estilo UML. Raramente uso diagramas de secuencia, encontrando que son difíciles de leer (y escribir).
Utilizo los diagramas de transición de estado para modelar la complejidad de, bueno, los diferentes estados de una aplicación en particular.
Yo no uso ninguno.
Apenas los he visto desde tiempos universitarios y mis proyectos de diploma.
Tener una impresión, principalmente los estudiantes / prof. Están interesados en estas metodologías, el mundo de la práctica vive felizmente sin UML.
Si bien no estoy diciendo que UML no puede traer ningún beneficio.
Nunca, nunca uso cualquier forma de UML para comunicar ideas técnicas. He encontrado que es un medio singularmente inútil para ese propósito. Hemos recorrido un largo camino desde que usamos pinturas rupestres para comunicar ideas entre individuos. Durante algunos milenios ahora, los seres humanos han estado utilizando el lenguaje real, con toda su complejidad, matices y elocuencia, para comunicar todo tipo de conceptos de manera clara y sin ambigüedades. Como especie, hicimos ese cambio importante de representaciones gráficas ambiguas de ideas a un lenguaje no ambiguo por una muy buena razón: la claridad.
Las únicas personas a las que he visto usar UML con gran vigor son personas no técnicas (por lo general, analistas de negocios y gerentes de proyectos), a quienes se les da la impresión errónea de que están realizando una resolución de problemas precisa, cuando en realidad simplemente están produciendo dibujos altamente ambiguos que a menudo significan cosas muy diferentes y conflictivas para las distintas audiencias a las que se les inflige. He visto a usuarios finales, desarrolladores, administradores de bases de datos, analistas de negocios y gerentes de proyectos sentados en torno al mismo conjunto de diagramas, asintiendo entre sí en aparente comprensión y armonía, y solo más tarde se dan cuenta de que cada uno se llevó una comprensión muy diferente de cuál era el problema real, y qué se necesitaba construir para resolverlo.
Seguiré con lo que me ha funcionado bien y con los usuarios finales que he construido más de cuarenta sistemas durante los últimos veinte años:
1) Escribir documentos de definición de problemas no ambiguos en inglés simple (complementado con tablas simples y diagramas relevantes para el problema discreto que se resolverá cuando corresponda).
2) Después de que se haya definido el problema, escriba una especificación técnica separada (también en inglés) que describa una solución propuesta para ese problema bien definido en términos que los usuarios finales reales puedan entender.
3) Finalmente, codifique una solución que cumpla con la definición del problema y la especificación técnica propuesta producida en los pasos 1 y 2 anteriores, ajustando la solución para cumplir con la realidad cuando sea apropiado (los pasos 2 y 3 a menudo se superponen, uno de ellos se alimenta al otro) .
Siento pena por las personas que honestamente creen que pueden omitir el paso 1 (definición del problema) * anterior, y de algún modo, saltar mágicamente directamente al paso 2, intentando describir una solución a un problema mal entendido y de escaso alcance, lo que agrava su dificultad al usar un medio torpe como UML que es intrínsecamente ambiguo y está sujeto a una interpretación errónea generalizada entre las distintas partes en el proceso. Así miente la locura.
- Peor aún, cuando le indica a los evangelistas no técnicos de UML que no han definido el problema antes de intentar describir una solución propuesta, por lo general le señalan una carga de "casos de uso" y diagramas con pequeñas figuras de palo que Me gusta llamar "actores", y no apreciamos por completo que esos aspectos de lo que han producido son, en el mejor de los casos, simplemente descripciones incompletas de una posible solución, y no representan en modo alguno una definición abstracta de un problema. Por ejemplo, el caso de uso "Bob presiona el pedal del acelerador y el automóvil va más rápido" es una descripción parcial de una solución potencial (un automóvil), que es en sí misma una única solución posible (y, quizás, no la más pertinente). ) al problema subyacente real que ''Bob necesita obtener de A a B''. Si también sabe que Bob 1) no puede conducir, 2) en cualquier caso, vive en un bote, lo que en realidad solo le dirá una definición completa del problema, ese caso de uso sobre el pedal comienza a parecer bastante irrelevante. ¿No es así?
Someteré a votación los diagramas de casos de uso, ya que se trata del único tipo de diagrama UML que los usuarios / clientes pueden entender y encontrar relevante para sus necesidades.
- Diagramas de casos de uso : para capturar unos requisitos de comportamiento
- Diagramas de secuencia : para capturar interacciones de objetos.
muy poco o ningún uso en absoluto de cualquier otra cosa