Diagrama de Flujo

Un diagrama de flujo es una forma de representar gráficamente los detalles algorítmicos de un proceso multifactorial. Se utiliza principalmente en programación, economía y procesos industriales, pasando también a partir de estas disciplinas a formar parte fundamental de otras, como la psicología cognitiva. Estos diagramas utilizan una serie de símbolos con significados especiales y son la representación gráfica de los pasos de un proceso. En computación, son modelos tecnológicos utilizados para comprender los rudimentos de la programación lineal.

Definición

Es la representación gráfica de flujo de un algoritmo o de secuencia rutinarias. Se basan en la utilización de diversos símbolos para representar operaciones específicas. Se les llama diagramas de flujo porque los símbolos utilizados se conectan por medio de flechas para indicar la secuencia de la operación.

Símbolos utilizados

Los símbolos que se utilizan para diseño se someten a una normalización, es decir, se hicieron símbolos casi universales, ya que, en un principio cada usuario podría tener sus propios símbolos para representar sus procesos en forma de Diagrama de flujo. Esto trajo como consecuencia que sólo aquel que conocía sus símbolos, los podía interpretar. La simbología utilizada para la elaboración de diagramas de flujo es variable y debe ajustarse a las normas preestablecidas universalmente para dichos símbolos o datos.

