DIAGRAMAS

¿QUE ES UN DIAGRAMA DE CLASES?

El Lenguaje Unificado de Modelado (UML, por sus siglas en inglés) puede ayudarte a modelar sistemas de diversas formas. Uno de los tipos más populares en el UML es el diagrama de clases. Popular entre los ingenieros de software para documentar arquitectura de software, los diagramas de clases son un tipo de diagrama de estructura porque describen lo que debe estar presente en el sistema que se está modelando. Sin importar tu nivel de familiaridad con diagramas UML o diagramas de clases, nuestro software UML está diseñado para ser simple y fácil de usar.

El UML se estableció como un modelo estandarizado para describir un enfoque de programación orientada a objetos (POO). Como las clases son los componentes básicos de los objetos, los diagramas de clases son los componentes básicos del UML. Los diversos componentes en un diagrama de clases pueden representar las clases que se programarán en realidad, los objetos principales o la interacción entre clases y objetos. 

La figura de clase en sí misma consiste en un rectángulo de tres filas. La fila superior contiene el nombre de la clase, la fila del centro contiene los atributos de la clase y la última expresa los métodos o las operaciones que la clase puede utilizar. Las clases y las subclases se agrupan para mostrar la relación estática entre cada objeto.

La biblioteca de figuras UML en Lucidchart puede ayudarte a crear prácticamente cualquier diagrama de clases por medio de nuestra herramienta de diagramas UML.

Componentes básicos de un diagrama de clases

El diagrama de clases estándar está compuesto por tres partes:

• Sección superior: Contiene el nombre de la clase. Esta sección siempre es necesaria, ya sea que estés hablando del clasificador o de un objeto.
• Sección central: Contiene los atributos de la clase. Usa esta sección para describir cualidades de la clase. Esto solo es necesario al describir una instancia específica de una clase.
• Sección inferior: Incluye operaciones de clases (métodos). Esto está organizado en un formato de lista. Cada operación requiere su propia línea. Las operaciones describen cómo una clase puede interactuar con los datos.

¿QUE ES UN DIAGRAMA DE OBJETOS?

Un diagrama de objetos UML representa una instancia específica de un diagrama de clases en un momento determinado en el tiempo. Cuando se lo representa visualmente, verás muchas similitudes con el diagrama de clases.

Un diagrama de objetos se enfoca en los atributos de un conjunto de objetos y cómo esos objetos se relacionan entre sí. Por ejemplo, en el siguiente diagrama de objetos, las tres cuentas bancarias están ligadas al banco mismo. Los títulos de clase muestran el tipo de cuentas (ahorros, corriente y tarjeta de crédito) que un cliente dado podría tener con este banco en particular. Los atributos de clase son diferentes para cada tipo de cuenta. Por ejemplo, el objeto de tarjeta de crédito tiene un límite de crédito, mientras que las cuentas de ahorros y corriente tienen tasas de interés. Para examinar este documento con más detalle, haz clic aquí.

No obstante, los diagramas de objetos no se limitan a casos de uso bancarios, ya que se puede crear fácilmente un diagrama de objetos para árboles genealógicos, departamentos corporativos o cualquier otro sistema con partes interrelaciones.

Elementos del diagramas de objetos

Los diagramas de objetos son sencillos de crear: se componen de objetos, representados por rectángulos, conectados mediante líneas. Echa un vistazo a los elementos principales de un diagrama de objetos.

Objetos

Los objetos son instancias de una clase. Por ejemplo, si "coche" es una clase, un Altima 2007 de Nissan es un objeto de una clase.

Títulos de clases

Los títulos de clases son los atributos específicos de una clase dada. En el diagrama de objetos de árbol genealógico, los títulos de clases incluyen nombre, género y edad de los integrantes de la familia. Se pueden listar títulos de clases como elementos en el objeto o incluso en las propiedades del propio objeto (como el color).

 ¿QUE ES UN DIAGRAMA DE CASOS DE USOS?

