UML2 ofrece diferentes tipos de diagramas. Hasta ahora solo usaba diagramas de clase.¿Qué tipo de diagramas UML usas?
¿Qué tipo de diagramas UML usas? ¿Qué tipos de diagramas se recomiendan para el diseño & documentación de un proyecto de software?
utilizo siguientes diagramas con mayor frecuencia:
EDITAR: Agregó enlaces según el comentario de @ Smith325.
Pondré un voto para los diagramas de casos de uso, ya que estos son sobre el único tipo de diagrama UML que los usuarios/clientes pueden realmente entender y encontrar relevante para sus necesidades.
No estoy del todo de acuerdo. Desarrollo casos de uso, pero la parte importante es la descripción de todos los casos de uso, más que el diagrama en sí. –
Obviamente, pero la pregunta era sobre diagramas. Y los diagramas de casos de uso son un buen gancho para colgar las discusiones de análisis. –
Los diagramas de secuencia son el tipo primario para mí, muy poco uso de algo más realmente.
¡Muy buen sitio! – bobobobo
que a menudo utilizan algún tipo de diagrama de despliegue cuando se modela el sistema (aunque, admittely, que tienden a utilizar cosas no UML en mis diagramas también)
venir a stackover-flow y unirse a la sala de chat de UML – Model
muy poco o ningún uso en absoluto de nada
Uso diagramas de transición de estado para modelar la complejidad de, bueno, los diferentes estados de una aplicación en particular.
Quizás sería mejor preguntar ¿qué beneficio práctico obtengo del uso de UML?
Cualquier mecanismo de diagramación junto con una narración clara pueden utilizarse para transmitir cualquier idea. Simplemente hágalo legible, claro y lógico, y debería ayudar a ser autoexplicativo.
El beneficio práctico de los diagramas UML es un lenguaje común. Claro, se puede usar cualquier mecanismo de diagramación pero luego tienes que pasar diez minutos explicando tu notación y cualquier matiz cada vez que se lo muestres a alguien nuevo. Además, lo que es una narración clara para el autor pocas veces es claro para otros. – Dunk
No es un lenguaje común. Criado por Jeff Atwood, el único, si es posible decir tal cosa entre usuarios y programadores, es el inglés. Grupos externos a los desarrolladores, tus usuarios no entienden UML. La única documentación verdadera de su sistema es el código. Más traducciones intermedias –
Entre el código (la implementación) y lo que sus usuarios entienden es superfluo e innecesario. La fuente de la verdad para tu calcetín debe ser INS solo jerga que todos entiendan - Inglés. ¿De verdad mantiene su clase y otros diagramas actualizados? La mayoría de las veces no son ... –
No uso ninguno.
Apenas las he visto desde la universidad y mis proyectos de diploma.
Tenga una impresión, principalmente los estudiantes/profs 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.
Entonces, ¿usa algo en su lugar? –
Nada. Solía usar PowerDesigner para el modelado de bases de datos, pero cuando SQL 2008 estaba fuera y no había actualizaciones para PD, lo descarté. Parece que no necesito nada para mi proyecto privado ni la empresa donde trabajo necesita nada para nuestra aplicación empresarial. – User
Estoy en el mismo barco. Yo no uso ninguno Cuando necesito algunos diagramas, dibujo algo en papel sin obedecer UML ni nada. Solo algunos cuadros y flechas que los conectan de la manera que quiero expresar en este momento –
Utilizo diagramas de clase bastante a menudo para documentar el diseño de alto nivel y las relaciones entre las clases más importantes. A menudo uso diagramas de transición de estado, pero no en estilo UML. Raramente utilizo diagramas de secuencia, encontrándolos difíciles de leer (y escribir).
Todos se pueden utilizar para el diseño y la documentación de un proyecto. Esto es muy abierto a la interpretación.
Va a depender del proyecto y para quién está creando la documentación. En algunos casos, UML es inútil, pero puede ayudarlo a crear un diagrama no UML más simple 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 para la comunicación. Si te vuelves demasiado religioso con tu uso de UML, no estás 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 efímeros en una pizarra.
Yo uso diagramas de clase para ilustrar cómo las clases se relacionan entre sí. Yo 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 a través de una lógica de programa enredada, aunque a menudo voy a refactorizar el código para obtener esa comprensión.
No me gustan los diagramas de casos de uso. El diagrama realmente no muestra mucho, creo que una lista con viñetas con descripciones es mucho más útil, si no completas descripciones de casos con escenarios, condiciones de falla, etc.
Los diagramas de clases son útiles, aunque nunca puse todos los detalles en ellos. Obtener las conexiones entre los objetos del dominio y cómo encaja todo parece ser más útil que recorrer y completar los comportamientos y los campos.
Los diagramas de secuencia son geniales si está tratando de descubrir el flujo de algo que se está volviendo un poco complicado y tiene problemas para visualizar lo que está sucediendo.
Los diagramas de clases, diagramas de secuencia y diagramas de estados también son geniales para tratar de descubrir qué hace el código existente.
No me preocupo por las formalidades en mis diagramas; son bocetos en una pizarra.
Los diagramas de casos de uso no proporcionan ningún detalle, pero no he visto una mejor manera de proporcionar rápidamente una descripción general de todos los casos de uso en el sistema.
Los diagramas de clases 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. Por lo tanto, los diagramas terminan siendo poco útiles.
Los diagramas de secuencia son indispensables. Las herramientas no admiten el uso útil de 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 mis operaciones de paquete, 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, así que generalmente termino dibujando mi propio diagrama usando Powerpoint o Visio.
No soy muy partidario de los diagramas de estados o actividades. Tuve algunas malas experiencias con los diseños de máquinas estatales de otras personas al principio de mi carrera y así los evité como la peste.
Cuando se trata de presentar a un cliente/gerente, entonces 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, generalmente requieren algún texto narrativo escrito para ser de valor.
Pregúntese lo entienden mis usuarios, soy yo verdaderamente capaz y comprometido a mantener mis diagramas actual y precisa o van a pudrirse y añadir confusión ...
Hágase hace .Net o Java UML entregan en cualquier lugar, parte de su paquete de documentación?
Solo uso el diagrama de casos de uso y el diagrama de implementación solo cuando los encuentro útiles para explicar la funcionalidad y la configuración de implementación, respectivamente.
Un modelo de dominio es indispensable en la mayoría de los proyectos. Le da al personal técnico una comprensión consistente, 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 Word (dependiendo de su herramienta UML elegida, por supuesto) y le recomiendo que siga la ruta UML para documentar tus casos de uso. Su herramienta UML casi seguramente 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 necesita un diagrama de estado, use 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 va a entender más ampliamente que cualquier notación ad hoc que invente por su cuenta.
Pero el mensaje general es utilizar las herramientas que tenga a mano para facilitar su trabajo.
Mi voto personal: Los diagramas de casos diagramas de secuencia diagramas de clases
con el ocasional actividad, complementaria Diagrama.
Pero creo que el kilometraje varía. Normalmente trabajo en sistemas con muchos casos de uso, algunos de los cuales se sirven integrando soluciones comerciales y escribiendo un poco de código. Entonces, para mí, los casos de uso a menudo son la parte más relevante de UML, con un diagrama de componentes ocasionales.
Secuencia y clase han sido los diagramas de facto para el diseño de software, pero los he visto usar muy mal. Es fácil caer en un patrón de diseño de diagramas de cortador de galletas con estos, y no perforar realmente en un diagrama que muestra los aspectos de diseño realmente críticos del sistema.
Me encanta UML por su capacidad para proporcionar una sintaxis clara y estandarizada para explicar los problemas de diseño de manera consistente. Pero odio que a veces se considere un "estándar" de desarrollo y no solo una herramienta para el trabajo. Digo usarlos si ayudan a ilustrar a un grupo crítico de personas y omitirlas por completo si sirven ahora con un propósito útil para tomar una decisión técnica.
ven a la sala de chat de stackoverflow y únete al chat de UML – Model
Diagramas de secuencia para ayudarme a hacer un seguimiento de las cosas cuando intento asimilar el código de otras personas.
Nunca utilicé alguna 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 el uso de pinturas rupestres para comunicar ideas entre individuos. Desde hace milenios, los seres humanos han utilizado el lenguaje real, con toda su complejidad, matices y elocuencia, para comunicar todo tipo de conceptos de manera clara e inequívoca. Como especie, hicimos ese cambio importante de representaciones gráficas ambiguas de ideas a un lenguaje inequívoco por una muy buena razón: claridad.
Las únicas personas que he visto usar UML con gran vigor son personas no técnicas (por lo general, analistas de negocios y gerentes de proyecto), a las que erróneamente les da la impresión de que están participando en una resolución de problemas precisa, cuando de hecho están meramente produciendo dibujos altamente ambiguos que a menudo significan cosas muy diferentes y contradictorias para las diversas audiencias sobre las que se inflingen. He visto usuarios finales, desarrolladores, administradores de bases de datos, analistas de negocios y gerentes de proyectos sentados alrededor del mismo conjunto de diagramas, asintiendo con la cabeza 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.
me quedo con lo que ha funcionado bien para mí y para los usuarios finales que he construido más de cuarenta sistemas durante más de los últimos veinte años:
1) Escribir documentos problema de definición inequívoca en la llanura Inglés (complementado con tablas y diagramas simples relevantes para el problema discreto a resolver donde corresponda).
2) Después de que se haya definido el problema, escriba una especificación técnica aparte (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 comprender.
3) Por último, la codificación de una solución que satisfaga tanto la definición del problema y la especificación técnica propuesta producido en los pasos 1 & 2 anteriormente, ajustando la solución para cumplir con la realidad en su caso (pasos 2 & 3 a menudo se superponen, con una alimentación en el otro).
Lo siento por las personas que honestamente creen que pueden omitir el paso 1 (definición del problema) * arriba, y de alguna manera mágicamente pasar directamente al paso 2, tratando de describir una solución a un problema mal entendido y de escaso alcance, componer su dificultad al usar un medio torpe como UML que es intrínsecamente ambiguo y sujeto a interpretaciones erróneas generalizadas entre las diversas partes del proceso. De esa manera, la locura miente.
http://stackoverflow.com/questions/104638/do-you-still-use-uml-how-what-for http://stackoverflow.com/questions/18803/is-uml-practical – dkretz
Le dorfier esos 2 no son la misma pregunta – bobobobo