UML
El lenguaje unificado de modelado (UML), sostiene la idea de que una imagen vale
más que mil palabras. Por ello, nos permite crear y generar diagramas para forjar
un lenguaje visual común en el complejo mundo del análisis y desarrollo de
software. Estos diagramas también son comprensibles para los usuarios y quien
desee entender un sistema.
Es importante aclarar que UML no es un lenguaje de programación, pero existen
herramientas que se pueden usar para generar código en diversos lenguajes
usando los diagramas UML. Además, UML guarda una relación directa con el
análisis y el diseño orientados a objetos.
“No es una metodología, sino una notación para desarrollar modelos (…) UML es
el estándar para visualizar, especificar, construir y documentar los artefactos de un
sistema de software”
Ahora veamos algunos conceptos de modelado especificados por UML. El
desarrollo de sistemas se centra en tres modelos generales de sistemas
diferentes:
1. Funcionales: Se trata de diagramas de casos de uso que describen la
funcionalidad del sistema desde el punto de vista del usuario.
2. De objetos: Se trata de diagramas de clases que describen la estructura
del sistema en términos de objetos, atributos, asociaciones y operaciones.
3. Dinámicos: Los diagramas de interacción, los diagramas de máquina de
estados y los diagramas de actividades se usan para describir el
comportamiento interno del sistema.
Un software que nos permite realizar Diagramas en UML es Lucidchart, y puedes
registrarte en el siguiente link: https://www.lucidchart.com
Más adelante visualizaremos con más detalle todas las características de UML.
Por ahora, vamos a conocer 2 tipos de diagramas para entender la POO (los
Diagramas de Clases, y los Diagramas de Secuencias)
Diagrama de Clases
El diagrama de clases es el diagrama UML más comúnmente usado, y la base
principal de toda solución orientada a objetos. En el se presentan las clases dentro
de un sistema, atributos y operaciones, y la relación entre cada clase. Las clases
se agrupan para crear diagramas de clases al crear diagramas de sistemas
grandes.
Los componentes básicos son:
1. 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.
2. Sección central: Contiene los atributos de la clase. Esta sección se usa
para describir cualidades de la clase.
3. Sección inferior: Incluye operaciones de clases (métodos). Estas se
organizan en un formato de lista y cada operación requiere su propia línea.
Las operaciones describen cómo una clase puede interactuar con los datos.
Todas las clases pueden tener diferente Visibilidad, es decir diferentes niveles de
acceso: Los más comunes son los Privados (-), y Protegidos (#)
Algunas clases pueden ser abstractas, porque en nuestro sistema no se crearía
una instancia de ella. El nombre de una clase abstracta puede colocarse en
Cursiva, o entre: <<nombre>>.
Además, hay diferentes relaciones entre clases:
1. Herencia: Es el proceso en el que una subclase o clase derivada recibe la
funcionalidad de una superclase o clase principal, también se conoce como
"generalización". Se simboliza mediante una línea de conexión recta con
una punta de flecha cerrada que señala a la superclase.
2. Asociación: Es la relación predeterminada entre dos clases. Ambas clases
están conscientes una de la otra y de la relación que tienen entre sí. Esta
asociación se representa mediante una línea recta entre dos clases.
3. Agregación: Relación en donde un objeto derivado puede existir sin su
objeto principal.
4. Composición: Relación en donde un objeto derivado no puede existir sin
su objeto principal.
5. Multiplicidad: Permite definir las relaciones numéricas (por ejemplo, 0..1,
n, 0..*, 1..*, m..n)
Diagrama de objetos
El diagrama de objetos muestra la relación entre objetos por medio de ejemplos
del mundo real e ilustra cómo se verá un sistema en un momento dado.
Representa a un objeto instanciado (creado en tiempo de ejecución) dentro de una
clase, estableciendo valores a los atributos. Dado que los datos están disponibles
dentro de los objetos, estos pueden usarse para clarificar relaciones entre objetos.
Los componentes básicos son:
Objetos: Los objetos son instancias de una clase. Por ejemplo, si "Auto" es una
clase, un 208 compacto de Peugeot es un objeto de una clase.
1. Títulos de clase: Los títulos de clases son los atributos específicos de una
clase dada. Se pueden listar títulos de clases como elementos en el objeto
o incluso en las propiedades del propio objeto (como el color).
2. Atributos: Los atributos de clases se representan por medio de un
rectángulo con dos pestañas que indica un elemento de software.
3. Enlaces: Los enlaces son líneas que conectan dos figuras de un diagrama
de objetos entre sí (debe nombrarse la interacción).
También, al igual que en el diagrama de clases, se puede agregar una tercera
sección donde estén indicados los métodos u operaciones.
"El diagrama de objetos también es conocido como diagrama de instancias"
Diagrama de components
El diagrama de componentes es uno de los principales diagramas UML. Está
clasificado como diagrama de estructura y, como tal, representa de forma estática
el sistema de información. Habitualmente se utiliza después de haber creado el
diagrama de clases, pues necesita información de este diagrama como pueden
ser las propias clases.
Este diagrama proporciona una vista de alto nivel de los componentes dentro de
un sistema. Los componentes pueden ser un componente de software, como una
base de datos o una interfaz de usuario; o un componente de hardware como un
circuito, microchip o dispositivo; o una unidad de negocio como un proveedor,
nómina o envío.
Algunos usos de este tipo de diagrama es el siguiente:
Se utilizan en desarrollo basado en componentes para describir sistemas
con arquitectura orientada a servicios.
Mostrar la estructura del propio código.
Se puede utilizar para centrarse en la relación entre los componentes
mientras se ocultan los detalles de las especificaciones.
Ayudar a comunicar y explicar las funciones del sistema que se está
construyendo a los interesados o stakeholders.
Elementos del diagrama de componentes
1. Componente
Un componente es un bloque de unidades lógicas del sistema, una abstracción
ligeramente más alta que las clases. Se representa como un rectángulo con un
rectángulo más pequeño en la esquina superior derecha con pestañas o la palabra
escrita encima del nombre del componente para ayudar a distinguirlo de una
clase.
Un componente puede representar dos tipos de elementos: componentes lógicos
(como por ejemplo componentes de negocio o proceso) o
componentes físicos (como
componentes .NET, EJB…). Por ejemplo, en una aplicación
desarrollada en java habrá, con total seguridad,
varios componentes “.java”, que son componentes
lógicos del sistema.
2. Interfaz
La interfaz está siempre asociada a un componente y se utiliza para representar la
zona del módulo que es utilizada para la comunicación con otro de los
componentes.
Se representa con una línea que tiene al final un circulo no relleno:
Otros módulos pueden conectarse a una
interfaz. Esto se hace cuando un componente requiere o utiliza al otro componente
mediante su interfaz, que son las operaciones externas que ofrece el componente.
Se representa con un linea que termina en un semicírculo que rodea la interfaz del
otro componente. En el diagrama se vería de la siguiente manera:
3. Relación de dependencia
La relación de dependencia representa que un componente requiere de otro para
ejecutar su trabajo. Es diferente a la interfaz, pues esta identifica que un
componente ofrece una serie de operaciones. En cualquier caso, en ocasiones
para simplificar el diagrama no se usan las interfaces sino que solamente se
utilizan relaciones de dependencia.
Una relación de dependencia se representa mediante una flecha discontinua que
va desde el componente que requiere de otro componente hasta el requerido.
Diagrama de componentes de una tienda online
Diagrama de secuencias
El diagrama de secuencia es un esquema conceptual que permite representar el
comportamiento de un sistema. Muestra cómo los objetos interactúan entre sí y el
orden de la ocurrencia. Representan interacciones para un escenario concreto.
El diagrama de secuencia describe básicamente cómo los objetos (e instancias)
intercambian mensajes en un orden determinado. Los objetos son los bloques de
construcción básicos de los diagramas UML y representan ciertas características
de un elemento del sistema, que varían dependiendo del diagrama. En las
interacciones, los objetos son las conocidas como líneas de vida.
Los diagramas de secuencia UML también son útiles cuando es necesario
representar gráficamente operaciones complicadas para su mejor comprensión.
Gracias a un modelado claro es posible identificar rápidamente las estaciones por
las que debe pasar una única tarea para que se complete con éxito. Así, por
ejemplo, es posible planificar y probar distintos métodos antes de implementarlos
en el negocio diario o en un sistema informático
Elementos del diagrama de secuencia
1. Rol de la clase
El rol de la clase describe la manera en que un objeto se va a comportar en el
contexto. No se listan los atributos del objeto.
2. Activación
Los cuadros de activación representan el tiempo que un objeto necesita para
completar una tarea.
3. Líneas de vida
Una línea de vida representa el curso del tiempo de un proceso. A la cabeza se
sitúa un rectángulo que contiene normalmente el nombre del objeto y el nombre de
la clase. Si falta el nombre del objeto, la línea de vida representa a una instancia
de objeto sin nombre. En este caso, se puede suponer que todos los objetos de la
misma clase actúan de la misma forma en esta secuencia. La línea de vida
siempre representa un solo operando. Si el operando tiene varios valores, se debe
seleccionar uno de ellos, es decir, la multiplicidad nunca es >1.
La línea discontinua situada bajo el encabezamiento representa el transcurso del
tiempo. El tiempo tiene un desarrollo lineal descendente. A lo largo de la línea
temporal se envían los mensajes y las respuestas. Un mensaje que haya de
enviarse tras otro se sitúa más abajo en la línea de tiempo. En esta notación no se
trata de puntos concretos en el tiempo, sino siempre de una secuencia. Los
mensajes siempre están dispuestos uno debajo de otro, a menos que existan en
fragmentos combinados de forma paralela.
Las líneas de vida indican cuánto tiempo participa activamente un objeto en un
proceso, lo que se puede ver por la longitud de una línea en comparación con
otras. Algunos objetos se destruyen antes de que el proceso haya terminado.
Cuando ya no se necesita un objeto, se indica con una X el punto en la línea de
vida en el que se ha de destruir.
Si quieres comprobar la robustez de tu sistema, el diagrama de secuencia es muy
adecuado pues muestra una vista muy detallada. Se pueden utilizar tres
estereotipos de clase de la línea de la vida:
Entidad
Límite
Control
En la imagen de arriba se pueden ver estas tres líneas de vida con la notación: la
entidad tiene una cabeza circular que se sitúa sobre una línea horizontal. El
estereotipo de línea de vida denominado límite consta de una cabeza de la misma
forma de la que sale una línea horizontal que conecta con otra vertical: a modo de
T rotada noventa grados a la izquierda. La cabeza del estereotipo de control está
compuesta por una flecha que gira en círculo. De todos estos estereotipos sale
una línea de vida discontinua, que desciende en vertical.
Los límites (boundaries) representan interfaces que interactúan con actores
externos. Estos objetos pueden ser, por ejemplo, interfaces de usuario, en cuyo
caso el actor correspondería a una persona. Las entidades (entities), por otro lado,
son contenedores de datos, o sea, objetos que contienen datos del sistema. Para
que los límites y las entidades se comuniquen, se necesita un elemento de control.
El control no tiene que ser necesariamente un objeto; también funciona un método
que se asigna a uno de los otros dos elementos. Se trata del medidador que
conecta entidad y límite, monitoriza las señales de los dos elementos y comprueba
su lógica.
Los tres estereotipos se comunican siguiendo estas cuatro reglas:
Los objetos de límite son, como interfaces, responsables de la
comunicación con los actores. De este modo, los actores se comunican
exclusivamente con las fronteras.
Por el contrario, los objetos de control se comunican con otros objetos de
control, así como con entidades y límites. Pero no interactúan con los
actores.
Los límites se comunican con los objetos de control y con los actores.
Las entidades son los soportes de datos más arraigados en el sistema. Solo
intercambian datos con objetos de control.
4. Mensajes
El mensaje es un elemento básico del diagrama de secuencia. En la programación
orientada a objetos, un sistema se compone de objetos. UML presenta estos
objetos como nodos unidos entre sí por los elementos de conexión, que en UML
pueden realizar varias tareas. Concretamente, en el diagrama de secuencia UML
se encargan de modelar los mensajes de metaclase. Como forma básica del
elemento de conexión la notación establece una línea. Las flechas son una forma
especial de elemento de conexión que representan una relación direccional o flujo
de información. En el diagrama de secuencia simbolizan a los mensajes.
5. Destrucción de objetos
Los objetos pueden ser eliminados tempranamente usando una flecha etiquetada
«<<destruir>>» que apunta a una X.
Ejemplo de un diagrama de secuencia
Diagrama de casos de uso
Un caso de uso es una descripción de las acciones de un sistema desde el punto
de vista del usuario. Es una herramienta valiosa dado que es una técnica de
aciertos y errores para obtener los requerimientos del sistema, justamente desde
el punto de vista del usuario.
Los diagramas de caso de uso modelan la funcionalidad del sistema usando
actores y casos de uso. Los casos de uso son servicios o funciones provistas por
el sistema para sus usuarios.
Elemento del diagrama de casos de uso
1. Sistema
El rectángulo representa los límites del sistema que contiene los casos de uso.
Los actores se ubican fuera de los límites del Sistema
2. Casos de uso
Se representan con óvalos. La etiqueta en el óvalo indica la función del sistema
3. Actores
Un diagrama de caso de uso contiene los símbolos del actor y del caso de uso,
junto con líneas conectoras. Los actores son similares a las entidades externas;
existen fuera del sistema. El término actor se refiere a un rol específico de un
usuario del sistema.
4. 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.
Ejemplo de un diagrama de caso de uso
Diagrama de máquina de estados
Un diagrama de estado UML (también llamado diagrama de estado, diagrama de
transición de estados o diagrama de máquina de estados) muestra los estados por
los que pasa una máquina de estados finitos, es decir, un modelo de
comportamiento que consiste en acciones y estados o transiciones a otros
estados. El diagrama proporciona un estado inicial y uno final, así como al menos
un estado intermedio para cada objeto. El diagrama de estado permite, de este
modo, representar el ciclo de vida completo de cualquier sistema, subsistema o
componentes o clases del mismo, como podrían ser una máquina de café, un
lector de libros electrónicos o un componente tecnológico de un vehículo.
Entre otras cosas, esta representación gráfica de los procesos debería dar
respuesta a las siguientes preguntas:
¿Qué sucede cuando el objeto está en un estado concreto?
¿En qué estado debe estar el objeto para cambiar de comportamiento?
¿Cuáles son los desencadenantes?
¿Qué propiedades debe tener el objeto para poder cambiar de estado?
Por lo tanto, los diagramas de estado UML se utilizan para optimizar cualquier
proceso de desarrollo donde sea útil visualizar los estados del objeto y las
condiciones para que se produzca la transición de un estado a otro. Suelen
emplearse, por ejemplo, en el diseño de sistemas embebidos (en inglés,
embedded systems), donde las señales automatizadas y los procesos en segundo
plano deben estar perfectamente coordinados. En este caso, el diagrama de
estado ayuda a los desarrolladores a visualizar todas las funciones de control y
regulación más importantes en un solo esquema.
La función de interrupción de la toma de agua que tienen casi todas las lavadoras
puede servirnos de ejemplo para imaginar un diagrama de estado UML. En este
contexto, esta función se representaría como un sistema independiente. En este
caso, el esquema mostraría en qué estado y bajo qué condiciones se activa la
función.
Elementos del diagrama de máquina de estados
1. Estados
Los estados son el componente principal de un diagrama de estado. Cada estado
real se muestra siempre en un rectángulo de esquinas redondeadas. Por ejemplo,
una puerta puede tener dos valores de estado
Asimismo, en el diagrama de estado de la puerta se indicaría que siempre debe
cumplirse la siguiente condición:
El objeto siempre se encuentra en uno de los dos estados: la puerta está
abierta o cerrada, pero nunca abierta y cerrada al mismo tiempo.
2. Transacciones
La transición que figura en el siguiente ejemplo se considera externa y tiene como
resultado que el objeto cambie de estado (entry/exit).
Ejemplo: después de que se active la alarma de una radio-despertador, el estado
cambia de “alarma activada” a “alarma desactivada”.
Ejemplo diagrama máquina de estados
Diagrama de actividad
Los diagramas de actividad son uno de los cinco diagramas en el UML para
modelar los aspectos dinámicos de un sistema. Un diagrama de actividad es un
caso especial de un diagrama de estado, en el cual casi todos los estados son
estados de acción (identifican qué acción se ejecuta al estar en él) y casi todas las
transiciones son enviadas al terminar la acción ejecutada en el estado anterior.
Este diagrama es el menos familiar y se utiliza poco en UML.
Los diagramas de actividad pueden visualizar, especificar y documentar la
dinámica de un conjunto de objetos. También se pueden usar para modelar el flujo
de control de una operación. Mientras que los diagramas de interacción enfatizan
el flujo de control de un objeto a otro, los diagramas de actividad subrayan el flujo
de control de una actividad a otra. La gran desventaja de los diagramas de
actividad es que no indican de forma explícita qué objetos ejecutan qué
actividades ni tampoco la forma en que el servicio de mensajería trabaja entre
ellos.
Para mostrar tales interacciones de forma clara son necesarios los diagramas de
interacción, los cuales son más utilizados en la práctica.
Los diagramas de actividad son útiles cuando queremos describir un
comportamiento paralelo, o cuando queremos mostrar qué
comportamientos interactúan en varios casos de uso
Los diagramas de interacción se utilizan cuando se quiere mostrar cómo
colaboran los objetos para implementar un diagrama de actividad.
Los diagramas de estado se utilizan cuando se quiere mostrar cómo
cambia un objeto a lo largo de su tiempo de vida.lementos de un diagrama
de actividad
Elementos de un diagrama de actividad
Ejemplo de un diagrama de actividad