En los apartados anteriores, vimos que el lenguaje UML es muy útil para la colaboración con personas sin conocimientos técnicos. Uno de los diagramas más importantes y útiles para entablar este proceso es el diagrama de casos de uso.

Empezaremos a escribir diagramas UML al final de la fase de inicio o al principio de la fase de elaboración. El primer tipo de diagrama que realizaremos es un diagrama de casos de uso. Es un diagrama que presenta a los usuarios finales del sistema y que trata de recoger todas las formas en la que los usuarios interactuarán con la aplicación.

Este diagrama es parte de los diagramas de comportamiento, que muestran de forma sencilla y visual cómo funciona el sistema para que todas las personas involucradas en el proyecto lo entiendan.

Ya estás familiarizado con casos de uso aunque no te des cuenta. Un caso de uso describe lo que siempre tiene que pasar dentro de nuestro sistema y los pasos para llegar a ello, pero también debe contemplar casos menos comunes. Por ejemplo, en caso de una avería o si el usuario cambia de idea a lo largo de su interacción

Ejemplo de un caso de uso

Vamos a ver algunos casos de uso para una tienda online.

1. Un vendedor de libros se conecta a la web para subir el articulo que tiene a la venta.
2. Un cliente se conecta a la página web de una tienda online para comprar un libro. Escribe el título del libro en la barra de búsqueda y busca el mejor precio entre los resultados. Cuando encuentra una oferta que le interesa, le añade al carrito de la compra. Tiene que haber iniciado una sesión para poder hacer

Relaciones

Las relaciones entre un actor y un caso de uso, se dibujan con una línea simple. Para relaciones entre casos de uso, se utilizan flechas etiquetadas “incluir” o “extender.” Una relación “incluir” indica que un caso de uso es necesitado por otro para poder cumplir una tarea. Una relación “extender” indica opciones alternativas para un cierto caso de uso.

Relaciones de los casos de uso

Las relaciones activas se conocen como relaciones de comportamiento y se utilizan principalmente en los diagramas de casos de uso. Hay cuatro tipos básicos de relaciones de comportamiento: comunica, incluye, extiende y generaliza.

¿QUE ES UN DIAGRAMA DE ESTADOS?

Este muestra la secuencia de estados por los que pasa bien un caso de uso, un objeto a lo largo de su vida, o bien todo el sistema. Es una forma de representación gráfica más intuitiva de los autómatas finitos basadas en dígrafos con arcos acotados llamados transiciones en los cuales se ponen los símbolos de tránsito entre un vértice (estado) y otro y se identifican los estados de partida y los de aceptación del resto. Los diagramas de estados finitos son también representaciones más cómodas para su elaboración, legibilidad y comprensión de distintos tipos de abstracciones computacionales de reconocimiento como los autómatas de pila y las máquinas de Turing.

Función

En el diagrama de estados se indica qué eventos hacen que se pase de un estado a otro y cuáles son las respuestas y acciones que genera. También ilustra qué eventos pueden cambiar el estado de los objetos de la clase. En cuanto a la representación, un diagrama de estados es un grafo cuyos nodos son estados y cuyos arcos dirigidos son transiciones etiquetadas con los nombres de los eventos. Normalmente contienen: estados y transiciones. Como los estados y las transiciones incluyen, a su vez, eventos, acciones y actividades. Al igual que otros diagramas, en los diagramas de estado pueden aparecer notas explicativas y restricciones.

Partes que conforman el Diagrama de Estados

Estado

Un estado se representa como una caja redondeada con el nombre del estado en su interior. Una transición se representa como una flecha desde el estado origen al estado destino. La caja de un estado puede tener 1 o 2 compartimentos. En el primer compartimento aparece el nombre del estado. El segundo compartimento es opcional, y en él pueden aparecer acciones de entrada, de salida y acciones internas.

Eventos

Es una ocurrencia que puede causar la transición de un estado a otro de un objeto. Esta ocurrencia puede ser una de varias cosas:

