Introducción a UML

Hola a todos y bienvenidos a un nuevo artículo: Introducción a UML.

No, no me he equivocado. Parece el mismo artículo de la última vez, pero hoy no es XML sinó UML.
Dejando de banda mi originalidad para los títulos, os diré que éstas son las siglas de “Unified Modeling Language” o “Lenguaje unificado de modelado”.

Está formado por un conjunto de diagramas que representan, con total precisión, cómo está diseñado un programa o cualquier proceso. Algo así como una “foto” que capta la estructura básica de una aplicación, como el plano que un arquitecto haría del edificio que va a construir.

En una empresa de software, el analista suele pasar diagramas UML al programador, para indicarle las partes a desarrollar de un programa.

 

Ejemplo de diagrama UML: Casos de uso

Introducción a UML

Antes de meternos en materia, vamos a hablar del diseño de software. Cuando las prisas aprietan (lo que es bastante común, por desgracia) nuestra primera reacción es «Corre! Ponte a programar como un loco, y así acabarás a tiempo».

Pocas veces esto es cierto, y en la mayoría de los casos completamente falso. El primer paso debería ser analizar los requerimientos de nuestro cliente. Tan fácil como una reunión de esas de «café y libreta», por ejemplo con el siguiente guión:

Nosotros: Buenos días

Cliente: Buenos días

Nosotros: Explíqueme. ¿Qué tipo de aplicación necesita?

Cliente: Pues es una aplicación para gestionar el stock de la empresa…

Nosotros: Explíqueme más (tomamos nota de las funcionalidades generales de la aplicación)

Cliente: (Sigue explicando, y termina)

Nosotros: ¿Me puede explicar más a fondo este punto? (alta, baja de productos… etc)

….

«Esta reunión se está alargando… ¡Y no quedan plátanos!»

Ni que decir tiene, que en un día no suele tomarse toda la información. La primera reunión es una toma de contacto, donde sabremos de qué irá la aplicación y qué funcionalidades va a tener. Estas funcionalidades cambiarán, porque muchas veces el mismo cliente no tiene claro del todo qué necesita, así que esas especificaciones evolucionan. Así que ya sabéis: Os pedís A Relaxing Café Con Leche, y paciencia!

Una vez tenemos documentadas al detalle las necesidades del cliente, es el momento de comenzar con UML.

1. Diagrama de casos de uso

este tipo de diagrama explica visualmente qué funcionalidades están disponibles en la aplicación para los diferentes «actores» que pueden participar en ella. Un actor es un perfil determinado, por ejemplo no tendrán las mismas posibilidades un usuario de cajero que el técnico que lo mantiene.

2. Diagrama de secuencia

Aquí el objetivo es mostrar la secuencia (como el nombre indica) de las acciones a realizar por el sistema, dada una petición del usuario. Por ejemplo, en este caso el usuario pide un reintegro. El cajero se comunica con la base de datos del banco, resta la cantidad pedida por el cliente, obtiene una respuesta de esa base de datos, en este caso un ok, y expende los billetes al usuario.

3. Diagrama de estados

Muestra los estados en que puede encontrarse un objeto, proceso o usuario. En este caso estamos hablando del cajero automático, que puede estar «En espera» de un usuario que lo utilice, «En funcionamiento» cuando está procesando acciones del usuario, y «Bloqueado» si ha habido algún problema, como detectar una tarjeta robada, o una avería de la maquina etcétera.

4. Diagrama de clases

Este diagrama sería la última fase antes de comenzar a programar, detalla qué clases necesitamos en nuestro programa y exactamente qué variables y funciones vamos a necesitar, además de las relaciones de herencia entre ellas (si las hay).

Hay otros muchos tipos de diagramas UML, pero estos son con mucho los más utilizados. Un buen diseño UML no tiene porqué usarlos todos, sino solamente los necesarios en cada momento.

Es tan perjudicial una documentación muy breve, como un exceso de ella. Por otra parte, una aplicación es algo «vivo» que va evolucionando, sobre todo cuando el cliente cambia las especificaciones. En principio esto no debería ocurrir, o no muy a menudo, pero en la práctica siempre hay modificaciones ya sea por errores de su parte, o por interpretaciones nuestras que no fueron acertadas. En estas situaciones, hay que actualizar la documentación para que refleje los cambios realizados.

Hasta aquí la introducción a UML, espero que os haya gustado y que os haya picado la curiosidad para seguir aprendiendo del tema. Adjunto 2 webs muy interesantes que tratan el tema a fondo, y el programa usado en los ejemplos

http://docs.kde.org/stable/es/kdesdk/umbrello/uml-basics.html

http://www.slideshare.net/MeneRomero/introduccin-a-uml-11458977

programa usado en los diagramas del artículo

http://alexdp.free.fr/violetumleditor/page.php

Gracias por vuestra atención, y saludos!