Quiero representar la lógica de mi programa a través de un diagrama, ya que el programa es bastante complejo; Necesito una forma de explicarle a otra persona, por qué y cómo sucede algo en mi programa. ¿Es el diagrama de flujo la única opción?Representación visual de Program Logic
Si necesita explicar las cosas paso a paso, sí, un diagrama de flujo es realmente lo que necesita. Si puede hablar a un nivel superior, otra opción puede ser un diagrama de estado.
diagramas de flujo son una opción popular, ya menudo adecuados para personas sin conocimientos técnicos.
Si está interesado en proporcionar una visión más técnica de la situación, UML puede ser una mejor opción.
A sequence diagram muestra cómo los componentes interactúan entre sí.
En UML, diferentes diagramas están pensados para diferentes cosas, utilizando diferentes metodologías. Teniendo en cuenta que tendemos a apoyarnos en las Metodologías Orientadas a Objetos, explicaré los diferentes diagramas y cómo funcionan.
caso de uso Diagrama - El punto de modelos de casos de uso es identificar y definir todos los procesos de negocio elementales que el sistema debe soportar. Esto es desde el punto de vista del usuario y del sistema. Cualquier acción individual dentro de su sistema se puede usar en un caso de uso, que luego permitirá el uso de más modelos explicativos.
Diagrama de actividades - Este es un tipo de diagrama de flujo de trabajo utilizado para describir lo que sucede en un diagrama de casos de uso. Básicamente es un método visual para describir el flujo de una actividad o múltiples actividades.
Diagrama de secuencia - Este es un diagrama para mostrar la comunicación entre diferentes objetos en un sistema, o un proceso. Los diagramas de secuencia son importantes en el análisis, ya que se vuelven cruciales para el diseño detallado del sistema y el diseño de la interfaz del usuario. Realmente me gustan, ya que ofrecen una vista fantástica de lo que está sucediendo en el sistema.
Diagrama de máquina de estado - Esto le permite rastrear los estados de los objetos a lo largo de su vida útil, lo que proporciona una gran idea de cómo deben funcionar los objetos. Esto le da la capacidad de cómo mapear eventos y similares de manera efectiva en el sistema.
Utilizando los diagramas mencionados anteriormente conduce a una gran base para el análisis y diseño, y hay que señalar que una vez que se crean estos diagramas, no son necesariamente completa. En los procesos de diseño, alterará estos diagramas a medida que el sistema evolucione. Espero que esto te ayude. A continuación hay enlaces a wikipedia para los diferentes diagramas mencionados.
Detrás de cada programa es un dominio del problema, en el que, presumiblemente, un conjunto de problemas que se entiende bien por un grupo de dominio de conocimientos personas, y un dominio de solución, en el cual los métodos para resolver tales problemas se recopilan y se usan para manejar los problemas.
Para explicar algo, primero tiene que ponerse de acuerdo en el dominio del problema. Si el dominio problemático es el procesamiento de la señal y la explicación está dirigida a alguien que no está familiarizado con el dominio, ya estás listo.
Luego debe explicar el dominio de la solución (o remitir a un conjunto de soluciones bien conocido como podría encontrar en un manual de ingeniería), para que pueda justificar una elección particular de solución adecuada para este problema en particular y otras restricciones que se pueden colocar en la respuesta (se ejecuta en una máquina pequeña, se puede construir en un día, etc.). Si la persona a la que le está explicando algo no comprende una Transformación Rápida de Fourier como una posible solución a un problema en el dominio de procesamiento de señal elegido, no podrá expandir la solución y mucho menos que sea lo mejor de su elecciones.
Una vez que pase estos dos obstáculos, luego tal vez un diagrama de flujo pueda ser útil. Otras muletas, como varios tipos de diagramas UML, tienen que ver con explicar la estructura de la solución desde varias perspectivas. La perspectiva que importa depende de cuál sea el propósito de la explicación.
En cuanto a los diagramas de flujo: si bien fueron populares una vez, para describir algoritmos, el código de psuedo es generalmente lo suficientemente bueno. Las personas que no pueden seguir el código de psuedo tampoco es probable que sigan un gran diagrama de flujo. Y si su diagrama de flujo es trivial, no lo necesita. No he usado uno en serio en 20 años. La mayor parte de la literatura de ciencias de la computación tampoco parece usarla.
Habiendo dicho esto, cuando uno quiere entender con gran detalle lo que está haciendo una pieza de código real, especialmente para el análisis automatizado de programas, los diagramas de flujo (bajo el nombre más elegante "flujo de control") siguen siendo bastante útiles . Ver a COBOL control flow graph (y ver this for an explanation). Debería ser obvio que no quiere usar esto para explicar un algoritmo a otra persona.
También hay diagramas de casos de uso. Pero basado en la pregunta, estoy de acuerdo, los diagramas de flujo serían mi primera opción. – TrueWill