Características que debe cumplir un diagrama de flujo [

En los diagramas de flujo se presuponen los siguientes aspectos:

• Existe siempre un camino que permite llegar a una solución (finalización del algoritmo).
• Existe un único inicio del proceso.
• Existe un único punto de fin para el proceso de flujo (salvo del rombo que indica una comparación con dos caminos posibles).

Desarrollo del Diagrama de Flujo

Las siguientes son acciones previas a la realización del diagrama de flujo:

• Identificar las ideas principales a ser incluidas en el diagrama de flujo. Deben estar presentes el dueño o responsable del proceso, los dueños o responsables del proceso anterior y posterior y de otros procesos interrelacionados, otras partes interesadas.
• Definir qué se espera obtener del diagrama de flujo.
• Identificar quién lo empleará y cómo.
• Establecer el nivel de detalle requerido.
• Determinar los límites del proceso a describir.

Los pasos a seguir para construir el diagrama de flujo son :

• Establecer el alcance del proceso a describir. De esta manera quedará fijado el comienzo y el final del diagrama. Frecuentemente el comienzo es la salida del proceso previo y el final la entrada al proceso siguiente.
• Identificar y listar las principales actividades/subprocesos que están incluidos en el proceso a describir y su orden cronológico.
• Si el nivel de detalle definido incluye actividades menores, listarlas también.
• Identificar y listar los puntos de decisión.
• Construir el diagrama respetando la secuencia cronológica y asignando los correspondientes símbolos.
• Asignar un título al diagrama y verificar que esté completo y describa con exactitud el proceso elegido.

Recomendaciones

A su vez, es importante que al construir diagramas de flujo, se observen las siguientes recomendaciones:

• Evitar sumideros infinitos, burbujas que tienen entradas pero no salidas.
• Evitar las burbujas de generación espontánea, que tienen salidas sin tener entradas, porque son sumamente sospechosas y generalmente incorrectas.

n flujo o un proceso porque simplemente no se le ocurre algún nombre razonable.

Ventajas de los diagrama de flujo

• Favorecen la comprensión del proceso a través de mostrarlo como un dibujo. El cerebro humano reconoce fácilmente los dibujos. Un buen diagrama de flujo reemplaza varias páginas de texto.
• Permiten identificar los problemas y las oportunidades de mejora del proceso. Se identifican los pasos redundantes, los flujos de los re-procesos , los conflictos de autoridad, las responsabilidades, los cuellos de botella, y los puntos de decisión.
• Muestran las interfaces cliente-proveedor y las transacciones que en ellas se realizan, facilitando a los empleados el análisis de las mismas.
• Son una excelente herramienta para capacitar a los nuevos empleados y también a los que desarrollan la tarea, cuando se realizan mejoras en el proceso.

Tipos de diagramas de flujos

• Formato vertical: En él el flujo o la secuencia de las operaciones, va de arriba hacia abajo. Es una lista ordenada de las operaciones de un proceso con toda la información que se considere necesaria, según su propósito.

• Formato horizontal: En él, el flujo o la secuencia de las operaciones, va de izquierda a derecha.

• Formato panorámico: El proceso entero está representado en una sola carta y puede apreciarse de una sola mirada mucho más rápido que leyendo el texto, lo que facilita su comprensión, aun para personas no familiarizadas. Registra no solo en línea vertical, sino también horizontal, distintas acciones simultáneas y la participación de más de un puesto o departamento que el formato vertical no registra.

• Formato Arquitectónico: Describe el itinerario de ruta de una forma o persona sobre el plano arquitectónico del área de trabajo. El primero de los flujogramas es eminentemente descriptivo, mientras que los utilizados son fundamentalmente representativos.

Diagrama de Colaboracion

Este diagrama de UML 1 es esencialmente un diagrama que muestra interacciones organizadas alrededor de los roles. A diferencia de los diagramas de secuencia, los diagramas de comunicación muestran explícitamente las relaciones de los roles. Por otra parte, un diagrama de comunicación no muestra el tiempo como una dimensión aparte, por lo que resulta necesario etiquetar con números de secuencia tanto la secuencia de mensajes como los hilos concurrentes.

• Muestra cómo las instancias específicas de las clases trabajan juntas para conseguir un objetivo común.
• Implementa las asociaciones del diagrama de clases mediante el paso de mensajes de un objeto a otro. Dicha implementación es llamada "enlace".

Un diagrama de comunicación es también un diagrama de clases que contiene roles de clasificador y roles de asociación en lugar de sólo clasificadores y asociaciones. Los roles de clasificador y los de asociación describen la configuración de los objetos y de los enlaces que pueden ocurrir cuando se ejecuta una instancia de la comunicación. Cuando se instancia una comunicación, los objetos están ligados a los roles de clasificador y los enlaces a los roles de asociación. El rol de asociación puede ser desempeñado por varios tipos de enlaces temporales, tales como argumentos de procedimiento o variables locales del procedimiento. Los símbolos de enlace pueden llevar estereotipos para indicar enlaces temporales.

Usos

Un uso de un diagrama de comunicación es mostrar la implementación de una operación. La comunicación muestra los parámetros y las variables locales de la operación, así como asociaciones más permanentes. Cuando se implementa el comportamiento, la secuencia de los mensajes corresponde a la estructura de llamadas anidadas y el paso de señales del programa.

Un diagrama de secuencia muestra secuencias en el tiempo como dimensión geométrica, pero las relaciones son implícitas. Un diagrama de comunicación muestra relaciones entre roles geométricamente y relaciona los mensajes con las relaciones, pero las secuencias temporales están menos claras.

Tipos

Es útil marcar los objetos en cuatro grupos: los que existen con la interacción entera; los creados durante la interacción (restricción {new}); los destruidos durante la interacción (restricción {destroyed}); y los que se crean y se destruyen durante la interacción (restricción {transient}).

Aunque las comunicaciones muestran directamente la implementación de una operación, pueden también mostrar la realización de una clase entera. En este uso, muestran el contexto necesario para implementar todas las operaciones de una clase. Esto permite que el modelador vea los roles múltiples que los objetos pueden desempeñar en varias operaciones.

Mensajes

Los mensajes se muestran como flechas etiquetadas unidas a los enlaces. Cada mensaje tiene un número de secuencia, una lista opcional de mensajes precedentes, una condición opcional de guarda, un nombre y una lista de argumentos y un nombre de valor de retorno opcional. El nombre de serie incluye el nombre (opcional) de un hilo. Todos los mensajes del mismo hilo se ordenan secuencialmente. Los mensajes de diversos hilos son concurrentes a menos que haya una dependencia secuencial explícita.

Flujos

Generalmente, un diagrama de comunicación contiene un símbolo para un objeto durante una operación completa. Sin embargo, a veces, un objeto contiene diferentes estados que se deban hacer explícitos. Por ejemplo, un objeto pudo cambiar de localización o sus asociaciones pudieron diferenciarse.

Los diferentes símbolos de objeto que representan un objeto se pueden conectar usando flujos "become" o "conversion". Un flujo "become" es una transición, a partir de un estado de un objeto a otro. Se dibuja como una flecha de línea discontinua con el estereotipo "become" o "conversión" y puede ser etiquetado con un número de serie para mostrar cuando ocurre. Un flujo de conversión también se utiliza para mostrar la migración de un objeto a partir de una localización a otra distinta para otro lugar.

Diagrama de Despliegue

El Diagrama de Despliegue es un tipo de diagrama del Lenguaje Unificado de Modelado

que se utiliza para modelar el hardware utilizado en las implementaciones de sistemas y las relaciones entre sus componentes.

Los elementos usados por este tipo de diagrama son nodos (representados como un prisma), componentes (representados como una caja rectangular con dos protuberancias del lado izquierdo) y asociaciones.

En el UML 2.0 los componentes ya no están dentro de nodos. En cambio, puede haber artefactos u otros nodos dentro de un nodo.

Un artefacto puede ser algo como un archivo, un programa, una biblioteca, o una base de datos construida o modificada en un proyecto. Estos artefactos implementan colecciones de componentes. Los nodos internos indican ambientes, un concepto más amplio que el hardware propiamente dicho, ya que un ambiente puede incluir al lenguaje de programación, a un sistema operativo, un ordenador o un cluster de terminales.

La mayoría de las veces el modelado de la vista de despliegue implica modelar la topología del hardware sobre el que se ejecuta el sistema. Aunque UML no es un lenguaje de especificación hardware de propósito general, se ha diseñado para modelar muchos de los aspectos hardware de un sistema a un nivel suficiente para que un ingeniero software pueda especificar la plataforma sobre la que se ejecuta el software del sistema.

Algunos de los usos que se les da a los diagramas de despliegue son para modelar:

• Sistemas empotrados: Un sistema empotrado es una colección de hardware con una gran cantidad de software que interactúa con el mundo físico.
• Sistemas cliente-servidor: Los sistemas cliente-servidor son un extremo del espectro de los sistemas distribuidos y requieren tomar decisiones sobre la conectividad de red de los clientes a los servidores y sobre la distribución física de los componentes software del sistema a través de nodos.
• Sistemas completamente distribuidos: En el otro extremo encontramos aquellos sistemas que son ampliamente o totalmente distribuidos y que normalmente incluyen varios niveles de servidores. Tales sistemas contienen a menudo varias versiones de componentes software, alguno de los cuales pueden incluso migrar de un nodo a otro. El diseño de tales sistemas requiere tomar decisiones que permitan un cambio continuo de la topología del sistema.

Diagrama de Secuencia

diagrama de secuencia es uno de los diagramas más efectivos para modelar interacción entre objetos en un sistema. Un diagrama de secuencia muestra la interacción de un conjunto de objetos en una aplicación a través del tiempo y se modela para cada método de la clase. Mientras que el diagrama de casos de uso permite el modelado de una vista business del escenario, el diagrama de secuencia contiene detalles de implementación del escenario, incluyendo los objetos y clases que se usan para implementar el escenario, y mensajes intercambiados entre los objetos. Típicamente uno examina la descripción de un caso de uso para determinar qué objetos son necesarios para la implementación del escenario. Si tienes modelada la descripción de cada caso de uso como una secuencia de varios pasos, entonces puedes "caminar sobre" esos pasos para descubrir qué objetos son necesarios para que se puedan seguir los pasos. Un diagrama de secuencia muestra los objetos que intervienen en el escenario con líneas discontinuas verticales, y los mensajes pasados entre los objetos como flechas horizontales.

Ejemplo de Diagrama de Secuencia

Existen dos tipos de mensajes: síncronos y asíncronos. Los mensajes síncronos se corresponden con llamadas a métodos del objeto que recibe el mensaje. El objeto que envía el mensaje queda bloqueado hasta que termina la llamada. Este tipo de mensajes se representan con flechas con la cabeza llena. Los mensajes asíncronos terminan inmediatamente, y crean un nuevo hilo de ejecución dentro de la secuencia. Se representan con flechas con la cabeza abierta.

También se representa la respuesta a un mensaje con una flecha discontinua.

Los mensajes se dibujan cronológicamente desde la parte superior del diagrama a la parte inferior; la distribución horizontal de los objetos es arbitraria. Durante el análisis inicial, el modelador típicamente coloca el nombre 'business' de un mensaje en la línea del mensaje. Más tarde, durante el diseño, el nombre 'business' es reemplazado con el nombre del método que está siendo llamado por un objeto en el otro. El método llamado, o invocado, pertenece a la definición de la clase instanciada por el objeto en la recepción final del mensaje.

Diagrama de Estados

Grafo dirigido

Una forma clásica de un diagrama de estados para una máquina de estados finitos es un grafo dirigido con los siguientes elementos:

Estados Q: un conjunto finito de vertices representados normalmente por círculos y etiquetados con símbolos designadores únicos o palabras escritas dentro de ellos (Booth (1967) p. 69, Hopcroft y Ullman (1979) p. 16, Sipser (2006) p. 34).

Símbolos de Entrada Σ: una colección finita de "símbolos" de entrada o designadores Σ (Booth, Hopcroft y Ullman, Sipser). Para una Autómata finito (AFD), Máquina de Estados Finitos no Determinista (AFN), Máquina de Estados Finita no Determinista Generalizada (GNFA), o una Máquina de Moore, la entrada está significada en cada arista, normalmente cerca del estado originador. Para una Máquina de Mealy, la entrada y la salida están significados sobre cada arista normalmente separados con una barra "/":

las etiquetas de entrada y salida Mealy sobre cada arista (flecha): "1/0" designa que el símbolo "1" causó el símbolo "0" como salida.

Símbolos de Salida Z: una colección finita de "símbolos" de salida o designadores (Booth, Hopcroft y Ullman, Sipser). Para una Máquina de Mealy, la entrada y la salida están significados en cada arista como puede verse a continuación. Para una Máquina de Moore la salida del estado está escrita normalmente dentro del círculo del estado, separado del designador del estado con una barra "/".

Ejemplo: Si un estado tiene varias salidas el diagrama debe reflejar esto : e.g. "q5/1,0" designa que el estado q5 tiene salidas a=1, b=0. Este designador será escrito dentro del círculo del estado.

La "Función de Salida ω" representa el mapeado ω de símbolos de entrada I x estados Q en símbolos de salida Z (Booth).

Aristas δ: representa las "transiciones" entre dos estados causados por la entrada (identificados sus símbolos dibujados en los "aristas"). Un 'arista' está dibujado normalmente como una flecha dirigda desde el estado presente hacia el siguiente estado. δ representa el mapeado de los símbolos de entrada I x estados Q en los símbolos de salida Z (Booth, Hopcroft y Ullman, Sipser).

Estado inicial qo: (no visto en los ejemplos anteriores). El estado inicial qo está representado normalmente por una "flecha apuntándolo desde ninguna parte" (cf Sipser (2006) p. 34, Hopcroft y Ullman (1979) p. 16). En textos antiguos (e.g. Booth (1969), McCluskey (1965), Hill y Peterson (1974)) el estado inicial no se mostraba y era inferido del texto.

Estado(s) de Aceptación F: Si se usa -- una colección de círculos dobles usados para designar los estados de aceptación(Hopcroft y Ullman, Sipser). A veces la función de el/los estado/s de aceptación se entiende como estado/s"Final/es" (cf Hopcroft y Ullman (1979) Figure 2.15, p. 33).

Ejemplos

Máquinas DFA, NFA, GNFA, o Moore

S₁ y S₂ son estados y S₁ es un estado de aceptación. Cada arista está etiquetado con la entrada.

Máquina de Mealy

S₀, S₁, y S₂ son estados. Cada flecha está etiquetado con "j / k" donde j es la entrada y k es la salida.

Cuadro de estados Harel

Los cuadros de estados(statecharts) Harel (desarrollados en 1987 por David Harel) están ganando en uso amplio dado que una variante ha llegado a ser parte del UML. El tipo de diagrama permite modelar superestados, diagramas de estados concurrentes y e.g. modelar las actividades como parte de un estado.

Los diagramas de estados clásicos son llamados diagramas "or", debido a que la máquina sólo puede estar en un estado o en otro. Con los cuadros de estados Harel es posible modelar máquinas "and", donde una máquina está en dos o más estados al mismo tiempo. Esto es debido a la posibilidad de tener superestados.

Diagrama de estados UML

Diagrama de Estados UML de Ejemplo.

Lenguaje Unificado de Modelado (UML) especifica una notación estandarizada para diagramas de estado que puede utilizarse para describir clases, sistemas, subsistemas o incluso procesos de negocio. Los elementos básicos de notación que pueden usarse para componer un diagrama son:

• Círculo lleno, apuntando a un estado inicial
• Círculo hueco que contiene un círculo lleno más pequeño en el interior, indicando el estado final (si existiera)
• Rectángulo redondeado, denotando un estado. En la parte superior del rectángulo está el nombre del estado. Puede contener una línea horizontal en la mitad, debajo de la cual se indican las actividades que se hacen en el estado
• Flecha, denotando transición. El nombre del evento (si existiera) que causa esta transición etiqueta el cuerpo de la flecha. Se puede añadir una expresión de Guarda, encerrada en corchetes( [] ) denotando que esta expresión debe ser cierta para que la transición tenga lugar. Si se realiza una acción durante la transición, se añade a la etiqueta después de "/". NombreDeEvento[ExpresiónGuarda]/acción
• Línea horizontal gruesa con x>1 líneas entrando y 1 línea saliendo o 1 línea entrando y x>1 líneas saliendo. Estas denotan Unión/Separación, respectivamente.

Diagrama de Clases

Un DIAGRAMA DE CLASES es un tipo de diagrama estático que describe la estructura de un sistema mostrando sus clases, atributos y las relaciones entre ellos. Los diagramas de clases son utilizados durante el proceso de análisis y diseño de los sistemas, donde se crea el diseño conceptual de la información que se manejará en el sistema, y los componentes que se encargaran del funcionamiento y la relación entre uno y otro.

• Propiedades también llamados atributos o características, son valores que corresponden a un objeto, como color, material, cantidad, ubicación. Generalmente se conoce como la información detallada del objeto. Suponiendo que el objeto es una puerta, sus propiedades serían: la marca, tamaño, color y peso.

• Operaciones son aquellas actividades o verbos que se pueden realizar con/para este objeto, como por ejemplo abrir, cerrar, buscar, cancelar, acreditar, cargar. De la misma manera que el nombre de un atributo, el nombre de una operación se escribe con minúsculas si consta de una sola palabra. Si el nombre contiene más de una palabra, cada palabra será unida a la anterior y comenzará con una letra mayúscula, a excepción de la primera palabra que comenzará en minúscula. Por ejemplo: abrirPuerta, cerrarPuerta, buscarPuerta, etc.

• Interfaz es un conjunto de operaciones y/o propiedades que permiten a un objeto comportarse de cierta manera, por lo que define los requerimientos mínimos del objeto.

• Herencia se define como la reutilización de un objeto padre ya definido para poder extender la funcionalidad en un objeto hijo. Los objetos hijos heredan todas las operaciones y/o propiedades de un objeto padre. Por ejemplo: Una persona puede subdividirse en Proveedores, Acreedores, Clientes, Accionistas, Empleados; todos comparten datos básicos como una persona, pero además tendrá información adicional que depende del tipo de persona, como saldo del cliente, total de inversión del accionista, salario del empleado, etc.

Al diseñar una clase se debe pensar en cómo se puede identificar un objeto real, como una persona, un transporte, un documento o un paquete. Estos ejemplos de clases de objetos reales, es sobre lo que un sistema se diseña. Durante el proceso del diseño de las clases se toman las propiedades que identifican como único al objeto y otras propiedades adicionales como datos que corresponden al objeto. Con los siguientes ejemplos se definen tres objetos que se incluyen en un diagrama de clases:

Ejemplo 1: Una persona tiene número de documento de identificación, nombres, apellidos, fecha de nacimiento, género, dirección postal, posiblemente también tenga número de teléfono de casa, del móvil, FAX y correo electrónico.

Ejemplo 2: Un sistema informático puede permitir administrar la cuenta bancaria de una persona, por lo que tendrá un número de cuenta, número de identificación del propietario de la cuenta, saldo actual, moneda en la que se maneja la cuenta.

Ejemplo 3: Otro objeto pueden ser "Manejo de Cuenta", dónde las operaciones bancarias de una cuenta (como en el ejemplo 2) se manejarán realizando diferentes operaciones que en el diagrama de clases sólo se representan como operaciones, que pueden ser:

• Abrir
• Cerrar
• Depósito
• Retiro
• Acreditar Intereses

Estos ejemplos constituyen diferentes clases de objetos que tienen propiedades y/u operaciones que contienen un contexto y un dominio, los primeros dos ejemplos son clases de datos y el tercero clase de lógica de negocio, dependiendo de quién diseñe el sistema se pueden unir los datos con las operaciones.

El diagrama de clases incluye mucha más información como la relación entre un objeto y otro, la herencia de propiedades de otro objeto, conjuntos de operaciones/propiedades que son implementadas para una interfaz.