• Condición que toma el valor de verdadero o falso
• Recepción de una señal de otro objeto en el modelo

Recepción de un mensaje

Paso de cierto período de tiempo, después de entrar al estado o de cierta hora y fecha particular. El nombre de un evento tiene alcance dentro del paquete en el cual está definido, no es local a la clase que lo nombre.

Envío de mensajes

Además de mostrar y transición de estados por medio de eventos, puede representarse el momento en el cual se envían mensajes a otros objetos. Esto se realiza mediante una línea punteada dirigida al diagrama de estados del objeto receptor del mensaje.

Transición simple

Una transición simple es una relación entre dos estados que indica que un objeto en el primer estado puede entrar al segundo estado y ejecutar ciertas operaciones, cuando un evento ocurre y si ciertas condiciones son satisfechas. Se representa como una línea sólida entre dos estados, que puede venir acompañada de un texto con el siguiente formato:

Transición interna

Es una transición que permanece en el mismo estado, en vez de involucrar dos estados distintos. Representa un evento que no causa cambio de estado. Se denota como una cadena adicional en el compartimiento de acciones del estado.

Acciones

Se puede especificar la solicitud de un servicio a otro objeto como consecuencia de la transición. Se puede especificar el ejecutar una acción como consecuencia de entrar, salir, estar en un estado, o por la ocurrencia de un evento.

Generalización de Estados

Se puede reducir la complejidad de estos diagramas usando la generalización de estados. Se distingue así entre superestado y subestados. Un estado puede contener varios subestados disjuntos. Los subestados heredan las variables de estado y las transiciones externas. La agregación de estados es la composición de un estado a partir de varios estados independientes. La composición es concurrente por lo que el objeto estará en alguno de los estados de cada uno de los subestados concurrentes. La destrucción de un objeto es efectiva cuando el flujo de control del autómata alcanza un estado final no anidado. La llegada a un estado final anidado implica la subida al superestado asociado, no el fin del objeto.

Subestados

Un estado puede descomponerse en subestados, con transiciones entre ellos y conexiones al nivel superior. Las conexiones se ven al nivel inferior como estados de inicio o fin, los cuales se suponen conectados a las entradas y salidas del nivel inmediatamente superior.

Transacción Compleja

Una transición compleja relaciona tres o más estados en una transición de múltiples fuentes y/o múltiples destinos. Representa la subdivisión en threads del control del objeto o una sincronización. Se representa como una línea vertical de la cual salen o entran varias líneas de transición de estado.

Transición a estados anidados

Una transición de hacia un estado complejo (descrito mediante estados anidados) significa la entrada al estado inicial del subdiagrama. Las transiciones que salen del estado complejo se entienden como transiciones desde cada uno de los subestados hacia afuera (a cualquier nivel de profundidad).

Transiciones temporizadas

Las esperas son actividades que tienen asociada cierta duración. La actividad de espera se interrumpe cuando el evento esperado tiene lugar. Este evento desencadena una transición que permite salir del estado que alberga la actividad de espera. El flujo de control se transmite entonces a otro estado.

Ventajas y Desventajas

Ventajas

• El Diagrama de Estados tiene éxito en sistemas interactivos, ya que expresa la intención que tiene el actor (su usuario) al hacer uso del sistema.

• Como técnica de extracción de requerimiento permite que el analista se centre en las necesidades del usuario, qué espera éste lograr al utilizar el sistema, evitando que la gente especializada en informática dirija la funcionalidad del nuevo sistema basándose solamente en criterios tecnológicos.
• A su vez, durante la extracción (elicitation en inglés), el analista se concentra en las tareas centrales del usuario describiendo por lo tanto los casos de uso que mayor valor aportan al negocio. Esto facilita luego la priorización del requerimiento.

Desventajas

• La inclusión de estas relaciones hace que los diagramas sean más difíciles de leer, sobre todo para los clientes.

Importancia

Los diagramas de estado en el caso de los automatas 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.