Nota editorial Estimados lectores: la universidad Politécnica Santiago Mariño, sede Valencia Venezuela, tiene el gusto de hacer publica su primera edición de “La revista” referente a los Diagramas de Estados, dedicado a esas personas que buscan mejores forma de comprensión para plasmar sus ideas en proyectos y otras áreas. Este tema aporta gran ayuda a nivel descriptivo a varios objetos en ocasiones difíciles, los estados son las diferentes combinaciones de información que se puede tener de un objeto y no como se comportan, generalmente este empieza con un circulo ósculo que indica el estado inicial y termina con un circulo blanco que denota el estado final. No obstante, ofrecemos estas páginas, cuya lectura deseamos despierte su interés, con la finalidad de ayudar a nuestros lectores en las fases de un proyecto. Angel Aponte Estudiante de Ingeniería de Sistemas Santiago Mariño
¿Que es un diagrama de estado y en que nos ayuda? Es una manera para caracterizar un cambio en un sistema, es decir que los objetos que lo componen modificaron su estado como respuesta a los sucesos y al tiempo. Los diagramas de estado en el caso de los autómatas finitos, además de mejorar su legibilidad, comprensión, e incluso visualizar una especie de primera aproximación material a su implementación física o computacional; también ayudan a visibilizar las propiedades del AF más intuitivamente que en la notaciones de la 5-tupla o la de la tabla de transiciones.
¿Cuales son sus elementos? • Estado compuesto - un estado que contiene subestados anidados. • Pseudoestado de opción - un símbolo de diamante que indica una condición dinámica con resultados potenciales ramificados. • Punto de salida - el punto en el cual se sale de un estado compuesto o de una máquina de estados. Se representa con un círculo con una X en su interior.
• Evento - una instancia que activa una transición. Se etiqueta con nombre arriba de la flecha de transición aplicable. • Estado final - un marcador para el primer estado del proceso. Se muestra mediante un círculo oscuro con una flecha de transición. • Protección - una condición booleana que permite o detiene una transición. Se escribe arriba de la flecha de transición. • Estado - un rectángulo redondeado que indica la naturaleza actual de un objeto. • Subestado - un estado contenido dentro de la región de un estado compuesto. • Transición - una flecha que corre de un estado a otro que indica un estado cambiante. • Comportamiento transicional - un tipo de comportamiento resultante que ocurre durante la transición de un estado. Se escribe arriba de la flecha de transición. • Disparador - un tipo de mensaje que mueve activamente un objeto de estado en estado. Se escribe arriba de la flecha de transición.
Tipos de diagramas de estados y su origen Existen muchas formas de diagramas de estado, cada una con semántica ligeramente diferente. La mas popular que se emplea en las técnicas de OO se basa en la tabla de estados de David Harel (Vol. 8). OMT fue quien la uso por primera vez para los métodos de OO y fue adoptada por Grady Booch en su segunda edición (1994). El estado en el que se encuentra un objeto determina su comportamiento. Cada objeto sigue el comportamiento descrito en el Diagrama de Estados asociado a su clase. Los Diagramas de Estados y escenarios son complementarios, los Diagramas de Estados son autómatas jerárquicos que permiten expresar concurrencia, sincronización y jerarquías de objetos, son grafos dirigidos y deterministas. La transición entre estados es instantánea y se debe a la ocurrencia de un evento. Diagramas de estados concurrentes Además de los estados de un pedido que se basan en la disponibilidad de los artículos, también existen estados que se basan en la autorización de pagos. Si vemos estos estados, podríamos ver un diagrama de estados como el de la figura 4
Tipos de Diagramas Diagrama de casos de uso Los Casos de Uso no forma parte de la llamada Fase de Diseño, sino parte de la fase de Análisis, respondiendo el interrogante ¿Qué?. De forma que al ser parte del análisis ayuda a describir que es lo que el sistema debe hacer. Estos diagramas muestran operaciones que se esperan de una aplicación o sistema y como se relaciona con su entorno, es por ello que se ve desde el punto de vista del usuario. Describen un uso del sistema y como éste interactúa con el usuario. Diagramas de clases En UML el diagrama de clases es uno de los tipos de diagramas o símbolo estático y tiene como fin describir la estructura de un sistema mostrando sus clases, atributos y relaciones entre ellos. Estos diagramas son utilizados durante el proceso de análisis y diseño de los sistemas informáticos, en donde se intentan conformar el diagrama conceptual de la información que se manejará en el sistema. Diagramas de Objetos Forma parte de la vista estática del sistema. En este diagrama se modelan las instancias de la clases del Diagrama de Clases. Este diagrama cabe aclarar que cuenta con objetos y enlaces. En estos diagramas también es posible encontrar las clases para tomar como referencia su instanciación. Diagramas de Actividades Un Diagrama de Actividades representa un flujo de trabajo paso a paso de negocio y operacionales de los componentes en un sistema. Diagramas de secuencias Un Diagrama de Secuencias muestra una interacción ordenada según la secuencia temporal de eventos y el intercambio de mensajes. Los diagramas de secuencia ponen especial énfasis en el orden y el momento en el que se envían los mensajes a los objetos. Diagramas de Componentes Lo que distingue el Diagrama de Componentes de otro tipo de diagramas es sin duda su contenido. Normalmente contiene componentes, interfaces y relaciones entre ellos. Los componentes perteneces a un mundo físico, es decir, representan a un bloque de construcción al modelar aspectos físicos de un sistema. Diagramas de despliegue Básicamente este tipo de diagrama se utiliza para modelar el Hardware utilizado en la implementación del sistema y la relaciones entre sus componentes. Los elementos usados por este tipo de diagrama son nodos, componentes y asociaciones. En el UML 2.0 los componentes ya no están dentro de nodos, en cambio puede haber artefactos (archivo, un programa, una biblioteca o Base de datos) u otros nodos dentro de nodos.
Ejemplos de diagramas El UML estรก compuesto por diversos elementos grรกficos que se combinan para conformar diagramas. Debido a que el UML es un lenguaje, cuenta con reglas para combinar tales elementos. La finalidad de los diagramas es presentar diversas perspectivas de un sistema, a las cuales se les conoce como modelo. Recordemos que un modelo es una representaciรณn simplificada de la realidad; el modelo UML describe lo que supuestamente harรก un sistema, pero no dice cรณmo implementar dicho sistema.
โ ข Diagrama de clase
Ejemplos de diagramas • Diagrama de objetos
• Diagrama de Actividades
Ejemplos de diagramas • Diagramas de secuencias
• Diagrama de componentes
Ejemplo de Diagramas • Diagrama de casos de uso
• Diagrama de despliegues
Pasos a seguir para su construcción de un diagrama de procesos Comenzaremos en el punto de partida y mostramos una transición inicial al estado de Comprobación. Esta transición esta etiquetada como “/obtener el primer articulo”. La sintaxis de una etiqueta de transición tiene tres partes, las cuales son optativas: Evento [Guard guardia] Acción. En este caso solo tenemos la acción "obtiene primer articulo” Una vez realizada tal acción, entramos al estado de comprobación. Este estado tiene una actividad asociada con el, la cual se indica mediante una etiqueta con la sintaxis hace/actividad. En este caso, la actividad se llama “comprueba articulo”.
Nótese que se utiliza los términos “acción” para indicar la transición, y “actividad” para indicar el estado. Aunque son procesos, implementados característicamente mediante algún método sobre Pedido, se tratan de manera diferente. Las acciones se asocian con las transiciones y se consideran como procesos que suceden con rapidez y no son interrumpidles. Las actividades se asocian con los estados y pueden tardar más. Una actividad puede ser interrumpida por algún evento. Adviértase que la definición de “rápidamente” depende del tipo de sistema que se esta produciendo. En un sistema de tiempo real, “rápidamente” puede significar unas pocas líneas de código de maquina; en los sistemas de información normales, “rápidamente” puede significar menos de unos cuantos segundos. Cuando una transición no tiene evento alguno en su etiqueta, significa que la transición se da tan pronto como se completa cualquier actividad asociada con el estado dado. En este caso, ello significa tan pronto termine la Comprobación. Del estado Comprobación se derivan tres transiciones. Las tres solo tienen guardias en su etiqueta. Un guardia es una condición lógica que solo devuelve “verdadero” o “falso” Una transición de guardia ocurre solo si el guardia se resuelve como “verdadero”.
Solo se puede tomar una transición de un estado dato, por lo que tratamos de que los guardias sean mutuamente excluyentes para cualquier evento. En la figura 1 abarcamos tres condiciones: • si no hemos comprobado todos los artículos, tomamos el siguiente artículo y regresamos al estado de comprobación para comprobarlo. • Si hemos comprobado todos los artículos y todos están en existencia, hacemos la transición al estado de Despachando. • si hemos comprobado todos los artículos pero no todos están en existencia, hacemos la transición al estado espera.
Funciones y uso del diagrama de procesos Los diagramas de estados son buenos para describir el comportamiento de un objeto a través de varios casos de uso. No son tan buenos para describir un comportamiento que involucra cierto número de objetos que colaboran entre ellos. Así pues, es útil combinar los diagramas de interacción son buenos para la descripción del comportamiento de varios objetos en un mismo caso de uso. Por su parte, los diagramas de actividades son buenos para mostrar la secuencia general de las acciones de varios objetos y casos de uso. Hay quienes consideran que los diagramas de estado son naturales, pero muchos no los consideran así. Preste atención al modo en que os emplean quienes trabajan con ellos, podría ocurrir que su equipo no considere útiles los diagramas de estado, debido a su modo de trabajar. Esto no seria un gran problema; como siempre, deben combinarse las técnicas que sean de utilidad. Si decide utilizar diagramas de estado, no trate de dibujar uno por cada clase del sistema. Aunque este es el enfoque que emplean los detallistas ceremoniosos, casi siempre es un esfuerzo inútil. Utilice los diagramas de estados solo para aquellas clases que presenten un comportamiento interesante, cuando la construcción de tales diagramas le ayude a comprender lo que sucede. Muchos consideran que los objetos de interfaz de usuario (IU) y de control tienen el tipo de comportamiento que es útil describir mediante diagramas de estado.
Aplicación en la vida real De forma similar a la mayoría de los diagramas UML, los diagramas de estado tienen varios usos diferentes. Las aplicaciones principales son las siguientes: • Representar objetos basados en eventos en un sistema reactivo. Ilustrar escenarios de casos de uso en un contexto de negocios. • Describir cómo se mueve un objeto a través de diversos estados a lo largo de su existencia. • Mostrar el comportamiento general de una máquina de estados o el comportamiento de un conjunto relacionado de máquinas de estados.
Nota de Cierre Los diagramas de estados UML son de gran importancia como lo vimos, pero debemos tener en claro que no es ni un método, ni una metodología, ni un ciclo de vida, ni similar. UML es sólo un lenguaje gráfico (símbolos que cuando los vemos todos interpretamos lo mismo) para representar partes de un sistema de software (diseño, comportamiento, arquitectura, etc.), con diagramas UML. Abajo, un ejemplo (un diagrama sobre una refactorización). Así, por ejemplo, cuando alguien quiere representar una clase, dibuja un cuadrado y todos sabemos a qué se refiere. Cuando dibuja una flecha cuya punta es un triangulo, todos sabemos que es herencia. Y así sucesivamente. Esto tiene su lógica razón de ser: nos vale para comunicarnos e interpretar todos lo mismo al ver esos diagramas UML. Esperamos que esta revista sea de gran agrado de los lectores y esperamos lo antes posible realizar otra publicación sobre temas informáticos. Valencia, 30 de julio de 2018