design - resueltos - ¿Qué técnicas de diagramación(no herramientas) usa durante su programación?

método de diagramación por precedencia ejemplos (13)

Qué técnica (s) de diagramación usa durante la programación para ayudarlo a usted u otras personas a entender su programa o diseño. No estoy hablando de la herramienta favorita de una persona , aunque una buena herramienta probable ayuda a una persona en gran medida con la diagramación.

Mi intención en esta pregunta es encontrar las técnicas de diagramación útiles que las personas realmente usan y encontrar otras nuevas para aprender.

¿Utiliza diagramas de flujo, diagramas de flujo de datos, diagramas ER, etc.?

¡La web está llena de recomendaciones! Pero, ¿qué es lo que los programadores, diseñadores y mantenedores de código realmente usan en su trabajo diario ?

Gracias por sus comentarios

¿Qué usamos realmente? Tal vez otras personas realmente crean diagramas formales, pero en su mayor parte solo garabateo burbujas, cajas y líneas en una hoja de papel.

Dibujo versiones bastardizadas de clase UML, diagramas de objeto y secuencia. Mientras trato de ser fiel a la sintaxis, estoy mucho más preocupado por expresar la idea principal detrás de una característica particular. Por lo tanto, redactaré algo, le pediré a un compañero que eche un vistazo y, si parece lo suficientemente claro, podríamos escanearlo y publicarlo en nuestra Wiki.

Entonces, cuando sucede que realmente tenemos algo de tiempo para trabajar en la documentación (y eso casi nunca ), usaré BOUML y redibujaré los garabatos en un diagrama apropiado.

Ahora, ponerlo todo en contexto, estoy trabajando en un equipo relativamente pequeño (5 desarrolladores), haciendo plataformas de configuración de productos y operaciones en Java. Tenemos nuestros dos productos que luego personalizamos a pedido del cliente. Al ser una comunidad unida, con un cambio bajo (cero) durante algunos años, usamos la documentación principalmente como un remanente de nosotros mismos. Y en esta configuración, el enfoque anterior funciona bastante bien.

Haré un diagrama de clase UML para todo lo que estoy diseñando que sea más grande que un par de clases. Al dibujar un diagrama de clases, me tomo un tiempo para pensar en el diseño en lugar de arar directamente en el código y siempre produce un mejor resultado.

Para arquitecturas más grandes y complicadas, encuentro que los diagramas de Secuencia son una buena forma de comunicar el comportamiento, especialmente para sistemas de subprocesos múltiples.

Pizarra para discusiones.

Pluma y papel para un registro menos temporal.

Code stubs para ''Cosas para el impelement''.

Código probado y de trabajo (con extensos comentarios) para la posteridad.

Tengo un diagrama de flujo del producto principal con el que trabajo y desarrollo.

Mi equipo también usa a menudo bocetos de diagramas UML en pizarras blancas mientras diseña piezas nuevas para que las implementemos. Son muy útiles para crear patrones de diseño y modelar la estructura de alto nivel de las clases que se necesitarán. Sin embargo, estos nunca son completos UML soplado ...

Trabajo en un entorno de desarrollo AJAX, y la mayor parte del código de back-end que escribo funciona como un conducto entre una base de datos relacional y la interfaz javascript (interfaz de usuario). Entonces, el ''diagrama'' más usado por decir que uso son los objetos JSON para describir cómo los datos deben pasarse entre la base de datos y la interfaz. Son estructuras de datos simples, universales y fáciles de entender.

Ejemplo:

{"id": row [''id''], "name": row [''name''], "mandatory": row [''mandatory''], "rangeDescription": "This is the Range", "globalRate": row [''global'']}

Uso diagramas de secuencia mucho (dibujados en papel). Encuentro que me brindan una buena representación visual del flujo lógico de llamadas de método e información entre varios sistemas y componentes en nuestras aplicaciones.

Uso lo que sea necesario para la comunicación. Usualmente eso no es nada en absoluto. A veces es una pizarra.

De vez en cuando, uso Sparx Enterprise Architect , que es una herramienta de modelado UML, aunque produce diagonales decentes mientras lo hace. Lo he usado para requisitos, caso de uso, actividad, secuencia, dominio e incluso modelado de clases, y algunas veces algunos diagramas ER de ingeniería inversa. Lo que sea necesario para transmitir el mensaje.

Utilizo ER y diagramas de clase en papel y pizarra para cualquier proyecto que sea más grande que un script de shell.

Diagramas de flujo, solo cuando necesito explicar un proceso a un no programador (o si es un proceso realmente complicado y necesito entenderlo primero).

Mi antiguo jefe solía decir "al tipo le encanta dibujar cosas".

Utilizo diagramas como una forma de entender rápidamente el código heredado. Se necesita algo de trabajo para crear el diagrama, pero siempre paga al final.

Normalmente utilizo diagramas de clase para obtener una idea general. A veces diagramas de secuencia e incluso diagrama de flujo de datos si una pieza de código es extremadamente difícil de entender.

En la fase de diseño utilizo diagramas de clase, y a menudo los diagramas de estado. Los diagramas de estado son perfectos si el comportamiento de clase difiere con su estado.

Utilizo una pizarra para modelar, así que supongo que el "lenguaje de modelado de pizarra" sería mi respuesta.

Debate de nivel muy alto - Diagramas de contexto donde los cuadros pueden representar clases, paquetes o subsistemas.
Diseño de alto nivel: diagramas de secuencia que muestran la interfaz entre subsistemas, aún no hay clases directamente utilizadas, pero pueden estar implícitas a partir de esto.
Diseño detallado - Diagramas de secuencia que están en el nivel de clase.

Si hay un algoritmo complicado para algo como la correlación de flujos de datos múltiples en una nueva secuencia, generalmente usaré un diagrama de flujo para calcular el algoritmo.

Si la solución requiere conocimiento de estado, entonces también se usa un diagrama de estado.

Esos son los que uso más.

Al hacer el diseño de Data Warehouse, dibujo Star Schemas para ver cómo almacenar los datos. Al hacer un diseño de base de datos transaccional utilizo diagramas de relación de entidad para trabajar nuestro almacenamiento de datos.

Al diseñar una interfaz de usuario, simplemente lo esbozo. Una vez que comience a trabajar en algunas partes de la interfaz de usuario y quiera jugar con algunas áreas, haré una plantilla, imprimiré copias y luego la usaré como guía para trabajar en subsecciones. Para esquemas de color, puede ser útil hacer un gráfico usando el gimp y tener capas para cada pieza del diseño y luego jugar con las capas que colorean cada una para encontrar el equilibrio correcto.

Me gustan los diagramas de flujo de datos. Mucho.