TOUR POR UML

 

 

En este artículo daremos un recorrido por las partes más importantes de UML e intentaremos haceros ver la importancia de modelar y porqué es tan importante un buen diseño de software.

 

Un proyecto de software con éxito es aquél que produce un software de calidad, consistente y sobre todo que satisface las necesidades de los usuarios que van a utilizar el producto resultante.

 

Una empresa que produce software de calidad, con un uso eficiente y efectivo de los recursos y terminar los proyectos en plazo tiene un negocio sostenible. Y tenemos que tener en cuenta que lo que importa es el producto final, que funcione bien y que cumpla los requisitos establecidos por los usuarios y no que sea muy bonito, que se hagan reuniones muy importantes o que se hayan codificado muchas líneas de código.

 

Hace ya tiempo leí una frase que creo que merece la pena recordar: “Para desarrollar software de calidad duradera, hay que idear una sólida base arquitectónica que sea flexible al cambio”.  El modelado es una parte fundamental en esta aspecto, construimos modelos para poder visualizar el comportamiento del sistema y poder controlar su arquitectura.

 

Incluso para producir software de sistemas pequeños sería bueno hacer un análisis y un modelado ya que se producirían sistemas de mejor calidad, pero lo que si es cierto, es que cuanto más grande y complejos son los sistemas más importante es hacer un buen modelado ya que nos ayudará a entender el comportamiento del sistema en su totalidad y que si no tenemos modelado sería bastante difícil. Y cuando se trata de sistemas complejos el modelado nos dará una idea de los recursos necesarios (tanto humanos como materiales) para abordar el proyecto. También nos dará una visión más amplia de cómo abordar el problema para darle la mejor solución.

 

El Lenguaje Unificado de Modelado (Unified Modeling Languaje, UML) es el lenguaje estándar para realizar el modelado de los sistemas de software y es independiente del lenguaje de programación utilizado.

 

En este artículo no vamos a entrar en más detalles de lo que es UML y de su historia, nos vamos a centrar en las partes más significativas del lenguaje.

 

UML tiene tres elementos fundamentales:

·         Bloques básicos de construcción

o        Elementos

o        Relaciones

o        Diagramas

·         Reglas que dictan como se pueden combinar estos bloques básicos. UML tiene reglas para:

o        Nombres

o        Alcance

o        Visibilidad

o        Integridad

o        Ejecución

·         Mecanismos comunes. Que se basen en algún patrón, al igual que en arquitectura se puede hablar del barroco, románico, etc..

o        Especificaciones

o        Adornos

o        Divisiones comunes

o        Mecanismos de extensibilidad

 

 

Como dijo Grady Booch: El 80 por ciento de la mayoría de los problemas pueden modelarse usando alrededor del 20 por ciento de UML.

 

En todo proceso de software donde se utilice una metodología orientada a objetos y la notación UML no pueden faltar los diagramas, para representar las diferentes vistas del producto final.

 

Los diagramas de UML se pueden dividir en estáticos (aportan una visión estática del sistema) y dinámicos (aportan una visión dinánica del sistema).

 

Los diagramas estáticos:

·         Diagrama de casos de uso

·         Diagrama de clases

·         Diagrama de objetos

·         Diagrama de componentes

·         Diagrama de despliegue

 

Los diagramas dinámicos:

·         Diagrama de estados

·         Diagrama de actividad

·         Diagramas de interacción:

o        Diagrama de secuencia

o        Diagrama de colaboración

 

 

 

Como se puede ver hay demasiados diagramas y en muchos proyectos no son necesarios todos los diagramas. Será la práctica y experiencia y el tipo de sistema a desarrollar lo que nos ayudará a escoger los diagramas a utilizar, por ejemplo podemos decir que para aplicaciones cliente se suelen utilizar los diagramas de casos de uso, de clase y de colaboración o de secuencia, para aplicaciones donde sean importantes los eventos se puede utilizar el diagrama de estados, para aplicaciones cliente-servidor aparte de los diagramas de casos de uso, clases y objetos también puede ser conveniente utilizar los diagramas de despliegue y componentes, y para aplicaciones complejas cliente-servidor pues si será recomendable utilizar todos los diagramas ya que dará una visión más amplia de cómo será el sistema final.

 

 

 

 

 

 

 

 

 

 

Diagramas de casos de uso.

Los diagramas de casos de uso muestran la funcionalidad del sistema desde la perspectiva que tienen los usuarios y lo que el sistema debe de hacer para satisfacer los requisitos propuestos. Pueden mostrar el comportamiento de un sistema completo o de una parte.

 

Los elementos básicos que se utilizan son:

1. Actores: Son los diferentes usuarios y el papel que representan dentro del sistema.

 

2. Caso de uso: Representan todo lo que el usuario puede realizar dentro del sistema

 

       

 

3. Relaciones: Para asociar los elementos anteriores.

 

Comunicación

 

Generalización   

 

Extensión (*)

 

Inclusión (*)

 

(*) En estas dos se deben de poner también las letras (include, o exclude).

 

 

 

Ejemplo:

 

 

Diagramas de clases

Los diagramas de clases son estáticos porque no describen un comportamiento en función del tiempo. Tienen que ver con la implementación de la aplicación.

 

Los elementos son:

1.      Clases: Se pueden definir como la descripción de un conjunto de objetos con las mismas propiedades. Puede ser un concepto del mundo real, se puede decir que es una plantilla para crear objetos.

2. Relaciones: Las relaciones pueden ser de distintos tipos asociación, agregación, herencia (generalización, especialización).

 

 

Ejemplo:

 

 

 

 

 

Diagrama de Estados

 

El diagrama de estados es un gráfico compuesto de los estados del sistema y sus transiciones.

 

Si se asocia a una clase describirá como una instancia de esta clase reacciona ante los eventos.

 

Si se asocia a un caso de uso describirá como funciona ese caso de uso con el sistema funcionando.

 

Estos diagramas son muy útiles para mostrar el ciclo de vida de las clases con complejidad media o alta, pero no tiene mucho sentido para clases de una complejidad simple ni tampoco para clases con una complejidad bastante elevada.

 

Símbolo inicial

                                   Símbolo de Fin

                   

                      

 

Ejemplo:

 

 

 

 

Diagrama de colaboración

 

Los diagramas de colaboración son útiles para mostrar los efectos que puede tener un  objeto con los demás.

 

Los elementos básicos son clases encerradas en rectángulos, enlaces entre clases y operaciones entre clases.

 

La estructura estática viene dada por los enlaces; la dinámica por el envío de

mensajes por los enlaces.

 

Ejemplo:

 

 

 

 

 

Diagrama de secuencia

 

Estos diagramas representan la interacción entre clases, se leen de izquierda a derecha y de arriba abajo. Muestran el comportamiento del sistema de forma cronológica. Y por esto son muy útiles cuando se está trabajando con sistemas de tiempo real.

 

Los elementos básicos son las clases que se representan con rectángulos, los actores, las barras de sincronización temporal que se representan con líneas discontinuas y los mensajes que se representan con flechas.

 

Ejemplo: