design - star - Si no diseñas en UML, ¿en qué diseñas?
uml diagrams examples (16)
UML es una herramienta de documentación y no una herramienta de diseño.
Llamaría basura a esa declaración. UML es una notación de diseño comprobada, proporciona una gran cantidad de profundidad en sus diversos diagramas y está estandarizada. Es genial si tienes un gran equipo y necesitas asegurarte de que todos estén en sintonía con las decisiones arquitectónicas.
Supongo que quien hizo esa declaración simplemente está cansado de UML, no entiende cómo usarlo, o ambos.
Me enseñaron a dibujar diagramas en UML para ver las interacciones entre clases, objetos y participantes / el sistema y demás. Sin embargo, he visto varias respuestas aquí que indican que el UML es una herramienta de documentación y no una herramienta de diseño.
¿Cómo se representan los diseños gráficamente si no se usa UML?
Algunas GRANDES palabras sobre ingeniería de software, por Richard Feynman, se pueden encontrar aquí . Realmente una lección para tomar de memoria ...
EDITAR: moví mis divagaciones a continuación ... ¡Mejor para escuchar a Feynman! :)
En mi humilde opinión, hay muchas opciones de diseño mal atendidas por UML.
¡UML está bien cuando no es excesivo! Tal vez algunos bocetos rápidos son el primer paso, refinado más tarde para convertirse en UML completo.
Solo por favor no lea detenidamente la metodología de arriba hacia abajo que UML (tiende a) fomentar demasiado (de nuevo en mi humilde opinión).
Cajas y flechas en papel o pizarra. Todas las cargas de UML sobre ti son exageradas en muchas situaciones, especialmente en las primeras etapas de un diseño.
Por supuesto, hay un nivel, después de algunas iteraciones, cuando comienza a ser útil (e incluso necesario) para documentar las decisiones previas en detalle con un formato estándar.
Comienzo con la pizarra, luego me muevo a GraphViz una vez que el diseño se ha estabilizado. Es fácil compartir la fuente con otros para examinar ideas alternativas o aclarar roles.
Luego puede mantener una copia de la fuente gráfica abierta en su editor y ajustar el diagrama a medida que avanza para mantener actualizados los detalles con su código.
Creo que la mayoría de la gente comienza dibujando diagramas de forma libre que son básicamente UML, pero no tan rígidos ni bien definidos.
Si los diagramas necesitan progresar más allá de esta etapa, se pueden convertir en diagramas UML adecuados que cumplan con todas las reglas.
He visto muy pocas alternativas a los diagramas UML. La mayoría de ellos parecen ser formatos más antiguos, que tienen sucesores directos en UML.
(Por cierto, me niego a escribir siempre "el UML" en las formas de destrucción de frases!)
Leí en alguna parte que la gente bosquejaría con notas post-it, pero no se les permitió escribir nada sobre ellos, y cuando el diseño es tan complejo que no se puede recordar qué post-it no fue qué clase / módulo / característica arquitectónica entonces necesitaría ser simplificado.
Pensé que eso estaba bien. Yo personalmente uso la clase UML-esque y diagramas de secuencia. Real UML es demasiado trabajo, en mi opinión.
Me ha parecido útil pensar en términos de estilos arquitectónicos descritos en libros como este cuando diseñé proyectos.
Mi propia notación extravagante personalizada. cajas de información, ya sean matrices, archivos, etc. Las ideas incompletas para las clases son solo el nombre de la clase con los miembros y los métodos escritos debajo. Trato el hardware a menudo, por lo que el sistema de adquisición de datos que se encuentra en un automóvil sometido a una prueba es solo un lindo dibujo de un automóvil. Duh, simple!
Hay algo parecido a un tenedor de pitch, un prod de la vaca, que indica cuando una cosa provoca otra en la acción o controla su actividad. Las flechas para los flujos de datos, que a veces pasan a través de aros, indican regulación, orientación y redirección de esos datos.
Uso flechas del tipo usado en UML para indicar herencia de clase. Eso es lo único que le robé a UML. (¿Qué usé antes de encontrarme con UML?) Mi experiencia es la electrónica, por lo que mi notación personal probablemente se basa en ver diagramas de bloques de radios y televisores cuando era niño.
Tengo la suerte de que aproximadamente el 90% de mi trabajo es solo, el código fuente está completamente bajo mi mando, y solo les doy a los demás versiones terminadas o de prueba de ejecutables. Si estuviera en una gran corporación, tendría muchas miradas extrañas, ¡como un monstruo de circo!
Por lo general, trato de comenzar con un boceto simplista en una hoja de papel porque a medida que construyo el diseño, descubro que las cosas a menudo están mejor adaptadas en otro lado y escribirlo me ayudará a recordarlo mejor más adelante.
No siempre llené los tipos al principio porque no siempre sé lo que necesito (por ejemplo, un booleano para una casilla de verificación o una enumeración para una casilla de verificación de tres estados).
Después de mi diseño básico, tiendo a implementar las clases y las conexiones, luego realizo los detalles de una clase de tarjeta de índice por clase antes de realizar una implementación real.
Scott Ambler tiene una gran tabla en su sitio web que enumera todos los diagramas utilizados habitualmente en proyectos de software, con enlaces a ejemplos.
Encuentro que los diagramas UML son útiles, pero estoy continuamente molesto por la mentalidad de "todo una caja".
EDITAR: tiendo a alejarme de las herramientas de modelado UML tanto como sea posible, porque el acto de crear un diagrama formal inevitablemente crea presión para ''pulirlo'' hasta que se vea como un producto de calidad (independientemente de cuánto valor haya en el diagrama mismo )
No ayuda que hasta hace poco la mayoría de los editores de UML proporcionaran poca ayuda en la preparación de diagramas, por ejemplo, dibujar una línea recta entre dos cuadros y un ''doblez'' aparece en el medio porque los elementos no son absolutamente horizontales. He visto a los desarrolladores perder horas tratando de hacer que todas las líneas estén horizontales o a 45 grados. Mi editor favorito personal es MagicDraw , pero Enterprise Architect parece ser muy popular, así que también lo uso mucho.
Cuando hago modelado dentro del equipo, utilizo bocetos UML + DFD + interfaz de usuario hasta que todos estén contentos, luego tomo una foto digital y la publico en el sitio web del proyecto. Si resulta muy útil, puede durar lo suficiente como para ser ''formalizado'', pero la mayoría no lo hace.
Tiendo a usar Pen (cil) y Paper. O posiblemente Sticky Notes y Whiteboard, según la complejidad.
Ejemplos ampliados de lo que estoy haciendo en este momento:- Mi diseño de proyecto de trabajo actual se implementa como un diagrama de flujo de trabajo en mi pizarra, con notas adhesivas. Las notas adhesivas representan en qué parte del flujo de trabajo tienen lugar ciertas operaciones y qué interfaces deberían estar involucradas. El sistema comienza en un lado, sigue varios caminos de izquierda a derecha y sale por el otro lado.
- Mi proyecto de juego se ejecuta en GAE, que tiende a empujar uno hacia objetos de datos más interesantes, con cierta duplicación dentro de su modelo por causa del rendimiento (falta de JOIN). Mis diseños para este proyecto suelen incluir un boceto básico de una vista y un esquema de los objetos modelo que se usarán, incluidas sus propiedades, para garantizar que tenga todo lo que necesito. No suelen existir enlaces entre clases, porque no quiero tener que atravesar algunos objetos en ninguna vista, por temor a ser aplastado por el guardián de la cuota de google.
UML es un lenguaje de comunicaciones. Cuando las personas dicen que usan recuadros y flechas en el papel, están usando UML o están usando algo que tienen que explicar a la persona con la que están hablando.
Si solo están hablando consigo mismos, entonces probablemente no deberían estar haciendo diseño: el diseño necesita variedad genética si no va a salir dañado por el cerebro, no me importa qué tan bueno sea el arquitecto.
Un papel y un lápiz
Uso tarjetas CRC: http://en.wikipedia.org/wiki/Class-Responsibility-Collaboration_card
Utilizo bocetos UML-esque rápidos como herramienta de diseño, y luego diagramas UML completos generados a partir del código como documentación. Un diagrama UML completo y preciso como diseño no es realmente posible (al menos no hasta que UML sea un lenguaje de programación completo), así que este me parece el mejor método.
Antes, usaba Excel simple para hacer mis diagramas y flujos de procesos. Muy fácil y sin tonterías. Ahora, usualmente uso herramientas más confiables como Visio, StarUML, Creately y Lucidchart para hacer mis diagramas.